AI 오케스트레이션 캠프/미니프로젝트

미니프로젝트 3일차 회고｜LawPath 최종 발표와 프로젝트 마무리

랩보다 AI 더 잘해지기 2026. 9. 10. 16:02
728x90

 

오늘로 두 번째 미니프로젝트 발표까지 모두 끝났다.

이번 미니프로젝트는 3일이라는 짧은 기간 동안 **생활 법률 문제를 AI Agent가 분석하고 법령·상담사례·판례를 찾아주는 서비스 LawPath**를 만드는 프로젝트였다.

1일차에는 각자의 기능을 개발하고, 2일차에는 팀원들의 기능을 통합하면서 실제 서비스 흐름을 만들어갔다. 그리고 오늘 3일차에는 최종 기능 정리 → 테스트 → 발표자료 준비 → 최종 발표까지 진행하면서 프로젝트를 마무리했다.

특히 오늘 GitHub에는 내가 작업한 Frontend 최종 커밋, 발표자료, 100건 평가용 테스트 코드와 함께 팀원들의 최종 작업이 차례로 병합됐다. (GitHub)

오늘은 무엇을 했는가?

오늘의 가장 큰 목표는 새로운 기능을 많이 추가하는 것이 아니라 지금까지 만든 LawPath를 실제 발표 가능한 상태로 만드는 것이었다.

전체적인 흐름은 다음과 같았다.

기능 최종 확인
    ↓
Frontend 마무리
    ↓
Backend / MCP / Database 통합 확인
    ↓
오류 및 예외 상황 점검
    ↓
발표자료 및 시연 순서 정리
    ↓
최종 발표

GitHub에서도 오늘 날짜인 9월 10일에

  • Frontend 최종 커밋
  • 발표자료 1차 업로드
  • Backend 관련 병합
  • 발표 대본 및 시연 영상 반영
  • 100건 평가용 테스트 추가

등이 이어진 것을 확인할 수 있다. (GitHub)

1. Frontend 최종 작업

오늘 내가 가장 집중한 부분은 Frontend 최종 정리였다.

내 담당 영역은 frontend/였고, 프로젝트에서 화면과 입력, Backend Client, 분석 결과 및 추가 질문 표시를 담당했다. README에도 현재 팀 역할이 그렇게 정리되어 있다. (GitHub)

오늘 최종적으로 정리한 Frontend는 단순히 질문을 입력하고 결과를 보여주는 화면이 아니라,

LawPath 시작
 ↓
법률 문제 입력
 ↓
AI 분석 요청
 ↓
분석 진행 상태 표시
 ↓
관련 근거 표시
 ├─ 법령
 ├─ 상담사례
 └─ 판례
 ↓
필요한 경우 추가 질문
 ↓
결과 저장
 ↓
질의 이력 확인

이라는 서비스 흐름을 보여줄 수 있도록 구성했다.

그리고 오늘 프론트엔드 파이널 커밋 앤 푸쉬라는 이름으로 최종 작업을 올렸다. 해당 커밋은 411개 파일이 변경된 큰 최종 반영 작업이었다. (GitHub)

2. 발표를 위해 기능보다 '흐름'을 확인했다

프로젝트를 개발할 때는 각각의 기능이 정상적으로 동작하는지가 중요했다.

하지만 발표 직전에는 관점이 조금 달라졌다.

발표에서는 사용자가 실제로 서비스를 사용하는 과정을 보여줘야 하기 때문이다.

그래서

"이 API가 정상적으로 응답하는가?"

보다

"사용자가 이 화면을 보고 다음에 무엇을 해야 하는지 이해할 수 있는가?"

를 더 신경 쓰게 됐다.

LawPath의 핵심 시연 흐름도 결국 다음과 같이 단순화할 수 있다.

생활 법률 문제 입력
        ↓
AI가 질문 분석
        ↓
필요하면 추가 정보 요청
        ↓
법률 자료 검색
        ↓
관련 법령 / 상담사례 / 판례 제공
        ↓
근거를 확인하면서 답변 확인

프로젝트의 기본 구조 역시 Frontend → Backend Agent → Legal MCP → PostgreSQL + pgvector로 연결되어 있다. (GitHub)

3. 법령·상담사례·판례를 보여주는 이유

이번 프로젝트에서 발표할 때도 중요하게 설명해야 했던 부분이다.

LawPath는 단순히 LLM에게

"이 법률 문제 어떻게 해결해?"

라고 질문하고 답을 받는 서비스가 아니다.

AI가 관련 자료를 검색하고 그 근거를 사용자에게 함께 보여주는 것이 핵심이다.

구조적으로는

법령
→ 실제 법률 규정

상담사례
→ 실제 상담·피해구제 사례

판례
→ 법원의 판단 사례

를 구분해서 보여준다.

프로젝트의 통합 목표 역시 소비자 분야에서 법령 3건, 상담사례 3건, 판례 3건을 각각 검색하고 Frontend에서 유형별로 표시하는 것이었다. (GitHub)

특히 상담사례와 판례를 같은 자료로 취급하지 않는 것도 이번 프로젝트에서 중요하게 생각했던 부분이다.

4. "무조건 9개를 보여준다"가 아니라는 점

이번 프로젝트를 진행하면서 개인적으로 인상 깊었던 부분이다.

처음에는

법령 3개 + 상담사례 3개 + 판례 3개 = 9개

를 보여주는 것이 목표라고 생각하기 쉽다.

하지만 실제 완료 기준은 그렇지 않았다.

관련 자료가 부족하다면 실제로 검색된 자료만 보여주는 것이 원칙이다.

즉,

법령 3개
상담사례 1개
판례 2개

라면 6개만 보여줘야 한다.

관련 없는 자료를 억지로 채우거나 AI가 존재하지 않는 근거를 만들어내면 오히려 법률 서비스에서는 문제가 될 수 있기 때문이다. 프로젝트 README에서도 중복·무관한 자료나 생성한 근거로 결과를 채우지 않도록 명시하고 있다. (GitHub)

이 부분을 프로젝트를 직접 만들어보면서 훨씬 현실적으로 이해하게 됐다.

5. 100건 평가 테스트도 추가했다

오늘 내가 추가한 작업 중 하나는 LawPath 100건 평가용 테스트 환경이었다.

프로젝트에는 tests/LAWPATH_EVALUATION.md, lawpath_100_dataset.py, run_lawpath_100.py, test_evaluation_dataset.py가 추가됐다. (GitHub)

100건의 테스트는 여러 상황을 나눠 구성했다.

정상 요청             50건
정보 부족              20건
검색 결과 없음         10건
API 타임아웃           10건
인증 실패                5건
상충 지시                5건

처럼 다양한 상황을 고려했다. (GitHub)

여기서 중요한 것은 이 테스트의 PASS가 법률 답변의 정답률을 의미하지 않는다는 것이다.

테스트에서는 완료 상태인지, 실제 모드 응답인지, 근거가 존재하는지, Frontend 계약이 맞는지 등을 확인하고, 법률적인 정확성은 별도의 사람이 평가하도록 구분했다. (GitHub)

이 부분을 보면서 AI 서비스에서 "테스트가 통과했다"는 말도 무엇을 테스트했는지 정확히 정의해야 한다는 것을 배웠다.

6. 발표자료도 직접 정리했다

오늘은 발표자료도 최종적으로 정리했다.

GitHub에는

  • LawPath_발표_대본.pdf
  • LawPath_발표_참고자료.pdf
  • LawPath_발표용.pdf
  • LawPath_발표용_표지.pdf
  • LawPath_발표자료.pdf
  • LawPath_시연_진행자료.pdf

등을 업로드했다. (GitHub)

단순히 PPT를 만드는 것보다 어려웠던 것은 어떤 순서로 프로젝트를 설명해야 이해하기 쉬운가였다.

개발하면서는

Frontend
Backend
MCP
Database
Agent

를 각각 따로 생각했지만 발표에서는 이렇게 설명하면 듣는 사람이 이해하기 어렵다.

그래서 발표에서는

"생활 속 법률 문제를 입력하면 LawPath가 어떻게 분석해서 근거를 찾아주는가?"

라는 하나의 사용자 시나리오를 중심으로 설명하는 것이 중요했다.

7. 팀 프로젝트에서 가장 많이 배운 부분

이번 미니프로젝트에서 기술적으로도 많은 것을 배웠지만, 개인적으로는 협업 과정 자체가 가장 큰 공부였다.

이번 프로젝트의 구조는

장상옥
Frontend

임다혁
Backend

오병훈
Legal MCP

박지혜
Database

로 역할을 나누었다. README에도 각 담당 영역과 책임이 정리되어 있다. (GitHub)

문제는 각자의 코드가 따로 동작한다고 해서 프로젝트가 완성되는 것이 아니라는 것이다.

예를 들어 Frontend에서는

consultations
similar_cases
related_laws

라는 데이터를 기대하는데 Backend에서 다른 이름으로 보내면 바로 문제가 발생한다.

그래서 프로젝트를 진행하면서 API 계약이 중요하다는 것을 직접 경험했다.

API 계약은 쉽게 말하면

"Frontend와 Backend가 서로 어떤 데이터를 어떤 이름과 형태로 주고받을지 정해놓은 약속"

이다.

프로젝트에서도 계약이 변경되면 Schema, 테스트, 명세서 등을 함께 수정하도록 정리되어 있다. (GitHub)

8. 팀 리더로서 느낀 점

이번 프로젝트에서는 Frontend 담당이면서 팀 리더 역할도 맡았다.

그래서 단순히 내 코드를 잘 만드는 것만으로 끝낼 수 없었다.

각 팀원의 작업이 어느 정도 진행되고 있는지 확인하고,

Backend
   ↕
Frontend

MCP
   ↕
Backend

Database
   ↕
MCP

각 부분이 실제로 연결될 수 있는지도 계속 확인해야 했다.

특히 마지막 날이 가까워질수록

"기능을 더 넣자."

보다

"지금 있는 기능이 발표 환경에서 확실하게 동작하는가?"

가 더 중요해졌다.

이 경험을 통해 팀 리더는 모든 코드를 직접 작성하는 사람이 아니라 각자의 작업이 하나의 결과물로 연결될 수 있도록 전체 흐름을 계속 확인하는 역할도 해야 한다는 것을 배웠다.

9. 발표 직전까지 계속 수정하게 되는 이유

프로젝트를 하면서 예상했던 것보다 발표 직전까지 수정할 것이 많았다.

개발할 때는 작은 문제가 크게 느껴지고, 발표를 준비할 때는 반대로 전체적인 흐름에서 부족한 부분이 보였다.

예를 들어

"이 기능은 구현했으니까 됐다."

라고 생각했던 것도 발표 시나리오에 넣어보면

"이걸 왜 사용하는지 설명하기 어렵다."

는 문제가 생긴다.

반대로 개발 과정에서는 중요하게 생각했던 세부적인 구현이 발표에서는 굳이 길게 설명할 필요가 없기도 했다.

결국 개발과 발표는 다른 관점에서 결과물을 바라보는 과정이었다.

10. 이번 미니프로젝트에서 가장 어려웠던 점

가장 어려웠던 것은 역시 짧은 시간 안에 여러 기술을 연결하는 것이었다.

이번 프로젝트에서는

  • Streamlit
  • FastAPI
  • LLM
  • Agent
  • MCP
  • PostgreSQL
  • pgvector
  • Embedding
  • API
  • 인증
  • 테스트
  • Git/GitHub

등 여러 요소가 하나의 프로젝트에 들어갔다.

각각의 기술을 하나씩 공부하는 것과 이 기술들을 실제 서비스 형태로 연결하는 것은 전혀 다른 문제였다.

특히 오류가 발생했을 때

Frontend 문제인가?
Backend 문제인가?
MCP 문제인가?
Database 문제인가?
환경변수 문제인가?
API 계약 문제인가?

를 찾아야 했다.

그래서 이번 프로젝트를 통해 개발에서 중요한 능력 중 하나는 오류가 발생하지 않게 만드는 능력뿐 아니라 오류가 발생했을 때 문제가 어느 영역에 있는지 빠르게 좁혀가는 능력이라는 것을 느꼈다.

11. 3일 동안 가장 크게 달라진 생각

처음에는 AI Agent 프로젝트라고 하면

LLM에게 좋은 프롬프트를 작성하고 MCP Tool을 연결하는 것

이 가장 중요하다고 생각했다.

하지만 프로젝트를 직접 만들어보면서 생각이 많이 바뀌었다.

실제 서비스에서는

LLM
+
Agent
+
Tool
+
Database
+
API
+
Frontend
+
Authentication
+
Testing
+
UX

가 모두 연결되어야 한다.

특히 법률처럼 답변의 근거가 중요한 분야에서는 단순히 AI가 그럴듯한 답을 만드는 것보다

어떤 자료를 검색했고
그 자료가 실제 질문과 관련 있는지
사용자가 그 근거를 확인할 수 있는지

가 훨씬 중요하다.

12. 두 번째 미니프로젝트 발표를 끝내며

이번 미니프로젝트는 첫 번째 미니프로젝트와는 확실히 다른 느낌이었다.

첫 번째 프로젝트에서는 팀 프로젝트 자체가 익숙하지 않았고, 내가 어떤 역할을 해야 하는지도 명확하지 않았다.

이번에는 Frontend 담당 + 팀 리더라는 역할을 맡으면서 프로젝트 전체를 조금 더 넓게 바라보게 됐다.

특히

"내 코드가 잘 돌아가는가?"

에서

"팀의 코드가 하나의 서비스로 연결되는가?"

로 생각하는 범위가 넓어진 것이 가장 큰 변화였다.

물론 아직 부족한 부분도 많다.

README의 현재 상태를 보면 소비자 분야의 대표 검색은 법령·상담사례·판례 각각 3건 반환까지 확인됐지만, 실제 Frontend의 최종 9건 표시나 일부 일반 서비스 데이터의 실제 DB 전환 등은 추가 검증이 필요한 상태로 정리되어 있다. (GitHub)

그래서 이번 프로젝트를 완벽하게 완성했다고 생각하기보다는, 짧은 기간 안에 AI Agent 서비스를 하나의 형태로 만들어보고 어디까지 구현할 수 있고 어디에서 부족한지 확인했다는 데 의미를 두고 싶다.

이번 미니프로젝트를 마치고

3일이라는 시간이 정말 짧았다.

기획하고, 역할을 나누고, 코드를 작성하고, Git으로 합치고, 오류를 해결하고, 테스트하고, 발표자료까지 만들다 보니 하루하루가 굉장히 빠르게 지나갔다.

특히 마지막 발표를 끝내고 나니 프로젝트를 시작할 때와 지금의 생각이 조금 달라진 것을 느낀다.

처음에는

"AI Agent를 만들어보자."

였다면,

지금은

"사용자가 실제로 사용할 수 있는 AI 서비스를 만들려면 무엇이 필요한가?"

를 조금 더 생각하게 됐다.

그리고 이번 프로젝트를 통해 내가 아직 Python, Backend, Database 같은 기초적인 부분에서 부족한 부분이 많다는 것도 다시 확인했다.

하지만 반대로 Frontend를 담당하면서 API를 연결하고, Backend와 데이터 구조를 맞추고, MCP와 Database가 어떻게 이어지는지 살펴보면서 전체적인 서비스 구조를 바라보는 시야는 이전보다 조금 넓어진 것 같다.

두 번째 미니프로젝트 발표까지 끝났으니 이제부터는 단순히 "프로젝트를 끝냈다"에서 멈추지 않고, 이번에 만든 LawPath를 통해 부족했던 부분을 다시 복습하고 내가 혼자서도 어느 정도 구현할 수 있는 기술 영역을 하나씩 늘려가는 것이 다음 과제가 될 것 같다.

미니프로젝트 3일차 핵심 정리

  • LawPath 최종 발표를 완료했다.
  • Frontend 최종 작업과 API 연동을 마무리했다.
  • 법령·상담사례·판례를 구분해 보여주는 구조를 정리했다.
  • 추가 정보가 필요한 질문과 정상적인 검색 요청을 구분했다.
  • 결과 저장 및 질의 이력 기능까지 하나의 사용자 흐름으로 연결했다.
  • 100건 평가용 데이터셋과 테스트 실행기를 추가했다. (GitHub)
  • 발표자료, 발표 대본, 시연 자료를 최종 정리했다. (GitHub)
  • 팀원들의 Backend·MCP·Database·Frontend 작업을 최종적으로 통합했다.
  • API 계약과 팀원 간 협업의 중요성을 경험했다.
  • "기능을 구현하는 것"과 "사용자가 실제로 사용할 수 있는 서비스로 만드는 것"의 차이를 배웠다.

이번 미니프로젝트를 한 문장으로 정리하면

두 번째 미니프로젝트는 AI Agent와 MCP를 실제 서비스 형태로 연결해보면서, 개발은 코드를 작성하는 것에서 끝나는 것이 아니라 팀의 코드를 하나의 사용자 경험으로 완성하는 과정이라는 것을 배운 3일이었다.