Sonar의 2026년 코드 현황 조사에 따르면, 커밋된 코드의 42%가 AI로 생성되었거나 AI의 도움을 상당히 받은 코드였습니다. 그리고 이 비율은 앞으로도 계속 늘어날 것으로 전망됩니다.

코드를 만드는 일은 점점 저렴해지고 있습니다. 반대로 희소해지는 자원은 검토, 검증, 이해, 유지보수입니다. 오랫동안 구글에서 Chrome 개발자 경험을 이끌다 지금은 Google Cloud AI를 맡고 있는 애디 오스마니는 여기서 문제를 하나 짚습니다. 생성 속도는 이렇게 빨라졌는데, 통제하는 속도는 그만큼 빨라지지 않았다는 것이죠. 그 결과 신뢰-검증 격차가 생겼습니다. AI가 짠 코드를 어느 정도 못 미더워하는 사람은 많은데, 정작 그 불신을 검증 과정에 꾸준히 반영하는 사람은 적다는 이야기입니다.

출처: Own the Outer Loop – Addy Osmani (Elevate)

에이전트가 힘을 가질수록 책임도 커진다

에이전트에게는 레버리지가 있고, 레버리지는 의무를 만듭니다. 무엇이 바뀌었는지, 왜 그게 안전한지, 틀렸을 경우 무슨 일이 생기는지를 누군가는 설명할 수 있어야 합니다. 그렇지 못하면 그 행동은 정당화될 수 없고, 애초에 조직이 그런 결과물을 원하지도 않게 됩니다.

오스마니는 이 문제를 세 개의 개념으로 나눠 설명합니다. 첫째는 품질입니다. 시스템을 풀어놓기 전에 설치해두는 모든 점검 장치를 가리키며, 이 점검들이 증거를 만들어냅니다. 둘째는 판정입니다. 그 증거를 보고 작업물을 다음 단계로 넘길지 결정하는 최종 판단이죠. 모델이 코드 한 줄을 쓸 수는 있지만, 그 판정은 여전히 사람의 몫입니다. 셋째는 설명책임입니다. 누군가 묻는다면 왜 그렇게 결정했는지 설명할 수 있다는 보장입니다.

안에서는 능력이, 밖에서는 결정이 돈다

오스마니는 에이전트를 모델 하나가 아니라, 파일과 도구, 메모리, 스킬, 샌드박스, 권한, 관찰가능성, 복구 기능까지 포함한 하나의 “하네스”로 정의합니다. 이 하네스가 조사, 구현, 검증, 반복이라는 순환을 돕니다. 여기서 중요한 건, 작업이 끝났는지를 판단하는 게 모델 스스로의 말이 아니라 독립된 점검이라는 점입니다.

이런 루프를 여러 개 동시에 돌리면 하나의 “소프트웨어 팩토리”가 됩니다. 에이전트는 그 안에서 작업을 실어 나르고, 사람은 경계에서 결정을 소유합니다. 시스템 안쪽에서는 제품팀의 의도나 이전에 출시된 작업, 최근 사고 이력, 구체적인 사용자 피드백 같은 입력을 받아 에이전트 루프가 과제를 조사하고 계획을 실행하고 결과를 검증합니다. 그 결과가 경계를 넘어오면, 그 시스템을 책임지는 사람이 증거를 보고 진행 여부를 결정합니다.

예전에는 에이전트가 실행 루프의 안쪽 일부를 맡았습니다. 지금은 에이전트가 그 안쪽 실행 루프 전체를 돕니다. 그래서 엔지니어는 바깥쪽 루프를 소유해야 합니다. 안쪽에서 일어나는 일은 결국 한 가지, 능력입니다. 과제를 조사하고 계획을 실행하고 결과를 테스트하고 보고하는 능력이죠. 바깥쪽에서 일어나는 일도 결국 한 가지, 자율성입니다. 결정하고 검증하고 승인하고 소유하는 자율성입니다.

판정을 방치하면, AI는 그 방치를 스타일로 배운다

이 “판정”을 대충 넘기면 실제로 어떤 일이 생기는지 보여주는 사례가 있습니다. 한 개발자는 라우트 핸들러, 백그라운드 작업, API 엔드포인트, 웹훅 등 여러 곳에 똑같은 접근 권한 검사가 필요했습니다. 매번 필요한 걸 설명하면 모델이 작동하는 코드를 만들어줬고, 그는 그걸 그대로 병합했습니다. 네 개의 조건문이 변수명만 살짝 다른 채 거의 똑같은 형태로 반복됐죠. 공유 헬퍼 함수로 뽑아내는 게 훨씬 깔끔했겠지만, 코드는 어차피 작동했고 테스트도 통과했습니다.

문제는 그다음이었습니다. LLM은 진공 상태에서 코드를 쓰지 않습니다. 이미 열려 있는 파일과 기존에 있던 패턴, 최근에 바뀐 코드를 읽습니다. 병합한 모든 편법은 사실 “여기선 이런 식으로 일한다”는 신호였던 셈이죠. 다음에 같은 접근 권한 규칙으로 새 엔드포인트를 요청하면, 모델은 원칙부터 다시 따지지 않습니다. 이미 저장소에 있는 나머지 네 벌의 사본에서 출발합니다. 다섯 번째 엔드포인트를 요청하면 다섯 번째 조건문이 똑같이 복사된 채로 나옵니다. 리팩터링을 요청해도 모델은 다섯 개를 다 그대로 보존합니다. 그게 이 코드의 스타일이라고 판단했기 때문입니다.

유지보수를 LLM에게 아웃소싱했다고 생각했는데, 실제로는 점점 더 나빠지는 습관을 학습시키고 있었던 셈입니다. 사소한 것 몇 개는 큰 문제가 아니라고 넘어갈 수 있지만, 코드 냄새는 그렇게 쌓입니다. 중복된 조건문 하나, “일단 만능 함수”로 넘긴 함수 하나, “나중에 정리하자”며 병합한 것 하나하나가 다음 프롬프트에 실리는 신호를 한 겹씩 더합니다. 결국 프롬프트만으로는 빠져나오기 어려운 지점에 이릅니다.

이 두 이야기는 결국 같은 지점을 가리킵니다. 에이전트가 안쪽 루프를 아무리 잘 돌려도, 바깥쪽에서 판정하고 설명할 사람이 없으면 그 판정의 부재 자체가 다음 결과물의 기준이 되어버립니다.

오스마니는 앞서 AI가 짠 코드를 아무도 진짜 이해하지 못한 채 승인만 쌓이는 “이해 부채” 문제도 짚은 적이 있습니다. 이번 글의 초점은 조금 다릅니다. 이해의 문제가 아니라, 이해했든 안 했든 누가 최종 판정을 내리고 그걸 설명할 수 있느냐는 책임의 문제입니다.