2021.09.01

글로벌 칼럼 | 직장으로서의 AWS에 대해 잘 알려지지 않은 것

Matt Asay | InfoWorld
2021년 8월 27일은 필자가 아마존 웹 서비스(AWS)에서 일한 마지막 날이다. AWS에서 2년 동안 오픈소스 마케팅과 전략팀을 운영했다. 표면적인 업무는 AWS의 오픈소스 활동에 대한 사람들의 인식을 넓히는 것이지만, 실제로는 AWS와 관련된 오픈소스 업스트림에 기여하는 이유와 그 방법을 이해하도록 제품팀을 돕는 데 대부분의 시간을 사용했다. 나머지 시간 동안 회사 외부에서 컨플루언트(Confluent), 데이터브릭스(Databricks)와 같은 오픈소스 업체와 AWS의 협력관계를 강화하는 일을 했다.

또한 필자는 AWS가 오픈소스 기업과 커뮤니티에 “해악”을 끼치는 것으로 인식됐을 당시 사태를 수습하는 일도 도왔다. 
 
ⓒ AWS

필자의 경험으로, 오픈소스와 관련하여 AWS를 향한 분노는 대체로 잘못된 생각에서 출발한다. AWS가 완벽하다는 뜻은 아니지만, AWS는 여전히 세계에서 오픈소스 프로젝트에 가장 많이 기여하는 기업이다. 기여자의 수, 코드의 양, 어느 쪽으로 측정하든 마찬가지다. 대부분의 분노는 AWS가 오픈소스에 대한 공통된 접근 방법을 가진 획일적 업체라는 잘못된 생각에서 비롯된 것이다. AWS에 관한 오해를 부른 큰 낭설 중 하나다. 여기서는 이런 헛소문을 비롯한 여러 내용을 다룰 것이다. 기밀은 없지만 아마존이 가급적 보이지 않게 숨기고 있는 부분일 것이다. 
 

2피자 팀 

아마존 창업자이자 전 CEO인 제프 베조스는 창업 초기에 “2피자 규칙”을 만들었다. 각 팀의 규모가 피자 2판으로 모두 먹을 수 있는 수준을 넘지 않도록 하는 규칙이다. 다소 과장된 부분은 있지만, 원칙 자체는 AWS 전반에서 철저히 지켜진다. 팀의 규모는 대체로 작고, 더 중요한 부분은 거의 완전히 자율적으로 움직인다는 점이다. 

즉, 서비스팀 X가 지금 시점에 오픈소스 프로젝트에 기여하지 않을 수 있지만, 그렇다고 다른 서비스팀도 모두 기여하지 않는다는 의미는 아니다. 서비스팀의 수가 200개 이상이다. 예를 들어 일래스틱캐시(ElastiCache)팀은 5명의 레디스(Redis) 유지관리자 중 한 명을 채용했다. 다른 여러 팀은 러스트(Rust)에 많은 부분을 기여한다. 아파치 루씬, 쿠버네티스, 오픈텔레메트리, etcd, 아파치 아이스버그, 오픈JDK, 그래프QL 등 예를 들자면 많다. 

아직 오픈소스 업스트림 관련 일을 하지 않는 팀이 있을까? 물론 있다. 마이크로소프트, 구글, 알리바바 등과 마찬가지다. 그러나 필자는 AWS에서 일하면서 변화가 일어나는 것을 봤다. 이 프로세스의 속도가 느린 실제 이유는 아마존이 상명하복 방식으로 일을 진행하는 경우가 거의 없는 기업이기 때문이다. 아마존이 더 많이 기여하기를 원한다면 개별 팀에 집중해야 하며, 그에 못지않게 중요한 것은 아마존 언어를 구사하는 것이다. 
 

실제로 존재하는 16가지 리더십 원칙 

“아마존 언어를 구사한다”는 말은 이 회사의 16가지 리더십 원칙(16 Leadership Principles, 이하 LP)에 반영된 언어와 사고의 프로세스를 의미한다. AWS에 들어오기 전에 필자는 LP를 좋게 보면 가식적인 구호, 나쁘게 보면 징고이즘 정도로 생각했지만, 사실 LP는 100만 명 이상의 아마존 직원들이 서로 대화하고 함께 일하기 위한 공통의 프레임워크를 제공한다. 아이디어를 제안하고 운영 계획을 결정하는 데 사용되는 익히 알려진 “6 페이저”를 포함해서 AWS에서 이뤄지는 모든 논의에 이 원칙이 스며 있다. 

필자는 AWS 입사 초기에는 토론에서 LP 사용을 기피했다. 결과는 좋지 않았다. 예를 들어 “프로젝트 X에 기여해야 한다. 그것이 올바른 일이기 때문”이라고 말하면 멍한 시선이 돌아왔다. “프로젝트 Y의 방향에 영향을 미칠 수 있도록 엔지니어들에게 이 프로젝트에 기여할 시간을 더 줘야 한다”고 말하면 찌푸린 시선이 돌아왔다. 결국 아무 데도 이르지 못했다. 

이후 논점을 LP에 맞추자 훨씬 더 나아지기 시작했다. 예를 들어 “코드 기여를 통해 우리가 의존하는 커뮤니티의 ‘신뢰를 얻지’ 못한다면 ‘고객에 집착’하면서 ‘검소함’으로 혁신을 제공하기는 어려울 것이다. 또한 이렇게 하면 기여를 통해 ‘결과를 제공’하고 고객을 지원하기 위한 더 좋은 위치에 서게 되므로 ‘최상의 기준을 고집’할 수 있다”는 식으로 말하기 시작했다. 

그러자 갑자기 사람들이 필자의 말을 이해하기 시작했다. 그 사람들이 아둔한 것이 아니라, 필자가 AWS(그리고 아마존)에서 일어나는 모든 일을 관할하는 원칙에 맞는 언어를 구사해야 했던 것이다. AWS에서 뭔가를 바꾸고 싶다면 원하는 결과를 LP를 사용해 투영해야 한다. 필자의 팀은 여기에 차츰 적응했고, 프로젝트에서 서비스팀의 개입이 늘면서 그에 따른 효과를 얻었다. 물론 여기에도 개선의 여지는 있다. 
 

의지는 있다 

필자는 AWS에서 일하면서 오픈소스의 중요함을 폄하하는 말은 한 마디도 들어본 적이 없다. 사실 정반대다. AWS를 오픈소스를 갈취하는 사악한 악당으로 조롱하는 것이 재미있다는 것은 알지만, 실제로 그 묘사에 부합하는 사람을 만나본 적은 없다. 서비스팀 총괄 관리자나 다른 사람들과 비즈니스에서 오픈소스의 중요성에 대해 의견이 불일치하는 경우, 핵심은 언제나 특정 상황에서 어떤 LP에 더 중점을 두느냐의 문제로 귀결됐다. 

예를 들어 “고객 집착”은 모든 아마존인에게 최우선 순위지만, 의미는 맥락에 따라 다를 수 있다. 필자는 오픈소스 기여를 고객 집착 측면에서 중장기적 핵심 요소로 볼 수 있지만 서비스팀 총괄 관리자는 단기적인 관점도 고려해야 한다. 이는 회사가 신속하게 버그를 수정하거나 고객이 요구하는 기능을 제공할 수 있도록 코드의 프라이빗 브랜치를 만든다는 것을 의미한다. 또한 고객이 모두 오픈소스를 좋아하고 원하는 것처럼 보여도 많은 고객이 그 코드를 운영할 수 있도록 만드는 것을 더욱 중시한다. 

이는 단기적으로 매끄러운 고객 경험을 보장하기 위해 엔지니어가 투입되어 프로젝트의 장기적인 성공에 기여할 시간은 그만큼 줄어든다는 것을 의미한다. 필자가 일하는 동안 개선되긴 했지만 2피자 팀으로 가득 찬 회사에는 오픈소스에 대한 통일된 한 가지 접근 방법은 존재하지 않는다. 

이 말은 “소유”, “발명과 간소화”, “최상의 기준 고집”, “결과 제공”과 같은 LP가 오픈소스 프로젝트의 상업적 관리 주체와의 원활한 파트너 관계와 상충하는 듯이 보일 수 있음을 의미하기도 한다. 고객이 더 쉬운 아파치 카프카를 원한다면, 그에 대한 즉각적인 대응은 움직이는 부분을 최소화해서 또는 실패의 가능성을 최소화해서 고객 대신 관리할 수 있는 서비스를 구축하는 것이다. AWS는 경험으로 첫 번째 옵션이 더 쉽다는 것을 알지만, 컨플루언트와 다른 오픈소스 업체의 많은 성공 사례는 고무적이다(카프카의 경우). 

이 분야에서 AWS는 아직 갈 길이 멀지만, 따지고 보면 우리 모두가 마찬가지다. 오픈소스 분야에서 20년 이상 일하면서 필자가 가장 좋아한 점은 오랜 시행착오에도 불구하고 업계 전체(그리고 개인과 각 업체)는 계속 배워야 한다는 것이다. 오픈소스 프로젝트 또는 비즈니스를 구축하고 운영하기 위한 완벽한 방법은 아직 누구도 찾지 못했다. 우리 모두 여전히 배우는 중이다. 

그러니 필자가 AWS에서 노력했던 것처럼 서로 조금씩 더 인내심을 갖고, 한 개인이나 회사가 지금처럼 행동하는 이유를 이해하기 위해 노력해야 할 것이다. editor@itworld.co.kr
 


2021.09.01

글로벌 칼럼 | 직장으로서의 AWS에 대해 잘 알려지지 않은 것

Matt Asay | InfoWorld
2021년 8월 27일은 필자가 아마존 웹 서비스(AWS)에서 일한 마지막 날이다. AWS에서 2년 동안 오픈소스 마케팅과 전략팀을 운영했다. 표면적인 업무는 AWS의 오픈소스 활동에 대한 사람들의 인식을 넓히는 것이지만, 실제로는 AWS와 관련된 오픈소스 업스트림에 기여하는 이유와 그 방법을 이해하도록 제품팀을 돕는 데 대부분의 시간을 사용했다. 나머지 시간 동안 회사 외부에서 컨플루언트(Confluent), 데이터브릭스(Databricks)와 같은 오픈소스 업체와 AWS의 협력관계를 강화하는 일을 했다.

또한 필자는 AWS가 오픈소스 기업과 커뮤니티에 “해악”을 끼치는 것으로 인식됐을 당시 사태를 수습하는 일도 도왔다. 
 
ⓒ AWS

필자의 경험으로, 오픈소스와 관련하여 AWS를 향한 분노는 대체로 잘못된 생각에서 출발한다. AWS가 완벽하다는 뜻은 아니지만, AWS는 여전히 세계에서 오픈소스 프로젝트에 가장 많이 기여하는 기업이다. 기여자의 수, 코드의 양, 어느 쪽으로 측정하든 마찬가지다. 대부분의 분노는 AWS가 오픈소스에 대한 공통된 접근 방법을 가진 획일적 업체라는 잘못된 생각에서 비롯된 것이다. AWS에 관한 오해를 부른 큰 낭설 중 하나다. 여기서는 이런 헛소문을 비롯한 여러 내용을 다룰 것이다. 기밀은 없지만 아마존이 가급적 보이지 않게 숨기고 있는 부분일 것이다. 
 

2피자 팀 

아마존 창업자이자 전 CEO인 제프 베조스는 창업 초기에 “2피자 규칙”을 만들었다. 각 팀의 규모가 피자 2판으로 모두 먹을 수 있는 수준을 넘지 않도록 하는 규칙이다. 다소 과장된 부분은 있지만, 원칙 자체는 AWS 전반에서 철저히 지켜진다. 팀의 규모는 대체로 작고, 더 중요한 부분은 거의 완전히 자율적으로 움직인다는 점이다. 

즉, 서비스팀 X가 지금 시점에 오픈소스 프로젝트에 기여하지 않을 수 있지만, 그렇다고 다른 서비스팀도 모두 기여하지 않는다는 의미는 아니다. 서비스팀의 수가 200개 이상이다. 예를 들어 일래스틱캐시(ElastiCache)팀은 5명의 레디스(Redis) 유지관리자 중 한 명을 채용했다. 다른 여러 팀은 러스트(Rust)에 많은 부분을 기여한다. 아파치 루씬, 쿠버네티스, 오픈텔레메트리, etcd, 아파치 아이스버그, 오픈JDK, 그래프QL 등 예를 들자면 많다. 

아직 오픈소스 업스트림 관련 일을 하지 않는 팀이 있을까? 물론 있다. 마이크로소프트, 구글, 알리바바 등과 마찬가지다. 그러나 필자는 AWS에서 일하면서 변화가 일어나는 것을 봤다. 이 프로세스의 속도가 느린 실제 이유는 아마존이 상명하복 방식으로 일을 진행하는 경우가 거의 없는 기업이기 때문이다. 아마존이 더 많이 기여하기를 원한다면 개별 팀에 집중해야 하며, 그에 못지않게 중요한 것은 아마존 언어를 구사하는 것이다. 
 

실제로 존재하는 16가지 리더십 원칙 

“아마존 언어를 구사한다”는 말은 이 회사의 16가지 리더십 원칙(16 Leadership Principles, 이하 LP)에 반영된 언어와 사고의 프로세스를 의미한다. AWS에 들어오기 전에 필자는 LP를 좋게 보면 가식적인 구호, 나쁘게 보면 징고이즘 정도로 생각했지만, 사실 LP는 100만 명 이상의 아마존 직원들이 서로 대화하고 함께 일하기 위한 공통의 프레임워크를 제공한다. 아이디어를 제안하고 운영 계획을 결정하는 데 사용되는 익히 알려진 “6 페이저”를 포함해서 AWS에서 이뤄지는 모든 논의에 이 원칙이 스며 있다. 

필자는 AWS 입사 초기에는 토론에서 LP 사용을 기피했다. 결과는 좋지 않았다. 예를 들어 “프로젝트 X에 기여해야 한다. 그것이 올바른 일이기 때문”이라고 말하면 멍한 시선이 돌아왔다. “프로젝트 Y의 방향에 영향을 미칠 수 있도록 엔지니어들에게 이 프로젝트에 기여할 시간을 더 줘야 한다”고 말하면 찌푸린 시선이 돌아왔다. 결국 아무 데도 이르지 못했다. 

이후 논점을 LP에 맞추자 훨씬 더 나아지기 시작했다. 예를 들어 “코드 기여를 통해 우리가 의존하는 커뮤니티의 ‘신뢰를 얻지’ 못한다면 ‘고객에 집착’하면서 ‘검소함’으로 혁신을 제공하기는 어려울 것이다. 또한 이렇게 하면 기여를 통해 ‘결과를 제공’하고 고객을 지원하기 위한 더 좋은 위치에 서게 되므로 ‘최상의 기준을 고집’할 수 있다”는 식으로 말하기 시작했다. 

그러자 갑자기 사람들이 필자의 말을 이해하기 시작했다. 그 사람들이 아둔한 것이 아니라, 필자가 AWS(그리고 아마존)에서 일어나는 모든 일을 관할하는 원칙에 맞는 언어를 구사해야 했던 것이다. AWS에서 뭔가를 바꾸고 싶다면 원하는 결과를 LP를 사용해 투영해야 한다. 필자의 팀은 여기에 차츰 적응했고, 프로젝트에서 서비스팀의 개입이 늘면서 그에 따른 효과를 얻었다. 물론 여기에도 개선의 여지는 있다. 
 

의지는 있다 

필자는 AWS에서 일하면서 오픈소스의 중요함을 폄하하는 말은 한 마디도 들어본 적이 없다. 사실 정반대다. AWS를 오픈소스를 갈취하는 사악한 악당으로 조롱하는 것이 재미있다는 것은 알지만, 실제로 그 묘사에 부합하는 사람을 만나본 적은 없다. 서비스팀 총괄 관리자나 다른 사람들과 비즈니스에서 오픈소스의 중요성에 대해 의견이 불일치하는 경우, 핵심은 언제나 특정 상황에서 어떤 LP에 더 중점을 두느냐의 문제로 귀결됐다. 

예를 들어 “고객 집착”은 모든 아마존인에게 최우선 순위지만, 의미는 맥락에 따라 다를 수 있다. 필자는 오픈소스 기여를 고객 집착 측면에서 중장기적 핵심 요소로 볼 수 있지만 서비스팀 총괄 관리자는 단기적인 관점도 고려해야 한다. 이는 회사가 신속하게 버그를 수정하거나 고객이 요구하는 기능을 제공할 수 있도록 코드의 프라이빗 브랜치를 만든다는 것을 의미한다. 또한 고객이 모두 오픈소스를 좋아하고 원하는 것처럼 보여도 많은 고객이 그 코드를 운영할 수 있도록 만드는 것을 더욱 중시한다. 

이는 단기적으로 매끄러운 고객 경험을 보장하기 위해 엔지니어가 투입되어 프로젝트의 장기적인 성공에 기여할 시간은 그만큼 줄어든다는 것을 의미한다. 필자가 일하는 동안 개선되긴 했지만 2피자 팀으로 가득 찬 회사에는 오픈소스에 대한 통일된 한 가지 접근 방법은 존재하지 않는다. 

이 말은 “소유”, “발명과 간소화”, “최상의 기준 고집”, “결과 제공”과 같은 LP가 오픈소스 프로젝트의 상업적 관리 주체와의 원활한 파트너 관계와 상충하는 듯이 보일 수 있음을 의미하기도 한다. 고객이 더 쉬운 아파치 카프카를 원한다면, 그에 대한 즉각적인 대응은 움직이는 부분을 최소화해서 또는 실패의 가능성을 최소화해서 고객 대신 관리할 수 있는 서비스를 구축하는 것이다. AWS는 경험으로 첫 번째 옵션이 더 쉽다는 것을 알지만, 컨플루언트와 다른 오픈소스 업체의 많은 성공 사례는 고무적이다(카프카의 경우). 

이 분야에서 AWS는 아직 갈 길이 멀지만, 따지고 보면 우리 모두가 마찬가지다. 오픈소스 분야에서 20년 이상 일하면서 필자가 가장 좋아한 점은 오랜 시행착오에도 불구하고 업계 전체(그리고 개인과 각 업체)는 계속 배워야 한다는 것이다. 오픈소스 프로젝트 또는 비즈니스를 구축하고 운영하기 위한 완벽한 방법은 아직 누구도 찾지 못했다. 우리 모두 여전히 배우는 중이다. 

그러니 필자가 AWS에서 노력했던 것처럼 서로 조금씩 더 인내심을 갖고, 한 개인이나 회사가 지금처럼 행동하는 이유를 이해하기 위해 노력해야 할 것이다. editor@itworld.co.kr
 


X