1. 무엇을 말하는 발표인가

마이크로소프트의 수석 응용과학자가 에이전트로 애플리케이션을 만드는 이야기를 한다. 사이버보안 부서에서 시큐리티 코파일럿과 그 에이전트를 만드는 데 참여했고, 그 전에는 우버에서 4년간 지오스페이셜 문제를 다루는 기계학습을 했다고 밝힌다.

이 발표가 자신이 오라일리에서 낼 300쪽짜리 책을 간추린 것이라고 먼저 말한다. 앞의 일곱 장이 이미 조기 공개돼 있고 다음 달 인쇄에 들어간다고 한다. 발표 내용의 코드 예제도 그쪽에 있다고 넘긴다.

바닥에 깔린 사실 하나가 나온다. Y 컴비네이터에 속한 회사 가운데 자기를 에이전틱하다고 말하는 곳이 3년 사이 254% 늘었다.

2. 축을 하나 더 놓는다

발표의 출발점은 사람들이 축을 하나만 보고 있다는 지적이다. 얼마나 자율적인가만 따진다는 것이다.

여기에 두 번째 축을 놓자고 한다. 그 시스템이 실제로 일을 해내는가다.

발표가 든 두 사례

사례가 둘뿐이라는 점은 그대로 적어 둔다. 발표는 네 칸을 다 채우지 않고 이 둘만 짚는다. 요점은 자율성이 낮아도 일을 잘 해내는 것이 있다는 쪽이다.

그래서 에이전시는 목표가 아니라 문제를 푸는 데 쓰는 수단이라고 정리한다.

3. 필요한 만큼만 올라가라

이 주장이 실제 설계로 내려오는 자리가 *오케스트레이션이다. 한 줄로 이어 붙인 체인으로 풀리면 그렇게 두라고 한다. 안 되면 갈림길을 만들어 모델이 어느 길로 갈지 고르게 한다. 완전히 에이전트에 맡기는 것은 모델의 손에 더 많은 힘을 쥐어 주는 일이라고 말한다.

한 판이 도는 방식 자체는 단순하다. 모델이 낸 글에 파서를 대고, 도구를 부르고, 돌아온 것을 관찰로 받고, 그 정보를 다시 넣어 반복하다가 마지막 출력을 낸다.

여러 에이전트를 쓸 때는 조정자를 하나 두고 그것이 알맞은 에이전트로 일을 넘기게 한다.

4. 평가가 바퀴가 되어야 한다

발표자는 완벽을 기대하지 말라고 못 박는다. 초기 프로토타입에서 정확도 70%까지는 쉽게 가는데, 복잡한 상황이 길게 이어지는 꼬리로 갈수록 점점 어려워진다는 것이다.

그래서 평가를 한 번 하고 끝내지 말고 바퀴로 만들라고 한다. 사람 검토를 거친 것만 평가셋에 쌓고, 늘어난 평가셋으로 다시 돌리고, 실패를 묶어 간추린 다음 고칠 것을 낸다.

안전 쪽도 한 줄 짚는다. 마이크로소프트가 *레드팀용으로 낸 파이릿(PyRIT)을 에이전트를 내보내기 전에 돌려 보라고 권한다. 자기 회사 도구를 권하는 대목이다. 다만 그러면서 좋은 소프트웨어 공학의 기본이 더 중요하다고 덧붙인다.

5. 발표가 밝히지 않은 것

50~70%대라는 점수가 무슨 지표인지 좁혀지지 않는다. 학계의 앞선 에이전트 벤치마크라고만 하고 어느 벤치마크인지 말하지 않는다. 여러 번 도구를 부르고 복잡한 환경에서 움직여야 하는 어려운 과제라는 설명만 붙는다.

롱테일이 얼마나 어려운지도 값이 없다. 70%까지 쉽고 그 뒤가 어렵다는 말은 나오는데, 남은 구간을 메우는 데 무엇이 얼마나 드는지가 없다.

두 축 위에 놓인 사례가 둘뿐이다. 높은 에이전시 쪽 칸이 비어 있어서, 자율성을 올렸을 때 효능이 어떻게 되는지가 사례로 안 나온다. 발표의 주장이 바로 그 자리에 있는데 그 자리가 비었다.

한 가지는 드물게 좋다. 발표자가 모델과 프레임워크가 발밑에서 바뀌고 있다고 스스로 밝힌다. 날짜를 붙여 읽어야 한다는 것을 발표가 먼저 말해 주는 편이다.