18. Session/Memory/Artifact [7]- VertexAiSessionService(3/3)

이번 실습은 단순히 VertexAiSessionService를 실행한 정도가 아니라, 로컬에서 실행하는 ADK 에이전트에 Google Cloud의 관리형 세션 서비스를 연결하고, 서버를 재시작한 뒤에도 대화 맥락이 유지되는 것을 검증한 것입니다.

 

특히 "오늘 서울 날씨 어때?"라고 질문한 다음 로컬 웹 서버를 종료하고 다시 실행한 뒤 "내일은?"이라고 물어 정상적으로 답변을 받았다면, 중요한 검증을 통과하신 것입니다.

1. 이번 실습에서 확인한 핵심

  ① Agent Engine 인스턴스 생성 및 ID 확보

    Google Cloud에 생성한 Agent Engine 인스턴스 ID를 확인하고 세션 서비스에 전달했습니다.

  ② VertexAiSessionService 연결

    기존의 InMemorySessionService 대신 Google Cloud에서 관리하는 세션 서비스를 사용하도록 구성했습니다.

  ③ 대화 맥락 유지 확인

    첫 질문에서 서울 날씨를 물은 뒤, 서버 재시작 후 "내일은?"이라고 질문했을 때 서울이라는 지역을 다시 묻지 않고 답변했습니다.

2. InMemorySessionService와 무엇이 다른가?

구분	InMemorySessionService	VertexAiSessionService
세션 저장 위치	실행 중인 프로세스의 메모리	Google Cloud의 관리형 세션 저장소
로컬 서버 재시작	기존 세션이 사라짐	기존 세션을 다시 조회할 수 있음
다른 실행 환경과 공유	기본적으로 불가능	동일한 프로젝트·인스턴스와 세션 식별 정보를 사용해 접근 가능
적합한 용도	학습, 테스트, 간단한 개발	지속적인 대화, 운영 서비스
운영 고려사항	서버 메모리 관리	IAM 권한, 비용, 세션 식별 및 데이터 관리

중요한 차이는 에이전트가 실행되는 장소와 세션이 저장되는 장소가 분리되었다는 점입니다.

로컬 PC에서 adk web을 실행하더라도 대화 세션은 Google Cloud의 관리형 서비스에 저장할 수 있습니다. 따라서 로컬 웹 서버가 종료되더라도 세션 데이터 자체는 유지될 수 있습니다.

3. 이번 실습의 전체 구조

 

여기서 한 가지 구분할 점이 있습니다. 세션 서비스가 대화 기록을 보존하는 것과 에이전트가 날씨 정보를 가져오는 것은 서로 다른 기능입니다. 날씨 정보는 기존에 구현한 날씨 도구가 제공하고, 세션 서비스는 "내일은?"이라는 질문을 이해하는 데 필요한 이전 대화 맥락을 보존합니다.

또한 서버 재시작 후에도 기존 대화가 이어졌다는 것은 성공적인 검증이지만, 엄밀하게는 같은 세션 ID로 기존 세션을 다시 조회했다는 점까지 확인하면 세션 지속성을 더욱 확실하게 검증할 수 있습니다.

 

4. Google ADK 실습 정리: VertexAiSessionService로 대화 세션 유지하기

1) 실습 목표

이번 실습의 목표는 로컬 PC에서 실행하는 Google ADK 에이전트에 Google Cloud의 관리형 세션 서비스를 연결하여, 웹 서버를 종료하고 다시 실행해도 기존 대화 맥락을 유지할 수 있는지 검증하는 것이다.

실습의 핵심 질문은 다음과 같다.

로컬에서 adk web으로 실행하는 에이전트가 대화 세션을 Google Cloud에 저장하면, 서버를 재시작한 뒤에도 이전 대화의 맥락을 이어갈 수 있을까?

이를 확인하기 위해 기존의 InMemorySessionService 대신 VertexAiSessionService를 사용했다.

실습 결과

• Google Cloud에 Agent Engine 인스턴스를 생성했다.
• 생성된 Agent Engine의 ID를 확인했다.
• ADK 에이전트에 VertexAiSessionService를 연결했다.
• "오늘 서울 날씨 어때?"라고 질문했다.
• 로컬 ADK Web 서버를 종료하고 다시 실행했다.
• 동일한 대화 세션에서 "내일은?"이라고 질문했다.
• 에이전트가 이전 대화의 서울이라는 지역 정보를 활용하여 답변하는 것을 확인했다.

따라서 로컬 서버 재시작 이후에도 기존 세션의 대화 맥락을 이어갈 수 있음을 확인했다.

---

2) 전체 구조 이해하기

이번 실습에서 가장 중요한 개념은 에이전트 실행 환경과 세션 저장소가 분리된다는 점이다.

사용자
  │
  ▼
웹 브라우저
  │
  ▼
로컬 PC의 ADK Web
  │
  ▼
ADK Agent
  │
  ├── 날씨 도구
  │     └── 서울의 오늘·내일 날씨 조회
  │
  └── VertexAiSessionService
        │
        ▼
      Google Cloud
      Agent Engine 기반 관리형 세션

각 구성요소의 역할은 다음과 같다.

구성 요소	역할
ADK Agent	사용자의 질문을 이해하고 답변을 구성한다.
날씨 도구	실제 날씨 데이터를 제공한다.
ADK Web	브라우저에서 에이전트와 대화할 수 있도록 로컬 웹 서버를 실행한다.
InMemorySessionService	실행 중인 프로세스의 메모리에 세션을 저장한다.
VertexAiSessionService	Google Cloud의 관리형 세션 서비스에 세션을 저장하고 조회한다.
Agent Engine 인스턴스	Google Cloud에서 세션 서비스를 사용할 때 지정하는 대상 리소스다.

여기서 중요한 점은 VertexAiSessionService가 날씨를 조회하는 기능을 제공하는 것이 아니라는 사실이다. 날씨 조회는 날씨 도구의 역할이고, 세션 서비스는 이전 대화 내용을 유지하고 불러오는 역할을 담당한다.

---

3) 실습 환경

3-1. 로컬 개발 환경

이번 실습에서 사용한 주요 환경은 다음과 같다.

항목설정

운영체제	Windows
개발 언어	Python
가상환경	C:\Dev\book_agentic_ai\venv
프로젝트 위치	C:\Dev\book_agentic_ai\adk\_\hello_agent
Google ADK	2.13.0
google-cloud-aiplatform	2.6.0
웹 서버 실행 방식	adk web
Google Cloud 프로젝트 ID	agent-project-512212
Google Cloud 리전	asia-northeast3

버전은 이번 실습 당시 확인한 값이다. 이후 재현할 때는 현재 설치된 버전을 확인하는 것이 좋다.

3-2. Python 가상환경 활성화

PowerShell에서 다음 명령어를 실행한다.

conda activate i_py310_64

위 명령은 해당 Conda 환경을 사용하는 경우에만 필요하다. 이후 이번 프로젝트에서 사용하던 가상환경을 활성화한다.

& "C:\Dev\book_agentic_ai\venv\Scripts\Activate.ps1"

가상환경이 활성화되면 터미널 앞부분에 (venv)가 표시된다.

현재 Python과 패키지 버전을 확인한다.

python --version
python -m pip show google-adk
python -m pip show google-cloud-aiplatform

프로젝트에서 사용하는 Python 버전과 설치된 패키지 버전을 확인해 두면, 나중에 오류가 발생했을 때 원인을 추적하기 쉽다.

---

4) Google Cloud 프로젝트 준비

4-1. 프로젝트 ID와 리전 설정

이번 실습에서는 다음 값을 사용했다.

PROJECT_ID   = agent-project-512212
LOCATION     = asia-northeast3

PROJECT_ID는 Google Cloud 프로젝트를 식별하는 문자열이다.

LOCATION은 Google Cloud 리전이다. 이번 실습에서는 서울 리전에 해당하는 asia-northeast3를 사용했다.

프로젝트 ID와 리전은 서로 다른 값이며, 둘을 혼동하면 안 된다.

4-2. PowerShell 환경변수 설정

$env:GOOGLE_CLOUD_PROJECT="agent-project-512212"
$env:GOOGLE_CLOUD_LOCATION="asia-northeast3"

환경변수는 프로그램이 실행될 때 프로젝트와 리전 정보를 참조할 수 있도록 해준다.

주의할 점은 PowerShell에서 설정한 $env: 환경변수가 일반적으로 현재 터미널 세션에 적용된다는 것이다. 새 터미널을 열었다면 다시 설정하거나 별도의 영구 환경변수 설정을 사용해야 한다.

4-3. Google Cloud 인증

로컬에서 Google Cloud 리소스에 접근하려면 인증이 필요하다.

gcloud auth login
gcloud auth application-default login

두 명령의 목적은 서로 다르다.

• gcloud auth login: gcloud 명령줄 도구에서 사용할 계정을 인증한다.
• gcloud auth application-default login: 로컬에서 실행되는 Google Cloud SDK 기반 Python 프로그램이 사용할 Application Default Credentials(ADC)를 설정한다.

Python 프로그램이 Google Cloud API를 호출할 때는 ADC가 중요하다.

4-4. API, 권한 및 결제 확인

실습 전 확인해야 하는 항목은 다음과 같다.

1. Google Cloud 프로젝트가 정상적으로 존재하는가?
2. Vertex AI API가 활성화되어 있는가?
3. 결제 계정이 프로젝트에 연결되어 있는가?
4. 현재 사용자에게 필요한 리소스 생성 및 조회 권한이 있는가?
5. Agent Engine 실행 서비스 계정에 필요한 권한이 부여되어 있는가?
6. 사용하려는 리전에서 필요한 기능을 지원하는가?

인증에 성공했다고 해서 모든 리소스에 접근할 수 있는 것은 아니다. 사용자 계정의 권한과 Agent Engine이 사용하는 서비스 계정의 권한도 구분해야 한다.

---

5) Cloud Storage 스테이징 버킷 준비

처음 Agent Engine을 생성할 때는 에이전트 코드를 패키징하여 업로드할 Cloud Storage 버킷이 필요했다.

기존 버킷은 다음과 같이 확인할 수 있다.

gcloud storage buckets list --project=agent-project-512212

버킷이 없다면 적절한 이름으로 생성한다. 버킷 이름은 전역적으로 고유해야 하며, 리전과 조직의 정책도 확인해야 한다.

예를 들어 다음은 형식만 보여주는 예시다.

gs://my-unique-agent-staging-bucket

실제 코드에는 반드시 본인이 생성했거나 접근 권한이 있는 버킷을 입력해야 한다.

이번 실습에서는 다음과 같은 스테이징 경로가 출력되었다.

gs://agent-project_512212-staging/agent_engine/agent_engine.pkl

이 경로는 Agent Engine 배포 패키지가 저장된 위치다. 이후 다시 실습할 때는 출력된 실제 경로를 확인해야 하며, 예시 경로를 무조건 복사해서 사용하면 안 된다.

---

6)  Agent Engine 인스턴스 생성

6-1. 처음 사용한 생성 코드

이번 실습에서는 vertexai.Client()와 client.agent_engines.create()를 이용해 Agent Engine 리소스를 생성했다.

코드의 핵심 구조는 다음과 같다.

import vertexai

PROJECT_ID = "agent-project-512212"
LOCATION = "asia-northeast3"
STAGING_BUCKET = "gs://실제-버킷-이름"

class SimpleAgent:
    def query(self, input: str, **kwargs):
        return {
            "message": f"Hello from Agent Engine: {input}"
        }

client = vertexai.Client(
    project=PROJECT_ID,
    location=LOCATION,
)

remote_agent = client.agent_engines.create(
    agent=SimpleAgent(),
    config={
        "display_name": "my-agent-engine",
        "description": (
            "Created with vertexai.Client().agent_engines.create()"
        ),
        "staging_bucket": STAGING_BUCKET,
        "requirements": [
            "google-cloud-aiplatform[agent_engines, adk]==1.141.0",
            "cloudpickle==3.0.0",
            "pydantic==2.12.3",
        ],
    },
)

print(remote_agent)

위 코드는 구조를 이해하기 위한 예시다. STAGING_BUCKET에는 실제 버킷 주소를 넣어야 하며, 의존성 버전은 현재 환경 및 배포 방식에 맞게 확인해야 한다.

6-2. 코드의 주요 부분 해설

① import vertexai

Google Cloud의 Vertex AI SDK를 불러온다.

② SimpleAgent 클래스

class SimpleAgent:
    def query(self, input: str, **kwargs):
        return {
            "message": f"Hello from Agent Engine: {input}"
        }

사용자가 전달한 입력을 받아 문자열 형태의 응답을 반환하는 간단한 에이전트다.

이 클래스는 ADK로 만든 날씨 에이전트와 동일한 코드가 아니다. 이번 생성 코드에서는 Agent Engine에 배포할 수 있는 간단한 객체를 사용했다.

③ vertexai.Client(...)

client = vertexai.Client(
    project=PROJECT_ID,
    location=LOCATION,
)

Google Cloud 프로젝트와 리전을 지정해 클라이언트를 생성한다.

④ client.agent_engines.create(...)

remote_agent = client.agent_engines.create(
    agent=SimpleAgent(),
    config={...},
)

Agent Engine 리소스의 생성을 요청한다.

display_name은 콘솔에서 리소스를 구분하기 위한 표시 이름이다. requirements는 배포 환경에서 필요한 Python 패키지를 지정한다.

6-3. 생성 결과 확인

이번 실행 결과에는 다음과 같은 정보가 출력되었다.

display_name='my-agent-engine'
agent_framework='custom'
...
pickle_object_gcs_uri='gs://.../agent_engine.pkl'
requirements_gcs_uri='gs://.../requirements.txt'
...
Resource name:
projects/92186***%%$$$6/locations/asia-northeast3/reasoningEngines/25286$$$%%%****

이 출력에서 확인할 수 있는 사항은 다음과 같다.

• display_name: 생성한 리소스의 표시 이름
• agent_framework='custom': 배포한 에이전트가 사용자 정의 방식으로 등록되었음을 나타내는 정보
• pickle_object_gcs_uri: 패키징된 에이전트 객체가 저장된 위치
• requirements_gcs_uri: 배포 환경의 의존성 정보가 저장된 위치
• Resource name: 생성된 리소스의 전체 이름

출력에 리소스 정보가 반환되었으므로 생성 요청이 성공적으로 처리된 것으로 판단할 수 있다. 다만 경고가 함께 출력되었다면 배포 상태와 원격 실행까지 별도로 점검하는 것이 좋다.

6-4. 의존성 경고에 대한 주의

당시 실행 결과에는 다음과 같은 경고가 나타났다.

The following requirements are incompatible:
pydantic==2.13.5 (required: ==2.12.3)
cloudpickle==3.1.2 (required: ==3.0.0)

이 경고는 현재 환경에서 확인된 패키지 버전과 배포 설정에 지정한 버전이 서로 다르다는 의미다.

리소스 생성 결과가 출력되었다고 해서 모든 의존성 문제가 해결되었다는 뜻은 아니다. 향후 배포 에이전트를 실제로 원격 실행할 때 문제가 발생한다면 이 부분을 먼저 점검한다.

또한 vertexai.Client 관련 deprecation 경고도 출력되었다. 새 프로젝트에서는 현재 Google Cloud SDK 문서에서 권장하는 클라이언트와 생성 API를 확인한 뒤 사용하는 것이 좋다.

---

7) Agent Engine ID 추출

세션 서비스에 연결하려면 생성된 Agent Engine 리소스의 ID가 필요하다.

이번 실습에서 확인한 리소스 전체 이름은 다음과 같다.

projects/****%%%%$$$$/locations/asia-northeast3/reasoningEngines/2528612$$$$%%%%****

구조를 나누어 보면 다음과 같다.

구성요소값

프로젝트 번호	921**********
리전	asia-northeast3
리소스 유형	reasoningEngines
Agent Engine ID	252861******************

여기서 Agent Engine ID는 전체 리소스 이름의 마지막 부분이다.

Python에서는 다음과 같이 추출할 수 있다.

resource_name = remote_agent.api_resource.name
agent_engine_id = resource_name.split("/")[-1]

print(agent_engine_id)

예상 출력:

252861286********

이 값을 이후 VertexAiSessionService의 agent_engine_id에 전달한다.

중요한 점은 프로젝트 ID와 Agent Engine ID가 서로 다른 값이라는 것이다.

• 프로젝트 ID: agent-project-512212
• Agent Engine ID: 252861*************60

둘을 바꾸어 넣으면 안 된다.

---

8. VertexAiSessionService 연결

8-1. InMemorySessionService에서 변경한 이유

기존의 InMemorySessionService는 실행 중인 Python 프로세스의 메모리에 세션을 저장한다.

따라서 일반적으로 서버가 종료되면 메모리에 있던 세션도 사라진다.

반면 VertexAiSessionService는 Google Cloud의 관리형 세션 서비스와 연동한다. 로컬 웹 서버가 종료되더라도 세션이 클라우드에 남아 있다면 같은 세션을 다시 조회할 수 있다.

8-2. 핵심 코드

기존 에이전트의 다른 부분은 유지하고, 세션 서비스 설정을 다음과 같은 형태로 구성한다.

from google.adk.sessions import VertexAiSessionService

PROJECT_ID = "agent-project-512212"
LOCATION = "asia-northeast3"
AGENT_ENGINE_ID = "2528*********3760"

session_service = VertexAiSessionService(
    project=PROJECT_ID,
    location=LOCATION,
    agent_engine_id=AGENT_ENGINE_ID,
)

각 인자의 역할은 다음과 같다.

project

세션 서비스를 사용할 Google Cloud 프로젝트를 지정한다.

location

Agent Engine 리소스가 생성된 리전을 지정한다.

agent_engine_id

세션을 저장하고 조회할 대상 Agent Engine 리소스의 ID를 지정한다.

이 세 값이 올바르게 연결되어야 한다.

8-3. Agent 실행 구성에 연결하기

세션 서비스를 생성하는 것만으로는 충분하지 않다. 실제 ADK 애플리케이션에서 해당 객체를 사용하도록 연결해야 한다.

일반적인 구성은 다음과 같다.

from google.adk.runners import Runner

runner = Runner(
    agent=root_agent,
    app_name=APP_NAME,
    session_service=session_service,
)

root_agent와 APP_NAME은 기존 프로젝트에서 사용하던 에이전트와 애플리케이션 이름을 의미한다.

실제 코드에서는 기존 Runner 생성 부분을 확인하고, 거기에 session_service=session_service가 전달되는지 확인해야 한다. 기존 코드의 구조에 따라 세부적인 위치는 다를 수 있다.

이번 실습에서는 기존 ADK 에이전트의 실행 구성에 VertexAiSessionService를 연결하고 adk web으로 실행했다.

---

9) ADK Web 실행

프로젝트 폴더에서 가상환경이 활성화되어 있는지 확인한 뒤 실행한다.

cd "C:\Dev\book_agentic_ai\adk\_\hello_agent"
adk web

ADK Web이 실행되면 터미널에 로컬 접속 주소가 표시된다. 해당 주소를 브라우저에서 연다.

이때 확인할 사항은 다음과 같다.

1. 에이전트가 정상적으로 검색되는가?
2. 웹 화면에서 에이전트를 선택할 수 있는가?
3. 날씨 질문에 정상적으로 답변하는가?
4. 세션 서비스 관련 인증 또는 권한 오류가 발생하지 않는가?

웹 서버가 실행된다는 사실과 세션 서비스가 정상적으로 작동한다는 사실은 서로 다르다. 실제 대화를 수행해 확인해야 한다.

---

10) 서버 재시작을 통한 세션 지속성 검증

이번 실습에서 가장 중요한 부분이다.

10-1. 첫 번째 질문

ADK Web 화면에서 다음과 같이 질문한다.

오늘 서울 날씨 어때?

에이전트는 날씨 도구를 이용해 서울의 오늘 날씨를 조회하고 답변한다.

이 과정에서 세션에는 사용자의 질문과 에이전트의 응답 등 대화에 필요한 기록이 저장된다.

10-2. 로컬 웹 서버 종료

ADK Web을 실행하고 있는 PowerShell 터미널에서 다음 키를 누른다.

Ctrl + C

이렇게 하면 로컬 웹 서버 프로세스가 종료된다.

10-3. 웹 서버 재실행

같은 프로젝트 폴더에서 다시 실행한다.

adk web

브라우저에서 다시 접속한 뒤, 이전에 사용한 대화 세션을 이어서 사용한다.

여기서 중요한 것은 이전 세션과 동일한 세션 ID를 사용해야 한다는 점이다. 새 세션을 생성했다면 이전 대화가 자동으로 이어지지 않을 수 있다.

10-4. 두 번째 질문

기존 대화에서 다음과 같이 질문한다.

내일은?

이번에는 질문에 도시 이름이 포함되어 있지 않다.

그런데 에이전트가 이전 대화에서 서울을 언급했다는 맥락을 활용하여 서울의 내일 날씨를 답변했다.

이는 세션에 보존된 대화 기록을 바탕으로 후속 질문을 해석할 수 있음을 보여준다.

10-5. 검증 결과

검증 항목결과

첫 번째 날씨 질문	성공
로컬 웹 서버 종료	성공
웹 서버 재실행	성공
후속 질문 "내일은?"	성공
이전 대화의 지역 정보 활용	확인
서버 재시작 후 세션 지속성	확인

단, 이 결과를 가장 엄밀하게 재현하려면 서버 재시작 전후에 같은 세션 ID를 사용했는지 확인해야 한다. 동일한 세션 ID가 유지되었다면 기존 세션을 다시 조회해 대화 맥락을 이어갔다는 근거가 더욱 명확해진다.

---

11) InMemorySessionService와 VertexAiSessionService 비교

구분InMemorySessionServiceVertexAiSessionService

저장 위치	로컬 프로세스 메모리	Google Cloud 관리형 세션 서비스
로컬 서버 종료	메모리의 세션 소실	클라우드 세션은 유지될 수 있음
서버 재시작 후 조회	기존 세션을 유지하지 못하는 것이 일반적	동일한 세션을 다시 조회할 수 있음
개발 편의성	간단하고 빠름	Google Cloud 설정 필요
인증·권한	로컬 실행 자체에는 클라우드 세션 권한이 필요하지 않음	Google Cloud 인증 및 권한 필요
적합한 용도	학습, 간단한 테스트	지속적인 대화가 필요한 서비스

이 비교에서 핵심은 단순히 저장 장소가 달라진다는 것뿐만 아니라, 애플리케이션이 재시작되어도 이전 세션을 다시 불러올 수 있도록 구조가 바뀐다는 것이다.

다만 VertexAiSessionService를 사용한다고 해서 모든 종류의 장기 기억이 자동으로 생성되는 것은 아니다. 이 서비스는 세션을 관리하는 기능이며, 사용자 선호나 지식을 추출해 여러 대화에 걸쳐 활용하는 Memory Bank와는 구분된다.

---

12) 실습에서 꼭 기억할 세 가지

첫째, 세션 서비스와 에이전트는 서로 다른 역할이다.

에이전트는 질문을 이해하고 도구를 사용해 답변한다. 세션 서비스는 대화 기록을 저장하고 다시 조회할 수 있도록 한다.

둘째, 서버 재시작 후에도 기존 세션을 사용해야 한다.

새 세션을 시작하면 이전 대화가 이어지지 않는 것이 정상일 수 있다. 지속성을 검증할 때는 기존 세션 ID를 유지했는지 확인해야 한다.

셋째, Agent Engine 생성과 세션 지속성 검증은 서로 다른 단계다.

Agent Engine 생성 결과가 출력되었다는 것은 리소스 생성이 성공적으로 처리되었음을 보여준다. 세션 지속성은 별도로 실제 대화를 수행하고 서버를 재시작한 뒤 검증해야 한다.

이번 실습에서는 후속 질문에 정상적으로 답변함으로써 해당 기능을 확인했다.

---

13) 이번 실습에서 구분해야 할 추가 개념

이번에 사용한 생성 코드는 SimpleAgent 객체를 전달해 Agent Engine에 배포 가능한 에이전트 리소스를 생성하는 방식이었다.

따라서 이를 엄밀하게 표현하면, 세션 저장소 전용 리소스만 생성한 실습이라기보다는 Agent Engine 리소스를 생성하고 그 ID를 VertexAiSessionService에 연결한 실습이다.

Google Cloud의 관리형 세션 기능을 사용하기 위해 반드시 별도의 사용자 정의 에이전트를 배포해야 하는 것은 아니다. 필요한 경우 에이전트 객체 없이 관리형 세션 용도의 Agent Engine 리소스를 생성하는 구성도 검토할 수 있다.

또한 VertexAiSessionService와 Memory Bank는 목적이 다르다.

• Session: 현재 대화의 메시지와 흐름을 유지한다.
• Memory Bank: 대화에서 얻은 유용한 정보를 장기적으로 활용할 수 있도록 관리한다.

따라서 다음 학습 단계에서는 세션 지속성을 이해한 뒤 Memory Bank를 학습하면 개념을 구분하기 쉽다.

---

14) 전체 실습 체크리스트

• Python 가상환경 활성화

• Google Cloud 프로젝트 ID와 리전 확인

• ADC 인증 확인

• Vertex AI API, 결제 및 필요한 권한 확인

• Cloud Storage 스테이징 버킷 확인

• Agent Engine 생성 결과 확인

• 전체 Resource name에서 Agent Engine ID 추출

• VertexAiSessionService 생성

• Runner에 session_service 연결

• adk web 실행

• 첫 번째 날씨 질문 수행

• 기존 세션 ID 확인

• 웹 서버 종료 및 재실행

• 동일한 세션에서 "내일은?" 질문

• 이전 대화 맥락이 유지되는지 확인

---

15) 최종 정리

이번 실습은 다음 흐름으로 요약할 수 있다.

Google Cloud 준비
       ↓
Agent Engine 생성
       ↓
Agent Engine ID 확인
       ↓
VertexAiSessionService 생성
       ↓
ADK Agent 실행 구성에 연결
       ↓
adk web 실행
       ↓
첫 번째 질문
       ↓
로컬 웹 서버 종료 및 재실행
       ↓
기존 세션에서 후속 질문
       ↓
대화 맥락 유지 확인

이번 실습을 통해 확인한 가장 중요한 원리는 다음과 같다.

에이전트가 실행되는 프로세스와 대화 세션을 저장하는 장소를 분리하면, 로컬 서버가 재시작되더라도 기존 대화 세션을 다시 조회하여 대화를 이어갈 수 있다.

이것은 이후 여러 전문 에이전트를 연결하거나 실제 서비스로 확장할 때 중요한 기반이 된다.