• Peter Naur의 「Programming as Theory Building」은 프로그래밍을
  프로그램 텍스트를 생산하는 활동이 아니라, 프로그래머가 문제와 해법에 대한 이론을 형성하는 활동으로 본다.

• 여기서 “이론”은 단순한 추상 명제나 문서화된 설계 설명이 아니다.

• 현실 세계의 문제가 어떤 의미를 갖는지 이해하고

• 프로그램 구조가 그 현실과 어떻게 대응하는지 설명할 수 있으며

• 왜 그렇게 설계했는지 정당화하고

• 새로운 요구가 들어왔을 때 기존 구조 안에서 어떻게 통합할지 판단할 수 있는 능력이다.

• 따라서 프로그램의 핵심 지식은 코드나 문서 안에 완전히 담기는 것이 아니라,
  그 프로그램을 이해하는 프로그래머의 머릿속에 있다.

프로그래밍과 지식

• Naur는 프로그래밍을 현실 세계의 활동을 컴퓨터가 수행할 수 있는 형식적 기호 조작으로 대응시키는 활동으로 본다.

• 이 관점에서는 프로그램 수정도 프로그래밍의 일부다.

• 현실 세계의 활동이 변하면 프로그램도 변해야 하기 때문이다.

• 프로그래밍의 본질은 문서나 코드 산출물이 아니라, 프로그래머들이 쌓아 가는 특정한 지식이다.

• 문서는 중요하지만 보조적이다.

• 문서는 이론을 완전히 대체하지 못한다.

• 문서는 이론 형성을 돕는 도구에 가깝다.

사례 1: 컴파일러 이전과 실패

• 그룹 A는 언어 L용 컴파일러를 만들었다.

• 그룹 B는 확장 언어 L + M을 위한 컴파일러를 만들기 위해 A의 컴파일러 코드와 문서, 조언을 제공받았다.

• 코드와 문서는 충분히 제공되었지만, B는 몇몇 설계에서 기존 구조의 힘을 활용하지 못하고 패치식 해법을 제안했다.

• A는 즉시 문제를 알아차리고 기존 구조 안에서 더 단순하고 자연스러운 해법을 제시했다.

• 이 사례의 핵심:

• 프로그램 텍스트와 문서만으로는 설계의 깊은 이론이 전달되지 않는다.

• 기존 설계의 “왜”와 “어떻게 확장해야 하는가”는 문서만으로 충분히 전달되지 않는다.

• 이후 A의 지도를 받지 않은 다른 프로그래머들이 컴파일러를 수정하면서 원래의 강한 구조는 점차 무정형적 추가물에 의해 약화되었다.

• 이는 프로그램 텍스트와 문서가 핵심 설계 이론을 보존하는 데 한계가 있음을 보여준다.

사례 2: 대규모 실시간 시스템

• 약 20만 줄 규모의 산업용 실시간 시스템 사례가 제시된다.
• 설치와 결함 진단을 맡은 프로그래머들은 시스템 설계 초기부터 오랫동안 시스템과 밀접하게 연결되어 있었다.
• 이들은 결함을 진단할 때 주로 자신의 즉각적인 시스템 이해와 주석 달린 코드에 의존했다.
• 반면 문서와 교육을 받은 외부 운영 프로그래머들은 반복적으로 어려움에 부딪혔다.
• 제작사의 숙련 프로그래머들은 그 문제를 쉽게 해결했다.
• 결론:
• 대규모 프로그램의 유지보수와 수정은 프로그램과 오래 연결되어 있던 사람들이 가진 지식에 본질적으로 의존한다.
• 문서화된 설명만으로는 그 지식을 완전히 대체할 수 없다.

Ryle의 “이론” 개념

• Naur는 Gilbert Ryle의 이론 개념을 가져온다.

• 이론을 가진다는 것은 단순히 명제를 아는 것이 아니다.

• 어떤 일을 할 줄 알고

• 그 일을 설명할 수 있으며

• 질문에 답할 수 있고

• 자신의 판단을 정당화할 수 있는 상태다.

• 지능적인 활동은 반드시 규칙을 따르는 활동으로 환원되지 않는다.

• 규칙을 따르는 일 자체도 지능적으로 수행되어야 하기 때문이다.

• 규칙을 따르는 방법에 또 다른 규칙이 필요하다고 하면 무한 퇴행이 발생한다.

• 따라서 지적 활동은 단순한 규칙 수행이 아니라, 상황의 유사성을 파악하고 적절히 대응하는 능력을 포함한다.

이론은 규칙으로 완전히 표현될 수 없다

• 어떤 이론을 가진 사람은 현실의 여러 상황 사이에서 의미 있는 유사성을 알아본다.

• 하지만 이런 유사성은 명확한 기준이나 규칙으로 완전히 표현되기 어렵다.

• 예:

• 얼굴의 닮음

• 선율의 유사성

• 와인의 맛의 유사성

• 마찬가지로 프로그래밍에서도 새로운 요구가 기존 구조와 어떻게 닮았는지, 어디에 통합해야 하는지는 단순 규칙으로 환원하기 어렵다.

• 이 점이 암묵지의 핵심이다.

프로그래머가 가져야 하는 이론

• 프로그램의 이론을 가진 프로그래머는 다음을 할 수 있어야 한다.

1. 현실 세계와 프로그램의 대응을 설명할 수 있어야 한다

• 프로그램의 각 부분이 현실 세계의 어떤 활동이나 개념에 대응하는지 설명할 수 있어야 한다.
• 반대로 현실 세계의 어떤 활동이 프로그램 안에서 어떻게 표현되는지도 설명할 수 있어야 한다.
• 무엇이 관련 있고 무엇이 무관한지를 판단하려면 현실 세계 전체에 대한 이해가 필요하다.

2. 프로그램이 왜 그렇게 되어 있는지 정당화할 수 있어야 한다

• 프로그램의 구조와 세부 구현이 왜 그렇게 설계되었는지 설명할 수 있어야 한다.
• 이 정당화는 규칙, 추론, 설계 원칙, 정량적 추정 등을 사용할 수 있다.
• 그러나 최종적으로 어떤 원칙을 적용할지 판단하는 것은 프로그래머의 직접적인 통찰에 달려 있다.

3. 새로운 수정 요구에 건설적으로 대응할 수 있어야 한다

• 새로운 요구가 기존 프로그램의 어떤 기능이나 구조와 유사한지 알아볼 수 있어야 한다.
• 그 유사성을 바탕으로 수정이 기존 이론에 자연스럽게 통합되도록 설계할 수 있어야 한다.
• 이 능력은 문서화된 절차만으로 대체하기 어렵다.

프로그램 수정과 비용

• 소프트웨어는 필연적으로 수정된다.

• 사용 과정에서 새로운 요구가 생기고

• 현실 세계의 조건도 변하기 때문이다.

• 흔히 기존 프로그램을 수정하면 새로 만드는 것보다 싸다고 생각한다.

• 그러나 Naur의 관점에서는 이 기대가 항상 타당하지 않다.

• 프로그램 수정의 비용은 텍스트 편집 비용이 아니다.

• 핵심 비용은 기존 프로그램의 이론을 이해하고

• 새 요구를 그 이론 안에 통합하는 데 든다.

• 따라서 코드가 쉽게 편집 가능한 텍스트라는 사실만으로 수정이 쉽다고 말할 수 없다.

유연성의 한계

• 프로그램에 미래의 변화를 대비한 유연성을 미리 넣자는 주장은 부분적으로만 타당하다.

• 유연성은 공짜가 아니다.

• 어떤 미래 상황을 대비할지 정해야 하고

• 매개변수와 구조를 설계해야 하며

• 구현, 테스트, 설명 비용이 든다.

• 그 유용성은 불확실한 미래 사건에 달려 있다.

• 따라서 유연성은 변화 대응의 일반 해법이 될 수 없다.

• 중요한 것은 모든 변화에 대비한 구조를 미리 넣는 것이 아니라, 변화가 왔을 때 프로그램의 이론에 근거해 적절히 판단하는 능력이다.

좋은 수정과 나쁜 수정

• 같은 외부 동작을 만족하는 수정도 여러 방식으로 구현될 수 있다.

• 겉으로는 모두 올바르게 보일 수 있다.

• 하지만 프로그램의 이론 관점에서는 차이가 크다.

• 어떤 수정은 기존 이론을 자연스럽게 확장한다.

• 어떤 수정은 기존 구조 위에 덧붙인 패치처럼 작동한다.

• 후자의 수정이 반복되면 프로그램은 점차 누더기가 된다.

• 프로그램의 장기적 생존 가능성은 각 수정이 기존 이론에 얼마나 잘 뿌리내리는지에 달려 있다.

프로그램의 삶, 죽음, 부활

프로그램의 삶

• 프로그램의 이론을 가진 프로그래머들이 여전히 그 프로그램을 능동적으로 통제하고 있을 때 프로그램은 살아 있다.
• 이들은 수정 요구에 지적으로 대응할 수 있다.

프로그램의 죽음

• 프로그램의 이론을 가진 팀이 해체되면 프로그램은 죽는다.
• 죽은 프로그램도 여전히 실행될 수 있고 유용한 결과를 낼 수 있다.
• 하지만 수정 요구에 제대로 대응하지 못할 때 그 죽음이 드러난다.

프로그램의 부활

• 새로운 팀이 기존 프로그램의 이론을 다시 구축하려는 시도다.
• Naur는 이것이 엄밀한 의미에서는 불가능하다고 본다.
• 문서와 코드만으로 원래 팀이 가졌던 이론을 완전히 복원할 수 없기 때문이다.
• 부활은 가능하더라도 비싸고 어렵고, 원래 이론과 다른 이론을 낳을 가능성이 크다.
• 경우에 따라서는 기존 코드를 살리는 것보다 새 팀이 문제를 새롭게 해결하는 편이 더 낫고 더 쌀 수 있다.

방법론에 대한 비판

• Naur는 프로그래밍 방법론을 “프로그래머가 어떤 순서로 어떤 작업을 해야 하는지 정한 규칙들의 집합”으로 본다.

• 이론 형성 관점에서는 이런 의미의 방법론이 프로그래밍의 본질을 포착하지 못한다.

• 이유:

• 이론 형성에는 정해진 순서가 없다.

• 이론은 본질적으로 부분들의 선형적 조합이 아니다.

• 표기법이나 문서 형식은 이론 형성을 도울 수는 있지만 이론 자체가 아니다.

• 따라서 프로그래밍의 일차 활동에 대해 보편적으로 올바른 방법은 없다는 결론이 나온다.

방법론이 완전히 무가치하다는 뜻은 아니다

• Naur가 부정하는 것은 기계적으로 좋은 설계를 보장하는 절차로서의 방법론이다.
• 방법론, 설계 기법, 표기법, 검증 기법은 교육적 가치를 가질 수 있다.
• 좋은 사례, 구조화 원리, 검증 기법에 익숙한 프로그래머는 더 좋은 이론을 형성할 가능성이 높다.
• 그러나 어떤 기법을 언제, 어떤 순서로 적용할지는 실제 문제를 이해한 프로그래머의 판단에 맡겨져야 한다.

프로그래머의 지위

• 프로그래밍을 산업 생산처럼 보면 프로그래머는 교체 가능한 부품처럼 취급된다.
• 절차와 규칙을 따르면 누구나 같은 결과를 낼 수 있다는 관점이다.
• Naur는 이 관점을 거부한다.
• 프로그램의 핵심 산물이 프로그래머가 가진 이론이라면, 프로그래머는 쉽게 교체 가능한 노동자가 아니다.
• 프로그래머는 컴퓨터가 포함된 활동 전체를 책임 있게 발전시키고 관리하는 전문직에 가깝다.
• 따라서 프로그래머에게는 지속적인 지위와 책임이 주어져야 한다.
• 교육도 단순한 문법, 표기법, 데이터 처리 기술을 넘어서 이론 형성 능력을 기르는 방향이어야 한다.

XP의 은유와 이론 형성

• XP의 “은유”는 Naur의 이론 형성 관점으로 잘 설명된다.

• 좋은 은유는 팀이 프로그램 구조에 대해 비슷한 추측을 하도록 돕는다.

• 예:

• 프로그램을 “조립 라인”으로 이해한다.

• 프로그램을 “식당”으로 이해한다.

• 좋은 은유는 단순한 비유가 아니다.

• 설계자들이 어떤 구조를 기대해야 하는지

• 새 코드를 어디에 추가해야 하는지

• 다른 사람이 만든 코드와 어떻게 맞물려야 하는지 판단하게 해 준다.

• 팀원이 많고 병렬 작업이 많을수록 공유된 은유의 가치는 커진다.

• 공통 이론이 없으면 각 프로그래머가 자기 나름의 이론을 만들고, 시스템은 점점 불일치하고 복잡해진다.

문서화의 역할

• 문서는 프로그램의 현재 상태를 완전히 따라잡기 어렵다.
• 그렇다고 문서가 불필요한 것은 아니다.
• 문서의 목적은 모든 것을 기록하는 것이 아니라, 다음 프로그래머가 적절한 이론을 형성하도록 돕는 것이다.
• 좋은 문서는 독자의 기억과 경험을 자극하고, 올바른 사고 경로를 열어 준다.
• 이런 문서는 단순히 현재 클래스, 함수, 모듈 목록을 나열하는 문서보다 오래 살아남는다.

좋은 설계 문서의 구성

• 경험 많은 설계자는 보통 다음 항목으로 문서를 시작한다.

• 핵심 은유

• 주요 컴포넌트의 목적 설명

• 주요 컴포넌트 사이의 핵심 상호작용 그림

• 이 세 가지는 다음 팀이 설계 이론을 형성하는 데 큰 도움을 준다.

• 소스 코드 자체도 이론 전달 수단이다.

• 일관된 명명

• 단순한 구조

• 예측 가능한 패턴

• 불필요한 예외의 최소화

• “깨끗한 코드”의 상당 부분은 독자가 시스템에 대한 일관된 이론을 얼마나 쉽게 형성할 수 있는가와 관련된다.