콘텐츠로 이동

Part 6 마무리

Section ID: P6-summary Version: v2026.07.24

Part 6에서는 생성형 AI를 LLM 중심 사례로 읽었습니다. 핵심은 LLM을 생성형 AI 전체와 동일시하는 것이 아니라, 생성형 AI의 산출물, 입력 표현, 후보 생성, 근거 보강, 도구 실행, 평가, 운영 기록을 한 흐름으로 볼 대표 경로로 삼는 것입니다.

이 Part의 출발점은 모델이 답을 잘하는가가 아니었습니다. 먼저 사람이 받는 산출물을 검토 대상으로 보고, 그 산출물이 토큰과 임베딩을 거쳐 계산 가능한 입력으로 바뀌며, Transformer와 GPT 계열 구조 안에서 다음 후보 선택으로 누적된다는 흐름을 보았습니다. 그 뒤에는 프롬프트, RAG, 벡터 데이터베이스, 도구 사용, 에이전트, MCP, 하네스, 평가, 운영 제약이 왜 따로 떨어진 주제가 아니라 생성형 AI 사용을 검토 가능하게 만드는 장치인지 확인했습니다.

반드시 남겨야 할 감각

  • 생성형 AI의 출력은 검토해야 할 산출물이다.
  • LLM의 생성은 완성 답을 한 번에 꺼내는 일이 아니라 후보 분포와 선택을 반복하는 흐름이다.
  • 텍스트 생성은 토큰과 임베딩을 거쳐 계산 가능한 표현으로 바뀐다.
  • Transformer와 GPT 구조는 문맥을 반영해 다음 후보를 만드는 흐름으로 읽어야 한다.
  • 사전학습, 파인튜닝, 지시 튜닝, 정렬은 각각 배우는 것과 맞추는 것이 다르다.
  • 프롬프트는 입력 지시를 조정하지만 최신성, 근거성, 실행 문제를 모두 해결하지는 않는다.
  • RAG와 벡터 데이터베이스는 답변 전에 외부 근거 후보를 붙이고, 그 후보의 원문과 메타데이터를 함께 보게 한다.
  • 도구 사용과 에이전트는 모델 밖 조회, 계산, 실행을 연결하며, 중간 관찰에 따라 다음 행동을 바꾼다.
  • MCP와 하네스는 모델 능력 자체가 아니라 도구 연결 형식, 실행 기록, 재현성, 검토 가능성을 다루는 관점이다.
  • 좋은 문장과 서비스 가능한 답변은 다르며, 평가, 비용, 지연 시간, 실패 대응, 실행 기록을 함께 봐야 한다.
  • 발전사와 BERT 계열은 GPT 중심 본류를 과장하지 않기 위한 배경 지도다.

오해하기 쉬운 지점

오해 다시 잡아야 할 기준
LLM은 생성형 AI 전체와 같은 말이다 LLM은 이 Part에서 생성형 AI를 설명하기 위한 중심 사례다. 이미지, 음성, 영상 생성까지 모두 같은 구조로 단정하지 않는다.
토큰 ID 숫자가 크면 더 중요한 의미다 token ID는 사전 안의 번호에 가깝고, 의미 비교는 임베딩 벡터와 유사도에서 다룬다.
가까운 벡터는 곧 정답이다 가까운 벡터는 후보를 좁히는 신호다. 최종 답에는 원문, 메타데이터, 최신성, 업무 조건 검토가 필요하다.
프롬프트를 잘 쓰면 대부분 해결된다 최신 문서 확인, 외부 조회, 계산 실행, 권한 승인, 실패 기록은 프롬프트 밖 구조가 필요하다.
자연스러운 답변이면 서비스에 넣어도 된다 서비스 가능한 답변은 품질 기준, 자동 평가, 사람 검토, 비용, 지연 시간, 실패 대응, 실행 기록을 함께 통과해야 한다.
에이전트는 알아서 끝까지 처리하는 자동 실행기다 에이전트는 계획, 행동, 관찰, 종료 조건, 사람 검토 기준이 함께 있어야 안전하게 읽힌다.

Part 6에서 닫은 흐름

흐름 닫은 기준
산출물에서 시작하기 생성형 AI 출력은 결과물이므로 맞고 틀림뿐 아니라 근거, 형식, 위험, 사용 가능성을 함께 검토해야 한다.
입력 표현으로 내려가기 사람이 쓴 문장은 토큰, token ID, 임베딩으로 바뀌며, 이 구분이 비용, 문맥 길이, 검색, 후보 비교를 바꾼다.
생성 구조 읽기 GPT 계열의 긴 답변은 다음 토큰 후보 선택이 반복된 결과이며, 출력 설정은 안정성과 다양성의 균형을 바꾼다.
응답 습관 구분하기 사전학습은 넓은 언어 기반을 만들고, 파인튜닝과 지시 튜닝, 정렬은 목적과 허용 기준에 맞게 응답 습관을 조정한다.
근거와 실행 붙이기 프롬프트 한계를 넘는 순간 RAG, 벡터 데이터베이스, 도구 사용, 에이전트 구조가 필요해진다.
연결과 기록 남기기 MCP는 도구와 자원을 일정한 형식으로 연결하게 돕고, 하네스는 실행 원인과 결과를 다시 볼 수 있게 감싼다.
서비스 상태로 검토하기 LLM 평가는 답변 문장만 보지 않고 자동 평가, 사람 평가, 운영 제약, 실패 대응까지 함께 본다.
배경과 비교로 균형 잡기 발전사와 BERT 계열은 GPT 중심 설명이 모든 언어 모델 설명을 덮지 않게 해 주는 비교 축이다.

프로젝트로 넘겨야 할 기준

Part 7에서는 이 흐름을 실제 프로젝트 산출물로 확인합니다. 이제 중요한 질문은 어떤 생성형 AI 기능을 만들 것인가보다 먼저, 요청, 입력, 근거, 출력, 평가, 실패 대응, 기록을 어떻게 남길 것인가입니다.

Part 7로 넘어가기 전에 다음 질문을 남겨 두면 됩니다.

  • 요청은 한 문장 목표와 입력 단위로 고정되어 있는가?
  • 기준점(baseline) 없이 좋아졌다고 말하고 있지는 않은가?
  • RAG를 쓴다면 답변보다 검색 근거와 실패 후보가 먼저 남는가?
  • 도구나 에이전트를 쓴다면 어떤 도구를 어떤 순서로 호출했고 어디서 멈췄는가?
  • 자동 평가는 무엇을 반복 검사하고, 사람 평가는 어떤 맥락 판단을 맡는가?
  • 비용, 지연 시간, 사용량 제한, 장애 기록은 다음 수정으로 이어질 수 있게 남아 있는가?

이 질문들이 남아 있어야 Part 7의 프로젝트가 코드 실행으로 끝나지 않고, 다시 검토하고 고칠 수 있는 학습 기록으로 닫힙니다.