AWS 장애와 '위시본12'가 보여준 클라우드의 민낯

한 번의 비밀번호가 거대한 클라우드를 멈추는 순간

거대한 클라우드 서비스가 멈출 때마다 많은 사용자는 단순히 "서버가 터졌다" 정도로만 받아들입니다. 하지만 이번에 회자된 AWS 장애 일화는 그 이면에 훨씬 인간적인 허술함이 숨어 있음을 보여줍니다. 10년 전 개발자가 개인 편의를 위해 짜둔 스크립트, 그리고 'wishbone12' 같은 비밀번호가 오늘날 글로벌 인프라의 목줄을 쥐고 있었다는 서사는 과장이 섞였더라도 묘하게 현실적입니다.

공식 원인보다 더 설득력 있는 '전언'의 힘

AWS는 해당 장애의 원인을 DNS 설정을 담당하는 계획자와 실행자 모듈 사이의 꼬인 동작으로 설명했습니다. 계획을 짜는 프로세스와 실제로 DNS를 갱신하는 프로세스가 어긋나면서, 이전 설정이 덮어써지고 일부 설정이 삭제되어 복구가 어려워졌다는 식의 구조입니다. 문장으로 보면 그럴듯하지만, 현업 개발자의 눈에는 어딘가 비어 있는 설명처럼 느껴집니다. "그럼 다시 한 번 제대로 실행하면 안 되는가"라는 질문이 자연스럽게 떠오르기 때문입니다.

반대로, 술집에서 우연히 들었다는 이야기, 즉 예전 계약 개발자가 만든 설정 복사 스크립트가 레포지토리 속에 잠들어 있다가 누군가 "편하겠다"는 이유로 프로덕션에 끌어올려 사용했다는 서사는 황당하면서도 이상하게 현실적입니다. 조직 안에서 종종 벌어지는 코드 재사용 패턴과 너무 비슷하기 때문입니다. 저라면 이 두 이야기를 진실 여부보다, 현대 클라우드 운영이 가진 구조적 위험을 드러내는 상징으로 읽겠습니다.

개발자의 사소한 편의가 인프라 전체를 흔드는 방식

이야기의 핵심은 한 사람의 실수라기보다, "원래는 나만 쓰려고 만든 도구"가 조직의 표준 툴처럼 자라난 과정에 있습니다. 개발자가 서버 설정을 쉽게 옮기려고 만든 복사 스크립트, 대충 테스트만 하고 개인 용도로 쓰던 코드가 레포지토리 어딘가에 남습니다. 시간이 흐르며 팀이 바뀌고, 누군가는 문서에서 그 스크립트를 발견합니다. 급한 일정 속에서 "이거 원래 쓰던 거니까 그냥 쓰자"라는 판단이 내려지고, 그 순간 개인용 해킹이 조직의 인프라 도구로 승격됩니다.

이 패턴은 어느 회사나 존재합니다. 한국의 중견 SI 기업부터 글로벌 빅테크까지 다르지 않습니다. 문제는 클라우드 인프라일수록 이 작은 도구가 영향을 미치는 범위가 폭발적으로 커진다는 점입니다. 한 줄짜리 잘못된 삭제 명령이 더 이상 한 대 서버의 초기화로 끝나지 않고, 수천 대 인스턴스의 설정 삭제로 이어질 수 있습니다. 제 기준에서는 이 지점이 '위시본12' 일화가 주는 가장 현실적인 경고라고 봅니다.

레거시 코드와 조직 문화, 왜 항상 같은 방식으로 터지는가

많은 조직에서 "우리 시스템은 다 정리되어 있다"라는 말을 하지만, 내부를 직접 들여다본 사람은 그 말을 곧이곧대로 믿기 어렵습니다. 특히 오랜 세월 운영된 시스템일수록 레거시 코드와 임시 스크립트가 기묘하게 얽힌 채 살아 있습니다.

레거시가 지워지지 않는 진짜 이유

레거시 코드는 단순히 "옛날 코드"라서 위험한 것이 아닙니다. 진짜 위험은, 그 코드가 지금도 잘 돌아간다는 사실입니다. 수년 동안 장애 없이 돌아갔기 때문에 누구도 손대려 하지 않습니다. 누군가는 주석에 "절대 수정 금지, 건드리면 난리 난다"라는 말을 적어두고 떠납니다. 이후 합류한 개발자는 저 주석을 보고 편집기를 조용히 닫습니다. 이 순간 레거시는 더 이상 기술이 아니라 권위와 공포의 문제가 됩니다.

이 구조에서 위험한 점은, 레거시 코드의 실제 동작과 의도가 문서가 아니라 사람의 기억 속에만 남는다는 사실입니다. 담당자가 퇴사하면 그 기억은 함께 사라집니다. 클라우드 시대에는 이 공백을 메우기 위해 "옛날에 여기서 일하던 사람에게 전화"하는 비상상황이 실제로 벌어질 수 있습니다. 'wishbone12' 같은 오래된 패스워드를 전직 개발자에게 다시 묻는 장면이 웃긴 동시에 이상하게 낯익게 느껴지는 이유입니다.

국내 환경에서도 상황은 크게 다르지 않습니다. 오래된 공공기관 시스템, 금융권 코어 시스템, 병원 전산 등은 특정 벤더나 특정 개발자의 코드에 과도하게 의존합니다. 레거시를 걷어내는 프로젝트는 매번 예산과 정치적 부담에 막힙니다. 이 지점에서 "이 정도면 그냥 두자"라는 선택이 반복되고, 언젠가 한 번의 장애로 통째로 청구서를 받게 됩니다.

AB 테스트, 내부 툴, 그리고 '임시'가 영구가 되는 순간

이야기 속에서 언급된 AB 테스트와 내부 자동화 도구 사례는 많은 조직이 공유하는 현실입니다. 성과를 빨리 내기 위해 "일단 실험부터 하고 보자"라는 문화가 자리 잡으면, 실험을 위해 만든 임시 코드가 프로덕션에 그대로 남는 경우가 많습니다. 실험이 끝났을 때 "정리해서 다시 짜자"라는 계획은 항상 다음 분기 우선순위에 밀립니다.

문제는 이 임시 코드 위에 또 다른 임시 코드가 쌓인다는 점입니다. 설정을 자동으로 배포해주는 툴, 특정 환경을 빠르게 초기화해주는 스크립트, 테스트 환경을 한 번에 지우는 유틸리티가 대표적입니다. 구글 클라우드에서 호주 연금 데이터를 날려버린 사건도 이 맥락과 닮았습니다. 테스트용으로 만든 자동 삭제 도구가 프로덕션과 같은 저장소에 적용되며, 백업까지 함께 삭제되었습니다.

개발자 입장에서는 이런 도구가 없으면 업무가 불가능에 가깝습니다. 그러나 조직 차원에서 보면, 이 도구들을 감시하고 통제할 구조가 없는 상태에서 사용 범위만 넓히는 것은 사실상 자폭 버튼을 곳곳에 설치하는 일입니다. 저라면 새로운 자동화 스크립트를 도입하는 시점마다, "이것이 잘못 작동할 때 영향을 받는 리소스 목록"을 먼저 적어보겠습니다. 귀찮더라도 그 리스트가 정리되지 않으면 프로덕션 접근은 막는 편이 안전합니다.

이 이야기에서 누가 무엇을 배워야 하는가

이런 이야기는 개발자에게는 너무 익숙해서 오히려 위기감을 덜 느끼기 쉽습니다. 반대로 비개발자에게는 "기술자들 세계의 특이한 해프닝" 정도로 느껴질 수 있습니다. 그러나 클라우드에 의존하는 비즈니스를 운영한다면, 어느 쪽이든 그냥 웃고 넘기기에는 위험한 신호입니다.

조직에게 유리한 사람, 그리고 거의 도움 되지 않는 사람

클라우드 인프라 의존도가 높은 스타트업이나 중견 기업의 의사결정자에게 이런 이야기는 상당히 유익합니다. 개발팀에 전적으로 맡겨둔 인프라가 실제로 어떤 방식으로 위험을 축적하는지 감을 잡을 수 있기 때문입니다. 기술적 세부 사항까지 이해할 필요는 없습니다. 다만 "우리도 개인용 스크립트가 프로덕션에서 돌고 있을 수 있다"라는 가정만으로도 점검할 항목이 명확해집니다.

반면, 단순 소비자 입장에서는 이 이야기가 당장 행동으로 이어지기는 어렵습니다. "클라우드가 이 정도로 불안하다면 나 혼자 무엇을 할 수 있는가"라는 무력감만 커질 수 있습니다. 개인이 할 수 있는 일은 결국 중요한 데이터의 이중 백업, 서비스 장애에 대비한 비즈니스 플랜 정도입니다. 그래서 일반 사용자라면 이 이야기를 개발 문화 비판이 아니라, "어떤 서비스든 단일 장애 지점을 믿고 모든 것을 걸면 안 된다"라는 상식적 교훈 정도로 받아들이는 편이 낫습니다.

지금 당장 할 수 있는 첫 번째 행동

조직 입장에서 가장 먼저 할 수 있는 일은 "임시"라는 이름이 붙은 것을 전수 조사하는 일입니다. 임시 스크립트, 내부용 툴, 실험적 배포 파이프라인, 개인 계정으로 관리되는 접근 권한이 여기에 해당합니다. 이 중에서 프로덕션 리소스에 직접 영향을 줄 수 있는 것들을 분리하고, 최소한의 승인 절차와 로그를 붙이는 것만으로도 리스크를 크게 줄일 수 있습니다.

개발자 개인에게 필요한 것도 비슷합니다. 나만 쓰려고 만든 코드가 언젠가 팀의 표준 도구가 될 수 있다는 전제를 머릿속에 두는 태도입니다. 코드 상단에 의도와 한계를 명확하게 적고, 위험한 동작에는 확인 단계를 넣는 습관이 중요합니다. 자동 삭제, 대량 변경, 설정 초기화 같은 기능에는 추가적인 보호 장치를 넣어야 합니다. CLI 하나로 수백 대 인스턴스를 지우는 명령어가 너무 쉽게 실행된다면, 언젠가 누군가는 실수로 그것을 실행합니다.

마지막으로, 서비스 이용자와 기업 모두에게 필요한 인식이 하나 있습니다. "클라우드는 완벽하게 자동화된 미래 기술"이 아니라, 여전히 사람의 실수와 귀차니즘, 조직 정치 위에서 굴러가는 거대한 시스템이라는 인식입니다. 이 사실을 인정하는 순간, 장애 뉴스가 나왔을 때 분노보다 질문이 먼저 떠오릅니다. "이번에는 어떤 임시방편이 영구 설정으로 굳어졌을까." 이 질문을 던지는 조직만이 비슷한 사고를 자기 차례가 오기 전에 줄일 수 있습니다.

출처 및 참고 :