“소프트웨어의 모든 것은 변한다. 요구사항은 변한다. 설계도 변한다. 비즈니스도 변한다. 기 술도 변한다. 팀도 변한다. 팀 구성원도 변한다. 변화는 반드시 일어나기에, 변화는 문제 그 자체가 되지 못한다. 변화를 극복하지 못하는 우리의 무능력이 문제다.”" – Kent Beck, <Extreme Programming>
레모네이드 개발팀은 변화에 민감합니다. 보다 짧은 주기로 어플리케이션을 테스트하고 개선하길 반복하죠. 시시각각 변화하는 개발환경 속에서 어쩔 수 없이 마주할, 무수히 많은 버그를 최소로 만들기 위해섭니다.
그래서인지 우리는 CI/CD 자동화와 유닛테스트에 익숙합니다. 지속적으로 의견을 하나로 모으고(Integration) 결과물을 보여주는 것(Deployment), 그리고 그 결과물의 효용을 테스트(Testing)하는 것은, 레모네이드 개발팀의 문화 그 자체를 대변한다고 해도 과언이 아닐 겁니다.
이런 문화를 만들고 유지할 수 있는 가장 중요한 요인은 '직급/경력에 구애받지 않는 자유로운 토론 문화'에 있습니다. 변화에 예민하게 움직이려면, 다양한 아이디어가 필요합니다. 혁신을 가져다 준 새로운 아이디어는 대부분 자유로운 분위기 속에서 나왔고, 때론 엉뚱할 수도 있는 상상이 어려운 문제를 쉽게 해결할 수 있는 키가 되어오지 않았습니까.
때문에 구성원들이 능동적으로 사고할 수 있는 환경을 조성하기 위해 애씁니다. 다음은 레모네이드 개발팀이 의견을 모아(Integration) 실력을 보여주고(Deployment), 성장을 시험해보는(Testing) 몇 가지 방법입니다.
Integration :
- 데일리 스탠드업 미팅 | 우리의 개발이 같은 곳을 바라보게 하는 것
오전 11시 40분, 구글 캘린더는 어김없이 개발팀의 데일리 이벤트를 리마인드해 줍니다. "개발팀 Daily Stand-Up Meeting 10분 전입니다."
이 스탠드업 미팅에서 우리는, 어제오늘 서로 어떤 일을 했고 내일 오전까지 어떤 것들을 처리할 것인지를 빠르게 확인하고 공유합니다. 업무 중 특이사항은 없었는지, 업무 이외의 이슈라도 주의해야 할 것은 없는지一예컨대 건강 상태나 업무 컨디션에 이상은 없는지 같은 소소한 이슈도 확인합니다.
이 미팅에서 가장 주안점을 두는 것은 '심플함'. 회의시간은 최대 10분을 넘기지 않습니다. 더 자세한 논의가 필요한 사안은 별도 미팅을 주최하거나 정기 미팅에서 심도있게 논의하는 편이죠.
Deployment :
- 개발팀 정기미팅 | 우리의 성장을 보여주기 위한 것
주간미팅
한 주 간 있었던 일은 매주 금요일마다 진행하는, 주간미팅에서 회고합니다. 짧으면 1시간, 길면 2시간까지 소요됩니다. 여기선 주간 업무 뿐만 아니라 리드 미팅 혹은 기타 미팅에서 나온 안건들을 공유하고 각자 나누고 싶은 토픽 등을 꺼내 논의합니다. 팀원들이 개별적으로 제시하는 토픽은, 개발팀 전원의 투표로 업무 우선순위를 지정합니다. 가장 높은 점수를 받은 토픽이 최우선 과제가 되는 것이죠. 각 토픽에 관해 토론할 때에는 모두의 의견을 듣고 최선의 답을 찾으려는 데에 집중합니다.
월간미팅
매월 마지막 금요일에는 월간미팅을 개최합니다. 주간미팅과 거의 유사하지만, 이때는 지난 한 달 간의 일들을 종합적으로 회고하고 다음 달에 내딛을 걸음걸음에 대해 공유하고 설계하는 시간을 갖습니다. 한 달이라는 큰 단위 기간에 대해 이야기하는 것이죠.
Testing :
- Pull Request 활용한 코드리뷰 | 나의 성장을 보여주는 것
비즈니스의 성장 속도에 보조를 맞추어, 우리도 다양한 기능과 서비스를 빠르게 개발해야 한다고 믿습니다. 하지만 속도만 중요시하다보면, 버그 발생 가능성이 높아지는 것은 물론, 이에 반비례하여 코드 품질 역시 떨어지게 됩니다.
코드 리뷰는, 이런 문제발생 가능성을 최소화하기 위한 방안 중 하나로, 팀원들의 피드백을 받고 통과한 Feature만을 서비스에 반영하는, 우리 팀의 대표적인 문화 중 하나입니다.
Pull request(주 : 특정 개발자가 시스템 상 변경한 내용을 동료들에게 알려주는 것. 혹자는 PR로 줄여 말하는 경우도 있는 것 같습니... 편의상 '내 활동을 남에게 알린다'는 개념 정도로 이해하면 되겠습니다.)를 통해 구성원들이 리뷰를 하는 것으로, 리뷰 요청의 상대방은 모든 팀원이 될 수 있습니다.
직급, 경력, 나이와 상관없이 말이죠. 덕분에 모두가 코드 리뷰에 참여하고, 각자의 리뷰 스킬을 향상시키고 있습니다. 설령 각자 다른 Feature를 개발하더라도 버그 및 코드 품질은 다 같이 점검하다보니, 코드 규격에 통일성을 마련할 수 있다는 장점도 있습니다. 우리는 이로써 비(非)담당자도 코드를 수정 또는 체크할 때에 쉽게 이해하여 빠르게 처리할 수 있으리라 기대합니다.
빠르게 성장하는 레모네이드 개발팀에서 일하고 싶다면 ?