핵심 이슈: 도구는 준비됐는데, 워크플로우가 없다
Cursor가 자체 개발 모델 Composer 2를 출시했다. SWE-bench Multilingual 73.7점, 공개 모델 최상위권. 가격은 동급 고속 모델 대비 공격적으로 낮다. 수직 통합 전략의 완성형이다. 외부 API에 의존하던 레이어에서 벗어나 모델까지 직접 쥔 Cursor는 이제 IDE와 모델 사이의 마찰을 스스로 줄일 수 있는 위치에 섰다.
그런데 솔직히 말하자. 모델이 좋아졌다고 팀의 생산성이 자동으로 올라가진 않는다. 오히려 지금이 더 위험한 시점이다. 도구가 강력해질수록, 구조 없이 쓸 때의 부작용도 커진다.
맥락 해석: Vibe Coding이 왜 지금 한계에 부딪히나
dev.to에 올라온 글 하나가 업계의 불편한 진실을 정면으로 건드렸다. 저자는 1년 전 AI로 20시간 만에 앱을 만들었다고 썼다. 85% 시간 단축. 그런데 1년이 지난 지금 그는 그 방식을 버렸다.
이유는 단순하다. "우리는 아무도 제대로 리뷰하지 않은 코드를 엄청난 속도로 프로덕션에 올리고 있다." 방향 없이 AI에게 맡기면 버그 하나 고치러 들어갔다가 모듈 절반이 리팩터링된다. '개선해줘'라는 말 한마디가 15개 파일 변경으로 돌아온다. 그린필드 단독 프로젝트에서는 통했지만, 팀 단위로, 레거시가 쌓인 환경에서, 컴플라이언스가 붙는 엔터프라이즈에서는 통하지 않는다.
이건 AI 모델의 문제가 아니다. 컨텍스트 문제다. AI는 팀이 이미 내린 결정, 코드베이스의 패턴, 요청의 실제 범위를 모른다. 그 공백을 채우지 않으면 가장 성능 좋은 모델도 노이즈 생성기가 된다.
시사점 1: Task-Driven Development — 실행 전에 정의하라
대안으로 제시된 구조가 Task-Driven Development(TDD)다. 핵심은 단순하다. 채팅창 열기 전에 작업을 먼저 정의한다.
- Spec → Tasks → Subtasks → Plan(검토·승인) → Execution → Review
여기서 가장 많이 건너뛰는 단계가 Plan이다. AI에게 코드를 짜기 전에 먼저 구현 계획을 쓰게 하고, 사람이 승인한 뒤에 실행에 들어간다. 이 한 단계가 '그냥 해봐'와 '어떻게 할 건지 말하고 나서 해'의 차이를 만든다. 리뷰 체크포인트가 생기고, 문제가 코드로 번지기 전에 잡힌다.
각 태스크에는 Definition of Done(DoD)이 붙는다. 테스트 통과, 회귀 없음, 프로젝트 패턴 준수, 번역 완료. AI는 이 기준을 충족해야만 태스크를 완료 처리할 수 있다. 'AI가 생성한 코드'에서 '프로덕션 기준을 통과한 코드'로 넘어가는 브릿지다.
팀 적용 관점에서 핵심은 이것이다. 개발자는 다시 아키텍트와 리뷰어가 된다. 스펙터가 아니라. AI가 실행하고, 사람이 방향을 잡는다. 도구가 강해질수록 이 역할 분리가 더 중요해진다.
시사점 2: 컨텍스트 관리 — AI에게 '기억'을 줘라
도구가 강력해도 컨텍스트 창이 압축되는 순간 모든 게 리셋된다. Claude Code를 10개 프로젝트 동시 운영하며 개발한 패턴이 dev.to에 공유됐다. 핵심 구조는 파일 두 개로 정리된다.
- CLAUDE.md: '이 프로젝트를 어떻게 작업하는가' — 영구적 매뉴얼
- SESSION.md: '지금 어디까지 왔는가' — 실시간 작업 로그
CLAUDE.md에 "세션 시작 시 SESSION.md를 읽어라"는 지시를 박아두면, autocompact가 발동돼도 Claude는 SESSION.md를 통해 맥락을 복구한다. 컨텍스트 전환 비용이 SESSION.md 읽는 몇 초로 줄어든다.
멀티 프로젝트 환경에서는 CONVENTIONS.md를 중앙화하고 심볼릭 링크로 배포한다. 규칙이 하나의 파일에 살고, 모든 프로젝트에 동기화된다. 안전 규칙도 여기 들어간다. rm -rf 확인, force push 금지, 시크릿 커밋 방지. 실제로 논문 교정 요청에서 Claude가 물리적으로 틀린 수식을 '수정'한 사고를 겪은 뒤 LaTeX 수식 수정 금지 규칙이 추가됐다는 사례는, 이 안전 장치가 이론이 아니라 현장 필요에서 나왔음을 보여준다.
전망: 세 흐름이 만드는 하나의 방향
Composer 2의 성능 도약, Task-Driven Development의 구조화, Claude Code 컨텍스트 패턴. 세 흐름은 각기 다른 레이어에서 같은 방향을 가리킨다.
모델은 충분히 강해졌다. 이제 병목은 워크플로우다.
Vibe Coding이 나쁜 게 아니다. 그린필드, 단독, 단기 프로젝트에서는 여전히 유효하다. 문제는 그 방식을 팀 환경, 장기 프로젝트, 엔터프라이즈 맥락에 그대로 가져오는 것이다. 도구가 강해질수록 구조 없는 사용의 부작용이 함께 커진다.
내일 팀에 당장 적용할 수 있는 출발점은 세 가지다. ① 태스크를 실행 전에 정의하고 Plan 단계를 건너뛰지 않는다. ② CLAUDE.md와 SESSION.md를 분리해 컨텍스트 복구를 자동화한다. ③ DoD를 명시적으로 붙여 AI의 완료 기준을 사람의 기준과 맞춘다.
모델 선택보다 이 세 가지 습관이 팀의 AI 생산성을 실제로 바꾼다. Composer 2가 아무리 좋아도, 워크플로우가 없으면 더 빠르게 엉키는 코드를 더 빠르게 만들 뿐이다.