Amazon Web Services Japan에서 약 12년간 일한 경험을 되돌아보며, 담당했던 역할과 배운 점, 그리고 퇴사에 이르게 된 이유를 정리한 개인적인 회고입니다.
URL: https://zenn.dev/moomindani/articles/5b4ee6d4f33b44
Title: Amazonでの12年間を振り返る
Amazon에서의 12년을 되돌아보며
이 글은 제가 Amazon에서 보낸 12년의 발자취를 되돌아본 개인적인 정리입니다. 자기 이야기가 굉장히 길어져 버렸으니, 바쁘신 분은 건너뛰셔도 됩니다.
@moomindani 입니다. 2014년 5월 1일부터 약 12년 가까이 일했던 Amazon Web Services Japan, G.K.[1] 를 2026년 1월 18일자로 퇴사했습니다.
현재는 Open Table Format Study Group (OTFSG) 운영도 하고 있습니다.
Amazon 이전에는 NTT데이터에 4년 조금 넘게 재직했고, Hinemos 라는 시스템 모니터링·잡 관리 오픈 소프트웨어의 개발과 지원 등을 담당했습니다.
2014년 5월 1일부터 2019년 7월 31일까지는 AWS 서포트 엔지니어 팀에서 클라우드 서포트 엔지니어로 일했습니다.
2019년 8월 1일부터는 AWS Glue 프로덕트 팀에서 빅데이터 아키텍트(후술)로 일했습니다.
클라우드 서포트 엔지니어(CSE)라는 역할은 AWS 서포트에 매일 들어오는 기술 문의에 대응하는 일입니다. AWS 서포트의 ‘안쪽 사람’이라는 느낌이죠.
2014년 입사 당시에는 AWS가 아직 30개 정도의 서비스만 갖고 있던 시기였고, 서포트 엔지니어 팀도 아직 소규모였기 때문에 모든 클라우드 서포트 엔지니어가 모든 AWS 서비스를 담당했습니다. 그 후 2015~2016년 즈음에 기술적 전문성을 축으로 한 프로파일 제도가 도입되면서, 각자의 전문 영역 서비스들을 주로 담당하게 되었습니다.
참고로 입사 직후의 AWS Summit Tokyo 2014 사진이 남아 있었는데, 당시 Amazon S3의 오브젝트 수는 총 2조 개였던 것 같습니다. re:Invent 2025의 Matt Garman CEO 키노트 세션에 따르면 2025년 시점에는 500 trillion objects, 즉 500조 개라고 하니, 격세지감이 있습니다.
입사 시에는 클라우드 서포트 엔지니어(L4)였고, 이후 두 번의 프로모션(승진)이 있어 2015년 10월에 클라우드 서포트 엔지니어(L5), 2017년 10월에 시니어 클라우드 서포트 엔지니어(L6)가 되었습니다. 참고로 L(Level)은 직무 레벨을 뜻하며 Amazon에서는 모든 사람에게 직무 레벨이 부여됩니다. 사내 이동에서는 직무 레벨 ±1 범위에서 도전할 수 있습니다.
클라우드 서포트 엔지니어 업무의 묘미는 기술적 폭과 깊이였습니다. 직접적으로 프로덕트를 개발하는 역할은 아니기 때문에, 고객과 관련된 기술을 폭넓게 만지고 학습할 기회가 많았습니다. NTT데이터 시절에는 직접 개발하던 Hinemos와 관련된 기술만 보면 되었기 때문에, 예를 들어 RDBMS는 PostgreSQL만 공부해도 충분했습니다. 반면 AWS에서는 당연히 MySQL도 Oracle도 SQL Server도 공부하게 됩니다. 거의 모든 기술이 업무와 연관될 수 있는 상황은 기술적 도전을 원하던 저에게 매우 잘 맞았고, 동기부여로 이어졌습니다. 또한 비슷한 혹은 변형된 트러블을 여러 번 마주칠 가능성이 높은 환경이었기에, 개인적으로도 조직적으로도 기술 지식 향상과 지견 공유에 대한 동기부여가 강했던 것도 좋은 환경이었다고 생각합니다. 이는 후술할 프로덕트 개발 팀과 비교해도 명확한 강점이자 장점이었습니다. 참고로 당시 이런 에피소드를 바탕으로 CodeZine에 공개된 인터뷰 기사가 일부에서 화제가 되었고, 그 이후 AWS 서포트 팀에 입사한 여러 엔지니어로부터 “그 기사 읽었어요!”라는 말을 들었던 것도 기쁜 추억입니다.
클라우드 서포트 엔지니어 시절에는 인력이 만성적으로 부족했기 때문에 신졸 채용을 새로 시작하거나, 인턴십을 시작하거나, 전국 대학을 돌며 홍보하는 등 다양한 시도를 했습니다. 당시 채용한 신졸 엔지니어들이 몇 년 뒤 팀의 주축이 되어가는 모습을 보는 것은 매우 감회가 깊었습니다. 채용 면접관으로서 100회가 넘는 면접을 했던 것도 값진 경험이었습니다.
제 커리어에 큰 영향을 준 것은 AWS Data Pipeline이라는 서비스입니다. 2026년 현재는 이미 유지보수(maintenance) 모드에 들어간 서비스지만, 간단히 말하면 데이터 복사나 이동을 위한 서비스로, EMR 클러스터 기동과 잡 실행을 스케줄링하는 구조였습니다. 당시 이 서비스를 프로덕션에 새로 도입한 일본 고객이 여러 곳 있었고, 이를 중심적으로 대응할 수 있는 스킬셋을 가진 서포트 엔지니어가 필요해져서 저는 자원했습니다. 이것이 제가 데이터 계열 커리어를 걷기 시작한 계기가 되었습니다. 이후 시애틀 출장에서 AWS Data Pipeline 프로덕트 팀과도 직접 대화했고, 당시 아직 출시 전이던 AWS Glue의 컨셉을 듣고 토론했던 것도 어제 일처럼 떠오릅니다. 앞서 말한 프로파일 제도가 도입된 타이밍에 빅데이터 영역의 초대 리더를 맡게 되었습니다. AWS Glue 런칭 후에는 서포트 엔지니어를 위한 전문가(SME: Subject Matter Expert) 프로그램을 준비해 트레이닝과 기술 면접 프로세스를 정비하기도 했습니다.
당시 Data Pipeline SME가 되었을 때 받은 메달 사진을 찾았습니다.
또 하나, 제 커리어에 큰 영향을 준 것은 2015년 라스베이거스에서 열린 AWS의 연례 컨퍼런스, AWS re:Invent 2015였습니다. 당시 매니저가 갑자기 “영어 할 수 있지?”라고 물어봤고, 어물쩍 답하는 사이 re:Invent 고객 대상 부트캠프 트레이닝과 Ask the Expert 부스의 Q&A 스태프로 배정되었습니다. 부트캠프 트레이닝은 준비 기간이 충분해서 콘텐츠도 충분히 파고든 뒤 당일을 맞을 수 있었고, 영어가 잘 통하지 않는 와중에도 어떻게든 기여할 수 있었던 것 같습니다. 반면 정말 큰 위기에 빠진 건 Ask the Expert 부스였습니다. 제가 부스에 도착하니 거기에는 고객의 긴 줄이… 전 세계에서 일부러 라스베이거스까지 모여 결코 싸지 않은 티켓값을 내고 상담을 하러 온 고객들의 기대치는 매우 높았고, 유스케이스 자료나 아키텍처 다이어그램을 가져온 분도 많았습니다. 그런 가운데 영어도 제대로 통하지 않는 제가 현장에서 척척 문제 해결을 할 리가 없고… 완전히 너덜너덜해져 낙담했던 기억이 강하게 남아 있습니다. “아, 영어를 못 하는 건 여기서는 치명적인 핸디캡이구나”를 통감했고, 어떻게든 영어로 무리해서라도 커뮤니케이션을 하려는 기개라든가 근성 같은 것이 이때 상황에 떠밀려 생겨난 것 같습니다.
앞서 언급한 AWS Glue SME 프로그램의 일환으로 아일랜드 더블린에서 해외 멤버들과 함께 트레이닝 콘텐츠를 만들던 때, 멤버 중 한 명이 “나 곧 프로덕트 팀으로 옮겨”라고 알려주었습니다. “그거 재밌겠다” 싶어서 덩달아 이런저런 우여곡절 끝에 2019년 8월 1일자로 AWS Glue 프로덕트 팀으로 이직(사내 이동)하게 되었습니다. 클라우드 서포트 엔지니어 일도 정말 즐거웠지만, 이 시점에 약 5년이 지나 어느 정도 다 해냈다는 느낌이 있었고, 직접 프로덕트를 개발·개선하는 활동을 통해 더 큰 임팩트를 내는 일을 해보고 싶었던 것이 주된 동기입니다.
우여곡절 부분을 조금만 설명하면… Amazon에는 글로벌로 다양한 오픈 포지션에 도전할 수 있는 사내 이동(Internal transfer) 제도가 있습니다. 이 프로덕트 팀 포지션은 미국 베이 에어리어 오피스에 연결된 오픈 포지션이었는데, 당시 프로덕트 팀의 General Manager와 협상해 도쿄로 헤드카운트를 옮겨 받았습니다. 해당 포지션 사내 면접을 통과해 이동에 이른, 그런 느낌입니다. 외국계 기업 경험이 있는 분들에겐 의외일 수도 있지만, 적어도 2019년 당시 Amazon에는 그런 예외적인 형태를 받아들이는 유연한 문화가 있었습니다. 이런 여러 상황에 도움을 받아, 원래 일본에 없던 포지션을 도쿄로 옮기고 도쿄에서 프로덕트 팀 소속으로 일하는 형태를 시작했습니다.
AWS Glue 프로덕트 팀에서 제 역할은 빅데이터 아키텍트(BDA)였습니다. 이는 Amazon Web Services 글로벌에서도 특수한 위치의 역할로, 과거 역사를 더듬어도 손으로 꼽을 정도의 인원밖에 없습니다. 간단히 말하면 절반은 소프트웨어 개발 엔지니어(SDE), 절반은 솔루션 아키텍트(SA) 같은 일입니다. 실제로는 더 혼돈스러워서, 프로덕트에 관련된 일이라면 뭐든 한다는 형태로 일하고 있었습니다. 사내에서 “BDA는 무슨 일이야?”라고 자주 물어보면 저는 “프로덕트 관련이면 뭐든 하는 잡무야”라고 답하곤 했습니다. 업무의 주성분으로는 앞의 두 직종 외에도 프로덕트 매니저(PM), 테크니컬 라이터(Tech Writer), 디벨로퍼 어드보케이트(DevRel), 그리고 클라우드 서포트 엔지니어(CSE) 요소가 포함되어 있었다고 생각합니다. 신기능의 PRFAQ(Press Release and FAQ)라는 문서를 쓰거나 Design Document를 쓰거나, AWS 문서나 블로그[2]를 쓰거나, 글로벌 중요 고객의 에스컬레이션을 받아 트러블슈팅과 성능 튜닝을 하거나, 백엔드 코드 버그를 고쳐 배포하거나… 정말 다양한 일을 할 기회가 있었습니다.
이 시기에 쓴 책이 3권[3] 있는데, 그중에서도 『AWS로 시작하는 데이터 레이크』는 많은 분이 읽어주신 것 같습니다. 개인적으로는 @simosako 아이디어로 서두에 추가된 “연어(샤케)를 모티프로 한 데이터 레이크 비유”를 정말 좋아합니다.
이들 중에서도 중심 업무로 위치づけ해 힘을 쏟았던 것은, 프로덕트와 고객 유스케이스 사이의 간극을 메우는 소프트웨어 아티팩트 개발이었습니다. 구체적으로는 프로덕트 내부에서 사용하는 데이터 통합용 소프트웨어 라이브러리, 다양한 데이터 스토어·데이터 웨어하우스에 연결하기 위한 커넥터/어댑터, 고객용 개발 유틸리티 등 주변 생태계에 걸친 아티팩트들입니다. Amazon DynamoDB용 커넥터나 AWS Glue 로컬 개발용 Docker 이미지, dbt Core용 어댑터 등은 이때 개발한 것들입니다. 이 중에는 수백만 번 다운로드된 것도 있어, 전 세계 많은 고객의 프로덕션 워크로드에 활용되었고, 매우 큰 성취감을 느낀 일이었습니다.
프로덕트 팀이 어떤 마일스톤을 기준으로 일하느냐 하면, 역시 빼놓을 수 없는 것이 AWS re:Invent입니다. 오해를 두려워하지 않고 말하면, AWS의 많은 프로덕트 팀은 re:Invent 타이밍에 큰 런치를 하는 것을 중요한 목표로 삼아 매일의 업무를 합니다. 이런 런치 플래닝은 많은 경우 고객 피드백을 바탕으로 시작됩니다. (AWS를 오래 사용하신 분이라면 AWS 멤버 발표에서 그런 이야기를 들어본 분도 있을 텐데, 실제로 그렇습니다.) 저도 이런 프로세스의 시작 부분부터 관여할 기회를 얻었습니다. 거기서 PR/FAQ[4]를 만들고, 다양한 이해관계자 간 논의를 통해 합의에 이르고, 그 다음 개발을 진행합니다. 많은 경우 몇 개월에서 1년 정도의 기간을 거쳐 런치에 이릅니다. 물론 그 과정이 아름다운 순간만 있는 것은 아니고, 합의 형성이 극도로 어려운 논의나, 냉혹한 의사결정의 반복, 피와 땀이 배어나는 지루한 작업의 누적이 있었습니다. 매우 힘든 일이었지만, 이 현실을 당사자로서 경험할 수 있었던 것은 귀중한 경험이었습니다.
클라우드 서포트 엔지니어 시절 참여한 re:Invent는 2015년 1회뿐이었지만, 빅데이터 아키텍트 시절 참여한 re:Invent는 2021, 2022, 2023, 2024, 2025의 5회로, AWS 커리어 전체를 통해 총 6회 참여했습니다. 특히 re:Invent 2021은 기억에 남는데, 마침 COVID-19 오미크론 변이가 re:Invent 직전에 유행했고, 결과적으로 일본 귀국 후 @toricls와 함께 호텔 격리를 하게 되었습니다. 격리 호텔이 알려지지 않아 목적지가 불명인 버스를 타고 정말 불안했던 것(가까우면 하네다 공항 근처, 멀면 센다이. 다행히 하네다 공항 근처였습니다.)과, 격리 기간 중 허리를 삐끗해(급성 요통) 고생했던 것을 기억합니다. 일본에서 re:Invent 2021에 참여한 사람은 극히 적었고, AWS Japan에서도 아마 @toricls와 저, 그리고 또 한 명, 3명만 참여했습니다. 어떤 re:Invent든 도전적인 일로 가득해 자극적인 경험이었습니다. 이 5회는 모두 세션 스피커로 참여[5]했는데, 그뿐 아니라 EBC(Executive Briefing Center) 미팅이라 불리는 특정 고객용 프라이빗 미팅에서 많은 고객과 AWS 서비스의 미래 로드맵, 그리고 고객이 당장 직면한 기술적 블로커 해결에 대해 많은 논의를 했습니다.
빅데이터 아키텍트로 일하면서 잊을 수 없는 일은 COVID Data Lake입니다. COVID-19가 전 세계로 확산되던 2020년 3월 어느 날 심야, General Manager에게 긴급 전화가 왔습니다. “오늘 미국에서는 믿기 힘들 정도로 많은 사람들이 죽고 있다. 지금 당장, 우리가 할 수 있는 일을 하자.” 그 전화는 새벽 3시까지 이어졌고, 그 뒤 며칠간 우리는 잠도 거의 못 자고 COVID Data Lake를 구축했습니다. 이는 New York Times 등 외부 기관에서 각국의 감염률, 사망자 수, 백신 접종 수 같은 데이터를 수집·처리하여 연구자와 엔지니어에게 데이터 분석 환경을 제공하는 구조입니다. 이 일은 평소 비즈니스 맥락과는 떨어진 특수한 위치づけ의 일이었습니다. 극도로 압박이 강한 긴급 프로젝트였지만, 소프트웨어 기술이 제 상상을 훨씬 뛰어넘어 사람들에게 도움이 되는 것을 목격했습니다. 이 COVID Data Lake는 2020년 4월 16일 Amazon 창업자 Jeff Bezos가 주주에게 발행한 레터에서도 소개되었습니다.
또 하나 기억에 남는 일은 보안 취약점 대응입니다. AWS에서는 보안을 ‘Job Zero’로 두고 가장 우선순위가 높은 일로 정의하며 실제로도 그렇게 합니다. 여러분 중에는 2021년 즈음의 Log4Shell을 기억하는 분도 많지 않을까요. 당시 이 보안 취약점이 보고되었을 때 AWS 내부도 큰 소동이었습니다. 구체적으로 무엇이 일어났고 무엇을 했는지는 많이 쓸 수 없지만, 제 개인 업무로는 AWS Glue 프로덕트 런치부터 그날까지 전 기간에 걸쳐 전 컴포넌트·전 리전의 모든 로그를 분석해 공격 영향이 없음을 확인하거나, 의존하는 모든 라이브러리 중 어떤 것에 영향 버전의 log4j가 포함되는지 확인해 긴급 업그레이드·재배포하는 등의 일을 했습니다. 긴급성이 극도로 높고 필요한 작업 범위가 매우 넓어 엄청 고생했습니다. 솔직히 여러 번 하고 싶지는 않지만, 우리만이 할 수 있는 매우 중요한 일이었다고 생각합니다.
이동 당시에는 직무 레벨을 유지한 채 시니어 빅데이터 아키텍트(L6)가 되었고, 이후 2021년 10월에 프린시펄 빅데이터 아키텍트(L7)가 되었습니다. 이것이 Amazon에서의 마지막 역할·포지션이 되었습니다.
Amazon에는 Leadership Principles라는 사고방식이 있습니다. 이는 일반적인 회사로 치면 사훈 같은 것이지만, Amazon 내부에서 극도로 강하게 강조·중요시되는 사고방식이며, 인재 채용, 인사 평가부터 다양한 구체적 의사결정까지 모든 장면에서 참조되고 실제로 사용됩니다. 예를 들어 채용 면접에서는 각 면접관에게 몇 가지 개별 Leadership Principle이 할당되고, 후보자가 그 Leadership Principle을 체현하는 사람인지 여부를 에피소드를 통해 확인하는 형태로 면접합니다. 즉 Amazon 면접 준비란, 이 Leadership Principle 각각을 축으로 자신의 경험을 에피소드 기반으로 되돌아보는 작업이 됩니다. (물론 역할에 맞는 하드 스킬도 필요합니다.)
이 Leadership Principles에 대해서는 12년 커리어의 여러 장면에서 배움이 있었습니다. 특히 통감한 것은, Leadership Principles는 그것을 완수하기 어려운 때에야말로 진가를 발휘한다는 점입니다. 기억에 남는 것들만 몇 가지 골라보겠습니다.
“수많은 Leadership Principles 중 가장 중요한 것은?”이라는 질문에 대해 가장 먼저 거론되는 것이 이 Customer Obsession입니다.
“고객이 이렇게 말하고 있으니 이렇게 합시다”는 사실 Customer Obsession이 아닙니다. “고객이 이렇게 말하지만, 사실 그 뒤에 있는 문제 해결에 필요한 것은 다른 것”이라는 상황은 어디에서나 발생합니다.
여러 번 본 것은 AWS 사용자에게 익숙한, AWS 서비스 한도 상향(상한 완화)입니다. AWS 서비스 한도는 결코 괴롭히려고 있는 것이 아니라 두 가지 목적이 있습니다. 하나는 AWS 서비스의 정상 운영을 지키기 위해, 다른 하나는 고객을 지키기 위해서입니다. 후자는 일차적으로 AWS 서비스를 과도하게 사용해 발생하는 예상치 못한 비용으로부터 고객을 보호한다는 뜻입니다. 하지만 AWS에서 오래 일하다 보면 가끔 터무니없는 요청을 보게 됩니다. 예를 들어 요청된 네트워크 대역폭이 일본의 인터넷 인프라를 크게 웃돈다든지, 요청된 API 레이트가 모든 예상 엔드유저가 24/365로 매초 API를 실행하는 수준이라든지요. 또 때로는 다른 고객의 1~100만 배 값(요청치)을 요구하는 요청도 있습니다. 이는 사실 중요한 시그널로, 이런 요청을 통해 AWS가 고객 워크로드나 유스케이스의 문제점에 눈치채 최적화를 제안하거나, 고객 교육을 위한 트레이닝을 제공하는 일이 벌어집니다. 고객 입장에서는 “한도 상향을 요청했으니 그냥 올려줘”가 될 수 있지만, 정말 필요한 문제 해결을 위해서는 때로 고객 요청을 거절하면서도 다른 해법을 제시하는 것, 이것이 Customer Obsession의 한 예라고 생각합니다.
공식 해설 문구가 훌륭해서 인용합니다.
리더는 동의할 수 없는 경우에는 존중을 갖추어 이의를 제기해야 합니다. 설령 그것이 번거롭고 힘이 드는 일이라 하더라도 예외는 없습니다. 리더는 신념을 갖고 쉽게 포기하지 않습니다. 쉽게 타협해 친목으로 흐르지 않습니다. 그러나 일단 결정이 내려지면, 전적으로 커밋하여 임합니다.
동의할 수 없는 일이 있을 때 반대하는 것은 중요합니다. 한편 결정이 내려진 뒤에도 언제까지나 반대만 하고 있는 것은 용납되지 않는다는 뜻입니다. 사람은 무르기 쉬워서, 좋지 않은 결과가 나오면 “그러니까 내가 그때 반대했잖아”가 되기 쉽습니다. 또한 자신이 반대하던 일에 전면적으로 커밋하는 것은 자연스럽게는 잘 되지 않습니다. 이를 억지로라도 교정하기 위해 이 Leadership Principle이 필요한 것입니다.
Amazon 내부의 다양한 장면에서 사용된다고 했지만, 반대로 제가 ‘절대로 써서는 안 된다’고 강하게 생각했던 것은 타인에게 무언가를 강요하는 상황입니다. 예를 들어 “네가 이렇게 하지 않는 건 Customer Obsession이 부족한 거 아니야?(=그러니 이렇게 해)” 같은 식입니다. 어디까지나 Leadership Principles는 주어가 “나” 또는 “우리”일 때, 스스로의 의사결정에 사용해야 한다는 점에尽きます.
Amazon에는 한 번 결정하면 되돌릴 수 없는 결정을 “One-way door decision”, 결정 후에도 되돌릴 수 있는 결정을 “Two-way door decision”이라고 부르는 사고방식이 있습니다. 이는 Jeff Bezos가 Amazon의 지속적인 혁신을 위해 제창한 의사결정 프레임워크로, 여러 책과 기사에서도 소개되어 있습니다.
저 역시 Amazon에서의 다양한 경험을 통해 어떤 의사결정이 “One-way door”인지 “Two-way door”인지 판별하고, “Two-way door”라면 신속히, “One-way door”라면 극도로 신중히 결정하는 방식을, 고통을 동반한 형태로 배웠습니다. 말로 하면 쉬워 보이지만 제게는 매우 어려웠고, 때로 “Two-way door”라고 생각하고 진행한 내용이 나중에 “One-way door”였음을 깨달아 돌이킬 수 없는 사태가 된 적도 여러 번 있었습니다. 이는 배움이기도 하고 크게 반성하는 점이기도 합니다. 되돌릴 수 없는 의사결정은 존재합니다. 그것을 겸손하게 되돌아보고 과오를 인정할 수 있는 사람은 많지 않습니다. “One-way door decision”을 정확히 간파하고, 정성 들여 신중하게 판단하는 것의 중요성은 말로 다 할 수 없습니다.
Amazon에는 많은 외국계 기업과 마찬가지로 Job Description이 있습니다. Job Description이란 직무의 구체적 내용, 책임 범위, 필요한 스킬·경험을 명기한 ‘직무기술서’입니다. 인재 채용 시에는 Job Description에 대해 Head Count가 정의되고 그 포지션에 사람이 채용됩니다.
일본에서는 이 Job Description에 대한 인식으로, 직원이 직무 내용이 문서화되지 않은 업무는 하지 않아도 된다는 의식으로 이어지기 쉬운 듯합니다. 하지만 어디까지나 제 Amazon 관측 범위에서는, 미국 멤버든 다른 나라 멤버든 Job Description에 적혀 있지 않더라도 비즈니스, 직무, 프로덕트에 필요한 일이라면 무엇이든 한다는 멘탈 모델로 일한 사람이 많았던 것 같습니다. Amazon에는 글로벌로 재미있는 일이 많고, 소속이나 역할, 직무 레벨을 이유로 도전하지 않는 것은 아깝다. 바로 도전하자!라는 멘탈 모델을 가진 사람이 성공해 나간 경우가 많았던 것 같습니다.
그만큼 통상 직무 범위를 넘어서는 일이 정당하게 평가받기 위해서는, 자신의 평가를 타인에게 무조건 맡기지 않는 것이 중요했습니다. 이는 매니저(상사)에게도 마찬가지입니다. 매일 많은 멤버를 리드하며 수많은 업무에 치이기 쉬운 매니저에게 “굳이 문서화하지 않아도 내 성과가 모두 올바르게 평가되겠지”라고 맡기는 것은 순진한 기대일 것입니다. 뛰어난 매니저라면 그 기대에 부응할 수 있겠지만, 그래도 그 시야는 제한되기 쉽습니다.
성과를 스스로 설명 가능한 문서로 정리해 어필하는 것이 극도로 중요합니다. 설령 조직이나 매니저가 요청하지 않더라도, 자신이 먼저 시작해 (멋대로) 제출합니다. 조직과 매니저가 나를 고평가하지 않을 수 없는 상황을 만든다고 말할 수도 있습니다. 여기서 자기 인식과 평가의 미스매치가 있다면, 그런 피드백을 받을 기회를 늘리는 데도 도움이 됩니다.
저의 경우 앞서 말한 빅데이터 아키텍트라는 특수한 역할로 일했기 때문에 KPI가 자명하지 않았고, 일상 업무도 반드시 타인에게 설명하기 쉬운 것만은 아니었습니다. 이런 일을 하는 경우일수록 스스로 성과를 어필하는 것이 더욱 중요해집니다. 가능하면 정기적으로, 최소한 1년에 1~2회는 그런 기회와 수단을 마련하는 프랙티스를 만들어 다른 사람에게도 권했습니다. 꽤 유효했기 때문에 다음 일에서도 도입하려고 합니다.
Amazon의 소프트웨어 엔지니어가 쓰는 소스코드라고 하면, 많은 분들이 훌륭한 품질의 코드를 기대하지 않을까요. 하지만 현실에는 많은 리포지토리가 존재하고 그 품질은 천차만별입니다. 그중에는 그다지 깔끔하다고 말하기 어려운 코드도 있습니다. 오픈소스 프로젝트 쪽이 코드 품질이 더 높은 경향인 경우도 있을지 모릅니다. 그럼에도 이 코드들은 Amazon과 AWS의 근간을 지탱하며 고객에게 가치를 전달하고 돈을 벌어온 코드입니다.
또 어떤 시점에서 코드를 봤을 때 의도가 잘 이해되지 않아도, 사실은 다양한 배경 사정으로 인해 어쩔 수 없이 그렇게 된 경우도 많습니다. 예를 들어 Amazon S3의 동작은(기능 지원 여부를 제외하면) 모든 리전에서 같다고 생각될 수 있지만, 기본적인 리다이렉트 동작이 리전별로 달랐다든지 하는 일이 있습니다. 그런 리전별 동작 차이를 흡수하는 코드는 얼핏 의도가 잘 보이지 않을 수 있지만 매우 중요한 역할을 합니다.
문제가 있는 코드가 있다면 방치하지 않고 리팩터링하는 것은 중요하지만, 한편 리스펙트 없는 커뮤니케이션은 팀 내에 심각한 갈등을 만들 수 있습니다. 이런 소스코드와 과거 소프트웨어 엔지니어의 작업에 대한 리스펙트를 잃지 않으면서, 균형 잡힌 시각으로 코드에 기여하는 것이 필요하다고 생각합니다.
“You build it, you run it.” 이는 당시 Amazon CTO였던 Werner Vogels의 말입니다. 존경하는 전 동료인 토리 씨의 프레젠테이션에서도 자세히 해설되어 있지만, 전통적인 소프트웨어 개발 모델에서는 개발과 운영이 분단되어 개발은 일단 릴리스하면 운영에 맡기고 잊어버리기 쉽지만 Amazon에서는 그렇게 하지 않는다. 개발자에게 소프트웨어 시스템 품질을 기술적으로, 고객 경험적으로 유지·개선할 책임을 지우는 문화라고 할 수 있습니다. 이는 많은 AWS 문서나 발표에서도 언급되는, 널리 알려진 문화라고 생각합니다. 이를 이유로 제가 아는 개발 팀들은 모두 소프트웨어 개발자가 일상 운영도 겸임합니다.
한편 저는 이 말이 Amazon의 ‘각오’라고 생각합니다. 이 문화는 은탄환이 아닙니다. 당연히 개발이 더 많은 책임을 떠안음으로써 생기는 개발 속도·생산성과의 트레이드오프가 포함됩니다. 그런 단점과 리스크, 오버헤드를 모두 감수할 각오가 되어 있다는 뜻입니다. 개발자가 일상 운영까지 하는 것은 힘듭니다. re:Invent를 위한 런치를 빠듯한 일정으로 진행하는 와중에 대규모 장애가 발생하거나, 외부에서 치명적인 보안 취약점이 보고되면 정말 상상하기 어려운 상황이 됩니다. 그럼에도 소프트웨어 시스템을 개발자가 운영함으로써 품질을 유지·개선하는 것이 더 중요하다고 판단해 이를 끝까지 관철한다는 의미입니다.
Amazon은 글로벌 기업이지만 시애틀에 HQ를 둔 미국 기업이며, 물론 영어가 공용어입니다. 일본 오피스에서 일본어 화자끼리 대화할 때 영어가 강제되지는 않지만, 영어를 못하면 중요한 커뮤니케이션을 할 수 없거나, 일과 커리어 선택지가 좁아집니다. 영어를 못하는 것은 핸디캡이 됩니다.
그렇다면 영어를 유창하게 못하는 것이 큰 문제냐 하면, 그렇지는 않습니다. 중요한 것은 “영어를 해 나가려는 마음”입니다. 설령 자신이 능숙하지 않더라도, 상대에게 전달되는 말로 어떻게든 커뮤니케이션을 하려는 자세와 그 노력이 중요합니다.
이 “영어를 해 나가려는 마음”은 누구나 가지고 있는 자질은 아닙니다. Amazon에도 영어 미팅이 되면 “저는 영어가 자신 없으니 잘하는 분께 맡기겠습니다”라며 조용해지는 사람이 많습니다. 커뮤니케이션할 의지가 없는 분위기는 상대에게도 전해지기 쉽고, 본래의 잠재력을 다 발휘하지 못하는 장면을 보면 아깝다고 느끼는 일도 있었습니다.
“영어를 해 나가려는 마음”이 있으면 커뮤니케이션은 결국 어떻게든 됩니다. 상대 영어가 들리지 않으면 몇 번이든 되묻습니다. 구두로 도저히 못 알아듣겠으면 스마트폰에 입력해 달라고 해도 되고, 원격 미팅이라면 채팅에 써달라고 하는 것도 도움이 됩니다. 내 영어가 전달되지 않으면 표현을 바꿔가며 몇 번이든 설명을 반복합니다. 저는 상대에게 폐를 끼친다는 부담감 때문에 잘 못했지만, 앞서 말한 re:Invent 2015의 뼈아픈 경험을 통해 점차 할 수 있게 되었습니다.
한 가지 더 덧붙이면, 목소리 크기가 중요했습니다. 제 주변의 제한된 관측 범위에서는 일본인의 영어가 통하지 않는 이유가 영어가 유창하지 않아서가 아니라, 사실 목소리가 작아서인 경우가 많았습니다. 제 개인 경험상 부끄러워하지 말고 큰 소리로 영어를 말하면 길이 열리기도 했습니다.
Amazon에서 글로벌 팀으로 여러 나라 멤버와 함께 일하면서 가장 힘들었던 것은 시차가 있는 커뮤니케이션입니다. 미국과 유럽과 인도와 일본 모두를 AND로 묶어 미팅을 잡으면 대개 일본은 심야가 됩니다. 정보 공유 성격의 미팅이라면 타임존에 맞춰 여러 번 하면 되지만, 이해관계자 합의를 위한 미팅은 그럴 수 없습니다. 해결책이 없으니 졸린 눈을 비비며 심야 미팅에 나갈 수밖에 없습니다.
한편 1:1 커뮤니케이션, 특히 누군가가 누군가에게 도움을 요청하는 커뮤니케이션이라면, 원칙적으로 의뢰자 쪽이 상대 타임존에 맞춰 양보해야 합니다. 타임존이 다른 누군가에게 무엇을 부탁할 때는 상대 타임존에 맞추는 편이 좋습니다. 반대로 누군가가 나에게 부탁할 때는, 커뮤니케이션을 통해 내 타임존에 맞춰달라고 하는 것이 워크라이프 밸런스 관점에서도, 평소 시차로 고생하는 다른 사람들을 위해서도 중요합니다. 이런 배려는 당연해 보일 수 있지만, 특히 미국 멤버 상당수는 상대 타임존에 맞추는 것에 익숙하지 않아 때로는 정중한 커뮤니케이션이 필요합니다.
Amazon 사내에는 재미있는 위키가 많은데, 제가 좋아하는 위키 페이지에는 “모두가 시애틀에서 일하는 건 아니니 전 세계 멤버를 배려합시다!”라는 메시지가 적혀 있습니다. 그만큼 시차로 곤란한 사람이 전 세계에 많다는 뜻이겠죠…
AWS의 각종 서비스는(구체적으로는 말할 수 없지만) 많은 경우 다른 AWS 서비스 위에 구축되어 있습니다. 즉 AWS 개발 팀은 AWS 서비스를 개발하는 사람이면서 동시에 다른 AWS 서비스의 사용자이기도 합니다.
즉 아이디어와 구현력만 있다면, AWS의 ‘새 서비스 같은 것’을 AWS 위에 구축하는 것이 원리적으로는 누구에게나 가능하다는 뜻입니다. 물론 AWS에는 비공개 구조나 서비스도 있어 내부자와 완전히 같은 것을 외부에서 할 수는 없지만, 그 가능성을 생각하면 가슴이 뜁니다.
AWS는 대규모 시스템을 개발·운영하기 위한 노하우를 많이 가지고 있습니다. 예를 들어 Cell-based Architecture입니다. Cell-based architecture에 대해서는 존경하는 전 동료 riywo 님이 퇴직 글과 기술 글에서 해설하고 있으니 관심 있는 분은 읽어보세요.
이런 여러 성숙한 노하우는 아무것도 없는 곳에서 갑자기 생겨난 것이 아닙니다. AWS는 긴 역사 속에서 수많은 실패를 해왔습니다. 그 실패를 하나씩 Correction Of Error(COE)라는 프로세스로 되돌아보고, 성실한 개선을 반복하는 과정에서 정리되고 발전해 온 것입니다. COE에 대해서는 correction of error(COE)를 개발해야 하는 이유에서 자세히 해설되어 있습니다.
그 밖에도 말해야 할 소재는 많지만, 12년이나 있었던 만큼 쓰다 보면 끝이 없으니 이 정도로 해두겠습니다.
AWS는 지금도 저에게 특별한 곳입니다. AWS에 조인하지 않았다면 지금의 저는 없었을 것입니다. 제가 쓴 코드가 처음으로 AWS 서비스의 일부로 배포되었을 때의 말로 표현하기 어려운 성취감은 지금도 선명하게 기억합니다. AWS에서 만난 동료들에게서 많은 자극을 받았고, 지금도 좋은 관계를 유지할 수 있는 것에 감사하고 있습니다. AWS를 떠난 전 동료들이 다양한 필드에서 활약하는 모습을 보는 것도 기쁘고 힘이 됩니다.
이번 퇴사에 대해서는 재직 기간도 길고 여러 방향으로 고민해 결정했기 때문에 간단히 설명하기는 어렵지만, 퇴사 이유 중 하나는 제가 Amazon에서 해야 할 일은 다 해냈다는 느낌이 있었기 때문입니다. 특히 프로덕트 개발 팀의 원격 멤버로서, 타임존도 위치도 다른 상황에서 할 수 있는 기여는 어느 정도 해냈다는 감각이 있습니다. (물론 마음먹으면 아직도 할 수 있는 일은 많다고는 생각하지만…)
한편 Amazon에서 12년을 있었던 만큼 그 프로덕트와 기술 영역, 조직의 구조에 익숙해져서 다소 ‘손에 밴 습관’으로 일하는 느낌도 있었습니다. 처음 참가한 re:Invent는 긴장감과 자극으로 가득했지만, 6번째인 re:Invent 2025는 일상의 연장선이 되어 있었습니다.
앞으로 적어도 20년 이상은 일할 것이라고 생각하기에, 향후 20년의 커리어를 내다봤을 때 필드를 바꿔 새로운 도전에 나서기에 딱 좋은 타이밍이 아닐까 싶게 만드는 몇 가지 일이 겹친 것도 이유입니다.
참고로 책 『싸우는 프로그래머』에 등장하는 Microsoft의 전설적인 프로그래머 David Neil Cutler를 존경하고 있어, 그가 최전선에서 물러나는 나이까지는 일하겠다고 10년 이상 전에 결심했는데, 2022년 기사를 보니 80세 시점에도 Microsoft에서 일하고 있는 것 같아, 꽤 각오를 단단히 해야 할 것 같습니다…
조만간 별도의 글을 하나 더 쓸까 합니다.
각주
정확히는 입사 당시에는 Amazon Data Services Japan에 입사했고, 이후 Amazon Web Services Japan이 설립된 타이밍에 그쪽으로 옮겼습니다. ↩︎
AWS 커리어를 통해 쓴 블로그는 약 80편이었습니다. 그중 First author로 쓴 블로그는 여기로 정리되어 있습니다: https://aws.amazon.com/blogs/big-data/author/sekiyama/↩︎
다른 2권은 모두 영어 서적으로, 『Serverless ETL and Analytics with AWS Glue』와 『Unleash the power of Apache Iceberg on AWS』입니다. ↩︎
Press Release & FAQ라는 Amazon의 제품 릴리스 방식에서 사용하는 문서입니다. 제품을 만들기 전에, 릴리스할 때를 상정하고 보도자료부터 쓰기 시작하는 것입니다. 저는 이를 제멋대로 ‘망상 드리븐 개발’이라고 부릅니다. ↩︎
모두 Chalk talk 형식의 세션이어서 아쉽게도 녹화가 남아 있지 않습니다. ↩︎
