AI 코딩 에이전트 성능을 확 올리는 실전 스킬: Context Pack 만들기

요즘 AI 코딩 에이전트를 쓰다 보면 이런 생각이 든다.

“얘가 멍청한 건가?”
“아니면 내가 일을 못 맡긴 건가?”

대부분은 후자다.

AI 코딩 에이전트가 이상한 코드를 만드는 이유는 모델이 약해서만은 아니다.
프로젝트 맥락을 제대로 못 받았기 때문이다.

개발자는 이미 알고 있다.

이 파일은 건드리면 안 되고,
이 로직은 UseCase에 있어야 하고,
이 테스트는 꼭 돌려야 하고,
이 API는 예전 버전이라 쓰면 안 되고,
이 폴더는 레거시라 참고만 해야 한다는 걸.

그런데 AI는 모른다.

그래서 요즘 해외에서는 “프롬프트 잘 쓰기”보다 Context Engineering 이야기가 더 많이 나온다.

말은 거창한데, 실무식으로 풀면 이거다.

AI에게 일을 시키기 전에
필요한 파일, 규칙, 금지사항, 테스트 명령, 완료 기준을
작은 패키지로 만들어서 관리하기

나는 이걸 그냥 Context Pack이라고 부른다.

AI에게 “이거 고쳐줘”라고 던지는 게 아니라,
“이 맥락 안에서만 움직여”라고 작업장을 깔아주는 방식이다.

---

1. AI에게 repo 전체를 읽히면 똑똑해질까?

많은 사람이 처음에는 이렇게 쓴다.

이 프로젝트 전체를 보고 결제 버그 고쳐줘.

뭔가 좋아 보인다.

프로젝트 전체를 보여주면 AI가 더 많이 이해할 것 같기 때문이다.

그런데 실제로는 반대인 경우가 많다.

AI는 너무 많은 파일을 받으면 중요한 것과 덜 중요한 것을 구분하지 못한다.

사람도 똑같다.

버그 하나 고치라고 했는데 회사 위키 전체, 3년치 PR, 전체 코드베이스, 회의록까지 던져주면 더 잘할까?

아니다.

오히려 헷갈린다.

AI 코딩 에이전트도 마찬가지다.

좋은 결과를 내려면 “많은 컨텍스트”보다 “정확한 컨텍스트”가 필요하다.

나쁜 컨텍스트:
- 프로젝트 전체
- 관련 없는 문서
- 오래된 코드
- 너무 긴 에러 로그
- 실패한 시도 기록 전부

좋은 컨텍스트:
- 이번 작업에 필요한 파일
- 현재 버그 증상
- 재현 조건
- 수정 가능한 범위
- 건드리면 안 되는 파일
- 테스트 명령
- 완료 기준

AI에게 많이 주는 게 실력이 아니다.

딱 필요한 것만 주는 게 실력이다.

---

2. Context Pack이 필요한 순간

모든 작업에 Context Pack이 필요한 건 아니다.

버튼 문구 하나 바꾸는 일에 굳이 문서 만들 필요는 없다.

구매 버튼 문구를 “결제하기”로 바꿔줘.
Localizable만 수정해줘.

이 정도면 충분하다.

Context Pack이 진짜 힘을 발휘하는 건 이런 작업이다.

- 버그 원인이 여러 계층에 걸쳐 있을 때
- ViewModel, UseCase, Repository가 같이 얽혀 있을 때
- 테스트까지 같이 추가해야 할 때
- AI가 자꾸 엉뚱한 파일을 고칠 때
- 팀 아키텍처 규칙이 중요한 작업일 때
- 개인정보, 인증, 결제, 로그가 관련될 때
- 기존 코드를 유지하면서 작은 diff로 고쳐야 할 때

특히 AI가 자꾸 “과하게 친절하게” 고치는 팀이라면 Context Pack을 무조건 써야 한다.

AI에게 이렇게 말하면 위험하다.

결제 버튼 중복 탭 버그 고쳐줘.

AI는 이렇게 생각할 수 있다.

결제 UI도 정리하고,
ViewModel도 리팩토링하고,
PaymentRepository도 바꾸고,
NetworkClient도 손보고,
버튼 컴포넌트도 개선하면 좋겠네?

그 결과 PR이 커진다.

사람 리뷰어는 지친다.

결국 AI가 만든 생산성이 사람 리뷰 비용으로 날아간다.

---

3. Context Pack의 핵심 구조

Context Pack은 길 필요 없다.

오히려 짧아야 한다.

내 기준으로는 이 정도면 충분하다.

context/
├── task.md
├── files.md
├── rules.md
├── tests.md
└── done.md

역할은 단순하다.

task.md
- 이번 작업이 뭔지

files.md
- 봐야 할 파일과 건드릴 수 있는 파일

rules.md
- 지켜야 할 팀 규칙

tests.md
- 실행해야 할 테스트

done.md
- 완료 기준

AI에게 프로젝트 전체를 던지는 대신 이 다섯 장을 준다.

이게 생각보다 강력하다.

---

4. task.md: 문제를 한 화면에 고정한다

먼저 작업을 짧게 고정한다.

예를 들어 iOS 앱에서 사용자가 결제 버튼을 빠르게 두 번 누르면 주문 생성 요청이 중복으로 나가는 버그가 있다고 하자.

task.md는 이렇게 쓴다.

# Task

결제 버튼을 빠르게 여러 번 탭했을 때 주문 생성 요청이 중복 실행되는 문제를 수정한다.

## Current Problem

사용자가 결제 버튼을 빠르게 두 번 이상 탭하면 `createOrder` 요청이 중복으로 실행될 수 있다.

현재 화면에서는 버튼을 누른 직후 로딩 상태가 반영되기 전에 추가 탭이 들어올 수 있고, 이 경우 같은 장바구니 기준으로 주문 생성 요청이 여러 번 발생할 수 있다.

## Expected Behavior

- 결제 요청이 진행 중이면 결제 버튼은 다시 눌리지 않아야 한다.
- 동일 화면 상태에서 `createOrder`는 한 번만 실행되어야 한다.
- 요청 성공 시 주문 완료 화면으로 이동한다.
- 요청 실패 시 안전한 에러 메시지를 보여준다.
- 실패 후에는 사용자가 다시 결제를 시도할 수 있어야 한다.

## Not Goal

- 결제 API 스펙 변경
- 주문 완료 화면 디자인 변경
- 결제 수단 추가
- 장바구니 구조 변경
- Analytics 구조 변경
- DesignSystem 버튼 컴포넌트 리팩토링

이 정도면 AI가 헛발질할 확률이 줄어든다.

중요한 건 Not Goal이다.

AI는 시키지 않은 일도 잘한다.

그래서 하지 말아야 할 일을 적어야 한다.

---

5. files.md: AI의 활동 반경을 제한한다

AI 에이전트가 제일 자주 사고치는 부분이 파일 범위다.

그래서 files.md를 만든다.

# Files

## Read First

- CheckoutView.swift
- CheckoutViewModel.swift
- CreateOrderUseCase.swift
- PaymentRepository.swift
- CheckoutViewModelTests.swift

## Allowed to Edit

- CheckoutViewModel.swift
- CheckoutViewModelTests.swift

## Do Not Edit Without Approval

- CheckoutView.swift
- OrderCompleteView.swift
- CreateOrderUseCase.swift
- PaymentRepository.swift
- PaymentAPI.swift
- NetworkClient.swift
- AnalyticsLogger.swift
- DesignSystem/
- Localizable.strings

## Reason

이번 버그는 결제 API나 화면 디자인 문제가 아니라,
결제 요청 중복 실행을 막지 못하는 UI 상태 관리 문제다.

따라서 우선 ViewModel과 관련 테스트 안에서 해결한다.

이 파일 하나가 PR 크기를 줄여준다.

AI에게 “관련 파일 찾아서 고쳐줘”라고 하면 너무 넓게 움직인다.

반대로 “읽을 파일”과 “수정 가능한 파일”을 나누면 훨씬 얌전해진다.

특히 실무에서는 이 구분이 중요하다.

Read First:
AI가 이해하기 위해 읽어야 하는 파일

Allowed to Edit:
실제로 수정해도 되는 파일

Do Not Edit:
건드리면 리뷰 비용이 커지거나 위험한 파일

이렇게 해두면 에이전트가 NetworkClient나 DesignSystem을 괜히 고칠 확률이 줄어든다.

---

6. rules.md: 팀의 규칙을 문서로 만든다

AI는 팀의 규칙을 모른다.

그래서 규칙을 짧게 써줘야 한다.

# Rules

## Architecture

- SwiftUI View는 API를 직접 호출하지 않는다.
- ViewModel은 UI 상태를 관리한다.
- UseCase는 주문 생성 흐름을 담당한다.
- Repository는 데이터 접근만 담당한다.
- API 응답 모델은 이번 작업에서 변경하지 않는다.

## Concurrency

- UI 상태는 MainActor에서 변경한다.
- 결제 요청이 진행 중이면 추가 요청을 막는다.
- 요청 성공 또는 실패 후에는 상태를 명확히 정리한다.
- 실패 후 재시도는 가능해야 한다.

## Payment Safety

- 동일 사용자 액션에서 주문 생성 요청이 중복 실행되면 안 된다.
- 결제 성공 상태에서 다시 요청을 보내면 안 된다.
- 결제 실패 메시지는 서버 원문을 그대로 노출하지 않는다.
- 결제 관련 로그에 카드 정보, 토큰, 개인정보를 남기지 않는다.

## Code Style

- 큰 리팩토링 금지
- 새 라이브러리 추가 금지
- public API 변경 금지
- 기존 테스트 스타일 유지
- 불필요한 주석 추가 금지

이게 진짜 중요하다.

AI가 코드를 못 짜서 문제라기보다,
팀 규칙을 모르고 코드를 짜서 문제가 되는 경우가 많다.

규칙은 길게 쓰지 않는다.

길면 안 읽힌다.

명령형으로 짧게 쓴다.

하지 마라.
이렇게 해라.
이 파일은 건드리지 마라.
테스트는 이걸 돌려라.

AI에게 예의 차릴 필요 없다.

애매하게 말하면 애매하게 고친다.

---

7. tests.md: “테스트 해줘”를 금지한다

AI에게 이렇게 말하면 별로다.

테스트도 추가해줘.

너무 흐릿하다.

대신 테스트 기준을 써준다.

# Tests

## Required Test Cases

- 결제 버튼을 여러 번 눌러도 `createOrder`는 한 번만 호출된다.
- 결제 요청 중에는 `isSubmitting`이 true가 된다.
- 결제 요청 성공 후 주문 완료 상태가 반영된다.
- 결제 요청 실패 후 `isSubmitting`이 false로 돌아온다.
- 결제 실패 후 사용자는 다시 결제를 시도할 수 있다.
- 결제 실패 시 안전한 에러 메시지를 표시한다.

## Preferred Test File

- CheckoutViewModelTests.swift

## Commands

xcodebuild test \
  -scheme MyApp \
  -destination 'platform=iOS Simulator,name=iPhone 16'

## If You Cannot Run Tests
Do not say tests passed.

Report:
Tests not run.
Reason:
Suggested command:

여기서 핵심은 마지막이다.

AI가 테스트를 못 돌렸으면 못 돌렸다고 말하게 해야 한다.

“통과할 것으로 보입니다” 같은 말은 금지해야 한다.

실무에서는 그 말이 제일 위험하다.

---

8. done.md: 완료 기준을 못 박는다

AI가 언제 멈춰야 하는지도 알려줘야 한다.

# Done Criteria

This task is complete when:

- `createOrder` cannot be called multiple times from repeated taps.
- `isSubmitting` prevents duplicate submit.
- Success state is handled once.
- Failure state resets submit state.
- User can retry after failure.
- Required tests are added or updated.
- No files outside Allowed to Edit are modified.
- No new dependency is added.
- Test command is executed or failure reason is reported.

## Final Report Format

## Summary

## Files Changed

## Validation

## Risk

## Not Changed

완료 형식까지 박아두면 리뷰가 편해진다.

AI가 마지막에 장황하게 말하는 걸 줄일 수 있다.

---

9. 이제 AI에게 이렇게 시킨다

Context Pack을 만들었으면 프롬프트는 짧아진다.

나쁜 프롬프트는 이렇다.

결제 버튼 중복 탭 버그 고쳐줘. 주문이 두 번 생성되는 것 같아.

좋은 프롬프트는 이렇다.

context/checkout-duplicate-submit/ 아래 문서를 읽고 작업해줘.

순서:
1. task.md 읽기
2. files.md 읽기
3. rules.md 읽기
4. tests.md 읽기
5. done.md 읽기

제약:
- Allowed to Edit 파일만 수정
- Do Not Edit 파일은 수정 금지
- 큰 리팩토링 금지
- 테스트 실행 결과를 마지막에 보고

먼저 수정 계획을 5줄 이내로 말하고,
그다음 구현해줘.

이렇게 하면 AI가 훨씬 다르게 움직인다.

중요한 건 “구현해줘” 앞에 작업장을 깔아주는 것이다.

---

10. iOS 코드로 보면 이렇게 바뀐다

이제 실제 버그를 보자.

문제가 있는 ViewModel은 대충 이런 형태일 수 있다.

@MainActor
final class CheckoutViewModel: ObservableObject {
    @Published var isSubmitting = false
    @Published var errorMessage: String?
    @Published var route: Route?

    private let createOrderUseCase: CreateOrderUseCase

    init(createOrderUseCase: CreateOrderUseCase) {
        self.createOrderUseCase = createOrderUseCase
    }

    func submitOrder() async {
        isSubmitting = true
        errorMessage = nil

        do {
            let order = try await createOrderUseCase.execute()
            route = .orderComplete(order.id)
        } catch {
            errorMessage = "결제에 실패했습니다."
        }

        isSubmitting = false
    }
}

겉으로 보면 문제 없어 보인다.

하지만 버튼을 빠르게 여러 번 누르면 submitOrder()가 여러 번 들어올 수 있다.

첫 번째 탭
→ submitOrder 실행

두 번째 탭
→ isSubmitting이 UI에 반영되기 전에 submitOrder 재실행 가능

결과
→ createOrder 중복 호출 가능

막아야 할 것은 단순하다.

이미 제출 중이면 바로 return
성공 후 중복 route 처리 방지
실패하면 다시 시도 가능하게 상태 복구

수정하면 이런 방향이 된다.

@MainActor
final class CheckoutViewModel: ObservableObject {
    enum Route: Equatable {
        case orderComplete(String)
    }

    @Published private(set) var isSubmitting = false
    @Published var errorMessage: String?
    @Published var route: Route?

    private let createOrderUseCase: CreateOrderUseCase

    init(createOrderUseCase: CreateOrderUseCase) {
        self.createOrderUseCase = createOrderUseCase
    }

    var canSubmit: Bool {
        !isSubmitting && route == nil
    }

    func submitOrder() async {
        guard canSubmit else { return }

        isSubmitting = true
        errorMessage = nil

        do {
            let order = try await createOrderUseCase.execute()
            route = .orderComplete(order.id)
        } catch {
            errorMessage = "결제에 실패했습니다. 잠시 후 다시 시도해주세요."
            isSubmitting = false
        }
    }
}

이 코드의 포인트는 화려한 Swift Concurrency가 아니다.

핵심은 이거다.

중복 진입을 guard로 막는다.
요청 중에는 버튼 상태를 잠근다.
성공 후에는 완료 route가 생기므로 다시 제출하지 않는다.
실패 후에는 isSubmitting을 false로 되돌려 재시도 가능하게 한다.

AI에게 그냥 “결제 버그 고쳐줘”라고 하면 이런 선에서 끝나지 않을 수 있다.

어쩌면 버튼 컴포넌트를 바꾸거나, Repository에 중복 방지 로직을 넣거나, API에 idempotency key를 추가하려고 할 수도 있다.

그게 항상 틀린 건 아니다.

하지만 이번 작업 범위가 “화면 중복 탭 방지”라면, ViewModel 안에서 먼저 작게 막는 게 맞다.

이게 Context Pack의 효과다.

AI를 똑똑하게 만드는 게 아니라,
AI가 너무 멀리 가지 않게 만드는 것이다.

---

11. 테스트도 Context Pack 기준으로 나온다

테스트는 대충 이런 방향으로 잡을 수 있다.

@MainActor
final class CheckoutViewModelTests: XCTestCase {
    func test_submitOrder_whenCalledMultipleTimes_callsCreateOrderOnlyOnce() async {
        let useCase = MockCreateOrderUseCase()
        let viewModel = CheckoutViewModel(createOrderUseCase: useCase)

        async let first: Void = viewModel.submitOrder()
        async let second: Void = viewModel.submitOrder()

        _ = await (first, second)

        XCTAssertEqual(useCase.executeCallCount, 1)
    }

    func test_submitOrder_whenFailed_allowsRetry() async {
        let useCase = MockCreateOrderUseCase()
        useCase.result = .failure(CheckoutError.paymentFailed)

        let viewModel = CheckoutViewModel(createOrderUseCase: useCase)

        await viewModel.submitOrder()

        XCTAssertFalse(viewModel.isSubmitting)
        XCTAssertTrue(viewModel.canSubmit)
        XCTAssertNotNil(viewModel.errorMessage)
    }
}

중요한 건 테스트 이름이다.

test_submitOrder_whenCalledMultipleTimes_callsCreateOrderOnlyOnce
test_submitOrder_whenFailed_allowsRetry

이렇게 되어 있으면 리뷰어가 바로 안다.

이번 버그가 뭔지, 어떤 조건을 막는지 보인다.

AI가 만든 테스트라도 사람이 읽기 좋아야 한다.

---

12. Context Pack을 자동으로 뽑는 작은 스크립트

매번 손으로 만들기 귀찮다면 간단한 스크립트로 시작해도 된다.

예를 들어 작업 폴더를 만들어주는 스크립트를 둔다.

#!/bin/bash

TASK_NAME=$1

if [ -z "$TASK_NAME" ]; then
  echo "Usage: ./new-context-pack.sh task-name"
  exit 1
fi

mkdir -p "context/$TASK_NAME"

cat > "context/$TASK_NAME/task.md" <<EOF
# Task

## Current Problem

## Expected Behavior

## Not Goal
EOF

cat > "context/$TASK_NAME/files.md" <<EOF
# Files

## Read First

## Allowed to Edit

## Do Not Edit Without Approval

## Reason
EOF

cat > "context/$TASK_NAME/rules.md" <<EOF
# Rules

## Architecture

## Concurrency

## Code Style

## Logging
EOF

cat > "context/$TASK_NAME/tests.md" <<EOF
# Tests

## Required Test Cases

## Commands

## If You Cannot Run Tests
EOF

cat > "context/$TASK_NAME/done.md" <<EOF
# Done Criteria

## Final Report Format

\`\`\`markdown
## Summary

## Files Changed

## Validation

## Risk

## Not Changed
\`\`\`
EOF

echo "Created context pack: context/$TASK_NAME"

사용은 이렇게 한다.

./new-context-pack.sh checkout-duplicate-submit

처음에는 귀찮아 보인다.

그런데 AI가 엉뚱한 파일 고치고, PR 커지고, 리뷰어가 화내는 비용보다 훨씬 싸다.

---

13. 더 센 스킬: git diff를 Context Pack에 붙인다

AI에게 현재 변경 사항을 리뷰시키거나 이어서 작업시킬 때는 git diff를 같이 넣는 게 좋다.

git diff --stat > context/checkout-duplicate-submit/diff-stat.txt
git diff > context/checkout-duplicate-submit/diff.patch

그다음 AI에게 이렇게 시킨다.

context/checkout-duplicate-submit/ 문서와 diff.patch를 읽고 리뷰해줘.

확인할 것:
- task.md의 Expected Behavior를 만족하는가
- files.md의 Allowed to Edit 범위를 넘었는가
- rules.md를 어긴 부분이 있는가
- tests.md의 Required Test Cases가 반영되었는가
- done.md 기준으로 완료라고 볼 수 있는가

코드 수정하지 말고 리뷰만 해줘.

이 스킬이 꽤 좋다.

AI에게 구현도 시키고, 같은 AI에게 다시 리뷰도 시킬 수 있다.

단, 같은 세션에서 바로 리뷰시키는 것보다 새 세션에서 Context Pack과 diff만 주는 편이 낫다.

이전 대화에 끌려가지 않고 더 객관적으로 본다.

---

14. 더 센 스킬 2: 에이전트에게 “먼저 멈추는 조건”을 준다

AI 에이전트는 너무 열심히 한다.

그래서 멈추는 조건을 줘야 한다.

# Stop Conditions

Stop and ask before editing if:

- More than 3 files need to change.
- A public API must change.
- A database schema must change.
- A new dependency seems necessary.
- A production config file needs to change.
- A security or privacy rule conflicts with the task.
- The bug appears to be in a Do Not Edit file.

이건 진짜 효과가 있다.

AI가 혼자 판단해서 큰 변경을 만들기 전에 멈춘다.

프롬프트에 꼭 넣어라.

Stop Conditions에 걸리면 구현하지 말고 이유만 설명해줘.

AI에게 계속 달리라고만 하면 사고 난다.

잘 멈추게 만드는 것도 스킬이다.

---

15. 더 센 스킬 3: “Not Changed” 보고를 강제한다

AI가 뭘 했는지는 보통 말한다.

그런데 뭘 안 했는지는 잘 안 말한다.

실무에서는 이게 중요하다.

완료 보고에 Not Changed를 넣어라.

## Not Changed

- PaymentAPI는 수정하지 않음
- NetworkClient는 수정하지 않음
- DesignSystem은 수정하지 않음
- Analytics 이벤트는 추가하지 않음
- 주문 완료 화면은 수정하지 않음
- 신규 라이브러리 추가하지 않음

이게 있으면 리뷰어가 편하다.

“이거 혹시 건드렸나?”를 덜 확인해도 된다.

AI에게 작업을 맡길 때는 결과뿐 아니라 경계도 보고하게 해야 한다.

---

16. AGENTS.md에는 전역 규칙만 둔다

Context Pack과 AGENTS.md는 역할이 다르다.

AGENTS.md에는 프로젝트 전체 규칙을 둔다.

# AGENTS.md

## Global Rules

- Keep diffs small.
- Do not modify unrelated files.
- Do not add dependencies without approval.
- Do not change production config.
- Do not log sensitive data.
- Do not claim tests passed unless executed.

## iOS Architecture

- SwiftUI View must not call API directly.
- ViewModel owns UI state.
- UseCase handles business flow.
- Repository handles data access.
- UI state changes must happen on MainActor.

## Completion Format

Every task must end with:

- Summary
- Files Changed
- Validation
- Risk
- Not Changed

Context Pack에는 작업별 규칙을 둔다.

AGENTS.md:
항상 지켜야 하는 팀 규칙

Context Pack:
이번 작업에서만 필요한 맥락

둘을 섞지 않는 게 좋다.

AGENTS.md가 너무 길어지면 AI가 중요한 걸 놓친다.

전역 규칙은 짧게, 작업 맥락은 Context Pack으로 분리한다.

---

17. 이 방식이 왜 먹히나

AI 코딩 에이전트는 사람 개발자처럼 일하려고 한다.

그런데 사람 개발자는 일을 시작하기 전에 많은 맥락을 이미 알고 있다.

팀 규칙
폴더 구조
테스트 방식
건드리면 안 되는 영역
예전 장애
리뷰어 성향
배포 위험

AI는 이걸 모른다.

Context Pack은 이 빈칸을 채워준다.

대신 모든 걸 다 주는 게 아니라, 이번 작업에 필요한 만큼만 준다.

이게 핵심이다.

전체 repo를 먹이는 게 아니라,
작업 가능한 작은 세계를 만들어준다.

AI가 그 세계 안에서만 움직이면 결과가 훨씬 안정된다.

---

18. 마무리

AI 코딩 에이전트를 잘 쓰는 사람은 프롬프트를 예쁘게 쓰는 사람이 아니다.

작업장을 잘 차리는 사람이다.

문제를 짧게 고정하고
볼 파일을 정하고
수정 가능한 파일을 제한하고
팀 규칙을 적고
테스트 기준을 주고
멈춰야 할 조건을 정하고
완료 보고 형식을 강제하는 사람

이게 요즘 말하는 Context Engineering의 실전 버전이다.

앞으로 AI 코딩 에이전트는 더 강해질 것이다.

그런데 모델이 강해질수록 더 조심해야 한다.

약한 AI는 조금 틀린 코드를 만든다.
강한 AI는 그럴듯한 큰 변경을 만든다.

그래서 개발자에게 필요한 스킬은 단순히 “AI에게 질문 잘하기”가 아니다.

이제는 이런 스킬이 필요하다.

AI가 일할 수 있는 작은 작업 공간을 설계하는 능력
AI가 건드릴 수 있는 파일을 제한하는 능력
AI가 멈춰야 할 조건을 정하는 능력
AI가 만든 결과를 검증 가능한 형태로 받는 능력

다음에 AI에게 일을 맡길 때 바로 구현부터 시키지 말자.

먼저 Context Pack을 만들어라.

task.md
files.md
rules.md
tests.md
done.md

이 다섯 개만 있어도 결과가 달라진다.

AI가 똑똑해지는 게 아니다.

AI가 헛똑똑하게 움직일 여지를 줄이는 것이다.

그리고 실무에서는 그게 진짜 생산성이다.

참고 자료

• AGENTS.md 공식 소개
• OpenAI Codex: Custom instructions with AGENTS.md
• Claude Code Docs: Best Practices
• Claude Code Docs: Hooks
• Claude Code Docs: Subagents
• arXiv: Context Engineering for AI Agents in Open-Source Software
• Stack Overflow Blog: Building shared coding guidelines for AI and people

Cookie