아키텍처란 2
작년 1월에 아키텍처란이란 글을 쓰면서 구체적인 부분에 대해서 의견을 남겼었다.
그해 11월부터는 회사를 옮겨서 "아키텍처 개선"이라는 주제 하에 거대 Monolithic 시스템을 점진적으로 MSA로 전환하는 작업을 진행하고 있다.
아키텍처 개선... 이건 개발자들도 이것이 뭔지 명확히 설명하기 쉽지 않은 주제라고 생각한다. 그런데 대기업(?)에서 이런 일을 하려면 함께 하는 개발자들의 이해, 몰입, 의욕 등도 필요하지만 기획, 사업, 상사분들의 지지도 만만치 않게 중요하다. 그런데 아키텍처 개선을 단기간(년 단위)에 정량적으로 평가하기 어렵기에 지지를 구하기가 정말 쉽지 않다.
아키텍처 개선 활동을 진행한 지 거의 10개월 정도 되었던 작년 추석 무렵 사장님께 경과보고를 드려야 하는 일이 있었다. 구체적인 활동을 설명드리는 것은 어렵지 않았다. 우리가 뭘 계획했고, 뭘 진행했고, 뭐가 부족했고, 앞으로 뭘 할지는 명확했다. 하지만 지금 이 활동이 중요하니 많이 도와주십시오라고 말하기가 참 어려웠다.
그래서 TOC 전에 아키텍처가 뭐고, 왜 개선해야 하는지 설명하는 한 장의 장표가 필요했다.
고민 끝에 만든 게 아래의 장표이다.
설명을 하자면 아키텍처는 사용자 요구 사항, 시스템/애플리케이션이 제공할 기능적 요구 사황과는 무관하다.
좋던 나쁘던 어떤 아키텍처를 가지고도 S/W 시스템을 구축할 수 있다. 심지어 뚜렷한 아키텍처 없이도 구현이 가능하다. 이 경우를 애자일에서는 Big Ball of Mud라고 한다. 우 상단의 그림은 Big Ball of Mud에 대한 구글 이미지 검색 결과이다. 그림을 잘 보면 알겠지만 진흙탕에서 공을 굴리는데 진흙 자체가 방해인 데다 참여하고 있는 구성원들을 보면 도대체 어떤 방향으로 굴리려는지 알 수 없다.
이처럼 좋은 아키텍처가 없다면 처음엔 빠르게 진행할 수 없지만 곧 이런 진흙탕에서 아우성을 치는 상황에 빠지게 된다.
좋은 아키텍처를 가지고 있다면 어떤 이점이 있을까? 기능 요구사항에 대한 것이 아니기에 기획, 고객, 상사에게 가시적 결과를 제공하지 못하는데 말이다. 이것은 평상시 꾸준히 운동과 건강한 식습관(정말 어려운 일 ㅠㅠ)을 통해 혈관을 깨끗하게 유지하는 것과 같다. 눈에 보이는 성과는 단기간에 이루기 어렵지만 지속되면 건강하게 살 수 있고, 간과한다면 갑자기 쓰러질 수도 있는 문제를 해결하는 것이다.
좀 더 구체적으로 보면 아키텍처는 각종 -bilities에 대한 것으로 유지보수 용이성, 기능 확장성(새로운 기능을 용이하게 추가), 테스트 용이성, 성능 확장성(트래픽/데이터 증가 시 수평 확장 용이성) 등의 이점을 제공한다. 따라서 좋은 아키텍처를 가지고 있다면 시장의 요구사항에 빠르게 반응함은 물론 높은 품질의 소프트웨어를 제공할 수 있게 된다. 아래 첨부로 개진한 Robert C. Martin이 언급한 SW의 2가지 가치 중 좋은 아키텍처는 첫 번째 가치를 이루는데 정말 중요하다.
내가 만일 스타트업에서 새로운 시스템을 만든다면 처음부터 좋은 아키텍처를 가지고 시작하지는 않을 것이다. 처음엔 속도가 중요할 것이다. 그렇다면 Monolithic, 그것도 DB와 UI 등을 최대한 활용하여 빠르게 개발할 것이다. 이후 서비스의 가치가 입증되고 돌아가기 시작한다면 빠르게 이를 좋은 아키텍처(지금은 MSA)로 개선할 것이다.
그러기 위해서 우리는 돌아가고 의미가 있다면 잘 만들 수 있는 능력(좋은 아키텍처를 적용할 수 있는)과 초기엔 개선할 수 있을 만큼 더럽지만 빠르게 개발하는 2가지 능력이 필요하다. 그리고 같이 일하는 이해당사자들(기획, 동료 개발자, 상사 등)과 이와 같은 내용을 공유하는 것이 필요하다.
아키텍처 개선을 위한 리소스 투입에 대해서 정말 진심으로 지지하는 그런 경우는 없었던 것 같다. 내 설명이 부족하여 가치가 잘 전달되지 않아서 일 것이다. 나의 부족함이 정말 아쉽게 느껴지는 최근 1.6년인 것 같다.
하지만 사회인은 전문가로서 매일매일 성장해야 한다는 선배님의 가르침을 생각한다면 일정 기간 후에는 우리의 설명, 노력이 더 많이 인정되고 가치도 높일 수 있다고 마음을 다진다.
----
The Two Values of SW - Primary and Secondary Values
Secondary value of SW
- 현재의 SW가 현재 사용자의 현재 요구사항을 만족하면 Secondary Value of SW가 달성
- 요구사항은 늘 변함. 그것도 자주. 그래서 고객의 요구사항과 SW의 행위 간의 일관성이 깨지게 됨(SW가 변한 요구사항을 수용하지 못함).
Primary Value of SW
- 지속적으로 변화하는 요구사항을 수용(tolerate, facilitate)하는 것
- 대부분의 SW는 경우 현재의 요구사항을 잘 만족하지만 변경하긴 어려움
- 이를 위해서는 지속적으로 변경할 수 있는 건전한 Architecture가 필요
