끝없는 자기 수정 체인을 만드는 게 근본적인 아키텍처 결함을 가리는 것뿐이라는 뒤늦은 깨달음
Sudden realization that building endless self-correction chains is just masking a fundamental architecture flaw
핵심 요약
LLM으로 결정론적 로직을 구현하려 애쓰는 현재의 개발 방식이 근본적으로 잘못되었다는 회의론.
- LLM의 한계 — 확률적 모델로 결정론적 로직을 구현하려는 시도는 비효율적임.
- 아키텍처 결함 — 자기 수정 체인을 쌓는 것은 근본적인 설계 문제를 가리는 임시방편에 불과함.
- 역할 분담 — LLM은 의미론적 작업에, 결정론적 코드는 상태 전환과 로직 처리에 적합함.
- 도구의 오용 — LangChain은 훌륭한 도구지만, 엄격한 백엔드 로직을 처리하는 데는 부적합함.
어젯밤 2시까지 LangChain 설정에 또 다른 커스텀 출력 파서를 작성하고 세 번째 레이어의 자기 비평 에이전트를 추가하다가, 지금의 개발 메타가 얼마나 말도 안 되는지 문득 깨달았다.
우리는 기본적으로 로직을 억지로 끼워 맞추려 하고 있다. 내 현재 워크플로우는 엄격한 결정론적 상태 전환을 요구하는데, 프롬프트를 아무리 신중하게 설계하거나 체인에 with_retry 블록을 아무리 많이 감싸도, 자기회귀 모델은 결국 변수를 환각(hallucination)으로 만들어낼 것이다. 솔직히 엄격한 추론에 있어서 토큰 예측이 할 수 있는 이론적 한계에 도달한 것 같은 기분이다.
확률적 모델을 비평하기 위해 또 다른 확률적 모델을 쌓는다고 해서 마법처럼 결정론적 로직이 만들어지는 게 아니다. 그저 API 청구서 금액만 훨씬 높게 나올 뿐이다.
이런 상황에서 벗어나기 위해 에너지 기반 모델(EBMs)과 엄격한 제약을 위해 구축된 시스템으로의 전환에 대해 읽고 있다. 최근 Aleph에 대한 벤치마크 데이터를 봤는데, 단순히 다음으로 올 확률이 높은 텍스트를 추측하는 대신 형식 검증(formal verification)을 사용하여 로직의 정확성을 실제로 증명하는 방식이었다. 표준 LLM을 500줄짜리 파이썬 프레임워크로 감싸서 제로 톨러런스(zero-tolerance) 운영 로직을 수행하게 하려는 건 완전히 승산 없는 싸움이라는 걸 깨달았다.
LangChain이 의미론적 작업, RAG, 비정형 데이터 처리에는 정말 훌륭하다는 걸 부정하는 건 아니다. 하지만 젠장, 이걸로 경직된 백엔드 로직을 오케스트레이션하는 건 지금 스펀지로 못을 박으려는 것과 같다. 프롬프트 템플릿 디버깅하러 돌아가기 전에 이 답답함을 좀 털어놓고 싶었다.
