소프트웨어 디자인은 인간관계의 연습이다📝

“소프트웨어 디자인은 인간관계 연습이다.” _ 켄트 벡 소프트웨어 디자인은 객체 간 결합, 응집, 여러 원칙, 디자인 패턴, 리팩터링과 같은 코드 품질에 관한 것이지만, 인간관계와 깊은 연관이 있습니다. 소프트웨어 디자인을 인간관계의 프리즘을 통해 보게 되면 이렇습니다. 인간관계에는 크게 두 가지의 역할이 존재하는데, 켄트 벡은 그들을 ‘웨이터’와 ‘체인저’라고 부릅니다. 웨이터는 서비스의 동작 변경을 요청하고, 체인저는 실제로 코드를 변경합니다. 하나의 큰 원이 웨이터가 제어할 수 있는 것과 없는 것을 분리하고 있습니다. 인간관계의 측면에서 중요한 지점은 ‘제어’해야 하는 상황에서 느껴지는 긴장감이 존재하기 때문에 웨이터와 체인저 양측이 서로 이해하지 못하면 관계를 정말 힘들어질 수 있다는 것입니다. 또한 인간관계에서 중요한 것은 원 안의 웃는 얼굴입니다. 이는 프로그래머와 자신과의 관계를 말합니다. 자신과의 관계라는 말이 굉장히 어렵게 다가오기도 하지만 개발자의 삶을 살면서 알게 된 ‘증후군’만 꽤 되는 것 같습니다. 그만큼 자기 자신을 신뢰하지 못하게 만드는 상황이 존재하고 그 결과 좋지 못한 결정을 내릴 때가 있기 때문에 자기 자신과의 관계를 먼저 원활하게 만드는 과정이 필요합니다. “인간성이라는 원칙을 믿고 따른다면 우리가 바꿀 수 있는 것은 나 자신의 말과 행동뿐이다. 다른 사람에게 의사소통이나 솔선수범을 통해 영향을 끼칠 수는 있지만, 우리가 원하는 대로 그들을 바꿀 수는 없다.” _ 안영회 님 “프로그래머로서 자신과 건전한 관계를 구축할 때까지 다른 프로그래머와 건전한 관계를 구축할 수 없다.” _ 켄트 벡 모든 소프트웨어 개발과 제품팀의 협업이 이성, 논리와 데이터의 정확도에 의해서 결과가 나온다면 인간관계보다는 탄탄한 논리 위에서 열심히 일만 하는 것이 중요하겠으나, 그렇지 않다는 것을 너무 잘 알기 때문에 인간성, 인간관계를 중요시할 수 밖에 없습니다. 🙌 인간관계 안에서의 소프트웨어 디자인 소프트웨어 개발은 기획자(또는 개발자, 디자이너가 될 수 있음)의 아이디어를 통해 코드가 수정되고 유저가 취하는 동작이 변경됩니다. 일반적으로 눈에 보이는 관계는 아이디어와 동작의 반복에 초점을 맞추지만, 눈에 보이는 인간관계의 수면 밑에는 구조(코드, 객체, 앱의 구조)라는 보이지 않는 면이 존재합니다. 저도 자주 쓰는 말인데, “이 버튼을 눌렀을 때의 동작 변경은 쉽지만, 코드의 구조가 깨지기 때문에 변경하기가 쉽지 않다.“ 이런 상황에서 개발자 가질 수 있는 현실적인 좋은 습관은 복잡한 문제를 다룰 때는 더 이해하기 쉬운 작은 문제로 분해하여 해결하는 것입니다. 하지만 근본적으로 가져야 할 자신과의 관계를 위한 쉬운 방법은 체인저가 웨이터에게 구조가 어떤 식으로 동작하고 있는지에 대한 아이디어를 역으로 제안할 수 있다는 것이고, 그 아이디어와 동작을 반복할 때 코드가 어떤 가치를 만들어 낼 수 있는지에 대한 방법을 조사할 수 있는 능력입니다. "아이디어 → 동작 → 아이디어"의 반복에 초점을 맞춘다면 구조가 망가지고 이는 개발자 지신과의 관계를 해치고 있다고 볼 수 있습니다. 물론 상황에 따라 이러한 선택을 불가피하게 할 수는 있지만, 그 선택을 투자라고 했을 때 그 투자는 과연 어떤 결과를 초래할 것인지는 상상하기도 싫습니다. 하지만 구조에 초점을 맞춰 웨이터에게 아이디어를 제시할 수 있다면 풀려고 하는 문제에 대한 명확한 이해가 될 것이고, 제품팀의 신뢰를 바탕으로 빠르게 가설을 검증할 수 있을 것입니다. 이 시점에서 켄트 벡은 모든 피드백 루프는 빠르게 반복돼야 한다고 주장합니다. 아이디어를 신속하게 시도하여 새로운 동작에 적합한 구조로 변경하고 동작 변경을 완료할 수 있어야 한다는 것이 중요한 특징입니다! 구조를 많이 변경해야 한다면 변경해야 하는 구조를 잘게 잘라서 작은 구조를 바꾸는 아이디어를 먼저 빠르게 수행할 수 있다면 뛰어난 가치를 만들어 낼 수 있을 것입니다. 핵심은 동작을 쉽게 변경할 수 있도록 구조를 변경하는 것입니다. 많은 코드를 포함하는 객체를 변경해야 한다고 했을 때, 먼저 코드를 읽고 이해한 후에 객체를 작은 논리적인 단위로 분할하는 방법을 익히고 변경할 수 있는 우선순위를 명확하게 정한 뒤 빠르게 아이디어를 실현하는 것입니다. 말은 쉽게 했지만 객체 구조를 바꾸는 것은 결코 쉬운 일이 아닙니다. 켄트 벡이 소프트웨어 디자인을 통해 얻은 통찰은 소프트웨어 비용은 소프트웨어 변경 비용과 거의 동일하며 초기 개발은 무관하다는 것입니다. 그러나 모든 변경 사항이 동일하지는 않습니다. 경우에 따라 저렴한 변경을 수행하는 총비용은 매우 비싼 비용이 될 수도 있습니다. 이유는 ‘객체 간 결합’ 때문입니다. 왜 모듈화에서 가장 중요한 개념이 ‘느슨한 결합’이라고 하는지 다시 한번 이해가 되는 순간입니다. 소프트웨어 디자인을 한 문장으로 축소한다면 “커플링과 디커플링의 절충을 관리하는 것”이라고 할 수 있습니다. 따라서 커플링이 시작되는 지점에 주목하고, 그 부분은 디커플링하는 측면을 추진할 필요가 있습니다. 자신과의 관계 정립부터 온전히 한다는 것은, 구조 변경이라는 보이지 않는 수면 아래의 복잡한 면을 보다 작고 변경하기 쉽고 이해하기 쉬운 것으로 만들 수 있는 관계 정립이며 제품팀, 이해관계자를 존중하며 신뢰를 바탕으로 아이디어를 빠르게 구현해나가며, 그 과정에서 구조를 변경하기 쉽도록 개발자 또한 아이디어를 낼 수 있는 건강한 팀이 된다면 속된 말로 제품팀 뽕이 차오르는 경험을 할 수 있을 거라 확신한다. 레퍼런스 https://beetroot.co/productivity/tidy-first-daily-empirical-software-design-why-it-works/