반응적 디자인은?
반응적 디자인은 주변 환경에 유연하고 민첩하게 적응해나가는 애자일에 근거한 디자인 방법론입니다.
가변적인 주변 상황들을 불확실성을 인정하고 유연하게 대응해 나가는 방법으로 세부적인 개발 이슈에 매달리기 이전에 좀 더 넓은 의미의 디자인적 관점에서 접근합니다.
왜 반응적 디자인을 사용해야하는가?
개발 환경은 항상 변합니다.
사용자, 요구사항, 기술, 패턴등 개발에 있어 주변 환경은 꾸준히 변합니다.
심지어는 개발하는 도중에도 변하는 환경에 맞춰나가야하는 변화무쌍한 소프트웨어 시장 환경에서는 이전에 적합했던 디자인이 이번에도 옳바른 디자인이라고 확신할 수 없습니다. 따라서 현재 상황 적합한 디자인을 판단할 수 있는 디자인적 능력은 매우 중요합니다. 이러한 디자인 판단 능력이 요구되는 상황에 민첩하게 대응할 수 있는 반응적 디자인의 방법론은 유용한 선택이 될 수 있습니다.
디자인의 정의
켄트벡씨는 디자인에 대해 다음과 같이 이야기했습니다.
"Benenfically Relation Elements"
이익이 되는 항목(혹은 행위)들간의 관계를 짓는 프로세스라고 정의하며, 디자인은 비용을 들여 수익인 결과물을 얻는 과정이라는 다소 경제학점 관점에서 접근하고 있었습니다.
이러한 디자인의 스케일, 즉 적용범위는 실제 코드부터 추상적인 구조까지 폭넓은 범위가 되겠습니다만 어떠한 스케일에서든 구성항목들간의 연관성을 항상 추구해야합니다. 디자인 스케일에 구애받지 않고 자유롭게 디자인 할 수 있는 것이 디자이너의 역량이라고 합니다.
효율성
켄트벡은 구현 비용이 다음과 같다고 합니다.
구현비용 = ( 초기비용 + 피쳐비용 + 변화비용 + 실수비용 + 기회비용 ) * 위험도
초기에 비용을 너무 많이 쏟으면 개발을 진행하면서 선택할 수 있는 옵션이 많아지지만 유연하지 않고 비용이 점점 비싸집니다.
일반적으로 개발 초기에 비용을 집중하고 경향이 있는데 한꺼번에 너무 많이 만들게 되면 사용자의 변하는 요구사항들을 만족시키기 어려워지고, 개발 초기에 구현하고자했던 방향성을 잃기 쉽습니다. 거기에 수익이 발생하기 전에 요구사항이 변하는 것은 물론 고객자체가 없어질지도 모릅니다. 이런 문제를 대처하기 위해 개발 단계를 짧은 이터레이션으로 구성하여 리듬감 있게 기능들을 개발하는 것이 좋습니다. 소프트웨어는 속성상 개발 초기에 바랬던 결과물이 나올 수는 없기때문에 개발이 진행되는 동안 피드백을 빠르게 얻을 수 있기때문에 좀 더 유연하게 목표에 도달 할 수 있습니다.
또, 구현했던 기능들이 변화할 가능성을 예상하고 그에 대한 비용도 책정해야합니다. 추가적으로 개발되는 기능은 디자인이 엉망이 되는 것을 막기 위해 필수적인 것들만 단순하게 최소화시켜 구현해야합니다. 디자인이 엉망이 될만한 추가 구현이라면 피쳐 그 자체를 구현할 것인지에 대해 클라이언트와 협상과 논의를 통해 피쳐를 축소하거나 가능하다면 버리도록 합니다.
기회 비용은 목표에 있어 정확한 요구사항을 유추할 수 없으므로 하나의 옵션에 모든 것을 투자하면 안되고, 적당히 분산해 개발자원을 투자해야합니다.
이런 모든 가능성에 대한 선택은 위험을 수반합니다. 따라서 모든 선택은 위험대비 효과를 기준으로 고려해야합니다.
재밌는 예로 건물의 회전문을 예로 들어 설명해주었습니다.
회전문에 사람이 몰려 기다리는 현상을 막고자 하는 개발 이슈가 생겼다고 가정하면, 시간당 회전문을 이용하는 사람의 수를 따지는 처리량(throughput)과 사람들이 대기하는 시간(latency), 출근 시간과 한산한 시간에 서로 줄이 다른 상황과 같은 가변성(variance)과 같은 기준으로 계측 해 볼 수 있습니다.
여기서 문제를 해결하기 위해 회전문에 강력한 모터를 달아 처리량을 늘리거나 회전문을 하나 더 설치하여 대기시간을 줄이는 등의 직접적인 방법론을 결정하기 앞서 왜 사람들이 회전문을 사용하는 가에 대한 고찰이 필요합니다. 예를들어 사람들이 해당 건물에 몰리는 이유가 건물안에 인기있는 커피샵때문이라면 그 커피샵을 밖으로 이전하여 몰리는 현상을 막는 것을 고려해볼 수 있습니다. 우리는 점 더 시스템을 크게 봐야합니다. 한걸음 뒤로 물러서서 전체 상황을 보면 근본적인 문제의 해결책을 찾을 수 있습니다.
가치
가치는 실체로 사용하게 되는 행위와 방법론부터 우선시 되는 기준입니다.
피드백 - 불확실한 것에 대해서는 피드백이 필요합니다. 테스트를 작성하고 읽는게 어려워지고 있다면 디자인의 문제가 있다는 신호로 볼 수 있습니다.
인간성 - 디자인의 의사결정을 하고 수행하는 주체는 사람입니다. 무엇보다 사람의 기준에서 디자인을 진행해야합니다.
용기 - 두려움이 있음에도 불구하고 진행할 수 있는 용기가 필요합니다. 켄트벡의 경우에는 개발 프로세스가 불편하면 개선할 때까지 개발을 더 진행하지 않았다고 합니다.
모호성 - 소프트웨어는 항상 아름다운 구조를 가질 수 없을 것입니다. 처음에는 완벽했을지 몰라도 시간이 지나면 추해지는게 순리입니다. 그러한 변질되는 모호성을 인정하고 가치로 둬야합니다. 바둑에서 초보와 고수의 차이는 모호성이라고 합니다. 초보는 모호성을 싫어하며 인정하지 않으려합니다. 모호한 부분을 뜯어 고치려 노력하고 큰 위험을 수반한 채 침몰하기 일쑤입니다.
따라서 필요이상의 노력이 들어갈 수 있는 모호한 상황을 두고 볼 수 있어야합니다. 추해지는 것 자체를 인정하고 때가 되면 디자인 해법을 찾아 자연스레 해결 할수도 있기때문에 추해지는 것, 모호해 지는 것에 대해 너그럽게 대처하는 것이 좋습니다. 이러한 모호함이 반복될 경우 일정한 패턴이 생길 수 있으므로 굳이 겁내어 달려들 필요는 없는 것입니다.
전략들
켄트벡이 디자인에 대한 선택을 할때마다 패턴을 적어 모아봤는데 나중에 분류를 해보니 4개의 그룹으로 나뉘어져서 정리해봤고 합니다. 디자인은 예술적인 센스에 의한 이뤄지는 작업이 아닌 훈련을 통해 발전시킬 수 있습니다.
Leap - 중간 과정을 생략하고 바로 목표 디자인을 구현하는 전략입니다. 기존의 코드를 근거로 짜지 않고, 처음부터 완전히 새로 짜는 것을 말합니다. 빠르게 진행할 수 있기때문에 효과성은 크지만 위험도도 따라 높아지게 됩니다.
Parallel - 기존의 시스템을 유지하면서 개발을 진행합니다. 여유가 있는 시점에서 새로운 시스템으로 마이그레이션을 진행하는 방식으로 중간에 과정을 하나 둬서 개발하는 방식입니다. 시스템을 하나 더 유지해야 되기때문에 비용은 비싸지만 안정적으로 개발을 진행할 수 있습니다.
Stepping Stone - 정확히 상상할 수 없이 근접한 구현 목표만 알고 있을 때 필요한 부분부터 단계별로 만들어 목표에 도달하는 방식입니다.
Simplification - 경험이 많은 디자이너가 애용하며, 최종 디자인이 확정적일 경우에 요구사항을 최소화하여 가장 작은 구현물을 만들고 점점 요구사항을 늘리며 목표를 달성하는 방식입니다. 요구사항을 선택하는 방식에 따라 구현 비용이 다릅니다. (예를들어 동시성에 대한 구현을 최후에 하면 초기에 진행항 것보다 개발비용이 비쌀 것입니다.) 이런식의 요구사항 최소화 기법은 미래의 요구사항이 바뀔 수 있기때문에 작업 도중에 필요하지 않게된 요구사항을 구현하지 않아 좋습니다.
앞의 4가지 조건과 잘 맞지 않고 디자인이 아름답지 않게 나오는 경우에도 일단은 추가하고 보는게 좋습니다. 그게 힘들면 조건부로 도입을 하는 것도 좋습니다. 하지만 이러한 경우에는 훗날 추가적인 비용을 지불할 때가 옵니다.
리팩토링
리팩토링은 구조가 바뀌지만 행동 목적(behavior)는 바뀌지 않는 것을 뜻합니다.
리팩토링도 앞서 이야기한 전략 분류에 벗어나지 않습니다. 리팩토링을 마스터하는 것은 반응적 디자이너가 되는 길입니다.
리팩토링과 새로운 기능 개발을 동시에 할 수 없고, 인터페이스와 구현을 동시에 수정할 수 없습니다.
변경을 고립시키기
변경을 하기전에 해당 부분을 먼저 고립시키는 게 좋습니다. 먼저 Extract Method 패턴으로 목표 코드나 모듈을 분리시켜 고립 시키게되면 외부의 영향을 받지 않게되기때문에 국소적인 변경이 가능해집니다. 이러한 노력은 변경을 쉽게 만들기 때문에 유효합니다.
큰 변경을 성공시키는 것에 희열을 느끼지 말아야합니다!
디자인은 섬과 같다
최고의 디자인이란 존재하지 않으며, 디자인을 진행할 때는 섬과 섬을 건널때 해수면 아래의 위험한 물속을 걷게 되는 상황은 반드시 오게 됩니다. "더 좋아지기전에는 항상 나빠진다", "악화시켜야만 더 좋아질 수 있다."라는 생각을 켄트벡씨는 항상하고 있습니다. 따라서 이러한 변경 과정은 최대한 짧고 안전하게 하는 것이 좋습니다.
그리고 중요한 목표가 변경되는 것은 섬의 지형도가 바뀌는 것과 같다고 비유할 수 있는데, 이전의 유용한 디자인이 지금도 유효하지 않게 되는 상황과 같습니다.
Observation
Power laws - 시스템의 일부분은 복잡하지만 복잡할 수 밖에 없다는 것은 인정해야합니다. 부익부 현상처럼 복잡도가 높은 부분은 더 복잡하게 됩니다.
Symmentry - 대칭성을 찾고, 균형을 깨는 것이 있다면 그것을 조율하도록 노력해야합니다.
Punctuated Equilibrium - 진화는 반복적이고 점진적으로 일어나다가 큰 폭으로 향상되곤 합니다. 이러한 진화론적인 접근을 디자인에도 적용이 될 것 같다고 예측합니다. Power laws 보다 설명하고 증명하기는 어렵습니다.
