[Code Complete] CH2: Metaphors for a Richer Understanding of Software Development

1. The Importance of Metaphors

 저자는 다양한 필드의 과학들은 모두 은유를 활용해 어떤 개념을 효율적으로 공부할 수 있다는 점에 주목한다. 생각해보면 과학이나 공학을 공부하면서, 물리 화학 법칙들을 은유를 통해 더 잘 이해할 수 있다. 예를 들어, 우리는 당구장에서 쓰리쿠션을 하는 행위로부터 물리학에서 배우는 탄성 충돌에 대해서 이해할 수 있다. 은유적인 상황 속에서 새로운 것을 발견하기도 한다. 예를 들어, 화학자 Kekulé은 뱀이 자기의 꼬리를 물고 빙글빙글 돌아가는 꿈을 꾼 뒤에, 6각형의 고리 형태인 벤젠 구조의 모델을 구상하고, 이를 증명했다.

 

 이처럼 좋은 은유로 간단하며, 이해하기 쉽고, 동작 과정을 설명할 수 있는 '모델'을 만들 수 있다. 그러나 이러한 모델들이 때로는 '충돌'을 일으키기도 한다. 예를 들어, 고대부터 내려왔던 천동설 모델과, 코페르니쿠스가 제시한 지동설 모델은 완전한 차이를 보인다. 여기에서 중요한 점은, 과학자들의 토론에 의해 모델은 더 "wrong"에서 "right"로 발전하는 것이 아니라, "worse"에서 "better"로 진화한다는 것이다. 지동설을 학생들이 공부하고, 믿는 이유는 그것이 현재 자연 현상들을 가장 잘 설명하는 모델일 뿐이다. 어떤 모델이 "옳다"라는 것을 증명할 순 없다. 

 

 컴퓨터 과학 분야 또한 마찬가지이다. 초기 컴퓨터 과학에서는 데이터를 sequential stream of cards로 보는computer-centered view가 패러다임이었지만, Bachman에 의해 데이터는 연속적이지 않으며, 일종의 pool에 흩어져 있고 이를 database가 관리한다는 database-oriented view 모델을 발표하고, 패러다임의 전환이 일어났다. Bachman의 metaphor가 성공한 이유는, 그 모델로 성능의 향상을 거둘 수 있다고 모두를 이해시켰기 때문이다. 

 

 그러나 실제로는, worse model이더라도 배울 점이 있고, 특정 상황에서는 그 모델을 적용시키는 것이 더 좋은 결과를 가져올 수 있다! 컴퓨터 과학 분야에서는 서로를 보충하기도 하는 모델, 서로 상충되는 모델이 다양하게 존재하는데, 이렇게 서로 다른 현상을 설명하는 다양한 모델을 이해하기 위해서 은유가 사용된다.

 

2. How to Use Software Metaphors

 software metaphor는 처음부터 끝까지 알려주는 로드맵이라기 보다는, 문제 해결을 도와주도록 빛을 밝혀주는 손전등과 같다. 로드맵에 해당하는 기술은 알고리즘이다. 알고리즘은 특정 task를 해결하기 위한 instructions들이고, 알고리즘을 그대로 따라가면 답을 찾을 수 있다. 그러나 SW metaphor는 큰 방향만 제시하는 휴리스틱에 해당한다. 

 

 예를 들어, 알고리즘은 Tmap 추천 경로로 서울에서 부산까지의 경로를 안내하지만, 휴리스틱은 나침반을 보고 동남쪽으로 이동하라는 것을 알려주고, 중간에 길을 잃었을때는 주변 사람이나 경찰에 연락을 취하고, 목적지를 가기위한 교통수단 등을 안내해주는 자료를 제공한다. 즉 휴리스틱은 실제적인 instruction을 사용자 스스로가 개발할 수 있도록 도움을 제공할 뿐이다.

 

 실제적인 instruction들이 제공된다면 프로그래밍이 쉬워지고, 결과를 예측하기 쉽다. 그러나 프로그래밍에서 가장 도전적인 과제는 문제를 conceptualizing하는 것이고, 프로그래밍에서 나타나는 많은 문제들이 문제를 제대로 conceptualizing하지 않았을 때 발생한다. 왜냐하면, 각각의  프로그램은 general하지 않고 개념적으로 unique하기 때문에, general set of instructions(==algorithm)이 모든 case에 적용되지 않는 것이다. 그러므로, 최소한 문제에 어떻게 접근할 지 알려주는 휴리스틱을 프로그래머들이 배워야하고, metaphor는 SW 개발을 위한 insight를 제공한다. 이것이 SW metaphor를 배워야하는 이유이다.

 

3. Common Software Metaphors

 하지만 SW metaphor중에는 "혼란스러운" 은유가 많다. 그래서 가장 기본적이며 널리 인정받은 software metaphor들에 대해 소개하겠다.

 

-1. Software Penmanship: Writing Code

 가장 원시적인 형태의 metaphor는 SW개발은 "writing code"와 같다는 것이다. 이 metaphor는 프로그래밍 개발이라는 것은, 자리에 앉아 종이에 펜을 활용해서 공식적인 편지를 쓰는 것과 같다고 은유한다. 글을 쓰는데에는 다른 절차가 필요하지 않고, 프로그래머가 하고 싶은 대로 코드를 작성하면 된다. 이 은유를 다른 말로는 letter-writing metaphor라고 한다.

 

 개인의 toy project같은 경우에,  writing code metaphor는 적절한 은유라고 볼 수 있다. 그러나 programming은 당연하게도, 혼자서 하는 것이 아니다. 우리는 정말 다양한 개성을 가진 많은 사람들과 함께 코드를 작성한다. 이때 실제 편지는 한번 보내면 편지 내용을 수정할 수 없으므로, "전부 폐기" 하고 다시 작성해야한다. code는 쉽게 수정해서 다시 배포할 수 있다. 즉, writing code metaphor는 지나치게 단순하며 경직된 은유에 해당한다.

 

-2. Software Farming: Growing a System

 또다른 metaphor에서는 SW 개발자들은 씨를 심고, 곡식을 기르는 농부들에 비유한다. 프로그래머들은 곡식을 디자인하고, 이를 코딩하고, 테스트하고, 추가한다. 이러한 "정해진" 단계를 밟으면서, 농사를 하면서 발생하는 트러블들을 최소화할 수 있다는 것이다.

 그러나 Farming metaphor에서는, 각 단계를 보다 효율적인 방법으로 바꿀 수 있으므로, 새로운 metaphor를 적용할 수 있다는 것이다. 때로는 단계들 중에 하나를 제외하기도 하고, 단계들을 나눈 것을 합치며 생산성을 높일 수 있다. 정해진 절차를 지키는 것에 중점을 둔 Growing a System metaphor는 발전 가능성이 낮으므로 적합하지 않다.

 

-3. Software Oyster Farming: System Accretion

 System Accretion metaphor는 Growing metaphor와 연관이 있지만, Accretion이 조금 더 많은 인사이트를 제공한다. accretion의 의미는, 점진적인 추가나 삽입에 의한 성장을 의미한다. 그것을 보여주는 비유가 굴속의 진주이다. 진주는 처음에는 그 크기가 매우 작지만, 정성스럽게 calcium carbonate를 추가하며 키운다면 최고의 보석이 된다. 

 

 이처럼 System Accretion metaphor는 Incrementa하고 Adaptive, Evolutionary한 방법을 강조한다. 우리는 처음 문제 설정을 매우 간단한 스켈레톤 코드에서부터 시작해서, 점진적으로 근육과 피부를 붙여나가면서 프로그램을 완성시킬 수 있다.발전 가능성이 무한하므로, 이 방법은 Growing a System metaphor보다 better metaphor라고 할 수 있다. 실제로 많은 프로젝트에서 활용하고, 업계에서 유행하는 Agile도 이 Metaphor에서부터 시작했다.

 

4. Software Construction: Building Software

 Construction이라는 Metaphore는, writing이나 growing에 비해 더 "detail"한 가이던스를 제공한다. 어떤 건축물을 짓는 과정에 대한 비유인데, Building은 다양한 단계를 갖추고 있다. planning, preparation, execution이 그것이다. 

 Building에서 가장 중요한 것은, 단연 planning이다. 만약 plan을 잘못짜서 중대한 설계 실수가 나온다면, 그동안 썼던 코드를 갈아엎고 refactor하거나 심각하면 처음부터 재작성해야한다. 예를 들자면, 강아지 집을 짓는데 입구를 짓지 않은(...) 경우이다.

아무리 그래도 입구는 지어야지..

 

그럼 더 복잡한 단독주택을 짓는다고 생각해보자. 이때는 정말 세심한 접근이 필요하다. 그렇다면 우리는 단계를 나누어서 집을 짓도록 해야한다.

1. 어떤 집을 짓고 싶은지 결정 : problem definition
2. 건축가와 함께 구조를 결정하고 설계 일임 : software architectural design
3. 구체적인 청사진을 완성하고 계약 완료 : detailed software design
4. 집 프레임 건설, 지붕 올리기 등 구체적인 건축 : software construction
5. 페인트칠하고 집 내부 외부 꾸미기 : software optimization
6. 부동산과 계약해서 시세 평가받고 세입자 구하기 : software reviews and inspections

 

 이것조차도 상당히 단순화한 것이고, 큰 프로젝트일수록, 더 세심한 계획이 필요하고, 이걸 문서화하는것이 좋다. 예를 들어, Capers Jones는 1 million lines of code는 약 69개 종류의 documentation을 필요로 한다고 기록했다. 왜냐하면, lack of planning은 이후 major problem들을 발생시키기 때문이다.

 

 실제 기업에서 실시하는 software project들은, 건축으로 치면 Empier State Building의 건설 계획과 비슷하므로, SW개발에 있어 가장 중요한 것이 building-construction metaphor를 적용하는 것이다. 현재 building metaphor가 적용된 개념들은 software architecture, scaffolding, construction, foundation classes, tearing code apart 등이 있다.

5: Software Techniques: The Intellectual Toolbox

 SW기술이 발전하면서 high-quality software를 만들 수 있는 훌륭한 테크닉들이 그동안 생겨났다. 그래서 이러한 많은 테크닉들을 analytical tools로 이용할 수 있다는 은유이다. 마치 숙련된 목수가 toolbox에서 다양한 도구를 적재적소에 사용하는 것처럼, 프로그래머는 그들의 mental toolbox에 analytic tools들을 저장한 후 최고의 효율을 보이는 도구를 잘 사용해보자는 은유이다.

6: Combining Metaphors

 앞서 살펴보았듯, Metaphor들은 algorithm이 아니라 heuristic한 solution이기 때문에, 반드시 한 가지가 정답이라고는 정해지지 않았고, 때로는 오히려 서로 다른 metaphor들을 한꺼번에 적용하는게 좋을 수도 있다. 예를 들어, 우리는 accretion과 construction metaphor를 한꺼번에 적용할 수 있다. 우선 핵심 부분에 대한 계획을 상세히 작성하고, 이후 주변부(pheripheral) 유닛들도 설계한 후 붙인다면(accretion) 효과적으로 프로젝트를 진행할 수 있을 것이다. 또한 Toolbox metaphor같은 경우도 다양한 metaphor들과 합칠 수 있으므로 유용하다.