산업별 사례 연구

사례를 읽는 법: 업종명이 아니라 업무의 흐름을 보라

Claude 도입 사례를 볼 때 가장 흔한 실수는 업종 이름에 먼저 끌리는 것이다. 금융이면 금융 사례만, 제조면 제조 사례만 찾는다. 그러나 실제 현장에서는 업종보다 업무의 흐름이 더 중요하다. 법무팀의 계약 검토, 제약사의 임상 문서 작성, 투자사의 리서치 메모, 제조사의 설비 매뉴얼 질의응답은 겉으로는 달라 보이지만 속은 비슷하다. 모두 많은 문서를 읽고, 필요한 근거를 찾고, 일정한 형식으로 정리하고, 사람이 최종 판단한다.

Anthropic의 공식 use-case guide 역시 Claude를 단순한 채팅 도구가 아니라 특정 업무 흐름에 맞게 설계하는 생산 시스템으로 다룬다.¹ 이 장에서는 그래서 '산업별 사례'를 소개하되, 산업을 고정된 분류표처럼 다루지 않는다. 대신 독자가 자신의 조직에 바로 옮길 수 있도록 입력, 처리, 출력, 검토, 운영 지표의 형태로 사례를 해부한다.

이 장에서 기억해야 할 문장은 하나다. 좋은 Claude 사례는 멋진 답변에서 끝나지 않고, 사람이 더 나은 결정을 내릴 수 있는 반복 가능한 흐름으로 남는다.

공통 프레임: 입력, 근거, 행동, 검증

산업별 사례는 다르지만 성공한 적용 방식에는 공통 골격이 있다. Claude에게 업무를 맡긴다는 말은 '이 문서를 읽고 답해 줘'라고 던지는 것이 아니다. 어떤 자료를 넣을지, 어떤 근거를 우선할지, 결과를 어디에 사용할지, 언제 사람에게 넘길지, 나중에 품질을 어떻게 확인할지를 함께 정하는 일이다.

가장 단순한 설계 도식은 다음과 같다.

이 프레임은 앞 장들에서 다룬 RAG, 도구 사용, 평가, 보안, 운영을 산업 맥락에 끼워 넣는 방법이기도 하다. 예를 들어 고객지원 에이전트라면 입력은 고객 문의와 계정 정보, 근거는 지식베이스와 정책 문서, 행동은 답변 초안과 티켓 라우팅, 검증은 해결률과 에스컬레이션 정확도다. 법률 검토라면 입력은 계약서와 사내 플레이북, 근거는 조항 위치와 선례 문구, 행동은 리스크 표와 수정 제안, 검증은 변호사 승인과 감사 로그다.

공개된 엔터프라이즈 사례에서도 반복되는 패턴은 비슷하다. Novo Nordisk는 규제 문서 작성 병목을 줄이기 위해 Claude 기반 문서화 플랫폼을 만들었고, Palo Alto Networks는 개발 조직의 코드 이해와 구현 속도를 높이는 데 Claude를 활용했으며, Cox Automotive와 Salesforce는 고객 접점과 에이전트형 워크플로우에 Claude를 붙였다.² 회사 이름은 다르지만, 공통점은 'AI를 써 보자'가 아니라 '어떤 병목을 어떤 통제 장치 아래 줄일 것인가'에서 출발했다는 점이다.

지식노동과 문서 작업: 읽는 시간을 판단의 시간으로 바꾸기

가장 넓은 적용 영역은 지식노동이다. 지식노동의 병목은 대개 글쓰기 그 자체가 아니다. 읽어야 할 문서가 너무 많고, 비교해야 할 버전이 많고, 회의에서 나온 말이 결정으로 정리되지 않으며, 초안은 있는데 검토 기준이 흩어져 있다. Claude는 이 흐름에서 '읽고 정리하는 중간층'을 맡을 때 가장 큰 가치를 낸다.

전형적인 문서 워크플로우는 다섯 단계로 구성할 수 있다.

예를 들어 전략기획팀이 신규 시장 진입 여부를 검토한다고 해 보자. 팀은 시장 보고서, 경쟁사 발표자료, 고객 인터뷰, 내부 매출 데이터를 따로 읽고 있다. 이때 Claude에게 곧바로 '시장 진입 전략을 써 줘'라고 요청하면 결과는 그럴듯하지만 위험하다. 더 좋은 방식은 먼저 문서별 요약 스키마를 고정하는 것이다.

요청은 이렇게 바꿀 수 있다.

다음 자료를 신규 시장 진입 검토 관점에서 읽어 주세요. 각 문서마다 시장 규모, 성장 근거, 고객 세그먼트, 경쟁 강도, 규제 리스크, 우리 회사에 대한 시사점을 같은 형식으로 정리하세요. 원문에 없는 내용은 추정하지 말고 '확인 필요'로 표시하세요. 마지막에는 문서 간 의견이 충돌하는 지점을 따로 모아 주세요.

이 요청의 핵심은 '요약'이 아니라 '비교 가능한 요약'이다. 같은 형식으로 정리되어야 다음 단계에서 판단할 수 있다. 이후에는 Claude에게 충돌 지점만 따로 묶게 하고, 근거가 약한 항목을 표시하게 하고, 임원 보고용 1쪽 메모와 실무 검토용 상세 메모를 각각 만들게 할 수 있다.

문서 작업에서 유용한 출력 형식은 목적에 따라 달라진다. 임원 보고라면 결론과 리스크를 앞에 둔 1쪽 메모가 좋다. 실무 회의라면 쟁점별 표가 좋다. 법무나 컴플라이언스 검토라면 원문 위치와 판단 근거가 필요하다. 고객 커뮤니케이션이라면 상대방의 이해 수준과 감정까지 고려해야 한다. Claude의 공식 활용 사례 페이지도 연구, 글쓰기, 코딩, 분석, 일상 업무를 분리해 보여 주는데, 이 구분은 결국 사용자가 원하는 출력의 형태가 다르기 때문이다.³

문서 작업에서 특히 조심해야 할 것은 '요약의 권위 착시'다. 깔끔하게 정리된 문장은 실제보다 더 확실해 보인다. 그래서 중요한 문서 요약에는 세 가지 장치를 붙이는 편이 좋다.

• 원문에 명시된 사실과 Claude의 추론을 분리한다.

• 의사결정에 영향을 주는 수치에는 문서명, 날짜, 위치를 붙인다.

• '확인 필요', '상충', '근거 부족' 같은 상태값을 출력 형식에 포함한다.

성과 지표는 단순히 작성 시간이 얼마나 줄었는지로만 보지 않는다. 문서 작업의 목표는 빠른 산출이 아니라 좋은 판단이다. 따라서 '초안 작성 시간', '검토 후 수정률', '누락 발견 건수', '회의 후 결정까지 걸린 시간', '재작업 횟수'를 함께 보는 것이 좋다.

개발자 보조와 Claude Code: 모르는 코드에서 안전한 변경까지

개발 조직에서 Claude의 가치는 코드 몇 줄을 빨리 쓰는 데만 있지 않다. 오히려 더 큰 가치는 낯선 코드베이스를 이해하고, 변경 범위를 좁히고, 테스트를 만들고, 리뷰 가능한 형태로 정리하는 데 있다. Palo Alto Networks 사례처럼 대규모 개발 조직에서는 신규 개발자의 온보딩과 기능 개발 속도 자체가 중요한 병목이 된다.²

Claude Code를 개발 워크플로우에 넣을 때는 '바로 구현'보다 '이해 후 변경'이 중요하다. 실무에서 자주 쓰이는 안전한 흐름은 다음과 같다.

Claude Code 워크플로우를 설명하는 실무 자료에서도 Explore → Plan → Implement → Commit처럼 읽기 전용 탐색과 실제 수정을 분리하는 접근을 강조한다.⁴ 이 구분은 단순한 절차가 아니다. 대규모 코드베이스에서는 잘못된 가정이 연쇄적으로 퍼진다. Claude가 처음부터 파일을 고치기 시작하면, 내부 규칙을 모르는 상태에서 '깨끗해 보이는' 코드를 만들 수 있다. 그러나 깨끗한 코드와 조직에서 안전한 코드는 다르다.

예를 들어 오래된 결제 모듈을 리팩터링한다고 하자. 나쁜 요청은 이렇다.

결제 코드를 리팩터링해 줘.

이 요청은 너무 넓다. Claude는 무엇을 보존해야 하는지, 어떤 테스트가 기준인지, 어떤 변경이 위험한지 알 수 없다. 더 좋은 요청은 다음과 같다.

먼저 결제 모듈의 현재 구조를 조사하세요. 파일별 책임, 외부 API 호출 지점, 데이터베이스 쓰기 지점, 테스트가 있는 함수와 없는 함수를 표로 정리하세요. 이 단계에서는 코드를 수정하지 마세요. 조사 결과를 바탕으로 리팩터링 후보를 위험도 순서로 제안하세요.

이후 사람은 제안 중 하나를 고른다. 그다음 Claude에게 '선택한 범위만' 구현하게 한다. 구현 후에는 반드시 테스트를 실행하게 하고, 실패 로그를 다시 Claude에게 제공해 수정 루프를 돈다. 테스트가 없는 코드라면 먼저 테스트 후보를 만들게 해야 한다. 특히 레거시 시스템에서는 '리팩터링 후 더 좋아졌다'보다 '동작이 바뀌지 않았다는 증거'가 중요하다.

개발자 보조 사례에서 Claude에게 맡기기 좋은 일은 다음과 같다.

• 코드베이스 구조 설명, 실행 흐름 추적, 의존성 파악

• 단위 테스트와 엣지 케이스 생성, 기존 테스트 패턴 복제

• 리팩터링 계획 수립, 작은 단위의 구현, 변경 diff 리뷰

• README, API 문서, ADR, 릴리스 노트, PR 설명 작성

• 오류 로그 분석, 원인 후보 정리, 재현 명령 제안

반대로 위험한 일도 있다. 운영 DB 마이그레이션, 권한 체계 변경, 결제·인증·암호화 코드 수정, 고객 데이터 삭제 작업은 Claude가 초안을 만들 수는 있어도 자동 실행해서는 안 된다. 이런 작업은 최소한 계획 승인, 코드 리뷰, 테스트, 스테이징 검증, 롤백 계획을 요구해야 한다.

개발 조직의 성공 지표는 'Claude가 작성한 코드 줄 수'가 아니다. 그 지표는 오히려 위험하다. 더 나은 지표는 PR 리드타임, 리뷰 반려율, 테스트 커버리지 증가, 신규 개발자 온보딩 기간, 장애 후 원인 분석 시간, 문서 최신성이다. Claude Code의 역할은 개발자를 대체하는 타자기가 아니라, 이해와 검증의 비용을 낮추는 동료에 가깝다.

고객지원 에이전트: 빠른 답변보다 신뢰할 수 있는 답변

고객지원은 AI 도입 유혹이 큰 영역이다. 같은 질문이 반복되고, 고객은 빠른 답을 원하며, 상담원은 지식베이스와 과거 티켓을 오가느라 지친다. 그러나 고객지원 에이전트는 잘못 만들면 가장 빨리 신뢰를 잃는 시스템이기도 하다. 틀린 환불 규정, 잘못된 장애 안내, 권한 없는 계정 정보 노출은 'AI 답변 오류'가 아니라 고객 경험 사고다.

따라서 고객지원 에이전트의 목표는 '무조건 자동 응답'이 아니다. 목표는 문의를 정확히 이해하고, 근거 있는 답변을 만들고, 위험하거나 복잡한 건은 사람에게 넘기며, 품질을 계속 측정하는 것이다.

기본 구조는 다음과 같이 설계할 수 있다.

예를 들어 B2B SaaS 회사가 고객지원 에이전트를 만든다고 해 보자. 고객이 'SSO 로그인이 안 된다'고 문의하면 Claude는 먼저 문의를 인증 문제로 분류한다. 그다음 고객의 플랜, 최근 장애 공지, SSO 설정 문서, 과거 유사 티켓을 검색한다. 답변은 '일반적인 SSO 설정법'이 아니라 해당 고객의 상황과 현재 공지에 맞아야 한다. 만약 관리자 권한 확인이나 로그 파일 요청이 필요하다면, Claude는 고객에게 바로 민감한 정보를 요구하지 않고 안전한 수집 절차를 안내해야 한다.

고객지원 답변의 좋은 형식은 다음과 같다.

이 구조가 중요한 이유는 고객에게 보이는 언어와 내부 판단을 분리하기 위해서다. Claude가 상담원에게는 '최근 릴리스 이후 특정 IdP에서 오류 증가'라고 설명하더라도, 고객에게는 확인되지 않은 내부 추정을 단정해서 말하면 안 된다.

고객지원에서 특히 주의할 점은 지식베이스의 품질이다. 오래된 문서가 검색되면 Claude는 오래된 답을 근사하게 포장할 수 있다. 그래서 문서에는 소유자, 마지막 검토일, 적용 제품 버전, 폐기 여부가 있어야 한다. 검색 결과에도 우선순위를 둬야 한다. 최신 장애 공지와 정책 문서는 블로그 글보다 우선해야 하고, 내부 실험 문서는 고객 답변 근거로 쓰지 않아야 한다.

운영 지표는 자동화율만 보면 안 된다. 자동화율이 높아졌는데 재문의율과 환불 요청이 늘었다면 실패다. 고객지원 에이전트의 지표는 첫 응답 시간, 평균 처리 시간, 1차 해결률, 재문의율, 고객 만족도, 잘못된 답변 비율, 에스컬레이션 정확도, 상담원 수정률을 함께 봐야 한다.

법률 요약과 검토 보조: 빠르게 읽되 책임은 흐리지 않는다

법률 업무는 Claude가 강력하게 쓰일 수 있는 분야다. 계약서, 판례, 규제 문서, 실사 자료는 길고 복잡하며 반복 검토가 많다. Anthropic의 법률 요약 가이드는 Claude가 대량의 법률 문서를 요약하고, 핵심 메타데이터를 추출하고, 정해진 형식의 요약을 만들고, 인용과 출처 확인을 돕는 데 유용하다고 설명한다.⁵

하지만 법률 분야에서 가장 중요한 원칙은 이것이다. Claude는 검토를 보조할 수 있지만 법적 판단의 책임자가 되어서는 안 된다. 특히 계약 리스크, 소송 전략, 규제 해석, 고객에게 제공되는 법률 의견은 반드시 변호사나 책임 있는 전문가가 검토해야 한다.

계약 검토 워크플로우를 예로 들어 보자. 구매팀이 벤더의 서비스 계약서를 법무팀에 보냈다. 법무팀은 모든 조항을 처음부터 읽기 전에 Claude에게 1차 구조화를 맡길 수 있다.

이때 프롬프트는 법률 검토자의 관점을 분명히 해야 한다.

당신은 계약 검토를 보조하는 법률 분석가입니다. 다음 계약서를 우리 회사의 표준 플레이북과 비교해 주세요. 각 조항에 대해 원문 위치, 요약, 표준 대비 차이, 잠재 리스크, 권장 조치, 변호사 확인 필요 여부를 표로 작성하세요. 원문에 없는 내용은 추정하지 마세요. 이 결과는 법률 자문이 아니라 변호사 검토를 위한 초안입니다.

이 프롬프트에는 네 가지 안전장치가 들어 있다. 역할은 '보조 분석가'로 제한되어 있고, 표준 플레이북이라는 기준이 있으며, 원문 위치를 요구하고, 최종 용도를 '변호사 검토 초안'으로 못 박는다. 법률 업무에서는 이런 제한이 생산성을 떨어뜨리는 것이 아니라 오히려 운영 가능성을 높인다.

2026년 5월 Anthropic은 법률 업계가 쓰는 문서관리, 계약 생애주기, e-discovery, 리서치 플랫폼과 Claude를 연결하는 MCP 커넥터와 법률 업무용 플러그인을 발표했다.⁶ 이 흐름이 의미하는 바는 분명하다. 법률 AI의 핵심은 고립된 채팅창이 아니라, 권한이 통제된 문서 저장소와 업무 시스템 안에서 작동하는 검토 보조 도구다.

법률 워크플로우에서는 민감 정보 통제도 중요하다. 계약서에는 개인정보, 영업비밀, 가격 조건, 인수합병 정보가 들어갈 수 있다. 따라서 최소한 다음 원칙을 지켜야 한다.

• 필요한 문서와 필요한 조항만 처리하고, 전체 데이터룸을 무차별로 넣지 않는다.

• 사용자 권한을 원본 시스템과 동일하게 적용한다.

• 외부 공유용 요약과 내부 검토용 요약을 분리한다.

• 법률 자문이 아니라 검토 보조 초안임을 명확히 표시한다.

• 최종 의견, 협상안, 고객 전달 문서는 사람 승인을 거친다.

성과 지표는 계약 1건당 1차 검토 시간, 누락 조항 발견률, 플레이북 위반 탐지율, 변호사 수정률, 사업부 응답 시간, 협상 회전 수로 볼 수 있다. 다만 법률 업무에서는 시간이 줄었다는 사실보다 '중요한 리스크를 놓치지 않았는가'가 더 중요하다.

콘텐츠 검토: 정책을 실행 가능한 분류기로 바꾸기

콘텐츠 검토는 고객지원과 비슷해 보이지만 한 가지가 다르다. 고객지원은 사용자의 문제를 해결하는 일이지만, 콘텐츠 검토는 정책을 일관되게 적용하는 일이다. 커뮤니티 게시글, 리뷰, 광고 문구, 이미지, 채팅 메시지, 판매 상품 설명 등은 조직의 정책에 따라 허용, 제한, 차단, 보류, 사람 검토로 나뉜다.

Claude를 콘텐츠 검토에 쓸 때 가장 먼저 해야 할 일은 정책 문서를 '읽을 수 있는 규정'에서 '판정 가능한 기준'으로 바꾸는 것이다. 정책이 모호하면 Claude의 답도 모호해진다. 예를 들어 '공격적인 표현 금지'라는 정책은 너무 넓다. 어떤 표현이 모욕인지, 풍자인지, 인용인지, 혐오 발언인지, 신고 대상인지 구분해야 한다.

콘텐츠 검토 워크플로우는 다음처럼 설계할 수 있다.

중요한 것은 Claude에게 단순히 '이 콘텐츠가 정책 위반인가?'라고 묻지 않는 것이다. 대신 정책 기준을 함께 제공하고, 위반으로 판단한 근거 문구를 표시하게 하고, 신뢰도와 사람 검토 필요 여부를 출력하게 해야 한다.

좋은 출력 형식은 다음과 같다.

콘텐츠 검토에서 반드시 다뤄야 하는 문제는 편향이다. 특정 방언, 정치적 입장, 소수자 정체성, 풍자 표현이 과도하게 제한될 수 있다. 따라서 평가셋에는 평범한 위반 사례뿐 아니라 경계 사례가 들어가야 한다. 동일한 문장이 자기표현인지 공격인지, 뉴스 인용인지 선동인지, 피해 경험 공유인지 유해 조장인지 구분해야 한다.

또 하나의 핵심은 이의제기 흐름이다. AI가 잘못 분류했을 때 사용자가 설명을 들을 수 있어야 하고, 사람이 재검토할 수 있어야 한다. 콘텐츠 검토는 정확도만의 문제가 아니라 절차적 신뢰의 문제다. 사용자는 결과에 동의하지 않더라도, 어떤 기준으로 판단되었고 어떻게 이의제기할 수 있는지 알 권리가 있다.

운영 지표는 정밀도와 재현율을 함께 본다. 정밀도는 위반이라고 잡은 것 중 실제 위반의 비율이고, 재현율은 실제 위반 중 얼마나 잡았는지다. 정밀도만 높이면 위험 콘텐츠를 놓칠 수 있고, 재현율만 높이면 정상 콘텐츠를 과도하게 막을 수 있다. 여기에 사람 검토 비율, 이의제기 인용률, 특정 집단에 대한 오분류율, 정책 개정 후 회귀 실패율을 함께 봐야 한다.

연구·분석 업무: 재현 가능한 분석 노트를 남기는 AI 동료

연구와 분석 업무에서 Claude는 '똑똑한 검색창'보다 '분석 노트를 함께 쓰는 동료'에 가깝다. 시장 리서치, 투자 분석, 정책 분석, 학술 문헌 검토, 제조 현장 문제 분석은 모두 질문을 쪼개고, 자료를 찾고, 가설을 세우고, 근거를 비교하고, 한계를 남기는 과정이다.

연구 업무에서 Claude를 쓰는 좋은 방식은 결과물보다 과정을 구조화하는 것이다. 예를 들어 연구원이 '배터리 재활용 시장의 성장 가능성'을 조사한다고 하자. 곧바로 최종 보고서를 요청하지 말고 다음 순서로 진행한다.

여기서 '재현 가능한 노트'가 중요하다. Claude와 대화하다 보면 좋은 결론이 나온 것처럼 느껴지지만, 나중에 왜 그런 결론에 도달했는지 추적하기 어렵다. 그래서 연구·분석 업무에서는 질문, 사용 자료, 제외 자료, 판단 기준, 중간 결론, 반대 근거, 미확인 사항을 남겨야 한다.

분석 노트의 기본 구조는 다음과 같이 잡을 수 있다.

산업 현장에서도 같은 원리가 통한다. 한 제지 제조 현장 사례에서는 Claude API를 설비 매뉴얼, 운영 데이터, 자연어 질의응답과 연결해 작업자가 기술 문서와 생산 데이터를 대화형으로 조회하도록 설계했다. 공개된 사례는 Claude가 불확실성을 표현하고, 안전 관련 주의 문구를 포함하며, 검색과 데이터 질의를 결합한 점을 강조한다.⁷ 제조·의료·금융처럼 현장 판단의 비용이 큰 곳에서는 바로 이 태도가 중요하다. Claude가 모를 때 모른다고 말하고, 조치 전에 계측값이나 안전 절차를 확인하라고 안내해야 한다.

연구·분석 업무의 실패 패턴은 크게 세 가지다. 첫째, Claude가 만든 보고서가 너무 매끄러워서 근거 검토가 생략된다. 둘째, 검색된 자료의 품질이 낮은데도 결론이 확정된다. 셋째, 같은 분석을 다시 실행했을 때 다른 결과가 나오지만 그 차이를 설명할 기록이 없다. 이를 막으려면 분석 프롬프트에 '근거 수준', '반대 증거', '재현 절차'를 포함해야 한다.

예를 들어 다음과 같이 요청할 수 있다.

다음 8개 자료를 바탕으로 시장 진입 가능성을 분석하세요. 결론을 먼저 쓰지 말고, 자료별 핵심 주장과 근거 수준을 정리한 뒤, 서로 충돌하는 내용을 표시하세요. 마지막에는 임시 결론, 결론을 뒤집을 수 있는 반대 증거, 추가로 확인해야 할 데이터를 구분해 주세요.

이런 요청은 Claude에게 '멋진 결론'보다 '검토 가능한 사고 과정'을 요구한다. 연구와 분석에서 중요한 것은 정답처럼 보이는 문장이 아니라, 다른 사람이 검증하고 이어받을 수 있는 흔적이다.

산업별 빠른 적용 지도

이제 지금까지의 사례를 한눈에 정리해 보자. 아래 표는 업종보다 업무 유형에 초점을 맞춘 적용 지도다. 자신의 조직과 가장 가까운 줄을 찾고, 입력 자료와 검토자를 바꾸면 파일럿 설계의 출발점이 된다.

이 표에서 가장 먼저 고를 만한 파일럿은 세 조건을 만족하는 업무다. 반복 빈도가 높고, 원문 근거가 있으며, 사람이 최종 검토할 수 있어야 한다. 반대로 처음부터 완전 자동 결정, 고위험 법적 판단, 생명·안전 관련 실시간 제어, 대규모 개인정보 처리는 피하는 편이 좋다.

사례를 파일럿으로 바꾸는 1쪽 브리프

Claude 도입 논의는 쉽게 추상화된다. '문서 작업에 AI를 쓰자', '고객지원에 챗봇을 넣자', '개발 속도를 높이자' 같은 말은 방향은 좋지만 실행 계획이 아니다. 실제 파일럿으로 바꾸려면 1쪽 브리프가 필요하다.

브리프에는 다음 항목을 넣는다.

이 브리프의 힘은 제외 범위에 있다. AI 프로젝트는 무엇을 할지보다 무엇을 하지 않을지를 정할 때 안전해진다. 특히 운영 환경에서는 'Claude가 할 수 있는 일'과 'Claude에게 맡겨도 되는 일'이 다르다.

품질 모니터링: 사례마다 작은 평가셋을 만든다

산업별 사례는 멋진 데모로 시작할 수 있지만, 운영은 평가셋으로 유지된다. 고객지원 답변, 법률 요약, 콘텐츠 분류, 코드 리뷰, 연구 분석은 모두 시간이 지나며 문서와 정책과 제품이 바뀐다. 오늘 잘 맞는 프롬프트가 다음 달에도 맞는다는 보장은 없다.

따라서 각 사례에는 작은 평가셋을 붙여야 한다. 거창할 필요는 없다. 30개에서 100개 정도의 대표 사례만 있어도 프롬프트 변경, 모델 변경, 지식베이스 변경 때 회귀를 잡아낼 수 있다. 평가 방식은 업무에 따라 다르다. 분류 문제는 정답 라벨과 비교하고, 요약 문제는 사람 루브릭으로 평가하고, 코드 문제는 테스트와 리뷰를 통과해야 한다. LLM 평가는 확률적이기 때문에, 실무팀은 작은 골드셋과 자동 평가를 함께 쓰는 편이 안정적이다.⁸

사례별 평가 기준은 다음처럼 잡을 수 있다.

중요한 것은 평가가 처벌 도구가 아니라 학습 장치라는 점이다. Claude가 틀린 사례는 프롬프트, 검색 인덱스, 정책 문서, 사용자 교육 중 어디를 고쳐야 하는지 알려 주는 신호다. 오판 사례를 모아야 시스템이 좋아진다.

사람의 위치를 다시 설계하라

Claude를 도입하면 사람의 일이 사라지는 것이 아니라 위치가 바뀐다. 문서 작업자는 빈 페이지에서 시작하는 대신 초안을 검토한다. 개발자는 반복 코드를 직접 쓰는 대신 설계와 검증에 더 집중한다. 상담원은 모든 답변을 처음부터 쓰는 대신 예외와 감정적 상황을 처리한다. 변호사는 조항 찾기에 쓰던 시간을 협상 전략과 책임 있는 판단에 쓴다. 연구자는 자료 정리에 묶이는 시간을 줄이고 가설 검증에 집중한다.

이 변화가 성공하려면 조직은 사람을 'AI 결과를 받아쓰는 사람'으로 만들면 안 된다. 사람은 기준을 정하고, 예외를 판단하고, 책임을 진다. Claude는 초안을 만들고, 근거를 찾고, 반복 작업을 줄이고, 놓친 부분을 보여 준다. 둘의 경계가 흐려질수록 위험해진다.

가장 좋은 산업별 사례는 결국 같은 모습을 하고 있다. 업무의 병목이 분명하고, 입력 자료가 정리되어 있으며, 출력 형식이 정해져 있고, 사람 검토가 남아 있으며, 품질 지표가 측정된다. 이 다섯 가지가 있으면 업종은 크게 중요하지 않다. 제약 문서든, 자동차 판매 문구든, 보안 코드 리뷰든, 법률 계약서든 Claude는 같은 원리로 조직의 속도를 높일 수 있다.

다음 장에서는 이 사례들을 독자의 상황에 맞게 학습 트랙과 프로젝트로 바꾼다. 입문자는 문서 요약과 워크플로우 캔버스에서 시작하고, 개발자는 Claude Code와 API 프로젝트로 들어가며, 엔터프라이즈 도입자는 보안·평가·운영을 포함한 파일럿을 설계하게 될 것이다. 이 장에서 마음에 남은 사례 하나를 고르자. 다음 장의 프로젝트는 바로 그 사례에서 출발하면 된다.

참고

¹Guides to common use cases - Claude API Docs

²How enterprises are driving AI transformation with Claude

³Use Cases | Claude

⁴Claude Code Common Workflows: Explore, Debug, Refactor and Ship

⁵Legal summarization - Claude API Docs

⁶Claude for the legal industry

⁷Claude API in Industrial AI

⁸Evaluating Claude Performance: The Evals Guide