Agents Are Where Microservices Were in 2015 — Roberto Milev & Uday Kanagala, Navan

한 줄 핵심

에이전트는 마이크로서비스 초기처럼 표준 아키텍처가 막 굳어지는 단계이며, 실전에서는 runtime·memory·context·관측·평가·권한을 따로 설계해야 안정적으로 운영할 수 있다.

시간별 요약

1. 0:00
   마이크로서비스 열풍과 그 교훈 마이크로서비스 확산 과정에서 컨테이너 오케스트레이션과 Kubernetes 같은 기반 기술은 시간이 지나며 정리됐고, 에이전트도 비슷하게 유행을 따라가기보다 먼저 단일 구조를 제대로 만드는 학습이 필요하다. 잘 구조화된 모놀리스를 만들지 못하면 무작정 마이크로서비스나 멀티 에이전트를 시도하는 것은 위험하다.
2. 1:25
   정립되기 시작한 기준 아키텍처 실서비스 운영을 거치며 에이전트용 참조 아키텍처가 runtime, memory, context management, orchestration 같은 계층으로 나뉘어 정리되고 있다. 업계도 이제 단순 실험이 아니라 대규모 토큰 사용과 생산 환경 신뢰성을 전제로 설계 방향을 수렴하는 중이다.
3. 2:34
   Runtime와 상태를 가지는 에이전트 에이전트는 본질적으로 상태를 가지므로, 기존의 무상태 API 서비스와 달리 세션 지속성, 격리, 수명주기 관리가 필요하다. AWS, GCP, Azure가 각자 agentic runtime을 내놓고 있으며, 실제 운영에서는 세션 persistence와 rehydration 같은 빈틈을 별도로 메워야 한다.
4. 3:42
   RAG에서 에피소드 기억으로 기억은 단순 RAG를 넘어서, 수집·추출·통합·검색 흐름으로 자동 생성되는 장기 기억과 짧은 대화 기억, 그리고 잘 됐던/안 됐던 사례를 담는 episodic memory로 확장되고 있다. 동시에 컨텍스트는 너무 많아도 문제이므로, 도메인별 instructions와 tool execution을 묶은 단위로 관리하는 방향이 효과적이다.
5. 6:04
   컨텍스트의 단위로서의 스킬 스킬을 재사용 가능하고 독립적으로 테스트할 수 있는 컨텍스트 단위로 보면, 필요한 기능만 동적으로 조합해 에이전트에 주입할 수 있다. progressive disclosure를 활용하면 처음에는 좁은 범위로 시작하고 메타데이터를 점진적으로 펼쳐가며 과도한 컨텍스트 유입을 줄일 수 있다.
6. 7:16
   왜 로그는 에이전트에서 작동하지 않는가 에이전트는 생각과 중간 판단을 많이 남기기 때문에 기존 마이크로서비스식 로그 탐색만으로는 실패 원인을 빠르게 파악하기 어렵다. 대신 pre-tool, post-tool, pre-decision, post-decision 같은 지점에서 훅을 걸어 traces와 metrics를 남겨야 운영이 가능하다.
7. 8:24
   훅, 트레이스, 신뢰도 점수 트레이스에는 현재 목표, 판단 근거, belief status, tool calls 같은 신호를 담아야 나중에 판단 흐름을 복원할 수 있다. 결과에 confidence score를 붙이면 추론 답변과 확정 답변을 구분해 사람이 개입해야 할 지점을 더 잘 찾을 수 있다.
8. 9:32
   비결정적인 것을 테스트하기 에이전트는 매번 다른 경로를 선택하는 비결정적 시스템이어서, 전통적인 결정론적 테스트 방식으로는 신뢰성을 담보하기 어렵다. 변경 하나가 다른 부분을 깨뜨리는 상황에서는 정답 비교보다 실행 경로와 실패 양상을 다루는 평가 방식이 필요하다.
9. 10:44
   출력 대신 궤적을 점수화하기 에이전트 평가는 최종 출력만 보지 말고 목표까지의 trajectory가 얼마나 효율적이고 완결적인지를 봐야 한다. inferred answer 신호와 결합하면 회귀를 분류하고 수정 지점을 찾는 데 더 유용한 평가 체계를 만들 수 있다.
10. 13:04
    누가 실제로 항공권을 구매했는가 에이전트가 사용자를 대신해 결정을 내리는 순간, 행위 주체가 사용자인지 에이전트인지 경계가 흐려지므로 세밀한 authorization 정책이 필요하다. tool call 전후에 guardrails를 두어 민감한 정보 유입과 권한 오남용을 막아야 한다.
11. 14:15
    마스터 에이전트 하나인가, 여러 개인가 Navan은 단일 master agent에 sub-skills를 붙이는 방식을 택했으며, 필요할 때만 스킬을 로딩해 컨텍스트를 제어한다. 동시에 대규모 조직처럼 경계가 분리된 영역에서는 A2A protocol 같은 agent-to-agent 통신 패턴도 유효한 대안으로 떠오르고 있다.
12. 15:29
    무엇이 해결됐고 무엇이 남았는가 runtime, memory, MCP와 tool calling은 상당히 성숙해졌지만, observability와 testing, orchestration은 아직 완전히 정리되지 않았다. 특히 과도한 설계를 피하면서도 품질과 신뢰성을 확보하는 균형이 현재의 핵심 과제로 남아 있다.
13. 17:48
    비용, 재생, 그리고 떠오르는 표준 실서비스 에이전트에서는 비용 예측과 통제가 어렵기 때문에 fallback이나 저렴한 모델 활용 같은 방어 전략이 필요하다. replay와 debugging도 큰 과제이지만, 커뮤니티 중심의 표준과 OTEL, A2A 같은 흐름이 점차 운영 가능성을 높이고 있다.

실무 인사이트

• 에이전트를 도입할 때는 멀티 에이전트부터 시작하기보다 단일 루프를 먼저 안정화하고, 그 위에 memory·context·권한·관측을 계층적으로 얹는 편이 실패 비용이 적다.
• 운영 중 디버깅을 고려해 logs 중심 사고를 버리고, 훅 기반 traces와 confidence score를 표준 관측 단위로 설계해야 한다.
• 평가 체계는 최종 답만 비교하지 말고 trajectory와 실패 유형을 함께 점수화해야 비결정적 에이전트의 회귀를 실용적으로 잡아낼 수 있다.