엘리트 빌더는 AI를 켜기 전에 이미 절반을 끝낸다

프롬프트는 시작점이 아니라 마지막 압축물이다

바이브 코더는 AI를 켜는 순간부터 생각을 시작한다. 엘리트 빌더는 다르다. 그는 AI를 켜기 전에 이미 문제의 모양을 줄이고, 위험한 경로를 제거하고, 모델이 건드릴 수 있는 영역과 건드리면 안 되는 영역을 나눈다. 그래서 그의 프롬프트는 길어서 강한 것이 아니다. 이미 많은 판단을 통과했기 때문에 강하다.

이 차이는 모델 등급의 차이만으로 설명되지 않는다. 더 비싼 모델을 쓰면 더 나은 답이 나올 가능성은 커진다. 그러나 문제 자체가 흐릿하면 고성능 모델도 흐릿한 해결책을 낸다. 반대로 문제가 좁고, 책임이 선명하고, 실패 기준이 명확하면 평범한 모델도 꽤 정확한 산출물을 낸다.

엘리트 빌더의 핵심은 AI에게 "좋은 앱을 만들어줘"라고 말하지 않는 데 있다. 그는 먼저 앱을 기능 덩어리가 아니라 책임의 배열로 본다. 무엇이 사용자 입력을 받는가. 무엇이 상태를 보관하는가. 무엇이 외부 API와 통신하는가. 무엇이 실패를 감지하는가. 무엇이 절대 바뀌면 안 되는 규칙인가. 이 질문을 거친 뒤에야 AI는 막연한 작업자가 아니라 정밀 가공기계가 된다.

AI 생성 이미지

선분해: 깊이 들어가기 전에 넓게 펼친다

초보자는 한 기능을 잡고 곧장 구현으로 파고든다. 로그인 화면을 만들다가 인증 로직을 붙이고, 그다음 데이터베이스 테이블을 바꾸고, 다시 UI를 고친다. 겉으로는 빠르다. 그러나 이 방식은 깊이 우선의 함정에 빠지기 쉽다. 한 구멍을 깊게 파는 동안 전체 지형을 잃어버린다.

엘리트 빌더는 먼저 넓게 펼친다. 이것이 Breadth-first Problem Decomposition이다. 전체 문제를 한 번에 해결하려 하지 않고, 먼저 책임 단위와 의존성 그래프를 만든다. 여기서 의존성 그래프란 어떤 모듈이 어떤 모듈에 기대어 작동하는지 그린 관계도다. 복잡한 그림일 필요는 없다. 중요한 것은 "무엇이 무엇을 알아야 하는가"를 드러내는 것이다.

예를 들어 결제 기능을 만든다고 하자. 바이브 코더는 "결제 기능 구현해줘"라고 말한다. 엘리트 빌더는 먼저 문제를 나눈다.

• 가격 계산은 주문 도메인의 책임이다.

• 결제 승인 요청은 결제 어댑터의 책임이다.

• 결제 성공 후 권한 부여는 구독 서비스의 책임이다.

• 실패 로그와 재시도 정책은 인프라 계층의 책임이다.

• 사용자가 보는 문구와 버튼 상태는 UI 계층의 책임이다.

이렇게 나누면 AI에게 줄 작업이 달라진다. "결제 기능"이라는 안개가 "결제 승인 결과를 받아 구독 상태를 갱신하는 순수 함수"로 좁아진다. 모델은 더 이상 전체 시스템을 상상해서 제멋대로 채울 필요가 없다. 이미 잘린 조각 안에서만 움직이면 된다.

선분해의 목적은 완벽한 설계도를 만드는 것이 아니다. AI가 잘못 추측해야 하는 면적을 줄이는 것이다. 모델은 빈칸을 싫어하지 않는다. 오히려 빈칸을 보면 그럴듯한 가정으로 채운다. 엘리트 빌더는 그 가정의 자유도를 줄인다. 이것이 토큰 절약보다 더 중요한 인지 절약이다.

다만 선분해는 폭포수식 설계를 다시 부활시키자는 말이 아니다. 처음부터 모든 것을 확정하려 들면 오히려 손이 굳는다. 엘리트 빌더가 원하는 것은 거대한 문서가 아니라, 지금 AI에게 넘길 수 있을 만큼 충분히 작고 안전한 작업 단위다. 넓게 펼친 뒤에는 다시 작게 자른다. 이 리듬이 중요하다.

정보 은닉: AI에게 모든 것을 보여주지 않는다

많은 사용자는 더 많은 컨텍스트를 넣으면 더 좋은 결과가 나온다고 믿는다. 전체 코드베이스를 붙여넣고, 모든 요구사항을 넣고, 이전 대화까지 밀어 넣는다. 물론 필요한 맥락은 충분히 줘야 한다. 문제는 정제되지 않은 긴 컨텍스트다. 긴 컨텍스트는 그 자체로 기억이 아니라 노출이다. 필요 없는 정보까지 노출하면 모델은 중요도 판단을 다시 해야 한다. 그 과정에서 엉뚱한 파일을 고치거나, 이미 안정된 구조를 흔들 수 있다.

정보 은닉은 시스템을 숨기는 기술이 아니다. 변경의 충격을 가두는 기술이다. 어떤 모듈은 외부에 자신의 내부 구조를 보여주지 않아야 한다. 외부는 오직 계약만 알아야 한다. 계약은 입력, 출력, 에러, 불변 조건이다. 내부 구현은 바뀔 수 있지만 계약은 쉽게 바뀌면 안 된다.

AI 빌딩에서도 같은 원리가 적용된다. 엘리트 빌더는 모델에게 전체를 맡기지 않는다. 대신 다음 두 영역을 나눈다.

첫째, AI가 수정해도 되는 영역이다. 새 컴포넌트, 고립된 유틸 함수, 테스트 파일, 문서화, 특정 어댑터처럼 경계가 분명한 부분이 여기에 속한다. 이 영역은 실패해도 되돌리기 쉽다.

둘째, AI가 절대 임의로 바꾸면 안 되는 영역이다. 데이터베이스 스키마, 인증 흐름, 결제 상태 전이, 공통 디자인 토큰, API 응답 형식, 배포 설정처럼 시스템의 뼈대가 되는 부분이다. 이 영역을 모델이 즉흥적으로 수정하기 시작하면 기술 부채는 폭발적으로 늘어난다.

따라서 좋은 프롬프트는 "무엇을 해라"만 말하지 않는다. "무엇을 하지 마라"를 함께 말한다. 파일을 새로 만들 수 있는지, 기존 함수를 바꿀 수 있는지, 공개 인터페이스를 수정해도 되는지, 임시 상태를 추가해도 되는지까지 제한한다. 제한은 창의성을 죽이는 것이 아니다. 창의성이 기술 부채로 새는 구멍을 막는 것이다.

예를 들어 같은 요청이라도 결과는 완전히 달라진다.

나쁜 요청: 결제 성공 후 구독 상태 갱신 기능 만들어줘.

좋은 요청: subscriptionService.updateAfterPayment() 내부만 수정하라. DB 스키마와 API 응답 형식은 변경하지 마라. 입력은 paymentId, userId, planId이며, 결제 상태가 APPROVED일 때만 구독을 활성화하라. 중복 요청이 들어와도 같은 구독이 두 번 생성되면 안 된다. 기존 테스트는 모두 통과해야 한다.

두 문장은 모두 결제 기능을 말한다. 그러나 첫 번째 문장은 모델에게 시스템 전체를 상상하게 만든다. 두 번째 문장은 모델을 좁은 가공 범위 안에 세운다. 엘리트 빌더의 프롬프트가 강한 이유는 바로 이 차이에 있다.

설계 헌법: 모델보다 먼저 규칙을 세운다

엘리트 빌더는 매번 AI와 협상하지 않는다. 먼저 설계 헌법을 세운다. 헌법은 프로젝트 안에서 반복적으로 지켜야 하는 상위 규칙이다. 기능 하나를 만들 때마다 새로 정하면 늦다. 모델은 세션마다 다른 취향을 가질 수 있다. 어제는 한 방식으로 상태를 관리하고, 오늘은 다른 방식으로 컴포넌트를 쪼갤 수 있다. 이 변덕을 막는 것이 설계 헌법이다.

설계 헌법에는 네 가지가 들어간다.

첫째, Design Tokens다. 색상, 간격, 폰트 크기, 그림자, 반응형 기준처럼 UI의 원자 규칙이다. "예쁘게 만들어줘"는 위험하다. 모델은 매번 새로운 파란색, 새로운 여백, 새로운 버튼 스타일을 만든다. 반면 "정의된 토큰만 사용하라"고 말하면 시각적 드리프트가 줄어든다.

둘째, API 계약이다. 요청 형식, 응답 형식, 에러 코드, 인증 방식, 페이지네이션 규칙을 명확히 둔다. 계약이 있으면 프론트엔드와 백엔드가 서로의 내부를 몰라도 협력할 수 있다. 계약이 없으면 AI는 한쪽에서 만든 임시 구조를 다른 쪽에서 또 다른 임시 구조로 해석한다.

셋째, 인프라 격리 규칙이다. 비즈니스 로직이 특정 클라우드 SDK나 데이터베이스 호출에 직접 달라붙지 않게 해야 한다. 외부 서비스는 어댑터 뒤에 둔다. 이렇게 해야 나중에 결제사, 메일 서비스, 저장소를 바꿀 때 전체 시스템을 다시 뜯지 않는다.

넷째, 데이터 불변 조건이다. 예를 들어 "결제 완료 상태의 주문은 가격을 바꿀 수 없다", "삭제된 사용자는 로그인할 수 없다", "무료 체험은 계정당 한 번만 가능하다" 같은 규칙이다. 이것은 단순한 검증 로직이 아니라 시스템의 윤리와 물리 법칙이다. AI는 이런 규칙을 모르면 그럴듯한 코드로 세계의 법칙을 깨뜨린다.

설계 헌법은 길 필요가 없다. 오히려 짧고 반복 가능해야 한다. 중요한 것은 AI가 매번 새 세계를 만들지 못하게 하는 것이다. 모델은 조수지만, 세계관의 주인은 빌더다.

실제로는 프로젝트 최상단에 짧은 문장으로 남겨두는 것만으로도 효과가 있다. "색상은 토큰만 사용한다", "도메인 계층은 외부 SDK를 직접 호출하지 않는다", "공개 API 계약은 별도 지시 없이 변경하지 않는다", "결제와 인증의 상태 전이는 테스트 없이 수정하지 않는다." 이런 문장들은 거창해 보이지 않는다. 그러나 AI가 세션마다 시스템을 흔드는 일을 막아주는 작은 울타리가 된다.

단발 검증: 한 번에 맞히려면 실패 기준이 먼저 있어야 한다

Single-shot Validation은 한 번의 프롬프트로 완벽한 결과를 얻겠다는 허세가 아니다. 한 번의 요청 안에 성공 조건과 실패 판정 기준을 충분히 넣어 재작업의 방향을 줄이는 방식이다. 단발 검증은 출력이 아니라 입력에서 시작된다.

엘리트 빌더의 입력 명세에는 보통 네 가지가 포함된다.

먼저 작업 범위가 있다. 어떤 파일을 만들고, 어떤 파일은 건드리지 않을지 정한다. 다음으로 입력과 출력이 있다. 함수라면 인자와 반환값, UI라면 상태와 이벤트, API라면 요청과 응답을 쓴다. 셋째, 테스트 조건이 있다. 정상 케이스뿐 아니라 빈 값, 권한 없음, 네트워크 실패, 중복 요청 같은 예외를 포함한다. 넷째, 실패 판정 기준이 있다. 타입 오류가 없어야 한다, 기존 테스트를 깨면 안 된다, 공개 인터페이스를 바꾸면 안 된다, 디자인 토큰 밖의 값을 쓰면 안 된다 같은 규칙이다.

이렇게 쓰면 프롬프트는 명령문이 아니라 작업 계약서가 된다. AI는 더 이상 추측으로 공간을 채우지 않는다. 주어진 계약 안에서 구현을 제안한다. 결과가 틀렸을 때도 대화가 빨라진다. "마음에 안 들어"가 아니라 "세 번째 불변 조건을 위반했다"라고 말할 수 있기 때문이다.

작업 계약서는 다음처럼 단순해도 충분하다.

• 목표: 결제 승인 후 구독 상태를 활성화한다.

• 범위: subscriptionService와 해당 테스트 파일만 수정한다.

• 입력: paymentId, userId, planId.

• 출력: 활성화된 구독 객체 또는 명확한 에러.

• 불변 조건: 같은 결제는 한 번만 반영된다. 결제 실패 상태에서는 구독을 만들지 않는다.

• 금지 사항: DB 스키마, 공개 API 응답 형식, 디자인 토큰은 변경하지 않는다.

• 검증: 정상 승인, 중복 승인, 실패 결제, 존재하지 않는 사용자 케이스를 테스트한다.

이 정도만 있어도 모델의 행동 반경은 크게 줄어든다. 프롬프트가 길어져서가 아니다. 판단해야 할 축이 정리되었기 때문이다. AI는 "무엇이든 가능한 공간"보다 "정확히 잘린 공간"에서 훨씬 안정적으로 움직인다.

단발 검증의 핵심은 검증을 나중으로 미루지 않는 데 있다. 많은 사람은 코드를 받은 뒤에야 테스트를 생각한다. 엘리트 빌더는 반대로 한다. 테스트 가능한 형태가 아니면 아직 AI에게 넘기지 않는다. 이 태도 하나가 토큰 낭비의 상당 부분을 잘라낸다.

정밀 가공기계로서의 AI

AI를 코딩 노예로 다루면 사용자는 감독자가 아니라 의존자가 된다. 노예에게 일을 던지듯 "알아서 해줘"라고 말하면, 산출물은 많아지지만 판단력은 줄어든다. 코드가 늘어날수록 빌더는 자신의 시스템을 덜 이해하게 된다. 이것이 이해 부채의 시작이다.

AI를 정밀 가공기계로 다루면 태도가 바뀐다. 가공기계는 아무 재료나 넣는다고 명품을 만들지 않는다. 도면, 치수, 허용 오차, 재료의 성질이 필요하다. 엘리트 빌더는 이 조건을 준비한다. AI에게 넘기는 것은 막연한 소망이 아니라 이미 절단된 부품이다.

물론 이 방식에도 위험은 있다. 너무 오래 분해하고, 너무 오래 설계하고, 한 줄도 만들지 못하는 분석 마비에 빠질 수 있다. 그래서 엘리트 빌더의 사전 사고는 무한하지 않다. 충분히 나누고, 핵심 경계를 세우고, 실패 기준을 정했다면 작은 단위로 실행한다. 제로 토큰 엔진은 실행을 피하는 핑계가 아니라 실행의 정확도를 높이는 장치다.

AI를 켜기 전 마지막으로 물어야 할 질문은 단순하다. 이 작업은 하나의 책임으로 잘렸는가. 모델이 바꾸면 안 되는 영역이 명확한가. 지켜야 할 설계 헌법이 있는가. 성공과 실패를 판정할 테스트가 있는가. 이 네 질문에 답하지 못한 프롬프트는 아직 준비되지 않았다.

엘리트 빌더는 토큰을 아끼는 사람이 아니다. 그는 토큰이 닿기 전에 문제를 날카롭게 만드는 사람이다. 그래서 같은 모델을 써도 다른 결과를 얻는다. 차이는 도구의 가격이 아니라, 도구 앞에 놓인 사고의 밀도에서 발생한다.