이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
사이드 프로젝트에서 Spring Boot로 사용자 서비스와 알림 서비스를 분리하는 마이크로서비스 구조를 처음 만들었습니다. 서비스 간 통신에서 동기 REST와 비동기 이벤트를 구분하는 기준을 잡는 게 가장 어려웠습니다. 알림처럼 즉각적인 응답이 불필요한 작업은 Kafka 토픽으로 분리했고, 주문 생성처럼 결과를 즉시 써야 하는 흐름은 REST로 유지했습니다. 분산 환경에서 트랜잭션 일관성이 어렵다는 걸 처음 실감한 건 서비스 한 쪽이 실패했을 때 롤백 범위를 정하지 않아 데이터가 일부만 반영된 경우였습니다.
각 서비스를 독립 배포하는 구조가 편의성과 복잡도를 동시에 가져온다는 걸 직접 다뤄보며 배웠습니다.
Spring Boot 마이크로서비스에서 서비스 간에 걸쳐있는 작업 중 일부 서비스가 실패했을 때 데이터 일관성을 어떻게 유지할지를 고민한 경험이 있습니다. 분산 환경에서 전통적인 트랜잭션이 여러 서비스에 걸쳐 동작하지 않기 때문에, 이미 성공한 서비스의 작업을 되돌리는 보상 트랜잭션 방식을 공부하면서 구현에 적용해봤습니다. 주문 생성이 성공했는데 결제 서비스가 실패했을 때 주문을 취소하는 흐름을 명시적으로 설계하는 방식이었습니다. 구현하면서 보상 로직 자체가 실패하는 경우도 처리해야 한다는 것을 알게 됐는데, 각 단계의 성공 여부를 기록해두고 보상이 필요한 단계를 재시도하는 구조가 필요했습니다. 마이크로서비스에서 데이터 일관성은 코드로 해결하는 것이 아니라 각 서비스의 경계와 보상 책임을 설계 단계에서 명확히 하는 것에서 시작한다는 것을 이 경험에서 배웠습니다.
Spring Boot 마이크로서비스를 운영하면서 서비스 간 API 계약이 변경됐을 때 제대로 조율하지 않아서 생긴 장애를 경험했습니다. 한 서비스에서 응답 구조를 변경했는데, 이를 소비하는 다른 서비스가 그 변경을 모르는 상태에서 배포가 진행됐습니다. 두 서비스가 각각 독립적으로 배포될 수 있다는 것이 마이크로서비스의 장점인데, 그 독립성이 서비스 간 계약 변경을 놓치게 만드는 원인이 됐습니다. 이후에는 서비스 간 API 변경 시 소비 서비스의 배포 타이밍을 조율하거나, 이전 버전을 유지하면서 단계적으로 전환하는 방식을 적용했습니다. 마이크로서비스의 독립 배포는 서비스 간 계약을 명시적으로 관리하는 비용을 만들고, 그 비용을 인식하지 못하면 독립성이 오히려 장애의 원인이 된다는 것을 이 경험에서 배웠습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 유진그룹 SW·IT 일반 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.