단 하나의 질문으로 끝내는 디자인 문서: 기능 범위가 폭주하는 걸 막는 작은 계획 트릭

어느 팀에나 이런 이야기가 하나쯤은 있다.

단순한 기능 요청이 “이것만 하나 더”로 변한다.
스펙은 커지고, 목업은 복잡해지고, 엣지 케이스는 기하급수적으로 늘어난다.
몇 달이 지나면 팀은 지치고 일정은 박살 나고, 원래 풀려고 했던 문제는 알아보기 힘들어져 있다.

이게 바로 기능 비대화(feature creep)다. 좋은 제품을 조용히 망가뜨리는 주범이다.

좋은 소식이 있다. 겉보기엔 너무 작아 보이는 도구 하나만 있어도 이걸 꽤 효과적으로 막을 수 있다. 바로 **‘단일 질문 디자인 문서(single-question design doc)’**다.

이건 새로운 산출물도 아니고, 무거운 템플릿도 아니고, 회의 하나 더 늘리는 프로세스도 아니다. 지금 쓰고 있는 디자인 문서나 기능 명세 위에 살짝 얹어 쓰는 작은 계획 트릭이다. 이 문서의 핵심은 단 하나, 이런 급진적인 명료함을 강제하는 데 있다.

“이 기능이 성공했다고 말하려면, 반드시 답해야 하는 단 하나의 질문은 무엇인가?”

이 질문을 제대로 잡으면 범위에 가드레일이 생긴다. 이 질문을 흐리게 잡거나 아예 생략하면, 기능은 거의 확실하게 통제 불능 상태로 번져 나간다.

디자인 문서 vs 기능 스펙: 같은 문제, 다른 각도

단일 질문 패턴을 이야기하기 전에, 자주 뒤섞여 쓰이는 두 가지 문서를 먼저 분리해서 생각해 보자.

1. 디자인 문서 (엔지니어)

엔지니어가 주로 쓰는 디자인 문서는 다른 엔지니어와 자기 자신을 위한 문서다.

무엇을 어떻게 만들지에 집중한다: 아키텍처, 트레이드오프, 데이터 플로우, 장애 시나리오 등.
보통 정적인 스냅샷에 가깝다: 설계 시점의 시스템 상태와 핵심 의사결정을 기록한다.
기술적 배경을 이해하는 독자를 전제로 한다: 스택, 제약, 용어를 알고 있는 사람들.

좋은 디자인 문서는 지형도를 닮았다. 미래의 엔지니어가 “왜 시스템이 이렇게 생겼는지”를 이해하게 해 준다.

2. 기능 스펙 (프로덕트 매니저)

프로덕트 매니저(그리고 때로는 디자이너)가 주로 책임지는 문서는 **기능 스펙(Functional Spec)**이다.

제품이 사용자와 비즈니스 관점에서 무엇을 하는지에 집중한다.
살아 있는 문서다: 제품이 바뀌면 같이 바뀐다. 요구사항이 변하고, 우선순위가 움직이고, 피드백이 들어오면 반영된다.
혼합된 이해관계자를 위한 문서다: 엔지니어, 디자이너, QA, 마케팅, 비즈니스 스테이크홀더 모두가 이해해야 한다.

기능 스펙은 지도라기보다 살아 있는 계약서에 가깝다. 우리가 무엇을, 어떤 식으로, 왜 제공하겠다고 약속하는지 정의한다.

둘 다 필수다. 둘 다 잘 쓰면 정말 아름답다. 그리고 둘 다, 너무 자주, 기능 비대화에 휘둘린다.

기능 비대화: 눈앞에 있는데도 잘 안 보이는 위협

기능 비대화는 그냥 귀찮은 수준의 문제가 아니라, 시스템적인 리스크다.

역사상 악명 높은 소프트웨어 프로젝트들 중 상당수가 이 문제 때문에 탈선했다.

Windows Vista는 범위 확대, 우선순위 변경, 복잡한 아키텍처가 일정과 사용자 신뢰를 어떻게 갉아먹는지 보여주는 대표적인 반면교사가 됐다.
의사소통 방식을 통째로 다시 정의하려 했던 Google Wave는, 끝없이 확장되는 기능과 불분명한 핵심 가치 때문에 결국 무너졌다. 많은 걸 할 수 있었지만, 단 하나의 매력적인 일을 제대로 하지 못했다.

패턴은 늘 비슷하다.

초기 문제가 애매하게 정의된다.
초반 문서들이 트레이드오프를 명확히 하기보다는 모든 사람을 만족시키려 한다.
새로운 아이디어가 메인 기능에 “이왕 하는 김에…” 하며 달라붙는다.
아키텍처는 이걸 수용하기 위해 이리저리 휘어진다.
프로젝트는 이해하기도, 테스트하기도, 출시하기도 어려운 상태가 된다.

문제의 심각성을 눈치챌 즈음엔 이미 너무 늦은 경우가 많다. 범위를 줄이려면 기술적으로도 정치적으로도 큰 비용을 치러야 한다.

이걸 “더 근면해지고”, “더 절제하고” 같은 정신력으로 해결할 수는 없다. 기능 비대화를 줄이는 가장 좋은 방법은 숨을 곳을 없애는 것이다.

그 지점에서 단일 질문 디자인 문서가 등장한다.

단일 질문 디자인 문서: 이것이 무엇인가

단일 질문 디자인 문서는 기존 문서를 대체하는 게 아니다. 기존 문서 위에 덧씌우는 집중 렌즈에 가깝다.

문서 전체는 단 한 줄을 중심으로 짜여 있다.

“이 기능은 다음 질문에 답하기 위해 존재한다: ‘사용자 X는 조건 Z에서 Y를 할 수 있는가?’”

딱 여기까지가 핵심이다.

나머지 문서는 이 한 질문을 풀어 설명할 뿐이다.

왜 이 질문이 중요한지
어떻게 이 질문에 답할 것인지
무엇은 지금은 답하지 않을 건지

기능을 하나의 날카로운 질문으로 축소하면:

문제에 대한 초기 명료성을 강제하게 되고,
범위의 경계가 보이고, 방어 가능해지고,
이후 나오는 모든 “이거 하나만 더” 요청에 대해 “이게 그 질문에 답하는 데 도움이 되나?”라는 간단한 테스트를 붙일 수 있다.

답이 “아니다”라면, 그 아이디어는 둘 중 하나다.

산만한 노이즈(잘라낸다), 혹은
별도 기능(따로 떼어 우선순위를 다시 매긴다).

단일 질문 디자인 문서 쓰는 법

기존 프로세스에 그냥 덧붙일 수 있는 가벼운 구조를 소개한다. 아키텍처나 UI를 깊게 파기 전에, 1–2페이지 안에 충분히 담을 수 있다.

1. 한 줄짜리 질문부터 쓴다

템플릿:

핵심 질문(Core Question)
이 기능은 다음 질문에 답하기 위해 존재한다.
“[어떤 사용자]가 [무엇을] [어떤 맥락/제약]에서 할 수 있는가?”

예시:

“새로 가입한 트라이얼 사용자가 가입 후 10분 이내에 기본 리포트를 생성하고 공유할 수 있는가?”
“고객 지원 담당자가 도구를 전환하지 않고 한 화면에서 고객의 최근 10개 상호작용을 볼 수 있는가?”

이걸 한 줄로 쓰는 게 어렵다면, 아직 그 기능을 충분히 이해하지 못한 것이다.

2. 그 질문을 기준으로 성공을 정의한다

핵심 질문에 바로 연결되는 짧은 성공 기준(Success Criteria) 섹션을 추가한다.

신규 트라이얼 사용자 중 80%가 가입 후 10분 안에 리포트를 생성한다.
지원 담당자가 상위 단계로 에스컬레이션하지 않고 해결하는 티켓이 25% 증가한다.

이 지표들은 이후 나오는 아이디어들에 대해 당신을 솔직하게 만든다. 이 숫자들을 움직이지 못하는 아이디어라면, 이 기능의 일부가 아니다.

3. 명시적인 비목표(Non-goals)를 적는다

비목표는 범위가 새어 나가는 걸 막는 가장 저렴한 방어선이다.

비목표 (이번 이터레이션에서 다루지 않음)

기본 템플릿을 넘어서는 고급 리포트 필터링 기능

내보낸 리포트에 대한 커스텀 브랜딩

오프라인 상태에서의 접근

이 중 일부는 훌륭한 아이디어일 수도 있다. 단지 지금 당장 이 핵심 질문에 답하는 데 필요한 것은 아닐 뿐이다.

4. 그 질문에 답하기 위한 최소 아키텍처를 그린다

이제 엔지니어링 디자인 문서의 차례다.

우리가 설계하려는 건 최종 형태의 “만능 시스템”이 아니다. 핵심 질문에 답할 수 있는 가장 작지만 일관된 아키텍처다.

여기서 **아키텍처 설명(architecture documentation)**이 중요해진다.

핵심 컴포넌트들이 어떻게 상호작용하는지 잡아 두고,
어떤 결정을 왜 내렸는지 기록하고,
무엇을 의도적으로 뒤로 미뤘는지 적어 둔다.

아키텍처 문서는 보여주기식 문서 작업이 아니다. 이건 안전난간이다. 지금 시스템이 무엇이고, 무엇이 아닌지를 명문화해서, 미래의 추가 기능들이 시스템을 조용히 뒤틀어서 깨지기 쉬운 형태로 변질시키지 못하게 막아 준다.

5. 이 문서는 고정 스냅샷으로, 기능 스펙은 살아 있는 문서로 둔다

단일 질문 디자인 문서는 스냅샷에 더 가깝다.

핵심 질문, 초기 결정, 의도된 범위를 담고,
합의가 끝나면 자주 바뀌지 않아야 한다.

반면 기능 스펙은 계속 살아 움직인다.

학습이 쌓일수록 UX 디테일, 엣지 케이스, 인터랙션을 다듬고,
스펙은 진화하지만, 항상 원래 질문의 제약 안에서 움직인다.

어떤 것이 정말로 맞지 않는다고 느껴질 때, 질문을 슬쩍 바꿔 쓰지 않는다. 이제는 다른 기능을 만들고 있다는 사실을 의식적으로 인정해야 한다.

역할별로 무엇이 좋아지는가

엔지니어에게

큰 아키텍처 베팅을 하기 전에, 문제의 경계가 또렷해진다.
누군가 “그냥 이거 하나만 빨리 넣자”고 할 때, 취향 싸움 대신 핵심 질문과 비목표를 기준으로 이야기할 수 있다.
디자인 문서가 날씬해진다. 한 가지 질문에 어떻게 답하는지 설명하는 문서이지, 언젠가 할 수도 있는 열 가지 가설적 기능까지 한꺼번에 담아두는 문서가 아니다.

프로덕트 매니저에게

기회주의적으로 늘어나는 범위에 대해 “그건 다른 질문이에요. 새 기능으로 따로 트래킹하죠.”라고 말하기 쉬워진다.
기능 스펙에 단단한 앵커가 생긴다. 모든 변경 사항은 핵심 질문을 돕는 방향이 아니면 우선순위가 밀린다.
스테이크홀더가 수많은 요구사항 문서를 헤집지 않고도, 이번 릴리스가 무엇을 위한 것인지 한 줄로 이해할 수 있다.

팀 전체에게

모두가 이 기능의 목적을 같은 한 줄로 반복해서 말할 수 있게 되면서 **정렬(alignment)**이 좋아진다.
트레이드오프가 쉬워진다. 두 가지 방향이 모두 질문에 답할 수 있다면, 더 단순한 쪽을 고르면 된다.
“뭔가 구체적인 것”을 더 빨리 출시하고, 배운 뒤, 그 위에 다시 반복(iterate)할 가능성이 훨씬 커진다. 끝없이 확장되는 비전만 좇다가 아무것도 완성하지 못하는 일을 피하게 된다.

기능 비대화를 일찍 포착하는 법

기능 비대화를 일찍 발견할수록, 고치는 비용은 싸진다.

경고 신호는 이런 것들이다.

핵심 질문을 쓰려는데, “그리고 또…”를 붙여야만 문장이 성립한다.
비목표 섹션이 비어 있거나, 너무 모호하다.
성공 지표를 바꾸지 않는 새 플로우를 자꾸 추가하고 있다.
아키텍처 다이어그램에 “나중에 쓸지도 모르는” 컴포넌트가 슬슬 등장한다.

해결책은 항상 같다. 다시 핵심 질문으로 돌아가는 것이다.

스스로에게 묻자.

여전히 이 질문이 우리가 가장 중요하게 생각하는 질문인가?
아니라면, 지금 기능을 이 상태로 마무리하고 새 기능을 시작해야 할까, 아니면 의식적으로 피벗해야 할까?

최악의 상황은 늘 같다. 다섯 개의 질문을 절반쯤만 건드려 놓고, 어느 하나에도 제대로 답하지 못한 채 프로젝트를 끝내는 것이다.

일관된 아키텍처 문서: 장기적인 방어선

시간이 지나면서 제품은 커지고, 새로운 기능들이 생겼다가 사라지고, 사람들이 들어오고 나간다.

이때 아키텍처 설명(Architecture Documentation)—시스템 구조와 의사결정을 체계적으로 기록하는 방식—이야말로 제품의 장기 기억이다.

이게 일관되게 관리되면:

각 기능의 설계가 어떤 질문과 어떤 비목표에서 출발했는지 한눈에 보인다.
즉흥적으로 붙인 애드혹 기능들이 어느새 핵심 의존성으로 굳어져 버리는 일을 피할 수 있다.
시스템이 각 시점에서 무엇을 하도록 의도됐는지를 알 수 있어, 향후 계획 수립이 쉬워진다.

단일 질문 디자인 문서와 일관된 아키텍처 문서를 함께 쓰면, 두 가지 강력한 제약이 생긴다.

의도(Intent): 이 기능이 왜 존재하며, 어떤 질문에 답하는가.
구조(Structure): 이걸 어떻게 구현했고, 무엇을 바꾸면 깨지는가.

이 조합이 제품을 취약하고 산만하게 만들지 않고, 집중되고 단단하게 유지시켜 준다.

결론: 한 질문이 해결하는 수많은 문제

기능 비대화는 도덕적 해이나 팀 기강 부족의 문제가 아니다. 다음과 같은 조건이 겹치면 자연스럽게 발생하는 결과다.

문제가 흐릿하게 정의되어 있고,
문서들이 한 번에 너무 많은 역할을 하려 들고,
아키텍처 결정이 명확한 목표와 연결되어 있지 않을 때.

단일 질문 디자인 문서는 이를 막는 작고 실용적인 해독제다.

기능이 반드시 답해야 할 단 하나의 명확한 질문을 정의한다.
성공 지표를 그 질문에 직접 연결한다.
비목표를 명시적으로 적어 둔다.
그 질문에 답할 수 있는 가장 작은 아키텍처를 설계한다.
기능 스펙은 계속 진화시키되, 질문을 슬그머니 바꾸지는 않는다.

이 패턴을 도입하면, 기능은 통제 불능의 범위 확장에서 벗어나기 시작한다. 더 단순하고, 더 빨리 출시되고, 사용자에게 실제로 필요한 것에 더 가까워진다.

그리고 누군가가 “이것만 하나 더 넣자”라고 말했을 때, 차분하고 객관적인 대답을 준비해 둘 수 있다.

“좋은 아이디어네요. 다만 그건 우리가 지금 답하려는 질문이 아니라, 다른 질문에 대한 답인 것 같아요. 그건 새 문서를 하나 파서 다루죠.”