읽기에 앞서…

실용주의 프로그래머를 읽고 느낀점을 써보려고 합니다. 제가 느낀바로는 이러한 내용이다 하는 방향으로 기술할 것 같습니다.

제 1장. 실용주의 철학

이 장에서는 문제에 어떻게 접근해야 하는지에 대한 철학을 알려준다.

1. 고양이가 내 소스코드를 삼켰어요:

• 내가 한 일에 대해선 책임을 져라. 안돌아가면 변명하지 말고 대안을 찾아야 한다.
• 본인의 실력에 대해 자부심을 가질 필요가 있다. 그런만큼 실수를 인정할 필요도 있다.

Tip 3. 어설픈 변명은 하지 말고 대안을 제시해라.

코드를 버려야하나? 리팩토링 가능 뭘 구현해야하지? 프로토타입 구현으로 먼저 보여줌 테스팅, 자동화도 도입해야할 요소

SE시간에 빤히 배웠던 것들을 다시금 강조한다.

부탁하고 묻고 하는 것에 두려움이 없어야 한다. 혼자 끙끙 앓으면 나만 아프다.

2. 소프트웨어 엔트로피

프로그램을 짜면 필연적으로 누더기 코드가 생긴다. ‘깨진창문 이론’을 생각하자! 작살났거나 쪼대로 짠 코드는 다른 코드도 대충짜게 만든다.

Tip 4. 깨진창문을 내버려두지 마라.

영 좋지않은 코드는 주석처리를 하든, 더미 데이터를 넣어놓든 해야한다.

시간이 촉박하거나 데모를 보여줘야할 땐 물론 급하게 돌아가게는 만들어야한다. 하지만 이는 반드시 수정되어야한다. 이러한 행동을 하지도 않는게 좋겠지.

멍청한 코드는 프로젝트를 망가뜨리는 지름길이기 때문이다.

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

돌죽 일화를 말한다.

킥스타팅은 별게 아니라 걍 쉬운걸 구현하는데서 시작한다는 말이다.

작년에 프로젝트를 해보면서 틀만 짜놓고 퍼졌던 적이 있다. 그래 뭐 이정도는 했지 ㅋㅋㅋ 하고 자만하고 끝이었는데, 다시보니 그때부터 시작이었던 것이다. 나부터 변화의 촉매가 되어야 한다.

Tip 5. 변화의 촉매가 되어라!

그렇지만, 기능을 잡아넣기만 하면 프로젝트가 뒤틀린다. 세세한거에 집중하다보니 원했던 구현이 되지 않는다. 책의 내용을 그대로 인용하자면 다음과 같다.

(중략) 프로젝트 폭주는 대부분 어느날 갑자기 일어난다. 코드에 패치가 하나 둘 적용되다가 원본이 하나도 남지 않을 때 까지, 시스템은 명세에서부터 기능 하나하나씩 정처 없이 떠다닌다.

그러니까 항상 ‘큰 그림을 기억해야’ 한다. 프로젝트가 어떻게 만들어질지 생각했으면 그거대로 만들어야한다 이말이다. 요구사항과 설계가 이래서 중요하나 싶다.

Tip 6. 큰 그림을 기억하라!

개구리는 서서히 끓는 냄비속에서 ‘어 따뜻해지네?’ 하다가 죽는다. 변화를 감지하지 못한 채로 있다가 방황할지도 모른다.

이 주제는 정말 중요한 질문을 던지며 마무리한다.

1. stone soup story에서의 변화와 개구리를 점진적으로 속이는 변화의 차이는 뭘까?

2. 내가 일으킨 변화는 팀에있어 스톤수프 변화일까, 개구리수프 변화일까?

3. 이 판단은 주관적일까, 객관적일까?

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

‘적당히 괜찮은’ 이란 말은 영 좋지않은 코드를 말하는게 아니다. 이건 책을 그대로 인용해서 이해하는 것이 좋겠다.

(중략) 시스템이 성공하려면 사용자의 요구사항을 충족해야 한다. 단지 우리는 여러분이 생산해낸 것이 어느 정도면 적당히 괜찮은지를 결정하는 과정에 사용자가 참가할 기회를 가져야 한다는 걸 말하고 있는 것이다.

피드백을 얻을 필요가 있다 이말. ‘얼마나 좋아야’되는가? 에 대한 질문은 유저들이 대답해줄 것이다. 프로토타입을 내어주고 그에 대한 피드백으로 개발할 수도 있는 부분이다.

Tip 7. 품질을 요구사항으로 만들어라.

프로그래밍은 애초부터 완벽하게 할 수가 없다. 불-완벽한(완벽에 최대한 수렴하는) 프로그램을 짤 생각을 해야한다.

내가 사용자라면? 버그가 단 하나도 없는 프로그램을 기다릴거냐? 복잡한 SW를 쓰면서 어느정도까지 버그는 감내할 수 있냐? 아니면, 결함이 더 적은 간단한 SW를 쓸거냐?

5. 지식 포트폴리오

내가 가지고 있는 지식은 결국 ‘소진하는 자산(expiring assets)’ 이다. 내 지식은 옛날의 것이 되고, 그 변하는 속도는 말 그래도 미쳤다 웹은 더 미친듯이 바뀐다. 오늘 다르고 내일 다르다.

그래서 책은 내가 알고있는 사실, 경험을 ‘지식 포트폴리오’로 생각하기를 권장한다. 실제 투자하고 밀접한 연관이 있는데 이는 다음과 같다.

1. 진지한 투자자들은 주기적으로 투자하는 습관을 가지고 있다.
2. 장투로 성공하기 위한 답은 다각화다.
3. 똑똑한 투자자들은 자신의 포트폴리오를 보수적인 투자, 위험성이 큰 투자, 보상이 높은 투자 사이에서 균형을 잘 맞춘다.
4. 최대 수익을 위해 싸게 사서 비싸게 판다.
5. 포트폴리오는 주기적으로 재검토, 재조정 해야한다.

프로그래머는 위의 수칙을 이렇게 응용할 수도 있다

• 주기적인 투자: 꾸준히 신기술을 배워야함.
• 다각화: 어느 분야의 특정 기술이 언제 생기고 언제 사라지는지 파악해야함. 많은 기술에 익숙하면 변화에 잘 적응할 수 있을 것이다.
• 리스크 관리: 어느 기술이 어떻게 흥하고 망할지는 아무도 모른다. 그러니까 한기술에 몰빵하지 마라.
• 싸게 사서 비싸게 팔기: 신기술이 생기면 적극적으로 들이대보라. 분명 리스크가 있는데, 빵 뜬 언어같으면 내가 그 언어를 ‘잘 안다’ 할 수 있다. 그건 분명 좋은 점이다.
• 검토 및 재조정: 작년까지 잘쓰던 기술이 올해는 쌉퇴물이 될 수도 있다. 한동안 안쓰던 기술을 이제와서보니 다시 쓰더라 하기 쉽다. 그래서 많이 다뤄봐야 한다는 말.

Tip 8. 지식 포트폴리오에 주기적으로 투자하라.

본 책에서는 다음과 같은 방법을 제안함.

• 매년 새 언어를 하나씩 배워라.
• 기술 서적을 분기마다 하나씩 읽어라.
• 비기술 서적을 읽어라. 심리학, 문화인류학, 건축학, 경영학 이런 것들 조차도..
• 수업을 들어라. 각종 세미나, 컨퍼런스에 가보라는 말.
• 지역 사용자 모임에 참여하라. 고립되면 안된다. 개발자 모임에 가서 새로운 피를 계속 수혈받아야한다.
• 다른 환경에서 실험해보라. 윈도우도 써보고 맥도 써보고 유닉스도 써보고 하여튼 다 써봐야함. ./configure, makefile, make도 해봐야되고 IDE도 써봐야되고 하여튼 다 써봐야한다.
• 트렌드를 계속 파악하고 있어야한다. subscribe! 이메일 노트도 계속 봐야한다. 맨날 쓰레기통에 주떤지지 말고
• 인터넷을 이용하라. 구글께서는 답을 알고계신다.

질문하는 방법은 kldp에도 있다. 그런 구루들에게 많이 물어서 답을 내꺼로 하자!

비판적인 사고는 중요하다. ‘내 말이 옳다!’ 하는 미치광이를 멀리해야한다. 어떤 문제에 대해 무조건 풀 수 있는 답 같은건 없다. 주어진 문제를 풀 수 있는 방법은 다양하기 때문이다. 하지만 때로는 아름다운 단 하나의 답만이 존재할 수도 있다.

kldp의 어느 사람의 말을 기억하자.

프로그래밍 언어는 목적이 아니라 수단일 뿐입니다. Buzz와 Fanboyism에 휘둘리기 보다는 하고 있는 일이 잘되게 하는 Getting Things Done에 집중하시길 추천드립니다.

Tip 9. 읽고 듣는 것을 비판적으로 분석하라.

6. 소통하라!

앞서 말한걸 다 할 수 있어도 다른사람과 함께 일할 수 없다면 아무 쓸모가 없다. 혼자 일하는 프로그래머는 거의 없고 있어도 다른 누군가하고 분명 소통하고 있을 것이다.

• 내가 말하고 싶은게 뭔지 파악하자. 문서에 서론, 본론, 결론 나눠서 생각하는 만큼 말할때도 다듬어서 하면 서로 좋다. 나는 할말 바로하고, 상대방은 바로 알아먹으니까.

• 청중을 파악하자. 쓸데없이 말 할 필요가 없다. WISDOM principle을 파악하고 써먹으면 그럴 필요가 없어진다.

WISDOM: 청중 이해하기(내 말을 듣는 사람이 어떤가?)

키워드	내용
What	듣는 사람이 무엇을 배우길 원하는가?
Interest	듣는 사람이 관심있어 하는 것은 무엇인가?
Sophisticated	듣는 이들이 얼마나 소양이있나?
Detail	듣는 이들이 어느정도의 구체적인 내용을 원하나?
Owe	누가 정보를 소유하길 원하나?
Motive	듣는 이가 경청하도록 동기를 주려면 어떻게 해야할까?

듣는사람을 여섯가지로 먼저 파악하고 말하면 이해도가 빠르다.

• 언제 내가 말하면 상대방이 잘 들을까? 상대방이 듣고싶어하는 때를 잘 캐치해서 말하는 것이 좋다. 듣는이의 우선순위를 고려하는 것이 좋은 방법이 될 것이다.

• 말하는 스타일을 골라라. 말하는 스타일이 듣는 사람이 듣고싶어하는 대로 해줘야 좋아하게 된다.

• 멋져보이게 하라. 아래아 한글을 써도 간지나게 쓰는 사람이 있는가하면 파워포인트를 써도 그놈의 보노보노를 쓰는 사람이 있다. 뭐가 나를 돋보이게 할까? 적어도 내가 쓰는 툴의 다양한 기능을 찾아서 간지나게 해야 보는 사람도 좋고 만든 사람도 뿌듯하지 않을까?

• 청중을 참여시켜라 문서의 초고를 독자가 보고 맘에든다/이건 싫다 하는걸로 피드백을 받을 수 있으면 도움이 된다.

• 청자(listener)가 되어라 내가 상대 말을 먼저 잘 들어야(경청해야) 남도 내 말을 들어준다.

• 응답하라 대답은 해줘야 핑퐁대화가 될 것 아니냐.

cf) 이메일 의사소통: 구글 검색해라

Tip 10. 무엇을 말하는가와 어떻게 말하는가 모두 중요하다