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

지난번 올려드린 [B급 프로그래머] 소프트웨어 설계 "프로세스"가 항상 이상화된 형태인 이유는?라는 글에 많은 독자분들께서 관심을 보여주셨다. 따라서, 원래 2회로 예정했던 계획을 변경해 3회로 늘이기로 마음 먹었다(쪽대본 아니에요!). 오늘은 지난번 심각한 문제점에도 불구하고 이상적인 프로세스를 기술해야 하는 이유에 대해 파나스 형님께서 쓴 글의 III번 항목을 번역해봤다.

위에서 언급한 내용(이상적인 프로세스의 비현실성)은 아주 명백하며, 주의 깊은 사고가에게 잘 알려져 있으며, 정직한 사람들이라면 수긍할 것입니다. 그럼에도 불구하고 소프트웨어 설계 프로세스, 소프트웨어 설계 방법론을 다루는 워킹 그룹, 소프트웨어 설계를 논리적인 방법으로 기술하는 (이윤이 많이 남는) 각종 교육 과정에서는 늘 이상화된 프로세스를 주제로 삼습니다. 이런 사람들이 성취하려는 목표가 무엇일까요? 이상적이긴 하지만 완전히 달성할 수 없는 프로세스를 파악했다면, 최대한 비슷하게 이상적인 프로세스를 따를 수 있으며 그 결과 이상적인 프로세스를 따를 경우 만들 수 있어야 했던 문서를 작성할 수 있습니다. 이런 활동을 '이상적인 설계 프로세스를 위조(fake)하기'라 부릅니다. 이런 위조 기법이 필요한 이유를 정리하면 다음과 같습니다.

1. 설계자들은 지침이 필요합니다. 큰 프로젝트를 맡았다면, 엄청난 작업 분량에 쉽게 압도 당합니다. 무엇을 먼저해야 할지 확실하지 않습니다. 이상적인 프로세스를 제대로 이해하면, 프로젝트 진행 방식을 알 수 있습니다.
2. 주먹구구식 임시 변통 대신 프로세스를 따르려 노력할 경우 이상적인 설계에 좀더 가까이 다가갈 것입니다. 예를 들어, 심지어 이상적인 시스템을 설계하기에 필요한 모든 사실을 모를 경우에도, 코딩에 앞서 이런 사실을 찾으려는 노력은 설계를 더 좋게 만들고 재작업을 줄일 것입니다.
3. 조직이 여러 소프트웨어 프로젝트를 수행할 때, 표준화된 절차는 큰 장점입니다. 여러 프로젝트 사이에서 좋은 설계 검토를 비롯해, 사람, 아이디어, 소프트웨어 공유를 원활하게 만듭니다. 표준화된 프로세스를 명세할 경우, 이상적이어야 한다는 사실은 합리적으로 보입니다.
4. 이상적인 프로세스에 동의했다면, 프로젝트를 만들어가는 프로세스를 측정하기가 더 쉬워집니다. 이상적인 프로세스가 요청하는 내용과 비교해 프로세스의 산출물을 비교할 수 있습니다. 어느 부분에서 뒤쳐졌는지 앞섰는지 알 수 있습니다.
5. 외부에서 프로젝트 진행을 주기적으로 검토하는 관례는 좋은 관리에 있어 핵심입니다. 프로젝트가 표준 프로세스를 따르려 시도한다면, 검토도 쉬워집니다.

지난번 글을 읽고 나서 이번 글을 읽으면 갑자기 멘붕이 올 것이다. 분명히 이상화된 프로세스는 현실적이지 않다고 말했는데, 그래도 이상적인 프로세스를 추구해야 한다는 모순된 이야기가 나온다. 너무 고민하지 마시라. 여기서 핵심은 바로 '위조(fake)'니까. 위조를 사전에서 찾아보면 '어떤 물건을 속일 목적으로 꾸며 진짜처럼 만듦.'이라 나온다. 코드 작성 과정에서 초롱초롱한 눈망울로 모니터 속에 들어갈 기세로 집중하는 개발자들이 문서를 작성하기만 하면 동공이 풀리고 어깨가 축 늘어지고 줄담배를 피고 웹 서핑을 하며 머리카락을 쥐어 뜯는 이유는 늘 진실되게 대화하는 컴퓨터 프로그래밍 언어와 달리 능숙한 위조를 요구하는 사람 언어로 뭔가를 작성해야 하기 때문이다. 레지스터 값 하나에 목숨을 거는 개발자들에게 위조는 고문 그 자체다. T_T 하지만, 문서를 보는 주체는 컴퓨터가 아니라 사람이므로 당연히 사람에 맞춰야 하며(빌어먹을 인문학!!!!!), 이 과정에서 이상과 현실 사이에 심각한 괴리가 생기기 마련이다.

자 그렇다면 우리가 위조해야 하는 이상화된 형태의 소프트웨어 설계 "프로세스"가 무엇일까? 파나스 큰 형님이 초지 일관 주장하는 모듈화와 관련이 깊다. 요약하자면 요구 사항 명세, 모듈 구조 설계와 문서화, 모듈 인터페이스 설계와 문서화, 'uses' 계층 설계와 문서화, 모듈 내부 구조 설계와 문서화, 프로그램 작성, 유지 보수 순을 따른다. 세부 사항을 여기서 설명할 경우 큰 주제를 흐릴 가능성이 높으므로 다음에 기회가 닿으면 하나씩 소개하기로 하겠다.

여기까지 글을 적고 허무하게 끝내버리면 "사람 약 올리냐!"라고 민원이 빗발칠게 뻔하므로, 다음에 올려드릴 마지막 글에서는 불쌍한 개발자들을 위해 이상화된 설계 문서를 _쉽고 제대로_ '위조'하는 방법을 (지금까지 경험을 곁들여) 정리하겠다.

EOB