Prova를 내놓는 데서 code는 오히려 쉬운 쪽이었다

Prova가 제게 진짜라고 느껴지기 시작한 순간은, product가 더 이상 제가 스스로를 속이게 두지 않았던 순간이었습니다.

Homepage는 꽤 오랫동안 aspirational한 상태로 남아 있을 수 있습니다.

하지만 live product는 그렇지 못합니다.

사람들이 signup하고, email을 confirm하고, 잘못된 state에 landing하고, billing을 건드리고, work를 submit하고, system이 무슨 일이 있었는지 기억해 주길 기대하는 순간, bottleneck은 바뀝니다.

Product는 real promises를 하기 시작합니다. 그리고 invisible work가 갑자기 아주 visible해집니다.

제가 3월과 4월 초에 Claude Max에서 Codex로 넘어간 이야기를 세 편의 post로 적었던 것을 보신 분이라면, 그 experiment가 아직도 진행 중이라는 걸 아실 겁니다. 저는 이미 May 2, 2026에 proper follow-up을 내겠다고 약속했고, 그 약속을 지킬 생각입니다. 이 글은 그 글이 아닙니다.

하지만 Prova는 그보다 먼저 더 useful한 realization을 억지로 보게 만들었습니다.

어떤 것이 이름 붙은 idea를 넘어서 real product가 되기 시작하면, bottleneck이 바뀝니다.

적어도 이 build에서 저는 그렇게 느꼈습니다.

어려웠던 건 LLM에게 code를 generate시키는 일이 아니었습니다.

어려웠던 건, 적어도 이번 push에서만큼은, code 바깥의 모든 것이었습니다.

지금 AI와 함께 무언가를 만들고 있다면, 특히 real users, real money, real product state가 얽혀 있다면, 아마도 이게 아무도 미리 잘 말해주지 않는 부분일 겁니다.

더 useful한 lesson은 이것입니다. Product가 더 이상 demo가 아닐 때, 무엇이 진짜 중요해지는가.

이름 짓기는 쉬운 쪽이었다

솔직히 말하면, Prova라는 이름을 정하는 건 전체 과정에서 더 쉬운 결정 중 하나였습니다.

이 이름은 실제 product와 정말 잘 맞았습니다.

Prova는 proof 혹은 test에 가깝습니다. 그리고 그게 바로 이 product의 일입니다. 사람을 어르고 달래서 이미 builder가 된 것처럼 느끼게 하려는 게 아닙니다. 실제로 work를 prove하게 만드는 겁니다. 이름도 좋고, useful하고, searchable합니다. 다시 말해, 그게 easy part였습니다.

더 어려운 부분은 그 다음부터 시작됐습니다. Prova가 그냥 이름과 landing page가 아니게 되는 순간, real products가 반드시 요구하는 모든 unglamorous work를 같이 요구하기 시작했기 때문입니다.

assessment logic
onboarding state
authored progression
review visibility
billing flows
auth hardening
content publishing
release gates

이 과정은 AI tools에 대한 제 생각도, product building에 대한 제 생각도 바꿨습니다.

Prova는 실제로 무엇이 되어야 했는가

Prova는 이제 marketers와 advertising professionals를 위한 structured AI builder program입니다. AI tools를 쓰는 수준에서 벗어나 real workflows, pilots, operating systems를 만들고 싶은 사람들을 위한 프로그램이죠. 실제 제품 차원에서는 assessment와 onboarding, chat-first가 아니라 sprint-first product, review-driven progression, durable product state, 그리고 generic AI chat box보다는 current sprint 주변의 office hours처럼 작동하는 mentor layer를 의미했습니다.

분명히 해두자면, 저는 Prova가 "끝났다"고 말하는 게 아닙니다. 그렇게 말하고 넘어가고 싶지만, 그건 너무 convenient하고 아마도 사실도 아닙니다. 지금 더 정확한 framing은 soft launch입니다. Core production system은 live이고 실제로 작동하지만, billing portal return-path cleanup이나 fuller MFA automation coverage 같은 launch-readiness work는 여전히 남아 있습니다. 오히려 저는 그래서 이 lesson이 더 useful하다고 느낍니다. 현실의 product building은 원래 이렇습니다. 끝난 것도 아니고, fake도 아닙니다. 다만 다음 실수가 비용을 만들 만큼은 충분히 real해진 상태입니다.

제가 그냥 generate할 수 없었던 일

AI product의 가장 쉬운 버전은 거의 항상 demo version입니다.

겉모습만 그럴듯하게 만드는 건 빠릅니다.

homepage 하나
chat box 하나
slick screenshots 몇 장
persuasive한 product sentence 하나

런치 teaser로는 그 정도면 useful합니다.

하지만 real work가 어디 있는지 이해하는 데는 별로 도움이 되지 않습니다.

제게 그 real work는 여섯 군데에서 드러났습니다.

1. Sprint system은 더 이상 그럴듯한 척하면 안 됐다

저는 Prova가 landing page에서는 structured해 보이지만, 안에 들어가면 곧바로 generic해지는 product가 되길 원하지 않았습니다.

Fixed authored sprints는 충분한 동안에는 useful했습니다.

그러다 어느 순간 충분하지 않게 됐습니다.

진짜 문제는 learner가 sprint 하나를 통과했는데, 다음 real gap이 catalog의 next authored sprint가 아닐 때 나타났습니다.

가장 lazy한 답은 이런 식이었겠죠.

"그냥 model이 next sprint를 invent하게 두자. title, rubric, review criteria, 전부 다."

저는 그걸 trust하지 못했습니다.

그래서 system은 그보다 더 strict해져야 했습니다.

이제 reviewer는 authored path가 맞으면 canonical next sprint를 그대로 recommend할 수 있습니다. known foundation gap이 보이면 adaptive detour, 즉 main path로 돌아가기 전에 foundation issue를 메우는 temporary sprint를 assign할 수 있습니다. 그리고 next real gap이 authored catalog 바깥에 있을 때만 composed sprint를 request할 수 있습니다.

이건 blog post로 쓰면 작아 보입니다.

Product 안에서는 전혀 작지 않습니다.

Composed sprint는 단순한 "dynamic text"가 아니기 때문입니다.

Placeholder sprint를 만들고, assignment를 persist하고, canonical roadmap으로 돌아가는 return path를 보존하고, sprint packet을 채우고, 나머지 system이 그 sprint를 real product state처럼 다루게 해야 합니다.

이걸 trustworthy하게 만든 constraint는 꽤 단순했습니다.

model은 standard를 invent하면 안 된다.

Composed sprint는 packet만 채웁니다. title, summary, context, assignment, example.

Submission schema와 review rubric은 계속 authored template sprint에서 옵니다.

이건 이번 build 전체를 통틀어 가장 큰 lessons 중 하나였습니다.

무언가 dynamic한 상태에서도 trustworthy하게 유지하려면, contract는 fixed로 두고 model은 그 안에서만 움직이게 해야 합니다.

여기서 Codex도 많이 도움 됐습니다. "봐, 이게 generate한 거야" 같은 flashy한 방식이 아니라, 훨씬 더 useful한 방식으로요. Migrations, router logic, placeholder lifecycle, request state, integration tests, 그리고 dynamic product를 덜 fake하게 만드는 boring contract work에서요.

그리고 솔직히, lazy한 버전이 잠깐은 저를 유혹하기도 했습니다. Model을 더 clever하게 두고, system은 더 magical하게 보이게 하고, 나중에 정리하자. 그 생각은 paying user에게 bad sprint assignment를 설명하는 장면을 떠올리는 순간 갑자기 약해집니다.

2. Retrieval은 semantic을 넘어서 curricular해야 했다

System이 sprints를 compose하도록 만들자, retrieval quality는 더 이상 backend detail이 아니었습니다.

그건 curriculum quality가 됐습니다.

Product가 tooling, measurement, competitive intelligence에 관한 sprint를 compose하려면, knowledge base에서 "대충 관련 있어 보이는" chunks를 집어 와서 packet이 coherent해 보이길 바라면 안 됐습니다.

Knowledge base 자체가 더 똑똑해져야 했습니다.

저희는 blog posts, course modules, transcripts, companions, templates, deep-dive resources 같은 real corpus에서 다시 구축했습니다.

그리고 source 종류에 따라 chunking 방식도 바꿨습니다.

Narrative blog posts는 더 크게 유지해도 됐습니다.

Instructional modules는 heading-first chunks가 필요했습니다.

Templates와 reference assets는 tables, checklists, slide references, quick-reference sections를 generic paragraphs로 납작하게 만들지 않도록 더 structured한 chunking이 필요했습니다.

그리고 tagging이 중요해졌습니다.

단순히 "이건 무엇에 관한 내용인가?"가 아니라,

이게 어떤 kind of chunk인가
어떤 topic tags가 맞는가
어떤 audience에 fit하는가
어느 difficulty level에 속하는가

이렇게 봐야 했습니다.

그 결과 retrieval은 "nearest vector wins"에서 curricular matching에 가까운 것으로 바뀌었습니다.

Product는 이제 이렇게 물을 수 있었습니다.

"이 topic, 이 audience, 이 level에 맞는 grounded material을 가져와."

이건 demo에 RAG만 붙여 놓은 것보다 훨씬 serious한 system입니다.

3. Evals는 model이 아니라 pipeline을 test해야 했다

이게 어쩌면 가장 중요한 lesson이었습니다.

UI에서 composed sprint 하나가 decent해 보인다고 victory를 선언하고 싶지는 않았습니다.

그래서 eval system도 product와 함께 자라야 했습니다.

처음에는 sprint review eval harness가 있었습니다.

그 다음 composition이 retrieval gate를 추가했습니다. tagged retrieval이 untagged baseline보다 grounded material을 실제로 개선하는지를 보는 pass/fail check였습니다.

그 다음 composition이 full end-to-end harness를 추가했습니다.

sprint packet compose하기
schema-valid synthetic submissions generate하기
real reviewer로 그 submissions를 실제로 review하기
grounding, audience differentiation, difficulty gradient, curriculum coherence, review quality, authored work 대비 비교 가능성으로 결과 judge하기

그게 real learning loop였습니다.

쉽게 말하면, 목표는 "personalized progression"이 fake personalization으로 무너지는 걸 막는 것이었습니다. System이 "이 next sprint는 정말 너를 위한 것"이라고 말하려면, decent-looking packet 하나로는 부족했습니다. 그 sprint가 grounded하고, level에 맞고, authored curriculum과 같은 standard로 여전히 reviewable하다는 evidence가 필요했습니다.

질문은 "model이 JSON을 반환하느냐"가 아니었습니다.

오히려 이런 질문들이었습니다.

packet이 grounded한가
track framing이 실제 work product를 바꾸는가
level 2와 level 5가 실질적으로 다르게 느껴지는가
reviewer가 여전히 올바른 pass/revise 판단을 하는가
composed sprint가 curriculum에 속한 것처럼 느껴지는가, 아니면 옆에서 둥둥 떠다니는가

이 loop는 real problems를 드러냈습니다.

Weak revise submissions인데도 여전히 너무 강한 경우.

Tracks를 바꾸면 audience framing이 무너지는 경우.

겉으로는 말이 되지만, 다른 learners의 다른 trust questions에 답하지 못하는 measurement packets.

제게 꽤 humbling했던 순간 중 하나는, UI에서 "꽤 괜찮아 보이는" 무언가가 stricter question 하나에 바로 무너질 수 있다는 걸 반복해서 본 일이었습니다. Packet은 매끄럽게 읽히는데도 여전히 너무 generic할 수 있었습니다. Revise case는 plausible해 보여도 여전히 너무 쉬울 수 있었습니다. 제 ego에는 꽤 useful했습니다.

그래서 저는 이 부분이 그렇게 중요했다고 생각합니다.

System이 좋아진 건 제가 좋은 prompt 하나를 찾았기 때문이 아니었습니다.

Users 앞에서 fail하기 전에, eval harness 안에서 먼저 제 앞에서 fail할 수 있었기 때문입니다.

실제 learning의 상당 부분은 4월 8일부터 10일까지의 tight loop 안에서 일어났습니다.

schema groundwork
composed sprint lifecycle
tagged knowledge rebuild
retrieval gate
composition calibration
full eval pass
integration coverage
live flow에서의 browser QA

이 sequence는 중요합니다.

이건 기적 한 번이 아니었습니다.

통제된 loop였습니다.

4. Trust가 걸린 surfaces는 진짜여야 했다

이 지점 역시 real products가 demos와 갈라지는 곳입니다.

다음이 안 되면, 아무도 당신의 AI layer가 얼마나 elegant한지 신경 쓰지 않습니다.

email confirmation이 깨진다
Google sign-in이 flaky하다
user가 auth loop에 갇힌다
abuse controls가 없다
account hardening이 뒤늦은 덧붙임처럼 보인다

Prova에서는 credibility layer에 결국 이런 것들이 들어갔습니다.

사람을 올바른 product flow로 돌려보내는 email confirmation
Google SSO
optional app-based two-factor auth (TOTP MFA)
auth와 assessment에 대한 Turnstile protection

이런 종류의 일은 operational하고 boring하게 들려서 보통 자랑하지 않습니다.

저는 그게 실수라고 생각합니다.

Products가 trust를 얻거나 조용히 잃는 곳은 바로 operational하고 boring한 지점입니다.

5. Billing은 imaginable한 것이 아니라 testable해야 했다

저는 monetization을 마치 Stripe screenshot 한 장만 있으면 해결될 일처럼 말하는 product builders를 점점 더 skeptical하게 보게 됩니다.

Billing은 아주 빨리 real해집니다.

질문은 단지 이게 아닙니다.

"기술적으로 누군가 pay할 수 있는가?"

질문은 이것들이기도 합니다.

trial state 동안 무슨 일이 일어나는가
webhook state가 늦게 도착하면 어떻게 되는가
자신의 revenue surface 위에서 theater를 하지 않고 어떻게 safely test할 것인가
나중에 system을 덜 reliable하게 만들 one-off exceptions를 invent하지 않고 전체 flow를 어떻게 verify할 것인가

지금 Prova에는 real subscription flow와, safer billing verification을 위한 internal QA checkout path가 있습니다. 사소하게 들릴 수 있습니다. 전혀 아닙니다. Product가 serious해질수록, commercial logic를 스스로 속이지 않고 test할 수 있는 길이 더 필요해집니다.

6. Operations는 product의 일부가 되어야 했다

Prova가 제게 real하게 느껴졌던 순간 중 하나는, 이걸 기존 site 안에 숨겨 둔 feature가 아니라 별도의 operational system으로 다뤄야 한다는 사실이었습니다.

Separate production system.

Separate Supabase project.

Separate Vercel project.

Separate auth configuration.

Separate billing setup.

Separate release gates.

이 문장은 sexy하지 않습니다.

하지만 아마 가장 중요한 문장일 겁니다.

Products는 UI layer에서만 깨지지 않기 때문입니다. Systems가 맞닿는 곳, assumptions가 새는 곳, environments가 drift하는 곳, 누군가 "launch하고 나서 고치자"고 말하고 결국 그 after-launch version이 제대로 오지 않는 곳에서 깨집니다.

저는 Prova를 작업할수록 boring한 operational sentences를 더 존중하게 됐습니다.

당신의 AI product를 빠르게 pressure test하고 싶다면, 이렇게 물어보면 됩니다.

model이 dynamic해질 때 무엇이 standard로 fixed되어 있는가
output을 grounded하게 붙들어 주는 retrieval은 무엇인가
user보다 먼저 fake personalization을 잡아내는 eval은 무엇인가
내일 당장 나를 민망하게 만들 auth, billing, state edge는 무엇인가

이 질문들에 대한 답이 아직 fuzzy하다면, 그 product는 아직 system보다 demo에 더 가깝습니다.

정말로 중요한 proof

저는 productization을 추상적으로만 말하고 싶지 않습니다. 그러면 실제보다 더 philosophical하게 들리기 쉽기 때문입니다.

정말 중요한 proof는 "내가 몇 개의 migrations를 썼는가?"가 아닙니다.

정말 중요한 건 지금 real user를 위해 무엇이 작동하느냐입니다.

이 soft-launch phase에서, product는 이제 credibly 이렇게 말할 수 있습니다.

email signup과 confirmation이 작동한다
Google SSO가 작동한다
optional TOTP MFA가 작동한다
downloadable resources와 signed downloads가 작동한다
sprint submission과 AI review가 production에서 작동한다
Stripe checkout handoff가 작동한다

이게 buyer-facing proof입니다.

그 아래에는 repo와 rollout work가 보여주는 system proof도 있습니다.

current production schema bootstrap까지 17개의 Supabase migrations가 적용되었다
composition retrieval을 위해 4,390개의 production knowledge-base rows가 publish되고 tag되었다
38개의 downloadable resources가 publish되었다
tagged retrieval gate가 untagged baseline을 이겼다
full 18-case composition eval suite가 gate를 통과했다
billing verification을 위한 safer internal QA checkout path가 있다

저는 이 숫자들로 바쁨을 과시하려는 게 아닙니다.

제가 아직 갖고 있지 않은 것은 meaningful batch of users로부터의 broad external proof입니다. "이게 내 outcomes를 바꿨다"라고 말해 주는 proof 말입니다. 아직은 너무 이르고, 저는 그걸 fake하고 싶지 않습니다.

이 숫자들을 적는 이유는, launch language로만 이야기하면 "idea를 product로 바꾼다"는 것이 실제로 무슨 뜻인지 너무 쉽게 과소평가하게 되기 때문입니다.

중요한 건 숫자 자체가 아닙니다.

그 숫자들이 무엇을 represent하느냐입니다.

sprint system이 decorative한 상태를 벗어났다
retrieval이 fuzzy한 상태를 벗어났다
evaluation이 performative인 상태를 벗어났다
product state가 신뢰할 만큼 durable해졌다

Invisible work는 여전히 work입니다.

그리고 대체로 더 어려운 work입니다.

이것이 제 머릿속을 어떻게 바꿨는가

저는 여전히 AI tools가 중요하다고 생각합니다. 당연히 중요합니다.

Codex는 이번 push에서 competent하고 careful하고 methodical하게 느껴졌기 때문에 useful했습니다. 감정적인 theater 없이 engineering work를 밀어 나가게 도와줬습니다. Claude는 일이 더 taste-heavy하고 creative해질 때 여전히 제게 더 잘 맞습니다.

하지만 Prova는 저를 더 중요한 결론으로 밀어 넣었습니다.

AI는 implementation을 accelerate할 수는 있지만, product boundaries, sequencing, credibility, operational truth에 대한 judgment의 필요를 없애 주지는 않습니다.

그 judgment가 여전히 일입니다.

Landing page는 product가 아닙니다.

이름 붙은 concept는 product가 아닙니다.

Chat interface는 product가 아닙니다.

Generated component는 더더욱 product가 아닙니다.

제게 어떤 것이 product처럼 느껴지기 시작하는 지점은 visible experience 주위에 invisible architecture가 세워질 때입니다. Real users가 들어와서, pay하고, progress하고, 막히고, recover하고, work를 submit하고, 자신이 보는 state를 trust할 수 있는 순간, 더 이상 demo를 가지고 노는 게 아닙니다. Promises를 만들고 있는 겁니다.

그리고 저는 promises가 바로 product building이 serious해지는 지점이라고 생각합니다.

이게 제게 더 useful한 April lesson이다

저는 여전히 May 2, 2026에 full 30-day Codex verdict를 내야 하고, 그날 publish할 생각입니다.

그 post는 cost timeline, limits story, Claude에서 무엇이 그리웠는지, 제 day-to-day working model에서 무엇이 바뀌었는지를 말하기에 맞는 곳일 겁니다.

하지만 Prova는 이미 tool comparison보다 더 오래 남을 무언가를 제게 가르쳐 줬습니다.

AI product building에서 truly interesting한 부분은 대개 demo가 아닙니다.

당신의 system이 users에게 real promises를 하기 시작하는 순간, 그리고 그 promises 가운데 얼마나 많은 것이 generated code 바깥에 살고 있는지를 깨닫는 순간이 더 interesting합니다.

저는 이제 그 부분을 훨씬 더 존중합니다.

그리고 honestly, 더 많은 builders가 이 부분을 이야기해야 한다고 생각합니다.

자주 받는 질문

Prova는 무엇인가요?

Prova는 marketers와 advertising professionals를 위한 structured AI builder program입니다. AI tools를 쓰는 단계에서 벗어나 real workflows, pilots, operating systems를 만들고 싶은 사람들을 위한 프로그램이죠. Product terms로 말하면 assessment, onboarding, sprint progression, review logic, resources, billing, auth, product state가 함께 작동하는 것이며, 하나의 AI chat box가 시스템 전체인 척하는 구조가 아닙니다.

Prova에서 composed sprint는 무엇인가요?

Composed sprint는 current authored catalog 바깥에 있는 real learner gap을 위해 generated되는 sprint packet입니다. 중요한 constraint는 model이 standard를 혼자 invent하지 않는다는 것입니다. Packet은 dynamic하지만, submission schema와 review rubric은 여전히 authored template sprint에서 옵니다.

Demo 이후에는 왜 AI product building이 더 어려워지나요?

Real users가 signup하고, pay하고, errors에서 recover하고, work를 submit하고, 자신이 보는 state를 trust할 수 있게 되는 순간 product는 promises를 만들기 시작합니다. 그 시점부터는 auth, retrieval quality, evals, billing, operations처럼 AI layer 주변의 invisible systems가 demo의 impressive first output보다 더 중요해집니다.

지금 AI로 무언가를 만들고 있다면, 저는 정말 궁금합니다.

당신의 project가 uncomfortable할 정도로 real하게 느껴지기 시작한 첫 순간은 언제였나요? Demo가 promise가 되는 그 순간 말입니다.

여기까지 적겠습니다.

Cheers, Chandler