41일차 회고｜SSE·Redis·pgvector·팀 통합｜AI 오케스트레이션 개발자 국비지원

 

프로젝트 마무리가 가까워지면서 오늘은 새로운 기술을 배우는 것보다 지금까지 만든 기능들을 실제 프로젝트 구조에 연결하고, 서버와 Git 환경을 맞추는 과정에 집중했다.

특히 SSE와 Redis를 이용한 AI Agent 진행 상황 전달 구조, PostgreSQL과 pgvector를 이용한 RAG 환경 구성, 그리고 프론트엔드·백엔드·MCP 서버를 연결하는 과정에서 프로젝트를 실제 서비스처럼 구성하려면 어떤 부분을 신경 써야 하는지 알 수 있었다.

---

오늘 배운 내용

오늘 가장 중요했던 내용은 크게 네 가지였다.

• SSE(Server-Sent Events)를 이용한 실시간 데이터 전달
• Redis를 이용한 Agent Trace 관리
• PostgreSQL + pgvector 기반 RAG 환경 구성
• Git develop 브랜치와 서버 통합 테스트

단순히 각각의 기술을 따로 사용하는 것이 아니라, 여러 서버와 데이터 흐름을 연결해서 하나의 AI 서비스로 만드는 과정이 핵심이었다.

---

1. SSE와 Redis를 이용한 AI Agent 진행 상황 전달

AI Agent를 실행하면 단순한 질문에 바로 답이 나오는 것이 아니라 내부적으로 여러 단계를 거칠 수 있다.

예를 들어 법률 질문을 처리한다면

질문 입력 → 필요한 정보 판단 → Tool 호출 → 데이터 검색 → 결과 정리 → 최종 답변

과 같은 과정이 발생할 수 있다.

이 과정이 오래 걸리면 사용자는 화면이 멈춘 것처럼 느낄 수 있다.

여기서 배운 것이 SSE(Server-Sent Events)였다.

SSE는 서버에서 브라우저로 데이터를 계속 보내주는 방식이다.

이번 프로젝트에서는 Agent가 실행되는 동안 발생하는 Trace(Agent가 어떤 단계를 진행하고 있는지 나타내는 실행 기록)를 Redis에 저장하고, 이를 Agent Worker가 처리한 뒤 SSE를 통해 프론트엔드에 전달하는 구조를 배웠다.

즉,

Agent → Redis → Agent Worker → SSE → Frontend

와 같은 흐름으로 진행 상황을 화면에 보여줄 수 있다.

이렇게 하면 AI 답변을 기다리는 동안 단순히 로딩 화면만 보여주는 것이 아니라 현재 어떤 작업을 하고 있는지 사용자에게 전달할 수 있다.

---

2. Redis와 DB의 역할을 구분해서 이해하기

오늘 Redis와 PostgreSQL의 역할도 다시 정리했다.

쉽게 생각하면,

PostgreSQL
→ 오래 보관해야 하는 데이터

Redis
→ 빠르게 읽고 쓰면서 임시로 관리할 데이터

라고 볼 수 있다.

프로젝트에서 회원 정보, 게시글, 질문 기록처럼 계속 보관해야 하는 데이터는 DB가 담당하고, AI Agent의 실행 과정이나 실시간 상태처럼 빠르게 전달하고 관리해야 하는 데이터는 Redis를 활용할 수 있다.

특히 오늘은 Redis에 Agent Trace를 저장하고 SSE로 전달하는 구조를 보면서 왜 DB 하나만 사용하는 것이 아니라 여러 저장소를 목적에 맞게 사용하는지 조금 더 이해하게 됐다.

---

3. PostgreSQL + pgvector 환경 구성

RAG를 사용하기 위한 데이터베이스 환경도 구성했다.

이번 프로젝트에서는 PostgreSQL + pgvector를 사용한다.

pgvector는 PostgreSQL에서 텍스트의 의미를 숫자 형태의 벡터로 저장하고, 벡터 간 유사도를 검색할 수 있게 해주는 확장 기능이다.

RAG에서는 대략 다음 과정으로 데이터가 만들어진다.

문서 → 텍스트 정리 → Chunk 분할 → Embedding → pgvector 저장

여기서 Embedding은 텍스트를 숫자로 표현하는 과정이다.

예를 들어 법률 관련 문서를 벡터로 변환해 저장해두면 사용자가 질문했을 때 질문 역시 벡터로 변환하고, 기존 문서 중 의미가 비슷한 내용을 찾아낼 수 있다.

이번 프로젝트에서 사용하는 법률 데이터 역시 현재는 법령 전체가 완성된 형태라기보다는 피해구제 사례와 같은 사례성 데이터를 중심으로 RAG 검색에 활용하는 방향으로 구성하고 있다.

따라서 앞으로 어떤 법률 자료를 추가할지, 어떤 형태로 문서를 정리해서 RAG에 넣을지가 중요한 부분이라고 느꼈다.

---

4. DB 초기화와 RAG 데이터 적재 과정

DB를 직접 SQL로 하나씩 만들어 넣는 방식보다는 프로젝트에 준비된 스크립트를 이용해 초기 환경을 구성하는 방법도 배웠다.

예를 들면 역할을 다음처럼 나눌 수 있다.

• setup → DB와 테이블 생성
• seed → 초기 데이터 입력
• ingest_rag → RAG 문서를 벡터 DB에 적재
• scripts → 위 작업을 자동화

특히 RAG 데이터는 단순히 문서 파일을 DB에 넣는 것으로 끝나는 것이 아니라,

문서 수집 → 정제 → Chunk 분할 → Embedding → Vector DB 저장

과정을 거쳐야 한다는 것을 다시 확인했다.

---

5. 환경변수와 서버 분리

오늘은 .env 설정도 중요하게 다뤘다.

프로젝트에는 생각보다 많은 서버와 설정값이 필요하다.

예를 들어

• LLM
• Vision Model
• STT
• TTS
• Embedding Model
• PostgreSQL
• Redis
• Backend
• MCP Server
• 서버 포트
• Timeout
• Tool 호출 제한
• 파일 저장 경로

등이 각각 설정될 수 있다.

또한 실제 프로젝트에서는 프론트엔드, 백엔드, MCP 서버 등이 각각 독립적인 서비스이기 때문에 각 서비스의 .venv와 .env를 분리해서 관리하는 것이 중요하다는 것도 배웠다.

특히 여러 명이 동시에 개발하다 보니 localhost와 포트 번호가 조금만 달라져도 서버 연결이 안 될 수 있었다.

결국 팀에서 사용할 포트와 서버 주소를 명확하게 정하고, 각자 임의로 변경하지 않는 것이 중요했다.

---

직접 진행한 팀 프로젝트 통합

오늘 후반부에는 이론보다는 실제 프로젝트 통합과 테스트에 집중했다.

현재 우리 팀은 법률 AI Agent를 개발하고 있고, 나는 Frontend와 팀 리더를 담당하고 있다.

프로젝트의 기본적인 데이터 흐름은 다음과 같이 생각할 수 있다.

Frontend
   ↓
Backend
   ↓
MCP Server
   ↓
법률 데이터 / RAG
   ↓
결과
   ↓
Frontend

회원, 게시판, 질문 기록 등의 데이터는 DB를 활용하고 AI 법률 질문과 관련된 처리는 MCP Server와 연결하는 구조다.

이 과정에서 중요한 것은 각 기능을 따로 만들어놓는 것이 아니라 실제로 전체 흐름이 연결되는지 확인하는 것이었다.

---

Git develop 브랜치 동기화

프로젝트 통합 과정에서 Git도 상당히 중요했다.

현재 팀에서는 develop 브랜치를 최신 개발 기준으로 사용하고 있고, main은 최종 결과를 위한 브랜치로 관리하는 방향이었다.

따라서 개발할 때는

develop 최신 코드 확인
        ↓
내 작업
        ↓
commit
        ↓
develop에 반영
        ↓
팀원들이 최신 develop pull

이라는 흐름을 맞추는 것이 중요했다.

특히 로컬에서 merge가 완료됐다고 해서 원격 저장소의 develop까지 자동으로 최신 상태가 되는 것은 아니기 때문에 실제 원격 브랜치에 변경사항이 반영됐는지 확인하는 과정도 필요했다.

팀 프로젝트에서는 코드를 잘 작성하는 것만큼 같은 코드를 보고 작업하는 환경을 유지하는 것이 중요하다는 것을 느꼈다.

---

서버 Reload와 통합 테스트

백엔드 코드를 수정할 때마다 서버를 직접 종료하고 다시 실행하는 것보다 reload 기능을 사용하면 코드 변경을 감지해서 서버를 다시 불러올 수 있다는 것도 확인했다.

물론 reload 과정에서 잠깐 연결이 끊길 수 있기 때문에 테스트 중에는 서버가 재시작된 것인지 실제 오류가 발생한 것인지 구분할 필요가 있었다.

또한 단순히

"서버가 실행되고 있다."

만 확인해서는 부족했다.

실제로는

Frontend → Backend → MCP → DB/RAG → Backend → Frontend

전체 흐름이 정상적으로 동작하는지 확인해야 한다.

서버가 연결된 상태인데도 Tool 실행이 제대로 되지 않는 경우처럼 "연결 성공"과 "기능 정상 작동"은 다른 문제라는 것도 다시 확인했다.

---

오늘 어려웠던 점

가장 어려웠던 부분은 역시 여러 서버와 Git 브랜치를 동시에 맞추는 과정이었다.

Frontend, Backend, MCP Server, DB, Redis가 각각 존재하다 보니 하나의 기능을 테스트하더라도 여러 요소가 동시에 정상적으로 실행되어야 한다.

특히 팀원마다 로컬 환경과 브랜치 상태가 다르면

"내 컴퓨터에서는 되는데 왜 다른 사람은 안 되지?"

라는 상황이 발생할 수 있다.

그래서 단순히 기능을 구현하는 것보다 현재 어떤 브랜치의 어떤 코드를 기준으로 실행하고 있는지, 각 서버가 어느 포트에서 실행되는지, 환경변수가 제대로 설정되어 있는지를 확인하는 것이 중요했다.

---

새롭게 이해한 점

오늘 가장 크게 느낀 것은 AI 프로젝트는 AI 모델만 잘 연결한다고 끝나는 것이 아니라는 점이다.

처음에는 LLM이나 RAG, MCP 같은 기술 자체에 관심이 많았다.

하지만 실제 프로젝트를 통합해보니

• Git 브랜치 관리
• API 규격
• 서버 포트
• 환경변수
• DB
• Redis
• 서버 Reload
• Frontend/Backend 연결
• MCP 연결
• 통합 테스트

같은 기본적인 개발 환경이 제대로 맞아야 AI 기능도 정상적으로 동작한다.

특히 API Spec이 프론트엔드와 백엔드 사이의 약속이라는 것도 실제 통합 과정에서 더 와닿았다.

각자 자기 기능만 잘 만드는 것이 아니라 서로의 기능을 연결할 수 있도록 공통 규칙을 맞춰야 했다.

---

현재 나의 상태

현재는 프로젝트의 전체 구조를 어느 정도 이해하고, 프론트엔드에서 백엔드와 연결되는 흐름과 팀 프로젝트에서 필요한 Git 동기화 과정을 직접 경험하고 있는 상태다.

또한 SSE, Redis, pgvector, RAG, MCP가 각각 따로 존재하는 기술이 아니라 하나의 AI Agent 서비스를 구성하기 위해 서로 연결될 수 있다는 점을 이해하게 됐다.

다만 아직 부족한 부분도 많다.

특히 실제로 여러 서버가 동시에 실행되는 환경에서 발생하는 오류를 빠르게 원인 분석하는 능력과, RAG 데이터의 품질을 높이는 방법은 더 공부해야 한다.

---

복습할 부분

이번 프로젝트를 마무리하면서 다음 부분은 다시 정리해봐야겠다.

1. SSE와 WebSocket의 차이
2. Redis와 PostgreSQL의 역할 차이
3. RAG 전체 처리 과정
4. Embedding과 Vector Search
5. MCP Tool과 Backend의 역할 구분
6. Git branch / merge / pull / fetch 흐름
7. Frontend → Backend → MCP → DB 전체 데이터 흐름
8. Docker 기반 PostgreSQL + pgvector 실행 방법

특히 프로젝트가 끝난 뒤에도 직접 처음부터 서버를 실행할 수 있도록 프로젝트 실행 방법을 문서화하는 것이 필요하다고 생각한다.

---

오늘의 회고

오늘은 새로운 기능 하나를 만드는 것보다 지금까지 배운 기술을 실제 프로젝트 안에서 연결하는 과정이 얼마나 어려운지 경험한 날이었다.

수업에서 배울 때는 SSE, Redis, MCP, RAG, pgvector가 각각 하나의 기술처럼 느껴졌지만, 실제 프로젝트에서는 이 기술들이 서로 연결되어 하나의 서비스가 된다.

그리고 그 과정에서 가장 중요한 것은 단순히 코드를 작성하는 것이 아니라 팀원 모두가 같은 구조와 규칙을 이해하고 있어야 한다는 것이었다.

프로젝트 마감이 가까워진 만큼 이제는 새로운 것을 무작정 추가하기보다는 현재 구현된 기능을 제대로 연결하고, 오류를 해결하고, 실제 사용자가 처음부터 끝까지 사용할 수 있는 상태로 만드는 것이 더 중요해졌다.

남은 기간에는 기능 구현 → 통합 → 테스트 → 오류 수정 → 발표 준비 순서로 프로젝트를 최대한 안정적으로 마무리해야겠다.