2번째 미니프로젝트 1일차｜법률 AI Agent 기획과 팀 협업 시작 (Family 엔코아 SK 네트웍스 멀티 AI 에이전트)

 

오늘부터 본격적으로 AI 오케스트레이션 미니프로젝트가 시작됐다.

이번 프로젝트는 단순히 LLM에게 질문하고 답변을 받는 형태의 서비스를 만드는 것이 아니라, 지금까지 수업에서 배운 LLM, Agent, Tool, MCP, RAG, Vector DB, Backend, Frontend 등의 기술을 하나의 서비스로 연결해보는 프로젝트다.

우리 팀은 여러 아이디어를 고민한 끝에 생활 법률을 도와주는 AI Agent 서비스를 만들기로 했다.

현재 프로젝트는 이후 개발을 거치면서 Frontend, Backend, Agent, Legal MCP, PostgreSQL 및 pgvector 등을 연결하는 형태로 확장되었지만, 1일차에는 무엇보다 "무엇을 만들 것인가"와 "어떻게 함께 만들 것인가"를 정하는 과정이 중요했다. (GitHub)

---

1. 이번 미니프로젝트의 주제 정하기

처음부터 법률 AI Agent가 확정되어 있었던 것은 아니다.

팀원들과 여러 아이디어를 이야기하면서 어떤 주제가 이번 수업에서 배운 AI Agent와 MCP를 제대로 활용할 수 있을지 고민했다.

최종적으로 선택한 주제는 생활 법률 상담을 도와주는 AI Agent였다.

법률이라는 분야를 선택한 이유는 일상생활에서 법률 문제가 발생하더라도 일반인이 관련 법령이나 판례를 직접 찾아보기 어렵다는 점 때문이었다.

예를 들어 사용자가

"퇴직했는데 퇴직금을 받을 수 있을까요?"

라고 질문한다고 생각해보자.

단순한 ChatGPT라면 학습된 지식을 바탕으로 답변할 수 있지만, 법률 분야에서는 정확한 근거를 함께 제공하는 것이 중요하다.

그래서 우리가 만들고자 한 서비스는 단순한 챗봇보다는 다음과 같은 방향에 가까웠다.

사용자의 생활 법률 질문
        ↓
질문 분석
        ↓
관련 법률 분야 판단
        ↓
법령 / 판례 / 사례 검색
        ↓
검색 결과를 바탕으로 답변 생성
        ↓
사용자가 이해하기 쉬운 형태로 제공

이렇게 생각하면서 자연스럽게 RAG와 MCP를 활용할 이유도 연결할 수 있었다.

---

2. 왜 일반적인 챗봇이 아니라 Agent가 필요한가?

프로젝트를 시작하면서 가장 먼저 고민했던 부분이었다.

법률 질문이라고 해서 모든 질문을 동일한 방식으로 처리할 수는 없다.

예를 들어 노동 문제라면 노동 관련 법령과 판례를 찾아야 하고, 임대차 문제라면 임대차 관련 자료를 찾아야 한다.

따라서 사용자의 질문을 보고 필요한 작업을 판단하고 적절한 Tool을 호출하는 구조가 필요했다.

개념적으로는 다음과 같은 형태다.

사용자
  ↓
AI Agent
  ↓
질문 분석
  ↓
필요한 Tool 선택
  ├─ 법령 검색
  ├─ 판례 검색
  └─ 사례 검색
  ↓
검색 결과
  ↓
LLM 답변 생성

여기에서 Agent는 단순히 답변을 생성하는 모델이 아니라, 사용자의 요청을 보고 어떤 작업을 수행해야 하는지 판단하는 역할을 한다.

이번 프로젝트를 시작하면서 그동안 수업에서 배웠던 Agent 개념이 실제 서비스에서는 어떻게 활용될 수 있는지 조금 더 구체적으로 이해할 수 있었다.

---

3. MCP를 왜 사용하는지도 다시 생각해봤다

이번 프로젝트에서 중요한 기술 중 하나가 MCP(Model Context Protocol)다.

MCP는 AI 모델이 외부의 도구나 데이터에 접근할 수 있도록 연결해주는 표준화된 방식이라고 이해하고 있다.

이번 프로젝트에서는 법률 데이터를 검색하는 기능을 MCP Tool로 분리하는 방향으로 설계했다.

예를 들어 Agent가 사용자의 질문을 분석한 뒤,

"관련 판례를 찾아야겠다."
        ↓
search_cases Tool 호출
        ↓
Legal MCP
        ↓
법률 데이터 검색
        ↓
검색 결과 반환

와 같은 흐름을 만들 수 있다.

이렇게 하면 Agent가 직접 데이터베이스의 세부 구현을 알 필요 없이 필요한 기능을 Tool로 요청할 수 있다는 장점이 있다.

나중에 실제 프로젝트가 진행되면서 Legal MCP에 상담사례 검색, 법률 용어 검색 등의 기능도 추가되었는데, 1일차에는 이런 전체 구조를 어떻게 가져갈지 방향을 잡는 것이 중요했다.

---

4. RAG를 법률 검색에 적용하기

이번 프로젝트를 통해 RAG의 필요성도 다시 생각해봤다.

RAG(Retrieval-Augmented Generation)는 쉽게 말하면 LLM이 답변하기 전에 외부 자료를 검색하고, 그 검색 결과를 참고해서 답변하도록 만드는 방식이다.

법률 서비스에서 특히 중요한 이유가 있다.

LLM에게 법률 질문을 그냥 물어보면 그럴듯한 답변을 만들 수 있지만, 실제 법령이나 판례를 근거로 답변한다는 보장이 없다.

그래서 우리는

질문
 ↓
관련 법률 데이터 검색
 ↓
관련 문서 검색
 ↓
검색 결과를 LLM에게 전달
 ↓
근거 기반 답변

이라는 방향을 생각했다.

그리고 수업에서 배웠던 Vector DB와 pgvector도 이 구조에 연결할 수 있었다.

단순히 데이터베이스에서 정확한 값을 찾는 것이 아니라, 사용자의 질문과 의미적으로 비슷한 법률 문서나 사례를 검색해야 하기 때문이다.

---

5. 프로젝트 구조를 먼저 생각해봤다

프로젝트를 시작하면서 팀원별로 무작정 코드를 작성하기보다는 전체적인 구조부터 나누는 것이 필요했다.

우리가 생각한 기본 구조는 다음과 같다.

┌──────────────┐
│   Frontend   │
└──────┬───────┘
       │
       ↓
┌──────────────┐
│   Backend    │
└──────┬───────┘
       │
       ↓
┌──────────────┐
│ AI Agent     │
└──────┬───────┘
       │
       ↓
┌──────────────┐
│  Legal MCP   │
└──────┬───────┘
       │
       ↓
┌────────────────────┐
│ PostgreSQL/pgvector│
└────────────────────┘

이 구조를 기준으로 Frontend, Backend, MCP, DB, Agent 영역을 나누어 생각했다.

이후 실제 GitHub 저장소에서도 feature/backend-mock-api와 같은 기능 브랜치가 만들어지고 develop을 중심으로 통합하는 형태로 발전했다. (GitHub)

---

6. 팀 리더로서 가장 먼저 신경 쓴 부분

이번 프로젝트에서 나는 Frontend와 팀 리더를 담당했다.

그래서 단순히 Frontend 화면을 만드는 것뿐만 아니라 팀 전체의 작업이 서로 충돌하지 않도록 초반 구조를 맞추는 것이 중요했다.

특히 프로젝트 초반에는 다음과 같은 문제가 생길 수 있었다.

• 각자 생각하는 프로젝트 방향이 다름
• API 데이터 형식이 서로 다름
• 브랜치 작업 방식이 통일되지 않음
• 같은 기능을 여러 명이 작업할 가능성
• Frontend와 Backend의 연결 방식이 달라질 가능성

그래서 처음부터 역할을 나누고 Git 브랜치에서 각자 작업한 뒤 develop에서 통합하는 방식을 생각했다.

현재 저장소에서도 develop을 비롯해 여러 기능 브랜치가 병렬적으로 존재하는 것을 확인할 수 있다. (GitHub)

---

7. Git 협업을 다시 경험하다

개인 프로젝트라면 내가 원하는 방식으로 파일을 수정하고 커밋하면 된다.

하지만 팀 프로젝트에서는 이야기가 달라진다.

한 사람이 Frontend를 수정하고 다른 사람이 Backend를 수정하면서 동시에 같은 파일이나 설정을 건드릴 수도 있다.

그래서 이번 프로젝트에서는 Git의 역할이 더욱 중요했다.

기본적인 작업 흐름을 다음과 같이 생각했다.

develop
   │
   ├── feature/frontend
   ├── feature/backend
   ├── feature/mcp
   └── feature/db
          ↓
      기능 개발
          ↓
       commit
          ↓
       push
          ↓
      develop 통합

이 과정에서 단순히 commit, push, pull을 할 줄 아는 것보다 어떤 브랜치에서 어떤 작업을 해야 하는지가 더 중요하다는 것도 느꼈다.

특히 팀 리더 역할을 맡으면서 GitHub의 브랜치와 작업 상황을 확인하고 통합하는 과정까지 신경 써야 했다.

---

8. 처음부터 모든 기능을 만들려고 하면 안 된다는 것도 배웠다

프로젝트 기간이 짧기 때문에 처음부터 회원가입, 관리자 기능, 모든 법률 분야, 모든 검색 기능 등을 전부 구현하려고 하면 핵심 기능을 완성하지 못할 가능성이 높았다.

그래서 먼저 가장 중요한 사용자 시나리오 하나를 완성하는 것이 중요하다고 생각했다.

예를 들면,

사용자 질문
   ↓
Agent 질문 분석
   ↓
법률 검색
   ↓
관련 판례 검색
   ↓
답변 생성
   ↓
Frontend 출력

이 하나의 흐름이 제대로 동작하는 것을 우선 목표로 잡는 방식이다.

이후 프로젝트가 진행되면서 실제 저장소에서도 Backend Mock API, MCP Tool, 사례 검색 등의 기능이 추가되면서 전체 흐름을 점차 확장해 나갔다. (GitHub)

---

9. 첫날부터 느낀 가장 큰 어려움

가장 어려웠던 것은 기술 자체보다 프로젝트 범위를 정하는 것이었다.

AI Agent 프로젝트라고 생각하면 하고 싶은 기능이 계속 늘어난다.

법률 검색뿐만 아니라

• 회원가입
• 로그인
• 사용자 이력
• 관리자
• 다양한 법률 분야
• 판례 검색
• 법령 검색
• 사례 검색
• 법률 용어 검색
• RAG
• MCP
• Vector DB
• AI Agent

등 생각할 수 있는 기능이 많았다.

하지만 프로젝트 시간이 제한되어 있기 때문에 결국 중요한 것은 "무엇을 더 만들 것인가?"보다 "무엇을 포기할 것인가?"였다.

이번 프로젝트를 시작하면서 개발에서는 기능을 많이 넣는 것보다 핵심 기능을 실제로 동작하게 만드는 것이 더 중요하다는 점을 다시 생각하게 됐다.

---

10. 첫날 새롭게 이해한 점

오늘 가장 크게 느낀 점은 AI 프로젝트도 결국 소프트웨어 프로젝트라는 것이다.

AI가 들어간다고 해서 기존 개발의 기본적인 원칙이 사라지는 것이 아니었다.

오히려

요구사항
 ↓
서비스 구조
 ↓
역할 분리
 ↓
API 설계
 ↓
Git 협업
 ↓
구현
 ↓
테스트
 ↓
통합

이라는 기본적인 개발 과정이 더욱 중요했다.

여기에 AI Agent와 MCP, RAG가 추가되는 형태라고 이해하게 됐다.

특히 Agent가 모든 것을 직접 처리하는 것이 아니라 필요한 기능을 Tool로 분리하고, 각 컴포넌트가 자신의 역할을 담당하도록 만드는 것이 AI 오케스트레이션의 중요한 부분이라는 것을 프로젝트를 시작하면서 조금 더 명확하게 이해할 수 있었다.

---

11. 오늘의 회고

미니프로젝트 1일차는 코드를 많이 작성한 날이라기보다 앞으로 만들 서비스를 정의한 날이었다.

처음에는 "법률 AI를 만들어보자" 정도로 시작했지만, 이야기를 나누면서

사용자 질문 → Agent → Tool → MCP → 법률 데이터 검색 → RAG → 답변

이라는 구체적인 흐름으로 발전시킬 수 있었다.

또한 Frontend 담당이면서 팀 리더 역할을 맡게 되면서 내가 맡은 기능만 생각하는 것이 아니라 다른 팀원이 작업하는 Backend, MCP, DB와 어떻게 연결될 것인지까지 생각해야 한다는 점도 느꼈다.

무엇보다 이번 프로젝트에서는 지금까지 수업에서 따로 배웠던 기술들이 실제로 하나의 서비스 안에서 연결된다는 점이 기대됐다.

앞으로는 새로운 기능을 무작정 추가하기보다 먼저 하나의 핵심 사용자 시나리오를 처음부터 끝까지 연결하는 것을 목표로 해야겠다.

첫날은 설계와 역할 분담의 시작이었다면, 다음 날부터는 실제 구현과 통합 과정에서 어떤 문제가 발생하는지 직접 경험해볼 차례다.

---

오늘의 핵심 정리

• 생활 법률을 도와주는 AI Agent 서비스를 프로젝트 주제로 선정했다.
• Agent가 필요한 Tool을 선택하고 MCP를 통해 법률 검색 기능을 사용하는 구조를 설계했다.
• 법률 데이터의 정확한 검색과 근거 제공을 위해 RAG와 Vector DB 활용 방향을 잡았다.
• Frontend, Backend, Agent, MCP, DB로 역할을 분리했다.
• 팀 프로젝트에서 Git 브랜치와 develop 통합 과정의 중요성을 확인했다.
• 제한된 프로젝트 기간 안에서는 기능의 양보다 핵심 사용자 시나리오의 완성도가 중요하다는 것을 생각하게 됐다.