몇 년 간 서드파티 보안 부분을 담당한 경험이 있고, 그 때 경험했던 부분들에 비추어 보면 해당 영역이 SAAS 와 비슷한 부분이 꽤 많다는 생각이 들어, 두 영역의 유사성을 비교해 보며 얘기를 시작해 보려 한다.

서드파티를 간단히 정의해 보면 우리 회사(1인칭 회사에 대한 여러 표현을 고민하다가 이렇게 지칭하기로 했다)는 아니지만 우리 회사의 업무를 대행하거나, 같이 일하거나, 반대로 비즈니스 기반을 의탁하는 회사들이 될 수 있다. 많은 회사들이 고객 센터, 택배 같은 분야를 전문 서드파티 회사에 위탁하여 운영 하는 경우도 많고, 이벤트, 광고 대행이나, 특정 분야의 판매 대행(예를 들면 e쿠폰, 여행) 카드사, 앱스토어 등의 회사들도 모두 본인 회사 입장에서는 서드파티라고 볼 수 있다. 이 외에도 건강검진, 급여, 교육 등의 회사 자체의 운영에 대한 서드파티 들도 있을 수 있다.

결과적으로 회사와 연결되어 있는 모든 제3의 회사들이 해당되기 때문에 무척 광범위한 범위를 가졌다고 볼 수 있고, 스타일 및 규모가 서로 다른 다양한 회사들이 해당되기 때문에 일률적인 기준을 적용하기도 무척 애매한(그럼에도 표준적인 형태의 관리를 원하는) 영역이라고 본다. 그럼 어떤 부분들이 SAAS와의 유사점을 가지게 될까?

2.1 데이터의 전달

우선 두 개의 유사성이 생기게 되는 가장 근본적인 원인은 우리 회사의 특별한 목적에 의해 서드파티 회사와 연결되고, 그에 따라 필수적으로 데이터의 전달이 일어난다는 측면일 것 같다. 서드파티 회사와 같이 일하는 이유 자체가 회사의 비즈니스를 확장하거나, 대행, 연계하자는 목적이 강하므로 결국 같이 일을 하기 위해서는 회사내의 필요한 데이터를 일정 수준 전달해 주는 것이 필요하다. 서드파티와 우리 회사는 공장내의 재료(데이터)를 주고받는 체인들처럼 서로 얽혀 있는 관계라고 볼 수 있기 때문에 결국 특정한 서비스를 수행하고자 한다면 내부 데이터의 전달이 반드시 필요하다고 본다.

SAAS 또한 어찌 보면 과거에 온프레미스에 있어야 했던 솔루션이 클라우드 위에 올라가 있는 것으로 볼 수 있기 때문에, 원하는 목적을 수행하기 위해서 회사내의 데이터가 전달되는 과정이 반드시 필요하게 된다. 그 데이터는 회사 사이트를 방문했던 사용자의 IP 일수도, 내부직원 및 고객 데이터의 일부 일 수도 있다. 회사는 해당 SAAS 시스템을 사용하는 목적 및 여러 컴플라이언스 및 사내 기준을 검토하여 전달할 수 있는 데이터가 무엇인지를 결정되게 될 것이다.

서드파티에 비춰보면 데이터가 전달된 이후의 해당 데이터의 사용과 보호는 많은 부분 상대편의 시스템과 프로세스의 수준에 영향을 받게 된다는 부분도 비슷하고, 그럼에도 불구하고 해당 전달된 데이터가 올바르게 쓰이는 지에 대해서 감사하고 연대 책임을 져야 하는 다는 것도 비슷하다. 

[그림 2-1 데이터의 전달] 

2.2 역학 관계

이상적으로 우리 회사와 서드파티 회사와의 관계는 서로 평등 해야 하지만(어느 회사나 공식적인 문서에는 아마 이렇게 적혀 있을 것이다), 현실적으로는 서드파티 회사들의 규모 및 비즈니스 상황에 따라서 서로 역학 관계가 생기게 되는 경우가 많다고 본다. 우리 회사와 서드파티 사이에는 언제나 미묘한 사업적인 역학 관계가 존재하며, 특정 담당자 들 중에서는 그러한 역학 관계를 전략적으로 잘 이용하는 사람들이 분명 있기 때문에 이상적인 평등함이 이루어지긴 힘들다. 예를 들어 대부분의 회사 입장에서는 카드나 모바일 스토어 등 플랫폼 기반의 서드파티 회사의 경우 가맹점 가입, 적절한 수수료, 앱 등록 허가 등의 관점 등에서 눈치를 봐야하는 입장이라고 본다. 카카오와 구글의 인앱결제 관련 힘겨루기 부분에서 해당 부분을 간접적으로 목격하지 않았나도 싶다.

반대로 매출 자체가 우리 회사에 크게 의존적이거나 대체가 쉬운 회사와 서드파티 관계에 있다고 할 경우는, 아무래도 여러 합법적이면서도 상대 서드파티의 자발적인 양보 측면에서 유리하게 리딩을 할 수 있을 것이다(물론 회사에 따라 법망을 애매하게 피해가는 울며 겨자 먹기인 경우도 종종 있겠지만 말이다). 그래서 많은 회사가 대체하기 힘든 플랫폼이나 점유율이 높은 회사의 포지션을 획득하기 위해 노력을 하는 것일 테고 말이다.

SAAS 또한 결국 솔루션이라는 측면에서 마찬가지로 비슷한 측면이 있다고 생각한다. 물론 돈을 지불하는 회사가 고객이기 때문에 당연히 선택권을 쥐지 않냐고 생각할 수도 있지만, 생각보다 선택 시에는 안정성이나 레퍼런스 등의 측면에서 적절한 솔루션 도입을 해야 하기 때문에, 솔루션 영역에 따라서는 선택지가 그렇게 많지 않을 수도 있다. 대부분의 솔루션 영역 들은 높은 점유율을 가진 몇몇 큰 회사들과 작은 점유율을 가진 마이너 회사들로 이루어져 있고, 어떤 경우는 실질적 독점 형태로 이루어진 경우도 있는 듯해서, 실제 운영 시의 안정을 보증할 레퍼런스 측면에서 상호 영향을 주는 경우가 많은 듯 싶다.

OS 및 네트워크, 방화벽 등 사실상 몇몇 회사들에 의해 이미 거의 굳히기가 되어 있는 분야에 대해서는 더 더욱 선택의 폭이 좁아 보이고, 보통 해당 솔루션 관리에 대한 학습 곡선과 적절한 장애 대응의 중요성에 의해 운영 인력과 솔루션이 기술적 커플링이 되는 경우가 많다. 그래서 일단 도입되어 안정이 된 후로는 비용, 보안, 안정성 면에서 적절한 명분이 생기기 전에는 다시 손을 대기가 무척 힘들다고 본다. 해당 솔루션 회사가 여러모로 맘에 안 든다고 하더라도 다른 대체제로의 마이그레이션이라는 것도 결국 돈과 사람이 소요되기 때문이다.

마지막으로 재밌는 측면 중 하나는 앞의 서드파티 들과의 관계와 동일하게 SAAS 회사도 공식적으로 표현은 안 하지만 서비스 제공자의 관점에서 우리 회사를 본인들의 방향에 맞게 길들이기를 원한다는 것이다. 가장 이상적인 역학 관계는 시소 게임 같이 적절히 서로 앞뒤로 무게 중심을 옮기면서 자신 및 상대의 이익을 최대화하는 점을 찾는 것 이겠지만, 세상일이 그렇듯 회사의 관계이자 동시에 사람의 관계가 되기 때문에 “죄수의 딜레마(협력할 경우 서로에게 가장 이익이 되는 상황일 때 개인적인 불안으로 서로에게 불리한 상황을 선택하는 문제)” 처럼 쉬운 상황은 아닌 듯싶다. 반대의 측면에서는 사람들 사이의 “이기적 유전자” 같은 관계가 회사 사이에서도 담당자와 연관 부서를 매개체로 일어나게 되는 듯도 싶고 말이다.

[그림 2-2 – 균형 맞추기] 

2.3 서로 다른 기준

앞서 이야기한 우리 회사와 서드파티 회사의 역학 관계에서 파생되는 부분 중 하나는 서드파티 회사에 대해서 서로 다른(좋게 포장하면 유연성 있는) 기준을 취할 수밖에 없다는 부분이다. 회사의 매출의 대부분을 의지하고 있는 서드파티 회사와 그 반대의 관계를 가진 서드파티 회사에 대해 여러 측면에서 동일한 포지션을 취하기는 어려울 것이다. 유리한 관계에서는 어떻게 든 회사의 이익을 극대화하는 방향으로 포지셔닝을 하도록 적당한 선에서 유도할 수 있겠지만, 아쉬운 관계에서는 겨우 잡은 안정된 기회를 놓치지 않도록 눈치를 보고 열심히 노력해야 할 것이다.

물론 표준적인 관리를 위해 각 그룹에 따라 적절한 (보안) 기준을 세우고 관리를 해야 한다는 부분에서 이런 고무줄 스타일의 포지셔닝은 비 합리적으로 보일 수도 있을 것 같다. 다른 현실적인 측면에서 변명해 보자면 보통 우리 회사가 상대적으로 아쉬울 수 있는 서드파티 회사(예를 들면 애플, 구글, 아마존) 들은 대부분의 경우 해당 회사의 규모가 더 크고, 보안 기준도 더 엄격하며, 인력이나 프로세스 등이 더 체계적인 경우가 많기 때문에, 해당 부분을 고려해 접근 방식을 조정하는 것은 현실적이고 나쁘지 않은 방법이 아닐까 싶다. 뭐 보안에서 항상 얘기하 듯 리소스나 비용은 한정되어 있기 때문에 그 노력을 좀 더 불안한 서드파티에 쏟는 리스크 기반으로 접근한다고 포장을 해보면 어떨 까도 싶다. 또한 현실적으로 작은 회사들이 그런 큰 플랫폼 회사들에 체계적인 서드파티 관리를 하려해도 서류 수준의 대응 이외에는 추가적인 협조를 안 해주는 경우도 종종 생길 수 있다고 본다.

온프라미스를 포함한 SAAS 솔루션 또한 위와 비슷한 포지셔닝을 가지게 된다고 본다. 업체를 선도하고 많은 회사에서 도입해 사용하며, 가격까지 괜찮은 솔루션이 있다면(다만 이 부분은 유니콘 같이 현실에서 보통 공존하긴 힘들어 보인다), 아마 우리 회사의 프로세스와 데이터에 일부 변화를 가져오는 불편이 있더라도 해당 솔루션을 적극적으로 사용하려 할 것이다. 반대로 온프라미스, 클라우드를 거쳐 대체제가 많아 별로 아쉬울 것 없는 솔루션이라면 회사의 여러 사정에 맞추어 적절히 취사선택하고, 해당 상황을 이용해 경쟁을 통해 유리하게 협상을 하려고 할 것이다. 뭐 어떻게 생각할 진 모르지만 생존을 위해 고양이를 대하는 태도와 호랑이를 대하는 태도는 다를 수밖에 없다.

 
[그림 2-3 - 고양이와 호랑이] 

2.4 선택의 다양성과 제한성, 레퍼런스

앞의 얘기들과 중복되긴 하지만, 세상에 다양한 서드파티 회사가 있지만 사실 대부분의 경우 몇몇 리딩하는 회사들이 대부분의 점유율을 확보하고 있는 경우가 많을 것이다. 서드파티 회사는 우리 회사의 기능을 확장하거나 위임하는 경우가 많기에 효율성에 앞서 안정성과 신뢰 또한 절대적으로 중요하기 때문에, 어떤 주요한 회사들과 일을 하나 체크할 수밖에는 없다. 그래서 이론적으로는 많은 선택지가 있겠지만, 아무리 가격 효율이 우수한 서드파티 회사가 괜찮은 서비스를 제공하는 듯하더라도, 그 신뢰성과 레퍼런스가 객관적으로 적절히 보장 되지 못한다면 회사의 파트너로서 선뜻 일을 하지는 못할 것이다.

비슷하게 SAAS 솔루션도 아무리 기능과 가격이 매력적인 서비스가 있더라도, 해당 부분이 회사의 중요한 기능과 연관되어 있다면 도입하기가 망설여 질 것이다. 사실 레퍼런스(특히 비슷한 분야의)가 많다는 것은 단순히 안정성 뿐만 아니라 우리 회사에서 고민하는 많은 문제들이 이미 타 사들의 요구에 의해서 해결되어 서비스로 제공되고 있을 가능성이 높다고 본다(물론 솔루션사가 보수적이면 아닐 수도 있다). 반대로 우리 회사 환경에서 솔루션 사용 중 불안정하거나 이해못할 문제가 발생할 가능성은 확률적으로 낮을 것이고 말이다(물론 이 확률은 회사 환경의 특이성에 따라 다르 긴 할 것이다).

물론 어떤 회사나 처음 시작이 있기 때문에 해당 회사에 대한 선견지명 및 믿음과 행운을 바탕으로 전략적인 파트너 관계에 배팅을 하는 경우도 있겠지만 자주 일어나는 일은 아닐 듯 하다. 그래서 사실 신규 회사 들의 경우 여러가지 간접적인 레퍼런스(예를 들면 어느 회사 출신이 차렸다든지, 어느 회사가 모 회사라든지, 유명한 회사 엔지니어 출신들이 많다든지 등등)을 이용해서 회사의 우수성과 안정성을 어필하는 전략도 자주 쓴다고 본다. 쿠키에 비유하자면 “우리 쿠키는 프랑스의 유명한 디저트 샵에서 오랫동안 근무했던 핫 한 파티셰 출신이 만든…” 같은 느낌일 것이다.

  [그림 2-4 - 쿠키 고르기] 

2.5 Lock-in 효과

우리 회사의 서비스가 서드파티와 연결되는 순간 적절한 서비스를 받는 동시에, 우리의 많은 프로세스와 노하우가 해당 서드파티 회사 쪽에 전달되는 측면도 생긴다고 본다. 예를 들어 서드파티 고객센터라면 단순히 고객 대응 시스템(형태에 따라 위탁하는 회사 시스템을 쓸 수도 있다)과 상담 인력, 공간 만을 의지하게 되는 게 아니라, 인력의 지식이나 체계 등이 서비스를 위탁한 회사의 니즈에 맞춰서 트레이닝 되고 최적화되면서 그에 맞춘 노하우들이 쌓이게 된다. 그래서 해당 서드파티 회사와 계약이 계속 연장될수록 보통 운영의 효율성이 늘고, 해당 상황을 관리하기 위한 내부 직원의 리소스 절감을 가져올 수 있지만, 반대로 무언가 좀 안 맞는 부분이 있더라도 선뜻 전혀 내부 사정과 노하우를 모르는 다른 서드파티 업체를 찾아보기는 어려운 상황이 생긴다(그리고 사실 이건 서드파티 회사 쪽도 어느정도 비슷한 측면이 생기는 것 같긴 하다).

SAAS 같은 경우도 대부분의 솔루션이 결국은 회사 내의 데이터를 가져와 목적에 맞게 처리해 주는 역할을 하기 때문에, 도입을 하면서 해당 회사의 실정에 맞는 많은 커스터마이즈 및 표준 환경과의 상이함에 따른 대안적 프로세스(workaround)를 구성할 수 있다. 예를 들면 SIEM이나 머신러닝 기반의 솔루션이라면 보통 몇 개월의 시간을 두고 해당 회사의 데이터를 기반으로 솔루션의 주요한 모델과 룰을 조정하게 될 것이다. 그래서 서드파티와 마찬가지로 해당 솔루션을 계속 사용하면서 노하우와 효율성이 차곡차곡 쌓일 수가 있지만, 바로 그 노하우와 효율성 때문에 일정 시간이 흐른 후에는 타 솔루션으로의 전환이 어렵게 될 수 있다.

최악의 경우 분쟁이 발생하고 감정이 격해진 경우, 타 솔루션으로 해당 데이터의 원활한 이관에 대해서 협조를 안해주는 경우도 생길 수도 있다(다만 어느 쪽이든 이런 경우는 사업을 하기 싫은 게 아닌가 싶을 정도의 나쁜 평판을 일으킬 수 있는 무리한 행동이라는 생각은 든다). 해당 부분에 대해 협의 및 초기 계약적인 부분(처음 도입 시는 보통 솔루션 업체가 왠만한 조항은 다 수용하기 때문에)으로 대책을 마련해 두어야 하는 측면도 있는 것 같다.

해당 부분은 특정 커피 머신을 구입하는 순간 그 모델에 맞는 호환 캡슐을 사야하는 제약이 생기는 것 과도 비슷하다고 본다. 물론 모든 것이 가능하다고 광고하는 SAAS 솔루션도 있긴 할 테지만, 대부분 그 경우는 이도 저도 아닌 애매한 경우 이거나, 해당 솔루션을 소개하는 사람이 해당 솔루션이 속한 분야 자체를 잘 모르는 어설픈 경우일 가능성이 더 높다고 본다. 대부분의 솔루션들은 보통 각 솔루션 회사의 고유 철학을 기반으로 설계되기 때문에, 타 솔루션에 대해 단점과 장점이 반드시 공존하게 된다. 실제 솔루션 개발이나 업그레이드 시에도 제한된 인력과 시간이라는 제약에 의해 그 차이가 점점 커지게 될 것이고 말이다.

[그림 2-5 – 호환 머신] 

2.6 장애 시 기다림

이번에는 회사와 같이 일하는 서드파티 회사에서 장애가 났다고 해보자. 서드파티 회사 담당자를 볶으면서 빨리 비즈니스를 정상화 해달라고 요청하거나, 계약 관계에 따라 차후 손해배상을 청구할 수도 있겠지만, 일어난 상황에 대해서는 해당 서드파티 회사에서 빨리 장애 원인을 찾아 해결해 주기를 기도하고 있을 수밖에 없다. 우리 회사 내부에 뛰어난 개발자나 시스템 전문가가 있더라도 그 사람들이 해당 시스템 구조 자체도 잘 모르는 서드파티 회사의 장애에 도움을 줄 수 있을 가능성은 아주 낮다. 그런 오지랖 넓은 행동을 하려하는 사람도 드물테고 말이다.

SAAS 장애시에도 비슷한 상황이 생기게 된다. 아무리 촘촘한 계약적 안전장치를 만들더라도 SAAS 솔루션 자체의 장애나, SAAS 가 몸담고 있는 클라우드 시스템에 장애가 생기면 마찬가지로 계속 확인은 하겠지만 두 손을 꼭 모으고 해당 회사 엔지니어 들의 빠른 대응을 기다릴 수밖에는 없다. 이 적극적인 대응에 대한 주도권을 뺏기는 불안감이 아마도 많은 회사들이 SAAS를 선뜻 도입하기 두려워하는 주요 이유 중 하나일 테지만, 이것은 앞 글에서 얘기했듯이 집에서 사용하는 인터넷, TV 서비스가 장애가 나는 상황과 비슷하다(뭐 집에서 일어나는 일이니 회사처럼 직접적인 피해는 없다고 생각할 수도 있지만 재택에서 화상회의를 하다가 갑자기 인터넷과 모바일 통신이 모두 안된다고 가정해 보자).

그래서 아무래도 이렇게 장애가 민감한 영역에 대해서는 규모가 크고, 사업 수행 경력이 오래되고, 점유율이 높고, 시스템 및 프로세스, 인력이 체계적인 회사들이 선택에 대한 경쟁에 원초적으로 유리하다고 본다. 편견 일수도 있겠지만 지역 케이블의 인터넷 서비스와 LG, SK, KT 브랜드의 대형 인터넷 서비스에 대한 고객 대응과 신뢰도 느낌 차이 정도가 아닐 까 싶지 싶다(물론 보통 안정된 메이저 서비스 쪽이 비용이 더 비싸긴 하다). 다만 한 가지 아이러니 한 것은 뭐 그걸 잘 방어하느냐는 별개의 문제겠지만 보통 외부 공격의 대상은 잘 알려진 큰 회사가 더 타겟팅 될 수는 있다는 점이다. SAAS를 쓴다는 것은 주인을 기다리는 고양이와 같이 어느 정도는 막연한 기다림과 불안함의 측면이 있을 수밖에 없다는 생각도 든다.

[그림 2-6 – 주인을 기다리기] 

2.7 비용 및 수수료 협상

서드파티와 같이 일을 하는 이유 중 하나는 우리 회사의 사업을 확장하고 업무를 효율적으로 하기 위해서 일 것이다. 그래서 회사 입장에서는 우리가 물건을 살 때 가성비를 열심히 따지는 것 같이 유리한 비용 및 수수료를 지불할 수 있는 서드파티 회사를 찾으려 할 것이다. 하지만 생각보다 비용 및 수수료 라는 부분은 우리의 바램 같이 고무줄 같이 유연하게 정해질 수 있는 부분은 아니다.

서비스를 제공하는 회사나 사용하는 회사나 이익을 최대화하려는 각자의 입장에 있기 때문에 보통 그 중간점에서 협상해 멈추기 마련이지만, 상황에 따라 상대에 대한 여러가지 미래가치나 레퍼런스 효과, 또는 그 비슷한 추상적/실제적 가치 때문에 여러가지 변수들이 생길 수 있다고 본다. 하나 크게 예외가 없는 부분은 일단 관계가 시작이 되게 되면, 이후부터는 해당 시작 조건을 출발지로 줄다리기가 시작되기 때문에 유리한 초기 시작점과 우호적인 관계를 포지셔닝 하는 것도 꽤 중요한 부분이라고 생각한다. 때론 앞에서 얘기했듯이 서드파티 회사 쪽에서 먹이를 주듯 쉽게 도입하도록 유도해 lock-in 시킨 후 유리하게 조건을 바꾸는 경우도 가끔 있지만, 해당 경우는 상호 이익에 대한 신뢰가 깨지게 되어 장기적으로 좋은 전략은 절대 아니라고 본다.

마찬가지로 SAAS 같은 경우도 서비스를 사용하는 쪽은 가능한 회사의 니즈를 최대한 충족해 주는 솔루션을 합리적이고 가성비가 좋은 가격에 구매하고자 하는 바램이 있고, SAAS 회사 쪽 또한 세일즈 목표를 이룰 수 있는 합리적인 가격을 제공하고 장기적인 고객 관계를 만들고 싶은 바램이 있을 것이다. 해당 목표를 위해서 예산 등 여러가지 상황을 기반으로 협상에 나서며, 서로 그 이해가 일치되게 될 때 해당 솔루션을 채택하게 된다고 본다. 다만 많은 경우 그 합리적인 가격이라는 부분에서 서로 입장 차이가 크기 때문에 문제가 생기기는 해 보인다.

그래서 사실 이 부분이 꽤 애매한 것 같기는 싶다. 서비스를 사용하는 입장에서는 최대한 비용이 적음 좋다고 생각할 수 있지만, 반대로 서비스를 제공하는 입장에서 특정한 직, 간접적인 이익이 없다고 생각하면 문자 그대로 해당 고객사에 대한 손절이 일어날 수도 있기 때문이고, 사실 그 손절은 사용자와 제공자 어느 쪽에서든 발생할 수 있다고 본다. 그래서 회사와 회사와의 관계이긴 하지만 현실에서는 양 쪽 회사의 엔지니어, 관리자, 구매 부서 담당자 들 간의 투명하고 믿음 있는 관계가 중요한 것 같긴 하다. 어찌 보면 너무 이상적으로 들릴지는 모르지만 항상 상대에 대해 어떤 유형적, 무형적 부가가치를 더 줄 수 있을지를 고민해야 좋은 관계가 지속될 수 있는 것은 같다(말 한마디에 천냥 빚을 갚는다고 한다).

뭐 결국은 이상적으로 회사는 시스템이지만 실제로는 회사의 효율성도 사람에 의해 일어나고, 비 효율성도 사람에 의해 일어나는 경우가 많지 않은가 싶기도 하다. 그래서 회사들이 좋은 인재를 뽑으려고 그렇게 노력하는 것일 테니까 말이다.

[그림 2-7 - 협상]