글 목록

블로그
사례와 실험

수정

변호사가 판례 찾는 데 하루 3시간을 쓰는 구조적 문제

법률 업무의 시간 구조 분석: 검색에 소비되는 시간을 분석으로 전환하는 RAG 접근법

이국환SION.LAB 대표예상 읽기 시간 10분


문서 검색에서 근거 있는 답까지본문에서 설명한 흐름을 먼저 확인합니다.. 문서 인덱싱: 판례를 나눠 벡터로 저장합니다. 의미 검색: 질문과 뜻이 가까운 판례 상위 몇 건을 찾습니다. 답변 생성: 찾은 판례를 근거로 답을 정리합니다. 원문 대조: 제시된 판례를 원문과 대조해 판단합니다. AI 답변과 법률 전문가의 판단을 구분합니다.전체 흐름문서 검색에서 근거 있는 답까지본문에서 설명한 흐름을 먼저 확인합니다.01문서 인덱싱판례를 나눠 벡터로 저장합니다02의미 검색질문과 뜻이 가까운 판례 상위 몇 건을찾습니다03답변 생성찾은 판례를 근거로 답을 정리합니다04원문 대조제시된 판례를 원문과 대조해 판단합니다AI 답변과 법률 전문가의 판단을구분합니다.
전체 흐름. AI 답변과 법률 전문가의 판단을 구분합니다.

기획의 시작: 검색이 분석보다 3배 오래 걸린다

법률 업무 자동화를 기획하면서 여러 변호사에게 물었습니다. "하루 중 가장 시간이 많이 걸리는 업무가 뭔가요?" 예상과 달리, 답은 "분석"이 아니라 **"검색"**이었습니다.

"판례를 '찾는' 시간이 '분석하는' 시간보다 3배 더 깁니다."

판례 바인더가 높이 쌓인 책상과 돋보기, 탁상시계

실무를 따라가보니 이유가 명확했습니다. 키워드 기반 검색 시스템에서 정확한 법률 용어를 알아야 검색이 되고, 결과가 수백 건이 나오면 하나씩 열어서 관련성을 판단해야 했습니다. 이 문제가 법률 업무 전반의 구조적 비효율이라고 판단하고, AI 기반 판례 검색 시스템을 직접 기획했습니다.

왜 RAG인가

판례 검색을 개선하는 접근법은 여러 가지입니다. 풀텍스트 검색 고도화, 파인튜닝된 분류 모델, 그리고 RAG(Retrieval-Augmented Generation).

풀텍스트 검색은 결과 수를 줄여주지만, 여전히 키워드 일치에 의존합니다. "보증금 반환 거부"와 "임차보증금 미지급"을 같은 맥락으로 인식하지 못합니다.

파인튜닝 모델은 정확도가 높지만, 새로운 판례가 추가될 때마다 재학습이 필요합니다. 법률 도메인은 판례가 지속적으로 쌓이기 때문에 유지보수 부담이 큽니다.

RAG는 기존 판례를 벡터로 저장하고, 검색 시 의미적 유사성으로 찾습니다. 새 판례는 벡터 DB에 추가만 하면 됩니다. 재학습이 필요 없고, 키워드가 달라도 의미가 유사하면 검색됩니다.

전통적 검색과 RAG 검색의 흐름 비교

전통적 키워드 검색

전통적 검색과 RAG 검색의 흐름 비교주체별 요청·응답과 순서를 확인합니다.. 참여: 변호사, 판례 DB. 순서: 1. 변호사 → 판례 DB: 키워드 입력; 2. 판례 DB → 변호사: 387건 반환 (점선); 3. 변호사 → 변호사: 제목 훑기·선별; 4. 변호사 → 판례 DB: 판례 열기; 5. 판례 DB → 변호사: 전문 20페이지 (점선); 6. 변호사 → 변호사: 읽고 메모; 7. 메모(변호사, 판례 DB): 5건 찾는 데 2~3시간; 8. 메모(변호사): 검색 시간 > 분석 시간. 각 주체 사이에 오가는 요청·응답과 메모를 순서대로 읽습니다.요청과 응답 순서전통적 검색과 RAG 검색의 흐름비교주체별 요청·응답과 순서를 확인합니다.변호사판례 DB01변호사판례 DB키워드 입력02판례 DB변호사387건 반환03변호사변호사제목 훑기·선별04변호사판례 DB판례 열기05판례 DB변호사전문 20페이지06변호사변호사읽고 메모07메모 · 변호사, 판례 DB5건 찾는 데 2~3시간08메모 · 변호사검색 시간 > 분석 시간각 주체 사이에 오가는 요청·응답과 메모를순서대로 읽습니다.
도식: 전통적 검색과 RAG 검색의 흐름 비교

RAG 기반 의미 검색

전통적 검색과 RAG 검색의 흐름 비교주체별 요청·응답과 순서를 확인합니다.. 참여: 변호사, RAG 시스템, 벡터 DB. 순서: 1. 변호사 → RAG 시스템: 질문 입력; 2. 메모(RAG 시스템, 벡터 DB): 의미 기반 검색; 3. RAG 시스템 → RAG 시스템: 질문 임베딩; 4. RAG 시스템 → 벡터 DB: 유사 판례 검색; 5. 벡터 DB → RAG 시스템: 상위 5건 + 관련 구절 (점선); 6. RAG 시스템 → 변호사: 판시 요지 + 근거 제시 (점선); 7. 메모(변호사, RAG 시스템): 30초 이내. 각 주체 사이에 오가는 요청·응답과 메모를 순서대로 읽습니다.요청과 응답 순서전통적 검색과 RAG 검색의 흐름비교주체별 요청·응답과 순서를 확인합니다.변호사RAG 시스템벡터 DB01변호사RAG 시스템질문 입력02메모 · RAG 시스템, 벡터 DB의미 기반 검색03RAG 시스템RAG 시스템질문 임베딩04RAG 시스템벡터 DB유사 판례 검색05벡터 DBRAG 시스템상위 5건 + 관련 구절06RAG 시스템변호사판시 요지 + 근거 제시07메모 · 변호사, RAG 시스템30초 이내각 주체 사이에 오가는 요청·응답과 메모를순서대로 읽습니다.
도식: 전통적 검색과 RAG 검색의 흐름 비교

RAG 파이프라인의 핵심 구조

# 판례 문서 인덱싱 (사전 처리)
def index_legal_documents(documents):
    for doc in documents:
        chunks = split_by_paragraph(doc.text, max_tokens=512)
        for chunk in chunks:
            embedding = embed_model.encode(chunk)
            vector_db.insert(
                text=chunk,
                vector=embedding,
                metadata={"case_id": doc.id, "date": doc.date}
            )
 
# 검색 시점 — 변호사의 질문 처리
def search_relevant_cases(query: str, top_k: int = 5):
    query_vector = embed_model.encode(query)
    results = vector_db.similarity_search(query_vector, top_k=top_k)
 
    context = "\n\n".join([r.text for r in results])
    prompt = f"""다음 판례를 참고하여 질문에 답변하세요.
 
판례:
{context}
 
질문: {query}
"""
    return llm.generate(prompt), results
항목키워드 검색RAG 기반 의미 검색
검색 방식단어 일치맥락·의미 유사도
결과 수수백~수천 건상위 5~10건 (관련도순)
검토 시간건당 5~10분 × 수십 건근거 제시로 즉시 판단
유사 판례 발견검색어에 따라 누락 가능의미 기반으로 포괄
신뢰도 검증전적으로 사람 의존AI 근거 + 사람 확인

AI 기반 법률 검색 도입 시 주의할 점

  • 출처 검증 필수: AI가 제시한 판례는 반드시 원문과 대조해야 합니다. 모델은 가끔 존재하지 않는 판례를 그럴듯하게 생성합니다.
  • 최신 판례 업데이트 주기: 벡터 DB는 정기적으로 갱신되어야 합니다. 인덱싱 날짜 이후의 판례는 검색되지 않습니다.
  • 전문 용어 임베딩 품질: 일반 임베딩 모델은 법률 용어 간 미묘한 차이를 충분히 반영하지 못할 수 있습니다.
  • AI는 보조 도구: 검색 결과를 법률적 판단의 출발점으로 활용해야 합니다.

도입을 검토할 시점

  • 판례 검색에 하루 2시간 이상을 소비하고 있다
  • 키워드를 바꿔가며 여러 번 검색해야 원하는 판례를 찾는다
  • 유사 판례를 놓쳐서 상대측에 먼저 인용당한 경험이 있다
  • 신입 변호사의 검색 효율이 시니어 대비 현저히 떨어진다

검색 시간을 줄이는 것이 목표가 아닙니다. 확보된 시간을 분석에 쓰는 것이 목표입니다. 그 전환이 가능해야 AI 도입의 의미가 있습니다.

#법률#AI검색#RAG#리걸테크
문의하기