폭포수 방식 설계는 기술 부채를 남긴다
베터코드 인사이트의 시작 6편
링크드인으로 알게 된 개발자 Yeti님의 글을 보다가 흥미로운 구절이 눈에 띄었습니다.
폭포수 모델 기반 프로젝트를 진행할 때 UML을 활용하여 산출물이라는 것들을 만들곤 했는데요.
UML을 어떻게 활용해야 유의미한 설계가 되는지는 이해하지 못했습니다. 왜냐하면 설계문서 작성 배정을 받은 다음 검토라는 단계가 없이 승인 및 구현에 들어가 피드백을 받을 수 없었습니다.
또한 구현 시에 설계의 부족한 부분이 확인되더라도 설계문서의 수정 없이 개발 효율만을 생각하며 개발을 하는 환경이었고, 프로젝트 마지막에 산출물 현행화라는 방식으로 설계문서를 현행화하는 시간을 가졌습니다.
폭포수 모델 기반 설계?
어떤 상황인지 이해할 수 있었지만, 단락의 제목이 '폭포수 모델 기반 설계'인 점이 어색했습니다. 개인적으로 폭포수 모델이라는 말을 자주 쓰지 않았던 탓에 설계 방식과 그 단어를 함께 쓰는 일이 낯설었습니다. 그래서 제가 익숙했던 표현인 ㅏUpfront design에 대해 (약 10년 만에) 구글링 해보니 요즘은 Big Design Up Front라고 하는 모양입니다.
정의를 읽어보면 폭포수 모델 기반 설계와 의미는 유사합니다.
Big Design Up Front (BDUF) is a software development approach in which the program's design is to be completed and perfected before that program's implementation is started. It is often associated with the waterfall model of software development.
UML이 충분한 설계가 될 수 있는가?
Yeti님의 글에서 다음 주장이 마음을 끌었습니다. 오래전 일이긴 해도 저도 비슷한 경험을 했으니까요. 이에 더하여 글로 제 생각을 남기게 한 계기가 있었습니다.
UML을 어떻게 활용해야 유의미한 설계가 되는지는 이해하지 못했습니다.
위 문장을 읽던 즈음에 <디지털 대전환기란 나에게 무엇인가?> 편을 쓰면서 4년 전에 발표했던 자료를 찾았습니다. 마침 거기서 발견한 아래 내용탓에 과거의 경험이 생생해졌습니다. UML 전문가(UML 교육과 활용으로 생업을 영위)이면서 동시에 Spring 개발자인 Rod Johnson 추종자[1]였던 저는 코드 보관소인 Github이 마이크로소프트에 매각될 때 그가 했던 말이 매우 인상적이었습니다.
다분히 비아냥에 가까운 pretty pictures(이쁜 그림)만으로 코드를 생성해준다는 MDA 류의 기술을 겨냥했죠. 코드를 사용하는 개발자의 협업을 부정하는 코드 생성 기술에 대한 겨냥이었습니다. 저는 코드 생성 자체가 나쁘다고 생각하지는 않습니다. 저 스스로도 과거 프레임워크를 만들 때, 코드 생성 기능을 넣었으니까요. 다만, UML이 설계에서 해줄 수 있는 역할은 매우 제한적이라는 것이 제 생각입니다. 모든 코드를 UML 설계가 대체할 수는 없습니다.
이런 생각을 갖고 있으니 Yeti님의 말이 저에게 울림을 주었고, 이 글을 쓰게 했습니다.
UML을 어떻게 활용해야 유의미한 설계가 되는지는 이해하지 못했습니다.
MDD는 어떤 효용 가치가 있을까?
Rod Johnson이 비난한 MDA에서 발전한 MDD(Model Driven Development)라는 기술로 차세대 프로젝트를 수행하는 기업에서 작성한 글을 찾아보았습니다.
이미 지인이 MDD를 적용한 차세대 프로젝트로 고생(?)을 심하게 하셨기에 해당 기술에 대한 제 입장은 부정적입니다. 그럼에도 불구하고 찾아본 이유는 기술 옹호자 입장을 듣고 싶었기 때문입니다. 마침 적절한 글을 찾을 수 있었습니다.
Rod Johnson이 비난한 부분이 장점으로 그려져 있습니다. 이에 대해서는 동의하기 어렵네요. 뒤에 제 주장을 전개하기로 하고 다른 효용성을 찾아보기로 하겠습니다.
인용한 글에 다음과 같은 질문이 있습니다.
모델이 소스코드보다 왜 수정하기 쉬운지 좀 더 자세히 설명해주실 수 있나요?
전에 제가 기고했던 글에서 보여드렸던 그림인데요. 같이 한번 보시죠. 동일한 로직을 왼쪽은 Java 언어로, 오른쪽은 UML 모델과 DSL로 작성한 것입니다. 어느 쪽이 이해하기 쉬우신가요?
나는 논리적 비약으로 들리긴 하지만, 그들의 효용 가치가 무엇인지는 분명하게 알 수 있다는 생각이 들었습니다. 소프트웨어 개발이 이니라 검수를 위한 결과물로 쓰이기에 그들의 표기법은 매력적일 수 있습니다.
차세대 프로젝트의 수행사 입장에서 좋은 옵션
만일 설계단계가 검수의 기준이라면 어떤 수단이 필요할까요? 기록이 불충분한 과거의 히스토리를 다 복원해서 설계 타당성을 확인해야 합니다. 궁극적으로는 왼쪽의 모습이 되어야 할 테지만, 코드는 전혀 모르는 고객사 실무자들이 확인을 하려면 오른쪽이 훨씬 더 유효합니다.
설계는 설계서가 아니라 의사소통입니다. 그런데 문제는 검수라는 단계가 있습니다. 통상 계약 대금의 30 ~ 40%가 달린 문제고, 대규모 차세대 프로젝트에서는 100 억이 넘는 금액이기도 합니다.
이런 상황이면 설계의 목적도 바뀝니다. 의사소통이 소프트웨어 개발에 대한 것이 아니라 계약 이행과 수금에 대한 적절성을 다루게 됩니다. 그렇다면, 예시로 보이는 UML 모델이 충분히 매력적일 수 있습니다.
큰돈이 걸려 있는 첨예한 갈등이 벌어질 수 있는 상황에서 합의에 이르는데 좋은 표기법이라는 점에 동의한 것입니다. 하지만, 검수라는 단계가 최종 소프트웨어에 대해 보장을 해주진 않습니다. 도리어 검수가 중시되는 프로젝트 관리 관행이 소프트웨어 품질이 훼손을 초래한다는 점에 대해 사회적 인식이 필요하다는 생각이 강하게 듭니다.
이제 20여 년 전에 애자일 선언문에 계약보다 고객과 협업(Customer collaboration)이 중요하다고 강조한 내용을 소환해보겠습니다. 검수라는 계약 방식에 품질이 희생되는 일을 20 년 전에 막자는 선언이 있었습니다.
https://brunch.co.kr/@graypool/117모델은 설계를 위한 도구일 뿐이다
이 글을 읽는 독자분들이 복잡한 이야기는 잊더라도 설계는 <설계서가 아니라 의사소통> 이라는 점을 기억하시길 바랍니다. 설계는 모델 자체가 아니라 의사소통이라는 점을 강조하고 싶습니다. 코드 생성 자동화는 구체적인 맥락 하에서만 의미가 있습니다. 다양한 맥락을 포용해야 하는 비즈니스 시스템에서 마치 '자동화' 결과물이 모든 프로그램을 대체하는 일인 것처럼 생각하면 큰 오산입니다.
사업 관리 단계가 만들어놓은 기술 부채
다시 Yeti님의 글로 돌아가 보겠습니다.
UML을 어떻게 활용해야 유의미한 설계가 되는지는 이해하지 못했습니다. 왜냐하면 설계문서 작성 배정을 받은 다음 검토라는 단계가 없이 승인 및 구현에 들어가 피드백을 받을 수 없었습니다.
<기술 부채는 무엇인가?> 편을 쓸 때 찾아본 링크 중에서 이런 내용들이 있었습니다. 실무적으로 유용한 내용이라 여겨 링크를 보관해둔 글입니다.
제품 소유자 및 비즈니스 이해관계자와의 협업 브레인스토밍 세션 일정을 세운다. 이 세션을 활용해 여러 구현 옵션을 검토하고, 기술 부채를 줄이는 옵션과 유지보수, 지원 및 향후 재작업이 필요한 다른 형태의 부채를 발생시킬 수 있는 것 등을 포함한 절충안을 논의한다.
검수 단계에서는 구현에서 발생하는 어려움이나 예상치 못한 작업(비용)에 대해서 다룰 수 없습니다. 아직 벌어지지 않은 일이라 다룰 수가 없습니다. 더군다나 사업 수행 업체(SI) 입장에서는 우리 일이 아닙니다. 발주한 고객사 입장에서는 나중 일이라고 할 수도 있으나 나는 이를 '기술 부채를 쌓는 첫 번째 단계'라고 주장합니다. 어떤 규모로 누가 어떻게 운영할 것인지라는 우리 조직의 중대한 문제를 나중으로 미루고, 검수 단계에서 계약서에 합의한 금액 지불이 적절한가 하는 문제에만 초점을 맞춥니다.
주객이 전도된 느낌이 들어 다시 한번 애자일 선언문을 소환하고 싶습니다. 차세대 발주사 입장에서 Customer collaboration은 앞으로 우리가 시스템을 운영하고 변경하는 방법을 암시합니다. 그리고 바러 윗줄에 나오는 선언문도 검수 단계와 연결해서 생각해볼 수 있습니다. 충분한 설계서(comprehensive documentation)가 검수 용도 말고 유용할까요? 설계서가 오픈 이후에 발생할 미래의 일들에 대처할 수 있는 시스템을 만드는 일보다 중요할까요?
https://brunch.co.kr/@graypool/117기술부채로 시작한 프로젝트가 기술부채를 남긴다
위 문장을 보고 '무슨 소리지?' 하는 분이 있을 듯합니다. 일부러 두 개의 문장을 섞어서 말했기 때문입니다. 운영 문제는 다 만든 후에 고민해보자는 식은 Following a plan이라 할 수 있습니다. 연간 계획 범위에서만 보고 하고 일을 한다면 그렇습니다. 그렇지만, 반복되는 차세대 실패라는 심각한 문제는 우리에게 변화에 대응(Respoding to change)할 것을 요구한다고 믿습니다.
그것은 설계서로 검수하는 전근대적인 방법을 극복하고 실환경에 돌아가는 소프트웨어(Working software)에 집중하는 용기를 실행할 때 만날 수 있을지 모릅니다. 그리고 차세대 프로젝트는 기술부채가 쌓여 도저히 프로그램을 수정할 수 없는 상태를 타계하기 위한 일이라고 할 수 있습니다. 그렇다면, 차세대 프로젝트의 결과물은 기술부채가 쌓이는 일을 막는 방법도 고민해야 합니다.
이에 대해 <코드 개선과 적절한 계획 및 측정이 기술 부채를 줄이는 지름길> 편은 의미 있는 체크 리스트를 제공합니다.
하지만, 대규모 외부 개발자에 기초해서 프로젝트를 하는 경우라면 이를 어떻게 우리 조직에서 소화해야 할지 난감한 문제가 아닐 수 없습니다.
주석
[1] 2000년 중반 대규모 해군 사업에 Spring 프레임워크를 적용한 후에 JCO 에서 Spring 관련 발표를 하거나 연사를 섭외했고, Toby 이일민 님과 함께 한국 스프링 사용자 모임(KSUG)을 만든 이력이 있습니다.
지난 베터코드 인사이트의 시작 연재
3. Funnel을 마케팅 말고 engagement 분석에?
5. 기술 부채는 무엇인가?
