지난 10월의 어느날. 평화로운 일요일 오전. 날씨는 맑음.
약간 늦은 잠을 깨서 따사로운 커튼 사이의 햇살을 받으며 직접 만든 브런치를 즐길 때의 사진이다.
좋은 천연 버터와 유기농 계란을 섞어 휘저으면 따로 소금간을 하지 않아도 훌륭한 음식이 된다. (인터넷으로 뉴질랜드 앵커 버터를 3~4개 주문하는걸 추천한다 100% 유기농에 가격은 시중 국산 가공 버터와 비슷하다!)
원룸으로 이사를 한 이후 왠만하면 기름에 튀기는 음식을 하지 않으려고 팬도 치웠기 때문에 요즘은 냄비에 버터를 녹여 영국식 스크램블 에그를 즐겨 한다. 팬에 할 때와는 다른 부드러운 식감이 일품이다.
구수한 식빵에 얹어 먹어도 좋고 심심하다 싶으면 소세지를 삶아서 입맛을 돋구면 그렇게 든든할 수가 없다.
커피는 내 소울 푸드인데 직접 빈을 갈아서 한땀 한땀 장인 정신으로 최순을 다해 내려 먹는다.
수년간 다진 brewing 기술은 청와대 민정수석이 와도 함부로 내려주지 않는다.
갑자기 먹방 블로그가 됐는데, 아무튼 스타트업의 정신없는 일주일을 보내고 나면 주말의 여유 정도는 좋지 아니한가?
요즘 소프트웨어 개발 용어들 중에 음식과 관련된 용어들을 많이 사용하는것 같아서 그냥 끄적여 봤다. baking 이라던가 brewing, cherry pick..
과거 전통적인 소프트웨어 용어들 architecture, compile, build 등이 건축 용어에서 따온 convention이 있곤 했는데 아재 냄새 안나고 신선한 것 같다.
프로그램을 말아서 넣다..는 어디서 온걸까?
곰탕을 말아 먹다 에서 따왔나? 크흡..
근데 이런 여유도 10월까지였다...
1달 1포스트를 목표로 했지만, 11월에는 글을 쓰지 못할 뻔 했다. 정말 전쟁같은 11월이 지났고, 어느덧 일년의 마지막 달을 목전에 두고 있다. 엎친데 덮친 격으로 토요일 마다 자꾸 광화문에 갈 일이 생겨서 글을 쓸 시간을 더 빼앗겨 버렸다.
오랜만에 거리의 행위 예술을 즐기니 마음의 양식을 먹은 것 같다.
곧 신제품 출시다, 다들 힘내자! 하야!!
아름다운 시구어는 마음을 울리고
이렇게 조형 예술도 보고
그래도 그 와중에 우리팀은 크리스마스 대목을 앞두고 신제품 런칭 준비에 한창이다!
요즘 부쩍 잡설이 길어진거 같다. 아무튼 본론으로 들어가자. (드디어..)
오늘은 애자일과 스크럼에 대한 짧은 의견을 적어보고자 한다.
스타트업에 와서 느끼는 한가지 큰 변화는 속도이다.
아 물론 어딜가나 모든 회사는 속도를 중요시 하긴 한다. 특히 대한민국의 회사들은 근면 성실 부지런함이 국민성이라고 세뇌시켜 밤낮으로 개발자를 갈아서 제품을 만들다가 몇명 등대에서 떨어져 죽어도 그러려니 하기도 한다. (작금의 사태를 비꼬는거 맞다)
누군가의 무능으로 효율성이란 것을 잃어버린 거대 조직이 속도를 내기 위해서는 개개인이 고통을 분담하여 청춘이라는 대출을 받아 메꾸는 것이 best way without thinking 아니겠는가?
근데 내가 여기에서 말하는 속도는 변화 속도이다. 큰 조직들에 비해 조직이 작은 신생 기업들은 구성원들 간의 단결력도 '상대적으로' 좋은 편이고 무엇인가 잘못되었을 때 과감하게 버리고 새로운 것을 시도할 수 있는 '변화 속도'가 장점이다.
그래서 많은 스타트업들 뿐만 아니라 큰 회사들의 팀 단위에서 빠른 변화에 대응하고 민첩하게 제품을 내놓기 위해 애자일 소프트웨어 개발방법론을 도입하곤 한다.
우리 엔지니어 팀도 애자일을 도입하고 있다. 애자일 개발 방법론 중에 여러 방법론들이 있지만 그 중 가장 유명한 건 스크럼인 듯 하다. (사실 뭔지 잘 모른다)
Agile 이 뭔가? 민첩한 것 아닌가?
팀원 모두가 하나의 공통의 Goal 을 향하고, 형식적인 계획이나 문서화를 최소화 하고, 기민하게 적응하며, 빠르게 적용하고, 버리고, 바꾸고, 잦은 리뷰와 소모적인 회의를 피하고, code-oriented 한 개발을 지향하는 것이다.
간혹 많은 사람들이 애자일의 의미를 잘못 오해하고 있는데 민첩하다고 해서 계획을 빨리 세우고 빨리 만들어 제품을 출시 하라는게 아니다. (그건 그냥 Press 다.... )
솔직히 애자일에 대해 책을 제대로 정독한 적도 없고 관심도 없었다.
다만 실전에서 느끼는 바를 짧게 적자면 애자일의 핵심은 빠른 개발이 아니다.
애자일은 빠른 변화, 빠른 적응을 의미한다.
(그래서 잦은 대화가 필수)
애자일 방법론 중 유명한, 우리 팀이 활용하고 있는 스크럼의 '형식적인' 방법론을 나열해 보자면 이렇다. (그냥 내가 본 것 들은것 느낀것을 나열한 지극히 주관적인 내용들이다)
Sprint 라 불리는 반복되는 개발 주기가 있고(보통 30일을 추천) 이 기간 동안 해야 할 일들을 정하는 Planning meeting 을 갖는다. 태스크들을 모아놓은 것을 Backlog 라 부르며 여기에서 스프린트 동안 할 일들을 골라서 계획을 세운다.
Planning meeting 에서 정한 태스크들은 Sprint 내에 모두 완료해야 한다. 모든 것이 구현되고 검증까지 완벽하게 되는 것을 원칙으로 한다. 그렇기 때문에 할 수 있는 태스크만 스프린트에 넣고 계획을 세워야 한다. 모든 팀원들이 각자 자기가 할 일을 정하고 포인트를 매겨서 이번 스프린트가 얼마나 빡세질 것인지를 계산해 둔다.
스크럼 보드에 태스크들을 나열 하고 3단계~5단계로 나눠 진행 상황을 팀원들과 공유를 한다.
원칙적으로 Sprint 도중 다른 태스크가 인터럽트 되는 것을 거.부.한.다. 이 역할을 스크럼 마스터가 한다. (총알받이가 되어 욕을 먹으라는 이야기다)
매일 일정 시간 동안 매우 짧은 (15분 내외) 스크럼 미팅을 정하고 그 전날 했던 내용, 이슈, 그 날 할 일들을 팀원 모두에게 공유하는 것을 추천한다.
스크럼 마스터는 각자의 태스크를 스프린트 내에 수행할 수 있도록 주기적으로 진행 상황을 점검하고 스프린트를 서포트 한다
미드 실리콘 벨리의 한 장면. 스크럼 보드에 덕지 덕지 쌓여 있는 태스크들
내가 6월에 조인 하고 나서 20번이 조금 안되는 스프린트를 돌았던 것 같다. 왜 그런지는 모르겠지만 우리 팀은 유독 스프린트 주기가 2주에서 4주 정도로 짧은 편이다.
솔직히 말하면 스크럼이 제대로 지켜진 적이 별로 없는듯 하다. 그만큼 애자일이 힘들다.
나같은 펌웨어 엔지니어들이나 하드웨어 엔지니어들에게는 애초에 생소할 수 밖에 없는 방법론이기도 하지만, 수많은 소프트웨어 엔지니어들도 스크럼 회의론은 많이 나온다.
그럼 왜 그렇게들 애자일에 실패 할까?
일단 빡세다
사실 실체가 없는게 애자일의 핵심이 아닐까. 뭐 이래라 저래라 하는 책들이 많은데, 그거 읽는다고 팀 생산성이 좋아지나?
정답이 없으니 flexible 하고
정도가 없으니 adaptive 한것 아니겠는가?
앞에서 '형식적인' 방법론 이라고 한 이유가 있다. 그리고 방법'론'은 말 그대로 theory 다.
실전에서 애자일이 좋다더라.. 해서 도입하려고 하면 뭔가 도입을 해야겠다는 강박 관념 때문에 애자일 망령에 빠지기 쉬운데 그러다 보면 실제 할일을 해내기 보다 스크럼을 위한 스크럼을 하게 된다.
어쩔때는 daily standing meeting 이 무의미하기도 했고 (딱히 공유점도, 이야기를 나누는 보람도 없는), 다들 over pace 스프린트를 마치고 나면 스프린트를 마치지 못했다는 자괴감에 빠지기도 한다. 소모적인 회의를 피해야 하는데 팀원이 많아지고 할일이 많아 지면서 회의가 2~3시간씩 길어지기도 했다. 연속적인 스프린트 강행군으로 팀원들의 피로가 쌓이는 것이 보이기도 했다.
다행히도 이런 부분들을 개선하기 위해 꾸준히 대화를 하며 고쳐 나가곤 했지만 아직은 모두가 서투른 것이 애자일이 아닌가 생각한다.
실제 며칠 전에 끝마친 우리팀의 Sprint Burndown Chart.
회색이 가이드 라인 속도이고 붉은 색이 실제 우리가 진행한 속도이다.
항상 그렇듯.. 숙제는 마지막에 몰아서
솔직히 말하면 개인적으로 애자일은 (임베디드 엔지니어인) 나를 너무 힘들게 하긴 했다.
일단 우리 팀의 스프린트 주기, 즉 배포 주기는 펌웨어 소프트웨어 배포 주기에 비해 너무 빠르기 때문이다.
며칠 만에 하나의 서비스 프로토타입 내지 기능을 뚝딱 배포하기도 하는 서비스 소프트웨어와는 달리 펌웨어는 배포의 개념이 전혀 다르기 때문이다. 물론 기능 별로 유닛 테스트를 할 수는 있지만 배포가 됐다고 할수는 없다.
생산성 최악의 언어(?) C 를 사용하는 것과 개발 환경이 그지 같다라는 것은 둘째 치고, 예상치 못한 하드웨어 이슈들과 시스템 이슈들이 겹치기 때문에 많은 부분들이 예상보다 많은 비용이 발생하기도 한다. 실제로 하나의 이슈를 처리하는데 원인 분석에만 한달이 걸린 적도 있다!
그리고 시스템이 커지면서 모든 팀원들이 feature implementation 보다는 trouble shooting 에 소모하는 시간이 점점 늘어나고 있다!!
그리고 시스템이 커지면서 모든 팀원들이 feature implementation 보다는 trouble shooting 에 소모하는 시간이 점점 늘어나고 있다!!
사실 세상 모든 이슈가 계획된 주기(스프린트) 내에 끝날 것이라고 예측하는 것은 애초에 말이 안된다. 그래서 나름 개인적으로 내린 결론은,
스크럼의 가이드 라인은 권장 사항으로 이해하되 그것에 너무 스트레스를 받을 필요는 없다... (라고 자기 최면중...)
공통의 목표에 맞춰서 스케쥴을 지키되, 각자의 개발 및 결과 도출 주기를 존중해야 한다.
다른 팀(또는 회사)와 우리 팀을 비교 하지 말아야 한다. 우리는 우리 나름대로의 pace 가 있다
애자일 보다 팀웍이 우선!
개인적으로도 애자일은 여전히 생소하며, 아직도 팀 내에서 스크럼에 대한 의견은 엇갈리고 있다. 하지만 본질적인 문제는 애자일 그 자체에 있는 것이 아니다. 매 번의 Sprint 보다 중요한 것은 모두가 공통의 목표를 바라보고 거시적인 Marathon 의 목표를 향해 나아가는게 중요하지 않을까