수요일 오후, 제품 관리자가 작은 요청을 했다. 보고서를 내보낼 때 항목을 하나 더 넣어 달라는 것이다. 엔지니어는 이를 coding agent, 즉 스스로 코드를 읽고 고칠 수 있는 AI 도구에게 넘겼고, 10분 뒤 변경 하나를 받았다. 파일 다섯 개가 바뀌었고 테스트는 모두 통과했다. 일은 끝난 것처럼 보인다.
하지만 이 시점에 팀은 아직 몇 가지를 모른다. 왜 파일 다섯 개를 모두 고쳐야 했는가. 내일 내보내기가 고장 나면 어디서부터 찾아봐야 하는가. 반년 뒤 이 코드를 고쳐야 할 때 누가 작동 방식을 기억하고 있을까.
GitHub은 2026년 7월 엔지니어링 블로그 글에서 AI가 내놓은 변경의 첫 버전을 “가격 확인"에 빗댔다. 싸게 얻을 수 있고, 가능한 해법과 그 범위를 아주 적은 비용으로 보여 준다. 하지만 싸진 것은 “쓰는” 부분뿐이다. 검토하고 유지보수하는 비용은 AI 때문에 줄지 않았다. 그래서 첫 버전을 완성품으로 다뤄서는 안 된다. 그 용도는 이 변경을 받아들이려면 얼마를 치러야 하는지 팀에게 보여 주는 것이다.
쓰는 일은 싸졌지만 나머지 두 청구서는 그대로다
코드 변경 한 번의 총비용은 대략 세 장의 청구서로 나눌 수 있다.
만드는 비용: 이 버전을 얻기까지 시간과 배경 설명을 얼마나 들였는가. 이것은 AI가 확실히 크게 줄였다.
검토하는 비용: 변경이 맞다고 확신하기까지 사람이 얼마나 힘을 들여야 하는가. GitHub의 글은 분명하게 말한다. 사람이 자신 있게 검증할 수 있을 때에만 변경이 싸다고 할 수 있고, 검토할 수 없는 변경은 비용을 뒤로 미룬 것에 불과하다.
유지보수하는 비용: 반년 뒤 이 코드의 동작에 책임질 사람이 있는가. 글쓴이가 쓰는 확인 질문은 6개월 뒤에도 이 동작을 떠맡을 수 있겠느냐는 것이다.
뒤의 두 청구서는 누가 낼까. 2026년 5월 공개되어 소프트웨어 공학 국제 학회 EASE 2026에 채택된 연구는 인기 있는 오픈소스 저장소 100곳에서 AI가 만든 파일 1,000여 개와 이후 변경 약 3,200건을 분석했다. 그 결과, AI가 쓴 코드의 이후 유지보수는 대부분 사람 개발자가 맡고 있었다. AI는 코드를 건네고 떠나고, 남는 것은 팀이다.
첫 버전으로 세 가지를 확인한다
첫 버전이 가격 확인이라면, 받은 뒤 해야 할 일은 그것으로 세 가지를 확인하는 것이다.
변경이 범위를 넘지 않았는가. “항목 하나 추가” 요청에 파일 다섯 개가 바뀌었다. 그게 타당한가, 아니면 AI가 하는 김에 다른 일을 했는가. GitHub 글이 살펴보라고 권하는 신호에는 변경이 여러 모듈로 퍼지는지, 테스트하기 어려운지, 새로운 제품 결정이 필요한지가 있다. 모두 그 변경이 보기보다 비싸다는 뜻이다.
검토하는 사람이 스스로 설명할 수 있는가. 검토자에게 AI와의 대화 기록은 잠시 치워 두고, 이 변경이 무엇을 해결하는지, 데이터가 어떻게 흐르는지, 실패하면 이전 버전으로 어떻게 되돌리는지 직접 설명해 달라고 한다. 설명할 수 있다면 검토 비용은 실제로 치른 것이다. 설명하지 못한다면 핵심 지식은 대화 기록 속에만 있다.
맡겠다는 사람이 있는가. 이 코드를 책임질 사람을 정하고 분명히 묻는다. 반년 뒤 여기서 문제가 생기면 당신이 처리하겠습니까. 이 질문은 테스트 통과 여부보다 답하기 어렵고, 더 중요하다.
세 가지 모두 답이 나오면 변경을 병합해도 된다. 방향은 맞지만 범위가 너무 크거나 테스트가 부족하다면 AI에게 범위를 줄여 다시 하게 한다. 가격 확인 결과 요구사항 자체가 아직 분명하지 않거나 아무도 맡으려 하지 않는다면 멈춘다. 멈춘다고 시도가 헛된 것은 아니다. 본격적인 개발에 투자하기 전에 이 청구서가 수지가 맞지 않는다는 것을 보게 해 주는 것, 그것이 첫 버전의 가치다.
작은 수정에는 이 절차가 필요 없다
이 점검은 작은 변경을 느리게 만든다. 한 줄짜리 문구 수정이나 버전 번호 갱신에 누가 유지보수할지까지 하나하나 확인하는 것은 분명 지나치다. 이렇게 점검할 가치가 있는 것은 데이터 흐름을 바꾸는 변경, 의존 패키지를 늘리는 변경, 과금, 개인정보, 권한에 닿는 변경이다. GitHub 글도 지원 부담, 개인정보, 과금, 규제와 관련된 변경은 코드가 아무리 짧아도 여전히 비싸다고 짚는다.
팀 자체의 기반도 이 점검이 쓸모 있을지를 좌우한다. 소프트웨어 배포 성과를 오래 연구해 온 DORA는 2025년 보고서에서 AI의 주된 역할이 증폭기이며, 조직이 원래 가진 강점과 약점을 키운다고 말한다. 테스트, 배포 흐름, 책임 분담이 원래 분명한 팀일수록 AI의 속도를 성과로 바꾸기 쉽다. 그 기반이 약한 곳에서는 늘어난 산출물이 혼란을 더 빨리 퍼뜨릴 뿐이다.
다음에 AI가 첫 버전을 내놓으면 병합하기 전에 두 가지를 물어보자. 검토하는 사람이 대화 기록 없이 설명할 수 있는가. 반년 뒤를 맡겠다는 사람이 있는가. 둘 다 “그렇다"면 병합한다. AI가 코드를 쓸 때 어디서 멈춰야 할지 아직 정하지 않았다면 이 issue를 coding agent에 맡길 수 있는지는 첫 번째 diff를 적을 수 있느냐에 달렸다를 참고하자. 검토가 휴대폰처럼 정보가 제한된 화면에서 이뤄진다면 AI가 고친 코드를 휴대폰으로 병합하기 전에, 저장소 규칙에 관문을 맡긴다도 참고할 만하다.
AI 정리 카드
AI가 코드 변경 묶음을 내놓았고, 병합하기 전에 받아들일 가치가 있는지 판단하고 싶다.
판단 방법은 이 글에서 가져왔다: https://boosterminiclass.com/ko/posts/ai-code-change-ownership-price-check/
글의 관점은 이렇다. AI 덕분에 첫 버전을 쓰는 일은 싸졌지만 검토와 유지보수 비용은 줄지 않았다. 첫 버전은 가격 확인이며, 병합 전에 세 가지를 확인한다. 변경이 범위를 넘지 않았는지, 검토하는 사람이 AI와의 대화 기록 없이 설명할 수 있는지, 반년 뒤 유지보수를 맡겠다는 사람이 있는지.
먼저 나에게 질문 3개를 해 달라:
1. 원래 요구사항은 무엇이고, AI는 어떤 파일을 바꾸고 어떤 의존 패키지를 추가했는가;
2. 검토하는 사람은 이 변경이 무엇을 해결하고, 데이터가 어떻게 흐르며, 실패하면 어떻게 되돌리는지 설명할 수 있는가;
3. 이 코드의 유지보수 담당자가 정해져 있는가, 그 사람은 맡는 데 동의했는가.
내 답을 바탕으로 다음을 출력해 달라:
- 변경이 요구사항을 넘는지, AI가 하는 김에 했을 수 있는 부분은 어디인지;
- 만드는 비용, 검토하는 비용, 유지보수하는 비용 각각의 상황과 아직 부족한 증거;
- 하나의 제안: 병합 / 범위를 줄여 다시 하기 / 멈춤, 그리고 이유;
- 지금 할 수 있는 가장 작은 다음 단계 하나.
파일은 하나도 고치지 말 것. 증거가 없는 부분은 "확인 필요"로 표시하고 직접 채우지 말 것. 병합 여부는 그 프로젝트를 책임지는 사람이 정한다.
참고 자료
- GitHub Blog: The cost of saying yes has changed — https://github.blog/engineering/the-cost-of-saying-yes-has-changed/ (2026-07-17)
- arXiv (EASE 2026): To What Extent Does Agent-generated Code Require Maintenance? An Empirical Study — https://arxiv.org/abs/2605.06464 (2026-05-07)
- DORA: State of AI-assisted Software Development 2025 — https://dora.dev/research/2025/dora-report/ [accessed: 2026-10-11]
