L12 AI 시스템 & LLM 애플리케이션 입구

분류: Layer 12 - AI 시스템 & LLM 애플리케이션

1. 선행 모델 호출의 한계 — L12의 등장과 해결 구조

L11까지는 토큰화·트랜스포머·모델 평가를 통해 LLM이 입력을 처리하고 출력을 만드는 원리를 배웠다. 하지만 모델을 한 번 호출해 그럴듯한 답을 얻는 것만으로는 최신 근거, 안전한 외부 상태 변경, 예측 가능한 비용·지연, 실패 원인 추적을 보장할 수 없다.

이 선행 한계 때문에 L12가 등장한다. 질문은 “모델이 똑똑한가”에서 끝나지 않는다. 요청과 응답의 계약은 안정적인가, 비용과 지연은 감당 가능한가, 오래된 지식을 어떻게 갱신하는가, 외부 API를 호출해도 안전한가, 품질이 나빠졌을 때 어떻게 알아차리는가를 함께 본다.

해결 구조의 중심은 모델 내부 수학보다 운영 가능한 경계다. API 호출, 프롬프트, 임베딩 검색, RAG(Retrieval-Augmented Generation, 검색으로 외부 근거를 가져와 생성에 붙이는 패턴), 도구 호출, 에이전트 흐름, 보안, 관측성, 평가가 하나의 애플리케이션 아키텍처로 이어진다. 모델은 핵심 엔진이지만, 제품은 모델만으로 만들어지지 않는다.

첫 일반 토픽인 LLM API 기초는 토큰화, 트랜스포머, 추론 비용 같은 L11 개념을 이미 알고 있다고 느껴질 수 있다. 이 문서는 그 내용을 다시 강의하지 않고, L12에 들어갈 때 어떤 렌즈를 들고 보면 되는지 잡아주는 입구다.

2. 이미 알고 있는 것에서 출발하기

이미 해오던 API 제품 개발 감각은 L12의 진입점을 낮춰준다. 다만 이 레이어의 본문은 프론트엔드 비유가 아니라 LLM 시스템 고유의 계약, 검색, 도구 실행, 평가로 빠르게 전환한다.

API 계약: LLM 호출도 요청 본문, 응답 형태, 에러 코드, 요청 제한을 가진 외부 API다. messages, tools, response_format은 낯선 마법이 아니라 계약 필드다. 같은 입력도 sampling(모델이 예측한 확률 분포에서 다음 토큰을 고르는 과정) 설정에 따라 응답이 달라질 수 있다.
스키마와 스트리밍: 타입·JSON Schema(JSON 구조 규칙)·streaming UX 감각은 structured output(구조화된 출력), function calling(함수 호출), TTFT(Time to First Token, 첫 토큰까지 걸린 시간), 중간 로딩 상태 설계로 이어진다.
실패와 피드백 루프: timeout, 429, 부분 실패, 사용자 피드백, 회귀 테스트 경험은 LLM API 재시도, idempotency(멱등성, 반복 적용해도 외부 상태에 미치는 효과가 한 번 적용했을 때와 같은 성질), prompt 평가, RAG faithfulness(검색 근거 충실도), observability(관측성)의 토대가 된다.

즉, L12는 완전히 새 학문으로 들어가는 문이 아니다. 이미 해오던 제품 개발에 “확률적이고 비결정적인 모델”이라는 새 의존성이 들어왔을 때, 그 의존성을 어떻게 길들이는지 배우는 레이어다.

3. 새로 배워야 하는 사고 모델

L12에서는 여섯 가지 질문을 반복해서 던지면 좋다.

첫째, 모델 호출은 어느 계약 안에 갇혀 있는가. 자유 텍스트로 답하게 둘지, JSON schema로 묶을지, 도구 호출로 넘길지에 따라 제품 안정성이 달라진다.

둘째, 비용과 지연은 어디서 생기는가. 입력 토큰, 출력 토큰, context window(한 번의 호출에서 입력과 생성 출력이 보통 함께 사용하는 총 토큰 한도), streaming, caching, 재시도, tool call 횟수가 모두 사용자 경험과 청구 비용에 영향을 준다.

셋째, 모델이 모르는 지식은 어디에서 가져오는가. 고정된 모델 지식만 믿을지, 임베딩 검색과 RAG로 최신 문서를 넣을지, 외부 API와 DB를 tool로 호출할지 결정해야 한다.

넷째, 실패를 어떻게 멈추고 설명하는가. LLM은 그럴듯한 오답, 잘못된 tool 호출, 권한 없는 데이터 노출, 무한 agent loop처럼 조용히 위험해지는 실패 모드를 만든다.

다섯째, 품질을 어떻게 측정하는가. 단순히 “답이 좋아 보인다”가 아니라 latency, cost, retrieval recall(필요한 근거를 검색해 낸 비율), faithfulness(근거 충실도), tool success rate(도구 호출 성공률), 사용자 피드백, 회귀 평가로 봐야 한다. 이때 gold dataset은 사람이 검수한 기대 결과·판정 근거를 가진 버전 관리 평가 데이터셋이다. 모델·prompt·검색 구성이 바뀌어도 같은 기준으로 회귀를 비교하게 해준다.

여섯째, 사람은 어디에 개입하는가. 자동화가 커질수록 승인, 수정, 감사, rollback(되돌리기), human-in-the-loop(HITL, 실행 중 사람의 승인·수정을 넣는 구조)가 제품 신뢰의 일부가 된다.

4. 들어가기 전 최소 선수지식

이 입구와 첫 일반 토픽 LLM API 기초가 공통으로 요구하는 L11 필수 선수는 frontmatter에도 기계 판독 가능한 prerequisites로 적은 content/topics/L11/tokenization-and-embedding.mdx와 content/topics/L11/transformer-and-attention.mdx다. 전자에서는 토큰 비용과 임베딩을, 후자에서는 입력을 한꺼번에 처리하는 prefill, 출력 토큰을 하나씩 만드는 decode, 이전 계산을 저장하는 KV(Key-Value) cache를 먼저 잡는다. 긴 context가 KV cache를 키워 지연과 메모리 사용량을 늘린다는 연결까지만 이해하면 되고, attention 수식 전체를 외울 필요는 없다.
L11 model-evaluation-and-data-quality.mdx는 L12 전체의 입구를 읽기 위한 hard prerequisite가 아니다. Gold dataset은 이 문서에서 짧게 정의하고, LLM 관측성과 평가처럼 실제로 평가 설계가 필요한 후속 토픽의 frontmatter에서 선수 관계를 요구한다. 이 구분 덕분에 레이어 공통 최소 전제와 선택 경로의 심화 전제를 섞지 않는다.
API 호출, JSON schema, timeout, retry, streaming UI, 타입 안정성은 이미 알고 있는 것으로 가져와도 된다. L12는 그 감각을 LLM이라는 비결정적 외부 의존성에 적용한다.
Fan-out 검색 패턴의 진입 관문은 frontmatter 기준 L9 content/topics/L9/distributed-systems-basics.mdx와 L12 RAG 기초이며, 정보 검색의 recall·precision·ranking·deduplication은 외부 선수지식이다. 처음에는 여러 요청을 병렬로 펼치고 합치는 분산 시스템 감각과 검색 결과의 누락·중복만 이해하면 된다.
벡터 검색이 낯설면 처음부터 ANN(Approximate Nearest Neighbor, 근사 최근접 이웃 검색)이나 HNSW(Hierarchical Navigable Small World, 그래프를 따라 가까운 벡터를 찾는 ANN 인덱스) 파라미터를 외우지 않는다. 임베딩과 벡터 운영에서 필요한 근거가 빠지는지, 오래된 문서가 나오는지, 권한 없는 문서가 섞이는지부터 본다.
LLM 관측성과 평가로 들어갈 때는 L6 content/topics/L6/logs-metrics-traces.mdx와 L11 content/topics/L11/model-evaluation-and-data-quality.mdx가 교차 레이어 필수 선수다. 요청 경로를 log·metric·trace로 연결하는 감각과, 평가 데이터·지표가 실제 실패를 측정하는지 판단하는 감각이 여기서 합쳐진다.

5. 이 레이어를 듣는 순서

learning_order는 레이어 안의 추천 읽기 순서이고, prerequisites는 해당 토픽을 이해하려면 먼저 읽어야 하는 실제 선수 문서다. 따라서 번호가 앞선 모든 문서가 자동으로 필수 선수지식이 되는 것은 아니다. 아래 타임라인은 L12의 공통 시스템 흐름인 learning_order 10~100을 보여주며, 선수 관계는 각 문서 frontmatter를 따른다.

L12 핵심 시스템 흐름 (learning_order 10~100)

10. LLM API 기초
모델 호출을 API 계약, 토큰 비용, streaming, structured output, 에러 처리의 관점으로 본다.
20. Prompt Engineering
같은 API 위에서 입력을 어떻게 설계하고, prompt를 코드 자산처럼 관리하며, 회귀를 어떻게 막는지 배운다.
30. 임베딩과 벡터 운영
텍스트를 검색 가능한 벡터로 바꾸고, vector store(벡터 저장소), chunking(문서 분할), hybrid search(키워드·벡터 결합 검색), reranker(후보 재정렬)로 의미 검색을 운영한다.
40. RAG 기초
모델의 고정 지식 한계를 외부 검색으로 보완하고, 출처 인용과 환각 감소를 제품 요구사항으로 다룬다.
45. Fan-out 검색 패턴
복잡한 질문을 여러 하위 검색으로 펼치고, 결과를 병합·재정렬해 recall과 비용을 함께 제어한다.
50. 도구·함수 호출
외부 API·DB를 구조화된 제안으로 호출하고 권한·sandbox(격리 실행)·감사 로그로 실행 경계를 제한한다. 현재 커리큘럼에서는 Fan-out을 선수로 두어 병렬 읽기 경로에서 실행 경계로 확장한다.
60. 에이전트 오케스트레이션
Prompt·RAG·Fan-out·도구 호출을 상태, 반복, 종료 조건과 묶어 제한된 자율성의 다단계 작업으로 만든다.
70. LLM 비용과 지연
앞의 호출 경로 전체를 토큰, 모델 호출 수, tool 왕복, 재시도, tail latency의 비용 구조로 다시 읽는다. P95/P99는 요청의 95%/99%가 각각 해당 시간 이하에 완료되는 지연 백분위다.
80. LLM 보안
Prompt·검색 문서·도구·agent 사이의 신뢰 경계를 확인하고, 권한과 승인으로 실행 피해를 제한한다.
90. LLM 관측성과 평가 (Observability/Evals)
요청 단계를 잇는 trace와 평가 데이터로 품질·비용·지연·도구 성공률을 함께 측정해 앞의 설계 선택을 통합 검증한다.
100. 컨텍스트 엔지니어링 (Context Engineering)
Observability/Evals의 trace와 gold dataset으로 확인한 실패를 기준으로 prompt, 검색 근거, 대화 이력·장기 메모리, tool 결과를 제한된 context 예산 안에서 선택·격리·압축한다.

Fan-out 검색 패턴 → 도구·함수 호출 → 에이전트 오케스트레이션은 이 저장소의 frontmatter가 정한 선수 관계다. Tool Calling 자체가 Fan-out을 기술적으로 반드시 요구하는 일반 법칙은 아니다. 이 커리큘럼은 여러 읽기 요청을 펼치고 합친 뒤 외부 상태 조회·변경으로 경계를 넓히는 차이를 먼저 보도록 둘을 연결했다. 에이전트는 이 검색과 도구 호출을 한 번 실행하는 데서 그치지 않고, 상태와 종료 조건을 가진 반복 흐름으로 묶는다.

비용·지연과 보안도 agent 뒤에만 적용하는 기능이 아니다. API 한 번, 검색 한 번, 도구 한 번마다 계속 발생하는 교차 관점이다. 다만 learning_order 70~80에서 다시 보는 이유는 agent까지 연결한 뒤에야 호출 증폭, 긴 tail latency, 과도한 권한처럼 시스템 전체의 문제가 선명해지기 때문이다. 비용 문서의 필수 선수는 LLM API이고, 보안 문서는 Prompt·RAG·Tool·Agent를 선수로 요구한다는 차이도 이 의미를 반영한다.

관측성과 평가(Observability/Evals)는 새 능력을 하나 더 추가하는 단계가 아니라 앞에서 고른 모델, prompt, 검색, 도구, agent, 비용 전략이 실제 요청에서도 함께 성립하는지 검증하는 단계다. LLM 관측성과 평가(90) → Context Engineering(100)은 단순히 측정 후 읽으면 좋다는 추천이 아니라 이번 커리큘럼이 정한 필수 선수 edge다. trace와 gold dataset으로 어떤 실패가 반복되는지 확인해야 검색 근거·대화 이력·도구 결과 중 무엇을 context에 남기거나 버릴지 근거 있게 판단할 수 있기 때문이다.

작은 예로 사내 지원 assistant가 질문을 세 갈래로 Fan-out 검색한 뒤 티켓 API를 호출한다고 하자. 정상 경로만 세면 질문 분해 모델 1회, 검색 3회, 결과 종합·도구 결정 모델 1회, 티켓 API 1회, 최종 답변 모델 1회로 총 7회 호출(모델 3회·검색 3회·도구 1회)이 생긴다. 티켓 생성은 성공했지만 응답이 timeout되어 agent가 ticket.create를 재시도하면 최소 8회 이상이 된다.

이때 trace에 ticket.create span이 두 개 있다는 사실만으로 멱등성 파괴를 확정할 수는 없다. 재시도가 서로 다른 idempotency key를 사용했다면 중복 방지 계약이 약해졌다는 증거일 뿐이다. 실제 티켓 두 건이 생성되었거나 그에 준하는 외부 효과가 두 번 반영되었다는 증거가 있어야 멱등성 파괴를 확정한다. 반대로 두 호출이 같은 key를 사용하고 두 번째 호출이 기존 티켓 결과를 반환했다면 span은 두 개여도 외부 상태 효과는 한 번이므로 멱등성이 유지된 반례다. 긴 context는 untrusted 문서가 모델에 노출되는 면을 늘린다. Context Engineering으로 검색 결과, 대화 이력, 도구 응답을 선별·격리해 품질·비용·노출 범위를 조절할 수 있지만, context 선별·격리 자체는 실행 보안 경계가 아니다. 권한 검사·승인·sandbox가 side effect를 제한한다.

특히 RAG 기초 → Fan-out 검색 패턴은 read-only 검색 coverage를 넓히는 흐름이고, 이 커리큘럼의 Fan-out 검색 패턴 → 도구·함수 호출 연결은 검색 결과를 읽는 단계에서 현재 상태 조회와 외부 action을 실행하는 경계로 넘어가는 흐름이다. 이때부터 side effect(외부 상태 변경), 승인, idempotency(반복 실행의 외부 상태 효과를 한 번 실행했을 때와 같게 만드는 성질), audit log(감사 로그)가 새 핵심 조건이 된다.

learning_order 110~150은 번호대로 모두 밟는 하나의 선형 심화가 아니라, 실제 prerequisites에 따라 갈리는 선택 경로다.

실행 제어 경로: Agent(60) → 상태 머신·워크플로 그래프(110) → Temporal Durable Execution(120) → HITL 워크플로(130)로 이어진다. 상태 머신은 허용되는 상태와 전이를 정의한다. Temporal은 durable event history를 저장하고 workflow code를 결정적으로 replay해 실패 뒤 실행을 복원한다. HITL은 승인·수정 지점과 감사 기록으로 사람의 판단을 그 실행에 결합한다. 각 문서 frontmatter 기준으로 상태 머신에는 L10 트리·그래프와 L9 설계 원칙이, Temporal에는 L6 Queue·Retry와 L9 분산 시스템·Saga가 실제 선수 관문이다. 상태 머신의 외부 선수는 기본 TypeScript 타입 문법이다. HITL은 이 경로에 더해 LLM 보안(80)도 요구한다.
지식 구조화 경로: 핵심 흐름의 RAG(40) + LLM 관측성과 평가(90) → Context Engineering(100)을 먼저 밟고, Context Engineering(100) + L11 모델 평가·데이터 품질이 온톨로지·역량 모델링(140)에서 합쳐진다. 외부 선수는 기초 데이터 모델링과 도메인 모델링 경험이다. 문서 조각 검색을 도메인 개념·관계·평가 기준으로 구조화할 때 선택한다.
선택 심화 합류점: Psychometrics와 SJT(Situational Judgment Test, 실제 업무 상황에서의 선택·서술 응답으로 판단 역량을 평가하는 검사) 설계(150)는 HITL(130) + LLM 관측성과 평가(90) + 온톨로지·역량 모델링(140) + L11 모델 평가를 선수로 요구한다. 외부 선수는 평균·비율·상관에 대한 기초 통계 직관뿐이다. 요인분석, IRT(문항반응이론), 산업·조직심리학은 선택 심화 맥락이며 필수 선수지식이 아니다. 사람이나 agent의 역량을 신뢰도·타당도가 있는 평가 도구로 측정할 때만 들어가면 되며, 일반 LLM 애플리케이션 구축의 필수 종착점은 아니다.

6. 어렵게 느껴지는 지점과 돌아갈 곳

막힐 때는 먼저 증상을 좁히고, 부족한 전제가 L11의 모델 이해인지 L12의 제품 설계인지 나누면 된다.

6. 어렵게 느껴지는 지점과 돌아갈 곳 비교

토큰, context, 한국어 비용 이야기가 감이 안 온다

보통 부족한 전제: 토큰화와 context window 직관

돌아갈 문서: `content/topics/L11/tokenization-and-embedding.mdx`

prefill, decode, KV cache가 지연과 연결되지 않는다

보통 부족한 전제: 트랜스포머 추론 비용 구조

돌아갈 문서: `content/topics/L11/transformer-and-attention.mdx`

LLM API가 그냥 일반 REST 호출과 같아 보인다

보통 부족한 전제: 호출 간 자동 기억이 없는 대화, 확률 분포에서 다음 토큰을 고르는 sampling, 구조화된 출력

돌아갈 문서: `content/topics/L12/llm-api-basics.mdx`

프롬프트가 감으로 쓰는 문장처럼 느껴진다

보통 부족한 전제: prompt를 계약과 테스트 자산으로 보는 관점

돌아갈 문서: `content/topics/L12/prompt-engineering.mdx`

RAG가 "문서를 붙여 넣는 것"처럼만 보인다

보통 부족한 전제: vector store, chunking, hybrid search, reranker의 역할

돌아갈 문서: `content/topics/L12/embeddings-and-vector-ops.mdx`

답변 품질이 좋아졌는지 판단하기 어렵다

보통 부족한 전제: 평가 데이터, faithfulness, 관측성

돌아갈 문서: `content/topics/L12/llm-observability-and-evals.mdx`

tool calling이 위험한 이유가 잘 안 보인다

보통 부족한 전제: API 권한, 호출 인자 구조 검증, 감사 로그

돌아갈 문서: `content/topics/L12/tool-and-function-calling.mdx`

도구 한 번은 이해했지만 agent 반복 흐름이 감이 안 온다

보통 부족한 전제: 상태, 종료 조건, tool loop의 역할

돌아갈 문서: `content/topics/L12/agent-orchestration.mdx`

어떤 상태와 전이를 허용해야 할지 모르겠다

보통 부족한 전제: 실행 규칙을 상태와 전이로 제한하는 모델

돌아갈 문서: `content/topics/L12/state-machines-workflow-graphs.mdx`

상태·전이는 그렸지만 실패 뒤 실행을 잇는 법이 감이 안 온다

보통 부족한 전제: durable history와 replay 기반 실행 복구

돌아갈 문서: `content/topics/L12/temporal-durable-execution-ai-workflows.mdx`

복구 가능한 실행에 사람 판단을 어디서 넣을지 모르겠다

보통 부족한 전제: 승인·수정 지점과 감사 가능한 인간 개입

돌아갈 문서: `content/topics/L12/human-in-the-loop-ai-workflows.mdx`

대화가 길어질수록 무엇을 남기고 버릴지 모르겠다

보통 부족한 전제: trace·gold dataset으로 실패를 측정한 뒤 context 예산, 출처, 메모리, 압축을 선택하는 기준

먼저 `content/topics/L12/llm-observability-and-evals.mdx`, 이어서 `content/topics/L12/context-engineering-agentic-systems.mdx`

RDF, OWL, SHACL의 역할이 뒤섞인다

보통 부족한 전제: 그래프 표현, 의미 추론, 제약 검증의 경계

돌아갈 문서: `content/topics/L12/ontology-and-competency-modeling-ai-applications.mdx`의 정의(§5)와 선택 기준(§11)

신뢰도, 타당도, 통계 용어가 낯설다

보통 부족한 전제: 측정 오차, 일관성, 점수 해석의 구분

돌아갈 문서: `content/topics/L12/psychometrics-and-sjt-design.mdx`의 정의(§1~4)와 손계산(§3.1, §7, §8.1)

7. 들을 준비가 된 상태

7. 들을 준비가 된 상태 체크

LLM 앱을 "모델 + API 계약 + UX + 운영 지표"의 조합으로 설명할 수 있다
입력과 생성 출력이 보통 context window 한도를 공유하며, 토큰 수가 비용과 latency UX에 영향을 준다는 점을 알고 있다
자유 텍스트 응답과 structured JSON 응답이 제품 안정성에서 어떻게 다른지 말할 수 있다
모델이 모르는 지식은 RAG나 tool calling으로 보완해야 하며, 둘의 실패 모드가 다르다는 점을 받아들일 수 있다
현재 커리큘럼에서 Fan-out 검색이 Tool Calling의 선수로 연결되고, Agent가 검색·도구 호출을 상태 있는 반복으로 묶는다는 관계를 설명할 수 있다
Agent, 비용·지연, 보안이 별도 기능 목록이 아니라 같은 호출 경로를 실행·경제성·신뢰 경계에서 보는 관점임을 안다
관측성과 평가가 앞의 설계 선택을 trace와 gold dataset으로 통합 검증하며, Context Engineering의 필수 선수라는 점을 안다
LLM 기능을 배포할 때 latency, cost, 보안, 평가, 사용자 피드백을 함께 봐야 한다는 것을 안다
막히면 L11의 `tokenization-and-embedding.mdx`, `transformer-and-attention.mdx`로 돌아가면 된다는 것을 안다

8. 이 레이어의 핵심 한 문장

L12 AI 시스템 & LLM 애플리케이션 레이어는 LLM을 “똑똑한 API”로 소비하는 데서 멈추지 않고, 비용과 지연을 예측하고, 외부 지식과 도구를 연결하고, 보안과 평가로 품질을 유지하는 제품 시스템으로 설계하는 법을 배운다.