AI 에이전트를 프로덕션에 올리는 일은 생각보다 복잡하다. 로컬 데모에서 잘 돌아가던 에이전트가 실제 배포 환경에서 무너지는 이유는 대부분 하나가 아니라 세 가지가 동시에 얽혀있기 때문이다. 세션마다 컨텍스트가 리셋되고, 품질 게이트는 평균 합격률에 속고, 모델은 비용 절감 명목으로 검증 없이 교체된다. 최근 세 편의 실무 중심 글이 이 문제를 각각 다루고 있는데, 묶어서 읽으면 체크리스트가 된다.
문제 1: 에이전트는 매 세션마다 기억을 잃는다
Cursor를 열고, Claude를 열고, 아키텍처 문서를 붙여넣고, 폴더 구조를 다시 설명하는 루틴—대형 코드베이스에서 이 반복은 단순한 불편이 아니라 실질적인 생산성 손실이다. dev.to에 올라온 Cortex 프로젝트는 이 문제를 CORTEX_MEMORY.md 파일 하나로 접근한다. 코드베이스의 모든 소스 파일을 구조화된 요약으로 변환하고, SHA-256 해시 비교로 변경된 파일만 선택적으로 재요약한다. 결과물은 특정 AI 도구에 종속되지 않는 순수 마크다운이다.
접근 방식 자체는 단순하지만, 실용적 판단이 돋보이는 부분이 있다. 파일 감시자(noisy), Git hook(커밋 시점에만 동작), 수동 업데이트(아무도 안 한다)를 모두 검토하고 세션 시작 시 해시 체크로 수렴한 결정 과정이다. 토큰 예산도 보수적으로 잡았다—파일당 2,000토큰, 세션당 10,000토큰, GPT-4o mini 기준 세션당 약 $0.003. 팀 리드 입장에서 이런 명시적 비용 상한선이 없는 메모리 레이어는 프로덕션에 들이기 어렵다.
다만 한계도 분명하다. 현재 알파 버전은 파일당 100KB, 런당 50개 파일 상한이 있어 대규모 모노레포에는 바로 적용하기 어렵다. MCP 서버 연동과 멀티모델 지원은 로드맵 단계다. 지금 당장 쓰기보다는 "영구 메모리 레이어를 어떻게 설계할 것인가"의 레퍼런스 구현으로 참고하는 편이 현실적이다.
문제 2: 합격률 92.5%는 안전하지 않을 수 있다
CI 파이프라인 끝에서 eval 점수를 보고 배포를 결정하는 방식에는 구조적 맹점이 있다. 평균은 모든 실패에 동일한 가중치를 부여하기 때문에, 공백 문자 오류 40건과 고객 이메일이 로그에 노출된 1건이 pass-rate에 미치는 영향이 같다. 충분히 큰 테스트 스위트에서 심각한 단일 실패는 통계적으로 반올림되어 사라진다.
dev.to의 severity_gate.py는 이 간극을 정확히 겨냥한다. 도구의 로직은 단순하다: eval 결과 JSON과 정책 파일을 읽어 SHIP / REVIEW / BLOCK 세 가지 판정을 반환한다. critical 심각도 실패가 하나라도 있으면 pass-rate와 무관하게 BLOCK이다. 같은 40개 케이스, 같은 92.5% 합격률에서 두 케이스의 severity_class를 low에서 critical로 바꾸면 판정이 SHIP에서 BLOCK으로 뒤집힌다. pass-rate는 미동도 없다.
이 도구의 실용성은 의존성이 없다는 점에서 온다. Python 표준 라이브러리만 사용하고, 네트워크 없이 오프라인으로 동작하며, 출력이 결정론적이다. CI 게이트 exit code(0/1/2)도 명확하게 정의되어 있다. 단, 명시적 한계도 있다: 심각도 레이블은 팀이 직접 붙여야 한다. "garbage labels in, garbage gate out"—도구는 레이블의 일관성을 보장하지 않는다. 레이블 정책을 팀 내부에서 합의하고 유지하는 것이 이 게이트 설계의 실제 난이도다.
문제 3: 모델 교체는 비용이 아니라 계약 문제다
오픈웨이트 모델이 프로덕션 선택지로 진지하게 거론되기 시작했다. 비용 압박, AI 게이트웨이의 멀티모델 지원 성숙, 데이터 로컬리티 요구가 맞물리면서다. 그런데 많은 팀이 모델 교체를 "프롬프트 몇 개 돌려보고 가격 비교"로 처리하다가 프로덕션에서 터진다. dev.to의 오픈웨이트 모델 롤아웃 체크리스트는 이 함정을 "모델을 교체하기 전에 계약을 먼저 써라"는 한 줄로 정리한다.
여기서 계약이란 태스크 유형, 출력 스키마, 허용 레이턴시, 태스크당 최대 비용, 폴백 모델, 인간 리뷰 조건을 명시한 YAML 스펙이다. 이 계약이 있어야 "이 모델이 우리 제품의 이 태스크에 더 낫다"는 판단을 감이 아니라 측정으로 할 수 있다. 체크리스트가 강조하는 핵심 지표 하나는 토큰 단가가 아니라 성공한 태스크당 비용이다. 80% 더 싸지만 실패율이 두 배인 모델은 재시도, 폴백, 지원 티켓, 고객 신뢰 손실까지 합산하면 더 비싸다.
모델 배포 경로(hosted API / managed private / self-hosted) 선택도 운영 부하 전체를 포함해 계산해야 한다. 자체 호스팅은 GPU 가동률, 양자화 영향, 보안 패치, 온콜 오너십이 모두 팀 몫으로 넘어온다. 싸게 시작해서 비싸게 운영하는 패턴이 여기서 반복된다. 라우팅 레이어를 모델 직접 호출 대신 게이트웨이로 추상화하는 것도 같은 맥락이다—모델이 실패할 때 코드베이스 전체를 수정하는 게 아니라 라우팅 정책만 바꾸면 된다.
세 문제가 수렴하는 곳
세 글이 각각 다른 층위를 다루지만, 결국 같은 질문으로 수렴한다: AI 에이전트의 동작을 어떻게 예측 가능하게 만들 것인가. 메모리 레이어는 컨텍스트 일관성을, 심각도 게이트는 배포 결정의 예측 가능성을, 모델 계약은 교체 가능성과 측정 기준을 각각 설계한다. 세 가지 중 하나라도 빠지면 에이전트는 프로덕션에서 예측 불가능하게 행동한다.
팀 리드라면 지금 당장 세 가지를 점검할 수 있다. 첫째, 현재 AI 에이전트가 세션 간 컨텍스트를 어떻게 유지하는가—아니면 매번 처음부터 시작하는가. 둘째, CI 파이프라인의 배포 게이트가 pass-rate 단일 숫자인가, 아니면 실패의 심각도 분포를 보는가. 셋째, 프로덕션에서 쓰는 모델의 교체 기준이 비용 감각인가, 아니면 태스크별 계약 스펙인가.
세 질문에 명확한 답이 없다면, 에이전트가 프로덕션에서 신뢰받는 건 운의 문제가 된다. AI 에이전트의 성숙도는 모델의 성능이 아니라 이 세 가지 설계 결정의 명시성으로 측정된다.