Laravel 리드·아키텍트 기술면접

데이터베이스 암호화는 디스크 탈취 시 보호를 위해 MySQL TDE나 파일시스템 암호화를 사용하고, 전송 구간은 TLS 1.3로 MITM 공격을 방지합니다. 애플리케이션 레벨에서는 Laravel Encrypter로 민감 필드를 암호화하되, 카드번호 같은 결제정보는 PCI-DSS 요구사항에 따라 별도 토큰화 서비스로 분리하여 애플리케이션에서는 토큰만 저장합니다. 암호화 키는 환경변수가 아닌 AWS KMS나 HashiCorp Vault 같은 외부 키 관리 시스템에서 관리하고, Laravel에서는 키를 메모리에만 보관하며 로그에 노출되지 않도록 합니다. 검색이 필요한 이메일이나 전화번호는 HMAC 기반 해시를 별도 컬럼에 저장하거나 FPE를 사용해 암호화하면서도 형식을 유지합니다. 성능 저하는 암호화 대상을 최소화하고, 배치 암호화 시 Queue를 활용하며, 읽기가 빈번한 데이터는 Redis에 복호화된 상태로 TTL 기반 캐싱하되 메모리 덤프 방지를 위해 encrypted Redis를 사용합니다.

API 계약 관리는 OpenAPI 스펙을 각 서비스 레포지토리에서 관리하고, Consumer-Driven Contract Testing(Pact)을 CI 파이프라인에 통합하여 소비자 서비스가 기대하는 계약을 프로바이더가 위반하지 않는지 자동 검증합니다. API 버저닝은 URI 버저닝(/v1, /v2)을 기본으로 하되, 마이너 변경은 하위 호환성을 유지하고 메이저 변경 시에만 새 버전을 생성하며, API Gateway에서 구버전을 최소 6개월 유지하는 deprecation 정책을 수립합니다. 배포는 각 서비스가 독립적으로 Blue-Green 배포를 수행하되, 위험도가 높은 변경은 Canary 배포로 5%-25%-100% 단계적 트래픽 전환을 하고, Laravel의 Feature Flag(Pennant)로 새 기능을 프로덕션에 배포하되 비활성화 상태로 유지했다가 점진적으로 활성화합니다. 서비스 메쉬(Istio, Linkerd)나 API Gateway(Kong, AWS API Gateway)에서 트래픽 라우팅, 서킷 브레이커, 재시도 정책을 중앙 관리하여 한 서비스 장애가 전파되지 않도록 격리합니다. 조직적으로는 각 팀이 서비스 소유권을 갖되, 플랫폼 팀이 공통 배포 파이프라인, 모니터링, 계약 테스트 인프라를 제공하고, 주간 아키텍처 리뷰에서 서비스 간 의존성 변경을 사전 검토합니다.

샤딩 키는 쿼리 패턴 분석 결과 user_id를 기준으로 선택하되, 일관된 해싱(Consistent Hashing)을 적용하여 샤드 추가 시 데이터 재분배를 최소화합니다. Hash-based 샤딩을 기본으로 하여 데이터를 균등 분산하고, Laravel에서는 사용자 요청 시 user_id를 해싱하여 어느 샤드에 연결할지 결정하는 ShardingManager 클래스를 구현합니다. 각 샤드는 Laravel의 다중 DB 연결 설정으로 관리하고, 미들웨어에서 인증된 사용자의 샤드를 식별하여 해당 연결을 자동 선택합니다. 크로스 샤드 쿼리는 성능상 최소화하되, 전체 통계는 각 샤드에서 집계 후 애플리케이션 레벨에서 병합하거나, Change Data Capture(CDC)로 데이터를 별도 분석 DB(ClickHouse, BigQuery)에 실시간 복제하여 조회합니다. 친구 관계는 양방향 저장 또는 별도 그래프 DB(Neo4j)로 분리하여 샤드 간 조인을 회피합니다. 샤드 리밸런싱은 새 샤드 추가 시 일관된 해싱으로 영향받는 키만 마이그레이션하고, 마이그레이션 중에는 dual-write(기존+새 샤드)와 lazy-migration을 병행하여 무중단 전환합니다. 조직적으로는 DBA 팀이 샤드 인프라를 관리하고, 애플리케이션 팀은 샤딩 로직을 추상화한 라이브러리를 사용하며, 샤드별 모니터링 대시보드로 데이터 분포와 쿼리 성능을 지속 관찰합니다.