권한 경계
개요
가장 강한 하네스 중 일부는 AI가 무엇을 하게 만들지보다, 애초에 무엇을 할 수 없게 만들지에서 시작한다.
이 문서는 harness/ai 적용 레이어의 가장 바깥쪽 경계로서,
AI 작업자가 애초에 어디까지 움직일 수 있는지를 먼저 닫는다.
capability boundary란 무엇인가
capability boundary는 AI가 현재 작업에서 접근하고 실행할 수 있는 표면을 제한하는 경계다.
대표적으로 다음을 포함한다.
- 어떤 파일을 읽고 쓸 수 있는가
- 어떤 명령을 실행할 수 있는가
- 어떤 도구를 사용할 수 있는가
- 어떤 환경에 배포하거나 영향을 줄 수 있는가
- 어떤 변경은 반드시 사람 승인 이후에만 가능한가
즉 task contract가 작업 내용을 닫는다면, capability boundary는 행동 가능 공간 자체를 먼저 닫는다.
왜 필요한가
AI는 비어 있는 권한을 대개 사용 가능한 경로로 해석한다.
- 쓸 수 있는 파일이 넓으면 unrelated refactor로 퍼진다
- 실행 가능한 명령이 넓으면 더 큰 우회 실험을 시도한다
- 배포나 외부 시스템 접근이 열려 있으면 검증 전 변경이 현실로 나간다
그래서 capability boundary는 선택적 안전장치가 아니라, AI 작업자 하네스의 첫 층이다.
좋은 capability boundary의 기본 원칙
write scope를 좁힌다
현재 task와 직접 관련된 파일이나 디렉터리만 수정 가능해야 한다. 전체 저장소 쓰기 권한은 대부분 과하다.
command scope를 나눈다
빠르고 국소적인 검증 명령과, 위험하거나 비용이 큰 명령을 같은 수준으로 두면 안 된다.
irreversible action은 분리한다
배포, 데이터 변경, 외부 write, destructive action은 반드시 별도 gate나 사람 승인을 거쳐야 한다.
tool surface를 최소화한다
도구가 많을수록 문제 해결력이 커질 수는 있다. 하지만 우회 표면도 같이 늘어난다. 필요한 도구만 열어두는 편이 안정적이다.
어떤 경계를 특히 먼저 잠가야 하는가
- broad file write
- destructive shell command
- production-like environment 변경
- secret / credential 접근
- 승인 없는 external side effect
이 표면은 한 번 잘못 열리면 실수 비용이 훨씬 더 커진다.
capability boundary와 task contract의 관계
둘은 비슷해 보이지만 다른 층이다.
- capability boundary 애초에 무엇이 가능한가를 제한한다
- task contract 그 안에서 이번 작업이 어디까지 허용되는가를 정의한다
예를 들어
src/feature-a/**만 쓸 수 있는 capability boundary가 있고,
그중에서도 feature-a/service.ts와 feature-a/test.ts만 만지는 task contract가 있을 수 있다.
즉 boundary가 바깥 경계고, contract가 그 안의 현재 작업 경계다.
나쁜 capability boundary 패턴
- 전체 저장소 write를 기본값으로 둔다
- 위험 명령과 안전 명령을 같은 수준으로 취급한다
- 승인이 필요한 action과 아닌 action을 섞는다
- 프로토타이핑 때 열어둔 권한을 계속 유지한다
- 권한 범위를 문서로만 말하고 시스템이 실제로 막지 않는다
이런 구조에서는 task contract가 좋아도 행동 반경이 너무 넓어 쉽게 무너진다.
AI 코딩에서 왜 더 중요해지는가
사람은 넓은 권한을 갖고도 자제할 수 있다. AI는 넓은 권한을 더 자주 탐색한다.
- 가까운 해결 경로처럼 보이면 바로 시도하고
- 한번 성공한 우회는 더 쉽게 반복하고
- 승인 경계가 흐리면 스스로 결정하려 든다
그래서 AI 환경에서는 capability boundary가 사실상 prompt보다 먼저 작동하는 control이다.
실무 질문
- write scope가 task와 무관한 파일까지 열려 있지 않은가
- 위험 명령과 안전 명령이 같은 층에 있지 않은가
- destructive / external side effect는 별도 승인 경계를 가지는가
- 권한 경계가 문서가 아니라 실제 도구/환경으로 강제되는가
- 프로토타입 시절의 과도한 권한이 아직 남아 있지 않은가
요약
좋은 capability boundary는 다음을 만족한다.
- write scope가 좁고
- command / tool surface가 최소화되며
- irreversible action이 별도 경계로 분리되고
- 실제 시스템에서 강제된다
하네스의 AI 적용에서 capability boundary는 사후 교정 수단이 아니라, 애초에 잘못된 시도를 줄이는 첫 번째 울타리다.