AI 도구를 매일 쓰는 개발자라면 한 번쯤 이 경험을 해봤을 것이다. 어제 Claude에게 코드베이스 구조를 설명했는데, 오늘 새 채팅을 열자마자 또 처음부터 설명해야 한다. 스타일 가이드, 레거시 결정 사항, 팀 컨벤션까지. 이걸 dev.to의 AGINE Academy 아티클은 '재브리핑 세금(re-briefing tax)'이라고 표현한다. AI 어시스턴트가 동료가 아니라 매번 새로 만나는 낯선 사람처럼 느껴지는 이유가 바로 이것이다.
문제의 본질은 프롬프트 품질이 아니다. 구조의 부재다. Claude Projects는 이 문제를 정면으로 겨냥한 기능이다. 커스텀 인스트럭션, 업로드된 파일들, 그리고 컨텍스트 경계—이 세 가지를 하나의 워크스페이스에 묶어두면, 프로젝트 안에서 시작하는 모든 대화가 이미 팀의 맥락을 알고 시작한다. 채팅이 길어져서 새로 열어도, 레퍼런스는 그대로 '선반 위에 꽂혀' 있다.
하지만 Projects를 만든다고 자동으로 잘 동작하지는 않는다. 가장 흔한 실수는 인스트럭션을 소망처럼 적는 것이다. "당신은 우리 스타트업을 위한 도움이 되는 어시스턴트입니다" 같은 문장은 Claude가 이미 가정하는 것과 다를 게 없다. 제대로 된 인스트럭션은 신입 개발자 온보딩 문서처럼 써야 한다. 역할, 제약, 출력 형식을 명시하고—특히 제약이 핵심이다. '패키지 추가 전에 먼저 물어볼 것' 한 줄이 '영리하고 꼼꼼하게 해줘' 열 줄보다 훨씬 더 많은 나쁜 출력을 막는다.
파일 관리도 설계가 필요하다. 드라이브를 통째로 업로드하고 싶은 충동을 참아야 한다. 오래된 PRD와 현재 스펙이 나란히 놓이면 Claude는 둘 다 사실인 것처럼 인용한다. 현재 아키텍처 개요, API 스키마, 스타일 가이드, 도메인 용어 사전, 그리고 '좋은 출력'의 예시 몇 개—이 정도가 신호 대 잡음비를 유지하는 최적점이다. 여기에 _START_HERE.md 같은 인덱스 파일을 하나 추가하면, Claude가 각 파일의 신뢰 수준을 판단하는 기준이 생긴다. '이 파일은 히스토리용, 현재 기준으로 쓰지 말 것'이라는 명시적 레이블이 모델의 혼동을 줄인다.
이 관점을 create-next-mui 프로젝트의 DX 철학과 연결하면 흥미로운 패턴이 보인다. Vikash Kumar가 CLI를 개선하면서 발견한 것은 '큰 기능 추가'보다 '작은 마찰 제거'가 실제 사용 경험을 바꾼다는 사실이었다. 의존성 자동 정렬, 한 번의 명령으로 설치까지 완료—각각은 사소해 보이지만, 매일 쓰는 도구에서 쌓이는 마찰을 제거한다. Claude Projects의 _START_HERE.md도 같은 논리다. 파일 하나가 모델의 혼동을 줄이고, 개발자의 컨텍스트 관리 부담을 줄인다. 좋은 개발 도구는 기능을 추가하는 게 아니라 매번 반복되는 마찰을 제거하는 방향으로 성숙한다.
한 가지 중요한 한계도 직시해야 한다. Projects는 라이브 지식 베이스가 아니다. 마지막으로 업로드한 시점의 스냅샷이다. 스키마가 바뀌었는데 파일이 그대로라면, Claude는 틀린 정보를 자신 있게 말한다. 오래된 컨텍스트는 컨텍스트가 없는 것보다 위험할 수 있다—권위 있어 보이기 때문이다. 따라서 Projects를 운용하는 팀은 '결정이 바뀌면 해당 파일을 업데이트하는' 습관을 워크플로우에 내재화해야 한다. README를 관리하는 것처럼.
결국 Claude Projects는 더 나은 프롬프트 기법이 아니라, AI와 일하는 방식 자체를 구조화하는 설계 문제다. 하나의 거대한 메가 프로젝트 대신 실제 도메인별로—코드베이스 하나, 클라이언트 하나—분리된 프로젝트를 운용하고, 맵 파일·아키텍처 문서·스타일 가이드 세 파일로 시작해서 실제 대화에서 틀리는 것을 발견할 때마다 프롬프트가 아니라 파일을 고치는 패턴. 이게 AI를 '채팅 장난감'이 아닌 팀의 실질적인 도구로 끌어올리는 방법이다. 좋은 DX 도구가 매번 반복되는 마찰을 제거하며 성숙하듯, AI 워크플로우도 똑같은 방향으로 설계되어야 한다.