독서록: 소프트웨어 장인

이 도서를 쿠팡으로 받기:
https://link.coupang.com/a/2Yw5D
* 이 포스팅은 쿠팡 파트너스 활동의 일환으로, 이에 따른 일정액의 수수료를 제공받습니다.

---

소프트웨어 장인:프로페셔널리즘/실용주의/자부심
어떻게 하면 더 나은 프로그래머가 될 수 있을까?
 

들어가며

이 책을 읽고 내가 집필중인 글을 일시중단했다.
왜 중단했냐고 묻는다면 부끄러워졌기 때문이라고 할 수 있을까, 오랫동안 숙성된 깊은 생각과 현안이 돋보이는 글을 읽으며 내가 작성한 초안을 돌아보니 괜스레 부끄러워졌다.
마침 고민중인 주제도 담고 있었다. 개발자는 어떻게 성장해야 하는가, 그리고 어떤 개발자가 잘하는 개발자인가. 개발자는 뭘 하는 사람일까? 개발자라고 모두 한 길만 걸어야 하는 걸까? 이 물음에 저자는 "장인이 되어라" 라고 답한다.
 
저자 산드로 만쿠소 의 링크드인:
https://www.linkedin.com/in/sandromancuso
 
아쉽게도 2020년 마지막 이후 활동을 하지 않는 듯 하다.
https://www.codurance.com/publications/author/sandro-mancuso

Publications | Codurance

 

그럼 장인은 무엇일까?

소프트웨어 개발을 대하는 태도, 자신의 일에 대한 관심, 매일같이 활용하는 실행 관례들, 자기계발을 위한 열정, 고객에 대한 존중을 가진 스스로 추구하는 가치와 프로페셔널한 태도를 가지고 있는 사람을 장인이라고 지칭할 수 있다고 한다.
 
이 책에서는 "장인" 이라는 키워드를 다루며 소프트웨어 개발자가 하고 있는 일들에 대해 장인은 어떻게 일을 하는지에 대해 말해준다.
코드만 잘 쓰는게 아닌 개발을 하는것에 있어 거치는 모든 과정을 신경쓰고 정성들이며 피드백하는 것
 
저자에 의한 짧은 정의는

소프트웨어 개발의 프로페셔널리즘을 가진 사람

굳이 내 방식의 한 단어로 말하자면 "정성 가득한 개발자" 라고 볼 수 있겠다.
 
사실 이건 꽤 오래된 개념이다.
 
그럼에도 내가 지금 이 책을 읽고 독서록을 쓰고 있는 이유는
이 책은 개발론이나 기술을 다루는 설명서가 아닌 성경이나 손자병법과 같은 소프트웨어 개발의 병법서와 같은 내용을 다루고 있기 때문이다. 그리고 놀랍게도, 저자는 지금 당장 적용해도 전혀 무리가 없는 내용들을 말하고 있다.(이는 결국 저자의 바램이 2023년 지금도 개발자 커뮤니티에 전달되지 않았음을 의미하기 때문에 슬픈 이야기이다)
 

매니페스토 소개

이에 대하여 소프트웨어 장인 커뮤니티에서는 이런 선언문을 만들었다.
https://manifesto.softwarecraftsmanship.org/

선언 전문

내용을 텍스트로 옮기자면, 이렇다.

소프트웨어 장인을 열망하는 우리는, 스스로의 기술을 연마하고, 다른 사람들이 기술을 배울 수 있도록 도움으로써 프로페셔널 소프트웨어 개발의 수준을 높이다. 이러한 일을 하는 과정에서 우리는 다음과 같은 가치들을 추구한다.

동작하는 소프트웨어뿐만 아니라, 정교하고 솜씨 있게 만들어진 작품을
변화에 대응하는 것뿐만 아니라, 계속해서 가치를 더하는 것을
개별적으로 협력하는 것뿐만 아니라, 프로페셔널 커뮤니티를 조성하는 것을
고객과 협업하는 것뿐만 아니라, 생산적인 동반자 관계를

이 왼쪽의 항목들을 추구하는 과정에서, 오른쪽 항목들이 꼭 필요함을 의미한다.

오랜기간동안 다듬어진 만큼 참 깔끔하기 그지없다.
 

매니페스토 풀이

한눈에 봐도 무슨 말인지 대충 느낌은 오지만 풀이를 통해 더 자세하게 알아보자.

정교하고 솜씨 있게 만드는것

정교하고 솜씨 있게 만드는것은 이런 것들이라고 한다.
 
개발자라면 쉽게 이해할 수 있어야 하고,
숨겨진 버그는 없어야 하며,
높은 커버리지와 신뢰할만한 테스트를 가지고 있어야하고,
명료하고 단순한 디자인과 용어로 기술되어야 하며,
충분한 역할분리 및 모듈화로 기능의 추가 및 수정이 용이해야 하고,
전체 코드 베이스도 적당한 사이즈여야 한다.
 
맞다, "잘" 만들어야 하는 것을 의미한다.
 

계속해서 가치를 더하는것

계속해서 가치를 더하는것에 대해 저자가 인용한 구절이 있다.

보이스카웃에는 캠핑 장소를 처음 발견했을 때보다 더 깨끗하게 남겨두라는 규율이 있다. 이는 소프트웨어에도 똑같이 적용할 수 있다. 코드도 처음 발견했을 때보다 더 깨끗하게 관리해야 한다. - 클린코드의 Uncle Bob

한번 만들고 끝나는 소프트웨어가 아닌 적절한 주기로 계속해서 리팩토링하고, 리뉴얼하여 최신의 이념과 기술을 유지하는 것을 의미한다.
 

프로페셔널 커뮤니티를 조성하는것

블로그에 글을 올리고,
오픈 소스 프로젝트에 기여하고,
작성한 코드를 공개하고,
개발 커뮤니티에 참여하고,
다른 개발자와 페어 프로그래밍을 하는 것
 
서로를 더 성장시킬 만한 사람들과 함께 일하고 지식을 나누며 상대에게 배우는 것, 혼자 일하는게 아닌 함께 일하는 것을 의미한다.
 

생산적인 동반자 관계

고객을 도와 그들의 업무 절차를 개선하고, 좀 더 실현 가능성이 높은 선택지를 제공해야 한다.
불필요한 관료주의를 없애고, 고객의 비즈니스 도메인을 이해하며 그들이 생산하는 가치와 관련된 요구사항에 질문할 수 있어야 한다.
업무 우선순위를 정하고 계획하는 일을 도울 수 있어야 한다.
심지어 소프트웨어 개발이 아닌 방향이 더 효율적이라면 그 방향을 제시할 수 있어야 한다.
"코드와 관련된 일이 아니라면 내 일이 아니다"라고 생각하지 않아야 한다.
 
내가 가장 관심을 가지고 추구하고 있는 항목이다.
나는 요구사항을 그대로 구현하는 개발자가 되고 싶지 않다. 더 나아가 받은 요구사항에 대한 피드백 없이 구현하는 개발자를 싫어한다.
비개발자에게 개발자의 인사이트를 제공하고, 비즈니스를 이해하고 같은 성공을 바라보며, 내가 쓴 코드가 들어간 제품의 고객의 경험까지 생각하는 그런 개발자가 되고 싶다.
 

소프트웨어 장인의 태도

소프트웨어 장인이 되기 위해 어떤 태도를 가져야하는지에 대한 내용이 기술되어있다.
내 기준에서 이해한 내용대로 요약해보았다.
 

끊임없는 배움

기술과 개념, 방법론, 철학에 대한 책을 읽는 것

말 그대로 기술서적과 인문서적, 자기계발서적을 읽는 것이다. 책을 읽는건 독서록을 쓰고있는 나도 느끼고 있지만 알고보면 생각보다 도움이 된다. 생각보다라고 표현한 것은 내가 "책은 개발실력에 별 도움이 안된다" 라고 생각하고 있었기 때문이다.
 
하지만 아주 최근에 생각이 바뀌었다.
물론 책을 읽어서 그런것도 있지만

[100일 리뷰] 책 읽는 습관이 무엇을 바꾸어 놓았는가

동료와 진지하게 스터디에 참여해서 기술서적을 정독해본 경험, 그리고 책을 읽으며 얻는 명상하는 효과는 도움이 된다.


다른 사람들의 블로그를 찾아보고 내 블로그에도 글을 써보는 것

블로그는 참 쉬우면서도 어렵다. 회사를 다니면서 블로그 글을 꾸준히 쓴다는 것 만으로도 나는 내 마음속으로 높은 점수를 준다.
그리고 나 스스로에게도 도움이 많이 되고 있다. 제대로 이해했는지 알기 위해서는 다른 사람에게 설명을 해보라는 말이 있듯이 글을 쓰기 위해 준비하고 정리하는 과정에서 이해도가 그 전과 비교하여 많이 올라간다.
 

기술 관련 미디어를 구독하고 트렌드를 파악하는 것

개발자에게 트렌드를 아는 것은 중요한 일이다. 물론 트렌드에 취해서 모든걸 갈아엎으려는 것만 아니라면 말이다.
요즘은 구독컨텐츠가 참 잘되어있다. 나는 Github Explore 를 이용한다.
https://github.com/explore

Explore GitHub

 
이 또한 블로그 글을 쓰면서 알게 된 기능인데, 거의 모든 개발자가 깃헙을 사용하는 만큼 트렌디하고 정확한 내용을 받아볼 수 있으니 추천한다.

Digging Github, 우리가 어쩌면 몰랐던 GitHub의 여러 기능들

 

SNS 를 통해 나의 길을 먼저 걸은 리더를 팔로우하는 것

뭐 내가 이 책을 읽고나서야 깨달은 바이기도 하다. 내 고민은 높은 확률로 이미 누군가 수십년전에 마친 고민일 수 있다.
 

끊임없는 훈련

코딩카타를 만드는 것

다들 한번쯤 개발자로써 취업하기 위해 코딩 테스트를 준비한 기억이 있을 것이다.
물론 나는 거의 없다. 라떼는 코딩 테스트가 정론이 아니었고 CS 지식과 이론에 대해 인터뷰하는 방식이 주류였다.
언제든 움직일 수 있도록 매사에 근육을 풀어놓는다고 생각하면 된다.
 
아무튼 코딩카타를 해볼 수 있는 사이트는 다음과 같다.
- https://www.acmicpc.net/ (백준 알고리즘)
- https://school.programmers.co.kr/learn/challenges (프로그래머스)
- https://codingdojang.com/ (코딩도장)
- https://level.goorm.io/ (구름LEVEL)
 

펫 프로젝트(토이 프로젝트)를 만드는 것

이건 누구든 반박할 수 없을 것이다. 토이 프로젝트를 만든다는 것은 그만큼의 경험을 더 해보았다는 것과 동일하다.
특히 토이 프로젝트에서는 효율적인 것과 실무에서 쓸 수 없는 최신기술과 같은 멋진 영역들을 다뤄볼 수 있다는 점에서 개발을 취미로 가진 많은 개발자들에게 정말 좋은 장난감이자 훈련법이다.
 
이 작고 귀여운 프로젝트들을 정말 쉽게 퍼블리싱할 수도 있다. 예시로 프론트엔드 개발자들에게는 Github Pages 가 있고, 백엔드 개발자들에게는 fly.io 가 있다.
 

개발자용 서비스 헤로쿠 “무료 플랜 단계적 폐지” - 테크레시피

(안타깝게도 올해부터 Heroku 의 무료플랜은 폐지되었다. 안돼 나의 헤로쿠...)
 

오픈 소스에 기여하는 것

개발자들이 다른 직군들과 다르게 정말 특이하다고 생각되는 점. 자신들의 자산이라고 생각할 수도 있는 코드를 공개한다는 점이다. 심지어 프로젝트 자체를 오픈해버리기도 한다! 이런 공유문화는 개발자 커뮤니티의 발전에 굉장한 도움이 되었다.
오픈 소스에 기여하는 것은 내가 나의 기술과 시간을 기여하여 개발자 커뮤니티 발전에 이바지한다는 의미에도 있지만 오픈 소스에 함께하는 다른 개발자들의 코드와 정신을 보고 배울 수 있다는 점에서 큰 도움이 된다.
 

페어 프로그래밍을 하는 것

관리자들이 정말 싫어하는 행위(ㅋㅋㅋ), 하나의 일에 다수의 인건비를 들이는 일이라고 생각할 수도 있겠지만 페어 프로그래밍은 개발자의 객관화와 개발팀 전체 성장에 있어 굉장히 중요한 일이다.
페어 프로그래밍을 하면서 자신의 코드와 아이디어에 대해서 즉각적으로 피드백을 받고 이에 관해 다시 한번 생각해볼 기회가 생긴다. 새로운 것을 배우거나, 내가 관성적으로 해오고 있던 실수를 찾을 수도 있다.
또한 위에도 말했듯이 개발팀에 속한 구성원들의 코딩 스타일이 표준화되어 새로운 개발자가 입사하더라도 코드의 퀄리티와 모양을 일치시켜 유지보수에 큰 도움을 줄 수도 있다.
 

끊임 '있는' 일

커뮤니티에 참여하는 것

매니페스토에서 언급된 부분이다. 커뮤니티에 속한 사람들의 지식을 공유받을 수 있으며 혼자가 아니라는 정서적 안정감을 얻을 수 있고 완전 다른 산업의 정보를 접해 인맥과 시각을 넓힐 수도 있다.
 
나는 일에 집중하여 3배 이상의 성과를 내고 싶었고 내가 하고 있는 비즈니스를 진정으로 이해하고 싶어 토스 입사를 기점으로 블로그와 커뮤니티를 끊었었는데, 4년이 지난 지금은 이것을 굉장히 후회한다.
 

모르는 것을 미리 아는 것

생각보다 우리는 우리가 모른다는것을 모른다. 예상할 수 없는 문제는 발생하기 마련이고 언제나 그 문제를 어떻게 해결하는지 알고 있을 수는 없다. 만드는 행위를 잠시 중단하고 뭔가 예상되는 문제는 없는지, 빠진건 없는지, 사용중인 기술의 최신 근황은 어떤지 점검해볼 필요가 있다.
 

잠시 내려두는 것

일도 중요하지만 일에 매몰되어 버린다면 평면적인 사람이 되어버린다. 뭔가 새로운걸 배우거나 새로운 만남을 가지는 것은 의외의 기회를 만들기도 하고 지금 하는 일에 간접적으로 도움이 되는 경우도 많다. 그게 아니더라도 쉬는것은 우리 몸에게 반드시 필요하다.
 
어디서 읽었는지 기억이 안나지만 아마 교보문고에서 관심가는 책들을 이것저것 넘겨보며 본 구절일 것이다.

사람은 누구나 제 일이 아닌 딴짓을 한다. 하지만 꼭 딴짓이 나쁘기만 한 행위는 아니다. 딴짓을 할 때는 "딴짓 핫스팟" 을 켜고 있다고 생각하면 된다. 이 핫스팟이 다른 핫스팟과 겹치는 순간 새로운 기회를 만나게 된다.

뭐 이런 내용이었다.
 

'아니오' 라고 말할 수 있는 것

사람들은 부정하는 것을 참 무서워 한다.
사실 피고용자의 입장에서 당연하긴 하다. 을의 입장이니 목소리를 내는게 정말 힘들겠지.
하지만 피고용자와 고용자는 서로의 전문성을 취하려는 동등한 입장이고 우리는 목소리를 내어야 할 의무가 있다는 점을 알아야 한다.
 

무너질게 뻔한 탑쌓기

누가봐도 일주일은 걸릴 일을 하루를 요구한 클라이언트에게 할 수 있다고 해놓고 밤을 새워 완성했지만 당연히 송송 뚫려있는 구현과 버그, 심지어 장애까지 터지니 멘탈도 함께 터진다.
 
물론 빠른 구현이 필요한 일에는 최대한 빠르게 하는게 맞다. 대표적으로 프리토타이핑이 여기에 속한다.

독서록: 아이디어 불패의법칙

 
하지만 실무에는 그렇지 않은 일들이 대부분이다. 하지만 아쉽게도 기술 베이스가 없는 PM 들은 얼마나 걸릴지에 대해 제대로 예측하지 못하고, 심지어 예측 자체도 하지 않은채로 제시하는 경우도 있다. 이걸 개발자가 받아들고는 소심하게 아무말도 못하고 받아들이고 문제를 만드는 것이다. 이런 개발자는 프로페셔널하다고 할 수 없다.
 
개발자에게는 비개발자, 혹은 코드베이스를 모르는 사람들을 위해 피드백해줄 의무가 있다. 이미 불가능한 것을 알고 있는데 "노력해보겠다" 라고 말하는 것은 전혀 도움이 되지 않는다.
 
요구사항을 제대로 해석하고 파악할 시간, 실제로 코드를 작성할 시간, 테스트를 작성해 넣을 시간, 코드 리뷰를 충분히 받을 시간을 모두 포함한 일정을 산출해서 요구사항을 제시한 사람에게 "그 일정은 어렵고, 확인해본 결과 이정도 시간이 걸릴 것이다." 라고 말해야 한다.
 
물론 당장은 능력없는 사람으로 평가될 수도 있다. 하지만 이렇게 완성한 무너지지 않는 우리의 탑과 빠르게 완성한 다른 금이가고 무너져내리는 탑을 보게되는 시점은 반드시 올 것이다.
 

개발하지 않기

의외로 꽤 자주 개발 요구사항으로 내려온 프로젝트가 개발하지 않고도 해결할 수 있는 방법이 있는 경우가 생긴다. 
위에서는 일정을 거역하라고 했지만 사실 당연히 충분히 검토된 일정은 비즈니스적으로 중요한게 맞다. 그렇다면 일정안에 할 수 있는 방법을 찾아야 함인데,
 
고객 만족을 위해 기능을 추가하는 것이 아닌 기능을 제거하는 것이 진짜 답일 수도 있고
새로운 플랫폼을 개발하는 것보다 전담할 사람을 한명 더 고용하는것이 더 효율적일 수도 있다.
 
자동화 우선순위가 그렇게 높지 않은 기능은 당장 개발하지 않고 수동으로 임시 처리한 다음 차차 자동화해나가는 방향이 옳을 수도 있다.
 
 

장인 채용하기

혹은 장인이 될 재목을 채용하기.
 
스스로 훌륭한 소프트웨어 장인이더라도 팀의 구성원이 이를 따라주지 않는다면 매우 힘들어질 것이다. 이를 저자도 깊게 느껴왔는지 채용에 대해서도 꽤 심도있게 다루고 있다.
 

스택나열이 아닌 니즈소개하기

요즘은 그나마 좀 덜한 것 같지만 소프트웨어 개발자의 채용 공고는 다들 참 딱딱하다.

자격요건
ㆍ관련 업무 경력 3년 이상이거나 그에 준하는 실력을 지닌 분
ㆍSwift 언어 중급 이상, 언어에 대한 이해 필요
ㆍStatic Library 개발 경험이 있는 분
ㆍ해외 여행 결격 사유가 없는 분
우대사항
ㆍiOS framework 개발 경험자
ㆍPython 을 활용한 타 바이너리 구조 변경 및 수정 경험이 있는 분
ㆍiOS 빌드 시 구조, 빌드 된 ipa에 대한 이해가 있으신 분

이 짤이 나오게 된 것도 그와 같은 맥락이라고 생각한다.
 
그 시절에는 그냥 언어를 다룰 수 있기만 하면 된다는 생각으로 채용을 한게 아닐까 싶다.
이건 마치 내 상가가 있는 부지의 재개발 건설사를 건축업 허가를 가진 아무나 랜덤으로 배정하는 것과 다를게 없다.
 
어떤 일을 하는지, 어떤 가치를 추구하는지, 어떤 능력을 기대하는지를 제대로 써놓지 않는 채용공고는 지원하는 개발자에게도, 채용하는 회사에도 큰 시간낭비를 만든다. 특히 개발자들은 일을 즐기는 케이스가 참 많은데, 그리고 즐기기 때문에 시키지 않아도 지들 스스로 역량을 키우고 성장하는 이런 개발자를 뽑는 것을 원할텐데 딱딱한 공고는 이것을 전혀 담고있지 않아 이 좋은 개발자들에게 전혀 흥미롭지 않다.
 

사내추천 받기

좋은 사람 옆에는 좋은 사람이 있다. 장인이 선호하는 동료는 장인이다. 겨우 이력서나 포트폴리오 몇장을 보거나 인터뷰 몇시간 하고 판단할 수 있는 정보보다 몇년 넘게 같이 일해본 사람의 정보가 더 값지다. 또한 이들의 시너지는 묻지 않아도 좋을 것이다.
 

커뮤니티 활용하기

소프트웨어 장인은 커뮤니티를 활용한다. 채용하는 사람도 커뮤니티를 활용하지 말라는 법은 없다.
소프트웨어 장인이 있는 커뮤니티를 후원함으로써 그들의 커뮤니티를 지원할 만큼 관심이 많고 생태계에 도움이 되는 회사라는 점을 어필한다.
꼭 일방적인 후원이 아니더라도 팀의 구성 개발자 또는 회사가 직접 커뮤니티에 참여하는 방향으로도 어필할 수 있다.
 

인터뷰 잘하기

좋은 인터뷰 경험과 나쁜 인터뷰 경험을 정의하라고 한다면 나는 이렇게 말할 것이다.
 
좋은 인터뷰는 끝나고 재밌는 대화였다는 느낌을 받는 인터뷰이고
나쁜 인터뷰는 끝나고 합격이던 불합격이던 인터뷰 결과를 예측하게 되는 인터뷰라고
 

마인드 맵핑

이 책에서 가장 인상깊었던 부분은 인터뷰과정에서의 마인드맵핑 메모이다.
인터뷰를 진행해본 사람들은 다들 느꼈겠지만 준비된 질문만 하는 인터뷰는 존재하지 않고 존재해서도 안된다.
준비된 질문이 있다면 그것은 이후 질문을 위한 씨앗이고 이 씨앗을 뿌렸을 때에 인터뷰이가 주는 답변을 따라 여러 질문들을 던지게 된다.
 
나는 왜 이게 마인드맵과 동일한 형태의 진행이었다는 것을 몰랐을까?
앞으로 기회가 생긴다면 써먹어보고 리뷰를 올리겠다.
 

잘못된 인터뷰

책에서는 잘못된 인터뷰 방식을 설명해준다.
 

거만한 인터뷰어

인터뷰이는 인터뷰어와 동등하다. 그리고 구직자와 회사도 동등하다.
인터뷰어가 높은 사람이라고 착각한 나머지 거만하거나 고압적인 태도로 인터뷰를 진행하는 것은 앞으로 파트너가 될 수도 있는 인터뷰이에게 굉장한 실례이고 이것이 인터뷰에 도움도 되지 않을 것이다.
 

스핑크스 빙의해버린 질문

냉장고에 코끼리를 넣는 시대는 이미 끝났다. 이런 종류의 질문을 해왔던 구글도 별로 효과가 없음을 깨닫고 이미 그만뒀다고 한다.
이 질문에 대한 답변으로 명확하게 평가할 수 있을지도 수수께끼고 당연히 좋은 개발자인지에 대해 판단할 수도 없다.
 

나도 모르는 질문

놀랍게도 실제로 겪어본 케이스이다. 인터뷰어도 답변할 수 없는 질문을 리스트에 있다고 해버린다. 최악이다.
 

인터뷰이 가르치기

물론 모르는 개념을 가르쳐주는건 좋지만 "가르치려 드는" 건 문제다.
인터뷰 자리는 서로를 알아보기 위해 주어진 시간이고 이 시간을 인터뷰어의 생각을 주장하기 위해 쓰면 절대 안된다.
 

인터넷 끊기

아직도 이런 회사들이 있더라, 21세기에 이건 말도 안된다.
개발자는 주어진 환경에서 가장 최상의 효율을 낼 수 있고 회사는 최상의 효율을 뽑아내는 것을 확인해야 한다. 물론 망분리 환경에서 코딩해야 한다면 말이 좀 다르겠지만 그게 아니라면 실무과 동일한 환경을 제공해야 한다.
 

종이에 코딩하기

이하동문, 대체 왜 이러는 걸까
 

알고리즘 풀게하기

생각보다 소프트웨어 개발에 알고리즘은 중요하지 않다.
물론 실무에 사용되는 알고리즘에 대한 것이라면 옳지만 코딩카타 사이트에서 긁어온 알고리즘 문제는 개발자를 평가하는데에 크게 도움이 되지 않는다.
 

전화 인터뷰하기

전화를 할 때는 제대로 된 대화보다 딱딱한 질문과 답변이 이어질 가능성이 높다.
너무 지원자가 많아서 시간이 진짜 모자랄때나 사용하자, 혹시 사용하더라도 인터뷰의 전처리 과정으로 사용하자
 

팀에 적용하기

채용에서도 강조했지만 장인은 구성원들도 장인으로 만들기 위해 노력해야 한다.
 
그에 앞서 저자가 팀을 바꾸기 위해 걸어오며 겪어왔던 부정적인 사람들, 그러니깐 회의론자들을 말한다.
부끄럽겠지만 아무도 보지 않으니 여기서 내가 속하는 타입이 있는지 체크해보자.
 

회의론자들

특정 도구나 방법론을 적용하지 않는 이유가 그냥 몰라서

그러한 것이 존재하는지도 모른다. 무지에 대한 본능적인 두려움 때문에 제안은 일단 거부부터 하고 본다.
심지어 제안했을때 적극적으로 배우려는 태도도 보이지 않는다. 이 사람이 몰랐던 이유가 보이기 시작한다.
 

자신감이 부족하여 스스로 결정을 내리지 않으려 함

어떤 결정을 내리기에 자신의 경험이 충분하지 않다고 생각한다. 중요한 결정들은 더 똑똑하고 경험 많은 개발자들에게 맡기려 한다.
사실 내가 이랬다. 아무래도 뛰어난 사람들이 모인 조직이다보니 스스로 너무 작아보였고 나보다 더 잘하는 사람이 있어보였다.
하지만 그건 기분탓이었고 알고보니 나도 충분히 할 수 있는 일이었다. 이미 늦었지만
 

합리적인 이유가 없는 논쟁을 위한 논쟁

논쟁을 좋아하고 지속적으로 자신을 증명하려 든다. 분명 더 합리적임을 알고 있음에도 새로운 환경에 들어 고생하는 것보다 논쟁을 통해 이김으로써 기존체제를 유지하는것이 더 쉽다고 생각한다.
 

과거에 도입해보았으나 실패한 경험을 가짐

안타까운 케이스이다. 이미 해봤고 실패한 경험을 가지고 있기 때문에 굳이 고생을 하지 않으려 한다.
더 안좋은 케이스는 이 실패경험으로 상대방을 설득하려는 것이다. 이럴때는 노련한 경험자를 데리고 빠르게 도입하여 이 불쌍한 사람에게 성공겸험을 안겨주어야 한다.
 

너무 바쁘기 때문에 새로운 시도를 하지 못함

물론 진짜 바쁜 경우도 있겠지만 대부분 효율적이지 않은 업무로 바쁘다. 더하여 새로운 도입이 이 바쁨을 해결해줄 수도 있다. 이들에게는 지금 바쁜것이 진짜 바쁨이 아니라는 것을 설득할 필요가 있다.
진짜 바쁜 경우는 이들이 아니라 인사결정권자를 설득해야 한다. 채용을 요구하거나 절대 불가능하다면 대우라도 올려주거나
 

상사인데 비 개발 베이스

우리나라에서 굉장히 흔한 케이스이다. 개발적 지식이 없는 귀막힌 상사를 만나면 그만큼 난처한 상황이 없다. 결정권은 가지고 있는데 설득하기 힘든 경우 이들의 언어로 말해야 한다. "자동화 도구를 만들자" 가 아닌 "프로젝트 운영비용을 줄이자" 로 말해야 하고, "TDD를 적용하자" 대신 "위험비용을 줄이자" 로 말해야 한다.
 

그냥 내가 싫은가봐

뒤를 돌아보자, 나의 인간 관계는 어땠는가. 개발자이기에 앞서 팀원이고 사람이기 때문에 감정적인 다툼이 일어날 수도 있다.
일단 해결하고나서 좋은 개발팀을 만들자
 

흘러가는대로 사는 사람

뭐가 어떻게 되던 아무 상관을 하지 않는다. 이들은 쉬운것 같으면서도 정말 위험할 수 있는게, 제안을 받아들인 것 같아도 제대로 이해하지 않고 성의없게 구현하여 결과적으로 좋은 아이디어를 나쁜 아이디어였던 것 처럼 만들어버릴 수 있다는 것이다.
 

회사에게 피해를 받고 있다고 생각함

고과나 급여, 복리 후생 등에서 불공정한 대우를 받고 있다고 생각하고 이것이 코드에 반영된다. 내 회사처럼 생각하지 않기 때문에 당연히 정성은 들어가지 않고 더 위험한 경우에는 복수하려는 생각에 코드를 의도적으로 망쳐놓을 수도 있다.
 

무능력한(멍청한) 사람

이 케이스도 안타깝다. 이들이 개발자에 적성이 맞지 않아 발생한다. 아무리 열심히 해도 깨우치질 못하고 딴소리만 한다. 열심히 하는게 보여서 뭐라고 하지도 못하겠다. 딴 일을 해보라고 권유할 수도 없고 난처하다.
 

자존감이 너무 높은 사람

이들은 자신이 모든것을 알고 있다고 생각한다. 가장 높은 지위를 차지하고 있다고 생각하며 자신의 아이디어가 아니면 나쁜 아이디어로 취급한다. 나의 실패는 있을 수 없으며 설령 있더라도 나의 지시를 제대로 따르지 않은 동료탓이다. 이들은 높은 확률로 코드를 직접 작성하지 않는다. 하지만 자신의 존재를 증명해야하기 때문에 새로운 기술 약어를 외우고 기술 스택을 정의하는 일을 도맡는다. 물론 그 일로 실무와 관련 없는 비효율적인 가이드가 탄생한다.
 

해고될까봐 두려운 사람

내가 사용하고 있는 기술 대신 다른 기술을 사용한다면 내 전문성이 떨어지기 때문에 해고될 것이라고 생각한다.
 

특정 기술의 팬이 된 사람

겪어봤다. 골치 아프다. 스스로 트렌드에 민감하다고 말한다. 특정 기술의 장점에 취해서 실제 업무 상황에 대한 합리적인 설득과 토론이 전혀 통하지 않는다.
 

본격적으로 적용하기

본격적으로 팀에 소프트웨어 장인정신을 불러오는 것은 하루만에 이루어지지 않는다.
이것은 차근차근 절차적으로 진행되어야 하며 안정적이게 기틀부터 쌓아올려야 한다.
 

신뢰를 쌓는다.

다른 사람들을 설득하기 위해서는 우선 믿음직한 사람이어야 한다.
프로젝트에 대한 열정을 먼저 보여주어야 하고 나라면 이 일을 할 수 있을 거라는 믿음을 주어야 한다.
또한 팀원들을 무난히 이끌 수 있다는 자신감도 보여주어야 한다.
 

전문성을 확보한다.

무언가를 도입하기 위해서는 나부터 제대로 알아야 한다. 새로운 기술의 도입은 초기비용이 들게 된다. 단골 멘트로 들고오는 "비용이 너무 많이 든다" 에 대하여 변화 후에 확실하게 더 나은 미래가 있을 것임을 가르치고 설득할 수 있어야 한다.
전문성은 회의론자들을 이길 수 있는 무기가 되어주기도 한다.
 

모범을 보인다.

기술을 도입할 때에 태도에 대한 변화까지 필요하다면 직접 보여주면서 따라하게 하는 것이 가장 좋은 방법이다.
처음 해보는 것에 대한 두려움도 옆에 앉아 페어 프로그래밍을 하는 방식으로 해결할 수 있다. 직접 기술을 시연하고 멘토링까지 도맡아서 해준다면 밑져야 본전이고 차마 거절하기도 힘들어질 것이다.
 

신중하게 싸울 곳을 정한다.

혼자서 회사 전체를 상대할 수는 없다. 작은 프로젝트, 조직부터 점진적으로 설득하고 바꾸어 나가는 것이 더 쉽다.
정말 의미 있는 곳에 노력을 집중하고 더 빨리 가치를 보여줄 수 있는 곳에서 싸움을 시작하자.
 

점진적으로 반복하고 관찰하고 수용한다.

애자일과 같다. 도입하고, 잘 적용 되었는지 확인하고, 효과가 좋은지 리뷰한다. 나 조차도 틀릴 수 있다. 내가 생각한 것과 같은 방향으로 가고 있는지, 혹시라도 내가 틀림을 확인한다면 고집부리지 않고 내려놓을줄도 알아야 한다.
 

마무리

요약은 여기까지다. 이후에는 자신의 커리어와 개발하는 방법에 대한 이야기들이 있다.
내가 인상깊었던 부분들을 요약했지만 꽤나 많은 내용들을 가져오게 되었다.
 
나는 소프트웨어 장인인가에 대해 주저 없이 아니라고 말할 수 있겠다.
그리고 내가 추구하는 메이커의 길에서도 아직 걸어야 할 길이 천리길이다.
 
이 책은 개발자가 아닌 사람들이 읽어도 진심으로 일하는 방식에 대해 고민하게 만들 것 같다.
마지막으로 이 책을 추천하고 빌려주었던 동료분에게 감사하다는 말씀을 드리며 글을 마무리하겠다.