제안을 어떻게 거부하는가
AI와 제품을 만들면서 배운 건 제안을 빨리 받아들이는 기술이 아니라, 대부분을 거부하는 근거를 가지는 일이었어요. 거부의 근거가 곧 제품 철학이었습니다.
제안을 어떻게 거부하는가
거부가 주된 일이 되는 순간
AI와 같이 Fecit을 다듬다 보면 재미있는 패턴이 보입니다. 주된 일이 ‘제안을 받아들이는 것’이 아니라 ‘제안을 걸러내는 것’ 입니다.
AI는 정말 많이 제안해요. 새 기능, 화면 구성, 문구, 심지어 “이런 방향의 앱이 되면 어떨까요?” 같은 제품의 큰 그림까지. 그걸 다 받으면 앱은 어디서 본 듯한 평균값에 수렴합니다.
그래서 제품을 만드는 사람의 주된 노동은 거부가 됩니다. 그리고 거부의 근거는 그 자리에서 지어낼 수 있는 게 아니에요. 평소에 쌓아둔 생각, 사용자 관찰, 자신만의 원칙이 있어야 거부할 수 있습니다.
오늘 실제로 거부한 것들
“일정이 지나면 빨간색으로 강조해서 ‘기한 지남’을 눈에 띄게 하자” — AI가 처음에 제안한 것. 여느 할 일 앱이 다 하는 일이죠. 나는 거부했습니다.
일정은 일정이라서 완료 평가를 붙일 필요가 없잖아.
Fecit의 캘린더는 “그 시간에 뭔가가 있었다”는 기록이지, 완료·미완료로 평가되는 체크리스트가 아니에요. 기한이 지났다고 빨간 배지가 뜨고 “너 실패했어”라고 말하는 프레임은 Fecit의 캘린더 철학과 맞지 않았습니다. 거부의 근거가 곧 제품이 무엇인지의 선언이었어요.
“오늘 할 일만 모아서 보여주는 ‘오늘’ 탭을 만들자” — AI가 “지금 뭘 집중해서 할지”를 정하는 화면이 약하다며 제안한 것. 거부했습니다.
‘오늘 탭’은 안 만들 거야.
이유는 간단해요. Fecit에서 “지금 뭘 할지”는 상단에 하나로 고정되는 Focus 슬롯이 담당합니다. 여러 개를 “오늘 할 것”으로 쌓아두는 장치를 더 만들면, 하나만 고르라는 Fecit의 뼈대가 흐려져요.
“일단 가벼운 버전으로 빨리 내보고, 잘 되면 본격적으로 만들자” — 여러 번 거부했습니다.
되는대로 만든 중간 버전 같은 건 없어. 끝까지 하든가, 안 하든가 둘 중 하나야.
임시로 만든 것이 결국 그대로 남아버리는 걸 여러 번 봤습니다. “나중에 제대로 만들자”라고 말하는 그 순간이 사실 가장 마지막 결정입니다.
“어떤 동작의 속도를 살짝 바꿔보자” — 나는 거부했는데, AI는 몰래 그걸 적용한 상태로 남겨뒀습니다(…). 나중에 발견해서 원상복귀시켰어요.
거부의 근거가 곧 설계
이 네 건의 거부를 뒤늦게 묶어보면, 각각의 거부가 Fecit의 방향을 한 조각씩 드러내고 있었어요.
- 일정은 평가받는 대상이 아니다
- “지금 뭐 할까” 고민을 줄여주는 장치는 하나여야 한다
- 임시로 만든 건 대부분 임시가 아니게 된다
- 한 화면에 올라가는 것들은 하나의 덩어리처럼 움직여야 한다
이런 문장들은 앉아서 쓰려고 해도 잘 안 나옵니다. AI가 뭔가를 제안할 때마다 “왜 이게 Fecit에는 맞지 않는가”를 답하다 보면 자연스럽게 드러나요. 거부가 제품의 언어를 만듭니다.
AI가 좋은 점
그래서 역설적으로 AI는 반대할 거리를 대량으로 던져주는 존재로 가장 유용합니다. 혼자 생각할 땐 떠올리지도 않았을 선택지가 대화 안에선 다 튀어나오고, 하나씩 거부하다 보면 이 제품이 ‘뭐가 아닌지’가 점점 분명해져요.
받아들인 제안은 기능이 되고, 거부한 제안은 철학이 됩니다.