LLM에게 운전대를 넘기지 마라 — Ornella Bahidika & Joel Allou, Microsoft

1. 핵심 주제 및 배경

Microsoft의 Ornella Bahidika와 Joel Allou가 만든 Ace는 처음부터 끝까지 하나의 레슨을 안정적으로 진행하는 실시간 AI 음성 튜터다. 이 발표의 핵심 메시지는 단순하다: LLM이 진행을 주도하게 두지 마라.

멀티스텝 에이전트를 배포해본 사람이라면 익숙한 장면이 있다. 데모에서는 완벽하게 작동하다가, 실제 사용자가 들어오면 에이전트가 중간에 "다 끝났다"고 판단해버리거나, 단계를 건너뛰거나, 같은 루프를 반복한다. 데모는 절대 이런 모습을 보여주지 않는다.

이 문제에 대한 흔한 첫 반응은 "프롬프트를 더 강하게 쓰자, 구멍을 더 메꾸자"이지만, 발표자들은 이것이 프롬프트 문제가 아니라 제어(control) 문제라고 단언한다.

2. 주요 내용 (단락별 상세)

모델은 배우, 하네스는 감독이다

발표의 핵심 비유: 모델은 대사를 전달하는 데는 뛰어나지만, 지금이 6단계 중 3단계인지 기억하는 데는 형편없다. 그래서 Ace 팀은 모델에게 "지금 어느 단계인지 스스로 판단하라"고 요구하는 것을 그만뒀다.

레슨은 intro → teach → check → grade → advance → wrap으로 이어지는 작은 상태 머신(state machine)으로 설계된다. 각 단계는 모델에게 "이 한 가지만 하고, 결과를 반환하라"는 좁은 계약(neural contract)을 보낸다. 하네스가 돌아온 결과를 검증하고, 상태를 전진시키고, 다음에 무엇을 할지 결정한다. 모델은 절대 "지금 어디에 있는지"를 스스로 결정하지 않는다. 이것이 설계의 핵심이다.

왜 하네스 엔지니어링인가 (Joel의 설명)

오늘날의 프론티어 모델(예: Anthropic의 Claude Opus 4.7)을 쓸 때 흔한 접근은 사고(thinking)와 처리(processing) 전부를 모델에 맡기는 것이다. 이는 그 자체로 나쁘지 않지만, 학생과 실시간으로 음성을 주고받는 라이브 AI 튜터 같은 상황에서는 효과적이지 않다. Ace 팀에게는 신뢰성, 비용 효율성, 속도라는 세 가지 요구사항이 있었고, 이것이 "하네스 엔지니어링(harness engineering)" 개념으로 이어졌다.

접근 방식은 이렇다: 매우 똑똑한 모델이 모든 걸 알아서 처리하게 두는 대신, 필요한 모든 단계를 팀이 직접 만들고, 모델에게는 특정 시나리오를 실행하는 데 필요한 입력만 제공한다. Ace를 만들면서 팀은 상태 머신을 깊이 고민했다: 지금 단계는 무엇인가? 그다음에 올 수 있는 단계는 무엇인가? 그리고 각 단계 안에서, 모델을 그 특정 행동, 그 특정 순간에만 국한시키기 위해 구체적으로 무엇을 제공할 수 있는가?

이렇게 함으로써 Ace 팀은 Opus 4.7 같은 무거운 모델 대신 Haiku 4.5 같은 훨씬 작은 모델을 쓸 수 있었다. 추론 능력은 부족하지만, 주변의 하네스 덕분에 원하는 수준의 성능을 낼 수 있었고, 그 결과 비용, 시간, 지연시간을 모두 절약했다.

로그로 보는 실제 동작

발표 중 실제 레슨의 로그 녹화를 재생하며 보여준 내용: 화면 오른쪽에서 여러 종류의 하네스가 동시에 작동하는 것이 보인다 — 특정 섹션에서 무엇을 말하고 무엇을 할지 모델에게 알려주는 하네스, 화이트보드에 그림을 그리는 하네스, 큐(queue)를 비우는 것을 다루는 하네스, 레슨을 끝내는 방법 등 그 사이의 모든 단계를 다루는 하네스까지. 새로운 시나리오가 들어오더라도 신뢰성 있게 레슨을 진행할 수 있도록 이 모든 것을 상태 머신 안에 녹여 넣으려고 했다.

결과적으로 모델이 신경 쓰는 것은 오직 하나다 — 주어진 입력에 대해 어떤 행동을 취할지 알고, 그 행동의 결과를 내놓는 것. 모델은 "생각"할 필요가 없다. 모델은 제안하지만, 최종적으로 결정하는 것은 하네스다.

Ace가 다뤄야 했던 세 가지 핵심 질문

1. 레슨이 언제 끝나는가?
2. 학생이 실제로 제대로 이해했는가 — 의도한 방식으로 배웠는가?
3. 다음에 무엇이 와야 하는가?

이 세 범주에 속하는 모든 질문과 모델이 취해야 할 모든 행동은 모델 바깥에서 설계됐다. 다시 말하지만, 모델은 입력을 받아 출력을 내놓을 뿐이다.

일반화: 이 원칙은 어디에나 적용된다

이 원칙은 Ace 같은 음성 모델뿐 아니라 코딩 에이전트, Ops 런북, 온보딩 플로우 등 어디에나 동일하게 적용된다고 강조한다. 핵심은 항상 같다: 모델이 생각하게 두지 말고, 그 주변에 추상화를 쌓아라.

이 접근을 언제 써야 할지 판단하는 좋은 기준: 지금 만든 에이전트의 신뢰성이 "동전 던지기" 수준이라면, 제어 흐름(control flow)을 모델에서 빼내야 한다. 모델이 많은 결정을 내리지 못하게 하고, 대신 그 결정들을 모델 주위에 설계해서 모델은 쉬운 입력을 받아 쉬운 출력을 내놓게 하라.

3. 핵심 인사이트 & 시사점

• 신뢰성은 프롬프팅 문제가 아니라 제어 문제다. 데모에서 통과하는 프롬프트도 실사용자 앞에서는 무너진다. 근본 원인은 모델이 "지금 어느 단계인지"를 스스로 추론하게 방치했기 때문이다.
• 작은 상태 머신 + 좁은 계약(narrow contract) 패턴은 멀티스텝 에이전트의 신뢰성을 높이는 구조적 해법이다. 각 단계마다 모델에게 "이것만 하고 반환하라"는 좁은 임무를 주고, 검증·전이·다음 단계 결정은 하네스(외부 코드)가 담당한다.
• 하네스가 강할수록 더 작고 저렴한 모델을 쓸 수 있다. Opus급 대신 Haiku 4.5로도 원하는 성능을 낼 수 있었던 것은 모델의 지능이 아니라 주변 시스템 설계 덕분이었다 — 비용·속도·지연시간을 동시에 개선.
• **"모델은 제안하고, 하네스가 결정한다(propose, not decide)"**는 원칙은 음성 튜터뿐 아니라 코딩 에이전트, 온보딩 플로우, Ops 런북 등 모든 멀티스텝 에이전트 설계에 일반화된다.
• 판단 기준: 에이전트의 성공률이 "동전 던지기"에 가깝다면, 문제는 모델 성능이 아니라 제어 흐름 설계에 있을 가능성이 높다 — 프롬프트를 더 정교하게 만들기 전에 상태 머신 구조부터 점검하라.

4. 실행 포인트 & 결론

• 멀티스텝 에이전트를 설계할 때, "지금 어느 단계인가"와 "다음에 무엇이 오는가"를 모델의 추론에 맡기지 말고 외부 상태 머신으로 명시적으로 관리한다.
• 각 단계마다 모델에게 좁고 구체적인 입력(그 단계에서만 필요한 정보)을 주고, 좁은 출력(그 단계의 결과)만 반환받는다.
• 모델이 반환한 결과는 하네스가 검증한 뒤에만 다음 상태로 전이시킨다 — 모델의 자기 판단을 신뢰하지 않는다.
• 하네스가 충분히 강하면, 더 크고 비싼 모델 대신 더 작고 빠른 모델로도 목표 성능을 달성할 수 있는지 검토한다.
• 에이전트의 신뢰성이 낮다면 프롬프트 튜닝보다 먼저 제어 흐름(상태 머신/검증 로직)이 모델 안에 있는지, 모델 밖에 있는지부터 점검한다.

핵심 요약 (20줄)

1. Microsoft의 Ornella Bahidika와 Joel Allou가 실시간 AI 음성 튜터 Ace를 발표했다.
2. Ace는 레슨을 처음부터 끝까지 안정적으로 진행하는 것이 핵심 목표다.
3. 핵심 메시지: LLM이 진행을 주도하게 두지 마라 — 신뢰성 문제는 프롬프팅이 아니라 제어(control) 문제다.
4. 멀티스텝 에이전트는 데모에서는 완벽해 보이지만 실사용자 앞에서 중간에 멈추거나 단계를 건너뛰거나 루프에 빠진다.
5. 비유: 모델은 배우(talent), 하네스는 감독(director)이다.
6. 모델은 대사를 잘 전달하지만 "지금 몇 단계째인지" 기억하는 데는 형편없다.
7. 해법: 레슨을 intro-teach-check-grade-advance-wrap의 작은 상태 머신으로 설계한다.
8. 각 단계는 모델에게 "이 한 가지만 하고 반환하라"는 좁은 계약을 보낸다.
9. 하네스가 결과를 검증하고, 상태를 전이시키고, 다음 행동을 결정한다 — 모델은 결코 스스로 위치를 판단하지 않는다.
10. Joel: 오늘날 프론티어 모델(예: Claude Opus 4.7)에 사고와 처리 전체를 맡기는 방식은 라이브 음성 튜터 같은 상황에는 비효율적이다.
11. Ace 팀의 요구사항은 신뢰성, 비용 효율성, 속도였고, 이것이 "하네스 엔지니어링" 개념으로 이어졌다.
12. 각 단계마다 모델을 그 순간의 행동에만 국한시킬 구체적 입력을 설계했다.
13. 그 결과 무거운 모델 대신 더 작은 Haiku 4.5로도 목표 성능을 달성해 비용·시간·지연시간을 절약했다.
14. 실제 로그 시연: 섹션 안내, 화이트보드 드로잉, 큐 클리어링, 레슨 종료 등 각기 다른 하네스가 동시에 작동한다.
15. 모델은 제안(propose)만 하고, 최종 결정은 하네스가 내린다.
16. Ace가 다룬 3대 핵심 질문: 레슨이 언제 끝나는가, 학생이 제대로 배웠는가, 다음에 무엇이 오는가 — 이 모두를 모델 바깥에서 설계했다.
17. 이 원칙은 음성 모델뿐 아니라 코딩 에이전트, Ops 런북, 온보딩 플로우 등 모든 멀티스텝 에이전트에 일반화된다.
18. 판단 기준: 에이전트 신뢰성이 "동전 던지기" 수준이면 제어 흐름을 모델에서 빼내야 한다.
19. 결론: 모델이 말하게는 하되(let it talk), 운전은 시키지 마라(don't let it drive).
20. 발표는 짧은 라이트닝 토크 형식으로, Ace 데모와 함께 하네스 설계 철학을 압축적으로 전달했다.