[이야기] 인간 중심의 디자인 설계

Overview

22년 가을 학기, 학교 강좌 중 소프트웨어 디자인 패턴 과목을 수강하고 있다. 엉클 밥 선생님께서 쓰신 Agile Software Development , 오렐리의 헤드 퍼스트 디자인 패턴 책을 읽으면서 김인규 교수님과 학우분들이 서로 생각을 공유하는 방식으로 진행되었다.

나는 언어 사용법 지식을 "열심히" 공부했다. 객체지향 프로그래밍을 배웠다고 생각했다. 그리고 그것이 문제였음을 인식했다. 인터넷에 떠도는 정보를 보고 피상적인 지식만 찾아다닌 것은 아닌지 생각해보았다. 인간이 새로운 도구를 만들 때에는 무언가를 효율적으로 더 잘해내기 만들지는 않았을까? 내가 무엇을 하려고 이런 메뉴얼 들을 들춰보고 있던 것일까?

Agile Software Development 관습을 통해 인간 중심의 가치관이 소프트웨어 개발 관습에 준 영향을 일부 추려보고 "변화" 를 중심으로 설계를 개선하는 방식을 간단히 소개한다.

---

인간을 중심으로 가치관을 바꾸다

A lot of times, people don't know that they want until you show it to them - Steve Jobs

비즈니스 환경에서 소프트웨어의 개발자와 사용자는 명확히 구분되어있는 경우가 많다. 사용자는 자신이 경험하고 있는 문제에 대해서는 인식하고 훌륭한 전략을 생각할 수 있는 힘이 있다. 하지만 어떤 전략의 실체를 보기 전까지는 자신이 원하는 것인지 판단하기 어려운 경향이 있는 것 같다. 소프트웨어 기획, 설계, 개발의 어려움은 이런 배경에서 시작되지 않았을까 조심히 추측해본다.

전통적인 개발 방식 중 하나인 Water-fall 개발 모델은 계획부터 개발을 거쳐 유지보수까지 폭포가 아래로 흐르는 것처럼 진행된다. 세상의 요구 사항은 빠르게 변화하고 있지만 이를 소프트웨어 솔루션에 반영하기 어려웠다. 수정을 위해 많은 돈과 시간을 들여 계획하고 시행해야 하기 때문이다.

고객은 자신의 문제를 해결하기 위한 여러 선택지 중 소프트웨어를 선택했을 것이다. 만약 개발사로 부터 공급 받은 소프트웨어가 자신의 문제를 해결하지 못한다면 백날 좋은 설계를 가진 프로그램도 쓸모가 없어질 것이다. 반면 소프트웨어 개발사 입장에서는 빈번한 요구사항 변경은 추가적인 개발, 설계 비용이 투입되어야 하기에 반갑지만은 않은 일이 될 것이다.

소프트웨어 개발 산업에서 초기에 만들었던 고객과의 분쟁 해결 방법은 "계약" 에 기반하여 소프트웨어를 제작하는 것이었다. 문제는 고객 입장에서 이 방식이 큰 부담이 된다는 점이다. 소프트웨어를 제작하기 위한 수많은 기능 명세서, 완성품을 보기도 전에 책임 요소를 핸들링 해야하는 점 등을 비전문가인 고객이 관리하는 것이 쉬운 일이겠는가? 이렇게 소프트웨어 제작이 부담되니 의뢰 요청 시장의 파이가 줄어들기 시작했다. 산업계가 자신을 보호하기 위해 만든 방법이 자신을 굶어 죽도록 복돋고 있었다.

Agile-Menifesto 애자일 소프트웨어 개발 선언은 소프트웨어 개발 시 사용되어온 전통적인 가치관을 인간 중심으로 바꿨다. 그리고 개발 관습, 문화, 설계 등의 모든 영역에서 큰 변화를 일으켰다. XP 를 통해 고객 등의 사람과 더욱 긴밀하게 소통하고, 변화를 수긍하며, 짧은 주기로 완전히 동작하는 소프트웨어를 산출시키는 모습을 볼 수 있게 되었다.

(... 중략 ...)

공정과 도구보다 개인과 상호작용을 포괄적인 문서보다 작동하는 소프트웨어를
계약 협상보다 고객과의 협력을
계획을 따르기보다 변화에 대응하기를

가치 있게 여긴다.

(... 후략 ...)

소프트웨어 추상화 설계의 역설

객체지향적으로 프로그램을 설계하는 과정의 이면에는 추상화가 숨어있다. 그리고 필자는 올해, 추상화에 푹 빠져있었다. 추상화가 세상의 모든 문제를 마법 처럼 해결해줄 생각 때문이다. 그런데, 소프트웨어를 구현하기 위해 처음 부터 과도한 설계를 집어넣는 것은 문제가 될 수 있다고 한다.

잠깐 우리가 살아온 지난 시간을 톺아본다. 만약 인류가 미래를 결점없이 예측할 수 있다면, 처음 부터 완벽한 계획을 세울 수 있을 것이다. 처음부터 계획이 완벽하기 때문에 변화할 필요가 없을 것이다. 하지만, 세상, 문제 해결 전략은 변화하며 중요하게 생각하는 관점도 언제나 변화한다. 소프트웨어 솔루션도 이에 대응하여 변화해야한다. 변하지 않는 것은 없다. 마찬가지로 결점없는 예측도 존재할 수 없다고 생각한다.

만약 인류가 세상의 변화를 알면서도 아무런 대응을 하지 않았거나 고대 인류로부터 두뇌가 아닌 다른 부분에서 계속 진화했다면 과연 인류는 살아남을 수 있었을까?

다시 소프트웨어 세상으로 돌아와본다. 특정 관점을 갖고 초기 부터 과도하게 설계를 해두면 미래에 관점이 전적으로 바뀌었을 때 방향을 틀기 어려울 수 있다. 실제로, 경로 의존성 이라는 개념이 있는데 요약하자면 "한번 어떤 길로 가기 시작하면 압도적인 이득이 있지 않는 한 다른 방향으로 트는 것이 어렵다." 의미를 갖는다.

Agile Software Development 책에서는 처음 부터 과도하게 설계하는 것을 지양하고 "변화" 가 발생할 때마다 코드 구조를 리팩터링 한다. 코드를 개선하기 위해 다음과 같은 주관적인 지표를 Code Smell 로 정의하여 활용한다.

1. 강성 (Rigidity) - 디자인의 변경이 어렵다.
2. 취약성 (Fragility) - 디자인이 깨지기 쉽다.
3. 부동성 (Immobility) - 디자인은 재사용하기 어렵다.
4. 점도 (Viscosity) - 올바른 일을 하기가 어렵다.
5. 불필요한 복잡성 (Needless Complexity) - 과잉 설계를 피하라.
6. 불필요한 반복 (Needless Repetition) - 마우스의 오용.
7. 불투명도 (Opacity) - 무질서한 표현.

위와 같은 디자인 문제점을 개선하기 위해 SOLID Principle 을 활용하여 Code Smell 을 개선한다. 다만, 과유불급으로 변화가 발생할 때마다 적절하게 활용하는 것이 좋다.

변화에 대응하는 민첩한 반복

프로그램의 기획, 설계, 개발 모두 사람을 중심으로 이뤄진다.

익스트림 프로그래밍(XP) 에서 고객과 가까운 거리에서 긴밀한 의사소통을 진행하여 요구사항을 도출하고 소프트웨어를 완성하는 작업을 반복한다. 페어 프로그래밍을 통해 의사 소통 도구보다 사람에 집중하여 생산성을 끌어올린다.

초기 부터 너무 많은 것을 계획하지 않고 변화에 빠르게 피드백을 할 수 있는 환경을 구축한다.

Code Smell 을 통해 좋지 못한 디자인의 문제를 식별한다. 이를 SOLID 등의 설계 원칙을 활용하여 문제를 진단하고 적절한 디자인 패턴을 활용하여 문제를 해결한다. 이런 소프트웨어 개발, 개선 과정을 매순간 반복하면서 시스템의 디자인을 가능한 단순하고 깨끗하고 표현력 있게 유지할 수 있도록 노력한다.