핵심 이슈: "세션 하나 더 돌리면 되지" 뒤에 숨겨진 제곱 비용
팀원에게 "Claude Code 세션 끊지 말고 계속 이어서 작업해"라고 말한 적 있다면, 그 한 마디가 비용을 기하급수적으로 끌어올리고 있을 가능성이 높습니다. exe.dev의 분석을 정리한 dev.to 기사에 따르면, LLM 기반 코딩 에이전트의 비용 구조는 선형이 아니라 이차(quadratic)입니다. 에이전트가 API를 호출할 때마다 전체 대화 히스토리를 캐시에서 읽어오는데, 컨텍스트 길이와 호출 횟수가 동시에 증가하기 때문입니다. 토큰이 27,500개일 때 캐시 읽기가 전체 비용의 50%를 차지하던 것이, 100,000개에 도달하면 87%까지 치솟습니다. '별것 아닌' 기능 하나 구현에 $12.93이 날아가는 현실 — 팀 단위로 에이전트를 5명이 굴리면 월 비용이 어떻게 되는지 금방 계산이 됩니다.
이 문제를 AI한테 물어보면 "세션을 짧게 끊으세요"라는 뻔한 답이 나옵니다. 맞는 말이지만, 팀에서 실전 적용하려면 세 가지가 함께 돌아가야 합니다: 비용 구조를 이해한 세션 분리 전략, 세션이 끊겨도 맥락을 유지하는 메모리 시스템, 그리고 병렬 세션을 한눈에 관리하는 오케스트레이션 도구.
맥락 해석 1 — 세션을 끊으면 컨텍스트가 사라진다, 그래서 메모리를 설계해야 한다
비용 때문에 세션을 자주 끊으면 컨텍스트 유실이라는 두 번째 문제와 정면으로 충돌합니다. dev.to의 SignalStack은 이 문제를 3계층 파일 기반 메모리 시스템으로 해결한 사례를 공유했습니다. Tier 1은 MEMORY.md — 운영자 선호도, 실패에서 얻은 교훈, 반복 패턴 등 장기 기억을 마크다운 한 파일에 큐레이션합니다. Tier 2는 일별 로그 파일(memory/2026-02-07.md) — 당일과 전일 이틀치만 로딩해서 토큰을 절약하면서도 최근 맥락을 유지합니다. Tier 3은 JSON 상태 파일 — 마지막 하트비트 시각, 대기 태스크 같은 구조화 데이터를 기계가 바로 읽을 수 있는 포맷으로 관리합니다.
이 구조에서 제가 특히 주목한 건 서브 에이전트에는 전체 메모리를 로딩하지 않는다는 설계 원칙입니다. is_main_session() 체크로 서브 에이전트에게는 해당 태스크에 필요한 타깃 컨텍스트만 넘기는 거죠. 앞서 이야기한 이차 비용 문제와 정확히 맞물립니다 — 서브 에이전트의 컨텍스트를 작게 유지하면 비용도 줄고 집중도도 올라갑니다. 팀 차원에서 보면, 이런 메모리 아키텍처를 표준 규약으로 정해두면 누가 세션을 끊고 다시 시작해도 에이전트가 "어제 뭐 했더라"를 잃지 않습니다.
맥락 해석 2 — 병렬 세션이 늘면, 오케스트레이션 도구가 필수다
세션을 짧게 끊고 서브 에이전트를 분리하면, 자연스럽게 동시에 돌아가는 세션 수가 늘어납니다. 이걸 터미널 탭 열 개로 관리하는 건 일주일이면 한계에 부딪힙니다. GeekNews에 소개된 오픈소스 도구 agent-of-empires가 바로 이 페인 포인트를 겨냥합니다. tmux 세션과 git worktree를 결합해서 각 에이전트를 독립된 세션으로 실행하고, TUI 대시보드에서 생성·모니터링·전환·삭제를 한 화면에서 처리합니다. Docker 샌드박싱으로 에이전트 간 격리까지 지원하니, "에이전트가 다른 브랜치 코드를 건드려서 충돌 났다"는 사고도 구조적으로 막을 수 있습니다.
AI-First 팀 리빌딩 관점에서 보면, 이런 오케스트레이션 계층은 단순한 편의 도구가 아니라 팀 개발 워크플로우의 인프라입니다. 개발자 한 명이 기능 구현 에이전트, 테스트 생성 에이전트, 리뷰 에이전트를 병렬로 돌리는 시대에, 세션 관리가 안 되면 컨텍스트가 꼬이고 비용이 폭주하고 결국 사람이 수동으로 정리하는 데 시간을 쏟게 됩니다.
맥락 해석 3 — 컨텍스트 붕괴는 버그가 아니라 기본값이다
dev.to의 John Wade는 6개월간 ChatGPT와 Claude로 프로젝트를 운영하면서 겪은 LLM 워크플로우 붕괴를 7단계(C1~C7)로 분류했습니다. 컨텍스트 포화(C1), 지시어 희석(C2), 용어 드리프트(C3), 참조 모호성(C4), 목표 확장(C5), 근거 소멸(C6), 스레드 파편화(C7). 핵심 통찰은 "붕괴는 실패 상태가 아니라 기본 상태(default state)"라는 겁니다. LLM은 기억을 검색하는 게 아니라 패턴에서 재생성하기 때문에, 스캐폴딩 없이 장기 프로젝트를 굴리면 반드시 무너집니다.
하지만 Wade가 동시에 경고하는 건, 스캐폴딩이 프로젝트 자체가 되어버리는 역설입니다. 온톨로지 파일, 컨텍스트 팩, 의사결정 로그를 유지보수하는 데 실제 개발보다 더 많은 시간을 쓰게 되면 본말이 전도됩니다. 그의 결론 — "스캐폴딩은 서보(servo)지, 엔진이 아니다" — 은 팀 운영에도 그대로 적용됩니다. 메모리 시스템과 세션 관리 규약은 최소한으로 시작해서 필요한 만큼만 추가하는 게 맞습니다.
시사점: AI-First 팀이 지금 해야 할 3가지
소스 기사 네 편을 종합하면, AI 코딩 에이전트를 팀 단위로 운영할 때의 핵심 원칙이 세 가지로 수렴합니다.
첫째, 세션 수명을 설계하라. 스펙 기반으로 태스크 범위를 정의하고, 하나의 태스크가 끝나면 세션을 끊습니다. 이것만으로도 이차 비용 곡선을 선형에 가깝게 눌러 내릴 수 있습니다. 서브 에이전트를 적극 활용해 메인 컨텍스트의 팽창을 막는 건 덤입니다.
둘째, 메모리를 코드처럼 관리하라. 3계층 메모리 — 큐레이션된 장기 기억, 시간 기반 단기 로그, 구조화된 상태 파일 — 를 Git으로 버전 관리하면, 세션을 자주 끊어도 컨텍스트 유실 없이 연속성을 확보할 수 있습니다. 벡터 DB는 파일 수가 수천 개를 넘을 때 도입해도 늦지 않습니다.
셋째, 오케스트레이션을 인프라로 취급하라. agent-of-empires 같은 세션 매니저로 병렬 에이전트를 관리하고, 각 에이전트의 실행 환경을 격리하세요. TUI 종료 후에도 에이전트가 백그라운드에서 돌아간다는 건, 사람이 퇴근해도 에이전트가 일하는 워크플로우가 가능하다는 뜻입니다.
전망: 비용 관리가 곧 팀의 경쟁력이 된다
기사 원문의 메타 레슨이 정확합니다 — 컨텍스트 관리, 비용 관리, 에이전트 오케스트레이션은 전부 같은 문제입니다. 이 셋을 초기에 잡은 팀은 같은 속도로 배포하면서 피처당 비용을 1/3로 줄일 수 있고, 그 여유를 아키텍처 개선이나 품질 향상에 재투자할 수 있습니다. AI 에이전트를 '무한 코딩 인턴'으로 방치하는 팀과, 비용·메모리·세션의 삼각 구조를 설계하는 팀 사이의 격차는 분기마다 벌어질 겁니다. 지금이 그 구조를 세울 때입니다.