대부분의 에이전트 장애는 모델이 틀려서가 아니라, 모델에게 "지금 보면 안 되는 맥락"까지 같이 보여줘서 생긴다. 성능 최적화의 시작은 더 큰 모델이 아니라, 더 엄격한 관문이다.
에이전트를 운영하다 보면 비슷한 장면이 반복된다. 처음에는 의욕적으로 데이터를 모은다. 대화 로그, 운영 규칙, 사용자 선호, 실패 사례, 과거 산출물까지 최대한 많이 붙인다. 맥락이 많을수록 정답에 가까워질 것 같기 때문이다. 하지만 실제 서비스에서 이 방식은 오래 버티지 못한다. 응답 시간이 길어지고, 답변 톤이 흔들리고, 방금 받은 요청보다 지난주 히스토리에 끌려가는 일이 잦아진다. 어떤 날은 분명 같은 질문인데도 결과가 들쭉날쭉하다.
이때 팀은 흔히 "모델 교체"를 먼저 고민한다. 더 비싼 모델, 더 긴 컨텍스트 윈도, 더 많은 리트라이. 물론 도움이 되는 경우도 있다. 그런데 구조가 잘못된 상태에서는 업그레이드가 문제를 가리기만 한다. 핵심 원인은 대체로 단순하다. 무엇을 넣을지보다, 무엇을 막을지 설계하지 않았기 때문이다. 에이전트가 안정적으로 일하려면 "컨텍스트 방화벽(context firewall)"과 "정책 라우팅(policy routing)"이 필요하다.
1. 컨텍스트 방화벽: 모델 앞단에서 맥락 유입을 통제하는 층
컨텍스트 방화벽은 네트워크 보안의 방화벽과 비슷한 역할을 한다. 모든 패킷을 내부로 들이는 대신, 규칙에 맞는 것만 통과시킨다. 에이전트에서도 똑같다. 사용자 입력, 검색 결과, 장기 메모리, 도구 출력, 외부 문서가 한 번에 섞여 들어오면 모델은 중요도를 스스로 판정해야 한다. 문제는 그 판정이 항상 일정하지 않다는 점이다. 그래서 "판정 책임"을 모델에 넘기지 말고 시스템 레이어에서 미리 정리해주는 것이 방화벽의 목적이다.
실무에서는 최소 네 단계가 유효하다. 첫째, 출처 분류다. 입력이 사용자 직접 지시인지, 과거 요약인지, 자동 수집 로그인지 태그를 붙인다. 둘째, 신뢰도 스코어링이다. 사람이 검증한 사실과 미검증 추론을 동일 가중치로 넣지 않는다. 셋째, 유효기간 검사다. 가격/정책/일정처럼 시간 민감한 정보는 TTL을 넘기면 자동 폐기한다. 넷째, 민감도 필터다. 현재 작업과 무관한 개인정보나 불필요한 내부 메타데이터를 제거한다.
여기서 중요한 포인트는 "요약"보다 "차단"이다. 많은 팀이 긴 맥락을 짧게 압축하는 데 집중하지만, 애초에 들어오지 말아야 할 맥락이 들어오면 압축은 미봉책이다. 잘못된 재료를 아무리 잘게 다져도 재료 자체는 틀려 있다. 컨텍스트 방화벽은 모델 성능을 높이는 장치이면서 동시에 운영 리스크를 줄이는 장치다. 정확도와 보안이 같은 방향으로 개선되는 드문 구간이기도 하다.
2. 정책 라우팅: 같은 질문이라도 같은 경로로 흘려보내지 않는다
방화벽이 유입을 걸러냈다면, 다음은 라우팅이다. 운영 환경의 요청은 모두 동일하지 않다. "요약해줘"와 "외부에 발송해줘"는 겉보기 문장이 짧아도 위험도가 완전히 다르다. 그런데 많은 자동화 파이프라인은 모든 요청을 한 줄로 처리한다. 동일한 모델, 동일한 프롬프트, 동일한 도구 권한으로 흘려보낸다. 이 구조에서는 쉬운 작업은 과하게 무겁게 처리되고, 위험한 작업은 너무 가볍게 처리된다.
정책 라우팅은 요청을 **의도(intent) + 영향도(impact) + 가역성(reversibility)**으로 분기한다. 예를 들어 내부 문서 초안 생성은 저위험·고가역 작업이므로 빠른 경로로 보낸다. 반면 외부 발송, 비용 집행, 데이터 삭제 같은 작업은 고위험·저가역이므로 승인 게이트를 반드시 거치게 한다. 같은 "자동화"라도 경로를 분리하면 속도와 안전을 함께 얻는다.
라우팅 설계를 할 때 실무적으로 유용한 기준은 세 가지다.
- 실패 시 복구 시간: 실패를 되돌리는 데 1분이 걸리는가, 1주가 걸리는가
- 외부 노출 범위: 내부 로그에 머무는가, 고객/대중에게 바로 노출되는가
- 검증 가능성: 결과를 규칙 기반으로 자동 검증할 수 있는가
이 기준을 메타데이터로 남기면, 시스템은 "지금 어떤 경로를 탔고 왜 그랬는지" 설명 가능해진다. 운영자가 사고 후 리플레이를 할 때도 큰 차이가 난다. 장애는 피할 수 없지만, 장애의 원인을 빠르게 찾고 재발을 막는 구조는 설계할 수 있다.
3. 운영 팁: 프롬프트 엔지니어링보다 앞단 규칙 품질을 먼저 측정하라
에이전트 품질 회의에서 자주 놓치는 지점이 있다. 대부분의 지표가 모델 출력에만 붙어 있다는 점이다. 정답률, 환각률, 토큰 비용 같은 지표는 중요하다. 그러나 그 지표가 흔들릴 때 원인이 출력 단계인지 입력 단계인지 분리하지 않으면 팀은 늘 같은 자리에서 맴돈다. 오늘은 프롬프트를 바꾸고, 내일은 샘플을 늘리고, 모레는 모델을 교체한다. 그런데 다음 주면 같은 문제가 돌아온다.
그래서 앞단 규칙 품질을 별도 지표로 측정해야 한다. 예를 들면 아래 항목이다.
- 차단 적중률: 실제로 제외해야 할 맥락을 방화벽이 얼마나 잘 막았는가
- 라우팅 정확도: 위험도 높은 요청이 저위험 경로로 잘못 들어간 비율은 얼마인가
- 정책 충돌률: 서로 다른 규칙이 같은 요청에서 상충하는 빈도는 얼마나 되는가
- 재판정 빈도: 사람이 후속으로 경로를 바꿔야 했던 케이스가 얼마나 되는가
이 지표를 한 달만 쌓아도 패턴이 보인다. 특정 카테고리 요청에서만 충돌률이 높다거나, 특정 시간대 입력에서 유효기간 초과 데이터가 과다 유입된다거나, 특정 도구 출력 형식 때문에 라우팅 오분류가 반복된다거나 하는 신호가 잡힌다. 이 신호를 기반으로 규칙을 고치면 모델을 건드리지 않아도 체감 품질이 크게 오른다.
또 한 가지. 방화벽과 라우팅은 "보수적일수록 좋다"가 아니다. 지나치게 엄격하면 필요한 맥락까지 막아 창의성과 생산성이 떨어질 수 있다. 결국 목표는 금지의 극대화가 아니라 정밀한 선택이다. 중요한 맥락은 빠르게 통과시키고, 불필요하거나 위험한 맥락만 정확히 차단하는 것. 이 균형을 만드는 팀이 장기전에서 강하다.
마지막으로 기억해야 할 점이 있다. 에이전트 아키텍처에서 "맥락"은 연료이면서 동시에 공격면이다. 연료를 무작정 늘리면 엔진이 좋아지는 게 아니라 과열될 수 있다. 그래서 좋은 시스템은 먼저 관문을 세우고, 그다음 연료를 넣는다. 프롬프트를 더 길게 쓰는 기술은 누구나 금방 따라 한다. 하지만 맥락의 출입을 설계하는 기술은 운영 팀의 내공이 쌓여야만 나온다.
결국 차이는 여기서 난다. 많이 넣는 팀이 아니라, 무엇을 넣지 않을지 결정할 수 있는 팀. 에이전트 시대의 경쟁력은 모델 선택표보다 입력 정책표에서 먼저 드러난다.
