Claude Code를 일상적으로 사용하면서, 맡고 있는 프로젝트가 2개, 3개로 늘어날 때 다음과 같은 증상을 겪고 계시지는 않습니까?

• 방금까지 이야기하던 프로젝트 A의 문맥이, 프로젝트 B 이야기를 한 직후에 깨끗하게 사라져 버린다
• "그 수정 사항, 끝났어?"라고 물으면, 세션은 이미 그 이야기를 기억하지 못한다
• 여러 태스크를 하나의 대화에서 전환할 때마다, 상황 설명부터 다시 해야 하는 상황에 처한다
• 정신을 차려보니 자신이 "Claude의 기억 담당자"가 되어 있고, 진척 관리를 인간이 대신하고 있다

이것은 Claude(혹은 다른 LLM 에이전트)의 능력이 부족해서 발생하는 것이 아닙니다. 하나의 대화 세션에 성격이 다른 여러 업무를 동시에 집어넣으려는 사용 방식 자체가, 여러 프로젝트를 병행하는 용도에 맞지 않기 때문입니다. 이 기사에서는 왜 그런 현상이 발생하는지를 구조적으로 설명하고, 이를 극복하기 위한 발상의 전환을 제시합니다.

왜 망가지는가: 3가지 벽

원인은 독립된 3가지 제약으로 나눌 수 있습니다.

벽 1: 컨텍스트(Context)는 "읽기만 해도" 줄어드는 유한한 자원

컨텍스트 윈도우(Context Window)의 소비는 사용자가 입력하는 지시문의 길이로만 결정되지 않습니다. 파일을 읽고, 커맨드 출력을 읽고, 대화를 기억하는 그 모든 것이 소비에 가산됩니다.

프로젝트 A의 코드를 읽어들인 직후에 프로젝트 B 이야기로 전환했다가 다시 돌아온다. 이를 반복하면 "지금은 관계없는 정보"가 컨텍스트에 계속 자리 잡고 있어, 정말 필요한 정보를 밀어내게 됩니다. 까다로운 점은 이것이 대화가 길어질수록 악화되는 일방향적 열화이며, 세션을 재시작하지 않는 한 회복되지 않는다는 점입니다.

벽 2: 응답은 단선적이며, 병행되는 것처럼 보일 뿐이다

Claude Code는 한 번에 하나의 응답만 생성할 수 있습니다. 시간이 오래 걸리는 처리를 하나 실행하는 동안, 해당 세션 자체는 (별도의 백그라운드 실행 메커니즘을 사용하지 않는 한) 다른 용도로 사용할 수 없습니다.

결과적으로 "다음에 무엇을 시킬 것인가"에 대한 스케줄링을 인간이 담당하게 됩니다. 이는 본래 에이전트에게 맡기고 싶었던 업무 그 자체입니다.

벽 3: 태스크의 무게와 위험도가 맞지 않은 채 같은 운동장에 올라간다

가벼운 조사도, 중요한 설계 판단도, 위험도가 높은 코드 실행도 모두 같은 세션, 같은 권한 설정으로 다루면 다음과 같은 일이 발생합니다.

• 정형적인 작업에 고정밀(이자 고비용) 모델을 사용하게 된다
• 반대로 중요한 판단을 대충 처리하여 나중에 재작업(rework)을 하게 된다
• "이것은 인간의 승인이 필요한 조작인가"에 대한 기준이 그 자리에서 흔들리며, 외부 공개나 과금을 동반하는 조작까지 기세로 실행하려 한다

3가지 벽은 별개의 문제가 아닙니다. 뿌리는 하나, **"하나의 뇌에 모든 것을 맡기고 있다"**는 점에 귀결됩니다.

발상의 전환: 에이전트를 "1명"이 아닌 "팀"으로 설계하기

해결 방향은 인간의 조직 운영에서 빌려온다고 이해하면 쉽습니다. 한 명의 매니저가 모든 프로젝트의 실무를 직접 수행하는 것이 아니라, 안건마다 담당자를 세우고 매니저는 의사결정과 진척 관리에 전념하는 방식입니다. 이를 그대로 세션 설계에 적용합니다.

• 감독역: 전체를 조망하며 태스크를 선택하고, 담당 세션에 지시를 내리며, 결과물을 검수하고 인간에게 보고한다. 직접 구현하지는 않는다.
• 실행역: 프로젝트별로 세우는 전담 세션. 코드를 만지고, 실험을 돌리고, 원고를 작성한다.

이 분업의 핵심은 단순히 역할을 나누는 것뿐만 아니라, "감독역이 직접 실무를 하지 않음"으로써 컨텍스트 소비가 비대칭적으로 이루어진다는 점입니다. 감독역이 읽는 것은 각 프로젝트의 상태를 요약한 파일과 보고서만으로 충분하며, 코드의 내용이나 로그 전문을 읽어들일 필요가 없습니다. 결과적으로 감독역은 장기간 다운되지 않고 전체를 계속 지켜볼 수 있습니다.

나아가 이 구조는 위험도에 따른 격리와도 맞물립니다. 시행착오가 심한 프로젝트에는 샌드박스(Sandbox) 환경을 부여하여 호스트에 접근하지 못하게 합니다. 태스크의 무게에 따라 모델의 등급을 바꿉니다. 그리고 인간의 승인이 필요한 조작(외부 공개, 과금, 외부 전송)은 어떤 세션에서든 반드시 인간에게 돌아오도록 하는 규칙을 처음부터 심어둡니다.

과도한 기대는 경계해야 합니다. 이러한 분업 체계를 구축한다고 해서 Claude 자체의 능력이 올라가는 것도 아니고, 구현이나 설계 판단의 질이 마법처럼 좋아지는 것도 아닙니다. 변하는 것은 "인간이 진척 관리자로부터 해방된다"는 것과, "병행하는 프로젝트 수를 늘려도 1개 프로젝트당 대응 품질이 저하되기 어려워진다"는 두 가지 점입니다.

여기서부터는 "구성 방법"의 문제로 넘어갑니다

진단(3가지 벽)과 발상의 전환(팀으로서 다루기)까지가 이 기사에서 공유하고 싶었던 내용입니다.

여기서부터는 실제로 직접 움직여보면 생기는 의문들

• 감독 역할과 실무 역할의 권한을 어떻게 구분할 것인가
• 상태(State)를 어떤 파일에 어떻게 기록할 것인가
• tmux로 어떻게 실행하고, 위험한 조작을 어떻게 격리할 것인가
• 외부에서 어떻게 개입할 것인가

이것들은 실제로 직접 움직여보며 재현할 수 있는 수준의 이야기입니다. 이 정도 수준까지 깊게 들어가면 기사 한 편으로는 다 담을 수 없습니다.

이후의 내용은 실제로 수개월 동안 이 체제를 운용하고 있는 설정 파일과 실제로 발생했던 장애 기록을 포함하여 "Claude Code로 구축하는 자율 멀티 에이전트 (Autonomous Multi-Agent) 개발 체제"로 정리해 두었습니다. 이 기사에서 언급한 "3가지 벽"과 "감독 역할/실무 역할"의 분업을 실제로 작동하는 형태로 구현하고 싶은 분들을 위한 내용입니다.

Discussion