[실용주의 프로그래머]를 읽고 #7. 2장. 실용주의 접근법. Topic 14, 15

실용주의 프로그래머라는 책을 읽으며, 삼색볼펜 독서법을 적용. 줄 친 내용에 대한 단상을 정리합니다.
삼색볼펜 스터디란? 책에서 중요하다고 생각되는 문장을 빨강 > 파랑 > 검정 순으로 줄을 치며 공부하는 방식.

🔴 가장 중요한 문장
🔵 그래도 꽤 중요한 문장
⚫ 그럭저럭 내 마음에 와닿은 문장
🤔 짧은 생각 (단상은 단상일뿐!!)
볼드체 중요한 문장은 아니지만 단락 구분 표시

---

Topic 14. 도메인 언어
🔴 문제 도메인의 언어가 어떤 프로그래밍 해결 방안을 제안하기도 하는데, 우리 생각에는 이것이 프로그래밍 언어의 사고방식보다 더 중요하다.
🤔 솔직히 잘 이해가 되지 않던 단락이긴 했다. DSL을 이야기하는건가? 싶었는데 딱히 그런거 같진 않았고…빨간색으로 칠한 이유는, 우리는 프로그래밍 언어로 문제를 해결하고 표현하려고 하는데, 일반적인 언어로 문제를 정의하고 해결하는 것이 먼저 되어야 다른 직군의 사람들과 일을 할 때 수월하다는 의미에서 빨간색으로 그었다.

⚫ 요구 사항 수집, 설계, 코딩, 출시를 차례대로 수행하는 전통적인 소프트웨어 개발 방식이 제대로 동작하지 않는 이유 중 하나는 이 방법이 우리가 요구 사항을 알고 있다는 전제에 기반하기 때문이다. 실제로는 잘 모른다.
🤔 개발자는 물론이고, 떄론 기획자나 정책 담당자도 요구사항을 잘 모른다. 즉, 실제 프로그래밍 언어보다 소통하는 언어. 우리의 도메인과 관련된 언어가 훨씬 중요하다. 이거 대충해놓으면 나중에 화딱지난다.
 
Topic 15. 추정
⚫ 추정하는 법을 배우고 추정 능력을 개발하여 무언가의 규모를 직관적으로 짚을 정도가 되면, 추정 대상의 가능성을 가늠하는 마법과 같은 능력을 발휘 할 수 있게 될 것이다.
🤔 학부 과제 같이 내 의사와 상관없이 일방적으로 기한이 정해지는 경우도 있지만, 보통은 ‘그래서 이거 얼마나 걸릴까요?’라는 질문을 받게 되고 그 후 일정 산정에 들어가게 된다. 따라서 이 일정 산정, 그러니까 추정에 있어서 높은 정확도를 가진다면 그만큼 설득력 있는 의견이 된다.

얼마나 정확해야 충분히 정확한가?
⚫ 사실은 사용하는 단위가 결과의 해석에 차이를 가져온다는 것이다.
🤔 한달과 4주, 30일이란 표현은 각각 다르게 와닿는다. 문제의 범위에 따라 표현하는 단위를 신중하게 골라야 오해가 없다. 

추정치는 어디에서 나오는가?
⚫ 모든 추정치는 문제의 모델에 기반한다. 이미 그 일을 해본 사람에게 물어보라.
🤔 해당 도메인에 익숙한 사람에게 조언을 구하는 것도 좋다. 그 사람이 모든 요구사항을 알 필요는 없지만 의견이라도 들으면 추정하는데 엄청난 도움이 된다.

무엇을 묻고 있는지 이해하라
🤔 이게 중요하다. 상대방은 당연하다고 생각하는 걸, 내가 당연하지 않다고 생각할수도 있고, 내가 당연하다고 생각하는걸 상대방은 모르고 있을 수도 있다. 서로 요구사항을 이해할 수 있도록 묻고 대답하자.

시스템의 모델을 만들어라
🔵 모델을 만드는 과정에서 이전에는 표면에 명확히 드러나지 않았던 숨겨진 패턴과 프로세스를 발견하는 경우도 많다.
🤔 유스케이스의 플로우를 그려봐도 좋고, 예광탄이나 프로토타이핑을 만들어 보는 것도 좋다. 서로 이해 못하고 있는 숨겨진 요구사항과 예외 케이스를 찾아내자!

모델을 컴포넌트로 나눠라
⚫ 일단 매개 변수를 찾아라
🤔 적절한 단위로 모듈을 나누고, 각 모듈에 영향을 주는 매개변수를 찾자. 이 부분은 소프트웨어 개발자들에게 익숙한 작업일지도 모른다.

각 매개 변수에 값을 할당하라
⚫ 각 매개 변수에 값을 할당할 차례다.
🤔 요구사항에 맞춰 매개변수에 값을 넣어 추정을 시작하자

닶을 계산하라
여러분의 추정 실력을 기록하라
🤔 어떤 매개변수에 어떤 값을 넣었을때 결과가 어떻게 나오는지 소상하게 기록해서 공유하자. 이래놓고 무시한다면 마음은 아프지만…그 문서 자체가 나의 의견이고 무기가 된다.

프로젝트 일정 추정하기
미사일에 페인트칠하기
🔵 모든 PERT(Program Evaluation Review Technique) 과업은 낙관적 추정치와 가장 가능성이 높은 추정치, 비관적 추정치를 갖는다.
🤔 보통 낙관적 추정치를 요구한다. 그래서 은근 많은 개발자들이 이 추정치만 이야기한다. 이 낙관적 추정치는 모든 가용인원이 연차 한개도 쓰지 않고, 한번도 아프지 않고, 모든 부서가 협조했을 때 가능하다. 현실은 저언혀 그렇지 않다. 다소 처음에 욕을 먹더라도 낙관적 추정치보다는 객관적으로 가장 가능성 높은 추정치를 말하는 것이 좋다. 나에게도 팀원에게도 훨씬 이득이다.

⚫ 확신이 없어 숫자를 부풀리는 게 추정 오류의 가장 흔한 원인인데, 값을 범위로 지정하면 이런 부풀리기를 피할 수 있을 뿐 아니라, PERT 속의 통계가 범위로 표현한 불확실성을 분산시켜 주므로, 전체 프로젝트에 대하여 더 나은 추정치를 얻을 수 있다.
🤔 무작정 비판적으로 이야기하지 말고, 그 수치에 대한 이유와 수치에 대한 범위를 이야기하면 납득할 수도 있고 안할 수도 있다. 하지만 내가 그런것까지 고려했다는 입장은 남으니, 그걸로 충분하다.

코끼리 먹기
🤔 사실 어떻게 해도, 추정값은 진행하면서 바뀌기 마련이다. 프로토타이핑은 프로토타이핑일 뿐 어떻게 시작하지도 않았는데 정확한 추정이 가능한가…? 맨날 똑같은 일 하는 것도 아닌데!!! 상황은 매번 달라지는데!

⚫ 코드와 함께 일정도 반복하며 조정하라. 이 방법은 경영진에게 별로 인기가 없다.
🤔 이게 맞지만, 슬픈 현실. 결국은 야근을 해서 일정을 맞추게 된다...

🔵 여러분은 팀, 팀의 생산성 그리고 환경이 일정을 결정한다는 사실을 경영진에게 이해시켜야 한다.
🤔 난 그래서 처음 추정치를 말할 때 비판적으로 말하는 편이다. 몇몇 사람들은 나에게 너무 비관적이라고 이야기하는데…나중에 보면 내 비관적인 추정조차도 너무 낙관적이었다는 게 밝혀지곤 한다. 세상은 마음대로 돌아가지 않아.

누군가 추정해 달라고 하면 뭐라고 대답해야 할까?
🔴 “나중에 연락드릴게요”라 말해야 한다.
🤔 가장 핵심 문장. 덮어두고 대충 말하지말자. 그 말은 나와 내 동료가 책임지고, 그 여파는 어디까지 퍼질지 모른다.
 

실용주의 프로그래머(20주년 기념판)