작업 중단을 만드는 환경 문제를 확인하고 복구했습니다.
PROFESSIONAL EXPERIENCE · 2022.09 – 2026.03
Cocoavision · VFX Pipeline / Infrastructure
아티스트가 쓰는 DCC 환경과 Linux Render Farm을 운영하며, 반복되는 설치 · 설정 · 제출 작업을 자동화하고 제작이 멈추는 원인을 해결했습니다.
01
업무 개요
사용자 문의를 한 번 해결하는 데서 끝내지 않고, 같은 문제가 반복될 때는 Pipeline이나 Infrastructure 차원에서 줄이는 방식으로 접근했습니다.
Houdini, Nuke, Maya 등 제작 도구와 Linux 기반 Render Farm 사이에서 작업이 안정적으로 이어지도록 환경을 운영했습니다. Render 실패, 경로/마운트 문제, 플러그인/버전 차이 등 제작 중 발생하는 이슈를 분석했고, 반복되는 설치와 설정 업무는 PXE와 Ansible로 자동화했습니다. 외주사와의 작업에서는 파일, 환경, 전달 방식의 차이에서 발생하는 문제를 기술적으로 설명하고 대응했습니다.
반복 설치, 노드 설정, 제출 과정을 자동화 가능한 형태로 바꿨습니다.
로그와 실행 환경 차이를 기준으로 문제 범위를 좁혔습니다.
기술적 원인과 필요한 조치를 비개발 사용자도 이해할 수 있게 전달했습니다.
02
핵심 문제
수십 대 규모의 Render Node를 개별로 관리하면 동일 작업이 반복되고 설정 편차가 생깁니다.
USB 기반 설치는 장비가 늘어날수록 사람이 직접 해야 하는 단계가 증가합니다.
Render Farm 제출 과정이 수동 절차에 의존하면 누락과 설정 차이가 발생하기 쉽습니다.
03
Case 01 · Ansible
AS-IS
- Render Node마다 SSH 접속 후 설정
- 패키지/마운트/도구 배포 반복
- 노드별 설정 편차 가능
→
TO-BE
- Inventory로 대상 노드 그룹화
- Playbook으로 공통 작업 선언
- 동일한 설정을 여러 노드에 반복 적용
| 대상 | 수십 대 규모 Linux Render Farm |
|---|---|
| 자동화 | 패키지 설치 · Mount · 팀별 Tool 배포 등 반복 운영 작업을 Playbook 단위로 정리했습니다. |
| 결과 | 서버별 수동 작업을 재사용 가능한 운영 코드로 전환 동일 작업을 여러 노드에 일관되게 적용할 수 있게 했습니다. |
04
Case 02 · PXE
AS-IS
- USB로 장비별 OS 설치
- 작업자가 직접 초기 세팅 반복
- 설치 절차 차이 발생 가능
→
TO-BE
- Network Boot 기반 설치
- PXE + DHCP/HTTP + Kickstart
- 초기 설치 절차 표준화
| 담당 파트 | PXE 부팅과 자동 설치 환경 구성 네트워크 부팅부터 설치 파일 제공, Kickstart 기반 자동 설치까지 연결했습니다. |
|---|---|
| 판단 | 장비 수가 늘어날수록 반복 작업이 커지는 문제를 Infrastructure로 해결 개별 작업 속도를 높이는 대신 사람이 개입해야 하는 단계를 줄였습니다. |
| 결과 | USB 중심 설치 → 네트워크 기반 설치 PC 초기 세팅을 동일한 절차로 반복할 수 있는 기반을 만들었습니다. |
05
Case 03 · Tractor Submit
AS-IS
- 작업자가 제출 정보를 직접 구성
- DCC마다 제출 절차가 달라 실수 가능
- Job 규칙을 사용자에게 의존
→
TO-BE
- Houdini / Nuke 안에서 Submit
- 작업 정보를 Tractor Job 형식으로 변환
- 공통 제출 규칙을 Pipeline Tool에 반영
| 담당 파트 | Custom Render / Submit Node 구성 DCC에서 필요한 Job 정보를 수집하고 Render Farm으로 전달하는 흐름을 만들었습니다. |
|---|---|
| 판단 | 사용자 교육보다 도구에 규칙을 넣는 방식 작업자마다 절차를 기억하게 하기보다 제출 도구가 동일한 입력과 Job 형식을 만들도록 했습니다. |
| 결과 | Submission Workflow 표준화 수동 Job 생성 단계를 줄이고 DCC 안에서 일관된 제출 경로를 제공했습니다. |
06
장애 대응 사례
아티스트 작업이 로컬에서는 열리지만 Render Farm 제출 후 실패해 제작이 중단되는 상황이었습니다.
Tractor Log, DCC/Plugin 버전, 환경 변수, 파일 경로, Mount 상태를 순서대로 비교했습니다.
문제 설정을 수정한 뒤 같은 유형이 다른 노드에 반복되지 않도록 운영 절차와 자동화 대상을 보완했습니다.
장애 대응에서 가장 중요하게 본 것은 "어디에서만 실패하는가"였습니다. 로컬과 Farm의 차이를 비교해 원인을 좁히고, 해결 후에는 같은 문제를 운영 코드나 절차로 줄이는 방식으로 접근했습니다.
07
성과와 연결점
VFX에서 경험한 운영 문제를 DevOps에서 사용하는 방식과 자연스럽게 연결할 수 있었습니다.
Render Farm 운영은 다수 노드의 일관된 설정, 장애 로그 분석, 반복 작업 자동화, 사용자와의 협업이 필요한 환경이었습니다. 이 경험은 이후 Kubernetes, CI/CD, IaC를 학습할 때 단순 도구 사용보다 운영 문제를 어떤 구조로 줄일지 생각하는 기반이 됐습니다.
FARM수십 대 노드
Linux Render Node 운영
AUTOMATION3개 영역 자동화
Submit · Provisioning · Configuration
WORK STYLEFix → Standardize → Automate
반복 이슈를 구조로 줄임
Tech Stack: Linux · Houdini · Nuke · Maya · Tractor · Python · Ansible · PXE · Unreal Engine · Blender
08
Earlier · Real-time R&D
NewMedia R&D팀에서 Unreal Engine과 Blender를 활용해 실시간 콘텐츠 제작과 Previs Workflow를 검토하고 구성했습니다.
웹툰 제작과 렌더링 과정에서 실시간 엔진을 활용할 수 있는 제작 방식을 검토했습니다.
Motion Capture 데이터를 콘텐츠 제작 Workflow에 연결하는 기술을 테스트했습니다.
Unreal Engine Scene을 구성해 감독이 촬영 구도와 장면 구성을 사전에 확인할 수 있게 했습니다.
도구 하나보다 여러 제작 단계가 어떻게 연결되는지 이해하는 경험이 이후 Pipeline 업무로 이어졌습니다.
| 담당 파트 | Real-time Content R&D 및 Workflow 구성 실시간 엔진과 기존 제작 방식을 연결할 수 있는 기술적 가능성을 검토했습니다. |
|---|---|
| 산출물 | Previs Scene · 실시간 제작 Workflow 테스트 아이디어와 장면 구성을 촬영/제작 전에 빠르게 검토할 수 있는 환경을 구성했습니다. |
| 연결점 | R&D → Pipeline / Infrastructure 제작 툴 자체보다 작업 흐름과 환경을 개선하는 데 관심이 커지며 이후 Pipeline 업무로 역할을 확장했습니다. |