아마존이 운영을 대하는 방식

1편: 고장 나야 움직인다

이 글은 Pragmatic Engineer 뉴스레터에서 발행된
『Working at Amazon as a software engineer – with Dave Anderson』 인터뷰를 바탕으로 작성되었습니다.
12년간 Amazon에서 일한 엔지니어링 디렉터의 회고를 통해, 제가 직접 경험한 실무 상황과 겹치는 지점을 돌아보며 AI 시대의 소프트웨어 설계와 엔지니어링 문화에 대해 사유해 본 글입니다.

세상에서 가장 많은 장애를 겪는 회사

아마존은 세상에서 가장 많은 장애를 겪는 회사일지도 모릅니다.
반대로 말하면, 세상에서 가장 많은 장애를 가장 진지하게 다루는 회사이기도 합니다.

이번 Pragmatic Engineer 팟캐스트에서, 12년간 아마존에서 SDM(Senior Development Manager)으로 일한 Dave Anderson의 이야기를 들으며, 저는 이렇게 생각했습니다.
‘고장 났을 때 어떻게 반응하는가’가 그 조직의 철학을 가장 적나라하게 보여준다.

장애가 발생했을 때, VP, SVP가 직접 콜에 들어오고,
백본 네트워크가 어디서 터졌는지 클라우드 제공업체보다 먼저 파악해 주는 엔지니어링 팀.
문제의 중심에 있는 사람에게 직접 책임과 권한을 부여하고,
그 사람이 고치지 않으면 아무도 고칠 수 없는 구조.
그리고 장애가 발생한 뒤에는 기능 개발을 멈추고 원인을 분석하고 재설계에 들어가는 문화.

한편으로는 "이게 진짜 가능한가?" 싶은 생각도 들었지만,
저 역시 AI 제품을 운영하며 겪었던 ‘온콜 지옥’의 기억과 겹치면서 고개를 끄덕이게 되었습니다.
코드가 완성되는 순간은 끝이 아니라 시작이며,
실서비스를 운영하는 순간부터 ‘일이 터질 준비’가 필요하다는 것을
뼈저리게 배운 적이 있기 때문입니다.

문제를 고치는 게 아니라, 문제를 피하는 시스템을 만든다

Dave는 말합니다.

“잘 운영되는 팀이라면, 새벽 3시에 또다시 호출되는 일이 반복된다면,
그 주엔 기능 개발을 멈추고 바로 리팩토링과 구조 개선에 들어갑니다.”

이 말이 인상 깊었던 이유는,
제가 일하는 환경에서는 종종 ‘문제는 터지고,

급한 불만 끈 뒤 다시 기능 개발로 돌아가는’ 방식이 반복되었기 때문입니다.

누구도 의도하진 않았지만, 결국 책임이 흩어지고, 아무도 전체를 책임지지 않는 구조가 되어 있었습니다.

아마존이 “코드를 작성한 사람이 운영 책임까지 진다”는 철학을 강조하는 이유도 여기에 있는 것 같습니다.

개발자로서 우리가 배워야 할 것은 단지 빠르고 정확한 코드 작성이 아니라,
장애가 발생했을 때 무엇을 멈추고,
어떻게 문제의 근본 원인을 찾아가며,
다시는 같은 문제가 생기지 않도록 설계하는가에 대한 집요함입니다.

작지만 강한 팀을 위한 기본기

아마존은 개발자에게 작고 독립적인 팀에서 최대한 많은 권한과 책임을 주는 구조를 지향합니다.

어떤 언어를 쓸지,
어떤 배포 방식을 선택할지,
어떤 모니터링 체계를 설계할지조차
팀 내에서 자율적으로 결정한다고 합니다.

Dave는 이를 두고 “작은 스타트업 수천 개가 붙어 있는 것과 같다”라고 표현했습니다.

이 말에 깊이 공감했습니다.

저 역시 스타트업과 사이드 프로젝트를 동시에 운영하면서
가장 크게 느낀 어려움은 바로 ‘운영의 단단함’을 갖추는 일이었습니다.

기능을 빠르게 붙이는 건 어렵지 않습니다.
하지만 장애가 나면 즉시 대응하고,
다음 장애를 막을 수 있도록 구조를 리팩터링 하는 능력은 쉽게 쌓이지 않습니다.

아마존에서 온콜과 장애 대응이 단순한 고통이 아니라
‘운영을 배운다’는 관점으로 인식되는 이유는,
이 경험들이 개발자의 기술적 성장뿐 아니라,
전체 시스템을 바라보는 시야를 키워주기 때문일 것입니다.

그래서 나는 다시, '운영'을 설계하고 싶어졌다

Amazon의 이야기를 들으면서 저는 결국
개발자의 성장은 ‘운영 경험’을 통해 완성된다는 사실을 다시금 느꼈습니다.

코드를 잘 짜는 것보다,
내가 만든 시스템이 실제 환경에서 어떻게 버티고, 무너지고, 복구되는지를
끝까지 책임지는 경험이야말로
개발자를 진짜 성장시키는 지점이기 때문입니다.

아마존처럼 거대한 조직이든,
세 명이 함께하는 사이드 프로젝트든,
결국 우리가 만들어야 하는 것은 똑같습니다.

문제가 터졌을 때 책임을 전가하지 않는 문화

문제가 반복되지 않도록 구조를 바꾸는 용기

그 과정에서 함께 성장하는 팀

기능을 빠르게 붙이는 것이 중요한 시기가 분명히 있습니다.
하지만 언젠가는 그 위에 ‘단단한 운영 설계’가 쌓이지 않으면,
팀도, 제품도 쉽게 무너질 수 있습니다.

끝으로

Dave의 마지막 말이 계속 마음에 남습니다.

“성공적인 사람은 문제를 피하지 않는다. 문제 한가운데로 뛰어든다.
그리고 그 안에서 더 나은 시스템을 만든다.”

그렇다면,
우리는 어떤 문제 속으로 들어가야 하고, 그 안에서 무엇을 다시 설계해야 할까요?
조직일 수도 있고, 관계일 수도 있으며, 나의 일하는 방식일 수도 있습니다.

지금 당신을 둘러싼 시스템은,
내가 원하는 방향으로 나를 성장시키고 있나요?

저는 오늘, 다시 제 일의 구조를 설계해보려 합니다.
조금 더 단단하게. 그리고 조금 더 정직하게.