AWS 운영 전환
운영 파트너를 바꾼다고 해서 AWS를 새로 구축할 필요는 없습니다. 고객의 사업과 시스템을 먼저 이해하고, 지금 환경에서 확인이 필요한 부분만 정리한 뒤 운영을 이어받습니다.
기업마다 필요한 AWS 운영 방식은 다릅니다. 표준화된 대규모 운영이 적합한 기업도 있고, 시스템과 사업 맥락까지 함께 보는 운영이 필요한 기업도 있습니다. 아래는 후자에 해당할 때 자주 나오는 이야기입니다.
우리 환경이 어떤 서비스를 위해 존재하는지 매번 다시 전달해야 한다면, 이해가 조직이 아니라 개인에게 남아 있는 상태입니다.
포함 범위가 그때그때 확인해야 하는 것이라면, 필요한 요청을 미루게 됩니다.
급하지 않은 일은 기다릴 수 있습니다. 다만 급한 일에는 급한 경로가 따로 있어야 합니다.
원인이 어느 쪽인지는 보통 미리 알 수 없습니다. 고객이 먼저 분류해야 하는 구조라면 규명 자체가 늦어집니다.
월 구독의 값은 작업량이 아니라 범위로 설명될 수 있어야 합니다.
기능이 늘고 사용자가 늘면 인프라가 감당해야 할 것도 함께 바뀝니다.
증상이 하나로 분명하다면 그 지면부터 보셔도 됩니다 — AWS 비용 최적화 · AWS 장애 · 안정화 · 통합 보안.
인프라가 어떤 서비스와 업무를 위해 존재하는지 모르면 비용·장애·보안·확장성을 판단하기 어렵습니다. 빌드업웍스는 고객의 서비스와 시스템 구성, 개발 방식, 보안 요구, 성장 계획을 먼저 확인한 뒤 AWS 운영 방향을 함께 정합니다.
계정 · 네트워크 · 컴퓨팅 · 데이터베이스 · 백업 · 모니터링 · 비용을 함께 봅니다.
접근 권한과 경계 설정을 서비스 구조와 함께 확인합니다.
애플리케이션이 어떻게 만들어지고 배포되는지 이해한 상태에서 인프라를 운영합니다.
문제가 AWS 쪽인지 애플리케이션 쪽인지 고객이 먼저 구분하지 않으셔도 됩니다. 전체 구조를 함께 확인하고 필요한 해결 방향을 정리합니다. 다만 세 영역의 모든 작업이 월 구독에 포함되는 것은 아닙니다 — 어디까지 포함되는지는 아래 자주 묻는 질문에 적어 두었습니다.
주장이 아니라 실제로 진행한 일입니다. 어떤 조건에서 나온 결과인지, 어떤 경우엔 맞지 않는지까지 열어뒀습니다.
고객사와 기존 운영사의 이름은 밝히지 않습니다. 아래는 운영을 이어받은 뒤 실제로 수행한 작업의 범위입니다.
전환 전웹서버(EC2)와 데이터베이스(RDS)를 중심으로 서비스를 운영하던 환경이었고, 다른 회사가 AWS 운영을 맡고 있었습니다.
전환 이후 수행한 작업
단순히 AWS 관리 회사가 바뀐 것이 아니라, 고객 서비스에 더 적합한 구조로 AWS와 애플리케이션을 함께 개선했습니다.
이런 구조가 모든 환경에 더 나은 것은 아닙니다. 이 고객 환경에 적합하다고 판단된 범위에만 적용했습니다.
전환 전디지털 서비스 의존도가 높고 빠르게 성장하는 기업으로, 사내 개발팀과 여러 외부 협력사가 함께 일하는 환경이었습니다.
전환 이후 수행한 작업
AWS 인프라를 별도로 관리한 것이 아니라, 고객의 사업 확장 속도에 맞춰 인프라가 함께 성장하도록 지원했습니다.
AWS 인프라만 따로 보지 않고, 고객 사업이 넓어지는 흐름과 함께 운영 범위를 조정했습니다.
위 두 건은 수행한 작업의 범위를 정리한 것이며, 측정된 성과 수치가 없어 수치는 싣지 않았습니다. 수치가 있는 기록은 고객 성공사례에서 근거와 함께 보실 수 있습니다.
전환 자체보다 전환 이후 안정적으로 운영되는 것이 더 중요합니다. 그래서 환경을 확인하는 데 앞부분을 씁니다.
핵심 서비스, 중요한 시스템, 사용자, 개발 구조, 운영에서 겪는 어려움, 성장 계획, 보안 요구를 먼저 확인합니다.
계정과 접근 권한, 네트워크, 서버와 데이터베이스, 백업, 모니터링, 청구, 보안 설정을 차례로 살펴봅니다.
현재 어떤 권한이 어디에 열려 있는지, 배포와 문의는 어떤 경로로 흐르는지 확인합니다.
그대로 둘 부분, 먼저 개선할 부분, 나중에 개선할 부분, 그리고 운영 책임 범위를 나눠 제안합니다.
필요한 권한과 모니터링을 정리하고 운영을 이어받습니다.
환경에 맞는 운영 범위를 적용하고, 이후에는 매달 상태를 확인하며 개선을 이어갑니다.
사내 가상화 환경이나 자체 장비를 함께 쓰고 계신 경우, 지금 사용량과 시스템 특성을 먼저 확인합니다. 유지 · 최적화 · 단계적 이전(Migration) 가운데 어떤 방법이 맞을지 함께 판단하고, AWS 이전이 더 적합한 경우에만 단계적으로 제안합니다.
실제로 사내 가상 서버를 AWS로 옮겨 검증한 뒤, 기대한 만큼의 효과가 확인되지 않자 그대로 보고하고 고객이 기존 환경을 유지하기로 결정한 기록이 있습니다. VMware 환경 이전 검증 기록 보기 →
환경과 서비스 중요도에 따라 세 가지 중에서 고릅니다. 무엇이 맞을지는 현재 환경을 확인한 뒤 제안합니다.
최종 비용은 AWS 계정 수, 환경 복잡도, 운영 범위, 변경 작업량, 보안 요구, 대응 수준에 따라 달라질 수 있습니다. 월 포함 작업 범위, 초과 작업 단가, 야간 · 주말 · 공휴일 대응, 세부 SLA는 고객 환경과 운영 범위에 따라 계약에서 확정합니다.
아닙니다. 지금 쓰고 계신 환경을 그대로 두고 운영 주체만 이어받는 것이 기본입니다. 계정과 데이터는 고객사 명의로 두는 것이 원칙이라 관리 주체가 바뀌어도 자산은 그대로 남습니다. 변경이 필요한 부분이 있으면 운영에 어떤 영향이 있는지 먼저 설명하고 협의한 뒤에 진행합니다.
맡습니다. 문서가 남아 있지 않거나 담당자가 퇴사한 환경도 이어받아 왔습니다. 현재 구성을 먼저 점검해 무엇이 어떻게 설정돼 있는지 정리한 뒤 운영을 이어받습니다.
괜찮습니다. 상담이 곧 계약 해지를 뜻하지는 않습니다. 현재 환경을 확인하고 어떤 운영 범위가 맞을지 함께 정리하는 것까지가 상담의 범위이며, 전환 시점은 고객이 정하십니다.
전부 포함되지는 않습니다. 실제 작업 범위는 계약된 운영 범위를 따릅니다. 계약된 운영 범위를 넘는 작업이나 별도 프로젝트 규모의 변경은 사전에 범위와 비용을 안내하고 고객 승인 후 진행합니다.
환경에 맞는 범위를 함께 정합니다. AWS 기본 운영 · AWS 운영 관리 · AWS 핵심 운영 세 가지 중에서 고르며, 무엇이 맞을지는 현재 환경을 확인한 뒤 제안합니다. 세부 조건은 계약에서 확정합니다.
빌드업웍스
