도구는 분명 빨라졌다. 와이어프레임은 몇 분이면 나오고, 코드는 AI가 대신 짜준다. 그런데 막상 실무를 하다 보면 기대만큼 극적으로 빨라진 느낌이 들지 않는다. 개발자는 같은 질문을 Cursor에 반복하고, Claude Code는 매번 새로운 신입처럼 행동하고, Figma에서 AI가 뽑아준 화면은 프롬프트를 조금만 바꿔도 완전히 다른 결과물이 나온다.
이 현상의 공통 원인은 하나다. AI 도구를 '사용'하고 있지만, '설계'하지 않고 있다.
반복의 비용: AI는 기억하지 못한다, 설계하지 않으면
dev.to에서 Cursor를 활용한 레거시 코드베이스 온보딩 워크플로우를 소개한 글은 출발점이 흥미롭다. 저자가 처음 저지른 실수는 대부분의 개발자가 저지르는 것과 같다. Cursor에게 "전체 프로젝트를 분석해줘"라고 던진 것. 결과는 예상할 수 있다. 토큰은 폭발적으로 소비되고, 답변은 두루뭉술하고, 컨텍스트는 금세 사라진다. 다음 질문에서 처음부터 다시 시작해야 한다.
해결책은 기술적이지 않다. 오히려 조직적이다. 저자는 Cursor를 "코딩 어시스턴트"가 아니라 "프로젝트 지식 어시스턴트"로 재정의하고, docs/onboarding/project-memory.md라는 중앙 지식 베이스를 만들었다. 레포지토리 목적, 아키텍처 노트, 서비스 간 관계, 비즈니스 도메인, 코딩 컨벤션이 모두 이 파일에 축적된다. 그리고 Cursor 룰에 명시적으로 지시한다. "코드를 분석하기 전에 반드시 project-memory.md를 먼저 읽어라."
/ticket, /implement, /review, /update-docs 같은 재사용 가능한 스킬까지 구성하고 나면, Cursor는 더 이상 매번 새로운 신입이 아니다. 프로젝트를 알고 있는 엔지니어링 파트너가 된다. 핵심은 단순하다. 같은 것을 두 번 학습하지 않는 구조를 만드는 것.
기억의 착각: 문제는 AI가 아니라 온보딩 문서의 부재였다
Claude Code를 매일 쓰면서도 매번 같은 맥락을 반복 설명해야 했던 한 개발자의 경험은 더 직접적인 교훈을 담고 있다. 그는 처음에 Claude Code의 "기억력" 문제라고 진단했다. 하지만 조사를 거듭하면서 판단이 바뀌었다. 새 대화는 원래부터 이전 컨텍스트가 없다. AI가 잊은 게 아니라, 처음부터 알려주지 않은 것이다.
비유가 정확하다. 새 팀원이 입사했을 때 우리는 바로 티켓을 던지지 않는다. 직원 온보딩 핸드북을 먼저 건넨다. 프로젝트가 뭔지, 기술 스택이 뭔지, 건드리면 안 되는 디렉토리가 어딘지, 어떤 규범을 따르는지. Claude Code에게 그 핸드북 역할을 하는 것이 CLAUDE.md다.
이 파일은 단순한 설명 문서가 아니다. Claude Code가 프로젝트에 진입할 때마다 먼저 읽는 "컨텍스트 레이어"다. 저자가 CLAUDE.md에 프로젝트 배경, 디렉토리 책임, 개발 규칙, 수정하면 안 되는 핵심 모듈을 정리하고 나서 달라진 것은 코드 품질이 아니었다. 커뮤니케이션 비용이었다. 이전에 매번 설명해야 했던 것들이 처음부터 공유된 전제가 되었다. 새 동료가 프로젝트 문서를 미리 읽고 출근한 것과 같은 효과다.
디자이너의 딜레마: 도구는 빨라졌는데 실무는 왜 그대로인가
개발자만의 이야기가 아니다. 브런치에 게재된 현업 디자이너의 AI 워크플로우 분석은 같은 문제를 디자인 관점에서 짚는다. 와이어프레임은 몇 분 만에 나오고, 이미지는 프롬프트 몇 줄로 생성된다. 그런데 체감 속도는 기대만큼 폭발적이지 않다.
이유가 있다. AI는 초안을 빠르게 만들지만, 실제 서비스 수준으로 다듬기 위한 검수, 정합성 확인, 브랜드 일관성 체크는 여전히 사람의 몫이다. 더 근본적인 문제는 프롬프트의 질이다. "메모앱 홈화면 만들어줘"와 iOS 스타일, 한국형 생산성 앱, 상단 헤더 구성 요소, 카드 레이아웃 방식까지 구체적으로 기술한 프롬프트의 결과물 차이는 극단적이다. Figma First Draft가 곧 Figma Agent에 자리를 내줄 것으로 예상되는 이유도 여기에 있다. 지금의 Draft는 정해진 규칙에 맞는 결과만 보여주는 1회성 생성 도구지만, Agent는 대화형으로 결과물을 함께 다듬어가는 구조이기 때문이다.
문제 정의 단계에서도 AI 활용의 질이 갈린다. Gstack이나 Superpowers 같은 스킬 기반 워크플로우가 주목받는 이유는, 단순히 아이디어를 확장하는 게 아니라 "정말 해결해야 하는 문제인가?"를 계속 질문하는 구조이기 때문이다. ChatGPT와 Figma를 연동해 플로우차트 초안을 만드는 것보다, 그 이전에 무엇을 만들지 말아야 하는지를 먼저 정의하는 것이 더 중요한 단계가 되었다.
컨텍스트 설계가 생산성의 실제 레버다
세 사례가 가리키는 방향은 하나로 수렴한다. AI 도구의 생산성은 도구 자체의 성능보다 그 도구에게 무엇을 알려줄 것인가를 설계하는 능력에 달려 있다.
project-memory.md는 Cursor가 레거시 코드베이스를 반복 학습하는 비용을 없앤다. CLAUDE.md는 Claude Code가 매번 새 신입처럼 행동하는 문제를 해결한다. 구체적으로 설계된 프롬프트와 Figma Agent 연계는 AI 생성 디자인의 일관성 문제를 구조적으로 접근하게 만든다. 모두 같은 원리다. AI에게 "일을 시키기 전에 어떤 맥락 위에서 일할지를 먼저 설계한다."
세탁기가 등장했을 때 가사 노동 시간이 바로 줄어든 게 아니었다는 비유가 정확하다. 청결 기준이 높아지고 새로운 노동 기준이 생겼다. AI도 마찬가지다. 초안 제작 속도는 빨라졌지만, 일관성 관리, 세부 수정, 협업 프로세스 반영이라는 새로운 과제가 그 자리를 채운다. 도구가 빨라질수록 설계의 질이 결과의 차이를 만드는 비중이 커진다.
다음 질문: 컨텍스트를 쌓는 구조를 팀 단위로 어떻게 설계할 것인가
지금까지의 논의가 개인 워크플로우 수준이었다면, 진짜 다음 질문은 팀 레벨이다. project-memory.md가 특정 개발자의 로컬에만 존재한다면, 팀 전체의 AI 생산성은 여전히 개인 역량에 종속된다. CLAUDE.md가 팀 공용 저장소에 버전 관리되고, 디자인 프롬프트 라이브러리가 디자인 시스템처럼 관리될 때, 비로소 AI 도구의 생산성은 팀 수준으로 올라간다.
AI 도구를 잘 쓰는 팀과 그렇지 않은 팀의 차이는 점점 더 컨텍스트 설계 능력으로 드러날 것이다. 더 강한 모델이 나올수록, 그 모델에게 무엇을 알려줄 것인가를 먼저 설계하는 팀이 그렇지 않은 팀을 압도한다. 도구를 '사용'하는 것과 도구를 '길들이는' 것은 다른 기술이다.