회사 전체가 한 명의 사람과 하나의 그래픽 카드(graphics card)로 이루어져 있습니다.

Linear에는 13개의 프로젝트가 있습니다. 수익을 창출하는 3개의 라이브 제품, 제작 중이며 유료 고객을 위해 매일 게시물을 올리는 4번째 제품이 있습니다. 모든 풀 리퀘스트(pull request)가 검토되고, 모든 배포(deploy)가 승인되며, 모든 인보이스(invoice)가 오클랜드(Oakland)의 동일한 책상에서 발송됩니다. 이를 가능하게 하는 인력은 소프트웨어입니다. 즉, 제가 잠든 동안 조사하고, 초안을 작성하고, 게시하고, 테스트하고, 감사(audit)하는 에이전트(agents)들입니다.

이것이 해당 구조의 운영(ops) 현실입니다. 비전 덱(vision-deck) 버전이 아닙니다. 실패 모드(failure modes)가 포함된 버전입니다. 왜냐하면 실패 모드야말로 모든 실제 교훈이 존재하는 곳이기 때문입니다.

이것이 어디에서 왔는가

저는 버클리(Berkeley)의 소매 매장에서부터 Sonus Faber의 북미 지역 운영에 이르기까지, 하이엔드 오디오 분야에서 20년 이상을 보냈습니다. 이 산업의 전체적인 학문은 노이즈가 있는 체인(chain)을 통해 깨끗한 신호를 쫓는 것입니다. 18년 차쯤 되었을 때, 저는 그것이 회사를 운영하는 것에 대한 적절한 설명이기도 하며, 제 삶의 노이즈 체인이 더 이상 아날로그가 아니라는 사실을 깨달았습니다.

그래서 이제 저는 소프트웨어를 만듭니다. 조직도(org-chart) 관점에서는 혼자입니다. 하지만 새벽 3시에 연구 에이전트(research agents)들이 무역 간행물을 읽고, 구성 파이프라인(compose pipeline)이 게시물을 초안 작성하며, 테스트 스위트(test suites)가 어젯밤의 머지(merges)를 대상으로 실행되고 있을 때, 중요한 의미에서의 혼자는 아닙니다.

운영의 형태

포트폴리오는 명확합니다. HiFi 소매업체를 위한 마케팅 엔진, 트레이더와 투자자를 위한 실시간 대시보드, 자동화된 일일 브리프(daily brief)를 발송하는 AI 하드웨어 정보 허브, 그리고 실제 비용을 지불하고 실제 게시물을 기대하는 첫 번째 고객인 하이엔드 오디오 딜러를 위해 매일 초안을 작성하고 게시하는 소셜 포스팅 엔진입니다.
이 모든 것은 단 하나의 RTX 5090이 장착된 하나의 Windows 워크스테이션과, 제가 '캡틴 대시보드(captain dashboard)'라고 부르는 하나의 제어 평면(control plane)을 통해 실행됩니다. 그 아래에는 이미지 생성, 비디오 생성, 3D, 학습(training), 전사(transcription), 로컬 LLM 서빙(serving) 등 19개의 관리되는 앱이 존재합니다. 대시보드는 무엇이 실행 중인지, 각 프로세스가 얼마만큼의 VRAM을 점유하고 있는지, 그리고 무엇이 대기열(queue)에 있는지 알고 있습니다.
마지막 부분은 들리는 것보다 훨씬 더 중요합니다.

하나의 GPU, 다수의 에이전트, 하나의 뮤텍스 (mutex)

아무도 경고해주지 않는 문제가 여기에 있습니다. 에이전트들은 예의 바르게 차례를 기다리지 않습니다. 만약 세 개의 파이프라인(pipelines)이 동시에 GPU가 필요하다고 결정한다면, 단순히 세 개의 작업이 느려지는 것이 아닙니다. 메모리 부족(out-of-memory) 충돌, 절반만 로드된 모델, 그리고 유용한 작업은 아무것도 실행되지 않으면서 할당량만 가득 차 있다고 보고하는 그래픽 카드를 마주하게 됩니다.
해결책은 부끄러울 정도로 구식인 뮤텍스(mutex)였습니다. 'gpu-heavy' 태그가 붙은 모든 작업은 그래픽 카드에 접근하기 전에 반드시 잠금(lock)을 획득해야 하며, 그 외의 모든 것은 대기합니다. 제 에이전트들은 엔지니어들이 커피 머신을 기다리는 것처럼, 투덜거리면서도 질서 정연한 줄을 서서 한 번에 하나씩 VRAM을 기다립니다.
두 번째 해결책은 위생(hygiene)입니다. Windows에서 강제 종료된 프로세스는 GPU 할당량이 유령처럼 남아있는 동안 아주 기쁘게(?) 죽어버립니다. 그래서 모든 세션은 동일한 방식으로 시작됩니다. 카드를 점검하고, 좀비 프로세스를 찾아내고, 포트(port)가 아닌 프로세스 경로(process path)를 통해 그들을 종료합니다. 충돌한 프로세스는 아무런 신호도 받지 않으면서 메모리만 점유하고 있기 때문입니다. 이것은 회사 전체에서 가장 매력적이지 않은 의식이지만, 이를 건너뛰는 대가는 제가 저지르는 그 어떤 단일 실수보다 더 많은 시간을 소모하게 만듭니다.

에이전트가 실제로 하는 일

마케팅용 목록이 아닌, 솔직한 목록은 다음과 같습니다:

• 리서치 (Research). 매일 밤, 에이전트들은 각 제품의 타겟 고객에게 중요한 출판물들을 읽고 변경된 사항을 추출합니다. 포스팅 엔진(posting engine)의 경우, 사용자가 잠든 동안 고객의 산업 분야를 모니터링한다는 것을 의미합니다.
• 초안 작성 (Drafting). 포스트, 브리핑, 코드, 마이그레이션(migrations). 초안이 복수형인 이유는 대부분 검토 과정에서 폐기되기 때문이며, 그것이 바로 시스템이 설계된 대로 작동하고 있다는 증거입니다.
• 테스트 및 감사 (Testing and auditing). 머지(merge) 시에 테스트 스위트(suites)가 실행됩니다. 그 외에도, 저는 에이전트 군집(agent swarm)을 제 운영 중인 SaaS의 감사자로 지정했는데, 이들이 제가 보지 못했던 실제 문제들을 찾아냈습니다. 이 이야기는 별도의 글로 다룰 가치가 있으며, 현재 작성 중입니다.
• 검증을 포함한 발행 (Publishing with verification). 포스팅 엔진은 스스로를 신뢰하지 않습니다. 성공적인 API 응답은 요청에 대한 영수증일 뿐, 포스트가 실제로 존재한다는 증거는 아니기에, 이후에 조정(reconcile) 단계를 거쳐 플랫폼의 실제 상태를 확인합니다.
• 기억하기 (Remembering). 이 부분은 해결하는 데 너무 오래 걸렸습니다. 에이전트들이 다른 에이전트가 이미 학습한 내용을 계속해서 다시 학습했기 때문입니다. 그래서 저는 약 450개의 메모리 파일에 대해 의미론적(semantic) 및 키워드 검색이 가능한 공유 메모리 레이어인 memsearch를 구축했습니다. 이제 알려진 함정에 빠진 에이전트는 이전 에이전트가 남겨둔 메모를 찾아낼 수 있습니다.

인간이 유지하는 것

다음 세 가지는 위임되지 않으며, 이 목록은 의도적으로 선정되었습니다.

• 승인 (Approvals). 고객과 접점이 있는 그 어떤 것도 저의 승인 없이는 라이브되지 않습니다. 포스팅 엔진이 초안을 작성하지만, 인간이 모든 포스트에 대해 승인 버튼을 누릅니다. 이것은 우리가 사과해야 할 한계가 아니라 설계 결정이며, 제 유료 고객들이 가장 중요하게 생각하는 지점입니다.
• 취향 (Taste). 에이전트는 초안이 문법적으로 맞고 근거가 확실한지는 말해줄 수 있습니다. 하지만 그 초안이 지루하다거나, 다른 모든 사람의 피드와 똑같이 들린다는 점은 말해주지 못합니다. 취향은 해자(moat)이며, 취향은 일괄 처리(batch)될 수 없습니다.
• 책임 (Accountability). 무언가 고장 나면 고객은 사람에게 이메일을 보내고, 그 사람이 답장합니다. 고객 #1과 저 사이에는 1차 지원(tier-one support) 봇이 존재하지 않습니다.

만약 파이프라인이 그의 게시물을 누락시킨다면, 그는 저로부터 즉각적인 피드백과 함께 해결책을 직접 듣게 됩니다. 제가 회사 전체에 대해 명시한 운영 규칙은 다음과 같습니다: 매일 하나의 대시보드를 확인하고, 진정으로 인간의 개입이 필요한 항목만 처리하며, 아이디어가 떠오르면 즉시 실행하고 완료될 때까지 추진하는 것입니다. 대부분의 날에는 이 규칙이 유지됩니다. 이 규칙이 지켜지지 않는 날들에 대해 다음 섹션에서 다루겠습니다.

솔직히 말해서 드는 비용

무료 API 키 사건. 일정 기간 동안 게시 엔진의 LLM (Large Language Model) 호출이 분당 5회로 속도 제한(rate-limited)이 걸린 무료 티어 API 키로 실행되었습니다. 반면, 크레딧이 충전되어 즉시 사용할 수 있는 유료 조직 계정은 완전히 유휴 상태로 방치되어 있었습니다. 증상은 마치 아키텍처(architecture) 문제처럼 보이는 429(Too Many Requests) 에러의 폭풍이었습니다. 저는 동시성 버그(concurrency bugs)나 백프레셔(backpressure) 설계 결함을 찾아 헤맸습니다. 실제 해결책은 프로덕션(production) 환경이 어떤 키를 보유하고 있는지 확인하는 것이었습니다. 교훈: 에이전트 인력이 제대로 작동하지 않을 때는 지루한 것부터 먼저 확인하세요. 왜냐하면 그 지루한 것이 정답이라 해도 부끄러워하지 않기 때문입니다.

모든 것을 거부한 게이트. 게시 엔진에는 사실 관계를 검증하는 게이트(gate)가 있습니다: 초안은 피드(feed)에 올라가기 전에 반드시 출처에 근거하여 주장을 입증해야 합니다. 어느 시점에는 그 게이트가 초안의 100%를 거부했습니다. 대부분이 아니라, 전부였습니다. 알고 보니 84자 길이의 헤드라인을 기준으로 전체 캡션(caption)을 평가하고 있었기에, 실제로 무언가를 말하는 모든 캡션은 실패했고, 아무 말도 하지 않는 캡션이 가장 높은 점수를 받았습니다. 공허함을 보상하는 품질 게이트는 게이트가 없는 것보다 더 나쁩니다. 우리는 지루한 방식으로 이를 해결했습니다: 게이트에 티저(teaser)가 아닌 전체 소스 텍스트(source text)를 제공하는 것입니다.

살아남은 지표. 충분한 사건을 겪고 나면 중간 신호(intermediate signals)를 신뢰하지 않게 됩니다. 큐(queue)는 아무것도 배송되지 않는 동안에도 건강해 보일 수 있습니다. 대시보드는 게시물이 하나도 올라가지 않는 동안에도 리듬(cadence)이 충족되었다고 말할 수 있습니다. 유료 계정에 대해 제가 이제 완전히 믿는 유일한 숫자는 '게시된 수(landed)가 0보다 크다'는 것입니다. 오늘 그 작업이 실제로 플랫폼에 나타났는가? 그 질문에 대한 답의 상류(upstream)에 있는 모든 것은 가설일 뿐입니다.

진정한 병목 현상 (bottleneck). 사람들은 1인 소프트웨어 기업의 제약 사항이 생성 능력 (generation capacity)이라고 가정합니다. 하지만 그렇지 않으며, 이미 오래전부터 그렇지 않았습니다. 에이전트 (Agents)는 지치지 않습니다. 병목 현상은 검토 규율 (review discipline)입니다. 즉, 에이전트가 생성한 결과물을 온전한 주의력을 기울여 읽고, 미묘한 오류를 잡아내며, 승인 단계가 단순히 형식적인 절차 (rubber stamp)로 전락하지 않도록 유지하는 저의 능력입니다. 승인이 반사적인 동작이 되는 날은 전체 모델이 조용히 실패하는 날이며, 그 순간에는 어떤 경보도 울리지 않습니다. ## 만약 당신이 이를 고려하고 있다면

• 인력 (workforce)을 구축하기 전에 제어 평면 (control plane)을 구축하십시오. 무엇이 실행 중이고 무엇이 막혀 있는지 답해주는 하나의 대시보드가 다음 세 명의 에이전트보다 더 가치 있습니다.
• 희소한 자원을 명시적으로 직렬화 (Serialize) 하십시오. 하나의 GPU는 하나의 뮤텍스 (mutex)를 의미합니다. 스케줄러 (schedulers)가 충돌하지 않기를 바라는 것은 전략이 아니라 카운트다운입니다.
• 에이전트들에게 조기에 공유 메모리 (shared memory)를 부여하십시오. 단 하나의 에이전트가 배운 모든 교훈은 당신의 회사가 다시 비용을 지불하게 될 교훈입니다.
• 실패뿐만 아니라 부재 (absence)를 계측 (Instrument) 하십시오. 오류는 당신에게 페이지를 호출하지만, 침묵은 그렇지 않으며, 그 침묵은 매우 값비싼 대가를 치르게 합니다.
• 승인, 취향, 그리고 책임 (accountability)은 인간의 영역으로 남겨두십시오. 그리고 세 번째 요소가 확장 가능하다 (scales)고 말하는 누구든 의심하십시오.

이 중 어느 것도 홍보 문구가 아닙니다. 여기서 언급된 제품들은 단지 운영 중인 시스템일 뿐이며, 이러한 구조로 인해 저는 실제 운영 사고를 겪었고, 며칠 동안 유령 아키텍처 문제를 추적했으며, 속도 제한기 (rate limiter)와 매우 겸허해지는 대화를 나누기도 했습니다. 하지만 이 구조는 작동하기도 합니다. 한 명의 사람, 하나의 GPU, 13개의 프로젝트, 그리고 스탠드업 (standup) 미팅을 요구하지 않는 인력. 이제부터 진짜 재미있는 부분이 시작됩니다.