[Claude 활용 24회 — AI에게 일을 위임하는 법] 4/24화: AI 작업 지시서 4요소 — 프롬프트 한 줄이 3시간을 태우는 이유

“알아서 잘 해줘.” 지난 3화에서 Claude Code를 설치하고 첫 성공을 맛본 다음 날, 저는 이 한 마디로 실무 작업을 시작했습니다. 레거시 API 하나를 정리하는 간단한 일이었습니다. 20분 뒤 코드는 아름다워졌고, 깔끔해졌고, 완전히 망가져 있었습니다. 함수 시그니처가 바뀌면서 세 군데 호출부가 동시에 깨졌고, 되돌리는 데 세 시간이 걸렸습니다. 처음부터 제대로 지시했으면 30분이면 끝날 일이었습니다. 문제는 AI가 아니었습니다. 문제는 제가 프롬프트를 쓴 거지, AI 작업 지시서를 쓴 게 아니었다는 점이었습니다.

20년 넘게 코드를 짰고, 대화형 AI 서비스를 8년째 만들고 있습니다. 신입 개발자에게 일을 맡길 때 “이거 알아서 잘 해”라고 말하면 어떤 결과가 돌아오는지 뼈저리게 알고 있습니다. 그런데 AI에게는 정확히 그 짓을 하고 있었습니다. 이 시리즈의 약속을 다시 꺼내겠습니다 — AI가 코드를 짜주는 시대가 아니라, AI에게 일을 위임하는 시대입니다. 위임할 줄 아는 사람이 하나의 회사가 됩니다. 그리고 위임의 핵심은 프롬프트가 아니라 작업 지시서입니다.

오늘은 그 차이가 만드는 결과의 격차를 보여드리겠습니다. 나쁜 지시와 좋은 지시 Before/After 5쌍, 실행 전에 설계를 리뷰하는 Plan Mode 활용법, 그리고 ‘알아서 잘’이 만드는 진짜 비용까지.

AI 작업 지시서의 4요소 — 맥락·제약·완료조건·검증방법

프롬프트와 작업 지시서의 차이는 간단합니다. 프롬프트는 “뭘 해줘”이고, 작업 지시서는 “이런 상황에서, 이런 조건 안에서, 이런 결과물을, 이렇게 확인할 수 있도록 해줘”입니다. 이 차이를 만드는 네 가지 요소가 있습니다.

1. 맥락(Context) — “지금 어떤 상황인가”

AI는 당신의 프로젝트를 모릅니다. 디렉토리 구조를 읽을 수는 있지만, 왜 그렇게 설계했는지, 지난주에 뭘 바꿨는지, 이 코드가 어디서 호출되는지는 알려줘야 합니다. 맥락 없는 지시는 빈 지도를 주고 목적지에 가라고 하는 것과 같습니다.

• 어떤 시스템/파일/모듈에 대한 작업인지
• 현재 상태가 어떤지 (무엇이 동작하고, 무엇이 문제인지)
• 최근에 무엇이 바뀌었는지 (변경 이력이 있다면)
• 이 작업을 왜 하는지 (비즈니스 목적)

맥락이 없으면 AI는 그럴듯한 추측으로 빈 칸을 채웁니다. 그 추측이 맞을 확률? 경험상 반반입니다. 반반이면 도박이지 업무가 아닙니다.

2. 제약(Constraints) — “하지 말아야 할 것”

이것이 가장 많이 빠뜨리는 요소입니다. AI에게 해야 할 것을 말하는 건 쉽습니다. 하지 말아야 할 것을 말하는 건 생각보다 어렵습니다. 하지만 제약이 없으면 AI는 “최선”을 다합니다 — 그 “최선”이 당신의 시스템에는 재앙일 수 있습니다.

• 건드리면 안 되는 파일, 모듈, 인터페이스
• 사용하면 안 되는 라이브러리, 패턴, 접근 방식
• 이번 범위에서 제외할 것 (다음 단계로 미루는 것)
• 성능, 호환성, 보안 관련 경계선

제 세 시간짜리 삽질도 제약이 없어서 생겼습니다. “기존 호출부의 시그니처는 바꾸지 마”라는 한 줄만 있었어도 일어나지 않았을 일입니다.

3. 완료조건(Definition of Done) — “뭐가 나와야 끝인가”

“깔끔하게 해줘”는 완료조건이 아닙니다. “이런 파일이, 이런 형식으로, 이런 내용을 담아 생성되면 끝”이 완료조건입니다.

• 구체적인 산출물 (파일명, 형식, 구조)
• 어디까지가 이번 작업의 범위인지
• 무엇이 존재하면 “끝”이라고 판단할 수 있는지

완료조건이 모호하면 AI는 멈출 타이밍을 모릅니다. 과하게 하거나 부족하게 합니다. 둘 다 시간을 잡아먹습니다.

4. 검증방법(Verification) — “결과가 맞는지 어떻게 아는가”

이 요소가 빠지면 AI의 작업물을 사람이 하나하나 눈으로 확인해야 합니다. 그건 위임이 아니라 감시입니다.

• 돌려볼 테스트 (자동화된 검증)
• 비교 대상 (이전 결과물, 기존 동작)
• 확인할 수치나 조건 (정합성 체크)

검증방법까지 지시서에 포함하면 AI가 스스로 결과를 검증하고, 문제가 있으면 고치고, 통과하면 보고합니다. 이게 진짜 위임입니다. Anthropic의 프롬프트 엔지니어링 가이드에서도 구조화된 지시(structured instructions)가 일관된 결과를 만든다고 강조합니다.

네 가지를 다 채워야 하냐고요? 간단한 작업이면 맥락과 완료조건만으로도 충분합니다. 하지만 무엇을 빠뜨렸는지 의식하는 것과 처음부터 모르는 것은 완전히 다릅니다. 의식하고 빠뜨리는 건 판단이고, 모르고 빠뜨리는 건 운에 맡기는 겁니다.

Before → After 5쌍 — 같은 요청, 다른 결과

이론만으로는 감이 안 잡힙니다. 실제로 어떻게 다른지, 다섯 가지 시나리오로 보여드리겠습니다. 각 쌍에서 Before는 제가 실제로 했던 (그리고 실패했던) 방식이고, After는 그 실패를 교정한 뒤의 AI 작업 지시서입니다. 개발 업무뿐 아니라 보고서 작성, 데이터 정리처럼 누구나 마주치는 상황도 포함했습니다.

1. 기능 추가 — “쿠폰 기능 만들어줘”

❌ Before (나쁜 지시)

장바구니에 할인 쿠폰 적용 기능 추가해줘.

무엇이 잘못됐나: Claude가 쿠폰 시스템을 만들긴 합니다. 그런데 기존 가격 계산 로직을 무시하고 새로운 할인 계산 함수를 만들어버립니다. 쿠폰 테이블 스키마가 기존 DB 네이밍 규칙과 충돌합니다. 만료 쿠폰 검증이 없습니다. 중복 적용 방어도 없습니다. 결과는 “동작하는 것 같지만 프로덕션에 올리면 터지는 코드”입니다.

✅ After (좋은 지시)

[맥락]
여행 예약 시스템의 장바구니에 할인 쿠폰 기능을 추가한다.
현재 가격 계산은 src/pricing/calculator.py의 PriceCalculator 클래스가 담당한다.
할인은 반드시 이 클래스의 apply_discount() 메서드를 통해 적용해야 한다.
DB는 PostgreSQL, 마이그레이션 도구는 Alembic.

[제약]
- 쿠폰 타입: 정액 할인, 정률 할인 2종만 지원 (포인트 차감은 이번 범위 아님)
- 이미 적용된 쿠폰과 중복 사용 불가
- 만료된 쿠폰은 적용 시점에 HTTP 422 반환
- 기존 PriceCalculator의 퍼블릭 인터페이스를 변경하지 않는다

[완료조건]
- POST /api/cart/{cart_id}/coupon 엔드포인트 동작
- PriceCalculator.apply_discount()를 경유하는 할인 적용
- Alembic 마이그레이션 파일 생성
- 쿠폰 관리(CRUD) API는 이번 범위에 포함하지 않음

[검증방법]
- pytest: 정액할인 / 정률할인 / 만료쿠폰 거부 / 중복적용 거부 — 4가지 시나리오
- 기존 test_pricing.py 전체 통과 확인
- mypy --strict 통과

무엇이 달라지나: Claude는 PriceCalculator의 기존 구조를 먼저 읽고, apply_discount()에 맞는 형태로 쿠폰 할인을 설계합니다. 테이블 네이밍도 기존 Alembic 히스토리에서 규칙을 가져옵니다. 만료·중복 검증이 처음부터 들어갑니다. 결과물이 나온 뒤 4가지 테스트를 돌려 스스로 확인합니다. “되는 것 같은” 코드가 아니라 “검증된” 코드가 나옵니다.

2. 보고서 — “매출 분석해줘”

❌ Before (나쁜 지시)

이번 주 매출 데이터 분석해서 보고서 만들어줘.

무엇이 잘못됐나: Claude가 데이터를 분석하긴 합니다. 그런데 누가 읽을 보고서인지 모르니 학술 논문 스타일로 씁니다. 전주 대비 비교가 빠져 있습니다. 기존 보고서와 형식이 다릅니다. “분석”이라는 말이 워낙 넓어서, 원하지 않는 예측과 추천까지 덕지덕지 붙여놓습니다. 결국 처음부터 다시 만듭니다.

✅ After (좋은 지시)

[맥락]
매주 월요일 팀장 회의에서 쓸 주간 매출 리포트를 만든다.
데이터: sales_weekly.csv (컬럼: date, product_category, revenue, units, region)
이전 보고서: reports/week26.md — 동일 형식을 유지한다.

[제약]
- 마크다운 형식, 표(table) 포함
- 전주 대비 증감률 필수 표기
- 카테고리별·지역별 교차 분석 포함
- 해석, 추천, 예측은 넣지 않는다 — 팩트와 수치만

[완료조건]
- reports/week27.md 파일 생성
- 구성: 요약 3줄 + 카테고리별 표 + 지역별 표 + 특이사항 목록

[검증방법]
- week26.md와 형식(헤더 구조, 표 컬럼) 일치 확인
- CSV 원본의 revenue 합계와 보고서의 총매출 수치 일치 확인

무엇이 달라지나: 이전 보고서를 참조하게 했으므로 형식이 일관됩니다. “팩트만”이라는 제약 하나로 불필요한 해석이 사라집니다. 검증방법으로 합계 교차검증을 넣었으므로 숫자 오류가 잡힙니다. 개발자가 아니어도 이 프레임은 그대로 쓸 수 있습니다. 보고서, 제안서, 회의록 정리 — 뭐든 같은 구조입니다.

3. 버그 수정 — “로그인이 안 돼”

❌ Before (나쁜 지시)

로그인이 안 돼. 이 에러 로그 보고 고쳐줘.

[에러 로그 붙여넣기]

무엇이 잘못됐나: 에러 로그만 주면 Claude는 그 에러 메시지의 직접 원인만 잡습니다. 표면적 증상은 고쳐지는데, 진짜 원인은 다른 곳에 있을 수 있습니다. 또한 수정 범위에 제한이 없으니 인증 모듈 전체를 리팩토링해버리는 사태도 벌어집니다. “고쳤는데 다른 데가 깨졌어요”의 시작입니다.

✅ After (좋은 지시)

[맥락]
도서 관리 시스템의 로그인이 특정 조건에서 실패한다.
- 언제부터: 이번 주 수요일 배포 이후 (PR #142 — 세션 타임아웃 설정 변경)
- 재현 조건: 비밀번호에 특수문자(@, #, !)가 포함된 계정만 실패
- 정상 계정: 영문+숫자 비밀번호는 문제없음

[에러 로그]
AuthenticationError: invalid credential format at line 47 ...

[제약]
- PR #142의 변경분(session timeout)과 관련 있을 가능성이 높다. 거기서부터 확인
- auth/ 디렉토리 밖의 코드는 수정하지 않는다
- 비밀번호 해싱 로직(bcrypt)은 건드리지 않는다
- 핫픽스 수준: 최소 변경으로 해결. 구조 개선은 별도 PR

[완료조건]
- 특수문자 포함 계정으로 로그인 성공
- 기존 정상 계정의 로그인에 영향 없음

[검증방법]
- 특수문자 조합 5종(@, #, !, 공백, 유니코드)에 대한 테스트 추가
- 기존 tests/test_auth.py 전체 통과

무엇이 달라지나: “수요일 배포 이후”라는 시간 단서와 “PR #142″라는 변경 지점을 줬으므로, Claude는 전체 코드를 뒤지는 대신 해당 커밋의 diff부터 확인합니다. “auth/ 밖은 건드리지 마”로 폭발 반경을 제한했습니다. 버그 수정에서 제약은 수정 범위의 울타리입니다. 울타리 없으면 AI는 “근본 원인을 고치겠다”며 시스템 절반을 들어냅니다.

4. 데이터 정리 — “이 CSV 좀 정리해줘”

❌ Before (나쁜 지시)

이 CSV 파일 좀 정리해줘. 지저분해.

무엇이 잘못됐나: “지저분하다”는 사람마다 의미가 다릅니다. Claude가 생각하는 “정리”와 당신이 원하는 “정리”가 같을 확률은 낮습니다. 중복 행을 지우면서 최신 데이터가 아니라 최초 데이터를 남길 수 있습니다. 전화번호 형식을 통일하면서 해외 번호를 잘라버릴 수 있습니다. 인코딩을 바꾸면서 원본을 덮어쓸 수 있습니다.

✅ After (좋은 지시)

[맥락]
외부 업체에서 받은 거래처 목록(vendors.csv, 약 2,340행)을 사내 시스템에 임포트해야 한다.
현재 상태:
- 인코딩 혼재 (일부 EUC-KR, 일부 UTF-8)
- 전화번호 형식 불일치 (하이픈 있는 것, 없는 것, 지역번호 괄호 등)
- 중복 행 존재

[제약]
- 출력 인코딩: UTF-8 (BOM 없이)
- 전화번호 형식: 010-0000-0000 (하이픈 포함, 지역번호는 02-000-0000 형태)
- 중복 판단 기준: biz_no(사업자등록번호) 컬럼 — 중복 시 updated_at이 최신인 행만 남긴다
- 원본 파일은 절대 수정하지 않는다. 결과는 vendors_cleaned.csv로 별도 저장

[완료조건]
- vendors_cleaned.csv 생성
- 전 행 UTF-8, 전화번호 정규화, 중복 제거 완료
- 처리 요약 로그를 터미널에 출력 (제거된 중복 수, 인코딩 변환 수, 전화번호 수정 수)

[검증방법]
- file --mime vendors_cleaned.csv → UTF-8 확인
- 전화번호 컬럼: 정규식 ^0\d{1,2}-\d{3,4}-\d{4}$ 100% 매치
- biz_no unique count = 전체 행 수 (중복 0)

무엇이 달라지나: “원본은 절대 수정하지 않는다”라는 제약 하나가 복구 불가능한 사고를 예방합니다. 중복 판단 기준과 어떤 행을 남길지까지 정해줬으므로 데이터 손실이 없습니다. 검증방법으로 정규식 매치까지 지정했으니 Claude가 자체적으로 품질을 확인하고 문제가 있으면 재처리합니다.

5. 리팩토링 — “이 코드 깔끔하게 해줘”

❌ Before (나쁜 지시)

이 코드 좀 깔끔하게 정리해줘.

무엇이 잘못됐나: 이게 바로 제가 첫날 세 시간을 날린 그 지시입니다. “깔끔하게”에는 백 가지 해석이 있습니다. 변수명을 바꿀 수도 있고, 함수를 쪼갤 수도 있고, 디자인 패턴을 적용할 수도 있고, 라이브러리를 교체할 수도 있습니다. Claude는 가능한 모든 개선을 동시에 하려고 합니다. 결과: 코드는 교과서처럼 예뻐졌지만, 기존 시스템과의 호환성은 산산조각입니다.

✅ After (좋은 지시)

[맥락]
여행 예약 시스템의 src/booking/processor.py (약 800줄)를 리팩토링한다.
문제: BookingProcessor 클래스가 예약 생성·결제 처리·알림 발송을 모두 담당.
목표: 단일 책임 원칙(SRP)에 따라 3개 클래스로 분리.

[제약]
- 외부에서 BookingProcessor를 호출하는 코드의 시그니처를 바꾸지 않는다
  → Facade 패턴으로 기존 인터페이스 유지
- 결제 처리 로직(process_payment 메서드)은 이번 범위에서 제외 — 별도 PR
- 새 파일: src/booking/creator.py, src/booking/notifier.py
- import 경로가 바뀌는 외부 모듈이 있으면 re-export로 호환성 유지

[완료조건]
- BookingProcessor → BookingCreator + BookingNotifier 분리
- BookingProcessor는 두 클래스를 조합하는 Facade로 남김
- 분리된 각 클래스 100줄 이내

[검증방법]
- 기존 tests/test_booking.py 전체 통과 (시그니처 유지 검증)
- mypy --strict 통과
- 새 클래스별 단위 테스트 최소 3개씩 추가

무엇이 달라지나: “깔끔하게”가 “SRP에 따른 3개 클래스 분리”로 구체화됐습니다. “시그니처를 바꾸지 마”로 호출부가 보호됩니다. “결제 로직은 제외”로 범위가 절반으로 줄었습니다. 이 지시를 받은 Claude는 먼저 기존 호출부를 검색하고, Facade를 설계하고, 테스트를 먼저 확인한 뒤 분리를 시작합니다. 제가 세 시간을 날린 그 작업이, 이 지시서로는 25분 만에 끝났습니다.

다섯 쌍을 관통하는 패턴이 보이시나요? 좋은 AI 작업 지시서는 “할 것”보다 “하지 말 것”이 더 많습니다. AI는 기본적으로 할 수 있는 모든 것을 하려고 합니다. 제약이 그 에너지를 올바른 방향으로 모아줍니다.

Plan Mode — 실행 전에 설계도를 먼저 받는다

아무리 좋은 작업 지시서를 써도, AI가 그걸 제대로 이해했는지 어떻게 알 수 있을까요? 여기서 Plan Mode가 등장합니다.

Claude Code에서 Shift+Tab을 누르면 입력 모드가 Plan과 Act 사이에서 전환됩니다. Plan 모드에서는 Claude가 코드를 수정하지 않고, 분석 결과와 실행 계획만 제시합니다. Claude Code 공식 문서에서도 복잡한 작업에서 Plan 모드를 먼저 사용하도록 권장합니다.

이걸 설계 리뷰로 쓰는 겁니다.

실제 워크플로를 보겠습니다. 위의 5번째 예시(리팩토링)를 Plan Mode로 먼저 실행하면 이런 흐름이 됩니다:

# 1단계: Plan Mode로 전환 (Shift+Tab → "Plan" 표시 확인)

# 2단계: 작업 지시서를 그대로 입력
여행 예약 시스템의 src/booking/processor.py를 리팩토링한다.
BookingProcessor → BookingCreator + BookingNotifier 분리.
외부 호출 시그니처는 유지. 결제 로직은 제외.

# 3단계: Claude가 "계획"을 보여줌 (코드 수정 없이)
┌─────────────────────────────────────────────┐
│  분석 결과:                                    │
│  - BookingProcessor를 호출하는 외부 모듈 3개 확인  │
│    (api/routes.py, services/checkout.py,      │
│     workers/batch_booking.py)                 │
│                                               │
│  실행 계획:                                    │
│  1단계: BookingCreator 클래스 추출              │
│   - create_booking()과 관련 private 메서드 분리  │
│   - BookingProcessor에 위임 호출 추가           │
│                                               │
│  2단계: BookingNotifier 클래스 추출              │
│   - send_confirmation(), send_reminder() 분리  │
│                                               │
│  3단계: BookingProcessor → Facade              │
│   - 기존 퍼블릭 메서드 시그니처 100% 유지        │
│   - 내부적으로 Creator, Notifier에 위임         │
│                                               │
│  ⚠ 위험 요소:                                  │
│  - process_payment()이 create_booking()과      │
│    트랜잭션을 공유함 → 분리 시 트랜잭션 경계 조정 │
│  - workers/batch_booking.py에서               │
│    BookingProcessor._internal_validate() 직접   │
│    호출 → protected 메서드 접근 경로 필요        │
│                                               │
│  이 계획으로 진행할까요?                         │
└─────────────────────────────────────────────┘

Plan Mode가 잡아낸 두 가지 위험 요소가 보이시나요? 트랜잭션 공유 문제와 내부 메서드 직접 호출 문제. 이걸 실행 전에 알았으니 계획을 조정할 수 있습니다.

# 4단계: 계획 조정
좋아. 두 번째 위험 요소 — _internal_validate()는 BookingCreator의
public validate() 메서드로 승격시켜줘. batch_booking.py의 호출부도
같이 바꿔야 해. 이건 제약에서 "외부 시그니처 유지"의 예외로 처리.

# 5단계: 조정된 계획 확인 → Act 모드로 전환 (Shift+Tab) → 실행

이 과정은 신입 개발자에게 설계 리뷰를 받는 것과 본질적으로 같습니다. 차이는 속도입니다. 사람과의 설계 리뷰는 30분짜리 미팅이 필요합니다. Plan Mode는 30초면 됩니다.

Plan Mode를 써야 할 때와 안 써도 될 때:

• 써야 할 때: 여러 파일에 걸친 변경, 기존 코드 구조 변경, 삭제나 이동이 포함된 작업, 처음 다루는 코드베이스
• 안 써도 될 때: 단일 함수 수정, 테스트 추가, 문서 작성, 이미 명확한 한 가지 변경

판단 기준은 간단합니다. “되돌리기 어려운 변경인가?” 그렇다면 Plan Mode. 아니면 바로 실행. Plan Mode를 쓰지 않더라도 지시서에 “먼저 계획을 보여주고, 내가 승인하면 실행해”라고 한 줄 추가하는 것만으로도 같은 효과를 낼 수 있습니다.

함정 — ‘알아서 잘’의 진짜 비용과 되돌리기 습관

AI 작업 지시서의 네 가지 요소를 알았으니, 이제 이 회차에서 반드시 피해야 할 함정 세 가지를 짚겠습니다.

함정 1: “알아서 잘”의 숨은 비용

“간단한 건데 뭘 그렇게 자세히 써?”라는 생각이 듭니다. 맞습니다. 파일 하나 고치는 간단한 작업에 작업 지시서를 쓸 필요 없습니다. 문제는 “간단한 건데”라고 생각한 작업이 간단하지 않을 때입니다.

무중단이 기본인 시스템을 운영하면서 깨달은 건, 사고는 항상 “간단한 변경”에서 시작된다는 겁니다. “알아서 잘”로 시작하면 AI는 빈 칸을 그럴듯한 추측으로 채웁니다. 그 추측이 맞으면 아무 문제 없습니다. 틀리면 — 디버깅하는 데 드는 시간이 작업 지시서 쓰는 시간의 열 배입니다.

규칙을 하나 만들었습니다. “5분 이상 걸릴 것 같은 작업이면 작업 지시서를 쓴다.” 작업 지시서를 쓰는 데 2분이 들어도, 5분짜리 작업이 30분짜리 디버깅으로 번지는 걸 막아줍니다.

함정 2: 체크포인트를 모르면 실험이 도박이 된다

Claude Code는 파일을 수정할 때마다 자동으로 체크포인트를 저장합니다. 이 체크포인트는 Git 커밋과는 별개로, Claude Code 내부에서 관리되는 스냅샷입니다. 작업 지시서가 완벽하더라도, 결과가 마음에 안 들 수 있습니다. 그때 체크포인트가 안전망이 됩니다.

체크포인트 활용 습관:

• 큰 변경 전에는 직접 Git 커밋을 해두세요. 체크포인트는 편리하지만, Git 커밋을 대체하지는 않습니다.
• Claude가 수정을 제안했는데 방향이 잘못됐다고 느끼면, 거절하고 다시 지시하면 됩니다. 이미 적용된 변경이라면 체크포인트로 롤백합니다.
• 실험적인 접근을 시도할 때는 “이 방식으로 먼저 해보고, 결과가 안 좋으면 다른 방식을 시도하자”라고 명시하세요. 두 가지를 비교한 뒤 나은 쪽을 채택하는 것이 위임의 고급 기술입니다.

함정 3: 멈추는 법을 모르면 손실이 커진다

Claude Code가 잘못된 방향으로 달려가고 있다면 — Esc 키를 두 번 누르세요. 첫 번째 Esc는 현재 도구 실행을 중단하고, 두 번째 Esc는 전체 턴을 취소합니다. 그리고 무엇이 잘못됐는지 다시 설명하면 됩니다.

많은 분들이 AI가 작업하는 걸 지켜보면서 “좀 이상한데… 끝까지 해보면 괜찮겠지”라고 기대합니다. 거의 항상 괜찮지 않습니다. 방향이 틀린 채로 10분을 달린 결과물을 고치는 것보다, 2분 만에 멈추고 지시를 교정하는 게 빠릅니다.

이 세 가지 습관을 한 문장으로 요약하면:

“지시서를 쓰고, 계획을 확인하고, 잘못되면 즉시 멈춘다.”

이게 AI에게 일을 위임하는 사람의 기본 루틴입니다. 프롬프트를 “잘 쓰는” 게 아니라, 위임의 구조를 갖추는 겁니다. 그리고 이 구조는 AI뿐 아니라 사람에게 일을 맡길 때도 동일하게 적용됩니다. 20년간 후배 개발자에게 일을 맡기면서 체득한 것과 AI에게 일을 맡기는 원칙이 완전히 같았다는 걸, 이 삽질을 통해 다시 깨달았습니다.

이번 회차의 수익화 지점

오늘 다룬 4요소 프레임워크(맥락·제약·완료조건·검증방법)는 그 자체로 판매 가능한 자산입니다. 형태를 하나 제안합니다:

“AI 작업 지시서 템플릿 팩” — 업무 유형별(기능 개발, 버그 수정, 데이터 분석, 문서 작성, 코드 리뷰) 빈칸 채우기 형태의 지시서 템플릿. 각 템플릿에 오늘 본 4요소가 미리 항목으로 잡혀 있어서, 빈칸만 채우면 좋은 지시서가 나오는 구조입니다. 노션 템플릿이든 마크다운 파일이든, 만드는 데 하루. 수요가 있냐고요? “AI한테 뭐라고 말해야 해요?”는 지금 가장 많이 나오는 질문입니다. 그 질문에 대한 구조화된 답이 템플릿입니다.

← 이전: 3화 — 첫 30분: 설치부터 첫 성공 경험까지
→ 다음: 5화 — CLAUDE.md: AI에게 영구적인 작업 매뉴얼을 심는 법
관련 회차: 1화 — 2026년 7월, AI 도구 이야기를 다시 써야 하는 이유 | 6화 — 권한과 샌드박스: AI의 행동 범위를 코드로 통제하는 법

오늘은 한 번의 대화에서 좋은 지시를 쓰는 법을 다뤘습니다. 그런데 매번 4요소를 처음부터 쓰는 건 비효율적이지 않을까요? 프로젝트의 맥락, 코딩 규칙, 금지 사항을 한 번 써두면 영구적으로 적용되는 파일이 있습니다. 다음 5화에서는 CLAUDE.md — 프로젝트의 영구 작업 매뉴얼을 만드는 법을 다룹니다. 이번 회의 4요소를 “매번 쓰는 것”에서 “한 번만 쓰는 것”으로 바꿔주는 도구입니다.

---

자주 묻는 질문

AI 작업 지시서와 프롬프트의 차이점은 무엇인가요?

프롬프트는 “뭘 해줘”라는 단순한 요청이고, 작업 지시서는 “이런 상황에서, 이런 조건 안에서, 이런 결과물을, 이렇게 확인할 수 있도록 해줘”라는 구조화된 지시입니다. 작업 지시서는 맥락, 제약, 완료조건, 검증방법의 4가지 요소로 구성되며, 이 차이가 30분이면 끝날 일을 3시간짜리 삽질로 만드는 결과의 격차를 만듭니다.

AI에게 코드 작업을 시킬 때 제약 조건을 왜 꼭 명시해야 하나요?

제약이 없으면 AI는 스스로 판단한 “최선”을 다하는데, 그 최선이 기존 시스템에는 재앙이 될 수 있습니다. 예를 들어 “기존 호출부의 시그니처는 바꾸지 마”라는 한 줄만 있었어도, 함수 시그니처 변경으로 세 군데 호출부가 동시에 깨지는 사고를 막을 수 있었습니다. 건드리면 안 되는 파일, 사용하면 안 되는 패턴, 이번 범위에서 제외할 것 등을 반드시 명시해야 합니다.

AI 작업 지시서의 4요소는 구체적으로 무엇인가요?

맥락(Context), 제약(Constraints), 완료조건(Definition of Done), 검증방법(Verification) 네 가지입니다. 맥락은 현재 상황과 작업 이유를, 제약은 하지 말아야 할 것을, 완료조건은 구체적인 산출물과 범위를, 검증방법은 결과가 맞는지 확인하는 테스트나 조건을 뜻합니다. 검증방법까지 포함하면 AI가 스스로 결과를 검증하고 문제를 고쳐서 보고하는 진짜 위임이 가능해집니다.