이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
직접적인 Flink 경험은 없지만, 학교 프로젝트에서 실시간 데이터 처리 파이프라인을 구축해보았습니다. Kafka로 이벤트를 발행하고, Python으로 스트림을 소비하는 구조였는데, 이벤트 순서 보장과 처리 지연 관리가 예상보다 복잡하다는 것을 느꼈습니다. Flink를 공부하면서 상태 관리(State)와 워터마크 개념이 그 문제를 더 체계적으로 해결하는 방식이라는 것을 이해하였습니다.
스트리밍 처리의 복잡성을 직접 경험한 것이 Flink를 배우는 동기가 되었습니다. 이론보다 문제를 먼저 경험하면 기술의 존재 이유가 명확하게 보입니다. 문제 경험 없이 기술을 배우면 왜 그 기술이 필요한지를 이해하기 어렵다는 것을 그때 배웠습니다.
Flink는 학습 중이에요. 스트리밍 처리를 공부하면서 배치 처리와의 근본적인 차이를 이해하게 됐어요. 배치는 결과를 기다리지만, 스트리밍은 데이터가 오는 대로 즉시 처리하는 구조라 지연 시간이 훨씬 중요해요. Flink의 Time Window와 Exactly-Once 시맨틱이 실시간 데이터 정합성을 지키는 핵심이라는 걸 이론으로 배웠고, 실습으로 확인하고 싶은 부분이 많아요.
스트리밍과 배치의 차이를 이해하면 어떤 기술을 언제 써야 하는지 판단이 생겨요. 데이터 흐름 방식의 이해가 기술 선택의 기반이에요. 진짜 실시간 처리가 필요한 이유를 이해하면 기술 선택이 훨씬 명확해져요.
스트리밍 처리 경험은 Spark Streaming으로 먼저 접했어요. 팀 프로젝트에서 IoT 센서 데이터를 실시간으로 처리하고 이상 탐지하는 과제였는데, 마이크로배치 방식의 한계를 느꼈어요. 처리 속도가 진짜 실시간이 아니라 짧은 배치의 반복이라 지연이 발생했어요. Flink는 그 문제를 네이티브 스트리밍으로 해결한다는 걸 이후에 알았고, 다음 프로젝트에서 써보고 싶은 기술이에요.
마이크로배치의 한계를 경험한 것이 진짜 스트리밍 기술의 가치를 이해하는 계기가 됐어요. 문제에서 시작한 학습이 가장 오래 남아요. 기존 방식의 한계를 직접 경험해야 새로운 기술의 필요성이 진짜로 와닿아요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 토스 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.