[소프트웨어 장인] 2장 애자일

7 분 소요

애자일

방대한 문서 작업을 기반으로 하는 소프트웨어 개발 방법론에 어떤 대안이 있을지 소프트웨어 업계에 영향력 있는 17명이 유타주의 스키 리조트에 모였다.
긴 토론 끝에, 애자일 매니페스토가 창안되었고 애자일 연합이 만들어 졌다.

애자일은 어떤 단일 개념이 아니다. 애자일은 서로 다른 여러 맥락에 따른 방법론과 테크닉의 조합이다.

애자일 원칙과 방법론들은 절차적인 부분과 기술적인 부분의 두 종류로 나눌 수 있다.

2장에서는 애자일 매니페스토와 함께 애자일이 의미하는 바가 무엇인지 알아보고, 조직에서 애자일을 적용하면서 겪는 어려운을 살펴본다.

절차적인 관점에서의 애자일 원칙

팀과 조직이 어떻게 구성되고 협업해야 하는지에 대한 것들을 규정한다.

회의 방식
구성원 각각의 역할
요구사항 파악 방법
작업 진척 속도 파악 방법
점진적/반복적으로 일할 때 취하는 방식
진행 상황을 개발팀 밖의 관계자(고객, 영업 등)에게 전달하는 방식
비즈니스 피드백 방식

애자일 원칙의 절차적인 부분들은 팀에 정말로 중요한것, 비즈니스에 가치가 있는 것에 집중한다.
즉, 올바른 목표를 향해 진행 중인지 확인할 수 있다.

기술적인 관점에서의 애자일 원칙

애자일 원칙의 기술적인 부분들은 개발, 확장, 유지보수, 제품을 출시 하면서 겪는 어려움들에 대해 특정한 기술적 관례나 기술 자체를 매우 구체적으로 가이드 한다.
테스트 주도 개발(TDD), 페어 프로그래밍, 지속적인 통합, 단순한 디자인 원칙 등과 같은 것들이다. 즉 목표한 것을 올바르게 실행하고 있는지에 대해 안심할 수 있게 한다.

애자일을 따른다는 것

‘애자일을 따른다’는 것은 새로운 환경에 성공적으로 적응하고 있다는 의미다.

톰 길브(Tom Gilb)

‘민첩(Agile)’하다고 해서 애자일을 실행하고 있는 것은 아니다.
애자일 방법론들은 모두 빠르고 짧은 피드백 루프에 대한 것이다. 더 빨리, 더 짧게 피드백 루프를 만들수록 더 애자일해진다.

애자일은 문제 자체를 해결해 주지는 않는다. 애자일은 문제를 드러나게 한다. 중간 결과물이나 수정 중인 프로토타입이라도 사용자에게 빨리 보여준다면 피드백을 속히 받을 수 있다. 여기서 사용자는 일반적인 의미로 사용되었다. 제품 기획자나 투자자, 혹은 최종 고객일 수도 있다.

게임 체인저

기존에는 섣부른 과잉 설계(Big Design Up-Front: BDUF)와 방대한 문서 작업, 관료체계에 의존했다면, 애자일은 비즈니스와 고객 가치 창출에 개발자들이 직업참여하는 것도 매우 중요하다고 주장한다.
미리 세운 계획에 따라 그저 기계적으로 코딩만 하는 것이 아니라, 계획, 일정 및 예산 등의 추산, 요구사항 분석, 팀 구성, 분석, 아키텍쳐, 제품 릴리즈, 우선순위 조정, 시연 그리고 사용자와 프로젝트 이해 관계자에게 정기적으로 피드백을 받는 단계까지 개발자가 수행하기 시작한 것이다.

피플 임파워먼트

개발팀은 수평적인 계층구조로 바뀌고 있다.
개발자의 의견을 바탕으로 투자자와 제품 오너가 우선순위를 매긴 작업 백로그(해야 할 업무 목록)를 이용한다.

프로페셔널의 진화

애자일한 방식으로 일하려면 소프트웨어 프로페셔널의 진화가 바탕이 되어야 한다.
코드를 잘 작성하는 것은 소프트웨어 프로페셔널이 가져야 할 최소한의 요건이다.
그에 더해 오느란ㄹ에는 테스트, 분석, 비즈니스에 대한 이해, 커뮤니케이션 능력, 보다 외향적인 성격을 소프트웨어 프로페셔널에게 요구한다.

애자일 매니페스토

다음은 애자일 매니페스토 웹사이트에서 발췌한 내용이다.

우리는 스스로 소프트웨어를 개발하고, 다른 사람들이 개발하는 것을 도와주면서 더 나은 소프트웨어 개발 방법들을 찾고 있다. 이 과정에서 우리는 다음과 같은 가치를 중요하게 생각한다.

절차와 도구보다는 개성과 화합을
방대한 문서 작업보다는 동작하는 소프트웨어를
계약 조건에 대한 협상보다는 고객과의 협력을
계획을 따르는 것을 넘어서서 변화에 대처하는 것을
더 가치있게 여긴다.

좌측의 사항도 가치가 있음을 인정하지만 우리는 우측의 사항에 더 높은 가치를 둔다는 것이다.

애자일의 창안자들은 애자일 매니페스토와 함께, 열두 가지의 원칙들도 제시하고 있다.

애자일 매니페스토의 원칙들

가치있는 소프트웨어를 일찍, 지속적으로 전달하여 고객을 만족시키는 것을 최우선으로 한다.
개발의 막바지 단계이더라도 고객의 요구사항 변경을 환영한다. 애자일 프로세스들은 변화를 활용하여 고객의 경쟁력을 높이는 데 기여한다.
동작하는 소프트웨어를 몇 주에서 몇 개월 단위로 자주 전달한다. 가능한 한 전달주기를 짧게 한다.
비즈니스 담당자들은 프로젝트 기간 내내 매일 개발자와 함께 일한다.
프로젝트는 동기가 부여된 개인들로 구성한다. 그들이 필요로 하는 환경과 지원을 제공하고 프로젝트가 완료될 때까지 믿고 맡긴다.
개발팀 내에서 정보를 전달하는 가장 효율적이고 효과적인 방법은 얼굴을 마주보고 대화하는 것이다.
프로젝트의 진척도를 가늠하는 가장 기본 요소는 동작하는 소프트웨어다.
애자일 프로세스들은 지속 가능한 개발을 이끈다. 투자자, 개발자, 사용자들은 일정한 개발속도를 계속 수용할 수 있어야 한다.
기술적인 탁월함과 좋은 걸계에 대한 지속적인 관심은 기민함을 높인다.
단숨함, 즉 하지 않아도 될 일은 최대한 하지 않아야 한다.
최선의 아키텍처, 요구사항, 설계는 스스로 조직화되는 팀에서 나온다.
개발팀은 정기적으로 일을 어떻게 하는것이 더 효과적인지 되돌아보고 그에 맞추어 일하는 방식을 조율하고 바로 잡는다.

애자일 격변기

애자일로 전환할 때 스크럼 등 몇가지 방법론들이 조합된 개발 방법론들을 선택한다.
애자일을 도입하는 첫 걸음으로서는 훌륭하다. 그런데 애자일에서 중요시하는 자기 조직화 팀에 대한 개념을 받아 들이기에는 기업 입장에서는 당혹스러울 것이다.

업무를 처리할 때 팀에 통제권을 준다는 것은 커다란 발전이다.

팀 구성원들이 서로 간에는 물론 그들의 고객과도 더 자주 의견을 나누는데 이 또한 기업들 입장에서는 낯선 풍경이다.

사람들이 자주 소통할 수 있는 환경이 제공되면 기업의 문제를 해결하는 것은 물론 팀과 개인의 약점과 강점을 이해하는 데도 도움이 된다. 애자일 프로세스는 팀 구성원이 단합하고 공동의 목표를 갖도록 한다.

애자일 행오버

많은 애자일 프로젝트들이 여전히 엉망인 코드를 반복하여 만들어내고 있다.

몇 년 동안 기업들과 개발팀들이 애자일 전환에 빠져 들어서 기업들이 변화하기 시작했다.
스탠딩업 형태의 회의로 바뀌었도, 프로젝트 관리를 위해 번-다운 차트, 업무 주기 백로그, 릴리즈 백로그 등의 새로운 도구가 도입 되었다. 유즈 케이스는 사용자 스토리로 대체되었고 프로젝트 관리자는 스크럼 마스터가 되었다.

이러한 변화에도 불구허고 좋은 소프트웨어를 빠르게 공급하지 못하고 있는 것이 현실이다. 많은 기업, 개발팀들이 애자일 전환 전에도 있던 문제들이 전환 후에도 여전하다.
릴리즈된 제품에 수정사항을 적용하는 데도 너무나 오랜 시간이 소요된다. 여전히 과거의 기술적 부채에 허덕인다.

애자일을 도입하여 모든 절차를 뒤바꾸는 궁극적인 목적은 소프트웨어에 대한 투자 대비 이득을 키우기 위해서다. 그 목적을 달성하지 못하면 이 노력들은 모두 허사다.

부분적인 전환

많은 기업들이 표면적으로는 애자일을 도입하려 했지만 그 노력은 애자일스럽지 못했다. 소프트웨어 프로젝트에서 가장 중요한 결과물이 소프트웨어 자체라는 점을 잊은 것 같다.

기업들은 애자일 코치를 고용하여 개발 절차를 바꾸는 데는 도움을 받지만, 더 높은 품질의 소프트웨어를 작성하는 데는 거의 도움이 안 되고 있다.

보통 애자일 전환은 절차에만 집중하고 사람들에 대한 기술적인 훈련에는 관심을 크게 두지 않는다. 즉 개발자의 역량을 키우는 데는 도움이 안된다.
애자일 코치는 운영 담당, 제품 서비스 담당, QA 담당과 같은 사람들의 역략을 키우는 데 현실적으로 아무것도 하는 것이 없다. 대부분 구성원들의 기술적인 훈련은 완전히 빠져 있다.

여기에는 ‘개발자들은 이미 훌륜하고 절차만 개선하면 된다’는 프로답지 않은 단편적인 가정이 깔려 있다.

애자일의 모든 절차들에는 기술적 탁월함이 전제되어 있다. 관리자들이나 역량이 부족한 애자일 코치들은 기술적 수준이 개선되어야 함을 자주 무시한다.

애자일이나 린(lean) 커뮤니티에는 도요타의 사례를 좋아하는 사람들이 많다.
도요타가 성공할 수 있었던 중요한 요인은 절차를 개선하는 것뿐만 아니라 자동차의 품질에 이미 충분한 역량과 그를 뒷받침하는 노력이 있었기 때문이다.

모든 단계마다 피드백이 있다는 전제에서만 절차의 개선으로 제품이 나아진다.

피드백 시스템이 동작하려면 자기가 하는 일에 충분히 주의를 기울이고 뭔가 잘못되고 있거나 더 나은 방법이 있다고 느낄 때 자기 목소리를 내는 재능 있고 프로페셔널한 사람들이 있어야 한다.

절차에만 집중하고 소프트웨어 개발을 공장 라인처럼 취급하면, 그저 시키는 일만 하고 출퇴근하는 공장 노동자와 다를 바 없는 개발자들만 생긴다. 이렇게 되면 비효율적인 피드백 시스템이 되어 전체 프로젝트에 해를 끼친다.

애자일 코치

애자일 선언의 진정한 의미를 이해한 애자일 고치는 절차뿐만 아니라 기술적 탁월함도 강조한다.
반면에 수준 이하의 애자일 코치는 스스로의 기술적 역량이 부족하여 절차적인 면만 강조하고 기술적 측면을 전혀 언급하지 않아 고객을 잘못된 방향으로 이끌기 십상이다.

고참 관리자에게 새로운 절차를 파는 것은 쉽지만 많은 노력과 어려움이 수반되는 기술 역량 형상에 투자하도록 설득하기는 꽤 어렵다. 고참 관리자들은 절차 자체는 잘 파악하지만, 실무개발자들에게 그냥 코딩하는 것 외에 더 큰 역할이 주어질 때 생기는 이득에 대해서는 이해하지 못한다.

궁극적인 질문은 ‘애자일 전환이 개발자의 역량 향상에 얼마나 도움이 되었는가?’임을 기억하자.

새로운 기술적 실행 관례에 대한 거부감

그 반대의 측면도 있다. 고객을 제대로 돕는 매우 훌륭한 애자일 코치나 컨설팅 업체도 있다. 그런데 XP를 도입할 때 일이 헝클어진다. 페어 프로그래밍 도입, 테스트 주도 개발 방법론에 대해서 개발자 스스로 이러한 방식들을 거부하기도 한다.
자동화한 테스트에 투자하지않는다면 지속적인 코드 통합(integration)은 크게 의미가 없다. 컴파일이 된다는 것 정도만 확인할 수 있을 뿐이다.
새로운 기술과 실행 관례를 배우는데 열정적이고 마음이 열린 개발자를 채용하는 것을 고려해야 한다.

소프트웨어 프로젝트를 바라보는 편협한 시각

매우 편협한 시각으로 소프트웨어 프로젝트를 진행할 때가 아직도 많다. 요구사항 작성을 위한 비즈니스 전문가, 다이어그램과 문서를 작성하는(코딩을 안하는) 테크니컬 리더, 프로젝트를 감독하는(아주 세세하게) 관리자를 매우 신경쓴다. 이 중요한 역할들만 고급인력으로 채우고 나면 값싼 개발자들을 고용한다. 이렇게 고용된 개발자들은 요구사항과 기술사항이 작성된 한 무더기의 문서를 넘겨 받는다. 하지만 이런식으로는 일이 절대 돌아가지 않는다. 이러한 프로젝트들은 실제 사용자의 목소리를 들을 수 없고, 비즈니스 담당자와는 칸막이가 쳐 있으며, 빠르고 빈번한 피드백 루프도 없다는 공통점이 있다.

산더미의 문서들을 얼굴 한번 본 적 없고 어떻게 선발되었는지도, 어떤 역량이 있는지도 모르는 개발자들한테 맡기고서는 모든 요구사항들을 충족하는 소프트웨어가 짠 하고 나타날 거라고 정말 믿는 것인가?

상급자들이 소프트웨어로부터 너무 떨어져 있다는 것도 문제다. 기술을 이해하지 못하는 사람들이 의사 결정을 하는 것은 프로젝트를 재앙으로 이끄는 지름길이다. 애자일 절차를 포함해서 모든 소프트웨어 절차들은 기술적 탁월함을 기본 배경으로 가정하고 있다. 기술적 탁월함을 갖추지 못한 소프트웨어 프로젝트는 고통과 당황함 일색의 매우 비산 경험이 되기 쉽다.

나쁜 소식만 있는 것은 아니다

절차를 개선하고 비즈니스 부서로의 제품 전달 피드백 루프를 단축시키면 현재 어떤 문제들이 있는지 전과 비교해서는 훨씬 나아졌을 것이다. 좋은 절차임에도 고객에게 결과물이 전달되지 않으면 소프트웨어 프로젝트가 성공할 수 없다. 반대로, 최고의 개발자들이 있더라도 그들이 제대로 일할 수 있는 절차가 없다면 마찬가지로 소프트웨어 프로젝트가 성공할 수 없다.

중요한 점은 어떤 문제가 있는지 재빨리 인식하고 대응하는 것이다. 늦을수록 좀더 고통스러울 뿐이다.

애자일과 소프트웨어 장인정신

애자일과 소프트웨어 장인정신은 상호 보완적이다.
애자일 방법론들은 가치에 따라서 일을 이해하고, 우선순위를 정하고, 관료주의와 낭비를 줄이고, 사람들에게 권한이양과 동기부여를 하고, 관료주의와 낭비를 줄이고, 사람들에게 권한이양과 동기부여를 하고, 피드백 루프를 만들어 준다. 이것은 기업이 올바른 일을 하도록 돕는 것이다.

소프트웨어 장인정신은 여러 기술적 실행 관례를 활용하고 정교하고 솜씨 있게 짠 코드의 중요성을 강조함과 동시에 코딩을 넘어서 고객의 더 많은 부분을 도울 것을 강조한다. 이것은 개발자와 기업들이 일을 올바르게 수행하도록 돕는다.

요약

많은 기업들이 애자일의 절차적인 부분에는 많은 관심을 기울이고 있지만 기술적 실행 관례에 대해서는 완전히 무시하고 있는것이 현실이다.
스크럼을 도입하고, 스탠딩업 미팅을 하고, 백로그 관리툴을 사용하는 것만으로 갑자기 소프트웨어 품질이 더 좋아지거나 개발자들의 역량이 높아질 수는 없다. 기술적 탁월함의 개선 없이 절차만 개선하는 것은 무의미하다.

완전한 애자일 전환을 위해서는 프로페셔널 소프트웨어 개발자들이 필요하다.

정기적으로 계속해서 배포되는 소프트웨어에 대해서도 높은 품질을 유지시키며, 완벽하게 테스트되고 쉽게 변경할 수 있는 소프트웨어를 개발할 수 있어야 한다. 완전한 애자일 전환을 위해서는 기업들이 소프트웨어 장인정신을 품어야 한다.

참조

소프트웨어 장인

hongmo