🤔 Chapter 2: 실용주의 접근법

🍭 Topic 8. 좋은 설계의 핵심

Tip 14. 좋은 설계는 나쁜 설계보다 바꾸기 쉽다.

어떤 게 잘 설계되었다는 건 그 물건이 사용하는 사람에게 적응하여 맞춰진다는 것이다. 이 말을 코드에 적용해 보면, 잘 설계된 코드는 바뀜으로써 사용하는 사람에게 맞춰저야 한다. 그래서 우리는 ETC 원칙을 따른다. 바꾸기 더 쉽게(Easier to Change, ETC). 이게 전부다.

우리가 아는 한 세상의 모든 설계 원칙은 ETC의 특수한 경우다.

왜 결합도를 줄이면 좋은가? 관심사를 분리함으로써 각각이 더 바꾸기 쉬워지기 때문이다. ETC.
왜 단일 책임 원칙이 유용한가? 요구 사항이 바뀌더라도 모듈 하나만 바꿔서 반영할 수 있기 때문이다. ETC.
왜 이름 짓기가 중요한가? 이름이 좋으면 코드가 읽기 쉬워지고, 코드를 바꾸려면 코드를 읽어야 하기 때문이다. ETC!

🥕 ETC는 규칙이 아니라 가치

가치는 여러분이 결정을 내리게 도움을 주는 것이다. 소프트웨어라는 틀에서 생각해 보면 ETC는 선택의 갈림길에서 도움을 주는 안내자다.

ETC에는 암묵적인 전제가 있다. 바로 여러 길 중 어떤 길이 미래의 변경을 쉽게 만드는지 알 수 있다는 것이다. 상식이 대개 통할 테고, 여러분의 지식을 바탕으로 추측할 수 있을 것이다. 하지만 가끔은 아무 실마리가 없을 수도 있다. 그래도 괜찮다. 이런 경우 다음 두 가지를 해 보라.

첫 번째로, 앞으로 어떤 모습으로 바뀔지 잘 모르겠을 때 언제건 궁극의 "바꾸기 쉽게"라는 길을 선택한다. 바로 여러분이 작성하는 코드를 교체하기 쉽게 만들도록 노력하는 것이다. 교체 가능하게 작성하라는 말은 코드의 결합도를 낮추고 응집도를 높이라는 이야기일 뿐이다.

두 번째는 이런 경우를 여러분의 직관을 발전시키는 기회로 삼으라는 것이다.

🍭 Topic 9. DRY: 중복의 해악

지식은 변화한다. 때로는 급격하게 변화한다. 프로그래머는 늘 유지 보수 모드에 있다. 우리의 이해는 날마다 바뀐다. 우리가 프로젝트에 열중해 있는 동안에도 새로운 요구 사항이 도착하고 기존 요구 사항은 진화한다.

소프트웨어를 신뢰성 높게 개발하는 유일한 길, 개발을 이해하고 유지 보수하기 쉽게 만드는 유일한 길은 우리가 DRY라 부르는 원칙을 따르는 것이라 생각한다. DRY 원칙은 다음과 같다.
모든 지식은 시스템 내에서 단 한 번만, 애매하지 않고, 권위 있게 표현되어야 한다.

Tip 15. DRY: 반복하지 말라(Don't Repeat Yourself)

DRY를 따르지 않으면 똑같은 것이 두 군데 이상에 표현될 것이다. 하나를 바꾸면 나머지도 바꿔야 함을 기억해야 한다. 우리는 DRY가 "실용주의 프로그래머"의 도구 상자에서 가장 중요한 도구 중 하나라고 생각한다.

🥕 DRY는 코드 밖에서도

많은 사람들이 DRY가 코드에만 해당한다고 받아들였다. "소스 코드를 복사-붙여넣기 하지 말라."로 이해한 것이다.

그것도 DRY의 일부인 것은 맞다. 하지만 아주 작고 자명한 부분일 뿐이다. DRY는 지식의 중복, 의도의 중복에 대한 것이다. 똑같은 개념을 다른 곳 두 군데에서 표현하면 안 된다는 것이다. 경우에 따라서 중복 표현이 두 가지 완전히 다른 방식으로 이루어질 수도 있다.

🥕 모든 코드 중복이 지식의 중복은 아니다

def validate_age(value):
    validate_type(value, :integer)
    validate_min_integer(value, 1)

def validate_quantity(value):
    validate_type(value, :integer)
    validate_min_integer(value, 1)

코드는 동일하지만 두 함수가 표현하는 지식은 다르다. 두 함수는 각각 서로 다른 것을 검증하고 있지만, 우연히 규칙이 같은 것뿐이다. 이것은 우연이지 중복이 아니다.

🥕 문서화 중복

왜인지는 모르겠지만 모든 함수에 주석을 달아야 한다는 미신이 생겨났다. 한 번은 주석으로, 또 한 번은 코드로 함수의 의도는 두 번 표현된다.
우리는 수정사항이 생기면 두 군데를 함꼐 고쳐야 한다. 시간이 지남에 따라 주석과 코드의 내용이 서로 어긋나게 될 거라고 거의 확실히 장담할 수 있다.

우리가 보기에는 이름이나 코드 구조의 부실함을 메꾸는 역할을 할 뿐이다. 함수 이름이 함수가 하는 일을 알려준다. 더 자세한 것을 알고 싶다면 소스 코드를 보면 된다. 이것이 DRY다!

🥕 표현상의 중복

여러분의 코드는 바깥세상과 연결된다. 다른 라이브러리와는 API로, 다른 서비스와는 원결 호출이나 외부 저장소의 데이터 등으로 연결된다. 그리고 이렇게 연결될 때마다 일종의 DRY 위반을 하게 된다. 외부에 무언가에 표현된 지식인 API나 스키마, 에러 코드의 의미 등을 여러분의 코드도 알아야만 하는 것이다. 여기서는 연결을 표현하는 지식을 여러분의 코드와 외부의 존재 양쪽이 모두 알아야 하기 때문에 중복이 생긴다. 한쪽에서만 바꾸면 다른 쪽은 망가질 것이다.

이런 중복은 아예 피할 수는 없지만 다소 완화할 수는 있다.

내부 API에서 생기는 중복

언어나 기술에 중립적인 형식으로 내부 API를 정의할 수 있는 도구를 찾아보라. 이런 도구는 일반적으로 문서와 목 API, 기능 테스트를 생성해 주고, API 클라이언트도 여러 가지 언어로 생성해 준다. 이상적으로는 이 도구를 이용하여 모든 API 정의를 중앙 저장소에 넣어 두고 여러 팀이 공유할 수 있게 하면 좋다.

외부 API에서 생기는 중복

공개 API를 OpenAPI 같은 형식으로 엄밀하게 문서화하는 경우가 점점 많아지고 있다. 이런 형식의 API 명세를 여러분의 API 도구로 불러와서 사용하면 더욱 신뢰성 있게 해당 서비스를 연동할 수 있다.

데이터 저장소와의 중복

많은 데이터 저장소가 데이터 스키마 분석 기능을 제공한다. 이런 기능을 이용하면 데이터 저장소와 코드 간의 중복을 많이 제거할 수 있다.

🥕 개발자 간의 중복

아마 발견하거나 없애기 가장 어려운 유형의 중복은 같은 프로젝트에서 일하는 개발자들 사이에서 발생할 것이다. 똑같은 일을 하는 코드가 우연히 중복으로 추가될 수 있고, 이런 중복은 수년 동안 발견되지 않을 수 있다.
개발자들의 산출물 간의 중복에 대처하려면 크게는 의사소통을 잘하는 튼튼하고 유대가 돈독한 팀을 만들어야 한다. 우리가 느끼기에 최선책은 개발자 간의 적극적이고 빈번한 소통을 장려하는 것이다.
일일 스크럼 스탠드업 미팅을 운영해 볼 수 있다. 슬랙 채널같이 공통의 문제를 다루기 위한 공간을 만들라. 이런 소프트웨어를 사용하면 모든 대화 기록을 보존할 수 있고, 방해를 최소화하면서 의사소통이 가능하다.

팀원 한 사람을 프로젝트 사서로 임명하라. 프로젝트 사서의 역할은 지식 교환을 돕는 것이다. 그리고 일상적으로든 코드 리뷰를 통해서든 다른 사람의 소스 코드와 문서를 반드시 읽어라. 다른 사람의 것을 기웃거리는 게 아니고, 거기서 배우는 것이다. 그리고 기억하라. 접근은 상호적이다. 다른 사람이 여러분의 코드를 들여다보고 건드린다고 해서 기분 나빠하지 말 일이다.

Tip 14. 재사용하기 쉽게 만들어라.

여러분은 뭔가를 직접 만드는 것보다 기존의 것을 찾아내고 재사용하기 쉬운 환경을 조성해야 한다. 사람들은 쉽지 않으면 하지 않을 것이다. 그리고 재사용에 실패한다면 지식 중복의 위험을 감수해야 한다.

🍭 Topic 10. 직교성

직교성(orthogonality)은 설계와 빌드, 테스트, 확장이 쉬운 시스템을 만드는 데에 있어 매우 중요한 개념이다.

🥕 직교성이란

컴퓨터 과학에서 이 용어는 일종의 독립성이나, 결합도 줄이기를 의미한다. 하나가 바뀌어도 나머지에 어떤 영향도 주지 않으면 서로 직교한다고 할 수 있다. 잘 설계된 시스템에서는 데이터베이스 코드가 사용자 인터페이스와 서로 직교할 것이다.

🥕 직교성의 장점

비직교적인 시스템은 본질적으로 변경과 조정이 더 복잡하다. 시스템의 컴포넌트들이 고도로 상호 의존적인 경우 특정 부분만 국지적으로 수정하는 방법이란 없다.

Tip 17. 관련 없는 것들 간에 서로 영향이 없도록 하라.

우리가 설계하고 싶은 것은 자족적인 컴포넌트, 즉 단일하고 잘 정의된 목적을 가진 독립적인 컴포넌트다. 컴포넌트들이 각기 격리되어 있으면 어느 하나를 바꿀 때 나머지 것들을 걱정하지 않아도 된다. 해당 컴포넌트의 외부 인터페이스를 바꾸지 않는 한 전체 시스템으로 퍼져 나가는 문제를 일으키지는 않으리라고 확신할 수 있다.

직교적인 시스템을 작성하면 두 가지 큰 장점이 있다. 바로 생산성 향상과 리스크 감소다.

생상성 향상

• 변화를 국소화해서 개발 시간과 테스트 시간이 줄어든다. 상대적으로 작고, 자족적인 컴포넌트들을 작성하는 것이 하나의 커다란 코드 덩어리를 만드는 것보다 더 쉽다. 간단한 컴포넌트는 설계하고, 코딩하고, 테스트하고, 그러고는 잊어버릴 수 있다. 새로운 코드를 추가할 때마다 기존의 코드를 계속 바꾸지 않아도 된다.
• 직교적인 접근법은 재사용도 촉진된다. 컴포넌트에 명확하고 잘 정의된 책임이 할당되어 있으면 애초의 구현자가 예상하지 못한 방식으로 새로운 컴포넌트와 결합할 수 있다. 시스템이 더 느슨하게 결합되어 있을수록 재조합하고 개량하기 쉽다.
• 직교적인 컴포넌트들을 결합하는 경우 얻을 수 있는 꽤 미묘한 생산성 향상 요소가 있다. 컴포넌트 하나가 M가지 서로 다른 일을 하고 또 다른 컴포넌트 하나가 N가지 일을 한다고 가정하자. 만약 두 컴포너트가 직교적이라면 결합했을 때 결과물을 M x N가지 일을 한다.

리스크 감소

직교적인 접근법은 모든 개발 작업에 존재할 수밖에 없는 위험의 크기를 감소시켜 준다.

• 감염된 코드가 격리되어 있다.
• 시스템이 잘 깨지지 않는다. 어떤 부분을 골라서 약간 바꾸고 고쳤을 때 혹시 문제가 생기더라도 문제점은 그 부분으로 한정될 것이다.
• 직교적인 시스템은 그 안의 컴포넌트들에 대해 테스트를 설계하고 실행하기 훨씬 쉽기 때문에, 아무래도 테스트를 더 많이 하게 된다.
• 특정 업체나 제품, 플랫폼에 덜 종속될 것이다.

🥕 설계

시스템은 서로 협력하는 모듈의 집합으로 구성되어야 하고, 각 모듈은 다른 부분과 독립적인 기능을 구현해야 한다. 계층 구조는 직교적 시스템을 설계하는 강력한 방법이다. 각 계층은 자기 바로 밑에 있는 계층이 제공하는 추상화만을 사용하기 때문에, 다른 코드에 영향을 끼치지 않으면서 기반 구현들을 변경할 수 있게 되어 유연성이 높아진다. 계층 구조는 또한 모듈 간에 의존성이 폭증할 위험을 줄인다.

설계가 직교적인지 확인하는 손쉬운 방법이 있다. 컴포넌트들을 나누었을 때 다음과 같이 스스로에게 물어보라. "특정 기능에 대한 요구 사항을 대폭 변경하는 경우 몇 개의 모듈이 영향을 받는가?" 직교적인 시스템에서는 답이 "하나"여야 한다.

여러분이 제어할 수 없고, 언제 어떤 이유로든 바뀔 수 있다. 자신의 힘으로 제어할 수 없는 속성에 의존하지 말라.

🥕 툴킷과 라이브러리

외부에서 만든 툴킷이나 라이브러리를 도입할 때 시스템의 직교성을 해치지 않는지 주의 깊게 살펴보기 바란다. 기술을 현명하게 선택하라.

툴킷이나 라이브러리를 도입할 때는 심지어 같은 팀의 다른 멤버가 작성한 것이더라도 이것이 여러분의 코드에 수용해서는 안 될 변화를 강요하지 않는지 검토해 보라.

🥕 코딩

코드를 작성할 때마다 여러분은 애플리케이션의 직교성을 떨어트릴 위험을 감수하는 셈이다. 현재 코딩하는 부분뿐만 아니라 애플리케이션의 큰 맥락을 끊임없이 살피지 않으면 의도치 않게 다른 모듈에 있는 기능을 또 추가하거나 동일한 지식을 두 번 표현할 수 있다.

직교성을 유지하기 위해 사용할 수 있는 몇 가지 기법이 있다.

코드의 결합도를 줄여라

부끄럼쟁이(shy) 코드를 작성하라. 즉, 불필요한 것은 다른 모듈에 보여 주지 않으며, 다른 모듈의 구현에 의존하지 않는 코드를 작성하라. 그리고 데메테르 법칙을 따르려 노력해 보자. 객체의 상태를 바꿀 필요가 있다면 여러분을 위해 객체가 직접 상태를 바꾸게 하라. 이렇게 한다면 코드는 다른 코드 구현으로부터 분리된 채로 남아있을 것이며, 계속하여 직교성을 유지할 확률이 높아진다.

전역 데이터를 피하라

코드가 전역 데이터를 참조할 때마다 코드는 해당 데이터를 공유하는 다른 컴포넌트와 묶이게 된다.

유사한 함수를 피하라

종종 유사해 보이는 함수를 여럿 구현해야 할 때가 있다. 아마도 시작과 끝에서는 동일한 코드를 사용하지만, 중간의 알고리즘이 다를 것이다. 중복 코드는 구조에 문제가 있다는 징후다.

자신이 작성하는 코드를 항상 비판적으로 바라보는 습관을 길러라. 기회가 있을 때마다 코드의 구조와 직교성을 개선하기 위해 노력하라. 이런 과정을 리팩터링이라 부른다.

🥕 테스트

직교적으로 설계하고 구현한 시스템은 테스트하기 더 쉽다. 시스템 컴포넌트 간의 상호 작용이 형식을 잘 갖추고 있고 제한적이기 때문에 시스템 테스트 중 많은 부분을 개별 모듈 수준에서 수행할 수 있다. 모듈 수준의 테스트나 단위 테스트가 통합 테스트보다 테스트 케이스를 만들고 수행하기 훨씬 쉬우므로 이는 좋은 소식이라 할 수 있다.

단위 테스트를 작성하는 행위 자체가 직교성을 테스트해 볼 수 있는 기회다. 단위 테스트를 빌드하고 실행하기 위해 어떤 작업이 필요한가? 나머지 시스템 중 상당 부분을 불러와야 하지는 않는가? 만약 그렇다면 모듈과 나머지 시스템 사이의 결합도를 충분히 줄이지 못했다는 뜻이다.

만약 버전 관리 시스템을 사용한다면, 테스트를 마친 뒤 코드를 병합할 때 버그 수정에 대한 태그를 붙여라. 이렇게 하면 버그 수정마다 수정한 소스 파일 개수를 수집하여 그 경향을 분석한 월 단위 리포트를 만들 수 있을 것이다.

🥕 문서화

놀랍게도 직교성은 문서에도 적용할 수 있다. 내용과 표현이라는 두 개의 축이 있다. 정말 직교적인 문서라면 내용 변화 없이 모양새를 완전히 바꿀 수 있을 것이다. 워드 프로세서가 제공하는 스타일 시트와 매크로를 사용하면 쉽게 할 수 있다. 우리는 개인적으로 마크다운 같은 마크업 체계를 좋아한다. 내용을 쓸 때는 내용에만 집중하고, 예쁘게 꾸미는 것 같은 다른 변환 도구에 맡길 수 있다.

🥕 직교적으로 살아가기

직교성은 DRY 원칙과도 밀접한 관계가 있다. DRY 원칙은 시스템 내부의 중복을 최소화하고, 직교성은 시스템 컴포넌트 간의 상호 의존도를 줄인다. DRY 원칙으로 무장하고 직교성 원칙을 충실히 적용한다면 개발하고 있는 시스템이 더 유연하고 이해하기 쉬워질 것이다. 디버깅, 테스트, 유지 보수 또한 쉬워질 것이다.

🍭 Topic 11. 가역성

🥕 가역성

여기서 추천하는 방법들, 특히 DRY 원칙, 결합도 줄이기, 외부 설정 사용하기를 따른다면 중요하면서도 되돌릴 수 없는 결정의 수를 가능한 한 줄일 수 있을 것이다. 되돌릴 수 없는 결정을 줄여야 하는 까닭은 우리가 프로젝트 초기에 늘 최선의 결정을 내리지 못하기 때문이다. 우리가 소프트웨어를 개발하는 속도는 요구 사항, 사용자, 하드웨어의 변화를 앞지를 수 없다.

결정이 바뀌지 않을 것이라 가정하고서 발생하지도 모를 우연한 사건에 대비하지 않는 데에서 실수가 나온다. 결정이 돌에 새겨진 것이 아니라 바닷가의 모래 위에 쓰인 글씨라 생각하라. 언제든지 큰 파도가 글씨를 지워버릴 수 있다.

Tip 18. 최종 결정이란 없다.

🥕 유연한 아키텍처

여러분이 할 수 있는 것은 바꾸기 쉽게 만드는 것이다. 외부의 API를 여러분이 만든 추상화 계층 뒤로 숨겨라. 여러분의 코드를 여러 컴포넌트로 쪼개라. 결국에는 하나의 거대한 서버에 배포하게 되더라도, 이 방식의 거대한 단일 모듈 애플리케이션을 가져다 쪼개는 것보다 훨씬 더 쉽다.

Tip 19. 유행을 좇지 말라.

누구도 어떤 미래가 펼쳐질지 알 수 없으며, 우리 분야는 특히 더 그렇다. 여러분의 코드가 로큰롤을 할 수 있게 하라. 락을 할 수도 있고, 필요한 롤을 할 수 있게 하는 것이다.

🍭 Topic 12. 예광탄

사용자들이 이전에 그런 시스템을 한 번도 본 적이 없기 때문에 요구 사항은 막연할지도 모른다. 익숙하지 않은 알고리즘, 기술, 언어, 라이브러리를 사용하기도 하므로, 여러분의 수많은 미지의 것과 맞닥트리게 된다. 그리고 프로젝트는 완성하는 데 시간이 걸리기 때문에 프로젝트가 끝나기 전에 여러분의 작업을 둘러싼 환경이 변하리라는 것도 거의 장담할 수 있다.

이런 상황에서의 전형적인 반응은 시스템을 극도로 세세히 명세화하는 것이다. 모든 불확실한 점을 잡아매고, 환경 조건을 제약하고, 모든 요구 사하을 일일이 항목으로 만들어서 몇 상자나 되는 명세서를 만든다. 그리고 목표물의 위치를 추측해서 총을 쏜다. 상당한 양의 계산을 우선 하고 나서, 그다음엔 발싸하고, 맞기를 비는 것이다.

🥕 어둠 속에서 빛을 내는 코드

우리를 요구 사항으로부터 최종 시스템의 일부 측면까지 빨리, 눈에 보이게, 반복적으로 도달하게 해 줄 무언가를 찾아야 한다.
시스템을 정의하는 중요한 요구 사항을 찾아라. 의문이 드는 부분이나 가장 위험이 커 보이는 곳을 찾아라. 이런 부분의 코드를 가장 먼저 작성하도록 개발 우선순위를 정하라.

Tip 20. 목표물을 찾기 위해 예광탄을 써라.

예광탄 개발 방법은 "프로젝트는 결코 끝나지 않는다."는 견해와도 일맥상통한다. 변경 요청과 기능 추가 요청은 언제나 계속 들어오기 마련이다. 예광탄 개발 방법은 점진적인 접근 방법이다.

이와 대비되는 전형적인 방법은 일종의 거대 공학적 접근 방식이다. 코드는 모듈로 나뉘고, 각 모듈을 격리된 상태에서 작성된다. 모듈을 조립해서 시스템의 하위 부품들을 만들고, 하위 부품들을 다시 조립해서 언젠가 마침내 전체 애플리케이션이 완성된다. 이때가 되서야 전체 애플리케이션을 사용자에게 보여주거나 테스트할 수 있다.

예광탄 코드 접근 방버에는 여러 장점이 있다.

1. 사용자가 뭔가 작동하는 것을 일찍부터 보게 된다.
2. 개발자가 들어가서 일할 수 있는 구조를 얻는다.
3. 통합(integration) 작업을 수행할 기반이 생긴다.
4. 보여줄 것이 생긴다.
5. 진행 상황에 대해 더 정확하게 감을 잡을 수 있다.

🥕 예광탄이 언제나 목표물을 맞히는 것은 아니다

예광탄 코드 기법은 일이 어떻게 될지 100% 확신할 수 없는 상황에서 사용된다. 그러므로 처음 몇 번 시도 때 목표에 맞지 않더라도 놀랄 필요가 없다. 지금 있는 것을 목표물에 더 가까워지도록 바꿔라. 그리고 가벼운 개발 방법론을 선택했다는 사실에 감사하라. 코드의 크기가 작으면 관성 역시 약하므로 빠르고 쉽게 바꿀 수 있다. 빠르고 저렴하게 애플리케이션에 대해 반응을 모아서 새롭고 더 정확한 버전을 만들 수 있을 것이다. 그리고 애플리케이션의 모든 주요 요소가 예광탄 코드에도 들어 있기 때문에, 사용자는 지금 보고 있는 것이 단지 종이에 쓰인 명세가 아니라 현실에 기반을 두고 있다는 확신을 얻을 수 있다.

🍭 Topic 13. 프로토타입과 포스트잇

다양한 산업 분야에서 구체적인 아이디어를 실험해 보기 위해 프로토타입을 이용한다. 프로토타입은 실제 제품보다 훨씬 저렴하게 만들 수 있기 때문이다. 소프트웨어 프로토타입도 위험 요소를 분석하고 노출시킨 후, 이를 매우 저렴한 비용으로 바로잡을 기회를 얻는 것이다. 자동차와 마찬가지로 각 프로토타입을 만들 때마다 프로젝트의 특정 측면에 중점을 둘 수 있다.

프로토타입을 반드시 코드로 작성해야 한다고 생각하기 쉬운데 꼭 그럴 필요는 없다. 포스트잇은 작업 흐름이나 애플리케이션 로직과 같이 동적인 것을 프로토타이핑할 수 있는 훌륭한 도구다. 사용자 인터페이스 프로토타입은 화이트보드에 그림을 그려서 만들 수도 있고, 그림판 프로그램, 인터페이스 빌더 등을 이용해 기능은 구현하지 않고 만들어 볼 수도 있다.

프로토타입은 제한된 몇 가지 질문에 답하기 위한 것이므로 실제 제품보다 훨씬 적은 비용으로 빠르게 개발할 수 있다. 여러분에게 당장 중요하지 않는 세부 사항이라면 추후에 사용자에게 매우 중요해질지도 모르지만 일단 무시하면서 코딩할 수 있다. 하지만 세부 사항을 포기할 수 없는 환경에 처해 있다면 진짜로 프토토타입을 만들고 있는 게 맞는지 자문해 보라. 아마도 이런 경우에는 예광탄 방식의 개발이 더 적절할 것이다.

🥕 프로토타이핑 대상

프로토타이핑으로 조사할 대상은 무엇인가? 위험을 수반하는 모든 것이다. 이전에 해 본 적이 없는 것, 최종 시스템에 매우 중요한 것이 프로토타이핑 대상이다. 증명되지 않았거나, 실험적이거나, 의심이 가는 것, 마음이 편하지 않은 것 모두가 프로토타이핑의 대상이 될 수 있다.

• 아키텍처
• 기존 시스템에 추가할 새로운 기능
• 외부 데이터의 구조 혹은 내용
• 외부에서 가져온 도구나 컴포넌트
• 성능 문제
• 사용자 인터페이스 설계

프로토타이핑은 학슴 경험이다. 프로토타이핑의 가치는 생산한 코드에 있는 것이 아니라 이를 통해 배우는 교훈에 있다. 이것이 프로토타이핑의 전정한 핵심이다.

Tip 21. 프로토타이핑으로 학습하라.

🥕 프로토타입을 어떻게 사용할 것인가?

프로토타입을 만들 때 무시해도 좋은 세부 사항은 무엇인가?

• 정확성
  • 적절히 가짜 데이터를 사용할 수 있다.
• 완전성(completeness)
  • 프로토타입은 제한된 방식으로만 작동하기도 한다. 어쩌면 미리 선정한 입력 데이터 하나와 한 가지 메뉴 항목만 작동해도 될 것이다.
• 안정성
  • 오류 검사를 빼먹거나 아예 무시할 수도 있다.
• 스타일
  • 프로토타입 코드에는 주석이나 문서가 많지 않아야 한다. 다만, 프로토타입을 사용해 본 결과를 문서로 많이 작성할 수는 있다.

프로토타입은 세부 사항을 생략하고 시스템의 특정 측면에 초점을 맞추기 때문에 파이썬이나 루비 같은 고수준 스크립트 언어를 이용하여 구현할 수도 있다. 사용자 인터페이스 프로토타입을 만들 때는 외양과 상호 작용에만 집중할 수 있는 도구를 사용하라.

🥕 아키텍처 프로토타이핑

예광탄과는 달리 프로토타입 시스템의 모듈이 꼭 기능을 가져야 하는 것은 아니다. 사실 아키텍처를 프로토타이핑할 때는 코드를 작성하지 않고 화이트보드, 포스트잇, 인덱스카드 등을 사용해도 된다.
프로토타이핑의 목적은 전체적으로 시스템이 어떻게 동작할지에 대해 감을 잡는 것이다. 다시 말하지만, 세부 사항은 무시한다.

🥕 프로토타입 코드를 사용하지 않도록 하려면?

프로토타입을 코드로 만들 때는 시작하기 전에 항상 모든 사람에게 여러분이 폐기 처분할 코드를 작성하고 있다는 사실을 이해시켜야 한다. 프로토타입은 그것이 프로토타입임을 모르는 사람에게는 오해를 살 정도로 매력적일 수도 있기 때문이다. 그러므로 코드는 폐기할 것이고, 불완전하며, 완성할 수 없다는 사실을 분명히 주지시켜야 한다.

만약 여러분이 작업하는 환경이나 문화에서 프로토타입 코드의 목적이 잘못 해석될 가능성이 크다고 느낀다면 예광탄 접근 방식을 취하는 편이 나을 것이다. 프로토타입을 적절히 사용하면 많은 시간과 돈, 고통과 고생을 줄일 수 있다. 개발 주기 초기에 잠재적 문제 지점을 발견하고 고칠 수 있기 때문이다. 실수를 적은 비용으로 손쉽게 고칠 수 있는 시기에 말이다.

🍭 Topic 14. 도메인 언어

문제 도메인의 언어가 어떤 프로그래밍 해결 방안을 제안하기도 하는데, 우리 생각에는 이것이 프로그래밍 언어의 사고방식보다 더 중요하다.

우리는 언제나 애플리케이션 도메인의 어휘를 사용해서 코드를 작성하려고 노력한다. 실용주의 프로그래머라면 어떤 경우에는 한 차원 더 나아가서 그 도메인의 실제 어휘와 문법, 의미론을 - 즉, 그 도메인의 언어를 - 사용해서 프로그래밍 할 수도 있다.

Tip 22. 문제 도메인에 가깝게 프로그래밍하라.

🥕 실세계 도메인 언어의 예

실제로 이 일을 해낸 사례를 몇 가지 살펴보자

RSpec

RSpec은 루비용 테스트 라이브러리로, 대다수 현대 언어에 비슷한 테스트 라이브러리를 만들도록 영감을 주었다. RSpec은 여러분이 코드에서 기대(expect)하는 동작을 테스트에 표현하도록 만들어졌다.

describe BowlingScore do
  it "3점을 네 번 얻으면 총점은 12점" do
    score = BowlingScore.new
    4.times { score.add_pins(3) }
    expect(score.total).to eq(12)
  end
end

큐컴버

큐컴버를 사용하면 프로그래밍 언어에 종속되지 않은 테스트를 정의할 수 있다. 정의한 테스트는 여러분이 사용하는 언어에 맞는 큐컴버 버전을 사용하여 실행시킬 수 있다.

기능: 점수 계산
배경:
조건 빈 점수판
시나리오: 볼링에서 3점을 여러 번 기록하기
조건 3점을 득점한다
그리고 3점을 득점한다
그리고 3점을 득점한다
그리고 3점을 득점한다
그리고 총점은 12점이다

🥕 내부와 외부 언어의 장단점

일반적으로 내부 도메인 언어는 호스트 언어의 기능을 쓸 수 있는 장점이 있다. 여러분이 만드는 도메인 언어를 공짜로 더 강력하게 만들 수 있는 것이다. 예를 들어, 루비 코드를 사용해서 자동으로 RSpec 테스트를 많이 생성할 수 있다. 다음 코드는 볼링에서 스페어나 스트라이크가 없는 경우를 테스트한다.

describe BowlingScore do
  (0..4).each do |pins|
    (1..20).each do |throws|
      target = pins * throws

      it "#{pins}점을 #{throws}번 얻으면 총점은 #{target}점" do
        score = BowlingScore.new
        throws.times { score.add_pins(pins) }
        expect(score.total).to.eq(target)
      end
    end
  end
end

내부 도메인 언어의 단점은 호스트 언어의 문법과 의미론을 따라야만 한다는 것이다. 이런 부분이 놀라울 정도로 유연한 언어도 있긴 하지만 그래도 여전히 원하는 언어와 구현할 수 있는 언어 사이에서 어느 정도 타협해야만 한다.

궁극적으로는 어떤 형태로 만들더라도 호스트 언어의 문법을 벗어날 수 없다.

외부 언어는 이런 제약이 없다. 여러분이 정의하려는 언어의 파서를 만들기만 하면 된다.

우리의 제안은 꽤 간단하다. 절약하는 것보다 더 많은 시간을 쏟지는 말라. 도메인 언어를 만들려면 프로젝트에 어느 정도 춛가 비용이 발생한다. 그럼에도 이를 상쇄할 만큼 비용을 절감할 수 있으리라는 확신이 있어야 한다. 아마 길게 보고 따져야 할 것이다.

🥕 손쉽게 만드는 내부 도메인 언어

마지막으로, 호스트 언어의 문법이 노출되어도 상관없다면 사용할 수 있는 편법이 있다. 메타프로그래밍을 남발하는 대신 그냥 함수를 써서 구현하라. 사실 RSpec도 그런 방식을 쓴다.

describe BowlingScore do
  it "3저믈 네 번 얻으면 총점은 12점" do
    score = BowlingScore.new
    4.times { score.add_pins(3) }
    expect(score.total).to eq(12)
  end
end

이 코드에서 describe, it, expect, to, eq는 모두 루비 메서드다. 막후에서 객체를 이리저리 넘기느라 약간의 작업이 있기는 하지만 모두 코드일 뿐이다.

🍭 Topic 15. 추정

추정하는 법을 배우고 추정 능력을 계발하여 무언가의 규모를 직관적으로 짚을 정도가 되면, 추정 대상의 가능성을 가늠하는 마법과 같은 능력을 발휘할 수 있게 될 것이다. 누군가 "우리는 백업한 것을 네트워크로 S3에 전송할 것입니다."라고 이야기할 때 직관적으로 이것이 가능한지 판단할 수 있게 된다. 코딩할 때에도 어떤 서브시스템을 최적화해야 하고, 어떤 서브시스템을 그대로 남겨 두어도 될지 알 수 있게 될 것이다.

Tip 23. 추정으로 놀람을 피하라.

🥕 얼마나 정확해야 충분히 정확한가?

어떤 의미에서 모든 답은 추정치다. 단지 어떤 답이 다른 답보다 좀 더 정확할 뿐이다. 그러므로 누군가 추정치를 물었을 때 스스로 물어보아야 할 첫 번째 질문은 여러분의 답변이 사용될 상황이 무엇인지다. 질문자가 매우 높은 정확도의 답을 요구하는가, 아니면 단순히 큰 그림만을 요구하는가?

우리는 여러분이 기간을 추정할 때 다음과 같은 단위를 사용하기를 추천한다.

1 ~ 15일: 일
3 ~ 6주: 주
8 ~ 20주: 달
20주 이상: 추정치를 말하기 전에 다시 한번 생각해 보라.

즉, 필요한 계산을 모두 해 봤더니 프로젝트에 대략 125근무일, 즉 25주가 소요될 것이라는 결론이 나왔다면 "대략 여섯 달"이 걸릴 거라고 이야기하라. 동일한 원리를 수량이나 분량의 추정치를 말할 때도 적용할 수 있다. 여러분이 전달하려는 정확도를 고려하여 답변의 단위를 선택하라.

🥕 추정치는 어디에서 나오는가?

모든 추정치는 문제의 모델에 기반한다. 그런데 모델을 작성하는 기술에 대해 깊이 파고들기 전에 항상 좋은 답을 알려주는 기본적인 추정의 비법을 하나 밝히겠다. 이미 그 일을 해본 사람에게 물어보라. 모델 작성에 너무 많은 시간을 쏟기 전에 과거에 비슷한 상황에 처했던 사람이 없는지 주변 사람들에게 문의해 보고, 그들이 어떻게 문제를 해결했는지 알아보자.
똑같은 일을 해 본 사람은 찾기 어렵겠지만, 놀라울 정도로 자주 다른 사람의 경험을 바탕으로 성공적인 추정치를 낼 수 있을 것이다.

무엇을 묻고 있는지 이해하라

어떤 종류의 추정을 하건 첫 단계는 상대방이 무엇을 묻고 있는지 이해하는 것이다. 앞서 이야기한 정확도 뿐 아니라 도메인에 존재하는 조건에 대해서도 감을 잡을 필요가 있다.
조건이 질문에 명시적으로 드러나지 않는 경우도 많지만, 여러분은 추정하기 전에 미리 어떤 조건이 있을지 생각하는 습관을 길러야 한다.

시스템의 모델을 만들어라

의뢰인의 요청을 이해한 후에는 간단하게 기본적인 것만 갖춘 개략적인 모델을 만들어 보라.
모델을 만드는 것은 창의적이면서도 동시에 장기적으로 유용한 작업일 수 있다. 모델을 만드는 과정에서 이전에는 표면에 명확히 드러나지 않았떤 숨겨진 패턴과 프로세스를 발견하는 경우도 많다. 초기의 질문을 재검토하길 원하게 될 수도 있다.

모델을 만들어 추정을 하면 그 결과는 부정확해질 수밖에 없다. 하지만 이는 피할 수 없는 일이며, 또한 유익한 일이기도 하다. 우리는 간결함과 정확성을 맞교환하고 있다. 모델을 만드는 데 두 배의 노력을 들이더라도 결과의 정확도는 미미하게 개선되는 정도일 것이다.

모델을 컴포넌트로 나눠라

다 만든 모델은 컴포넌트로 분해할 수 있다.

대부분의 컴포넌트에는 각 컴포넌트가 어떻게 전체 모델에 기여하는지를 나타내는 매개 변수가 있다. 이 단계에서는 일단 매개 변수를 찾기만 하면 된다.

각 매개 변수에 값을 할당하라

이 단계에서 약간 오차가 발생할 수 있다. 이때의 요령은 결과에 가장 큰 영향을 미치는 매개 변수를 찾아서 이 매개 변수의 값을 최대한 정확하게 산출해 내는 것이다.

이러한 주요 매개 변수를 계싼할 때는 나름의 근거가 있어야 한다. 예컨대 대기열 시스템에서 매개 변수를 계산하려면, 현재 시스템에서 일어나고 있는 실제 시간당 요청 수를 측정해 보거나, 측정할 수 있는 비슷한 시스템을 찾아 보아야 할 것이다. 실제로 추정을 하다 보면 다른 하위 추정치를 사용하여 추정치를 계산하는 경우가 있는데, 이때 큰 오차가 슬그머니 기어들어 올 확률이 높다.

답을 계산하라

주요 매개 변수들의 값을 변경시켜 가면서 여러 번 계산해보고, 이 가운데 어떤 것이 모델에 잘 들어맞는지 찾아내라.

여러분의 추정 실력을 기록하라

여러분이 계산한 추정치를 기록해 노혹, 나중에 이 값이 실제 결과에 얼마나 가까웠는지 평가해 보면 정말 좋을 것이다. 만약 전체 추정치를 구하기 위해 하위 추정치를 몇 개 계산했다면 이 역시 기록하라. 많은 경우 여러분의 추정치는 꽤 좋을 것이고 점차 평가 시간을 고대하게 될 것이다.

추정치가 틀렸더라도 움츠리거나 도망가지 말라. 왜 틀렸는지 찾아라. 현실과 동떨어진 매개 변숫값을 선택했을 수도 있고, 아니면 모델 자체가 틀렸을 수도 있다. 원인이 무엇이든 시간을 들여 이를 규명하라. 다음 추정치는 훨씬 나아질 것이다.

🥕 프로젝트 일정 추정하기

여러분은 보통 어떤 일에 걸리는 기간을 추정해 달라는 요청을 받을 것이다. 그 "어떤 일"이 복잡하다면 추정은 매우 어려워진다. 여기서는 불확실성을 줄이는 두 가지 기법을 살펴보자.

미사일에 페인트칠하기

"이 집에 페인트를 칠하려면 얼마나 걸릴까요?"
"글쎄요. 아무 문제가 없고 페인트 제품 설명에 나오는 리터당 도포 면적이 정확하다면 10시간 만에도 될 겁니다. 하지만 사실 그보다는 더 걸릴 것 같군요. 18시간이 더 현실적인 숫자인 것 같습니다. 물론 날씨가 나빠지면 30시간 넘게도 걸릴 수 있지요."

실제 상황에서는 사람들이 추정을 이렇게 한다. 숫자 하나로 대답해야만 하는 상황이 아니라면 숫자 하나가 아니라 여러 가지 시나리오로 추정한다.

값을 범위로 추정하는 건 추정 오류를 피할 수 있는 훌륭한 방법이다. 확신이 없어 숫자를 부풀리는 게 추정 오류의 가장 흔한 원인인데, 값을 범위로 지정하면 이런 부풀리기를 피할 수 있는 뿐 아니라, 통계가 범위로 표현한 불확실성을 분산시켜 주므로, 전체 프로젝트에 대해서 더 나은 추정치를 얻을 수 있다.

하지만 우리는 PERT(프로그램 평가 검토 기법)를 썩 좋아하지 않는다. 사람들은 벽을 가득 채우는 큰 차트에 프로젝트의 모든 과업을 그려 놓고는 은근히 자신들이 정확한 추정치를 갖고 있으리라 믿는다. "수식"을 사용헀다는 이유만으로 말이다. 하지만 실제로 이 프로젝트를 수행해 본 적은 없으므로 추정치가 정확할 리는 없다.

코끼리 먹기

가끔은 프로젝트의 일정을 정할 수 있는 방법이 해당 프로젝트를 경험해 보는 것뿐일 때가 있다. 기능을 매우 작은 단위로 나누어 다음과 같은 단계들을 반복하는 점증적 개발을 실천한다면 꼭 그런 것만은 아니다.

• 요구사항 확인하기
• 위험을 분석하고 위험도가 높은 부분을 우선 하기
• 설계, 구현, 통합
• 사용자와 함께 검증하기

초기 기능을 구현과 테스트를 마친 후, 이를 첫 번째 반복 주기의 끝으로 삼아라. 첫 반복 주기의 경험을 바탕으로 반복 주기의 수와 각 반복 주기에서 무엇을 지에 대한 처음의 추측을 다듬을 수 있을 것이다. 각 반복 주기가 끝날 때마다 추측을 더 다듬다 보면, 일정에 대한 확신도 이와 함께 커질 것이다. 이런 추정은 보통 각 반복 주기가 끝날 때 팀 리뷰 회의 시간에 한다.

Tip 24. 코드와 함께 일정도 반복하며 조정하라.

이 방법은 경영진에게 별로 인기가 없다. 경영진은 보통 프로젝트가 시작되기도 전에 하나의 정확한 숫자를 원하기 때문이다. 여러분은 팀, 팀의 생산성 그리고 환경이 일정을 결정한다는 사실을 경영진에게 이해시켜야 한다. 이를 공식화하고 더 정확한 일정을 추정하는 것을 각 반복 주기의 일부로 삼았을 때, 여러분이 추정할 수 있는 가장 정확한 일정을 경영진에게 건넬 수 있을 것이다.

🥕 누군가 추정해 달라고 하면 뭐라고 대답해야 할까?

"나중에 연락드릴게요."라 말해야 한다.

잠시 손을 멈추고 시간을 내어 이번 항목에서 설명한 단계를 밟아 나간다면 대부분의 경우 더 좋은 추정치를 얻을 수 있을 것이다.