2) 미국에서의 개발 적응
미국 생활 적응 뿐 아니라 개발 방식의 적응도 필요하다는 것을 절실히 느꼈습니다.
한국에서는 SW아키텍트를 하면서 요구기능이 있으면 주로 만들어 썼습니다.
메일, 로깅, 모니터링, FTP 기타 등등
외부 솔루션들이 있기는 하지만 상용 솔루션들은 비용도 많이 들고 사용하려면 다시 배우고 interface해야 하고 문제 발생 시 쉽게 조치받을 수 없기 때문에 빠른 개발을 위해서 바로 적용할 공통 모듈을 제공하는 것이 능력있는 아키텍트의 자질이였다고 생각을 했습니다.
그런데 이곳에서는 모두 밖에서(open source 또는 SaaS) 가져다 쓰는데,
AWS 메일(SES), 각종 모니터링 툴(AWS monitoring, uptime robot, newrelic), 각종 통계툴(mixpanel, adjust, amplitude) 등 거의 없는 것이 없었습니다.
새로운 요구 기능이 발생하면 외부에서 소싱할 수 있는지 먼저 확인하고 있으면 가져다 쓰는 방식이였습니다. (ruby의 Don't Repeat Yourself (DRY) 그 자체다.)
외부에 dependency가 생기고 연계 개발 시 오히려 생산성이 떨어진다고 PM이나 PL들을 설득해서 자체 모듈을 사용했던 한국에서의 나의 방식과는 사뭇 다른 접근입니다.
이런 접근이 가져 올 몇가지 장점들을 발견했습니다.
1. 외부 솔루션들이 검증되고 지속적으로 개선될 수 있다.
- 실리콘밸리의 다양한 업체들이 성공할 수 있는 기반이 아닌가 생각됩니다.
2. 개발자 의존도가 많이 줄어든다.
- 내가 만든 모듈을 사용한다면 나의 도움이 필요할 수도 있습니다.
- 6개월, 1년 계약직이 많고, 정규직이라도 5년 이상 근무하지 않는다고 하니 의존도를 낮추는 것이 중요합니다.
3. 소스가 simple해 진다.
- 복잡한 모듈이 외부에서 소싱되니 당연합니다.
하나 더, 나는 주로 업무 시스템만 했기 때문에 일반 사용자 대상 시스템에 대한 이해가 부족했다. 이건 미국, 한국의 문제가 아니라 업무시스템 / 일반사용자 시스템의 차이였습니다.
한국의 업무시스템 개발은 거의 획일적으로 unix, oracle, spring, EAI 이 정도의 stack에서 출발하는데 짦은 기간 동안 다양한 경험을 했다. 사실 엔지니어가 5명인 startup에서 다양한 경험을 하지 않을 수 없었는데, 특히나 내가 fullstack이며 server engineer이기 때문에 가능하지 않았나 싶습니다.
한국에서는 프로젝트 초반에 솔루션을 선정하고 프로토타이핑을 하면서 기술 검토를 하는 것이 나의 일반적인 업무였기 때문에 새로운 기술을 받아들이는 것이 부담되는 것이 아니라 오히려 재밌는 업무였습니다.
5명의 엔지니어팀에 1명은 인도계 미국인 CTO, 1명은 fullstack 엔지니어(android, server), 2명 안드로이드 개발자, 나 이렇게 구성되어 있었고, CTO는 관리업무만 했고 초반에 아키텍쳐를 구성했던 full-stack 엔지니어가 서버 관련 작업을 나에게 거의 넘기고 android 개발에 집중했기 때문에 모든 서버쪽 작업 및 새로운 시도는 나의 몫이 된 것이였다. 이렇게 다양한 시도를 하는 것을 한국에서는 꺼려하는 일이지만 이곳에서는 몇가지 이유에서 오히려 즐기는 분위기 였습니다.
- trendy한 startup의 기술 (Spring으로 prototyping했더니 node.js로 가자고 했습니다.)
- 엔지니어의 경력 개발 (빅데이터 관련 기술 경험을 위해서 필요성을 만들어서 도입하기도 합니다.)
- 외부 솔루션(opensource, SaaS) 엔지니어와의 자연스런 협업
지난 1년 동안 경험한 startup 기술을 정리하면 다음과 같습니다.
- 클라우드: aws
- node.js & angular.js
- Play!(Java)
- android
- Redis
- 사용량 통계(BI툴): amplitude, mixpanel
- health check: uptime robot
- 성능테스트, 모니터링: jmeter / newrelic
- 검색엔진: elasticsearch
http://doohee323.blogspot.com/search?q=elasticsearch
- 빅데이터: Apache Tajo ( with Hadoop Library)
특히 그루터의 사장님(권영길)이외 엔지니어 분들(최현식, 장정식, 최주열, 한연수 등) 수차례 방문하고 원격으로 지원한 덕에 나도 타조에 대한 얉은 경험을 할 수 있었습니다.
Apache Tajo 사용은 짧았지만 앞으로도 깊이있게 경험하고 싶은 분야가 되었고, 면접을 보면서 타조의 장점에 대해서 많이 어필하곤 했습니다.
참고로 Apache Tajo 활용을 위한 batch app을 만들었는데 그 내용은 다음과 같습니다.
사용자 정보와 사용자의 이벤트 정보를 동적으로 join하기 위해서는 타조의 도움없이 힘들었을 듯한데, 미국에서는 다양한 사용자 분석 솔루션 회사가 존재하지만 (mixpanel, adjust 등) 사용자별 정보를 추출하기 위해서 별도의 빅데이터 분석 환경을 갖춰야 한습니다.
고가의 AWS 장비를 사용해야 하기 때문에 분석을 위한 배치 작업을 할 때만 spot instance를 띄웠다가 바로 terminate하도록 구성했습니다.
현재는 c3.2xlarge spot instance를 10개를 띄워서 cohort 분석 쿼리를 돌리는데 40초 정도밖에 걸리지 않습니다.
배치 프로그램은 아래와 같이 작성했습니다.
1. spot instance 10개 기동
2. 인스턴스 생성 및 tajo worker 동작 여부 확인
3. S3에 있는 source 로그 파일을 기반으로 tajo table 생성(사용자, 이벤트)
4. 결과를 저장할 수 있는 tajo table 생성 (S3)
5. 쿼리 수행후 결과를 tajo table에 저장
6. 저장된 결과(S3)를 다운로드
7. mysql에서 테이블 생성
8. 생성된 테이블에 다운로드된 결과를 load
9. spot instance 10개 종료
위에 기술한 많은 작업을 관리하기 위해서 별도의 툴을 만들었는데 그냥 터미널에 명령어를 입력하듯이 정의해 놓으면 동일하게 실행하도록 했습니다.
(아주 급히 돌아가게만 만들었기 때문에 제대로 다시 만들 날이 왔으면 합니다. 그러려면 프로젝트에서 타조를 다시 쓸 수 있는 기회를 만들어 할 듯합니다.)
특별히 big data의 경험없이도 원하는 결과를 얻게 되었다. 물론 Tajo가 없었다면 접근하기 힘든 작업이 였습니다.
Comments
Post a Comment