AI 주도 개발에서의 사람의 판단 책임과 계약 체계

구현 전 완성 조건, 핸드오프의 다층 계약, 편집 범위 한정, 커밋 단위의 규율 — AI 주도 개발에서 사람이 맡아야 할 판단의 줄기를 정리한다.

1. 들어가며 — 왜 'AI 활용'보다 'AI와의 계약'이 먼저인가

AI 코딩 에이전트를 쓰기 시작하면 구현 속도는 금방 올라간다. "이 화면 만들어줘" "이 버그 고쳐줘" 하면 몇 분 뒤에 동작하는 코드가 돌아온다.

문제는 조금 뒤에 생긴다. 부탁하지도 않은 부분까지 고쳐져 있다. 테스트는 통과했는데, 무엇을 확인한 테스트인지 알 수 없다. "공개해 뒀습니다"라는 말을 듣고서야 알아챈다.

이 중 어느 것도 AI가 악의로 움직인 결과는 아니다. 지시문에 "여기서부터는 건드리지 않는다" "공개 여부는 사용자가 판단한다"를 적어두지 않은 것이 원인이었다.

2. 구현 전에 완성 조건을 선언한다 — Sprint Contract 운용

이 장에서는 AI에게 구현을 넘기기 전에 "완성 조건"을 짧게 적어두는 Sprint Contract의 운용을 다룬다.

AI 코딩 에이전트에게 "이 기능 구현해줘"라고 부탁하면 구현 자체는 진행된다. 그런데 완료의 정의가 흐릿하면 마지막에 이런 확인거리가 남는다.

정상 동작은 됐는데, 에러가 났을 때의 동작은 확인이 안 됐다. 인가나 이용 조건이 본문에 아예 나오지 않는다. 테스트는 통과했는데, 무엇을 확인한 테스트인지 알 수 없다. 회귀 방지(no-regression) 관점이 빠져 있다.

3. AI끼리의 handoff를 다층 계약으로 설계한다

이 장에서는 AI끼리의 인수인계(handoff)를 6개 층의 작업 계약으로 적는 방법을 다룬다.

Codex와 Claude Code를 같은 리포지터리에서 함께 쓰다 보면, 작업 인수인계는 금세 흐릿해진다.

어느 파일까지 건드려도 되는지가 모호해서, 다른 글이나 다른 기능까지 고치기 시작한다. published: true, git push, release 같은 최종 조작을 AI 쪽이 판단하려 든다.

4. handoff 다층 계약의 운용 패턴을 체크리스트로 굳힌다

이 장에서는 앞 장에서 보인 6계층 계약의 작성법을, 실제 작업 패턴별로 체크리스트로 정리한다.

AI끼리의 handoff를 단순한 인수인계 메모가 아니라, 작업 계약으로 적기 위한 체크리스트를 정리한다.

5. 편집 범위를 지시에 직결되는 곳으로만 좁힌다 — Surgical Changes

이 장에서는 AI의 편집 범위가 지시와 무관한 곳까지 번지는 문제를, 룰 파일 한 장으로 잡는 운용을 다룬다.

AI 코딩 에이전트에게 수정을 부탁하면, 지시 범위 밖의 코드까지 "친절하게" 정리·리팩터링·정돈되어 diff가 부풀어 오를 때가 있다.

6. 커밋 단위의 경계를 사람이 긋는다 — git add 개별 지정

이 장에서는 git add . 를 그만두고 개별 파일 지정으로 옮겨감으로써, 커밋에 섞이는 diff를 의도한 범위 안에 담는 운용을 다룬다.

작업이 끝난 뒤 git add . 로 한꺼번에 staging하면, 의도하지 않은 파일까지 커밋 후보에 들어갈 때가 있다.

7. 마무리 — AI에게 맡겨도 남는, 사람의 판단 책임

다섯 개 장에 걸쳐, AI 주도 개발에서 사람이 미리 정해둬야 할 것을 정리했다.

각 장에서 다룬 문제는 모두 "사람이 정해두지 않은" 것이다. AI는 일을 하고 있지만, 그 일이 의뢰한 쪽의 의도와 맞지 않았을 뿐이다.

워크넷(공공일자리 · 취업지원)에서는 다양한 일자리 정보와 취업 지원 서비스를 제공합니다. 자세한 사항은 워크넷 웹사이트를 방문해 주세요.