다운로드 폴더가 어지럽다고 곧바로 Cursor에 통째로 맡겨도 될까? 이번 실험에서는 가짜 파일 10개를 이미지·PDF·텍스트·기타 폴더로 정리하는 스크립트를 만들었다. 생성된 스크립트는 코드 수정 없이 이번 세션의 규칙에 따라 가짜 파일 10개를 모두 정확히 옮겼다. 이번 세션에서는 결과를 완료로 판단하기 전에 연습 폴더 → 계획 → 미리보기 → 실행 → 검증의 다섯 단계를 차례로 확인했다.
이 결과는 인간 초보자의 사용성 시험이 아니다. AI 코딩 에이전트인 Codex가 한 Mac에서 합성 파일로 수행한 단일 세션이다. 따라서 “비개발자는 모두 여기서 막힌다”가 아니라, 실제 파일을 맡기기 전에 무엇을 확인해야 하는지 보여주는 사례로 읽어야 한다.

이 글의 목차
1. 원본 대신 연습 폴더를 연다
실험에는 개인 사진이나 업무 문서를 쓰지 않았다. 별도 작업 공간에 내용까지 전부 가짜인 파일 10개를 만들고, Cursor에서 그 격리 작업 공간을 열어 진행했다. 실제 Downloads 전체를 열면 AI가 읽거나 명령을 실행할 수 있는 범위도 함께 넓어진다. Cursor 공식 설명에 따르면 Agent는 파일을 읽고 편집할 뿐 아니라 터미널 명령도 실행할 수 있다.
처음이라면 원본이 아니라 복사본 5~10개로 연습하는 편이 낫다.
2. Plan에서 ‘정리’의 뜻부터 정한다
처음 요청은 “계획만 만들고 파일과 터미널은 건드리지 말라”였다. Plan Mode 문서는 코드를 쓰기 전에 작업 폴더를 살펴보고 질문과 계획을 만드는 흐름을 설명한다.
Plan Mode 선택만으로 실행 차단을 가정하지 않고, 이번 요청에는 파일 변경과 터미널 실행 금지를 따로 적었다.
Cursor는 두 가지를 되물었다.
- 결과 폴더를
inbox안에 둘까, 작업 공간 맨 위에 둘까? - 확장자 없는
README와archive.zip은 텍스트일까, 기타일까?
“파일을 정리해 줘”만으로는 정답이 없다는 뜻이다. 목적지, 같은 이름 처리, 확장자 없는 파일, 하위 폴더 규칙을 먼저 말로 정해야 한다. 이번에는 네 결과 폴더를 inbox 안에 만들고, .txt만 Text로 보내며 나머지 미지원 파일은 Other에 보존하기로 했다.
3. 실행 전에 dry-run을 읽는다
계획을 확인한 뒤 파일 작성과 명령 실행이 가능한 Build 모드로 바꾸되 실제 이동은 금지하고, 먼저 아래 미리보기만 요청했다.
python3 organize_inbox.py --dry-run
dry-run은 무엇을 어디로 옮길지 보여주되 파일은 바꾸지 않는 예행연습이다. 출력에는 예정 이동 10건과 다른 위치의 파일을 가리키는 바로가기 같은 심볼릭 링크 1건을 건너뛴다는 결과가 나왔다. 같은 이름의 파일은 숫자 접미사로 둘 다 보존하고, README와 .zip은 Other로 보낼 계획이었다. Cursor와 별도로 실행한 검증에서도 대상 파일은 그대로였다.
다만 명령 옆에 잠시 Delete attempted(삭제 시도됨)라는 표시가 나타났다. 이유는 확인하지 못했다. 실제 삭제는 없었지만, 이런 표시가 보일 때 모델의 설명만 믿고 넘어가서는 안 된다. 이 표시의 의미를 실제 파일 상태로 확인하기 전에는 실제 이동을 요청하지 않는 편이 안전하다. 이번 세션의 삭제 없음 판정은 독립 검증 결과다. 출발지·목적지·파일 수·제외 항목 설명은 별도의 dry-run 범위 확인 기준이다.
4. 범위를 확인한 뒤 복사본에서 실행한다
실제 실행은 명령이 오류 없이 끝났다는 신호인 종료 코드 0을 반환했고, 파일 10개를 옮기고 심볼릭 링크 1건을 건너뛰었다. 명령을 실행해도 되는지 Cursor가 자동으로 판별하는 설정인 Auto-review가 켜진 이 세션에서 명령은 승인 버튼 클릭 없이 실행됐다. Run Modes 문서도 Auto-review가 보안 경계는 아니며 자동 판별이 틀릴 수 있다고 경고한다.
따라서 “위험하면 Cursor가 반드시 물어볼 것”이라고 기대하면 안 된다. 실행 요청을 보내는 행위 자체를 승인으로 보고, 그 전에 dry-run의 범위가 맞는지 확인해야 한다.
5. 성공 메시지 대신 파일 상태를 확인한다
종료 코드 0은 명령이 오류 없이 끝났다는 뜻일 뿐, 결과가 맞다는 보장은 아니다. 이번에는 별도 정답표와 검증기로 다음을 확인했다.
- 가짜 파일 10개가 정해 둔 네 범주 중 하나에만, 빠지거나 중복되지 않고 존재했다.
- 파일 내용의 지문 값인 해시가 10/10 보존됐다.
- 같은 이름의 두 파일이 덮어써지지 않았다.
inbox밖에 일부러 둔, 건드리면 안 되는 확인용 파일과 심볼릭 링크가 바뀌지 않았다.- 같은 명령을 다시 실행했을 때 추가 이동이 0건이었다.
심볼릭 링크 대상을 단순히 읽었는지까지는 탐지하지 못했다. 그래도 실제 사용자는 원본을 남기고, 미리보기와 실행 후의 파일 수를 비교하고, 같은 이름이 둘 다 살아 있는지 확인하는 것부터 시작할 수 있다. Agent의 마지막 문장보다 실제 파일 상태를 완료 기준으로 삼는 것이 핵심이다.
이 사례에서 권하는 확인 순서
- 원본이 아닌 복사본 5~10개로 연습 폴더를 만든다.
- Plan에서 “계획만, 파일 변경과 터미널 실행 금지”라고 쓴다.
- 목적지·중복 이름·확장자 없는 파일·하위 폴더 규칙을 답한다.
- “덮어쓰기·삭제 금지, 심볼릭 링크 건너뛰기”를 명시한다.
- Build에서 스크립트와
--dry-run까지만 요청한다. - 미리보기의 출발지·목적지·건수·제외 항목을 확인한다.
- 범위가 맞으면 복사본에서 실제 실행을 한 번 요청한다.
- 실행 후 파일 수와 같은 이름 파일이 모두 남았는지 확인한 뒤, dry-run을 다시 실행해 추가 예정 이동이 0건인지 본다.
실험에서는 두 번째 실제 실행으로 추가 이동 0건을 확인했다. 위 권고는 독자가 불필요한 실제 재실행 대신 dry-run으로 다시 확인하도록 더 좁힌 절차다.
참고: 이번 실험의 조건과 기술적 한계
- 기준일: 합성 실험 2026년 9월 2일, 공식 문서 재확인 2026년 9월 6일
- 환경: Cursor 3.18.25,
Cursor Grok 4.6 Medium, Apple Silicon Mac - 로그인: 로그인 전 시도는
Log In과Sign Up화면에서 멈췄고, 계정 소유자가 로그인한 뒤 별도 세션에서 재개. 절차의 난이도와 시간은 미측정 - 결과: 자연어 메시지 5회, 추가 질문 2개, 코드 수정 요청 0회, 기능 오류 0회
- Cursor 표시 Agent 작업 시간: 8분 31초. 설치·사용자 로그인·독립 검증 시간은 제외
- 판정: 이 합성 파일 10개에 한정해 첫 실행 성공, 분류 10/10, 두 번째 실행 추가 이동 0건
.cursorignore는 AI 문맥에서 파일을 제외하지만 Agent의 터미널·외부 도구 접근까지 막는 경계는 아니다.- Privacy Mode 설명에서 학습에 쓰지 않는다는 말은 파일 내용이 Cursor 서버를 거치지 않는다는 뜻이 아니다. 이번 세션에서는 Privacy Mode 활성 여부를 측정하지 않았다.
- Checkpoint는 Agent 변경용 로컬 복원 지점이지 완전한 백업이나 Git 대체물이 아니다. 이번 세션에서는 복원을 시험하지 않았다.
이 세션에서 코드 수정 요청은 0회였다. 그 뒤에도 확인할 대상은 남았다. 작게 격리하고, 계획을 읽고, 미리 본 뒤, 실제 파일 상태를 확인하는 순서다.
이 글은 AI를 활용해 자료 조사와 초안 작성을 보조하고, 작성자가 직접 검증·편집했습니다.
댓글 남기기