애자일 방법론의 가치를 극대화하는 방법

InfoWorld

애자일 개발 프로세스를 진행하거나 참여 중인 사람이라면, 그리고 스크럼(scrum) 방법론과 같은 애자일 모델을 선택한 사람이라면 제품 오너와 고객 니즈, 그리고 여러 팀을 결과 산출에 맞춰 조정하기 위한 기본적인 프로세스를 갖추고 있다고 할 수 있다. 각 팀이 맡고 있는 책무를 뚜렷하게 정의하고, 미팅 스트럭처를 규정하고 일정을 정했으며, 백로그를 관리하기 위한 애자일 협업 툴을 갖춘 상태다.

이 모든 구조, 프로세스, 그리고 협업의 조합이 제대로 갖춰져 있다면 그 어떤 분야의 팀도 애자일 프랙티스를 수월하게 수행할 수 있다. 사실, 애자일 방법론은 애자일 마케팅 등 다양한 비 기술적 분야에도 적용되고 있다.

그렇다면 좋은 소프트웨어를 개발하는 데 있어서 애자일 프로세스만으로 충분할까?

그렇지 않다. 애자일 프로세스 외에도 테크놀로지가 뒷받침 된 일련의 규율이 존재해야만 애자일 방법론의 가치를 극대화 할 수 있다. 애자일의 가치를 극대화 한다는 것은 이 방법론을 통해 기업에서 만족할만한 성과를 거둔다는 의미다.

오늘 이 글에서 다룰 주제는 아래와 같다.

- 애자일 협업 툴이 주요 소프트웨어 개발 라이프사이클(SDLC)을 확실히 지원하도록 하려면 어떤 기술적 문제들을 고려해야 하는가?

- 애플리케이션이 제작 준비가 되었는지, 그리고 변경 내용을 제작 및 컴퓨팅 환경에 반영하기 위한 프로세스를 갖추고 있는지 소프트웨어 개발팀에서 어떻게 확인할 수 있는가?



애자일 개발 방법론의 기술적 부채 정의 및 해결
애자일 개발에서 사용자 시나리오를 구성하기 위해서는 많은 타협과 절충안에 도달해야만 한다. 특히 사용자 시나리오를 구성 시 기능적인 측면에서 타협이 많이 논의 되는데, 스토리 포인트를 예측하기 위해 애자일 추정(agile estimation)을 사용할 경우 더욱 그러하다.

사용자 시나리오가 끝나면, 이제 개발팀에서 그 이행에 대한 기술적 결정을 내릴 시간이다. 이러한 결정을 내릴 때에는 설령 엄격한 기술적 기준이 존재한다 하여도 어느 정도 이행 상의 타협이 불가피하다. 그리고 이러한 타협은 결국 추후 갚아야 할 기술적 부채(technical debt)로 남게 된다.

개발 과정에서는 이러한 기술적 부채가 가시적으로 드러나지 않을 지도 모른다. 이러한 기술적 부채는 이행 단계에서 사용자 행위가 기술적 한계를 노출시킴에 따라 드러나게 된다. 혹은 퍼포먼스나 확장성으로 인해 드러날 수도 있다. 아니면 업그레이드가 필요한 기저의 소프트웨어 요소 라이프사이클이 그 원인일 수도 있다.

애자일 개발 팀에 있는 개발자에게는 이러한 기술적 부채를 기록할 중요한 의무가 있다. 문제가 심각하지 않고 작다면, 코드에 투-두(to-do) 코멘트를 달아 다음 개발자가 해결하도록 두면 된다. 그러나 리팩토링(refactoring)이 필요할 정도의 큰 문제는 백로그에 아이템화 시켜두어야 한다. (여러 개의 코드 변경이 필요하거나, 추가적인 테스팅이 요구되는 기저의 소프트웨어 아키텍처나 컴포넌트 업그레이드와 같은) 애플리케이션 라이프사이클에 따른 니즈는 에픽(epics)으로 정리해 두는 것이 최선이다.

애자일 팀은 자체적인 규칙에 따라 이러한 기술적 부채의 우선 순위를 결정하게 된다. 내가 애자일 프로그램 팀을 이끌 때는 제품 오너들에게 백로그의 최소 30%를 기술적 부채 해결에 할애해 달라고 부탁했다. 수치를 30%로 정한 이유는 소프트웨어 벤더들이 지원 계약에 평균적으로 부과하는 수준이 20~30% 가량이기 때문이다. 그러나 새로운 애플리케이션의 경우 이보다 더 낮은 비율만 할애해도 괜찮다. 반대로, 레거시 애플리케이션이라면 이보다 훨씬 더 높아야 할 것이다.

기술적 부채는 여러 가지 층위에서 해결할 수 있다.

- 대규모 애플리케이션의 라이프사이클 문제의 경우, 업그레이드를 실행하기 위해 하나 이상의 릴리즈를 계획해 두는 것이 좋다. 그리고 이러한 업그레이드에는 새로운 기능이나 변경된 기능을 도입하지 않을 것을 추천한다. 그렇게 해야만 테스팅 팀에서 테스트를 통해 업그레이드의 문제를 파악하기가 더 쉽고, 근본 원인 파악이 수월해 진다.

- 릴리즈 시 제품 오너가 개발팀과 협력하여 사용자, 개발자 생산성에 가장 큰 영향을 미치거나, 애플리케이션을 기타 리스크에 노출시킬 수 있는 기술적 부채를 파악한다. 이러한 채무를 우선순위화하여 사용자 시나리오로써 아이템화 해 두어야 한다.

- 단일 유저 시나리오의 경우, 기저의 기술적 부채 문제를 해결할 수 있도록 개발 팀이 수용 기준을 제안할 수 있다.

유능하고 규율이 확실한 애자일 팀이라면 기술적 부채를 측정하여 채무가 수용 가능 레벨을 넘어섰음을 알리는 지표를 만들어 낼 것이다.

애자일 개발과 QA의 양립
애자일 개발팀 리더들로부터 가장 많이 받는 질문 중 하나가 어떻게 하면 품질 보증(QA, quality assurance)을 애자일 개발 프로세스와 양립시킬 수 있겠느냐 하는 것이다. 특히 스크럼 방법론을 사용하는 팀에서 흔하다.

매 스프린트(sprint) 마지막에 ‘끝난다’는 것은 QA가 그 어떤 새로운 기능 테스트나 회귀 테스트도 스프린트 내에 이행할 수 있게 된다는 의미이다. 그러나 스프린트 지속 시간이 짧고 개발자들이 데모 시점까지 코딩 하기를 원할 경우 이것인 생각보다 쉬운 일이 아닐 수 있다.

또한 유닛 테스팅, 자동화, 그리고 테스트 주도형 개발 관행 등으로 QA와 개발팀 간 책임선이 흐릿해진 가운데 QA를 애자일에 끼워 넣기란 쉽지 않다. 아울러 테스팅에도 여러 종류가 있는데 API, 기능성, 데이터, 모바일 인터페이스, 애플리케이션 보안, 퍼포먼스, 확장성 테스팅 등이 그것이다. 애자일을 통해 시장에 더 빨리 새로운 기능을 공급해야 한다는 기대가 형성된 상태에서 이 모든 테스트를 다 거치는 것은 불가능하거나, 가능하더라도 용납되지 않을 가능성이 높다.

따라서, 애자일 방법론을 통해 더 중요한 것은 ‘빨리 빨리’가 아니라 ‘더 안전하게,’ ‘더 퀄리티 높은’ 기능을 조달하는 것임을 애자일 팀 리더를 비롯하여 모두에게 상기시키는 것이 중요하다. 그러기 위해서는 애플리케이션 개발 단계에 품질보증 관행이 필요하다. 리스크를 관리하고, 개발자와 QA간에 책임을 나누고 규정하며, 애자일 개발 프로세스에 테스팅 일정을 포함시킬 수 있도록 말이다.

테스팅과 개발 관행의 조화를 위해서는 우선 개발 프로세스의 어느 단계에 테스팅이 들어가는 것이 적합할지 생각해 보자. 예컨대, 스크럼 프로세스에서는 아래와 같을 것이다.

- 사용자 시나리오의 초기 테스트는 개발과 동시에 시작되어야 한다. 특히 리스크가 높은 시나리오나, 스프린트 초기에 테스팅이 필요한 시나리오에 대한 테스팅을 먼저 완수하는 것이 중요하다.

- 부가적인 테스트들은 대개 스프린트 막바지에 마무리 된다. 개발자는 기능성 테스트 및 회귀 테스트가 얼마나 오래 걸리느냐에 따라 스프린트가 끝나기 수 일 전에 코드 동결(code freeze)을 계획해 두고 보고된 문제점을 테스트 및 해결하기 위해 노력해야 한다.

- 보안 테스트, 코드 분석, 그리고 퍼포먼스 테스트는 지난 스프린트에서 완성된 코드를 대상으로 진행해도 된다. 코드가 릴리즈 되기 전 일련의 마지막 테스트를 진행한다.

정해진 스프린트 시간 제한 내에 모든 QA와 테스팅을 다 하려면 상당한 수준의 자동화가 필요하다. 기능성 테스트 케이스를 자동화 하여 회귀 테스트에 추가하여야 한다. 이러한 테스트들 중 일부분은 퍼포먼스 테스팅으로 그 용도를 변경할 필요가 있다. 역량 있는 팀일수록 스스로 테스트 커버리지와 자동화 된 테스트 케이스의 비율을 측정할 것이다.


코드 브랜칭 기준을 정립할 것
애자일 개발 관행의 가장 기초가 되는 것이 바로 코드를 버전 관리하고, 다양한 활동 경로로 개발을 브랜칭하며, 릴리즈 코드를 각각 별개의 테스트 및 생산 환경으로 나누어 패키징하는 능력이다.

지난 몇 년간 여러 도구의 성능은 눈에 띄게 개선되었으며, 많은 개발팀들이 과거에는 고급 소스 코드 관리라고 여겨졌던 것들을 기트(Git) 같은 툴을 사용하여 할 수 있게 되었다. 퍼포먼스가 우수한 애자일 팀일수록 이러한 툴을 활용하여 효율성을 증대시키고 각기 다른 개발 활동에 맞춘 유연한 개발 프로세스를 가능케 한다.

이러한 유연성의 핵심은 바로 코드를 파생(branch) 및 통합(merge)시키는 능력이다. 코드 파생은 여러 가지 비즈니스에 맞춘 개발 경로를 제공하여 개발자들이 독립적인 코드 카피에서 작업할 수 있다. 개발팀은 영구적, 일회성 파생 코드를 적절히 조합하여 필요에 따라 각 브랜치를 하나로 통합할 수 있다. 대부분 개발팀에는 개발, 테스팅, 생산을 지원할 표준 브랜치가 존재한다. 하지만 다음과 같은 것들을 지원하기 위한 일회성 브랜치를 생성할 수도 있다.

- 특정 기능을 자체적인 브랜치 내에서 개발하여 완성 후 나머지와 통합.

- 생산상의 문제를 해결해 개발 중인 코드를 편입시키지 않고 디플로이 해야 할 경우를 위한 패치

- 상당 수준의 코드 변경을 요하며, 각 테스팅이 생산 릴리즈를 위해 충분히 준비가 될 때까지 별개의 브랜치에서 이루어 질 수 있도록 하는 컴포넌트 또는 아키텍쳐 업그레이드.

코드리뷰 제도화를 통한 퀄리티 및 개발자 협업 개선
기트와 같은 소스 코드 매니지먼트 툴의 또 다른 특징은 코드 리뷰를 형식화 한다는 것이다. 기트에서 개발자들은 주로 개발 또는 기능 브랜치에서 작업하며 필요에 따라, 혹은 정책에 맞춰 코드를 만든다. 코드가 완성되면, 개발자의 풀(pull) 요청을 통해 이러한 변경 사항들이 개발 브랜치나 기능 브랜치에서 나와 테스팅 브랜치로 옮겨 간다. 두 번째 개발자가 이러한 풀 요청을 테스팅에 통합한다.

이러한 협업 프로세스는 개발자들로 하여금 브랜치 통합 전에 코드 리뷰를 할 수 있게 한다. 코드 리뷰를 통해 안 좋은 코드나 표준에 맞지 않는 코드를 골라 낼 수도 있겠지만, 동료가 코드를 이해하고 읽을 수 있도록 하기 위해 지식 이전을 가능케 하기도 한다. 이는 특히 팀 멤버들 간에 책임을 공유하고 시니어 개발자들이 주니어 개발자들의 멘토가 되어주는 애자일 개발 방법론에서는 더 중요하다.

지속적인 통합 및 딜리버리 이행
애자일 팀이 프로세스 효율성과 퀄리티를 높이기 위해 다음으로 하는 일이 바로 코드 패키징 및 런타임 환경으로의 딜리버리 방식의 자동화를 손 보는 것이다.

과거 많은 애플리케이션의 제작 및 딜리버리가 수동적으로 각 단계를 거쳐 진행됐다. 개발자가 통합 개발 환경(integrated development environment, IDE)에서 한 단계를 진행한 후, 그 아웃풋을 스크립트를 이용하여 패키징 한다. 그리고 그 파일을 저장소에 FTP하여 승인된 변경 요청을 받은 오퍼레이션팀 직원이 여러 단계를 거쳐 해당 코드를 타깃 런타임 환경으로 전달한다.

이러한 수동 프로세스는 에러에 취약할 뿐 아니라 변경 사항을 주기적으로 생산 환경에 디플로이 하고자 하는 비즈니스에도, 테크놀로지팀에게도 비효율적이다.

이러한 단계들을 자동화 하는 것이 하나의 솔루션이 될 수 있다. 개발팀과 오퍼레이션팀이 협업하여 애질리티 및 오퍼레이션 상의 안정성을 개선하면, 데브옵스가 등장한다. 주요 데브옵스 관행은 아래와 같다.

- 브랜치 통합이 빈번하며 애플리케이션 빌드 프로세스가 자동화 된 지속적 통합 (continuous integration, CI)

- 버튼 한 번 누르는 것으로 선택된 런타임 환경으로 소프트웨어를 푸시하는 지속적 전달(continuous delivery, CD)

지속적 통합 및 딜리버리(CI/CD)에는 자동화 된 테스팅이 필요하다. CI/CD는 릴리즈 매니지먼트 전략(release management strategy)의 일환으로 모든 기관들에서 애자일 개발 프로세스의 일환으로 정립해야 하는 전략이다. 코드 디플로이를 원하는 앞선 개발 기관들일수록 더 빈번하게(하루에 한 번, 혹은 그 이상으로 자주) 지속적 디플로이먼트를 선택한다.

자동화와 프로세스 개선을 위한 애자일 이용
이런 식의 자동화나 협업이 가능하다는 것이 마법처럼 들릴 수도 있지만, 분명한 것은 이런 성과가 결코 하루 아침에 이루어진 것이 아니라는 사실이다. 오랜 시간에 걸쳐, 그것도 많은 비즈니스 문제들에 대처하고 해결하려 노력한 끝에 얻어진 결과물일 것이다.

가장 좋은 시작점은 우선 이러한 솔루션을 도입했을 때 소비자에게 미치게 될 영향이다. 자동화 및 협업 니즈를 사용자 시나리오로써 구체화 하고 그 디플로이먼트를 백로그에 우선 순위화 하여 소프트웨어 개발 프로젝트처럼 관리해야 한다. 그렇게 함으로써 이러한 솔루션의 이행을 시작하고 향후 개선 사항들을 위한 로드맵을 그릴 수 있게 될 것이다.

* Isaac Sacolick은 애자일과 데브옵스, 데이터 과학 분야를 주로 다루는 전문 기고가다. 스타CIO의 대표이자 CIO닷컴 등에서 오랜 기간 블로거로 활약해왔다. ciokr@idg.co.kr