사용자가 AI를 의식하지 않게 — 프롬프트 최소화 UX

AI를 붙이면 왜 다들 채팅창부터 그릴까

제품에 AI를 넣자는 회의는 거의 항상 같은 그림에서 시작한다. 화면 어딘가에 입력창을 하나 두고, 사용자가 원하는 걸 말하면 모델이 답한다. LLM = 프롬프트 창이라는 멘탈모델이 워낙 강해서, “AI 기능”과 “채팅 UI”가 거의 동의어처럼 쓰인다.

그런데 우리 타겟의 자리에 앉아보면 그 빈 입력창은 선물이 아니라 숙제다. 밥비서의 사용자는 “오늘 뭐 먹지, 뭐 사지, 어떻게 만들지”를 매일 고민할 여력이 없어서 우리를 찾은 사람들이다. 그에게 빈 칸을 내밀고 “원하는 식단을 말씀해 주세요”라고 하는 건, 덜어주겠다던 의사결정을 다시 떠넘기는 일이다. 자유발화 인터페이스는 표현의 자유를 주는 동시에, “무엇을 어떻게 말해야 좋은 결과가 나오는가”라는 부담을 사용자에게 전가한다. 프롬프트를 잘 쓰는 법은 결국 사용자가 배워야 할 또 하나의 기술이다.

그래서 우리는 정반대로 갔다. 밥비서는 챗봇이 아니다. 사용자는 프롬프트를 쓰지 않고, AI가 일하고 있다는 사실조차 의식하지 않는다.

의도를 구조로 받는다 — 설문과 프리셋

핵심 전환은 단순하다. 의도를 자유 텍스트가 아니라 유한한 선택지로 받는다.

온보딩은 대화가 아니라 구조화된 설문이다. 사용자는 끼니별로 가볍게 먹을지 든든하게 먹을지를 고르고, 못 먹거나 피하고 싶은 식재료를 빼고, 식사 인원을 정하고, 한식·양식 같은 구성 비율과 라이프스타일 프리셋을 선택한다. 자기 취향을 문장으로 묘사할 필요가 없다 — 몇 개의 선택지를 짚으면 의도가 구조화된 설정으로 저장된다. 취향은 시간이 지나며 바뀌므로 설문은 언제든 다시 제출할 수 있고, 갱신된 설정이 다음 식단에 반영된다.

입력은 구조, 출력은 요일×끼니 표다. 사용자가 채우지 않은 빈자리는 엔진이 결정론적으로 메운다. 여기서 중요한 건 사용자가 만지는 표면에는 프롬프트가 한 줄도 없다는 점이다. 의도는 폼(form)으로 들어오고, AI는 그 아래에서 조용히 식단을 짠다.

사용자가 보는 것은 “이번 주에 뭘 먹을지”이지, “AI에게 뭐라고 말할지”가 아니다.

자유도를 줄여 신뢰를 올렸다

자유발화를 없앤 건 우리가 못 만들어서가 아니라, 트레이드오프를 의식적으로 택한 결과다.

자유 텍스트 입력에는 보이지 않는 비용이 따라온다. 사용자에겐 표현 부담과 학습 비용이 생기고, 시스템 쪽에는 해석 편차가 생긴다. 같은 의도라도 사람마다 다르게 적고, 같은 문장이라도 모델이 다르게 읽는다. 그 편차는 결과의 일관성을 갉아먹는다. 반대로 구조화 입력에도 대가가 있다 — 표현력이 제한된다. 선택지 밖의 미묘한 요구는 담기 어렵다.

우리가 후자를 택한 이유는 타겟의 욕구가 분명했기 때문이다. 이들이 원하는 건 더 똑똑한 대화 상대가 아니라 생각 없이 따라 하면 되는 한 주치 집밥이다. 표현력 약간을 포기하는 대신 입력 부담과 결과 편차를 동시에 줄이는 거래는, 이 사용자에겐 남는 장사다.

그리고 이 선택은 엔진 설계와도 맞물린다. 의도가 유한한 구조로 들어오면, 그 아래 LLM 없이 도는 결정론 엔진이 안정적으로 식단을 짤 수 있다. 입력이 자유 텍스트였다면 의미를 다시 해석하는 단계가 끼어들어 결과가 흔들렸을 자리다. 입력의 자유도를 줄인 것이 곧 결과의 신뢰도를 올린 지렛대였다.

lovable한가? — MLP가 걸러낸 것들

우리 제품 원칙은 MLP, Minimum Lovable Product다. 매 접점에서 “이게 되는가”가 아니라 “이게 사랑할 만한가”를 묻는다. 추상 슬로건처럼 들리지만, 실제로는 유혹을 걸러내는 필터로 작동한다.

더 많은 입력 옵션을 주면 더 강력해 보인다. 채팅 UI를 얹으면 더 똑똑해 보인다. 둘 다 “되는 기능”이지만, 매주 반복해서 쓰는 사용자에게 사랑받는 경험은 아니었다. lovability를 기준에 두자 선택이 갈렸다 — 입력 부담을 최소화하고, 식단에서 장보기, 밀프렙으로 이어지는 동선을 한 번에 흐르게 하는 쪽이었다.

이건 책상에서 나온 원칙이 아니다. RN으로 만든 v1을 내고 나서, “매주 다시 쓰는” 관점으로 보니 입력 동선이 무겁다는 게 드러났다. 우리는 v2를 Flutter로 다시 세우며 입력 흐름을 처음부터 다시 짰다. 무엇을 더 넣을지가 아니라 무엇을 덜어낼지가 그 재설계의 질문이었다.

프롬프트를 사용자에게 떠넘기지 마라

여기서 일반화할 수 있는 패턴은 도메인을 가리지 않는다. 사용자에게 프롬프트 엔지니어링을 전가하지 말고, 의도를 구조로 받아 엔진이 처리하게 하라. 그러면 사용자는 AI를 의식하지 않고 결과만 누린다.

우리는 이 설계를 식단에서 검증했지만, 의도를 흡수하는 인터페이스와 그 아래에서 도는 결정론 엔진이라는 구조는 그대로 옮길 수 있는 자산이다. 자사 제품에 AI를 얹을지 고민 중이라면, 디폴트로 채팅창을 놓기 전에 한 번 더 물어볼 만하다 — 이 의도는 정말 문장으로 받아야 하는가, 아니면 구조로 받아 흡수할 수 있는가.

이 질문을 당신의 도메인에서 함께 풀고 싶다면, partners@creativengine.ai로 이야기를 시작하면 된다.