에이전트에게 일을 넘기기 전에 무엇을 준비해야 할까. 많은 팀이 이 질문을 건너뛴다. 도구를 설치하고, 첫 태스크를 던지고, 결과물이 나오면 '된다'고 판단한다. 그런데 에이전트가 한두 개일 때는 괜찮다. 태스크가 늘어나고, 프로젝트가 쌓이고, 팀원이 동시에 여러 에이전트를 돌리기 시작하면 균열이 온다. 컨텍스트가 섞이고, 결정이 어디서 났는지 추적이 안 되고, 리뷰 큐가 막힌다. 이건 에이전트의 문제가 아니라 설계의 문제다.
1. 계획은 마크다운으로, 리포에 산다
dev.to의 'Plans Are the New Code'는 이걸 정확히 짚는다. 에이전트는 당신이 건네는 스펙을 그대로 증폭한다. 한 줄짜리 티켓을 주면 LLM 속도로 N개의 해석이 나온다. 인터페이스 경계, 에러 형태, 통합 지점까지 명시한 50줄짜리 스펙을 주면 팀 전체가 오후 한 나절에 수렴한 결과물을 만든다. 여기서 핵심은 '문서의 존재'가 아니라 '에이전트가 읽을 수 있는 위치에 있느냐'다. Confluence 뒤에 SSO 로그인이 걸려 있거나, OneDrive에 .docx로 올라가 있으면 에이전트는 그 문서를 읽지 못한다. 결국 인간이 수동으로 컨텍스트를 붙여넣는 구조로 돌아간다. 계획 문서는 리포 안에, 마크다운으로 있어야 한다. diff 가능하고, 버전 관리되고, 에이전트가 파싱할 수 있는 포맷이어야 비로소 '레버리지'가 생긴다.
구조도 중요하다. 번호가 붙은 모듈형 스펙 섹션, 판단이 갈리는 지점을 기록한 아키텍처 결정 레코드(ADR), 패키지별 제약을 담은 README, 그리고 다음 독자가 '이게 왜 이렇게 돼 있지?'라고 물을 만한 지점에 박힌 코드 주석. 이 네 레이어가 각각 '무엇을', '왜 이 선택을', '어떻게 작동하는지', '왜 이 코드가 여기 있는지'를 분담한다. 이걸 하나의 긴 문서로 합치면 문서가 썩는다. 레이어를 분리하는 게 핵심이다.
2. 컨텍스트는 프로젝트 단위로 격리한다
멀티 프로젝트 환경에서 가장 먼저 무너지는 건 컨텍스트 격리다. 오전 내내 프로젝트 A의 인증 아키텍처를 다루다가 오후에 프로젝트 B로 전환하면, 에이전트는 A의 잔여 컨텍스트를 B에 적용하려 한다. A에서 맞는 결정이 B에서는 틀릴 수 있다. dev.to의 'Managing AI Context Across Multiple Projects' 아티클은 이 문제를 구조로 푼다. 각 프로젝트마다 세션 상태 파일, 제약 파일, 의사결정 로그를 분리하고, 프로젝트 허브를 세션 진입점으로 삼는다. 공유 개념(공통 API, 디자인 시스템, 규제 요건)은 wiki/concepts/에 한 번만 작성하고 각 프로젝트에서 링크한다. 중복 없이 업데이트가 전파된다.
실용적인 포인트는 컨텍스트 스위칭 프로토콜이다. 프로젝트를 전환할 때마다 현재 세션 상태를 업데이트(3~4분)하고, 새 세션에서 새 프로젝트의 허브를 로드한다. 같은 세션에서 프로젝트를 바꾸지 않는다. 잔여 컨텍스트가 너무 강하기 때문이다. 이 구조를 세팅하는 데 반나절이 걸리지만, 저자에 따르면 첫 주에 회수된다. 6개 프로젝트를 동시에 돌릴 때 컨텍스트 혼선으로 낭비되는 하루 1~2시간이 사라진다.
3. 설계 대화를 먼저, 계획은 그 다음
'I Don't Start with a Plan. Here's What I Do First.'는 또 다른 실용적 관점을 더한다. 계획을 만들기 전에 설계 대화가 먼저다. Jira 이슈, GitHub 스레드, 기존 설계 문서를 에이전트에게 먹인 뒤, 관련 코드를 탐색하고 유사 문제가 어떻게 해결됐는지 추적하게 한다. 그 다음 설계안을 요청한다. 이때 CLAUDE.md에 한 줄이 있느냐 없느냐가 결과를 가른다: '여러 대안이 있을 때, 가장 가능성 높은 것을 자동으로 선택하지 말고 각 옵션의 장단점과 확신도를 함께 보여줄 것.' 이 한 줄이 없으면 에이전트는 스스로 판단하고 달린다. 있으면 설계 토론이 자연스럽게 일어난다.
같은 맥락에서, 컨텍스트 창이 45% 차기 전에 핸드오버를 트리거하는 습관도 중요하다. 자동 압축에 맡기면 이전 결정이 조용히 사라진다. 직접 새 세션에 현재 상태(완료된 것, 결정된 것, 다음 스텝, 주의사항)를 패키징해서 넘기는 게 훨씬 안전하다. 에이전트가 세션 수명을 관리하게 두지 말라는 원칙이다.
팀 리드의 역할은 설계 밀도를 높이는 것
세 가지 실천법을 관통하는 공통 원칙이 있다. 에이전트는 생각을 대신하지 않는다. AI는 타이핑 비용을 낮추지, 사고 비용을 낮추지 않는다. 구현의 무게중심이 코드에서 스펙으로, 코드 리뷰에서 설계 문서로 이동하고 있다. 팀 리드가 에이전트에게 일을 넘기기 전에 해야 할 일은 결국 이 세 가지다: 에이전트가 읽을 수 있는 위치에 구조화된 계획 문서를 둘 것, 프로젝트별로 컨텍스트를 격리할 것, 설계 결정을 에이전트에게 떠넘기지 말고 대화로 수렴시킬 것. 도구는 준비됐다. 설계는 여전히 리드의 몫이다.