이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
인턴 때 기존 스케줄 기반 배치를 이벤트 기반으로 바꾸는 검토를 맡았습니다. 처음에는 들어본 것들 중 괜찮아 보이는 것을 고르면 되겠다고 생각했는데, 막상 옵션이 여러 개였고 각각 장단이 달랐습니다. 저는 먼저 기존 배치의 처리량과 지연을 측정해 수치를 잡는 것부터 시작했습니다. 그 수치가 선택 기준의 근거가 됐습니다. 이후 두 가지 후보를 각각 로컬에서 간단한 파이프라인으로 구성해 비교했습니다. 처리 지연 목표를 맞추는 데는 둘 다 가능했지만, 팀이 이미 익숙한 생태계와 연동하기 쉬운 쪽을 선택 기준 중 하나로 추가했습니다. 처음에는 새로운 기술이면 어김없이 좋은 것으로 판단했다가, 팀원 중 한 명이 운영하는 사람이 이해할 수 있어야 한다고 짚어주셔서 기준을 바꿨습니다. 최종 선택안과 이유를 문서로 정리해 리뷰를 받았고, 이 경험으로 기술 선택은 성능만이 아니라는 걸 알게 됐습니다.
졸업 프로젝트에서 팀이 쓰던 데이터 처리 방식이 데이터가 늘수록 느려지는 문제가 생겼습니다. 처음엔 코드를 최적화하면 되겠다고 생각했지만, 측정해보니 근본 원인이 사용하던 라이브러리의 단일 스레드 처리 방식에 있었습니다. 다른 도구를 찾아야 했습니다. 후보를 세 가지로 줄인 뒤, 각각 우리 데이터셋과 비슷한 규모의 샘플로 처리 시간을 측정했습니다. 그 결과를 스프레드시트에 정리해 팀원들과 공유했습니다. 한 도구는 성능은 좋았지만 설치 의존성이 복잡해서 팀원이 환경 설정하는 데만 이틀이 걸릴 것 같았습니다. 결국 성능이 두 번째였지만 설치가 간단하고 문서가 충분한 쪽을 골랐습니다. 도입 후 처리 시간이 기존 대비 약 55% 줄었습니다. 성능을 어느 정도 양보해도 팀 전체가 쓸 수 있는 도구를 고르는 게 낫다는 판단이었고, 지금도 그게 맞는 선택이었다고 생각합니다.
개인 사이드 프로젝트에서 데이터 저장 방식을 기존 방식에서 컬럼형 포맷으로 바꾸는 실험을 해봤습니다. 읽기 성능이 좋다는 글을 보고 바꿨는데, 처음엔 실제로 조회 속도가 빨라져서 만족했습니다. 그런데 쓰기가 많아지는 구간에서 파일 크기가 예상보다 빠르게 늘어나는 문제를 발견했습니다. 작은 데이터를 자주 쓰는 패턴에서는 압축 효율이 오히려 낮아지는 특성이 있었습니다. 처음엔 이런 특성이 있다는 걸 전혀 몰랐습니다. 이후 쓰기를 일정량 모아서 한 번에 플러시하는 방식으로 바꿨더니 파일 크기 문제가 해결됐습니다. 다만 쓰기 직후 바로 읽으면 아직 플러시되지 않은 데이터가 보이지 않는 경우가 생겨 그 부분을 추가로 처리해야 했습니다. 기술을 도입하면 예상치 못한 부작용이 따라오는 경우가 많다는 걸, 작은 프로젝트에서 먼저 경험할 수 있어서 좋았습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 데이터 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.