코딩 에이전트를 팀 업무에 붙일 때 가장 먼저 부딪히는 문제는 모델 성능이 아니다. 권한을 어디까지 줄지, 언제 승인을 요구할지, 실패했을 때 어떤 범위까지만 영향이 퍼지게 할지가 더 큰 운영 이슈가 된다. 특히 에이전트가 파일을 읽고 쓰고, 테스트를 돌리고, 필요하면 외부 도구까지 만질 수 있게 되는 순간부터는 “잘 코딩하느냐”보다 “어디까지 행동할 수 있느냐”가 품질을 결정한다.
OpenAI가 Windows sandbox를 설명한 배경도 여기에 있다. 매번 승인만 누르게 만들면 자동화는 느려지고, 반대로 풀액세스를 바로 열면 위험 범위가 너무 커진다. 실무에서 필요한 것은 둘 중 하나를 고르는 일이 아니라, 작업 단계별로 권한 경계와 승인 시점을 다르게 설계하는 일이다.
메인 허브 글인 MCP 보안 체크리스트 실전 가이드: n8n·Codex·Computer Use를 운영 전에 어떻게 검증할까에서 전체 맥락을 다뤘다면, 이 글은 그중에서도 Codex 같은 코딩 에이전트 운영 기준에 집중한다.
왜 승인 과다와 풀액세스가 둘 다 문제일까
승인을 너무 자주 요구하면 사람은 금방 맥락을 잃는다. 어떤 액션이 왜 위험한지보다, 또 하나의 팝업으로 느끼게 된다. 이 상태가 되면 승인은 통제가 아니라 형식이 된다. 반대로 풀액세스를 열어 두면 에이전트가 편해지지만, 실수 한 번의 영향 범위가 과도하게 커질 수 있다. 디렉터리 전체 수정, 민감한 파일 접근, 외부 명령 실행이 같은 수준으로 허용되면 복구도 어려워진다.
즉 문제는 승인 횟수가 아니다. 승인 의미가 흐려지는 것이다. 팀이 잡아야 할 기준은 “이 액션이 어떤 경계를 넘는가”다.
샌드박스 설계는 권한 거절이 아니라 경계 설계다
샌드박스라는 말을 들으면 종종 무조건 제한하는 구조로 이해한다. 하지만 실무적으로는 반대에 가깝다. 샌드박스는 에이전트가 반복적으로 일할 수 있게 하되, 사고가 나도 영향 범위를 좁히는 장치다. 즉 속도를 포기하는 구조가 아니라, 속도를 감당 가능한 범위에 가두는 구조다.
코딩 에이전트 운영에서 샌드박스 경계는 대체로 네 층으로 나눠 볼 수 있다.
- 읽기 경계: 어떤 코드와 설정을 볼 수 있는가
- 쓰기 경계: 어떤 디렉터리와 파일만 수정할 수 있는가
- 실행 경계: 어떤 테스트나 빌드 명령만 실행할 수 있는가
- 외부 경계: 네트워크, 배포, 원격 시스템 접근을 어느 수준까지 허용할 것인가
이 네 층을 분리해 두면 모든 액션을 같은 위험도로 취급하지 않아도 된다. 예를 들어 읽기는 비교적 넓게 허용하더라도, 쓰기는 특정 워크스페이스로 제한하고, 외부 경계는 별도 승인으로 묶는 식의 운영이 가능하다.
승인은 “사용자 경험”이 아니라 상태 전이로 설계해야 한다
많은 팀이 승인 기능을 UI 상의 편의 요소처럼 다룬다. 하지만 운영 자동화에서는 승인도 상태 전이다. 예를 들어 초안 작성, 수정안 준비, 테스트 완료, 승인 대기, 외부 반영처럼 단계가 나뉘어야 한다. 그래야 사람이 무엇을 검토하는지 이해할 수 있고, 에이전트도 승인 전까지 무엇을 끝내 둬야 하는지 분명해진다.
좋은 승인 설계는 아래 특징을 가진다.
- 승인 요청 시점이 일관된다.
- 승인 없이 가능한 준비 작업 범위가 넓다.
- 승인 후 실행되는 액션 목록이 짧고 명확하다.
- 승인 거절 후 재작업 경로가 정의돼 있다.
이 기준이 없으면 에이전트는 사소한 수정마다 승인을 묻거나, 반대로 마지막 순간까지 너무 많은 준비를 진행해 버린다.
팀이 먼저 정해야 할 네 가지 정책
Codex 운영을 안정화하려면 모델 설정 전에 아래 정책부터 문서화하는 편이 낫다.
1. 기본 쓰기 범위
어떤 폴더가 에이전트 기본 수정 범위인지 정해야 한다. 실험 폴더, 생성 산출물, 검토 대상 디렉터리처럼 안전한 구역부터 허용하는 것이 좋다.
2. 고위험 액션 정의
배포, 시크릿 접근, 권한 변경, 파괴적 명령처럼 반드시 별도 승인이 필요한 액션을 미리 나열해야 한다. 이 목록은 짧을수록 좋지만 흐려지면 안 된다.
3. 테스트와 검증 기준
승인 요청 전에 어떤 테스트나 정적 검사를 통과해야 하는지 정해야 한다. 사람이 보는 것은 코드 전체가 아니라 “최소 검증을 통과한 변경”이어야 한다.
4. 감사 흔적
어떤 파일을 읽고, 무엇을 수정했고, 어떤 명령을 실행했는지 복기 가능한 흔적이 필요하다. 샌드박스는 막는 장치이기도 하지만, 설명 가능한 운영 장치이기도 하다.
풀액세스를 열기 전에 던져야 할 질문
팀이 풀액세스를 고려할 때는 보통 속도가 이유다. 하지만 실제로는 아래 질문에 답하지 못하면 속도보다 되돌림 비용이 커진다.
- 이 에이전트가 접근하면 안 되는 경로가 분명한가.
- 실수 시 되돌릴 수 없는 액션이 무엇인지 합의돼 있는가.
- 승인 없이 진행 가능한 작업과 아닌 작업이 구분돼 있는가.
- 실패 원인을 실행 로그만으로 추적할 수 있는가.
- 사람 검토 없이 외부 시스템 상태를 바꾸는 액션이 남아 있지 않은가.
이 질문에 답이 없다면, 풀액세스는 생산성 기능이 아니라 운영 부채가 된다.
실무 적용 순서
한국 팀 환경에서는 처음부터 정교한 정책 엔진을 두기보다 아래 순서가 현실적이다.
- 읽기 범위를 먼저 넓히고 쓰기 범위는 좁게 시작한다.
- 테스트 실행은 허용하되 외부 반영 액션은 별도 승인으로 둔다.
- 승인 요청 포맷을 고정해 검토 비용을 줄인다.
- 실패 시 재개 지점과 롤백 기준을 함께 적는다.
- 반복적으로 안전성이 확인된 액션만 점진적으로 자동 승인 범위에 넣는다.
이렇게 가면 승인 지옥도 피하고, 무리한 풀액세스도 피할 수 있다. 핵심은 권한을 많이 주느냐 적게 주느냐가 아니라, 어떤 경계를 기준으로 점진적으로 신뢰를 쌓느냐다. 코딩 에이전트가 길게 일하게 하려면 자유보다 먼저 경계가 필요하다.