BLOG POST
AI로 제품을 만들 때 quality bar는 어디에 둘 것인가
Related Product #
Why this post #
AI를 쓰면 만드는 속도는 분명 빨라진다.
예전 같으면 며칠 걸릴 화면, 플로우, 카피, 구현이 이제는 훨씬 짧은 시간 안에 나온다.
문제는 그 다음이다.
빠르게 나왔다는 이유로 그대로 공개할 것인가, 아니면 어떤 기준을 넘어야만 공개 가능한 제품으로 볼 것인가.
나는 결국 이 기준이 있어야 77BuildsIn7Months 같은 시도도 의미가 생긴다고 본다.
이 글은 그 기준을 내 식대로 정리해 두는 문서다.
완성된 답은 아니지만, 지금 내가 어떤 제품은 계속 밀고 어떤 제품은 멈추는지 설명하는 가장 직접적인 기준이기도 하다.
quality bar는 단순 구현 완료가 아니다 #
quality bar를 너무 낮게 잡으면, “작동은 하지만 다시 들어가고 싶지는 않은 제품”이 쌓인다.
반대로 너무 높게 잡으면 아무것도 공개하지 못하게 된다.
그래서 내가 생각하는 quality bar는 하나의 항목이 아니라 몇 가지 층위의 합이다.
1. 아이디어 자체가 설명 가능한가 #
첫 번째 기준은 구현보다 앞에 있다.
이 제품이 왜 존재해야 하는지, 누구에게 어떤 감각이나 문제 해결을 제공하는지 한 문장으로 설명이 되어야 한다.
여기서 막히면, 구현이 아무리 빨라도 제품은 약하다.
예를 들어:
1분일탈은 짧은 행동 제안으로 기분 전환을 만든다.낭만타로는 결과 문구보다 카드 리추얼 감각을 준다.
이런 문장이 먼저 있어야 이후의 화면, 인터랙션, 수익화도 의미를 갖는다.
1분일탈은 첫 화면과 초반 선택 흐름까지는 "짧은 카드 경험으로 기분을 환기한다"는 제품 의도가 비교적 설명되는 편이었다. 다만 그 다음에 무엇이 이어져야 하는지는 더 선명하지 못했다. 아이디어가 초반부에서만 설명되고 뒤에서 흐려지면, 구현이 더 빨라도 제품으로는 약하다.
2. UI가 아니라 UX가 성립하는가 #
AI로 만들면 화면은 빨리 나온다.
하지만 보기 좋은 UI와 다시 쓰고 싶은 UX는 다르다.
내가 보려는 기준은 이런 쪽이다.
- 첫 진입에서 무엇을 해야 하는지 바로 이해되는가
- 흐름이 끊기지 않는가
- 한 번 눌러보고 끝나는 느낌이 아닌가
- 결과를 받는 과정 자체가 감각적으로 납득되는가
특히 낭만타로처럼 리추얼 경험이 중요한 제품은 결과 텍스트보다 과정의 손맛이 훨씬 중요하다.
낭만타로의 card_select 화면은 이 기준을 가장 잘 보여 준다. 이 제품의 핵심은 결과 문구보다, 카드를 고르는 순간이 실제 리추얼처럼 느껴지는가에 있었다.
3. 결과 품질이 흔들리지 않는가 #
AI 제품은 데모 화면 한 장은 잘 나온다.
문제는 실제 사용에서 품질 편차가 커진다는 점이다.
그래서 quality bar에는 결과 품질의 안정성도 포함된다.
- 결과가 한두 번만 그럴듯한가
- 반복 사용해도 기준 이하로 무너지지 않는가
- 내가 사용자라면 실제로 이 결과를 신뢰할 수 있는가
K-Glow Stylist를 돌아보면, 바로 이 지점이 중요했다.
학습용 build로는 의미가 있었지만, 품질 기준을 안정적으로 넘기는 단계까지는 가지 못했다.
K-Glow Stylist는 보기 좋은 결과 화면을 만드는 것과, 반복 사용에서도 신뢰 가능한 품질을 일정하게 내는 것이 전혀 다른 문제라는 점을 보여 준 사례였다. 학습용 build로서는 충분했지만, 실제 출시를 논할 만큼 높고 동일한 품질을 만들려면 더 많은 노력이 필요했고, 그 단계까지는 더 밀지 않기로 한 제품이기도 했다.
4. 운영 가능한 구조인가 #
출시 직전에는 코드보다 운영 구조가 더 중요해지는 순간이 온다.
예를 들면:
- 실제 데이터를 어떻게 관리할 것인가
- 카피나 결과 품질은 어떻게 유지할 것인가
- 문의나 오류 대응은 어떻게 할 것인가
- 결제나 수익화는 어떤 단위로 붙일 것인가
즉 quality bar에는 UI/UX뿐 아니라 운영 현실도 포함된다.
아무리 그럴듯해도 운영이 안 되면 아직 launched로 보기 어렵다.
1분일탈은 한 번 쓰는 경험 자체는 만들 수 있었지만, 이후 기록과 재방문 구조, 실제 서비스 데이터를 어떻게 관리할지까지 이어져야 launch를 논할 수 있다는 점을 보여 줬다.
5. 내가 다시 붙들고 싶은 제품인가 #
마지막으로는 꽤 자의적인 기준이 들어간다.
이 제품을 내가 정말 더 밀어붙이고 싶은가, 아니면 학습과 실험으로서 의미를 끝냈는가.
이 기준은 차갑게 보일 수도 있지만 중요하다.
관심과 우선순위가 없는 제품은 대개 품질도 끝까지 끌어올리기 어렵다.
그래서 quality bar는 객관식 체크리스트이면서 동시에 창업자의 주관적 판단이기도 하다.
결국 오래 붙들 제품은 화면보다 우선순위에서 드러난다. nangman_craft 같은 core product는 계속 손을 대게 되지만, 그렇지 않은 build는 어느 시점부터 자연스럽게 우선순위에서 밀린다.
실제로는 이렇게 판단한다 #
지금 공개된 제품들을 보면, 같은 속도로 만들었어도 결론은 다르게 나온다.
| Product | 현재 상태 | quality bar 관점의 해석 |
|---|---|---|
| No.001 K-Glow Stylist | Ended · MVP | 학습용 build로는 충분히 의미 있었지만, 결과 품질과 장기 우선순위가 launch 기준까지는 가지 못했다. |
| No.002 1분일탈 | Hold · MVP | 짧은 카드 경험의 가능성은 확인했지만, 실제 서비스에 들어갈 데이터 품질과 재방문 구조, 수익화 방향이 더 필요하다. |
| No.004 낭만타로 (가칭) | Hold · Prototype | 핵심 UX는 살아 있지만, 결과 품질과 상품 구조, 운영 연결이 아직 launch 기준을 넘지 못했다. |
이 표를 보면, quality bar는 단순히 “코드가 있느냐”의 문제가 아니라는 점이 더 분명해진다.
지금 내 기준을 한 문장씩 풀면 #
현재 나는 아래 다섯 가지가 어느 정도 함께 성립해야 launched를 이야기할 수 있다고 본다.
-
아이디어가 한 문장으로 설명된다.
이 제품이 왜 있어야 하는지, 누가 왜 다시 들어와야 하는지 바로 말할 수 있어야 한다. -
핵심 UX가 다시 쓰고 싶을 정도로 납득된다.
기능이 되는 것과 “한 번 더 써보고 싶다”는 감각은 다르다. -
결과 품질이 반복 사용에서 크게 무너지지 않는다.
AI를 붙인 서비스일수록 한두 번 잘 되는 것보다 편차 관리가 더 중요하다. -
운영 구조와 수익화 방식이 어느 정도 연결된다.
launch는 코드 완료가 아니라 운영 시작이기 때문에, 뒤에 남는 구조가 있어야 한다. -
내가 계속 붙들 만한 이유가 남아 있다.
창업자 입장에서 이 기준은 생각보다 크다. 우선순위와 관심이 없는 제품은 결국 quality bar를 넘기기 어렵다.
이 중 몇 개가 빠지면 Prototype이나 MVP일 수는 있어도, Launched라고 부르기는 어렵다.
그래서 77BuildsIn7Months에서도 중요한 건 숫자보다 선이다 #
77BuildsIn7Months는 많이 만들기 위한 프레임이기도 하지만, 아무거나 다 launched로 세겠다는 뜻은 아니다.
오히려 지금은 반대로 본다.
- 많이 만들수록 quality bar는 더 선명해야 한다
- product page에 남길 만한 결과와 배움이 있어야 한다
- launched보다
왜 아직 아닌지를 설명할 수 있는 상태 관리가 더 중요할 수 있다
그래서 이 사이트에서는 Prototype, MVP, Hold, Ended 같은 상태를 숨기지 않는다.
그건 미완성을 미화하려는 게 아니라, 어떤 기준에서 멈췄는지까지 공개하는 것이 build in public에 더 가깝다고 보기 때문이다.
지금 결론 #
지금 시점에서 내가 보는 quality bar는 “잘 만들었는가”보다 아래에 더 가깝다.
- 왜 존재하는지 설명되는가
- 다시 쓰고 싶은 경험이 있는가
- 결과 품질이 반복 사용을 버티는가
- 운영과 수익화가 연결되는가
- 내가 계속 밀 이유가 남아 있는가
이 다섯 개가 모여야 launched를 붙일 수 있다.
Next #
앞으로 이 기준은 계속 바뀔 가능성이 크다.
AI 툴이 바뀌고, 구현 속도가 더 빨라지면 quality bar는 오히려 더 높아져야 할 수도 있다.
그래서 이 글은 완성된 기준이라기보다, 현재 내가 어디에 선을 긋고 있는지 기록해 두는 초안에 가깝다.