웹 개발자로 스타트업에서 살아남기 : Demo

들어가며

스타트업에서 일한 지 벌써 몇 달이 지났다. 스타트업에서 웹 개발자로 살아가면서 여러 고난을 겪고 내가 해결한 방법과 탐구 과정에 대해서 정리해보려고 한다. 아직 많이 미숙한 글이지만 이 글이 다른 스타트업에서 힘겹지만 노력하는 개발자들에게 도움이 되었으면 좋겠다.

 

환경

나는 이제 막 시드 투자를 유치하는 스타트업에 웹 개발자로 참여하게 되었다. 이 시기의 스타트업은 실제로 사용자를 모으고 비즈니스 모델을 단단하게 구현하기 보단 투자자, 협업체 그리고 예비 사용자의 피드백을 받고 거기서 새로운 시도를 통해 어떤 가치를 찾을 수 있을지 탐구하는게 가장 큰 목표다. 즉, 시도와 보완이 계속해서 이루어진다. 마치 인공지능이 올바른 방법을 찾기 위해서 학습을 하고 평가를 반복하듯 보이지 않는 정답을 향해 한 걸음 또 한걸음 나아간다.

그렇기에 거의 매번 요구사항이 변경되는 경험을 얻을 수 있다. 정말로 심할때는 한 번 회의를 할 때마다 6개 이상의 기능이 변경되거나 처음에 정말로 변하지 않을 거라 계획했던 기능조차 변경된 경험도 했다. 예를 들어, 복합적인 환자 정보를 효과적으로 관리하는 시스템을 단순히 환자 이미지를 관리하는 시스템으로 바꿔달라는 소리를 들었을 땐 정말로 어안이 벙벙했다. 예전에 책에서 사용자도 정말로 자신이 뭘 원하는지 모른다는 글을 읽었는데 이를 실감하는 경험이었다. 

 

하지만 인력은 부족하다. 경영자의 입장에서는 "빠르게", "다양한" 시도를 원한다. 이를 위해선 그 만큼의 인적, 물적 자원이 필요하지만 스타트업에은 대기업에 비해서 이 자원이 턱없이 부족하다.  클린 애자일에서는 프로그래밍의 피할 수 없는 진리로 철십자가 언급된다. 철십자는 좋음,빠름,저렴함,완성 중 오직 3가지만 선택이 가능하다는 뜻이다. 스타트업은 여기서 완성과 저렴함을 무조건 선택할 수 밖에 없다. 자본은 부족하고 결과를 만들어야 하기 때문이다. 따라서 스타트업에서는 느리지만 좋은 결과를 만들 것이냐, 좋은 기능은 아니지만 빠르게 결과를 만들 것이냐 둘 중 하나의 선택이 강요된다.

문제

하지만 경영자는 "좋은"걸 "빠르게" 만들길 원한다. 물론 좋은 인력이 많으면 많을수록 이를 만족 할 수 있다. 그러나, 앞서 말했듯 스타트업은 자원이 부족하지 않은가? 여기까지 글을 읽은 사람들은 개발을 하기 전에 기획자가 요구사항을 검수하고 디자이너가 목업을 만들어 최소한의 필요성을 검증한 다음에 개발을 진행하는 스프린트를 적용하면 최대한 효율적으로 진행되지 않을까?라고 생각하지만 이상과 현실은 다르다. 경영자는 최소한의 자원을 투입하려고 한다. 그리고 아직 배포하지도 않을 프로젝트를 위해서 기획자나 디자이너는 필요하지 않다고 생각한다. 또한 반복적인 수정사항이 코드를 망가뜨리고 나중에 수정사항을 요청할 때마다 비용이 많이 드는 것을 이해하지 못한다. 

 

그리고 디자이너가 목업을 만드는 것도 한계가 존재한다. 웹 개발같은 경우 기능이 반응형, 사용자와 상호작용 그리고 동영상 등 동적인 경우가 많다. 이런 기능은 디자이너가 Figma, Adobe XD를 이용한다고 해도 구현하기가 어렵다. 따라서 예비 사용자나 협업체에서 올바른 피드백을 주기가 어렵다. 실제로 Figma를 이용해서 만든 데모를 통해 받은 피드백 보다 MVP를 통해 받은 피드백이 훨씬 많고 가치가 있었다. 그리고 초기 스타트업은 가치있는 피드백이 곧 비즈니스 모델로 직결되기 때문에 매우 중요하다. 

 

또한 개발 가능성과 예상 구현 기간을 추론하는데도 직접 개발을 진행하는 것은 매우 중요하다. 새로운 요구사항이 추가되면 항상 따라오는 질문이 있다. "언제까지 개발이 가능한가요?". 이미 많이 구현해본 기능이고 기존 코드에서 쉽게 변경할 수 있을 것 같다면 이 질문에 잘 대답할 수 있지만, 전혀 새로운 기능이거나 기존 코드에 어떻게 이식할지 감이 잡히지 않을 때는 곧바로 대답하기 어렵다. 하지만 경영자도 일정이 있기 때문에 예상 개발 기간은 매우 중요하다. 이 경우 목업을 따로 만들기 보다는 오히려 바로 구현을 시도해봄으로써 예상 기간을 빠르게 파악할 수 있다. 

 

즉, 이상적으로는 기획 - 디자인(프로토타입, 목업) - 개발 과정은 훌륭한 수단이지만 초기 스타트업에서는 이를 실행하기 위한 인력이 부족하고 빠르게 좋은 피드백을 받기 어려우며 개발 일정을 예상하기 어렵다. 

해결 방법

결국 초기 스타트업에서는 빠르게 기능을 구현하는 것이 중요하다. 여기서 웹 프로젝트 구조를 다시 돌아보자. 현재 내가 개발하고 있는 웹 프로젝트는 아래와 같이 3-Tier로 구성되어 있다. 그리고 나는 프론트와 벡엔드 모두 개발을 진행중인데 지속적으로 기능 요구사항을 받으면서 알게 된 것이 하나 있다. 사실 피드백을 위해서 서버나 데이터베이스의 기능은 그렇게 중요하지 않은 것이다. 대부분의 피드백은 클라이언트에서 뷰와 컴포넌트가 어떻게 구성되어 있고 클릭이나 드래그 등 입력시 어떻게 반응하는지가 중점이지 서버에 어떤 기능을 추가해 달라는 요구사항은 별로 존재하지 않았다. (만약 존재하고 이를 구현한다고 해도 다음 피드백의 퀄리티를 크게 높이지는 못한다.)

즉, 피드백을 받기위한 목업을 만들기 위해서 서버나 데이터베이스에서 개발이 필요하지 않다. 그래서 나는 개발과정에서 Demo 라는 스테이지를 만들어 빠르게 개발하는 방법을 도입했다.

Demo

웹 개발을 해본 사람이라면 웹 서비스는 크게 dev-stage-production 등 요구되는 환경에 따라 개발 설정이 달라지는 것을 알것이다. 나는 dev 이전에 Demo라는 스테이지를 만들었는데 이 단계는 오직 피드백을 위해서 클라이언트 데모를 만드는 단계다. 즉, 이 단계에서는 서버나 데이터페이스가 기능에 포함되지 않는다. 클라이언트에서 서버로 전달되는 요청은 모두 Fake 데이터를 전달한다. 코드로 살짝 표현하자면 아래와 같다.

// HTTP 요청 예시
HttpRequest.post('api/v2/~~')
	.then(response=> {...})
    .catch(error=>{...}
    
// HttpRequest.config.ts
config={
	request : 'api/v2/~~',
    response : {
    	status : 200,
        content-type : 'application/json',
        response : ...
    }
}

만약 yarn demo 커맨드를 이용하면 모든 HTTP 요청은 HttpRequest.config.ts에 정의된 Fake Response를 응답으로 받게된다. 하지만 yarn dev, yarn prod 커맨드를 이용해서 클라이언트가 실행되면 실제로 프록시로 설정한 서버에 요청이 전송되고 응답을 받도록 한다.

 

언듯보면 Jest를 이용해 코드를 테스트할 때 API를 Mocking하는 작업과 유사하다. 하지만 이 라이브러리는 테스트 코드가 아니라 실제로

전체적인 데모를 위해서 Fake Response를 전달하고 demo 과정에서 dev 과정으로 넘어갈 때 따로 코드를 수정할 필요가 없도록 하는 것이 목표다.

 

이를 이용하면 서버, 데이터베이스 개발 없이 빠르게 데모가 구현가능하고 결과적으로 빠르게 피드백을 받아 개발 사이클은 물론 경영자도  경영전략을 빠르게 수립할 수 있다. 현재 이와 관련된 라이브러리를 개발 중이고 업무에 적용할 예정이다. 의미있는 성과를 얻게 된다면 이 포스트에 업데이트 할 예정이다.