AI가 "권한을 요청합니다"라고 할 때 실제로 벌어지는 일

새로 합류한 팀에서 레거시 결제 API를 새 SDK로 옮기는 작업을 맡았습니다. 파일이 200개가 넘어서, 이번엔 처음부터 AI 에이전트에게 마이그레이션 전체를 맡겨보기로 했습니다.
월요일 아침, 에이전트에게 "결제 모듈 전체를 새 SDK 문법으로 바꿔줘"라고 시켰습니다. 몇 분 지나지 않아 화면이 멈췄습니다.

AI가 갑자기 멈춰서 승인부터 구할 때, 권한 프롬프트의 정체

text
1다음 명령을 실행하시겠습니까?
2 rm -rf ./legacy-payment/*.old
3
4[y/n]
파일을 지우겠다는 요청은 저도 예상 못 한 부분이었습니다. 마이그레이션 스크립트를 짜달라고만 했지, 뭘 지우라고 시킨 적은 없었습니다.
공식 문서를 찾아보니 이유가 나와 있었습니다. 파일 삭제, 외부 네트워크 호출, 시스템 설정 변경처럼 되돌리기 번거로운 작업은 에이전트가 스스로 판단해서 멈추고 사람에게 확인을 구하도록 설계돼 있었습니다. AI가 눈치를 보는 게 아니라, 위험도가 일정 기준을 넘는 순간 자동으로 사람 손을 거치게 만든 장치였습니다.
위험도가 낮은 작업은 그대로 진행되고, 기준을 넘는 지점부터 승인 프롬프트가 뜨는 구조
위험도가 낮은 작업은 그대로 진행되고, 기준을 넘는 지점부터 승인 프롬프트가 뜨는 구조
승인 요청을 거절하고 이유를 다시 물었더니, 이번엔 삭제 대신 파일을 .old 확장자로 이름만 바꾸는 방식으로 진행했습니다. 파일을 지우지 않고도 작업은 끝났습니다.
문제는 그다음이었습니다. 승인한 명령이 실제로 실행되기 전에, 뭔가 한 겹을 더 거친다는 걸 알게 됐습니다.

rm 명령을 승인했는데 파일이 멀쩡할 때, 샌드박스가 하는 일

같은 팀 동료의 지난 PR을 훑어보다가 .claude/settings.json에 이런 설정이 있는 걸 발견했습니다.
json
1{
2 "sandbox": {
3 "bash": "restricted",
4 "network": "deny"
5 }
동료에게 물어보니, 이 설정 덕분에 에이전트가 실행하는 명령이 실제 프로젝트 폴더가 아니라 격리된 임시 환경에서 먼저 돌아간다고 했습니다. 결과가 안전하다고 확인된 다음에야 진짜 파일에 반영되는 구조였습니다.
모의 계좌로 먼저 이체를 걸어보고 문제가 없을 때만 실제 계좌로 보내는 것과 같은 순서였습니다. 명령 자체는 그대로 실행되지만, 실제 자원에 닿기 전에 안전한 방에서 한 번 걸러지는 셈입니다.
명령이 실제 폴더에 닿기 전, 격리된 층 안에서 먼저 실행되고 검증되는 구조
명령이 실제 폴더에 닿기 전, 격리된 층 안에서 먼저 실행되고 검증되는 구조
덕분에 마이그레이션 스크립트가 중간에 잘못된 경로를 지웠어도, 실제로 사라진 파일은 하나도 없었습니다. 화요일이 그렇게 지나갔고, 수요일엔 스크립트를 절반쯤 되돌리고 싶은 일이 생겼습니다.

마이그레이션을 절반쯤 갈아엎고 싶을 때, 체크포인트로 돌아가는 법

결제 모듈 중 한 곳을 잘못된 방향으로 너무 많이 고쳐놨다는 걸 뒤늦게 알았습니다. 되돌리려고 화면을 보는데, 에이전트가 스스로 이런 메시지를 띄운 게 눈에 들어왔습니다.
text
1Checkpoint saved: before-refactor-payment-v2
217 files changed
제가 되돌리기 기능을 요청한 적은 없었는데, 큰 변경 작업 직전마다 이런 저장 지점이 자동으로 남고 있었습니다. 작업이 커질 때마다 되돌아갈 지점을 미리 찍어두는 방식이라, "여기로 돌아가줘"라고만 말하면 그 시점의 코드로 정확히 복원됐습니다.
큰 변경 직전마다 자동으로 저장된 지점 중 하나를 골라 그대로 되돌아가는 구조
큰 변경 직전마다 자동으로 저장된 지점 중 하나를 골라 그대로 되돌아가는 구조
체크포인트가 없었다면 잘못된 부분만 손으로 골라내며 되돌려야 했을 겁니다. 시간을 많이 잡아먹었을 일이 명령 한 줄로 끝났습니다.
저녁 무렵, 노트북 화면에 저장 지점 목록이 나열되고 커서가 하나를 가리키는 장면
결제 모듈은 정리됐는데, 목요일이 되니 다른 문제가 생겼습니다. 알림 모듈도 같이 손봐야 하는데, 결제 모듈 브랜치를 아직 마무리 못 한 상태였습니다.

브랜치 두 개를 동시에 손대야 할 때, 워크트리 격리가 필요한 이유

예전에 비슷한 상황에서 남겨둔 메모가 있었는지 찾아보다가, 프로젝트 폴더 옆에 낯선 디렉터리가 하나 있는 걸 발견했습니다.
bash
1$ ls ../
2payment-migration/
3payment-migration-notify/ # 지난달에 만들어놓고 잊고 있던 폴더
한 달 전, 비슷하게 두 작업을 동시에 진행해야 했을 때 만들어놓고 까맣게 잊고 있던 작업 공간이었습니다. 같은 저장소인데도 브랜치별로 폴더 자체를 분리해두면, 한쪽 작업 파일이 다른 쪽에 전혀 안 섞입니다.
같은 집 안에 방을 하나 더 만들어서, 이사하지 않고도 다른 프로젝트를 그 방에서 진행하는 것과 비슷합니다. 저장소를 통째로 복제할 필요 없이, 폴더만 하나 더 열어서 다른 브랜치를 그 자리에서 바로 작업할 수 있었습니다.
한 저장소 안에서 브랜치를 체크아웃만 할 때와 워크트리로 폴더째 분리할 때의 차이
한 저장소 안에서 브랜치를 체크아웃만 할 때와 워크트리로 폴더째 분리할 때의 차이
알림 모듈용 폴더를 새로 하나 열어서 결제 모듈 작업을 방해하지 않고 병행했습니다. 그렇게 한 주를 거의 다 썼는데, 금요일 오후엔 에이전트가 조금 이상하게 굴기 시작했습니다.

에이전트가 앞서 한 말을 자꾸 잊어버릴 때, 컨텍스트 소진의 신호

월요일에 정해둔 명명 규칙을 다시 설명해달라고 하니, 이미 여러 번 알려준 내용을 처음 듣는 것처럼 되물었습니다. 한 번은 그러려니 했는데, 비슷한 일이 계속 반복됐습니다.
text
1Compacting conversation...
2Compacting conversation...
3Compacting conversation...
화면 구석에 뜨는 이 메시지가 매번 지나칠 정도로 자주 나온다는 걸 알아채고 나서야 연결이 됐습니다. 일주일치 대화와 파일 내용이 쌓이면서, 에이전트가 한 번에 들고 있을 수 있는 기억의 한도에 가까워지고 있었습니다. 한도에 닿으면 오래된 세부 내용부터 요약하거나 밀어내며 공간을 확보합니다. 그 과정에서 초반의 자잘한 규칙이 흐려집니다.
책상 위에 자료를 계속 쌓다 보면 어느 순간 오래된 서류부터 상자에 넣어 치우게 됩니다. 다 없어지는 건 아니지만, 당장 눈에 보이는 자리에서는 밀려납니다.
대화가 쌓여 한도에 가까워지면 오래된 내용부터 압축해 공간을 만드는 순환 구조
대화가 쌓여 한도에 가까워지면 오래된 내용부터 압축해 공간을 만드는 순환 구조
한 주를 마무리하며 명명 규칙을 규칙 파일에 다시 적어두고, 다음 주는 새 세션으로 시작하기로 했습니다. 기억이 흐려지는 걸 막을 수는 없어도, 중요한 규칙은 매번 다시 말하는 대신 파일에 박아두면 된다는 걸 알게 됐습니다.
금요일 오후, 어수선한 책상과 정리된 메모장이 나란히 놓인 장면

자주 묻는 질문

권한 프롬프트가 뜰 때마다 무조건 승인해도 되나요?

아닙니다. 삭제나 외부 호출처럼 되돌리기 어려운 작업일수록 왜 필요한지 한 번 더 확인하는 게 안전합니다. 다만 반복되는 익숙한 작업이라면 설정에서 특정 명령을 미리 허용해두고 매번 묻지 않게 할 수도 있습니다.

워크트리를 여러 개 만들면 디스크 용량이 그만큼 늘어나나요?

파일을 완전히 복제하는 것보다는 적게 늘어납니다. 다만 브랜치마다 별도 폴더가 생기는 구조라 완전히 공짜는 아니라서, 작업이 끝난 워크트리는 주기적으로 정리하는 게 좋습니다.

컨텍스트가 소진되면 이전 작업 내용을 완전히 잃게 되나요?

완전히 사라지기보다는 요약되거나 뒤로 밀려나는 쪽에 가깝습니다. 다만 세부 조건이나 자잘한 규칙처럼 요약 과정에서 빠지기 쉬운 내용은 규칙 파일이나 메모에 별도로 남겨두는 게 안전합니다.

<a href="/glossary/code-generation" class="glossary-link" title="AI가 자연어 설명이나 기존 코드 문맥을 바탕으로 프로그래밍 코드를 자동으로 작성하는 기술입니다.">AI 코딩</a> 도구 용어 사전 연작의 2편입니다. 다음 편 예고 · 3편 에이전트를 껐는데도 터미널에 뭔가 계속 돌고 있을 때 좀비 태스크 · 고아 프로세스 · 에이전트 스웜 · 바이너리 · 의존성

관련 글