1. AWS를 “플랫폼”이 아닌 “빌딩 블록”으로 만든 이유
클라우드를 처음 접하면 가장 흔하게 하는 오해가 있다.
AWS를 하나의 완성된 플랫폼, 즉 “알아서 다 해주는 거대한 시스템”으로 보는 것이다. 하지만 AWS는 의도적으로 그런 모습을 거부했다. AWS가 스스로를 플랫폼이라고 부르지 않고, 수많은 작은 서비스들의 집합으로 만든 이유는 명확하다. 모든 고객의 요구를 하나의 정답으로 통합하는 순간, 확장성과 유연성은 동시에 죽기 때문이다.
AWS는 처음부터 전 세계 수많은 기업이 각기 다른 요구사항을 가지고 들어올 것을 알고 있었다. 어떤 회사는 안정성을 최우선으로 하고, 어떤 회사는 비용을, 또 어떤 회사는 속도를 원한다. 이 요구들을 하나의 “정답 아키텍처”로 묶는 것은 불가능하다. 그래서 AWS는 완성품을 제공하는 대신, EC2, S3, VPC, RDS 같은 기본 재료(building block)만 제공한다. 사용자는 이 재료들을 조합해 자신만의 시스템을 만들어야 한다.
이 선택의 대가는 분명하다. AWS는 불친절하다. 대신 자유롭다. 사용자는 실수할 수 있고, 잘못 설계할 수 있다. AWS는 그 책임을 대신 지지 않는다. 하지만 바로 이 점이 AWS가 전 세계 최대 클라우드가 될 수 있었던 이유다.
2. AWS 아키텍처의 최종 책임을 사용자에게 두는 이유
AWS를 쓰다 보면 자주 드는 감정이 있다.
“이 정도는 AWS가 알아서 해줘도 되는 거 아니야?”
하지만 AWS는 일부러 그 선을 넘지 않는다.
AWS가 최종 아키텍처 책임을 사용자에게 두는 이유는, 책임을 가져가는 순간 선택권을 빼앗게 되기 때문이다. 예를 들어 AWS가 “이 서비스는 반드시 멀티 AZ로 써야 합니다”라고 강제한다면, 비용을 줄이고 싶은 고객은 아예 서비스를 못 쓰게 된다. 반대로 “이건 단일 AZ만 허용됩니다”라고 하면, 고가용성이 필요한 고객은 떠나게 된다.
그래서 AWS는 가능성만 제공한다. 멀티 AZ도 가능하고, 단일 AZ도 가능하다. 암호화도 할 수 있고, 안 할 수도 있다. 보안도 강하게 할 수 있고, 허술하게 할 수도 있다. 이 모든 선택의 결과는 사용자가 감당해야 한다. AWS는 이 구조 덕분에 산업, 규모, 성숙도가 전혀 다른 고객들을 모두 끌어안을 수 있었다.
3. AWS가 장애를 완전히 막으려 하지 않는 이유
AWS는 장애를 숨기지 않는다. 그리고 장애가 발생하지 않는 시스템을 약속하지도 않는다. 이는 기술력이 부족해서가 아니라, 그게 현실적이지 않다는 걸 너무 잘 알기 때문이다.
대규모 분산 시스템에서 장애는 확률의 문제다. 서버 수가 늘어날수록, 디스크가 많아질수록, 네트워크 장비가 많아질수록 장애는 “언젠가” 반드시 발생한다. AWS는 이 사실을 인정하고 출발한다. 그래서 목표는 “장애를 없애는 것”이 아니라, 장애가 발생해도 시스템 전체가 무너지지 않게 하는 것이다.
이 철학은 AWS의 거의 모든 설계에 녹아 있다. AZ 분리, 멀티 AZ, 헬스체크, 오토스케일링, 백업, 복제. 이 모든 것은 장애를 전제로 한 설계다. AWS는 장애를 막아주지 않는다. 대신 장애를 다룰 수 있는 도구를 준다.
4. SLA를 100%로 잡지 않는 이유
처음 보면 이상하다.
왜 AWS는 SLA를 99.9%, 99.99%처럼 애매한 숫자로 표현할까?
이유는 간단하다. 100% SLA는 거짓말이기 때문이다.
어떤 시스템도 100% 가용성을 보장할 수 없다. 이를 약속하는 순간, 단 한 번의 장애로 신뢰는 무너진다. AWS는 처음부터 현실적인 숫자를 제시한다. 그리고 그 숫자조차 서비스 단위, 구성 단위로만 보장한다.
중요한 점은, AWS의 SLA는 “아키텍처 전체”에 대한 것이 아니라, 개별 서비스 구성 요소에 대한 것이라는 사실이다. 즉, SLA를 조합해 최종 가용성을 만드는 책임은 사용자에게 있다. 이 구조는 불편하지만, 정직하다.
5. Design for Failure 철학
AWS를 이해하는 핵심 문장 하나를 꼽으라면 이것이다.
“Everything fails, all the time.”
AWS는 실패를 예외로 취급하지 않는다. 정상 상태의 일부로 취급한다. 그래서 서버 하나가 죽어도, AZ 하나가 사라져도, 서비스가 계속 동작하도록 설계하라고 강요한다. 이 철학이 없으면, 클라우드는 오히려 온프레미스보다 위험한 환경이 된다. 서버 수가 많아질수록 실패 확률은 기하급수적으로 증가하기 때문이다.
Design for Failure는 단순한 슬로건이 아니라, AWS 사용자의 기본 사고방식이 되어야 한다. “이게 실패하면?”이라는 질문을 끊임없이 던지는 사람이 클라우드에 적합한 사람이다.
6. 자유도가 높지만 위험한 이유
AWS는 거의 모든 것을 허용한다. 이건 장점이자, 치명적인 단점이다. 잘못된 보안 설정 하나로 데이터가 인터넷에 공개될 수 있고, 잘못된 아키텍처 하나로 비용이 폭발할 수 있다.
AWS는 이를 막아주지 않는다. 대신 “그럴 수 있다”는 사실을 문서로 알려줄 뿐이다. 이 자유도는 숙련자에게는 무기지만, 초보자에게는 지뢰밭이다. 그래서 클라우드는 “쉽게 시작할 수 있지만, 쉽게 망할 수도 있는” 환경이다.
7. 베스트 프랙티스를 강제하지 않는 이유
AWS는 베스트 프랙티스를 문서로 제공하지만, 강제하지 않는다. 왜냐하면 베스트 프랙티스는 항상 맥락 의존적이기 때문이다. 스타트업과 금융권, 내부 서비스와 대외 서비스의 “최선”은 다르다.
AWS는 정답을 정해주지 않는다. 대신 선택지를 열어둔다. 이로 인해 사용자는 끊임없이 판단해야 하고, 그 판단의 결과를 책임져야 한다.
8. 사용자가 실수하게 놔두는 이유
이건 잔인하게 들릴 수 있지만, AWS는 사용자가 실수할 자유를 존중한다. 왜냐하면 실수를 막기 위해 시스템을 단순화하면, 유연성도 함께 사라지기 때문이다.
AWS는 Guardrail을 제공하지만, 울타리를 치지는 않는다. 이 철학 덕분에 AWS는 어떤 사용자는 천재적으로 쓰고, 어떤 사용자는 재앙처럼 쓰게 된다.
9. Managed Service의 공통적인 제약이 생긴 이유
Managed Service를 쓰다 보면 답답해진다. “왜 이 설정은 못 바꾸지?”, “왜 커널 접근이 안 되지?”
그 이유는 간단하다. AWS가 대신 운영하려면, 통제권이 필요하기 때문이다.
자유를 주는 순간, 자동화는 깨진다. 자동화가 깨지는 순간, 매니지드는 성립하지 않는다. 그래서 Managed Service는 필연적으로 제약을 가진다. 이 제약을 받아들이는 대신, 사용자는 운영 부담을 내려놓는다.
10. 클라우드는 결국 “타협의 집합”이다
클라우드는 마법이 아니다.
자유 ↔ 통제
비용 ↔ 안정성
편의성 ↔ 성능
이 모든 것 사이에서 끊임없이 타협한 결과물이 클라우드다. AWS는 이 타협을 사용자에게 숨기지 않는다. 오히려 노골적으로 드러낸다. 그래서 어렵고, 그래서 강력하다.
출처: ChatGPT
