68단계업무 도구 연결하기

걸리는 시간 · 읽기 약 10분 · 따라 하기 약 45분 · 난이도 ★★☆ 실무 · 처음엔 건너뛰어도 되는 단계 · 화면 확인 2026.09.27

이 단계를 마치면

• 우리 팀의 분류 기준표를 한 페이지로 정리할 수 있습니다.
• Jira나 Zendesk를 연결해, 쌓인 건을 기준표대로 분류한 표를 받습니다.
• 분류가 믿을 만한지 대조해 확인하고, 도구 안에서 쓰기를 허용할 시점을 판단합니다.

월요일 아침, 고객지원팀 문의함을 열면 주말 동안 쌓인 문의가 한꺼번에 밀려듭니다. 업무 도구에는 처리할 건이 늘 줄지어 쌓입니다. 개발팀의 Jira에는 이슈가, 고객지원팀의 Zendesk에는 문의가 있습니다. 하나씩 읽고, 종류를 나누고, 누구에게 넘길지 정하는 일이 매일 되풀이됩니다. 이런 분류는 Claude가 잘하는 일입니다. 글을 읽고 정해진 범주에 넣는 일이기 때문입니다.

연결하기

Jira는 Atlassian 연결자로, Zendesk는 Zendesk 연결자로 연결합니다. Atlassian 연결자는 Confluence 문서도 함께 읽을 수 있어서, 이슈를 보면서 관련 기획 문서를 찾는 식으로 쓸 수 있습니다. 두 서비스 모두 회사 관리자가 연결을 관리하는 경우가 많습니다.

기준표가 곧 품질이다

분류를 맡길 때는 기준을 내가 줍니다. "알아서 분류해 줘"라고 하면 Claude가 그럴듯한 기준을 만들어 내지만, 그 기준이 우리 팀의 기준과 같다는 보장은 없습니다. 더 큰 문제는 기준이 매번 달라질 수 있다는 점입니다. 같은 결제 오류 문의를 월요일에는 "환불"로, 화요일에는 "기술 문제"로 넣으면 주간 통계가 무너집니다.

좋은 기준표에는 분류 이름과 함께 정의와 경계가 적혀 있습니다.

핵심은 "파손은 도착 후라도 배송에 넣는다" 같은 경계 문장입니다. 사람끼리도 분류가 엇갈리는 곳은 언제나 경계입니다. 경계를 적어 두면 Claude와 신입 팀원이 같은 답을 냅니다. 이 기준표를 제6부에서 배운 대로 스킬로 만들어 두면 매번 붙여 넣지 않아도 됩니다.

기준표를 만드는 순서

기준표는 책상에 앉아 머리로만 쓰면 잘 안 됩니다. 경계는 실제 사례에서 나오기 때문입니다. 다음 순서를 따릅니다.

1. 지난 건 가운데 스무에서 서른 개쯤을 뽑습니다. 쉬운 건만 고르지 말고, 처리하면서 고민했던 건을 일부러 섞습니다.
2. 팀원 둘이 서로 보지 않고 따로 분류합니다. 분류 이름만 정해 주고 정의는 아직 주지 않습니다.
3. 두 사람의 분류가 엇갈린 건만 모아 놓고 왜 달랐는지 말로 설명합니다. 그 설명이 바로 경계 문장이 됩니다. "나는 파손을 상품 문제로 봤는데, 너는 배송 중에 생긴 일로 봤구나. 우리는 배송으로 하자."
4. 이렇게 만든 기준표를 Claude에게 주고 같은 건들을 분류하게 합니다. 사람 둘은 같은데 Claude만 다르게 넣은 건이 있다면, 기준표가 사람들 머릿속의 말하지 않은 약속에 기대고 있다는 신호입니다. 그 약속을 문장으로 꺼내 기준표에 적습니다.

여기서 흔한 오해 하나를 풀고 넘어갑시다. 사람끼리도 엇갈리는 건을 Claude가 맞혀 주리라 기대하는 것입니다. 사람 둘이 엇갈린 건에서 Claude가 어느 한쪽과 달랐다면, 그 건에는 아직 정답이 없습니다. Claude를 탓할 일이 아닙니다. 이때는 프롬프트의 말투를 다듬어 봐야 소용이 없고, 기준표를 고쳐야 합니다.

대화창에서 먼저, 도구 안에는 나중에

분류 결과를 도구에 직접 반영하는 일, 즉 이슈 상태를 바꾸거나 담당자를 지정하는 일은 처음에는 맡기지 않습니다. 대화창에서 분류표를 받고, 며칠 동안 사람이 맞춰 본 뒤 믿을 만하다고 판단되면 그때 쓰기를 검토합니다.

부서별 변형

• 개발팀(Jira): 분류보다 "중복 찾기"가 쓸모 있습니다. 새 이슈마다 비슷한 기존 이슈를 붙여 달라고 합니다. Confluence의 기획 문서와 이슈가 어긋나는 곳을 찾게 할 수도 있습니다.
• 고객지원(Zendesk): 분류와 답변 초안을 함께 받습니다. 초안에 쓸 근거는 사내 도움말 문서로 한정합니다.
• 운영·경영: 분류된 결과로 주간 추세를 봅니다. "지난주보다 늘어난 분류와 그 대표 사례 셋"을 묻습니다.

업종에 따라서도 기준표의 모양이 달라집니다.

• 기업 고객을 상대하는 소프트웨어 회사: 고객 문의 하나가 버그 신고이면서 기능 요청인 경우가 많습니다. Zendesk 문의를 분류할 때 Jira에 같은 내용의 이슈가 이미 있는지 함께 찾게 합니다. 두 연결을 한 대화에서 켜 두면 됩니다.
• 제조·설비의 사후 관리: 분류 기준이 두 가지입니다. 어떤 제품인가, 어떤 증상인가. 모델명 목록을 기준표에 붙여 두지 않으면 비슷한 모델명을 섞어 읽습니다.
• 교육·예약 서비스: 같은 문의라도 시점에 따라 분류가 달라집니다. 수업이나 예약일 전인지 후인지를 기준표의 경계 문장에 넣습니다.

한 걸음 더: Hugging Face 연결하기

업무 도구 가운데 성격이 조금 다른 곳이 하나 있습니다. Hugging Face는 전 세계 연구자와 기업이 만든 AI 모델, 공개 데이터셋, 논문, 그리고 모델을 바로 써 볼 수 있는 작은 웹 앱(Space)을 모아 둔 곳입니다. 개발팀이나 데이터팀이 "이 일에 맞는 모델이 이미 나와 있나", "학습에 쓸 만한 공개 데이터가 있나"를 찾을 때 가장 먼저 들르는 곳이기도 합니다. Hugging Face는 MCP 서버를 공개하고 있어서 Claude에 연결할 수 있습니다.

연결하면 대화창에서 이런 부탁이 가능해집니다.

연결 순서는 다른 연결자와 같습니다. Claude 앱의 연결자 목록에서 Hugging Face를 찾아 추가하고, Hugging Face 계정으로 로그인해 허락합니다. 목록에서 보이지 않으면 64단계에서 본 대로 MCP 서버 주소(https://huggingface.co/mcp)를 사용자 지정 연결자로 넣습니다. Claude Code에서는 터미널에서 claude mcp add --transport http hf https://huggingface.co/mcp처럼 등록한 뒤, 세션 안에서 /mcp로 로그인과 연결 상태를 확인합니다. Hugging Face 계정의 설정 화면에서 Claude가 쓸 도구와 Space를 고를 수 있습니다. 메뉴 이름과 등록 명령은 버전에 따라 바뀌니 양쪽 공식 안내를 한 번 확인합니다.

주의할 점은 세 가지입니다. 첫째, 라이선스입니다. 공개되어 있다고 모두 회사에서 써도 되는 것은 아닙니다. 모델과 데이터셋마다 상업적 이용 허용 여부가 다르니, Claude에게 비교표를 받을 때 라이선스 열을 반드시 넣고 원문 페이지에서 한 번 더 확인합니다. 둘째, Space에 넣는 자료입니다. Space는 남의 서버에서 돌아가는 공개 앱입니다. 회사 문서나 고객 정보를 Space에 넣는 것은 외부 서비스에 올리는 것과 같으니 7단계의 기준을 그대로 적용합니다. 셋째, 쓰임새의 범위입니다. 이 연결은 찾고 비교하고 요약하는 데서 가장 쓸모가 큽니다. 찾은 모델을 실제 업무 시스템에 붙이는 일은 96단계처럼 개발팀과 요청서를 주고받으며 진행합니다.

기준표는 한 번 만들면 끝일까요? 한 쇼핑몰 고객지원팀장은 한 달 만에 그 답을 얻었습니다.

현장 장면

온라인 쇼핑몰 고객지원팀의 서 팀장은 아침마다 밤사이 들어온 문의를 배송·환불·상품·계정·기타로 나눕니다. Zendesk를 연결한 Claude에게 처음에는 분류 이름 다섯 개만 주고 맡겨 보았습니다. 결과표의 상당수는 서 팀장의 판단과 같았습니다. 하지만 파손 문의는 배송과 상품 사이를 오락가락했고, "교환하고 싶다"는 문의는 환불로 들어갔습니다.

서 팀장은 팀원 둘과 머리를 맞대고 기준표에 경계 문장을 넣었습니다. 파손은 배송, 교환은 상품. 다음 날 같은 방식으로 돌리자 오락가락이 눈에 띄게 줄었습니다. 남은 오류는 한 문의에 요청이 두 가지 섞인 경우였습니다. "배송이 늦는데, 늦을 거면 환불해 주세요." 서 팀장은 규칙을 하나 더했습니다. "요청이 둘이면 돈이 걸린 쪽으로 분류하고 근거란에 둘 다 적어."

이제 Claude는 분류와 함께 답변 초안까지 쓰고, 팀원들은 그 초안을 고쳐 보내는 것으로 하루를 시작합니다. 다만 "환불" 건만큼은 초안이 있어도 반드시 사람이 규정을 확인하게 했습니다. 돈이 나가는 일이기 때문입니다. 기준표는 스킬로 만들어 팀 전체가 같은 것을 씁니다.

한 달쯤 지나 표 아래 분류별 건수에서 이상한 점이 눈에 띄었습니다. "기타"가 조금씩 늘고 있었습니다. 기타 건을 모아 읽어 보니 대부분 새로 시작한 정기배송 서비스의 해지·변경 문의였습니다. 기준표를 만들 때는 없던 유형이라 어디에도 들어맞지 않았던 것입니다. Claude는 기준표대로 정확히 일했을 뿐입니다. 서 팀장은 "정기배송" 분류를 새로 만들고 경계 문장을 붙였습니다. "정기배송의 배송 지연은 배송에, 해지·주기 변경은 정기배송에." 그리고 기준표 맨 아래에 고친 날짜를 적었습니다. 주간 건수를 비교할 때 분류가 바뀐 날을 알아야, 숫자가 실제로 늘었는지 분류가 나뉘었을 뿐인지 구분할 수 있기 때문입니다.

따라 하기

1. 회사가 쓰는 업무 도구(Jira, Zendesk 등)의 연결자를 연결합니다. 성공 기준: 내가 평소 보는 프로젝트나 문의함의 최근 건 하나를 Claude가 제목 그대로 찾아옵니다.
2. 우리 팀의 분류 이름과 정의를 하나씩 적고, 헷갈리는 곳마다 경계 문장을 붙입니다. 성공 기준: 분류마다 정의가 있고, 경계 문장이 두 개 이상 있습니다.
3. 아래 프롬프트에 기준표를 넣고 최근 건들을 분류하게 합니다. 성공 기준: 모든 건에 분류와 근거가 붙어 있습니다.
4. 결과 가운데 열 건 정도를 무작위로 골라 내 판단과 대조합니다. 성공 기준: 틀린 건의 수와 틀린 유형을 적었습니다.
5. 틀린 건이 있으면 기준표의 어느 정의가 모호했는지 찾아 고치고 다시 돌립니다. 성공 기준: 같은 유형의 오류가 다시 나오지 않습니다.
6. (선택 심화) 나, 팀원 한 명, Claude가 같은 스무 건을 서로 모르게 분류하고 세 결과를 나란히 놓습니다. 성공 기준: 셋이 엇갈린 건마다 원인을 "기준표가 모호함", "사람끼리도 판단이 다름", "Claude가 잘못 읽음" 가운데 하나로 적었고, 앞의 두 원인에는 경계 문장을 하나씩 새로 붙였습니다.

복사해 쓰는 프롬프트

[Jira 프로젝트 이름 / Zendesk]에서 [기간] 동안 들어온 [이슈 / 문의] 가운데
[상태 조건, 예: 아직 담당자가 없는 것]을 읽어 줘.

아래 기준표대로 분류해.
- [분류 1]: [정의]. [경계 문장]
- [분류 2]: [정의]. [경계 문장]
- [분류 3]: [정의]
- 기타: 위 어디에도 맞지 않는 것
요청이 둘 이상 섞여 있으면 [우선 규칙, 예: 돈이 걸린 쪽]으로 분류하고 근거란에 둘 다 적어.

출력은 표로. 열은 번호, 제목, 분류, 근거(짧게), 긴급도(높음/보통/낮음), 권장 담당.
어느 분류인지 확신이 없으면 근거란에 "확인 필요"라고 써.
표 아래에 분류별 건수를 붙여.
도구 안의 상태·담당자·댓글은 바꾸지 마. 고객에게 아무것도 보내지 마. 결과는 대화창에만.

막히면 이렇게

스스로 점검

• ☐ 기준표에 경계 문장이 두 개 이상 있습니다.
• ☐ 분류 결과 열 건 정도를 내 판단과 대조하고 틀린 유형을 적었습니다.
• ☐ 도구 안에서 쓰기를 허용하기 전에 거쳐야 할 단계를 말할 수 있습니다.

기억할 것

• 분류 기준은 우리가 정해 줍니다. 기준표가 곧 품질입니다.
• 오류는 경계에서 생깁니다. 기준표에는 이름보다 경계를 적습니다.
• 도구 안의 상태를 바꾸는 쓰기는 분류를 믿을 수 있게 된 뒤에 엽니다.

더 알아보기 · Hugging Face MCP 설정 · Claude Code MCP 연결