1P by GN⁺ 1일전 | ★ favorite | 댓글 1개

핵심 주장: 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은 인터페이스 역할에 집중하고, 핵심 로직은 전용 시스템에 맡겨야 함
Hacker News 의견
  • 논리에는 두 가지 유형이 있음

      1. 본질적으로 정확하고 엄격해야 하는 논리
      1. 컴퓨터의 특성상 그렇게 되어온 논리
  • 1번 유형은 보안, 금융, 수학 등과 같은 분야에 해당함

  • 2번 유형은 AI가 대체할 가능성이 높음

  • 같은 애플리케이션의 다른 부분은 1번이나 2번에 적합할 수 있음

  • 최근 해커톤에서 교육용 게임을 제작했음

    • LLM을 사용해 게임을 생성하고 실행했으나 게임의 흐름이 좋지 않았음
    • 최종적으로는 많은 Python 코드와 여러 프롬프트를 사용하여 게임 상태를 관리했음
    • LLM은 큰 시스템의 작은 부품으로 사용하는 것이 가장 좋음
  • LLM은 논리를 구현하지 않아야 함

    • 논리, 최적화, 제약 프로그래밍은 별도의 기법임
    • 현대 논리학의 창시자는 George Boole이며, 그는 Geoffrey Everest Hinton의 조부임
  • LLM의 기능을 이해하는 것은 어려움

    • 독자들은 간단한 답변을 원함
    • LLM은 간단한 상태 기계를 작성하는 데 어려움을 겪을 수 있음
    • 연구 논문이 인기를 끌고 있으며, 2025년까지도 LLM을 완전히 이해하는 사람은 없을 것임
  • LLM 응답이 빠르고 저렴해야 한다면 짧은 프롬프트와 작은 모델을 사용해야 함

    • 많은 정보가 큰 모델을 사용하는 것을 전제로 하고 있음
    • 전통적인 UI가 더 나은 선택일 수 있음
  • LLM만으로는 테스트가 어려움

    • 개인의 스타일이 상호작용에 영향을 미침
    • 유지보수 비용이 높을 수 있음
    • API 호출로 변환하는 것이 더 합리적임
  • LLM을 비즈니스 로직에 사용하는 것은 위험함

    • 언어 처리에 적합함
  • AI 생성 이미지를 사용해 기사를 요약할 수 있음