Every의 공동 창업자이자 CEO인 Dan Shipper는 AI 모델의 능력이 빠르게 달라지는 상황에서 제품팀이 어떻게 일해야 하는지 묻는다. 새 모델을 따라가느라 로드맵을 놓칠 수도 있고, 로드맵에만 집중하다가 제품의 가능성이 달라졌다는 사실을 놓칠 수도 있다. 고객 역시 새 기술을 충분히 이해하지 못한 채 제품팀이 방향을 제시해 주기를 기다리는 경우가 있다고 그는 말한다.
Shipper의 제안은 제품 조직에 연구소의 운영 방식을 도입하는 것이다. 새로운 가능성을 시험하는 사람과 기존 제품을 개선하는 사람의 책임을 나누고, 실험 중 실제로 유용한 것만 제품에 반영한다. Every에서 경험한 방법은 한두 명으로 실험하고, 실제 업무에서 반복 사용되는지 확인한 뒤, 측정하고 개선할 수 있는 시스템으로 만드는 것이다.
탐색과 실행을 나누면 새 기술을 시험하면서도 로드맵을 지킬 수 있다
Shipper는 탐색과 실행이 서로 다른 방식으로 이루어진다고 설명한다. 탐색할 때는 새 모델을 써 보고, 여러 데모를 만들고, 가능성을 넓혀야 한다. 만든 결과물 상당수는 버리게 된다. 반면 실행할 때는 선택지를 좁히고, 다른 일을 거절하며, 정해 놓은 로드맵에 집중해야 한다. 모든 구성원에게 두 가지를 동시에 잘하라고 요구하면 서로 반대되는 방향으로 일하게 된다.
조직에는 이미 다른 사람보다 훨씬 많은 실험을 하는 얼리어답터가 있다. 이들은 주말에도 새 모델로 개인 프로젝트를 만들고 업무에 적용할 방법을 찾는다. 제품이 앞으로 어떻게 달라질 수 있는지 먼저 알아차릴 수 있지만, 유용하지 않은 기술에도 흥분해 주변 사람들의 집중을 방해할 수 있다. Shipper가 제시하는 과제는 이들의 호기심을 활용하면서 나머지 팀이 맡은 일에 집중하도록 만드는 것이다.
연구팀은 새 모델이 나오면 무엇이 가능해졌는지 탐색하고 여러 실험을 한다. 제품팀은 이미 효과가 확인된 제품을 개선하고 확장하며 기존 고객에게 일관된 경험을 제공한다. Shipper는 연구팀이 만든 것의 약 90%는 버리고, 제품팀은 약 10%를 채택할 것으로 기대하라고 말한다. 이는 실험의 성공률을 측정한 통계가 아니라 두 팀이 결과물을 대하는 기대 수준을 설명하는 수치다.
반론. 연구팀을 따로 둘 만큼 인력과 예산이 충분한가. Shipper는 청중이 제기할 법한 이 우려를 직접 꺼낸 뒤, AI를 활용하면 연구팀을 한 명으로도 시작할 수 있다고 답한다. 새 모델이 나왔을 때 한 사람이 집중적으로 시험하고 배운 내용을 팀에 전달하는 역할만 맡아도 된다. 큰 연구 조직을 만드는 것이 선행 조건은 아니다.
한두 명의 실험팀에서 빠르게 만드는 사람과 다듬는 사람을 짝지을 수 있다
Shipper는 기존의 ‘피자 두 판 팀’이 여덟 명에서 열 명 정도를 뜻했다면, AI 시대에는 ‘피자 두 조각 팀’이 적합하다고 말한다. 한두 명이면 빠르게 많은 것을 만들 수 있고, 인원이 늘어나면 의견을 조율하는 비용과 서로 다른 구상이 속도를 떨어뜨리기 때문이다.
그가 쓰는 표현은 ‘해적과 설계자’다. 해적은 가치 있는 무언가를 찾는 데 몰두하며 거칠게라도 여러 결과물을 만든다. Shipper는 자신이 이 역할에 가깝다고 설명한다. 완성도가 낮더라도 많이 시도하고 버리면서 쓸 만한 것을 찾아낸다. 설계자는 이렇게 만든 복잡하고 불완전한 결과물을 살펴보고, 가치가 분명하며 잘 다듬어지고 확장할 수 있는 시스템으로 바꾼다.
이 조합을 처음부터 모든 실험에 똑같이 적용할 필요는 없다. 뒤에서 소개하는 Every의 사례에서는 Shipper가 먼저 실험용 도구를 만들고, 팀 내부에서 사용되기 시작한 시점에 설계자 역할을 하는 동료를 참여시킨다. 실험용 도구를 빨리 만드는 능력과 실제로 계속 개선할 수 있는 시스템을 만드는 능력을 함께 활용하는 방식이다.
실험은 실제 업무에 써 보아야 새로움과 유용함을 구분할 수 있다
Shipper가 연구팀 운영에서 중시하는 것은 무언가를 만든 뒤 그것이 좋은지 알게 되기까지 걸리는 시간을 줄이는 일이다. 가장 빠른 방법은 자신이 실제로 쓸 도구를 만드는 것이다. 직접 사용할 수 없다면 얼리어답터 성향의 초기 고객 몇 명과 가까이 협력해 자주 피드백을 받아야 한다.
실험 결과물은 실제로 해야 하는 업무에 사용해야 한다. 데모가 신기하다는 반응만으로는 도움이 되는지 알 수 없다. 기존 업무를 처리해 보아야 ‘새롭다’는 느낌과 ‘쓸모가 있다’는 판단을 구분할 수 있다는 것이 그의 주장이다.
또한 Shipper는 연구팀에서는 같은 문제를 해결하려는 실험도 여러 개를 병행하라고 권한다. 제품팀에서라면 중복 작업이나 일관성 부족으로 보일 수 있지만, 새로운 모델이 등장했을 때는 무엇이 가능한지 아직 알려져 있지 않다. 각자 다른 접근법으로 같은 문제를 풀어 보면서 어느 방향에 가치가 있는지 알아낼 수 있다.
제품에 채택되지 않은 실험도 콘텐츠와 학습 자료로 활용할 수 있다
대부분의 실험을 버릴 계획이라면, Shipper는 제품에 포함되지 않은 결과물에서도 투자한 만큼의 가치를 얻을 방법을 찾으라고 말한다. Every는 무엇을 시도했고, 무엇이 작동했으며, 무엇이 실패했는지를 외부 콘텐츠로 만든다. 이런 기록을 읽으러 온 사람이 다른 콘텐츠와 제품에도 관심을 갖게 된다는 설명이다.
실험은 초기 사용자 프로그램에도 활용할 수 있다. 새로운 기술을 먼저 써 보고 개발팀과 가까이 협력하고 싶은 고객에게는 실험에 참여할 기회 자체가 가치가 될 수 있다. 모든 고객을 실험에 참여시키는 것이 아니라, 이런 관계를 원하는 고객과 함께 배우는 방식이다.
최소한 연구팀은 모델의 능력이 어디까지 발전했고 무엇이 새로 가능해졌는지를 제품팀에 공유해야 한다. 제품팀이 직접 모든 새 기술을 시험하지 않아도 제품을 만들 때 그 지식을 활용할 수 있어야 한다. Shipper에게 연구팀의 산출물은 출시할 기능뿐 아니라 제품팀이 판단에 사용할 수 있는 지식이기도 하다.
실험 결과물은 내부 사용과 초기 고객 검증을 거쳐 제품에 반영한다
Shipper는 아이디어를 제품에 반영하기까지의 과정을 ‘연구 파이프라인’이라고 부른다. 처음에는 연구팀 안에서 많은 실험을 하고, 그중 가능성이 있는 결과물을 실제 업무에 사용한다. Every에서는 다른 구성원이 자발적으로 사용하기 시작하는지가 첫 번째 확인 지점이다.
팀 내부에서 사용이 확산되면 초기 고객에게 보여 주고, 제품팀도 로드맵의 어느 부분에 들어갈 수 있는지 검토한다. 이 단계에서도 모든 실험이 검증을 통과하는 것은 아니다. 검증을 통과한 결과물만 고객에게 제공할 수 있도록 확장하고 출시한다.
Every는 Notion에 진행 상황을 기록하고 매주 전체 회의에서 검토한다. 제품팀이 어떤 실험에 가능성이 있고 무엇이 다음 단계로 넘어가는지 미리 알 수 있게 하려는 것이다. 실험이 검증되었을 때 제품에 어떤 변화가 필요할지 생각할 시간을 주면, 갑자기 새 실험의 내용을 파악하느라 기존 업무를 중단할 필요가 줄어든다.
편집 자동화 사례에서는 실제 채택을 확인한 뒤 개선 체계를 만들었다
Shipper는 Every의 편집장 Kate를 돕기 위해 몇 년간 AI 교정 실험을 해 왔다고 말한다. 조직이 약 30명으로 커지면서 Kate가 모든 원고를 직접 교정하기 어려워졌기 때문이다. 비슷한 편집 감각을 지닌 사람을 채용하고 훈련하는 것도 쉽지 않아, Kate의 판단을 더 많은 원고에 적용하면서 야간 교정 시간을 줄일 방법을 찾았다.
그는 Kate가 지난 3년 동안 남긴 교정 기록을 모아 AI가 새 원고를 교정하게 했다. 처음부터 충분히 잘 작동한 것은 아니며, 여러 해 동안 시도한 끝에 모델의 능력이 실제로 Kate가 써 볼 만한 수준에 도달했다고 설명한다. 그는 이 실험을 ‘Kate bench’라고 부른다.
가능성이 보이자 Every에서 내부적으로 사용하는 회사 공용 에이전트에 이 기능을 넣었다. Kate가 자신이 교정하던 방식대로 초안을 수정해 달라고 요청하면, 에이전트가 과거 편집 기록을 참고해 수정안을 제안하는 식이다. Kate가 직접 사용하기 시작하고 다른 구성원에게도 사용이 확산되자 조직에 유용할 수 있다는 신호로 받아들였다.
이 시점에 Shipper는 설계자 역할의 동료를 참여시켰다. 그 동료의 이름은 자막에서 Yanek으로 표기된다. Yanek은 문서마다 제안한 수정안이 얼마나 채택되었는지, 에이전트가 교정한 뒤 Kate가 얼마나 더 수정해야 했는지 확인할 수 있는 대시보드를 만들었다. 대시보드에서는 에이전트의 교정 이후 Kate가 실제로 바꾼 내용을 살펴볼 수 있다.
Shipper는 특정 유형의 교정에서 Kate의 작업이 전달보다 12% 줄었다고 설명한다. 핵심은 완성도가 낮은 실험 결과물을 지속적으로 측정하고 개선할 수 있는 시스템으로 바꾸는 데 있다. 발표 당시 Every는 이 방식을 초기 고객에게 제공하고 교정 이외의 업무에도 적용할 수 있을지 검토하는 단계였다. 고객 대상의 검증과 확장까지 완료했다고 말한 것은 아니다.
반복 사용과 비용을 기준으로 판단해야 성공한 실험을 제품에 반영할 수 있다
Shipper는 실험을 다음 단계로 옮길 때 명확한 기준을 두고, 단계가 바뀌었다는 사실을 팀이 알 수 있게 하라고 말한다. 그가 제시하는 기준은 세 가지다.
- 사람들이 실제로 사용하며 다시 돌아오는가. Every는 내부 사용을 가치가 있다는 간접 지표로 삼는다.
- 기존 방법보다 열 배 나은가. 새롭다는 이유로 흥분하는 시기가 지난 뒤에도 차이가 있는지, 한 달 정도 지난 뒤에도 사람들이 계속 사용하는지 살펴본다.
- 고객에게 대규모로 제공할 수 있는 비용 수준인가. 실험이 작동하더라도 제품으로 운영할 수 있는지는 별도로 확인한다.
그가 말하는 최종 목적은 검증을 통과한 결과물을 주력 제품에 통합하는 것이다. Shipper는 소규모 실험에서 제품이 성장하는 사례로 Anthropic Labs와 Codex를 소개한다. Claude Code, MCP, skills 등이 작은 집단의 실험에서 나왔다고 설명하고, OpenAI 내부에서도 코딩의 미래를 두고 여러 팀이 IDE와 CLI 등 서로 다른 형태를 시험했다고 말한다. 이 사례들은 발표자가 조직 운영의 가능성을 설명하기 위해 든 것이다.
Shipper가 기대하는 결과는 기존 제품을 확장하면서 다음 제품도 준비할 수 있는 조직이다. 새 모델의 출시가 로드맵을 흔드는 사건으로만 느껴지지 않고, 따로 시험하고 판단할 기회가 된다. 다만 이 발표는 Every의 경험과 운영 원칙을 제시하며, 팀 규모나 고객 유형이 다른 조직에서도 같은 효과가 나타나는지와 편집 자동화가 외부 고객에게 얼마나 유용한지는 확인하지 않는다.