모델 전쟁이 끝나고 플랫폼 전쟁이 시작됐다
16일 사이에 프런티어 AI 모델 다섯 개가 쏟아졌다. Claude, GPT-5.6, Grok 4.5, Muse Spark, Kimi K3. dev.to의 분석에 따르면 이미 6개 이상의 랩이 Intelligence Index 50점을 넘겼고, 모델 간 능력 차이는 '세대 차'가 아니라 '퍼센트 차'로 좁혀졌다. 이 수렴의 의미는 단순하다. 이제 '어떤 모델이 가장 똑똑한가'라는 질문은 점점 의미를 잃는다. 대신 '어떤 모델이 내 워크플로우에 자연스럽게 녹아드는가'가 실질적인 선택 기준이 된다.
이 맥락이 중요한 이유는, 팀에서 AI 코딩 도구를 쓸 때 겪는 가장 큰 좌절도 정확히 같은 지점에서 발생하기 때문이다. 모델이 약해서가 아니라, 도구를 워크플로우에 제대로 심지 못해서. Cursor가 망가진 코드를 짤 때, 우리는 보통 모델 탓을 한다. 하지만 진짜 원인은 다른 곳에 있다.
Cursor가 버그를 만드는 진짜 이유
Cursor를 써본 팀이라면 이 패턴을 안다. 파일이 엉뚱한 위치에 생성된다. 멀쩡히 돌아가던 코드가 덮어써진다. 존재하지 않는 임포트를 환각한다. 에러 하나를 고치면 세 개가 새로 생긴다. 이른바 "I fixed it → New error" 루프. dev.to의 실무 분석은 이 현상의 원인을 명확하게 짚는다. 문제는 Cursor의 능력이 아니라, 아키텍처 정보의 부재다.
LLM은 컨텍스트 안에서 추론한다. 기술 스택, 폴더 구조, 데이터베이스 설계, 코딩 컨벤션, 구현 순서—이 정보가 없으면 AI는 추측으로 채운다. 그 추측이 쌓이면 중복 컴포넌트, 일관성 없는 API, 충돌하는 상태 관리가 된다. 주니어 개발자에게 "SaaS 앱 전체를 만들어"라고 시키면 어떻게 되는지 생각해보면 된다. 아키텍처도, 요구사항도, 폴더 구조도 없이. Cursor도 정확히 같은 상황에 놓인다.
컨텍스트 설계: 3단계 워크플로우
해법은 Cursor를 덜 쓰는 게 아니라, Cursor에게 일을 시키는 방식을 바꾸는 것이다. 실무에서 검증된 3단계 구조는 다음과 같다.
1단계: 기술 스택과 DB 스키마를 먼저 문서화한다. Frontend(Next.js, TypeScript), Backend(Node.js, Express), DB(PostgreSQL + Prisma), Auth(Clerk), Hosting(Vercel)처럼 스택을 명시하고, Users·Projects·Tasks 테이블의 필드까지 정의한다. AI가 테이블을 임의로 발명하기 전에, 어떤 데이터가 존재하는지를 먼저 알려주는 것이다.
2단계: 디렉토리 구조를 설계한다.
src/components, src/services, src/database, src/utils처럼 폴더 레이아웃을 미리 정의하고, 각 폴더의 역할 규칙을 명시한다. "공유 컴포넌트는 components/, API 로직은 services/"처럼. 이 단계를 건너뛰면 AI는 파일을 루트 디렉토리에 마구 쏟아낸다.
3단계: 단계별 프롬프트 시퀀스로 개발한다. '앱 전체를 만들어'가 아니라, Phase 1(UI만), Phase 2(인증·DB·API), Phase 3(비즈니스 로직)로 쪼개서 요청한다. 각 단계는 이전 단계의 결과물을 안정적인 기반으로 삼는다. LLM의 작업 기억(working memory)은 유한하다. 동시에 20개의 문제를 풀게 하면 컨텍스트를 잃는다. 하나씩 명확히 정의된 문제를 풀게 하면 결과가 달라진다.
Claude Code Stop Hook: 컨텍스트를 데이터로 만드는 법
컨텍스트 설계의 다음 단계는 팀이 AI를 어떻게 쓰는지를 측정하는 것이다. 측정할 수 없으면 개선할 수 없다. Claude Code의 Stop Hook은 이 문제를 해결하는 흥미로운 접근이다. dev.to의 사례에 따르면, 세션 종료 시 발동하는 Stop Hook의 transcript_path 페이로드를 Python으로 파싱해 모든 에이전트 호출을 JSONL로 누적한다.
결과는 구체적이다. 7일간 general-purpose 에이전트가 58회, Explore가 24회 호출됐고, 정의된 에이전트 47개는 한 번도 호출되지 않았다. 이 데이터가 없었다면? 47개의 '좀비 에이전트'는 계속 컨텍스트를 오염시키고 있었을 것이다. 사용되지 않는 에이전트 정의는 단순히 낭비가 아니라, 컨텍스트 인젝션을 늘려 AI 출력 품질을 떨어뜨리는 적극적인 해악이다.
구현의 핵심은 두 가지다. 첫째, Stop Hook의 stdin은 한 번만 읽을 수 있으므로 tmpfile에 저장한 뒤 각 Hook에 리다이렉트해야 한다. 둘째, session_id × tool_use_id 조합으로 중복을 제거해야 한다. tool_use_id만으로 중복 처리하면 크로스 세션 충돌로 레코드가 유실된다. 이런 엣지 케이스를 직접 부딪혀 해결한 경험이 쌓여야 팀의 AI 운영 인프라가 실제로 작동한다.
팀 테크 리드로서의 판단
두 가지 흐름을 묶으면 하나의 원칙이 보인다. AI 코딩 도구의 품질은 도구 세팅이 아니라 컨텍스트 설계가 결정한다. Cursor에게 아키텍처를 주는 것, Claude Code의 에이전트 호출을 로깅해 좀비를 제거하는 것—둘 다 결국 AI에게 '좋은 컨텍스트'를 제공하는 작업이다.
팀 리빌딩 관점에서 이것이 중요한 이유는, 이 역량이 개인 스킬이 아니라 팀 인프라로 자리잡아야 하기 때문이다. 아키텍처 문서 템플릿, 단계별 프롬프트 시퀀스, 에이전트 사용량 대시보드—이것들은 팀 표준으로 코드베이스에 박혀 있어야 한다. 그렇지 않으면 AI를 잘 쓰는 사람 한 명의 노하우로 끝난다.
전망: 컨텍스트 엔지니어링이 새 역량이 된다
모델이 수렴하고 플랫폼 전쟁으로 넘어가는 지금, 팀 경쟁력의 변수는 어떤 모델을 구독하느냐가 아니다. 얼마나 잘 구조화된 컨텍스트를 AI에게 제공할 수 있느냐, 그리고 그 컨텍스트 설계를 팀 전체의 반복 가능한 프로세스로 만들 수 있느냐다. '프롬프트 잘 쓰기'가 아니라 '시스템 설계 수준의 컨텍스트 아키텍처'—이것이 AI-First 팀의 다음 핵심 역량이다. Cursor가 망가진 코드를 짠다면, 먼저 우리가 Cursor에게 무엇을 줬는지를 돌아봐야 한다.