이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
클라우드 실습 과정에서 멀티 어카운트 구조를 처음 설계해 봤습니다. 단일 어카운트로 모든 환경을 운영하다가 개발·스테이징·운영이 같은 네트워크에 있으면 실수로 운영 리소스를 건드리는 위험이 크다는 걸 경험하고, 계정을 분리하는 이유를 이해하게 됐습니다.
Transit Gateway로 VPC 간 라우팅을 중앙화하고, 계정별로 허용할 통신 경로를 명시적으로 정의하는 방식을 배웠습니다. 보안·거버넌스 측면에서는 SCPs로 어카운트별 서비스 사용 범위를 제한해 최소 권한 원칙을 계정 레벨에서도 적용했습니다.
실제 운영 규모의 설계 경험은 아직 없지만, 이 구조가 감사와 비용 추적을 어카운트 단위로 분리할 수 있다는 장점도 이해했습니다. 멀티 어카운트 전략은 초기에 설계하는 것이 나중에 마이그레이션하는 것보다 훨씬 효율적이라는 걸 이 실습에서 체감했습니다.
멀티 어카운트 구성에서 네트워크 비용을 예측하지 못한 경험이 있습니다. 학습 프로젝트에서 계정 간 통신을 구성했는데, 운영 후 VPC 피어링과 데이터 전송 요금이 예상보다 훨씬 많이 나왔습니다. 아키텍처 설계 시 보안·격리 목적에만 집중하고 트래픽 비용 구조는 검토하지 않았습니다. 계정 간 통신 빈도와 데이터 이동량에 따라 비용이 선형으로 늘어난다는 것을 몸으로 배웠습니다.
설계 단계에서 통신 경로와 예상 트래픽을 함께 계산했어야 했습니다. 이후로는 멀티 어카운트 설계 시 계정 간 통신 경로별 예상 트래픽과 비용 추정을 설계 문서에 포함하는 방식을 택했습니다. 이 실수가 이후 네트워크 설계 시 비용 시뮬레이션을 아키텍처 검토 항목에 포함하는 기준이 됐습니다. 멀티 어카운트 설계는 격리 목적만큼 계정 간 통신 비용 구조를 함께 검토하는 것입니다.
멀티 어카운트 네트워크 설계를 보안 감사 입장에서 생각해본 경험이 있습니다. 클라우드 보안 강의에서 실제 감사 체크리스트를 검토했는데, 감사자가 가장 먼저 보는 것은 계정 간 네트워크 접근이 문서화돼 있는지라는 것을 알게 됐습니다. 설계가 잘 돼 있어도 어떤 계정에서 어떤 계정으로 어떤 포트가 열려 있는지가 기록되지 않으면 감사에서 불명확 판정이 납니다. 이 시각에서 보면, 멀티 어카운트 설계의 완성은 구성도만큼 계정 간 접근 정책과 예외 규칙의 문서화를 포함합니다. 이를 반영해 설계 시 계정 간 허용 트래픽 목록과 근거를 아키텍처 문서에 병기하는 방식을 채택했습니다.
이 관점이 이후 네트워크 설계 시 구성 완성과 감사 가시성을 별개 체크 항목으로 두는 습관을 만들었습니다. 멀티 어카운트 설계의 신뢰성은 구성 완성도만큼 접근 정책 문서화에서 증명됩니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 핀다 네트워크 엔지니어 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.