프롬프트 엔지니어링을 위한 OODA 루프: 다섯 번의 실패가 가르쳐 준 것

John Boyd 대령의 OODA 루프는 1960년대 전투기 조종사의 의사결정을 위해 개발되었습니다. 관찰-판단-결정-행동 주기를 더 빠르게 완료하는 조종사가 항공기 성능과 관계없이 결정적인 우위를 점했습니다. 저는 동일한 원리가 프롬프트 엔지니어링에도 적용된다는 것을 발견했습니다 — 다섯 번의 값비싼 실패를 통해 프롬프트를 작성하는 것이 가장 덜 중요한 단계라는 것을 깨달은 후에야 말입니다.¹

TL;DR

OODA 루프(관찰, 판단, 결정, 행동)는 프롬프트 엔지니어링에서 가장 흔한 실패 모드, 즉 관찰(전체 맥락 파악) 전에 행동(프롬프트 작성)하는 것을 방지하는 체계적인 프레임워크를 제공합니다. 44개의 스킬 — 각각 자동 활성화 로직을 갖춘 구조화된 프롬프트 — 을 구축하면서, 프롬프트 자체는 결과의 약 20%만 차지한다는 것을 배웠습니다. 나머지 80%는 관찰(모델에 어떤 맥락이 필요한가?), 판단(이 작업은 어떤 유형의 작업인가?), 결정(어떤 프롬프트 패턴이 이 작업 유형에 적합한가?)입니다. 아래의 인터랙티브 빌더는 전체 OODA 주기를 안내합니다. 그 결과: 반복적인 수정 없이 첫 시도에 성공하는 프롬프트를 만들 수 있습니다.

다섯 번 실패한 프롬프트

행동 전에 관찰하는 법을 배우기 전, 저는 코드를 작성하는 개발자처럼 프롬프트를 작성했습니다: 곧바로 해결책으로 뛰어들었습니다.

실패 1: 블로그 평가기. 블로그 품질 평가 프롬프트의 첫 번째 시도: “이 블로그 게시물을 평가하고 1-10점으로 점수를 매기세요.” 모델은 “7/10”이라는 모호한 문단을 반환했고 실행 가능한 피드백은 없었습니다. 네 번 반복한 후에야 문제가 프롬프트 문구가 아니라는 것을 깨달았습니다 — 문제는 “품질”이 무엇을 의미하는지 정의하지 않았다는 것이었습니다.

OODA 수정: 30분 동안 제 자신의 평가 과정을 관찰했습니다. 제가 중요하게 여기는 여섯 가지 구체적인 차원을 식별했습니다: 독자 가치(25%), 기술적 정확성(20%), 교육적 품질(20%), 글쓰기 품질(15%), 사실적 무결성(15%), SEO 효과(5%). 가중치 루브릭은 blog-evaluator 스킬이 되었고, 이후 모든 평가에서 일관되고 실행 가능한 점수를 산출하고 있습니다.²

실패 2: 코드 리뷰어. 첫 번째 리뷰 프롬프트: “이 코드에서 버그와 보안 문제를 검토하세요.” 모델은 15개의 발견 사항을 반환했는데, 그 중 12개는 스타일 관련 지적이었습니다. 신호 대 잡음 비율 때문에 리뷰가 쓸모없었습니다.

OODA 수정: 작업을 세 개의 별도 하위 작업(정확성, 보안, 규칙)으로 판단하고, 각각 제한된 도구 접근 권한과 구체적인 평가 기준을 가진 세 개의 전용 리뷰어 서브에이전트를 구축했습니다. 정확성 리뷰어는 로직 오류만 지적합니다. 보안 리뷰어는 OWASP 취약점만 지적합니다. 규칙 리뷰어는 패턴 이탈만 지적합니다. 각 프롬프트가 하나의 차원에만 좁게 범위가 지정되어 있기 때문에 잡음이 거의 0으로 떨어졌습니다.³

실패 3: 번역 프롬프트. “이 블로그 게시물을 한국어로 번역하세요.” 모델은 번역했지만 모든 마크다운 서식을 잃었고, 각주 참조를 제거했으며, 영어로 유지해야 할 기술 용어를 재작성했습니다.

OODA 수정: 제 사용 사례에서 “번역”이 실제로 무엇을 의미하는지 관찰했습니다: 마크다운 구조 보존, 각주 번호 보존, 코드 블록 미번역, 고유 명사 영어 유지, 직역 대신 관용적 표현 적용. 제약 조건 목록이 번역 지시보다 더 길어졌습니다. 각 제약 조건은 “이것을 번역하세요”가 생성했을 실패 모드를 제거했습니다.⁴

프롬프팅에 적용된 OODA 루프

1단계: 관찰

프롬프트의 한 단어도 작성하기 전에, 문제 공간을 관찰합니다:

실제 작업은 무엇인가? 표면적인 요청이 아니라 근본적인 필요를 파악합니다. “이 문서를 요약하세요”는 실제로 “이 회의에서 내린 세 가지 결정을 추출해서 후속 조치를 취할 수 있게 해 주세요”를 의미할 수 있습니다.

모델이 알아야 할 것은 무엇인가? 올바른 응답에 필요한 맥락을 열거합니다. 맥락이 부족하면 할루시네이션이 발생합니다. 맥락이 과도하면 토큰을 낭비하고 모델의 주의를 분산시킬 수 있습니다.

출력은 어떤 모습인가? 프롬프트를 작성하기 전에 원하는 출력의 형식, 길이, 어조, 구조를 정의합니다. 모호한 출력 기대는 모호한 출력을 생성합니다.⁵

관찰 체크리스트: - [ ] 실제 작업(표면적 요청이 아닌) 식별 - [ ] 필요한 맥락 열거 - [ ] 출력 형식 정의 - [ ] 성공 기준 명시 - [ ] 실패 모드 예상

2단계: 판단

모델의 기능 범위 내에서 작업을 판단합니다:

작업 유형 분류. 작업이 추출(제공된 텍스트에서 정보를 가져오기), 생성(새로운 콘텐츠 만들기), 변환(형식 간 변환), 분석(콘텐츠 평가 및 추론), 또는 분류(입력 범주화)인지 판단합니다.⁶

각 작업 유형에는 확립된 프롬프트 패턴이 있습니다. 제 44개의 스킬이 이 패턴을 반영합니다: blog-evaluator 스킬은 분석 패턴(가중치 루브릭, 구조화된 채점)을 사용합니다. blog-writer-core 스킬은 생성 패턴(스타일 규칙, 제약 조건 목록, 예시 구조)을 사용합니다. citation-verifier 스킬은 추출 패턴(주장 추출, 출처와 대조)을 사용합니다.

복잡성 평가. 작업을 단일 프롬프트로 완료할 수 있는지, 아니면 분해가 필요한지 판단합니다. 경험 법칙: 작업에 세 가지 이상의 별개의 인지 작업이 필요하면 분해합니다.

제 심의 시스템은 분해를 한 단계 더 발전시킵니다: 신뢰도가 낮을 때(점수 0.70 미만) 시스템은 여러 에이전트를 생성하여 문제를 독립적으로 탐색한 다음, 품질 순으로 응답을 순위화합니다. 단일 프롬프트의 복잡성 임계값은 다양하지만, 조사, 분석, 생성이 혼합된 작업은 모두 분해합니다.

제약 조건 매핑. 어떤 제약 조건이 적용되는지 파악합니다. 토큰 제한, 출력 형식 요구 사항, 사실적 정확성 요구, 어조 요구 사항, 대상 독자 고려 사항. 각 제약 조건은 프롬프트의 명시적인 지시가 됩니다.

3단계: 결정

관찰과 판단을 기반으로 프롬프트 아키텍처를 결정합니다:

프롬프트 패턴 선택:

역할 할당. 역할은 작업이 특정 관점의 혜택을 받을 때 효과적입니다. 제 security-reviewer 서브에이전트는 “OWASP Top 10 취약점에 대한 코드를 검토하는 시니어 보안 엔지니어” 역할을 부여받습니다 — 역할이 출력을 보안 문제에 집중시킵니다. 역할이 작업과 모순될 때 역할은 실패합니다(“당신은 창의적인 작가입니다”를 사실 분석 작업에 사용하는 경우).⁷

4단계: 행동

3단계의 결정을 사용하여 프롬프트를 작성합니다. 프롬프트는 일관된 구조를 따릅니다:

[ROLE] (if applicable)
[CONTEXT] (the information the model needs)
[TASK] (the specific instruction)
[FORMAT] (the expected output structure)
[CONSTRAINTS] (restrictions and requirements)
[EXAMPLES] (if using few-shot)

이 구조는 기계적으로 채울 템플릿이 아닙니다. 이 구조는 체크리스트입니다: 관찰, 판단, 결정 단계가 각 섹션을 작성하기에 충분한 명확성을 생성했는지 확인합니다. 어떤 섹션이든 불명확하면 적절한 이전 단계로 돌아갑니다.⁸

프롬프트 라이브러리: 구조화된 프롬프트로서의 44개 스킬

제 Claude Code 스킬 시스템은 본질적으로 작업 유형별로 정리된 프롬프트 라이브러리입니다. 각 스킬은 OODA 구조를 따릅니다:

---
description: FastAPI backend development patterns and conventions
allowed-tools: [Read, Grep, Glob, Edit, Write, Bash]
---
# FastAPI Development Expertise

## Project Structure
[CONTEXT: expected file layout, naming conventions]

## Route Patterns
[CONSTRAINTS: response format, error handling, dependency injection]

## Database Patterns
[CONSTRAINTS: SQLAlchemy 2.0+ async, Pydantic v2 models]

스킬 설명은 관찰(스킬이 언제 활성화되어야 하는가?)을 처리합니다. allowed-tools 필드는 판단(작업에 어떤 기능이 필요한가?)을 처리합니다. 본문은 결정과 행동(모델이 어떤 패턴을 따라야 하는가?)을 처리합니다.⁹

blog-writer-core 스킬은 14개의 필수 스타일 규칙을 포함하고 있습니다 — 실패를 통해 발견한 제약 조건입니다:

1. 능동태만 사용 (“엔지니어들이 설치했다”이지 “엔지니어들에 의해 설치되었다”가 아님)
2. “이것”을 주어로 사용하지 않음 (항상 지시 대상을 명시)
3. 모든 주장에 각주로 인용 표기
4. 코드 블록에 언어 식별자 태그 지정
5. 엠 대시 사용 금지 (쉼표 또는 세미콜론 사용)

각 규칙은 해당 규칙을 위반한 게시물을 발행했기 때문에 존재합니다. 규칙 #1은 blog-quality-gate 훅이 7개의 수동태 문장을 포착하면서 탄생했습니다. 규칙 #3은 McKinsey 통계에 대한 미인용 주장을 게시하면서 탄생했습니다. OODA 관찰 단계가 실패를 식별했고, 프롬프트의 제약 조건이 재발을 방지합니다.¹⁰

반복 루프

OODA 루프는 본질적으로 반복적입니다. 행동(프롬프트 전송) 후 결과를 관찰합니다:

1. 출력을 관찰합니다: 무엇이 올바른가? 무엇이 잘못되었는가? 무엇이 빠져 있는가?
2. 격차를 판단합니다: 문제가 맥락(정보 누락), 형식(잘못된 구조), 또는 기능(단일 프롬프트로는 너무 복잡한 작업)에 있는가?
3. 수정을 결정합니다: 맥락을 추가하거나, 형식 지시를 조정하거나, 작업을 분해합니다.
4. 수정된 프롬프트로 행동합니다.

각 반복 주기는 정확히 하나의 변수만 변경해야 합니다. 여러 프롬프트 요소를 동시에 변경하면 어떤 변경이 어떤 효과를 생성했는지 식별하는 것이 불가능합니다.¹¹

제 블로그 평가 워크플로우는 전체 반복 루프를 따릅니다:

1. Lint (deterministic) → fix structural issues
2. Evaluate (LLM) → score on 6 dimensions
3. Critique (LLM) → identify specific improvements
4. Fix (LLM) → apply surgical improvements
5. Re-evaluate → verify score improved

각 단계는 해당 작업 유형에 최적화된 별도의 프롬프트를 사용합니다. Lint 단계는 추출(위반 사항 찾기)을 사용합니다. 평가 단계는 분석(루브릭에 따른 채점)을 사용합니다. 비평 단계는 생성(개선 제안 산출)을 사용합니다. 수정 단계는 변환(구조를 보존하며 변경 적용)을 사용합니다. 이 체인은 단일 “이 게시물을 개선하세요”라는 통합 프롬프트보다 더 나은 결과를 생성합니다.¹²

핵심 요점

AI 기능을 구축하는 엔지니어를 위해: - 프롬프트를 작성하기 전에 전체 OODA 주기를 적용하세요. 5분의 관찰과 판단이 30분의 반복적인 프롬프트 수정을 절약합니다 - 프롬프트 패턴을 선택하기 전에 작업 유형(추출, 생성, 변환, 분석, 분류)을 분류하세요. 각 유형에는 일반적인 프롬프팅보다 뛰어난 확립된 패턴이 있습니다 - 작업 유형별로 정리된 프롬프트 라이브러리를 구축하세요. 제 44개의 스킬은 프로젝트 전반에서 재사용하는 검증된 프롬프트 패턴을 나타냅니다

AI를 매일 사용하는 제품 팀을 위해: - AI 출력이 기대에 미치지 못할 때, 실패가 관찰(잘못된 작업 식별), 판단(잘못된 접근 방식), 결정(잘못된 프롬프트 패턴), 또는 행동(잘못된 프롬프트 문구) 중 어디에 있는지 진단하세요. 수정 방법은 각 단계마다 다릅니다 - 제약 조건은 영리한 프롬프트 문구보다 더 많은 실패를 방지합니다. 제 블로그 작성기의 14개 필수 규칙은 아무리 많은 “잘 써 주세요”보다 더 일관된 품질을 생성합니다

참고 문헌