Vercel Daemons, 트레이스를 Vercel Tracing으로 직접 전송

발표 내용

2026년 11월 13일, Vercel은 변경 로그에서 Vercel Daemons가 이제 OpenTelemetry 트레이스를 Vercel Tracing으로 직접 보낼 수 있다고 발표했습니다. Vercel의 설명에 따르면 이를 통해 개발자와 에이전트가 백그라운드 워커의 동작을 프로젝트의 다른 트레이스와 나란히 살펴볼 수 있습니다. 글쓴이는 Vercel 인프라 팀의 소프트웨어 엔지니어 Gal Schlezinger이며, 읽는 시간은 1분으로 표시되어 있습니다. 짧은 글이지만 내용은 구체적입니다.

구체적인 방법

발표가 설명하는 방식은 세 단계입니다. 첫째, Vercel은 각 daemon에 OTLP/HTTP 트레이스를 받는 유닉스 소켓을 제공하고, 이 소켓의 경로를 환경 변수 VERCEL_OTEL_SOCKET_PATH에 설정합니다. 둘째, @vercel/otel을 2.3.0 이상으로 올립니다. 이 버전에서는 기본 설정을 쓰는 Node.js daemon이 트레이스를 자동으로 내보냅니다. SDK가 소켓을 감지해 워커가 기록한 span을 Vercel로 보냅니다. 셋째, 워커가 시작되기 전에 OpenTelemetry를 초기화합니다. 공식 예제는 worker.ts의 두 줄입니다. registerOTel을 가져와서 serviceName을 'my-daemon'으로 호출합니다. 서비스 이름은 직접 정합니다.

데이터를 보는 방법

이 span들은 Vercel CLI로 가져올 수 있습니다. 발표에 나온 명령은 vercel traces search이며, --project로 프로젝트를, --service로 서비스를 지정하고 --json으로 JSON 출력을 받습니다. Vercel은 프로젝트 안에서 서비스 이름으로 검색하고 에이전트가 쓸 JSON을 돌려받을 수 있다고 설명합니다. 예제의 설명 문구는 최근 한 시간의 daemon span을 검색한다고 되어 있습니다. 글 끝에는 daemon 트레이싱 문서로 가는 링크가 있으며, 이 이상의 세부 사항은 문서가 기준입니다.

왜 눈여겨볼 만한가

이 부분은 발표 원문이 아니라 우리의 해석입니다. 백그라운드 워커에는 페이지 요청 같은 뚜렷한 진입점이 없습니다. 문제가 생기면 개발자가 읽을 수 있는 것이 로그뿐인 경우가 많습니다. 트레이스는 하나의 작업을 시간이 붙은 span으로 나누기 때문에 어느 단계에서 시간이 쓰였는지 보입니다. 이번 변경의 실용적 가치는 daemon의 span이 프로젝트의 다른 트레이스와 같은 자리에 나타난다는 점입니다. 별도의 수집 경로를 만들 필요가 없고 데이터를 어디로 보낼지 정할 필요도 없습니다. 경로는 플랫폼이 환경 변수로 주고 SDK가 알아서 찾기 때문입니다. 유닉스 소켓으로 받는다는 것은 데이터가 머신 안에서 오간다는 뜻이기도 해서, daemon을 위해 외부 수집기 주소를 따로 설정할 필요가 없습니다. 이 점은 발표에서 다루지 않았으므로 일반적인 보충 설명으로만 적습니다.

또 하나는 에이전트와의 궁합입니다. 발표는 CLI가 에이전트용 JSON을 돌려줄 수 있다고 밝혔습니다. 코딩 에이전트나 운영 에이전트에게 최근 한 시간의 daemon span을 조회하게 하는 것은 Vercel이 직접 염두에 둔 사용 방식입니다. 플랫폼이 관측 데이터를 자동화 도구에 여는 최근 흐름과도 맞닿아 있습니다.

유의할 범위

발표가 분명히 말하는 것은 기본 설정의 Node.js daemon이 트레이스를 자동으로 내보낸다는 것과 @vercel/otel이 2.3.0 이상이어야 한다는 것뿐입니다. 다른 런타임, 사용자 지정 설정, 샘플링, 보관 기간, 요금에 대해서는 언급이 없으며 추측하지 않겠습니다. 필요하면 문서를 확인하세요. 모든 요금제에서 쓸 수 있는지, daemon 자체에 버전 요건이 있는지도 적혀 있지 않으므로 사용 전에 확인해야 합니다. 예제는 워커가 시작되기 전에 OpenTelemetry를 초기화해야 한다고 강조합니다. 그보다 앞선 작업은 기록되지 않을 수 있다는 것은 순서에서 나오는 일반적인 추론이며, 발표가 결과까지 적은 것은 아닙니다.

팀별 의미

OpenTelemetry를 연동할 때는 @vercel/otel 2.3.0 이상 버전을 사용하고 워커 프로세스 초기화 전에 registerOTel을 호출해야 합니다. 공식 예제는 모듈을 가져와 서비스 이름을 등록하는 기본 경로를 보여 줍니다. SDK는 워커가 기록한 span을 내보내며, 특정 업무 단계를 남기려면 필요에 따라 직접 span을 생성할 수 있습니다. 서비스 이름은 나중에 조회할 때 그대로 쓰이므로 분명하게 짓는 편이 좋고, 한 프로젝트에 daemon이 여러 개라면 서로 다른 이름으로 구분해야 결과가 깔끔합니다. 이는 명령 인자에서 이끌어 낸 우리의 사용 제안이며 발표가 따로 적은 내용은 아닙니다.

적용 전 점검

실제로 의존하기 전에 네 가지를 권합니다. 첫째, @vercel/otel이 2.3.0 이상인지 확인합니다. 둘째, 초기화 코드가 워커 시작 전에 실행되는지 확인합니다. 셋째, 배포한 뒤 vercel traces search로 서비스 이름을 조회해 span이 실제로 돌아오는지 봅니다. 넷째, daemon 트레이싱 문서를 읽고 요금제, 런타임, 보관 기간처럼 발표가 다루지 않은 조건을 확인합니다. 모두 어렵지 않지만 하나라도 빠지면 트레이싱이 연결된 줄 알았는데 실제로는 아무것도 조회되지 않는 일이 생길 수 있습니다.

정리

작지만 실용적인 업데이트입니다. 기본 설정에 플랫폼이 Unix 소켓을 제공하는 Node.js daemon에서 @vercel/otel을 2.3.0 이상으로 올리고 워커가 시작되기 전에 registerOTel을 호출하면 daemon의 span이 Vercel Tracing에 나타나고, vercel traces search로 JSON 형태로 가져올 수 있습니다. 이미 Vercel Daemons로 백그라운드 작업을 돌리는 팀이라면 변경 비용이 낮아 시험해 볼 만합니다.