Grill

grill

사용자는 명세를 길게 쓰고 싶어하지 않는다. 짧은 요청 뒤에 있는 의도·설계 방향은 Claude가 캐물어서 끌어낸다.

"모호하면 멈추고 물어본다"는 수동 방어가 아니다. 명확해 보여도 먼저 캐묻는다는 능동 인터뷰다. 요청이 한 문장으로 깔끔할수록 그 안에 접힌 결정이 많다.

언제 여나

연다 — 없던 것을 새로 만드는 요청:

• 기능·화면·API·스크립트·스킬·플러그인
• 문서·계획서·템플릿·지침
• "하는 거 만들어줘", " 넣고 싶어", "~ 하면 좋겠는데" 같은 아이디어 단계의 한 문장

열지 않는다:

• 조회·읽기·조사("이 파일 뭐하는 거야", "어디에 있어")
• 명세가 이미 확정된 수정(버그 수정, 지정된 파일 편집, 리뷰 지적 반영)
• 사용자가 이미 상세 명세·계획서를 준 경우 — 그때는 그 명세의 빈칸만 짚는다
• 사용자가 "그냥 해", "묻지 말고"라고 말한 경우 → 즉시 닫고 진행한다

경계가 애매하면 연다. 질문 하나 붙는 비용보다 방향을 틀리게 잡는 비용이 크다.

어떻게 묻나

핵심 하나에 집중하고, 나머지는 목록으로 보여준다.

한 번에 결정 하나만 묻는다. 판단이 가장 크게 갈리는 것 — 답에 따라 만들 물건 자체가 달라지는 것 — 을 골라 그것만 질문 도구로 던진다. 나머지 확신 없는 지점은 같은 응답에 목록으로 함께 보여준다.

1. 핵심 질문 (한 번에 하나)

가장 판단이 갈리는 갈림길 하나를 골라 구조화 질문 도구로 묻는다. 여러 사안을 한꺼번에 펼치면 사용자가 무엇부터 답해야 할지 고르는 일까지 떠맡는다.

선택지는 그것만 읽고 고를 수 있게 쓴다. 사용자는 방금 내가 읽은 코드·검토 결과를 보지 않았다는 전제로 작성한다:

• 이걸 고르면 무엇을 하게 되는지(동작)
• 무엇을 얻고 무엇을 잃는지(트레이드오프)
• 판단에 필요한 구체 수치·근거

라벨과 한 줄 요약만 던지면 "설명이 부족해 판단 못 하겠다"로 되돌아오고, 그 왕복이 곧 낭비다. 세션 안에서만 통하는 항목 번호·내부 약어를 질문의 뼈대로 쓰지 않는다 — 풀어 쓴 문장으로 만든다.

권장안이 있으면 첫 번째에 두고 라벨에 "(권장)"을 붙이되, 권장하는 이유를 설명에 담는다.

2. 나머지 불확실 목록 (같은 응답에)

핵심 외에 확신이 안 서는 지점을 전부 목록으로 낸다. 각 항목에 잠정 판단과 그 근거를 붙인다:

그 밖에 확신이 안 서는 지점 (잠정 판단대로 가면 이렇게 됩니다):
- 이름: `grill` — 짧고 사용자가 쓴 표현 그대로라 기억하기 쉬움
- 종료 후: 합의 요약 3줄 남기고 바로 구현 — 규모가 크면 draft-plan으로 넘김
- 실패 시: 3번 물어도 방향이 안 잡히면 가정을 명시하고 진행

사용자는 신경 쓰이는 것만 골라 답하고 나머지는 넘어갈 수 있다. 언급하지 않은 항목은 잠정 판단대로 진행하고, 무엇을 그렇게 정했는지 밝힌다.

3. 다음 라운드

답을 받으면 그 답이 열어젖힌 다음 갈림길을 같은 방식으로 묻는다. 상한은 두지 않되, 더 물어도 만들 물건이 안 바뀌는 지점에서 닫는다.

무엇을 캐묻나

질문 소재는 아래에서 뽑는다. 전부 묻지 말고, 답이 아직 안 정해진 것만 고른다.

기존 자산은 특히 먼저 본다. 새로 짓기 전에 이미 있는 것을 재사용할 수 있는지, 표준 라이브러리나 이미 깔린 의존성으로 되는지 확인하면 만들 물건 자체가 사라지는 경우가 있다.

초안은 가장 좁은 동작 범위로 시작한다. 추가 플랫폼·자동 기본값·부가 기능은 임의로 넓히지 말고 "이것도 포함할까요?"로 사용자에게 넘긴다. 넓게 시작하면 덜어내는 재작업이 생긴다.

닫을 때

인터뷰를 닫으면 합의된 것을 짧게 요약하고 바로 구현으로 넘어간다. 요약에는 넣는다:

• 확정된 결정(사용자가 고른 것)
• 잠정 판단대로 간 것(사용자가 언급 안 한 항목)
• 남은 가정

규모가 커서 구현 순서·리스크까지 적어야 하면 draft-plan으로 넘긴다.