8장 도약

[jongfeel]

8장 도약(Breakthrough)

리팩터링에 들어간 노력의 양이 적으면 개선되는 부분 역시 적을 수 밖에 없다.
리팩터링은 엔트로피와의 싸움이며 레거시 시스템이 퇴보하는 것을 막는 최전선에 있다.
하지만 중요한 통찰력은 어느 순간 갑자기 떠오르게 되고 그에 따른 충격은 프로젝트 전체로 퍼진다.

팀은 확실하게 습득한 지식을 자신의 것으로 만들고 모델에 투영한다.
심층 모델은 한번에 하나의 객체를 대상으로 소규모 리팩터링 과정을 거쳐 모습을 드러낸다.

개발자는 개별적인 코드 개선과 모델의 개선 작업을 토대로 더 명확한 시각을 갖게 된다.
그러면 통찰력을 도약시킬 수 있는 잠재적인 가능성이 생긴다.
복잡성이 사라지는 바로 그때 갑자기 모델의 융통성과 표현력이 높아진다.

이런 도약은 기법이 아닌 사건이다. 무슨 일이 일어나는지 파악하고 어떻게 처리할지 결정해야 한다.
도약을 경험한다는 것이 어떤 것인지를 프로젝트 사례를 토대로 알아본다.

도약에 관한 일화

여러 대출회사가 모여 퍼실리티(facility)를 지원할 자금을 공동으로 출자하는 채권은행단(syndicate)을 구성한다.
투자 은행이 채권은행단의 대표를 맡고 거래와 다양한 서비스를 조율한다.
프로젝트는 이와 관련된 프로세스를 추적하고 지원하는 소프트웨어를 제작하는 것이 목표였다.

괜찮은 모델이기는 하지만...

네 달 동안 리팩터링 작업을 통해 응집도 높은 MODEL-DRIVEN DESGIN을 만들게 되었다.
그림 8.1에 반영된 모델은 Loan Investment(대출 투자)는 Facility(퍼실리티) 내에서의 지분(share)에 비례하는 특정 투자자의 Loan(대출) 분담액을 표현하는 파생 객체다.

퍼실리티란 무엇인가?

상업 은행 도메인에서 퍼실리티는 돈을 대출해 줄 회사와의 매매 계약을 의미한다.
신용카드에서 미리 정해진 금리로 최대 금액까지 빌릴 수 있는 권한을 부여하는 것이 퍼실리티에 해당한다.
연회비는 신용카드(퍼실리티)를 보유한 권리에 대한 요금이며 대출과는 무관하다.

Facility에 포함된 지분은 특정 대출자금을 인출할 때의 가이드라인일 뿐이라는 걸 나중에 이해해서 문제가 발생했다.
차용인이 대출금을 요청하면 각 대출사가 보유한 지분만큼의 대출금을 제공해 줄 것을 요청한다.

보통은 지분에 해당하는 금액을 제공하지만 채권은행단의 다른 회사와 협의를 거쳐 더 적은(또는 더 많은) 금액을 제공하기도 한다.
모델에 Load Ajustment(대출 조정)을 추가해 이 요구사항을 수용할 수 있었다.

또 다른 문제로 반올림 불일치가 발생했다.
1억 달러 규모의 거래에서 몇 페니의 금액이 사라졌는데 원인을 설명하지 못하는 소프트웨어를 신뢰할 수는 없을 것이므로
기본적인 설계 문제에서 비롯된 점이라는 걸 깨닫기 시작했다.

도약

업무에 적합하지 않은 방식으로 모델 내의 Facility와 Loan 지분을 밀접하게 결부시켜 놓았고 모델에 광범위하게 영향을 미쳤다.
새로운 모델을 그려서 핵심적인 특징을 뽑아냈다.
Loan의 지분과 Facility의 지분은 상호독립적으로 변경 가능하다.
이 통찰력을 바탕으로 다음과 같이 새로운 모델을 시각화한 후 다양한 시나리오를 검토했다.

이 그림에 따르면 차용인이 Facility에 위탁한 1억 달러 금액 중 5천만 달러를 차입하는 걸 결정한 상황이다.
대출회사 A, B, C는 정확하게 Facility 지분에 비례해 지분을 제시했고, 대출화사는 5천만 달러의 Loan을 나눠 갖는다.

그 후에 그림 8.4와 같이 차용인이 추가로 3천만 달러를 차입해서 미변제 Loan이 8천만 달러가 됐지만
아직 Facility 제한 금액 1억 달러를 초과한 건 아니다.
하지만 대출회사 B가 대출에 참여하지 않아서, 대출회사 A가 지분을 부담하게 됐다.
인출 금액이 Loan에 더해질 때 Loan의 지분은 Facility의 지분에 비례하지 않는다.

차용인이 Loan에 대한 대출금을 상환하면 Facility가 아닌 Loan에서 지분 비율에 따라 대출회사에 분배한다.
이자 역시 Loan의 지분 비율에 따라 분배된다.

차용인이 Facility 소유권에 대한 비용을 지불할 경우, 어느 회사가 대출해 줬는지와 상관 없이 Facility 지분 비율에 따라 납입금을 분배한다. 수수료를 납입해도 Loan은 변경되지 않는다.

더 심층적인 모델 (A Deeper Model)

앞에서 살펴본 대로 두 가지의 통찰력을 얻게 되었다.

• 투자(Investment)와 대출 투자(Loan Investment)는 지분(share)의 두 가지 특수한 경우에 불과하다.
• 퍼실리티, 대출, 상환액 분배 등의 지분은 존재하고 분배할 수 있는 값을 의미한다.

지분에 관한 모델(그림 8.7)과 새로운 대출 모델(그림 8.8)을 구상했다.

이제 Facility나 Loan의 지분을 표현하는 특수 개념은 없다.
분석을 통해 두 가지 모두 "Share Pie(지분 총액)" 라는 개념으로 통합했다.
따라서 계산 자체를 표현력 있고, 간결하며, 쉽게 조합할 수 있는 "지분 계산(shares math)"을 도입하는 게 가능해졌다.

새로운 모델은 합계, 수수료 분배 등에 관한 제약사항을 유지하면서도 Loan Share가 Facility Share에 대한 비율에 얽매이지 않게 만들었다.
Load의 Share Pie를 직접 조정할 수 있으므로 Loan Adjustment가 필요 없게 됐다.

Loan Investment(대출 투자)는 사라졌는데, 이 용어는 은행에서 사용하지 않는 용어라는 사실을 알게 됐다.
업무 전문가는 대출 투자 용어를 이해할 수 없다고 얘기해 왔지만 소프트웨어 전문가를 믿었고 기술적인 설계 과정에서 대출 투자가 맞다고 추측해서 쓴 것이다. 즉, 도메인을 이해하지 못한 상태에서 용어를 만들고 쓰고 있었던 것이다.

이제 모델 다이어그램이 "너무 기술적"이라고 얘기했던 업무 전문가들은 새로운 모델 다이어그램을 완벽하게 이해하게 되었다. 이제 반올림 문제가 없어졌으므로 복잡한 반올림 코드를 폐기할 수 있었다.

냉정한 결정

리팩터링의 근본 취지는 항상 모든 것이 정상적으로 동작하는 상태를 유지하면서 작은 단계를 거치면서 코드를 개선해야 한다는 점이다. (The gospel of refactoring is that you always go in small steps, always keeping everything working.)

새로운 모델로 리팩터링을 하려면 많은 양의 코드를 수정해야 하므로 애플리케이션이 안정적인 상태를 유지할 수 있는 작은 단계를 구분하기가 어려웠다.
작은 단계를 통해 새로운 모델로 리팩터링 하는 방법도 있지만, 애플리케이션 일부 기능이 정상적으로 동작하지 않을 가능성이 높았다. 또 프로젝트 전반에 걸쳐 자동화된 테스트가 사용되기 전이었다.
테스트가 없었으므로 리팩터링 도중 애플리케이션의 어떤 부분이 정상적으로 동작하지 않을지 예측하기가 불가능했다.

프로젝트 관리자는 회의를 통해 리팩터링을 해야 하는 이유에 대해 파악을 했었고, 프로젝트 진행에 따른 비난이나 공격은 자신이 처리할 것이라고 해줬다.
그 프로젝트 관리자가 그 결정을 내린 용기와 신뢰에 헤아릴 수 없는 존경을 표한다.

결말

요구사항 변경은 중단됐는데, 반올림 로직은 단순하지는 않았지만 안정화되고 논리적으로 타당하긴 했다.
첫 번째 버전 출시 후 계산 방식은 두 번째 버전에서 명확해졌다.

두 번째 버전에서 Share Pie는 전체 애플리케이션을 관통하는 통일된 주제가 되었다.
기술 인력, 업무 전문가 모두 시스템을 논의하는데 Share Pie를 사용했다. 마케팅 부서도 마찬가지였다.
잠재 고객과 실제 고객은 Share Pie 의미를 수월하게 이해했으며, 신디케이트 론의 의미를 설명하는 핵심 개념으로
진정한 UBIQUITOUS LANGUAGE의 일부가 되었다.

기회

심층 모델로 도약할 수 있는 기회가 찾아오면 종종 두려움을 느낀다.
그런 변화는 리팩터링 보다 더 큰 기회와 더 큰 위험을 수반한다. 그리고 시점이 적절하지 못할 수도 있다.

변화를 원하는 만큼 진행 과정은 쉽지 않다.
진정 심층적인 모델로 변화하려면 근본적인 사고방식의 전환이 필요하며 설계의 대부분을 수정해야 한다.
많은 프로젝트에서 모델과 설계에서 나타나는 가장 중요한 발전은 도약을 거쳐 이루어진다.

기본에 집중하라

도약을 위해 프로젝트 진행을 정지한 채 마비상태에 빠져서는 안 된다.
수많은 적정 규모의 리팩터링을 수행하고 나서야 도약이 나타나기 때문이다.
대부분의 시간은 단편적인 개선에 소요되고 결과적으로 연속적인 각 정제 과정 속에서 서서히 모델에 대한 통찰력을 얻게 된다.

도약이 등장할 수 있는 무대를 마련하려면 지식 탐구와 함께 인내심을 가지고 UBIQUITOUS LANGUAGE를 만드는 일에 집중해야 한다.
중요한 도메인 개념을 조사하고 그런 개념을 모델 내에 명시적으로 표현한다.
유연해지도록 설계를 정제한다.
모델의 정수를 추출한다.
도약에 앞서 명확함을 늘리는 데 도움이 되는 이러한 예측 가능한 계층을 만드는 노력을 멈춰서는 안 된다.

점진적으로 모델의 깊이를 더하는 적정 규모의 개선 작업을 망설여서는 안 된다.

후기: 연이은 새로운 통찰력의 출현

심층적인 모델은 애플리케이션을 더 풍부하게 만들고 설계를 더 명확하게 만들 수 있는 예상치 못한 기회를 얻었다.

Share Pie 버전 출시 이후 모델 내에 설계를 복잡하게 만드는 부자연스러운 측면이 있다는 점을 발견했다.
모델 내에 존재해야 하는 중요한 ENTITY가 누락되서 다른 객체가 여분의 책임을 맡고 있던 것이다.
대출자금 인출(loan drawdown), 수수료 납입(fee payment) 등의 중요 규칙에 대한 로직은 Facility와 Loan에서 제공하는 메서드 안에 억지로 포함돼 있었다.
복잡한 메서드 안에 묻혀 있던 "거래(transaction, 금융거래를 뜻함)"와 같이 모델에서 찾아볼 수 없던 용어가 갑자기 등장했다.

이번엔 시간 압박이 덜 했고 앞선 과정을 다시 거쳐서 또 다른 새로운 통찰력과 더 심층적인 모델을 얻게 되었다.
새로운 모델은 Transaction과 같은 개념이 명확하게 표현됐고, Position(Facility와 Loan을 포함하는 추상)을 단순화시켰다.

심층 모델로의 도약을 거치고 나면 새로운 설계의 명확성과 단순함이 새로운 UBIQUITOUS LANGUAGE를 기반으로 한 개선된 의사소통과 결합되어 또 다른 모델링 도약으로 이어지는 사례가 자주 발생한다.

[jongfeel]

기본에 집중하라 단락은 프로젝트를 경험해 보지 않고는 얻을 수 없는 통찰력이라고 본다.

작업은 일정에 맞춰 계속 진행되어야 하는데 잘못된 걸 바로잡는다고 시간을 쓸 여유가 없기 때문이다.
그래서 잘못된 걸 알면서 억지로 맞춰서 개발이 진행되고, 코드 양은 많아져서 리팩터링도 포기하게 되며 일정에 맞게 구현만 하게 되는 경우가 많은 것 같다.

이게 되려면 프로젝트 리더가 결단력을 가지고 기능 구현과 동시에 모델링 부터 설계 까지 변경을 주도해서 본인이 직접 하든 팀원들에게 시키든 해야 하는데, 소프트웨어를 잘 만들어야겠다는 진지한 생각을 가진 사람이 얼마나 될까? 라는 생각을 해 보면 잘 모르겠다.

내 경험상 소프트웨어에 진심인 사람을 몇 명 못만나봐서 그런 것 같다.