Huny's Dev Blog
huny.dev

도메인 전문성을 AI 도구로 전환하는 방법: Sullivan & Cromwell의 Codex 활용 사례

글로벌 로펌 Sullivan & Cromwell이 Codex로 맞춤형 계약 분석 도구 Agreement Analyzer를 개발한 사례를 정리한다. 선례(Precedents)와 플레이북 결합 구조, 변경 추적(Track Changes) 검토 방식, 도메인 특화 AI 도구 개발 시 확인할 점을 살펴본다.

Hun Jang

OpenAI가 공개한 Sullivan & Cromwell의 Codex 활용 영상과 공식 사례 글은 비개발 직군의 도메인 전문가가 어떻게 자신의 업무 노하우를 소프트웨어 도구로 직접 구현하고 전사 시스템으로 확장했는지를 다룬다. 글로벌 로펌 Sullivan & Cromwell의 파트너 변호사 John Savva는 Codex를 사용해 맞춤형 계약 검토 도구인 Agreement Analyzer의 초기 프로토타입을 직접 구축했다.

결론부터 말하면, 전문 도메인에서 작동하는 AI 도구의 핵심은 범용 모델에 문서를 그대로 넣는 것이 아니라, 조직이 축적한 선례(precedents)와 판단 기준(playbook)을 구조화된 입력으로 결합하고 전문가가 검증할 수 있는 형태로 결과를 반환하는 데 있다. 다만 이 글은 OpenAI가 공개한 인터뷰 영상과 사례 문서를 바탕으로 도구의 입출력 설계와 워크플로를 정리한 것이며, 실제 법률 검토 정확도나 처리 시간을 직접 측정한 결과는 아니다.

도메인 전문가가 직접 만드는 프로토타입

전문 분야의 사내 도구를 개발할 때 흔히 겪는 문제는 도메인 지식과 소프트웨어 구현 사이의 간극이다. 현업 전문가는 어떤 맥락과 기준이 필요한지 알고 있지만 코드를 직접 짜기 어렵고, 개발팀은 현업의 미묘한 의사결정 기준을 모두 파악하기 어렵다.

이번 사례에서 주목할 점은 출발점이다. 파트너 변호사가 엔지니어링 팀에 요구사항 명세서를 넘기는 대신, Codex를 활용해 1인용 개념 검증(PoC) 애플리케이션을 직접 만들어 작동 방식을 먼저 검증했다. 이후 이 프로토타입을 바탕으로 사내 기술팀 및 OpenAI와 협업해 다수 사용자가 쓸 수 있는 Agreement Analyzer로 발전시켰다. OpenAI의 Sullivan & Cromwell 사례 소개

Agreement Analyzer의 입력과 출력 구조

단순히 계약서 초안을 넣고 “문제가 있는지 봐달라”고 요청하는 방식은 실무에서 그대로 쓰기 어렵다. 거래 유형마다 적용할 선례가 다르고, 고객사의 입장이나 시장 관행에 따라 수용 가능한 조건이 달라지기 때문이다.

영상과 발표 문서에서 설명하는 Agreement Analyzer의 입출력 구성을 정리하면 다음과 같다.

구분
구성 요소
실무에서의 역할
입력 1
상대방 계약서 초안 (Draft Agreement)
검토 대상이 되는 원문 문서
입력 2
핵심 선례 (Curated Precedents)
해당 거래 유형에 가장 부합하는 조직 내부의 검증된 과거 계약 사례
입력 3
협상 플레이북 (Negotiating Playbook)
고객사의 입장, 시장 관행(market practice), 로펌 내부의 검토 기준
출력 1
쟁점 및 근거 메모 (Issue Memorandum)
식별된 문제점 목록과 각 판단에 대한 구체적인 근거(rationale)
출력 2
변경 추적 마크업 (Track Changes Markup)
변호사가 기존 문서 도구에서 바로 검토·수정·반영할 수 있는 수정본

여기서 중요한 것은 두 가지 출력 형태다. 결과만 바뀐 문서를 내놓으면 검토자는 왜 그 문구가 수정되었는지 다시 역추적해야 한다. 반대로 모든 결정의 근거(rationale)가 담긴 메모와 변경 추적(Track Changes) 마크업을 함께 제공하면, 전문가는 판단 이유를 투명하게 확인하고 필요한 부분만 빠르게 수정해 고객에게 전달할 수 있다.

범용 챗봇 호출과 맞춤형 애플리케이션의 차이

이 사례는 현업에서 ChatGPT 같은 대화형 인터페이스를 그대로 쓰는 것과, Codex로 맞춤형(bespoke) 래퍼 애플리케이션을 만드는 것의 차이를 잘 보여준다.

Receive a memorandum of all the issues that were identified with full transparency into the rationale for all the decisions and a track changes markup that can be reviewed by the lawyer, adapted, changed, and then made available for their client's use.

매번 긴 프롬프트로 선례와 플레이북을 복사해 넣는 대신, 입력 항목을 정형화하고 출력 형식을 기존 업무 문서 포맷(Track Changes)에 맞춘 전용 도구를 만들면 작업 속도와 분석의 깊이가 달라진다. AI가 전문가를 대체하는 것이 아니라, 전문가가 초안 대조와 반복 문서 작업에 쓰는 시간을 줄여 더 깊은 분석에 집중하도록 돕는 구조다.

도메인 특화 AI 도구를 설계할 때 확인할 점

법률뿐 아니라 금융, 의료, 엔지니어링 등 높은 정확도와 검증이 요구되는 도메인에서 내부 AI 도구를 구축할 때는 다음 기준을 함께 점검할 만하다.

  • 참조 기준의 명시적 분리: 모델의 일반 지식에 의존하지 않도록 조직의 선례(Precedents)와 정책(Playbook)을 별도 입력 계층으로 주입하는가?
  • 판단 근거의 투명성 확보: 최종 수정안만 출력하지 않고, 왜 해당 항목을 문제로 분류했는지 근거(Rationale)를 함께 제시해 사람이 검증할 수 있는가?
  • 기존 업무 포맷과의 호환성: 출력물이 현업 담당자가 매일 쓰는 도구(예: Word의 Track Changes, 코드의 diff) 형태로 바로 변환되는가?
  • 프로토타입과 프로덕션의 경계: Codex 등으로 빠르게 만든 1인용 PoC를 전사 도구로 전환할 때, 민감 데이터 보안(예: ChatGPT Enterprise 환경 분리), 권한 관리, 감사 로그를 별도로 갖췄는가?

결국 코딩 에이전트의 가치는 개발자의 생산성 향상에만 있지 않다. 도메인 전문가가 머릿속의 업무 규칙을 작동하는 프로토타입으로 직접 구현할 수 있게 되면서, 현업에 꼭 맞는 맞춤형 도구를 만드는 초기 비용 자체가 낮아지고 있다.

참고 자료

발표 내용과 구성은 October 28, 2026 공개 자료 확인 기준이다.

추천 글