모듈성의 진짜 의미는 수행 그 자체다

이 논문은 “Fun Boy Three Were Wrong: it is what you do, not the way that you do it”라는 제목 아래, 모듈성의 본질과 그 역사적 배경을 재조명하고, 특히 스프레드시트 설계에 적용할 때 발생할 수 있는 문제점을 탐구한다. 서론에서는 1970년대 팝 음악 가사와 달리 프로그래밍에서는 “무엇을 하는가가 중요하고, 어떻게 하는가는 부차적이다”는 모듈성의 핵심 원칙을 제시한다. 저자는 많은 사람들이 스프레드시트를 모듈화해야 한다고 주장하지만, 구체적인 의미와 장점을 명확히 설명하지 못한다는 점을 지적한다. 2장에서는 모듈성의 핵심 아이디어를 정리한다. 데이터 구조를 하나의 모듈에 캡슐화하고, 외부에서는 정의된 연산(인터페이스)만 사용하도록 함으로써 구현 세부를 숨긴다(정보 은닉). 이렇게 하면 구현을 바꾸어도 인터페이스가 유지되는 한 다른 모듈에 영향을 주지 않는다. 추상 데이터 타입(ADT) 개념을 도입해, 사용자는 연산 이름, 매개변수 타입, 반환값만 알면 되고 내부 구현은 알 필요가 없다는 점을 강조한다. 또한, 이러한 설계는 별도 컴파일과 독립적인 팀 개발을 가능하게 한다. 와이어트의 Modula‑2와 Oberon에서 제시된 스택 모듈 정의 예시를 통해 구체적인 인터페이스와 구현 분리를 보여준다. 3장에서는 대출 계산 프로그램을 예시로 들어 모듈화를 실제 코드 설계에 적용하는 과정을 설명한다. 세 개의 모듈(입력, 계산, 출력)로 나누고, 금리 유형 플래그를 문자열 그대로 저장하면 다국어 지원 시 모든 모듈을 수정해야 하는 문제를 제시한다. 이를 해결하기 위해 Loans 모듈을 ADT 형태로 정의하고, set_interest_type, interest_type 같은 인터페이스만 공개한다. 이렇게 하면 입력 모듈은 문자열을 플래그로 변환해 전달하고, 출력 모듈은 플래그를 받아 적절한 문자열을 표시한다. 구현 세부가 바뀌어도 인터페이스만 유지되면 다른 모듈은 수정할 필요가 없어진다. 3.1절에서는 스프레드시트가 셀 수준에서 정보 은닉을 제공하지 못한다는 점을 강조한다. 셀 안에 복잡한 로직을 숨길 방법이 없으며, 동일 데이터가 여러 시트에 중복돼 관리가 어려워진다. 이는 1999년 David Every가 언급한 초기 고급 언어의 한계와 유사하다. 4장에서는 모듈성의 역사적 배경을 살펴본다. 1960년대의 소프트웨어 위기와 제한된 메모리·연산 자원 속에서 효율적인 코드를 만들기 위해 모듈화와 정보 은닉이 필요했으며, 1970년대에는 팀 프로그래밍을 지원하기 위한 언어 설계 목표가 등장했다. 와이어트는 Modula‑2의 모듈을 “벽”이라고 비유하며, 외부에 공개된 식별자만 접근 가능하도록 함으로써 정보 은닉을 구현했다. 파라스는 모듈을 나누는 기준을 “변경이 최소화되는 부분”으로 정의했으며, KWIC 인덱스 생성 예시를 통해 작업을 단계별 모듈로 분할하는 방법을 제시했다. 5장(본문에 포함되지 않았지만 언급된)에서는 구조적 프로그래밍과 탑‑다운 설계가 모듈성의 전신임을 암시한다. 결론에서는 Excel이 모듈성을 전혀 지원하지 않으므로, 모듈성 필요성을 인식하고 다른 스프레드시트 도구나 외부 플러그인, 혹은 전용 프로그래밍 언어를 활용해 문제를 완화해야 한다고 주장한다. 모듈성을 이해하고 적용하면 복잡성 관리, 팀 협업, 유지보수 비용 절감 등 실질적인 이점을 얻을 수 있다.