법원에서 등기가 왔습니다 - 문과생 변호사의 AI 분투기

1. 프롤로그: "경휘님, AI로 툴 하나 만들어보시죠?"

코빗에 사내변호사로 입사하고 두 달째 되던 날이었습니다. 대표님이 쓱 오시더니 대뜸 미션을 던지셨습니다.

"AI를 활용해서 법원 회신 프로세스를 획기적으로 개선할 방안을 직접 만들어보세요."

컴퓨터 지식이라곤 대학 교양수업으로 HTML/CSS 몇 줄 찍어먹어 본 게 전부인 순수 문과생인데... 어디서부터 손을 대야 할지 머릿속이 하얘졌습니다. 일단 요즘 직장인들의 필수 AI 툴이 된 Claude Code를 켰습니다.

깜빡이는 커서 앞에서 뭐부터 해야 하는지 막막했습니다. 처음 며칠은 "이거 한국어로 물어봐도 알아듣나?" 같은 초보적인 의문부터 시작해서, "법원 회신 프로세스를 개선하는 보조 툴을 만들고 싶은데 뭐부터 해야 해?" 같은 막연한 질문을 이것저것 던졌습니다. MCP(Model Context Protocol)라는 생소한 규격을 연결하는 것부터 난관이었습니다. 그래도 안 되는 원인을 붙잡고 헤매다 보니 여러 시행착오 끝에 어느새 하나둘씩 기초 세팅이 갖춰졌습니다.

그 뒤로는 Claude Code와 씨름하며 파일 생성과 디버깅을 반복했습니다. 동시에 매일 이 까다로운 반복 업무를 수동 처리하시던 동료 지윤님 옆에 붙어 업무 툴과 프로세스를 꼬치꼬치 여쭤봤습니다. AI와 실무자 사이를 오가는 동안, 베일에 싸여있던 법원 회신 프로세스가 조금씩 선명해지기 시작했습니다. 시스템의 도움을 받아 규칙대로 쿼리를 던지면 되는 구간과 민감 정보라 사람 손을 꼭 타야 하는 구간을 한 단계씩 추렸습니다.

2. 시작하자마자 마주한 벽: 법원 서류와 컴플라이언스 리스크

가상자산 거래소에는 회원 한 명의 거래내역 또는 잔고내역 전체를 정해진 법원 양식에 맞춰 정리해 회신해야 하는 업무가 있습니다. 주로 법원에서 날아오는 요청은 크게 네 가지입니다.

• 압류명령 — "이 사람 자산 묶어두세요."
• 제3채무자 진술서 — 압류한 뒤, "그래서 묶어둔 자산이 정확히 얼마인지 진술하세요."라는 후속 요구
• 사실조회 — "이 사람이 귀사 회원이 맞는지, 거래 내역이 있는지 확인해 주세요."
• 문서제출명령 등 자료제출 요구 — "이 사람 거래내역 전부(또는 일부) 뽑아서 보내세요."

이름은 거창하고 제각각이지만, 본질은 결국 이 한 줄로 요약됩니다.

"이 회원의 거래소 활동 내역을 정리해서 돌려보내달라."

간단해 보이지만, 회신 한 건을 완성하려면 송달 정리, 조회 대상 매칭, 시트 검토, 자료 정리, 회신서 작성, 최종 제출까지 손이 제법 많이 가는 작업입니다.

그래서 미션을 받고 처음 머릿속에 그렸던 그림은 법원 서류를 AI가 통째로 읽은 다음 접수 내역을 공유 스프레드시트에 정리하고 최종 회신서까지 한 번에 뽑아내는 전 과정(End-to-End) 통합 자동화였습니다. 서류를 인식해 또 다른 문서를 자동으로 생성하는 작업은 기술적으로 그리 어렵지 않아 보였기에, 금방 구현할 수 있을 줄 알았습니다.

하지만 본격적인 설계에 들어가자마자 간과할 수 없는 컴플라이언스 이슈에 부딪혔습니다. 법원 송달 서류 원본에는 실명, 주민등록번호, 주소 등 민감한 개인식별정보가 그대로 담겨 있습니다. 이를 Claude 같은 외부 AI에 업로드하면 '당사자 동의 없는 개인정보 제3자 제공'이나 '국외 이전'이라는 중대한 법적 리스크가 발생할 위험이 있었습니다. 이 때문에 초기 구상대로 진행할 수는 없었고, 그렇다고 개발 지식이 부족한 제가 당장 외부망이 차단된 독립적인 로컬 OCR 서버를 뚝딱 구축하는 것도 현실적으로 어려웠습니다.

그래서 우선 리스크 통제가 까다로운 앞단의 '문서 입력 단계'는 과감히 뒤로 미루고, 개인정보 이슈 없이도 실무자의 시간을 가장 많이 뺏는 작업 구간부터 해결하기로 방향을 틀었습니다. 바로 가명처리된 내부 식별자(user_id)를 기반으로, 필요한 거래내역과 잔고내역만 법원 양식에 맞춰 안전하게 추출하고 정리하는 단계였습니다. 그리고 서류 속 실명, 주민등록번호로 회원을 특정해 내부 user_id를 찾아내는 '조회 대상 매칭'은 사람이 사내 시스템에서 직접 수행합니다. 즉, 개인식별정보는 이 도구를 거치지 않고, 도구에는 user_id만 건네집니다.

3. 진짜 문제는 '대기 시간': 기존 Tableau 대시보드의 비효율

우선순위를 위와 같이 정하긴 했지만, 이 추출 단계 역시 원래는 따로 시스템화되어 있지 않았습니다. 사내 분석용 Tableau 대시보드에 접속해 user_id로 필터를 걸고, 거래내역 종류별로 쪼개진 여러 개의 화면을 차례로 열어 한 장씩 엑셀로 내려받는 것이 기존의 방식이었습니다.

데이터를 다각도로 탐색하고 시각화하는 도구로서 Tableau는 분명 훌륭합니다. 하지만 법원에서 온 요청 내용에 따라 여러 갈래의 내역 중 필요한 항목을 골라 조합하고, 이를 다시 정해진 고정 양식에 맞춰 추출해야 하는 소모적이고 번거로운 작업에는 너무 무거웠습니다. 케이스마다 조회해야 하는 데이터의 조합이 조금씩 달라지다 보니, 매번 대시보드 화면을 새로 전환하고 필터를 다시 적용할 때마다 데이터베이스에서는 무거운 쿼리가 새로 돌았습니다. 화면이 바뀔 때마다 모니터의 모래시계는 멈출 줄 몰랐고, 다운로드 버튼을 수차례 누르며 시스템의 응답을 마냥 기다려야 했습니다.

회신 한 건당 길어야 15분 안팎의 시간이었지만, 요청서에 맞춰 화면을 이리저리 오가며 로딩을 견뎌내는 무의미한 대기 시간과 손수 부품을 조립하는 듯한 가공 과정은 실무자를 참 지치게 만들었습니다. 정작 집중해야 할 서류 검토와 판단을 하기도 전에, 단순 클릭 노가다가 주는 피로감이 업무 에너지를 불필요하게 소모하게 만들었던 셈입니다.

그래서 만든 프로그램은 이러한 비효율을 걷어내기 위해, 다양한 법원 요청 서류들이 공통으로 요구하는 핵심 데이터의 '최대공약수'를 뽑아내어 한 번에 정리하는 것에만 초점을 맞춘 전용 도구입니다. Tableau가 가진 화려한 탐색 기능을 과감히 포기하는 대신, 자주 인용되는 핵심 내역들을 한 번의 실행으로 깔끔한 PDF 한 권에 알아서 모아주는 직관적인 '문서화 기능'만 떼어내어 가볍게 구현했습니다. 만약 케이스별 요구사항에 따라 아주 미세하게 추가되는 특이 정보가 있다면, 프로그램이 뽑아준 핵심 PDF를 바탕으로 실무자가 해당 부분만 수동으로 살을 붙여 운영하는 방식을 택했습니다. 이렇게 탄생한 시스템의 핵심 구조는 생각보다 심플합니다.

4. 해결의 실마리: 핵심 데이터의 '최대공약수' 추출하기

마우스 클릭과 대기 시간을 걷어내기 위해 새롭게 정비한 추출 프로세스의 직관적인 데이터 흐름은 다음과 같습니다.

   [ 입력 ]  user_id (한 개 이상) + 조회 기간
      │
      ▼
   [ 추출 ]  개인 식별 정보가 사전 제거된 분석용 데이터웨어하우스(DW)에
            핵심 쿼리를 던져 필요한 내역을 수집
      │
      ▼
   [ 정리 ]  수집한 결과를 법원 회신 양식에 맞춰 PDF 1개로 병합
      │
      ▼
   [ 전달 ]  회신서 작성 단계로

이 시스템은 사내망 안의 분석용 데이터웨어하우스에서 개인 식별 정보가 사전 제거된 DB만 조회하도록 설계되었습니다. 앞서 말했듯 실명 기반의 회원 특정은 사람이 이미 끝낸 뒤이므로, 도구에 들어오는 값은 이름이나 생년월일이 포함되지 않은 사내 내부 식별자 user_id(단건 또는 다수)와 조회 기간뿐입니다. 이 값을 입력하면 시스템은 분석용 DW를 대상으로 법원 회신에 꼭 필요한 핵심 쿼리들을 차례대로 실행하여 데이터를 수집합니다. 모든 케이스를 100% 자동화하려는 욕심 대신, 어떤 요청이 오든 반드시 포함되는 데이터의 최대공약수를 안전하고 빠르게 뽑아내는 데 집중한 것입니다. 수집하는 대표적인 데이터 유형은 다음과 같습니다.

결과물은 법원 회신 양식에 맞춰 가독성을 극대화한 딱 1개의 핵심 PDF 파일로 출력되며, 당연히 이름이나 생년월일 같은 개인 식별 정보는 완벽히 제외됩니다. 특징을 짧게 정리하면 이렇습니다.

• 입력 — 이름·생년월일이 포함되지 않은 사내 내부 식별자인 user_id (단건 또는 다수) + 조회 기간(시작일·종료일 또는 잔고 기준일)
• 출력 — 법원 회신 양식에 맞춰 가독성을 다듬은 PDF 딱 1개. 이름·생년월일 등 개인 식별 정보는 포함되지 않음.
• 처리 위치 — 사내망 안의 분석용 데이터웨어하우스. 개인 식별 정보가 사전 제거된 DB만 조회.
• 사람 개입 지점 — ① 회원 특정(실명 → user_id 매칭), ② 시스템 실행 전 입력값 검토, ③ 실행 후 PDF 검수 및 케이스별 추가 항목 수동 보완

작아 보이지만 이 파이프라인 덕분에 사람 손을 타며 매번 15분씩 걸리던 소모적인 반복 작업이 수십 초로 줄어들었고, 실무를 짓누르던 불필요한 번거로움과 에너지 소모를 크게 절감할 수 있게 되었습니다.

5. 여기서 잠깐: 개발 비하인드 Q&A

Q1. AI한테 코드를 짜달라고 하면 사내 데이터가 유출되는 거 아닌가요?

시작부터 Claude에게 엄격한 사내 보안 규정과 법적 리스크를 얘기하면서 "외부로 데이터가 새어나가면 절대 안 되니, 내 컴퓨터 안에서만 폐쇄적으로 구동되는 Python 프로그램을 짜 달라"는 가이드라인을 주었고, Claude가 이를 바탕으로 코드를 짜 주었습니다. 즉 개발 과정에서 Claude가 받아 본 것은 저의 요구사항과 코드였을 뿐, 실제 회원 데이터가 아닙니다. 그렇게 완성된 프로그램은 실행될 때 실제 데이터를 외부 AI 모델로 단 한 줄도 흘려보내지 않고, 오롯이 제 컴퓨터 안에서만 돌아갑니다.

Q2. 실제 업무에 적용할 때 예기치 못한 변수는 없었나요?

실무 환경에 숨어 있는 미묘한 예외 케이스들은 코딩 과정에서 마주한 가장 예상치 못한 난관이었습니다. 대표적으로 'ID의 다중성' 문제가 있었습니다. 법원 서류는 '사람(개인)' 기준이지만 사내 시스템은 '계정' 기준이다 보니, 한 사람이 휴면 계정과 활성 계정을 모두 보유해 user_id가 두 개인 경우가 존재했습니다. 이 케이스까지 무리하게 자동화하려다 로직이 꼬여버려서, 부득이하게 예외적인 ID 분리는 실무자가 직접 확인하고 처리하는 것으로 타협했습니다. 그리고 사건마다 (특히 이혼사건) 요구하는 기간이 제각각인 점도 고민이었는데, 기본값으로 가입일부터 조회 전일까지의 전체 내역을 뽑아주되, 필요한 경우 실무자가 날짜를 수동으로 조정해서 언제든 다시 추출할 수 있는 기능을 만들어 두었습니다.

Q3. 그렇다면 최종 PDF 결과물은 만족스러웠나요?

여러 줄로 복잡하게 쪼개져 있던 날것의 데이터들을 법원에서도 한눈에 보기 좋게 날짜순으로 정렬하고 깔끔하게 그리드를 잡았습니다. 특히 서면에 담길 틀을 짜고, 회사 로고를 원하는 위치에 딱 배치하고, 폰트와 색상 디자인 그리고 여백까지 제 의도대로 커스텀하여 어엿한 공식 문서 형태로 만들어낼 수 있었습니다. 단순히 고정된 템플릿을 채우는 것에 그치지 않고 담길 내용을 자유롭게 구성할 수 있는 것은 물론, 향후 디자인의 변경이 필요하더라도 개발팀 손을 빌리지 않고 저 스스로 양식까지 언제든 직접 수정할 수 있다는 것이 너무 편리하게 느껴졌습니다.

6. 남겨진 과제: 로컬 OCR을 구축할 수 있을까

이렇게 가장 번거로웠던 데이터 추출 구간을 효율화하고 나니, 그 다음엔 자연스럽게 처음에 꿈꿨던 전 과정(End-to-End) 통합 자동화의 남은 퍼즐 조각들에 다시 눈길이 갔습니다. 법원에서 온 서류를 AI가 통째로 읽어 접수 내역을 공유 스프레드시트에 정리하는 앞단의 작업까지 매끄럽게 이어져야 비로소 진정한 자동화 파이프라인이 완성되기 때문입니다.

결국 컴플라이언스 리스크 때문에 과감히 뒤로 미뤄두었던 첫 단추를 다시 채워야 할 차례가 온 셈입니다. 외부 OCR을 사용할 때 발생하는 개인정보 제3자 제공 등의 법적 리스크를 원천 차단하려면, 해결책은 오직 제 로컬 컴퓨터에서 폐쇄적으로 구동되는 로컬 OCR 환경을 구축하는 것뿐이었습니다.

다행히 개발팀과 보안팀 동료들의 조언 덕분에 PaddleOCR이라는 오픈소스 OCR의 존재를 알게 되었고, 이를 설치해 PDF를 읽어오는 기능을 앞단에 붙여보는 중입니다. 꽤 좋은 평가를 받는 오픈소스 OCR답게 법원 서류 특유의 빽빽하고 정형화된 레이아웃을 생각보다 잘 읽어내려가는 것 같습니다. 하지만 종종 엉뚱한 글자를 전혀 다른 위치에서 인식해 버리는 오류가 자잘하게 계속 발생해서 여전히 헤매고 있습니다. 이 인식률의 벽을 어떻게 넘어야 할지 비개발자로서 참 난감하지만... AI 동료와 휴먼 동료분들께 열심히 자문을 구하며 대안을 찾아가보려 합니다.

7. 에필로그: 비개발자도 직접 문제를 해결하는 시대

현업 개발자분들이 보시기에는 여기까지의 내용이 너무나 간단하고 소박한 작업일지 모릅니다. 하지만 기획팀과 개발팀의 리소스를 사용한 거창한 시스템 도입을 마냥 기다리지 않고, 법무팀 내부에서 우리가 가장 잘 아는 업무 프로세스 상의 페인 포인트(pain point)를 정확히 해결하는 도구를 직접 뚝딱뚝딱 만들어 써본 것은 무엇보다 값진 경험이었습니다.

기획서 한 장 써본 적 없던 제가 문제 정의부터 코드 구현까지 온전히 해내며, AI를 활용해 실무 환경에서 얼마나 큰 효율을 만들어낼 수 있는지 깊이 체감할 수 있었습니다. 물론 그 과정이 만만치만은 않았습니다. 의도대로 고쳐지지 않는 코드를 붙잡고 씨름하며 전체적인 아키텍처를 조망하고 수정하는 일이 생각보다 얼마나 정교한 작업인지 알게 되었고, 사내 보안 체계의 중요성과 그 엄격한 울타리 안에서 AI를 활용해 코드를 짜는 것의 까다로움도 뼈저리게 배웠습니다.

하지만 그 모든 고생을 뒤로하고, "어라, 이게 진짜로 되네?"를 온몸으로 느낀 그 순간만큼은 개인적으로 가장 짜릿하고 유의미한 경험이었습니다. 단언컨대 입사 3개월(!) 동안 가장 재미있는 프로젝트였습니다. 앞으로도 분발해보겠습니다. 감사합니다!