이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
퍼블릭 클라우드 아키텍처를 분석할 때 제가 먼저 보는 건 보안 경계와 접근 제어 구성입니다. 어떤 리소스가 외부에 노출되어 있고, 내부 서비스 간 통신이 어떻게 제어되는지가 아키텍처의 신뢰성을 결정하는 핵심 요소입니다. 다음으로는 가용성 설계를 확인합니다. 단일 가용 영역에 모든 것을 배치했는지, 아니면 멀티 AZ로 분산되어 있는지를 보면 장애 시 서비스 중단 가능성을 예측할 수 있습니다. 비용 구조도 중요한 분석 항목입니다.
예약 인스턴스와 온디맨드의 혼합 비율, 불필요한 데이터 전송 비용 발생 여부 등을 확인하면 최적화 가능한 부분을 식별할 수 있습니다. 태그 정책과 리소스 그룹 구성을 보면 조직이 클라우드를 얼마나 체계적으로 관리하고 있는지도 파악할 수 있습니다. 아키텍처 분석은 현재 구성의 문제점보다 의도를 먼저 이해하는 것부터 시작합니다.
클라우드 환경을 분석하다가 사용하지 않는 리소스가 여러 리전에 걸쳐 방치된 것을 발견한 경험이 있습니다. 서비스 목적으로 생성됐다가 삭제 없이 남은 인스턴스와 스토리지가 지속적으로 비용을 발생시키고 있었습니다. 이후에는 클라우드 아키텍처 분석 시 리소스 태그 현황과 미태그 리소스 목록을 먼저 확인하는 단계를 추가했습니다. 태그가 없는 리소스는 생성 목적이 불명확하고 삭제 여부 판단이 어려워지는 경우가 많았습니다. 퍼블릭 클라우드에서 아키텍처의 완성도는 기술 구성만이 아니라 리소스 가시성과 관리 가능성도 포함됩니다.
이 경험이 이후 클라우드 아키텍처 분석 시 리소스 태깅 현황을 초기 점검 항목에 포함하는 기준이 됩니다. 퍼블릭 클라우드 아키텍처 분석에서 리소스 가시성 확보는 보안·비용·운영 세 가지 측면 모두에서 분석의 선행 조건이 된다는 원칙을 지킵니다.
클라우드 아키텍처를 분석하면서 특정 벤더의 독점 서비스에 과도하게 의존하는 구조를 발견한 경험이 있습니다. 서비스 이전이나 장애 시 대체 경로가 없는 구간이 여러 곳에 있었고, 이것이 단일 장애점이자 협상력 약화 요인이 됐습니다. 분석 시 독점 서비스 사용 비율과 이식 가능성(portable vs. managed-only)을 함께 파악하는 접근이 유효하다는 것을 배웠습니다. 기술 선택이 좋더라도 그 선택이 만드는 종속 구조를 함께 인식해야 아키텍처 위험을 제대로 평가할 수 있습니다. 퍼블릭 클라우드 분석에서 기능 적합성과 벤더 종속 위험은 동시에 평가해야 하는 두 축입니다.
이 관점이 이후 클라우드 아키텍처 분석 시 벤더 종속 구간 식별을 분석 항목에 포함하는 기준이 됩니다. 퍼블릭 클라우드 아키텍처 분석에서 기술 적합성만이 아니라 벤더 종속 위험을 함께 평가해야 실질적인 아키텍처 위험 판단이 완성된다는 원칙을 지킵니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 넷마블 정보보안 담당 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.