굿닥에서의 1년 에 대한 회고.

굿닥에서의 1년,  그 시간에 대해서 생각을 해보다

2017년 1월을 기점으로, 저는 굿닥에 입사한지 1년 가량의 시간을 보내었고, 굿닥의 서비스팀에서의 서비스와 기술, 그리고 사람에 대한 여러가지 생각과 실험을 해왔던 시기 입니다. 공교롭게도 저의 입사시점에 팀은 자연스럽게 리빌딩이 되었고, 이에따라 모든 단계들을 차곡차곡 쌓아 나갔던 시기이기도 하지요.

굿닥에서의 1년은 저의 그동안의 경력 과정에서 가장 다양한 분야에 대한 고민을 하였던 시기입니다.

이전에는 기술, 그리고 주어진 업무를 잘 수행하는 것 만으로도 저의 가치가 충분히 있었습니다. 제가 지속적으로 개발경력을 쌓아왔던 안드로이드 플랫폼과 자바언어 기반의 기술스택을 지속해서 갈고 닦고, 그밖의 기술영역에 대한 호기심을 가지고 작게나마 도전을해오면서 그동안에는 충분히 능력을 인정받으면서 경력을 쌓아 왔습니다. 물론 그 안에서 제품을 주어진대로 만드는 것 보다는 사용자에게 더 나은 가치를 줄 수있는 것들에 대한 고민들은 서비스를 만드는 사람으로서 꾸준히 해왔다고 생각합니다.

하지만 굿닥에서 서비스를 만들어가는 개발팀을 리딩하는 관점에서의 노력은 `개발만` 잘해서는 팀을 꾸려가기 어렵다는 생각을 하였습니다. 어떻게 하면 함께 일을 잘 할 수 있을까? 또는 맹목적으로 주어진 업무를 하는 것이 아닌 업무의 목표와 공감대를 바탕으로 진행될 수 있도록 할 수 있을까? 또한 이 과정에서 주어진 비즈니스 계획을 최대한 실행 할 수 있도록 하는 것.. 이런 것들에 대한 고민이 많았고, 이 모든 것들을 결국 사람이 하기에 사람에 대한 고민도 많이 있었다고 할 수 있겠네요.

굿닥 개발팀에서는 일정주기가 끝나고 회고라는 절차를 통해 잘 했던 것, 부족했던 점을 채우는데, 이 형식에 맞추어 1년여간의 회고를 해보려고 합니다.

고민해 왔던 점.

  • 엔지니어링 문화 관점에서의 고민
    • 굿닥에 적합한 개발방법론이라는 것을 만들어갈 수 있는가?
    • 어떻게 하면 업무라는 것에만 집중할 수 있도록 할 수 있는가?
    • 단순히 주어진 업무를 수행하는 관점 보다 내가 만들어가는 일이라고 생각하고 이를 통한 동기부여를 만들어 갈 수 있는가?
    • 야근의 관점이 아닌 단위시간내에서의 생산성향상을 가져갈 수 있는 방법이 무엇이 있으며, 이를 측정할 수 있는 방법이 있는가?
    • 협업을 하는 과정이 마치 잘짜여진 축구팀 처럼 빠른 단계들을 거쳐 결과물을 만들어 낼 수 있는가?
    • 끊임없는 비즈니스 요구사항들을 어떻게 조율하여 한정된 리소스안에서 수행 할 수 있도록 하는가?
    • 해야하는 일과 하지 않아도 되는 일을 잘 구분하여 결정할 수 있는가?

 

  • 기술적 관점에서의 고민
    • 불안정한 인프라 환경에 대한 개선을 어떻게 할 수 있는가
    • 낡은 코드베이스를 어떻게 개선할 것인가?
    • 신규서비스에 대한 인프라 환경의 테크스택은 어떻게 만들어 가는 것이 좋은가?
    • git을 git답게 쓰도록 만들어 가야하지 않는가(git branch 전략의 도입)
    • 최소한의 서비스 모니터링 환경은 어떻게 구축 할것인가?
    • TDD 기반의 CI를 달성하여 품질과,반복되는 행위를 줄일 수 있도록 하자
    • 새로운 아키텍처의 도입을 통해 기술적 역량을 지속적으로 올릴 수 있는가?

이 중에서 어떤 것들은 적용/개선하였고, 어떤 것들은 시도하지 못한 것들도 많이 있습니다. 

잘 해왔던 점.

  • Jira를 비롯한 협업도구의 도입
    • 굿닥에서는 기존 Asana라는 할일관리도구를 사용하였고, 팀원이 늘어남으로 인해 점점 복잡도가 증가하게 되었습니다. Mantis 와 Jira사이에서 고민하다 Jira를 선택하게 되었고, 아직까지 아쉬움은 있지만 잘 활용하기 위해 노력하고 있습니다. 가장 의미있는 점이라고 하면 일의 추적성이 생겼다는 것과, 좀 더 의미가 있는 기록을 잘 남길 수 있는 토대가 된 점이라고 생각합니다.
  • 현대화된 개발환경 도입
    • 신규 프로젝트를 진행함에 있어 기존 인프라와 무관한 AWS Lambda기반의 환경으로 서버리스 아키텍처를 구성하였고, Android는 MVP패턴의 도입과 RxJava의 도입, Web은 Angular 기반 웹페이지를 구축하였습니다. 짧은시간안에 익숙하지 않은 개발환경에 대해 잘 적응하고, 문제해결을 해감으로 인해 기술선택지에 대한 폭이 넓어 졌다고 생각하네요
  • 우선순위를 조율하면서 다른 부서와 협업을 해왔던 점 
    • 비즈니스, 마케팅조직과 처음 협업을 할때는 요청부터 결과물까지 순탄하지 않았고, 데드라인 가까이 요청이 왔는데도 사전에 진행중인 업무로 인해 상호간의 불만족 스러운 상황들이 많이 발생하였습니다. 우선순위를 팀간의 조율하는 것 뿐만아니라, 요청사항의 근본적인 목적을 이해하고 더 올바른 결과를 나올 수 있도록 기획/개발을 진행하는 문화가 서서히 자리 잡아가고 있다고 생각합니다.
  • 서비스 안정화를 이루어 낸점
    • 당연한 것이지만, 부족한 부분이었고, 고가용성 유지나 트래픽에 대한 대응등을 2016년 동안 여러 단계에 거쳐 해왔습니다. 클라이언트(앱,웹)도 동작에 대한 오류나 여러 해상도에 따른 대응 등을 진행해서 사용자레벨에서의 안정성 확보도 잘 만들어 왔네요.
  • git flow의 부분적인 도입
    • 첫술에 배부를 순 없듯, 플랫폼별로 편차가 있지만 git을 좀 더 git답게 쓰려는 노력을 해 나가고 있습니다. 우선은 gitflow 기반의 브랜치전략으로 feature/release/hotfix 를 중심으로 구성해 나가고 있으며,  merge시점에서 pull request를 통한 코드리뷰도 해나가고 있네요.
  • 개발자간의 기술공유 문화를 만들어 낸점
    • 슬랙을 기반으로 article을 공유하는 작은 실행해서 부터 출발하여, 주단위로 세미나나 기술관련 논의를 하는 테크톡을 통해 조금씩이라도 기술영역간의 간격을 좁히고, 다른 파트에 대해서 접근을 시작하는 문화를 만들어 냈습니다.

아쉬웠던 점.

  • 직무역량의 강화(개인적인)
    • 팀의 여러가지 이슈들을 해결하는 과정에서 스스로 개발자로서의 업무는 상대적으로 감소할 수 밖에 없습니다. 이부분에 대해서는 감내해야 하는 부분이겠지만, 좀 더 밀도있게 스스로의 기술역량 강화와 팀 기술 역량강화를 위해서 시간을 쏟지 못한점이 아쉬움으로 남습니다.
  • 한사람 한사람과의 소통의 시간/피드백의 시간 부족
    •  팀원이 늘었기도 하지만, 업무의 관점에서 커뮤니케이션 하기 바빴다고 생각하고, 업무가 아닌 직무, 성과, 개인계발 측면에서의 소통을 많이 하지 못한점이 아쉽습니다.
  • 회고에 대한 Action Item을 지속적으로 follow하지 못한점
    • 1달에 한번정도 꼴로 업무단위가 끝나면 회고를 진행하였습니다. 회고 자체에 대한 만족도는 여러차례 개선 끝에 향상되고 있지만, 정작 도출된 action item을 지속적으로 챙겨가면서 유지되도록 만드는 노력은 부족했다고 생각이 드네요.

 

2017년에 노력해야하는 것들.

  • CI/CD 의 도입
    • 자동화 관점에서의 필요성은 점점 느껴지지만 도입하는 것이 쉽지는 않은 부분이라고 생각이 듭니다. 당장 해결해야 하는 여러가지 과제들에 우선순위가 밀리는 면이 있지만 2017년에는 개발에 좀 더 집중 할 수 있도록 하는 측면에서라도 빠르게 자동화배포 환경을 도입하는 것이 필요하다고 생각합니다.
  • 기술부채 청산
    • 모든 기술부채들을 줄일 수는 없겠지만, 현재 고도화 하는 영역이나 핵심 기능들에 대해서는 지속적으로 개선하려는 의지가 필요하다고 생각합니다.
  • 생산성 향상과 측정방법에 대한 고민
    • 기본적으로 스타트업은 해야하는 일이 많을 수 밖에 없습니다.(제한된 리소스) 우선순위를 잘 정해서 한다고 하더라도 모두가 공감하는 일들을 해나가려면 생산성이라는 측면에서 접근할 수 밖에 없는데, 주어진 시간안에 더 많은 결과물을 높은 품질을 유지할 수 있는 방법은 결국 개인의 역량강화와 불필요한 낭비를 줄이는 길이라고 생각합니다. 이를 잘 만들어 갈 수 있는 방안을 모색해봐야 합니다.
  • 작게 자주 바꾸는 개발문화
    • 지금도 잘 해나가고 있지만 가설을 기반으로 측정을 자주 하고 더 변경을 통해 실험하는 개발문화를 정착시켜야 합니다.
  • 기술 뿐만 아니라 서비스의 가치도 높이려는 노력
    • 설레는 서비스를 만들 수 있도록 팀 안에서의 의견이 좀 더 반영되고 더 짧은 주기안에 실행할 수 있도록 만들어 가야 할 것입니다.

 


굿닥은 현재 더 좋은 개발자분들과 함께 일하기 위해 각 직군별로 채용을 진행하고 있습니다. (백엔드,프론트) 관심 있으신 분들의 지원 기다리고 있겠습니다.

http://blog.naver.com/goodockorea/220976855845

 

굿닥의 테크스택에 관하여 – 1 – 서버 스택편

굿닥은 현재 웹과 모바일앱 두종류의 플랫폼 환경에서 서비스를 제공하고 있으며, 이와 더불어 신규로 모바일 애플리케이션을 개발하고 있습니다.

굿닥은 현재 전체적인 엔지니어링 컬처를 변화시키고 있으며, 이를위한 여러가지 작업들도 비즈니스 요구사항과 더불어 진행하고 있습니다. 이에 대해서 한번 정리하고, 스타트업에서 어떻게 속도와 비용문제를 해결하기 위한 노력을 하고있는지에 대한 내용을 공유하고자 합니다.

이미 스타트업 중에서도 굿닥에 비해 훨씬 선진화된 개발/CI환경을 구축해 계신곳이 많은 것으로 알고 있습니다만, 속도가 항상 중시되는 상황에서 적은 개발인력으로 나름대로 많은 고민을 해가고 있습니다.

이번 글에서는 굿닥서비스의 뼈대가 되고 중추가 되는 서버스택과 관련한 내용을 먼저 공유하고자 합니다.

 

ServerStack

굿닥의 서비스는 크게 두가지 환경에서 운영/개발 되고 있으며, 현재는 모두 클라우드 기반의 환경을 적용하고 있습니다.

기본적으로 고가용성과 비용을 적절히 타협하기 위한 노력들을 하고 있으며, 선진기술에 대해서도 적극적으로 도입하려는 개발조직에서 만들어 지고 있습니다.

굿닥 서비스 테크스택

굿닥 서비스 의 경우는 현재 개발조직 구성원이 기반을 다져온 환경은 아닙니다. 그래서 선택의 이유는 정확히 모르는 부분들이 있습니다. 나름대로 합리적인 서버스택을 구성해 왔으나 여러 부분에서의 이슈들이 존재하고 있고, 이를 개선하기 위한 노력을 점진적으로 수행해 나가고 있습니다.

Vultr Cloud 기반 구성

굿닥 서버 환경은 Vultr이라는 저렴한 VPS 클라우드에서 구동되고 있습니다. Nginx가 로드밸런서 역할을 담당하고, Api/Web Server역할을 수행하는 instance가 api요청에 대한 응답을 수행하도록 구성되어 있습니다. SPOF( single point of failure)을 제거하기 위해 Api서버는 이중화 되어있으나, DB의 경우는 현재 MHA를 통한 고가용성을 유지하기 위한 방안을 검토 중에 있습니다.

Vultr을 통한 시스템 운용을 함에 있어 가장 큰 단점은 장애 대응이 원활하지 않다는 점입니다. 최근 굿닥의 경우 하드웨어/네트워크 이슈로 인한 장애상황을 꽤 잦은 빈도로 맞이하면서, 정확한 장애원인파악이나 보상등이 이루어 지지 않고 기대수준만큼의 즉각적인 조치도 일어나지 않았습니다. 경우에 따라서는 콘솔환경에 대한 접속도 이루어지지 않아 아무 조치도 할 수 없는 상황도 맞이한 적이 있어 고가용성 환경으로 구축하는데에 많은 어려움이 존재합니다.

Ruby on Rails

굿닥의 기본적인 인프라는 Ruby on Rails를 기반으로 구현되어 있습니다. 최근에는 각광받는 프레임워크는 아니지만 생산성 측면에서는 매우 우수한 환경이라고 생각합니다. 현재 굿닥은 Unicorn + Rails로 구성이 되어 있고, 배포는 Capistrano를 사용하여 다중서버(4대)로 배포합니다.  만일 백엔드 개발자가 어느정도 프론트페이지의 개발을 진행해야 한다면 다른 프레임워크에 비해 매우 효율적인 환경이 될 수 있습니다. 현재 굿닥은 웹-프론트 개발파트를 따로 구성하고 있어, 그 장점을 십분 활용하고 있지는 못하고 있습니다.

 

Maria DB

DB에 대해서는 별다른 코멘트 요소가 없으며, 병원,이벤트,회원등의 메타정보를 저장하기 위한 목적으로 활용되고 있습니다. 마스터 슬레이브 구조로 구축되어 있으나 SPOF에 대한 무결성을 보장하기위한 MHA를 구성하고 별도의 환경에 이중화를 하는 형태의 개선작업을 7월 중 수행할 계획을 세우고 있습니다.

CDNetworks

이미지 등의 정적파일을 캐시하는 목적으로 CDN을 활용중에 있습니다. 차후 CDN의 이중화도 고려중에 있습니다. 이미지 및 자바스크립트 파일 등이 변경되는 경우 파일서버에서 물리파일을 가져와 CDN에서 저장/반환하도록 구성되어 있습니다.

Apache Spark+Zeppline

Spark은 메모리 기반에서 대용량데이터를 처리할 수 있는 분산처리 환경으로, 통계를 위하여 Zeppline과 연동하여 사용합니다. 현재로서는 서비스 내부의 아주 부분적인 통계지표를 만드는데 활용되고 있으나 점점 그 활용범위를 넓혀 가려고 하고 있습니다.

신규 서비스 테크스택

아직까지 개발과정에 있는 서버스택입니다만, AWS Lambda기반의 서비스 구축사례가 아직까지 국내에는 드문 듯 하여 간략하게 나마 공유를 하려 합니다. 현재 굿닥 개발팀은 AWS환경에 대한 이해도가 높은 상황은 아니지만 비교적 빠르게 도입검토를 마치고 적용을 진행중에 있습니다.

AWS Lambda/API Gateway/Cloudfront

굿닥에서는 현재 신규 서비스를 개발 중에 있으며, 이에 대한 서버스택에 대해 많은 고민을 하였습니다. 최초 서버스택은 Heroku를 통해 Python+Flask 기반의 서비스 아키텍처를 구축하려고 하였으나, Heroku가 기본적으로 미국 Region을 활용하여야 하는점으로 인해 latency가 느린 점이 차후 서비스의 영향도가 있을 듯 하여 최근 각광을 받고 있는 Serverless 환경의 대표주자격인 Lambda기반의 환경을 검토하게 되었습니다.

인프라 설치, 운용, 확장성 고려, 복잡한 배포 및 모니터링 등 많은 관리 업무를 줄이고, 민첩하게 대응하기 위한 환경을 위해 마이크로서비스를 채택하였습니다.

적용을 하면서 일반적인 API Server/RDS 아키텍처와 다른 구성을 적용하다보니, 당연한 것들이 당연하지 않게 되는 점들이 많이 있는 것 같습니다. 기본적으로는 CPU연산시간을 기준으로 과금하는 Lambda의 과금체계로 인해 연산시간을 줄이기 위한 여러가지 기법들을 수행하는 형태의 고민들이 필요하고, 아울러 서버사이드에서의 로지컬한 구현보다, 다수의 처리를 클라이언트에서 구현해야 하는(그래야 비용이 절감되는)이슈들을 많이 만나고 있고, 이를 개발속도와 성능사이에서의 trade-off를 지속적으로 고려하면서 구축해 나가고 있습니다.

AWS DynamoDB

성능과 편의성, 대규모 DB 구축에 필요한 비용 절감. 읽기와 쓰기가 매우 빈번하고 처리 속도가 빨라야 하는 환경, 작은 용량의 데이터가 매우 많은 서비스 특성을 고려하여 dynamoDB를 사용하고 있습니다.

dynamoDB는 NoSql기반의 AWS제품으로 Streams 라는 개념을 통해 DB에 데이터의 변경이 발생할 때에 필요한 event trigger를 수행하도록 구현할 수 있습니다.

AWS s3

수많은 유저의 컨텐츠를 저장하기 위해 저렴하고 견고한 AWS S3를 사용하고있습니다. 현재로서는 이미지를 중심으로 사용자정보를 저장하고 있습니다. 또한 신규 구축중인 AngularJs기반의 어드민 웹사이트의 경우도 s3를 통해 배포하여 배포자동화환경에 한발 더 다가가고 있습니다.

AWS CloudSearch

Cloud Search는 DynamoDB의 데이터를 검색하기 위한 목적으로 사용하며, 최초 ElasticSearch를 고려하다,서비스를 빠르게 구현하고, 우리의 서비스 특성상 문맥을 파악하는 검색보다 키워드방식의 검색이 더 빈번할 것으로 판단되어 도입하였습니다.

향후 고도화 단계에서는 확장성이 있는 ElasticSearch로 점진적으로 변경할 계획입니다.

Redis

Redis는 Memory 기반의 Key/Value Dictionary로 Value에 List/Map/Set 타입의 자료구조도 저장할 수 있는 장점을 가지고 있어 빠른처리가 필요한 부분에 다양한 목적으로 사용할 수 있습니다. 일반적으로는 캐쉬의 목적으로 활용하거나, 굉장히 빈번하게 발생하는 요청을 처리하기 위하여 활용합니다. 그리고 Memcached와 달리 Snapshot을 Disk에 저장할 수 있어, 데이터의 유실가능성이 낮은 장점을 가지고 있습니다.

정리하며..

이번 글에서는 백엔드 테크를 살펴보았는데, 다음 글에서는 프론트엔드 테크스택을 소개하려고 합니다.

테크 중심의 스타트업에 비해 굿닥이 굉장히 선진화된 엔지니어링 컬처를 가지고 있지는 않습니다. 아직까지 기술부채도 다수 존재하는 것도 사실이지만, 이 시스템을 통해 꾸준히 비즈니스를 성장시켜 온만큼 좀 더 안정적이며,  우수한 서버기반이 갖춰진다면 더욱 더 많은 가치들을 사용자에게 전달 해 줄수 있을 것입니다.

 

 

 

굿닥 엔지니어링 블로그를 시작하며..

굿닥의 개발팀을 리딩하고 있는 찰스 입니다.

스타트업에서는 나름 마케팅으로 핫한 굿닥입니다만, 굿닥 서비스에 대한,  그리고, 기술적인 부분에 대한 인지도는 아직까지 높지않은 것 같습니다.

여기에는 여러가지 이유가 있겠습니다만, 가장 큰 이유는 기존의 서비스를 책임지는 조직의 부재와 비즈니스 요구사항의 수용에만 발 맞춘 개발계획으로 인해 해결해야하는 근본적 문제나 기술부채를 적절히 갚아나가지 못하였던 것이라고 생각합니다.

또한, 별도의 프로세스 없이 일하던 방식을 전면 개편하여스크럼과 칸반을 혼용한 애자일 개발프로세스를 도입하여 가시성 확보 및 요구사항간의 우선순위 조율을 통해 개발자의 업무만족도와 속도라는 두마리 토끼를 잡기 위해 노력하고 있습니다.

서비스팀은 단순히 주어진 업무를 하는 것 뿐만 아니라, 서로가 서로에게 영감을 주고, 자극을 줄 수 있도록 기술을 공유하고, 새로운 것들을 찾아 나아가기 위한 여러가지 노력들을 진행하고 있으며, 그 하나의 일환으로 엔지니어링 블로그를 만들어가고자 합니다.

작게 시작하되 꾸준히 실행해서 지속적인 개선과 발전이 일어날 수 있도록 다양한 시도들을 해볼 수 있는 굿닥을 기대해주세요!