AWS가 아닌 아마존에 SA가 왜 필요해?
클라우드 아키텍트와 SaaS 아키텍트의 차이
내가 아마존에 간다고 했을 때 10명 중 8명은 “오 개발자로 가는 거야?”라고 물었다. 원래대로 SA로 간다고 답하면 “아마존에 SA가 왜 필요해?”라고 물었다. 나의 사회생활용 한 줄 답변은 “AWS처럼 아마존에도 API를 기반으로 하는 IT 제품이 있고, 내가 새로 가는 팀이 그런 제품을 가진 팀이라서 다른 파트너나 고객들이 잘 사용할 수 있게 하는 일을 한다”는 것이다. 이 말은 틀린 말은 아니지만 내가 하는 많은 일들, 지난 1년간 겪은 어려움, 그 모든 것 뒤에 배운 것들을 정확히 표현해주지도 못한다. 그래서 내가 AWS에서 SA로 일할 때와 아마존 (Buy with Prime) SA 팀에서 일하면서 느낀 가장 큰 차이점, 그 과정에서 배운 점들을 정리해 봤다. 한 줄로 그 차이점을 요약하자면, 직접 고객이 비기술직군이라는 것이고 그에 따라 내가 함께 일하는 ‘파트너’의 정의가 바뀌었다는 것이다.
1. Solutions Architect 의 덕목 - 아니 너 그래서 하는 일이 뭔데? 에 대한 긴 답변
2. 클라우드와 소프트웨어 SA의 차이점
3. SaaS SA가 하는 일 (1) - 아니 너 그래서 하는 일이 뭔데?에 대한 조금 더 구체적인 답변
4. SaaS SA가 하는 일 (2) - 내가 내리는 기술적 결정들
클라우드 SA이면 기술적으로는 일단 어느 정도는 제너럴리스트가 되어야 한다. 전체적인 네트워크 구성부터 어떤 컴퓨팅 플랫폼을 사용해서 개발된 애플리케이션을 호스팅 할 것인지, 데이터는 어떤 DB에 저장할 것인지, 보안 설정은 어떻게 할 것인지 등등 아주 큰 구성을 봐야 한다. 그렇다 보니 사실 실제 개발된 애플리케이션을 자세히 볼 일은 별로 없었다. 그 애플리케이션은 고객의 비즈니스를 수행하는 핵심이기에, AWS 입장에서 그것을 볼 수 있어서도 안 됐다. 애플리케이션은 내가 설계해야 하는 그림 안에 포함되는 많은 것들 중 한 가지일 뿐이었다.
내가 AWS SA로서 고객들을 만날 때에는 그들이 내가 대표하는 제품의 ‘사용자’들이었다. 말 그대로 고객이었다. 나는 그들이 AWS를 더 잘 사용할 수 있게 도와주는 일종의 서비스 그 자체였다. 그래서 나는 늘 그들이 하는 대부분의 질문에 답을 할 수 있어야 하고 그들을 주도하여 어디론가 끌고 갈 수 있어야 했다. 내가 그들을 끌고 가는 어딘가는 ‘AWS를 사용하기 시작’이거나 ‘아주 잘 사용하게 되는 경지’였다. 내가 고객을 만날 때 나의 목적은 그들을 성공시키는 것, 그것 하나였다. 내가 일을 하며 느끼는 가장 큰 보람 중 하나는 그들에게 AWS 클라우드를 가르치고 실제로 사용할 수 있게 연습시키고 마침내 진짜 프로젝트에 도입시키는 일이었다. 말하자면 내가 과외를 하며 학생들 성적이 실제로 올라가는 것을 지켜봤을 때 느꼈던 보람과 비슷한 종류의 것이다. 다만 주제가 이제 수백만 요청을 1초에 모두 처리하려면 어떻게 해야 하는지, 절대 보안 사고가 나지 않는 안전한 구성을 어떻게 만들 수 있는지로 옮겨간 것이다. 이때에도 파트너사들과 함께 일을 하게 되는데 이 파트너사들은 보통 나의 가이드와 고객의 요구사항을 명확히 알고 이행하는 역할을 하게 된다.
SaaS 프로덕트의 SA가 된다는 것은 아주 다른 일이었다. 일단 SaaS 프로덕트가 있는 팀에 갈 때는 먼저 생각해봐야 하는 게 고객이 누구인지이다. 클라우드와 달리 SaaS는 직접 사용자가 개발자 같은 기술 직군 사람이 아닐 수 있다. Buy with Prime의 예를 들면 우리 프로덕트의 사용자는 리테일 사업자들이다. 가내수공업으로 만든 공예품을 파는 아주 작은 상인일 수도 있고 수 만 명의 사람들이 사랑하는 브랜드일 수도 있다. 이렇게 고객이 비 기술 직군일 때, 고객들이 우리 제품을 잘 이해하고 쓸 수 있게 도와주던 나 같은 사람들은 크게 두 분류로 나눠지게 된다. 한쪽은 고객이 제품을 완벽하게 최적의 방향으로 잘 사용할 수 있게 해주는 쪽이다. 그 SaaS 제품의 과외 선생님이 되는 것이다. 다른 한쪽은 그 사용자들의 경험을 더 개선하거나 확장할 수 있도록 다른 회사들과 파트너십을 맺는 것이다. 달리 말해 사용자들을 위한 생태계를 만드는 것이다. 예를 들어 한 쇼핑몰에서 뭔가를 사려고 한다고 생각해 보자. 아마 구글이나 카카오 계정으로 로그인하겠냐고 물어볼 것이다. 그리고 결제할 때가 되면 네이버페이나 카카오페이로 결제하고 싶냐고 물을 것이다. 이게 가능한 이유는 그 쇼핑몰의 나 같은 사람들이 구글, 카카오, 네이버의 API를 활용해서 시스템들끼리 연결을 해놓았기 때문이다. 이렇게 SaaS 환경에서의 SA 역할을 한다면, 나는 후자이다. 고객들의 의견과 경험에 늘 귀를 기울여야 하지만 내가 매일 같이 만나는 사람은 다른 SaaS 회사의 사업개발, SA이거나 프로덕트 매니저이다. 그들과 정말 파트너가 돼서 같이 힘을 합쳐 우리의 공통 고객인 사용자를 위해 어떤 경험을 제공할 것인지 결정하고, 그것이 서로가 가진 솔루션들을 합침으로써 가능한지 그렇지 않다면 어떻게 무슨 도구를 사용하여 개발할 것인지 등을 논의한다. 이것은 여러 가지를 의미한다. 첫 번째는 원래 내가 클라우드 아키텍트로서 보던 그림에서 아주 일부분이기만 했던 애플리케이션이 이제는 메인이 됐다는 얘기이다. 두 번째는 파트너사는 더 이상 내 방침을 그저 이행만 하는 사람이 아니고, 한편으로는 내 고객이기도 한데 그들은 내가 가르쳐야 하는 존재는 또 아니라는 점이다. 내가 우리 시스템을 그들에게 알려주는 만큼 나도 그들의 시스템을 배워야 하기 때문이다. 우리는 말 그대로 파트너이다.
나는 머리로는 이걸 이해하면서도 일하는 중에 큰 실수를 저지르고 나서야 완벽하게 체화하게 됐다. 우리가 고객인 상인들을 위해 제공하고 싶은 제품 경험이 있었고, 그걸 해내기 위해 이미 그 분야에서 고객들의 인정을 받고 있는 파트너들과 일을 하기 시작했다. 나는 그중 한 파트너를 담당하게 됐다. 그들의 제품을 이해하고 지금 우리 쪽에서 준비된 API 들을 확인해서, 우리가 원하는 경험을 전달하기 위해 어떤 솔루션을 만들어야 하는지 디자인하는 일이었다. 우리는 모두 그들을 ‘파트너’라고 불렀지만 나에게는 고객에 가까웠다. 고객의 비즈니스를 이해하고 그들의 기존 시스템을 잘 안 뒤에 더 좋은 아키텍처를 제안할 수 있는 것처럼, 나는 그들의 문서를 열심히 읽었고 기능들을 테스트해보며 뭘 만들 수 있을지 파악했다. 그렇지만 일의 속성이 바뀌고 묘하게 역할이 바뀌다 보니 감이 잘 오지 않았다. 어디까지 알아야 하고 어디서부터는 PM이나 다른 사람들한테 맡겨야 하는지 등등이 헷갈렸다. 나는 묻지 않았다. 그저 그들을 내 서비스를 받는 고객이라고 생각하고 접근했다. 그래서 내가 정답이라고 생각하는 아키텍처를 그린 뒤 실제 구현 기획까지 면밀하게 준비해서 일을 진행시켰다. 꼭 필요한 부분에 대한 아주 구체적인 질문만을 파트너들에게 물었을 뿐이지, 전체적인 그림에 대해서 알려준 적은 없었다. 그저 완성품을 보여줘야 한다는 생각이었다. 내가 AWS SA일 때 내 사고 과정을 하나하나 보여준 적은 없이 모든 고민을 끝낸 뒤 뭔가 제안했던 것처럼 말이다. 특히 이 ‘경험’을 같이 만들어나간다는 것은 ‘뭘 개발할지’를 같이 논의한다면 ‘어떻게 개발할지’는 각자가 알아서 해야 한다고 생각해서 충분히 커뮤니케이션을 하지 않았다. 나 역시 파트너사 제품의 사용자이며, 최초로 사용하는 사람으로서 그들의 제품을 완벽하게 이해하고 설루션을 기획하기란 어렵다는 것을 완전히 간과했다. 그 결과 내가 만든 아키텍처가 계획까지 포함하여 수행사에게 넘어가고 나서야, 그 파트너가 “이거 아닌데?”라고 의아한 반응을 보내왔다. 내가 그들의 문서를 곡해한 부분이 있었기 때문이었다. 그 파트너는 나를 질책하지 않았고, 내가 만들고 싶은 걸 말해주면 어떻게 할 수 있을지 역으로 제안을 해주겠다고 얘기했다. 이 모든 대화가 생경했다. 그간 회사 외부의 제3자와 대면해 온 모든 순간, 일을 하는 건 나였고 고객은 의사결정을 하거나 인풋을 줄 뿐, 나를 위해 뭔가 만들어주지는 않았기 때문이다. 그때 깨달았다. 우리는 정말 ‘파트너’라는 것, 각자 다른 회사 소속이지만 고객을 위해 ‘같이’ 일한다는 것.
내가 Buy with Prime 팀에서 1년 간 SA로 일하면서 가장 크게 느낀 점은 나는 이제 영업 소속이 아니라 프로덕트 개발 소속이라는 것이었다. 고객이 내 제품을 잘 쓰길 바라는 것보다도, 그들에게 주는 제품을 어떻게 확장할 것인지 더 많이 고민하기 때문이다. SaaS 하는 조직으로 온다는 게 어떤 의미였는지 1년 전에 좀 더 잘 알았다면 조금 덜 실수할 수 있었을 텐데. 1년간 가장 크게 배운 점을 되짚는 한 편, 다른 분들께도 SA라는 직군 안에서 다양한 기회를 탐색하고 계시다면 조금이라도 도움이 되었으면 좋겠다.
