이 질문 뒤에 면접관이 확인하려는 것은 따로 있습니다.
퍼블릭 클라우드 아키텍처 설계에서 가장 먼저 한 것은 워크로드 특성 파악이었습니다. 읽기가 많은 서비스와 쓰기가 많은 서비스는 배치 전략이 달라야 하고, 배치 작업과 실시간 요청 처리도 인프라 구성을 다르게 가져갔습니다.
네트워크 설계에서는 VPC 서브넷을 퍼블릭과 프라이빗으로 분리하는 것을 기본으로 했습니다. 외부에서 직접 접근이 필요 없는 DB나 내부 서비스는 프라이빗 서브넷에 배치하고, 로드 밸런서만 퍼블릭에 두는 구조로 보안 레이어를 구성했습니다.
비용 최적화도 설계 단계에서 함께 고려했습니다. 개발 환경에는 스팟 인스턴스를 사용하고, 프로덕션은 예약 인스턴스로 비용을 줄이는 전략을 팀에 제안했습니다. 아키텍처는 기능만큼 비용도 설계 기준이라는 것을 인식하게 됐습니다.
졸업 프로젝트에서 처음 퍼블릭 클라우드를 써봤는데, 한 달 뒤 예상보다 3배 높은 청구서가 나왔습니다. 무엇이 비용을 키웠는지 바로 알 수 없어서 콘솔을 뒤졌더니, 테스트용으로 올려뒀던 인스턴스들이 종료하지 않은 채 계속 돌아가고 있었습니다. 이후 모든 리소스에 환경과 용도 태그를 붙여 목적별로 구분하고, 월간 예산 임계값을 설정해 80% 도달 시 알림이 오도록 했습니다. 이 설정만으로 다음 달부터 비용이 예측 범위 안에서 움직였습니다. 클라우드는 쓴 만큼 나오는 구조라 비용 가시성을 먼저 확보하지 않으면 언제 터질지 모른다는 걸 이 경험으로 배웠습니다.
팀 프로젝트에서 온프레미스 서버를 클라우드로 옮길 때, 처음에는 아키텍처를 통째로 재설계하려다 너무 범위가 커져 막혔습니다. 결국 기존 구성을 그대로 클라우드 VM으로 Lift & Shift하는 것부터 시작했습니다. 서비스가 안정적으로 돌아가는 걸 확인한 뒤, 정적 파일은 오브젝트 스토리지로 옮기고 DB는 매니지드 서비스로 전환하는 작업을 단계별로 진행했습니다. 처음에는 VM 안에서 DB를 직접 운영했는데 백업이나 복제 설정을 직접 해야 해서 번거로웠는데, 매니지드 서비스로 옮기자 그 부담이 사라졌습니다. 한꺼번에 바꾸는 것보다 단계를 나눠 각 전환 시점에 검증하는 방식이 리스크를 크게 줄였습니다.
답변에서 흔히 빠지는 것들 — 빠져 있으면 꼬리질문이 깊어집니다.
이 질문에 이어 신세계아이앤씨 솔루션 아키텍트 면접관이 던질 가능성이 높은 후속 질문.
이 페이지의 질문·답변·꼬리질문은 유사 직군 채용 시장의 공개된 면접 후기·커뮤니티 게시물을 분석해 구성한 학습 자료입니다. 특정 회사가 실제로 이 질문을 출제했다는 것을 보장하지 않으며, 모든 예시는 우문현답이 직접 작성한 창작물입니다. 해당 회사의 공식 입장과는 무관합니다. 회사 측의 정정 요청이 있을 경우 24시간 이내에 응답·수정합니다.