이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
저는 이벤트 기반 아키텍처(EDA)를 선호합니다. 첫 번째 이유는 서비스 간 의존성을 낮출 수 있다는 점입니다. 팀 프로젝트에서 REST 동기 호출 방식으로 연결했을 때, 하나의 서비스가 느려지면 전체 응답이 지연되는 문제를 겪었습니다. 이후 Kafka를 이용한 비동기 방식으로 리팩토링했더니 개별 서비스의 배포 주기가 독립적으로 관리됐고, 장애 전파도 줄었습니다. 장점으로는 서비스 확장 시 기존 코드를 수정하지 않고 구독자만 추가하면 되는 유연성이 큰 이점이었습니다. 단점은 이벤트 순서 보장과 중복 처리 설계가 복잡해진다는 점인데, 이 부분은 idempotent consumer 패턴을 적용해 해결했습니다.
패턴 선택은 항상 서비스 규모와 팀 역량을 같이 고려해야 한다고 생각합니다.
어플리케이션 아키텍트로서 서비스 간 결합을 최소화하고 독립적인 확장이 중요한 시스템에서는 이벤트 드리븐 아키텍처(EDA)를 선호합니다. EDA에서는 서비스가 서로를 직접 호출하는 대신 이벤트를 발행하고 구독하는 방식으로 통신하기 때문에, 서비스 간 강결합 없이 새로운 기능을 이벤트 구독자로 추가하는 방식으로 확장이 가능합니다.
EDA 느슨한 결합 구조가 한 서비스의 장애나 변경이 다른 서비스에 영향을 주지 않는 방식이고, 이것이 대규모 시스템에서 안정성과 확장성을 동시에 확보하는 방법입니다. 주문 처리 시스템에서 주문 완료 이벤트를 발행하고 재고·결제·알림 서비스가 각각 구독하는 구조를 설계했을 때, 새로운 요구 사항이 생겨도 기존 코드를 수정하지 않고 구독자만 추가하면 됐습니다. 다만 이벤트 순서 보장과 중복 처리 방지가 추가 설계 과제이고, 이 부분을 함께 설계하는 것이 EDA의 핵심 난이도입니다.
시스템은 변한다고 가정하고 설계해야 하고, EDA는 그 변화에 가장 유연하게 대응합니다. EDA 기반 느슨한 결합과 독립 확장 설계가 복잡한 도메인에서 선호하는 방식입니다.
어플리케이션 아키텍처에서 장기적으로 선호하는 패턴은 헥사고날 아키텍처(Ports & Adapters)이고, 그 이유는 비즈니스 로직을 데이터베이스·프레임워크·외부 API 등 외부 의존성으로부터 격리할 수 있기 때문입니다. 핵심 도메인 로직이 인프라 구현에 의존하면, 데이터베이스 변경이나 외부 서비스 교체 시 비즈니스 코드 자체를 수정해야 하는 문제가 생기고, 헥사고날 아키텍처는 이 의존성 방향을 역전시켜 인프라가 도메인에 의존하도록 구조화합니다.
포트·어댑터 구조가 비즈니스 로직은 인터페이스(포트)를 통해서만 외부와 소통하고, 실제 구현(어댑터)은 언제든지 교체 가능한 방식이고, 이것이 테스트 용이성과 기술 스택 독립성을 동시에 확보하는 방법입니다. 레거시 ORM을 다른 DB 엔진으로 교체해야 했던 프로젝트에서, 헥사고날 구조로 설계된 서비스는 어댑터 교체만으로 핵심 비즈니스 로직 수정 없이 마이그레이션을 완료했고, 그렇지 않은 서비스는 도메인 코드 전반을 수정해야 했습니다.
구조가 올바르면 변경이 쉬워지고, 변경이 쉬워야 소프트웨어가 살아남습니다. 헥사고날 아키텍처로 비즈니스 로직 격리가 선호하는 아키텍처 패턴의 핵심 이유입니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 LG CNS 솔루션 아키텍트 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.