4장: 셰이핑은 여전히 사람의 일

원작은 셰이핑(shaping)을 마친 아이디어가 갖춰야 할 상태를 세 낱말로 정리했습니다. 거칠고(rough), 해결되어 있고(solved), 경계가 있는(bounded) 상태입니다 (2장: 셰이핑의 원칙). 세부를 확정하지 않아 만드는 쪽이 채워 넣을 여지가 있고, 핵심 요소와 그 연결이 이미 정해져 방향을 잃지 않으며, 무엇을 하지 않을지가 함께 못 박혀 있다는 뜻입니다.

이 세 낱말은 원래 사람에게 건네는 말이었습니다. 그런데 만드는 쪽이 사람에서 에이전트로 바뀌자 같은 세 낱말이 오히려 더 정확한 말이 되었습니다.

스펙 우선의 재발견

바이브 코딩이 남긴 실패 모드에 업계가 내놓은 답은 스펙 우선(spec-driven development)이었습니다. 명세를 1차 산출물로 두고 코드는 거기서 다시 만들어 낼 수 있는 출력물로 취급하자는 접근으로, 원형은 2024년 11월 AWS의 AI-DLC에 이미 있었습니다 (AI-DLC의 스펙 우선 구현). 2025년에는 GitHub이 Spec Kit을 공개하며 명세·계획·작업·구현을 순서가 있는 단계로 못 박았고 (GitHub 블로그), AWS는 같은 해 7월 Kiro를 내놓으며 요구사항을 EARS 문법으로 쓰게 했습니다. 2026년에는 주요 코딩 도구가 저마다 이 구조를 탑재했습니다.

이 흐름은 Shape Up을 아는 눈으로 보면 낯설지 않습니다. 무엇을 만들지 먼저 고정하고, 그 문서를 근거로 구현을 통째로 넘기고, 넘긴 다음에는 세부에 개입하지 않는다는 구조가 그대로입니다. 피치(pitch)를 써서 팀에 맡기는 일과 명세를 써서 에이전트에 맡기는 일은 같은 모양입니다.

도착한 자리는 같은데 출발한 이유는 달랐습니다. Shape Up은 6주 안에 확실히 출시하려고, 스펙 우선은 에이전트가 엉뚱한 것을 만들어 놓는 사고를 막으려고 이 구조를 택했습니다. 다른 문제를 풀다 같은 답에 닿았다는 것은 이 구조가 도구가 아니라 원리에 가깝다는 방증입니다.

피치는 그대로 브리핑 문서가 된다

원작이 정한 피치의 다섯 구성 요소는 문제, 애피타이트(appetite), 해결책, 래빗 홀(rabbit hole), 제외 항목(No-gos)입니다 (6장: 피치 작성하기). 이 목록을 지금 다시 읽으면 에이전트에게 일을 맡길 때 채워야 할 항목과 구별되지 않습니다. 새 서식을 만들 필요가 없습니다. 이미 있습니다. 다만 뒤의 두 항목은 의미가 크게 달라집니다.

래빗 홀은 원래 셰이퍼가 미리 찾아내 메워 두는 리스크였습니다 (5장: 리스크와 래빗 홀). 사람 팀에게는 "여기 빠지면 사이클을 날린다"는 경고로 충분했습니다. 사람은 막다른 길에 들어서면 대체로 스스로 멈추고 물어보러 오지만, 에이전트는 멈추지 않고 근거가 부족한 자리에서도 그럴듯한 답을 계속 만들어 냅니다. 그래서 VDLC의 피치 서식은 이 항목을 다시 씁니다. 래빗 홀은 에이전트가 스스로 판단하지 말고 사람에게 에스컬레이션해야 하는 구간의 명시적 선언입니다.

제외 항목의 지위 변화는 더 큽니다. 사람 팀에게 제외 항목은 있으면 좋은 안전장치였습니다. 적어 두지 않아도 대개는 만들지 않았기 때문입니다. 에이전트에게는 그 "대개"가 없습니다. 에이전트는 금지를 명시하지 않으면 반드시 하므로 이것이 피치에서 가장 중요한 재료이고 최소 세 개 이상 적어야 한다는 것이 VDLC가 이 항목에 붙인 주석입니다. 다섯 번째로 적히던 것이 첫 번째로 올라온 셈입니다.

추상화 수준은 여전히 '적당히'

에이전트가 빈칸을 임의로 채워 사고를 낸다면 아예 빈칸을 남기지 말고 더 자세히 쓰면 되지 않겠느냐는 생각이 자연스럽게 듭니다. 실제로는 반대 방향으로 갑니다. 와이어프레임 수준까지 그려 놓은 명세는 에이전트가 더 나은 방법을 찾을 여지를 미리 닫아 버립니다. 굵은 마커 스케치(fat marker sketch)로 의도만 남기라는 원작의 조언은 세부를 채우는 쪽이 빨라진 만큼 오히려 더 유효합니다.

VDLC는 이 감각을 의도 해상도라는 원칙으로 정식화하면서 원작의 세 낱말을 그대로 가져다 씁니다. 와이어프레임은 너무 구체적이라 에이전트의 탐색을 죽이고 한 줄 요구사항은 너무 추상적이라 에이전트가 임의로 채우니, 어포던스와 연결만 정의하는 브레드보딩이 가장 알맞은 해상도라는 것입니다. 그리고 피치를 사람을 설득하는 문서에서 에이전트가 직접 소비하는 실행 가능한 1차 산출물로 승격시킵니다 (VDLC 주간 사이클). 다만 이 원칙은 구조와 로직에 적용되고 UI와 룩앤필은 예외입니다. 취향은 에이전트가 탐색할 대상이 아니라 사람이 확정할 대상이기 때문입니다.

셰이핑하는 방식 자체도 달라집니다. 원작이 스케치와 글로 해결책을 다듬은 것은 만들어 보는 비용이 논의하는 비용보다 컸기 때문입니다. 바이브 코딩은 이 부등호를 뒤집었고, 그래서 VDLC의 셰이핑은 문서 작업이 아니라 프로토타입 라운드를 내장한 실험 활동이 됩니다. 방향이 맞는지 확인해야 할 때는 하나를 만들어 써 보고 고치기를 반복하는 수렴형 라운드를, 말로 설명하기 어려운 취향을 판정해야 할 때는 같은 문제에 프로토타입 두세 개에서 다섯 개를 나란히 만들어 놓고 고르는 발산형 라운드를 돌립니다. 프로토타입은 결정을 위한 도구일 뿐이라 승자까지 포함해 프로덕션으로 올리지 않고, 확정된 의도만 피치로 옮겨 빌드 사이클에서 다시 만듭니다.

발산형 라운드에서 사람이 하는 일은 만드는 것이 아니라 고르는 것, 곧 큐레이션입니다. 몇 개까지 늘어놓을 수 있느냐를 정하는 것도 컴퓨트가 아니라 사람이 실제로 비교하고 판정할 수 있는 주의력, 곧 3장에서 예산으로 잡았던 그 자원입니다.

그러니 1장에서 인용한 Karpathy의 문장 — 에이전트는 인턴 같은 존재이고 미감과 판단, 취향과 감독은 여전히 사람이 쥐고 있어야 한다는 말 (Sequoia Ascent 2026) — 은 코드 리뷰에 대한 조언보다 셰이핑에 대한 서술로 읽을 때 더 정확합니다. 무엇을 만들지 좁히고, 어디서 멈춰야 하는지 적고, 여럿 중에 하나를 고르는 일. 자동화되지 않고 남는 것은 이 일입니다.

프로토타입으로 판단을 앞당기고 피치가 곧바로 실행 가능한 입력이 된다면, 그 피치를 받아 만드는 기간이 6주여야 할 이유는 남아 있을까요. 3부의 첫 장에서 사이클을 다시 재겠습니다.