새로운 기술이 아무리 좋다 한들 팔려야 가치가 생긴다. 그런데 기술적인 설명만으로는 기술을 판매하는 게 잘 되지 않는다. 조금 더 적극적이고 포괄적인 접근법이 필요하다.

[보안뉴스 문정후 기자] 핀옵스(FinOps)라는 것이 세계 최초로 정식 서비스되기 시작할 때 필자도 그 과정에 관여하고 있었다. 그 때 우리는 우리가 하는 일들을 핀옵스라 부르지 않았고, ‘클라우드 금융 오피스(Cloud Financial Office)’라고 명명했었다. 핀옵스라는 말은 한참 나중에 나왔다. 한 고객사와 회의를 할 때였다. 그 회사의 IT 결정권자와 재무 결정권자와 만나는 자리였고 우리는 최적화를 위한 방법을 제안하려 했었다. 그 방법이란 소프트웨어 플랫폼의 규모를 딱 맞게 만드는 것이었다. 그래서 각종 컴퓨팅 관련 인스턴스들로 가득한 보고서를 작성해 제출했고, 우리는 그 인스턴스들을 줄이거나 종료시켜야 최적화가 가능하다고 결론을 맺었다.


보고가 끝나고 재무 책임자가 IT 책임자에게 질문을 했다. 보고서에 나온 자원들이 누구 소유이며, 따라서 지금의 최적화를 방해하는 것이 누구의 책임이냐는 것이었다. 그러자 IT 책임자는 우리의 보고서를 다시 들춰봤다. 그러더니 놀랍게도 자신의 기술 분야 팀원에게 전화를 걸기 시작했다. 클라우드 금융 오피스라는 개념이 새로운 것이긴 해도, 현재 상태의 네트워크 상태를 기술 분야 책임자가 잘 몰라서 직원에게 전화를 한다는 사실에 우리는 갑자기 불편해졌다. 뭔가 나쁜 일이 일어날 것 같았다.

곧 그 직원이 회의실에 도착했고 IT 책임자(즉, CTO)는 왜 이렇게 불필요한 인스턴스가 많은지 설명하라고 요구했다. 해당 직원은 말을 잇지 못했다. 갑자기 들어온 질문에 당황한 기색이 역력했다. 어떤 의도로 그런 질문이 나오고 있는지, 어떤 맥락의 회의가 진행되고 있었는지, 이 회의의 목표가 무엇인지, 심지어 우리가 누구며 뭐하러 그 자리에 있는 건지, 아무런 배경 설명도 없이 왜 네트워크에 노이즈가 많은지를 물으니 누구라도 그랬을 것 같다. 그는 우리가 제출한 보고서를 읽기 시작했다. 물론 읽는 내내 CTO와 CFO의 따가운 시선이 그를 향해 고정되어 있었다. 곧 그 직원은 답변을 내놓기 시작했다. 왜 우리의 보고서가 틀렸는지에 관한 내용이 거의 전부였다. 그러자 CTO와 CFO는 누구 말이 맞는지 헷갈리기 시작했다.

순식간에 서로가 서로를 불신하게 된 상태에서 우리는 전부 그 자리에서 조용히 앉아있을 뿐이었다. 아무도 무슨 말을 어떻게 꺼내야할지 몰랐다. 그래도 어떻게 시간은 흘러갔고, 손님이었던 우리는 그 방을 나왔다. 사업적 성과는 둘째치고 중요한 교훈을 가슴에 품은 상태였다. “이런 식으로 고객과 대화를 해서는 안 된다!”는 것이 바로 그 교훈이었다. 그리고 다시는 그런 실수를 반복하지 않았다.

그 다음에도 여러 고객들에게 기술적인 특장점을 설명해야 할 일은 많이 있었다. 우리는 대화의 톤을 바꿨고, 그 결과 훨씬 나은 반응들을 높은 확률로 이끌어낼 수 있었다. 그렇게 하니 고객들 역시 그들이 핀옵스를 통해 이루고자 하는 일들을 보다 빠르게, 그리고 효과적으로 얻어내기 시작했다. 그렇다면 우리는 어떻게 우리의 접근법을 변경시켰을까? 다음과 같다.

1. 핀옵스에 대한 이해도부터 장착시킨다
CTO부터 만나 핀옵스에 대해 설명하기 전에 조직 내 더 많은 사람들을 만나 우리 자신을 소개하기 시작했다. 우리가 어떤 일을 하며, 우리의 핀옵스 서비스가 어떤 장점을 가지고 있는지 무겁지 않게 설명했다. 혹시 핀옵스에 대해 잘 모를 독자들을 위해 이 자리를 빌어 간단히 설명하자면, 클라우드 운영 비용을 효과적으로 절감할 수 있도록 돕는 서비스라고 볼 수 있다. 클라우와 관련된 비용을 효과적으로 운영하고 조정하고, 보고할 수 있도록 베스트 프랙티스를 맞춤형으로 개발하고 공유해 조직 내에서 널리 퍼트리는 게 핀옵스의 역할이다.

여기서 한 가지 오해가 생길 수 있다. 잘못 설명했다가는 또 다른 엄격한 규정 정도로 핀옵스를 이해하게 된다. ‘가뜩이나 생각하고 지켜야 할 규정이 그렇게 많은데 뭐가 더 생긴다고?’라는 생각이 들어가는 순간 모두 핀옵스를 싫어하게 된다. CTO를 통해서만 핀옵스를 도입하면(즉, 아무런 설명없이 지켜야 할 것들만 항목화 하여 전달되면) 100% 이런 절차를 밟게 된다. 그러면 조직 내에 긍정적인 변화를 이끌어낼 수 없다.

2. 요청 사항과 수정 사항보다 시급한 건 관계 구축이다
핀옵스 팀에 대한 소개가 어느 정도 끝났다면 기술 담당자들과 책임자들을 만날 수 있다. 하지만 아무리 기술에 대한 이해도를 가진 사람들이라고 해도 처음부터 핀옵스의 기술적 내용을 쏟아내서는 안 된다. 먼저는 관계를 형성해야 한다. ‘우리는 단순히 운영적 이상론을 규정으로 만들어 제시하는 귀찮은 사람들이 아니다’라는 걸 이해시켜야 한다. 아무래도 클라우드 비용 절감이라는, 민감할 수 있는 부분을 건드리는 외부인들에 대해 선뜻 마음을 열기 힘든 건 기술 분야 사람들도 마찬가지다.

3. 아무 것도 전제하지 말고 질문을 하라
서로에 대해 조심스럽게 접근하는 시간이 지나갔다면 본론으로 들어가야 한다. 어떤 식으로 클라우드를 운영해야 비용을 절감할 수 있는지, 얼마나 줄어들 수 있는지, 그들로서는 궁금하지 않을 수 없다. 그러므로 서비스 제공자들은 이 부분을 충족시킬 수 있는 방법론을 제안해야 한다. 중요한 건 여기에 아주 약간의 소금을 쳐야 한다는 것이다.

기술 보고서를 통해 방법을 제안하려면 각종 성능 및 기능 지표들을 기반으로 할 수밖에 없다. 그러나 그 지표들은 어떻게 나왔는가? 보통 데이터들은 1분에 한 번, 1시간에 한 번 등 특정 주기에 따라 추출이 된다. 그렇다는 건 중간에 측정되지 않고 놓치는 게 생긴다는 뜻이 된다. 실제 상황과 숫자로 나타나는 상황이 사뭇 달라질 수도 있다는 것이다. 그렇다면 핀옵스 제안 사항들이 큰 효과를 발휘하지 못할 가능성이 생긴다. 실제 클라우드 비용 절감은 이뤄지는데, 사용자 경험이 크게 하락한다든지 하는, 다른 부분에서의 비용이 있을 수 있다. 데이터만으로는 올바른 진단을 하기 힘들 수 있다는 것이다.

그렇기 때문에 핀옵스 서비스를 제공하려면 고객사에 굉장히 많은 질문을 해야 한다. 제안을 하기 전에, 데이터를 확보하고 있더라도, 물어야 할 것들이 많아야 한다. 제안사항을 만들어가는 과정 중에 ‘그랬을 거야’나 ‘이랬을 거야’라고 짐작하고 넘어가는 건 하나도 없어야 한다. 이런 과정 없이 다짜고짜 데이터만 들여다보고 이 부분의 인스턴스들을 줄이세요, 라고 말하는 건 CTO로서 기분 나쁘게 들릴 수밖에 없다. 진짜 핀옵스로서 성공적인 비용 절감을 이뤄내려면 반드시 모든 부분을 꿰차고 있어야 한다.

핀옵스 이후
예리한 독자들은 느꼈을지 모르지만, 위에 필자가 쓴 내용은 비단 핀옵스에만 적용되는 게 아니다. 낯설고 새로운 기술을 조직에 거부감 없이 도입하려면 거쳐야 하는 과정이다. 신기술을 가진 자들은 이런 식의 접근 방법을 훈련해야 자신들이 가진 신기술을 극대화시킬 수 있게 된다. 결국 아무리 맛있는 음식이더라도 플레이팅이 엉망이면 아무도 맛보지 않는다는 원리가, 신기술이 빠르게 나오고 있는 IT 분야에도 적용된다는 것이다. 기술들마다 이뤄내고자 하는 것과 역할이 다를 것이니 ‘플레이팅’ 방법도 그에 따라 고민해 보도록 하자.

글 : 리치 호여(Rich Hoyer), 디렉터, SADA
[국제부 문정후 기자(globoan@boannews.com)]

<저작권자: 보안뉴스(www.boannews.com) 무단전재-재배포금지>