[코드 컴플리트 2] Ch2. Metaphors for a Richer Understanding of Software Development

Park Yeongseo·2025년 1월 6일

Code Complete 2

목록 보기

2/2

컴퓨터 사이언스에서는 '바이러스', '트로이의 목마', '버그' 등의 다양한 비유를 사용한다. 이 비유들은 구체적인 소프트웨어적 현상을 설명하기 위해 쓰이며, 이러한 비유들을 잘 사용하면 소프트웨어 개발 프로세스를 더욱 잘 이해할 수 있게 된다.

2.1. The Importance of Metaphors

과학에서는 잘 모르는 주제를 설명하기 위해 더 잘 이해하는 유사한 주제의 비교를 이용하곤 한다. 이러한 비유를 모델링(modeling)이라고 한다.

모델링 사례
+ 벤젠의 구조 : 꼬리를 물고 있는 뱀
+ 기체 분자 : 당구공
+ 빛 : 소리

모델링을 이용하면, 비유 대상이 가지고 있는 속성과 관계, 혹은 필요한 추가 정보들을 이용해, 설명 대상을 보다 생생히 그려내고, 그 전체 개념의 윤곽을 잡을 수 있다.

단, 비유에 불과하다는 사실을 잊고 둘을 과도하게 동일시할 때에도 문제는 발생할 수 있다.

예) 빛과 소리의 비유: 소리가 매질을 필요로 하는 것처럼 빛의 매질(에테르)도 필요할 것이다.

어떤 비유는 다른 비유들보다 낫다. 좋은 비유는 간단하고, 다른 비유들과도 잘 연관되어 있고, 실험적 증거나, 관찰된 다른 현상들도 대부분 잘 설명한다. 좋은 비유는 그렇지 않은 비유를 사용했을 때에는 찾아낼 수 없었던 문제들을 해결할 수 있도록 하는, 좀 더 나은 관점을 제공해주기도 한다.

소프트웨어 개발에서도 마찬가지로, 비유를 이용하면 많은 이슈들을 더 잘 이해할 수 있다. 다만 소프트웨어 개발 분야는 다른 과학들에 비해서는 아직 그렇게 성숙하지 못해, 상충하는 비유들이 여럿 섞여 있기도 하다. 어떤 비유는 더 낫고, 다른 것들은 그렇지 않다. 비유를 얼마나 잘 이해하는지가 소프트웨어 개발을 얼마나 잘 이해하는지를 결정한다.

2.2. How to Use Software Metaphors

소프트웨어에서의 비유는 로드맵보다는 서치라이트에 가깝다. 이는 어디에서 답을 찾을 수 있는지 알려주는 것이라기 보다는, 어떻게 이를 찾을 수 있을지를 알려주는 것에 가깝고, 알고리즘이라기보다는 휴리스틱에 가깝다.

알고리즘: 특정 작업을 수행하기 위해 필요한 잘-정의된 명령들의 집합. 예측 가능하고, 결정론적이며, 우연에 따라 변하지 않음.
휴리스틱: 답을 찾는 데 도움을 주는 테크닉. "무엇"을 찾아야 하는지보다, "어떻게" 찾아야하는지를 알려줌. 예측 가능성은 조금 떨어지고, 확률적으로 결과가 바뀔 수도 있음.

물론 프로그래밍에서 발생할 수 있는 문제들을 어떻게 풀 수 있을지 정확히 알려주는 것이 가능하다면 좋겠지만, 그렇게 하기는 어렵다. 모든 프로그램에는 고유의 개념들이 있고, 그런 모든 프로그램들에 일괄적으로 적용될 수 있는 솔루션을 만들 수는 없다. 때문에 그런 문제들에 '일반적으로' 어떻게 접근할 수 있는지를 아는 것이 중요하다.

소프트웨어 비유를 통해, 프로그래밍 문제와 프로세스에 대한 통찰을 얻고, 자신의 프로그래밍 활동을 다시 돌아보고 더 나은 방법은 없을지를 찾아보자. 소프트웨어 비유를 통해 개발 프로세스를 이해하는 사람은 그렇지 않은 사람들보다 소프트웨어 개발을 더 잘 이해하고, 더 나은 코드를 더 잘 이해하는 사람이 될 것이다.

2.3. Common Software Metaphors

Software Penmanship: Writing Code

코드 작성을 손으로 편지를 쓰는 작업에 비유해보자. 한 사람이 형식적인 계획 없이 쓰고 싶은 것들을 쓴다.

개인 작업이나 소규모 프로젝트들에서는 적절할 수 있다.
하지만 그렇지 않은 경우, 이는 소프트웨어 개발을 제대로, 적절히 설명하지 못한다.
편지를 쓰는 것은 개인의 활동인 반면, 소프트웨어 프로젝트에는 서로 다른 역할을 가지고 있는 여러 사람들이 참여한다.
편지를 다 쓰고 보내면 더 이상 수정할 수 없지만, 소프트웨어의 경우에는 수정을 하기 쉽고, 완벽하게 완성을 하는 일도 거의 없다.

Software Farming: Growing a System

어떤 개발자들은 소프트웨어를 만드는 일을 씨를 뿌리고 작물을 키우는 일에 비유하기도 한다. 일부를 설계하고 코딩하고 테스트한 후, 전체 시스템에 조금씩 추가해 나가는 방식이다.

조금씩 점진적으로 개선해나간다는 컨셉은 좋지만, 좋은 비유는 아니다.
소프트웨어 개발에 대한 직접적인 제어 개념이 없다. 씨앗을 뿌리고 작물이 제대로 잘 자라기를 기도할 뿐이다.

Software Oyster Farming: System Accretion

소프트웨어 개발을 굴 양식에 비유해보자. 위 농사의 비유와 마찬가지로 개발을 진행하면서 점진적으로 사이즈를 키우는 일이다. 굴에다 탄산 칼슘을 조금씩 주입하면서 진주를 만드는 것을 생각해보자.

소프트웨어 시스템에 조금씩 추가해나가는 방법.
점진적 설계, 구축 및 테스트는 가장 강력한 소프트웨어 개발 개념 중 하나.
실행될 시스템의 간단한 초기 버전을 만든다. 이 버전은 실제 입력도, 데이터에 대한 실질적인 조작을 수행할 필요도, 실제 출력을 만들 필요도 없다. 개발할 실제 시스템을 지탱할 수 있을 만한 뼈대, 각 기능의 더미 클래스를 만든다.
뼈대를 만들고 나면, 각 더미 클래스를 실제 클래스로 만든다. 실제로 입력을 받아 출력을 하게 만든다.

Software Construction: Building Software

소프트웨어를 '건설'의 대상으로 생각하는 것은, 소프트웨어를 '쓰거나', '키우는' 대상으로 보는 것보다 더 유용하며, 점진적 개발 개념과 함께 좀 더 세부적인 가이드도 제공한다.소프트웨어를 건설한다는 것은 소프트웨어의 종류와 규모에 따라 계획, 준비, 수행에 여러 단계를 둔다는 것을 의미한다.

같은 종류라도 그 규모에 따라 다른 플랜과 테크닉이 필요하다.
+ 예를 들어 작은 개집을 만든다고 생각해보자. 나무 판자와 못들을 사면 금방 만들 수 있을 것이다. 하지만 같은 개집의 크기를 100배로 키운다면 어떨까? 단순히 더 많은 나무 판자와 못들을 산다고 해서 같은 방법으로 100배 큰 개집을 만들 수는 없다.
+ 작은 프로젝트에서는 설계 미스가 있어도 금방 고칠 수 있다. 하지만 프로젝트의 규모가 커지면 잘못된 설계로 인한 비용은 훨씬 더 커진다.
건설은 여러 단계를 거친다. 소프트웨어 구축도 마찬가지다.
+ 어떤 집을 만들지 정하기 : 문제 정의
+ 건축가와 함께 전체적인 설계 : 소프트웨어 아키텍처 설계
+ 구체적인 청사진 그리고 토건업자 고용하기 : 세부 소프트웨어 설계
+ 부지 구하기, 기반 다지기, 골조, 벽, 지붕, 배관 배선 작업 : 소프트웨어 구현
+ 정원사, 페인트공, 인테리어 업자의 작업 : 소프트웨어 최적화
+ 각 단계에서 작업이 제대로 진행되고 있는지 관리 : 소프트웨어 리뷰와 인스펙션
인건비가 많이 든다.
+ 실제로 집을 지을 때, 원자재도 물론 비싸기는 하지만, 가장 돈이 많이 드는 것은 인건비다.
+ 소프트웨어의 경우, 원자재 비용은 별로 들지 않고, 임금이 많이 든다.
이미 살 수 있는 것들을 굳이 다 만들 필요는 없다.
+ 살 수 있는 가전 제품들은 굳이 만들기보다는 사서 쓰면 된다.
+ 소프트웨어 시스템에서도 마찬가지로, 굳이 ready-made한 자원들이 있는데 직접 만들어 쓰지는 않는다.
+ 물론 커스텀이 필요한 경우에는 그렇게 할 수도 있다.
계획에는 적당한 수준이 필요하다.
+ 잘못된 순서로 만들면, 만들기도, 테스트하기도, 문제점을 찾기도 어렵다.
+ 그렇다고 해서 너무 완벽한 계획을 만드는 것은 시간도 많이 들고 복잡해, 혼란스러워지기 쉽다.
+ "제대로 설계"된 프로젝트는 나중에 세부 사항을 수정하기 쉬운 프로젝트다.
대상에 따라 다른 개발 방법이 필요하다.
구조를 변경하는 일은 단순히 주변적인 것들을 수정하는 것보다 어렵다.
규모가 큰 프로젝트들에 대한 인사이트
+ 안전성이 가장 중요하다. 건물이 무너지는 것보다는 10% 정도 비싸더라도 더 좋은 자재를 쓰는 것이 낫다.
+ 소프트웨어의 경우도 마찬가지로, 복잡하고 큰 프로젝트의 경우 최대한 철저한 사전 준비가 필요하다.