시스템의 일부로서의 LLM
TMThttps://brooker.co.za/blog/2025/08/12/llms-as-components.html
타워 오브 하노이는 어쨌든 지루한 게임이다.
제가 Kiro 블로그에서 쓴 글, Kiro와 AI 명세 기반 소프트웨어 개발의 미래에서는 AI 에이전트 기반 개발 도구의 향후 방향에 대해 제 생각을 정리했습니다. 그 글에서 저는 매우 중요한 주제에 대해 약간은 짓궂고 간접적인 언급을 했습니다. 저는 Kiro에게 타워 오브 하노이 게임을 만들라고 요청했습니다.
이는 애플의 The Illusion of Thinking 논문과 그에 뒤따른 논의를 향한 간접적인 참조입니다. LLM이 타워 오브 하노이를 확장 가능하게 플레이할 수 있는지의 질문은 이론적·과학적으로 흥미롭긴 하지만, 가장 중요한 질문은 아닙니다. 더 중요한 질문은 LLM으로 구축된 시스템이 이러한 게임을 플레이할 수 있는가? 입니다. 그 다른 글에서 타워 오브 하노이를 선택함으로써, 저는 그 답이 분명히 그렇다 임을 지적했습니다. 그리고 이는 여러 LLM 세대 동안 그래왔습니다.
시스템 구축자로서 저는 LLM과 도구로 이루어진 시스템이 함께 무엇을 할 수 있는지에 훨씬 더 관심이 있습니다. LLM과 코드 인터프리터. LLM과 데이터베이스. LLM과 브라우저. LLM과 SMT 솔버. 이러한 시스템은 오늘날, LLM 단독으로는 단순히 할 수 없고, 앞으로도 결코 할 수 없을 일들을 해낼 수 있습니다. 더 중요한 점은, 동일한 일을 할 수 있는 경우에도 오늘날 이러한 시스템은 LLM보다 몇 자릿수나 더 저렴하고 빠르게 일을 해냅니다.
그런, 이런 종류의 것 말이죠:
> 문자열에서 r의 개수를 세는 파이썬 코드 조각을 생성하라.
def count_rs(input_string):
return input_string.lower().count('r')사소한가요? 맞습니다. 하지만 이제 저는 이 LLM이 풀 수 없는 문제를 풀 수 있는 시스템을 만들었습니다. 더 나은 LLM이라면 가능하겠지만, 예당 비용은 약 6자릿수 더 비쌉니다. 시스템은 근본적으로 구성 요소의 합보다 큽니다. 좋은 시스템은 어떤 구성 요소도 단독으로는 할 수 없는 일을 할 수 있습니다.
사소한 예가 사소하긴 하지만, 그 힘이 수십 년간 축적된 알고리즘의 진보를 활용하는 것까지 확장될 수 있음을 상상할 수 있습니다. 그리고 단지 count만이 아니라, SMT 솔버나 ILP 근사법, MCMC 같은 훨씬 더 강력한 것들까지요. 하지만 효율성 때문에, count, sum, grep 같은 사소한 것들조차도 흥미롭습니다.
좀 더 발전된 예로는 아마존 베드록의 Automated Reasoning Checks가 있습니다. Automated Reasoning Checks는 LLM을 사용해 문서 집합에서 근본적인 _규칙_을 추출하고, LLM이나 에이전트의 응답에서 _사실_을 추출한 다음, SMT 솔버를 사용해 그 사실들이 규칙과 논리적으로 일치하는지 검증합니다. Danilo의 블로그 글은 이 과정이 어떻게 보이는지에 대한 상세한 예시를 다루고 있으니, 더 이해하고 싶다면 참고하십시오.
Automated Reasoning Checks는 위의 사소한 예처럼, LLM을 다른 추론 방법과 결합해 구성 요소의 합보다 큰 시스템을 만들어냅니다. LLM은 인간이 사용하는 지저분한 자연어에서 사실과 규칙을 추출하는, 자신이 잘하는 역할을 수행합니다. SMT 솔버는 명확한 논리적 단계들을 통해 정밀하게 추론하고, 그 추론에 대한 형식적 정당화를 제공하는, 자신이 뛰어난 역할을 수행합니다. 현재 세대의 LLM은 이러한 유형의 추론을 단독으로 수행할 수 없지만, LLM과 다른 도구들(이 경우 SMT 솔버)로 구성된 시스템은 이를 수행할 수 있습니다.
LLM을 둘러싼 과대광고와 유행은 이 점을 잊게 만들기 쉽지만, 이는 매우 중요한 포인트입니다. LLM은 신중하게 설계된 시스템의 구성 요소로 배치될 때 더 강력하고, 더 신뢰할 수 있으며, 더 효율적이고, 더 유연합니다.
시스템 엔지니어에게는 매우 흥미로운 시대입니다. 더 나은 시스템을 더 새로운 능력과 함께 구축할 수 있도록 해주는, 새롭고 극도로 강력한 구성 요소를 손에 쥐었기 때문입니다. 일부 오래된 아이디어는 사라질 것입니다. 하지만 근본적인 아이디어들은 사라지지 않을 겁니다. 오히려 그 어느 때보다 더 관련성이 높아질 것입니다.
The Bitter Lesson은 어떻게 할 것인가?
LLM을 시스템의 일부로 보는 이러한 관점은 리치 서튼의 The Bitter Lesson과 일치할까요? 서튼은 이렇게 말합니다:
지난 70년간의 AI 연구에서 읽을 수 있는 가장 큰 교훈은, 계산을 활용하는 일반적 방법이 궁극적으로 가장 효과적이며, 그 차이는 매우 크다는 것이다.
그리고
우리는 장기적으로 우리가 생각하는 방식을 내장하는 것이 효과가 없다는 ‘씁쓸한 교훈’을 배워야 한다.
제가 제안하는 것은 이러한 시스템, 즉 LLM과 다른 계산·저장 도구로 구성된 시스템이 _우리가 생각한다고 생각하는 방식_을 내장해야 한다는 것이 아닙니다1. 제가 서튼의 요점을 읽는 방식은, 계산을 수행하는 더 나은(더 효율적이고, 더 신뢰할 수 있는 등) 방식과 덜 나은(덜 효율적이고, 덜 신뢰할 수 있는 등) 방식이 존재한다는 생각과 전혀 모순되지 않습니다. 예를 들어, 서튼은 어떤 작업을 많은 선형대수로 수행하는 것보다, 그 작업을 수행할 코드를 생성해 실행(또는 메모이즈하고, 검색해, 실행)하는 것이 덜 좋다고 암시하는 것 같지 않습니다.
우리는 우리가 발견한 것을 담고 있는 에이전트가 아니라, 우리처럼 발견할 수 있는 AI 에이전트를 원한다. 우리의 발견을 내장하는 것은 발견 과정이 어떻게 수행될 수 있는지를 이해하기 더 어렵게 만들 뿐이다.
그렇습니다. 파이썬에서 SMT에 이르기까지의 컴퓨팅은 80여 년 동안 강력한 발견의 도구였습니다. 우리가 구축하는 시스템, 특히 우리가 구축하는 AI 에이전트에게 이러한 도구들을 제공하는 것은, 그들에게 더 많은 힘과 지렛대를 부여합니다. 우리가 생각하는 방식을 코딩함으로써가 아니라, 우주가 작동하는 방식에 대해 컴퓨터 과학이 배운 것들을 코딩함으로써입니다.