이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 프로젝트에서 데이터 파이프라인 일부를 자동 복구되도록 개선하는 과제를 맡았습니다. 처음에는 LLM 기반 이상 감지 모듈을 붙이면 간단할 줄 알았는데, 정작 어려운 건 오류 로그 구조가 너무 달라 LLM에 넘길 입력을 통일하는 작업이었습니다. 수집 소스마다 스키마가 달라 정규화 레이어를 먼저 짰고, 오류 패턴을 15가지로 분류해 각 패턴에 대한 복구 액션 맵을 정의했습니다. LLM은 분류 판단에만 쓰고 실제 복구는 결정적인 스크립트가 처리하도록 역할을 나눴더니 안정성이 높아졌습니다. 완전 자동화보다 사람이 검토할 지점을 명확히 두는 설계가 운영 단계에서 훨씬 낫다는 걸 배웠습니다.
자동화 설계는 실패 케이스를 먼저 열거하는 데서 시작해야 한다는 것도 이 경험에서 배웠습니다.
팀 프로젝트에서 배치 파이프라인 장애 감지를 자동화하는 역할을 맡았습니다. 초기에는 LLM이 동일한 오류 로그를 다른 라벨로 분류하는 문제가 반복됐습니다. 원인은 수집 소스마다 로그 형식이 달라 컨텍스트에 들어가는 내용이 매번 달라진 것이었습니다. 해결을 위해 LLM에 넘기기 전 필수 필드(타임스탬프, 오류 코드, 스택 트레이스 상위 3줄)만 추출하는 전처리 레이어를 추가했습니다. 입력이 통일되자 분류 일관성이 눈에 띄게 올라갔습니다. Self-Healing 구조에서 LLM 앞단의 전처리가 모델 선택보다 중요한 순간이 있다는 걸 배웠습니다. 자동화 설계에서 입력의 일관성을 먼저 확보하지 않으면 모델이 아무리 좋아도 불안정한 구간이 생긴다는 게 그 프로젝트의 핵심 교훈이었습니다.
데이터 엔지니어링 수업 팀 프로젝트에서 모델 드리프트 감지 모듈을 파이프라인에 붙이는 작업을 맡았습니다. 가장 어려웠던 건 드리프트 기준을 무엇으로 정할지였습니다. 처음에는 예측 분포 변화만 기준으로 삼았는데, 정상 분포 안에서도 오류가 발생하는 케이스가 나왔습니다. 결국 입력 스키마 변화와 예측값 분포 모니터링을 두 채널로 분리해 각각 알림을 보내는 구조로 바꿨습니다.
두 채널 중 하나만 발화해도 사람이 확인하게 만든 것이 오탐을 줄이는 데 효과적이었습니다. AI가 판단을 대신하는 게 아니라 이상 신호를 플래그하고 사람이 최종 결정하는 방식이 운영 단계에서 더 안전한 구조였습니다. 그 경험 이후로 파이프라인 설계 초기에 실패 시 누가 어떤 신호를 받을지를 먼저 그려두는 습관이 생겼습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.