Prompt Engineering은 Prompt 전에 시작된다

Prompt Engineering이라고 하면 많은 사람은 여전히 문구, 역할 설명, XML 태그, Prompt Template, 혹은 아주 상세한 System Instruction부터 떠올립니다. 전형적인 시작은 이런 식입니다.

“You are a world-class senior software architect …”

지난 몇 년 동안 Prompt를 둘러싼 작은 전문 영역이 생겨났고, 때로는 평범한 AI 답변과 훌륭한 AI 답변의 차이가 주로 올바른 표현 공식을 찾는 데 있다는 인상까지 주었습니다.

완전히 틀린 말은 아닙니다. 구조는 도움이 될 수 있고, 예시는 도움이 될 수 있으며, 명확한 언어도 중요합니다. 최신 Model Guidance 역시 여전히 구체적인 Prompting Technique을 설명합니다.

하지만 내가 Coding Agent와 실제로 일할 때는, 이 부분이 이제 전체 문제에서 비교적 작은 비중만 차지합니다.

아주 이해하기 쉬운 문장을 하나 보겠습니다.

사용자 관리 기능을 만들어 줘.

문장 자체에는 별문제가 없습니다. 짧고 명확하며 불필요한 전문용어도 없습니다.

그런데 실제 구현에 필요한 정보는 거의 전부 빠져 있습니다.

어떤 종류의 사용자가 있는가? 어떤 Role을 갖는가? 누가 사용자를 생성할 수 있는가? 사용자는 자신의 데이터를 수정할 수 있는가? 초대 Flow가 있는가? 인증은 어떻게 동작하는가? 어떤 데이터를 저장해야 하는가? 중복 E-Mail은 어떻게 처리하는가? 이미 Identity Provider가 있는가? 기존 시스템의 어느 부분까지 수정할 수 있는가? 어떤 Architecture가 적용되는가? 어떤 오류 사례가 Scope에 포함되는가? 명시적으로 Scope 밖인 것은 무엇인가? 그리고 마지막으로, 이 Feature가 올바르게 구현되었다고 어떻게 판단할 것인가?

원래 문장 앞에 다음과 같은 문구를 추가해도 이 문제들은 해결되지 않습니다.

You are a world-class senior software architect.

잘 표현된 불명확한 작업은 여전히 불명확한 작업이다. 따라서 진짜 Engineering은 같은 요청을 더 그럴듯하게 표현하는 방법에서 시작하는 것이 아니라, 아직 빠져 있는 의사결정과 정보를 찾아내는 데서 시작합니다.

왜 이 글은 이전 글들 다음에 와야 하는가

앞선 세 글은 이 결론을 단계적으로 준비했습니다.

4편에서는 Context, Memory, Agent Files, Skills, Tools를 다뤘습니다. 거기서 Context를 현재 모델 처리 시점에 실제로 “책상 위에 놓여 있는 것”으로 설명했습니다. Memory, Agent Files, Skills, 프로젝트 문서는 그 Context에 정보를 제공할 수 있지만 서로 다른 역할을 합니다. 특히 지속적인 프로젝트 지식과 현재의 구체적인 작업 지시를 구분했습니다.

여기서 Prompt에 대한 중요한 결론이 하나 나옵니다. 구현 Prompt가 매번 Repository 전체를 다시 설명할 필요는 없습니다.

프로젝트에서 Presentation이 Infrastructure에 직접 접근하면 안 된다는 규칙이 지속적으로 유효하다면, 그 규칙을 매 Ticket마다 새로 작성하고 싶지는 않습니다. 특정 Test Strategy가 적용되고, Naming Rule이 존재하며, Layering이 강제된다면 그런 결정은 지속적으로 존재할 장소가 필요합니다.

단순화하면:

Agent Files / Skills / Memory / Documentation
=
지속적인 작업 지식

Implementation Prompt
=
현재 Task의 구체적인 작업 지시

최근의 실무 보고도 이 구분을 뒷받침합니다. Anthropic은 Context Engineering을 가능한 한 큰 Context가 아니라 가능한 한 관련성 높은 Context를 지속적으로 선택하는 작업으로 설명하며, Agent에게 Just-in-Time Retrieval 같은 방식도 권장합니다. OpenAI는 자사의 agent-first 소프트웨어 프로젝트에서 거대한 단일 AGENTS.md가 Task, Code, 관련 문서를 Context 밖으로 밀어낼 수 있고, 규칙은 금방 낡으며, Guidance가 너무 많으면 우선순위가 약해진다고 보고했습니다. 그래서 짧은 Agent 파일은 오히려 더 깊고 버전 관리되는 Repository 문서로 안내하는 지도 역할을 합니다.

5편에서는 또 다른 특성을 다뤘습니다. Agent는 Solution Path를 구성합니다. 파일을 읽고, Tool을 사용하고, 관찰 결과를 평가한 뒤, 그 과정에서 변화한 Context를 기준으로 다음 결정을 내립니다. 같은 Task가 반드시 같은 Implementation Path로 이어지지는 않습니다.

이 경로를 완전히 결정적으로 규정하고 싶지 않다면—Agent에게는 종종 그 자체가 목적을 훼손할 수 있으므로—최소한 어떤 결정이 허용 가능한 범위에 속하는지는 정의해야 합니다.

6편은 다음 문제를 추가했습니다. 그럴듯한 경로가 잘못된 가정 위에 서 있을 수 있습니다. 그 가정은 Code Change가 되고, commit되며, 나중에는 Repository 안에서 Local Evidence로 다시 나타날 수 있습니다. 개별적인 잘못된 결정이 Drift로 이어질 수 있다는 뜻입니다. 동시에 Generation과 Verification이 서로 다른 작업이라는 점도 보았습니다.

그러면 자연스럽게 Requirements로 오게 됩니다.

우리가 상세한 Implementation Prompt를 쓰는 이유는 Agent에게 가능한 한 많은 텍스트를 주기 위해서가 아니다. Context는 제한되어 있고, Agent는 의사결정 공간을 가지며, 그럴듯한 해결책도 틀릴 수 있기 때문이다.

따라서 첫 질문은 단순히 이것이 아닙니다.

어떻게 하면 더 좋은 Prompt를 쓸 수 있을까?

먼저 물어야 할 것은 이것입니다.

실제로 무엇이 반드시 성립해야 하는가?

실제 Prompt는 마지막에 만들어진다

그래서 지금의 내 작업 방식은 보통 Implementation Prompt를 쓰는 것에서 시작하지 않습니다.

처음에는 Idea, Ticket, 또는 관찰 하나만 있는 경우가 많습니다. 그다음 Discovery가 시작됩니다.

단순화한 mental model은 다음과 같습니다.

Idea / Ticket
↓
Discovery
↓
질문
↓
Alternatives
↓
도메인 의사결정
↓
기술 의사결정
↓
Constraints
↓
Acceptance Criteria
↓
Implementation Prompt
↓
Agent
↓
Verification

이것은 내가 항목별로 체크하는 Process Model이 아닙니다. 내 일상에는 “Discovery 완료”라는 공식적인 상태 전환이 없습니다.

어떤 Task는 5분이면 충분히 명확해지고, 다른 Task는 여러 번의 대화가 필요합니다. Legacy 시스템에서는 먼저 Code를 조사해야 하는 경우가 많고, 그 과정에서 비로소 빠진 도메인 결정이 드러나기도 합니다. 반대로 이미 존재하는 Reference Implementation 하나만으로 거의 모든 기술적 질문이 해결되기도 합니다.

나는 대체로 80/20 Rule에 가깝게 일합니다. 다음 단계를 통제 가능한 방식으로 진행할 만큼 충분히 이해하고 결정했다면 계속 진행합니다. 앞으로 생길 모든 질문을 미리 답하려 하지는 않습니다.

Discovery는 다음 통제 가능한 단계가 합리적으로 시작될 수 있을 만큼 충분하면 된다.

이것은 Requirements가 어느 순간 갑자기 “완전해진다”는 뜻도 아닙니다. Implementation 중 새로운 정보가 나오고, 기존 가정이 틀린 것으로 드러나며, 기존 Contract가 예상과 다르게 동작하거나, 실제 Data Flow를 따라가야 비로소 특정 도메인 Edge Case가 보일 수 있습니다.

그때 다시 다듬는 것은 Discovery의 실패가 아니라 Discovery의 일부입니다.

LLM을 Requirements Sparring Partner로 사용하기

이 단계에서 강력한 LLM은 나중의 Coding Agent와는 다른 역할을 맡습니다.

내 질문에 답하기만 해서는 안 됩니다.

오히려 나에게 질문해야 합니다.

내가 Feature Idea를 설명하면, 그 안에 아직 숨어 있는 결정이 무엇인지 알고 싶습니다. 말하지 않은 가정은 무엇인가? 빠진 실패 사례는 무엇인가? 어떤 Role이 영향을 받는가? 도메인에서 “삭제”는 실제로 무엇을 의미하는가? 개발자가 스스로 Product Decision을 내리지 않으려면 어떤 정보가 필요한가? 어떤 행동은 단지 내 즉흥적인 생각이고, 어떤 것은 실제 Requirement인가?

예를 들어 이런 질문이 가능합니다.

이 Requirement에서 아직 불명확한 것은 무엇인가?

우리가 지금 암묵적으로 가정하는 것은 무엇인가?

빠진 Edge Case는 무엇인가?

아직 결정되지 않은 도메인 결정은 무엇인가?

명시적으로 Scope 밖인 것은 무엇인가?

기존 System Boundary 중 어떤 것이 영향을 받을 수 있는가?

나중에 구현이 올바른지 어떻게 판단할 것인가?

좋은 Planning Model은 질문에 답하기만 하지 않는다. 빠진 질문을 보이게 만든다.

이것은 단순한 이론적 사용 사례가 아닙니다. LLM-assisted Requirements Elicitation 연구는 이미 Stakeholder에게 던질 Follow-up Question 생성 자체를 명시적으로 다루고 있습니다. 2025년 Software Requirement Patterns 관련 연구에서는 LLM이 만든 Elicitation Question이 기본적으로 활용 가능하다는 결과와 함께, 반복 질문과 Out-of-Scope 질문이 발생하고 여전히 상당한 Expert Assessment가 필요하다는 점도 보고했습니다. 2026년 8월의 Systematic Mapping Study는 74편의 연구를 분석했는데, Requirement 후보를 식별하는 단계에서는 Automation이 비교적 널리 사용되지만 Consolidation, 특히 Stakeholder Validation으로 갈수록 자동화 수준이 크게 줄어드는 모습을 보여 줍니다.

이 결과는 내가 Planning Model을 사용하는 방식과 잘 맞습니다.

Planning Model은 Sparring Partner입니다.

Requirements Owner가 아닙니다.

누가 이 결정을 할 권한이 있는가?

소프트웨어 개발자는 문제를 해결하는 데 익숙합니다. 그래서 Discovery 중에 자신에게 실제 권한이 없는 결정까지 너무 쉽게 내려 버릴 수 있습니다.

기술적으로는 Status를 하나 더 추가하는 것이 우아해 보일 수 있습니다. 다른 Data Flow가 더 일관적일 수 있고, Process Step 하나를 추가하면 Edge Case가 사라질 수도 있습니다. Authorization Logic을 바꾸면 구현이 훨씬 단순해질 수도 있습니다.

하지만 그렇다고 우리가 그 변경을 해도 된다는 뜻은 아닙니다.

실제 프로젝트에는 Product Owner, 비즈니스 부서, 고객, Domain Expert처럼 특정 도메인 결정을 책임지는 사람들이 있습니다. Ticket에 사용자가 어떤 Process를 다시 열 수 있는지 명확하게 쓰여 있지 않다면 “기술적으로 가장 아름다운 선택”이 자동으로 정답이 되지는 않습니다.

Requirements Engineering은 내가 결정할 권한이 없는 곳에서 대신 결정하지 않는 것까지 포함한다.

이 원칙은 인간과 Agent에게 똑같이 적용됩니다.

Planning Model은 Option을 정리하고, 결과를 설명하고, 모순을 보여 주고, Alternative를 비교할 수 있습니다. 그래도 최종 결정은 도메인 책임이 있는 곳에 남아 있어야 합니다. 기술적으로 옳다는 것과 비즈니스적으로 옳다는 것은 같은 말이 아니기 때문입니다.

Legacy 시스템에서는 Discovery 자체가 기술 작업이 된다

Greenfield 프로젝트에서는 많은 기술 결정을 직접 설명할 수 있습니다. 하지만 Legacy 시스템에서는 시작 시점에 나 자신도 실제 상태를 충분히 모르는 경우가 많습니다.

그럴 때 나는 Planning Model, Coding Agent, Repository 사이에서 작업을 주고받습니다.

Planning LLM
↓
Exploration Task
↓
Coding Agent가 Repository 조사
↓
Findings
↓
다시 Planning
↓
새로운 Decision

일반적인 Coding Task와의 핵심 차이는 목표입니다.

Exploration Prompt는 아직 구현해서는 안 됩니다. 예를 들어 비슷한 Flow가 이미 존재하는지, 실제로 어떤 Pattern이 쓰이는지, 어떤 Component가 영향을 받는지, 현재 Data Flow가 어떻게 움직이는지, 예정된 변경이 어떤 Dependency를 건드리는지를 조사해야 합니다.

이런 Task는 매우 좁게 정의할 수 있습니다.

이 Feature 안에서 유사한 Create Flow가
현재 어떻게 구현되어 있는지 조사하라.

아무것도 구현하지 마라.

보고할 것:
- 관련 파일
- 반복되는 Patterns
- 차이점
- 사용 중인 Dependencies
- Open Questions

서로 경쟁하는 Pattern이 여러 개 존재하면,
앞으로 무엇을 표준으로 삼을지
직접 결정하지 마라.

이렇게 Repository 자체가 Discovery의 일부가 됩니다.

오래된 시스템에서는 특히 중요합니다. 문서와 실제 Code가 반드시 같은 이야기를 하지 않기 때문입니다. OpenAI의 내부 Data Agent에서도 유사한 메커니즘을 설명합니다. Metadata만으로 데이터의 의미를 파악하기 어려워서, 실제 의미와 생성 방식을 이해하기 위해 Code를 직접 조사합니다. 팀의 경험을 요약하면 이런 식입니다.

의미는 설명만이 아니라 실제로 실행되는 Code 안에 존재하는 경우가 많다.

Legacy Software에서는 이 생각을 더 넓게 적용할 수 있습니다.

Legacy 시스템의 Requirements는 대화에서만 나오지 않는다. 그 일부는 기존 시스템에서 직접 찾아내야 한다.

이 단계에서 Coding Agent는 Implementer이기 전에 Exploration Tool입니다.

Discovery는 발산해도 되지만 Implementation은 훨씬 덜 그래야 한다

Discovery 중에는 Planning Model의 창의성을 원합니다.

Alternative를 만들고, 내 생각을 의심하고, 다른 Data Flow를 제안하고, 처음 생각한 해결책이 왜 과도하게 복잡한지 설명해도 좋습니다. 아직 어떤 가능성이 있는지 이해하는 단계이므로 큰 Solution Space가 도움이 됩니다.

하지만 도메인 행동, Architecture, Coding Style이 정해지고 나면 Task의 성격이 달라집니다.

Discovery
=
Solution Space 열기

Decision
=
Options 평가

Implementation
=
Solution Space 닫기

이 패턴은 시리즈 뒤의 다른 글에서 더 자세히 다룰 예정입니다. 지금은 내 경험에서 나온 한 가지 관찰만 있으면 충분합니다.

창의성은 모든 단계에서 동일한 가치가 있지 않습니다.

프로젝트에서 Slice 구조, Dependency 방향, State Modeling, Naming을 이미 결정했다면, Agent가 Feature마다 새로운 “그럴듯한 Variant”를 만들어 내길 원하지 않습니다.

내 개인적인 기준은 이제 이렇습니다.

프로젝트 전체가 한 명의 개발자가 작성한 것처럼 읽혀야 한다.

모든 개발자가 완전히 같은 Code를 작성한다는 뜻이 아닙니다. 핵심은 Consistency입니다. Repository의 Architecture만 보고 어느 Feature를 어느 Agent나 어느 모델이 만들었는지 알아볼 수 있어서는 안 됩니다.

Coding Style, Layering, Naming, Dependency Rules에서는 추가적인 창의성이 종종 장점이 아닙니다.

그건 새로운 Variance입니다.

그렇다면 Implementation Prompt는 무엇인가?

이런 배경에서

Feature X를 만들어라.

는 나에게 보통 Implementation Prompt가 아닙니다.

작은 POC라면 충분히 합리적일 수 있습니다. 작은 Correction도 다섯 페이지 Specification이 필요하지 않습니다. 일부러 Agent가 어떤 해법을 만들어 내는지 보고 싶다면 Task를 의도적으로 열어 둘 수도 있습니다.

하지만 기존 시스템에서 도메인적으로 중요한 변경을 한다면 작업 지시는 훨씬 다릅니다.

상세한 Implementation Prompt에는 다음이 들어갈 수 있습니다.

• Goal과 도메인 목적
• Scope와 Non-goals
• Discovery에서 얻은 관련 Findings
• 영향을 받는 Slice 또는 Module
• 이미 결정된 도메인 Decisions
• 관련 Architecture Boundaries
• 기존 Reference Patterns
• Data Flow와 State Flow
• Error Cases와 Edge Cases
• Acceptance Criteria
• 필요한 Tests
• Verification Steps
• Stop Conditions
• 필요하다면 합리적인 Implementation Sequence

이런 Prompt는 실제로 한두 문장의 Chat 요청보다 여러 페이지의 Technical Specification처럼 읽힐 수 있습니다.

Implementation Prompt는 Agent에게 던지는 짧은 지시가 아니다. 문제와 그 경계를 압축한 Specification이다.

최신 OpenAI Guidance for agentic models도 비슷한 방향을 명시적으로 권장합니다. 모든 작업 단계를 미리 지시하기보다 Outcome, Success Criteria, Constraints, Available Evidence, Stop Rules를 정의하라는 것입니다. Coding Workflow에서는 Acceptance Criteria, Tests, Agent가 계속 진행해야 할 때와 도움을 요청해야 할 때의 규칙까지 추가로 권장됩니다.

이는 Prompt Engineering을 단순히 같은 요청을 더 길게 표현하는 것으로 보는 관점과 중요한 차이가 있습니다.

추가된 길이에는 이유가 있어야 합니다.

각 Section은 하나의 위험을 줄여야 한다

왜 이 모든 정보가 필요할까요?

Agent가 긴 텍스트를 좋아해서가 아닙니다.

작업 지시의 서로 다른 부분이 서로 다른 실패 유형을 제한하기 때문입니다.

구성 요소	어떤 위험을 줄이는가?
Goal	Agent가 기술적으로 흥미롭지만 실제로는 잘못된 문제를 최적화하지 않도록 한다.
Relevant Context	Task-specific 지식은 자동으로 존재하지 않는다.
Scope	그럴듯한 추가 Feature가 조용히 Task에 포함되지 않도록 한다.
Constraints	허용 가능한 Solution Space를 좁힌다.
Existing Patterns	우연히 찾은 예시보다 관련 Local Evidence를 더 명확하게 보여 준다.
Non-goals	변경이 불필요하게 확장되지 않도록 한다.
Acceptance Criteria	“그럴듯해 보인다”와 “Task를 충족한다”를 구분한다.
Verification	Generated Output이 자기 자신의 품질 증명이 되지 않도록 한다.
Stop Conditions	핵심 가정이 깨졌을 때 Agent가 조용히 새로운 근본 결정을 하지 않도록 한다.

여기서 이전 글들이 다시 하나로 모입니다. Context는 제한되어 있고, Solution Path에는 Variance가 있으며, Plausibility만으로는 품질을 판단할 수 없습니다.

따라서 Prompt의 각 추가 Section은 구체적인 위험 하나를 줄여야 한다. 단순히 Prompt를 더 길게 만들기 위한 것이어서는 안 된다.

긴 Prompt가 자동으로 좋은 Prompt는 아니다

앞의 논리를 잘못 받아들이면 쉽게 이런 결론에 도달합니다.

상세한 Prompt가 불명확한 Prompt보다 좋다면, 더 긴 Prompt는 더 좋지 않을까?

그렇지 않습니다.

거대한 작업 지시는 Review하기 어려워질 수 있습니다. 서로 모순될 수 있고, 오래된 Decision과 새로운 Decision이 같이 남을 수 있습니다. 중요한 Rule이 사소한 Detail 사이에서 사라질 수도 있습니다. 무엇보다 하나의 매우 큰 Work Package가 되어 Agent가 오랫동안 작업한 뒤에야 인간이나 다른 Verification Step이 결과를 보게 될 수 있습니다.

그만큼 가능한 Drift Distance도 길어집니다.

그래서 나는 큰 작업을 의도적으로 더 작은 Work Package로 나눕니다.

Discovery
↓
Work Package 1
↓
Review / Verification
↓
Work Package 2
↓
Review / Verification
↓
Work Package 3

작은 Work Package는 Generation과 Verification 사이의 거리를 줄인다.

비슷한 원리는 현재 Agent Harness에서도 볼 수 있습니다. Anthropic은 장시간 Software Development에서 작업을 manageable unit으로 쪼개는 것과, Work Package가 언제 “done”인지 그리고 그것을 어떻게 검증할지를 나타내는 명시적 Contract를 설명합니다. 흥미로운 점은 더 강한 모델을 사용하게 되면서 이후 일부 Sprint Structure를 제거할 수 있었다는 것입니다. 즉, 이 구조는 Dogma가 아니라 당시 Task의 불확실성과 모델 Capability Limit에 대응하기 위한 것이었습니다.

나 역시 Work Package를 그렇게 봅니다.

이상적인 파일 수는 없습니다.

이상적인 Prompt 길이도 없습니다.

보편적인 Acceptance Criteria 개수도 없습니다.

Package Size는 불확실성을 따라가야 합니다.

Bug는 특별한 경우다

Bug에서는 이 차이가 더 선명합니다.

Feature Implementation에서는 많은 결정이 이미 끝났기 때문에 추가 Detail이 불확실성을 줄일 수 있습니다. 반면 원인을 모르는 Bug에서는 같은 수준의 Detail이 조사 자체를 악화시킬 수 있습니다.

예를 들어 리스트가 페이지를 나갔다 다시 들어와야 갱신된다고 해 봅시다. 내가 Agent에게 이렇게 말하면:

문제는 Store X가 Update 후
invalidated되지 않기 때문이다.

거기에 Reload를 추가해라.

나는 이미 가장 중요한 결정, 즉 Root Cause를 결정했을 수 있습니다.

내 가설이 틀리면 Agent는 잘못된 진단에 대해 아주 훌륭한 구현을 만들어 낼 수 있습니다.

그래서 Bug에서는 먼저 이런 내용을 설명하는 경우가 많습니다.

Observed Behavior
Expected Behavior
Reproduction Conditions
Known Observations
Relevant Constraints

먼저 Root Cause를 조사하라.
실제 Flow를 이해하기 전에는
해결책을 구현하지 마라.

Detail은 이미 결정이 내려진 곳에서 불확실성을 줄여야 한다. Agent가 아직 조사해야 하는 곳에서 결정을 대신 내려서는 안 된다.

처음에는 상세한 Prompt라는 생각과 모순처럼 들릴 수 있지만 실제로는 같은 Rule입니다.

최대한 많이 정하려는 것이 아닙니다.

적절한 Decision Space를 정하려는 것입니다.

질문은 Prompt의 결함이 아니다

상세한 Discovery를 했더라도 Coding Agent는 Implementation 중에 아무도 미리 보지 못한 것과 마주칠 수 있습니다.

정상입니다.

예상했던 API가 존재하지 않을 수 있습니다. 옆 Feature가 문서와 다르게 동작할 수 있고, 두 Pattern이 충돌할 수 있으며, 계획했던 해법이 이전에는 몰랐던 Architecture Boundary를 깨야만 가능할 수도 있습니다.

이런 상황에서 “좋은 Prompt라면 질문이 없어야 한다”는 생각 때문에 Agent가 추측하도록 강제하면 안 됩니다.

질문은 Working Model의 일부입니다.

OpenAI의 내부 Data Agent도 비슷하게 동작한다고 설명합니다. Instructions가 모호하거나 불완전하면 시스템이 적극적으로 Clarifying Question을 하고, 위험이 낮은 Gap에서는 합리적인 Default를 사용할 수 있습니다. 여기서 중요한 것은 구체적인 구현보다 원칙입니다.

모든 불확실성이 같은 위험을 가지는 것은 아닙니다.

사소한 Decision은 Agent에게 Autonomy를 줄 수 있습니다.

도메인이나 Architecture에 중요한 Decision은 Breakpoint가 더 적절할 수 있습니다.

Stop Conditions는 Autonomy의 끝을 정의한다

그래서 Explicit Stop Conditions는 내가 가장 유용하게 사용하는 Prompt Component 중 하나입니다.

예를 들면:

이 상황에 해당하는 기존 Architecture Pattern을
찾을 수 없다면:

STOP.

발견 내용을 보고하라.

새로운 Global Architecture Decision을
독자적으로 내리지 마라.

또는:

예상한 API가 존재하지 않거나
그 Contract가 설명된 Behavior와
본질적으로 다르다면:

STOP.

차이를 문서화하고
가능한 다음 단계를 제안하라.

다른 Breakpoint는 이런 것이 될 수 있습니다.

• 필요한 Contract가 없다
• Ticket이 실제 기존 Behavior와 충돌한다
• 요청된 구현이 정의된 Dependency Rule을 위반한다
• 도메인 State가 정의되지 않았다
• 구현에 Scope보다 훨씬 큰 변경이 필요하다

모든 불확실성을 미리 해결할 필요는 없다. 하지만 허용된 Decision Space가 어디에서 끝나는지는 정의할 수 있다.

따라서 Stop Conditions도 다른 Constraint와 같은 역할을 합니다.

전체 경로를 설명하지 않습니다.

Solution Space를 제한합니다.

최신 OpenAI Guidance 역시 이런 Stopping Conditions를 명시적으로 언급하며, Success Criteria와 Missing Evidence에 대한 규칙과 연결합니다. 이는 과거의 “비밀 Prompt 문구”라는 이미지와 꽤 멀리 떨어져 있습니다.

지속적인 결정은 하나의 Task 안에만 있으면 안 된다

Implementation 중 새로운 기본 원칙이 생길 수 있습니다.

특정 종류의 Feature에서는 앞으로 하나의 Mapper를 통일해서 써야 한다는 결론이 나올 수 있습니다. 새로운 Dependency Rule이 생길 수도 있고, Naming이 정해질 수도 있으며, 지금까지 암묵적이던 Architecture Pattern을 처음으로 명시적으로 결정할 수도 있습니다.

그 Decision은 먼저 현재 Working Context에 속합니다.

하지만 그다음 질문이 필요합니다.

다음 Feature에서는 이 Decision을 어디에서 찾을 것인가?

답이 “지난 화요일 Prompt”라면 문제가 있습니다.

지속적인 Rule에는 지속적인 장소가 필요합니다. 정보의 성격에 따라 Agent File, Skill, 프로젝트 문서, ADR, Architecture Test, 혹은 다른 Automated Rule이 될 수 있습니다.

Task-specific
→ Implementation Prompt

Reusable Workflow
→ Skill

Persistent Project Rule
→ Agent File / Documentation / ADR

Mechanically Verifiable Rule
→ Test / Linter / Architecture Rule

각 Agent System의 경계가 완전히 같지는 않습니다. 중요한 것은 Intent입니다.

Task-specific Decision은 Implementation Prompt에 속한다. 지속적인 Project Decision에는 지속적인 장소가 필요하다.

이것은 4편과 직접 연결되며 동시에 6편의 문제 하나를 피하게 합니다. 중요한 결정이 단지 어느 날 Code로 commit되었다는 이유만으로 Pattern이 되어서는 안 됩니다.

그 결정은 명시적으로 드러나야 합니다.

나는 이제 Implementation Prompt를 거의 직접 쓰지 않는다

여기서 내 개인적인 작업 방식 중 조금 특이하게 보일 수 있는 부분이 나옵니다.

짧은 Correction Prompt는 여전히 직접 씁니다. Task가 작고 명확하다면 별도의 프로세스가 필요하지 않습니다.

하지만 큰 Feature에서는 Requirements, Scope, Decisions, Architecture Questions, Acceptance Criteria를 적극적으로 다루면서도, 마지막의 상세 Implementation Prompt는 자주 직접 작성하지 않습니다.

LLM에게 맡깁니다.

나는 이제 Implementation Prompt를 거의 직접 쓰지 않는다. 대신 그 안에 들어갈 내용을 만든다.

이 차이는 나에게 중요합니다.

내 Attention을 “3번 Section 이름이 Constraints가 좋은가 Technical Boundaries가 좋은가”에 쓰고 싶지 않습니다.

어떤 Boundary가 실제로 적용되는지를 결정하는 데 쓰고 싶습니다.

강한 모델은 이미 정리된 정보를 Structured Work Assignment로 바꾸는 데 매우 뛰어납니다. Redundancy를 줄이고, Decisions를 묶고, Acceptance Criteria를 명시적으로 만들며, 여러 번의 대화를 하나의 일관된 Execution Briefing으로 정리할 수 있습니다.

Critical Boundary는 다른 곳에 있습니다.

AI는 Prompt를 써도 된다. 하지만 모르게 Requirements까지 만들어 내서는 안 된다.

Planning Model이 빠진 Product Decision을 그럴듯한 Variant로 채워 놓고, 그것을 자신 있게 Implementation Prompt에 적는다면 우리는 아무것도 개선하지 못했습니다.

Decision이 어디에서 만들어졌는지만 숨겼을 뿐입니다.

Anthropic이 2025년 10월부터 2026년 4월까지의 약 40만 Claude Code Session을 분석한 결과도 흥미로운 실무 그림을 보여 줍니다. 해당 Classifier-based Analysis에서 인간은 평균 약 70%의 Planning Decision을, Claude는 약 80%의 Execution Decision을 맡았습니다. Anthropic은 이를 분명한 역할 분담으로 해석합니다. 인간은 무엇을 만들지, 언제 Done인지 더 많이 결정하고, Agent는 실제 Execution을 더 많이 맡습니다. 이 연구는 Agentic Work의 보편 법칙은 아니지만, 내 작업 방식과 놀라울 만큼 비슷합니다.

OpenAI도 내부 agent-first 소프트웨어 프로젝트에서 유사한 이동을 설명합니다. 인간의 작업은 Environment를 설계하고, Intent를 명시하고, Feedback Loop를 만드는 쪽으로 이동했고, Codex가 Code를 생성했습니다.

내 짧은 표현은 이렇습니다.

인간이 반드시 Prompt를 authored할 필요는 없다. 인간은 Requirements를 authored한다.

Prompt를 “컴파일된 작업 산출물”로 보기

이 과정을—명확히 말해 단지 Metaphor로—작은 Compiler처럼 볼 수도 있습니다.

Intent
↓
Requirements
↓
Decisions
↓
Constraints
↓
LLM
↓
Execution Prompt
↓
Agent
↓
Artifact

“Prompt Compiler”라는 표현은 기술적으로 정확하지 않습니다. LLM은 TypeScript Compiler가 Source Code를 Compile하듯 Requirements를 Deterministic하게 Compile하지 않습니다.

하지만 mental model로서는 마음에 듭니다.

실제 가치가 어디에서 만들어지는지를 이동시켜 보기 때문입니다.

Prompt는 Feature를 갑자기 만들어 내는 Magic Source Code가 아닙니다.

이미 만들어진 정보와 의사결정을 Agent가 사용할 수 있도록 압축한 표현입니다.

그래서 최종 Prompt가 길어도 내가 그 문구 자체에 많은 시간을 쓰지 않았을 수 있습니다.

실제 작업은 그 전에 이미 일어났기 때문입니다.

같은 패턴은 글쓰기에도 적용된다

이 작업 방식은 Software Development에만 적용되지 않습니다.

이 글 시리즈 역시 처음부터 이렇게 시작하지 않습니다.

Hallucination에 대한 글을 써라.

대개 처음에는 Thesis나 Observation이 있습니다.

그다음 대화가 이어집니다. 개념을 분리하고, 너무 강한 주장에 반대하고, 연구를 찾고, 서로 비교할 수 없는 숫자를 버리고, 개인적인 경험을 적절한 맥락에 배치합니다. 그러고 나서야 어떤 주장이 실제로 방어 가능하고, 어떤 문장이 단지 그럴듯하게 들리는지 더 선명해집니다.

그 이후에 상세한 Generation Prompt가 만들어집니다.

Initial Thesis
↓
Discussion
↓
Research
↓
Counter-questions
↓
Decisions
↓
Narrative Thread
↓
Generation Prompt
↓
Draft
↓
Editorial Review

Generation Prompt에는 그때 이미 Title, Central Claims, Source Framework, Examples, 명시적으로 주장하면 안 되는 내용, 원하는 Transition, 다른 글과의 연결까지 포함될 수 있습니다.

겉에서 보면 “아주 잘 쓴 Prompt”처럼 보입니다.

실제로는 긴 Discovery의 마지막으로 보이는 단계일 뿐입니다.

Generation Prompt는 창의적인 시작점이 아니다. 그 전에 있었던 사고 과정의 결과다.

그리고 당연히 첫 Draft도 곧바로 Published Article은 아닙니다.

Generation과 Editorial Work는 여전히 다른 단계입니다.

이미지 생성도 마찬가지다

이미지도 비슷합니다.

Image Model에게 이렇게 요청할 수도 있습니다.

Architecture Drift에 대한 Infographic을 만들어라.

어쩌면 예쁜 이미지가 나올 수도 있습니다.

하지만 더 중요한 작업은 여전히 그 전에 시작됩니다.

그래픽은 무엇을 설명해야 하는가? 어떤 관계를 한눈에 보여 줘야 하는가? Process가 필요한가, Comparison이 필요한가, Spatial Metaphor가 필요한가? 이 이미지는 무엇을 잘못 암시해서는 안 되는가? 어떤 Text가 정확하게 보여야 하는가? 어떤 요소는 의미상 중요하고 어떤 것은 장식인가?

이 질문이 명확해진 다음에야 해당 Image Model이 잘 이해할 수 있는 Prompt로 번역할 필요가 생깁니다.

Communication Goal
↓
Visual Concept
↓
Boundaries of the Claim
↓
Visible Content
↓
Style
↓
Image Prompt
↓
Image Model

여기서도 인간이 반드시 최고의 Prompt Author일 필요는 없습니다.

중요한 것은 이미지가 무엇을 전달해야 하는지 아는 것입니다.

그다음 Specialized Model이나 다른 LLM이 그 Intent를 적절한 Image Prompt로 번역하는 일을 도울 수 있습니다.

Prompt Engineering은 Prompt 이전의 Engineering으로 이동한다

그래서 Prompt Engineering이라는 말의 의미가 내게는 달라졌습니다.

Prompt Engineering이 사라진 것은 아닙니다. 구체적인 문구는 여전히 중요하고, Structure, Examples, Priorities, Clear Instructions는 모델 행동에 영향을 줍니다.

하지만 실제 Agentic Work에서는 이것이 더 큰 문제 속의 일부입니다.

Anthropic은 기술적인 차원에서 이 변화를 Prompt Engineering에서 Context Engineering으로의 이동이라고 설명합니다. 특정 문구 하나를 최적화하는 것보다 모델에게 어떤 정보 상태를 언제 제공할 것인지 관리해야 한다는 뜻입니다. OpenAI도 실무에서 지나치게 경직되고 Prescriptive한 Prompt가 오히려 덜 잘 작동할 수 있었고, Goal과 Relevant Boundaries를 정의한 뒤 모델이 구체적인 Path를 결정하도록 하는 방식이 더 Robust했다고 설명합니다.

내 작업에서는 여기서 한 단계 더 나아가고 싶습니다.

Prompt Engineering은 Prompt를 쓰는 일에서, Prompt가 만들어지는 정보와 결정을 Engineering하는 일로 이동하고 있다.

여기에는 Discovery와 Requirements뿐 아니라 Context Selection, Architecture Rules, Acceptance Criteria, Verification, 그리고 Agent가 어디까지 스스로 결정할 수 있는지에 대한 의식적인 결정도 포함됩니다.

Prompt는 이 Process의 시작에 있지 않습니다.

상당히 뒤쪽에 있습니다.

Requirements는 첫 번째 경계다

이제 다시 이 글이 시리즈 안에서 어떤 역할을 하는지 돌아오겠습니다.

5편은 여러 개의 그럴듯한 Solution Path가 존재할 수 있음을 보여 줬습니다. 우리는 이 특성을 완전히 없애고 싶지 않습니다. Agent가 어떤 파일을 먼저 읽을지, 기존 Architecture 안에서 Local Implementation Detail을 어떻게 해결할지는 스스로 결정할 수 있습니다.

하지만 6편은 Plausible이 자동으로 Correct를 뜻하지 않는다는 점을 보여 줬습니다.

그래서 Boundary가 필요합니다.

Requirements는 먼저 마지막에 무엇이 반드시 성립해야 하는지를 정의합니다.

예를 들면:

어떤 도메인 State가 허용되는가? Success는 무엇인가? Error는 무엇인가? 어떤 사용자가 어떤 Action을 할 수 있는가? 무엇이 Scope에 속하는가? 어떤 Property는 협상 불가능한가? Implementation 후 어떤 Condition이 실제로 관찰 가능하게 충족되어야 하는가?

Requirements는 어떤 Outcome이 애초에 수용 가능한 것으로 간주될 수 있는지를 정의한다.

그렇다고 전체 Solution Path를 Deterministic하게 만드는 것은 아닙니다.

허용 가능한 Outcome Space를 설명합니다.

이 차이는 중요합니다.

Requirements는 아직 Architecture가 아니다

그럼에도 하나가 더 남습니다.

예를 들어 Requirement가 다음과 같다고 합시다.

사용자는 자신의 데이터만 수정할 수 있다.

이것은 원하는 도메인 또는 Security Behavior를 설명합니다.

반면 Architecture Rule은 이렇게 생길 수 있습니다.

Presentation은 Infrastructure에
직접 접근해서는 안 된다.

두 문장 모두 Solution을 제한하지만 서로 다른 수준에서 제한합니다.

Requirements는 주로 무엇이 반드시 성립해야 하는가를 설명합니다.

Architecture Constraints는 해결 과정에서 어떤 구조적 Boundary를 깨서는 안 되는가를 더 강하게 설명합니다.

Agent가 시스템의 더 큰 영역을 독립적으로 수정하기 시작하면 이 구분이 중요해집니다. 도메인 관점에서 완전히 올바른 Outcome도 구조적으로는 나쁜 Solution일 수 있기 때문입니다.

Prompt는 더 앞에서 시작된다

오늘 내가 여러 페이지짜리 Implementation Prompt를 Coding Agent에게 넘길 때, 가장 중요한 작업은 이미 끝나 있는 경우가 많습니다.

질문을 했고, Repository를 조사했고, 도메인 Decision과 Technical Decision을 분리했고, Scope와 Non-goals를 정했고, 누가 무엇을 결정할 권한이 있는지 확인했고, Agent가 어디까지 자율적으로 결정할 수 있는지 정했으며, 최종 결과를 어떻게 Verification할지도 정했습니다.

그다음에야 Prompt가 만들어집니다.

Prompt Engineering은 Prompt 전에 시작된다.

4편은 Agent가 Relevant Context를 필요로 한다는 것을 보여 줬습니다.

5편은 그 Context 안에서도 서로 다른 Solution Path를 선택할 수 있다는 것을 보여 줬습니다.

6편은 Plausible Path가 여전히 잘못된 가정 위에 설 수 있음을 보여 줬습니다.

7편은 그래서 다음 결론을 추가합니다.

우리는 어떤 Outcome을 수용할 것인지, Decision Space가 어디에서 끝나는지를 더 정확하게 정의해야 합니다.

Requirements는 첫 번째 Boundary입니다.

하지만 그것만으로는 충분하지 않습니다.

도메인 관점에서 무엇이 성립해야 하는가가 완전히 분명해도 한 가지 질문이 남습니다.

이미 존재하는 시스템의 구조에 맞는 Solution이라는 것을 어떻게 보장할 것인가?

다음 글은 바로 그 문제를 다룹니다.

Requirements는 도메인적으로 수용 가능한 Outcome을 제한한다. 다음 단계에서는 시스템 구조에도 같은 일을 해야 한다.

출처와 설명

• OpenAI – Model Guidance / Prompting Best Practices, 2026년 9월 기준. 현재 GPT-5.5 Guidance는 agentic tasks에서 Outcome, Success Criteria, Constraints, Available Evidence, Explicit Stopping Conditions를 정의하고 불필요한 Process Micromanagement는 피할 것을 권장합니다. 이는 제품별 Guidance이지 보편적인 Prompt Theory는 아닙니다. Model guidance
• OpenAI – Inside OpenAI’s in-house data agent, 2026년 1월. 이 실무 보고서는 Layered Context, 불명확하거나 불완전한 Instructions에 대한 적극적 Clarification, 합리적인 Defaults, 그리고 “Guide the Goal, Not the Path”라는 경험을 설명합니다. Code를 Semantic Evidence의 원천으로 직접 사용하는 방식도 다룹니다. Inside OpenAI’s in-house data agent
• OpenAI – Harness engineering: leveraging Codex in an agent-first world, 2026년 2월. 내부 agent-first 소프트웨어 프로젝트에서 인간의 역할이 Intent, Environment Design, Feedback Loops 쪽으로 크게 이동한 사례를 설명합니다. 거대한 단일 AGENTS.md는 문제가 되었고, 더 짧은 Agent 파일이 Versioned Knowledge Base로 가는 안내 역할을 하게 되었습니다. Harness engineering
• Anthropic – Effective context engineering for AI agents, 2025년 9월. Anthropic은 Context를 유한한 자원으로 설명하며, 특정 Prompt 문구 최적화보다 어떤 정보를 모델이 어느 시점에 사용할 수 있어야 하는지를 설계하는 데 초점을 둡니다. Effective context engineering for AI agents
• Anthropic – Agentic coding and persistent returns to expertise, 2026년 6월. 2025년 10월부터 2026년 4월까지 약 40만 건의 Claude Code Session을 Privacy-preserving, Classifier-based 방식으로 분석했습니다. Typical Session에서는 인간이 약 70%의 Planning Decision을, Claude가 약 80%의 Execution Decision을 담당했습니다. 이는 하나의 구체적인 제품 사용 패턴을 설명하는 것이지 Agentic Work의 보편 법칙은 아닙니다. Agentic coding and persistent returns to expertise
• Anthropic – Harness design for long-running application development, 2026년 3월. Planner / Generator / Evaluator 구조, Sprint Contract, Testable Criteria를 다룹니다. 특히 나중의 단순화가 흥미롭습니다. Opus 4.6을 사용하면서 Sprint Decomposition을 제거할 수 있었지만, Evaluator는 모델 Capability Limit 근처에서 여전히 가치를 제공했습니다. Harness design for long-running application development
• Franch et al. – Leveraging Requirements Elicitation through Software Requirement Patterns and LLMs, REFSQ 2025. LLM이 생성한 Stakeholder Question이 기본적으로 활용 가능하지만 반복과 Out-of-Scope Question이 발생할 수 있으며 상당한 Expert Assessment가 여전히 필요하다는 점을 보여 줍니다. Publication entry
• Eltahier et al. – Automated Software Requirements Elicitation: A Systematic Mapping Study, 2026년 8월. 2021년부터 2025년까지의 Peer-reviewed Paper 74편을 정리했습니다. 74편 모두 Identification을 Automation하며, 51%는 Structuring, 23%는 Consolidation, 8%만이 기술적으로 통합된 Stakeholder Validation까지 도달합니다. Information 17(8), 777
• Pasquale et al. – Exploring the Use of LLMs for Requirements Specification in an IT Consulting Company, IEEE RE 2025. 산업 사례에서는 LLM이 Requirements Specification의 표준화와 작성에 도움을 줄 수 있지만 품질이 Input에 크게 의존하며, 인간의 도메인 및 기술 Review가 여전히 필요하다는 점을 보여 줍니다. IEEE DOI