굿닥에서의 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

 

리모트 근무에대한 10가지 오해

원문 : The 10 Biggest Misconceptions About Remote Work

굿닥 서비스팀은 최근 리모트 근무 도입에 대해 진지하게 고민하고 있습니다. 사내 공유 목적으로 진행된 번역입니다만, 리모트에 관심있는 다른 분들도 함께 보실 수 있도록 공유합니다. 미국의 꽤 많은 IT기업들이 원격을 도입하고 있습니다. 아직 한국에서는 리모트 근무에 대해 많은 편견들이 존재하는것 같습니다. 이 글이 그에대한 작은 해답이 될 수 있을것 같군요.  대괄호[]는 번역자가 추가한 것입니다. 

Office on the Road by Alan Levine
Office on the Road by Alan Levine

최근 리모트 근무가 주목받고 있습니다. 믿거나 말거나, 직원들은 교통체증으로 30분을 보내는 것보다 30분간 잠을 자는것을 선택하고 있습니다. 결국 그들은 휴게실에서 냉동식품을 전자렌지에 데워 먹는것보다 부엌 테이블에서 집밥을 먹는것을 좋아하는 것으로 드러났습니다. 또한 그들은 뒷담화가 아니라 인상적인 동료와의 협업을 선택합니다. 즉, 리모트 근무는 잘 작동되고 있습니다.

2015년 갤럽 여론 조사에 따르면 미국 노동력의 37%가 원격으로 일하고 있고, 그 수는 계속 증가하고 있습니다. 그러나 여전히 리모트 근무에 대한 오해와 오명이 계속 되고 있습니다.

오해1 : 리모트 근무는 생산성 감소를 의미한다

리모트 근무는 생산성을 감소시키지 않습니다.

직장 상사와 가까운 거리에 있지 않다는 이유로 리모트 근무자들이 더 산만하다고 가정하는것은 쉽습니다. 그러나 하버드 비즈니스 리뷰의 연구는 그것이 틀렸다는것을 증명하는데, 일부 기업들이 원격 작업을 허용한 후 근로자의 생산성이 13.5% 증가했다고 합니다.

사무실 밖에서 일하는 사람은 일종의 휴게실 효과 — 커피와 함께 얘기를 나누거나 동료의 생일을 위해 케이크를 나누기위해 노동자가 책상으로부터 멀어지고 있다는 생각 —과 같은 것들과 씨름하느라 주의가 산만해지는 일이 줄어듭니다.

리모트 근무자들은 이런 인터럽트들을 피하고 그 때문에 재집중하느라 낭비되는 시간을 아낄 수 있습니다.

오해2 : 리모트 근무자들은 연락이 어렵다

리모트 근무는 커뮤니케이션에 지장을 주지 않습니다.

리모트를 한다고해서 피크닉을 떠나는것은 아닙니다. 리모트 근무자들도 비슷한 시간대에 최소 법정 근로시간인 8시간을 함께 일하고 있습니다. TINYpulse에서 실시한 리모트 근무자들의 만족도와 생산성에 관한 설문조사를 보면 리모트 작업자의 52%가 적어도 하루에 한 번 매니저와 연락을 취하고 34%는 적어도 일주일에 한 번 매니저와 대화를 한다고 합니다.

오해3 : 보안에 취약하다

리모트 근무는 보안에 타협하지 않습니다.

많은 사람들이 보안되지 않은 서버에서 컴퓨터로 회사 정보와 데이터를 전송하게되면 정보가 유출될것을 우려하고있습니다. 간단히 말해 사실이 아닙니다. 기술은 자격을 갖춘 IT 팀이 이러한 유형의 문제를 최소한으로 유지할 수 있는 정도로 발전해왔습니다.

우리는 이제 어디서나 보안 솔루션의 지레대를 활용할 수 있습니다. 클라우드 기반의 어플리케이션을 사용함으로서 보안관련 인증을 해당 소프트웨어에 아웃소싱할 수 있고 직원의 물리적 머신의 접근없이 버전 컨트롤을 모니터링 할 수 있습니다. 추가적으로 좋은 보안예시는 Two Factor Authentication을 설정하는 것과 VPN망을 사용하여 인증받지 않은 사람들로 하여금 정보를 보호하는 것입니다.

많은 사람들이 주장하는 것처럼, 의도적으로 정보를 훔치려는 사람은 그들이 어디에서 일하든 그렇게 할 것입니다. 리모트 근무를 둘러싼 많은 문제들처럼 이것은 사람의 문제지, 장소의 문제가 아닙니다.

오해 4 : 커뮤티케이션이 어렵다

어떤사람이 리모트로 근무한다고 해서 커뮤니케이션의 질이 떨어지지는 않습니다.

온라인 커뮤니케이션은 대면 대화에서 발생하는 미묘한 뉘앙스 차이를 제거하고 곧바로 의미있는 작업에 뛰어들 수 있도록 합니다. 다만 이렇게 되려면 매니저가 분명한 목표를 설정할 필요가 있고, 원격으로 일하면서 사용할 커뮤니케이션 도구를 잘 선택해야합니다.

점점 더 많은 리모트 회사들이 사회적 관계형성을 위한 디지털 도구들을 직원들에게 제공하는 추세입니다. 정해진 시간에 영상통화를 통한 “breakroom talk”, 업무와 무관한 채널(반려동물, 육아, 운동 등과 같은 채널은 언제나 인기입니다) 그리고 여러 밋업들은 모두 리모트 팀들이 커뮤니케이션을 활성화하고 결속력을 느끼게하는 방법들입니다.

오해 5 : 회의가 효과적이지 않다

커뮤니케이션의 여러 방식과 마찬가지로, 스카이프, 줌, 또는 다른 기술을 통해 회의는 실제로 더 효과적입니다.

사람들이 매일 같은 공간에서 프로젝트를 완수하려할때 마치 팀의 집중력과 능력이 무한할거라고 느끼게 됩니다. 그러나 리모트 팀원들은 특정 프로젝트에 특정 시간을 할당할때 서로 다른 시간대와 업무 부하에 대해 더 민감합니다. [역자 주 : 사람들은 서로 같은 공간에 있을 때 자신들의 능력에 대해 더 관대하게 생각하는 반면에 리모트 근무자들이 더 시간에 대해 민감하게 생각하기 때문에 회의가 더 효율적일 수 있다고 풀이됩니다.]

오해 6 : 리모트 근무자들은 외롭다

리모트로 일한다는것이 하루종일 사일로에 앉아 있는것을 의미하지는 않습니다. 물론 어떤 사람은 혼자 자신의 집에서 일하는 것을 선택할 수 있습니다. 그러나 그것이 유일한 옵션은 아니지요. 커피 숍, 도서관 및 협업 공간들이 “office-less” 노동자들 에게 매우 인기 있는 장소들입니다.

Workfrom 같은 새로운 사이트는 리모트 근무에 가장 적합한 공공 장소를 선별하기 위해 원격 근로자의 의견을 집계하고 있습니다. Workfrom은 리모트 근무자들과 한가한 레스토랑과 같은 공간을 연결시켜주는 스타트업입니다.

오해 7 : 리모트는 비용이 더 든다

어떤 사람들은 IT 문제가 실제로 원격 근로자를 고용하는데 드는 비용이 증가한다고 가정합니다. 완전히 사실이 아닙니다. 분명 근무자들이 위치한 곳마다 책상과 장비들을 제공하는 초기 비용은 있을것입니다. 그러나 전체적으로보면 리모트 근무자들이 더 싸게 먹힙니다.

더 큰 사무실 공간이 더이상 필요없기 때문에 하늘 높은 임대료, 가구, 유지 보수와 사무실 내의 커피, 음식, 복사기등의 비용을 줄이면 상당한 비용절감이 됩니다. 출퇴근하는 직원들이 적으니 탄소 발자국(carbon footprint)이 줄어드는것은 말할 것도 없습니다.

오해 8 : 기업문화가 악화된다

팀이 떨어져서 일할때 동료간의 우애가 애전과는 다를거라는 주장은 유효합니다. 그러나 훌륭한 기업으로 만드는 것은 회사뒷담화(water cooler gossip)–사실 그것이 회사문화를 악화시키는 것이지요–가 아닙니다.

커뮤니케이션 전략을 약간 비틀면 이 이슈를 완전히 개선시킬 수 있습니다.

오해 9 : 리모트 근무자는 주7일 24시간동안 일한다

매일 물리적으로 사무실에 오고 가지 않는다는 것이 결코 시계를 보지 않는다는것을 의미하지 않습니다. 리모트 근무자는 그들의 사무실과 상응하는 유사한 스케줄을 유지하고 일- 삶의 균형이 그들에게도 동일하게 제공되어야 합니다.

마찬가지로, 집에서 일하거나 사무실과 떨어져서 일한다는것이 일을 일찍 끝내고 술집에 간다거나(happy hour drink) 퇴근 후 바로 공항으로 달려가는 사람(last minute airport ride)을 의미하는것은 아닙니다. 그들에겐 끝내야 할 일이 여전히 있습니다.

오해 10 : 넷플릭스는 하루 종일 스트리밍되고 있다

리모트 근무자들도 사무실 근무자들과 마찬가지로 라디오나 스포티파이 같은 배경 소음을 틀어놓는 것을 즐깁니다. 그러나 이들 그룹은 또한 시간을 더 의미있게 조직하여 직접 대면이 부족한 부분을 보상받습니다.

리모트 근로자는 매일 실제로 바지를 입는 답니다.[바지도 입지 않고 게으르게 일할거라는 편견에 대한 말] 그리고 사무실 근무자들과 마찬가지로 그들이 좋아하는 TV쇼를 보면서는 집중력과 생산성을 유지하는것이 힘들다는것을 알고요.

자마린으로 굿닥앱 만들기 – 2 – Main화면 (1)

개발환경 구축


먼저 자마린을 빌드하기 위한 환경을 구성해 보자.

우선 Visual Studio(이하 VS)를 설치하여야 한다.  Mac OS에서도 자마린 개발이 가능하지만 이 연재글에서는 윈도우즈 환경을 기준으로 한다. 이 글을 쓰는 시점에서 VS 최신 버전은 2015이다.

https://www.visualstudio.com/ko-kr/products/visual-studio-community-vs.aspx

왼쪽에 Community 2015 버전을 다운받자.

# VS가 체고의 IDE이시다VS_site

개인과 소규모 기업에 한해서는 Community버전을 무료로 사용 가능하니 공부 목적이면 부담없이 사용하면 된다.

Visual Studio 설치는 여타 윈도우즈 프로그램 처럼 특별할 것 없이 그냥 다음버튼만 눌러주면 설치가 끝난다. 다만 윈도우즈 폰앱도 같이 빌드하고자 하면 유니버셜 Windows 앱 개발 도구를 선택해 줘야 한다. 해당 옵션을 선택하지 않으면 자마린 폼즈 프로젝트를 생성할 때마다 귀찮게 확인창이 뜨니 어지간하면 그냥 선택해서 설치하자.

VS_install

비주얼 스튜디오가 설치되면 자마린도 사이트에서 다운받아 설치하여야 한다.

https://www.xamarin.com/download

자마린 설치도 하라는 대로 다음 버튼만 눌러주면 끝. 그리고 JDK가 설치되어 있지 않다면 JDK도 설치해야 한다. 안드로이드 최신 버전으로 빌드하려면 1.8이상의 버전이 필요하다.

프로젝트 생성


설치가 완료되었으면 프로젝트를 생성해서 빌드하여 보자. 새 프로젝트 -> 설치됨 -> 템플릿 -> Visual C# -> Cross Platform -> Blank Xaml App (Xamarin.Forms.Portable)을 선택하자.

VS_create_project

프로젝트가 생성되면 맥 원격 로그인 다이얼로그가 뜨는데 iOS도 함께 빌드하고자 하면 안내에 따라 설정하면 된다. iOS 앱 디버깅/실행을 위해서는 가상머신 혹은 실제 맥이 필요하며 맥에 엑스코드가 설치되어 있어야 한다. 우리는 전직원에게 맥을 제공하긴  하지만 본인은 아이맥에 윈도우(…)를 깔아버린 관계로 더 이상 자세한 설명은 생략한다.

# VS 상단 메뉴VS_topbar

빌드하기전 VS 상단을 보면 Android Emulator Manager와 Android SDK Manager가 보일 것이다. 이클립스나 안드로이드 스튜디오에 들어가는 것과 동일한 그것이다. 안드로이드 에뮬레이터는 기본으로 선택되어 있는 x86에뮬레이터를 추천한다.

# SDK ManagerSDK_Manager

SDK는 2.1 이클레어 부터 최신버전인 7.0 N 누룽지 까지 다양하게 설치가 가능하다. 이 연재글에선 6.0 마시멜로 기준으로 앱을 빌드하기로 한다.

첫번째 빌드 Hello World.


우측 솔루션 탐색기를 보면 안드로이드(.Droid) , iOS(.iOS), Windows(.UWP) 세개의 플랫폼 프로젝트가 생성되어 있는 것을 볼 수 있다. 우선 빌드 되면 실행될 타겟을 지정하자. 처음이니까 만만한 Android를 선택해보자.

# 시작 프로젝트 설정startup_project

실행 프로젝트를 설정했으면 빌드+디버깅 단축키인 F5키를 눌러서 앱을 디버그 모드로 실행해 보자. 처음 빌드할 경우 필요한 패키지들을 다운받기 때문에 시간이 좀 소요된다. 만약 해외망이 느린 지역 케이블 인터넷 가입자라면 약간 인내심을 가지고 기다릴 필요가 있다. 빌드가 완료되면 에뮬레이터가 실행되면서 자마린 폼즈 앱이 구동된다.

# 이 모든 것이 한방에. 멋지지 않은가? 아… MS♥First_Run

텍스트 수정을 위해 레이아웃을 수정해 보도록 하자. 우측 솔루션 탐색기를 보면 플랫폼 프로젝트 위에 공통 프로젝트가 하나 더 존재하고 있는데  이곳에 공용 라이브러리나 레이아웃 파일들이 존재하게 될 것이다. 여기에 있는 MainPage.xaml 파일을 열어 Label 컨트롤의 Text속성을 여러분의 짝사랑 이름이나 하고싶은 말을 적고 다시 빌드해 보도록 하자.

하루 리모트 근무 체험기

최근 사내에서 원격근무(이하 리모트)에 대한 논의가 진행중입니다. 개발팀장과 어떻게 시작할 수 있을지에 대한 대화를 나눈적이 있었는데 막막한 점도 있고 도입되면 너무 큰 변화가 일어나지 않을까라는 생각에 실현 가능성에 대해 의심을 하고 있는 상황이었습니다. 그러다가 최근에 스포카 CTO의 “사내 리모트 시스템 성공적으로 도입하기” 강연을 들으면서 리모트에 대한 분명한 시각을 갖게되었고 천천히 혹은 부분적으로 도입할 수 있음을 알게되었습니다. 그러면서 직접 한번 체험해보고 싶다는 생각을 했습니다. 마침 집에서 가구들을 배송받아야할 일이 생겨서 리모트를 해보겠다고 요청했고, 흔쾌히 받아들여져서 진행하게 되었습니다. 리모트를 하루동안 체험하면서 느꼈던 것들을 공유해보고자 합니다.

출퇴근 시간의 절약

개인적으로는 가장 크게 느껴지는 이점이 바로 출퇴근 시간의 절약입니다. 물론 회사와 가까우신 분들에게는 큰 이점이 아닐 수 있습니다. 그러나 많은 분들이 출퇴근시간이 상당히 깁니다. “OECD 국가의 평균 통근시간은 38분(편도)인데 비하여, 한국의 경우는 58분” 으로 매우 길지요. OECD국가 중 가장 출퇴근 시간이 긴 두 번째 국가입니다. 이는 개인적으로도 많은 비용을 낭비하고 있는 것이지만, 회사와 국가 차원에서도 많은 낭비입니다.

저의 경우에는 하루 3시간씩 길에다가 시간을 버리고 있습니다. 하루 세 시간이면 일주일이면 15시간이고 한달이면 60시간입니다. 그래서인지 리모트를 하면서 가장 피부에 와닿았던 장점이었습니다. 일단 지옥철 of 지옥철인 9호선을 비롯해 세 개의 전철을 갈아 타고 1시간 반 걸려 회사에 도착하면 이미 그날 체력이 모두 소모된 느낌입니다. 그러나 리모트 근무 아침에는 평소보다 더 천천히 일어났음에도 식사도 여유있게 하고 간단한 집안 정리를 하고서 실제 출근시간보다 30분 정도 일찍 업무관련일을 할 수 있었습니다.

여유로운 하루일과?

리모트를 하면 혼자있는 시간이 대부분이니 심심하거나 루즈하거나 한적할거라고 생각했습니다. 몇 일 전 구입한 신고니움(물론 혼자서도 잘 자랍니다만)도 돌보고 우아하게 이파리도 좀 닦아주고, 그녀가 오기전 근사한 요리도 좀 준비하고 소파에 앉아 여유롭게 코딩을 하는 모습을 상상하였습니다. 그러나 상식과는 사뭇 달랐습니다. 한마디로 매우 바빴습니다. 이날 일정을 대략 시간순서로 정리해보면 다음과 같습니다.

시간 업무 장소 비고
9시 기상 씻고 가구 배송시간 확인 전화 등 아 무려 1시간 반이나 늦게 일어났는데도 출근 한시간 전이야!
9시 20분 침대 매트리스 배송 도착  
9시 30분 업무시작 일일 이슈사항 정리 및 공유
~ 11시 굿닥캐스트 이슈 작업 진행  
~11시 40분 어드민 오류사항 처리  
~12시 반 굿닥캐스트 이슈 계속 진행  
12시반 ~ 50분 청소 및 외출을 위한 준비  
~2시 식사 및 구청 개인업무 후 카페이동 이동 예상외로 많이 걸려 30분정도 지체됨.
~ 4시 반 굿닥캐스트 이슈 계속 진행 카페  
4시반 ~ 5시 가구 배송 도착, 설치 및 정리  
5시 집앞 카페에서 업무 재개 카페  
7시 반 퇴근     구청 개인 업무로 지연된 만큼 연장근무

혼자 있다고 해서 모든 채널을 닫고 있으면 안됩니다. 굿닥의 경우 슬랙을 적극적으로 사용하고 있기 때문에 버그와 같은 중요한 슬랙방들의 알림을 적극적으로 켜놓고 보면서 대화해야합니다. 때문에 오늘 할일에 대해서 꽤 구체적으로 생각하지 않으면 시간이 금방 달아납니다. 그리고 여러가지 개인적인 일도 함께 처리할 목적이 있었던 리모트 근무였기 때문에 더욱 빠릿빠릿 해야 계획했던 일들을 잘 처리할 수 있습니다.

생산성(이슈트레커/온라인채팅)

스포카 CTO의 리모트 도입 강연에서 계속 강조했던 것이 생산성입니다. 매우 생산적인 스타트업을 가정해볼게요. 모든 개인들의 과업들이 지라와 같은 이슈트래커에 기록으로 남고, 많은 협의사항등의 문서들이 위키에 기록되며, 슬랙으로 실시간 대화가 이루어집니다. 조직구조는 매우 빠른 의사결정구조로 많은 일들이 정확하고 효율적으로 이루어집니다. 이런 효율적인 기업은 리모트도입이 자연스럽게 이루어질 수 있겠지요.

이렇게 극적인 생산성이 준비되어야만 리모트도입이 가능한걸까요? 제 생각에는 생산성이 부족하더라도 생산성을 높여가면서 리모트 도입을 시작할 수 있을 것 같습니다. 리모트 근무가 생산성에 긍정적인 영향을 끼치기 때문입니다. 리모트를 함으로서 효율성이 자연스럽게 강조된다는 점입니다.

리모트 근무를 하는 날 출근신호로 슬랙에 이슈를 정리하여 올리고 일을 시작하면서 좀 더 타이트하게 스스로 일정을 관리할필요가 강하게 느껴졌습니다. 다른말로 ‘스스로 일을 잘 계획하고 실천해야’하는 압력이 자연스레 형성되는 것이지요. 일을 시작하기전 일에 대한 정의를 더 구체화 해야겠다는 생각이 들게되었습니다. 현재 진행중인 과업을 7개로 쪼개 마감일을 정했습니다. 이렇게하면 훨씬 구체적으로 오늘과 2-3일 사이의 할일에 대해 그림이 그려집니다. 그리고 이 나뉘어진 태스크들에 자세한 코멘트를 달기 시작합니다. 상태변경도 일들을 처리할때마다 잊지않고 업데이트 합니다. 오히려 이런 경험이 평소에 우리가 이슈트래킹을 제대로 활용하지 못하고 있을을 느끼게 했습니다.

그 사이에 서비스 질문방에 오류에 대한 문의들이 올라옵니다. 아무래도 바로 옆에 동료들이 없는 상황이기 때문에 내가 봐야할 오류사항을 놓칠 수 있습니다. 알림이 와도 종종 놓치는 경우가 있습니다. 모든 알림을 일일이 확인하면 집중이 흐트러질 수 있습니다. 다만 자신만의 호흡을 만들어 중간중간에 슬랙을 확인해야합니다. 이러다보니 원래 나 자신이 슬랙에 민감한 편이 아니었음을 깨닫게 됩니다. 이 지점이 리모트를 하면서 가장 힘들었던 점인것 같습니다. 아마 얼마간 적응기간을 거치게되면 해결될 수 있는 문제라는 생각을 해봅니다.

이슈트레커와 슬랙을 마치 입고있는 옷 마냥 사용하게됩니다. 위에서 말했던 ‘스스로 일을 잘 계획하고 실천’할 수 있는 매우 좋은 도구입니다.

집중과 비동기 멀티태스킹

노트북 모니터에 몰입해서 일하고 있는 나를 발견합니다. 회사가 아닌 곳에서 일에 몰입하고 있는 저를 발견한건 의외의 결과였습니다. 아까 7개로 분리되었던 티켓들에 내용들이 채워지고 7개에서 10개로 더 상세하게 분리되고 새로운 일들을 추가했습니다. 칸반/글쓰기/오류대응 등으로 메인 과업의 진행이 쉬원찮던 차였는데, 오늘은 일이 시원시원히 진행됩니다. 코딩에 자신감이 붙습니다.

사무실에서는 주변의 인터럽트가 많습니다. 개인적으로는 자리도 상당히 불편해서 그것도 인터럽트의 한 요소였습니다. 때문에 코딩에 집중하고 싶다는 생각이 많이 들곤했는데 이 점이 슬랙의 중요한 대화를 자주 놓치게 하는 것 같습니다. 이날은 슬랙 메시지를 놓치지 않으면서도 코딩에 잘 집중할 수 있었습니다. 평소보다 멀티플레이나 인터럽트의 개수가 적어져서 오히려 멀티플레이가 잘되는 느낌입니다.

사람마다 조금씩 다르겠지만, 이런 방식이 비동기 멀티태스킹이라고 생각합니다. 예컨대 누구는 궁금한게 생겼을때 담당 직원을 불러 당장 해결하지 않으면 답답해서 다음 일을 진행하지 못하는 사람들이 있습니다. 비동기 멀티태스킹은 채팅으로 물어보고 다른 일을 진행하다가 문제가 해결되면 적절한 시점에 다시 막혔던 일을 진행시키는 것입니다. 리모트를 하면 자연스럽게 그렇게 일하게되는것 같습니다. 위키/이슈트레커/채팅 와 같은 온라인 도구들이 비동기 멀티태스킹을 빠르게 할 수 있도록 도와주는 것이지요. 게다가 리모트 환경에서는 다른말로, 본인이 가장 집중하고 좋은 곳(물론 누구에게는 카페가 될 수도 있고 누구에게는 사무실이 될 수도 있습니다)에서는 이런 멀티태스킹이 더 효과적으로 발휘된다는 느낌을 받았습니다.

커뮤니케이션

사무실에서 오고가면서 나누는 대화들, 흡연과 식사 중간에도 여러가지 대화로 일이 진행되는 경우가 많기 때문에 리모트를 하면 일 진행이 더 느려질 거라고 걱정하시는 분들이 많습니다. 사실 저는 이번 리모트 체험 전부터 그런 걱정은 불필요하다고 생각하고 있었습니다. 이전 직장에서 외부업체 두 군데의 서비스를 유지보수하는 업무가 제 업무의 일부였는데, 약 6개월동안 담당자의 얼굴한번 보지 않고 일을 진행했습니다. 당시에는 Trello/Podio/이메일로 무리없이 진행했었습니다. 이메일로도 전달이 안되는 경우가 생겨서 통화로 해결한 적이 단 한번 있었습니다. 심지어는 직장을 떠날 즈음에 그 중 한곳에서 얼굴도 한 번 본적없는 제게 스카웃제의를 하기도 했습니다. 결국에는 일을 진행하는 프로세스가 잘 정립되어있으면 특히 개발자들의 일들은 대면없이 진행할 수 있는 일들이 대부분입니다.

기록

저는 원래 기록을 좋아하는 편입니다. 결혼준비를 하면서도 결혼에 들어간 돈들을 항목별로 구분하여 기록하고 있습니다. 나중에 어떤 분류의 항목들에 얼마가 들어가는지 확인해보고 싶었기 때문입니다. 그래서 이렇게 리모트 근무도 자세히 기록하고 있는 것이지요.

1차적으로는 자신의 하루 일과를 이끌어가는데 좋습니다. 일의 진행에 대해 기록하는 것 뿐 아니라 옆에 동료가 없으므로 도움이 필요한 사람들에게 무언가를 적절한 시점에 요청하고 일정을 잡기위해서는 이메일/슬랙/이슈트레커 등 다양한 도구를 적극 활용해야합니다. 이메일을 쓰고, 채팅을하고 위키에 문서를 정리하는 것은 따져보면 모두 기록인 것이지요. 자연스레 리모트를 하면서 기록의 양이 많아지게 되는걸 알 수 있었습니다.

2차적으로는 조직의 효율을 위해 중요합니다. 하지만 이 점은 쉽게 드러나지 않아 간과하기 쉽습니다. 기록의 중요성은 기록을 쌓아가고 있지 않으면 알기 힘듭니다.

얼마전 사내에서 무료로 사용하고 있던 슬랙을 유료버전 트라이얼 버전으로 바꾸어서 사용한 일이 있었습니다. 트라이얼 버전이 끝나고 다시 무료 버전으로 돌아갔는데, 이때 우리는 과거에 오고 갔던 대화를 매우 검색할 수 없다는것을 느꼈습니다. 물론 슬랙의 상술 이겠지만, 다른 한편으로는 무료 버전으로 돌아가 검색기능이 축소 되었을때 기록의 이점이 사라져 버렸다는 것을 피부로 느끼게 된 셈입니다. 생각보다 이 기능은 우리에게 꽤 큰 효율을 주고 있었습니다. 우리는 슬랙 검색기능을 사용하기위해 비용을 더 투자 하기로 결정했습니다.

결론

많은 이야기를 중구난방 한것 같지만, 사실 일을 효과적으로 잘 진행해 나가고, 업무 외 시간에 잘 쉬고 놀 수 있는것을 말하고 싶었습니다. 키워드로 말하자면 자기주도성과 생산성이 될 것입니다. 이 두가지는 한 몸이어야 합니다. 누가 억지로 시키는 생산성이 아니라 스스로 만들어가는 생산성입니다. 리모트를 경험한 이후에 계속 이런 상태를 지속하려고 노력하고 있습니다. 물론 쉽지 만은 않습니다. 효율 즉, 일을 잘하는것. 이것이 리모트 도입에 있어서 가장 중요한 요소입니다. 물론 리모트 근무 도입은 서로간의 신뢰가 부족하면 이루기 힘들거라고 생각합니다. 그러나 이것도 사실 신뢰문제도 업무 효율이 낮은 상황과 맞물려 있는 경우가 많습니다.

일도 잘하고 놀기도 잘하는 직장인이 되기 싫은 사람은 아무도 없겠지요. 개인적으로 생각하는 이상적인 직장도 그런 모습입니다. 업에 대한 성취감과 개인적인 행복을 모두 가지는것은 불가능한 걸까요? 단언할 수는 없지만 우리가 생산성을 높이려는 시도들을 꾸준히 진행하고 있다면 점진적으로 리모트를 도입해가면서 생산성을 극대화 시킬 수 있을거라 생각합니다.

모두가 행복한 일터를 만들어 나가시길!

같이 읽어보면 좋은 글들

페이스북 메신저 플랫폼 – 1 – 굿닥 병원 검색 봇 개발기

사이드 프로젝트로 페이스북 메신저 플랫폼 스터디를 진행하면서 개발한 굿닥 병원 검색 봇에 대한 개발 후기 입니다.

시작


굿닥에서는 매주 금요일 서비스팀 개발자들이 모여 기술 세미나를 진행하거나 한주간 공유 되었던 글들을 살펴보는 ‘테크톡’ 을 진행하고 있습니다.

테크톡에서 공유되었던 ‘Node.js로 5분안에 봇 만들기‘ 라는 글을 보고 정말 5분이면 만들수 있는까? 에서부터 시작 되었습니다.

Heroku 환경 구축과 페이스북 페이지 설정을 하다 보니 실제로는 30분 정도 걸려서 에코봇을 완성하였습니다.

5분봇 테스트

[에코봇]

 

다시 시작


에코봇을 완성하고 “그래 요정도 까지만 하자, 만들어봤자나..” 라는 마음으로 접어두고, 굿닥의 새로운 커뮤니티 서비스 굿닥속닥 오픈에 매진하였습니다. 

서비스 오픈후 안정화 작업까지 진행하고 나니 새로운 활력소가 필요하게 되었습니다

그래서 페이스북 메신저 플랫폼에 대해서 좀더 자세히 알아보고,  병원검색 기능을 제공하는 굿닥 병원 검색 봇 개발을 시작하였습니다.

 

Heroku 에서 AWS Lambda로


에코봇 테스트는 Heroku 환경에서 진행 했었는데  Lambda로 변경하는 작업을 먼저 시작하였습니다. 

Lambda로 변경하게 된 이유는 다음과 같습니다

  • 프론트개발자로서 Severless 환경에 구축에 대한 관심
  • 차후 확장성 및 운용, 모니터링 강화
  • 굿닥속닥에서 사용중인 환경

이미 굿닥에서 AWS 환경을 사용중이여서 서버 개발자분의 도움을 받아 Lambda 환경을 구축하였습니다.(굿닥의 커뮤니티 서비스 굿닥속닥의 서버 환경은  Lambda 기반으로 구축한 서비스 입니다. 굿닥의 테크스택에 관하여 -1- 서버스택편 참고)

참고 : Building a Serverless Facebook Messenger Chatbot

 

개발 시나리오  


  • 첫 메신저 실행시 인사 메시지 설정
  • 시작하기 버튼 추가(클릭시 콜백 메시지 전송)
  • 고정메뉴 추가(병원 이벤트 모아보기, 굿닥 캐스트, 굿닥 웹사이트)
  • 사용자가 전송한 메시지를 굿닥의 검색API 를 이용하여 병원 검색
  • 병원 검색 결과를 generic 탬플릿 구조에 맞게 사용자에게 전송
  • 검색 결과 없을시 “[검색어]의 검색 결과가 없습니다메시지 전송

 

굿닥 병원검색 봇 


현재 굿닥 병원 검색 봇은 페이스북 메신저를 통해서 사용할 수 있습니다. 

굿닥 페이스북 PC bot

[PC 페이스북 페이지]

굿닥 메신저 mobile 봇

[모바일 페이스북 메신저 앱]

고정메뉴

[고정 메뉴]

병원 검색 결과

[메시지 검색 결과]

 

후기


페이스북 메신저 봇 개발은 자발적인 스터디와 사이드 프로젝트로 시작 하였습니다.

새로운 기술에 대한 관심, 자기주도 학습, 리뷰를 통해서 성장할 수 있는 기회가 되었고, 앞으로도 더 많은 것을 해보고 싶다는 생각이 든 계기가 되었습니다.
사내 리뷰

[사내 리뷰]

현재는 병원 검색을 이용할 수 있는 단순한 기능의 챗봇 이지만 굿닥에서 진행하는 ‘병원 이벤트’, 유용한 의료 콘텐츠 ‘굿닥 캐스트’ 등 다양한  콘텐츠를 제공할 수 있는 챗봇을 만들기 위해서 노력하고 있습니다. 

 

굿닥에서는 좋은 개발자와 함께 하기를 항상 기대하고 있습니다. 개인의 성장이 회사의 성장으로 이어 질 수 있도록, 많은 노력을 해나가고 있습니다.

현재 서버 백엔드, 모바일(Android) 개발자를 채용중에 있으므로 관심있으신 분들의 많은 지원을 기다리고 있겠습니다. 

팀 건강체크 모델 – 무엇을 개선해야 하는지 시각화하기

원문 : https://labs.spotify.com/2014/09/16/squad-health-check-model/

저자 : Henrik Kniberg

[]와 강조는 역자가 추가한 것입니다. Spotify는 squad라는 팀 모델을 중심으로 조직이 구성되어있고, 이  Squad 내부에 기획, 개발, 테스트, 배포 등이 가능한 모든 기술과 자원을 갖추고 있습니다. 한 Squad는 하나의 작은 스타트업 처럼 구성되어있습니다. 조승빈 님의 “spotify의 조직 문화” 을 읽어보시길. 이 글에서 Squad는 편의상 팀으로 번역합니다.

팀(squad) 건강체크 모델이란 무엇인가

많은 회사들이 팀이 어떻게 일을 하는지 측정하고 시각화하는 실험을 합니다. 이것들을 보통 “성숙도 모델maturity model”이라고 부르고 다양한 레벨의 단계별 과정들을 포함하고 있습니다.

보통 이런 종류의 모델들이 가진 의도는 좋습니다. — 예를 들어 큰 조직의 관리자나 코치들은 개선을 집중해야할 곳을 감지하고 시스템 문제점을 찾아내려고 합니다. 또한 그들은 팀 스스로가 개선노력을 할 수 있도록 더 자기인식적일 수 있도록 도움을 주고자 합니다.

우리는 “건강 체크 모델”과 같이 조금 다른 용어를 사용하길 좋아합니다. 왜냐하면 ‘maturity’라는 말은 좀… 잘난체하는 것처럼 들립니다. 더해서 우리의 모델들은 다양한 레벨의 단계별 과정을 포함하지 않으며, 관리가 아니라 팀 그 자신을 위해서 필요합니다.

조직의 개선 과정은 매우 추측성 게임입니다.(개선을 위해 필요한 것이 무엇인지, 어떻게 그것이 개선중이라는것을 알 수 있을까요?) 명확한 시각화로 체계적인 접근방법을 통해 우리는 ‘추측’을 줄일 수 있습니다.

좋아, 그런데 모델이 정말 잘 동작할까?

답은 다양합니다. 어떨때는 모델이 정말 도움이 될 수 있지만 어떨 때는 좀 지루합니다. — 사람들은 워크샵이든 설문조사든 성실하게 임하지만 데이터를 무시하게 되면 그럴 수 있습니다.

조심해야 합니다. 어떤 회사에서 모델이 괴물처럼 되는것을 본적이 있습니다. 관리자가 팀을 심판하기 위해 “성숙도 모델”을 사용함으로서 두려움을 야기하는 억압의 도구로 변하고 서로를 구덩이로 밀어넣으며 팀은 문제를 숨김니다. 전혀 좋은 그림이 아닙니다!

아래 극닥적으로 일반화한 파이-차트가 있습니다. 우리가 지금까지 다양한 회사들을 통해 경험한 것들을 기반으로 만들었습니다.

여러분이 적용해본 모델이 잠재적으로 이득보다 손실이 더 많을지도 모릅니다. 하지만 거기엔 어쨋든 이득이 있고 우리는 손실이 많은 재앙적인 시나리오를 피할 수 있는 방법을 알고 있습니다.

Spotify에서 우리는 지난 몇 년 동안 매우 조심스럽게 실험을 해왔고 잘 운영되는(손실보다 이득이 더 많도록 하는)방법들을 찾았습니다. 우리는 팀 건강체크 모델을 몇몇 회사들에게 소개해왔고 비슷한 결과를 얻을 수 있었습니다. 그래서 우리는 이 글을 써야할 때라고 생각했지요.

팀 건강체크 모델은 누구를 위한 것인가?

팀(squad)의 건강을 체크할때는 아래 두 종류의 이해관계자가 있습니다.

  1. 팀 자신. 건강을 체크하는 기준들에 대해 토론하는 동안 팀은 무엇이 잘 작동하고 무엇이 그렇지 못하는지 스스로 인식하게됩니다. 질문[기준]을 넓게 선택하는 것이 관점의 확장에 도움이 됩니다. 아마 팀원들은 코드 품질에 대해서는 잘알겠지만 고객 가치의 관점에 대해서는 그다지 잘 모를 수 있습니다. 폭이 넓어야 균형감이 있는 관점을 제공할 수 있습니다.
  2. 팀을 돕는 사람들. 팀의 바깥에서(혹은 부분적으로만 바깥에서) 일하는 관리자와 코치는 팀이 무엇을 잘하고 무엇을 못하는지에 대해 매우 높은 수준의 요약된 결과를 얻을 수 있습니다. 그들은 여러 팀들을 관통하는 패턴을 볼 수 도 있겠지요. 만약 당신에게 12개의 팀이 있다면 그들 모두와 모든것에 대해 얘기해볼 수 없을 것입니다. 이 시각화된 결과물은 여러분이 무엇을 해야하는지 무엇에 대해 누구와 이야기해야 하는지에 대해 도움을 줄 것입니다.

문제를 해결하기 위한 첫 번째 단계는 문제를 인식하는 것입니다. 이런 시각화된 결과물은 모두로 하여금 문제를 무시할 수 없도록 만들것입니다.

Spotify 우리는 어떻게 했는가

우리는 기본적으로 아래 세 가지를 했습니다.

  1. 워크샵을 통해 팀 멤버들과 다양한 관점(품질, 재미, 가치 등)에 기반하여 현재 상황에 대해 토론하고 가늠합니다.
  2. 결과물을 시각적으로 요약합니다.
  3. 팀의 개선을 돕기 위해 데이터를 사용합니다.

우리는 여러가지 버전을 가지고 있습니다. 그 중 하나는 “팀 건강 체크 모델”이라고 부르고, 다른 것은 “fluent@agile game”과 “quarterly reflection”이라고 부르는 것이 있습니다(아마 나중에 이에 대해 글을 쓸것 같네요). 팀 건강 체크 모델은 2012년 Scaling Agile @ spotify 에서 언급했었던 분기별 설문지라 할 수 있는 “autonomous squads”의 개선된 버전이라고 할 수 있습니다.

아래는 팀 건강체크의 실제 예시입니다.

위 예시는 7개의 서로다른 팀의 상황을 보여주고 있습니다. 색상은 현재 상태(녹색 = 좋음, 노랑 = 몇 가지 문제가 있음, 빨강 = 매우 나쁨)를 나타냅니다. 화살표는 경향(개선되고 있거나 나빠지고 있음)을 나타냅니다.

위 예시를 보고 있으면 여러분은 몇 가지 흥미로운 것을 발견하실 수 있습니다.

  • 각 열을 보면, 팀간의 중요한 차이점이 보입니다. 팀4는 모든 면에서 좋게 보입니다. 팀2는 많은 문제를 안고 있는것 같지만, 대부분 개선되고 있습니다.
  • 각 행을 보면, 전체적인 패턴을 볼 수 있습니다. 모든 팀은 즐거워하고 있네요.(그리고 심지어 개선되고 있습니다.) 동기부여는 확실히 나빠보이지 않습니다. 하지만 릴리즈 프로세스는 문제가 있어보이며 코드 베이스 건강도는 전체적으로 나빠보입니다. 시간이 지나면 즐거움도 아마 감소할 것입니다.
  • 전체적인 그림을 보면, 모든 화살표가 위로 향하고 있음을 알 수 있습니다. 오직 두 개의 화살표만 아래로 향하고 있네요. 그것은 개선 프로세스가 잘 동작하고 있다는것을 보여줍니다.

물론 이것은 단지 실제의 근사치일 뿐입니다(“모든 모델은 틀렸다. 하지만 몇몇은 쓸모있다” — George Box). 그래서 액션을 취하기 전에 신중하게 체크해봐야 할 것입니다.

팀4는 정말 훌륭해 보입니다. 아니면 그들은 단지 낙관적인 사람들이거나 그들 자신의 문제를 보지 못하는 것일 수 있지요. 대부분의 팀들은 자신이 그들의 고객들에게 좋은 가치를 전달하고 있다고 여깁니다 — 그러나 그들이 무엇을 근거로 그렇게 알고 있는걸까요? 희망적인 사고에 근거한 것일까요? 아니면 실제 고객들의 피드백에 근거한 것일까요?

특이하게도 실제 팀4는 건강 체크 불과 1주일 전에 결성된 팀입니다. 이제 형태를 갖춰가는 단계이거나 “허니문”입니다. 그래서 팀2 뿐만 아니라 팀4도 도움을 많이 필요로 할 것입니다.

Easy to release”는 분명하게도 중요한 이슈입니다. 이것은 ‘지속적인 배포’와 같은 이슈에 더 집중할 수 있도록 리드하며, 우리는 긍정적인 진보를 경험한 적이 있습니다.

이것이 정직함과 팀원들의 주관적인 의견에 기반한 자기 평가 모델이라는 것에 주의하세요. 그래서 이 모델은 팀원들이 관리자와 동료들을 신뢰하는 환경에서만 제대로 기능합니다. 

다행이도 Spotify는 매우 높은 신뢰도를 갖춘 환경이며 관리자와 코치들이 매우 조심스럽게, 이것이 심판 도구가 아니라 지원도구라는 것을 보여주었습니다.

데이터를 얻기

우리는 이런 종류의 일에는 온라인 설문이 매우 좋지 않다는 것을 발견해왔습니다. 그렇게 하면 커뮤니케이션이 단절됩니다. 커뮤니케이션은 모델의 가치 중 가장 큰 부분입니다. 팀 멤버들은 토론을 하는 동안 인사이트를 얻고, 코치는 어떻게 팀을 도울 수 있을지에 대한 인사이트를 얻습니다. 데이터는 단지 그 인사이트들의 작은 부분을 제공합니다. 그것에만 의존하면 잘못된 길로 빠질 수 있습니다.

그래서 우리(보통 애자일 코치들을 말함)는 팀들과 워크샵을 열고 건강을 나타내는 여러 기준들을 가지고 얼굴을 맞대어 대화합니다. 보통 한 두 시간 정도면 충분합니다.

이것을 용이하게 하기위해 우리는 “Awesome Cards”라는 카드를 사용합니다. 각 카드는 팀 건강의 기준 중 하나입니다.

(Download the cards as PDF or PPTX thx Martin Österberg for designing the card layout)

보통 카드 한 벌은 10개의 카드로 이루어저있습니다. 아래는 완전한 한 벌의 카드 예시입니다:

카드 예시 Table

구분 : 매우 좋음 / 형편없는
쉬운 릴리즈 : 릴리즈가 단순하고, 안전하고, 쉽고, 자동화되어있다. / 릴리즈가 불안하고, 쉽지 않고, 수동으로 해야하는 부분이 많고, 오래 걸린다.
알맞은 프로세스 : 프로세스가 현재 우리에게 완벽하게 맞다. / 현재 프로세스가 완전 별로다.
기술 품질(코드 베이스 건강도) : 우리는 우리 자신의 코드가 자랑스럽다! 매우 분명하고, 읽기 쉽다. / 테스트 커버리지도 높다.우리의 코드는 똥더미이며 기술부채가 통제 불가능하다.
가치 : 우리는 고객에게 훌륭한 결과물을 전달한다. 우리는 그것을 자랑스러워하고 이해당사자들이 정말 행복해하고 있다. / 우리는 쓰레기같은 것들을 전달한다. 우리는 그것을 수치스러워하며 이해당사자들은 우리를 싫어한다.
속도 : 우리는 결과물을 정말 빠르게 만들어낸다. 기다림과 지연이 거의 없다. / 우리는 제대로 끝내본적이 없다. 우리는 지연되고 있거나 방해받고 있다. 스토리에는 계속 부가적 요소들이 붙어 지연되고 있다.
목표 : 우리는 우리가 왜 여기에 있는지 정확히 알고 있고 그것이 우리를 정말이지 흥분케 한다.우리는 우리가 왜 여기에 있는지 모르겠다. 우리의 미션은 불분명하고 영감을 주지 못한다.
즐거움 : 우리는 일하러 가는것을 좋아하고, 동료들과 함께 일하는 것이 즐겁다. / 지루ㅜㅜㅜㅜㅜㅜㅜㅜ하다.
배움 : 우리는 항상 많은 것을 배우고 있다! / 우리는 결코 뭔가를 배울 시간이 없다.
지원 : 우리의 요청에 대해 항상 지원과 도움을 받고 있다. / 우리의 요청에 대해 아무런 지원과 도움을 받지 못해 점점 더 나아가지 못하고 꽉 막혀있다.
주체성 : 우리는 스스로 우리의 운명을 통제한다! 무엇을 만들고 어떻게 만들건지 우리가 결정한다. / 우리는 단지 체스판의 말에 불과하다. 무엇을 만들고 어떻게 만들건지에 대해 아무런 영향을 끼치지 못한다.

각 질문에 대해 각 팀은 “아주 좋음”에 가까운지 혹은 “형편없는”에 가까운지 질문하고 토론합니다. 그리고 dot voting 등과 같은 방법으로 그 질문에 대해 색상(녹색, 노랑색, 붉은색)과 경향(안정정, 개선중, 더 나빠지는중)에 대한 합의를 도출합니다.

우리는 녹색/노랑색/붉은색 세 가지 레벨로 단순하게 하는 것을 좋아합니다. 이 세가지 단계의 정확한 정의는 변경될 수 있지만 대략 다음과 같습니다.

  • 녹색은 완벽을 의미하지 않습니다. 팀이 해당 항목에 대해서 행복하고 지금 당장 개선을 필요로 하는 이슈가 없는 것을 의미할 수 도 있습니다.
  • 노랑색은 해당 항목에 대해 재앙 까지는 아니지만, 중요한 문제가 있음을 의미합니다. Yellow means there are some important problems that need addressing, but it’s not a disaster.
  • 붉은색은 매우 안좋은 상황이며 개선을 필요로 함을 의미합니다.

네, 이것은 주관적인 데이터입니다. 이상적으로는 팀은 객관적인 데이터(cycle time, defect count, velocity, etc)를 선택할지도 모르지만 실제로는 거의 그렇게 하지 않습니다. 왜냐하면 객관적인 데이터라고 하더라도 팀은 그것이 문제인지 아닌지를 판단하기위해 해석해야하기 때문입니다. 결국에는 모든것은 주관적인 것으로 나아갑니다. 만약 무언가가 문제라고 느껴진다면, 그것이 문제인 것입니다.

때로 우리는 회고에 이런 방식을 포함시킵니다. 어떤 문제를 개선하기위한 액션을 도출하기 위해 위처럼 투표를 하지요.

어떤 질문이 좋을까?

이제 위 예제들을 바탕으로 여러분이 실제 사용할 질문들을 만들어야 할텐데, 다음 가이드를 참고하길 바랍니다:

  • 질문은 다양한 관점의 넓은 범위를 포괄할 수 있도록 디자인 합니다.[코드품질, 팀원간 신뢰, 서비스 가치 등등 다양한 질문들을 사용하라는 의미]
  • 이 질문은 단지 시작에 불과합니다. 팀은 자유롭게 제거하고 추가하고 변경합니다.
  • 질문 개수는 10개 정도로 제한하는 것이 좋습니다. 다른 질문을 추가하려면 몇몇은 합쳐지거나 삭제될 수 있습니다.

우리가 확실히 해야할 것은, 이 질문들이 팀을 운영하는 환경에 대한 것이어야하지 팀의 생산성(예컨대 속도)에 대한것이어서는 안된다는 것입니다. 그렇게 해야 이 과정이 심판하려는 것이 아니라 우리에게 도움과 개선을 준다는 관점을 강화시켜줍니다.

우리의 가정은(맞든 틀리든) 팀은 본질적으로 성공을 원하고, and will perform as well as it can under given circumstances.

팀 건강체크를 얼마나 자주 해야하나?

언급한대로 다양한 모델들이 존재하고 그것들은 계속 변화한다. 결국 우리는 완벽한 주기를 나타내는 숫자를 얻을 수 없다(아마 앞으로도 그럴 것이다).

처음에는 분기별로 하는 것이 좋아 보인다. 매 월 하는 것은 너무 짧다.(데이터가 그만큼 빨리 변하지 않는다.) 반년에 한 번씩 하는것은 너무 길다(그 안에 너무 많은 일들이 일어난다). 다시한번 말하지만 최적의 정해진 주기는 없다 다양하다.

결론 – 진행하기 전에 염두해야 할 것들

이 모델은 여러분의 개선노력을 가속화시키고 그것에 집중할 수 있게 도와줍니다. 하지만 부적절하게 사용하면 여러분의 문화를 완전히 망칠 수도 있습니다. 그래서 조심스럽게 진행해야 합니다.

아래는 성공가능성을 높일 수 있는 가이드입니다:

  • 모델을 소개할때 여러분의 도입 목적(동기)를 분명히 하십시요. 그 목적은 ‘심판’이 아니라 ‘개선’이 되야합니다.
  • 데이터를 수집할때는 온라인 설문이 아니라 면대면 대화를 통해 하는 것이 중요합니다. 데이터를 모으는 과정에는 흥미과 재미요소가 필요합니다.
  • 모델을 어떻게 적용할지 결정하는데에 팀을 참여시키고 그들이 직접 수정할 수 있도록 하십시요.
  • 팀원들의 결정이 데이터 일관성보다 중요합니다. 만약 팀A가 팀B와 좀 다르게 질문 세트를 선택했다 하더라도 괜찮습니다(나중에 결과를 그리기에 좀 지저분해질 지라도 말입니다).
  • 이 모델의 결과에 따라 어떠한 인센티브도 없다는 것을 확실히 해야합니다. 자신의 팀이 좋아 보이길 바라는 어떠한 동기도 없어야 한다.
  • 데이터를 시각화할 수 있는 간단한 방법을 찾으십시요. 더 분명하고 직관적으로 시각화한 데이터가 더 잘 사용될 가능성이 높습니다.
  • 팀간에 서로 비교되는 것을 조심하십시요. 만약 팀A가 초록색이고 팀B가 붉은 색일 경우, 그것이 팀A가 더 “나은”것을 위미하지 않습니다. 팀A가 더 단순한 상황에 있거나 더 낙관적인 전망을 가지고 있는것일 수도 있습니다. 혹은 팀B가 그들 자신의 문제에 대해 더 솔직한 것일 수도 있지요. 어느쪽이든 팀B은 도움이 필요한 상황일 것입니다. 관리자의 태도는 “내가 어떻게 도와줄 수 있을까요?”가 되야하지, “왜 여러분은 다른 팀보다 나쁜거지요?”가 되어서는 안될 것입니다.
  • 후속조치를 하십시요. 사람들에게 다음과 같은 질문을 해보세요. “이 모델이 정말 여러분에게 도움이 되고 있습니까?”, “만약 건강체크를 지금 중단한다면, 여러분이 그것들[건강의 기준들]을 놓치게 될까요?” , “우리가 어떻게 이 모델을 더 유용하게 만들 수 있을까요?”, 모델 스스로가 지속적으로 개선될 필요가 있습니다.

매우 인사이트가 넘치는 마틴 파울러의 기사도 꼭 보시길 바랍니다.

자 이게 전부예요. 이 글이 도움이 되길 바랍니다! 여러분도 이와 비슷한 종류의 경험이 있으신가요? 그렇다면 여러분의 경험을 댓글을 통해 공유해주십시요!

– Henrik Kniberg & Kristian Lindwall, Sep 2014.

원문 : https://labs.spotify.com/2014/09/16/squad-health-check-model/

(Download the cards & instructions as PDF or PPTX)

ECMAScript 2016 표준 릴리즈

ECMAScript의 표준 릴리즈 주기를 1년으로 결정하고 뒤에 붙는 버전(ES7)대신 발표년도(2016)를 쓰기로 한 이후 첫 정식 릴리즈 입니다.

ES2016은 ES2015에 비해서 크게 달라진 점은 없지만 자바스크립트의 표준화가 이루어 지고 있다는 점에서 의미가 있다고 생각합니다.


Array.prototype.includes

이 메소드는 원래 ES2015에서  Array.prototype.contains로 추가 될 예정이였으나 명칭의 혼동이 있어서 이번에 includes로 추가 되었습니다. 배열안에 있는 데이터 중에서 찾고자 하는 요소가 있는지 여부를 알수 있는 메소드 입니다.

Syntax

array.includes(searchElement[, fromIndex])

Examples

[1, 2, 3].includes(2);     // true

[1, 2, 3].includes(4);     // false

[1, 2, 3].includes(3, 3);  // false

[1, 2, 3].includes(3, -1); // true

[1, 2, NaN].includes(NaN); // true


Exponentiation(거듭제곱) Operator

x ** y” 형태로 사용하며 Math.pow(x, y) 의 결과와 동일합니다.

Syntax

var1 ** var2

Examples

2 ** 3 // 8

3 ** 2 // 9

3 ** 2.5 // 15.588457268119896

10 ** -1 // 0.1

NaN ** 2 // NaN

2 ** 3 ** 2 // 512

2 ** (3 ** 2) // 512

(2 ** 3) ** 2 // 64


지원

크롬은 52 버전에서 ES 2016을 지원할 예정이고, 파이어폭스는 이미 정식 배포된 43버전부터 시험판 단계인 48 버전까지 단계별로 ES 2016 기능을 구현할 예정입니다.


참고링크

ECMAScript 2016 Language Specification

자마린으로 굿닥앱 만들기 – 1 – Xamarin 소개

XAMARIN 소개


자마린은 iOS, Android, Windows Phone 개발을 위한 크로스 플랫폼 도구이며 최근에 MS가 인수하여 주목을 받고 있다.

기존 유니티, 폰갭등의 크로스 플랫폼 도구와 다른 큰 특징 중 하나는 공통화된 자마린 프레임웍이 존재하면서도 플랫폼별 네이티브 계층에 접근이 가능한 점이다. 그래서 각 플랫폼의 고유 기능을 대부분 같게 구현할 수 있다.image_9beb523f-8a48-4812-a600-818fc9630e54

아직 여타 다른 크로스 플랫폼 도구보다는 인지도가 많이 적은 상황이지만 슬랙, 다우존스, ING같이 규모 있는 회사들이 자마린으로 앱을 개발해 서비스 중이다. 게다가 MS에 인수된 뒤 라이센스가 무료로 전환되어 크로스 플랫폼 도구를 검토 중이라면 좋은 선택이 될 수 있다.

해당 연재 글의 최종 목적은 자마린으로 Windows Phone 그리고 Android 앱을 만들어 각 마켓에 올리는 것 (굿닥 앱 개발팀 의문의 실업자행). 그리고 새로운 플랫폼을 적용해보며 겪는 갖은 삽질과 분노를 공유하고자 하며 아래 독자들에게 특히 더 유용할 듯하다.

  • 같은 일을 반복하는 것이 싫으신 분
  • 최소한의 자원으로 iOS, Android, Windows Phone 앱을 동시에 개발하시고 싶으신 분
  • 저는 서버 개발자인데 갑자기 사장님이 앱을 만들래요(…)
  • MS 기반 개발이나 C#에 익숙하신 분

그럼 자마린이 어떻게 동작하는지 간략히 살펴보도록 하자.

플랫폼 구조도 #1


공통 로직 부분이 존재하고 플랫폼별로 특성화된 UI 로직을 따로 작성할 수 있다. 안드로이드는 기존 JAVA 로직과 거의 같게 C#으로 앱을 작성할 수 있다. (약간의 제약이 있는 점을 제외하면 iOS도 같다.)

플랫폼 구조도 #2 – 자마린 폼즈


또 다른 특징으로 자마린을 하며 아마도 가장 많은 삽질과 분노를 겪을 자마린 폼즈(Xamarin Forms)라는 것이 존재한다. 위 그림에선 공통 로직 부분이 플랫폼별 UI와 완전히 분리되어 있었지만 아래 그림은 조금 다르다.

container2

플랫폼별 네이티브 계층이 얇아진 것을 볼 수 있는데 자마린 폼즈가 각 UI 로직을 일부 담당하게 되어 그렇다. 자마린 폼즈를 이용하면 UI 중복 작업 제거를 기대해 볼 수 있겠다. 잘 안돼서 분노도 증가하겠지만.

자마린 폼즈는 객체지향 프로그래밍 원칙 중 DIP(의존성 역전 원칙)를 염두에 두며 작업하면 좋을 듯하니 잠시 짚고 넘어가 보자.

#자마린 폼즈를 위한 DIP 설명

간략히 자마린을 살펴보았으니 다음 글에서는 굿닥 메인 화면을 컴파일해 보도록 하자. 메인 화면이 궁금하신 분은 스토어에서 내려받아 미리 앱을 실행해보면 된다. 별 다섯 개를 주는 것도 잊지 말자.

굿닥의 테크스택에 관하여 – 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에 저장할 수 있어, 데이터의 유실가능성이 낮은 장점을 가지고 있습니다.

정리하며..

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

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

 

 

 

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

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

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

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

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

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

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