오버 엔지니어링과 기술 부채

워낙 요즘 스타트업과 IT 기술에 대한 관심이 높아지다 보니 마치 경쟁이라도 하듯이 기술 스택이 복잡해지고 있다. 어떤 사람은 기술 부채 라는 단어를 만들기도 하고, 반대로 오버 엔지니어링이 화두가 되기도 한다. 여기에 대한 의견은 사람마다 다르겠지만 잠깐 짚어보고 넘어가보고 싶다.

오버 엔지니어링

얼마전에 한 스타트업 CTO 가 쓴 기술 스택과 구현 과정이 인터넷~~페이스북~~ 상에서 많이 공유되었는데, 솔직히 과도했다고 느껴졌다. 뭐 나름대로 그렇게 한 이유는 다양하겠지만, 그 서비스의 엔지니어링 스펙을 실제로는 20%도 다 못쓰고 있을거라는 것이 자명했다.

본질적으로 해당 서비스는 쇼핑몰이었다. 동영상이 들어간 쇼핑몰. 아마 그 정도는 카X24 혹은 고X몰~~고자몰?~~ 로도 충분히 만들 수 있고 안정적으로 운영할 수 있었을 것이다. 물론 기왕 만들거 잘 만들면 좋겠지만, 장담컨데 들어간 엔지니어링 혹은 개발자에 비해 트래픽은 상대적으로 낮을것이다. 그렇다면 굳이 왜 그렇게 만들어야 했을까?

우리가 오버 엔지니어링을 하게 될때 이는 스케일 업에 대한 고민에서 시작된다. 서비스 성장 가능성 이라던가 개발 확장성을 고려하게 되면 자연스럽게 엔지니어링에 대한 욕심이 생겨난다. 예를 들어 이런 것들이다.

사용자가 폭주하면 어떻게 될까?

서버를 가상화하여 긴급 상황에 대비하도록 하자.
Docker 나 Vagrant 로 패킹해두면 손쉽게 가능할 것이다.
queue 를 도입하여 폭주 상황을 효율적으로 핸들링하자.

서비스 확장성을 고려한다면...

단순히 static 페이지만 보여주지 말고 인터렉션을 추가할 수 있게 react 를 도입하자.
open source e-commerce 를 사용하면 API 개발도 효율적이겠지.
관리자 페이지는 점점 더 늘어날테니 Django 가 좋겟다.

신기술을 써보자

실시간 성을 강화하기 위해 socket 을 도입하자.
rethink-db 가 궁합이 좋다더니 이것도 써보자.

솔직히 말해서 나도 한번씩 다 해보고 싶은 것들이다. 뛰어난 개발자일수록 이러한 유혹에 빠지기 쉬운데, 가장 큰 이유는 꼭 필요해서가 아니라, 해보고 싶고 또 할 수 있기 때문이라는 것을 부정할 수 없을 것이다. 반면 CEO 라면 필요한 것의 대부분은 이미 저렴한 가격에 디자인만 입히면 (심지어 디자인도 저렴하다) 바로 서비스를 시작할 수 있는데 왜 저렇게 해야 하나 하는 의문이 생길 것이다.

기술 부채

한편으로는 기술 부채가 있다. 내가 근무하는 회사의 경우 앱 개발이 사실상 웹 개발과 다를 것이 없다. PHP 웹 페이지를 Cordova 로 감싼 형태로 이루어져 있다보니 장점보다는 단점이 많다. 태생적 한계 또한 없지 않아서, 기능 수정에 많은 노력에 드는 것도 사실이다. 그러다보니 서비스 개발에 필요 이상의 노력이 필요한 경우도 있었다.

이전에 잠깐동안 근무하던 한 회사의 CTO 가 이런 말을 남겼고 큰 공감을 느꼈다.

모든 기술 기반의 스타트업이 성공하는 것은 아니지만, 성공한 스타트업은 모두 기술이 뛰어난 회사이다.

결국 성공하는 기업은 기술 부채를 언제까지 방치할 수는 없고, 부채는 단기적으로는 자산이지만 당연히 장기적으로는 갚아야할 빚이다. 언젠가는 갚아야 하는데, 생각보다 그 순간이 빠르게 다가올 수 있다. 벤처에서 흔히 말하는 Chasm(캐즘) 에 빠졌을때 기술적으로 성숙하지 못하면 이를 빠져나오기 위한 비용이 많이 발생하게 되고, 원하는 시기에 성장하지 못하게 될 가능성이 많다. 이 역시 예를 들어 보자.

단독 서비스에 한계가 왔다.

추가적인 서비스를 개발해야 하는데 레거시 코드를 손보기가 매우 어렵다.
이미 매출이 발생하는 레거시를 버릴수는 없고, 이걸 건드리자니 너무나 고생스럽고 그러다보니 당연히 버그가 많다.

트래픽과 서버 유지/보수 비용이 동시에 가파르게 증가한다.

트래픽이 늘어나는 건 확실한데 서버 유지/보수 비용 또한 함께 증가한다.
가상화가 되어있지 않아서, 빠르게 스케일 아웃 할 수 없고 다시 줄일수도 없다.
데이터베이스를 확장하다보니 서비스 중단이 발생한다.

신기술 도입이 필요하다.

실시간성이 중요해져서 소켓을 도입하려니, 현재 기술 스택에서 개발기간이 크게 늘어난다.
차세대를 할만한 여유는 없는데, 지금 기술로는 성장에 방해가 될 정도에 이르렀다.
오래된 기술 때문에 좋은 개발자들이 지원하지 않는다.

어느 순간에 이르면 확실하게 한계가 보이기 시작한다. 최근 유행하는 머신 러닝이나 로그 분석 과같은 기본적인 매출 최적화도 사실상 기술 스택이 낮으면 유지/보수 업무로 인해 시간을 투자하기 어렵다. 게다가 서비스는 시간이 갈수록 개발 복잡도가 기하 급수적으로 올라간다. 때문에 단순한 기능 수정에 불과한 일들도, 리팩토링 수준이 낮거나 기술 성숙도가 떨어지면 어려움을 겪을 수 밖에 없다.

뭐가 중헌디

나는 어플리케이션 개발자로서 엔지니어링과 서비스 운영이라는 두가지 토끼를 쫓아야 한다고 생각한다. 개발자로서 서비스를 운영을 게을리 해서도 안되고, 엔지니어링에 집착해서 빠르게 방향전환을 못해서도 안된다. 하지만 둘 중 하나를 꼭 선택해야 한다면 당연히 서비스 운영이어야 한다. 개발자도 월급이 필요하다. 월급을 받으려면 회사가 기능해야 하고 회사로서 발빠르게 고객에 대처하려면 개발의 도움이 반드시 필요하다. 나는 오버 엔지니어링을 피하기 위한 몇가지 기준을 세웠다.

이 기술이 없으면 서비스가 불가능한가?

가능하다 : 0점
불편하다 : 3점
불가능하다 : 5점

이 서비스는 단기간 내에 복잡도가 증가할 것인가?

그렇지 않다 : 0점
잘 모르겠다 : 1점
그렇다 : 3점
매우 그렇다 : 5점

이 기술을 감당할 개발자가 나 말고 또 있는가?

그렇지 않다 : -1점
1명 : 1점
2명 이상 : 3점

이 서비스의 고객은 어떠한 사람인가?

무료 사용자 : 0점
유료 사용자 : 3점

해보고 싶고 일정을 지킬 수 있는가?

해보고 싶다 : 1점
해보고 싶지만 자신 없다 : 0점
두마리 토끼 둘다 가능하다 : 3점

결과

8점 이하 : 오버 엔지니어링
8점~11점 : 기술 부채를 쌓아도 괜찮다
12점 이상 : 적정 엔지니어링

서비스에 영향을 줄 정도가 아니라면 기술 부채를 안고 가는 것도 나쁘지 않다. 엔지니어링이 지나치면 돈이 많이들고 개발 기간이 늘어나는 것은 물론이거니와, 개발자의 스트레스도 높아진다. 높은 개발비를 투자해서 개발은 완료 했는데, 서비스 사용자는 없다. 게다가 개발비를 너무 많이 들이다보니 방향전환도 어렵고, 투자금은 바닥을 드러낸다.

마지막으로 더게임툰의 한장면을 인용해서 끝을 맺고 싶다.

최신 기술로 앞서 나가야 하는 것이 아니다. 서비스의 본질은 아이디어와 운영이다. 우리는 엔지니어인 동시에 서비스 개발 책임자 라는 것을 잊지 말자.