Solutions Architect 의 덕목

You can make anything
by writing

C.S.Lewis

그래서 제가 하는 일이 뭐냐면요…

내 경험상 SA가 하는 일은 아주 대강 세 가지가 있다. 회사마다 구체적인 모습은 매우 다르니 참고만 하시기를 권한다. 가장 중요한 첫번째는 고객을 만나는 일이다. 고객이 우리 제품을 정확하게 잘 이해하고 아주 적확한 방식으로 그들의 환경에 도입하도록 돕는 것이다. 여기에는 고객들에게 교육해주는 것, 컨설팅, 제품 시연, 도입 계획을 짜는 것을 돕는 것도 포함된다. 링크드인을 통해 들어오는 제안들을 보면 많은 회사들이 이 첫번째 부분만 기대하기도 하는 것 같다. 두번째는 고객들이 더 잘 학습할 수 있도록 학습 자료를 만들거나, 어려움이 있을 때 더 잘 헤쳐나갈 수 있도록 돕는 도구들을 만들어 이를 널리 알리는 것이다. 컨퍼런스에 나가 발표하는 것 등이 포함된다. 세번째는 현장에서 수집되는 고객들의 피드백을 프로덕트 팀에 잘 전달하여 우리 제품이 고객들이 원하는 방향으로 개발될 수 있도록 돕는 것이다. 우리 만큼 고객의 가까이에 있는 기술자들은 없다. 그들이 하는 이야기를 하나도 허투루 들어서는 안된다.

일 잘하는 SA의 덕목

SA가 하는 일은 IT 산업의 변화에 맞춰 바뀌어왔다. 과거 데이터 센터 기반으로 IT 시스템들이 운영되던 때에는, 하드웨어 회사의 경우 실제로 서버를 가지고 고객 데이터 센터에 들어가서 설치해주었고 소프트웨어의 경우 설치 파일을 가지고 가서 고객이 요청한 서버에 설치해주는 것이 주된 모습이었다. 산업 전체 방향이 클라우드로 돌아서게 되면서 데이터센터에 들어가지 않는다는 점이 크게 달라졌다. 그렇지만 이 업의 본질은 그대로라고 생각한다.

제품을 정확히 알기를 멈추지 않을 것

제품을 잘 안다는 것은 ‘안팎’으로 잘 알아야 한다는 것이다. 그 제품이 어떻게 동작하는지, 필요한 경우 동작 원리까지 알아야 한다. 클라우드의 경우 제품의 본질이 고객들이 시간과 노력을 불필요하게 많이 들여서 해야 했던 것들을 우리가 잘 추상화해서 API로 제공한다는 것이다. 그 말인 즉슨 제품이 어떻게 개발되었는지 파고들 깊이를 정해야 한다는 말이다. 예를 들어 AWS Fargate 의 경우 컨테이너가 돌아갈 호스트 서버까지 AWS에서 관리형으로 제공하는 것인데, 고객 입장에서 이게 실제로 안전한지 궁금할 것이 아닌가? AWS에서 관리 잘못해서 다른 사람이 내 어플리케이션을 해킹한다면? 이런 의문들을 원천적으로 해결하기 위해서는 이 제품이 실제로 어떤 식으로 설계 및 구성이 되어 있어서 그런 문제가 발생할리가 전혀 없다는 것을 설명할 수 있어야 한다. 그렇지만 사사로이 S3가 어떤 언어로 개발돼서 어떤 로직으로 돌아가는지 등등은 알 필요가 없다. 고객이 알 필요 역시 없는 일이기 때문에 그렇다.

이것이 제품의 안을 잘 아는 일이라면, 밖을 잘 아는 것도 중요하다. 우리 제품이 시장에서 갖는 의미가 무엇인지, 다른 제품들 대비 장점은 뭐고 단점은 뭔지, 내가 고객이라고 생각했을 때에도 쓸 제품인지 나 스스로 납득할 수 있어야 한다. 세일즈 교육 어디에선가 굴러나온 문장들을 외워서 말하는 수준 밖에 되지 않는다면 내가 고객을 설득하고 상황을 주도할 수 있을리 전혀 없다. 일 잘하는 SA는 자신을 선생님이라고 생각하고, 이 제품의 기반이 되는 IT 기본 지식부터 출발해서 동작 원리, 산업 동향 등등 모두를 설명할 수 있어야 한다. 고객들은 이 모든 것을 모르고도 개발하고 운영하며 살 수 있지만 SA들은 그렇지 않다. IT업계에 있는 사람들의 덕목이 새로운 것을 배우기를 두려워하지 않는 것이 이제 일반 명제라면, SA들은 그 최전선에 있는 사람들이다.

패턴 찾기

내가 SA일을 하면서 가장 좋아하는 것은, 여러 회사에 걸쳐 공통적으로 발견되는 것들을 관찰할 수 있다는 것이다. 많은 고객들이 사실 같은 문제를 고민하고 비슷한 역경에 부딪히며 비슷하게 좌절한다. 그래서 그들을 그룹화할 수 있다. 예를 들어 이 정도 규모가 되는 회사에서는 데이터 분석을 하려고 할 때 이런 문제가 공통적으로 있구나, 데이터 사이즈가 보통 얼마가 되면 어떤 방식으로 마이그레이션 생각을 해야 하는구나 등등이 있다. 이렇게 문제를 패턴화 할 수 있으면 답을 찾아줄 수 있다. 그리고 지금 우리 회사, 혹은 오픈소스 커뮤니티 전체를 통틀어 이 문제를 해결할 만한 도구들이 충분히 있는지 알아볼 수 있다. 만약에 없다면 내가 그 문제를 해결하는 선봉에 설 수도 있다. 그것이 오픈소스 툴을 시작하는 것이든, 회사 제품 방향에 기여하는 것이든 그렇다.

고객이 될 것

고객은 스스로가 원하는 게 뭔지 잘 모른다. 내가 B2B IT 외국계 회사를 다니며 고객들을 만나면서 가장 크게 배운 것이다. SA는 고객이 자기도 모르던 자기의 니즈를 파악하고, 지금껏 스스로에게 묻지 않았던 질문을 하게 해야 한다. “저 다 모르겠으니까 설명 좀 해줘봐요”하고 나오신다면 차라리 쉽다. 과외 선생으로 빙의해서 알려드리거나 이미 잘 정리되어 있는 문서, 설명 영상들을 공유하면 된다. 그런데 뭔가 스스로 알고 있는 것처럼 고객이 상황을 주도해가는데 알고보니 잘 모른다면 곤란하다. 예전에 한 고객과 기술 미팅을 한 적이 있는데, 그 회사는 온라인 커뮤니티를 운영하면서 거기에서 광고 수익을 얻기도 하고 일부 상품 거래에 대한 수수료를 받기도 하는 회사였다. 나는 사실 잘 모르는 커뮤니티였는데 그들의 세계에서는 꽤나 잘 나간다고 했다. (그렇지만 그들의 클라우드 비용으로 미루어볼 때 절대 큰 사이트는 아니었다.) 미팅이 잡힌 이유는 대규모 트래픽을 받을 수 있는 아키텍처를 제안 받고 싶어서였다. 사전에는 무엇이든 할 것처럼 이야기했지만 가서 질문을 몇 가지 해보니 비용 제약이 아주 큰 상황이었다. 그래서 몇 가지 기본적인 점검 포인트를 제시하고, 보다 장기적인 관점에서 최근에 출시된 신규 칩 기반의 EC2 인스턴스 타입으로 전환 시도를 해보는 것을 제안했다. 고객은 자기는 절대 인텔 칩을 포기할 생각이 없고 ARM 은 자신들의 트래픽을 감당할 수 없다고 말했다. 너무도 즉각적이고 그다지 근거도 없는 자기 개인 선호 주장에 살짝 당황했다. 그들의 고급 인텔칩은 팽팽 놀고 있었고 로직을 들어보니 CPU 아키텍처에 대단히 영향을 받을 것도 없었다. 정리해보자면 이 고객은 비용은 현재보다 아주 약간만 올라가는 선에서, 2배 이상되는 트래픽을 받으면서, 인텔 칩을 사용하고 싶어했다. 당연히 그럴 수 없다. “어쩌자고 이러시는 걸까” 싶은 고객들을 만나게 되지만 우리는 그들이 필요로 하는 것부터 같이 정의해줄 수 있어야 한다. 더 이상 다른 회사 직원이 아니라 그냥 고객의 팀원이 되는 것이다.

종종 화가 난 것처럼 보이는 이 고객을 내 팀장이라고 생각해보자. 그는 화가 난 듯 보일지 몰라도 그 안에는 두려움이 있다고 생각한다. 쌩판 모르는 남의 회사 제품을 들이려고 할 때 무섭지 않을까? 게다가 팀장이면 두려움을 업무에 포함시키고 돈을 더 받는 사람들인데, 당연히 다른 사람들보다 훨씬 더 많이 걱정이 될 것이다. 이것은 일이 잘못될 것에 대한 걱정, 내가 아래 직원들보다 멍청해보일 것에 대한 걱정, 이 다른 회사 놈들에게 속은 것은 아닐까에 대한 걱정, 만약에 내가 잘못 결정하면 무슨 일이 일어날까 싶은 노파심… 내가 이들을 안정시키기 위해 쓰는 방법은 프로젝트 플랜을 보여주는 것이다. 지금 미팅룸에 앉아 있는 여러분들이 전적으로 시간을 투자한다고 하면, 우리가 지금까지 논의한 이 모든 것을 실행하기 위해 이런 액션 아이템들을 수행해야 하고, 아마도 시간은 이 정도 걸릴지도 모르는데 그것은 우리가 앞으로 같이 정의해나갈 것이고, 잘된다면 이런 긍정적인 영향이, 잘 안된다면 이런 위험이 있을 것인데 그런 상황이 발생했을 때 우리 쪽에서는 이런 사람들이 여러분을 도와줄 것임을 알려주는 것이다. 고객들은 ‘그래서 내가 다음에 뭐해야지?’를 모르는 상황, 그들이 독박써야 하는 상황을 제일 어려워한다. 내가 그들의 PM이 되어줄 수는 없지만, 밑그림 잡아주는 역할 정도는 해줄 수 있다.

brunch