2장: 소프트웨어 개발의 이해를 돕기 위한 비유

2장: 소프트웨어 개발의 이해를 돕기 위한 비유

2.1 비유의 중요성

• 중요한 발전은 종종 유추에서 시작
• 잘 이해하지 못하는 주제를, 더 잘 아는 비슷한 대상과 비교하면 더 잘 이해할 수 있음
• 이런 비유의 사용을 modeling이라고 함
• 비유는 대상을 한 덩어리의 개념으로 붙잡게 함. 성질, 관계, 추가 탐구 영역까지 떠올리게 함
• 비유는 탐구 방향 제시. 잘못 확장되면 오도 가능함
• 좋은 비유는 단순함. 다른 관련 비유와도 잘 연결됨. 관찰된 현상과 실험 결과를 넓게 설명해야 함
• 소프트웨어 개발도 마찬가지임. 어떤 비유를 쓰느냐에 따라 무엇을 보고, 어떤 문제를 묻고, 어떤 해법을 떠올리는지가 달라짐
• “틀린 비유에서 맞는 비유로”의 단번 전환과는 다름. 덜 좋은 비유에서 더 좋은 비유로 이동됨
• 예전 비유도 더 좁은 맥락에서는 여전히 유용할 수 있음
• 소프트웨어 개발은 아직 비교적 젊은 분야임. 표준 비유가 완전히 정착되지 않음. 서로 보완되거나 충돌하는 여러 비유가 함께 존재

2.2 소프트웨어 비유 사용법

• 소프트웨어 비유는 지도보다 탐조등에 가까움. 답을 직접 주지 않고, 어디를 어떻게 봐야 할지를 비춰 줌
• 비유는 알고리즘보다 발견적 방법에 가까움
  • 알고리즘: 정해진 작업을 수행하는 명확한 절차
  • 발견적 방법: 답을 직접 주기보다, 답을 찾는 방향 제시
• 둘의 차이는 해답과의 거리
  • 알고리즘: 지시를 직접 줌
  • 발견적 방법: 지시를 스스로 발견하도록 도움
• 프로그래밍은 아직 모든 문제를 일반 절차로 풀 수 있는 단계가 아님. 각 프로그램은 개념적으로 고유함. 많은 오류도 개념화 단계에서 생김
• 그래서 구체적 해법만큼 문제에 접근하는 관점 자체도 중요함
• 비유는 코드 한 줄의 옳고 그름을 판정하는 규칙이 아님. 개발 과정 전체를 이해하고, 더 나은 방식으로 생각하게 만드는 사고 프레임에 가까움
• 이런 비유를 잘 활용할수록 프로그래밍을 더 잘 이해하게 됨. 더 나은 코드를 더 빠르게 만들 수 있음

2.3 일반적인 소프트웨어 비유

글쓰기 비유: Writing Code

• 가장 원시적인 비유는 “코드를 쓴다”는 표현 자체임. 프로그램 개발을 편지처럼 처음부터 끝까지 써 내려가는 일로 보게 됨
• 계획 없이 쓰면서 생각을 정리해도 된다는 인상 제공. “가독성”, “문체”, “읽기 좋은 프로그램” 같은 표현도 여기서 나옴
• 작은 개인 작업에는 어느 정도 맞음. 하지만 실제 소프트웨어는 협업, 변경, 재사용이 중요하므로 편지 쓰기와는 다름
• Fred Brooks의 “하나 만들고 하나 버려라” 같은 사고도 이 비유와 연결됨. 대형 소프트웨어에서는 이런 시행착오 비용이 너무 큼
• 핵심 한계는 개발을 너무 단순하고 경직된 과정으로 보게 만든다는 점임

농사 비유: Growing a System

• 소프트웨어를 “자라게 한다”는 비유. 설계 조금, 코딩 조금, 테스트 조금을 반복하며 시스템을 조금씩 키운다는 발상
• 장점은 한 번에 큰 덩어리를 만들기보다 작은 단위로 진전시키는 태도 강조
• 하지만 농사 비유 자체는 약함. 소프트웨어 개발은 자연과 운에 맡기는 일이 아님
• 끝까지 밀면 “설계를 비옥하게 한다”, “코드 수확량을 높인다” 같은 부적절한 확장 발생
• 점진적으로 만든다는 기술은 좋음. 하지만 농사 비유는 통제 가능성, 설계성, 공학적 판단을 충분히 담지 못함

점진적 축적 비유: Software Accretion

• 농사보다 더 나은 비유는 축적(accretion). 조개가 진주를 만들 때 작은 층을 조금씩 덧입히는 방식에 가까움
• 먼저 “돌아가는 가장 단순한 골격” 구성. 입력과 출력이 임시여도 되고, 핵심은 시스템의 뼈대가 서 있는 상태
• 더미 클래스를 실제 클래스로 바꾸고, 가짜 입력과 출력을 실제 것으로 조금씩 교체
• 이렇게 하면 매 단계마다 동작하는 시스템을 유지한 채 확장 가능
• 강점은 “조금씩 덧붙인다”는 점을 설명하면서도, 결과가 자연 발생이 아니라 의도적 구축이라는 점을 놓치지 않는 데 있음

건축 비유: Building Software

• 가장 강하게 지지되는 비유는 건축. 소프트웨어 개발을 계획, 준비, 시공, 점검이 있는 공사로 보게 함
• 맥주 캔 10개로 쌓는 작은 탑과 그보다 100배 큰 구조물은 같은 방식의 단순 확대가 아님. 전혀 다른 수준의 계획과 공법 필요
• 개집은 오후 안에 만들 수 있고, 문을 빼먹어도 다시 고치면 됨. 작은 프로그램도 설계가 틀리면 다시 짜거나 리팩터링하기 비교적 쉬움
• 집을 짓는 경우에는 문제 정의, 아키텍처, 상세 설계, 구현, 최적화, 리뷰와 검사에 해당하는 단계가 차례로 필요
• 집에서 벽을 6인치 옮기는 비용이 사람 시간 때문인 것처럼, 소프트웨어에서 보고서 형식을 바꾸는 일도 인건비 때문에 비쌈
• 세탁기나 냉장고를 직접 만들지 않고 사서 쓰듯이, 소프트웨어도 공통 기능과 라이브러리는 재사용하는 편이 일반적으로 나음
• 반대로 고급 주택의 맞춤 설비처럼, 고급 소프트웨어에서는 성능과 일관성을 위해 자체 클래스나 함수 라이브러리를 만들 수도 있음
• 큰 건축물일수록 안전 여유, 정교한 문서, 타이밍 관리가 필요함. 대규모 소프트웨어도 비슷함
• 핵심은 프로젝트 규모와 위험이 커질수록 준비와 통제가 더 중요해진다는 점임

지적 도구 상자 비유: The Intellectual Toolbox

• 개발 기법 자체를 도구 상자에 비유
• 좋은 장인은 도구 하나만 믿지 않음. 작업에 맞는 도구를 알고 적절히 고름
• 프로그래머도 여러 기법, 요령, 설계 원칙, 방법론을 머릿속 도구 상자처럼 축적해야 함
• 특정 방법론에 100% 몰입하면 모든 문제를 그 틀로만 해석하게 되는 위험 발생
• 중요한 것은 “정답 방법론”이 아니라, 현재 문제에 맞는 도구 선택과 조합 능력임

비유의 조합

• 비유들은 서로 배타적이지 않음
• 점진적 축적 비유와 건축 비유를 함께 써도 되고, 필요하면 다른 비유와도 섞어 쓸 수 있음
• 자신의 사고를 넓히고 팀의 의사소통을 돕는 방향으로 활용하는 것이 핵심임

참고 자료

• Thomas S. Kuhn, The Structure of Scientific Revolutions

  과학 이론이 등장하고, 발전하고, 다른 이론으로 대체되는 과정을 다룬 책이다. 비유, 모델, 패러다임이 어떻게 사고방식을 바꾸는지 이해하는 데 도움이 된다고 소개된다.

• Robert W. Floyd, “The Paradigms of Programming”

  프로그래밍에서 모델과 패러다임이 어떤 역할을 하는지 다룬 글이다. 책에서는 Kuhn의 관점을 소프트웨어 개발에 연결해 생각해 볼 자료로 추천한다.

요점 정리

• 비유는 알고리즘이 아니라 발견적 방법(heuristic)이다. 그래서 다소 느슨할 수 있다.
• 비유는 소프트웨어 개발 과정을, 이미 알고 있는 다른 활동과 연결해 이해하도록 돕는다.
• 어떤 비유는 다른 비유보다 더 낫다.
• 소프트웨어 구현을 건축 시공과 비슷하게 보는 관점은, 신중한 사전 준비가 필요하다는 점을 보여 주고 큰 프로젝트와 작은 프로젝트의 차이도 드러낸다.
• 소프트웨어 개발 실천법을 지적 도구 상자의 도구로 보는 관점은, 모든 프로그래머가 여러 도구를 갖고 있으며 어떤 하나의 도구도 모든 문제에 맞지 않는다는 점을 보여 준다. 각 문제에 맞는 도구를 고르는 일은 효과적인 프로그래머가 되기 위한 핵심이다.
• 비유들은 서로 배타적이지 않다. 자신에게 가장 잘 맞는 비유의 조합을 사용하라.