안녕하세요, 주간 SaaS 입니다. 지난주 레터 “SaaS 영업사원을 존중하세요”가 구독자 여러분의 많은 관심을 끌었던 것 같습니다. 아마도 SaaS 조직과 그 구성원들의 역할에 대해 여전히 많은 정보가 알려져 있지 않았던것 같아요. 그래서 SaaS 비즈니스를 이끄는 다양한 역할들을 소개하면 좋겠다는 생각을 하게 되었습니다.
Solutions Architect, Customer Engineer, Sales Engineer 등으로 불리는 역할은 복잡하고 빠르게 변화하는 비즈니스와 적정 기술을 연결하는 중요한 역할을 하며, as a Service 모델의 성공을 이끄는 핵심이 되고 있습니다. 혹자는 이 역할을 SaaS 산업의 이름없는 영웅 이라고도 합니다.
오늘 소개할 글은 아마존과 AWS에서 Solutions Architect로 활약하고 계신 염지원님께서 솔루션 아키텍트의 역할에 대해 소개하는 글입니다.
(*SA라는 직무가 어떻게 고객과 비즈니스에 기여하는지 원작자의 경험이 담긴 다른 글도 꼭 읽어보시면 좋겠습니다)
SA라는 직무가 as a Service 비즈니스 모델에서 고객과 비즈니스에 어떻게 기여 하는지, 그리고 우리만의 as a Service 비즈니스 모델에 필요한 SA의 역할을 정의하는데 너무 좋은 인사이트를 주는 글이 될거라 생각됩니다.
그럼 오늘 하루도 좋은 하루 되세요!
저는 2019년에 처음 솔루션 아키텍트(이하 SA)로 일을 시작했습니다. 솔루션 아키텍트 직군에는 프리세일즈, 솔루션 엔지니어 등 회사마다 다양한 직책이 있습니다. 회사마다 직무에 대한 설명은 다르지만 큰 흐름은 동일합니다. 기술적 전문성을 바탕으로 고객이 회사의 제품을 기술적인 관점에서 잘 사용할 수 있도록 돕는 것이죠. 사실 서버 관리자나 데브옵스 엔지니어로 일할 때는 제 업무를 설명하기 쉬웠는데, SA가 되고 나니 조금 어려웠어요. 이 업계에 오래 종사하지 않으면 실제로 어떤 의미인지 알 수 없으니까요. 그래서 친구들에게 "그래서 새로 맡은 일이 뭐야?"라는 질문을 받으면 열심히 설명하려고 노력했지만 결국 비기술자 친구들에게 "아, 그럼 개발자야?"라는 말을 듣게 되더라고요. 그래서 저는 "비슷하지만 개발자가 아니라 개발자를 돕는 일을 하고 있습니다."라고 더 설명해야 했습니다. AWS에서 아마존의 다른 조직인 Buy with Prime SA로 옮겼을 때는 AWS의 동료 SA들에게도 제가 하는 일을 다시 설명해야 했습니다. 이 업계에서는 이제 모두가 AWS SA가 하는 일을 잘 알고 있지만, Amazon의 SA는 여전히 설명해야 할 것이 많습니다. Facebook SA와 Google Advertising SA도 비슷한 경험이 있을 것입니다. 2023년 7월이 되면 제가 이 설명하기 어려운 일을 시작한 지 3년이 됩니다. 앞으로 이 직업에 대한 저만의 정의를 세우며 좀 더 자세히 들여다보려고 합니다. 이 시리즈는 총 4회에 걸쳐 솔루션 아키텍트가 실제로 무엇인지, AWS와 아마존은 어떻게 다른지, 제가 하는 일상적인 업무는 무엇인지, SaaS 솔루션 아키텍트로 전환한 후 1년 동안 무엇을 배웠는지에 대해 설명하는 것을 목표로 하고 있습니다. 이 글은 제가 속한 회사를 대변하지 않습니다. 제 개인적인 경험과 배움을 공유할 뿐입니다.
그래서 제가 하는 일은...
제 경험상 SA가 하는 일은 크게 세 가지입니다. 회사마다 일상적인 업무에 대한 정의가 매우 다르므로 참고만 하시기 바랍니다.
첫 번째로 중요한 것은 고객을 만나는 것입니다. 고객이 제품을 정확하게 이해하도록 돕고, 이를 잘 설계된 방식(일명 모범 사례)으로 고객의 환경에 도입하는 것입니다. 여기에는 고객 교육, 컨설팅, 제품 데모, 구현 계획 수립 지원 등이 포함됩니다. LinkedIn을 통해 들어오는 제안서를 보면 많은 기업이 솔루션 아키텍트에게 이 업무만 수행하기를 기대하는 것 같습니다. 하지만 더 많은 일이 있습니다.
두 번째는 고객이 더 잘 배울 수 있도록 학습 자료를 만들거나 고객이 제가 담당하는 제품을 사용할 때 직면하는 어려움을 극복하는 데 도움이 되는 도구를 만드는 것입니다. 여기에는 컨퍼런스에 가서 발표하는 것도 포함됩니다. 세 번째는 고객의 피드백을 제품 팀에 꼼꼼하게 전달하여 고객이 원하는 방향으로 제품이 개발될 수 있도록 돕는 것입니다. 저희만큼 고객과 가까이 있는 기술 인력은 없습니다. 그래서 그들의 이야기를 헛되이 흘려 보내서는 안됩니다.
좋은 SA가 되기 위해 해야 할 일
SA가 하는 일은 IT 산업의 변화에 따라 변화해 왔습니다. 과거 데이터센터를 기반으로 IT 시스템이 운영되던 시절에는 하드웨어 업체가 실제로 서버를 가져와 고객 데이터센터에 설치하고, 소프트웨어의 경우 설치 파일을 가져와 고객이 요청한 서버에 설치하는 방식이었죠. 산업 전반이 클라우드로 전환하면서 데이터센터에 들어가지 않는다는 사실에 큰 변화가 생겼습니다. 하지만 이 일의 본질은 변하지 않았다고 생각합니다. 좋은 SA가 되기 위한 SA의 덕목은 세 가지입니다.
제품에 대한 끊임없는 연구
제품을 안다는 것은 제품의 '안팎'을 모두 아는 것을 의미합니다. 제품이 어떻게 작동하는지, 어떻게 작동하는지, 필요한 경우 그 이면의 논리를 알아야 합니다. 클라우드의 경우, 고객이 불필요하게 많은 시간과 노력을 투자할 필요가 없도록 복잡성을 추상화하고 API를 제공하는 것이 제품의 본질입니다. 이것이 우리에게 의미하는 바는 제품이 어떻게 개발되었는지에 대해 얼마나 깊이 파고들 것인지 결정해야 한다는 것입니다. 예를 들어, AWS Fargate는 서버를 관리할 필요 없이 애플리케이션 구축에만 집중할 수 있는 서버리스 종량제 컴퓨팅 엔진입니다. 따라서 고객 입장에서는 AWS가 대신 많은 일을 해주기 때문에 실제로 안전한지 궁금해하는 것이 당연합니다. "AWS가 제대로 관리하지 않아서 다른 사람이 내 애플리케이션을 해킹하면 어떻게 하나요?"라고 질문할 수도 있습니다. 이러한 질문을 해결하려면 이 제품이 실제로 어떻게 설계되고 어떤 방식으로 구성되는지 설명할 수 있을 만큼 지식이 있어야 하므로 그런 문제가 발생할 가능성은 전혀 없습니다. 그러나 다른 한편으로 S3가 어떤 언어로 개발되었고 어떤 로직에 의존하는지 알 필요는 없습니다. 고객도 알 필요가 없기 때문입니다.
제품 내부를 아는 것은 어느 정도 의미가 있지만, 외부에서 제품을 안다는 것은 어떤 의미일까요? 즉, SA로서 우리 제품이 시장에서 어떤 의미가 있는지, 다른 제품과 비교했을 때 장단점은 무엇인지, 내가 고객이 되어도 우리 제품을 사용할 것인지에 대해 이해할 수 있어야 합니다. 영업 교육에서 배운 내용을 반복하거나 마케팅의 특징적인 피치를 뱉어낸다면 고객과 대화를 이끌고 고객이 가이드를 따르도록 설득할 수 없습니다. 대부분의 경우 훌륭한 SA는 스스로를 교사라고 생각하고 기본적인 IT 지식부터 제품의 근간이 되는 작동 원리 및 산업 트렌드에 이르기까지 모든 것을 설명할 수 있어야 합니다. 고객은 이 모든 것을 몰라도 개발, 운영, 생활할 수 있지만 SA는 이 지식이 없으면 살아남을 수 없습니다. 우리 모두가 IT 분야에서 학습이 초능력이고 유일한 상수는 영원한 것은 없다는 데 동의한다면, 그 최전선에 있는 사람들이 바로 SA라고 생각할 수 있습니다.
패턴 찾기
제가 SA로 일하면서 가장 좋아하는 점은 여러 회사와 산업 전반에서 패턴을 관찰할 수 있다는 점입니다. 실제로 많은 고객이 똑같은 문제를 걱정하고, 비슷한 역경에 직면하며, 비슷한 좌절감을 느낍니다. 따라서 이들을 그룹화할 수 있습니다. 예를 들어, 이 정도 규모의 기업이라면 데이터를 분석할 때 이런 문제가 공통적으로 발생하고, 데이터 규모가 어느 정도일 때 어떤 종류의 마이그레이션을 고려해야 하는지 알 수 있습니다. 문제를 패턴화 할 수 있다면 많은 고객에게 좋은 영향을 미치는 해답을 찾을 수 있습니다. 그런 다음 자체 제품이나 오픈 소스 커뮤니티를 활용하여 해답을 구현할 수 있는 도구를 검색할 수 있습니다. 그렇지 않다면 오픈소스 도구를 출시하거나 회사의 제품 방향에 기여하는 등 문제 해결을 위한 멋진 도구 개발의 선봉에설 수도 있습니다.
나만의 고객 되기
고객은 자신이 무엇을 원하는지 모릅니다. 이것이 제가 B2B IT 기업에서 일하면서 고객을 만나면서 배운 가장 큰 교훈입니다. SA는 고객이 자신도 몰랐던 자신의 니즈를 파악하고, 스스로에게 물어보지 않았던 질문을 할 수 있도록 해야 합니다. "저는 아무것도 모르니 설명해 주세요."라고 말하는 사람이 있다면 오히려 더 쉬워집니다. 고객을 위한 특별한 튜터가 되어주거나 이미 잘 정리된 문서와 설명 동영상을 공유할 수도 있습니다. 하지만 고객이 스스로 무언가를 아는 것처럼 상황을 이끌어가다가 상당한 시간이 지나서야 아무것도 모른다는 것을 깨닫는다면 곤란합니다. 온라인 커뮤니티를 운영하며 웹사이트에서 발생하는 일부 소매 거래에 대한 광고 및 서비스 수수료가 주요 수익원인 고객과 기술 미팅을 진행한 적이 있습니다. 비교적 작은 시장을 타깃으로 하는 회사였기 때문에 만나기 전까지는 그 회사에 대해 잘 알지 못했습니다. 제가 그곳에 도착했을 때 그들은 그들이 얼마나 인기가 있는지 자랑했습니다. (하지만 IT 비용으로 볼 때 결코 큰 사이트는 아니었습니다.) 미팅의 목적은 대규모 트래픽을 처리할 수 있는 아키텍처를 제안하기 위해서였습니다. 그들은 이를 실현하기 위해 많은 돈을 쓸 수 있다고 말했지만 몇 가지 질문을 해보니 비용적인 제약이 크다는 것을 깨달았습니다. 따라서 몇 가지 기본적인 체크포인트를 제시하고 장기적인 관점에서 최근 출시된 새로운 칩 기반 EC2 인스턴스 유형으로 천천히 마이그레이션을 시도할 것을 제안했습니다. 고객은 인텔 칩을 포기할 의사가 없으며 ARM이 트래픽을 처리할 수 없다고 말했지만 이는 명백히 사실이 아닙니다. 개인적 선호에 대한 즉각적이고 근거 없는 주장에 약간 놀랐지만 고객을 올바른 방향으로 이끌 수밖에 없었습니다. 저는 그들의 똑똑한 팀원처럼 그들의 지표 검토를 바탕으로 그들의 멋진 하이엔드 인텔 칩이 80% 유휴 상태이며 비즈니스 로직은 CPU 아키텍처와 아무 관련이 없다는 주장을 펼쳤습니다. 요약하자면, 고객이 원하는 것이 무엇인지 깨닫게 하고 고객이 말하는 것을 듣게 해야 합니다. 당시 고객은 인텔 칩을 사용하여 약간의 비용 증가만으로 현재 트래픽의 두 배 이상을 처리하기를 원했습니다. 물론 기대치를 제대로 맞춰야 합니다. 솔루션 아키텍트는 "도대체 무엇을 원하는 걸까?"라고 생각할 수 있는 고객을 만나게 됩니다. 먼저 고객에게 필요한 것이 무엇인지 정의해야 합니다. 여러분은 더 이상 회사의 직원이 아니라 고객 팀의 일원이 됩니다.
자주 화를 내는 고객을 제 팀장이라고 생각해보죠. 화난 것처럼 보이지만 그 안에는 두려움이 담겨 있습니다. 모르는 사람에게서 제품을 사려고 하면 무섭지 않을까요? 게다가 팀장이라는 직책은 업무에 대한 두려움을 극복하는 것이 월급에 포함되어 있기 때문에 당연히 다른 사람들보다 훨씬 더 많은 걱정을 할 것입니다. 일이 잘못될지도 모른다는 걱정, 직원들보다 멍청해 보일지도 모른다는 걱정, 모르는 영업 사원에게 속았을지도 모른다는 걱정, 일이 잘못되었을 때 직면해야 할 결과... 제가 그들을 안정시키고 위로하기 위해 사용하는 방법은 계획을 보여주는 것입니다. 저는 마치 프로젝트 매니저가 된 것처럼 매우 구체적인 실행 항목과 일정에 대해 이야기하며 그들을 이끌고 있습니다. 주요 목표와 종료 기준이 무엇인지, 얼마나 많은 리소스를 투자해야 하는지, 위험이 있다면 어떻게 완화할 것인지 등에 대해 팀원들과 함께 논의합니다. 기본적으로 멋진 말이 아니라 구체적인 계획과 지침을 통해 이 여정 내내 여러분이 함께하고 있다는 확신을 주어야 합니다. 가장 큰 어려움은 - 그들이 종종 말하는 것처럼 - 때때로 길을 잃었다고 느끼고 스스로에게 "그래서 다음은 무엇인가"라고 물어야 하는 상황이라는 것입니다. 우리가 그들의 PM이 될 수는 없지만 큰 그림을 그릴 수 있도록 도울 수는 있습니다.
댓글
의견을 남겨주세요