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

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

트웰브랩스가 ‘완벽’보다 ‘속도’를 선택하는 방식

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

“Tokens Never Sleep.”

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

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

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

“이걸 더 많이 연결할 수 있을까요?”
“모두가 쓸 수 있게 할 수 있을까요?”
“우리가 자는 동안에도 돌아가게 만들 수 있을까요?”

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

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

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

완벽해질 때까지 기다리는 대신, 일단 배포하고 피드백으로 다듬을 것.
데모로 보여줄 수 없는 아이디어는 의심할 것.
무언가를 시작하기 전에 “AI가 이 일의 80%를 할 수 있을까?”를 먼저 물을 것.

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

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

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

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

AI 회사에서 IT는 생각보다 훨씬 더 중요합니다. 아무리 뛰어난 영상 AI 모델을 만들고 있어도, 누군가의 계정이 제때 열리지 않거나, 한밤중 권한 오류 하나로 엔지니어의 작업이 멈추거나, 서로 다른 타임존 사이의 공백 시간에 내부 도구가 멈춰버리면 생산성은 그대로 끊겨버리기 때문입니다.

기존 IT 운영 방식은 대개 티켓 큐와 SLA를 중심으로 돌아갑니다. 누군가 요청을 넣고, 대기열에 쌓이고, 영업시간에 사람이 확인하고, 다시 몇 번의 커뮤니케이션이 오가죠. 하지만 서울과 샌프란시스코처럼 여러 타임존에 걸쳐 움직이는 조직에서는 이런 방식이 금세 한계에 부딪힙니다.

그래서 Rick은 자신의 역할과 사용하는 도구, 우선순위를 이해하는 코파일럿을 만들었습니다.

티켓 분류, 접근 권한 설정, 계정 관리, 보안 모니터링, 디바이스 관리 같은 스킬을 붙여, 실제 운영 업무를 맡길 수 있는 코파일럿을 만든 것입니다.

그리고 이건 실제로 숫자로 증명되는 효과가 있었습니다.

일상적인 접근 권한 요청은 8시간 걸리던 처리 시간이 15분 수준으로 줄었습니다.
신규 입사자 온보딩은 관리 콘솔을 일일이 열어보며 하루를 쓰던 일에서, 10분 검토로 끝나는 프로세스로 바뀌었습니다.
새로 합류한 사람들은 첫날부터 필요한 도구를 모두 사용할 수 있게 됐습니다.
그리고 일상적인 IT 티켓의 60%는 사람 손을 거치지 않고 닫히게 되었습니다.

나머지 40% 역시 그냥 사람의 큐로 넘어오는 것이 아니라, 무엇을 확인했고, 어떤 문제가 발견됐고, 다음으로 어떤 조치가 필요한지까지 정리된 상태로 들어옵니다. 말 그대로 시스템이 하루 종일 티켓을 지켜보고 있는 셈입니다.

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

하나의 코파일럿이 분명한 효과를 보이자, 모두가 자기만의 코파일럿을 가질 수는 없을까? 라는 질문은 자연스럽게 따라왔습니다.

그래서 트웰브랩스는 코파일럿끼리 연결되는 커뮤니케이션 레이어를 만들었습니다. 각 구성원이 자신의 역할과 진행 중인 프로젝트, 사용하는 도구, 권한 범위를 이해하는 개인 코파일럿을 가질 수 있도록 말이죠.

하지만 이 시스템은 단순히 “모두에게 챗봇 하나씩 주는 것”과는 다릅니다. 각 코파일럿이 서로의 스킬을 찾고, 필요한 작업을 서로에게 넘길 수 있기 때문입니다.

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

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

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

문제 해결 방식도 비슷합니다. “이 내부 앱이 좀 이상해요”같은 모호한 제보는 실제 운영에서 생각보다 자주 발생합니다. 하지만 이제 코파일럿 네트워크는 그 “이상함”을 애매한 상태로 남겨두지 않습니다. 시스템 로그, 최근 변경 사항, 과거의 유사 사례를 함께 엮어 사람이 보기 전에 이미 진단 가능한 문제로 바꿔놓죠.

그렇게 구성원들은 애매모호한 요청들이 아니라, 무엇이 왜 문제인지에 대한 정리된 맥락을 마주하게 됩니다.

해결사를 넘어, 빌더로서의 IT

이 과정에서 IT의 역할도 달라졌습니다.

Tokens Never Sleep은 세 가지 원칙 위에서 움직입니다.

Speed Over Perfection.
완벽하게 다듬을 때까지 기다리기보다, 몇 시간 안에 배포하고 피드백으로 반복 개선합니다.

Demo-Driven Development.
말로만 설명할 수 있고 데모로 보여줄 수 없다면, 정말 할 만한 가치가 있는지 의심합니다.

AI-First Thinking.
어떤 작업이든 시작하기 전에 “AI가 이 일의 80%를 처리할 수 있을까?”를 먼저 묻습니다.

특히 마지막 원칙이 트웰브랩스에서 IT의 역할을 바꿔놓았습니다.

예전에는 “이걸 추적하는 간단한 대시보드 하나 가능할까요?” 혹은 “이런 기능 되는 도구 없을까요?” 같은 요청이 들어오면, 답은 늘 비슷했습니다.

“검토해볼게요.”
“도구를 알아볼게요.”
“구매 절차를 확인해볼게요.”
“엔지니어링 팀에 요청해볼게요.”

그러다 보면 2주가 지나거나, 한 달 뒤 백로그 어딘가에 들어가는 식이었죠.

이제는 내부 도구를 단 몇 시간 안에 만듭니다. 그리고 이건 IT뿐만이 아니라, 사내 여러 팀의 업무 방식을 바꿔놨습니다. 재무팀은 대시보드를 만들었고, 채용팀은 소싱 앱을 만들었습니다. 예전 같으면 사이드 프로젝트로 끝났을 아이디어들이 실제 운영 도구가 되어가고 있는 것입니다.

덕분에 IT팀도 예전에는 “확인해보고 다시 말씀드릴게요”라고 말하던 팀이었다면, 이제는 “일단 하나 보여드릴게요”라고 말할 수 있는 팀이 됐습니다. 코파일럿이 유지보수와 긴급 대응을 맡아주면서, 예전에는 많은 시간을 잡아먹던 반복 업무와 급한 불 끄는 역할이 크게 줄어들었기 때문입니다.

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

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

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

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

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

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

ENS Pod를 이끌고 있는 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은 에이전트를 쓰면서 관리 업무에 드는 비용이 크게 줄었다고 말합니다. 여기서 말하는 비용은 단순한 시간 비용이 아닙니다. 누가 무엇을 하고 있었는지, 어떤 결정이 어디서 나왔는지, 어떤 논문이 현재 workstream과 연결되는지, 어떤 논의가 다시 surface되어야 하는지를 계속 머릿속에 붙잡고 있어야 하는 비용입니다.

Dot이 팀의 맥락을 계속 붙잡고 있기 때문에, Dan은 모든 정보를 직접 들고 있는 사람이 아니라 정리된 맥락 위에서 더 중요한 판단을 하는 사람이 될 수 있게 되는 것입니다.

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

토큰은 잠들지 않습니다.
그리고 그 덕분에 우리는 더 중요한 문제를 생각할 시간이 생겼습니다.

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

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

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

첫 번째로, 토큰을 많이 쓴다고 생산성이 자동으로 오르지는 않습니다.

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

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

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

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

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

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

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

Operations와 Recruiting 업무를 보는 Hyemin은 이 변화를 채용 현장에서도 체감하고 있습니다.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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