3장. 애자일 전도사#3

#3-3 애자일 아키텍처

#3-3 애자일 아키텍처

애자일 방식으로 소프트웨어를 개발할 때 가장 모호하다고 얘기하는 기법이 있다. 그것은 바로 애자일 아키텍처라는 개념이다. 개념이 나온지 꽤 오래되었지만, 현재도 여전히 정의하기 어려운 말로 통용된다. 이를 이해하기 위해 먼저, 애자일 아키텍처라는 말이 어떻게 유래되었는지 잠시 살펴보자. 

'94년 DSDM(Dynamic systems development method)이라는 프로젝트 딜리버리 프레임웍이 발표되었다. 이는 빠르게 개발을 하기 위해 만들어진 RAD(rapid application development ) 라는 방식에서 발전되어 애자일 프로세스의 한 기조로 자리잡았다. 이 프로세스는 과거 XP, 스크럼처럼 개발 자체에 중심을 둔 방식과는 다르게, 프로젝트 관리와 거버넌스에 중심을 두었다. 추후 확장되어 IT가 아닌 영역에서도 많이 사용되는 프레임웍으로 발전했다. 

이 DSDM의 원칙들 중 “확고한 기초(Firm foundations) 위에 점진적으로 제품을 만든다” 라는 것이 있다. 이 확고한 기초라는 말이 이후 2008년에 딘 레핑웰이라는 소프트웨어 아키텍트를 통해 해석되어 필요한 만큼(Just Enough) 구축하는 애자일 아키텍처라는 말로 발전되었다. 필자는 이러한 진화가 정말 의아했다. '확고한 기초 -> 필요한 만큼'은 느낌상 많이 다른 느낌이다. '필요한 만큼 확고한 기초'라는 의미일까? 

[딘 레핑웰, SAFe의 창시자로 잘 알려져 있다]

아무튼, “필요한 만큼 확고한 기초”는 얼마만큼의 준비를 이야기 하는 것일까? 이 부분이 현실에서 적용될 때 매우 애매한 부분이다. 다양한 이해관계자들에 때라 다르게 해석될 여지가 있다. 특히나 워터폴을 경험했던 인력이 애자일을 활용해야 하는 상황이라면 더욱 그럴 것이다. 

만약 여러분의 팀이 4~5명 규모의 작은 팀으로 시작하여 점점 SW 크기를 불려나가는 인하우스(Inhouse) 개발을 한다면 이러한 모호함은 크게 문제가 되지 않는다. 아키텍처를 상황에 따라 변경하며 자연스레 함께 성장시키면 되기 때문이다. 하지만, 처음부터 50명 이상이 함께 수행해야 하는 프로젝트에 갑자기 애자일 아키텍처를 적용한다고 했을때는 상황이 달라진다. 이전의 접근과는 매우 다른 차이가 발생할 수 있다. 

다시 이전 챕터에서 이야기했던 100+명 대규모 프로젝트로 돌아가보자. 

* 설계/개발 이터레이션 수행 시 발생한 아키텍처 문제 

커뮤니케이션 방식이 바뀌면서 프로젝트는 한결 대화가 많아졌다. 하지만 모든 문제가 순조롭게 해결되기 보다는 오히려 더 많은 문제들이 발생한 것처럼 보였다. 기존에 가려졌던 문제들이 봇물 터지듯 터져나오기 시작했다. 

상향식으로 이슈가 빠르게 전달되는 공식적인 채널이 생기면서, 기본적으로 이슈의 양부터 많아졌다. 그리고 중간관리자들은 이를 정제하고 의논해야 했기에 더 많은 시간 회의와 타 팀과의 협업을 해야했다. 중복된 것은 제거하고 다른 팀에 비슷한 이슈가 있는 것을 확인하여 이를 우선순위화 했다. 이전보다 나아지긴 했으나 훨씬 바빠졌다. 

설계/개발 기간을 통합하여 이터레이션을 진행하다보니, 이전과 다른 이슈들이 발생했다. 과거에는 주로 협업, 고객과의 커뮤니케이션에 대한 것이 많았다면, 대부분 아키텍처와 공통기능에 대한 불만이 대부분이었다. 짧은 납기에 많은 것을 개발해야 하는 개발자들은 다음과 같이 목소리를 높이며 이야기했다. 

 “내가 기능 개발하기 위한 공통기능이 전혀 준비되어 있지 않다.” 

설계/개발의 이터레이션 초기에 개발자들은 아키텍처와 공통 기능 때문에, 개발을 할 수 없다고 이야기 했다. 이 말을 듣고 아키텍처/공통팀에 가보니, 이들은 며칠째 밤샘을 하며 기능을 개발하고 있었다. 그리고 그들은 볼멘소리로 이야기 했다. 

“애자일 방식은 우리 공통팀을 쥐잡듯 잡는 프로세스다.” 

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

왜 이러한 상황이 발생했을가? 

과거 워터폴 방식으로 프로젝트를 수행했던 경험을 다시 기억해보자. 위 상황을 설명하기 위해 일반적인 13개월 짜리 워터폴 프로젝트를 생각해보자. 그리고 분석 2개월, 설계 3개월, 개발 6개월, 테스트 2개월 단위로 나누었다고 가정하자. 

[워터폴의 아키텍처 기간]

일반적으로 50명 이상 규모의 프로젝트가 되면 아키텍처/공통을 담당하는 팀을 전담으로 배치한다. 왜냐하면 로그인, 세션, 로깅, 업무 공통 기능 같은 경우 업무 개발팀 중 누가 개발해야 할 지 애매한 경우가 많기 때문이다. 

이들은 분석 단계 2개월 동안 정의된 요구정의 내용을 기반으로 기능들을 도출하여 설계 기간 3개월 통한 업무팀이 투입되기 전 대부분의 필요 아키텍처 및 공통 기능을 개발하기 위해 노력한다. 이를 통해 다음 시작되는 개발 단계에 개발자들이 활용할 수 있는 다양한 기능들을 준비해 놓는다. 

물론 개발단계에서도 이 작업은 계속된다. 실제 업무 개발팀에서 피드백을 받지않고 만든 아키텍처나 공통 기능은 아직 부족한 것이 많다. 때문에 아키텍처/공통 기능팀의 개발자들은 업무 개발팀의 개발자들과 이야기 하면서, 지속적으로 이를 수정하며 보완해 나간다. 

이 피드백을 받아 보완한다는 것은  업무 개발팀 입장에서는 필연적인 재작업을 의미한다. 아키텍처/공통 기능팀의 개발자가 피드백을 받아 아키텍처를 변경하면 전체 업무 개발자들이 이를 다시 반영해야 하기에 이미 개발해 놓은 기능에 대해 다시 작업하는 일은 필연적으로 발생한다. 이는 표준이 변경되는 것을 의미한다. 

때문에 이를 개발 단계 초기에 잡느냐 잡을 수 없느냐가 프로젝트의 성패와 긴밀한 관계가 있다. 이를 개발자들이 기능개발을 많이 하지 않은 조기에 해결하면 그만큼의 재작업 공수가 적게들고 개발 단계 뒤로 가면 갈수록 공수는 기하급수적으로 늘어난다. 

애자일을 수행한다고 하면서, 단순하게 설계/개발 단계를 합쳐 이터레이션을 수행한다고 가정해보자. 위와 같은 상황과 엮이면 어떠한 문제가 발생할까? 설계 단계 3개월이 없어지면서 아키텍처/공통 기능 개발자들은 준비할 물리적 시간을 부여받지 못하게 된다. 

설계/개발 이터레이션이 진행되면서 미완된 기능을 개발하는 것과 개발자들의 피드백을 동시에 받는 일이 진행된다. 아키텍처/공통팀은 굉장한 압박을 받게 된다. 이들은 개발팀에 필요한 것들을 제공해주기 위해 최선을 다하나, 물리적인 준비 시간 자체가 부족하다. 

[설계개발을 단순 합쳤을때 애자일의 아키텍처 기간]

해당 프로젝트에서는 14회에 걸쳐 전체적인 개발의 영향을 주는 아키텍처와 공통기능이 크게 변경되는 일이 발생했다. 이는 개발자들의 재작업 + 피로감으로 이어졌고, 프로젝트에 있는 모두가 이를 버거워했다. 

애자일은 이터레이션을 통해 고객 피드백을 받아 소프트웨어를 지속적으로 개선하는 작업이다. 이터레이션 자체는 분명히 프로젝트 성공에 도움이 된다. 하지만, 대규모 인력이 한번에 참여해야 하는 비즈니스 상황에서는 무조건 이터레이션을 너무 빨리 수행하려고 하지 말자. 필연적으로 준비하는 기간이 필요하다. 그리고 이후 쇼케이스를 통해 고객 피드백을 받으면 된다.   

2장에서 설명한 프로젝트는 다른 경우이다. 당시 프로젝트는 기존에 존재했던 아키텍처 위에 개발이 수행된 형태였다. 이러한 경우는 위 같은 문제가 발생하지 않는다. 이 경우는 이터레이션을 아주 초반부터 수행해도 문제가 없다. 

이 두가지의 차이가 어찌보면 ‘필요한 만큼 확고한 기초’의 경험적 정의가 아닐까 싶다.   

작은 팀(4~6명의 개발자)이 비즈니스 상황에 따라 인력이 늘어나는 경우는 아키텍처 준비기간이 필요 없다. 이 경우 그냥 만들면서 고쳐나가면 된다.  

50명 이상의 프로젝트에서 기존 아키텍처 위해 기능 개선하는 상황에서는 아키텍처를 위한 준비기간이 필요 없다. 그냥 바로 개발을 시작해도 된다.  

50명 이상의 신규 프로젝트에서는 반드시 아키텍처링과 공통 기능을 위한 준비기간이 필요하다.   

필자의 은사이신 랄프 존슨(Ralph Johnson) 교수에게 09년 당시 전화 통화로 위와 같은 질문을 한 적이 있다. 

“제가 120명 규모의 애자일 프로젝트를 수행하는데, 혹자는 애자일이기 때문에 아키텍처링이 필요 없다고  합니다. 어떻게 생각하시나요?”

[디자인패턴의 창시자 GoF 랄프존슨 교수]

교수님은 다음과 같은 명쾌한 답을 주었다.

“나는 그런 말도 안되는 이야기를 들어본 적이 없다. 한번에 많은 기능을 개발해야 하는 비즈니스 상황에서는 아키텍처링이 반드시 필요하다. 혹시 그 질문을 했던 분이 프로젝트를 한번도 수행해 보지 않은 것은 아닌가?”   

금번 경험을 통해 이후 수행하는 프로젝트 부터는’이터레이션 0’ 라는 개념을 도입하기 시작했다. 50명 이상의 프로젝트에서는 1~2개 정도의 이터레이션은 최소의 개발인원이 들어와 현재의 기능 전체를 보고 나중에 투입될 업무 개발자들을 위해 아키텍처링과 공통기능을 만들었다. 그 뒤로는 위와 같은 문제가 현저히 줄었다. 

['이터레이션 0'이 추가된 공정]

위와 같은 이유로, 대형 구축형 사업을 주로 서비스하는 여럿 회사들은 이터레이션 0를 먼저 진행한다. 이 기간동안 여러 개발자들이 최소한의 재작업이 발생하도록 ‘필요한 만큼 확고한 기초’ 의 아키텍처링을 수행한다.