AI 보조 개발의 병목 현상은 더 이상 코드 생성(Code Generation)이 아니다

저는 프로그래밍 배경이 없습니다. 실제 서비스용 코드(production code)를 작성해 본 적도 없습니다. 저는 교육과 직업 측면에서 Quality Manager(품질 관리자)입니다. 즉, 규칙, 감사(audit), 위반, 그리고 시스템이 수행하기로 되어 있는 일과 실제로 수행하는 일 사이의 간극이라는 관점에서 생각하는 사람입니다.

지난주 저는 CORE 저장소(repository)를 확인했습니다: 1,022개의 소스 파일. 자율 AI 시스템을 위한 헌법적 거버넌스 런타임(constitutional governance runtime) — 감사 엔진(audit engines), 교정 작업자(remediation workers), 블랙보드 통신 레이어(blackboard communication layer), 헌법적 규칙 집행 파이프라인(constitutional rule enforcement pipeline), 샌드박스 실행 환경(sandboxed execution environment). 프로덕션 환경에서 실행 중입니다. 스스로를 통제하고 있습니다.

저는 그중 어느 것도 작성하지 않았습니다. 단 한 줄의 코드도, 단 하나의 거버넌스 파일도, 단 하나의 아키텍처 문서도 작성하지 않았습니다.

저의 유일한 도구는 질문이었습니다.

여기서 제가 주의하고 싶은 점이 있습니다: 이것은 생산성에 관한 이야기가 아닙니다. 저는 여러분에게 "AI를 사용하여 코드를 더 빠르게 작성했다"라고 말하려는 것이 아닙니다. 그것도 사실이지만, 일어난 일 중에서 가장 흥미 없는 부분입니다.

흥미로운 점은 AI가 신뢰할 수 있는 무언가를 작성하기 전에 무엇이 존재해야만 했는가 하는 점입니다.

아무도 묻지 않았던 질문

모두가 AI 보조 개발(AI-assisted development)에 대해 이야기하기 시작했을 때, 대화의 주제는 속도였습니다. 얼마나 빨리 생성할 수 있는가? 얼마나 많은 컨텍스트(context)를 유지할 수 있는가? 자동 완성(autocomplete)은 얼마나 좋은가?

저는 다른 각도에서 접근했습니다. 왜냐하면 저는 속도에 대해 생각하지 않기 때문입니다. 저는 정확성(correctness), 추적 가능성(traceability), 그리고 무언가 잘못되었을 때 어떤 일이 발생하는지에 대해 생각합니다.

저의 질문은 "AI가 코드를 작성할 수 있는가?"가 아니었습니다. 코드 생성(Code generation)은 해결된 문제입니다. 모델들은 충분히 훌륭합니다. 저의 질문은 이것이었습니다: 무엇이 옳은지 누가 결정하는가?

전통적인 개발 팀에서 그 책임은 코드 리뷰(code review), 테스트(tests), CI, 그리고 개발자 자신의 암묵적 지식에 분산되어 있습니다. AI가 코드를 생성할 때, 그 전체 구조는 처음부터 다시 설계되어야 합니다. AI는 무엇이 옳은지 알지 못합니다 — AI는 무엇이 그럴듯한지(plausible)를 알 뿐입니다. 이 둘은 위험할 정도로 다른 것입니다.

코드가 존재하기 전에 제가 실제로 기여한 것

하나의 개념(concept). AI가 이를 아키텍처(architecture)로 변환할 수 있을 만큼 정밀하게 유지되고, 끊임없이 질문을 던져 검증된 개념 말입니다.

CORE에는 .intent/라는 디렉터리가 있습니다. 이는 데이터로서의 거버넌스 법(governance law)입니다. 헌법적 규칙, 집행 정책, 작업자 일정, 권한 체인을 정의하는 YAML 및 JSON 파일들입니다. 저는 이 파일들을 작성하지 않았습니다. AI가 작성했습니다. 제가 기여한 것은 그 이면에 담긴 사고(thinking)였습니다. 무엇이 "정확함(correct)"을 의미하는지, 무엇이 "위반(violation)"을 의미하는지, 시스템이 절대 해서는 안 되는 일은 무엇인지 질문하고, 그 답변이 규칙이 될 수 있을 만큼 정확해질 때까지 밀어붙이는 작업이었습니다.

AI는 .intent/에 손을 댈 수 없습니다. 관례나 요청에 의해서도 안 됩니다. 아키텍처적 불변성(architectural invariant)에 의해서도 안 됩니다. 실행부(execution arm)는 헌법이 말하는 바를 구현합니다. 거버너(governor)인 저는 개념을 보유합니다. AI는 이를 모든 산출물, 즉 코드, 거버넌스 파일, 아키텍처 문서 등 모든 것에 반영하여 번역합니다. 모든 것이 말입니다.

그러한 분리가 전통적인 저자(authorship) 없이도 신뢰할 수 있는 소프트웨어를 가능하게 만들었습니다. AI가 더 똑똑해졌기 때문이 아닙니다. AI의 역할이 명확하게 제한되도록 아키텍처가 설계되었기 때문입니다. 즉, 개념이 명시하는 바를 구현하고, 위반 사항을 숨기는 대신 드러내며, 무엇이 정확한지를 정의하는 계층에는 절대 손을 대지 못하도록 설계된 것입니다.

패턴: 거버너(governor)와 실행부(execution arm)

제가 우연히 발견하고, 이후 의도적으로 설계한 것은 AI를 활용해 무언가를 만드는 모든 이에게 적용될 수 있다고 생각하는 분리 모델입니다.

거버너는 규칙을 작성합니다. 실행부는 이를 구현합니다. 실행부는 규칙을 수정할 수 없습니다.

이것은 당연하게 들리지만, 구조적으로 이를 강제하는 사람이 거의 없다는 사실을 깨닫기 전까지는 그렇습니다. 대부분의 AI 보조 개발 환경은 AI가 제약 조건 자체를 변경하는 것을 포함하여 무엇이든 제안할 수 있도록 허용합니다. 이는 거버넌스의 실패가 발생하기 직전의 상태입니다. AI가 악의적이기 때문이 아니라, 자신이 평가받는 규칙을 스스로 다시 쓸 수 있는 에이전트는 언제나 통과할 수 있기 때문입니다. 위반 사항은 기록에서 단순히 사라져 버릴 뿐입니다.

CORE에서 헌법 계층 (constitutional layer)은 AI의 변이 표면 (mutation surface) 밖에 존재합니다. AI는 src/에 대한 변경을 제안합니다. 하지만 .intent/에 대한 변경은 제안할 수 없습니다. 거버너 (governor)가 의도 (intent) 변경 사항을 검토하고 적용합니다. AI는 이를 구현합니다. 위반 사항은 블랙보드 (blackboard)에 나타납니다. 워커 (workers)가 이를 수정합니다. 이 사이클은 자율적으로 작동하지만, AI가 재형성할 수 없는 프레임 (frame) 내에서 실행됩니다.

코드를 생각하는 것을 멈췄을 때 변한 것

프로그래밍 배경지식 없이도 이것을 가능하게 만든 변화는 다음과 같습니다:

저는 "이것을 어떻게 작성할까?"라고 묻는 것을 멈추고, "올바른 상태가 무엇인지 어떻게 명시할까?"라고 묻기 시작했습니다.

이 두 질문은 완전히 다르며, 두 번째 질문이 바로 제가 답변하도록 훈련받은 질문입니다. 품질 관리 (Quality management)란 생산 전에 정확성을 정의하고, 실시간으로 편차를 탐지하며, 그 격차를 체계적으로 메우는 규율입니다. 헌법적 AI 거버넌스 (Constitutional AI governance)는 이와 동일한 규율을 다른 영역에 적용한 것입니다. 어휘는 바뀌었지만, 사고방식은 바뀌지 않았습니다.

저는 규칙을 직접 작성할 필요가 없었습니다. 대신 AI가 규칙을 정확하게 작성할 수 있을 만큼, 그리고 AI가 작성하지 못했을 때 제가 알아챌 수 있을 만큼 규칙을 충분히 잘 알고 있으면 되었습니다. 그것은 다른 종류의 기술이며, 결과적으로 그것이 바로 희소한 기술임이 드러났습니다.

이제 코드는 쉬운 부분입니다. 모델은 코드를 작성할 수 있습니다. 모델이 할 수 없는 것은 코드가 달성해야 하는 바를 정의하거나, 어떤 위반 사항이 차단 (blocking) 요소인지 아니면 권고 (advisory) 사항인지 결정하거나, 아키텍처가 의존하는 범위와 결과에 대해 판단을 내리는 일입니다. 그것은 거버너의 역할입니다. 그것은 인간의 역할입니다.

코딩을 할 줄 안다면 이것이 의미하는 바

AI 보조 시스템을 구축하는 개발자라면, 여기서 유용한 관점의 재구성 (reframe)이 가능하다고 생각합니다.

여러분의 가치는 더 이상 타이핑에 있지 않습니다. 타이핑은 원래부터 핵심이 아니었지만, 이제 그것은 부정할 수 없는 사실이 되었습니다. 여러분의 가치는 명세 (specification)에 있습니다. 즉, AI의 구현 결과가 그에 따라 평가될 수 있도록 헌법을 매우 정밀하게 작성하는 것에 있습니다.

제가 본 AI 보조 개발 (AI-assisted development) 과정에서 어려움을 겪는 개발자들은 AI를 자신의 더 빠른 버전으로 사용하려고 합니다. 즉, 동일한 워크플로우 (workflow), 동일한 사고방식을 유지하면서 단지 자동 완성 (autocomplete) 기능만 더해진 형태로 사용하는 것입니다. 반면, 진정한 레버리지 (leverage)를 찾는 사람들은 AI가 올바르게 구현할 수 있을 만큼 명확하게 사양 (spec)을 작성하며, AI가 제대로 수행하지 못했을 때 이를 잡아낼 수 있는 평가 레이어 (evaluation layer)를 구축합니다.

병목 현상은 거버넌스 (governance) 전문성에 있습니다. 코드 생성 (code generation)이 아닙니다.

증거 (The receipts)

CORE는 오픈 소스 (open source)입니다. 헌법적 규칙 (constitutional rules), 강제 불변량 (enforcement invariants), 그리고 거버넌스 아키텍처 (governance architecture)가 모두 리포지토리 (repo)에 존재합니다. 감사 엔진 (audit engine)은 스스로를 거버넌스합니다. 자율 데몬 (autonomous daemon)은 프로덕션 (production) 환경에서 실행되며, 수정 사항을 제안하고 인간의 검토 하에 이를 실행하지만, 무엇이 올바른 것인지를 정의하는 헌법 (constitution)에는 손을 댈 수 없습니다.

이 시스템은 코드를 작성하지도, 거버넌스 파일을 작성하지도, 아키텍처 문서 (architectural documents)를 작성하지도 않은 한 품질 관리자 (Quality Manager)에 의해 구축되었습니다. 그는 답변이 시스템이 될 수 있을 만큼 정밀해질 때까지 질문을 던졌습니다.

만약 당신이 AI 시스템을 구축하고 있으면서 아직 선을 긋지 않았다면 — 즉, AI가 절대로 넘어서는 안 될 선을 정의하지 않았다면 — 이것이 그것이 실제로 어떻게 구현되는지에 대한 하나의 해답입니다.

github.com/DariuszNewecki/CORE

저는 자율 AI 시스템을 위한 오픈 소스 헌법적 거버넌스 런타임 (constitutional governance runtime)인 CORE를 구축하고 있는 품질 관리자 (Quality Manager)입니다.