이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
Azure Data Factory로 데이터 파이프라인을 구축한 경험에서 가장 중요하게 다룬 것은 소스와 싱크 간 스키마 불일치 처리였습니다. 원본 데이터와 목적지 테이블의 컬럼 형식이 달라 Mapping Data Flow에서 변환 로직을 직접 구성했습니다.
파이프라인 구성 시 의존성 있는 활동 간 순서 제어도 중요했습니다. 앞 단계가 완료되기 전에 다음 단계가 실행되면 빈 데이터를 읽는 문제가 생겨, 성공 조건 트리거를 활동 간에 명시적으로 설정했습니다.
운영 안정성을 위해 오류 알림과 파이프라인 재실행 구조를 구성했습니다. 실패한 활동만 선택적으로 재실행할 수 있는 기능을 활용해 전체를 다시 돌리지 않아도 복구가 가능하도록 했습니다.
Azure Data Factory를 쓰면서 파이프라인이 복잡해질수록 디버깅이 어려워지는 한계를 경험했습니다. 단순한 복사 작업은 직관적이었는데, Mapping Data Flow에서 여러 변환 단계를 연결하다 보면 중간 단계의 데이터 상태를 확인하기 어려웠습니다. 데이터 미리보기 기능이 있었지만 실제 데이터 크기에서 실행하면 속도가 느렸습니다. 오류 메시지도 어느 변환 단계에서 문제가 생겼는지 정확히 특정하기 어려운 경우가 있었습니다. 비용 관리도 신경 쓰였는데, Mapping Data Flow는 클러스터를 띄우는 비용이 발생해서 간단한 변환은 데이터 흐름보다 다른 방식이 더 경제적이라는 것을 알게 됐습니다. 스케줄 트리거를 잘못 설정하면 불필요하게 파이프라인이 자주 실행되는 경우도 있었습니다. ADF는 코드 없이 파이프라인을 구성할 수 있다는 장점이 있지만, 복잡한 변환 로직은 오히려 코드로 구현하는 것이 추적하기 쉬울 수 있다는 것을 이 경험에서 배웠습니다.
Azure Data Factory 파이프라인을 운영하면서 파이프라인이 실패했을 때 어떻게 알고 어떻게 복구할지 설계하는 것이 구축 자체만큼 중요하다는 것을 배웠습니다. 처음에는 실패가 나면 직접 포털에 들어가서 확인하는 방식이었는데, 경보 정책을 설정해서 실패 시 이메일 알림이 오도록 바꿨습니다. 파이프라인 전체를 다시 시작하면 이미 완료된 단계도 다시 실행되는 낭비가 생겼는데, 실패한 활동만 선택적으로 재실행하는 구조를 적용하니 복구 시간이 줄었습니다. 데이터 품질 검증 단계도 추가했는데, 변환 완료 후 목적지에 적재된 행 수와 소스 행 수를 비교하는 체크를 넣으니 데이터가 누락 없이 이동됐는지 확인할 수 있었습니다. 파이프라인은 구축 후 운영 관점에서 알림, 재처리, 품질 검증을 함께 설계해야 한다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넥스트증권 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.