AI 작업의 맥락 단절과 '바이브 솔루셔닝' — Rocket 1.0 직접 사용기

핵심 메시지

• 대부분의 AI 워크플로는 같은 지점에서 무너진다. 리서치는 한 앱, 메모는 다른 앱, 코드는 또 다른 곳에 있어 실제 작업이 '여기저기를 이어 붙이는 일'이 되어 버린다.
• 발표자는 Rocket 1.0에서 모든 작업이 채팅·스레드가 아니라 '프로젝트' 안에 담기는 설계를 핵심으로 꼽는다. 프로젝트가 리서치·추적·빌드·협업자를 모두 담는 그릇이 되어 모든 도구가 같은 맥락을 공유한다.
• 리서치 기능 'Solve'는 퍼플렉시티식 사실 나열과 달리 시장 개요·기존 플레이어·격차 분석과 함께 '만들지 말지'에 대한 입장을 담은 보고서를 내놓고, 그 결과를 4초 만에 PPT로 내보낸다.
• 한 문장만으로 'Solve 보고서를 토대로 MVP를 만들라'고 지시하자, 빌드는 리서치 문서의 구조를 그대로 반영한 대시보드를 만들어 냈다. 다만 출력은 바로 출시할 수준이 아니라 2~3일치 작업을 압축한 '뼈대'다.
• 같은 프로젝트의 다른 작업도 앞선 작업의 맥락을 그대로 안다. 랜딩 페이지는 리서치의 구매 신호·격차 분석에서 헤드라인과 가격 구조를 끌어왔고, 팀원은 인계 문서 없이 프로젝트에 들어와 산출물 자체로 맥락을 파악한다.

쉽게 이해하기

영상은 'AI 워크플로는 대개 같은 곳에서 무너진다'는 진단으로 시작한다. 리서치는 한 앱, 메모는 다른 앱, 코드는 또 다른 곳에 흩어져 있어 실제 작업이 모든 것을 이어 붙이는 일로 변한다는 것이다. 발표자는 새 AI 에이전트 프레임워크를 추적·벤치마크하고 결과를 한곳에 정리하는 내부 모니터링 대시보드를, 리서치부터 경쟁 분석·MVP 빌드·랜딩 페이지·팀 인계까지 전부 Rocket 1.0 안에서 만들어 본다. Rocket은 자사 플랫폼을 '바이브 솔루셔닝을 위한 엔드투엔드 플랫폼'이라 부른다.

가장 중요한 점은 기능이 아니라 설계 결정이라고 발표자는 말한다. 모든 것이 채팅이나 스레드가 아니라 '프로젝트' 안에 담긴다는 것이다. 클로드나 ChatGPT에서는 대화 하나하나가 섬이어서 새 채팅을 열면 모델이 아무것도 모르지만, 이 도구에서는 프로젝트가 리서치·추적·빌드·협업자를 담는 그릇이 되고 그 안의 모든 도구가 같은 '두뇌'를 공유한다.

리서치 기능 'Solve'에 그는 'AI 에이전트 프레임워크 시장을 모니터링하는 도구를 만들 가치가 있는지, 진짜 격차인지 아니면 너무 작아 의미 없는 함정인지 말해 달라'는 까다로운 프롬프트를 넣는다. 결과는 퍼플렉시티식 세 문단·열 개 인용이 아니라, 시장 개요·기존 플레이어·격차 분석·구매 신호와 함께 '만들어라/접어라' 권고와 그 답을 바꿀 세 가지 조건을 담은 구조화된 문서였다. 게다가 'export to PPT'를 누르자 보통 3시간 걸리던 덱이 4초 만에 만들어졌다.

'Track'은 경쟁 인텔리전스 계층으로, URL을 주면 모니터링하다가 가격 페이지 변경·새 기능·채용 신호처럼 의미 있는 변화가 생기면 알려 준다. 발표자가 앤트로픽·오픈AI·퍼플렉시티 등 다섯 개 URL을 넣자, 보고서는 단순 변경 로그가 아니라 포지셔닝·제품·가격·채용 신호로 분류해 '무엇이 바뀌었고 당신이 만드는 것에 비춰 왜 중요한지'까지 정리했다. 'Build'에서는 '리서치 보고서를 토대로 MVP를 만들라'는 한 문장만으로, 격차 분석에서 아키텍처를 끌어와 프레임워크 레지스트리·벤치마크 러너·추천 패널을 갖춘 대시보드를 만들어 냈다.

발표자는 빌드 결과가 장난감 수준이 아니라 제대로 된 데이터 테이블 패턴과 큐 상태, 설정 서랍을 갖췄고 묻지도 않은 데이터베이스·인증·분석 연동까지 더했다고 평가한다. 다만 바로 출시할 코드는 아니며 벤치마크 로직은 뼈대 수준이라고 분명히 한다. 같은 프로젝트에서 '랜딩 페이지를 만들라'고만 했을 때도 헤드라인은 구매 신호에서, 가격 구조는 리서치 권고에서 끌어왔다. 즉 두 번째 작업이 첫 작업의 모든 맥락을 알고 있었다. 그는 이를 '바이브 코딩은 실행에서 시작하지만 바이브 솔루셔닝은 그 앞, 즉 그동안 제품으로 빠져 있던 사고(thinking) 계층에서 시작한다'고 정리하며, 순수 실행 엔진으로는 여전히 클로드 코드가 낫다고 덧붙인다.

주요 인사이트

• AI 작업의 진짜 병목은 모델 성능이 아니라 도구 사이에서 맥락이 끊기는 것이다. 작업이 '이어 붙이기'가 되는 순간 생산성이 새어 나간다.
• 채팅이 아니라 '프로젝트'를 단위로 삼는 설계는 사소한 용어 차이가 아니다. 모든 도구가 같은 맥락을 공유하면 매번 배경을 다시 설명하는 부담이 사라진다.
• 좋은 리서치는 사실 더미가 아니라 '입장'을 제시하는 것이다. Solve가 만들/접을 권고와 그 판단을 바꿀 조건을 함께 내놓는 점이 단순 검색과의 결정적 차이다.
• 생성형 빌드 결과는 출시본이 아니라 2~3일치 작업을 압축한 '뼈대'로 보는 것이 현실적이다. 어댑터 로직 등 핵심은 여전히 사람의 몫이다.
• 여러 도구를 같은 맥락 위에 묶는 것은 개별 기능을 복제하는 것과 다른 종류의 엔지니어링 난제다. 발표자는 이 '맥락 누적'을 경쟁자가 가장 따라 하기 어려운 부분으로 본다.

자주 묻는 질문

관련 AI 소식