L12 AI 시스템 & LLM 애플리케이션 입구
L12 AI 시스템 & LLM 애플리케이션 입구
섹션 제목: “L12 AI 시스템 & LLM 애플리케이션 입구”분류: Layer 12 - AI 시스템 & LLM 애플리케이션
1. 이 레이어는 무엇을 가능하게 하나
섹션 제목: “1. 이 레이어는 무엇을 가능하게 하나”L12는 LLM을 한 번 호출해 답을 받는 실험을, 사용자가 계속 믿고 쓸 수 있는 제품 시스템으로 바꾸는 법을 다룬다. 여기서 중요한 질문은 “모델이 똑똑한가”에서 끝나지 않는다. 요청과 응답의 계약은 안정적인가, 비용과 지연은 감당 가능한가, 오래된 지식을 어떻게 갱신하는가, 외부 API를 호출해도 안전한가, 품질이 나빠졌을 때 어떻게 알아차리는가를 함께 본다.
그래서 L12의 중심은 모델 내부 수학보다 운영 가능한 경계다. API 호출, 프롬프트, 임베딩 검색, RAG, 도구 호출, 에이전트 흐름, 보안, 관측성, 평가가 하나의 애플리케이션 아키텍처로 이어진다. 모델은 핵심 엔진이지만, 제품은 모델만으로 만들어지지 않는다.
첫 일반 토픽인 LLM API 기초는 토큰화, 트랜스포머, 추론 비용 같은 L11 개념을 이미 알고 있다고 느껴질 수 있다. 이 문서는 그 내용을 다시 강의하지 않고, L12에 들어갈 때 어떤 렌즈를 들고 보면 되는지 잡아주는 입구다.
2. 이미 알고 있는 것에서 출발하기
섹션 제목: “2. 이미 알고 있는 것에서 출발하기”프론트엔드와 플랫폼 실무에서 이미 익숙한 감각은 L12에서 큰 자산이 된다.
- API 계약: LLM 호출도 결국 요청 본문, 응답 형태, 에러 코드, 요청 제한을 가진 외부 API다.
messages,tools,response_format은 낯선 마법이 아니라 계약 필드다. - 구조화된 JSON: 타입과 스키마로 화면 상태를 안정화하던 경험은 structured output, function calling, tool schema 설계로 이어진다.
- 스트리밍 UX: 긴 응답을 기다리게 두지 않고 부분적으로 보여주는 감각은 LLM의 streaming, TTFT, 중간 로딩 상태 설계와 직접 연결된다.
- 오류와 재시도: timeout, 429, 500, 부분 실패를 다뤄본 경험은 LLM API 재시도, idempotency, fallback provider, tool 실행 실패 처리의 토대다.
- 상태처럼 느껴지는 UX와 stateless 요청: 사용자는 대화를 이어간다고 느끼지만 API는 매번 독립 호출일 수 있다. 이 차이는 chat history, context window, memory, RAG 설계에서 계속 등장한다.
- 제품 피드백 루프: 사용자 반응, A/B, 회귀 테스트를 본 경험은 prompt 평가, RAG faithfulness, LLM observability로 확장된다.
즉, L12는 완전히 새 학문으로 들어가는 문이 아니다. 이미 해오던 API 제품 개발에 “확률적이고 비결정적인 모델”이라는 새 의존성이 들어왔을 때, 그 의존성을 어떻게 길들이는지 배우는 레이어다.
3. 새로 배워야 하는 사고 모델
섹션 제목: “3. 새로 배워야 하는 사고 모델”L12에서는 여섯 가지 질문을 반복해서 던지면 좋다.
첫째, 모델 호출은 어느 계약 안에 갇혀 있는가. 자유 텍스트로 답하게 둘지, JSON schema로 묶을지, 도구 호출로 넘길지에 따라 제품 안정성이 달라진다.
둘째, 비용과 지연은 어디서 생기는가. 입력 토큰, 출력 토큰, context 길이, streaming, caching, 재시도, tool call 횟수가 모두 사용자 경험과 청구 비용에 영향을 준다.
셋째, 모델이 모르는 지식은 어디에서 가져오는가. 고정된 모델 지식만 믿을지, 임베딩 검색과 RAG로 최신 문서를 넣을지, 외부 API와 DB를 tool로 호출할지 결정해야 한다.
넷째, 실패를 어떻게 멈추고 설명하는가. LLM은 그럴듯한 오답, 잘못된 tool 호출, 권한 없는 데이터 노출, 무한 agent loop처럼 조용히 위험해지는 실패 모드를 만든다.
다섯째, 품질을 어떻게 측정하는가. 단순히 “답이 좋아 보인다”가 아니라 latency, cost, retrieval recall, faithfulness, tool success rate, 사용자 피드백, 회귀 평가로 봐야 한다.
여섯째, 사람은 어디에 개입하는가. 자동화가 커질수록 승인, 수정, 감사, rollback, human-in-the-loop가 제품 신뢰의 일부가 된다.
4. 들어가기 전 최소 선수지식
섹션 제목: “4. 들어가기 전 최소 선수지식”- 토큰이 무엇이고 왜 비용 단위가 되는지 감이 없다면
content/topics/L11/tokenization-and-embedding.md의 토큰 비용, context window, 임베딩 정의 부분을 먼저 본다. L12에서는 이를 수학보다 비용 견적과 검색 품질의 언어로 다시 사용한다. - 트랜스포머의 attention 수식이 완전히 편하지 않아도 괜찮다. 다만 prefill, decode, KV cache, long-context 비용이 왜 지연과 메모리 문제로 이어지는지 막히면
content/topics/L11/transformer-and-attention.md로 돌아간다. - API 호출, JSON schema, timeout, retry, streaming UI, 타입 안정성은 이미 알고 있는 것으로 가져와도 된다. L12는 그 감각을 LLM이라는 비결정적 외부 의존성에 적용한다.
- 벡터 검색이 낯설면 처음부터 ANN 알고리즘을 외우려 하지 말고, “텍스트를 의미 좌표로 바꾸고 가까운 문서를 찾는다”는 정도만 잡고 들어간다. 세부 운영은
content/topics/L12/embeddings-and-vector-ops.md에서 다룬다.
5. 이 레이어를 듣는 순서
섹션 제목: “5. 이 레이어를 듣는 순서”LLM API 기초- 모델 호출을 API 계약, 토큰 비용, streaming, structured output, 에러 처리의 관점으로 본다.Prompt Engineering- 같은 API 위에서 입력을 어떻게 설계하고, prompt를 코드 자산처럼 관리하며, 회귀를 어떻게 막는지 배운다.임베딩과 벡터 운영- 텍스트를 검색 가능한 벡터로 바꾸고, vector store, chunking, hybrid search, reranker로 의미 검색을 운영한다.RAG 기초- 모델의 고정 지식 한계를 외부 검색으로 보완하고, 출처 인용과 환각 감소를 제품 요구사항으로 다룬다.도구·함수 호출- LLM이 외부 API, DB, 파일, 업무 시스템을 호출하게 만들 때 schema, 권한, sandbox, audit log를 설계한다.
이후에는 에이전트 오케스트레이션, LLM 비용과 지연, LLM 보안, LLM 관측성과 평가로 이어진다. 처음부터 모든 agent 패턴을 외우기보다, “호출을 안정화한다 → 입력을 설계한다 → 지식을 검색한다 → 도구를 연결한다 → 운영 신호로 감시한다”는 흐름을 놓치지 않는 것이 중요하다.
6. 어렵게 느껴지는 지점과 돌아갈 곳
섹션 제목: “6. 어렵게 느껴지는 지점과 돌아갈 곳”막힐 때는 먼저 증상을 좁히고, 부족한 전제가 L11의 모델 이해인지 L12의 제품 설계인지 나누면 된다.
| 막히는 느낌 | 보통 부족한 전제 | 돌아갈 문서 |
|---|---|---|
| 토큰, context, 한국어 비용 이야기가 감이 안 온다 | 토큰화와 context window 직관 | content/topics/L11/tokenization-and-embedding.md |
| prefill, decode, KV cache가 지연과 연결되지 않는다 | 트랜스포머 추론 비용 구조 | content/topics/L11/transformer-and-attention.md |
| LLM API가 그냥 일반 REST 호출과 같아 보인다 | stateless 대화, sampling, structured output | content/topics/L12/llm-api-basics.md |
| 프롬프트가 감으로 쓰는 문장처럼 느껴진다 | prompt를 계약과 테스트 자산으로 보는 관점 | content/topics/L12/prompt-engineering.md |
| RAG가 “문서를 붙여 넣는 것”처럼만 보인다 | 임베딩 검색, chunking, rerank의 역할 | content/topics/L12/embeddings-and-vector-ops.md |
| 답변 품질이 좋아졌는지 판단하기 어렵다 | 평가 데이터, faithfulness, 관측성 | content/topics/L12/llm-observability-and-evals.md |
| tool calling이 위험한 이유가 잘 안 보인다 | API 권한, schema validation, 감사 로그 | content/topics/L12/tool-and-function-calling.md |
7. 들을 준비가 된 상태
섹션 제목: “7. 들을 준비가 된 상태”- LLM 앱을 “모델 + API 계약 + UX + 운영 지표”의 조합으로 설명할 수 있다.
- 토큰 수가 비용, context 길이, latency UX에 영향을 준다는 점을 알고 있다.
- 자유 텍스트 응답과 structured JSON 응답이 제품 안정성에서 어떻게 다른지 말할 수 있다.
- 모델이 모르는 지식은 RAG나 tool calling으로 보완해야 하며, 둘의 실패 모드가 다르다는 점을 받아들일 수 있다.
- LLM 기능을 배포할 때 latency, cost, 보안, 평가, 사용자 피드백을 함께 봐야 한다는 것을 안다.
- 막히면 L11의
tokenization-and-embedding.md,transformer-and-attention.md로 돌아가면 된다는 것을 안다.
8. 이 레이어의 핵심 한 문장
섹션 제목: “8. 이 레이어의 핵심 한 문장”L12 AI 시스템 & LLM 애플리케이션 레이어는 LLM을 “똑똑한 API”로 소비하는 데서 멈추지 않고, 비용과 지연을 예측하고, 외부 지식과 도구를 연결하고, 보안과 평가로 품질을 유지하는 제품 시스템으로 설계하는 법을 배운다.