데이터독 AI 지원 마이그레이션, DB 비용 90% 절감
데이터독 AI 지원 마이그레이션은 회사의 메트릭 파이프라인을 라우팅하는 서비스 Stream Router를 실시간 트래픽 중단 없이 FoundationDB에서 PostgreSQL로 옮겼다고, 엔지니어 아널드 와킴이 쓴 글을 InfoQ가 2026년 7월 10일 다뤘어요. 엔지니어들은 실패하는 테스트를 기준으로 메서드마다 클로드와 커서를 썼어요. 회사는 가장 무거운 작업이 45분에서 약 1초로, 데이터베이스 비용은 90% 줄었다고 말해요. 이 결과는 모델만큼 테스트 스위트에 달려 있었어요.
Stream Router가 키-값 저장소를 넘어선 이유
데이터독의 문제는 병목이 된 라우팅 서비스였어요. Stream Router는 생산자에게 메트릭 데이터를 어디에 쓸지, 조회자에게 어디서 읽을지 알려 주는 내부 컨트롤 플레인으로, 하루 백조 건이 넘는 이벤트를 처리하는 플랫폼에서 데이터포인트마다 카프카 클러스터, 토픽, 파티션을 골라요.
이 서비스는 더 오래된 문제를 고치려고 시작됐어요. 2016년에는 라우팅을 3줄짜리 설정 파일로 관리했는데, 손으로 편집하는 수천 줄로 불어났어요. Stream Router는 이를 gRPC 서비스로 바꿨고, 쓰기 경로는 키-값 모델로 FoundationDB 위에서 돌았어요.
라우팅 테이블이 커지자 핵심 작업이 FoundationDB의 트랜잭션 크기 제한에 걸렸어요. 가장 무거운 작업은 수천 번의 순차 왕복 때문에 최대 45분이 걸렸어요. 라우트, 스트림, 샤딩 전략, 규칙은 본래 관계형인데, 코드는 수만 개 항목을 파드 프로세스로 끌어와 프로세스 안에서 관계형 데이터베이스 노릇을 했어요.
데이터독이 데이터 모델에서 바꾼 것
해법은 관계형 스키마였어요. 엔지니어들은 그 엔티티 사이의 관계를 중심으로 데이터 모델을 다시 설계해서, 애플리케이션 코드가 손으로 재구성하던 규칙을 PostgreSQL의 외래 키가 강제하게 했어요.
강한 모듈성이 전환을 가능하게 했어요. 새 Stream Router는 FoundationDB 대신 PostgreSQL 위에서 같은 API를 구현했고 다른 곳은 고칠 필요가 없었어요. 남은 일은 코드베이스 전체를 옛 모델에서 새 모델로 리팩터링하는 것이었고, 팀은 여기에 클로드와 커서를 투입했어요.
클로드와 커서는 메서드마다 어떻게 일했나
모델은 혼자가 아니라 촘촘한 루프 안에서 일했어요. 엔지니어 아널드 와킴은 이렇게 설명했어요.
"코드를 자율적으로 생성하게 하지 않았어요. 메서드마다 옛 구현, 새 스키마, 실패하는 테스트를 줬어요." 아널드 와킴, 데이터독 엔지니어
모델이 초안을 만들고 맞는지는 테스트가 판단했어요. 작업은 세 단계로 진행됐어요. 먼저 클로드가 핵심 함수마다 의도를 설명하고, 엔지니어들이 기대 동작과 첫 단계의 맥락을 담은 집중 프롬프트로 실패하는 테스트를 고치게 했어요. 마지막으로 새 서비스를 블루/그린 구성으로 운영에 올렸어요.
팀이 실시간 트래픽을 안전하게 지킨 방법
운영 안전은 두 시스템을 동시에 돌려서 얻었어요. PostgreSQL 기반과 FoundationDB 기반 Stream Router 인스턴스 두 개가 같은 요청을 처리했고, 기능 플래그로 클라이언트를 둘 사이에서 옮겼어요. 모든 클러스터의 검증 서비스가 라우팅 응답을 비교하고 어긋나면 팀에 즉시 알렸어요.
모델이 부족했던 곳
모델에는 분명한 한계가 있었고 와킴이 이를 열거해요. 상위 수준의 프롬프트는 잘 먹히지 않았어요. 클로드는 결과는 맞지만 필요 이상으로 왕복이 많은 쿼리를 썼고, 배치 처리, UNNEST, 공통 테이블 표현식 같은 최적화에는 사람의 입력이 필요했어요. 엔지니어가 최적화된 패턴을 한 번 써 주면 모델은 이후 메서드에서 반복했지만 스스로 찾아내지는 못했어요. 팀이 잘라낸 발췌가 아니라 전체 테스트 출력을 루프에 넣었기 때문에 토큰 사용량도 많았어요.
마이그레이션이 가져온 것
측정된 결과는 회사 자체 수치예요. 45분 걸리던 작업이 약 1초로 줄었고 지연은 수백 밀리초에서 몇 밀리초로 떨어졌어요. 데이터 저장 용량은 최대 40배 줄었고 CPU와 메모리 사용이 감소했으며 데이터베이스 비용은 90% 떨어졌어요. 데이터독은 AI 도구 없이는 주어진 시간 안에 구현을 마치지 못했을 것이라고 말해요.
AI로 리팩터링을 계획하는 팀에 주는 시사점
엔지니어링 조직의 과제는 마감 아래에서 운영 코드를 크고 반복적으로 리팩터링하는 일이에요. 데이터독 AI 지원 마이그레이션은 가치가 어디에 있는지 보여 줘요. 모델은 타이핑을 빠르게 했고, 그 속도를 안전하게 만든 건 테스트 스위트, 모듈식 설계, 나란히 돌린 검증기였어요. 와킴은 테스트 스위트의 강도가 팀이 AI 생성 코드를 얼마나 믿을 수 있는지 결정했다고 결론지어요. 그런 스위트가 없는 팀은 같은 코드를 더 빨리 얻지만 그것이 맞는지 알 방법이 없어요.
자주 묻는 질문
데이터독은 마이그레이션에서 클로드와 커서를 어떻게 썼나요?
엔지니어들은 메서드마다 모델에 옛 구현, 새 스키마, 실패하는 테스트를 줬어요. 모델이 초안을 쓰면 테스트가 맞는지 보여 줬어요.
PostgreSQL 마이그레이션은 어떤 결과를 냈나요?
데이터독에 따르면 작업이 45분에서 약 1초로 줄었고, 지연은 수백 밀리초에서 몇 밀리초로 떨어졌고, 저장 용량은 최대 40배 줄었고, 데이터베이스 비용은 90% 줄었어요.
AI 모델이 하지 못한 일은 무엇인가요?
맞지만 느린 쿼리를 썼어요. 배치 처리, UNNEST, 공통 테이블 표현식은 엔지니어의 손이 필요했고, 모델은 그런 패턴을 본 뒤에야 재사용했어요.
MOZGII의 시각
우리라면 이렇게 만듭니다
이 사례의 교훈은 모델이 가장 특별하지 않은 부분이었다는 거예요. 데이터독이 기계가 쓴 코드를 믿을 수 있었던 건 메서드마다 있는 테스트, 바뀌지 않는 인터페이스, 같은 요청에 나란히 답하는 살아 있는 두 시스템 덕분이었어요. 큰 리팩터링은 모델을 고르기 전에 이 세 가지를 중심으로 짜겠어요.
실제로는 메서드마다 실패하는 테스트를 먼저 쓰고 그것을 명세로 다룰 거예요. 모델에는 작업마다 작고 고정된 묶음을 줘요. 옛 코드, 새 스키마, 테스트예요. 엔지니어는 통과한 변경을 모두 검토하고, 데이터베이스 쿼리처럼 정답이어도 왕복이 많이 늘 수 있는 느린 경로는 직접 맡아요. 전체 로그가 토큰 사용량을 키웠으니 테스트 출력은 모델에 넣기 전에 줄일 거예요.
테스트가 얇은 곳에서 무너질 거예요. 커버리지가 약한 메서드는 틀린 코드를 끝난 것처럼 통과시키고, 나란히 돌리는 검증기는 실제 트래픽이 건드린 것만 잡아요. 지켜볼 지표는 하나예요. 옛 시스템과 새 시스템의 차이를 검증기가 찾아내는 빈도를 라우트 유형별로 보고, 옛 시스템을 끌 만큼 충분히 오래 차이가 없어질 때까지 지켜봐요.
다음으로는 손으로 쓴 쿼리 패턴을 모델이 먼저 읽는 공용 라이브러리에 모아, 다음 마이그레이션이 이번이 끝난 곳에서 시작하게 할 거예요.
출처
이 기사의 사실은 다음 출처에서 가져왔습니다.
- 01How Datadog Used Claude and Cursor for Test-Driven Production Migration - InfoQinfoq.com
- 02How we migrated a live routing system using AI-assisted refactoring | Datadogsecurity-platformrumcidashboardhost-mapapmsecurity-platformrumcidashboardhost-mapapmsecurity-platformrumcidashboardsecuritydatadoghq.com