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

미니프로젝트 2일차 회고｜LawPath 통합·저장 이력·법률 검색 고도화

랩보다 AI 더 잘해지기 2026. 9. 9. 20:59

728x90

미니프로젝트 LawPath 개발 2일차.

첫날에는 프로젝트의 기본 기능과 화면을 연결하는 데 집중했다면, 오늘은 본격적으로 각 팀원이 개발한 기능을 하나의 서비스 흐름으로 통합하고 실제 사용 시나리오를 완성하는 작업이 진행됐다.

특히 내가 맡은 Frontend + 팀 리더 역할에서는 Backend API와 연결되는 화면을 정리하고, 분석 결과 저장과 질의 이력, 로그인 상태, 오류 처리까지 하나의 흐름으로 연결하는 작업을 진행했다.

현재 develop 브랜치에는 오늘 날짜인 9월 9일 기준으로 Frontend, Backend, Database/MCP 관련 기능들이 계속 병합되고 있다. (GitHub)

오늘 진행한 프로젝트

이번 미니프로젝트의 주제는 생활 법률 문제를 AI Agent가 분석하고 관련 근거를 찾아주는 서비스 LawPath다.

사용자가 생활 속 법률 문제를 입력하면

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

형태로 동작한다.

현재 프로젝트는 임대차·주거, 근로·임금, 소비자·중고거래 분야를 대상으로 하고 있으며, 특히 소비자 분야에서는 법령·상담사례·판례를 각각 검색해서 결과를 제공하는 통합 흐름을 목표로 하고 있다. (GitHub)

1. 단순한 분석 결과에서 '저장할 수 있는 결과'로 확장

오늘 Frontend에서 가장 크게 작업한 부분은 분석 결과 저장 기능이었다.

기존에는

질문 입력
→ AI 분석
→ 결과 확인

으로 끝나는 구조였다.

하지만 실제 서비스라면 사용자가 나중에 다시 확인할 수 있어야 한다.

그래서 오늘은

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

이라는 흐름으로 확장했다.

실제 코드에서도 result_save.py, save_selection.py, saved_history.py, unified_history.py 등의 컴포넌트가 추가되었고, 저장 관련 API 계약을 별도의 문서로 정리했다. (GitHub)

2. 저장 API의 데이터 계약을 맞추는 과정

이번 작업에서 생각보다 중요했던 부분은 Frontend와 Backend가 어떤 데이터를 주고받을지 명확하게 정하는 것이었다.

예를 들어 분석 결과 저장은

POST /api/agent-runs/{run_id}/save

형태로 요청하고, 성공하면 conversation_id를 받아 저장된 이력과 연결한다.

또한 이미 저장된 결과를 다시 저장하더라도 새로운 레코드를 계속 만드는 것이 아니라 동일한 ID를 반환하도록 계약을 정리했다. (GitHub)

이 과정에서 run_id, request_id, conversation_id가 각각 다른 의미를 가진다는 것도 확인했다.

처음에는 이런 ID가 단순히 데이터를 구분하기 위한 값이라고 생각하기 쉬웠는데 실제 서비스를 연결하다 보니

분석 실행 ID
요청 ID
저장된 대화 ID

를 명확하게 구분해야 했다.

Frontend에서 API를 연결할 때 데이터의 이름과 의미를 정확하게 이해하는 것이 상당히 중요하다는 것을 다시 느꼈다.

3. 로그인 사용자와 비회원의 저장 방식 구분

저장 기능을 구현하면서 회원과 비회원의 처리 방식도 달라야 한다는 점을 확인했다.

회원은 로그인 상태에서 자신의 분석 결과를 저장하고 질의 이력에서 확인할 수 있다.

반면 비회원은 영구적으로 저장하는 것이 아니라 임시 이력 형태로 관리한다.

프로젝트의 Frontend 계약에서도 회원은 saved-conversations API를 사용하고, 비회원은 X-Guest-Id를 기반으로 임시 이력을 조회하는 구조로 정리되어 있다. (GitHub)

결국 같은 "이력" 기능이라도

회원
→ DB에 저장
→ 로그인 계정과 연결

비회원
→ 임시 저장
→ Guest ID와 연결

처럼 사용자 상태에 따라 다르게 처리해야 했다.

이 부분을 구현하면서 인증과 서비스 기능은 서로 따로 존재하는 것이 아니라 실제 사용자 경험에서는 연결되어 있다는 것을 체감했다.

4. 질의 이력을 하나로 통합

오늘은 기존에 각각 관리되던 이력 화면을 통합 이력 형태로 구성하는 작업도 진행했다.

LawPath에서는 크게

법률 사례 분석
법률 용어 질문

같은 기능이 존재하기 때문에 사용자가 여러 화면을 돌아다니지 않고 자신의 기록을 한 곳에서 확인할 수 있도록 구성하는 방향으로 수정했다.

저장된 대화 목록에는

제목
질문
요약
생성 시간
유형

등을 표시할 수 있도록 API 계약도 정리했다. (GitHub)

이 작업을 하면서 단순히 기능을 각각 만드는 것보다 사용자가 실제로 서비스를 이용하는 흐름을 기준으로 기능을 묶어야 한다는 점을 생각하게 됐다.

5. Backend 오류를 Frontend에서 사용자에게 맞게 처리하기

오늘은 API 오류 처리도 개선했다.

기존에는 Backend에서 오류가 발생하면 단순히 에러를 전달하는 방식이었다면, 이제 HTTP 상태 코드에 따라 사용자가 이해할 수 있는 메시지를 표시하도록 변경했다.

예를 들어

401
→ 로그인이 필요하거나 만료되었습니다.

403
→ 이 항목에 접근할 권한이 없습니다.

404
→ 항목이 없거나 해당 기능이 아직 준비되지 않았습니다.

와 같이 처리한다. (GitHub)

개발자 입장에서는 401, 403, 404가 명확하지만 일반 사용자에게는 그렇지 않다.

그래서 오류를 그대로 보여주는 것이 아니라 사용자가 다음에 무엇을 해야 하는지 알 수 있도록 바꿔주는 것이 Frontend의 역할 중 하나라는 것을 배웠다.

6. 로그인 상태도 API와 연결

오늘 Frontend에서는 API 모드에서 인증 상태를 갱신하도록 수정했다.

또한 API 요청에 인증 토큰을 전달하고, 인증이 만료된 경우 Frontend에서 이를 인식할 수 있도록 처리했다. (GitHub)

기존에는 화면을 기준으로

로그인 화면이 있다.

정도의 구현이었다면 이제는

로그인
↓
Token
↓
API 요청
↓
인증 확인
↓
내 저장 이력 조회

라는 실제 서비스 흐름에 가까워졌다.

이 부분은 단순한 UI 개발과 실제 웹 서비스 개발의 차이를 느낄 수 있었던 부분이다.

7. Backend에서는 입력이 충분한지 판단하는 기능 추가

오늘 Backend 쪽에서도 중요한 변화가 있었다.

사용자가 입력한 법률 질문이 바로 분석할 수 있을 정도로 충분한지 LLM 기반으로 판단하는 기능이 추가됐다.

그리고 정보가 부족하면 바로 답을 만들어내는 대신 추가 정보를 요청하는 흐름이 연결됐다.

GitHub의 오늘 커밋에서도

LLM 기반 입력 충분성 판단 구현

과

입력 판단 체크와 선택 저장 대화 흐름 추가

가 확인된다. (GitHub)

이 기능은 LawPath의 목적과도 상당히 잘 맞는다고 생각했다.

법률 질문은

"월세 계약 해지할 수 있나요?"

처럼 너무 짧게 들어오면 정확하게 판단하기 어렵다.

따라서 AI가 무조건 검색부터 하는 것이 아니라

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

이라는 과정을 거치는 것이 더 자연스럽다.

8. 법률 검색 데이터도 계속 확장

Database 쪽에서는 오늘 전체 사례 파일을 추가하고 해당 데이터를 적재하고 임베딩하는 작업도 진행됐다. (GitHub)

여기서 임베딩(Embedding)은 문장을 AI가 비교할 수 있는 숫자 벡터로 변환하는 과정이다.

LawPath에서는 이 데이터를 PostgreSQL의 pgvector와 연결해 질문과 의미적으로 가까운 법률 자료를 찾는 데 활용한다.

즉 단순히

"배송되지 않은 상품"

이라는 단어가 정확히 들어간 자료만 찾는 것이 아니라 의미가 비슷한 상담사례나 판례를 검색할 수 있도록 하는 것이다.

9. 법령·상담사례·판례를 구분하는 이유

오늘 프로젝트를 통합하면서 다시 중요하게 느낀 부분이다.

LawPath에서는 검색 결과를 하나로 섞지 않는다.

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

를 각각 구분한다.

README에서도 소비자 분야의 목표 결과를

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

으로 구분하고 있으며, 실제 검색 결과가 부족한 경우 억지로 9건을 채우지 않는 것을 완료 기준으로 정하고 있다. (GitHub)

이 기준이 중요한 이유는 AI 서비스에서 결과의 개수보다 결과의 신뢰성과 출처가 더 중요하기 때문이다.

10. "9건을 채우는 것"이 목표가 아니라는 점

프로젝트를 개발하다 보면

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

를 화면에 보여주는 것이 목표처럼 느껴질 수 있다.

하지만 실제 프로젝트 기준은 그렇지 않다.

검색 결과가

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

라면 그대로 6개를 보여줘야 한다.

관련 없는 자료를 억지로 추가하거나 존재하지 않는 근거를 만들어서는 안 된다.

README에도 자료가 부족하면 실제 검색된 건수만 반환하고, 중복·무관한 자료나 생성한 근거로 9건을 채우지 않는다고 명시되어 있다. (GitHub)

이 부분은 법률 AI 프로젝트에서 특히 중요하다고 생각했다.

11. 팀 리더로서 느낀 부분

오늘은 개인적인 코드 작업뿐 아니라 팀 전체의 코드를 맞추는 과정이 많았다.

각자 담당 영역에서는 기능이 정상적으로 동작하더라도 실제로 합치면

Backend의 응답 구조
≠
Frontend가 기대하는 구조

가 되는 경우가 생길 수 있다.

그래서 오늘은 기능 자체보다

API 계약
데이터 필드
ID 규칙
저장 방식
인증 상태
검색 결과 구조
오류 상태

같은 팀 간 약속을 맞추는 작업의 중요성을 크게 느꼈다.

실제로 오늘 develop 브랜치에는 여러 팀원의 작업이 Merge되면서 Frontend, Backend, Database 관련 변경사항이 동시에 들어왔다. (GitHub)

어려웠던 점

오늘 가장 어려웠던 부분은 내가 작성한 Frontend 코드만 이해해서는 프로젝트 전체를 완성할 수 없다는 점이었다.

예를 들어 저장 버튼 하나를 만들더라도

저장 버튼
 ↓
run_id 필요
 ↓
Backend 저장 API
 ↓
인증 Token 필요
 ↓
conversation_id 반환
 ↓
이력 목록에 표시
 ↓
상세 조회
 ↓
삭제

까지 연결되어야 한다.

따라서 하나의 기능을 개발할 때 해당 기능의 앞뒤 흐름까지 확인해야 했다.

특히 팀 프로젝트에서는 각자의 코드를 합치는 과정에서 API 계약이 맞지 않으면 바로 문제가 발생하기 때문에 코드를 작성하는 능력뿐 아니라 다른 사람이 만든 코드를 읽고 연결하는 능력도 중요하다는 것을 느꼈다.

오늘 새롭게 이해한 점

오늘 가장 크게 이해한 것은 AI Agent 프로젝트도 결국 하나의 서비스라는 점이다.

처음에는

LLM + MCP + RAG를 구현하면 AI 프로젝트가 완성되는 것 아닐까?

라고 생각하기 쉬웠다.

하지만 실제로 만들어보니

AI Agent
+
MCP
+
RAG
+
Database
+
Backend API
+
Authentication
+
Frontend
+
Storage
+
Error Handling

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

특히 오늘 저장 기능을 추가하면서 이 점을 더 확실하게 느꼈다.

AI가 아무리 좋은 답을 만들어도 사용자가

"이 결과를 나중에 다시 볼 수 있나?"

라고 했을 때 아무것도 할 수 없다면 실제 서비스로서는 부족하다.

현재 LawPath의 상태

미니프로젝트 2일차가 끝난 현재 LawPath는 단순한 화면 시제품에서 벗어나 실제 통합 서비스에 가까워지고 있다.

현재 목표 구조는

사용자
 ↓
질문 입력
 ↓
입력 정보 충분성 판단
 ↓
필요하면 추가 질문
 ↓
Consumer Agent
 ↓
MCP 검색
 ├─ 법령
 ├─ 상담사례
 └─ 판례
 ↓
PostgreSQL + pgvector
 ↓
분석 결과
 ↓
Frontend 표시
 ↓
결과 저장
 ↓
질의 이력

형태로 확장되고 있다. (GitHub)

다만 아직 모든 기능이 완전히 통합되어 검증된 것은 아니다.

README에서도 소비자 분야의 API 기준 검색 결과는 확인했지만 실제 Frontend 최종 화면까지의 통합 검증은 남아 있는 상태라고 정리되어 있다. (GitHub)

미니프로젝트 2일차를 마치며

첫날에는

"일단 동작하는 서비스를 만들어보자."

라는 생각이 강했다.

하지만 2일차가 되면서 생각이 조금 바뀌었다.

"동작하는 것"과 "사용할 수 있는 것"은 다르다.

오늘은 분석 결과를 저장하고, 로그인 상태를 관리하고, 이력을 조회하고, 오류를 처리하고, 입력이 부족하면 추가 질문을 하는 기능까지 연결하면서 이 차이를 직접 경험했다.

특히 Frontend 담당자로서 화면만 완성하는 것이 아니라 Backend API의 구조와 데이터 흐름까지 이해해야 제대로 된 화면을 만들 수 있다는 것을 배웠다.

또 팀 리더 입장에서는 각자 열심히 만든 코드가 하나의 서비스로 연결되려면 팀원 간 API 계약과 데이터 구조를 맞추는 과정이 반드시 필요하다는 것도 느꼈다.

내일은 최종 발표를 앞두고 있기 때문에 새로운 기능을 무작정 추가하기보다는 지금까지 구현한 기능을 실제 사용자 흐름으로 처음부터 끝까지 점검하고, 발표에서 LawPath가 왜 필요한 서비스이고 AI Agent와 MCP, RAG가 어떤 역할을 하는지 명확하게 보여주는 것에 집중해야겠다.

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

AI 법률 분석 결과 저장 기능을 구현했다.
저장된 결과를 확인할 수 있는 통합 질의 이력을 구성했다.
회원과 비회원의 이력 처리 방식을 구분했다.
run_id, request_id, conversation_id 등 API 데이터 계약을 정리했다.
로그인 Token을 API 요청과 연결했다.
401 / 403 / 404 등의 Backend 오류를 사용자 친화적인 메시지로 처리했다.
LLM을 활용해 법률 질문의 정보 충분성을 판단하는 흐름이 추가됐다.
정보가 부족한 질문에는 추가 질문을 통해 정보를 보완하도록 연결했다.
법령·상담사례·판례를 별도의 근거 자료로 관리했다.
Database에 상담사례 데이터를 적재하고 임베딩하는 작업이 진행됐다.
팀원들의 Backend·MCP·Database·Frontend 코드를 develop에 통합했다.
단순히 기능을 만드는 것보다 API 계약과 전체 사용자 흐름을 맞추는 것이 중요하다는 것을 배웠다.

오늘의 한 문장 회고

미니프로젝트 2일차는 AI 기능을 만드는 단계에서 한 단계 더 나아가, 여러 기술과 팀원의 코드를 하나의 실제 서비스 흐름으로 연결하는 과정이었다.