Chapter 21. 운영과 인시던트 대응

서비스는 출시하는 날보다, 출시한 뒤 살아 있는 날이 훨씬 길다. 멋지게 배포한 Next.js + Supabase 예약 SaaS도, 잘 돌아가던 Express + MongoDB 백오피스 API도, 어느 날 새벽 갑자기 느려지고, 깨지고, 알림을 쏟아낸다. 그때부터 개발은 다시 시작된다.

지난 장이 배포 직전의 품질 루프였다면, 이번 장은 배포 이후의 생존 루프다. 핵심은 단순하다. Codex를 운영 단계의 조수로 바꾸는 것이다. 코드를 짜게 하는 데서 끝내지 않고, 모니터링 신호를 읽고, 알림을 분류하고, 장애를 트리아지하고, 보안 취약점을 스캔하고, 안전한 핫픽스 초안까지 가져오게 만드는 것이다.

여기서 중요한 전제가 하나 있다. 운영에서 Codex의 역할은 대체로 '판단을 대신하는 사람'이 아니라 '판단에 필요한 맥락을 빠르게 모아 주는 사람'이다. 장애 대응 시간의 대부분은 코드를 치는 시간보다, 무슨 일이 벌어졌는지 파악하는 시간에 쓰이기 때문이다.¹²

운영에서 Codex가 진짜 잘하는 일

운영 업무를 잘게 뜯어 보면 의외로 반복이 많다. 최근 알림 모아 보기, 실패한 배포 확인하기, 관련 로그 찾기, 최근 커밋과 배포를 대조하기, 이슈 우선순위 정리하기, 비슷한 장애가 있었는지 찾아보기 같은 일들이다. 사람에게는 귀찮고, 새벽에는 더 느리지만, 에이전트에게는 꽤 잘 맞는 일이다.

특히 Codex는 최근 알림, 이슈, 실패한 체크, 로그, 채팅 보고를 한 스레드로 모아 우선순위를 정리하는 식의 버그 트리아지 자동화에 잘 맞는다.¹ 운영자가 원하는 것은 알림 200개가 아니라, '지금 가장 먼저 봐야 할 3개'이기 때문이다.

운영에서 Codex에게 맡기기 좋은 일은 대체로 네 가지다.

• 여러 시스템에 흩어진 신호를 한데 모아 요약하기

• 최근 변경 사항과 장애 시점을 빠르게 상관 분석하기

• 재현 가능한 핫픽스 초안을 diff로 만들기

• 장애 후 포스트모템 초안을 정리하기

반대로 '프로덕션에 바로 손대기'는 다른 문제다. 운영은 자동화보다 가드레일이 먼저다. 빠른 손보다, 잘 멈추는 손이 더 중요하다.

모니터링은 많이 보는 것보다 잘 읽히게 만드는 게 먼저다

모니터링을 처음 붙일 때 많은 팀이 대시보드부터 화려하게 만든다. 그런데 운영이 잘되는 팀은 대시보드보다 먼저 질문을 정리한다.

이런 질문들이다.

• 지금 사용자가 실제로 겪는 문제는 무엇인가

• 어느 서비스가 처음부터 이상했는가

• 직전 30분 안에 바뀐 것은 무엇인가

• 지금 당장 해야 할 첫 완화 조치는 무엇인가

Codex가 운영에서 힘을 발휘하려면, 이 질문에 답할 재료가 연결돼 있어야 한다. 메트릭, 로그, 트레이스, 최근 배포, 이슈 트래커, 팀 채팅이 서로 따로 놀면 Codex도 똑똑한 척만 할 뿐이다. 반대로 관측 데이터가 연결돼 있으면, 에이전트는 '에러율 급증 → 특정 API 엔드포인트 집중 → 직전 배포 존재 → 관련 커밋 범위 확인' 같은 흐름을 아주 빠르게 엮어 낸다.²³

예를 들어 동네 병원 예약 SaaS를 운영한다고 해보자. 오전 9시에 알림이 쏟아진다. /api/reservations의 500 응답이 늘고, 로그인 성공률도 떨어졌다. 이때 사람이 대시보드 6개를 탭 전환하며 보는 대신, Codex에게 이렇게 맡길 수 있다.

지난 30분 동안 예약 생성 실패와 로그인 실패 관련 알림, 최근 배포, 실패한 체크, 고객 문의를 모아 우선순위 순으로 정리하고, 공통 원인이 있는지 요약해줘.

이 한 문장으로 장애가 해결되지는 않는다. 하지만 빈 터미널 앞에서 멍해지는 시간을 크게 줄여 준다. 운영에서 가장 비싼 것은 종종 CPU가 아니라 멈칫하는 10분이다.

알림은 울리는 것이 아니라 분류되는 것이 중요하다

운영 초보 팀은 종종 알림을 세게 건다. CPU 70%, 메모리 75%, 에러 한 건, 지연 1초 증가. 그러면 어떻게 되느냐. 하루 만에 모두가 알림을 무시한다. 운영이 망가질 때의 전형적인 시작이다.

그래서 인시던트 대응은 '알림 발생'보다 '심각도 선언'이 더 중요하다. 좋은 운영 플레이북은 장애 시작 시점에 현재 심각도, 영향 범위, 소유자, 다음 체크포인트를 먼저 적게 만든다.⁴

실무에서는 서비스 장애를 대략 이렇게 나누면 충분하다.

여기서 중요한 건 숫자보다 합의다. 팀이 '이 상태면 바로 롤백을 먼저 본다'는 공통 언어를 가져야 한다. 심각도는 보고서 장식이 아니라 행동 스위치다.⁴

예를 들어 슈퍼앱 클론에서 결제 콜백이 20% 누락되고 있다면, 그건 단순한 에러율 상승이 아니다. 매출, 정산, 고객 신뢰가 동시에 흔들리므로 SEV-1에 가깝다. 반대로 관리자 통계 페이지가 느려진 것은 짜증나지만, 핵심 거래가 정상이라면 SEV-2나 SEV-3로 볼 수 있다. 운영이 안정되는 순간은 모두가 똑같이 화내는 순간이 아니라, 모두가 똑같이 분류하는 순간이다.

장애가 터졌을 때 첫 15분은 원인 찾기보다 안정화가 먼저다

장애가 났을 때 사람은 본능적으로 범인을 찾으려 든다. 하지만 운영에서는 범인보다 출혈부터 멈춰야 한다. 관측 우선 인시던트 플레이북도 같은 점을 강조한다. 먼저 영향 범위와 최근 변경 사항을 파악하고, 깊은 원인 분석보다 시스템 안정화를 우선해야 한다는 것이다.²

첫 15분은 보통 이렇게 흘러가면 좋다.

1. 심각도와 인시던트 오너를 선언한다.

2. 영향 받는 시스템과 사용자 범위를 적는다.

3. 직전 배포, 설정 변경, 기능 플래그, 외부 의존성 이상 여부를 확인한다.

4. 롤백, 플래그 비활성화, 트래픽 제한, 임시 스케일업 같은 가역적 대응책을 먼저 검토한다.

5. 그 다음에야 깊은 원인 분석으로 들어간다.

여기서 Codex는 꽤 유용하다. Datadog 같은 관측 도구와 GitHub 정보를 함께 읽게 하면, 최근 30분 로그, APM 트레이스, 최근 배포 이벤트를 연결해 가설을 빠르게 세울 수 있다.³

예를 들어 Next.js + Supabase 예약 서비스에서 14시 23분부터 로그인 후 대시보드 진입이 무한 리다이렉트에 빠졌다고 해보자. Codex가 로그를 읽어 보니 set-cookie 이후 첫 서버 요청에서 세션 검증이 실패하고, APM에서는 미들웨어 레벨에서 302 체인이 급증했다. GitHub 배포 기록을 보니 14시 18분 배포가 있었다. 그러면 사람은 훨씬 빨리 질문을 좁힐 수 있다. '방금 배포한 인증 미들웨어 변경이 원인인가?'라고.

새벽 장애 대응에서 가장 무서운 문장은 '일단 이것저것 해보죠'다. Codex가 잘하는 것은 바로 이 '이것저것'을 줄여 주는 일이다.

운영용 Codex 프로필은 읽기 중심으로 시작해야 한다

운영에서 제일 위험한 실수는, 도구가 똑똑해 보여서 권한까지 넓게 주는 것이다. 실제 운영 사례에서도 안전한 패턴은 비슷하다. 초반 조사는 읽기 위주로 두고, 쓰기나 변경은 사람 승인 뒤로 미루는 것이다.³

운영 프로필은 대략 이런 성격이면 좋다.

[profiles.incident-investigate]
approval_policy = 'always'

[profiles.incident-investigate.mcp]
allowed_servers = ['datadog', 'github']

핵심은 복잡하지 않다. 처음에는 Codex가 로그, 메트릭, 트레이스, 배포 이력만 읽게 한다. 그리고 결과는 꼭 정해진 형식으로 내보내게 만든다. 예를 들면 다음 네 칸이다.

• 타임라인

• 가장 유력한 원인 가설

• 가설을 지지하는 증거

• 추천 조치와 남은 리스크

이 형식이 좋은 이유는, 사람끼리 인계할 때도 그대로 쓸 수 있기 때문이다. 장애 대응은 개인전 같아 보여도 사실 핸드오프 게임이다. 채팅창 깊숙한 곳에 맥락이 가라앉기 시작하면 복구 시간은 순식간에 길어진다.

핫픽스는 빠르게 적용하는 것보다, 빠르게 되돌릴 수 있어야 한다

운영에서 진짜 무서운 것은 느린 수정이 아니라 되돌릴 수 없는 수정이다. 그래서 좋은 인시던트 플레이북은 늘 '가역적 선택 사다리'를 먼저 권한다. 위험 경로를 플래그로 끄기, 범위 제한된 패치 적용, 마지막으로 전체 롤백 순서다.⁴

이 순서가 왜 중요할까. 이유는 단순하다. 장애 순간의 판단은 대개 정보가 부족한 상태에서 이뤄지기 때문이다. 정보가 부족할수록 더 되돌리기 쉬운 선택을 해야 한다.

Express + MongoDB 기반 백오피스 API를 예로 들어보자. 갑자기 CPU가 치솟고 GET /admin/orders가 12초씩 걸린다. Codex가 최근 로그와 쿼리 패턴을 읽고 N+1 조회 가능성을 짚어 준다. 이때 최고의 첫 대응은 대규모 리팩터링이 아니다. 관리자 통계의 일부 필드를 임시로 숨기거나, 특정 확장 조회 옵션을 플래그로 끄거나, 안전한 인덱스 추가 초안을 만드는 것이다.

즉, 자동 핫픽스의 목표는 '지금 바로 머지'가 아니라 '지금 바로 검토 가능한 초안'이다. 좋은 운영 팀은 Codex에게 이렇게 시킨다.

원인 가설을 바탕으로 최소 범위 패치를 diff로 제안해줘. 직접 적용하지 말고, 롤백 방법과 검증 명령까지 함께 적어줘.

이 요청에는 운영의 철학이 담겨 있다. 패치는 빨라도 되고, 검증은 반드시 있어야 한다.

병렬 대응은 네 개의 레인으로 나누면 덜 무너진다

장애가 커질수록 채팅방은 바빠지고, 바쁠수록 서로 같은 파일을 건드리거나 같은 사실을 두 번 확인하게 된다. 그래서 큰 장애는 처음부터 레인을 나누는 편이 좋다.⁴

가장 실전적인 구조는 네 레인이다.

• 트리아지 레인: 심각도, 영향 범위, 유력 원인 분류

• 완화 레인: 롤백, 플래그 오프, 임시 제한 같은 안정화 조치 준비

• 검증 레인: 재현, 재실행, 회복 여부 검증

• 커뮤니케이션 레인: 내부 공지, 고객 안내, 다음 업데이트 시각 관리

Codex는 이 중 앞의 세 레인에서 특히 빛난다. 트리아지 레인에서는 로그와 배포를 묶어 읽고, 완화 레인에서는 diff나 롤백 후보를 정리하고, 검증 레인에서는 헬스 체크와 재현 명령을 문서화할 수 있다. 반면 커뮤니케이션 레인은 사람이 최종 문장을 잡는 편이 낫다. 특히 한국 서비스는 공지 문구 톤 하나로도 고객 체감이 달라진다.

재미있는 점은, 운영이 성숙할수록 개발 실력보다 작문 실력이 중요해진다는 것이다. '현재 무엇을 알고 무엇을 아직 모르는지'를 짧고 정확하게 적는 능력이 복구 속도를 바꾼다.

보안 인시던트는 일반 장애와 같은 방식으로 자동화하면 안 된다

여기서 하나 선을 분명히 그어야 한다. 서비스 장애와 보안 인시던트는 비슷해 보여도 성격이 다르다.

일반 운영 장애에서는 Codex가 로그와 트레이스를 읽고 패치 초안을 만드는 역할이 꽤 잘 맞는다. 하지만 활성 보안 사고에서는 훨씬 더 조심해야 한다. 보안 인시던트는 거짓 양성 필터링, 심각도 재선언, 증거 보존, 규제 대응 시계 시작처럼, 코드 수정보다 증거성과 절차가 먼저이기 때문이다.⁵

특히 다음 상황은 강한 경계 신호다.

• 계정 탈취가 의심된다

• 데이터 유출 가능성이 있다

• 관리자 권한 오남용이 보인다

• 감사 로그나 보안 로깅이 비활성화됐다

• 두 개 이상의 시스템이 연쇄적으로 의심된다

이때는 Codex를 완전 자동 복구 도구로 쓰기보다, 읽기 전용 조사 보조로 두는 편이 낫다. 무엇보다 증거는 휘발된다. 라이브 메모리, 실행 중 프로세스, 활성 세션, 현재 시간 정보는 재부팅이나 성급한 조치로 금방 사라질 수 있다.⁵

쉽게 말해, 서비스 장애에서는 '빨리 고쳐라'가 중심일 때가 많지만, 보안 사고에서는 '무엇이 있었는지 훼손 없이 남겨라'가 먼저다. 이 순서를 거꾸로 잡으면 기술적으로는 복구했어도 법적으로는 더 큰 문제를 만들 수 있다.

Aardvark 계열 보안 스캔은 운영의 야간 경비원에 가깝다

운영 단계에서 보안은 특별 행사처럼 하면 늦다. 배포 전 한 번 보고 끝내는 것이 아니라, 살아 있는 코드베이스를 계속 훑어야 한다. 이 지점에서 Codex Security가 의미가 있다. 이 도구는 저장소 맥락을 바탕으로 스캔 컨텍스트를 만들고, 가능성 높은 취약점을 코드베이스 맥락에 비춰 본 뒤, 신호가 강한 항목은 격리된 환경에서 검증해 표면으로 올린다.⁶

이 접근이 좋은 이유는 기존 정적 분석 도구의 오래된 문제를 줄여 주기 때문이다. 운영팀이 가장 싫어하는 것은 취약점 그 자체보다 '또 오탐이겠지'라는 피로감이다. 검증 없는 경고는 운영 백로그를 쓰레기통처럼 만든다. 반대로 실제 맥락과 격리 검증을 거친 결과는 훨씬 다루기 쉽다.⁶

다만 여기에도 운영 팁이 있다. 첫 스캔이 끝나면 생성된 위협 모델을 반드시 검토하고, 우리 아키텍처와 신뢰 경계, 비즈니스 맥락에 맞게 업데이트해야 한다는 점이다.⁷ 예를 들어 한국형 슈퍼앱 클론이라면 단순한 CRUD 앱과 보는 포인트가 다르다.

• 소셜 로그인과 토큰 재발급 흐름

• 파일 업로드와 이미지 프록시 경로

• 관리자 대리 로그인 기능

• 결제 콜백과 정산 배치

이런 지점이 위협 모델에 정확히 반영돼야 스캔 결과도 현실과 가까워진다. 보안 스캔은 많이 도는 것보다, 팀의 서비스 구조를 제대로 반영하는 것이 더 중요하다.

보안 스캔 결과는 운영 백로그와 연결돼야 한다

보안 스캔이 실패하는 가장 흔한 이유는 결과가 따로 논다는 점이다. 경고는 나왔는데 누가 볼지 모르고, 심각도는 적혀 있는데 언제 처리할지 모른다. 그러면 결국 언젠가 큰 사고가 난 뒤에야 다시 꺼내 본다.

운영 단계에서는 보안 결과도 일반 운영 흐름에 태워야 한다. 예를 들어 이렇게 정리하면 좋다.

예를 들어 Next.js + Supabase 서비스에서 관리자 전용 CSV 내보내기 경로에 권한 우회 가능성이 발견됐다고 해보자. 이건 '언젠가 고치자'가 아니다. 실제 데이터 노출 가능성이 있으므로 운영 이슈가 아니라 보안 인시던트 후보가 된다. 반대로 오래된 Express 관리자 화면에서 저장형 XSS 가능성이 발견됐지만 접근이 내부망으로 제한되고 방어 레이어가 있다면, 우선순위는 높더라도 처리 방식은 다를 수 있다.

즉, 보안 스캔의 목적은 경고 수집이 아니라 운영 우선순위 재정렬이다.

새벽 3시 온콜에서 Codex를 어떻게 쓸까

실전 감각으로 한 번 그려 보자. 새벽 3시, 예약 SaaS에서 알림이 울린다. 에러율 35%, 로그인 실패 급증, 고객 채널에 '예약이 안 된다'는 메시지가 올라온다.

이때 가장 현실적인 흐름은 이렇다.

먼저 Codex에게 최근 30분 로그, APM 트레이스, 최근 배포, 기능 플래그 변경 이력을 읽게 한다. 동시에 사람은 심각도 선언과 공지 채널 정리를 한다. Codex가 14분 전 배포, 미들웨어에서 302 루프, 세션 쿠키 파싱 오류, 로그인 후 예약 API 연쇄 실패를 한 번에 묶어 주면, 사람은 빠르게 롤백과 핫픽스 중 무엇이 더 가역적인지 고를 수 있다.²³⁴

그다음 Codex는 두 가지 산출물을 만들면 된다.

• 원인 가설과 증거 요약

• 롤백안과 최소 패치안 두 가지 초안

여기서 중요한 점은 둘 다 동시에 준비한다는 것이다. 운영에서는 자존심보다 선택지가 중요하다. 패치가 맞아 보여도 검증이 길어지면 롤백이 이긴다. 좋은 온콜은 늘 가장 똑똑한 선택이 아니라, 가장 덜 위험한 선택을 한다.

포스트모템까지 가야 장애가 끝난다

많은 팀이 서비스가 살아나면 장애가 끝났다고 생각한다. 하지만 진짜로는 그때부터 절반이다. 좋은 플레이북은 장애 종료 조건을 분명히 둔다. 완화 조치가 적용됐고, 신선한 재실행 증거가 있고, 남은 리스크가 문서화돼 있고, 후속 작업의 담당자와 기한이 정해져 있어야 한다.⁴

이 단계에서도 Codex는 유용하다. 조사 로그와 타임라인을 읽고 포스트모템 초안을 만드는 데 잘 맞기 때문이다.³ 다만 결론은 사람이 써야 한다. 특히 다음 질문은 사람이 직접 답하는 편이 좋다.

• 처음 신호를 왜 늦게 알아챘는가

• 어떤 의사결정 지점이 가장 오래 걸렸는가

• 누구의 소유권이 애매했는가

• 다음에는 어떤 자동화 하나가 시간을 가장 많이 줄일까

• 어떤 회귀 테스트를 추가해야 같은 종류의 사고를 막을 수 있을까

좋은 포스트모템은 죄인을 찾는 문서가 아니다. 다음 새벽 3시를 덜 괴롭게 만드는 문서다.

운영에서 사람이 끝까지 쥐어야 하는 것

운영에 Codex를 깊게 붙일수록, 오히려 사람이 끝까지 쥐어야 할 것도 더 또렷해진다.

이 표를 보면 약간 심심해 보일 수도 있다. 하지만 바로 이 심심한 경계가 운영을 안전하게 만든다. Codex가 운영의 많은 시간을 줄여 주는 것은 사실이다. 그렇다고 마지막 스위치까지 모두 넘기면, 생산성은 잠깐 오를지 몰라도 신뢰는 오래 못 간다.

운영 장의 핵심 문장

이 장을 한 문장으로 요약하면 이렇다.

Codex는 운영에서 문제를 혼자 해결하는 영웅이 아니라, 사람이 더 빨리 올바른 결정을 내리게 만드는 관제사다.

모니터링에서는 신호를 읽고, 인시던트에서는 맥락을 모으고, 핫픽스에서는 초안을 만들고, 보안에서는 취약점을 검증하고, 포스트모템에서는 기억이 사라지기 전에 구조를 남긴다. 이 역할만 제대로 해도 운영의 체감 난이도는 눈에 띄게 내려간다.

출시는 박수받는 순간이지만, 운영은 오래 버티는 기술이다. 그리고 오래 버티는 팀은 늘 비슷하다. 장애를 덜 겁내고, 알림을 덜 무시하고, 실수를 더 빨리 문서화한다. Codex를 운영 단계까지 확장한다는 것은 결국, 서비스를 고치는 속도보다 서비스에서 배우는 속도를 높이는 일이다.

참고

¹Automate bug triage

²incident-observability SKILL.md

³Codex CLI Incident Response: Automating On-Call with Agents

⁴Codex Incident Recovery Playbook

⁵Incident Response — Agent Skill & Codex Plugin

⁶Security - Codex | OpenAI Developers

⁷Setup - Codex Security | OpenAI Developers