[B급 프로그래머] 소프트웨어 설계 "프로세스"가 항상 이상화된 형태인 이유는?

그 동안 불꽃튀는 논쟁이 벌어질만한 내용은 언급을 자제했으나... 무더운 여름을 날려버리기 위해 오늘은 조금 도발적인 주제를 다뤄보도록 하겠다. 파나스 큰 형님이 쓰신 논문인 A RATIONAL DESIGN PROCESS: HOW AND WHY TO FAKE IT 의 II번 항목을 번역해봤다.

우리는 "이성적인" 방식으로 전개되는 소프트웨어 프로젝트를 결코 보지 못할 것입니다. 몇 가지 이유를 정리하면 다음과 같습니다.

1. 대부분 소프트웨어 시스템 제작을 의뢰하는 사람들은 정확히 무엇을 원하는지 모르며, 자신들이 알고 있는 내용을 우리에게 말해줄 능력이 부족합니다.
2. 심지어 우리가 요구 사항을 알았다 하더라도, 소프트웨어 설계에 필요한 다른 사항이 존재합니다. 이런 세부 사항은 구현을 진행하는 과정에서만 알게 됩니다. 이렇게 알게된 몇몇 지식은 설계를 무효로 만들어버리므로 설계 단계로 거슬러 올라가야합니다. 잃어버린 작업량을 최소로 줄이려 시도하기에, 결과로 만들어진 설계는 이성적인 설계 프로세스에서 나온 결과와는 거리가 멉니다.
3. 시작하기 전에 모든 관련 사항을 알고 있다하더라도, 경험에 따르면 우리 인간은 올바른 시스템을 설계하고 만들기 위해 반드시 고려해야 하는 엄청난 세부 사항을 완전히 이해할 수 없습니다. 소프트웨어 설계 프로세스는 고려 사항을 분리함으로써 관리 가능한 정보를 사용해 작업하는 과정입니다. 하지만 고려 사항을 분리할 때까지 우리는 필연적으로 오류를 만들어내기 마련입니다.
4. 심지어 필요한 모든 세부 사항을 마스터할 수 있다하더라도 가장 하찮은 프로젝트조차도 외부 원인에 의해 변경될 운명에 처합니다. 몇몇 변경은 직전 설계 결정을 무효로 만듭니다. 이런 결과로 만들어진 설계는 이성적인 설계 프로세스가 생성한 설계와 거리가 멉니다.
5. 사람의 오류는 사람이 개입되지 않아야 피할 수 있습니다. 심지어 고려 사항을 분리한 다음에도 오류가 발생합니다.
6. 우리는 종종 사전에 형성된 설계 아이디어 때문에 부담을 느낍니다. 우리가 고안했던 아이디어, 관련된 프로젝트에서 얻은 아이디어, 수업 시간에 들은 아이디어 말입니다. 종종 좋아하는 아이디어를 사용하거나 시도하려 프로젝트를 맡기도 합니다. 이런 아이디어는 요구 사항에서 이성적인 설계 프로세스를 사용해 유도되지 않았을지도 모릅니다.
7. 종종 경제적인 이유 때문에 다른 프로젝트를 위해 개발한 소프트웨어를 사용하도록 장려합니다. 어떤 상황에서는 진행 중인 다른 프로젝트와 소프트웨어를 공유하도록 장려하기도 합니다. 이런 결과로 만들어진 소프트웨어는 양쪽 프로젝트 어디를 봐도 이성적인 소프트웨어가 아닙니다. 즉, 요구 사항 자체를 기반으로 개발한 소프트웨어가 아니며, 노력을 줄일 목적으로 고만고만하게 만든 소프트웨어입니다.

이런 이유 때문에, 소프트웨어 설계자가 요구 사항으로부터 이성적이고 오류가 없는 방식으로 설계한 그림은 엄청나게 비현실적입니다. 어느 시스템도 이런 이성적인 방식으로 개발되지 않았으며, 아마도 앞으로도 이런 일은 생기지 않을 것입니다. 심지어 교과서나 논문에 나온 작은 프로그램 개발조차도 비현실적입니다. 교과서나 논문에 나온 프로그램은 개선되고 수정되는 과정을 거치면서 저자들이 바라는 바를 보여주지 실제 일어난 과정을 보여주지는 않습니다.

여러분이 진행 중인 소프트웨어 개발 과정을 잠시 상상해보자. 애자일 개발 방법을 논하지 않더라도 고객 요구 사항을 수집하고, 스펙을 만들고, 아키텍처 설계를 마치고, 세부 설계에 들어간 다음 불꽃 코딩을 거치면 위대한 결과물이 톡 튀어 나온다고 생각하는 개발자는 그렇게 많지 않을 것이다. 하지만 구현에 앞서 문서(스펙, 아키텍처, 세부 설계, 뭐든 좋다)를 열과 성을 다해 제대로 작성하지 않았기에 소프트웨어가 엉망진창으로 나온다는 희한한(응?) 주장에는 딱히 반박하지 못했을 것이다. 하지만 정말 그럴까? 우리는 소프트웨어 개발에 앞서 이성적이고 완벽한 문서가 짜잔하고 만들어질 수 있느냐를 놓고 고민할 필요가 있다. 이런 고민이 필요한 이유는 간단하다. 개발자들이 처음부터 완벽한(아니 이성적인) 문서를 만들지 못했다는 죄책감에서 벗어나야 하기 때문이다. 처음부터 완벽한 소프트웨어가 없듯이 처음부터 완벽한 문서도 없다. 그렇다면 이런 상황에서 어떻게 문서를 만들어야 할까? 다음 번에 파나스 큰 형님의 조언을 정리해드리겠다. 조금만 기다리시라. :)

주의: "용감한 프로그래머에게 설계 따윈 필요없으니 코딩으로 바로 뛰어들자!"라는 주장이 아님을 노파심에서 다시 한번 강조한다.

EOB