코드는 설계다: 13년 후의 반론 — Jack W. Reeves

이전 포스팅에서 잭 W. 리브스(Jack W. Reeves)의 1992년 에세이 "코드 = 설계 (Code As Design)"라는 통찰을 다뤘다.

그로부터 13년이 지난 2005년, 리브스는 자신의 주장에 대해 쏟아진 비판과 오해들에 답하는 후속 에세이 "What Is Software Design: 13 Years Later"를 발표했다.

이전 글이 소프트웨어 공학의 '본질'을 꿰뚫었다면, 이번 글은 현실 세계의 '반론'들에 대한 날카로운 '반박'이다. 여전히 많은 개발 조직이 겪고 있는 비효율적인 프로세스와 오해에 대해 그가 어떻게 방어 논리를 펼쳤는지 정리해 본다.

코드는 설계다: 13년 후의 반론 (Jack W. Reeves)

리브스가 1992년에 처음 에세이를 발표했을 때, 그는 업계의 격렬한 반박을 기대했다. 하지만 돌아온 것은 침묵이었다. 인터넷이 발달하고 위키 문화가 퍼진 뒤에야 그는 사람들이 자신의 글을 읽고 토론하고 있음을 알게 되었다.

하지만 그 토론의 대부분은 "코드가 설계라니, 그럼 설계도 안 하고 막 코딩하라는 말이냐?"라는 식의 오해거나, 기존의 고정관념에 갇힌 비난들이었다. 리브스는 이에 대해 4가지 주요 관점으로 반박한다.

1. '프로그래머는 조립공'이라는 착각 (순환 논리의 오류)

가장 흔한 비판은 이런 논리였다.

리브스는 이것이 전형적인 '논점 선취의 오류(Begging the Question)'라고 지적한다. 비판하는 사람들은 이미 '프로그래밍 = 제조(Manufacturing) 활동'이고, '프로그래머 = 조립 라인의 노동자'라는 전제를 깔고 있다.

리브스의 주장은 간단하다. "소스 코드를 설계로 간주할 때, 소프트웨어 업계에서 벌어지는 수많은 현상(설계 불일치, 유지보수의 어려움 등)이 훨씬 더 잘 설명된다"는 것이다. 반대론자들은 기존의 낡은 가정을 방어하기 위해 새로운 관점을 거부할 뿐이다.

2. 설계 '과정'과 설계 '산출물'의 혼동

이 부분이 이번 에세이의 핵심이다. 많은 사람들이 "코드가 설계다"라는 말을 "설계 프로세스를 없애라"는 말로 오해한다.

리브스는 이에 대해 분노하며 명확히 선을 긋는다.

• 설계 과정(Process): 생각을 정리하고, 다이어그램을 그리고, 토론하는 행위.
• 설계 산출물(Product): 그 과정의 최종 결과물.

리브스는 "설계 과정을 하지 말라"고 한 적이 없다. 오히려 좋은 아키텍처, 좋은 추상화가 절실히 필요하다고 강조한다. UML을 쓰든, CRC 카드를 쓰든, 화이트보드에 그림을 그리든, 도움이 된다면 무엇이든 해야 한다.

하지만 중요한 점은 "그 중간 산출물(다이어그램, 문서)들이 소프트웨어 설계 그 자체는 아니라는 점"이다.

• 중간 산출물에 목숨 걸지 마라. 그것은 도구일 뿐이다.
• 최종적인 설계 산출물은 오직 '소스 코드' 뿐이다.
• 아무리 화려한 UML 다이어그램을 그려도, 코드가 엉망이면 설계는 엉망인 것이다.

결국 설계 검증의 유일한 방법은 코드를 작성하고 테스트하는 것뿐이다.

3. '능력 부족한 프로그래머'를 위한 프로세스는 없다

애자일이나 XP(Extreme Programming) 논쟁에서 자주 등장하는 질문이 있다. "당신의 말대로 코드 레벨에서 설계를 하려면 뛰어난 프로그래머가 필요하다. 그럼 능력이 부족한 프로그래머는 어떻게 관리할 것인가?"

보통의 조직들은 이들의 부족한 실력을 메우기 위해 엄격한 프로세스, 방대한 문서 작성, 단계별 승인 절차를 강요한다. 리브스는 이를 의료계에 비유하며 일침을 가한다.

소프트웨어 개발에서 지능, 적성, 경험을 '프로세스'로 대체하려는 시도는 실패할 수밖에 없다. UML을 그리고 문서를 작성하는 것조차도 사실은 상당한 전문성을 요하는 일이다. 문서를 많이 쓰게 한다고 해서 코드를 못 짜는 사람이 갑자기 좋은 소프트웨어를 만들게 되지는 않는다.

4. 컴파일러는 창의적이지 않다 (코드는 명세서가 아니다)

마지막으로, 소스 코드를 '설계'가 아니라 '명세서'로 보고, 컴파일된 바이너리가 진짜 설계라고 주장하는 사람들도 있다.

리브스는 '창의성(Creativity)'을 기준으로 이를 반박한다.

• 명세서(Spec): '무엇(What)'을 만들지 정의한다.
• 설계(Design): '어떻게(How)' 만들지 상세히 기술한다.

소스 코드가 컴파일러를 통해 기계어로 변환될 때, 컴파일러는 정해진 규칙에 따라 기계적으로 변환할 뿐 창의성을 발휘하지 않는다. 기계적인 해석이 가능하다면 그것은 제조 과정이다.

반면, 사람이 소스 코드를 작성할 때는 '어떻게' 구현할지에 대한 무한한 창의적 의사결정이 필요하다. 창의적인 인간의 해석이 필요한 단계, 즉 소스 코드 작성 단계가 바로 설계 단계이다.

결론: 현실을 직시하라

13년이 지난 후에도 리브스의 메시지는 여전히 유효하다. 아니, 오히려 더 강력해졌다.

1. 중간 산출물(문서)을 제품으로 착각하지 마라. 고객이 사용하는 것은 코드(가 실행되는 소프트웨어)이지, 당신이 쓴 설계 문서가 아니다.
2. 코딩을 두려워하지 마라. 설계를 검증하는 유일한 방법은 짓고(Code), 돌려보는(Test) 것이다.
3. 프로세스로 무능력을 감출 수 없다. 개발자에게 필요한 것은 더 많은 문서 양식이 아니라, 코드를 통해 설계를 표현할 수 있는 역량이다.

"설계가 끝날 때까지 코딩하지 마라"는 폭포수 모델의 망령은 여전히 곳곳에 남아있다. 리브스는 우리에게 다시 한번 상기시킨다. 우리가 키보드를 두드리는 그 순간이, 가장 구체적이고 치열한 설계를 하고 있는 순간이라고.