AI가 쓴 코드는 누구 책임인가: 팀 합의문에 먼저 적어 둘 것들

AI 코딩 어시스턴트를 설치하는 데는 하루면 충분하다. 오래 걸리는 것은 그다음, 팀원마다 다른 사용 방식을 하나의 기준으로 맞추는 일이다. 누군가는 제안을 거의 그대로 받아들이고, 누군가는 참고만 한다. 그 차이가 리뷰에서 부딪히기 시작하면 "AI가 쓴 코드인데요"라는 말이 책임을 흐리는 핑계가 되기도 한다. 이 칼럼은 그런 상황이 생기기 전에 팀이 문장으로 합의해 둘 항목을 정리하고, 바로 고쳐 쓸 수 있는 합의문 초안을 제시한다.

AI는 팀이 가진 것을 증폭한다

합의문이 필요한 이유는 DORA의 2025년 보고서가 잘 보여 준다. 보고서 발표 글의 핵심 문장은 "AI는 팀을 고쳐 주지 않고, 이미 있는 것을 증폭한다"는 것이다. 응답자의 90%가 업무에 AI를 쓰고 80% 이상이 생산성이 올랐다고 느끼지만, 30%는 AI가 만든 코드를 거의 또는 전혀 신뢰하지 않는다고 답했다. 또 AI 도입은 전달 처리량과는 양의 관계를 보인 반면 전달 안정성과는 여전히 음의 관계를 보였다. 보고서는 강한 자동 테스트, 성숙한 버전 관리, 빠른 피드백 같은 통제 장치 없이 변경량만 늘면 불안정해진다고 설명한다.

팀 문화 관점에서 읽으면 이렇다. 리뷰 기준이 느슨한 팀은 AI 덕분에 느슨한 코드를 더 많이, 더 빨리 병합하게 된다. 도구를 바꾸기 전에 기준부터 맞춰야 하는 이유다.

책임은 사람에게 있다는 것을 문서가 먼저 말한다

도구 제공자도 책임 소재를 분명히 한다. GitHub의 Copilot 코드 리뷰 책임 사용 문서는 Copilot이 만든 코드는 유효해 보여도 의미상·문법상 틀리거나 보안 취약점을 포함할 수 있으므로 항상 검토하고 테스트하라고 하고, Copilot 리뷰는 사람의 리뷰를 대체하는 것이 아니라 보완하는 도구로 쓰라고 권한다. 팀 합의문의 첫 줄은 이 문장을 팀 언어로 옮기는 데서 시작하면 된다. "병합 버튼을 누른 사람과 승인한 리뷰어가 책임진다. 코드를 누가(무엇이) 처음 썼는지는 책임을 바꾸지 않는다."

새로 생긴 결정: AI의 승인을 승인으로 셀 것인가

합의가 필요한 항목은 도구가 발전하면서 늘어난다. Copilot 코드 리뷰 문서에 따르면 Copilot은 저장소의 필수 승인 규칙을 팀원의 승인과 같은 방식으로 충족하는 승인 리뷰를 제출할 수 있다. 이 기능은 공개 프리뷰이며 명시적으로 켜야 하고, 기본값에서는 Copilot 리뷰가 필수 승인 수에 포함되지 않는다. 룰셋으로 모든 PR에 자동 리뷰를 요청할 수 있고, 저장소의 .github/copilot-instructions.md로 리뷰 기준을 안내할 수도 있다.

편리한 기능이지만 "AI 승인 1건 + 사람 승인 0건"으로 병합되는 경로가 열린다는 뜻이기도 하다. 이 기능을 켤지는 기술 설정이 아니라 팀의 책임 구조에 관한 결정이므로, 켜기 전에 합의문에 규칙으로 적어 둔다.

역할별로 나눠 둘 책임

바로 고쳐 쓸 수 있는 합의문 초안

저장소에 docs/ai-usage.md 같은 파일로 두고, 규칙 파일처럼 PR로 변경한다. 항목은 팀 상황에 맞게 지우고 더하면 된다.

# 우리 팀 AI 코딩 도구 사용 합의 (v1)

## 책임
- 병합한 사람과 승인한 리뷰어가 코드에 책임진다. 작성 주체(사람/AI)는 책임을 바꾸지 않는다.
- 작성자는 변경 이유를 자기 말로 설명할 수 있어야 한다.

## PR 규칙
- AI가 주로 작성한 파일이나 범위를 PR 설명에 적는다.
- 테스트를 로컬에서 실행한 결과를 첨부한다.
- AI 리뷰 승인은 필수 승인 수에 포함하지 않는다. (변경 시 팀 합의 필요)

## 넣지 않는 데이터
- 운영 DB 덤프, 고객 개인정보, 비밀 키, 계약서 원문

## 규칙 파일
- 소유자: @담당자
- 분기마다 쓰이지 않는 규칙과 충돌하는 규칙을 정리한다.

## 도구·요금제
- 회사 코드에는 조직 요금제 계정만 사용한다.

합의문 가운데 기계적으로 확인할 수 있는 항목, 예를 들어 테스트 파일이 함께 추가됐는지나 금지된 API 호출 패턴이 있는지는 .github/copilot-instructions.md에도 옮겨 둔다. 그러면 자동 리뷰가 같은 기준으로 코멘트를 남기고, 사람 리뷰어는 설계와 책임 판단에 집중할 수 있다. 새 팀원 온보딩 때는 합의문을 읽고 자기 계정의 요금제와 학습 거부 설정을 확인하는 단계를 체크리스트에 넣는다.

합의문의 PR 규칙을 실제 리뷰 체크리스트로 옮기는 방법은 AI 생성 코드 리뷰 규칙에서, 규칙 파일을 짧고 구체적으로 쓰는 방법은 Cursor Rules 작성법과 Claude Code 설정 글에서 다룬다. 요금제와 데이터 문제를 먼저 정리하고 싶다면 도입 전 다섯 가지 질문부터 읽는 편이 순서상 맞다.

완벽한 규칙보다 고칠 수 있는 규칙

처음부터 모든 경우를 규칙으로 막으려 하면 합의문이 길어지고 아무도 읽지 않게 된다. 위 초안처럼 책임, PR 규칙, 금지 데이터, 규칙 파일 소유자, 요금제 다섯 줄기만 먼저 합의하고, 리뷰에서 같은 논쟁이 두 번 반복될 때마다 한 줄씩 더하는 방식이 오래 유지된다. 합의문 자체에 버전 번호를 붙여 두면 언제 무엇이 바뀌었는지도 추적할 수 있다.