[Day 16] 소프트웨어 장인 - 06

1부 이념과 태도

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

2부 완전한 전환

9장 인재 채용

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

 

---

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

• 면접은 쌍방이다. 회사는 그들의 목적을 달성하는 데 도움을 줄 수 있는 개발자를 찾으려 하고, 개발자는 자신의 열망과 커리어 방향에 적합한 회사를 찾으려 한다.
• 개발자는 면접을 볼 때 그 회사에 대해서 파악할 수 있는 중요한 기회로 삼아야 한다.
• 회사와 개발자들이 상호 생산적인 파트너십이 가능할지를 어떻게 판단할 수 있을까?

 

• 비즈니스 협상
  • 기업이 경쟁우위를 점하려면 실력있고 열정 가득한 개발자를 채용하는 것이 필수임을 이제 모든 회사들이 깨닫고 있다.
  • 면접을 볼 때, 일자리를 구걸하는 입장이 아니라는 것을 기억해야 한다. 비즈니스 협상을 하는 것이다.
  • 소프트웨어 장인들은 업계에서 나름의 평판이 있다. 이 평판에 해를 끼치는 것도 위험요소로 보아야 한다. 좋지 않은 상태로 꾸려지고 있는 프로젝트나 회사에 합류하는 것은 장인의 평판을 상당히 깎아내리는 행위다.
  • 생산적인 파트너십이 자리잡히지 않은 회사들은 피해야 한다. 반면에 프로젝트가 위험에 빠져 있기는 하지만 개발자들이 필요한 것은 무엇이든 할 수 있고, 비즈니스 담당과 긴밀하게 협력하고 있는 상황이라면 소프트웨어 장인에게는 역량을 발휘하고 빛날 수 있는 훌륭한 기회다.
  • 성공적인 프로페셔널이라면, 나쁜 조건을 거부하는 것이 나은 경우도 있다는 것을 이해한다. 좋은 파트너십은 양쪽 모두에게 가치 있어야 한다는 것도 이해한다.

 

• 생산적인 파트너십을 알아보는 방법
  • 회사 입장에서의 관점
    • 어떤 식으로 일하는지, 무엇을 성취하길 원하는지, 당면한 문제가 무엇인지 등에 대해 면접 때조차 아무런 질문도 하지 않은 사람이, 실제 업무 현장에서 갑자기 적극적으로 질문을 하리라고 기대할 수 있을까? 지원자가 많은 질문들을 쏟아낸다면 그가 그의 커리어를 소중히 하고 올바른 직장을 찾는 중이라고 짐작할 수 있다.
    • 재능있는 개발자를 채용한다는 의미는 그의 의견을 중요하게 생각하고 일하는 방식을 개선하는 데 그의 도움을 받겠다는 것이다.
    • 지원자에게 회사와 프로젝트에 관해 설명할 때는 좋은 점은 물론 나쁜 점, 껄끄러운 부분까지 가급적 모두 말해야 한다. 면접은 적합한 사람을 찾아 내는 것 뿐만 아니라 회사에 남아있을 수 있는 사람을 구하는 과정이기도 하다.
  • 지원자 입장에서의 관점
    • 지원자에게 면접은 그 회사와 회사의 사람들(잠재적으로 같이 일하게 될)에 대해 알 수 있는 대단히 중요한 기회다. 세부적인 요소들에 집중하면 진실이 무엇인지 힌트를 얻을 수 있다.
      • 관리층이 개발자들을 신뢰하는가? 면접관들이 실무 개발자들이 아니라 관리자, 아키텍트, 팀 리더들로만 구성되어 있다면 계층 구조로 운영되는 회사이고 개발자를 신뢰하지 않을 가능성이 높다.
      • 다단계 면접이 아닌 원샷 면접으로 채용하는 회사는 좀 더 우려스럽다. 너무 급해서 적합한 인재를 채용할 시간이 없을 가능성이 높다.
      • 면접관의 질문들은 대개 면접관이 중요하게 생각하는 것들을 반영한다. 면접관이 이미 주어진 질문지를 그냥 읽기만 하고 매우 특정된 짧은 질문들만 연이어 내놓는다면, 그 면접관은 새로운 아이디어를 듣거나 논쟁하고 싶어하지 않는다는 뜻이다. 면접관이 이러한 태도라면 그 개발팀의 문화 자체가 새로운 생각에 폐쇄적일 수도 있다.
• 바람직한 면접 방법
  • 좋은 면접은 자유 토론과도 같아야 한다. 소프트웨어 개발과 관련하여 지식과 정보를 교환하고, 기술/도구/방법론들에 대해서도 의견을 나누어야 한다. 이런 종류의 면접은 지원자 입장에서 미리 준비할 수 잇는 성격의 것이 아니다. 바로 이 부분이 자유 도론 방식 면접의 백미다. 바로 지원자의 실제 경험을 알아낼 수 있다.
  • 올바른 집중
    • 우리의 핵심 가치는 무엇인가? 우리에게 필요한 주요 기술은 무엇인가? 더 잘하고 싶은, 더 나아지고 싶은 것들은 무엇인가? 새로운 사람을 채용하기 전에 이러한 질문들에 스스로 대답을 준비해야 한다. 전혀 상관도 없는 사항들을 확인하느라 면접 시간을 낭비하지 말자. 회사의 입장에서 더 중요하고 가치있는 것에 집중해야 한다.
  • 마인드 맵핑 대화
    • 면접관으로서 면접을(사실 대화에 가까운) 진행할 때 마인드 맵을 이용하면 매우 편리했다. 개방형 질문에는 유지보수, 테스트, 가독성, 성능, 요구사항 등과 관련된 답변이 뒤따른다. 면접이 끝나면 모든 대화가 마인드 맵으로 종이에 남아 각 지원자와 나누었던 대화들을 다시 기억해 내는 데 효과적으로 이용된다.
  • 페어 프로그래밍 면접
    • 어떤 테스트를 작성할지 얼마나 빨리 결정하는가? (경험 수준)
    • 개발 도구(IDE, 언어, 테스팅/목업 프레임워크, 단축키 등)에 얼마나 익숙한가?
    • 클래스, 메서드, 변수 네이밍을 얼마나 적합하게 하는가?
    • 코드를 얼마나 깨끗하고 명료하게 작성하는가?
    • 면접관이 제안이나 조언을 할 때 어떻게 반응하는가?
    • 지원자가 어떤 방식으로 생각을 전개하는가?
    • 문제 해결만이 아니라 문제 해결을 위한 방법과 과정에도 얼마나 주의를 기울이는가?
    • 페어 프로그래밍을 할 때는 지원자가 어디까지 해낼 것인지 현실적인 기대를 가져야 한다.
    • 면접이긴 하지만 페어 프로그래밍이기 때문에 가장 당연한 대응은 도움을 요청하는 것이다. 이때 면접관은 지원자가 올바른 방향을 찾을 수 있또록 가능한 모든 도움을 주어야 한다.
    • 면접관으로써 어떤 일을 하든지 간에, 지원자가 너무 오래 헤매도록 내버려 두어서는 안 된다. 길어야 3~4분 정도 기다렸다가 도움을 주어야 한다. 지원자는 이미 압박 속에 있기 때문에 시간을 지체하면 상황만 나빠질 뿐이다. 지원자가 어느 부분을 어려워하는지 파악할 수 있고 면접관으로서 계속 평가할 수 있다면 지원자가 자신의 역량을 보이도록 최대한 도와야 한다.
    • 지원자가 면접 시간에 이클립스의 단축키와 새로운 테스팅 프레임워크를 배웠다는 것이 흥미로운 면접이었다. 그는 단축키를 모르는 것에 불편해 하면서 열정을 보여주었다. 그는 새로운 프레임워크를 꽤 빨리 배웠고 질문하는 것을 부끄러워 하지 않았다. 그는 나와 팀으로서 일할 수 있음을 쉽게 보여주었다.
  • 개인 컴퓨터를 지참한 면접
    • 지원자가 좋아하는 도구가 무엇인지도 알 수 있고 소중한 면접 시간을 아낄 수도 있다.
    • 관심을 가지는 부분이 지원자의 테크닉, 코드의 깨끗한 정도, 테스트 작성 역량, 문제 접근 방법 같은 것들이라면 지원자가 어떤 도구, 어떤 개발 언어를 사용하느냐는 전혀 상관이 없다.
  • 맞춤형 면접
    • 지원자의 다재다능한 면을 알아보는 것은 바람직한 행위다. 단, 그 부분이 지원자를 배제할 요건으로서 작용하지는 말아야 한다.
    • 사전 선별 절차는 극히 중요하다. 사전 선별은 회사의 핵심 가치에 따라 지원자를 걸러내는 단계다. 업무와 전혀 관련 없는 기술들에 대한 객관식 온라인 시험으로 지원자를 평가하는 것은 최악의 방법이다.
• 번트 홈런
  • "몇 개의 펫 프로젝트를 하고 있습니까?" 나의 물음에 그는 "다섯 가지가 있습니다." 라고 답했다.
  • 그가 새로운 것을 시도하는 데 얼마나 열정적인지 알 수 있었다. 그는 업무 시간에는 허락되지 않는 배움의 욕구를 채우기 위해 개인 시간을 투자하고 있었다. 올바른 환경과 기회만 주어진다면 아주 훌륭한 개발자로 빛날 매우 전형적인 스타일이었다.
• 지원자와 회사 모두 면접을 어떻게 하는지 알아야 한다
  • 면접 테크닉은 지원자와 면접관 모두 숙달해야만 한다.
  • 강한 팀은 각 개발자들 모두 면접을 진행할 수 있어야 한다. 모든 개발자들이 팀이 기대하는 인재를 발굴해 낼 수 있어야 한다.
  • 경험 많은 개발자는 면접을 진행할 때 반드시 경험이 적은 주니어 개발자를 대동하여 참관하게 해야 한다. 시간이 지나면 역할을 바꿀 수 있다. 경험이 적었던 개발자가 면접관이 되고 경험이 많았던 개발자가 참관인이 될 수 있다.
• 개발자 채용 면접은 개발자가 보아야 한다
  • 좋은 개발자는 나쁜 개발자를 채용하지 않는다. 좋은 개발자는 그들 자신보다도 더 훌륭한 개발자를 찾으려 노력한다. 좋은 개발자는 훌륭한 팀을 구성하는 것이 얼마나 중요한지 잘 알고 있다. 훌륭한 팀은 회사뿐만 아니라 개발자들 자신에게도 이익이 된다.
  • 지원자 입장에서도 개발자가 아닌 사람이 면접을 하고 있다면 다른 회사를 찾아보는 것이 좋다.
• 면접 과정을 지켜보기만 해도 그 회사와 그 안의 개발팀, 개발자들에 대해 많은 것을 알 수 있다. 어떤 계층 구조로 구성되어 있는지, 형식적 절차를 중시하고 관료적인지, 소프트웨어 개발 자체에 얼마나 신경을 쓰고 있는지, 개발자들이 어떻게 취급되고 있는지, 관리층과 개발팀 상호 간의 신뢰 수준이 어떠한지 알 수 있다.
• 소프트웨어 장인이 직장을 찾을 때는 특정한 프로젝트나 펜시한 기술, 괜찮은 급여만을 쫓지는 않는다. 소프트웨어 장인은 생산적인 파트너십과 아침에 일어날 때마다 일하러 가는 것이 행복한 그러한 직장을 찾는다.

---

Chap 11. 잘못된 면접 방식

 

• 회사의 채용 절차를 하나하나 상세하게 뜯어보면 그 회사가 추구하는 가치와 문화를 엿볼 수 있다.
• 소프트웨어 장인을 유인하기 위해서는 면접을 할 때 무엇을 피해야 하는지 면접관이 잘 알고 있어야 한다.
• 똑똑한 척하는 면접관을 세운다.
  • 면접관이 지원자보다 똑똑하거나 더 우월해보이고 싶어해서는 안 된다.
  • 지원자를 프로페셔널 개발자로서 대하고, 채용을 위한 평가나 취조가 아니라 당신이 존중하는 누군가와의 유익한 기술 토론이 되도록 면접을 이끌어야 한다.
• 수수께끼식 질문을 던진다.
  • 두뇌 장난 같은 질문들은 완전히 시간 낭비다. 구글의 면접관들도 잘못된 것을 깨닫고 이런 질문을 그만둔 지 오래 되었다.
• 답을 모르는 질문을 한다.
  • 면접관으로서 어떤 질문에 어떤 답변이 나와야 하는지 잘 모르겠다면 채용중인 직무와 관련해서는 그다지 중요한 질문이 아닐 가능성이 높다.
  • 팀 동료에게 흔히 하지 않는 질문이라면, 팀 동료가 짜증을 낼 질문이라면, 지원자에게도 삼가해야 한다.
• 지원자를 바보로 만든다.
• 인터넷 접속을 막는다.
  • 코딩 면접을 할 때 인터넷을 사용하지 못하도록 접속을 막는 회사들이 있다. 솔루션들을 탐색하고 더 나은 문제 대응 방법을 찾는 것은 소프트웨어 개발자로서 갖추어야 할 핵심적인 능력이다. 인터넷 접속을 막는 것은 전혀 합당하지 않다. 인터넷 검색 때문에 코딩 면접이 변별력을 잃을 수 있다면 면접 과제 자체에 문제가 있다고 본다.
• 종이에 코드를 작성하게 한다.
  • 면접관 스스로도 할 수 없는 일이나 실제 업무 현장에서 부딪히지 않을 상황을 지원자에게 요구해서는 안 된다. 종이나 화이트보드에 불편하게 끄적인 코드가 아니라 실제 도구를 이용해서 생산된 실제 코드를 평가해야 한다.
• 알고리즘 문제를 낸다.
  • 알고리즘 연습문제를 코딩 면접 과제로 선택하는 면접관들이 많다.
  • 실제 여러 시스템의 문제들 중 거의 대부분이 알고리즘이 어떻게 작성되었느냐와는 관계가 없다. 알고리즘을 만들 때 비즈니스 도메인 모델이나 클래스를 만들지는 않는다. 시스템의 주요 문제가 알고리즘이 아니라면 코딩 면접 때 알고리즘 문제 대신 실제 문제에 가까운 과제를 제시해야 한다.
  • 프로젝트를 위해 실제 필요한 역량이 무엇인지, 무엇이 가장 가치있는지를 면접용 코딩 문제에 잘 반영하고 있어야 한다는 것이다.
• 전화 면접을 한다.
  • 전화 면접은 제대로 된 대화보다는 매우 딱딱한 질문과 답변으로 흐르기 쉽다. 오프라인에서 직접 얼굴을 마주보는 면접이 가장 바람직하다.
• 좋은 개발자를 찾기는 꽤 어렵고 오랜 시간이 걸린다. 면접에 시간을 투자하고 있다면 그를 최대한 의미있게 활용해야 한다.
• 좋은 개발자에 대한 수요는 매우 높다. 뛰어난 개발자와 일하고 싶다면 그들과의 면접을 어떻게 수행해야 좋은지 알고 있어야 한다. 면접은 지원자의 입장에서 회사를 가늠하는 자리라는 것을 잊지 말아야 한다. 즉 좋은 개발자들은 거꾸로 회사를 면접하여 평가하고 나쁜 회사들을 걸러낸다.

---

Chap 12. 낮은 사기의 대가

 

• 개발자들의 낮은 사기는 소프트웨어 프로젝트 실패의 주된 이유 중 하나다.
• 애자일 행오버: 낮은 사기
  • 애자일 행오버*에 처한 개발자들은 자신들이 그저 코딩 기계일 뿐, 아이디어를 내고 회사에 기여할 수 있는 프로페셔널로서 대우받고 있지 못하다고 느낀다.
    cf. 애자일 행오버(숙취) : 애자일로 전환하고 나서도 제품 개발 역량이 여전히 뒤떨어져 있다는 깨달음
  • 애자일을 도입한다는 것은 실무자들에 대한 권한 위임, 변화에 대한 내재화, 협업 증대, 정말로 중요한 것들에 대한 집중, 각 업무들의 가치 이해, 맹목적인 업무의 배제를 시행한다는 것과 같은 의미다. 즉 자율성과 목적의식을 제공할 수 있어야 한다.
  • 애석하게도 현실은 애자일 도입을 새로운 절차 정도로 이해하는 회사들이 많다. 그런 회사들은 개발자들이 새로운 절차를 기계적으로 따르기만 하면 애자일스럽게 일이 되는 줄로만 안다. 애자일 도입 이전에도 동기 부여가 되어 있지 않았다면 애자일 도입 이후에도 마찬가지다.
• 그저 '출퇴근'만 하는 개발자들로 인한 대가
  • 열정의 부재 자체가 열정적인 개발자들을 화나게 하는 것은 아니다. 열정적인 개발자들을 화나게 하는 것은 열정을 다해서 애플리케이션을 더 나아지게 하고 일하는 방식을 개선하려고 온갖 노력을 쏟는 동안 다른 개발자들이 그저 뒤에서 팔짱만 끼고 구경하거나 심지어 방해하는 것이 화가날 뿐이다.
  • 나는 에너지가 넘쳤고 프로젝트가 제 궤도를 찾을 수 있도록 영향력을 발휘할 준비가 되어 있었다. 어느 시점에선가 누군가는 일을 즐기기 시작하고 좋아질 것이라고 희망을 가졌다. 그런 일은 일어나지 않았다. 대신 그들은 코드를 임의로 바꾸어서 내가 만든 모든 테스트를 망가뜨렸다.
  • 이런 프로젝트를 개발자 한 명이 바꾸는 것은 거의 불가능하다. 어떤 프로젝트는 훨씬 더 큰 수준에서의 개입이 필요하다.
• 낮은 수준의 동기가 만드는 제약
  • 모든 회사들이 문제를 안고 있다. 어떤 구성원이든지 간에, 회사가 좀 더 나아졌으면 하는 항목들을 쉽게 떠올릴 수 있다.
  • 많은 회사들이 일하는 방식을 개선하지 못하는 이유는 바로 동기가 낮기 때문이다. 구성원들이 동기 부여가 되어 있지 않고 그들의 일이 어떻게 되든 상관하지 않으면 조직을 변화시킬 방법이 없다.
• 개발자들에게 열정을 불어넣기
  • 보통의 개발자와 소프트웨어 장인의 차이점 중 하나는 소프트웨어 장인의 경우 스스로 설정한 임무가 있다는 점이다. 소프트웨어 장인은 고객에게 가치를 전달하고 자신을 둘러싼 사람들에게 영감을 불어 넣기 위해 모든 노력을 아끼지 않는다.
  • 소프트웨어 장인을 팀에 들이는 것은 기술적인 문제 해결에 도움이 될 뿐만 아니라 열정을 불어 넣고 혁신을 일으키는 데 지지자이자 동맹이 되어 준다. 개발자들은 다시 기술에 대한 흥미를 되찾았고 스스로 성장하는 데 관심을 쏟게 되었다. 개발자들이 스스로 만든 제품의 품질에 얼마나 신경을 쓰는지, 회사를 생각해서가 아니라 그 일 자체를 즐기기 때문에 그렇게 한다는 것을 모두가 느낄 수 있었다.
• 직원들의 사기가 낮으면 회사가 파괴되기 쉽다. 동기부여가 되지 않는 사람들은 혁신을 창조하고 적용할 에너지가 없다. 일을 제대로 하고 책임을 지는데도 관심이 없다.
• 사람들의 열정을 없애는 데 정말 능숙한 회사들도 있다.
• 개발자에게 동기를 부여할 수 있는 최선의 사람은 바로 동료 개발자다. 소프트웨어 장인이야 말로 최고의 동기 부여가 될 수 있다. 개발팀에 열정을 불어넣고 동기를 부여하고 싶다면 소프트웨어 장인 몇 명을 팀에 영입해야 한다.