44일차 회고｜AI 법률 서비스 프론트엔드 통합과 결과 저장｜AI 오케스트레이션 개발자 국비지원

 

미니프로젝트 2일차가 지나면서 이제 단순히 화면을 만드는 단계에서 벗어나 Frontend와 Backend, Agent, MCP, DB가 실제로 연결되는 흐름을 확인하는 단계로 넘어갔다.

이번에는 내가 담당하고 있는 Frontend를 중심으로 실제 프로젝트 코드와 팀원들의 작업 내용을 맞춰보면서, 사용자가 질문을 입력한 뒤 결과를 확인하고 다시 조회할 수 있는 전체 흐름을 정리했다.

현재 프로젝트의 develop 브랜치는 Frontend, Backend, Database, Legal MCP가 각각 분리된 구조로 구성되어 있고, Frontend는 Streamlit을 이용해 Backend API와 연결되는 형태다. (GitHub)

---

1. 오늘 배운 내용

이번 프로젝트에서 가장 크게 느낀 부분은 Frontend 개발도 화면만 만드는 작업이 아니라 API 계약과 Backend의 데이터 구조를 함께 이해해야 한다는 것이었다.

현재 LawPath의 기본 흐름은 다음과 같다.

사용자 질문
   ↓
Frontend
   ↓
Backend Agent
   ↓
Legal MCP
   ↓
PostgreSQL + pgvector
   ↓
법령 / 상담사례 / 판례 검색
   ↓
Backend 응답
   ↓
Frontend 결과 표시

프로젝트에서는 법률 검색을 MCP를 통해 처리하고 있으며, 소비자·중고거래 분야에서는 법령, 상담사례, 판례를 각각 검색해 결과를 제공하는 구조를 목표로 하고 있다. (GitHub)

특히 단순히 "검색 결과 9개가 나왔다"가 중요한 것이 아니라 어떤 종류의 자료인지 구분해서 사용자에게 보여주는 것이 중요하다는 것을 다시 확인했다.

---

2. Frontend에서 실제로 신경 써야 했던 부분

내 담당은 frontend/였기 때문에 이번 프로젝트에서는 사용자가 실제로 서비스를 이용하는 흐름을 만드는 데 집중했다.

현재 Frontend는 Streamlit으로 구성되어 있고 Backend API만 호출하도록 역할을 분리하고 있다. Frontend가 DB나 MCP에 직접 접근하지 않는 구조다. (GitHub)

특히 이번에 작업하면서 중요하게 본 부분은 분석 결과를 어떻게 사용자에게 보여줄 것인가였다.

법률 검색 결과는 크게

• 관련 법령
• 상담사례
• 유사 판례

로 구분된다.

Backend에서는 각각 related_laws, consultations, similar_cases 형태로 전달되기 때문에 Frontend에서도 이 구조를 그대로 이해하고 화면에 표시해야 한다. (GitHub)

결국 Frontend 개발자는 단순히 API를 호출해서 JSON을 출력하는 것이 아니라,

"이 데이터가 사용자에게 어떤 의미를 갖는가?"

를 생각하면서 화면을 구성해야 한다는 것을 배웠다.

---

3. 분석 결과 저장과 질의 이력 연결

오늘 특히 의미 있었던 작업은 분석 결과 저장과 질의 이력 화면을 연결한 것이다.

GitHub 커밋을 확인해보면 내가 작업한 Frontend 쪽에서

feat(frontend): add post-result saving and unified history

작업이 반영되어 있다. 이후 frontend 브랜치가 develop에 merge되면서 결과 저장 및 이력과 관련된 변경사항이 통합됐다. (GitHub)

처음에는 법률 질문을 입력하고 결과를 보여주는 것만 생각했는데, 실제 서비스처럼 만들려면 사용자가 이전에 어떤 질문을 했는지 다시 확인할 수 있어야 한다.

그래서 이번 작업을 통해

질문 입력
↓
AI 분석
↓
분석 결과 확인
↓
결과 저장
↓
질의 이력에서 다시 확인

이라는 사용자 흐름을 조금씩 갖춰가고 있다.

이 과정에서 하나의 기능을 완성하려면 화면 하나만 수정해서 끝나는 것이 아니라 데이터가 저장되고 다시 조회되는 흐름까지 연결해야 한다는 것을 체감했다.

---

4. 화면의 가독성도 기능만큼 중요했다

Frontend 작업을 하면서 결과를 정확하게 가져오는 것만큼이나 사용자가 결과를 이해하기 쉽게 보여주는 것도 중요했다.

최근 작업에서는 분석 결과의 Evidence를 중첩 Expander 형태로 보여주도록 수정했고, PDF 오류 안내와 분석 자료 접기 UI도 개선했다. 또한 입력 체크리스트와 검색 진행 상태를 보여주는 UI도 추가했다. (GitHub)

법률 정보는 일반적인 텍스트보다 내용이 길고 용어도 어렵기 때문에 한 화면에 모든 내용을 펼쳐놓으면 오히려 사용하기 불편하다.

그래서

• 핵심 결과는 먼저 보여주고
• 세부 자료는 필요할 때 펼쳐보고
• 법령·판례·상담사례를 구분하고
• 검색이 진행 중인지 사용자가 알 수 있도록 하는 것

이 중요하다고 생각했다.

---

5. 입력 정보가 부족한 경우도 고려해야 했다

이번 프로젝트에서 또 하나 인상적이었던 부분은 사용자의 질문이 항상 충분한 정보를 가지고 있지는 않다는 것이다.

Backend에는 LLM을 활용한 입력 충분성 판단과 보완 질문 기능이 추가되어 있다. 실제로 Frontend에서도 Backend의 판단 결과와 보완 질문을 표시하도록 연결했다. (GitHub)

예를 들어 사용자가 단순히

"퇴직금을 받을 수 있나요?"

라고 질문한다고 생각해보면 근무기간이나 퇴직 상황 등에 따라 필요한 정보가 달라질 수 있다.

따라서 AI가 무조건 검색을 실행하는 것이 아니라,

질문 입력
↓
정보가 충분한가?
├─ YES → 검색 및 분석
└─ NO → 추가 질문

이라는 흐름을 만드는 것이 필요하다.

이 부분을 보면서 AI Agent 서비스에서는 검색 기능 자체보다 언제 검색하고, 언제 사용자에게 다시 질문할지를 판단하는 것도 중요한 기능이라는 것을 이해하게 됐다.

---

6. 팀 프로젝트를 하면서 느낀 어려움

이번 프로젝트에서 가장 어려운 부분은 각각의 기능을 따로 개발하는 것보다 팀원들이 만든 기능을 하나의 서비스로 연결하는 과정이었다.

현재 프로젝트 구조만 봐도

Frontend
Backend
Legal MCP
Database

가 각각 분리되어 있다. (GitHub)

따라서 Frontend에서 API를 호출하려면 Backend의 요청·응답 구조를 알아야 하고, Backend의 응답이 제대로 나오려면 MCP가 정상적으로 검색해야 하며, MCP 검색 결과가 제대로 나오려면 DB에 필요한 데이터가 들어 있어야 한다.

한 부분만 수정해도 다른 부분과 연결되는 경우가 많았다.

특히 GitHub의 현재 develop 상태에서도 원격 코드와 실제 실행 서버 사이에 차이가 남아 있고, 일부 기능은 아직 Mock 또는 임시 구현을 포함하고 있기 때문에 "API가 응답한다"는 것만으로 전체 기능이 완성됐다고 판단해서는 안 된다는 점도 확인했다. (GitHub)

---

7. 이번에 새롭게 이해한 점

프로젝트를 시작하기 전에는 Frontend를 주로

"사용자가 보는 화면을 만드는 작업"

이라고 생각했다.

하지만 실제 팀 프로젝트를 진행하면서 생각이 조금 바뀌었다.

Frontend는 결국 각각의 시스템을 사용자가 이해할 수 있는 하나의 경험으로 연결하는 역할도 해야 했다.

예를 들어 Backend에서 다음과 같은 상태를 전달한다고 해도,

status
termination_reason
follow_up_questions
related_laws
consultations
similar_cases

그 데이터를 그대로 출력하는 것만으로는 좋은 서비스가 되지 않는다. (GitHub)

사용자가

"지금 AI가 검색하고 있는 건지"

"내 질문에 정보가 부족한 건지"

"이 결과가 법령인지 판례인지"

"이전에 질문했던 내용을 다시 볼 수 있는지"

를 자연스럽게 알 수 있도록 만들어야 한다.

이번 프로젝트를 하면서 API 데이터 구조와 사용자 경험은 별개의 문제가 아니라 서로 연결되어 있다는 것을 조금씩 이해하고 있다.

---

8. 현재 나의 상태

현재는 Streamlit을 활용해 Frontend 화면을 만들고 Backend API와 연결하는 작업 흐름을 어느 정도 이해하고 있다.

특히 이번 프로젝트를 통해

• Frontend와 Backend의 역할 분리
• API 요청과 응답 구조
• 법률 검색 결과의 유형별 표시
• 추가 질문 UI
• 검색 진행 상태 표시
• 분석 결과 저장
• 질의 이력 연결
• 팀 브랜치와 PR을 통한 코드 통합

등을 실제 프로젝트 안에서 경험할 수 있었다.

다만 아직 Python과 Backend 코드 자체를 깊게 이해하는 수준은 아니다.

다른 팀원이 작성한 Agent Runtime이나 MCP Repository 코드를 봤을 때 전체적인 역할은 파악할 수 있지만, 내부 로직을 처음부터 끝까지 직접 구현할 수 있는 정도는 아니다.

그래서 지금은 "코드를 잘 짠다"기보다 전체 구조를 보고 각 기능이 어떻게 연결되는지 이해하는 능력이 조금씩 생기고 있는 단계라고 생각한다.

---

9. 오늘의 회고

미니프로젝트 2일차가 되면서 프로젝트의 모습이 조금씩 서비스 형태에 가까워지고 있다.

처음에는

"법률 질문을 입력하면 AI가 답변해주는 서비스"

정도로 생각했다.

하지만 실제로 구현해보니 그 안에는

입력 → 정보 충분성 판단 → Agent → MCP → DB 검색 → 결과 분류 → Frontend 표시 → 저장 → 이력 조회

처럼 생각보다 많은 과정이 들어가 있었다.

특히 이번 프로젝트에서 가장 크게 배운 것은 기능 하나를 만드는 것과 서비스를 만드는 것은 다르다는 것이다.

검색 기능이 정상적으로 동작하는 것에서 끝나는 것이 아니라 사용자가 결과를 이해하고, 필요한 정보를 추가로 입력하고, 이전 결과를 다시 확인할 수 있어야 실제 서비스에 가까워진다.

남은 프로젝트 기간에는 단순히 화면을 추가하는 것보다 실제 Backend와 MCP까지 연결된 상태에서 전체 사용자 흐름이 끊김 없이 동작하는지 확인하는 것에 집중해야겠다.

아직 부족한 부분은 많지만, 프로젝트를 직접 연결해보면서 수업에서 배웠던 AI Agent, MCP, API, DB, Frontend의 관계가 조금씩 하나의 그림으로 보이기 시작했다.

---

오늘의 핵심 정리

AI 서비스를 만든다는 것은 AI 모델 하나를 연결하는 것이 아니라, 사용자의 입력부터 검색·판단·결과 표시·저장까지 전체 흐름을 설계하는 일이라는 것을 배웠다.

해시태그

#AI오케스트레이션 #국비지원 #개발자국비지원 #멀티에이전트 #AI에이전트 #MCP #Streamlit #FastAPI #법률AI #미니프로젝트