데브옵스, 안정적이면서도 빈번한 배포 가능한 문화 만들기.

많은 스타트업들은 의도하지 않은 상태에서 개발과 운영을 한 팀이 진행하게 됩니다. 사실 정확하게 말하면 개발팀이 아닌 한두명의 개발자가 개발도 하고 운영도 하는 것입니다. 하지만 서비스가 괘도에 오르면 운영팀을 따로 조직하는 과정을 거치게 되고, 개발팀과 운영팀이 서로의 전문성에 맞게 조직화 됩니다. 우리는 여지껏 이런 과정이 최선이라고 생각해 왔습니다.  하지만 최근 들어 서비스 개선의 지속성을 중시하고 린 스타트업이 일상화 되는 과정에서 개발팀과 운영팀의 경계가 허물어져 가고 있습니다. 그리고 그 중심에 데브 옵스가 있습니다.

지속적인 개선과 데브 옵스

 

데브 옵스란 문화를 만들어 가는 것입니다.

DevOps(Development + Operations)는 소프트웨어를 배포를 자동화하고 인프라를 변경하는 과정에서 소프트웨어 개발자와 타 분야 IT 전문가들의 협업과 대화를 강조하는 문화, 움직임 또는 행동이라 할수 있습니다. 데브 옵스는더 빠른, 더 빈번한 그리고 안정적인 빌드, 테스트, 소프트웨어 릴리즈가 가능한 문화와 환경을 만들어 가는 것을 목표로 합니다.

 

개발 주기의 극적인 변화

2000년대 중반까지도 소프트웨어를 만드는데  필요한 최소 개발 주기는 적어도 1년이 넘었습니다. 수 개월간 기획을 하고 개발을 완료하면 품질 관리부서가 수 많은 테스트를 진행하고 나서야 제품이 고객에게 인도될 수 있었습니다. 이런 작업 방식은 웹 서비스까지도 이어졌죠. 개발팀이 개발을 완료하면 품질 점검이 끝나면 운영팀이 들어가서 서비스를 운영하는 것이 너무나도 당연하였습니다. 하지만 2000년대 후반부터 조금씩 변화의 조짐이 나오기 시작했습니다. 스타트업에서 부터 점점 더 짧은 개발 주기에 대한 이야기들이 나오기 시작한 것입니다. 대표적인 방식이 린 스타트업이였죠. 그리고 페이스북 같이 매일 서비스를 릴리즈 하는 기업들이 나타나게 됩니다.이렇게 개발 주기의 극적인 변화와 함께 개발과 운영의 경계가 무너지기 시작하게 되었고 데브 옵스는 이런 움직임을 이끌어 가고 있습니다.

 

데브 옵스, 더 자주 코드를 배포하다.

데브 옵스의 프랙틱스를 실행하는 회사들은 더 많은 것들을 완료해 나가고 있습니다. Puppet Labs에 따르면 데브 옵스의 회사들은 일반적으로 경쟁사들보다 30배 더 코드를 배포하며 배포가 실패하는 확률은 50% 이상 줄어들었습니다. 데브 옵스 환경안에서 가장 큰 변화는 개발자, 품질관리자, DBA, 비즈니스 분석가, 운영자 가 하나의 팀으로 구성된다는 것입니다. 이렇게 다양한 멤버들이 하나의 팀으로 구성된다는 것은 다음과 같은 이점을 제공해 줍니다.

기술 장점 :

  • 소프트웨어의 지속적인 제공이 가능해 집니다.
  • 해결해야 할 문제의 복잡도를 낮출 수 있습니다.
  • 문제를 다양한 관점에서 빠르게 해결할 수 있습니다.

비즈니스 이점 :

  • 고객에게 기능을 더 빠르게 제공합니다.
  • 보다 안정적인 운영 환경을 구축할 수 있습니다.
  • 유지와 보수에 들어가는 시간보다 더 많은 시간을 가치를 제공하는데 사용할 수 있습니다.

 

데브 옵스와 서비스의 지속적인 개선

이전에는 기획, 개발, 운영이라는 사이클 상에서 서비스가 이루어 졌습니다. 하지만 린 스타트업은 개발과 운영 과정에서 나온 데이터를 기반으로 기획을 하게 되죠. 그런 의미에서 지속적인 소프트웨어 배포는 서비스를 성공으로 이끄는 거대한 두개의 요소를 가지고 있습니다. 먼저, 아이디어에서 작동하는 소프트에어까지의 초기 프로젝트 개발 기간을 단축할 수 있습니다. 그리고 우리는 실행 속도, 판매, 가입과 같은 측정 가능한 것들을 지속적으로 개선하는 과정에서 더 많은 것들을 경험할 수 있습니다.

 

기능을 자주 추가하면 안정성이 떨어진다?

개발과 운영이 분리된 환경에서는 새로운 기능을 배포하는 것과  운영적 안정성을 유지하는 것 사이에서 갈등이 발생하는 경우가 있습니다. 개발팀은 새로운 기능을 더 많이 배포하는 것으로 인정받으며 운영팀은 안정적으로 시스템을 운영해야지만 인정받을 수 있기 때문입니다. 여기서 발생되는 다양한 이슈들은 과거 몇년간 많은 조직의 고민이였습니다.데브 옵스 환경에서는 개발과 운영이 하나의 팀이며 새로운 기능과 안정성에 대한 책임을 모두 가지게 됩니다. 더이상 운영과 코드의 경계가 존재하지 않기 때문에 코드의 공유, 지속적인 통합, 테스트 기반의 개발 기술들과 자동 배포의 조합을 통해 어플리케이션 코드, 인프라의 구성 또는 설정에서 발생되는 문제를 더 빠르게 찾아낼 수 있습니다. 또한 잦은 배포로 인해 변화의 크기가 작아지면 작아질 수록 문제의 복잡도는 점점 더 떨어지는 경향이 있습니다. 팀이 분리되어 있지 않기 때문에 트러블슈팅과 수정이 한 팀에서 이루어지며 문제를 해결하는 시간은 더 단축됩니다.

 

개발팀과 운영팀을 합치면 데브 옵스인가?

데브 옵스는 자동화된 배포와 표준화 된 생산 환경등으로 일상적인 반복 작업을 없애는 것이 핵심입니다. 이런 목표를 만들어 가는 과정에서 개발팀과 운영팀이 합쳐지는 것입니다. 운영팀이 일상적으로 책임져야 하는 단순 업무가 많다면 이런 것들을 개발팀과 함께 줄여가야 합니다. 이런 활동에 도움을 주는 다양한 오픈 소스와 좋은 서비스들이 정말 많습니다. 와탭 과 같은 서버 모니터링 서비스 또한 이런 흐름에서 만들어진 좋은 서비스입니다. 데브 옵스는 린 스타트업과 함께 현재의 개발 흐름을 대표하는 움직임 중에 하나입니다. 데브 옵스를 통해 많은 회사들이 개발과 운영의 벽을 허무는 과정에서 더 빠른 릴리즈와 더 안정적인 환경을 만들어 갈 수 있으면 합니다.

 

데브 옵스에 도움을 주는 도구들

개발과 운영에 접점을 찾는 많은 팀들이 자주 사용하는 도구들이 있습니다. 소스 저장소에서 자동 배포 툴은 기본이고 서비스 모니터링과 형상 관리 도구들까지 수많은 오픈 소스와 서비스들을 사용한다면 서비스를 지속적으로 개선하는데 도움을 받을 수 있습니다.

  1. Jenkins 정말 많은 사람들에게 사랑받는 CI(Continuous Integration)도구입니다. 저희 와탭도 Jenkins를 무척 사랑하고 있습니다. 젠킨스가 가장 빠르고 환상적이라고는 할 수 없지만 쉽게 시작할 수 있으며 플러그인과 에드온을 기반으로 하는 거대한 에코시스템을 가지고 있습니다. 커스터마이징에도 최적화된 CI 도구입니다. 와탭에서도 코드를 빌드하고 테스트를 진행하고, 스테이징과 프로덱션을 빌드하는 과정에서 많은 역할을 해 주고 있습니다.
  2. Zabbix대표적인 서버 모니터링 오픈 소스입니다. 일본에서 특히 많이 사용하는 모니터링 오픈소스입니다. 많은 기능과 다양한 커스터마이징이 가능하며 사용되는 에이젼트의 신뢰도가 매우 높습니다.
  3. Docker2015년 가장 인기있는 클라우드 오픈 소스를 꼽으라 한다면 아마도 Docker가 아닐까 싶습니다. 리눅스의 컨테이너 기술인 Docker는 Micro Service Architectures에 최적화 되어 가장 주목받는 기술 중 하나입니다.
  4. Git(GitHub)
    소스를 저장하고 공유하는 Git은 몇 년 전만 해도 SVN과 비교되어 Git을 꼭 써야 하는지에 대한 분분한 의견이 있었지만 최근들어 SVN과 비교하는 일은 거의 없어진 듯 합니다. 아직 안 쓰고 있는 곳이 있다면 Git으로 변경하시는 것도 좋습니다.
  5. whatap.io국내에서 유일하게 SaaS 기반의 서버 모니터링 서비스를 제공하는 서비스입니다. Zabbix나 Nagios가 오픈 소스로 제공되기 때문에 개발 또는 서버 설치 작업이 필요한 반면 와탭 은 가입만 하면 쉽게 서버를 모니터링 하는 핵심 기능들을 사용할 수 있는 무료 서비스 입니다.
  6. seleniumSelenium은 웹 어플리케이션을 위한 테스팅 프레임워크로 자동화 테스트를 위한 여러가지 강력한 기능을 지원합니다. 와탭 은 잦은 배포로 인한 안정화 문제를 셀레늄으로 해결하고 있습니다.

 

데브 옵스에 도움이 되는 도구들은 이 외에도 어마어마하게 많습니다. 와탭에서 사용하거나 사용할 예정인 것들 중에서 제가 알고 있는 것만 정리한 것입니다. 다음 번에는 데브 옵스에 사용될 수 있는 도구들만 정리해 드리도록 하겠습니다.

 

 

관련 글

  • https://en.wikipedia.org/wiki/DevOps
  • http://newrelic.com/devops/benefits-of-devops
  • http://devops.com/2015/08/07/9-open-source-devops-tools-love/

 

와탭의 핵심 서버 모니터링 기능은 무료로 제공됩니다.

2015 TechCrunch Beijing with WhaTap

TechCrunch Beijing?

TechCrunch Beijing은 중국 북경에서 열린 세계적 규모의 스타트업 행사입니다.

tcbj-2015-adbanner-en-600

이번 TechCrunch Beiing은 에릭 슈미츠가 기조 연설을 했고 전 세계 수많은 국가에서 온 스타트업들이 행사에 참여하였습니다. 한국은 D.Camp를 통해 선발 된 6개의 스타트업이 참가하였으며 여기에 와탭랩스도 포함 되었습니다. D.Camp에서는 매년 상해와 북경에서 열리는 테크 크런치 행사를 지원하고 있으니 관심 있는 분들은 D.Camp를 통해 내년 행사에 참여하면 좋을 것 같습니다.

D.Camp가 TechCrunch Beijing을 지원 합니다.

직접 TechCrunch에 참여 할 수도 있지만, D.Camp를 통하면 아래와 같은 지원을 받을 수 있습니다.

  • 부스 비용: 200만원
  • VIP TICKET: 1인당 70만원 (참여인원 전부 지원)
  • 항공료: 40만원
  • 호텔 숙박비: 20만원

저희 와탭은 중국 진출을 준비하는 과정에 있습니다.  그렇다면 이번 기회는 와탭에 좋은 기회일 수밖에 없죠.

앞날이 얼마나 고달플지 모르는 3인!

앞날이 얼마나 고달플지 모르고 해맑게 웃고 있는 와탭 3인방!

 

TechCrunch Beijing의 핵심은 중국어

다행히 중국에 가기 전 뉴지스탁 대표님께서 꼭 중국어가 가능한 분이 필요하다는 이야길 해 주셔서 저희는 중국어가 가능한 초특급 인재와 함께 5명이서 부스를 운영하였습니다. 그런데 중국은 정말 영어를 거의 사용하지 않더군요. 중국 진출을 염두하시는 분들은 꼭 체크하세요. 중국어 못하면 벙어리가 됩니다. 그리고 에그보다는 데이터로밍을 추천하고 싶습니다. 그리고 VPN도 꼭 준비해 놓고 가세요. 저는 무방비로 갔다가 구글과 페이스북 그리고 라인에 카톡까지 모두 막혀서 너무 힘들었습니다.

중국어가 가능한 초 특급 인재들.

중국어가 가능한 초 특급 인재들.

 

중국 핵심 어플 위챗!

행사 하루 전날 도착한 우리는 미리 행사장을 둘러볼 수 있었습니다. 중국에서는 위챗을 기본 메신저로 사용하였는데요. 처음에는 익숙하지 않았지만 몇일 써보니 매우 편하더군요. 그런데 한국에서는 별로 쓸 일이 없습니다. 그리고 중국에서 받은 명함들을 살펴보니 위챗과 연동되는 QR코드를 많이 넣어 둡니다. 실제로 이 QR Code로 위챗 연락처를 교환하면 꽤 편하기도 합니다.

한국 부스는 다른 부스와 달리 프레임이 있어서 정말 멋있습니다.

저희는 11월 1일 출발하여 11월 4일 한국을 돌아왔습니다. 하루 전날 테크크런치 베이징 행사 장소를 미리 둘러 보았습니다. 어마어마한 행사 규모에 다들 놀라워했습니다. WhaTap 잘 보이시나요? 옆 부스는 SEERS LABIU Editor 입니다.

개시 손님!

중국 현지인이신 정인님(왼쪽)의 활약이 돋보였습니다.

TechCrunch Beijing에서 놀란 것은 B2B에도 엄청 높은 관심을 보인다는 것이였습니다. 그리고 질문도 많이 하셔서 다들 정신없이 부스에서 행사를 진행하였습니다.

UCLOUD

UCLOUD

부스 진행중에 잠시 짬을 내어 중국 UCLUD를 다녀왔습니다. 꼼꼼하게 미팅 일정을 진행해주신 베스핀 글로벌에 김준태 과장님 덕분에 UCLOUD에서 많은 이야기를 나눌 수 있었습니다. 중국 UCLOUD는 4년만에 어마어마한 규모로 성장한 중국 클라우드 업체입니다.

TechCrunch Beijing은 3박 4일이라는 짧은 시간 동안 많은 중국 스타트업 관계자들을 만날 수 있고 중국 스타트업계의 분위기를 느낄 수 있는 자리였습니다.

내년에도 상해와 북경에서 테크크런치 행사가 진행된다고 하니 관심 있는 분들은 꼭 참여하세요.

 

와탭은 전 분야에 걸쳐 개발자를 모집하고 있습니다.

와탭은 전 분야에 걸쳐 개발자를 모집하고 있습니다.

집에서 누가 내 컴퓨터를 사용하고 있는지 궁금한 경우 와탭을 사용하는 꿀팁!

집에서 컴퓨터를 사용하기 있는지 알고 싶은 경우가 있습니다.

동생이 내 컴퓨터를 쓰는 것 같은데 알고 싶다던지. 아니면 아이들이 낮에 컴퓨터를 사용하는거 같은데 물어보면 안 한다고 하면 집에 있는 컴퓨터의 상황이 궁금해 집니다.

이렇게 집에 있는 컴퓨터의 상태를 알고 싶은 경우 간단하게 “https://whatap.io” 서비스를 이용하면 됩니다.

“와탭” 서비스가 없던 때에는 간단히 메신저를 이용하곤 했습니다.

예를 들면 카카오톡에 “윈도우 시작시 자동실행” 옵션을 체크해 놓는 겁니다.

카카오톡 설정하기

카카오톡 설정하기

핸드폰에 [PC 버전 자동 로그인]이 뜨면 집에 전화를 걸어 동생에게 “왜 내 컴퓨터를 켰어? 아우님” 하고 물어보면 됩니다. 이 방법은 한두번 써 먹으면 옵션 해제를 비롯한 다양한 방법으로 해결할 수 있기도 합니다.

다른 방법으로는 시중에 나와있는 아이들이 컴퓨터 쓰는 것을 방지하기 위한 솔루션들을 사용하는 것입니다. 아이들이 컴퓨터를 쓰는 시간을 제한하는 용도로 만들어진 “아이키퍼” 같은 솔류션들이 많이 나와 있습니다만 이런 솔류션들은 유료이기도 하고 컴퓨터의 오작동을 유발하기도 해서 조금 꺼려지는게 사실입니다. 그리고 밖에서 컴퓨터의 상태를 확인할 방법을 제공하지 않는다는 단점들이 있죠.

그럼 집에서 ‘와탭’을 사용하면 어떻게 될까요? 사실 ‘와탭’은 무료 서버 모니터링 서비스인데요. 집에서 사용하면 무료 PC 모니터링 서비스가 됩니다. 장점은 쉽고 안전하고 빠르게 컴퓨터의 상태를 알려준다는 것이죠.  

와탭은 IT 서비스의 장애를 알려주는 서비스입니다.

와탭은 IT 서비스의 장애를 알려주는 서비스입니다.

와탭은 IT 서비스를 모니터링 하기 위한 솔류션이긴 하지만 직관적인 인터페이스와 쉬운 설치 유명한 서비스 이기 때문에 일반인들도 쉽게 설치하고 사용 해 볼 수 있습니다. 특히 좋은 점은 모바일 서비스를 제공하기 때문에 언제 어디서나 집에 있는 컴퓨터 상태를 확인 할 수 있다는 것이기도 합니다. 예를 들면 토렌트를 걸고 나왔다면 현재 트래픽 상태를 체크해 볼 수도 있습니다.

게다가 IT 전문 개발사들이 사용하는 솔루션이다보니 에러도 적고 컴퓨터 성능에 영향도 주지 않도록 설계 되어 있습니다. 마지막으로 가장 중요한 것은 평생 무료라는 것입니다.

와탭은 데이터베이스를 모니터링 하거나, 데이터를 보존 또는 보고서 제작과 같은 회사에서 사용하는 기능들에 대해서만 유료 정책을 가져가고 있습니다.

그럼 간단하게 어떻게 사용하면 되는지 설명해 드리도록 하겠습니다.

우선 WhaTap은 가입형 서비스 이기 때문에 가입을 해야 합니다.

와탭 홈페이지 에서 가입페이지로 넘어 가거나 와탭 가입페이지 로 바로 가셔서 가입을 하시면 됩니다.

회사 정보에는 개인이라고 적으면 됩니다.

“회사 이름”에는 개인이라고 적으면 됩니다.

그리고 가입이 되면 실행파일을 다운받고 라이센스를 사용하여 설치하면 됩니다.

와탭 에이젼트 설치 화면

와탭 에이젼트 설치 화면

마지막으로 모바일 앱스토어나 플레이 스토어를 통해 “와탭” 앱을 설치하시면 됩니다. 앱을 설치 하고 나면 컴퓨터가 켜지거나 꺼질때마다 모바일 노티피케이션을 통해 집에 있는 컴퓨터의 상태를 알 수 있습니다.

저는 아이들이 컴퓨터를 얼마나 사용하는지 체크하는 용도로 WhaTap을 집 컴퓨터에 설치하였는데요. 아이들이 어떤 패턴으로 컴퓨터를 사용하는지만 체크하고 있습니다. 아직 초등학생이기 때문에 부모의 관리하에서 컴퓨터를 사용해 주었으면 하지만 요즘처럼 컴퓨터에 익숙한 어린 세대에게 그런건 부모의 욕심이겠죠.

WhaTap은 IT 서비스를 모니터링 서비스 이기 때문에 당연히 훨씬 많은 기능들이 있습니다. 만일 조금만 더 자세히 보시게 된다면 컴퓨터의 성능에서 부터 네트웍 트래픽 패턴까지 분석해 보실 수 있으며 집에 있는 컴퓨터가 어떤 실행 프로그램 때문에 문제가 발생하는지도 알아 보실 수 있습니다.

이번 글은 저처럼 아이를 기르는 부모님들께 도움이 되는 팁으로 소개를 시켜 드렸습니다. 그리고 아이가 컴퓨터를 너무 오래 사용한다면 저녁이나 주말에 아이들과 많은 대화를 해보는 건 어떨까 합니다. 혼내시지는 마시구요.

와탭 모니터링 화면

와탭 모니터링 화면

 

서버 장애 예측은 와탭으로 해결하세요.

 

 

 

스타트업에서 매일 아침마다 해야하는 Stand-up Meeting (A to Z 모두 알아보기)

직장 생활을 하면서 가장 싫어하는 일 중에 하나가 끝나지 않는 회의 입니다. 회의를 하면서 이 회의에 내가 참석해야 하는 이유도 모르겠고, 왠지 이야기는 사내 정치에 가깝게 느껴집니다. 특히 개발자들은 이 시간에 코딩 한줄 더 했으면 합니다. 그리고 스타트업에 참여하면 정말 핵심적인 일들만 할 수 있을 거라를 기대를 갖습니다. 개발자는 코딩만 열심히 하고 디자이너는 디자인에 최선을 다하는 것이 제품에 집중하는 스타트업의 모습이라고 생각하면서 말이죠. 하지만 저는 오늘 여러분께 매일 매일 아침마다 회의를 하라고 요구할 것입니다. 그것도 서서 하라고 말이죠.

회의에 대한 추억들.

 

Daily Meeting & Weekly Meeting

스타트업에 있는 당신에게 가장 중요한 활동 하나를 알려 드린다면 그건 매일 아침마다 스탠드업 미팅을 진행하라는 것입니다. 짜증나죠? 하지만 괜찮습니다. 제가 말씀 드리는 스탠드업 회의는 팀에 윤활제 같은 역할을 하며 오래 걸리지도 않습니다.

일주일에 한번 미팅하는 것도 힘들죠? 그런데 매일 매일 회의를 하면 더 힘들거라 생각되나요? 팀이 팀이 주단위로 모인다면, 공지사항, 지난 주의 업무, 그리고 다음주의 계획에 대해 토론 하는라 최소한 한 시간은 걸릴 겁니다. 하지만 아침마다 하는 스탠드업 미팅은 아주 다릅니다. 스탠드업 미팅은 일정에 심각한 악영향을 주지 않고도 상호작용이나 의사소통을 장려하는 간단한 팀 회의입니다.

스탠드업 미팅 전용 룸이 있는 경우!

 

왜 매일 하는가? (왜 Daily Meeting 인가요?)

놀랍게도 스타트업의 가장 큰 실패는 의사 소통의 부재에서 나오는 경우가 많습니다. 지금도 누군가는 일주일째 다른 직원들과 대화도 없이 직면한 문제들을 해결하고 있는 분들이 있을 겁니다. 그리고 어쩌면 지금 해결하는 문제는 이미 문제가 아닐수도 있습니다. 이런 의사소통의 실패를 해결하는 가장 쉬운 방법은 팀과 보다 자주 이야기를 나누는 거라 하겠습니다. 이렇게 하면 어디에 문제가 있는지 이해하는 데 도움이 되고, 일단 문제를 발견하면 고칠 기회도 얻게 됩니다.

사람들은 대부분 팀의 목표에 맞춰 일하려 합니다. 불행히도 사람들은 방향을 곡해하거나 놓치기도 하는데, 그래서 여러분은 이를 조정하기 위해 조치를 취해야 합니다. 그러기 우해 팀 전체와 좀 더 자주만나서 모든 사람이 자기가 무슨 일을 하고 있는지 공유하기 위해 매일 짧은 미팅을 진행하는 것이 좋습니다. 진행 방향을 수시로 바로 잡는 게 목표입니다. 여러분이 차를 몰아 길을 따라 내려가고 싶을 때, 한 방향을 정해놓고 그쪽에만 매달리지 않을 겁니다. 가고 싶은 방향으로 차를 움직여놓고, 바퀴를 왼쪽, 오른쪽으로 틀면서 조금씩 방향을 조정해 갑니다. 방향 조정을 해주지 않고 버티다 보면 결국 도로를 벗어나 차를 망가뜨리게 됩니다. 소프트웨어 프로젝트도 마찬가지라, 조금씩 조정해 주지 않으면 부서져버립니다.

 

왜 서서하는가? (왜 Stand-up Meeting 인가요?)

꼭 서서해야하는 것은 아닙니다. 단지 우리가 회의를 싫어하는 가장 큰 이유인 긴 회의 시간을 줄이기 위한 방편일 뿐입니다. 아침부터 장황한 이야기를 듣고 나서 일을 시작하는 것을 좋아하는 분들은 없을 겁니다.  서서 미팅을 하게 된다면 우리는 심리적으로 또는 육체적으로 길게 회의를 진행하기 힘들어 집니다. 하지만 그럼에도 회의를 길게 만드는 놀라운 재주를 타고난 분들이 있습니다. 이런 분들을 막기 위해 우리는 몇가지 원칙을 가지고 Daily Stand-up Meeting을 진행합니다.

Daily Stand-up Meeting의 원칙은 각자가 짧게 다음과 같은 세가지 내용을 공유한다는 것입니다.

  • 어제 한 일
  • 오늘 할 일
  • 장애가 되고 있는 일

서 있는건 앉아있는 것보다 힘들어요.

왜 아침마다 하는가? (왜 Daily Morning Stand-up Meeting 인가요?)

스타트업마다 상황이 다를 수 있습니다. 인정합니다. 재택을 하는 경우도 있을 것이고, 시차가 존재할 수도 있습니다. 하지만 가능하면 아침에 진행하시기 바랍니다. 아침에 진행하게 되면 어제 작업한 내용을 정리 할 수 있으며 하루를 시작하기 전에 해야 할 일들을 이야기 할 수 있습니다. 장애가 되는 일들도 아침에 이야기 하고 당일에 해소하기 위한 노력을 해볼 수도 있습니다. 하지만 오후에 Daily Meeting 을 진행한다면 이런 이점들을 살릴 수 없을 것입니다. 그렇기 때문에 부득이한 경우가 아니면 아침에 미팅을 진행하시기 바랍니다. 일반적으로는 출근시간에 맞쳐서 진행하시면 됩니다.

아침에 커피와 함께 하는 미팅이 좋아요!

 

몇 명이서 하는게 좋은가?

두가지 질문이 있을 수 있습니다. “우리는 겨우 3명인데 해야하나?” 또는 “우리는 10명이 넘는데 할 수 있나?” 입니다.

우선 인원이 적은 경우입니다. 저는 스타트업의 인원이 3명 이하라면 권하고 싶지 않습니다. 3명이하인 경우엔 소통의 부재로 발생되는 문제 자체가 없어야 합니다. 일반적으로 Co-Founder끼리만 몰려서 있는 규모에서는 회사의 방향에 대한 모든 것들이 공유될 확률이 높기 때문에 Daily Meeting이 없더라도 문제가 되지 않습니다. 다만 성향의 문제가 나오는 경우는 있습니다. 예를 들면 한명 있는 개발자가 워낙 말이 없고 수동적인 경우가 있습니다. 이런 경우에는 Daily Morning Stand-up Meeting(이제 Daily Meeting 으로 부르겠습니다)을 진행하는 것이 좋습니다.

10명이 넘는 경우는 어떻게 해야 할까요? 경험적으로는  12명까지 가능하며 6명에서 8명을 가장 좋은 구성원으로 생각합니다. 종종  30명까지도  Daily Meeting 을 진행하는 경우를 있습니다만 오래 지속되는 것은 권장하지 않습니다. 참여 인원에 대한 기준은 시간으로 정하는 것이 좋습니다. 사람들이 부담없이 미팅에 집중할 수 있는 15분 이내에 Daily Meeting을 끝낼 수 있다면 가능한 인원이라 보시면 됩니다.

Processed with VSCOcam with f2 preset

 

어떤 내용을 어떻게 공유해야 하는가?

Daily Meeting의 가장 중요한 점은 보고가 아니라 공유라는 것입니다. 자신에게 생긴 어려움을 결코 숨겨서는 안됩니다. 스타트업에 발생하는 문제들은 함께 공유하고 같이 해결해야 합니다. 그러기 위해 개발팀 전원의 활동 현황을 공유하고 전날 수행한 작업 내용과 오늘 수행할 작업을 확인합니다. 일어선 채로 매일 정해진 시간에 정해진 장소에서 15분의 짧은 시간 동안 미팅이 진행됩니다. 팀원 한 사림씩 ‘어제 한일’, ‘오늘 할 일’, ‘장애가 되고 있는 것’을 순서대로 말합니다. 개발팀 내에서 해결할 수 없는 장애를 제거하는 것은 우리 모두의 일입니다.

Daily Meeting에서는 다음의 3가지를 중요하게 생각하고 공유합니다. (만일 칸반을 사용한다면 어제 한 일 및 오늘 할 일이 칸반으로 이야기 되기 때문에 장애에 대한 이야기만 하기도 합니다. )

 

  • 어제 한 일
  • 오늘 할 일
  • 장애가 되고 있는 일

Daily Meeting 은 팀 멤버들이 생각하는 바를 결합하는 기법입니다. 매일 아침 팀 멤버들의 생각과 행동을 통합하여 최신 상태로 유지하는 것입니다. 고정된 장소와, 시각, 짧은 시간동안 수행하는 것을 습관화하는 것이 포인트로, 누구든지 자유롭게 “미팅하시죠?”라고 말하면 충분합니다. 앞에서 언급한 세가지 이외에 예를 들어 ‘오늘은 아이들을 유치원에 데리러 가야 하므로 5시에 퇴근합니다.’라는 사항도 여기에서 공유합니다. 이처럼 팀원 모두가 자신의 일에 투명성을 가지고 참여하는 것이 중요합니다.

이 Daily Meeting 은 문서로 하는 진척 보고를 대신하는 것이 아닙니다. 비록 짧은 시간이지만 일일 스크럼 도중에 던진 질문에 누군가 곧바로 해결책을 알려주는 경우도 있습니다. 그것만으로도 프로젝트 분위기를 원활하게 만들 수 있으며, 협업함으로써 누군가 곤란한 상화어에서 도움을 받을 수도 있습니다. 모든 사람이 외톨이로 각자 주어진 일을 해내는 것이 아니라, 같은 목표를 향해 무언가를 함께 만든다는 일체감을 매일 만드는 것입니다. Daily Meeting은 개발팀을 위한 것이지 상사를 위한 진천 보고 시긴이 아닙니다.

Daily Meeting은 스크럼 또는 칸반의 기본요소.

 

장애가 되고 있는 일이란? (장애 요소 식별하기)

어제 한 일과 오늘 할 일은 쉽게 이해 되지만 “장애가 되고 있는 일이 뭘까?” 궁금할 수 있습니다. 만약 팀원이 업무를 효과적으로 수행하는 데 장애가 되는 것을 발견했다면, 누군가는 (스크럼에서는 스크럼 마스터이지만 스크럼을 사용하지 않는 스타트업에서는 팀장 또는 대표가 그 역할을 맡아야 한다.)그 장애 요소를 기록하고 제거할 책임이 있습니다. 장애 요소는 벽에 걸린 화이트보드 같은 곳에 적어 두어야 하며 만약 팀장 또는 스타트업의 대표가 그 장애 요소를 제대로 이해하지 못했다면, 스크럼 회의가 끝난 후에 해당 장애 요소를 보고하 사람을 만나서 좀더 자세히 듣도록 합니다. 일반적인 장애 요소들은 다음과 같습니다.

  • 워크스테이션, 네트워크나 서버들 중 하나 혹은 전체의 작동이 중지되었다.
  • 네트워크나 서버가 느리다.
  • 인사 부서의 교육 훈련에 참석해야 한다.
  • 경영진과의 현황 회의에 참석해야 한다.
  • 경영진이 스프린트 백로그에 없는 다른 일을 시켰다.
  • 이번 스프린트에 해당 팀원이 하기로 한 것과는 다른 일을 요구 받았다.
  • 어떻게 처리해야 할지 모르겠다.
  • 설계가 확실하게 결정되지 않았다.
  • 기술을 어떻게 사용해야 할지 자신이 없다.

좋은 리더의 최우선 업무는 장애물을 제거하는 것입니다. 만약 팀원이 리더에게 이것만 해결된다면 자신의 생산성이 올라갈 것이라고 말한다면 리더는 그것을 해야만 합니다. 이렇게 스타트업의 리더는 일일 스크럼을 통해서 팀의 생산성을 향상시키기 위해서 자신이 무엇을 해야 하는 지에 대한 정보를 직접적으로 얻을 수 있습니다.

만약 장애물이 즉시 해결되지 않으면, 다음날 팀은 여전히 장애를 겪고 있다고 보고 할 것입니다. 그러나 장애 요소가 제거되지 않았는데도 팀원들이 장에 요소에 대해서 보고하지 않는 것은 좋지 않은 조짐입니다. 이것은 리더가 자신들의 문제를 해결할 수 있고 실제로 그럴 것이라는 확신을 잃어버렸다는 것을 의미합니다. 어떠한 이유로도 장애 요소를 제거하지 못했다면 리더는 다음 일일 스크럼에서 이 사실을 보고 해야만 합니다. 이런 장애를 해결하는 과정을 통해 조직의 신뢰를 향상 시킬 수도 있습니다.

장애가 존재한다는 것조차 모르는 경우가 더 많습니다.

 

후속회의 개최하기(After Meeting / After Party)

Daily Meeting에서 각각 세가지 질문(어제 한일 / 오늘할일 / 장애가 되는 일)에 대한 대답을 들어 확인된 현황과는 다른 무엇이 필요하다면, 후속회의를 개최할 필요가 있을 것입니다. 어떤 팀원이 자신의 현황을 보고한 이후에 다른 팀원이 불쑥 끼어들 수 있습니다. “저는 방금 하신 말씀에 대해 다른 의견을 가지고 있습니다. ~~~”, 이 대화는 설계나 요구 사항에 대한 다른 대안이나 해석이 될 수도 있습니다. 이와 같은 정보 공유 문제는 범위가 막연하여 설계에 대한 토론으로 이어지기도 합니다. 어떤 팀원이 마침 이전에 비숫한 일을 해봤거나 그 일을 처리하는 더 쉬운 방법을 알 수도 있을 것입니다. 그러나 이런 경우, 다른 팀원이 또 다른 접근법을 제안하게 되고, 그 결과 설계에 대한 토론으로 바뀌어 버리고 의도치 않게 Daily Meeting은 점점 길어지기 시작합니다.

이런 문제를 해결하기 위해 After Meeting을 만들 수 있습니다. 다른 의견 또는 후속 조치에 대한 깊은 이야기를 하고 싶은 경우에는 다음과 같이 진행합니다. “저는 일일 스크럼 회의 후에 이 사안에 대해서 좀더 논의하고 싶습니다. 관심이 있으신 분은 누구든지 가지 말고 남아주세요.” 한명 이상의 팀원이 해당 주제에 대해서 깊은 이야기를 나누고 싶어할 수도 있습니다. 작업에 관련된 회의는 어떤 결정에 이르거나 설계 또는 표준에 대한 토론으로 발전되어야 합니다.

After Meeting 의 경우, 어느 경우이든 간에 대화에는 아무런 제한이 없습니다. 더 많은 시간이 소요될 수도 있지만 다른 팀원들이 합류할 수도 있기에 이러한 토론은 모두 가치 있을 뿐만 아니라 꼭 필요한 요소입니다. 단지 일일 스크럼이 끝난 다음에 벌어지기만 하면 상관없습니다. 일일 스크럼과 실제 작업에 관련된 모든 회의는 명확하게 구분하도록 해야 합니다. 그렇게 하지 않으면, 현황 파악 회의와 실제 업무 회의 사이의 구분이 희미해지면서 딱 정해진 짧은 시간만 소요되는 일일 스크럼의 장점을 상실하게 됩니다.

After Meeting은 편하게 진행하시면 됩니다.

 

 

관련 자료

 

와탭랩스 개발자 모집 중

  • 와탭랩스에서 자바 개발자 모집 중입니다. 지금 참여하시면 모니터링 분야 최고의 개발자들과 함께 톰캣 모니터링 서비스 개발을 경험해 보실 수 있습니다. 관심 있으신 분은 recruit@whatap.io로 메일 주세요.
와탭 랩스에서는 서버 개발자를 모집중에 있습니다.

와탭 랩스에서는 자바 개발자를 모집 중에 있습니다.

스타트업이 산으로 가는 이유 – 확증 편향

 

확증편향 (確證偏向, Confirmation bias)은 원래 가지고 있는 생각이나 신념을 확인하려는 경향성을 의미 합니다. 이 확증편향은 자신의 생각이나 신념과 일치하지 않는 정보를 무시하는 경향을 가집니다.

우리는 대개 자신이 옳다고 생각하며 움직이는 경향이 있으며, 중립적이거나 애매 모호한 증거를 의심하기 보다는 자신의 생각을 지지하는 증거로 해석합니다. 서비스가 산으로 가는 원인의 상당수가 여기에 있습니다.

나는 보는 것을 믿지 않는다. 믿는 것을 볼 뿐이다.

나는 보는 것을 믿지 않는다. 믿는 것을 볼 뿐이다.

 

 

스타트업에서 초기 멤버들은 자신들의 아이디어에 대한 강한 믿음 때문에 사업에 안 좋은 시스널을 무시하는 경향을 보이게 됩니다.  이것은 우리의 뇌가 자연적으로 작동하는 방식입니다. 불행하게도 이 확증편향은 워낙 교묘해서 인지 부조화 같은 문제보다도 잘 드러나지 않습니다. 그 결과 제품의 핵심 가정을 반박하는 피드백을 주는 사용자가 있는데도, 제품을 잘 이해하지 못했거나 제품의 가치를 모르는 멍청한 사용자로 일축해 버리곤 합니다.

확증편향을 줄여주는 방법들

  • 나는 이 분야의 전문가일지라도 언제나 틀릴 수 있다는 생각을 가진다.
  • 나의 생각을 증명할 수 있는 가정과 가정을 증명할 데이터들을 문서로 정리한다. 글은 생각보다 명확하다.
  • 멤버들과 치열하게 토의하는 문화를 만들어 나간다. YES를 외치는 멤버들만 있다면 더욱 쉽게 확증편향에 빠진다.
선택

선택

확증편향을 줄이기 위한 가장 좋은 방안은 철학자 칼 포퍼(Karl Popper)의 말처럼 ‘우리가 옳다고 하는 만큼 우리는 언제나 틀릴 수 있다. 언제 틀릴지는 알지 못한다.’라는 생각을 가지는 것입니다. 특히 객관적 사실을 겸허한 자세로 분석하는 스스로의 자세와 다양성을 인정하는 조직의 문화가 확증편향을 줄여주는 좋은 요소라고 볼 수 있습니다.

 

관련 자료

 

사족~~~

  • 와탭랩스 자바 개발자 모집 중입니다. 지금 참여하시면 모니터링 분야 최고의 개발자들과 함께 톰캣 모니터링 서비스 개발을 경험해 보실 수 있습니다. 관심 있으신 분은 recruit@whatap.io로 메일 주세요.

 

11895252_1927414600817055_7000107499292301905_o

스타트업 운영의 기법 – 5 Whys

프로젝트를 진행하다 보면 문제가 발생하기 나름입니다. 그럼 우리는 일반적으로 잘못을 저지른 당사자의 책임을 묻곤 합니다. 또는 책임을 묻지 않더라도 암묵적인 확인을 거치게 되죠. 하지만 ‘왜’라는 질문을 던지는 것 만으로도 상황에 대한 근본적인 인식까지 접근 해 볼수 있습니다. 저는 5 Whys를 리더들이 몸에 익혀야 하는 중요한 방법론이라 생각합니다. 왜냐하면 리더는 누군가의 잘잘못을 가리는 자리가 아닌 팀원들이 프로젝트를 진행하는데 불편을 주는 장애물을 치워주는 역할이가 때문입니다. (글을 쓰다보니, 저부터 반성 모드로 전환해야 겠네요. T.T)

The-5-Whys

The-5-Whys

5 Whys는 글자 그대로 다섯 번 ‘왜?’라는 질문을 던지는 방법론입니다.  RCA(Root Cause Analysis), 원인 분석의 기법들 중 유명한 이 테크닉은 도요타 자동차의 제조혁신 과정에서 개발되었습니다.

 

도요타 측은 이 배경에 대해 “문제와 원인을 명확히 하기 위해 우리는 5개의 Why를 활용하며, 이 과학적인 접근법을 통해 문제, 원인을 명확히 알 뿐만 아니라 해결책까지도 명쾌하게 도출할 수 있었다.”라고 설명하고 있습니다.

우리가 프로젝트를 진행하면서 문제가 생길때마다 ‘왜’라는 질문을 던지는 것 만으로 과거의 표면적인 답변을 파고 들어서 문제의 근본적인 원인을 찾을 수 있음에도 대부분의 사람들은 증상에 대한 확인 만으로 멈춰버리곤 합니다.

 

에릭 리스의 5 Whys

에릭 리스의 블로그에 다음과 같은 예가 있습니다.

여러분은 웹 사이트가 다운되었다는 것을 알았다고 해보자. 당연히 가장 먼저 해야 하는 일은 웹사이트를 복구하는 것이다. 하지만 위험이 지나가자마자 ‘왜’라고 묻는 데서부터 시작하는 일종의 해부 훈련을 해야 한다.

  • 왜 웹사이트가 다운되었는가?
    • 모든 프론트엔드 서버의 CPU 사용률이 100%가 되었다.
  • 왜 CPU 사용률이 100%가 되었는가?
    • 새 코드 중 몇 줄에 무한루프를 실행시키는 내용이 있었다!
  • 왜 이런 실수가 있는 채로 코드가 체크인되었는가?
    • 그 기능에 대한 단위 테스트를 하지 않았다.
  • 왜 단위 테스트를 하지 않았는가?
    • 코드 작성자가 신입직원이였고, 테스트 주도 개발에 대해서 충분히 교육을 받지 못했다.

첫 번째 ‘왜’라는 질문에 대한 답만 보면 하드웨어 문제 같습니다. 세 번째  ‘왜’에 대한 답을 보고 나면, 엔지니어 탓을 하고 싶은 생각이 들 수도 있죠. 다섯번째로 ‘왜’라는 질문을 하고 나면, 이런 실수가 다시 일어나지 않도록 하기 위해서는 직원의 조직 적응 프로세스 중에 실수가 있는 부분을 보완해야 한다는 것이 명확해집니다.

7d50b56276ee0f174b1f708ab7a1c0c29dff5fab0f5363b78404cce3dcb6eed8

해당 내용은 에릭 리스의 블로그 STARTUP LESSONS LEARNED에 Five Whys 를 통해 확인해 보실 수 있습니다.

 

제프 베조스의 5Whys

조금 다른 이야기를 보겠습니다. 아마존 창업자 제프 베조스는 직원의 손가락이 벨트에 끼어 상처를 입자 5 Whys를 사용해 원인을 분석하였다고 합니다. 아래는 그 내용입니다.

  • 왜 손가락을 다쳤지?
    • 컨베이어 벨트에 끼였기 때문에
  • 왜 손가락이 컨베이어 벨트에 끼였지?
    • 컨베이어 벨트 위에 있는 가방을 쫓아가다고 있었기 때문에
  • 왜 가방을 쫓았지?
    • 평소 가방을 컨베이어 벨트 위에 올려 놓는데, 컨베이어 벨트가 갑자기 작동했기 때문에
  • 왜 가방을 컨베이어 벨트 위에 올려 놓지?
    • 컨베이어 벨트가 테이블로 사용되기 때문에

직원이 손가락을 다친 이유를 직원의 부주의로 보고 넘어갈 수도 있지만 5 Whys를 통해 직원들이 사용할 테이블이 없다라는 근본 이유를 찾아 낼 수 있었습니다.

자세한 내용은 Jeff Bezos and Root Cause Analysis 에서 확인 해 보실 수 있습니다.

5 Whys

5 Whys

 

5 Whys Canvas

이런 좋은 도구를 비주얼화 시키면 더 좋겠죠? 누군가가 좋은 캔버스를 만들어 놓았더군요. 아래 이미지는 https://www.tuzzit.com/en/canvas/5_whys_canvas 에서 다운 받을 수 있습니다.

5 Whys Canvas

5 Whys Canvas

 

이제 5 Whys 같은 간단하면서도 강력한 도구를 평소에 사용하길 추천합니다.

 

관련 자료

  • http://www.startuplessonslearned.com/2008/11/five-whys.html
  • http://www.shmula.com/jeff-bezos-5-why-exercise-root-cause-analysis-cause-and-effect-ishikawa-lean-thinking-six-sigma/987/

모니터링 서비스 분석 2. mackerel

Meckerel

Meckerel

요약:

  • 고등어라는 의미의 Mackerel 은 일본에서 만들어진 APM 서비스이다.
  • 특징으로는 서버 인프라의 지표뿐만 아니라 서비스의 KPI를 모니터링 할 수있게되어 있다는 것이다.
  • 특히 쉽고 직관적인 API를 제공하여 매트릭을 직접 구성할 수 있게 도와준다.

 

URL:

  • https://mackerel.io/

 

서비스 추가:

모니터링 추가

모니터링 추가

  • Host Metric
  • Service Metric
  • External Http (Experimental)
    • 베타 테스트 기능인 경우 experimental 이라는 마크를 추가하는 게 맘에 듦.

서비스 오픈:

  • 2014년 05월 베타 서비스
  • 2014년 09월 서비스 오픈

 

가격:

  • Free
    • 5 대 까지
  • Standard
    • 월 2000 JPY (2015년 7월 환율 약 18000원)

 

위치:

  • 일본 도쿄

 

개발사:

  • http://hatenacorp.jp/

모니터링 서비스 분석 1. Crittercism

캡처

CRITTERCISM

 

분야:

  • 모바일 모니터링

 

설명:

  • 모바일 애플리케이션 성능 관리 (mAPM) 솔루션을 제공하는 스타트업.

 

기능

  • App Crash Monitoring and Reporting
  • Cloud Service API Monitoring
  • Transaction Monitoring
  • User and app analytics data
  • Breadcrumbs

 

요금:

  • 무료
    • 월 사용자 3만명까지 지원
  • 월 $300 (월 32만원)
    • 월 사용자 1만명까지 지원

 

투자자:

  • Google Ventures
  • Scale Venture Partners
  • Opus Capital
  • Shasta Ventures
  • InterWest Partners
  • Accenture
  • vmware
  • KPCB
  • AOL Ventures
  • AngelPad

 

위치:

  • San Francisco CA

 

 

와탭에서 개발자를 모집합니다.

와탭 엔지니어팀의 일주일

매일 아침 칸반 보드 앞에서 stand-up meeting으로 하루를 시작하는 와탭 엔지니어팀은 고객들의 모니터링 데이터를 수집, 보관, 분석하는 데 필요한 것과 그 이상의 것들을 개발합니다. 와탭은 국내에서 유일하게 가입형 모니터링 서비스를 개발 및 운영하고 있으며 매달 100% 이상 증가하는 고객의 데이터들을 안정적으로 처리하고 있습니다. 수 천대 이상의 서버가 매 분마다 제공하는 수 많은 데이터들을 안정적으로 수집하고 처리하는 과정에서 시스템을 끊임없이 개선하는 일은 개발자에게 때로는 좌절을 그리고  때로는 희열을 가져다 줍니다. 또한 수집 된 데이터들을 더욱 유려하고 편리하게 표현하는 과정에서 자신의 숨은 미적 감각과 센스를 찾아내기도 합니다. 와탭 모니터링 엔지니어팀은 한 주의 마감을 매주 금요일 다 같이 모여 회고를 통해 마무리 하고 있습니다. 와탭의 일주일 안에는 다음과 같은 Activity들이 포함되어 있습니다.

  • 매일 서로의 일정에 대해 주고 받는 Stand-Up Meeting
  • 와탭이 하는 모든 일들을 확인 할 수 있게 도와주는 Kanban Grooming
  • 하나의 스토리를 같이 작업하는 Pair Programming
  • 일주일간의 작업들을 잘된 점과 안된 점들을 생각해보는 Friday Retrospective
이미지 1

와탭 칸반 보드

자신이 만든 서비스로 모니터링하는 와탭 엔지니어팀.

“와탭”은 “와탭 모니터링 서비스”를 통해 모니터링 받고 있습니다. 관리 또한 와탭 서비스는 와탭 엔지니어팀이 직접 진행합니다. 자신이 개발한 기능을 사용해서 개발중인 서비스를 모니터링 하는 경험은 정말 놀라운 일입니다. 와탭을 개발하고 와탭으로 모니터링하며 와탭으로 서비스를 관리하는 엔지니어팀에게 DevOps는 너무나 자연스러운 일상입니다. 와탭은 셀프 모니터링을 통해 장애를 사전에 차단하여 고객의 불편의 최소화하는 것을 목표로 삼고 있습니다. 와탭 엔지니어팀은 어떠한 개발 과정에서도 운영에 소흘함을 남기지 않습니다.

이미지 2

모니터링 기술 스택

와탭 모니터링 서비스는 고객의 서비스 데이터를 매 분마다 수집하기 때문에 대규모 데이터가 누적되고 있습니다. 와탭 모니터링 엔지니어팀은 이 방대한 데이터를 안정적으로 다뤄야 할 뿐만 아니라 데이터를 통해 고객에게 어떤 가치를 줄지 고민해야 합니다. 다양한 운영체계와 시스템에 대한 전문 지식이 필요합니다. 그리고 가장 중요한 것은 배움에 대한 자세와 더 좋은 결과물을 얻기 위해 토론을 즐기는 것입니다. 와탭 서비스는 아직도 매일 매일 더 개선 된 모델을 향해 조금씩 변화하고 있습니다. 모니터링 엔지니어팀은 다양한 더 낳은 서비스를 위한 이슈 처리와 함께 계속 증가하는 데이터를 안정적으로 처리하기 위한 모델 개선에 노력하고 있습니다. 와탭 모니터링 엔지니어팀은 아래와 같은 기술 스택을 가지고 있습니다.

  • 모니터링 내부 엔진으로 사용하기 위한 Zabbix
  • 고객의 정보를 저장하기 위한  MySQL DB
  • 시스템간 메세지 교환을 위한 RabbitMQ
  • 모바일 지원을 위한 Push Notification
  • 데용량 데이터 베이스를 위한 HBase
  • WhaTap Monitoring Technology Stack
Backend

WhaTap Monitoring Technology Stack

와탭이 사용하는 협업 도구들

와탭 모니터링 엔지니어팀은 효과를 중요시 여깁니다. 고객에게 가장 좋은 효과를 제공하기 위해 많은 고민을 하지만 확신이 서지 않는 경우에는 빠르게 제품을 만들고 고객의 의견에 반응합니다. 이 과정에서 와탭 모니터링 엔지니어팀은 효율을 최우선 하게 됩니다. 와탭 모니터링 엔지니어팀에서는 효율적인 작업 프로세스를 위해 아래와 같은 커뮤니케이션 도구들을 활용하고 있습니다.

  • 빠른 정보 전달과 일정 관리를 위한 Kanban
  • 프로젝트 이슈 관리를 위한 Redmine
  • 팀 커뮤니케이션을 위한 Telegram
  • 팀의 효율적인 문서화를 위한 Google Apps

모니터링 엔지니어팀에 합류하게 된다면…

2주 내에 와탭 서비스에 자신이 만든 코드를 적용하는 경험을 가지게 됩니다.
매주 한번 이상 자신의 코드가 와탭 서비스에 반영되는 경험을 가지게 됩니다.
개발을 넘어 서비스에 대한 고민을 하는 경험을 가지게 됩니다.
수평적 조직 구조를 경험하게 됩니다.
칸반을 경험하게 됩니다.
서버를 모니터링 하는 방법들을 경험하게 됩니다.

지원 분야

  • 웹 개발
    • C# , ASP.NET, HTML, JQuery, Python, MySQL, NoSQL
  • 모바일
    • Android, iOS

 

지원 자격

  • 지원 분야에 대한 개발이 가능 하신 분(개발 년차에 상관 없음)
  • 하나의 서비스를 지속적으로 개발한 경험 (우대 사항)
  • Android와 iOS 개발이 모두 가능한 분 (우대 사항)
  • 대용량 데이터 처리 및 분석 경험 (우대 사항)
  • 독서를 즐기시는 분 (우대 사항)
  • 글 쓰기를 좋아하시는 분 (우대 사항)

근무 환경

  • 신입:  3,000 만원 + α
  • 근무 시간 : 9시 ~ 18시
  • 무제한 도서 구입

 

지원 방법 및 절차

와탭 엔지니어팀에 지원하고 싶은 신 분께서는 recruit@whatap.io 로 이메일을 보내주시면 됩니다. 이력서를 제출해 주시면 일주일 이내에 저희 개발팀에서 전화 인터뷰 요청을 문자로 보내드립니다. 전화 인터뷰를 후에는 분야 별 코딩 테스트를 이메일로 진행하게 되구요. 코딩 테스트를 통과하신 분들은 와탭 개발팀과 팀 인터뷰를 진행하게 되며 팀 인터뷰가 마무리 되면 채용이 결정되게 됩니다. 이 과정에서 와탭은 지원자 분들에게 불편함이 없도록 최선을 다하겠습니다.

  • 이메일 지원 recruit@whatap.io 으로 이력서 제출 (희망연봉 기재)
  • 전화 인터뷰
  • 분야별 코딩 테스트 (e-mail)
  • 팀 인터뷰
  • 채용 결정

 

와탭은 경력보다는 실력과 스마트함을 중요하게 생각합니다.

좋은 개발자를 위한 최고의 대우를 위해 노력 하고 있습니다. ( 생각처럼 쉽지 않네요. 죄송합니다. )

 

회사 전화: 070-7151-1803

회사 주소: 경기도 성남시 분당구 장미로 36(야탑동)

스타트업이 스크럼을 버리고 칸반으로 가는 이유에 대해

첫 사랑처럼 다가왔던 스크럼과 이별하다.

처음 스크럼을 알게 됬을 때, 첫 사랑에 눈뜬 청년마냥 가슴이 두근두근 했었습니다. 일일 스크럼, 스프런트 계획, 스프런트 리뷰로 이어지는 쳬계적인 스케쥴과 반복을 통한 자기학습은 팀을 성장시키면서 프로젝트를 진행하는 완벽한 프로세스로 보였습니다. 하지만 그런 스크럼과의 7년 열애를 뒤로하고 이제 저는 스크럼과 이별을 하고 있습니다 . 하지만 스크럼은 앞으로도 저에게 가장 큰 영향을 준 프로세스가 될 것입니다.

Scrum

 

왜 헤어져야 했는가.

제가 스크럼을 만났을 때, 스크럼은 가장 합리적인 프로세스였습니다. 쓸데없이 산출물을 요구하지도 않았으며 짧으면 2주 길어도 한달이면 우리가 만든 것들을 보면서 대화를 나눌 수 있었습니다. 그 시절 다른 프로세스들은 1년이 지나도 동작하는 소프트웨어를 만나기 어려웠기에 스크럼은 더욱 더 돋보일 수밖에 없었습니다. 하지만 시간이 흘러 저는 스타트업을 하고 있고 3개월안에 가치 증명을 원하는 린 세상에서 스크럼은 느려보였습니다. 그리고 지금 제 옆엔 칸반이 서 있습니다.

 

무슨일이 있었길래.

사실 스크럼은 잘못한게 없습니다. 다만 제 상황이 변한 것 뿐이죠. 이 모든 것의 시작은 제가 스타트업을 시작하면서 부터였습니다. 스타트업인 와탭(구 디자인플러스디)을 시작했을 때 우리는 개발자 3명이 전부였습니다. 스크럼 팀을 구성하기엔 너무 조직이 작았습니다. 다행히 우리는 스크럼에 익숙했고 우리가 만들어야 하는 것에 대해 너무나 잘 알고 있었기에 개발자 셋 모두가 PO(제품 책임자)였으며 스크럼마스터였습니다. 하지만 팀은 작았으며 속도는 더 빨라야 했습니다. 우리는 매주 스프린트 결과물을 확인하길 원했지만 추가로 딸려오는 플래닝과 추정은 부담으로 다가왔습니다. 우리는 아침마다 스크럼미팅을 통해 간략한 상황 파악만 하였고 매주 결과물을 보며 다음 주에 해야 할 것들을 정리했습니다. 결국 우리는 관리가 전혀 필요하지 않은 프로세스가 필요했고 그런 우리에게 칸반이 다가왔습니다.

3e12972c32658548e55b2b866c53864d

 

지금은.

지금 우리는 개발자 5명과 디자인, 기획, 마케팅, 영업 한명씩 모두 9명이 있는 스타트업입니다. 스크럼 팀으로 운영되기에 이상적인 환경입니다. 하지만 지금도 우리는 스크럼을 사용하지 않습니다. 우리는 제품 책임자도 없으며 스크럼 마스터도 없습니다. 제품에 대한 방향도 전체 팀원들이 정하며 추정 또한 사용하지 않습니다. 와탭은 매주 한번 이상의 서비스 업데이트를 하고 있기에 이터레이션은 여전히 1주 이내입니다. 그리고 중심에는 칸반 프로세스가 있습니다.

 

칸반에 반하다.

와탭이 스크럼 대신 칸반은 쓰는 이유는 무엇일까요? 그건 칸반이 협업은 최대로 끌어올리지만 관리 요소는 최소화 시키기 때문입니다 . 그리고 칸반은 스크럼에 비해 아주 경량화 된 프로세스입니다. RUP와 비교한다면 프로세스가 없다라고 할 수도 있습니다. 하지만 프로세스가 없는 것과 칸반을 쓰는 것은 엄청난 차이입니다. 그리고 작업 단계별 제약 사항은 이제 우리에게 없으면 안되는 프로세스가 되었습니다.

칸반이란 일본어로 ‘신호카드’를 의미한다. 제조업에서는 프로세스의 상류단계에 더 생산하라는 신호를 보낼 때 이 카드를 사용한다. 하루 단계로부터 이 신호를 받지 못하면 프로세스 각 단계에 있는 작업자는 업무를 진행할수가 없다.

와탭 칸반 프로세스:

  • 일을 작은 조각으로 나누고, 카드에 각 항목을 기입 한 후 벽에 붙인다.
  • 이름이 부여된 열을 사용하여 각 항목이 작업 흐름의 어디에 있는지 표시한다.
  • 작업항목(Work In Process) 개수를 제한한다.
  • 리드타임( 한 항목을 완료하는 데 소요되는 평균시간)을 측정하고, 리드 타임을 가능한 짧고 예측 가능하게 만들 수 있도록 프로세스를 최적화한다.

www.crisp.se_file_uploads_Kanban_vs_Scrum

 

칸반과 사귀기 위해 준비한 것들.

우리는 칸반과의 만남을 위해 몇가지 준비를 해야 했습니다.

  • 커다란 칸반 보드
  • Redmine
  • Git

스크럼과 마찬가지로 칸반 프로세스의 핵심은 작업의 시각화입니다. 우리는 칸반보드를 벽에 붙여서 관리하고 있습니다. 트렐로를 많이들 이용하지만 빈 벽이 있다면 벽을 사용하시는 것을 추천드립니다. 온라인으로 작업 하시길 원하신다면 Trello와 Taiga 같은 온라인 칸반 보드들이 있습니다.

칸반 보드만 사용한다면 히스토리가 남지 않는 것에 대한 불편함을 가질 수 있습니다. 그래서 Redmine, Trac, Jira 같은 도구들을 사용하여 프로젝트를 관리하면 많은 도움이 됩니다. 그 중 Redmine은 무료이면서도 강력한 도구입니다.

마지막으로 소스 저장소 입니다. 사실 소스 저장소는 칸반과 전혀 상관이 없습니다만 아직 SVN 또는 Git을 사용하지 않고 있다면 아직 프로세스를 점검할 단계가 아닙니다. 우선 소스 저장소 부터 사용하시기 바랍니다.

당장은 이정도만 준비 해도 칸반을 적용하실 수 있습니다. 만일 팀이 정말 작다면 Redmine은 사용하지 않으셔도 됩니다.

Board-05

 

 

칸반과의 만남을 유지하려면.

칸반과 만남을 유지하려면 몇가지 약속들을 지켜야 합니다. 칸반은 원하는 것이 많지 않지만 그러기에 신경이 더 쓰이는 것도 사실입니다. 자신이 있는 조직에 상황에 맞게 원칙을 만들어가야 합니다. 원칙들을 만들어 가지 못한다면 칸반은 카오스로 변할지도 모릅니다.

와탭이 지키는 칸반 규칙:

  • 매일 오전 10시 이전  칸반 보드 앞에서의 스탠드 미팅
  • 틈틈이 칸반 보드 그루밍
  • 매주 금요일 회고 및 리뷰
  • 한달에 한번 Backlog 만들기
  • WIP 제약 사항 지키기

오전 스탠드 미팅은 선택사항이긴 하지만 애자일에서 무척 중요하게 여기는 활동입니다. 어제 한 일, 오늘 할 일, 업무장애에 대한 이야기만 짧게 하기 때문에 하루 15분을 넘지 않습니다. 하지만 이 시간만 잘 이용한다면 팀에서 생기는 소통에 관힘 이슈들이 대부분 해소됩니다. 특히 칸반 보드를 앞에 두고 한다면 효과는 훨씬 좋습니다.

모든 일들은 시간이 지나면 상황이 변하기 마련입니다. 그러기에 매일 또는 매주 두번이나 세번정도 칸반 보드 그루밍을 해야 합니다. Backlog와 ToDo도 현재 상황에 맞는지 확인해야하며 버틀랙(병목지점)이 없는지도 확인해 봐야 합니다. 칸반보드 그루밍은 스탠드 미팅이 끝나고 진행 할 수도 있으며 누구나 할 수 있습니다.

매주 금요일 회고 및 리뷰는 칸반에서 가장 중요한 일중에 하나입니다. 왜냐하면 이 때 모든 것들을 정의할 수 있기 때문입니다. 칸반에서 회고를 언제하라는 실행 방침은 없지만 칸반은 경험을 통한 발전을 지향하는 프로세스입니다. 매주 각자 지내온 일들을 뒤돌아 보고 더 좋은 방법을 찾고 장애물을 제거하는 시간입니다.

와탭은 한달에  한번씩 전체가 모여 Backlog를 만들고 있습니다. 전체 로드맵과 개발 Backlog를 일치 시키는 일은 자주 해야 할 일은 아니지만 한달에 한번씩 진행할 가치있는 일입니다.

WIP(Work In Process) 제약을 만들고 지키는 일은 칸반의 핵심이자 필수입니다. 스크럼과 칸반의 가장 다른 점은 스크럼은 이터레이션 별 작업량을 제한하지만 칸반은 작업 구간별로 작업량을 제한하는 것입니다. 구간별로 작업량을 제한하면 전체 프로세스가 빨라지는 마법같은 일이 일어나게 되는데, 작업량을 어떻게 제한할지는 경험적으로 알아내야 합니다.

 

언젠가는 또 이별하겠지만.

스크럼과 칸반 모두 프로세스 도구입니다. 도구라는 것은 상황에 맞게 사용하는 것이기에 우리는 또 다른 상황이 되면 다른 프로세스 도구를 사용하고 있을 수 있습니다. 하지만 운영과 개발을 모두 해야하며 소규모 조직이 관리의 들어가는 비용을 최소화하기위한 방법으로 칸반보다 더 매력적인 프로세스가 언제 나올수 있을지는 모르겠습니다.

 

 

p.s.

스타트업 개발사이면서 칸반을 도입하려거나 개발 프로세스를 만들고자 하는 팀과 같이 이야기 나누길 좋아합니다.

필요하시면 덧글 남겨주세요.

 

관련글모음

  • http://pitzcarraldo.github.io/articles/2014/05/08/goodbye-scrum-hello-kanban/
  • 칸반과 스크럼(헨릭크니버그, 마티아스 스카린 | 심우곤, 인범진)
  • 칸반 (데이비드 J. 엔더슨 지음 | 조승빈 옮김)
  • http://selfothercontext.com/tag/%EC%8A%A4%ED%81%AC%EB%9F%BC/ (칸반의 개척자 데이비드 J. 앤더슨과의 인터뷰)