주제 : 자체 sLLM 개발을 통한 기업 업무 활용 생성형 AI 플랫폼
서비스명 : LAWMATE (생성형 AI 기반 법무법인 업무 보조 플랫폼)
1. 주제 선정 및 이유
이번 프로젝트의 주제는 생성형 AI 기반 법무법인 업무 보조 플랫폼이다.
사실 처음에는 문서 템플릿 자동 생성과 회의록 자동 작성 기능을 중심으로 기획을 시작했었다. 이 아이디어는 범용적으로 활용 가능하다는 장점이 있었지만, 어떤 산업에나 적용될 수 있는 만큼 차별성이 부족했고, 특정 기능 하나를 깊이 있게 설계해보기엔 다소 애매하다는 판단이 들었다.
그래서 팀원들과 논의 끝에, 조금 더 복잡하고 보수적인 법률 분야에 생성형 AI를 적용해보자는 결론에 도달했다. 법무법인이라는 특수한 환경에서 실제 사용할 수 있도록 설계하고, 나아가 기업 내부의 법무팀에서도 적용 가능하다는 확장성 측면도 고려했다.
우리는 단순히 문서 자동화에서 그치는 게 아니라, 전략 수립까지 보조 가능한 AI 시스템을 만들어보고자 했다. 마침 공개된 민사소송 판례 데이터셋도 존재해 LLM 모델을 파인튜닝하여 실제 서비스에 적용해볼 수 있다는 점도 주제 선정에 큰 도움이 되었다.
2. 서비스 개요 및 이름 선정
이번 프로젝트에서 우리가 만든 서비스의 이름은 LAWMATE다.
'Law + Mate'의 합성어로, 말 그대로 법률 업무를 함께 도와주는 AI 동료라는 의미를 담고 있다.
법무법인 내 변호사나 실무자들이 다루는 문서들은 대부분 복잡하고, 참고해야 할 판례들도 방대하다. 이런 상황에서 LAWMATE는 단순히 기능만 제공하는 도구가 아니라, 클라이언트의 문제 해결을 함께 고민하고, 전략까지 함께 세워주는 '동료' 같은 존재가 되기를 바라는 마음으로 이름을 지었다.
단순한 자동화 시스템이 아니라, 실질적으로 의사결정에 도움을 줄 수 있는 지능형 보조 파트너라는 이미지가 어울린다고 생각했다.
3. 기획 및 설계 과정
서비스 기획
이번 프로젝트에서는 민사소송 건수 증가와 정보 과부하 문제를 해결하는 데 초점을 맞췄다.
그에 따라 핵심 기능으로는
- 판례 결과 분석
- 유사 판례 검색
- 전략 분석
이 세 가지를 설정했다.
또한, 사용자의 역할(파트너 / 변호사 / 사무원 등)에 따라 제공하는 기능과 대시보드를 다르게 구성함으로써, 협업 효율을 높이는 구조를 만들고자 했다.
기술 설계
구현 과정에서는 아래와 같은 기술 스택과 구조를 설계했다:
- 인증/인가:
JWT 토큰 기반 인증 방식을 적용하여 사용자 권한과 정보를 안전하게 관리 - 판례 결과 분석 분류:
bert-base-multilingual-cased모델을 활용한 자연어 분류 모델 도입 - 유사 판례 검색:
FAISS벡터 DB를 활용한 임베딩 기반 검색 시스템 구성 - 챗봇 응답 생성:
GPT-4o모델을 기반으로 답변 생성 - RAG 파이프라인 구성: 챗봇 흐름을 여러 개의 분기로 나누고, 분기 판단은 GPT-4o가 수행
- 예를 들어, 분기 중 하나인 사건 전략 수립은
Gemma3-1b모델을 Full 파인튜닝한 뒤 사용자가 입력한 사건 정보를 기반으로 전략을 생성해주는 구조로 구성
- 예를 들어, 분기 중 하나인 사건 전략 수립은
- AI 추천 팀 기능:
LangGraph기반으로 구성- 단순히 유사 사건 처리 이력만 고려하는 게 아니라, 현재 각 팀의 업무량까지 반영한 가중치 수식을 적용해 기아 상태(한쪽만 계속 배정되는 상황)를 방지
- 백엔드 인프라:
Django: 웹 서비스 전체를 구성FastAPI: AI 모델 추론 및 판례 검색 등 AI 기능을 별도의 API로 분리
- 프론트엔드: 사용자 경험을 고려한 대시보드 및 판례 검색 화면 구성
프로젝트 구현을 위한 자료조사
이번 프로젝트를 준비하면서 학습한 개념들을 내 블로그에 정리해 두었다.
주요 개념들을 팀 내에서 공유하거나, 기능 구현 전 참고용으로 자주 활용했다.
4. 어려웠던 점 & 해결 과정
1) 데이터 수집 및 전처리
- 대법원에서 제공한 판례 JSON은 구조가 일정하지 않고, HTML 태그가 포함된 경우가 많아서 분석이 어려웠다.
→HTML 태그 제거,불필요한 문장 정리,라벨 정제등을 단계별로 자동화하는 방식으로 해결했다.
2) 클래스 불균형 문제
- 일부 라벨은 데이터 수가 극히 적어서 모델 학습에 어려움이 있었다.
→Stratified Split을 적용해 학습/검증/테스트 세트를 균등하게 분할했다.
→ 라벨 수가 너무 적은 경우는 룰 기반으로 사전 처리하고, 나머지는bert 기반 분류 모델로 학습했다.
→ 평가 지표는f1-score를 선택하여 소수 클래스까지 고려할 수 있도록 구성했다.
3) 유사 판례 검색 정확도 부족
-
단순히 벡터 임베딩만으로는 법률 문서의 쟁점이나 문맥을 충분히 반영하지 못하는 문제가 있었다.
→ 특히, '손해배상'이나 '과실' 같은 단어가 반복된다는 이유로 서로 다른 성격의 사건(예: 교통사고와 의료소송)을 유사하다고 판단하는 경우가 발생했다.
→ 자주 인용되는 유명 판례는 잘 검색되지만, 최신 판례나 희귀 사건은 벡터 공간에서 고립되어 검색되지 않는 경우가 있었다. -
이를 해결하기 위해, 판례 전문 전체를 임베딩하는 대신 핵심 정보를 추출한 뒤 임베딩하는 구조로 개선했다.
- 판시사항, 판결요지 등 주요 컬럼을 선정하고, GPT-4를 활용해 요약문과 키워드를 생성했다.
- 자동 생성된 텍스트를 직접 검토하여, 판례의 핵심 쟁점을 잘 반영하고 있는지 정성 평가를 진행했다.
- 이후, 원문 전체가 아닌 정제된 요약문과 주요 키워드만 벡터로 임베딩하여 불필요한 노이즈를 줄이고 검색 정확도를 높였다.
4) 기아 상태 발생 가능
- 팀 추천 기능을 처음 설계했을 때는, 유사 사건 처리 경험이 있는 팀에게 사건을 배정하는 방식이었다.
→ 하지만 이 방식은 유사한 사건을 처리한 적이 없는 팀은 영원히 사건 배정이 되지 않는 ‘기아 상태’가 발생할 수 있었다.
→ 그래서 선택한 방법은 가중치 수식을 도입하는 것이었다.
→ 유사도와 현재 업무량을 동시에 고려한 수식을 만들고, α(알파), β(베타) 값을 조정하며 테스트를 반복했다.
→ 그 결과, 모든 팀에게 균등하게 사건이 분배되도록 구조를 개선할 수 있었다.
| 설명 | 이미지 |
|---|---|
| 최종 수식 |  |
| 알파(α), 베타(β) |   |
| norm_sim 변수 수식 |  |
| MinMax 수식 정의 |  |
5) Database 및 Django 환경변수 저장 위치
- 처음에는
.env파일을 통해 환경변수와 데이터베이스 정보를 관리했다.
→ 하지만 로컬에 민감한 정보가 그대로 저장되어 있어, 보안상 위험하다고 판단했다.
→ 이를 해결하기 위해 AWS Parameter Store를 사용해 환경변수를 외부에서 안전하게 관리하도록 수정했다.
6) Database 실행 위치 통일
- 초기에는 각 팀원의 로컬에서 Docker로 MySQL을 실행했다.
→ 환경 설정이 달라 오류가 발생하기 쉬웠고, 모든 변경사항을 팀원들이 수동으로 맞춰야 하는 번거로움이 있었다.
→ 이를 해결하기 위해 AWS RDS를 사용해 공용 DB를 구축했고, 팀원 전원이 같은 RDB를 바라보도록 구조를 통일했다.
7) JWT 인증/인가 로직을 미들웨어로 구성
- 우리 팀은 보안을 강화하기 위해
JWT 토큰 기반 인증/인가방식을 도입했다.
→ 법률 서비스라는 주제 특성상, 보안은 필수 요소라고 판단했기 때문이다.
→ 초기에 인증 로직을 클래스 단위로 구현했는데, 이 경우 모든 기능마다 해당 클래스를 직접 호출해야 했다.
→ 그래서 Django의 미들웨어 구조를 활용해middleware.py를 작성하고settings.py에 등록함으로써,
→ 별도 호출 없이도 인증 로직이 자동으로 동작하도록 개선했다.
5. 시스템 아키텍처 및 구성, 설계
| 시스템 아키텍처 |
|---|
|
| JWT 토큰 기반 인증/인가 설계 |
|---|
|
| 시나리오 배경 |
|---|
|
6. 구현된 화면
화면 이미지
| 3.1 사용자 맞춤 기능 |
|---|
|
|
|
| 3.2 판례 검색 및 분석 |
|---|
|
|
7. 느낀 점
솔직히 말하면, 파이널 프로젝트 기간 두 달은 그 전 네 달간 배웠던 시간보다 훨씬 더 힘들었던 것 같다.
기능 하나하나 완성할 때마다 오는 그 짜릿한 성취감은 정말 말로 다 표현할 수 없을 정도였지만, 기획이나 설계 단계에서 미처 고려하지 못했던 부분이 발목을 잡을 때마다 일정이 밀리는 상황은 매번 적응이 안 됐다.
게다가 팀원들마다 잘하는 영역도 다르고 작업 속도도 다르기 때문에, 이런 점들을 고려해서 전체 일정을 설계하는 것도 생각보다 훨씬 더 어려웠다.
그럼에도 불구하고, 지금까지 했던 여러 프로젝트 중에서 이번이 가장 뿌듯했던 건 확실하다.
이번 프로젝트에서는 백엔드 개발뿐만 아니라, 전반적인 기획과 기술 설계까지 직접 리드하면서 큰 그림을 그려가며 프로젝트를 끌고 나갈 수 있었고, 그 경험은 앞으로 취업이나 개인 프로젝트를 하게 될 때 정말 큰 자산이 될 거라 믿는다.
물론 이전에 했던 프로젝트들이 AI 관련은 아니었지만, 이번 파이널에서 그 경험들이 꽤나 많은 도움이 됐다고 느꼈다.
덕분에 팀원들의 역량을 빠르게 파악하고 일정도 효율적으로 조율할 수 있었고, 필요한 부분에 어떤 공부가 들어가야 할지도 자연스럽게 판단할 수 있었다.
그리고 전체를 조망하면서 프로젝트를 진행하는 습관 덕분에, 설령 중간에 빠진 게 있더라도 금방 캐치해서 수정할 수 있었던 점도 이번에 큰 도움이 됐던 것 같다.
이번 경험은 단순히 하나의 결과물만 남긴 게 아니라, 이후 어떤 일을 하더라도 잘 해낼 수 있을 거라는 자신감도 같이 얻은 시간이었다.
8. 수료증 및 상장
 |  |
|---|---|
| 수료증 | 파이널 프로젝트 우수팀 선정 |
