[IT/리뷰] 소프트웨어 장인

소프트웨어 장인 : 네이버 도서 (naver.com)

소프트웨어 장인 : 네이버 도서

무슨 책을 읽을까 찾아보다가 '로버트 C. 마틴'을 보고 바로 집었다. 이 책은 다른 책에서도 나왔던 '소프트웨어 장인정신'에 대해서 다룬다. 책의 부제는 '프로페셔널리즘/실용주의/자부심'이다. 책의 내용과 정확히 부합하는 부제라 생각한다.

저자가 그동안 개발자로서 일을 하면서 경험한 장인 정신에 대해 다룬다. 일반적인 개발자가 아닌 장인으로서의 태도를 가질 것을 강조한다. 장인 정신이 무엇인지, 장인으로서의 태도는 어떤 것인지, 직장에서는 어떻게 해야 하는지, 프로젝트에서는 어떻게 해야 하는지, 직장에 문화를 어떻게 바꿔야 하는지 등에 대해서 다룬다.

뿐만 아니라 인재 채용과 직장을 구하는 과정에서는 어떤게 올바르고 올바르지 않은 것인지 말한다. 특히 잘못된 면접 방식은 다 우리가 경험해 오던 것이다. 올바른 면접 방식은 신선한 충격이었고 많은 것을 깨닫게 해줬다.

 

다른 자기 계발서와 같은 느낌이다. 읽고 나서 변화해야겠다는 다짐을 했고 어떤 식으로 변화를 해야 할지 고민하게 만드는 책이었다.

이전에 다른 책들에서도 느꼈지만 이 시절의 개발자들의 책을 읽다 보면 지금도 적용되는 내용도 많고 그러다보니 내 자신을 되돌아보게 하는 내용이 너무 많다. 나도 장인의 태도를 갖고 장인 정신을 갖고 성장해 나가야겠다고 생각했다.

 

아래는 책의 내용 중 필요하다 생각했던 일부를 간략하지는 않지만 정리를 했다.

---

소프트웨어 장인정신과 애자일은 상호 배타적인 것이 아니며 상호 보완적이다. 애자일은 조직과 비즈니스에 새로운 사고방식을 제공한다. 이는 기업의 반응속도를 높이고 기민하게 하여 기업이 올바른 일을 하도록 돕는다. 소프트웨어 장인정신은 개발에 있어서의 프로페셔널리즘이다. 가슴에 품는 일종의 이념으로, 여러 기술적 실행 관례를 활용하고 정교하고 솜씨 있게 짠 코드의 중요성을 강조말과 동시에 코딩을 넘어서 고객의 더 많은 부분을 도울 것을 강조한다. 즉, 개발자와 기업들이 일을 올바르게 수행하는 것을 돕는다.

많은 기업들이 애자일의 절차적 부분에만 관심을 기울이고 기술적 실행 관례는 무시하는 것이 현실이다. 애자일 매니페스토만 보더라도 '절차와 도구보다는 개성과 화합을' 중요시하고 있지만, 실제 애자일 전환은 절차와 도구로 끝나버린다. 완전한 애자일 전환을 위해서는 프로페셔널 소프트웨어 개발자들이 필요하다.

 

짧은 정의는, 소프트웨어 장인정신은 소프트웨어 개발의 프로페셔널리즘에 대한 것이다. 실제로는 정의 의상의 의미가 있다. 어떤 이념이나 마음가짐에 더 가깝다. 자신이 하는 일에 주인의식을 갖고 프로페셔널하게 행동하고, 고객이 원하는 것은 무엇이든 달성할 수 있도록 돕는다. 다른 개발자에게 배우고 자신의 지식을 나누며 경험이 부족한 개발자들을 멘토링하는 것들이다. 이런 가치를 두고 있다면 그 사람은 소프트웨어 장인이다.

 

소프트웨어 장인정신 매니페스토

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

이 매니페스토에 대해서 몇 가지 비판이 있다. 애자일 매니페스토와 달리 그저 좋기만 한 내용들이라 반대할 이유가 없다는 점이다. 예를 들어 문서를 남기는 것이 중요하다 생각하는 사람은 '방대한 문서 작업보다는 동작하는 소프트웨어를'이라는 애자일 매니페스토의 내용을 받아들이기 힘들다. 하지만, '방대한 문서 작업보다 동작하는 소프트웨어'가 더 중요한 사람이라면 '정교하고 솜씨 있게 만들어진 소프트웨어'를 반대할 이유가 없다.

즉, 애자일 가치에 동의하는 사람이라면 소프트웨어 장인정신 매니페스토에 반대할 사람이 없다. 

 

내 커리어의 주인은 나다.

집에 물이 새서 배관공을 불러야 한다고 해보자. 전문가를 찾아갈 때는 어떤 문제를 해결하기 위해서다. 그 전문가가 당신에게 "최신 기술 서적을 사주세요. 교육 프로그램을 보내주세요."라고 한다면 어떨 것 같은가?

고객을 만족시키기 위한 투자는 스스로 해야 한다. 고객은 프로페셔널의 교육이 아닌 그의 지과 기술에 대한 돈을 지불하는 것이다. 프로페셔널로 대우받기를 원한다면 프로처럼 행동해야 한다. 스스로를 발전시키는 데 자신의 돈과 시간을 들여야 한다. 나 자신의 커리어의 주체로서 언제, 무엇을 배울지를 스스로 결정해야 한다.

 

자기 계발이 가능한 종류로는 책에 소개된 것들은 다음과 같다.

• 독서
  • 특정 기술에 대한 서적 : 프레임워크나 프로그래밍 언어 또는 소프트웨어 이용 방법을 급하게 알아야 할 때
  • 특정 개념에 대한 서적 : 커리어를 진전시킬 때 필요한 기초를 쌓을 수 있는 책으로, 새로운 개념이나 패러다임, 실행 관례들을 소개 (TDD, DDD, OOD, 함수형 프로그래밍 등)
  • 행동양식에 대한 서적 : 효율적으로 일할 수 있는 방법 또는 일반적 상황에서 프로페셔널이 될 수 있는 방법 (애자일 방법론, 소프트웨어 장인정신, 린 소프트웨어 개발, 심리학, 철학, 경영 등)
  • 혁명적 서적(또는 고전) : 일하는 방식이나 개인의 가치관을 바꾸는 책 (<실용주의 프로그래머>, <The Mythical Man-Month>, <GoF>, <테스트 주도 개발>, <익스트림 프로그래밍>, <소프트웨어 장인정신>, <클린 코더>, <리팩토링> 등)

• 블로그
• 기술 웹사이트
• 소셜 미디어 : 트위터 등을 통해 팔로우할 리더를 찾자
• 끊임없는 훈련
  • 카타 : 작은 훈련용 코딩을 말하며, 주로 카타를 이용해 익숙하지 않은 TDd, 다른 개발 언어, 새로운 프레임워크 등을 연습한다.
  • 펫 프로젝트 : 취미생활과도 비슷한 나만의 소프트웨어 프로젝트
  • 오픈 소스
  • 페어 프로그래밍
• 사회 활동 (프로페셔널 커뮤니티)

 

커리어를 위해 업무 외 시간에 학습과 훈련을 게을리하지 않는 것이 중요하다 이야기했다. 그러면 항상 "그럴 시간이 없다."라는 대답이 돌아온다. 어쩌면 맞다. 그것은 그렇게 믿기로 결정한 것이고 그에 따라 현실이 되었다. 시간을 최적화하지 못한 것이다. 어제 하루를 얼마를 낭비했고 얼마를 생산적으로 보냈는지 생각해 보자. 시간이 부족한 점을 게으름의 변명으로 이용하지 말자. 아예 SNS를 하지 말고 웹서핑을 하지 말라는 것이 아니라 절제하자는 것이다.

 

빡빡한 일정에 부딪히는 상황은 흔히 일어난다. 빡빡한 일정을 다루는 가장 좋은 방법은 모든 필요한 것을 분석해 가능한 위험과 우려사항을 터놓고 관계자들과 소통하는 것이다. 불명확하거나 불편한 사실들, 걱정되는 사항들은 최대한 이른 시점에 문제제기해야 한다. 주어진 일정을 준수할 수 있을지에 대해 어느 정도 자신감을 갖고 있는지 꾸준히 표명해야 한다.

"노력하겠다."는 말은 "그렇게 되게 하겠다."와 같은 말이다. 그게 아니라면 평소에는 열심히 일을 하지 않았다는 것을 고백하는 것 밖에 안 된다.

우리는 실망시키지 않기 위해 말하는 '네'는 거짓말에 지나지 않는 것을 알아야 한다. 단, 항상 '아니요'라고만 얘기하는 것은 프로다운 태도가 아니다. '아니요'에는 하나 이상의 대안이 따라와야 한다. '아니요'라고 대답하기 전에 문제를 분석해 대안이 있어야 한다. 항상 실용적인 대안을 찾아낼 수 있는 것은 아니다. 그래도 최소한 브레인스토밍은 해봐야 한다.

 

훌륭한 관리자는 자신의 개발팀의 일부다. 관리자와 개발자 사이에 갑과 을의 관계는 없다. 개발자들이 어떤 기능을 개발할 수 없다고 할 때 관리자들은 고맙게 생각해야 한다. 좋은 소식은 아니지만 솔직함으로 인해 큰 문제를 피할 수 있다. 최대한 이른 시점에 붉은 깃발을 세워 다른 사람들로 하여금 현실적인 대안을 찾아낼 수 있도록 해야 한다.

 

개발 업무를 작은 단위의 업무로 나눌 때 '단위 테스트 구현'을 별도 작업 항목으로 정의하는 경우가 많다. 절대 그래서는 안 된다.

첫 번째로 단위 테스트는 우리가 코드를 작성하는 방식에 이미 녹아있는 것이지 별도의 작업이 아니다. 테스트하지 않으면 코드 작성을 완료한 것이 아니다. 두 번째로 우리가 공식적인 작업 일정표에 무언가를 올려놓는다는 것은 제품 오너가 중요하지 않다고 생각하는 것을 삭제할 권리를 준 것과 같다.

 

애자일 방법론의 절차 중심적인 부분은 비즈니스 목표에 맞게 가고 있는지 정기적으로 살펴볼 수 있는 피드백 루프를 만들어 준다. 애자일 방법론은 변화와 싸우는 것이 아니라 변화 자체를 내재화한다. 애자일과 같은 빠른 피드백 루프를 이미 구축하고 있다면 문제 될 것은 없다.

몇 가지 예외를 제외하고는 애자일 방법론이 폭포수 모델이나 문서 기반의 다른 방법론보다 더 낫다고 생각한다. 애자일은 빠르고 짧은 피드백 루프를 제공해 '올바른 일'을 하고 있는지 점검하도록 도와준다.

 

소프트웨어 장인정신은 좀 더 프로페셔널하고 윤리적인 태도를 북돋우는 것과 더불어 익스트림 프로그래밍(XP)의 실행 관례들을 여러모로 활용하도록 한다. XP 실행관례들에는 TDD, 페어 프로그래밍, 리펙토링, 단순한 디자인, 지속적인 통합 등이 있다.

XP 실행 관례를 이용하지 않는 이유를 물으면 많은 개발자들은 제대로 대답하지 못한다. "당신은 우리 회사를 모릅니다. 같이 일하는 사람들이 어떤지 몰라서 그래요. 제대로 우리 회사에 정착할 수 없어요. 상사가 허락하지 않을 겁니다. 나는 공감하지만 일하고 있는 팀은 그렇지 않습니다."와 같은 대답을 한다.

애자일 방법론을 도입하기 전에 어떤 상황에 놓여 있는지 파악하는 것은 대단히 중요하다. 업무 절차가 바뀌면 역할과 책임 그리고 정보의 흐름에 영향을 줄 수 있기 때문이다.

 

XP 실행 관례들은 소프트웨어의 품질, 즉 일을 올바르게 수행하는 관점에서 피드백 루프를 단축시킬 수 있는 여러 방법들을 제공한다. XP 실행 관례를 도입한다고 해서 일이 갑자기 저절로 되지는 않는다. 실행 관례는 매일 같이 습관처럼 해야 하는 것이다. TDD를 한다면 그것을 하거나 하지 않거나 둘 중 하나다. 지속적인 통합도 마찬가지다. 부분적인 것은 도움이 되지 않는다.

"어떻게 하면 팀에 TDD나 페어 프로그래밍 같은 것들을 도입하도록 설득할 수 있는가?"라는 질문을 자주 듣는다. 기술적 실행 관례들 그 자체를 직접적으로 팔려고 드는 것은 상대를 납득시키는 데 있어서 아무 의미가 없다. 현재 일하는 방식과 비교해 그것이 가져올 이익에 집중을 해야 한다. 빠른 피드백 루프, 요구사항과 비용에 대한 더 나은 이해, 지식 공유, 줄어드는 버그, 전체적으로 자동화되고 릴리즈가 빨라지는 일들이 기술적 실행 관례를 도입함으로써 얻을 수 있는 가치들이다.

 

TDD를 단위 테스트와 동일하게 생각하는 것이 가장 흔한 오해다. TDD는 어느 정도로 테스트 단위가 작아야 하는지 강제하지 않는다. 자동화 테스트 종류는 다양하지만 TDD가 가져오는 가치만을 살펴보자.

TDD는 사실 '테스트' 보다는 '설계'에 대한 실행 관례다. 테스트가 코딩 방향을 주도하면 복잡한 코드를 작성하는 것 자체가 어려워진다. 첫 번째 이유는 정확한 요구사항만큼만 만족시키는 부분만 작성하게 되기 때문이다. 첫 설계 단계에서 요구사항을 확대 해석하고 불확실한 미래에 대한 부가 조건들이 추가되기 쉬워 설계가 커지고 복잡해지는 BDUF(Big Design Up Front) 경향이 있다. TDD가 이를 방지한다. 잘못된 설계로 과한 복잡도를 갖게 되면 새로운 테스트를 작성하기 힘들고 는 설계를 재검토하고 코드를 더 단순하게 리펙토링 하는 원인이 된다.

TDD의 피드백은 정규적인 설계 리뷰 미팅보다 빠르고 객관적이다. 기존 코드의 유지보수 용이성에 대해 거의 즉시 피드백을 받는다. 설계 리뷰는 좋은 것이지만 TDD와 비교해 단점이 있다. 설계 리뷰는 기여하고자 하는 참여자의 욕구로 인해 객관성을 잃고 오버 엔지니어링된다. 주체가 구체적이어야만 설계 리뷰는 효과가 있다. TDD와 설계 리뷰는 배타적인 것이 아니며 제공하는 가치와 피드백 루프 주기가 다름을 이해해야 한다.

 

리팩토링은 보이스카웃의 '캠핑 장소를 처음 발견했을 대보다 더 깨끗하게 남겨두라'는 규칙을 적용하는 것이다. '깨진 유리창 법칙'으로도 알려져 있는 문제를 이겨내야 한다. 지속적인 리펙토링이 필요한 것이다.

실용주의 관념 없이 리펙토링 하는 것은 위험하다. 코드를 수정할 필요가 없다면 리펙토링해야 할 이유도 없다. 보이스카웃 규칙은 모든 것이 아니라 해당 부분을 이해하여 변경할 필요가 있을 때, 적용해야 한다.

 

뉴욕 양키스 출신의 요기 베라는 '어디로 가고 있는지 모르고 있다면, 결국 가고 싶지 않은 곳으로 간다.'라는 말을 남겼다. 소프트웨어 장인으로서 스스로의 커리어를 가치 있게 여기고 아끼고 보살펴야 한다. 어디로 가기를 원하는지 커리어의 방향을 정하는 것이 중요하다. 장기적인 목표고 중간에 많은 것이 바뀔 수 있다.

 

어디로 가야 할지 모른다면 어떻게 해야 할까? 사실 커리어 방향을 정의한다는 것은 대단히 어려운 일이다. 딱 한번 정하고 아무 생각 없이 달리기만 하면 되는 것이 아니다. 지속적으로 결정을 평가하고 다시 목표를 세워야 한다.

어디로 가고 싶은지 방향을 확신할 수 없을 때는 모든 문들을 열어보기 시작해야 한다. 우리에게 기회가 나타날 수 있는 상황들을 만들어낼 필요가 있다. 밖으로 나가서 교류를 해야 한다. 세상이 나에게 접근할 수 있어야 한다. 

• 익숙하고 편한 것에서 벗어나 새로운 것을 공부하고 기술적 지식을 확장한다. 새로운 프로그래밍 언어나 기술들을 배운다.
• 지역 커뮤니티에 정기적으로 출석하거나 행사에 참여한다.
• 다른 개발자, 비즈니스맨들과 교류한다.
• 새롭게 배운 것, 지금 하고 있는 것들에 대해 블로깅한다.
• 오픈 소스 프로젝트에 참여한다.
• 프로젝트를 만들고 공개한다.
• 콘퍼런스에 참석한다.
• 콘퍼런스에 연사로 나선다.

위와 같은 것들은 새로운 기회에 내가 노출되는 상황이 생긴다. 커리어의 다음 여정을 정할 때도 도움이 된다.

 

---

인재 채용 시 직무 요건 목록을 기술하는 것은 피해야 할 관례다. 몇 가지 이유를 보자.

• 절대적인 숫자
  • 숫자는 임의적이고 오해하기 쉬우며 변덕스럽다. 자바 5년 경력, 학점 얼마 이상은 별 도움이 안 된다. 5년 경험은 1년 경험을 5번 반복한 것과 다르다. 또한, 프로페셔널에 필요한 기술은 일을 통해서 또는 자발적 자기 계발을 통해서 배우는 것이지 학점이나 자격증으로 얻는 것이 아니다.
• 키워드 매칭
  • 채용 담당자들은 특정 기술이나 플랫폼에 대한 약어들을 선호하지 않는다.
• 기술 목록의 나열
  • 불필요하게 너무 많은 기술 목록을 나열하면 재능 있고 정직한 개발자가 스스로 지원을 포기하게 만들 수 있다. 희망 기술까지 더해질 경우 개발자를 선별하기는커녕 후보군만 줄인다. 
• 잘못된 기업 문화 설명
  • 기업의 가치와 기대되는 태도, 책임을 잘못 설명하는 경우가 많다. 팀워크, 긍정적 태도, 배움에 대한 열정, 지혜로움과 같은 단어들이 자신에 해당하지 않는다고 배제할 지원자는 없다.
• 잘못된 요구 항목
  • 기술, 경력, 산업군, 출신 학교, 학점 등보다 어떤 직무에서 어떤 책임을 져야 하는지 설명하는 것이 훨씬 낫다.
• 잘못된 선별 조건
  • 최고의 인재를 끌어들이기 우이한 선별 조건이 아니라 최악의 인재를 걸러내기 위한 목적으로 설계되는 경우가 많다. 최고의 개발자들은 신중하게 경력 년수가 기준이 아니며 신중하게 일을 찾는다. 기술 사용 유무보다 회사 문화, 업무 책임, 프로젝트 종류를 더 중요하게 여긴다.
• 승진 요건과의 불일치
  • 승인 심사 때 특정 프레임워크를 아는 것이나 자바 경력 년수가 반영되지는 않는다. 채용 공고의 직무 요건이 승진 요건과 합치하는 부분이 없다면 직무 요건으로 필터링된 사람들이 회사 안에서 좋은 성과를 낼 것으로 기대하는 것이 옳은가.

 

훌륭한 개발자를 서류 심사에서 놓치지 않기 위해서는 훌륭한 개발자에 대한 명확한 정의가 먼저 필요하다. 이 부분은 채용 상황에 전적으로 종속적이다. 열정을 중요하게 본다면 아래와 같은 사항들이 이력서에 있는지 보면 된다.

• GitHub 계정
• 블로그
• 오픈 소스 활동
• 기술 커뮤니티나 사용자 그룹 활동 내역
• 펫 프로젝트 내용
• 트위터 계정
• 좋아하는 기술서적 목록
• 참석했거나 발표했던 콘퍼런스

위의 사항들이 있다면, 자신의 커리어를 위해 개인 시간을 들여 투자한 사람으로, 열정 있는 사람을 구분하기에는 충분하다.

 

리쿠르팅을 꾸준히 적극적으로 해야 한다. 상황이 절박하면 실수할 확률이 높아진다. 채용 기준을 낮추고 아무나 받아들이기 쉽다. 정기적으로 꾸준히 채용을 해야 한다. 좋은 개발자를 찾는 것은 대단히 어렵고 시간이 오래 걸리기 때문이다. 대신 채용 절차를 아주 상세화시킴으로써 관심을 쏟고 싶은 개발자들만 지원하도록 했다. 이는 지원자의 수도 줄이지만 채용의 성공 확률도 높인다.

저자의 경우, 채용할 준비가 안 된 상태에서 지원서가 오면 미리 자리가 없음을 분명히 한다. 대신 채용 절차가 통과하면 자리가 났을 때 최우선 채용할 수 있도록 이야기해 준다. 채용 절차 주에는 최소한 주말을 투자해야 하는 코딩 과제를 제시한다. 당장 채용할 수 없지만 채용 절차를 통해 매우 충실하게 리뷰해 피드백할 것을 약속한다. 이를 통해 회사는 실력 있는 후보자를 확보하고 필요한 시점에 좋은 개발자를 채용할 수 있었다. 지원자도 채용이 되지 못하더라도 코드에 대해 가치 있는 조언을 얻을 수 있다.

 

리쿠르팅 에이전시는 최후의 수단으로 이용해야 한다. 채용을 의뢰한 회사와 이해관계가 상충되기 때문에 고객사의 문화나 가치에 대해 제대로 고려하지 않는 경우가 많다. 거의 대부분 직무 요건을 이력서로 키워드 매칭해 선별한다.

미래의 성공을 위해서는 열정적인 개발자를 찾아야 한다. 개방된 사고로 항상 무언가를 배우기 원하기 때문이다. 스스로 동기가 부여되어 혁신하고 기술 변화를 이끌 것다.

회사 입장에서 사내 개발자들이 마음에 들지 않는다면 개발자를 탓하는 대신 회사가 그들을 어떻게 채용했었는지 회사의 채용 방식에 대해 의문을 품어야 한다.

 

회사와 개발자 모두 생산적인 파트너십을 찾고 있다. 서로 다른 관점에서 바라볼 뿐이다.

저자가 회사에 소속되어 많은 개발자를 면접할 때는 지원자에게 질문이 있냐고 물을 때 '아니요'라는 대답이 많았다. 그 자체만으로 너무 실망스러워 탈락시킨 적도 있다. 여러 관점의 질문을 던지고 일하는 방식을 개선하여 목표를 성공적으로 달성하는 데 기여하기를 원한다.

항상 질문을 많이 하는 지원자를 우선시하는 것이 좋다. 더 능력이 있다는 것은 아니지만 최소한 지원자가 즐겁게 일할 수 있는 곳을 찾고 있다는 증거는 될 수 있다. 몇 가지 주의깊게 볼 것은 과거 프로젝트나 업무, 기술, 또는 스스로 성취한 사항을 얼마나 열정적이고 애착을 보이는가? 실패 사례는 어떻게 표현하고 책임감은 느끼는가? 잘못된 상황을 정상으로 되돌리기 위해 무엇이든 노력해 본 적이 있는가? 이전 업무에서 불평불만 대신 상황을 개선하기 위해 스스로 노력한 적이 있는가? 어떤 종류의 업무 환경을 찾는가? 등이다.

회사를 설명할 때는 좋은 점은 물론 나쁜 점과 껄끄러운 부분까지 가급적 모두 말해야 한다. 적합한 사람을 찾아내는 것뿐만 아니라 회사에 남아 있을 수 있는 사람을 구하는 과정이기 때문이다. 지원자가 사전에 기대한 것에서 크게 어긋나지 않도록 해야 한다.

지원자 입장에서는 회사와 회사 사람들을 알 수 있는 대단히 중요한 기회다. 면접관은 누구인가? 얼마나 많은 지원자들을 면접 보고 있나? 어떤 질문들이 주어지나? 특정된 질문인가 개방형 질문인가? 단답형을 좋아하는가 상세하게 지원자의 생각들을 파보려 하는가? 등이 있다.

지원자는 면접 자리에서 진실을 파해치는 것이 중요하다. 관리층이 개발자를 신뢰하는지도 확인해야 한다. 면접관들이 실무 개발자들이 아니라 관리자, 아키텍트, 팀 리더들로만 구성된다면 계층 구조로 운영되는 회사이며 개발자들을 그다지 신뢰하지 않을 가능성이 있다. 개발자들에게 권한 위임이 되고 있는지를 알 수 있다. 다단계 면접이 아닌 경우는 우려스럽다. 급해서 채용할 시간이 없을 가능성이 높다. 면접관이 이미 주어진 질문지를 읽기만 하고 특정된 짧은 질문들만 한다면 새로운 아이디어를 듣거나 논쟁하고 싶어 하지 않는다는 것일 수도 있다.

 

그럼 바람직한 면접은 무엇일까? 좋은 면접은 자유 토론과도 같아야 한다. 지식과 정보를 교환하고 기술/도구/방법론들에 대해서도 의견을 나누어야 한다.

면접을 할 때 특정 기술에 대한 지식이 아니라 지원자의 재능, 태도, 열정 그리고 잠재성을 보아야만 한다. 직장 경력 자체가 거의 없어도 특정 포인트를 통해 올바른 환경과 기회만 주어진다면 아주 훌륭한 개발자로 빛날 수 있는 사람들이 있다.

 

면접 테크닉은 지원자와 면접관 모두 숙달되어야 한다. 면접 기술을 가르쳐 주는 경우는 거의 없다. 강한 팀은 몇몇 고참 개발자들만이 기술 면접을 수행하는 것이 아닌, 각 개발자들 모두 면접을 진행할 수 있어야 한다. 모든 개발자들이 팀이 기대하는 인재를 발굴해 낼 수 있어야 한다.

경험 많은 개발자는 경험 적은 주니어 개발자를 대동해 면접을 참관하게 해야 한다. 시간이 지나면 역할을 바꿀 수 있다. 경험이 적었던 개발자가 면접관이 되고 경험이 많았던 개발자가 참관인이 될 수 있다. 팀원들이 직접 면접을 보고 선별 과정에 참여하면 팀의 사기와 주인의식이 높아질 수 있다.

 

회사 안에서 진정으로 기술적 변화를 이끌어내고 싶다면 몇 가지 꼭 갖춰야 할 것들이 있다. 가장 중요한 것은 용기다. 동료 개발자, 관리자, 기술 리더와 언성 높이는 논쟁을 두려워해서는 안 된다. 용기와 함께 정직함과 투명함은 소프트웨어 장인이라면 반드시 가져야 할 핵심 가치다.

• 단순함을 추구해야 한다. 
  • 아이디어나 제안은 아주 명료하고 단순해야 한다. 누구든지 이해하기 쉽게 만들어야 한다. 받아들여지기 위해서는 내용도 중요하지만 커뮤니케이션도 중요하다.
• 상대방의 언어로 말해야 한다.
  • 제안 내용에 따라 설득해야 하는 상대방이 개발자, 관리자, 아키텍트, 투자자, 제품 오너, 비즈니스 분석가 등으로 나뉠 수 있다. 상대방 입장에서 제안이 가져올 이익을 그들의 관점에서 그들의 언어로 말해야 한다.
• 말할 내용에 대해 스스로 제대로 이해해야 한다.
  • 연구하고 실습하고 연습해야 한다. 반대 의견이나 지적이 있을지 미리 생각하고 수용될만한 답을 미리 준비해야 한다. 제안의 단점과 예상 문제는 질문이 나오기 전에 미리 밝혀야 한다. 충분한 정보가 없는 부분이 있다면 미리 투명하게 고백해야 한다.
• 상대방을 존중해야 한다.
  • 상대방을 바보처럼 느끼게 해서는 안 된다. 무례하고 공격적인 태도는 사람들을 방어적으로 만든다.
• 경청하는 법을 배운다.
  • 당신만 좋은 아이디어를 갖고 있다고 오판해서는 안 된다. 같은 문제더라도 사람들은 관점이 다르다.

 

그렇다면 상사를 어떻게 하면 설득할 수 있을까? 이에 대한 답은 '설득할 수 없다'이다. 용서를 구하는 것이 허락을 구하는 것보다 쉽다.

기술적 실행 관례라면 굳이 관리자가 관심을 가질 이유가 없다. 일정에 맞춰 제품이 딜리버리 되고 예산을 지키고 버그가 없는 것에 관심이 있을 뿐이다. 개발자들이 TDD를 하든 페어 프로그래밍을 하든 지속적인 통합을 하든 상관하지 않는다.

고객은 개발자에게 높은 품질의 소프트웨어, 훌륭한 솔루션을 기대한다. TDD, 페어 프로그래밍, 연속된 통합 등의 실행 관례는 모두 그것을 달성하도록 돕기 위함이다. 누군가에게 물어볼 것 없이 그냥 실행하면 된다.

 

팀이 TDD를 수용하도록 설득하는 방법 중 하나의 좋은 방법은 도움을 요청하는 것이다. 팀에서 가장 열정적인 동료에게 코드 구현을 도와달라고 하자. 작업 내용을 설명하고 한 두 시간 도안 TDD로 구현해보자고 제안해 보자. 동료가 TDD를 아무도 사용하지 않는다고 할지라도 그냥 재미로 해보자고 한다. 이때가 TDD의 훌륭함을 보여줄 수 있는 때다.

내가 TDD에 능숙하지 않아도 같이 공부하면 된다. 열성적인 사람에게는 TDD를 전파하기 매우 쉽다. 반면 매사 의심이 많은 사람을 설득하는 어렵다. 우선 내가 TDD에 통달해야 한다. TDD는 어렵고 느려서 가치가 없다는 확신을 심어주면 안 된다.

 

테스트 주도 개발이 항상 필요할까? 실용적이 대답은 '아니다'다. 무언가를 해야 할지의 여부에 대해 단정적인 단어는 피하자.

TDD 회의론자들은 항상 TDD를 할 시간이 없다고 한다. TDD에 능숙한 사람 중에는 그런 말을 하는 사람이 없다. 실행 관례에 의문을 표하는 사람들은 뒤에 남길 골칫덩이에 대해 인지하지 못하고 당장 뭔가를 만들어 내는 것에만 집중한다.

유능한 개발자라면 TDD 때문에 개발 일정이 지연되지 않는다. 논란은 의미가 없다.

 

리팩토링을 위한 리팩토링은 시간낭비다. 특별한 이유도 없이 코드를 열어서 재정리하는 일은 아무 의미가 없다. 나쁜 것은 아니지만 실용적인 관점에서는 그저 시간 낭비일 뿐이다.

레거시 코드를 대상으로 작업할 때는 최소한 수정한 부분만큼은 원래 보다 깨끗하게 만들어 놓아야 한다. 새로운 기능을 추가할 때마다 코드를 분석하고 필요한 겨우 레거시 코드가 새로운 기능을 자연스럽게 받아들일 수 있도록 해야 한다.

 

TDD에 능숙한 개발자는 개발 초기부터 디자인 패턴을 적용하는 일이 극히 드물다. 테스트 코드는 비즈니스 요구사항에 맞추는 것이지 디자인 패턴에 맞추는 것이 아니다.

코드는 테스트 통과에 꼭 필요한 만큼만 작성된다. 당장 합당한 이유 없이 미래를 대비해야 한다는 모호한 전제로 초기부터 추상화를 하면 애플리케이션이 엉망이 된다. 미래에 어느 부분이 수정이 필요할지 모르기 때문에 모든 부분에서 추상화를 적용해버린다. 똑똑한 대응이 아닌 바보 같은 짓이다.

복잡도가 낮은 시스템이 높은 시스템보다 유지보수 비용이 낮다. 디자인 패턴 자체가 나쁜 것은 아니다. 무조건 사용해야 할 도구가 아닌 것이다. 리펙토링 때 필요한 경우 흔하게 적용되는 패턴을 찾아서 적용할 수도 있다. 하지만 패턴이 먼저가 아니라는 것이다.

 

실용주의가 없는 장인정신은 장인정신이 아니다. 장인이 가장 중요하게 초점을 맞추는 것은 고객의 만족이다. 품질은 물론이고 시간과 비용도 고객 만족을 위한 구성요소다.

품질은 비싼 것이 아니다. 스킬 부족이 잘 작성된 코드를 비싼 것으로 만드는 원인이다. TDD가 개발자를 느리게 만들지는 않는다. 타이핑 자체가 병목점인 경우는 없다. 새로운 스킬, 새로운 실행 관례, 새로운 기술을 배우고 마스터하는 것이 병목점이 된다.

 

커리어를 만들어 나가야 한다. 저자는 일을 선택하기 전에 아래와 같은 질문들을 스스로에게 던졌다.

• 나의 커리어로부터 나는 무엇을 원하는가?
• 그것을 성취하기 위한 다음 단계는 무엇인가?
• 이 일은 나의 커리어 방향과 합치하는가?
• 내가 이 회사에 줄 수 있는 가치의 양은 얼마나 되는가?
• 그러한 투자에 대한 이익은 무엇인가?
• 그러한 투자는 대략적으로 얼마 동안 지속되어야 하는가?
• 내가 되고자 하는 프로페셔널에 이르는 데 이 일은 얼마나 도움이 되는가?
• 이 일에서 나는 조율성, 통달, 목적의식을 가질 수 있나?
• 나의 고용주와 생산적인 동반자 관계를 맺을 수 있나? 양측 모두 가치 얻고 행복할 수 있나?

위 질문들은 계약 형태와는 관련이 없다. 계약직이나 컨설턴트라고 해서 달라질 것은 없다.

이 모든 질문들에 대한 대답은 고용 계약서에 서명하기 전에 파악하기는 거의 불가능하다. 실제 일을 시작하고 나서야 일부 질문들에 대답할 수 있다. 그렇다고 사전에 답을 구하길 포기해야 한다는 뜻은 아니다. 면접 과정에서 최대한 정보를 얻어야만 한다.

저자는 그렇게 신중하게 골랐음에도 이직할 수밖에 없는 상황들에 대해 설명한다. 시간이 지남에 따라 커리어 열망이 바뀌었고 개인적인 삶도 변했기 때문이다. 어떤 경우는 더 이상 회사에 기여할 것이 없었기 때문이기도 했다. 무언가 큰 변화를 원할 수도 있기도 했다.