← 프롬프트보다 중요한 것

Chapter 14

혼돈의 군주와 거절

그때 느꼈다.

이건 마왕이다.

혼돈의 군주.

달콤한 목소리로 속삭인다.

“이것도 추가해볼까?” “저것도 있으면 좋잖아.” “사용자가 원하는 거야.”

하나하나는 합리적이다. 하지만 다 하면 프로젝트는 괴물이 된다.

세금 계산기가 세무사 대체 프로그램이 되고, 대출 계산기가 은행 심사 시스템이 되고, 결국 아무것도 제대로 하지 못하는 거대한 잡탕이 된다.

스코프 크립. 범위가 기어올라간다. 눈에 안 보이게, 조금씩, 그러나 확실하게.

환각의 세이렌이 용사를 유혹했다면, 혼돈의 군주는 설계자를 유혹한다.

“더 좋게 만들 수 있어.” “사용자가 원해.” “하나만 더.”

달콤하다. 하지만 독이다.

나는 요청 목록을 바라봤다. 20개. 다 합리적이다. 다 “좋은” 기능이다.

거절하면 어떻게 될까?

사용자가 실망할 것이다. “제 의견은 무시하시네요”라고 생각할 것이다. 다른 서비스로 떠날 수도 있다. 겨우 2,000명인데, 그 중 일부라도 잃으면?

수용하면 어떻게 될까?

사용자가 기뻐할 것이다. “피드백 반영해줬네요!”라고 할 것이다. 더 많은 사람이 올 수도 있다.

수용이 정답처럼 보였다.

하지만 뭔가 걸렸다.

다른 서비스들은 어떻게 했을까? 성공한 서비스들, 애플이나 구글 같은 데.

애플은 “아니오”로 유명하다. 스티브 잡스가 말했다. “우리가 한 일만큼 하지 않은 일도 자랑스럽다.”

결국 선택이다. 모두를 만족시킬 수는 없다. 시도하면 아무도 만족시키지 못한다.

나는 깊이 숨을 들이쉬었다.


나는 선택해야 했다.

선택지 A: 요청을 다 수용한다. 사용자가 원하니까. 그러면 좋은 서비스가 되겠지.

선택지 B: 요청을 선별한다. 일부는 거절한다. 사용자가 실망할 수도 있다.

A를 선택하면 모두가 행복해 보인다. 단기적으로. 하지만 프로젝트는 비대해지고, 복잡해지고, 결국 아무도 관리 못하는 괴물이 된다.

B를 선택하면 누군가는 실망한다. 하지만 프로젝트는 집중을 유지하고, 하나의 일을 제대로 한다.

나는 B를 선택했다.

기준을 세웠다.

  1. 핵심 기능 강화인가? 연봉 → 실수령액 계산. 이게 핵심이다. 이걸 더 정확하게, 더 편하게 만드는 건 수용.

  2. 복잡도 대비 가치가 있는가? 다크 모드는 구현이 쉽고 많은 사람이 원한다. 가치 있다. 청년 소득세 감면은 복잡한데 해당자가 적다. 나중에.

  3. 원래 방향과 맞는가? 이미지 저장은 “계산기”의 범위다. 세무 상담 챗봇은 완전히 다른 프로젝트다.

20개 요청 중 5개만 수용했다.

부양가족 공제 - 수용 (핵심 기능 강화) 비과세 식대 - 수용 (핵심 기능 강화) 다크 모드 - 수용 (쉽고 가치 있음) 월급 입력 - 수용 (쉽고 편의성 향상) 이미지 저장 - 수용 (범위 내, 공유 촉진)

나머지 15개는 거절하거나 “나중에”로 분류했다.

거절 댓글을 달았다.

“좋은 아이디어입니다! 다만 현재 버전에서는 핵심 기능에 집중하고 있어서, 향후 업데이트에서 검토하겠습니다.”

누군가는 실망했을 것이다. 하지만 프로젝트는 살아남았다.