AI가 코드를 썼다는 기록, 누가 결정해야 하는가

What Happened

VS Code 논란은 작은 설정 변경에서 시작됐다

최근 VS Code 저장소의 한 pull request가 글로벌 개발자 커뮤니티에서 큰 논쟁을 불렀습니다. 2026년 4월 16일 병합된 microsoft/vscode#310226은 Git 확장의 git.addAICoAuthor 기본값을 바꿔 AI 공동 작성자 trailer가 기본적으로 붙을 수 있게 했습니다. 문제는 “AI 기여를 기록할 수 있다”가 아니었습니다. 실제 AI 관여가 없거나 AI 기능을 꺼둔 경우에도 Copilot 공동 작성자 표기가 들어갈 수 있다는 보고가 이어졌다는 점이 핵심이었습니다.

이 변화는 곧 되돌려졌습니다. 2026년 5월 3일 병합된 microsoft/vscode#313931은 기본값을 다시 off로 돌리고, AI 기능이 비활성화된 상태에서는 추적 기능이 동작하지 않도록 했습니다. 대응은 빨랐지만 논쟁은 여기서 끝나지 않았습니다. 개발자들이 문제 삼은 것은 특정 PR 하나가 아니라, AI 기능이 개발 기록 안으로 들어오는 방식 자체였기 때문입니다.

Why It Matters

Git 커밋은 마케팅 문구가 아니라 감사 기록이다

Git 커밋은 단순한 메모가 아닙니다. 커밋 로그는 소프트웨어 변경의 감사 기록이고, 보안 사고가 발생했을 때의 추적 단서이며, 오픈소스 프로젝트에서는 기여자와 책임을 구분하는 근거입니다. 회사 내부에서는 승인된 AI 도구를 사용했는지, 외부 코드나 민감한 정보가 AI 시스템을 거쳤는지, 특정 변경의 실제 책임자가 누구인지 판단하는 자료가 되기도 합니다.

그래서 부정확한 Co-authored-by 표기는 단순한 UX 실수가 아닙니다. 이메일 하단의 “Sent from my iPhone” 같은 제품 흔적과도 다릅니다. Git commit trailer는 협업 플랫폼, 감사 도구, 정책 엔진이 읽는 구조화된 신호입니다. 틀린 신호가 들어가면 개발자는 설명해야 하고, 보안팀은 확인해야 하며, 저장소에는 잘못된 흔적이 남습니다.

Policy Risk

기업 보안 정책에서는 “보이는 흔적”이 곧 조사 대상이 된다

많은 조직은 AI 코딩 도구를 전면 금지하지 않습니다. 대신 승인된 도구, 승인된 데이터, 승인된 저장소, 승인된 작업 범위 안에서만 허용합니다. 이런 환경에서 모든 커밋에 Copilot 공동 작성자 표기가 붙는다면, 실제로는 AI를 쓰지 않았더라도 정책 위반처럼 보일 수 있습니다. 감사 기록은 “나중에 설명하면 되는 것”이 아니라, 설명 비용 자체를 줄이기 위해 존재합니다.

더 중요한 문제는 책임의 범위입니다. AI가 한 줄을 자동완성한 커밋과, AI 에이전트가 여러 파일을 수정하고 테스트까지 만든 커밋은 같은 사건이 아닙니다. 그런데 기록이 둘을 구분하지 못하면 AI 사용 기록은 투명성 도구가 아니라 혼란의 원인이 됩니다.

Agent Reality

AI 에이전트의 성능보다 운영 맥락이 더 중요해지고 있다

최근 소프트웨어 엔지니어링 에이전트 연구들도 같은 방향을 가리킵니다. agent-authored PR 3만 건 이상을 분석한 연구는 에이전트가 실제 GitHub 저장소에서 pull request를 만들고 있지만, 실패한 PR은 더 많은 파일을 건드리고 CI 검증을 통과하지 못하는 경우가 많다고 보고합니다. 단순히 코드 생성량이 늘어난다고 개발 과정이 안전해지는 것은 아닙니다.

또 다른 SWE-Skills-Bench 연구는 사전에 정의된 agent skill이 항상 성능을 높이지는 않는다고 지적합니다. 49개 skill 중 다수는 pass rate 개선에 기여하지 못했고, 어떤 경우에는 토큰 비용을 늘리거나 프로젝트 맥락과 충돌해 성능을 떨어뜨렸습니다. 즉 AI 코딩의 핵심 문제는 “더 강한 모델을 붙이면 해결된다”가 아닙니다. 저장소 구조, 테스트 환경, 코드 리뷰 문화, 보안 정책이 함께 작동해야 합니다.

Operating Principles

좋은 AI 개발 도구가 남겨야 할 세 가지 기록

• 정확한 provenance: AI가 어떤 파일을 수정했는지, 단순 자동완성인지, 테스트 생성인지, 대규모 리팩터링인지 구분해야 합니다.
• opt-in 기본값: Git, CI, package publishing, security scanning처럼 신뢰 체계와 연결되는 영역에서는 개발 기록을 바꾸는 기능이 명시적 선택이어야 합니다.
• 사람의 최종 책임: AI가 만든 코드를 사람이 merge한다면 최종 책임은 여전히 사람과 조직에 있습니다. 기록은 그 책임을 흐리게 만드는 대신 설명 가능하게 만들어야 합니다.

Takeaway

AI가 코드를 쓰는 시대에는 기록이 더 엄격해져야 한다

AI 코딩 도구는 분명히 유용합니다. 반복적인 구현을 줄이고, 낯선 API를 빠르게 탐색하게 도와주며, 테스트와 문서 초안을 만드는 시간을 줄여줍니다. 하지만 개발의 핵심 자산은 코드 그 자체만이 아닙니다. 변경 이력, 리뷰 맥락, 책임 소재, 운영 지식도 자산입니다. AI 도구가 이 자산을 흐리게 만든다면 생산성 향상은 쉽게 신뢰 손실로 바뀝니다.

앞으로 좋은 AI 개발 도구는 코드를 많이 생성하는 도구가 아니라, AI가 관여한 부분을 정확히 설명하고 기록하는 도구가 될 것입니다. 좋은 조직은 AI 사용을 무조건 금지하는 조직도, 무조건 장려하는 조직도 아닙니다. AI가 만든 결과를 사람이 이해하고 책임질 수 있는 형태로 남기는 조직입니다.

References

참고 자료

• microsoft/vscode#310226: Enabling ai co author by default.
• microsoft/vscode#313931: Change default for git.addAICoAuthor to off.
• GitHub Blog: Commit together with co-authors.
• Where Do AI Coding Agents Fail?: failed agentic pull requests in GitHub.
• SWE-Skills-Bench: do agent skills actually help in real-world software engineering?