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

URL: https://www.youtube.com/watch?v=A7xJz1A74B8 날짜: 2026-09-08 채널: Tech Bridge

---

📌 핵심 질문 / 이 작업이 다루는 핵심 논점

==AI를 활용한 레거시 리팩터링은 코드를 한 번에 생성하는 일이 아니라, 코드베이스를 감사하고 범위를 정한 뒤 작은 티켓 단위로 실행·검증·유지하는 운영 체계를 만드는 일이다.== Cursor는 에이전트 창, IDE, CLI, 브라우저, Slack, 모바일 앱을 하나의 흐름으로 묶고, 모델 선택권과 Cursor harness를 결합해 이 체계를 장시간·다중 저장소 작업으로 확장한다.

• Cursor Canvas가 코드베이스의 테스트 커버리지와 마이그레이션 우선순위를 시각화한다.
• Plan Mode가 TDD 템플릿에 맞춘 전략 문서와 현재·목표 아키텍처를 만들며, 코드 생성 전에 질문으로 범위를 좁힌다.
• Atlassian 플러그인이 계획을 Jira의 단계별 티켓으로 나누고, Cloud Agent가 티켓마다 별도 PR과 스크린샷·동영상·테스트 증거를 만든다.
• Automations가 기능 플래그·의존성·인시던트를 선제적으로 관리해 다음 대규모 리팩터링을 줄인다.

대규모 변경의 위험은 모델에게 거대한 작업을 맡기는 방식에서 커진다. 감사 결과를 계획으로 바꾸고, 계획을 검토 가능한 티켓으로 쪼개며, 원격 에이전트의 자율성을 CI·브라우저 테스트·사람의 PR 리뷰로 감싸야 한다. 모델의 성능만으로는 부족하고 도구 실행, 캐시 관리, 동적 컨텍스트 관리, 컨텍스트 조립을 담당하는 harness가 결과의 일관성과 확장성을 좌우한다.

1. Cursor가 대규모 리팩터링에 적합한 이유

Cursor의 차별점은 특정 모델이나 편집기 하나가 아니라 여러 작업 표면, 모델 선택, 실행 하네스를 하나의 개발 체계로 제공하는 데 있다.

1.1. 에이전트 창·IDE·CLI의 역할 분리

1. 에이전트 창을 중심으로 한 개발

   1. 에이전트는 저장소별로 화면 측면에 배치되고, 가운데 대화 영역에서 요청·모델·저장소를 선택한다.
   2. 지난 6개월 사이 사용하지 않았다면 새롭게 보일 수 있는 이 화면이 Cursor가 상정하는 개발의 미래에 가깝다. 여러 에이전트를 동시에 띄우고 각각의 진행 상황을 관찰할 수 있다.

2. VS Code 기반 IDE

   1. Cursor IDE는 VS Code 포크이므로 VS Code 디버거, 확장 프로그램, 하단 터미널을 그대로 선호하는 개발자에게 적합하다.
   2. IDE 지원은 계속 유지되며, 에이전트 창과 IDE 중 어느 쪽에서 코드를 생성·검토할지는 개인의 작업 습관에 달려 있다.

3. Cursor CLI

   1. 터미널 멀티플렉서(T-Max) 워크플로우를 유지하거나 Android Studio·Xcode처럼 네이티브 Cursor 환경이 아직 없는 IDE에서 작업할 때 CLI를 사용할 수 있다.
   2. 웹사이트에서 다운로드할 수 있고 다른 TUI(Text User Interface) 기반 AI 제품과 비슷한 방식으로 터미널 안에서 활용한다.

1.2. 원격 실행 표면이 만드는 지속성

1. Cursor Cloud Agent

   1. Cloud Agent는 원격 컴퓨터에서 자율적으로 실행되므로 에이전트를 시작한 뒤 노트북을 닫아도 작업이 계속된다.
   2. 여러 차례 왕복 지시가 필요한 장기 마이그레이션·리팩터링을 맡기고, 완료 시점에 동영상·스크린샷·테스트 결과로 의도한 변경을 증명하게 할 수 있다.

2. Slack 연동

   1. Slack 채널 안에 에이전트를 두고 온라인 문서와 실제 구현이 동기화되어 있는지 확인하게 할 수 있다.
   2. 에이전트는 PR을 열고 다른 사람의 리뷰를 요청하며, Cursor 앱이나 브라우저를 열지 않아도 Slack에서 작업 상태를 노출한다.

3. 모바일 앱

   1. 모바일 앱은 당시 iOS App Store에서 제공되고 Android 버전은 출시 예정이었다.
   2. 로컬에서 시작한 에이전트를 클라우드로 넘기고, 이동 중에 모든 에이전트·워크스페이스를 확인하거나 특정 저장소와 브랜치에서 새 에이전트를 실행할 수 있다.

1.3. 모델 유연성과 Cursor harness

1. 용도별 모델 조합

   1. Cursor는 여러 프론티어 랩의 모델, 오픈 소스 모델인 Kimi·GLM, 자체 모델인 Composer와 Grok 4.6을 함께 제공한다.
   2. Grok 4.6은 공개 벤치마크에서 강한 성능을 보이면서도 장시간 작업에 비해 저렴하다. Composer와 GPT 계열처럼 실행에 초점을 둔 모델보다 다소 비쌀 수 있지만 다른 프론티어 모델보다 비용 효율적이다.
   3. 계획에는 글쓰기와 전략 수립에 강한 GPT56 Soul을 사용하고, 계획이 완성된 뒤에는 더 빠른 Grok 4.6으로 전환하는 식으로 작업 특성에 맞춰 모델을 바꾼다.

2. 에이전트 스웜과 비용 관리

   1. Cursor가 SQLite를 처음부터 다시 구축한 사례는 여러 모델을 조합한 에이전트 스웜이 Fable 하나 또는 GPT55 하나만 사용하는 것보다 훨씬 저렴할 수 있음을 보여준다.
   2. 무거운 모델은 계획에, 실행 중심의 빠른 모델은 실제 코드 작성에 배정하면 품질과 전체 예산을 함께 관리할 수 있다.

3. Cursor harness

   1. 플랫폼은 IDE·에이전트 창·브라우저·CLI 같은 Cursor 사용 표면이고, 모델은 Cursor가 활용하거나 위임할 수 있는 LLM이다.
   2. 두 층 사이의 harness는 도구 실행, 캐시 관리, 동적 컨텍스트 관리, 컨텍스트 조립을 담당한다.
   3. harness가 모델과 저장소 사이에 필요한 도구·정보를 조율하기 때문에 대규모 코드베이스 리팩터링이나 SQLAlchemy 한 버전에서 다음 버전으로의 마이그레이션을 단순 채팅보다 강력하게 수행할 수 있다.

2. 4단계 리팩터링 워크플로우의 출발점: 코드베이스 감사

실제 사례는 PHP와 React가 섞여 있고 레거시 PHP 코드가 남은 오픈 소스 WordPress 저장소를 대상으로 진행한다. 목표는 모든 코드를 한꺼번에 바꾸는 것이 아니라 테스트 상태를 파악하고 일부 컴포넌트를 React로 옮길 안전한 범위를 정하는 것이다.

2.1. WordPress 저장소와 실행 환경 확인

1. 코드베이스 구성

   1. WordPress 웹사이트는 PHP와 React를 혼합해 구성되어 있지만 오래된 PHP 컴포넌트가 상당수 남아 있다.
   2. 일부 레거시 컴포넌트를 현재 주력 프레임워크인 React로 이전하고, 회귀 오류가 생기지 않았음을 확인하는 테스트를 함께 추가한다.

2. Cursor Browser 활용

   1. WordPress 저장소를 복제한 뒤 Cursor에 앱 브라우저에서 WordPress 웹 앱을 실행하도록 요청한다.
   2. 내장 브라우저는 풀스택 앱부터 프런트엔드 앱까지 실행할 수 있고, 브라우저 패널을 넓혀 실행 중인 WordPress 화면을 직접 확인하게 한다.

3. 감사 목표 설정

   1. 현재 어떤 테스트가 존재하는지 확인하고 테스트 커버리지를 어디에서 개선할지 파악한다.
   2. 같은 시점에 PHP 컴포넌트를 React로 옮길 마이그레이션 계획을 세워 감사 결과와 구현 전략이 분리되지 않게 한다.

2.2. Canvas로 커버리지와 우선순위 시각화

1. Canvas 생성

   1. 새 채팅에서 /canvas를 실행하면 코드베이스를 분석하고 테스트 공백과 React 마이그레이션 후 추가할 커버리지 영역을 표시한다.
   2. Canvas 에이전트는 WordPress 저장소 옆에서 자동 실행되므로 감사와 계획 에이전트를 동시에 진행할 수 있다.

2. 코드베이스 데이터의 시각화

   1. Canvas는 파일, Excel 스프레드시트, MCP에서 가져온 데이터 등 여러 입력을 받을 수 있다.
   2. 원시 데이터나 표로만 보던 내용을 인터랙티브 시각화로 바꿔 리더십 보고나 기술적 의사결정에 활용한다.
   3. 관리자 화면별 커버리지를 표로 만들고, 다음에 마이그레이션할 화면·나중에 처리할 화면·이미 React인 컴포넌트를 구분한다.

3. 테스트 공백의 구체화

   1. 커버리지를 추가할 위치와 QUnit 테스트가 없는 client.js 위치를 따로 표시한다.
   2. 새 테스트를 어떤 구조로 작성할지까지 제안하므로, 마이그레이션 전에 보호망을 만드는 순서를 잡을 수 있다.

4. 수정과 공유

   1. Canvas 자체를 편집할 수 있어 파이 차트를 막대 차트로 바꾸는 등 데이터 표현을 즉시 조정한다.
   2. 게시한 Canvas는 링크를 가진 같은 Cursor 팀 구성원이 브라우저에서 볼 수 있고 변경 사항도 함께 확인할 수 있다. 팀 밖의 부모님이나 외부인은 같은 팀에 속하지 않으면 링크를 열 수 없다.
   3. Canvas는 살아 있는 문서로 유지되며 PDF로 내려받아 인쇄물이나 회의용 자료로 사용할 수 있다.

3. 계획 수립: Plan Mode와 TDD 마이그레이션 전략

계획 단계는 코드를 생성하지 않고 요구사항, 범위, 위험, 검증 방법을 문서화하는 단계다. 질문을 통해 범위를 먼저 좁혀야 레거시 전체를 한 번에 건드리는 일이 줄어든다.

3.1. 계획 요청과 모델 선택

1. 마이그레이션 목표

   1. 기존 PHP 레거시 컴포넌트를 React로 옮긴다.
   2. 회귀 오류가 없음을 확인하도록 테스트를 추가한다.
   3. 현재 기술 아키텍처와 마이그레이션 후 목표 아키텍처를 각각 다이어그램으로 그린다.

2. 전략 수립용 모델

   1. 글쓰기와 문서화에 강하다고 평가한 GPT56 Soul을 계획 작성에 사용한다.
   2. 장점이 분명한 모델에도 다른 영역의 한계가 있으므로 모든 작업에 같은 모델을 고정하지 않고 단계별로 바꾼다.

3. 다이어그램 출력

   1. Cursor는 Mermaid를 기본 다이어그램 형식으로 사용한다.
   2. 필요하면 Lucidchart, Excalidraw, FigJam과 연결해 해당 서비스 형식으로 출력할 수 있으며, 첫 시도는 Mermaid로 시작하는 것이 빠르다.

3.2. 질문으로 범위와 앵커 컴포넌트 확정

1. 초기 질문

   1. “레거시 컴포넌트”라는 표현이 모호하므로 어떤 범위를 대상으로 할지 먼저 묻는다.
   2. 우선 한 화면만 대상으로 정하고, 이후 재사용 가능한 단계별 패턴으로 확장하는 방향을 선택한다.

2. Ask Question 도구

   1. Cursor의 Ask Question 도구는 계획을 쓰기 전에 사용자에게 질문을 던진다.
   2. 최소 5개의 질문을 하도록 설정할 수 있어 요구사항이 충분히 구체화된 뒤에 계획을 생성하게 한다.
   3. 실제 대화에서 “어떤 레거시 컴포넌트를 계획의 앵커로 삼을 것인가?”라는 질문에는 프로필 컴포넌트를 우선 대상으로 지정했다.

3. Plan Mode의 안전장치

   1. Plan Mode의 산출물은 Markdown 문서이며, 이 모드에서는 코드를 직접 작성하지 않고 전략만 작성한다.
   2. Confluence에 저장한 TDD 템플릿을 Plan Skill로 불러와 모든 계획이 같은 형식으로 보이게 한다.

3.3. 계획 문서의 내용과 편집 방식

1. 요구사항과 아키텍처

   1. 기능 요구사항과 비기능 요구사항을 분리한다.
   2. 현재 상태 아키텍처와 목표 아키텍처를 함께 그리고, 변경할 지점을 명시한다.

2. 구현 순서와 계약

   1. 코드베이스의 실행 순서와 데이터 흐름을 추적한다.
   2. API 설계, 변경할 데이터 모델, 조정해야 할 기능 플래그를 목록화한다.

3. 살아 있는 계획

   1. 계획은 완성 후에도 직접 편집·수정할 수 있는 문서다.
   2. 채팅으로 계획의 특정 부분을 추가하거나 “이 섹션을 줄여 달라”고 요청할 수 있으며, 계획 요약 축약 작업과 티켓 분할 작업을 병렬로 실행할 수도 있다.

4. 계획을 실행 단위로 바꾸기: 플러그인과 Jira 티켓

계획을 하나의 거대한 PR로 보내지 않고 단계와 컴포넌트별 티켓으로 나누면 의존성·검증·리뷰가 관리 가능한 크기로 유지된다.

4.1. Atlassian MCP와 플러그인 생태계

1. Jira 티켓 생성

   1. Plan Mode를 종료한 뒤 “이 계획을 Jira 티켓으로 나누고 Atlassian의 WordPress 공간에 게시하라”고 요청한다.
   2. Atlassian MCP를 통해 비어 있던 Jira 보드에 PHP→React 마이그레이션용 에픽과 단계별 티켓을 채운다.

2. 연결 가능한 업무 도구

   1. Jira뿐 아니라 Linear와 monday.com도 Cursor 플러그인 영역에서 연결할 수 있다.
   2. Atlassian, Datadog, Figma MCP를 사용할 수 있고 Google Drive·Google Calendar·Gmail도 플러그인으로 연결한다.
   3. 계획을 Google Docs에 게시하거나 Cursor로 일정을 잡을 때 캘린더를 참조하는 등 문서·일정·개발 흐름을 이어 붙일 수 있다.

3. Figma 연동

   1. Figma 플러그인은 FigJam 게시와 디자인 시스템 가져오기에 활용한다.
   2. 디자인 시스템 마이그레이션 때 Figma 디자인을 코드 변경의 입력으로 사용할 수 있다.

4.2. 티켓 구조와 병렬 처리

1. 검토 가능한 티켓

   1. 각 Jira 티켓에 목표, 범위, 승인 기준, 테스트, 의존성, 메모를 포함한다.
   2. 상위 티켓과 단계별 티켓을 구분하고, 먼저 부모 티켓을 처리한 뒤 1단계·2단계 작업으로 진행한다.

2. 멀티태스킹 모드

   1. 한 에이전트가 실행되는 동안 다른 에이전트를 좌우로 타일링해 동시에 관찰할 수 있다.
   2. 실행 중인 부모 에이전트의 특정 코드 부분을 선택해 사이드 채팅에 추가하고, 그 패턴이나 의사결정 이유를 별도 질문으로 확인할 수 있다.
   3. 사이드 채팅은 부모 에이전트의 실행과 충돌하지 않으며, /vtw를 사용한 터미널 흐름을 더 사용자 친화적인 UI로 확인하는 방식에 가깝다.

3. 독립 작업의 병렬화

   1. 한 에이전트는 경영진 요약을 줄이고 다른 에이전트는 계획을 Jira 티켓으로 분할하는 식으로 관련성이 낮은 작업을 동시에 처리한다.
   2. 단계가 있는 워크플로에서 독립적인 작업을 병렬화하면 전체 대기 시간을 줄이고, 순차적으로 진행해야 할 티켓은 의존성에 맞춰 다음 단계로 넘길 수 있다.

5. Cursor Cloud Agent로 자율 구현·검증하기

로컬에서 만든 계획과 티켓을 원격 실행 환경으로 넘기면 컴퓨터 자원과 작업 시간의 제약을 줄이면서도 사람은 결과를 리뷰하는 흐름에 집중할 수 있다.

5.1. 로컬에서 클라우드로 넘기는 방법

1. 실행 진입점

   1. 계획 화면에서 클라우드로 바로 빌드하는 버튼을 누르거나, 새 에이전트를 실행할 때 Mac 대신 Cloud를 선택할 수 있다.
   2. 선호하는 방식은 브라우저의 cursor.com/agents에서 에이전트를 관리하는 것이다. 과거 에이전트를 고정하고 GitHub에 있는 저장소를 연결할 수 있다.

2. 다중 저장소 에이전트

   1. Select multiple로 여러 저장소를 하나의 Cloud Agent에 연결할 수 있다.
   2. 마이크로서비스 환경이나 여러 클라이언트가 의존하는 내부 SDK를 운영할 때, SDK의 필드·JSON 변경을 모든 클라이언트 서비스에 전파하는 데 적합하다.
   3. 모노레포가 아니거나 저장소가 작더라도 한 저장소의 컨텍스트를 다른 저장소로 넘겨야 하는 마이그레이션이라면 다중 저장소 기능이 유용하다.

3. 모델과 비용

   1. Cloud Agent도 모델을 유연하게 선택할 수 있지만 장시간 실행하고 로컬 에이전트보다 더 많은 토큰을 사용할 수 있으므로 저렴하고 빠른 모델을 고르는 것이 중요하다.
   2. Grok 4.6, Composer 25, GPT56은 Cursor에서 제공되는 모델로 소개되며 전체 마이그레이션 비용은 약 3~4달러 수준으로 설명된다.
   3. Composer와 GPT 계열을 상황에 따라 사용하고, 비용이 높은 Anthropic 계열 모델은 보통 피한다.

5.2. 장시간 실행과 환경 캐시

1. Long-running Agents

   1. Long-running Agent는 /slashgoal과 비슷하게 완료될 때까지 작업을 계속하며, 종료 시점이나 작업 시간 제한을 지정할 수 있다.
   2. Python 버전 업데이트나 의존성 업데이트처럼 코드 변경과 전체 테스트 통과를 함께 기다려야 하는 작업에 적합하다.

2. 원격 환경 준비

   1. 최초 환경 설정에는 약 10~20분이 걸릴 수 있지만, 이후에는 Build로 환경을 저장해 매 실행마다 설치를 반복하지 않는다.
   2. 설치 스크립트나 스냅샷을 미리 제공하면 큰 WordPress 저장소도 저장된 환경에서 곧바로 작업을 시작할 수 있다.

3. MCP 연결

   1. 로컬에서 사용하던 MCP를 클라우드 환경에도 연결할 수 있으며, Atlassian과 Datadog를 켜고 Google Drive·Granola·PagerDuty 등을 필요에 따라 추가한다.
   2. 에이전트는 Jira MCP에서 연속된 티켓 3개를 찾고, 1단계에 들어가기 전에 부모 티켓을 먼저 확인한다.

5.3. 티켓 단위 구현과 분산 팀 운영

1. 작은 PR 원칙

   1. 담당자에게 배정된 WordPress 보드의 티켓을 찾아 작업하고, 티켓마다 별도 PR을 만들며 스크린샷이나 동영상 녹화로 변경을 검증하도록 요청한다.
   2. 수천 줄의 변경을 하나의 거대한 PR에 넣으면 리뷰가 불가능해지므로 컴포넌트나 서비스별로 여러 PR을 쌓는다.

2. 비동기 협업

   1. 금요일에 밀린 티켓을 Cloud Agent에 맡기고 월요일에 PR을 검토하는 방식으로 백로그를 처리할 수 있다.
   2. 유럽 팀과 아시아 팀이 서로의 수면 시간에 작업을 이어받는 분산 팀에도 적합하며, 항상 실행되는 에이전트가 시간대 사이의 대기 시간을 없앤다.

3. 자율성과 사용자 개입

   1. Cloud Agent는 대부분의 일을 자율적으로 수행하지만 후속 지시를 추가하거나 작업을 중단할 수 있도록 설계되어 있다.
   2. 작업 방향에 동의하지 않으면 브라우저에서 후속 질문을 보내거나 모바일 앱에서 실행을 중단하고, 필요한 지시를 반영한 뒤 다시 진행하게 할 수 있다.

5.4. 원격 브라우저 테스트와 변경 리뷰

1. 컴퓨터를 가진 Linux VM

   1. Cloud Agent는 원격 Linux VM에서 실행되고 데스크톱·마우스에 접근할 수 있다.
   2. 풀스택 프런트엔드 애플리케이션을 브라우저에서 직접 조작하고, 로컬 테스트 스위트와 실제 UI 흐름을 함께 검증할 수 있다.

2. Graphfana 테마 전환 사례

   1. Graphfana 저장소에서 코드베이스의 테마 전환 기능을 구현하도록 요청하고, 에이전트가 자신의 마우스와 컴퓨터로 기능을 직접 실행했다.
   2. 사람의 조작 없이 전체 과정을 녹화해 결과 동영상으로 돌려보내며, 클릭·화면 전환·기능 동작을 기록한다.
   3. 마이그레이션된 코드가 기존 기능을 깨뜨리지 않고 예상대로 동작한다는 신뢰를 높이려면 이런 End-to-End 검증을 PR에 포함해야 한다.

3. 변경·CI·PR 검토

   1. Cloud Agent의 변경 화면은 버전 관리 UI처럼 삭제·추가·수정된 부분을 보여준다.
   2. 모든 변경 사항, CI 체크의 통과 여부, 커밋 이력을 한 화면에서 빠르게 확인할 수 있으며 당시에는 Cursor Bugbot 체크가 하나 표시되었다.
   3. 준비가 되면 PR을 열어 다른 사람의 리뷰를 받고, 티켓별 PR 스택을 오가며 각 PR이 담당한 컴포넌트와 서비스 범위를 비교한다.

6. 모바일에서 이어지는 에이전트 운영

모바일 앱은 에이전트의 실행 장소를 바꾸는 것이 아니라 동일한 Cloud Agent 흐름을 휴대폰까지 확장한다.

6.1. 모바일 에이전트 실행

1. 상태 확인

   1. 앱에서 방금 시작한 Jira 티켓 에이전트와 전날 실행한 에이전트, 개발 환경 설정 작업, 여러 워크스페이스를 확인한다.
   2. 데스크톱에서 앱으로, 다시 브라우저로 돌아오는 흐름이 매끄러워 에이전트가 무엇을 하는지 계속 파악할 수 있다.

2. 새 작업 시작

   1. 특정 저장소와 특정 브랜치에서 에이전트를 빌드하라고 모바일에서 요청할 수 있다.
   2. Graphfana 코드베이스를 설명해 달라는 간단한 요청을 Auto 모드로 보내면, 스마트 라우터가 여러 모델 중 적절한 모델을 선택하고 브라우저에 새 Cloud Agent가 나타난다.

6.2. 이동 중에도 유지되는 사람의 통제

1. 원격 확인

   1. 노트북을 닫고 산책하거나 이동하는 동안에도 에이전트의 작업·결과·검증 기록을 모바일에서 확인한다.
   2. 장시간 작업의 모든 세부 사항을 직접 수행하지 않으면서도 필요한 순간에는 같은 컨텍스트에 개입할 수 있다.

2. 중단과 후속 지시

   1. 에이전트가 예상과 다르게 움직이면 모바일 앱에서 중단하거나 후속 요구사항을 보낸다.
   2. 자율성은 사람의 검토와 통제를 없애는 기능이 아니라, 사람이 원하는 시점에 개입할 수 있도록 대기 시간을 줄이는 운영 방식이다.

7. Automations로 유지보수와 안정성 확보하기

Cursor Automations는 예약되거나 이벤트로 트리거되는 Cloud Agent다. 마이그레이션 직후의 일회성 성공을 장기적인 코드 품질로 바꾸려면 자동화를 유지보수 흐름에 연결해야 한다.

7.1. 트리거와 연결 방식

1. 실행 조건

   1. 정해진 시간에 자동화를 실행할 수 있다.
   2. PR 열림, PR 라벨 변경, Slack·Teams 새 메시지 같은 이벤트를 트리거로 사용할 수 있다.
   3. 사용자 지정 웹훅을 만들 수 있어 Jira 티켓을 To Do에서 In Progress로 끌어올릴 때 실행되도록 연결할 수 있다.

2. 도구 조합

   1. 하나 또는 여러 저장소를 자동화에 연결해 단일 코드베이스와 서비스 묶음을 모두 관리한다.
   2. PR 생성 도구와 Slack 메시지 도구를 조합하고, 완료된 PR을 담당자에게 DM으로 보내 리뷰를 요청한다.

7.2. Feature Flag Cleaner 설계

1. 주기적 정리

   1. 매주 저장소를 검사해 지난 30일 동안 사용되지 않은 오래된 기능 플래그를 찾는다. 30개월·30주라고 잘못 말한 뒤 30일로 바로잡는 짧은 농담이 있었다.
   2. 플래그 제거만 수행하지 않고 제거로 회귀가 발생하지 않았음을 확인하는 테스트까지 포함한 PR을 만든다.

2. 관측 데이터와 교차 확인

   1. 통계 MCP 연결을 시도했으나 연결되어 있지 않아 사용자 지정 MCP 추가가 가능하다는 점을 확인한다.
   2. Datadog와 Sentry의 문제 기록을 교차 확인해 해당 플래그와 관련된 장애가 없었는지 확인한 뒤 제거한다.

3. 사람에게 결과 전달

   1. 작업이 끝나면 PR 링크를 Slack 메시지로 보내도록 지시해 사람이 결과를 검토한다.
   2. 자동화가 코드를 대신 소유하는 것이 아니라 반복 작업·검증·알림을 맡고, 최종 병합 판단은 리뷰어가 내리는 구조다.

7.3. 사후 대응을 사전 예방으로 바꾸는 템플릿

1. 레거시가 쌓이는 원인

   1. “어떻게 코드베이스가 이런 상태가 되었을까?”라는 질문의 답은 의존성 업데이트와 선제적 관리가 충분하지 않았기 때문인 경우가 많다.
   2. 미리 작은 문제를 해결하지 않으면 기능 플래그와 의존성이 쌓이고, 나중에 큰 리팩터링을 한꺼번에 감당해야 한다.

2. 재사용 가능한 자동화 템플릿

   1. 테스트 커버리지 추가, 코드베이스 취약점 검사, 인시던트 분류 템플릿을 바로 시작점으로 사용할 수 있다.
   2. Datadog 알림 채널, PagerDuty, incident.io와 연결해 장애 초기 조사를 자동으로 수행할 수 있다.

3. 온콜과 문서화

   1. 새벽 3시에 담당자를 깨우기 전에 에이전트가 초기 조사를 하고 담당자에게 발견 사항을 짧게 요약한다.
   2. 결과는 Slack·Datadog로 보내거나 Notion·Confluence에 게시하도록 맞춤 설정할 수 있다.
   3. 자동화를 서로 연결하거나 사용자 지정 웹훅을 더하면 단일 작업을 넘어 지속적인 운영 시스템이 된다.

8. 완성된 PHP→React 마이그레이션의 증거

실시간으로 실행한 작업이 행사 시간 안에 끝나지 않더라도, 완료된 이전 실행 결과를 통해 원하는 산출물의 기준을 확인할 수 있다.

8.1. 두 컴포넌트와 End-to-End 동영상

1. 범위 제한

   1. PHP에서 React로 두 개의 특정 컴포넌트를 이전하고, End-to-End 테스트로 정상 동작을 확인한다.
   2. PR 규모가 이미 큰 경우 더 많은 컴포넌트를 한 번에 확장하지 않고 두 컴포넌트만 범위에 남겨 리뷰 가능성을 지킨다.

2. 동영상 검증 흐름

   1. 에이전트가 화면을 클릭하며 이전된 기능과 기존 데이터가 예상대로 대체·표시되는지 확인한다.
   2. 로그인, 댓글 보기, 사용자 보기 구간을 동영상 안에 라벨로 표시해 어떤 UI 시나리오를 검증했는지 추적할 수 있게 한다.

3. PR 스택으로 확장

   1. 두 Jira 티켓에 대해 두 개의 PR을 만들고, 각 PR을 열어 어느 변경이 어느 티켓을 담당하는지 비교한다.
   2. 여러 컴포넌트나 서비스를 마이그레이션할 때 이런 다중 티켓·다중 PR 구조가 거대한 단일 PR보다 리뷰와 롤백에 유리하다.

9. 질문과 답변: 보안·학습·네트워크·복구

9.1. 환경 변수와 Cloud Agent 보안

1. 비밀 정보 저장

   1. 환경 변수, API 키, 시크릿은 Cursor Cloud 환경 설정에 저장한다.
   2. 환경을 만들 때 필요한 키를 입력하고 라우팅 규칙을 지정할 수 있다.

2. 접근 제한

   1. 특정 IP를 허용 목록에 추가해 Cloud Agent가 정해진 링크에만 접근하도록 제한한다.
   2. 데이터 저장 위치와 보관 기간을 비롯한 보안·시크릿·프라이빗 연결 정보는 cursor.com/cloud와 기업용 문서에서 확인한다.

9.2. 플러그인에 포함된 Skills와 지속 학습

1. 플러그인 Skills

   1. Atlassian 플러그인은 MCP뿐 아니라 Atlassian 팀이 게시한 Skills도 함께 제공한다.
   2. Figma 플러그인도 MCP와 함께 여러 Skills를 제공하므로 자주 사용하는 도구의 업무 방식을 바로 재사용할 수 있다.

2. 저장소 온보딩 Skill

   1. Gutenberg WordPress 서브저장소에 새로 들어갔을 때 /onboard라는 자체 Skill을 사용해 기술 스택, 필요한 Python 버전, 프로그램 역할, 백엔드·프런트엔드 위치를 확인한다.
   2. Cursor 팀이 오픈 소스로 공개한 Skills 목록과 모두가 사용할 수 있는 Superpowers 플러그인도 재사용 가능한 출발점이다.

3. 직접 만드는 Skill과 지속 학습

   1. Cursor의 Create Skill 기능으로 자신의 코딩 스타일과 업무 흐름에 맞는 워크플로우를 만들 수 있다.
   2. Continual Learning 플러그인은 agents.mmd 파일에 작업 방식, 글쓰기 스타일, 코딩 스타일 정보를 기록하고 개인용 또는 팀용으로 적용한다.
   3. 각 Automation에는 memories.mmd 파일이 있어 실행 중 놓친 항목이나 Slack 문구에 대한 사용자의 후속 피드백을 다음 실행에 반영한다.

9.3. 사설 네트워크와 로컬 데이터 연결

1. Private Connectivity

   1. Azure 사설 네트워크 안에 서비스가 있다면 Cursor 문서의 Private Connectivity 옵션을 검토한다.
   2. AWS 밖에서는 Cloudflare Tunnel, AWS에서는 AWS PrivateLink를 사용할 수 있고 Tailscale 같은 VPN도 선택지다.

2. 자체 호스팅 선택

   1. 인프라를 자체 네트워크 안에 유지하면서 Cloud Agent를 사용해야 한다면 자체 호스팅 Cloud Agent도 선택할 수 있다.
   2. 보안 요구가 높은 고객은 PrivateLink·터널·VPN과 Cursor 보안 기능을 조합하거나 Cursor Cloud의 보안을 신뢰해 운영하며, 자체 호스팅을 처음부터 권장하는 방식은 아니다.

3. 예약 자동화와 로컬 파일

   1. 저장소에 커밋된 계획, Skill, 파일은 예약된 Automation이 접근할 수 있다.
   2. 사용자 컴퓨터에만 있는 로컬 파일은 Cloud Agent가 직접 볼 수 없으므로 PrivateLink·터널 등 별도 연결이 필요하다.

9.4. 실행 충돌·복구와 Cloud MCP

1. 과거 대화 참조

   1. 로컬 Cursor에서는 @chats로 이전 대화를 컨텍스트로 불러올 수 있다.
   2. Cloud Agent가 충돌했을 때 동일한 과거 대화 참조가 가능한지는 확실하지 않으며, 이 기능이 클라우드까지 확장되는지 별도 확인이 필요하다.

2. Cloud MCP 진단

   1. Cursor Cloud MCP를 사용하면 실패한 실행, 환경 설정, 환경 문제를 진단할 수 있다.
   2. 에이전트가 접근할 수 있는 정보와 실행 기록을 점검하는 보조 수단으로 Cursor 문서의 Cloud MCP를 활용한다.

9.5. Grokbot과 클라우드·로컬 병행

1. 로컬 인프라가 필요한 경우

   1. 예약된 Cloud Agent가 로컬 인프라의 데이터에 접근해야 하면 AWS PrivateLink나 Cloudflare Tunnel을 구성한다.
   2. 로컬 계획이 저장소에 커밋되어 있다면 Automation이 그 계획과 저장소 내 Skills·파일을 직접 읽을 수 있다.

2. 추가 도구

   1. Grokbot은 일반 지식 학습 제품으로 소개되지만 코딩 학습에도 사용할 수 있다.
   2. 클라우드와 로컬을 함께 사용해 한 컴퓨터에서 여러 작업을 처리하는 방법을 다루는 워크숍이 다음 주 목요일에 예정되어 있다.

주요 발언 모음

“AI로 레거시 코드베이스를 리팩터링하는 가장 좋은 방법은 무엇이고, 왜 Cursor를 사용해야 하는가?”

“Plan Mode에서는 코드를 직접 작성하지 않고 전략만 작성한다.”

“모델과 플랫폼 이상의 것이 있다. 그 위에 Cursor harness가 있다.”

“수천 줄의 코드가 담긴 거대한 PR 하나가 아니라, 서로 다른 컴포넌트나 서비스를 다루는 여러 PR을 원한다.”

“Cloud Agent의 목표는 대부분의 작업을 처리하면서도 사용자가 원할 때 계속 상황을 파악할 수 있게 하는 것이다.”

“자동화는 사후 대응이 아니라 선제적 대응으로 코드베이스를 유지하는 방법이다.”

핵심 데이터 & 수치

• 4단계: Canvas 감사·Plan Mode 전략 수립 → 플러그인으로 티켓화 → Cloud Agent 구현·검증 → Automation 유지보수.
• 약 6개월: 그 사이 Cursor를 사용하지 않았다면 에이전트 창이 새롭게 보일 수 있다고 설명한다.
• 최소 5개 질문: Ask Question 도구가 계획 작성 전에 물을 질문 수를 설정할 수 있다.
• 약 3~4달러: 저렴하고 빠른 Cursor 모델을 사용한 전체 마이그레이션 비용의 예시다.
• 약 10~20분: 원격 환경 최초 설정에 걸리는 시간이며 이후 Build로 재사용한다.
• 30일: Feature Flag Cleaner가 사용되지 않은 오래된 기능 플래그를 찾는 기준이다.
• 2개 컴포넌트: 완성된 PHP→React 사례에서 이전한 범위다.
• 3개 연속 티켓: Cloud Agent가 Jira에서 찾아 부모 티켓을 먼저 처리한 뒤 진행한 예시다.
• iOS 우선: 모바일 앱은 당시 iOS App Store에서 제공되며 Android는 출시 예정이었다.

결론 및 시사점

1. 먼저 관찰하고 범위를 줄인다: Canvas로 테스트 커버리지·레거시 위치·마이그레이션 우선순위를 시각화하고, 한 화면·한 앵커 컴포넌트부터 시작한다.
2. 코드보다 계획을 먼저 고정한다: Plan Mode의 질문과 TDD 템플릿으로 기능·비기능 요구사항, 아키텍처, API·데이터 모델·플래그 변경, 테스트 전략을 문서화한다.
3. 계획을 리뷰 단위로 변환한다: Atlassian MCP로 부모·단계·컴포넌트별 Jira 티켓을 만들고 목표·승인 기준·테스트·의존성을 명시한다.
4. 자율성은 원격 실행으로 확보한다: Cloud Agent에 티켓을 넘겨 노트북을 닫은 뒤에도 작업하게 하고, 다중 저장소 컨텍스트와 저장된 Build 환경으로 반복 비용을 줄인다.
5. 검증 증거를 산출물에 포함한다: Linux VM의 데스크톱·마우스로 실제 UI를 End-to-End 테스트하고, 스크린샷·동영상·CI·커밋·PR 리뷰를 함께 확인한다.
6. 큰 변경을 작은 PR로 쪼갠다: 수천 줄짜리 PR 하나 대신 컴포넌트·서비스별 다중 티켓과 다중 PR을 만들어 리뷰·롤백·병렬 협업을 가능하게 한다.
7. 반복되는 운영 문제를 자동화한다: 기능 플래그 정리, 의존성 업데이트, 취약점 검사, 테스트 커버리지, 인시던트 초기 조사를 예약·이벤트·웹훅으로 연결한다.
8. 사람을 루프에서 제거하지 않는다: Cloud Agent와 Automation은 일을 대신하지만, 후속 지시·중단·PR 리뷰·최종 병합 판단은 사람이 맡는다.
9. 팀의 지식을 파일과 플러그인에 남긴다: agents.mmd와 memories.mmd, 팀 Skills, 저장소에 커밋한 계획으로 다음 실행이 이전 피드백을 활용하게 한다.
10. 보안 경계를 먼저 설계한다: 비밀 키·허용 IP·PrivateLink·Cloudflare Tunnel·VPN·자체 호스팅을 조직의 네트워크와 데이터 보존 정책에 맞춰 선택한다.

핵심 요약 (20줄)

1. Tech Bridge는 Cursor로 Lexi 코드베이스와 WordPress 레거시 코드를 안전하게 리팩터링하는 방법을 소개한다.
2. Cursor는 에이전트 창, VS Code 포크 IDE, CLI, 브라우저, Slack, 모바일 앱을 하나의 개발 흐름으로 묶는다.
3. Cloud Agent는 원격 컴퓨터에서 자율적으로 실행되므로 노트북을 닫아도 장기 작업을 계속한다.
4. 여러 모델을 목적별로 조합하면 계획 품질과 코드 실행 속도를 동시에 확보하면서 비용을 낮출 수 있다.
5. Cursor harness는 도구 실행, 캐시 관리, 동적 컨텍스트 관리, 컨텍스트 조립을 담당한다.
6. 첫 단계는 Canvas로 코드베이스의 테스트 커버리지와 레거시 컴포넌트를 감사하는 일이다.
7. Canvas는 관리자 화면별 커버리지, QUnit 테스트가 없는 client.js, React 컴포넌트를 시각화한다.
8. Canvas 결과는 편집하고 공유하거나 PDF로 내려받아 팀의 기술 자료로 활용할 수 있다.
9. Plan Mode는 코드 대신 Markdown 전략 문서를 작성하고 TDD 템플릿을 일관되게 적용한다.
10. Ask Question 도구는 범위를 한 화면이나 특정 앵커 컴포넌트로 좁히기 전에 요구사항을 묻는다.
11. 계획에는 기능·비기능 요구사항, 현재·목표 아키텍처, 데이터 흐름, API·데이터 모델·기능 플래그가 포함된다.
12. Atlassian MCP는 계획을 목표·범위·승인 기준·테스트·의존성을 가진 Jira 티켓으로 분할한다.
13. Cloud Agent는 여러 저장소를 연결해 내부 SDK 변경을 마이크로서비스 전체에 전파할 수 있다.
14. 원격 환경은 최초 10~20분 설정 후 Build로 저장하며, 전체 마이그레이션 비용은 약 3~4달러로 제시된다.
15. Long-running Agent는 의존성이나 Python 버전 업데이트를 전체 테스트가 끝날 때까지 수행한다.
16. Linux VM의 데스크톱과 마우스는 브라우저 UI를 직접 조작하고 End-to-End 동영상을 만든다.
17. 마이그레이션은 수천 줄의 단일 PR 대신 컴포넌트·서비스별 다중 티켓과 다중 PR로 관리한다.
18. Automations는 일정, PR·라벨 이벤트, Slack·Teams 메시지, Jira 웹훅으로 Cloud Agent를 실행한다.
19. Feature Flag Cleaner는 30일 동안 사용되지 않은 플래그를 Datadog·Sentry와 교차 확인한 뒤 테스트 포함 PR을 연다.
20. 성공적인 운영은 Canvas 감사, Plan Mode 전략, 플러그인 티켓화, Cloud Agent 실행, Automation 예방 관리의 순환을 만든다.