제 지난 글에서 저는 SKILLmama에 Flow B를 추가했습니다. 인자(argument) 없이 /skillmama를 실행하면 프로젝트를 스캔하고, 역량 격차(capability gaps)를 찾아낸 뒤, 검색하기 전에 질문을 던집니다. 핵심은 AI가 사용자가 무엇을 필요로 하는지 추측하는 것을 방지하는 것이었습니다.

그 후 @alexshev님이 다음과 같은 댓글을 남겼습니다:

AI가 먼저 질문하게 만드는 것은 과소평가되어 있습니다. 왜냐하면 그것이 계약(contract)의 성격을 답변 생성(answer-generation)에서 모호성 감소(ambiguity-reduction)로 바꾸기 때문입니다. 제가 사용해 본 최고의 에이전트들은 코드에 손을 대기 전에 미지의 영역을 줄이는 데 약간의 시간을 할애합니다.

"답변 생성보다 모호성 감소(Ambiguity-reduction over answer-generation)." 이는 제가 스스로 생각해냈던 것보다 더 날카로운 개념 정의였습니다. 하지만 글을 다시 읽어보니, 그 댓글이 제 설계의 허점을 조용히 드러냈다는 사실을 깨달았습니다.

허점 (The Hole)

SKILLmama에는 두 가지 진입점(entry points)이 있습니다:

• Flow B — 인자 없이 /skillmama 실행 → 스캔 → 질문 → 검색
• Flow A — /skillmama find me a job queue 실행 → 스캔 → 검색

Flow B는 먼저 질문했습니다. Flow A는 그렇지 않았습니다.

사용자가 역량을 직접 명시하면, SKILLmama는 스택 컨텍스트(stack context)를 위해 프로젝트를 스캔한 뒤, 곧바로 검색 및 순위 매기기(ranking) 단계로 넘어갔습니다. 이는 파일에서 '볼 수 있는' 모호성은 줄여주었지만, '볼 수 없는' 모호성은 전혀 줄여주지 못했습니다: 예산, 라이선스, 셀프 호스팅(self-hosted) 대 호스팅(hosted), "이미 실행 중인 것과 호환되어야 함"과 같은 것들 말입니다.

따라서 개인 사이드 프로젝트에서 /skillmama find me a job queue라고 입력하면, 기술적으로는 가장 높은 점수를 받은 엔터프라이즈급의 인프라가 무거운 1순위 결과물을 기쁘게 반환할 것입니다. 이는 기술적으로는 최고 점수일지 몰라도, 질문한 사람에게는 실질적으로 틀린 답입니다. 댓글 작성자의 원칙은 Flow B에는 완벽하게 적용되었습니다. Flow A는 여전히 답변 생성(answer-generation) 모드에 머물러 있었습니다.

해결책: Phase 1.5

저는 Flow A에 한 단계를 추가했습니다: 제약 조건 확인 (Confirm Constraints).

Phase 0   — 요청 파싱 (parse the request)
Phase 1   — 프로젝트 스캔 (scan the project)
Phase 1.5 — 제약 조건이 명시되지 않은 경우: 정보에 기반한 질문을 '하나' 던지고 중단(STOP)  ← 신규 추가
...

핵심 단어는 '정보에 기반한(informed)'입니다. Phase 1이 이미 사용자의 스택을 스캔했기 때문에, 던지는 질문은 단순히 '제약 조건이 있나요?'라는 일반적인 것이 아니라, 방금 발견한 정보로부터 구축된 것입니다:

SKILLmama: Python / FastAPI / PostgreSQL / Docker / OpenAI를 사용하시는 것 같습니다. 
검색하기 전에 — 제약 조건이 있나요? (예: 자체 호스팅(self-hosted), 오픈 소스 전용, 무료 티어, PostgreSQL과 통합 필수). 'none'이라고 답하시면 필터 없이 검색합니다.

그리고 멈추고 기다립니다. 이 하드 스톱(hard stop)이 Flow B를 협업적으로 만드는 요소입니다.

짜증나지 않게 유지하는 세 가지 규칙

명확화 질문은 필요할 때만 작동해야 좋은 것입니다. 따라서 Phase 1.5에는 안전장치(guardrails)가 있습니다:

1. 제약 조건이 없을 때만 작동합니다. 만약 이미 '오픈 소스 작업 큐를 찾아줘'라고 말했다면, 제약 조건은 테이블 위에 놓여 있는 것이므로 — 질문을 건너뛰고 즉시 검색합니다. 귀찮게 하지 않습니다.

2. 우아하게 저하됩니다(degrades gracefully). 스캔할 프로젝트 파일이 없을 경우(빈 폴더, 새 리포지토리), '사용하시는 것은 [없음]'이라는 깨진 문장을 출력하지 않습니다. 대신 일반적인 제약 조건 질문으로 대체합니다.

3. 한 번만 질문합니다. 재프롬프팅 루프가 없습니다. 하나의 질문과 사용자의 답변(또는 'none')을 받은 후 실행됩니다.

왜 '하나의 정보 기반 질문'이 '양식(Form)'보다 나은가

Flow B가 하는 것처럼 같은 세 가지 질문을 Flow A에 시킬 수도 있었습니다. 하지만 저는 의도적으로 그렇게 하지 않았습니다.

Flow B는 개방형 발견(open-ended discovery)을 수행하기 때문에 세 가지 질문을 할 자격이 있습니다. 몇 가지 격차와 필요성을 발견했고, 어떤 것이 중요한지, 사용자의 제약 조건은 무엇인지, 그리고 놓친 부분이 무엇인지 알아야 하기 때문입니다. Flow A는 이미 능력을 알고 있습니다. 남아 있는 유일한 실제 미지수는 '제약 조건'뿐입니다. 그 이상을 묻는 것은 자체적인 마찰(friction)이 될 뿐입니다.

댓글 작성자가 설명한 계약 — 코드를 건드리기 전에 미지수를 줄여라 — 는

Phase 1.5가 네 가지 어댑터(adapters) — Claude Code, Claude.ai, OpenAI Codex, Antigravity — 전체에 v1.4.0 버전으로 적용되었습니다. 이제 두 진입점(entry points) 모두 동작하기 전에 모호함(ambiguity)을 줄입니다. 즉, 이미 알고 있는 정보의 양에 맞춰 적절한 수의 질문을 던집니다.

npx skills add Magithar/SKILLmama

github.com/Magithar/SKILLmama — Apache 2.0.

만약 질문하는 대신 여전히 추측(guess)하는 부분에 대해 날카로운 관찰 결과가 있다면 댓글을 남겨주세요. 지난번 댓글은 실제 릴리스(release)로 이어졌습니다.