2장. 팀#4
#2-3 SI 프로젝트에 애자일을 적용할 수 있는가?
#2-3 SI 프로젝트에 애자일을 적용할 수 있는가?
* 지금 내가 하는 것이 과연 애자일인가?
필자가 작성한 일기를 통해, 애자일 팀과 어떻게 일했는지에 대한 궁금증이 조금은 해소됐으리라 생각한다. 하지만 방법론/프로세스 측면으로 과연 어떻게 진행했을지 궁금할 것이다. ‘08년도 S사의 당시의 개발 방법론은 모두 워터폴이었다. 심지어 공공 프로젝트에는 매우 엄격한 감리라는 과정이 있었다.(현재도 있다.) 외부의 감리사들이 프로젝트에 찾아와 산출물을 점검하여 정해진 프로세스를 준수했는지를 검증했다. (향후 상시 감리로 변경되었다) 당시 공공사업에는 애자일을 통한 짧은 개발 주기라는 콘셉트 자체도 매우 급진적인 접근이었다.
혹시나 본인이 처한 상황이 모두가 워터폴 프로세스를 쓰고 있는데, 본인은 애자일의 무언가를 시도하고 싶은 분들이 있는가? 주변 환경을 바꿀 수 있는 여건은 안되지만 지금 있는 환경에서 프로세스적인 애자일을 시도하고 싶은 분들을 위해 필자의 경험을 공유드리고 싶다.
지금 보면, “이것이 과연 애자일인가?”라는 질문을 받을 수 있을 만큼 매우 워터폴에 가까운 애자일 방식이었고, 애자일을 통해 반드시 얻어야 하는 사용자의 가치에는 그다지 근접하지 못한 방식이었다. 하지만, 당시 고객과 회사와 엮인 단단한 프로세스 상에서 약간의 유연함을 부여할 수 있는 시도였다고 생각한다. 그리고 필자가 근무하던 회사는 아예 없던 이터레이션(짧은 주기 개발)이라는 기법을 최초로 도입했던 시도이기도 했다.
그럼 이야기를 시작해 보자. 혼자서 담당하던 코드를 만지며, 일부 애자일 기법 등을 수행했던 경험을 여러 차례 거친 후, 4년 차의 개발자가 “이제는 애자일 방식으로 프로젝트를 수행하고 싶습니다”라는 용기 있는 말을 던진 후 필자가 속한 프로젝트에서 제일 먼저 했던 고민은 애자일의 가장 큰 특징 중 하나인 이터레이션을 어떻게 프로세스에 녹일지였다.
당시의 상황을 좀 설명하자면,
개요: 70명 규모의 13개월 기간의 대형 SI 프로젝트 이후, 추가 계약 사업이 만들어졌다. 8개월 정도 추가 기능을 만드는 작업이었다.
아키텍처: 대형 SI 프로젝트의 아키텍처를 그대로 재사용하는 모델이었다.
팀: 13명이었다. 프로젝트 관리자는 수년간의 경험을 통해 폭포수 방법론을 이용하는 것에 잔뼈가 굵은 사람이었지만 필자와 신뢰 관계가 있었고 당시 프로세스를 담당하는 품질담당자는 회사의 표준을 제시하며, 그에 따라 프로젝트를 온전히 수행하게 하는 하는 책임이 있었다. 그는 회사의 프로세스와 산출물을 그대로 따르도록 가이드해야 했기에, 이를 어기는 것은 매우 큰 문제라 인지하였다.
프로세스: 회사의 방법론은 전형적인 워터폴이었다. 분석이 끝나고 모든 산출물이 작성 완료되면, 설계 단계에 들어갔고, 설계단계가 온전히 완료되면 개발에 들어갔고, 이후 테스트가 되었다. 방법론이라는 말에 대해 익숙하지 못할 독자를 위해 조금 설명한다면, 기본적으로 방법론이라는 것은 다음과 같이 구성되는데, 그것은 프로세스 + 툴 + 가이드이다. 그리고 프로세스는 단계별 / 액티비티 별로 쪼개져 역할과 책임, 그 액티비티의 입력 물과 출력물이 정의되어 있었다.
동일한 도메인에서 수행된 이전 프로젝트에서는 8개월의 프로젝트 기간이 있으면 경험적 접근에 따라 분석-1개월, 설계-2개월, 개발-4개월, 테스트-1개월 정도의 기간으로 나누었다. 그리고 회사가 제공하는 프로젝트 성격에 맞는 방법론의 WBS(Work breakdown structure) 템플릿을 가져와 기간을 넣고, 동시에 방법론 테일러링이라는 액티비티 보완을 통해 프로젝트에 적합한 산출물을 어떻게 작성할지 정했다.
Before: Waterfall 방식이러한 일련의 과정을 반복하고 보완했다. 품질담당자가 작성한 WBS를 기반으로 보다 현실에 맞게 프로젝트 관리자가 수정하고 확정하면 이때부터 이 WBS를 기준으로 프로젝트 관리가 시작되었다.
프로젝트 관리자의 스타일에 따라 설계와 개발과 관련된 액티비티 수준을 다르게 쓰기도 했는데, 관리를 보다 철저하게 하기 위해 WBS에 최초 프로젝트 안에서 개발하기로 한 정의된 기능명을 모조리 집어넣는 경우도 있었고, WBS자체가 너무 무거워지면 수정하기 어렵기에 이를 별도 엑셀로 관리하기도 했다. 프로젝트 초반에 회사/고객과 연관된 다양한 이벤트를 수행해야 할 때는, 이 WBS가 좋은 기준이 되었다. 고객과 커뮤니케이션을 위한 도구였고, 고객에게 “자 우리 이렇게 하기로 합의했었죠? 이때까지는 무엇을 해주셔야 합니다. 이 때는 우리 모두 같이 모여 미팅해야 합니다” 등의 이야기를 말하는 도구로 쓰였다.
하지만, 개발이 시작되게 되면 완전히 다른 이야기가 되었다. 개발이 시작되는 순간, 어떤 기능이 얼마나 만들어졌는지에 대한 진척 결과가 매주 수행하는 미팅의 주된 관심사였고, WBS에 대한 관심은 점점 멀어졌다.
프로젝트는 늘 빡빡하게 수행되도록 일정이 짜였고 예산에 대한 압박이 있었기에, 필자의 경험으로는 진척이 계획보다 느린 경우가 대부분이었다. 8개월의 기간이 있으면 분석-설계 기간인 3개월은 별 문제가 없었다가 기능 개발 결과가 투명하게 공유되는 순간인 4개월째부터 고객과 대립이 생기다 진척이 커다란 문제가 되는 6개월 정도가 되면 이 갈등은 극단으로 치닫는다.
흥미로운 것은 개발이 2개월 정도 수행되고 나면 중간보고라는 형식으로 고객에게 제품을 보여주는 이벤트를 하게 되는데, 이때까지도 (예외는 있겠지만) 보통 고객들은 제품에 도통 관심이 없다. 중간보고회 때 초대된 인물들이 해당 시스템을 쓰지 않는 인물일 수도 있고, 단 기간 동안 정말 많은 화면을 그냥 파워포인트 화면 캡처 형태로 보여주는 것은 청자 입장에서 그다지 감흥이 없다.
개발팀 입장에서도 이를 실제 쓰도록 하게 되면 발생한 버그에 대해 고객이 어떠한 반응을 보일지 모르기 때문에, 실제 데모 환경을 제공하는 것은 현실적으로 조심스러웠다. 그리고 변경을 최소화하려면, 보여주는 것을 최소화해야 된다는 생각이 뿌리 깊게 박여 있었다. 불 필요한 제품의 노출은 추가 요구사항의 발생을 의미했다.
그들의 습관이었던 폭포수 방법론을 낯선 애자일 방식으로 변경한다는 것 자체가 모두에게는 부담이었다. 고객을 비롯한 주변을 설득하는 것 은 당시 필자의 입장에서 매우 어려운 일이었다. 실제로 늘 저항이 있었다. 하지만, 시간을 두고 주변의 한 명 한 명을 설득했다. 이터레이션을 수행하면 액티비티를 한 번에 수행하는 것보다 경험적으로 더 일이 늘어날 것이라 생각하는 사람들이 많았다. 이들을 설득하는 것은 특히 어려웠다. 요구사항에 대한 변경을 더 조기에 잡을 수 있기 때문에 결과적으로는 공수가 준다고 이야기했다.
* 설계 + 개발 이터레이션의 탄생
필자는 프로젝트 이해관계자들과 협의하여 우선 설계와 개발 단계를 합치고, “설계/개발 이터레이션” 단계라 명명하였고, 설계와 개발 6개월의 기간을 이터레이션화 했다. WBS는 먼저 필자가 작성하고 품질 담당자를 설득했다. 품질 담당자는 우리 프로젝트를 지원하는 역할이었기에, 크게 이를 걱정하지는 않았다. 그때 최대한 스스로를 애자일 전문가라는 것처럼 이야기를 했던 것 같다.
Waterfall 프로세스의 설계/개발 프로세스를 통합이터레이션을 몇 주로 가져갈 지에 따라 개발팀과 프로젝트 관리자 서로가 대립하는 양상을 보였는데, 개발팀은 가능하면 길게, 프로젝트 관리자는 가능하면 짧게 가져가고 싶어 했다. 개발팀은 한 달 이상으로 프로젝트 관리자는 1주일 단위로 정하길 원했다. 이 의사결정을 위해, 양 쪽 모두를 인터뷰하고, 2주 정도의 서로가 이해할 만한 수준의 합의를 보게 했다.
설계/개발 프로세스를 12개의 이터레이션으로 분리또한 이 이터레이션마다 어떠한 액티비티와 산출물을 가져가야 하는지가 관건이었고, 필자는 품질담당자와 이 부분에 대해 협의했다. 당시를 뒤돌아보면, 품질 담당자는 필자와 대화하는 것을 매우 싫어했는데, 기존 산출물 작성에 대해 매우 부정적인 인상을 가진 개발자였기 때문이다.
과거에는 일반적으로 다음과 같은 형태로 설계/개발이 진행되었다. (더 많은 산출물이 있었지만, 이들은 보통 프로젝트 전체에서 한 명 정도가 작성하는 것들이었기에 생략하기로 한다)
[분석] (1) 요구사항 정의서/추적표, (2) 아키텍처 정의서
[설계] (3) 화면 목록/정의서, (4) 유스 케이스 목록/정의서, (5) 클래스 목록/정의서,
(6) 엔티티 다이어그램, (7) 테이블 목록/정의서, (8) 단위 테스트 시나리오, (9) 통합 테스트 시나리오
[개발] (10) 소스코드, (11) 테스트 결과서
[테스트] (12) 통합 테스트 결과서
위 내용은 당시 소스코드를 제외하면 거의 모든 것이 물리적인 문서였다. 원칙상 프린트해야 했고, 이를 바인더로 보관해야 했다. 이를 프린트하여 보관했던 이유를 생각해보면 보통 유지보수에 필요하다는 명분 때문이었는데, 사실 심지어 유지 보수할 때도 이 문서들을 보는 이는 거의 없었다.
산출물 바인더프로젝트의 구성원들은 사실 문서를 그다지 믿지 않았다. 왜냐하면, 자신들의 경험으로 볼 때, 실제 유지보수 시 문서들을 업데이트할 필요가 없었다. 코드를 보면 되었다. 테이블 개수가 워낙 많아 내부 공유를 위해 엔티티 다이어그램 정도가 아니면 아무도 문서에 대해 유지보수 기간 동안 업데이트하지 않았다.
위의 이야기를 하면서 품질 담당자에게 문서를 이터레이션마다 작성하지 않고, 중간 감리(외부 담당자가 와서 프로젝트 상태를 점검하는 이벤트) 때 한 번에 보완하자는 제안을 했다. 대신에 필자가 요구사항 추적표를 통한 문서 추적성(Traceability)에 문제가 생기지 않게 책임을 지겠다고 했다.
* 클린업 이터레이션을 통한 산출물 정리
중간 감리란 설계단계 종료 시 설계단계의 모든 산출물을 검증하는 것이었다. 하지만, 이터레이션은 설계/개발이 동시에 일어나니, 현실적으로 설계문서가 동일한 시점에 모두 나올 수가 없었다. 때문에, 설득을 통해 감리 전 설계 산출물에 대해서만 검증하자고 제안했다. 대신 그동안 개발한 개발 목록과 테스트 결과를 보여주자고 했다.
그림으로 표현하면 아래와 같은 12개의 이터레이션 중 앞에 5개의 이터레이션에 개발할 항목에 대해 작성했고, 중간 감리 때는 이 5번의 이터레이션에 대한 감리만 진행했다. 6번째 이터레이션은 이 산출물을 정리하는 시간으로 활용했다. (나중에 Clean up 이터레이션라고 이름 지었고, 전사 표준처럼 가이드되었다.) 감리인들이 프로젝트에 와서 산출물이 적은 것에 약간 당황했으나, 특별한 문제는 없었다.
감리 전 산출물 작성을 위한 이터레이션을 두었다.당시 이 사업의 감리는 두 번을 필수적으로 진행되도록 법으로 정해져 있었고, 첫 번째는 중간 감리(과거 설계문서를 프로세스 관점에서 주로 검증하던 감리), 두 번째는 최종 감리(프로덕트 관점에서 기능/아키텍처 검증 등)였다. 이 방식에 대한 관성 때문이었을까? 설계/개발을 통합하고 위와 같은 형태로 이터레이션을 만드니, 중간 감리 때 아래처럼 앞에 5개에 대한 산출물을 확인하고, 최종 감리 때 감리단이 들어왔을 때는 이상하게도 뒤쪽 이터레이션 설계문서에 대해서는 감리단이 거의 들여다보지 않았다. 대신에, 테스트 결과에 보다 초점을 맞추는 것이었다. 결국 설계문서가 당시 별로 의미가 없었다는 것을, 그들도 증명해준 게 아닌가 라는 생각을 조심스레 해본다.
이제부터 산출물 하나하나를 어떻게 달리 썼는지를 이야기해보자
(1) 요구사항 정의서/추적표: 열심히 작성했다.
(2) 아키텍처 정의서: 굳이 새로 작성될 필요가 없었다. 기존 시스템의 추가 개발 사업이라, 이전 산출물을 그대로 복사하면 되었다.
(3) 화면 목록/정의서: 화면 설계의 주된 문서인데 초반에 작성하더라도 실제 코딩과 더불어 만들어진 화면이 디자인되면, 그것을 캡처해서 다시 붙이고 이벤트, 컴포넌트에 대해 다시 작성해야 하는 일이 빈번했다. 왜냐하면 화면 정의서를 작성할 단계에, 화면 컴포넌트가 무엇이 들어가야 할지 구체적으로 전체를 알 수 없었다. 그래서 화면은 코드로 있으니, 만든 후 한 번에 캡처 떠서 보관했다. 화면에 대한 상세한 스펙은 쓰지 않았다. 화면을 그리는 개발자가 개발도 하고 테스트도 하는데, 단순한 등록/수정/삭제/조회 화면에 스펙을 쓰는 건 합리적이지 않았다.
(4) 유스 케이스 목록/정의서: 업무 설계의 주된 문서인데, 등록/수정/삭제/조회가 중심인 개발 콘텍스트를 생각하면, 굳이 이를 작성할 만큼 복잡한 로직이 없었다. 클래스 목록/정의서 또한 문서로 정의하는 것보다, 실제 코딩을 하면서 역으로 작성하는 것이 대부분이었다. 차라리 주석을 적어 JAVA의 경우 JAVADOC으로 문서를 만들어 내는 것이 현실적이었다.
(5) 엔티티 관계 다이어그램: 데이터 설계의 주된 문서인데, 요구사항 정의서에서 엔티티들을 찾아내고, 프로세스 정의서를 보며 어떠한 칼럼과 속성을 가져가야 하는지를 고민하게 되는데, 기존 레거시 시스템에 이미 만들어진 엔티티 관계 다이어그램이 있기 때문에, 이를 개념화 → 논리화 → 물리화하는 것은 실제로 굳이 필요하지 않았다.
(6) 단위 테스트 시나리오: 유스 케이스 시나리오의 동어반복 같은 느낌이었다. 특별히 문제가 생기지 않는 한 단위 테스트를 문서로 작성할 필요가 없다는 것에 대한 공감대가 이미 형성되어 있었기 때문에, 테스트 체크리스트로 대체하고 개발자별로 이 체크리스트를 보고 테스트를 했다는 사인을 받았다. (지금 생각하면 정말 이게 무슨 가치가 있는지 싶다)
(7) 통합 테스트 시나리오: 외부 테스트를 위해 열심히 작성했다.
사실상 고객이 관심 있는 문서는 요구사항 정의서와 액티비티로는 “시연” 밖에 없었다. 이를 어렵게 설득하고, 프로젝트를 시작했다. 그리고 개발자들에게 설계/개발 이터레이션 동안 작성해야 할 문서들에 대해 정의했다. 그것은 화면 정의서와 엔티티 정의서의 업데이트 그리고 소스코드였다.
[분석] 요구사항 정의서(작성), 아키텍처 정의서(재활용)
[설계] 화면 목록/정의서(감리 전, 마지막에 한 번에 작성)
유스 케이스 목록/정의서(작성하지 않음), 클래스 목록/정의서(Javadoc으로 대체),
엔티티 다이어그램(재활용), 테이블 목록/정의서(재활용),
단위 테스트 시나리오(체크리스트로 대체), 통합 테스트 시나리오(개발 후 작성)
[개발] 소스코드(작성), 테스트 결과서(작성)
품질을 보는 관점은 크게 두 가지가 있다. 한 가지는 프로세스를 보는 것이고, 또 다른 하나는 프로덕트 관점에서 보는 것이다. 프로세스를 보는 이유는 프로세스를 잘 지키면 좋은 제품이 된다라는 가정에서 인데, 이 프로세스는 늘 더 나은 방식으로 개선될 필요가 있다. 프로세스라는 것이 각종 노하우들을 표준화한 것이나, 프로젝트의 모든 상황을 표준에 맞추는 것은 현실적으로 어렵기 때문에, 불필요한 것은 제거하고, 더 필요한 것을 추가하는 유연함 또한 필요하다고 필자는 생각한다.
