Java 리드/아키텍트 보안 면접

Java 리드 · 아키텍트 (10년+) 보안 5문항 조회수 33 · 2026-08-04 (화) 14:51:11
1 인증/인가 아키텍처
Hard

Q. 마이크로서비스 아키텍처로 전환하는 대규모 레거시 시스템에서 기존 세션 기반 인증을 JWT 기반으로 전환하려고 합니다. 전환 과정에서 발생할 수 있는 보안 리스크와 이를 최소화하기 위한 마이그레이션 전략을 설계해주세요. 특히 동시 운영 기간 동안의 보안 고려사항을 중심으로 설명해주세요.

두 인증 방식이 공존하는 기간 동안의 세션 하이재킹, 토큰 탈취, 권한 불일치 문제를 고려해보세요.

A. 모범답안

먼저 Strangler Fig 패턴을 적용하여 단계적 전환을 수행합니다. 초기에는 API Gateway에서 세션과 JWT를 모두 검증하는 하이브리드 인증 레이어를 구축하고, 세션에서 JWT로 변환하는 토큰 브리지를 구현합니다. JWT는 짧은 만료시간(15분)의 Access Token과 Refresh Token 구조로 설계하며, Redis를 활용한 토큰 블랙리스트를 구축하여 즉시 무효화가 가능하도록 합니다. 전환 기간 동안 모든 인증 이벤트를 로깅하고 이상 패턴을 모니터링하며, 권한 불일치 발생 시 더 제한적인 권한을 적용하는 Fail-Safe 정책을 적용합니다. 마지막으로 카나리 배포를 통해 소수 사용자부터 점진적으로 JWT로 전환하고, 롤백 시나리오를 명확히 정의하여 리스크를 최소화합니다.

핵심 포인트
  • • 하이브리드 인증 레이어 구축과 단계적 전환 전략
  • • 토큰 블랙리스트와 즉시 무효화 메커니즘
  • • 전환 기간 중 보안 모니터링과 Fail-Safe 정책
  • • 카나리 배포와 명확한 롤백 시나리오
답변에 넣으면 좋은 키워드
JWT Strangler Fig 패턴 토큰 블랙리스트 Refresh Token API Gateway 카나리 배포
실무에서는

모놀리식 시스템을 MSA로 전환하면서 인증 체계를 현대화할 때 무중단으로 안전하게 마이그레이션하는 상황

Follow-up 질문

JWT의 Signature 알고리즘으로 HS256과 RS256 중 어떤 것을 선택하시겠습니까? 마이크로서비스 환경에서의 선택 기준은 무엇인가요?

2 웹 취약점 방어
Hard

Q. 회사의 주요 서비스에서 XSS, CSRF, SQL Injection 방어를 위한 다층 방어 전략을 수립하려고 합니다. 각 취약점에 대해 애플리케이션 레벨, 프레임워크 레벨, 인프라 레벨에서 적용할 수 있는 방어 기법을 설명하고, 특히 Spring Framework 환경에서 조직 차원의 보안 가이드라인을 어떻게 구축하시겠습니까?

개발자 실수를 방지하는 자동화된 보안 메커니즘과 코드 리뷰 체크리스트를 고려해보세요.

A. 모범답안

XSS 방어는 Spring Security의 Content Security Policy 헤더 설정, OWASP Java Encoder를 사용한 출력 인코딩, React나 Vue 같은 프레임워크의 자동 이스케이핑 활용으로 구성합니다. CSRF는 Spring Security의 CsrfToken 자동 검증, SameSite Cookie 속성 설정, Stateless API는 커스텀 헤더 검증으로 방어합니다. SQL Injection은 JPA/MyBatis의 PreparedStatement 강제, QueryDSL 같은 타입 세이프 쿼리 빌더 사용, 데이터베이스 권한 최소화로 대응합니다. 조직 차원에서는 SonarQube에 OWASP 룰셋을 적용하여 CI/CD에서 자동 검사하고, ArchUnit으로 아키텍처 규칙을 테스트하며, 보안 챔피언 제도를 운영하여 각 팀에 보안 전문가를 배치합니다. 또한 SAST/DAST 도구를 파이프라인에 통합하고, 정기적인 모의 해킹과 버그 바운티 프로그램을 운영합니다.

핵심 포인트
  • • 다층 방어 전략과 프레임워크 자동 보안 기능 활용
  • • 타입 세이프 쿼리와 PreparedStatement 강제
  • • CI/CD 파이프라인에 통합된 자동화된 보안 검사
  • • 보안 챔피언과 조직 문화 구축
답변에 넣으면 좋은 키워드
Content Security Policy OWASP PreparedStatement SonarQube SAST DAST SameSite Cookie
실무에서는

전사 보안 정책을 수립하고 수백 명의 개발자가 일관된 보안 기준을 따르도록 시스템을 구축하는 상황

Follow-up 질문

최근 주목받는 Server-Side Request Forgery(SSRF) 공격에 대해서는 어떤 방어 전략을 수립하시겠습니까?

3 암호화 및 키 관리
Hard

Q. 금융 서비스에서 민감한 개인정보를 암호화하여 저장해야 합니다. 암호화 알고리즘 선택, 키 관리 전략, 키 로테이션 정책을 포함한 전체 암호화 아키텍처를 설계해주세요. 특히 개발/스테이징/프로덕션 환경별 키 관리와 규정 준수(ISMS-P, PCI-DSS) 관점에서 설명해주세요.

암호화 키 자체를 어떻게 안전하게 보관하고 관리할지, 그리고 키 유출 시 대응 방안을 생각해보세요.

A. 모범답안

데이터 암호화는 AES-256-GCM을 사용하며, Envelope Encryption 패턴으로 DEK(Data Encryption Key)로 데이터를 암호화하고 KEK(Key Encryption Key)로 DEK를 암호화합니다. 키 관리는 AWS KMS, HashiCorp Vault, Azure Key Vault 같은 전용 HSM 기반 서비스를 사용하고, 환경별로 완전히 분리된 키를 운영합니다. 애플리케이션은 IAM Role 기반으로 키에 접근하며, 키 자체는 코드나 설정 파일에 절대 포함하지 않습니다. 키 로테이션은 자동화하여 최소 연 1회 수행하고, 로테이션 시 기존 키는 즉시 폐기하지 않고 복호화 전용으로 유지하며 점진적으로 재암호화합니다. 모든 키 접근은 감사 로그로 기록하고, 이상 접근 패턴을 실시간 모니터링합니다. 규정 준수를 위해 암호화 범위 문서화, 키 생명주기 정책 수립, 정기적인 암호화 강도 검토를 수행합니다.

핵심 포인트
  • • Envelope Encryption 패턴과 HSM 기반 키 관리
  • • 환경 분리와 IAM 기반 접근 제어
  • • 자동화된 키 로테이션과 점진적 재암호화
  • • 감사 로그와 규정 준수 문서화
답변에 넣으면 좋은 키워드
AES-256-GCM Envelope Encryption HSM KMS Vault 키 로테이션 ISMS-P
실무에서는

금융권이나 의료 서비스에서 법적 요구사항을 충족하면서 대용량 민감 데이터를 안전하게 암호화하는 상황

Follow-up 질문

데이터베이스 컬럼 레벨 암호화와 TDE(Transparent Data Encryption) 중 어떤 방식을 선택하시겠습니까? 각각의 장단점과 사용 시나리오는 무엇인가요?

4 인가 및 접근 제어
Hard

Q. 복잡한 권한 체계를 가진 B2B SaaS 플랫폼을 설계 중입니다. 조직 계층 구조, 역할 기반 권한, 리소스별 세밀한 권한 제어가 모두 필요한 상황에서, RBAC과 ABAC을 결합한 하이브리드 접근 제어 모델을 어떻게 설계하시겠습니까? 성능과 확장성, 감사 추적 관점에서 설명해주세요.

권한 평가가 매 요청마다 발생하므로 성능과 일관성을 동시에 고려해야 합니다.

A. 모범답안

기본 구조는 RBAC으로 역할별 기본 권한을 정의하고, ABAC으로 컨텍스트 기반 세밀한 제어를 추가합니다. 권한 모델은 조직(Organization), 워크스페이스(Workspace), 리소스(Resource) 3단계 계층으로 설계하고, 각 레벨에서 역할을 상속받되 하위 레벨에서 제한할 수 있도록 합니다. 권한 평가 엔진은 Policy Decision Point를 별도 서비스로 분리하고, 평가 결과를 Redis에 TTL 기반으로 캐싱하여 성능을 확보합니다. 정책은 OPA(Open Policy Agent)나 Cedar 같은 정책 엔진을 활용하여 선언적으로 정의하고, 정책 변경 시 캐시를 즉시 무효화합니다. 모든 권한 체크는 AOP로 중앙화하여 일관성을 보장하고, 권한 평가 결과와 의사결정 근거를 상세히 로깅하여 감사 추적을 가능하게 합니다. 대용량 데이터 접근 시에는 데이터베이스 레벨의 Row-Level Security도 함께 적용하여 다층 방어를 구현합니다.

핵심 포인트
  • • RBAC과 ABAC의 하이브리드 모델과 계층적 권한 구조
  • • Policy Decision Point 분리와 캐싱 전략
  • • OPA 같은 정책 엔진 활용과 선언적 정책 정의
  • • AOP 기반 중앙화와 상세한 감사 로깅
답변에 넣으면 좋은 키워드
RBAC ABAC Policy Decision Point OPA Row-Level Security AOP 권한 캐싱
실무에서는

Slack이나 Notion 같은 협업 도구에서 조직, 워크스페이스, 문서별로 복잡한 권한을 관리하는 상황

Follow-up 질문

멀티 테넌시 환경에서 테넌트 간 데이터 격리를 보장하기 위한 아키텍처 패턴은 무엇이 있으며, 각각의 트레이드오프는 무엇인가요?

5 개인정보 보호 및 규정 준수
Hard

Q. 글로벌 서비스를 운영하면서 GDPR, CCPA, 국내 개인정보보호법을 모두 준수해야 합니다. 개인정보의 수집, 저장, 처리, 삭제 전 생명주기를 관리하는 기술 아키텍처를 설계하고, 특히 '잊혀질 권리' 구현과 데이터 최소화 원칙을 어떻게 시스템에 반영하시겠습니까? 레거시 시스템이 존재하는 상황을 가정하고 설명해주세요.

개인정보가 여러 시스템과 백업에 분산되어 있을 때 완전한 삭제를 보장하는 메커니즘을 고려해보세요.

A. 모범답안

먼저 Data Inventory를 구축하여 모든 시스템의 개인정보 저장 위치를 매핑하고, 데이터 분류 체계(민감도, 보유기간)를 정의합니다. 개인정보는 중앙 Identity Service에서 관리하고, 다른 서비스는 가명화된 UUID만 참조하도록 아키텍처를 재설계합니다. 잊혀질 권리 구현은 삭제 요청을 이벤트로 발행하고, 모든 시스템이 구독하여 처리하는 이벤트 드리븐 방식을 적용하며, Saga 패턴으로 분산 트랜잭션을 관리합니다. 백업 데이터는 암호화 키를 폐기하는 Crypto-Shredding 기법으로 복호화 불가능하게 만들고, 백업 보관 정책에 따라 물리적 삭제 시점을 명확히 합니다. 데이터 최소화는 수집 시점에 목적과 보유기간을 명시하고, TTL 기반 자동 삭제를 구현하며, 불필요한 로그의 개인정보는 마스킹 처리합니다. 레거시 시스템은 Change Data Capture로 데이터 동기화하고, Anti-Corruption Layer로 점진적으로 개선합니다.

핵심 포인트
  • • Data Inventory와 중앙화된 Identity Service
  • • 이벤트 드리븐 삭제와 Saga 패턴
  • • Crypto-Shredding과 백업 데이터 처리
  • • TTL 기반 자동 삭제와 레거시 통합 전략
답변에 넣으면 좋은 키워드
GDPR 잊혀질 권리 Data Inventory Crypto-Shredding Saga 패턴 CDC 데이터 최소화
실무에서는

유럽과 미국, 한국에서 동시에 서비스하는 글로벌 플랫폼에서 각국의 개인정보 보호 법규를 모두 만족시켜야 하는 상황

Follow-up 질문

개인정보 유출 사고 발생 시 72시간 내 신고 의무를 준수하기 위한 모니터링 및 대응 체계는 어떻게 구축하시겠습니까?

댓글 0

로그인 후 댓글을 작성할 수 있습니다.

아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!