AWS 20년차 엔지니어가 말하는 '그건 내 일이 아닌데'라고 말하지 않는 문화

20년이면 강산이 변하는데, AWS에서 20년이라니

AWS가 처음 서비스를 시작한 게 2006년이에요. 그때부터 지금까지 약 20년간 AWS와 함께해온 엔지니어가 자신의 경험을 회고하는 글을 올렸는데요, 글의 제목이 인상적이에요. "20 years on AWS and never not my job" — 직역하면 "AWS에서 20년, 한 번도 '내 일이 아니다'라고 한 적이 없다"는 뜻이에요.

이 글을 쓴 사람은 Colin Percival인데요, 보안 분야에서 꽤 유명한 엔지니어예요. FreeBSD 보안 담당관을 오랫동안 역임했고, Tarsnap이라는 암호화 백업 서비스를 만든 사람이기도 해요. 이런 배경을 가진 엔지니어가 20년간의 경험을 돌아보면서 이야기하는 핵심 주제는 바로 오너십(ownership), 즉 주인의식이에요.

"그건 내 담당이 아닌데요"라는 말의 문제

개발 조직에서 가장 위험한 말 중 하나가 "그건 내 일이 아닌데요"예요. 물론 업무 범위를 명확히 하는 건 중요하지만, 이 말이 문화로 자리 잡으면 문제가 커져요. 누군가의 담당이 아닌 영역에서 버그가 발생하면, 서로 미루다가 고객이 피해를 보는 상황이 생기거든요.

AWS에는 유명한 리더십 원칙(Leadership Principles)이 있는데요, 그중 하나가 바로 "Ownership"이에요. 이게 뭐냐면, "리더는 자기 팀의 범위를 넘어서 행동한다. '그건 내 일이 아니야'라고 절대 말하지 않는다"는 원칙이에요. Colin은 이 원칙을 단순한 슬로건이 아니라 실제로 20년간 실천해온 방식으로 이야기해요.

실제 사례를 보면, 자기 담당 서비스가 아닌 곳에서 문제를 발견했을 때 "해당 팀에 티켓 넣어놓을게요"로 끝내는 게 아니라, 직접 원인을 파악하고 수정 패치까지 만들어서 해당 팀에 전달하는 식이었다고 해요. 이건 단순히 성실한 게 아니라, 문제 해결의 속도와 품질이 완전히 달라지는 접근이에요.

오너십이 실제로 코드 품질에 미치는 영향

이런 문화가 왜 중요한지 기술적인 관점에서 생각해볼게요. 대규모 분산 시스템에서는 장애의 원인이 하나의 서비스에만 있는 경우가 드물어요. 서비스 A의 타임아웃 설정이 서비스 B의 재시도 로직과 맞물려서 서비스 C에 과부하를 일으키는 식의 복합적인 문제가 많거든요.

이런 상황에서 "내 서비스는 정상이에요"라고 말하는 문화와 "전체 시스템 관점에서 내가 뭘 할 수 있을까"라고 생각하는 문화는 장애 대응 시간에서 엄청난 차이를 만들어요. AWS가 20년간 대규모 클라우드 인프라를 운영하면서 쌓은 노하우 중 상당 부분은 이런 문화적 측면에서 나온 거예요.

Colin은 특히 보안 분야에서 이 원칙이 더 중요하다고 강조해요. 보안 취약점은 팀 경계를 신경 쓰지 않거든요. 인증 서비스의 취약점이 결제 시스템에 영향을 미칠 수 있고, 네트워크 설정의 문제가 데이터 유출로 이어질 수 있어요. 그래서 보안 엔지니어는 특히 "내 담당 영역"이라는 개념을 넓게 잡아야 한다는 거예요.

한국 개발 문화와의 비교

한국 IT 업계에서도 오너십에 대한 논의가 많은데요, 현실은 좀 복잡해요. "주인의식을 가져라"라는 말이 때로는 "야근을 감수해라" 또는 "네 업무가 아니어도 해라"라는 뜻으로 변질되기도 하거든요.

여기서 중요한 구분이 있어요. 건강한 오너십은 권한과 책임이 함께 가는 거예요. 문제를 발견하고 직접 고칠 수 있는 권한이 있어야 진짜 오너십이 가능해요. 단순히 "더 열심히 해라"가 아니라, 코드에 대한 접근 권한, 의사결정 자율성, 그리고 실패에 대한 심리적 안전성이 뒷받침되어야 하는 거예요.

AWS의 Two-Pizza Team(피자 두 판으로 먹일 수 있는 규모의 팀) 구조가 바로 이런 맥락이에요. 작은 팀이 자기 서비스에 대해 전체적인 권한과 책임을 갖는 구조인데요, 이 구조가 있어야 "내 일이 아닌 것도 내 일"이라는 마인드가 자연스럽게 작동해요. 큰 조직에서 권한 없이 책임만 지우면 번아웃만 오거든요.

주니어 개발자가 가져가면 좋을 포인트

이 이야기를 읽고 "나도 모든 걸 다 해야 하나"라고 부담 느낄 필요는 없어요. Colin이 20년 경력의 시니어라는 걸 감안해야 해요. 주니어 단계에서의 오너십은 좀 다른 형태로 실천할 수 있어요.

예를 들어, 코드 리뷰에서 자기 담당이 아닌 PR도 가끔 들여다보는 것, 장애가 났을 때 "나는 관련 없으니까" 하고 빠지지 않고 옆에서 배우는 것, 문서가 부족한 부분을 발견하면 간단하게라도 정리해두는 것. 이런 작은 행동들이 쌓이면 시스템 전체를 이해하는 개발자로 성장하는 밑거름이 돼요.

특히 온콜(on-call) 경험이 있다면 공감할 텐데요, 새벽 3시에 알람이 울렸을 때 "이거 내 서비스 문제 아닌데"라고 확인하고 다시 자는 것과, 일단 전체 상황을 파악하고 담당팀에 의미 있는 정보를 전달하는 것은 조직에 주는 가치가 완전히 달라요.

마무리

20년간 하나의 플랫폼에서 일하며 쌓은 이 엔지니어의 교훈은 결국 기술적 역량만큼 중요한 게 문제를 대하는 태도라는 거예요. 도구와 언어는 계속 바뀌지만, "내 범위 밖의 문제도 내 문제로 바라보는 자세"는 시대가 바뀌어도 가치 있는 엔지니어의 공통점이에요.

여러분의 조직에서 오너십 문화는 어떤가요? 건강한 오너십과 과도한 업무 떠넘기기의 경계는 어디라고 생각하시나요?