제8부 · 회사 도구와 연결하기
제7부에서 우리는 Claude에게 폴더를 맡기고 결과물을 받아 보았습니다. 그런데 한 번 떠올려 봅시다. 여러분 회사의 일감이 정말 내 컴퓨터 폴더 안에 다 들어 있습니까? 기획서는 Google Drive에, 회의록은 Notion에, 논의는 Slack에, 고객 문의는 Zendesk에 흩어져 있습니다. 지금까지는 사람이 그 자료를 하나하나 열어 복사하고 대화창에 붙여 넣었습니다. 이 부에서는 그 손품을 덜어 냅니다.
손품이 문제인 까닭은 시간 말고도 있습니다. 사람이 자료를 나르면 나르는 사람의 눈이 거름망이 됩니다. 바쁜 날에는 문서 세 개 가운데 하나만 붙이고, 어제 올라온 수정본을 모른 채 지난주 파일을 붙입니다. Claude의 답이 틀렸을 때 거슬러 올라가 보면, 잘못된 재료가 원인인 경우가 많습니다. 연결은 이 거름망을 줄이는 일입니다.
연결자(connector)는 Claude가 사내 도구에 직접 들어가 자료를 읽고, 허락한 범위 안에서 쓸 수 있게 해 주는 통로입니다. 이 부는 다음 순서로 진행합니다.
| 단계 | 다루는 것 | 손에 남는 것 |
|---|---|---|
| 64단계 · 연결자와 MCP, 모든 연결의 공통 규격 | 연결자와 MCP의 원리 | 연결할 후보 두 곳, 연결자별 읽기·쓰기 목록 |
| 65~69단계 | 문서 창고, 메일·일정, 메신저, 업무 도구, GitHub | 실제로 연결한 연결자와 검증된 프롬프트 |
| 70단계 · 읽기 권한과 쓰기 권한 | 읽기·쓰기·보내기의 경계 | 우리 팀 권한 표 |
| 71단계 · 연결이 안 될 때 | 막혔을 때 푸는 순서 | 관리자 요청 메일, 해결 기록 |
| 제8부를 마치며 | 제4편 결과물 발표 | 스킬 하나와 연결자 둘로 돌아가는 업무, 한 페이지짜리 인수인계서 |
전부 연결할 필요는 없습니다. 65~69단계 가운데 우리 회사가 실제로 쓰는 도구를 다룬 두 단계를 골라 끝까지 따라 하고, 나머지는 읽어만 두어도 됩니다. 영업 조직이라면 메일·일정과 문서 창고가, 개발 조직이라면 업무 도구와 GitHub가, 고객지원 조직이라면 업무 도구와 메신저가 먼저입니다.
미리 분명히 해 둘 것이 있습니다. 연결은 편해지는 만큼 위험도 커집니다. 읽기와 쓰기는 다른 일이고, 쓰기와 보내기는 또 다른 일입니다. 이 부의 프롬프트마다 끝에 "쓰지 마", "보내지 마"가 붙어 있는 것도 그래서입니다. 이 부의 고비는 70단계이고, 거기서 그은 선이 제9부 자동화의 안전장치가 됩니다.
이 부를 마치면 사내 도구 두 개와 연결된 Claude를 갖게 됩니다. 이 부를 마치는 자리에서는 제6부에서 만든 스킬 하나와 이 연결자 둘을 묶어, 실제로 돌아가는 업무 하나를 보여 줍니다.
화면의 메뉴 이름과 위치는 자주 바뀝니다. "설정에서 연결자 항목을 연다"처럼 적은 것은 대략의 위치로 받아들이면 됩니다. 버튼이 안 보이면 설정 화면을 한 번 둘러봅시다. 어느 요금제에서 어떤 연결자를 쓸 수 있는지도 자주 바뀌므로 이 책에는 요금제별 목록을 싣지 않았습니다. 쓰기 전에 공식 안내를 확인하기 바랍니다.
이 부의 단계
- 64연결자와 MCP, 모든 연결의 공통 규격복사해 붙이던 자료를 Claude가 직접 가서 읽게 하는 통로가 연결자이고, 그 통로를 한 가지 방식으로 잇는 규격이 MCP입니다.★★☆ 실무
- 65문서 창고 연결하기Google Drive·Notion에서 찾아 읽고 요약합니다.★★☆ 실무
- 66메일과 일정 연결하기받은 편지함과 일정을 읽어 오늘 할 일을 뽑습니다.★★☆ 실무
- 67메신저 연결하기Slack 채널의 논의를 요약하고 결정 사항만 모읍니다.★★☆ 실무
- 68업무 도구 연결하기Jira·Zendesk의 이슈와 문의를 분류합니다.★★☆ 실무 · 선택
- 69개발팀 저장소를 경영의 말로 읽기개발팀의 변경 기록이 쌓이는 저장소를 경영의 말로 읽게 합니다.★★☆ 실무 · 선택
- 70읽기 권한과 쓰기 권한읽기는 넓게, 쓰기는 좁게, 보내기는 확인한 뒤에.★★☆ 실무
- 71연결이 안 될 때로그인 만료, 관리자 승인, 권한 범위를 차례로 봅니다.★★☆ 실무
제8부를 마치며
이 부에서 한 일을 간추리면 이렇습니다. 사람이 나르던 재료를 Claude가 직접 가져오게 했고, 그 대신 무엇을 읽게 하고 무엇을 쓰게 하고 무엇을 사람이 보낼지 선을 그었습니다. 아래 여섯 항목에 모두 표시할 수 있으면 다음 부로 넘어갑니다.
- ☐ 내가 자주 복사해 붙이던 곳 두 곳을 연결자로 연결했습니다
- ☐ 연결자마다 "목록 먼저, 요약은 고른 뒤"로 시험하고 출처를 대조했습니다
- ☐ 연결자마다 읽기·쓰기·보내기 가운데 무엇을 허락했는지 표로 적었습니다
- ☐ 메일 발송·채널 게시·고객 답변·결제·삭제는 사람이 누른다는 원칙을 팀과 공유했습니다
- ☐ 막혔던 연결 하나를 로그인·관리자·범위 순서로 풀었거나 요청을 보냈습니다
- ☐ 스킬 하나와 연결자 둘로 돌아가는 업무를 발표하고, 인수인계서를 만들었습니다
제4편 결과물 발표
제6부부터 여기까지가 "시스템 구축" 과정이었습니다. 제6부에서 반복 업무를 스킬로 만들었고, 제7부에서 Claude에게 일을 맡기는 법을 익혔고, 이 부에서 사내 도구를 연결했습니다. 제4편은 이 세 가지가 한 업무 안에서 함께 돌아가는 모습을 남 앞에서 보여 주는 발표로 마무리합니다. 스킬 하나와 연결자 둘로 돌아가는 업무 하나를 시연하고, 그 업무를 옆 사람에게 넘길 한 페이지짜리 인수인계서를 함께 냅니다.
혼자 쓰는 요령은 쉽게 흐트러집니다. 바쁜 주에는 예전 방식으로 돌아가고, 한 달쯤 지나면 어떤 프롬프트를 썼는지도 잊어버립니다. 남 앞에서 돌려 보이려면 순서를 정리해야 하고, 한 번 정리한 순서는 기록으로 남습니다. 발표는 내 업무가 "나만 돌리는 요령"인지 "넘겨줄 수 있는 시스템"인지 가려내는 시험이기도 합니다.
좋은 발표 과제는 세 조건을 갖춥니다. 매주 또는 매일 하는 일이어야 하고, 재료가 두 곳 이상에 흩어져 있어야 하며, 결과물의 형식이 정해져 있어야 합니다.
| 후보 업무 | 반복 | 재료 두 곳 이상 | 형식이 정해짐 | 판단 |
|---|---|---|---|---|
| 주간 영업 보고 (Slack 영업 채널 + Drive 실적 파일) | 매주 | 예 | 보고 양식 있음 | 좋습니다 |
| 아침 할 일 정리 (메일 + 일정) | 매일 | 예 | 66단계의 세 부분 | 좋습니다 |
| 고객 문의 분류 (Zendesk + 도움말 문서) | 매일 | 예 | 기준표 | 좋습니다 |
| 신규 사업 아이디어 탐색 | 가끔 | 제각각 | 없음 | 발표에 맞지 않습니다 |
| 계약서 한 건 검토 | 가끔 | 한 곳 | 있음 | 연결자보다 업로드가 맞습니다 |
재료는 연결자가 가져오고, 형식은 스킬이 잡고, 사람은 숫자를 검토하고 판단을 더합니다. 발표는 세 부분으로 합니다. 먼저 전에는 이 일을 어떻게 했는지 한두 문장으로 말합니다. 다음으로 미리 만든 결과 대신 현장에서 실제로 돌려, Claude가 어느 연결자를 부르고 어느 스킬을 쓰는지 화면에 드러나게 합니다. 끝으로 사람이 확인하는 단계를 보여 줍니다. 무엇을 읽고, 무엇을 고치고, 무엇을 사람이 보내는지.
준비 과정에서는 같은 부탁을 처음부터 끝까지 세 번 돌려 봅니다. 세 번 모두 같은 항목, 같은 순서로 나오고 숫자가 원본과 맞아야 합니다. 화장품 브랜드의 임 팀장은 주간 영업 보고로 리허설을 하다가 숫자는 지난주 파일에서 오고 항목 순서는 돌릴 때마다 바뀌는 일을 겪었습니다. 숫자가 틀린 것은 재료 문제라 부탁하는 말에 "이번 주 날짜가 붙은 파일만, 읽기 전에 파일 이름을 먼저 보여 줘"를 넣었고, 항목이 흔들린 것은 형식 문제라 스킬의 출력 형식에 항목 이름과 순서를 못 박았습니다. 발표 날 옆 팀장이 "우리 팀에도 쓰고 싶다"고 하자 인수인계서를 건넸고, 그 팀장은 다음 주에 Slack 채널 이름만 바꿔 돌렸습니다. 남에게 넘겨도 돌아갔으니 시스템이라고 부를 만했습니다.
합격 기준은 하나입니다. 다른 사람이 그 결과물을 받아 다음 주에 그대로 쓸 수 있습니까? 스킬은 조직에 공유할 수 있으니, 넘겨받는 사람이 스킬을 설치하는 방법까지 인수인계서에 적습니다. 인수인계서는 아래 프롬프트로 만듭니다.
제4편 결과물 발표용 인수인계서를 한 페이지로 만들어 줘. 아래 내용을 표와 짧은 문장으로 정리해.
- 업무 이름: [업무]
- 전에는: [예전 방식 한두 문장, 어디서 자주 틀렸는지]
- 쓰는 스킬: [스킬 이름]과 그 스킬이 정하는 결과물 형식
- 쓰는 연결자: [연결자 1]에서 [가져오는 것], [연결자 2]에서 [가져오는 것]
- 부탁하는 말: [실제로 입력하는 문장]
- 사람이 확인하는 단계: [무엇을 읽고, 무엇을 고치고, 무엇을 직접 보내는지]
- 넘겨받는 사람이 할 일: 스킬 설치, 연결자 연결, 확인 규칙
마지막에 "다른 사람이 다음 주에 그대로 쓰려면 빠진 것"을 네가 점검해서 목록으로 붙여.
내가 적지 않은 기능이나 숫자는 지어내지 마.
| 증상 | 원인 | 처방 |
|---|---|---|
| 돌릴 때마다 결과의 항목이 달라집니다 | 스킬의 출력 형식이 느슨합니다 | 항목 이름과 순서, 빈 항목 처리 규칙을 스킬에 못 박습니다 |
| 숫자가 지난주 것입니다 | 재료의 범위를 정하지 않았습니다 | 부탁하는 말에 날짜 조건을 넣고, 읽을 파일 목록을 먼저 보게 합니다 |
| 발표 도중 연결이 끊겼습니다 | 로그인 만료 등(71단계) | 미리 받아 둔 결과 화면으로 넘어가고, 끝난 뒤 원인을 적습니다 |
| 옆 사람이 인수인계서만으로는 못 돌립니다 | 내 머릿속에만 있는 단계가 있습니다 | 옆 사람이 돌리는 것을 지켜보며 막힌 곳을 인수인계서에 더합니다 |
발표를 듣는 쪽에도 할 일이 있습니다. 다른 사람의 업무를 보며 "우리 팀에도 이런 모양의 일이 있다"를 하나씩 적습니다. 영업 보고와 생산 보고는 재료가 달라도 모양이 같습니다. 특히 "매번 같은 시각에 같은 부탁을 하는" 업무는 제9부에서 예약 실행으로 넘길 첫 후보입니다.
이 부의 과제
과제 이름: 연결자 둘과 스킬 하나로 돌아가는 업무 한 건
하는 일: 내 업무 가운데 반복되고, 재료가 두 곳 이상에 흩어져 있고, 결과물 형식이 정해진 일 하나를 고릅니다. 그 재료가 있는 사내 도구 둘을 연결자로 연결하고, 제6부에서 만든 스킬 하나로 형식을 잡아, 한 번의 부탁으로 결과물이 나오게 합니다. 완성한 업무는 위 「제4편 결과물 발표」대로 남 앞에서 돌려 보이고, 옆 사람에게 넘길 인수인계서를 함께 냅니다.
제출물
| 번호 | 제출물 | 담을 것 |
|---|---|---|
| 1 | 권한 표 | 연결한 연결자별 읽기·쓰기·보내기 상태, 범위에서 뺀 공간, 항상 사람이 누르는 일 |
| 2 | 검증 기록 | 연결자마다 출처 대조 세 건의 결과(맞음/틀림, 틀렸다면 고친 방법) |
| 3 | 인수인계서(한 페이지) | 업무 이름, 전에는, 쓰는 스킬, 쓰는 연결자, 부탁하는 말, 사람이 확인하는 단계, 넘겨받는 사람이 할 일(스킬 설치, 연결자 연결, 확인 규칙). 「제4편 결과물 발표」의 프롬프트로 만듭니다 |
| 4 | 결과물 세 벌 | 같은 부탁으로 세 번 돌린 결과(날짜가 다르면 더 좋습니다) |
| 5 | 발표 | 전에는 → 실제로 돌리기 → 사람이 확인하는 단계, 세 부분. 다른 사람의 발표에서 고른 제9부 자동화 후보 하나를 함께 적습니다 |
완료 기준
- 결과물 세 벌이 같은 항목, 같은 순서로 나왔고, 숫자와 사실이 원본과 맞습니다.
- 권한 표에 "모름"으로 남은 항목이 없고, 보내기 층에 예외가 없습니다.
- 기밀 등급이 높은 공간이 연결 범위에서 빠져 있습니다.
- 동료 한 명이 인수인계서만 받아, 내 도움 없이 한 번 돌려 결과물을 얻었습니다.
- 발표에서 사람이 확인하는 단계를 보여 주었습니다.
하지 않을 것: 발표를 위해 연결자에 보내기 권한을 여는 일, 회사 규칙이 허용하지 않은 자료를 연결 범위에 넣는 일, 미리 만든 결과를 실제로 돌린 것처럼 보여 주는 일.
이것으로 제4편을 마칩니다. 다음 제5편의 첫머리인 제9부의 주제는 자동화입니다. 지금까지는 내가 부탁해야 Claude가 움직였습니다. 제9부에서는 정해진 시각이나 새 메일, 새 파일 같은 신호에 맞춰 흐름이 저절로 돌게 만듭니다. 이 부에서 연결한 연결자가 재료를 대고, 제6부의 스킬이 형식을 잡습니다. 이 부의 과제에서 세 번 같은 형식으로 나온 업무가 첫 자동화 후보입니다. 그리고 70단계에서 그은 선, 곧 보내기 앞에는 반드시 사람이 있다는 원칙은 자동화 설계도에도 그대로 들어갑니다. 사람이 부탁하지 않아도 돌아가는 흐름일수록 그 원칙은 더 단단해야 합니다.