경험 편찬 1차 정리
사실과 맥락
•
팀의 기존 모델 평가 플랫폼은 하나의 리더보드가 개발 중인 모델의 지표를 기록하는 Experiment Management와 최종 모델 파일·벤치마크를 관리하는 Model Registry 역할을 함께 맡고 있었음.
•
평가 결과 하나를 남기기 위해서도 평가 로직 추가, model_zoo 규약 준수, 특정 실행 환경 준비가 필요해 사용자가 감당해야 할 연동 비용이 컸음.
•
팀원 인터뷰에서 시스템을 한 번도 사용하지 않았거나 앞으로 사용할지 모르겠다는 반응이 확인됨.
•
부적절 이미지 필터링 모델은 레거시 Xeye2·Xeye3 학습 경로를 새로운 구조에서 재현하고 여러 모델 변경안을 빠르게 비교할 필요가 있었음.
판단과 행동
•
동료 개발자 인터뷰로 사용 장벽을 확인하고, 개발 중인 모델의 지표 기록과 검증된 모델의 중앙 관리를 서로 다른 책임으로 다시 정의함.
•
개발 중인 모델의 지표는 모델 파일 없이 API로 기록하고, 중앙 리더보드는 검증된 모델 파일과 최종 벤치마크를 관리하는 Model Registry 역할에 집중하도록 재설계함.
•
지표 등록 API와 클라이언트를 분리하고, Nubes에서 등록 결과를 주기적으로 가져와 리더보드에 반영하는 처리 과정과 EvaluableMetricHelper, 사용 가이드를 구현해 팀에 배포함.
•
레거시 학습 코드를 PyTorch Lightning 기반의 데이터·모델·트레이너 구조로 옮기고, 재설계한 지표 기록 경로를 직접 사용해 재현과 모델 변경안 비교를 수행함.
기술 선택과 시행착오
•
모델 평가는 장시간 실행되는 GPU 작업이었고, latency 측정은 다른 평가 작업의 간섭 없이 독점적으로 실행돼야 했음. 실행 상태·로그·소요 시간 관측, 작업 취소, 자원별 동시성 제어가 가능한 워크플로 오케스트레이터가 필요했음.
•
Argo Workflow는 Kubernetes 자체가 필요했고, Airflow는 안정적이지만 정적인 DAG와 데이터 파이프라인 중심이며 상대적으로 무거웠고, Dagster는 데이터 중심 추상화였음. Python 함수에 가까운 동적·작업 중심 플로우를 정의할 수 있고 Kubernetes 없이 로컬·Docker 환경에서 시작할 수 있으며 필요한 관측·동시성 기능을 갖춘 Prefect를 선택함. 대신 버그와 낮은 성숙도를 감수해야 하는 선택임을 인지했음.
•
처음에는 gRPC 서버 안에서 Prefect flow를 호출했으나 비동기 실행 과정이 블랙박스가 되고 예상하지 못한 동작이 발생함. 불필요한 gRPC 의존성을 제거하고 request 서버가 Prefect 클라이언트 역할을 맡도록 구조를 단순화함.
•
Prefect의 local subprocess work pool과 Docker worker를 검토했으나 전자는 알려진 동작 오류가 있었고 후자는 GPU 런타임 설정에 제약이 있었음. 상시 Docker Compose 방식과 요청마다 컨테이너를 프로비저닝하는 방식을 모두 문서화하고, 더 많은 검증을 거친 상시 컨테이너 방식을 기본 운영 시나리오로 제시함.
•
원격 flow의 반환값이 ~/.prefect/storage에 저장되는 특성 때문에 컨테이너 간 공유 마운트를 구성함. SQLite 사용 시 DB lock으로 추정되는 Web UI 장애가 반복돼 Prefect backend를 PostgreSQL로 운영함.
•
모델·가중치·데이터셋 파일은 MinIO를 통해 평가 컨테이너에 전달하되, 지나치게 범용적인 gRPC 컨텍스트 대신 필요한 식별자만 명시적으로 전달하도록 인터페이스를 줄임. 클라이언트 바이너리 재컴파일·재배포의 버전 관리와 디버깅 비용을 확인하고, 최소 의존성의 Python 소스와 사내 PyPI 패키지 배포 경로로 전환함.
결과와 근거
•
Prefect Web UI를 통해 평가 작업의 실행 상태·로그·소요 시간 확인, 오류 작업 취소와 latency 평가의 독점 실행을 제공하고, 안정형·확장형 서버 운영 시나리오와 사용 문서를 함께 배포함.
•
개인 장비에서 지표 등록 API 호출, Nubes 업로드와 서버 반영까지 검증하고, 등록 결과가 약 5분 주기로 리더보드에 반영되는 내부 배포를 완료함.
•
모델 평가 결과를 기록하기 위해 기존 model_zoo와 evaluation 스캐폴드를 모두 따라야 했던 결합을 낮추는 사용 경로를 만듦.
•
재설계한 플랫폼을 직접 사용해 Safety 학습 경로를 재현하고 모델 변경안을 비교했으며, 약 한 달 안에 기존 서비스 모델의 성능을 넘어선 모델을 개발함. 해당 모델은 이후 프로덕션에 반영됨.
한계와 확인 필요
•
광범위한 팀 채택이나 투자 대비 효과가 입증되었다는 근거는 없음. 최종 회고에도 가치 검증과 우선순위 설정을 더 일찍 했어야 한다는 판단이 남아 있음.
•
Prefect 서버 중단 시 평가 시스템 전체가 함께 중단되는 단일 장애점과 Web UI에서 수동으로 설정해야 했던 global concurrency limit가 남아 있었음. 인턴 종료 전 최종적으로 어떻게 완화했는지는 연결된 원천만으로 확인되지 않음.
•
"한 달 안에 기존 서비스 모델 성능을 넘어선 모델을 개발했고 해당 모델이 이후 프로덕션에 반영됨"은 2026-07-17 사용자 직접 확인을 근거로 사실로 채택함. 모델 배포 자체를 담당했다는 의미는 아님. 당시 원장 체계가 엄밀하지 않아 연결된 실험 노트만으로는 이 성과가 완전히 재구성되지 않음.
•
원장 기간은 2024.01-2024.07, 현재 이력서는 2024.01-2024.06으로 다름. 실제 근무 종료일 확인 필요함.
해석 및 이력서 표현 후보
•
내부 도구를 만들었다는 사실보다, 사용자 인터뷰로 낮은 채택 원인을 찾고 Experiment Management와 Model Registry의 책임을 분리한 제품·시스템 판단이 핵심임.
•
Prefect는 기술 스택 이름 자체보다 장시간 평가의 관측·취소·동시성 요구를 해결하기 위해 대안을 비교하고, 실제 장애를 겪으며 gRPC·컨테이너·DB 구조를 수정한 사례로 활용 가치가 있음.
•
재설계한 플랫폼을 직접 사용해 한 달 만에 서비스 모델 성능을 넘어선 모델을 개발했고, 해당 모델이 이후 프로덕션에 반영됐다는 점이 플랫폼 재설계와 모델 개발을 하나의 검증 서사로 연결함.
•
대표 문장 후보 1: "팀원 인터뷰로 평가 코드·실행 환경의 연동 부담이 플랫폼 사용을 막고 있음을 발견함. 개발 중에는 지표만 API로 기록하고, 검증된 모델 파일과 최종 벤치마크만 중앙 리더보드에서 관리하도록 Experiment Management와 Model Registry 역할을 분리함."
•
대표 문장 후보 2: "서로 다른 의존성을 가진 모델을 격리된 컨테이너에서 실행하고, 한정된 연산 자원을 공유하는 여러 장시간 평가 요청을 큐잉하며 latency 측정은 다른 작업의 간섭을 받지 않도록 Prefect·Docker 기반 평가 백엔드 구현을 채택함."
•
대표 문장 후보 3: "재설계한 플랫폼을 부적절 이미지 필터링 모델 개발에 직접 활용해 한 달 만에 기존 서비스 모델의 성능을 넘어서는 모델을 개발함. 해당 모델은 이후 프로덕션에 반영됨."