비동기 처리 Stream Engine인 MQ나 Kafka를 활용한 경험이 있다면, 어떤 프로젝트에서 어떻게 사용했는지 설명해 주세요. | CJ올리브영 백엔드 면접 질문

CCJ올리브영백엔드경험·이력2026년 출제

답변 미리보기

서비스 간 결합을 낮추기 위해 Kafka를 처음 도입한 건 주문 완료 후 이메일 발송 흐름이었습니다. 기존엔 동기 호출로 연결돼 이메일 서비스가 느리면 주문

예상 답변 시간

60~90초

예상 꼬리질문

3회

난이도

난이도 중상

출제 빈도

높음

INTERVIEWER'S INTENT · 면접관의 의도

이 질문, 네 갈래로 뜯어봅니다.

면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.

맥락 결을 짚는가?

처리량·지연·기간 결을 짚는 흔적이 강합니다. 막연한 '경험 있다'만 답하면 면접관이 결을 다시 묻는 자리가 자주 보입니다.

방법 결이 구체인가?

파티션·복제·소비 결을 짚는 흔적이 답에 있어야 합니다. 한 결만 답하면 면접관이 결을 다시 캐는 결이 자주 통합합니다.

본인 사례 결을 받치는가?

구체 케이스·결과 결을 자기 언어로 짚는 흔적이 강하게 통합합니다. 이론만 답하면 면접관이 적용을 다시 묻는 자리가 강합니다.

측정 결이 있는가?

지연·전송·재현 결을 짚는 흔적이 자주 통합합니다. 정성 평가만 답하면 면접관이 객관성을 다시 캐는 자리가 강합니다.

말로 해봐야 는다

읽는 것과 말하는 건 다릅니다.
이 질문, 소리 내어 답해 볼까요?

CJ올리브영 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.

음성으로 답해보기

토픽 이벤트 발행 → 컨슈머 그룹 → 멱등성 처리 추가약 90초 Kafka 도입 후 메시지 지연 지표를 측정하며 컨슈머 수를 조정한 경험약 120초 메시지 큐 도입 후 메시지 유실 가능성을 발견하고 보완한 경험약 120초

예시 답변 1

약 90초

토픽 이벤트 발행 → 컨슈머 그룹 → 멱등성 처리 추가

서비스 간 결합을 낮추기 위해 Kafka를 처음 도입한 건 주문 완료 후 이메일 발송 흐름이었습니다. 기존엔 동기 호출로 연결돼 이메일 서비스가 느리면 주문 API도 함께 느려졌는데, 토픽으로 이벤트를 발행하고 컨슈머가 독립적으로 처리하는 구조로 바꿨습니다.

컨슈머 그룹을 활용해 같은 토픽을 여러 서비스가 독립적으로 소비할 수 있게 됐고, 통계 집계 서비스를 추가할 때 프로듀서 코드를 전혀 수정하지 않아도 됐습니다. 처음에는 메시지 중복 소비 문제를 고려하지 않아 이메일이 여러 번 발송되는 버그가 있었고, 멱등성 처리를 추가하는 게 배포 후 긴급 패치가 됐습니다.

at-least-once 보장이 멱등 컨슈머를 전제한다는 걸 직접 겪으며 배웠습니다.

이 결의 특징

서비스 간 결합을 낮추기 위해 Kafka를 처음 도입한 건 주문 완료 후 이메일 발송 흐름이었습니다. 기존엔 동기 호출로 연결돼 이메일 서비스가 느리면 주문 API도 함께 느려졌는데, 토픽으로 이벤트를 발 흔적이 있습니다.

이 결이 통하는 자리

니다. 처음에는 메시지 중복 소비 문제를 고려하지 않아 이메일이 여러 번 발송되는 버그가 있었고, 멱등성 처리를 추가하는 게 배포 후 긴급 패치가 됐습니다. at-least-once 보장이 멱등 컨슈머를 전 통합니다.

예시 답변 2

약 120초

Kafka 도입 후 메시지 지연 지표를 측정하며 컨슈머 수를 조정한 경험

Kafka를 도입하고 나서 처음에는 단순히 동작하는지만 확인했는데, 운영하면서 컨슈머가 처리하는 속도보다 메시지가 쌓이는 속도가 빠른 상황이 생겼습니다. 컨슈머 랙이라고 부르는 지표를 모니터링하기 시작했는데, 특정 시간대에 이벤트가 몰리면서 처리 지연이 발생하는 것을 수치로 확인할 수 있었습니다. 파티션 수와 컨슈머 수를 늘려서 병렬 처리를 확대하니 지연이 줄었는데, 파티션 수보다 컨슈머 수가 많으면 일부 컨슈머가 놀게 된다는 것도 이 과정에서 알게 됐습니다. 이전 동기 방식에서는 처리 지연이 API 응답 시간에 바로 나타났는데, Kafka로 분리한 이후에는 메시지 처리 지연이 별도 지표로 관리되기 때문에 모니터링 방식도 달라져야 한다는 것을 배웠습니다. 비동기 처리 시스템은 동작한다고 끝이 아니라 컨슈머 랙 같은 지표를 지속적으로 관찰해야 실제 서비스 품질을 유지할 수 있다는 것을 이 경험에서 배웠습니다.

이 결의 특징

Kafka를 도입하고 나서 처음에는 단순히 동작하는지만 확인했는데, 운영하면서 컨슈머가 처리하는 속도보다 메시지가 쌓이는 속도가 빠른 상황이 생겼습니다. 컨슈머 랙이라고 부르는 지표를 모니터링하기 시작했는데, 흔적이 있습니다.

이 결이 통하는 자리

놀게 된다는 것도 이 과정에서 알게 됐습니다. 이전 동기 방식에서는 처리 지연이 API 응답 시간에 바로 나타났는데, Kafka로 분리한 이후에는 메시지 처리 지연이 별도 지표로 관리되기 때문에 모니터링 방식 통합니다.

예시 답변 3

약 120초

메시지 큐 도입 후 메시지 유실 가능성을 발견하고 보완한 경험

메시지 큐를 도입하면서 처리가 완료되기 전에 시스템이 재시작되면 메시지가 유실될 수 있다는 것을 운영 중에 알게 됐습니다. 컨슈머가 메시지를 받은 직후 오프셋을 자동으로 커밋하는 설정이 기본으로 돼 있었는데, 오프셋이 커밋됐지만 실제 처리가 완료되기 전에 장애가 생기면 그 메시지는 다시 처리되지 않았습니다. 오프셋 커밋을 처리 완료 후에 수동으로 하는 방식으로 바꾸니 장애 후 재시작해도 미처리 메시지를 이어받아 처리할 수 있었습니다. 이 변경으로 중복 처리 가능성이 생겼는데, 처리 결과를 저장할 때 같은 메시지 ID를 두 번 처리해도 결과가 달라지지 않도록 멱등성을 보장하는 로직을 추가했습니다. 메시지 큐를 사용할 때 전달 보장 방식과 멱등성 처리는 함께 설계해야 하는 문제라는 것을 이 경험에서 배웠습니다.

이 결의 특징

메시지 큐를 도입하면서 처리가 완료되기 전에 시스템이 재시작되면 메시지가 유실될 수 있다는 것을 운영 중에 알게 됐습니다. 컨슈머가 메시지를 받은 직후 오프셋을 자동으로 커밋하는 설정이 기본으로 돼 있었는데, 흔적이 있습니다.

이 결이 통하는 자리

리할 수 있었습니다. 이 변경으로 중복 처리 가능성이 생겼는데, 처리 결과를 저장할 때 같은 메시지 ID를 두 번 처리해도 결과가 달라지지 않도록 멱등성을 보장하는 로직을 추가했습니다. 메시지 큐를 사용할 때 통합니다.

위 답변은 여러 풀이 중 한 가지 예시입니다. 정답이 아니며, 외워서 그대로 말하면 면접관이 다음 질문을 그 자리에서 시작하는 경우가 많습니다. 본인의 프로젝트·기준·숫자로 다시 짜는 자리로만 쓰세요.

자주 빠지는 자리

같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.

MQ와 Kafka를 구분하지 않고 뭉뚱그리지 않았는가? 두 기술은 구조와 쓰임이 다릅니다.
왜 비동기 처리가 필요했는지 배경을 빼놓지 않았는가? 어떤 문제 상황이었는지가 있어야 합니다.
프로젝트 규모나 트래픽 조건을 언급하지 않았는가? 상황에 맞는 기술 선택이었는지가 드러나야 합니다.
장애나 메시지 유실 같은 운영 이슈를 생략하지 않았는가? 도입만 말하면 운영 경험이 없어 보입니다.

이어질 꼬리질문

진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.

壹메시지 유실을 어떻게 풀까요?

대응ACK·재시도 결을 자기 언어로 짚는 답이 강하게 통합합니다. 직관만 답하면 통제 흔적이 약하게 읽히는 자리가 자주 보입니다.

貳처리량과 일관이 충돌하면 어떻게 풀까요?

대응기준·근거 결을 짚는 답이 자주 통합합니다. 한쪽만 답하면 균형 흔적이 약하게 보이는 자리가 강합니다.

參체계를 다시 짠다면 무엇을 바꾸시겠어요?

대응설계·측정·기록 중 어디를 손볼지 짚는 결이 강합니다. 그대로 가겠다는 답은 학습 흔적이 약하게 읽히는 자리가 자주 보입니다.

이제, 직접 답해볼 차례예요.

눈으로 읽은 답은 면접장에서 나오지 않아요. CJ올리브영 면접관과 이 질문으로 한 번 대화해 보세요.

이 질문으로 모의면접 해보기

안내 · 이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 실제 출제·회사 공식 입장과는 무관하며, 정정 요청 시 24시간 내 반영합니다. 자세히

개인정보처리방침 이용약관 문의

CCJ올리브영백엔드경험·이력2026년 출제

답변 미리보기

예상 답변 시간

60~90초

예상 꼬리질문

3회

난이도

난이도 중상

출제 빈도

높음

INTERVIEWER'S INTENT · 면접관의 의도

이 질문, 네 갈래로 뜯어봅니다.

면접관이 이 한 문장으로 확인하려는 것들. 각 갈래를 알면 답의 뼈대가 잡혀요.

맥락 결을 짚는가?

처리량·지연·기간 결을 짚는 흔적이 강합니다. 막연한 '경험 있다'만 답하면 면접관이 결을 다시 묻는 자리가 자주 보입니다.

방법 결이 구체인가?

파티션·복제·소비 결을 짚는 흔적이 답에 있어야 합니다. 한 결만 답하면 면접관이 결을 다시 캐는 결이 자주 통합합니다.

본인 사례 결을 받치는가?

구체 케이스·결과 결을 자기 언어로 짚는 흔적이 강하게 통합합니다. 이론만 답하면 면접관이 적용을 다시 묻는 자리가 강합니다.

측정 결이 있는가?

지연·전송·재현 결을 짚는 흔적이 자주 통합합니다. 정성 평가만 답하면 면접관이 객관성을 다시 캐는 자리가 강합니다.

말로 해봐야 는다

읽는 것과 말하는 건 다릅니다.
이 질문, 소리 내어 답해 볼까요?

CJ올리브영 면접관 페르소나가 이 질문을 던지고, 당신의 답에 꼬리질문으로 되물어요.

음성으로 답해보기

예시 답변 1

약 90초

토픽 이벤트 발행 → 컨슈머 그룹 → 멱등성 처리 추가

at-least-once 보장이 멱등 컨슈머를 전제한다는 걸 직접 겪으며 배웠습니다.

이 결의 특징

이 결이 통하는 자리

예시 답변 2

약 120초

Kafka 도입 후 메시지 지연 지표를 측정하며 컨슈머 수를 조정한 경험

이 결의 특징

이 결이 통하는 자리

예시 답변 3

약 120초

메시지 큐 도입 후 메시지 유실 가능성을 발견하고 보완한 경험

이 결의 특징

이 결이 통하는 자리

자주 빠지는 자리

같은 실수가 반복돼요. 이것만 피해도 절반은 갑니다.

MQ와 Kafka를 구분하지 않고 뭉뚱그리지 않았는가? 두 기술은 구조와 쓰임이 다릅니다.
왜 비동기 처리가 필요했는지 배경을 빼놓지 않았는가? 어떤 문제 상황이었는지가 있어야 합니다.
프로젝트 규모나 트래픽 조건을 언급하지 않았는가? 상황에 맞는 기술 선택이었는지가 드러나야 합니다.
장애나 메시지 유실 같은 운영 이슈를 생략하지 않았는가? 도입만 말하면 운영 경험이 없어 보입니다.

이어질 꼬리질문

진짜 면접은 두 번째 질문부터예요. 이 답 뒤에 따라올 법한 것들.

壹메시지 유실을 어떻게 풀까요?

대응ACK·재시도 결을 자기 언어로 짚는 답이 강하게 통합합니다. 직관만 답하면 통제 흔적이 약하게 읽히는 자리가 자주 보입니다.

貳처리량과 일관이 충돌하면 어떻게 풀까요?

대응기준·근거 결을 짚는 답이 자주 통합합니다. 한쪽만 답하면 균형 흔적이 약하게 보이는 자리가 강합니다.

參체계를 다시 짠다면 무엇을 바꾸시겠어요?

대응설계·측정·기록 중 어디를 손볼지 짚는 결이 강합니다. 그대로 가겠다는 답은 학습 흔적이 약하게 읽히는 자리가 자주 보입니다.

이제, 직접 답해볼 차례예요.

눈으로 읽은 답은 면접장에서 나오지 않아요. CJ올리브영 면접관과 이 질문으로 한 번 대화해 보세요.

이 질문으로 모의면접 해보기

개인정보처리방침 이용약관 문의