B컷전문 | 개발과 인생의 이야기

결제 서비스의 오류 메시지를 고쳐 달라고 AI 코딩 에이전트에 맡겼다. 에이전트는 문구뿐 아니라 공통 예외 처리기와 로깅 설정도 바꾼 풀 리퀘스트를 올렸다. 테스트는 초록색이다. 그렇다면 바로 병합해도 될까? 변경을 만든 주체보다 중요한 것은 무엇이 바뀌었고 누가 그 위험을 이해한 채 승인했는가다.

AI 코딩 에이전트는 저장소를 읽고 파일을 수정하며 테스트를 실행할 수 있다. GitHub의 Copilot cloud agent 설명도 계획·코드 변경·브랜치 작업과 풀 리퀘스트로 이어지는 흐름을 소개한다. 하지만 자동으로 만들어진 변경은 자동으로 정당화되지 않는다. 이 글은 작업 범위, 검토 증거, 승인 책임을 분리하는 실무 설계에 초점을 맞춘다.

1. 요청과 변경 범위를 먼저 고정한다

“오류 메시지를 개선해 줘”라는 요청만으로는 성공 조건과 금지할 변경을 알 수 없다. 담당자는 작업 전에 영향받는 화면·API, 기대 동작, 변경하지 말아야 할 계약, 확인할 테스트를 적는다. 에이전트가 범위 밖 변경을 발견하면 조용히 함께 고치기보다 별도 제안으로 분리하도록 한다.

경계	요청서에 남길 내용	검토 질문
목적	결제 실패 안내 문구의 오해를 줄인다	정상 결제 흐름은 그대로인가?
허용 범위	표시 문구와 해당 분기의 테스트	공통 예외 처리나 로그 필드까지 바뀌었나?
금지·승인 필요	결제 상태 전이, 개인정보 로그, 외부 API 계약	별도 소유자 검토가 필요한가?
완료 증거	재현 사례, 테스트 결과, 변경 파일 목록	실패한 검사와 미실행 검사가 구분됐나?

이 표는 가상의 결제 서비스 예시다. 실제 범위는 서비스 소유자와 배포 규칙에 맞게 정해야 한다.

2. 풀 리퀘스트를 “결과”가 아니라 검토 패키지로 만든다

리뷰어에게는 diff만이 아니라 원래 문제와 변경 이유가 필요하다. 풀 리퀘스트 본문에 재현 방법, 변경 파일과 의도, 영향받는 호출 경로, 실행한 검사와 결과, 남은 불확실성, 되돌리는 방법을 남긴다. 에이전트의 “테스트 통과” 요약을 그대로 믿지 말고 검사 이름·실행 환경·실패 또는 건너뜀 여부를 확인한다.

• 범위 확인: 요청과 무관한 파일, 생성 파일, 의존성·설정 변경을 따로 살핀다.
• 행동 확인: 정상·오류·경계 입력과 이전 동작의 호환성을 비교한다.
• 보안·데이터 확인: 권한 검사, 로그의 민감정보, 비밀값, 외부 호출과 마이그레이션을 점검한다.
• 증거 확인: 테스트의 단언 내용과 실제 실행 결과를 읽고 중요한 경로는 직접 재현한다.

GitHub의 Copilot code review 책임 있는 사용 안내는 AI 리뷰가 특히 크거나 복잡한 변경에서 문제를 놓칠 수 있음을 설명한다. AI 리뷰 코멘트는 검토 단서이지 사람의 도메인 판단이나 실행 증거를 대체하는 판정문이 아니다.

3. 승인 책임을 작업 생성과 분리한다

작업 지시자, 코드 소유자, 병합 승인자, 배포 담당자의 역할을 팀 규칙으로 명시한다. 작은 문구 변경과 결제 상태 전이 변경에 같은 검토 강도를 적용할 필요는 없지만, 위험한 변경에 필요한 승인을 생략해서는 안 된다. 에이전트가 제안한 수정에 사람이 다시 손을 댔다면 최종 diff 전체를 새로 확인한다.

GitHub의 브랜치 보호 규칙 문서에는 병합 전 풀 리퀘스트, 승인, 필수 상태 검사, 코드 소유자 검토, 새 커밋 후 오래된 승인 무효화 등을 설정하는 방법이 있다. 이는 설정 가능한 통제 수단이지 모든 저장소에 자동 적용되는 기본값은 아니다. 조직은 우회 권한과 관리자 예외까지 확인해야 한다.

4. 실전 예시: 결제 오류 문구를 바꾸는 PR

가상 PR에서 에이전트가 “결제 실패 시 다시 시도해 주세요”를 “카드사 승인 후 다시 시도해 주세요”로 바꾸고, 동시에 공통 예외 처리기의 오류 코드를 수정했다고 하자. 리뷰어는 아래 순서로 검토할 수 있다.

1. 요청서와 diff를 대조해 공통 처리기 변경을 범위 밖으로 표시한다.
2. 카드사 승인 실패와 네트워크 오류에서 같은 문구가 적절한지 제품 담당자와 확인한다. 원인을 모르면 특정 주체를 단정하지 않는다.
3. 오류 코드 변경이 모바일 앱, 고객지원 대시보드, 알림·재시도 정책에 영향을 주는지 호출자를 찾는다.
4. 기존 오류 사례를 재현하고 새 테스트가 문구뿐 아니라 상태 코드와 재시도 조건을 검증하는지 읽는다.
5. 공통 처리기 변경을 별도 PR로 분리하거나 해당 소유자의 추가 검토를 받은 뒤, 최종 커밋 기준으로 다시 검사한다.

테스트가 통과해도 명세에 없는 문구의 법적·고객 경험상 적합성을 증명하지는 않는다. 반대로 테스트 실패를 “원래부터 실패했다”라고 넘기려면 기준 브랜치에서도 동일하게 실패했는지 증거를 남겨야 한다.

5. 흔한 문제와 개선 팁

• 변경이 너무 크다: 기계적 정리와 기능 변경을 분리하고 작은 단위로 리뷰한다. 줄 수만으로 위험을 재단하지 말고 영향 경로를 본다.
• 설명이 그럴듯해 diff를 건너뛴다: PR 요약에서 주장한 수정과 실제 파일·테스트를 매핑한다. 특히 삭제된 검사와 완화된 단언을 확인한다.
• AI 리뷰를 승인으로 착각한다: 저장소의 현재 승인 정책과 AI 리뷰 기능 설정을 확인하고, 필요한 사람 검토를 별도 게이트로 둔다.
• 승인 뒤 추가 커밋이 들어온다: 새 diff와 상태 검사를 다시 확인하고, 필요하면 기존 승인을 무효화하는 규칙을 설정한다.
• 문제가 생겨도 책임자가 없다: 승인자, 배포자, 롤백 판단자와 사고 연락 경로를 PR에 연결한다. 책임은 에이전트 이름으로 넘길 수 없다.

요약

AI 코딩 에이전트가 변경을 빠르게 제안할수록 검토의 초점은 “누가 코드를 썼나”에서 요청 범위, 실제 diff, 검증 증거, 위험별 승인자로 이동한다. 작은 작업도 경계를 적고, 큰 영향이 생기면 분리하거나 소유자에게 넘긴다. 테스트와 AI 리뷰는 판단 자료이며, 병합·배포의 책임은 명시된 사람과 팀의 절차에 남는다.

참고 자료

• GitHub Docs, About GitHub Copilot cloud agent
• GitHub Docs, Responsible use of GitHub Copilot code review
• GitHub Docs, Managing a branch protection rule