LLM이 이메일 하나 제대로 읽을 거라곤 믿지 않으면서, 왜 전체 워크플로우를 맡기는 걸까?

LLM에 대해 똑같은 불평들이 계속 올라오네:

“이메일 스레드 전체를 안 읽었어.” “중간에 멈췄어.” “일부 작업을 건너뛰었어.” “거짓말을 아주 당당하게 하더라.”

충분히 할 만한 불평이지.

근데 여기서 우리가 좀 이상한 짓을 하고 있어.

40페이지짜리 계약서를 분석하게 하고, 운영 중인 코드베이스를 수정하고, 시장 조사를 시키고, 브라우저를 돌리고, 회사 데이터를 다루게 하고, 의사결정을 내리고, 워크플로우를 알아서 처리하게 시킨 다음, 마지막엔 LLM한테 지가 일을 제대로 끝냈는지 물어보는 식이지.

사소한 것도 못 믿으면서 정작 중요한 일은 점점 더 많이 맡기고 있는 꼴이야.

난 이게 단순히 “다음 모델 나올 때까지 기다리자”로 해결될 문제라고 보지 않아.

아마 우리가 아키텍처를 잘못 짠 거 아닐까?

지금 대부분의 시스템은 LLM한테 과업을 이해하고, 상태를 기억하고, 다음 행동을 결정하고, 도구를 선택해서 쓰고, 오류를 복구하고, 마지막엔 지가 한 일이 맞는지 검증까지 하라고 시키고 있어.

시스템에서 제일 못 믿을 놈한테 너무 많은 책임을 떠넘기는 거 아니냐?

그래서 난 요즘 정반대 아키텍처에 관심이 많아.

상태, 메모리, 권한, 증거, 검증, 워크플로우 제어는 전부 LLM 밖으로 빼버리는 거야.

그리고 LLM은 원래 잘하는 거, 즉 해석, 추론, 종합, 창작, 그리고 모호한 상황을 다루는 데만 쓰는 거지.

다시 말해서:

LLM이 시스템을 돌리게 하지 말고, 시스템이 LLM을 돌리게 해야 한다는 거야.

지금 어떤 모델이 벤치마크 1등 먹었네 마네 하는 뻔한 토론보다는, 사람들이 실제로 이 문제를 어떻게 해결하고 있는지 그게 훨씬 궁금해.

그래서, 진짜 시스템을 만드는 사람들한테 묻는다:

LLM이 구라를 치거나, 일을 건너뛰거나, 중간에 멈추거나, 상태를 까먹거나, 제대로 하지도 않고 다 했다고 우길 때 너희는 실제로 어떻게 대응해?

모델 밖으로 뭘 빼냈어?

상태 머신(State machines)? 독립적인 검증? 결정론적 테스트? Evals? 이벤트 로그? 증거/출처 추적? 권한 경계? 다중 모델? 외부 메모리? 아니면 또 다른 거?

그리고 지금은 없지만 제발 좀 있었으면 하는 인프라는 뭐야?

마지막으로 한마디 던지자면, LLM이 일을 제대로 끝냈는지 확인하는 방법이 그 LLM한테 직접 물어보는 게 전부라면, 그건 LLM 엔지니어링이라고 부르기 좀 민망하지 않나 싶다.

프롬프트 좀 더 다듬거나 CLAUDE.md 수정한다고 해결될 문제가 아니야.

내가 보기에 LLM 엔지니어링과 **LLM 쇼(LLM theatre)**를 가르는 결정적인 엔지니어링 관습이 하나 있거든.

그게 뭐라고 생각해?

그리고 더 중요한 건, 너희는 실제로 뭘 쓰고 있냐?

내 스파링 파트너인 ChatGPT와 공동 집필함. 주제가 주제인 만큼 밝히는 게 맞는 것 같아서. 내 맥북이랑 와이파이한테까지 공을 돌리진 않을 거니까.