AI 코드 거버넌스(Governance): 새로운 코드 리뷰의 병목 현상

현재 가장 믿을 만한 AI 코딩 이야기는 모든 사람이 갑자기 10배 더 빠르게 결과물을 내놓고 있다는 것이 아닙니다.

그보다는 많은 팀이 기존의 리뷰 시스템이 수용하도록 설계된 것보다 더 많은 코드를 생성하고 있다는 것입니다.

GitLab은 이번 주에 매우 익숙한 양상을 띠는 새로운 AI 책임성(accountability) 연구를 발표했습니다. 도입률은 높습니다. 출력은 더 빨라졌습니다. 리더들은 ROI(투자 대비 효율)를 확인합니다. 개발자들은 여러 AI 코딩 도구를 사용합니다. 그러다 불편한 부분이 등장합니다. 응답자의 85%는 AI가 병목 현상을 코드를 작성하는 단계에서 리뷰하고 검증하는 단계로 옮겨 놓았다는 데 동의하며, 84%는 가장 큰 과제가 AI가 생성한 코드가 만들어진 이후에 발생하는 일들을 거버넌스(governance)하는 것이라는 데 동의합니다.

이는 타당하게 느껴집니다.

수년 동안 판매 전략은 "AI가 코드 작성을 도와줄 것입니다"였습니다. 좋습니다. 실제로 그렇습니다. 때로는 잘, 때로는 서투르게, 종종 충분히 유용하게 말이죠.

하지만 코드 작성이 업무의 전부는 아니었습니다.

업무란 이 코드가 존재해야 하는지, 여기에 적합한지, 지루한 운영(production) 환경에서도 올바르게 작동하는지, 나중에 누군가 유지보수할 수 있는지, 그리고 모델이 다음 작업으로 넘어간 후 팀이 그 결과에 대해 책임을 질 의사가 있는지를 결정하는 것입니다.

이것은 생성(generation)의 문제가 아닙니다.

이것은 거버넌스(governance)의 문제입니다.

생성은 쉬운 데모가 된다

코드 생성 데모는 전후 차이가 명확하기 때문에 만족감을 줍니다.

무언가를 설명합니다. 도구가 파일을 작성합니다. 테스트가 나타날 수도 있습니다. UI가 렌더링됩니다. 풀 리퀘스트(pull request)가 열립니다. 모두가 결과물을 가리키며 기계가 작업을 수행했다고 말할 수 있습니다.

거버넌스는 데모하기가 더 어렵습니다. 왜냐하면 결과물이 주로 '부재(absence)'의 형태로 나타나기 때문입니다.

안전하지 않은 의존성(dependency)이 머지(merge)되지 않았습니다. 생성된 마이그레이션(migration)이 롤백(rollback)을 망가뜨리지 않았습니다. 에이전트(agent)가 두 번째 결제 경로를 만들어내지 않았습니다. 리뷰어가 구현 내용이 프롬프트(prompt)와는 일치하지만 시스템을 위반하는 지점을 잡아냈습니다. 팀은 장애 발생 시 생성된 변경 사항이 어디서 왔는지 설명할 수 있었습니다. 누군가 필요할 때 감사 추적(audit trail)이 존재했습니다.

이것은 도구가 한 단락의 글을 보고 기능을 구축하는 것을 지켜보는 것보다 덜 흥미진진합니다.

또한 이것은 실제 업무에 더 가깝습니다.

GitLab의 수치는 속도와 통제를 분리하여 보여준다는 점에서 흥미롭습니다. 발표 내용에 따르면, 조직의 78%가 AI 도구를 도입한 이후 개발자들이 더 빠르게 코드를 작성하고 커밋(commit)하고 있다고 답했습니다. 동시에 43%는 자체 코드베이스에서 AI가 생성한 코드와 사람이 작성한 코드를 신뢰성 있게 구분할 수 없다고 답했으며, 82%는 AI 생성 코드가 관리할 준비가 되지 않은 새로운 종류의 기술 부채(technical debt)를 생성할 위험이 있다고 답했습니다.

이것이 바로 AI의 역설을 한 문장으로 요약한 것입니다: 입력(input)은 저렴해졌지만, 출력(output)은 여전히 시스템 내에서 살아남아야 합니다.

리뷰는 이제 하나의 생산 시스템(production system)입니다

모든 코드를 사람이 작성했을 때도 코드 리뷰는 충분히 불편한 작업이었습니다.

이제 여기에 백그라운드 에이전트(background agents), 생성된 테스트, 추측성 리팩터링(speculative refactors), 너무 빠르게 승격된 프로토타입 코드, 그리고 도구가 생성한 모든 줄을 완전히 이해하지 못할 수도 있는 사람들이 작성한 풀 리퀘스트(pull requests)를 더해 보십시오.

리뷰 대기열(review queue)은 압력 조절 밸브(pressure valve)가 됩니다.

AI 코딩이 제대로 작동한다면 레버리지(leverage)로 활용할 수 있습니다. 하지만 실패한다면, 조직은 불확실성을 제조하는 더 빠른 방법을 찾아낸 것뿐입니다.

이것이 제가 리뷰를 사회적 의례(social ritual)라기보다 하나의 생산 시스템(production system)으로 취급해야 한다고 생각하는 이유입니다.

리뷰에는 입력(inputs), 대기열(queues), 서비스 수준(service levels), 실패 모드(failure modes), 소유권(ownership), 그리고 포화 지점(saturation points)이 존재합니다. 리뷰는 과부하될 수 있습니다. 중요한 작업을 누락할 수 있습니다. 숨겨진 노고(toil)를 만들어낼 수 있습니다. 만약 모든 인센티브가 "더 많은 코드 배포"에만 맞춰져 있고 "나중에 거절될 코드 감소"에는 맞춰져 있지 않다면, 잘못된 행동을 보상할 수도 있습니다.

기존의 리뷰 프로세스는 새로운 코드 볼륨을 견뎌내지 못할 수도 있습니다.

그렇다고 해서 모든 회사가 당장 거대한 거버넌스(governance) 플랫폼을 필요로 한다는 뜻은 아닙니다. 다만, AI 중심의 워크플로우 끝에 사람이 단순히 도장만 찍는(rubber stamp) 것으로 충분하다고 가장하는 것을 팀들이 멈춰야 한다는 뜻입니다.

리뷰는 더 앞 단계로 이동해야 합니다.

에이전트가 시작되기 전에, 작업(task)은 경계(boundaries)를 정의해야 합니다: 허용된 파일, 금지된 의존성(dependencies), 마이그레이션 제약 조건, 테스트 기대치, 보안 가정, 그리고 에이전트가 반드시 생성해야 하는 증거(evidence) 등이 포함됩니다.

작업이 진행되는 동안, 시스템은 프롬프트(prompt), 모델(model), 도구 호출(tool calls), 명령(commands), 읽은 파일(files read), 실행된 테스트(tests run), 발생한 실패(failures encountered), 그리고 인간의 개입(human interventions)과 같은 흔적(traces)을 유지해야 합니다.

작업이 끝난 후, 풀 리퀘스트(pull request)는 리뷰어가 마치 법의학 고고학자(forensic archaeologist)가 되지 않고도 결정을 내릴 수 있을 만큼 충분한 문맥(context)을 보여주어야 합니다.

그것이 바로 거버넌스(governance)입니다.

위원회(committee)가 아닙니다. 40페이지짜리 정책(policy)도 아닙니다. 당신이 직접 타이핑하지 않은 작업물을 신뢰하기 위해 필요한 최소한의 운영 기제(operational machinery)입니다.

출처(provenance)는 사치가 아니다

GitLab의 조사 결과 중 가장 불편한 사실 중 하나는 추적 가능성(traceability)의 격차입니다.

조직들은 AI가 생성한 코드가 운영 장애(production incident)에 기여했는지 여부를 판단할 수 있다고 자신하지만, 지난 1년 동안 장애를 겪었던 많은 조직이 실제로 그 판단을 내릴 수 없었습니다.

이것이 바로 팀들이 너무 늦게 깨닫게 되는 바로 그 종류의 문제입니다.

차분한 계획 회의 중에는 모두가 이력이 재구성 가능할 것이라고 가정합니다. 풀 리퀘스트(pull request)가 있고, 커밋(commit)이 있고, 이슈(issue)가 있습니다. 에이전트 트랜스크립트(agent transcript)도 아마 어딘가에 있을 것입니다. 누군가 Slack을 검색하면 됩니다. 누군가는 어떤 도구가 사용되었는지 기억할 것입니다.

그러다 장애가 발생하고, 고객은 화가 나며, 보안 팀은 답변을 요구합니다. 그런데 증거는 다섯 개의 제품, 두 개의 브라우저 탭, 로컬 터미널 히스토리(terminal history), 그리고 더 이상 동일한 문맥을 가지고 있지 않은 모델이 작성한 요약본에 흩어져 있습니다.

책임에는 흔적이 필요하기 때문에 출처(provenance)가 중요합니다.

이 변경 사항은 어디에서 왔는가? 생성되었는가, 편집되었는가, 아니면 직접 작성되었는가? 어떤 지침(instructions)이 이를 가이드했는가? 어떤 테스트가 통과했는가? 어떤 경고(warnings)가 무시되었는가? 누가 승인했는가? 모델이 외부 소스를 사용하는 것이 허용되었는가? 올바른 내부 문서(internal docs)를 읽었는가? 나중에 사람이 위험한 부분을 수정했는가?

그러한 흔적이 없다면, "AI 생성"은 유용한 엔지니어링 사실이 아니라 그저 하나의 느낌(vibe)이 되어버립니다.

그리고 느낌(vibe)은 장애 상황의 아티팩트(artifact)로서 최악입니다.

거버넌스가 비난을 의미해서는 안 된다

우리가 피하기를 바라는 잘못된 형태의 AI 코드 거버넌스가 있습니다.

그것은 개발자를 위한 감시 계층(surveillance layer)으로 변질됩니다.

모든 줄에 라벨이 붙습니다. 모든 모델 상호작용(model interaction)에 점수가 매겨집니다. 생성된 모든 커밋(commit)은 컴플라이언스(compliance) 대상이 됩니다. 관리자들은 왜 어떤 사람은 다른 사람보다 더 많은 AI 코드를 생성했는지 묻기 시작합니다. 리뷰어(Reviewer)들은 리스크 사무원(risk clerks)이 됩니다. 개발자들은 감사 추적(audit trail)이 함정처럼 느껴지기 때문에 도구 사용을 숨깁니다.

그것은 낭비가 될 것입니다.

목표는 AI를 사용한다는 이유로 사람들에게 수치심을 주거나, 인간이 작성한 코드와 생성된 코드 사이의 순수성 테스트(purity test)를 만드는 것이어서는 안 됩니다. 코드베이스(codebase)는 특정 줄이 모델에서 시작되었는지, 자동 완성(autocomplete)인지, 코드 스니펫(snippet)인지, Stack Overflow의 답변인지, 혹은 밤 11시의 지친 엔지니어로부터 나왔는지에는 관심이 없습니다.

코드베이스가 신경 쓰는 것은 그 줄이 정확한지, 유지보수 가능한지(maintainable), 안전한지(secure), 관찰 가능한지(observable), 그리고 소유권(owned)이 명확한지 여부입니다.

거버넌스(Governance)는 이러한 질문들에 더 쉽게 답할 수 있도록 만들어야 합니다.

유용한 시스템은 다음과 같이 말합니다: "이 변경 사항은 에이전트의 도움을 받았으며, 지시 사항은 이러했고, 이 파일들이 수정되었으며, 이 테스트들이 실행되었고, 이러한 리스크들이 선언되었으며, 이 사람이 이를 승인했고, 나중에 검사가 필요할 경우를 대비한 증거 추적(evidence trail)은 이것입니다."

나쁜 시스템은 다음과 같이 말합니다: "여기 누가 AI를 가장 많이 사용했는지 보여주는 리더보드(leaderboard)가 있습니다."

하나는 팀이 소프트웨어를 운영하도록 돕습니다.

다른 하나는 더 화려한 대시보드(dashboard)와 함께 코드 라인을 재현할 뿐입니다.

소규모 팀에게도 이것이 필요합니다

AI 거버넌스를 엔터프라이즈(enterprise) 문제로 취급하고 싶은 유혹이 생깁니다.

대기업은 컴플라이언스 부서, 조달 프로세스, 보안 검토, 감사 요구 사항을 갖추고 있으며, 모든 것이 플랫폼 문제처럼 느껴질 정도로 충분한 도구 확산(tool sprawl)을 겪고 있습니다. 물론 그들에게는 거버넌스가 필요합니다.

하지만 소규모 팀도 근본적인 문제는 동일하며, 단지 회의가 더 적을 뿐입니다.

3인 규모의 스타트업도 아무도 이해하지 못하는 생성된 코드를 병합할 수 있습니다. 1인 유지보수자(maintainer)는 테스트는 통과하지만 미묘한 동작을 변경하는 에이전트 작성 의존성 업데이트(dependency update)를 수락할 수 있습니다. 아주 작은 제품 팀은 AI로 프로토타입을 만들고 출시한 다음, 아무도 내린 결정을 기억하지 못하는 결정들 속에서 6개월을 보내게 될 수도 있습니다.

차이점은 소규모 팀은 보통 프로세스(process)를 통해 문제를 해결할 여력이 없다는 것입니다.

그들에게는 가벼운 습관(lightweight habits)이 필요합니다.

저장소 지침(repository instructions)을 작성하세요. 생성된 풀 리퀘스트(pull request)의 크기를 도구가 생성하려는 것보다 더 작게 유지하세요. 구현 세부 사항뿐만 아니라 동작을 증명하는 테스트를 요구하세요. 에이전트에게 트레이드오프(tradeoffs)와 거부된 접근 방식에 대해 설명하도록 요청하세요. 위험한 변경 사항에 대해서는 트랜스크립트(transcripts)를 저장하세요. 리뷰어가 단순히 차이점(diff)만 보는 것이 아니라 작업 경계(task boundary)를 확인하도록 하세요. 아무도 소유하려 하지 않는 생성된 코드는 공격적으로 삭제하세요.

이 중 대부분은 비용이 많이 들지 않습니다.

이것은 규율(discipline)의 문제입니다.

새로운 병목 현상은 판단력(judgment)이다

흥미로운 커리어 관점은 AI가 엔지니어링 판단력(engineering judgment)의 가치를 떨어뜨리지 않는다는 점입니다.

오히려 판단력을 희소한 요소로 만듭니다.

코드의 초안을 작성하는 비용이 저렴해진다면, 가치 있는 엔지니어는 그 초안이 정말 괜찮은지 결정할 수 있는 사람입니다. 이는 코드를 주의 깊게 읽는 것을 의미합니다. 시스템 경계(system boundaries)를 이해하는 것. 테스트가 의미 있는지 아는 것. 변경 사항이 너무 큰지 파악하는 것. 숨겨진 의존성(dependency)의 이름을 붙이는 것. 그럴듯한 헛소리(plausible nonsense)를 거부하는 것. 왜 "작동한다(works)"는 것이 "적절하다(belongs)"와 같지 않은지 설명하는 것 말입니다.

이것은 불편한 일입니다. 왜냐하면 판단력은 구문(syntax)보다 가르치기 더 어렵기 때문입니다.

또한 측정하기도 더 어렵습니다. 생성된 라인 수는 셀 수 있습니다. 병합된 풀 리퀘스트(pull requests) 수도 셀 수 있습니다. 리뷰 코멘트 수도 셀 수 있습니다. 하지만 누군가 적절한 시점에 짜증 나는 질문 하나를 던졌기 때문에 발생하지 않은 나쁜 마이그레이션(migration)을 세는 것은 훨씬 더 어렵습니다.

하지만 그것이 바로 업무입니다.

AI 지원 개발(AI-assisted development)을 더 잘하게 되는 팀은 단순히 가장 강력한 모델을 가진 팀이 아닐 것입니다. 그들은 판단력을 재사용 가능한 시스템으로 바꾸는 팀이 될 것입니다. 즉, 작업 템플릿(task templates), 리뷰 체크리스트(review checklists), 저장소 지침(repository instructions), 추적 가능한 증거(traceable evidence), 좋은 테스트, 명확한 소유권(ownership), 그리고 생성된 작업물을 거부하는 것이 당연한 문화가 있는 팀입니다.

마지막 부분이 중요합니다.

만약 조직이 모든 AI 풀 리퀘스트(pull request)를 반드시 보존해야 하는 생산성으로 취급한다면, 리뷰어들은 잘못된 작업물을 어떻게든 살려내야 한다는 압박을 느끼게 될 것입니다. 때로는 올바른 리뷰가 "아니오"인 경우가 있습니다. 때로는 브랜치(branch)를 삭제하는 것이 최선의 결과일 수도 있습니다. 때로는 에이전트(agent)가 요청받은 대로 정확히 수행했으나, 그 요청 자체가 잘못되었을 수도 있습니다.

거버넌스(Governance)는 이러한 상황을 용인할 수 있어야 합니다.

핵심 요약 (the punchline)

AI 코딩은 코드 작성 비용을 낮추었지만, 소프트웨어를 소유(own)하는 비용을 낮추지는 못했습니다.

이것이 GitLab 연구 결과 속에 숨겨진 부분입니다. 병목 현상(bottleneck)이 생성(generation) 단계에서 리뷰(review), 검증(validation), 출처(provenance), 그리고 책임(accountability) 단계로 이동하고 있습니다. 어려운 질문은 더 이상 "도구가 코드를 생성할 수 있는가?"가 아닙니다.

물론 생성할 수 있습니다.

진짜 어려운 질문은 "코드가 존재하게 된 이후에 일어나는 일들을 팀이 통제할 수 있는가?"입니다.

이는 코드가 어디에서 왔는지, 무엇을 하기로 되어 있었는지, 어떻게 검사되었는지, 누가 승인했는지, 그리고 프로덕션(production) 환경에서 누가 소유하고 있는지를 아는 것을 의미합니다.

팀이 이러한 메커니즘을 구축한다면, AI 코딩은 진정한 레버리지(leverage)가 될 수 있습니다.

만약 구축하지 못한다면, 이해할 수 있는 속도보다 더 빠르게 코드를 생성하고, 거버넌스(govern)할 수 있는 속도보다 더 빠르게 코드를 병합(merge)하며, 나중에 그 뒷수습을 "기술 부채 (technical debt)"라고 부르게 될 것입니다.

기술적으로는 맞는 말입니다.

하지만 코드 리뷰가 결국 핵심 제품(product)이었다는 사실을 깨닫기에는 매우 값비싼 방식이기도 합니다.

참고 문헌 (references)

제 프로젝트를 테스트하기 위해 저는 Railway를 사용합니다. 시작할 때 20달러(USD)를 받고 싶다면, 이 링크를 사용하세요.