Kim.C.J.

[면접 복기] Kafka, MQ 기반의 전공 면접 (Placement)

agilesoda

Placement 면접 복기 ( Backend 인턴)

  • 지원 포지션: 강화학습팀 Backend 인턴
  • 면접관: 2명 (AI 파트 / Backend 파트)
  • 형태: 대면 면접, Q&A 중심

1) 1분 자기소개

  • 기존에 했던 면접을 기반으로 1분 자기소개는 거의 동일하게 진행.

2) 프로젝트 질문

2.1 SBOM 프로젝트 소개 / 통합 SBOM 프로젝트 설명

  • SBOM 생성/분석 경험 소개
  • “통합 SBOM” 관점에서 다음 포인트가 중요하게 보였음
    • 여러 생성기/도구 결과를 어떻게 정규화(normalization) 했는지
    • 누락/불일치가 발생하는 이유(메타데이터 기반 vs 코드 기반 등)를 어떻게 분석했는지
    • 결과 품질을 어떻게 검증했는지(커버리지/정합성 기준)

2.2 Django를 많이 썼는데 Spring Boot 경험이 있는가?

  • Spring Boot 경험 여부 확인 + 백엔드 실무 스택 적응력을 보는 질문
    • 해커톤에서의 경험 및 ‘김영한’님 강의를 수강하며 JPA 및 Spring 공부 중임을 밝힘

2.3 Django가 Spring Boot보다 더 나았던 점은?

  • “프레임워크 비교”라기보다 본인의 기술 선택 근거를 확인하는 질문으로 보임
    • 어드민 페이지를 제공해주며 admin.py를 통해 DB에 저장된 값을 시각적으로 볼 수 있다는 점이 매력적이었음. 코드 수정에 따른 자동적인 서버 재시작이 debug 및 초기 개발 속도에 박차를 가할 수 있었다는 답변을 하였음.

2.4 OCR 프로젝트를 했는데, 왜 비동기 파이프라인을 추가로 설계 중인가?

  • 면접 질문 의도: “왜 비동기여야 하는가?”를 설계 레벨로 설명 가능한지
  • 답변 포인트 예시:
    • OCR은 CPU/IO 비용이 크고 처리 시간이 들쭉날쭉 → 동기 처리 시 타임아웃/스레드 점유/UX 악화
    • 작업 큐 기반 비동기 처리로
      • 요청-처리 분리(빠른 응답)
      • 재시도/부분 실패 격리
      • 확장성(워커 수평 확장)
      • 파이프라인 단계별 모니터링/관측성 확보

3) 시스템 설계/운영 질문

3.1 Kafka 아키텍처에서 “DB는 정상인데 Consumer가 메시지를 처리 못 했을 때” 사후 처리?

  • 질문 의도: 부분 실패(partial failure) 상황에서 복구 전략과 운영 능력
  • 핵심 키워드
    • Retry(재시도): 즉시 재시도 + backoff
    • DLQ(Dead Letter Queue): 최종 실패 메시지 격리
    • Re-drive(재처리): 원인 해결 후 DLQ 재투입/리플레이
    • Idempotency(멱등성): 중복 처리 대비(eventId 기반 dedupe 등)
    • Offset commit 타이밍: 성공 후 commit(유실 최소화) + 멱등성으로 중복 대응
    • Poison pill: 특정 메시지가 계속 실패해 적체를 만드는 문제 → 검증 실패는 DLQ로 보내고 진행

결론: “DLQ + 재투입 절차 + 멱등 처리”까지 말하면 운영 관점 답변이 됨.

  • 내가한 답변: 특정 시간까지 확인 형태의 신호가 돌아오지 않는다면 다시 시동한다고 했음.

    3.2 무한정 Retry를 한다면 kafka가 “시끄러운 이웃(noisy neighbor)”이 될 수 있다. 이는 어떻게 하면 좋은가?

  • 질문 의도: 재시도는 하되, 재시도가 시스템 전체를 망치지 않게 통제할 수 있냐?

  • 내가한 답변: Kafka를 사용해보진 않았지만 운영체제의 Deadlock과 비슷한 상황이니 다음과 같은 방법을 사용할 것 같다는 말을 했음. 특정 임계치보다 높게 Kafka가 자원을 할당하거나 놓아주지 않는다면 이를 관제하는 다른 어플리케이션을 활용하여 Kafka를 일부 재시작하는 방법을 적용할 것 같다는 답변을 했음.

  • 핵심 키워드

    (A) 재시도는 Backoff + Jitter로 과열을 막는다

  • Exponential backoff: 1s → 2s → 4s → 8s…
  • Jitter(랜덤): 동일 시간에 재시도가 몰리는 thundering herd 방지
  • 핵심: “즉시 무한 재시도”를 하지 않겠다

(B) 재시도 횟수에 상한(cap)을 두고, 초과하면 DLQ로 격리

  • N번 실패하면 더 이상 메인 플로우를 괴롭히지 않도록 Dead Letter Queue로 이동
  • 이후 운영자가 원인 해결 후 re-drive(재투입)

(C) 격리(Isolation): “실패 트래픽”을 정상 트래픽과 분리한다

방법 예시:

  • Retry 전용 토픽/큐로 분리 (retry-5s, retry-1m 등)
    • 정상 토픽과 별개로 처리 → 메인 컨슈머가 재시도에 잡아먹히지 않음
  • 별도 Consumer group / 별도 워커 풀
    • 실패 처리 워커의 concurrency를 낮게 제한하여 폭주 방지
  • (가능하면) 별도 리소스/노드에 배치
    • k8s면 별도 deployment + resource limit/cpu/mem limit

3.3 예약 시스템: 1000명까지만 예약 가능, 이후 유저 reject는 어떻게?

  • 질문 의도: 동시성 제어 + 트래픽 상황에서 정확한 제한 보장
  • 대표적인 접근 방식
    • DB 레벨에서 강제 제한(정합성 최우선)
      • 예: capacity를 관리하고 트랜잭션/락/조건부 업데이트로 1000명 초과 방지
    • 원자적 카운팅(Redis 등)
      • INCR/Lua script로 원자적으로 카운트 증가 후 초과 시 즉시 거절
      • 다만 최종 정합성을 위해 DB와의 싱크 전략이 필요

3.3 대기열을 쓴다면 생길 수 있는 문제점은?

  • 질문 의도: “대기열”이 만능이 아니라는 점을 알고 있는지 + 전공지식 확인

대표 이슈들:

  • 공정성(Fairness): 먼저 들어온 사람이 먼저 처리되는가? 우선순위가 필요한가?
  • Backpressure / 적체: 처리량보다 유입량이 크면 큐가 무한정 쌓임 → 지연 폭증
  • 폭주 시 리소스 문제: 메모리 사용량, 큐 저장소(브로커/Redis) 병목
  • Timeout / 사용자 경험: 대기 시간이 길어지면 이탈률 증가, 재시도 폭탄 발생
  • 중복 요청/중복 처리: 사용자가 새로고침/재시도하면 큐에 중복 enqueue 가능
  • 순서 보장과 병렬성 트레이드오프
    • Partition/key 기반 순서 보장을 하면 병렬성이 제한됨
  • 장애 복구 시 재처리/중복 처리
    • at-least-once 특성으로 중복 가능 → 멱등 처리 필요

3.4 Kotlin 경험이 거의 없는데 어떻게 대처?

  • 질문 의도: 언어 적응력 + 학습 전략 + 리스크 관리 능력
  • 답변 포인트 예시:
    • Java 기반 경험이 있다면 JVM 생태계 공통점을 활용하겠다고 말하기
    • 코틀린 문법/코루틴/스프링 코틀린 관용구 등 우선순위 기반 학습 계획
    • 작은 기능부터 PR 단위로 안전하게 확장(리뷰 적극 활용)
    • 팀 코드 컨벤션 + 테스트 + 정적 분석 도구로 실수 줄이기

4) End-to-End 검증이 중요한 이유?

  • 답변 요약: B2B의 경우 고객이 기업인만큼 서비스 제공 업체의 솔루션이 클라이언트의 매출에 직접 영향을 줄 수 있음. 특히 AI 관련 솔루션을 제공하는 경우, Agent의 환각, 정확성, F1 Score과 같은 정량적인 지표도 매우 중요하다고 생각함. B2B는 신뢰성이 담보가 되어야 하는데, 이러한 신뢰성은 최종 단계에서의 최종 점검이 있어야 한다고 봄.
  • 위의 답변에 대한 추가 질문: Q) 고객사의 환경과 개발자의 내부 테스트 환경의 차이점이 있을 것 같은데 이를 어떻게 조정할 수 있는 지 설명

    • A) 고객사에서 요구하는 환경을 구현하기 위해 일부러 부하를 주어 테스트할 수 있음. 서버 환경의 특수성을 고려하여 유사한 서버 환경을 가상으로 구축하고 해당 환경에서 테스트를 진행할 수 있음.

      5) 추가 질문 (지원자가 질문)

5.1 Q) 바이브 코딩에 대한 생각 & 현업에서 AI 활용

  • 답변 요약
    • B2C에서는 바이브 코딩이 어느 정도 유효
    • 업계 시각으로는 B2C 기업은 3년 정도면 주니어 역할 대체 가능 관측
    • 다만 B2B는 사후관리/운영/책임 문제가 커서 더 오래 사람의 역할이 중요
    • AI 활용은 주로
      • 코드 리팩토링
      • 반복 작업을 줄이기 위한 MCP 개발(자동화 도구화)

5.2 Q) 3~4학년이 Kafka/RabbitMQ/Redis 같은 실무 기술을 공부하는 좋은 방법?

  • A 요약
    • 체험형 인턴(ICT, Placement 등)이 가장 효과적
    • 학교 지식(논문/이론)은 현업과 거리감이 존재
    • 학점과 병행 가능하면 적극 추천
    • 신기술은 해커톤/대회에서 오버엔지니어링 하며 부딪혀보는 방식 추천
    • 블로그도 좋지만, 서적을 직접 읽고 내부 원리를 뜯어보는 학습이 체화에 유리

6) 면접에서 느낀 포인트 / 다음 대비 메모

  • 질문들이 전반적으로 “운영 가능한 백엔드”를 보는 방향이었음
    • 장애/부분 실패/재처리/멱등성/DLQ 같은 키워드를 끌어낼 수 있어야 함
  • 기술 스택 질문(Django vs Spring, Kotlin)은
    • “우열”이 아니라 선택 근거 + 적응력을 보려는 성격이 강했음
  • 시스템 설계 질문(예약 1000명 제한, 대기열 문제점)은
    • 동시성/정합성/확장성/UX 트레이드오프를 명확히 설명하는 게 핵심

7) 다음 면접 대비 체크리스트

  • Kafka, Redis 및 네트워크 지식을 조금 더 공부해본다.

Categories:

Updated:

Leave a comment

You may also enjoy