[Dev] 소프트웨어 장인 리뷰

• Prologue
• Part1.이념과 태도
  • 21세기 소프트웨어 개발
  • 애자일
    • 애자일 매니페스토
  • 소프트웨어 장인정신
    • 매니페스토
  • 소프트웨어 장인의 태도
    • 끊임없는 자기개발
  • 영웅, 선의 그리고 프로페셔널리즘
  • 동작하는 소프트웨어
  • 기술적 실행 관례
    • TDD(테스트 주도 개발)
    • 페어 프로그래밍
    • 리팩토링
    • 실용주의
• Part2.완전한 전환
  • 인재 채용
    • 효과적인 선별 조건의 정의
  • 소프트웨어 장인 면접하기
  • 배움의 문화
  • 실용주의 장인정신
  • 소프트웨어 장인으로서의 커리어
• Review

Prologue

• 우아한테크코스의 캡틴으로 불리는 박재성님이 0순위로 추천한 책이다.

• 책을 읽고 난 소감은 개발과 관련해서 더 나은 개발자가 되기 위한 마인드 위주의 책이었다.

• 이 책은 개인적인 일화와 현장 경험에서 비롯된 무게감 있는 조건이 가득했다.

• 자신의 일에 자부심을 갖는 프로페셔널로 도약하기 위해 필요한 계획, 전략, 태도, 원칙 등을 여러 가지 관점에서 조언했다.

• 책을 읽으면서 내가 생각한 중요한 부분이나 기억해야 할 부분들을 정리해봤다.

Part1.이념과 태도

21세기 소프트웨어 개발

• 개발자라면 다음과 같은 여러가지를 할 수 있어야 한다.

  • 고객과 대화하기

  • 테스트/배포 자동화하기

  • 전체 비즈니스에 영향을 미칠 기술 선정하기

  • 지리적으로 분산된 팀들과 협업하기

  • 고객을 도와 필요한 작업을 정의하기

  • 우선순위 선정하기

  • 진척 상황 보고하기

  • 변경사항과 기대일정 관리하기

  • 잠재 고객 및 파트너에게 제품 소개하기

  • 사전 영업 활동 지원하기

  • 개발 일정과 비용 산출하기

  • 채용 면접하기

  • 아키텍쳐 설계하기

  • 비기능적 요구사항과 계약조건(SLAS) 검토하기

  • 사업 목표 이해하기

  • 주어진 여건에서 최적의 결정하기

  • 새로운 기술 주시하기

  • 더 나은 업무 방식 찾기

  • 고객에게 가치 있는 상품이 전달되고 있는지 고민하기

• 어떤 사람들은 훌륭한 개발자라면 위의 일들을 이미 해왔을 거라고 한다.

애자일

• 애자일은 서로 다른 여러 맥락에서 따른 방법론과 테크닉의 조합이다.

• 애자일 원칙의 절차적인 부분들은 팀과 조직이 어떻게 구성되고 협업해야 하는지에 대한 것들을 규정한다.

  • 회의 방식, 구성원 각각의 역할, 요구사항 파악 방법, 작업 진척 속도 파악 방법, 점진적/반복적으로 일할 때 취하는 방식 등과 같은 것들이다.

  • 팀에 정말로 중요한 것, 비즈니스 가치가 있는 것에 집중한다.

• 애자일 원칙의 기술적인 부분들은 개발, 확장, 유지보수, 제품을 출하면서 어려움들에 대해 특정한 기술적 관례나 기술 자체를 매우 구체적으로 가이드한다.

  • 테스트 주도 개발(TDD), 페어 프로그래밍, 지속적인 통합, 단순한 디자인 원칙 등과 같은 것들이다.

• 게임 체인저

  • 비즈니스와 고객 가치 창출에 개발자들이 직접 참여하는 것도 매우 중요하다고 주장한다.

  • 소프트웨어 프로젝트의 여러 다른 방면에서도 개발팀의 책임이 있다는 인식이 산업계의 판도를 바꾸고 있다.

애자일 매니페스토

• 다음은 애자일 매니페스토 웹사이트에서 발췌한 내용이다.

• 우리는 스스로 소프트웨어를 개발하고, 다른 사람들이 개발하는 것을 도와주면서 더 나은 소프트웨어 개발 방법들을 찾고 있다.

• 이 과정에서 우리는 다음과 같은 가치를 중요하게 생각한다.

  • 절차와 도구보다는 개성과 화합을

  • 방대한 문서 작업보다는 동작하는 소프트웨어를

  • 계약 조건에 대한 협상보다는 고객과의 협력을

  • 계획을 따르는 것을 넘어서서 변화에 대처하는 것을

• 더 가치있게 여긴다. (우측의 사항에 더 높은 가치를 둔다)

소프트웨어 장인정신

• 소프트웨어 장인정신은 소프트웨어 개발자가 스스로 선택한 커리어에 책임감을 가지고, 지속적으로 새로운 도구와 기술을 익히며 발전하겠다는 마음가짐이다.

• 책임감, 프로페셔널리즘, 실용주의 그리고 소프트웨어 개발자로서의 자부심을 의미한다.

매니페스토

• 소프트웨어 장인을 열망하는 우리는, 스스로의 기술을 연마하고, 다른 사람들이 기술을 배울 수 있도록 도움으로써 프로페셔널 소프트웨어 개발의 수준을 높인다.

• 이러한 일을 하는 과정에서 우리는 다음과 같은 가치들을 추구한다.

  • 동작하는 SW뿐만 아니라, 정교하고 솜씨 있게 만들어진 작품을,

  • 변화에 대응하는 것뿐만 아니라, 계속해서 가치를 더하는 것을,

  • 개별적으로 협력하는 것뿐만 아니라, 프로페셔널 커뮤니티를 조성하는 것을,

  • 고객과 협업하는 것뿐만 아니라, 생산적인 동반자 관계를,

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

• 이 매니페스토의 핵심은 부제, 프로페셔널 소프트웨어 개발의 수준을 높인다에 있다.

소프트웨어 장인의 태도

• 고객을 만족시키기 위한 투자는 스스로 해야 한다.

• 고객은 프로페셔널의 교육이 아닌, 그의 지식과 기술에 대한 돈을 지불하는 것이다.

• 소프트웨어 프로페셔널로 대우받기를 원한다면 프로처럼 행동해야 한다.

• 이는 스스로를 발전시키는 데 자신의 돈과 시간을 들여한다는 것이다.

끊임없는 자기개발

오늘날 우리는 계속해서 늘어만 가는 정보 속에, 계속해서 줄어만 가는 의미를 목도하는 세상에 살고 있다.

• 장 보드리야르(Jean Baudrillard)

독서

• 커리어를 위해서라면 개념이나 행동양식에 대한 책들에 더 관심을 두는 것이 좋다.

블로그

• 실제 경험, 개인적인 발견, 성공담, 실패담들이 짧게 담겨 있기 때문에 소프트웨어 장인정신이나 애자일 모델에 태생적으로 궁합이 잘 맞다.

• 모든 소프트웨어 개발자는 경험 수준과 관계없이 블로그가 있어야 한다. 경험과 발견을 공유함으로써 훌륭한 프로페셔널 커뮤니티를 이루는 데 도움이 되어야 한다.

• 우선 블로그는 우리의 배움과 자기개발에 대한 기록의 장으로 두는 게 좋다. 무엇이든 글로 써서 기록을 남기는 것은 가치가 있다.

기술 웹사이트

• 기술 관련 웹사이트들도 시장의 최신 동향을 알아보기에 좋은 수단이다.

영웅, 선의 그리고 프로페셔널리즘

• 프로답게 행동하자. 빡빡한 일정을 다루기 가장 좋은 방법은 필요한 모든 것을 분석하여 가능한 위험과 우려사항을 터놓고 관계자들과 소통하는 것이다.

• 불편한 사항들이나 우려되는 부분들은 최대한 이른 시점에 문제제기해야 한다.

• 개발자들은 협상 기술을 익혀야 한다.

• 다툼을 피하지 말고 부딪혀서 어려운 결정을 내릴 수 있어야 한다.

• 우리가 정직하고 투명한 방법을 사용한다면 누군가 부당하게 피해를 입는 일 없이 팀 전체는 물론 회사에도 이득이 될 것이다.

동작하는 소프트웨어

• 동작하는 소프트웨어를 자주, 몇 주나 2개월 단위로, 가능하면 짧은 주기로 전달한다. (진척도를 가능하는 주된 기준)

• 항상 프로젝트에 다른 사람들도 있다는 사실을 인식하고 전체 프로젝트에 미치는 영향을 감안하여 책임있게 행동해야 한다.

• 점진적으로 기존 코드에 대한 테스트 코드를 작성하면서 코드에 대한 이해도를 높이고 리펙토링을 해나간다.

기술적 실행 관례

• 애자일 방법론은 빠르고 짧은 피드백 루프를 제공하여 우리가 올바른 일(Right Things)을 실행하고 있는지 점검하도록 도와준다.

• 이것은 실행 관례와 몇몇 활동들의 조합으로 이루어진다.

• 작업 진척도를 시각화하고, 즉각적으로 업무를 계획하거나, 우선순위를 조정하고, 최소 시장 충족 기능(MMFs: minimum marketable features)에 집중하고,

  백로그를 관리하고, 스탠딩업 미팅을 하고, 번-다운 차트를 만들고, 사용자 스토리와 시나리오를 쓰고, 제품 수용 기준을 정하는 등

• 애자일 방법론에서 이야기하는 여러 다른 종류의 것들이 포함된다.

• 익스트림 프로그래밍(XP)의 실행 관례에는 테스트 주도 개발(TDD), 페어 프로그래밍, 리펙토링, 단순한 디자인, 지속적인 통합 등이 있다.

TDD(테스트 주도 개발)

• TDD(테스트 주도 개발)은 테스트 코드를 먼저 작성하는 것의 진화된 버전이다.

• TDD는 코드의 설계, 단순성, 유지보수 용이성에 대해 피드백이 빠르다. 또한 코드에 대한 살아 움직이는 문서 역할을 한다. 더불어 긍정적인 부가효과로 회귀 테스트 역할도 해준다.

• 이러한 것이 TDD가 주는 비즈니스적 가치다.

페어 프로그래밍

• 코드의 품질을 보증하기 위해 코드 리뷰를 많은 팀들에서 흔히 적용하고 있다.

• 코드 리뷰는 시스템에 대한 지식과 유용한 코딩 스킬을 팀 전체에 전하는 데도 좋다.

리팩토링

• 프로젝트의 시작단계부터 리팩토링을 하면 코드가 점진적으로 상태가 향상되어 나중에 리팩토링에 너무 많은 시간을 들이는 일이 없어진다.

실용주의

• 무언가를 절대적인 진리로 바라보는 것은 바람직하지 않다.

• 항상 우리가 무엇을 하고 있고 그것을 왜 하고 있는지 질문해야 한다.

• 우리의 일에 항상 최선의 기술, 도구, 절차, 방법론 그리고 실행 관례를 선택할 수 있도록 개발적인 사고 방식을 가져아 한다.

Part2.완전한 전환

인재 채용

• 이 Chapter은 지원자보다는 면접관 입장 위주 내용이었다.

• 회사입장에서 채용공고를 작성할 때, 단순히 직무 요건 목록을 나열하는 것 보다 태도와 책임, 프로젝트 종류, 사용 기술 그리고 가치관과 회사의 문화에 집중된 내용으로 채워져야 한다.

• 다음과 같은 요소를 채용공고에 넣으면 더 좋을 것 같다.

  • 이런 분을 찾습니다. : 태도와 책임과 관련된 내용

  • TDD : TDD를 중요시하는 회사라면 TDD 내용을, TDD가 아니면 그와 관련된 내용(이건 회사마다 Case by Case - TDD, DDD, BDD 등)

  • 직무 역할 : 일하는 방식(TDD, 페어프로그래밍, 리펙토링, 지속적인 제품 릴리즈, 정기적인 콘퍼런스 혹은 이벤트 참석 등)

  • 사용 중인 기술 : 프로젝트 종류와 사용 기술들

• 프로젝트 관리자나 중간 관리자가 아닌 개발자가 제품 오너 및 이해 관계자와 협력적인 방식으로 직접적으로 함께 일한다는 것을 전달하는 것이 중요하다.

• 또한 개발자 역량 향상을 위해 배우고 연습할 시간(개발 스터디, 정기적인 콘퍼런스 참석, 독서모임)을 따로 제공하고 이러한 부분이 회사에 문화적으로 녹아 있음을 강조하는 것 역시 중요하다.

• 이러한 공고를 낸다면 열정적이고 재능있는 개발자를 끌어들이는 데 최적화될 것이다.

효과적인 선별 조건의 정의

• 이력서에 다음과 같은 내용을 추가하면 좋을 것 같다.

  • GitHub 계정

  • 블로그

  • 오픈 소스 활동

  • 기술 커뮤니티 혹은 사용자 그룹 활동 내역

  • 트위터 계정

  • 좋아하는 기술서적 목록

  • 참석했거나 발표했던 콘퍼런스

소프트웨어 장인 면접하기

• 면접은 비즈니스 협상을 하는 것이다. 회사는 그들의 목적을 달성하는 데 도움을 줄 수 있는 개발자를 찾으려 하고, 개발자는 자신의 열망과 커리어 방향에 적합한 회사를 찾으려 한다.

• 면접은 회사와 개발자들이 상호 생산적인 파트너십이 가능할지를 판단하는 협상 자리다.

• 생산적인 파트너십을 알아보는 방법은 각각의 관점마다 다르다.

  • 회사 입장에서의 관점 : 성숙한 채용 문화의 회사라면 파트너십을 기대한다. 면접자의 역할은 지원자가 협업을 잘 할 수 있는지, 권한부여를 잘 감당할 수 있는지 판별하는 것이다. 지원자가 얼마나 많은 질문을 하느냐는 면접관 입장에서 그 사람의 협업 능력과 비즈니스 기여 가능성을 가늠할 수 있는 중요한 단서가 된다. 즉, 항상 질문을 많이 하는 지원자를 우선시하는 것이 좋다.

  • 지원자 입장에서의 관점 : 다단계 면접으로 진행이 되는지, 그리고 면접관이 개발자인지를 파악해야 한다. 면접관이 개발자라면 회사의 관리층이 개발자를 신뢰할 수 있다는 의미이다. 다단계 면접이 좋은 이유는 회사에서 지원자의 서로 다른 여러 측면을 보는 것이기 때문에 제대로 된 프로페셔널을 채용하는 데 진지하게 임한다는 징표일 수 있다. 그리고 면접관들의 질문들을 중요시하게 봐야한다. 그러한 질문들은 대게 면접관이 중요하게 생각하는 것들을 반영하기 때문이다.

배움의 문화

• 관리자들을 개발자에게 권한을 위임하고 개발자들 스스로 배움의 문화를 만들어갈 수 있도록 북돋워야 한다.

• 그러한 환경을 조성하기 위해 다음과 같은 해당 사항들을 고려하자.

  • 북 클럽에 가입하기 - 한 주에 한 번정도 점심 시간이나 기타 여유 시간에 모여서 한 권의 책에 대해 서로 의견을 공유하고 대화를 시도해보기.

  • 테크 런치 진행하기 - 일주일에 한 번정도 점심 시간에 기술과 관련된 난상 토론회를 가지는 것을 제안하기.

  • 그룹 토론회에 참여하기 - 가장 많이 득표한 주제를 두 주제를 가지고 사람들을 두 그룹으로 나눈 다음 해당 주제에 대해 토론 시간을 가지기.

  • 업무 교환하기 - 업무가 반복적으로 찾아올 시기일 때 프로젝트의 한 업무 주기 동안 팀끼리 개발자를 서로 바꾸면서 새로운 것을 볼 기회를 만들어주기. 다른 팀의 개발자와 페어 프로그래밍을 하면 다른 기술, 테크닉, 업무 방식, 사고 경험을 경험하게 된다.

  • 그룹 코드 리뷰하기 - 서로간의 코드를 리뷰하면서 더 나은 개선점이 있는 지 확인한다.

  • 그 밖에 코딩 실습하기, 내부 학습 모임 만들기, 회사에서의 펫 프로젝트 시간을 허용하기, 외부 기술 커뮤니티와 교류하기 등 다양한 배움의 문화가 있다.

• 만약 아무도 참여하려 하지 않는다면 스스로 먼저 모범을 보이고, 관심을 보이는 사람들에게만 집중한다. 굳이 모든 사람들을 강제로 변화시키는 것은 욕심이고, 소수의 사람들이 변화된 것만으로 큰 진보를 나갈 수 있다.

실용주의 장인정신

• 소프트웨어 장인이라면 J.B. 레인스버거이 말한 단순한 설계를 위한 네 가치 원칙을 먼저 생각해야 한다.

1. 모든 테스트의 통과

2. 중복의 최소화

3. 명료성의 최대화

4. 구성요소의 최소화

• 장인이 가장 중요하게 초점을 맞추는 것은 고객의 만족이다.

• 품질은 물론이고 시간과 비용도 고객만족을 위한 구성요소다. 고객에게 가치를 전달할 수 없다면 잘 작성된 코드라고 할 수 없다.

• 깨끗하고 잘 작성된 코드는 비즈니스의 요구에 맞추어 빠르고 안전하게 변경할 수 있는 기반이 된다.

• 요구사항의 변화에 맞추어 코드를 빠르게 바꿀 수 있는 것이 비즈니스를 돕는 최선의 방법이다.

소프트웨어 장인으로서의 커리어

• 열정. 이 단어 하나가 모든 것을 요약한다.

• 장인이 된다는 것은 새로운 것에 대해 호기심을 가지고 실험한다는 것과 같은 의미앋. 장인은 항상 주어진 문제에 가장 적합한 도구를 찾고 단순한 해결책을 추구한다.

• 진정한 소프트웨어 장인은 가장 먼저, 코드 작성이 아니라 문제 해결에 집중한다.

• 정직과 용기는 소프트웨어 장인이 갖추어야 할 핵심적인 자질이다. 즉, 고객이 나쁜 의사결정을 할 때 그것이 적절치 못하다고 지적하는 정직함과 용기를 말한다.

• 본인의 커리어를 만들어 나가기 위해서 일을 선택하기 전에 아래와 같은 질문들을 스스로에게 던져보고 생각해보자.

  • 나의 커리어로부터 나는 무엇을 원하는가?

  • 그것이 성취하기 위한 다음 단계는 무엇인가?

  • 이 일은 나의 커리어 방향과 합치하는가?

  • 내가 이 회사에 줄 수 있는 가치의 양은 얼마나 되는가?

  • 그러한 투자에 대한 이익은 무엇인가?

  • 내가 되고자 하는 프로페셔널에 이르는 데 이 일은 어떻게 도움이 되는가?

  • 이 일에서 나는 자율성, 통달, 목적의식을 가질 수 있나?

  • 나의 고용주와 생산적인 동반자 관계를 맺을 수 있나? 양측 모두 가치 얻고 행복할 수 있나?

• 본인이 원하는 바를 모른다면 최대한 많은 문을 열어 보아야 한다. 커뮤니티 행사에 참석하고, 오픈소스에 기여하고, 토론 메일링 리스트에 참여한다. 영감을 줄 수 있는 사람도 찾아 나서는 게 좋다.

• 밖으로 나가서 당신이 무엇을 할 수 있는지 다른 사람들에게 보여준다. 그렇게 하면 당신이 모르던 큰 세상이 있음을 알게 될 것이다.

• 이렇게 하다보면 당신이 어디로 가고 싶어 하는지 감이 잡힐 것이다.

소프트웨어 장인의 사명

• 소프트웨어 장인은 자신만의 사명이 있다.

• 더 나아지는 데 집중하고, 계속해서 자신의 커리어에 투자하며, 배우고, 가르치고, 공유한다.

• 그가 많은 고객에게 항상 가치를 전달할 수 있도록 해야 한다.

• 진정한 사명은 프로페셔널리즘, 열정, 관심으로 소프트웨어 산업의 수준을 높이는 것이다.

Review

• 개발자가 쉽게 이해할 수 있는 코드를 구현하기 위한 개발의 실력도 중요하지만, IT 분야의 팀 프로젝트 전반적인 이해와 한 단계 성장하는 계발자가 되려면 어떤 요소가 필요한 것이 무엇인지 알려줬다.

• 이 책의 아쉬운 점은 예비(신입)개발자 입장에서 보면 Part1의 내용들은 얻어갈 게 많았지만, Part2의 내용들은 Part1에서 얘기했던 내용들과 많은 부분들이 겹쳤고, 크게 중요하다고 생각하는 부분이 별로 없었다는 점이다.

• 책 페이지 전체 수가 300 조금 넘지만, 나에게 실제로 얻어갈 내용은 100 안쪽이였다.

• 그래도 개발자로서 어떻게 살아가야 할지 도움을 주었던 책이었고, 개발자에서의 자기개발 책으로서는 만족한 책이었다.

• 앞으로 개발에 대한 마인드 셋이 필요할 때마다 해당 책을 참고하며 개발자의 마음가짐을 새겨두고 실전에 체화하자.