brunch

라이킷 12 댓글 4

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by 신황규 Hubert Feb 10. 2021

3장. 애자일 전도사#4

#3-4 애자일 문서(?)

#3-4 애자일 문서(?)

100+명의 SI 프로젝트를 코칭하면서 필자는 정말 훌륭한 경험들을 쌓았다. 이전 소규모 프로젝트와는 완전히 다른 경험이었다.

그 때를 회상하면, 하루에도 2~3회 정도 애자일 관련한 질문을 받았던 것 같다. 그 때 애자일 코치로서 가장 많은 받은 질문은 산출물 작성에 관한 내용이었다. 애자일 산출물의 작성 범위와 수준에 대해서도 모호하게 생각하며 궁금해하는 이들이 많았다.

특히 애자일 선언 중 ‘복잡한 문서보다 동작하는 소프트웨어를'이라는 말을 그들 나름대로 해석하여, 애자일은 산출물 작성이 필요 없다고 주장하거나 정말 없어도 되는지 필자를 통해 확인하고 싶어 했다. 사실 모두가 '문서작성'을 싫어했다.

과거 추가 사업으로 진행했던 소규모의 프로젝트에서는 적어도 산출물 작성 방법에 대해서는 이견이 없었다. 이해 관계자의 수도 적었고, 고객은 기본적으로 산출물에 관심이 없었다. 그들은 '검수'라는 행위를 통하여 인수인계를 받을 때에만 약속한 산출물이 작성되어 있는지 없는지 정도를 확인했다. 외부 감리가 필수라 어느 정도의 수준은 필요했지만, 그 수준에 맞춘다면 문서의 품질에 대해서는 누구도 제어하지 않았다.

때문에, 외부에서 보는 산출물의 틀(종류)을 그대로 두고, 추적성에만 집중하고 내용을 전반적으로 줄이는 방식을 고민할 수 있었다. 이를 경험으로 필자는 약속된 산출물은 작성해야 하나 양을 얼마든지 줄일 수 있으니, 쇼케이스를 통한 동작하는 제품을 중심으로 중간중간에 고객에 확인하여 충실도를 낮추자라는 주장을 했다. 동시에 고객에게도 이제는 동작하는 제품을 보고, 당신들이 향후 파기할 문서 따위는 신경 쓰지 말라고 설득했다.

실제로 고객을 포함한 모든 이해관계자들은, 워터폴에서도 설계 단계에서 개발 단계로 넘어가는 순간부터 모두가 단계별 진척에 관심 갖지 않고 기능 목록의 기능이 몇 퍼센트 완성되고 테스트되었는지만 확인하는 관례들을 가지고 있었다. 동작하는 소프트웨어를 확인할 수 있으면 굳이 중간과정의 산출물을 확인할 필요가 없기 때문이다.

* 대형 프로젝트에서의 애자일 문서

대형 프로젝트에서도 동일한 방식으로 고객을 설득하며 산출물 작성 수준을 줄이고 이해관계자들이 동작하는 제품에 관심을 가질 수 있도록 노력했다. 산출물은 기본적으로 객체지향 방법론을 기반으로 했다. 그 객체지향 관련 문서에 애자일 산출물인 사용자 스토리를 더했다.

유스 케이스 다이어그램에서 정의된 유스 케이스들을 스토리로 쪼개고, 스토리는 사용자와 이벤트들로 작성하게 했다. 유스 케이스는 비즈니스, 화면, 데이터, 인터페이스로 분할되고 비즈니스 쪽 산출물을 사용자 스토리가 보완하는 형태로 문서를 작성하게 했다. 당시 고객들이 산출물의 중요성을 늘 언급하던 사람들이라 설계/개발 이터레이션 중 작성해야 하는 문서는 10종 정도 되었다.

설계/개발 이터레이션은 계단식 방식(스태거드 어프로치라고 한다)으로 역할을 나누어 분석/설계자는 다음 이터레이션에 개발될 내용에 대해 설계하고, 다음 이터레이션에서 개발자들이 이를 개발하는 동안 분석/설계자는 그다음 이터레이션의 설계 내용을 준비하였다.

[계단식 방식(Staggerd Approach) 그림]

N차 이터레이션에서, N+1차 이터레이션에 개발할 목록에 대한 설계 산출물을 고객 제품 책임자에게 한번 검증하고 N+1차 이터레이션에서 개발 시 개발된 내용과 함께 설계서를 한번 더 검증하는 형태로 진행했다. 2주 단위로 이터레이션을 돌렸었는데 2주 단위 마지막 주 목요일은 N+1차 이터레이션 대상 개발 목록 설계 검증을, 금요일은 N차 이터레이션의 기능 검증을 수행했다.

설계/개발 이터레이션 단계 초반에는 이 검증들이 정말 잘 진행되었다. 설계와 개발 검증이 진행되며, 아무런 문제가 되지 않는 것 같았다. 설계 및 개발이 30% 정도 진행되었다.

하지만, 어느 날부터인가 고객과 개발팀 사이의 마찰음이 발견되었다. 고객사의 일부 제품 책임자들로부터 불만이 터져 나왔는데, 개발팀이 설계 산출물을 제대로 작성하지 않는다는 것이었다. 그 목소리는 다소 극단적이었다.

“설계 없이 개발을 할 수 있는 겁니까? 그건 소프트웨어의 101을 지키지 않는 것 아닙니까?”

'설계 없이 개발을 한다.' 이 말의 의미가 무엇인지 필자는 한 팀 한 팀을 돌아다니며, 현상태를 파악했다. 확인해 보니, 예상치 못하는 결과들이 보이기 시작했다. 최초 불만은 개발팀에서 시작되었다. 동작하는 제품을 제품 책임자에게 늘 시연하는데 동시에, 굳이 이런 상세한 문서를 써야 하냐는 내용이었다.

개발자들은 어느 순간 패턴화 되어 있는 산출물들의 작성을 줄이고 동작하는 제품을 테스트하고 시연하는데 중심을 두고 일하고 싶어 했다. 그리고 그 불만을 제품 책임자에게 표현하여 결국 마찰로 이어진 것이었다.

필자는 조금 더 개발팀을 관찰하기로 했다. 상황을 좀 더 면밀히 분석해볼 필요가 있었다. 그리고 그들이 일하는 내용에 대해 좀 더 확인했다. 그들은 상세한 설계서 없이 다음과 같은 패턴으로 일하고 있었다.

--------------------------------------------

분석/설계자는 늘 내 옆에 있는 비즈니스 전문가인 제품 책임자에게, 간단하게 쓰인 사용자 스토리를 중심으로 질문하며, 기능 개발 방향에 대해 정한다.

분석/설계자는 화면 표준에 맞는 화면을 툴로 그린다.

분석/설계자는 사용자 스토리를 기반으로 본인들이 그린 화면을 개발자들에게 보여주며 구두로 설명한다.

개발자들은 이를 기반으로 개발을 시작한다.

개발자들은 설계서를 보고 정의된 아키텍처와 공통기능, 화면 표준을 기반으로 구현한다.

실제 만든 것들은 개발자가 충분히 테스트 한 뒤, 설계/개발자에게 기능 URL을 전달한다.

설계/개발자는 이를 테스트 한 뒤 제품 책임자에게 한번 더 확인해달라고 기능 URL을 전달한다.

팀원 모두가 모여, 시연을 통해 전반적인 표준이나 부족한 부분에 대해 피드백받고 이를 수정한다.

--------------------------------------------

여러분은 이 개발 과정을 어떻게 생각하는가? 상세 설계서가 없기 때문에 개발을 하기에 부족한 상황으로 생각되는가?

문서가 중요하다고 주장하는 사람들은 늘 운영/유지보수에 대해 이야기한다. 이들에게 시스템을 온전히 인수인계하려면 문서는 반드시 필요하다고 말한다. 운영/유지 보수할 인력이 개발 인력과 다른 인력들이라는 가정하에서는 말이다.

하지만, 실제 운영 운영/유지보수를 하는 사람들에게 물어보면 보통 다르게 이야기하는 경우가 많다. 그들 또한 코드에 대해 알게 되면 그간 작성된 산출물을 업데이트하는 것이 매우 부담스러운 상황이 된다는 것이다. 결국 구축 사업에서 작성한 그 많은 양의 문서들은 일부의 정말 필요한 산출물을 제외하고는 활용하기 어렵다는 말이 된다.

문서는 다른 사람에게 정보를 전달하기 위해 작성하는 것이다. 즉, 보다 나은 커뮤니케이션을 위한 수단이다. 문서로 작성하면 필요한 정보의 보관이 가능해진다. 그런데 위와 같이 일을 하기 위해 직접 면대면으로 수행하는 커뮤니케이션이 잘 되는 상황에서 굳이 과거의 워터폴 프로세스에서 작성했던 복잡한 문서들을 작성할 필요가 있을까?

이를 작성할 시간에 코드의 품질을 높이거나 결함을 줄이기 위한 방법을 고민해 볼 수는 없을까? 관행처럼 작성해오던 문서들에 대해 '그동안 나는 문서를 왜 작성했을까?'라는 질문을 해보고 이를 관장하는 이해관계자와 함께 이야기해보기를 조심스레 제안해본다.

keyword