LLM은 무엇이고 왜 필요한가

오늘의 질문

검색, 규칙 기반 프로그램, LLM은 무엇이 다르고 LLM은 어디에 잘 맞는가?

이 질문이 실무에서 나올 때 진짜 형태는 보통 이렇다.

“이 업무, 그냥 검색으로 되지 않나? 아니면 if문 몇 개로 끝나는 거 아닌가? 굳이 LLM을 왜 써?”

그래서 오늘 답할 것은 “LLM이 무엇인가”라는 사전적 정의가 아니라, 셋 중 무엇을 고를지 판단하는 기준이다.

먼저 답하기

셋은 경쟁 기술이 아니다. 서로 다른 질문에 답하는 도구다. 한 줄로 줄이면 이렇다.

• 검색은 “답이 이미 문서 어딘가에 통째로 있는가?” 에 답한다. 있으면 찾아다 준다.
• 규칙 기반 프로그램은 “입력의 경우의 수를 사람이 미리 다 적을 수 있는가?” 에 답한다. 적을 수 있으면 가장 정확하고 가장 싸다.
• LLM은 앞의 두 질문이 모두 “아니오”일 때 남는 선택지다. 답이 어디에도 통째로는 없고, 경우의 수도 다 못 적겠는데, 그래도 지금 쓸 만한 결과가 필요할 때.

여기에 판단을 하나 더 붙여야 한다. 틀렸을 때 알아챌 수 있는가?

검색이 실패하면 “결과 없음”이 뜬다. 규칙이 실패하면 로그에 남거나 처리되지 않은 채 쌓인다. LLM이 실패하면 그럴듯한 오답이 나온다. 실패가 눈에 보이지 않는다. 그래서 LLM은 “경우의 수를 못 적는 일” 중에서도 결과를 사람이나 다음 단계가 검산할 수 있는 일에 먼저 붙이는 게 맞다.

아래는 이 결론이 어디서 나왔는지를 풀어 쓴 것이다.

LLM은 언제 필요한가

왜 필요한가

규칙 기반이 무너지는 지점

규칙 기반 프로그램은 나쁜 기술이 아니다. 오히려 조건이 유한할 때는 LLM보다 모든 면에서 낫다. 정확하고, 빠르고, 싸고, 왜 그 답이 나왔는지 설명할 수 있다.

문제는 입력이 자연어일 때 경우의 수가 사람이 적을 수 있는 범위를 넘어간다는 것이다. 같은 뜻을 사람들은 제각각 쓴다. “결제가 두 번 됐어요”, “카드가 두 번 긁힌 것 같은데요”, “중복 청구 확인 부탁드립니다” — 셋 다 같은 일인데 겹치는 키워드가 없다.

여기서 규칙을 추가하는 방식으로 대응하면 비용이 어떻게 늘어나는지, 아주 작은 계산으로 감각만 잡아보자.

가정

• 분류에 사용하는 판단 축이 k = 6개 (예: 요청 종류, 제품 영역, 긴급도, 고객 등급, 언어, 채널)
• 각 축이 가질 수 있는 값이 m = 4개
• 축이 서로 독립이라고 단순화

단위: 사람이 검토해야 하는 조건 조합의 개수 (rule count)

식과 결과

규칙 하나를 추가하는 비용이 문제가 아니다. 값 하나를 추가할 때 같이 검토해야 하는 조합이 곱셈으로 늘어난다는 게 문제다. 새 제품 카테고리 하나가 생기면 1,024개 조합의 동작을 다시 확인해야 한다는 뜻이다.

적용 한계 (중요)

• 실제 시스템의 축은 독립이 아니고, 기본값(fallback)과 우선순위 규칙으로 실제 작성하는 규칙 수는 이보다 훨씬 적다. 위 숫자는 코드 라인 수가 아니라 “검토 범위의 상한”에 대한 감각이다.
• 이 계산은 LLM이 더 정확하다는 근거가 전혀 아니다. 규칙 기반의 유지보수 비용이 어떤 모양으로 증가하는지만 보여준다. 정확도 비교는 별도의 측정이 필요하다.
• k, m 값은 설명을 위한 임의의 toy 설정이다. 실제 업무 수치가 아니다.

검색이 무너지는 지점

검색은 “답이 문서 어딘가에 통째로 있을 때” 최고의 도구다. 원문을 그대로 주므로 출처가 명확하고, 내용을 왜곡하지 않는다.

무너지는 지점은 답이 한 문서에 통째로 있지 않을 때다. 세 문서에 흩어진 내용을 합치거나, 표를 문장으로 바꾸거나, 긴 스레드를 세 줄로 줄이는 일은 “찾기”가 아니라 “만들기”다. 검색은 만들지 않는다.

그래서 남는 요구

정리하면 이런 도구가 필요해진다.

경우의 수를 사람이 미리 열거하지 않았는데도, 처음 보는 입력을 그럴듯하게 처리하는 함수.

LLM은 이 자리를 채우는 도구다. 그리고 이 자리를 채우는 대가로 정확성과 설명 가능성을 일부 포기한다. 이 교환이 오늘 글의 핵심이다.

핵심 용어

처음 나오는 순서대로, 짧게 정의하고 흔한 오해를 한 줄씩 붙인다.

generative AI (생성형 AI) 기존 데이터에서 답을 찾아 보여주는 대신, 새 출력을 만들어내는 AI. → 오해 방지: “만든다”는 건 창의적이라는 뜻이 아니라, 출력이 원본 어딘가에 그대로 있지 않다는 뜻이다. 그래서 출처를 되짚기 어렵다.

model (모델) 입력을 받아 출력을 내놓는 함수. 그 함수의 구체적인 모양은 파라미터(parameter) 라고 부르는 숫자 뭉치가 결정한다. → 오해 방지: 모델은 데이터베이스가 아니다. 학습 문서가 안에 저장돼 있는 게 아니라, 패턴이 숫자로 눌려 들어가 있다.

LLM (large language model, 대규모 언어 모델) 아주 많은 텍스트로 학습해서, 주어진 맥락 다음에 올 말을 예측하도록 훈련된 큰 모델. → 오해 방지: “다음 말 예측”이 전부다. 요약도 번역도 분류도, 결국 이 하나의 동작으로 처리된다.

training (학습) 데이터를 보면서 파라미터 값을 조정하는 단계. 계산량이 크고, 보통 한 번 또는 가끔 일어난다.

inference (추론) 학습이 끝난 파라미터를 고정한 채, 입력을 넣어 출력을 받는 단계. 요청이 올 때마다 반복된다.

이 그림이 없으면 독자는 “프롬프트에 예시를 넣는 것”과 “모델을 학습시키는 것”을 같은 일로 오해한다. 두 단계의 시점이 분리돼 있다는 사실을 봐야, 프롬프트가 왜 중요한지도 프롬프트가 왜 모델을 바꾸지 못하는지도 설명된다.

이 분리에는 공개 출처로 뒷받침되는 근거가 있다. GPT-3 논문(arXiv:2005.14165)은 과제를 프롬프트 안의 예시(few-shot demonstration)만으로 지정하고, 그 과정에서 gradient 갱신이나 fine-tuning을 수행하지 않는 방식을 명시적으로 다룬다. 즉 프롬프트에 예시를 넣는 것은 학습이 아니라 입력이다.

그래서 “프롬프트 설계”라는 작업이 따로 존재한다. 파라미터를 못 바꾸는 상황에서 결과를 바꿀 수 있는 손잡이가 입력이기 때문이다.

작은 예시

고른 업무: 고객 문의 메일을 담당 팀으로 분류하기. 엔지니어에게 익숙하고, 규칙으로도 짤 수 있고, LLM으로도 되는 일이다.

규칙 기반으로 짜면

if "결제" in text or "환불" in text:  → 결제팀
elif "로그인" in text or "비밀번호" in text: → 인증팀
else: → 일반 CS

돌려보면 이런 입력에서 깨진다.

3행이 핵심이다. 키워드는 단어의 존재만 보고, 의도는 못 본다. 그리고 이걸 고치려면 “결제 키워드가 있어도 로그인 키워드가 함께 있으면 인증팀” 같은 예외를 추가해야 하는데, 이게 앞에서 계산한 조합 폭발의 시작점이다.

LLM으로 하면

지시문 하나로 대체된다.

다음 고객 문의를 [결제 / 인증 / 배송 / 일반] 중 하나로 분류하고,
확신이 없으면 "판단불가"로 답하라. 이유를 한 문장으로 덧붙여라.

키워드 목록도, 예외 규칙도 없다. 2·3행 같은 입력도 대체로 처리된다. 대신 새로운 문제가 생긴다.

• 왜 그렇게 분류했는지 추적이 어렵다. 이유를 물어보면 답은 하지만, 그 설명이 실제 계산 과정이라는 보장은 없다.
• 같은 입력에 항상 같은 답이 나온다고 보장하기 어렵다. 샘플링 설정에 따라 달라질 수 있다.
• 모르는 걸 모른다고 하지 않는 경향이 있다. 위 지시문에 “판단불가” 선택지를 넣은 이유가 이것이다.

같은 축에서 비교

이 표가 없으면 독자는 세 도구를 “성능 순서”로 오해한다. 셋은 서로 다른 축에서 강하고, 어느 축이 중요한지가 선택을 결정한다.

표를 읽는 법: LLM이 이기는 칸은 사실상 두 줄뿐이다 — “입력 표현이 다양해지면”과 “새 경우가 생기면”. 나머지 줄에서는 대체로 진다. 그러니 저 두 줄이 내 업무에서 가장 아픈 지점일 때만 LLM이 옳은 선택이다.

실무에서는 기술 선택보다 판단 축을 잘못 고르는 것이 더 큰 실패로 이어진다. 정산이나 규정 판정처럼 “재현성”과 “설명 가능성”이 중요한 업무에 LLM을 넣으면, 얻는 이득보다 잃는 것이 커질 수 있다.

자주 묻는 질문

Q1. 프롬프트에 예시를 넣으면 모델이 학습되나요? 아니다. 예시는 입력의 일부로 들어갈 뿐이고 파라미터는 그대로다. GPT-3 논문이 다루는 few-shot 방식이 정확히 이 구도로, 프롬프트에 예시를 제시하되 gradient 갱신은 하지 않는다. 실무적으로 두 가지 결과가 따라온다. ① 이번 요청에서 알려준 내용은 다음 요청에 남지 않는다. ② 예시를 넣을수록 입력이 길어지고, 요청마다 그 비용을 다시 낸다.

Q2. LLM이 검색을 대체하나요? 아니다. 오히려 자주 같이 쓴다. 답이 문서에 통째로 있으면 검색이 정확하고 출처도 남는다. LLM은 찾아온 문서를 요약·변환·조합하는 쪽을 맡는 게 낫다. 판단 기준은 하나다 — 원문 그대로가 답인가, 아니면 원문을 가공해야 답이 되는가?

Q3. 규칙 기반은 이제 필요 없나요? 정반대다. 경우의 수가 유한한 부분은 여전히 규칙으로 짜는 게 맞다. 정확하고, 싸고, 설명 가능하고, 테스트할 수 있다. 현실적인 조합은 “규칙으로 확실한 것부터 걸러내고, 남는 애매한 입력만 LLM으로 넘기는” 구조다. 이러면 LLM 호출량도 줄고 실패 범위도 좁아진다. (이 구성은 내 권장이지 출처 있는 주장은 아니다.)

Q4. LLM이 틀리는 건 버그인가요, 원래 그런 건가요? 설계상 예상되는 동작에 가깝다. LLM은 “맥락 다음에 올 그럴듯한 말”을 만들도록 훈련됐지, “사실인 말”을 만들도록 훈련되지 않았다. 그럴듯함과 사실은 대개 겹치지만 항상 겹치지는 않는다. GPT-3 논문 자체도 여러 과제에서의 약점과 대규모 웹 코퍼스 학습의 한계를 함께 기술한다. 그러니 정확도를 올리는 문제가 아니라, 틀린 걸 잡아내는 장치를 어디에 둘 것인지의 문제로 접근하는 게 낫다.

Q5. 우리 업무에 쓸지 어떻게 판단하나요? 네 가지를 순서대로 확인하면 대체로 판단이 선다.

1. 답이 문서에 통째로 있는가? → 있으면 검색.
2. 입력의 경우의 수를 다 적을 수 있는가? → 적을 수 있으면 규칙.
3. 둘 다 아니라면, 결과가 틀렸을 때 누가/무엇이 검산하는가? → 검산 지점이 없으면 아직 넣지 말 것.
4. 틀렸을 때의 최대 피해가 감당 가능한가? → 초안·분류·요약은 대체로 감당 가능, 정산·규정 판정은 아님.