개발자가 가장 행복할 때는 개발에 집중할 수 있을 때다. 화창한 아침 기분 좋게 출근해서 어제 작업하던 화면을 하나씩 불러온다. 모니터에 코드가 적힌 편집툴이 하나씩 올라오고 머릿속에도 관련 기능 개발을 위한 자료 구조와 알고리즘이 하나씩 ‘로드’된다. 이 데이터는 이쪽, 이 부분은 이렇게 로직을 짜봐야지. 집중해서 코드를 짜고 있으면 어느새 모니터 외에는 아무 것도 보이지 않는다. 이러다 보면 누군가 어깨를 두드린다. “점심 먹으러 가요.”
많은 개발자가 이런 순간을 행복하게 느낀다. 집중해서 일할 때 느끼는 엔도르핀은 초콜릿 5개를 한꺼번에 입에 넣었을 때보다 덜하지 않다.
상황을 조금 바꿔보자. 집중해서 코드를 짜려는 데 누군가 어깨를 두드린다. “회의좀 하죠.” “요구사항 명세서는 다 작성했나요?” “새로 개발하는 기능은 언제까지 가능한가요? 사실 다음주까지 끝내야 하는데…” “저번에 말한 그 기능에 이것좀 추가해줄 수 있나요?”
어깨를 두드린 분의 심정을 이해 못하는 건 아니다. 상황이 어쩔 수 없다는 것도 안다. 소프트웨어가 가진 본래 특성에 따라 복잡성을 다루는 게 쉽지 않기 때문에 사실 개발자가 행복하게 개발할 수 있는 상황을 만들기는 쉽지 않다.
하지만 계속해서 이렇게 힘들게 살아야 할까. 아마도 아닐 것 같다. 그동안 많은 사람들이 이 같은 문제를 겪어왔고 상황을 타개하려고 노력해왔다. 수많은 개발 방법론과 도구가 등장했고 개발 패러다임 역시 마찬가지로 진화해왔다. 그렇다면 앞서 일궈놓은 유산을 바탕으로 좀더 나은 환경을 우리도 만들 수 있을지 모른다.
◇ 애자일 소프트웨어 개발=개발자나 관련 분야 종사라면 한번쯤 이 ‘쿨내’ 진동하는 단어를 들어봤을 것이다. 기민한 소프트웨어 개발이라니. 이 얼마나 멋진 말인가. 하지만 사실 이 쿨한 이름과 달리 애자일에 대한 얘기는 꽤 오래 됐다. 어떻게 하면 이 지긋지긋한 소프트웨어 복잡성을 덜어낼 수 있을지에 대한 고민이 서로 다른 이름으로 하나씩 정리되어 왔다. 그러던 중 2001년 켄트 벡, 마틴 파울러, 로버트 마틴, 제프 서덜런드 등 이름만 봐도 쟁쟁한 리더가 한 스키장 리조트에 모여 애자일 선언문을 작성한다.
애자일 선언문(Agile Manifesto. 출처)
우리는 소프트웨어를 개발하고 또 다른 사람의 개발을 도와주면서 소프트웨어 개발의 더 나은 방법들을 찾아가고 있다. 이 작업을 통해 우리는 다음을 가치 있게 여기게 되었다:
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를
가치 있게 여긴다. 이 말은 왼쪽에 있는 것들도 가치가 있지만 우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
애자일이라는 말에서 알 수 있듯 애자일 선언문은 속도에 집중한다. 다만 단순히 속도에만 집중하는 게 아닌 일이 되게 만드는 속도에 집중한다. 간단하게 식사하겠다고 분식집에 김밥 먹으러 온 손님에게 최고의 식사를 대접하겠다며 재료 손질부터 하면 손님은 이미 떠나고 없을 터. 그게 설사 최고의 김밥이라도 말이다.
애자일을 말할 때 자주 혼동하는 게 있다. 애자일은 방법론인가 혹은 프로세스인가. 그렇지는 않다. 애자일은 RUP나 SPICE, CMMI 프로세스처럼 정형화된 개발 단계와 산출물이 존재하는 프로세스가 아니다. 애자일 선언문에서도 볼 수 있듯 소프트웨어를 개발하면서 어디에 더 중요한 가치를 둬야 할지에 대한 철학이라고 할 수 있다. 말이 쉽지 않게 들릴 수 있다. 이들을 위해 애자일 선언문 작성자들은 12가지 원칙을 들어 다시 설명하고 있다.
애자일 선언 이면의 원칙
1> 우리의 최우선 순위는 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
2> 비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
3> 작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.
4> 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.
5> 동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.
6> 개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화다.
7> 작동하는 소프트웨어가 진척의 주된 척도다.
8> 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.
9> 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.
10> 단순성이 (안 하는 일의 양을 최대화하는 기술이) 필수적이다.
11> 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.
12> 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고 이에 따라 팀의 행동을 조율하고 조정한다.
애자일 선언문과 이를 실천하기 위한 12가지 원칙은 가장 이상적이고 기민한 소프트웨어 개발을 지향한다(개발자를 위한 십계명 ‘애자일 선언문’).
물론 중요한 건 실천이다. 애자일은 십이계명이지만 마치 십계명과 같은 이 원칙에 따라 실제 필자가 근무 중인 기업(버즈빌)에선 어떻게 일하고 있는지 살펴본다. 이미 실천 중인 좋은 경험은 그림에 표시했다. 굳이 내용을 하나씩 언급하면서 교과서적인 내용을 서술하는 것보다는 실제로 12원칙에 얼마나 가까운지 살펴보는 게 더 의미가 있을 것 같아서다. 그림 속 빨간색 네모 박스는 실천 중이거나 도입 중인 부분.
- 우리의 최우선 순위는 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
소프트웨어가 필요한 이유는 고객이 존재하기 때문이다. 아무리 멋지고 훌륭한 제품을 만들어도 이를 사용할 고객이 없다면 아무런 가치가 없다. 버즈빌의 고객은 크게 4개로 나눌 수 있다. 잠금화면 유저와 광고주, 퍼블리셔, 오퍼레이터가 그것. 이들 고객에게 필요한 가치는 다양하다. 질 좋은 광고나 콘텐츠를 통한 유저 경험 극대화, 고도화된 타깃팅을 통한 광고 효율 향상, 안정적 서비스를 통한 수익 창출, 오퍼레이션 편리성 등 다양한 요구가 있는 것.
고객은 너그럽지 않다. 이런 고객 가치를 온전하게 제공할 수 없다면 고객은 기다려주지 않는다. 유저는 서비스를 떠날 것이고 광고주는 더 이상 광고를 주지 않는다. 퍼블리셔는 서비스를 믿을 수 없어 사업을 포기할 수도 있고 오퍼레이터는 지루하고 복잡한 작업으로 떠나버릴 수 있다.
따라서 이런 가치를 측정할 수 있는 데이터를 수치화해서 실시간으로 모니터링한다. 빠른 배포와 피드백을 통해 지속적으로 고객을 만족시키려 노력한다. 그 어떤 것보다 이보다 우선할 수는 없다.
- 비록 개발 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스는 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
개발자 입장에서 요구사항 변경은 그리 반가운 일이 아니다. 기껏 애써서 설계와 구현을 해놨더니 그간 노력이 까만 화면 위 글자 뿐인 아무 가치 없는 낙서로 남게 될 상황은 아무도 좋아하지 않을 것이다. 하지만 요구사항은 바뀌기 마련이다. 고객은 스스로 뭘 원하는지 모를 수 있고 비즈니스 상황에 따라 더 이상 필요 없거나 바꿔야 할 수도 있다.
인정해야 한다. 요구사항은 자주 변한다. 심지어 제품이 출시된 이후 변할 수도 있다. 이런 현실을 극복하려면 어떻게 해야 할까. 일단 문제를 나눠보는 게 좋다.
◇ 요구 사항 인입과 정제=요구사항 인입 초기에는 서로간 이해하가 좀더 분명해야 오해를 줄일 수 있고 요구사항 변경 역시 덜해질 수 있다. 개발팀으로 오는 모든 요구사항은 Product Manager (PM)을 통해 이뤄진다. 제품 관점에서 가장 폭넓게 이해하고 있는 PM은 고객 요구사항이 정확하게 뭔지 다시한번 정제하고 필요하다면 개발자와 상의해 구현 가능 여부를 검토한다.
이를 통해 요구사항이 좀더 구체화되면 불확실성과 모호성이 사라진다. 버즈빌의 경우 PM은 모두 4명. 엔드유저와 광고주 혹은 광고시스템, 퍼블리셔와 제품 고도화로 나뉜다. PM이 대응하는 고객에 따라 요구사항 인입과 정제 방식도 다르다. 정리된 요구 사항은 매 스프린트 계획 회의 전에 재정리되어 제품 백로그에 우선순위에 따라 나열된다.
◇ 요구사항 개발과 확인=제품팀에 요구사항을 제기한 사람은 본인이 요청한 사항이 어떻게 진행되고 있는지 항상 확인할 수 있다. 개발팀 스크럼보드는 개발팀 뿐 아니라 모두에게 공개되어 있다. 스크럼보드는 트렐로(Trello)를 통해 관리한다. 카드마다 구체적 내용을 담을 수 있어 카드를 통해 얼마든지 논의할 수 있다. 개발 중인 내용은 카드를 통해 진척사항을 기록하고 PM이나 요구사항 발주자 역시 개발 사항에 대한 질문을 요구할 수 있다. 큰 틀에서 벗어나지 않는다면 요구사항 변화는 이 카드를 통해 적응할 수 있다.
- 작동하는 소프트웨어를 자주 전달하라. 몇 주에서 몇 달 간격으로 하되 더 짧은 기간을 선호하라.
앞서 밝혔듯 고객 요구사항은 변화무쌍해 언제 어떻게 바뀔지 모른다. 따라서 가능하면 빨리 고객 피드백을 받고 이를 다시 제품에 반영할 수 있어야 한다. 이를 위해 배포하는 방법은 쉽고 자동화되어 있어야 한다. 지속 통합, 나아가 지속 배포가 해답이 될 수 있다.
모든 소프트웨어 자산은 깃허브를 통해 형상 관리를 하고 브랜치마다 마스터에 머지하기 전 젠킨스(Jenkins)를 통해 필수 테스트를 자동으로 거친다. 물론 새로운 기능에 대한 유닛 테스트도 새로 작성될 수 있고 Continuous Integration(CI) 과정에 포함된다. 무중단 배포, 빌드 버전, 라이브러리 패치 등 배포 스크립트 대부분은 패브릭(Fabric)을 통해 자동화한다. 개발자가 할 일은 개발을 마친 뒤 명령어(fab deploy)만 실행하는 것이다.
최근에는 형상관리 시스템에 코드를 푸시하는 것만으로도 배포까지 되게 자동화하는 작업을 진행 중이다. 배포가 간결하고 쉽기 때문에 작은 변경에 대한 배포를 자주 할 수 있고 그만큼 고객 피드백은 더 빠르게 받을 수 있다.
- 비즈니스 쪽 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.
필자의 회사에는 특이한 문화가 있다. 2달마다 한번씩 제비뽑기를 해서 이후 2달 동안 근무할 자리를 정하는데 예외없이 모두에게 해당된다. 이런 이유 때문인지 팀간 경계가 없다. 바로 옆자리 사람이 디자이너가 될 수도 있고 비즈니스 담당자가 될 수도 있다. 같은 공간 안에서 밀접하게 일할 수 있기 때문에 커뮤니케이션 비용이 상당히 적고 서로의 언어를 더 잘 이해할 수 있다.
다만 비즈니스, 파트너십 팀은 나머지 팀과 공간이 분리되어 있다. 업무 특성상 이들 팀에는 전화 통화나 방문자가 많다. 더 자유롭게 소통할 수 있어야 하는 것. 그 밖에 다른 팀은 좀더 집중할 수 있는 환경을 구성하기 위해 공간을 이렇게 나눈 것이다. 물론 비즈니스, 파트너십 팀 역시 이 공간 안에선 2개월마다 자리 배치는 랜덤인 건 같다.
- 동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 일을 끝낼 것으로 신뢰하라.
“Trust & Respect”. 필자가 회사 문화 중 가장 좋아하는 대목이다. 최고의 팀원과 함께 일하고 있고 팀원마다 스스로 올바른 결정을 내리고 책임감 있게 일하고 있다고 믿는 것이다. 서로를 상호 존중하는 것이다. 주니어라도 의견 개진에 주저하지 않고 시니어라도 본인 의견만 관철시키려 하지 않는다. 모두가 모두에게 배우려는 것이다.
스프린트 시작마다 일정 산정이나 계획 회의를 하는데 일감에 대한 차이는 있지만 어떤 일감을 가져갈지 여부는 오직 개발자 각자의 몫이다. 본인 판단 하에 일감을 정하고 각자 계획해서 일하는 것.
- 개발팀으로 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화다.
현재 슬랙이나 트렐로, 깃허브, 구글캘린더, 구글독스와 G메일, 스카이프 등 다양한 협업 도구를 이용하고 있다. 모두 훌륭한 커뮤니케이션 수단이다. 하지만 한계는 엄연히 존재한다. 면대면으로 얘기하는 것보다 더 효율적인 의사소통 수단은 없다.
물론 이슈가 있을 때마다 매번 상대를 간섭하는 건 부담스럽다. 따라서 서로 편하게 의견을 나눌 수 있는 시간을 정한다. 매일 아침 개발팀은 15분 가량 데일리스크럼을 진행한다. 어제 하던 일이나 오늘 할 일, 이슈나 도움이 필요한 사항에 대한 브리핑을 1분간 짤막하게 공유한다. 간단한 질문은 할 수 있지만 구체적 논의는 데일리스크럼이 끝난 직후 당사자끼리 모여서 다시 진행한다. 때론 필요에 따라 짝 프로그래밍도 한다. 주로 새로 합류한 개발자 혹은 기존 개발자 중에도 주로 다루지 않았던 코드 작업이 필요할 때 진행한다.
- 작동하는 소프트웨어가 진척의 주된 척도다.
스프린트 리뷰 시간에는 각자 5분씩 그간 개발해온 기능을 가볍게 공유한다. 필요하다면 소스코드를 같이 보거나 실제 작동 모습을 데모하기도 한다. 서로 박수로 칭찬하기도 하고 궁금한 점은 질문한다.
물론 기능적 구현만 공유하는 게 아니라 비기능적 구현도 마찬가지. 리팩토링을 통해 훨씬 이해가 쉽고 확장성 있는 코드를 만들었다든지 새로운 기술에 대한 연구나 고찰에 대한 내용을 공유하기도 한다.
- 애자일 프로세스는 지속 가능한 개발을 장려한다. 스폰서와 개발자, 사용자는 일정 속도를 유지할 수 있어야 한다.
스프린트마다 개발할 과제는 개발자 스스로 결정한다. 보통 하루에 개발에만 집중할 수 있는 시간을 5시간이라고 하면 2주 기준으론 50시간 업무량이다. 개발 과제 난이도나 작업량을 고려해 스스로 업무량을 산정하고 장애 처리나 예상치 못한 상황에 대한 버퍼를 감안, 30∼40시간 가량 일감을 스프린트에 올린다. 제품마다 PM은 스프린트 중에도 계속해 개발자마다 로드를 확인해 업무가 과중되지 않게 관리한다.
스프린트라는 말을 들으면 의미 탓에 오해가 생길 수 있다. 스프린트는 목표를 정하고 집중하자는 의미다. 체력적으로 모든 걸 쏟는 전력 질주가 아니라는 것. 밤세워 개발하는 건 절대로 자랑스러운 일이 아니다. 밤을 세울 수밖에 없다면 스스로 계획을 잘못 세웠거나 대표가 나쁜 사람이거나. 단기간 성과보다는 지속적이고 예측 가능한 성과를 장려해야 한다.
개발자는 엉덩이보다 머리로 개발해야 한다. 집중할 수 있는 시간에 집중하고 쉴 때는 과감하게 쉬어야 한다. 회사에는 탁구대를 테이블로 쓰는 회의실이 있다. 점심시간에는 항상 사람으로 붐빈다. 휴게실에는 TV와 플레이스테이션이 있다. 가끔 사내에선 위닝일레븐 대회가 열리기도 한다.
- 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.
회사 서버에는 하루에도 수백만에 달하는 유저로부터 요청이 온다. 단순히 기능적 동작 뿐 아니라 다양한 아키텍처도 고려해야 한다. 광고 할당 로직을 위한 최적화에서 타깃팅 고도화를 위한 검색 고려, 데이터 수집과 가공에 대한 고려 등 수없이 많다.
따라서 설계에 대한 고민은 지속적 요구사항 구현과 더불어 계속되어야 한다. 최근에는 복잡성을 줄이기 위해 마이크로 아키텍처 진화, 서능을 고려해 일부 병목 기능을 고랭(Golang)으로 구현하는 최적화를 진행 중이다. 필요한 사항은 어떻게든 시작한다. 나중으로 미루면 절대로 시작되지 않는다.
그럼에도 기술 부채가 남을 수 있다. 이를 위해 스프린트 3회가 끝나면 이런 고민을 집중할 수 있는 유지보수 스프린트를 1회 연다. 이 때에는 잠시 새로운 요구사항 인입을 보류하고 기술 부채 해결을 위해 시스템을 보수한다. 대체로 프레임워크나 서버 등 인프라 관리, 보안과 모니터링 등 평소에 진행하기 어려웠던 과제 위주다.
- 단순성이 (안 하는 일의 양을 최대화하는 기술이) 필수적이다.
요구사항을 이해하고 구현할 때에는 최대한 시간을 절약하고 단순화하는 게 중요하다. 개발 일정 추정과 진행사항 확인을 위해 복잡한 방법을 쓰고 보고하는 일이 필요할까. 중요한 건 일이 되게 만든다는 것이다. 일정 산출과 추정을 위해 단순하게 트렐로 카드에 얼마나 시간이 필요하고 진행 상황을 적는 게 훨씬 좋다. 개발 일정에 대해 개발자만큼 더 잘 아는 사람은 없을 것이다.
이미지는 필자의 구글 캘린더에서 캡처한 것이다. 드립커피 소모임 등 개인 일정 외에 대부분은 제품팀과 회의다. 소모적인 회의는 없고 보고를 위한 미팅도 없다. 누구도 개발자를 마이크로 매니지먼트하지 않는다. 누구도 보고를 원하지 않는다. 스프린트 계획과 리뷰 미팅, 데일리스크럼을 통해 충분히 소화할 수 있다.
- 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.
누가 시켜서 하는 일은 재미없다. 만일 누군가 “다른 일은 넘보지 마시고 이 일만 집중하라”고 했다면 회사를 뛰쳐나갔을지도 모른다. 실제로 이전 직장에서 뛰쳐나온 가장 큰 이유 중 하나가 개인적으로 재미있어 하고 좋아하는 일을 빼앗아가 버렸기 때문이었다.
개발자가 개발할 대부분 과제는 백로그에서 직접 가져온다. 하고 싶은 일에 집중할 수 있을 때 생산성이 높다. 본인이 스스로 일감과 스케줄을 계획하고 진행하기 때문에 책임감을 가질 수밖에 없다. 코드 한줄을 작성해도 이 기능이 왜 필요한지 다시한번 확인하고 다음번 수정을 위해서 유연하게 변경 가능하지 검토한다. 코드에 오너십이 없다는 원칙에 동의하지만 그렇다고 책임질 수 없는 코드를 작성하지는 않는다.
- 어떻게 하면 더 효과적일지 정기적으로 숙고하고 팀을 조율한다.
매번 스프린트 마무리에 일감에 대한 리뷰와 데모가 끝나고 나면 스프린트 동안 잘 했던 일과 개선 사항에 대해서 얘기한다. 그 중 몇 가지를 나열해보면 아래와 같다.
- 과제에 대한 정의가 명확하지 않다→과제 인입되기 전에 PM을 통해 구체화한다.
- 장애나 긴급 이슈로 인해 스프린트 초기 설정한 계획이 무용지물이 된다→버퍼를 고려한다.
- 코드 리뷰 요청이 일부 개발자에게만 집중된다→리뷰가 업무를 토스 할 수 있는 방안 마련
- 테스트 폰 관리가 어렵다→테스트 폰에 라벨링해 사물함에 보관하고 필요시 명함을 꽂아 넣고 사용한다.
- 유닛 테스트 코드 활용 방안 마련→중요한 코드에 대해서 먼저 작성될 수 있도록 가이드.
- 코드 리뷰가 밀리는 경우가 발생한다→슬랙봇을 이용해 아침 출근이나 점심 식사 직후 알람을 보내도록 설정하고 다른 업무 전에 리뷰 먼저 처리하도록 가이드.
- 스탠딩 데스크 활용 방안→먼저 스탠딩 데스크 4개를 구매헤 시범 사용 후 확대 방안 논의
- 개발과 관련된 지식정보 모으기→깃허브에 프로젝트 생성해 위키로 활용
이렇게 회고 시간에는 다양한 의견을 나눈다. 의견이 수렴되면 바로 액션 아이템으로 삼아 실행한다. 유지보수 스프린트에 대한 논의는 내부에서도 늘 뜨거운 감자다. 유지보수 일감을 미뤄두고 하는 게 맞을지 혹은 일반 스프린트에 같이 진행하는 게 맞을지 등등. 물론 계속해서 이에 대해 논의해 적절한 답을 찾아갈 것이다.
애자일 소프트웨어 개발은 프로세스나 방법론이 아니다. 물론 흔히 알려진 스크럼이나 익스트림 프로그래밍, 칸반같은 정리 도구가 존재하지만 사람이 좋다고 해서 그대로 적용하는 건 바보 같은 일이다.
사람의 성격과 성향이 다양하게 많은 것처럼 팀도 마찬가지다. 어떤 팀은 구조화된 조직을 가지고 있는가 하면 다른 어떤 팀은 수평적인 조직일 수 있다. 팀은 자신들에게 적절한 방법을 생각해볼 수 있어야 한다. 그리고 서로간의 신뢰를 바탕으로 새로운 방법에 적응할 수 있어야 한다.
You must be logged in to post a comment.