7부 · 원리에서 실전으로 (시리즈 다리)

← 6부 한계와 그 이유 · 목차 · 다음: 부록 →

여기까지 LLM이 왜 그렇게 작동하는지를 봤습니다. 이제 그 원리가 실전 기법들을 어떻게 설명하는지 정리합니다. 이 부의 한 줄 요약입니다.

실전 기법은 마법이 아니다. 1~6부의 원리에서 곧장 따라 나온다. 모델의 강점을 살리고 한계를 메우는 방향으로 입력(컨텍스트)을 설계하는 일이다.

핵심 통찰 하나를 먼저 새기면 나머지가 쉽습니다. 당신이 모델을 바꿀 수는 없지만(가중치는 고정, 3·4부), 모델이 보는 컨텍스트는 바꿀 수 있다(5부). 거의 모든 실전 기법은 "컨텍스트를 더 좋게 만드는 법"입니다.

flowchart TB
    P["원리(1~6부)"] --> T1["프롬프트<br/>= 컨텍스트를 명확히"]
    P --> T2["맥락 제공<br/>= 컨텍스트에 근거를 담아"]
    P --> T3["RAG<br/>= 최신·전용 지식을 검색해 컨텍스트로"]
    P --> T4["도구<br/>= 못하는 일을 외부에 위임"]
    P --> T5["에이전트<br/>= 위 것들을 스스로 반복 조합"]

    classDef pr fill:#d8b4f8,stroke:#8b5cf6,color:#000
    classDef tech fill:#a8e6e2,stroke:#2ba89e,color:#000
    class P pr
    class T1,T2,T3,T4,T5 tech

7.1 왜 프롬프트가 통하는가

프롬프트(prompt) 는 당신이 모델에 넣는 입력입니다. 같은 모델도 프롬프트에 따라 결과가 크게 달라집니다. 왜일까요?

5부에서 봤듯, 모델은 지금까지의 컨텍스트를 보고 다음 토큰의 확률 분포를 만듭니다. 프롬프트는 바로 그 컨텍스트의 출발점입니다. 명확하고 구체적인 프롬프트는 모델이 "그럴듯하다"고 볼 토큰의 범위를 원하는 쪽으로 좁혀 줍니다. 모호한 프롬프트는 분포를 넓게 열어 두어, 엉뚱한 방향으로 샘플링될 여지를 키웁니다.

이것이 잘 알려진 프롬프트 요령들이 통하는 이유입니다.

비유 — 즉흥 연주자에게 주는 첫 소절
뛰어난 즉흥 연주자에게 첫 몇 마디를 또렷이 주면 그 분위기로 이어 갑니다. 흐릿하게 주면 어디로 튈지 모릅니다. 프롬프트는 그 첫 소절입니다.
이 비유가 깨지는 곳: 연주자는 곡의 의도를 이해하지만, 모델은 패턴을 잇는 것에 가깝습니다. 그래서 "의도를 알아서 헤아리겠지"라고 기대기보다 명시적으로 적는 게 안전합니다.

7.2 왜 맥락(컨텍스트)을 제공하면 효과적인가

질문에 필요한 자료를 프롬프트에 함께 넣어 주면 답이 좋아집니다. 회의록을 붙이고 "요약해 줘"라고 하면, 모델은 기억에서 끌어내는 대신 눈앞의 텍스트를 근거로 답합니다.

원리적으로 이건 두 한계를 동시에 메웁니다. 첫째, 환각(6부)을 줄입니다 — 빈자리를 그럴듯한 추측으로 메우는 대신, 컨텍스트의 실제 내용을 참조합니다. 둘째, 지식 컷오프(4·6부)를 우회합니다 — 학습에 없던 정보라도 컨텍스트에 있으면 쓸 수 있습니다.

다만 5부·6부의 한계도 함께 작동합니다. 컨텍스트 창은 유한하고(너무 긴 자료는 잘림), 중간 소실이 있어(가운데 정보는 놓치기 쉬움), 무작정 많이 넣는 게 능사가 아닙니다. 그래서 중요한 내용을 앞이나 끝에 배치하고, 관련 높은 것만 추려 넣는 게 효과적입니다.

7.3 RAG — 검색을 붙여 지식 한계를 메우기

RAG(검색 증강 생성, Retrieval-Augmented Generation) 는 7.2의 "맥락 제공"을 자동화한 것입니다. 질문이 들어오면, 먼저 외부 지식베이스(문서·DB·웹)에서 관련 자료를 검색해 가져오고, 그것을 프롬프트에 끼워 넣어 모델이 답하게 합니다.

flowchart LR
    Q["질문"] --> R["관련 자료 검색<br/>(외부 지식베이스)"]
    R --> AUG["프롬프트에 자료 추가<br/>(컨텍스트 증강)"]
    Q --> AUG
    AUG --> M["모델이 그 자료를<br/>근거로 답 생성"]
    M --> A["출처 있는 답"]

    classDef q fill:#fff3b0,stroke:#e0a800,color:#000
    classDef proc fill:#a8e6e2,stroke:#2ba89e,color:#000
    classDef out fill:#b9f6ca,stroke:#2e9e5b,color:#000
    class Q q
    class R,AUG,M proc
    class A out

RAG가 정확히 어떤 원리적 한계를 메우는지 보면 명확합니다.

비유 — 도서관 출입증을 받은 박식한 사람
4부에서 본 "지식을 흐릿하게 기억하는 사람"에게 도서관 출입증을 줘서, 답하기 전에 관련 자료를 찾아보게 하는 것입니다. 기억에만 의존하던 사람이 근거를 들고 답하게 됩니다.
이 비유가 깨지는 곳: 출입증이 있어도 엉뚱한 책을 가져오면 답도 틀립니다. RAG의 품질은 검색이 얼마나 정확한지에 크게 좌우되며, 검색이 부실하면 그럴듯한 오답이 그대로 나옵니다.

흔한 오해 깨기
흔히들 "RAG를 붙이면 모델이 더 똑똑해진다"고 생각하지만, 실제로는 모델의 지식 접근을 개선할 뿐 추론 능력 자체를 키우지는 않습니다. 또 검색이 부실하면 RAG도 환각을 막지 못합니다. (자세한 RAG 설계는 후속 시리즈 권에서 다룹니다.)

7.4 도구 — 못하는 일을 외부에 위임하기

6부에서 모델이 산수·정확한 계산·실시간 정보에 약하다고 했습니다. 도구 사용(tool use) 은 이런 일을 모델 바깥의 전용 도구(계산기·검색엔진·코드 실행기·API)에 맡기는 방식입니다. 모델은 "지금 계산기가 필요하다"를 판단해 도구를 부르고, 그 결과를 받아 답에 반영합니다.

flowchart TB
    Q["'1234 × 5678은?'"] --> M["모델: 직접 계산은 약함<br/>→ 계산기 도구 호출 결정"]
    M --> TOOL["계산기 도구<br/>정확히 계산"]
    TOOL --> R["결과: 7,006,652"]
    R --> M2["모델: 결과를 받아<br/>답에 반영"]

    classDef q fill:#fff3b0,stroke:#e0a800,color:#000
    classDef inside fill:#a8e6e2,stroke:#2ba89e,color:#000
    classDef tool fill:#d8b4f8,stroke:#8b5cf6,color:#000
    classDef out fill:#b9f6ca,stroke:#2e9e5b,color:#000
    class Q q
    class M,M2 inside
    class TOOL tool
    class R out

원리적으로 도구는 "그럴듯한 예측"의 약점을 "정확한 실행"으로 대체합니다. 계산은 계산기에, 최신 정보는 검색에 맡기면, 모델은 자기가 잘하는 일—언어를 매끄럽게 엮고 맥락을 다루는 일—에 집중할 수 있습니다.

비유 — 도구 상자를 든 만능 조수
암산은 서툴지만 말은 잘하는 조수에게 계산기와 검색을 쥐여 주는 것입니다. 약점은 도구로 메우고, 강점은 살립니다.
이 비유가 깨지는 곳: 조수는 "언제 어떤 도구가 필요한지"를 늘 옳게 판단하지 않습니다. 도구를 부를 타이밍을 잘못 잡거나, 도구 결과를 잘못 해석할 수 있습니다.

7.5 에이전트 — 스스로 반복하며 조합하기

에이전트(agent) 는 위의 것들(프롬프트·검색·도구)을 모델이 스스로 여러 단계에 걸쳐 반복 조합하게 만든 시스템입니다. 한 번에 답하는 대신, "생각 → 도구 사용 → 결과 관찰 → 다시 판단"의 고리를 돌며 복잡한 작업을 단계적으로 풀어 갑니다.

flowchart LR
    G["목표"] --> THINK["판단: 다음에 뭘 할까"]
    THINK --> ACT["행동: 도구 사용/검색"]
    ACT --> OBS["관찰: 결과 확인"]
    OBS -->|"아직 미완"| THINK
    OBS -->|"완료"| DONE["최종 결과"]

    classDef g fill:#fff3b0,stroke:#e0a800,color:#000
    classDef loop fill:#a8e6e2,stroke:#2ba89e,color:#000
    classDef done fill:#b9f6ca,stroke:#2e9e5b,color:#000
    class G g
    class THINK,ACT,OBS loop
    class DONE done

에이전트는 더 복잡한 일을 해내지만, 그만큼 앞선 모든 한계가 누적됩니다. 단계가 길어질수록 한 단계의 오류(6부)가 다음으로 전파되고(5부 오류 누적), 컨텍스트가 길어져 중간 소실(6부)이 심해지며, 도구 판단 실수도 쌓입니다. 그래서 에이전트의 신뢰성 확보는 여전히 활발한 연구·엔지니어링 과제입니다.

흔한 오해 깨기
흔히들 "에이전트는 사람처럼 자율적으로 계획하고 실행한다"고 생각하지만, 실제로는 매 단계가 여전히 "다음 토큰 예측 + 도구 호출"의 반복입니다. 자율적으로 보이는 행동도 그 기본 동작 위에 쌓여 있으며, 길어질수록 취약해집니다.

7.6 모델을 고를 때 알아야 할 것들

마지막으로, 실제로 모델을 고르거나 쓸 때 도움이 될 관점을 원리와 엮어 정리합니다.

• "더 큰 모델 = 항상 더 나음"이 아니다. 크기 외에 학습 데이터 품질, 사후학습 방식, 용도 적합성이 결과를 좌우합니다. 간단한 일엔 작고 빠른 모델이 더 효율적일 수 있습니다.
• 컨텍스트 창 크기를 본다. 다룰 자료가 길면 창이 큰 모델이 유리하지만, 창이 크다고 중간 소실(6부)이 사라지는 건 아닙니다.
• 지식 컷오프를 확인한다. 최신 정보가 필요하면 검색·도구 연결 여부가 모델 크기보다 중요할 수 있습니다.
• 용도에 맞는 설정. 사실·코드엔 낮은 temperature, 창작엔 높은 temperature(5부)처럼, 같은 모델도 설정으로 성격을 바꿉니다.
• 검증 가능한 일에 강하다. 요약·초안·아이디어 발상처럼 당신이 결과를 확인할 수 있는 일에서 가장 안전하게 쓰입니다. 확인이 어려운 전문적 사실 판단은 항상 교차 검증하세요.

구체적인 제품·모델의 스펙(파라미터 수, 가격, 컨텍스트 길이 등)은 빠르게 바뀌므로 이 안내서에서 수치로 단정하지 않습니다. 사용 시점에 공식 문서를 확인하는 것이 정확합니다.

7부 요약

• 실전 기법의 공통 원리: 모델(가중치)은 못 바꿔도, 모델이 보는 컨텍스트는 설계할 수 있다.
• 프롬프트는 다음 토큰 분포를 원하는 쪽으로 좁힙니다. 구체적·명확하게, 예시·형식·역할을 명시합니다.
• 맥락 제공은 환각과 지식 컷오프를 동시에 메웁니다. 단, 창의 유한성·중간 소실 때문에 중요한 건 앞·끝에 둡니다.
• RAG는 맥락 제공을 자동화해 최신·전용 지식과 출처를 더합니다. 검색 품질이 좌우합니다.
• 도구는 산수·검색 등 약점을 정확한 외부 실행으로 대체합니다.
• 에이전트는 이 모두를 반복 조합하지만, 앞선 한계가 누적되어 신뢰성 확보가 과제입니다.
• 모델 선택은 크기만이 아니라 데이터·사후학습·컨텍스트·컷오프·용도 적합성을 함께 봅니다.

각 기법의 설계 실전(프롬프트 엔지니어링, RAG 구축, 에이전트 설계)은 이 시리즈의 후속 권들에서 다룹니다. 이 안내서에서 잡은 원리가 그 실전의 "왜"를 떠받칩니다.

← 6부 한계와 그 이유 · 목차 · 다음: 부록 →