brunch

You can make anything
by writing

C.S.Lewis

by 염전씨 Feb 27. 2023

SaaS SA가 하는 일 (1)

아니 너 그래서 하는 일이 뭔데?에 대한 더더더 구체적인 답변

이전 글에서 SaaS 회사에서 다른 SaaS 회사와 파트너가 된다는 것이 나 개인에게 어떤 태도의 변화를 요구했는지, 그리고 이것을 어떻게 프로젝트 속에서 배웠는지 다뤘다. 내가 한국에서 SaaS 회사들을 고객으로 만날 때는 그들이 자체적인 솔루션을 더 고도화 하느라 다른 SaaS 회사와의 통합, 확장 등은 잘 논의되지 않았었다. 상대적으로 SaaS 시장이 활성화된 미국에 오니까 다른 SaaS 제품들과 연결해서 총체적인 경험을 확장하는, 말 그대로 타사와의 통합이 아주 활발하게 이루어지는 것을 볼 수 있었다. 1년 간 내가 이 SaaS 간 통합을 목표로 한 프로젝트를 진행하면서 배운 프로젝트 접근 방법과 기술적 결정사항들을 정리했다.

1. Solutions Architect 의 덕목 - 아니 너 그래서 하는 일이 뭔데? 에 대한 긴 답변

2. 클라우드와 소프트웨어 SA의 차이점

3. SaaS SA가 하는 일 (1) - 아니 너 그래서 하는 일이 뭔데?에 대한 더더더 구체적인 답변

4. SaaS SA가 하는 일 (2) - 내가 내리는 기술적 결정들

프로젝트에 들어가기

SaaS to SaaS 통합이라는 개념 자체가 나에게는 상당히 새로웠다. 나와 같을 사람들을 위해 조금 더 설명을 해보겠다. 내가 수세미를 온라인으로 팔고 싶은 소상공인이라고 생각해보자. 내가 하고 싶은 건 수세미를 팔고 싶은 것뿐인데 해야 하는 일이 상당히 많다. 먼저 내가 배송을 보낼 수 있어야 하고, 세금 신고도 해야 하고 (미국의 경우 주 별로 세금 체계가 다르기 때문에 대단히 복잡한 일이다), 고객 관리도 해야 하고, 주문해줘서 고맙다거나 중간에 계산을 안 하고 끊어버리면 뭐가 잘못됐는지 확인해보라는 메일도 보내야 한다. 이걸 내가 다 해야지 수세미를 팔 수 있다면 아주 스트레스 받는 일이 될 것이다. 그래서 많은 SaaS 회사들이 이를 돕기 위한 소프트웨어를 개발하고 서비스를 제공한다. 데이터 관점에서 생각해보면, 내 고객이 발생시키는 주문을 기준으로 내가 방금 말한 이 모든 소프트웨어들이 동작을 시작하게 됨을 알 수 있다. 손님 A 가 내 웹 사이트에 방문해서 주문을 하고, 여기에 입력한 데이터 값들에 따라 세금을 계산하고, 배송을 시작하고, 이메일 커뮤니케이션을 하고 등등의 일이 발생한다는 의미이다. 이 말은 즉 내가 SaaS 회사 입장에서는 이런 다른 데이터 소스들을 외부에서 받아와야 한다는 뜻이다. 그래서 SaaS 한 회사로서는 큰 생태계에 편입되고 다른 회사들과 연결되어, 고객의 사업 사이클 안에 자리 잡을 수 있어야 한다.

SaaS to SaaS 통합을 할 때는 개입되는 사람들이 많다. 가장 먼저 두 회사의 협력 관계를 정의하기 위해서 Business Development Manager 가 일단 등장한다. 그들은 왜 우리 회사와 협력을 해야 하며 여기에서 발생하는 비용은 어떻게 충당할 것인지 발생하는 이익은 어떻게 나눌 것인지 등등을 함께 정의한다. 이 과정에 Product Manager 도 참여를 하게 된다. 양사가 가지고 있는 기능들을 분석하고 우리가 만들어낼 경험이 무엇인지, Mandatory 는 무엇이고 Good-to-have 는 무엇인지 결정한다. 초기 단계에서부터 Solutions Architect 가 들어가기도 한다. 상대방의 프로덕트와 기술적 인터페이스 등을 분석하고, 우리 쪽에서 개발되어야 하는 것이 있는지 혹은 상대방 쪽에서 없는 기능이 있는지 등을 파악하여 기술적 타협접을 만들어야 하기 때문이다. 양사가 서로 감당 가능한 비용으로 이 프로젝트를 런칭시켜서 합리적인 이득을 볼 수 있겠다고 결정하고 도장을 찍으면 프로젝트가 시작된다.

프로젝트 접근 방법

초반에 요구사항을 정의할 때에는 BD, PM 이 이야기를 주도하고 SA가 기술적인 가이드와 제안을 하는 정도이다. 그런데 이때 멍때리고 있으면 안된다. 자칫 잘못하면 어느 프로젝트나 그렇듯 현실 가능성 없는 요구사항에 빠져서 모두가 산으로 가게 될 수도 있기 때문이다. 그래서 촉각을 곤두세우고 지금 이 사람들이 말하는 걸 구현하려면, 내가 이걸 만들어야 하는 개발자라면 어떻게 무슨 API 를 어떻게 불러서 어떻게 개발해야 할지 깊이 있게 생각해봐야 한다. 그렇게 하기 위해 내가 사용하는 방법은 이런 것들이 있다.

순서도로 기능적 요구사항 완전히 검증하기

내가 가장 먼저 하는 것은 요구사항을 순서도로 만드는 것이다. 머리 속에서 대충 여기서 저기서 뭐 확인하고 그 다음에 어쩌고저쩌고 하면 되겠지 생각해도, 그것을 확실히 순서도로 만들게 되면 몇가지 이점이 있다. 첫번째는 양 쪽에서 필요한 액터, 시스템 구성요소를 아주 정확히 파악할 수 있다. 화살표의 끝이 어디로 가야 할지 결정해야 하기 때문이다. 두번째는 한 화살표를 그리고 나면 그 다음 화살표를 그려야 하기 때문에 거의 함수 단위로까지 생각을 구체화할 수 있다. 이 과정에서 현재 부족한 API, 기능이 뭔지 파악한다. 이렇게 대략적인 순서도 파악이 완료 됐다면, 기능 공백을 메꿔야 할지 그렇다면 서로가 얼마나 개발 공수를 투자할 수 있을지, 만약에 메꾸지 않고 가면 대안은 무엇인지 협의한다.

또 한가지 반드시 생각해야 하는 점은 어디까지는 programatic 하게 막아야 하는 side effect 인지 어디는 문서와 사용자 교육으로서 해결해야 하는 부분인지 명확히 갈래를 나눈다. 완전히 모든 것을 자동화할 수 있으면 정말 좋겠지만 대부분의 경우 그럴 수 없는 것이 대부분이기 때문이다. 어디가 우리가 타협할 수 없는 선이며 어디는 고객들의 손을 꼭 잡고 하나하나 알려주면 피해갈 수 있는 도랑인지 파악하는 과정이다.

없이 못 사는 PlantUML, 코드로 작성한 순서도 예시

놓치지 말아야 할 비기능적 요구사항

비기능적 요구사항의 많은 부분이 있지만 여기에서는 보안, 향후 확장 가능성, 성능, 고객 지원에 대해서만 이야기해보려고 한다. 조직에 따라서 우선순위는 다르겠지만 많은 대기업의 경우 대부분 이 두가지가 중요할 테니 말이다.

보안은 어디까지 갈 것인지 정하기가 아주 쉽지 않은 부분이다. 특히 유럽 고객 베이스가 있다면 특히 GDPR 기능이 반드시 포함되도록 서로 합의가 되어야 한다. 여기에 더해서 양사에서 원하는 인증 프로그램이 있는지, 만약에 그것이 없는 경우 어떤 테스트로 보안성을 테스트할 것인지를 정의해야 한다. 예를 들어 ISO27001 인증이 있는지, 없다면 우리가 주고 받는 데이터가 서로의 환경에서 안전하게 저장됨을 어떻게 확신할 수 있는지를 정하는 것이다. 이때 어느 수준을 서로 요구하는지가 명확히 소통이 되어야 막판에 프로젝트 런칭을 해야 할 때 “너 왜 이랬어” 해야 하는 어색한 상황을 피할 수 있다.

기능적 확장 가능성도 반드시 요구사항으로서 생각해야 한다. 기능적 요구사항들을 정리하면서 “지금은 일단 이렇게 하고 나중에 수정하거나 추가하자”라는 부분들이 많이 생겨날 것이다. 이 말은 당신이 디자인할 시스템이 반드시 기능적 확장을 하게 된다는 말이다. 최초 요구사항을 위해 쓰는 코드가 두번째 시기에 추가되는 기능에도 재활용 가능할 수 있는 부분이 있는지? 그렇지 않다면 추가로 투입되어야 하는 공수는 얼마나 되는지? 이런 것들에 대해 답할 수 있어야 한다.

성능은 사실 처음에 시작할 때 가장 어려운 점이다. 우리가 이 프로젝트를 통해 탄생시킬, 두 회사의 제품을 오가는 이 경험은 세상에 처음 등장하는 것이기 때문에 사람들이 얼마나 사용할지 얼마나 많은 데이터가 오고 갈 지 예측하는 것이 쉽지 않다. 성능 지표 설정을 위해 벤치마킹 가능한 지표가 없다는 의미이다. 그래도 아예 없이 시작하는 것보다는, “X초 이내에 모든 절차가 완료된다” 혹은 “최초 Y초 이내에 어떤 결과를 받아 본다”는 식으로 약간 널널하게 기능에 대한 Success criteria 를 최초에 정의하고 조정해나갈 수있는 장치를 두는 것을 권한다.

고객 지원은 프로젝트 안에서 기술적 요구사항이라고 볼 수는 없으나 비기능적으로 반드시 고려해야 하는 부분이다. 기술적인 문서화가 많이 수반되는 분야이기 때문이다. 특히 상대방 제품을 통해 유입되는 고객도 있고 반대로 우리 제품에서 상대방 쪽으로 가게 되는 고객도 있을 것이기 때문에 양방향에서 빈틈없이 고객 지원 체계를 준비해놓아야 한다. 여기에는 문서도 포함되고 컨택 포인트도 포함되고 고객센터에서 가지고 갈 가이드 문서도 포함된다.

브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari