SA가 왜 못 막았나요
구현은 팀이 하지만, 구현이 설계를 배신하지 않게 만드는 건 SA의 일입니다.
SA는 그 구조를 만들어야 합니다.
SA는 조직의 돈을 지키는 사람입니다.
보안은 체크리스트로 끝나는 게 아니라 운영입니다.
SA는 알림을 설계하는 사람이어야 합니다.
비용폭증은 대부분 기술이 아니라 통제의 부재입니다.
특히 보안과 관측, 비용 제어는 나중에 붙이는 옵션이 아니라 설계의 기본이 라고 생각하며, IAM 최소 권한, 네트워크 경계, 데이터 보호, 로그와 알림, 태깅과 예산통제까지 초기에 고정하겠습니다.

GS네오텍-면접)[Cloud] Solutions Architect(2026 신입) 면접 질문 기출, 1분 스피치, 2025 면접족보
일반면접 질문 15]
관측 가능성(Obs ervability) 설계를 어떻게 하며, 어떤 지표를 운영 KPI로 보나요
장애 원인이 본인 설계 결함으로 밝혀지면 어떻게 책임지겠습니까
저는 '예쁜 설계도'를 만드는 사람보다, 운영에서 버티는 설계를 만드는 사람이 경쟁력이 있다고 확신합니다.
Solutions Architect는 "고객의 요구를 시스템 제약과 비용 현실에 맞게 번역해, 운영 가능한 구조로 고정시키는 사람"입니다.
설계의 결과가 장애, 비용폭증, 보안사고로 돌아왔을 때 원인을 설명하고 재발을 막을 수 있어야 한다는 뜻입니다.
구현은 팀이 하지만, 구현이 설계를 배신하지 않게 만드는 건 SA의 일입니다.
이 걸 놓치면 SA는 장식이 됩니다.
성공 기준 : 무엇을 "성공"이라고 판단하는 가(가용성, 지연시간, 처리량, 비용 상한, 보안 기준
성공 기준 예시로는 목표 TPS/동시접속, p95 지연시간, 장애시 복구시간(RTO/RPO), 비용 상한(월 예상비용 범위), 보안 기준(접근 통제/암호화/로그) 같은 것들이고, 종료 조건은 1) 기준 충족시 본 프로젝트 전환 2) 미충족 시 대 안 아키텍처로 재시도 3 사업 가치가 부족하면 중단으로 명확히 합니다.
PoC가 늘어지는 건 기술 문제가 아니라 의사결정 구조가 없기 때문입니다.
SA는 그 구조를 만들어야 합니다.
기준은 네 가지입니다.
그래서 보안은 관측과 알림이 같이 가야 합니다.
그리고 알림은 적게, 정확하게 갑니다.
알림이 많으면 아무도 보지 않습니다.
SA는 알림을 설계하는 사람이어야 합니다.
30일 : 구조개선(아키텍처/운영), 자동화(알림/ 런북), 테스트(장애리허설), KPI 재정의
변경은 반드시 비용과 리스크를 동반합니다.
변경은 문서로 남긴다(요구사항, 영향 범위, 일정, 비용
변경은 우선순위를 바꾼다(추가하면 무엇을 빼는지 합의
변경은 테스트 범위를 바꾼다(회귀 범위 재정의
이 원칙을 지키면 SA는 고객을 막는 사람이 아니라, 프로젝트를 지키는 사람이 됩니다.
SA는 말로 설득하지만, 최종적으로는 문서로 팀을 움직입니다.
다만 고집으로 버티지 않고 선택지를 만들어 버티겠습니다.
B안 : 일정은 조금 늘리되치명 리스크 제거
SA는 선택지를 제공해야 합니다.
재발방지장치(표준, 리뷰, 테스트, 모니터링)를 남겨야 책임입니다.
트레이드 오프(비용/가용성/보안/일정)를 수치와 시나리오로 정리해 선배와 팀이 빠르게 결정하도록 돕겠습니다.

[hwp/pdf](GS네오텍-면접) [Cloud] Solutions Architect(2026신입) 면접질문기출, 1분 스피치, 2025면접족보