{
  "title": "Cursor와 함께한 1년: 에이전트에서 아키텍트로 진화한 나의 워크플로우",
  "excerpt": "Cursor와의 여정은 이 도구 자체의 성숙을 반영합니다: 단순한 에이전트에서 정교한 아키텍처 파트너로. 이 글에서는 @ mentions, MCP, Plan Mode, 그리고 custom commands를 통해 나의 워크플로우가 어떻게 진화했는지 상세히 다룹니다.",
  "content_html": "<p>Cursor를 주요 IDE로 삼은 지 1년이 넘었으며, 이것이 제 업무에 미친 영향을 과장해서 말할 수 없습니다. Dylog에서 대화형 AI 플랫폼을 구축하고 개인 프로젝트로 agentic 인프라를 실험하는 머신 러닝 엔지니어로서, 저는 AI-native 개발의 진화를 직접 경험해왔습니다. Cursor와의 여정은 이 도구 자체의 성숙을 반영합니다: 단순한 에이전트에서 정교한 아키텍처 파트너로.</p>\n<p>이 글은 그 여정에 대한 성찰이며, 워크플로우가 어떻게 진화했는지, 그리고 어떻게 Plan Mode, custom commands, 그리고 context engineering의 강력한 조합에 의지하게 되어 더 빠르고, 더 똑똑하며, 더 명확하게 빌드하게 되었는지를 상세히 다룹니다.</p>\n<h2>Phase 1: 에이전트가 핸들을 잡다</h2>\n<p>처음 시작했을 때, 저의 사용 방식은 단순했습니다. 저는 Cursor를 고성능 자동완성 도구처럼 다뤘습니다. 주석을 작성하고 <code>Cmd+K</code>를 누르면 에이전트가 코드를 생성하도록 내버려두었죠. 마법 같았지만, 동시에 블랙박스였습니다. 저는 승객이었고, 에이전트가 운전하고 있었습니다.</p>\n<p>그러다 <strong>@ mentions</strong>가 등장했습니다. 이것은 에이전트에게 실제 컨텍스트를 제공한 첫 경험이었습니다. 코드베이스를 이해하길 바라는 대신, 명시적으로 무엇을 봐야 하는지 알려줄 수 있게 되었습니다:</p>\n<ul>\n<li><code>@file</code>: 특정 파일을 참조합니다</li>\n<li><code>@folder</code>: 전체 디렉토리를 포함합니다</li>\n<li><code>@codebase</code>: 전체 프로젝트를 검색하도록 합니다</li>\n<li><code>@web</code>: 외부 문서를 가져옵니다</li>\n<li><code>@docs</code>: 라이브러리의 공식 문서를 참조합니다</li>\n</ul>\n<p>이것은 엄청난 도약이었습니다. 갑자기 에이전트는 추측하지 않았습니다; 저와 동일한 컨텍스트를 가지고 작업하고 있었습니다. 저는 \"이 함수를 <code>@file:utils/helpers.ts</code>의 패턴에 맞게 리팩토링해줘\"라고 말할 수 있었고, 에이전트는 실제로 이해했습니다.</p>\n<img src=\"/assets/images/cursor-at-mentions.webp\" alt=\"Cursor @ mention context\" class=\"post-img\" width=\"1639\" height=\"935\">\n<span class=\"post-img-caption\">Cursor의 @ mention 드롭다운으로, @file, @folder, @codebase, @web, @docs와 같은 컨텍스트 옵션을 보여주며 명시적인 컨텍스트 제어를 가능하게 합니다</span>\n<p>하지만 더 나은 컨텍스트를 가지고도, 저는 종종 생성하고, 디버깅하고, 다시 생성하는 루프에 빠지곤 했습니다. 에이전트는 더 큰 작업에 대한 아키텍처적 비전이 부족했습니다.</p>\n<h2>Phase 2: MCP가 모든 것을 바꾸다</h2>\n<p><strong>Model Context Protocol(MCP)</strong>의 도입은 일이 진지해지기 시작한 순간이었습니다. MCP를 통해 Cursor를 외부 도구와 데이터 소스에 연결할 수 있게 되면서, 에이전트는 코드 생성기에서 제 전체 워크플로우에 접근할 수 있는 진정한 어시스턴트로 변모했습니다.</p>\n<p>저는 다음을 위해 MCP를 통합하기 시작했습니다:</p>\n<ul>\n<li><strong>GitHub</strong>: issues와 PRs를 컨텍스트에 직접 가져오기 위해</li>\n<li><strong>Linear</strong>: 태스크 관리 통합을 위해</li>\n<li><strong>Slack</strong>: 팀 커뮤니케이션 컨텍스트를 위해</li>\n<li><strong>Custom MCPs</strong>: 내부 API와 데이터베이스를 위해</li>\n</ul>\n<p>MCP를 통해 저는 \"Linear issue #234에 설명된 기능을 구현해줘\"라고 말할 수 있었고, 에이전트는 해당 이슈를 가져와 요구사항을 이해하고 빌드를 시작했습니다. 이제 더 이상 코드만의 문제가 아니었습니다; 개발 생태계 전반에 걸쳐 점들을 연결하는 것이었습니다.</p>\n<img src=\"/assets/images/cursor-mcp-integrations.webp\" alt=\"MCP integrations in Cursor\" class=\"post-img\" width=\"1639\" height=\"935\">\n<span class=\"post-img-caption\">GitHub, Linear, Slack, 그리고 custom servers와 같은 연결된 통합 기능을 보여주는 MCP 설정 패널로, Cursor의 기능을 개발 생태계 전반으로 확장합니다</span>\n<h2>Phase 3: 플래너의 부상</h2>\n<p><strong>Plan Mode</strong>의 도입은 다음 게임 체인저였습니다. 이것은 AI와 협업하고 있다고 느낀 첫 순간이었습니다. 단순히 위임하는 것이 아니라 말이죠. Ray Fernando와 같은 개발자들의 워크플로우에서 영감을 받아, 저는 두 단계 프로세스를 사용하기 시작했습니다:</p>\n<ol>\n<li><strong>Opus로 계획하기:</strong> 저는 Claude Opus와 같은 강력한 모델을 사용하여 상세한 단계별 구현 계획을 생성했습니다. 높은 수준의 목표를 주면, 파일 이름, 함수 시그니처, 그리고 로직을 갖춘 일련의 구체적인 작업으로 세분화했습니다.</li>\n<li><strong>Sonnet/GPT로 실행하기:</strong> 그런 다음 해당 계획을 Sonnet이나 GPT-5.2와 같은 더 빠르고 저렴한 모델에 전달하여 각 단계를 실행하게 했습니다. 더 저렴한 모델은 뛰어난 아키텍트일 필요가 없었습니다; 성실한 빌더이기만 하면 되었습니다.</li>\n</ol>\n<p>이 워크플로우는 엄청난 개선이었습니다. \"무엇(what)\"과 \"어떻게(how)\"를 분리했고, 코드가 작성되기 전에 편집하고 승인할 수 있는 계획이라는 검토 가능한 산출물을 제공했습니다. 또한 토큰 비용도 엄청나게 절약했습니다.</p>\n<img src=\"/assets/images/cursor-plan-mode.webp\" alt=\"Cursor Plan Mode workflow\" class=\"post-img\" width=\"1639\" height=\"935\">\n<span class=\"post-img-caption\">왼쪽에 <code>.cursor/plans/</code> 파일의 상세한 구현 계획, 오른쪽에 해당 생성된 코드를 보여주는 분할 뷰로, 아키텍처와 실행의 분리를 보여줍니다</span>\n<h2>Phase 4: 아키텍트의 등장 (Commands + Planning)</h2>\n<p>이것이 바로 제가 현재 작업하는 방식입니다. Plan Mode가 여전히 워크플로우의 중심이지만, 저는 프로세스를 미세 조정하고 아키텍처 원칙을 IDE에 직접 녹여내기 위해 일련의 <strong>custom commands</strong>와 <strong>rules</strong>를 추가했습니다.</p>\n<h3>나의 현재 설정</h3>\n<p><strong>Rules (<code>.cursorrules</code>):</strong> 저는 코딩 표준, 선호하는 패턴, 그리고 아키텍처적 제약을 정의하는 규칙 세트를 가지고 있습니다. 에이전트는 모든 작업 전에 이것들을 읽어 코드베이스 전반에 걸쳐 일관성을 보장합니다.</p>\n<p><strong>Custom Commands:</strong> 저는 가장 일반적인 워크플로우를 감싸는 커맨드를 만들었습니다:</p>\n<ul>\n<li><code>/plan</code> - Opus를 사용하여 상세한 구현 계획을 생성합니다</li>\n<li><code>/refactor</code> - 파일을 가져와 지시에 따라 리팩토링합니다</li>\n<li><code>/test</code> - 주어진 함수에 대한 테스트 스위트를 생성합니다</li>\n<li><code>/review</code> - 규칙에 따라 코드를 검토하고 개선 사항을 제안합니다</li>\n</ul>\n<p><strong>Queued Messages:</strong> 저는 에이전트가 작업하는 동안 후속 지시를 대기시키기 위해 <code>Ctrl+Enter</code>를 사용합니다. 이를 통해 미리 생각하고 현재 작업을 중단하지 않고 모멘텀을 유지할 수 있습니다.</p>\n<img src=\"/assets/images/cursor-custom-commands.webp\" alt=\"Cursor custom commands and rules\" class=\"post-img\" width=\"1639\" height=\"935\">\n<span class=\"post-img-caption\"><code>/plan</code>, <code>/refactor</code>, <code>/test</code>, <code>/review</code>와 같은 custom commands를 보여주는 Cursor 커맨드 팔레트와 코딩 표준 및 아키텍처 제약을 정의하는 <code>.cursorrules</code> 파일</span>\n<h2>한눈에 보는 진화</h2>\n<table>\n<thead>\n<tr>\n<th>단계</th>\n<th>핵심 기능</th>\n<th>변화한 점</th>\n</tr>\n</thead>\n<tbody>\n<tr>\n<td>1</td>\n<td>Agent Mode + @ Mentions</td>\n<td>컨텍스트가 추측이 아닌 명시적으로 변했습니다</td>\n</tr>\n<tr>\n<td>2</td>\n<td>MCP Integration</td>\n<td>외부 도구와 데이터에 접근할 수 있게 되었습니다</td>\n</tr>\n<tr>\n<td>3</td>\n<td>Plan Mode</td>\n<td>아키텍처와 실행이 분리되었습니다</td>\n</tr>\n<tr>\n<td>4</td>\n<td>Commands + Rules</td>\n<td>워크플로우가 반복 가능하고 개인화되었습니다</td>\n</tr>\n</tbody>\n</table>\n<h2>왜 이것이 중요한가</h2>\n<p>에이전트에서 아키텍트로의 이러한 진화는 단순한 개인의 생산성 해킹 이상입니다. 이것은 소프트웨어 개발의 미래를 엿볼 수 있는 창입니다. 우리는 코드를 작성하는 세상에서 <strong>시스템을 설명하는</strong> 세상으로 이동하고 있습니다. 우리의 역할은 아키텍트가 되고, 청사진을 정의하며, 에이전트가 빌딩을 하도록 하는 것입니다.</p>\n<p>Cursor는 제가 사용한 어떤 도구보다도 이러한 전환을 이해하고 있습니다. 이것은 단순히 코드를 생성하는 것이 아닙니다; 복잡성을 관리하고, 컨텍스트를 유지하며, 개발자들이 이전에는 상상할 수 없는 규모로 빌드할 수 있는 레버리지를 제공하는 것입니다.</p>\n<p>만약 여러분이 여전히 AI를 단순한 코드 생성기로 사용하고 있다면, @ mentions, MCP, Plan Mode, 그리고 custom commands를 탐색해 보시길 권합니다. 이것은 AI를 사용하는 개발자에서 AI를 지휘하는 아키텍트로 변모시키는 여정입니다.</p>",
  "source_hash": "sha256:414a9187cf9ba648188a0c14e26a1e88844cad86a23d18e16d6b9df6b5c9add2",
  "model": "moonshotai/kimi-k2.6",
  "generated_at": "2026-08-07T07:12:52.713086+00:00"
}