Datadog가 Claude Code용 '범용 공작 기계'를 구축한 방법

에이전트, 기계화, 그리고 산업화

Datadog의 모든 엔지니어는 프로덕션 코드 작업에 AI 코딩 도구를 활용하며, 그 중 최소 3분의 2는 Claude Code로 처리한다. Claude Code를 통해 소프트웨어 개발 수명주기(SDLC) 내에서 네 가지 유형의 맞춤형 플로우를 만들어낸다.

• 타겟 변경: 난도 높은 버그 수정, 성능 최적화, 기존 서비스 연동 작업 수십 건.
• 대규모 리팩토링: 커스텀 프로토버프 파서를 사흘 만에 리팩토링하고, 메트릭 컨트롤을 FoundationDB에서 Postgres로 석 달 이내에 재작성.
• 주요 부분 교체: 새로운 샤딩 알고리즘 도입 및 오토스케일링 재설계.
• 전체 시스템 구축: MongoDB를 Postgres로 교체, BYOC 컨트롤 플레인, 인제스천 파이프라인을 처음부터 새로 구축.

그런데 작업이 이 범위 전반으로 확장되면서 한 축으로는 생성 복잡도가, 다른 축으로는 검증 불확실성이 함께 높아지는 양상이 나타났다.

플로우 문제

엔지니어에게 플로우란 원래 의도와 코드 사이의 직접적인 관계를 의미했다. 문제를 파악하고, 코드를 작성하고, 테스트하고, 리뷰하고, 배포하고, 운영하는 과정을 반복하는 것이다. 에이전트의 등장으로 이 추상화 구조는 빠르게 바뀌고 있다.

"이제 코드를 직접 작성하는 게 아니라 작업 자체를 설계합니다. 에이전트가 무엇을 봐야 하는지, 어떤 도구를 써야 하는지, 성공의 기준은 무엇인지, 실패를 어떻게 감지할지를 결정하는 거죠. 마치 모든 엔지니어가 원하지도 않았는데 갑자기 세 단계씩 승진해서 관리자가 된 것 같은 느낌입니다"라고 Datadog 엔지니어링 부사장 Sesh Nalla는 말한다.

Claude Managed Agents와 같은 방식을 도입하면서 Datadog의 세션은 때로는 며칠씩 이어질 만큼 길어졌다. 각 에이전트는 자체적인 도구, 글루 코드(glue code), 컨벤션을 직접 만들어낸다. 에이전트의 활용도는 크게 높아졌지만, 에이전트 실행 결과와 인간을 위해 설계된 도구 사이의 간극을 메우는 데는 여전히 사람의 개입이 필요하다.

공작 기계(machine tool)는 제조 현장에서 볼 수 있는 지그(jig), 고정구(fixture), 게이지(gauge), 밀링 머신(mill) 같은 장비들이다. 이 기계들은 정밀하고 반복 가능한 부품을 생산하며, 이 부품들이 모여 엔진, 항공기, 원자로, 달 착륙선처럼 더 크고 복잡한 기계를 이룬다. 부품이 조합 가능하고, 검사 가능하며, 교체 가능해지면서 공작 기계는 산업화의 핵심 돌파구가 되었다.

Sesh가 설명하는 Temper는 에이전트 시스템을 위한 범용 공작 기계를 구현하려는 Datadog의 시도다. 에이전트가 안전하고 정밀하게 필요한 것을 구축할 수 있도록 하는, 최소한의 커널이라고 할 수 있다.

"이 시점에서 더 구조적인 무언가가 필요하다고 느꼈습니다"라고 Sesh는 말한다. "에이전트가 우리 시스템과 데이터베이스, 즉 미션 크리티컬한 영역의 상당 부분을 구축하고 운영하게 된다면, 공작 기계에 해당하는 개념이 반드시 필요합니다. Temper는 Datadog에게 바로 그런 공작 기계입니다."

Temper에 이르는 길

기계화는 에이전트가 더 많은 작업을 직접 수행하는 것이고, 산업화는 그 작업이 반복 가능하고 검증·통제·확장 가능해지는 것이다. Datadog에서 이 과정은 한 번에 이루어지지 않았다. Temper에 이르기까지 Courier, BitsEvolve, Helix라는 세 프로젝트를 거쳤고, 각 프로젝트는 다음 단계의 병목을 드러내는 동시에 더 큰 목표를 향한 발판이 됐다.

2024년, 분산 큐잉 시스템인 Courier를 도입했다. 처음부터 끝까지 직접 손으로 구축하는 데 꼬박 1년이 걸렸다.

"어려운 부분은 개별 구성 요소를 만드는 것이 아니라, 그 요소들 간의 상호작용을 관찰 가능하고 테스트 및 검증 가능하게 만드는 것이었습니다. 그래서 공식 모델링과 시뮬레이션에 철저히 공을 들였고, 실수했을 때 비용이 크거나 되돌리기 어려운 부분을 식별해 그 부분의 엄밀함을 높였습니다"라고 Sesh는 말한다.

2025년 9월에는 폐쇄 루프 방식의 진화적 최적화 하니스(harness)인 BitsEvolve를 구축했다. 여러 모델로 구성된 위원회가 코드 변형을 생성하고, 벤치마크(benchmarks), 테스트, 프로덕션 가관측성이 연쇄적으로 작동하며 살아남을 코드를 결정하는 구조다.

"소프트웨어의 일부가 마치 살아있는 유기체처럼 — 변이와 피드백, 적응을 통해 성장하도록 — 배양될 수 있다는 것을 처음으로 엿본 순간이었습니다"라고 Sesh는 회상한다.

문제는 진화의 품질이 그것이 적응하는 환경에 달려 있다는 점이었고, BitsEvolve의 병목은 바로 이 피드백 루프였다. 그래서 Kafka에 필적하는 스트리밍 서비스 Helix를 구축했다. 한 명의 엔지니어가 방향을 잡아주면서 Claude Code가 대부분의 구축 작업을 담당했다.

"믿기 어려웠지만, 불과 며칠 만에 Kafka에 필적하는 완전한 기능의 시스템이 완성됐습니다"라고 Sesh는 말한다. "[빠르게 구축한 뒤] 섀도잉을 시작했더니 비용을 2~5배까지 절감할 수 있는 기회가 보이기 시작했습니다."

하지만 실제 프로덕션에 올리는 데는 훨씬 더 많은 시간이 필요했다. 운영 수준의 견고함은 한 사람의 노력만으로는 부족하고 시간이 쌓여야 얻어지는 것이었으며, 지금도 롤아웃이 진행 중이다.

"병목이 또 한 번 이동했습니다. 에이전트가 시스템의 상당 부분을 구축할 수 있게 됐지만, 그 결과물을 프로덕션에 배포하는 과정에서는 여전히 사람이 인간 중심으로 설계된 도구와 프로세스에 맞춰 협력해야 했습니다"라고 Sesh는 설명한다.

Datadog에는 에이전트가 검증된 정책 기반 런타임 환경 안에서 자체적으로 도구를 구축할 수 있는 방법이 필요했다. 그 런타임이 바로 Temper다.

Temper

에이전트는 어떤 팀이 수작업으로 검토할 수 있는 속도보다 빠르게 코드를 생성한다. 하지만 그만큼 실수도 생긴다.

Sesh에 따르면, 에이전트가 생성한 결과물과 검증을 통과하는 결과물 사이의 그 간극에 장애 유형들이 쌓인다. 그렇다고 에이전트를 기존 코드베이스에 단순히 씌우는 방식은 처리량 문제로만 접근할 뿐, 검증 간극 자체를 해소하지는 못한다.

Temper는 이 방정식을 뒤집는다. 에이전트가 애플리케이션 코드를 직접 생성하는 대신 명세를 작성하면, 결정론적 커널이 각 명세를 읽고 4단계 분석을 통해 검증한 뒤 해당 명세가 기술하는 실행 시스템을 배포한다. 명세가 증명되는 산출물인 동시에 실행되는 산출물이기 때문에, 검증된 것과 실제로 실행되는 것 사이에 괴리가 생기지 않는다.

"Temper는 시스템의 중심을 바꿉니다. 에이전트가 더 이상 필요할 때마다 제각각의 도구를 만들어낼 필요가 없습니다. 대신 의도와 문제 영역에 대한 정밀한 명세를 작성하면 됩니다. 지그나 CNC 머신처럼, 나사 나사선 규격을 명세로 입력하면 극도로 일관성 있게 결과를 생산하는 공작 기계와 같은 원리입니다. 그 반복성 덕분에 항공기나 그에 준하는 복잡한 것들도 만들어낼 수 있죠"라고 Sesh는 말한다.

즉, 에이전트가 매번 최종 메커니즘을 즉흥적으로 만들어내는 것이 아니다. 정밀한 명세를 작성하고 Temper(또는 Temper와 유사한 메커니즘)와 반복적으로 작업해 먼저 동작하게 만든 뒤, 이를 반복 가능하고 검증 가능하며 재사용 가능한 형태로 발전시킬 수 있다. 그렇게 되면 코드베이스를 중심으로 실질적인 소프트웨어 팩토리를 구축할 수 있다.

각 기능은 세 가지 컨트랙트(contract)로 정의된다.

• 동작(Behavior): 반드시 충족되어야 하는 상태, 전이(transition), 사전 조건, 안전 속성.
• 데이터 컨트랙트(Data contract): 엔티티 유형, 해당 속성, 각 유형이 지원하는 액션을 기계 파싱 가능한 형태로 게시하여 에이전트가 문서 없이도 전체 API를 파악할 수 있도록 한다.
• 인가(Authorization): 기본적으로 모든 접근을 거부(default-deny)하며, 범위 기반 승인 방식을 사용한다. 거부된 요청은 대기 중인 결정으로 기록되어 사람이 승인한 뒤 정책 엔진에 즉시 반영(hot-load)할 수 있다.

커널이 명세를 로드하려면 4개의 독립적인 계층을 모두 통과해야 한다. 심볼릭 추론(symbolic reasoning)은 각 가드(guard)가 충족 가능한지, 각 불변식(invariant)이 귀납적인지를 증명한다. 완전 상태 탐색(exhaustive state exploration)은 도달 가능한 모든 상태를 순회한다.

결정론적 시뮬레이션은 시드 값 기반의 장애 주입 — 패킷 손실, 지연, 순서 변경, 크래시 — 을 적용해 실제 프로덕션 코드 경로를 실행함으로써, 동일한 시드 값으로 장애를 정확히 재현할 수 있도록 한다.

무작위 속성 테스트는 약 1,000개의 유사 난수 액션 시퀀스를 실행하고, 위반이 발생하면 최소한의 반례로 축소한다. 작은 명세의 경우, 이 전체 연쇄 과정이 1초도 채 걸리지 않는다.

Helix를 위한 다크 팩토리

Simon Willison이 대중화한 '다크 팩토리(dark factory)'는 가상의 생산 현장에서 사람 없이 에이전트만이 계속 작업하는 소프트웨어 프로세스를 뜻한다. Helix 다크 팩토리에서 Temper는 세 가지 역할을 맡는다.

첫째, 관리형 에이전트를 위한 에이전트 컨트롤 플레인 — 세션, 역할, 작업 큐, 라이프사이클 관리. 둘째, SDLC 도구(Git, CI, 배포)를 소규모 Temper 앱으로 연결하는 도구 빌더 계층. 셋째, 워크로드를 실행하는 데이터 플레인 주변의 라이프사이클 인터페이스인 Helix 컨트롤 API.

"놀랍게도 이것이 에이전트 인프라보다 더 범용적인 무언가처럼 느껴지기 시작했습니다. 조금 추상적으로 보면 많은 소프트웨어가 결국 데이터베이스 API를 둘러싼 제어 로직, 즉 상태와 변경에 대한 정책, 라이프사이클 전이, 외부 시스템과의 연동 구조를 갖습니다. Temper는 이 구조를 가진 어떤 소프트웨어에도 적용될 수 있다는 점에서 범용적일 수 있습니다"라고 Sesh는 말한다.

그냥 CRUD 앱을 만들면 안 되나요?

"Claude Code는 TypeScript나 Python으로 CRUD 앱을 아주 잘 만듭니다. 하지만 일반적인 CRUD 앱에서는 제어 로직이 라우트, 데이터베이스 제약, 서비스 코드, 백그라운드 잡, 문서에 분산되어 있습니다. 테스트와 커버리지가 충실하더라도, 일반적으로 상태 머신(state machine) 형태로 존재하는 운영 모드는 코드베이스 안에 암묵적으로 숨어 있습니다"라고 Sesh는 설명한다.

"Temper는 그 상태 머신을 명시적으로 드러냅니다. 에이전트는 임의의 코드가 아닌 정밀한 명세를 작성하고, 컴파일 단계는 Rust 코드를 Rust 컴파일러에 넘기듯 LLM 바깥에서 이루어집니다. 전이 테이블(transition table)은 서비스 메서드에 뒤엉킨 제어 흐름이 아닌 데이터로 존재하기 때문에, 에이전트가 정책 안에서 동적으로 변경하고 CI를 거치지 않고도 즉시 반영(hot-reload)할 수 있습니다"라고 그는 설명한다.

앞으로의 방향

Temper의 핵심 아이디어는 각 산출물이 한 사람의 머릿속에 담길 만큼 작아야 한다는 것이다. 항공이나 금융 시스템처럼 높은 신뢰성이 요구되는 소프트웨어는 수십 년간 이런 방식으로 구축되어 왔지만, 사람의 힘으로 그 수준의 엄밀함을 달성하는 비용은 일반 소프트웨어에 적용하기엔 너무 높았다. 에이전트가 등장하기 전까지는.

산업혁명이 가능했던 것은 공작 기계가 부품을 조합 가능하고, 검사 가능하며, 교체 가능하게 만들었기 때문이다. 그 덕분에 점점 더 크고 복잡한 기계를 만들 수 있었다.

"에이전트가 이런 수준의 규율 아래 팩토리 안에서 자율적으로 소프트웨어를 구축할 수 있다면, 다크 팩토리에서 멈출 필요가 없을지도 모릅니다. 이런 방식으로 구축된 소프트웨어는 피드백과 선택, 적응을 통해 성장하고 배양하며 진화시킬 수 있는 유기체처럼 느껴지기 시작합니다"라고 Sesh는 말한다.

전체 세션 보기에서 Datadog가 Temper를 구축한 방법에 대한 라이브 데모와 심층 논의를 확인하세요. Temper는 일회성 에이전트 도구를 세션과 팀을 넘어 누적되는 안전하고 재사용 가능한 컴포넌트로 전환하는 제약 기반 프레임워크입니다.

‍