AI 오케스트레이션 캠프/일차별 회고

42일차 회고｜법률 AI Agent 프로젝트 통합과 프론트엔드 개선｜AI 오케스트레이션 개발자 국비지원

랩보다 AI 더 잘해지기 2026. 9. 8. 17:44
728x90

 

오늘은 수업에서 배운 AI 오케스트레이션 기술을 실제 팀 프로젝트에 연결하면서, LawPath 생활 법률 검색 AI Agent를 발표 가능한 수준으로 끌어올리는 작업에 집중했다.

우리 팀 프로젝트는 사용자가 자신의 생활 법률 상황을 입력하면 분야별 Agent가 법령과 판례를 검색하고, 검색된 근거를 바탕으로 이해하기 쉽게 정리해주는 서비스다. 현재 프로젝트는 frontend → backend → Agent → Legal MCP → PostgreSQL + pgvector로 이어지는 구조를 가지고 있다. (GitHub)

특히 오늘은 단순히 화면을 만드는 것보다 각 파트의 결과물을 하나의 서비스로 연결하는 과정을 경험했다.

1. 오늘 배운 내용

① AI Agent와 MCP를 실제 프로젝트에 연결하기

프로젝트의 전체적인 요청 흐름은 다음과 같다.

사용자
 ↓
Streamlit Frontend
 ↓ HTTP
FastAPI Backend
 ↓
Agent
 ↓ MCP
Legal MCP
 ↓
PostgreSQL + pgvector

Frontend와 Backend가 데이터베이스를 직접 조회하는 것이 아니라, 법률 검색은 Legal MCP를 거치도록 역할을 분리했다. 이렇게 하면 각 파트가 자신의 책임 영역에 집중할 수 있고, 시스템 구조도 명확해진다. (GitHub)

오늘 특히 인상적이었던 부분은 MCP가 단순히 외부 기능을 연결하는 기술이 아니라 Agent가 필요한 Tool을 선택하고 실행할 수 있도록 중간에서 역할을 나누는 구조라는 점이었다.

실제 개발 과정에서도 Consumer 상담사례 MCP Tool 연결, MCP 응답에 분석 답변 포함, 근거 부족 시 MCP 보완 검색 추가, MCP 추가 Tool 호출 함수 연결 등의 작업이 이어졌다. (GitHub)

2. 프론트엔드에서 실제로 구현한 것

내 담당은 Frontend + 팀 리더였기 때문에 오늘도 화면과 팀 전체 통합 관점에서 프로젝트를 확인했다.

현재 Frontend는 Streamlit을 사용하고 있으며, Backend가 연결되지 않은 상황에서도 Mock 데이터를 이용해 전체 사용자 흐름을 확인할 수 있도록 구성했다.

단순히 법률 검색 화면 하나만 만든 것이 아니라 다음과 같은 기능을 구현했다.

  • 생활 법률 분야 선택
  • 내 사례 분석
  • 대표 질문 불러오기
  • 입력 내용 검증
  • 법령 검색
  • 실제 사례 검색
  • 법률 용어 검색
  • 필요 서류 체크리스트
  • 다음 행동 체크리스트
  • FAQ
  • 사용자 질문
  • 질문 수정·삭제
  • 페이지네이션
  • 질의 이력
  • 결과 Markdown 저장
  • 회원/비회원/관리자 역할별 화면
  • QA 테스트 모드
  • 발표용 시나리오

현재 Frontend 진행 문서 기준으로 이러한 기능들이 Mock 환경에서 구현되어 있고, Frontend 테스트도 22개가 통과한 상태다. (GitHub)

3. 오늘 가장 중요했던 부분은 '통합'이었다

프로젝트 초반에는 각자 맡은 영역을 개발하는 것 자체가 중요했다.

하지만 프로젝트가 어느 정도 완성되면서부터는 상황이 달라졌다.

Frontend가 만들어졌다
        ↓
Backend도 만들어졌다
        ↓
MCP도 만들어졌다
        ↓
DB도 준비됐다
        ↓
그런데 실제로 서로 연결되는가?

이제부터는 각각의 기능이 존재하는 것보다 하나의 사용자 요청이 처음부터 끝까지 정상적으로 흘러가는지가 더 중요했다.

우리 프로젝트에서 가장 중요한 통합 목표도 다음 흐름으로 정의되어 있다.

퇴직금 질문
 → LaborAgent
 → search_cases
 → Legal MCP
 → pgvector
 → 공식 판례 Top 3
 → Backend 응답
 → Frontend 표시

이 흐름이 정상적으로 연결된 이후 다른 분야와 보조 기능을 확장하는 방식이다. (GitHub)

오늘 프로젝트를 보면서 AI 프로젝트는 AI 모델 하나를 잘 만드는 것만으로 끝나는 것이 아니라는 것을 다시 느꼈다.

사용자 화면부터 API, Agent, Tool, DB까지 모든 요소가 연결되어야 실제 서비스가 된다.

4. 프론트엔드와 백엔드의 계약이 중요하다는 것을 체감했다

프로젝트를 진행하면서 가장 많이 신경 쓴 부분 중 하나가 데이터 형식이었다.

Frontend에서 화면을 만들 때 Backend가 어떤 데이터를 반환할지 명확하지 않으면 화면을 계속 수정해야 한다.

그래서 프로젝트에서는 Mock Service와 향후 Backend Client가 동일한 View Model을 사용하도록 분리했다.

MockLegalService
       ↓
   같은 데이터 형식
       ↑
 Backend Client

덕분에 Backend가 실제로 연결되더라도 화면 Component를 전부 다시 만드는 것이 아니라 Service 부분을 교체하는 방식으로 연동할 수 있게 됐다. (GitHub)

이번 프로젝트를 통해 API에서 말하는 계약(Contract)이 단순한 문서가 아니라 실제 협업에서 상당히 중요한 개념이라는 것을 이해하게 됐다.

팀원이 서로 다른 작업을 하더라도 데이터의 약속만 맞춰져 있다면 동시에 개발할 수 있기 때문이다.

5. Mock과 실제 기능을 구분하는 것도 중요했다

이번 프로젝트에서는 시간이 제한되어 있기 때문에 모든 기능을 처음부터 실제 DB와 인증까지 연결하기는 어려웠다.

그래서 Mock 데이터를 적극적으로 사용했다.

중요한 것은 Mock을 실제 기능처럼 포장하지 않는 것이었다.

현재 프로젝트에서도 화면 결과에 DEMO MODE를 표시하고 있으며, Mock 결과는 실제 법률정보가 아니라 UI와 연결을 확인하기 위한 데이터라고 명확하게 구분하고 있다. (GitHub)

특히 법률 서비스이기 때문에 더 조심해야 했다.

프로젝트 개발 규칙에서도 검색되지 않은 법령이나 판례를 임의로 생성하지 않고, 검색 점수를 승소 가능성처럼 표현하지 않으며, 서비스가 법률 자문이나 승패 예측을 제공하지 않는다고 명시하고 있다. (GitHub)

AI를 활용한 서비스일수록 무엇을 할 수 있는지뿐만 아니라 무엇을 하면 안 되는지도 설계해야 한다는 점을 배웠다.

6. 오늘의 어려움

가장 어려웠던 부분은 역시 각자의 개발 결과물을 하나의 흐름으로 맞추는 과정이었다.

Frontend 입장에서는 화면이 정상적으로 동작해도 Backend API의 응답 형식이나 MCP 연결 상태가 달라지면 실제 통합 과정에서 다시 수정해야 한다.

반대로 Backend나 MCP가 정상적으로 동작하더라도 Frontend에서 해당 응답을 제대로 처리하지 못하면 사용자에게는 기능이 동작하지 않는 것처럼 보인다.

그래서 오늘은 단순한 기능 개발보다는 다음과 같은 부분을 계속 확인하게 됐다.

  • API 요청/응답 형식
  • Agent의 응답 상태
  • MCP Tool 연결
  • 검색 결과 구조
  • 근거가 부족한 경우의 처리
  • 결과가 없는 경우의 화면
  • 로딩 및 오류 상태
  • Mock과 실제 API 전환
  • 팀 서버 연결 상태

결국 각자의 코드가 잘 작동하는 것과 전체 서비스가 잘 작동하는 것은 다른 문제라는 것을 체감했다.

7. Git 협업도 프로젝트의 일부라는 것을 느꼈다

오늘 GitHub를 확인하면서 프로젝트가 실제로 여러 브랜치에서 병렬적으로 개발되고 있다는 것도 확인할 수 있었다.

현재 저장소에는 main, develop을 비롯해 Frontend, Backend, MCP 관련 작업 브랜치가 존재하고 있으며, 기능 개발 후 develop으로 통합하는 방식으로 진행되고 있다. (GitHub)

특히 오늘 develop에는 Backend Mock API 병합, MCP Tool 연결, 근거 부족 시 보완 검색, 상담사례 응답 지원, Consumer 상담사례 검색 연결 등의 작업이 이어졌다. (GitHub)

팀 리더 역할을 하면서 느낀 점은 Git은 단순히 코드를 저장하는 도구가 아니라 팀원들의 작업을 하나의 결과물로 합치는 협업 도구라는 것이다.

8. 새롭게 이해한 점

이번 프로젝트를 진행하기 전에는 AI Agent 프로젝트라고 하면 LLM에게 좋은 프롬프트를 작성하고 답변을 잘 나오게 만드는 것이 핵심이라고 생각했다.

하지만 실제 프로젝트를 진행해보니 생각이 달라졌다.

좋은 LLM
    ↓
좋은 Agent
    ↓
적절한 Tool 선택
    ↓
정확한 데이터 검색
    ↓
Backend 처리
    ↓
사용하기 쉬운 Frontend

이 모든 과정이 연결되어야 사용자가 실제로 사용할 수 있는 AI 서비스가 된다.

특히 AI 오케스트레이션은 각각의 AI 기능을 만드는 것보다 여러 구성 요소가 올바른 순서로 협력하도록 만드는 것이 핵심이라는 것을 프로젝트를 통해 조금씩 이해하게 됐다.

9. 현재 나의 상태

이번 프로젝트를 통해 단순히 Frontend 코드를 작성하는 것에서 한 단계 더 나아가 전체 서비스 구조를 함께 생각하는 경험을 하고 있다.

현재는 Streamlit 기반 Frontend의 주요 사용자 흐름을 구성하고, Mock 환경에서 다양한 상태와 역할을 테스트할 수 있는 수준까지 구현했다. (GitHub)

또한 팀 리더로서 다른 팀원의 Backend, MCP, DB 작업이 Frontend와 어떻게 연결되는지도 계속 확인하고 있다.

다만 아직 부족한 부분도 분명하다.

특히 실제 Backend → Agent → MCP → DB까지 연결된 환경에서 발생하는 오류를 직접 추적하고 해결하는 경험은 더 필요하다.

현재 프로젝트도 Legal MCP의 일부 검색 경로가 Mock 호환을 포함하고 있으며, AgentRuntime과 실제 pgvector Hybrid Search 역시 후속 구현 대상으로 남아 있다. (GitHub)

10. 오늘의 회고

42일차는 "각자 만든 기능을 어떻게 하나의 서비스로 만들 것인가"를 고민한 날이었다.

처음에는 화면 하나를 완성하는 것도 쉽지 않았지만, 프로젝트가 진행될수록 더 중요한 것은 화면 자체가 아니라 Backend, Agent, MCP, DB와 연결되는 구조라는 것을 알게 됐다.

특히 팀 프로젝트에서는 내가 작성한 코드만 잘 돌아가면 끝나는 것이 아니라 다른 사람이 작성한 코드와 연결되어야 하기 때문에 데이터 계약, Git 브랜치 전략, 역할 분리, 테스트가 모두 중요했다.

이번 프로젝트를 통해 AI 오케스트레이션이라는 개념을 단순히 수업에서 배운 기술로만 이해하는 것이 아니라, 실제 프로젝트 구조 속에서 조금씩 체감하고 있다는 점이 가장 큰 수확이었다.

이제 프로젝트에서 남은 시간은 새로운 기능을 무작정 추가하기보다 핵심 사용자 시나리오가 처음부터 끝까지 안정적으로 동작하는지 확인하고 발표에서 우리가 무엇을 만들었고 왜 이렇게 설계했는지를 설명할 수 있도록 정리하는 것에 집중해야겠다.

참고한 프로젝트

LawPath 팀 프로젝트 GitHub 저장소

※ 이번 글은 현재 GitHub의 develop 브랜치와 프로젝트 문서, 최근 커밋 기록을 기준으로 작성했다. 현재 저장소에는 9월 8일에도 Backend/MCP 통합 작업이 진행되고 있어, 실제 발표 직전 상태와는 일부 차이가 생길 수 있다. (GitHub)

#AI오케스트레이션 #AI에이전트 #멀티에이전트 #MCP #RAG #pgvector #FastAPI #Streamlit #Git협업 #국비지원