36일차 회고｜미니프로젝트 설계·역할 분담·MCP 서버｜AI 오케스트레이션 개발자 국비지원

 

오늘은 단순히 코드를 작성하는 날이라기보다 앞으로 진행할 미니프로젝트의 전체적인 개발 구조를 잡는 날에 가까웠다.

지금까지는 mini_agent를 중심으로 LLM, Tool, MCP, RAG 등을 하나씩 실습했다면, 이제는 배운 내용을 실제 프로젝트 구조 안에 어떻게 배치할 것인지 고민해야 했다.

특히 오늘은 법률 사례 검색 AI Agent라는 프로젝트 방향을 구체화하고, 프론트엔드·백엔드·Agent·MCP 서버·DB/RAG의 역할을 어떻게 나눌지 팀원들과 논의했다.

---

오늘 배운 내용

오늘 가장 중요했던 것은 기능을 만드는 것보다 먼저 시스템 구조를 설계해야 한다는 것이었다.

기존 미니프로젝트에서는 편의상 하나의 환경에서 프론트엔드와 백엔드를 함께 다루기도 했지만, 실제 프로젝트에서는 각각의 역할과 실행 환경을 분리하는 것이 중요하다는 설명을 들었다.

대략적인 구조는 다음과 같이 생각할 수 있다.

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

여기에 RAG를 적용한다면 DB에서 검색한 데이터를 기반으로 유사 사례를 찾아 Agent가 답변을 구성하는 형태가 될 수 있다.

---

프론트엔드와 백엔드를 분리해야 하는 이유

처음에는 프론트엔드와 백엔드를 하나의 .env에서 관리해도 큰 문제가 없다고 생각할 수 있다.

하지만 실제 프로젝트에서는 각각 사용하는 환경과 의존성이 다르다.

frontend/
 ├─ package.json
 ├─ .env
 └─ ...

backend/
 ├─ requirements.txt
 ├─ .env
 └─ ...

프론트엔드는 사용자 화면을 담당하고, 백엔드는 데이터 처리와 Agent 실행 등을 담당한다.

특히 DB나 LLM에 직접 접근하는 것은 백엔드의 역할에 가깝기 때문에 프론트엔드가 DB에 직접 연결하는 구조는 피하는 것이 좋다는 점을 다시 이해했다.

---

MCP 서버를 별도로 구성하는 이유

오늘은 MCP 서버의 역할도 다시 생각해보게 됐다.

MCP(Model Context Protocol)는 AI가 외부 도구나 데이터에 접근할 수 있도록 연결해주는 표준적인 방식이다.

이번 프로젝트에서는 하나의 MCP 서버만 사용하는 것으로 끝나는 것이 아니라, 향후 필요에 따라 여러 MCP 서버로 확장할 수 있는 구조를 고려하기로 했다.

                ┌─ MCP Server 1
Agent ──────────┼─ MCP Server 2
                └─ MCP Server 3

예를 들어 법률 사례 검색을 만든다면

• 법률 데이터 검색
• 외부 법률 API
• DB 검색
• 유사도 검색

등을 각각 Tool 형태로 구성할 수 있다.

오늘 특히 중요했던 부분은 MCP 서버를 실제 프로젝트에서 여러 개 사용할 가능성을 고려해 처음부터 확장 가능한 디렉터리 구조를 만들어두는 것이었다.

---

미니프로젝트 주제도 구체화했다

팀원들과 여러 아이디어를 논의한 결과, 최종적으로는 법률 사례 검색 AI Agent 방향으로 정리했다.

처음에는 범죄 사례, 부동산, 음악, 영화·드라마 등 여러 주제가 후보로 나왔다.

그중에서도 법률 분야를 선택한 이유는 단순히 재미있는 주제라서가 아니라, AI Agent와 RAG를 적용했을 때 기술적인 의미를 보여주기 좋다고 판단했기 때문이다.

다만 법률 분야 전체를 다루면 범위가 지나치게 커진다.

그래서 핵심 기능을 최대한 좁혔다.

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

우선은 이 정도를 1차 목표로 잡았다.

예를 들어 사용자가

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

와 같은 상황을 입력하면,

입력
 ↓
Agent
 ↓
관련 법률/사례 검색
 ↓
유사도 검색
 ↓
Top 3 사례
 ↓
사용자에게 결과 제공

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

---

법률 상담이 아니라 '유사 사례 검색'에 집중

법률 프로젝트를 이야기하면서 가장 중요하게 생각했던 부분이다.

AI에게 법률적인 판단이나 조언을 직접 맡기면 잘못된 정보나 환각(Hallucination)이 발생했을 때 문제가 커질 수 있다.

그래서 처음부터 범위를 좁혀서

"당신의 상황은 이런 법률 문제입니다."

라고 단정하는 서비스보다는,

"입력한 상황과 유사한 사례를 찾아드립니다."

라는 방향으로 잡는 것이 더 적절하다고 생각했다.

이를 통해 프로젝트의 기술적인 목표도 명확해진다.

• 사용자 입력
• 사례 데이터 검색
• 임베딩 및 유사도 검색
• RAG
• Agent
• MCP Tool
• 검색 결과 정리
• 최종 결과 출력

등 우리가 지금까지 배운 내용을 하나의 서비스에 연결할 수 있다.

---

역할 분담도 시작했다

오늘은 개발 역할도 구체적으로 논의했다.

처음에는

1. Frontend
2. Backend
3. MCP Server
4. Database
5. Agent

정도로 나누는 방안이 나왔다.

하지만 우리 팀은 4명이기 때문에 단순하게 5개 역할을 한 명씩 맡을 수는 없었다.

그래서 최종적으로는 대략적인 영역을

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

와 같이 가져가는 방향으로 논의했다.

다만 중요한 것은 역할을 나눴다고 해서 서로 완전히 분리되는 것은 아니라는 점이었다.

특히 Backend, Agent, MCP, DB/RAG는 서로 강하게 연결되어 있기 때문에 계속 소통하면서 개발해야 한다.

---

디렉터리 구조가 생각보다 중요했다

오늘 가장 많이 강조된 부분 중 하나가 디렉터리 구조였다.

단순히 파일을 아무 곳에나 넣어놓고 기능이 작동하도록 만드는 것이 아니라,

"왜 이 기능을 이 폴더에 넣었는가?"

를 설명할 수 있는 구조가 필요하다는 것이다.

이번 프로젝트는 기존에 진행했던 mini_agent_03_tool 구조를 기본으로 가져가되, 프로젝트 요구사항에 맞게 수정하는 방향으로 이야기가 나왔다.

특히 다음과 같은 구조를 고려했다.

project/
├─ frontend/
├─ backend/
├─ mcp/
├─ db/
├─ agent/
└─ ...

정확한 최종 구조는 팀에서 추가로 정리해야 하지만, 오늘의 핵심은 처음부터 전체 구조를 잡고 개발을 시작해야 한다는 것이었다.

---

Git 협업 방식도 다시 정리했다

이번 프로젝트는 2.5일 정도의 짧은 기간 안에 개발해야 하기 때문에 Git 협업 방식도 중요하다.

지난 프로젝트에서 여러 명이 동시에 작업하면서 충돌이 발생했던 경험이 있었기 때문에 이번에는 작업 내용을 자주 커밋하고 머지하는 방식을 사용하기로 했다.

특히 공통 파일을 수정할 경우에는 팀원들에게 미리 공유하는 것이 중요하다.

예를 들어,

"이 파일은 현재 제가 수정하고 있습니다."

라고 알려놓으면 다른 팀원이 같은 파일을 동시에 수정하는 상황을 줄일 수 있다.

또한 개발을 마지막에 한꺼번에 합치는 것보다 중간중간 커밋과 머지를 진행하는 것이 충돌 원인을 파악하기 쉽다.

---

짧은 개발 기간을 고려한 일정도 중요했다

이번 프로젝트는 시간이 많지 않다.

그래서 2.5일이라고 해서 2.5일 전체를 개발에 사용할 수 있는 것은 아니라는 점도 이야기했다.

발표와 시연 영상까지 준비해야 하기 때문에 실제 개발 완료 시점을 앞당겨야 한다.

대략적으로는

1일차
→ 핵심 기능 개발

2일차
→ 기능 연결 및 통합
→ 대부분의 코드 머지 완료

2일차 오후
→ 디버깅
→ 시연 영상 준비

3일차 오전
→ 최종 발표 준비

와 같은 흐름을 생각했다.

특히 외부 API나 LLM을 사용하는 경우 실제 시연 과정에서 응답 시간이 길어질 수 있기 때문에 시연 영상을 미리 준비하는 방법도 이야기했다.

---

SSE도 다시 연결해서 이해했다

오늘 수업 내용과 함께 궁금해서 확인했던 개념이 SSE(Server-Sent Events)였다.

SSE는 서버가 클라이언트에게 데이터를 지속적으로 전달할 수 있는 방식이다.

AI Agent에서 답변 생성 시간이 오래 걸린다면 결과를 한 번에 기다리게 하는 대신,

답변 생성 중...
↓
검색 결과 확인
↓
사례 분석 중...
↓
답변 생성

처럼 서버에서 생성되는 결과를 프론트엔드에 실시간으로 전달하는 데 활용할 수 있다.

이번 프로젝트에서 반드시 SSE를 사용한다고 결정한 것은 아니지만, AI Agent 서비스의 사용자 경험을 개선할 수 있는 기술이라는 점을 이해했다.

---

오늘 새롭게 이해한 점

오늘 가장 크게 느낀 것은 프로젝트는 기능을 하나씩 만드는 것만으로 완성되는 것이 아니라는 점이다.

이전에는

"이 기능을 어떻게 구현하지?"

라는 생각을 먼저 했다면,

오늘은

"이 기능은 시스템에서 어디에 있어야 하지?"

를 먼저 생각하게 됐다.

특히 Agent, MCP, DB, Backend가 서로 어떤 관계를 가지고 있는지를 먼저 정리해야 이후 개발이 덜 꼬일 것 같다는 생각이 들었다.

또 하나는 프로젝트 범위를 줄이는 것이 오히려 중요하다는 것이다.

법률이라는 큰 주제를 선택했지만 법률 전체를 구현하려고 하면 짧은 기간 안에 제대로 완성하기 어렵다.

그래서 이번에는

법률 → 특정 생활 사례 → 유사 사례 검색

정도로 범위를 좁히는 것이 현실적인 접근이라고 생각한다.

---

현재 나의 상태

지금은 단순히 LLM이나 MCP를 각각 실습하는 단계에서 벗어나 이 기술들을 하나의 시스템으로 연결하는 과정으로 넘어가고 있다.

현재 이해한 구조는 대략 다음과 같다.

사용자
 ↓
Frontend
 ↓
Backend
 ↓
Agent
 ↓
MCP Tool
 ↓
DB / 외부 API
 ↓
검색 결과
 ↓
Agent
 ↓
Frontend

그리고 이번 프로젝트에서는 여기에 RAG와 유사도 검색을 연결해서 사용자 상황과 비슷한 법률 사례를 찾아주는 것을 핵심 기능으로 잡았다.

아직 부족한 부분도 많다.

특히 DB와 RAG를 실제 프로젝트 수준으로 설계하는 부분, MCP Tool을 어떤 기준으로 분리할지, Agent가 어떤 순서로 Tool을 선택하게 만들지 등은 직접 구현하면서 더 이해해야 할 것 같다.

---

복습할 부분

이번 프로젝트를 진행하면서 다음 부분을 중점적으로 복습해야겠다.

• MCP Server와 MCP Tool 구조
• Agent와 Tool의 연결 방식
• RAG 동작 과정
• 임베딩과 유사도 검색
• PostgreSQL / pgvector
• Backend API 설계
• Frontend ↔ Backend 통신
• SSE
• Git branch / commit / merge / conflict 해결
• 프로젝트 디렉터리 구조 설계

특히 DB와 RAG가 제대로 설계되지 않으면 MCP나 Agent를 잘 만들어도 결국 검색 품질이 떨어질 수 있기 때문에 이 부분을 우선적으로 이해해야겠다는 생각이 들었다.

---

오늘의 회고

오늘은 코드를 많이 작성한 날은 아니지만, 앞으로 진행할 프로젝트를 어떻게 만들어야 하는지에 대해서는 오히려 많은 생각을 하게 된 날이었다.

지금까지 배운 내용을 하나씩 따로 보면 LLM, Tool, MCP, RAG, DB 등이 각각의 기술처럼 느껴졌는데, 실제 프로젝트에서는 이 기술들이 서로 연결되어 하나의 시스템이 된다.

특히 "무엇을 만들 것인가"보다 "어떻게 구조화할 것인가"가 먼저 정리되어야 한다는 점을 배웠다.

이번 미니프로젝트에서는 욕심을 내서 법률 전체를 다루기보다 법률 사례 검색이라는 하나의 핵심 기능을 제대로 구현하는 것에 집중해보고 싶다.

그리고 단순히 "작동하는 프로그램"을 만드는 것에서 끝나지 않고,

왜 이런 구조로 설계했는지, 왜 이 기술을 선택했는지 설명할 수 있는 프로젝트를 만드는 것을 목표로 해야겠다.