애자일 실천 사례 - XP 편
Pivotal Labs SF에서 살펴본 SW 개발 문화 이야기
본 글은 필자가 작성한 애자일 관련 글 중 5번째로 작성한 글이며, 앞 글의 연장선상에 있음을 먼저 밝힌다.
https://brunch.co.kr/@insuk/17
이번 글에서는 앞 글에서 설명한 내용 중 다소 분량이 적었던 애자일 관련 이야기를 풀어 쓸까 한다. 이 내용 역시 필자가 샌프란시스코의 Pivotal Labs에서 보낸 3개월의 경험담 및 당사에서 공유가 가능한 자료들로 구성해 보았다. 아마도 전 세계에서 가장 독보적인 애자일 개발 문화를 정착 및 유지, 전파하고 있는 유일한 곳이 아닌가 싶다. 이런 내용들이 국내의 소프트웨어 개발 문화에 좋은 본보기가 되었으면 하는 바람이다.
그럼, 시작해보자.
필자가 발행한 예전 글(1부, 2부)에서는 애자일 방법론의 여러 도구 중 가장 흔하게 접할 수 있는 애자일 도구인 스크럼에 대해서 알아보았다.
스크럼은 프로젝트를 진행하는 프로세스에 대한 도구이다 보니, 소스 코드를 작성하는 방법과 같이 기술적인 부분은 다루지 않고 있다. 사람과 사람이 모여서 소프트웨어 개발을 할 때 어떤 업무 프로세스를 적용해야 커뮤니케이션 비용을 최소화하면서 투명성을 높이고 리스크를 최소화하는 여러 가지 기법들을 소개하고 있는 방법들을 모아놓은 도구 세트 인 셈이다.
하지만 이런 방법들로만 가지고는 소프트웨어 개발의 엔지니어링 측면의 도움을 주기에는 어렵다. 가령, '우리 프로젝트의 소프트웨어 품질을 높이기 위해서 어떤 것들을 해야 하나'라는 질문에는 스크럼을 통해 답을 찾기 어렵다는 뜻이다. 이러한 유형의 질문에 오래전부터 명쾌한 답을 준 도구가 있다. 자바 단위 테스트 도구인 JUnit의 창시자, 켄트 백 아저씨가 주창한 XP(eXtreme Programming)가 바로 그것이다.
켄트 백 아저씨는 1999년에 발표한 'Extreme Programming Explained - Embrace Change'라는 책에서 XP를 발표하였고, 현재 해당 책은 2004년에 Second Edition이 나온 뒤로 현재까지 많은 소프트웨어 개발 조직의 이정표 역할을 하고 있다. 국내에는 인사이트에서 2006년에 '익스트림 프로그래밍'이라는 이름으로 번역이 되었다. 애자일 필드에서 잘 알려지신 김창준 님께서 번역에 참여하셨다.
XP에 대한 개념이나 원칙에 대한 글들은 인터넷에 많이 있으니 넘어가도록 하겠다. (위키피디아 한글 링크: https://ko.m.wikipedia.org/wiki/익스트림_프로그래밍)
그럼 Pivotal Labs에서 지키고 있는 XP 기법들은 어떤 것이 있을까? 하나하나 살펴보자.
함께 앉는다 (Sit Together)
Pivotal Labs 사무실 전경 (출처: https://www.wired.com/2013/11/pivotal-one/)위 사진은 Pivotal Labs SF 사무실의 모습을 보여주고 있다. 보다시피 파티션이 전혀 존재하지 않는 오픈 스페이스에 모든 팀원이 모여 앉아 있다. 작은 프로젝트는 5~6명 정도이니, 위 사진에도 여러 프로젝트가 진행되고 있음을 알 수 있다. 자세히 살펴보면, 테이블 위에 전화기가 보이질 않는다. 이는 전화조차도 제품 개발에 방해가 되기 때문이다. 대신, 전화기가 있는 작은 크기의 개인 공간을 제공한다.
이러한 열린 공간은 함께 일하는 사람 간의 커뮤니케이션 비용을 줄여주고, 팀원들이 어떤 일에 집중하고 있는지 쉽게 알 수 있게 해주며, 이슈나 궁금한 사항이 생겼을 때 짧은 시간 내에 해결해주는 데 기여한다. 대신, 사무실이 무척 시끌벅적하다. :)
페어 프로그래밍 (Pair Programming)
필자가 Pivotal Labs의 PM과 Pairing을 하던 모습Pivotal Labs에는 크게 3개의 롤이 존재한다. 제품 관리자(Product Manager, PM), 제품 디자이너(Product Designer, PD) 그리고 개발자(Developer, Dev)가 바로 그것이다. Pivotal Labs에서는 이 3개의 롤을 가진 팀원들이 모두 하루 종일 페이링(Pairing)을 한다. 즉, 짝을 이루어 하루 종일 같은 컴퓨터를 사용하면서 일을 한다. 보통, 개발자간의 페어 프로그래밍(Pair programming)은 어느 정도 익숙하지만, PM, PD를 페이링하는 것은 무척 생소한 일이 아닐 수 없다. 이는 Pivotal Labs의 독특한 문화 중 하나로 일반적으로 고객과 프로젝트를 수행할 때, 교육이나 세미나를 제공하지 않고, 페어링을 통해 실제 업무를 함께 수행하면서 다운로드하기 위함이다. 또한, 팀 내에서는 특정 인력에게 의존성이 생기는 것을 방지한다. 만약, 누군가가 프로젝트를 떠난다면, 인수인계를 할 필요가 없다. 왜냐하면, 다른 짝이 같은 일을 해왔기 때문이다. 누군가가 새로 투입된다면, 페어링을 통해 빠른 시일 내에 업무를 파악할 수 있다.
또, 하나의 재미있는 부분은 개발자인 경우 매일 짝을 바꾼다는 것이다. 이는 소스 코드의 오너십은 특정 사람/페어가 아니라 팀에 있으며, 특정 개발자만이 혼자 개발하는 소스는 없어야 하기 위함이다. 필자가 개발자 역할을 할 때 이 부분이 잘 될까 하는 의구심이 들었으나, 막상 해보면 그리 어렵지 않다. 그리고 배우는 것이 갑절이 되는 느낌을 가졌다. 대신, 개발 속도 측면에서는 조금 떨어질 수도 있겠으나, 나중에 문제가 생겨서 담당자가 아니면 고치지 못하는 상황이 벌어지는 것을 생각해보면 충분히 감내할 수 있는 수준이라고 생각한다.
Pivotal Labs의 역할 관련해서는 다음 글에서 자세히 다뤄 볼 예정이다.
스토리 (Stories)
Pivotal Labs에는 스크럼의 스크럼 마스터와 같이 방법론 가이드를 위한 퍼실리테이터가 없다. 모든 팀원이 그 역할을 하고 있다고 볼 수 있다. 대신, Pivotal에서 만든 PivotalTracker라는 도구를 적극 활용한다. 이는 프로젝트 관리 도구로 잘 알려진 Atlassian Jira나 Redmine과 비슷한 도구이다. 이 녀석이 퍼실리테이터 역할을 한다고 볼 수도 있겠다.
PivotalTracker는 사용자 스토리를 작성하고, 구현 복잡도 기반으로 크기를 산정해서 표기 한 다음, 우선순위를 정하여 순서대로 팀이 일을 진행할 수 있게 도와준다. 이때 작성된 사용자 스토리는 사용자 입장에서 작성이 되어야 하며, 최대한 자세히 기술이 되어야 한다. 아래 예시를 살펴보자.
기능을 나타내는 User Story 작성 예제 (출처: PivotalTracker 블로그)제목에는 제품을 사용할 엔드 유저를 구체화한 페르소나의 이름을 사용하여, 사용자 입장에서 작성을 하였다. (예: Frank는 다른 사람을 친구로 추가할 수 있다.)
Description 부분에는 상세한 정보가 기입된다.
제목을 자세히 서술한 내용이 추가되고, PM이 스토리가 마무리되었다는 것을 확인하기 위한 인수 테스트 조건이 기입된다.(GIVEN, WHEN, THEN)
스토리상에 Dev나 PD에게 전달할 사항이 있다면 함께 기입한다.
그리고 해당 스토리에 대한 화면 디자인을 댓글에 PD가 입력함으로써, Dev가 개발을 진행하기 위한 구체적인 정보를 제공한다.
상세한 스토리 작성에 대한 가이드는 PivotalTracker 블로그에 필자와 페이링을 하였던 Ryan Johns라는 친구가 작성한 아래의 글을 참고하기 바란다.
https://www.pivotaltracker.com/blog/principles-of-effective-story-writing-the-pivotal-labs-way/
주 단위 사이클 (Weekly Cycle)
Pivotal Labs의 이터레이션은 기본적으로 1주이다. PivotalTracker의 default iteration도 1주로 되어 있다. 해서, 매주 월요일 오전에는 IPM(Iteration Planning Meeting)을 통해 향후 2~3주 정도 수행이 가능한 백로그의 크기를 산정하고, 우선순위 하는 작업을 수행하며, 금요일 오후에는 회고(Retrospect, Retro)를 통해 한 주 동안 좋았던 일, 그저 그랬던 일, 나빴던 일 들을 나누고 다음 이터레이션을 위한 Action Item을 도출한다. 필자는 기존에 3주 정도의 이터레이션을 수행해 본 적은 있으나, 한 주 단위의 이터레이션을 돌려보는 것은 처음이었고, 우려가 컸다. 하지만, 한 주 단위의 프로세스가 점차 몸에 익숙해지면서, 훨씬 업무를 수행하는 데 도움이 되는 것을 느꼈다. 좋은 리듬이 생겼다고나 할까.. 팀의 속도(Velocity) 측정도 간편해졌고, 이슈의 도출도 더 쉬워졌다.
휴식 (Slack)
Pivotal Labs 사무실 한 켠에 있는 탁구대에서 탁구를 치는 Pivotal Labs 직원들Pivotal Labs의 인력들의 집중력은 놀라운 수준이다. 업무 시간에는 철저하게 업무에만 온 에너지를 쏟아붓는다. 그러다 보니, 틈팀이 휴식을 취해야만 한다. 이를 위해 언제든지 사용이 가능한 탁구대가 비치되어 있고, 실제로도 하루 종일 탁구대에 사람이 붐빈다. 식당에는 꽉 채워져있는 냉장고에 각종 음료들이 들어있고, 간단한 스낵이나 견과류, 초콜릿등이 항상 선반에 꽉 채워져 있다. 주방 한켠에 있는 맥주와 와인들도 언제든지 꺼내 먹을 수 있다.
지속적 통합 (Continuous Integration, CI)
CI는 이제 어디서나 기본인 듯싶다. 필자의 프로젝트는 모든 소스 코드 및 배포 환경이 클라우드상에 있었다. 해서, 소스 코드를 Github.com에 push 하고 나면, 자동으로 CI 툴이 이를 감지하여 전체 빌드 및 자동화 테스트를 수행한 뒤, 타겟 서버로 배포가 되게 하였다. 필자는 그 당시 CircleCI라는 도구를 사용했었고, 매 빌드 시마다, 리눅서 서버 자체를 초기화하여 생성한 뒤, JVM 설치부터 실행이 되며, 모든 단위 테스트 및 통합 테스트를 수행한다. 혹시라도 변경한 사항에 대한 side effect가 있어 테스트가 정상 수행되지 않으면, 바로 해당 로그를 포함한 에러 보고서를 메일로 받을 수 있다.
테스트 주도 프로그래밍 (Test-First Programming)
이는 오늘날 Test-Driven Development, TDD로 잘 알려진 부분이다. 모든 기능에는 단위 테스트 코드가 반드시 먼저 작성이 되어야 한다. 필자 같은 경우는 백엔드는 JUnit으로, 프론트엔드는 Jasmine을 활용하였다. 백엔드는 개발하고자 하는 모든 public 함수에 대해서는 테스트시에만 활용하는 가상 데이터 기반으로 내가 원하는 반환 값을 반환하는지 테스트해야 한다. 프론트엔드는 웹 브라우저상에 보이는 것들을 HTML을 파싱 하여 내가 원하는 대로 보이는 지 테스트해야 한다. 단순 텍스트도 있겠지만, 테스트 데이터에 따라 색이 변경되는 경우나, 이벤트가 원하는 대로 실행이 되는지 테스트할 수 있다. 통합 테스트 역시 사람이 수작업으로 하던 기능 테스트를 phantomjs와 같은 headless 브라우저를 통해 자동으로 테스트해 볼 수 있다. 이러한 테스트 케이스 작성은 개발자에게 본인이 수정한 것이 다른 소스에 영향을 미치는지 쉽게 확인할 수 있으며, 개발자에게 본인의 작업에 대한 자신감을 확보할 수 있다.
점증적 디자인 (Incremental Design)
앞 글에서도 언급하였지만, Pivotal Labs에서는 소프트웨어 구현을 하기 전에, 심지어는 사용자 스토리를 작성하기 전에 정성적 사용자 연구를 통해 최종 화면을 검증할 수 있다. 하지만, 처음부터 제품 전체에 대한 디자인을 수행하는 것인 비효율적이다. 왜냐하면, 모든 것이 바뀔 수도 있기 때문이다. 해서, 현시점에 가장 중요도가 높은 최소 기능 요건 제품에 대한 디자인에만 집중한다. PD만이 아니라, PM, Dev가 모두 모여 팀 단위로 와이어프레임(Wireframe)을 작성한 다음, 인터뷰를 통해 이 와이어프레임의 적합성을 검증한다. 검증이 되었다면, PM은 해당 디자인을 위한 사용자 스토리를 작성하고, 그 뒤에 Dev가 구현을 시작한다. 이때 PD는 다음 단계의 디자인 작업을 진행하고, 조금씩 조금씩 살을 붙여 나간다.
지금까지 필자가 XP 실천 관점에서 바라본 Pivotal Labs의 모습을 살펴보았다. 작성하다 보니 조금 더 상세하게 쓸 만한 내용도 여러 개 도출이 된 듯하다. 댓글에 더 자세히 듣고자 하는 내용이 있다면 꼭 남겨주기 바란다.
오늘도 더 좋은 SW 개발 문화 만들기에 한 걸음 더 다가갔기를 바란다. :)
* 참고자료: Extreme Programming Explained - Embrace Change(2004, Second Edition)
