---
title: "AI 에이전트의 대화, 문장만 저장해도 괜찮을까요?"
date: 2026-10-25
status: review-draft
category: AI 서비스 설계
tags: [AI, Agent, 대화이력, 시스템설계]
source_author: Christian Tzolov
source_publisher: Spring Blog
source_published_at: 2026-09-25
source_url: https://spring.io/blog/2026/09/25/spring-ai-2-1-0-M1-available-now/
---

# AI 에이전트의 대화, 문장만 저장해도 괜찮을까요?

AI에게 주문을 확인해 달라고 부탁했는데, 답변이 나오기 직전에 연결이 끊겼다고 해볼까요? 다시 접속하면 AI는 어디서부터 일을 이어가야 할까요?

우리는 앞서 어떤 말을 했는지 기억하면 된다고 생각하기 쉽습니다. 그런데 AI가 중간에 도구를 써서 무언가를 처리했다면, 대화 내용만으로는 부족할 수도 있습니다. 오늘은 이 차이를 주문 조회 이야기로 살펴보겠습니다.

## 말을 기억하는 것과 일을 기억하는 것

Spring 팀의 최근 글을 보면, 텍스트와 도구 호출·결과를 순서가 있는 여러 조각으로 표현하는 방식을 소개하고 있습니다. **AI의 대화를 문장뿐 아니라 작업의 흐름으로 다뤄보려는 시도**로 읽힙니다. 뒤의 표현은 발표를 읽고 제가 붙인 해석입니다. [참고한 Spring 팀의 글 — 2026.09.25](https://spring.io/blog/2026/09/25/spring-ai-2-1-0-M1-available-now/)

이름이나 버전을 외울 필요는 없습니다. “무슨 말을 했는가”와 “어디까지 일을 했는가”를 구별해 보자는 관점만 가져가면 됩니다.

## 주문을 조회하는 에이전트를 떠올려 봅시다

이제부터는 위 발표를 이해하기 위해 제가 구성한 가상 예시입니다. Spring 팀이 실제로 운영하는 주문 시스템을 소개하는 것은 아닙니다.

고객이 “제 주문이 어디까지 왔나요?”라고 묻는다고 해보겠습니다. 에이전트는 다음과 같이 움직일 수 있습니다.

```text
고객의 질문
  → 주문 조회 도구 호출 A
  → 호출 A의 결과 수신
  → 고객에게 결과 설명
```

채팅창에서는 마지막 설명이 가장 중요하겠지요. 하지만 개발자가 문제를 찾으려면 어떤 조회 결과를 근거로 답했는지도 알아야 합니다. 다른 대화에서 이 작업을 이어가려면, 사용 중인 모델·공급자가 요구하는 입력 형식도 맞춰야 하고요.

그런데 이 과정을 전부 “주문을 조회했습니다. 배송 중입니다.”라는 문장으로만 남기면 어떨까요? 읽기는 편하지만, 어느 요청에서 나온 결과인지 이 문장만으로 확인하기는 어렵습니다.

그래서 여기서 한 가지를 구분해 두면 좋습니다. **사용자에게 보여주는 요약과 실행을 확인하기 위한 기록은 역할이 다릅니다.**

## 기록을 설계할 때는 세 가지를 물어보세요

### 첫째, 이 결과는 어떤 호출의 답일까요?

두 주문을 동시에 조회했는데 결과가 반대 순서로 돌아올 수도 있습니다. 이때 단순히 먼저 도착한 결과를 첫 번째 주문의 답으로 취급하면 곤란하겠지요.

내부 기록에 호출을 식별하는 ID를 두고, 결과에도 같은 ID를 연결해 보는 겁니다. 그러면 도착 순서와 별개로 어떤 호출의 결과인지 확인할 근거가 생깁니다.

### 둘째, 어디까지 끝난 작업일까요?

조회는 성공했는데 고객에게 설명을 만드는 도중 연결이 끊겼다고 해보겠습니다. 다시 시작할 때 조회부터 할지, 이미 받은 결과로 설명만 만들지 판단해야겠지요.

문자열을 이어 붙이는 것과 작업의 시작·완료를 기록하는 것은 다릅니다. 장애 후 재개가 필요한 서비스라면 어느 단계까지 끝났는지도 함께 설계해 보세요.

### 셋째, 화면용 기록과 실행용 기록을 꼭 같게 만들어야 할까요?

화면에는 간결한 설명이 좋습니다. 반면 실행을 점검하려면 식별자나 상태 같은 정보가 필요할 수 있습니다. 저장할 정보와 다음 모델 요청에 보낼 정보도 반드시 같을 필요는 없습니다.

아래는 이 차이를 생각해 보기 위한 내부 이벤트 예시입니다. 실제 SDK나 공급자 API의 요청 형식은 아닙니다.

```json
{
  "conversation_id": "demo-conversation",
  "events": [
    {"seq": 1, "kind": "tool_call", "call_id": "lookup-a", "tool": "lookup_order"},
    {"seq": 2, "kind": "tool_result", "call_id": "lookup-a", "status": "success"},
    {"seq": 3, "kind": "display_text", "text": "주문 상태를 확인했습니다."}
  ]
}
```

이 정도만으로 대화 복원 기능이 완성되는 것은 아닙니다. 입력과 결과의 본문, 공급자별 상태, 보관 방식 등은 별도로 정해야 합니다. 지금은 “문장 외에 무엇을 기록해야 할까?”를 생각하는 출발점으로 봐주세요.

## 환불 에이전트라면 무엇을 더 생각해야 할까요?

이번에는 가상의 핀테크 적용 예시로 조금 확장해 보겠습니다.

조회와 달리 환불은 실제 업무 상태를 바꿉니다. 대화를 복원했다는 이유만으로 환불 실행까지 다시 해서는 안 되겠지요. AI의 대화 기록과 업무 시스템의 처리 결과를 연결하되, 이미 처리한 요청인지 확인하는 경계가 따로 필요합니다.

여기서 **대화 이력을 잘 보존하는 것과 같은 업무를 두 번 실행하지 않는 것은 다른 문제**라는 점을 기억해 두면 좋겠습니다. 앞에서 살펴본 대화 기록만으로 이 문제까지 해결되는 것은 아니겠지요. 실제 서비스를 만든다면 따로 고민해야 할 부분입니다.

## 우리 서비스에서도 작은 실험을 해볼 수 있습니다

거창하게 시스템을 바꾸기 전에, 저장된 대화 한 건을 꺼내 다음 질문을 해보세요.

- 도구 결과가 역순으로 도착해도 원래 호출에 연결할 수 있나요?
- 저장했다가 다시 읽어도 순서와 호출 ID가 유지되나요?
- 같은 결과를 두 번 받아도 화면이나 업무 처리가 중복되지 않나요?
- 도구 실행 뒤 답변 생성이 실패하면, 다음 시도는 어디서 시작하나요?

이 질문에 답해 보면 지금 저장하는 것이 단순한 채팅 기록인지, 실행을 점검하고 이어갈 수 있는 기록인지 조금 더 분명해질 겁니다.

## 부록: 직접 만들어보고 싶다면

Java/Spring 같은 프레임워크를 쓰더라도 처음에는 작은 실험이면 충분합니다. 도구 호출 두 건과 결과를 기록하고, 프로그램을 껐다 켠 뒤에도 어느 결과가 어느 호출의 것인지 찾아보세요.

그다음에는 결과 하나를 두 번 넣어보거나 순서를 바꿔보는 겁니다. 무엇이 헷갈리는지 관찰하면, 왜 문장 외의 기록이 필요한지도 더 쉽게 이해할 수 있습니다.

---

## 출처와 읽는 범위

- 작성자: Christian Tzolov
- 매체: Spring Blog
- 글: [Spring AI 2.1.0-M1 Available Now](https://spring.io/blog/2026/09/25/spring-ai-2-1-0-M1-available-now/)
- 원문 게시일: 2026년 9월 25일
- 확인일: 2026년 10월 25일
- 원문에서 확인한 부분: 여러 종류의 내용을 순서 있는 조각으로 표현하는 접근
- 자체 해설: 주문 조회·환불 가상 예시, 내부 이벤트 모델, 설계 질문과 점검 항목

원문 전체를 번역한 글이 아니라, 확인한 변화에 설명을 덧붙인 검토용 초안입니다.