지난 주에는 신규입사한 개발자들을 대상으로 conway's law에 대해서 간단하게 설명을 했었다. 설명을 하다가 보니 더 자세하게 정리를 하고 싶어서 글을 쓰기 시작했는데 너무 방대하게 글이 써지기 시작을 했다.(글쓰기는 너무 어려워;;)
conway's law로 시작을 해서 software architecture로 내용이 발전하기 시작했고 component architecture와 network architecture를 얘기하다가 급기야 monolithic aerchitecture와 microservice architecture까지 진행하고 있었다.
conway's law는 architecture와 조직구조에 대한 얘기라 자연스럽게 조직구조에 대한 얘기를 적기 시작했더니 바로 공개하기 어려운 상태로 글이 진행이 되었다. 주제가 너무 광범위해지면서 끝맺음을 하기 어려운 지경에 이른 것이다. 아마 이번 비공개 상태의 글은 주제별로 나누어서 공개를 하던가, 내년 상반기까지 글을 쓸거 같다. 주로 내가 다녔었고 다니고 있는 3개의 회사에서(eMFORCE, Naver, Coupang) 겪어온 과거의 경험과 현재의 경험, 그리고 미래에 대한 이야기를 하게 될 것이다.
다소 장황한 글을 쓰다가 용어를 하나 만들었는데 semi-microservice architecture라는 표현이다. 지금까지 실무를 하면서 명확하게 느낀 사실은 아키텍쳐와 조직구조들은 0과 1이 아닌 반정도의 상태가 존재를 하고 이 시간들이 꽤 길었다는 것이다. 그 긴 시간동안 가고자 하는 아키텍처의 방향으로 수많은 팀들이 있는 조직이 점진적으로 변경하는 것은 어렵고 고단한 일이지만 실무에서는 항상 존재하고 해결해야 하는 이슈이다. 이 아키텍처 패턴의 의미는 monolithic architecture와 microservice architecture의 중간 형태로 보면 이해가 쉬울 것이다.
비즈니스가 성장하고 조직이 커지면서 여러가지 문제들이 발생을 하는데 그 문제점들을 최소화할 수 있는 조직문화를 만들고 지켜야 한다. 우리 쿠팡의 개발조직은 처음부터 많은 수의 개발자들이 참여해서 업무를 할 수 있도록 설계를 하고 시작을 했다.
우리가 많이 보던 애자일 선언문이다. 애자일에 관심을 가진 사람이라면 한번씩을 읽어봤을 것이다. 선언문의 철학은 애자일/스크럼 전체 프랙티스들에 큰 영향을 끼치고 있다. 선언문은 단순하지만 애자일 철학이 중요하게 생각하는 키워드가 분명하다.
위의 그림은 쿠팡의 핵심가치이다. 핵심가치와 애자일의 철학은 비슷하게 닮아있다. 이 철학을 바탕으로 우리에게 가장 적합한 테크실행조직을 완성하였다. 회사의 핵심가치는 정말 중요하다. 실무자선에서 어떤 실행을 하더라도 핵심가치를 되새기면서 더 올바른 판단을 할 수가 있고 회사는 하나의 비젼으로 나아갈 수가 있다.
애자일 조직의 가장 기본이 되는 팀의 구성원은 다음과 같다. 팀은 self-organizing, self-manage를 통해서 최대한의 생산성을 낼 수 있도록 노력해야 한다.
Product Owner : 업무의 우선순위를 결정하고 백로그를 관리하는 역할
Scrum Master : 팀의 피플매니징을 하는 사람으로써 실제 팀의 실행을 리딩하는 역할
Makers
Developer : 개발자
Designer : 디자이너
function으로 모이는 조직으로 COP가 있다. COP는 기술중심의 모임으로 정기적/부정기적으로 만나서 프랙티스들을 공유한다. 각각의 COP에는 리더들이 있다. COP리더도 애자일팀에 속해서 업무를 하며 COP할 때 리딩하는 역할을 수행한다.
PO COP 비즈니스 목표와 의존성에 대해서 논의를 한다.
SM COP 실행 시에 팀간에 의존성있는 업무에 대해서 확인 및 프로세스 개선을 한다.
Design COP 디자인 가이드, 시안리뷰 및 피드백을 한다.
Tech COP 기술적인 프랙티스에 대해서 공유를 한다.
그림을 보면 일반적인 기업의 조직구조와 비슷해보이지만, 몇 가지 다른 원칙이 있다.
cross functional team function별로 조직이 되어 있지 않고 목적조직으로 되어 있다. 완결형 조직으로 목표수립부터 릴리즈까지 팀에서 실행이 가능해야 한다.
팀장이 없다. 일반적인 기술조직에서의 랩장/팀장/센터장/본부장과 같은 사람이 없고 경영진 아래 flat한 구조의 팀으로 구성이 된다. 기존에 matrix조직은 상하위 구조로 보고쳬계를 가지고 있지만, 애자일팀은 보고를 하는 대상이 없고 팀전체가 daily scrum을 통해서 업무를 공유한다.
팀은 9명이하로 제한한다. 팀의 사이즈를 제한하는 이유는 팀의 구성원이 많아지면 커뮤니케이션이 어렵고, 관료화될 가능성이 높아진다. 팀사이즈에 대한 이슈는 다음 글을 읽어보면 도움이 된다. http://www.ologist.co.kr/1013
QA조직이 별도로 없다. product의 품질은 애자일팀 내에서 책임을 가지고 준수를 해야 한다. 쿠팡에서 QA조직은 해체가 되어 각각의 애자일팀에 속해 있고 아웃소싱 TE들은 계약을 중단했다. QA들은 스스로 스터디를 하면서 점진적으로 프로그래머로 직무를 전환했다.
주제/이슈 중심으로 움직이는 써클의 모습니다. cross-functional한 조직으로 하나의 목적을 달성하기 위해서 조직화가 되고 목적을 달성하면 해체를 한다. 한국에서 일반적으로 TFT라는 불리우는 형태와 비슷하다.
위의 그림은 실제 애자일팀에 물리적인 형태 왼쪽이 팀이름이고 오른쪽은 실제로 하는 biz업무이다. 팀이름은 섬이름으로 작명을 하고 있고 팀의 목표를 달성하면 팀원들이 모두 여행을 간다는 취지에서 팀원들이 스스로 팀이름을 만든다.(현재는 위의 그림보다 훨씬 많은 팀들이 존재를 한다.)
아래는 쿠팡에서 하는 애자일의 전체 그림이다.
업무진행을 위한 timebox와 lifecycle이다.
PSI Planning objective를 설정하고 계획을 세운다.
PSI objective를 설정하고 실행하는 주기이다. 보통 PSI는 splint 3~4개로 이루어진다.
Splint Planning sprint에 대한 계획을 한다.
Sprint 애자일팀이 업무 실행을 하는 최소한의 단위이다.
Splint grooming 변경이나 이슈가 발생했을 때 재계획을 통해서 업무에 대한 가시성을 높인다.
Demo stakeholder에게 산출물을 보여주고 확인하는 시간이다.
Retrospective 회고를 통해서 팀이 성장할 수 있는 action plan을 수립한다.
Daily meeting 일단위로 진행하는 스탠딩 미팅으로 어제 한일/오늘 할일/이슈에 대해서 팀원들에게 공유를 한다.
기술적인 이슈
유저스토리 기반으로 개발이 가능하도록 full stack programmer를 지향한다. 모든 사람이 full stack일 필요는 없다. 하지만, 역할을 분장해서 설계/개발에서 릴리즈까지 팀에서 모두 해결이 가능해야 한다. 다만, 전체 애자일팀의 일관성을 위해서 플랫폼팀이 전체적인 아키텍처와 컨벤션을 가이드한다.
Practices
Continous Delivery
A/B Test
Pair Programming
Code Review
Deploy Plan
모든 팀이 항상 배포를 할 수 있지만, 배포의 충돌을 막기 위해서 태극기를 들고 있으면 그 팀에 배포가 가능하다. 아래는 작년에 장바구니 개발하고 오픈 위한 계획이다.
지만갑(지금 만나러 갑니다)
바쁜 일상생활 속에서 애자일조직원들이 지인들과 식사를 장려하고 지원하는 조직문화.
회고
팀은 주기적으로 회고를 하고 지속적인 개선을 통해서 성장을 합니다.
Clean Code Day
주기적으로 일정을 정해서 코드를 청소하는 시간을 가진다. 비즈니스 가치를 위해서 quickAndDirty를 하는 경우가 있는데 정리를 하는 시간이다. 참여한 팀 전체가 참여해서 오픈된 투표로 가장 성과가 높은 팀을 결정했다. 부상은 CTO님이 하사하는 회식비 :)
Team Building Day
볼링, 영화 등등의 활동과 맥주한잔과 함께 쌓이는 팀웍
CMD(catch my detail)
경영진이 아닌 현업부서와 개발자가 하고 싶은 일들을 백로그로 만들고 개발자가 능동적으로 선택을 해서 제품을 개발하고 리뷰(데모)를 하는 행사이다. 실제로 개발자들이 기획을 할 수 있다는 가능성을 보여줬고 멋진 아이디어들이 구현이 되었다. 문제를 해결하기 위한 요구사항을 전달했던 요청자들도 즐겁게 참여할 수 있었던 코딩파티였다.
coupang developer open house
쿠팡본사에 개발자들을 초대해서 쿠팡의 비젼과 철학을 알리고 경영진과 실제 근무하는 개발자들을 만나 볼 수 있는 시간을 갖었다.
continuous delivery
테크회사는 사람중심으로 일을 하다가 보니 조직의 포메이션과 문화적인 부분도 공개를 했는데, 기술적인 부분도 일부 공개합니다. 아래 그림은 기본적인 프로세스의 뼈대인 빌드/배포 프로세스에 대한 것도 간단하게 정리했습니다. 현재 쿠팡의 개발자는 플랫폼 개선뿐만 아니라 전반적인 서비스의 아키텍처 개선을 하는 비타민 프로젝트를 진행 중이며 이 부분의 디테일한 부분은 추후에 내부적인 논의를 통해서 방법을 마련해서 최대한 공유드리도록 드리도록 하겠습니다.
commit chart
우리는 완벽하지는 않지만 많은 부분을 측정하고 측정을 통해서 배우려고 한다. 아래는 우리 팀원들과 기획해서 만들어 본 팀별 커밋그래프이다. 아래 그래프만 가지고 배울 수 있는 부분이 적어서 다른 부분을 더 측정을 해보려고 한다. 개발프로세스상의 측정, 그리고 비지니스 사이드의 A/B Test와 같은 여러가지 측정방법을 시도하고 있다.
앞으로
예전에 Scrum master of scrum masters를 수행하면서 여러 팀들의 이슈에 대해서 공유를 받고 의견을 나누기도 했다. 내 눈에 문제점들이 보이기는 했지만 인위적인 행동은 가급적 피했고 경청을 하고 시스템을 만드려고 노력을 많이 했다. 대부분의 문제들은 시간이 주어지면 팀 스스로 문제를 해결을 해나가고 있었다. 물론 고질적으로 풀리지 않는 문제들도 있었지만 대부분 나쁜 습관에 관련된 것들이라 시간이 더 필요할 것으로 보였다. 약20개의 팀들이 미묘하게 다른 모습으로 팀웍을 만드는 것을 보면서 신기한 생각이 들었다. 대부분의 팀의 구성원들은 자신이 속한 팀이 최고라고 얘기를 하고 만족도가 높았다. 지금은 나보다 더 잘할 수 있고 집중할 수 있는 매튜 scrum master of masters를 모셔와서 나는 조직보다 쿠팡의 플랫폼을 담당하는 기술적인 업무에 더 집중을 하고 있다.
리얼 애자일은 대부분의 기업에서 만들기 어려운 구조이다. 기존에 있던 조직장들이 정치력과 권한들을 모두 내려두고 실무를 해야하기때문이다. 대부분의 기업들이 경영진에서 말단 사원에 이르기까지 많은 중간 관리자들이 있다. 이들이 권위의식과 기득권을 포기하고 동참을 해야하는 아주 어려운 선택을 해야 하는 것이다. 조직에 따라 다르겠지만 상당수의 조직장이 적응하지 못하고 회사를 떠날 수도 있다. 또한 조직장이 아니더라도 기존에 기득권과 권한을 가졌던 사람들은 적응하기 힘들어 할 수도 있다.
scaledagileframework을 바탕으로 애자일조직을 시작했지만 지속적으로 개선을 하면서 쿠팡만의 애자일을 만들어 가고 있다. 현재까지는 성공적으로 조직문화를 만들어가고 있지만 크고 작은 문제들이 지속적으로 발견이 되고 모두가 힘을 모아서 해결하고 있다.
우리 회사가 업무를 수행할 때 추구하는 철학,개념이다. 나는 테스트는 애자일의 심장이라고 얘기를 할 만큼 중요하다고 생각한다. 그리고, 데이터와 측정은 언제나/어디서나 중요하다.
- test, test and test
- measure anything, measure everything
지금 시점에서 우리가 앞으로 해결을 해야할 과제들은 다음과 같다.
- 기술셋별로 성장에 대한 로드맵
- 팀간에 커뮤니케이션 비용 최소화 및 의존성 줄이기(조직의 규모에 맞는 아키텍처 적용)
- 급격한 성장에 따라 빠르게 개발하면서 발생한 technical dept해결
- 자율적인 품질관리 강화
- 공정한 평가체계
- 비즈니스확장 및 시스템 고도화를 위한 인력채용
우리 쿠팡애자일조직은 오늘도 변화를 하고 있고 내일도 변화를 할 것이다. 현재의 조직문화가 더 성숙하고 완전한 문화가 될수 있도록 지속적인 개선을 해나가는데 지속적으로 기여를 하겠다.
현재 회사에 있는 모든 분들과 앞으로 쿠팡에 조인하게 될 동료들이 열정적으로 일을 할 수 있다면 우리가 한국의 아마존이 될 수 있을 것이다. 어렵겠지만 우리는 목표를 달성하기위해 끊임없이 기술을 발전시키고 노력을 할 것이다.
2012년 2월에 NHN에서 쿠팡으로 이직을 한 이후에 돈을 주고 살수도 없는 값진 경험들이 있었다.(벌써 2년이 넘었군요!) 회사의 비즈니스가 급격하게 성장하면서 회사 조직의 변화가 많았는데 특히 내가 속한 기술조직은 더 큰 변화가 있었다. 그 변화의 중심에서 능동적이고 창의적인 개발조직의 기본기를 만들기 위해서 쿠팡 내에서 여러 동료들과 함께 노력을 하였다.
나는 이전 회사에서도 애자일에서 나온 여러가지 프랙티스, 특히 XP진영의 프랙티스들을 실천하면서 만족도 있는 경험을 일부 했었다. 대부분 능동적인 개발자들과 일을 해서 배우는 것도 많았지만 조직적인 한계때문에 실질적인 애자일에 대한 경험을 해보지는 못했다. 조직적인 지원이 없는 반쪽 짜리 애자일도 충분히 해볼만한 문화였다.
대부분의 애자일러처럼 애자일 관련 서적을 수십권은 읽은 것 같다. 대부분 유사한 내용이었고 XP에서 Lean에 이르기까지 다양한 사례들도 볼 수가 있었다. 하지만, 쿠팡에 오기 전에 조직적인 문제때문에 경험적으로 제약이 있을 수 밖에 없었다. 전사적으로 전체가 같은 흐름으로 움직이는 실제적인 리얼 애자일은 쿠팡에서 첫경험을 하였고 이제 1년6개월이 훌쩍 넘었다. 조직문화라는 것이 완결형이 있을 수도 없기때문에 지금 시점에서 중간 공유를 하는 것도 의미가 있다고 생각을 했다. 그리고, 내 주변의 사람들이 쿠팡애자일에 대해서 많이들 궁금해하는 것 같아서 글로써 공유를 하려고 한다. :)
그 동안의 쿠팡에서의 경험은 기존에 책을 통한 애자일,스크럼과 프로그래머들만 한정적으로 몇 가지 프랙티스만 적용했던 것과 많이 달랐고 근본적인 철학에 대해서 실질적인 경험을 통해서 더욱 더 잘 이해를 할수 있게 되었다. 경험을 통한 학습에서 느끼는바지만 아는 것과 실행하는 것에는 큰 차이가 있다.
무엇보다 일을 잘하기 위해서는 기본기가 더 중요하다는 것을 깨달았다. 기술역량,커뮤니케이션,체력,강한 멘탈,지속적인 학습/개선 그리고 성장은 필수적인 기본 요건이다. 체력이 좋지 않으면 멘탈이 무너지기 쉬우므로 운동도 꾸준히 해야 하는 것도 알았고 스트레스를 이겨내는 스킬도 반드시 가져야 한다고 생각한다. 인터넷의 발달로 많은 기술과 지식이 실시간으로 공유되는 시대로 패러다임이 빠르게 변화를 하고 있다. 지속적인 학습과 자기개선은 매우 중요하다.
여러가지 프로세스와 프랙티스를 만들고 내재화를 해가면서 부딪히는 문제들은 대부분이 사람이슈였는데 이 경험들을 통해서 나를 더 잘 알게 되었던 것도 큰 소득이었다. 이제 쿠팡에 애자일을 적용한지도 이제 1년정도 시간이 지났고 지금까지 걸어온 길에 대해서 현재 상태를 공유를 하고자 한다.
개발조직문화의 변화
기업이 조직문화에 관심을 가지고 막대한 비용을 들이면서 만드는 이유는 무엇일까? 일이 되게 하는 조직구조는 어떤 구조일까? 오래 전부터 관심을 많이 가져오는 주제였고 이전 회사 NHN에서 팀장을 하면서 팀원들과 함께 여러가지 시도를 해보기도 했다. 물론 개발조직만 관심을 가지고 실행을 해본 것은 한계점이라 할 수 있다.
쿠팡에 조인을 한 뒤 여러가지 시도를 해보고 변화를 만드려고 많은 애를 썼지만 더디게 변화가 있었고 기존에 다니던 회사와 쿠팡의 비즈니스 환경이 많이 달라서 업무프로세스의 변화와 조직문화를 만들기 쉽지 않았다. 개발조직의 문화를 만든다는 것이 개발조직만의 노력으로 되는 것도 아니었고 사업적인 요구사항은 내가 예상한 것보다 훨씬 빠르게 증가를 하고 있었다. 개발문화를 지속적이고 점진적으로 변화를 만들어서 부작용을 최소화를 하기 원했지만 비즈니스의 흐름을 따라가기 어려웠고 그 단계에서 많은 동료들이 힘들어하고 나도 지쳐가고 있었다.
조직문화 관점에서 점진적인 변화도 좋지만, 큰 패러다임의 전환이 필요한 시점이었다. 가장 개선이 시급한 것은 우리의 비젼과 전략에 대한 공감, 우선순위에 맞는 업무들, 그리고 합리적인 업무량이었다. 그 시점에 경영진 주도하에 전체 애자일 적용으로 조직문화를 한번에 바꾸게 된다. 컨설팅과 교육을 받으면서 참여자들의 이해를 높이고 물리적인 조직개편도 함께 실시를 하였다.
작년 7월에 재성이형이 썼던 글이다. 이 글로 인해서 쿠팡의 개발조직이 뭔가 변화를 한다는 것이 업계에 알려지게 시작한거 같다. 그 때는 애자일조직으로 조직개편을 하고 막 시작하는 시점이었다.
비즈니스 환경의 변화
흥하는 기업의 10대 전조에 보면 첫번째로 나오는 것이 "전직원이 현장을 한다."라는 것이 있다. 이 의미는 대표부터 시작을 해서 말단 사원까지 현장에서 실무를 한다는 것이다. 어떻게 하면 실무자 중심의 업무를 진행할 수가 있을까? 그리고 기업이 지속성장이 가능하려면 어떻게 해야 할까?
회사에서 수익을 만드는 비즈니스 모델에 대한 얘기를 하자면 더 어려워진다. 최근에 기업들을 보면 평생 많은 수익을 많이 낼 것 같은 회사들도 무너지고 새로운 신생기업들도 계속 생겨나고 있다. 어떤 혁신으로 신생기업들이 생겨나는지, 기존에 기업들은 어떻게 지속적으로 성장을 하고 있는지 알아야 한다. 대부분 기본적이고 근본적인 문제들을 나이스하게 해결하는 기업과 시장에 상황에 따라서 빠르게 변화를 만들 수 있는 기업들이 오랜 세월동안 장수를 하고 있었다.
애자일의 철학은 빠르고 변화를 많이 요구하는 현대의 비즈니스 환경에 잘 맞아떨어진다. 애자일은 사회적인 변화에 능동적으로 대응이 가능하고 변화를 만들어 낼수 있는 최선의 선택이다. 우리는 변화를 인정하고 기민하게 반응하기 위해서 선택한 것이 애자일이다.
본격적인 얘기를 시작하기 전에 먼저 쿠팡의 애자일 조직문화를 엿볼수 있는 개발자 채용 홍보 영상을 보자. 작년에 유행했던 쿠팡자바맨 동영사이다. 주위에서는 2탄을 기대할 정도로 많이 알려진 영상이다. 자세히 보면 다수가 등장한 장면에 저도 잠깐 나옵니다..^^;
<에필로그>
요즘 긴글을 잘 안쓰다가 보니 블로그에 임시저장을 해두고 발행을 하지 않은 글이 꽤 많다. 이 글도 그 중에 하나인데 주변의 사람들이 쿠팡과 애자일, 그리고 조직문화에 관심이 많아서 선배포 후에 연재 또는 수정을 하려고 한다...^^
if (action.equals("create")) {
String id = request.getParameter("id");
String name = request.getParameter("name");
String salary = request.getParameter("salary");
bean.createEmployee(Integer.parseInt(id), name,
}
// ...
}
}
코드작성 시에 문제가 될만한 것을 피하는 것이 좋다. 위에 코드는 그 중에 하나를 어긴셈인데, if문의 조건을 비표하는 순서이다. 외부에서 "action"이라는 파라미터명으로 값을 전달 받았는데 비교하는 구문이 action이 널이면 예외가 발생할 수 있는 코드가 될 수도 있다. 이 경우 아래처럼 코드를 작성하는 것이 좋은 습관으로 보인다.
Listing 3-30. Using the EmployeeService Session Bean from a Servlet
public class EmployeeServlet extends HttpServlet {
쿠팡에는 한달에 한번 팀빌딩을 위한 행사를 할 수 있도록 오후5시에 조기퇴근을 하는 제도가 있다.(평소는 오후 6시30분 퇴근) 대부분의 팀은 영화관람, 볼링 등등을 하면서 팀워크를 다진다. 우리 팀은 특별한 취미(?)는 없고 해서 그 동안은 주로 술을 마시면서 팀워크를 다졌는데 이번에는 독특한 시도를 해봤다.
"코딩하는 쿠요일이다."
저녁을 맛나게 먹고 시원하고 물좋은 커피솝에서 가서 코딩을 하는 것이다. 랭귀지부터 개발플랫폼까지 모두 생소한 것을 가지고 해보는 것이었다.그냥 단순 코딩을 하면 의미가 적으니 평소에 사용하고 싶은 기술을 가지고 세상에 가치가 있는 것을 만들어보자는 것이 취지였다. 세상까지는 아니더라도 회사 내에서도 가치를 만들어 낼 수 있는 것은 얼마든지 많다.
예전에 팀내에서 잡담을 하다가 나왔던 주제를 가지고 계획은 세우고 커피솝에 갔지만 하루종일 서스이슈로 지쳐있던 상태였고 실제로 집중력을 발휘할 수 있을지 의문이었다. 초반에 릴렉스하게 앉아서 얘기를 하면서 시작포인트를 못잡고 있는 상황이었다. 키튼님이 갑작스런 일이 생겨서 먼저 일어나시고 얼마 되지 않아서 갑자기 누구랄 것 없이 노트북에 개발환경을 셋팅하기 시작했다.(키튼님 먼저 가셔서 아쉬웠음)
개발환경을 셋팅 후에 랭귀지 특성에 맞게 웹개발에 필요한 기본적인 코드들을 작성해보기 시작했다. 신규입사자로 우리팀에서 OJT를 하던 2분이 있었는데 같이 구경을 하다가 먼저 가시고 남은 우리들은 기본적인 개발환경까지 갖추는데 성공을 하였다. 목적 달성을 위한 기획도 만들려는 시스템 도메인의 이해도가 높은 나하고 찰리하고 초안까지 작성을 하였다. 짧은 순간 많은 집중을 해서 상당히 많은 진도를 나갈 수가 있었다. 놀이처럼 개발환경설정처럼 코딩을 하고 나니 오늘 쌓였던 스트레스들이 다 풀렸다...ㅎㅎㅎ (신규입사자 2분에게는 좀 미안했지만 담주에 술한잔하는 것을 하고;;)
코딩하는 쿠요일은 색다른 경험이었다. 코딩을 하면서 쉴 수 있다는 좋은 경험을 가지게 해준 우리팀이 참 고맙다. 멘탈이 강하고 건강한 우리팀은 정말로 좋은 팀이다. 업무를 진행할 때 항상 정도를 걷기 위해서 많은 어려움이 있지만 타협하지 않는 우리팀이 자랑스럽다. "아발론팀 파이팅"
클래스가 너무 커지거나 extract method를 하다가 보면 private 메소드가 나오게 된다. 대부분 이런 경우는 그 클래스에 맡은 역할이 많아서 발생하는 경우가 많다. 이 경우에 context나 role이 묶이는 메소드들이 있는데 명시적으로 extract class를 하자.
http://refactoring.com/catalog/extractMethod.html
기존에 클래스에 테스트 코드가 있으면 extract class를 한 후에 테스트를 실행해보면 문제가 있는지 없는지 바로 알수 있다. 없다면 테스트케이스를 반드시 만드는 것이 좋다. 문제가 없다면 새로 생긴 클래스쪽으로 테스트 작성을 옮기고 기존에 클래스의 테스트는 제거를 한다.
extract class를 통해서 새로 생긴 클래스에서 테스트를 보강하고 role에 맞게 flow를 개선해서 가독성을 높이는 작업을 한다.
긴 메소드 안에 변수들이 얼마나 쓰이는지, 어떤 의존성을 가지는 지 판단하기가 어려운 경우가 있다. 이런 경우 eclipse나 intellij는 더블 클릭을 하면 코드 내에서 사용하는 블럭들을 표시해준다. 눈에 잘 들어오지 않으면 변수들을 주석처리하면서 에러를 발생시키면서 눈으로 확인을 해본다.
전체적인 메카니즘에 대해서 이해를 하고 충분한 역할단위로 블럭이 만들어지면 주석단위 위주로 extract method를 한다. extract method를 할때 가장 중요한 것은 flow가 보이고 symmtery에 맞추어서 추출을 하는 것이다. 그리고, extract method를 할 때 collecting paramter는 메소드 간에 의존성을 끌고 가는 경우가 생기므로 가급적이면 사용하지 말아야 하지만 필요한 경우도 있다.
애자일 조직에서 1년이상 근무를 하면서 가장 마음에 드는 규칙 중에 하나가 팀의 크기를 9명이하로 유지를 하는 것이다. 현재 우리 팀원은 5명인데 팀의 목표를 만들고 실행할 때 모두의 의견을 듣고 바반영할 수 있고 집중력이 좋다. 업무 시 발생하는 대부분의 이슈들을 같이 공유하면서 업무가 진행이 되고 식사나 티타임에도 모두가 같이 움직이기 편하다.
