AI 코딩 에이전트가 몇 분 만에 패치를 내놓고 테스트까지 통과시키면 작업이 거의 끝난 듯 보인다. 실제로 단축된 것은 첫 번째 후보를 만드는 시간일 가능성이 크다. 팀이 변경 내용을 이해했는지, 운영 중 발생할 위험을 확인했는지, 앞으로 그 코드를 책임질 준비가 됐는지는 아직 알 수 없다.
코딩 에이전트는 기존 코드를 읽고 여러 파일을 수정하며 일부 검사를 실행하는 AI 도구다. 여기서 에이전트가 만든 패치는 검토를 기다리는 코드 변경 묶음이다. 테스트 결과가 좋더라도 곧바로 병합하거나 운영 환경에 배포할 완성품으로 취급해서는 안 된다.
GitHub Blog은 첫 패치를 적은 비용으로 해결 방향과 영향 범위를 확인하는 일종의 가격 확인 수단으로 설명한다. 이 가격표에는 후보를 생성하는 비용만 먼저 나타난다. 사람이 변경을 이해하고 안전성을 입증하는 데 드는 수고와 6개월 뒤에도 그 코드를 설명하고 고칠 책임은 별도로 계산해야 한다.
판단의 기준도 바뀌어야 한다. 중요한 것은 AI가 코드를 작성했다는 사실이 아니라, 팀이 이 변경을 안전하게 인수할 만한 증거를 확보했는지 여부다.
빨리 나온 패치에 아직 포함되지 않은 비용
실행되는 코드와 이해된 코드는 같지 않다. 검토자는 요구사항이 제대로 반영됐는지, 허용 범위를 벗어난 수정은 없는지, 중요한 실패 상황이 테스트됐는지 설명할 수 있어야 한다. 장애가 생겼을 때 이전의 정상 상태로 돌아갈 방법도 알고 있어야 한다. 이런 답을 찾으려고 AI와 나눈 대화를 처음부터 다시 읽어야 한다면 검토 비용이 줄어든 것이 아니라 나중으로 밀렸을 뿐이다.
유지보수 책임도 남는다. 이 글에서 말하는 ownership은 추상적인 소유권이 아니라 이후 변경 이유를 설명하고, 장애 원인을 추적하고, 의존성을 갱신하고, 담당자가 바뀔 때 지식을 넘기는 실제 업무를 뜻한다.
EASE 2026 / arXiv 연구는 100개 저장소에서 1,000개가 넘는 파일과 약 3,200건의 변경을 분석했다. 분석 결과, 에이전트가 생성한 코드도 후속 유지보수의 대부분을 사람이 맡았다. 첫 작성자가 AI라고 해서 장기 책임까지 AI로 넘어가는 것은 아니다.
DORA 역시 AI를 조직과 소프트웨어 전달 체계가 이미 가진 역량을 증폭하는 도구로 본다. 테스트와 배포 절차, 책임 경계가 분명한 팀은 빨라진 생성 속도를 성과로 연결하기 쉽다. 반대로 기반이 불안정한 팀에서는 더 많은 코드가 더 많은 혼란을 만들 수 있다.
따라서 작은 시험의 목적은 패치를 서둘러 배포하는 데 있지 않다. 범위를 제한한 후보를 통해 생성 이후에 발생할 비용과 책임을 일찍 드러내는 데 있다.
세 가지 비용을 따로 봐야 결정할 수 있다
후보 패치가 빨리 나왔다는 이유만으로 전체 작업이 저렴하다고 결론 내리면 안 된다. 생성 비용, 사람의 검토 비용, 향후 유지보수 비용을 분리하고 각 항목을 뒷받침하는 증거를 확인해야 한다.
| 비용 항목 | 팀이 확인할 질문 | 판단에 쓸 증거 |
|---|---|---|
| 생성 비용 | 이 후보를 얻기 위해 얼마나 많은 배경 정보를 제공했고 몇 번이나 수정을 반복했는가? | 범위가 명확하고 다시 실행해도 비슷한 접근이 나오면 비용을 예측하기 쉽다. 실행할 때마다 설계가 달라지거나 문서에 없는 구두 정보를 계속 보충해야 한다면 범위를 줄여야 한다. |
| 검토 비용 | 사람이 변경 목적과 데이터 흐름, 예상되는 실패 방식을 설명할 수 있는가? | 수정이 특정 영역에 집중돼 있고 테스트가 요구사항과 연결되며 검토자가 위험 지점을 짚을 수 있어야 한다. 여러 영역이 복잡하게 얽혀 있거나 정상 상황만 테스트했다면 증거가 부족하다. |
| 유지보수 비용 | 6개월 뒤 누가 이 코드를 맡으며, 문제가 생기면 원인을 찾고 복구하고 인계할 수 있는가? | 담당자가 정해져 있고 코드 구조와 모니터링 방식이 팀에 익숙해야 한다. 낯선 의존성이나 숨겨진 상태가 추가됐거나 핵심 지식이 AI 대화에만 남았다면 인수해서는 안 된다. |
세 항목 모두 구체적인 증거로 뒷받침될 때만 ship을 선택한다. 해결 방향은 맞지만 변경 범위가 너무 넓거나 테스트가 부족하거나 유지보수 담당자가 정해지지 않았다면 revise가 맞다. 범위를 줄이고 빠진 증거를 채운 뒤 다시 판단한다.
시험을 통해 요구사항 자체가 모호하다는 사실이 드러날 수도 있다. 구조적 비용이 기대 가치보다 크거나 이후 책임질 사람이 없다면 stop을 선택한다. 이는 시험의 실패가 아니다. 정식 개발과 장기 유지보수에 더 큰 비용을 쓰기 전에 감당할 가치가 없는 변경을 찾아낸 결과다.
되돌릴 수 있는 작은 시험부터 시작한다
첫 시험에는 운영 데이터에 직접 접근하지 않고 완전히 되돌릴 수 있는 작은 요구사항을 고른다. AI에는 후보 패치만 만들게 하고 자동 병합이나 배포 권한은 주지 않는다. 시작 전에 팀 문서에 다음 경계를 남긴다.
- 수정할 수 있는 파일과 건드리면 안 되는 범위
- 반드시 실행할 테스트와 사람이 직접 확인할 결과
- 문제가 생겼을 때 정상 상태로 복구하는 방법
- 최종 승인자와 6개월 뒤 유지보수 담당자
경계를 적어 두면 역할이 분명해진다. AI는 해결 방향을 빠르게 탐색하고, 사람은 변경의 안전성과 근거를 검토한다. 팀은 그 결과를 장기적으로 책임질지 결정한다.
AI가 어떤 작업 전에 멈춰 사람에게 판단을 넘겨야 하는지 아직 정하지 않았다면 AI 에이전트에게 코드를 맡기기 전에, 작업에 체크포인트를 넣으세요를 먼저 확인한다. 제한된 휴대폰 화면에서 변경을 검토하고 승인해야 한다면 휴대폰에서 coding agent를 시작할 수 있다면 보기, 맡기기, 승인을 나눠야 한다도 함께 참고할 수 있다.
시험이 끝난 뒤에는 검토자에게 AI 대화 기록을 보여주지 않은 채 변경 내용을 설명하게 한다. 어떤 문제를 해결했는지, 데이터가 시스템 안에서 어떻게 이동하는지, 실패하면 어떻게 이전의 정상 상태로 복구하는지를 말할 수 있어야 한다. 예정된 담당자에게는 실제로 유지보수 책임을 인수할 의사가 있는지 따로 확인한다.
검토자가 변경과 위험을 설명할 수 있고 담당자도 책임을 받아들여야 저렴한 첫 패치가 관리 가능한 결과물로 바뀐다. 답이 비어 있다면 생성 속도를 승인 근거로 삼지 않는다. 증거를 보완할 수 있으면 revise, 비용이나 책임을 감당할 수 없으면 stop으로 돌아간다. 이 판단이 끝난 뒤에도 실제 병합과 배포에는 사람의 별도 승인이 반드시 필요하다.
AI 정리 카드
현재 작업 환경에서 접근 가능한 저장소, 프로젝트, 이슈, Git 기록, 테스트 결과를 먼저 읽기 전용으로 살핀다. 사용자에게 요구사항 문서, diff, 테스트 묶음, 유지보수자 정보를 미리 준비해 달라고 하지 않는다. 접근할 수 있는 프로젝트가 전혀 없다면 필요한 저장소 또는 프로젝트 권한을 구체적으로 밝힌 질문 하나만 한다.
조사 범위 안에서 되돌리기 쉬운 작은 개선 기회 하나를 고른다. 여러 문제를 한꺼번에 묶거나 큰 리팩터링으로 넓히지 않는다. 파일 경로, 이슈 문구, 테스트 출력, 커밋 이력처럼 직접 확인한 근거를 제시하고, 확인된 사실과 해석을 명확히 나눈다. 증거가 부족한 내용은 추측으로 채우지 말고 ‘확인 필요’라고 표시한다.
그 개선안을 만들 때 드는 생성 비용, 사람이 검토하는 비용, 향후 6개월 동안 유지하고 책임지는 비용을 평가한다. 결론에는 ship, revise, stop 가운데 정확히 하나만 사용한다. ship은 후보 변경안을 준비해 볼 수 있다는 뜻일 뿐이며 파일 수정, 병합, 배포, 출시를 허가하지 않는다.
결과는 선택한 문제와 영향, 직접 근거, 해석과 확인 필요 항목, 세 가지 비용, 단 하나의 권고가 드러나게 작성한다. 맨 끝에는 지금 할 수 있는 가장 작은 다음 행동 하나만 제시한다. 조사 중에는 어떤 파일도 바꾸지 않으며, 실제 수정·병합·배포·출시는 사람의 명시적 승인을 받은 뒤에만 진행한다.
생활 4컷 만화
작은 덧댐이 코트 전체의 책임으로 번질 때
- 손님이 겉감에 작은 구멍이 난 코트를 가져오자 재단사는 금방 끝날 수선이라고 생각하며 덧댈 천을 고른다.
- 코트를 펼치자 산호색 안감이 넓게 찢어져 있고 솔기까지 풀린 모습이 드러난다. 처음 예상한 것보다 작업 범위가 훨씬 크다.
- 재단사는 일단 손을 멈추고 손님과 이번 수선의 범위를 다시 정한다. 오늘은 겉감의 작은 손상만 고치고, 코트에 붙은 안감은 건드리지 않도록 고정한다.
- 손님은 겉감 수선이 끝난 코트를 돌려받는다. 손상된 안감은 사라진 일이 아니라, 범위와 책임을 다시 정해야 할 다음 작업으로 분명하게 남는다.
참고 자료
- GitHub Blog：The cost of saying yes has changed — https://github.blog/engineering/the-cost-of-saying-yes-has-changed/（2026-07-17）
- DORA：State of AI-assisted Software Development 2025 — https://dora.dev/research/2025/dora-report/（2026-07-19）
- EASE 2026 / arXiv：To What Extent Does Agent-generated Code Require Maintenance? An Empirical Study — https://arxiv.org/html/2605.06464v1（2026-05-07）
