그럼 LLM은 언제 쓰는 게 맞을까

형식이 정해지지 않은 글과 말을 다룰 때, 그리고 결과를 사람이 확인할 수 있을 때 LLM이 가장 빛납니다.

앞 장에서 LLM이 필요 없는 경우를 봤습니다. 그렇다고 LLM이 쓸모없다는 건 아닙니다. 오히려 다른 방법으로는 거의 불가능했던 일을 해냅니다. 기준은 간단합니다.

LLM이 빛나는 곳

1. 형식이 정해지지 않은 글과 말

규칙으로 짜려면 입력의 모양이 정해져 있어야 합니다. 그런데 사람이 쓰는 메일, 리뷰, 회의 대화, 문서는 모양이 제각각입니다. 이런 걸 읽고 요약하고, 분류하고, 다른 말투로 바꾸고, 번역하는 일은 LLM이 가장 잘하는 일입니다.

2. 사람과 말로 주고받아야 할 때

메뉴를 누르는 대신 “지난달 회의에서 예산 얘기 나온 부분 찾아줘”처럼 말로 원하는 걸 설명할 수 있다는 것. 이건 LLM 이전에는 어려웠던 일입니다.

3. 초안이 필요할 때

빈 화면에서 시작하는 것보다 초안을 고치는 게 훨씬 빠릅니다. 글, 기획안, 코드의 첫 버전을 만드는 데 LLM은 강력합니다. 2부에서 본 것처럼 초안으로 받고 내가 고친다는 전제만 지키면요.

그리고 결과를 확인할 수 있을 때

LLM이 잘하는 일이어도, 결과를 확인할 방법이 있을 때 가장 안전하게 쓸 수 있습니다. 요약이라면 원문이 있고, 번역이라면 아는 사람이 볼 수 있고, 코드라면 실행해볼 수 있습니다. 확인할 방법이 없는 곳에 LLM을 쓰면, 기초 이론 편 6.1에서 본 환각을 걸러낼 수 없습니다.

섞어 쓰는 게 보통입니다

실제 서비스는 하나만 쓰지 않습니다. 예를 들어 고객 문의를 처리한다면:

LLM이 자유로운 문의 글을 읽고 “환불 / 배송 / 기타” 중 무엇인지 정리하고,
규칙이 “환불이면서 30일 이내면 자동 승인”처럼 정해진 처리를 하고,
애매한 건 사람에게 넘깁니다.

LLM은 글을 다루는 부분을, 규칙은 정해진 판단을, 사람은 책임과 예외를 맡는 식입니다. 기초 이론 편 4.4에서 본 “판단만 빠르게 하는 모델”도 이런 역할 나누기의 한 예입니다.

정리

LLM은 형식 없는 글과 말, 말로 주고받기, 초안 만들기에서 빛납니다.
결과를 확인할 방법이 있을 때 가장 안전하게 쓸 수 있습니다.
실제로는 LLM, 규칙, 사람을 섞어서 각자 잘하는 부분을 맡깁니다.