[실용주의 프로그래머] Topic 1 ~ 5

Topic 1. 당신의 인생이다.

개발자들의 다양한 여러 불만 → 현재 업무, 기술의 변화, 성과, 연봉, 팀 분위기 등

이에 대한 답은 한결 같다. “왜 직접 바꾸지 않는가?”

당신에게는 스스로의 행동을 직접 결정할 수 있는 힘이 있다.

• 필요한 사항이 있으면 요구해보기
• 안된다 했을 때 정말 원하는 거면 다른 곳 찾아보기
• 여가시간 쪼개서 재미있어 보이는 것 공부하기

이 업계는 여러분에게 놀랄 만큼 다양한 기회를 준다. 주도적으로 행동해서 그 기회를 잡아라.

---

Topic 2. 고양이가 내 소스 코드를 삼켰어요.

실용주의 철학 중 하나 “자신과 자신의 행동에 대해 책임을 지는 것”

• 기술적 문제? → 정직하고 솔직해져야 한다. 실수나 무지 같은 단점도 인정해야 한다.

팀 내 신뢰

• 팀이 여러분을 믿고 의지할 수 있어야 한다.
• 신뢰에 바탕을 둔 건강한 환경에서는 안전하게 여러분의 생각을 말하거나 아이디어를 제안 할 수 있다.

책임지기

• 실수, 잘못된 판단을 내렸다면, 정직하게 인정하고 다른 방을 제안하도록 노력하라.
• 다른 사람 혹은 다른 무언가를 비난하거나 변명을 만들어 내지 말라. 해결책을 찾아내야 하는 사람은 여러분이다.
• 소스 코드 백업을 안해서 날라갔다? 상사에게 “고양이가 내 소스 코드를 삼켰어요"라고 변명해봤자 도움이 안될 것. 어설픈 변명 말고 대안을 제시하라.

변명말고 대안을 제시하라. 안된다고 하지 말고, 상황을 개선하기 위해 무엇을 할 수 있는지 설명하라.

• 자원이 더 필요하면 요청하라. 부탁을 어려워하지 말고 도움이 필요하다는 사실을 인정하라.
• “잘 모르겠어요"라고 말했다면, 꼭 바로 이어서 “하지만 알아볼게요"라고 말하자. 모른다는 것은 인정하더라도 전문가답게 책임을 지는 좋은 방법이다.

---

Topic 3. 소프트웨어 엔트로피

엔트로피: ‘무질서'한 정도

• 소프트웨어의 무질서도가 증가할 때, 이를 ‘소프트웨어의 부패’ 라고 함. 또 다른 표현으로 기술 부채 (Technical debt) 라고 한다.

왜 ‘기술 부채’라고 할까?

• ‘부채’라는건 빚이므로 언젠간 갚아야 되는 것을 의미.
• 즉, 소프트웨어의 무질서도라는 것이 기술적인 갚아야하는 것들을 의미하기 때문에 기술부채라고 일컫는 것 같다.
• ‘기술 부채'는 언젠간 갚을 수 있다는 뉘앙스를 풍기지만, 아마 갚지 않을 것.

소프트웨어 부패하는데 관여하는 요소 중 가장 중요한 것은 기술적인 것이 아님. ‘심리학적 혹은 문화적 요소’ 임.

• 깨진창문 이론
  • 오랜 기간 수리하지 않고 방치된 창문 하나 때문에 거주자들에게 버려진 듯한 느낌이 스며듬. 그 상황에서 다른 창문이 하나 더 깨지게 되면, 사람들이 쓰레기를 함부로 버리기 시작. 벽에 낙서가 등장하고, 이렇게 진행되면서 심각한 구조적 손상이 시작됨.
• 즉, 명백히 망가진 상황을 무시하는 것은 아무것도 고쳐지지 않을 것 같다는 생각, 아무도 신경쓰지 않는다는 생각, 망조가 들었다는 생각을 더 굳어지게 만든다. 이런 부정적인 생각이 팀원들 사이로 퍼져서 악순환을 만들 수 있다.

그래서 말하고 싶은 것은 ‘깨진 창문을 고치지지 않은 채로 내버려 두지 말라는 것’

• 개발에서 ‘깨진 창문'이란, 나쁜 설계/잘못된 결정/형편없는 코드 등이 있다.
• 발견하자마자 바로 고치자. 고칠 시간이 없다면, 코멘트를 해놓거나, dummy 데이터를 넣어 보완해놓거나, 엉터리 코드를 주석처리 해놓기라도 하자.
  • 이는 개발 기능 상 영향도가 없을 수 있어도 ‘더 이상 손상을 방지하기 위해 어떤 조치든 취하고 상황을 잘 관리하고 있음’을 보여줄 수 있다.

깨끗하고 잘 기능하던 시스템이 일단 창문이 깨지기 시작하면 급속도로 악화되는 경우를 많이 보았다.

• 방치는 다른 어떤 요인보다도 부패를 더 가속화 시킨다.

깨진 창문이 꽤 있는 프로젝트에서 일할 때는 ‘나머지 코드가 전부 쓰레기니깐 나도 그렇게 하지 뭐'라는 사고에 빠지기 너무 쉽다.

• 여러분이 속한 프로젝트의 코드가 깨끗하고 잘 설계되었으며 우아하다면, 특별한 주의를 더 많이 기울여서 엉망으로 만들지 않으려 할 것이다.
• 명심하자. “깨진 창문은 없어야 한다”

---

Topic 4. 돌멩이 수프와 삶은 개구리

돌멩이 수프 스토리

• 군인 3명이 전쟁 끝나고 귀가 중, 마을을 발견. 마을이 가까워지자, 마을사람들이 음식을 대접할 것이라 기대.
• 하지만 전쟁을 겪으며 식량이 부족해진 마을 사람들은 문을 다 잠그고, 마을 사람들 개개인들도 각자 몰래 음식재료들을 숨겨놓은 상황. 즉, 군인들에게도 음식을 대접하지 않았음.
• 군인들은 단념하지 않고, 냄비에 물을 끓이고 돌멩이 3개를 넣었음.
• 놀란 마을 사람들이 이 광경을 보러 나옴. “돌멩이만 집어 넣는 거에요?”라고 묻자, 군인들은 돌멩이 스프라며 “당연하죠, 뭐 어떤 이들은 당근을 몇 개 집어넣으면 더 맛있다고 하지만요.”라고 대답함. 이걸 들은 한 명이 당근 한 바구니를 가져와서 줌.
• 다른 사람이 “이제 된 건가요?” 묻자, “감자를 몇 개 더 넣으면 더 맛있긴한데요..”라고 답함. 그러자 마을 사람 중 또 다른 한명이 감자를 가져다 줌. 그 후 계속해서 군인들은 재료를 이야기했고, 결국엔 많은 재료가 들어간 수프를 만들어냈고, 돌멩이는 건져내고 마을사람들과 수프를 맛있게 먹음.

여기서 얻을 수 있는 교훈이 있다?

• 군인들은 음식재료를 얻으며 마을 사람들을 속임. 하지만 이런 속임수가 “촉매"로 작용해 마을 사람들 스스로 불가능했던 무언가를 힘을 모아 이룰 수 있도록 도움.
• 이런 “속임수 촉매"가 없었다면, 마을 사람들 스스로가 힘을 합쳐 수프를 만들 수 없었을 것. 시너지의 결과를 만들었다.

상황을 현실에 대입해보자.

전체 시스템이 눈앞에 빤히 그려지고, 여러분은 그 시스템이 옳다는 것을 알고 있는 상황.

• 막상 그 일을 진행하려하니 허락이 필요하고, 위원회가 생기고, 예산 승인이 필요하고 등등 일이 지연되기 시작하고, 복잡해지기 시작.
• 모든 사람이 각자 자신의 자원을 지키려고 할 것 → “시작 피로(start-up fatigue)” 라고 한다.

이런 상황이라면, 돌멩이를 내놔야 할 때이다.

• 큰 무리없이 요구할 수 있는 것을 찾고, 그걸 잘 개발하자. 이로써 무언가 결과물이 나오면, 그걸 보여주고 그들을 놀라게 만들자.
• 그러고는 “물론 ~ 기능을 추가하면 더 결과물이 좋아지긴 하겠죠"라며 그다지 중요하지 않은 척 가장하자. 이제 물러나, 사람들이 그 기능을 추가해달라고 부탁할 때까지 기다리자.
• 이런 것처럼 미래를 살짝 보여주면 이게 촉매가 되어 도와주기 위해 몰려들 것이다.

마을 사람들 입장을 생각해보자.

• 돌멩이에만 너무 지나치게 집중 → 다른 상황을 보지 못한다.
• 현실을 보자. 모르는 새 서서히 상황 또는 프로젝트가 악화되고 있는 것을 자주 볼 수 있다. 처음에는 대부분 작아 알아채지 못하지만, 어느새 갑자기 폭주하고 있다. 이렇듯 종종 작은 것들이 쌓여 사람들의 의욕, 팀, 프로젝트를 파괴한다.

차가운 물이 든 냄비속 개구리를 넣고 물을 끓이면 개구리는 온도가 오르는 것을 감지 못하고 삶아질 때까지 그대로 있는다고 한다.

• 위 상황과 같은 것.
• Topic 3의 깨진창문과는 조금 다르다. 깨진 창문은 사람들이 주의를 기울이지 않는다는 것을 알게되니 엔트로피에 대해 대항할 의지를 잃게 된다는 것. 반면 개구리는 단지 변화를 감지 못하는 것.
• 개구리처럼 되지 말자. 큰 그림에 늘 주의를 기울이자. 당장 하고 있는 일에만 정신을 쏟지 말고, 주변에서 무슨 일이 벌어지는지 늘 살펴보자.

실생활에 반영해보기

• 머리 위 천장에 전등이 몇 개 있는가?, 지금 있는 방에 출구는 몇 개 있는가?, 사람이 몇 명이 보이는가?, 주위에 뜬금 없는 것이나 여기에 속하지 않는다고 생각하는 물건이 있는가? ⇒ 상황인식 훈련을 해보자.
• 주변을 살피고, 의식하는 습관을 들이자. 그리고 여러분의 프로젝트에 대해서도 똑같이 행하자.

---

Topic 5. 적당히 괜찮은 소프트웨어

많은 사용자가 휘황찬란한 버전을 위해 일 년을 기다리느니 차라리 오늘 당장 좀 불편한 소프트웨어를 사용하고 싶어한다.

• ‘적당히 괜찮은' 소프트웨어

‘적당히 괜찮은'이란 표현은 형편없는 코드를 의미하지 않는다.

• 시스템의 요구사항을 만족 → 이걸 알기 위해서 타협과정에 사용자를 참여시켜라.

오늘의 훌륭한 소프트웨어는 많은 경우 환상에 불과한 내일의 더 완벽한 소프트웨어보다 낫다.

• 사용자에게 뭔가 직접 만져볼 수 있는 것을 일찍 준다면, 피드백을 통해 마지막에는 더 나은 해결책에 도달할 수 있을 것이다.

생각해보기

• 기능 블로트(feature bloat) 현상: 소프트웨어가 사용하는 기능에 비해 훨씬 더 많은 기능을 가지고 있을 때, 기능이 많은 만큼 버그 및 보안 취약점이 생길 가능성도 높은 현상.
  • 주변의 프로젝트 중 기능 블로트 현상이 있는 프로젝트가 없는가? 기능 블로트 현상에 빠진 유명한 소프트웨어가 어떤게 있을까?