How a Frontier Team Can Help Your Company Keep Up With AI

🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

How a Frontier Team Can Help Your Company Keep Up With AI를 중심으로, 탐색과 실행을 분리한다. Every의 프런티어 팀은 새로운 모델과 업무 방식을 시험한다. 다른 구성원은 모든 출시를 따라가를 핵심 판단 포인트로 압축 정리한다.

📌 핵심 요점

1. 탐색과 실행을 분리한다. Every의 프런티어 팀은 새로운 모델과 업무 방식을 시험한다. 다른 구성원은 모든 출시를 따라가는 부담을 줄이고, 활용할 준비가 된 결과에 집중한다.
2. 빠른 실험을 운영 가능한 시스템으로 바꿀 역할이 필요하다. ‘해적’은 가능성을 찾고, ‘설계자’는 유지보수와 다양한 사용 상황을 고려해 구조를 만든다. ‘랭글러’는 흩어진 실험을 조직하고 학습을 종합해 전달한다.
3. 평가와 지식 전달을 실제 업무에 연결한다. 개인 업무 벤치마크로 모델의 유용성을 구체화하고, Checks 설명 영상처럼 원래 회의 발언까지 추적할 수 있는 자료로 학습을 전달한다. Compound Writing에서는 독자 맥락을 추가해 원고 검토의 유용성을 시험한다.
4. 실험의 비용과 운영 방식을 함께 관리한다. 토큰 대시보드는 사람·업무별 사용량과 추정 비용을 살펴보게 한다. 비개발 운영자의 내부 도구 제작과 Minga의 목표·계획 단위 작업은 AI 활용 범위가 넓어지는 사례다.
5. 성과의 기준은 조직의 채택이다. 실험이 많아도 실제 업무에 통합되지 않으면 효과를 내기 어렵다. 이해하기 쉬운 결과 전달, 동료의 주의력 보호, 소프트웨어의 신뢰성과 유지보수성이 함께 필요하다.

🧩 배경과 문제 정의

• 직원들은 당장의 업무를 끝내는 일과 새로운 AI 도구·업무 방식을 따라가는 일 사이에서 갈등한다. 최신 기술을 외면하면 변화에 뒤처질 수 있고, 신기술만 좇으면 지속 가능한 제품과 서비스를 만들기 어렵다.
• Every의 프런티어 팀은 AI 실험을 전담하고, 검증된 성과를 제품·서비스와 내부 업무로 옮기는 역할을 맡는다. 나머지 구성원은 모든 모델 출시를 직접 추적해야 하는 부담을 줄일 수 있다.
• 실험의 사업적 가치를 높이려면 빠른 탐색뿐 아니라 유지 가능한 시스템 설계, 모델 성능 평가, 학습 내용의 정리·전달, 비용과 성과의 점검이 필요하다.

🕒 시간순 섹션별 상세정리

1. AI 탐색과 제품 실행을 분리하는 프런티어 팀

• 최신 AI를 무시하면 예상하지 못한 에이전트 중심 제품에 위협받을 수 있고, 새 도구만 좇으면 오래가는 결과물을 만들기 어렵다. 프런티어 팀은 탐색과 일상 업무를 분리해 두 활동을 병행하게 한다 [00:21]
• 실험의 성과는 새로운 통찰을 담은 콘텐츠가 되거나 제품·서비스에 반영된다. 다른 구성원은 실험이 활용할 준비를 갖췄을 때 집중하면 된다 [02:05]

2. 빠르게 탐색하는 ‘해적’과 구조를 만드는 ‘설계자’

• ‘해적’형 구성원은 다소 거칠더라도 짧은 시간에 많은 실험을 시도하며 유용한 가능성을 찾는다. ‘설계자’형 구성원은 그 결과를 실제로 사용할 수 있는 구조로 정리한다 [02:53]
• 대부분의 실험은 폐기되지만, 회사 내부로 확산할 실험에는 유지보수와 다양한 사용 상황을 고려한 설계가 필요하다. 이 단계에서 설계자가 일회성 바이브 코딩 결과물을 이해하고 확장할 수 있는 시스템으로 바꾼다 [03:30]

3. 감각적인 모델 평가를 개인 업무 벤치마크로 구체화

• 모델에는 사람들이 아직 충분히 시험하지 못한 역량이 남아 있다. 프런티어 팀은 모델의 한계를 밀어붙여 새롭게 가능한 일과 업무 방식을 찾는다 [05:18]
• 평가 담당 마이크 테일러는 정성적인 ‘바이브 체크’에 수치적 근거를 더하고, 구성원별 실제 업무를 활용한 개인 벤치마크를 내부 제품으로 확장하고 있다. AI의 아첨 성향도 정의와 시험 방법을 구체화할 대상으로 삼는다 [05:49]

4. Opus로 흩어진 업무 기록을 설명 영상의 재료로 전환

• 마이크는 오랫동안 시험해 온 AI 영상 편집이 Opus에서 실용적으로 작동하기 시작했다고 평가한다. 개인 벤치마크 제품 Checks의 설명 영상에는 Slack 메시지와 회의 기록에서 찾은 근거를 활용했다 [06:46]
• 방대한 자료를 읽히기 위해 높은 노력 수준의 ‘ultra code’ 설정을 선택했다. 수백 개 에이전트가 회의별 자료를 나눠 처리하고, 관련 출처를 모아 하나의 자료 모음을 구성했다 [08:24]

5. 출처를 추적할 수 있는 서사와 영상 제작

• 수집한 자료는 Checks를 설명하는 12개 문장의 서사로 압축됐다. 각 문장에서 인사이트 카드와 원래 회의 발언까지 거슬러 올라갈 수 있어 설명의 근거를 확인할 수 있다 [08:58]
• Opus는 Slack에서 관련 화면을 찾고 주석을 붙였으며, Gemini를 이용한 음성 해설까지 조합했다. 이렇게 만든 영상은 실험 담당자의 지식을 다른 구성원이 이해하기 쉬운 형태로 전달한다 [09:42]

6. AI에 충분한 맥락을 주고 동료의 주의력을 보호

• 마이크는 AI가 필요한 맥락을 고르는 능력이 크게 좋아졌다고 평가하며, 업무 기록과 연결 서비스에 접근할 수 있도록 충분한 맥락을 제공할 것을 권한다. 자신도 Gmail과 Slack을 연결하지 않던 상태에서 폭넓게 연결하는 방식으로 바뀌었다 [10:45]
• AI로 아이디어와 결과물의 생산량이 늘어날수록 다른 사람의 정보 처리 부담을 줄이는 일이 중요해진다. 실험 결과를 계속 쏟아내기보다 영상처럼 소화하기 쉬운 형태로 만드는 것이 새로운 업무가 된다 [11:36]

7. 실험을 사업의 학습으로 바꾸는 ‘랭글러’

• 아리엘의 ‘프런티어 랭글러’ 역할은 실험을 적절히 조직하고, 학습을 수집·종합해 외부에 전달하며 내부 탐색 방향을 잡는 것이다. 운영자로서 직접 실용적인 내부 시스템도 실험한다 [12:33]
• 창의적인 구성원들이 다음 실험으로 빠르게 이동할수록, 여러 활동을 이해하기 쉬운 주제로 묶고 의미를 찾는 조직적 역할이 필요하다. 정리된 학습은 콘텐츠, 제품, 컨설팅에서 가르치는 개념으로 계속된다 [13:25]

8. 토큰 사용량을 비용과 업무 가치에 연결하는 대시보드

• 모델 발전으로 실험 기회가 늘면서 토큰 소비도 빠르게 증가한다. 실험 투자를 관리하려면 무엇을 시험했고 얼마를 썼으며 무엇을 얻었는지 함께 파악해야 한다 [14:31]
• 사용량 대시보드는 총비용과 토큰 수를 사람별로 나누고, 컴퓨터에서 사용하는 여러 실행 도구의 사용 기록을 수집한다. 모델과 노력 수준도 확인할 수 있지만, 당시 10월 지출은 아직 한 달 전체가 모이지 않은 상태였다 [15:13]

9. 비개발 운영자도 필요한 내부 시스템을 직접 구축

• 아리엘은 과거라면 모델 제공업체가 추적 기능을 추가하기를 기다리거나 엔지니어와 협업해야 했지만, 이제 필요한 기능의 일부를 직접 만들 수 있다고 드러낸다 [17:08]
• 모델이 더 똑똑해질수록 운영자가 아이디어를 실제 시스템으로 구현할 수 있는 범위도 넓어질 것으로 기대한다 [17:27]

10. Gemini Audio 광고가 제시하는 음성 업무 기능

• 광고에서 제시한 Gemini 3.5 Transcribe의 핵심 기능은 말하는 도중의 정정과 군더더기를 처리해 정돈된 텍스트를 만드는 것이다. “화요일, 아니 수요일” 같은 수정도 자동 반영하는 사례가 포함된다 [17:57]
• Gemini 3.8 Live Extended Thinking의 광고상 특징은 추론과 발화를 동시에 수행하고, 작업 중에도 후속 질문과 피드백을 받는 것이다. 음성 대화로 복잡한 아이디어를 발전시키는 사용 방식을 제안한다 [18:21]

11. 탭 없는 브라우저로 개인 업무 방식을 직접 설계

• 잭 창은 사전 제공 모델로 인터랙티브 경험과 게임을 만들며 이전에는 시도하기 어려웠던 역량을 시험한다. 개인 앱 제작도 실험 범위에 포함한다 [19:20]
• 브라우저 탭과 잦은 맥락 전환에 압도되던 문제를 해결하기 위해 탭 없는 브라우저를 만들었다. 실제 편집 업무에 사용하도록 공급업체와 모델을 선택할 수 있는 에이전트 패널도 추가했다 [20:10]

12. 생산량 증가와 함께 커지는 집중력 부담

• 잭은 ADHD를 관리하기 위해 오랫동안 적응 전략을 사용해 왔다. AI로 더 많은 일을 하게 됐지만, 여러 일을 동시에 시도하려는 유혹과 집중력을 유지하는 부담도 커졌다고 느낀다 [22:50]
• 앞으로 만들고 싶은 도구는 글쓰기와 아름다운 결과물의 창작을 돕고 지역 공동체와의 연결을 강화하는 도구다. 실험이 자신의 가치관을 뒷받침하고 깊게 만드는 방향을 지향한다 [23:55]

13. 모델 시험·학습 전달·도구 제작을 함께 수행하는 작가

• 케이티는 여러 업체의 사전 제공 모델을 실제 업무에 적용하고, 사용 경험을 ‘바이브 체크’ 독자에게 전달한다. 팀에 상주하는 작가로서 프런티어 팀의 학습을 글로 정리한다 [24:48]
• 직접 Compound Writing 같은 도구를 만들고 글쓰기에 맞춰 미세 조정된 모델도 활용한다. 다른 팀원이 만든 도구의 초기 사용자로 참여해 실제 사용 과정의 문제를 시험한다 [25:38]

14. Compound Writing에 독자 맥락을 추가

• Compound Writing은 아이디어 발상부터 계획·개요, 초안, 마무리까지 지원하는 플러그인이다. 기존에는 문장과 어휘의 목소리를 담는 보이스 가이드와, 주제 및 서술 방식을 담는 style.md를 중심으로 작동했다 [26:06]
• 케이티는 최종 독자가 누구인지 정의하는 audience.md를 세 번째 핵심 문서로 추가하고 있다. 독자 정보가 플러그인의 사용 경험과 유용성을 어떻게 바꾸는지 시험하는 단계다 [26:44]

15. 독자별 원고 검토를 구체화하고 후속 실험으로 확장

• ‘Working Overtime’ 칼럼의 독자는 AI에 관심을 갖기 시작한 탐색자와 일상 업무의 실용적 적용을 찾는 운영자로 정의된다. 독자가 글을 읽으며 어떤 변화를 경험해야 하는지도 ‘영웅의 여정’ 개념으로 독자 문서에 포함했다 [27:50]
• 독자 문서를 적용한 원고 검토는 맥락 설명과 개인적 해결 경험의 장점을 짚는 한편, 입문 독자가 따라오기 어려운 부분과 운영자가 궁금해할 실패의 피해·비용을 구체적으로 지적했다. 케이티는 이런 피드백이 글쓰기 도구의 가치를 높일 수 있다고 평가한다 [28:46]

16. 원하는 글쓰기 도구를 직접 구현해 요구사항을 구체화

• 글쓰기 도구에 원하는 기능과 취향을 설명하기 위해 개인 워드프로세서 ‘Word Better’를 직접 만들고 있다. 작동하는 결과물을 Kieran에게 보여주는 방식으로 더 적합한 사용 경험을 전달하려 한다. [30:19]

17. 시제품을 실제 운영 가능한 소프트웨어로 전환

• Yanik은 여러 프로젝트의 아키텍트 역할을 맡으며, 초기에는 Proof를 되살리고 실제 운영에 사용할 수 있도록 준비했다. 현재는 편집장의 판단과 취향을 재현하려는 Capebench 스킬을 통해 작업 부담을 줄이는 데 집중한다. [30:58]
• AI는 필요한 도구를 찾아 그럴듯한 결과물과 데모를 빠르게 만들 수 있다. 그러나 신뢰성과 유지보수성을 확보하려면 코드 구조, 라이브러리 선택, 배포 방식 등 소프트웨어 전반을 판단하는 전문성이 여전히 필요하다. [31:52]

18. Minga로 개별 코딩 작업에서 목표와 계획 관리로 이동

• 오케스트레이터 ‘Minga’는 개별 코딩 세션보다 목표와 계획 수준에서 일하기 위한 실험이다. 예시 프로젝트 ‘Reply Guy’는 동료 Becky가 트위터의 유행을 탐색하고 자사의 새 ‘vibe check’ 콘텐츠로 답글을 달 수 있도록 돕는 도구다. [32:59]
• 사용자가 목표와 요구사항을 전달하면 오케스트레이터 에이전트가 작업을 나누고 의존성과 실행 순서를 정한다. 백그라운드에서 구현을 진행하다가 결정이 필요하면 사용자에게 알리고, UI 초안에 대한 피드백을 받아 작업을 이어간다. [33:49]

19. 반복 실험과 지식 공유로 조직의 시도 범위를 확대

• Kieran의 Kora 개발과 여러 실험에서 compound engineering 등이 나왔다. 프런티어 팀이라는 이름은 기존의 탐색 활동에 정체성을 부여하고, 무엇이 작동하고 작동하지 않는지 실험할 여지를 준다. [35:51]
• 새 모델이 나올 때마다 가능한 일이 달라지므로 매주 최소 한 번, 대개 여러 번 실험한다. 배운 내용을 팀과 Every 구독자에게 공유해 활용 방향을 잡도록 돕는다. [36:28]

20. 모델의 실패 한계를 시험하며 더 복잡한 제품에 도전

• 모델 평가는 어디까지 밀어붙이면 실패하는지 확인하는 데 초점을 둔다. 초기의 코드 작성 능력에서 여러 파일을 함께 다루고 UI를 구현하는 능력으로 실험 범위가 확대됐다. [37:50]
• 이후 에이전트가 작업을 이어받아 수행하는 방식이 가능해졌고, CRDT와 실시간 편집을 포함한 복잡한 텍스트 편집기도 일주일 안에 구현할 수 있는 수준에 도달했다. Proof는 이런 변화 속에서 나온 사례다. [38:37]

21. 회의의 아이디어를 보존하는 영상 도구와 차세대 글쓰기 편집기

• 개발 중인 영상 도구는 편집뿐 아니라 라이브 스트리밍과 회의 녹화까지 포함한다. 회의에서 사라지기 쉬운 구성원의 아이디어를 기록하고, 편집자가 익숙하게 다룰 수 있으면서 에이전트도 작업할 수 있는 형태로 제공하려 한다. [40:19]
• 글쓰기 편집기에서는 Proof의 다음 버전을 만들거나 기존 기능을 개선하고 확장할 수 있는지 실험하고 있다. [40:51]

22. 프런티어 팀의 성과를 실제 업무에 정착

• 프런티어 팀은 구성원에게 영감을 주는 동시에 구성원의 필요를 들어야 한다. 실험을 100개 해도 결과가 조직에 정착하거나 업무에 통합되지 않으면 효과를 내기 어렵다. [41:27]
• 실험의 자유는 실제 조직에 결과를 가져오는 책임과 연결된다. 채널에 실험 100개를 한꺼번에 쏟아 조직을 압도하기보다, 사람들이 내용을 이해하고 일부 결과를 실제로 채택하도록 해야 한다. [41:50]

23. 교육과 소프트웨어를 묶은 Every 구독 안내

• Every 구독은 새 모델에 대한 평가 등 교육 콘텐츠와 소프트웨어 도구를 함께 제공한다. 회사 전반의 AI 활용을 돕는 에이전트도 포함하며, 영상 시청자와 청취자에게 설명란 링크를 통한 2주 무료 체험을 안내한다. [42:23]

🧾 결론

• 프런티어 팀의 역할은 새로운 도구를 시험하는 데서 끝나지 않는다. 실험에서 얻은 가능성을 제품·서비스와 내부 업무로 연결해야 한다.
• 탐색, 시스템 설계, 평가, 학습 정리는 서로 보완하는 역할이다. 빠른 시제품 제작 이후에도 운영 가능한 구조를 만드는 판단이 필요하다.
• AI가 생산량을 늘릴수록 결과를 선별하고 이해하기 쉽게 전달하는 일이 중요해진다. 구성원이 실제로 채택할 수 있어야 실험이 조직의 역량으로 남는다.

📈 투자·시사 포인트

• 기업의 AI 활용 수준을 살필 때 도구 도입이나 실험 개수와 함께 실제 업무 채택, 유지보수 체계, 학습 공유 방식을 확인필요가 있다.
• 토큰 지출은 무엇을 시험했고 어떤 결과를 얻었는지와 연결해 판단해야 한다. 사용량 증가만으로 성과를 설명하기는 어렵다.
• 운영자가 필요한 시스템을 직접 만드는 사례는 내부 도구 개발의 범위가 넓어질 가능성을 보여준다. 실제 운영에서는 신뢰성과 소프트웨어 설계 역량도 계속 중요하다.
• Every는 실험에서 얻은 학습을 콘텐츠·제품·컨설팅으로 연결한다. 다만 영상에는 이 구조의 수익성이나 투자수익률을 판단할 정량 자료가 제시되지 않는다.

⚠️ 불확실하거나 확인이 필요한 부분

• 전담 팀 도입 전후의 생산성, 업무 채택률, 유지보수 비용이 정량적으로 제시되지 않는다. Every의 사례가 다른 규모와 업종에서도 같은 성과를 낼지는 확인이 필요하다.
• 토큰 대시보드의 당시 10월 지출은 한 달 전체 자료가 아니며, 업무별 비용도 추정치다. 이를 완결된 월간 비용이나 투자수익률로 해석하기 어렵다.
• Opus의 영상 제작, 복잡한 편집기 구현, DAW 제작 가능성은 출연자의 경험과 평가에 근거한다. 모델·설정·작업 조건에 따른 재현성은 별도로 확인해야 한다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 현재 업무에서 AI로 시험할 문제를 고르고, 탐색·설계·평가·학습 정리를 누가 담당할지 정한다.
• 구성원의 실제 업무를 개인 벤치마크로 삼아 모델이 잘하는 작업과 실패하는 조건을 기록한다.
• 실험마다 사용한 모델과 설정, 토큰 비용, 얻은 결과를 함께 정리해 업무 가치와 비교한다.
• 내부에 확산할 시제품은 코드 구조, 라이브러리, 배포 방식과 유지보수 가능성을 점검한다.

❓ 열린 질문

• 어떤 실험을 폐기하고 어떤 결과를 제품이나 내부 업무로 옮길지 판단하는 기준은 무엇인가?
• 전담 팀에 투입한 시간과 비용을 업무 개선 효과와 연결해 어떻게 평가할 것인가?
• ‘해적’과 ‘설계자’가 같은 프로젝트에서 함께 작업하면 순차 인계보다 어떤 효과를 얻을 수 있는가?