큰 작업을 위한 AI 지시문 설계 — 상담에서 실행까지

큰 작업을 CLI 에이전트에 바로 요청하는 대신, 채팅 앱에서 먼저 상담을 받아 지시문을 다듬고 그 결과물을 CLI에 넘기는 방식에 대한 이론적 정리.

발견: 같은 모델인데 결과가 다르다

같은 모델에 같은 작업을 요청해도 결과의 품질이 달라지는 경험을 했다.

방식 A: CLI 에이전트에 머릿속 요구사항을 즉석에서 풀어서 길게 요청한다.
방식 B: 채팅 앱에서 먼저 “이런 걸 하고 싶은데”라고 상담하고, 대화로 요구사항을 다듬은 뒤, 완성된 지시문을 받아 CLI에 붙여넣는다.

방식 B의 결과가 더 일관적이었다. 모델의 성능은 같은데 왜 차이가 생겼을까. 결론부터 말하면 모델보다 입력 방식의 차이가 컸고, 여기에는 구조적인 이유가 있다.

전제: 지시문의 구체성이 에이전트의 품질을 좌우한다

에이전트형 AI는 지시문의 빈틈을 스스로 메운다. 이는 편리함을 제공하지만 결과의 불확실성을 높이기도 한다.

즉석에서 작성한 큰 지시에는 빈틈이 생기기 쉽다. 목표는 있지만 완료 조건이 없고, 해야 할 일은 있지만 하지 말아야 할 일은 빠져 있으며, 머릿속의 전제가 글로 표현되지 않기도 한다. 에이전트는 이 빈틈을 그럴듯한 가정으로 채운다. 작업이 클수록 가정이 누적되고, 일부는 의도와 어긋날 가능성이 커진다.

문제는 이 어긋남이 실행이 상당히 진행된 뒤에야 드러날 수 있다는 것이다. 이때 방향을 바로잡는 비용은 처음부터 요구사항을 명확히 하는 비용보다 커진다.

왜 CLI 직행이 불리한가 — 세 가지 구조적 이유

1. 실행 공간은 생각하는 곳이 아니다

CLI 에이전트는 행동 지향적이다. 지시를 받으면 곧장 파일을 열고, 탐색하고, 계획을 세우고, 수정을 시작한다. 이 특성은 실행에는 적합하지만 요구사항이 충분히 정리되지 않은 상태에서는 오히려 제약이 된다. 요청자의 의도가 아직 구체화되지 않았는데도 에이전트는 실행을 시작하기 때문이다.

반면 채팅 앱은 구조적으로 대화 지향적이다. 도구도 코드베이스도 없으니 할 수 있는 게 되묻고, 정리하고, 대안을 제시하는 것뿐이다. 이 “실행할 수 없음”이 오히려 요구사항 정제 단계에서는 장점이 된다. 같은 모델이라도 놓인 환경이 행동 성향을 결정한다.

2. 방향 전환의 비용이 비대칭이다

채팅에서 의도를 정정하는 비용은 매우 낮다. 아직 텍스트만 오간 상태이기 때문이다.

실행 중인 에이전트의 방향을 바꾸는 비용은 더 크다. 이미 수정된 파일과 잘못된 전제 위에 만들어진 추상화가 남고, 컨텍스트에도 이전 판단이 누적된다. 되돌리고 다시 설명하고 실행하는 과정에서 세션의 복잡성이 높아진다. 불확실성은 방향 전환 비용이 낮은 채팅에서 먼저 줄이고, 실행 공간에는 충분히 정리된 내용을 전달하는 편이 좋다.

3. 컨텍스트의 첫인상이 세션의 질을 정한다

CLI 직행 방식에서 세션의 출발점은 내 두서없는 요구사항이다. 말하다가 덧붙이고, 번복하고, “아 그리고 이것도”가 이어진다. 에이전트는 이 뒤엉킨 서사 전체를 컨텍스트로 안고 출발하며, 번복 전의 요구와 번복 후의 요구를 계속 함께 들고 다닌다.

상담 방식에서 세션의 출발점은 정제된 지시문 하나다. 목표·범위·제약·완료 조건이 밀도 높게 압축된 문서. 같은 정보량이라도 정돈된 형태로 시작한 세션과 뒤엉킨 형태로 시작한 세션은 이후의 모든 판단에서 차이가 난다.

상담 단계에서 실제로 일어나는 일

채팅 앱에서의 상담은 단순히 “프롬프트를 예쁘게 다듬는” 게 아니다. 세 가지 실질적인 변환이 일어난다.

① 암묵지의 구체화. 좋은 상담자는 되묻는다. “이 기능의 사용자는 누구인가?”, “실패하면 어떻게 처리해야 하는가?”, “기존 기능과의 호환성은 필요한가?”. 이 질문들에 답하는 과정에서 머릿속에만 있고 지시문에는 없던 전제들이 글로 정리된다. 에이전트가 가정으로 메웠을 빈틈을 상담 단계에서 답변으로 미리 채우는 것이다.

② 주요 결정의 사전 처리. 큰 작업에는 여러 갈림길이 있다. 방식 A와 B 중 무엇을 선택할지, 이번 범위에 무엇을 포함할지 등을 정해야 한다. CLI에 바로 요청하면 에이전트가 실행 중에 갈림길을 만나 임의로 선택하거나 작업을 멈추고 질문한다. 상담 단계에서는 이러한 선택지가 실행 전에 드러나고, 결정권자가 미리 판단할 수 있다. 트레이드오프 검토를 실행 흐름 밖에서 마친 상태가 되는 것이다.

③ 비목표(non-goals)의 명문화. 즉석 지시에는 해야 할 일만 있고 하지 않을 일은 빠지는 경우가 많다. 요청하지 않은 리팩터링이나 구조 변경은 이런 빈틈에서 발생한다. 상담에서 제외하기로 한 항목을 지시문의 비목표로 명시하면 실행 범위를 양쪽 경계에서 분명히 할 수 있다.

결과물: 좋은 지시문의 형태

상담의 산출물은 대략 이런 구조로 수렴한다.

## 목표
무엇을 왜 만드는가. 한 문단.

## 배경 / 전제
상담에서 인출된 암묵지. 사용자, 상황, 기존 구조에 대한 전제.

## 요구사항
해야 할 일의 목록. 갈림길마다 상담에서 내린 결정이 반영된 상태.

## 비목표
이번에 하지 않는 것. 범위의 바깥 경계.

## 완료 조건
"됐다"를 판정할 수 있는 구체적 기준.

## 열린 질문
상담에서도 못 정한 것. 에이전트가 코드를 보고 판단하되, 판단 근거를 보고할 것.

주목할 점: 이건 소프트웨어 공학이 수십 년 다듬어 온 요구사항 명세서의 축소판이다. 새로운 발명이 아니라, 사람 팀에서 검증된 문서 형태가 사람–AI 협업에 그대로 이식된 것이다.

한 단계 위의 같은 패턴

이 워크플로는 Advisor/Worker 역할 분리와 같은 구조를 가진다.

	Advisor/Worker (세션 안)	상담 → 실행 (세션 밖)
판단 담당	Advisor (메인 세션)	나 + 채팅 앱 상담
실행 담당	Worker (서브에이전트)	CLI 에이전트
인터페이스	작업 브리프	정제된 지시문
핵심 원리	판단과 노동의 컨텍스트 분리	정제와 실행의 공간 분리

두 패턴 모두 같은 통찰에 기댄다. 충분히 정리되지 않은 상태에서 실행을 시작하면, 실행 주체가 사람이든 AI든 결과의 일관성이 낮아질 수 있다. Advisor가 Worker에게 브리프를 전달하듯, 나도 CLI에 큰 작업을 요청하기 전에 지시문을 준비한다. 다듬어진 지시문은 결국 “내가 나의 Worker(CLI)에게 주는 브리프”다.

층위를 겹쳐 보면 이런 그림이 된다:

나 ──(상담)── 채팅 앱        ← 요구사항 정제 층
 │
 │  지시문 (= 나의 브리프)
 ▼
CLI Advisor                  ← 작업 분해·검증 층
 │
 │  작업 브리프
 ▼
Worker × N                   ← 구현 층

각 층의 산출물이 다음 층의 입력이 되고, 각 층은 자기 층의 판단만 책임진다. 위층의 정제 품질이 아래층 전체의 상한선을 정한다.

상담 단계에서 주의할 점

이 방식에도 주의할 점이 있다. 채팅 앱은 코드베이스를 보지 못한다는 한계가 있기 때문이다.

구현 세부 사항은 지시문에서 확정하지 않는다. 코드를 보지 못한 상담자가 함수 구현 방식까지 정하면 실제 코드베이스와 맞지 않는 구체성이 생길 수 있다. 에이전트는 모호한 부분은 탐색으로 해결할 수 있지만, 명시된 지시는 부정확해도 따르려는 경향이 있다. 지시문은 요구사항 층위에 머물고, 구현 결정은 코드를 볼 수 있는 CLI에 맡긴다. “열린 질문” 항목이 그 위임 장치다.
상담의 종료 조건을 정한다. 요구사항 정제에도 수확 체감이 있다. 주요 갈림길이 드러나고 완료 조건이 작성됐다면 실행을 시작할 수 있다. 그 이상의 정리는 실제 실행에서 얻을 피드백을 미리 추측하는 일이 될 수 있다.
작은 작업에는 간소화한다. 오타 수정처럼 단순한 작업에는 별도의 명세가 필요하지 않다. 이 워크플로의 효용은 “에이전트가 채워야 할 빈틈의 수”에 비례한다. 빈틈이 적다면 바로 실행하고, 많다면 상담을 거치는 방식으로 조절할 수 있다.

정리

	CLI 직행	상담 → 지시문 → CLI
요구사항의 빈틈	에이전트가 가정으로 메움	상담 질문에 대한 내 답으로 미리 메움
갈림길 결정	실행 중 에이전트가 임의 선택	실행 전 내가 선불 결정
방향 전환 비용	높음 (기존 수정·이전 판단이 남은 컨텍스트)	낮음 (텍스트 수정)
세션 출발 컨텍스트	두서없는 서사	밀도 높은 명세
범위 통제	”할 일”만 존재	비목표로 바깥 경계까지 명시

핵심은 한 문장이다. 에이전트의 실행력이 좋아질수록, 병목은 실행이 아니라 지시의 품질로 이동한다. 실행이 싸지면 정제가 비싸지는 게 아니라, 정제의 가치가 올라간다. 그리고 정제는 실행할 수 없는 공간 — 되묻는 것밖에 할 수 없는 대화창 — 에서 가장 잘 된다.

같은 모델을 두 번 사용하는 것이 비효율적으로 보일 수 있다. 하지만 한 번은 상담자로, 한 번은 실행자로 활용하는 것은 하나의 모델에 서로 다른 역할을 부여하는 것이다. 이 과정에 드는 비용은 어긋난 가정 위에서 상당 부분 진행된 작업을 되돌리는 비용보다 대체로 낮다.