Cursor AI Composer 멀티파일 수정 및 에이전트 모드 사용법

Cursor AI Composer 멀티파일 수정 및 에이전트 모드 사용법

Cursor AI Composer 멀티파일 수정 및 에이전트 모드 사용법

단순한 코드 추천을 넘어 폴더 전체를 고치는 도구

기존 Chat 창에서 코드를 짜 달라고 하면 복사해서 직접 붙여넣어야 했습니다. 파일이 한두 개일 때는 괜찮지만, 여러 파일의 인터페이스를 한꺼번에 수정해야 할 때는 작업이 꽤 번거로웠구요. Cursor의 Composer 기능은 이 과정을 훨씬 매끄럽게 이어 줍니다. 명령을 입력하면 관련 파일을 찾아서 알아서 수정해 놓거든요.

직접 돌려보면 에디터가 파일을 열고 스스로 타이핑하는 모습을 실시간으로 볼 수 있습니다. 2026년 기준 Cursor 에디터에서 가장 생산성이 높은 기능이라고 해도 크게 어색하지 않죠. 처음에는 단축키가 헷갈려 일반 Chat과 혼동하기 쉽지만, 한 번 손에 익으면 개발 속도가 확실히 빨라집니다.

에디팅 모드와 에이전트 모드의 실질적인 차이점

에디팅 모드와 에이전트 모드의 실질적인 차이점

Composer에는 크게 Edit 모드와 Agent 모드 두 가지가 있습니다. Edit 모드는 주어진 코드 파일을 수정하는 데 집중하구요. 반면 Agent 모드는 터미널 명령어 실행 권한까지 가져가서 테스트를 돌리거나 패키지를 설치하는 등 능동적인 작업을 처리하게 됩니다.

기본적으로 Edit 모드는 토큰 소비가 적고 빠르게 작동하거든요. Agent 모드는 에러가 나면 빌드 로그를 읽고 스스로 고치는 루프를 돌기 때문에 복잡한 리팩토링에 유리합니다. 다만 그만큼 API 비용이나 쿼터 소모가 커질 수 있어서 상황에 맞게 모드를 전환하는 감각이 필요합니다.

Step 1: Composer 활성화 및 대상 파일 지정

가장 먼저 Composer 창을 띄우는 작업부터 시작합니다.

Ctrl + I (macOS는 Cmd + I)

단축키를 누르면 화면 중앙이나 우측에 입력 창이 표시됩니다. 여기서 중요한 건 수정하고 싶은 파일들을 컨텍스트에 정확하게 넣어 주는 일입니다.

입력창에 @를 치고 파일명을 입력하면 대상을 추가할 수 있구요. 만약 전체 폴더나 특정 디렉토리를 참조해야 한다면 폴더 자체를 멘션하는 편이 낫습니다. 대상 파일이 빠지면 엉뚱한 템플릿만 나올 수 있어서, 초기 설정이 의외로 중요합니다.

Step 2: 멀티파일 수정 프롬프트 작성 및 실행

이제 고칠 내용을 구체적으로 지시하는 단계입니다.

auth.ts의 로그인 성공 콜백 함수에 redirectUrl을 추가하고, 이와 관련된 login.tsx의 폼 컴포넌트 구조도 그에 맞게 업데이트해 줘.

요청 사항을 적고 엔터를 누르면 Cursor가 대상 파일들을 분석하기 시작하죠. 변경할 코드 블록은 초록색 추가와 빨간색 삭제로 표시됩니다.

코드 수정이 끝나면 각 파일 위에 Accept 또는 Reject 버튼이 나타납니다. 일일이 누르기 귀찮다면 단축키를 활용하는 편이 훨씬 유용하구요. Ctrl + Enter를 누르면 변경된 모든 내용이 한 번에 작업 폴더로 반영됩니다.

Step 3: 에이전트 모드 전환 및 터미널 명령어 실행

단순 수정을 넘어 테스트 빌드까지 자동으로 돌려야 하는 순간이 옵니다.

Composer 창 하단이나 상단 메뉴에서 모드를 Agent로 변경해 보세요. 그 상태에서 빌드 에러를 잡아 달라고 명령을 내리면 스스로 터미널을 열고 명령어를 실행합니다.

npm run build 명령어로 빌드가 잘 되는지 검증하고, 에러가 나면 관련된 index.css 파일의 스타일 선언까지 같이 고쳐 줘.

에이전트 모드는 명령어 실행 전에 사람에게 승인(Approve)을 요청합니다. 보안이나 쿼터 낭비를 막기 위해 터미널 명령어 내용을 확인하고 승인 버튼을 눌러야 하구요. 컴파일러 에러 메시지가 사라질 때까지 에이전트가 코드를 알아서 고치고 재빌드를 시도합니다.

토큰 요금을 아끼기 위한 실무 제어 규칙

토큰 요금을 아끼기 위한 실무 제어 규칙

이 편리한 도구도 마구 쓰다 보면 한 달 무료 쿼터가 순식간에 줄어듭니다. 불필요한 파일을 잔뜩 컨텍스트에 얹어서 질문하면 불필요한 토큰 소비가 발생하거든요. 필요한 파일만 명시적으로 @ 멘션해서 범위를 좁히는 습관을 들여야 합니다.

그리고 에이전트 모드가 무한 루프에 빠지지 않도록 명령어 실행 횟수에 제한을 두는 편이 안전합니다. 빌드 에러가 3번 이상 반복되면 잠시 중단하고 수동으로 파일 구조를 점검하는 것이 시간과 비용을 아끼는 지름길이 되곤 하죠.

결국 사람이 마지막 빌드를 점검하는 구조가 안전하다

아무리 에이전트 모드가 알아서 테스트를 통과시켰다고 해도 실제 런타임에서 예상치 못한 사이드 이펙트가 발생할 수 있습니다. 수정을 완료한 뒤에는 git diff를 띄워두고 바뀐 파일들을 차분히 리뷰해야 하구요. 이 과정까지 생략하면 나중에 버그를 찾을 때 고생하기 마련입니다.

도구의 편리함을 온전히 누리되, 마지막 머지나 커밋 권한은 사람이 들고 통제하는 밸런스가 필요합니다. 이 룰만 잘 지키면 복잡한 아키텍처 개편도 앉아서 말만으로 끝낼 수 있을 겁니다.

관련 검색어

  • 🔍 Cursor 사용법
  • 🔍 Cursor 비교
  • 🔍 Cursor Composer 사용법
  • 🔍 Cursor Composer 비교
  • 🔍 AI 코딩 도구 사용법
  • 🔍 AI 코딩 도구 비교

댓글 쓰기

다음 이전