LangGraph 장기 메모리 완벽 가이드

LangGraph에서 Store를 활용한 장기 메모리 구현 방법을 알아봅니다. namespace와 key를 통한 계층적 데이터 관리부터 Semantic Search까지 실무에서 바로 적용할 수 있는 내용을 다룹니다.

---

목차

1. Store_개념과_구조
2. namespace와_key_계층화
3. InMemoryStore_설정
4. runtime_store_put_저장
5. runtime_store_get_조회
6. Semantic_Search_활용

---

1. Store 개념과 구조

김개발 씨는 챗봇 프로젝트를 진행하던 중 고민에 빠졌습니다. 사용자가 "지난번에 말했던 내 취미 기억해?"라고 물으면 챗봇이 멀뚱멀뚱 아무것도 모르는 척하는 겁니다.

분명 어제 대화에서 사용자가 등산을 좋아한다고 했는데 말이죠.

Store는 LangGraph에서 제공하는 장기 메모리 저장소입니다. 마치 도서관의 서고처럼 정보를 체계적으로 보관하고 필요할 때 꺼내 쓸 수 있습니다.

대화가 끝나도 사라지지 않는 영구적인 기억 공간이라고 생각하면 됩니다.

다음 코드를 살펴봅시다.

from langgraph.store.memory import InMemoryStore

# Store 생성 - 장기 메모리의 시작점
store = InMemoryStore()

# Store의 기본 구조
# namespace: 데이터를 분류하는 폴더 역할
# key: 각 데이터를 식별하는 파일명 역할
# value: 실제 저장되는 데이터

# 예시: 사용자 정보 저장
namespace = ("users", "user_123")
key = "preferences"
value = {"hobby": "등산", "food": "한식"}

김개발 씨는 입사 6개월 차 AI 개발자입니다. 최근 회사에서 고객 상담 챗봇을 개발하는 프로젝트에 투입되었습니다.

기본적인 대화 기능은 구현했지만, 한 가지 큰 문제가 있었습니다. "김 개발자, 우리 챗봇이 왜 사용자가 어제 말한 걸 기억 못 하죠?" 팀장님의 질문에 김개발 씨는 머리를 긁적였습니다.

현재 구조에서는 대화가 끝나면 모든 정보가 사라지기 때문입니다. 선배 개발자 박시니어 씨가 다가와 설명을 시작했습니다.

"LangGraph의 Store를 사용해 보세요. 장기 메모리를 구현할 수 있어요." 그렇다면 Store란 정확히 무엇일까요?

쉽게 비유하자면, Store는 마치 개인 비서의 수첩과 같습니다. 비서가 중요한 정보를 수첩에 적어두고 나중에 필요할 때 찾아보듯이, Store도 애플리케이션이 기억해야 할 정보를 저장해두고 필요할 때 꺼내줍니다.

LangGraph에서 메모리는 크게 두 종류로 나뉩니다. 하나는 단기 메모리로, 현재 대화의 맥락을 유지하는 역할을 합니다.

다른 하나는 장기 메모리로, 여러 대화 세션에 걸쳐 정보를 유지합니다. Store는 바로 이 장기 메모리를 담당합니다.

Store가 없던 시절에는 어땠을까요? 개발자들은 외부 데이터베이스를 직접 연동해야 했습니다.

Redis나 PostgreSQL을 설정하고, 연결 코드를 작성하고, 에러 처리까지 신경 써야 했습니다. 간단한 프로토타입을 만들 때도 이런 복잡한 작업이 필요했습니다.

바로 이런 불편함을 해결하기 위해 LangGraph는 Store라는 추상화 계층을 제공합니다. Store의 내부 구조를 살펴보면, 크게 세 가지 요소로 구성됩니다.

namespace는 데이터를 분류하는 폴더 역할을 합니다. key는 각 데이터를 식별하는 파일명입니다.

value는 실제 저장되는 데이터입니다. 이 구조 덕분에 사용자별, 기능별로 데이터를 깔끔하게 정리할 수 있습니다.

마치 잘 정돈된 서류 캐비닛처럼 원하는 정보를 빠르게 찾을 수 있습니다. 실제 현업에서는 어떻게 활용할까요?

예를 들어 쇼핑몰 챗봇을 개발한다고 가정해봅시다. 사용자의 선호 브랜드, 최근 본 상품, 사이즈 정보 등을 Store에 저장해두면, 다음 방문 시 "지난번에 보신 운동화가 할인 중이에요"라고 맞춤 안내를 할 수 있습니다.

다시 김개발 씨의 이야기로 돌아가 봅시다. 박시니어 씨의 설명을 들은 김개발 씨는 눈이 반짝였습니다.

"아, 그래서 Store를 쓰는 거군요!"

실전 팁

💡 - Store는 그래프 실행과 독립적으로 동작하므로 여러 대화에서 공유할 수 있습니다

• 개발 단계에서는 InMemoryStore로 시작하고, 프로덕션에서는 영구 저장소로 전환하세요

---

2. namespace와 key 계층화

김개발 씨가 Store를 사용하기 시작했습니다. 그런데 며칠 지나니 데이터가 뒤죽박죽 섞여버렸습니다.

어떤 데이터가 어느 사용자 것인지, 어떤 용도인지 구분하기 어려워졌습니다. 박시니어 씨가 다가와 물었습니다.

"namespace 제대로 설계했어요?"

namespace는 데이터를 계층적으로 분류하는 튜플입니다. 마치 파일 시스템의 폴더 구조처럼 여러 단계로 나눌 수 있습니다.

이를 통해 사용자별, 기능별, 시점별로 데이터를 체계적으로 관리할 수 있습니다.

다음 코드를 살펴봅시다.

from langgraph.store.memory import InMemoryStore

store = InMemoryStore()

# 계층적 namespace 설계
# 1단계: 서비스 영역 (users, products, orders)
# 2단계: 고유 식별자 (user_id, product_id)
# 3단계: 데이터 유형 (preferences, history)

# 사용자 선호도 저장
user_namespace = ("users", "user_123", "preferences")

# 사용자 대화 히스토리 저장
history_namespace = ("users", "user_123", "history")

# 상품 정보 저장
product_namespace = ("products", "electronics", "phones")

# key는 해당 namespace 내에서 고유해야 함
key = "latest"

김개발 씨는 Store에 데이터를 저장하기 시작했습니다. 처음에는 간단하게 사용자 ID만 namespace로 사용했습니다.

하지만 프로젝트가 커지면서 문제가 생겼습니다. "사용자의 선호도 데이터는 어디 있죠?" "대화 기록은요?" "최근 검색 이력은?" 매번 데이터를 찾을 때마다 혼란스러웠습니다.

박시니어 씨가 화이트보드에 그림을 그리며 설명했습니다. "namespace를 폴더 구조처럼 생각해 보세요." 그렇다면 namespace 설계는 어떻게 해야 할까요?

쉽게 비유하자면, namespace는 마치 주소 체계와 같습니다. "서울시 강남구 테헤란로 123번지"처럼 큰 범위에서 작은 범위로 좁혀가는 구조입니다.

이렇게 하면 원하는 위치를 정확히 찾을 수 있습니다. LangGraph의 namespace는 튜플 형태로 표현됩니다.

예를 들어 ("users", "user_123", "preferences")는 "users 폴더 안의 user_123 폴더 안의 preferences"를 의미합니다. 계층 설계의 핵심 원칙이 있습니다.

첫째, 첫 번째 단계는 서비스 영역을 나타냅니다. users, products, orders처럼 큰 도메인으로 구분합니다.

둘째, 두 번째 단계는 고유 식별자입니다. user_id나 product_id처럼 특정 엔티티를 식별합니다.

셋째, 세 번째 단계는 데이터 유형입니다. preferences, history, settings처럼 어떤 종류의 데이터인지 나타냅니다.

key는 namespace 내에서 개별 항목을 식별합니다. 같은 namespace 안에서는 key가 고유해야 합니다.

하지만 다른 namespace에서는 같은 key를 사용해도 됩니다. 실무에서 흔히 사용하는 패턴을 살펴보겠습니다.

멀티테넌트 서비스의 경우 ("tenants", tenant_id, "users", user_id)처럼 테넌트를 최상위에 둡니다. 이렇게 하면 테넌트별로 데이터가 완전히 분리됩니다.

시간 기반 데이터의 경우 ("users", user_id, "daily_summary", "2024-01-15")처럼 날짜를 key로 사용합니다. 특정 기간의 데이터를 쉽게 조회할 수 있습니다.

주의할 점도 있습니다. namespace를 너무 깊게 설계하면 관리가 어려워집니다.

보통 3~4단계가 적당합니다. 또한 namespace에 자주 변하는 값을 넣으면 데이터가 흩어질 수 있습니다.

김개발 씨는 고개를 끄덕였습니다. "아, 처음부터 구조를 잘 잡아야 하는군요!"

실전 팁

💡 - namespace는 3~4단계로 유지하고, 더 세분화가 필요하면 key에서 처리하세요

• 자주 함께 조회하는 데이터는 같은 namespace에 두는 것이 효율적입니다

---

3. InMemoryStore 설정

"일단 빠르게 프로토타입을 만들어 보세요." 팀장님의 지시를 받은 김개발 씨는 복잡한 데이터베이스 설정 없이 바로 테스트할 방법을 찾기 시작했습니다. 박시니어 씨가 말했습니다.

"InMemoryStore로 시작해 보세요. 설정이 거의 필요 없어요."

InMemoryStore는 메모리 기반의 Store 구현체입니다. 별도의 데이터베이스 없이 바로 사용할 수 있어 개발과 테스트에 최적입니다.

프로세스가 종료되면 데이터가 사라지므로 프로덕션에서는 영구 저장소로 전환해야 합니다.

다음 코드를 살펴봅시다.

from langgraph.store.memory import InMemoryStore
from langgraph.graph import StateGraph
from langgraph.checkpoint.memory import MemorySaver

# InMemoryStore 생성
store = InMemoryStore()

# MemorySaver는 단기 메모리(체크포인트)용
checkpointer = MemorySaver()

# 그래프 정의
graph_builder = StateGraph(State)
# ... 노드 추가 ...

# 그래프 컴파일 시 store 연결
graph = graph_builder.compile(
    checkpointer=checkpointer,  # 단기 메모리
    store=store                  # 장기 메모리
)

# 이제 그래프 내에서 store 사용 가능

김개발 씨는 챗봇 프로토타입을 빠르게 만들어야 했습니다. 데이터베이스를 설치하고 설정하는 데만 반나절이 걸릴 것 같았습니다.

이런 상황에서 InMemoryStore는 구세주 같은 존재입니다. 박시니어 씨가 설명을 이어갔습니다.

"InMemoryStore는 말 그대로 메모리에 데이터를 저장해요. 설정할 게 거의 없죠." 그렇다면 InMemoryStore는 어떻게 사용할까요?

쉽게 비유하자면, InMemoryStore는 마치 화이트보드와 같습니다. 빠르게 적고 지울 수 있어서 아이디어 회의에 딱 좋습니다.

하지만 회의실 문을 닫으면 내용이 사라지듯, 프로세스가 종료되면 데이터도 사라집니다. 코드를 살펴보면, InMemoryStore()를 호출하는 것만으로 Store가 생성됩니다.

복잡한 연결 문자열도, 인증 설정도 필요 없습니다. 여기서 중요한 개념이 등장합니다.

LangGraph에서 checkpointer와 store는 다른 역할을 합니다. checkpointer는 단기 메모리를 담당합니다.

현재 대화의 상태, 메시지 히스토리 같은 것들을 저장합니다. 대화가 끝나면 필요 없어지는 정보입니다.

store는 장기 메모리를 담당합니다. 사용자 선호도, 학습된 정보처럼 여러 대화에 걸쳐 유지해야 하는 정보입니다.

그래프를 컴파일할 때 두 가지를 모두 연결합니다. compile(checkpointer=..., store=...)처럼 각각 전달하면 됩니다.

실제 개발 흐름은 이렇습니다. 먼저 InMemoryStore로 기능을 개발하고 테스트합니다.

로컬에서 빠르게 반복 개발이 가능합니다. 기능이 완성되면 프로덕션용 저장소로 교체합니다.

Store의 인터페이스가 동일하므로 코드 변경이 최소화됩니다. 주의할 점이 있습니다.

InMemoryStore는 프로세스가 재시작되면 모든 데이터가 사라집니다. 따라서 프로덕션 환경에서는 반드시 영구 저장소를 사용해야 합니다.

LangGraph는 PostgreSQL 기반의 저장소도 제공합니다. 김개발 씨는 빠르게 코드를 작성했습니다.

5분도 안 되어 기본 설정이 완료되었습니다.

실전 팁

💡 - 개발 중에는 InMemoryStore로 빠르게 테스트하고, 배포 전에 영구 저장소로 전환하세요

• checkpointer와 store를 혼동하지 마세요. 전자는 단기, 후자는 장기 메모리입니다

---

4. runtime store put 저장

InMemoryStore 설정을 마친 김개발 씨는 이제 실제로 데이터를 저장해보려 합니다. "그런데 Store에 어떻게 데이터를 넣죠?" 박시니어 씨가 웃으며 답했습니다.

"runtime의 store.put() 메서드를 사용하면 돼요."

store.put() 메서드는 Store에 데이터를 저장하는 핵심 기능입니다. namespace와 key를 지정하고 value를 저장합니다.

그래프의 노드 함수 내에서 runtime 파라미터를 통해 store에 접근할 수 있습니다.

다음 코드를 살펴봅시다.

from langgraph.config import RunnableConfig
from langgraph.store.base import BaseStore

def save_user_memory(state: State, config: RunnableConfig, *, store: BaseStore):
    # config에서 user_id 추출
    user_id = config["configurable"]["user_id"]

    # namespace 설정 - 사용자별 메모리 공간
    namespace = ("memories", user_id)

    # 저장할 데이터
    memory_data = {
        "preference": state["extracted_preference"],
        "timestamp": "2024-01-15T10:30:00"
    }

    # Store에 저장
    store.put(
        namespace=namespace,
        key="user_preferences",
        value=memory_data
    )

    return {"status": "saved"}

김개발 씨는 이제 Store에 데이터를 저장하는 방법을 배우려 합니다. 박시니어 씨가 화면을 가리키며 설명을 시작했습니다.

"LangGraph에서 Store에 접근하려면 노드 함수의 파라미터를 활용해야 해요." 그렇다면 store.put()은 어떻게 사용할까요? 쉽게 비유하자면, store.put()은 마치 파일을 저장하는 것과 같습니다.

어느 폴더에 저장할지(namespace), 파일명은 무엇인지(key), 파일 내용은 무엇인지(value)를 지정합니다. 노드 함수에서 Store에 접근하는 방법을 살펴보겠습니다.

함수 시그니처에 store: BaseStore를 추가합니다. LangGraph가 자동으로 Store 인스턴스를 주입해줍니다.

이것이 의존성 주입 패턴입니다. config: RunnableConfig 파라미터도 중요합니다.

여기서 user_id나 thread_id 같은 런타임 정보를 가져올 수 있습니다. 이 정보를 namespace에 활용하면 사용자별로 데이터를 분리할 수 있습니다.

store.put() 메서드의 파라미터를 살펴보겠습니다. namespace는 튜플 형태입니다.

앞서 배운 대로 계층적으로 설계합니다. key는 문자열입니다.

해당 namespace 내에서 고유해야 합니다. value는 딕셔너리 형태의 데이터입니다.

JSON으로 직렬화 가능한 데이터여야 합니다. 실무에서 자주 사용하는 패턴이 있습니다.

대화 중에 사용자의 선호도를 추출했다면, 그 즉시 Store에 저장합니다. 나중에 같은 사용자가 다시 대화를 시작하면, 저장된 선호도를 불러와 맞춤형 응답을 제공할 수 있습니다.

주의할 점도 있습니다. 같은 namespace와 key로 put()을 호출하면 기존 데이터가 덮어쓰기 됩니다.

데이터를 누적하고 싶다면 먼저 get()으로 기존 데이터를 가져온 후 병합해서 저장해야 합니다. 또한 value에 저장하는 데이터는 JSON 직렬화가 가능해야 합니다.

datetime 객체나 커스텀 클래스는 문자열로 변환해서 저장하세요. 김개발 씨가 코드를 작성하며 물었습니다.

"그럼 저장한 데이터는 어떻게 가져오나요?"

실전 팁

💡 - 같은 key로 put()하면 덮어쓰기 됩니다. 누적이 필요하면 get() 후 병합하세요

• config["configurable"]에서 user_id, thread_id 등 런타임 정보를 활용하세요

---

5. runtime store get 조회

"저장했으면 조회도 해야죠!" 김개발 씨는 신이 났습니다. 드디어 챗봇이 사용자를 기억할 수 있게 되는 겁니다.

박시니어 씨가 말했습니다. "store.get()을 사용하면 돼요.

저장할 때 사용한 namespace와 key를 그대로 쓰면 됩니다."

store.get() 메서드는 Store에서 데이터를 조회합니다. 저장할 때 사용한 namespace와 key를 지정하면 해당 데이터를 가져올 수 있습니다.

데이터가 없으면 None을 반환하므로 항상 존재 여부를 확인해야 합니다.

다음 코드를 살펴봅시다.

from langgraph.config import RunnableConfig
from langgraph.store.base import BaseStore

def load_user_memory(state: State, config: RunnableConfig, *, store: BaseStore):
    # config에서 user_id 추출
    user_id = config["configurable"]["user_id"]

    # namespace 설정 - 저장할 때와 동일하게
    namespace = ("memories", user_id)

    # Store에서 조회
    item = store.get(namespace=namespace, key="user_preferences")

    # 데이터 존재 여부 확인
    if item is not None:
        # item.value에 실제 데이터가 있음
        user_preferences = item.value
        return {"preferences": user_preferences}

    # 데이터가 없는 경우
    return {"preferences": None}

김개발 씨는 이제 저장한 데이터를 조회하는 방법을 배웁니다. 박시니어 씨가 차근차근 설명을 이어갔습니다.

"get()은 put()과 짝을 이루는 메서드예요. 저장할 때 사용한 namespace와 key를 그대로 사용하면 됩니다." 그렇다면 store.get()은 어떻게 사용할까요?

쉽게 비유하자면, get()은 마치 도서관에서 책을 찾는 것과 같습니다. "서울 도서관의 2층 서가에서 '파이썬 입문'이라는 책을 찾아주세요"처럼, namespace와 key를 정확히 지정해야 원하는 데이터를 찾을 수 있습니다.

코드를 자세히 살펴보겠습니다. store.get()은 namespace와 key 두 개의 파라미터를 받습니다.

저장할 때 사용한 값과 정확히 일치해야 합니다. 대소문자도 구분하니 주의하세요.

반환값이 중요합니다. get()이 반환하는 것은 단순한 딕셔너리가 아닙니다.

Item 객체입니다. 실제 데이터는 item.value에 들어있습니다.

데이터가 없는 경우 get()은 None을 반환합니다. 따라서 항상 if item is not None: 체크를 해야 합니다.

이걸 빼먹으면 AttributeError가 발생합니다. Item 객체에는 value 외에도 유용한 정보가 있습니다.

item.key는 해당 데이터의 키입니다. item.namespace는 namespace 정보입니다.

item.created_at과 item.updated_at은 생성 및 수정 시간입니다. 이런 메타데이터를 활용하면 데이터 관리가 더 수월해집니다.

실무에서의 활용 패턴을 살펴보겠습니다. 챗봇이 대화를 시작할 때 먼저 사용자 정보를 조회합니다.

"안녕하세요, 김철수 님! 지난번에 관심 보이셨던 등산화 할인 중이에요"처럼 개인화된 인사를 할 수 있습니다.

주의할 점이 있습니다. get()은 정확한 key를 알아야 합니다.

비슷한 key나 패턴으로는 찾을 수 없습니다. 여러 항목을 조회하고 싶다면 search() 메서드를 사용해야 합니다.

김개발 씨가 질문했습니다. "그럼 key를 모를 때는 어떻게 하죠?" 박시니어 씨가 미소 지었습니다.

"좋은 질문이에요. 바로 Semantic Search를 알아볼 차례네요."

실전 팁

💡 - get() 반환값은 Item 객체입니다. 실제 데이터는 item.value로 접근하세요

• 데이터가 없으면 None이 반환되므로 항상 존재 여부를 확인하세요

---

6. Semantic Search 활용

"사용자가 '예전에 말했던 음식 뭐였지?'라고 물으면 어떻게 찾죠? key를 정확히 모르는데요." 김개발 씨의 질문에 박시니어 씨가 눈을 빛냈습니다.

"바로 그럴 때 Semantic Search를 사용해요. 의미 기반으로 검색할 수 있거든요."

Semantic Search는 텍스트의 의미를 기반으로 유사한 데이터를 검색하는 기능입니다. 임베딩을 사용하여 저장된 데이터 중 질문과 의미적으로 관련된 항목을 찾아줍니다.

정확한 key를 몰라도 자연어로 검색할 수 있어 강력합니다.

다음 코드를 살펴봅시다.

from langgraph.store.memory import InMemoryStore

# 임베딩 함수 설정 - OpenAI 또는 다른 임베딩 모델 사용
from langchain_openai import OpenAIEmbeddings

# Semantic Search가 가능한 Store 생성
store = InMemoryStore(
    index={
        "embed": OpenAIEmbeddings(model="text-embedding-3-small"),
        "dims": 1536  # 임베딩 차원
    }
)

# 데이터 저장 시 자동으로 임베딩 생성
store.put(
    namespace=("memories", "user_123"),
    key="food_preference",
    value={"content": "사용자는 매운 한식을 좋아합니다"}
)

# 의미 기반 검색
results = store.search(
    namespace_prefix=("memories", "user_123"),
    query="좋아하는 음식이 뭐였지?",
    limit=3
)

# 검색 결과 활용
for item in results:
    print(f"관련 메모리: {item.value}")

김개발 씨는 마지막 퍼즐 조각을 찾은 기분이었습니다. 지금까지 배운 get()은 정확한 key를 알아야 했습니다.

하지만 실제 사용자는 "그거 뭐였더라?"처럼 모호하게 질문합니다. 박시니어 씨가 설명을 시작했습니다.

"Semantic Search는 의미를 이해해서 검색해요. 마치 똑똑한 비서처럼요." 그렇다면 Semantic Search는 어떻게 작동할까요?

쉽게 비유하자면, 일반 검색은 도서관에서 정확한 책 제목으로 찾는 것과 같습니다. "파이썬 입문"이라고 검색하면 그 책만 나옵니다.

반면 Semantic Search는 "프로그래밍 배우고 싶어요"라고 말해도 관련 책들을 추천해주는 AI 사서와 같습니다. 이 마법의 핵심은 임베딩입니다.

임베딩은 텍스트를 숫자 벡터로 변환합니다. 의미가 비슷한 텍스트는 비슷한 벡터값을 가집니다.

"매운 음식을 좋아한다"와 "좋아하는 음식"은 벡터 공간에서 가까운 위치에 있게 됩니다. Semantic Search를 사용하려면 Store 생성 시 index 설정을 추가합니다.

embed에는 임베딩 모델을 지정합니다. OpenAI의 text-embedding-3-small이 비용 대비 성능이 좋습니다.

dims는 임베딩 차원입니다. 사용하는 모델에 맞춰 설정합니다.

이렇게 설정하면 put()으로 데이터를 저장할 때 자동으로 임베딩이 생성됩니다. 별도로 임베딩을 계산하는 코드를 작성할 필요가 없습니다.

검색은 search() 메서드를 사용합니다. namespace_prefix는 검색 범위를 지정합니다.

튜플의 앞부분만 일치하면 됩니다. query는 자연어 질문입니다.

limit은 최대 결과 개수입니다. 실무 활용 시나리오를 살펴보겠습니다.

사용자가 "전에 얘기했던 여행 계획 있잖아"라고 말합니다. 챗봇은 search()로 "여행 계획"과 의미적으로 관련된 메모리를 찾습니다.

"제주도 여행 일정"이라는 메모리가 검색됩니다. 챗봇이 "제주도 여행 일정 말씀이시죠?"라고 응답합니다.

주의할 점도 있습니다. 임베딩 모델 API 호출에는 비용이 발생합니다.

저장할 데이터가 많다면 비용을 고려해야 합니다. 또한 임베딩 계산에 시간이 걸리므로 실시간 성능에 영향을 줄 수 있습니다.

김개발 씨는 감탄했습니다. "이제 정말 똑똑한 챗봇을 만들 수 있겠네요!" 박시니어 씨가 고개를 끄덕였습니다.

"맞아요. Store, namespace, put, get, 그리고 Semantic Search.

이 다섯 가지를 마스터하면 장기 메모리는 완벽해요."

실전 팁

💡 - 임베딩 모델은 비용과 성능을 고려해 선택하세요. text-embedding-3-small이 균형 잡힌 선택입니다

• search()의 namespace_prefix를 활용하면 특정 사용자나 도메인으로 검색 범위를 제한할 수 있습니다

---

이상으로 학습을 마칩니다. 위 내용을 직접 코드로 작성해보면서 익혀보세요!