HOONS의 소프트웨어 개발이야기

스타트업의 개발 환경은 조직과 환경의 특성상 일반 개발 조직과 많이 다르다. 보다 민첩해야하고 자기주도적이여야 하며 낭비를 최소화 해야 한다. 이런 부분에서 개발팀에서 많이 하게 되는 공통적인 실수들을 많이 보게 되는데 미리 알아두면 좋을 5가지 전략을 공유해 본다.

1. Trend와 Right Tech를 구분하는 것

개발팀을 꾸릴때 가장 먼저 하게 되는 것이 어떤 기술 스택을 이용해서 개발을 해야 되는지 고민하는 경우가 많다. 손에 잘 맞는 도구가 있을 것이고 한번 잡아보고 싶은 도구도 있을 것이다. 손에 맞든 맞지 않든 좋은 트렌디한 기술들은 개발자들을 영입할 때 좋은 당근이 당연하기 때문에 달콤하다. 하지만 이때 과도한 기술 트렌드의 유혹을 이기지 못하고 여러 트렌디한 기술들을 무차별하게 도입한 뒤에 예상치 못한 문제들에 대응하게 되는 것을 많이 보게 된다. 왜냐하면 그 기술 트렌드에서 부각되지 않은 단점들을 많이 생각해보지 못한 경우 때문에 그렇다.

대부분의 테크 트렌드는 기존의 개발문제나 기술문제를 해결하고 더 좋은 퍼포먼스를 제공한다. 하지만 여기서 생각해볼 부분이 그 기술문제를 해결하는 방법이 기존의 어떤것을 포기하고 장점을 취하는 즉, 트레이드 오프의 형태로 대안을 찾아 간다는 부분이다. 예를 들어, 요즘 많이 사용하는 flask라던가 node.js와 같은 마이크로 웹 프레임워크 같은 것들은 빠른 성능을 제공하는 대신 안정성은 개발자들의 몫으로 돌리는 것과 같은 이야기다.

즉, 이런 형태의 기술 트렌드들은 대부분 더 좋은 퍼포먼스와 해결점에만 초점을 맞출 뿐 그것을 통해서 잃게 되는 단점 부분에 대해서는 초점을 맞추지 않고 있다. 때문에 개발자들이 그 기술의 명과 암을 정확하게 읽어내기 어려운 부분이 있다.

다른 예를 들어 보자면 RDB 대신 NOSQL을 선택한 경우이다. 빠른 엑세스 속도를 제공하는 대신에 안정성 부분과 데이터들끼리의 릴레이션 관리에 대해서는 개발자들이 해야하는 일들이 더 늘어날 수 있다. 그리고 만약 데이터의 관계 구조가 복잡하다면 Json을 이용한 쿼리문 작성은 어마어마하게 늘어날 수 있다는 것을 감안해야 한다.

즉, 어떤 새로운 기술을 도입하기 전에 이 기술이 어떤문제를 해결하였고 반면에 어떤 부분을 희생하게 되었는지 단점을 중심으로 먼저 살펴보아야 한다. 어떤 부분에서 장점이 될 수 있고 어떤 단점이 있을지를 명확하게 분석해서 접근하는 노력이 필요하다는 이야기다. 

이렇게 트레이드오프 형태의 기술들이라면 어느정도 보안하면서 여차저차 끌고갈 수는 있다. 물론, 안정성에서는 많은 시행착오를 거칠 것이라고 하더라도 말이다. 하지만 더 큰 리스크는 전혀 새로운 형태의 기술 트렌드를 따르는 것이다. 예를들어 HTML5를 통하여 하이브리드 앱을 만든다거나 메신저와 같은 하이테크 앱을 개발하는데 있어서 티타늄이나 자마린 같은 도구를 쓴다거나와 같은 결정이다.

이런 형태의 기술들은 다시 돌이키기 어려운 결과를 가져오게 된다. 페이스북이 모바일 앱에서 고전했던 흑역사도 너무 이른 타이밍에 HTML5를 도입하여 하이브리드 앱을 만든 것에 있었다. 페이스북이 네이티브 앱을 발표하면서 모바일 매출의 증가속도가 2배나 늘어나는 것을 볼 수 있었다. 말은 그럴싸하겠지만 어떤 제품을 개발하는데 있어서 지름길은 존재하지 않는다. 단지 타협이 존재할 뿐이다. 우리의 기술 목표와 잘 부합하느냐에 따라서 더 필요한 강점을 찾을 수 있는 기술을 선정하고 또 그 기술의 단점을 어떻게 매울 수 있을지를 구분해 낼 수 있는 안목을 기르거나 많은 사람들을 만나서 그 경험을 들을 필요가 있다. 

[HTML5로 개발되었던 페이스북 하이브리드 앱]

여기서 할 수 있는 질문이 리서치를 해보니 적합한 도구 같은데 내가 사용하기에는 낯선 도구라면 어떻게 해야할까? 일텐데, 이것은 개인 역량에 달렸다. 보통 senior 레벨의 개발자들이라면 도구를 바꾸는데 있어서 큰 거부감이 없을 것이지만 개인의 역량에 따라서 시간이 많이 걸릴수도 있고 어려울수도 있다. 필자의 주관은 뛰어난 개발자들로 꾸려진 팀이라면 낯선 도구의 거부감이나 두려움은 많지 않다고 생각한다.

2. 로드맵보다는 사람이 중요하다.

팀이 꾸려지기 전에 로드맵을 만드는 것은 굉장히 신중하게 생각해봐야 할 문제이다. 잘못된 선택을 할 수 있는 리스크가 커지기 때문이다. 만약 그 전에 로드맵을 만들어도 적절한 사람을 찾지 못할 경우에 대한 로드맵도 따로 준비하는 것이 중요하다. 예를 들어 개발 로드맵이 확정된 상황에서는 대부분 개발팀을 뽑아야 할 데드라인이 형성된다. 하지만 그 데드라인은 결국 원했던 사람이 아닌 그저 그랬던 멤버와도 타협을 야기하게 된다.

여기서 최악의 경우가 발생할 수 있는데 그렇게 뽑은 사람의 퍼포먼스가 생각보다 나오지 않아서 다시금 채용을 하게 되는 경우이다. 스타트업에서는 팀을 최소화 하여 원하는 퍼포먼스를 정확한 방향으로 끌고가야 한다. 하지만 팀이 늘어나게 되면 그만큼 버틸 수 있는 맺집이 약해지게 되고 더불어 의사결정이 더딜 수 있고 마지막으로 관리라는 보이지 않는 리소스가 추가되게 된다. 즉, 사람을 뽑음으로서 그 사람의 100% 리소스를 쓰는것과 더불어 그 사람과 커뮤니케이션하고 관리를 하기 위한 한 사람의 10-30%의 리소스를 포기해야 되는 것이다. 주니어 레벨일수록 관리자의 리소스를 더 많이 필요하기 때문에 시니어 레벨에서도 충분히 할 수 있는 일이라면 최대한 시니어 레벨을 뽑는것이 좋다.

그럼 어떻게 내가 원하는 사람을 효율적으로 영입할 수 있을까? 초기 단계의 스타트업에서는 발품을 파는 수밖에 없다. 사람을 물어물어 어떻게든 좋은 사람을 수소문해내고 찾아가서 비전을 보여주고 원하는 것을 제시해야 한다. 초기 단계라면 아이디어와 팀원을 보게 된다. 적어도 내가 믿고 따를 리더나 동업자들이 적어도 같은 수준이 되냐라는 것이다. 그들이 생각한 아이디어에 호응을 얻어서 조인하는 경우는 많지 않다. 그 대상이 되는 정확한 고객이거나 같은 비지니스 도메인에 있으면서 자기가 생각했던 불편함들과 일치할 확률이 극히 드물기 때문이다. 만약 구인광고를 하게 되면 아이디어와 제품과 더불어 어떤 사람들이 모여있는지 어필해줄 필요가 있다.

스타트업 프로토타입이 만들어 지고 A/B 시리즈를 받아서 팀을 확충해야 하는 경우라면 좋은 기술스택과 회사의 비전 그리고 개발자들이 좋아할만한 혜택들을 얹어서 홍보를 한다면 채용은 조금 수월해진다. 이때 좋은 사람을 찾아야 하는데 아마 좋은 기술력과 팀에 잘 녹아들 수 있는 인성을 가진 사람이 원하는 인재일 것이다. 그 사람이 스킬풀한지에 대한 고민은 기술에 대한 열정과 코딩테스트를 통해서 충분히 고민해볼 수 있기 때문에 어렵지 않다. 하지만 인성은 같이 일해본 경험이 없다면 고민이 될 수 밖에 없다. 이것을 검증하기 위해서 많은 기업들이 내부추천제도를 통해서만 채용하는 경우도 있고 어떤 회사는 면접에서 악역을 만들어서 어떻게 반응하는지 보는 경우도 있다. 

필자가 해외에서 개발팀을 꾸렸을 때는 인성부분을 크게 걱정하지 않아도 됐다. 외국에서는 일하기 전에 경력이든 신입이든 프로베이션 기간을 가지는 것이 일반화 되어 있기 때문이다. 보통 프로베이션 기간 동안에는 채용 후보자의 인성과 팀원들과 어울리는 모습을 2달 정도 지켜보게 된다. 그리고 그 기간 이후에 본인도 원하고 회사가 원한다면 그때 정식으로 같이 일을 하는 옵션으로 진행하게 된다. 

국내에서는 이 기간을 수습기간이라는 제도로 오해하게 되면서 많은 사람들이 꺼려하는 경우가 있기는 하다. 그래도 국내의 여러 스타트업들에서 많이 도입하고 있는 것으로 알고 있다. 만약 후보자가 정말 이 회사에 뜻이 있고 자신의 인성이 떳떳하다면 솔직히 이 기간을 망설일 이유가 없을 것이다. 더군다나 안정을 원하는 사람이라면 스타트업을 선택하는 이유가 없기 때문에 크게 걱정하지 않고 도입해보는 것을 추천한다.

마지막으로 똑똑한 싸가지 때문에 고생하고 있는 스타트업이 있다고 한다면 필자가 생각하는 방법은 한가지 밖에 없다. 우정으로 그를 설득시키거나 뜻을 전달하는 방법밖에 없다. 논리적으로 누군가를 설득한다는 것은 한국 사람들에게는 많이 어렵다. 토론문화 없이 주입식 교육으로 자라왔고, 토론이 맞는 것을 같이 찾는 과정이라기 보다는 서로 자신의 논리가 맞다고 서로 주장하는 시간으로의 인식이 아직도 팽배하기 때문이다. 

더군다가 스타트업에서는 데이터나 숫자가 아닌 개인의 역량과 판단 지표로 결정을 내려야 하는 경우가 많은데 이 인사이트가 모두를 만족시킬 수는 없다. 이 때 만약 똑똑한 싸가지와 방향이 다르다면 불만을 토로하며 분위기와 사기를 저해하는 경우가 많다. 이런 불만이 있을것 같은 상황을 항상 주시하다가 우정으로 먼저 다가가서 그를 설득시켜야 한다는 것이 그들을 다루는데 핵심이다.

3. 핵심기술 외에는 관대해져라.

애자일의 한 개발방법론으로 스타트업에서 많이 채용하고 있는 철학 중에 하나가 바로 린(Lean) 개발 방법론이다. 이 린 방법론의 핵심은 원래 만들려고 했던것에서 1/3만 만들라고 이야기 하고 있다. 대부분의 제품은 사용자의 피드백을 받으면 그 모양이 변하기 마련이다. 그 변화를 통해서 많은 기술들이 낭비를 거듭하게 되는데 결국 그 낭비를 최소화 하기 위해서 생각한 핵심 기능만 제대로 만들어서 피드백을 받아 보자는 것이다.

핵심만 만들자는 것이 말은 쉽지만 개발자들에게는 어려운 숙제이다. 개발자들은 자신이 원하는 제품의 퀄리티와 완성도를 높이기 위한 관습이 그들도 모르게 베여있다. 때문에 작은 기능에도 완벽함을 추구하려고 할 것이다. 지금 고치지 않아도 되는 옵션 정도의 기능도 개발자들은 볼때마다 눈에 거슬려서 때로는 일의 우선순위가 그들은 다르게 생각할 수도 있다. 이 것을 조율하기 위해서는 개발자들에게 Lean 방법론에 대한 공감을 같이 얻어내는 것이 중요하다.

스타트업에서 TDD를 적용해야 하냐는 토론들을 많이 보고는 한다. 필자의 견해는 스타트업이 기술로서 완벽을 추구해야 하는 시기는 적어도 A/B 시리즈 투자를 받고 기술을 통해서 비지니스의 퍼포먼스를 내줘야 하는 시기라고 생각한다. 초기에는 완벽하게 1개의 제품을 만드는 것보다는 2-3개의 제품을 MVP로 만들어서 시장의 반응을 살펴 보는 것이 중요하기 때문이다. 때문에 100%의 테스트 커버리지를 스타트업 초기 단계에 작성하는 것은 바람직하지 않다. 단, 비지니스를 이루는 핵심 기술에 대해서는 시간을 투자하는 것이 맞다. 다시 말하자면, 핵심 기술이라고 생각하는 영역에 대해서는 TDD를 도입하고 자동 테스트를 만들어 두는 것이 나쁘지 않다는 것이다.

추가적으로 스타트업이 무게를 두어야 할 곳은 Front-end보다는 Back-end(서버사이드)라고 말하고 싶다. 스타트업의 핵심멤버는 반드시 백엔드 사이드를 잡고 있어야 한다. 멤버가 없어서 외주를 줘야 한다면 front-end까지는 가능할 수 있다. 프론트엔드는 자주 바뀔 수 있는 영역이다. 하지만 서버 사이드는 한번 설계하면 바꾸기가 비교적 수월하지 않고 아키텍쳐 확장에도 많은 영향을 주게 된다. 때문에 핵심 개발 멤버를 모집하려면 서버사이드 멤버가 1순위가 되어야 한다.

4. 사용자 중심의 언어로 커뮤니케이션 하라.

스타트업에서 가장 중요한 요소는 커뮤니케이션이다. 하지만 개발팀이 존재할 경우에 간혹 기획팀과 개발팀 사이에서 커뮤니케이션 문제로 제대로 호흡을 맞추지 못하는 경우를 많이 보게된다. 최악의 경우는 서로 사이가 안좋아지기까지 하는 경우이다. 개발팀은 팀내에서 개발 용어로 커뮤니케이션을 하는 것이 아닌 누구나 다 알 수 있는 공용어를 써야 한다. 

조금더 구체적인 예를들어 보자면 만약 업무의 진행상황을 볼 수 있는 보드가 있다면 이 보드에는 "DB설계", "서버셋팅" 등과 같은 개발 용어를 이용하기 보다는 기능 위주의 "feature1", "feature2"와 같은 용어가 있어야 한다는 것이다. 이런 공용어들을 통해서 개발팀 뿐만 아니라 모든 멤버가 업무의 우선순위를 정하고 팀의 진척을 파악하고 적당한 타이밍에 데모를 요청해볼 수 있는 척도를 알 수 있기 때문이다.

스타트업은 많은 시간 리서치에 시간을 투자하기가 어렵다보니 비지니스의 정확한 숫자와 데이터를 기반으로 일을 진행하기가 어렵다. 때문에 그들의 인사이트로 제품을 개발해 나가는 경우가 불가피 한데 이런 이유 때문에 방향이 충분히 틀릴 수 있고 제품의 로드맵은 언제든 즉시 수정이 가능해야 한다. 이때 이런 작업을 원할하게 도와주는 것이 사용자(고객) 중심 언어의 소통이며 팀원들끼리의 퀄리티 높은 커뮤니케이션이다. 여기서 퀄리티 높은 커뮤니케이션은 얼굴을 보면서 바로 옆에서 할 수 있는 대화이다. 이런 일들을 메일이나 내부 툴 혹은 메신저를 통해서 하는 것은 질과 민첩성을 떨어뜨리게 된다. 때문에 스타트업의 개발팀이라면 독립된 공간에서 원하는 시간에 일하기 보다는 어느정도 시간을 맞추어 다같이 한곳에 모여서 일하는 것이 가장 효율적이다라고 정의할 수 있다. 

5. 애자일의 함정에 빠지지 말아라.

마지막으로 하고 싶은 이야기는 애자일 개발 방법론의 함정을 조심해야 한다는 것이다. 결론부터 이야기 하자면 애자일의 스크럼은 개발팀이 5명채 되지 않은 작은 스타트업 조직에게는 적합한 도구가 아니다. 많은 스타트업들이 애자일 환경에서 일하는 것을 선호하고 많이 도입을 하려고 한다. 애자일을 도입한다의 올바른 의미가 XP, 스크럼, 린, FDD, 크리스탈등과 같은 도구를 도입하는 것이 아니다. 아쉽게도 많은 기업들이 그저 그런 practice들을 따라해보는 것을 애자일을 도입하는 것으로 오해하는 경우가 많다. 애자일을 도입한다는 것은 개발팀 모두가 애자일 메니페스토(http://www.agilemanifesto.org)에서 이야기 하고 있는 개발 철학을 받아드리고 있냐라는 것이다. 여러 방법론들은 자신의 조직구조와 특징과 특성을 분석한 뒤에 잘 맞는 방법론들을 이용하면 된다. 즉, 도구의 개념으로 보면되는 것이다.

예를 들어 스크럼 방법론의 경우 Epic과 같은 큰 카테고리를 생성하고 그 밑에 유저스토리 그리고 또 그 아래 task가 덧붙여지게 된다. 그리고 각 스토리마다 추정을 통하여 일의 크기를 결정하게 된다. 이런 많은 작업들을 유지하기 위해서 스크럼 마스터가 책임을 지고 개발팀과 더불어 업무들을 관리하는 것을 부여하게 된다. 하지만 개발자가 많아야 2-3명 되는 스타트업의 환경이라면 이런 프로세스 자체가 오히려 곤욕이고 퍼포먼스가 저해될 가능성이 높다.

애자일에서 이야기 하고 있는 것은 고객 중심적인 사고를 가지고 변화를 인정하면서 지속적으로 만들고 있는 결과 최대한 자주 확인하면서 대화해 나가는 것이 핵심이다. 개발자들은 기획문서를 찾고 그것을 만들면 끝나고 왜 기획서에는 그런 내용을 넣어두지 않았냐고 할것이 아니라 그런 것들도 계속 대화를 통해서 덧붙여 나가는 것이다.

(이 내용은 개인적으로 SKT 인사이더 인큐베이팅 프로그램에서 발표했던 "스타트업을 위한 기술전략"을 글로 옮겼습니다.)