에이전트를 팀 워크플로우에 붙이는 건 어렵지 않다. 문제는 그 다음이다. 데모에서 잘 돌아가던 에이전트가 프로덕션에서 비용 폭탄을 터뜨리거나, 오래된 메모리를 근거로 엉뚱한 액션을 실행하거나, 7단계까지 진행된 작업이 크래시 한 번에 처음부터 재시작된다. 이건 모델 문제가 아니다. 설계 문제다.
세 가지 관점—에이전트 아키텍처(하네스), 토큰 비용 최적화, 메모리 거버넌스—을 따로 보면 각각 독립된 기술 이슈처럼 보인다. 하지만 프로덕션 에이전트를 실제로 운영해보면 이 세 가지는 서로 맞물려 있고, 하나라도 설계가 빠지면 나머지 두 개도 흔들린다.
1. 하네스: 에이전트를 감싸는 구조가 경쟁력이다
tomtunguz.com의 분석은 이걸 '하네스(Harness) 시대'라고 명명한다. 모든 팀이 동일한 모델에 접근할 수 있는 시대에는 모델 스펙이 아니라 그 모델을 얼마나 잘 감싸느냐가 경쟁력을 가른다는 논지다. AI를 야생마에 비유하는 건 과장처럼 들리지만, 실제로 LLM을 프로덕션에 올려본 팀이라면 이 감각을 안다.
하네스를 구성하는 7개 레이어 중 팀 리빌딩 관점에서 즉시 설계가 필요한 세 가지를 꼽으면 이렇다.
Context & Memory: 범용 모델은 도메인별 맞춤 검색 시스템 없이는 쓸모가 반감된다. 단기 세션 메모리와 장기 컨텍스트 DB를 분리하고, 팀의 표준운영절차(SOP)를 에이전트가 참조 가능한 '레시피북' 형태로 구조화해야 한다.
State & Persistence: 10단계 작업의 7단계에서 에이전트가 크래시하면 8단계부터 재개할 수 있어야 한다. 체크포인트, 세션 스레드, 아티팩트 저장소 없이 에이전트를 장시간 작업에 투입하는 건 복불복 도박이다.
Observability & Governance: '볼 수 없는 것은 신뢰할 수 없다.' 모든 도구 호출을 로깅하고, evals를 회귀 테스트처럼 운영하고, 고위험 결정에는 human-in-the-loop를 설계해야 데모가 프로덕션 시스템으로 전환된다.
2. 토큰 비용: 가격이 내려가도 청구서는 올라간다
dev.to의 엔지니어링 습관 분석이 짚는 역설은 명확하다. 토큰 단가는 떨어지지만 볼륨이 더 빠르게 늘어난다. 단가 $15→$4로 73% 하락해도 볼륨이 10M→600M으로 60배 폭증하면 청구서는 $150에서 $2,400으로 뛴다. 같은 제품, 같은 모델인데 6주 만에 비용이 3배가 된 팀의 이야기는 이 업계에서 이제 흔한 패턴이다.
비용 설계에서 당장 팀에 적용할 수 있는 세 가지 습관이 있다.
모델 라우팅: 대부분의 프로덕션 워크로드는 소형 모델로 처리 가능한 작업이 대형 모델 가격표를 달고 있다. 분류·추출은 Haiku급, 요약·초안은 Sonnet급, 복잡한 추론만 Opus급으로 라우팅하는 간단한 분류기 하나가 비용 구조를 바꾼다.
캐싱 전략: 동일한 시스템 프롬프트가 매 요청마다 전송되고 있다면 프롬프트 프리픽스 캐싱만으로 인풋 비용을 절반 가까이 줄일 수 있다. 시맨틱 캐싱까지 조합하면 FAQ성 트래픽의 상당 부분이 LLM 호출 없이 처리된다.
RAG 정밀도: 큰 청크를 많이 집어넣는 RAG는 조용한 비용 킬러다. 256토큰 단위의 작은 청크, 관련성 임계값 기반의 Top-K 검색, 메인 컨텍스트 윈도우 진입 전 경량 리랭커로 필터링—이 세 단계가 'RAG를 제대로 하는 것'의 실체다.
3. 메모리 거버넌스: 관련성이 권한이 되면 안 된다
에이전트 메모리에 관한 dev.to의 분석은 단순한 메모리 설계 가이드를 넘어선다. 핵심 명제는 이것이다: 관련성(relevance)은 권한(authority)이 아니다.
검색 시스템은 '현재 요청과 가장 가까운 메모리가 무엇인가'에 최적화되어 있다. 하지만 에이전트 안전성은 다른 질문을 요구한다: '어떤 메모리가 이 액션을 결정할 수 있는가?' 오래된 배포 명령, 만료된 자격증명, 철회된 승인 기록—이 모두가 높은 의미적 유사도를 가진 채로 검색될 수 있다.
Hermes Agent 아키텍처 분석에서 제안하는 메모리 역할 분리는 실용적이다. 사실(facts)은 MEMORY.md, 운영 규칙(operating rules)은 AGENTS.md나 전용 정책 레이어, 절차(procedures)는 스킬로 분리하는 방식이다. 평범한 텍스트 더미로 합쳐진 메모리는 의미적으로 가장 '관련성 높은' 메모리가 가장 '권한 있는' 메모리를 이길 수 있는 구조를 만든다.
세션 중 메모리 동결(frozen snapshot) 문제도 실제 운영에서 중요하다. 에이전트가 세션 중 메모리를 갱신해도 현재 프롬프트 컨텍스트는 세션 시작 시점의 스냅샷으로 고정된다. 낮은 위험도의 사용자 선호 정보라면 무방하다. 하지만 배포 타깃 변경, 자격증명 폐기, 승인 규칙 업데이트가 이 동결 구간에 걸리면 에이전트는 폐기된 정보를 근거로 실제 액션을 실행할 수 있다.
설계 없이 붙이면 속도가 아니라 부채가 쌓인다
세 가지 관점을 통합하면 결국 같은 결론으로 수렴한다. 에이전트를 팀에 붙이는 것 자체는 쉽다. 하네스 없이 붙이면 신뢰성이 없고, 비용 설계 없이 붙이면 청구서가 폭증하고, 메모리 거버넌스 없이 붙이면 에이전트가 잘못된 권한으로 잘못된 액션을 실행한다.
'가장 잘 타는 자(best riders)가 승리한다'는 하네스 시대의 논리는 틀리지 않았다. 하지만 잘 탄다는 것은 빠르게 붙인다는 뜻이 아니다. 에이전트가 어디서 멈춰야 하는지, 어떤 메모리를 믿어야 하는지, 어떤 모델에 어떤 작업을 보내야 하는지—이 세 가지 설계 판단이 선행되지 않으면 에이전트는 팀의 속도가 아니라 운영 복잡도를 가속한다. 프로덕션에 올리기 전에 이 구조를 먼저 그려라.