개발방법론 (waterfall + agile or iteration)

2021년 진행해야 될 공공프로젝트에 서비스 오픈을 애자일 식으로 반복해서 해달라는 고객요청이 왔다.

감리는 기존처럼 폭포수 방법론의 산출물로 해야 되고

진행방식은 애자일로 해야 되는 이상한 상황에 직면해 구글링하던 중 아래와 같이 좋은 아이디어를 가진 분의 블로그를 발견하였다.

결론은 테일러링을 해야 될것 같고, 이를 위해 내외부적으로 설득이 필요해 보인다.

===================

[Phase#2] Waterfall에 설계/개발 이터레이션을 적용하다

Hubert Shin

May 13, 2017·12 min read

기존에 있던 단단한 워터폴 프로세스와 필연적으로 부딪혀야 하면서도, 애자일의 무언가를 시도하고 싶은 분들, 본인이 가진 권한이 없어 주변을 바꿀 수 있는 여건은 안되지만 프로세스적으로 내가 지금 있는 환경에서 “낯설음"을 시도하고 싶은 분들을 위해 필자의 경험을 공유드리고 싶다.

08년 당시를 돌이켜보면, 현실 vs 이상의 고민 속에서 매우 현실쪽에 가까운 시도였고, 애자일을 통해 반드시 얻어야하는 사용자의 가치에는 그다지 근접하지 못한 방식이었다. 하지만, 당시 회사의 단단한 프로세스에 대해 약간의 유연함을 부가할 수 있는 시도였고 필자가 근무하던 회사에 없던 이터레이션이라는 프로세스를 최초로 도입했던 시도였다.

그럼 이야기를 시작해 보자.

이전까지, 혼자서 담당하던 코드를 만지며, 일부 애자일 프랙티스 등을 수행했던 경험을 여러차례 거친 후,

4년차의 젊은 개발자가 “이제는 애자일 방식으로 프로젝트를 수행하고 싶습니다” 라는 용기있는 말을 던진 후 내가 속한 프로젝트에서 제일먼저 했던 고민은 애자일의 가장 큰 특징 중 하나인 이터레이션을 어떻게 프로세스에 녹일 지 였다.

당시의 상황을 좀 설명하자면,

• 프로젝트: 100+ 규모의 대형 SI프로젝트 이후, 추가계약 사업이 만들어졌다. 8개월 정도 추가기능을 만드는 작업이었다.
• 아키텍처: 대형 SI프로젝트의 아키텍처를 그대로 상속하는 모델이었다.
• 팀규모: 20명 정도였다. 상세하게 말하면, PM은 수년간의 경험을 통해 폭포수 방법론을 이용하는 것에 잔뼈가 굵은 사람이었지만 필자와 큰 신뢰가 있었고 당시 프로세스를 담당하는 QA는 회사의 표준을 제시하며, 그에 따라 프로젝트를 온전히 수행하게 하는 하는 책임이 있었다. 이를 다르게 표현하면 그는 회사의 프로세스와 산출물을 그대로 따르도록 가이드 했고, 이를 어기는 것은 매우 큰 문제라 인지하였다. 개발자들은 대부분이 15명 정도의 협력업체 사람들이었다.
• 프로세스: 회사의 방법론은 전형적인 워터폴이었다. 분석이 끝나고 모든 산출물이 작성 완료되면, 설계 단계에 들어갔고, 설계단계가 온전히 완료되면 개발에 들어갔고, 이후 테스트가 되었다. 방법론이라는 말에 대해 익숙하지 못할 독자를 위해 조금 설명한다면, 기본적으로 방법론이라는 것은 다음과 같이 구성되는데, 그것은 프로세스 + 툴 + 가이드이다. 그리고 프로세스는 단계별 / 액티비티 별로 쪼개져 역할과 책임, 그 액티비티의 입력물과 출력물이 정의되어 있었다.

기존(Waterfall)

기존의 하던 방식으로 프로젝트를 생각하면, 8개월의 기간을 분석-1개월, 설계-2개월, 개발-4개월, 테스트-1개월 정도의 기간으로 나누고, 회사가 제공하는 프로젝트 성격에 맞는 방법론의 WBS(Work breakdown structure) 템플릿을 가져와 기간을 넣고, 동시에 방법론 테일러링이라는 액티비티를 통해 프로젝트에 적합한 산출물을 어떻게 작성할 지 QA의 도움으로 정한다.

[Before: Waterfall 방식]

이러한 일련의 과정을 지나 PM이 QA가 작성한 내용을 기반으로 WBS를 수정하고 이를 확정 하면, 이 때부터 이 WBS를 기준으로 프로젝트를 관리하는 것이 시작되었다.

PM의 스타일에 따라 설계와 개발을 다르게 쓰기도 했는데, 액티비티 만으로는 상세한 진척관리를 할 수 없다고 WBS에 최초 프로젝트 안에서 개발하기로 한 정의된 기능명을 모조리 집어 넣는 경우도 있었고, WBS자체가 너무 무거워지는 경우에는, 이를 별도의 Excel로 관리하기도 했다.

프로젝트 초반에 회사/고객과 연관된 다양한 이벤트를 수행해야 할 때는, 이 WBS가 꽤나 좋은 기준이 되었다. 고객과 커뮤니케이션을 위한 도구였고, 고객에게 “자 우리 이렇게 하기로 합의 했었죠? 이 때까지는 무엇을 해주셔야 합니다. 이 때는 우리 모두 같이 모여 미팅해야 합니다” 등의 이야기를 말하는 도구로 쓰였다.

하지만, 개발이 시작되게 되면 완전히 다른 이야기가 되었다. 개발이 시작되는 순간, 어떤 기능이 얼마나 만들어졌는지에 대한 진척이 주마다 수행하는 미팅에 이야기가 주된 관심사 였고, WBS는 특별히 관심을 갖지 았다. 정부 프로젝트를 할 때 필수적으로 수행하는 감리 절차가 들어올 때 빼고는 WBS는 신경쓰지 않았다.

다시 말해 이때 부터는 개발 공정이 얼마나 늦어지고 있는데, 왜 늦어지는지가 늘 대화의 중심이었다.

대부분의 프로젝트는 타이트하게 일정이 수행되도록 일정이 짜여졌기 때문에, 고객과의 대립이 늘 발생할 수 밖에 없었다. 8개월의 기간이 있으면 분석-설계 기간인 3개월은 행복했다가 갑자기 4개월째부터 조금씩 문제의 전조가 보이고, 6개월정도가 되면 이 갈등은 극단으로 치닫는다.

개발이 2개월정도 수행되고 나면 중간보고라는 형식으로 고객에게 제품을 보여주는 이벤트를 하게 되는데, 이 때까지도 (예외는 있겠지만)보통 고객들은 제품에 도통 관심이 없다. 중간보고회 때 초대된 인물들이 해당 시스템을 쓰지 않는 인물일 수도 있고, 단 기간동안 정말 많은 화면을 그냥 ppt 형태로 보여주는 것은 청자 입장에서 그다지 감흥이 없다.

개발팀 입장에서도 이를 실제 쓰도록 하게 되면 발생한 버그에 대해 고객이 어떠한 반응을 보일 지 모르기 때문에, 실제 데모 환경을 제공하는 것은 현실적으로 조심스러웠다. 그리고 변경을 최소화 하려면, 보여주는 것을 최소화해야 된다는 생각이 뿌리 깊게 있었다. 불 필요한 제품의 노출은 추가 요구사항의 발생을 의미했다.

새로운 시도(Waterfall + Iteration)

우선 이 방법론을 변경하는 것, 늘 내 경험으로는 대충 작성하던 산출물을 완전히 하지 않는다고 선언하고 주변을 설득하는 것 은 당시 필자의 입장에서 매우 어려운 일이었다. 저항이 있었다.

역량과 경험은 부족했지만, 당시 난 전체 PL의 역할이었다. 그 역할을 이용하여 한 명 한 명 설득하기 시작했다.

그리고, 이터레이션을 통해, 일이 더 늘어나지 않도록 한다면, 선택과 집중을 하는 일이 필요했다. 기간이 늘어나거나 공수가 늘어난다면, 누구든 이에 동의하지 않을 것이기 때문이었다.

난 우선 설계와 개발 단계를 합치고, “설계/개발 이터레이션” 단계라 명명하였고, 설계와 개발 6개월의 기간을 이터레이션화 했다. WBS는 그냥 필자가 그렸다. 그리고 QA를 설득했다. QA는 우리 프로젝트를 지원하는 역할이었기에, 크게 이를 나무라지는 않았다. 그 때 최대한 스스로를 애자일 전문가라는 것처럼 이야기를 했던 것 같다.

[Waterfall 프로세스의 설계/개발 프로세스를 통합]

이터레이션을 몇 주로 가져갈 지에 따라 개발팀과 PM이 대립하는 양상을 보였는데, 개발팀은 가능하면 길게, PM은 가능하면 짧게 가져가고 싶어했다. 개발팀은 한 달 이상, PM은 1주일 정도로 가져가길 원했다. 나는 이 의사결정을 위해, 양 쪽 모두를 인터뷰 하고, 2주 정도의 서로가 이해할 만한 수준의 합의를 보게 했다.

[설계/개발 프로세스를 12개의 이터레이션으로 분리]

또한 이 이터레이션 마다 어떠한 액티비티와 산출물을 가져가야 하는지가 관건이었고, 나는 QA와 이 부분에 대해 협의하기 시작했다. 당시 기억하면, QA는 필자와 대화하는 것을 매우 싫어 했는데, 기존 산출물 작성에 대해 매우 부정적인 개발자였기 때문이다.

과거에는 일반적으로 다음과 같은 형태로 설계/개발이 진행되었다. (더 많은 산출물이 있었지만, 이들은 보통 1~2인이 작성하는 것들이었기에 생략하기로 한다)

[분석]
요구사항정의서, 아키텍처정의서
[설계]
화면목록/정의서, 유스케이스목록/정의서, 클래스 목록/정의서, 엔티티다이어그램, 테이블목록/정의서, 단위테스트시나리오, 통합테스트시나리오
[개발]
소스코드, 테스트결과서
[테스트]
통합테스트결과서

위 내용은 당시 소스코드를 제외하면 모두 문서였다. 프린트해야 했고, 이를 바인더로 보관해야 했다.

이를 작성했던 이유를 생각해보면 보통 유지보수에 필요하다는 명분 때문이었는데, 사실 심지어 유지보수할 때도 이 문서들을 보는 이는 거의 없었다.

여러가지 이유가 있었지만, 대부분의 개발자들은 문서를 믿지 않았다. 자신들의 경험을 빌면, 실제 유지보수 시 문서들을 업데이트 할 필요가 없었다. 코드를 보면 되었기 때문이다. 테이블 개수가 워낙 많아 공유를 위해 엔티티다이어그램 정도가 아니면 아무도 유지보수 기간동안 문서를 업데이트 하지 않았다.

위의 현실적인 이야기를 하면서 QA에게 문서를 이터레이션 마다 작성하지 않고, 중간감리(외부 담당자가 와서 프로젝트 상태를 점검하는 이벤트) 때 한번에 작성하자는 제안을 했다. 대신에 내가 추적성(Traceability)에 문제가 생기지 않게 책임을 지겠다고 했다.

중간 감리 시점이란 워터폴 프로세스를 염두한 것인데, 설계단계 이후 설계단계의 모든 산출물을 검증하는 것이었다. 하지만, 이터레이션은 설계/개발이 동시에 일어나니, 현실적으로 설계문서가 동일한 시점에 모두 나올 수가 없었다. 때문에, 설득을 통해 감리 전 설계산출물에 대해서만 검증하자고 제안했다. 대신 그동안 개발한 개발 목록과 테스트 결과를 보여주자고 했다.

그림으로 표현하면 아래와 같은 12개의 이터레이션 중 앞에 5개의 이터레이션에 개발할 항목에 대해 작성했고, 중간 감리때는 이 5번의 이터레이션에 대한 감리만 진행했다. 6번째 이터레이션은 이 산출물을 정리하는 시간으로 활용했다. (나중에 Clean up 이터레이션 라고 이름지었다) 감리인들이 프로젝트에 와서 산출물이 적은 것에 약간 당황 했으나, 특별한 문제는 없었다.

[감리 전 산출물 작성을 위한 이터레이션을 두었다.]

당시 이 사업의 감리는 두 번을 필수적으로 진행되도록 법으로 정해져 있었고, 첫번째는 중간감리(과거 설계문서를 주로 검증하던 감리), 두 번째는 최종감리(기능/아키텍처 검증 등)였다. 이 방식에 대한 관성 때문이었을까? 설계/개발을 통합하고 위와 같은 형태로 이터레이션을 만드니, 중간감리때 아래처럼 앞에 5개에 대한 산출물을 확인하고, 최종감리때 감리단이 들어왔을때는 이상하게도 뒤쪽 이터레이션 설계문서에 대해서는 감리단이 거의 들여다보지 않았다. 대신에, 테스트 결과에 보다 초점을 맞추는 것이었다. 결국 설계문서가 중요하지 않다는 것을, 그들도 증명해준게 아닌가 라는 생각을 조심스레 해본다.

산출물 바꾸기

이제부터 산출물 하나하나를 어떻게 풀어갔는지 이야기해보자

아키텍처정의서는 굳이 새로 작성될 필요가 없었다. 기존 시스템의 추가개발 사업이라, 이전 산출물을 그대로 복사하면 되었다.

화면목록/정의서는 화면설계의 주된 문서인데 초반에 작성하더라도 실제 코딩과 더불어 만들어진 화면이 디자인되면, 그것을 캡쳐해서 다시 붙이고 이벤트, 콤포넌트에 대해 다시 작성해야 하는 일이 빈번했다. 왜냐하면 화면 정의서를 작성할 단계에, 화면 콤포넌트가 무엇이 들어가야 할 지 구체적으로 전체를 알 수 없었다. 그래서 화면은 코드로 있으니, 만든 후 한번에 캡쳐 떠서 보관했다. 화면에 대한 상세한 스펙은 쓰지 않았다. 화면을 그리는 개발자가 개발도 하고 테스트도 하는데, 단순한 CRUD화면에 스펙을 쓰는 건 합리적이지 않았다.

유스케이스 목록/정의서는 업무설계의 주된 문서인데, CRUD가 중심인 개발 컨텍스트를 생각하면, 굳이 이를 작성할 만큼 복잡한 로직이 없었다. 클래스 목록/정의서 또한 문서로 정의하는 것보다, 실제 코딩을 하면서 역으로 작성하는 것이 대부분이었다. 차라리 주석을 적어 JAVA의 경우 JAVADOC 으로 문서를 만들어 내는 것이 현실적이었다.

엔티티 다이어그램은 데이터설계의 주된 문서인데, 요구사항 정의서에서 엔티티들을 찾아내고, 프로세스 정의서를 보며 어떠한 컬럼과 속성을 가져가야 하는지를 고민하게 되는데, 기존 레거시 시스템에 이미 만들어진 ERD가 있기 때문에, 이를 개념화 → 논리화 → 물리화하는 것은 실제로 굳이 필요하지 않았다.

또한 단위테스트시나리오는 유스케이스 시나리오의 동어반복 같은 느낌이었다. 특별히 문제가 생기지 않는 한 단위테스트를 문서로 작성할 필요가 없다는 것에 대한 공감대가 이미 형성되어 있었기 때문에, 테스트 체크리스트로 대체하고 개발자별로 이 체크리스트를 보고 테스트를 했다는 사인을 받았다. (지금 생각하면 정말 이게 무슨 가치가 있는지 싶다) 통합테스트시나리오는 외부 테스트를 위해 기존처럼 작성했다.

무엇보다 고객이 관심있는 문서는 요구사항정의서와 액티비티로는 “시연” 밖에 없었다.

이를 어렵게 설득하고, 프로젝트를 시작했다. 그리고 개발자들에게 설계/개발 이터레이션 동안 작성해야 할 문서들에 대해 정의했다. 그것은 화면정의서와 엔티티정의서의 업데이트 그리고 소스코드 였다.

[분석]
요구사항정의서(작성),
아키텍처정의서(재활용)

[설계]
화면목록/정의서(감리전, 마지막에 한번에 작성)
유스케이스목록/정의서(작성하지 않음),
클래스 목록/정의서(Javadoc으로 대체),
엔티티다이어그램(재활용),
테이블목록/정의서(재활용),
단위테스트시나리오(체크리스트로 대체),
통합테스트시나리오(개발 후 작성)

[개발]
소스코드(작성),
테스트결과서(작성)

[테스트]
통합테스트결과서(5 page 분량 ppt 로 작성)

지금 돌아보면 (회사를 잘 몰랐어서 그랬는지) 무모했고, 이러한 방식에 공감하지 못하는 사람도 주변에 많이 있었다. 하지만, 한 가지 필자가 정말 가치있다고 생각하는 것이 있는데,
그것은 위와 같이 프로세스의 무게를 줄이려 했던 시도가 결국 나와 함께한 개발자에게 자신의 코드 품질에집중할 시간을 주었다는 것이다.

노파심에, 혹시나 이 글을 읽으면서 필자가 특별한 상황이 좋았네, 내가 처한 상황과는 다르네라고 생각할 분들 위해 말씀드리고 싶다.

“언제나, 어디서나, 어떻게든 지금 상황을 개선 시킬 수 있는 방법은 있다"

필자가 14년간 해온 20개 남짓 프로젝트 중 어느 프로젝트도, 새로운 시도를 해보라던 곳은 없었으니까…