코덱스 툴 사용법 08: 권한 프로필로 작업 경계 잡기 | DAKER 커뮤니티

코덱스 툴 사용법 08: 권한 프로필로 작업 경계 잡기

코덱스를 잘 쓰는 사람은 프롬프트를 길게 쓰는 사람이 아니라, 작업 경계를 잘 닫는 사람이다. "이거 고쳐줘"라고만 하면 코덱스는 파일을 읽고, 수정하고, 명령을 실행하면서 필요한 경로를 찾아간다. 이 능력이 강점이지만, 동시에 권한을 넓게 열어 두면 원하지 않는 파일 변경이나 외부 영향까지 따라올 수 있다.

OpenAI 공식 Codex 매뉴얼 기준으로 Codex에는 :read-only, :workspace, :danger-full-access 세 가지 기본 권한 프로필이 있다. 읽기 전용은 로컬 명령 실행을 읽기 중심으로 제한하고, 워크스페이스는 활성 작업 폴더 안의 쓰기를 허용하며, 전체 접근은 로컬 샌드박스 제한을 제거하므로 그 넓은 접근이 의도된 경우에만 써야 한다.

아래 Mermaid 다이어그램은 권한 선택을 작업 범위 기준으로 나누는 흐름이다. 게시 본문에서는 같은 판단 흐름을 SVG 시각 자료와 함께 읽으면 된다.

1. 권한은 속도 설정이 아니라 변경 범위 설정이다

권한 프로필을 "빠른 모드"와 "느린 모드"로 보면 위험하다. 실제 기준은 코덱스가 어디까지 읽고, 어디까지 쓰고, 어떤 명령을 실행할 수 있어야 하는지다.

처음 보는 저장소에서 구조를 파악하거나 리뷰만 맡길 때는 읽기 전용이 맞다. 테스트 추가, 작은 버그 수정, 문서 보강처럼 프로젝트 안에서 끝나는 작업은 워크스페이스 권한이 맞다. 홈 디렉터리 설정, 여러 저장소, 시스템 도구, 로컬 샌드박스 밖 파일을 건드려야 하는 작업은 영향 범위가 커지므로 별도 격리와 중지 조건을 먼저 정해야 한다.

2. 처음 요청은 읽기 전용으로 시작해도 충분하다

코덱스에게 바로 수정을 맡기기 전에 "수정하지 말고 먼저 읽어줘"라고 시키면 품질이 올라간다.

이 저장소의 결제 실패 처리 흐름을 읽고,
관련 파일 5개 이하와 위험한 수정 지점만 정리해줘.
아직 파일은 수정하지 말고, 검증에 쓸 테스트 명령도 같이 제안해줘.

이 요청은 코덱스의 탐색 능력을 살리면서 쓰기 위험을 닫는다. 특히 오래된 프로젝트, 테스트가 부족한 프로젝트, 여러 앱이 섞인 모노레포에서는 먼저 읽는 시간이 실제 수정 시간을 줄인다.

3. 일반 개발 작업은 워크스페이스 권한으로 좁힌다

대부분의 바이브코딩 작업은 워크스페이스 안에서 끝난다. 프론트엔드 컴포넌트 수정, API 핸들러 버그 수정, 테스트 보강, README 업데이트가 여기에 해당한다.

좋은 프롬프트는 쓰기 범위를 같이 적는다.

로그인 실패 메시지가 비어 보이는 문제를 고쳐줘.
수정 범위는 이 프로젝트 안으로 제한하고, 인증 설정 파일과 환경 변수 파일은 건드리지 마.
변경 후 관련 테스트를 실행하고, 실패하면 원인과 다음 조치만 보고해줘.

여기서 중요한 문장은 "건드리지 마"와 "변경 후 관련 테스트"다. 코덱스는 작업을 끝내기 위해 주변 파일을 넓게 읽을 수 있지만, 쓰기 범위와 검증 기준이 좁으면 diff가 작고 리뷰하기 쉬워진다.

4. 전체 접근은 의도와 환경을 같이 적는다

:danger-full-access는 이름 그대로 조심해야 한다. 공식 매뉴얼은 이 프로필이 로컬 샌드박스 제한을 제거한다고 설명한다. 그래서 "귀찮으니 전체 권한"이 아니라 "격리된 환경에서 이 범위까지 필요하다"는 식으로 써야 한다.

예를 들어 임시 VM, 깨끗한 컨테이너, 버려도 되는 복제 저장소에서 대규모 마이그레이션을 돌리는 경우에는 넓은 접근이 필요할 수 있다. 그래도 프롬프트에는 다음을 넣는다.

이 작업은 버려도 되는 복제 저장소에서만 수행한다.
홈 디렉터리, SSH 키, 브라우저 프로필, 실제 운영 자격 증명은 읽거나 쓰지 마.
패키지 설치와 빌드 캐시 정리는 허용하지만, 배포 명령은 실행하지 마.
완료 기준은 테스트 통과와 diff 요약이다.

전체 접근은 권한 문제가 아니라 책임 범위 문제다. 권한을 넓히는 순간, 하지 말아야 할 일을 더 명확히 써야 한다.

5. AGENTS md와 권한 프로필을 함께 쓴다

권한 프로필은 실행 경계이고, AGENTS.md는 프로젝트의 작업 계약이다. 예를 들어 "환경 변수 파일은 읽지 않는다", "마이그레이션은 별도 승인 없이는 실행하지 않는다", "테스트 없이 완료 보고하지 않는다" 같은 규칙은 AGENTS.md에 남겨두면 반복 작업에서 효과가 크다.

코덱스에게는 이렇게 말할 수 있다.

먼저 AGENTS.md를 읽고 이 작업에 적용되는 규칙을 요약해줘.
그다음 워크스페이스 안에서만 수정하고,
AGENTS.md의 검증 규칙에 맞춰 완료 여부를 판단해줘.

이렇게 하면 권한 프로필과 프로젝트 규칙이 서로 보완된다. 권한은 "어디까지 할 수 있는가"를 막고, 지침은 "어떻게 해야 하는가"를 정한다.

6. 완료 보고에는 권한과 검증을 같이 남긴다

코덱스 작업 보고는 "수정했습니다"보다 아래처럼 닫히는 편이 낫다.

권한 범위: 워크스페이스 안의 파일 수정만 수행
변경 파일: src/auth/login.ts, tests/auth/login.test.ts
건드리지 않은 영역: 환경 변수, 배포 설정, DB 마이그레이션
검증: npm test -- auth/login 통과
남은 위험: 실제 SSO 공급자 연동은 스테이징 계정에서 별도 확인 필요

이 형식이면 리뷰어가 diff뿐 아니라 작업 경계까지 확인할 수 있다. 권한 범위가 보고에 남으면 다음 작업에서 어디부터 이어가야 하는지도 분명해진다.

7. 실무에서는 세 단계로 외우면 된다

코덱스 권한 운영은 복잡하게 생각할 필요가 없다.

처음 보는 문제는 읽기 전용으로 조사한다.
일반 수정은 워크스페이스 안에서 작게 바꾸고 바로 검증한다.
전체 접근은 격리된 환경, 금지 영역, 중지 조건을 적은 뒤에만 쓴다.

이 세 단계만 지켜도 코덱스가 "알아서 고치는 도구"에서 "경계를 알고 일하는 작업자"에 가까워진다.

Senior takeaway: 코덱스 권한 프로필은 생산성을 늦추는 안전장치가 아니라, 리뷰 가능한 작업 단위를 만드는 설계 도구다. 읽기 전용으로 맥락을 잡고, 워크스페이스에서 작게 고치고, 전체 접근은 의도된 격리 환경에만 쓰면 바이브코딩의 속도와 팀 개발의 통제력을 함께 가져갈 수 있다.