[면접] 프로젝트 면접 (1~4)

1. JWT(토큰) 기반의 인증 방식에 대한 설명과 함께 JWT의 보안 취약점과 해결 방법에 대해 설명해주세요.

  "JWT(JSON Web Token) 인증 방식은 디지털 서명이 된, URL에 친화적인 토큰을 사용하여 서버와 클라이언트 사이에 안전하게 정보를 교환합니다. 이는 상태를 유지하지 않는 RESTful API에 이상적으로, 인증 정보를 클라이언트 측에 저장합니다. 그러나 토큰 탈취 시 정보 노출 위험이 있어, 이를 방지하기 위해서는 HTTPS로 통신을 암호화하고, 토큰의 만료 시간을 짧게 설정하며, 접근 토큰과 갱신 토큰의 사용을 분리하는 등의 보안 조치가 필요합니다."

 

꼬리 질문 > JWT 토큰 방식을 선택한 이유는 무엇이며 JWT 토큰의 동작 방식에 대해 설명해 주세요.

  "JWT(JSON Web Token) 방식은 상태를 저장하지 않는 인증 메커니즘으로, 이는 서버가 사용자 세션을 유지할 필요 없이 클라이언트가 각 요청과 함께 토큰을 전송함으로써 사용자 인증을 수행할 수 있게 합니다. JWT는 헤더, 페이로드, 서명의 세 부분으로 구성되며, 각 부분은 사용자 인증 정보의 안전한 전송을 보장합니다. 헤더는 토큰의 타입과 사용된 해싱 알고리즘을 명시하고, 페이로드는 사용자의 식별 정보와 메타데이터를 담으며, 서명은 토큰의 무결성과 인증을 확인합니다. 이 방식은 효율적인 인증 처리를 가능하게 하며, RESTful API와 같이 상태를 유지하지 않는 서비스에 적합합니다."

 

꼬리 질문 >  JWT 토큰의 보안 취약점을 어떻게 해결 하셨나요?

  "JWT 토큰의 보안 취약점을 해결하기 위해, 토큰의 만료 시간을 짧게 설정하여 토큰의 노출 위험을 최소화하였습니다. 또한, Redis를 사용하여 발급된 토큰을 관리하였습니다. 사용자의 상태를 Redis에 저장하고, 요청이 들어올 때마다 Redis에 저장된 상태 정보를 참조하여 토큰의 유효성을 검증함으로써, 토큰이 만료되거나 무효화되었을 경우 즉시 접근을 차단할 수 있습니다. 이 두 가지 조치를 통해 JWT 토큰의 보안성을 크게 향상시켰습니다."

 

2. 모놀리스 구조와 MSA 구조의 차이점에 대해 설명해주세요.

  "모놀리식 아키텍처에서는 애플리케이션의 모든 기능이 하나의 큰 코드 베이스에 통합되어 있어, 초기 개발 및 배포가 간단합니다. 그러나 애플리케이션이 성장함에 따라 복잡성이 증가하며 유지보수와 확장이 어려워질 수 있습니다. 반대로, MSA는 애플리케이션을 여러 독립적인 서비스로 분할하여 각각을 별도로 개발하고 배포합니다. 각 서비스는 특정 비즈니스 기능을 수행하며, 이는 애플리케이션의 확장성과 유연성을 높이지만 서비스 간 통신과 데이터 관리가 더 복잡해질 수 있습니다."

 

꼬리 질문 > MSA에 대해서 알고 계신 만큼 설명해주세요

  "MSA(Microservices Architecture)는 애플리케이션을 작고 독립적으로 운영 가능한 여러 서비스로 나누어 관리하는 구조입니다. 이 구조는 각 서비스가 특정 비즈니스 기능에 초점을 맞추게 함으로써 애플리케이션의 확장성과 유연성을 증가시키고, 복잡성을 효과적으로 관리할 수 있게 합니다. MSA를 채택함으로써, 각 마이크로서비스는 독립적인 개발 및 배포가 가능하고, 서로 다른 프로그래밍 언어 및 데이터 스토리지 솔루션을 활용할 수 있습니다, 이는 기업이 시장 변화에 빠르게 대응하고 서비스를 지속적으로 개선하는 데 기여합니다."

 

꼬리질문 > 프로젝트를 MSA로 전환하는 과정에서 겪어보신 트러블슈팅을 설명해주세요.

  "MSA 전환 과정 중 겪었던 한 가지 트러블슈팅 경험은 REST API 응답에서 발생한 예상치 못한 Null 값 문제였습니다. 이 문제의 근본 원인은 서로 다른 서비스 간의 응답 구조 차이였으며, 특히 필요한 데이터가 ApiResponse 객체의 data 필드 내에 일관되지 않게 포함되어 있는 경우가 많았습니다. 이를 해결하기 위해 모든 서비스에 공통으로 사용될 ApiResponse 클래스를 도입해 응답 형태를 표준화하였고, 이를 통해 클라이언트가 필요한 데이터에 일관되게 접근할 수 있도록 로직을 개선했습니다. 이 조치는 데이터의 일관성을 강화하고 향후 비슷한 문제를 방지하는 데 중요한 역할을 했습니다."

 

꼬리 질문 > 어떤 점에서 MSA가 해당 프로젝트에 적합하다고 생각 하셨나요?

  "해당 예약구매 프로젝트에서 MSA를 선택한 결정적 이유는 프로젝트의 다양한 기능적 요구사항과 확장성 때문이었습니다. 구매 기능과 뉴스피드 기능은 서로 다른 비즈니스 로직을 가지고 있으며, 각각의 기능이 독립적으로 발전하고, 필요에 따라 별도로 확장될 가능성이 큽니다. MSA 구조를 채택함으로써, 각 서비스를 독립적으로 개발, 배포 및 확장할 수 있게 되어, 빠르게 변화하는 사용자 요구사항에 유연하게 대응할 수 있게 되었습니다. 또한, 이러한 분리는 작업 효율성을 높이고, 각 기능에 최적화된 기술 스택을 선택할 수 있는 기회를 제공했습니다."

 

꼬리 질문 > 서비스를 나눈 기준은 무엇 이며 분할 시 발생한 문제와 해결 방법에 대해 설명해 주세요.

  "서비스 분할 기준은 각 기능의 비즈니스 로직 복잡성과 서비스 간 의존도를 최소화하는 것이었습니다. 구체적으로, 구매 기능과 뉴스피드 기능을 별도의 서비스로 분리하여 각각의 개발 및 확장을 독립적으로 관리할 수 있게 했습니다. 분할 과정에서 서비스 간 통신 지연과 처리량 문제가 발생했고, 이를 해결하기 위해 비동기 및 논블로킹 I/O 모델을 지원하는 Webflux를 도입했습니다. Webflux의 적용으로 각 서비스의 통신 효율과 처리 성능이 크게 개선되었으며, 이는 전체 시스템의 응답성과 확장성 향상으로 이어졌습니다."

 

3. 캐시 (읽기, 쓰기)전략에 대해 아는 만큼 설명해주세요.

  "캐싱 전략은 데이터를 빠르게 접근하기 위해 사용되며, 주로 읽기 전략과 쓰기 전략으로 구분됩니다. 읽기 캐시 전략에서는 자주 접근하는 데이터를 메모리에 저장하여 데이터베이스 접근을 줄이고, 응답 속도를 향상시킵니다. 쓰기 캐시 전략에서는 쓰기 연산을 최적화하기 위해 데이터를 일시적으로 캐시에 저장한 후, 배치 처리나 지연 쓰기(log) 방식을 통해 데이터베이스에 반영합니다. 이러한 캐싱 전략은 애플리케이션의 성능을 크게 향상시킬 수 있지만, 일관성과 최신성을 유지하기 위한 추가적인 메커니즘 구현이 필요합니다."

 

꼬리 질문 > 캐싱을 어떤 식으로 활용하셨나요?

  "프로젝트에서 실시간 재고 관리 기능의 성능을 향상시키기 위해 캐싱을 활용했습니다. 자주 조회되지만 변동이 비교적 적은 재고 데이터를 메모리 기반 캐시에 저장함으로써, 데이터베이스에 대한 불필요한 접근을 줄이고 응답 시간을 단축시켰습니다. 또한, 재고 변동 시 캐시를 즉시 업데이트하여 데이터 일관성을 유지하고, 사용자에게 실시간 재고 정보를 정확히 제공할 수 있도록 했습니다. 이러한 캐싱 전략은 시스템의 전반적인 부하를 감소시키고, 사용자 경험을 크게 개선했습니다."

 

꼬리 질문 > 본인 프로젝트에 적용된 캐시에 대해서 설명해주세요

  "제 프로젝트에서는 실시간 재고 관리 시스템을 효율적으로 운영하기 위해 캐싱 기술을 적극 활용했습니다. 주요 상품의 재고 상태를 빠르게 액세스할 수 있도록 Redis와 같은 인메모리 데이터 스토어에 캐시해 두었습니다. 이를 통해, 고객이 상품 정보를 요청할 때마다 데이터베이스를 직접 조회하는 대신, 미리 캐시된 데이터를 제공함으로써 응답 속도를 대폭 개선하고 데이터베이스의 부하를 줄일 수 있었습니다. 재고가 변경될 때마다 캐시도 동시에 업데이트되어, 실시간으로 정확한 재고 정보를 유지할 수 있었습니다."

 

4. 스케일 업과 스케일 아웃에 대해 아는 만큼 설명해주세요.

  "스케일 업은 시스템의 처리 능력을 향상시키기 위해 서버의 CPU, 메모리 같은 하드웨어 자원을 물리적으로 증가시키는 방식입니다. 반면, 스케일 아웃은 추가 서버를 도입하여 네트워크를 통해 여러 서버가 협력하는 방식으로 시스템의 처리 능력을 확장합니다. 스케일 업은 구현이 비교적 간단하지만 비용이 많이 들고 확장에 한계가 있으며, 스케일 아웃은 확장성이 높고 비용 효율적이지만, 부하 분산, 데이터 일관성 관리 등의 복잡한 관리가 필요합니다."

 

꼬리 질문 > 스케일아웃이 필요한 상황에 어떻게 대응하셨는지 직접적으로 설명해주세요

  "프로젝트에서 대규모 주문 처리를 위해 스케일아웃이 필요한 상황에 직면했을 때, Redis를 활용하여 대응했습니다. Redis를 세션 관리 및 캐싱 레이어로 통합하여, 서버 간 세션 공유 및 주문 데이터 처리 속도를 향상시켰습니다. 이를 통해, 단일 서버에 대한 부하를 분산시키고, 여러 서버에서 주문을 동시에 처리할 수 있는 환경을 구축했습니다. 결과적으로, 시스템의 처리 용량과 가용성이 크게 향상되었으며, 사용자에게 빠르고 안정적인 서비스 제공이 가능해졌습니다."