엘리트 빌더 훈련법: 프롬프트 이전의 훈련

토큰을 아끼는 사람은 절약가가 아니다

토큰을 적게 쓰는 능력은 짠돌이 습관이 아니다. 더 싼 모델을 쓰고, 답변 길이를 줄이고, 무료 요금제 안에서 버티는 기술도 아니다. 엘리트 빌더가 적은 토큰으로 높은 결과를 내는 이유는 프롬프트 이전에 이미 많은 판단을 끝냈기 때문이다.

여기서 핵심은 압축이다. 막연한 요구사항을 목표, 제약, 입력, 출력, 불변 조건, 테스트로 압축한다. 불안한 직감을 사용자 흐름, 데이터 흐름, 실패 흐름으로 압축한다. AI가 대신 추측해야 할 넓은 공간을 인간이 먼저 좁혀둔다.

반대로 토큰을 많이 쓰는 사람은 종종 사고를 압축하지 않은 채 실행으로 도망친다. "이거 만들어줘." "에러 나." "다시 고쳐줘." 이 세 문장만 반복하면 AI는 매번 새로운 임시 구조를 만든다. 겉으로는 전진하는 것 같지만 내부에서는 기술 부채가 자란다. 토큰 낭비는 비용 문제가 아니라 판단 공백의 증상이다.

엘리트 빌더의 훈련은 이 공백을 줄이는 훈련이다. 더 빨리 프롬프트를 쓰는 것이 아니라, 프롬프트를 쓰기 전 더 정확히 보는 훈련이다. 이 장에서 말하는 훈련법은 거창한 천재론이 아니다. AI에게 던질 한 문장을 쓰기 전에, 내가 무엇을 알고 있고 무엇을 아직 모르는지 분리하는 아주 현실적인 절차다.

AI 생성 이미지

6~19분 설계 리허설

스포츠 심상 훈련에서 중요한 것은 막연한 상상이 아니다. 실제 수행과 최대한 비슷한 조건을 머릿속에 재현하는 것이다. PETTLEP 모델은 심상 훈련이 신체 감각, 환경, 과제, 시간, 학습 수준, 감정, 관점을 함께 포함할 때 실제 수행에 더 가까운 형태가 된다고 설명한다¹. 이 원리를 소프트웨어 설계에 옮기면, 프롬프트 작성 전 짧은 설계 리허설이 된다.

다만 여기서 말하는 6~19분은 스포츠 과학이 정해준 절대 처방이 아니다. 빌더가 분석 마비에 빠지지 않으면서도 최소한의 흐름을 점검하기 위한 실전 타임박스다. 6분은 세 가지 흐름을 한 번씩 통과하기에 필요한 최소 단위에 가깝다. 19분은 더 생각한다는 핑계로 구현도 질문도 미루기 전에 멈추기 좋은 상한선이다. 이 시간 안에 코드 한 줄 한 줄을 상상하려고 애쓰지 말고, 시스템이 실제로 움직이는 장면을 통과해야 한다.

첫째, 사용자 흐름을 통과한다. 사용자가 어디서 들어오는가. 무엇을 보고, 어떤 버튼을 누르고, 어떤 실수를 하는가. 로그인하지 않은 사용자는 어디서 막히는가. 결제 실패 후 다시 시도하면 어떤 화면으로 돌아오는가. 여기서 중요한 것은 이상적인 성공 경로가 아니라 실제 사람이 망설이고, 오해하고, 되돌아가는 장면이다.

둘째, 데이터 흐름을 통과한다. 입력값은 어디서 생성되는가. 어떤 검증을 거치는가. 서버로 넘어갈 때 형태가 바뀌는가. 데이터베이스에는 무엇이 저장되고, 무엇은 저장되면 안 되는가. 캐시는 언제 갱신되고, 삭제는 어디까지 전파되는가. 데이터 흐름을 눈으로 따라가지 못하면 AI에게 구현을 맡겨도 나중에 책임 위치를 잃는다.

셋째, 실패 흐름을 통과한다. 네트워크가 끊기면 무엇이 보이는가. 중복 요청이 들어오면 같은 주문이 두 번 생기는가. 권한 없는 사용자가 URL을 직접 치면 어떤 응답이 나가는가. 외부 API가 느려지면 전체 화면이 멈추는가. 실패 흐름은 엘리트 빌더의 진짜 경기장이다. 성공 경로는 누구나 만든다. 시스템의 품질은 실패 경로에서 드러난다.

리허설 중 막히는 지점이 나오면 즉시 AI를 켜지 않는다. 그 빈칸을 기록한다. "결제 실패 후 상태 복구가 불명확함." "캐시 무효화 책임이 서버인지 클라이언트인지 미정." "중복 요청을 막는 기준이 없음." 이런 문장이 프롬프트의 재료다. 모르는 것을 모른 채 질문하는 사람과, 모르는 위치를 정확히 표시하고 질문하는 사람의 토큰 효율은 처음부터 다르다.

19분이 지나도 빈칸이 너무 많다면 더 오래 앉아 있는 것이 답이 아닐 수 있다. 그때는 작업 범위를 줄인다. "결제 전체"가 아니라 "결제 실패 후 상태 복구"로, "대시보드 전체"가 아니라 "필터 상태가 URL과 동기화되는 흐름"으로 줄인다. 엘리트 빌더는 오래 생각하는 사람이 아니라, 생각할 수 있는 크기로 문제를 자르는 사람이다.

프롬프트 이전의 여섯 칸

좋은 프롬프트는 문장력이 아니라 분해력에서 나온다. AI에게 말하기 전에 다음 여섯 칸을 채워야 한다.

• 목표: 이번 작업이 끝났을 때 무엇이 달라져야 하는가. "로그인 기능"이 아니라 "이메일 인증 사용자가 세션을 유지한 채 대시보드에 접근한다"처럼 결과 상태로 쓴다.

• 제약: 절대로 바꾸면 안 되는 기술 스택, 파일 구조, 디자인 토큰, API 계약, 보안 규칙은 무엇인가.

• 입력: AI가 참고해야 할 코드, 타입, 데이터 예시, 에러 로그, 사용자 시나리오는 무엇인가.

• 출력: 원하는 결과물은 코드 전체인가, 패치인가, 테스트 케이스인가, 설계 검토인가, 반례 목록인가.

• 불변 조건: 어떤 경우에도 유지되어야 하는 규칙은 무엇인가. 예를 들어 "결제 금액은 클라이언트 입력을 신뢰하지 않는다", "컴포넌트는 전역 상태를 직접 수정하지 않는다" 같은 조건이다.

• 테스트: 무엇을 통과해야 성공이라고 볼 것인가. 단위 테스트, 통합 테스트, 수동 확인 절차, 실패 케이스를 함께 둔다.

이 여섯 칸은 AI를 통제하기 위한 형식이 아니다. 인간의 생각을 정렬하는 장치다. 칸을 채우지 못했다면 아직 프롬프트가 이르다는 뜻이다. 특히 불변 조건과 테스트가 비어 있으면 AI는 가장 그럴듯한 길로 달려간다. 그 길은 빠를 수 있지만, 프로젝트의 장기 구조와 다를 수 있다.

예를 들어 "로그인 기능 만들어줘"라는 요청은 AI에게 너무 넓은 추측 공간을 준다. 반면 다음 요청은 훨씬 좁다.

목표: 이메일 인증을 마친 사용자만 대시보드에 접근하게 하라.
제약: 기존 세션 저장 방식과 라우터 구조는 바꾸지 말라. 새 인증 라이브러리는 추가하지 말라.
입력: 현재 auth middleware 코드와 protected route 예시를 참고하라.
출력: 변경이 필요한 함수 단위의 패치와 테스트 케이스만 제시하라.
불변 조건: 서버에서 인증 상태를 최종 판단해야 하며, 클라이언트 플래그를 신뢰하면 안 된다.
테스트: 미로그인 사용자, 이메일 미인증 사용자, 인증 완료 사용자, 만료된 세션 사용자를 각각 검증하라.

이 프롬프트는 겉으로는 길어 보이지만 실제로는 토큰을 아낀다. AI가 임의로 라이브러리를 고르고, 폴더 구조를 바꾸고, 정상 경로만 구현한 뒤 다시 수정 요청을 받는 비용을 미리 차단하기 때문이다.

엘리트 빌더는 AI에게 "전체를 알아서 만들어달라"고 하지 않는다. 그는 작은 경계 안에서 강하게 요청한다. "이 타입 계약을 유지한 채, 이 함수 내부만 바꾸고, 새 의존성은 추가하지 말고, 다음 세 실패 케이스를 통과하게 만들어라." 이런 프롬프트는 짧아 보여도 내부에는 긴 리허설이 압축되어 있다.

답변을 받은 뒤 바로 붙여넣지 않는다

AI의 답변이 나오면 손이 먼저 움직인다. 복사하고, 붙여넣고, 실행하고 싶어진다. 이 순간이 가장 위험하다. 빠른 출력은 판단을 마비시킨다. 바이브 코딩의 기술 부채는 대개 생성 순간이 아니라 채택 순간에 생긴다.

따라서 답변을 받은 뒤에는 짧은 냉각 시간이 필요하다. 거창한 의식이 아니다. 5분이면 충분한 경우도 많다. 이 시간 동안 세 가지를 본다.

첫째, 반례를 만든다. 이 코드가 실패할 수 있는 가장 현실적인 상황은 무엇인가. 빈 입력, 중복 요청, 느린 네트워크, 권한 없는 접근, 오래된 캐시, 잘못된 타입, 타임존 차이처럼 흔한 실패를 먼저 대입한다. AI가 낸 답이 정상 경로만 처리한다면 아직 완성물이 아니다.

둘째, 경계 조건을 검증한다. 이 변경이 맡은 책임을 넘어서지 않았는가. UI 컴포넌트가 비즈니스 규칙을 품고 있지는 않은가. 유틸 함수가 데이터베이스 구조를 알아버리지는 않았는가. 작은 편의를 위해 정보 은닉을 깨는 순간, 다음 수정 비용은 급격히 커진다.

셋째, 의존성을 추적한다. 새 패키지를 들여왔는가. 기존 타입을 우회했는가. 한 파일을 고치기 위해 네 파일이 따라 바뀌었는가. 수정당 영향 범위가 커졌다면 그것은 기능 추가가 아니라 결합도 증가일 수 있다.

이 냉각 시간은 속도를 늦추는 장치가 아니다. 재시도율과 롤백률을 낮추는 장치다. 한 번 붙여넣은 뒤 무너진 구조를 되돌리는 것보다, 붙여넣기 전에 5분 멈추는 편이 훨씬 빠르다.

채택 여부를 결정할 때는 한 문장만 물어도 좋다. "이 답변은 내 시스템의 경계를 더 선명하게 만드는가, 아니면 당장의 에러만 가린 채 경계를 흐리는가." 전자라면 붙여넣을 수 있다. 후자라면 다시 질문하기 전에 먼저 프롬프트 이전의 여섯 칸으로 돌아가야 한다.

독서와 명상은 낭만이 아니라 인프라다

엘리트 빌더에게 독서는 취미가 아니다. 장기 기억 속 구조 패턴을 늘리는 훈련이다. 좋은 코드베이스를 읽으면 책임이 어디서 끊기는지 배운다. 장애 회고를 읽으면 실패가 어떤 경로로 전파되는지 배운다. 프레임워크 문서를 읽으면 도구가 허용하는 경계와 금지하는 경계를 배운다.

AI 시대의 독서는 더 중요해졌다. AI는 이미 많은 문법과 예제를 알고 있다. 인간이 가져야 할 것은 더 많은 코드 조각이 아니라 더 좋은 판별 기준이다. 판별 기준은 무작정 프롬프트를 반복한다고 생기지 않는다. 좋은 구조를 오래 보고, 나쁜 구조가 무너지는 과정을 읽고, 그 차이를 자신의 언어로 설명해보는 과정에서 생긴다.

그러므로 읽기는 넓게 하되, 질문은 구체적으로 해야 한다. 이 모듈은 왜 여기서 책임을 끊었는가. 이 테스트는 어떤 실패를 미리 막고 있는가. 이 장애 회고에서 진짜 원인은 코드 한 줄인가, 아니면 소유권과 경계의 모호함인가. 이런 질문으로 읽을 때 독서는 프롬프트 품질을 올리는 훈련이 된다.

명상도 신비주의가 아니다. 프롬프트를 던지고 싶은 충동을 알아차리는 훈련이다. 도파민성 반복 프롬프팅은 불확실성을 견디지 못할 때 발생한다. 막히면 바로 묻고, 답이 오면 바로 실행하고, 다시 에러가 나면 다시 묻는다. 이 루프는 생산성처럼 보이지만 실제로는 주의력의 산만한 방전이다.

하루에 몇 분만 키보드에서 손을 떼고 문제를 바라보는 시간을 둔다. 지금 내가 모르는 것은 문법인가, 구조인가, 요구사항인가, 테스트 기준인가. 이 구분만 해도 프롬프트의 품질이 달라진다. 명상은 마음을 비우는 일이 아니라 문제의 층위를 분리하는 일에 가깝다.

무료 요금제는 약점이 아니라 훈련 장치가 될 수 있다

제한된 호출 횟수는 불평등한 조건이다. 이 현실을 낭만화해서는 안 된다. 고성능 모델에 더 자주 접근할 수 있는 사람은 학습과 실험에서 분명한 이점을 가진다. 접근권의 차이는 실제 차이다. 다만 제한이 항상 패배를 뜻하지는 않는다. 제한은 잘 설계하면 고정밀 사고 훈련 장치가 된다.

무료 요금제 사용자는 매 호출 전에 질문해야 한다. 이 한 번의 호출로 무엇을 얻어야 하는가. 설계 비판인가, 구현 패치인가, 테스트 케이스인가. 목표가 셋이면 호출을 쓰지 않는다. 하나로 줄인 뒤 쓴다.

세 번의 호출만 있다고 가정하면 루틴은 이렇게 짜는 편이 좋다. 첫 번째 호출은 구현이 아니라 설계 검토에 쓴다. "이 구조의 실패 가능성과 빠진 불변 조건을 지적하라." 두 번째 호출은 가장 작은 책임 단위의 구현에 쓴다. "이 함수 또는 이 컴포넌트만 수정하라." 세 번째 호출은 테스트와 반례에 쓴다. "내 변경이 깨뜨릴 수 있는 경계 조건을 찾아라."

이 방식은 느려 보이지만 실제로는 빠르다. 처음부터 전체 구현을 맡기면 두 번째 호출부터는 수습에 쓰인다. 설계 검토, 작은 구현, 반례 검증으로 나누면 호출이 누적될수록 내부 모델이 선명해진다. 토큰당 학습량이 남는다.

엘리트 빌더의 목표는 영원히 적은 토큰만 쓰는 것이 아니다. 대규모 리팩터링, 긴 코드베이스 검토, 보안 감사, 복잡한 마이그레이션처럼 많은 컨텍스트가 필요한 순간에는 큰 모델과 많은 토큰을 써야 한다. 중요한 차이는 그가 토큰을 쓰기 전에 이미 쓸 이유를 알고 있다는 점이다. 제한된 환경에서 훈련한 사람은 풍부한 환경에서도 낭비하지 않는다.

하루 훈련 루프

프롬프트 이전의 훈련은 거창한 커리큘럼이 아니다. 매일 반복할 수 있는 작은 루프면 충분하다.

1. 10분 읽기: 좋은 코드, 문서, 장애 회고, 테스트 파일 중 하나를 읽는다. 읽으면서 "책임이 어디서 끊기는가"를 본다.

2. 6~19분 리허설: 오늘 만들 기능의 사용자 흐름, 데이터 흐름, 실패 흐름을 눈감고 통과한다. 막히는 지점은 바로 적는다.

3. 여섯 칸 채우기: 목표, 제약, 입력, 출력, 불변 조건, 테스트를 쓴다. 비어 있는 칸이 있으면 질문 범위를 줄인다.

4. 한 번의 호출: AI에게 넓은 작업을 던지지 말고, 가장 작은 책임 단위 하나를 맡긴다.

5. 5분 냉각: 답변을 즉시 붙여넣지 않는다. 반례, 경계 조건, 의존성을 먼저 본다.

6. 토큰당 학습량 기록: 오늘 쓴 토큰이 무엇으로 남았는지 적는다. 사용자 가치인가, 구조 안정성인가, 내 판단의 개선인가.

이 루프를 반복하면 프롬프트는 짧아지지만 사고는 얇아지지 않는다. 오히려 더 조밀해진다. AI는 더 적게 추측하고, 더 정확히 실행한다. 빌더는 더 적게 흔들리고, 더 냉정하게 선택한다.

토큰 효율은 비용 절감의 언어로 시작하지만, 결국 훈련의 언어로 끝난다. 프롬프트 이전의 침묵을 견디는 사람만이 단 한 번의 호출에 자신의 판단을 압축할 수 있다.

참고

¹Paul S. Holmes and David J. Collins, "The PETTLEP Approach to Motor Imagery: A Functional Equivalence Model for Sport Psychologists," Journal of Applied Sport Psychology, 13(1), 2001, pp. 60–83. https://doi.org/10.1080/10413200109339004