프롬스의 SWDEVLAB
두 가지 가치에 대한 이야기
모든 소프트웨어 시스템은 이해관계자에게 서로 다른 두 가지 가치를 제공합니다.
행위(Behavior)와 구조(Structure)가 바로 그것입니다. 소프트웨어 개발자는 두 가치를 모두 반드시 높게 유지해야 하는 책임을 집니다. 개발자들은 불행하게도 한 가치에만 집중하고, 다른 하나는 배제하거나.. 덜 중요한 가치에 집중하여 쓸모없는 소프트웨어를 만들게 됩니다.
행위
소프트웨어의 첫번째 가치는 바로 행위(Behavior)입니다. 프로그래머를 고용하는 이유는 이해관계자를 위해 기계가 수익을 창출하거나 비용을 절약하도록 만들기 위해서입니다. 이해관계자가 기능 명세서나 요구사항 문서를 구체화할 수 있도록 돕고, 기계가 이러한 요구사항을 만족하도록 코드를 작성합니다. 기계가 요구사항을 위반하면 디버거를 열어 문제를 고칩니다.
많은 프로그래머가 이러한 활동이 자신이 해야할 일의 전부라고 생각합니다. 슬프게도 그들은 틀렸습니다.
아키텍처
소프트웨어의 두번째 가치는 소프트웨어(Software)라는 단어와 관련이 있습니다. 소프트웨어라는 단어는 부드러운(Soft)과 제품(Ware)이라는 단어의 합서어입니다. 제품이라는 단어는 상품(Product)을 뜻하고, 부드러운(Soft)라는 단어... 여기에 두번째 가치가 존재합니다.
소프트웨어는 반드시 부드러워야 합니다. 다시말해 변경하기 쉬어야 합니다. 이러한 변경사항을 적용하는 데 드는 어려움은 변경되는 범위(Scope)에 비례해야 하고, 변경사항의 형태(Shape)와는 관련이 없어야 합니다.
소프트웨어 개발 비용의 증가를 결정짓는 주된 요인이 바로 이 변경사항의 범위와 형태에 있습니다. 바로 이 때문에 개발 비용은 요청된 변경사항의 크기에 비례해 집니다. 이해관계자는 비슷한 일련의 변경사항을 제시할 뿐이지만, 점점 복잡도 높아지고 시스템의 형태와 소프트웨어의 형태가 서로 맞지 않기 때문에 힘들어집니다.
문제는 바로 시스템의 아키텍처입니다. 아키텍처가 특정 형태를 다른 형태보다 선호하면 할수록, 새로운 기능을 이 구조에 맞추는게 더 힘들어집니다. 따라서 아키텍처는 독립적이어야 하고, 그럴수록 더 실용적이게 됩니다.
더 높은 가치
기능인가 아니면 아키텍처일까? 둘 중 어느 것의 가치가 더 높을까? 소프트에어 시스템이 동작하도록 만드는 것이 더 중요할까? 아니면 소프트웨어 시스템을 더 쉽게 변경할 수 있도록 하는 것이 더 중요할까?
업무 관리자에게 묻는다면 소프트웨어 시스템이 동작하는 것이 더 중요하다고 대다수가 대답할 것입니다. 하지만 이는 잘못된 태도입니다.
- 완벽하게 동작하지만 수정이 아예 불가능한 프로그램을 내게 준다면, 이 프로그램은 요구사항이 변경될 때 동작하지 않게 되고, 결국 프로그램이 돌아가도록 만들 수 없게 됩니다. 따라서 이러한 프로그램은 거의 쓸모가 없습니다.
- 동작은 하지 않지만 변경이 쉬운 프로그램을 내게 준다면, 나는 프로그램이 돌아가도록 만들 수 있고, 변경사항이 발생하더라도 여전히 동작하도록 유지보수할 수 있습니다. 따라서 이러한 프로그램은 계속 유용한 채로 남습니다.
좀 설득력이 떨어지는 주장이기는 하지만, 현실적으로 수정이 불가능한 시스템은 존재하기 마련입니다. 변경이 드는 비용이 창출되는 수입을 초과하는 경우입니다. 대체적으로 개발자들은 변경이 가능하도록 하는 것이 당연히 중요하다고 생각하지만, 현재 기능의 동작 여부가 미래의 유연성보다 더 중요하다고 여전히 생각을 할 것입니다. 하지만 추 후 업무 관리자가 변경을 요구했을 때, 이에 대처를 하지 못한다면 그는 화를 낼 가능성이 높을 것입니다.
아이젠하워 매트릭스
드와이트 D. 아이젠하워(Dwight D. Eisenhower) 미국 대통령이 고안한 중요성과 긴급성에 관한 아이젠하워 매트릭스를 살펴봅시다.
이 격언에 엄청난 중요한 진실이 담겨 있습니다. 긴급한 문제가 아주 중요한 문제일 경우는 드물고, 중요한 문제가 몹시 기간한 경우는 거의 없다는 사실입니다.
소프트웨어의 첫 번째 가치인 행위는 긴급하지만 매번 높은 중요도를 가지는 것은 아닙니다.
소프트웨어의 두 번째 가치인 아키텍처는 중요하지만 즉각적인 긴급성을 필요하는 경우는 절대 없습니다.
최종적으로 이들 네 가지의 경우에 다음과 같이 우선순위를 매길 수 있습니다.
- 긴급하고 중요한
- 긴급하지는 않지만 중요한
- 긴급하지만 중요하지 않은
- 긴급하지도 중요하지도 않은
아키텍처, 즉 중요한 일은 첫 번째와 두 번째에 위치하는 반면, 행위는 첫 번째와 세 번째에 위치한다는 점을 주목해봅시다. 업무 관리자와 개발자가 흔히 저지르는 실수는 세 번째에 위치한 항목을 첫 번째로 격상시켜 버리는 것입니다. 다시 말해 긴급하지만 중요하지 않은 기능과 진짜로 긴급하면서 중요한 기능을 구분하지 못합니다. 이러한 실패로 중요도가 높은 아키텍처를 무시한 채 중요도가 떨어지는 기능을 선택하게 됩니다.
업무 관리자는 보통 아키텍처의 중요성을 평가할 만한 능력을 겸비하지 못하기 때문에 고용된 소프트웨어 개발자는 이것의 중요성을 설득하는 것도 하나의 책임입니다.
아키텍처를 위해 투쟁하라
이러한 책임을 다하려면 싸움판에 뛰어들어야 하고, '투쟁'해야 합니다. 개발팀, 관리팀, 마케팅팀, 영업팅, 운영팀 모두 각자가 중요하다고 스스로 믿는 가치를 위해 투쟁하게 됩니다.
효율적인 소프트웨어 개발팀은 이러한 투쟁에서 정면으로 맞서 싸웁니다. 뻔뻔함을 무릅쓰고 다른 이해관계자들과 동등하게 논쟁합니다. 이것도 개발자들의 역할 중 하나이며, 책무 중 하나입니다. 그리고 이것이 고용된 이유 중 하나이기도 합니다.
이러한 도전이 당신이 소프트웨어 아키텍트라면 두 배로 중요해집니다. 시스템의 구조에 더 중점을 두고, 개발하기 쉽고, 간편하게 수정할 수 있으며, 확장하기 쉬운 아키텍처를 만들어야하기 때문입니다.
하나만 기억하면 됩니다. 아키텍처가 후순위가 되면 시스템을 개발하는 비용이 더 많이 들고, 일부 또는 전체 시스템에 변경을 가하는 일이 현실적으로 불가능해집니다. 이러한 상황이 발생하도록 용납했다면, 이는 결국 소프트웨어 개발팀이 스스로 옳다고 믿는 가치를 위해 충분히 투쟁하지 않았다는 뜻이 되어버립니다.
포스팅을 마무리하며 ...
오늘 본문에서는 중요한 두 가지 가치.. 행위와 아키텍처에 대해서 말하고 있습니다. 그 중에서도 잘 인지하고 있지 못한, 아키텍처에 대해서 더 중요하게 살펴볼 필요가 있습니다. 저도 개발 업무를 수행할 때, 기능 위주로 일정을 산정하고 이를 처리하기 위한 아키텍처를 맞추는 형식으로 많이 해왔던 것 같습니다.
아이젠하워 매트릭스의 교훈에서 배운 것처럼, 세 번째의 일이 첫 번째가 되는 일은 피하도록 합시다. 행위가 아키텍처보다 더 중요하다고 생각되는 것들을 구별할 수 있도록 매 번 신경쓰도록 해야겠습니다.
관련글
내용이 도움이 되셨으면 공감 버튼 꼬옥 눌러주세요 ♥
본문을 퍼가실 경우 댓글을 달아주세요 ★
'SW LAB > Algorithm' 카테고리의 다른 글
| Clean Code : (2) 의미 있는 이름 (0) | 2020.05.07 |
|---|---|
| Clean Code : (1) 깨끗한 코드 (0) | 2020.05.07 |
| Clean Architecture : (1장) 소개 - 설계와 아키텍처란 ? (0) | 2020.05.06 |
| Clean Architecture : 서론 (0) | 2020.05.06 |
| Clean Code : (0) 서론 (0) | 2020.05.06 |
댓글