데모는 인상적이다. 근데 그다음은?
AI 이미지 생성 도구를 처음 보는 순간, 누구나 감탄한다. 프롬프트 한 줄에 그럴듯한 사진이 나오고, 데모 영상은 언제나 완벽한 결과물만 보여준다. 그런데 실제 사용자는 그 '한 번의 완벽한 결과'를 위해 제품을 쓰는 게 아니다. 반복 가능하고 예측 가능한 결과를 원한다. 이 간극이 바로 AI 데모와 AI 제품의 차이다.
창의적 자유도를 줄이면 품질이 올라간다
dev.to에 공개된 GenBlink 개발 회고는 이 간극을 정면으로 다룬다. 사용자가 사진 한 장을 업로드하면 10~50장의 AI 포토슈트를 생성하는 이 제품이 가장 먼저 버린 것은 '자유로운 프롬프트 입력창'이었다. 자유도가 넓을수록 실패 원인을 특정하기 어렵다. 소스 이미지가 문제인지, 배경 설정이 문제인지, 포즈가 문제인지 알 수가 없다.
대신 GenBlink는 '큐레이티드 팩' 구조를 선택했다. 프로페셔널 스튜디오, 도시 데이팅, 골든아워 피트니스 같이 일관된 촬영 언어를 가진 팩을 사전 정의하고, 사용자는 그 안에서 선택한다. 창의적 방향은 제품이 미리 잡아두고, 사용자는 세부 디테일만 조정한다. 선택지를 제한했더니 오히려 결과물이 예측 가능해졌다.
복잡한 건 백엔드가 책임진다
GenBlink가 다음으로 설계한 것은 '신원 보존을 사용자 몫으로 두지 않는 것'이다. 얼굴, 나이, 피부 톤, 체형을 일관되게 유지하는 시스템 프롬프트는 백엔드에 은닉한다. 사용자는 '안경을 추가해줘' 같은 간단한 지시만 하면 된다. UI가 단순해지는 동시에 시스템이 일관된 결과를 보장한다.
크레딧 구조도 마찬가지다. '사진 한 장 = 크레딧 1개'라는 약속은 단순하지만, 그 뒤에는 예약→사용→환불을 추적하는 append-only 원장이 있다. 실패한 생성은 크레딧을 돌려준다. 10장 중 3장이 실패해도 7장은 정상 제공된다. 사용자가 경험하는 약속은 단순하고, 그것을 지키는 구조는 견고하다. 이 분리가 제품의 신뢰를 만든다.
선택이 생성의 일부다
GenBlink의 또 다른 핵심 설계는 '리뷰 워크플로우'를 핵심 제품 기능으로 다룬다는 점이다. AI 생성 이미지에는 여전히 왜곡된 손, 뒤틀린 반사, 원본과 멀어진 얼굴이 섞여 나온다. 이를 숨기지 않고, 모달 미리보기→선택→다운로드→리믹스 흐름 전체를 품질 관리 워크플로우로 설계했다. 배치 결과를 실시간으로 스트리밍해 어떤 결과가 완료됐고 어떤 결과가 실패했는지 즉시 보여준다. '생성'과 '선택'은 분리된 단계가 아니라 하나의 경험이다.
실제 사용자 앞에 앱을 던져야 보이는 것들
velog에 올라온 우산 알림 앱 개발 4주차 회고는 같은 교훈을 팀 프로젝트 현장에서 보여준다. 팀은 '내 최애가 우산을 챙기라고 알림을 보낸다'는 컨셉을 사용자 인사이트로부터 도출했다. 동네 친구와의 대화에서 시작된 이 아이디어는 마일스톤 발표에서 긍정적인 반응을 얻었다. 그런데 진짜 검증은 그 이후였다.
팀은 발표 전 주말 동안 팀원 전원이 실제로 앱을 들고 동네를 돌아다니며 테스트했다. 그리고 Live Activity 기능이 의도와 다르게 작동한다는 사실을 발견했다. 잠금화면에 계속 떠 있는 Live Activity는 '알림'처럼 느껴지지 않았다. 사용자가 무시하게 될 기능이었다. 직접 써보지 않았다면 '이 정도면 사용자가 의도대로 쓰겠지'라는 지레짐작으로 넘겼을 것이다. 회고록의 말이 정확하다. "주말 동안 테스트해보길 참 잘했다."
AI 코딩 도구는 속도를 주지만, 코드 소유권은 여전히 사람 몫
개발 과정에서 팀은 바이브코딩, 즉 AI 기반 코드 생성을 주요 도구로 썼다. 속도는 확실히 빨라졌다. 그런데 오류가 나면 다시 AI에게 '고쳐줘'를 외쳐야 하는 상황이 반복됐다. 코드를 어느 정도 읽을 수 있어야 AI 도움도 효과적이라는 것을 몸으로 배웠다. AI 코딩 에이전트가 지시하지 않은 작업을 수행하거나 하지 말라는 작업을 해서 되돌리느라 시간이 걸린 경험도 있었다.
GenBlink 개발자가 '사용자 프롬프트와 시스템 동작을 분리 저장하라'고 강조한 것과 같은 맥락이다. AI가 생성한 코드도, AI가 생성한 이미지도, 그 결과를 검토하고 선택하는 구조가 없으면 제품이 아니라 실험이 된다.
워크플로우가 없으면 AI는 그냥 마법처럼 보일 뿐이다
두 사례가 공통으로 가리키는 것은 하나다. AI 도구가 만들어주는 것은 결과물의 초안이지, 사용자 경험의 전체 흐름이 아니다. GenBlink는 입력 제약→생성→스트리밍 진행→리뷰→재사용의 워크플로우를 설계했기 때문에 제품이 됐다. 우산 알림 앱 팀은 컨셉 검증→자체 테스트→해외 멘토 피드백→사용자 테스트→수정의 루프를 반복했기 때문에 Live Activity를 푸시 알림으로 제때 바꿀 수 있었다.
빠르게 만드는 것과 제대로 만드는 것은 대립하지 않는다. AI 도구로 속도를 확보하되, 검증 루프를 설계하는 것이 그 둘을 동시에 가능하게 하는 조건이다. 프로토타입을 빨리 뽑는 능력보다, 그 프로토타입을 실제 사용자 앞에 빨리 던질 수 있는 구조가 더 중요한 시대다.
다음 질문은 '얼마나 빨리'가 아니라 '어디서 검증할 것인가'
AI 코딩 도구의 발전은 프로토타이핑 비용을 계속 낮추고 있다. 이는 검증 주기도 짧아질 수 있다는 뜻이다. 그러나 도구가 빨라질수록, '무엇을 검증해야 하는가'를 설계하는 역량의 비중은 오히려 커진다. GenBlink가 보여주듯 사용자 경험의 계약—명확한 입력, 예측 가능한 출력, 솔직한 실패 복구—은 AI 모델이 아니라 그 주변 워크플로우에서 만들어진다. AI로 제품을 만드는 팀이 가장 먼저 설계해야 할 것은 모델 선택이 아니라 검증 루프다.