예제를 활용한 명세의 핵심 이점(3) – 높은 제품 품질

등록일: 2014. 08. 07

Specification by Example [한국어판]: 성공적인 프로젝트를 관통하는 핵심 실천법

  • 고코 아지치 지음
  • 이종화, 최윤상, 정성민 옮김
  • 332쪽
  • 30,000원
  • 2014년 04월 24일

높은 제품 품질

예제를 활용한 명세는 팀원 간의 협업을 증진하고 비즈니스 사용자의 참여를 촉진한다. 또한 개발하는 제품의 목적을 분명히 함으로써 제품의 품질 향상에 크게 이바지한다.

두 연구 사례가 이를 보여준다. 사브르 홀딩스(Sabre Holdings )의 애자일 코치인 웨스 윌리엄스(Wes Williams )와 BNP 파리바(Paribas )의 컨설턴트 개발자인 앤드류 잭맨(Andrew Jackman)은 예제를 활용한 명세를 도입하기 전까지 다수의 프로젝트가 어떻게 실패했는지 설명했다. 이 책에서 설명하는 접근법 덕분에 개발팀은 복잡한 비즈니스 도메인을 더욱 쉽게 이해할 수 있었고, 결국 고품질 제품을 개발할 수 있었다.

사브르 홀딩스에서 웨스 윌리엄스는 2년짜리 항공 예약 프로젝트에 참여했는데, 그 프로젝트는 전 세계에 분산된 시스템인데다 데이터 기반 프로세스 등으로 복잡한 프로젝트였다. 이 프로젝트에 참여한 30명의 개발자는 세 개의 팀으로 나뉘어, 두 대륙에 걸쳐 근무하고 있었다. 이 프로젝트는 처음에 두 번의 실패를 맛봤고, 세 번째 시도에서야 예제를 활용한 명세를 이용해 성공할 수 있었다. 윌리엄스는 이렇게 이야기했다.

대형 고객사(대형 항공사)에서 이용하면서도 문제는 거의 없었습니다. 단지 (비즈니스 인수) 테스트 과정에서 발견됐던 심각도 수준 1에 해당하는 실패 복구 관련 이슈가 하나 있었을 뿐입니다.

윌리엄스는 예제를 활용한 명세가 프로젝트 성공의 핵심 요소였다고 평가한다. 예제를 활용한 명세는 높은 품질을 보장할뿐더러 개발자와 테스터 간의 신뢰를 형성하는 데도 기여했다.

BNP 파리바(옮긴이: 프랑스에 있는 은행)의 시에라(Sierra ) 프로젝트는 예제를 활용한 명세가 어떻게 제품의 품질을 향상시키는지 보여주는 중요한 사례 중 하나다. 시에라는 다수의 내부 시스템, 신용 평가기관 및 기타 외부 기관으로부터 정보를 통합해 은행 내의 다양한 시스템으로 해당 정보를 분산하는 채권 데이터 보관소 시스템이다. 그런데 다양한 시스템과 조직에서 같은 용어를 다른 의미로 사용했고, 이로써 수많은 오해를 야기했다. 이 시스템을 구현하기 위해 여러 차례에 걸쳐 시도했으나 처음 두 번은 실패하고 세 번째 시도에서 비로소 성공한다. 이 팀의 개발자 중 한 명인 채닝 월턴(Channing Walton)에 따르면 세 번째 성공에는 부분적으로 예제를 활용한 명세가 도움이 됐는데, 예제를 활용한 명세 덕분에 개발팀이 복잡한 문제를 다루고 서로 이해한 바를 공유할 수 있었다. 실제로 완성된 제품의 품질은 인상적인 수준이었다. 시에라 프로젝트의 컨설턴트 개발자였던 앤드류 잭맨에 따르면 이 프로젝트는 2005년 이후 여전히 “큰 사고 없이” 잘 운영되고 있다. 현재 시에라 프로젝트에 참여 중인 사람들은 대부분 프로젝트가 시작할 때부터 있었던 사람들은 아니지만 품질 수준은 여전히 매우 높다고 한다.

주요 프랑스 은행 지점의 자동차 임대 시스템에 대한 벡(Bekk) 컨설팅에서도 비슷한 결과를 볼 수 있다. 원래 팀의 멤버이자 Cucumber (예제를 활용한 명세를 지원하는 유명한 자동화 도구)를 만든 아즈락 헬레소이(Aslak Hellesøy )에 따르면 시스템이 운영되기 시작한 이후로 2년간 오직 5개의 버그만 보고됐다고 한다. 현재 완전히 새로운 팀에서 유지보수하고 있음에도 말이다.

랜스 월턴(Lance Walton)은 런던에 있는 대형 스위스 은행의 지점에서 프로세스 컨설턴트로 근무했는데, 그가 맡은 주문관리 시스템은 프로젝트에 착수하는 데 이미 몇 차례 실패한 상태였다. 월턴에 따르면 그 프로젝트는 애초 시스템 운영에 필요한 지원팀의 규모가 개발팀 규모만큼이나 큰 환경을 가정하고 진행됐었다고 한다. 월턴의 팀에서는 예제를 활용한 명세를 이용해 프로젝트를 시작한 지 9달만에 시스템을 운영 환경에 적용했다. 비즈니스 인수 테스트를 하루 만에 통과했으며, 그 후 6개월 간 아무런 버그도 보고되지 않았다. 새로운 시스템은 추가적인 지원 인력을 필요로 하지도 않았고, 예상보다 적은 비용이 들었으며, 팀에서는 완성된 제품을 일찍 출시할 수 있었다. 이와 대조적으로 옆 팀에서는 개발보다 지원 업무에 10배나 많은 인력을 쏟아붓고 있었다.

월턴은 이렇게 이야기했다.

팀에서는 여전히 매주 릴리즈하고, 사용자도 거기에 항상 만족해 하고 있습니다. 품질 면에서도 더할 나위가 없죠.

예제를 활용한 명세 기법은 신규 개발 프로젝트뿐 아니라 재개발 프로젝트에도 적용할 수 있다. 신뢰할 수 있는 문서를 만들고 레거시 시스템을 정리하는 데 시간은 걸리지만 팀은 새 제품에 대한 자신감을 비롯한 여러 이점을 빠르게 얻을 수 있다.

런던의 제이피 모건 체이스(JP Morgan Chase)의 외환 관리 시스템이 좋은 사례 중 하나다. 프로젝트의 테스트 자동화 컨설턴트였던 마틴 잭슨(Martin Jackson)에 따르면 비즈니스 분석가는 프로젝트가 지연되리라 예상했지만 실제로는 2주 빨리 끝났다. 게다가 제품의 높은 품질 덕분에 비즈니스 인수 테스트를 원래 계획했던 4주보다 훨씬 앞당겨 1주만에 성공적으로 완료할 수 있었다. 잭슨은 다음과 같이 이야기했다.

시스템을 배포했고 잘 동작했습니다. 경영진은 이사회에 지금까지 경험한 프로젝트 중에서 최고의 인수 테스트였다고 보고했죠.

예제를 활용한 명세를 도입함으로써 잭슨의 팀은 프로젝트 후반에 “중대한 기술적 변화”에도 빠르게 대처할 수 있었고, 계산의 정확도 역시 향상됐다. 잭슨은 다음과 같이 이야기했다.

FitNesse 스위트(리빙 도큐멘테이션)에서 다뤄지는 모든 기능들은 시스템 테스트 및 사용자 인수 테스트를 전부 통과했고, 단 하나의 결함도 없이 출시까지 유지될 수 있었습니다. 한번은 시스템 테스트 중에 핵심 연산 컴포넌트 외부에서 오류 몇 개가 발견된 적이 있었습니다. 그러한 연산 오류가 발생했을 때 근본 원인은 연산 코드 자체보다는 위쪽에 있을 것1이라고 우리 모두가 확신했던 일은 비즈니스 사용자들에게는 좋은 사용자 인수 테스트 경험으로 작용했습니다. FitNesse 스위트를 사용했기에 결함의 원인을 진단하기가 쉬웠고, 따라서 제품을 배포하는 과정이 더 깔끔하고 빨라졌습니다.

콜로라도 덴버에 위치한 목재회사인 와이어하우저(Weyerhaeuser)의 소프트웨어 개발팀은 목재 프레임에 대한 공학용 애플리케이션 및 계산 엔진을 개발하고 유지보수하는 일을 담당하고 있다. 예제를 활용한 명세를 적용하기 전에는 개발팀이 복잡한 계산 공식과 법칙을 다루고 있었음에도 구조 공학자들은 소프트웨어 개발에 참여하지 않았다. 이로써 다양한 품질 문제와 프로젝트 지연이 야기됐고, 다양한 애플리케이션에서 해당 엔진을 사용했기 때문에 프로세스가 더욱 복잡해졌다. 프로젝트의 소프트웨어 품질 책임자(SQA; Software Quality Assurance)인 피에르 베라겐(Pierre Veragen)에 따르면 출시 전 안정화 단계에서 지연되는 일이 많았고, 문제 없이 출시되는 일은 극히 드물었다고 한다.

예제를 활용한 명세를 도입한 후, 팀은 명세를 이용해 구조 공학자들과 협업하고 결과 검증 과정을 자동화하고 있다. 변경 요청이 발생하면 개발이 시작되기 전에 테스터와 구조 공학자는 예상하는 계산 결과를 토대로 예제와 함께 명세를 기록하고, 변경을 승인한 공학자가 추후 명세와 테스트를 작성하는 식이다.

베라겐은 시스템을 변경할 때 확신을 가질 수 있게 된 점이 새로운 접근법의 주된 효과라고 말했다. 2010년 초에는 리빙 도큐멘테이션 시스템에 3만 개가 넘는 점검 사항이 있었지만 수년간 중대한 버그를 발견하지 못했고, 지금은 버그 추적을 멈춘 상태다. 베라겐은 다음과 같이 이야기했다.

저희에겐 ‘버그 개수’와 같은 지표가 필요하지 않습니다. 예전 상태로 돌아가지 않으리라는 사실을 잘 알기 때문이죠. 이제 기술자들은 테스트 우선 방식과 자동화된 테스트를 직접 다룰 수 있다는 사실에 매우 만족해 합니다.

랜스 월턴은 런던의 대형 프랑스 은행 지점의 신용 위험 관리 시스템 프로젝트에 참여한 바 있다. 프로젝트에는 팀이 익스트림 프로그래밍에 적응할 수 있게끔 도와줄 외부 컨설턴트도 있었다. 하지만 그들은 예제를 활용한 명세와 같은 아이디어는 도입하지 않았다(실행 가능한 명세와 매우 유사한 고객 테스트가 익스트림 프로그래밍에 포함돼 있었음에도). 6개월 후 월턴이 이 프로젝트에 참여했을 때 그는 코드의 품질이 낮다는 사실을 발견했다. 팀에서는 2주마다 출시하고 있었음에도 코드는 검증하기 쉽게 작성돼 있지 않았다. 개발자는 최근에 구현한 기능만 테스트했는데, 시스템의 규모가 커지면서 그 방식은 맞지 않게 됐다. “제품을 출시할 때가 되면 사람들은 초조하게 둘러앉아 시스템이 여전히 잘 작동하는지 확인했고, 이슈가 조금만 발견되길 바랬다”라고 월턴은 이야기했다. 하지만 예제를 활용한 명세를 도입하면서 제품의 품질과 신뢰도는 눈에 띄게 향상됐다. 그는 다음과 같이 덧붙였다.

아무런 문제없이 출시할 수 있겠다는 자신감이 생겼습니다. 매우 즐겁게 배포하고 점심을 먹으러 나갈 수 있었다는 얘기죠. 배포 후 문제가 없는지 확인하기 위해 자리를 지켜야 할 필요가 없었으니까요.

반면 영국의 트레이더 미디어 그룹의 웹사이트를 재구축하는 프로젝트에서 겪은 품질 문제는 예제를 활용한 명세의 활용을 중단했을 때 발생했다. 초기에 팀에서는 협업을 통해 명세를 작성했고 검증을 자동화했다. 하지만 더 많은 기능을 빠르게 개발해야 한다는 경영진의 압박으로 이를 중단했다. “저희는 품질이 곤두박질치는 광경을 목격했습니다”라고 테스트 팀 리더였던 스튜어트 테일러(Stuart Taylor )가 말했다. “예제를 활용한 명세를 이용할 때는 테스터가 결함을 찾기가 매우 힘들었지만, 그것을 중단한 후로는 한 스토리마다 4~5개의 결함이 발견되곤 했습니다.”


비애자일 팀의 적용 사례

애자일 팀만이 명세의 공동작업에서 오는 이점을 누릴 수 있는 것은 아니다. 『Bridging the Communication Gap』2 에서 나는 이와 비슷한 실천법을 좀 더 전통적인 구조적 프로세스에도 적용할 수 있을 것이라고 제안했다. 『Bridging the Communication Gap』을 출간한 후 이 책을 쓰기 위해 연구하는 동안 어떤 회사에서 우연히 그러한 사례를 발견했다.

영국에 위치한 소프라 그룹(Sopra Group)의 선임 테스트 컨설턴트인 매튜 스티어(Matthew Steer)는 대형 통신사의 서드파티 해외 소프트웨어 제공 파트너사가 이 실천법(명세의 공동작업)을 도입하도록 도왔다. 이런 변화가 필요했던 주된 이유는 프로젝트가 형편없이 정의된 요구사항으로 고통받고 있었기 때문이다. 스티어는 이 아이디어들을 적용한 해의 연간 소프트웨어 납품 비용을 이전 해와 비교했다. 당연한 얘기지만 폭포수 모델을 적용한 이 프로젝트는 무결함 수준까지는 도달하지 못했지만 이를 통해 “상위 계층에서 결함을 발견하는 확률이 높아졌고 하위 계층에서는 재작업과 비용이 줄었다”고 스티어는 말했다.

저희는 전통적으로 마지막 단계에서 발견되는 결함을 생명주기의 초기 단계에서 발견함으로써 이 방법의 효과를 입증할 수 있었습니다. 생명주기의 초기 단계에서는 결함이 증가했지만 마지막 단계에서는 결함이 대폭 줄어들었습니다.

결과적으로 2007년에만 170만 파운드(약 30억 원)에 달하는 개발 비용이 절감됐다.



  1. (옮긴이) 명세 수준에서의 결함이었다는 의미다. 

  2. 고코 아지치(Gojko Adzic), 『Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing』 (Neuri Limited, 2009)