LLM 프롬프트 캐싱의 원리: KV Cache와 TTL

TL;DR — LLM 프롬프트 캐싱은 아키텍처에 나중에 덧붙인 최적화가 아니다. Transformer 아키텍처가 attention을 계산하는 방식 자체에서 자연스럽게 나온다. 변경되지 않는 prefix의 Key/Value 벡터를 수학적으로 재사용할 수 있는 이유를 이해하면, 진짜 놀라운 부분은 두 가지 효과를 동시에 얻는다는 점이다. 비용은 50–90% 줄고, time-to-first-token은 5–20× 빨라진다. 5부작 시리즈의 Part 1인 이 글에서는 캐싱이 가능한 아키텍처상의 이유, 캐시의 경제성을 결정하는 메모리와 연산량의 트레이드오프, 모든 개발자가 알아야 할 TTL 동작을 다룬다. Part 2에서는 provider별 구현 방식을 자세히 살펴본다.

시리즈: 5부작 중 Part 1 — 캐싱 원리 · 다음 글: Part 2 — Provider 비교와 평가 · Part 3 — 실행 가능한 코드 튜토리얼 · Part 4 — 사용 사례별 최적의 LLM · Part 5 — LangChain 연동 · 한 페이지 요약: 프롬프트 캐싱 완벽 가이드

사용자보다 빠르게 늘어나는 AI 앱의 token 비용

챗봇, RAG 앱, AI agent를 운영하다 보면 비슷한 문제에 부딪힌다. 사용량은 그대로인데 청구 금액이 두 배로 뛴다. 요청 로그를 열어 보면 수천 token에 이르는 동일한 system prompt, 동일한 tool 설명, 동일한 knowledge base chunk가 호출할 때마다 다시 전송되고 있다.

LLM inference 비용 문제의 핵심은 모델에 상태가 없다는 것이다. 요청이 들어올 때마다 전체 context를 처음부터 다시 처리한다. 8K-token system prompt를 1,000번 호출하면 800만 token 분량의 작업이 반복된다. 이 모든 token에 비용을 내야 하고, 사용자 역시 처리될 때까지 매번 기다려야 한다.

프롬프트 캐싱은 이 문제를 해결한다. 일반적인 성능 최적화와 달리 아키텍처에 별도로 추가된 기능이 아니다. Transformer attention의 정의에서 자연스럽게 나온다. 이 원리를 이해하면 비용, TTL, provider별 차이도 명확해진다.

1. LLM에 캐시가 존재하는 이유: Transformer inference 과정

대부분의 “프롬프트 캐싱” 튜토리얼은 이 부분을 건너뛴다. 하지만 캐시가 애초에 왜 존재하는지 이해하려면 반드시 알아야 한다. Provider가 제공하는 할인율도 임의로 정한 마케팅 숫자가 아니라 실제 GPU 비용 구조를 반영한다.

1.1 하나의 식으로 보는 Self-Attention

Decoder-only Transformer는 GPT-4, Claude, Gemini, DeepSeek, Qwen이 모두 속하는 계열이다. 이 모델들은 self-attention을 반복 적용해 token을 처리한다. N개 token으로 구성된 sequence에서 각 token i의 attention 출력은 다음과 같다.

Attention(Q, K, V) = softmax( Q · Kᵀ / √d ) · V

Q, K, V는 입력 embedding에 학습된 세 개의 linear projection을 적용해 얻는 [N × d] 형태의 matrix다. Layer와 head마다 별도의 projection이 있다. 이 정의는 Attention Is All You Need (Vaswani et al., 2017)에서 처음 제시됐다.

캐싱과 관련해 이 식에서 중요한 성질은 두 가지다.

성질 1 — Causal masking. 생성 과정에서 token i는 위치가 ≤ i인 token만 참조할 수 있다. Attention matrix는 lower-triangular 형태다. 앞쪽 token의 K와 V 벡터는 이후 모든 token에서 사용되지만, 뒤쪽 token이 이 값을 변경하지는 않는다.

성질 2 — K와 V는 prefix에 의해서만 결정된다. 위치 i의 K와 V 벡터는 위치 1…i의 입력 embedding에 고정된 weight matrix를 적용해 계산한다. 따라서 위치 1…i에 있는 token의 결정론적 함수이며, 오직 이 token들에 의해서만 정해진다. 위치 i+1의 내용은 K_i나 V_i를 바꿀 수 없다.

결론은 명확하다. 두 요청이 길이 P의 완전히 동일한 prefix를 공유한다면, K와 V의 첫 P개 row도 bit 단위까지 동일하다.

이것이 프롬프트 캐싱의 이론적 기반 전부다. 나머지는 엔지니어링 문제다.

1.2 Inference의 두 단계

최신 LLM inference는 GPU 시간을 전혀 다른 방식으로 사용하는 두 단계로 나뉜다. 이 구분은 Efficiently Scaling Transformer Inference (Pope et al., 2022)에 자세히 설명돼 있다.

Prefill 단계. 모델이 전체 prompt를 한 번에 입력받는다. 각 layer에서 모든 입력 token의 Q, K, V를 계산하고 self-attention을 수행한다. Prefill은 compute-bound 작업이다. GPU의 matrix-multiply unit을 최대한 사용한다. Attention matrix 때문에 비용은 prompt 길이에 따라 **O(N²)**으로 증가한다.

Decode 단계. 모델이 autoregressive 방식으로 한 번에 하나씩 출력 token을 생성한다. t 단계에서는 새 token의 Q만 계산하고, 이를 이전 모든 token의 K/V와 비교한다. Decode는 memory-bandwidth-bound 작업이다. 대부분의 시간이 연산보다 GPU memory에서 K/V를 읽는 데 사용된다. Token당 비용은 현재 context 길이에 따라 **O(N)**으로 증가한다.

일반적인 챗봇 workload가 8K-token system prompt, 100-token 사용자 질의, 300-token 응답으로 구성돼 있다면 wall-clock time과 비용에서 prefill이 decode보다 대략 4:1로 큰 비중을 차지한다. 캐싱이 줄여 주는 부분이 바로 prefill이다.

Per call breakdown (8K prompt, 300 output tokens, Claude-class model):

  ████████████████████████████████░░░░░░░░  Prefill: ~80% of compute
  ░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░████████  Decode:  ~20% of compute

1.3 KV Cache: Prefill 결과를 Decode에서 재사용하기

“KV cache”는 원래 단일 요청 내부에서 사용하는 최적화를 뜻했다. Decode 중 새로 생성되는 token은 이전 모든 token의 K와 V를 참조해야 한다. 이를 단계마다 다시 계산하면 O(N)인 decode가 O(N²)이 된다. 그래서 모든 inference engine은 prefill에서 계산한 K와 V를 GPU memory에 저장하고 decode 단계 전체에서 재사용한다. 모든 상용 LLM이 사용하는 보편적인 방식이다. 이 최적화가 있어야 현실적인 속도로 생성할 수 있다.

Provider가 “프롬프트 캐싱”이라는 이름으로 제공하는 기능은 이 방식을 한 단계 더 확장한 것이다. 요청이 끝난 뒤에도 KV cache를 보관하고, 동일한 prefix를 공유하는 다음 요청에서 재사용한다.

1.4 메모리와 연산량의 트레이드오프: TTL이 필요한 이유

그렇다면 모든 provider가 모든 값을 영구적으로 캐싱하지 않는 이유는 무엇일까? KV cache가 엄청나게 크기 때문이다.

Transformer layer 수가 L, attention head 수가 H, head-dimension이 D, 값 하나의 byte 수가 B인 모델에서 N개 token의 KV cache 크기는 다음과 같다. B는 일반적으로 fp16에서 2다.

KV cache size  =  2 × L × H × D × B × N
                  ↑   ↑   ↑   ↑   ↑   ↑
                  K&V layers heads head bytes tokens

70B급 모델이 80개 layer, 8개 KV head(grouped-query-attention 적용 후), 128 head-dim, fp16 weight를 사용한다면 token당 대략 320 KB가 필요하다. 32K-token context 하나의 KV cache만으로 ~10 GB를 차지한다. 최신 H100 GPU의 memory는 80 GB이므로 이런 context는 동시에 몇 개밖에 올리지 못한다.

vLLM의 기반 논문인 PagedAttention (Kwon et al., 2023)은 batch 수준에서 이 제약을 해결하기 위해 설계됐다. 같은 제약이 요청 간 프롬프트 캐싱의 한계도 결정한다.

따라서 provider의 cache TTL은 본질적으로 메모리 eviction 정책이다. 어느 시점이 되면 다른 사용자의 활성 workload에 GPU memory가 필요해지고, 캐싱된 prefix는 제거된다. HBM에 상주하는 cache는 5분, DRAM으로 paging되는 cache는 최대 1시간, disk-backed cache는 수 시간까지 유지된다.

DeepSeek의 접근법. DeepSeek-V2는 Multi-head Latent Attention(MLA)을 도입했다. 표준 grouped-query attention과 비교해 KV cache를 약 4× 압축한다(DeepSeek-AI, 2024). 이 압축 덕분에 KV cache를 HBM이 아닌 disk에 저장할 수 있다. 그 결과 최소 cache 단위를 크게 줄이고(64 token, HBM 상주 cache는 1,024 token) 실질적인 TTL도 훨씬 길게 유지할 수 있다.

요청 간 캐싱에 token 단위로 완전히 동일한 prefix가 필요한 이유도 여기에 있다. Cache index는 token ID의 hash로 생성된다. 단 한 문자라도 달라져 tokenization 결과가 바뀌면 그 지점부터 K와 V도 달라진다. 이 layer에는 “fuzzy match”가 없다. 의미 기반 일치는 semantic caching이 담당하며, gateway에서는 별도의 메커니즘으로 처리한다.

1.5 두 계층으로 구성된 캐싱

┌──────────────────────────────────────────────────────────────┐
│  Layer 1: Per-request KV cache (always on, every provider)    │
│  → keeps decode O(N) instead of O(N²)                        │
│  → you don't pay attention to it; the provider just does it  │
└──────────────────────────────────────────────────────────────┘
                              ↓
┌──────────────────────────────────────────────────────────────┐
│  Layer 2: Cross-request Prompt Cache (the money-and-time      │
│           saver this series is about)                         │
│  → reuses prefill K/V across requests with matching prefixes  │
│  → exposed as: explicit / fully automatic / hybrid           │
│  → bounded by TTL (memory-eviction-driven)                   │
└──────────────────────────────────────────────────────────────┘

이 시리즈의 나머지 내용과 개발자가 조정해야 할 대부분의 항목은 Layer 2에 해당한다.

2. 두 가지 효과: 비용과 latency

대부분의 글은 캐싱을 비용 최적화로만 설명하지만, 이는 효과를 과소평가한 것이다. 특히 사용자가 직접 이용하는 chat에서는 production 팀이 캐싱을 도입하는 더 큰 이유가 latency인 경우가 많다.

2.1 비용 계산

가격 페이지에는 대표적인 수치만 있고, 현실적인 workload에 적용한 계산은 거의 없다. 8,000-token system prompt를 사용하는 고객 지원 bot이 하루 100K건의 질의를 처리하고, 사용자 메시지는 200 token이라고 가정하자. Anthropic이 공개한 2026년 요금(캐싱된 input은 10%, cache write는 125% 할증)을 기준으로 claude-sonnet-4-5의 비용을 계산하면 다음과 같다.

캐싱하지 않는 경우

• 호출당 input: 8,200 token × 기본 input 요금
• 호출당 비용(단일 호출 측정): ~$0.022
• 월간 비용: 100K × 30 × $0.022 = ~$66,000

프롬프트 캐싱을 사용하는 경우

• 최초 cache write: 8,000 token × 125% 할증(월간 처리량과 비교하면 무시할 수준)
• 이후 호출당 비용: 8,000 token × 기본 요금의 10% + 200 token × 기본 요금 + output
• 실질적인 호출당 비용: ~$0.003
• 월간 비용: ~$9,000

약 86%가 절감된다. Anthropic이 공개한 할인율을 현실적인 input 구성에 적용한 결과다. 이어지는 Part 3 — 튜토리얼에서는 다른 provider에서도 직접 측정한 수치를 보여 준다.

2.2 Latency 개선: 더 중요한 효과인 경우가 많다

Prefill은 비용만 많이 드는 게 아니다. Prompt가 수백 token보다 길어지면 time-to-first-token에 가장 큰 영향을 주는 단일 요소가 된다. Cache hit가 발생하면 이 작업을 거의 전부 건너뛸 수 있다.

2026-05-25, 약 7,300-token의 고정된 system prompt로 공개 Synthorai gateway에서 streaming TTFT를 측정한 결과다.

Single-run, single-tenant 환경에서 측정했다. TTFT 개선은 긴 prompt(>5K token)에서 가장 두드러진다. 짧은 prompt는 전체 latency에서 prefill이 차지하는 비중이 작다. 측정 결과 Claude의 가장 큰 이점은 비용이었다. Cache read 시 input 비용이 약 88–89% 줄었다. Anthropic이 공개한 수치에 따르면 prompt 크기가 100K 이상이면 TTFT 개선 효과도 상당히 커진다.

Chat UI에서 사용자가 지연을 명확히 인식하기 시작하는 기준은 TTFT 약 1 s, 처음으로 유용한 text가 표시되기까지 약 2 s다. 캐싱하지 않은 10K-token RAG prompt는 이 기준을 확실히 넘는다. 캐싱을 적용하면 동일한 workload가 즉각 반응하는 것처럼 느껴진다.

15단계 이상으로 구성된 agent loop에서도 비용 절감 효과는 크다(50% 절감). 하지만 실제로 출시 가능한 제품으로 만들어 주는 것은 latency 개선이다. 작업당 15단계 × 5s prefill = 75 s의 대기 시간이 캐싱 후에는 15 × 0.5s = 7.5 s로 줄어든다.

2.3 제품 전략에서 중요한 이유

캐싱을 출시 후에 덧붙이는 “운영팀의 비용 최적화”로 취급하는 경우가 많다. 하지만 latency가 줄어들면 캐싱은 UX의 일부가 된다.

• TTFT가 1 s 미만인 챗봇은 살아 있는 듯 반응하지만, 같은 bot이 3 s 걸리면 고장 난 것처럼 느껴진다.
• Retrieval과 prefill에 4 s가 걸리는 RAG 제품은 동일한 작업을 1 s에 처리하는 제품에 밀린다.
• 작업을 20 s에 끝내는 agent는 90 s가 걸리는 agent보다 경쟁력이 있다.

Cache 전략은 출시 후 세 번의 sprint가 지난 시점이 아니라, 모델과 prompt 구조를 결정할 때 함께 정해야 한다.

3. Cache freshness, TTL, 운영 모델

TTL은 프롬프트 캐싱에서 가장 많이 묻지만 제대로 설명되는 경우는 드문 주제다. 두 가지를 알아야 한다.

3.1 Freshness의 두 가지 의미를 구분해야 한다

Cache freshness ≠ response freshness. 서로 다른 두 개념이 자주 혼동된다.

캐싱된 응답은 모델 품질 관점에서 “오래된” 응답이 아니다. 캐싱하지 않았을 때와 수학적으로 동일하다. 하지만 system prompt에 “현재 시각은 14:32:05”를 넣고 cache hit에 의존한다면, TTL이 만료될 때까지 “현재 시각”은 14:32:05로 유지된다. 모델은 사용자에게 잘못된 시간을 확신에 차서 답하게 된다.

3.2 Provider별 TTL 동작

기본값이 5분인 데는 이유가 있다. 사용량이 많은 모델이 peak load 상태일 때 GPU memory가 버틸 수 있는 시간대가 대략 이 정도다. §1.4에서 계산했듯이 대형 context 하나의 KV cache가 수십 GB에 이를 수 있으므로 provider가 이를 무기한 유지할 수는 없다.

3.3 TTL을 고려한 설계

Production에서 효과적인 세 가지 패턴이 있다.

패턴 A — Session을 warm 상태로 유지한다. Chat에서는 turn 사이의 자연스러운 요청 간격이 몇 초에서 몇 분이므로 cache가 자동으로 유지된다. TTL을 걱정할 필요는 없다. 단, 동적 데이터를 prefix에 넣지 않아야 한다.

패턴 B — Batch 작업에는 heartbeat를 사용한다. 수 시간 동안 실행되는 batch job은 TTL/2 간격으로 최소한의 요청을 보내 cache를 warm 상태로 유지한다. 비용은 사실상 0에 가깝고(input token 몇 개), cache eviction이 한꺼번에 발생하는 것을 막을 수 있다.

패턴 C — 낮은 빈도로 사용하는 데이터에는 TTL이 긴 provider를 선택한다. 50K-token 문서를 간헐적으로 조회한다면(예: 일주일 동안 시간당 한 번), storage fee를 고려해도 Gemini explicit cache(24-hour TTL)나 DeepSeek disk cache가 TTL이 짧은 대안보다 유리하다.

4. 모든 개발자가 알아야 할 공통 원칙

Provider는 캐싱을 매우 다른 다섯 가지 형태로 제공한다. Explicit marker, 완전 자동 방식, hybrid 방식, disk-backing 아키텍처, 또는 캐싱을 제공하지 않는 경우도 있다. 다음 글인 Part 2 — Provider 비교와 평가에서 이를 자세히 비교한다. 하지만 방금 살펴본 아키텍처에서 바로 도출되는 네 가지 원칙은 provider와 무관하게 적용된다.

4.1 캐싱은 Prefix 기반이므로 순서가 중요하다

위치 i의 K/V는 위치 1…i의 token에 의해 결정되므로 provider는 token 0부터 시작하는 연속된 prefix만 일치시킬 수 있다. 위치 0에서 문자 하나만 바뀌어도 전체 prefix가 무효화된다. 변하지 않는 content는 앞에, 자주 바뀌는 content는 뒤에 둬야 한다. 이는 경험칙이 아니라 self-attention의 causal 구조에서 직접 나오는 결과다(§1.1).

4.2 Cache에는 답변이 아니라 K/V가 저장된다

Cache hit는 이전에 생성한 답변을 반환하는 것이 아니다. 이전에 계산한 K와 V 벡터를 반환하고, 모델은 이를 사용해 현재 질문에 대한 새 응답을 생성한다. 따라서 다음 특성이 유지된다.

• 출력 품질은 캐싱하지 않은 호출과 동일하다(§1.1).
• 출력은 일반적인 방식으로 비결정적이다. Temperature, top-p 등이 그대로 적용된다.
• 캐싱된 응답은 모델 품질 관점에서 절대 “오래되지” 않는다. Timestamp, 가격 등 prompt의 content만 오래될 수 있다. §3.1을 다시 참고하라.

4.3 Cache write는 무료가 아니라 투자다

Write 비용을 할증하는 provider(Anthropic 125%, Gemini explicit 125%)에서는 새로운 prefix를 사용하는 첫 호출이 캐싱하지 않을 때보다 더 비싸다. 손익분기점에는 빠르게 도달하며 보통 hit 한 번이면 충분하다. 하지만 “고정된” prefix가 요청마다 바뀌면 write 비용만 반복해서 내고 아무 효과도 얻지 못한다. 검색된 문서를 relevance 기준으로 정렬하는 구현에서 자주 발생하는 대표적인 anti-pattern이다.

4.4 Provider마다 캐싱 API가 호환되지 않는다

cache_control(Anthropic) ≠ cached_content(Gemini) ≠ cache_id(Qwen)다. 애플리케이션이 여러 provider를 지원해야 한다면 세 가지 integration을 각각 유지하거나, 앞단에 Token Gateway를 두고 하나의 인터페이스로 통합해야 한다. Part 2에서 자세히 다룬다.

5. 프롬프트 캐싱은 무조건 이득일까?

거의 그렇다. 다음 조건을 만족하면 효과가 있다.

• Prompt에 system prompt, knowledge base, tool schema 같은 고정된 prefix가 있다.
• 호출이 빈번하거나 서로 연결돼 있다. 동일 session, batch workload, 실행 중인 agent run이 이에 해당한다.
• 변하지 않는 content가 앞에 오도록 prompt를 구성할 수 있다.

세 조건을 만족하면 모델을 바꾸지 않고도 일반적으로 비용을 50–90% 줄이고, TTFT를 3–20× 단축할 수 있다.

다음 글: Part 2 — Provider 캐싱 비교와 평가 프레임워크에서는 위 아키텍처를 바탕으로 Claude, OpenAI, Gemini, DeepSeek, Qwen의 기능을 항목별로 비교하고, workload에 맞는 provider를 선택할 수 있는 평가 기준을 제시한다.

빠른 시작: OpenAI SDK로 모든 Provider 사용하기

Synthorai는 OpenAI 호환 endpoint를 제공한다. 공식 openai SDK가 이 endpoint를 바라보게 설정하면 Claude, GPT, Gemini, DeepSeek, Qwen 사이에서 한 줄만 바꿔 모델을 교체할 수 있다. Gateway는 cache_control을 각 provider의 native 캐싱 문법으로 변환한다.

import os
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["SYNTHORAI_KEY"],
    base_url="https://synthorai.io/v1",
)

resp = client.chat.completions.create(
    model="claude-sonnet-4-5",                       # swap freely
    max_tokens=256,
    messages=[
        {"role": "system", "content": "You are a helpful assistant."},
        {"role": "user",   "content": "Hello"},
    ],
)

print(resp.choices[0].message.content)
print(resp.usage.prompt_tokens_details)  # cached_tokens when upstream reports it
print(resp.usage.cost)                   # USD per call (gateway-computed)

같은 호출을 gpt-5.4-mini, gemini-2.5-pro, deepseek-v4-flash, qwen3-max에도 사용할 수 있다. model field만 바꾸면 된다. Gateway는 프롬프트 cache hit metadata를 표준 OpenAI prompt_tokens_details.cached_tokens field로 반환한다. 호출별 USD 비용도 cost field에 함께 제공하므로 애플리케이션에서 vendor별 요금 matrix를 따로 관리할 필요가 없다.

FAQ

LLM 프롬프트 캐싱과 semantic caching은 같은가? 아니다. 프롬프트 캐싱은 prefix 기반이다. Prompt 시작 부분이 token 단위로 정확히 일치하면 K/V 값을 재사용한다. Semantic caching은 embedding으로 의미를 비교하고 이전 응답을 반환한다. 둘 다 유용하며, 잘 설계된 Token Gateway는 이를 여러 계층으로 조합한다.

프롬프트 캐싱이 모델 출력을 바꾸는가? 아니다. K와 V는 입력 token의 결정론적 함수다(§1.1). 캐싱된 K/V를 사용해 모델이 생성하는 logit은 새로 계산한 K/V에서 생성한 logit과 수학적으로 동일하다. 캐싱은 품질에 영향을 주지 않는 순수한 효율 최적화다.

Cache TTL은 왜 이렇게 짧은가? 영구적으로 유지할 수는 없나? KV cache는 매우 크다(§1.4: 70B 모델의 32K context당 ~10 GB). GPU memory가 병목이므로 server가 활성 workload에 memory를 사용해야 할 때 cache가 제거된다. Disk-backed cache(DeepSeek)는 수 시간 동안 유지할 수 있지만, in-memory cache는 일반적으로 그렇게 오래 유지할 수 없다.

KV cache와 prompt cache의 차이는 무엇인가? KV cache는 inference 중 사용하는 in-memory data structure다. “Prompt cache”는 이 KV cache를 여러 요청에서 재사용하는 방식이다. 위 §1.5의 Layer 1과 Layer 2에 해당한다.

캐싱된 prompt가 오래돼 품질이 떨어지는 경우가 있는가? 모델 관점에서는 없다. 하지만 prompt가 시간에 민감한 정보를 포함한다면 content 관점에서는 문제가 생길 수 있다. Cache는 세상의 사실이 아니라 K/V 벡터를 저장한다. §3.1을 참고하라.

Cache hit rate는 어떻게 측정하는가? 모든 provider가 response usage object에 관련 값을 반환한다. Anthropic은 cache_read_input_tokens, OpenAI는 cached_tokens, Gemini는 cached_content_token_count, DeepSeek는 prompt_cache_hit_tokens를 사용한다. Logging pipeline에서 이 값을 추적하면 된다.

참고 문헌과 출처: Vaswani et al., “Attention Is All You Need” (NeurIPS 2017) · Pope et al., “Efficiently Scaling Transformer Inference” (2022) · Kwon et al., “Efficient Memory Management for LLM Serving with PagedAttention” (SOSP 2023, vLLM) · DeepSeek-AI, “DeepSeek-V2: A Strong, Economical, and Efficient MoE Language Model” (2024) — MLA 아키텍처 · Anthropic 프롬프트 캐싱 문서 · OpenAI 프롬프트 캐싱 문서 · Google Gemini Context 캐싱 문서 · DeepSeek KV Cache 가이드 · Alibaba Bailian Context Cache

← 블로그로 돌아가기