Don’t Let the LLM Drive - Ornella Bahidika & Joel Allou, Microsoft
📺 원본 영상: Don’t Let the LLM Drive - Ornella Bahidika & Joel Allou, Microsoft
🎙️ 채널: AI Engineer
📅 정리 일자: 2026-07-20
⚠️ Note: 본 리포트는 영상의 음성을 텍스트로 변환(STT)하여 정리한 것입니다. 화면에 표시된 자료(차트, 코드, 슬라이드 등)는 포함되지 않을 수 있습니다.
개요
이 발표의 핵심 메시지는 명확하다. LLM 기반 멀티스텝 에이전트를 안정적으로 운영하려면, 모델에게 전체 흐름의 운전대를 맡겨서는 안 된다. Microsoft의 Ornella Bahidika와 Joel Allou는 실시간 AI 음성 튜터인 ACE를 만들면서, 신뢰성 문제의 본질이 프롬프트 품질이 아니라 제어 구조에 있다는 점을 강조한다.
강연자들은 LLM을 “재능 있는 배우”에 비유하고, 하네스(harness)를 “감독”에 비유한다. 모델은 특정 순간에 자연스럽게 말하고, 답변하고, 판단을 제안하는 데 뛰어나지만, 지금이 6단계 중 3단계인지 기억하고 전체 수업 흐름을 책임지는 데는 적합하지 않다. 따라서 ACE는 모델이 스스로 수업을 끌고 가도록 두지 않고, 상태 머신과 하네스가 단계별 계약을 제공하고 결과를 검증하는 구조로 설계되었다.
프롬프트 문제가 아니라 제어 문제다
발표는 많은 AI 에이전트 개발자가 이미 겪었을 법한 장면에서 출발한다. 데모에서는 완벽하게 보였던 멀티스텝 에이전트가 실제 사용자 앞에서는 중간 단계를 건너뛰거나, 엉뚱한 방향으로 흐르거나, 같은 행동을 반복하는 문제가 발생한다. 이런 상황에서 개발자가 가장 먼저 시도하는 처방은 보통 프롬프트를 더 길고 정교하게 만드는 것이다. 더 많은 지시문을 넣고, 예외 조건을 추가하고, 모델이 실수하지 않도록 더 촘촘한 문장을 작성하려고 한다.
그러나 강연자들은 이 접근이 문제의 핵심을 비켜간다고 본다. ACE를 구축하며 얻은 결론은, 신뢰성은 프롬프트 엔지니어링(prompt engineering)의 문제가 아니라 제어 흐름(control flow)의 문제라는 것이다. 모델은 특정 입력에 대해 유창한 응답을 생성하는 데 강하지만, 장기적인 절차 상태를 안정적으로 보존하고 다음 단계를 결정하는 시스템 컴포넌트로 쓰기에는 불안정하다. 이 때문에 모델에게 “수업 전체를 알아서 진행하라”고 시키는 순간, 시스템은 모델의 추론 능력뿐 아니라 모델의 일관성, 기억, 절차 준수 능력까지 모두 믿어야 하는 구조가 된다.
강연자들은 이를 “모델은 재능이고, 하네스는 감독”이라는 비유로 설명한다. 배우가 한 장면의 대사를 훌륭하게 전달할 수 있다고 해서, 영화 전체의 촬영 순서와 편집 구조까지 맡길 수는 없다. 마찬가지로 LLM은 특정 작업을 수행하는 재능 있는 실행자일 수 있지만, 수업의 현재 위치와 다음 전환을 책임지는 오케스트레이터가 되어서는 안 된다. 이 구분이 ACE 설계의 출발점이다.
ACE의 핵심 구조는 작은 상태 머신이다
ACE의 수업은 하나의 거대한 자유형 대화가 아니라, 작은 상태 머신(state machine)으로 구성된다. 강연자는 수업의 흐름을 intro, teach, check, grade, advance, wrap 같은 단계로 나누어 설명한다. 이 구조에서 각 단계는 모델에게 새로운 “계약(contract)”을 보낸다. 계약의 의미는 단순하다. 지금 이 단계에서 해야 할 한 가지 일을 수행하고, 정해진 형태의 결과를 반환하라는 것이다.
01:01 - ACE 수업을 intro, teach, check, grade, advance, wrap 단계로 나누는 상태 머신 구조
이 설계에서 중요한 점은 모델이 “우리가 지금 어디에 있는지” 결정하지 않는다는 데 있다. 현재 상태를 알고 있는 것은 하네스이며, 모델은 그 상태 안에서 제한된 작업만 수행한다. 모델이 결과를 반환하면 하네스는 그 결과를 검증하고, 상태를 전진시키며, 다음에 어떤 단계로 갈지 결정한다. 따라서 모델은 제안할 수 있지만, 최종 결정권은 하네스에 남아 있다.
이 방식은 특히 라이브 음성 튜터처럼 지연 시간과 신뢰성이 동시에 중요한 서비스에서 큰 의미를 가진다. 사용자는 대화가 자연스럽게 이어지기를 기대하지만, 교육 시스템은 단순히 자연스럽게 말하는 것만으로는 충분하지 않다. 학생이 실제로 개념을 이해했는지 확인해야 하고, 오답이 나왔을 때 적절한 피드백을 줘야 하며, 수업이 끝났는지 아니면 다음 설명으로 넘어가야 하는지 판단해야 한다. 이러한 절차적 책임을 모델 내부의 암묵적 추론에 맡기면, 시스템은 매번 모델이 같은 방식으로 판단해주기를 기대해야 한다. ACE는 그 기대를 줄이고, 명시적인 상태 전이로 수업을 관리한다.
하네스 엔지니어링은 모델을 덜 똑똑하게 쓰는 기술이 아니다
Joel Allou는 오늘날의 프런티어 모델을 사용할 때 많은 개발자가 모델에게 사고, 처리, 실행 사이의 모든 역할을 맡기는 경향이 있다고 설명한다. 강연자가 예로 든 모델명은 문맥상 Anthropic의 Claude Opus 계열 모델을 가리킨다. 요점은 특정 모델명이 아니라, 매우 강력한 대형 모델을 사용하더라도 모든 제어를 모델에게 위임하는 방식이 언제나 효과적인 것은 아니라는 데 있다.
ACE는 학생과 실시간으로 말하고 듣는 AI 튜터이기 때문에 세 가지 요구사항을 동시에 만족해야 했다. 응답은 안정적이어야 하고, 비용은 감당 가능해야 하며, 지연 시간은 짧아야 한다. 대형 모델 하나에 전체 수업 흐름을 맡기면 구현은 단순해 보일 수 있지만, 비용과 속도, 예측 가능성 측면에서 부담이 커진다. 그래서 강연자들은 모델 바깥에 필요한 단계와 제어 구조를 만들고, 모델에게는 각 시나리오 수행에 필요한 최소 입력만 제공하는 방식을 택했다.
02:43 - 각 단계에서 모델에게 구체적 입력을 제공해 특정 액션 안에 제한하는 하네스 엔지니어링 개념
이 접근은 모델을 “덜 똑똑하게” 쓰는 것이 아니라, 모델이 잘하는 일에 집중하도록 환경을 설계하는 것이다. 하네스가 상태와 전이를 관리하면, 모델은 현재 단계의 제한된 과업만 수행하면 된다. 그 결과 ACE는 더 무거운 프런티어 모델에만 의존하지 않고, 상대적으로 작은 Haiku 계열 모델로도 기대 수준의 동작을 달성할 수 있었다고 강연자들은 말한다. 하네스가 모델 주변에 충분한 구조를 제공했기 때문에, 모델 자체의 추론 능력 부족을 시스템 설계가 보완한 것이다.
로그가 보여주는 실제 하네스의 역할
강연 중간에는 ACE의 특정 수업 녹화와 로그가 소개된다. 강연자는 화면 오른쪽에 다양한 하네스 로그가 나타난다고 설명하며, 이 로그들이 모델에게 어떤 입력이 제공되고 어떤 액션이 제한되는지를 보여준다고 말한다. 음성으로 확인되는 범위에서, 로그에는 수업 섹션을 위한 하네스, 화이트보드에 그리는 동작을 위한 하네스, 큐(queue)를 비우는 절차, 수업 종료 단계와 관련된 제어 흐름 등이 포함된다.
03:30 - ACE 수업 녹화 화면 오른쪽의 로그를 보며 여러 하네스가 작동하는 모습
03:45 - 화이트보드 그리기, 큐 정리, 수업 종료 등 개별 동작을 위한 하네스 로그
💡 [영상 참조] 강연자는 이 구간에서 화면 오른쪽의 로그를 보며 ACE 내부에서 여러 하네스가 작동하는 모습을 설명합니다. 상세한 로그 내용은 원본 영상을 확인하세요.
이 대목에서 중요한 것은 하네스가 단순한 wrapper나 후처리 코드가 아니라는 점이다. 하네스는 모델이 말할 내용, 수행할 액션, 다음 단계로 넘어갈 조건을 명시적으로 제한한다. 새로운 시나리오가 발견되면 그것을 상태 머신과 수업 구조 안에 통합하고, 모델이 임의로 흐름을 해석하지 않도록 제어한다. 즉, ACE의 안정성은 모델이 항상 완벽하게 판단하기 때문이 아니라, 모델이 판단해야 할 범위를 시스템이 지속적으로 줄였기 때문에 나온다.
강연자들은 특히 세 가지 질문을 하네스 바깥의 중요한 제어 기준으로 제시한다. 수업이 끝났는가, 학생이 실제로 맞게 이해했는가, 그리고 다음에는 무엇을 해야 하는가가 그것이다. 이 질문들은 교육 경험의 핵심이지만, 동시에 모델이 매번 자유롭게 판단하도록 두기에는 위험한 지점이다. 그래서 ACE에서는 이 범주의 질문과 관련된 다양한 액션을 모델 외부에서 엔지니어링하고, 모델에는 해당 순간의 입력과 기대 출력만 전달한다.
04:35 - 수업 완료 여부, 학생의 이해 여부, 다음 단계 결정을 모델 외부에서 제어해야 한다는 설명
“말하게 하되, 운전하게 하지는 말라”
발표의 제목인 “Don’t Let the LLM Drive”는 단순한 경고가 아니라, 에이전트 아키텍처에 대한 설계 원칙이다. 강연자들은 모델을 침묵시키라는 뜻이 아니라고 말한다. 오히려 모델은 말해야 한다. 학생에게 설명하고, 질문에 반응하고, 자연스러운 대화를 만들어내는 역할은 모델이 가장 잘 수행하는 영역이다. 다만 모델이 전체 워크플로를 운전하게 해서는 안 된다.
이 원칙은 ACE 같은 음성 튜터에만 적용되는 것이 아니다. 강연자는 같은 방식이 코딩 에이전트, 애플리케이션, runbook, onboarding flow에도 적용될 수 있다고 설명한다. 사용자가 어떤 절차를 따라야 하고, 시스템이 여러 단계의 작업을 안정적으로 수행해야 하며, 실패 시 복구 가능한 경로가 필요하다면, 그 시스템은 모델 중심의 자유형 대화보다 하네스 중심의 제어 구조가 더 적합하다.
판단 기준도 비교적 단순하다. 에이전트의 신뢰성이 동전 던지기처럼 느껴진다면, 제어 흐름을 모델 밖으로 꺼내야 한다. 모델이 많은 결정을 내릴수록 시스템의 행동은 모델의 순간적 해석에 더 크게 의존하게 된다. 반대로 결정 구조를 모델 주변에 만들고, 모델에게 쉬운 입력과 제한된 작업을 제공하면, 시스템은 더 빠르고 저렴하며 예측 가능해진다. 결국 좋은 AI 에이전트 설계란 모델의 능력을 극대화하는 일이면서 동시에 모델이 책임질 필요가 없는 일을 덜어내는 일이다.
05:37 - 에이전트 신뢰성이 불안정할 때 제어 흐름을 모델 밖으로 꺼내야 한다는 설계 원칙
개발자에게 주는 실전적 함의
이 발표가 실무적으로 중요한 이유는, 많은 팀이 LLM 에이전트의 실패를 여전히 “프롬프트가 충분히 좋지 않아서”라고 해석하기 때문이다. 물론 프롬프트 품질은 중요하지만, 멀티스텝 시스템에서 반복적으로 발생하는 이탈, 루프, 단계 누락은 프롬프트만으로 해결하기 어렵다. 이런 문제는 대개 시스템이 명시적인 상태와 전이를 갖고 있지 않거나, 모델의 자연어 응답을 사실상 제어 흐름으로 사용하고 있기 때문에 발생한다.
하네스 엔지니어링은 이 지점을 정면으로 다룬다. 개발자는 먼저 에이전트가 수행해야 하는 전체 과정을 단계로 나누고, 각 단계에서 모델이 받아야 할 입력과 반환해야 할 출력을 정의해야 한다. 그런 다음 하네스가 결과를 검증하고, 실패 또는 예외 상황을 처리하며, 다음 상태를 결정하도록 해야 한다. 이때 모델은 범용 추론 엔진이라기보다, 명확히 제한된 액션을 수행하는 컴포넌트가 된다.
이 접근은 비용 구조에도 영향을 준다. 모든 상황에서 가장 강력한 모델을 호출하는 대신, 상태 머신과 하네스가 충분한 맥락과 제약을 제공하면 더 작은 모델도 안정적으로 사용할 수 있다. ACE 사례에서 강연자들이 강조한 “saving money, saving time, and saving latency”는 단순한 최적화 문구가 아니다. LLM 제품이 실제 사용자와 실시간으로 상호작용하려면, 품질뿐 아니라 운영 비용과 지연 시간까지 설계의 중심에 놓아야 한다는 뜻이다.
참고할 만한 개념들
이 발표를 더 깊게 이해하려면 상태 머신(state machine), 오케스트레이션(orchestration), 검증 가능한 출력 구조(structured output), 그리고 가드레일(guardrails)을 함께 생각할 필요가 있다. 상태 머신은 시스템이 현재 어떤 상태에 있고, 어떤 이벤트가 발생했을 때 어느 상태로 이동할 수 있는지를 명시적으로 표현한다. LLM 에이전트에 이 개념을 적용하면, 모델의 응답은 상태 전이의 원인이 될 수는 있지만 상태 전이를 최종 결정하는 주체가 되지는 않는다.
또한 하네스는 단순히 모델 호출 앞뒤에 붙는 코드가 아니라, 모델의 역할과 책임을 재정의하는 아키텍처 계층으로 볼 수 있다. 모델에게 “무엇이든 알아서 해줘”라고 요청하는 대신, “이 상태에서 이 입력을 바탕으로 이 형식의 결과를 반환해줘”라고 요청하는 방식이다. 이 차이는 작아 보이지만, 제품의 신뢰성에서는 결정적이다. 특히 교육, 의료, 금융, 개발 자동화처럼 단계 누락이나 잘못된 판단의 비용이 큰 영역에서는 모델의 자유도를 줄이는 설계가 오히려 더 강력한 사용자 경험으로 이어진다.
다만 이 참고 설명은 강연 내용을 바탕으로 한 기술적 보완이며, 발표자가 화면에서 보여준 실제 코드나 내부 구현을 직접 재구성한 것은 아니다. 원본 영상에는 로그와 시각 자료가 포함되어 있으므로, 구체적인 구현 형태는 영상을 함께 확인하는 것이 좋다.
마무리 / 핵심 정리
Ornella Bahidika와 Joel Allou의 발표는 LLM 에이전트 설계에서 가장 흔한 오해를 바로잡는다. 더 강한 모델과 더 긴 프롬프트가 항상 더 신뢰할 수 있는 제품을 만드는 것은 아니다. 특히 수업, 업무 절차, 코딩 작업, 온보딩처럼 단계와 상태가 중요한 시스템에서는 모델이 전체 흐름을 운전하게 하는 순간 실패 가능성이 커진다.
ACE의 사례는 반대 방향의 해법을 보여준다. 수업을 작은 상태 머신으로 나누고, 각 단계마다 모델에게 제한된 계약을 제공하며, 하네스가 결과를 검증하고 다음 상태를 결정하게 만든다. 이렇게 하면 모델은 자신이 잘하는 자연어 생성과 특정 작업 수행에 집중할 수 있고, 시스템은 더 낮은 비용과 지연 시간으로도 안정성을 확보할 수 있다.
결국 발표의 결론은 간결하다. LLM은 말하게 해야 하지만, 운전하게 해서는 안 된다. 에이전트의 신뢰성이 불안정하게 느껴진다면, 더 강한 프롬프트를 쓰기 전에 먼저 제어 흐름이 어디에 있는지 살펴봐야 한다. 그 제어가 모델 내부에 숨어 있다면, 그것을 하네스와 상태 머신이라는 명시적인 시스템 구조로 끌어내는 것이 더 실전적인 해법이다.
📚 출처 및 참고
| 구분 | 내용 |
|---|---|
| 원본 영상 | Don’t Let the LLM Drive - Ornella Bahidika & Joel Allou, Microsoft |
| 채널 | AI Engineer |
| 영상 길이 | 약 6분 6초 |
| 리포트 작성 | 2026-07-20 |
| 작성 방식 | YouTube 영상 STT 변환 후 에디팅 |
💬 본 리포트는 영상 내용을 바탕으로 재구성되었습니다. 정확한 내용은 원본 영상을 참조해 주세요.