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

> Clean Markdown view of GeekNews topic #20114. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=20114](https://news.hada.io/topic?id=20114)
- GeekNews Markdown: [https://news.hada.io/topic/20114.md](https://news.hada.io/topic/20114.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2025-04-03T09:52:30+09:00
- Updated: 2025-04-03T09:52:30+09:00
- Original source: [sgnt.ai](https://sgnt.ai/p/hell-out-of-llms/)
- Points: 1
- Comments: 1

## Topic Body

### 핵심 주장: 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은 인터페이스 역할에 집중하고, 핵심 로직은 전용 시스템에 맡겨야 함

## Comments



### Comment 36676

- Author: neo
- Created: 2025-04-03T09:52:30+09:00
- Points: 1

###### [Hacker News 의견](https://news.ycombinator.com/item?id=43542259) 
- 논리에는 두 가지 유형이 있음
  - 1. 본질적으로 정확하고 엄격해야 하는 논리
  - 2. 컴퓨터의 특성상 그렇게 되어온 논리
- 1번 유형은 보안, 금융, 수학 등과 같은 분야에 해당함
- 2번 유형은 AI가 대체할 가능성이 높음
- 같은 애플리케이션의 다른 부분은 1번이나 2번에 적합할 수 있음

- 최근 해커톤에서 교육용 게임을 제작했음
  - LLM을 사용해 게임을 생성하고 실행했으나 게임의 흐름이 좋지 않았음
  - 최종적으로는 많은 Python 코드와 여러 프롬프트를 사용하여 게임 상태를 관리했음
  - LLM은 큰 시스템의 작은 부품으로 사용하는 것이 가장 좋음

- LLM은 논리를 구현하지 않아야 함
  - 논리, 최적화, 제약 프로그래밍은 별도의 기법임
  - 현대 논리학의 창시자는 George Boole이며, 그는 Geoffrey Everest Hinton의 조부임

- LLM의 기능을 이해하는 것은 어려움
  - 독자들은 간단한 답변을 원함
  - LLM은 간단한 상태 기계를 작성하는 데 어려움을 겪을 수 있음
  - 연구 논문이 인기를 끌고 있으며, 2025년까지도 LLM을 완전히 이해하는 사람은 없을 것임

- LLM 응답이 빠르고 저렴해야 한다면 짧은 프롬프트와 작은 모델을 사용해야 함
  - 많은 정보가 큰 모델을 사용하는 것을 전제로 하고 있음
  - 전통적인 UI가 더 나은 선택일 수 있음

- LLM만으로는 테스트가 어려움
  - 개인의 스타일이 상호작용에 영향을 미침
  - 유지보수 비용이 높을 수 있음
  - API 호출로 변환하는 것이 더 합리적임

- LLM을 비즈니스 로직에 사용하는 것은 위험함
  - 언어 처리에 적합함

- AI 생성 이미지를 사용해 기사를 요약할 수 있음