[태그:] 개발자 도구

6,000만 달러. AI 에이전트용 클라우드를 만드는 뉴욕 스타트업 Daytona Platforms가 FirstMark Growth 주도로 유치한 시리즈 B 금액이다. 기업가치는 10억 달러로 평가받았고, 회사가 밝힌 누적 투자액은 9,100만 달러다. 금액보다 눈여겨볼 것은 이 회사가 파는 상품이다. Daytona의 상품은 AI 모델이 아니다. 에이전트가 코드를 돌리고, 파일을 만들고, 프로그램을 띄우는 ‘작업장’이다. 에이전트가 실제로 일할 컴퓨터를 누가 어떻게 빌려줄지가 모델 경쟁과는 별도로 투자 대상이 됐다는 신호로 읽힌다.

이 글은 투자 소식 자체보다 그 소식이 건드린 질문에 무게를 둔다. 에이전트용 실행 환경은 일반 서버와 무엇이 다른가. 팀이 직접 고른다면 무엇부터 따져야 하나.

에이전트마다 컴퓨터 한 대씩, 에이전트 클라우드의 기본 구조

챗봇의 일은 텍스트로 답하는 데서 끝난다. 에이전트는 다르다. 목표를 받으면 스스로 단계를 쪼개고, 코드를 실행해 결과를 확인하고, 실패하면 고쳐서 다시 돌린다. 이 반복에는 명령을 실행할 운영체제, 중간 결과를 쌓아 둘 디스크, 필요한 패키지를 설치할 권한이 따라붙는다. 말로만 일하는 모델에는 필요 없던 것들이다. 결국 실제 컴퓨터가 있어야 한다는 뜻이다.

에이전트 클라우드는 이 작업 공간을 떼어 내 서비스로 제공하는 인프라다. Daytona 창업자 Ivan Burazin은 투자 발표 블로그 글에서 자사 클라우드가 모든 에이전트에게 각자의 컴퓨터를 한 대씩 쥐여 주는 것과 같다고 설명했다. 그가 밝힌 구성은 이렇다. 한 플랫폼 안에서 샌드박스 형태의 Linux, Windows, macOS 환경과 GPU 등을 함께 쓸 수 있다.

샌드박스는 바깥 시스템과 떨어진 격리 공간을 가리킨다. 안에서 프로그램이 오작동하든 파일이 지워지든, 피해가 다른 사용자나 원래 서버로 번지지 않게 막는 울타리다. 에이전트가 작성한 코드는 사람이 한 줄씩 검토하지 않은 채 실행되는 경우가 많다. 에이전트 실행 환경에서 격리를 ‘있으면 좋은 기능’이 아니라 출발 조건으로 봐야 하는 이유가 여기에 있다.

짧고, 많고, 상태를 가진 작업이 기존 클라우드와 어긋나는 지점

Burazin의 문제 제기는 다음 두 문장에 압축돼 있다. “에이전트는 기존 클라우드가 염두에 두고 설계된, 오래 떠 있는 서비스처럼 일하지 않는다. 에이전트는 아무도 미리 계획하지 않은 짧고 상태를 가진 작업을 수천 개씩 띄우며, 그에 맞게 만든 클라우드가 필요하다.” 그의 주장을 항목별로 나눠 보면 아래 표와 같다.

구분	기존 클라우드가 전제한 작업	에이전트가 만드는 작업
작업의 성격	오래 실행되는 서비스(long-lived services)	짧고 상태를 가진(stateful) 작업
작업이 생기는 방식	클라우드 설계 단계에서 염두에 둔 서비스	아무도 미리 계획하지 않은 작업이 수천 개씩 생성
제공 단위	서비스를 올려 두는 서버	에이전트별 독립 컴퓨터(Linux·Windows·macOS 샌드박스, GPU 등)

첫 번째 차이는 수명이다. 웹 서비스용 서버는 한 번 띄우면 오랫동안 같은 자리에서 요청을 받는다. 클라우드의 과금, 배포, 모니터링 도구도 대부분 이렇게 오래 떠 있는 서버를 기준으로 짜여 있다. 에이전트가 만든 하위 작업은 정반대다. 생겼다가 금방 사라진다.

두 번째는 예측 가능성. 서비스 운영자는 트래픽을 내다보고 용량을 잡는다. 에이전트는 작업 도중 스스로 하위 작업을 만들어 내기 때문에, 실행 환경이 언제 몇 개 필요할지 사람이 미리 알기 어렵다. Burazin이 굳이 ‘아무도 미리 계획하지 않은’이라는 수식어를 붙인 것도 이 때문이다.

세 번째가 상태다. 짧은 작업은 흔히 상태를 남기지 않는 함수 실행 방식으로 처리해 왔다. 에이전트의 작업은 짧으면서도 직전 단계에서 설치한 패키지, 작성 중인 파일, 열어 둔 프로그램을 그대로 이어 써야 한다. 오래 떠 있는 서버 모델과 상태 없는 짧은 실행 모델 사이에 빈틈이 생기는 셈이다. Daytona의 문제의식은 바로 이 빈틈을 겨냥한 것으로 보인다. 다만 이 대목은 창업자 설명을 바탕으로 한 해석이다.

Daytona가 스스로를 ‘장기 실행 에이전트’용 클라우드라고 소개한다는 점은 언뜻 앞의 설명과 엇갈려 보인다. 실은 시간 단위가 두 겹이다. 에이전트 자체는 길게 일하지만, 에이전트가 쪼갠 작업 하나하나는 짧다. 실행 환경을 평가할 때 이 두 가지 시간 단위를 모두 봐야 하는 이유다.

투자자 구성도 같은 맥락에서 읽힌다. 엔젤 명단에는 결제, 전자상거래, 화상회의, 모니터링, AI 검색 분야 기업을 이끄는 인물들이 고루 들어 있다. 이들이 에이전트 실행 인프라에 개인 자금을 넣었다는 것까지가 사실이다. 이를 현업에서 이 문제를 병목으로 보는 시각이 있다는 방증으로 받아들이는 것은 해석의 영역에 속한다.

운영체제부터 과금까지, 실행 환경을 거르는 다섯 기준

Daytona를 포함해 에이전트용 실행 환경을 검토할 때는 용도, 규모, 상태, 보안, 비용 순서로 기준을 세우는 편이 효율적이다. 앞 단계에서 맞지 않는 후보가 먼저 걸러지기 때문이다. 아래 항목은 특정 제품의 사양표가 아니다. 어느 플랫폼에든 똑같이 던질 수 있는 질문 목록이다.

① 에이전트가 하는 일과 필요한 운영체제. 코드 실행과 데이터 처리가 대부분이라면 Linux 샌드박스로 충분한 경우가 많다. 데스크톱 프로그램을 조작하거나, 특정 운영체제에서만 돌아가는 빌드·테스트를 맡길 생각이라면 Windows나 macOS 환경이 있어야 한다. 에이전트가 모델 추론이나 이미지 처리를 직접 한다면 GPU까지 필요하다. 이 가운데 두 가지 이상이 필요해지는 순간, 한 플랫폼에서 함께 제공하는지가 운영 부담을 가른다. 계정과 네트워크 규칙, 접근 권한을 환경마다 따로 관리하면 설정 실수가 끼어들 틈도 그만큼 넓어진다.

② 기동 속도와 동시 실행 한도. 짧은 작업이 대량으로 쏟아지는 구조에서는 실행 환경을 띄우는 시간이 작업 시간보다 길어지는 순간 효율이 크게 떨어진다. 배보다 배꼽이 커지는 셈이다. 확인할 것은 세 가지. 새 샌드박스를 만들어 첫 명령을 실행하기까지 걸리는 시간, 계정당 동시에 띄울 수 있는 샌드박스 수, 그리고 한도를 넘었을 때 요청이 대기열로 가는지 바로 실패하는지다. 에이전트가 하위 작업을 예고 없이 늘린다는 앞의 설명을 떠올리면, 마지막 질문의 무게가 결코 가볍지 않다.

③ 상태 보존과 재개. 작업과 작업 사이에 파일 시스템이 유지되는지부터 본다. 실행 중인 환경을 멈췄다가 같은 상태로 다시 켤 수 있는지, 특정 시점의 상태를 저장해 여러 갈래로 복제할 수 있는지도 관건이다. 에이전트가 같은 출발점에서 여러 해법을 동시에 시험하는 방식으로 일한다면, 복제 기능이 있느냐 없느냐에 따라 체감 성능이 달라진다.

④ 격리 강도와 권한 통제. 같은 ‘샌드박스’ 간판을 달고 있어도 운영체제 커널을 공유하는 컨테이너 방식과 가상머신 단위로 떼어 내는 방식은 격리 강도가 다르다. 이름만 보고 판단해서는 안 되는 대목이다. 외부 인터넷 접속을 막거나 허용 목록으로 제한할 수 있는지, API 키 같은 비밀 정보를 어떤 경로로 넣는지, 작업이 끝난 뒤 디스크 데이터를 언제 지우는지도 함께 따져야 한다. 에이전트가 외부 웹페이지를 읽고 그 내용에 따라 명령을 실행하는 구조라면 한층 보수적으로 접근할 필요가 있다. 악의적인 지시가 섞여 들어오는 경우까지 가정하고 네트워크와 권한을 좁혀 두는 편이 안전하다.

⑤ 과금 단위와 비용 예측. 짧은 작업이 많을수록 최소 과금 단위가 청구서를 크게 좌우한다. 사용 시간을 어떤 단위로 끊어 계산하는지, 멈춰 둔 환경에도 요금이 붙는지, 저장 공간과 GPU를 따로 과금하는지 확인해야 한다. 에이전트는 사람이 예상하지 못한 만큼 작업을 불릴 수 있다. 계정 단위로 지출 상한을 걸 수 있는지가 단순한 편의 기능으로 끝나지 않는 이유다. 해외 서비스를 달러로 결제한다면 환율 변동도 비용 예측에 넣어 둬야 한다.

다섯 기준 가운데 ②와 ⑤는 뿌리가 같다. ‘짧은 작업이 많다’는 하나의 구조가 한쪽에서는 기동 시간 문제로, 다른 쪽에서는 최소 과금 단위 문제로 드러난다. 두 항목을 따로 점검하기보다 한 묶음으로 계산하는 편이 맞다.

한국 팀이라면 국외 이전 규정과 왕복 지연부터

데이터가 국경을 넘는지. 에이전트 샌드박스에는 사내 소스코드와 내부 문서, 경우에 따라서는 고객 데이터까지 들어간다. 해외 지역에서 실행되는 서비스로 개인정보가 담긴 데이터를 넘긴다면 국외 이전에 관한 국내 규정을 먼저 검토해야 한다. 사내 보안 정책이 외부 실행 환경 사용을 제한하는 조직이라면, 도입 논의에 앞서 보안 심사부터 거치는 것이 순서다.

네트워크 지연이 쌓이는지. 샌드박스가 한국에서 먼 지역에서 돈다면, 짧은 작업을 수없이 주고받는 구조 자체가 약점이 될 수 있다. 한국과 실행 지역 사이의 왕복 지연이 작업마다 더해지면서 전체 처리 시간이 늘어나는 식이다. 어디까지나 구조에서 끌어낸 추정이고, 실제 영향은 파일럿에서 측정해 확인해야 한다.

Samsung Next의 참여가 곧 한국 지원을 뜻하지는 않는다. 이번 라운드에는 Qualcomm Ventures, Okta Ventures와 함께 삼성 계열 투자사인 Samsung Next가 이름을 올렸다. 투자 사실까지는 확인된다. 이것이 국내 서비스 연동이나 협력으로 이어질지는 별개의 문제다. 투자자 명단 한 줄만 보고 한국 지원이 강화되리라 기대하기는 이르다.

확인된 것과 아직 불확실한 것

확인된 것

• Daytona Platforms는 뉴욕에 기반을 둔 스타트업이다. FirstMark Growth 주도로 6,000만 달러 시리즈 B를 유치했고, 기업가치는 10억 달러다.
• 회사가 밝힌 누적 투자액은 9,100만 달러다. FirstMark는 앞선 2,400만 달러 시리즈 A도 주도했다.
• 엔젤 투자자로 Patrick Collison(Stripe), Tobi Lütke(Shopify), Aravind Srinivas(Perplexity), Eric Yuan(Zoom), Olivier Pomel(Datadog), Adam D’Angelo(Quora, OpenAI 이사회 멤버), Brendan Foody(Mercor)가 참여했다. Qualcomm Ventures, Samsung Next, Okta Ventures도 이름을 올렸다.
• Daytona는 장기 실행 에이전트를 위한 클라우드를 내세우며, 한 플랫폼에서 Linux·Windows·macOS 샌드박스와 GPU 등을 제공한다고 밝혔다.

아직 불확실한 것

• 샌드박스 기동 시간, 동시 실행 한도, 격리 방식 같은 기술 세부는 원문에 담기지 않았다.
• 요금 체계와 과금 단위는 공개된 자료로 확인되지 않는다.
• Daytona가 한국 지역 서버, 원화 결제, 한국어 지원을 제공하는지는 알려진 바가 없다.
• 새 투자금의 쓰임새와 Samsung Next 등 기업 투자자와의 사업 협력 여부는 밝혀지지 않았다.
• 에이전트 전용 클라우드가 독립된 시장으로 자리 잡을지, 대형 클라우드의 한 기능으로 흡수될지는 지켜봐야 할 대목이다.

계약서에 서명하기 전, 파일럿으로 재 볼 다섯 항목

기준을 세웠다면 남은 일은 측정이다. 실제 에이전트 작업 하나를 골라 짧은 파일럿을 돌려 보는 것이 가장 확실하다. 소개 자료에 적힌 수치보다 자기 작업 패턴에서 나온 측정값이 더 정확하기 때문이다. 기동 시간이나 동시 실행 한도 같은 기술 세부가 이번 원문에 빠져 있다는 점을 감안하면, 파일럿의 비중은 더 커질 수밖에 없다.

• 첫 명령까지 걸리는 시간: 새 샌드박스 생성을 요청한 시점부터 첫 명령의 결과가 돌아올 때까지를 여러 번 잰다. 평균만 보지 말고 최댓값도 함께 본다.
• 동시 실행 내구성: 평소 예상하는 동시 작업 수의 몇 배를 한꺼번에 띄워, 실패율과 대기 시간을 기록한다.
• 상태 복원: 패키지를 설치하고 파일을 만든 뒤 환경을 멈춘다. 다시 켰을 때 같은 상태로 돌아오는지 확인한다.
• 네트워크 차단 실효성: 허용 목록 밖의 주소로 접속을 시도해, 실제로 막히는지 시험한다.
• 비용 환산: 파일럿 사용량을 실제 운영 규모로 늘려 월 비용을 추정하고, 지출 상한 설정이 제대로 작동하는지 확인한다.

작업이 짧고 잦아질수록 환경을 띄우고 격리하는 비용은 계속 쌓인다. 에이전트가 맡는 일이 늘어날수록 병목이 모델의 답변 품질에서 실행 환경의 속도와 안전성 쪽으로 옮겨 갈 가능성이 크다고 보는 이유다. Daytona에 붙은 10억 달러라는 가격표는 투자자들이 이 변화에 먼저 값을 매긴 결과로 볼 수 있다. 여기까지는 해석이다. 어떤 플랫폼이 맞는지는 기업가치가 아니라 팀의 작업 패턴이 결정하고, 그 답은 파일럿에서 나온 숫자가 준다.

출처: TechCrunch