hyunkim.lawyer
오답은 있지만 정답은 없다. 언제나 더 나은 답이 있다.

오픈소스 도구를 이용한 법률문서 코딩과 문서작성 자동화

2018년 7월 18일 작성


변호사는 자고로 능력이 있어야 하고, 기술을 잘 활용할 수 있어야 한다 (지난번 글 참고). 변호사는 많은 경우 시간당 보수를 청구한다. 그렇다면 기술을 잘 몰라서 과다청구하게 되면 비윤리적인가? 그렇다. 위 글에서도 말한 것처럼 변호사가 코더가 아닌 이상 기술 발전을 아주 잘 알 필요는 없지만, 합리적인 수준에서 기술을 잘 활용할 수 있어야 한다. 옛날에는 부하변호사에게 시켰던 일들—예를 들어, 문서 자동화(document automation 또는 document assembly)을 거의 직접 한다. 기술 발전의 혜택이다. 요즘 (미국) 법조계에서 화두이기도 하다.

이를 위한 솔루션도 많다. 어떤 블로그 글에서는 직접 하는 것이 가장 좋다고 한다.

이상적으로는 변호사들이 직접 문서를 자동화하는 것이 좋다. 가장 효과적인 시스템은 변호사들이 마이크로소프트 워드를 이용하여 자기 양식을 직접 자동화함으로써 IT 전문가를 활용하여 법률문서 템플릿을 자동화할 필요를 없애는 것이다. 이렇게 하면, 업무를 주제에 대하여 전문성이 없는 사람에게 시킬 때 어쩔 수 없이 발생하는 리스크를 없앨 수 있고 템플릿 유지를 쉽게 한다. 변호사가 자기의 문서 템플릿을 자동화뿐 아니라 유지를 할 수 있게 하는 문서 자동화 소프트웨어를 사용하는 것만이 편지병합 이상의 무엇을 추구하는 프로젝트에는 유일하게 지속가능한 솔루션이다. — What is document automation?에서; 번역은 내가

나는 그냥 직접 한다. 소프트웨어는 변한다. 유행도 변한다. 그리고 내가 마이크로소프트 워드를 잘 사용하지 않는 이유를 여러차례 이야기했지만, 사실 가장 큰 이유는 문서를 텍스트로 저장해야만 문서자동화뿐 아니라 계약관리와 버전관리에 유용하기 때문이다. 이 과정을 궁금해 하는 고객들도 꽤 있었고, 고객 또는 경우에 따라 다른 변호사와 협업할 때도 유용할 것 같고, 나도 내 나름 정리해 두면 좋을 것 같아 정리해 둔다. 그리고, 지금까지는 [일못변] 시리즈에서 남들 못하는 것 지적질만 했기 때문에, 나는 어떻게 하는지도 정리해야 하겠다고 생각이 들었다. 나름대로는 오랜 시행착오를 거쳐 정립된 나만의 방법이다.

아래에서는 내가 일을 진행하는 방법을 간략히 정리해 보고자 한다. 편의상 예를 들어, 한 소프트웨어 회사가 앱을 만들었는데 이 앱을 이용하여 미국시장에 진출하고자 하는 경우를 생각해 보자. 상담 결과 법률환경 등에 대한 리서치 결과와 로드맵을 정리한 리서치 의견서와 이를 반영한 약관, 개인정보 사용에 대한 동의 및 Privacy Policy를 작성하기로 하였다. 참고로, Privacy Policy는 개인정보의 수집과 사용과 관리에 대한 회사의 방침을 기술한 문서이다. 일종의 유행같은 것이다. 새로 나온 핸드폰처럼 꼭 없어도 되지만, 일단 가지려면 제대로 된 걸 가져야 한다. 꼭 있어야 하는 이유는 남들이 다 가지고 있기 때문이다. 이게 회사의 운영 현실과 맞지 않으면 사기로 처벌받을 수도 있다.

makefile로 로드맵 만들기

일단 프로젝트를 시작하면, 나는 가장 먼저 makefile을 만든다. 예를 들면 다음과 같다.

MEMO = $(shell date +%F)-memo.pdf
TERMS = $(shell date +%F)-terms-and-conditions.pdf
CONSENT = $(shell date +%F)-consent.pdf
PRIVACYPOLICY = $(shell date +%F)-privacy-policy.pdf
YAML = common.yaml
CONTRACTTEMPLATE = contractTemplate.tex
MEMOTEMPLATE = memoTemplate.tex
ENGINE = lualatex
MEMODRAFT = memo.md
TERMSDRAFT = terms.md
CONSENTDRAFT = consent.md
PRIVACYPOLICYDRAFT = privacyPolicy.md
BIBFILE = research.bib

memo: $(YAML) $(MEMOTEMPLATE) $(MEMODRAFT) $(BIBFILE)
	pandoc --filter pandoc-citeproc -o $(MEMO) $(YAML) $(MEMODRAFT) --template=$(MEMOTEMPLATE) --pdf-engine=$(ENGINE)
terms: $(YAML) $(CONTRACTTEMPLATE) $(TERMSDRAFT)
	pandoc -o $(TERMS) $(YAML) $(TERMSDRAFT) --template=$(CONTRACTTEMPLATE) --pdf-engine=$(ENGINE)
consent: $(YAML) $(CONTRACTTEMPLATE) $(CONSENTDRAFT)
	pandoc -o $(CONSENT) $(YAML) $(CONSENTDRAFT) --template=$(CONTRACTTEMPLATE) --pdf-engine=$(ENGINE)
privacypolicy: $(YAML) $(CONTRACTTERMS) $(PRIVACYPOLICYDRAFT)
	pandoc -o $(PRIVACYPOLICY) $(YAML) $(PRIVACYPOLICYDRAFT) --template=$(CONTRACTTEMPLATE) --pdf-engine=$(ENGINE)

makefile이 무엇인지 아는 사람은 금방 이해했겠지만, 여기에는 프로젝트 전체의 로드맵이 있다. 사실 프로젝트 관리에 makefile보다 좋은 것은 없다. 모든 결과물에는 $(shell date +%F)가 붙어 있으므로, 자동으로 맨 앞에 날짜가 추가된다. 예를 들어, 메모 파일의 최종본은 (오늘 컴파일했다면) 2018-07-19-memo.pdf가 된다. 여기에서는 4건의 결과물이 있다.

그리고, 모든 프로젝트에 공통으로 적용되는 내용 (예를 들어, 고객명, 주소, 날짜 등)은 모두 YAML 파일 하나에 기록하여 공유한다. 그리고, 두 개의 템플릿이 있다. 계약서용 템플릿이 있고, 메모/의견서용 템플릿이 있다. 엔진은 lualatex을 사용한다. 출력물을 만드는 것은 pandoc을 사용한다.

그리고 다섯 개의 초안을 작성하여야 한다. 이 파일들을 솔직히 tex으로 작성하는 것이 더 편하다. 마크다운을 아주 좋아하지만, 심각한 문제는 커멘트를 할 수 있는 공식적인 방식이 없다는 것이다. 이 문제는 조금 더 심각한게 git 자체에서도 커멘트를 사용할 수 없다. github이나 gitlabissue 같은 서비스를 이용해야 한다. 여기에 대해서는 나중에 다시 이야기하겠다. 한 가지 장점이라면, 만약 고객이 소스파일을 원하거나 소스파일로 협업하기를 원할 경우에는 마크다운이 tex 파일보다는 조금 더 읽기 편하고, 작업하기 편하다는 것이다.

이제 해야하는 것은 각각의 파일들을 만드는 것 뿐이다.

문서자동화

이것만으로도 훌륭한 문서자동화가 가능하다. 문제가 복잡하거나, 계약이 좀 더 복잡하다면, 두 가지 방법이 있다. 첫째는 여러 파일로 나누는 것이다. latex\input{}을 사용하거나, 아니면 md 파일을 여럿으로 나누어 위 makefile에서 순서대로 정렬해 두기만 하면 된다.

두 번째 방법은 pandoc template를 만들어 두는 것이다. 이것은 흔히 자주 사용하는 계약, 예를 들어 자문계약서 등의 경우에 유용하다. 항상 포함되는 조항 등은 템플릿을 만들어 여기 포함시켜 두고, 특정 경우에만 적용되는 것은 별도 파일에 기록하는 방식이다.

나름 꽤나 오랫동안 수정과 변경을 거쳐 정리한 방법이지만, 아주 효율적이다. 나는 이 방법을 통하여 계약서 작성이나 프로젝트 진행 시간을 크게 줄였다.




Disclaimer (경고)

첫째, 여기에서 내가 한 일 또는 법에 대해서 이야기해도 비슷한 일을 하면 비슷한 결과가 나올 것이라는 뜻은 아닙니다. 둘째, 여기에서 내가 어떤 법이나 분야에 대해서 이야기했다고 하더라도, 내가 그 분야의 전문가이거나 자격증을 가지고 있거나 인증기관으로부터 인증을 받았다는 뜻은 아닙니다. 셋째, 여기서 하는 이야기는 수시로 업데이트되며, 관련 주제에 대한 이야기의 전체가 아니고 오로지 일부분일 뿐입니다. 넷째, 달리 표시하지 않은 한 번역은 본인이 직접 하였습니다. 다른 곳에서 더 나은 번역을 찾을 수도 있습니다. 다섯째, 여기에서 하는 이야기는 법률자문이 아닙니다. 또 이곳의 이야기는 미국 변호사 이야기이고, 미국법 이야기입니다.

무엇보다도 여기서 읽은 이야기는 일반적인 정보이지 법률자문이 아닙니다.

이 경고는 법에 대해 이야기하는 모든 페이지에 나타납니다.

License (사용)

개인적 목적으로 다른 곳에 글을 복사해 가는 것은 허용합니다만, 반드시 출처를 표시해 주시기 바랍니다. 글의 일부만 복사해갈 경우, 글의 전체 맥락에 따라 내가 의도하는 바가 잘못 표현될 수 있으므로, 반드시 링크 등을 포함시켜 독자가 직접 의도와 맥락을 확인할 수 있도록 해 주시기 바랍니다. 복사할 때에는 반드시 Disclaimer와 License를 포함시켜 주시기 바랍니다.

글쓰기 규칙

제가 한 업무에 대해서는 글을 쓰지 않습니다. 심지어는 비밀특권이나 비밀보호의무에 해당하지 않는 경우라도 쓰지 않습니다. 자랑하는 것은 체질도 아니거니와, 제가 하는 일은 --- 계약이건 의견서 작성이건 소송이건 --- 고객 한 사람만을 위한 일이기 때문입니다. 다만, 고객이 요청하는 경우에는 예외입니다.

비록 로펌에서 일하지만, 회사명과 회사 이메일은 공개하지 않습니다. 회사에도 홈페이지가 있습니다. 홈페이지/블로깅에 대하여 회사와 대화를 한 적이 있었습니다. 회사 방침은 개인적으로 블로깅을 하는 것은 허용하지만, 회사 홈페이지를 사용하는 것은 안된다고 말하였습니다. 이 말을 존중합니다. 또, 어차피 제 입맛에 맞추어 다 고칠 수도 없는 바에야... 연락은 hyunkim [at] hyunkim.lawyer로 부탁합니다.