AWS 최고 엔지니어 Marc Brooker, 3000건 이상의 사고 경험과 AI 시대 소프트웨어 엔지니어링의 변화에 대해 말하다

이 영상은 AWS의 최고 엔지니어인 Marc Brooker가 3,000건 이상의 클라우드 시스템 사고 후 분석(postmortem) 경험을 바탕으로 얻은 기술적 통찰과, AI 시대에 소프트웨어 엔지니어링이 어떻게 변화하고 있는지에 대한 깊이 있는 이야기를 나눈 인터뷰입니다. 그는 중요한 문제를 찾아내는 방법, 캐시의 단점, 온콜(on-call) 근무의 중요성, 그리고 엔지니어로서 글쓰기의 가치에 대해 설명하며, 주니어 및 시니어 엔지니어들에게 AI 시대에 필요한 역량과 적응 전략에 대한 조언을 아끼지 않습니다.

1. 중요한 문제를 찾는 방법 🤔

Marc Brooker는 커리어 초기에 시니어 엔지니어들이 자신보다 훨씬 더 큰 영향력을 발휘하는 이유를 궁금해했다고 합니다. 단순히 더 많은 시간 일하거나 더 많은 코드를 작성하는 것보다 작업의 방향성, 즉 어떤 문제를 해결하는지가 훨씬 더 중요하다는 것을 깨달았죠. 그는 중요한 문제를 찾는 방법을 세 가지 관점에서 설명합니다.

고객의 목소리에 귀 기울이기: 고객들이 AWS 서비스를 사용하면서 겪는 어려움, 투자하는 분야, 그리고 시간을 낭비하고 싶지 않은 부분을 경청하는 것이 중요하다고 말합니다.

"저는 AWS 고객들과 많은 시간을 보내면서 그들이 우리 분야에서 여전히 어렵다고 생각하는 것, 무엇에 투자하고 있는지, 어디에 시간을 보내고 싶지 않은지에 대해 경청합니다."
기술 트렌드 파악하기: 네트워크, 스토리지, GPU 등 기술의 발전 속도를 주시하며, 이러한 기술 발전이 새로운 가능성을 어떻게 열어주는지 파악하는 것이 필요합니다.
세상의 큰 변화 이해하기: 산업과 세상이 어떻게 변화하는지 큰 그림을 보고, 이러한 변화의 순간에 새로운 것을 만들고 문제를 인식할 기회가 생긴다고 강조합니다.

이러한 접근 방식을 통해 Marc는 2020년 람다(Lambda) 팀에서 일할 당시, 고객들이 서버리스와 컨테이너를 이용한 개발에 열광했지만, 관계형 데이터가 이 패러다임에 잘 맞지 않는다는 문제점을 발견했다고 합니다. 이를 계기로 그는 오로라(Aurora) 팀에 합류하여 Aurora Serverless와 DSQL을 개발하는 데 기여했고, 이는 고객의 니즈와 기술 트렌드가 완벽하게 결합된 성공적인 사례가 되었습니다.

2. 3,000건 이상의 포스트모템(Postmortem)에서 얻은 교훈 📝

Marc는 15년간 온콜(on-call) 근무를 하며 분산 시스템 구축에 대한 실질적인 지식을 얻었다고 합니다. 그는 온콜 근무를 통해 시스템이 실제로 어떻게 작동하고, 고객들이 예상치 못한 방식으로 시스템을 사용할 때 어떤 문제가 발생하는지 배우며, 시스템을 더욱 견고하게 만드는 방법을 고민하게 된다고 설명합니다.

온콜 근무의 가치: 온콜 근무는 단순히 반복적인 문제 해결이 아니라, 시스템의 작동 방식, 고객의 사용 패턴, 그리고 예상치 못한 문제 발생 시 시스템의 거동을 이해하는 데 매우 중요하다고 강조합니다. 반복되는 문제는 자동화로 해결하고, 심층적인 문제는 깊이 파고들어 시스템을 개선하고 지식을 공유해야 한다고 말합니다.

"온콜은 그런 것들을 배울 수 있는 최고의 방법 중 하나입니다. 시스템이 실제로 어떻게 작동하는지, 어떻게 행동하는지, 고객이 실제로 어떻게 사용하는지 볼 수 있는 최고의 방법입니다."
훌륭한 포스트모템의 조건:
1. 깊은 이해: 사건 발생의 모든 세부 사항을 깊이 있게 이해하는 것이 중요합니다. 로그, 지표, 관찰 가능성, 시뮬레이션 등을 통해 무슨 일이 일어났는지 정확히 파악해야 합니다.
2. 근본 원인 분석: 단순한 코드 버그를 넘어 '왜' 이런 일이 발생했는지 여러 단계에 걸쳐 질문해야 합니다. 테스트와 검증 과정에서 놓친 부분은 없는지, 시스템 행동에 대한 가정이 잘못되지는 않았는지 등 더 깊은 층위의 원인을 찾아야 합니다.
3. 다차원적 해결책: 근본 원인에 대한 전술적인 수정뿐만 아니라, 기술, 조직, 제품 전반에 걸친 광범위한 해결책을 모색해야 합니다. 여러 포스트모템에서 반복되는 패턴이 있다면, 서비스나 라이브러리를 구축하여 해당 문제의 근본적인 해결을 시도해야 합니다.
  
  "훌륭한 포스트모템은 근접 원인에 대한 수정뿐만 아니라 기술, 조직, 제품에 대한 광범위한 수정 사항도 식별합니다."
AWS의 포스트모템 문화: AWS는 주간 회의를 통해 엔지니어와 리더들이 모여 포스트모템을 검토하고, 거기서 얻은 교훈을 회사 전체에 적용한다고 합니다. 이 과정은 AWS 성공의 핵심 요인 중 하나이며, 시스템 운영 방식과 이유를 깊이 이해하는 데 도움을 줍니다.

3. 캐시(Cache)는 왜 나쁠까? 😱

시스템 설계 시 흔히 "캐시를 적용하라"는 조언을 듣지만, Marc는 캐시가 나쁜 경우도 있다고 말합니다.

캐시의 이점과 단점: 캐시는 컴퓨터 과학의 핵심 개념인 시간적/공간적 지역성을 활용하여 시스템 속도를 높이고 확장성을 개선하는 데 매우 효과적입니다. 하지만 분산 시스템에서 캐시는 두 가지 모드를 가지는데, 하나는 캐시가 제대로 작동하여 시스템이 빠르고 건강한 상태인 경우이고, 다른 하나는 캐시가 비어 있거나 잘못된 데이터를 포함하여 시스템이 느려지거나 다운되는 경우입니다.
준안정 실패(Metastable Failures)의 위험: 캐시가 비거나 잘못된 데이터를 포함하는 경우, 백엔드는 처리되지 않은 트래픽으로 인해 부하가 걸리고, 고객은 실망하게 됩니다. 이러한 상태는 준안정 실패라고 불리며, 시스템이 안정적으로 다운된 상태에서 스스로 회복하기 어렵게 만듭니다. 예를 들어, 과도한 트래픽이 데이터베이스에 부하를 주거나 네트워크를 포화시켜 캐시를 다시 채우는 것을 방해할 수 있습니다.
캐시의 대안: Marc는 이러한 준안정 실패를 피하기 위해 캐시를 가능한 한 피하는 것을 선호한다고 말합니다. 대신, 데이터의 완전한 물질화된 뷰(complete materialized view)를 사용하거나, 확장 가능한 백엔드(scalable backend)를 직접 사용하여 캐시 없이도 필요한 성능을 달성하도록 유도해야 한다고 조언합니다. DSQL의 경우, 스토리지 계층 자체가 데이터베이스의 모든 행을 포함하는 완전한 캐시 역할을 하여 캐시가 비어있는 문제를 방지합니다. 또한, 오로라(Aurora)와 같이 리더가 장애 조치 대상에게 지속적으로 캐시할 데이터를 알려주어 장애 조치 시 캐시가 "웜(warm)" 상태를 유지하도록 하는 방법도 있습니다.

"저는 가능한 한 캐싱을 피하는 팀을 선호합니다. 데이터의 완전한 물질화된 뷰를 가지는 패턴을 선호합니다."
준안정 실패의 빈도와 영향: 준안정 실패는 자주 발생하는 것은 아니지만, 발생할 경우 대규모 서비스 중단, 긴 복구 시간, 복잡한 문제 해결을 야기하는 경우가 많다고 설명합니다. 따라서 업계와 엔지니어 커뮤니티는 이러한 현상을 깊이 이해하고 대비해야 한다고 강조합니다.

4. AI가 소프트웨어 엔지니어링을 어떻게 바꿀까? 🤖

Marc는 AI가 소프트웨어 엔지니어링의 미래에 미칠 영향에 대해 흥미로운 통찰을 제시합니다.

소프트웨어의 무한한 기회: 소프트웨어는 여전히 공급이 제한된(supply-constrained) 상태이며, 세상에 더 많은, 더 크고, 더 나은, 더 개인화된 소프트웨어에 대한 기회는 무궁무진하다고 말합니다. AI는 이러한 소프트웨어 개발의 경제학을 변화시키고 있으며, 이는 소프트웨어 개발자들이 더 많은 것을 만들 수 있는 엄청난 기회가 될 것이라고 강조합니다.

"우리는 소프트웨어가 세상에 미칠 영향의 시작을 겨우 보았을 뿐입니다. 더 많은 소프트웨어, 더 큰 소프트웨어, 더 나은 소프트웨어, 더 개인화된 소프트웨어에 대한 기회가 너무 많습니다."
AI 시대의 소프트웨어 개발 경력:
- "오래된 방식": 아날로그 회로처럼, 과거의 기술과 언어로 소프트웨어를 개발하는 방식은 여전히 존재하지만, 점차 틈새시장(niche)으로 변모할 것이라고 예상합니다. 하지만 여전히 경제적 기회는 있을 것이라고 덧붙입니다.
- "새로운 방식" (주류): AI 기반 개발, 에이전트 개발, 명세 기반 개발 등 새로운 기술을 적극적으로 수용하는 방식이 주류가 될 것이며, 이곳에서 대부분의 경력과 경제적 기회가 창출될 것이라고 예측합니다.
- 실제 세계와 소프트웨어의 결합: 소프트웨어가 물리적인 세계와 접목되는 분야에서는 새로운 기술과 관행을 적용하는 방식에 대한 흥미로운 질문들이 많이 생겨날 것이라고 말합니다.
주니어 엔지니어들을 위한 조언:
- 고객과 비즈니스 이해: 코드를 작성하는 것만큼이나 고객, 비즈니스, 시스템, 경제학에 대한 이해가 중요해질 것입니다. 과거에는 시니어 엔지니어의 역할이었던 이러한 이해가 이제는 주니어 엔지니어들에게도 요구될 것이라고 예상합니다.
- 순수한 코딩보다 문제 해결: 단순히 코딩만 하는 역할은 점차 줄어들고, 고객의 문제와 비즈니스 컨텍스트를 이해하고 함께 해결하는 역할이 더 중요해질 것이라고 말합니다.
- 깊은 기술적 지식의 레버리지: 최적화 문제, 인프라 문제, 데이터베이스 등 특정 기술 분야에 깊은 전문성을 가진 엔지니어들은 AI 시대에 그 지식을 소프트웨어 개발에 활용할 수 있는 더 큰 기회를 얻을 것입니다. 과거에는 불필요한 번거로움이 많았지만, 이제는 AI 덕분에 깊은 지식을 활용하기가 훨씬 쉬워졌다고 설명합니다.
- 학습과 멘토링의 중요성: 대학교 졸업생들이 모든 지식을 가지고 있을 것이라고 기대하지 않으며, 조직은 주니어 엔지니어들이 새로운 기술과 고객 커뮤니케이션 능력을 배울 수 있도록 가이드라인, 멘토링, 피드백을 제공해야 한다고 강조합니다.
  
  "이것은 고객에 대한 이해, 비즈니스에 대한 이해, 경제학에 대한 이해, 시스템에 대한 이해를 요구합니다. 그리고 이것은 거의 시니어 엔지니어의 역할에서 벗어나..."
시니어 엔지니어들을 위한 조언:
- 현업에 복귀하기: 시니어 엔지니어들은 과거의 경험과 지식에만 의존하지 않고, 새로운 기술과 변화하는 소프트웨어 개발 방식을 깊이 이해하기 위해 다시 현업으로 돌아가 직접 코딩해야 한다고 강조합니다.
  
  "정말 중요하다고 생각하는 것은 여러분이 다시 구축해야 한다는 것입니다. 다시 현업에 뛰어들어야 합니다."
- 도구 활용 및 호기심: 새로운 도구들이 개발자들이 훨씬 더 큰 영향력을 발휘할 수 있게 해주므로, 호기심을 가지고 새로운 도구를 배우고 활용해야 합니다. 과거에는 회의에 참석하고 똑똑하게 보이려 했다면, 이제는 배우고, 만들고, 고객의 문제를 해결하며, 새로운 기술을 탐구하는 본래의 열정을 되찾아야 한다고 말합니다.
- 현실에 대한 이해: AI 시대에는 직접 경험하지 않으면 새로운 기술에 대한 이해가 매우 부정확할 수 있습니다. 화려한 직함이나 경력을 가진 사람이라도 겸손하게 새로운 것을 배우려는 태도가 필수적이라고 강조합니다.
  
  "지금 이 순간, 직접 하지 않으면 그것에 대한 당신의 의견은 완전히 틀릴 가능성이 매우 높습니다."

5. 왜 엔지니어는 글을 써야 할까? ✍️

Marc는 엔지니어로서 글쓰기가 엄청난 힘을 가진다고 강조합니다.

전문 지식의 확장: 글쓰기는 머릿속의 아이디어를 세상과 공유하고, 자신의 전문 지식을 시간과 공간을 넘어 확장하는 강력한 도구입니다. 좋은 제품을 만들거나 멘토링을 통해 지식을 공유하는 것도 좋지만, 글쓰기는 훨씬 더 많은 사람들에게 장기간 영향을 미칠 수 있다고 설명합니다.

"글쓰기는 공간과 시간에서 당신의 전문 지식의 영향력을 확장시켜줍니다."
사고의 명확화: 글쓰기는 사고의 명확성을 높이는 데 탁월합니다. 단순히 말하거나 슬라이드를 만드는 것과 달리, 글을 쓰는 과정은 아이디어를 깊이 있게 고민하고 구조화하도록 강제합니다. 이는 아마존의 문화적 핵심 가치 중 하나이기도 합니다. 그는 스스로의 생각을 정리하기 위해 누구에게도 공유하지 않을 문서를 쓰기도 한다고 말합니다.

"글쓰기는 말하기, 슬라이드 데크 만들기 등과는 다른 수준의 정신적 명확성을 강요합니다."
효율적인 의사소통 및 미래 대비:
- 협업 및 역사 기록: 글쓰기는 복잡한 기술 결정을 문서화하여 팀원들이 이해하고, 미래의 팀원들이 시스템을 개선할 때 참조할 수 있는 중요한 아티팩트를 제공합니다.
- 의도 파악: 중요한 기술 결정에 대한 문서화를 통해, 나중에 시스템을 개선하는 사람들이 어떤 결정이 신중하게 고려되었고 어떤 결정이 임의적이었는지 파악할 수 있도록 돕습니다. 이는 불필요한 재작업을 줄이고, 깊이 있는 사고가 필요한 부분에 집중할 수 있게 합니다.

6. 가시성과 전문성 사이의 균형 ⚖️

Marc는 '네 가지 취미와 겉보기 전문성(hobbies and apparent expertise)'이라는 블로그 게시물을 통해 '실행(doing) 대 논의(discussing)'와 '취미(hobby) 대 장비(gear)'의 2x2 매트릭스를 제시하며, 전문성과 가시성 사이의 미묘한 균형에 대해 이야기합니다.

과도한 '실행'의 단점: 끊임없이 코딩만 하는 엔지니어는 엄청난 전문성을 가질 수 있지만, 외부와의 소통이 부족하여 자신의 가치를 제대로 알리기 어렵습니다. 또한, 항상 고개를 숙이고 일하면 정말로 중요한 문제가 무엇인지 놓치고 엉뚱한 일을 하고 있을 가능성도 있다고 지적합니다.

"하루 종일 IDE에만 머리를 박고 있다면, 매우 높은 확률로 잘못된 일을 하고 있을 수 있습니다."
과도한 '논의'의 단점: 반대로, 이야기하고 소통하는 데만 집중하는 엔지니어는 높은 가시성을 얻지만, 실제로는 코딩 능력이나 기술적 깊이가 부족할 수 있습니다. 이런 사람들의 의견은 현실과 동떨어져 있을 가능성이 높습니다.
이상적인 균형: Marc는 '실행 75%, 소통 25%' 또는 '실행 80%, 소통 20%' 정도의 균형이 자신에게 가장 적합했다고 말합니다. 이 범위 안에서 엔지니어들은 실질적인 전문성을 유지하면서도 자신의 지식을 공유하고 영향력을 확대할 수 있습니다.
과대평가 vs. 과소평가: 커리어에 있어 과대평가되는 것과 과소평가되는 것 중 어떤 것이 더 좋으냐는 질문에 Marc는 장기적으로 봤을 때 과소평가되는 것이 더 낫다고 답합니다. 과대평가는 일시적으로 기분 좋을 수 있지만 지속 가능하지 않으며, 현실과 동떨어진 채로는 오래가지 못한다는 것이죠. 그는 스포츠 선수나 장인처럼 자신의 실제 능력을 속일 수 없는 분야의 예를 들며, 결국에는 실력이 드러난다고 말합니다.

"장기적으로 볼 때, 그 용어를 사용한다면 과소평가되는 것이 더 낫다고 생각합니다. 과대평가되는 것은 순간적으로 기분 좋을 수 있지만, 지속 가능하지는 않습니다."

7. 존경하는 AWS 엔지니어와 추천 도서 📚

Marc는 AWS에서 많은 훌륭한 사람들과 일할 수 있었던 것이 큰 행운이라고 말하며, 특히 Elva Muan을 존경하는 인물로 꼽습니다. Elva는 S3 설계의 핵심 기여자이자, Paxos 논문의 세부 사항을 깊이 있게 이해하면서도 클라우드 전략과 같은 최고 경영진 수준의 논의를 아우를 수 있는 깊이와 폭넓은 시야를 가진 사람이었다고 합니다.

기술 서적으로는 다음을 추천합니다:

Martin Kleppmann의 분산 시스템 관련 서적: 분산 시스템을 구축하는 모든 사람에게 적극 추천합니다.
Hennessy and Patterson의 'Computer Architecture: A Quantitative Approach': 컴퓨터 아키텍처 전반을 다루는 유용한 서적입니다.

Marc는 책보다는 주로 기술 논문을 읽는 것을 선호하며, AI 도구(Claude 등)를 활용하여 논문을 요약한 뒤 깊이 있게 읽는다고 합니다. 또한, 오래된 기술 서적이나 논문에서도 놀라운 통찰을 얻을 수 있다고 강조합니다. 예를 들어, 람다(Lambda)에서 트래픽 관리 및 버스트 처리에 사용된 일부 알고리즘은 100년 전 Erlang이 전화 교환 센터 관리를 위해 연구했던 내용에서 비롯된 것이라고 설명합니다.

8. 젊은 시절의 자신에게 해주고 싶은 조언 🚀

만약 젊은 시절의 자신에게 돌아가 조언할 수 있다면, Marc는 "조금 더 대담해져라(Be a little bit bolder)"고 말할 것이라고 합니다. 그는 자신이 일했던 팀들을 정말 좋아했지만, 때로는 새로운 것을 배우고 성장할 수 있는 기회를 놓치지 않기 위해 조금 더 빨리 팀을 옮기거나 새로운 도전을 했어야 했다고 회상합니다.

그는 자신의 커리어 동안 네 번 정도 크게 조직을 옮겼지만, 다섯 번 또는 여섯 번 정도가 최적이었을 것이라고 추측합니다. 중요한 것은 자신이 무엇을 배우고 있는지, 누구에게서 배우고 있는지, 그리고 더 빠르게 배우고 성장할 수 있는 환경이 있는지를 끊임없이 고민하는 것입니다. 호기심을 따라 움직인 모든 순간이 개인적으로 만족스러웠고 가치 있는 움직임이었다고 말하며, 이는 결국 엔지니어로서 지속적인 성장을 위한 중요한 동력이 된다고 조언합니다.

마치며 ✨

Marc Brooker는 AI 시대의 급변하는 기술 환경 속에서 엔지니어들이 갖춰야 할 중요한 역량과 태도에 대해 깊이 있는 통찰을 제공했습니다. 특히, 단순히 코드를 작성하는 것을 넘어 고객의 문제를 이해하고, 깊이 있는 기술적 지식을 바탕으로 글을 통해 영향력을 확장하며, 끊임없이 배우고 현업에 참여하는 겸손한 자세가 성공적인 엔지니어 커리어를 위한 핵심임을 강조합니다. 그의 조언들은 새로운 기술의 파도 속에서 길을 찾는 모든 엔지니어들에게 큰 울림을 줄 것입니다. 🌊