이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
졸업 작품으로 쇼핑몰 주문 데이터를 분석해 재고 보충 시점을 예측하는 파이프라인을 Python으로 만들었습니다. 판매 이력을 읽어 이동평균으로 수요를 예측하고, 재고 임계값 이하로 떨어지면 이메일을 보내는 흐름이었습니다.
처음엔 모든 처리를 하나의 큰 함수에 넣었는데, 테스트하기 어렵고 단계별 중간 결과를 확인할 수 없는 구조였습니다. 단계별로 함수를 분리하고 각 단계 출력을 로그로 남기니 문제 발생 시 어디서 틀렸는지 바로 보였습니다.
3개월 데이터 기준으로 예측 오차가 12% 이내로 유지됐고, 실제 재고 부족 이벤트 4번 중 3번을 사전에 감지했습니다. 파이프라인은 투명하게 만드는 것이 기능만큼 중요하다는 걸 그때 배웠습니다.
팀 프로젝트에서 회원 등급별, 시간대별, 쿠폰 유형별 할인이 중첩 적용되는 로직을 Java로 구현했습니다. 처음엔 if-else 분기가 4단계까지 중첩됐고, 새 정책이 추가될 때마다 어디를 수정해야 할지 저도 찾기 어려웠습니다.
각 할인 정책을 인터페이스로 분리하고 실행 순서를 리스트로 관리하는 구조로 바꿨습니다. 새 정책이 생기면 구현체 하나를 추가하고 리스트에 넣는 것만으로 반영됩니다. 코드 줄 수는 늘었지만 정책 추가 시 기존 코드를 건드리지 않게 됐습니다.
리팩터 전 단위 테스트를 먼저 작성해 두고 리팩터 후에도 통과하는지 확인했습니다. 테스트가 안전망이 되어준 덕분에 과감하게 구조를 바꿀 수 있었습니다. 비즈니스 로직 구현에서 확장 가능성과 테스트 가능성을 함께 설계하는 습관이 그때 생겼습니다.
사이드 프로젝트에서 수수료 정산 기능을 Python으로 만들 때, float 타입으로 계산하다 하루 전체 합산이 1~3원 차이나는 오류가 생겼습니다. 금액이 소액이라 처음엔 대수롭지 않게 봤는데, 날짜가 쌓이면 수십 원이 됐습니다.
`decimal.Decimal`로 전환하고 반올림 방식을 `ROUND_HALF_UP`으로 명시했습니다. 동시에 일별 정산 결과를 외부 장부 합계와 비교하는 자동 검증 스크립트도 추가했습니다.
`float`의 부동소수점 오차가 이렇게 누적될 줄 몰랐습니다. 이후엔 금액이 포함된 모든 계산에서 Decimal을 첫 번째 선택으로 쓰게 됐습니다. Python에서 비즈니스 금융 로직을 짤 때 타입 선택이 정확성을 좌우한다는 것이 그 경험이 남긴 교훈입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 데이터 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.