43일차 회고｜상담사례 연동·Frontend 상태 처리·테스트｜AI 오케스트레이션 개발자 국비지원

 

오늘은 미니프로젝트 LawPath의 기능을 실제 서비스 흐름에 맞게 다듬는 작업을 진행했다.

특히 내가 담당하고 있는 Frontend 영역에서 Backend가 전달하는 상담사례 데이터를 화면에 표시하고, 분석 진행 상태와 결과 상태를 사용자에게 명확하게 보여주는 작업에 집중했다.

GitHub develop 브랜치의 오늘 프로젝트 변경사항을 기준으로 정리하면, 단순히 화면을 꾸미는 것보다 Backend → Frontend 데이터 계약을 맞추고 실제 검색 결과를 사용자에게 어떻게 보여줄 것인가가 중요한 작업이었다. (GitHub)

---

오늘 배운 내용

오늘 프로젝트에서 가장 크게 느낀 부분은 Frontend 개발도 화면만 만드는 작업이 아니라 Backend와의 데이터 계약을 이해하는 과정이 필요하다는 것이었다.

LawPath의 기본 구조는 다음과 같다.

사용자
  ↓
Frontend
  ↓
Backend Agent
  ↓
Legal MCP
  ↓
PostgreSQL + pgvector
  ↓
법령 / 상담사례 / 판례
  ↓
Backend
  ↓
Frontend

현재 프로젝트는 법률 질문을 입력하면 Backend Agent가 MCP의 검색 도구를 활용해 관련 법령, 상담사례, 판례를 검색하고 그 결과를 Frontend에서 보여주는 구조로 만들어지고 있다. (GitHub)

여기서 오늘 추가된 중요한 데이터가 상담사례(consultations)였다.

기존에는 주로

• 관련 법령
• 유사 판례

를 화면에 표시했다면, 이제는 여기에 소비자원 상담사례까지 별도의 근거 자료로 표시할 수 있도록 수정했다.

---

1. 상담사례 데이터를 Frontend에 연결하기

오늘 내가 작업한 핵심 중 하나는 consultations 데이터를 Frontend에서 정상적으로 받을 수 있도록 구조를 확장한 것이다.

기존 모델에서는 Source의 종류가

law
case
external

정도로 구분되어 있었는데, 여기에

consultation

을 추가했다.

또한 LegalQuestionView에도 다음과 같이 상담사례 목록을 받을 수 있도록 변경했다.

consultations: list[EvidenceView] = Field(default_factory=list)

즉 Backend에서 상담사례가 들어오더라도 Frontend 모델에서 이를 받을 수 있는 구조가 된 것이다. (GitHub)

처음에는 이런 부분이 단순히 변수 하나 추가하는 작업처럼 보였다.

하지만 실제로는

Backend 응답
→ Frontend Model
→ API Service
→ 화면 컴포넌트
→ 다운로드 결과
→ 테스트

까지 연결되어야 제대로 된 기능이 된다는 것을 알게 됐다.

---

2. 법령·판례와 상담사례를 구분해서 보여주기

상담사례는 판례와 비슷하게 참고할 수 있는 자료지만 같은 종류의 자료는 아니다.

그래서 화면에서도 단순히 판례 목록에 섞어버리지 않고 별도의 영역으로 표시하도록 수정했다.

현재 화면에서는 다음과 같이 구분한다.

관련 법령

유사 판례

소비자원 상담사례

특히 상담사례 영역에는

공식 상담·피해구제 사례이며 법원 판례와 구분됩니다.

라는 설명도 함께 표시하도록 했다. (GitHub)

이 작업을 하면서 법률 AI 서비스에서는 검색 결과를 많이 보여주는 것보다 각각의 자료가 무엇인지 정확하게 구분해서 보여주는 것이 중요하다는 점을 다시 생각하게 됐다.

법령과 판례와 상담사례를 전부 하나의 "검색 결과"로 보여주면 사용자가 어떤 자료를 근거로 판단해야 하는지 혼란스러울 수 있기 때문이다.

---

3. 분석 중이라는 상태를 사용자에게 보여주기

또 하나 크게 수정한 부분은 분석 진행 상태 표시였다.

기존에는 분석 과정에서 별도의 Workflow 표시를 사용했지만, 실제 API 연동 환경에서는 사용자 입장에서 더 직관적인 상태 표시가 필요했다.

그래서 st.status()를 활용해 분석 중에는

사례를 분석하고 있습니다.

라는 상태를 보여주고,

완료되면

분석 요청 처리가 완료되었습니다.

로 변경하도록 했다.

오류가 발생하면

분석을 완료하지 못했습니다.

라는 상태가 표시된다. (GitHub)

이걸 구현하면서 단순히 API 요청을 보내고 결과를 기다리는 것과 사용자가 현재 시스템에서 어떤 일이 진행되고 있는지 이해할 수 있도록 만드는 것은 다른 문제라는 것을 느꼈다.

특히 AI Agent처럼 내부에서 여러 Tool을 호출할 수 있는 서비스에서는 요청 시간이 길어질 수 있기 때문에 이런 상태 표시가 더 중요하다고 생각한다.

---

4. Mock과 실제 API의 화면을 구분하기

프로젝트 초반에는 화면 개발을 위해 Mock 데이터를 많이 사용했다.

하지만 실제 Backend와 연동하기 시작하면서 Mock 데이터와 실제 데이터를 동일하게 취급하면 문제가 생길 수 있었다.

그래서 이번 작업에서는 is_mock 값을 확인해서 Demo 데이터일 때만 Demo 배너를 표시하도록 수정했다.

if result.get("is_mock", True):
    render_demo_banner()

또한 실제 API 모드에서는 기존의 Mock용 분석 진행 표시가 중복되지 않도록 처리했다. (GitHub)

이 작업을 하면서 프로젝트가 "화면을 만드는 단계"에서 "실제 서비스 구조를 연결하는 단계"로 넘어가고 있다는 느낌을 받았다.

---

5. 검색 결과가 없을 때도 정상적인 상태로 처리하기

오늘 또 하나 중요했던 부분은 결과가 없다고 해서 무조건 실패가 아니라는 것이었다.

예를 들어 법령이나 판례가 없어도 상담사례가 검색될 수 있다.

기존에는

related_laws 또는 similar_cases

가 있어야 완료 상태로 판단했다.

하지만 이제는

related_laws
similar_cases
consultations

중 하나라도 결과가 있으면 완료된 것으로 판단하도록 수정했다. (GitHub)

이 부분은 실제 AI 서비스를 만들 때 상당히 중요한 개념이라고 느꼈다.

예를 들어

법령 0건
판례 0건
상담사례 3건

이라면 검색 실패가 아니라 상담사례를 통해 참고할 수 있는 결과가 존재하는 정상적인 검색 결과다.

결과의 존재 여부를 단순한 Boolean으로 판단하는 것보다 어떤 종류의 결과가 반환되었는지까지 고려해야 한다는 것을 배웠다.

---

6. 다운로드 결과에도 상담사례 추가

화면에서만 상담사례를 보여주는 것으로 끝내지 않았다.

LawPath에서는 분석 결과를 Markdown 형태로 내보낼 수 있기 때문에 다운로드 결과에도 상담사례를 포함하도록 수정했다.

기존에는

입력한 상황
↓
관련 법령
↓
유사 판례

였다면 이제

입력한 상황
↓
관련 법령
↓
유사 판례
↓
소비자원 상담사례

까지 포함된다. (GitHub)

또한 Mock 데이터인지 실제 검색 데이터인지에 따라서 안내 문구도 다르게 표시하도록 수정했다.

이 작업을 통해 화면에 표시되는 데이터와 다운로드되는 데이터의 일관성도 중요하다는 것을 알게 됐다.

---

7. 실제 데이터를 받는 상황을 테스트하기

오늘은 코드만 수정한 것이 아니라 상담사례 데이터가 실제로 들어왔을 때 화면에서 문제가 없는지 테스트할 수 있는 코드도 추가했다.

테스트에서는 상담사례만 반환되는 상황을 만들어서

• consultations 데이터가 정상적으로 들어오는지
• 분석 상태가 completed가 되는지
• 법령과 판례가 없어도 정상 처리되는지
• Markdown 다운로드 결과에 상담사례가 포함되는지
• Streamlit 화면에 상담사례가 표시되는지
• "검색 결과가 없습니다"가 잘못 표시되지 않는지

등을 확인하도록 했다. (GitHub)

그리고 기존에 consultations 필드가 없는 예전 응답도 오류 없이 처리할 수 있도록 호환성 테스트까지 추가했다.

이 부분을 보면서 새로운 기능을 추가하는 것뿐 아니라 기존 기능이 깨지지 않도록 하는 것도 개발의 중요한 부분이라는 것을 다시 느꼈다.

---

오늘의 가장 큰 깨달음

오늘 가장 크게 배운 것은 Frontend는 Backend에서 오는 데이터를 "그냥 받아서 보여주는 역할"이 아니라는 것이다.

실제 프로젝트에서는 다음과 같은 계약이 계속 맞아야 한다.

Backend Schema
      ↓
API Response
      ↓
Frontend Model
      ↓
Service
      ↓
Component
      ↓
화면
      ↓
Test

한 곳에서 필드 이름이나 데이터 구조가 바뀌면 다른 부분도 영향을 받는다.

특히 오늘 consultations를 추가하면서 이 흐름을 직접 경험했다.

단순히 화면에

상담사례를 추가해주세요.

라고 하면 끝나는 것이 아니라,

데이터가 어디에서 생성되고 → 어떤 형태로 전달되고 → Frontend에서 어떻게 변환되고 → 어떤 UI로 보여주고 → 다운로드와 테스트에는 어떻게 반영할 것인지

까지 생각해야 했다.

---

프로젝트 전체적으로도 변화가 있었다

오늘 develop 브랜치에는 Backend와 MCP 쪽에서도 상당한 변경이 이어졌다.

실제로 오늘 프로젝트 변경사항에는

• MCP 추가 Tool 호출 연결
• 근거 부족 시 보완 검색
• 상담사례 MCP Tool 연결
• Consumer 상담사례 검색 흐름 연결
• Agent Tool 선택 및 Backend DB 연결
• Frontend 상담사례 응답 지원

등이 함께 진행됐다. (GitHub)

즉 각 팀원이 자신의 담당 영역만 개발하는 것이 아니라 Frontend ↔ Backend ↔ MCP ↔ Database가 실제로 연결되는 단계로 넘어가고 있었다.

프로젝트 README에서도 현재 구조를

Frontend
→ Backend Agent
→ Legal MCP
→ PostgreSQL + pgvector

형태로 정의하고 있고, 내가 담당한 Frontend는 Backend API만 호출하도록 역할이 분리되어 있다. (GitHub)

---

어려웠던 점

오늘 가장 어려웠던 부분은 특정 코드 하나를 작성하는 것보다 각 컴포넌트의 역할과 데이터 흐름을 이해하는 것이었다.

특히 프로젝트가 커지면서

Frontend
Backend
Agent
MCP
Repository
Database

각각의 코드가 서로 연결되어 있기 때문에 한 부분만 보고 수정하면 다른 부분에서 문제가 생길 수 있다.

그래서 앞으로는 코드를 수정할 때도

"이 값을 누가 만들고, 어디에서 전달하고, 최종적으로 어디에서 사용하는가?"

를 먼저 확인하는 습관이 필요하다고 느꼈다.

---

현재 나의 상태

미니프로젝트를 시작할 때는 Frontend를 주로 화면 구성의 관점에서 생각했다.

하지만 지금은 조금 다르게 생각하게 됐다.

사용자 입력
→ API 요청
→ Agent 처리
→ MCP Tool 검색
→ 검색 결과 반환
→ Frontend 데이터 변환
→ 결과 표시

전체 흐름을 어느 정도 이해하면서 개발해야 실제 서비스 형태의 Frontend를 만들 수 있다는 것을 체감하고 있다.

특히 오늘은 내가 담당한 Frontend에서 실제 Backend 응답 구조에 맞춰 UI와 모델, 테스트까지 함께 수정하는 경험을 했다.

아직 Backend Agent의 내부 동작이나 MCP 검색 로직까지 완전히 이해했다고 할 수는 없지만, 적어도 내가 담당하는 Frontend가 전체 시스템에서 어떤 역할을 하는지는 이전보다 명확해졌다.

---

앞으로 보완할 부분

앞으로는 단순히 결과를 화면에 표시하는 것을 넘어서 다음 부분을 더 확인해야 할 것 같다.

• Backend 실제 연동 환경에서 전체 E2E 테스트
• 추가 질문이 필요한 경우의 UI 처리
• 검색 결과가 없는 경우와 검색 실패의 구분
• 법령·판례·상담사례 결과의 일관된 UI
• 별도 법령/판례/상담사례 검색 화면
• 질의 이력과 DB 연동
• 실제 DB 저장소 전환 후 Mock 제거

현재 프로젝트 README에서도 소비자 분야의 법령·상담사례·판례 3종 검색 결과를 실제 화면까지 연결하고, 임대차·근로 분야의 추가 정보 질문 흐름을 검증하는 것이 다음 개발 단계로 정리되어 있다. (GitHub)

---

오늘의 회고

오늘은 코드를 많이 작성했다는 것보다 프로젝트가 실제 서비스에 가까워지는 과정에서 Frontend가 어떤 역할을 해야 하는지 배운 날이었다.

특히 상담사례를 추가하면서 단순히 UI 하나를 만드는 것이 아니라,

데이터 모델 → API → 서비스 → 컴포넌트 → 다운로드 → 테스트

까지 하나의 기능이 연결되어 있다는 것을 직접 경험했다.

처음에는 "상담사례를 화면에 보여주면 된다"고 생각했지만 실제로 구현해보니 데이터 계약과 예외 상황, 기존 기능과의 호환성까지 고려해야 하나의 기능이 완성된다는 것을 알게 됐다.

미니프로젝트가 이제 단순한 기능 구현을 넘어 실제 통합 테스트 단계로 들어가고 있는 만큼, 앞으로는 내가 작성한 코드만 보는 것이 아니라 전체 서비스가 사용자 입장에서 처음부터 끝까지 정상적으로 동작하는지 확인하는 시각을 더 키워야겠다.

---

오늘의 핵심 정리

• 상담사례 데이터를 Frontend에 연동했다.
• 법령·판례·상담사례를 서로 다른 근거 자료로 구분했다.
• AI 분석 중·완료·실패 상태를 사용자에게 표시하도록 개선했다.
• Mock 데이터와 실제 API 결과를 구분했다.
• 검색 결과가 상담사례만 존재하는 경우도 정상적인 완료 상태로 처리했다.
• 다운로드 결과에도 상담사례를 포함했다.
• 상담사례 응답에 대한 Frontend 테스트를 추가했다.
• Frontend 개발에서도 Backend와의 데이터 계약을 이해하는 것이 중요하다는 것을 배웠다.
• 프로젝트가 화면 구현 단계에서 Frontend–Backend–MCP 통합 단계로 넘어가고 있음을 체감했다.

43일차의 가장 큰 배움은 "화면 하나를 만드는 것보다 하나의 기능이 전체 시스템에서 어떻게 연결되는지를 이해하는 것이 더 중요하다"는 것이었다.

LawPath GitHub 저장소