Ship it! 은 개발 프로젝트 수행 단계, Release it은 개발이 끝나고 라이브가 진행중인 단계에 도움이 될만한 책이라고 널리(?) 알려져 있다.
근데 난 어찌 순서가 좀 거꾸로 된듯 싶은게, Release it을 먼저 (빌려)읽은 후 이 책을 봤다(...).
Release it 같은경우 번역 문제도 그랬지만(참고로, r모님 말씀대로 Release it 같이 좋지 않은 번역서는 정말 번역서 질의 향상을 위해서라도 사서 보아선 안된다고 생각한다.), 특정 분야를 어느 정도 잘 알고 있지 않으면 원서로 보아도 많이 힘들 것으로 생각된다.
반면!.
ship it은 개발자에게도 좋은 참고/재밌는 이야깃거리가 될 뿐더러(개발자는 한번 두번 세번, 사과를 그려가며 읽어도 재밌다), 개발자와 같이 일해야 하는 비개발자들도 한번 거들떠 보면 더불어 살아가는 데 좋을 듯한 책이다.
다른 실용주의 개발 책들과 달리, 실험해 볼 수 있는 실제적인 방법들을 비교적 소상히(?) 소개하고 있다.
난 특히 다음과 같은 소재들이 마음에 들었다(스포일러이므로 볼 사람만 보시오).
===몇가지 소재들===
- 코드 리뷰
정말정말정말정말 필요하다고 생각. 개슈든 버리버리 개발자든 옆에 줄주리타가 있으면 큰 힘이 되는 것이 자명하다.
"페어프로그래밍"도 "눈이 네 개일 때 더 버그도 잘 잡고 일도 빨라지고 둘의 이해도도 완벽해진다"라는 배경에서 출발했지만, 나의 경우 사람에 따라 지나치게 긴장해서 체력이 급강하 되고 머리가 잘 안풀리는 문제 또한 있었다. 특히 상사의 경우, 시험감독이 뻔히 보고 있는 앞에서 덜덜덜 거리며 문제를 푸는 느낌이랄까;-;;..
반면 현실적으로 부딪히는 문제는, 많은 회사의 개발자가 자기 일만으로 헐떡헐떡 거려 남의 코드를 볼 마음과 시간의 여유가 없을 때가 많다는 것. 이 여유를 만들어주고 리뷰를 귀찮다고 생각하지 않게 만드는 게 제일 허들.
- 일일 회의
매일매일 한다는 사실보다는, "모든 구성원이 말을 하게 만들어야 한다" 라는 점이 특히 공감이 간다. 한국 사회의 특성인지, 연구실이고 회사고 모임의 장으로부터 조금씩은 수직적으로 일을 하는 성향이 다들 배여 있고, 회의도 위에서부터 잔소리 듣는 시간이 되기 쉽다. 모두가 자신의 일에 대해 꿍얼꿍얼 말을 열기 시작하면, 자연스레 위아래/수평적으로 의사소통이 될 여지가 많다.
"적당한 폴링"을 자연스럽게 하는 효과도 있을 듯.
그나마 제시한 회의 형태와 가장 유사했던 게 대학원 때 일주일에 한번 진행했던 "팀미팅"이다. 물론 "교수님과 나 사이의 일방적인 보고 활동"에 가까웠다는 건 좀 아쉬웠어도, 내가 뭘 하고 있는지 내가 설명하면서 스스로가 정리되고, 남이 대충 뭘 하는지도 꿍쳐 들을 수 있는 게 좋았다. 개슈 선배들에게 조언도 많이 들을 수 있었고..
일일 회의가 문제가 될 만한 게 있다면, "쓸데없는 회의는 하지 않는다"를 주장하는 개발자들도 많다는 것. 사실 그것도 그들 입장에선 맞는 말이긴 하다. "쓸데 있는 회의"를 만들어 시간낭비라고 생각하지 않게 하는 게 중요하겠지. 뭐 "매일매일"이라는 건 실제 도입했을 때 얼마나 효과가 있을지 궁금하다 정도?
- 테스트 주도 개발
말할 필요도 없이 멋지구리!!.
업종 전환 전 '임베디드 스러운' 일들을 잠시 할 때는 테스트 시나리오는 끝도 한도 없이 있고, 손으로 하지 않으면 테스트할 수 없는 기능들이 많아 머리가 아팠다("핸드폰을 켜고 새 동영상 업로드를 3건 시도하고, 3건 째가 올라가는 중에 갑자기 배터리를 손으로 뺀뒤, 다시 핸드폰을 켜본다"라는 시나리오는 로봇을 만들지 않는 이상 사람이 할 수밖에 없다. "전원을 끈다"와 "배터리를 뺀다"는 저언혀 이 세계에서 다른 개념이므로 ㅠㅠ).
이렇게 고생스러운 분야이기에 오히려 "테스트 할 수 있는" 시나리오는 모두 빡세게 테스트 하는 습관들이 좀 된다 싶은 기업들이라면 박혀있는 듯. 테스트 가능한 아이들을 완벽히 통과시키면 그만큼 "고생스러운 테스트"에서 "괴로운 디버깅"을 할 가능성도 줄어든다는 것을 몸으로 알고 있기 때문이다(뭐 물론 무식한 회사들이 없는 건 아니다==.).
각종 시뮬레이터와 에뮬레이터, CAD 툴들에 대해서도 수없이 많은 논문과 방법론들(반 이상은 다시는 안쓰일지도 모를)이 나오는 이유도 이것 때문이겠지.
요새는 또 다른 이유로 여러 가지 머리가 지끈지끈 아픈데, 업종전환(?)을 한 분야의 테스트가 참말로 "광활하기" 때문이다. 그러나 이쪽은 머리를 잘 쓰면 훨씬 편하게 살 수 있을 여지가 있어보여 끙차끙차 중. 임베디드 쪽이 나무 구멍에다 작대기를 사흘 밤낮으로 비벼대며 불을 피울 수밖에 없는 쪽이라면 이 곳은 무려 부싯돌이 있는 느낌이랄까!!!. 가짜 객체라든지도 얼마든지 적용이 가능한 분야라니!!
이쪽에 관련한 끙차끙차 고민거리들은 추후 가끔 포스팅에 보일지도 모르겠다.
이 책의 "Test Driven"은 다른 실용주의 책과는 좀 달리 "손에서 상상할 수 있는 레벨"이라는 게 재미있다.
위의 스포일러도 호기심이 가지만, 정말 공감했던 부분은 Co-work의 중요성이다. 개발자 동료가 또라이라도, 덕후라도, 히스테리 노처녀라도, 혹은 히키코모리라도 이에 굴하지 않고 팀웍을 다지고 모두들 똑똑해지는 게 얼마나 중요한 일인지 강조하는 게 참 맘에 들었다. 아쉽게도 그건 현실에서 백만톤 정도 힘든 일이긴 하지만. 처음부터 어긋난 만남이라는 게 얼마나 무서운지. 일터가 평화로울지 전쟁터가 될지는 이미 구성원에서 XX% 정해진다고 난 믿는다. 아무리 좋은 프로세스/도구가 있어도 사람들이 고집스럽게 이를 무시하고 막나가거나 배째는 경우 결말은 "nice boat"임이 뻔히 보이는 것을(머엉).
대부분의 한국 회사(뿐만 아니라 외국에 있는 회사들도 어느 정도 그렇다고 들었지만,)는 수직적인 성향이 강하여 아래로부터 멋지구리하다고 생각하는 팀웍들을 실험해 볼 여지가 그닥 많지는 않다고 본다. 그래도 지금 버리버리 개발자 레벨일 때 이리저리 "어떻게 하면 정신줄 놓는 일을 덜 만들 수 있을까", "어떻게 하면 일을 확 줄여서 빈둥빈둥 일해도 월급 잘 받아 먹으며 살 수 있나" 잔머리 굴려보고 뚝딱뚝딱 해보는 건 정신/육체 건강에 꽤 도움이 될 듯.
