이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
최근 수업 프로젝트에서 `Apache Spark`를 처음 써봤습니다. 대용량 로그 데이터를 처리할 때 pandas로 시작했는데 메모리 오류가 계속 나서 Spark로 전환했습니다. 분산 처리 개념이 낯설었지만, DataFrame API는 pandas와 구조가 비슷해서 진입 장벽이 생각보다 낮았습니다.
조인 연산이 로컬에서 8분 걸리던 게 3분대로 줄었고, 그때 분산 처리가 실제로 어떤 상황에서 필요한지 체감했습니다. 지금도 데이터 크기를 먼저 보고 도구를 고르는 습관이 생겼습니다.
졸업 프로젝트에서 실시간 이벤트 데이터를 처리하는 파이프라인을 만들면서 처음 Apache Kafka를 도입했습니다. 사용자의 행동 로그를 DB에 직접 넣으면 쓰기 부하가 몰리는 문제가 있었고, Kafka를 중간에 두어 메시지를 버퍼링하는 구조로 바꿨습니다. Producer에서 토픽으로 이벤트를 보내고 Consumer가 배치 단위로 소비하도록 설정하자 DB 쓰기 횟수가 70% 이상 줄었습니다. 가장 배운 점은 파티션 수와 Consumer 그룹 설계가 처리량과 직결된다는 것이었습니다. 처음에 파티션을 1개로 설정했다가 Consumer를 늘려도 병렬 처리가 안 돼 3개로 조정했고, 그 과정에서 Kafka의 병렬성이 파티션 단위로 동작한다는 구조를 직접 체감했습니다.
데이터 흐름을 설계할 때 처리 속도보다 메시지 순서와 안정성을 먼저 고려해야 한다는 걸 이 프로젝트에서 배웠습니다.
데이터 분석 수업에서 Elasticsearch를 활용한 로그 검색 시스템을 구축해봤습니다. 서버 로그 약 500만 건을 RDBMS에 넣었더니 특정 패턴을 텍스트로 검색할 때 쿼리 시간이 10초 이상 걸렸고, Elasticsearch로 인덱싱하자 같은 검색이 200ms 이내로 줄었습니다. 처음에는 역색인 구조를 개념으로만 알고 있었는데, 실제 검색 결과와 스코어링이 어떻게 나오는지 보면서 왜 전문 검색엔진이 별도로 존재하는지 실감했습니다. 다만 집계 쿼리가 많아지자 메모리 사용량이 급격히 늘어서, 집계는 캐싱하고 검색 위주 쿼리만 실시간으로 처리하도록 구조를 나눴습니다.
도구는 어떤 연산을 주로 하느냐에 따라 적합성이 달라진다는 걸 이 경험으로 배웠고, 문제 유형에 맞는 저장소 선택이 기술 선택의 출발점이라는 생각이 생겼습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 데이터 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.