이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
이벤트 주도 아키텍처의 가장 큰 장점은 컴포넌트 간 의존성이 낮아진다는 점입니다. 서비스 A가 이벤트를 발행하면 B, C, D가 각자 구독하여 처리하기 때문에, A는 B~D의 존재를 몰라도 됩니다. 이 느슨한 결합 덕분에 새로운 서비스를 추가하거나 기존 서비스를 변경할 때 영향 범위가 줄어듭니다. 반면 단점은 전체 흐름을 추적하기 어렵다는 것입니다. 요청이 어느 서비스에서 처리되었고 어디서 실패했는지 파악하려면 별도의 트레이싱 도구가 없으면 힘듭니다. 팀 프로젝트에서 이벤트 방식을 사용해 보았을 때 오류 발생 시 원인을 찾는 데 로그를 여러 곳에서 뒤져야 했던 경험이 있습니다. 장점이 크지만 운영 복잡도도 함께 올라간다는 것을 직접 느꼈습니다.
이벤트 주도 아키텍처를 쓰면 요청 처리를 비동기로 분산할 수 있어서 응답 속도를 개선하는 데 유리합니다. 사용자 요청을 받은 뒤 바로 응답하고, 실제 처리는 백그라운드에서 이벤트로 진행하는 방식이 대표적이에요. 처리가 느린 작업이 전체 응답 흐름을 막지 않는다는 게 큰 강점입니다. 단점은 이벤트 중복이나 순서 보장이 어렵다는 것이에요. 네트워크 문제로 이벤트가 두 번 전달될 수 있고, 순서가 뒤바뀌면 데이터 상태가 예상과 달라질 수 있습니다. 이를 해결하려면 idempotency 처리나 이벤트 순서 추적 로직이 추가로 필요해요.
편의성이 올라가는 만큼 설계 복잡도도 올라가는 구조라는 걸 공부하면서 알게 됐습니다. 문제를 알고 쓰는 것과 모르고 쓰는 것은 다르더라고요.
이벤트 주도 방식의 장점 중 하나는 특정 서비스가 일시적으로 다운돼도 이벤트가 큐에 쌓여 있다가 복구 후 처리되기 때문에 시스템 전체가 멈추지 않는다는 점이에요. 단일 장애 지점이 전체 장애로 이어지는 걸 막아주는 구조입니다. 반면 이벤트 큐 자체가 다운되거나 용량이 초과되면 이벤트가 유실될 수 있다는 위험이 있어요.
큐 모니터링과 백프레셔 처리가 제대로 안 되어 있으면, 트래픽이 몰릴 때 메시지가 사라지는 상황이 생길 수 있습니다. 개인 프로젝트에서 이 방식을 써보다가 큐 길이를 관리하지 않아서 메모리가 넘친 경험이 있어요. 장점을 누리려면 큐 인프라를 제대로 설계해야 한다는 걸 그때 배웠습니다. 아키텍처의 강점은 운영이 뒷받침될 때 발휘돼요.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 쿠팡 백엔드 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.