츄카 시스템 구조 소개 - 상편

츄카 시스템은 다음 그림과 같은 구조로 설계되었습다. Client-Server-DB로 이어지는 전형적인 3-Tier구조로 아키텍처의 설명보다는 각 tier에서 왜 특정 솔루션을 선택했는지 이유를 중심으로 소개하려고 합니다.

츄카 시스템 구조도

1. Play Framework 와 Java

어떤 언어를 사용할지 또 그 언어 기반으로 어떤 프레임워크를 사용할지 가장 많이 고민했던 부분입니다. 우리에게 맞는 것이 어떤것인가를 생각했을때 스타트업이라는 것과 개발리소스가 부족할 것이라는 것에서 다음 두가지 조건이 가장 중요하다고 봤습니다.

- 생산성
- 유지보수성

두가지 조건이 통하는 면도 있고 어떤 부분은 상충되는 부분도 있다고 생각되는데 이 두가지를 적절히 조화할 수 있는 것이 무었일까 생각했을때 결론이 Java와 Play Framework 였습니다.

먼저 생산성 측면에서 보면 Java 개발에 필수라고 할수 있는 Eclipse나 Intellj 같은 IDE의 파워가 강력하고 Java로 되어 있는 수많은 오픈소스와 개발 리소스들도 생산성에 큰 도움을 줄수 있다고 봤습니다. 하지만 python, php 와 같은 언어와 같은 인터프리터가 아니기 때문에 개발 결과물을 보기 위해서 compile 과정을 거치고 또 서버를 재시작하는 과정이 문제이기는 합니다.
Play Framework은 이런 문제를 해결하기 위해 triggered execution 이란 기능을 제공합니다. 이름에서 대충 예상되듯이 소스가 변경되면 compile을 수행하고 서버 재시작없이 결과물을 확인 가능합니다. 이런 기능이 있기 때문에 인터프리터가 가질수 있는 장점을 Java 개발에서도 경험할 수 있습니다.
또한 Play Framework 은 경량프레임워크이기 때문에 간단한 설정으로 시작이 가능하고 비지니스 로직 개발만 집중해서 개발만 할수 있도록 되어 있습니다.

두번째 유지보수성 측면에서는
일단 유지보수성이 훨씬 중요한 요소라고 생각되는데 개발보다 유지보수 기간이 더 긴것이 당연하고 또 스타트업의 특성상 오픈이후 실 사용자들의 반응을 보고 개편을 하는 것이 더 중요하기 때문입니다. 이런 측면에서 볼때 python, php 같은 언어들은 문법적 오류를 코드가 실행되어야 알수 있는데 이점은 그동안의 경험상 굉장히 유지보수를 힘들게 하는 지점이었습니다.
물론 테스트 케이스를 촘촘히 잘만들면 된다고 하지만 테스트 코드의 코드 커버리지를 100%로 만드는 것은 현실적으로 불가능한 일이기도 하고(사실 50%도 쉽지 않죠) DB 작업이 대부분인 웹서비스의 테스트 코드는 테스트를 위한 데이터 준비도 만만치 않은 작업입니다.
그래서 Java같은 static typing  언어가 유지보수성에서는 좋다고 판단했습니다. 코스 수정시에도 변수명이나 함수명을 수정하면 이것을 사용하는 부분에서 바로 compile error가 발생하고 이걸 쉽게 파악할수 있기때문에 이런 static typing의 특성은 시스템이 커지고 복잡해 질수록 유지보수성에 도움을 준다고 생각합니다.

참고
playframework - https://www.playframework.com/
sbt - http://www.scala-sbt.org/
triggered execution - 이 기능은 정확히는 play framework 의 빌드 툴인 sbt 의 기능입니다. 하루종일 개발을 하다보면 가끔 비정상적으로 빌드가 되는 경우가 있어서 가끔은 클린빌드를 해줘야 하기는 합니다. --;

2. Ncloud를 서버 인프라로

저희 개발팀은 모두 N사 출신입니다. 아주 큰회사죠. 스타트업을 시작하고 나서 다시 한번 느꼈습니다. "내가 맡아서 개발한 부분은 정말 작은 것이구나. 내가 개발하기 위해 정말 많은 사람들이 일하고 있구나."

그중에서 인프라 구축은 큰 리소스가 들어가는 일입니다. 인력도 그렇고 돈도 그렇고. 서버를 구매해서 사용한다면 초반에는 트래픽이 적다고 낮은 스펙의 서버를 구매해서 쓸수는 없습니다. 왜냐하면 트래픽이 증가할때를 생각해야되고 그때 서버를 교체한다면 남는 낮은 사양의 서버의 처리도 애매하고 등등.

그래서 클라우드 서비스를 이용하기로 했습니다. 처음에는 AWS를 생각했습니다. 국내 서비스인 S사나 K사는 소문이 별로 좋지 않아서 간지나게 AWS를 쓰기로 했죠.
free tier 수준에서는 1년동안 무료로 사용이 가능해서 개발기간 동안은 free tier 수준으로 세팅해서 사용했습니다. 이제 실서버를 세팅하려는데 비용이 얼마나 나올지 전혀 예상이 안되더군요. 사용량을 넣으면 비용을 계산해주기는 하는데 항목이 너무 세세하고 복잡해서 어떻게 넣어야 할지 모르겠더라구요. 이미 서비스가 되고 있는거면 예상을 해서 넣겠는데 그런것도 아니고 지금 생각해보면 분명 월 100만원에 훨씬 못미치는 금액에서 +- 였을텐데도 예측이 안되니까. 그게 좀 힘들었습니다.

그러다가 네이버 ncloud 소식을 듣게 되었습니다. 네이버도 클라우드 서비스를 하고 있더군요. 알려지지 않아서 그렇지 내부 서비스도 여기서 서비스를 하고 많은 업체가 들어가 있다고 하더군요.
당장 담당자와 연락해서 설명을 들었습니다. 아주 심플했습니다. 서버를 몇대 쓰면 얼마가 나오겠다가 바로 계산되니까. 좋았어요. 게다가 메뉴얼도 한글이고--;;
가격 정책도 심플하지만 서비스도 심플하고 콘솔도 심플했습니다. "뭐 우리는 다른 거 필요없음. 그냥 서버만 있으면 됨" 이라고 생각하고 계약하고 바로 세팅 진행했습니다.
있어야 할건 다 있고 없을건 없는 그런 클라우드.

하지만 얼마 지나지 않아서 엄청난 일이 발생하는데...

참고
ncloud - https://eco.ncloud.com/noauth/product/main

오늘은 여기까지 쓰겠습니다. 집에 가야 해서... 다음편에 Ncloud에서 일어난 엄청난 일과 남은 주제에 대해서 말씀드리도록 할께요.

by 치킨연구소 테리야끼