Cursor로 레거시 코드를 안전하게 리팩터링하는 실전 4단계

URL: https://www.youtube.com/watch?v=A7xJz1A74B8
날짜: 2026-09-09
채널: Tech Bridge
원문 제목: [한영자막] Cursor 엔지니어의 AI를 이용한 레거시 코드 리팩터링 시연 영상

---

📌 핵심 질문 / 이 영상이 다루는 핵심 논점

==대규모 레거시 코드 리팩터링은 AI 모델 하나에 코드를 한꺼번에 맡기는 작업이 아니라, 코드베이스 감사·마이그레이션 계획·작업 티켓·원격 실행·자동화 검증을 연결한 운영 시스템으로 설계해야 한다.==

• Cursor Canvas는 테스트 커버리지와 마이그레이션 후보를 시각화해 초기 감사(audit)를 돕는다.
• Cursor Plan Mode는 코드 변경 없이 요구사항, 아키텍처, 데이터 흐름, 테스트 전략을 담은 Markdown 계획을 만든다.
• Atlassian 같은 플러그인으로 계획을 검토 가능한 Jira 티켓으로 나누고, Cursor Cloud Agent에 티켓 단위로 위임한다.
• 원격 Linux VM의 브라우저·마우스·테스트 도구가 스크린샷과 동영상으로 결과를 증명하며, 자동화(Automations)가 의존성·기능 플래그·장애 대응을 선제적으로 관리한다.

PHP와 React가 섞인 WordPress 저장소를 사례로 삼아, 오래된 PHP 컴포넌트를 React로 단계적으로 옮기고 테스트로 회귀(regression)를 막는 흐름을 시연한다. 핵심은 모델의 지능만이 아니라 여러 모델을 목적에 맞게 조합하고, 도구 실행·캐시·동적 컨텍스트·컨텍스트 조립을 담당하는 Cursor Harness를 활용하며, 사람이 계획과 검토의 고리를 유지하는 데 있다.

1. Cursor를 대규모 리팩터링에 사용하는 이유

Cursor의 차별점은 모델을 호출하는 채팅창을 넘어 여러 실행 표면(surface), 모델 선택권, 에이전트 하니스(harness), 원격 검증 환경을 하나의 작업 흐름으로 묶는 데 있다.

1.1. 세 가지 개발 표면과 원격 실행

1. Agents Window

   1. 에이전트는 저장소별로 화면 한쪽에 배치되고, 중앙의 채팅 영역에서 실제 작업을 지시한다.
   2. 작업 중 모델을 선택할 수 있으며 여러 저장소를 넘나들며 작업할 수 있다.
   3. 이 방식은 에디터보다 에이전트의 계획·실행·상태 확인에 많은 시간을 쓰는 개발자에게 적합하다.

2. IDE

   1. Cursor IDE는 VS Code의 포크(fork)이므로 VS Code 디버거, 확장 기능(extensions), 하단 터미널을 계속 사용할 수 있다.
   2. VS Code 확장 기능을 수년간 사용해 왔거나 디버거 중심으로 코드를 검토하는 개발자는 IDE를 선호할 수 있다.
   3. Agents Window가 확장되어도 IDE 지원은 중단되지 않으며, 어느 표면을 쓸지는 개인 선호에 달려 있다.

3. Cursor CLI

   1. CLI는 tmux 워크플로를 보존하려는 개발자에게 적합하다.
   2. Android Studio나 Xcode처럼 아직 네이티브 Cursor 해법이 없는 IDE에서도 터미널 기반으로 사용할 수 있다.
   3. Cursor 웹사이트에서 내려받을 수 있고, 다른 TUI AI 제품과 비슷한 방식으로 작동한다.

4. Cursor Cloud Agent

   1. 에이전트가 원격 머신에서 자율적으로 실행되므로 노트북을 닫거나 산책을 나가거나 잠들어도 긴 마이그레이션을 계속 진행한다.
   2. 작업이 끝나면 코드 변경뿐 아니라 동영상, 스크린샷, 테스트 결과로 수행 내용을 입증할 수 있다.
   3. Cursor Browser에서 클라우드 에이전트를 실행하며, 같은 에이전트를 Slack과 모바일 앱에서도 제어할 수 있다.

5. Slack 연동과 모바일 앱

   1. Slack 채널 안에 상주하는 에이전트가 온라인 문서와 실제 구현의 불일치를 확인하고, 필요한 경우 PR을 열어 리뷰를 요청할 수 있다.
   2. Slack 연동은 Cursor 앱이나 브라우저를 열지 않아도 에이전트의 활동을 확인하게 해 준다.
   3. 모바일 앱은 현재 iOS App Store에서 제공되고 Android는 추후 지원될 예정이다.
   4. 모바일에서 에이전트 목록과 워크스페이스를 탐색하고 로컬 에이전트를 클라우드로 넘기거나 저장소·브랜치·작업 지시를 지정해 새 에이전트를 시작할 수 있다.

1.2. 모델 유연성과 모델 조합

1. 폭넓은 모델 선택

   1. Cursor는 여러 프런티어 연구소(frontier lab)의 모델과 오픈 모델을 함께 제공한다.
   2. 언급된 선택지에는 Kimi, GLM, Cursor의 자체 모델인 Composer, 그리고 Grok 4.6이 포함된다.
   3. Grok 4.6은 시연 전날 출시된 모델로, 여러 외부 벤치마크에서 다른 프런티어 모델과 경쟁력 있는 결과를 보인다.

2. 가격과 작업 성격의 균형

   1. Grok 4.6은 강력한 모델임에도 가격이 비교적 낮아 장시간 작업에 효율적이다.
   2. Composer와 GPT 계열은 실행 중심(execution-focused) 작업에 더 적합하고 Grok은 장시간·복합 작업을 처리하는 능력이 강한 것으로 설명된다.
   3. 클라우드 작업은 토큰 사용량이 많아질 수 있으므로, 빠르고 저렴한 모델을 골라 전체 비용을 낮추는 판단이 중요하다.

3. 계획 모델과 실행 모델의 분업

   1. Cursor의 에이전트 스웜(agent swarm)으로 SQLite를 처음부터 다시 만든 사례는 여러 모델을 조합하면 단일 고가 모델만 사용하는 것보다 저렴하게 결과를 얻을 수 있음을 보여준다.
   2. 해당 사례의 비교 대상에는 자막에서 “Fable”로 표기된 모델과 GPT-5.5가 언급되며, 특정 모델 하나에 모든 단계를 맡기지 않는 전략이 강조된다.
   3. 무거운 모델은 요구사항 해석과 계획에 사용하고, 더 빠른 실행 중심 모델은 실제 코드 작성에 사용하는 조합이 예산 대비 결과를 개선한다.

1.3. Cursor Harness가 제공하는 실행 계층

1. 플랫폼과 모델 사이의 계층

   1. 플랫폼은 Agents Window, IDE, CLI, Cloud, Browser, Slack, 모바일 같은 사용 표면을 뜻한다.
   2. 모델은 Cursor가 위임할 수 있는 LLM을 뜻한다.
   3. 그 사이의 Cursor Harness는 모델이 대규모 작업을 안정적으로 수행하도록 실행 환경을 구성한다.

2. 하니스의 핵심 기능

   1. 도구 실행(tool execution)은 파일·터미널·브라우저·외부 서비스와의 상호작용을 조정한다.
   2. 캐시 관리(cache management)는 반복되는 환경 설정과 작업을 재사용한다.
   3. 동적 컨텍스트 관리(dynamic context management)와 컨텍스트 조립(context assembly)은 긴 마이그레이션에 필요한 정보가 모델에 전달되도록 한다.
   4. 이 계층이 SQLAlchemy 버전 업그레이드나 대규모 코드베이스 리팩터링에서 단순한 모델 호출보다 높은 효율을 만든다.

3. 추가 학습 자료

   1. Cursor가 모델 위에 어떤 하니스를 쌓는지 더 기술적으로 설명하는 4월자 블로그 글이 소개된다.
   2. 해당 글은 Cursor 엔지니어 두 명이 작성했으며, 하니스의 동작을 더 자세히 확인할 수 있는 자료로 제시된다.

2. 레거시 마이그레이션의 네 단계 전략

레거시 코드를 안정적으로 현대화하려면 감사와 계획을 먼저 수행하고, 작업을 검토 가능한 단위로 나눈 다음, 원격 에이전트와 자동화로 실행과 유지보수를 연결해야 한다.

2.1. 1단계 — Canvas로 코드베이스 감사

1. WordPress 사례 준비

   1. 오픈 소스 WordPress 저장소를 복제하고 Cursor Browser에서 웹 앱을 실행한다.
   2. Cursor에서 @browser 또는 브라우저 앱을 지정하면 풀스택 앱이나 프런트엔드 앱을 내장 브라우저에서 실행할 수 있다.
   3. WordPress는 PHP와 React가 함께 쓰이지만 여전히 PHP로 작성된 오래된 컴포넌트가 많아 마이그레이션 사례로 적합하다.

2. 테스트 커버리지 감사 요청

   1. 새 채팅에서 /canvas를 호출해 코드베이스의 현재 테스트를 분석한다.
   2. 커버리지 공백을 찾아내고, React로 옮길 때 회귀를 막기 위해 어느 부분에 테스트를 추가해야 하는지 보여 달라고 요청한다.
   3. Canvas 생성은 별도의 에이전트로 저장소 옆에서 실행되므로, 다른 에이전트가 계획을 만드는 동안 병렬로 작업할 수 있다.

3. 시각화 결과 활용

   1. Canvas는 코드베이스의 데이터를 관리 화면별 커버리지 표로 바꾸고, 다음에 마이그레이션할 대상·그 이후 대상·이미 React인 컴포넌트를 구분한다.
   2. 테스트를 추가해야 할 위치, QUnit 테스트가 없는 client.js 위치, 새 테스트를 구성하는 방식도 함께 정리한다.
   3. 코드·Excel 스프레드시트·MCP 데이터 등 다양한 입력을 받아 표와 인터랙티브 시각화를 만들 수 있다.
   4. 결과는 원시 데이터나 단순 표보다 리더십에게 설명하기 쉽고, 마이그레이션 우선순위를 빠르게 논의할 수 있게 한다.

4. Canvas의 수정과 공유

   1. 생성된 시각화를 “파이 차트 대신 막대 차트로 바꿔 달라”고 요청하면 Canvas가 결과를 수정한다.
   2. Publish를 누르면 같은 Cursor 팀의 구성원, 동료, 매니저가 링크로 최신 Canvas를 볼 수 있다.
   3. Cursor 팀 밖의 가족이나 외부인은 팀 권한이 없어 링크를 열 수 없다.
   4. Canvas는 변경 사항이 반영되는 살아 있는 문서이며 PDF로 내려받아 인쇄하거나 공유용 자료로 사용할 수도 있다.
   5. IDE에서도 Command+Shift+B로 포트 8888 로컬호스트 브라우저를 열고 /canvas를 사용할 수 있다. IDE에서 Canvas를 쓸 수 없다는 초기 안내는 실제 사용 과정에서 정정되었다.

2.2. 2단계 — Plan Mode로 마이그레이션 전략 수립

1. 구체적인 목표 정의

   1. 계획 에이전트에 레거시 PHP 컴포넌트를 React로 옮기라고 요청한다.
   2. 새 테스트를 추가해 회귀가 없음을 확인하고, 현재 기술 아키텍처와 마이그레이션 후 아키텍처를 각각 다이어그램으로 그리도록 요구한다.
   3. 전체 저장소를 한 번에 바꾸지 않고 우선 한 화면을 대상으로 삼은 뒤 재사용 가능한 패턴을 단계적으로 확장한다.

2. 계획 전 질문으로 범위 확정

   1. “레거시 컴포넌트”가 모호하므로 Cursor는 어떤 범위를 설계 대상으로 삼을지 먼저 질문한다.
   2. 범위는 우선 한 화면으로 정하고, 이후 반복 적용할 수 있는 phased pattern으로 확장한다.
   3. Cursor의 Ask Question 도구는 사용자가 원하면 계획 작성 전에 최소 다섯 가지 질문을 하도록 구성할 수 있다.
   4. 마이그레이션의 기준 컴포넌트(anchor)는 프로필(Profile) 화면으로 정한다.

3. Plan Mode의 산출물과 제한

   1. Plan Mode의 결과는 코드가 아니라 편집 가능한 Markdown 문서다.
   2. Plan Mode는 코드를 만들거나 수정하지 않고 전략만 작성하므로, 구현 전에 사람이 방향을 검토할 수 있다.
   3. 계획 문서는 Confluence에 있는 TDD 템플릿을 불러와 팀의 계획 형식을 통일한다.
   4. 계획이 끝난 뒤에도 내용을 직접 고치거나 일부를 채팅에 넣어 “이 섹션을 줄여 달라”고 요청할 수 있다.

4. 계획에 포함되는 설계 내용

   1. 기능 요구사항(functional requirements)과 비기능 요구사항(non-functional requirements)을 분리한다.
   2. 현재 상태(status quo) 아키텍처, 목표(target) 아키텍처, 양쪽의 변경 사항을 Mermaid 다이어그램으로 표현한다.
   3. 구현 순서와 데이터 흐름, API 설계, 갱신이 필요한 데이터 모델, 변경해야 할 feature flag를 정리한다.
   4. Mermaid를 Lucidchart, Excalidraw, FigJam과 연결해 다른 협업 서비스의 다이어그램으로 출력할 수도 있다.

5. 여러 에이전트와 사이드 채팅

   1. 여러 에이전트를 좌우로 타일링하면 한 에이전트의 장시간 실행을 지켜보면서 다른 에이전트의 상태를 확인할 수 있다.
   2. tmux 사용자도 터미널을 벗어나 비슷한 병렬 작업 환경을 얻는다.
   3. 코드 일부를 선택해 “Add to Side Chat”으로 보내면 부모 에이전트와 충돌하지 않는 별도의 질문을 할 수 있다.
   4. 이 방식은 장시간 실행 중인 에이전트가 특정 패턴을 왜 선택했는지, 코드베이스의 특정 부분에서 무슨 일이 일어나는지 더블클릭하듯 조사하게 한다.

2.3. 3단계 — 플러그인으로 Jira 티켓을 만들고 Cloud Agent에 위임

1. 계획을 작업 단위로 쪼개기

   1. Plan Mode를 종료한 뒤 “계획을 Jira 티켓으로 나누고 Atlassian의 WordPress 공간에 게시하라”고 요청한다.
   2. Atlassian MCP는 계획을 마이그레이션용 Jira 에픽과 단계별 티켓으로 변환한다.
   3. 다른 에이전트가 임원 요약을 줄이는 동안 티켓 분할을 병렬로 수행하는 Multitask Mode도 사용할 수 있다.

2. 플러그인 생태계

   1. Atlassian 외에도 Linear와 monday.com 같은 업무 관리 도구를 연결할 수 있다.
   2. DataDog, Figma, Google Drive, Google Calendar, Gmail이 플러그인으로 제공되며, 계획을 Google Doc에 게시하거나 일정과 결합할 수 있다.
   3. Figma 플러그인은 FigJam 게시, 디자인 시스템 가져오기, 디자인 시스템 마이그레이션에 활용된다.
   4. 필요한 MCP나 플러그인은 Customize 화면에서 켜고 끌 수 있다.

3. 티켓 품질과 할당

   1. 생성된 각 Jira 티켓에는 목표(goal), 범위(scope), 인수 기준(acceptance criteria), 테스트, 의존성(dependencies), 메모가 포함된다.
   2. 티켓을 자신에게 할당하고 1단계와 2단계의 작업을 묶어 실행 대상으로 만든다.
   3. 계획에서 바로 Cloud로 빌드하는 버튼도 있지만, 티켓별 통제와 검토를 위해 그 버튼을 누르지 않고 직접 위임한다.

4. Cloud Agent의 저장소 선택과 멀티 리포지토리

   1. cursor.com/agents 브라우저에서 GitHub에 연결된 WordPress develop 저장소를 선택한다.
   2. 여러 저장소를 선택하면 마이크로서비스 간 작업이나 공용 내부 SDK 변경을 한 번에 처리할 수 있다.
   3. 예를 들어 SDK의 필드나 JSON 파일을 바꿨을 때 그 SDK에 의존하는 여러 클라이언트 서비스도 함께 갱신해야 한다.
   4. 작은 저장소나 모노레포가 아닌 현실의 시스템에서는 저장소 간 컨텍스트가 필요한 경우가 많으므로 멀티 리포지토리 Cloud Agent가 중요한 차별점이 된다.

5. Cloud Agent의 모델과 장시간 실행

   1. 클라우드 에이전트는 긴 작업과 스크린샷·동영상 생성 때문에 로컬 에이전트보다 토큰을 많이 쓸 수 있다.
   2. Grok 4.6, Composer 2.5, GPT-5.6처럼 빠르고 효율적인 모델을 선택하면 전체 마이그레이션 비용을 약 3~4달러 수준으로 낮출 수 있다는 설명이 나온다.
   3. 비용이 높은 Anthropic 모델은 이 작업에서 대체로 피하고, 작업의 성격에 맞춰 Cursor에서 제공되는 모델을 선택한다.
   4. Long-Running Agents는 /goal과 비슷하게 완료될 때까지 작업하게 하며, 완료 시한이나 실행 시간 제한을 설정할 수 있다.
   5. 의존성 업데이트나 Python 버전 업데이트처럼 모든 테스트가 끝날 때까지 지속적으로 확인해야 하는 작업에 유용하다.

6. 티켓별 PR 위임

   1. Cloud Agent에 “WordPress 보드에서 자신에게 할당된 모든 Jira 티켓을 찾고, 각각을 작업하라”고 지시한다.
   2. 각 티켓마다 별도의 PR을 만들고 스크린샷이나 동영상으로 변경 사항을 검증하라고 요구한다.
   3. 에이전트는 순차적으로 연결된 세 티켓을 발견하고, 1단계를 시작하기 전에 부모 티켓을 먼저 처리하겠다고 보고한다.
   4. 계획을 수정하고 티켓으로 나눈 뒤 구현을 위임하면 수천 줄짜리 하나의 거대한 PR이 아니라 검토 가능한 단계별 PR 묶음이 된다.

7. 환경 빌드와 MCP 재사용

   1. Cloud Agent는 원격 환경을 자동으로 준비하며 최초 설정에는 약 10~20분이 걸릴 수 있다.
   2. 한 번 만든 환경은 Build로 저장되어 이후 설치 과정을 반복하지 않고 즉시 실행된다.
   3. WordPress처럼 큰 저장소도 미리 제공한 설치 스크립트와 스냅샷이 있으면 빠르게 작업을 시작할 수 있다.
   4. 로컬에서 연결한 Atlassian, DataDog, Google Drive, Granola, PagerDuty 등의 MCP도 클라우드 환경에서 다시 연결해 사용할 수 있다.

8. 비동기 개발과 항상 켜진 에이전트

   1. 금요일에 백로그 티켓 전체를 에이전트에 맡기고 월요일에 PR을 검토하는 방식으로 주말 동안 작업을 진행할 수 있다.
   2. 유럽 팀이 잠든 뒤 아시아 팀이 이어받는 식으로 분산 팀이 시간대 차이를 비동기 협업으로 바꿀 수 있다.
   3. 노트북을 닫아도 실행이 계속되므로 개발자의 로컬 머신을 점유하지 않는 항상 켜진 작업자가 된다.

2.4. 4단계 — Automations로 품질과 안정성 유지

1. 자동화의 트리거

   1. Automations는 예약 실행되거나 이벤트에 반응하는 Cloud Agent다.
   2. 시간, PR 생성, 라벨 변경, Slack 또는 Teams의 새 메시지, 사용자 정의 웹훅을 트리거로 사용할 수 있다.
   3. Jira 티켓을 To Do에서 In Progress로 끌어 옮길 때 웹훅을 발생시켜 에이전트를 시작하는 워크플로도 만들 수 있다.

2. 기능 플래그 정리 자동화

   1. 주 1회 저장소를 검색해 지난 30일 동안 사용되지 않은 stale feature flag를 찾도록 설정한다. 설정 과정에서 “30개월”, “30주”라고 잘못 말한 뒤 “30일”로 정정했고 참석자들이 웃었다.
   2. Statsig MCP는 연결되어 있지 않아, DataDog와 Sentry로 해당 플래그와 관련된 문제가 없었는지 확인하도록 구성한다.
   3. 사용하지 않는 플래그를 제거하고, 제거로 회귀가 생기지 않았음을 확인하는 테스트를 추가한 PR을 열도록 한다.
   4. 작업이 끝나면 Slack으로 PR 링크를 보내 검토자가 확인하도록 한다.

3. 선제적 유지보수

   1. 기능 플래그 정리 외에도 의존성 업데이트와 코드베이스 취약점 스캔을 자동화할 수 있다.
   2. 이런 접근은 레거시 상태가 된 뒤 원인을 추적하는 반응적 리팩터링보다, 문제가 커지기 전에 줄이는 선제적 관리다.
   3. 자동화를 서로 연결하거나 사용자 정의 웹훅으로 체인을 구성하면 반복적인 운영 작업을 지속적으로 처리할 수 있다.

4. 자동화 템플릿과 장애 대응

   1. 직접 처음부터 만들지 않아도 테스트 커버리지 추가, 취약점 스캔, 인시던트 트리아지용 템플릿을 사용할 수 있다.
   2. DataDog 알림 채널, PagerDuty, incident.io와 연결해 초기 장애 조사를 자동화할 수 있다.
   3. 실제 온콜 흐름에서는 새벽 3시에 사람을 깨우기 전에 에이전트가 초기 조사를 수행하고, 발견한 내용을 당번에게 간단한 요약으로 보낼 수 있다.
   4. 결과를 Slack으로 보내거나 DataDog를 사용하고, 조직의 도구에 맞춰 Notion이나 Confluence에 게시할 수도 있다.

3. 원격 브라우저와 동영상으로 회귀를 증명하는 방법

Cloud Agent는 코드를 작성하는 실행자이면서 원격 컴퓨터를 조작하는 테스트 담당자이므로, “수정했다”는 설명을 실제 동작 증거로 바꾼다.

3.1. Linux VM의 데스크톱 권한

1. 브라우저·마우스·컴퓨터 접근

   1. Cloud Agent는 원격 Linux VM에서 실행되고 데스크톱, 마우스, 컴퓨터에 접근할 수 있다.
   2. 따라서 풀스택 프런트엔드 애플리케이션을 직접 열고 클릭하며 사용자 흐름을 테스트할 수 있다.
   3. 로컬 개발자가 모든 화면을 수동으로 재현하지 않아도 에이전트가 테스트 과정을 녹화해 전달한다.

2. Grafana 테마 변경 사례

   1. 다른 저장소인 Grafana에서 테마 전환 기능을 구현하고 테스트한 사례가 제시된다.
   2. 에이전트가 자신의 마우스와 컴퓨터로 기능을 실행했으며, 사람이 화면을 조작하지 않은 상태에서 전체 동영상을 녹화했다.
   3. 녹화에는 로그인, 댓글 보기, 사용자 보기 같은 단계 라벨이 붙어 각 기능이 어디서 검증됐는지 확인할 수 있다.

3.2. PHP에서 React로 옮긴 결과 검토

1. 완료된 두 컴포넌트 마이그레이션

   1. 이전 Cloud Agent 실행은 PHP 컴포넌트 두 개를 React로 옮겼다.
   2. 요청에는 엔드투엔드 테스트가 포함됐고, 에이전트는 마이그레이션된 기능이 기존 동작을 깨뜨리지 않았는지 화면에서 확인했다.
   3. 로그인, 댓글 보기, 사용자 보기 흐름을 클릭하며 기대한 동작과 실제 결과를 비교한다.

2. 작업 범위와 PR 크기

   1. 마이그레이션 PR이 이미 커졌다면 한 번에 더 많은 컴포넌트를 넣기보다 두 컴포넌트로 범위를 제한하는 편이 검토에 유리하다.
   2. 두 Jira 티켓을 처리할 때도 각 티켓에 대해 별도의 PR을 만들고 화면에서 두 PR을 전환하며 무엇을 다뤘는지 확인한다.
   3. 수천 줄의 코드를 포함하는 거대한 PR 하나보다, 컴포넌트나 서비스별로 나뉜 여러 PR이 리뷰와 회귀 추적에 적합하다.

3.3. 사람의 개입과 검토 고리

1. 자율 실행과 사용자 입력의 공존

   1. Cloud Agent는 자율적으로 일하지만 사용자 입력을 받도록 설계되어 있다.
   2. 작업 중간에 후속 지시를 추가하거나, 방향이 마음에 들지 않으면 실행을 중단하거나, 모바일 앱에서 개입할 수 있다.
   3. 에이전트가 대부분의 일을 하되 사람이 필요할 때만 루프에 들어가는 구조가 목표다.

2. 변경·CI·PR 검토

   1. Cloud 화면은 버전 관리 UI처럼 삭제·추가·수정된 내용을 보여 준다.
   2. 커밋 이력과 CI 체크를 확인할 수 있으며, 시연 환경에서는 Cursor Bugbot 체크가 통과하는지 볼 수 있다.
   3. 변경을 검토한 뒤 PR을 열어 다른 사람이 리뷰하게 한다.

4. Cursor 활용을 확장하는 생태계

마이그레이션의 실행력은 에이전트 자체뿐 아니라 업무 도구, 스킬, 보안 연결, 기억 관리가 조합될 때 커진다.

4.1. 온보딩과 스킬

1. Cloud Agent 온보딩

   1. cursor.com/onboard에서 GitHub를 연결하고 새 원격 환경을 만든다.
   2. 환경이 준비되면 저장소를 선택해 계획·티켓·자동화 기반의 마이그레이션을 시작할 수 있다.
   3. 레거시 코드베이스 리팩터링 모범 사례를 설명하는 Cursor Cookbook 문서가 있었지만, 시연 시점에는 링크를 찾지 못했거나 문서가 내려간 상태였다.

2. 플러그인에 포함된 스킬

   1. Atlassian 플러그인은 MCP뿐 아니라 Atlassian 팀이 공개한 스킬도 함께 제공한다.
   2. Figma 플러그인도 MCP와 여러 스킬을 함께 제공하므로 반복적인 협업·디자인 업무를 바로 활용할 수 있다.
   3. superpowers 플러그인은 누구나 사용할 수 있도록 공개된 팀 공용 스킬 묶음으로 소개된다.

3. 저장소별 온보딩 스킬

   1. Gutenberg WordPress 서브리포지토리에서 직접 만든 /onboard 스킬은 새 저장소를 처음 만났을 때 사용한다.
   2. 기술 스택, 필요한 Python 버전, 저장소의 역할, 백엔드와 프런트엔드가 위치한 곳을 먼저 파악하게 한다.
   3. 이런 맞춤 스킬은 팀의 반복 절차를 코드베이스에 맞는 온보딩 워크플로로 고정한다.

4. 직접 만드는 스킬

   1. Cursor의 Create Skill 기능으로 각 팀의 작업 방식에 맞는 워크플로를 정의할 수 있다.
   2. 자주 반복되는 계획·검증·문서화 절차를 스킬로 만들면 에이전트에게 매번 같은 배경을 설명할 필요가 줄어든다.

4.2. 비밀, 네트워크, 보안

1. 환경 변수와 비밀 관리

   1. API 키, 환경 키, 시크릿은 Cloud Agent 환경 설정에 저장한다.
   2. 라우팅 규칙과 허용할 IP도 환경에 지정해 에이전트가 접근할 수 있는 범위를 제한할 수 있다.
   3. 보안·데이터 저장 위치·보존 기간·시크릿·버전·프라이빗 연결 정보는 cursor.com/cloud와 엔터프라이즈 문서에서 확인한다.

2. 사설 인프라 연결

   1. Azure 같은 사설 네트워크의 서비스에 접근해야 하면 Cloudflare Tunnel을 사용할 수 있다.
   2. AWS 인프라라면 AWS PrivateLink를 선택할 수 있고, Tailscale 같은 VPN 방식도 상황에 따라 가능하다.
   3. Cloud Agent를 자체 호스팅하는 선택지도 있지만 처음부터 권장되는 방식은 아니다.
   4. 보안 수준이 높은 고객은 제공된 연결 도구를 사용하거나 Cloud Agent의 보안 모델을 신뢰해 운영한다.

3. 로컬 파일과 예약 자동화의 한계

   1. 저장소에 커밋된 계획, 스킬, 파일은 예약된 자동화가 읽을 수 있다.
   2. 개발자 컴퓨터에만 있는 로컬 파일은 Cloud Agent가 직접 접근할 수 없으므로 PrivateLink, Cloudflare Tunnel 같은 네트워크 연결이 필요하다.
   3. 로컬과 클라우드를 함께 사용해야 하는 코딩 흐름을 위해 일반 지식 제품인 Grokbot을 활용할 수 있으며, 해당 주제의 워크숍이 다음 주 목요일에 예정되어 있다고 안내된다.

4.3. 팀 기억과 지속적 학습

1. Continual Learning 플러그인

   1. Continual Learning 플러그인은 팀이 일하는 방식, 글쓰기 스타일, 코딩 스타일을 agents.mmd 파일에 기록한다.
   2. 개인 플러그인으로 사용할 수도 있고 팀 플러그인으로 배포해 모든 구성원이 같은 작업 습관을 공유할 수도 있다.
   3. 과거 협업 경험을 바탕으로 다음 빌드 계획을 개선하려는 요구를 해결하는 방식이다.

2. Automations의 memories.mmd

   1. 각 자동화에는 memories.mmd 파일이 있어 실행 경험을 다음 실행에 반영한다.
   2. 예를 들어 Slack 메시지의 문구가 마음에 들지 않는다고 후속 피드백을 주면, 다음 실행부터 표현을 개선한다.
   3. 자동화가 한 번 실행될 때마다 누락이나 사용자 피드백을 학습해 점진적으로 나아간다.

3. 과거 대화와 실행 진단

   1. 로컬 Cursor에서는 @chats로 저장소의 과거 대화를 현재 컨텍스트로 불러올 수 있다.
   2. Cloud Agent에도 같은 과거 대화 접근이 가능한지는 질의 시점에 확답하지 못했으며 확인이 필요한 항목으로 남았다.
   3. Cursor Cloud MCP를 사용하면 실패한 실행, 환경 설정, Cloud Agent의 동작을 진단할 수 있다.

5. 질의응답에서 확인된 운영 원칙

5.1. 제품·모델·사용 환경

1. DeepSeek V4 Flasher Pro의 미국 서버 제공 여부

   1. 미국 서버에 호스팅되는 DeepSeek V4 Flasher Pro 지원 계획을 묻는 질문에 현재 계획이 없다는 답변이 나왔다.
   2. DeepSeek V4 Flasher Pro의 미국 서버 지원 계획은 아직 없다고 정리된다.

2. IDE와 Agents Window 선택

   1. VS Code 디버거와 익숙한 확장 기능이 중요하면 IDE를 사용하고, 에이전트 실행과 클라우드 코드 리뷰가 중심이면 Agents Window를 선택할 수 있다.
   2. 둘 중 어느 하나가 절대적으로 우월한 것이 아니라 개인의 작업 방식에 따른 선택이다.

3. Canvas 링크 권한

   1. Canvas를 Publish하고 Copy Link를 누르면 링크를 복사해 같은 Cursor 팀 구성원에게 공유할 수 있다.
   2. 팀 밖 사용자는 링크가 있어도 열 수 없으며, PDF 다운로드는 별도의 공유·인쇄 경로가 된다.

5.2. 연속 학습과 크래시 복구

1. 팀의 협업 방식 학습

   1. Continual Learning 플러그인은 agents.mmd에 팀의 글쓰기·코딩·업무 스타일을 축적한다.
   2. 자동화는 memories.mmd를 이용해 실행 후 피드백을 기억하므로, 반복 작업이 팀의 기대에 가까워진다.

2. Cloud Agent 크래시 뒤 컨텍스트

   1. 로컬 Cursor의 과거 대화는 @chats로 참조할 수 있다.
   2. Cloud Agent 실행이 중단된 뒤 기존 실행 컨텍스트를 그대로 복구할 수 있는지는 별도 확인이 필요하다.
   3. Cloud MCP는 실패한 실행과 환경을 조사하는 진단 수단으로 활용할 수 있다.

5.3. 네트워크 제한이 있는 조직

1. Azure와 사설 네트워크

   1. 내부 서비스가 Azure 사설 네트워크 뒤에 있다면 Cloudflare Tunnel, AWS 환경의 PrivateLink, VPN 계열 연결을 검토한다.
   2. 자체 호스팅 Cloud Agent도 가능하지만 운영 복잡성이 있으므로 기본 선택으로 권장되지는 않는다.

2. 예약된 에이전트와 로컬 자원

   1. 저장소에 커밋된 파일은 예약 에이전트가 읽을 수 있지만, 개인 컴퓨터에만 있는 파일은 직접 읽지 못한다.
   2. 로컬 자원을 써야 하는 경우 사설 연결을 구성하거나 로컬·클라우드 작업을 조정하는 별도 도구를 사용해야 한다.

주요 발언 모음

“대규모 마이그레이션에서는 모델과 플랫폼만 보는 것이 아니라 그 위에 제공되는 하니스까지 봐야 한다.”

“Canvas로 감사하고 Plan Mode로 전략을 세운 다음, 플러그인으로 티켓 범위를 정하고 Cloud Agent에 넘겨라.”

“수천 줄짜리 하나의 거대한 PR보다 각 컴포넌트나 서비스가 담당하는 여러 PR이 검토하기 쉽다.”

“Cloud Agent는 자율적이지만 사용자가 원할 때 루프에 들어와 후속 지시를 하거나 중단할 수 있어야 한다.”

“자동화는 문제가 생긴 뒤 대응하는 대신 문제가 커지기 전에 싹을 잘라내는 방법이다.”

핵심 데이터 & 수치

• WordPress 저장소: PHP와 React가 공존하며 PHP 레거시 컴포넌트를 React로 옮기는 시연 대상이다.
• Plan Mode 범위: 처음에는 전체 저장소가 아닌 한 화면(Profile)을 앵커로 정하고 재사용 가능한 단계별 패턴으로 확장한다.
• 초기 Cloud 환경 준비 시간: 처음 구축할 때 약 10~20분이 걸릴 수 있으며 이후 Build 캐시로 재사용한다.
• Cloud 마이그레이션 비용 예시: Grok 4.6, Composer 2.5, GPT-5.6 같은 모델을 선택하면 전체 작업이 약 3~4달러가 될 수 있다.
• 기능 플래그 기준: 지난 30일 동안 사용되지 않은 플래그를 찾아 제거 후보로 삼는다.
• 자동화 실행 주기: 기능 플래그 정리 예시는 주 1회 실행으로 설정하며 실제 빈도는 과도하면 조정한다.
• 원격 실행 환경: Cloud Agent는 원격 Linux VM의 데스크톱과 마우스를 이용해 풀스택·프런트엔드 흐름을 테스트한다.
• 완료된 마이그레이션 예시: PHP 컴포넌트 두 개를 React로 옮기고 엔드투엔드 테스트와 동영상 검증을 수행했다.
• Cloud Agent 티켓 흐름: 부모 티켓을 먼저 처리한 뒤 세 개의 순차 티켓을 단계적으로 실행하는 구조다.
• 모바일 지원: iOS 앱은 제공 중이며 Android 앱은 향후 지원 예정이다.

결론 및 시사점

1. 레거시 리팩터링의 첫 단계는 코드를 수정하는 일이 아니라 Canvas로 현재 테스트 커버리지와 마이그레이션 우선순위를 시각화하는 일이다.
2. Plan Mode에서는 한 화면 같은 좁은 앵커를 정하고 요구사항, 비기능 요구사항, 현재·목표 아키텍처, 데이터 흐름, API, 데이터 모델, 플래그를 문서화한다.
3. 계획은 Markdown 문서로 남기고 사람이 편집한 뒤 Jira 티켓으로 바꿔야 에이전트의 작업 범위를 검토할 수 있다.
4. 각 티켓은 목표, 범위, 인수 기준, 테스트, 의존성, 메모를 갖추고 별도 PR로 구현해야 대규모 변경을 안전하게 리뷰할 수 있다.
5. 무거운 모델은 계획에, 빠른 모델은 실행에 배치하고 Cursor Harness의 컨텍스트·캐시·도구 계층을 함께 활용하면 비용과 시간을 줄일 수 있다.
6. Cloud Agent는 원격 Linux VM에서 노트북과 분리되어 실행되므로 장시간 마이그레이션과 분산 팀의 비동기 작업에 적합하다.
7. 화면을 클릭하는 브라우저 테스트, 스크린샷, 동영상, CI 결과를 요구하면 AI가 변경을 완료했다고 주장하는 데서 실제 동작을 증명하는 단계로 넘어간다.
8. 사람은 계획 승인, 범위 조정, 후속 지시, PR 리뷰, 필요할 때의 중단을 담당하고 에이전트는 반복적인 구현과 검증을 담당한다.
9. 기능 플래그 제거, 의존성 업데이트, 취약점 스캔, 장애 초기 조사를 Automations로 예약하면 레거시가 다시 쌓이는 속도를 늦출 수 있다.
10. 가장 재사용 가능한 운영 공식은 Canvas 감사 → Plan Mode 전략 → 플러그인 티켓화 → Cloud Agent 구현·검증 → Automations 유지보수다.

핵심 요약 (20줄)

1. 대규모 레거시 리팩터링은 단일 AI 모델 호출이 아니라 감사·계획·티켓·실행·검증을 잇는 운영 시스템으로 설계해야 한다.
2. Cursor는 Agents Window·IDE·CLI·Cloud Agent·Browser·Slack·모바일을 하나의 개발 흐름으로 연결한다.
3. Agents Window는 여러 저장소와 모델을 중앙 채팅에서 다루며 에이전트 상태를 화면 양쪽에서 병렬로 확인하게 한다.
4. Cursor IDE는 VS Code 포크이므로 디버거·확장 기능·터미널을 중시하는 기존 개발자의 흐름을 보존한다.
5. Cursor CLI는 tmux와 Android Studio·Xcode 같은 비네이티브 IDE의 터미널 워크플로를 지원한다.
6. Cloud Agent는 원격 Linux VM에서 실행되어 노트북을 닫아도 장시간 마이그레이션과 리팩터링을 계속한다.
7. Cursor의 모델 유연성은 계획용 고성능 모델과 실행용 저비용 모델을 조합해 품질과 비용을 조절하게 한다.
8. Cursor Harness는 도구 실행·캐시 관리·동적 컨텍스트·컨텍스트 조립을 담당해 대규모 저장소 작업을 안정화한다.
9. WordPress PHP·React 저장소는 오래된 PHP 컴포넌트를 React로 옮기는 단계적 마이그레이션 사례로 사용된다.
10. Canvas는 테스트 커버리지 표와 마이그레이션 후보를 시각화해 코드베이스의 위험과 우선순위를 빠르게 드러낸다.
11. Canvas는 코드·스프레드시트·MCP 데이터를 인터랙티브 차트로 만들고 수정·팀 공유·PDF 내보내기를 지원한다.
12. Plan Mode는 코드를 바꾸지 않고 기능·비기능 요구사항과 현재·목표 아키텍처를 Markdown 문서로 정리한다.
13. 한 화면과 Profile 컴포넌트를 앵커로 삼으면 전체 저장소를 위험하게 건드리지 않고 재사용 패턴을 검증할 수 있다.
14. Atlassian MCP는 계획을 목표·범위·인수 기준·테스트·의존성을 갖춘 Jira 티켓과 에픽으로 분해한다.
15. Cloud Agent는 부모 티켓과 순차 의존성을 확인한 뒤 티켓마다 별도 PR을 만들고 스크린샷·동영상으로 검증한다.
16. 멀티 리포지토리 에이전트는 공용 SDK 변경과 여러 마이크로서비스 갱신처럼 저장소 간 컨텍스트가 필요한 일을 처리한다.
17. 원격 환경은 첫 구축에 10~20분이 걸릴 수 있지만 Build 캐시와 설치 스크립트로 다음 실행을 빠르게 시작한다.
18. 브라우저와 마우스를 가진 Cloud Agent는 로그인·댓글·사용자 보기 같은 엔드투엔드 흐름을 직접 클릭해 회귀를 확인한다.
19. Automations는 기능 플래그·의존성·취약점·장애 대응을 예약하거나 이벤트로 실행해 레거시가 다시 쌓이는 것을 예방한다.
20. 최종 운영 공식은 Canvas 감사, Plan Mode 전략, 플러그인 티켓화, Cloud Agent 검증, Automations 유지보수의 순환이다.