이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
TIBCO Rendezvous를 직접 사용해본 경험은 없지만, 팀 프로젝트에서 RabbitMQ를 활용하면서 발행-구독 모델의 메시지 브로커가 어떻게 동작하는지 배웠습니다.
TIBCO RV가 금융권에서 많이 사용되는 이유를 찾아보니 멀티캐스트 기반이라 브로커 없이도 낮은 레이턴시를 보장한다는 점이 특징이라는 것을 알게 되었습니다. 브로커가 단일 실패 지점이 되는 문제를 피할 수 있는 구조였습니다.
팀 프로젝트에서는 RabbitMQ 브로커가 죽으면서 메시지가 전부 유실된 경험이 있었습니다. 이후 퍼시스턴트 큐와 확인 응답을 추가했는데, TIBCO RV의 자체 신뢰성 메커니즘과 유사한 개념이라는 것을 이후에 알게 되었습니다. 직접 경험은 없지만 빠르게 익힐 자신이 있습니다.
TIBCO RV는 써본 적이 없지만, 인턴 때 메시지 큐 기반 파이프라인에서 네트워크 순단 때 메시지가 조용히 유실되는 문제를 겪은 적이 있어요.
RabbitMQ를 쓰고 있었는데, 컨슈머가 재접속할 때 그 사이에 들어온 메시지가 기본 설정에서는 버려진다는 걸 뒤늦게 알았습니다. 이미 1,000건 넘는 이벤트가 유실된 후였어요.
이후 퍼시스턴트 큐와 수동 ACK로 바꾸고, 컨슈머가 처리를 확인하기 전까지는 메시지를 지우지 않도록 설정했습니다. TIBCO RV도 유사한 신뢰성 보장 기능을 가지고 있다고 알고 있어서, 실제로 써보면 개념 연결이 빠를 것 같아요.
TIBCO RV를 직접 다뤄본 경험은 없지만, 졸업 프로젝트에서 여러 서비스가 같은 이벤트를 동시에 받아야 하는 구조를 설계하면서 발행-구독 패턴을 처음 구현했어요.
처음엔 서비스마다 직접 API를 호출하는 방식으로 짰는데, 구독자가 3개를 넘어가니 발행 측 코드가 점점 복잡해졌어요. 이벤트 버스로 분리하고 나서야 발행 측이 구독자를 몰라도 되는 구조가 됐습니다.
TIBCO RV가 금융 시스템에서 신뢰성 있는 멀티캐스트 메시징에 쓰인다는 걸 읽었는데, 제가 소규모로 구현한 것과 개념은 같고 규모와 신뢰성 보장 방식이 다른 것 같았어요. 실무에서 배울 기회가 생기면 기존에 익힌 메시징 개념을 토대로 빠르게 적응할 수 있을 것 같습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 SK inc.(AX) 데이터 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.