AWS 리드·아키텍트 종합 기술면접

Transit Gateway는 중앙 집중식 허브 모델로 관리가 용이하지만 홉이 추가되어 레이턴시가 증가하고 데이터 처리 비용이 발생합니다. VPC Peering은 1:1 직접 연결로 레이턴시가 가장 낮지만 관계가 많아지면 관리 복잡도가 기하급수적으로 증가합니다. PrivateLink는 서비스 엔드포인트 방식으로 보안성이 높고 특정 서비스 노출에 적합하지만 시간당 비용과 데이터 처리 비용이 모두 발생합니다. 리전 간 통신이 빈번한 핵심 서비스는 VPC Peering으로 직접 연결하고, 관리 목적이나 비빈번한 통신은 Transit Gateway로 통합하며, 외부 파트너나 제한적 서비스 노출은 PrivateLink를 사용하는 하이브리드 전략이 효과적입니다. 비용 최적화를 위해 CloudWatch 메트릭으로 실제 트래픽 패턴을 분석하고, 데이터 전송량이 많은 경로는 리전 통합이나 캐싱 전략을 먼저 검토해야 합니다.

먼저 Cost Explorer와 Cost and Usage Report를 활용해 리소스별, 팀별, 프로젝트별 비용 가시성을 확보하고 태깅 정책을 강제합니다. 안정적인 베이스라인 워크로드는 Compute Savings Plans로 1-3년 커밋하여 최대 할인을 받고, 예측 가능한 특정 인스턴스 타입은 RI로 커버하며, 배치 작업이나 스케일 아웃은 Spot Instance로 70-90% 비용 절감을 달성합니다. FinOps 팀을 구성하여 주간 비용 리뷰를 진행하고, 각 팀에 예산을 할당한 뒤 AWS Budgets로 알림을 설정하며, 비용 절감 성과를 팀 KPI에 반영합니다. Service Control Policy와 AWS Config Rules로 비승인 리전이나 고비용 인스턴스 타입 사용을 자동 차단하되, 개발팀은 승인된 범위 내에서 자유롭게 실험할 수 있도록 샌드박스 계정을 별도 운영합니다. Trusted Advisor와 Compute Optimizer의 권장사항을 자동으로 수집하여 월간 최적화 백로그를 만들고, 우선순위가 높은 항목부터 순차적으로 적용합니다.

사용자 프로필과 관계 데이터는 트랜잭션과 일관성이 중요하므로 Aurora PostgreSQL을 메인 DB로 사용하고, Read Replica를 통해 읽기 부하를 분산합니다. 게시물과 댓글은 DynamoDB를 사용하여 무제한 확장성을 확보하고, 사용자별 파티션 키로 효율적인 쿼리를 지원합니다. 타임라인과 피드는 ElastiCache Redis의 Sorted Set을 활용하여 실시간 조회 성능을 극대화하고, TTL을 설정하여 메모리를 효율적으로 관리합니다. 전문 검색과 해시태그 검색은 OpenSearch에 비동기로 인덱싱하며, 좋아요 카운트 같은 집계 데이터는 DynamoDB Streams를 통해 실시간 업데이트합니다. Aurora에서 DynamoDB로의 마이그레이션은 DMS를 활용하고, DynamoDB에서 OpenSearch로는 Lambda를 통한 이벤트 기반 동기화를 구현하며, 각 저장소의 eventual consistency 특성을 고려하여 UI에서 적절한 피드백을 제공합니다.

Terraform을 주요 IaC 도구로 선택하되 멀티 클라우드 확장성과 풍부한 프로바이더 생태계를 활용하고, AWS 네이티브 서비스는 CDK로 보완하여 타입 안정성과 추상화 수준을 높입니다. 중앙 플랫폼 팀이 VPC, Transit Gateway, 보안 베이스라인 등 공통 인프라를 Terraform 모듈로 제공하고, 각 서비스 팀은 이를 참조하여 자신의 애플리케이션 인프라를 정의합니다. 멀티 계정 환경은 AWS Organizations와 Control Tower로 구조화하고, 계정별로 별도 Terraform 상태 파일을 S3 백엔드에 저장하며 DynamoDB로 락을 관리합니다. GitOps는 ArgoCD나 Flux를 활용하여 Git 저장소가 단일 진실 공급원이 되도록 하고, PR 기반 리뷰와 자동 검증을 통해 변경을 통제합니다. 팀 자율성을 위해 서비스별로 독립적인 배포 파이프라인을 구성하되, Sentinel 정책이나 OPA로 보안 및 비용 가드레일을 자동 검증하며, 공통 모듈 업데이트는 의존성 관리 도구로 점진적으로 전파합니다.

먼저 CloudWatch와 X-Ray로 평소 트래픽 패턴을 분석하여 병목 지점을 식별하고, Load Testing 도구로 목표 부하에서의 시스템 동작을 사전 검증합니다. 애플리케이션 레이어는 ECS Fargate나 EKS를 사용하여 Target Tracking 정책으로 CPU/메모리 기반 스케일링을 구성하고, 이벤트 시작 전 Scheduled Scaling으로 미리 용량을 확보합니다. Aurora는 Auto Scaling으로 Read Replica를 자동 증설하고, 쓰기 부하는 Aurora Serverless v2로 즉각 대응하며, 캐시 히트율을 높이기 위해 ElastiCache 용량을 사전 증설합니다. Lambda는 Reserved Concurrency로 다운스트림 보호와 Provisioned Concurrency로 콜드 스타트를 제거하며, SQS를 활용한 비동기 처리로 급격한 부하를 평탄화합니다. CloudFront에서 캐싱 정책을 최적화하여 오리진 부하를 최소화하고, WAF Rate Limiting으로 악의적 트래픽을 차단하며, 이벤트 종료 후 Step Scaling 정책으로 빠르게 스케일 인하여 비용을 절감합니다.

먼저 현재 시스템을 도메인별로 분석하여 비즈니스 가치와 기술 부채를 매트릭스로 평가하고, 의존성이 낮고 가치가 높은 영역부터 우선순위를 정합니다. Strangler Fig 패턴으로 API Gateway를 앞단에 배치하여 라우팅 규칙으로 점진적으로 트래픽을 신규 서비스로 전환하고, 레거시와 신규 시스템 간 데이터 동기화는 DMS와 CDC를 활용합니다. 초기 단계는 Lift and Shift로 EC2에 빠르게 이전하여 클라우드 운영 경험을 쌓고, 이후 컨테이너화와 마이크로서비스 분리를 순차 진행하며, 최종적으로 서버리스나 매니지드 서비스로 최적화합니다. 각 단계마다 Feature Flag를 활용하여 즉시 롤백 가능하도록 하고, 병렬 운영 기간 동안 Shadow Traffic으로 신규 시스템을 검증합니다. 조직 측면에서는 AWS 교육 프로그램과 핸즈온 워크샵을 진행하고, 클라우드 센터 오브 엑셀런스를 구성하여 베스트 프랙티스를 전파하며, 초기 파일럿 프로젝트의 성공 사례를 내부 홍보하여 변화 저항을 완화합니다.

먼저 각 이해관계자와 1:1 미팅을 통해 근본적인 우려사항과 목표를 파악하고, 상충이 아닌 공통 목표(안정적인 서비스, 비즈니스 성장)로 프레이밍합니다. 기술적으로는 멀티 계정 전략으로 샌드박스-개발-스테이징-프로덕션 환경을 분리하여 개발팀은 샌드박스에서 자유롭게 실험하되, Service Control Policy로 자동화된 가드레일을 설정하여 보안 요구사항을 충족합니다. 비용 측면에서는 샌드박스 계정에 자동 종료 정책과 예산 알림을 적용하고, FinOps 대시보드로 팀별 비용을 가시화하여 자율 규제를 유도합니다. 보안팀과는 정기 리뷰를 통해 위협 모델을 함께 검토하고, AWS Security Hub와 Config로 지속적 컴플라이언스 모니터링을 자동화하여 수동 검토 부담을 줄입니다. 경영진에게는 클라우드 전환의 단기 비용 증가를 투명하게 공유하되, 속도 개선과 인프라 운영 비용 절감을 정량적 지표로 보고하며, 파일럿 프로젝트의 성공 사례로 신뢰를 구축합니다. 분기별 회고를 통해 각 팀의 피드백을 수렴하고 정책을 점진적으로 개선하여, 통제와 자율성의 균형점을 지속적으로 조정합니다.