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

1주차에서 주제를 정하고 문제의 방향을 잡았다면, 2주차는 그 문제를 실제로 풀기 위해 “지금 내가 다루고 있는 로그와 환경 정보는 무엇이고, 이를 어떻게 관측 가능하게 만들 것인가”를 정리하는 단계였다.

클라이언트 로그가 어떤 방식으로 생성되고, 이를 어떤 흐름으로 추적·수집해 운영 단위의 액션까지 연결할지에 대한 설계를 정리하는 데 시간을 썼다.

클라이언트 애플리케이션 구조

현재 사용하는 클라이언트 애플리케이션은 Python 기반의 Mac / Windows / Linux 환경에서 동작하는 크로스 플랫폼 네이티브 데스크탑 앱이다.

이 앱은 단일 실행 파일이라기보다는, 각 DCC 툴을 실행시켜주는 런쳐 같은 역할을 하며(Maya, Photoshop 등) 부트스트랩시 PMS 클라이언트 앱이 플러그인 형태로 탑재되어 동작한다. DCC 툴 내부에는 Python 인터프리터가 포함되어 있고, PMS와의 상호작용도 이 Python 레이어를 통해 이루어진다.

이 구조 때문에 로그는 다음과 같은 특성을 가진다.

• 로그는 서버가 아니라 클라이언트 PC 로컬 디스크에 남는다
• OS마다 경로는 다르지만, 특정 로그 디렉토리에 모인다
• 로그는 엔진(engine) 단위로 생성된다

여기서 말하는 엔진은 하나의 실행 환경 혹은 실행 컨텍스트이다.

각 엔진은 독립적인 Python 실행 환경을 가지고 있고, 그 안에서 플러그인이 동작하며 로그를 남긴다. 그래서 로그 파일도 보통 tk-<engine>.log 형태로 생성된다.

결과적으로 하나의 클라이언트 PC 안에는 여러 엔진의 로그 파일이 동시에 존재한다.

로그가 관측되지 않는 지점

로그 자체는 항상 남고 있었다. 문제는 로그가 존재하지 않는 것이 아니라, 문제가 발생했을 때 이 로그와 클라이언트 실행 환경 정보를 중앙에서 바로 관측하고, 운영 단위의 액션으로 연결할 수 있는 구조가 아니라는 점이었다.

• 작업 중 오류가 발생하면 로그는 남는다
• 하지만 그 로그와 실행 환경 정보는 작업자 PC 안에만 머문다
• 중앙에서는 문제 발생 자체를 즉시 인지하기 어렵다

이 구조에서는 에러의 원인을 분석하기 이전에, “어디서, 어떤 환경에서, 어떤 문제가 발생했는지”를 파악하는 단계에서부터 지연이 발생한다.

그래서 이번 주에는 로그 수집을 단순한 데이터 모으기가 아니라, 운영 흐름의 시작점으로 보는 설계를 정리했다.

로그 수집 및 티켓 생성 설계

1안. 로그를 일정 기준으로 모아서 전달하는 방식

클라이언트에서 로그를 모아서 서버로 전달하는 방식이다.

구현은 단순하지만,

• 대부분의 로그는 정상 동작 로그고
• 실제 문제가 없는 로그까지 함께 수집된다
• PMS 서버 쪽 저장 용량과 운영 비용이 불필요하게 증가한다

운영 관점에서 모든 로그를 상시 수집하는 구조는 목적 대비 과하다고 판단했다.

2안. 에러 발생을 기준으로 로그 수집과 티켓 생성을 연결하는 방식

그래서 설계의 중심으로 잡은 방식은 에러 발생을 트리거로 로그 수집과 티켓 생성을 하나의 흐름으로 묶는 구조다.

이 설계에서는:

• 클라이언트에서 로그 파일을 상시 참조하고
• 에러 패턴이 감지되면
• 해당 로그 파일과 클라이언트 실행 환경 정보를 함께 서버로 전달한다
• 서버에서는 전달된 정보를 기준으로
  • 문제가 발생한 클라이언트를 식별하고
  • 내부 티켓을 자동으로 생성한다

이렇게 하면:

• 로그 수집 자체가 운영 이벤트가 되고
• 별도의 수동 보고 없이도
• 장애 인지부터 대응까지 하나의 흐름으로 이어진다

티켓은 단순한 알림이 아니라,
“이 클라이언트에서 이 시점에 이 문제가 발생했다”는
운영 단위의 명확한 상태 표현이 된다.

물론,

• 어떤 수준의 에러를 티켓 생성 기준으로 볼 것인지
• 로그를 어디까지 묶어서 전달할 것인지 같은 세부 정책은 이후 단계에서 더 정리해야 할 부분이다.

로그 데이터 흐름 정리

위 설계를 바탕으로, 로그 데이터가 이동하는 흐름을 하나의 다이어그램으로 정리했다.

• 로그는 클라이언트 환경에서 생성되고
• 로컬 로그 디렉토리에 쌓이며
• 클라이언트 수집기가 이를 읽어
• 에러 로그와 실행 환경 정보가 중앙 시스템으로 전달된다
• 전달된 데이터는 운영 티켓 생성의 입력으로 사용된다

2주차를 마치며

2주차에는 “로그를 어떻게 모을 것인가”보다 “로그와 실행 환경 정보를 어떻게 운영 가능한 신호로 만들 것인가”를 설계했다.

다음 주부터는 이 설계를 기준으로 클라이언트 수집기의 최소 기능을 구현하면서, 에러 감지부터 티켓 생성까지의 흐름을 실제로 연결해보려고 한다.