AI 모델의 성능이 급격히 바뀌는 시대에는 기존 제품 로드맵을 안정적으로 실행하는 일과 새로운 가능성을 탐색하는 일을 한 팀에 동시에 맡기기 어렵습니다. Every의 공동창업자이자 CEO인 댄 시퍼는 이를 해결하기 위해, 소수의 인원으로 빠르게 실험하는 제품 연구소(Labs) 와 기존 고객을 위한 제품을 고도화하는 제품팀을 분리하자고 제안합니다. 핵심은 대부분의 실험이 실패해도 괜찮게 만들고, 실제 업무에서 살아남은 소수의 아이디어만 제품의 중심으로 옮기는 것입니다.

1. AI가 바꿔 놓은 제품 개발의 전제

댄 시퍼는 AI가 단순히 기능을 조금 개선하는 수준이 아니라, 제품을 만드는 방식 자체를 흔들고 있다고 말하며 발표를 시작합니다. 새로운 모델이 출시될 때마다 "세상이 또 바뀌었다"고 느껴질 정도로, 이전에는 불가능했던 결과물이 빠르게 현실이 되고 있다는 것입니다.

그는 최근 나온 Fable 5.1과 Astra 6 같은 모델을 예로 듭니다. 단 한 번의 프롬프트를 입력한 뒤 약 네 시간 동안 실행했더니, 역사적으로 정확한 워털루 전투의 3D 시뮬레이션이 만들어졌다고 설명합니다. 또 팀원 한 명은 고객 행동에 관한 논문을 넣고, 수천 명의 고객 에이전트를 컴퓨터에서 시뮬레이션하며 시각적으로 관찰하는 실험을 했다고 합니다.

"명령 하나를 넣고 네 시간 정도 돌렸더니 이런 결과가 나왔습니다. 정말 미친 일이죠."

AI는 영상 작업에도 이미 실용적인 수준으로 들어왔다고 말합니다. Every는 영상을 많이 만들며, Astra가 Adobe Premiere 같은 편집 도구 안에서 실제 편집 작업을 수행할 만큼 충분히 좋아졌다고 평가합니다. 발표에 쓰인 애니메이션 대부분도 Astra가 만들었고, 그는 자신이 애니메이션 탭을 거의 만지지 않았다고 덧붙입니다.

이런 변화 앞에서 제품 리더가 취할 수 있는 반응은 여러 가지입니다. 기존 업무에만 집중할 수도 있고, 고객에게 무엇을 원하는지 물어볼 수도 있으며, 심지어 기존 SaaS 제품을 완전히 다른 종류의 3D 멀티플레이 전략 게임처럼 바꾸고 싶어질 수도 있습니다. 하지만 댄은 어느 하나도 단순한 정답은 아니라고 봅니다. 고객 역시 이런 최신 변화의 가능성을 잘 모르기 때문에, 오히려 회사가 방향을 제시해 주기를 기대하는 경우가 많기 때문입니다.

그래서 그는 약간 농담 섞인 첫 번째 원칙을 내놓습니다. 새로운 AI 모델을 처음 만났을 때 너무 흥분해 회사의 운명을 건 결정을 내리지 말라는 것입니다.

"명상 수련회나 환각 경험, 혹은 처음으로 최첨단 모델을 만난 뒤 30일 안에는 인생을 바꿀 결정을 내리지 마세요."

2. 실행과 탐색은 서로 다른 일이다

댄이 말하는 근본적인 문제는 제품 조직이 한꺼번에 두 가지 상반된 일을 해야 한다는 데 있습니다. 하나는 이미 세운 로드맵을 따라 제품을 안정적으로 만들고 개선하는 실행이며, 다른 하나는 새 모델과 새 인터페이스, 새 사용자 행동을 탐색하는 탐색입니다.

탐색은 다양한 방향으로 퍼져 나가는 일입니다. 여러 모델을 써 보고, 수많은 프로토타입을 만들고, 데모를 보여 주고, 상당수를 버립니다. 반면 실행은 반대 방향입니다. 선택지를 줄이고, 우선순위를 정하고, 계획에 집중하고, 고객이 이해할 수 있는 일관된 제품을 완성합니다.

"새로운 영역을 탐색하려면 발산해야 합니다. 많은 것을 시도하고, 그중 많은 것을 버리게 됩니다."

"반대로 실행은 수렴입니다. 집중하고, 일부를 거절하고, 이미 세운 계획을 해내는 일이죠."

두 방식을 한 팀과 같은 프로세스 안에서 동시에 극대화하려 하면 결국 모두가 산만해진다고 그는 지적합니다. 특히 조직 안에는 신기술을 누구보다 빨리 만져 보고, 주말에도 새 모델로 개인 프로젝트를 해 보는 얼리 어답터가 반드시 존재합니다. 이들은 미래의 가능성을 먼저 보는 사람들인 만큼 매우 소중하지만, 동시에 제품팀 전체를 끊임없이 새로운 방향으로 흔들 수 있는 존재이기도 합니다.

"우리는 이미 미래에 살고 있기 때문에, 여러분의 제품이 어디로 갈 수 있을지 꽤 잘 압니다. 하지만 동시에 우리는 엄청난 방해물이 될 수도 있습니다."

따라서 제품 리더가 풀어야 할 질문은 명확합니다. 조직 안의 얼리 어답터와 일부 선도 고객의 통찰을 활용하되, 나머지 제품팀이 탐색의 소음에 휘말리지 않게 하려면 어떻게 해야 하는가입니다.

3. 작은 연구소로 탐색을 분리하기

댄의 답은 제품 조직 안에 연구소 팀(Labs team) 을 만드는 것입니다. 제품팀은 현재 잘 작동하는 것을 개선하고 규모를 키우는 데 집중하며, 연구소 팀은 다음에 가능해질 일을 탐색합니다. 연구소는 새로운 모델을 시험하고, 데모를 만들고, 낯선 사용 방식을 발견하는 역할을 맡습니다.

이렇게 역할을 나누면 조직은 두 가지 장점을 동시에 확보할 수 있습니다. 제품팀은 기존 고객과 제품 경험을 안정적으로 책임질 수 있고, 연구소는 실패를 두려워하지 않고 미래의 가능성을 탐색할 수 있습니다.

특히 AI 시대에는 이 연구소가 꼭 거대한 별도 조직일 필요가 없다고 말합니다. 한 명만 있어도 충분히 시작할 수 있습니다. 그 사람이 새로운 모델이 나올 때마다 직접 실험하고, 어떤 것이 가능해졌는지 조사한 뒤, 결과를 팀에 가져오면 됩니다. AI 도구가 개인의 생산성을 크게 올려 주기 때문에 작은 팀도 과거보다 훨씬 많은 탐색을 할 수 있다는 논리입니다.

"AI의 멋진 점은 한 사람짜리 연구소 팀도 만들 수 있다는 겁니다."

연구소와 제품팀은 성공 기준부터 다릅니다. 연구소는 만든 것의 약 90%를 버리는 것이 정상입니다. 반면 제품팀은 연구소가 던진 수많은 가능성 가운데 약 10% 정도만 채택해 기존 제품 안에 녹입니다. 이 구조에서는 버려진 실험조차 실패가 아니라, 빠르게 가능성을 확인하고 불필요한 길을 제거한 성과가 됩니다.

그는 Anthropic의 사례를 듭니다. Anthropic Labs 같은 소규모 독립 그룹이 다양한 실험을 수행했고, 그 과정에서 콘텐츠 관련 기능, 스킬, Claude의 설계 요소 등 여러 성공적인 기능과 제품이 나왔다는 것입니다. 사람들이 보지 못한 수많은 실험도 있었지만, 회사는 성공한 아이디어에만 점진적으로 더 투자했습니다.

4. 연구소를 운영하는 네 가지 원칙

아주 작은 팀으로 시작하기

댄은 과거의 "피자 두 판 팀", 즉 8~10명 정도의 팀 규모를 AI 시대에는 "피자 두 조각 팀"으로 바꿔야 한다고 말합니다. 이상적인 연구소 규모는 한두 명입니다. 인원이 늘면 조율 비용이 커지고 관점이 충돌하며, 빠른 탐색의 속도가 사라질 수 있기 때문입니다.

"AI 시대에는 '두 조각 팀'이라고 부르고 싶습니다. 한 명, 많아야 두 명이면 됩니다."

그가 추천하는 조합은 '해적'과 '건축가'입니다. 해적은 다소 혼란스럽고 무질서해 보여도, 가능한 한 빨리 가치 있는 것을 찾아내려는 사람입니다. 여러 아이디어를 만들고 버리며 흥미로운 신호를 포착합니다. 건축가는 그렇게 나온 혼란스러운 시제품을 보고, 이를 아름답고 신뢰할 수 있으며 확장 가능한 시스템으로 바꾸는 사람입니다.

"해적은 어떻게든 가치를 찾아냅니다. 건축가는 그 혼란스러운 시스템을 가치 있고 아름답고 확장 가능한 것으로 바꿉니다."

실제 업무에 직접 써 보기

연구소에서 가장 중요한 일은 제품을 만든 뒤 "이게 좋은가?"라는 질문에 대한 답을 빨리 얻는 것입니다. 이를 위해서는 가능한 한 스스로 제품을 사용해야 합니다. 제품을 실제 업무 흐름에 넣어 보고, 진짜 시간과 비용을 아끼는지, 아니면 그저 신기한 장난감인지 확인해야 합니다.

내부에서 직접 사용하기 어려운 제품이라면, 소수의 얼리 어답터 고객과 촘촘한 피드백 루프를 만들어야 합니다. 중요한 것은 인터뷰에서 긍정적인 반응을 얻는 것이 아니라, 사람들이 반복해서 실제로 쓰는지를 보는 일입니다.

"모든 실험을 실제 업무에 사용해 보세요. 그래야 유용한지, 아니면 그냥 새로워서 흥미로운 것인지 알 수 있습니다."

같은 문제를 여러 방식으로 병렬 실험하기

제품팀은 보통 하나의 문제를 풀기 위해 정렬된 계획을 세우지만, 연구소는 같은 문제를 여러 방식으로 동시에 풀어 봐야 합니다. 겉으로는 중복되고 어수선해 보여도, 새로운 능력이 등장했을 때는 무엇이 가치 있는지 아직 알 수 없기 때문입니다.

서로 다른 사람이 각자의 관점으로 같은 문제를 접근하면, 넓은 미지의 영역을 빠르게 지도화할 수 있습니다. 어떤 방식이 실제로 작동하고, 어떤 방식이 쓸모없는지 더 빨리 알게 됩니다.

버려지는 실험에서도 수익을 얻기

연구소의 실험 90%가 제품으로 이어지지 않는다면, 그 실험들을 그냥 폐기하지 말고 다른 방식으로 가치를 회수해야 합니다. Every는 실험 결과를 외부 콘텐츠로 만들었다고 설명합니다. 무엇을 시도했고 무엇이 성공했으며 무엇이 실패했는지를 공개하면, 콘텐츠 자체가 브랜드와 고객 유입에 도움이 됩니다.

"사람들은 우리가 무엇을 시도했는지 보고 싶어 합니다. 무엇이 통했고 무엇이 통하지 않았는지 말이죠."

또한 실험은 선도 고객 프로그램에도 활용할 수 있습니다. 더 긴밀하게 회사와 함께하고 싶은 고객에게 아직 완성되지 않은 시도들을 먼저 보여 주고, 함께 검증하도록 하면 고객에게도 특별한 가치를 줄 수 있습니다. 동시에 연구소가 발견한 변화와 가능성은 제품팀에 계속 공유해야 합니다. 제품팀이 직접 모든 실험을 수행할 필요는 없지만, 앞으로 제품 전략에 영향을 줄 신호는 알아야 하기 때문입니다.

5. 실험을 제품으로 옮기는 연구 파이프라인

연구소를 만든 뒤의 핵심 과제는 "좋은 실험을 어떻게 제품으로 옮길 것인가"입니다. 댄은 이를 왼쪽에서 오른쪽으로 이동하는 연구 파이프라인으로 설명합니다.

처음에는 연구소가 아주 작은 실험을 대량으로 만듭니다. 대부분은 중단되지만, 일부 가능성 있는 실험은 실제 업무 환경에서 검증됩니다. 그다음 다른 팀원들이 써 보게 하고, 내부 사용이 늘어난다면 얼리 어답터 고객에게 제공할 수 있습니다. 이후 제품팀이 이를 면밀히 검토해 제품 전략과 로드맵 속 위치를 정하고, 정말 준비되었을 때만 고객 전체로 확장합니다.

"다른 팀원들이 쓰기 시작하면, 보통은 얼리 어답터 고객에게 보여 줄 준비가 된 것입니다."

Every 내부의 사례로 그는 편집장 케이트(Kate) 를 소개합니다. 케이트는 뛰어난 편집 감각을 가진 사람이지만, 약 30명으로 커진 팀의 모든 글을 직접 편집하기에는 한계가 있었습니다. 댄은 케이트를 더 채용하기 어려운 이유가 단순한 인력 부족이 아니라, 그녀 특유의 편집 감각을 대체하기 어렵기 때문이라고 말합니다.

그래서 그는 수년간 케이트가 남긴 과거 편집 기록을 활용해 AI가 최신 글을 편집하도록 실험해 왔습니다. 케이트는 종종 이런 메시지를 받았다고 합니다.

"별일은 아닌데, 지난 3년간 당신이 한 모든 글 편집을 올려서 Fable에게 최신 글을 편집해 보라고 했어요."

처음에는 개인 시간에 만든 다소 조잡한 실험이었지만, 성능이 점차 좋아지자 조직 전체가 내부에서 쓰기 시작했습니다. AI 에이전트가 케이트의 과거 수정 방식에 기반해 초안을 검토하고 수정 제안을 하며, 케이트가 이후에 실제로 어떤 변경을 하는지도 다시 학습합니다.

이 시스템이 내부에서 채택되자, 이제 '건축가' 역할의 엔지니어가 등장합니다. 댄은 야닉(Yannick)이라는 엔지니어가 이 혼란스러운 도구를 체계적인 제품으로 바꾸고 있다고 말합니다. 대시보드에는 문서별 제안 수락률, AI가 처리한 뒤에도 케이트에게 남는 작업량, 케이트가 AI의 제안 이후 다시 수정한 내용 등이 표시됩니다. 이를 통해 시스템이 점점 개선되는지 측정할 수 있습니다.

그 결과 케이트가 추가로 해야 하는 편집 작업은 한 달 전보다 12% 줄었다고 합니다. 단순히 "AI가 편집을 해냈다"가 아니라, 실제 업무 부담이 줄었다는 지표를 확보한 것입니다. 이 단계에 이르면 팀은 이 기능이 편집 외의 작업에도 적용될 수 있는지, 그리고 얼리 어답터 고객에게 제공할 수 있는지를 검토하기 시작합니다.

6. 제품 편입의 기준과 장기적 목표

댄은 연구 파이프라인을 정기적으로 검토해야 한다고 강조합니다. Every는 Notion에서 실험들을 추적하고, 매주 회의에서 어떤 실험이 진행 중인지, 무엇이 유망해 보이는지, 무엇이 다음 단계로 이동할지 함께 논의합니다. 이는 연구소와 제품팀이 분리되어 있으면서도 서로 단절되지 않게 만드는 장치입니다.

제품팀은 모든 실험에 뛰어들 필요가 없지만, 어떤 가능성이 현실이 될 경우 제품에 어떤 영향을 미칠지는 미리 생각할 수 있어야 합니다.

"제품팀이 직접 모든 실험을 하느라 산만해지지 않아도, '이게 정말 맞다면 우리 제품에는 어떤 의미일까?'를 생각할 수 있어야 합니다."

아이디어를 다음 단계로 넘길 때는 명확한 기준이 필요합니다. 댄은 특히 다음 질문을 중요하게 제시합니다.

• 사람들이 실제로 사용하는가, 그리고 다시 돌아와 사용하는가
• 기존 방식보다 정말로 10배 더 나은가
• 시간이 지나도 새로움이 아니라 지속적인 가치를 보여 주는가
• 많은 고객에게 제공할 수 있을 만큼 비용 구조가 가능한가

"새로운 것은 아주 흥미롭게 보입니다. 하지만 한 달 뒤에도 정말 더 나은가요?"

"지금 작동한다는 것과, 고객에게 규모 있게 제공할 수 있다는 것은 다른 질문입니다."

최종 목표는 연구소에 멋진 실험을 쌓아 두는 것이 아니라, 검증된 성공을 핵심 제품에 통합하는 것입니다. 그는 OpenAI의 Codex를 이 방식의 좋은 예로 봅니다. Codex는 메인 애플리케이션 밖에서 작은 팀이 개발했으며, 그동안 OpenAI 내부의 여러 팀은 미래의 프로그래밍이 IDE 안에서 이뤄질지, CLI에서 이뤄질지 등 다양한 방향을 실험했습니다.

그 실험의 결과로 Codex 데스크톱 앱이 2026년 2월에 출시됐고, 빠르게 성장한 뒤 결국 ChatGPT에 통합되어 핵심 기반 중 하나가 되었다고 설명합니다. 작은 실험팀이 대규모 사용자 기반의 핵심 제품 경험에 영향을 미친 사례라는 것입니다.

"현재 버전을 확장하면서도, 동시에 제품의 다음 세대를 만들 수 있습니다."

7. 변화가 두려움이 아니라 기회가 되는 순간

댄 시퍼의 메시지는 단순합니다. AI처럼 변화 속도가 빠른 환경에서는 기존 제품을 지키는 팀과 미래를 실험하는 팀이 모두 필요합니다. 모든 사람이 모든 신기술을 쫓게 하면 조직은 산만해지지만, 탐색을 전담하는 작고 빠른 연구소를 두면 기존 사업을 흔들지 않으면서도 미래를 준비할 수 있습니다. 🚀

연구소는 실패를 많이 해야 하고, 제품팀은 그 실패의 소음에서 보호받아야 합니다. 대신 실제 업무에서 반복 사용되고, 기존 방식보다 압도적으로 낫고, 비용 면에서도 확장 가능한 아이디어만 제품 중심으로 옮겨야 합니다.

그가 제시하는 성공의 가장 분명한 신호는 새로운 AI 모델이 나왔을 때의 조직 반응입니다.

"새 모델이 나왔을 때 걱정하는 대신 반기고 흥분하게 된다면, 이 방식이 제대로 작동하고 있다는 뜻입니다."

결국 좋은 제품 조직은 변화하는 기술을 무조건 따라가는 조직이 아니라, 변화가 생길 때마다 빠르게 실험하고 학습한 뒤, 고객에게 실질적인 가치로 바꿔 내는 조직입니다.