Claude Code를 '채팅창'으로만 쓰고 있다면, 지금 손해 보고 있는 것이다
Claude Code를 쓰는 개발자 대부분이 비슷한 패턴에 머문다. 질문을 던지고, 기다리고, 결과를 검토하고, 다시 질문한다. 한 번에 하나의 태스크, 하나의 스레드. 마치 천재 개발자를 고용해놓고 하루 종일 티켓 하나만 처리하게 시키는 것과 다를 바 없다. 최근 dev.to에서 주목받는 세 편의 아티클은 이 패턴을 정면으로 문제 삼으며, 각기 다른 각도에서 같은 결론으로 수렴한다. Claude Code는 챗봇이 아니라 오케스트레이션 레이어라는 것.
첫 번째 축: 병렬화—'나는 지금 세 피처를 동시에 빌드 중이다'
"Stop Chatting With Claude. Start Orchestrating It."(dev.to)의 저자가 제안하는 멘탈 모델은 간단하다. 개발자는 더 이상 키보드 앞에 앉아 코드를 치는 사람이 아니라, AI 개발자 팀을 조율하는 엔지니어링 리드라는 것. 그 구체적인 실행 방법이 흥미롭다.
핵심은 Git Worktree와 Repo Copy의 용도 분리다. 피처 하나를 순차적으로 작업할 때는 git worktree add로 브랜치 단위 격리를 하면 충분하다. 하지만 여러 피처를 동시에 병렬로 진행할 때는 Worktree가 git 오브젝트를 공유하기 때문에 프로세스 충돌이 생긴다. 테스트 러너가 서로 리소스를 빼앗고, 락 충돌이 발생한다. 이 문제의 해결책은 cp -r로 리포를 통째로 복사하는 것이다. project-1, project-2, project-3—각 디렉토리가 완전히 독립된 Claude Code 세션을 가지며, 에이전트 A가 피처 A를 빌드하는 동안 에이전트 B는 피처 B를, 에이전트 C는 피처 C를 동시에 처리한다.
각 태스크 실행에는 두 개의 리뷰 게이트가 있다. 요구사항 충족 여부를 확인하는 Gate 1이 통과된 후에만 코드 품질을 검토하는 Gate 2가 작동한다. 이 두 게이트는 모두 컨텍스트 오염을 막기 위해 '프레시 서브에이전트'로 실행된다. 병렬화는 단순히 속도의 문제가 아니라 구조적 격리의 문제다.
두 번째 축: 지속 메모리—'6일 전 다른 머신에서 만든 버그를 기억하다'
Claude Code의 가장 근본적인 한계는 세션이 끝나면 모든 컨텍스트가 사라진다는 점이다. 새 세션은 항상 백지에서 시작한다. "The Amnesiac That Learned to Remember"(dev.to)의 저자는 이 문제를 sqlite-memory-mcp로 풀었다.
시작은 세 개의 Claude Code 세션이 동일한 JSONL 파일에 동시에 쓰면서 데이터가 조용히 손상되는 사고였다. JSONL은 append-only 로그 포맷이지 데이터베이스가 아니다. 그래서 WAL 모드 SQLite로 교체했다. Write-Ahead Logging은 멀티 세션 동시 쓰기를 트랜잭션 안전하게 처리하고, FTS5는 BM25 랭킹 기반 전문 검색을 제공한다.
여기서 한 발 더 나아간 것이 세션 간 태스크 핸드오프다. 한 세션이 "FTS5 인젝션 픽스는 절반 완료, 테스트는 미작성, 우선순위 높음"이라는 구조화된 태스크를 남기면, 다음 세션이 이 컨텍스트를 그대로 이어받아 시작한다. 더 나아가 Lamport 클락 기반의 Bridge Sync가 홈 데스크탑과 노트북 사이를 git 리포를 통해 동기화한다. 서울 집에서 작업하다 끊은 흐름을 지하철 안 노트북에서 그대로 이어가는 것이 가능해진다. 중요한 점은 로컬 퍼스트, 기본값은 프라이빗—클라우드 서비스도, API 키도, 월정액도 없다.
세 번째 축: 컨텍스트 최적화—'당신의 CLAUDE.md는 74%가 쓰레기다'
세 번째 문제는 더 조용하게 돈을 태우고 있다. "I built a linter that proves 74% of your AGENTS.md is wasting your AI agent's time"(dev.to)의 저자는 오픈소스 리포 8개의 컨텍스트 파일을 분석한 결과 가장 흔하고 가장 쓸모없는 패턴 네 가지를 발견했다.
디렉토리 트리는 에이전트가 ls로 200ms 안에 스스로 파악하는 정보다. 스택 설명("React 18, TypeScript, Tailwind로 빌드됨")은 package.json을 읽으면 되는 내용이다. 스타일 가이드는 .prettierrc나 .eslintrc가 이미 강제하고 있다. 낡은 파일 경로는 에이전트를 존재하지 않는 파일을 찾아 헤매게 만든다. 이 마지막 항목이 특히 위험한 이유는 에이전트가 오류를 디버깅하는 데 추가 토큰을 소비하고, 결국 스스로 올바른 경로를 찾아내기 때문이다. 비용을 세 배 지불하는 셈이다.
이를 해결하기 위해 만들어진 ctxlint는 LLM을 쓰지 않는다. 파일 존재 여부는 fs.existsSync()로, npm 스크립트 유효성은 JSON 파싱으로, README 중복은 트라이그램 오버랩으로 처리한다. 결정론적 문제를 LLM으로 푸는 건 느리고 비싸고 덜 정확하다. npx @ctxlint/ctxlint check 한 줄로 컨텍스트 파일의 신호 대 노이즈 비율을 측정할 수 있다.
세 축이 하나의 설계 원칙으로 수렴하는 지점
이 세 가지 접근법이 흥미로운 이유는 각각 독립적인 문제를 다루면서도 동일한 사고방식을 공유하기 때문이다. AI 에이전트의 품질은 지능의 문제가 아니라 구조의 문제라는 것.
병렬 워크플로우는 에이전트에게 명확한 계획(feature-name.md)과 격리된 실행 환경을 제공한다. 지속 메모리는 세션 단절이라는 구조적 결함을 SQLite 트랜잭션과 Lamport 클락으로 보완한다. 컨텍스트 최적화는 에이전트가 실제 작업에 집중할 수 있도록 노이즈를 제거한다. 세 가지 모두 에이전트의 능력을 끌어올리려는 시도가 아니라, 에이전트가 실패하는 구조적 이유를 제거하는 접근이다.
프론트엔드 개발자 입장에서 이 흐름은 컴포넌트 설계와 닮아 있다. 좋은 컴포넌트는 외부 의존성을 최소화하고, 상태를 명확히 정의하며, 테스트 가능한 경계를 갖는다. 좋은 에이전트 설계도 마찬가지다. 컨텍스트 경계를 명확히 하고, 세션 간 상태를 지속시키며, 실행 환경을 격리한다.
지금 당장 시작할 수 있는 것
세 도구를 한꺼번에 도입할 필요는 없다. 지금 당장 가장 쉽게 시작할 수 있는 것은 ctxlint다. 이미 CLAUDE.md나 AGENTS.md가 있다면 npx @ctxlint/ctxlint check를 실행해보자. 현재 컨텍스트 파일이 얼마나 많은 노이즈를 담고 있는지 수치로 확인할 수 있다.
다음은 .claude/plans/ 디렉토리에 태스크 계획을 파일로 저장하는 습관이다. 세션이 끊겨도 다음 세션이 동일한 계획 파일을 참조해 이어갈 수 있다. 이 단순한 파일 기반 컨텍스트 지속성이 sqlite-memory-mcp의 핵심 아이디어와 방향을 공유한다.
병렬 에이전트는 리포 복사와 독립 세션이라는 다소 로우레벨한 접근이지만, 지금 당장 두세 개의 독립적인 피처를 동시에 진행해야 한다면 기술적 진입 장벽이 낮다. cp -r과 Claude Code 세션 열기가 전부다.
AI 에이전트를 팀 개발 흐름에 녹이는 일은 여전히 진행 중인 실험이다. 하지만 방향은 점점 선명해지고 있다. 에이전트에게 더 좋은 프롬프트를 던지는 것보다, 에이전트가 일할 수 있는 더 좋은 구조를 만드는 것이 먼저다.