현재 배포 아키텍처에서 Kafka 테스트 배치 및 구성 방향 질문드립니다.

안녕하세요 강사님! 강의 잘 듣고 있습니다.

현재 개인 프로젝트(IdolGlow)를 EKS 기반(Spring Boot + RDS PostgreSQL)으로 AWS에 배포 완료한 상태에서, 대용량 부하 테스트 및 장애 복구 경험을 포트폴리오에 깊이 있게 녹여내고자 고민 중입니다.

실무 및 기술 검증 관점에서 Kafka를 어디에 어떻게 배치하여 테스트하는 것이 맞는지 2가지 방향을 고민해 보았는데, 강사님의 조언을 얻고 싶어 질문드립니다.

[현재 저의 아키텍처 구조]

• EKS (Worker Node 2개) + Spring Boot (Kotlin)

• 
  

• Amazon RDS PostgreSQL

• 
  

• ALB -> Ingress -> Service -> Pod

• 
  

[고민 중인 2가지 방향]

1. 아키텍처 내부에 Kafka를 직접 추가하여 검증하는 방식

• EKS 내부(Pod) 또는 Amazon MSK로 Kafka를 추가하고, 결제 승인 웹훅이나 대량 데이터 수집 로직을 비동기 이벤트 기반으로 변경합니다.

• 
  

• 목적: k6 부하 테스트 시 Consumer Lag 지연 측정, EKS Pod 강제 종료 시 메시지 재처리 및 멱등성(중복 방지)을 실제로 아키텍처상에서 검증하고 포트폴리오에 데이터로 남기는 목적입니다.

• 
  

2. 아키텍처 외부에 별도 격리 환경으로 테스트 후 결과만 포트폴리오에 녹이는 방식

• 메인 배포 아키텍처는 현재 구조(Spring Boot + RDS)로 깔끔하게 유지하고, Kafka 관련 부하/장애 테스트는 로컬 Docker Compose나 별도 테스트 전용 EC2 인스턴스에서 독립적으로 진행한 뒤 "비동기 메세징 검증 경험"으로 정리합니다.

• 
  

[질문 내용]

1. 면접관 입장에서 "실제 포트폴리오의 완성도와 깊이"를 보여주려면, 현재 EKS 메인 아키텍처에 Kafka를 직접 편입시켜 비동기 파이프라인 전체를 부하 테스트한 지표를 보여주는 것이 훨씬 설득력이 있을까요?

2. 
   

3. 아니면 서비스의 복잡도보다 "결제/예약 시 정합성과 장애 상황(Consumer 중단, 메시지 중복)을 데이터로 검증했는가" 자체가 더 핵심이므로, 별도 환경에서 테스트한 기록만 남겨도 충분한 가치가 있을까요?

4. 
   

강의 범위 외의 포트폴리오 전략 관련 질문이지만, 현업에서의 실무적 관점이 궁금하여 여쭤봅니다. 바쁘시겠지만 방향성에 대해 조언해 주시면 정말 큰 도움이 될 것 같습니다. 감사합니다!