스크립트
00:00:00안녕하세요 여러분. 저희 발표에 오신 것을 환영합니다. 제 이름은 로베르토 밀레브이고, 저는
00:00:20나반의 수석 아키텍트입니다. 그리고 아키텍처 팀의 일원인 우데도 함께 참석해 있습니다. 나반은 여행 및
00:00:27경비 관리 회사이며, 저희가 AI를 어떻게 운영하고 있으며
00:00:32어떤 점들을 발견했는지 그 배움의 일부를 공유해 드리려고 합니다. 이 업계에 오래 계셨던 분들이라면
00:00:41시간이 흐름에 따라 몇 차례의 패러다임 전환이 있었고, 우리 모두 유행에 편승해
00:00:46어떻게든 올바르게 일하려고 노력해 왔다는 것을 기억하실 것입니다. 지난번에는
00:00:53우리 모두 마이크로서비스 유행에 편승했었고, 그 과정에서
00:00:58컨테이너 오케스트레이션, 쿠버네티스 같은 많은 좋은 것들이 나왔고, 그 후에는
00:01:05서비스 메시, 서킷 브레이커 등 유용한 기술들이 등장했습니다. 하지만 그것이 하루아침에
00:01:11일어난 것은 아닙니다. 오랜 시간이 걸렸죠. 이러한 것들을 다루는 법을 배우는 데 일정 시간이 소요되었습니다.
00:01:16그래서 그 당시의 명언 중 하나가, 잘 구조화된 모놀리스를
00:01:21구축할 수 있다면 애초에 왜 마이크로서비스를 구축하려고 하느냐는 것입니다. 이는 오늘날에도
00:01:26비슷하게 적용됩니다. 단일 에이전트 루프조차 제대로 구축할 수 없다면, 왜 굳이 들어가서
00:01:32멀티 에이전트 오케스트레이션 시스템을 구축하려고 하겠습니까? 따라서 시간이 흐르면서 이전과 마찬가지로 참조
00:01:41아키텍처가 부상하고 있습니다. 저희는 프로덕션 환경에서 직접 운영해 보며 몇 가지 사실을 배웠습니다. 저희는 수많은
00:01:50에이전트를 보유하고 있고, 하루에 수많은 토큰이 사용되고 있습니다. 앞서 말씀드렸듯이 몇 가지 계층들이
00:01:58표준화되었으며, 프로덕션 환경에서 에이전틱 플로우를 안정적으로 실행하기 위해
00:02:04무엇이 필요한지 주변으로 구체화되었습니다. 런타임 메모리, 컨텍스트 관리, 그리고 운영상의
00:02:12다양한 공통 관심사들과 오케스트레이션 관련 사항들까지 말입니다. 그래서 오늘 저희는 이러한 계층들 중 일부,
00:02:18실제로 이 모든 계층들을 살펴볼 것입니다. 그리고 업계의 현황, 저희가 해온 일, 배운 교훈 등을 보여드리겠습니다.
00:02:27먼저 런타임 계층부터 시작하겠습니다. 그동안 우리는 서비스를 무상태(stateless)로
00:02:34확장하기 위해 많은 이야기를 나누고 수많은 서비스를 구축해 왔습니다. 그리고 이제 우리는 에이전트가
00:02:43본질적으로 상태 유지(stateful)인 새로운 세상에 와 있습니다. 에이전트는 지속적인 세션이 필요합니다. 격리 기능도 필요합니다.
00:02:51그들의 수명 주기는 전통적인 API 서비스의 수명 주기와는 다릅니다. 따라서 클라우드
00:02:59제공업체들이 뛰어들어 이 공백을 메우려 노력해 왔습니다. AWS, GCP, 애저 모두 에이전틱 런타임의
00:03:10어떤 형태든 갖추고 있습니다. 이 슬라이드와 다음 슬라이드의 QR 코드를 스캔하시면,
00:03:16일부 기능들의 비교와 다양한 클라우드 제공업체들이 이에 접근하는 방식을 확인하실 수 있습니다.
00:03:25나반에서는 모든 것을 AWS 위에서 실행하고 있습니다. AWS에는 에이전트 코어 런타임이 있습니다. 저희는 이를 적극적으로 활용하고 있지만,
00:03:33세션 지속성 및 재수화(rehydration) 같은 부분에서는 저희가 직접 구축하여 공백을 메웠습니다. 또한
00:03:41에이전트 작성을 위한 여러 다른 SDK들도 함께 실행하고 있습니다. 이러한 런타임의 일부는 일반적으로
00:03:50프레임워크 중립적이지만, 비록 각자 자사의 기본 프레임워크를 선호하는 경향이 있기는 합니다.
00:03:58스택의 다음 계층은 메모리입니다.
00:04:04우리는 RAG로 시작했습니다. RAG는 한동안 큰 화두였습니다. 우리는 에이전트에
00:04:11무제한의 컨텍스트를 담을 수 없기 때문에 어쩔 수 없이 RAG로 이끌렸습니다. 그리고 시간이 지나면서,
00:04:20이 모든 클라우드 제공업체들과 업계는 메모리가 일종의
00:04:27수집, 추출, 그리고 통합 및 검색이라는 워크플로를 거쳐 자동으로 생성되는 파이프라인을 구현해 왔습니다.
00:04:33그리고 본질적으로 약간의 시맨틱 특성을 가진 장기 기억 같은 기능 내에 RAG의 일부가 내장되어 있습니다.
00:04:40하지만 메모리는 단기 대화형 메모리에서부터 직접 관리하는 장기 기억까지 시간에 따라 구축됩니다. 그런 다음
00:04:46잘 작동했던 인스턴스들과 잘 작동하지 않았던 인스턴스들에 대한 에피소드 기억 등이 있습니다. 저희 나반 역시 AWS를
00:04:54사용하는 기업으로서, 그들의 에이전트 코어 메모리를 활용하고 있습니다. 하지만 저희의
00:05:02유스케이스에 부합하는 방식으로도 이를 구현하고 있습니다.
00:05:09다음은 컨텍스트 관리입니다. 이는 뜨거운 주제였습니다. 과거에도 뜨거운 주제였고 지금도 여전히 뜨거운 주제입니다. 컨텍스트 윈도우는 점점 커지고 있지만, 컨텍스트는 결코
00:05:18충분하지 않습니다. 혹은 컨텍스트가 너무 많으면 이 역시 에이전트가 초점을 잃게 만들기 때문에
00:05:23에이전트들이 어려움을 겪습니다.
00:05:29효과가 있다고 확인된 방법은 스킬을 컨텍스트의 단위로 초점을 맞추는 것입니다. 제가 무슨 뜻인지 설명해 드리겠습니다.
00:05:39우리는 스킬이 특정 도메인이나 작업에 대한 지침과 설정이라는 의미의 컨텍스트를 둘 다 가지고 있다고 봅니다.
00:05:48그리고 스킬의 두 번째 부분인 도구 실행과 에이전틱한 부분이 있습니다. 우리는
00:05:54플러그인 가능하고, 독립적으로 테스트할 수 있으며, 재사용할 수 있는 작업 단위로 사용하는 스킬들로부터 컨텍스트를 동적으로 구성합니다.
00:06:06예를 들어, 에이전트가 있을 때 우리는 도메인에 특화된 스킬들을 가지고 있습니다. 그리고 그것을 바탕으로 구성합니다. 우리는
00:06:15제한된 범위의 컨텍스트로 시작하여 나중에 포함된 메타데이터를 통해
00:06:24확장하는, 스킬 자체의 기능인 점진적 공개(progressive disclosure)에 의존합니다.
00:06:32이제 우데에게 넘겨서 나머지 내용을 설명해 주도록 하겠습니다. 우데, 고마워요. 알겠습니다. 여기서 손을 한번 가볍게 들어주시겠습니까? 20단계나 30단계에 달하는 멀티
00:06:42스텝 프로세스의 중간에 실패했으며, 에이전트가 왜 실패했는지 빠르게 파악하거나
00:06:52추론할 수 있었던 에이전트를 만들어 보신 분이 계신가요?
00:07:00에이전트가 실패한 이유 말입니다.
00:07:05로그에 대해서 말하자면, 우리는 전통적으로 마이크로서비스를 다룰 때 로그에 익숙해져 있습니다.
00:07:11거기에 로그가 있고, 우리는 로그를 확인하러 갑니다. 하지만 우리가 에이전트로 전환하는 순간 이 모든 것이 바뀝니다.
00:07:16에이전트는 엄청난 양의 사고 과정을 출력합니다. 소비하기에는 너무 양이 많습니다. 따라서 그것은 올바른
00:07:22방법이 아닙니다. 전통적으로는 그것이 방법이었지만, 이제는 우리의 생각이 바뀌어야 합니다.
00:07:28클로드를 예로 들어보겠습니다. 에이전트로서 클로드를 예로 들면, 훅(hooks)이 존재하여
00:07:35에이전트로서 클로드가 그 수준에서 수행하는 모든 것을 가로챌 수 있습니다. 어떤 도구를 호출하는지,
00:07:42어떤 결정을 내리는지 말입니다. 도구 호출 전후(pre-tool, post-tool)나 세션 전후 시점처럼 말이죠. 따라서 이 모든 것들은
00:07:49우리가 개입하여 결정을 내리고 차단 작업을 수행하거나
00:07:56메트릭을 로깅하거나 방출할 수 있는 시점입니다. 이것은 매우 중요한
00:08:04위치이며, 여기서 OpenTelemetry(otel) 트레이스를 내보낼 수 있습니다. 나반에서는 제공업체 중 하나인 브레인러스트를 사용하여 이러한 otel 트레이스를 내보냅니다.
00:08:11그리고 이 트레이스를 통해 스팬(spans)과 트레이스를 파악할 수 있으며, 에이전트가 어느
00:08:17시점에 멈춰 있는지 알 수 있어, 에이전트를 운영하고 구축하는 방법에 훨씬 더 큰 확신을 줍니다.
00:08:25이것이 바로 2일 차(Day 2) 운영상의 과제입니다. 요즘 에이전트를 구축하는 프레임워크는 정말 많지만,
00:08:32나중에 에이전트를 구축하고 운영하는 방식을 어떻게 탐색할 것인가가 주된 관심사가 되었습니다.
00:08:39게다가 여기서 추론 체인, 사고 과정, 그리고 우리가 내보내는 중요한 신호들이 있습니다. 트레이스 캡처의
00:08:45일환으로, 우리는 몇 가지 주요 신호를 내보냅니다. 에이전트가 현재 수행 중인 목표는 무엇인가?
00:08:52그 연산 뒤에 숨겨진 이유와 믿음 상태, 그리고 에이전트가 호출하고 있는 도구들이 무엇인가 하는 것들입니다.
00:08:57이것은 트레이스 내에서 판단 지표를 제공합니다. 그리고 에이전트가 결정을 내릴 때,
00:09:07이 판단을 내릴 때 얼마나 확신하는지를 나타내는 신뢰도 점수가 있습니다. 이 선택으로 이어진
00:09:12경로가 여러 개인지, 혹은 이것이 추론된 답변인지에 따라 말이죠. 기본적으로
00:09:18이러한 신호들은 나중에 검토할 수 있는 신뢰를 줍니다. 이것이 추론된 답변이라면, 인간이 개입하여
00:09:24가이드하고 에이전트가 더 나은 성능을 발휘하도록 유도할 수 있습니다.
00:09:32다시 한번 손을 들어 확인해 볼까요? 에이전트를 이용한 테스트 파이프라인에 대해 얼마나 확신하시나요? 100% 확신하시나요?
00:09:40테스트 파이프라인에 말입니다.
00:09:43맞습니다. 이것이 오늘날의 또 다른 중요한 측면 중 하나입니다.
00:09:51에이전트는 비결정론적이기 때문입니다. 우리 모두는 훨씬 더
00:09:55결정론적인 플로우를 프로그래밍하고 작성하는 데 익숙해져 있습니다. 그리고 그것이 어떻게 작동하는지 알고 있습니다. 엔지니어에게 물어보면, 엔지니어는 알고리즘과
00:10:02연산 시퀀스가 어떻게 되는지 설명해 줄 수 있습니다. 모든 것이 우리의 머릿속에 프로그래밍되어 있고, 모든 것이
00:10:06예상한 대로 흘러갑니다. 하지만 이제 에이전트가 비결정론적인 방식으로 들어왔는데, 어떻게 테스트해야 할까요?
00:10:11바로 그것이 매우 중요한 지점입니다. 네, 저희도 고군분투하고 있습니다. 저희는 에이전트 구축을 시작했고
00:10:19데이터 운영이 도전적이었으며, 많은 단계에서 실패를 겪었습니다. 어떻게 바로잡아야 할까요?
00:10:23무언가를 바꾸는 순간, 다른 무언가가 고장 납니다. 그렇죠?
00:10:29그럼 어떻게 해야 할까요? 저희가 취한 접근법 중 하나는, '궤적(trajectory)' 개념에 관한 연구 논문들에서 착안한 것입니다.
00:10:36다중 단계 오케스트레이션에서 에이전트가 목표에 도달하기 위해 30개의 단계나 결정을 거칠 때,
00:10:44만약 그것이 프로그램이라면 이야기가 다르겠지만, 이것은 프로그램이 아닙니다. 이것은
00:10:51매번 자신만의 단계를 다르게 만들어내는 비결정론적인 방식입니다. 그렇다면 어떻게
00:11:00여기에 결정론적인 그래프를 그려낼 수 있을까요? 가능할까요? 아닙니다. 시작점에서 목표까지의
00:11:09궤적을 가지고, 궤적을 따라 얼마나 멀리 갔는지, 소스에서
00:11:15목적지까지 얼마나 멀리 이동했는지를 보는 방식으로 에이전트 평가의 효율성이나 완성도를
00:11:23산출할 수 있습니다. 그래서 저희는 궤적 평가에 크게 의존하고 있습니다. 그리고 앞서 이전 슬라이드에서
00:11:35간략히 말씀드렸듯이 추론된 신호와 관련된 몇 가지 다른 신호들도 있습니다. 만약 답변이 추론된 답변이라면,
00:11:42어떻게 이를 루프에 통합하여 이것이 회귀(regression)라고 분류하고 에이전트에 대한 수정 사항을
00:11:52만들어낼 수 있을까요? 다음은 가드레일입니다.
00:12:11이거 맞나요? 네. 가드레일과 권한 부여입니다. 이것은 매우 중요하며,
00:12:21엔터프라이즈 AI에서 결정적인 역할을 합니다. 수많은 정보가 모델로 파이프라인화되고 있습니다.
00:12:28우리도 모르게 그 안으로 민감한 정보가 들어갈 수 있습니다. 리더로서 우리들은
00:12:35이를 막기 위해 이러한 거버넌스 계층을 어떻게 마련할 것인가가 여기서 매우 중요합니다. 그리고
00:12:44인증(authentication)과 권한 부여(authorization)의 개념은 여기서 다른 접근 방식을 취하고 있습니다. 전통적으로
00:12:51우리는 사용자나 서비스 계정을 보아왔지만, 이제 에이전트란 무엇입니까? 에이전트는 사용자를 대신해서 행동할 수 있습니다.
00:13:00정말 많은 유스케이스가 존재합니다. 야, 200달러보다 저렴할 때 비행기 표를 예약해줘 같은 것 말이죠. 그래서 우리는 이러한 주장을 전달하고
00:13:06200달러보다 저렴할 때 비행기를 예약해 줘, 이런 식으로요? 그래서 우리는 이런 요청을 하고
00:13:12에이전트가 이를 파악하여 내 대신 이 작업을 수행합니다. 그렇다면 이 구매를 하는 것은 나인가요,
00:13:19아니면 나를 대신해 에이전트가 하는 것인가요? 에이전트는 사용자를 대신해 행동하며, 에이전트 사용자나 서비스 계정이 될 수도 있습니다.
00:13:27따라서 이 경계가 모호해지고 있으며, 우리는 여기서 세밀한 권한 부여 결정을 내려야 합니다.
00:13:32정책 계층, 즉 가드레일과 인증 및 권한 부여가 중요한 역할을 하는 지점이 바로 여기입니다.
00:13:39Navan에서는 모든 툴 호출 전(pre-tool)과 후(post-tool)에 이러한 가드레일을 두어 확인하고 차단하며 정보에 입각한 결정을 내립니다.
00:13:51그리고 단일 에이전트와 멀티 에이전트의 비교는, 다시 말해 단일 에이전트를 구축할 것인지
00:14:00멀티 에이전트를 구축할 것인가에 대한 일종의 오케스트레이션 전쟁이라고 볼 수 있습니다.
00:14:05앞서 Roboto가 간략히 시사했듯이, 단일 에이전트조차 완벽하게 구축하지 못하면서 왜 멀티 에이전트로 넘어가겠습니까?
00:14:14그러니 우리의 실패와 경험으로부터 배우고 그 방향으로 구축해야 합니다. Navan에서는 우리가 취한 접근 방식이
00:14:22단일 마스터를 두고 하위 기술(sub-skills)을 채택하는 것입니다. 내부에 하위 에이전트들이 존재하죠. 즉, 단일 에이전트가
00:14:32기술을 점진적으로 로드하고 컨텍스트에 무엇을 로드해야 할지 명확하게 이해한 다음
00:14:39이 유스케이스를 헤쳐 나갈 수 있습니다. 하지만 이 외에도 새롭게 부상하는 다른 패턴들이 있습니다.
00:14:48여기에는 다양한 유형의 유스케이스가 존재합니다. 그중 하나는
00:14:51에이전트 간 통신입니다. 대규모 조직을 가정해 보면, 경계선을 형성하고 서로 대화하지 않는
00:14:56수많은 팀들이 존재하는데요, 가령
00:15:02우리는 어떻게 소통해야 할까요? 이 양쪽에는 각각 에이전트가 존재하는데요. 어떻게 해야 할까요?
00:15:07기술 측면에서 계약(contracts)을 수립하는 데 도움을 줄 수 있는 A2A 프로토콜이 존재하며,
00:15:14팀 간의 경계 역할을 하는 프로토콜로서 A2A를 활용할 수 있습니다.
00:15:22그렇습니다, 바로 A2A 프로토콜이죠.
00:15:29좋습니다. 스택을 쭉 살펴보았듯이, 스택의 일부 구성 요소는 더욱 성숙한 상태에 있으며
00:15:36우리는 이미 그것들에 대한 좋은 해답을 가지고 있습니다. 앞서 말했듯이 런타임은
00:15:42거의 해결된 것 같습니다. 오케스트레이션 측면에서 매우 발전해 있으며, LLM을 일종의 매우
00:15:50브루트 포스(brute force) 방식으로 실행하고 있습니다. 따라서 확장성은 문제가 되지 않습니다. 메모리 역시 마찬가지입니다. 최첨단 LLM이 발전하고
00:15:59우리의 관행이 개선됨에 따라, 대다수의 유스케이스를 커버할 수 있는 방법을 찾게 될 것이며
00:16:06클라우드 제공업체들 사이에서도 상당한 성숙도가 형성되어 있습니다. MCP가 사실상의(de facto) 프로토콜로 부상했으며 툴 호출은
00:16:15이제 모든 이가 지원하는 기능이 되었습니다. 따라서 이와 관련해 업계의 수렴 현상도 목격하고 있습니다.
00:16:23그리고 표준으로서의 MCP 역시 진화하고 있습니다. 이제 상태 비저스(stateless)해지고 있으며,
00:16:29에이전트를 통해 서비스와 툴을 호출하는 방법을 알게 되는 지점에 이르렀습니다. 어떤 영역에서는 발전이 이루어지고 있지만,
00:16:39여전히 관측 가능성(observability)에 대해서는 미지의 부분이 많습니다. Otel(OpenTelemetry)을 도입하려는 움직임이 있지만,
00:16:45Otel이 에이전틱 호출에 정말로 효과가 있을까요? 네, Uday가 말했듯이 작동하도록 만들 수는 있습니다.
00:16:53또한 테스트 패턴에 대해서도 좀 더 익숙해지고 있습니다. 테스트하기는 매우 어렵지만,
00:17:00에이전틱 시스템의 신뢰할 수 없는 특성에도 불구하고 고객에게 양질의 경험을 제공할 수 있는 방법을 찾아냈습니다.
00:17:07그리고 그것이 좀 더 잘 정의된 상태로 자리 잡아가고 있다고 생각합니다. 오케스트레이션은
00:17:15패턴이 존재하는 또 다른 영역입니다. 더 큰 에이전트나 더 작은 에이전트를 구축할 수 있죠. 앞서 말했듯이
00:17:29아마도 올바른 해답은 과도하게 엔지니어링하지 않는 것일 겁니다. 따라서 우리는 그 과정에서 배우고 있으며 패턴도
00:17:40형성되고 있습니다. 우리 모두가 고군분투하고 있으며, 이전 강연에서도 다루었던 내용은 개발자
00:17:47AI 보조 개발 관점에 관한 것이었지만, 프로덕션 에이전트에서도 이러한 문제들을 겪고 있습니다. 비용을 예측하기가 매우 어렵고,
00:17:54비용을 관리하며 가드레일을 설정하고 이를 해결하는 것이 매우 어렵습니다.
00:18:02신뢰할 수 있는 폴백(fallback)을 마련하거나 특정 작업에 대해 에이전트가 더 저렴한 모델을 사용하도록 하는 방식으로 말이죠.
00:18:12이 모든 것은 대형 AI 공급업체들에 의해 주도되는 측면이 있으며, 그들의 이해관계는 우리 모두가 더 많은
00:18:20토큰을 소비하게 만드는 데 있다고 생각합니다. 리플레이와 디버깅 역시 Ude가 이야기했던 부분입니다. 이것도 매우 큰 문제입니다. 이해하기가 매우 어렵지만,
00:18:28이 역시 해결될 것이라고 생각합니다. 왜냐하면 이제 에이전트가 하는 일을 디버깅하려는 인지적 과부하를 극복하기 위해
00:18:36에이전트 자체를 활용할 수 있기 때문입니다. 그리고 표준입니다. 표준은 커뮤니티에 의해
00:18:46형성되고 있습니다. 앞서 언급했듯 Otel은 그렇다 치고, 에이전트 간 통신은 아직 초기 단계입니다. 특정 공급업체들에 의해
00:18:55추진되고 있지만, 시간이 지나면 결국 자리 잡게 될 것입니다. 이 모든 것을 종합해 볼 때, 우리는 무엇이 필요한지 알고 있으며
00:19:04이를 시도하고 구축하는 것은 우리의 몫입니다. 여러분, 감사합니다.