이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
Event-Driven 아키텍처의 가장 큰 장점은 서비스 간 결합도를 낮출 수 있다는 점입니다. 이벤트를 발행하는 쪽과 소비하는 쪽이 서로를 직접 알 필요가 없어서, 한 서비스를 교체하거나 확장해도 다른 서비스에 미치는 영향이 적습니다. Kafka 같은 메시지 브로커를 사이에 두면 트래픽 급증 시에도 소비 속도를 독립적으로 조절할 수 있어 확장성도 좋습니다. 단점은 이벤트 흐름을 추적하기 어렵다는 점입니다. 요청-응답 구조에서는 호출 스택을 따라가면 되는데, EDA에서는 어떤 이벤트가 어디서 소비됐는지 분산 트레이싱 없이는 파악하기 힘듭니다.
이벤트 순서 보장이 필요한 경우에는 추가 설계가 필요하다는 점도 주의해야 합니다.
팀 프로젝트에서 주문 처리 흐름을 EDA로 리팩토링한 경험이 있어요. 기존에는 여러 서비스를 순차 호출하다 보니 하나가 느려지면 전체가 느려졌는데, 이벤트 기반으로 바꾸고 나서 각 서비스가 독립적으로 처리할 수 있게 됐어요. 그런데 이벤트 스키마가 바뀔 때 소비 측 서비스를 한꺼번에 업데이트하지 못해서 일부 서비스가 잘못된 이벤트를 처리하는 문제가 생겼어요. 그 이후로 스키마 변경 시에는 하위 호환성을 유지하는 기간을 정해두는 원칙을 만들었습니다. EDA는 확장성 이점이 크지만, 이벤트 설계 규율이 없으면 운영 중 문제가 곳곳에서 터질 수 있어요.
EDA를 쓸 때는 이벤트 설계 규율이 코드 품질만큼 중요하다는 걸, 그 경험에서 배웠습니다.
EDA의 장점은 비동기 처리로 응답 지연을 줄이고, 서비스 간 독립성을 높이는 것이에요. 결제 완료 후 알림 발송처럼 즉각적인 응답이 필요 없는 흐름에서 특히 효과적이에요. 반면 이벤트가 처리됐는지 즉시 알기 어렵기 때문에, 트랜잭션 일관성이 중요한 경우엔 EDA만으로 설계하기 어려워요.
중복 이벤트 처리나 멱등성 설계를 미리 고려하지 않으면 같은 이벤트가 두 번 처리되는 문제도 생겨요. EDA가 만능이 아니라 적합한 흐름을 골라 쓰는 것이 핵심이라고 생각해요. EDA가 적합한 흐름과 그렇지 않은 흐름을 구분하는 것이 아키텍처 결정의 핵심이라고 생각해요. EDA를 선택할 때는 운영 복잡도까지 함께 고려해야 한다는 걸 배웠어요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 당근마켓 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.