AI 에이전트 학습 데이터의 빈틈: 코드베이스를 넘어 인프라 운영까지 담는 샌드박스 실험

핵심 메시지

• AI 에이전트는 애플리케이션 계층 작업에는 능숙하지만 인프라 복잡성을 추론하는 데는 여전히 약하다. 발표자들은 이 능력 격차가 결국 데이터 격차라고 본다.
• 현재의 대표적 코딩 벤치마크는 과제가 코드베이스 안에서만 이루어진다. 50~100턴에 걸쳐 수천 줄짜리 PR을 만들어 내지만, 사람이 하는 일의 상당 부분은 빠져 있다.
• 이들은 소프트웨어 기업을 통째로 컨테이너 환경에 넣어, 프로젝트·인시던트·고객 대화 같은 조직 맥락과 노드 장애·데이터 손상·클럭 스큐처럼 규모에서만 드러나는 문제를 함께 담는다.
• 단일 노드 샌드박스로도 분산 클러스터를 흉내 낼 수 있지만, 리소스 프로비저닝부터 시작되는 실제 클라우드 서비스 구축 과정을 담기에는 한계가 분명하다.
• 그래서 이들이 향하는 방향은 실제 클라우드 자원을 프로비저닝하는 멀티 노드 샌드박스, 즉 '상자 안에 담은 클라우드'다.

쉽게 이해하기

AI 엔지니어 콘퍼런스에서 데이터 랩 이뮬레이티드의 조셉과 공동창업자 시드가 에이전트 학습 데이터의 빈틈을 주제로 발표했다. 이들의 출발점은 콘퍼런스의 모든 발표가 공유하는 전망, 즉 에이전트가 점점 더 긴 시간 동안 사람의 개입 없이 유용한 일을 하게 되리라는 것이다. 그렇다면 그 미래를 위해 데이터와 모델 계층은 무엇을 준비해야 하는가가 이들이 던진 질문이다.

두 사람의 배경은 네트워크 인프라, 분산 데이터베이스, 샌드박스 인프라처럼 장애가 치명적인 영역이다. 몇 달 전 대형 클라우드 데이터베이스 서비스가 멈추자 특정 리전과 인터넷의 상당 부분이 함께 멈춘 일을 예로 들며, 모델은 애플리케이션 계층은 능숙하게 다루면서 데이터베이스 엔진의 동시성 제어처럼 데이터 손상으로 이어질 수 있는 인프라 문제를 추론하는 데는 어려움을 겪는다고 지적했다. 그리고 머신러닝에서 대개 그렇듯, 모델의 격차는 곧 데이터의 격차라고 이들은 정리한다. 구체적으로 무엇이 비어 있는가. 최근의 주요 코딩 벤치마크들은 과제가 코드베이스 안에서만 일어난다. 에이전트는 큰 과제를 받아 50~100턴에 걸쳐 수천 줄짜리 PR을 만들어 내지만, 여기에는 PM이 고객과 대화하며 문제를 파악하는 일, 엔지니어가 여러 접근을 시도하고 성능을 테스트하는 일, 그리고 몇 달이 아니라 몇 년에 걸쳐 코드베이스 밑의 인프라를 책임지는 일이 빠져 있다.

이뮬레이티드가 메우려는 것이 바로 이 부분이다. 이들은 소프트웨어 기업을 컨테이너 환경에 통째로 집어넣는다. 여기에는 프로젝트와 인시던트, 고객과의 대화 같은 조직적 맥락이 포함되고, 분산 노드 사이의 네트워크 장애나 데이터 손상, 클럭 스큐처럼 규모가 커져야만 나타나는 문제도 들어간다. 발표에서 예로 든 것은 실제 서비스가 의존할 법한 합의 클러스터 환경이다. 기존 환경이 주로 소스 코드 영역만 다뤘다면, 이 환경에서는 티켓과 프로젝트, 포스트모템에서 시작해 변경을 만들고, 롤링 배포를 시작하고, 낡은 하드웨어에서 새 하드웨어로 옮기는 도중 실패하는 노드 같은 예기치 못한 문제를 실시간으로 헤쳐 나가야 한다. 그러는 동안에도 라이브 트래픽을 받는 서비스는 멈출 수 없으므로 영향 범위를 계속 의식해야 한다.

단일 노드 샌드박스 안에서 여러 노드가 흔들리고 지연되는 분산 클러스터를 흉내 내는 것도 꽤 멀리까지 갈 수 있지만, 이들이 보기에 그것으로는 부족하다. 클라우드 서비스를 만든다고 상상해 보면 이유가 분명해진다. 소프트웨어가 어딘가에서 실제로 돌아야 하니 호스트와 VPC, 서브넷, 보안 그룹 같은 자원을 프로비저닝해야 하고, 고객이 쓸 API와 인증·인가, 배포와 롤백, 헬스 모니터링, DNS와 인증서 관리, 나아가 관리 콘솔과 과금까지 이어진다. 어느 임계점을 넘으면 단일 노드 샌드박스로는 감당이 되지 않는다는 것이다.

그래서 이들이 제시하는 방향은 실제 클라우드 자원에 접근하는 멀티 노드 샌드박스, 이른바 '상자 안에 담은 클라우드'다. 남은 과제도 솔직하게 공개했는데, 서버리스 런타임 같은 스택 전체를 띄우는 데 몇 시간이 걸리는 문제를 학습 롤아웃에 어떻게 넣을지, 비용은 어떻게 감당할지, 실제 자원을 쓰더라도 남는 시뮬레이션과 현실의 간극은 어떻게 다룰지가 그것이다. 인프라부터 시작한 이유로는 자신들의 배경과 가장 맞닿아 있어 데이터 품질을 높일 수 있다는 점, 그리고 회사 전체를 시뮬레이션할 때 인프라는 사용자가 원하는 바가 비교적 분명해 문제 정의가 쉽다는 점을 들었다.

주요 인사이트

• 벤치마크가 측정하는 범위가 곧 모델이 잘하게 되는 범위다. 과제를 코드베이스 안으로 한정하면 에이전트도 딱 그만큼만 유능해진다.
• 에이전트의 자율성을 늘리는 병목이 모델 구조가 아니라 학습 환경의 충실도에 있다는 관점은, 데이터 확보 경쟁이 텍스트에서 '환경'으로 옮겨 가고 있음을 보여 준다.
• 규모에서만 나타나는 문제, 즉 노드 간 네트워크 장애와 데이터 손상, 클럭 스큐 같은 것들은 작은 예제에서는 재현되지 않는다. 이런 문제를 겪어 본 적 없는 모델이 운영을 맡기 어려운 이유다.
• 발표자들이 이 접근을 공개하는 이유로 든 것은 함께 풀 사람을 찾기 위해서였다. 스택 기동 시간, 비용, 시뮬레이션과 현실의 간극이 아직 열려 있는 문제라는 점을 스스로 밝혔다.
• 특정 도메인을 수직으로 깊게 파는 방식이 다른 수평 도메인으로도 전이된다는 것이 이들의 판단이며, 그래서 인프라를 첫 출발점으로 삼았다.

자주 묻는 질문

관련 AI 소식