피터 나우어(Peter Naur)는 프로그래밍 언어 문법 표기법인 “배커스-나우어 형식”(BNF)의 공동 저자로 잘 알려져 있다. 그는 1985년 “프로그래밍을 이론 구축으로 보다”라는 글을 썼고, 이 글은 그의 저작집인 Computing: A Human Activity(Naur 1992)에 다시 실렸다. 이 글은 내 생각에 프로그램을 설계하고 코딩하는 과정에서 일어나는 일을 가장 정확하게 설명한 것이다. 나는 이 글을 문서화의 정도, 암묵적 지식의 전달 방법, XP(익스트림 프로그래밍)의 메타포 설정 연습의 가치 등을 논의할 때 자주 참고한다. 또한 이 글은 방법론의 경제적 구조를 분석하는 데 유용한 틀을 제공한다.
이 글에서 주목할 점은 설계자의 작업 품질이 문제에 대한 이론과 해결책에 대한 이론 간의 일치 정도와 관련이 있다는 것이다. 또한 후속 프로그래머의 작업 품질은 그들의 이론과 이전 프로그래머의 이론 간의 일치 정도와 관련이 있다는 점도 중요하다.
나우어의 아이디어를 활용하면 설계자의 임무는 “설계”를 전달하는 것이 아니라 설계를 이끄는 “이론”을 전달하는 것이다. 후자의 목표가 더 유용하고 적절하다. 이는 이론에 대한 지식이 소유자에게 암묵적으로 존재한다는 점을 강조하며, 따라서 이론을 전달하려면 명시적 지식과 암묵적 지식을 모두 전달해야 한다는 것을 의미한다.
다음은 피터 나우어가 이를 표현한 방식이다.
이 글은 프로그래밍이 무엇인지 이해하는 데 기여한다. 프로그래밍은 프로그래머가 특정한 통찰, 즉 문제에 대한 이론을 형성하거나 달성하는 활동으로 보아야 한다는 관점을 제안한다. 이 제안은 프로그래밍을 프로그램과 다른 텍스트를 생산하는 활동으로 보는 일반적인 관점과 대조된다.
여기에 제시된 관점의 배경은 프로그램과 이를 다루는 프로그래머 팀이 예상치 못한 오류나 프로그램의 수정 상황에서 겪는 실제 사례에서 비롯된다. 이러한 관찰을 프로그래밍을 생산 활동으로 보는 관점에 적용하기 어렵다는 점은 이 관점이 오해를 불러일으킬 수 있음을 시사한다. 이에 대한 대안으로 이론 구축 관점을 제시한다.
이 글의 더 일반적인 배경은 프로그래밍이 무엇인지 적절히 이해하는 것이 중요하다는 확신이다. 우리의 이해가 부적절하면 프로그래밍 활동에서 발생하는 어려움을 오해하게 되고, 이를 해결하려는 시도가 갈등과 좌절을 초래할 수 있다.
이론 구축은 특정한 종류의 행동이 순차적으로 진행되어 특정한 문서화된 결과를 도출하는 과정과 다르다. 이론을 구축하는 데는 특정한 행동의 순서가 없는데, 이는 개인이 가진 이론이 본질적으로 부분으로 나뉘거나 순서가 정해져 있지 않기 때문이다. 오히려 이론을 가진 사람은 질문이나 요구에 따라 다양한 방식으로 이를 표현할 수 있다.
특정한 표기법이나 형식화의 사용은 이차적인 문제일 뿐이다. 왜냐하면 이론 자체는 표현될 수 없고, 따라서 그 표현의 형태에 대한 문제도 발생하지 않기 때문이다.
이론 구축 관점에서는 프로그래밍의 주요 활동에 대해 올바른 방법이란 존재할 수 없다는 결론이 도출된다. 이 결론은 여러 측면에서 기존의 의견과 충돌할 수 있으며, 이론 구축 관점에 반대하는 논거로 여겨질 수 있다. 여기서는 두 가지 명백한 모순을 다룬다. 첫 번째는 과학적 방법의 중요성에 관한 것이고, 두 번째는 소프트웨어 개발에서 실제로 사용되는 방법의 성공에 관한 것이다.
첫 번째 논거는 소프트웨어 개발이 과학적 방식에 기반해야 하며, 따라서 과학적 방법과 유사한 절차를 사용해야 한다는 것이다. 이 논거의 결점은 과학적 방법이 존재하며 과학자들에게 도움이 된다는 가정에 있다. 이 문제는 최근 몇 년 동안 많은 논쟁의 주제가 되어왔으며, Feyerabend(1978)와 Medawar(1982)와 같은 저자들은 과학적 방법이 실천적인 과학자들을 위한 지침으로서의 개념은 오류라고 결론지었다.
이 결론은 Polya(1954, 1957)의 문제 해결에 관한 연구와 모순되지 않는다. 이 연구는 수학 분야의 사례를 통해 프로그래밍에도 매우 관련성이 높은 통찰을 제공한다. 그러나 이 연구가 진행해야 할 방법을 제시한다고 주장할 수는 없다. 오히려 이 연구는 다양한 작업 방식을 제시함으로써 문제 해결자의 사고 활동을 자극하는 것을 목표로 한다.
두 번째 논거는 특정 방법의 사용이 출판된 보고서에 따르면 성공적이었다는 것이다. 이에 대한 반박으로, 프로그래밍 방법의 효능에 대한 체계적인 연구는 아직 이루어지지 않았다고 답할 수 있다. 그러한 연구는 잘 확립된 통제 실험 기술을 사용해야 한다(Brooks, 1980 또는 Moher와 Schneider, 1982 참조). 이러한 연구가 부족한 이유는 부분적으로는 결과가 의미 있으려면 발생할 것이 분명한 높은 비용 때문이며, 부분적으로는 프로그램 개발 분야에서 방법이라고 불리는 개념을 운영적으로 확립하는 문제 때문이다. 대부분의 출판된 보고서는 특정 기술과 절차를 설명하고 권장할 뿐, 그 유용성이나 효능을 체계적으로 입증하지 않는다. C. Floyd와 여러 동료들이 수행한 다섯 가지 다른 방법에 대한 상세한 연구(Floyd, 1984)는 임의의 맥락에서 기계적으로 좋은 해결책을 이끌어내는 규칙 체계로서의 방법 개념은 환상이라고 결론짓는다. 남은 것은 프로그래머 교육에서 방법의 효과뿐이다. 이 결론은 프로그래밍의 이론 구축 관점과 완전히 일치한다.
실제로 이 관점에서 프로그래머가 구축한 이론의 질은 프로그래머가 전형적인 문제에 대한 모델 솔루션, 설명 및 검증 기술, 복잡한 상호작용을 하는 많은 부분으로 구성된 시스템을 구조화하는 원칙에 얼마나 익숙한지에 크게 의존한다. 따라서 방법의 많은 관심사는 이론 구축과 관련이 있다. 이론 구축 관점이 방법론자들과 다른 점은 어떤 기술을 사용할지와 그 순서에 대한 문제이다. 이론 구축 관점에서는 이는 전적으로 프로그래머가 실제 해결해야 할 문제를 고려하여 결정해야 할 문제로 남는다.
이론 구축 관점(Theory Building View)의 결과와 현재 널리 퍼진 관점 사이의 차이가 가장 두드러지는 부분은 프로그래머의 개인적 기여와 프로그래머의 적절한 지위에 대한 인식이다. 이론 구축 관점과 기존의 관점 사이의 대조는 프로그래밍에 대한 일반적인 논의에서 자주 드러난다. 예를 들어, Oskarsson[1982]이 대규모 소프트웨어 시스템의 수정 가능성에 대해 진행한 연구를 살펴보자. 이 연구는 대형 상용 시스템의 한 버전에서 이루어진 상당한 수의 수정 사항에 대해 광범위한 정보를 제공한다. 각 수정의 배경, 내용, 구현을 설명하며, 특히 프로그램 변경이 특정 모듈에만 국한되는 방식에 주목한다.
그러나 이 연구에서는 수정 사항의 구현이 프로젝트에 참여한 500명의 프로그래머의 배경(예: 프로젝트 참여 기간)에 따라 달라질 수 있다는 점은 전혀 언급하지 않는다. 또한, 설계 결정이 500명의 프로그래머 사이에 어떻게 분배되었는지에 대해서도 설명하지 않는다. 그럼에도 불구하고, ‘결정이 잘못된 블록에서 구현되었다’거나 ‘AXE 철학’과 같은 표현을 통해 이론의 중요성이 간접적으로 인정되고 있다. 하지만 연구가 진행된 방식 때문에 이러한 인정은 고립된 단서로만 남을 뿐이다.
더 일반적으로, 현재의 많은 프로그래밍 논의는 프로그래밍을 산업 생산과 유사한 것으로 간주하는 듯하다. 프로그래머는 생산 과정의 구성 요소로 여겨지며, 절차 규칙에 의해 통제되고 쉽게 교체될 수 있는 존재로 인식된다. 또 다른 관련된 관점은 인간이 기계처럼 규칙을 따를 때 가장 잘 작동한다는 것이다. 이는 형식적 표현 방식에 대한 강조로 이어지며, 이를 통해 형식적 조작 규칙에 기반한 논리를 수립할 수 있다고 본다. 이러한 관점은 컴퓨터를 다루는 사람들 사이에서 흔히 발견되는, 인간의 마음이 컴퓨터처럼 작동한다는 생각과 잘 맞아떨어진다. 산업 관리 차원에서 이러한 관점은 프로그래머를 낮은 책임과 짧은 교육만으로 충분한 노동자로 취급하도록 한다.
이론 구축 관점에서는 프로그래밍 활동의 주된 결과가 프로그래머가 가진 이론이라고 본다. 이 이론은 그 자체로 각 프로그래머의 정신적 소유물이기 때문에, 프로그래머를 프로그래밍 생산 활동에서 쉽게 교체할 수 있는 구성 요소로 보는 개념은 폐기되어야 한다. 대신 프로그래머는 컴퓨터가 포함된 활동의 책임 있는 개발자이자 관리자로 간주되어야 한다. 이러한 역할을 수행하기 위해 프로그래머는 엔지니어나 변호사와 같은 다른 전문직과 유사한 지위를 가진 영구적인 직책을 부여받아야 한다. 이들의 기업 내 기여는 지적 능력에 기반을 둔다.
이론 구축 관점이 제안하는 프로그래머의 지위 상승은 프로그래머 교육의 재정립으로 뒷받침되어야 한다. 표기법, 데이터 표현, 데이터 처리와 같은 기술적 숙련도는 여전히 중요하지만, 교육의 주된 초점은 이론 형성에 대한 이해와 능력을 키우는 방향으로 전환되어야 한다. 이를 어느 정도까지 가르칠 수 있는지는 여전히 열린 질문이다. 가장 유망한 접근 방식은 학생들이 지도 하에 구체적인 문제를 해결하며 능동적이고 건설적인 환경에서 학습하는 것이다.
외부 환경의 변화에 따라 프로그램을 수정하는 것을 프로그래밍의 핵심 요소로 받아들일 때, 프로그래밍의 주요 목표는 프로그래머가 특정 문제를 해결하기 위해 프로그램 실행을 통해 이론을 구축하는 것이라고 주장할 수 있다. 이러한 관점은 프로그램의 생명이 프로그래머가 그 이론을 지속적으로 지원하는 데 달려 있다는 개념으로 이어진다. 또한, 이 관점에서 프로그래밍 방법론은 프로그래머가 따라야 할 일련의 절차 규칙으로 이해되지만, 이는 잘못된 가정에 기반을 두고 있으므로 기각되어야 한다. 이러한 관점의 추가적인 결과로, 프로그래머는 컴퓨터가 속한 활동의 책임 있는 영구적 개발자 및 관리자로서의 지위를 부여받아야 하며, 그들의 교육은 데이터 처리와 표기법에 대한 지식 습득과 함께 이론 구축 능력을 강조해야 한다.
프로그래밍을 이론 구축의 관점에서 바라보면, 익스트림 프로그래밍(XP)에서의 “메타포 구축” 활동을 더 잘 이해할 수 있다. 또한, 설계 지식을 전달하는 데 있어 암묵적 지식과 문서화의 상호 보완적 역할을 명확히 파악할 수 있다.
켄트 벡은 디자인 팀이 프로그램의 전반적인 설계를 단일 메타포에 맞춰 단순화하는 것이 유용하다고 제안했다. 예를 들어, “이 프로그램은 조립 라인과 비슷하다. 라인을 따라 섀시에 부품이 추가되는 방식이다.” 또는 “이 프로그램은 레스토랑과 비슷하다. 웨이터와 메뉴, 요리사, 계산원이 있는 구조다.“와 같은 메타포를 사용할 수 있다. 메타포가 적절하다면, 디자이너들이 그 메타포를 중심으로 만드는 다양한 연관성은 프로그래밍 상황에 잘 맞는다.
이는 바로 나우르가 제안한 설계 이론 전달의 개념과 일치한다. 만약 “조립 라인”이 적절한 메타포라면, 이후 프로그래머들은 조립 라인에 대해 알고 있는 지식을 바탕으로 소프트웨어의 구조를 추측할 수 있고, 그 추측이 실제와 “가깝다”는 것을 발견하게 된다. 이는 단 두 단어, “조립 라인”이 가진 놀라운 힘이다.
좋은 메타포의 가치는 디자이너의 수가 많을수록 더 커진다. 각 사람의 추측이 다른 사람들의 추측과 “가까울수록” 최종 시스템 설계의 일관성은 더욱 높아진다. 10명의 프로그래머가 최대한 빠르게 병렬로 작업하면서 각자 설계 결정을 내리고 클래스를 추가한다고 상상해보자. 각자는 필연적으로 자신만의 이론을 발전시킬 것이다. 코드를 추가할수록 그들의 작업을 묶는 이론은 점점 더 일관성이 없어지고 복잡해진다. 유지보수가 어려워질 뿐만 아니라, 그들 자신의 작업도 어려워진다. 설계는 쉽게 “엉망진창”이 될 수 있다. 반면, 공통의 이론이 있다면, 그들은 서로 잘 맞는 방식으로 코드를 추가할 수 있다.
적절하고 공유된 메타포는 팀원이 방금 추가한 코드의 위치를 정확히 추측하게 하고, 자신의 새로운 코드를 그와 어떻게 맞출지 알려준다.
문서는 거의 항상 현재 프로그램의 상태보다 뒤쳐져 있다. 하지만 사람들은 주변을 잘 살펴보는 능력이 있다. 그렇다면 문서에는 무엇을 담아야 할까? 다음 프로그래머가 프로그램에 대한 적절한 이론을 구성하는 데 도움이 되는 내용을 담아야 한다. 이는 매우 중요하다. 문서의 목적은 독자의 기억을 되살리고, 관련 경험과 비유를 통해 사고의 경로를 설정하는 것이다.
이런 종류의 문서는 프로그램의 수명 동안 단순히 시스템의 구성 요소를 나열하는 것보다 더 안정적이다. 설계자는 관련 사고 경로를 설정하기 위해 필요한 모든 표현 방식을 자유롭게 사용할 수 있다. 심지어 전체 프로그램에 적합한 단일 비유를 찾지 못했다면 여러 비유를 사용할 수도 있다. 예를 들어, 한 섹션은 프랙탈 압축 알고리즘을 구현하고, 두 번째 섹션은 회계 장부와 유사하며, 사용자 인터페이스는 모델-옵저버 디자인 패턴을 따른다고 설명할 수 있다.
경험 많은 설계자들은 종종 문서를 다음 세 가지로 시작한다:
이 세 가지 항목만으로도 다음 팀이 설계에 대한 유용한 이론을 구성하는 데 큰 도움이 된다.
소스 코드 자체도 다음 프로그래머에게 이론을 전달하는 역할을 한다. 간단하고 일관된 명명 규칙은 다음 사람이 일관된 이론을 구성하는 데 도움을 준다. 사람들이 “깨끗한 코드”에 대해 이야기할 때, 그들이 말하는 상당 부분은 독자가 시스템에 대한 일관된 이론을 얼마나 쉽게 구성할 수 있는지와 관련이 있다.
문서는 모든 것을 말할 필요도 없고, 그럴 수도 없다. 문서의 목적은 다음 프로그래머가 시스템에 대한 정확한 이론을 구성하는 데 도움을 주는 것이다.