나는 계속해서 모델을 탓했다.

GPT-5가 잘못된 것을 만들었다면, 내 프롬프트가 약하다고 가정했다.
Claude Opus 4.6이 엣지 케이스 (edge case)를 놓쳤다면, 더 많은 제약 조건을 추가했다.
OpenClaw 워크플로 (workflow)가 어긋난다면, 시스템 메시지 (system message)를 다시 작성했다.

프롬프트는 길어졌다.
출력 비용은 더 비싸졌다.
제품은 여전히 잘못되어 있었다.

내 생각을 완전히 바꾼 것은, 에이전트가 내가 절대 출시하지 않을 법한, 지극히 합리적으로 보이는 관리자 대시보드 (admin dashboard)를 구축하는 것을 지켜보았을 때였다.

나는 다음과 같은 것들을 요청했다:

• 간단한 내부 대시보드
• 사용자 관리
• CSV 가져오기
• 역할 기반 액세스 권한 (role-based access)

코드는 좋아 보였다. 컴포넌트 (components)는 렌더링되었고, 테스트 (tests)는 대부분 통과했다.

하지만 제품 결정 (product decisions)은 터무니없었다:

• 관리자가 모든 필드를 편집할 수 있음
• 잘못된 형식의 CSV 행이 조용히 건너뛰어짐
• 역할 변경에 승인 프로세스 (approval flow)가 없음
• 정지된 사용자가 여전히 검색 결과에 나타남
• 모바일 동작이 기본적으로 정의되지 않음
• 민감한 변경 사항에 대한 감사 추적 (audit trail)이 없음

이 중 그 어떤 것도 코딩의 실패가 아니었다.

에이전트는 내가 내리지 않은 제품 결정을 내렸다.

그 순간, 나는 해결책이 더 똑똑한 코딩 프롬프트라는 믿음을 버렸다.

진짜 문제: 구현 에이전트들이 제품 디자인을 강요받고 있다

더 나은 OpenClaw 워크플로를 파헤치던 중, r/openclaw의 한 스레드에서 누군가가 거의 한 번에 빌드 계획을 만들어낼 수 있는 가장 진보된 "나를 심문하라 (grill me)" 기술을 요청하는 것을 발견했다.

그 프레임워크 (framing)는 정확하다.

대부분의 형편없는 코딩 에이전트 출력물은 코딩을 못 하는 것이 아니다.
그것은 해결되지 않은 제품의 모호함 (product ambiguity)이 모델에 의해 조용히 채워지고 있는 것이다.

만약 당신이 에이전트에게 다음과 같이 말한다면:

사용자 초대 기능을 만들어줘

에이전트는 다음과 같은 질문들에 대한 답을 스스로 지어내야 한다:

• 초대가 만료되는가?
• 워크스페이스 (workspaces) 전체에서 이메일이 고유해야 하는가?
• 초대된 사용자가 수락하기 전에 역할을 할당할 수 있는가?
• 링크를 모바일에서 열면 어떻게 되는가?
• 초대가 취소되면 감사 로그 (audit log)에 남는가?

당신이 이 질문들에 답하지 않는다면, GPT-5, Claude, Grok, 혹은 당신이 사용하는 어떤 에이전트 스택 (agent stack)이라도 당신 대신 그 질문들에 답할 것이다.

그것이 바로 수많은 AI 생성 코드들이 데모(demo)에서는 인상적으로 보이지만, 실제 운영 환경(production)에서는 고통스러운 이유입니다.

더 큰 프롬프트는 과대평가되어 있다

저는 지금 AI 코딩 분야에서 "그저 더 나은 프롬프트를 작성하라"는 말이 최악의 조언 중 하나라고 생각합니다.

거대한 프롬프트는 두 가지 작업을 동시에 수행하려고 시도합니다:

1. 무엇을 구축해야 하는지 파악하기
2. 그것을 구축하기

이것은 잘못된 분할입니다.

당신의 요구사항을 심문해야 할 바로 그 에이전트(agent)는 보통 다음 단계로 넘어가 파일을 생성하기 시작하고 싶어 안달이 나 있습니다.
그는 두 개의 얕은 확인 질문(clarifying questions)을 던지고, 부분적인 답변을 얻으면, 가짜 자신감을 가지고 구현(implementation) 단계로 돌진해 버립니다.

그보다 더 효과적인 방법은 훨씬 덜 화려합니다:

• 에이전트 1: 인터뷰어 (interviewer)
• 에이전트 2: 플래너/코더 (planner/coder)
• 에이전트 3: 리뷰어 (reviewer)

업무를 분리하십시오.

실제로 도움이 되었던 워크플로우 (workflow)

이것이 제가 현재 신뢰하는 코딩 에이전트 오케스트레이션 (orchestration) 패턴입니다:

1. 먼저 인터뷰어 에이전트 (interviewer agent)를 실행합니다.
2. 위험한 모호함이 사라질 때까지 계속해서 질문하도록 강제합니다.
3. 답변들을 명세서 산출물 (spec artifact)로 변환합니다.
4. 그 명세서를 코딩 에이전트 (coding agent)에게 전달합니다.
5. 리뷰어 에이전트 (reviewer agent)가 명세서에 따라 구현되었는지 확인하게 합니다.

그게 전부입니다.

마법 같은 것은 없습니다. 그저 운영상 합리적일 뿐입니다.

인터뷰어 에이전트가 실제로 물어야 할 것들

이 부분은 사람들이 보통 대충 넘어가곤 하는 부분입니다.

"확인 질문을 던지세요"라는 말은 듣기 좋지만, 질문이 날카롭지 않으면 그저 대화만 길어질 뿐 결과물은 똑같이 나쁩니다.

유용한 인터뷰어 에이전트는 다음과 같은 영역을 파고들어야 합니다:

• 인증 (auth) 및 세션 동작
• 권한 (permissions) 및 역할 경계 (role boundaries)
• 임포트/엑스포트 (import/export) 규칙
• 재시도 (retries) 및 백오프 (backoff)
• 빈 상태 (empty states) 및 에러 상태 (error states)
• 모바일 제약 사항 (mobile constraints)
• 감사 가능성 (auditability) 및 승인 (approvals)
• 실패 모드 (failure modes) 및 롤백 (rollback) 동작

예를 들어:

인증 (Auth)

• 정지된 사용자가 기존 세션을 갱신할 수 있습니까?
• 매직 링크 (magic links)는 첫 사용 후 만료됩니까, 아니면 특정 시간 범위 후에 만료됩니까?
• 한 워크스페이스 (workspace)에 SSO가 활성화되어 있다면, 다른 워크스페이스에서는 어떤 일이 발생합니까?

임포트 (Imports)

• CSV 헤더가 엄격한가요, 아니면 유연한가요?
• XLSX 파일도 허용하나요?
• 부분적인 실패 (partial failure)가 발생하면 어떻게 되나요?
• 중복된 행은 병합되나요, 거부되나요, 아니면 두 번 임포트되나요?

권한 (Permissions)

• 지원 팀 (support staff)이 사용자를 사칭 (impersonate)할 수 있나요?
• 관리자는 내보내기 (export)는 가능하지만 삭제는 불가능한가요?
• 어떤 작업에 감사 로그 (audit logs)가 필요한가요?
• 어떤 작업에 승인 (approval)이 필요한가요?

신뢰성 (Reliability)

• 어떤 실패 상황에서 자동으로 재시도 (retry)해야 하나요?
• 지수 백오프 (Exponential backoff)를 사용할까요, 아니면 고정 지연 (fixed delay)을 사용할까요?
• 언제 사람에게 페이지 (page)를 보내야 하나요?
• 무엇을 사용자 오류 (user error)로 보고, 무엇을 상위 시스템 장애 (upstream outage)로 간주하나요?

이것은 과잉 대응이 아닙니다.
이것이 바로 명세 (spec)입니다.

인터뷰어 에이전트를 위한 실용적인 프롬프트

다음은 제가 실제로 사용할, 군더더기를 뺀 인터뷰어 역할의 버전입니다.

당신은 코딩 워크플로 (coding workflow)를 위한 요구사항 인터뷰어입니다.

당신의 역할은 아직 코드를 제안하는 것이 아닙니다.
...

이것만으로도 코딩 모델에 긴 문단을 던져놓고 결과가 좋기를 바라는 것보다 훨씬 낫습니다.

예시: 모호한 요청 vs 심문된 요청

문제를 일으키는 입력의 유형은 다음과 같습니다:

사용자 관리, CSV 임포트, 역할 기반 액세스 (role-based access) 기능이 있는 내부 대시보드를 구축해줘.

명확하게 들립니다.
하지만 명확하지 않습니다.

적절한 인터뷰어 단계를 거친 후에는 다음과 같은 모습이어야 합니다:

feature: internal admin dashboard
users:
  - super_admin
...

이제 코딩 에이전트 (coding agent)가 작업할 수 있는 실제 데이터가 생겼습니다.

자동화 워크플로에서는 이것이 훨씬 더 중요합니다

이것은 코딩 에이전트만의 문제가 아닙니다.

저는 n8n, Make, Zapier에서도 동일한 실패 패턴을 목격합니다.

에이전트는 기술적으로는 실행되지만, 여전히 끔찍한 가정을 내포한 워크플로를 생성할 수 있습니다:

• 불안정한 API (flaky APIs)에 대한 재시도 정책 (retry policy) 부재
• 데드 레터 경로 (dead-letter path) 부재
• 멱등성 키 (idempotency key) 부재
• 사용자 오류와 제공업체 장애 (provider outage) 간의 구분 부재
• 빈 필드나 잘못된 형식의 페이로드 (malformed payloads)에 대한 처리 부재

이 워크플로는 현실과 맞닥뜨리기 전까지는 "작동"합니다.

자연어를 통해 자동화를 생성하고 있다면, 인터뷰어 우선 오케스트레이션 (interviewer-first orchestration)은 더욱 중요합니다. 워크플로 버그는 운영 환경의 트래픽이 유입될 때까지 숨어 있는 경향이 있기 때문입니다.

가격 책정이 팀의 에이전트 워크플로 설계를 바꾸는 이유

이 부분은 사람들이 그냥 지나치기 쉽지만, 매우 중요합니다.

토큰당 과금 (per-token billing) 방식 하에서는, 팀들이 인터뷰어 에이전트 (interviewer agent)가 제 역할을 다하도록 하는 것을 이상할 정도로 주저하게 됩니다.

추가적인 확인 단계(clarification round) 하나하나가 모두 비용으로 느껴지기 때문입니다.
그래서 사람들은 질문 단계를 짧게 줄여버리고, 나중에 재작업 (rework)을 통해 그 대가를 치릅니다.

이는 끔찍한 인센티브 구조를 만듭니다:

• 질문을 줄여 비용을 절감함
• 재작성 (rewrites)에 시간을 낭비함
• 피할 수 있었던 실수를 수정하느라 더 많은 토큰을 소모함

만약 n8n, Make, Zapier, OpenClaw, 또는 커스텀 OpenAI 호환 스택 (OpenAI-compatible stack)에서 에이전트를 지속적으로 실행한다면, 컴퓨팅 비용 (compute)이 예측 가능할 때 인터뷰어 우선 (interviewer-first) 워크플로를 정당화하기가 훨씬 쉬워집니다.

이것이 바로 Standard Compute가 이러한 방식의 오케스트레이션 (orchestration)에 흥미로운 이유 중 하나입니다.
Standard Compute는 고정된 월간 가격을 제공하는 OpenAI API의 드롭인 교체재 (drop-in replacement)이므로, 에이전트가 코딩을 시작하기 전에 더 많은 질문을 던지도록 허용할 여유가 생깁니다.

토큰에 대한 불안감 (token anxiety)을 중심으로 모든 워크플로를 최적화하는 대신, 더 나은 사양 (specs)과 더 적은 재구축 (rebuilds)을 목표로 최적화할 수 있습니다.

이미 사용 중인 스택이 OpenAI API를 지원한다면, 교체는 간단합니다.

export OPENAI_BASE_URL="https://api.standardcompute.com/v1"
export OPENAI_API_KEY="your_standard_compute_key"

또는 JavaScript에서:

import OpenAI from "openai";

const client = new OpenAI({
...

이는 워크플로가 "하나의 프롬프트, 하나의 응답"이 아니라 다음과 같을 때 매우 중요합니다:

• 인터뷰 (interview)
• 정교화 (refine)
• 사양 생성 (spec generation)
• 구현 (implementation)
• 리뷰 (review)
• 재시도 (retry)
• 패치 (patch)

토큰 과금 방식 하에서 이러한 루프 (loop)는 비용이 빠르게 상승합니다.

깔끔한 멀티 에이전트 레이아웃 (multi-agent layout)

만약 제가 이것을 실제 파이프라인 (pipeline)에 연결한다면, 다음과 같이 구성할 것입니다:

사용자 요청 (User request)
  -> 인터뷰어 에이전트 (Interviewer agent)
  -> 사양 생성기 (Spec generator)
...

또는 의사 코드 (pseudo-code)로:

const request = getUserRequest();

const interview = await interviewer.run(request);
...

핵심은 코더 (coder)가 모호한 문단을 받는 것이 아니라, 사양 (spec)을 받는다는 점입니다.

인터뷰어는 언제 멈춰야 하는가?

대화가 길게 느껴질 때가 아닙니다.

해결되지 않은 결정 사항들이 더 이상 위험하지 않을 때 멈추어야 합니다.

저에게 있어, 이는 보통 다음과 같은 사항들이 명확해졌음을 의미합니다:

• 사용자 역할 (user roles) 및 권한 경계 (permission boundaries)
• 해피 패스 (happy path) 및 실패 경로 (failure path)
• 가져오기/내보내기 (import/export) 동작
• 재시도 (retry) 및 타임아웃 (timeout) 정책
• 빈 상태 (empty states) 및 에러 상태 (error states)
• 장치 제약 사항 (device constraints)
• 감사 (audit) 및 승인 (approval) 요구 사항

아주 작은 스크립트라면 이 과정은 5분 정도 걸릴 수 있습니다.
하지만 인증 (auth), 가져오기 (imports), 알림 (notifications), 관리자 제어 (admin controls)가 포함된 실제 기능을 구현하는 경우라면, 네, 한 시간 가까이 걸릴 수도 있습니다.

그 한 시간은 보통 "거의 맞지만 틀린" 코드를 다섯 번 수정하는 것보다 비용이 적게 듭니다.

인터뷰(interviewing)와 코딩(coding)을 분리한 후 바뀐 점

코드는 마법 같은 느낌은 줄어들었지만, 훨씬 더 유용해졌습니다.

제가 목격한 변화는 다음과 같습니다:

• 재작성 (rewrites) 횟수 감소
• 숨겨진 가정 (hidden assumptions) 감소
• 계획 (planning)과 구현 (implementation) 사이의 더 깔끔한 인수인계 (handoffs)
• 더 나은 리뷰 결과
• "PR에서는 괜찮아 보였는데, 운영 환경(production)에서 실패하는" 순간의 감소

가장 큰 변화는 정신적인 측면이었습니다.

저는 에이전트가 파일을 얼마나 빨리 생성하는지로 판단하는 것을 멈췄습니다.
대신 에이전트가 모호함 (ambiguity)을 얼마나 공격적으로 드러내는지를 기준으로 판단하기 시작했습니다.

그것이 더 나은 지표임이 밝혀졌습니다.

나의 견해

미래는 아마도 하나의 거대한 천재적인 프롬프트 (prompt) 형태는 아닐 것입니다.

그보다는 좁은 직무와 더 엄격한 인수인계 (handoffs)를 가진 여러 개의 특화된 에이전트 (specialized agents)들의 형태가 될 것입니다.

모델 선택 (Model choice)은 여전히 중요합니다.
어떤 리포지토리 (repo)에는 GPT-5가 가장 적합할 수 있습니다.
또 다른 곳에는 Claude Opus 4.6이 더 나을 수 있습니다.
Grok 4.20은 다른 생성 스타일 (generation style)에 맞을 수도 있습니다.
OpenClaw는 이 모든 것을 하나로 묶는 오케스트레이션 레이어 (orchestration layer)가 될 수도 있습니다.

하지만 요구 사항 (requirements)이 흐리멍덩하다면, 모델 선택은 진짜 문제보다 하위 단계의 문제입니다.

진정한 업그레이드는 에이전트가 코딩할 권리를 얻기 전에, 속도를 늦추고 나를 심문 (interrogate)하게 만든 것이었습니다.

만약 여러분이 지금 에이전트 워크플로우 (agent workflows)를 구축하고 있다면, 다음을 꼭 한 번 시도해 보시길 강력히 권장합니다:

• 코딩 프롬프트 (coding prompt)는 작게 유지하세요.
• 모호함 찾기 (ambiguity-hunting)를 별도의 인터뷰어 에이전트 (interviewer agent)로 옮기세요.
• 출력물을 구조화된 사양 (structured spec)으로 만드세요.
• 오직 그 후에만 코딩 에이전트 (coding agent)가 리포지토리 (repo)를 건드리게 하세요.

이 변화는 그 어떤 "궁극의 코딩 프롬프트"보다 저에게 더 큰 도움이 되었습니다.