Claude Code 사용기(1): 판례번호 추출기 개발 — 생성형 LLM의 시대에도 여전히 유념해야할 것

  Claude Code의 가장 강력한 점은, 이제 기초적인 프로그래밍 지식이 없어도 자신이 필요로 하는 애플리케이션의 코드를 짤 수 있다는 것이다. 물론, 그 코드가 항상 내 의도대로 돌아가는 코드라는 건 장담할 수 없다.
  코딩 공부를 시작한 건 개발자 열풍 불기 이전인 2013년, 3차 산업혁명에 대한 믿음 때문이었다. '닷컴버블'이 환기해주듯, 정보통신기술은 2010년대에만 하여도 '신사업'이고 직장생활의 모습이나 우리 일상만 조금 바꿨을 뿐, 인류가 누리는 부의 증가와는  연관관계가 보이지 않았다. 하지만 bit로 저장한 정보가 축적되고, 그 정보가 저장되고 정보를 처리하는 반도체 기술의 발달로 컴퓨팅 퍼포먼스 향상, 전력소비와 면적 감소로 생산성 향상이 예상되고 있었다. 내게는 초등학교 때 배우던 우리 시대의 엑셀 같은 것이었다. 개발자의 길을 걷는 친구들도 python이 인기를 끌기 시작하자, 나와 같은 머글들에게도 python 배워두면 두고두고 도움이 될 거라 했다.
  컴퓨터 검정능력 시험 공부하다 실제로 일하는 데 코드를 써본 건 취업 준비 중 아르바이트를 했던 어느 그룹의 HR 센터에서였다. 리서치 직무였는데, 실제로 주어진 일은 자료를 정리해서 웹에 정해진 포맷으로 올리는 작업이었다. DB 파일을 만들어서 한 번에 업로드하면 됐으면 좋겠다고 했지만, 웹 관리 부서에서는 하나씩 손으로 올려야 한다고 했다. 그래서 Python으로 매크로 코드를 짜서 컴퓨터에게 일을 시켜두고 제대로 하는지 감독했다. 퇴사하면서 사용법을 남겼지만 내가 하던 지루한 작업에만 맞춰진 코드라, 잘 활용됐을지는 모르겠다.
  로스쿨에 들어가서도 코딩이 필요한 순간이 있었다. 최신 판례 자료나 교재 업데이트 과정에서, 판례색인이 있는 교재라면 그걸 보고 찾을 수 있겠지만 그 과정이 너무 귀찮았다. 판례색인이 없는 자료면 더 성가셨다. 그래서 정규식으로 코드를 짰다. 특히나, 형사재판실무, 민사재판실무 과목에서 새로 언급된 판례를 정리하거나, 최신 판례 자료들을 서로 비교할 때 내가 짠 코드는 나름 유용했다.

 

 

python

CASE_NUMBER_PATTERN = re.compile(r'\d{2}(?:\d{2})?[가-힣]{1,2}\d{1,10}')

  깔끔하다. 논리적이다. 판례번호는 연도 + 한글 유형코드 + 일련번호 구조니까, 정규식 하나면 충분할 것 같았다. 실제 자료에 돌려봐도, 가끔 조문이나 날짜 등이 섞여 나오곤 했지만, 예외 설정해주고 할만큼 여유가 있진 않았고, 혼자 쓰는 거니 적당히 제거하면서 볼 수 있었다.
 

생애 첫 배포 도전

  졸업하고 여유가 생긴 지금, 후배들에게도 공유할 겸 이 판례번호 추출기를 배포해보기로 마음먹었다. 회사에 다닐 때도 결과 레포트를 요약하고 비교하는 기능이 필요해 UNIX Shell에서 작동하는 간단한 Python 프로그램을 짜서 공유한 경험이 있다. 그때는 Python 2.x가 기본으로 깔려 있는 환경이라 'python [내 코드의 디렉토리]'와 사용 설명서만 공유해도 가능한 일이었다.
  Python은 직관적이고 쉽다고 하지만, 컴퓨터에 Python 설치가 싫은 사람도 있고, CLI 창에서 뭘 조작하는 게 익숙하지 않은 사람도 있다. 패키지까지 쓰는 코드라면 Python까진 설치해도, 보안 설정부터 머리가 아파지면서 결국 Python도 삭제하게 된다. 내가 짠 기존 코드는 TXT 문서의 텍스트만 읽는 방식이라 혼자 쓸 때는 더 개선할 필요를 못 느꼈지만, 배포까지 하기로 한 이상 사용성에 신경을 쓰기로 했다. 목표는 TXT뿐 아니라 HWP, DOCX, PDF, PPTX, XLSX도 직접 읽어서 판례번호를 추출하고, 기존에 갖고 있던 판례 목록과 비교도 할 수 있는 웹 서비스였다.
  가장 먼저해야할 건, 내가 적당히 제거하면서 봤던 예외들이었다. 수공예로 선물을 주더라도, 정성도 좋지만 완성도도 어느정도 있어야하는 것 아닌가? Claude에게 인터넷에서 임의의 법률문서들을 찾아 예외들을 잡아달라고 이야기했다. Claude가 찾은 것은 전화번호도 판례로 인식하는 것이었다.
  Claude가 잡아준 예외도 있었지만, LLM의 원리는 그럴듯한 문장을 확률 기반으로 추론하여 써주는 데에 있다. 그렇기에 Claude만 믿고 있을 수는 없다. 내가 주로 사용했던 자료들 말고, 갖고 있던 다른 자료들로 테스트한 결과,  제50조의2, 2023년3월, 10월15일 같은 날짜와 조문 표기도 전부 판례번호처럼 인식됐다. 

python

_LAW_TERMS = '조제항호목절관편장의년월일'
CASE_NUMBER_PATTERN = re.compile(
    r'(?<!\d)\d{2}(?:\d{2})?(?![' + _LAW_TERMS + r'])[가-힣]{1,2}\d{1,10}'
)
```

  그 다음에는 PDF 파일을 넣어보니, 잡혀야하는 판례번호가 잡히지 않는 경우가 생겼다. PDF로 랜더링 되는 과정에서 텍스트가 잘리는 경우다. 법원 판결문이나 논문을 넣어보면
"선고 2023가
합12345 판결"
과 같이 끊겨서 판례번호가 아예 나오지 않는 결과가 있었다.
  이 문제도 해결한 후에는 오히려 또 버그가 터졌다. 전부 붙여버리면 아래와 같은 문제가 발생한다.
" 2023가합12345 2022나67890 → 2023가합123452022나67890 "
  배운 게 있다면, Claude는 띄어쓰기 잘못해서 에러를 내는 법은 없지만, 내 의도와는 전혀 다른 잘 돌아가는 코드를 짜기도 한다. 인간과 마찬가지로 Claude에게 아직은 텔레파시 능력을 기대하기 어려운 것 같다.

첫 배포는 별 일이 아니었다

  Claude Code에 Vercel 계정을 연결해서 배포를 시도했다. GitHub에 push 정도는 해봤지만, 호스팅해서 웹 서비스로 배포해본 건 처음이었다. 요즘 Vercel 많이 쓰고 Claude Code에서 지원도 하길래 바로 가입하고 연동하고, 정말 충격적으로 "딸깍"으로 끝냈다. 클라이언트가 4MB까지만 업로드 가능한 단점이 있었지만, DOCX나 PPTX, PDF는 브라우저에서 텍스트를 직접 읽게 해서 용량 제한을 피할 수 있었다.  친구들에게 공유하기 전에 먼저, 읽기전용이나 암호화된 HWP 파일을 넣어봤다. 지정된 에러메시지가 아닌 전혀 다른 메시지가 떴다. 이 부분도 수정해달라고 요청하니, Claude는 이제 정상적인 HWP 파일까지 막고 읽기전용이라고 우기는 코드를 짜버렸다. HWP 파일에 관한 지식이 전무하다보니, 계획 짠 걸 보고도 그대로 속아넘어간 것이다. 유튜브를 보면 "딸깍"으로 다 끝난다고들 하지만, 도메인 지식이나 개발자 세계에서 훈련받으며 직관적으로 따르는 관습은, 언젠가 극복되겠지만 일반인이 자연스레 검증하기는 어려울 것 같다.
  마지막으로 당한 것은 배포 후에 친구가 남겨준 "컴퓨터에서 작성하고 PDF로 랜더링한 파일에서 의도한대로 작동이 안 된다"는 피드백이었는데, 나는 이미 word 파일로 PDF로 내보낸 파일을 검증한 단계여서 이해가 되지 않았다. 파일을 달라고 하여 받아보니, HANCOM PDF로 인쇄해서 만든 pdf 파일이었다. 텍스트가 있긴 한데,
2 0 2 3 가 합 1 2 3 4 5
처럼 글자마다 공백이 삽입되어 있어서 추출이 안 됐던 것이다. 원인을 파악한 후 수정을 지시해서 해결했다.
 
https://list-extractor.vercel.app/

판례번호 추출기 | List Extractor

 

그래서 이게 경제적인가?

  아마 이 프로젝트를 공부하면서 손으로만 짰다면, 완성에 3~4일은 족히 걸렸을 것 같다. Claude의 도움으로 한 나절에 끝낼 수 있었다. 다만, 친구들로부터 몇 가지 피드백을 받았다.
  먼저, "이거 그런데 언제 써?" 나는 사실 많이 썼지만, 대부분의 친구들은 신기하게 볼 뿐 필요성을 크게 느끼지 못했다. 아무리 우수한 기술도 니즈가 없으면 상품으로서 가치는 없다. 배포까지 할 거라면 니즈를 먼저 확인해봐야 한다는 교훈을 얻었다. 개인용으로 만드는 건 경제성이 충분하다고 생각하지만, 내가 만든 건 상품이 아니라 어쩌면 개인화된 생산성 툴이다. "모두가 코드를 짤 줄 알아야 하는 시대가 온다"는 이렇게 성큼 다가와버렸다.
  그리고 "제미나이도 diff 기능은 할 수 있어." 맞는 말이다. AI 에이전트를 비서 부리듯 쓸 수 있는 시대 아닌가. 다만, 다른 프로젝트를 하면서 API를 쓰면서 토큰을 탈탈 털려본 입장에서, 매번 LLM에 시키는 건 비경제적이라고 생각한다. AI는 꽤 고급자원이다. 그냥 떠있는 창이 아니고, 클라우드 컴퓨팅 방식으로 방대한 데이터를 처리하기 때문에, 데이터센터 건설부터 전기 사용까지 굉장히 비싸다. 그래서 AI를 잘 쓴다는 개념은, 단지 원하는 결과를 가져올 수 있는 프롬프트를 잘 짜는 게 아니고, 적은 토큰을 써서 빠른 시간 내에 의도된 결과물을 완성시킬 수 있다는 의미가 될 것 같다. 항상 새로운 창조적인 일을 할 수 있다면 좋겠지만, 내가 하는 일의 본질과는 상관 없는 루틴성 잡일을 하는 시간은 줄여주는 게 생산성 툴의 핵심 중 하나라고 생각한다.
  가용 자원이 한정되어 있는 환경에서, 효율성과 생산성은 좀 다른 의미를 갖는다. 어떤 작업을 도구로 만들어 자동화할 것인가? 어느 단계에 LLM을 쓰고, 또 어느 단계는 내가 직접할 것인가? 이 질문들이 생산성 향상을 고민하는 사람이라면 피할 수 없는 질문인 것 같다. 배포한 첫 서비스는 비생산적이었다.