1. 무엇을 만들며 얻은 이야기인가

마이크로소프트 리서치의 수석 리서치 소프트웨어 엔지니어가 사람과 AI가 만나는 자리를 주로 다뤄 왔다고 밝히며 발표를 연다. 깃허브 코파일럿을 만들었고, 멀티 에이전트 프레임워크 오토젠과 그 스튜디오를 만들었다. 그 전에는 IBM 리서치에서 사람과 컴퓨터가 주고받는 일을 다뤘다.

이 발표는 3D 제작 소프트웨어 블렌더를 자연어로 다루는 에이전트를 직접 만들며 얻은 것을 재료로 삼는다. 거기서 뽑은 설계 원칙 넷을 준다고 먼저 말하고, 완전하지도 완벽하지도 않다고 스스로 못 박는다.

2. 만드는 순서

순서 자체가 주장이다. 목표를 정하고, 견줄 기준을 잡고, 도구를 만들고, 재는 자리를 세우고, 그다음에 에이전트를 붙인다.

둘째 자리가 눈에 걸린다. 견줄 기준은 에이전트와도 AI와도 무관한 것으로 잡으라고 한다. 에이전트가 맨 마지막에 오는 것도 같은 뜻이다. 재는 자리가 먼저 서 있어야 에이전트를 붙인 뒤 무엇이 나아졌는지 말할 수 있다.

재는 자리도 한 번에 만들지 않았다. 처음은 주피터 노트북이었고, 그다음이 사람이 직접 눌러 보는 웹 화면이었고, 마지막이 자동으로 도는 평가 묶음이었다.

3. 루프가 자란 순서

블렌더 에이전트도 한 번에 완성하지 않았다. 단순한 루프를 먼저 돌리고, 결과가 맞는지 보는 검증 에이전트를 붙이고, 단계를 먼저 짜는 계획 에이전트를 붙였다.

화면에서는 작업을 받으면 먼저 분석 중이라고 알리고, 계획을 세웠다고 보여 주고, 단계마다 도구를 불러 실행하는 것을 흘려보내고, 검증을 거쳐 결과물을 낸다.

4. 반쯤 자율일 때 필요한 것 넷

발표자가 든 네 가지 설계 원칙

넷째 원칙에 붙은 예가 구체적이다. 파이썬 코드를 쓰게 했더니 운영체제를 통째로 지우려 드는 일이 생길 수 있다는 것이다. 그런 일이 벌어지기 전에 행동의 값을 재고 사람에게 넘기는 자리가 있어야 한다고 말한다.

5. 멀티 에이전트가 이득인 일은 작다

발표자가 든 그림 하나가 이 발표의 균형을 잡는다. 엔지니어링 팀이 해야 할 일을 큰 원이라 하면, 멀티 에이전트 방식으로 진짜 이득을 보는 일은 그 아래 작은 원 하나라는 것이다.

무엇이 그 작은 원에 드는지 가늠하는 물음도 준다. 계획이 필요한 일인가, 여러 관점이나 역할로 쪼갤 수 있는 일인가, 방대한 맥락을 다뤄야 하는 일인가, 상황에 따라 답이 달라져야 하는 일인가.

6. 발표가 밝히지 않은 것

오류율 20%가 1.5%로 내려간 것은 이 에이전트 이야기가 아니다. 2022년에 만든 앞선 프로젝트에서 모델을 바꾸며 난 변화다. 첫 판은 한 모델을 썼고 석 달 뒤 다른 모델로 옮겨 손보자 그렇게 됐다. 검증 에이전트나 계획 에이전트를 붙여서 난 변화가 아니므로 겹쳐 읽으면 안 된다.

그 검증과 계획을 붙여서 무엇이 얼마나 나아졌는지는 수치가 없다. 루프가 자란 순서는 나오는데 각 단계의 값이 안 나온다. 재는 자리를 먼저 세우라고 말한 발표인 만큼 이 대목이 비어 있는 것이 특히 걸린다.

원칙 넷의 효과를 잰 값도 없다. 발표자가 완전하지도 완벽하지도 않다고 먼저 밝히기는 한다.

작은 흠 하나. 멀티 에이전트가 맞는 일인지 가늠하는 틀을 다섯 단계라고 부르면서 실제로는 넷만 든다. 자막에 그대로 그렇게 나온다.