도구 탓이 아니다
Cursor 구독했다. Claude Code도 붙였다. GitHub Copilot Agent Mode도 켰다. 그런데 스프린트 속도는 3개월 전과 같다. 이 상황이 낯설지 않다면, 솔직하게 짚고 넘어가야 할 게 있다.
문제는 도구가 아니다. 도구에 넣는 입력이다.
LLM은 증폭기다—노이즈도 증폭한다
dev.to에 올라온 한 글이 이 문제를 정확하게 짚었다. "LLM은 증폭기다. 마법이 아니다." 깨끗한 신호를 넣으면 깨끗한 출력이 나오고, 노이즈를 넣으면 더 큰 노이즈가 나온다. 대부분의 팀은 지금 노이즈를 넣고 있다.
현장에서 반복되는 패턴은 이렇다. 컨텍스트 없이 채팅창을 연다. 스펙도 없고 플래닝도 없다. 모델에게 "이 기능 만들어줘"라고 던진다. 결과물이 나오면 붙여넣는다. 뭔가 깨진다. 2시간 디버깅한다. 에러를 다시 붙여넣는다. 수정된 코드가 다른 걸 깨뜨린다. 이걸 'AI 어시스티드 개발'이라고 부른다. 실제로는 혼돈을 10배 속도로 돌리는 것에 가깝다.
스펙 단계가 빠진 것이 원인이다
속도가 안 오르는 팀의 공통점은 하나다. AI가 강력해지는 전제 조건—스펙과 컨텍스트 준비—을 건너뛴다. AI 시대에 개발자는 사실상 PM, 아키텍트, QA, 개발자를 동시에 맡게 됐다. 그런데 소프트웨어 프로젝트 원칙을 모르는 상태에서 도구만 쥐면, 도구는 그 무질서를 자신 있게, 그리고 대규모로 되돌려줄 뿐이다.
실용적으로 쓸 수 있는 4단계 흐름이 있다.
1단계: 컨텍스트 — 코드를 한 줄도 쓰기 전에 모델에게 모든 걸 먹인다. 에픽, 유저 스토리, 기술 스택 결정, 건드리면 안 되는 영역. 신입 개발자를 온보딩할 때 첫날 바로 랩탑을 주지 않는 것처럼, LLM에도 똑같이 해야 한다. 컨텍스트 없이 시작하면 모델은 할루시네이션을 낸다—틀린 게 아니라 다른 문제를 푼 코드가 나온다.
2단계: 플래닝 — 컨텍스트를 먹인 모델에게 유저 스토리를 작은 마일스톤으로 쪼개게 한다. 큰 덩어리가 아니라 명확한 체크포인트가 있는 순서로. 이 단계 하나가 AI로 빨라지는 팀과 그렇지 않은 팀을 가른다.
3단계: 승인 게이트와 함께 빌드 — 모델이 다음 단계로 넘어가기 전 반드시 사람이 검토한다. 느린 것처럼 보이지만 반대다. 이 단계를 건너뛴 팀이 이해할 수도 없고 디버깅도 안 되는 AI 생성 코드 3,000줄 앞에서 3일을 쓰는 걸 봤다.
4단계: 러닝 — 버그를 고치면 그 패턴을 모델의 메모리와 스펙에 반영한다. 다음 세션에도 같은 함정에 빠지지 않도록. 모델을 계산기처럼 쓰다 내려놓는 팀은 도구가 자신들을 학습한 적이 없어서 속도가 안 오르는 것이다.
컨텍스트 관리의 실제 문제: CLAUDE.md만으론 부족하다
4단계 중 '러닝'을 실제로 구현하려고 하면 바로 벽에 부딪힌다. 세션이 새로 시작될 때마다 같은 프로젝트 컨텍스트를 다시 설명해야 한다는 것이다.
dev.to에 올라온 Memento MCP 사례가 이 문제를 잘 보여준다. Claude Code를 헤비하게 쓰는 개발자가 계속 같은 것에 치였다. "이 모듈은 레거시처럼 보이지만 크리티컬한 플로우를 지원한다", "이 쿼리는 이전에 성능 이슈를 일으켰다", "이 아키텍처 결정은 이상해 보이지만 이유가 있다." 이런 것들을 세션마다 다시 설명해야 했다.
CLAUDE.md는 안정적인 온보딩 지침에는 적합하다—프로젝트 실행 방법, 테스트 방법, 코딩 컨벤션. 문제는 모든 함정, 디버깅 노트, 의사결정 기록까지 다 밀어넣으면 두 가지가 망가진다. 첫째, 매 새 세션마다 관련 없는 내용까지 토큰 비용을 낸다. 둘째, 컨텍스트가 많을수록 정작 중요한 정보가 묻힌다. 더 많은 컨텍스트가 항상 더 나은 컨텍스트는 아니다.
그래서 나온 구분이 명확하다. CLAUDE.md = 안정적인 온보딩 지침. 워킹 메모리 = 프로젝트 작업 중 발생한 지식. 워킹 메모리는 매 프롬프트에 덤프하는 게 아니라, 현재 태스크와 관련된 것만 검색해서 주입해야 한다.
Copilot Agent Mode가 끼어든 맥락
컨텍스트와 스펙 준비가 워크플로우의 전제라면, 그 위에 올라타는 에이전트 도구는 어떻게 골라야 할까. GitHub Copilot이 2026년 4월 에이전트 모드를 IDE 인라인까지 확장한 것은 이 맥락에서 봐야 한다.
Copilot Agent Mode, Claude Code, Cursor는 각각 다른 컨텍스트를 자동으로 본다. IDE 내장 에이전트는 열려 있는 파일, 커서 위치, 언어 서버의 심볼·진단 정보, 저장되지 않은 버퍼 상태를 공짜로 본다. CLI 에이전트는 셸 커맨드 출력, 환경 변수, 프로세스 종료 코드를 본다. 두 리스트는 유용하지만 같지 않다.
요점은 간단하다. 에이전트 선택이 컨텍스트 접근 방식을 결정한다. 그리고 어떤 에이전트를 쓰든, 에이전트가 볼 수 있는 컨텍스트의 품질이 결과물의 품질을 결정한다. 좋은 도구를 골랐다고 끝나는 게 아니다.
팀에게 실질적으로 의미하는 것
AI 도구를 도입했는데 속도가 그대로라면, 먼저 확인할 것은 워크플로우 설계의 '전 단계'다. 도구를 쓰기 전에 무엇을 준비했는가.
실행 가능한 체크리스트는 세 가지다.
첫째, 컨텍스트 문서를 구조화하라. CLAUDE.md나 .cursorrules에 모든 걸 밀어넣지 말고, 안정적인 지침과 세션 중 발생하는 지식을 분리한다. Memento MCP 같은 접근이든, 단순히 context/ 디렉토리에 마크다운 파일을 정리하는 방식이든, 구조 자체가 중요하다.
둘째, 승인 게이트 없이 빌드 단계를 통과시키지 마라. 마일스톤마다 사람이 검토하는 체계가 없으면, AI가 만든 코드는 이해할 수 없는 부채로 쌓인다. 속도처럼 보이지만 실제로는 가속된 기술 부채 생산이다.
셋째, 러닝 루프를 설계하라. 버그를 고쳤으면 그 패턴을 문서화해서 다음 세션 컨텍스트에 반영한다. 모델이 팀의 코드베이스와 패턴을 학습하는 구조를 만들지 않으면, 매 세션은 항상 첫날이다.
결론: 도구보다 먼저 설계해야 할 것
LLM은 증폭기다. 이 한 문장이 'AI 도입 → 속도 향상'이라는 등식이 자동으로 성립하지 않는 이유를 설명한다. 도구가 아무리 강력해도, 넣는 신호가 노이즈면 출력은 더 큰 노이즈다.
팀이 AI 도구를 도입하기 전에 설계해야 할 것은 도구 선택이 아니다. 컨텍스트를 어떻게 준비할 것인가, 플래닝을 어떻게 구조화할 것인가, 승인 게이트를 어디에 둘 것인가, 그리고 학습한 내용을 어떻게 다음 세션으로 이어갈 것인가—이 네 가지 워크플로우 설계가 먼저다.
어떤 모델이 다음 달에 유행하든, 어떤 도구가 다음 주에 출시되든, 이 원칙은 바뀌지 않는다.