토스 러너스 하이 2기 1주차 회고

2 minute read

이번에 토스 러너스 하이 2기에 참여하게 되었다.

한 달 동안 내가 선택한 하나의 주제에 온전히 몰입할 수 있는 기회를 얻게 되었고, 그 순간 가장 먼저 떠올랐던 생각은 이거였다.

“그래서… 한 달 동안 뭘 해야 하지?”

한 달 동안 뭘 할 것인가에 대한 고민

러너스 하이는 과제를 던져주지 않는다. “이거 해보세요”라는 명확한 가이드도 없다. 가이드 세션에서 토스 서버 챕터를 맡고 계신 이항령님이 했던 말이 계속 기억에 남았다.

스스로 문제를 정의하고,
왜 이걸 하는지 설명할 수 있는 사람이
결국 계속 성장한다.

그래서 주제를 정할 때도 “기술적으로 멋있어 보이는 것”보다는 실제 비즈니스에서 반복적으로 겪었던 문제를 떠올려 보기로 했다.

많은 고민을 하지 않고도 한 가지 주제가 떠올랐다.

현재 재직 중인 회사에서는 PMS(Project Management System)를 기반으로 미디어 & 엔터테인먼트 제작 파이프라인을 구축하고 있다.

아래 그림은 제작 파이프라인 작업 공정을 최대한 단순화해서 도식화한 그림이다.

실제 작업은 아티스트의 로컬 PC에서 이루어진다. DCC(Digital Content Creation Tool) 툴을 통해 파일을 생성하고, 렌더링하고, 결과물을 만든다.

이렇게 생성된 작업 결과물은 클라우드로 직접 업로드되지 않고, 스튜디오 내부의 중앙 스토리지(NAS)에 저장된다. 각 작업자 PC는 운영체제가 다르더라도 사전에 약속된 마운트 포인트를 통해 동일한 파일 경로 구조를 공유한다.

PMS 서버로 전달되는 것은 파일 자체가 아니라, 어디에 어떤 결과물이 생성되었는지에 대한 메타데이터(경로, 상태 정보) 와 리뷰용 미디어파일 이다.

즉, 프로젝트의 상태와 흐름은 서버에서 관리되지만 실제 실행과 연산, 그리고 실패는 모두 클라이언트 PC에서 발생한다.

이 구조를 이해하고 나면, 로그가 왜 서버가 아니라 클라이언트 PC에 남을 수밖에 없는지도 자연스럽다.

작업의 주체가 클라이언트 PC이기 때문이다. 연산, 파일 I/O, DCC 툴 연동 모두 로컬 프로세스에서 수행된다. 따라서 에러와 예외, 실패에 대한 정보 역시 각 작업자 PC의 로그 파일로 남게 된다.

문제는 이 로그들이 각 OS, 각 PC에 흩어져 있다는 점이다.

작업이 정상적으로 진행될 때는 이 구조가 크게 문제로 드러나지 않는다. 문제는 장애가 발생했을 때다. 이 환경에서 장애는 대부분 클라이언트 PC에서 시작되지만, 그 사실을 시스템적으로 인지할 방법은 없다. 결국 문제는 사람을 통해 전달된다.

작업자는 오류가 발생했지만 원인을 알기 어렵고, 결국 구체적인 정보 없이 “툴이 안 된다”는 식으로 문제를 전달하게 된다.

관리자는 로그 수집을 요청하고 OS별 경로를 안내하며 전달을 기다린다. 문제 해결보다 로그 전달과 정리에 더 많은 시간이 소요된다.

개발자는 이렇게 전달된 로그를 기반으로 분석을 시작한다. 하지만 실행 환경을 직접 볼 수 없기 때문에 로그만으로 상황을 재구성해야 하고, 원인을 추측하며 접근하게 된다.

이 흐름에서 가장 큰 문제는 누군가의 실수나 개인의 역량이 아니라 구조 자체에 있다. 실행은 클라이언트에서 발생하지만, 관측은 시스템적으로 이루어지지 않고, 그 사이를 사람이 메우고 있다. 이 때문에 문제는 항상 늦게 발견되고, 같은 유형의 장애가 반복된다.

이 패턴은 올해 진행한 파이프라인 구축 사업의 PoC 단계에서도 이미 여러 번 반복되었고, 작업자 → 관리자 → 개발자로 이어지는 사람 중심의 커뮤니케이션 구조 자체가 문제 해결의 병목이 되고 있었다.

이쯤에서 자연스럽게 이런 질문이 들었다.

서버에서는 너무 당연한 Observability를
왜 클라이언트 쪽에는 거의 적용하지 못하고 있을까?

로그는 존재한다. 다만 관측 가능하지 않은 상태로 흩어져 있을 뿐이다.

그래서 이번 러너스 하이에서는 멀티 플랫폼 Client-side Observability 구축이라는 주제로 한 달 동안 몰입해보기로 했다.