권한 계단: 읽기 전용에서 수정까지 한 칸씩

2026년 5월 20일 | 바이브코딩 Tips

---

코딩 에이전트에게 쓰기 권한을 바로 열면, 문제 해결 속도보다 실패 반경이 먼저 커질 때가 있다. 처음에는 작은 버그 하나를 보라고 했는데, 어느새 파일 다섯 개가 바뀌고 테스트 이름까지 정리되어 있는 식이다. 결과가 맞으면 다행이지만, 틀렸을 때는 어디서부터 되돌려야 하는지 애매해진다. 나는 이때 “에이전트가 과하게 고쳤다”라고만 생각했는데, 곰곰이 보면 내가 권한을 너무 한 번에 열어 준 경우가 많았다.

그래서 바이브코딩을 오래 굴릴수록 권한 계단을 먼저 둔다. 읽기 전용, 패치 제안, 좁은 수정, 독립 검증, 인수인계처럼 권한을 한 칸씩 올리는 방식이다. 거창한 보안 모델은 아니다. 다만 에이전트가 지금 할 수 있는 일을 작게 고정해 두면, 좋은 방향으로 빠르게 움직일 때와 이상한 방향으로 번질 때를 훨씬 빨리 구분할 수 있다.

Figure 1. 권한 계단은 읽기 전용에서 시작해 수정, 검증, 인수인계까지 권한을 단계별로 열어 실패 반경을 작게 유지하는 운영 패턴이다.

1. 읽기 전용을 진짜 단계로 둔다

많은 작업에서 첫 번째 실수는 “확인해 보고 고쳐줘”라는 문장이다. 사람 입장에서는 자연스럽다. 확인도 하고, 고칠 게 있으면 고치면 된다. 그런데 에이전트에게는 이 문장이 읽기와 쓰기를 동시에 허용하는 신호가 된다. 로그를 다 읽기도 전에 가장 그럴듯한 파일을 열고, 그 자리에서 수정까지 들어갈 수 있다. 문제는 그 수정이 맞았는지 틀렸는지 판단할 근거가 아직 충분하지 않다는 점이다.

나는 이제 낯선 코드나 오래 안 본 프로젝트에서는 첫 턴을 일부러 읽기 전용으로 묶는다. “수정하지 말고 관련 파일과 실패 로그만 읽어라”, “원인 후보를 세 개까지 줄여라”, “바꿔야 할 파일을 추정하되 아직 edit하지 마라” 정도면 충분하다. 이 단계의 산출물은 해결책이 아니라 지도다. 지도가 있어야 다음 권한을 어디까지 열지 정할 수 있다. 읽기 전용 산출물이 짧더라도, 그 안에 실패 로그 위치, 의심 파일, 아직 모르는 가정이 분리되어 있으면 다음 단계가 훨씬 덜 흔들린다.

2. 패치 제안은 적용보다 앞에 둔다

두 번째 칸은 패치 제안이다. 여기서도 아직 실제 변경을 허용하지 않는다. 에이전트에게 “어느 파일의 어느 함수 근처를 바꾸고, 왜 그 변경이 필요한지”를 먼저 쓰게 한다. 코드 블록으로 완성 패치를 받는 날도 있지만, 핵심은 코드를 예쁘게 받는 것이 아니다. 사람이 읽을 수 있는 변경 의도를 먼저 받는 것이다. 이 의도가 실패 로그와 연결되지 않으면, 아직 수정 칸으로 올릴 때가 아니라고 본다.

이 칸을 두면 이상한 수정이 꽤 빨리 보인다. 에이전트가 실패 로그와 상관없는 파일을 고치려고 하거나, 테스트 공백을 구현 문제로 착각하거나, 작은 조건문 대신 구조 개편을 제안하는 순간이 드러난다. 그때 바로 edit을 막고 다시 읽기 전용으로 내릴 수 있다. 적용 전 제안은 속도를 늦추는 절차처럼 보이지만, 실제로는 잘못된 넓은 diff를 한 번 막아 주는 보험에 가깝다.

3. 수정 권한은 파일 수보다 경로로 묶는다

수정 단계로 넘어가면 허용 범위를 숫자로만 쓰지 않는다. “파일 두 개까지만 수정” 같은 제한은 없는 것보다 낫지만, 어떤 파일인지가 더 중요하다. 중심 파일, 인접 파일, 금지 경로, 확장이 필요한 경우의 멈춤 조건을 같이 둬야 한다. 파일 수가 하나여도 위험한 설정 파일일 수 있고, 파일 세 개여도 같은 컴포넌트 안에서 자연스러운 변경일 수 있기 때문이다.

내가 자주 쓰는 문장은 아래처럼 짧다. 길게 쓰면 계약서가 아니라 또 하나의 문서 일이 된다.

1차 권한: 읽기 전용으로 원인 후보와 수정 위치만 정리
2차 권한: app/components 안의 관련 파일 1~2개만 수정
확장 조건: 설정, 라우팅, 데이터 삭제 경로가 필요하면 멈추고 요청
검증 조건: 변경 후 실행한 확인과 아직 보지 않은 경로를 분리

여기서 중요한 줄은 확장 조건이다. 에이전트가 똑똑할수록 “이것도 같이 고치면 좋겠다”는 방향으로 번지기 쉽다. 그 자체가 나쁘지는 않다. 다만 번지는 순간을 사람이 볼 수 있어야 한다. 권한 계단은 에이전트를 덜 믿겠다는 장치가 아니라, 더 넓은 작업으로 넘어가는 문턱을 보이게 만드는 장치다.

4. 검증은 같은 권한으로 하지 않는다

수정이 끝난 뒤에도 같은 세션에게 바로 “검증까지 해줘”라고 던지면 판단이 흐려질 수 있다. 만든 쪽은 이미 자기 변경의 이유를 알고 있다. 그래서 검증 질문을 해도 자연스럽게 자기 설명을 방어하는 방향으로 읽는다. 작은 작업은 괜찮지만, 인증, 결제, 저장, 삭제, 배포처럼 실패 비용이 큰 경로에서는 검증 권한을 다시 낮추는 편이 낫다.

내 기준은 단순하다. 만든 세션은 변경 파일, 실행한 확인, 남은 위험을 남긴다. 확인 세션은 읽기 전용으로 그 묶음만 보고 PASS, HOLD, FAIL 중 하나를 낸다. FAIL이면 바로 큰 수정으로 돌아가지 않고, 실패 묶음으로 접어 다음 edit 권한을 다시 작게 연다. 이 구조가 있으면 “방금 만든 사람이 방금 통과시킨 결과”를 그대로 믿는 상황이 줄어든다.

5. 권한을 내리는 것도 진행이다

바이브코딩을 하다 보면 권한을 올리는 것만 진행처럼 느껴질 때가 있다. 읽기에서 수정으로, 수정에서 실행으로, 실행에서 배포로 올라가야 뭔가 되고 있는 것 같다. 그런데 실제로는 권한을 내리는 판단도 꽤 중요하다. 원인 후보가 흐리면 다시 읽기 전용으로 내리고, diff가 넓어지면 패치 제안 단계로 되돌리고, 검증이 애매하면 인수인계로 묶어 보류한다.

이걸 패배처럼 보면 계속 밀어붙이게 된다. 반대로 권한을 내리는 일을 정상적인 진행으로 보면 작업이 덜 무너진다. 나중에 다시 열 사람이 무엇을 봐야 하는지, 어디까지 허용됐는지, 어떤 조건에서 멈췄는지가 남기 때문이다. 권한 계단의 목적은 에이전트를 묶어 두는 데 있지 않다. 오히려 좋은 자동화가 계속 달릴 수 있는 난간을 세우는 일에 가깝다. 빠르게 만들되, 빠르게 되돌아올 수 있는 발판을 같이 두는 데 있다.

6. 작은 작업에는 두 칸만 써도 충분하다

물론 모든 작업을 다섯 칸으로 나눌 필요는 없다. 오타 수정이나 단일 테스트 이름 변경까지 읽기, 제안, 수정, 검증, 인수인계로 나누면 금방 피곤해진다. 작은 작업에서는 읽기 전용 한 칸과 좁은 수정 한 칸만으로 충분하다. 반대로 오래된 코드, 외부 API, 상태 저장, 데이터 삭제, 여러 파일 diff가 섞이면 계단을 더 잘게 나눈다.

나는 권한 계단을 프롬프트 기교보다 운영 리듬에 가깝게 본다. 에이전트가 잘할 때는 빨리 다음 칸으로 올리고, 이상한 냄새가 나면 한 칸 내린다. 이 정도만 해도 “일단 고쳐줘”로 시작해서 “왜 이렇게 많이 바뀌었지”로 끝나는 날이 줄어든다. 바이브코딩에서 필요한 건 매번 완벽한 지시문이 아니라, 권한이 커지는 순간을 사람이 놓치지 않는 감각에 더 가깝다.