Lv3 실전편 · 11편 (10편 속편)
10편(워크플로우 설계)의 마지막 단계는 “트리거 단어 결정 + 스킬화” 였다. 그 단계에서 “좋은 트리거 3가지 조건” 만 짧게 짚고 “다음 편에서 자세히” 라고 예고했다. 이 편이 그 답이다.
운영 6개월 누적해보면 “같은 워크플로우인데 트리거에 따라 발화율이 다르다” 가 명확해진다. “포스팅했어” 는 잘 작동하는데 “포스팅 완료처리” 는 자꾸 다른 스킬로 갈리고, “끝났어” 는 아예 발화 안 됨.
차이는 어디서 갈리나? — 트리거 설계 5조건에서 갈린다.
이 편은 그 5조건을 정리한다. 5편(CLAUDE.md 좋은 구조 5원칙)·6편(좋은 스킬 5특징)·8편(좋은 프롬프트 5원칙)에 이어 시리즈의 “5가지” 구조 누적 — Cowork 운영의 4번째 5조건.
트리거가 작동하는 메커니즘 — 한 줄로
트리거 단어 = 사용자 발언이 워크플로우(스킬)에 박힌 description과 매칭되는 패턴.
6편에서 “스킬 description의 첫 줄이 호출 판단을 좌우한다” 라고 짚었다. 그 “호출 판단” 의 실제 매커니즘은 “사용자가 던진 한 마디” vs “스킬 description에 박힌 발언 패턴” 의 비교다.
사용자 발언: "포스팅했어"
↓
[1단계] Cowork가 새 채팅창 시작 시점에 모든 스킬 description을 가볍게 메모리에 올림
[2단계] 사용자 발언이 들어오면 description의 키워드와 매칭 검사
[3단계] 매칭률 가장 높은 스킬을 호출 (또는 매칭 임계치 못 넘으면 일반 대화로 처리)
[4단계] 호출된 스킬 본문이 토큰에 추가 로드 → 워크플로우 발화
이 매커니즘을 알면 “좋은 트리거 단어” 의 본질이 보인다. 사용자 발언과 description의 매칭률을 최대로 높이는 단어 패턴.
트리거 설계 5조건
조건 ① 본인 평소 표현 그대로
가장 중요한 첫 조건. 본인이 작업 끝나고 자연스럽게 입에서 나오는 표현을 그대로 트리거로.
| 시나리오 | 평소 표현 | ❌ 부자연 | ✅ 자연 |
|---|---|---|---|
| 블로그 발행 후 | “포스팅했어” | “블로그 게시 완료처리” | “포스팅했어” |
| 주식 리뷰 시간 | “주간 리뷰 해줘” | “주식 포트폴리오 분석 시행” | “주간 리뷰 해줘” |
| 메일 보낼 때 | “이 메일 보내줘” | “전자메일 발송 요청” | “이 메일 보내줘” |
왜 이게 1번 조건인가? 작업 시점에 “트리거를 어떻게 던지더라” 떠올리는 순간 흐름이 끊긴다. 평소 표현 그대로면 떠올림 비용이 0이라 자연스럽게 발화된다.
트리거가 어색하면 안 쓴다. 안 쓰면 워크플로우 자체가 죽은 것.
운영 5번 이상 발화돼야 “이게 트리거구나” 가 본인 손에 익는다. 손에 안 익는 트리거는 결국 폐기.
조건 ② 명확함 — 어느 워크플로우인지 모호하지 않게
본인 평소 표현이라도 “모호한 표현” 은 트리거로 부적합. “끝났어”·”완료”·”됐어” 같은 표현은 어느 작업이 끝났는지 명시 안 됨.
| ❌ 모호 | ✅ 명확 |
|---|---|
| “끝났어” | “포스팅했어” / “메일 보냈어” / “리뷰 끝났어” |
| “됐어” | “분석 됐어” / “보고서 완성됐어” |
| “완료” | “포스팅 완료” / “발송 완료” |
명확함의 기준: 트리거 단어를 들었을 때 “어느 작업의 트리거인지” 가 즉시 떠오르는가. 본인뿐 아니라 6개월 후의 본인도. 떠오르지 않으면 모호.
조건 ③ 짧음 — 한 마디로 끝나야
좋은 트리거는 3~7글자가 정석. 너무 길면 “이거 한 마디 던지면 되겠다” 가 부담된다.
| 길이 | 평가 | 예시 |
|---|---|---|
| 1~2글자 | ❌ 너무 짧음 (모호) | “끝”·”OK” |
| 3~7글자 | ✅ 정석 | “포스팅했어”·”주간 리뷰”·”메일 보내” |
| 8~15글자 | △ 부분적 OK | “블로그 발행했어”·”이 데이터 분석해줘” |
| 16글자 이상 | ❌ 너무 김 (트리거 X, 일반 프롬프트) | “이 폴더 사진들로 블로그 초안 만들어줘 결과는…” |
16글자 이상이면 그건 이미 트리거가 아니라 프롬프트다. 8편·9편의 5원칙·5단계가 적용되는 영역. 트리거는 “짧고 가벼운 한 마디” 가 본질.
조건 ④ 충돌 회피 — 다른 트리거와 명확히 구분
여러 워크플로우의 트리거가 비슷하면 “어느 게 발화될지 모호”. 10편 함정 ③번에서 짚은 영역. 트리거 결정 시점에 기존 트리거 목록과 한 번 비교해야 한다.
내 운영 사례 예:
- “리뷰 해줘” — 주식 주간 리뷰
- “리뷰 작성해줘” — 블로그 글 검토
- “리뷰 점검해줘” — 본인이 쓴 글 자체 점검
세 트리거가 모두 “리뷰” 라는 단어를 공유. 작업 시점에 어느 게 발화될지 흐릿하다. 해법: 각 트리거에 “활동 한정사” 를 박아서 충돌 회피.
- “주식 리뷰” (주식 한정)
- “이 글 리뷰” (현재 보고 있는 글 한정)
- “본인 점검” (자체 점검 한정)
조건 ⑤ 변형 견딤 — 표현이 약간 달라도 매칭
사용자가 매번 정확히 같은 한 마디를 던지진 않는다. “포스팅했어” 와 “포스팅 올렸어” 와 “포스팅 발행했어” 가 다 같은 의도. 좋은 트리거 설계는 이 변형을 견딘다.
description에 변형 패턴을 같이 박는 게 정석:
description: >
포스팅 완료 처리 워크플로우. 다음 표현 중 하나라도 매칭되면 발화:
- "포스팅했어" / "포스팅 올렸어" / "포스팅 발행했어"
- "블로그 올렸어" / "글 발행했어"
- "포스팅 완료" / "발행 완료"
3~5개 변형 패턴을 같이 박아두면 본인이 어떤 변형을 던져도 매칭률이 90% 이상. 6편 “호출 안 될 때 디버깅 4가지” 의 ①번(“description에 트리거 단어가 빠짐”)을 사전에 막는 설계.
5조건의 우선순위 — 충돌하면 어느 게 이기나
5조건이 충돌하는 경우가 있다. 예를 들어:
- “포스팅 완료처리” — ②(명확함) ✅ / ③(짧음) ❌ (글자수 8자)
- “끝” — ③(짧음) ✅ / ②(명확함) ❌
이런 경우 어느 조건을 우선할까?
| 우선순위 | 조건 | 이유 |
|---|---|---|
| 1순위 | ② 명확함 | 모호하면 발화 자체가 잘못된 방향으로 |
| 2순위 | ① 평소 표현 | 어색하면 안 쓰게 됨 |
| 3순위 | ④ 충돌 회피 | 비슷한 트리거가 둘 이상이면 둘 다 죽음 |
| 4순위 | ⑤ 변형 견딤 | description에서 흡수 가능 |
| 5순위 | ③ 짧음 | 길어도 작동은 함 |
명확함이 1순위인 이유: 모호한 트리거는 잘못 발화돼서 다른 워크플로우가 실수로 작동할 위험이 있다. 이게 사고 발생 시 가장 큰 비용.
트리거 분기 규칙 — CLAUDE.md에 박는 헌법
여러 워크플로우가 있을 때 “이 트리거는 A 워크플로우, 저 트리거는 B” 를 미리 정해두면 충돌이 사라진다. 5편 좋은 구조 ③번(“트리거 단어 명시”)의 워크플로우 영역 적용.
내 CLAUDE.md에 박혀있는 분기 규칙 한 예:
# 활동별 트리거 분기 (충돌 방지)
블로그 활동:
- "포스팅했어" → ROI 트래커 + 대시보드 + 폴더 이동 워크플로우
- "포스팅 초안 만들어줘" → 블로그 초안 작성 워크플로우
- "포스팅 검증해줘" → 발행 전 자체 점검
주식 활동:
- "주간 리뷰" → 주식 포트폴리오 주간 리뷰
- "초단타 후보" → 매일 저녁 5종목 스크리닝
메일 활동:
- "[이메일주소] [상품명] 보내줘" → 구매자 메일 발송 (초안 생성 후 승인)
분기 규칙이 박혀있으면 새 트리거 추가할 때도 “기존이랑 충돌 안 나게” 가 헌법 차원에서 보장된다.
트리거 점검 — 사고 후 다듬기
운영하다 보면 “발화가 안 되는 트리거” 가 발견된다. 점검 흐름은 6편(스킬 점검 신호 3가지)의 트리거 영역 적용.
| 사고 패턴 | 원인 | 해법 |
|---|---|---|
| 트리거 던졌는데 일반 대화로 처리됨 | description에 변형 패턴 부족 | 평소 자주 쓰는 표현 3~5개 추가 |
| 다른 워크플로우가 발화됨 | 트리거 충돌 | 활동 한정사 추가 (조건 ④) |
| 트리거 떠올림이 부담됨 | 본인 평소 표현 아님 | 트리거 자체를 평소 표현으로 변경 (조건 ①) |
| 가끔만 발화됨 | 새 채팅창에서 시작 안 함 | 5-2편 검증 원칙 — 트리거는 새 채팅창에서 |
가장 자주 마주치는 사고는 첫 번째 패턴 — 변형 패턴 부족. 본인이 “포스팅 올렸어” 라고 던졌는데 description엔 “포스팅했어” 만 박혀있으면 매칭 실패. description에 변형을 한 줄씩 추가하면 즉시 해결.
자동 트리거 vs 명시 트리거
트리거에는 두 종류가 있다.
자동 트리거 — 발언 패턴 매칭
위에서 다룬 “포스팅했어”·”주간 리뷰” 같은 일반 트리거. 사용자가 의식적으로 “트리거 던지자” 안 해도 평소 표현이 자동 매칭되어 발화.
적용: 워크플로우 대부분이 이 형태. 운영 흐름에 자연스럽게 녹는다.
명시 트리거 — 스킬명 직접 호출
/스킬명 또는 “○○ 스킬 실행해줘” 형태로 명시적 호출. 일반 트리거가 모호한 경우의 대안.
적용: 트리거 충돌 회피 또는 가끔 쓰는 워크플로우. 매번 평소 표현에 박힐 필요가 없을 때.
| 비교 | 자동 트리거 | 명시 트리거 |
|---|---|---|
| 자연스러움 | ✅ 평소 흐름에 녹음 | △ 의식적 호출 필요 |
| 충돌 위험 | 매칭률에 따라 가변 | ❌ 거의 0 (정확한 이름) |
| 적용 영역 | 자주 쓰는 핵심 워크플로우 | 가끔 쓰는 / 모호한 영역 |
대부분의 운영 워크플로우는 자동 트리거. 명시 트리거는 “가끔 쓰지만 발화는 정확히 되어야 하는” 경우의 보조.
운영 누적이 만드는 “트리거 라이브러리”
5조건으로 트리거 한두 개 만들면 어색하다. 5~7개 만들면 본인 운영의 “트리거 라이브러리” 가 형성된다.
내 라이브러리 예 (트리거 → 워크플로우 매핑):
| 트리거 한 마디 | 발화되는 워크플로우 |
|---|---|
| “포스팅했어” | 블로그 완료 처리 (ROI + 대시보드 + 폴더) |
| “주간 리뷰” | 주식 포트폴리오 주간 리뷰 |
| “초안 만들어줘” | 블로그 초안 작성 |
| “[메일주소] 분석집 보내줘” | 구매자 메일 발송 (초안 → 승인 → 발송) |
| “임시 폴더 다 지워줘” | 임시 폴더 정리 (레슨앤런 3편) |
| “소환해줘” | 여행 폴더 기반 포스팅 초안 자동 생성 |
7~8개 트리거가 손에 익으면 하루에 1시간 분량 작업이 5~10분으로 압축된다. 이게 Cowork 자동화의 정점.
라이브러리가 정착하면 새 트리거 추가 시점에 “기존 7개와 충돌 안 나는 표현” 만 떠올리면 끝. 매번 5조건 다 거치는 부담이 없어진다.
자주 묻는 질문
Q1. 트리거를 영문으로 박아도 되나?
A. 본인이 영문 표현으로 자주 말하면 영문 OK. 다만 한국어 사용자라면 “publish” 보다 “발행” 이 자연스러움. 조건 ①(평소 표현) 따라가는 게 정석.
Q2. 트리거에 변수(날짜·장소)를 박을 수 있나?
A. 가능. “4월 19일 ○○ 포스팅 초안 만들어줘” 같은 변수 박힌 트리거는 description에 “[날짜] [장소] 포스팅 초안” 패턴으로 박아두면 매칭. 6편 “명확한 트리거 vs 모호한 트리거” 표 참조.
Q3. 트리거 5조건과 5편 좋은 구조 5원칙·6편 좋은 스킬 5특징·8편 좋은 프롬프트 5원칙의 관계?
A. 같은 “명확하게 적힌 것은 일관되게 작동한다” 라는 전제에서 출발한 4가지 “5조건”. 각자 다른 영역(헌법·스킬·프롬프트·트리거)이지만 결은 같음. 한 영역을 익히면 나머지 영역의 5조건도 자연스럽게 흡수.
Q4. 트리거 5조건을 다 만족 못 해도 운영은 가능?
A. ①(평소 표현)·②(명확함)만이라도 만족하면 70% 효과. ③·④·⑤는 운영 중에 누적되면서 점진적 보강. 다만 ①·②를 빼면 트리거 자체가 안 박힘.
Q5. 트리거 점검은 따로 하는가?
A. 6편 “스킬 점검 신호 3가지” 와 같이 사건 기반. “발화가 잘 안 되는 트리거가 발견됐을 때” 즉시 점검. 주기 기반은 아님.
정리
이 편에서 챙길 핵심 5가지.
- 조건 ① 본인 평소 표현 그대로 — 어색하면 안 쓰게 되니까 1순위
- 조건 ② 명확함 — 어느 워크플로우인지 모호하지 않게. 충돌 시 1순위
- 조건 ③ 짧음 — 3~7글자가 정석. 16자 이상은 트리거 아니라 프롬프트
- 조건 ④ 충돌 회피 — 활동 한정사로 다른 트리거와 명확히 구분
- 조건 ⑤ 변형 견딤 — description에 3~5개 변형 패턴 같이 박아서 매칭률 90% 이상
5편(CLAUDE.md)·6편(스킬)·8편(프롬프트)·11편(트리거)의 “5가지” 구조가 누적되어 Cowork 운영의 4대 5조건이 완성됐다. 이후 마지막 편에서 1년 운영 사이클로 시리즈를 마무리한다.
2026년 5월 현재 상태
- Lv3 실전편 진행 — 11편 (트리거 단어 설계 5조건)
- 10편(워크플로우)·11편(트리거)이 “워크플로우 본문 + 발화 단어” 의 결로 연결
- 5편·6편·8편·11편이 모두 “5가지” 구조 — Cowork 운영의 4번째 5조건 완성
- 5조건 우선순위 확정: ② 명확함 > ① 평소 표현 > ④ 충돌 회피 > ⑤ 변형 견딤 > ③ 짧음
- 트리거 라이브러리 7~8개 누적 시 “하루 1시간 작업이 5~10분으로 압축” 의 정점
- 다음 편 예정: 시리즈 마무리 — Cowork 운영의 1년 사이클
undefined