LLM이 결정을 내리거나 비즈니스 로직을 실행하도록 하지 마세요

핵심 주장: LLM에서 최대한 빨리 빠져나오고 오래 머물지 말아야 함

• LLM에게 의사결정이나 비즈니스 로직을 맡기면 안 됨 → 정확성과 안정성이 부족
• 대부분의 경우, LLM은 단지 사용자와 애플리케이션 API 사이의 인터페이스 역할만 해야 함
• 핵심 로직은 전용 시스템이나 엔진에서 수행하고, LLM은 사용자 요청을 API 호출로 바꾸고 결과를 다시 자연어로 바꾸는 역할만 맡아야 함

왜 그런가?

• 체스 봇 예시: 사용자가 WhatsApp으로 "내 비숍으로 나이트를 잡아줘"라고 보냄 → LLM이 체스판 상태 유지 및 플레이도 가능은 하지만, 신뢰성, 성능, 유지보수 측면에서 문제가 많음

• 성능: LLM은 체스를 두는 능력이 놀랍긴 하지만 여전히 전문 체스 엔진(예: Stockfish)에 비해 느리고 정확도도 떨어짐

• 디버깅 및 조정 불가: 왜 그런 판단을 했는지 알기 어려워서 의도한 방식으로 동작하게 수정하기 어려움

• 기타 문제들:

  • LLM 출력은 테스트가 어려움
  • 수학이나 무작위 숫자 생성 성능이 낮음
  • 버전 관리와 감사가 어려움
  • 상태를 자연어로 유지하는 방식은 취약함
  • API 요금, 속도 제한 등의 문제가 발생함
  • 보안 경계가 흐려짐

다양한 예시로 본 올바른 역할 분리

• 게임에서 "플레이어 X를 보팔 소드로 공격할래요" → LLM은 이걸 attack(player=X, weapon="vorpal_sword") 형태로 변환해서 게임 로직에 넘기는 역할만 수행해야 함
• 협상 에이전트 → LLM은 협상 판단을 하지 않고, 사용자의 입력을 포장해서 협상 엔진에 넘기고 결과를 전달함
• 무작위 응답 생성 → LLM이 선택하지 않고 외부의 무작위 함수에서 처리해야 함

LLM이 잘하는 일

• LLM은 변환, 해석, 커뮤니케이션에 특화됨
• 예시:
  • "오크를 칼로 때린다" → attack(target="orc", weapon="sword")로 변환
  • { "error": "insufficient_funds" } → "골드가 부족합니다"로 자연스럽게 설명
  • 사용자의 입력이 전투 명령인지, 인벤토리 확인인지, 도움 요청인지 분류 가능
  • 인간 개념(예: blade = sword, smash = attack)을 잘 이해함
• 핵심은 복잡한 판단이나 상태 관리가 아님 → 단지 사용자의 의도를 시스템에 연결하는 다리 역할

미래 전망과 지속되는 원칙

• 기술이 빠르게 발전하고 있어서, 지금은 불가능한 것도 곧 가능해질 수 있음
• 그러나 LLM이 해결할 수 없는 구조적 문제는 계속 남을 가능성이 높음:
  • LLM을 사용하지 않는 로직은 더 이해하기 쉽고, 유지보수 및 버전 관리가 쉬움
  • 실행 비용도 더 저렴함
• 미래에도 마찬가지로, LLM은 인터페이스 역할에 집중하고, 핵심 로직은 전용 시스템에 맡겨야 함