brunch

브런치북 비개발자와 개발자를 위한 잡담. 28화

라이킷 7 댓글

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 신현묵 Jul 17. 2019

스타트업, 사파(?)스럽게
개발 속도를 증가시키기!

하지만, 이는 마교(?)의 방법, 속성은 언제나 레거시와 쓰레기로...

스타트업 비즈니스의 속도를 증가시키는 몇 가지 사파의 방법을 적어 볼까 합니다.

첫째. 개인정보와 보안에 대해서 신경 쓰지 않는다.

서비스가 만들어지고, 구성되는 기본적인 아키텍처상에서 개인정보 보호와 보안이 가미된 상황에서 서비스가 디자인되면, 시스템은 복잡해지고, 클라이언트와 서버, 중간 API구조 등에 매우 많은 복잡성이 가미된다.

동일한 기능 하나를 구현하고, 실제 동작할 때까지 들어가는 투입 대비 결과물의 개발자 규모와 개발기간은 6배 이상 증폭된다.

보안에 신경 쓰지 않으면, 개발 속도를 증가시킬 수 있다.

둘째. 대규모 트랜잭션에 대한 구조를 만들지 않는다.

처음부터 100만 사용자를 위한 서비스를 설계하고 구현한다는 것인 비효율적인 것이 맞다. 하지만, 동시 접속자가 10명만 되더라도 데이터 정합성에 문제가 발생하고, 이슈를 만들어내는 서비스는 실제 서비스를 제공하기에는 무리가 따른다.

이런 경우에 파이썬이나 노드 형태의 싱글턴 서비스들은 매우 빠른 서비스와 대규모 트랜잭션에 대해서 어느 정도는 커버가 가능한 구조를 가질 수 있다.

셋째. 98%만 동작하면 된다.

순간적인 트래픽에 의해서, 서비스에 무리가 가는 상황에서 발생되는 손해를 포기하면 된다. 실제, 대규모 트랜잭션을 처리하는 O2O기업의 경우 이때에 발생하는 손해를 비즈니스적으로 커버하지, 서비스 규모나 개발 조직에서 커버하도록 의사결정을 하지 않았다.

대략 2% 정도의 서비스는 버려도 무방하다.

아니러니 하지만, 대규모 통신사의 경우에도 이런 규칙은 비슷한 비기능 요소로써 아키텍처에 반영된다.

넷째. 단일 언어로 만들고, 해당 서비스는 1~2년 이내에 버린다.

초기 개발 속도를 증가시키는 최선의 방법은 언어를 단일화하고, 프레임웍도 단일화하는 것이 효과적이다. 해당 서비스를 유지 보수하거나, 개발하는 데 있어서는 이 방식이 초기에 최선이다.

다섯째. 입력되는 값의 인터페이스 오류는 웬만큼 무시한다.

앱이나 웹의 경우에 사용자 입력 오류를 커버하기 위해서 개발자들은 공을 많이 들인다. 사용자가 '옳은 값'들만 입력할 수 있도록, UX를 구성하고, 개발자들은 그 이외의 상황들은 모두 예외처리를 할 수 있도록 사용자 시나리오를 구성하면, 클라이언트나 서비스 개발 속도가 3배 이상 증가한다.

여섯째. 결제나 중요한 트랜잭션 보장이 필요 없는 서비스는 테스트 기간을 최소화한다.

조금 잘못 입력된 데이터나, 사용성의 변화가 예측되는 시점에서, 결제와 같이 '보장성'이 필요한 서비스가 아닌 상태에서, 개발 이후에 배포를 최단시간으로 줄이는 방법을 사용하면, 사용자들은 비정상적인 상황에서 불편을 느낄 수 있지만, 중요 기능이 아니기 때문에 감내할 수 있다.

이때에 사용성을 커버할 수 있는 시나리오로 구성되면, 이는 개발기간을 다 축하는데 매우 요긴하다.

일곱째. 복잡한 것은 서비스에서 분리하고, 꼭 필요한 최소 기능만 구현한다.

MVP(Minimum Viable Product)의 핵심기능만 구현하는 것은 매우 당연하다. 대다수의 사용자들이 만족할 만한 기능에만 집중한다. 그리고, 기업의 본질가치를 가질 수 있는 기능에만 집중한다.

나머지 기능은 대부분 부가적인 기능들이다.

이외에도,

기타...

- 백엔드 기능을 수작업으로 처리하거나, Admin 따위는 나중에 만드는 방법으로, 실 서비스 중에는 서버 개발자가 한 땀 한 땀 수기 데이터 처리하는 방법,

- 일부 기능은 목업 형태로 만들어 두고, 서비스 개시 직전에 대응하여 대체하는 방법.

- 웹이나 앱의 경우에 기준이 되는 단말기를 가장 최신 기종에 맞추고 개발하는 방법.

- 데이터 정제나 데이터 축적은 포기하고, 일단 서비스를 가동하는 방법.

등이 있습니다.

다만...