매주 30분 걸리던 주간 보고를 3분으로 줄인 이야기 — Claude Code Skill 자동화 후기

AX(AI Transformation) 시리즈 1편.
일하는 방식을 LLM 기반으로 다시 짜본 사례를 모아 봅니다. 첫 글은 PM 업무에서 가장 자주 반복되는
"주간 고객사 보고"를 자동화한 과정을 담았습니다.

안녕하세요. B2B 프로젝트 PM으로 일하고 있습니다.

매주 반복되는 보고 업무가 익숙하지만 결코 가볍지 않으신 분, 자동화에 관심은 있지만 "코드를 잘 짜지 않아서 망설여진다"는 분들께 이 글이 도움이 되었으면 합니다.

처음 시작할 때 저는 Claude Code의 Skill 기능을 한 번도 써본 적이 없었습니다. 그게 정확히 무엇인지조차 잘 몰랐고요. 그래도 클로드에게 공식 문서 링크를 던지면서 "이거부터 읽어봐"로 시작했고, 5번의 실패를 거쳐 매주 30분 걸리던 일을 3분으로 줄였습니다. 이 글에는 그 과정을 실패까지 솔직하게 담았습니다.

---

0. 출발점 — 왜 자동화를 시작했나요?

B2B 프로젝트 PM을 맡고 있습니다. 매주 한 번 고객사에 진행상황을 서면으로 공유하는 업무가 있는데요. 보고서 내용 자체는 어렵지 않습니다.

• 핵심 산출물 진행 현황 (완료/진행/대기 건수)
• 이번 주 주요 작업
• 이슈와 리스크
• 다음 주 계획

문제는 정보가 한 곳에 모여 있지 않다는 점입니다.
한 주치 컨텍스트를 읽는데 

(10개 슬랙 채널에 흩어져 있고요. 산출물 적재 채널, B2B 프로젝트 채널, 고객사 공유 채널을 거슬러 올라가며 메시지를 읽고, 분류하고, 고객사 톤으로 다시 옮기는 과정이 필요했습니다. 한 번 작성하는 데 )

30분이 걸렸어요.

매주 30분이면 작은 시간이 아닙니다. 더 본질적인 일에 시간을 쓰고 싶었고, 마침 Claude Code의 Skill 기능을 한 번도 안 써봤던 참이라 이번에 처음 만들어보기로 했습니다.

1. 처음엔 Skill이 뭔지도 몰랐습니다

시작은 공식 문서 링크를 클로드에게 던지고 "이거 읽어봐"였습니다. PM이라 직접 코드를 많이 짜지는 않고, "Claude Code의 Skill"이 뭔지 정확한 정의도 몰랐어요. 단순한 슬래시 커맨드인지, 별도 워크플로우 엔진인지, 자동 트리거가 되는지조차 헷갈렸습니다.

클로드가 정리해준 핵심은 이랬습니다.

Skill이란?

• SKILL.md라는 파일 하나로 반복 작업 절차를 패키징하는 기능
• CLAUDE.md와 다른 점은 호출 시점에만 컨텍스트로 로드된다는 것 (토큰 비용 절약)
• /skill-name으로 직접 호출하거나 Claude가 자동 판단해서 호출
• frontmatter에 메타데이터 (description, allowed-tools, disable-model-invocation 등)
• shell 명령을 미리 실행해서 결과를 끼워넣는 동적 컨텍스트 주입 기능

문서를 한 번에 다 이해한 건 아닙니다. 만들어가면서 모르는 게 나올 때마다 그때그때 물어봤어요.

2. 설계 원칙 — 3-layer로 쪼개기

자동화를 시작할 때 먼저 정한 건 "한 덩어리로 짜지 않는다"였습니다. 외부 의존성이 많은 작업은 단계마다 막히는 지점이 다르고, 한 곳이 안 돼도 나머지는 살아 있어야 하거든요. 그래야 뭐라도 건집니다.

레이어	역할	도구 후보
A. 보고서 생성	슬랙 채널 분석 → 보고서 초안 작성	Claude Code Skill
B. 자동 실행	매주 정해진 시각에 A 실행 + DM 전송	Claude Code Remote Routine
C. 알림	시간 기반 알림 (B 실패 대비)	macOS launchd / Reminders

결과적으로 B가 막혔는데도 A와 C만 살려서 70%는 건졌습니다. 처음부터 한 덩어리로 짰다면 어느 한 곳에서 막히는 순간 다 무너졌을 거예요.

3. Layer A — 첫 Skill 만들기

클로드와 핑퐁하면서 헷갈렸던 것들

먼저 어떤 스킬을 만들지부터 클로드가 질문해줬습니다. 자동 호출 vs 수동 호출, 어디에 저장(개인용/프로젝트용), 인수 필요 여부, 동적 컨텍스트 주입 사용 여부. 이 중 인수와 동적 컨텍스트 주입은 무슨 말인지 몰랐어요.

"예: /my-skill 123 처럼 값을 넘길지 — 이게 무슨 말인지 모르겠어 설명해줘"

이렇게 솔직하게 물어봤습니다. 클로드 답변을 정리하면 인수는 스킬을 호출할 때 추가 값을 같이 넘기는 기능입니다. /주간보고처럼 인수 없이 매번 같은 동작을 할 수도 있고, /주간보고 2026-05-01 2026-05-14처럼 시작일/종료일을 매번 다르게 줄 수도 있어요.

이번 케이스는 "기간을 매주 자동으로 최근 7일"로 잡으면 인수가 필요 없었습니다. 그래서 인수 없이, 대신 동적 컨텍스트 주입(! 문법)으로 날짜를 자동 치환하는 쪽으로 정했어요.

또 헷갈렸던 디렉토리 구조

기존 ~/.claude/skills/ 폴더를 보니 .md 파일들이 그냥 들어가 있었습니다. 그런데 클로드가 만들어준 건 ~/.claude/skills/<skill-name>/SKILL.md 디렉토리 형식이었어요. 어느 게 표준인지 헷갈려서 또 물어봤습니다.

답은 — 디렉토리 형식이 정식이고, 단일 .md는 구식 호환 포맷이었어요. frontmatter나 지원 파일을 쓰려면 디렉토리 형식이어야 합니다.

완성된 SKILL.md

~/.claude/skills/customer-weekly/SKILL.md:

---
name: customer-weekly
description: 고객사에 보낼 주간 진행상황 보고서 초안을 슬랙 채널 분석을 통해 작성한다.
disable-model-invocation: true
allowed-tools: mcp__slack__slack_list_channels mcp__slack__slack_get_channel_history mcp__slack__slack_get_thread_replies mcp__slack__slack_get_user_profile
---

# 주간 진행상황 보고서 작성

## 기간
- 시작일: !`date -v-7d +%Y-%m-%d`
- 종료일: !`date +%Y-%m-%d`

## 역할 설정
- 너는: 프로젝트 총괄 책임자 PM
- 독자: 고객사 팀장
- 목적: 이번 주 진행상황을 서면으로 공유

## 작업 순서
1. 채널 식별 (고정 채널 + 키워드 자동 탐색)
2. 메시지 수집 (최근 7일)
3. 분류 (산출물 진행 / 작업 / 이슈 / 다음 주)
4. 슬랙 마크다운 형식 보고서 작성

## 작성 가이드라인
- PM 톤: 정중하지만 명확
- 고객 관점: 내부 약어/농담 제거
- 수치 우선: "많이 진행됨" 대신 구체 건수
- 출처 근거: 슬랙 메시지 기반
- 분량: 슬랙 한 메시지로 읽힐 정도

만든 직후 또 물어봤습니다. "이 스킬은 수동 호출인가요? 특정 날짜에 자동으로 알림이 가나요?"

답은 — 이 스킬 자체는 수동 호출만 합니다 (disable-model-invocation: true). 매주 자동 알림이 가게 하려면 별도 스케줄링이 필요해요. 그래서 Layer B와 C가 필요해진다는 걸 그제야 이해했습니다.

4. SKILL.md 프롬프트 엔지니어링 — 5가지 구성 요소

만들면서 가장 시간을 많이 쓴 건 프롬프트 자체였습니다. "보고서 만들어줘" 한 줄로는 결과가 매번 다르게 나오거든요. 클로드와 핑퐁하면서 다듬다 보니 좋은 SKILL.md에는 다섯 가지가 들어가야 한다는 게 보였습니다.

(1) description — 자동 호출 트리거이자 자기 명함

description: 고객사에 보낼 주간 진행상황 보고서 초안을 슬랙 채널 분석을 통해 작성한다.

description은 두 가지 역할을 합니다. Claude가 "지금 이 스킬을 자동으로 써야 하나?"를 판단하는 기준이자, 동시에 / 메뉴에서 사용자가 보는 설명이기도 해요.

처음엔 "주간 보고 자동화"처럼 한 줄로 짧게 썼다가 너무 막연해서 다시 풀어 적었습니다. 목적어, 행위, 산출물 셋이 들어가니 검색성이 좋아졌어요.

(2) 역할 부여 (Persona)

## 역할 설정
- 너는: 프로젝트 총괄 책임자 PM
- 독자: 고객사 팀장
- 목적: 이번 주 진행상황을 서면으로 공유

LLM에게 역할을 명시하면 출력 톤이 일관되게 잡힙니다. 핵심은 "독자가 누구인가"를 적어주는 거예요. 같은 진행상황도 내부 개발자에게 쓸 때와 고객사 팀장에게 쓸 때 어휘 자체가 달라집니다.

이 항목을 빼면 LLM이 "기술적으로 정확하면서 친근한 톤"이라는 무난한 디폴트로 흘러갑니다. 그러면 고객사 톤이 안 나와요.

(3) 작업 순서 (Stepwise instructions)

## 작업 순서
1. 채널 식별 (고정 채널 + 키워드 자동 탐색)
2. 메시지 수집 (최근 7일)
3. 분류 (산출물 진행 / 작업 / 이슈 / 다음 주)
4. 슬랙 마크다운 형식 보고서 작성

순서를 명시하면 단계를 건너뛰지 않습니다. 처음엔 "슬랙을 분석해 보고서를 작성한다"라고만 적었는데요. 그랬더니 채널을 1~2개만 보고 결론을 내려버리는 일이 있었습니다. 단계별로 분리한 뒤로는 매번 같은 채널 세트를 빠짐없이 훑었어요.

(4) 출력 형식 템플릿

*[주간 진행상황] {시작일} ~ {종료일}*

안녕하세요 고객사 팀장님,
지난 한 주간 프로젝트 진행 상황을 공유드립니다.

━━━━━━━━━━━━━━━━━━
*1. 산출물 진행 현황*
• (구체적 수치/상태)
...

"예쁜 보고서 만들어줘"라고 하면 매번 다른 모양이 나옵니다. 슬랙 마크다운을 그대로 보여주고 빈칸만 채우게 하면 100% 같은 형태로 나와요.

💡 모호함을 줄이는 가장 빠른 방법은 골격째로 박아두는 것입니다.

(5) 가이드라인 (Constraint)

- PM 톤: 정중하지만 명확. 추측이나 모호한 표현은 피한다
- 고객 관점: 내부 용어/약어는 풀어서 설명. 슬랙에서 쓰던 농담/이모티콘은 제거
- 수치 우선: "많이 진행됨" 대신 구체적인 건수/비율을 쓴다
- 출처 근거: 각 항목은 실제 슬랙 메시지에 근거. 없으면 "해당 사항 없음"으로 명시
- 분량: 슬랙 한 메시지로 읽힐 정도로 핵심만

가이드라인은 "이런 출력은 거부한다"의 모음이에요. 특히 출처 근거 한 줄이 핵심인데요. 이게 없으면 LLM이 슬랙에 없는 내용을 추정으로 만들어냅니다. "메시지가 없으면 '해당 사항 없음'으로 명시"라는 출구를 명시적으로 열어주면 추정 대신 솔직히 비워두고요. 이 한 줄을 추가하고 hallucination이 거의 사라졌습니다.

동적 컨텍스트 주입

- 시작일: !`date -v-7d +%Y-%m-%d`  → 자동으로 2026-05-07
- 종료일: !`date +%Y-%m-%d`        → 자동으로 2026-05-14

매주 날짜를 직접 박아 넣지 않아도 됩니다. shell이 먼저 돌고 결과로 치환되니까요. 이 기능을 처음 들었을 때는 "그게 무슨 말이냐"고 다시 물어봤어요. 알고 보니 단순한데 이름이 좀 어렵습니다.

도구 사전 승인

allowed-tools에 슬랙 MCP 도구를 미리 적어두면 실행 시 권한 요청 없이 바로 호출됩니다. 자동화 흐름에서 사용자 승인 클릭은 의외로 큰 마찰이에요. 4개 도구 호출에 매번 클릭이 필요했다면 "자동화"가 아니라 "반자동 클릭 게임"이 됐을 겁니다.

첫 실행

/customer-weekly 입력 → 3개 채널 분석 → 50개 메시지 수집 → 4-섹션 보고서 초안 출력까지 약 1분. 처음에 사양만큼 잘 나와줘서 좀 놀랐습니다. 여기까지는 순조로웠어요.

5. Layer B — Remote Routine에서 막힌 순간

Layer A가 작동하니 다음은 자동 실행이었습니다. 클로드가 "Remote Routine이라는 게 있어"라고 알려줬습니다. 클라우드에서 cron 스케줄로 Claude 에이전트를 자동 실행하는 기능인데요. 이것도 처음 들어봤어요.

매주 수요일 KST 10시 = UTC 01시 → cron 0 1 * * 3으로 등록을 시도했습니다.

처음 막힌 건 API 명세였어요. mcp_connections에 슬랙 커넥터를 넣었는데 connector_uuid: Field required 400 에러가 떴습니다. 그런데 claude.ai의 커넥터 설정 페이지(/customize/connectors)에는 UUID가 안 보여요. 한참 헤맸습니다. 결국 https://claude.ai/directory/connectors/{uuid} 형식의 URL에서 추출했어요.

{
  "mcp_connections": [{
    "connector_uuid": "597f662f-...",
    "name": "slack",
    "url": "https://mcp.slack.com/mcp"
  }]
}

이걸로 routine 생성은 됐고(HTTP 200), 즉시 실행 테스트를 돌렸습니다. 그런데 원격 에이전트가 답한 게 좀 뜻밖이었어요.

현재 환경에 Slack MCP 서버가 연결되어 있지 않습니다. 작업을 수행하려면 다음이 필요합니다... ~/.claude/settings.json에 아래 내용을 추가하세요...

여기서 또 모르는 게 나왔습니다. 분명 슬랙 커넥터를 attach 했는데 왜 못 보는지. 클로드한테 진단을 부탁했어요.

답은 이랬습니다.

• claude.ai 커넥터는 사용자 웹 채팅 세션의 OAuth 토큰에 묶여 있습니다.
• Remote Routine은 별개의 격리된 환경에서 실행됩니다.
• mcp_connections로 attach 했지만 OAuth 토큰이 routine 환경으로 전달되지 않습니다.

제 설정 문제가 아니라 시스템 자체의 한계였어요. claude.ai 커넥터를 그대로 routine에서 못 쓴다는 건 그날 처음 알았습니다.

의사결정

세 가지 옵션을 비교했습니다.

옵션	작업량	자동화 수준
Slack Bot Token 발급 → routine 환경변수 주입 → bash로 Slack API 호출	30분~1시간	100%
Routine 비활성, 수동 실행만 사용	0분	50%
시스템 개선 대기	0분 (대기)	0% (현재)

옵션 2를 골랐습니다. 이유는 두 가지예요.

고객사에 나가는 메시지를 100% 자동 전송하는 건 오히려 위험합니다. 잘못된 수치, 어색한 문장, 민감한 표현이 검토 없이 나가면 신뢰 비용이 더 큽니다. 검토 단계는 일부러 남겨두는 편이 낫다고 판단했어요.

또 하나는 Bot Token 방식이 워크스페이스 관리자 권한과 토큰 보안 관리 부담을 끌고 옵니다. 1시간 작업으로는 안 끝나고, 운영 부담이 계속 따라옵니다. 현재 시점에선 그 정도까지 갈 가치가 없다고 봤어요.

Routine은 enabled: false로 비활성화했습니다. API에 delete가 없어서 disable만 가능했어요.

6. Layer C — macOS 알림, 4번의 실패

이제 매주 수요일 10시에 알림만 띄우면 끝이었습니다. 가장 쉬울 줄 알았어요.

시도 1: launchd + osascript

macOS는 launchd로 사용자 LaunchAgent를 등록할 수 있다고 클로드가 알려줬습니다. plist에 osascript로 알림 띄우는 명령을 넣었어요.

<key>ProgramArguments</key>
<array>
    <string>/usr/bin/osascript</string>
    <string>-e</string>
    <string>display notification "..." with title "..." sound name "Glass"</string>
</array>
<key>StartCalendarInterval</key>
<dict>
    <key>Weekday</key><integer>3</integer>
    <key>Hour</key><integer>10</integer>
</dict>

launchctl load 후 즉시 실행 테스트. 알림이 안 뜹니다. 여기서 또 모르는 게 튀어나왔어요. 클로드가 "시스템 설정 → 알림에서 스크립트 편집기 권한 확인해줘"라고 했는데, 제 화면에는 그 항목이 안 보였습니다.

"스크립트 편집기가 원래 이름이 맞아? 이름이 안보여"

이렇게 또 물어봤어요. 답은 — osascript는 별도 앱이 아니라 명령줄 도구라서, 호출한 부모 프로세스(터미널, iTerm, Cursor, cmux 등)의 권한을 따라갑니다. 즉 시스템 설정에는 "스크립트 편집기"가 아니라 제가 Claude Code를 띄워놓은 그 터미널 앱 이름으로 등록될 수 있다는 거였어요.

제 환경은 cmux였습니다. 클로드가 "cmux는 백그라운드 멀티플렉서라 부모 프로세스가 모호해서 macOS가 권한을 어디다 물어야 할지 못 정한다"고 진단했어요. 듣고 보니 그럴듯했습니다.

시도 2: terminal-notifier

대안으로 terminal-notifier를 써보기로 했어요. 자체 .app 번들로 배포되니 자기 이름으로 권한 관리가 명확해질 거라고 봤습니다. brew가 안 깔려 있어서 GitHub 릴리스에서 직접 받았어요.

curl -L -o tn.zip https://github.com/julienXX/terminal-notifier/releases/download/2.0.0/terminal-notifier-2.0.0.zip
unzip tn.zip
mv terminal-notifier.app ~/Applications/

직접 호출 테스트는 잘 됐어요. 알림이 떴습니다. 그래서 plist를 terminal-notifier로 바꾸고 launchctl start로 호출했어요. 안 뜹니다.

직접 실행은 되는데 launchd가 호출하면 안 되는 이상한 패턴이었습니다. 그리고 이때 처음으로 시스템 알림이 떴어요. "백그라운드 항목이 추가됨"이라는 메시지였습니다.

"백그라운드 항목이 추가됨' 이렇게 알림떴어"

이게 제 알림인 줄 알고 좋아했는데, 클로드가 보더니 "그건 macOS가 LaunchAgent 등록할 때 자동으로 띄우는 시스템 알림이고, 우리가 보내려던 알림은 여전히 silent 차단되고 있어"라고 알려줬습니다. 허무했어요.

시도 3: open 명령 우회

launchd가 백그라운드 컨텍스트에서 도는 게 문제일 거라 짐작하고, open 명령으로 .app을 GUI 세션에서 띄우게 했습니다. 여전히 안 떴어요.

시도 4: AppleScript .app 직접 패키징

osacompile로 알림 띄우는 .app을 직접 만들었습니다. 시스템 설정 → 알림에 그 .app 이름이 새로 추가되어 권한 관리가 가능할 거라고 기대했어요.

cat > /tmp/notify.applescript <<'EOF'
display notification "..." with title "주간 보고 시간" sound name "Glass"
EOF
osacompile -o ~/Applications/WeeklyReminder.app /tmp/notify.applescript
open ~/Applications/WeeklyReminder.app

아무 일도 안 일어났어요. 시스템 설정 → 알림에 항목조차 안 떴습니다. 또 클로드한테 물어봤더니, osacompile로 만든 .app은 macOS가 신뢰하는 코드 서명이 없어서 권한 요청 UI 자체가 트리거되지 않는다고 했어요. macOS Sequoia(15) 이후 알림 시스템이 더 엄격해진 영향이라고 합니다.

종합 진단

호출 경로	결과	원인
터미널 → terminal-notifier	성공	GUI 세션 컨텍스트
launchd → terminal-notifier	실패	백그라운드 컨텍스트, 알림 권한 부재
launchd → open → .app	실패	동일
미서명 .app	실패	권한 요청 UI 자체가 안 뜸

launchd로 알림을 띄우는 시도 자체가 macOS 보안 모델과 충돌하고 있었어요. 우회하려면 codesign으로 강제 서명하거나 GUI 세션 PID에 bsexec로 attach하는 등 복잡도가 확 올라갑니다. 여기서 멈췄어요.

7. 우회 — macOS Reminders.app

여기까지 와서야 클로드가 마지막 옵션을 제시했습니다.

"이런 케이스에서 macOS가 안정적으로 알림 띄우는 방법은 macOS 기본 앱(Calendar, Reminders)에 등록하는 것이야. 100% 동작 보장."

문제를 다시 봤습니다. 목표는 "매주 정해진 시각에 알림 뜨기"였지 "launchd로 알림 띄우기"가 아니었어요. 그리고 macOS는 이미 "정해진 시각에 알림 띄우는 기능"을 OS 차원에서 잘 만들어두고 있습니다. Calendar.app이랑 Reminders.app이죠.

처음부터 이걸 안 쓴 이유는 별 거 없습니다. 그냥 "스크립팅으로 풀어야 한다"는 본능이 먼저 작동했어요. 돌이켜보면 도구 선택 우선순위가 거꾸로였습니다. 순서는 이래야 했어요.

1. OS / SaaS 기본 기능
2. 검증된 라이브러리 / CLI
3. 직접 코드

AppleScript로 Reminders에 미리알림을 등록하면 알림 권한 컨텍스트를 신경 쓸 필요가 없습니다. macOS가 알아서 띄워줘요.

Reminders의 AppleScript dictionary에서 recurrence를 RRULE로 직접 설정하는 건 또 까다로워서, 1년치 52개를 한 번에 등록하는 식으로 우회했어요. 1년 후에 또 추가하면 됩니다.

osascript <<'EOF'
tell application "Reminders"
    set defaultList to default list
    set startDate to current date
    set day of startDate to 20
    set month of startDate to 5
    set year of startDate to 2026
    set hours of startDate to 10
    set minutes of startDate to 0

    set i to 0
    repeat 52 times
        set targetDate to startDate + (i * 7 * 24 * 60 * 60)
        tell defaultList
            set newRem to make new reminder with properties {name:"주간 보고", body:"슬랙 DM 확인 후 /customer-weekly 실행"}
            set remind me date of newRem to targetDate
        end tell
        set i to i + 1
    end repeat
end tell
EOF

30초 후 발화하는 테스트 미리알림을 만들었더니 알림이 깔끔하게 떴습니다. 4번을 헤맸는데 이건 5분 만에 끝났어요.

8. 최종 셋업

레이어	도구	상태
A. 보고서 생성	Claude Code Skill /customer-weekly	동작
B. 클라우드 자동 실행	Remote Routine	비활성
C. 알림	macOS Reminders (52주치)	동작

운영 흐름은 이렇습니다.

1. 수요일 10시 → Reminders 알림
2. Claude Code 실행
3. /customer-weekly 입력
4. 채팅창에 보고서 초안 출력 (약 1분)
5. 검토 후 슬랙 채널에 붙여넣기

기존 30~40분이 약 3분으로 줄었습니다. 보고서 품질도 수치/근거가 슬랙 메시지에서 직접 나오니 오히려 더 좋아졌어요.

 

 

 

 

 

9. 회고 — 모르는 채로 시작해도 괜찮습니다

PM도 LLM과 대화로 자동화를 만들 수 있다

이 글의 가장 솔직한 메시지는 이겁니다.

저는 PM이고 코드를 잘 짜지 않습니다.

Skill이 뭔지도 모르고 시작했고, 동적 컨텍스트 주입, 인수, frontmatter, launchd 권한 컨텍스트, AppleScript 코드 서명 같은 건 그날그날 처음 들었어요. 그런데도 3시간 만에 매주 30분 절약하는 자동화를 만들었습니다.

비결은 단순해요. 모르는 게 나오면 그 자리에서 클로드한테 물어봤습니다. "이게 무슨 말인지 모르겠어 설명해줘", "스크립트 편집기가 원래 이름이 맞아?", "왜 알림이 안 뜨지?" — 부끄러운 질문도 그냥 했어요. 어차피 클로드는 표정이 없으니까요.

LLM 시대 AX의 본질은 "엔지니어 없이도 자동화가 가능해진다"가 아니라, "학습 곡선의 비용이 거의 0에 수렴한다"는 거라고 생각합니다. 모르면 물어보면 되고, 답은 그 자리에서 옵니다. 그게 RPA나 매크로와의 결정적 차이예요.

Skill은 프롬프트 엔지니어링을 담는 그릇이다

Skill을 처음 써보고 가장 만족한 부분입니다. SKILL.md 한 파일에 5가지 요소(description, persona, stepwise, output template, guidelines)를 한꺼번에 정의할 수 있어요. 매크로/RPA는 동작 순서만 기록하지만, Skill은 판단 기준과 톤까지 같이 담습니다.

특히 출력 템플릿을 골격째로 박아두는 것, 그리고 출처 근거를 명시 강제하는 가이드라인. 이 둘만 잡아도 결과물 일관성이 확 올라갑니다. 처음엔 "프롬프트 엔지니어링이라는 게 별 거 있나" 싶었는데요. 막상 만들어보니 빈 화면에서 시작할 때랑 5요소 체크리스트 따라갈 때의 결과 차이가 컸어요.

100% 자동화가 정답이 아닐 때가 많다

Layer B를 끝내 살리려면 Slack Bot Token 발급하고 환경변수로 주입하는 추가 작업이 필요했습니다. 30분이 30분~1시간으로 줄어드는 효용 vs 토큰 보안 관리 부담을 비교하면 70% 자동화 + 30% 수동 검토가 적정이었어요.

특히 고객사에 나가는 메시지는 검토 단계를 일부러 남겨두는 편이 낫다고 봅니다. AX 설계에서 자동화 수준은 "기술적으로 가능한 최대"가 아니라 "리스크와 효용의 균형점"입니다.

OS 기본 기능부터 보자

launchd + osascript + terminal-notifier로 4번 실패하는 동안 Reminders.app은 5분 만에 풀렸어요. macOS가 이미 잘 만들어둔 기능을 우회하려고 코드를 짜는 건 거의 항상 비효율이었습니다. 이번에 비싸게 산 교훈이에요.

트러블슈팅 시간을 미리 잡아두자

처음 견적은 1시간이었는데 실제로는 3시간이 걸렸습니다. 자동화 작업은 70%가 트러블슈팅이라고 봐도 됩니다. macOS 보안 모델, 클라우드 환경 격리, MCP/Connector 호환성 같은 건 공식 문서에 안 나오는 함정이 많아요. 3-layer로 쪼개서 1개라도 작동하면 부분 가치가 나오게 설계한 게 결과적으로 잘한 선택이었습니다.

마치며

AX가 거창한 ML 모델 학습이나 복잡한 워크플로우 엔진을 의미하지는 않습니다. 매주 30분 걸리던 일을 3분으로 줄이는 것, 그게 AX라고 생각해요. 시작점은 보통 "내가 매주 똑같이 반복하는 게 뭐지?"라는 질문입니다.

성공 사례만 보면 "왜 나는 안 되지?"라는 좌절이 더 커지니까 트러블슈팅 사례도 솔직히 남겼습니다. 모르는 채로 시작해도 괜찮습니다. 모르는 게 나올 때마다 물어보면서 만들어가면 되거든요. 그게 LLM 시대의 자동화 방식이라고 생각해요.

이 글이 비슷한 반복 업무에 시달리시는 PM 분들, 그리고 "코드를 잘 모르는데 자동화에 관심 있는" 분들께 조금이라도 도움이 되었으면 좋겠습니다. 궁금한 점이나 더 듣고 싶은 부분이 있으시면 언제든 댓글이나 피드백 부탁드려요. 🙇🏻‍♀️

---

Stack

• 프레임워크: Claude Code (Skills, Remote Routines)
• 통신: Slack MCP, claude.ai Connectors
• 스케줄링: macOS Reminders.app + AppleScript
• 시도했지만 안 쓴 것: launchd, osascript, terminal-notifier, 미서명 AppleScript .app

---

추천 태그: #PM #ClaudeCode #Skill #MCP #슬랙자동화 #AX #업무자동화 #프롬프트엔지니어링

카테고리: AX / PM 업무 자동화