만약 IT 스타트업을 하나의 밴드 공연으로 비유한다면, 저희 개발자의 포지션은 무엇일까요?
IT 회사니까 개발자가 당연히 주인공인 보컬의 역할일까요?,
아니면 보컬 다음으로 인기가 많은 기타?
여러분은 어떤 포지션이 어울린다고 생각하시나요?
저는 개발자의 포지션은 프론트맨보다는 뒤에서 지원을 해주는 베이스기타와 가장 비슷하다고 생각한답니다.
과연 왜 그럴까요?
💡 프론트맨이란? :
1. 락 밴드의 리드 싱어 혹은 기타리스트.
2. 조직을 대표하고 그 조직의 이미지를 대중에게 더욱 매력적으로 만들기 위해 노력하는 사람.
신규 서비스를 런칭하거나, 소규모 서비스의 운영에서 개발자의 역량이 단기 성과에 큰 연관성이 없기 때문입니다!
왜냐면, 데이터가 충분히 쌓이지 않은 환경에서 신규 서비스를 런칭하거나,
새로운 기능을 선보일때 시장이 어떻게 받아드릴지는 정말 미지수이기 때문이에요.
(그리고 아마 높은 확률로 아무런 반응을 보이지 않겠죠ㅠ)
아무리 개발자가 아름다운 패턴과, 극한의 퍼포먼스를 구현해도, 결국 사용자가 없으면 그 코드는 충분한 가치, 즉 매출을 만들어 내지 못합니다.
이러한 상황에서 초기 고객을 유인해 서비스에 랜딩을 유도할 수 있는 방법은 매력적인 캐치 프라이즈를 사용한 마케팅, 재치 있는 기획들이죠.
초기 사업성을 '검증' 하는 개발비용은 매우 비싼 금액입니다.
아마존과 쿠팡과 같은 의도한 적자를 감수하는 특별한 모델이 아니면
사업 초기에 비즈니스 모델의 검증에서는 웹페이지가 없으면 이메일을 보내며 검증 할 수 있고
이메일도 보내기 어려우면 인스타그램과 블로그를 운영하며,
그것 또한 맞지 않는다면 직접 발로 뛰며 오프라인으로도 사업성을 검증할 수 있기 때문입니다.
조금 더 단순한 형태로서 먼저 사업성을 검증하는 것이 현 스타트업 혹한기에서는 생존하기 더욱 유리한 방법이기 때문이에요.
예시 중 하나로는 인프런의 초기 상황이 있겠습니다.
이러한 방식이 생존에 유리한 이유는 기획안을 변경하는 작업이 작성한 코드를 변경하는것 보다 훨씬 쉽다는 이유에 기반해요.
개발 공수를 투자하기 이전에 기획 단계에서 가능한 많은 예외 상황과 고려하지 못한 케이스를 찾아 수정하는 것이 총비용을 아낄 수 있는 좋은 방법이 될 수 있어요.
초기 스타트업에서 사업팀과 개발조직의 관계는, 길거리 버스킹 공연의 보컬과 베이시스트의 관계와 비슷합니다.
만약 우리가 길을 걸어가다 공연에 눈길이 간다면
그 이유는 베이스 기타의 소리보단 일반적으로는 보컬의 매력적인 목소리, 혹은 외모에 더 관심이 가기 쉬운 것과 비슷한 관계를 가지게 됩니다. (물론 저는 베이스 기타를 정말 좋아한답니다)
'시장의 반응을 전혀 예측할 수 없다, 그리고 아마 지금 시도는 높은 확률로 성공하지 못한다' 라는 이유로 개발자의 역할은 '일단 최대한 많은 기능을 출시하도록 도와주는 것' 이 조직에서 기대하는 제1목표가 됩니다.
이러한 상황에서 개발속도가 가장 중요하게 여겨지게 되는 이유는 초기 스타트업의 위기 때문이에요.
신규 스타트업은 창업 이후 곧바로 위기에 닥치게 되는데요,
그 위기는 바로 "시드머니가 다 소진되기 이전에 어떻게든 시장에서 유의미한 반응을 받아야 한다." 입니다.
그 외의 모든 일은 부차적인 문제입니다. 첫 번째 고비를 넘지 못하면 그 회사는 생존 할 수 없기 때문이죠.
이러한 과정은 타임어택이라고 볼 수 있습니다.
남은 시간과 탄창(자금)을 다 소진하기 이전에 필사적으로 어떠한 목표라도 맞춰야 하는 게임이기 때문이에요.
이때, 목표물을 맞추는 사수의 역할은 사업, 기획, 운영의 영향이 주도적이게 됩니다.
이전에 설명했듯이, 초기 사용자를 앱에 랜딩하게 만드는 건 앱의 좋은 퍼포먼스 보단, 마케팅과 기획이 주도적인 역할을 수행하기 때문이에요.
그럼 이러한 상황에서 개발팀의 역할은 무엇일까요?
저는 개발팀의 역량은 보급병에 가깝다고 생각합니다.
역량이 부족한 개발팀은, 단 한발의 총알밖에 제공하지 못해 올림픽 사격 선수들만 목표(시장의 반응)를 달성 할 수 있지만,
역량이 충분한 개발팀의 경우에는 충분한 탄약을 제공해 줘 제한 시간 내에 사수가 여기저기 최대한 많은 표적지를 노려볼 수 있게 되는 거죠.
결국 주니어~미드래벨 개발자의 역할은, 초기자본이 다 떨어지기 전에 최대한 많은 시도를 사업팀이 해볼 수 있는 기회를 제공하는 것이라 정리 할 수 있겠습니다.
여담) 시니어를 따로 분리한 이유는,
개발자도 시니어 레벨이 되면 개발자 대부분에 대한 관리 감독, 높은 퀄리티의 코드 산출과 더붙어, 자신의 경험을 바탕으로 사업 전반에 대한 의견도 제시할 책임과 권한이 부여되는 것 같더군요. 쉽지 않은 자리인 것 같습니다.
그렇다면 빠르기가 전부일까?
지금쯤이면 여러분들은 코드 퀄리티는 생각하지 않고 최대한 빨리 구현만 하면 다 인 건가? 라는 생각이 들 수 있을 거에요.
시장의 초기 반응을 확보하는 데에는 개발자의 능력 중, 구현 속도가 가장 중요한 요소인 것은 사실입니다.
하지만 일단 반응이 온 뒤는 어떨까요?
시장에서 유의미한 성과를 얻었다 판단한다면, 전사적으로 드라이브를 걸어야 해요.
이때, 재빠른 기능의 추가와 CS 대응, 사용자의 요구사항을 적극적으로 반영하기 위해선 단단하고 유연한 초기 설계가 매우 중요해져요.
어렵게 잡은 기회로 들어온 사용자들이 버그로 인해 실시간으로 이탈되어 가고 있는 상황에서, 더티 코드로 인해 이를 재빨리 잡지 못한다면... 생각만 해도 끔찍하네요.
따라서 개발자는 초기 스타트업에서 "확장 가능성" 과 "구현속도" 라는 두 가치를 저울 해가며 적절한 균형을 잡으려 노력해야 합니다. (이를 흔히 trade-off라 말하죠.)
어떤 부분에 확장 가능성을 충분히 고려해야 하는지, 적당히 빨리 시장에 내보내고 필요하다면 다시 고치면 되는지에 대한 판단은 작업하는 개발자 본인 말고는 알 수 없어요.
개발자 또한 이러한 trade-off를 적절히 수행하기 위해서는 높은 기술적인 역량은 물론이고, 그에 못지않게 비즈니스 도메인에 대한 이해가 중요해져요.
예를 들자면, 실물 상품을 다루는 커머스 비즈니스의 경우에는 고객의 주소지 정보가 비즈니스에 매우 중요한 정보이겠지만
제품을 직접 배송하지 않아도 되는 비즈니스, 예를 들어 게임의 경우에는 고객의 주소 정보는 비즈니스에 정말 핵심적이지는 않겠지요?
이처럼 본인이 작업하고 있는 비즈니스가 과연 어떤 시장의, 어떤 비즈니스 모델을 가지고 있는지에 대한 이해가 결국 제품의 UX 퀄리티로서 나타난답니다.
또한 이러한 trade-off 가 정말 어려운 점은, 정답이 없다는 점입니다!
어떠한 대원칙을 따르며 진행할 수 이는 영역이 될 수 없고, 그때그때 보다 적절하다고 믿는 방향으로 결정해야 하기 때문이죠.
궁극적으로 추구해야 하는 방향이라는 어렴풋한 나침반은 가지고 있지만.
가장 빨리 가는 길이 지나고 보면 돌아가는 길이고,
일반적인 정답 또한 때와 상황에 따라서 이번에는 다를 수도 있어요.
이러한 부분이 소프트웨어 엔지니어링을 정말 어렵고 가치 있게 만들고, 이러한 결정을 잘 수행하는 사람은 공학을 Technology에서 Art 의 영역으로 승화시키는 사람이라 생각해요.
이 글을 읽고 계신 여러분도 앞으로 주도적으로 확장 가능성과 개발 속도의 trade-off를 판단하고 왜, 얼마나 투자해야 하는지를 팀에게 적극적으로 공유해보려 노력해 보시는 건 어떨까요?
결론
이제 글의 시작에서 말씀드린 스타트업이 만약에 밴드라면, 개발자의 포지션은 베이스 기타에 가깝다고 말씀드린 제 말을 조금은 동의하실지 모르겠네요.
필드의 최전선에서 고객의 피드백을 직접적으로 받는 사업, 운영팀에 대해 존중과 응원을,
개발자가 스타트업 조직에서 해야 할 업무는 이를 돕기 위한 기술적인 지원이라는 걸 마지막으로 강조하며 글을 마무리해 봅니다.
