Cowork 마스터 백서 — Lv3 실전편 · 8편
Lv2 기본편 7편(폴더 구조 설계) 마지막에 “Lv2까지가 도구 정비였다면, Lv3부터는 그 도구로 결과를 뽑아내는 단계” 라고 결을 잡았다. 이 편이 그 시작이다.
도구가 다 정비된 상태에서도 결과가 아쉬운 경우가 자주 있다. 같은 CLAUDE.md, 같은 스킬, 같은 폴더 구조를 두고 작업을 시키는데 어떤 날은 한 번에 깔끔하게 끝나고, 어떤 날은 “내가 의도한 게 아닌데” 의 연속. 차이는 어디서 갈리나?
차이는 프롬프트에서 갈린다.
이 편은 “같은 질문도 결과를 가르는 작은 차이” — 좋은 프롬프트의 5가지 설계 원칙을 정리한다. 5편(CLAUDE.md 좋은 구조 5원칙)의 결을 프롬프트 영역으로 확장한 패턴.
이 글이 검색해서 들어왔다면 다음 질문 중 하나일 것이다 — “AI 프롬프트 작성법이 뭔지”, “ChatGPT·Claude 같은 AI한테 질문 잘하는 법은”, “프롬프트 엔지니어링 기초가 궁금한데 어디서 시작해야 하는지”, “프롬프트 잘 쓰는 사람과 못 쓰는 사람의 차이는 뭔지” — 이 네 가지 모두 같은 답으로 수렴한다. 좋은 프롬프트는 5가지 작은 차이로 결정된다. 이 글은 그 5원칙을 비개발자 눈높이로 정리한다.
왜 프롬프트가 결과를 가르는가
7편까지 정리한 도구들(CLAUDE.md·스킬·폴더)은 “매번 같은 상태로 준비된 작업장” 같은 거다. 작업장이 잘 정비돼있으면 같은 도구로 같은 결과를 뽑을 가능성이 높아진다. 그런데 작업 지시를 어떻게 내리느냐가 결과의 마지막 30%를 좌우한다.
비유하면 이렇다:
| 요소 | 비유 |
|---|---|
| CLAUDE.md (5·5-2·5-3편) | 회사 헌법 |
| 스킬 (6편) | 부서별 SOP 매뉴얼 |
| 폴더 구조 (7편) | 사무실 자리 배치 |
| 프롬프트 (이 편) | 직원에게 일을 시키는 한 마디 |
좋은 사무실에 좋은 SOP를 갖췄는데 “이거 좀 해줘” 한 마디로 다 처리되길 기대하면 결과가 아쉽다. 무엇을 / 어떻게 / 어디에 / 언제까지 / 어떤 형식으로 가 명확해야 한 번에 정확한 결과가 나온다.
원칙 ① 명확한 동사로 시작하라
가장 자주 빠지는 함정은 “애매한 시작” 이다.
| ❌ 모호 | ✅ 명확 |
|---|---|
| “이 파일 좀 봐줘” | “이 파일의 데이터를 표로 정리해줘” |
| “블로그 글 작업해줘” | “블로그 글 초안을 작성해줘” / “블로그 글의 SEO 메타데이터를 추출해줘” |
| “정리 좀” | “이 폴더의 파일들을 날짜순으로 분류해줘” |
“이 파일 좀 봐줘” 라고 시작하면 “읽고 요약하라는 건가, 분석하라는 건가, 오류를 찾으라는 건가, 그냥 열어두라는 건가” 가 모호하다. 첫 동사가 작업의 전체 결을 결정한다.
첫 동사 = 작업의 본질. 명확하지 않으면 결과도 명확하지 않다.
자주 쓰는 명확한 동사들: 작성하다 · 추출하다 · 분류하다 · 비교하다 · 검증하다 · 수정하다 · 이동하다 · 백업하다 · 발행하다. “보다” · “하다” · “처리하다” 같은 막연한 동사는 피한다.
원칙 ② 결과물의 형식·위치·이름을 미리 정한다
레슨앤런 4편에서 “저장 위치를 명시 안 하면 코워크 폴더 루트가 기본값” 이라는 함정을 짚었다. 이 원칙은 그 함정의 일반화 버전이다.
좋은 프롬프트는 결과물의 다음 3가지를 명시한다.
| 명시 항목 | 예시 |
|---|---|
| 형식 | .md 파일 / .xlsx 시트 / 한 줄 답변 / 표 / 코드 블록 |
| 위치 | 프로젝트A/분석결과/ / 코워크 폴더 루트 / 활동 폴더 안 |
| 이름 | 2026-05-15_분석본.md / [프로젝트명]_요약_v1.xlsx |
세 가지를 다 명시하면 “결과가 어디에 어떤 모양으로 떨어질지” 를 본인이 작업 시작 시점에 알고 있다. 모르면 결과가 다 만들어진 후에 “이거 어디에 저장됐지?” 부터 찾아야 한다.
❌ "이 데이터 분석해줘"
✅ "이 Excel 데이터를 분석해서 결과는 `프로젝트A/분석결과/2026-05-15_매출요약.md`로 저장해줘.
형식은 한 줄 요약 + 표 + 추천 액션 3가지 구조로."
길어 보이지만 본문은 한 줄이고 “어디에 어떤 모양으로” 가 30단어 정도 추가됐을 뿐. 이 30단어가 결과의 80%를 좌우한다.
원칙 ③ 단계를 미리 쪼개서 알려준다
복잡한 작업일수록 “전체를 한 번에 시키지 말고 단계를 미리 알려주는 게” 결과 정확도가 높아진다. 6편(스킬)에서 다룬 “STEP 단위 쪼개기” 원칙을 프롬프트 한 줄에도 적용.
❌ "이 폴더 사진들로 블로그 초안 만들어줘"
✅ "이 폴더 사진들로 블로그 초안 만들어줘. 단계는:
1) EXIF에서 GPS·시간 추출
2) 비슷한 시점·위치 사진을 클러스터링
3) 각 클러스터마다 한 단락씩 본문
4) 도입부·마무리 추가
5) 결과는 `블로그/{날짜}_초안.docx`로 저장"
같은 시간에 같은 분량의 결과를 받지만, 단계가 명시된 쪽이 단계별 결과를 검증하기 쉽다. 중간에 한 단계가 잘못되면 그 단계만 다시 시키면 됨.
단계를 미리 쪼개는 게 사고 발생 시 복구 비용을 가장 크게 낮춘다.
이 원칙은 6편 좋은 스킬 5특징 ②번(“단계가 잘 쪼개져 있다”)과 정확히 일치한다. 스킬 본문이든 일회성 프롬프트든, 단계 쪼개기는 같은 효과를 낸다.
원칙 ④ 금지 사항을 같이 명시한다
좋은 프롬프트는 “무엇을 하라” 만큼 “무엇을 하지 마라” 도 같이 박는다. 5편 좋은 구조 ④번(“숫자·경로·금지선은 정확히”) 원칙을 프롬프트 영역으로 확장.
자주 쓰는 금지 패턴:
| 금지 패턴 | 예시 |
|---|---|
| 원본 보호 | “원본 파일은 절대 수정 X. 사본을 만들어서 작업” |
| 자동 발행 차단 | “본인 승인 받기 전 메일·블로그·SNS 발송 금지” |
| 데이터 손실 방지 | “기존 데이터 덮어쓰기 X. 새 시트로 추가” |
| 범위 제한 | “이 폴더 안만 처리. 다른 폴더는 건드리지 마” |
❌ "이 사진 보정해줘"
✅ "이 사진 보정해줘. 원본은 절대 수정 금지. 보정본은 `보정/` 폴더에 저장.
EXIF 메타데이터는 그대로 유지."
금지 사항을 같이 박으면 “내가 안 시킨 일을 알아서 하다가 사고” 가 차단된다. CLAUDE.md 헌법급 한 줄(5편 좋은 구조 ①번)과 같은 결.
원칙 ⑤ 검증 조건을 미리 정의한다
이게 가장 자주 빠뜨리는 원칙이자, 가장 효과가 큰 원칙이다. 6편 좋은 스킬 5특징 ③번(“자가 검증이 강제로 박혀있다”)의 프롬프트 영역 적용.
❌ "블로그 초안 만들어줘"
✅ "블로그 초안 만들어줘. 결과물이 다음 4가지 모두 만족하는지 자가 검증 후 보고:
□ 본문 분량 1,500~2,000자
□ 도입부에 핵심 메시지 한 줄 존재
□ 단락당 3~5문장
□ SEO 키워드 3개 이상 자연스럽게 포함
하나라도 ❌면 보고 후 보강 진행."
검증 조건을 미리 박으면 첫 결과물의 정확도가 눈에 띄게 올라간다. 작업자(Claude)가 결과를 만드는 동안 “이게 조건을 만족하나?” 를 스스로 체크하면서 진행하기 때문.
검증 조건이 없으면 첫 결과물은 “대충 만들어진 1차 시도” 가 되기 쉽다.
5-2편의 “점검 30분 루틴 검증 5분” 단계가 사후 검증이라면, 이 원칙은 “작업 중 자가 검증” 의 사전 적용. 둘이 합쳐지면 사고가 거의 안 난다.
5원칙을 한 번에 적용한 예시
위 5가지를 모두 박은 프롬프트 한 예시.
"여행블로그 폴더의 260424_부민병원 건강검진 사진들로 블로그 초안 만들어줘.
[원칙 ①] 동사: 작성
[원칙 ②] 결과물:
- 형식: .docx
- 위치: 같은 폴더 안 `초안/`
- 이름: 260424_건강검진_초안_v1.docx
[원칙 ③] 단계:
1) EXIF에서 GPS·시간 추출
2) 시간순 정렬
3) 본문 구성 (도입·검진 흐름·총평·총비용)
4) 사진 캡션 자동 생성
5) 결과 파일 저장
[원칙 ④] 금지:
- 원본 사진 폴더 건드리지 X (별도 사본 사용)
- 자동 발행 X (검토 단계까지만)
[원칙 ⑤] 검증:
□ 본문 1,500~2,000자
□ 사진 모두 캡션 있음
□ 영수증·비용 정보 표 포함
하나라도 ❌면 보강 후 재검증."
길어 보이지만 5원칙이 다 들어가있으니 결과물이 첫 시도에 80% 이상 정확하게 나온다. “내가 의도한 게 아닌데” 가 거의 없어짐.
5원칙을 다 적용하면 길어지지 않나
길어지는 게 맞다. 다만 시간 비용으로 보면 짧다.
- “이거 해줘” 한 줄 → 결과 받기 → “아 이거 말고…” → 두 번째 시도 → … → 5번째 시도쯤 만족
- 5원칙 박은 30줄 프롬프트 → 첫 결과가 정확 → 한 번에 끝
같은 “만족스러운 결과” 까지 걸리는 시간은 5원칙 박은 쪽이 훨씬 짧다. 30줄 작성 비용은 작업당 1~2분, 두세 번 시도 비용은 5~10분. 프롬프트가 길어지면 작업이 짧아진다.
운영 누적이 만드는 “내 프롬프트 패턴”
5원칙을 한두 번 적용하면 어색하다. 5번쯤 적용하면 자연스러워진다. 10번쯤 적용하면 “이 작업은 이런 패턴으로 시키면 결과가 좋더라” 가 본인 패턴으로 누적된다.
이 누적된 패턴이 다음 단계 — 스킬 작성 의 좋은 출발점이 된다. 같은 패턴의 프롬프트를 매번 손으로 쓰는 대신, 스킬에 박아두고 트리거 단어 한 마디로 발화. 6편(스킬)과 이 편이 자연스럽게 연결되는 지점.
좋은 프롬프트 → 누적된 패턴 → 스킬 → 자동화 의 흐름이 Lv3 실전편 전체의 큰 그림이다.
이 편 다음에 다룰 “프롬프트 만드는 5단계” 는 위 5원칙을 적용하는 실전 흐름을, 그 다음 “워크플로우 설계” 는 누적된 패턴을 N단계 자동화로 묶는 방법을 정리할 예정.
자주 묻는 질문
Q1. 5원칙을 다 적용하기엔 작업이 너무 작은데?
A. 그러면 1·2·5원칙(동사·결과물·검증)만이라도. 3·4원칙(단계·금지)은 작업이 커질 때 의식적으로 추가. 작업 크기에 비례해서 원칙을 늘리는 게 정석.
Q2. 5원칙을 적용해도 결과가 자꾸 어긋나면?
A. 6편(스킬) “호출이 안 될 때 디버깅 4가지” 와 같은 결로 점검. description의 트리거가 아니라 프롬프트의 표현이 추상적이면 결과가 어긋난다. 모호한 단어(“적당히”·“필요시”·“잘”·“자연스럽게”)가 들어있는지 다시 보기.
Q3. 5원칙이 CLAUDE.md 좋은 구조 5원칙과 비슷한데?
A. 비슷한 게 맞다. CLAUDE.md는 “규칙을 박는 법”, 프롬프트 5원칙은 “한 작업을 시키는 법” 이다. 두 영역의 원칙이 비슷한 이유는 둘 다 “명확하게 적힌 것은 일관되게 작동한다” 라는 같은 전제를 공유하기 때문.
Q4. 5원칙을 매번 다 박으면 부담 안 되나?
A. 처음엔 부담된다. 운영 5번 정도 지나면 “이런 작업은 이 원칙들이 자동으로 떠오른다” 가 된다. 본인 운영 환경에 맞춰 “내가 자주 까먹는 원칙 2~3개” 만 의식적으로 박아도 효과가 큼.
Q5. 5원칙을 어디에 적어두면 좋아?
A. CLAUDE.md에 박을지 / 스킬에 박을지 / 별도 노트에 박을지는 5-3편 판단 기준 3가지로 결정. “모든 작업에 공통” 이면 CLAUDE.md, “특정 작업” 이면 스킬, “개인 학습 노트” 면 별도. 내 경우 5원칙 자체는 별도 노트(이 백서)에 두고, 활동별 적용 패턴은 각 스킬에 박혀있다.
정리
이 편에서 챙길 핵심 5가지.
- 원칙 ①: 명확한 동사로 시작 — 첫 동사가 작업의 본질을 결정
- 원칙 ②: 결과물의 형식·위치·이름 미리 명시 — “어디에 어떤 모양으로” 가 결과의 80% 좌우
- 원칙 ③: 단계를 미리 쪼개서 알림 — 사고 발생 시 복구 비용 가장 큰 감소
- 원칙 ④: 금지 사항 같이 명시 — “안 시킨 일을 알아서 하다가 사고” 차단
- 원칙 ⑤: 검증 조건 미리 정의 — 첫 결과물의 정확도가 가장 크게 올라가는 원칙
이로써 Lv3 실전편 시작. 이후 편에서 프롬프트 만드는 5단계·워크플로우 설계·트리거 단어 설계·1년 운영 사이클로 이어진다. Lv2(도구)에서 다진 기반 위에 Lv3(운영)으로 한 단계 올라가는 흐름.
2026년 5월 현재 상태
- Lv3 실전편 시작 — 8편 (좋은 프롬프트 설계 5원칙)
- 5편(CLAUDE.md 좋은 구조 5원칙)·6편(좋은 스킬 5특징)·8편(좋은 프롬프트 5원칙)이 모두 “5가지 원칙” 구조 — 같은 결의 누적이 의도된 일관성
- 7편 마무리에서 예고한 “Lv2 도구 정비 → Lv3 결과 뽑기” 흐름 본격 시작
- 누적 5원칙 적용 후의 다음 단계: 운영 패턴 누적 → 스킬 작성 → 자동화 (6편과 자연 연결)
- 이후 편 예정: 프롬프트 만드는 5단계 · 워크플로우 설계 · 트리거 단어 설계 · 1년 운영 사이클 마무리
undefined