# Bitcoin Binary Option Trade Platform
## 개요
가상화폐인 비트코인을 이용한 실시간 예측 기반 금융거래 시스템(Binary Option)을 초기부터 기획, 설계, 개발하였습니다. 초기 멤버는 저를 포함하여 총 4명으로 기획자 2명, 개발자 2명으로 구성되었으며 서비스 오픈 후 개발자 1명을 추가로 영입하였습니다. 팀빌딩 후 3개월 간 개발 한 서비스는 2015년 9월에 글로벌 시장에 오픈하였고 최근까지 운영해왔습니다.

저의 주된 업무는 인프라 구축 및 관리, 웹 서비스 개발이였지만 스타트업에 특성상 그 외에도 홍보, 고객대응 등 다양한 역할을 수행하였습니다. 덕분에(?) 많은 문제점들과 직면할 수 있었고, 문제점을 해결하면서 그 어느 시기보다 많은 것을 학습하고 경험하였습니다. 모든 경험들을 이곳에 다 적을 수는 없을 듯하고 프로젝트의 기술 스택을 간단히 소개하고 내부적으로 있었던 큼지막한 프로젝트들에 대한 경험을 기술합니다.

## Back-End
증권사에서 Spring을 이용하여 사내 인트라넷을 개발했던 경험을 바탕으로 개발 언어는 `Java` 에 `Spring Boot` 프레임워크를 사용하였습니다. AWS의 IaaS인 EC2, RDS, ELB, S3를 활용하 여 도쿄 리전에 배포하였으며, 보안은 `Spring Security`를 적용하고, Spring의 모든 설정은 `Java Config` 방식으로 하였습니다. 데이터베이스는 `MySQL`를 사용하였고, ORM 기술인 `Spring Data JPA`을 사용하여 유지보수, 개발 생산성의 향상을 고려하였습니다. 빌드 시스템은 `Gradle`로 구성하였습니다. 금융 거래를 위해 실시간으로 차트가 그려져야 하는 요구 조건을 만족하기 위해 `WebSocket` 사용이 필수적이였고, 이는 `STOMP + SockJS` 규격으로 개발하였습니다. 이렇게 WebSocket으로 브라우저에 보여지는 시세 데이터는 오픈 소스 메시지 큐인 `RabbitMQ`를 사용하여 웹 서버로 수신하였습니다.

서버는 `Ubuntu 14.04 LTS` + `Nginx` + `Tomcat 9` 로 구성하였습니다. 일차적으로 `ELB` 가 요청을 수신하여 `Nginx`로 전달하면 정적 리소스의 경우 직접 서비스하고, API 데이터 요청일 경우 톰캣으로 Proxy 하도록 하였습니다. `Scale Out`을 고려하여 설계하였으나, 아직까지 `Scale Out`을 할 정도의 트래픽은 발생하지 않은 상태입니다.

## Front-End
초기 개인 프로젝트를 진행하면서 자주 사용했던 `Bootstrap3`을 사용하여 웹 페이지를 제작하였으나, 서비스 하기에는 다소 미흡한 디자인이라고 판단하였고, 외주 디자이너를 통해 디자인된 소스를 받아 개발을 진행하였습니다. 외주 디자이너로부터 받은 커다란 하나의 소스를 유지보수를 위해 기능별, 영역별로 여러 파일로 나누고, CSS는 `Sass`로 재작성하는 작업을 하였습니다. 뷰 템플릿 엔진은 `Thymeleaf3`를 사용하였고 실시간으로 업데이트 되어야 하는 기능 들은 `Ajax`와 `JQuery`를 사용하였습니다. `Sass`의 precompile, uglify, concat, 이미지 최적화등 개발 중에 반복적으로 발생하는 작업들을 자동화하기 위해 `Gulp`를 적용하였습니다. 서비스의 가장 중요한 요소인 차트는 `D3.js`를 학습하여 직접 개발하려고 시도하였으나, 기술적, 디자인적 한계를 느껴 `highcharts` 라이브러리를 채택하여 구현하였습니다. 비록 운영중인 서비스에는 사용하지 않았지만 데이터를 동적 그래프로 바인딩하는 `D3.js`에 대한 학습은 개인적으로 틈틈히 진행하고 있습니다.

## 개발 문화
소프트웨어 프로젝트를 진행하면서 산출되는 결과물은 비단 제품 하나만이 아니라 그 과정에서 발생하는 경험 또한 팀이 성장할 수 있는 영양분이 되는 중요한 자산이라고 생각합니다. 이러한 신념을 바탕으로 팀빌딩 초기부터 팀내 지식들을 축적할 수 있는 지식 베이스 시스템 도입을 적극적으로 제안하였고, 팀원들의 동의를 얻어 `Confluence`, `JIRA`, `Bitbucket`, `Jenkins`, `Slack`, `Google Apps` 와 같은 제품을 도입하였습니다. 이러한 도구들의 사용법을 팀원들에게 전파하며 개발 문화를 형성하기 위해 노력하였습니다. 이로 인해 팀원 간의 협업 효율 향상과 제품 배포 주기 단축이라는 성과를 얻을 수 있었습니다. 또한 새로운 팀원이 업무에 더 빨리 적응하는 것에도 도움이 되었습니다.

# Internal project
## 시스템 아키텍처 개선
초기 서비스의 모든 비즈니스 로직은 웹 서버에 담겨있었습니다. 다른 팀원이 비트코인 입출금, 주문과 같은 주요 비즈니스 로직을 작성하여 패키지에 넣어두면 저는 컨트롤러에서 요청에 해당 하는 인터페이스를 호출하여 요청을 처리하였습니다. 이러한 방법은 몇 가지 문제점을 가지고 있었습니다. 거래소의 특성상 입출금, 주문에 대한 정책의 변경이 빈번했는데, 이 때마다 웹 서버를 다시 배포해야했고, 인터넷에 오픈된 웹 서버에 주요 비즈니스 로직이 있는 것은 보안상으로 안전하지 못했습니다. 따라서 주요 비즈니스 로직을 따로 각각의 데몬 프로세스로 분리하는 작업을 진행하였습니다.
이 과정에서 웹 서버와 각 데몬 프로세스들이 통신하기 위한 방법을 고려하였고, 이미 시세 기능을 위해 `Publish/Subscribe` 방식으로 사용하고 있던 `RabbitMQ`를 활용하기로 결정하였습니다. 다만 주문의 경우 비동기적이 아닌 동기적으로 응답을 받아야서 처리해야 했습니다. 다행히 `RabbitMQ`는 작업 프로세스로 전달하는 메시지에 `Callback Queue`를 명시하여 동기적으로 처리하는 `Remote Procedure Call(RPC)`를 지원하였고, 이를 구현하여 기존 2티어 아키텍처를 3티어로 변경하였습니다.

해당 프로젝트를 통해 웹 서버의 재기동 없이도 주문, 입출금등의 주요 업무 로직을 수시로 변경할 수 있게 되었으며, 웹 서버와 분리되어 보안성을 향상시키는 성과를 얻었습니다. 개인적으로는 미들웨어에 대해 더 깊게 이해하고, `RabbitMQ`의 활용법을 숙지할 수 있었습니다.

## 모바일 어플리케이션 지원 
웹 서비스가 어느정도 안정화된 후 저희 팀은 고객과의 접점을 다양화할 필요성을 느꼈습니다. 바이너리 옵션 거래가 모바일에서도 가능하도록 안드로이드 앱 개발 프로젝트를 진행하였고, 저는 안드로이드에서 서버 자원을 사용할 수 있도록 API를 개발하는 역할을 맡았습니다. 사용자의 이벤트에 의해 발생하는 요청은 `@RestController`를 사용하여 `JSON`로 응답하고 이를 `jQuery`로 처리하고 있었기 때문에 크게 변경하지 않아도 되었지만, 최초 페이지 로딩시 보여져야 하는 데이터는 `Thymeleaf`의 뷰 모델에 맵핑되고 있었기 때문에 모바일을 지원하기 위해서 맵핑되고 있는 데이터를 `JSON`으로 응답하는 별도의 `@RestController`를 작성하였습니다. 모바일 지원 작업을 끝내고 보니 서버가 랜더링해서 완성된 페이지를 응답하는 `@Controller`와 `JSON`형식으로 서버 자원만 응답하는 `@RestController`의 코드가 대부분 중복되었고 이를 개선하기 위해 프론트 엔트 템플릿 엔진인 `Handlebars.js`를 사용하여 `@RestController`만 사용하도록 개선하였습니다. 

MOBILE 프로젝트를 진행하며 `Restful`한 API를 위해 URL 작명, `HTTP Method`에 맞는 작 업 수행등을 고려하여 설계하였는데, 이 과정에서 `Restful`에 많은 관심을 갖게 되었습니다. `Restful API`에는 아직까지 명확한 표준이 없어 `Open API`를 사용하게 될 때면 이 프로젝트는 API를 어떻게 설계했는지 살펴보곤 합니다. 또한 프론트 엔드 템플릿을 사용하며 경험한 편의성과 이점은 추후 `Angular.js`나 `React.js` 학습과 도입을 고려하게 된 계기가 되었습니다.

## 결제 플랫폼 도입 및 리액트 
비트코인 뿐만 아니라 USD, CNY, JPY 세 가지 통화를 입금하고, 거래할 수 있도록 하여 타켓 고객 범위를 넓히기 위해 진행한 프로젝트입니다. 통화의 입출금 요청과 입출금 내역확인, 각 통화별 잔고를 확인할 수 있는 페이지를 개발하고 유니온페이와 신용카드를 통해 통화를 입금할 수 있도록 결제 수단을 도입하였습니다. 입출금 페이지는 `Angular.js`로 먼저 개발되었다가 `React.js`로 전환하여 다시 개발하였습니다. 앵귤러의 경우 Blur Admin이라는 디자인된 프레임워크를 사용하였는데, 앵귤러에 대한 학습곡선이 제가 예상한 것보다 높았고, 앵귤러에 대한 철학을 제대로 이해하지 못한 상태에서 다른 개발자가 작성한 프레임워크를 수정하여 팀내 요구사항을 반영하는데 한계를 느꼈습니다. 따라서 일차적으로 앵귤러로 서비스 오픈 후 리액트를 사용하여 처음부터 끝까지 다시 개발하여 서비스하였습니다.
 
리액트를 학습하고 적용하는 과정에서 `Webpack`을 사용하여 모듈 방식으로 개발하였고, 자바스크립트는 `es2016`의 기능들을 적극 활용하였으며, `Redux`를 사용하여 데이터 교류와 State 관리 효율을 고려하였습니다. 모듈 방식의 개발과 리액트의 활용은 제가 프론트 엔드 개발을 하면서 느꼈던 답답한 점들을 해소해주었고, 프론트 엔드 개발에 재미를 느끼게 해주었습니다. 이러한 경험은 추후 서비스에 모든 부분들을 리액트로 조금씩 변경해나가겠다는 계획을 세우는데 영향을 주었습니다.

## AWS 인프라 재구축
서비스의 개선과 기능 추가 일정에 인프라 보안에 오랫동안 신경쓰지 못했고, AWS 인프라는 팀빌딩 초기 짧은 지식으로 설계한 인프라를 그대로 유지하고 있었습니다. 기본적인 보안을 위해 `Security Group` 설정과 같은 보안 설정은 한 상태였지만, 운영해오면서 보안상 취약한 점들을 발견해왔고 이를 리스트업 해놓았습니다. 통화 입출금 기능의 도입으로 보안의 강화가 더욱 필요해졌고 이를 위해 모두 Default로 설정해놓았던 여러가지 요소들을 재설계하였습니다.

먼저 팀원들이 사용하는 관리자 서버와 젠킨스 서버와 같은 리소스를 서울 리전으로 옮기고 운영 서버는 `Google Analytics` 분석 결과 고객의 접속이 가장 많았던 북미 리전으로 옮겼습니다. 각 리전에 `VPC`를 생성하고, `AZ-ZONE`과 `Public/Private`을 고려하여 `Subnet`을 나누고, `Routing Table`을 명시하여 허용하지 않는 패킷은 네트워크를 흐르지 않도록 설계하였습니다. `OpenVPN`을 사용하여 서울 리전과 북미 리전을 연결하였으며, 개발자들은 `VPN` 을 통해서만 서버에 접속할 수 있도록 하였습니다.

개인적으로 이 프로젝트를 진행하면서 인프라 설계를 고민할 수 있었고, AWS 제품의 활용법을 깊이있게 숙지할 수 있었습니다. 하지만 인프라에 대한 지식은 아직 많이 부족하고, 보안을 위한 고민은 끝없이 계속되어야 한다고 생각합니다.
 
# 미니 원장 시스템
기간 : 2013.01 ~ 2013.06 (6개월)
사용 기술 : ANCI C, Linux, Java, Oracle, Socket
코스콤 자본시장 IT아카데미에서 수행했던 미니 원장 프로젝트는 제게 개발자로서의 재미를 느끼게 해 준 의미있는 프로젝트입니다. 사용자 요구 정의서를 작성하며 제품을 기획, 설계하고 다섯명의 팀원이 역할을 나누어 개발한 것을 통합하며 하나의 제품을 만들어가는 과정은 이전까지 대학이나 개인적으로 진행해왔던 프로젝트와는 다른 경험을 제공했습니다. 

저는 원장 사용자 생성과 주식 매도 부분을 개발하는 역할을 맡았고 그 과정에서 `ANCI C`를 이용한 개발, 커널에 `IPC`를 사용하는 방법, `Socket`을 통한 자바 클라이언트와 서버간의 데이터 송수신등 여러 가지 기술을 사용하였습니다. 이곳에서 배우고 사용했던 `RabbitMQ`와 `Redis`는 추후 IDS Option 프로젝트에서 발생한 문제를 해결하는 것에도 큰 도움이 되었습니다.

# 증권사 사내정보시스템
기간 : 2014.05 ~ 2014.08 (3개월)
사용 기술 : Java, Spring 3.1, XML Config, Mybatis, JSP, jQuery, AJAX, MSSql
개발자의 꿈을 품고 들어간 증권사에서 저의 주된 업무는 이미 존재하는 시스템 점검하여 이슈가 발생되지 않도록 하고, 이슈 발생시 외주 업체에게 해결을 요청하여 시스템을 정상적으로 유지하는 것이였습니다. 당시 증권사 자체적으로 개발된 몇 안되는 프로젝트 중에 하나가 사내정보시스템이였는데 Model1 방식으로 개발되어 새로운 기능 추가나 이슈 해결에 상당한 시간이 소요되었습니다. 팀 내에서 사내정보시스템을 스프링 기반으로 다시 개발하는 프로젝트를 제안하였고, 제가 그 업무를 담당하게 되어 혼자서 사내정보시스템 개발을 진행하게 되었습니다.

스프링을 사용해 본 적은 없었지만, 출퇴근길에 두꺼운 `토비의 스프링 3.1`을 들고 다니며 학습과 개발을 동시에 진행하였습니다. 당시 모든게 처음이라 스프링 환경설정에만 3일 넘게 걸린 기억이 납니다. 이는 추후에 `Spring Boot`와 `Java Config` 방식을 사용하게 하는데 큰 영향을 주었습니다. 디자인은 `Bootstrap3`를 사용하였으며, 페이스북을 벤치마킹하여 제작하였고 사내 직원들에게 좋은 평가를 받았습니다. 이 프로젝트를 시발점으로 자바 기반 웹 서비스 개발자의 길을 메인으로 걷게 되었습니다.