솔루션 아키텍트(SA)의 역할

솔루션 아키텍트(SA)의 역할

저는 2019년에 솔루션 아키텍트(이하 SA)로서의 업무를 시작했습니다. 솔루션 아키텍트 직군은 회사마다 다양한 직함을 가지고 있습니다. 예를 들어, 프리세일즈, 솔루션 엔지니어 등이 있습니다. 회사마다 직무 설명은 다르지만, 핵심은 동일합니다. 기술적 전문성을 바탕으로 고객이 회사의 제품을 잘 활용할 수 있도록 돕는 것입니다. 사실 서버 관리자나 DevOps 엔지니어로 일할 때는 제 업무를 설명하기가 쉬웠지만, SA가 되고 나서는 설명하기가 어려워졌습니다. 이 업계에서 오랫동안 일하지 않은 사람은 실제로 무슨 일을 하는지 이해하기 어렵기 때문입니다. 그래서 친구들이 제 새로운 직업에 대해 물어볼 때, 설명을 하다가 결국 “그럼 개발자야?”라는 반응을 많이 받았습니다. 그럴 때마다 “비슷하지만, 나는 개발을 돕는 역할을 해”라고 더 설명해야 했습니다.

 AWS에서 아마존의 또 다른 조직인 Buy with Prime으로 SA로 전환했을 때도, AWS의 SA에게조차 제 역할을 설명해야 했습니다. 이 업계에서는 AWS SA가 무슨 일을 하는지 잘 알고 있지만, 아마존의 SA에 대해서는 아직도 설명할 것이 많습니다. 페이스북이나 구글 광고의 SA도 비슷한 경험을 할 것입니다. 2023년 7월이 되면 이 설명하기 어려운 직업을 시작한 지 3년이 됩니다.
이제 이 직업에 대해 제 나름대로 정의를 내리며 더 자세히 탐구해보려 합니다. 이 시리즈는 총 네 개의 기사로 구성되며, 솔루션 아키텍트가 실제로 무엇인지, AWS와 아마존 간의 차이점, 일상적인 업무 및 SaaS 솔루션 아키텍트로서의 1년간의 배움을 설명할 것입니다. 단, 이 글들은 제 개인적인 경험과 배움을 공유하는 것이며, 제가 속한 회사의 입장을 대변하지 않습니다.

제가 하는 일은…

제 경험에 따르면, SA가 하는 일은 크게 세 가지로 나눌 수 있습니다. 각 회사마다 일상적인 업무에 대한 정의가 다르므로 참고용으로만 사용하시기 바랍니다. 첫 번째 중요한 일은 고객을 만나는 것입니다. 이는 고객이 우리의 제품을 정확히 이해하고, 이를 잘 설계된 방식으로(즉, 모범 사례) 환경에 도입하도록 돕는 것입니다. 여기에는 고객 교육, 컨설팅, 제품 시연, 구현 계획 수립 등이 포함됩니다. 많은 회사들이 솔루션 아키텍트에게 이 일만을 기대하는 것 같지만, 사실 더 많은 일이 있습니다. 두 번째는 고객이 제품을 더 잘 배울 수 있도록 학습 자료를 만들거나, 제품 사용 시 겪는 어려움을 극복할 수 있는 도구를 만드는 것입니다. 이를 위해 컨퍼런스에 참석하여 발표하기도 합니다. 세 번째는 고객의 피드백을 제품 팀에 세심하게 전달하여 제품이 고객이 원하는 방향으로 발전하도록 돕는 것입니다. 기술적인 측면에서 고객과 가장 가까운 사람은 우리입니다. 고객의 이야기를 놓쳐서는 안 됩니다.

좋은 SA가 되기 위한 조건

IT 산업의 변화에 따라 SA의 역할도 변화하고 있습니다. 과거 데이터 센터 기반의 IT 시스템 운영 시절에는 하드웨어 회사가 실제로 서버를 고객의 데이터 센터에 설치하거나, 소프트웨어 설치 파일을 서버에 설치했습니다. 그러나 산업 전반이 클라우드로 전환되면서 데이터 센터에 들어가지 않는 것이 큰 변화가 되었습니다. 하지만 이 직업의 본질은 변하지 않았다고 생각합니다. 좋은 SA가 되기 위한 세 가지 덕목을 소개합니다.

  1. 제품에 대한 끊임없는 학습

    제품을 안다는 것은 제품의 ‘속속들이’를 아는 것입니다. 제품이 어떻게 작동하는지, 왜 그런 방식으로 작동하는지, 필요한 경우 그 논리까지 알아야 합니다. 클라우드의 경우, 제품의 본질은 복잡성을 추상화하여 고객이 불필요한 시간과 노력을 투자하지 않도록 API를 제공하는 것입니다. 따라서 제품이 어떻게 개발되었는지에 대해 얼마나 깊이 파고들 것인지 결정해야 합니다. 예를 들어, AWS Fargate는 서버를 관리하지 않고 애플리케이션을 구축할 수 있게 해주는 서버리스 컴퓨팅 엔진입니다.

    고객은 AWS가 많은 일을 대신해주기 때문에 실제로 안전한지 궁금해할 수 있습니다. 이러한 질문을 해결하려면 제품이 어떻게 설계되고 구성되었는지 설명할 수 있을 정도로 충분히 알아야 합니다. 그러나 S3가 어떤 언어로 개발되었는지, 어떤 논리에 의존하는지는 알 필요가 없습니다. 고객도 알 필요가 없기 때문입니다.

    제품의 내부를 아는 것은 이해가 되지만, 외부를 아는 것은 무엇을 의미할까요? SA로서 우리 제품이 시장에서 어떤 의미를 가지는지, 다른 제품과 비교했을 때의 장단점은 무엇인지, 내가 고객이 되었을 때 우리 제품을 사용할 것인지 이해해야 한다는 뜻입니다. 세일즈 교육에서 배운 것을 반복하거나 마케

    좋은 SA는 교사처럼 기본적인 IT 지식부터 제품의 운영 원리와 산업 동향까지 모든 것을 설명할 수 있어야 합니다. 고객은 이를 몰라도 개발, 운영, 생활할 수 있지만, SA는 이를 모르면 살아남을 수 없습니다. 학습이 IT에서의 슈퍼 파워이고 유일한 상수는 변화뿐이라는 사실에 모두가 동의한다면, SA는 그 최전선에 있는 사람들입니다.
  2. 패턴 찾기

    SA로 일하면서 가장 좋아하는 것은 여러 회사와 산업에서 패턴을 관찰할 수 있다는 것입니다. 많은 고객이 사실 동일한 문제를 걱정하고, 비슷한 어려움에 직면하며, 비슷하게 좌절합니다. 그래서 이를 그룹화할 수 있습니다. 예를 들어, 특정 규모의 회사는 데이터 분석 시 공통적으로 이런 문제를 겪고, 데이터 크기에 따라 어떤 마이그레이션을 고려해야 하는지 알 수 있습니다.

    문제를 패턴화하면 많은 고객에게 긍정적인 영향을 미칠 수 있는 답을 찾을 수 있습니다. 그런 다음 자신의 제품이나 오픈 소스 커뮤니티를 활용하여 해결책을 구현할 도구를 찾을 수 있습니다. 그렇지 않으면, 문제를 해결하기 위한 멋진 도구를 개발하는 선두에 설 수도 있습니다. 오픈 소스 도구를 출시하거나 회사 제품의 방향을 결정하는 데 기여하는 것입니다.
  3. 자신이 고객이 되기

    고객은 종종 자신이 무엇을 원하는지 모릅니다. 이는 제가 B2B IT 회사에서 일하며 고객들을 만나면서 배운 가장 큰 교훈입니다. 솔루션 아키텍트는 고객이 스스로 알지 못했던 필요를 파악하게 하고, 그들이 이전에 스스로에게 던지지 않았던 질문을 던지도록 해야 합니다. 누군가가 “저는 아무것도 모르니 모든 것을 설명해 주세요”라고 말한다면 오히려 더 쉽습니다. 그들에게 특별한 튜터가 되거나, 이미 잘 정리된 문서와 설명 영상을 공유하면 되기 때문입니다. 그러나 고객이 자신이 뭔가를 알고 있는 것처럼 상황을 주도하다가, 시간이 지나서야 자신이 아무것도 모른다는 것을 깨닫는 경우는 어렵습니다.

한 번은 광고와 소매 거래 수수료로 수익을 창출하는 온라인 커뮤니티를 운영하는 고객과 기술 회의를 가졌습니다. 이 회사는 비교적 작은 시장을 대상으로 했기 때문에, 만나기 전까지는 잘 알지 못했습니다. 그들을 만났을 때, 그들은 얼마나 인기가 있는지 자랑했습니다. (그러나 IT 비용을 고려할 때 결코 큰 사이트는 아니었습니다.) 회의의 목적은 대규모 트래픽을 처리할 수 있는 아키텍처를 제안하는 것이었습니다. 그들은 많은 돈을 투자할 수 있다고 했지만, 몇 가지 질문을 하자 엄청난 비용 제약이 있다는 것을 깨달았습니다. 따라서 우리는 기본적인 체크포인트를 제시하고, 장기적인 관점에서 최근에 출시된 새로운 칩 기반 EC2 인스턴스 유형으로 점진적으로 전환할 것을 제안했습니다. 그러나 고객은 Intel 칩을 포기할 생각이 없으며 ARM이 그들의 트래픽을 처리할 수 없다고 주장했습니다. 이는 분명히 사실이 아니었습니다. 저는 개인적인 선호도에 기반한 즉각적이고 근거 없는 주장에 놀랐지만, 올바른 방향으로 이끌 수밖에 없었습니다. 그들의 팀에서 데이터 측정 항목을 검토하고, 고급 Intel 칩이 80% 유휴 상태이며, 비즈니스 로직이 CPU 아키텍처와 아무런 관련이 없다는 점을 논리적으로 설명했습니다.

결론적으로, 고객이 자신이 무엇을 원하는지 깨닫게 하고, 그들의 말을 듣게 해야 합니다. 당시 제 고객은 현재 트래픽의 두 배 이상을 처리하면서도 비용은 조금만 증가시키기를 원했습니다. 물론 기대치를 조정해야 합니다. 솔루션 아키텍트로서 우리는 때때로 “도대체 무엇을 하고 싶은 거지?”라고 생각하게 만드는 고객을 만날 것입니다. 먼저 그들의 필요를 정의해야 합니다. 이제 당신은 더 이상 회사의 직원이 아니라, 고객 팀의 일원이 된 것입니다.

자주 화를 내는 고객을 팀 리더라고 생각해 봅시다. 그들은 화를 내는 것처럼 보이지만, 그 안에는 두려움이 있습니다. 잘 모르는 사람에게 제품을 구매하려 할 때 무섭지 않겠습니까? 게다가 팀 리더로서 직무의 두려움을 극복하는 것도 그들의 업무의 일환이기 때문에, 다른 사람들보다 훨씬 더 걱정할 것입니다. 일이 잘못될 수 있다는 걱정, 직원들보다 어리석어 보일 것이라는 걱정, 이 무작위한 영업 사원들에게 속았을지도 모른다는 걱정, 일이 잘못되었을 때 직면해야 할 결과들… 제가 그들을 안정시키고 위로하는 방법은 계획을 보여주는 것입니다. 프로젝트 매니저처럼 매우 구체적인 행동 항목과 타임라인을 이야기하며 이끌어갑니다. 우리는 팀으로서 우리의 주요 목표와 종료 기준, 투자해야 할 자원, 잠재적인 위험이 있다면 그것을 어떻게 완화할 것인지 등을 논의합니다. 기본적으로, 화려한 말보다는 구체적인 계획과 지침으로 그들이 이 여정에서 혼자가 아니라는 확신을 주는 것입니다. 고객들이 자주 느끼는 가장 큰 어려움은 때때로 방향을 잃고 “그 다음에는 무엇을 해야 하지?”라고 스스로에게 묻게 되는 상황입니다. 우리는 그들의 프로젝트 매니저는 아니지만, 그들이 큰 그림을 그릴 수 있도록 확실히 도울 수 있습니다.
본 글은 Jiwon Yeom의 What does a Solutions Architect do?를 의역한 글입니다. 링크에 방문하여 원문과 더 다양한 글을 만나보세요!

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *