GitHub 법무팀의 사례에서 주목할 부분은 법률 업무에 AI를 사용했다는 사실 자체가 아니다. 변호사, 프로그램 매니저, 비즈니스 담당자가 반복 업무를 저장소에 버전 관리되는 지침, 참고 자료, 템플릿, 재사용 가능한 절차로 바꿨다는 점이 핵심이다. 이들은 GitHub Copilot CLI에 자연어로 원하는 결과를 설명하고, 각자의 판단 기준을 작업 흐름에 반영했다.
개발자와 연구자에게도 같은 접근이 유효하다. 일회성 질문을 더 잘 작성하는 데 머무르지 않고, 반복해서 사용하는 기준과 출력 형식을 파일로 관리하면 결과의 일관성을 높이고 복사와 붙여넣기를 줄일 수 있다. 다만 이 사례를 곧바로 “코딩 없이 모든 업무를 자동화할 수 있다”는 의미로 받아들여서는 안 된다. 초기 워크플로는 자연어 중심으로 만들었지만, 기사에 등장하는 데스크톱 앱 단계에서는 실제 코드도 필요했다.
무엇이 달라졌나
GitHub 법무팀이 먼저 해결하려 한 문제는 계약 검토, 반복적인 법률 질의 대응, DMCA 통지 분석처럼 비슷한 판단을 계속 수행하면서도 매번 작업을 처음부터 시작해야 하는 상황이었다. 기존 지침을 재사용할 수 있었지만, 개인별 프롬프트와 수작업에 흩어져 있으면 결과를 재현하거나 팀에 전달하기 어렵다.
이들은 Copilot CLI를 단순한 질의 도구가 아니라 업무 방법을 구현하는 제작 도구로 사용했다. 지침과 자료를 저장소에 모으고, 원하는 분석 절차와 보고서 형식을 자연어 파일로 표현했다. 저장소를 사용하면 변경 이력을 확인하고, 어떤 기준이 결과에 영향을 주었는지 추적하며, 팀이 같은 기반에서 개선할 수 있다.
이 구조는 일반적인 개발 업무에도 대응시킬 수 있다. 코드 리뷰 기준, 장애 분류 절차, 릴리스 점검표, 연구 데이터 정리 규칙, 과제 채점 보조 기준처럼 사람이 반복해서 적용하는 방법을 먼저 명시한 뒤 도구가 그 절차를 따르게 하는 방식이다. 중요한 것은 AI가 업무를 대신한다는 표현보다, 사람의 기준을 읽을 수 있고 수정 가능한 형태로 운영한다는 데 있다.
계약 작성 도구에서 확인할 수 있는 설계 원칙
제품 법률 담당자 Ngandu Kasuku는 데이터, 인프라, 제품 통합과 관련된 파트너십 계약이 늘면서 검토 부담을 겪었다. 거래마다 조건이 달라 기존 문서를 단순 복제하기 어려웠고, 프롬프트 모음을 사용할 때는 자료를 반복해서 복사해 넣어야 했다. 이에 Copilot CLI를 이용해 계약 작성 도구인 terms-ai를 만들었다.
그는 프로젝트의 기본 구조를 만들고, AI가 참고할 지침과 작성 자료, 작업 절차를 저장소에 정리했다. 주요 기능 중 하나는 쉬운 표현을 선호하는 자신의 계약 작성 원칙을 담은 내부 스타일 가이드였다. 이미 검토를 마친 계약서 라이브러리도 구성해 기존 파트너가 부속 합의서나 새 계약서를 보낼 때 과거 작업을 참고할 수 있게 했다.
기사에서 당사자는 이 도구를 사용한 뒤 검토와 작성 시간이 대략 절반으로 줄었고, 계약 조항과 문체도 더 일관되어졌다고 설명한다. 다만 이는 특정 담당자의 업무에서 나온 경험치다. 모든 계약 업무나 다른 조직에서 같은 절감률을 보장하는 성능 기준으로 해석하면 안 된다. 문서 유형, 검토 깊이, 승인 절차, 입력 자료의 품질에 따라 효과는 달라질 수 있다.
정보 공개 범위도 구분되어 있다. 도구와 일반적인 작업 흐름은 오픈소스로 제공하지만, 실제 계약서와 민감한 정보는 공개 저장소에 포함하지 않았다. 해당 자료는 승인된 접근 통제 환경에 남겨 두었다. 공개 가능한 프로그램과 비공개 업무 데이터를 분리하는 원칙은 법률팀뿐 아니라 소스 코드, 연구 자료, 고객 정보, 보안 보고서를 다루는 모든 사용자에게 중요하다.
DMCA 분석에서 시작한 반복 가능한 법률 워크플로
온라인 안전 법률 담당자 Jesse Geraci는 DMCA 통지를 평가하기 위해 소스 코드를 신속하고 정확하게 분석해야 하는 문제에서 출발했다. 초기 구성은 DMCA 분류, 코드 비교, 라이선스 확인, 기술적 우회 여부 검토처럼 반복되는 업무를 위한 Copilot 지침 모음이었다.
목표는 구성원들이 각자 일회성 프롬프트를 만드는 상태를 벗어나, 필요한 사실을 빠뜨리지 않고 같은 기준으로 분석할 수 있는 절차를 만드는 것이었다. 핵심 구성 요소는 워크플로 지침, 정책 참고 자료, 보고서 템플릿을 담은 자연어 파일이었다. 법률가가 가진 문장 구성 능력과 판단 기준을 구조화된 지침으로 표현했다는 점에서, 프로그래밍 언어를 직접 작성하는 능력만이 자동화의 출발점은 아니라는 사실을 보여준다.
이후에는 사용 대상에 따라 분석 방식을 나눴다. 일반 의뢰자에게는 더 빠른 결과와 상향 검토 권고를 제공하고, 법률 담당자에게는 깊은 검토와 양측 논거를 제공하도록 구성했다. 외부 데이터 소스도 연결했으며, 최종적으로는 미리 정의된 법률 워크플로를 실행하는 데스크톱 앱으로 발전했다.
데스크톱 앱은 계약 검토, 비밀유지계약 분류, 위험 평가, 규정 준수 확인, 답변 작성 등 더 넓은 사내 업무를 지원하게 됐다. 내부적으로는 접수, 기준표 정렬, 위험 점수화, 증거 확인, 상향 전달, 보고서 조립 같은 단계를 재사용할 수 있지만, 담당자는 읽기 쉬운 Markdown 지침을 통해 행동을 수정할 수 있었다.
여기에는 중요한 제한이 있다. 이 시스템은 법률적 판단의 대체물이 아니라 사람의 검토를 중심에 둔 의사결정 지원 도구로 설명된다. 개발 환경에서도 보안 승인, 라이선스 판단, 연구 결과 해석처럼 책임이 필요한 결정은 같은 원칙을 적용해야 한다. AI 출력은 판단 자료일 뿐이며, 최종 승인자와 오류 발생 시 책임 범위를 명확히 해야 한다.
개발자와 연구자가 가져갈 수 있는 실용적인 기준
이 사례를 적용할 때는 “어떤 거대한 앱을 만들 것인가”보다 “매주 반복되며 기준이 비교적 분명한 작업은 무엇인가”부터 묻는 편이 좋다. 반복 빈도가 낮거나 매번 판단 구조가 완전히 달라지는 업무라면 구축과 유지에 드는 비용이 절감 효과보다 클 수 있다.
- 개발자: 이슈 분류, 릴리스 노트 작성, 코드 리뷰 사전 점검, 장애 보고서 초안처럼 입력과 출력 형식이 반복되는 작업을 후보로 삼을 수 있다.
- 학생: 수업 자료 정리, 참고문헌 형식 확인, 과제 제출 전 점검처럼 규칙은 명확하지만 반복적인 절차를 검토할 수 있다.
- 연구자: 논문 메타데이터 정리, 실험 기록 형식 통일, 분석 전 데이터 점검에 활용할 수 있다. 다만 비공개 연구 데이터와 개인정보의 입력 가능 여부를 먼저 확인해야 한다.
- 팀 운영자: 개인 프롬프트를 공유하는 수준을 넘어 지침 변경 이력, 승인자, 실패 처리, 결과 검토 책임을 함께 설계해야 한다.
작게 검증하는 적용 순서
- 작업 하나를 고른다. 시간이 많이 들면서도 결과 형식과 판단 기준을 설명할 수 있는 반복 업무가 적합하다.
- 현재 절차를 먼저 기록한다. 입력 자료, 확인 순서, 예외 조건, 최종 출력, 승인자를 적는다. 기존 절차가 불명확하면 AI 도구도 불명확한 결과를 반복할 가능성이 크다.
- 지침과 참고 자료를 분리한다. 행동 규칙, 정책 자료, 예시, 출력 템플릿을 한 파일에 뒤섞기보다 역할별로 관리하면 변경 원인을 찾기 쉽다.
- 민감한 자료를 구분한다. 공개 가능한 도구와 실제 고객 문서, 계약서, 비공개 코드, 연구 데이터가 같은 저장소에 들어가지 않도록 경계를 정한다.
- 작은 표본으로 비교한다. 기존 방식과 새 워크플로에서 걸린 시간, 수정 횟수, 누락된 항목, 사람이 다시 확인한 범위를 기록한다.
- 실패 경로를 만든다. 확신할 수 없는 결과를 표시하고 담당자에게 넘기는 조건, 이전 절차로 돌아가는 방법, 생성 결과를 폐기하는 기준을 마련한다.
- 팀 공유 전에 권한을 점검한다. 저장소 접근 권한, 외부 데이터 연결, 로그와 결과물의 보존 범위를 실제 계정과 조직 설정에서 확인한다.
도입 전에 확인할 체크포인트
| 항목 | 확인할 질문 | 적용 기준 |
|---|---|---|
| 가격과 사용 조건 | 현재 계정이나 조직 플랜에서 Copilot CLI를 사용할 수 있는가? 별도 제한이나 사용량 조건이 있는가? | 기사에는 구체적인 가격과 플랜 조건이 제시되지 않았다. 현재 공식 가격표와 계정 화면을 확인한 뒤 기존 도구의 비용과 비교한다. |
| 저장소 권한 | CLI가 어떤 저장소와 파일에 접근하며, 실행 계정은 어느 범위까지 읽거나 변경할 수 있는가? | 필요한 디렉터리와 저장소만 허용하고, 비밀값과 민감 문서는 별도로 관리할 수 있어야 한다. |
| 데이터 경계 | 입력한 코드와 문서, 생성 결과, 로그가 어디에 저장되고 누가 볼 수 있는가? | 업무 문서나 연구 자료를 넣기 전에 조직 정책과 서비스의 최신 데이터 처리 조건을 확인한다. |
| 정확성 | 결과가 정책 원문, 코드, 증거 자료를 빠짐없이 반영했는가? | 표본을 수동 검토하고 중요한 판단에는 근거 확인과 사람의 승인을 유지한다. |
| 재현성 | 같은 입력과 지침에서 결과가 충분히 일관적인가? | 지침, 참고 자료, 템플릿의 버전을 함께 기록해 결과 차이의 원인을 추적할 수 있어야 한다. |
| 유지보수 | 정책이나 팀 기준이 바뀌었을 때 누가 지침을 수정하고 검토하는가? | 파일 담당자와 승인 절차를 지정하고, 오래된 기준이 계속 사용되지 않도록 변경 이력을 관리한다. |
| 기존 대안 | 스크립트, 템플릿, 체크리스트, 기존 자동화 도구로도 같은 결과를 낼 수 있는가? | 전환과 검증 비용보다 반복 작업의 절감 효과가 클 때 우선 도입한다. |
기사의 표현을 읽을 때 주의할 점
GitHub는 자연어로 원하는 도구를 만들 수 있다는 가능성을 강조한다. 실제 사례도 비개발 직군이 자신의 전문 지식을 작동하는 워크플로로 바꿀 수 있음을 보여준다. 그러나 자연어를 사용한다고 해서 설계와 운영 책임까지 사라지는 것은 아니다. 좋은 결과를 내려면 방법론, 기준, 예외, 출력 형식을 명확하게 설명해야 한다.
또한 “코드를 한 줄도 작성하지 않는다”는 메시지는 사용자가 전통적인 방식으로 코드를 직접 작성하지 않아도 시작할 수 있다는 뜻에 가깝다. 기사 속 워크플로가 데스크톱 앱으로 확장되는 과정에는 많은 코드가 필요했다고 명시되어 있다. 따라서 간단한 개인용 절차와 여러 사용자가 쓰는 제품 수준의 앱을 같은 난이도로 보면 안 된다. 배포, 권한, 업데이트, 오류 처리, 보안 검토가 필요해지면 개발자의 역할도 다시 커질 수 있다.
바로 도입해도 될까
공개 기사만 보고 전체 업무를 옮기는 것은 이르다. 먼저 반복 업무 하나와 공개하거나 테스트해도 되는 자료를 골라 제한된 실험을 진행하는 편이 안전하다. 결과가 빨라졌는지만 보지 말고, 누락과 오류가 줄었는지, 사람이 수정한 횟수는 얼마인지, 새 지침을 유지하는 부담이 생기지 않았는지를 함께 확인해야 한다.
기존 도구가 이미 같은 결과를 안정적으로 낸다면 바로 전환할 이유는 약하다. 반대로 개인별 프롬프트가 흩어져 있고 같은 설명을 계속 복사하며 결과 품질도 들쭉날쭉하다면, 지침과 템플릿을 저장소에서 관리하는 방식은 검토할 가치가 있다. 이때 핵심 성과는 화려한 생성 결과보다 반복 가능한 절차, 추적 가능한 변경, 명확한 사람의 검토 지점이다.
출처와 검증
사례와 기능 설명은 GitHub Blog의 How the GitHub legal team used Copilot CLI to streamline their workflows를 기준으로 재구성했다. 기사에 제시되지 않은 현재 가격, 플랜별 제공 범위, 데이터 처리 조건, 지역 및 계정 제한은 실제 적용 시점의 GitHub 공식 문서와 조직 설정에서 별도로 확인해야 한다.