6장 HR, 법무 및 고객 지원

금요일 오후 다섯 시, 서울 테헤란로의 한 스타트업. 인사 담당자의 모니터에는 채용 공고 마감 후 쏟아진 이력서 247통이 정렬되지 않은 채 쌓여 있습니다.

PDF, 워드, 한글 파일이 뒤섞여 있고, 어떤 지원자는 포트폴리오를 이메일 본문에 링크로 붙였습니다. 바로 옆 자리에서는 법무 담당자가 파트너사에서 보내온 45페이지짜리 합작투자 규약서를 인쇄해 형광펜으로 줄을 긋고 있습니다.

복도 건너편 고객 지원팀 방에서는 상담원 세 명이 쉴 새 없이 키보드를 두드리고 있습니다. 시스템 업데이트 이후 밀려든 문의 티켓이 120건을 넘었고, 그중에는 결제 오류로 당장 환불을 요구하는 메일과 "이런 기능 좀 만들어 달라"는 장문의 제안서가 아무 구분 없이 섞여 있습니다.

세 장면에 공통점이 있습니다.

모두 텍스트를 읽고, 분류하고, 판단하고, 다시 텍스트로 응답하는 작업입니다. 읽는 양은 방대하고, 분류 기준은 정해져 있으며, 판단의 실수는 곧바로 사람에게 영향을 미칩니다. 채용에서 좋은 지원자를 놓치면 조직이 손해를 보고, 계약서에서 독소 조항을 넘기면 회사가 위험해지며, 고객 불만에 늦장을 부리면 신뢰가 무너집니다.

이 장에서 다루는 네 가지 작업은 기업의 백오피스(Back-office, 고객에게 직접 보이지 않는 내부 행정 업무 영역)를 떠받치는 기둥입니다. 대량 이력서 평가와 순위 매기기, 신규 직원 온보딩과 오퍼 레터 작성, 인바운드 고객 지원 티켓 처리, 계약서 검토와 기밀유지협약(NDA) 분석입니다.

코워크의 HR 플러그인과 법무 플러그인, 고객 지원 플러그인은 2026년 1월 말에서 2월 사이에 순차적으로 공개되었습니다.

Anthropic은 이 플러그인들을 오픈소스로 GitHub에 공개했고, 각 기업이 자사의 평가 기준, 계약 심사 기준, 고객 응대 정책에 맞춰 커스터마이즈할 수 있도록 설계했습니다.

법무 플러그인이 2월 초에 발표되었을 때, 톰슨 로이터스(Thomson Reuters) 주가가 하루 만에 16%넘게 빠졌고, 리걸줌(LegalZoom)은 20% 가까이 하락했습니다. 2,850억 달러의 시가총액이 증발한

그 하루를 언론은 "SaaSpocalypse"라고 불렀습니다. 플러그인 하나가 시장에 던진 충격의 크기가 이 도구의 잠재력을 설명합니다.

HR, 법무, 고객 지원은 모두 사람의 삶에 직접 닿는 영역입니다. 이력서 뒤에는 생계가 걸린 지원자가 있고, 계약서 뒤에는 회사의 운명이 걸린 의사결정이 있으며, 티켓 뒤에는 불편을 겪고 있는 고객이 있습니다. 코워크는 읽고 분류하고 초안을 쓰는 일을 대신합니다. 그러나 탈락시킬 지원자를 확정하는 것, 계약서에 서명하는 것, 고객에게 최종 답변을 보내는 것은 사람의 판단이자 사람의 책임입니다. 기계는 시간을 절약해 주지만, 그 절약된 시간에 사람이 무엇을 하느냐가 결과의 질을 결정합니다.

1 대량 입사 지원서 평가 및 순위 매기기

한 포지션에 300명이 지원하면, 숙련된 인사 담당자가 이력서 한 건을 검토하는 데 평균 7분이 걸립니다. 300건이면 35시간, 꼬박 4일 이상입니다. 그 4일 동안 담당자의 피로는 누적되고, 월요일 아침에 읽은 첫 번째 이력서와 금요일 오후에 읽은 마지막 이력서가 같은 잣대로 평가되리라는 보장은 없습니다. 잠재력이 뛰어난 지원자의 서류가 피로에 짓눌린 오후의 시선 아래 묻힐 수 있습니다. 인간의 인지 능력에는 한계가 있고, 수백 명의 기록을 일관된 기준으로 끝까지 읽어내는 것은 물리적으로 불가능에 가깝습니다.

코워크는 이 서류 검토 과정을 완전히 다른 차원으로 끌어올립니다. 회사가 미리 설정한 채용 평가표를 기준 프레임워크(Framework, 판단의 뼈대가 되는 기준 체계)로 삼고, 각 이력서에서 해당 항목을 추출하여 수치화합니다. 기계는 피곤해지지 않고, 300번째 이력서를 1번째와 같은 강도로 읽습니다.

가 왜 필요한가

문제는 이력서의 형식이 제각각이라는 점입니다. 어떤 지원자는 PDF에 깔끔한 표를 넣고, 어떤 지원자는 워드 파일에 자유롭게 서술합니다. 경력 기간을 "3년"이라고 적는 사람이 있고, 프로젝트 시작일과 종료일만 적는 사람이 있습니다.

코워크에 탑재된 대규모 언어모델은 이런 비정형 텍스트에서 의미를 파악하는 데 강점이 있습니다. 형식이 다르더라도 "이 사람의 관련 경력이 몇 년인가", "어떤 기술을 사용할 줄 아는가"를 맥락에서 추론합니다.

평가의 핵심은 투명성입니다. AI가 왜 이 지원자에게 85점을 주고 저 지원자에게 72점을 줬는지, 항목별 근거가 드러나야 합니다. 근거 없는 점수는 공정하지도, 쓸모 있지도 않습니다.

나 무엇을 해주는가

코워크의 HR 플러그인을 설치하면, Claude는 즉시 인사 업무에 특화된 스킬(Skill, 특정 분야의 지식과 작업 절차가 담긴 설정 파일)을 장착합니다. 이메일에 쌓인 지원서를 Gmail 커넥터로 수집하거나, 폴더에 모아둔 이력서 파일을 일괄로 읽어 들입니다. 사용자가 제공한 평가표의 기준에 따라 각 지원자의 경력 연차, 기술 일치도, 프로젝트 경험, 직무 적합성을 항목별로 채점하고, 총점 순위와 함께 각 점수의 근거를 문장으로 남깁니다. 결과물은 조건부 서식이 적용된 엑셀 파일입니다.

다 어떻게 하는가: 기본 사용

가장 간단한 형태부터 시작합니다. 이력서 10건을 평가표 기준으로 채점해 봅니다.

[따라하기]

① Claude Desktop 앱을 열고 상단의 "Cowork" 탭을 클릭합니다. 좌측 사이드바의 "Customize" 메뉴에서 HR 플러그인을 설치합니다. 아직 설치하지 않았다면, "Browse Plugins"를 눌러 목록에서 "HR"을 찾아 "Install" 버튼을 클릭합니다.

② 바탕화면에 "2026_마케터_채용"이라는 폴더를 만듭니다. 폴더에 세 가지를 넣습니다. 회사의 채용 평가표 파일(PDF 또는 워드), 직무 기술서(JD) 파일, 그리고 지원자들의 이력서 파일 10건입니다.

③ 코워크 화면 상단에서 이 폴더를 작업 폴더로 지정합니다.

④ 다음 프롬프트를 입력합니다.

"이 폴더에 있는 채용 평가표와 직무 기술서를 먼저 읽어 줘. 그 기준을 바탕으로 이 폴더의 모든 이력서 파일을 분석하고 다음 작업을 해 줘.

첫째, 평가표의 항목(관련 경력 연차, 기술 스택 일치도, 프로젝트 경험, 직무 적합성)별로 10점 만점 기준 점수를 매겨 줘.

둘째, 각 점수에 대해 '왜 이 점수인지' 근거를 한두 문장으로 써 줘. 예를 들어 'SEO 도구 경험을 언급했으나 구체적인 성과 수치가 없어 기술 숙련도 6점'처럼.

셋째, 총점 기준 내림차순으로 정렬한 엑셀 파일을 만들어 줘. 열 구성은 지원자 이름, 연락처, 항목별 점수, 총점, 순위, 평가 근거 요약으로 해 줘. 상위 3명은 셀 배경을 초록색으로, 하위 3명은 노란색으로 표시해 줘.

파일명은 '마케터_지원자_평가표.xlsx'로 이 폴더에 저장해 줘."

⑤ Claude가 계획을 표시합니다. "평가표를 읽겠습니다 → 직무 기술서를 분석하겠습니다 → 채점 프레임워크를 구축하겠습니다 → 이력서를 순차 분석하겠습니다 → 엑셀을 생성하겠습니다." 계획을 확인한 뒤 "진행해 줘"를 입력합니다.

⑥ 2~3분 뒤 폴더에 엑셀 파일이 생성됩니다. 파일을 열면 각 지원자의 이름 옆에 항목별 점수와 근거가 정리되어 있고, 총점 순으로 정렬되어 있습니다.

라 어떻게 하는가: 응용 사례

지원자가 수십 명으로 늘어나고, Gmail에서 직접 이력서를 수집하는 상황입니다. ① 코워크에서 Gmail 커넥터를 연결합니다. 좌측 사이드바의 "Customize" 메뉴에서 "Connectors" 를 열고 Gmail을 선택합니다.

② 다음 프롬프트를 입력합니다.

"Gmail 커넥터를 사용해서 내 받은편지함에서 지난 2주 동안 제목에 '마케터 지원'이 포함된 이메일을 모두 찾아 줘. 각 이메일의 첨부파일(이력서)을 이 폴더에 저장해 줘. 그리고 앞서 만든 채점 프레임워크를 그대로 적용해서 모든 지원자를 평가하고, 동일한 형식의 엑셀 파일을 새로 만들어 줘. 이번에

는 지원자가 많으니, 상위 10명에 대해서만 '심층 면접 시 물어볼 맞춤형 질문 2개'를 추가 열에 작성해 줘."

③ Claude가 Gmail에 접속하여 이메일을 검색하고, 첨부파일을 다운로드하고, 분석을 시작합니다. 사이드바에 진행 상황이 표시됩니다.

마 어떻게 하는가: 실전 활용 300건이 넘는 대규모 채용에서, 평가 보고서와 경영진 요약 문서를 동시에 생성합니다.

① 다음 프롬프트를 입력합니다.

"이 폴더에 있는 모든 이력서를 채용 평가표 기준으로 평가해 줘. 지원자가 300명이 넘을 수 있으니 끝까지 처리해 줘. 다음 세 가지 파일을 만들어 줘.

첫째, 전체 지원자 평가표 엑셀. 항목별 점수, 총점, 순위, 근거 요약, 조건부 서식(상위 10% 초록, 하위 30% 빨강) 적용. 둘째, 상위 15명에 대한 심층 분석 Word 문서. 각 후보자의 핵심 강점, 우려 사항(Red flags), 맞춤형 면접 질문 3개를 포함해 줘. 셋째, 경영진에게 보고할 1페이지 요약서 Word 문서. 총 지원자 수, 평균 점수, 상위 5명의 프로필 한 줄 요약, 채용 추천 의견을 담아 줘."

② 코워크가 서브 에이전트를 실행하여 이력서를 병렬로 처리합니다. 300건의 비정형 문서에서 정보를 추출하고, 같은 기준으로 채점합니다.

③ 완성된 엑셀을 열면 "1위: 정우진 (총점 56/60점)"처럼 정렬되어 있고, Word 문서에는 면접 질문까지 포함되어 있습니다.

바 AI 채용 평가의 경계선

이 도구의 효과가 클수록 짚어야 할 것도 분명합니다.

첫째, AI 평가는 1차 스크리닝 도구이지, 최종 판단 도구가 아닙니다. 이력서에 드러나지 않는 잠재력, 조직 문화와의 적합성, 면접에서 보여줄 의사소통 능력은 기계가 읽어낼 수 없는 영역입니다. AI가 낮은 점수를 준 지원자 중에도 면접에서 빛나는 인재가 있을 수 있습니다.

하위 점수대 지원자 중 일정 비율을 무작위로 인사 담당자가 직접 검토하는 안전장치를 두는 것이 바람직합니다.

둘째, 편향(Bias) 문제입니다. 미국 평등고용기회위원회(EEOC)는 소프트웨어와 AI를 활용한 채용 평가에서 장애를 가진 지원자에게 차별이 발생할 수 있다고 경고해 왔습니다.

평가 기준에 특정 대학 출신에 가산점을 부여하거나, 경력 공백이 있는 지원자를 일률적으로 감점하는 규칙이 포함되어 있다면, AI는 그 편향을 사람보다 더 일관되게 반영합니다. 기준이 공정하면 AI는 공정한 도구가 되고, 기준이 편향되어 있으면 AI는 편향의 증폭기가 됩니다. 채용 시스템을 도입하기 전에 평가표 자체의 공정성을 먼저 점검해야 합니다.

셋째, 설명 가능성입니다. 자동화가 후보자를 "정렬"하는 데는 유용하지만, 탈락을 "기계가 확정"하는 구조로 가면 법적 위험이 커집니다. AI가 산출한 점수는 추천값으로 활용하되, 왜 그런 점수가 나왔는지 설명할 수 있는 근거가 항상 함께 남아 있어야 합니다.

기계가 1위부터 300위까지 줄을 세워준 깔끔한 명단을 받아든 채용 담당자는, 서류를 읽는 노동에서 해방되었습니다. 그 대신 하위권으로 밀려난 이력서들을 다시 한번 들여다보며, 알고리즘이 미처 발견하지 못한 가능성이 숨어 있지 않은지 살피는 책임을 짊어지게 됩니다.

사 이런 문제가 생겼다면

(1) 한글(.hwp) 파일의 이력서를 제대로 읽지 못합니다. 코워크는 PDF와 워드 파일의 텍스트 추출에 안정적입니다. 한글 파일은 형식에 따라 인식률이 떨어질 수 있습니다. 지원자에게 PDF 제출을 안내하거나, 한글 파일을 PDF로 변환한 뒤 폴더에 넣으면 정확도가 올라갑니다.

(2) 같은 지원자가 이력서를 여러 번 보냈습니다. Gmail 커넥터로 수집하면 같은 이름의 이메일이 여러 통 잡힐 수 있습니다. 프롬프트에 "같은 발신자 이메일이 여러 건 있으면 가장 최신 첨부파일만 사용하고, 이전 버전은 무시해 줘"라는 조건을 추가합니다.

(3) AI가 특정 항목에서 지나치게 후한 점수를 줍니다. 평가표의 기준이 모호하면 AI가 넓게 해석합니다. "'SEO 경험 있음'이라고만 적힌 지원자는 기술 숙련도 5점 이하로 제한해 줘. 구체적인 도구명(Google Analytics, Ahrefs, SEMrush 등)과 성과 수치가 함께 있어야 7점 이상이야"처럼 채점 기준을 프롬프트에서 정밀하게 잡아 줍니다.

2 직원 온보딩 및 제안서 작성

합격자가 확정되는 순간, 새로운 종류의 행정 업무가 시작됩니다. 합의된 연봉과 보너스, 휴가 일수, 수습 기간 조건이 정확하게 기입된 오퍼 레터를 작성하고, 기밀유지 서약서를 준비하며, 첫 출근 날 노트북 사양을 IT 부서에 요청하는 일련의 과정입니다.

동시에 입사 첫날부터 30일까지 무엇을 하고, 누구를 만나고, 어떤 시스템에 접근 권한을 받는지 온보딩 계획을 짜야 합니다.

오퍼 레터는 법적 구속력을 가질 수 있는 공식 문서이고, 온보딩 계획은 실무적 안내서입니다. 성격은 다르지만, 둘 다 반복적 구조를 가지면서 후보자마다 세부 내용이 달라야 한다는 공통점이 있습니다. AI가 효과를 발휘하기 좋은 조건입니다.

가 왜 필요한가

오퍼 레터에서 실수가 발생하면 신뢰가 금이 갑니다. 이전 후보자의 연봉 숫자가 그대로 남아 있거나, 직급과 맞지 않는 성과급 비율이 기재되는 경우가 실제로 있습니다. 인사 담당자가 여러 건을 동시에 처리하다 보면, 이런 사소하지만 치명적인 빈칸에서 실수가 생깁니다. 온보딩 계획이 부실하면 신규 입사자의 초기 정착률이 떨어집니다. 체계적인 온보딩을 경험한 직원의 1년 내 이직률이 그렇지 않은 직원보다 낮다는 연구 결과가 다수 존재합니다.

나 무엇을 해주는가

코워크의 HR 플러그인에는 오퍼 레터 초안 작성과 온보딩 계획 수립에 특화된 스킬이 내장되어 있습니다. 회사의 표준 오퍼 레터 템플릿과 보상 체계표를 제공하면, 특정 후보자의 확정 조건을 정확하게 채워 넣은 문서를 생성합니다. 온보딩 계획은 직무 정보, 부서 정보, 입사자의 경력 수준을 입력받아 맞춤형 일정표와 체크리스트로 만들어냅니다.

다 어떻게 하는가: 기본 사용

오퍼 레터 한 건을 만들어 봅니다.

[따라하기]

① "2026_채용_온보딩" 폴더에 회사의 오퍼 레터 템플릿(워드 파일)과 합격자 조건 메모(텍스트 파일) 를 넣습니다. 조건 메모에는 이름, 직급, 연봉, 시작일, 특약 사항을 적어 둡니다.

② HR 플러그인이 설치된 코워크에서 다음 프롬프트를 입력합니다.

"이 폴더에 있는 오퍼 레터 템플릿과 합격자 조건 메모를 읽어 줘. 메모에 적힌 조건(이름: 정우진, 직급: 콘텐츠 마케팅 스페셜리스트, 연봉: 6,000만 원, 시작일: 2026년 5월 2일, 유급 휴가: 연 20일)을 템플릿에 정확하게 반영하여 오퍼 레터 Word 문서를 작성해 줘. 톤은 공식적이되 환영하는 느낌을 담아 줘. 서명란과 수락 기한(발송일로부터 7일)을 포함해 줘. 파일명은 '오퍼레터_정우진.docx'로 저장해 줘."

③ Claude가 템플릿의 양식과 회사 로고를 유지한 채, 빈칸에 해당 조건을 채워 넣은 문서를 생성합니다.

④ 반드시 문서를 열어 숫자를 검증합니다. 연봉, 시작일, 수습 기간 조건이 메모와 정확히 일치하는지 확인합니다.

라 어떻게 하는가: 응용 사례

오퍼 레터에 이어 온보딩 계획까지 한 번에 만듭니다.

① 폴더에 회사의 시스템 환경 정보(사내 메신저는 슬랙, 문서 관리는 노션, 이메일은 Gmail)를 적은 텍스트 파일을 추가합니다.

② 다음 프롬프트를 입력합니다.

"앞서 만든 오퍼 레터에 이어서, 정우진 님의 입사 온보딩 패키지를 추가로 만들어 줘.

첫째, 입사 첫날(Day 1)부터 첫째 주(Week 1)까지의 시간대별 온보딩 일정표를 Word 문서로 만들어 줘. 회사가 슬랙, 노션, Gmail을 쓴다는 점을 반영해서, 언제 어떤 시스템의 계정을 설정하고, 언제 팀원들과 인사하고, 언제 첫 프로젝트 브리핑을 받는지 구체적으로 넣어 줘. 둘째, 온보딩 진행 상황을 추적할 수 있는 체크리스트 Word 문서도 만들어 줘. '보안 교육 수강', 'IT 계정 생성', '급여 계좌 등록', '팀 소개 미팅 완료' 같은 항목을 포함해 줘. 셋째, 합격자에게 이 문서들을 첨부해서 보낼 환영 이메일 초안을 텍스트 파일로 작성해 줘. 세 파일 모두 이 폴더에 저장해 줘."

③ Claude가 온보딩 일정표, 체크리스트, 이메일 초안을 동시에 생성합니다.

마 어떻게 하는가: 실전 활용

여러 직무의 합격자를 동시에 처리합니다.

① 같은 폴더에 개발자, 영업, 디자이너 세 명의 합격자 조건 메모를 각각 만들어 넣습니다.

② 다음 프롬프트를 입력합니다.

"이 폴더에 세 명의 합격자 조건 메모가 있어. 각 합격자에 대해 오퍼 레터, 맞춤형 온보딩 일정표, 체크리스트, 환영 이메일을 만들어 줘. 직무가 다르니까 온보딩 일정도 달라야 해. 개발자는 첫 주에 코드 저장소 접근 권한과 개발 환경 설정이 먼저이고, 영업은 CRM 시스템과 제품 자료 숙지가 먼저이고, 디자이너는 피그마 접근 권한과 브랜드 가이드라인 리뷰가 먼저야. 각 합격자별로 하위 폴더를 만들어 파일을 분리해 줘."

③ 코워크가 서브 에이전트를 실행하여 세 명의 패키지를 병렬로 생성합니다. 공통 항목(보안 교육, 급여 계좌 등록)은 동일하게, 직무별 항목은 다르게 구성됩니다.

기계가 행정 문서를 빈틈없이 만들어 주었습니다. 그러나 새롭게 출근하는 직원이 진정으로 원하는 것은 완벽하게 조판된 계약서나 빈틈없이 짜인 일정표 자체가 아닙니다. 낯선 환경에 첫발을 내딛을 때 느끼는 불안감을 덜어 주는 것은 환영해 주는 사람들의 따뜻한 인사입니다. 기계가 모든 행정적인 짐을 덜어준 지금, 인사 담당자와 부서 리더들은 그 매끄러운 문서 위에 자신만의 진심 어린 환영의 언어를 덧입히는 일에 집중할 수 있습니다.

바 이런 문제가 생겼다면

(1) 오퍼 레터의 연봉 숫자가 메모와 다릅니다. Claude가 메모의 숫자를 잘못 읽었을 가능성이 있습니다. 메모 파일에서 숫자를 "60,000,000원"처럼 쉼표와 단위를 명확히 표기하면 인식률이 올라갑니 다. 생성된 문서의 숫자는 반드시 사람이 대조합니다.

(2) 온보딩 일정이 회사의 실제 프로세스와 맞지 않습니다. HR 플러그인의 기본 스킬은 일반적인 온보딩 순서를 따릅니다. 회사 고유의 절차(예: 첫날 반드시 대표 미팅, 둘째 주에 법정 의무 교육)가 있다면, 플러그인을 커스터마이즈하여 스킬 파일에 자사 절차를 추가합니다. "Customize" 버튼을 눌러 Claude와 대화하며 수정할 수 있습니다.

3 인바운드 고객 지원 티켓 처리

고객 지원 부서의 하루는 쏟아지는 티켓과의 전쟁입니다. 제품 결함 신고, 환불 요청, 기능 개선 요구, 사용법 문의, 계정 문제가 성격 구분 없이 한꺼번에 밀려듭니다.

상담원은 각 티켓을 읽고, 문제를 파악하고, 우선순위를 정하고, 회사 정책에 맞는 답변을 작성해야 합니다. 이 과정에서 가장 어려운 것은 감정적으로 격앙된 고객에게 거절의 메시지를 전달하는 일입니다. 욕설과 흥분을 걷어내고 고객이 진짜 원하는 기술적 조치가 무엇인지 파악한 뒤, 정해진 매뉴얼에 따라 건조하면서도 친절한 답변을 작성하는 것은 엄청난 감정 노동입니다.

가 왜 필요한가

상담 업무의 병목은 "답장을 못 써서"가 아니라 "누가 이 티켓을 봐야 하는지 모르는 상태"에서 생기는 경우가 많습니다. 기능 요청인지, 장애인지, 사용법 문의인지, 환불 불만인지가 처음부터 갈리면 대응 속도와 품질이 크게 달라집니다.

나 무엇을 해주는가

코워크의 고객 지원 플러그인(Customer Support Plugin)은 들어오는 티켓을 자동으로 분류하고, 우선순위를 매기고, 회사 정책에 맞는 답장 초안을 작성합니다.

Anthropic 공식 문서에 따르면, 이 플러그인에는 다섯 가지 슬래시 명령어(Slash Command, "/" 기호로 시작하는 실행 명령)가 내장되어 있습니다. /triage는 티켓을 분류하고 우선순위를 매깁니다. /research는 고객 질문에 대한 답을 여러 소스에서 찾습니다. /draft-response는 상황과 채널에 맞춘 답장 초안을 작성합니다. /escalate는 엔지니어링이나 제품팀에 넘길 에스컬레이션 브리프를 만듭니다. /kb-article은 해결된 이슈를 지식 기반 문서로 변환합니다.

다 어떻게 하는가: 기본 사용

고객 문의 이메일 10건을 분류하고 답장 초안을 만들어 봅니다.

[따라하기]

① 코워크에 고객 지원 플러그인을 설치합니다. Customize 메뉴에서 Browse Plugins → Customer Support → Install.

② "고객지원_티켓" 폴더에 고객 문의 이메일을 텍스트 파일로 저장해 넣습니다. (Gmail 커넥터를 연결했다면 폴더 없이 직접 이메일을 읽을 수도 있습니다.)

③ 다음 프롬프트를 입력합니다.

"/triage 이 폴더에 있는 고객 문의 파일 10건을 분석해서 다음과 같이 분류해 줘. 카테고리: 버그 리포트, 기능 요청, 결제 문제, 사용법 문의, 계정 문제. 우선순위: P1(긴급, 서비스 장애나 결제 오류), P2(높음, 핵심 기능 관련 버그), P3(보통, 일반 문의), P4(낮음, 기능 제안). 결과를 엑셀 표로 정리해 줘. 열은 티켓 번호, 고객명, 카테고리, 우선순위, 핵심 내용 요약(한 줄), 권장 조치로 해 줘."

④ Claude가 각 이메일의 의도와 긴급도를 분석하여 분류표를 생성합니다.

⑤ 이어서 답장 초안을 요청합니다.

"/draft-response 방금 분류한 P1 티켓에 대해 즉시 답장 초안을 만들어 줘. 고객의 불편에 공감하는 문장을 앞에 넣고, 환불 절차 안내를 중간에 넣고, 추가 도움이 필요하면 연락하라는 마무리를 넣어 줘. 톤은 정중하되 따뜻하게."

⑥ Claude가 각 P1 티켓에 맞춤화된 답장 초안을 텍스트 파일로 생성합니다.

라 어떻게 하는가: 응용 사례

기능 요청 티켓에 대해 정중한 거절 이메일을 만듭니다.

① 다음 프롬프트를 입력합니다.

"/draft-response 분류 결과에서 '기능 요청' 카테고리 티켓들을 찾아 줘. 이 요청들은 현재 우리 제품 로드맵에 포함되어 있지 않아. 고객의 아이디어에 감사를 표하면서도, 현재 개발 계획에는 없다는 점을 솔직하게 알려주는 답장 초안을 만들어 줘. 다만 고객이 존중받는다고 느낄 수 있는 톤이어야 해. ' 귀하의 피드백은 제품팀에 전달되었습니다'라는 문장을 포함하되, 약속처럼 들리지 않게 조심해 줘. 각 고객의 이름과 요청 내용을 반영해서 개인화된 답장을 만들어 줘."

② Claude가 고객별로 맞춤화된 거절 이메일을 생성합니다. 상담원은 초안을 검토하고 전송합니다.

마 어떻게 하는가: 실전 활용

하루 치 티켓 전체를 한 번에 처리하고, 주간 분석 리포트까지 만듭니다.

① Gmail 커넥터를 연결한 상태에서 다음 프롬프트를 입력합니다.

"Gmail 커넥터로 지원 이메일함(support@회사.com)에 들어온 오늘자 미확인 티켓을 모두 읽어 줘. 다음 작업을 순서대로 해 줘.

첫째, 모든 티켓을 /triage로 분류하고 우선순위를 매겨 줘. 둘째, P1 긴급 티켓에는 즉시 답장 초안을 /draft-response로 만들어 줘. 셋째, 기능 요청 티켓은 요청 내용을 요약하여 '기능요청_주간정리.xlsx' 파일에 추가해 줘. 기존 파일이 있으면 이어 붙이고, 없으면 새로 만들어 줘. 넷째, 심각한 버그 리포트는 /escalate로 엔지니어링팀 에스컬레이션 브리프를 만들어 줘. 버그 재현 단계, 영향 범위, 보고 고객 수를 포함해 줘. 다섯째, 이번 주 티켓 전체를 분석하여 '주간 고객 지원 리포트 Word 문서'를 만들어 줘. 카테고리별 건수, 평균 응답 시간, 반복 발생하는 불만 유형 Top 3을 포함해 줘."

② 코워크가 여러 서브 에이전트를 동시에 실행하여 분류, 초안 작성, 에스컬레이션, 리포트를 병렬로 처리합니다.

이 체계가 갖춰지면 고객 지원이 사후 대응에서 제품 개선의 입력 채널로 격상됩니다. 기능 요청 엑셀 파일에 쌓인 데이터가 제품팀에 전달되면, 감이 아니라 근거로 우선순위를 잡을 수 있습니다.

다만 AI가 생성한 답변을 그대로 보내지 않아야 합니다. AI 초안은 상담원의 출발점이지 최종 결과물이 아닙니다. 고객의 상황에는 텍스트에 드러나지 않는 맥락이 있을 수 있고, 이전 상담 이력과의 연속성도 고려해야 합니다. AI가 80%를 완성하고, 상담원이 나머지 20%를 채우는 구조에서, 상담원은 하루에 처리할 수 있는 티켓 수가 늘어나면서도 각 고객에게 더 정성 어린 응대를 할 수 있게 됩니다.

바 이런 문제가 생겼다면

(1) Claude가 고객의 감정을 잘못 읽어 부적절한 톤의 답장을 만듭니다. 고객이 농담 섞인 불만을 적었는데 Claude가 심각한 사과문을 쓰는 경우가 있습니다. 프롬프트에 "답장 톤을 정할 때 고객 메시지의 감정 강도를 상, 중, 하로 먼저 판단하고, 그에 맞는 톤을 적용해 줘"라는 지침을 추가합니다.

(2) 기능 요청 거절 메일이 기계적으로 느껴집니다. 거절 메일의 품질은 고객의 구체적 요청을 얼마나 정확히 언급하느냐에 달려 있습니다. "고객이 요청한 구체적 기능명을 답장에 반드시 포함하고, 그 기능이 현재 제품에 없는 이유를 한 문장으로 설명해 줘"라고 지시합니다.

(3) 에스컬레이션 브리프가 엔지니어링팀에 필요한 정보를 빠뜨립니다. /escalate 명령어의 기본 출력에 브라우저 버전, OS, 고객 플랜 등급 같은 기술 정보가 포함되지 않을 수 있습니다. "에스컬레이션 브리프에 고객의 플랜 등급, 사용 브라우저, 오류 발생 시간을 반드시 포함해 줘. 고객 이메일에 이 정보가 없으면 '정보 미제공'으로 표시해 줘"라고 조건을 추가합니다.

4 계약서 검토 및 NDA 분석

법무팀에 상대방 기업이 보내온 45페이지짜리 조인트 벤처 파트너십 규약서가 도착했습니다. 검토 기한은 5영업일입니다. 동시에 신규 거래처와의 기밀유지협약(NDA, Non-Disclosure Agreement, 당사자 간 비밀 정보를 외부에 누설하지 않겠다는 계약) 3건, 소프트웨어 라이선스 계약 수정본 1건, 데이터 처리 위탁 계약서 1건이 대기 중입니다. 변호사 두 명이 이 모든 문서를 기한 안에 검토해야 합니다.

법률 문서를 검토하는 일은 고도의 전문 지식과 끝을 알 수 없는 편집증적 집요함을 동시에 요구합니다. 우호적인 인사말로 시작되는 문서의 이면에는, 만약의 사태가 발생했을 때 모든 책임을 상대방에게 떠넘기기 위한 조항들이 복잡한 수식어구 속에 교묘하게 숨어 있습니다. 손해배상 한도를 설정한 14 조 2항의 모호한 단어 하나를 놓치는 순간, 회사는 미래에 수십억 원의 소송 위험을 떠안게 됩니다.

가 왜 필요한가

법무 업무의 병목은 읽는 시간입니다. 45페이지를 처음부터 끝까지 정독하면서 각 조항의 의미를 파악하고, 회사의 컴플라이언스 워크플로우(Compliance Workflow, 법규 준수 여부를 확인하는 내부 심사 절차)와 대조하는 데 하루 이상이 걸립니다. 그 시간 동안 변호사는 다른 긴급한 법무 이슈에 손을 댈 수 없습니다.

나 무엇을 해주는가

코워크의 법무 플러그인(Legal Plugin)은 2026년 2월 2일에 최초 공개되었습니다. 이 플러그인은 계약서 검토, NDA 분류, 컴플라이언스 워크플로우를 자동화하는 전문 시스템입니다. Anthropic 공식 문서에 따르면, 핵심 슬래시 명령어는 다섯 가지입니다.

/review-contract는 계약서를 회사의 협상 플레이북(Playbook, 조항별 수용 가능 범위와 협상 기준을 정리한 내부 지침서)과 대조하여, 조항별로 안전(GREEN), 주의(YELLOW), 위험(RED) 등급을 매기고 수정 제안을 합니다.

/triage-nda는 들어온 NDA를 빠르게 선별하여, 표준 승인, 법무 검토, 전면 재검토 세 단계로 분류합니다. /vendor-check는 거래처 계약 상태를 확인합니다. /brief는 법적 이슈에 대한 요약 브리핑을 생성합니다. /respond는 데이터 주체 요청이나 소송 보전 같은 표준 법률 서한을 템플릿 기반으로 만듭니다.

[알아두기] 플레이북이란?

법무 플러그인의 핵심은 플레이북입니다. 플레이북은 "우리 회사는 이 조항을 이렇게 해석하고, 이 범위까지만 수용한다"는 내부 기준을 정리한 문서입니다. 예를 들어 "무제한 배상 책임 조항은 RED", " 비경쟁 조항 기간 2년 이내는 GREEN, 3년 이상은 YELLOW" 같은 규칙이 담겨 있습니다. 플레이북이 있어야 AI가 "우리 기준으로 어디가 위험한지"를 판단할 수 있습니다. 플레이북 없이 분석하면 일반적인 상업 표준에 따른 검토만 가능합니다.

다 어떻게 하는가: 기본 사용

NDA 한 건을 분석해 봅니다.

[따라하기]

① 코워크에 법무 플러그인을 설치합니다. Customize → Browse Plugins → Legal → Install.

② "2026_계약검토" 폴더에 상대방이 보내온 NDA 파일(PDF)을 넣습니다.

③ 다음 프롬프트를 입력합니다.

"/triage-nda 이 폴더에 있는 NDA 파일을 분석해 줘. 나는 정보 제공자(Disclosing party) 입장이야. 다음 사항을 확인해 줘. 첫째, 기밀 정보의 정의 범위가 지나치게 넓지 않은지. 둘째, 기밀 유지 기간이 합리적인지(업계 관행은 보통 2~3년). 셋째, 잔존지식 조항(Residuals clause)이 포함되어 있는지.

넷째, 반환 및 폐기 의무에 백업 예외가 있는지. 분류 결과를 표준 승인, 법무 검토, 전면 재검토 중 하나로 알려 줘."

④ Claude가 NDA를 읽고, 각 확인 사항에 대해 분석 결과와 분류를 표시합니다.

라 어떻게 하는가: 응용 사례

회사의 플레이북을 적용하여 계약서를 조항별로 검토합니다.

① "2026_계약검토" 폴더에 회사의 계약 심사 플레이북 파일(워드 또는 텍스트)과 상대방의 계약서 파일을 함께 넣습니다.

② 플러그인을 커스터마이즈합니다. Customize 버튼을 눌러 Claude에게 "우리 회사의 플레이북 파일은 이 폴더에 있는 '계약심사기준.docx'야. 이 기준을 /review-contract 명령어에 적용해 줘"라고 지시합니다.

③ 다음 프롬프트를 입력합니다.

"/review-contract 이 폴더에 있는 조인트 벤처 파트너십 규약서를 우리 플레이북 기준으로 조항별 검토해 줘. 다음 산출물을 만들어 줘. 첫째, 조항별 분석 보고서(Word). 각 주요 조항(당사자 정의, 출자 구조, 이익 분배, 지배구조, 지적재산권 귀속, 비경쟁 의무, 해지 조건, 분쟁 해결, 준거법)에 대해 GREEN/YELLOW/RED 등급을 매기고, YELLOW와 RED 조항에 대해서는 위험의 성격과 권장 수정 방향을 써 줘. 둘째, 경영진이 5분 안에 읽을 수 있는 1페이지 경영진 요약서(Word). 핵심 위험 3가지, 즉각적 조치 사항, 협상 우선순위를 담아 줘. 두 파일을 이 폴더에 저장해 줘."

④ Claude가 45페이지를 분석하여, 조항별 신호등 시스템이 적용된 보고서와 1페이지 요약서를 생성합니다.

마 어떻게 하는가: 실전 활용

NDA 여러 건과 대형 계약서를 동시에 처리합니다.

① 폴더에 NDA 5건과 파트너십 규약서 1건을 모두 넣습니다.

② 다음 프롬프트를 입력합니다.

"이 폴더에 있는 모든 법률 문서를 검토해 줘. NDA 파일들은 /triage-nda로 빠르게 분류하고, 파트너십 규약서는 /review-contract로 조항별 심층 분석해 줘. 첫째, NDA 5건의 분류 결과를 한 장의 엑셀 표로 요약해 줘. 열은 파일명, 상대방 회사명, 기밀 유지 기간, 핵심 위험 사항, 분류(표준/검토/재검토)로 해 줘. 둘째, 파트너십 규약서의 조항별 분석 보고서를 플레이북 기준으로 만들어 줘. 셋째, RED로 표시된 조항에 대해서는 우리가 상대방에게 제안할 수정 문구(Redline)를 포함한 수정 계약서 초안을 만들어 줘. 넷째, 경영진 요약서 1페이지를 만들어 줘. 모든 파일을 이 폴더에 저장해 줘."

③ 코워크가 NDA는 빠르게 분류하고, 규약서는 깊이 있게 분석하는 두 가지 깊이의 검토를 동시에 수행합니다.

바 AI 법률 분석의 절대적 경계선

AI의 법률 문서 분석은 변호사의 법적 판단을 대체하지 않습니다.

AI는 텍스트에서 패턴을 인식하고 잠재적 이슈를 표면화하는 역할을 합니다. 그러나 해당 조항이 특정 관할권의 판례법에 비추어 실제로 집행 가능한지, 우리 회사의 사업 전략 맥락에서 그 위험을 감수할 가치가 있는지, 상대측과의 관계를 고려할 때 어느 수준까지 수정을 요구하는 것이 적절한지는 변호사만이 판단할 수 있는 영역입니다.

AI가 "위험 없음"이라고 분류한 조항에서 실제 문제가 발생했을 때, 그 책임은 AI가 아닌 검토 변호사에게 있습니다. AI 분석 결과를 맹신하지 않고 비판적으로 검토하는 태도가 필수입니다.

Anthropic 자체도 코워크가 리서치 프리뷰 단계이며, 규제 대상 업무(Regulated workloads)에는 사용하지 말 것을 명시하고 있습니다. 법무 플러그인의 출력은 "보조(Assistance)"이지 "조언(Advice)" 이 아닙니다. 최종 판단과 서명의 책임은 언제나 사람에게 있습니다.

코워크는 변호사가 45페이지를 물리적으로 읽는 시간을 절약해 주고, 놓칠 수 있는 조항을 한 번 더 확인해 주는 보조 도구입니다. 조항을 분석하는 고단한 노동은 기계에 넘겨주었지만, 그 조항이 현실에서 어떤 결과를 만들어낼지 판단하고 계약서에 서명하는 순간의 무게는 책상 앞에 앉은 사람의 몫으로 남습니다.

사 이런 문제가 생겼다면

(1) 플레이북 없이 /review-contract를 실행했더니 분석이 피상적입니다. 플레이북이 없으면 Claude 는 일반적인 상업 표준에 따라 분석합니다. 회사 고유의 위험 허용 기준이 반영되지 않으므로, 실무적 가치가 떨어집니다. 자사의 계약 심사 체크리스트나 과거 검토 의견서를 참고하여 플레이북 파일을 만들어 플러그인에 연결합니다. 플레이북에는 최소한 각 주요 조항 유형별 수용 가능 범위와 에스컬레이션 기준을 적어 두면 됩니다.

(2) 한국어 계약서의 법률 용어를 정확히 인식하지 못합니다. "손해배상 예정액", "하자담보책임", "기한의 이익 상실" 같은 국내 법률 용어에 대해 Claude가 맥락을 잘못 잡을 수 있습니다. 프롬프트에 "이 계약서는 대한민국 법을 준거법으로 하는 한국어 문서야. 한국 민법과 상법의 맥락에서 분석해 줘"라고 명시하면 정확도가 올라갑니다.

(3) RED로 표시된 조항이 너무 많아서 실무적으로 쓸모가 없습니다. 플레이북의 기준이 지나치게 엄격하면, 대부분의 조항이 RED로 찍혀 우선순위 판단이 어려워집니다. 플레이북을 수정하여 "우리가 절대 수용하지 않는 조항"과 "협상 가능한 조항"을 분리하고, RED는 전자에만 적용하고 후자는 YELLOW로 설정합니다.

이 장에서 다룬 네 가지 작업은 공통된 구조를 가지고 있습니다. 기계가 대신하는 것은 방대한 텍스트를 읽고, 기준에 따라 분류하고, 초안을 생성하는 일입니다. 기계가 대신할 수 없는 것은 지원자의 잠재력을 알아보는 눈, 신규 직원을 따뜻하게 맞이하는 진심, 고객의 절박함을 헤아리는 공감, 법적 위험을 감수할지 말지 결정하는 판단입니다.

300통의 이력서를 읽는 노동에서 해방된 채용 담당자는, 기계가 놓친 가능성을 살피는 사람이 됩니다. 문서 작성에서 벗어난 인사 담당자는, 첫 출근하는 직원에게 커피를 건네는 사람이 됩니다. 티켓 분류에서 자유로워진 상담원은, 기계의 답장이 고객의 마음에 닿았는지 살피는 사람이 됩니다. 45페이지의 문자에서 벗어난 변호사는, 위험과 기회를 저울질하는 전략가가 됩니다.

코워크가 만든 보고서와 초안은 완성품이 아니라 출발점입니다. 그 출발점에서 사람이 무엇을 더하느냐가, 채용의 질을, 고객의 신뢰를, 계약의 안전을 결정합니다.