4월에, 나는 Prova가 진짜처럼 느껴지게 만든 것에 대해 썼다: 스프린트 엔진, 과금, 평가, 데모와 제품을 구분하는 지루한 운영 작업.
그 글은 내가 발행했을 때는 맞았다. 내가 설명한 스프린트 우선 아키텍처——작성된 스프린트, 루브릭 리뷰, 적응형 라우팅, Operator와 Builder 경로——는 진짜로 작동하고 있었다. 엔진은 맞았다.
내가 아직 몰랐던 것은 그 위에 겹쳐진 커리큘럼이 여전히 틀렸다는 점이었다.
데모에서 잡아낼 수 있는 종류의 틀림이 아니었다. 모든 루브릭을 작성하고, 모든 사용자 경로를 추적하고, 5월 중순까지 아무도 나에게 강요하지 않았던 질문을 던진 후에야 드러나는 종류의 틀림이었다: 무료 챗봇이 이것을 복제하기 어렵게 만드는 것은 정확히 무엇인가?
5월 중순부터 6월 말까지, 커리큘럼은 두 번 재구축되었다. 매번, 나는 이전에 확신했던 것을 교체했다. 각 재작성이 실제로 무엇에 관한 것이었는지 여기 있다.
3레인 아키텍처 (5월 26일–6월 1일)
5월 말까지, 제품에는 문제가 있었다. 33개의 스프린트가 있었고, 세 개의 전혀 다른 대상——워크플로를 재설계하는 오퍼레이터, 첫 유용한 슬라이스를 출시하려는 빌더, 팀을 변혁하려는 리더——가 9개 중 7개의 스프린트를 공유하고 나머지 두 개를 "트랙"이라고 부르고 있었다. 그것은 메뉴였지, 척추가 아니었다.
넓이는 해자가 아니다.
그래서 나는 엄격한 답변처럼 느껴지는 것을 구축했다: 공유 Layer 0 기반 위에 세 개의 대상 레인(Operator, Builder, Leader)이 각자 전용 스프린트를 가진 계층형 아키텍처, 모두 코스의 16개 템플릿과 출판된 말뭉치에서 소싱된 것. 5개 유닛 유형에 걸친 38개 유닛. 개념, 연습, 스프린트, 프로젝트, 체크포인트——각각 다른 완료 의미론을 가진.
종이 위에서는, 진짜 커리큘럼처럼 보였다.
망가진 것은 개별 스프린트가 아니었다. 그 모든 것 아래의 구조적 가정이었다: 더 많은 레인과 더 많은 스프린트가 제품을 더 방어 가능하게 만든다는 것.
그렇지 않다.
해밀턴 헬머의 7 Powers 프레임워크가 이를 명시적으로 명명한다. 힘은 장벽에서 나온다——경쟁자가 단순히 하기로 결정하는 것만으로는 복제할 수 없는 구조적 이점. 경로에 스프린트를 추가하는 것은 장벽이 아니다. 운영 표면적이다. 범용 챗봇은 넓이를 마찰 없이 즉시 맞춘다.
3레인 모델은 커버리지를 추가했다. 깊이를 추가하지 않았다. 나는 잘못된 것을 구축했고, 아키텍처가 배포되고 모든 스프린트가 작성될 때까지 그것을 보지 못했다.
나는 3레인 모델을 위해 24개의 새로운 스프린트를 작성했고, 코스의 템플릿과 출판된 말뭉치에서 소싱했다. 아키텍처는 종이 위에서 엄격해 보였다. 나는 그것이 자랑스러웠다.
레인 시스템은 출시된 같은 주에 폐기되었다.
하나의 규칙 (6월 2일–22일)
두 번째 재작성은 스프린트에서 시작되지 않았다. 전략 질문에서 시작되었다.
나는 앉아서 물었다: 만약 Prova의 유일한 방어 가능한 엣지가 수평적 AI 도구가 구조적으로 채택할 수 없는 것이라면, 그 엣지는 무엇일까?
답은 세 개의 상호 강화 레이어에 착륙했다:
수직적 깊이(쐐기). 실제 측정과 의사결정 게이트를 갖춘 브리프 문서화된 캠페인 워크플로를 광고 업계 표준으로 출시하는 마케터. 그것은 챗봇이 프롬프트에서 생산할 수 있는 것이 아니다.
스캐폴딩(활성화). 대부분의 마케터는 무엇을 물어야 할지 모른다. 제품은 그들이 "AI가 이걸 도와줄 수 있을 것 같은데 어디서 시작해야 할지 모르겠어"라는 지점에서 만나, 범위 설정, 순서 지정, 표준 설정의 작업을 해야 한다.
검증된, 표준에 따라 출시된 작업(증명). 모든 스프린트는 실제 루브릭에 대해 검토된 제출로 끝난다. "좋아 보이나"가 아니다. "문법적으로 깨끗한가"도 아니다. 대신: 이 산출물이 에이전시 오퍼레이터나 미디어 바이어가 실제로 사용할 것에 견디는가?
그 세 레이어로부터, 아키텍처는 극적으로 단순화되었다.
3레인 구조는 하나의 루프 문법으로 대체되었다: 현실 점검 → 브리프 → 계획 → 실행/구축 → 결정 게이트 → 캡스톤.
세 경로 모두에 동일한 문법. 경로마다 다른 산출물. 오퍼레이터는 캠페인 워크플로 파일럿을 실행한다. 빌더는 작동하는 제품 슬라이스를 출시한다. 리더는 이해관계자 비즈니스 케이스와 운영 모델 청사진을 구축한다.
깊이는 캡스톤 이후에만 추가된다: 에이전시 확장, 제품 깊이 확장, 조직 변화 확장. 사용자가 더 원하면, 먼저 척추를 통과해서 얻는다.
넓이는 사라지지 않았다. 증거 트리거 우회 모듈로 강등되었다——리뷰어가 작성된 척추가 현재 다룰 수 없는 격차를 감지할 때만 나타나는, 짧고 할당된 스프린트. 데이터 인프라 감사. 벤더 스택 결정. 테이블 스테이크 진단. 그것들은 여전히 존재한다. 단지 제품이 그것들이 필요하다는 증거를 가지고 있지 않는 한 당신이 가는 경로가 아닐 뿐이다.
이를 공식화한 단일 커밋은 6월 11일의 feat!: replace dual curriculum routing with unified path sequences였다. !는 파괴적 변경을 나타낸다. primary_path(operator, builder, leader)가 learning_track을 단일 라우팅 축으로 대체했다. DISABLE_BRIEF_DRIVEN_RESET_PATH라는 기능 플래그가 QA 게이트가 통과될 때까지 전환을 격리했다. 7개의 레거시 스프린트가 시퀀싱에서 은퇴했지만 이력으로 볼 수 있게 유지되었다.
캡스톤은 기능이 아닌 구조가 되었다. 그것이 전환 비용 메커니즘이다. 수평적 도구는 괜찮은 스프린트 패킷을 생성할 수 있다. 지속적인 리뷰어 이력을 가진 광고 업계 표준에 대해 검토된, 검증된, 출시된 산출물의 포트폴리오는 생성할 수 없다.
새로운 스프린트나 경로를 작성하기 전에, 물어라: 이것이 7 Powers 중 어떤 것을 강화하는가, 그리고 그 장벽은 무엇인가? 정직한 답이 "커버리지를 추가한다"이고 장벽이 없다면, 그것은 챗봇이 이미 커버하는 운영 표면적이다——구축하지 마라.
—— 2026년 6월 5일, Prova 커리큘럼 전략 문서
그 규칙이 3레인 아키텍처를 무너뜨렸다. 잘 쓰였지만 구조적으로 중복된 스프린트들을 무너뜨렸다. 내가 미루고 있던 기능이었던 캡스톤을 구조적 요구사항으로 바꾸었다. 그리고 그것은 내가 3월부터 물었어야 할 질문이다.
4월과 6월 사이의 차이
4월에 출시한 제품은 엔진이 맞았다. 6월에 확정한 제품은 척추가 맞았다.
엔진——작성된 스프린트, 루브릭 리뷰, 적응형 라우팅, 구성 스프린트 수명 주기——은 필요했다. 작동하는 스프린트 엔진이 없는 커리큘럼 아키텍처는 강의계획서일 뿐이다.
그러나 방어 가능한 척추가 없는 스프린트 엔진은 무료 도구가 이미 맞추고 있는 기능 목록일 뿐이다.
두 제품의 차이는 더 많은 코드가 아니었다. 더 나은 질문이었다. "이것이 어떤 Power를 강화하는가?"가 나로 하여금 자랑스러워하던 것들을 죽이게 했고, 선택 사항으로 취급하던 것들을 격상시키게 했다.
6월의 아키텍처가 완성되었다고 주장하는 것은 아니다. 제품은 거의 완성되지 않는다. 하지만 지금 학습 제품을 구축하고 있다면, 다음 스프린트를 쓰기 전에 이 질문을 물어볼 가치가 있다. 넓이는 추가하기 가장 쉬운 것이고, 범용 AI가 가장 먼저 상품화할 것이기 때문이다.
추가 맥락: Prova는 마케터와 광고 전문가를 위한 내 코칭 제품으로, Operator 경로(워크플로 재설계)와 Builder 경로(첫 유용한 슬라이스 출시)가 있다. prova.chandlernguyen.com에서 이용 가능하다. 7 Powers 프레임워크는 해밀턴 헬머의 책 7 Powers: The Foundations of Business Strategy에서 온 것이다——이 글은 프레임워크를 참조하지만 가르치지는 않는다; 책이 원천이다.
빠르게 움직이는 AI 레이어 위에 구조화된 제품을 구축하고 있다면, 진심으로 궁금하다: 당신의 아키텍처에서 무료 도구가 프롬프트를 추가하는 것만으로는 복제할 수 없는 한 가지는 무엇인가?
오늘은 여기까지.
건배, Chandler