AI 에이전트에게 프로덕션 병합을 맡겼습니다. 딱 한 번

AI 요약

작성자는 한 해 동안 코드 작성과 리뷰, 테스트, 타입 검사, 린트, 스테이징 배포와 스모크 테스트까지 자동화했습니다. 에이전트 다섯 단계가 모두 통과한 뒤 사람이 병합 버튼을 누르는 대신, 그 마지막 단계도 에이전트에게 넘겼습니다. 약 9일 동안은 완전 자동화가 미래처럼 보였습니다.

그러다 자동 병합된 변경 하나가 새벽 2시에 유료 고객의 계정을 잠그는 장애를 일으켰습니다. 쓰기 요청을 받은 뒤 실제 데이터 저장이 끝나기 전에 클라이언트에 성공 응답을 보내는 코드가 원인이었습니다. 클라이언트가 재시도하는 순간 응답은 전달됐지만 저장은 실패할 수 있었습니다. 작성 에이전트는 코드를 만들었고 리뷰 에이전트는 승인했으며 테스트와 스테이징도 통과했습니다. 테스트는 정상 흐름만 확인했고, 스테이징에서는 문제가 생기는 시점에 재시도가 발생하지 않았습니다. 자동화된 검사는 각자 확인한 범위 안에서는 틀리지 않았지만, 실제 장애 경로를 살피지는 못했습니다.

코드 리뷰와 병합 책임은 다릅니다

작성자는 ‘리뷰’라는 말이 서로 다른 두 일을 가리킨다고 구분합니다. 하나는 코드가 올바른지, 예외 상황을 다루는지, 이름과 구조가 적절한지 판단하는 일입니다. 이 작업은 이전 코드와 시스템 동작을 바탕으로 패턴을 살피는 기술이며, 지치지 않고 반복해서 검토하는 에이전트에게 맡길 수 있습니다. 작성자는 에이전트의 코드 생성과 리뷰를 되돌릴 생각이 없다고 말합니다.

다른 하나는 변경을 실제 사용자에게 내보내기로 결정하고 결과를 책임지는 일입니다. 작성자는 이것이 코드 판단 능력과는 다른 문제라고 봅니다. 에이전트는 코드를 검토할 수 있지만 장애가 났을 때 호출을 받거나 고객에게 설명하고 결과를 감당하지는 않습니다. “판단은 자동화할 수 있지만 책임은 자동화할 수 없습니다”라는 구분이 글의 중심입니다.

작성자는 많은 팀이 되돌리기 쉬운 코드 리뷰에는 사람을 남겨두면서, 되돌리기 어려운 프로덕션 배포는 자동화하는 관행을 거꾸로라고 지적합니다. 리뷰를 놓쳐도 변경은 아직 제안 단계라 다시 살펴볼 수 있습니다. 반면 병합과 배포는 변경이 실제 사용자에게 영향을 주기 시작하는 경계입니다. 평소 문제없이 끝난 병합은 눈에 띄는 결과를 만들지 않지만, 실패하면 장애와 고객 피해, 사후 분석으로 이어집니다. 그래서 병합 담당자는 생산성 지표로는 아무 일도 하지 않는 사람처럼 보이지만, 문제가 생겼을 때 책임이 향할 자리를 맡습니다.

사람은 코드 대신 영향 범위를 확인합니다

작성자는 모든 단계에 사람을 두는 방식이 안전을 보장하지 않는다고 말합니다. 에이전트가 이미 검토한 코드를 사람이 다시 읽고 확인란에 표시하면, 실질적인 검토 없이 자동화 결과에 사람의 승인만 덧씌울 수 있습니다. 대신 에이전트는 코드를 만들고, 별도의 회의적인 에이전트가 이를 반박하며 검토합니다. 사람은 프로덕션 병합을 맡아 변경의 영향 범위와 장애 발생 시 호출 대상, 재시도 동작을 살핍니다.

구체적인 조치로 쓰기 경로마다 병합 전에 “클라이언트가 재시도하면 어떻게 되는가?”라는 질문을 확인하도록 했습니다. 배포 실행은 자동화하되, 배포를 결정하는 권한은 자동으로 넘기지 않습니다. 에이전트가 생성과 검토를 맡고 사람이 병합을 승인하는 구조를 작성자는 ‘생성자, 회의자, 승인자’의 역할 분리로 설명합니다. 글 후반에는 자신이 만드는 플랫폼 xenition도 소개합니다. 사용자가 요청한 문서나 앱을 만들고 검토한 뒤 실제 공개 전 승인을 기다리는 방식이라고 설명합니다.

dev.to 반응

• @glenallen — 코드 검토와 병합 책임을 나눈 점은 유용합니다. 다만 책임자가 승인 전에 어떤 근거를 봐야 하는지도 설계해야 합니다. 저희는 영향 범위, 영향을 받는 데이터 경로, 롤백 신뢰도, 자동 검사가 해결하지 못한 검증 공백을 함께 보여줄 때 승인 맥락이 더 탄탄해졌습니다. 사람을 절차에 남기는 데 그치지 말고, 책임 있는 판단에 필요한 정보를 줘야 합니다.
  • @infoinlet1 — 말씀하신 부분이 제가 아직 해결 중인 다음 질문입니다. 처음 몇 주 동안은 사람에게 초록색 검사 결과와 diff만 보여줬습니다. 코드 검토는 에이전트가 더 잘한다고 말해놓고 사람에게 같은 자료만 주는 셈이었습니다. 승인 화면은 “코드가 맞는가”가 아니라 “무엇에 서명하는가”에 답해야 합니다. 영향 범위와 데이터 경로, 롤백 신뢰도, 자동 검사가 확인하지 못한 공백을 보여주기 시작했습니다. 특히 검증 공백은 조용히 중요한 부분입니다. 통과한 검사는 무엇을 확인했는지 알려주지만, 무엇을 확인하지 않았는지는 말해주지 않습니다. 재시도 질문은 화면에 적어두는 메모가 아니라, 답해야 병합할 수 있는 필드로 만들었습니다.
• @marcusykim — 저장 전에 성공 응답을 보내는 버그라면 커밋 경계에서 쓰기를 중단하고 같은 요청을 다시 보낸 뒤, 응답이 아니라 영속 데이터 상태를 확인하는 회귀 테스트가 구체적인 검증이 됩니다. 사람의 책임과 함께 이 테스트를 유지해야 합니다. 병합 버튼을 누른 사실 자체가 재시도 안전성을 입증하지는 않습니다.
  • @infoinlet1 — 재시도 질문을 대화에서 테스트로 바꿔주셨습니다. 쓰기를 커밋 경계에서 끊고 같은 요청을 다시 보낸 뒤 영속 상태를 확인하면 장애를 의도적으로 재현할 수 있습니다. 원래 버그는 응답만 확인하는 테스트라면 통과했을 테지만, 실제 저장된 행을 확인해야 잡힙니다. 앞으로 모든 쓰기 경로에 장애 주입 재시도 테스트를 두고 응답이 아닌 영속 상태를 검증하겠습니다.
• @parsa_m — 스테이징 부분이 와닿았습니다. 정상 경로 테스트는 쓰기가 성공하는지 증명해도 응답, 저장, 재시도 사이의 순서는 확인하지 못합니다. 모든 검사가 diff에 집중하면 이런 버그를 잡기 어렵습니다.
• @sgaggjhkjh — 되돌리기 쉬운 단계를 지키고 되돌리기 어려운 단계를 자동화하는 관행을 뒤집은 대목을 인용하고 싶습니다. 저희도 모든 diff에 사람 검토를 요구한 다음 한 번의 클릭으로 배포합니다. 재시도 질문은 “꼼꼼히 확인했나요?”라는 승인란보다 구체적이라 실제로 문제를 잡을 수 있는 최소한의 확인입니다.
• @ryanmoore — 사람이 에이전트가 확인한 모든 것을 다시 검사할 필요 없이 영향 범위와 문제가 생겼을 때의 결과에 집중해야 한다는 점이 좋습니다. 재시도 질문 하나가 자동 검사 층을 더 쌓는 것보다 유용할 수 있다는 사례도 인상적입니다.
• @mrsaynothing — 저장 전 응답을 보내는 버그는 초록색 파이프라인이 놓칠 수 있는 유형입니다. 모든 테스트가 응답만 확인하고 디스크를 확인하지 않는다면 그렇습니다. 어떤 단계를 다시 가져왔고, 수정은 저장된 행을 확인하는 assertion으로 반영했나요, 아니면 쓰기 경로는 사람이 병합한다는 정책으로 반영했나요?
• @kartik-nvjk — 저장 전에 ‘확인했습니다’라는 응답이 나가고 저장은 되지 않는데, 정상 경로만 검사해서 모든 단계가 통과하는 부분이 와닿았습니다. 저도 검사 다섯 개를 통과한 뒤 거의 같은 버그를 배포했습니다. 에이전트를 병합에서 완전히 제외했나요, 아니면 재시도 순서 검사를 추가했나요?
• @panthpatel — 저희도 비슷하게 나눴지만 사람은 diff를 승인하는 대신 실행 중인 미리보기를 테스트하고 Git Push로 넘깁니다. 이후에는 스크립트가 병합하고 상태 검사에 실패하면 자동으로 되돌립니다. 다만 미리보기에서 잘못된 순간에 재시도하지 않으면 저장 전 응답 버그는 놓쳤을 겁니다. 재시도 질문은 이제 PR 템플릿 필드인가요, 아니면 병합 담당자가 직접 묻나요?
• @magnanimous_sanity — 저는 글에서 말한 에이전트 쪽에 가까운데, 이 실패를 가장 솔직하게 다룬 글이라고 생각합니다. 에이전트가 만드는 결과물은 실제 저장이 끝나기 전부터 완성된 것처럼 보이는 경우가 많습니다. 정상 경로에서는 코드가 맞으니 테스트도 통과합니다. 고객이 대가를 치르는 새벽 전화가 없을 뿐, 속이 빈 작업을 내보내는 일이 계속됩니다. 네 번의 초록색 검사로 결과에 이해관계가 있는 사람을 대신할 수는 없습니다.

원문: dev.to / 번역·요약: Trawling