[Phase#5] 애자일 아키텍처(?)
애자일을 수행할 때 가장 모호하다고 이야기 하는 것 중, 애자일 아키텍처라는 말이 있다. 이 말은 여전히 국내 IT 시장에서 정의하기 어려운 말로 통용된다. 이를 이해하기 위해 먼저, 애자일 아키텍처라는 말이 어디에서 나왔는지를 잠시 살펴보자.
1994년에 DSDM(Dynamic systems development method)이라는 프로젝트 딜리버리 프레임웍이 발표되었다. 이는 빠르게 개발을 하기 위해 만들어진 RAD(rapid application development ) 라는 방식에서 발전되어 애자일 프로세스의 한 기조로 자리잡았다. 이 프로세스는 과거 XP, 스크럼처럼 개발 자체에 중심을 둔 방식과는 다르게, 프로젝트 관리와 거버넌스에 중심을 두었다. 때문에 추후 확장되어 IT가 아닌 영역에서도 많이 사용되는 프레임웍으로 발전했다.
DSDM의 여러가지 원칙 중에 “확고한 기초(Firm foundations) 위에 점진적으로 제품을 만든다” 라는 것이 있다. 이 확고한 기초라는 말이 이후 2008년에 딘 레핑웰이라는 소프트웨어 아키텍트를 통해 해석되어 필요한 만큼(Just Enough) 구축하는 애자일 아키텍처라는 말로 발전되었다.
그렇다면 “필요한 만큼” 은 얼마만큼의 준비를 이야기 하는 것일까? 이 부분이 현실에서 적용될 때 애매한 부분이다. 이는 이해관계자 관점에서 다를 수가 있다. 특히나 모두 워터폴을 경험했던 인력 구성원이라면 더욱 그럴 것이다.
이 부분이 애자일 아키텍처라는 말에 대해 많은 사람들이 모호하다는 이야기를 하는 지점이다. 만약 여러분의 팀이 4~5명 규모의 작은 팀으로 시작하여 점점 SW 크기를 불려나갔다면 이러한 모호함은 발생하지 않을 것이다. 아키텍처가 상황에 따라 적응하며 자연스레 함께 성장하기 때문이다.
하지만, 50명 이상 프로젝트에 갑자기 애자일 아키텍처를 적용한다고 했을때는 상황이 달라진다. 많은 문제들이 발생할 수 있다. 이전 Phase에서 이야기했던 프로젝트의 이야기를 계속해보자. (물론 비즈니스를 이렇게 하면 안되다는 논쟁을 벌일 독자도 있을꺼라 생각한다. 필자도 그 말에 동의한다. 하지만, 그 논란은 뒤로 미루자. 현실에서 여러가지 전략적인(?) 이유로 최초부터 많은 인력을 투입하는 프로젝트는 여전히 있다.)
* 설계/개발 이터레이션 수행시 발생한 아키텍처관련 문제점
커뮤니케이션 방식이 바뀌면서 프로젝트는 한결 대화가 많아졌다. 하지만 모든 문제가 순조롭게 해결되기 보다는 오히려 더 많은 문제들이 발생한 것처럼 보였다.
개발자들로부터 상향식으로 이슈가 전달되는 공식적인 채널이 생기면서, 기본적으로 이슈의 양부터 많아졌다. 그리고 중간관리자들은 이를 정제하고 의논해야 했기에 더 많은 시간 회의와 타 팀과의 협업에 매달렸다. 중복된 것은 제거하고 다른 팀에 비슷한 이슈가 있는 것을 확인하여 이를 우선순위화 했다. 그리고 프로젝트 관리자는 이를 해결하기 위해 노력했다.
설계/개발 기간을 통합하여 이터레이션을 돌리다보니, 이전과의 이슈의 종류가 많이 달랐다. 과거에는 주로 협업, 고객과의 커뮤니케이션에 대한 것이 많았다면, 이번 프로젝트는 대부분 아키텍처와 공통기능에 대한 내용이 대부분이었다. 짧은 납기에 많은 것을 개발해야 하는 개발자들은 다음과 같이 목소리를 높이며 이야기했다.
“내가 개발하기 위해 준비된 것이 없다”
설계/개발의 이터레이션 초기에 개발자들은 아키텍처와 공통 기능 때문에, 개발을 할 수 없다고 이야기 했다. 이 말을 듣고 아키텍처/공통팀에 가보니, 이들은 며칠째 밤샘을 하며 기능을 개발하고 있었다. 그리고,
“애자일은 우리에게 너무 힘들다”
라며, 얼마나 그들이 어려움을 겪고 있는지 표현했다.
과거 워터폴 방식으로 프로젝트를 수행했던 경험을 다시 기억해보자. 위 상황을 설명하기 위해 일반적인 13개월 짜리 워터폴 프로젝트를 생각해보자. 그리고 분석 2개월, 설계 3개월, 개발 6개월, 테스트 2개월 단위로 나누었다고 가정하자.
일반적으로 50명 이상 규모의 프로젝트가 되면 아키텍처/공통을 담당하는 팀을 전담으로 배치한다. 왜냐하면 로그인, 세션, 로깅, 업무 공통 기능 같은 경우 업무 개발팀 중 누가 개발해야 할 지 애매한 경우가 많기 때문이다.
이들은 분석 단계 2개월 동안 정의된 요구정의 내용을 기반으로 기능들을 도출하여 설계 기간 3개월 통한 업무팀이 투입되기 전 대부분의 필요 아키텍처 및 공통 기능을 개발하기 위해 노력한다. 이를 통해 다음 시작되는 개발 단계에 개발자들이 활용할 수 있는 다양한 기능들을 준비해 놓는다.
물론 개발단계에서도 이 작업은 계속된다. 실제 업무 개발팀에서 피드백을 받지않고 만든 아키텍처나 공통 기능은 아직 부족한 것이 많다. 때문에 아키텍처/공통 기능팀의 개발자들은 업무 개발팀의 개발자들과 이야기 하면서, 지속적으로 이를 수정하며 보완해 나간다.
이 피드백을 받아 보완한다는 것은 업무 개발팀 입장에서는 필연적인 재작업을 의미한다. 아키텍처/공통 기능팀의 개발자가 피드백을 받아 아키텍처를 변경하면 전체 업무 개발자들이 이를 다시 반영해야 하기에 이미 개발해 놓은 기능에 대해 다시 작업하는 일은 필연적으로 발생한다. 이는 표준이 변경되는 것을 의미한다.
때문에 이를 개발 단계 초기에 잡느냐 잡을 수 없느냐가 프로젝트의 성패와 긴밀한 관계가 있다. 이를 개발자들이 기능개발을 많이 하지 않은 조기에 해결하면 그만큼의 재작업 공수가 적게들고 개발 단계 뒤로 가면 갈수록 공수는 기하급수적으로 늘어난다.
애자일을 수행한다고 하면서, 단순하게 설계/개발 단계를 합쳐 이터레이션을 수행한다고 가정해보자. 위와 같은 상황과 엮이면 어떠한 문제가 발생할까? 설계 단계 3개월이 없어지면서 아키텍처/공통 기능 개발자들은 준비할 물리적 시간을 부여받지 못하게 된다.
설계/개발 이터레이션이 진행되면서 미완된 기능을 개발하는 것과 개발자들의 피드백을 동시에 받는 일이 진행된다. 아키텍처/공통팀은 굉장한 압박을 받게 된다. 이들은 개발팀에 필요한 것들을 제공해주기 위해 최선을 다하나, 물리적인 준비 시간 자체가 부족하다.
해당 프로젝트에서는 14회에 걸쳐 전체적인 개발의 영향을 주는 아키텍처와 공통기능이 크게 변경되는 일이 발생했다. 이는 개발자들의 피로감으로 이어졌고, 프로젝트에 있는 모두가 이를 버거워했다.
애자일은 이터레이션을 통해 고객 피드백을 받아 소프트웨어를 지속적으로 개선하는 작업이다. 이는 분명히 프로젝트 성공에 도움이 된다. 하지만, 대규모 인력이 한번에 참여해야 하는 비즈니스 상황에서는 무조건 이터레이션을 너무 빨리 수행하려고 하지 말자. 필연적으로 준비하는 기간이 필요하다. 그리고 이후 쇼케이스를 통해 고객 피드백을 받으면 된다.
Phase #2에서 설명한 프로젝트는 다른 경우이다. 당시 프로젝트는 기존에 존재했던 아키텍처 위에 개발이 수행된 형태였다. 이러한 경우는 위 같은 문제가 발생하지 않는다. 이 경우는 이터레이션을 아주 초반부터 수행해도 문제가 없다.
이 두가지의 차이가 어찌보면 ‘필요한 만큼’의 경험적 정의가 아닐까 싶다.
- 작은 팀(4~6명의 개발자)이 비즈니스 상황에 따라 인력이 늘어나는 경우는 아키텍처 준비기간이 필요 없다. 이경우 그냥 만들고 고쳐나가면 된다.
- 50명 이상의 프로젝트에서 기존 아키텍처 위해 기능 개선하는 상황에서는 아키텍처를 위한 준비기간이 필요 없다. 그냥 바로 개발을 시작해도 된다.
- 50명 이상의 신규 프로젝트에서는 반드시 아키텍처링과 공통 기능을 위한 준비기간이 필요하다.
필자의 은사이신 일리노이 주립대학의 랄프 존슨(Ralph Johnson) 교수에게 09년 전화 통화로 위와 같은 질문을 한 적이 있다.
“제가 120명 규모의 애자일 프로젝트를 수행하는데, 혹자는 애자일이기 때문에 아키텍처링이 필요 없다고 합니다. 어떻게 생각하시나요?”
교수님은 다음과 같은 명쾌한 답을 주었다.
“나는 그런 말도 안되는 이야기를 들어본 적이 없다. 한번에 많은 기능을 개발해야 하는 비즈니스 상황에서는 아키텍처링이 반드시 필요하다. 혹시 그 질문을 했던 분이 프로젝트를 한번도 수행해 보지 않은 것은 아닌가?”
금번 경험을 통해 이후 수행하는 프로젝트 부터는’이터레이션 0’ 라는 개념을 도입하기 시작했다. 50명 이상의 프로젝트에서는 1~2개 정도의 이터레이션은 최소의 개발인원이 들어와 현재의 기능 전체를 보고 나중에 투입될 업무 개발자들을 위해 아키텍처링과 공통기능을 만들었다. 그 뒤로는 위와 같은 문제가 현저히 줄었다.
위와 같은 이유로, TCS, 와이프로, 코그니전트, 사피엔트 같은 대형 구축형 사업을 주로 서비스하는 인도 회사들은 이터레이션 0를 먼저 진행한다. 이 기간동안 ‘필요한 만큼’ 의 아키텍처링을 수행한다.