안녕하세요 👋

최근까지 저의 AI 코딩 설정은 업계의 절반이 사용하는 방식인 GitHub Copilot이 포함된 VS Code의 기본 설정이었습니다. 그러다 가격 정책이 변경되었고, 계산을 해보니 결과가 좋지 않았습니다. 구독 비용 계산 방식이 바뀌었습니다. 크레딧이 소진되면 저를 제한하는 단 하나의 "만능 도구 (God-tool)"에 매달 200달러를 쓰는 대신, 그 예산을 Claude와 Cursor의 연간 플랜, 그리고 할인된 Antigravity 티어에 나누어 배분했습니다. 이제 저는 프리미엄 크레딧을 사용하여 최적의 모델로 작업을 설계하고, 단순 반복 작업은 OpenCode와 같은 무료 티어 도구에 맡깁니다. 만약 도구의 토큰이 소진된다면, 그것은 그저 휴식을 취하라는 신호일 뿐입니다.

저는 이번 이전을 단순히 하나의 구독을 다른 것으로 교체하는 것이 아니라, 전체적인 시스템을 재고하는 계기로 삼았습니다. 오늘 저는 마이크가 강력한 제어 모드로 들어가 무언가로 전환했다가 다시 아날로그 스테레오 듀플렉스로 돌아가야만 작동한다는 것을 알게 되었습니다. 마이크를 영구적으로 어떻게 고칠 수 있을까요? 저는 네 가지 도구, 즉 주력 도구인 Claude Code와 Cursor, 그리고 백업용인 Antigravity와 OpenCode를 사용합니다. 각 도구가 제 자리를 찾아가는 것을 확인하기 전까지는 이것이 과도해 보일 수 있습니다. 이 설정을 몇 달간 사용한 후, 비슷한 환경을 구축하려는 모든 분께 드릴 수 있는 열 가지 팁을 정리했습니다.

1. 모든 것을 도구에 구애받지 않게 유지하기 (Keep everything tool-agnostic)

Copilot을 떠나며 배운 가장 중요한 한 가지는, 특정 도구에 종속되지 말라는 것이며, 여기에는 해당 도구의 설정 형식도 포함됩니다. CLAUDE.md 대신 AGENTS.md를 사용하세요. 이제 대부분의 에이전트가 이를 읽을 수 있으며, 특정 파일 이름을 고집하는 도구들을 위해 심볼릭 링크 (symlink)를 사용할 수도 있습니다. 규칙과 컨벤션은 저장소 (repo) 내에 한 번만 작성하여 어떤 도구든 소비할 수 있는 형식으로 유지하세요. 다음 가격 정책 변경이 닥쳤을 때, 전환에 드는 비용은 일주일이 아니라 단 한 오후면 충분해야 합니다.

IDE를 넘어, 저는 Claude나 Gemini와 같은 일반 모델들을 코딩하지 않는 "사고 (thinking)" 계층으로 취급합니다. 이들은 계획 수립, 심층 조사, 제품 마케팅 초안 작성, 심지어 제 이력서 검토까지 담당합니다. 또한 홈 오피스 배치를 위한 가구 치수 확인부터 식물 관리에 대한 구체적인 조언을 얻는 것까지, 코드 에디터에 속하지 않는 일상 관리 작업에도 이들을 활용합니다.

2. 하나의 만능 에이전트(god-agent)가 아닌, 특화된 에이전트 군단(fleet)을 운영하세요

계획을 세우고, 코드를 작성하고, 리뷰하고, 푸시(push)까지 수행하는 에이전트는 이 네 가지 일을 모두 서투르게 해낼 것입니다. 저의 설정은 작업을 전문화된 역할로 나눕니다: 프로젝트 플래너(Project Planner), 오케스트레이터(Orchestrator), 그리고 코드 푸셔(Code Pusher)입니다. 특화된 에이전트(Narrow agents)는 경로를 이탈할 확률이 적고, 더 적은 컨텍스트(context)를 요구하며, 하나가 제대로 작동하지 않을 때 어떤 특정 프롬프트(prompt)를 수정해야 하는지 정확히 알 수 있습니다. 이러한 모듈화(modularity)는 개발 생명주기(development lifecycle)의 각 부분이 방대한 지시 사항과 씨름하는 일반론자가 아닌, 집중된 전문가에 의해 처리되도록 보장합니다.

저는 이 흐름을 task-.md 파일로 관리하며, 이 파일은 에이전트 군단(fleet)을 위한 공유 브레인(shared brain) 역할을 합니다. 이 파일에는 단계별 명확한 체크리스트가 포함되어 있으며, 특정 "훅(hooks)"—즉, 한 에이전트가 상태 업데이트를 남기면 다음 에이전트가 이를 이어받는 잘 정의된 인계 지점(handoff points)—을 사용합니다. 이 시스템을 통해 작업 중간에 제공자(provider)를 변경하더라도, 제가 지시 사항을 반복하지 않아도 새로운 에이전트가 무엇이 완료되었고 다음 목표가 무엇인지 정확히 알 수 있습니다.

3. 코드 리뷰어에게 성격을 부여하세요

저의 코드 리뷰어는 드라마 <실리콘 밸리(Silicon Valley)>의 길포일(Gilfoyle)을 모델로 합니다. 말투는 비꼬는 태도(sarcasm), 농담, 그리고 봐주는 것 없는 차갑고 냉혹한 비판이 주를 이룹니다. 다소 거칠게 들릴 수 있지만, 건조하고 로봇 같은 응답보다 훨씬 더 주의를 기울이게 만들기 때문에 PR(Pull Request) 리뷰를 읽는 것이 오히려 즐거움이 됩니다. 에이전트가 보안 결함이나 지저분한 함수에 대해 진심으로 "못되게" 굴 때, 저는 그 피드백을 무시할 가능성이 훨씬 낮아집니다.

냉소적인 말투 속에서 중요한 조언을 놓치지 않기 위해, 저는 중요한 출력값에 대해 "주의 사항(caveat)" 구조를 구현했습니다. 에이전트가 즉각적인 수동 개입이 필요하거나 높은 위험을 수반하는 사항을 식별할 때마다, 해당 내용을 특정 시각적 콜아웃(callout)으로 감쌉니다. 이는 해당 정보가 저의 온전하고 집중된 주의를 기울일 만큼 중요하다는 신호를 보내며, 중요한 기술적 경고를 스타일적인 냉소와 분리해 줍니다.

4. 코딩하기 전에 먼저 계획하세요

제가 사용하는 모든 도구에는 '계획 모드 (plan mode)'가 있으며, 저는 단일 파일 변경보다 큰 작업을 수행할 때는 항상 이를 사용합니다. 텍스트 기반의 계획을 수정하는 데는 문장 하나면 충분하지만, 모노레포 (monorepo) 전체에 걸쳐 잘못된 디프 (diff)를 풀어내는 데는 오후 전체를 허비해야 할 수도 있습니다. 에이전트가 계획을 보여주게 하고, 그 단계에서 에이전트와 논쟁하십시오. 그리고 아키텍처적 접근 방식에 대해 양측이 모두 합의했을 때만 에이전트가 파일에 접근하도록 허용하세요. 이 단계는 기술 부채 (technical debt)를 방지하기 위한 가장 큰 예방 조치입니다.

에이전트가 무거운 작업을 처리하거나 코드를 생성하는 동안, 그냥 가만히 앉아 있지 마세요. 저는 그 시간을 활용해 엣지 케이스 (edge cases)에 대한 수동 노트를 작성하거나, 에이전트가 신경 쓰지 않기를 바라는 UI의 작고 정밀한 수정 사항들을 처리합니다. 이러한 병렬 처리 (parallel processing)는 추진력을 유지해 줍니다. 에이전트가 "큰 작업"을 마칠 때쯤이면 저는 이미 주변의 세부 사항들을 다듬어 놓은 상태가 되어, 결과적으로 전체 사이클 타임 (cycle time)을 훨씬 단축할 수 있습니다.

5. 스킬 팩토리 (skill factory)를 구축하세요

이 방법은 제가 새로운 프로젝트에 온보딩 (onboarding)하는 방식을 바꾸어 놓았습니다. 저는 다른 스킬과 에이전트를 생성하는 것만을 목적으로 하는 전용 "팩토리 (factory)" 스킬을 작성했습니다. 새로운 리포지토리 (repo)를 지정하면, 그 팩토리는 당일 사용 중인 도구에 맞춰 포맷팅된 특화된 에이전트 정의를 스캐폴딩 (scaffolds)합니다. 예전에는 커스텀 에이전트를 설정하는 데 수동 구성으로 저녁 시간을 통째로 써야 했지만, 이제는 프로젝트별 워크플로우의 전체 기반이 단 몇 분 만에 마련됩니다.

이 팩토리는 제가 선택한 프로바이더 (providers)와 프로젝트의 특정 코딩 컨벤션 (coding conventions)에 대한 정보를 선제적으로 요청함으로써 작동합니다. 스택 (stack)과 규칙을 이해하고 나면, 팩토리는 스킬들이 리포지토리의 아키텍처와 완벽하게 일치하도록 필요에 따라 스킬을 자동으로 생성하거나 업데이트합니다. 이러한 자동화 덕분에 제가 가동하는 모든 에이전트는 첫 번째 코드 라인을 작성하기도 전에 프로젝트의 특정 스타일 가이드 (style guides)와 라이브러리 선택 사항에 대해 이미 "검증 (vetted)"된 상태가 됩니다.

6. 사용 가능한 최고의 추론 모델 (reasoning model)로 스킬을 작성하세요

스킬 (Skills)은 시간이 지남에 따라 복리로 쌓입니다. 한 번 작성하면 수백 번 실행되기 때문에, 스킬을 작성하는 데 사용된 토큰 비용보다 초기 작성 품질이 훨씬 더 중요합니다. 저는 시장에서 가장 비싼 모델이라 할지라도, 제가 접근할 수 있는 가장 강력한 추론 모델 (reasoning model)을 사용하여 항상 스킬 초안을 작성합니다. 완벽하게 표현된 스킬은 이후 이를 실행하는 모든 저렴한 모델의 성능을 배가시키는 승수 효과 (force multiplier)를 가져옵니다.

향후 수천 번의 세션을 안내할 단 하나의 문서를 위해 프리미엄 토큰 비용을 지불하는 것은, 이 전체 설정에서 가장 쉬운 거래입니다. 만약 "마스터 지침 (master instruction)"이 결함이 없다면, 더 작고 빠른 모델들도 높은 신뢰도로 작업을 수행할 수 있습니다. 초기 고성능 추론 초안에 투자하는 것은, 이후 몇 주 동안 제대로 따르지 않는 지침을 디버깅하며 겪게 될 좌절감을 방지해 줍니다.

7. 컨텍스트 (context)를 적절히 관리하세요

활성화된 상태로 두는 모든 MCP 서버, 스킬, 파일은 프롬프트의 단 한 단어를 입력하기도 전에 이미 컨텍스트 예산 (context budget)을 잠식합니다. 저는 작업마다 이를 엄격하게 토글 (toggle)합니다. 코드를 배포할 때는 git 도구가 켜져 있지만, 문서를 작성할 때는 꺼둡니다. 브라우저 도구는 실시간 테스트가 구체적으로 필요한 경우에만 활성화합니다. 이러한 절제는 모델이 무관한 배경 데이터에 의해 주의가 분산되지 않고 현재 당면한 작업에 집중할 수 있도록 보장합니다.

서버를 능동적으로 토글하여 컨텍스트 예산을 확인하는 것은 품질 저하를 방지하는 데 매우 중요합니다. 만약 에이전트가 세션 중간에 기본적인 지침을 잊기 시작하거나, 명확한 이유 없이 논리가 떨어지기 시작한다면, 그 원인은 대개 컨텍스트 비대화 (context bloat)입니다. 불필요한 도구를 비활성화하여 "노이즈 (noise)"를 제거하면 에이전트의 추론 능력이 즉시 회복되어, 출력을 날카롭고 정확하게 유지할 수 있는 경우가 많습니다.

8. 단순 반복 작업은 무료/저렴한 모델로 보내세요

제 설정에서 OpenCode는 무료 모델로 실행되는데, 이것이 바로 핵심입니다. PR 리뷰 (Pull Request reviews), 기본적인 QA 수정, 문서화 작업과 같은 태스크들은 최첨단 추론 엔진 (frontier reasoning engine)을 필요로 하지 않습니다. 대신 인내심과 확실한 체크리스트가 필요합니다. 지루하고 반복적인 작업을 무료 티어 (free tiers)로 라우팅 (routing)하면, 실제로 "최첨단" 가격표를 달 가치가 있는 아키텍처 문제들을 위해 유료 크레딧을 보존할 수 있습니다.

저는 보통 무료 모델을 "쉬운 승리 (easy wins)"를 위해 남겨두지만, 초기 "전투 계획 (battle plan)"이 충분히 서술적이라면 복잡한 태스크를 처리하는 데 놀라울 정도로 유능합니다. 만약 플래닝 에이전트 (planning agent)가 로직을 정의하는 힘든 작업을 이미 수행했다면, 무료 모델은 큰 문제 없이 이를 실행할 수 있습니다. 로드맵이 명확하고 세분화되어 있기만 하다면, 단순히 타이핑을 수행하기 위해 프리미엄 두뇌에 비용을 지불할 필요는 없습니다.

9. 어떤 도구가 어려운 문제를 해결하는지 파악하세요

복잡한 결정 매트릭스 (decision matrix)를 과하게 설계하기보다는, 저는 명확하고 확립된 라우팅 계층 구조 (routing hierarchy)를 고수합니다: 1순위 Claude Code, 2순위 Antigravity, 3순위 Cursor입니다. 이러한 단순함은 "결정 마비 (decision paralysis)"를 방지하며, 도구를 선택하는 데 시간을 덜 쓰고 코딩하는 데 더 많은 시간을 쓰도록 보장합니다. Claude Code는 가장 견고하기 때문에 저의 기본값이며, 다른 도구들은 서로 다른 시나리오를 위한 특정 전술적 백업 역할을 합니다.

저의 계층 구조는 간단합니다: Claude Code는 모든 것에 대한 기본 도구입니다. Claude Code가 속도 제한 (rate-limited)에 걸리거나 특히 까다로운 문제에 대해 제2의 의견이 필요할 때 Antigravity가 개입합니다. Cursor는 IDE를 떠나지 않고 파일에 밀착하여 빠르게 에디터 내에서 작업하고 싶을 때를 위해 남겨둡니다. 이 계층 구조를 암기하고 있으면 워크플로우가 기술적이고 강제적인 느낌이 아니라 유동적이고 자연스럽게 느껴집니다.

10. 터미널을 최적화하세요, 이제 그것도 스택의 일부입니다

AI 에이전트(AI agents)는 터미널에서 실행되므로, 여러분의 에디터(editor)와 마찬가지로 동일한 수준의 관리와 설정이 필요합니다. 저는 텍스트가 겹쳐서 혼란스러운 상태가 되지 않으면서도, 병렬 에이전트(parallel agents)를 지원할 수 있는 깨끗하고 조직적인 터미널 환경을 유지하는 데 집중합니다. 잘 관리된 터미널은 수많은 탭의 바다 속에서 에이전트의 출력(output)을 놓치지 않게 해주며, 멀티 에이전트 오케스트레이션(multi-agent orchestration)을 통제할 수 있게 해줍니다.

복잡한 툴셋(toolsets)에 의존하는 대신, 저는 Git worktrees와 같은 기본적인 기능을 사용하여 병렬 에이전트들이 서로의 변경 사항을 짓밟지 않고 동일한 리포지토리(repo)에서 작업할 수 있도록 합니다. 터미널 설정을 단순하게 유지하고 세션 관리(session management)를 논리적으로 수행함으로써, 높은 가시성을 가지고 여러 에이전트를 동시에 추적할 수 있습니다. 이러한 조직적 명확성 덕분에 단 한 명의 개발자가 집중력을 잃지 않고도 4개의 에이전트 함대를 동시에 효과적으로 "지휘"할 수 있는 것입니다.

결론

도구는 계속 변할 것이고, 가격은 그보다 더 빠르게 변할 것입니다. 살아남는 설정은 여러분만의 컨벤션(conventions) 외에는 그 무엇도 핵심적인 하중을 받지 않는 설정입니다. 즉, 휴대 가능한 설정(portable configs), 좁은 범위의 에이전트(narrow agents), 그리고 여러분이 소유한 기술(skills)입니다. 이것들을 한 번 구축해 두면, 벤더(vendors)들이 누가 그것들을 실행할지를 두고 싸우게 두면 됩니다.

이 포스트에 담긴 몇 가지 기술들은 제 개인적인 워크플로우(workflow)를 넘어 성장했으며, 여러분도 사용할 수 있는 무언가로 발전시키고 있습니다. 곧 더 자세한 내용을 공유하겠습니다.