P6-1.2 생성형 AI를 읽는 중심 사례로서의 LLM¶

Section ID: P6-1.2 Version: v2026.07.23

생성형 AI에는 이미지 생성, 음성 생성, 영상 생성, 코드 생성처럼 여러 흐름이 있습니다. Part 6이 이 전체를 모두 깊게 다루지는 않습니다. 이 Part에서는 LLM(large language model)을 중심 사례로 삼아 생성형 AI의 동작 원리와 사용 구조를 읽습니다.

LLM을 중심 사례로 두는 이유는 LLM이 생성형 AI의 전부이기 때문이 아닙니다. 텍스트 생성형 AI는 다음 흐름을 한 Part 안에서 가장 직접적으로 보여 줍니다.

flowchart TD
  A["사용자 요청"]
  B["LLM 응답 산출물"]
  C["프롬프트 보강"]
  D["외부 근거 연결"]
  E["도구 실행"]
  F["평가와 운영 기록"]

  A --> B
  B --> C
  B --> D
  B --> E
  C --> F
  D --> F
  E --> F

이 흐름은 LLM이 답을 만든다에서 멈추지 않습니다. 요청이 들어오면 LLM은 먼저 읽고 쓸 수 있는 산출물을 만들지만, 실제 서비스에서는 그 산출물을 더 나은 프롬프트로 제어하거나, 외부 문서로 근거를 보강하거나, 도구 실행과 평가 기록으로 이어 붙여야 합니다.

이미지나 음성 생성에서도 산출물을 만들고 검토한다는 공통 문제는 남습니다. 다만 Part 6의 대표 경로는 텍스트 LLM입니다. 텍스트 LLM을 먼저 읽으면 프롬프트, RAG, 도구 사용, 에이전트, 평가, 운영 제약을 한 흐름으로 연결할 수 있습니다.

텍스트 LLM이 대표 사례로 적합한 이유는 출력이 문장이라서 쉬워 보이기 때문이 아닙니다. 오히려 문장 산출물은 사용자가 실제 서비스에서 마주치는 여러 문제를 한 화면에 드러냅니다.

LLM은 생성형 AI 전체가 아니라 연결 지점이다¶

LLM을 중심 사례로 읽는다는 말은 이미지 생성이나 음성 생성을 덜 중요하게 본다는 뜻이 아닙니다. Part 6의 목적은 생성형 AI 전체를 종류별로 훑는 것이 아니라, 하나의 생성 산출물이 사용 장면에서 어떻게 보강되고 검토되는지 끝까지 따라가는 것입니다.

텍스트 LLM은 이 목적에 잘 맞습니다. 사용자의 요청, 모델의 중간 입력, 검색된 문서, 함수 호출 인자, 평가 기록이 모두 텍스트나 구조화된 텍스트로 남기 쉽기 때문입니다. 그래서 독자는 화면에 나온 답변만 보지 않고, 그 답변을 만들기 전후의 흔적을 함께 읽는 연습을 할 수 있습니다.

생성형 AI 흐름	공통 문제	LLM에서 특히 잘 보이는 지점
이미지 생성	산출물이 요청 의도와 맞는지 검토해야 한다.	프롬프트가 어떤 조건을 넣고 뺐는지 문장으로 추적하기 쉽다.
음성 생성	말투, 발음, 맥락 적합성을 확인해야 한다.	대본, 지시, 안전 기준을 텍스트로 먼저 나누어 볼 수 있다.
코드 생성	실행 결과와 오류를 확인해야 한다.	설명, 코드, 테스트, 실행 로그가 한 흐름으로 이어진다.
텍스트 답변 생성	사실, 근거, 권한, 형식을 함께 검토해야 한다.	RAG, tool use, 평가, 운영 기록과 바로 연결된다.

따라서 Part 6에서 LLM은 가장 중요한 생성형 AI라는 결론이 아니라 생성, 보강, 실행, 검토가 한 화면에서 이어지는 대표 경로입니다. 이 관점이 있어야 뒤에서 등장하는 용어들이 제품 기능 목록처럼 흩어지지 않습니다.

보강 구조는 요청의 성격에 따라 달라진다¶

사용자 요청	LLM만으로 먼저 할 수 있는 일	그대로 끝내기 어려운 이유	필요한 보강
`환불 정책을 알려 줘`	자연스러운 설명을 만든다.	정책이 바뀌었을 수 있다.	최신 문서를 찾아 붙인다.
`이 금액의 세금을 계산해 줘`	계산 방법을 설명한다.	숫자 계산은 한 자리 오류도 문제가 된다.	계산 도구로 값을 확인한다.
`고객에게 답장을 보내 줘`	답장 초안을 만든다.	실제 발송은 권한과 기록이 필요하다.	승인 절차와 실행 기록을 남긴다.
`이 답변이 안전한지 평가해 줘`	자체 점검 문장을 만든다.	평가 기준이 없으면 점검이 기분에 가까워진다.	기준표와 사람 검토를 붙인다.

이 표에서 중요한 점은 LLM이 모든 문제를 혼자 해결한다는 뜻이 아닙니다. LLM은 사용자의 요청을 읽고 산출물을 만들 수 있기 때문에, 어디까지는 문장 생성으로 처리하고 어디부터는 검색, 계산, 승인, 평가로 넘겨야 하는지가 잘 보입니다. Part 6은 이 경계선을 읽는 연습입니다.

따라서 여기서 바로잡을 오해는 세 가지입니다. LLM은 생성형 AI 전체가 아니라 대표 사례입니다. 생성형 AI는 산출물을 만들고 끝나는 기술이 아니라, 사용 장면에서 검토와 보강과 기록이 붙어야 하는 구조입니다. 텍스트 생성도 단순 글쓰기 기능이 아니라 검색, 도구, 평가, 운영 구조와 쉽게 연결되는 실행 흐름입니다.

사례 및 예시¶

다음은 같은 답변을 만들어 달라는 요청처럼 보여도 필요한 구조가 달라지는 예입니다.

요청	먼저 만들 수 있는 산출물	막히는 지점	다음에 붙일 구조
`회의 내용을 세 줄로 요약해 줘`	요약문	입력 안에 근거가 이미 있으면 대체로 프롬프트 조정으로 충분하다.	형식 지시, 길이 제한
`우리 회사 보안 정책을 요약해 줘`	정책 설명문	모델 기억이나 일반 지식으로는 최신 사내 정책을 보장할 수 없다.	문서 검색, 근거 인용
`이 주문의 배송비를 계산해 줘`	계산 설명문	실제 주문 금액, 지역, 쿠폰 조건을 정확히 계산해야 한다.	데이터 조회, 계산 함수
`조건이 맞으면 환불을 처리해 줘`	처리 안내문	실제 상태 변경에는 권한, 승인, 기록이 필요하다.	함수 호출, 승인, 실행 로그

이 표의 네 줄은 앞으로의 Part 6 목차를 미리 압축한 지도입니다. 프롬프트는 산출물의 형식과 맥락을 조정합니다. RAG는 외부 근거를 붙입니다. 도구 사용은 조회와 계산과 실행을 맡습니다. 에이전트와 하네스는 여러 단계를 반복하고 기록으로 남깁니다.

바로 적용해 보면¶

다음 요청을 읽고 프롬프트만으로 먼저 해 볼 일과 구조를 붙여야 할 일을 나누어 보세요.

요청	프롬프트만으로 먼저 해 볼 일	구조를 붙여야 할 일
`이 공지문을 부드럽게 바꿔 줘`	말투, 길이, 독자 수준을 지시한다.	보통은 추가 구조가 없어도 된다.
`오늘 기준 환율로 견적서를 써 줘`	견적서 형식과 말투를 지시한다.	최신 환율 조회와 계산 도구가 필요하다.
`고객에게 쿠폰을 발급하고 안내해 줘`	안내 문장 형식을 지시한다.	쿠폰 발급 권한, 실행 API, 기록이 필요하다.

LLM을 중심 사례로 읽는 이유는 이처럼 경계가 잘 보이기 때문입니다. 텍스트 답변은 시작점이고, 실제 서비스는 그 답변에 근거, 실행, 평가, 기록을 붙이면서 완성됩니다.

연습 및 예제¶

다음 요청을 보고, LLM 산출물만으로 끝내기 어려운 이유를 하나씩 표시해 보세요. 오른쪽 열은 확인 해설입니다.

요청	생성 산출물	추가로 필요한 구조
`우리 회사 최신 요금제를 비교해 줘`	비교 설명	최신 문서 검색
`이번 달 사용량으로 예상 비용을 계산해 줘`	계산 설명	실제 계산 도구
`고객에게 보상 쿠폰을 발급해 줘`	안내 문장	권한 확인과 실행 기록

세 요청 모두 텍스트 답변처럼 보이지만, 필요한 보강 구조는 다릅니다. 이 구분이 있어야 LLM을 단순 채팅 도구가 아니라 생성형 AI 서비스 구조를 읽는 중심 사례로 볼 수 있습니다.

이 구분이 잡히면 LLM을 채팅 화면에서 문장을 만들어 주는 기능으로만 보지 않게 됩니다. LLM은 생성형 AI 전체가 아니라, 생성 산출물과 보강 구조와 운영 기록을 한 흐름으로 읽게 해 주는 대표 사례입니다.

체크리스트¶

LLM이 생성형 AI 전체가 아니라 대표 사례라는 점을 설명할 수 있다.
Part 6이 텍스트 LLM을 중심으로 삼는 이유를 말할 수 있다.
이미지, 음성, 영상 생성과 LLM 사이의 공통점과 범위 차이를 구분할 수 있다.