AWS 솔루션스 아키텍트 면접을 위한 STAR 기법: 활용 방법과 예시
STAR 기법은 AWS Solutions Architect 면접에서 행동 및 상황 기반 질문에 답변을 구조화하는 가장 신뢰도 높은 방법입니다. 이 글에서는 STAR가 어떻게 작동하는지, 역할별 예시와 함께 답변을 더 날카롭게 만들어 줄 Google XYZ 공식까지 정리했습니다. 그리고 그 모든 것에 앞서, 일단 면접 자리에 불려가야 합니다 — Specific Resume는 당신의 적합성이 한눈에 드러나는 맞춤형 이력서를 작성하는 데 도움을 줄 수 있습니다.
STAR 기법이란?
STAR 기법은 답변을 위한 프레임워크입니다. Situation, Task, Action, Result의 약자죠. 면접관이 “언제 한 번 이런 일이 있었는지 말해 주세요…” 같은 행동 질문을 쓰는 이유는, 과거 행동이 미래 퍼포먼스를 예측하는 실질적인 신호이기 때문입니다. STAR는 우리가 핵심에서 벗어나지 않고, 명확하고 완결성 있게 답변하도록 도와줍니다.
- Situation(상황) — 맥락입니다. 어디에서, 어떤 일이 벌어지고 있었나요?
- Task(과제) — 당신이 책임졌던 일, 혹은 해결해야 했던 문제입니다.
- Action(행동) — 그 상황에서 당신이 구체적으로 한 일입니다.
- Result(결과) — 그 행동의 결과로 무엇이 일어났는지, 가능하면 숫자로 표현합니다.
이게 왜 효과적일까요? 대부분의 지원자가 이런 질문에 제대로 답하지 못하기 때문입니다. 추상적으로 말하거나, 배경 설명을 건너뛰거나, 팀에 공을 돌리느라 본인 역할이 흐릿해지거나, 결과를 끝까지 말하지 않습니다. STAR 답변은 따라가기 쉽고, 주장보다는 증거를 제시하며, 숙련된 면접관이 후보자를 평가하는 방식과도 잘 맞습니다. 즉, 면접관의 언어로 말하게 도와주는 셈입니다.
요즘처럼 애초에 면접을 잡는 것 자체가 어려운 상황에서는 이게 더 중요합니다. LinkedIn의 2024년 미국 노동시장 데이터에 따르면, 공고당 지원자 수가 2022년 약 1.5명에서 2024년 2.5명으로 증가했습니다. AWS만의 수치는 아니지만, 몇 년 전보다 채용 퍼널이 훨씬 더 좁아졌다는 사실을 보여 줍니다. [1]
이제 AWS Solutions Architect 역할에 STAR를 실제로 적용하면 어떻게 보이는지 살펴 보겠습니다.
AWS Solutions Architect 면접에서의 STAR 기법 예시
아래 예시는 실제 AWS Solutions Architect들이 자주 받는 질문을 바탕으로 작성했습니다. 더 폭넓은 질문 리스트가 필요하다면, 이 AWS Solutions Architect 면접 질문 모음과 AWS Solutions Architect 면접에서 리크루터가 실제로 생각하는 것에 대한 가이드를 같이 참고해 보세요.
예시 1: “아키텍처 결정과 관련해 엔지니어링 팀과 의견이 갈렸던 때를 말해 주세요”
면접관은 우리가 ego 없이 설득할 수 있는지, 트레이드오프를 균형 있게 다루는지, 그리고 신뢰성과 비용을 동시에 지킬 수 있는지를 보고 싶어 합니다.
Situation: 한 프로덕트 팀이 고객-facing 워크로드를 EC2에서 컨테이너로 빠르게 이전하고 싶어 했습니다. 그런데 더 많은 제어권을 가질 수 있다고 생각해, EC2 위에 자체 관리형 Kubernetes 구성을 고집했습니다.
Task: 저는 출시 마감일을 지키면서도 불필요한 운영 오버헤드를 만들지 않는 아키텍처를 추천해야 했습니다.
Action: 가용성, 스케일링, 보안, 운영 부담 측면에서 요구사항을 정리한 뒤, 자체 관리형 Kubernetes와 Amazon EKS(관리형 노드 그룹 포함) 두 가지 옵션을 제시했습니다. 패치, 클러스터 유지보수, 업그레이드 리스크에 따른 운영 비용을 추정해 보여 주고, 오토스케일링과 서비스 계정용 IAM 역할을 포함한 짧은 PoC를 진행했습니다.
Result: 팀은 최종적으로 EKS를 선택했습니다. 우리는 일정대로 런칭했고, 예상 클러스터 유지보수 노력을 줄였으며, 장기적으로 운영 리스크를 키울 수 있었던 커스텀 컨트롤 플레인 구성을 피할 수 있었습니다.
예시 2: “프로덕션 성능 문제를 해결했던 경험을 설명해 주세요”
면접관은 우리가 단지 아키텍처를 추상적으로 설명하는 수준이 아니라, 실제 클라우드 이슈를 체계적으로 진단할 수 있는지 증거를 보고 싶어 합니다.
Situation: 한 클라이언트의 웹 애플리케이션이 지역 마케팅 캠페인으로 트래픽이 급증한 후 피크 시간대에 지연(latency) 스파이크를 겪기 시작했습니다.
Task: 저는 병목 구간을 빠르게 찾아내고, 과도한 비용 증가 없이 성능을 안정화해야 했습니다.
Action: CloudWatch 지표, ALB 타깃 응답 시간, RDS Performance Insights, 애플리케이션 로그를 검토했습니다. 그 결과 비효율적인 DB 쿼리와 부족한 읽기 용량이 주요 문제라는 것을 파악했습니다. 반복 조회를 위해 ElastiCache를 도입하고, 쿼리 최적화를 제안했으며, 읽기 리플리카를 추가하고, 애플리케이션 계층의 오토 스케일링 임계값을 조정했습니다.
Result: 피크 시간대 평균 응답 시간이 크게 감소했고 에러율도 정상 수준으로 돌아왔습니다. 클라이언트는 롤백 없이 캠페인을 계속 진행할 수 있었고, 최종 아키텍처는 버스트 트래픽에서도 훨씬 예측 가능하게 스케일링 되었습니다.
예시 3: “아키텍처 결정이 계획대로 되지 않았던 경험을 말해 주세요”
면접관은 우리가 실수를 인정하고, 빠르게 학습하며, 방어적으로 굴지 않고 회복할 수 있는지를 확인하고 싶어 합니다.
Situation: 한 마이그레이션 프로젝트 초기에, 저는 AWS 이전을 빠르게 진행한다는 목표로 레거시 내부 애플리케이션에 대해 리프트앤시프트 접근을 추천했습니다.
Task: 제 목표는 마이그레이션 리스크를 줄이고 시스템을 신속하게 AWS로 옮기는 것이었지만, 애플리케이션에는 숨겨진 의존성과 부족한 가시성 문제가 있었습니다.
Action: 첫 번째 테스트 컷오버에서 설정 드리프트와 깨지기 쉬운 배치 작업이 드러나자, 저는 전략을 바꾸었습니다. 실패 지점을 문서화하고 단계적 마이그레이션을 제안했으며, CloudWatch로 로깅을 강화하고, 워크로드를 나눠 안정적인 컴포넌트는 먼저 리호스트하고 리스크가 큰 서비스는 이후에 리팩터링하도록 설계했습니다.
Result: 전체 컷오버는 지연되었지만, 수정된 계획 덕분에 지저분한 프로덕션 장애를 예방할 수 있었습니다. 또한 이 프로젝트를 기반으로 마이그레이션 체크리스트를 만들어 이후 워크로드에 재사용하면서 예상치 못한 이슈가 훨씬 줄어들었습니다.
모든 질문에 STAR를 쓸 필요는 없다
STAR는 행동 및 상황형 질문에 쓰는 도구입니다. 예를 들면 “언제 한 번 이런 일이 있었는지 말해 주세요…”, “어떤 상황에서…”, “어떻게 대처했나요?” 같은 질문이죠. 반대로 희망 연봉, 입사 가능일, Terraform·CloudFormation·EKS 사용 경험 여부 같은 직접적인 사실 질문에는 맞지 않습니다. 단순 질문에 STAR를 억지로 끼워 넣으면, 준비해 온 티가 과도하게 나고 솔직하지 않은 인상을 줄 수 있습니다. 질문 유형에 맞춰 답변 구조를 바꾸는 것이 더 좋은 전략입니다.
Google XYZ 공식: 결과를 더 강하게 만드는 법
Google XYZ 공식은 단순합니다: [X]를 달성했으며, [Y]로 측정되었고, [Z]를 수행하여 이뤄 냄. Google이 이력서 불릿 포인트용으로 널리 퍼뜨린 방식이지만, 면접에서도 똑같이 유용합니다. 무엇이 바뀌었는지, 어떻게 측정됐는지, 우리가 무엇을 해서 그 결과를 만들었는지를 명확히 말하도록 강제하기 때문입니다.
STAR와 XYZ는 함께 쓸 때 가장 효과적입니다.
| 프레임워크 | 하는 일 |
|---|---|
| STAR | 무슨 일이 있었고, 우리가 어떻게 대응했는지를 이야기 형식으로 보여 줍니다 |
| XYZ | 그 이야기의 ‘한 줄 요약’이자 측정 가능한 임팩트를 제시합니다 |
실전에서는 XYZ가 STAR의 Result(결과) 부분 안에 들어갑니다. “잘 마무리되었습니다”로 끝내는 대신, 구체적인 성과를 제시하는 거죠.
Situation: AWS 상에서 동작하는 한 SaaS 워크로드가 트래픽 스파이크 시 비용과 지연 시간 문제를 겪고 있었습니다.
Task: 저는 클라우드 비용을 비례 이상으로 늘리지 않으면서 성능을 개선해야 했습니다.
Action: 캐싱 레이어를 재설계하고, 컴퓨트 리소스를 적정 용량으로 조정했으며, 정적 자산을 CloudFront 뒤로 이전했습니다.
Result (XYZ 적용): CloudFront 캐싱 도입, 인스턴스 적정화, 스케일링 정책 개선을 통해 평균 페이지 로드 지연 시간을 35% 줄이고, 월간 인프라 비용을 18% 절감했습니다.
이 논리는 이력서에서도 그대로 통합니다. 지금 지원 중이라면, 이력서 역시 이런 임팩트 우선 사고방식을 반영해야 합니다. AWS Solutions Architect 커버 레터를 맞춤 작성해 스토리를 강화하는 것도 좋지만, 첫 스캔에서 가장 많은 역할을 하는 것은 여전히 이력서입니다.
AWS Solutions Architect 면접에서 눈에 띄는 지원자는 극적인 스토리를 가진 사람이 아니라, 자신의 일이 만들어 낸 구체적인 영향력을 명확하게 설명할 수 있는 사람입니다.
연습해야 STAR 기법이 자연스러워진다
STAR는 구조를, XYZ는 임팩트를 제공합니다. 둘 다 소리 내서 연습해야 답변이 기계적이지 않고 자연스럽게 나옵니다. 실제 면접 전 리허설용으로 이 가이드 — ChatGPT로 AWS Solutions Architect 면접 질문을 연습하는 방법 — 을 활용해 보는 것도 좋은 방법입니다.
하지만 면접을 못 잡으면 이 모든 게 소용없습니다. 리크루터는 여전히 몇 초 안에 스냅 판단을 내리기 때문에, 이력서에서 곧바로 ‘딱 맞는 후보’라는 인상이 전달되어야 합니다. 지금 지원 중이라면, Specific Resume로 다음 AWS Solutions Architect 지원을 위해 맞춤형 이력서를 만들어 보세요.
출처
- LinkedIn Economic Graph 2025 노동시장 전망 — 미국 기준 공고당 지원자 수가 2022년 1.5명에서 2024년 2.5명으로 증가한 데이터 인용.
