AI에게 '일단 만들어줘'라고 하지 마라 — brainstorming 스킬

버그 나기 전에 갈리는 승부

지난 글에서 systematic-debugging 스킬을 다뤘다. 버그가 난 다음에 찍지 말고 조사부터 하라는 스킬이었다. 그런데 버그의 절반은 버그가 나기 전에, 그러니까 코드를 짜기도 전에 이미 정해진다.

AI 페어 프로그래밍에서 내가 망친 패턴 1번이 "다 알아서 해줘"였다. 큰 작업을 한 줄로 던지면 AI는 진짜로 코드를 다 만든다. 파일 수십 개가 5분 만에 들어찬다. 그리고 1주일 뒤에 안다. 방향이 틀렸다는 걸. 5분짜리 결과물이 1주일을 낭비한 출발점이 된다.

이걸 막아주는 게 brainstorming 스킬이다. systematic-debugging이 "버그 난 뒤"의 스킬이라면, 이건 "코드 짜기 전"의 스킬이다.

스킬이 강제하는 단 하나의 문(gate)

systematic-debugging에 Iron Law가 있었듯, brainstorming에는 HARD-GATE가 있다. 스킬 문서 상단에 이렇게 박혀 있다.

설계를 제시하고 사용자가 승인하기 전까지는
어떤 코드도 짜지 말고, 프로젝트를 스캐폴딩하지 말고,
구현 스킬을 호출하지 마라. 프로젝트가 아무리 간단해 보여도.

핵심은 마지막 문장이다. 아무리 간단해 보여도. 스킬은 "이건 너무 간단해서 설계가 필요 없어"를 대표 안티패턴으로 규정한다. 투두 리스트, 함수 하나짜리 유틸, 설정 변경 — 전부 이 과정을 거친다. 이유가 좋다.

"간단한" 프로젝트야말로 검토되지 않은 가정이 가장 많은 낭비를 만드는 곳이다.

설계는 짧아도 된다. 정말 간단하면 몇 문장이면 된다. 하지만 제시하고 승인받는 것은 건너뛸 수 없다. 이게 문의 전부다.

프로세스

HARD-GATE 다음은 대화의 흐름이다.

여기서 눈여겨볼 지점이 몇 개 있다.

한 번에 한 질문

스킬의 핵심 원칙 중 하나가 이거다. 한 메시지에 질문 하나. 여러 개를 쏟아붓지 않는다. 한 주제가 더 파고들 게 있으면, 그걸 또 여러 질문으로 쪼갠다. 그리고 가능하면 객관식으로 묻는다. 열린 질문보다 답하기 쉬우니까.

나는 처음에 이게 답답했다. "그냥 궁금한 거 한꺼번에 물어봐"라고 생각했다. 그런데 한 번에 한 질문을 받으면 내가 생각할 시간이 생긴다. 다섯 개를 한꺼번에 받으면 첫 번째만 대충 답하고 나머지는 흘려보낸다. 하나씩 받으면 각 결정을 실제로 한다. 그게 설계의 질을 바꾼다.

2-3 접근법 + 추천

질문이 끝나면 스킬은 곧장 답을 내놓지 않는다. 2-3개의 다른 접근법을 트레이드오프와 함께 제시한다. 그리고 추천안을 먼저 말하고 이유를 설명한다. 이게 중요하다. 선택지 없이 하나만 던지면, 나는 그게 최선인지 판단할 근거가 없다. 세 개를 비교하면 왜 그걸 골랐는지가 보인다.

승인은 섹션마다

설계는 통으로 던지지 않는다. 아키텍처, 컴포넌트, 데이터 흐름, 에러 처리, 테스트를 복잡한 만큼 나눠서 제시하고, 섹션마다 "여기까지 맞나?"를 묻는다. 통으로 승인받으면 틀린 부분을 늦게 발견한다. 나눠 받으면 첫 섹션에서 방향을 튼다.

코드부터 vs 설계부터

같은 요청을 두 방식으로 처리하면 이렇게 갈린다.

"느려 보이지만"이 핵심이다. 질문 몇 개 주고받는 5분이 아까워서 건너뛰면, 잘못된 방향으로 간 1주일이 기다린다. systematic-debugging의 "체계적인 게 느린 게 아니라 헤매는 게 느린 것"과 정확히 같은 구조다.

Claude Code에서 어떻게 발동하나

스킬은 두 가지로 켜진다. 세션에서 /brainstorm을 직접 부르거나, 기능·컴포넌트를 만들어달라고 하면 스킬이 알아서 로드된다. 스킬의 트리거는 "기능 생성, 컴포넌트 구축, 동작 변경 등 창의적 작업 전"이다. 이 트리거가 왜 이렇게 쓰이는지, 명령어·서브에이전트와 뭐가 다른지는 서브에이전트 vs 스킬 vs 커맨드 글에서 다뤘다.

Plan Mode와 헷갈리기 쉬운데, 역할이 다르다. brainstorming은 뭘 만들지를 정하고, 그 다음 writing-plans가 어떻게 만들지를 짠다. Plan Mode는 그 계획을 실행 전에 검토하는 안전장치에 가깝다. 셋을 순서로 보면 이렇다. brainstorming(무엇) → writing-plans(어떻게) → 구현. 이 흐름이 Superpowers 워크플로우의 앞단이다.

실제로 뭐가 달라졌나

가장 크게 바뀐 건 "코드 시키기 전에 멈추는 습관"이다. 예전엔 아이디어가 떠오르면 바로 "만들어줘"였다. 지금은 스킬이 먼저 질문을 던지니, 내가 그 질문에 답하다가 스스로 설계 구멍을 발견한다. AI가 나 대신 설계해주는 게 아니라, 나에게 설계를 시키는 도구다.

부작용도 있다. 정말 사소한 걸 할 때도 스킬이 질문을 던지면 귀찮다. 그럴 땐 "설계는 한 줄이면 된다"고 말해주면 스킬이 짧게 끝낸다. 스킬 자신도 "간단하면 몇 문장"이라고 허용한다. 문을 없애는 게 아니라 문을 빠르게 통과하는 거다.

또 하나. brainstorming과 systematic-debugging은 결국 같은 말을 한다. 찍지 말고 먼저 이해하라. 하나는 만들기 전에, 하나는 고치기 전에. 두 스킬을 같이 쓰면 개발의 앞뒤가 다 잡힌다.

직접 겪은 일: 게이트가 실제로 걸렸을 때

이 스킬의 값은 막히는 순간에 나온다. 그래서 막혔던 이야기를 적는다.

목록 페이지에서 태그를 주소로 읽게 만들고 싶었다. 방법이 바로 떠올랐고 «이렇게 해줘»라고 하면 될 일이었다. 실제로 그렇게 시켰고, 코드가 나왔고, 잘 돌아 보였다.

그 방법이 서버가 내보내는 HTML을 비우는 방식이라는 걸 배포한 뒤에 알았다. 되돌리고 다시 만들 때는 접근법을 두 개 놓고 시작했다 — 서버에서 읽는 방법과 브라우저에서 읽는 방법. 그러자 첫 번째 방법이 왜 안 되는지가 짜기 전에 나왔다. 이 사이트가 올라가는 곳에는 파일을 읽을 수 있는 서버가 없다는 사실이 거기서 걸렸다.

같은 정보를 처음에도 알 수 있었다. 다만 하나의 방법만 놓고 있으면 그 방법이 되는 이유만 찾게 된다. 두 개를 놓아야 비교할 축이 생기고, 축이 생겨야 제약이 보인다.

승인 전에 구현을 막는 규칙이 답답한 건 사실이다. 그런데 답답함의 정체는 대개 아직 안 정한 것을 정하기 싫은 마음이었다.

정리

brainstorming은 코드를 대신 짜주는 스킬이 아니다. 오히려 코드를 못 짜게 막는 스킬이다. 승인 전엔 한 줄도 안 짠다. 그 제약이 잘못된 방향을 5분에서 끊는다.

세 줄로 요약하면 이렇다.

1. HARD-GATE — 설계 제시하고 승인받기 전엔 구현 없다
2. 한 번에 한 질문 — 내가 각 결정을 실제로 하게 만든다
3. 2-3 접근법 — 비교해야 왜 그걸 골랐는지 안다

예전 글에서 "코드 시키기는 가장 비싼 의사결정"이라고 썼다. brainstorming은 그 비싼 결정 앞에 문을 하나 세운다. "일단 만들어줘" 대신 "먼저 뭘 만들지 같이 정하자"라고 한 문장만 바꾸면, 이 스킬이 켜진다.