[SK네트웍스 Family 엔코아AI캠퍼스] AI 오케스트레이션 캠프 1기_9월 1주차 회고

 

이번 주는 지금까지 배워온 LLM, Tool, MCP, RAG, Memory, Redis, pgvector, Workflow, Agent 등의 개념을 하나의 흐름으로 연결해보는 시간이었다.

특히 이번 주부터는 단순히 예제 코드를 따라 작성하는 단계에서 벗어나, 실제 AI Agent 서비스를 어떻게 설계하고 테스트할 것인지를 고민하기 시작했다.

지난주까지는 각각의 기술이 무엇인지 이해하는 데 집중했다면, 이번 주에는 조금 다른 질문을 하게 됐다.

“이 기술을 실제 서비스에서 어떻게 연결해야 할까?”

그리고 한 주 동안 수업을 들으면서 이 질문에 대한 답이 조금씩 정리되기 시작했다.

이번 주에는 미니프로젝트의 주제와 구조를 구체화했고, Agent와 Workflow의 차이를 이해했으며, Memory와 RAG의 역할을 구분했다.

또한 AI Agent에서 중요한 State, Run, Trace, Human-in-the-Loop, Approval 등의 개념을 학습했고, 마지막에는 Agent가 제대로 동작하는지 검증하기 위한 테스트와 평가까지 연결했다.

결국 이번 주는

기획 → 설계 → 구현 → 상태 관리 → 승인 → 테스트 → 평가

라는 AI Agent 개발의 전체적인 흐름을 처음으로 경험한 한 주였다고 생각한다.

---

1. 미니프로젝트의 방향을 구체화하다

이번 주의 시작은 미니프로젝트 설계였다.

그동안 여러 가지 프로젝트 아이디어를 생각했지만 팀원들과 논의한 결과 최종적으로 법률 사례 검색 AI Agent를 만들기로 했다.

법률이라는 주제는 굉장히 넓기 때문에 처음부터 모든 법률 상담을 제공하는 서비스를 만드는 것은 현실적으로 어려웠다.

그래서 프로젝트의 범위를 최대한 좁혔다.

사용자가 자신의 법률 관련 상황을 입력하면 AI Agent가 유사한 법률 사례를 검색하고, 유사도가 높은 사례를 보여주는 서비스

정도로 핵심 기능을 정의했다.

예를 들어 사용자가

“중고거래를 했는데 판매자가 돈을 받은 뒤 연락이 되지 않습니다.”

라고 입력한다면,

사용자 입력
   ↓
AI Agent
   ↓
법률 사례 검색
   ↓
임베딩 / 유사도 검색
   ↓
유사 사례 Top 3
   ↓
결과 정리
   ↓
사용자에게 제공

와 같은 흐름을 생각할 수 있다.

특히 법률 상담이나 법률 판단 자체를 AI에게 맡기는 것이 아니라 유사 사례 검색에 집중하는 방향으로 정한 것이 중요했다.

AI가 잘못된 법률 정보를 생성하거나 환각을 일으켰을 때 발생할 수 있는 문제를 생각하면, 프로젝트의 범위를 명확하게 제한하는 것이 필요하다고 느꼈다. (랩보다 AI 더 잘해지기)

---

2. 프로젝트는 기능보다 구조가 먼저였다

미니프로젝트를 준비하면서 가장 크게 느낀 것은 “무엇을 만들 것인가”만큼 “어떻게 구성할 것인가”가 중요하다는 점이었다.

기존에는 기능을 먼저 생각했다.

“법률 사례를 검색하려면 어떻게 구현하지?”

하지만 이번에는 조금 다르게 생각하게 됐다.

“이 기능은 시스템의 어디에 있어야 하지?”

전체적인 구조를 생각하면 다음과 같이 정리할 수 있다.

Frontend
   ↓
Backend
   ↓
AI Agent
   ↓
MCP Server
   ↓
Tool
   ↓
DB / 외부 API

그리고 법률 사례 검색에서는 DB에 저장된 데이터를 기반으로 RAG와 유사도 검색을 연결할 수 있다.

팀원이 4명이기 때문에 역할도 단순하게 나누는 것이 아니라,

Frontend + 프로젝트 총괄
Backend + Agent
MCP Server
Database + RAG

와 같이 영역을 나누는 방향으로 정리했다.

하지만 역할을 나눴다고 해서 각각 완전히 독립적으로 개발할 수 있는 것은 아니었다.

특히 Backend, Agent, MCP, DB/RAG는 서로 강하게 연결되어 있기 때문에 지속적인 소통이 필요하다는 것도 알게 됐다. (랩보다 AI 더 잘해지기)

---

3. Memory를 배우면서 데이터의 ‘목적’을 생각하게 됐다

37일차에는 AI Agent의 Memory를 공부했다.

처음에는 Memory라고 하면 단순히 이전 대화를 저장하는 기능이라고 생각했다.

하지만 실제로는 조금 달랐다.

Memory는 사용자의 모든 대화를 무조건 저장하는 것이 아니라,

• 사용자의 선호
• 사용자 상태
• 이전 대화
• 필요한 사용자 정보

등을 저장하고 필요할 때 다시 활용하는 개념에 가까웠다.

그리고 여기서 PostgreSQL, Redis, pgvector의 역할을 구분하는 것이 중요했다.

PostgreSQL

장기적으로 보관해야 하는 데이터를 저장한다.

예를 들면,

• 사용자 정보
• 대화 기록
• Agent 실행 기록
• 사용자 Memory

등이 있다.

Redis

짧은 시간 동안 유지할 데이터나 현재 실행 중인 상태를 저장하는 데 적합하다.

특히 TTL을 이용하면 일정 시간이 지나면 자동으로 데이터를 삭제할 수도 있다.

pgvector

문서의 임베딩을 저장하고 유사도 검색을 수행하는 데 사용할 수 있다.

결국 중요한 것은

“어떤 저장소가 가장 좋은가?”

가 아니라

“이 데이터는 어떤 목적으로 저장되는가?”

라는 것이었다. (랩보다 AI 더 잘해지기)

---

4. RAG와 Memory의 차이가 조금 더 명확해졌다

기존에는 RAG와 Memory가 모두 데이터를 검색해서 LLM에게 전달한다는 점 때문에 비슷하게 느껴졌다.

하지만 이번 주를 통해 둘의 목적을 조금 더 명확하게 구분할 수 있게 됐다.

RAG는 서비스에 필요한 지식이나 문서를 검색하는 것이고,

Memory는 사용자와 관련된 상태나 이전 정보를 기억하는 것이다.

법률 AI Agent에 적용한다면,

법률 문서 / 판례 / 사례
        ↓
       RAG
        ↓
   유사 사례 검색

반면,

사용자 정보
이전 사건 맥락
이전 대화
        ↓
     Memory
        ↓
개인화된 Agent 동작

과 같이 구분할 수 있다.

이 차이를 이해하고 나니 앞으로 프로젝트에서 법률 데이터와 사용자 데이터를 어떻게 분리해서 관리해야 하는지도 조금 더 명확하게 보였다. (랩보다 AI 더 잘해지기)

---

5. Workflow와 Agent의 차이를 이해하다

38일차에는 지금까지 배웠던 Workflow와 Agent의 차이를 다시 정리했다.

처음에는 단순히 Workflow와 Agent가 비슷한 개념처럼 느껴졌다.

하지만 핵심은

“누가 다음 행동을 결정하는가?”

였다.

Workflow는 개발자가 정해놓은 순서대로 실행한다.

A
 ↓
B
 ↓
C
 ↓
D

Conditional Workflow는 조건에 따라 분기하지만 그 조건 자체를 개발자가 정한다.

반면 Agent는 현재 상태와 Tool 실행 결과 등을 확인하면서 다음 행동을 결정한다.

Goal
 ↓
현재 State 확인
 ↓
Tool 실행
 ↓
Observation
 ↓
State 업데이트
 ↓
다음 행동 결정
 ↓
반복 또는 종료

그리고 여기서 AI 모델이 의사결정을 담당하면 AI Agent라고 볼 수 있다.

결국 중요한 차이는 단순히 코드가 복잡하냐의 문제가 아니라,

의사결정을 누가 수행하는가?

라는 것이었다. (랩보다 AI 더 잘해지기)

---

6. Agent에서는 State와 Trace가 중요했다

Agent를 공부하면서 새롭게 중요하게 느껴진 개념이 State와 Trace였다.

Agent가 여러 단계로 동작한다면 현재 어디까지 실행했는지를 알아야 한다.

예를 들어,

초기 State
   ↓
법률 사례 검색
   ↓
검색 결과 추가
   ↓
유사도 분석
   ↓
결과 생성
   ↓
최종 응답

처럼 State가 계속 변경된다.

그리고 Trace는 Agent가 실제로 어떤 과정을 거쳐 결과를 만들었는지 확인할 수 있는 실행 기록이다.

사용자 요청
   ↓
Tool 선택
   ↓
Tool 실행
   ↓
결과 확인
   ↓
다음 Tool 선택
   ↓
최종 결과

이러한 실행 과정을 기록해두면 문제가 발생했을 때 어느 단계에서 잘못됐는지 추적할 수 있다.

AI Agent가 복잡해질수록 최종 답변만 확인해서는 문제를 찾기 어렵기 때문에 이런 실행 기록이 중요하다는 것을 이해했다. (랩보다 AI 더 잘해지기)

---

7. Human-in-the-Loop를 통해 ‘AI가 모든 것을 하면 안 된다’는 것을 배웠다

이번 주에 특히 인상 깊었던 개념 중 하나는 Human-in-the-Loop였다.

AI Agent라고 해서 모든 작업을 AI가 알아서 처리하게 만드는 것이 좋은 것은 아니다.

특히

• 데이터 변경
• 예약
• 결제
• 중요한 의사결정

처럼 위험도가 높은 작업은 사람의 승인을 거치는 것이 필요하다.

예를 들어,

사용자 요청
   ↓
Agent 실행
   ↓
정보 검색
   ↓
작업 준비
   ↓
사용자 승인 요청
   ↓
[Pause]
   ↓
사용자 승인
   ↓
[Resume]
   ↓
실제 작업 실행

과 같은 구조를 만들 수 있다.

여기서 중요한 것은 단순히 “승인 버튼”을 만드는 것이 아니었다.

Agent가 승인 요청을 한 시점의 State를 저장하고, 사용자가 승인한 이후 기존 State를 기반으로 작업을 다시 이어갈 수 있어야 한다.

즉 AI Agent는 단순한 질문 → 답변 시스템을 넘어 사람과 상호작용하면서 작업을 이어가는 시스템이 될 수 있다는 점을 이해했다. (랩보다 AI 더 잘해지기)

---

8. Tool도 ‘기능’만 만들면 끝나는 것이 아니었다

이번 주에는 Tool을 설계할 때도 단순히

“이 기능이 필요한가?”

만 생각하면 안 된다는 것을 배웠다.

예를 들어 Tool을 위험도에 따라 구분할 수 있다.

날씨 조회       → Read
사례 검색       → Read
DB 조회         → Read

데이터 저장     → Change
예약 생성       → Change

결제             → Critical

Read 성격의 Tool은 자동 실행할 수 있지만 데이터를 변경하는 Tool은 사용자 승인이 필요할 수 있다.

따라서 Tool을 만들 때는

어떤 기능인가?
        +
자동 실행 가능한가?
        +
사용자 승인이 필요한가?
        +
실행하면 안 되는 상황은 무엇인가?

까지 정의해야 한다.

특히 중요한 점은 AI에게 위험 여부를 판단하도록 전부 맡기는 것이 아니라 개발자가 Tool별 정책을 미리 정의해야 한다는 것이었다. (랩보다 AI 더 잘해지기)

---

9. AI Agent는 ‘정상적으로 실행되는 것’만으로 충분하지 않았다

39~40일차에서 가장 중요했던 부분은 테스트와 평가였다.

일반적인 프로그램은 같은 입력에 대해 비교적 동일한 결과를 기대할 수 있다.

하지만 AI Agent는

사용자 입력
 ↓
LLM 판단
 ↓
Tool 선택
 ↓
Tool 실행
 ↓
결과 확인
 ↓
다음 행동 결정
 ↓
최종 응답

처럼 여러 단계를 거친다.

따라서 단순히

“에러 없이 실행됐는가?”

만 확인해서는 부족하다.

예를 들어 다음과 같은 항목까지 확인해야 한다.

• 적절한 Tool을 선택했는가?
• Tool에 올바른 인자를 전달했는가?
• 필요한 단계가 누락되지 않았는가?
• 승인 요청이 필요한 시점에 정상적으로 멈췄는가?
• 승인 이후 State를 유지하면서 실행을 이어갔는가?
• 동일한 작업이 중복 실행되지 않았는가?
• 최종 결과가 예상한 형태인가?

결국 AI Agent 테스트는 최종 결과만 평가하는 것이 아니라 Agent가 결과를 만들어가는 전체 과정을 평가하는 것이라는 점을 배웠다. (랩보다 AI 더 잘해지기)

---

10. Expected가 있어야 테스트가 가능하다

테스트를 공부하면서 가장 중요한 개념 중 하나가 Expected였다.

테스트는 단순히 결과가 나왔는지를 확인하는 것이 아니다.

우리가 먼저

“이 입력을 넣으면 어떻게 동작해야 하는가?”

를 정의해야 한다.

예를 들어,

Input
↓
Expected Tool
↓
Expected State
↓
Expected Result

를 먼저 정의하고 실제 결과와 비교해야 한다.

그러면

Expected = 실제 결과
→ PASS

Expected ≠ 실제 결과
→ FAIL

이라는 방식으로 테스트할 수 있다.

특히 AI Agent는 결과가 항상 동일하지 않을 수 있기 때문에 무엇을 정상적인 동작으로 볼 것인지 기준을 먼저 정하는 것이 중요하다는 것을 알게 됐다. (랩보다 AI 더 잘해지기)

---

11. 정상적인 요청보다 비정상적인 요청이 더 중요할 수도 있다

40일차에는 정상적인 요청뿐만 아니라 비정상적인 요청과 서비스 범위를 벗어난 요청도 테스트해야 한다는 내용을 배웠다.

예를 들어 날씨 Agent라면

“제주도 날씨를 알려줘.”

는 정상적인 요청이다.

하지만

“시드니 날씨를 알려줘.”

처럼 서비스에서 지원하지 않는 범위의 요청이 들어올 수도 있다.

이때 AI가 억지로 답을 만들어내는 것이 아니라,

“현재 지원하지 않는 요청입니다.”

라고 명확하게 알려주는 것이 올바른 동작일 수 있다.

결국 AI Agent 테스트에서 중요한 것은

정상 케이스
+
비정상 케이스
+
예외 상황
+
경계 조건

까지 생각하는 것이었다. (랩보다 AI 더 잘해지기)

---

12. Redis와 SSE가 사용자 경험으로 연결됐다

이번 주에는 Redis와 SSE가 Agent의 실행 상태를 사용자에게 전달하는 구조로도 연결됐다.

Agent가 여러 단계를 거쳐 실행되는 경우 사용자는 아무것도 표시되지 않는 화면에서 무작정 기다려야 할 수도 있다.

하지만 실행 상태를 전달한다면,

법률 사례를 검색하고 있습니다.
        ↓
유사 사례를 분석하고 있습니다.
        ↓
관련 법률 정보를 확인하고 있습니다.
        ↓
결과를 정리하고 있습니다.
        ↓
완료

처럼 사용자에게 현재 진행 상황을 보여줄 수 있다.

구조적으로는

AI Agent 실행
     ↓
State 변경
     ↓
Redis 저장
     ↓
SSE
     ↓
Frontend

와 같이 생각할 수 있다.

지금까지 Redis는 단순히 빠른 저장소라고만 생각했는데, Agent의 실행 상태와 연결해서 생각하니 실제 서비스에서 왜 필요한지 조금 더 이해할 수 있었다. (랩보다 AI 더 잘해지기)

---

13. 이번 주 가장 크게 달라진 생각

이번 주를 시작하기 전에는 AI Agent를 생각하면

LLM + Prompt + Tool

정도로 생각했던 것 같다.

하지만 지금은 조금 다르게 생각하게 됐다.

실제 AI Agent 서비스를 만들기 위해서는

LLM
+
Prompt
+
Tool
+
MCP
+
RAG
+
Memory
+
State
+
Database
+
Redis
+
SSE
+
Human-in-the-Loop
+
Evaluation
+
Testing

등 여러 요소를 함께 고려해야 한다.

그리고 이 모든 기술을 사용하는 것 자체가 중요한 것이 아니라 각각의 역할을 적절하게 나누고 연결하는 것이 중요하다.

특히 이번 주에 가장 많이 생각하게 된 것은

“AI Agent를 만드는 것”과 “AI Agent를 제대로 설계하는 것”은 다르다.

라는 점이다.

---

14. 미니프로젝트에 적용해본다면

현재 진행 중인 법률 AI Agent를 기준으로 생각하면 이번 주에 배운 내용을 다음과 같이 연결할 수 있을 것 같다.

                    사용자
                      ↓
                  Frontend
                      ↓
                   Backend
                      ↓
                  AI Agent
                 ↙        ↘
             Memory        MCP
                ↓            ↓
           PostgreSQL      Tools
                              ↓
                       법률 사례 검색
                              ↓
                         pgvector
                              ↓
                       유사도 검색
                              ↓
                            RAG
                              ↓
                         검색 결과
                              ↓
                         AI Agent
                              ↓
                        최종 응답

그리고 Agent 실행 과정에서 필요한 상태는 Redis 등을 활용하고, 필요한 경우 SSE를 통해 프론트엔드에 현재 진행 상태를 전달할 수 있다.

또한 단순히 기능 구현에서 끝나는 것이 아니라,

Agent 설계
   ↓
정상 / 비정상 시나리오 정의
   ↓
Tool 및 State 정의
   ↓
구현
   ↓
테스트 케이스 작성
   ↓
테스트 실행
   ↓
Expected / Actual 비교
   ↓
PASS / FAIL
   ↓
테스트 결과 보고서

까지 연결해야 한다.

이번 미니프로젝트가 단순한 기능 구현 과제가 아니라 AI Agent의 전체 개발 사이클을 경험하는 프로젝트가 될 수 있을 것 같다. (랩보다 AI 더 잘해지기)

---

15. 이번 주를 돌아보며

이번 주는 개인적으로 꽤 중요한 전환점이었다.

그동안은 새로운 기술을 배우면

“이게 어떻게 동작하지?”

라는 질문을 많이 했다.

하지만 이번 주부터는 조금씩

“이걸 실제 서비스에서는 어떻게 설계하지?”

라는 질문을 하기 시작했다.

LLM을 호출하는 방법을 아는 것과 AI Agent를 만드는 것은 다른 문제였다.

Tool을 만드는 것과 Tool을 안전하게 사용할 수 있도록 설계하는 것도 다른 문제였다.

RAG를 구현하는 것과 어떤 데이터를 RAG 대상으로 만들고 어떤 검색 전략을 사용할 것인지 결정하는 것도 다른 문제였다.

그리고 Agent를 실행시키는 것과 Agent가 제대로 동작했는지 평가하는 것 역시 다른 문제였다.

특히 이번 주에 배운

Workflow → Agent → AI Agent → Multi-Agent

라는 흐름과

State → Tool → Observation → State Update → Next Action

이라는 구조가 앞으로 AI Agent를 이해하는 데 중요한 기준이 될 것 같다.

---

16. 앞으로의 목표

이제 미니프로젝트가 본격적으로 시작된다.

이번 프로젝트에서는 단순히

“AI가 법률 사례를 검색해준다.”

라는 결과만 만드는 것이 목표가 아니다.

가능하다면 다음을 직접 경험해보고 싶다.

• 법률 데이터 구조 설계
• PostgreSQL / pgvector 구성
• RAG 검색 구현
• MCP Server 및 Tool 구성
• Agent와 Tool 연결
• Agent State 관리
• 사용자 요청 처리
• 정상 / 비정상 테스트
• Expected / Actual 비교
• Agent 실행 Trace 확인
• 최종 테스트 결과 정리

그리고 프로젝트가 끝난 뒤에는 단순히

“작동하는 AI Agent를 만들었다.”

에서 끝나는 것이 아니라,

“왜 이런 구조로 설계했고, 왜 이 기술을 사용했으며, 어떻게 테스트해서 정상 동작을 검증했는지 설명할 수 있다.”

정도의 수준까지 가는 것을 목표로 해보고 싶다.

---

마무리

이번 주를 한 문장으로 정리한다면,

“AI Agent를 만드는 법에서 AI Agent를 설계하고 검증하는 법으로 시야가 넓어진 한 주였다.”

라고 표현할 수 있을 것 같다.

처음에는 LLM과 Tool을 연결하는 것만으로도 신기했는데, 이제는 Agent 하나를 만들기 위해 데이터 구조, Memory, State, Tool, MCP, RAG, 사용자 승인, 실행 기록, 테스트와 평가까지 생각해야 한다는 것을 배우고 있다.

아직 모든 개념이 완벽하게 정리된 것은 아니지만, 적어도 각각의 기술이 왜 필요한지, 그리고 서로 어떻게 연결되는지는 이전보다 훨씬 선명해졌다.

이제 배운 내용을 실제 법률 AI Agent 미니프로젝트에 적용해볼 차례다.

짧은 개발 기간 안에 얼마나 완성도 있게 구현할 수 있을지 걱정도 되지만, 이번에는 단순히 기능을 만드는 것보다 설계 → 구현 → 테스트 → 평가까지 하나의 흐름으로 경험해보고 싶다.

다음 주에는 직접 코드를 작성하면서 지금까지 머릿속으로 정리했던 구조가 실제 프로젝트에서 어떻게 연결되는지 확인해봐야겠다.