LLM 옵저버빌리티: Datadog CTO에게 배우는 6가지 교훈

교훈 1: AI가 기존 코드 리뷰 방식을 무너뜨렸다

모든 것을 촉발하는 압박부터 시작해 봅시다. 읽을 수 있는 것보다 코드가 더 많습니다.

레콕은 과거의 모델, 즉 사람이 PR을 줄 단위로 읽는 방식이 AI 보조 개발과는 양립하기 어렵다고 단언합니다. 업계 전반에서 듣는 불안은 리뷰가 불가능해지고 있다는 점입니다. PR을 읽어 따라가기에는 일이 너무 많기 때문입니다.

그의 대응은 더 빨리 읽으라고 요구하는 것이 아니라, 리뷰의 무대를 다른 곳으로 옮기는 것입니다.

마지막 문구는 놓치기 쉽습니다. 한 에이전트가 계획하고, 다른 에이전트가 작성하고, 또 다른 에이전트가 테스트하도록 오케스트레이션하면, 문제 해결 대신 자동화 테스트를 요리조리 피해 가는 행위를 막아야 합니다.

그는 테스트를 넘어섭니다. Datadog은 이제 스펙이 의도대로 작동함을 보이는 반정형·정형 증명을 추가합니다. 예전에는 너무 힘들어 널리 시도하기 어려웠지만, 이제 에이전트가 무거운 작업을 맡으면서 가능해졌습니다. 이는 수학적으로 정밀 추론이 가능한 백엔드와 조정 시스템에서 특히 효과적입니다.

교훈 2: 프로덕션만이 유일하게 의미 있는 테스트

CI에서 모든 테스트를 통과하는 것은 필요조건일 뿐 충분조건과는 거리가 멉니다. 중요한 실패는 그 이후에 발생합니다.

모든 릴리스는 사전에 완전히 검증할 수 없는 가정 위에 서 있습니다. 데이터의 형태와 사용자 행동에 관한 가정 말입니다. 충분한 실제 트래픽을 받으면, 드문 케이스는 더 이상 드물지 않습니다. 그것이 바로 데이터 및 모델 드리프트가 일으키는 일상적인 지연과 오류입니다.

LLM은 이를 더 어렵게 만듭니다. 일반적인 코드의 경우 최소한 모든 분기를 추론할 수 있지만, 모델이 어떤 출력을 내는지 기계적으로 설명할 수 있는 사람은 없습니다. 같은 입력이 항상 같은 출력을 보장하지 않습니다. 가끔 나타나는 이상한 결과를 공학적으로 완전히 제거할 수는 없습니다.

따라서 출하 전에 시스템의 정당성을 입증하려는 시도를 멈춥니다. 대신 다음을 수행합니다.

• 원하는 동작을 위한 평가 기준을 작성합니다.
• 프로덕션에서 모니터링합니다.
• 문제가 생기면 롤아웃을 중지할 수 있는 제어 장치를 유지합니다.

이제 질문은 통과 여부가 아니라, 문제가 일회성인지 추세의 시작인지입니다.

라이브 시그널은 사람을 위한 대시보드에 그치지 않습니다. 배포 시스템에 연결되면, 신중한 엔지니어처럼 에이전트가 실제 데이터를 근거로 변경 사항을 사용자 1%에, 이어 5%에 점차 롤아웃하며 의도한 효과를 내는지 판단할 수 있습니다.

교훈 3: 반복 업무는 에이전트에게

레콕이 에이전트를 옹호하는 이유는 엔지니어를 대체하기 위해서가 아니라, 사람을 지치게 하는 업무를 대신 맡기기 위해서입니다.

인시던트 트러블슈팅은 증상에 온갖 가설을 던지는 일입니다. 긴 인시던트에서는 엉뚱해 보이는 가설이 맞는 경우도 잦습니다. Datadog의 Bits AI 에이전트는 엔지니어보다 앞서 이러한 가설을 병렬로 모두 점검하고, 사람은 대시보드에 나타나지 않을 직감을 따라 방향을 잡아줍니다.

핵심은 피로입니다. 온콜 롤아웃은 갑작스러운 경계심과 몇 시간의 무작업이 반복되며, 결국 판단력이 흐려집니다.

에이전트는 개의치 않으며, 네 시간 동안 숫자를 응시했다고 성능이 떨어지지도 않습니다. 스트레스와 피로는 인간의 성과를 떨어뜨리기에, 팀이 온콜을 순환하는 이유이기도 합니다.

지치지 않는 관찰을 기계에 맡기면, 사람은 정말 필요한 판단에 더 나은 컨디션으로 복귀합니다. 보안 트리아지에도 같은 논리가 적용됩니다. 분석가가 오탐과 실제 위협을 가르느라 소진되곤 합니다.

교훈 4: 일을 두 개의 루프로 나누라

레콕은 Datadog의 에이전트 작업을 두 개의 루프로 조직합니다.

개발 루프

대부분의 엔지니어에게 익숙한 첫 번째 루프입니다.

1. 코드 작성
2. 배포
3. 동작 확인
4. 수정
5. 반복

Datadog의 관점은, 코드에서 비롯된 문제는 대개 코드에서 해결책을 찾을 수 있다는 것입니다. 따라서 플랫폼은 애플리케이션 소유, 최근 변경, 발생 오류 등 알고 있는 정보를 바탕으로 그 해결책을 제시하려 합니다.

예로 데이터베이스 쿼리 최적화를 들 수 있습니다. 어떤 모델이든 느린 쿼리를 다시 쓸 수는 있습니다. 더 어려운 부분은 그 재작성본이 프로덕션에 가기 전에 실제로 더 빠르고 안전함을 증명하는 것입니다. 그래서 Datadog은 프로덕션 데이터의 현실적인 사본으로 먼저 테스트하고, 증거를 첨부한 PR을 전달합니다.

운영 및 보안 루프

다른 루프는 동일 인력 또는 별도 팀이 병행하여 수행합니다.

1. 탐지
2. 조사
3. 수정
4. 반복

이 영역에서는 Datadog의 AI Guard가 보안 이벤트를 분류하고, 분석가가 수작업으로 처리하는 것보다 빠르게 공격을 차단합니다. 또한 엔지니어가 매일 큰 의욕 없이 수행하는 운영성 잡무, 예컨대 특정 Kubernetes 파드 리사이징 같은 작업도 에이전트가 처리할 수 있습니다.

두 루프 전반에서 레콕은 작업 순서를 분명히 합니다. Datadog은 "여기 AI가 있다, 어떤 문제를 풀 수 있을까?"에서 출발하지 않습니다. 고객이 이미 불평하는 문제, 대개 "이 반복 작업을 하고 싶지 않다"는 요구에서 출발해, 에이전트에게 맡겨도 될지를 거꾸로 검토합니다.

교훈 5: AI 비용을 관리하라

비용은 안전과 나란히 놓인 제약입니다. 대형 언어 모델의 운영화 비용을 통제하는 일은 그 자체로 하나의 분야가 되고 있습니다. 레콕이 DASH에서 제시하는 해법은 Datadog의 Agent Console입니다.

개발자에게 어떤 모델이 필요한지 물으면, 종종 가장 강력하고(그리고 비싼) 모델을 고릅니다. 그게 맞을 때도 있지만, 많은 작업은 보일러플레이트로 더 저렴하고 빠른 모델도 충분히 잘 처리합니다. 둘을 가르려면 조직의 에이전트 트래젝토리, 호출하는 도구, 성공 빈도를 읽어 패턴을 찾아야 합니다.

그 패턴은 규칙이 아니라 휴리스틱이 됩니다. 최신 Claude Opus나 GPT 같은 프론티어 모델은 기획에, Claude Haiku처럼 저렴한 모델은 테스트 생성에 쓰는 식입니다.

그 밑바탕 원칙은 의사결정의 소유입니다. 비용을 하나의 숫자로만 올리면, 레콕이 말하는 "매우 낮은 실천 가능성"만 남습니다. 모두 지출을 멈춰 유용한 작업이 죽거나, 모두 계속 써서 비즈니스가 감당하지 못하게 됩니다. 그는 데이터를 모델을 선택하는 개발자와 SRE에게 직접 보여주길 원합니다.

교훈 6: 학습하는 법을 배우라

신입 엔지니어가 무엇을 공부해야 하느냐는 질문에, 레콕은 오래된 듯하지만 결코 낡지 않은 답을 내놨습니다.

모델은 그 어떤 것보다 인내심 강한 튜터입니다. 무엇이든, 어떤 속도로든 설명해 줍니다. 과거에는 개인 교사가 있는 왕족만 누리던 접근성이었습니다. 하지만 튜터는 캐묻지 않으면 무용지물입니다. 핵심 역량은 무엇을 물을지, 답을 어떻게 검증할지 아는 것입니다.

그는 컴퓨터를 마법처럼 대하지 말고 층층이 이해하라고 권합니다. 스케줄러, 로드밸런서, 샌드박스를 예로 들어 모델에게 동작 원리를 설명하게 하고, 계속 파고드세요.

• 이 용어의 의미는 무엇인가?
• 어떻게 측정하는가?
• 그 배경의 수학은 무엇인가?
• 잘 작동하는지 어떻게 아는가?

고전을 이런 방식으로 공부하는 것은 의도적으로 느립니다. 그는 악기를 배우는 것에 비유합니다. 음악을 하루 종일 들을 수는 있지만, 피아노를 연주하려면 결국 손을 건반 위에 올려야 합니다.

AI가 작성한 코드도 마찬가지입니다. 바이브 코딩 은 괜찮다고 그는 말합니다. 다만 왜 작동했는지, 왜 이렇게 구성되었는지, 더 나은 접근이 있는지, 무엇을 본떠 만들었는지 반드시 되돌아보아야 합니다. 목표는 AI로 코드를 덜 쓰는 것이 아닙니다. 이제 훨씬 더 많이 생산하게 된 코드를 제대로 이해하는 것입니다.

마무리 생각

레콕의 핵심 메시지는 루프 자체는 변하지 않았지만, 속도는 변했다는 것입니다. 달라진 점은 AI의 속도를 사람이 충분히 면밀히 따라볼 수 없다는 사실입니다. 그래서 관찰과 점점 더 많은 빌드 작업이 피로와 당황을 모르는 에이전트로 이동합니다.

그는 옵저버빌리티를 차트 모음이 아닌 제어 플레인으로 다루자고 주장합니다. 에이전트가 소프트웨어를 작성·테스트·배포·운영하려면, 뛰어난 엔지니어가 의존하는 실제 프로덕션 데이터와 같은 기반이 필요하며, 여기에 판단과 중지 버튼을 쥔 사람이 더해져야 합니다. Datadog은 옵저버빌리티를 이러한 균형을 안전하게 하는 계층으로 포지셔닝하고 있습니다.

이 관점이 엔지니어에게 요구하는 역량은 분명합니다. 소스를 넘어, 프로덕션에서의 동작을 통해 시스템을 읽는 습관입니다. 그 습관을 기르고 싶다면, 우리의 Machine Learning in Production 스킬 트랙이 좋은 출발점입니다.