연말 보안 감사를 준비하며 한 해를 되짚어보던 날
올해 마지막 근무일, 외부 감사 기관에서 한 해 동안의 시스템 변경 이력을 전부 제출해달라고 요청해왔습니다.
어디서부터 뽑아야 하나 고민하다가, 로그를 다시 뒤져보니 이미 필요한 게 전부 한곳에 쌓여 있었습니다.
누가 뭘 언제 바꿨는지 통째로 남아있던 이유, 감사로그
text
12026-03-14 14:02 user:jiho action:deploy target:payment-service22026-03-14 14:05 user:jiho action:permission-change target:admin-panel
일 년치 로그를 다시 열어보니, 누가 언제 무슨 작업을 했는지가 하나도 빠짐없이 시간 순서대로 남아 있었습니다. 사람이 따로 기록하지 않아도, 시스템 자체가 모든 중요한 행동을 자동으로 남겨두는 별도의 기록이었습니다. 평소엔 아무도 들여다보지 않다가 문제가 터지고 나서야 되돌려보게 되는, 은행 CCTV 같은 기록이었습니다. 감사 기관에 이 로그를 그대로 제출했습니다.
로그를 정리하다가, 올 한 해 정말 큰 변경 작업 전마다 항상 먼저 켰던 모드 하나가 떠올랐습니다.
큰 작업 전, 코드를 건드리기 전에 먼저 확인하는 이유, 플랜 모드
입사 초반, 사수가 알려준 습관이었습니다. "위험한 작업일수록, 일단 계획부터 세우게 하고 그다음에 실행시켜."
text
1[PLAN MODE] 코드를 수정하지 않고 계획만 세웁니다.
실제로 파일을 고치기 전에, 어떤 순서로 무엇을 바꿀지 계획부터 세우고 사람이 그 계획을 검토한 다음에야 실행에 들어가는 방식이었습니다. 집을 고치기 전에 설계도부터 확인받는 것과 같아서, 이 습관 덕분에 올해 큰 사고 없이 넘어간 작업이 여럿 있었습니다.
화면도 없이 서버 혼자 알아서 돌아가는 이유, 헤드리스 모드
bash
1$ claude --headless "테스트 실행하고 결과 요약"
문서를 보니, 사람이 화면을 보며 대화하는 방식 말고도 이렇게 쓸 수 있는 방식이 따로 있었습니다. 화면이나 대화창 없이, 명령 하나로 실행되고 결과만 파일이나 로그로 남기는 방식이었습니다. 사람이 지켜보지 않아도 정해진 절차대로 알아서 돌아가는 무인 매장에 가까웠습니다. 올 한 해 밤사이 자동으로 돌아간 테스트가 이 방식 덕분이었습니다.
파이프라인 코드를 살펴보다가, 몇 달 전 동료가 만든 설정 하나가 왜 있는지 궁금해졌습니다.
동시에 너무 많은 요청이 몰리지 않게 막아둔 것, 세마포어
js
1const semaphore = new Semaphore(5); // 동시에 5개까지만
동료가 예전에 만들어둔 코드를 보니, 외부 API에 동시에 너무 많은 요청이 몰려서 차단당했던 일이 있었고 그 뒤로 이 장치를 걸어뒀다고 적혀 있었습니다.
정해진 개수만큼만 동시에 통과시키고, 그 자리가 다 차면 나머지는 순서를 기다리게 만드는 신호등 같은 장치였습니다. 좁은 통로에 한 번에 다섯 명씩만 들여보내고 나머지는 줄 세우는 것과 비슷했습니다. 이 설정 덕분에 올해는 같은 문제가 재발하지 않았습니다.
감사 자료를 거의 다 모았을 때쯤, 올해 초 있었던 큰 장애의 원인 조사 파일이 폴더 한구석에 남아있는 걸 발견했습니다.
서버가 통째로 멈췄을 때 남는 마지막 흔적, 코어 덤프
text
1Segmentation fault (core dumped)2core.12045 generated
파일 크기가 몇백 메가바이트나 되는 이 파일을 처음 봤을 땐 뭔지도 몰랐는데, 시스템이 스스로 남긴 설명 덕분에 알게 됐었습니다. 프로그램이 갑자기 멈췄을 때, 그 순간 메모리에 있던 모든 상태를 그대로 파일 하나에 얼려서 남겨두는 방식이었습니다. 사고 현장을 그대로 봉인해두었다가 나중에 감식반이 재구성하는 것과 비슷했습니다. 이 파일 덕분에 그때 장애 원인을 정확히 밝혀서, 올해 감사 보고서에도 원인과 재발 방지 조치를 함께 적을 수 있었습니다.
감사 자료를 다 모으고 나니 창밖은 이미 어두워져 있었고, 사무실엔 몇 명 남아있지 않았습니다.
1편에서 서브에이전트가 뭔지도 몰라 당황했던 게 바로 올해 초였습니다. 그 사이 훅, 슬래시커맨드, 샌드박스, 컴파일, 데드락 같은 낯선 말들을 하나씩 실제로 부딪히며 익혔습니다. 돌아보니 낯설던 말 하나하나가, 그 순간엔 당황스러웠어도 결국 지나고 나면 다음번엔 더 빨리 알아보게 해주는 표지판 역할을 했습니다.
자주 묻는 질문
감사로그는 얼마나 오래 보관해야 하나요?
업종이나 규정에 따라 다르지만, 보통 최소 1년 이상 보관하도록 요구되는 경우가 많습니다. 저장 비용을 고려해 오래된 로그는 압축해서 별도 보관소로 옮기는 방식을 씁니다.
세마포어 자리 수는 어떻게 정하나요?
정답이 정해져 있지는 않고, 상대 서버가 감당할 수 있는 동시 요청 수를 참고해서 정합니다. 너무 적으면 대기가 길어지고, 너무 많으면 원래 막으려던 문제가 재발할 수 있습니다.
코어 덤프 파일은 아무나 열어봐도 되나요?
그 순간의 메모리 상태를 그대로 담고 있어서 민감한 정보가 들어있을 수 있습니다. 조사 목적이라도 접근 권한을 제한하고, 다 확인한 뒤에는 안전하게 삭제하는 게 안전합니다.
<a href="/glossary/code-generation" class="glossary-link" title="AI가 자연어 설명이나 기존 코드 문맥을 바탕으로 프로그래밍 코드를 자동으로 작성하는 기술입니다.">AI 코딩</a> 도구 용어 사전 연작의 14편입니다. 시리즈를 마치며 AI 코딩 도구 용어 사전, 14편으로 완결합니다 1편 서브에이전트부터 14편 코어 덤프까지, 70개 용어를 실제로 부딪히며 정리했습니다. 읽어주셔서 감사합니다.