이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 프로젝트에서 클라우드 데이터 처리 파이프라인을 만들었는데, 처음에는 레코드를 1건씩 처리하도록 짰더니 10만 건 처리에 40분이 걸렸습니다. 완전히 실용성이 없는 속도였습니다.
원인 분석해보니 DB 연결을 매 레코드마다 맺고 끊는 것이 문제였습니다. 배치 사이즈를 1,000건으로 묶어서 처리하도록 바꾸고 트랜잭션을 묶으니 같은 10만 건이 4분으로 줄었습니다. 처음에는 배치 크기를 너무 크게 잡아서 메모리 에러가 났고, 500~1,000 구간이 이 환경에서 최적이라는 것을 실험으로 알아냈습니다.
그 경험에서 배운 것은 파이프라인 성능은 알고리즘보다 I/O 패턴이 먼저라는 것입니다. 코드 로직보다 데이터를 어떻게 읽고 쓰는지가 10배 이상 차이를 만들 수 있다는 것을 직접 보았기에 설계할 때 항상 I/O 흐름을 먼저 생각하게 되었습니다. 그 실패가 성능 설계를 배우는 계기가 되었습니다.
개인 프로젝트에서 로그 데이터를 분석하는 파이프라인을 만들었는데, 날짜 조건으로 조회해도 전체 테이블을 풀스캔한다는 걸 실행 계획에서 발견했어요.
그때 테이블 파티셔닝을 처음 적용해봤어요. 날짜 컬럼 기준으로 월별 파티션을 나누고 쿼리에 날짜 조건을 명시하니까, 실행 계획에서 파티션 프루닝이 동작하면서 스캔 범위가 전체의 1/12 수준으로 줄었습니다. 처리 시간은 28초에서 4초로 줄었어요.
파티셔닝이 마법이 아니라 쿼리 조건이 파티션 키와 일치할 때만 효과가 있다는 것도 그때 배웠어요. 처음에 파티션 키와 다른 컬럼으로 조회했더니 오히려 더 느려지는 실수를 했거든요. 설계 단계에서 어떤 조건으로 데이터를 볼 건지를 먼저 생각해야 한다는 걸 배웠습니다.
이 경험이 데이터 설계를 쿼리 패턴부터 시작하는 습관을 만들어줬습니다.
팀 프로젝트에서 데이터 파이프라인이 느리다는 불만이 나왔는데, 어느 단계가 느린지 아무도 몰랐어요. 다들 '전체적으로 느리다'고만 했고, 각 단계 소요 시간을 측정하는 코드가 없었습니다.
각 단계 시작과 끝에 타임스탬프 로깅을 추가했더니 전처리 단계 하나가 전체 시간의 73%를 차지하고 있다는 걸 발견했어요. 원인은 반복 루프 안에서 정규식 컴파일을 매번 하고 있었던 것이었고, 패턴 객체를 캐싱하는 것만으로 해당 단계가 8초에서 0.9초로 줄었습니다.
그 경험에서 최적화는 추측이 아니라 측정에서 시작해야 한다는 걸 배웠어요. '이 부분이 느릴 것 같다'는 직관이 틀린 경우가 더 많았거든요. 지금은 파이프라인 코드를 짤 때 로깅 포인트를 처음부터 심어두는 걸 기본으로 합니다. 그 경험 덕분에 한 단계 성장할 수 있었습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 CJ올리브영 ML 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.