AI는 작동하는 데모를 만드는 비용을 획기적으로 낮추었습니다.

이는 유용합니다. 하지만 동시에 위험하기도 합니다. 그럴듯한 인터페이스(interface)가 제품의 실질적인 증거가 나타나기도 훨씬 전에 진전이 이루어지고 있다는 착각을 불러일으킬 수 있기 때문입니다.

App Foundry에서 우리는 생성을 쉬운 부분으로 취급합니다. 어려운 부분은 무엇이 존재할 가치가 있는지 결정하고, 증거를 일관된 제품 계약(product contract)으로 전환하며, 낯선 사람이 경험하게 될 실제 여정(live journey)을 증명하는 것입니다.

데모는 제품이 아닙니다

프로토타입(prototype)은 익숙한 패턴들이 서로 잘 맞물린다는 것을 증명할 수 있습니다. 하지만 사람들이 그 결과물을 필요로 한다는 것을 증명하지는 못합니다.

제품은 현실과의 접촉에서 살아남아야 합니다:

• 사람들이 그것을 찾을 수 있는가?
• 맥락(context) 없이도 이해할 수 있는가?
• 핵심 과업(core task)을 완수할 수 있는가?
• 오류(error)로부터 깔끔하게 복구되는가?
• 다루는 데이터를 보호하는가?
• 개발자 상태(developer state)가 없는 깨끗한 브라우저에서도 여전히 작동하는가?

이것이 우리의 워크플로(workflow)가 "앱을 빌드하자"에서 시작하지 않는 이유입니다. 우리의 워크플로는 왜 이 앱이 존재해야 하는지에 대한 근거를 찾는 것에서 시작합니다.

이미 수요가 존재하는 곳에서 시작하십시오

새로움은 유혹적입니다. 하지만 기존의 수요는 측정 가능합니다.

우리는 사람들이 이미 검색하고 사용하는 카테고리를 찾은 다음, 현재 도구들에 대한 불만 사항을 연구합니다. 후보군은 가시적인 수요, 확립된 대안, 도달 가능한 관객, 방어 가능한 이름, 그리고 선택을 바꿀 만큼 의미 있는 개선 사항을 갖추어야 합니다.

증거가 없는 매력적인 아이디어는 아이디어로 남을 뿐입니다.

이것이 성공을 보장하지는 않습니다. 다만 생성을 수요로 오해하는 것을 방지할 뿐입니다.

연구를 제품 계약으로 전환하십시오

기회가 연구를 통과하면, 그것은 계약이 됩니다.

계약은 다음을 정의합니다:

• 사용자 및 수행할 과업 (job)
• 핵심 여정의 시작과 끝
• 차별화된 기능 (differentiating features)
• 상업적 모델 (commercial model)
• 프라이버시 경계 (privacy boundary)
• 검색 의도 (search intent)
• 출시를 차단하는 조건들

이는 기능 목록(feature list)보다 더 엄격합니다. 이는 모든 전문가에게 도전할 수 있는 안정적인 대상을 제공합니다.

디자인(Design)은 사용자를 조용히 변화시킬 수 없습니다. 엔지니어링(Engineering)은 여정을 조용히 좁힐 수 없습니다. 마케팅(Marketing)은 제품이 증명하지 못한 것을 약속할 수 없습니다. 제품이 변한다면, 계약(contract)이 먼저 변해야 합니다.

생성과 검증의 분리

파운드리(foundry)는 하나의 전능한 어시스턴트(assistant) 대신 전문화된 에이전트(agent)들을 사용합니다.

리서치 에이전트(Research agents)는 증거를 수집하고 검증합니다. 프로덕트 에이전트(Product agents)는 이를 계약(contract)으로 전환합니다. 디자인 에이전트(Design agents)는 상호작용(interaction)과 시각적 시스템(visual system)을 정의합니다. 엔지니어링 에이전트(Engineering agents)는 이를 구현합니다. 보안(Security), 접근성(accessibility), SEO, 그리고 적대적 에이전트(adversarial agents)는 사용자가 하기 전에 가설(assumptions)을 깨뜨리려 시도합니다.

어떤 단계도 자신의 작업이 증명되었다고 스스로 표시할 수 없습니다.

이러한 분리는 참여하는 모델(model)의 수보다 더 중요합니다. 보안 실패는 출시 노트(launch note)가 될 수 없습니다. 깨진 클린 로그인(clean-login) 흐름은 "대체로 작동함"이 될 수 없습니다. 기존 쿠키(cookie)가 있어야만 올바르게 동작하는 페이지는 브라우저 대응(browser proof)이 된 것이 아닙니다.

이견(Disagreement)은 시스템의 일부입니다.

거절을 성공적인 결과로 만들기

대부분의 자동화는 완료(completion)를 향해 편향되어 있습니다. 구축하도록 요청받았기에, 구축합니다.

유용한 제품 시스템은 중단하는 능력 또한 동일하게 갖추어야 합니다.

수요가 약하거나, 브랜드가 이미 점유되었거나, 인프라(infrastructure) 비용이 너무 높거나, 고객 획득(acquisition)이 비현실적이거나, 제안된 개선 사항이 중요하지 않을 정도로 작을 때 기회는 실패할 수 있습니다. 제품은 나중에 실제 여정(live journey)이 신뢰할 수 없거나, 접근할 수 없거나, 안전하지 않거나, 불완전하기 때문에 실패할 수 있습니다.

이러한 것들은 나쁜 출시(release)를 방지할 때 좋은 결과가 됩니다.

거절된 작업은 감사 추적(audit trail)으로서 보존됩니다. 대시보드(dashboard)를 생산적으로 보이게 하려고 삭제되지 않으며, 대기열(queue)로 조용히 재활용되지도 않습니다.

낯선 사람으로서 실제 도메인을 테스트하기

단위 테스트(Unit tests)와 빌드 체크(build checks)는 필수적입니다. 하지만 제품이 고장 난 상태에서도 통과할 수 있습니다.

최종 관문은 깨끗한 브라우저에서 배포된 도메인(deployed domain)을 사용합니다. 이는 첫 방문, 관련 시 계정 생성, 전체 도구 여정(tool journey), 실패 상태(failure states), 새로고침(reloads), 반응형 레이아웃(responsive layouts), 메타데이터(metadata), 아이콘(icons), 분석 데이터 전달(analytics delivery), 그리고 사용자가 실제로 얻고자 하는 결과물을 확인합니다.

기존 세션은 편의성이 아닌 오염(contamination)으로 간주됩니다.

질문은 간단합니다. 구현 방식에 대한 지식이 전혀 없는 사람이 와서 성공할 수 있는가?

감시 없이 결과 측정하기

출시 후, 우리는 의도적으로 아주 작은 규모의 쿠키 없는(cookieless) 이벤트 세트를 측정합니다:

• 페이지 뷰 (page views)
• 도구 시작 (tool starts)
• 성공적인 완료 (successful completions)
• 실패한 여정 (failed journeys)

검색 성능과 수익은 별도로 추적됩니다.

이것만으로도 제품을 개선하기 위한 질문에 답하기에 충분합니다. 사람들이 제품을 찾고 있는가? 시작하는가? 완료하는가? 어디에서 이탈하는가?

더 개인적인 데이터를 수집하는 것은 반드시 더 나은 판단을 더해주지 않으면서 위험만 가중시킬 뿐입니다.

속도는 품질의 기준을 높여야 합니다

AI는 더 많은 소프트웨어를 생산하는 것을 가능하게 합니다. 이에 대한 당연한 반응은 더 많이 출시(ship)하는 것입니다.

더 나은 반응은 출시되는 모든 것에 더 많은 것을 요구하는 것입니다.

우리의 작업 원칙은 간단합니다: 기존의 수요에서 시작하고, 제품을 선택해야 할 이유를 만들며, 생성(creation)과 검증(verification)을 분리하고, 출시가 축적된 증명의 결과가 되도록 만드는 것입니다.

결과물은 AI 앱처럼 느껴져서는 안 됩니다. 자신의 자리를 쟁취한 집중력 있는 도구처럼 느껴져야 합니다.

정식 버전을 읽고 라이브 파운드리(live foundry)를 탐색해 보세요: Software Is Cheap. Proof Is Not.