brunch

You can make anything
by writing

C.S.Lewis

by 정주홍 Oct 10. 2019

B2B 스타트업 개발자와 도메인 지식

지금의 팀에 합류한 뒤 일하기 시작한 지도 벌써 꽤 많은 시간이 지났다. 처음엔 게임 개발로 코딩을 시작했지만, 웹 개발, 모바일 개발, 언젠가는 모바일 SDK 개발을 했었다가 지금은 백엔드 개발, 그리고 데이터 엔지니어, 어떨 때는 데이터를 분석하는 일을 하고 있다. 이렇게 다양한 일을 하면서 스스로의 정체성과 또 어떻게 하면 더 잘할 수 있을까에 대해 고민하게 되는 것은 당연한 일일 것이다. 그중에서도 오늘은 스타트업 개발자에게 도메인 지식이란 어떤 것일까에 대해 생각을 정리해보고자 한다.

앞서 언급한 바와 같이 나는 게임 개발자로 코딩을 시작했다. 어렸을 때, 게임을 하면서 즐거워했던 제 모습이 지금도 선하다. 프로그램이 대체 어떻게 돌아가는 것인가에 대한 의구심을 처음 갖기 시작했던 것은 메이플 스토리라는 한 RPG 게임에서 화살표 키를 눌렀을 때 내 캐릭터가 움직이는 것을 다시금 보게 됐었을 때였던 것으로 기억한다. "내가 오른쪽 방향키를 누른 것을 어떻게 알고 게임에서 캐릭터가 오른쪽으로 움직이는 걸까?" 이에 대한 의문은 이후 게임 개발을 직접 해보기 시작하면서 OS의 키보드 이벤트를 처리하는 로직을 직접 구현하며 알게 됐다.

게임 개발을 하는 사람 중에서는 게임을 사랑하는 사람이 정말 많다. 오죽하면 업무 시간 중에는 열심히 게임을 만들다가 퇴근 후 집에 돌아와서는 LoL, 오버워치, 피파와 같은 다른 게임을 즐긴다. 이런 사람들에게는 게임에서 어떤 기능이 필요하다는 것이 자연스럽게 머릿속에 각인되어 있다. LoL을 즐기는 유저라면 미드 라인에 오는 챔피언이 어떤 의미를 가지는지 알고 있고, 탱커라는 포지션이 어떤 역할을 해야 하는지 알고 있다. 바론을 잡았을 때 얻고자 하는 것이 무엇인지 안다. 게임마다 다르긴 하지만 대부분의 게임에는 공통되는 지식이 있기 때문에 개발자가 즐기는 게임이 일로써 개발하고 있는 게임이 아닐지라도 어느 정도 사용자가 원하는 것을 알 수 있다.

게임은 말하자면 대표적인 B2C 비즈니스이다. End User를 대상으로 게임이라는 서비스를 제공한다. 지금 우리 팀에서 개발하고 있는 airbridge라는 제품의 비즈니스 모델은 B2B이다. 회사에서 원하는 것을 파는 회사인 셈이다. B2B는 B2C와 일부 비슷하지만 매우 다른 양상을 보인다. B2B에서는 특수한 목적의 서비스를 제공하는 경우가 많다. 예를 들어, airbridge는 퍼포먼스 마케팅을 집행하는 마케터들이 캠페인 집행을 더욱 효과적으로 할 수 있도록 하기 위한 서비스이다. 사용자들 또한 일반적인 사람보다는 퍼포먼스 마케팅을 어느 정도 집행해보고, 또 어떻게 하면 더 잘할 수 있을까에 대한 고민이 있는 사람들일 것이다. (혹은 상급자의 요구에 의한 것이거나.)

그런 사람들이 원하는 것이 무엇인지 어떻게 알 수 있을까? 개발자로서 Github과 같은 서비스에서는 어떤 기능을 제공해주면 사용자들이 좋아할지에 대해서는 쉽게 떠올릴 수 있다. 왜냐하면 Github은 본인이 항상 사용하는 서비스니까. 반면, 개발자 중에서 마케팅 캠페인을 직접 집행해본 사람들은 거의 없을 것이다. 따라서, airbridge를 이용하는 사용자들이 어떤 점에서 아픔을 느끼는지에 대해 가늠하기 쉽지 않다.

airbridge의 중요한 기능 중 하나로 Postback 기능이 있다. 매체의 어떤 광고를 통해 전환이 발생하면 전환에 대한 정보를 해당 매체에게 보내주는 기능이다. 매체에서는 Postback을 이용하여 성과가 잘 발생하는 audience를 대상으로 광고를 더 많이 노출해 전환을 더 많이 발생시키기 위한 최적화를 할 수 있다. 또한, 광고주와 매체 간의 정산을 위한 중요한 지표로 사용되기도 한다. 하지만 실제 구현 자체는 개발자에게 단순하게 여겨지는 HTTP 요청으로 구현된다. Postback이 어떤 의미를 지니는지에 대해 깊게 알고 있는 개발자가 아니라면 HTTP 요청이 적당히 보내지면 되는 정도로만 이해하고 개발할 것이다. 중요한 것은 이러한 시스템들이 분산 처리 시스템으로 구현되고, 또한 수많은 트래픽 안에서는 어떤 데이터가 얼마나 존재하는지에 대해 누구도 잘 알지 못한다는 점이다. 분산 처리 시스템에서 중요한 문제 중 하나는 Messaging System Semantics인데, Postback은 정산에 이용되는 데이터이기 때문에 At Most Once, At Least Once, Exactly Once 중 Exactly Once가 반드시 지켜져야 한다. 만약 마케팅이라는 도메인에서 Postback이 어떤 의미를 가지는지에 대한 지식이 없는 개발자라면 단순히 서버 비용을 줄이기 위해 At Least Once Semantic을 지키도록 개발할지도 모른다. 그 결과로는 정산을 위한 데이터가 맞지 않게 되는 고통이 찾아온다.

또 다른 예시도 있다. 개발자라면 누구나 최신 데이터를 볼 수 있는 것을 즐겁게 여길 것이다. 모바일 환경에서는 과거의 이벤트 데이터가 네트워크 문제 등으로 인해 굉장히 나중에 보내지기도 한다. 당연히 새로 들어오는 데이터가 있으면 그 데이터가 통계에 반영되어야 하지 않겠는가? 나 역시도 그렇게 생각했었고, 최대한 서버에 들어온 데이터를 통계에 반영될 수 있도록 하기 위해 노력했었다. 하지만 현실은 그렇지 않았다. 실제로는 데이터가 계속 바뀐다는 것 때문에 사용자들은 불편함을 토로했다. 데이터 분석을 위해 이래저래 데이터를 뒤져보는데, 시간이 지남에 따라 자꾸 데이터가 바뀌니 분석에 불편함이 있었던 것이다. 이런 불편함은 직접 경험해보지 않으면 예상하기 어렵다.

하물며 데이터 분석에 있어서는 어떨까? 내부적으로 데이터 분석을 하면서 이런저런 데이터를 뽑아본다. 복잡한 Query를 작성한 뒤 실행해보니 어떤 서비스의 Organic 설치가 10%라고 나타난다. 마케팅에 대한 배경 지식이 별로 없는 개발자였더라면 이 수치를 보고 의아함을 느끼지 못하고 그냥 넘어갔을 것이다. 하지만 어느 정도 지식을 가진 마케터라면 해당 서비스의 버티컬에서 10%의 Organic 설치는 이상하다는 것을 바로 알아차릴 수 있다. 물론 테스트 데이터가 잘 준비된 환경이었더라면 개발자도 작성한 Query가 잘못됐다는 것을 테스트 데이터를 통해 검증할 수 있다. 하지만 현실에서는 그런 테스트 데이터를 잘 만들어두기 어렵고, 대부분의 데이터가 깨끗하지 못하기 때문에 어느 정도의 잘못된 것을 감수하고 분석을 진행해야 한다. 그런 상황에서 정답, 혹은 해라 불리는 것을 정하기란 쉽지 않다. 어느 정도 "직감"이 필요한 예인 셈이다.

나는 스타트업에서 개발자는 코딩만 하면 되는 존재라고 생각하지 않는다. 오히려 스타트업이기 때문에 더더욱 비즈니스 개발에 많이 참여해야 한다고 생각한다. 혹자는 자신의 업무도 아닌 것에 신경을 써야 하는 것이 불합리하다고 말하기도 한다. 그런 분들에게는 스타트업이 적절한 일터가 아닐 가능성이 높다고 생각한다. 스타트업이란 한 명이 하나의 역할만 수행하는 것이 아닌, 수많은 역할을 수행하면서 일당백을 하는 곳이라 믿기 때문이다. 이렇게 열심히 비즈니스에 개입하며 개발한 결과로 내가 만드는 제품이 더욱더 가치 있는 제품으로 돌아온다면 그것이 내가 스타트업에서 달리는 이유 아닐까?

비즈니스 개발과 기획에 있어 의미 있는 도움을 많이 주기 위해서는 앞서 강조한 것과 같이 도메인 지식을 충분히 갖고 있어야 한다. 하지만 도메인 지식을 갖추기가 쉽지 않은 것이 현실이다. 특히나, 앞서 설명한 airbridge의 비즈니스에서는 더욱더 어렵다. 마케팅 캠페인을 직접 집행해보면 배울 수 있는 점이 분명 많겠지만 다른 해야 할 일이 많은 상황에서, 또한 제한된 예산 안에서 그런 노력을 기울이기는 현실적으로 쉽지 않다.

내가 생각한 현실적으로 할 수 있는 노력은 아이러니하게도 아는 게 적을지언정 더욱 열심히 기획 단계에 참여하는 것이다. 내가 아는 게 없어도, 또는 아는 게 적어도 기획을 주도하는 사람과 계속 부딪히면서 간접적으로 도메인 지식을 얻어나갈 수 있다. 또한, 더욱 논리적이기 위해 노력해야 한다. 주어진 기획을 그냥 곧이곧대로 구현해선 안 된다. 왜 이런 기능을 제공해야겠다고 생각하게 됐는지에 대해 더 의심하고 더 챌린지를 걸어야 한다. 어떤 빈틈이 있을 지에 대해 끊임없이 생각하며 도메인 지식을 학습하게 되니까. 또한, 직접 사용자를 인터뷰할 기회가 있다면 최대한 활용해야 한다. 지금 만들어진 것에 대해 어떻게 생각하는지, 불편한 점은 없었는지와 같은 질문을 하며 알게 되는 것들이 분명 있다.

처음엔 어렵다. 하지만 그동안 우리 팀원들을 봐왔을 때, 처음엔 어렵지만 기획 단계에 더 개입하기 위해 노력한 결과는 좋은 결과로 돌아왔다. 한 번 그렇게 개입된 후에는 더 쉬워진다. 이미 배경 지식이 꽤나 보충된 뒤니까 더 학습해야 할 것이 줄어든다. 그렇게 서로 투닥거리면서 논리가 더욱 정연해지고, 그 결과 좋은 제품으로 돌아온다. 단순히 제품 자체가 좋은 것뿐만 아니라 코드를 짤 때도 나중에 어떤 요구 사항의 변경이 있을지에 대해 더 예상하기 쉬워지기 때문에 유연한 구조로 코드를 작성하기에도 좋다.

그리고 다시 한번 강조해본다. 시키는 일을 하는 개발자보다는 하고 싶은 일을 하는 개발자가 더 즐겁지 않을까? 내가 더 좋은 제품을 만들기 위해 해야 할 일을 찾아다니고, 그 결과 내가 만든 제품을 사람들이 더 좋아하게 되는 것이 어떻게 즐겁지 않을 수가 있을까?

keyword