1장 파운데이션 모델을 활용한 AI 입문

개요

• AI 모델의 성능이 좋아지면서 수행할 수 있는 작업도 늘었다.
• 대규모 언어모델 학습에는 데이터, 컴퓨팅 자원, 전문 인력이 필요하다. 이 비용을 감당할 수 있는 조직은 소수다.
• AI 애플리케이션에 대한 수요는 증가한 반면 진입장벽은 낮아졌다.

1.1 AI 엔지니어링의 부상

개요

• AI 엔지니어링의 변천: 단순 언어 모델 -> 대규모 언어 모델 -> 파운데이션 모델

1.1.1 언어모델에서 대규모 언어모델로

• 언어모델은 예전부터 존재했지만 자기지도학습 덕분에 대규모 언어모델로 성장할 수 있었다.

언어모델

• 언어모델은 하나 이상의 언어에 담긴 통계 정보를 인코딩한다.
• 언어모델의 기본 단위는 토큰이다.

언어의 통계적 특성

언어는 아무 단어가 아무 순서로 나오지 않는다. 앞이 정해지면 다음에 올 것의 확률이 한쪽으로 치우친다. 「내가 좋아하는 색은 ___」 뒤에 「파랑」이 올 확률과 「자동차」가 올 확률은 다르다. 언어모델은 이런 확률의 차이를 통계 정보로 학습한다.

• 문장의 확률분포
  • 언어모델은 P(다음 토큰 | 앞의 토큰들)를 계산한다.
  • 문장 전체의 확률은 조건부확률의 곱으로 분해된다 (chain rule). P(w1…wn) = P(w1)·P(w2|w1)·…·P(wn|w1…wn-1)
  • 그래서 「문장을 생성한다」와 「문장에 점수를 매긴다」가 같은 일이 된다. 생성은 이 분포에서 뽑는 것이고 평가는 이 분포에 넣어 보는 것이다.
• 지프(Zipf)의 법칙
  • 빈도 순위 r인 단어의 출현 빈도가 대략 1/r에 비례한다. 상위 소수 단어가 전체 출현의 대부분을 차지하고 나머지는 긴 꼬리(long tail)로 흩어진다.
  • 어휘를 단어 단위로 고정하면 꼬리 쪽 단어는 학습 중 몇 번 못 보고 처음 보는 단어(OOV)도 계속 생긴다. 이 문제를 줄이기 위해 서브워드 토큰화를 쓴다.
• 중복(redundancy)과 엔트로피
  • 섀넌(1951)은 인쇄 영어의 엔트로피를 문자당 약 1비트 수준으로 추정했다. 문자 하나가 가질 수 있는 경우의 수에 비하면 훨씬 낮다. 다음 글자를 어느 정도 예측할 수 있다는 뜻이다.
  • 그래서 문장 일부가 지워져도 사람은 복원한다. 오타 교정·음성 인식 후보 고르기·번역이 「의미를 이해해서」가 아니라 분포를 알기 때문에 어느 정도 된다.
  • 모델의 예측 난이도는 perplexity로 측정한다. 「다음 토큰을 평균 몇 개 중에서 헷갈리는가」를 나타낸다. 낮을수록 그 텍스트를 잘 예측하는 모델이다.
• 분포 가설
  • "단어는 함께 나타나는 이웃들로 알 수 있다"(Firth). 비슷한 문맥에 등장하는 단어는 비슷한 뜻일 가능성이 높다.
  • 사람이 사전을 써 넣지 않아도 같이 등장하는 패턴만으로 의미의 상당 부분을 학습할 수 있다. 임베딩이 성립하는 이유다.
• 가까운 문맥만으로는 부족하다
  • n-gram은 바로 앞 n-1개만 본다. 「그가 어제 산 책은 … 재미있었다」처럼 멀리 떨어진 의존은 못 잡는다.
  • 문맥을 길게 볼수록 예측이 좋아지는데, n-gram은 n을 키우면 경우의 수가 급격히 늘어난다. 이 한계 때문에 신경망 언어모델과 트랜스포머를 사용한다.

언어모델은 사람이 문법 규칙을 일일이 입력하지 않아도 분포를 학습해 언어 작업을 수행한다. 다만 학습하는 것은 「무엇이 그럴듯한가」이므로 사실과 다른 내용을 생성할 수 있다. (→ 환각 문제)

• 특징 및 개념
  • 토큰: 모델이 텍스트를 다루는 최소 단위다. 문자 하나일 수도, 단어 하나일 수도, 그 사이(서브워드)일 수도 있다. 요즘 모델은 대부분 서브워드를 쓴다.
  • 토큰화: 텍스트를 토큰 열로 쪼개는 과정이다. 쪼개는 규칙은 모델마다 다르므로 같은 문장도 모델이 다르면 토큰 수가 다르다. (과금과 컨텍스트 길이를 계산할 때 영향을 준다.)
  • 어휘(vocabulary): 모델이 아는 토큰 전체의 집합이다. 보통 수만 개 수준이다. 어휘 크기가 곧 출력층의 크기이고 다음 토큰 확률분포는 이 어휘 위에서 정의된다.

토큰화를 사용하는 이유

쪼개는 단위는 문자와 단어 사이 어디든 될 수 있다. 문자와 단어 단위에는 각각 한계가 있어 서브워드로 절충한다.

단위	어휘 크기	시퀀스 길이	의미	모르는 단어
문자	아주 작음	아주 김	거의 없음	문제 없음
단어	빠르게 증가	짧음	있음	UNK로 처리
서브워드	수만 개	중간	어느 정도	조각으로 표현

1. 문자에 비해 의미 있는 수준으로 나눈다 예: 요리하기 → 요리 + 하기
   • 문자 단위는 어휘가 몇십 개로 끝나지만 「ㅇ」 「요」 하나에는 뜻이 없고 문장 하나가 수백 스텝으로 늘어난다.
   • 같은 조각을 포함한 단어들은 학습 결과를 공유한다. 「요리」를 배운 모델은 요리사·요리법·요리하기를 같은 조각 위에서 처리한다.
2. 고유 단어 수 > 고유 토큰 수 → 어휘 크기를 압축한다
   • 한국어처럼 어미가 붙는 말은 단어 단위로 세면 어휘 수가 급격히 늘어난다. 먹다·먹었다·먹었었다·먹겠습니다… 가 전부 다른 단어가 된다.
   • 「먹」+ 어미 몇 개로 쪼개면 훨씬 작은 어휘로 같은 표현을 다룰 수 있다. 지프 법칙에서 설명한 드문 단어도 공통 조각으로 표현한다.
   • 어휘 크기는 출력층의 크기를 결정한다. 어휘가 커지면 파라미터와 매 스텝의 계산량이 같이 커진다.
3. 알려지지 않은 단어를 유추할 수 있다
   • 단어 단위 어휘는 처음 보는 단어를 전부 UNK 하나로 처리한다. 신조어·고유명사·오타가 다 같은 토큰이 되어 정보가 사라진다.
   • 서브워드는 이미 아는 조각들의 조합으로 표현한다. 학습 때 못 본 단어도 쪼개서 문맥 안에서 다룰 수 있다.

서브워드에도 한계는 있다. 잘게 쪼개질수록 시퀀스가 길어지고 비용은 토큰 수로 매겨진다. 영어 위주로 만든 토크나이저에 한국어를 넣으면 같은 뜻에 토큰이 몇 배 더 든다.

• 마스크 언어모델

  • 정의: 누락된 토큰 전후 컨텍스트를 사용해 시퀀스의 어느 위치에서든 누락된 토큰을 예측한다.
  • 예시: "내가 가장 좋아하는 __는 파란색이다" -> 빈칸에 "색상"이 들어가야 한다고 예측한다.
  • 주요 용도: 코드 디버깅, 감정분석
  • 학습 방식: 입력 토큰의 일부(BERT는 15%)를 [MASK]로 가리고 원래 토큰을 맞히게 한다. 빈칸 채우기(cloze) 방식이며 대표 모델은 BERT다.
  • 활용 이유: 문장 전체를 보고 판단하는 작업이기 때문이다. 「이 영화 진짜…」까지만 보면 호평인지 혹평인지 모르고 뒤까지 봐야 정해진다. 코드도 마찬가지로 아래쪽 줄을 봐야 위쪽의 버그가 보인다.
  • 한계: ① 생성에는 적합하지 않다. 빈칸은 채우지만 임의 길이로 이어 쓰는 구조가 아니다. ② 학습 때만 쓰는 [MASK]가 실제 입력엔 없어서 학습/사용 조건이 어긋난다. ③ 한 문장에서 15%만 학습 신호로 쓰므로 같은 데이터에서 얻는 학습 신호가 적다.
  • 활용 분야: 파운데이션 모델의 주류에서는 벗어났고 임베딩·분류·검색 리랭킹 쪽에 남아 있다.

• 자기회귀 언어모델

  • 정의: 이전 토큰들만 보고 시퀀스의 다음 토큰을 예측한다.
  • 예시: "내가 가장 좋아하는 색상은 ___" -> 다음 들어올 토큰은 "파란색, 노란색.."등 색상이 나온다고 예측한다.
  • 주요 용도: 텍스트 생성 분야, 생성형 AI
  • 학습 방식: 뒤를 가린 채(causal mask) 다음 토큰 하나만 맞히게 한다. 대표 모델은 GPT 계열이고 오늘날 LLM은 사실상 전부 이쪽이다.
  • 활용 이유: 학습 목표와 사용 방식이 같기 때문이다. 생성한 토큰을 입력 뒤에 붙이고 다음 토큰을 예측하는 과정을 반복하면(자기회귀) 임의 길이의 글이 나온다. 따로 생성용 장치를 붙일 필요가 없다.
  • 학습 신호: 모든 토큰이 학습 신호가 된다(MLM은 15%). 라벨도 필요 없어서 인터넷 텍스트를 그대로 학습 데이터로 쓸 수 있다. (→ 다음 절 자기지도학습)
  • 한계: ① 뒤 문맥을 못 본다. ② 한 번 뽑은 토큰을 되돌릴 수 없어 오류가 뒤로 누적된다. ③ 토큰을 하나씩 뽑으므로 생성이 느리다.

마스크 언어모델과 자기회귀 언어모델의 비교

	마스크(MLM)	자기회귀(AR)
보는 문맥	앞 + 뒤 (양방향)	앞만 (단방향)
맞히는 것	가려진 자리의 토큰	바로 다음 토큰
학습 신호	가린 일부(~15%)	모든 토큰
잘하는 일	이해 · 분류 · 임베딩	생성
대표	BERT	GPT

둘 다 정답을 사람이 달아주지 않는다. 원래 텍스트의 일부를 가려 문제와 정답을 만든다. 별도 라벨링 없이 대량의 데이터를 사용할 수 있어 언어모델의 규모를 키울 수 있었다. (→ 다음 절 자기지도학습)

자기지도학습

• 지도학습

  • 정의: 레이블이 있는 데이터를 사용해 ML 알고리즘을 학습한다.
  • 주요 흐름: 데이터 레이블 -> 모델 학습 -> 새로운 데이터 예측
  • 예시: 강아지 얼굴 추출 알고리즘, 사기 탐지 모델
  • 단점: 고품질의 데이터 레이블이 필요하기 때문에 비용과 시간이 많이 든다.

• 자기지도학습

  • 정의: 레이블을 사람이 달지 않고 데이터 자체에서 정답을 만들어 학습한다. 텍스트의 일부를 가리면 가려진 그 자리가 곧 정답이다.
  • 주요 흐름: 원문 수집 -> 일부를 가려 (문제, 정답) 쌍을 자동 생성 -> 가려진 토큰 예측 학습 -> 대량 반복
  • 예시: "내가 가장 좋아하는 색상은 파란색이다" 한 문장에서 학습 샘플이 여러 개 나온다.
    • 「내가」 -> 「가장」
    • 「내가 가장」 -> 「좋아하는」
    • 「내가 가장 좋아하는」 -> 「색상은」
    • … 토큰 수만큼 문제가 만들어진다. 사람이 따로 레이블을 달지 않는다.
  • 장점: 레이블 비용이 0이라 인터넷 규모의 텍스트를 그대로 학습 데이터로 쓸 수 있다. 지도학습에 필요한 라벨링 비용과 시간을 줄여 대규모 학습이 가능해졌다.
  • 한계: ① 라벨링 비용은 줄지만 컴퓨팅 비용은 남는다. 병목이 라벨링 인력에서 학습 비용과 GPU로 옮겨간다. ② 데이터의 편향·오류가 그대로 들어온다. ③ 배우는 건 「무엇이 그럴듯한가」이지 「무엇이 사실이고 유용한가」가 아니다 → 사후 정렬(RLHF 등)이 따로 필요하다.

지도학습·자기지도학습·비지도학습 비교

	지도학습	자기지도학습	비지도학습
레이블	사람이 단다	데이터가 스스로 만든다	없다
학습 목표	주어진 정답 맞히기	가려진 자리 맞히기	구조·군집 찾기
병목	라벨링 비용	컴퓨팅 비용	-

자기지도학습은 데이터에서 레이블을 자동으로 만든다. 학습 방식 자체는 지도학습과 같고 정답을 누가 만드느냐만 다르다.

1.1.2 대규모 언어모델에서 파운데이션 모델로

• 파운데이션 모델

  • 정의: 대량의 데이터로 자기지도학습해 만든, 특정 작업에 매이지 않은 범용 기반 모델이다. 하나를 크게 만들어 두고 여러 작업에 적응시켜 쓴다. 여러 응용의 토대(foundation)라는 뜻이다.
  • 이름이 바뀐 이유: 다루는 데이터가 텍스트를 넘어 확장되면서 「언어」모델이라는 말이 좁아졌다. 언어 · 이미지 · 음성을 같은 틀로 다루니 「대규모 언어모델」 대신 「파운데이션 모델」로 부른다.
  • 달라진 점: 예전엔 작업마다 모델을 따로 학습했다. 지금은 모델 하나에 적응 기법(프롬프트 · RAG · 파인튜닝)을 얹어 여러 작업에 활용한다. 작업마다 모델을 학습할 필요가 없어 진입장벽이 낮아졌다.

• 멀티모달 모델

  • 정의: 둘 이상의 데이터 형태를 처리할 수 있는 모델이다.

  멀티모달의 예시

  방향	예	모델
  이미지 + 텍스트 → 텍스트	사진 넣고 「이거 무슨 오류야?」	GPT-4V, Claude, Gemini
  텍스트 → 이미지	문장으로 그림 생성	DALL·E, Midjourney, Stable Diffusion
  음성 → 텍스트	회의 녹음 전사	Whisper
  텍스트 → 음성	TTS 읽어주기	-
  텍스트 → 동영상	문장으로 영상 생성	Sora

  필요한 이유: 사람이 세상을 받아들이는 방식이 원래 멀티모달이다. 차트 · 스크린샷 · 도면에 든 정보는 텍스트로 옮겨 적으면 상당 부분이 손실된다. 입력을 텍스트로만 받으면 그 손실을 사람이 메워야 한다.

• CLIP(이미지 처리)

  • 정의: 텍스트와 이미지를 함께 임베딩하도록 학습한 모델이다.

  임베딩 과정 예시

  1. 데이터: 인터넷에서 (이미지, 캡션) 쌍을 4억 개 수집한다. 사람이 라벨을 달지 않았다. 기존 캡션을 정답으로 활용하는 자기지도학습이다.
  2. 인코더 둘: 이미지 인코더는 사진을 벡터로, 텍스트 인코더는 문장을 벡터로 바꾼다.
  3. 대조학습(contrastive): 한 배치 안에서 짝이 맞는 쌍은 벡터를 가깝게, 어긋난 조합은 멀게 민다.
     • 강아지 사진 ↔ "a photo of a dog" → 당긴다
     • 강아지 사진 ↔ "a photo of a car" → 밀어낸다
  4. 결과: 텍스트와 이미지가 같은 벡터 공간에 놓인다. 서로 다른 형태인데 거리를 잴 수 있게 된다.

  활용 :

  • 제로샷 분류: 후보 라벨을 문장으로 만들어 임베딩하고 이미지 벡터와 가장 가까운 것을 고른다. 그 클래스로 학습한 적이 없어도 된다.
  • 텍스트로 이미지 검색: 질의 문장을 같은 공간에 넣고 가까운 이미지를 찾는다.
  • 이 「같은 공간」이 나중에 텍스트→이미지 생성 모델을 제어하는 데 쓰인다.

모델을 작업에 맞추는 방법

	가중치	비용	맞는 일	안 맞는 일
프롬프트 엔지니어링	안 바꿈	거의 없음	형식 · 톤 · 절차 지시	모델이 모르는 지식
검색증강생성(RAG)	안 바꿈	중간(검색 인프라)	최신 · 사내 지식	말투 · 형식 교정
파인튜닝	바꿈	높음(데이터 + 학습)	행동 · 문체 학습	자주 바뀌는 사실 주입

• 파인튜닝: 모델 가중치를 추가 학습으로 바꾼다. 「무엇을 아는가」보다 「어떻게 행동하는가」를 바꾸는 데 맞다. 도메인 문체, 고정된 출력 형식, 특정 작업의 정확도에 적용한다. 데이터와 비용이 들고 사실이 바뀌면 다시 학습해야 한다.
• 프롬프트 엔지니어링: 모델은 그대로 두고 입력을 바꿔 원하는 동작을 끌어낸다. 지시와 예시(few-shot)를 넣고 출력 형식을 지정한다. 비용이 적고 빠르게 시도할 수 있어 먼저 적용한다.
• 검색증강생성(RAG): 모델 밖의 지식을 검색해 프롬프트에 붙여 넣는다. 질문 → 관련 문서 검색 → 컨텍스트에 삽입 → 답변. 학습 이후의 정보나 사내 문서를 다루는 방법이고 근거 문서를 그대로 들고 있으니 출처를 달 수 있다.

세 방법은 함께 사용할 수 있다. 실무에서는 보통 프롬프트로 시작하고 지식이 부족하면 RAG를 추가한다. 그래도 원하는 동작을 얻기 어려우면 파인튜닝을 적용한다.

1.1.3 파운데이션 모델에서 AI 엔지니어링으로

• AI 엔지니어링
  • 정의: 파운데이션 모델을 기반으로 애플리케이션을 만드는 과정이다.
  • 기존 ML 엔지니어링과 차이: 이미 존재하는 모델을 활용한다. (추후 장에서 자세히 설명)

  AI 엔지니어링을 가속하는 요인

  1. 범용 AI 능력: 파운데이션 모델의 발달로 더 많은 작업을 수행할 수 있다.
  2. AI 투자 증가: 글로벌 빅테크, 주요 선진국에서 집중적인 투자가 이루어지고 있다.
  3. 낮아진 진입장벽: 자연어로 컴퓨터와 대화할 수 있게 되면서 개발의 진입장벽이 낮아지고 있다.

1.2 파운데이션 모델 활용 사례

1.2.1 코딩

1.2.2 이미지 및 동영상 제작

1.2.3 글쓰기

1.2.4 교육

1.2.5 대화형 봇

1.2.6 정보 집계

1.2.7 데이터 체계화

1.2.8 워크플로 자동화

1.3 AI 애플리케이션 기획

1.3.1 활용 사례 평가

• 가장 먼저 해야 할 질문은 "왜 만들고 싶은가"이다.

  개발 동기 평가

  순위	동기	성격	실무 함의
  1순위	AI를 가진 경쟁사에게 밀려 생존에 위협이 되는 경우	방어	늦으면 시장을 잃는다. 완성도보다 속도
  2순위	이익과 생산성 증대의 기회를 포착하려는 경우	공격	기대 효과를 숫자로 잡을 수 있다. ROI로 판단
  3순위	활용법은 불확실하지만 흐름에 뒤처질까 불안한 경우	불안	가장 위험하다

  3순위는 목적이 불분명해 성공 기준을 세우기 어렵다. 결과를 평가하거나 중단을 결정할 근거도 부족해 자원을 낭비하기 쉽다. 이 경우엔 제품을 만들기 전에 「어떤 문제를 풀 것인가」부터 정해야 한다.

• 애플리케이션에서 AI와 사람의 역할

  • AI의 역할: AI가 제품에서 맡을 역할을 세 가지 기준으로 구분한다.

    • 핵심적 또는 보완적: AI가 없어도 동작을 하는가

      • 보완적: 지메일: 메일 자동 완성 기능이 없어도 메일 기능에 문제가 없다.
      • 핵심적: 챗봇: AI가 답변을 생성하지 않으면 기능 자체가 동작하지 않는다.

      실패 허용치와 투자 규모가 달라진다. 보완적이면 틀려도 사용자가 무시하면 그만이라 낮은 정확도로도 출시할 수 있다. 핵심적이면 오류가 제품 기능에 직접 영향을 주므로 품질 기준과 예산이 같이 올라간다.

    • 반응형 또는 선제형: AI가 생성하는 데이터를 언제 활용하는가

      • 반응형: 사용자가 요청할 때 AI가 구동된다. (검색, 챗봇)
      • 선제형: AI가 먼저 데이터를 만들어 두고 사용자의 피드백을 받는다. (추천, 요약 미리 생성)

      요구하는 지연 시간과 낭비되는 비용이 달라진다. 반응형은 사용자가 화면 앞에서 기다리므로 응답 속도가 곧 품질이다. 선제형은 미리 만들어 두니 배치로 느리게 돌려도 되지만 사용하지 않을 결과까지 생성해 비용을 낭비할 수 있다.

    • 동적 또는 정적: 업데이트 주기가 스케줄인가 이벤트인가

      • 동적: 사용자의 피드백·이벤트가 발생할 때마다 업데이트한다.
      • 정적: 일정한 주기(스케줄)에 따라 대규모로 업데이트한다.

      개인화 수준과 필요한 인프라가 달라진다. 동적은 사용자별 상태를 계속 유지해야 하므로 피드백 수집·반영 파이프라인이 필요하다. 정적 방식은 단순하지만 변화를 반영하는 속도가 느리다.

  • 사람의 역할: AI가 낸 결과를 사람이 어디까지 검토하고 책임지는가. 실패 비용이 클수록 사람의 검토가 중요하다.

    • 휴먼 인 더 루프(human-in-the-loop): AI의 의사결정 과정에 사람을 참여시키는 방식이다.

      • 목적: ① 틀린 결과가 그대로 나가는 걸 막고 ② 책임 소재를 사람에게 두며 ③ 사람의 선택이 다시 학습·개선 데이터가 된다.
      • 대가: 사람이 참여하는 만큼 느려지고 인건비가 든다. 그래서 「넣느냐 마느냐」가 아니라 어느 지점에 얼마나 넣느냐의 문제다.

    • 사람의 개입 정도: 완전 수동과 완전 자동 사이의 스펙트럼이다.

      형태	사람의 개입	HITL	예
      사람이 최종 결정	AI는 후보만 내고 사람이 고른다	○	코드 자동완성, 메일 초안
      사람이 검토 후 통과	AI가 만들고 사람이 승인해야 나간다	○	의료 판독 보조, 심사
      사람 없이 자동	결과가 바로 사용자에게 간다	✗	추천, 스팸 필터

      같은 모델이라도 어디에 놓느냐에 따라 요구 정확도가 달라진다. 사람이 뒤에서 걸러주면 틀려도 회수되지만 결과를 바로 전달하면 오류가 사용자에게 직접 영향을 준다.

      사람 없이 자동으로 결과를 전달하는 방식은 HITL에 해당하지 않는다. 틀린 결과를 사용자가 무시해도 되는 용도에 적용한다. (→ 위 「핵심적/보완적」 구분)

• AI 제품 방어 가능성

  • 진입장벽이 낮아진 만큼 경쟁 제품도 쉽게 등장한다. 같은 모델로 비슷한 제품을 만들기 쉽다. 그래서 경쟁 제품과 어떻게 차별화할지도 정해야 한다.

  • 기술력: AI가 고도화·평균화됨에 따라 AI를 활용한 기술력은 차이가 없다.

    • 같은 모델을 모두가 API로 쓴다. 모델 선택만으로는 차별화하기 어렵다. 좋은 모델이 나오면 경쟁사도 다음 날 교체할 수 있다.
    • 차별화할 수 있는 부분은 평가 체계(좋은 답의 기준을 알고 있는가), 데이터 파이프라인, 기존 제품과 얼마나 긴밀하게 연결되는가다.
    • 선발 주자 우위도 짧다. 기술 격차로 버는 시간 동안 데이터나 유통에서 경쟁 우위를 확보해야 한다.

  • 데이터: AI가 사용 가능한 데이터를 먼저 확보할 수 있는가

    • 모델은 살 수 있어도 제품에서 독자적으로 쌓은 데이터는 살 수 없다. 셋 중 가장 오래 유지되는 경쟁 우위다.
    • 데이터 플라이휠: 제품을 쓰면 → 데이터가 쌓이고 → 모델이 좋아지고 → 제품이 좋아져 더 쓰게 된다. 이 과정이 반복되면 후발주자는 같은 데이터를 모을 방법이 없다.

    AI-ready data

    데이터를 많이 보유해도 바로 쓸 수 있는 것은 아니다. AI-ready는 모델이 바로 학습·검색에 넣을 수 있는 상태를 말한다.

    조건	무슨 뜻	안 되어 있으면
    접근 가능	부서별 사일로에 갇혀 있지 않고 권한·경로가 정리됨	있는 줄 알지만 못 꺼낸다
    기계가 읽을 수 있음	스캔 이미지·종이가 아니라 텍스트·구조화 형식	전처리에 많은 시간과 비용이 든다
    정제됨	중복 · 오류 · 구버전이 걸러짐	낡은 사실을 모델이 학습한다
    메타데이터	출처 · 시점 · 권한이 붙어 있음	출처를 못 달고 권한 사고가 난다
    법적으로 사용 가능	동의 · 라이선스 · 개인정보 처리 근거가 있음	나중에 통째로 못 쓰게 된다

    데이터가 많아도 위 조건을 충족하지 못하면 프로젝트의 대부분을 데이터 정리에 써야 한다. 보유량만으로 데이터 우위를 판단하기 어렵다. AI-ready로 만드는 데 걸리는 시간 자체가 진입장벽이 되기도 한다.

  • 유통력: 사용자에게 제품을 전달하는 능력. 대기업 > 중소기업

    • 기존 사용자가 많은 제품에 같은 AI 기능을 추가하면 유통에 유리하다. 구글이 지메일에, MS가 오피스에 붙이는 순간 별도 앱을 쓸 이유가 사라진다.
    • 기술과 데이터가 비슷하면 사용자 접점이 경쟁력을 결정한다. 모델 성능보다 기존 사용자의 접근성이 더 큰 영향을 준다.
    • 그래서 후발·소규모는 대기업이 진출하지 않은 영역을 고른다. 좁은 도메인, 규제가 걸린 업종, 기존 워크플로와의 긴밀한 통합 등이 있다.

1.3.2 기대치 설정

• 제품 개발에 착수하기 전에 성공 지표를 정한다.

  • 나중에 정하면 나온 결과에 맞춰 기준을 끼워 맞추게 된다. 착수 전에 정해야 「이만하면 됐다」와 「접자」를 판단할 수 있다.
  • 정할 것은 무엇을 재는가, 그리고 얼마면 충분한가(임계선)다.

• ① 품질 지표

  • 품질은 여러 지표로 평가하며 제품마다 중요한 지표가 다르다.

    축	묻는 것	재는 법
    정확성 · 사실성	틀린 말을 지어내지 않는가	정답셋 대조, 환각률, 근거 문서와 대조
    관련성	물어본 것에 답했는가	사람 평가, LLM 심판
    형식 준수	JSON 스키마 · 길이 · 말머리를 지키는가	파싱 성공률 (자동)
    일관성	같은 입력에 같은 답이 나오는가	같은 질의 반복 후 분산
    안전성	유해 · 편향 · 민감정보가 새지 않는가	레드팀 셋, 필터 통과율

    제품마다 우선순위가 다르다. 사내 문서 QA는 사실성이 1순위, 파이프라인에 연결한 추출기는 형식 준수가 1순위다. 지표를 구분하지 않고 「정확도」 하나로 평가하면 어떤 부분에 문제가 있는지 파악하기 어렵다.

• ② 정량 / 정성 평가

  • 정량 지표: 자동으로 수치를 산출할 수 있는 지표다. 파싱 성공률, 정답셋 정확도, 지연 시간, 요청당 비용.

    • 장점: CI에 연결해 성능이 떨어졌는지 바로 확인할 수 있다.
    • 한계: 수치로 정의한 항목만 평가한다. 「답이 맞긴 한데 쓸모없다」 같은 문제는 잡기 어렵다.

  • 정성 지표: 사람의 판단이 필요한 지표다. 톤이 맞는가, 읽을 만한가, 실제로 도움이 됐는가.

    • 수집: 사용자 피드백(긍정/부정 평가), 전문가 리뷰, 사용자 인터뷰, A/B 테스트.
    • 한계: 느리고 비싸고 사람마다 다르다.

  • 정성 평가에 기준을 정하면 정량 평가로 확장할 수 있다.

    1. 루브릭을 먼저 쓴다: 「좋은 답」의 조건을 문장으로 고정한다. 기준이 없으면 평가자마다 다른 항목을 평가한다.
    2. 샘플을 사람이 채점한다: 수십~수백 건. 이 결과를 기준점(골든셋)으로 삼는다.
    3. LLM 심판(LLM-as-judge)을 붙인다: 같은 루브릭으로 모델이 채점하게 하고 사람 채점과 얼마나 일치하는지 먼저 검증한다.
    4. 일치하면 그때부터 자동으로 돌린다. 사람 채점과의 일치율을 주기적으로 다시 확인한다.

    순서를 건너뛰고 LLM 심판부터 붙이면, 채점의 신뢰도를 확인하지 않은 채 평가 결과를 쌓게 된다.

• ③ 기술 / 비기술 지표

  • 기술 지표: 시스템이 안정적으로 동작하는지 측정한다.

    지표	뜻
    TTFT (time to first token)	첫 글자가 나오기까지. 체감 속도에 영향을 준다
    TPOT (time per output token)	토큰 하나당 시간. 긴 답의 속도
    전체 지연 시간	요청부터 완료까지
    처리량	초당·분당 처리 요청 수
    요청당 비용	입력·출력 토큰 × 단가
    가용성 · 에러율	외부 API 장애 · 타임아웃 · 스키마 실패

  • 비기술(사업) 지표: 제품이 사업에 기여한 정도를 측정한다. 채택률, 재사용률, 작업 시간 단축, 자동 해결률(사람에게 안 넘어간 비율), 전환율, 만족도.

  • 기대치를 정할 때는 기술 지표와 사업 지표를 연결한다. 지연이 2초에서 1초가 됐다는 말만으로는 투자 효과를 판단하기 어렵다. 「1초가 되면 이탈이 몇 % 준다」까지 연결해야 투자 여부를 판단할 수 있다.

기대치 설정 시 고려할 점

1. 출시할 수 있는 기준을 정한다. 목표는 「정확도를 높인다」가 아니라 「정확도 X% 이상, 지연 Y초 이하면 출시」처럼 숫자와 부등호로 적혀야 한다.
2. 품질 · 비용 · 지연은 서로 맞바꾼다. 큰 모델을 쓰면 품질은 오르고 비용과 지연은 나빠진다. 세 지표를 모두 최대로 만족시키기 어려우므로 무엇을 포기할지를 착수 전에 정한다.
3. 100% 정확도를 기대하기는 어렵다. 확률 모델이라 틀린 출력이 반드시 섞인다. 그래서 「틀리지 않게 하는 법」이 아니라 「틀렸을 때 어떻게 되는가」를 같이 설계해야 한다. (→ 위 휴먼 인 더 루프)

1.3.3 마일스톤 계획

• 계획은 목표치와 현재 구현·모델 성능의 차이를 기준으로 세운다.

  • 목표치는 1.3.2에서 그은 임계선이고 현재 위치는 현재 프롬프트만으로 얻는 점수다. 둘 다 수치로 확인해야 필요한 개선 정도를 알 수 있다.
  • 현재 성능을 모르면 일정을 잡기 어렵다. 비용이 가장 적게 드는 프롬프트부터 적용해 기준 성능을 측정한다.

• 데모는 짧은 시간에 만들 수 있지만 제품 개발에는 몇 달, 몇 년이 걸릴 수 있다.

  • 차이는 실패 대응에 있다. 데모는 되는 경우만 보여주면 되고 제품은 안 되는 경우를 다 감당해야 한다.
  • 데모는 최선의 경우를 보여주지만 제품은 최악의 경우도 견뎌야 한다.
  • 그래서 마지막 구간에 전체 시간의 대부분이 든다. 80%까지는 며칠, 남은 20%에 몇 달이 간다. 데모의 속도로 제품 일정을 잡으면 실제 개발 기간과 차이가 생긴다.

• 마일스톤 구분

  단계	하는 일	끝났다는 기준
  1. 초기 성능 확인	프롬프트만으로 데모	현재 점수가 숫자로 나옴
  2. 실패 수집	안 되는 케이스를 모음	실패 유형이 분류됨
  3. 평가 체계	골든셋 + 자동 채점	고쳤는지 아닌지 판별 가능
  4. 개선	RAG · 파인튜닝 · 프롬프트 손질	임계선 도달
  5. 운영	모니터링 · 피드백 회수	지표가 유지됨

  4번 개선에 앞서 3번 평가 체계가 필요하다. 평가 체계가 없으면 수정의 효과를 확인하기 어렵다.

• 마일스톤마다 계속할지 접을지(go/no-go)를 정해 둔다. 「언제 완성되나」보다 「어디서 멈출지」가 실제로 필요한 결정이다.

• 외부 모델의 성능은 직접 통제할 수 없다. 개선 시점도 제공사가 정하고 반대로 다음 모델이 나와서 우리가 몇 달 들인 문제가 해결되기도 한다. 일정에도 이 불확실성을 반영한다.

1.3.4 유지보수

AI 제품은 코드를 수정하지 않아도 모델, 데이터, 법·규제의 변화에 영향을 받는다. 이 변화를 고려해 유지보수 계획을 세운다.

• AI 기술의 변화 속도를 고려해 제품 유지보수 방안을 마련한다.

  • 모델 단종(deprecation): 제공사가 모델 지원을 종료하면 다른 모델로 교체해야 한다. 우리 일정과 무관하게 날짜가 정해진다.
  • 같은 프롬프트가 새 모델에서 다르게 동작한다. 그래서 모델 버전을 고정(pin)해 두고 바꿀 때는 골든셋으로 회귀 검증한 뒤에 교체한다. 검증 없이 바꾸면 품질 변화를 확인하기 어렵다.
  • 조용한 성능 저하: 입력 분포가 바뀌면(사용자·용어·문서가 바뀌면) 에러 없이 품질만 떨어진다. 오류가 발생하지 않아 모니터링 없이는 알아차리기 어렵다.
  • 새 모델이 나오면 유지보수가 줄어들 수도 있다. 다음 모델이 더 싸고 좋아서 우리가 몇 달 들여 만든 우회 로직이 통째로 필요 없어지기도 한다. 「지금 만드는 것 중 무엇이 곧 쓸모없어질까」를 고려해 설계한다.

• AI 관련 법안과 규제에도 대비해야 한다.

  • 고지 의무: AI가 만든 결과임을 알려야 하는 경우가 늘어난다.
  • 개인정보: 프롬프트에 개인정보가 섞이면 외부 API 호출이 곧 제3자 제공·국외 이전이 된다. 「그냥 API 쓰는 것」이 아니다.
  • 학습 데이터의 출처·저작권: 나중에 못 쓰게 되면 그 데이터를 사용한 제품에도 영향을 준다.
  • 설명·추적 가능성: 「왜 그 답이 나왔는가」를 뒤에서 재구성할 수 있어야 한다.
  • 대비 방법: 나중에 붙이기 어려운 것부터 처음에 넣는다. 입력·출력·모델 버전 로그, 데이터 출처, 동의 이력을 기록한다. 기능은 나중에 붙여도 되지만 지나간 기록은 소급해서 만들 수 없다.

• 데이터 인프라의 변화도 고려한다.

  • 벤더 종속: 특정 제공사 API에 강하게 의존하면 갈아타기 어렵다. 호출부를 얇은 레이어로 감싸 두면 교체 비용이 줄어든다.
  • 비용 구조가 계속 바뀐다: 토큰 단가가 내려가고 더 싼 모델이 나온다. 지금 최적인 구성이 반년 뒤에는 달라진다.
  • 임베딩·벡터 DB: 임베딩 모델을 바꾸면 기존 벡터를 전부 다시 만들어야 한다. 규모가 커진 뒤에는 작업량이 많으므로 교체 계획을 미리 잡아 둔다.
  • 평가·모니터링 자체가 인프라다: 골든셋, 자동 채점, 프롬프트 버전 관리, 로그 수집. 제품 기능이 아니라서 미뤄지기 쉬운데, 없으면 모델이나 인프라 교체의 영향을 판단하기 어렵다.

변경 대상별 관리 방법

바뀌는 것	관리 방법
모델	버전 고정 + 골든셋 회귀 검증
입력 분포	품질 모니터링 · 사용자 피드백 회수
법 · 규제	로그 · 출처 · 동의 이력 (소급 불가)
제공사 · 단가	호출부 추상화
임베딩	재색인 절차

1.4 AI 엔지니어링 스택

• AI 엔지니어링의 급격한 성장은 FOMO를 불러일으켰다. 새로운 기술을 따라 적용하기에 앞서 기본 원리를 이해하고 활용하는 능력이 중요하다.
• AI 엔지니어링은 ML 엔지니어링을 바탕으로 발전했다. ML 엔지니어링의 원리를 이해하면 AI 엔지니어링에도 적용할 수 있다.

1.4.1 AI의 세 가지 계층

• AI 애플리케이션도 결국 이전 애플리케이션처럼 비즈니스 문제를 해결해야 한다.

• 비즈니스 지표와 ML 지표를 상호 연계하는 것도 여전히 중요하다. (→ 1.3.2 ③ 기술/비기술 지표)

• AI 제품은 세 가지 계층으로 나눈다. 각 항목은 1.4.2에서 자세히 다룬다.

  계층	하는 일	구성
  애플리케이션 개발	모델은 가져다 쓰고 모델 바깥에서 제품을 만든다	AI 인터페이스 · 프롬프트 엔지니어링 · 컨텍스트 구성 · 평가
  모델 개발	모델 자체를 만들고 손본다	모델링과 학습 · 데이터셋 엔지니어링 · 추론 최적화 · 평가
  인프라	애플리케이션과 모델의 실행을 지원한다	컴퓨팅 관리 · 데이터 관리 · 모델 서빙 · 모니터링

  무게중심이 모델 개발 → 애플리케이션 개발로 옮겨왔다. 파운데이션 모델을 사용할 수 있어 모델을 만드는 대신 가져다 쓰고 대부분의 AI 엔지니어는 애플리케이션 개발을 맡는다. (→ 맨 위 개요 「진입장벽이 낮아졌다」)

계층별 평가와 개선 순서

1. 평가가 두 층에 모두 있다. 평가의 목적은 다르다. 모델 개발의 평가는 「이 모델이 얼마나 똑똑한가」, 애플리케이션 개발의 평가는 「이 답이 우리 사용자에게 쓸모 있는가」. 벤치마크 1등 모델도 제품의 요구사항을 충족하지 못할 수 있다.
2. 위로 갈수록 싸고 빠르고 아래로 갈수록 비싸고 느리다. 개선은 애플리케이션 계층부터 시도한다. 프롬프트로 안 되면 컨텍스트를, 그래도 안 되면 모델을 수정한다. (→ 1.1.2 프롬프트 → RAG → 파인튜닝과 같은 원리)

1.4.2 AI 엔지니어링 대 ML 엔지니어링

• AI 엔지니어링과 ML 엔지니어링의 차이

  • 전통적인 ML에서는 파운데이션 모델 없이 필요한 모델부터 직접 학습한다.
  • AI 엔지니어링이 더 많은 컴퓨팅 자원을 사용하고 지연 시간도 길다. 그만큼 추론 최적화가 중요하다.
  • AI 엔지니어링은 개방형 출력을 생성할 수 있는 모델을 다룬다. 출력은 유연하지만 평가 기준을 더 세밀하게 정해야 한다.

  	ML 엔지니어링	AI 엔지니어링
  시작점	데이터 모아 모델부터 만든다	이미 있는 모델을 가져다 쓴다
  주요 개발 대상	모델 (가중치)	모델 바깥 (입력 · 컨텍스트 · 제품)
  다루는 데이터	정형	비정형 (텍스트 · 이미지 · 음성)
  출력	닫혀 있다 (분류 · 회귀)	열려 있다 (자유 생성)
  평가	정답과 대조하면 끝	정답이 하나가 아니다: 별도 체계 필요
  비용 병목	학습	추론 (매 요청마다 돈이 나간다)

  큰 차이는 평가에 있다. 분류 모델은 맞았나 틀렸나로 끝나지만 생성 모델은 「맞는 답」이 여러 개이며 「틀린 답」도 그럴듯해 보인다. 그래서 AI 엔지니어링에서는 평가 체계를 만드는 것 자체가 일이다.

• 애플리케이션 개발

  ML 엔지니어링에는 이 층이 거의 없었다. 모델을 직접 만들었으니 고칠 곳도 모델이었다. 모델을 직접 바꾸기 어려워지면서 평가, 입력 설계, 인터페이스 개발이 중요해졌다.

  • 평가

    • 모델의 결과와 기대 결과의 차이를 측정한다.
    • 평가가 어려운 이유
      • ML은 정답셋과 대조하면 끝났다(정확도 · F1). 생성은 맞는 답이 여러 개고 틀린 답도 그럴듯해 보인다.
      • 출력 공간이 열려 있어 전수 검증이 안 된다. 가능한 입력을 모두 예상하기도 어렵다.
      • 외부 모델의 내부는 확인하기 어렵다. 출력만 보고 판단해야 한다.
    • 평가의 역할도 달라진다. ML에서 평가는 학습의 부산물이었지만 AI 엔지니어링에서는 개발의 전제다. 평가 체계가 없으면 프롬프트를 고쳐도 좋아졌는지 알 수 없다. (→ 1.3.2 ②, 1.3.3 3단계)

  • 프롬프트 엔지니어링 및 컨텍스트 구성

    • 모델 가중치를 변경하지 않고 입력만으로 AI 모델에서 원하는 동작을 이끌어낸다.
    • ML 엔지니어링에 대응물이 없는 층이다. 모델을 못 바꾸니 입력으로 동작을 제어하는 방법을 쓰게 됐다.
    • 가중치를 안 건드리므로 비용이 적게 들고 빠르게 적용하거나 되돌릴 수 있다. 그래서 먼저 시도한다.
    • 컨텍스트 구성에도 많은 작업이 필요하다. 검색 결과 · 대화 이력 · 도구 실행 결과 중 무엇을 얼마나 넣을지 고른다. 컨텍스트 길이는 한정돼 있고 비용은 길이에 비례한다.
    • 관리: 프롬프트도 코드처럼 관리해야 한다. 버전 관리와 회귀 테스트가 필요하다. 모델이 바뀌면 같은 프롬프트가 다르게 동작한다. (→ 1.3.4)

  • AI 인터페이스

    • 최종 사용자가 AI 애플리케이션과 상호작용할 수 있는 인터페이스를 만든다.
    • ML 모델은 추천 점수나 스팸 필터처럼 제품 내부에서 동작하는 경우가 많았다. 사용자는 모델을 직접 만나지 않았다. 지금은 사용자가 모델과 직접 대화하므로 인터페이스가 곧 제품이다.
    • 인터페이스 설계 시 고려할 점
      • 오류 가능성 표시: 출처 표시 · 확신 정도 · 「확인이 필요합니다」. 너무 단정적으로 보여주면 사용자가 검증을 안 한다.
      • 수정 기능: 재생성 · 부분 수정 · 되돌리기. 한 번에 맞히는 것보다 빨리 고치게 하는 것이 체감 품질을 더 크게 바꾼다.
      • 응답 대기: 스트리밍으로 첫 글자를 먼저 내보낸다. (→ 1.4.2 추론 최적화)
      • 피드백 수집: 긍정/부정 평가, 채택 여부, 수정 이력. 다음 개선에 쓸 데이터가 된다. 인터페이스가 데이터 수집 장치이기도 하다.

• 모델 개발

  • 모델링과 학습

    • 모델 아키텍처를 설계하고 학습·파인튜닝한다.
    • ML 지식이 필수적이다. ML 알고리즘, 신경망 아키텍처, 모델 학습 과정을 이해해야 한다.

    학습, 사전학습, 파인튜닝 및 사후학습의 차이점

    넷은 별개의 기술이 아니라 모델 하나가 거쳐 가는 순서다. 「학습(training)」은 가중치를 바꾸는 모든 단계를 묶어 부르는 말이고 사전학습, 사후학습, 파인튜닝이 여기에 포함된다.

    무작위 초기화 → [사전학습] → 베이스 모델 → [사후학습] → 출시된 모델 → [파인튜닝] → 우리 모델
                                                                                 ↑
                                                           [프롬프트 엔지니어링]: 가중치를 안 건드림
    

    • 사전학습(pre-training): 무작위 초기화에서 시작해 대량의 비라벨 데이터로 자기지도학습한다. 이 중 비용이 가장 높고 소수 조직만 한다. 결과물인 베이스 모델은 「다음 토큰 예측」만 할 줄 알고 지시는 따르지 못한다.
    • 사후학습(post-training): 베이스 모델이 지시를 따르고 유용한 답을 생성하도록 학습하는 단계다. 보통 두 과정으로 나눈다. ① 지도 파인튜닝(SFT): 「지시 → 응답」 쌍으로 대화하는 법을 가르친다. ② 선호 정렬(RLHF · DPO): 사람이 선호하는 답을 생성하도록 조정한다. 제공사가 출시 전에 한다.
    • 파인튜닝(fine-tuning): 출시된 모델을 우리 문제에 맞추는 추가 학습이다. 가중치를 바꾸지만 사전학습보다 데이터·비용이 훨씬 적다.
    • 프롬프트 엔지니어링: 가중치를 전혀 안 바꾼다. 입력만 설계한다. 가장 싸고 즉시 되돌릴 수 있다.

    용어 구분: 사후학습도 기법상으로는 파인튜닝이다. 나누는 기준은 기법이 아니라 누가 무엇을 위해 하느냐다. 제공사가 출시 전에 범용으로 하면 사후학습, 사용자가 자기 문제에 맞추면 파인튜닝으로 구분한다.

    	시작점	가중치	데이터	비용	누가
    사전학습	무작위	바꿈	수조 토큰	최고	소수 조직
    사후학습	베이스 모델	바꿈	수만~수십만 건	높음	모델 제공사
    파인튜닝	출시 모델	바꿈	수백~수천 건	중간	사용자
    프롬프트 엔지니어링	출시 모델	안 바꿈	0~수십 건(예시)	거의 없음	사용자

  • 데이터셋 엔지니어링

    • 모델의 학습과 조정에 필요한 데이터를 선별·생성하고 라벨링한다.

    • ML 엔지니어링은 정형 데이터를 AI 엔지니어링은 비정형 데이터를 많이 다룬다.

    • 다루는 데이터에 따라서 모델 개발의 중점 데이터셋이 다르다.

    • 주요 작업: 데이터 수집보다 선별·중복 제거·품질 관리에 집중한다. 인터넷 텍스트는 이미 많아 어떤 데이터를 제외할지가 성능에 영향을 준다.

    • 데이터 품질: 파인튜닝은 잘 만든 수백~수천 건이 잡음 섞인 수십만 건보다 낫다. 라벨 하나가 잘못되면 모델이 그걸 배운다.

    • 합성 데이터: 모델로 학습 데이터를 만들어 쓰는 방법이다. 라벨 비용을 줄이지만 만든 모델의 편향과 오류가 그대로 상속된다.

      데이터 양: 모델 학습 > 파인튜닝 > 프롬프트 엔지니어링

      오른쪽으로 갈수록 데이터도 비용도 줄고 되돌리기 쉬워진다. 그래서 오른쪽부터 시도한다.

  • 추론 최적화

    • 모델 실행에 드는 비용과 시간을 줄인다.
    • 최적화가 필요한 이유: 모델이 크고 토큰을 하나씩 순서대로 뽑는다(자기회귀). 비용은 학습할 때뿐 아니라 요청마다 나간다. 사용자가 늘수록 비용이 비례해서 늘어난다.
    • 주요 기법
      • 양자화: 가중치 정밀도를 낮춰(fp16 → int8/int4) 메모리와 계산을 줄인다.
      • 증류(distillation): 큰 모델의 출력을 흉내 내도록 작은 모델을 학습시킨다.
      • 캐싱: 반복되는 앞부분(시스템 프롬프트 등)의 계산 결과를 재사용한다.
      • 배칭: 여러 요청을 묶어 한 번에 처리해 처리량을 올린다.
      • 라우팅: 쉬운 요청은 작은 모델로, 어려운 것만 큰 모델로 보낸다.
      • 스트리밍: 총 시간은 그대로여도 첫 글자를 먼저 내보내 체감 속도를 바꾼다.
    • 측정 지표: TTFT · TPOT · 처리량 · 요청당 비용 (→ 1.3.2 ③ 기술 지표)
    • 양자화·증류에는 품질 저하가 따른다. 1.3.2에서 그은 임계선이 허용할 수 있는 품질 저하의 기준이 된다.

1.4.3 AI 엔지니어링 대 풀스택 엔지니어링