캐싱 (Caching): 성능 최적화와 시스템 효율을 위한 마법 같은 기술

오늘날 소프트웨어 시스템은 사용자에게 빠르고 안정적인 경험을 제공하는 것이 무엇보다 중요합니다. 데이터베이스에서 데이터를 가져오거나, 복잡한 연산을 수행하거나, 외부 API를 호출하는 작업은 시간이 오래 걸리며 시스템 리소스를 많이 소모합니다. 이러한 병목 현상을 해결하고 시스템의 전반적인 효율성을 극대화하기 위한 강력한 기술 중 하나가 바로 **캐싱(Caching)**입니다.

저는 10년 동안 다양한 시스템을 개발하고 운영하며 캐싱의 중요성을 수없이 체감했습니다. 적절한 캐싱 전략은 느려터진 시스템을 번개처럼 빠르게 만들고, 엄청난 트래픽에도 끄떡없는 견고함을 부여하며, 심지어 클라우드 비용까지 절감해주는 마법 같은 효과를 가져옵니다. 하지만 잘못된 캐싱은 오히려 시스템을 더 복잡하게 만들고 치명적인 데이터 불일치 문제를 야기할 수도 있습니다.

이 글에서는 초중급 개발자 여러분이 캐싱의 기본 개념부터 핵심 원리, 실무 적용 방법, 그리고 흔히 겪는 문제점과 해결책까지 완벽하게 이해할 수 있도록 안내하겠습니다.

1. 개념 소개: 캐싱이란 무엇이며 왜 중요한가?

정의

캐싱은 자주 접근하는 데이터나 연산 결과를 임시 저장소(캐시)에 미리 저장해두었다가, 동일한 요청이 들어왔을 때 저장된 데이터를 즉시 반환하여 원본 데이터 소스에 대한 접근을 줄이는 기술입니다. 즉, "미리 준비해두기" 또는 "기억해두기"와 같습니다.

탄생 배경

컴퓨터 시스템의 역사를 보면, CPU와 메모리, 디스크, 네트워크 간의 속도 차이는 항상 존재했습니다. CPU는 매우 빠르지만, 디스크나 네트워크에서 데이터를 가져오는 데는 상대적으로 긴 시간이 소요됩니다. 이러한 속도 불균형은 시스템의 전체 성능을 저하시키는 주요 원인이었습니다. 이 문제를 해결하기 위해 고안된 것이 바로 캐싱입니다. 데이터를 더 빠르고 가까운 곳에 저장하여 접근 지연 시간을 줄이는 것이 캐싱의 핵심 목표입니다.

왜 중요한가?

캐싱은 현대 소프트웨어 시스템에서 다음과 같은 이유로 매우 중요합니다.

• 성능 향상: 가장 직접적인 이점입니다. 데이터 접근 지연 시간(latency)을 줄여 응답 속도를 빠르게 하고, 초당 처리할 수 있는 요청 수(throughput)를 증가시킵니다.
• 비용 절감: 데이터베이스 쿼리 횟수나 외부 API 호출 횟수를 줄여 데이터베이스 서버의 부하를 낮추고, 네트워크 트래픽을 감소시킵니다. 이는 클라우드 환경에서 운영 비용 절감으로 직결됩니다.
• 시스템 안정성 향상: 백엔드 시스템(데이터베이스, 외부 서비스)의 부하를 줄여 장애 발생 가능성을 낮춥니다. 백엔드 시스템에 일시적인 문제가 발생하더라도 캐시된 데이터로 서비스를 계속 제공할 수 있어 시스템의 회복탄력성을 높입니다.
• 사용자 경험 개선: 빠른 응답 속도는 사용자 만족도를 높이고 이탈률을 줄이는 데 결정적인 역할을 합니다.

2. 핵심 원리 설명: 캐시 히트, 미스, 그리고 전략들

캐싱의 핵심은 데이터가 캐시에 있는지 없는지를 판단하고, 없을 경우 어떻게 가져올지, 그리고 캐시가 가득 찼을 때 어떤 데이터를 버릴지 결정하는 것입니다.

캐시 히트 (Cache Hit)와 캐시 미스 (Cache Miss)

• 캐시 히트 (Cache Hit): 요청된 데이터가 캐시에 존재하여 캐시에서 바로 데이터를 가져오는 경우입니다. 이는 매우 빠른 응답을 의미합니다.
• 캐시 미스 (Cache Miss): 요청된 데이터가 캐시에 존재하지 않아 원본 데이터 소스(데이터베이스, 외부 API 등)에서 데이터를 가져와야 하는 경우입니다. 데이터가 원본 소스에서 로드된 후에는 다음 요청을 위해 캐시에 저장됩니다.

비유: 여러분이 자주 읽는 책이 있다고 상상해 봅시다.

• 캐시: 여러분의 책상 위에 있는 책꽂이입니다. (가장 빠르고 가까운 곳)
• 원본 데이터 소스: 학교 도서관입니다. (데이터는 많지만 멀고 느립니다)
• 캐시 히트: 책상 위 책꽂이에서 원하는 책을 바로 찾았습니다.
• 캐시 미스: 책상 위 책꽂이에 원하는 책이 없어 도서관에 가서 찾아왔습니다. (그리고 다음번에 찾기 쉽도록 책상 위 책꽂이에 두었습니다.)

캐시 계층 (Cache Hierarchy)

캐시는 시스템의 다양한 레벨에 존재하며, 각 레벨은 속도와 용량 면에서 트레이드오프를 가집니다.

• CPU 캐시 (L1, L2, L3): CPU 내부에 있는 가장 빠르고 작은 캐시입니다.
• 메모리 캐시: OS나 애플리케이션이 RAM에 데이터를 캐싱하는 것입니다. (예: functools.lru_cache, Redis, Memcached)
• 디스크 캐시: OS가 자주 접근하는 디스크 블록을 RAM에 캐싱하는 것입니다.
• 브라우저 캐시: 웹 브라우저가 정적 파일(이미지, CSS, JS)을 로컬에 저장하는 것입니다.
• CDN (Content Delivery Network): 전 세계 여러 지역에 분산된 서버에 콘텐츠를 캐싱하여 사용자에게 가장 가까운 서버에서 데이터를 전송합니다.

캐시 전략 (Cache Policies)

캐시를 어떻게 활용할지에 대한 다양한 전략이 있습니다.

데이터 읽기 전략

1. Cache-aside (레이지 로딩):

   • 애플리케이션이 데이터를 조회할 때, 먼저 캐시를 확인합니다.
   • 캐시에 데이터가 있으면(Hit) 캐시에서 가져옵니다.
   • 캐시에 데이터가 없으면(Miss) 원본 데이터 소스에서 가져와 캐시에 저장한 후 반환합니다.
   • 장점: 캐시에 필요한 데이터만 저장하므로 메모리 효율적입니다.
   • 단점: 첫 번째 요청 시에는 캐시 미스로 인해 지연이 발생할 수 있습니다.
   • 가장 일반적인 웹 애플리케이션 캐싱 패턴입니다.

2. Read-through:

   • Cache-aside와 유사하지만, 캐시 라이브러리나 시스템이 원본 데이터 소스에서 데이터를 가져와 캐시에 저장하는 로직을 직접 처리합니다. 애플리케이션은 단순히 캐시에게 데이터 조회를 요청합니다.
   • 장점: 애플리케이션 코드가 더 간결해집니다.
   • 단점: 캐시 시스템이 원본 데이터 소스에 접근하는 방법을 알아야 합니다.

데이터 쓰기 전략

1. Write-through:
   • 데이터를 업데이트할 때, 캐시와 원본 데이터 소스 모두에 동시에 업데이트합니다.
   • 장점: 캐시와 원본 데이터 소스의 데이터 일관성이 즉시 보장됩니다.
   • 단점: 쓰기 작업의 지연 시간이 길어질 수 있습니다.
2. Write-back:
   • 데이터를 업데이트할 때, 캐시에만 먼저 업데이트하고, 일정 시간 후 또는 특정 조건(예: 캐시가 가득 찼을 때)이 되면 원본 데이터 소스에 비동기적으로 업데이트합니다.
   • 장점: 쓰기 작업의 응답 속도가 빠릅니다.
   • 단점: 데이터 유실 위험이 있고, 캐시와 원본 데이터 소스 간의 일관성 유지가 어렵습니다. (예: 전원이 갑자기 꺼지면 캐시에만 있던 데이터가 사라질 수 있습니다.)

캐시 교체 정책 (Eviction Policies)

캐시의 용량이 가득 찼을 때, 어떤 데이터를 버리고 새로운 데이터를 저장할지 결정하는 정책입니다.

• LRU (Least Recently Used): 가장 오랫동안 사용되지 않은 데이터를 먼저 버립니다. (가장 널리 사용됨)
• LFU (Least Frequently Used): 가장 적게 사용된 데이터를 먼저 버립니다.
• FIFO (First-In, First-Out): 가장 먼저 캐시에 들어온 데이터를 먼저 버립니다.
• ARC (Adaptive Replacement Cache): LRU와 LFU의 장점을 결합한 정책입니다.

캐시 무효화 (Cache Invalidation)

캐싱에서 가장 어려운 문제 중 하나는 "데이터가 변경되었을 때 캐시의 데이터를 어떻게 업데이트하거나 삭제할 것인가"입니다. 이를 캐시 무효화라고 합니다. 잘못된 무효화는 사용자에게 오래된(Stale) 데이터를 보여주거나, 심각한 데이터 불일치를 야기할 수 있습니다.

• TTL (Time To Live): 캐시된 데이터에 만료 시간을 설정하여, 시간이 지나면 자동으로 무효화되도록 합니다. 가장 간단하고 널리 사용되는 방법입니다.
• 수동 무효화: 데이터가 변경될 때 애플리케이션 코드에서 직접 캐시의 해당 데이터를 삭제합니다.
• 발행/구독 (Publish/Subscribe) 모델: 데이터 변경 이벤트를 발행하고, 캐시 시스템이 이를 구독하여 자동으로 캐시를 무효화하는 방식입니다. (분산 시스템에서 유용)

3. 코드 예제: Python으로 캐싱 맛보기

여기서는 Python의 functools.lru_cache를 사용한 간단한 메모리 캐싱과, Redis를 활용한 분산 캐싱의 기초를 살펴보겠습니다.

예제 1: Python의 lru_cache를 이용한 함수 캐싱

lru_cache는 특정 함수의 결과를 캐싱하여 동일한 인수로 다시 호출될 때 캐시된 결과를 반환하도록 해주는 데코레이터입니다. 이는 Cache-aside 패턴의 한 형태로 볼 수 있습니다.

import time
from functools import lru_cache

# 최대 128개의 최근 결과만 캐싱하고, 캐시된 결과는 최대 600초(10분) 동안 유효
@lru_cache(maxsize=128, typed=False) # maxsize: 캐시할 항목의 최대 개수, typed: 인수의 타입 구분 여부
def expensive_calculation(n):
    """
    시간이 오래 걸리는 연산을 흉내내는 함수.
    """
    print(f"[{time.time():.2f}] 복잡한 계산 수행 중... (n={n})")
    time.sleep(2) # 2초 대기
    return n * n + 100

print("--- 첫 번째 호출 (캐시 미스) ---")
result1 = expensive_calculation(5)
print(f"결과: {result1}\n")

print("--- 두 번째 호출 (캐시 히트) ---")
# 동일한 인수로 호출되므로 캐시된 결과 반환
result2 = expensive_calculation(5)
print(f"결과: {result2}\n")

print("--- 다른 인수로 호출 (캐시 미스) ---")
result3 = expensive_calculation(10)
print(f"결과: {result3}\n")

print("--- 다시 첫 번째 인수로 호출 (캐시 히트) ---")
result4 = expensive_calculation(5)
print(f"결과: {result4}\n")

# lru_cache의 통계 정보 확인 (선택 사항)
print("\n--- 캐시 통계 ---")
print(expensive_calculation.cache_info())

코드 설명: expensive_calculation 함수는 2초의 지연 시간을 가집니다. lru_cache 데코레이터를 적용하면, expensive_calculation(5)가 처음 호출될 때는 2초가 걸리지만, 두 번째 호출부터는 즉시 캐시된 결과를 반환하여 지연 없이 실행됩니다. cache_info()를 통해 캐시 히트/미스 횟수, 현재 캐시 크기 등을 확인할 수 있습니다.

예제 2: Redis를 활용한 분산 캐싱

Redis는 인메모리 데이터 구조 저장소로, 캐싱, 메시지 브로커 등으로 널리 사용됩니다. 여러 애플리케이션 인스턴스 간에 캐시를 공유할 수 있어 분산 시스템에서 특히 유용합니다.

먼저 redis-py 라이브러리를 설치해야 합니다: pip install redis 그리고 Redis 서버가 실행 중이어야 합니다. (Docker로 간단히 실행 가능: docker run --name my-redis -p 6379:6379 -d redis)

import redis
import json
import time

# Redis 클라이언트 연결
# 실제 환경에서는 환경 변수 등으로 호스트, 포트, 비밀번호를 관리합니다.
r = redis.Redis(host='localhost', port=6379, db=0, decode_responses=True)

def get_user_data(user_id):
    """
    사용자 데이터를 데이터베이스에서 가져오는 척하는 함수.
    """
    print(f"[{time.time():.2f}] DB에서 사용자 데이터 조회 중... (user_id={user_id})")
    time.sleep(1) # DB 조회 지연 흉내
    return {"id": user_id, "name": f"User_{user_id}", "email": f"user{user_id}@example.com"}

def get_user_data_cached(user_id):
    """
    Redis를 활용하여 사용자 데이터를 캐싱하는 함수. (Cache-aside 패턴)
    """
    cache_key = f"user:{user_id}"
    
    # 1. 캐시에서 데이터 조회
    cached_data = r.get(cache_key)
    if cached_data:
        print(f"[{time.time():.2f}] Redis 캐시 히트! (key={cache_key})")
        return json.loads(cached_data) # JSON 문자열을 파이썬 객체로 변환
    
    # 2. 캐시 미스 시 원본 데이터 소스에서 조회
    user_data = get_user_data(user_id)
    
    # 3. 조회한 데이터를 캐시에 저장 (TTL 300초 = 5분)
    r.setex(cache_key, 300, json.dumps(user_data)) # 파이썬 객체를 JSON 문자열로 변환하여 저장
    print(f"[{time.time():.2f}] Redis에 데이터 저장. (key={cache_key}, TTL=300s)")
    
    return user_data

print("--- 첫 번째 사용자 데이터 요청 (캐시 미스) ---")
user1 = get_user_data_cached(1)
print(f"사용자 1 정보: {user1}\n")

print("--- 두 번째 사용자 데이터 요청 (캐캐시 히트) ---")
user2 = get_user_data_cached(1) # 동일한 user_id
print(f"사용자 1 정보: {user2}\n")

print("--- 다른 사용자 데이터 요청 (캐시 미스) ---")
user3 = get_user_data_cached(2)
print(f"사용자 2 정보: {user3}\n")

# 캐시 수동 무효화 예시 (예: 사용자 정보가 업데이트되었을 때)
print("\n--- 캐시 수동 무효화 ---")
r.delete("user:1")
print("user:1 캐시 무효화 완료.")

print("--- 무효화 후 다시 요청 (캐시 미스) ---")
user4 = get_user_data_cached(1)
print(f"사용자 1 정보: {user4}\n")

코드 설명: get_user_data_cached 함수는 user:{user_id} 형태의 캐시 키를 사용하여 Redis에서 데이터를 조회합니다. 데이터가 캐시에 있으면 바로 반환하고(json.loads로 역직렬화), 없으면 get_user_data 함수를 호출하여 DB에서 데이터를 가져온 후, json.dumps로 직렬화하여 Redis에 저장합니다. setex 함수를 사용하여 만료 시간(TTL)을 300초로 설정합니다. r.delete("user:1")을 통해 특정 캐시 키를 수동으로 무효화하는 예시도 포함되어 있습니다.

4. 실무 적용 사례

캐싱은 거의 모든 현대 소프트웨어 시스템에서 다양한 형태로 활용됩니다.

• 웹 애플리케이션 백엔드:
  • 데이터베이스 쿼리 결과 캐싱: 자주 조회되는 상품 목록, 사용자 프로필, 인기 게시물 등의 쿼리 결과를 Redis, Memcached 같은 인메모리 캐시에 저장하여 DB 부하를 줄이고 응답 속도를 높입니다.
  • API 응답 캐싱: 특정 API 엔드포인트의 응답을 캐싱하여 동일한 요청에 대해 빠르게 응답합니다. 특히 변경이 잦지 않은 읽기 전용 API에 효과적입니다.
  • 세션 캐싱: 사용자 세션 정보를 데이터베이스 대신 캐시에 저장하여 세션 관리의 성능을 향상시킵니다.
• CDN (Content Delivery Network):
  • 이미지, CSS, JavaScript 파일, 동영상 등 정적 콘텐츠를 사용자에게 물리적으로 가까운 엣지 서버에 캐싱하여 전송 속도를 높이고 원본 서버의 부하를 줄입니다.
• 브라우저 캐시:
  • 웹 브라우저가 정적 리소스(이미지, CSS, JS)를 로컬 디스크에 저장하여 웹 페이지 재방문 시 더 빠르게 로드되도록 합니다. HTTP 헤더(Cache-Control, ETag, Last-Modified)를 통해 제어됩니다.
• 분산 시스템 및 마이크로서비스:
  • 서비스 간에 공유되는 설정 데이터, 인증 토큰, 권한 정보 등을 캐싱하여 서비스 간 통신 오버헤드를 줄입니다.
• 데이터 분석 및 머신러닝:
  • 전처리된 대규모 데이터셋, 머신러닝 모델의 추론 결과 등을 캐싱하여 반복적인 연산 시간을 단축하고 리소스 사용량을 최적화합니다.

5. 자주 하는 실수와 해결법

캐싱은 강력하지만, 잘못 사용하면 오히려 독이 될 수 있습니다.

1. 오래된 데이터 (Stale Data) 문제

문제: 캐시된 데이터가 원본 소스의 데이터와 일치하지 않아 사용자에게 잘못된 정보를 제공하는 경우입니다. 캐시 무효화 전략이 없거나 잘못되었을 때 발생합니다. 해결법:

• TTL (Time To Live) 설정: 캐시된 데이터에 적절한 만료 시간을 설정하여 자동으로 무효화되도록 합니다. 데이터의 변경 주기를 고려하여 TTL을 정하는 것이 중요합니다.
• 버전 관리: 데이터가 변경될 때마다 버전 번호를 부여하고, 캐시 키에 버전 번호를 포함하거나, 새로운 버전의 데이터를 캐싱하고 이전 버전 캐시는 삭제하는 방식입니다.
• 발행/구독 모델: 데이터 변경 이벤트를 발행하고, 캐시 시스템이 이를 구독하여 해당 데이터를 즉시 무효화합니다. (예: Kafka, RabbitMQ와 연동)
• Write-through 패턴: 쓰기 시 캐시와 DB에 동시에 반영하여 일관성을 즉시 유지하지만, 쓰기 성능 저하를 감수해야 합니다.

2. 캐시 스탬피드 (Cache Stampede)

문제: 특정 데이터에 대한 캐시가 만료되거나 초기 캐시 미스 상태일 때, 수많은 요청이 동시에 들어와 모든 요청이 원본 데이터 소스로 몰려 과부하를 일으키는 현상입니다. (일명 "Thundering Herd" 문제) 해결법:

• 락(Lock) 기반 접근: 캐시 미스 발생 시, 단 하나의 요청만 원본 데이터 소스에 접근하도록 락을 걸고, 나머지 요청은 락이 풀릴 때까지 대기하도록 합니다. (예: Redis 분산 락)
• 사전 로딩 (Pre-fetching): 캐시 만료 시간이 임박했을 때, 백그라운드에서 미리 데이터를 갱신하여 캐시 미스가 발생하기 전에 새로운 데이터를 채워 넣습니다.
• 세분화된 TTL: 모든 데이터에 동일한 TTL을 적용하기보다, 각 데이터의 중요도와 변경 빈도에 따라 TTL을 다르게 설정하여 캐시 만료 시점을 분산시킵니다.
• 소프트 만료 (Soft Expiry): TTL이 만료되었더라도 즉시 데이터를 삭제하지 않고, 백그라운드에서 비동기적으로 갱신을 시도하는 동안에는 오래된 데이터를 제공하는 방식입니다.

3. 과도한 캐싱 또는 잘못된 캐싱 대상

문제: 모든 데이터를 캐싱하려고 하거나, 캐싱할 가치가 없는(예: 거의 접근되지 않거나, 항상 최신이어야 하는) 데이터를 캐싱하여 메모리 낭비, 복잡성 증가, 데이터 불일치 위험만 초래하는 경우입니다. 해결법:

• 신중한 대상 선택: 캐싱은 "자주 접근되고, 변경이 잦지 않으며, 조회 비용이 비싼" 데이터에 집중해야 합니다.
• 모니터링: 캐시 히트율, 캐시 사용량, 캐시 미스율 등을 지속적으로 모니터링하여 캐싱 전략의 효과를 평가하고 최적화합니다.

4. 캐시 키 설계의 어려움

문제: 캐시 키를 어떻게 설계해야 효율적인 캐시 히트를 유도하고, 데이터 무효화를 쉽게 할 수 있을지 결정하기 어렵습니다. 너무 일반적이거나 너무 세분화된 키는 문제가 될 수 있습니다. 해결법:

• 예측 가능한 키: 요청 파라미터, 리소스 ID 등을 조합하여 예측 가능하고 고유한 키를 만듭니다. (예: user:{id}, product:{category}:{id})
• 계층적 키: 여러 레벨의 데이터에 대한 캐시를 관리할 때, 계층적인 키 구조를 사용하여 특정 범주의 캐시를 한 번에 무효화하기 용이하게 합니다. (예: product:{id}와 product_list:{category}를 구분)
• 해시 함수 활용: 키의 길이가 너무 길어질 경우, 해시 함수를 사용하여 키의 길이를 일정하게 유지하고 저장 공간을 절약합니다.

5. 분산 캐시의 일관성 문제

문제: 여러 서버에 분산된 캐시 인스턴스 간에 데이터가 불일치하는 경우입니다. 한 서버의 캐시가 업데이트되었지만 다른 서버의 캐시는 여전히 오래된 데이터를 가지고 있을 수 있습니다. 해결법:

• 일관성 모델 선택:
  • 결과적 일관성 (Eventual Consistency): 대부분의 분산 캐시 시스템이 채택하는 방식으로, 일정 시간 후에는 모든 캐시 인스턴스가 동일한 데이터를 가지게 됩니다.
  • 강력한 일관성 (Strong Consistency): 모든 캐시 인스턴스가 항상 최신 데이터를 가지도록 보장하지만, 성능 오버헤드가 크고 구현이 복잡합니다. (대부분의 캐싱 시나리오에서는 불필요)
• 중앙 집중식 캐시 시스템 활용: Redis Cluster와 같은 분산 캐시 시스템은 데이터 샤딩 및 복제 기능을 제공하여 일관성 관리를 돕습니다.
• 발행/구독 모델: 데이터 변경 시 모든 캐시 노드에 무효화 이벤트를 전파하여 캐시를 일관되게 유지합니다.

6. 더 공부할 리소스 추천

캐싱은 깊이 파고들수록 흥미로운 주제입니다. 더 심도 있는 학습을 위해 다음 리소스들을 추천합니다.

• Redis 공식 문서: Redis는 캐싱의 대명사입니다. 공식 문서를 통해 Redis의 데이터 구조, 명령어, 클러스터링, 영속성 등 다양한 기능을 익힐 수 있습니다.
  • Redis Documentation
• Memcached 공식 문서: Redis와 함께 널리 사용되는 또 다른 인메모리 캐시 시스템입니다. Redis보다는 기능이 제한적이지만 단순 캐싱에 매우 효율적입니다.
  • Memcached Wiki
• Martin Fowler의 블로그 - Cache (2002): 비록 오래된 글이지만, 캐싱의 근본적인 개념과 문제점들을 명확하게 설명해 줍니다.
  • https://martinfowler.com/bliki/Cache.html
• High Performance Browser Networking - Ilya Grigorik (O'Reilly): 웹 성능 최적화에 대한 전반적인 내용을 다루며, HTTP 캐싱에 대한 깊이 있는 이해를 제공합니다.
  • https://hpbn.co/
• Udemy, Coursera 등 온라인 강의: "System Design Interview" 관련 강의들은 캐싱 전략을 포함한 다양한 시스템 설계 패턴을 다룹니다.

캐싱은 단순히 데이터를 빨리 가져오는 기술을 넘어, 시스템의 아키텍처와 성능, 안정성, 비용 효율성에 지대한 영향을 미치는 핵심 기술입니다. 이 글을 통해 캐싱의 기본기를 다지고, 여러분의 시스템에 현명하게 적용하여 더 나은 소프트웨어를 만드는 데 도움이 되기를 바랍니다.