트웰브랩스

Tokens Never Sleep: 트웰브랩스가 AI 에이전트와 일하며 배운 3개월의 기록

Sue Kim

트웰브랩스는 지난 3개월 동안 Tokens Never Sleep 이니셔티브를 통해 AI 코파일럿과 에이전트를 실제 업무 흐름에 적용해왔습니다. IT 운영, 제품 개발, 리서치, 채용과 사무 관리까지 AI가 반복 업무와 맥락 정리를 맡는 동안, 사람은 더 중요한 판단과 관계, 구조 설계에 집중할 수 있게 됐습니다. 이 글은 AI-native하게 일한다는 것이 속도와 신뢰, 그리고 사람의 역할이 어떻게 바뀌는지에 대한 트웰브랩스의 기록입니다.

트웰브랩스는 지난 3개월 동안 Tokens Never Sleep 이니셔티브를 통해 AI 코파일럿과 에이전트를 실제 업무 흐름에 적용해왔습니다. IT 운영, 제품 개발, 리서치, 채용과 사무 관리까지 AI가 반복 업무와 맥락 정리를 맡는 동안, 사람은 더 중요한 판단과 관계, 구조 설계에 집중할 수 있게 됐습니다. 이 글은 AI-native하게 일한다는 것이 속도와 신뢰, 그리고 사람의 역할이 어떻게 바뀌는지에 대한 트웰브랩스의 기록입니다.

In this article

No headings found on page

Join our newsletter

Join our newsletter

Receive the latest advancements, tutorials, and industry insights in video understanding

Receive the latest advancements, tutorials, and industry insights in video understanding

Search, analyze, and explore your videos with AI.

May 11, 2026

10 minutes

Copy link to article

우리가 잠든 사이에도 돌아가는 시스템

트웰브랩스가 실행 속도를 복리로 쌓는 방식

트웰브랩스 안에서 요즘 자주 들리는 말이 있습니다.

“Tokens Never Sleep.”

지금은 하나의 슬로건처럼 쓰이고 있지만, 처음부터 슬로건이었던 것은 아닙니다. 시작은 아주 현실적인 질문이었죠.

올해 초, 한 팀원이 LLM과 연결된 재무 도구로 예전에는 몇 주가 걸렸을 분석을 몇 분 만에 해냈습니다. 누군가는 그 장면을 보고 “좋은 데모/사례구나” 하고 넘겼을지도 모르지만, CEO가 본 것은 조금 달랐습니다. AI를 기존 업무에 단순히 덧붙인 것이 아니라, 처음부터 AI를 기반으로 일하는 방식이었습니다.

그 자리에서 질문이 이어졌습니다.

"이걸 다른 데이터와 업무 시스템에도 더 붙일 수 있을까요?”
“모두가 쓸 수 있게 할 수 있을까요?”
“우리가 자는 동안에도 돌아가게 만들 수 있을까요?”

Tokens Never Sleep(TNS)은 그렇게 태어났습니다.

반복적이지만 손이 가는 인지 노동, 예를 들어 티켓 분류, 계정 관리, 업데이트 추적, 회의 준비, 리서치 모니터링 같은 일을 AI 코파일럿과 에이전트가 밤낮없이 처리하고, 사람은 진짜 판단이 필요한 곳에 집중하게 만드는 방식입니다.

이 이니셔티브는 처음부터 원칙도 명확했습니다.

  • 배포하고 피드백으로 다듬을 것. 실행 하나하나가 다음 실행을 더 빠르게 만든다.

  • 데모로 보여줄 수 없는 아이디어는 의심할 것.

  • 무언가를 시작하기 전에 “AI가 이 일의 80%를 할 수 있을까?”를 먼저 물을 것.

트웰브랩스는 지난 1월 말부터 약 3개월 동안 Tokens Never Sleep을 실제 업무 속에서 운영해왔습니다. 처음 질문이 “얼마나 많은 일을 AI에게 맡길 수 있을까?”였다면, 지금의 질문은 조금 달라졌습니다.

더 많은 토큰을 쓰는 것이 무조건 더 높은 생산성으로 이어지지는 않는다는 사실을 깨달았기 때문이죠. 토큰 사용의 피크를 지나온 지금, 이제 중요한 것은 토큰을 얼마나 쓰는가가 아니라, 토큰이 어떤 맥락을 읽고, 어떤 ground truth 위에서 움직이며, 사람의 판단을 어떻게 적재적소에 배치하는가입니다.


모든 건 하나의 코파일럿에서 시작됐다

이 모든 것은 IT 매니저 Rick Mondragon의 코파일럿에서 시작했습니다.

아무리 뛰어난 영상 AI 모델을 만들고 있어도, 한밤중 권한 오류 하나로 엔지니어의 작업이 멈추거나, 서로 다른 타임존 사이의 공백 시간에 내부 도구가 멈춰버리면 생산성은 그대로 끊겨버립니다. Rick은 이 문제를 해결하기 위해, 자신의 역할과 사용하는 도구, 우선순위를 이해하는 코파일럿을 직접 만들었습니다. 티켓 분류, 접근 권한 설정, 보안 모니터링 같은 스킬을 붙여 실제 운영 업무를 위임할 수 있게 된 것입니다.

결과는 수치로 나타났습니다.

  • 일반적인 접근 권한 요청: 8시간 → 15분

  • 신규 입사자 온보딩: 하루 → 10분 검토

  • 일상 IT 티켓의 60%: 사람 손을 거치지 않고 처리

나머지 40%도 코파일럿이 먼저 무엇을 확인했고, 어떤 문제가 발견됐으며, 다음 조치가 무엇인지 정리해서 함께 전달됩니다.

하나의 코파일럿이 분명한 효과를 보이자, 자연스럽게 다음 질문이 따라왔습니다. 코파일럿끼리 연결할 수 있다면 어떨까?


하나의 코파일럿에서 네트워크로

하나의 코파일럿이 분명한 효과를 보이자, 모두가 자기만의 코파일럿을 가질 수는 없을까? 라는 질문은 자연스럽게 따라왔습니다. 그래서 트웰브랩스는 코파일럿끼리 연결되는 커뮤니케이션 레이어를 만들었습니다. 각 구성원이 자신의 역할과 진행 중인 프로젝트, 사용하는 도구, 권한 범위를 이해하는 개인 코파일럿을 가질 수 있도록 말이죠.

예를 들어 샌프란시스코는 새벽 2시이고 서울은 저녁 6시라고 해보겠습니다. 서울의 한 엔지니어가 새로운 내부 도구에서 권한 오류를 만나게 되면, 그 엔지니어의 코파일럿이 문제를 인식하고, Rick의 코파일럿이 가진 프로비저닝 스킬을 호출해 권한 매트릭스를 확인합니다. 동시에 보안 모니터링 스킬과 교차 검증해 시스템 자체의 장애는 아닌지도 확인합니다.

그렇게 몇 분 안에 접근 요청이 해결됩니다. 예전 같으면 엔지니어는 샌프란시스코가 동이 틀때까지 기다려야 했겠지만, 지금은 일의 흐름이 끊기기도 전에 문제가 해결되는 것입니다.

물론 여기서 코파일럿이 서로 협업한다고 해서 사람의 통제 밖에서 멋대로 움직이게 두지는 않습니다. 모든 코파일럿 간 작업은 Slack에서 사람의 승인을 거치고, 판단이 필요한 순간이 오면 코파일럿은 필요한 맥락을 먼저 정리해서 올리고, 사람은 그 위에서 결정을 내리게 되죠.

이 네트워크는 운영 도구를 넘어 내부 빌딩 속도도 바꿨습니다. 재무팀은 대시보드를 만들었고, 채용팀은 소싱 앱을 만들었습니다. 예전 같으면 "검토해볼게요"로 시작해 백로그 어딘가에 들어갔을 아이디어들이, 이제는 몇 시간 안에 실제 운영 도구가 되고 있습니다.


AI를 만드는 팀이 AI로 일했다

Pegasus 1.5를 개발하던 시기, 비슷한 장면들이 제품 개발 현장에서도 펼쳐지고 있었습니다. AI 모델을 만드는 팀이 동시에 AI를 가장 적극적으로 활용하는 팀이기도 했습니다.

Sam(ML Research Scientist)은 학습 초반에 구조적인 문제에 부딪혔습니다. 학습 속도를 대폭 높여주는 Flash Attention 패키지가 트웰브랩스 모델 구조에는 그대로 적용되지 않았습니다. 우회하는 대신, Sam은 Claude Code를 활용해 GPU 커널을 직접 커스텀해서 문제를 해결했습니다.

“Claude Code를 엄청 써서 GPU 커널 같은 거를 직접 짜서 커스텀해서 썼거든요. AI Native 환경에서 일하면 이런 걸 할 수 있구나 싶었어요.”

— Sam, ML Research Scientist

개발 속도도 달라졌습니다. Backend Engineer인 Genie는 Pegasus 1.5의 핵심 기능인 TBM, Time-based Metadata를 이틀 만에 개발했습니다. PRD가 나오면 Technical Document를 먼저 꼼꼼하게 작성하고, 구현은 Claude에게 에이전트로 위임하는 방식이었습니다. 테스트 자동화, 플랫폼 연동, 버그 탐지까지 모두 그 흐름 안에서 처리됐습니다.

수치가 그 차이를 선명하게 보여줍니다. 타임존을 넘나들며 협업했던 이전 프로젝트에서는 2~3주 작업 결과 약 30개의 QA 버그가 나왔지만, 이번 Pegasus 1.5는 개발기간 이틀만에 버그 6개가 발생했습니다.

“실질적으로 코드를 직접 쓰는 시간은 훨씬 많이 줄었고, 어떻게 하면 더 예쁘고 사용하기 좋은 API 스펙을 만들지 이런 건설적인 대화를 할 시간이 훨씬 많아진 것 같아요.”
— Genie, Backend Engineer

단순히 '코드를 더 빨리 쓸 수 있다'에 머무는 이야기가 아닙니다. 개인에게 더 많은 결정권과 더 빠른 루프가 주어질 때, AI는 생산성을 끌어올리는 도구가 아니라 일하는 방식의 기본 전제가 됩니다.

“코딩 에이전트 같은 게 많이 발전하면서 개인의 생산성이 굉장히 올라갔어요. 그러면 이걸 잘 활용하려면 개인한테 결정하고 루프를 돌 수 있는 권한을 빨리빨리 줘야 되거든요.”
— SJ, Machine Learning Engineering Manager


팀의 기억을 시스템으로 만들기: Dan의 두 에이전트

Marengo and Search 팀을 이끌고 있는 Dan은 연구팀 리드로서 늘 고민하던 문제가 있었습니다. 서울과 샌프란시스코에 걸쳐 있는 팀원들, 동시에 진행되는 여러 이니셔티브, 그리고 끊임없이 흘러가는 Linear 티켓, GitHub 커밋, WandB 실험 결과들. 리드로서 팀 전체의 맥락을 놓치지 않으면서 자신의 실무를 해야 한다는 것이 큰 부담이었습니다.

Dan은 이 문제를 구조적으로 풀기로 했습니다. 두 개의 목적이 다른 에이전트를 직접 만든 것입니다.

하나는 Dot입니다. Dot은 팀을 위한 지식 코디네이터로, 매일 아침 팀이 출근하기 전에 Linear 이니셔티브 현황, GitHub 커밋 및 PR 활동, WandB 실험 결과, Notion PRD를 동기화하고 정리합니다. 누군가 “이 이니셔티브 지금 어디까지 왔나요?”라고 물으면, Dot은 여러 시스템에 흩어진 정보를 엮어 팀원들이 같은 맥락을 반복 설명하지 않아도 되게 만드는 것이죠.

다른 하나는 Dan’s OS입니다. Dan 개인의 workflow engine에 가까운 이 에이전트는, 밤사이 쌓인 Slack 멘션을 분류해 아침에 무엇부터 봐야 할지 정리하고, 미팅 전에는 이해관계자 맥락과 최근 의사결정 흐름을 묶어 브리핑으로 올립니다. 새로 올라온 논문이 현재 연구 과제나 제품 로드맵과 연결될 수 있는지도 살핍니다. 무엇이 결정됐는지만 저장하는 것이 아니라, 왜 그렇게 결정됐는지까지 설명을 남깁니다.

그렇게 Dot은 팀의 기억을 담당하고, Dan’s OS는 리더의 판단 맥락을 담당합니다. 두 에이전트는 서로 다른 일을 하지만, 함께 돌아갈 때 하나의 운영체계처럼 작동합니다.

Dan에게는 Slack에 Dot을 위한 scratchpad도 있습니다. 생각을 정리할 때 그곳에 두서없이 적으면, Dot이 이를 받아 정리하고 필요한 흐름으로 연결합니다. 리드의 머릿속에만 남아 있던 생각이 시스템 안으로 들어오고, 팀이 다시 활용할 수 있는 맥락으로 바뀌는 것입니다.

Dan은 에이전트를 쓰면서 관리 업무에 드는 비용이 크게 줄었다고 말합니다. 여기서 말하는 비용은 단순한 시간 비용이 아닙니다. 누가 무엇을 하고 있었는지, 어떤 결정이 어디서 나왔는지, 어떤 논문이 현재 workstream과 연결되는지, 어떤 주제를 재검토해야되는지를 계속 머릿속에 붙잡고 있어야 하는 비용입니다. Dot이 팀의 맥락을 계속 붙잡고 있기 때문에, Dan은 모든 정보를 직접 들고 있는 사람이 아니라 정리된 맥락 위에서 더 중요한 판단을 하는 사람이 될 수 있게 되는 것입니다.


3개월의 기록: 우리가 배운 것

Tokens Never Sleep을 올해 1월 말에 시작해서, 어느덧 3개월이라는 시간이 지났습니다.

처음에는 “AI로 일하면 더 많이, 더 빠르게 할 수 있다”는 기대가 컸습니다. 실제로 많은 일처리가 빨라졌죠. 하지만 3개월이 지난 지금, 조금 더 정교한 것들을 배우게 되었습니다.

첫 번째로, 토큰을 많이 쓴다고 생산성이 사용량에 비례해서 오르지는 않습니다.

에이전트를 돌리는 이유는 사람의 시간과 집중력이 유한하기 때문입니다. 그 유한한 자원을 진짜 판단이 필요한 곳에 쓰기 위해, 반복적이고 맥락 정리가 필요한 일을 에이전트에게 위임하는 것입니다. 핵심은 사용량이 아니라 사용의 방향입니다.

두 번째로, 에이전트보다 데이터가 먼저입니다.

MCP 같은 연결 레이어가 많아지고, Slack, Linear, GitHub, Notion, WandB 같은 시스템을 쉽게 이어 붙일 수 있게 되면서 에이전트가 할 수 있는 일은 빠르게 늘고 있습니다. 하지만 연결이 쉬워졌다고 해서 좋은 결과가 자동으로 나오는 것은 아닙니다.

에이전트를 아무리 잘 만들어도, 그 에이전트가 읽는 데이터가 엉망이면 소용이 없습니다. 똑똑한 사람에게 잘못된 정보의 책을 읽게 하는 것과 같죠.

결국 에이전트의 품질은 데이터의 품질에서 시작합니다. 어떤 문서가 최신인지, 어떤 데이터가 기준인지, 어떤 결정이 확정된 것인지, 어떤 메모가 단지 생각의 흔적인지를 팀 안에서 정리해두는 것. 그것이 시스템 전체의 기반이 됩니다.

좋은 에이전트를 만드는 일은 견고한 ground truth를 만드는 일과 떨어져 있지 않습니다.

세 번째로, 채용의 기준도 달라지고 있습니다.

한국 사무실 지사장인 Hyemin은 이 변화를 채용 분야에서도 체감하고 있습니다.

“3개월 전과 지금 제가 후보자를 보는 기준이 달라졌어요. 예전에는 데이터 정리나 반복 작업을 도와줄 수 있는 사람이 필요했다면, 이제는 그 일의 상당 부분을 에이전트가 할 수 있게 됐거든요. 그러다 보니 지금은 구조를 설계하고 판단을 내릴 수 있는 사람, 에이전트에게 잘 위임하고 결과를 해석할 수 있는 사람을 찾게 돼요.”
— Hyemin Lee, Country Manager- Korea

일하는 방식이 바뀌면, 함께 일하고 싶은 사람의 모습도 바뀝니다.

예전에는 기본적인 데이터 정리나 운영 업무를 도와줄 사람이 필요했다면, 이제 그런 일의 상당 부분은 에이전트에게 맡길 수 있습니다. 대신 사람에게 더 중요해지는 일은 따로 있습니다. 업무의 구조를 설계하는 일, 좋은 입력과 기준을 만드는 일, 사람 사이의 신뢰와 engagement가 필요한 지점을 구분하는 일, 그리고 최종 판단의 책임을 지는 일입니다.

트웰브랩스에서 AI-native하게 일한다는 것은 단순히 AI 툴을 잘 쓴다는 뜻에 머물지 않습니다. 문제를 구조화하고, 견고한 ground truth를 만들고, 반복 가능한 시스템으로 바꾸고, 최종 판단에 대한 책임을 질 수 있다는 뜻에 가깝습니다.


우리는 더 중요한 문제를 생각하기 위해 AI를 쓴다

Tokens Never Sleep은 “AI를 많이 쓰자”는 캠페인이 아닙니다.

우리가 잠든 사이에도 토큰이 돌아가게 만들자는 말이지만, 그 목적은 사람이 더 오래 일하게 만드는 것이라기보단, 사람이 가진 집중력과 판단력을 더 아껴 쓰기 위한 방식입니다.

티켓은 코파일럿이 지켜볼 수 있습니다.
문서는 에이전트가 정리할 수 있습니다.
회의 전 맥락 정리는 시스템이 준비할 수 있습니다.
논문은 밤사이 읽혀 있을 수 있습니다.
반복되는 follow-up은 자동화될 수 있습니다.

하지만 무엇이 중요한 문제인지 정하는 일, 어떤 결정을 내려야 하는지 판단하는 일, 누구와 어떻게 신뢰를 쌓을지 선택하는 일은 여전히 사람에게 남아 있습니다.

트웰브랩스가 지난 3개월 동안 배운 것은 단순합니다.

AI는 사람을 대체하기보다, 사람이 더 잘해야 하는 일을 더 또렷하게 드러냅니다.
토큰은 잠들지 않지만, 토큰이 대신할 수 없는 판단은 여전히 사람의 몫입니다.
그래서 좋은 에이전트를 만드는 일은 곧 더 효율적인 조직 운영 방식을 만드는 일입니다.

우리는 완벽해질 때까지 기다리지 않습니다.
우선 만들고, 실제 업무에 적용하고, 피드백으로 다듬습니다.
데모가 되지 않는 아이디어는 의심하고, 사람이 반복해서 붙잡고 있는 일은 다시 묻습니다.

“AI가 이 일의 80%를 할 수 있을까?”
“그렇다면 사람은 나머지 20%에서 무엇을 더 잘해야 할까?”

Tokens Never Sleep은 그 질문에서 시작해, 지금도 매일 조금씩 바뀌고 있습니다.

토큰은 잠들지 않습니다.
그래서 우리는 더 중요한 문제를 생각할 수 있습니다.


팀과 여정을 함께할 분들을 찾고 있습니다 → TwelveLabs Careers

우리가 잠든 사이에도 돌아가는 시스템

트웰브랩스가 실행 속도를 복리로 쌓는 방식

트웰브랩스 안에서 요즘 자주 들리는 말이 있습니다.

“Tokens Never Sleep.”

지금은 하나의 슬로건처럼 쓰이고 있지만, 처음부터 슬로건이었던 것은 아닙니다. 시작은 아주 현실적인 질문이었죠.

올해 초, 한 팀원이 LLM과 연결된 재무 도구로 예전에는 몇 주가 걸렸을 분석을 몇 분 만에 해냈습니다. 누군가는 그 장면을 보고 “좋은 데모/사례구나” 하고 넘겼을지도 모르지만, CEO가 본 것은 조금 달랐습니다. AI를 기존 업무에 단순히 덧붙인 것이 아니라, 처음부터 AI를 기반으로 일하는 방식이었습니다.

그 자리에서 질문이 이어졌습니다.

"이걸 다른 데이터와 업무 시스템에도 더 붙일 수 있을까요?”
“모두가 쓸 수 있게 할 수 있을까요?”
“우리가 자는 동안에도 돌아가게 만들 수 있을까요?”

Tokens Never Sleep(TNS)은 그렇게 태어났습니다.

반복적이지만 손이 가는 인지 노동, 예를 들어 티켓 분류, 계정 관리, 업데이트 추적, 회의 준비, 리서치 모니터링 같은 일을 AI 코파일럿과 에이전트가 밤낮없이 처리하고, 사람은 진짜 판단이 필요한 곳에 집중하게 만드는 방식입니다.

이 이니셔티브는 처음부터 원칙도 명확했습니다.

  • 배포하고 피드백으로 다듬을 것. 실행 하나하나가 다음 실행을 더 빠르게 만든다.

  • 데모로 보여줄 수 없는 아이디어는 의심할 것.

  • 무언가를 시작하기 전에 “AI가 이 일의 80%를 할 수 있을까?”를 먼저 물을 것.

트웰브랩스는 지난 1월 말부터 약 3개월 동안 Tokens Never Sleep을 실제 업무 속에서 운영해왔습니다. 처음 질문이 “얼마나 많은 일을 AI에게 맡길 수 있을까?”였다면, 지금의 질문은 조금 달라졌습니다.

더 많은 토큰을 쓰는 것이 무조건 더 높은 생산성으로 이어지지는 않는다는 사실을 깨달았기 때문이죠. 토큰 사용의 피크를 지나온 지금, 이제 중요한 것은 토큰을 얼마나 쓰는가가 아니라, 토큰이 어떤 맥락을 읽고, 어떤 ground truth 위에서 움직이며, 사람의 판단을 어떻게 적재적소에 배치하는가입니다.


모든 건 하나의 코파일럿에서 시작됐다

이 모든 것은 IT 매니저 Rick Mondragon의 코파일럿에서 시작했습니다.

아무리 뛰어난 영상 AI 모델을 만들고 있어도, 한밤중 권한 오류 하나로 엔지니어의 작업이 멈추거나, 서로 다른 타임존 사이의 공백 시간에 내부 도구가 멈춰버리면 생산성은 그대로 끊겨버립니다. Rick은 이 문제를 해결하기 위해, 자신의 역할과 사용하는 도구, 우선순위를 이해하는 코파일럿을 직접 만들었습니다. 티켓 분류, 접근 권한 설정, 보안 모니터링 같은 스킬을 붙여 실제 운영 업무를 위임할 수 있게 된 것입니다.

결과는 수치로 나타났습니다.

  • 일반적인 접근 권한 요청: 8시간 → 15분

  • 신규 입사자 온보딩: 하루 → 10분 검토

  • 일상 IT 티켓의 60%: 사람 손을 거치지 않고 처리

나머지 40%도 코파일럿이 먼저 무엇을 확인했고, 어떤 문제가 발견됐으며, 다음 조치가 무엇인지 정리해서 함께 전달됩니다.

하나의 코파일럿이 분명한 효과를 보이자, 자연스럽게 다음 질문이 따라왔습니다. 코파일럿끼리 연결할 수 있다면 어떨까?


하나의 코파일럿에서 네트워크로

하나의 코파일럿이 분명한 효과를 보이자, 모두가 자기만의 코파일럿을 가질 수는 없을까? 라는 질문은 자연스럽게 따라왔습니다. 그래서 트웰브랩스는 코파일럿끼리 연결되는 커뮤니케이션 레이어를 만들었습니다. 각 구성원이 자신의 역할과 진행 중인 프로젝트, 사용하는 도구, 권한 범위를 이해하는 개인 코파일럿을 가질 수 있도록 말이죠.

예를 들어 샌프란시스코는 새벽 2시이고 서울은 저녁 6시라고 해보겠습니다. 서울의 한 엔지니어가 새로운 내부 도구에서 권한 오류를 만나게 되면, 그 엔지니어의 코파일럿이 문제를 인식하고, Rick의 코파일럿이 가진 프로비저닝 스킬을 호출해 권한 매트릭스를 확인합니다. 동시에 보안 모니터링 스킬과 교차 검증해 시스템 자체의 장애는 아닌지도 확인합니다.

그렇게 몇 분 안에 접근 요청이 해결됩니다. 예전 같으면 엔지니어는 샌프란시스코가 동이 틀때까지 기다려야 했겠지만, 지금은 일의 흐름이 끊기기도 전에 문제가 해결되는 것입니다.

물론 여기서 코파일럿이 서로 협업한다고 해서 사람의 통제 밖에서 멋대로 움직이게 두지는 않습니다. 모든 코파일럿 간 작업은 Slack에서 사람의 승인을 거치고, 판단이 필요한 순간이 오면 코파일럿은 필요한 맥락을 먼저 정리해서 올리고, 사람은 그 위에서 결정을 내리게 되죠.

이 네트워크는 운영 도구를 넘어 내부 빌딩 속도도 바꿨습니다. 재무팀은 대시보드를 만들었고, 채용팀은 소싱 앱을 만들었습니다. 예전 같으면 "검토해볼게요"로 시작해 백로그 어딘가에 들어갔을 아이디어들이, 이제는 몇 시간 안에 실제 운영 도구가 되고 있습니다.


AI를 만드는 팀이 AI로 일했다

Pegasus 1.5를 개발하던 시기, 비슷한 장면들이 제품 개발 현장에서도 펼쳐지고 있었습니다. AI 모델을 만드는 팀이 동시에 AI를 가장 적극적으로 활용하는 팀이기도 했습니다.

Sam(ML Research Scientist)은 학습 초반에 구조적인 문제에 부딪혔습니다. 학습 속도를 대폭 높여주는 Flash Attention 패키지가 트웰브랩스 모델 구조에는 그대로 적용되지 않았습니다. 우회하는 대신, Sam은 Claude Code를 활용해 GPU 커널을 직접 커스텀해서 문제를 해결했습니다.

“Claude Code를 엄청 써서 GPU 커널 같은 거를 직접 짜서 커스텀해서 썼거든요. AI Native 환경에서 일하면 이런 걸 할 수 있구나 싶었어요.”

— Sam, ML Research Scientist

개발 속도도 달라졌습니다. Backend Engineer인 Genie는 Pegasus 1.5의 핵심 기능인 TBM, Time-based Metadata를 이틀 만에 개발했습니다. PRD가 나오면 Technical Document를 먼저 꼼꼼하게 작성하고, 구현은 Claude에게 에이전트로 위임하는 방식이었습니다. 테스트 자동화, 플랫폼 연동, 버그 탐지까지 모두 그 흐름 안에서 처리됐습니다.

수치가 그 차이를 선명하게 보여줍니다. 타임존을 넘나들며 협업했던 이전 프로젝트에서는 2~3주 작업 결과 약 30개의 QA 버그가 나왔지만, 이번 Pegasus 1.5는 개발기간 이틀만에 버그 6개가 발생했습니다.

“실질적으로 코드를 직접 쓰는 시간은 훨씬 많이 줄었고, 어떻게 하면 더 예쁘고 사용하기 좋은 API 스펙을 만들지 이런 건설적인 대화를 할 시간이 훨씬 많아진 것 같아요.”
— Genie, Backend Engineer

단순히 '코드를 더 빨리 쓸 수 있다'에 머무는 이야기가 아닙니다. 개인에게 더 많은 결정권과 더 빠른 루프가 주어질 때, AI는 생산성을 끌어올리는 도구가 아니라 일하는 방식의 기본 전제가 됩니다.

“코딩 에이전트 같은 게 많이 발전하면서 개인의 생산성이 굉장히 올라갔어요. 그러면 이걸 잘 활용하려면 개인한테 결정하고 루프를 돌 수 있는 권한을 빨리빨리 줘야 되거든요.”
— SJ, Machine Learning Engineering Manager


팀의 기억을 시스템으로 만들기: Dan의 두 에이전트

Marengo and Search 팀을 이끌고 있는 Dan은 연구팀 리드로서 늘 고민하던 문제가 있었습니다. 서울과 샌프란시스코에 걸쳐 있는 팀원들, 동시에 진행되는 여러 이니셔티브, 그리고 끊임없이 흘러가는 Linear 티켓, GitHub 커밋, WandB 실험 결과들. 리드로서 팀 전체의 맥락을 놓치지 않으면서 자신의 실무를 해야 한다는 것이 큰 부담이었습니다.

Dan은 이 문제를 구조적으로 풀기로 했습니다. 두 개의 목적이 다른 에이전트를 직접 만든 것입니다.

하나는 Dot입니다. Dot은 팀을 위한 지식 코디네이터로, 매일 아침 팀이 출근하기 전에 Linear 이니셔티브 현황, GitHub 커밋 및 PR 활동, WandB 실험 결과, Notion PRD를 동기화하고 정리합니다. 누군가 “이 이니셔티브 지금 어디까지 왔나요?”라고 물으면, Dot은 여러 시스템에 흩어진 정보를 엮어 팀원들이 같은 맥락을 반복 설명하지 않아도 되게 만드는 것이죠.

다른 하나는 Dan’s OS입니다. Dan 개인의 workflow engine에 가까운 이 에이전트는, 밤사이 쌓인 Slack 멘션을 분류해 아침에 무엇부터 봐야 할지 정리하고, 미팅 전에는 이해관계자 맥락과 최근 의사결정 흐름을 묶어 브리핑으로 올립니다. 새로 올라온 논문이 현재 연구 과제나 제품 로드맵과 연결될 수 있는지도 살핍니다. 무엇이 결정됐는지만 저장하는 것이 아니라, 왜 그렇게 결정됐는지까지 설명을 남깁니다.

그렇게 Dot은 팀의 기억을 담당하고, Dan’s OS는 리더의 판단 맥락을 담당합니다. 두 에이전트는 서로 다른 일을 하지만, 함께 돌아갈 때 하나의 운영체계처럼 작동합니다.

Dan에게는 Slack에 Dot을 위한 scratchpad도 있습니다. 생각을 정리할 때 그곳에 두서없이 적으면, Dot이 이를 받아 정리하고 필요한 흐름으로 연결합니다. 리드의 머릿속에만 남아 있던 생각이 시스템 안으로 들어오고, 팀이 다시 활용할 수 있는 맥락으로 바뀌는 것입니다.

Dan은 에이전트를 쓰면서 관리 업무에 드는 비용이 크게 줄었다고 말합니다. 여기서 말하는 비용은 단순한 시간 비용이 아닙니다. 누가 무엇을 하고 있었는지, 어떤 결정이 어디서 나왔는지, 어떤 논문이 현재 workstream과 연결되는지, 어떤 주제를 재검토해야되는지를 계속 머릿속에 붙잡고 있어야 하는 비용입니다. Dot이 팀의 맥락을 계속 붙잡고 있기 때문에, Dan은 모든 정보를 직접 들고 있는 사람이 아니라 정리된 맥락 위에서 더 중요한 판단을 하는 사람이 될 수 있게 되는 것입니다.


3개월의 기록: 우리가 배운 것

Tokens Never Sleep을 올해 1월 말에 시작해서, 어느덧 3개월이라는 시간이 지났습니다.

처음에는 “AI로 일하면 더 많이, 더 빠르게 할 수 있다”는 기대가 컸습니다. 실제로 많은 일처리가 빨라졌죠. 하지만 3개월이 지난 지금, 조금 더 정교한 것들을 배우게 되었습니다.

첫 번째로, 토큰을 많이 쓴다고 생산성이 사용량에 비례해서 오르지는 않습니다.

에이전트를 돌리는 이유는 사람의 시간과 집중력이 유한하기 때문입니다. 그 유한한 자원을 진짜 판단이 필요한 곳에 쓰기 위해, 반복적이고 맥락 정리가 필요한 일을 에이전트에게 위임하는 것입니다. 핵심은 사용량이 아니라 사용의 방향입니다.

두 번째로, 에이전트보다 데이터가 먼저입니다.

MCP 같은 연결 레이어가 많아지고, Slack, Linear, GitHub, Notion, WandB 같은 시스템을 쉽게 이어 붙일 수 있게 되면서 에이전트가 할 수 있는 일은 빠르게 늘고 있습니다. 하지만 연결이 쉬워졌다고 해서 좋은 결과가 자동으로 나오는 것은 아닙니다.

에이전트를 아무리 잘 만들어도, 그 에이전트가 읽는 데이터가 엉망이면 소용이 없습니다. 똑똑한 사람에게 잘못된 정보의 책을 읽게 하는 것과 같죠.

결국 에이전트의 품질은 데이터의 품질에서 시작합니다. 어떤 문서가 최신인지, 어떤 데이터가 기준인지, 어떤 결정이 확정된 것인지, 어떤 메모가 단지 생각의 흔적인지를 팀 안에서 정리해두는 것. 그것이 시스템 전체의 기반이 됩니다.

좋은 에이전트를 만드는 일은 견고한 ground truth를 만드는 일과 떨어져 있지 않습니다.

세 번째로, 채용의 기준도 달라지고 있습니다.

한국 사무실 지사장인 Hyemin은 이 변화를 채용 분야에서도 체감하고 있습니다.

“3개월 전과 지금 제가 후보자를 보는 기준이 달라졌어요. 예전에는 데이터 정리나 반복 작업을 도와줄 수 있는 사람이 필요했다면, 이제는 그 일의 상당 부분을 에이전트가 할 수 있게 됐거든요. 그러다 보니 지금은 구조를 설계하고 판단을 내릴 수 있는 사람, 에이전트에게 잘 위임하고 결과를 해석할 수 있는 사람을 찾게 돼요.”
— Hyemin Lee, Country Manager- Korea

일하는 방식이 바뀌면, 함께 일하고 싶은 사람의 모습도 바뀝니다.

예전에는 기본적인 데이터 정리나 운영 업무를 도와줄 사람이 필요했다면, 이제 그런 일의 상당 부분은 에이전트에게 맡길 수 있습니다. 대신 사람에게 더 중요해지는 일은 따로 있습니다. 업무의 구조를 설계하는 일, 좋은 입력과 기준을 만드는 일, 사람 사이의 신뢰와 engagement가 필요한 지점을 구분하는 일, 그리고 최종 판단의 책임을 지는 일입니다.

트웰브랩스에서 AI-native하게 일한다는 것은 단순히 AI 툴을 잘 쓴다는 뜻에 머물지 않습니다. 문제를 구조화하고, 견고한 ground truth를 만들고, 반복 가능한 시스템으로 바꾸고, 최종 판단에 대한 책임을 질 수 있다는 뜻에 가깝습니다.


우리는 더 중요한 문제를 생각하기 위해 AI를 쓴다

Tokens Never Sleep은 “AI를 많이 쓰자”는 캠페인이 아닙니다.

우리가 잠든 사이에도 토큰이 돌아가게 만들자는 말이지만, 그 목적은 사람이 더 오래 일하게 만드는 것이라기보단, 사람이 가진 집중력과 판단력을 더 아껴 쓰기 위한 방식입니다.

티켓은 코파일럿이 지켜볼 수 있습니다.
문서는 에이전트가 정리할 수 있습니다.
회의 전 맥락 정리는 시스템이 준비할 수 있습니다.
논문은 밤사이 읽혀 있을 수 있습니다.
반복되는 follow-up은 자동화될 수 있습니다.

하지만 무엇이 중요한 문제인지 정하는 일, 어떤 결정을 내려야 하는지 판단하는 일, 누구와 어떻게 신뢰를 쌓을지 선택하는 일은 여전히 사람에게 남아 있습니다.

트웰브랩스가 지난 3개월 동안 배운 것은 단순합니다.

AI는 사람을 대체하기보다, 사람이 더 잘해야 하는 일을 더 또렷하게 드러냅니다.
토큰은 잠들지 않지만, 토큰이 대신할 수 없는 판단은 여전히 사람의 몫입니다.
그래서 좋은 에이전트를 만드는 일은 곧 더 효율적인 조직 운영 방식을 만드는 일입니다.

우리는 완벽해질 때까지 기다리지 않습니다.
우선 만들고, 실제 업무에 적용하고, 피드백으로 다듬습니다.
데모가 되지 않는 아이디어는 의심하고, 사람이 반복해서 붙잡고 있는 일은 다시 묻습니다.

“AI가 이 일의 80%를 할 수 있을까?”
“그렇다면 사람은 나머지 20%에서 무엇을 더 잘해야 할까?”

Tokens Never Sleep은 그 질문에서 시작해, 지금도 매일 조금씩 바뀌고 있습니다.

토큰은 잠들지 않습니다.
그래서 우리는 더 중요한 문제를 생각할 수 있습니다.


팀과 여정을 함께할 분들을 찾고 있습니다 → TwelveLabs Careers