컨텍스트 윈도우가 200K, 심지어 1M 토큰까지 커졌다. 그런데 팀 생산성은 그만큼 올라갔는가? Claude Code 사용 경험을 정리한 한 분석(dev.to)은 이 질문에 냉정하게 답한다. "더 큰 창고가 생겼을 뿐, 무엇을 어디에 넣어야 하는지는 여전히 사람의 몫이다." 벤치마크 숫자는 비교하기 쉽다. 하지만 '우리 팀이 컨텍스트를 얼마나 잘 설계하고 있는가'에는 지표가 없다. 그래서 아무도 들여다보지 않는다.
컨텍스트는 품질이지 용량이 아니다
'Dump Truck' 패턴은 익숙하다. 레포 전체 파일, 이슈 47개, 회사 핸드북을 통째로 넣고 AI에게 던진다. 결과는 예상 가능하다—AI가 노이즈 속에서 패턴을 찾느라 정작 필요한 추론에 쓸 에너지가 줄어든다. 'Lost in the Middle' 문제는 연구로도 반복 확인된다. 긴 컨텍스트에서 AI는 처음과 끝에 집중하고, 중간은 흐릿해진다. 창고가 클수록 바늘 찾기는 오히려 어려워진다.
진짜 문제는 그다음이다. 'Groundhog Day' 패턴—매 세션마다 AI가 같은 것을 다시 배운다. pnpm 워크스페이스 구조, auth 패키지 위치, 레거시 폴더 금지 규칙. 팀원이 매일 아침 프로젝트 구조를 다시 설명해달라고 한다면 진지하게 대화를 나눠야 할 상황이다. 그런데 AI에게는 그걸 당연하게 받아들이고 있다.
'지니어스 사일로'가 팀 격차를 만든다
같은 Claude 모델인데 결과물이 극명하게 갈린다. 시니어 개발자가 쥔 AI는 '천재'처럼 움직인다. 코드베이스의 역사, 지뢰 위치, 문서화되지 않은 관례—이 암묵적 컨텍스트가 프롬프트 속에 자연스럽게 녹아든다. 주니어 개발자의 AI는 그 모든 것을 처음부터 다시 발견한다. 토큰을 태우고, 시간을 태우고, 결국 빈손으로 돌아온다. AI가 팀 도구가 아니라 개인 비서에 머물고 있다는 증거다. 팀 리드는 이 격차를 볼 수 없다. 보이지 않으니 설계도 못 한다.
해법의 방향은 분명하다. '개인의 도메인 지식을 팀의 프롬프트 자산으로 전환'하는 것이다. 시니어가 "이 컴포넌트는 퍼포먼스 크리티컬, O(n²) 안 됨"이라고 AI에게 말할 때, 그 판단에는 수개월의 맥락이 압축되어 있다. 이걸 개인 채팅 창 안에 묻어두면 팀의 AI는 영원히 Groundhog Day를 반복한다.
검증은 도구 문제이자 워크플로우 문제다
컨텍스트 설계가 AI에게 '무엇을 줄지' 결정하는 일이라면, 검증은 AI가 낸 결과물을 '사람이 어떻게 확인할지'의 문제다. dev.to에 게재된 또 다른 분석은 이 문제를 정면으로 건드린다. 'vibe coding'의 공공연한 비밀—결과물을 의뢰한 사람이 그 코드를 읽을 수 없다는 것이다. 프롬프트를 넣고, 모델이 TypeScript 탑을 쌓고, 사람은 '작동하니까 맞겠지'로 넘긴다. 검증 단계가 조용히 증발한다.
이 분석이 제안하는 방향은 흥미롭다. AI가 코드를 생성할 때 문서화 블록을 함께 작성하게 하고, 코드와 문서에 각각 SHA 해시를 붙여 둘 중 하나가 변경되면 즉시 드리프트를 감지하는 구조다. 에디터는 코드와 문서를 나란히 보여주는 리뷰 모드를 제공한다. 핵심은 '이해(comprehension)'를 '비교(comparison)'로 바꾸는 것이다. 전문가가 아니어도 "코드가 문서가 말하는 대로 동작하는가"라는 질문은 답할 수 있다. 인간의 역할이 저자(author)에서 검토자(reviewer)로 이동했다면, 도구도 그에 맞게 바뀌어야 한다.
에이전트 시대의 디바이스 선택이 말해주는 것
세 번째 흐름은 다소 의외의 각도에서 온다—iPad를 진지한 개발 도구로 쓰는 시나리오다. 에이전트 프로그래밍 시대의 개발자 워크플로우를 다룬 분석(dev.to)은 흥미로운 관찰을 담고 있다. AI 에이전트가 코드 작성 자체를 상당 부분 담당하면서, 개발자에게 필요한 컴퓨팅 자원의 성격이 바뀌었다는 것이다. 이전에는 빠른 CPU와 편안한 키보드가 핵심이었다. 지금은 다르다—변경 사항을 리뷰하기 좋은 디스플레이, 여러 컨텍스트(코드·터미널·문서·에이전트 채팅)를 동시에 볼 수 있는 멀티태스킹 환경, 그리고 diff를 빠르게 훑을 수 있는 인터페이스가 더 중요해졌다.
이게 단순한 iPad 홍보가 아닌 이유는, 워크플로우의 무게중심이 '입력'에서 '네비게이션과 검토'로 이동했다는 사실을 장비 선택이 증명하기 때문이다. 에이전트에게 지시하고, 진행 상황을 모니터링하고, diff를 확인하고, 방향을 수정하고, 커밋을 만든다—이 흐름은 타이핑 집약적 작업이 아니다.
팀 리드가 설계해야 할 세 가지 실무 역량
세 분석을 묶으면 하나의 결론으로 수렴한다. AI-First 팀에서 개발자의 역할은 세 축으로 재편된다.
첫째, 컨텍스트 설계자. 무엇을 넣고 무엇을 버릴지 결정하는 큐레이션 능력. 세션이 끝날 때 "오늘 AI가 발견한 것 중 내일 팀 전체의 AI가 알아야 할 것은 무엇인가"를 묻는 습관. 개인의 도메인 지식을 팀 공유 프롬프트 자산으로 변환하는 프로세스.
둘째, 검증 설계자. AI 생성 코드를 '작동하면 맞다'가 아니라 '의도한 대로 동작하는가'로 검토하는 구조 설계. 시니어의 암묵적 필터링 본능—"작년에 비슷한 PR이 테스트를 깼었는데"—을 팀 전체의 루틴으로 만드는 것. 이 필터링 본능은 여전히 개인 지식 안에 갇혀 있다.
셋째, 네비게이터. AI 에이전트가 실행하는 동안 방향을 잡고, 중간 결과를 판단하고, 다음 스텝을 설계하는 역할. 타이핑이 아니라 판단이 핵심 업무가 된 개발자.
내일 당장 팀에 적용할 수 있는 질문은 단순하다. "우리 팀의 주니어 개발자가 쥔 AI와 시니어 개발자가 쥔 AI의 출력 품질 차이는 얼마나 되는가?" 그 차이가 크다면, 문제는 AI 모델이 아니다. 컨텍스트 설계가 아직 개인의 머릿속에 갇혀 있다는 신호다. 팀 리드가 먼저 이 격차를 가시화하고, 시스템으로 만드는 것—그게 AI-First 워크플로우 설계의 출발점이다.