대기업도 하는 애자일, 스타트업에겐 필수
구글, MS, 넷플릭스가 저렇게 빨리 성장하고 있는 이유가 애자일 덕분이라고 하죠. 우리나라 대기업들도 생존을 걱정하며 애자일을 주창하고 있습니다. 애자일 도입하라고 위에서 지시는 내려오는데 나더러 어쩌라는 것인지 난감한 실무자들도 많을 것입니다. 애자일이 무엇인지, 실체는 있는 것인지, 인썸니아는 어떻게 애자일을 실행하고 있는지 정리해봤습니다.
많이 들어봤습니다만 무슨 뜻이고 왜 생겨났나요?
애자일은 2001년에 소프트웨어 개발 업계의 명성 있는 개발자 17명이 토론 끝에 만들어낸 개념입니다. agile이라는 단어의 사전적 의미는 '민첩한, 재빠른'이라는 뜻이죠. 애자일을 누군가는 개발 철학이라고 말하기도 하고 개발 방법론이라고 얘기하기도 하고 실체가 없다고 보는 사람도 있습니다. 어찌 되었건 그 출발점은 '애자일 소프트웨어 개발 선언'입니다.
많은 사람들이 투입되어 많은 비용을 들여 오랜 기간 개발해 온 소프트웨어 프로젝트들이 실패하는 것을 지켜보면서 이 개발 전문가들은 더 효율적이고 군더더기 없으며 사람 중심의 빠르고 안전한 개발 방법론을 만들고 이를 전파하기로 하였습니다. 그것이 애자일 선언이 나오게 된 계기이며 애자일 선언은 크게 철학과 원칙으로 나눠져 있습니다.
애자일 소프트웨어 개발 선언
철학
공정과 도구보다 개인과 상호작용을
포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를
가치 있게 여긴다.
이 말은, 왼쪽에 있는 것들도 가치가 있지만,
우리는 오른쪽에 있는 것들에 더 높은 가치를 둔다는 것이다.
원칙
1. 우리의 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것이다.
2. 비록 개발의 후반부일지라도 요구사항 변경을 환영하라. 애자일 프로세스들은 변화를 활용해 고객의 경쟁력에 도움이 되게 한다.
3. 작동하는 소프트웨어를 자주 전달하라. 두어 주에서 두어 개월의 간격으로 하되 더 짧은 기간을 선호하라.
4. 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야 한다.
5. 동기가 부여된 개인들 중심으로 프로젝트를 구성하라. 그들이 필요로 하는 환경과 지원을 주고 그들이 일을 끝내리라고 신뢰하라.
6. 개발팀으로, 또 개발팀 내부에서 정보를 전하는 가장 효율적이고 효과적인 방법은 면대면 대화이다.
7. 작동하는 소프트웨어가 진척의 주된 척도이다.
8. 애자일 프로세스들은 지속 가능한 개발을 장려한다. 스폰서, 개발자, 사용자는 일정한 속도를 계속 유지할 수 있어야 한다.
9. 기술적 탁월성과 좋은 설계에 대한 지속적 관심이 기민함을 높인다.
10. 단순성이 (안 하는 일의 양을 최대화하는 기술이) 필수적이다.
11. 최고의 아키텍처, 요구사항, 설계는 자기 조직적인 팀에서 창발한다.
12. 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정한다.
선언문은 간단하지만 실전에서의 적용은 복잡합니다
애자일 철학은 아래와 같이 간단하게 요약할 수 있습니다
도구 < 사람
문서 < 가치
계약 < 협력
계획 < 대응
도구(프로세스) 보다 사람을 신뢰하고 문서 작업보다 부가 가치를 중시하며 복잡한 계약보다 참여자들 간의 협력에 의지하고 철저한 계획보다 기민한 대응을 선택합니다. 애자일 철학과 원칙을 처음 보시는 분들은, 뭐 좋은 말인 것 같네 생각하시겠지만 애자일을 오랜 기간 고민해왔던 저는 애자일 철학과 원칙을 볼 때마다 거룩한 마음과 함께 고개를 끄덕이게 됩니다. 저 한 줄 한 줄을 토론하고 고민하며 결정했을 선언자들의 경험과 연륜, 문장 속 단어들이 함축하고 있는 의도와 절제가 보입니다. 기독교인이 십계명을 대하는 마음과 비슷하지 않을까 합니다.
저는 2007년부터 애자일에 빠져서 지금까지 애자일 관련 서적을 30권 가까이 읽었고 국내 애자일 전문가이신 김창준님의 교육과 국내 스크럼/XP 모임에도 참석했습니다. 15년의 개발 경력 대부분을 애자일을 고민하고 시도하였습니다. 일부는 성공하고 일부는 포기하고 일부는 실패하면서 그래도 애자일을 도입하기 위해 노력을 해왔다고 말할 수 있습니다. 애자일 철학이 뿌리까지 스며있는 레일스 프레임워크를 주력으로 사용하고 있습니다.
읽은 책은 실용주의 프로그래머, 생각하는 프로그래밍, 익스트림 프로그래밍, 스크럼, 사용자 스토리, 사용자 스토리 맵 만들기, 칸반과 스크럼, 애자일 회고, 애자일 프랙티스, 애자일 UX 디자인, 애자일 마스터, 애자일 & 스크럼 프로젝트 관리, 함께 자라기, 리팩터링, 도메인 주도 설계 핵심, 네이키드 애자일, 레일스와 함께하는 애자일 웹 개발, 애자일 민첩하고 유연한 조직의 비밀, 테스트 주도 개발, 린 스타트업, 러닝 린, 린 UX, 클린 코드, 일을 버려라, 똑바로 일하라, 켄트 백의 구현 패턴, 스프린트 등입니다.
애자일을 주창했던 개발 구루들은 각자 애자일 관련 서적들을 집필하여 애자일 방법론을 확장시켜 나갔습니다. 이 지식들이 방대하기 때문에 방법론과 사례들이 상당히 많아졌고 어떤 것은 간단하게 적용할 수 있지만 어떤 것은 조직 구조를 바꿔야만 실행할 수 있는 것도 있습니다. 그래서 애자일은 철학과 원칙에 깊이 공감을 하고 자발적으로 어떤 방법론을 적용할 것인지 구성원들이 같이 논의하고 적용해야 합니다. 공감대와 자발성 없이 임원이 시킨다고 도입되기 어렵습니다.
어떤 실천 방법들이 있을까요?
애자일에는 철학(Philosophy), 원칙(Principles)과 더불어 실천 방법(Practices)들이 있습니다. 사실 실천 방법은 꽤 여러 가지가 있고 하나하나 깊은 의도와 상세한 사례가 담겨 있어서 묵직합니다. 많이 알려진 것들도 있고 생소한 것들도 있습니다. 저희도 모든 실천 방법들을 사용하고 있지는 않으며 아래 나열한 것들이 실천 방법 전부를 다룬 것도 아니니 애자일을 정복하고 싶으신 분들은 제가 읽은 책들에 더해 거기에 빠진 실천 방법들까지 다루는 원서들도 추가로 읽으셔야 할 겁니다. 다 합치면 100가지도 넘을 것 같아요.
애자일의 모든 방법을 적용할 필요는 없으며 시도해보고 잘 동작하는 것들만 사용해도 되고 각 조직에서 구성원들이 같이 논의하여 기존에 없던 효율적인 실천 방법을 적용하는 것도 애자일의 철학과 원칙에 부합합니다. 이점 때문에 우리 팀이, 회사가 애자일 했는지 아닌지, 이렇게 일하는 것이 애자일한 것인지 아닌지 애매합니다. 그래서 애자일을 '애자일 점수'를 내기 위한 기준이라고 보지 말고 좋은 방향으로 가기 위한 지향점으로 생각해야 합니다.
몇몇 애자일 실천 방법은 개발 방법도 있지만 개개인의 동기부여 방법이나 학습법 및 교습법, 문제에 대한 접근 및 해결 방법, 프로젝트 관리 및 소통 방법, 조직 관리법도 있습니다. 애자일이 그래서 재미있는데, 개발자도 '개발'을 하는 사람 이전에 '사람'이고, 동기 부여와 인간관계, 협업과 소통 방식에 의해 생산성이 좌우되기 때문에 생산성을 올리기 위해서는 개발 외적으로도 장치들을 마련해야 합니다. 이 글에서는 실천 방법을 크게 프로젝트 관리 측면, 프로그래밍 측면으로 나눠보겠습니다.
프로젝트 관리 측면의 실천 방법
동작하는 가장 단순한 해결책, 우선순위가 높은 순서대로 개발, 언제든 출시 가능한 상태, 데모를 사용하여 자주 피드백받기, 짧은 스프린트 반복과 점진적인 배포, 단순하게 유지하기, 고객사를 개발에 참여시키기, 고정 금액 계약 지양하기, 문서 작성 최소화 등 프로젝트 관리 측면의 애자일 실천 방법 중에 저희가 실천하고 있는 것들은 저의 이전 글에서 다루었습니다. 개발자분들은 출근하여 한 공간에서 같이 일하기 때문에 면대면 소통을 활용하지만 한 공간에 있지 않은 고객사와의 소통은 시대에 맞게 슬랙/카카오톡을 적극 활용하고 있습니다. 아무래도 이메일과 전화만 가능했던 2001년에 비해 2020년에는 효과적인 원격 소통 도구들이 있어 적극적이고 빈번한 커뮤니케이션이 좀 더 간편해졌다고 생각합니다.
❖ 함께 읽으면 좋아요!
이렇게 개발하는 회사는 처음 봅니다
http://www.openads.co.kr/nTrend/article/6926
저희는 인셉션 덱, 플래닝 포커, 칸반, 스크럼, 사용자 스토리, 회고는 원래의 실천 방법보다 훨씬 간소화해서 적용하고 있습니다. 애자일 방법론이 수십억 원, 수백억 원의 프로젝트까지 커버할 수 있는 방법이다 보니 수 천만 원 내외의 프로젝트에서는 실천 방법 그대로 적용하기보다는 간단한 의사결정과 의사소통으로 끝내도 된다고 판단했습니다. 위의 실천 방법 각각에 대해 책이 몇 권씩 출간되어 있으므로 여기서는 간단하게 개념만 정리해보겠습니다.
인셉션 덱은 프로젝트 전체를 개괄하기 위한 정리 방법입니다. 프로젝트의 목적/결과물/규모/관련자/구현/기술 이슈/우선순위를 정의한 표라고 보면 됩니다. 사용자 스토리는 구현할 기능 목록을 서술하는 방식인데, 개발자뿐만 비개발자를 포함한 모든 프로젝트 구성원이 이해할 수 있고, 구현 시간 예측과 구현 여부 기록을 하기 위한 최소 단위입니다. 가령 '게시물 작성'이라는 기능을 사용자 스토리 형태로 정의하면 '사용자는 +버튼을 눌러 게시물을 등록할 수 있다' 이런 식으로 주어와 서술어가 들어간 문장 형태가 됩니다. 주어를 명시하는 이유는 서비스의 이용 주체(페르소나라고 표현하기도 합니다)가 구매자, 판매자, 관리자 등 여러 개일 수 있기 때문입니다.
플래닝 포커는 사용자 스토리별로 구현 시간을 예측하기 위한 방식이고 칸반은 기능이나 스토리 단위로 테스트가 적힌 작업 카드를 '작업 전' 칸에 쌓아두고 개발자들이 하나씩 개발한 후 완료되면 '작업 완료' 칸으로 이동하는 방식으로 테스크를 관리하는 방법입니다. 칸반을 도입할 때 아날로그 방식을 좋아한다면 화이트보드에 테스크가 펜글씨로 적힌 포스트잇을 띄었다가 붙였다가 할 수도 있고, 디지털이 좋다면 트렐로를 씁니다. 스크럼은 칸반과 스프린트 반복, 그리고 진행상황 소통을 종합한 방법론입니다. 다시 말씀드리지만 개념 이해를 도와드리기 위해 극단적으로 단순화했으므로 실제로 도입하려면 각각의 실천 방법에 대한 서적을 꼭 읽으시기를 바랍니다.
저희가 수주하는 프로젝트 규모는 수 천만 원 단위로 작기 때문에 수주 및 착수 시점에 약 1~2시간의 고객사 및 개발자 논의, 그리고 예상 견적 계산 기능을 이용해 인셉션 덱, 주요 사용자 스토리를 완성할 수 있고 플래닝 포커를 생략해도 대략적인 공수 파악이 됩니다. 스크럼과 칸반은 프로젝트가 유지보수 단계로 넘어가 장기화되면 트렐로 등을 이용하지만 초기 단계에서는 고객사와 개발자 모두가 초대된 카카오톡 단체방에서 구현된 것과 구현할 것, 문의할 것, 피드백할 것을 빈번하게 주고받는 것으로 대신합니다. 회고 차원에서 새로 발견하고 해결한 기술 이슈에 대해서 사내 개발 게시판에 정리하고 공유합니다. 프로젝트 현황 공유가 목적인 스크럼 데일리 미팅은 따로 하지만 진행 현황과 이슈 사항이 있을 때마다 브리핑을 하고 피드백을 주는데 몇 분 밖에 소요되지 않습니다.
프로그래밍 측면의 실천 방법
코드 리뷰, 코드 공동 소유, 페어 프로그래밍, 리팩터링, 단위 테스트, 테스트 주도 개발 등이 있습니다. 코드 리뷰는 다른 개발자의 코드 변경 사항을 보면서 문제점이나 개선점 등을 논의하는 과정이고 코드 공동 소유는 다른 사람이 작성한 코드라도 문제를 발견했으면 자발적으로 고치고 같이 책임진다는 개념입니다. 리팩터링은 기능을 변경하지 않고 코드를 좋은 구조로 고쳐나가는 것, 페어 프로그래밍은 두 사람이 하나의 키보드를 두고 번갈아가면서 개발해나가는 것, 테스트 주도 개발은 구현을 먼저 하지 않고 테스트 코드를 먼저 작성한 후 테스트가 통과하도록 구현하는 것, 단위 테스트는 각 기능이 제대로 동작하는지를 보장하는 테스트 코드를 작성해둠으로써 리팩터링이나 기능 추가 등으로 기존의 기능이 갑자기 동작하지 않는 상황을 방지하도록 합니다.
저희는 기본적으로 프로젝트 코드를 개발자들이 함께 책임지고 수정하며 주기적으로 코드 리뷰를 하면서 동시에 리팩터링을 합니다. 더 좋은 구조에 대한 교육과 프로젝트 개선을 동시에 하는데 대게 시니어가 주니어에게 교육시키는 방향이기 때문에 페어 프로그래밍의 형태보다는 교정/첨삭의 형태에 가깝습니다. 고객사 프로젝트가 아닌 내부 프로젝트의 경우는 조금 더 교육의 측면에서 코드 리뷰와 리팩터링에 시간을 투자하지만 고객사 프로젝트의 경우 비용 절감이 중요하기 때문에 적절한 수준의 리팩터링을 위한 코드 리뷰를 합니다.
테스트 주도 개발(TDD)은 크고 복잡한 프로젝트를 장기적으로 안전하게 관리하기 위한 좋은 방법임을 인정하지만 규모가 수 천 만원 단위 정도로 작고 비용 관리가 중요한 프로젝트, 그리고 초반부터 기획이 빈번하게 수정되는 스타트업 서비스 초기 프로젝트에서 오히려 비효율적으로 느껴져서 적용하지 않고 있습니다. 비슷한 이유로 단위 테스트도 프로젝트 초기에 사용하지 않고 프로젝트가 안정화되고 복잡도가 증가하는 시점에 부분적으로 사용하고 있습니다. TDD, 페어 프로그래밍, 단위 테스트는 대표적인 애자일 기법이라서 사실 도입하지 않고 있다는 사실이 좀 불편하기도 하였는데 이에 대해서는 조언을 해주실 분이 계시다면 감사하겠습니다. 이외에도 코드 관리 측면의 실천 방법으로 볼 수 있는 지속적 통합, 자동화된 배포, 코드 버젼 관리는 github과 배포 스크립트 등으로 역시 간소화하여 적용하고 있습니다.
