[Day 13] 소프트웨어 장인 - 05

1부 이념과 태도

1장 21세기의 소프트웨어 개발
2장 애자일
3장 소프트웨어 장인정신
4장 소프트웨어 장인의 태도
5장 영웅, 선의 그리고 프로페셔널리즘
6장 동작하는 소프트웨어
7장 기술적 실행 관례
8장 길고 긴 여정

2부 완전한 전환

9장 인재 채용

10장 소프트웨어 장인 면접하기

11장 잘못된 면접 방식
12장 낮은 사기의 대가
13장 배움의 문화
14장 기술적 변화의 실행
15장 실용주의 장인정신
16장 소프트웨어 장인으로서의 커리어
부록 소프트웨어 장인정신에 대한 오해와 설명

 

---

 

• 새로운 인재를 채용할 때 현재의 문제를 더 키우지 않아야 한다는 것을 우선으로 고려해야 한다. 현재 업무가 제대로 진행이 안 되고 잘못된 행동들을 하고 있는 기존 개발자들이 문제라면 그와 똑같이 행동한 사람을 또 채용하는 일이 없도록 해야 한다.
• 모든 회사들이 최고의 인재를 원한다고 표방하지만 최고의 인재가 실제로 어떤 의미인지는 잘 모르는 경우가 허다하다.
• 더 나은 사람을 고용하기 위해서는 채용 방식을 바꾸어야 한다는 것을 모른다. 훌륭한 개발자를 유인하려면 먼저 채용 공고의 직무 요건을 바로잡아야 한다.
• 낮은 사기, 많은 기술적 부채, 열정과 혁신의 부족과 같은 문제들을 해결하려는 회사에게 이러한 채용 공고의 자격 요건들이 얼마나 도움이 될까?
• 채용 공고의 요구 조건 목록은 엉뚱한 것에 집중하고 있고 회사의 가치와 후보자에게 기대되는 태도에 대해서는 아무것도 말하지 않는다ㅋ 회사에서 내보내고 싶은 사람과 같은 부류의 사람을 또 채용하게 될 수도 있다.
• 정확히 어떤 사람을 찾는지 어떻게 찾을 수 있는지도 잘 모르는 경우가 흔하다.
• 가장 흔한 질문이 "어느 정도 형편없는가?"였다. 그리고 내가 미처 대답하기도 전에 "개발자들 역량이 충분한 것 같지가 않다. 뭔가 하나 시키면 언제 끝날지 알 수가 없다. 도대체 뭘 하고 있는지 모르겠다. 누가 가장 문제인지 말해달라. 조치를 취하겠다." 라고 부연을 한다.
• "당신이 가진 불만들은 그 개발자들의 문제가 아니다. 그 개발자들은 어느 날 갑자기 회사 문을 박차고 들어와서 여기서 일하겠다고 한 사람들이 아니다. 그들은 채용 과정을 거쳤다. 이력서를 보내고 당신의 선별 과정을 거쳤다. 당신의 문제는 미숙한 개발자들이 아니다. 당신의 문제는 채용 과정이고 그것에 권한과 책임이 있는 사람이 문제다. 바뀔 것은 채용 절차이고 해고될 사람은 그것에 책임이 있는 사람이다."
• 신뢰할 수 있고 좋은 관계를 맺을 수 있는 사람을 동료로 두는 것은 대단히 중요하다. 면접에 투자할 시간이 없다는 것은 훌륭한 팀을 구성하는 것에 소홀히 한다는 것과 같다.
• 좋은 개발자인지 나쁜 개발자인지가 면접관 개인의 기술적 역량 가치 기준 편견에 따라 정해진다. 계층 구조와 통제에 가치를 두는 사람은 자기보다 더 나은 사람 심지어 자신과 비슷한 수준의 사람조차 배척한다. 반면에 항상 배우기를 원하고 더 나은 일하는 방법을 찾는 사람은 자신보다 훌륭한 사람과 함께 일하기를 원하고 최소한 자신과 비슷한 역량의 사람이라도 채용되기를 희망한다.
• 로 에들러Lou Adler는 기술과 경험을 나열하는 전통적 직무 요건이 "재능에도 반하고, 다양성에도 반하며, 성공적인 채용과의 상관관계도 최악이다"라고 말하고 있다.
• 절대적인 숫자 : 숫자는 임의적이고 오해하기 쉬우며 변덕스럽다. 5년간의 자바 경력 또는 얼마 이상의 대학 학점은 후보자를 제대로 선별하는 데 별 도움이 안 된다.
• 키워드 매칭 : 채용 담당자들은 특정 기술이나 플랫폼에 대한 약어들을 선호하지 않는다. 채용 담당자는 해당 업무의 본질적인 부분을 잘 모르기 때문에 선 무당에게 굿을 맡기는 결과가 된다.
• 기술 목록의 나열 : 불필요하게 너무 많은 기술 목록을 나열하면 재능이 있고 정직한 개발자가 스스로 지원을 포기하게 만들 수 있다.
• 잘못된 기업 문화 설명 : 채용 공고에 기업의 가치와 기대되는 태도 책임을 잘못 설명하는 경우가 많다.
• 잘못된 요구 항목 : 더 훌륭한 개발자를 유인하기 위해서는 기술, 경력 년수, 일한 산업군, 출신 학교, 학점 이런 것들보다 그 직무에서 무엇을 책임져야 하는지 설명하는 것이 훨씬 낫다.
• 잘못된 선별 조건 : 직무 요건들은 최고의 인재를 끌어들이는 것이 아니라 최악의 인재를 걸러내기 위한 목적으로 설계되어 있다. 직무 요건 내용들이 최고의 개발자들을 배척하는 부작용을 만들 수 있다.
• 승진 요건과의 불일치 : 채용 공고의 직무 요건이 이러한 승진 요건과 합치되는 부분이 없다면 그 직무 요건으로 필터링된 사람들이 회사 안에서 좋은 성과를 낼 것으로 기대하는 자체가 앞뒤가 안 맞는 말이다.
• 직무 요건을 꼭 작성해야 한다면 태도와 책임, 프로젝트 종류, 사용 기술(요구 조건이 아니라 참고 정보로서) 그리고 가치관과 회사의 문화에 집중된 내용으로 채워져야 한다.
• 어떤 일을 하는 회사이며 무엇을 가치있게 여기는지, 새롭게 합류할 개발자에게 어떠한 것을 기대하는지
• '당신에게 일은 단순히 직장에 출퇴근하는 것 이상의 의미가 있어야 합니다.' 라는 부분을 볼 때 이 회사는 진정으로 훌륭한 개발자가 이 채용 공고를 보았을 때 어떻게 느낄지 이미 계산해 두고 있는 것으로 보인다.
• 훌륭한 개발자들에게 일은 그냥 일이 아니다. 일은 취미이자 열정이다. 좋아하는 일을 하면서도 돈을 벌 수 있어서 행운이라고 느낀다. 일은 단순한 의미의 일 이상이기 때문에 훌륭한 개발자들은 회사도 같은 방식으로 생각하기를 바란다. 개발자들은 그들이 빛날 수 있는 기회와 재미난 일거리를 많이 제공해 줄 회사를 찾는다.
• 좋은 개발자들은 좋은 개발자들과 일하고 싶어한다. 이것 하나만이 (추천 채용의) 동기로서 의미가 있다.
• 소프트웨어 장인이라면 다른 개발자를 추천하는 것 자체가 스스로의 평판을 시험대에 올리는 행위임을 이해한다. 소프트웨어 장인이 다른 개발자를 추천했다는 것은 그 개발자도 소프트웨어 장인이라는 의미다. 즉 추천한 본인과 동등한 수준의 열정, 가치, 원칙으로 헌신하는 사람이어야 한다.
• 커뮤니티를 적극적으로 후원함으로써 얻을 수 있는 가장 큰 이익은 재능있는 개발자를 발견하고 그들에게 직접 다가갈 수 있다는 것이다. 이 부분은 개발자 입장에서도 마찬가지다. 그 회사의 문화가 어떠한지, 어떤 개발자들이 일하고 있는지, 어떤 종류의 애플리케이션을 만들고 있는지, 어떤 식으로 일하는지 개발자들의 입장에서 파악할 수 있다.
• 가장 중요하게 생각하는 개발자의 자질이 무엇인지, 개발팀에 어떤 문화를 심고 싶은지 곰곰히 생각해보았다. 결론은 열정적인 소프트웨어 장인이었다. 열정은 기술적인 역량이나 프로그래밍 언어에 대한 이해보다도 더 중요한 조건이었다. 나는 항상 새로운 것을 시도하고, 배우고, 지식을 공유하고, 커뮤니티 활동에 적극적인 사람을 원했다.
• 채용 조건을 아무리 잘 만든다고 하더라도 이력서를 선별할 때는 좋은 개발자를 의도하지 않게 제외시키기도 한다. 훌륭한 개발자를 서류 심사에서 놓치지 않으려면 어떻게 해야 할까? 가장 먼저 훌륭한 개발자에 대해서 명확히 정의해야 한다.
• 일반적인 이력서만으로는 열정 수준을 가늠할 방법이 없었다. 그래서 다른 형태의 이력서를 요구했고 다음 사항들 중에 해당되는 것이 있다면 기술하도록 했다.
  • GitHub 계정
  • 블로그
  • 오픈 소스 활동
  • 기술 커뮤니티나 사용자 그룹 활동 내역
  • 펫 프로젝트 내용
  • 트위터 계정
  • 좋아하는 기술서적 목록
  • 참석했거나 발표했던 콘퍼런스
• 상황이 절박하면 실수할 확률이 높아진다. 특히 채용할 때는 더욱 그렇다. 채용 기준을 낮추고 아무나 받아들이기 쉽다.
• 회사는 시급하게 채용해야 하는 상황을 절대 만들어서는 안 된다. 급하게 채용해야만 하는 상황에서는 잘못된 사람이 조직에 들어오기 쉽다.
• 정기적으로 계속해서 채용하기로 했다. 훌륭한 개발자를 찾는 것은 대단히 어렵고 시간이 오래 걸리는 일이다. 정말 좋은 개발자가 꼭 필요한 상황이 되었을 때, 그 때 가서 원하는 스타일의 개발자를 시간 맞춰 찾을 수 있을 가능성은 매우 낮다.
• 광범위하게 채용 공고를 내기 위해 어쩔 수 없이 직무 요건을 기술해야만 한다면 회사의 문화나 가치, 프로젝트의 상세한 내용, 기대하는 역할과 책임, 사용된 기술들(지원 조건이 아닌 참고 자료로서)에 대해서 명확하게 설명하는 것을 잊지 말아야 한다.
• 열정적인 개발자는 개방된 사고로 항상 무언가를 배우기를 원하기 때문이다.
• 열정적인 개발자는 성장하기 위해 개인 시간을 기꺼이 투자한다. 당장 오늘은 미숙하더라도 그리 길지 않은 시간이 지나면 훌륭한 프로페셔널이 될 가능성이 매우 높다.
• 개발자들을 탓하는 대신 먼저 회사가 그들을 어떻게 채용했었는지 회사의 채용 방식에 의문을 품어야 한다.