AI 코딩 자율성, 얼마나 맡기고 어떻게 검증할지 정하는 기준 | DAKER 커뮤니티

AI 코딩 도구를 쓸 때 고민은 이제 프롬프트를 얼마나 잘 쓰느냐에만 머물지 않습니다. 실제로는 어디까지 맡길지, 그리고 그 결과를 어떤 증거로 검증할지가 더 중요한 문제가 됩니다.

Addy Osmani는 이 지점을 자율성의 문제로 설명합니다. 특히 Claude Code나 Codex처럼 실행과 반복, 병렬 작업까지 가능한 도구를 쓸수록 자율성을 한 줄의 등급표로 보기보다, 무엇을 얼마나 맡기고 여러 작업을 어떻게 조율할지 나눠서 보는 것이 중요해집니다.

자율성은 한 축으로만 보이지 않습니다

Addy Osmani의 「Agentic Autonomy Levels」는 AI 코딩의 논점이 프롬프트 작성에서 자율성 설계로 이동했다고 설명합니다. 여기서 핵심은 자율성을 단일 사다리처럼 보지 않는 데 있습니다.

한 에이전트가 얼마나 멀리 가는지와 여러 에이전트를 어떻게 조율하는지는 분리해서 봐야 합니다.

그는 이를 agency와 orchestration으로 나눕니다. agency는 한 에이전트가 스스로 계획하고 실험하며 목표를 향해 나아가는 정도를 뜻합니다. orchestration은 여러 에이전트를 어떤 방식으로 조율하고, 분리된 작업 공간에서 어떻게 협업하게 할지를 가리킵니다.

이 구분은 Claude Code나 Codex에서 곧바로 실무 판단 기준이 됩니다. 작업 모드, 자동 승인, 백그라운드 실행, 서브에이전트 사용 여부를 정할 때 이 두 축을 함께 봐야 하기 때문입니다.

언제 이 기준이 특히 중요해질까

이 기준은 단순 수정이 아니라 목표 달성형 작업을 맡길 때 더 중요해집니다. 장시간 리팩터링, 여러 작업의 병렬 처리, 자동 리뷰처럼 범위가 넓고 반복이 필요한 작업에서는 자율성 설정이 결과를 크게 좌우합니다.

예를 들어 문구 수정은 낮은 자율성으로도 충분할 수 있습니다. 반면 결제 경로 리팩터링이나 권한 정책 변경은 같은 코딩 작업이라도 높은 자율성을 바로 켜는 것이 적절하지 않을 수 있습니다. 실패했을 때 되돌리기 어렵고 영향 범위가 넓을수록 자율성의 상한은 낮아지고, 검증에 필요한 증거는 더 강해져야 합니다.

되돌리기 어려울수록 자율성은 낮추고, 검증 증거는 더 강하게 가져가는 것이 좋습니다.

agency와 orchestration을 나눠서 보는 이유

agency: 한 에이전트에게 어디까지 맡길 것인가

낮은 agency에서는 에이전트가 후보 행동을 제안하고 사람의 결정을 기다립니다. 중간 agency에서는 범위가 정해진 일을 수행하고, 그 과정과 결과에 대한 증거를 보고합니다. 높은 agency에서는 목표 조건을 만족할 때까지 계획, 실행, 테스트, 차단 해소를 반복합니다.

orchestration: 여러 에이전트를 어떻게 움직일 것인가

orchestration은 작업이 한 스레드에서 끝나는지, 여러 에이전트가 분리된 worktree에서 움직이는지, 혹은 큐와 스케줄을 기준으로 돌아가며 예외 상황만 사람에게 올리는지에 따라 달라집니다.

Osmani의 비유를 빌리면 자율성 등급은 자동차의 속도가 아니라 운전 권한에 가깝습니다. 빠른 차라고 해서 언제나 운전대를 오래 넘겨도 되는 것은 아닙니다. 좁은 골목에서는 오히려 더 조심스럽게 권한을 나눠야 합니다.

실무에서는 어떻게 적용하면 좋을까

적용의 출발점은 작업 위험도를 먼저 가르는 일입니다. 사용자 데이터, 인증, 결제, 보안, 대규모 삭제처럼 영향이 큰 작업은 기본적으로 높은 위험도로 두는 편이 좋습니다.

그다음에는 위험도에 따라 기본 자율성을 정하면 됩니다. 낮은 위험도에는 제안 후 멈추는 방식이 어울립니다. 중간 위험도에는 수정 후 테스트 증거를 제출하게 하는 방식이 적합합니다. 높은 위험도에는 계획 승인을 먼저 받고, 제한된 범위 안에서만 실행하게 두는 편이 안전합니다.

완료 조건은 수치보다 증거 중심으로 적는 것이 좋습니다.

Codex나 Claude Code에 작업을 지시할 때도 완료 조건을 막연하게 두기보다 증거로 써두는 편이 좋습니다. 예를 들어 관련 테스트 통과 여부, 변경 파일 목록, 실패 시 되돌릴 파일, 사람이 확인해야 할 위험 지점 보고 같은 항목이 여기에 해당합니다.

병렬 에이전트를 쓸 때는 더 분명한 경계가 필요합니다. worktree를 어떻게 나눌지, 각 에이전트의 담당 범위를 어디까지 둘지, 충돌은 어떤 방식으로 보고할지, 최종 통합 책임자는 누구인지 먼저 정해두는 것이 좋습니다.

자동 승인도 같은 원칙으로 접근할 수 있습니다. 되돌리기 쉬운 명령부터 켜고, 배포, 삭제, 권한 변경, 외부 API 쓰기처럼 되돌리기 어려운 행동에는 사람 확인 게이트를 유지하는 편이 적절합니다.

결국 중요한 것은 맡기는 범위보다 검증 방식입니다

AI 코딩 도구의 자율성은 높을수록 무조건 좋은 기능이 아닙니다. 어떤 작업인지, 실패했을 때 얼마나 위험한지, 여러 에이전트가 얽히는지에 따라 적절한 수준이 달라집니다.

그래서 실무에서는 얼마나 똑똑한 모델을 쓰는가보다, 어디까지 맡기고 어떤 증거를 받아 검토할지를 먼저 정하는 것이 더 중요해집니다. Osmani의 구분은 바로 그 판단을 구조화하는 데 도움이 됩니다.

참고 자료

https://addyosmani.com/blog/agentic-autonomy-levels/
https://addyosmani.com/blog/loop-engineering/
https://addyosmani.com/blog/agent-harness-engineering/

여러분은 코딩 작업에서 AI에게 어디까지 맡기고, 어떤 지점에서 반드시 사람 검토를 두는 편이신가요?