Opus 4.6과의 진로 상담

Author: Claude Opus 4.6, mangowhoiscloud
Purpose: Interface Engineering과 Prompt Engineering의 기술적 구분을 코드/아키텍처 레벨에서 서술
Date: 2026-02-08

Executive Summary

"프롬프트 잘 짠다"는 LLM 시대의 대표적 스킬로 인식되지만, 이 영역은 DSPy(Stanford NLP)와 같은 자동 최적화 프레임워크에 의해 빠르게 자동화되고 있습니다. 본 문서는 Prompt Engineering("무엇을 말할 것인가")과 Interface Engineering("LLM과 시스템이 어떤 계약으로 소통할 것인가")이 코드·아키텍처 수준에서 본질적으로 다른 작업임을 증명합니다.

핵심 논지: structured output 강제, tool-call contract 설계, schema validation, failure handling 등 Interface Engineering의 핵심 패턴은 모델 발전에 의해 흡수되지 않는 자동화 저항성이 높은 시스템 설계 영역입니다.

프레임워크: Andrej Karpathy가 2025년 제안한 Context Engineering(LLM=CPU, context window=RAM)을 상위 개념으로 위치시키고, 2026년 2월 제안한 Agentic Engineering  "코드를 직접 작성하지 않고 에이전트를 오케스트레이션하며, 아키텍처·품질·정확성의 소유권은 인간이 유지하는" 엔지니어링 규율이 본 문서의 Interface Engineering 논지와 정합함을 보입니다. ReliabilityBench(2026), Anthropic의 Opus 4.6 공식 튜토리얼(2026) 등의 실증 자료로 뒷받침합니다.

---

1. 문제 제기: "프롬프트 잘 짠다"의 기술 밀도

1.1 Prompt Engineering의 정의

Prompt Engineering은 LLM에 전달하는 단일 지시문(instruction)의 표현과 구조를 최적화하는 작업입니다. 여기에는 role-playing("You are a legal assistant"), few-shot 예시 배치, Chain-of-Thought 유도("Let's think step by step"), temperature 조정 등이 포함됩니다.

이 작업의 본질은 자연어 문자열 조작입니다:

# Prompt Engineering의 전형적 작업
prompt_v1 = "Summarize this document"
prompt_v2 = "Summarize this document in 3 bullet points, focusing on key findings"
prompt_v3 = "You are a senior analyst. Summarize this document in 3 bullet points..."

각 반복(iteration)은 문자열을 수정하고, 출력을 관찰하고, 다시 문자열을 수정하는 과정입니다. 이 루프는 체계적이지 않으며, 재현 가능성(reproducibility)이 낮습니다.

1.2 자동화의 현실: DSPy와 프롬프트 최적화

Stanford NLP의 DSPy는 이 수동 루프를 프로그래밍 문제로 재정의했습니다. DSPy의 핵심 주장은 명확합니다:

"Programming—not prompting—language models."
— DSPy GitHub (Stanford NLP, 2023–2025)

DSPy의 MIPROv2 옵티마이저는 다음 3단계를 자동화합니다:

단계	수동 Prompt Engineering	DSPy 자동화
예시 생성	사람이 few-shot 예시 수작업	BootstrapFewShot이 trace에서 고품질 예시 자동 필터링
지시문 탐색	"좀 더 구체적으로..." 반복	MIPRO가 Bayesian Optimization으로 instruction space 탐색
모델 전환	새 모델마다 프롬프트 재작성	설정 변경 + 재컴파일로 동일 파이프라인 유지

DSPy Multi-Use Case Study(arxiv:2507.03620, 2025.07)는 5개 유즈케이스에서 테스트한 결과, 기본적인 프롬프트도 DSPy 최적화를 거치면 전문가가 수작업한 프롬프트에 근접하는 성능을 달성했다고 보고합니다. Prompt Evaluation 태스크에서는 정확도가 46.2% → 64.0%로 상승했습니다.

이것이 의미하는 바는 직접적입니다: 수동 프롬프트 튜닝은 프로그래밍으로 대체 가능한 영역입니다.

1.3 판단 기준: 자동화 저항성

엔지니어 스킬의 지속 가능성을 평가하는 핵심 질문이 있습니다:

"이 스킬은 모델이 한 세대 좋아지면 사라지는가?"

Prompt Engineering의 대부분은 YES입니다. temperature 실험, phrasing 개선, jailbreak 대응 — 이들은 모델 발전에 의해 흡수됩니다. GPT-3에서 필요했던 정교한 프롬프팅 테크닉 상당수가 GPT-4에서는 불필요해졌고, 이 패턴은 계속됩니다.

Anthropic의 Claude Opus 4.6 공식 튜토리얼(2026.02)은 다음과 같이 안내합니다:

"Skip the role setting. You don't need to tell Opus 4.6 to 'act as a [professional]' or 'be an expert in…'. Opus 4.6 infers the appropriate level of expertise from the task and context you provide."
— Anthropic, "Get the most from Claude Opus 4.6" (2026.02)

 

Role-playing("You are a senior analyst...")은 Prompt Engineering의 가장 대표적인 테크닉 중 하나였습니다. Anthropic이 자사 모델의 공식 가이드에서 이 테크닉을 불필요하다고 선언한 것은, 모델 발전이 프롬프트 테크닉을 흡수하는 과정 중 하나입니다. 같은 문서는 추가적인 패턴 변화도 기록합니다:

이전의 Prompt Engineering 관행	Opus 4.6에서의 변화	의미
지시를 반복 강조 ("And remember to...")	"Say it once. Trust that instructions landed."	반복 프롬프팅 불필요 — 모델이 instruction following 자체를 개선
few-shot 예시 대량 삽입	"A few clear examples is enough."	예시 최적화 작업 축소 — 일반화 능력 향상
role-playing 프롬프트	"Skip the role setting."	역할 지정 불필요 — context에서 전문성 수준 추론
단계별 가이드 제공	"Opus 4.6 orients itself."	사전 구조화 축소 — 모델이 자체적으로 context를 수집·정리

이 4가지는 모두 Prompt Engineering의 주요 기법입니다. 모델 한 세대의 업그레이드로 공식 가이드에서 "불필요"로 재분류된 것입니다.

그러나 같은 문서에서 여전히 강조하는 것은 "Front-load your context", "Set check-in points", "Ask to explore alternatives" 등 — 이들은 모두 context 설계와 실행 계약에 관한 것으로, Interface Engineering의 영역입니다. 모델이 좋아질수록 프롬프트 문자열 조작의 가치는 감소하지만, 시스템 레벨의 인터페이스 설계의 가치는 오히려 증가합니다.

---

2. 개념 정의: Context Engineering 프레임 내의 위치

2.1 Karpathy의 Context Engineering 프레임워크

2025년 6월, Andrej Karpathy는 다음 비유를 제시했습니다:

"LLM은 CPU다. Context window는 RAM이다."
— Andrej Karpathy, X (2025.06)

 

이 비유에서 Context Engineering은 운영체제(OS)에 해당합니다. RAM에 무엇을 적재할지, 언제 적재할지를 결정하는 시스템 설계입니다. Karpathy는 이를 다음과 같이 정리합니다:

"Context engineering is the delicate art and science of filling the context window with just the right information for the next step."

 

2025년 7월, Mei et al.의 서베이(arxiv:2507.13334)는 1,400+ 논문을 분석하여 Context Engineering을 정식 학문 분야(formal discipline)로 제안했습니다. 이 서베이는 Context Engineering을 3개 기초 컴포넌트(retrieval/generation, processing, management)와 4개 시스템 구현(RAG, memory, tool-integrated reasoning, multi-agent)으로 분류합니다.

2.2 3계층 구분: Prompt → Interface → Context

이 프레임 안에서 세 개념의 계층적 관계가 드러납니다:

┌─────────────────────────────────────────────┐
│          Context Engineering                │
│   "LLM이 보는 전체 정보 환경 설계"            │
│                                             │
│  ┌─────────────────────────────────────┐    │
│  │      Interface Engineering          │    │
│  │  "LLM과 시스템 간 계약 설계"          │    │
│  │                                     │    │
│  │  ┌─────────────────────────────┐    │    │
│  │  │   Prompt Engineering        │    │    │
│  │  │  "지시문 문자열 최적화"        │    │    │
│  │  └─────────────────────────────┘    │    │
│  │                                     │    │
│  │  + structured output schema         │    │
│  │  + tool-call contract               │    │
│  │  + failure handling                 │    │
│  │  + validation pipeline              │    │
│  └─────────────────────────────────────┘    │
│                                             │
│  + RAG / retrieval architecture             │
│  + memory hierarchy                         │
│  + state management                         │
│  + multi-agent orchestration                │
│  + eval pipeline                            │
└─────────────────────────────────────────────┘

Prompt Engineering은 "무엇을 말할 것인가(what to say)"를 최적화합니다.

Interface Engineering은 "어떤 형식으로, 어떤 계약으로 소통할 것인가(how to contract)"를 설계합니다.

Context Engineering은 "전체 정보 환경을 어떻게 구성할 것인가(what to architect)"를 다룹니다.

DSPy가 자동화하는 것은 첫 번째 레이어입니다. 두 번째와 세 번째 레이어는 시스템 설계 문제이며, 자동화 저항성이 본질적으로 다릅니다.

---

3. Interface Engineering의 4가지 핵심 패턴

3.1 Pattern 1: Structured Output Schema — 출력의 타입 안전성

Prompt Engineering 접근:

# ❌ Prompt Engineering: 문자열로 포맷 요청
prompt = """You are a helpful assistant.
Extract the address from the text below.
Your output MUST be valid JSON, enclosed in triple backticks.
Include fields: street, city, country, postal_code."""

이 방식의 문제점은 실증적으로 확인됩니다. Geol.ai의 50+ 소스 분석(2026.01)에 따르면, 프롬프트만으로 JSON을 요청할 때 validity rate는 73%에 불과합니다. 나머지 27%는 마크다운 코드 블록, 부연 설명, 누락된 필드 등으로 파싱에 실패합니다.

Interface Engineering 접근:

# ✅ Interface Engineering: 스키마로 계약 강제
# (OpenAI Responses API/Agents API, 2025~ — structured output를 네이티브 지원하는 최신 인터페이스)
from pydantic import BaseModel

class Address(BaseModel):
    street: str
    city: str
    country: str
    postal_code: str

response = client.responses.parse(
    model="gpt-4o",
    input=[{"role": "user", "content": "123 Main St, Madrid, Spain 28001"}],
    text_format=Address   # 스키마가 곧 계약
)

address: Address = response.output_parsed  # 타입 안전한 객체

JSON Schema + validation + reprompt를 적용하면 validity rate는 94%, 제한적 수리(repair)를 추가하면 97%까지 상승합니다(Geol.ai, 2026).

핵심적 차이: 첫 번째 코드는 LLM에게 부탁합니다. 두 번째 코드는 LLM에게 계약을 강제합니다. 전자는 phrasing에 민감하고 모델마다 다시 작성해야 합니다. 후자는 Pydantic 모델이라는 프로그래밍 인터페이스이며, 모델을 교체해도 스키마는 유지됩니다.

Azati(2025)는 이 구분을 Schema-Guided Reasoning(SGR)이라는 개념으로 격상시킵니다:

"Structured output is the contract. SGR is the way you design that contract so the model can think reliably inside it."
— Azati, Schema-Guided Reasoning (2025.09)

SGR은 필드 순서, 그룹핑, 중간 계산의 cascading까지 스키마에 설계합니다. 모델이 특정 필드에 도달할 때, 직전 context에 이미 필요한 정보가 포함되도록 스키마 자체가 추론 구조를 인코딩합니다. 이것은 "microprompting embedded into the response format"이며, prompt tweaking과는 완전히 다른 레벨의 설계입니다.

3.2 Pattern 2: Tool-Call Contract — 함수 시그니처로서의 프롬프트

Prompt Engineering 접근:

# ❌ Prompt Engineering: 자연어로 도구 사용 유도
prompt = """You have access to a weather API.
When the user asks about weather, call the API like this:
get_weather(city="Seoul", unit="celsius")
Please include the function call in your response."""

Interface Engineering 접근:

# ✅ Interface Engineering: tool-call contract 정의
tools = [{
    "type": "function",
    "function": {
        "name": "get_weather",
        "description": "Get current weather for a location",
        "parameters": {
            "type": "object",
            "properties": {
                "city": {"type": "string", "description": "City name"},
                "unit": {"type": "string", "enum": ["celsius", "fahrenheit"]}
            },
            "required": ["city"]
        }
    }
}]

response = client.chat.completions.create(
    model="gpt-4o",
    messages=messages,
    tools=tools,
    tool_choice="auto"  # 모델이 필요시 도구 호출
)

첫 번째 코드에서 LLM은 자연어 응답 안에 함수 호출을 "흉내"냅니다. 파싱이 불안정하고, 모델이 존재하지 않는 함수를 환각(hallucinate)할 수 있습니다. 두 번째 코드에서 LLM은 정의된 함수 시그니처에 대해 structured 인자를 생성합니다. vLLM의 구현(2025)은 tool_choice="required" 설정 시 structured output 백엔드를 사용하여 스키마를 만족하는 도구 호출만 생성되도록 강제합니다. 이 차이는 인터페이스 설계(interface design)입니다. 도구 스키마는 API contract이며, 이를 설계하려면 시스템의 기능 분해(functional decomposition), 에러 모드 분석, 인자 유효 범위 정의 등 소프트웨어 엔지니어링 역량이 필요합니다.

3.3 Pattern 3: Failure Handling — 장애를 설계 대상으로

Prompt Engineering 접근:

# ❌ Prompt Engineering: 프롬프트에 에러 처리 요청
prompt += "\nIf you cannot find the answer, say 'I don't know'."

Interface Engineering 접근:

# ✅ Interface Engineering: schema validation + fallback chain
from pydantic import BaseModel, ValidationError

class ToolCallResult(BaseModel):
    action: str
    parameters: dict
    confidence: float

def execute_with_fallback(llm_response: str) -> ToolCallResult:
    try:
        # 1차: Schema validation
        result = ToolCallResult.parse_raw(llm_response)
        if result.confidence < 0.7:
            raise ValueError("Low confidence")
        return result
    except (ValidationError, ValueError):
        # 2차: Sanitation agent
        result = fallback_sanitizer.correct(llm_response)
        return result
    except Exception:
        # 3차: Deterministic fallback
        return ToolCallResult(
            action="escalate_to_human",
            parameters={"reason": "parse_failure"},
            confidence=0.0
        )

ReliabilityBench(arxiv:2601.06112, 2026.01)는 LLM 에이전트에 chaos engineering 원칙을 적용한 최초의 체계적 평가입니다. 1,280개 에피소드에서의 핵심 발견:

장애 유형	성공률 영향	시사점
Transient timeout	98.75% pass	단순 재시도로 충분히 처리
Rate limiting	-2.5% (최대 열화)	에이전트가 backoff 로직에 취약
Schema drift	후속 도구 호출까지 전파	validation이 없으면 cascading failure
Perturbation (동의어 치환, 산만 주입)	-8.8%	입력 변형에 상당히 취약

특히 주목할 발견: 단순한 ReAct 아키텍처가 복잡한 Reflexion보다 장애 복구에서 더 우수했습니다(reliability surface volume 2.5% 차이). 복잡한 추론 아키텍처가 도입하는 추가 실패 모드가 이점을 상쇄한 것입니다.

또한 τ-bench(2024)는 단일 실행(pass@1) 60%를 달성한 에이전트가 반복 실행 시 25% 일관성만 보인다고 보고합니다. 벤치마크 성능과 프로덕션 신뢰성 사이의 갭은 프롬프트가 아닌 시스템 수준 장애 처리로만 해소됩니다.

3.4 Pattern 4: Evaluation Pipeline — 품질을 측정 가능하게

Prompt Engineering의 평가:

사람이 출력을 눈으로 확인 → "이전보다 좋아 보인다" → 프롬프트 반영

Interface Engineering의 평가:

# ✅ Interface Engineering: 메트릭 기반 파이프라인
def evaluate(program, dataset, metric_fn):
    scores = []
    for example in dataset:
        output = program(example.input)
        score = metric_fn(output, example.expected)
        scores.append(score)
    return {
        "mean": statistics.mean(scores),
        "std": statistics.stdev(scores),
        "pass_rate": sum(1 for s in scores if s > threshold) / len(scores)
    }

# metric 정의 → 데이터셋 준비 → 프로그램 평가 → 최적화 → 재평가

DSPy는 이를 더 직접적으로 구현합니다:

# ✅ DSPy: 메트릭 정의 → 컴파일러가 프롬프트 자동 최적화
import dspy

# 1. 메트릭 정의 — 엔지니어의 핵심 설계 영역
def quality_metric(example, prediction, trace=None):
    schema_valid = isinstance(prediction, ServiceResponse)  # 스키마 준수
    tone_match = prediction.tone == example.expected_tone    # 톤 일치
    policy_cited = prediction.referenced_policy is not None  # 정책 인용 여부
    return schema_valid and tone_match and policy_cited

# 2. 평가 실행 — 자동화
evaluator = dspy.Evaluate(devset=dev_set, metric=quality_metric, num_threads=8)
score = evaluator(my_program)

# 3. 최적화 — 메트릭 기반으로 프롬프트를 컴파일러가 자동 생성
optimizer = dspy.MIPROv2(metric=quality_metric, auto="medium")
optimized = optimizer.compile(my_program, trainset=train_set)

핵심 차이: 무엇을 측정할 것인가(metric 설계)와 무엇을 기준으로 판단할 것인가(dataset curation)는 도메인 전문성이 필요한 설계 영역이며, 프롬프트 문자열 자체의 최적화는 컴파일러에 위임됩니다.

DSPy의 실질적 기여는 프롬프트 자동화 자체보다, "메트릭을 정의하면 최적화는 컴파일러가 한다"는 패러다임 전환에 있습니다. 이 패러다임에서 엔지니어의 핵심 역할은 프롬프트 작성이 아니라 메트릭 설계, 데이터셋 큐레이션, 파이프라인 구조화입니다.

---

4. 코드 수준 비교: 동일 태스크, 다른 접근

고객 서비스 응답 생성이라는 동일 태스크를 두 접근 방식으로 구현하면 차이가 명확합니다.

4.1 Prompt Engineering 접근

# 전체 "시스템": 하나의 문자열
system_prompt = """You are a customer service agent.
Your job is to provide a single, concise response.
Be empathetic but professional.
If unsure, ask for clarification.
Response format: plain text, 2-3 sentences max."""

response = openai.chat.completions.create(
    model="gpt-4o",
    messages=[
        {"role": "system", "content": system_prompt},
        {"role": "user", "content": customer_query}
    ]
)
# → 문자열 출력, 포맷 보장 없음, 테스트 불가

기술적 특성:

• 입출력이 모두 비구조화 문자열
• 평가 기준이 "좋아 보이는가"에 의존
• 모델 변경 시 프롬프트 재작성 필요
• 장애 모드: 무응답, 형식 이탈, 할루시네이션 → 모두 같은 코드 경로

4.2 Interface Engineering 접근

from pydantic import BaseModel, Field
from enum import Enum

# 1. 출력 계약 정의
class ResponseTone(str, Enum):
    empathetic = "empathetic"
    professional = "professional"
    escalation = "escalation"

class ServiceResponse(BaseModel):
    message: str = Field(max_length=500)
    tone: ResponseTone
    requires_followup: bool
    confidence: float = Field(ge=0.0, le=1.0)
    referenced_policy: str | None = None

# 2. 도구 계약 정의
tools = [{
    "type": "function",
    "function": {
        "name": "lookup_order",
        "parameters": {
            "type": "object",
            "properties": {
                "order_id": {"type": "string", "pattern": "^ORD-[0-9]{6}$"}
            },
            "required": ["order_id"]
        }
    }
}]

# 3. 실행 + validation + fallback
def handle_customer_query(query: str) -> ServiceResponse:
    try:
        raw = call_llm(query, tools=tools, response_schema=ServiceResponse)
        response = ServiceResponse.parse_raw(raw)

        # 4. 비즈니스 로직 기반 라우팅
        if response.confidence < 0.5:
            return escalate_to_human(query, reason="low_confidence")
        if response.requires_followup:
            schedule_followup(query, response)

        return response
    except ValidationError as e:
        log_schema_violation(e, query)
        return fallback_response(query)
    except RateLimitError:
        return retry_with_backoff(query, max_retries=3)

기술적 특성:

• 입출력이 타입 안전한 구조체
• 평가 기준이 schema compliance, confidence threshold로 정량적
• 모델 변경 시 스키마 유지, 재컴파일만 필요
• 장애 모드별 분기된 처리 경로

---

5. 자동화 저항성 분석: 왜 Interface Engineering은 자동화되기 어려운가

5.1 기술 밀도 스펙트럼

두 영역의 자동화 저항성을 결정하는 요인을 분석합니다:

요인	Prompt Engineering	Interface Engineering
입력 공간	자연어 문자열 (연속적)	스키마·계약·아키텍처 (이산적, 구조적)
최적화 가능성	gradient-free search로 자동화 가능 (DSPy 증명)	도메인 요구사항 분석 필요, 자동화 난이도 높음
모델 의존성	모델 세대마다 최적 프롬프트 변화	스키마·계약은 모델 독립적
진입 장벽	언어 감각 + 실험 (비전공자 접근 가능)	타입 시스템, API 설계, 분산 시스템 이해 필요
실패 모드	"출력이 이상하다" (관찰적)	ValidationError, TimeoutError, SchemaViolation (구조적)
테스트 가능성	A/B 비교, 주관적	unit test, integration test, chaos test

5.2 시스템 권력(System Power)

엔지니어 커리어에서 강한 포지션은 "시스템을 통제하는 사람"에서 나옵니다. 본 문서는 이를 평가하는 간단한 모델을 제안합니다:

시스템 권력 = f(제거 비용, 대체 난이도, 영향 범위)

Prompt Engineering의 시스템 권력:

• 제거 비용: 낮음 — DSPy 컴파일러나 다른 사람이 대체 가능
• 대체 난이도: 낮음 — 패턴 학습으로 빠르게 습득
• 영향 범위: 단일 LLM 호출

Interface Engineering의 시스템 권력:

• 제거 비용: 높음 — 스키마 변경은 하위 시스템 전체에 cascade
• 대체 난이도: 높음 — 도메인 지식 + 시스템 설계 역량 필요
• 영향 범위: 전체 파이프라인 (LLM 호출 → validation → routing → 모니터링)

5.3 Complexity의 소재지

LLM 시대에도 희소한 엔지니어는 complexity를 다룰 수 있는 사람입니다.

Prompt Engineering의 complexity:

• 문자열 조합의 경우의 수 → 넓지만 얕은 탐색 공간
• DSPy가 Bayesian Optimization으로 효과적 탐색 가능

Interface Engineering의 complexity:

• 스키마 간 의존성 그래프
• 장애 모드의 조합적 폭발 (ReliabilityBench: 3차원 reliability surface)
• 일관성(consistency), 관찰 가능성(observability), 비동기 오케스트레이션
• 분산 시스템 고유의 복잡도 — 이것은 알고리즘이 아닌 경험의 영역

LangChain의 Context Engineering 정리(2025.10)는 agent context를 write, select, compress, isolate 4가지 패턴으로 분류합니다. 이 4가지 각각이 시스템 설계 문제입니다. "무엇을 context에 쓸 것인가(write)"는 메모리 아키텍처, "무엇을 선택할 것인가(select)"는 retrieval 설계, "어떻게 압축할 것인가(compress)"는 토큰 효율 최적화, "어떻게 격리할 것인가(isolate)"는 multi-agent 분리입니다.

---

6. 산업 방향: Context Engineering에서 Agentic Engineering으로

2025년 7월, Gartner는 다음과 같이 선언했습니다:

"Context engineering is in, and prompt engineering is out."
— Gartner (2025.07)

이 선언의 기술적 근거는 본 문서에서 분석한 것과 일치합니다. Cognition AI(Devin 개발사)는 더 직접적으로 표현합니다:

"Context engineering is effectively the #1 job of engineers building AI agents."

Geol.ai의 6개월 실증 분석(2025.07~2026.01)은 이를 뒷받침합니다:

"The winning LLM applications won't be the ones with the best prompts. They'll be the ones with the best data contracts."

6.1 Karpathy의 진화: Context Engineering → Agentic Engineering

2026년 2월 4일, Andrej Karpathy는 "vibe coding" 1주년 회고에서 산업의 다음 단계를 명명했습니다:

"Many people have tried to come up with a better name for this to differentiate it from vibe coding, personally my current favorite 'agentic engineering.'"
— Andrej Karpathy, X (2026.02.04)

Karpathy는 두 단어 각각에 명확한 의미를 부여합니다:

구성 요소	의미	본 문서와의 대응
"agentic"	코드를 직접 작성하지 않음. 99%의 시간을 에이전트 오케스트레이션과 감독(oversight)에 사용	Interface Engineering의 tool-call contract, failure handling — 에이전트의 행동을 계약으로 규정하고 장애를 처리
"engineering"	배울 수 있고, 깊이가 있는 art & science. 프롬프트 DJ가 아닌 엔지니어링 규율(discipline)	schema validation, eval pipeline — 재현 가능하고 측정 가능한 시스템 설계

 

이 구분은 Addy Osmani(Google Engineering Lead)의 분석에서 더 선명해집니다:

"Vibe coding = YOLO. Agentic engineering = AI does the implementation, human owns the architecture, quality, and correctness."
— Addy Osmani, "Agentic Engineering" (2026.02.04)

 

Osmani가 제시하는 agentic engineering의 실천 원칙은 본 문서의 Interface Engineering 패턴과 1:1로 대응합니다:

Agentic Engineering 원칙              Interface Engineering 패턴 (본 문서)
─────────────────────────────────────────────────────────────────────
"You start with a plan"            → Schema 설계 (Section 3.1: Pydantic 모델 정의)
"You direct, then review"          → Tool-call contract (Section 3.2: function signature as interface)
"You test relentlessly"            → Eval pipeline (Section 3.4: DSPy compiler paradigm)
"You own the codebase"             → Failure handling (Section 3.3: schema validation + fallback chain)

 

핵심 통찰은 이것입니다: Karpathy가 2025년에 "무엇을 RAM에 적재할 것인가"(Context Engineering)를 물었다면, 2026년에는 "누가 어떤 계약 하에 실행할 것인가"(Agentic Engineering)를 묻고 있습니다. 전자는 정보 관리(information management)이고, 후자는 실행 계약(execution contract)입니다. Interface Engineering은 이 두 질문이 만나는 교차점에 위치합니다.

Osmani는 한 가지 불편한 현실도 지적합니다:

"Agentic engineering disproportionately benefits senior engineers."

 

시스템 설계, 보안 패턴, 성능 트레이드오프를 이해하는 엔지니어에게 AI는 massive force multiplier가 됩니다. 반면, 기초 없이 AI에 의존하는 주니어 엔지니어는 "프롬프트할 수는 있지만 디버깅할 수 없고, 생성할 수는 있지만 추론할 수 없는" 위험한 기술 위축(skill atrophy)에 직면합니다. 이것은 본 문서의 자동화 저항성 프레임과 정확히 동일한 논리입니다. 기초 엔지니어링 역량이 곧 자동화에 저항하는 역량입니다.

6.2 용어의 진화가 보여주는 산업 방향

Karpathy 한 사람의 용어 진화가 산업 전체의 방향을 압축합니다:

2025.02  Vibe Coding        "그냥 프롬프트 때려넣고, 되면 되는 거지"
                             → Prompt Engineering의 극단적 표현
2025.06  Context Engineering "LLM은 CPU, context window는 RAM"
                             → 정보 관리 시스템으로의 전환
2026.02  Agentic Engineering "에이전트를 오케스트레이션하고, 아키텍처를 소유하라"
                             → 실행 계약과 엔지니어링 규율의 강조

이 궤적은 본 문서의 3계층 모델(Prompt → Interface → Context)과 방향이 일치합니다. 프롬프트 문자열 조작에서 시작하여, 시스템 계약 설계로, 최종적으로 에이전트 오케스트레이션으로 기술 밀도가 높아지는 방향으로 산업이 이동하고 있습니다.

---

7. 실무 함의: 포지션 맵

7.1 기술 밀도에 따른 LLM 엔지니어 분류

자동화 저항성 (높음)
 ▲
 │  ■ retrieval architecture
 │  ■ memory hierarchy design
 │  ■ eval pipeline
 │  ■ tool orchestration         ← Interface/Context Engineering
 │  ■ agent reliability
 │  ■ cost/latency tradeoff
 │  ■ multi-agent coordination
 │  ─────────────────────────────
 │  □ structured output design   ← 경계 영역
 │  □ schema-guided reasoning
 │  ─────────────────────────────
 │  ○ few-shot 예시 선택
 │  ○ chain-of-thought 유도
 │  ○ temperature 실험           ← Prompt Engineering
 │  ○ phrasing 개선
 │  ○ jailbreak 대응
 │
 └──────────────────────────────► 자동화 속도 (높음)

7.2 올바른 위치 설정

Prompt Engineering은 다른 역량을 증폭시키는 보조 기술로 multiplier skill입니다. 그러나 core identity가 되어서는 안 됩니다.

좋은 엔지니어는 프롬프트도 잘 다룹니다. 차이는 여기 있습니다:

• ❌ 프롬프트를 "튜닝 대상"으로 봄 → 문자열을 반복 수정
• ✅ 프롬프트를 "설계 대상"으로 봄 → 스키마, 계약, 장애 모드를 설계

후자가 Interface Engineering이며, 이는 prompt engineering이 아니라 software engineering의 LLM 시대 확장입니다.

---

8. 결론

Prompt Engineering과 Interface Engineering의 구분은 표현(wording)과 계약(contract)의 차이입니다. 전자는 자연어 문자열을 조작하며 DSPy에 의해 자동화가 진행 중입니다. 후자는 스키마, 타입 시스템, 장애 모드, 검증 파이프라인을 설계하며, 이는 소프트웨어 엔지니어링의 본질적 복잡도를 내포합니다.

Karpathy의 프레임에서 정리하면: Prompt Engineering은 RAM에 적재할 개별 명령어를 최적화하는 것이고, Interface Engineering은 CPU와 RAM 사이의 ISA(Instruction Set Architecture)를 설계하는 것이며, Context Engineering은 운영체제 전체를 설계하는 것입니다. 그리고 2026년의 Agentic Engineering은 이 운영체제 위에서 다수의 프로세스(에이전트)를 오케스트레이션하는 시스템 관리자가 되는 것입니다.

Karpathy 자신의 용어가 1년 만에 Vibe Coding → Context Engineering → Agentic Engineering으로 진화한 것은, 산업이 "프롬프트 문자열을 잘 쓰는 것"에서 "실행 계약을 설계하는 것"으로 이동하고 있다는 가장 명확한 증거입니다.

모델은 한 세대마다 좋아집니다. 좋은 프롬프트의 정의도 따라서 변합니다. 그러나 시스템 간 계약(contract), 장애 경로(failure path), 검증 파이프라인(validation pipeline)은 모델 세대와 무관하게 설계가 필요합니다. 프롬프트는 기술이 아니라 인터페이스입니다. 에이전트를 오케스트레이션하고, 시스템을 설계하는 사람이 되십시오.

---

References

1. DSPy: Programming—not prompting—Language Models. Stanford NLP. https://dspy.ai/
2. Karpathy, A. (2025.06). Context engineering post. X (Twitter). https://x.com/karpathy/status/1937902205765607626
3. Karpathy, A. (2026.02.04). Agentic Engineering — Vibe coding 1주년 회고. X (Twitter). https://x.com/karpathy/status/2019137879310836075
4. Osmani, A. (2026.02.04). Agentic Engineering. AddyOsmani.com. https://addyosmani.com/blog/agentic-engineering/
5. Mei, L. et al. (2025). A Survey of Context Engineering for Large Language Models. arXiv:2507.13334.
6. Martin, L. (2025.10). Context Engineering for Agents. LangChain Blog. https://rlancemartin.github.io/2025/06/23/context_engineering/
7. DSPy Multi-Use Case Study (2025.07). Is It Time To Treat Prompts As Code? arXiv:2507.03620.
8. ReliabilityBench (2026.01). Evaluating LLM Agent Reliability Under Production-Like Stress Conditions. arXiv:2601.06112.
9. Azati (2025.09). Schema-Guided Reasoning: Fixing Broken LLM Pipelines. Medium.
10. Geol.ai (2026.01). Structured Data for LLMs: Schemas, RAG & Tool Use. https://geol.ai/briefing/the-complete-guide-to-structured-data-for-llms
11. τ-bench (2024). A Benchmark for Tool-Agent-User Interaction in Real-World Domains. arXiv:2406.12045.
12. Lütke, T. (2025.06). Context engineering tweet. Shopify CEO.
13. Gartner (2025.07). Context Engineering is In, Prompt Engineering is Out.
14. Cognition AI (2025). Context Engineering as #1 Job for Agent Engineers.
15. Portkey (2025.07). Retries, Fallbacks, and Circuit Breakers in LLM Apps. https://portkey.ai/blog/
16. Martin-Short (2025). Systematic LLM Prompt Engineering Using DSPy. Towards Data Science.
17. Anthropic (2025). Claude Tool Use & Structured Output Documentation. https://docs.anthropic.com/
18. Anthropic (2026.02). Get the most from Claude Opus 4.6. https://claude.com/resources/tutorials/get-the-most-from-claude-opus-4-6