66단계업무 도구 연결하기

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

이 단계를 마치면

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

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

연결하기

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

기준표가 곧 품질이다

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

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

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

기준표를 만드는 순서

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

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 계정으로 로그인해 허락한다. 목록에서 보이지 않으면 62단계에서 본 대로 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에 넣는 것은 외부 서비스에 올리는 것과 같으니 8단계의 기준을 그대로 적용한다. 셋째, 쓰임새의 범위다. 이 연결은 찾고 비교하고 요약하는 데서 가장 쓸모가 크다. 찾은 모델을 실제 업무 시스템에 붙이는 일은 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 연결