이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
캡스톤 프로젝트에서 공공 데이터를 하루 한 번 내려받아 분석하는 배치 파이프라인을 만들었습니다. 처음에는 간단해 보였으나, 원천 데이터 스키마가 갑자기 바뀌면서 파이프라인이 통째로 멈추는 문제가 첫 주에 발생했습니다.
그때부터 스키마 변경 알림을 먼저 탐지하는 검증 단계를 앞에 추가하였습니다. 데이터가 기대 형식이 아닐 경우 파이프라인을 중단하고 슬랙으로 알림이 오도록 설정했습니다.
이후 요구사항이 변경되어 Apache Kafka를 사용하여 실시간 처리로 전환하는 작업도 맡았습니다. 기존 배치 로직을 스트림 처리에 맞게 다시 작성하는 것이 생각보다 어려웠습니다. 특히 집계 윈도우 설계에서 두 번이나 로직을 수정하였습니다. 완성 후 지연 시간이 하루에서 5초 이내로 줄어들었습니다.
인턴 때 로그 데이터를 수집해서 분석 대시보드에 올리는 파이프라인을 담당했어요. 2주 뒤 팀장님이 대시보드 숫자가 이상하다고 지적했는데, 알고 보니 수집 중 null 값이 그대로 DB에 들어가 있었습니다.
파이프라인에 검증 단계가 없었던 게 원인이었어요. 이후 null 비율, 범위 이탈, 중복 레코드 체크를 적재 전에 먼저 돌리고, 실패하면 해당 배치를 격리하는 구조를 추가했습니다.
처음엔 검증이 파이프라인 속도를 느리게 할까 걱정했는데, 배치 10만 건 기준으로 검증 추가 오버헤드가 3초 미만이라 실제로는 큰 영향이 없었어요. 나쁜 데이터가 들어가면 분석 결과 전체가 흔들린다는 걸 몸으로 배운 경험입니다.
PM이나 PL로 팀을 이끈 경험은 없지만, 4인 팀에서 데이터 수집·가공 부분을 담당한 적이 있어요.
크롤러로 뉴스 기사를 수집해서 DB에 넣는 작업을 맡았는데, 사이트마다 HTML 구조가 달라서 파서가 계속 깨졌어요. 처음엔 사이트별로 파서를 하드코딩했는데, 3개 사이트를 넘어가니 유지보수가 힘들었습니다.
그래서 CSS 선택자를 설정 파일로 분리하고, 새 사이트를 추가할 때 코드를 건드리지 않아도 되는 구조로 바꿨어요. 이 변경 덕에 팀원이 혼자 사이트 2개를 추가할 수 있었습니다. 명시적으로 리드를 맡지 않아도 코드 구조 개선으로 팀 속도를 높인 경험이라 기억에 남아요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 비즈테크아이 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.