이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 레거시 시스템에서 신규 DB로 데이터를 이전하는 ETL 작업의 일부를 맡았습니다. 직접 Informatica를 쓰진 못했지만, 유사한 ETL 구조를 수업 과제로 설계한 경험이 있습니다. 소스와 타겟 테이블 간의 컬럼 매핑을 정리하는 과정에서 양쪽의 날짜 포맷이 달라 변환 중 데이터가 깨지는 문제가 생겼습니다. 처음엔 매핑 문서를 간단히 작성했는데 실제 데이터를 넣어보니 예외 케이스가 많이 나왔습니다. 이후 샘플 데이터 100건을 먼저 통과시켜 결과를 검토하는 단계를 추가했습니다. 이 단계에서 발견한 문제가 전체 이전 이후에 발견했을 경우보다 수정 비용이 훨씬 낮았습니다. ETL 설계에서 소규모 검증 단계를 앞에 두는 것이 얼마나 중요한지 이 경험으로 배웠습니다.
수업 프로젝트에서 여러 소스의 데이터를 하나로 합치는 ETL 파이프라인을 설계했습니다. 처음엔 오류가 나면 전체를 멈추도록 했는데, 소스 하나에 오류가 생길 때마다 전체가 중단되는 문제가 반복됐습니다. 오류가 드문 케이스가 아니라 데이터 품질이 일정하지 않은 소스에서는 흔한 상황이었습니다. 이후 오류 데이터를 별도 테이블에 기록하고 정상 데이터는 계속 처리하는 방식으로 바꿨습니다. 오류 기록에는 소스명, 발생 시각, 오류 이유를 남겨 나중에 확인할 수 있게 했습니다. 이 구조로 바꾼 뒤 전체 중단 없이 처리가 완료됐고, 오류 데이터는 별도로 재처리할 수 있게 됐습니다. ETL에서 오류는 피하는 것보다 잡아두고 처리하는 구조가 현실적이라는 걸 이 경험에서 배웠습니다.
졸업 프로젝트에서 두 개의 이질적인 데이터 소스를 통합하는 ETL 파이프라인을 만드는 팀에서 매핑 설계를 맡았습니다. 소스마다 같은 의미인데 컬럼 이름이 다르거나 값 표현 방식이 다른 경우가 많아서, 매핑 테이블을 문서로 먼저 정리했습니다. 처음에 매핑 기준을 팀원과 합의하지 않고 제 판단으로 작성했는데, 나중에 팀원이 다른 방식으로 이해하고 있었다는 걸 발견했습니다. 이후 매핑 초안을 공유하고 팀원이 검토하는 단계를 추가했습니다. 다른 시각에서 보니 제가 놓쳤던 케이스 5개를 팀원이 발견해줬습니다. 검토 단계를 넣기 전보다 나중에 발견되는 오류가 크게 줄었습니다. ETL 설계에서 매핑 정의는 혼자 완성하려 하기보다 검토를 거치는 것이 결과물을 더 안전하게 만든다는 걸 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 SK inc.(AX) 데이터 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.