소프트웨어 설계란 무엇인가: 13년 후

게시일: 2025년 12월 12일 | 원문 작성일: 2005년 2월 23일 | 저자: Jack W. Reeves | 원문 보기

원작에 대한 논란

1992년에 쓴 “소프트웨어 설계란 무엇인가”라는 에세이는 꽤 많은 논쟁을 불러일으켰어요. 핵심 주장은 단순해요: 소스 코드가 곧 설계다. 하지만 이 주장에 대해 여러 비판과 오해가 쏟아졌고, 13년이 지난 지금 이에 대해 답변하려고 해요.

순환 논증의 오류

가장 흔한 비판은 “프로그래머는 제조 노동자지 설계자가 아니다”라는 전제에서 시작해요. 근데 이건 논점 선취의 오류(begging the question)예요. 제 주장이 바로 그 전제 자체에 도전하는 건데, 비평가들은 그걸 당연한 사실로 깔고 반박하려 하거든요.

자기 가정을 논리적 증명과 혼동하는 분들이 많아요. “프로그래머 = 제조 노동자”는 증명된 사실이 아니라 하나의 관점일 뿐이에요.

과정 vs. 산출물

또 다른 흔한 오해는 제 주장이 “사전 설계 없이 바로 코딩하라”는 것이라고 생각하는 거예요. 전혀 아니에요.

”우리에게는 좋은 아키텍처(상위 수준 설계), 좋은 추상화(클래스 설계), 그리고 좋은 구현이 모두 필요합니다.”

제 주장은 최종 설계 산출물이 무엇인가에 관한 거예요. 설계자가 미리 생각하는 과정을 건너뛰라는 게 아니에요. 탐색, 스케치, 논의는 모두 설계 과정의 일부지만, 최종 설계 문서는 코드 그 자체라는 거죠.

보조 도구들의 역할

UML 다이어그램, 화이트보드 스케치, 설계 논의 — 이런 것들 저도 적극 지지해요. 하지만 이건 어디까지나 탐색적 보조 수단이에요. 진짜 설계는 코드를 작성하고 테스트할 때 비로소 구체화돼요.

건축가가 스케치북에 아이디어를 그리는 것처럼, 프로그래머도 UML로 아이디어를 탐색해요. 하지만 건축에서 최종 설계 문서가 청사진이듯, 소프트웨어에서 최종 설계 문서는 소스 코드예요.

문서화 vs. 설계

모든 엔지니어링 분야에서 문서화는 핵심 결과물이에요. 소프트웨어도 마찬가지여야 해요. 그리고 소프트웨어의 마스터 설계 문서는 바로 소스 코드예요.

다른 엔지니어링 분야와 비교해볼게요:

• 기계 공학 — 상세 도면이 설계 문서
• 전자 공학 — 회로도가 설계 문서
• 건축 — 청사진이 설계 문서
• 소프트웨어 — 소스 코드가 설계 문서

사양 vs. 설계

코드가 단순한 사양(specification)이 아니라 진정한 설계인 이유가 뭘까요?

사양은 “무엇을 할지”를 명시해요. 반면 설계는 “어떻게 할지”를 충분한 세부사항과 창의성으로 정의하죠.

제조 명령서는 기계적으로 따를 수 있어요. 하지만 소스 코드는 그렇지 않아요. 코드에는 수많은 설계 결정, 추상화 선택, 알고리즘 결정이 녹아있어요. 이건 창의적인 설계 작업이지, 기계적인 변환이 아니에요.

왜 이게 중요한가

이 관점이 업계 현실을 더 잘 설명하는 이유가 있어요:

• 유지보수가 왜 어려운가 — 코드가 설계라면, 코드 변경은 설계 변경이에요. 소프트웨어 유지보수가 어려운 이유가 바로 이거예요.
• 테스트가 왜 중요한가 — 설계를 검증하려면 실제로 만들어봐야 해요. 소프트웨어에서는 코드를 작성하고 테스트하는 게 곧 설계 검증이에요.
• 애자일이 왜 성공했나 — 반복적이고 점진적인 개발 방식이 효과적인 이유는 설계가 코딩 과정에서 진화하기 때문이에요.

결론

”소스 코드 = 설계”라는 관점은 처음엔 도발적으로 들릴 수 있어요. 하지만 이 프레임워크가 소프트웨어 개발의 현실을 더 잘 설명한다고 믿어요.

프로그래머는 제조 노동자가 아니라 설계자예요. 그리고 우리의 설계 문서는 컴파일러가 읽을 수 있는 형태로 작성된, 소스 코드 그 자체예요.