코딩 에이전트를 아키텍처 결정권자가 아닌 제약된 실행자로 다뤄야 할까?
Should coding agents be treated as constrained executors rather than architectural authorities?
핵심 요약
코딩 에이전트의 권한을 제한하고 인간이 아키텍처 통제권을 유지하는 워크플로우 모델에 대한 논의입니다.
- 권한 분리 — 인간이 아키텍처와 제약 조건을 정의하고 에이전트는 제한된 작업만 수행함
- 실행 통제 — 에이전트의 작업 완료 보고를 증거가 아닌 주장으로 간주하고 검증 절차를 거침
- 권한 예산 — 에이전트가 수행 가능한 작업 범위와 도구를 명확히 규정하여 무분별한 확장을 방지함
- 실패 모드 — 에이전트가 모호한 상황에서 임의로 판단하지 않고 작업을 중단하도록 설계함
난 혼자 일하면서 ChatGPT랑 코딩 에이전트 써서 소프트웨어 시스템 설계하고 만드는 사람임.
프로젝트 규모가 커지니까, AI한테 코드 짜달라고 하는 건 이제 문제가 아니더라고. 진짜 골치 아픈 건 에이전트가 뭘 건드릴 수 있는지, 아키텍처를 어떻게 해석하는지, 그리고 도대체 뭘 '완성된 작업'으로 칠 건지에 대한 통제권을 쥐는 거였음.
그래서 이런 원칙을 세웠다:
코딩 에이전트는 유능한 실행 도구일 순 있어도, 시스템의 아키텍처를 결정하는 권한까지 가져선 안 된다.
대략적으로 나는 책임 소재를 이렇게 나누려고 함:
-
사람은 시스템의 의도, 아키텍처, 경계, 그리고 절대 타협할 수 없는 제약 사항을 정의한다.
-
에이전트는 저장소 전체에 대한 무제한 권한을 갖는 게 아니라, 딱 정해진 단위의 작업만 받는다.
-
프로젝트 상태는 대화창 밖에서 관리해서, 세션 새로 열 때마다 시스템을 처음부터 다시 기억해내게 만들지 않는다.
-
에이전트가 작업 끝냈다고 말하는 건 그냥 주장일 뿐, 증거로 받아들이지 않는다.
-
테스트, 저장소 상태, 그리고 명시적인 승인 절차를 거쳐야 진짜 작업이 끝난 걸로 친다.
-
다음 단계로 넘어갈 땐 에이전트가 멋대로 판단하는 게 아니라, 사람이 직접 결정한다.
-
불분명하거나 허가받지 않은 행동은 창의적으로 해석하지 말고, 그냥 실패하게 둬야 한다.
아직 이 논리 구조를 검증 중이라 구체적인 구현 방식은 일부러 안 적었음.
실제로 에이전트 워크플로우를 구축해봤거나 관리해본 사람들한테 쓴소리 좀 듣고 싶다:
-
이거 진짜 거버넌스 문제 맞냐? 아니면 그냥 코딩 워크플로우를 불필요한 관료주의로 망치고 있는 거냐?
-
에이전트가 파일 수정하고, 도구 실행하고, 다단계 의사결정까지 하게 되면 어떤 통제 장치가 필수적이냐?
-
인간의 권한은 어디까지고, 에이전트의 자율성은 어디서부터 시작해야 하냐?
-
이 모델로도 막지 못하는 실패 유형은 뭐가 있냐?
-
권한, 범위가 정해진 실행, 외부 상태 관리, 검증, 명시적 승인을 다 아우르는 기존의 방법론이 이미 있냐?
나 뭐 파는 거 아니고, 어떤 코딩 에이전트 쓸지 추천받으려는 것도 아님. 그냥 이 '통제된 실행 모델'이 기술적으로 말이 되는지 확인하고 싶을 뿐임.
