[서평] 소프트웨어 장인 ★★★★☆

[읽게 된 동기]


 

개발자로써 중급의 문턱에 서있다고 느꼈다. 초급 개발자를 넘어 중급 개발자가 되려면 어떻게 해야 하는지 궁금했다.

 

[한 줄 평]


 

소프트웨어 장인이 갖춰야 할 몇 가지 태도가 내 생각과 일치해 꽤나 기쁘게 읽은 책.

 

[서평]


 

나는 지난 4년간 Android 개발자로써 일했다. IT 업 중 최악이라는 SI, 그 중에서도 가장 힘들다는 금융SI 프로젝트를 하면서 나는 많이 싸우기도, 많이 배우기도 했다.

가장 아쉬움이 남는 것은 제품의 주체였다. 나는 내 제품을 만들고 싶었다. 늘 타회사(갑) 의 제품을 만들다보니 제품에 정을 붙일 수 없었다. 아직도 몇몇 제품들은 꽤나 애정이 남아있지만, 시간이 흐르다보면 내가 만들었던 기능들은 찾아볼 수 없었다. 그렇게 내 흔적들이 지워져가는 것은 꽤나 슬픈 일이다.

 

<프로페셔널, 행동>

 

 

나는 스스로가 프로라고 생각했다. 내가 나를 프로페셔널이라 생각치 않으면 누가 나를 그렇게 봐주겠는가? 또한, 내가 사회에 나와 돈을 받으며 일한다는 사실이 기뻤다. 작은 성취가 있을 때의 그 성취감은 말로 표현 할 수 없었으며, 차근차근 학자금을 갚고 주말마다 치킨을 사먹을 때마다 내가 월급을 번다는 사실이 느껴졌다. 아마 입사 후 1년간 치킨을 주 2회 정도는 먹었을 것이다. 약… 100마리 정도가 되겠다. 어… 200만원인가?

일을 더 빠르게, 잘 하고 싶었다. 입사 당시 나는 팀에서 서열 10위의 막내였는데, 팀이 거대하다보니 내게 일이 떨어지지를 않았다. 몇 개월이 흐른 뒤, 나는 선배들에게 좋지 않은 소리를 듣기 시작했다.

“넌 열정이 없어.” “열심히 좀 해라.” “네가 뭘 했어?” “일? 뭘 믿고 너한테 일을 줘?”

자존심이 상했다. 단언컨대 육체 폭력보다 언어 폭력이 더 아프고 자존심 상했다. 그때부터였다 진짜 프로가 되기 위해 행동 한 것은.

 

고객을 만족시키기 위한 투자는 스스로 해야 한다. 소프트웨어 프로페셔널로 대우받기를 원한다면 프로처럼 행동해야 한다. 이는 스스로를 발전시키는데 자신의 돈과 시간을 들여야 한다는 것이다.

 

내게 열정이 없다는 선배들에게 도전장을 냈다. 기술적인 질문들을 던졌다. 질문을 위해서 공부했다. 2시간 일찍 출근해서 2시간 늦게 퇴근했다. 선배들은 하나, 둘 ‘나도 모른다고!’ 라며 화를 냈고, 그렇게 선배들이 사용하는 기술들 대부분을 익혔다.

일찍 출근하고 늦게 퇴근하는 모습을 보여야만 열정이 있다고 하고, 자신들만큼 알고 있다는 것을 보여줘야만 건드리지 않는 한국의 문화가 씁쓸했다.

그렇게 시간이 흐른 뒤 나는 일이 없다는 불만을 할 생각이 싹 사라졌다. 일이 폭발했다. 내 행동들 때문이 아니었다. 그저 회사에 일이 많아진 것 뿐.

 

그렇게 일을 1년, 2년 하다보니 내 분야에 자신감이 생겼고, 타 파트와의 전쟁에도 발을 담그기 시작했다. 프로젝트에서 물러 터지면 먹히게 마련이다. 그러던 중 몇몇과는 얼굴을 붉히기도 했고, 그렇게 나는 싸움닭이 되어갔다.

 

“세용씨는… 자기 분야에 대한 자부심이 강하네요.”

 

나와 언쟁을 펼치던 한 동료가 내게 말했다. 그게 프로페셔널이라 생각했다. 내 분야는 아무도 건들지 마라! 이렇게 외치며 내가 일을 다 해내면 그게 프로라고 생각했다.

 

<기본기>

 

프로젝트를 하다보면 정말 많은 사람들을 만나게 된다. 하지만 거의 모든 개발자들은 다 나보다 나이가 많았다. 대게 30대 개발자들이었으며, 40대 정도가 되면 관리자로 변신하곤 했다. 물론 50대 개발자들과도 일을 했다.

목소리 큰 사람이 이기는 한국이다. 나는 목소리가 큰 편이었고, 내가 주장하면 대게 무언가를 얻는 편이었다. 하지만 더 목소리 큰 사람들을 만나고 나서야 깨달았다. 결코 좋은게 아니다.

 

코드를 잘 작성하는 것은 소프트웨어 프로페셔널이 가져야 할 최소한의 요건이다.

 

나는 변종 개발자였다. 게임으로 따지면 마검사랄까? 개발자임에도 말 하는 것을 좋아했고, 혼자서 개발하는 것 보다 함께 회의하는 것을 더 좋아했다. 새로운 아이디어나 새로운 기술을 찾고 적용시키는 것을 좋아했고, 동료들이 모르는 것을 알게 되면 기뻤다.

다소 외향적인 성격을 보일 수 있었기에, 타 파트와의 협업에 능숙했다. 개발자에게 업무가 떨어지면 개발을 하는 것이 가장 개발자다운 방법이지만, 나는 타이핑보다 말로써 일하는 것을 즐겼다.

디자인적으로 기능을 풀기도 했고, 기획을 바꾸기도 했다. 이도저도 안되면 영업적으로 푸는 방법도 있었다. 그렇게 이리저리 돌려막다보니 한 프로젝트에서는 부하가 걸렸다. 막을 수 없는 상태가 된 것이다.

 

결국 나는 개발을 해야만 했고, 끙끙 앓은 뒤 해결했다. 하지만 그게 끝이 아니었다. 오픈 전날 다수의 테스트를 통과한 내 코드가 보안에 취약하다는 결과를 받았고, 프로젝트 총 책임자의 칼날이 내 목에 닿았다.

당시 대리였던 나는 신입때도 듣지 않았던 욕설을 들었고, 쥐구멍에 숨고 싶었다. 왜 코드를 이따위로 짰냐며, 한 줄, 한 줄 내 코드를 보는 부장님. 정말 알몸으로 시내 한복판에 서 있는 기분이었다.

아마 그때였을것이다. 내가 상당히 겸손해진것은.

 

 

저자는 장인정신을 강조한다. 쉽게 말해 프로의 마인드다. 늘 더 나은 것을 찾되, 실용적인 마인드를 잃지 않아야 하고. 치열하게 살되, 늘 겸손함을 잃지 않아야 한다.

마치 무림의 고수가 이야기 하듯 ‘맞는 말’ 을 계속해서 한다. 때문에 2/3 지점에서는 좀 지루하기도 했다. 너무 맞는 말만 해서… ㅎㅎ

 

하지만 저자의 말은 아무리 강조해도 지나치지 않는 것들이다. ‘정도 正道’ 랄까?  본질에 충실하고 기본기를 다져라. 늘 공부하고 겸손하라.

 

<본질>

 

본질에 대한 이야기를 읽다보니 한 가지 일화가 생각났다. 내가 운영하는 커뮤니티에서 홈페이지를 만들었는데, 친구들은 가끔 앱을 만들자고 했다. 내가 앱 개발자이니 쉽게 만들 수 있으리라 생각했나보다. 나는 홈페이지의 기능을 말하며 굳이 앱을 만들 필요가 없다고 설득했고, 왜 앱이 필요하느냐고 물었다. 그 친구는 내 설명을 듣더니 이렇게 말했다.

‘음… 아이폰 바탕화면에 이렇게 아이콘이 있어야 들어가기 편해서…’

맙소사… 나는 당장 아이폰 홈 화면에 즐겨찾기를 만들어주었고, 문제는 해결되었다.

 

이게 본질이다. 고객이 도대체 뭘 원하는지를 알아야 한다. 저자는 일을 하달 받아서 코딩만 하는 것은 장인 정신이 아니라고 한다. 이 일을 왜 해야하는지 묻고, 더 나은 방법을 찾고. 그래, 이런류의 말들은 대다수의 성공학 서적에서 많이 이야기하는 것이다. ‘내 일처럼 하라.’ 역시 어느 분야든 높은 위치에 가려면 방법은 똑같나보다.

 

<내가 틀리지 않았던 것>

 

사실 요즘 자신감이 많이 떨어져 있었다. 생각처럼 일이 풀리지 않았고, 확고하다 생각했던 내 비전은 너덜너덜해졌다. 나 스스로도 내가 어디로 걸어가는지 모르겠는 지경이 되었다.

나는 기본기가 부족하고, 해야 할 것은 너무도 많다. 나는 바닥인게다…

 

미리 세운(대부분 잘못 정의된) 계획에 따라 그저 기계적으로 코딩만 하는 것이 아니라, 계획, 일정 및 예산 등의 추산, 요구사항 분석, 팀 구성, 분석, 아키텍처, 제품 릴리즈, 우선순위 조정, 시연 그리고 사용자와 프로젝트 이해 관계자에게 정기적으로 피드백을 받는 단계까지 개발자가 수행하기 시작한 것이다.

 

그런데 저자는 장인정신을 이야기하며 너무도 많은 것을 요구한다. 아니, 코딩은 기본이라며 코딩 외적인 부분에 더 신경을 써야 하는 시대가 왔다고 한다.

하하. 나는 거꾸로인것이다. 나는 기본기는 부족하면서 코딩 외적인 부분에 역량을 쌓았다.

조금은 관점이 달라졌다. 내가 쌓은 것들은 쓸모 없는게 아니었다. 다만, 내가 더 잘해야 하는 것 보다 먼저 익혔을 뿐이다. 더 비틀어서 볼까? 나는 장인정신이 갖춰진 개발자였던 것이다.

 

나는 늘 말이 많았다. 도대체 왜 이렇게 기획을 해? 디자인… 더 편하게 받아야해 가이드 문서를 만들자. 코드 템플릿이 필요하겠어, 주석을 포맷을 통일 하자고. 의견을 많이 내고 대화를 더 하자, 우리 지금 쓰는 공통단 4년도 넘었어 바꿔야 해.

2013년 Google 에서 네트워크 라이브러리 Volley 를 내놓자 나는 혼자 독학을 했다. 홈페이지를 만들겠다며 CentOS 를 공부하고 WordPress 를 공부했다. 금융SI 시장은 인터넷이 다 막혀있다. 아이패드를 가지고 원격 커맨드창을 띄워 스터디를 했다.

결국 아무도 시키지 않았던 그 뻘짓이 Volley 를 이용한 공통단을 만들게 되고, 팀내 서버를 운영하게 되고, 다수의 홈페이지를 WordPress 로 만들게 되었다.

 

왜? 에서 시작하고, 일정관리, 아키텍처에 대한 고민, 스터디 등. 저자가 이야기하는 장인정신에 맞는 태도를 나는 스스로 익혔다. 안타깝게도 당장 소득이 없었기에 나는 이상한 곳에 관심이 많은 놈이라 생각했지만 뒤돌아보니 그 뻘짓들이 내 가치를 높여주었다.

 

이 책 소프트웨어 장인을 구입하면서 사실 내 방향성에 대해 제대로 가르쳐주길 기대했다. 좀 더 나은 방향, 좀 더 빠른 방향을 배울 수 있길 기대했다.

역시, 그딴건 없다. 늘 배움의 자세를 잃지 않고, 천천히 꾸준히 내 길을 걷는 것이 답이다.

해외의 프로젝트들도 우리나라와 별반 다를게 없다는 것을 다시 알 수 있었고, 수많은 개발자들이 현실과 이상 사이에서 씨름을 하고 있다는 것도 확인할 수 있었다.

 

그때 이후로, 아침에 눈을 뜰 때마다 오늘 할 일이 하고 싶어 기대되는 일만 하기로 스스로와 약속했다.

 

왕도는 없다. 내가 옳다고 생각하는 길을 걷는 것. 그게 마스트가 되는 길이다.

 

[인상 깊은 문구]


 

  • 코딩을 시작한 이후 처음으로, 내게 시간을 들여 좋은 코드를 만드는 법을 보여 주는 사람을 찾았다는 사실을 깨달았다. 나를 가르치는 데 기꺼이 시간을 투자하는 사람을 만났다. 무엇보다도 나의 첫번째 멘토를 찾았다.
  • 거의 1년 동안 문서 작업과 다이어그램만 그리다 보니 더는 일을 계속 할 수가 없었다. 상사에게 개발팀으로 돌아가고 싶다고 했다. 일주일 후 나는 다시 개발팀으로 돌아갔고 코딩의 즐가움도 되찾았다.
  • 그때 이후로, 아침에 눈을 뜰 때마다 오늘 할 일이 하고 싶어 기대되는 일만 하기로 스스로와 약속했다.
  • 미리 세운(대부분 잘못 정의된) 계획에 따라 그저 기계적으로 코딩만 하는 것이 아니라, 계획, 일정 및 예산 등의 추산, 요구사항 분석, 팀 구성, 분석, 아키텍처, 제품 릴리즈, 우선순위 조정, 시연 그리고 사용자와 프로젝트 이해 관계자에게 정기적으로 피드백을 받는 단계까지 개발자가 수행하기 시작한 것이다.
  • 코드를 잘 작성하는 것은 소프트웨어 프로페셔널이 가져야 할 최소한의 요건이다.
  • 도요타가 성공할 수 있었던 중요한 요인은 절차를 개선하는 것뿐만 아니라 자동차의 품질에 이미 충분한 역량과 그를 뒷받침하는 노력이 있었기 때문이다.
  • 소프트웨어 장인정신은 마스터가 되어가는 긴 여정이다.
  • 상대에게 배우는 것은 더 나아지기 위한 최선의 방법이다. 블로그에 글을 올리고, 오픈 소스 프로젝트에 기여하고, 작성한 코드를 공개하고, 지역 커뮤니티에 참여하고, 다른 개발자와 페어 프로그래밍을 하는 것은 업계의 발전을 위해 할 수 있는 방법들이다.
  • 아침에 출근해 칸막이에 파묻혀 고개를 숙인 채 그저 지시받은 사항만 해내는 이는 프로가 아니다.
  • 고객을 만족시키기 위한 투자는 스스로 해야 한다. 소프트웨어 프로페셔널로 대우받기를 원한다면 프로처럼 행동해야 한다. 이는 스스로를 발전시키는데 자신의 돈과 시간을 들여야 한다는 것이다.
  • 새로운 개념, 패러다임, 실행 관례를 배우는 것은 특정 기술을 익힐 때보다 훨씬 힘들다. 어떤 경우는 완전히 이해하고 익숙해지는데 몇 년이 걸리기도 한다. 이러한 개념들을 알아두면 새 기술을 배울 때 학습 시간을 크게 단축시키는 장점이 있다.
  • 운전을 처음 어떻게 배웠는지 기억을 떠올리자. 언덕길을 오를 때마다 신호등이 빨간색으로 바뀔까봐 조마조마했다. 익숙해지면 자동차 안에 있다는 사실을 그다지 의식하지 않게 된다. 이제는 목적지로 제대로 가고 있는지에만 신경 쓴다.
  • 펫 프로젝트를 실제 비즈니스로 전환하기는 상당히 고통스럽고 실망만 가득한 일이 되기 쉽다. 나 역시 그러한 시도를 했다. 펫 프로젝트를 비즈니스화 하고 싶다면 비즈니스 자체에 집중하고, 작성된 코드들을 시장이 원하는 방향이 아니라면 얼마든지 버릴 준비가 되어 있어야 한다.
  • 소프트웨어 프로페셔널이 할 수 있는 최대의 실수는 자신이 모르는 것을 모른다고 받아들이지 않는 것이다. 모르고 있다는 것을 인지하지 못한 상태를 ‘2단계 무지’ 라고 한다. 아직 배울 내용이 많음을 인정하는 것은 성숙하다는 증거이고 마스터가 되기 위한 첫걸음이다.
  • 진실은, 우리는 항상 시간이 있다는 것이다. 시간을 최적화 하지 못할 뿐이다. 우리 커리어에는 그다지 중요하지도 않은 다른 일에 시간을 소모하고 있을 가능성이 높다.
  • 우리는 프로페셔널하지 못했다. 우리가 왜 그 일을 하는지 스스로 묻지 않았다. 고객이 실제로 무엇을 원하는지 이해하려 하지 않았고 다른 대안을 제시하지도 않았다.
  • 개발자들이 어떤 기능을 개발할 수 없다고 부정적인 이야기를 할 때 관리자들은 고맙게 생각해야 한다. 좋은 소식은 아니지만 그러한 솔직함으로 인해 더 큰 문제를 피할 수 있다.
  • 좋은 코딩과 관련된 서적들과 도구, 테크닉, 방법론 그리고 웹에서 얻을 수 있는 정보들은 매우 많다. 그럼에도 불구하고 허술한 코드를 만들어 내는 함량 미달의 개발자들로 팀을 꾸린다는 것은 있을 수 없는 일이다.
  • 나는 테스트 주도 개발 방법론에 익숙해지고 레거시 코드에 테스트를 만들어 넣은 이후로는 코드 자체를 디버깅해야 하는 상황이 손에 꼽을 만큼 적었다. 내가 아는 다른 많은 개발자들도 마찬가지였다. 자동화된 테스트를 만들고 활용하는데 능숙한 개발자라면 코드 디버깅을 해야 하는 상황이 매우 드물다.
  • 소프트웨어 장인정신 토론회 중 하나에서, 백지상태에서 시작하는 그런 필드 프로젝트를 선호하는 사람이 있냐는 질문에 거의 모두가 손을 들었다. 반면에 레거시 코드에서 작업해야 하는 프로젝트를 선호하는 사람은 손을 들어 달라고 했을 때는 아무도 없었다.
  • 무언가를 절대적인 진리로 바라보는 것은 바람직하지 않다. 항상 우리가 무엇을 하고 있고 그것을 왜 하고 있는지 질문해야 한다.
  • 요기 베라는 ‘어디로 가고 있는지 모르고 있다면, 결국 가고 싶지 않은 곳으로 간다’ 라는 말을 남겼다.
  • 커리어에서 옳고 그른 것은 없다. 지식은 영원하고 돈과 안정은 영원할 수 없다는 것만은 마음에 새기고 있어야 한다.
  • 다니엘 핑크의 저서 [원동력: 동기부여에 대한 놀라운 진실] 에서 돈은 충족되어야 할 기본 조건이고, 지식 노동자를 움직이는 것은 자율성, 통달, 목적의식 이렇게 세 가지라고 이야기 하고 있다. 돈은 기본적으로 충족되어야 하는 조건이라는 것이 매우 중요하다.
  • 내가 항의하러 갔을 때 그들은 ‘이미 얘기 했지만 그런 거는 시간 낭비라고요. 프로젝트 관리자와 비즈니스 분석가는 전혀 쓸모 없습니다. 그들 스스로도 자기가 뭘 원하는지 모릅니다. 그냥 그 사람들이 직접 시스템을 테스트하게 두면 됩니다. 누가 불평하면 그때 가서 고치면 되고요.’ 컨설팅 회사는 그 문제를 고객사의 IT 부서 고위직까지 이슈화시켰고 결국 거의 팀원 전체가 교체되었다.
  • 유능한 개발자라면 TDD 때문에 개발 일정이 지연되지 않는다. 그것은 진실이다. 논란은 아무런 의미가 없다.
Share:
오세용 Domingo

오세용 Domingo

글쓰는 감성개발자 오세용입니다. IT, 책, 축구, 커뮤니티 등에 관심이 많습니다.