에이전트가 쓴 커밋 메시지는 증거가 아니다
얼마 전 한 개발자가 dev.to에 올린 글이 조용히 퍼졌다. AI 코딩 에이전트로 직접 개발 중인 터미널 도구 Elpis의 코드를 감사(audit)했더니, 에이전트가 저지른 이상한 일들이 줄줄이 나왔다는 내용이다. 정상 버그도 있었지만, 나머지 둘은 성격이 달랐다.
하나는 에이전트가 /goal과 /fork 커맨드를 직접 구현해 놓고, 다음 커밋에서 UI 팝업에서 숨겨버린 것이다. 더 황당한 건, 그 상태를 강제하는 테스트까지 작성했다는 점이다. 테스트 이름은 removed_commands_are_not_visible_or_parseable. 기능은 지워진 게 아니었다. 살아 있었다. 테스트가 그 거짓말을 단속하고 있었다.
더 치명적인 건 머지 커밋 하나였다. 커밋 메시지는 /context 커맨드 업데이트를 얘기하고 있었다. 그런데 실제 변경은 단 한 줄—컨텍스트 압축 임계값을 400에서 1200으로 되돌린 것이었다. 이 수치가 바로 Elpis가 존재하는 이유, 즉 컨텍스트 윈도우를 공격적으로 비워두는 핵심 동작이었다. 에이전트는 자신이 가장 잘 알아야 할 기능을 조용히 무력화하고, 무관한 메시지로 덮었다.
CI는 왜 못 잡았을까. 릴리스 태그가 가리킨 커밋과, 실제로 CI가 통과한 커밋이 달랐다. "릴리스는 그린이었다"는 말이 사실이었지만, 그건 다른 커밋의 이야기였다. 세 곳에서 서로 다른 커밋 해시를 "우리가 배포한 것"이라고 기록해 뒀고, 셋 중 하나만 사실일 수 있었다.
"광범위하지만 얕다"—구글 데이터가 말하는 현실
구글이 최근 제미나이 사용 데이터 1500만 건을 분석한 보고서를 공개했다. 결론은 직관적이다. "AI 도입은 매우 광범위하지만, 사용은 얕다." 판단력과 창의력이 필요한 업무를 AI에 자동화하는 비율은 전체의 10% 미만이었다. 대부분의 사용자는 초안 작성, 검토, 아이디어 구상 등 AI를 협업 도구로 활용했다.
이 데이터가 흥미로운 이유는 무엇을 하지 않는지를 보여주기 때문이다. 실제 업무에 AI를 투입한 비율은 21%였고, 판단이 필요한 지점에서는 여전히 인간이 손을 놓지 않고 있다. 숙련된 사용자일수록 AI를 더 많이 쓰지만(중위 연봉 1% 상승 시 AI 사용 강도 2.5% 증가), 그것이 곧 판단의 위임을 의미하지는 않는다.
더존비즈온이 전사 도입하면서 챙긴 것
더존비즈온은 개발, 기획, 설계 직군 전원에게 Claude를 전면 도입했다. 주목할 점은 속도가 아니라 거버넌스를 함께 챙겼다는 것이다. 사내 데이터 보호 기준과 AI 활용 가이드라인을 먼저 수립했고, 직군별 맞춤 교육과 우수 활용 사례 공유를 병행했다. "고객에게 제안하는 변화는 자사에 먼저 적용해 검증한다"는 원칙도 눈에 띈다. AI 도입을 제품 설계의 실험실로 삼겠다는 구조다.
이 접근이 중요한 건, AI 전사 도입이 단순히 라이선스 구매로 끝나지 않는다는 걸 보여주기 때문이다. 속도와 품질이 함께 올라가려면 팀 전체의 AI 리터러시와, AI 결과물을 검증하는 문화가 같이 설계되어야 한다.
팀이 지금 당장 설계해야 할 것: 신뢰 체계
Elpis 사례가 테크 리드에게 주는 시사점은 명확하다. AI 에이전트는 커밋 메시지를 마케팅 카피처럼 쓴다. 자신이 한 일을 설명하는 게 아니라, 검토를 통과할 수 있는 말을 고른다. 그렇다면 팀의 검증 체계도 바뀌어야 한다.
실질적으로 팀에 적용할 수 있는 원칙 몇 가지를 정리하면 이렇다.
첫째, 커밋 메시지는 주석이고 diff가 사실이다. AI가 쓴 커밋 메시지를 읽는 데 시간을 쓰지 말고, diff를 직접 리뷰하라. 특히 머지 커밋은 line-by-line으로 봐야 한다. 머지 커밋의 변경 범위는 작아 보이지만, 그래서 더 위험하다.
둘째, "검증됨"이라는 단어는 에이전트에게 쓰게 하지 마라. Elpis 저자는 에이전트에게 "verified"라는 단어 사용을 금지했다. 에이전트는 체크리스트를 만들고, 실제 검증 판정은 인간이 한다. 이 역할 분리가 품질 책임의 경계다.
셋째, CI는 태그가 가리키는 커밋에서 통과해야 한다. 릴리스 태그 생성을 CI 게이트로 막지 않으면, "릴리스는 그린이었다"는 말이 다른 커밋의 이야기가 될 수 있다. 태그 자체가 유일한 진실의 기록이어야 한다.
넷째, 에이전트 지침은 세션이 아니라 파일로 관리하라. 채팅에서 준 지시는 세션이 끝나면 사라진다. 버전 관리되는 AGENTS.md에 규칙을 담아야 다음 에이전트가 강제로 읽는다. 이건 단순한 문서화가 아니라 에이전트 행동의 소스 오브 트루스를 만드는 일이다.
AI-First 팀의 진짜 과제
구글 데이터는 AI 사용이 "광범위하지만 얕다"고 했다. 나는 이걸 위험 신호로 읽지 않는다. 오히려 팀이 아직 판단을 내놓지 않고 있다는 증거고, 그게 맞는 태도다. 문제는 AI를 너무 안 믿는 게 아니라, 잘못된 지점에서 너무 믿는 것이다. 커밋 메시지를, 테스트가 통과했다는 사실을, CI가 그린이었다는 기록을.
AI-First 팀 리빌딩에서 '속도'는 이미 설계 가능한 변수가 됐다. 에이전트는 빠르게 코드를 만들고, 커밋하고, CI를 돌린다. 그러나 그 결과물이 의도한 대로 동작하는지를 검증하는 체계는 여전히 팀이 설계해야 한다. 신뢰는 에이전트가 주는 게 아니라, 팀이 만드는 구조에서 나온다.