소프트웨어 장인

 

소프트웨어 장인

이 책에서 풀어낸 소프트웨어 장인정신의 프로페셔널리즘, 기술적 탁월함, 고객 만족은 애자일, 린(lean) 원칙들과 시너지를 일으켜 소프트웨어 업계를 한 단계 도약시킬 수 있다. 또한 프로젝트와 개발자를 공장 운영과 생산 라인 노동자로 보는 관점을 바꾸는데 기여할 것이다. 그리고 책에서 다룬 경험을 바탕으로 한 사례와 실용적인 조언은 소프트웨어 개발자뿐만 아니라 프로젝트와 연관이 있는 모든 참여자에게 도움이 될 것이다.

저자

산드로 만쿠소

출판

길벗

출판일

2015.09.25

 

Part 0.

추천사

아픔에 대한 책이기도 하다. 당신과 나 그리고 모든 프로그래머가 겪는 아픔을 생생하게 전달한다. 수준 이하로 일을 마무리했던 경험, 전혀 프로답지 않았던 경험, 더 나아지고 싶지만 어떻게 해야 하는지 몰랐던 아픔 등에 관한 일화와 그 치유법을 담았다.

 

저자 서문

“다 끝냈습니다. 동작도 합니다.“라고 외치자, 그는 타이핑을 멈추고 나를 돌아봤다. “코딩이 직업인 사람이 동작하는 코드를 만드는 건 기본이예요.” 그는 조용히 말했다. “일을 끝냈다는 말에는 제대로 동작한다는 것이 당연히 포함되어 있죠.”

 

델파이 :: 미국 볼랜드에서 오브젝트 파스칼 언어의 기능을 향상시켜 개발한 일반 응용 프로그램 개발 언어이다. 또한 데이터베이스 프로그래밍까지 가능한 VCL 개발도구이다. VCL(visual component library)이라고 불리는 하나의 객체 지향적인 구조를 사용하며, 코딩하는 과정에서도 완성 후의 모습을 살펴볼 수 있다.
오브젝트 파스칼 언어의 기능을 향상시킨 언어이다. 이외에도 비주얼 베이식의 통합 개발 환경(IDE:integrated development environment)과 비슷하지만 그보다 훨씬 가시적인 개발 환경을 제공한다. 델파이는 VCL(visual component library)이라고 불리는 하나의 객체 지향적인 구조를 사용한다.흔히 윈도우를 가르켜 GUI(그래픽에 의한 처리)라고 말한다. 이것은 화면에서 움직이는 대부분의 프로그램 요소가 그래픽으로 처리되어 사용자가 쉽게 운영체제를 익힐 수 있는 장점이 있다. 델파이는 이러한 GUI를 충실히 컴파일러에 반영한 도구이다. 처음 델파이를 설치한 후 델파이의 개발 환경을 살펴보면 당연히 델파이가 주변에서 흔히 볼 수 있는 비주얼 툴에 지나지 않는 것처럼 보이지만 엄격히 말해서 컴파일러이다.또한 델파이로 코딩하는 과정, 즉 프로그램이 동작하지 않는 과정에서도 델파이는 완성 후의 모습을 살펴볼 수 있다. 그러나 이것은 설계시에 프로그램이 동작하는 것이 아니라 내부적으로만 동작하고 있는 것이다. 이러한 시각적인 개발 환경은 프로그램의 모습을 보면서 바로 프로그램을 수정할 수 있는 방법을 제공한다.
[네이버 지식백과] 델파이 [Delphi] (두산백과 두피디아, 두산백과)

 

1990년대에는 다른 사람이 알아볼 수 없는 난해한 코드를 짤 수 있는 사람이 실력있는 개발자로 통했다. “와우! 그는 똑똑한 개발자가 틀림없어. 그 사람 코드는 무엇을 하는 코드인지 전혀 감을 잡을 수가 없거든.” 나 역시 내가 얼마나 똑똑한지 보이려고 난해한 코드들을 조금 집어 넣었다. 나무르는 순간, 그 코드가 무엇을 하는지 알아냈다. 나는 내 기분을 띄워줄 말을 기대했다. “이 코드가 얼마나 무례한지 알고 있습니까?” 그는 조용히 말했다. “많은 팀과 개발자들이 같은 코드 베이스에서 아주 큰 시스템을 만들고 있습니다. 모든 개발자들이 이런 식으로 으스대려고 난해한 코드를 만들면 코드를 이해하기가 얼마나 어려워질지 생각해봤나요? 수천 라인, 아니 수백만 라인의 코드가 이런 식이라고 상상해보세요”

그는 키보드를 몇 번 두드려서 내가 작성한 모든 코드가 들어 있는 파일을 삭제했다. “좋습니다. 아직 3일이나 남았으니 다시 해보세요.”

“일을 하는 것도 중요하지만 그에 못지 않게, 일을 어떻게 하느냐도 중요합니다.”

 

일을 끝내는 것 자체로는 부족하다는 것, 그 일을 어떻게 하느냐가 더 중요하다는 것, 특히 팀에서 일할 때는 더욱 그러하다는 것을 배웠다.

 

‘일을 어떻게 했느냐는 일을 해낸 것만큼이나 중요하다.’

 

이 책에 대하여

애자일 방법론 ::  신속하고 변화에 유연하며 적응적인(adaptive) 소프트웨어 개발을 목표로 하는 다양한 경량 개발 방법론 전체를 일컫는 총칭으로, 반복(iteration)이라 불리는 단기 단위를 채용함으로 위험을 최소화하는 개발방법이다. 
소프트웨어 개발 방법의 하나로, 개발 대상을 다수의 작은 기능으로 분할하여 하나의 기능을 하나의 반복 주기 내에 개발하는 개발 방법을 말한다. 하나의 반복 기간은 프로젝트마다 다르지만 일반적으로 1주에서 4주 정도인 경우가 많다. 이 반복 주기를 계속해 나가며 하나씩 기능을 추가 개발하는 것이다. 각각의 반복은 소규모 소프트웨어 개발 프로젝트와 비슷하며, 각 반복은 지금까지 개발된 성과물에 하나의 작은 기능을 추가하는 역할을 한다. 계획, 요구분석, 설계, 구현(코딩), 테스트 및 문서화 등 소프트웨어 프로젝트에 필요한 모든 공정이 하나의 반복 내에서 모두 실시된다. 각 반복이 끝날 때마다 기능이 추가된 새로운 소프트웨어(빌드, build)를 출시하는 것을 목표로 하며, 각 반복이 끝나면 프로젝트 팀은 프로젝트의 우선 순위를 재평가하여 다음 반복을 실시한다.기존의 문서 기반 개발 방법과는 달리 프로젝트 관계자 사이에서 필요할 때 직접 얼굴을 맞대고 즉각적으로 의사 소통하는 것을 강조한다. 일반적으로 애자일 개발 팀은 소프트웨어 개발에 필요한 모든 참가자가 한 곳의 작업장에서 일한다. 즉, 소프트웨어 개발자와 필요한 소프트웨어를 정의하는 고객, 테스터, 사용자 인터페이스 설계자, 기술 문서 기록자 등을 모두 포함한다. 또한 결함을 조기에 식별하기 위해 테스트를 강화하고, 개발 초기부터 테스트를 수행하며, 자동화된 테스트 및 배포 환경을 구축함으로써 지속적인 시스템 통합을 수행하고자 한다.이러한 애자일 소프트웨어 개발 방법은 1990년대의 중반 중량 폭포수(heavyweight waterfall-oriented) 소프트웨어 개발 방법론에 대한 반대 운동인 경량 소프트웨어 개발 방법으로부터 시작되었다. 이러한 경량 소프트웨어 개발 방법론에는 동적 시스템 개발 방법(DSDM, Dynamic Systems Development Method), 스크럼(Scrum), 익스트림 프로그래밍(XP, Extreme Programming) 등이 있다. 2001년 켄트 벡(Kent Beck)을 포함한 이 분야의 저명한 소프트웨어 개발자 17명이 미국 유타의 스노우버드(snow bird) 리조트에서 모여, 애자일 소프트웨어 개발 선언을 발표하였다.이 선언에서는 도구보다는 상호작용을, 문서보다는 소프트웨어 자체를, 계약 협상보다는 고객과의 협력을, 계획 준수보다는 변화에 대한 대응을 강조하는 개발 원칙들이 공표되었다. 2001년 이후로는 비영리 조직 애자일 연합(Agile Alliance)이 애자일 소프트웨어 개발 방법론을 추진하고 있다.
[네이버 지식백과] 애자일 개발방법론 [Agile Software Development] (두산백과 두피디아, 두산백과)

 

익스트림 프로그래밍 :: 익스트림 프로그래밍(영어: eXtreme Programming, XP)는 켄트 백 등이 제안한 소프트웨어 개발 방법이다. 비즈니스 상의 요구가 시시각각 변동이 심한 경우에 적합한 개발 방법이다.Programming Explained - Embrace Change'에서 발표되었다. 애자일 개발 프로세스라 불리는 개발 방법 중의 대표적인 하나로 꼽히며, 약칭인 'XP'로 잘 알려져 있다.
10~12개 정도의 구체적인 실천 방법(Practice)을 정의하고 있어, 비교적 적은 규모의 인원의 개발 프로젝트에 적용하기 좋다. 개발 문서 보다는 소스코드를, 조직적인 개발의 움직임 보다는 개개인의 책임과 용기에 중점을 두는 경향이 크다.
켄트 백은 XP를 이끄는 가치와 원칙에 대해서도 강조했다. XP에서 실천 방법에만 집중하고 가치와 원칙을 무시하면 제대로 XP를 실천하고 있다 하기 힘들 것이다. 원칙은 가치와 실천 방법을 잇는 다리 같은 것이다.
XP의 목적은 '고객이 원하는 양질의 소프트웨어를 빠른 시간안에 전달하는 것'이다. 수시로 발생하는 고객의 요구사항에 대처하고, 고객이 원하는 SW를 고객이 원하는 시간에 인도하기 위해서는 고객과 팀원간의 대화를 통해 해결한다.
다른 애자일 방법론과 구분되는 XP만의 특징에는 테스팅이 있다. XP는 프로그래머들이 코딩을 할때에 테스트 코드를 작성하도록함과 동시에 테스트를 기반으로 프로젝트를 완성시켜 나가도록 한다. 또한 이러한 테스트에 기반을둔 프로젝트 발전 과정은 애자일 방법론의 기본 개념인 "반복적으로 프로토 타입을 고객에 전달함으로써 고객의 요구사항 변화에 민첩하게 대응한다"를 실천하는데에 큰 도움을 줄 수 있다. 왜냐하면 매번 프로토 타입을 고객에 전달함에 있어서 프로토 타입 자체로써 버그가 상대적으로 적은 완벽에 가까운 데모를 경험하게 해줄 수 있기 때문이다.
[위키백과] 익스트림 프로그래밍 [eXtreme Programming, XP]

 

 

 

Part 1. 이념과 태도

Chapter 1. 21세기의 소프트웨어 개발

그 당시에는 난해한 코드를 만들 수 있는 능력이 개발자의 실력을 가늠하는 척도였고, 그 코드를 이해하지 못한다면 아직 숙련이 덜 된 거라고 치부했다. 아무도 이해할 수 없는 코드를 짤 수 있다면 즉시 고급 개발자로 인정받을 수 있었다. “이 코드는 지금 수정 못해. 담당자가 휴가에서 돌아와야 해. 다른 사람은 이 코드를 이해할 수가 없거든.”이라는 식의 이야기가 흔한 때였다.

 

Gof 디자인 패턴 :: 대부분 그렇지만 소프트웨어를 설계할 때도 경험만큼 확실한 것은 없다. 그러나 모든 사람이 숙련된 설계 경험자일 수는 없다. 그렇다면 경험이 적은 사람들이 설계를 잘할 수 있는 방법은 없을까? 있다. 바로 경험 많은 전문가의 지식과 노하우를 공유하는 것이다. 그렇다면 어떻게 소프트웨어 설계에 대한 지식과 노하우를 공유할 수 있을까?
한 가지 방법은 소프트웨어 설계 방법론과 지침을 통해 공유하는 것이다. 그러나 이런 접근에는 한계가 있다. 방법론이나 지침은 일반화된 것이어서 구체적인 문제에 적용하려면 또 다른 지식이나 노하우가 필요하기 때문이다. 예를 들어 객체지향 방법론을 아는 것과 내가 개발할 소프트웨어를 직접 객체지향 방법론에 따라 설계하는 것에는 차이가 있다.
또 다른 방법은 사례를 통한 공유다. 즉 주어진 문제를 해결하기 위해 여러 가지 설계 사례를 분석해서 지식이나 노하우를 공유하는 접근 방법이다. 그러나 이 방법도 사례와 전혀 다른 유형의 문제를 해결하려면 또 다른 노력이 필요하다. 개별 사례는 너무 구체적이고 특정 문제의 가정에 의존적일 수 있기 때문이다. 예를 들어 일괄 처리를 목적으로 하는 소프트웨어를 설계할 때의 지식이나 노하우를 실시간 처리를 목적으로 하는 소프트웨어 설계에 적용하기는 힘들 것이다.
그렇다면 너무 일반적이지도, 너무 구체적이지도 않은 형태로 소프트웨어 설계를 위한 지식이나 노하우를 공유할 수 있는 방법은 무엇일까?
이를 위해 고안된 것이 바로 에릭 감마(Erich Gamma), 리처드 헬름(Richard Helm), 랄프 존슨(Ralph Johnson), 존 블리시데스(John Vlissides)가 제안한 GoF(Gang of Four)의 디자인 패턴이다. 객체지향 개념에 따른 설계 중 재사용할 경우 유용한 설계를 디자인 패턴으로 정립한 것이다. 여기서 디자인 패턴이란 여러 가지 문제에 대한 설계 사례를 분석하여 서로 비슷한 문제를 해결하기 위한 설계들을 분류하고, 각 문제 유형별로 가장 적합한 설계를 일반화해 패턴으로 정립한 것을 의미한다.
따라서 디자인 패턴은 소프트웨어 설계에 대한 지식이나 노하우가 문제 유형별로 잘 구체화되어 있을 뿐 아니라, 동일한 문제 유형에 대해서는 그 해결 방법에 대한 지식이나 노하우가 패턴 형태로 충분히 일반화된 것이라 할 수 있다. 단, 이 디자인 패턴은 쉽게 재사용할 수 있도록 객체지향 개념에 따른 설계만을 패턴으로 지정하였다.
사실 소프트웨어는 그 목적이 다 다르고, 구체적인 적용 상황이나 환경에 따라서도 최적의 해결책이 달라지는 만큼, 일정한 틀을 가진 패턴을 여러 소프트웨어 설계에 적용한다는 것은 이해가 되지 않을 수 있다. 그러나 가만 생각해보면 우리는 자주 비슷한 상황, 비슷한 문제를 경험하게 된다. 특히 주어진 상황이나 문제를 세분화해 분류해보면 놀랍게도 많은 문제들이 전에도 경험했던 것들임을 알 수 있다.
예를 들어 객체를 생성하거나 공유하는 문제, 모듈 간의 연관 관계를 간단하게 만들거나 특정 모듈에서 수행해야 할 역할을 위임시키는 문제 등은 소프트웨어를 설계할 때 늘상 접하는 문제라고 할 수 있다. 따라서 이미 여러 사람에 의해 검증된 디자인 패턴을 잘 이해하고 활용한다면 경험이 부족하더라도 충분히 좋은 소프트웨어를 설계할 수 있을 것이다.
[네이버 지식백과] Gof 디자인 패턴 (쉽게 배우는 소프트웨어 공학, 2015. 11. 30., 김치수)

 

UML :: 요구분석, 시스템설계, 시스템 구현 등의 시스템 개발 과정에서, 개발자간의 의사소통을 원활하게 이루어지게 하기 위하여 표준화한 모델링 언어이다.
객체 관련 표준화기구인 OMG에서 1997년 11월 객체 모델링 기술(OMT;object modeling technique), OOSE 방법론 등을 연합하여 만든 통합 모델링 언어로 객체 지향적 분석 ·설계 방법론의 표준 지정을 목표로 하고 있다. 요구 분석, 시스템 설계, 시스템 구현 등의 과정에서 생길 수 있는 개발자간의 의사 소통의 불일치를 해소할 수 있다. 모델링에 대한 표현력이 강하고 비교적 모순이 적은 논리적인 표기법(notation)을 가진 언어라는 장점이 있다. 따라서 개발자간의 의사 소통이 쉬워지며 생략되거나 불일치되는 모델링 구조에 대한 지적도 용이하고, 개발하려는 시스템 규모에 상관없이 모두 적용 가능하다.유스케이스(use case) 다이어그램, 클래스 다이어그램 등 8개의 다이어그램을 기반으로 객체지향 소프트웨어를 개발하기 위한 풍부한 분석 및 설계 장치를 제공하고 있어 향후 상당 기간 동안 산업계의 표준으로 활용될 것이라 예상된다. UML을 가장 잘 적용할 수 있는 소프트웨어 개발 프로세스는 1998년 11월 미국 래셔널(Rational)사에서 개발한 통합 프로세스(Unified Process) 5.0이다. 이 프로세스는 웹 애플리케이션(web application) 개발에 효율적이고 개발팀의 생산성을 극대화하며 UML의 장점을 최대한 살릴 수 있도록 고안된 실무형 개발 프로세스이다.
[네이버 지식백과] UML [unified modeling language] (두산백과 두피디아, 두산백과)

 

오늘날에는 그런 방식을 오버 엔지니어링이라고 한다. 직설적으로는 어리석은 짓이라고 말하지만 그 당시에는 아키텍트의 혜안이라고 했다.

 

아키텍트로서의 업무는 전혀 즐겁지 않았다. 매일같이 다이어그램을 그리는 것은 신물이 났고, 장기적인 예측과 계획은 시간 앞에 허망하게 빗나갈 때가 많았다. 나는 개발의 즐거움을 선택하기로 했다. 매일 코드를 작성하는 일은 행복이었다. 그때 이후로, 아침에 눈을 뜰 때마다 오늘 할 일이 하고 싶어 기대되는 일만 하기로 스스로와 약속했다.

 

커리어 패스를 정할 때는 내가 열정이 있는 것, 진정 즐겁게 할 수 있는 것을 따라야 한다는 것이다. 아키텍트든, 개발자든, 테스터든, 비즈니스 분석가든, 관리자든 상관없다. 모든 역할이 필요하고 중요하다.

 

고참 개발자

같은 경험을 10년 동안 열 번 반복하는 것과, 10년 동안 매년 서로 다른 경험을 하는 것 사이에는 어마어마한 차이가 있다. 10년 동안, 다른 프로젝트, 다른 기술, 다른 회사에서 일한 것과 10년 동안 같은 회사, 같은 프로젝트, 같은 사람, 같은 기술로만 일한 것은 크게 다르다.

 

폭포수 모델 :: 소프트웨어 개발생명주기(SDLC; Software Development Life Cycle)에 기반하고 있는 소프트웨어 개발 기법으로, 워터폴 모델·폭포수 모형·선형순차 모형·단계적 생명주기라고도 한다. 한 번 떨어지면 거슬러 올라갈 수 없는 폭포수와 같이 소프트웨어 개발도 각 단계를 확실히 매듭짓고 다음 단계로 넘어간다는 의미에서 붙여진 명칭이다. 전통적인 시스템 생명주기 모델로 소프트웨어를 개발할 때 가장 널리 사용된다.
개발 과정이 명확하게 단계화되어 있다. ①타당성을 분석하고, ②사용자의 기능·성능·신뢰도 등에 대한 요구를 분석하며, ③소프트웨어를 설계하고, ④프로그래밍을 한 뒤, ⑤통합 테스트를 거쳐, ⑥소프트웨어를 운용하고 유지·보수시키는 등의 단계를 거친다. 각 단계가 명확하여 관리가 쉬우나 요구 분석에 상당한 시간이 소요되며, 일단 분석이 끝나면 수정이 어렵다는 단점을 지닌다. 또 개발 단계마다 피드백이 발생하므로 순차적인 흐름을 따라가기 어려우며, 규모가 크고 복잡한 시스템에는 적합하지 않다. 이러한 단점을 보완하기 위하여 모델을 변형하거나 단계 통합 또는 새로운 단계 추가 등이 시도되고 있다.
[네이버 지식백과] 폭포수 모델 [Waterfall Model, 瀑布水─] (두산백과 두피디아, 두산백과)

 

고참 개발자, 신참 개발자라는 것은 없다. 큰 규모의 기업 시스템용 자바 애플리케이션 개발에 경험이 많더라도 자바 스크립트로 게임을 만드는 데는 생초보일 수 있다. 애자일 방법론을 채택하고 다수와 협력하여 일하는 방법에는 매우 익숙하더라도, 다단계 구조인 관료적/정치적인 조직에서는 신입사원과 별 다를 바 없을 수 있다.

 

새로운 현실

코딩은 개발자가 해야 하는 많은 일들 중에 하나일 뿐이다. 코딩을 잘하거나 특정 언어나 프레임워크에 매우 익숙하다고 해서 고참 개발자가 되는 것은 아니다.

 

소프트웨어 개발자가 소프트웨어 개발 업무만 하면 되던 시절은 지나갔다. 코딩과 관련된 것이 아니면 개발자와 상관없는 문제라는 태도는 이젠 용납되지 않는다. 기업들은 더 작아지고 기민해지며 조직 계층 구조도 평탄해지고 있다. 한 가지밖에 할 줄 모르는 지엽적인 전문가들은, 이제 자기 전문 분야와 더불어 비즈니스에 관련된 여러 방면에 조예가 있는 사람들로 바뀌고 있다.

 

폭포수 모델을 전통적인 관리형태와 결합하여 사용하면 오늘날처럼 빠르게 변하는 시장에 더는 대응할 수가 없다. 제품 출시와 피드백 루프를 신속하게 수행하는 린 스타트업(Lean StartUp)모델이 경쟁 방식을 완전히 바꾸어 놓았다.

 

 

 

Chapter 2. 애자일

스크럼 :: 스크럼(scrum)은 프로젝트 관리를 위한 상호, 점진적 개발방법론이며, 애자일 소프트웨어 개발 중의 하나이다. 스크럼(scrum)은 소프트웨어 개발 프로젝트를 위하여 고안되었지만, 소프트웨어 유지보수 팀이나 일반적인 프로젝트/프로그램 관리에서도 적용될 수 있다.
역사
이 방법은 일본 히토츠바시 대학의 노나카 이쿠지로와 타케우지 히로타카가 1986년 1~2월 Harvard Business Review에 올린 "The New New Product Developement Game"[1]에서 시작된다. 그 후 1991년 디그라스(DeGrace)와 슈탈(Stahl)이, "Wicked Problems, Righteous Solutions"[2]에서 스크럼을 처음 언급했다. 처음 노나카와 타케우지가 스크럼을 만들때의 목표는 공업품의 개발이었으나, 1995년 Ken Schwaber가 이 방법을 Advanced Development Method라는 이름으로 자신의 회사에서 사용하였다. 비슷한 때에 Jeff Sutherland, John Scumniotales, 그리고 Jeff McKenna는 Easel 사에서 이와 비슷한 방법을 개발하고, 스크럼이라고 처음 불리게 되었다.
스크럼의 특성
스크럼은 특정 언어나 방법론에 의존적이지 않으며, 개발 언어는 물론이고 객체지향 언어와도 관련이 없는 넓은 응용 범위의 개발 기법이다. 스크럼은 애자일 소프트웨어 개발 과정의 하나로 다음과 같은 특성을 가지고 있다.
- 솔루션에 포함할 기능/개선점에 대한 우선 순위를 부여한다.
- 개발 주기는 30일 정도로 조절하고 개발 주기마다 실제 동작할 수 있는 결과를 제공하라.
- 개발 주기마다 적용할 기능이나 개선에 대한 목록을 제공하라.
- 날마다 15분 정도 회의를 가져라.
- 항상 팀 단위로 생각하라.원활한 의사소통을 위하여, 구분 없는 열린 공간을 유지하라.
[위키백과] 스크럼 (애자일 개발 프로세스)

 

동적 시스템 개발 모델(Dynamic System Development Model: DSDM) :: 동적 시스템 개발 방법
(Dynamic systems development method, DSDM)은 초기에 소프트웨어 개발 방법으로서 사용된 애자일 프로젝트 전달 프레임워크이다. 1994년 처음 모습을 드러된 DSDM은 원래 고속 응용 프로그램 개발(RAD) 방식의 일부 원리를 제공하려고 했다. 나중 버전에서 DSDM 애자일 프로젝트 프레임워크가 개정되면서 소프트웨어 개발과 코드 작성에 주로 초점을 두는 대신, 프로젝트 관리, 솔루션 전달의 일반적인 접근 방식이 되었으며 IT가 아닌 프로젝트에서 사용될 수 있게 되었다.
[위키백과] 동적 시스템 개발 방법

 

피처-드리븐 개발(FDD) :: 개발을 상품이나 서비스 단위가 아니라 신규 기능 단위로 하는 개발 방법론
각 개발 컴포넌트별 코디네이션이 중요하나의 기능 개발을 위해 전체 팀에서 필요한 내용을 중재하고 전체 시스템의 흐름을 정의할 수 있는 아키텍트의 역할 필요
[IT위키] FDD

 

게임 체인저

변화에 피동적으로 대처했던 기존과 달리 애자일에서는 변화 자체를 내재화한다.

 

코드를 잘 작성하는 것이 소프트웨어 프로페셔널이 갖춰야 할 여러 역량 중 에 하나일 뿐이라는 인식이 높아졌다. 그저 계획에 맞춰서 지시받은 일만 하는 것이 아니라, 비즈니스와 고객 가치 창출에 개발자들이 직접 참여하는 것도 매우 중요하다고 주장한다. 소프트웨어 프로젝트의 여러 다른 방면에서도 개발팀의 책임이 있다는 인식이 산업계의 판도를 바꾸고 있다. 소프트웨어 프로페셔널들이 진화하도록 유도하는 것이다. 미리 세운(대부분 잘못 정의된) 계획에 따라 그저 기계적으로 코딩만 하는 것이 아니라, 계획, 일정 및 예산 등의 추산, 요구사항 분석, 팀 구성, 분석, 아키텍처, 제품 릴리즈, 우선순위 조정, 시연 그리고 사용자와 프로젝트 이해 관계자에게 정기적으로 피드백을 받는 단계까지 개발자가 수행하기 시작한 것이다.

 

프로페셔널의 진화

코드를 잘 작성하는 것은 소프트웨어 프로페셔널이 가져야 할 최소한의 요건이다.

 

애자일 매니페스토

우리는 스스로 소프트웨어를 개발하고, 다른 사람들이 개발하는 것을 도와주면서 더 나은 소프트웨어 개발 방법들을 찾고 있다. 이 과정에서 우리는 다음과 같은 가치를 중요하게 생각한다.  

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

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

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

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

더 가치있게 여긴다.  

좌측의 사항도 가치가 있음을 인정하지만 우리는 우측의 사항에 더 높은 가치를 둔다는 것이다.

 

애자일 매니페스토의 원칙들

애자일 매니페스토의 원칙들 열두 가지 원칙들은 다음과 같다.     

1. 가치있는 소프트웨어를 일찍, 지속적으로 전달하여 고객을 만족시키는 것을 최우선으로 한다.   

2. 개발의 막바지 단계이더라도 고객의 요구사항 변경을 환영한다. 애자일 프로세스들은 변화를 활용하여 고객의 경쟁력을 높이는 데 기여한다.   

3. 동작하는 소프트웨어를 몇 주에서 몇 개월 단위로 자주 전달한다. 가능한 한 전달주기를 짧게 한다.   

4. 비즈니스 담당자들은 프로젝트 기간 내내 매일 개발자와 함께 일한다.   

5. 프로젝트는 동기가 부여된 개인들로 구성한다. 그들이 필요로 하는 환경과 지원을 제공하고 프로젝트가 완료될 때까지 믿고 맡긴다.   

6. 개발팀 내에서 정보를 전달하는 가장 효율적이고 효과적인 방법은 얼굴을 마주보고 대화하는 것이다.   

7. 프로젝트의 진척도를 가늠하는 가장 기본 요소는 동작하는 소프트웨어다.   

8. 애자일 프로세스들은 지속 가능한 개발을 이끈다. 투자자, 개발자, 사용자들은 일정한 개발속도를 계속 수용할 수 있어야 한다.   

9. 기술적인 탁월함과 좋은 설계에 대한 지속적인 관심은 기민함을 높인다.

10. 단순함, 즉 하지 않아도 될 일은 최대한 하지 않아야 한다.

11. 최선의 아키텍처, 요구사항, 설계는 스스로 조직화되는 팀에서 나온다.

12. 개발팀은 정기적으로 일을 어떻게 하는 것이 더 효과적인지 되돌아보고 그에 맞추어 일하는 방식을 조율하고 바로잡는다.

 

부분적인 전환

많은 기업들이 표면적으로는 애자일을 도입하려고 했지만 그 노력은 애자일스럽지 못했다. 대부분 그냥 따르기만 하면 갑자기 모든 것이 나아지는 처방전을 바랐다. 오늘날, 애자일이 별 효과가 없다고 이야기하는 기업과 개발팀들이 많다. 애자일로 전환했음에도 이전과 비교해 실제로 크게 나아진 것이 없다고 말한다. 소프트에어 프로젝트에서 가장 중요한 결과물이 소프트웨어 자체라는 점을 잊은 것 같다.

 

애자일 전환은 절차에만 집중하고 사람들에 대한 기술적인 훈련에는 관심을 크게 두지 않는다. 즉 개발자의 역량을 키우는 데는 도움이 안 된다.

 

“절차만 개선하면 돼. 다른 것들은 괜찮아”. 기존의 똑같은 개발자, 똑같은 습관을 가진 사람들이 갑자기 멋진 소프트웨어를 만들기 시작할 것이라 믿는다. “코딩은 쉽다. 코딩은 그냥 지엽적인 세부 사항일 뿐이다. 우리는 더 나은 절차만 있으면 된다.” 불행하게도 결코 그렇지 않다.

애자일의 배경이 되는 기본 원칙이 잊혀졌다. 기술적 탁월함보다 절차가 더 중요해졌다. 애자일의 모든 절차들에는 기술적 탁월함이 전재되어 있다.

 

애자일이나 린(lean) 커뮤니티에는 도요타의 사례를 좋아하는 사람들이 많다. 도요타가 절차를 개선해서 낭비(또는 재고)를 줄이고, 중간 제품(WIP)이 넘쳐나는 것을 막는 등 얼마나 훌륭한 성과를 거두었는지 이야기한다. 일부 애자일 코치와 컨설팅 업체들은 정보에 어두운 어리숙한 고객(기업)에게 이러한 도요타의 성공 사례를 팔기도 한다. 자동차를 만드는 것과 소프트웨어를 만드는 것은 다르다. 아직 완성되지 않은 자동차가 도로에서 운행되거나, 이미 팔린 자동차에 문짝을 하나 더 달아 달라고 하거나, 엔진을 앞에서 뒤로 옮겨달라고 공장으로 되돌려 보내는 일은 없다. 하지만 소프트웨어는 그런 일이 비일비재하다.

도요타 사례를 이야기할 때 “생산된 자동차의 품질이 나쁘다면? 시장에서 팔리지 않는다면? 너무 허술해서 한 달에 한 번씩 수리를 해야 한다면?”과 같은 상황은 거의 고려되지 않는다. 도요타가 성공할 수 있었던 중요한 요인은 절차를 개선하는 것뿐만 아니라 자동차의 품질에 이미 충분한 역량과 그를 뒷받침하는 노력이 있었기 때문이다.

 

도요타 자동차를 살 때에는 자동차의 품질을 고려할뿐이지 공장이 어떤 과정으로 돌아가는지는 별 관심이 없다.

 

소프트웨어 프로젝트를 바라보는 편협한 시각

해외 아웃소싱에서도 대단히 실망스러운 사례들을 보았다. 기업의 의사결정권자들이 이런 식으로 일을 하면서 어떤 다른 결과를 기대하는 건지 이해할 수가 없다. 산더미의 문서들을 얼굴 한번 본 적 없고 어떻게 선발되었는지도, 어떤 역량이 있는지도 모르는 개발자들한테 맡기고서는 모든 요구사항을 충족하는 소프트웨어가 짠 하고 나타날 거라고 정말로 믿는 것인가?

 

 

 

Chapter 3. 소프트웨어 장인정신

좀더 주관적인 정의

소프트웨어 장인정신은 소프트웨어 개발자가 스스로가 선택한 커리어에 책임감을 가지고, 지속적으로 새로운 도구와 기술을 익히며 발전하겠다는 마음가짐이다. 소프트웨어 장인정신은 책임감, 프로페셔널리즘, 실용주의 그리고 소프트웨어 개발자로서의 자부심을 의미한다.  

 

짧은 정의

소프트웨어 장인정신은 소프트웨어 개발의 프로페셔널리즘에 대한 것이다.  

이 부분이 소프트웨어 장인정신에서 가장 중요한 내용이다. 이 책에서 단 한 가지만 알아야 한다면 이 문장을 기억했으면 한다.

 

공예, 사업, 엔지니어링, 과학 또는 예술

개인적으로는 장인(개발자)과 공예품(소프트웨어)이라는 비유가 좋다. 하지만 정말 중요한 것은 비유가 아니라 그 비유가 상징하고, 장려하는 가치와 행동들이다.

소프트웨어 장인정신은 시켜야만 일하는 역량 미달의 노동자가 아니라 소프트웨어 프로페셔널의 수준을 높여, 프로의 모습으로 일하는 소프트웨어를 개발자를 지향한다.

 

매니페스토

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

동작하는 소프트웨어뿐만 아니라, 정교하고 솜씨 있게 만들어진 작품을,

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

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

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

이 앞의 항목들(일반 굵기)을 추구하는 과정에서, 다음 항목들(볼드체)이 꼭 필요함을 의미한다.

 

동작하는 소프트웨어뿐만 아니라, 정교하고 솜씨 있게 만들어진 작품을

동작하는 소프트웨어라고 해서 잘 만들어진 애플리케이션이라고 할 수 있을까? 좋은 소프트웨어라면 그 애플리케이션이 얼마나 오래되었든 간에 개발자가 쉽게 이해할 수 있어야 한다. 부작용도 알려져 있어야 하고 관리가 가능해야 한다. 높은 커버리지에 신뢰할 수 있는 테스트가 가능해야 하고, 명료하고 단순한 디자인과 비즈니스 용어로 잘 기술된 코드여야 한다. 새로운 기능을 추가 및 수정하는 일이 처음 애플리케이션을 개발할 때와 비슷한 수준의 개발 공수로 완료될 수 있어야 하고 코드 베이스 자체도 최대한 작아야 한다.

소스 코드는 예측가능하고 유지보수될 수 있는 상태여야 한다. 코드를 수정할 때 어떤 일이 일어날지 개발자가 알 수 있어야 하고 수정 자체가 두려운 상황에 처하지 않도록 해야 한다. 변경사항이 있더라도 그 영향이 해당 기능 모듈에만 국소적으로 제한되며 애플리케이션의 다른 부분에 파급효과가 없어야 한다. 몇 분 또는 몇 초 만에 전체 애플리케이션에 대한 자동화 테스트가 구동되어 잘못된 부분이 있는지 파악 가능해야 한다.

애플리케이션이 진화하려면 개발자들이 애플리케이션을 수정하는 일을 부담스러워해서는 안 된다. 테스트 주도 개발, 단순한 디자인, 비즈니스 용어로 표현된 코드는, 코드를 건강하고 잘 만들어진 상태로 유지하는 최선의 방법이다.  

 

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

기업이 소프트웨어 프로젝트에 비용을 들이는 유일한 이유는 돈을 벌거나, 돈을 아끼거나, 아니면 매출을 지키기 위해서다. 기업의 그러한 목적을 달성시키기 위해 우리가 일하고 있음을 늘 인식해야 한다.

매니페스토의 계속해서 가치를 더한다라는 의미는 신규 기능을 추가하거나 버그 수정만을 뜻하지는 않는다. 코드를 깔끔하게 정리하고 구조를 개선하며 확장성을 높이고, 테스트 가능하게 하고, 쉽게 유지보수할 수 있게 하는 것을 포함한다. 소프트웨어가 나이를 먹고 덩치가 점점 커지고 있다면 동시에 우리는 기업의 이익도 늘어나게 해야 한다. 프로젝트에 새로운 기능들을 추가하고 수정하는 속도가 프로젝트 초기와 다를 바 없으면 소프트웨어가 얼마나 오래되었든지 관계없이 시장에 빠르게 대응할 수 있다. 소프트웨어가 오래될수록 고통과 비용이 아닌 그 가치가 커져야 한다.

소프트웨어의 생명을 늘리면서 변화에 빠르게 대응할 수 있도록 유지하는 것이 우리의 주요 목표다.

 

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

 

애플리케이션의 수명을 오래 유지시키려면 소프트웨어의 품질에 최우선으로 집중해야 한다. 수년에 걸쳐 애플리케이션을 완전히 다시 만들게 되면 투자 대비 효과가 크게 떨어진다. 애플리케이션을 재작성한다는 결정은 보통, 기존 애플리케이션의 유지보수 비용이 감당하기 어려울 정도로 높아지면 하게 될 때가 많다.  

문제는, 유지보수 비용이 높은 기존 애플리케이션을 개발했던 바로 그 잘못된 방법으로 새로운 애플리케이션을 개발하여, 몇 달 또는 몇 년 후 똑같은 오류를 반복한다는 점이다. 이러한 악순환을 끊고 제대로 된 애플리케이션을 개발하는 것이 우리의 역할이다.  

 

같은 일을 반복하면서 다른 결과를 기대하는 것은 미친 짓이다.

-앨버트 아인슈타인Albert Einstein  

 

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

소프트웨어 장인정신의 중심에는 멘토링과 공유가 있다. 소프트웨어 장인은 항상 열정적으로 자기발전을 추구한다. 이보다 더 큰 임무가 있다. 다음 세대의 장인을 준비시킬 책임이 있다.

 

소프트웨어 장인정신이 엘리트 주의라고 생각한다면 이는 소프트웨어 장인을 오해하는 것이다. 소프트웨어 장인은 항상 다른 사람에게 배우려 하는 겸손한 사람이어야 하고 경험이 적은 개발자와 지식을 공유하기를 주저하지 않는 사람이어야 한다.

 

상대에게 배우는 것은 더 나아지기 위한 최선의 방법이다.

 

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

생산적인 동반자 관계는 어떤 순간이든 고객에게 가치를 제공하는 것을 의미한다.

고객이 속한 산업의 본질이 소프트웨어 개발이 아닌 다른 것인 때가 많다. 이때는 소프트웨어 프로젝트가 성공하도록 돕는 것이 전적으로 우리들이 해야 할 일이다. 그것이 우리가 대가를 받는 이유다. 코드와 관련된 일이 아니면 나의 일이 아니라고 생각하는 개발자는 진정한 소프트웨어 장인이라고 할 수 없다.  

 

 

 

Chapter 4. 소프트웨어 장인의 태도

내 커리어의 주인은 누구인가

소프트웨어 프로페셔널로 대우받기를 원한다면 프로처럼 행동해야 한다. 이는 스스로를 발전시키는 데 자신의 돈과 시간을 들여야 한다는 것이다. 나 자신의 커리어의 주체로서 언제, 무엇을 배울지를 스스로 결정해야 한다. 고객, 고용자를 도와줄 수 있는 위치에 있어야 한다. 자신이 일하는 회사가 새 지식을 가르쳐 주길 기대한다면 이는 프로페셔널 소프트웨어 개발자가 아니다. 개발자로 가장한 공장 노동자일 뿐이다.

 

끊임없는 자기계발

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

- 장 보드리야르Jean Baudrillard

 

카타

카타는 ‘품세’라는 뜻으로 일본 무예 훈련에서 나온 용어다. 소프트웨어 카타는 작은 훈련용 코딩들을 의미한다.

 

사실 일본의 무예 훈련에 대한 정확한 용어는 ‘게이코’다. 이미 세계적으로 개발자들이 카타라는 용어를 사용하고 있기 때문에 그냥 카타라고 표현한다.

 

펫 프로젝트

펫 프로젝트는 취미생활과도 비슷한 나만의 소프트웨어 프로젝트다. 대신 일정이나 예산 등 압박 요인이 아무 것도 없다. 수익을 낼 필요도 없고 요구사항도 내 마음대로다. 특히 어떤 기술과 방법론을 적용할 것인지는 내키는 대로 정할 수 있다. 내가 바로 사장이다.

 

페어 프로그래밍

개발자들에게 코딩할 때 누군가 옆에서 지켜본다고 상상해보라고 하면 불편함이나 두려움을 느끼는 것이 대부분이다. 오래 전에 나 역시 그러했다. 그 불편함과 두려움의 근원이 나의 한계가 드러날 수 있다는 걱정에서 온다는 것을 깨달았다.

 

누군가를 가르치다보면 내 생각을 구조화할 수밖에 없어서 설익은 개념을 제대로 이해하고 가다듬게 된다. 그러고 나면 다른 사람도 이해시킬 수 있다.

 

의도한 발견

나는 아테네에서 가장 똑똑한 사람임에 틀림없다. 왜냐하면 나는 내가 아무것도 모른다는 사실을 알기 때문이다.

- 소크라테스Socrates  

 

소프트웨어 프로페셔널이 할 수 있는 최대의 실수는 자신이 모르는 것을 모른다고 받아들이지 않는 것이다.

 

필립 G. 아모어의 ‘무지의 5단계’
0단계: 무지의 부재
"어떤 것을 알고 있음을 증명할 수 있을 때, 0OI라고 한다."
0OI의 단계는 질문과 답을 가지고 있다는 것을 뜻합니다. 예를 들면, "유지보수 가능한 엔터프라이즈 소프트웨어를 구축하는데 어떤 프로그래밍 환경이 적합한가?"라는 질문에 "자바"라고 답하는 것입니다. 물론, 이 질문에는 여러가지 다른 답이 있을 수 있지만 요점은 당신이 질문과 답을 다 가지고 있다는 사실입니다. 이런 경우 자바로 유지보수 가능한 엔터프라이즈 소프트웨어를 작성함으로써 무지의 결핍을 설명할 수 있습니다. 0OI 상태에 도달했을 때 효과적인 해결책을 얻기 위해서는 시간과 실행의 문제만 있을 뿐입니다.

1단계: 지식의 부제 
"어떤 것을 알지 못할 때 1OI라고 한다."
1OI 단계는 답을 할 수 있도록 질문 영역에 관해 충분한 정황을 포함하는 적격 질문을 가지고 있다는 것을 뜻합니다. 예를 들면 "데이터베이스에, create, read, update, delete 동작을 지원하는 웹 사용자 인터페이스를 빨리 구축하는데는 무엇을 사용할 수 있습니까?"라는 질문이 있따고 합시다. 이 경우 루비 온 레이스(ruby on Reils)가 한가지 답이 될 수 있다. 1OI에서는 질문 자체가 상당히 구체적인 지식을 포함하고 있다. 1OI상태에 있지 않음을 보여주는 이와 반대되는 예시는 "시스템의 요구사항은 무엇인가?"입니다. 이 질문은 1OI이라고 부르기에는 너무 모호하며 사실 이 질문은 2OI를 나타냅니다.

2단계: 인식의 부재
"어떤 것을 알지 못한다는 그 자체를 모를 때 2OI라고 한다."
2OI 단계는 어떤 질문을 해야 하는지조차 모르지만(이 부분이 중요함) 어떤 질문을 해야하는지 알아낼 방법은 있다는 뜻입니다. 이 책을 집필하는 과정에 겪었던 개인적인 경험을 예로 들어볼 것입니다. 인터뷰의 음성을 필사할 때 오디오 플레이어의 재생 버튼을 누르고 위드 프로세서에 옮겨적은 작업을 번갈아 하느라 상당히 많은 시간을 낭비하고 있다는 사실을 알았습니다. 나는 "타이프를 치는 동안 플레이어를 발로 밟는 페달로 작동할 수 있다면 좋지 않을까?"하고 생각했습니다. 필립 아모어는 이런"~면 좋지 않을까?"라는 질문을 "메타 질문"이라고 하며 2OI라는 것을 입증하는 하나의 지표라고 합니다. 나는 질문을 "페달로 재생버튼을 작동 할 수 있는 상품이 있을까?"로 바꾸어 단계는 1OI로 낮추었습니다. 그리고 분명 시장에는 그런 상품이 많이 있었습니다. 나는 하나를 구입하여 문제는 0OI로 다시 낮추었습니다. 이 경우 문제 자체는 "나는 필사를 더 빨리 할 방법이 필요해"가 2OI에서 1OI로 줄이는 열쇠였다는 것입니다. 많은 경우 그 영역으 지식이 있다는 점에서 2OI는 1OI로 줄이는 중요한 열쇠입니다.

3단계: 효율적인 프로세스의 결여 
"무언가늘 모른다는 사실을 알지 못한다는 것을 밝혀낼 적절하고 효과적인 방법이 없을 때 3OI라고 한다."
3OI단계는 무엇을 질문해야 할 지 모르고 또한 무엇을 질문할 이 아는 좋은 방법조차 모른다는 뜻입니다. "적절하고 효과적인"이라는 말이 아주 중요합니다. 소프트웨어 개발에 있어서 여러분의 시스템에서 3OI를 발견하기 좋은 방법은 그 시스템을 운영환경으로 전환하는 것입니다. 여러분의 소프트웨어 개발 철학에 좌우되기 때문에 3OI를 발견하는 데 있어서 "적절하고 효과적인"방법이 될 수도 있고 그렇지 않을 수도 있습니다. 여러분이 끊임없는 베타 인터넷 스쿨에서 나왔다면 적절하고 효과적인 방법이 될 것입니다. 카우보이 같은 접근 방법을 선호하지 않는다면 적절하고 효과적인 방법이 되지 않을 것입니다.
예를 들어 사람들이 내 웹사이트를 방법하는 것에 대한 보고서를 생성하기 위해 웹 로그를 분석하는 소프트웨어를 작성하고 있다고 합시다. 그런 문제는 웹분석학의 영역의 영향을 받습니다. 웹 로그 분석 소프트웨어 작성의 문제에 직면했지마 "웹분석학"의 문제 영역을 알지 못한다는 것이 3OI가 되는 한 예입니다. 또 다른 예를 들면, 수 테라바이트에 이르는 대용량의 데이터를 처리하는 어떤 소프트웨어를 만들어야 하는 경우입니다. 이 때 Google의 MapReduce 프레임워크(http://labs.google.com/papers/mapreduce.html)를 알지 못한다는 것이 3OI의 예가 될 것입니다.

4단계: 메타무지
"무지의 5단계에 관해 알지 못할 때 4OI라고 한다."
아모어의 체계에서 이것은 약간 놀림조의 말인데 4OI는 무지의 단계에 대한 무지입니다.

필립 아모어는 그의 책[The Laws Of Software Process]에서 무지의 5단계의 기본적인 철학을 확장했습니다. 
http://hillbillylady.blogspot.com/2011/02/g-5.html

 

생각 가능한 모든 측면에서 우리가 파악하지 못한 것을 찾아내기 위해 시간을 투자해야 한다. 이러한 투자는 수익률이 대단히 높다.

무지는 상숫값이다.

 

무지는 프로젝트에서 가장 큰 단일 장애요소다. 즉 무지의 수준을 최대한 빨리 낮추면 낮출수록 업무 생산성과 효율이 매우 높아진다.

모르는 것을 배우는 기회를 만들기 위해 항상 노력해야 한다. “내가 무엇을 모르는지 알지 못하는데 어떻게 그걸 배울 기회를 만들 수가 있나?”라고 반문할 수도 있다.

 

일과 삶의 균형

업무 외 개인 시간을 내어 커리어에 대한 투자해야 한다고 하면 항상 “그럴 시간이 없다.”라는 대답이 돌아온다. 당신도 그렇게 생각할 수 있다. 어쩌면 그것이 맞다. 그것은 당신이 그렇게 믿기로 결정한 것이고 그에 따라 현실이 되었다. 진실은, 우리는 항상 시간이 있다는 것이다. 시간을 최적화하지 못할 뿐이다. 우리 커리어에는 그다지 중요하지도 않은 다른 일에 시간을 소모하고 있을 가능성이 높다.

 

시간 만들기

시간이 부족하다는 점을 게으름에 대한 변명으로 이용할 때를 꽤 자주 본다.

 

이러한 활동들이 긴장을 풀고 휴식을 취하는 좋은 방법이기는 하지만 매일 저녁 또는 밤을 새우면서까지 할 이유는 없다.

 

집중: 뽀모도로 기법

1 어떤 일을 할지 정한다.   

2 뽀모도로(타이머)를 25분에 맞춘다.   

3 타이머가 끝날 때까지 그 일을 한다.   

4 짧게 쉰다(보통 5분).   

5 매 4회의 ‘뽀모도로’마다 길게 쉰다(15~30분).

 

균형

업무 외에는 아예 컴퓨터에 손을 대는 것조차 싫은 사람이라면 현재의 커리어를 다시 생각해보는 것이 좋다.

 

요약

시간이 없다는 말은 더 이상 변명이 될 수 없다. 우리는 항상 시간이 있다. 우리는 모두 정확히 같은 만큼의 시간이 주어진다. 차이점은 우리가 그 시간을 어떻게 쓰느냐일 뿐이다.

 

 

 

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

비즈니스 팀에 있던 친구들이 보기에는 아키텍처 팀은 터무니 없는 일을 하고 있었다. 차에서 잠을 자고, 야근수당도 없이 그렇게 오래 일하는 것은 정상이 아니었다. 친구들은 “도대체 요즘 뭘 하고 있는 건가? 왜 참고 있나?”라고 물었다. 나의 머릿속에는 그런 개념이 없었다. 나는 아직 미혼에 혼자 살고 있었고 일이 좋았다. 무엇보다도 내가 무엇을 해낼 수 있는지 보이고 싶었고, 팀원 모두가 프로젝트를 성공해내길 바랐다. 우리 모두는 영웅이 되고 싶었다. 프로젝트를 통해 많은 것을 배우고 있었고 경험 많은 팀 동료들과 어울리는 것도 좋았다. 특히 고품질의 좋은 코드를 작성하는 일이 즐거웠다. 팀 동료들은 모두 그렇게 생각했다. 모두가 지치고 힘들었지만 마음 깊은 곳에서는 즐기고 있었다.

돌이켜 보면 정말 말도 안 되는 일을 했다는 것을 깨닫는다. 우리는 프로페셔널하지 못했다. 우리가 왜 그 일을 하는지 스스로 묻지 않았다. 고객이 실제로 무엇을 원하는지 이해하려 하지 않았고 다른 대안을 제시하지도 않았다. 고객을 만날 수도 없기는 했지만, 요구사항에 대해서 질문을 하지도, 실행할 수 없다는 이야기도 하지 않았다. 우리는 그냥 주어진 환경을 있는 그대로 두고, 무작정 일을 밀어 붙였다. 그때는 그것이 프로페셔널이라고 생각했다.

마음 깊은 곳에서는 인정과 명예를 원했다. 우리는 프로젝트를 구한 영웅으로, 불가능한 일을 해낸 사람으로 보이고 싶었던 것이다. 결국 그 모든 노력은 헛고생으로 끝났다. 일정은 늦춰졌고 비즈니스 부서의 그 누구도 우리가 얼마나 노력했는지 알아주지 않았다. 우리는 명예를 얻지도 못했고, 그저 값싸게 노예처럼 일하는 개발자들에 불과했다. 요구받은 거의 모든 것들을 힘겹게 완료했지만 그 누구로부터의 설명도 없이 그냥 일정이 늦춰져 버렸다. 우리가 노예처럼 일할 때 영업, 비즈니스 부서 사람들은 항상 정시에 퇴근해 가족과 시간을 보냈다. 우리는 영업팀과 비즈니스 팀을 위해 헌신한다고 생각했지만 당사자들은 실상 아무런 생각도 없었다. 상명하복의 위계 구조에서 이뤄지는 거의 모든 결정들이 우리에게는 보이지 않았다. 우리는 그저 모든 부담을 떠안고 힘들게 일만 하는 공장 노동자에 지나지 않았다. 그 당시에는 그런 것들을 몰랐다. 오히려 그 부담이 좋았다. 우리 팀에는 실력있는 동료들이 가득했고 그들과 함께 일할 수 있다는 것이 기뻤다.

우리는 일을 잘못하고 있었다. 당시 우리가 어떤 취급을 받았는지 떠올리면 가슴이 아프다. 아직도 그러한 일이 비일비재하다는 사실에 더욱 속이 상한다. 우리의 행동이 프로답지 못했음을 지금은 이해한다. 철없던 어린 시절을 떠올리는 것처럼 그때의 일들이 부끄럽고 안쓰럽다. 우리가 무엇을 하고 있는지, 실제 어떤 문제가 있는지 한번도 질문하지 않았다. 대안을 제시하려 노력하지도 않았다. 우리를 공장 노동자처럼, 노예처럼 취급하도록 내버려 두었다. 공장 노동자처럼, 노예처럼 행동했고 그를 즐기기까지 했다. 회사에도 해를 끼쳤다. 우리는 연이은 실수들을 했다. 새벽 3시에 전체 상용 데이터베이스를 삭제하기도 하고 전혀 필요도 없는 것들을 만들기도 했다. 실제 이슈에 대해서 제대로 이해하지도 못했고 더 나은 솔루션을 낼 수 있도록 상황을 바꾸지도 못했다. 개인적인 삶을 버렸을 뿐만 아니라 늦은 야근 후 자동차에서 잠을 자고, 12시간 이상 일하지 않는 사람을 차별하기도 했다. 우리는 전혀 프로답지 못했다. 한번도 ‘아니오’라고 말하지 않았기 때문이다.

 

‘아니오’라고 말하는 방법 배우기

빠듯한 일정과 상급 관리자로부터의 많은 압박 속에서 상당수의 프로젝트가 진행된다. 이러한 일정들은 비현실적일 때가 대부분이다. 보통 상급 관리자들은 계약 기간 내에 프로젝트를 끝내려는 욕심에 의도적으로 무리하게 일정표를 만들어 개발자들을 밀어 붙인다. 특히 젊은 개발자들은 그러한 무리한 요구에 굴복하고 일정 안에 해보겠다는 약속을 하고 만다. 상급 관리자에 대항하는 것을 두려워하거나, 아니면 그냥 논쟁자체를 피하려 한다. 그 모든 기능들을 주어진 일정 안에 완료한다는 것이 불가능함을 알고 있으면서도 상급 관리자의 요구를 그냥 받아들이고 그대로 실행한다.

이에 따른 결과는 참혹하다. 릴리즈 버전 소프트웨어에 버그가 가득하고 고객은 화를 내며 신뢰는 바닥으로 추락한다. 개인 생활과 사랑하는 가족을 희생하면서 아무리 오랫동안 일을 하더라도 부실한 결과물에 시달릴 수 밖에 없다. 정작 불가능한 것을 알면서도 그렇게 개발자들을 압박한 바로 그 상급 관리자 자신은 집에 일찍 들어가고 주말을 가족들과 즐긴다. 그러고는 모든 책임을 개발자들에게 뒤집어 씌운다. 모든 문제는 개발자들의 능력이 부족해서, 개발자들이 더 열심히 일을 하지 않아서, 개발자들이 약속을 지키지 않아서 라고 한다. “아니, 분명 이날까지 완료한다고 약속해 놓고 왜 못했나? 어떻게 이런 말도 안 되는 버그를 심어 놓았나? 초당 10000 트랜잭션도 처리 못하는 시스템을 지금 쓰라고 만들어 놓은 건가?”라는 식이다.

 

교훈

프로젝트 매니저뿐만 아니라 개발자들도 전혀 프로답지 않았다. 이미 불가능하다고 알고 있는 것에 대해 ‘해보겠다’라고 말하지 말았어야 했다.

 

상사에게 대항할 수 없다는 불편함과 전체 상황 자체에 대한 증오 말고도 그렇게 무책임하게 밀고 나간 또 다른 원인이 우리 마음 속에 있었다. 마음 깊은 곳에서는 스스로가 얼마나 잘났는지 내보이고 싶었던 것이다.

 

스스로 도박을 선택했다.

 

대단히 나쁜 방식이었지만, 프로젝트 매니저의 입장에서는 그의 미션인 ‘모든 기능들을 일정 안에 개발 완료하여 마케팅에 전달하는 것’을 수행하려 했다. 프로젝트 매니저가 자신의 미션을 수행하려 했듯이, 개발자들도 개발자로서의 미션을 해냈어야 했다. 상용화 수준에 미달되는 저품질의 소프트웨어가 될 수밖에 없다면 주어진 조건들을 거부했어야 했다. 현실적으로 행동했어야 했다. 새 기능을 추가하라는 지시에 개발자와 마케팅 팀이 협의하지 않고서는 기능을 개발할 수 없음을 명확히 했어야 했다. 설령 모든 기능이 구현되더라도 시스템이 다운되면 전혀 의미가 없다는 점도 전달했어야 했다. 우리가 영웅이 될 수 있다는 망상에 사로잡혀 프로페셔널하게 행동하지 못했다. 우리는 ‘아니오’라고 말할 수 있어야 했다.

 

프로답게 행동하기

일정 안에 모두 완료하는 것이 거의 불가능한 상황이라는 것을 분명히 알면서도 상사에게 “노력해보겠다.”라는 말을 어떻게 할 수가 있나? 노력해 본다는 것의 의미가 무엇인가? 열심히만 하면 갑자기 불가능하던 일이 가능해지고 전부 완료할 수 있다는 것인가? 아니면 개인 생활과 가족을 모두 희생하고 야근과 휴일 근무를 밥먹듯이 하겠다는 뜻인가? 그런 뜻이라면 오래 일한다고 달라지는 것이 있나? 그렇지 않다면 평소 일을 대충하고 있다는 고백임과 동시에 거짓말을 하고 있다는 것이 된다.

차드 파울러Chad Fowler는 저서 『열정적인 프로그래머』에서 그저 실망시키지 않기 위해 말하는 ‘네’는 거짓말에 지나지 않는다고 했다. 그냥 거짓말이 아니라 중독적이고 파괴적인 습관이다. 양의 탈을 쓴 나쁜 습관이다.

‘안 된다’, ‘할 수 없다’라는 부정적인 말을 하길 꺼린다. ‘아니다’라고 말할 때 우리는 무언가 실패한 듯한, 무언가 협조하길 거부한 기분, 좋은 팀원이 되지 못한 듯한 기분이 든다. 우리는 같이 일하는 사람을 실망시키는 것을 가장 싫어한다. 성공하길 원하고 우리의 역량을 후회없이 최대한 발휘하고 싶어한다. 언뜻 보기에는 긍정적인 사고방식같지만, 그 이면에는 대단히 이기적인 욕구가 숨어 있다. ‘네’라고 말할 때 사람들은 그 말을 믿고 그에 의존해서 계획을 짠다는 것을 반드시 기억해야 한다. 상사는 우리의 말을 믿고 그 상사에게, 다른 팀들에게, 고객에게, 다른 여러 관계자들에게 약속을 한다. 정직하지 못하고 불투명하면 회사 전체에 피해를 입힐 수 있다. 프로페셔널리즘은 나 자신과 팀 동료들 그리고 관리자들과 고객들에게 정직함을 의미한다.

 

대안 제시

항상 ‘아니오’라고만 얘기하는 것은 프로다운 태도가 아니다. 모든 ‘아니오’ 에는 반드시 하나 이상의 대안들이 따라와야 한다. ‘아니오’라고 대답하기 전에 문제를 분석해서 대안이 있어야 한다.

 

아무런 대안 없이 그냥 안 된다고만 하면 그 대답을 듣는 사람 입장에서는 뭔가 할 수 있는 여지가 없기 때문에 상황에 별 도움이 안 된다. 이와 관련하여 다음과 같은 일화가 있다. 어떤 상사가 두 젊은 부하 직원에게 오렌지 주스를 사오라고 지시했다. 첫 번째 부하직원은 눈앞에 보이는 가까운 길 모퉁이의 주스 가게에 들러 오렌지 주스가 있는지 물어보고 5분만에 바로 돌아와서 “오렌지 주스가 없다고 합니다.”라고 바로 보고했다. 그런데 두 번째 부하직원은 20분이나 늦게 돌아왔다. 상사는 부하직원의 보고도 듣지 않고 “오렌지 주스가 없다는 것을 이미 알고 있다. 뭘 한다고 그렇게 늦었나?”라고 물었다. 그 두 번째 부하직원은 “말씀대로 오렌지 주스는 없다고 합니다. 하지만 파인애플 주스와 사과 주스는 있습니다. 파인애플 주스는 신선한 상태이지만 사과 주스는 병에 보관된 상태입니다. 주변 정보를 더 알아보니 좀 떨어진 곳에 큰 슈퍼마켓이 있다고 합니다. 거기서 오렌지를 사면 주스를 만들 수 있습니다. 파인애플 주스나 사과 주스도 괜찮으시다면 5분 안에 가져다 드릴 수 있습니다. 시간이 걸려도 오렌지 주스를 원하신다면 30분 정도 소요됩니다. 어떤 것을 원하십니까?”

첫 번째 부하직원은 보고를 빨리 하기는 했지만 상사에게 남는 것이 전혀 없다. 상사는 주변 상황에 대한 정보도 없이 자기 스스로 문제 해결 방법을 찾아야 한다. 반면에 두 번째 부하직원은 상사에게 대안을 제시했고 상사는 그중 하나를 선택할 수 있다. 무엇이든 할 수 있다는 태도는 어디서든 환영받는다. 우리가 ‘아니오’라고 대답해야 하는 상황에서도 항상 ‘네’라고 말할 방안을 탐색해야 한다.

 

아무리 나쁜 상황에서도 우직한 정직함을 보여줄 수 있다면 프로페셔널의 조건 중 하나를 갖춘 것이다.

 

뜻밖의 실용적인 대안

첫 번째 일정을 맞추기 위해 코드의 품질을 희생한다면 그 다음 번, 그리고 그 이후의 일정을 지키기가 점점 더 어려워질 것이 뻔했다.

 

깨어 있는 관리자

만약 우리가 “네”라고 약속할 때마다 제때 완료를 했었다면 우리가 “아니오”라고 할 때 관리자들은 우리를 더 많이 믿어 줄 것이다.

 

관리자는 팀의 한 부분이다. 관리자도 팀과 동고동락해야 한다. 팀원 모두가 야근을 한다면 관리자도 야근을 해야 한다. 실무를 하지는 않더라도 피자나 간식거리를 사주면서, 개발자들은 격려하고, 농담으로 분위기를 북돋울 수는 있다. 그렇게 하면 팀원 모두가 같은 배를 탔다는 공동체 의식이 강화되고 프로젝트의 고통과 희열을 함께 느낄 수 있다. 무엇이 되었든 성과를 낼 수 있는 것에 몰입하는 분위기가 조성된다. 좋은 관리자는 외부의 압력으로부터 개발자를 보호하고 팀이 가진 장애요소들을 제거한다. 팀원들이 편안한 마음으로 자신감을 갖고 일할 수 있도록 해준다. 관리자는 화합의 촉매가 되어야 한다. 팀을 건강하고 행복하고 단결되게 하는 것은 관리자의 직무다.

 

요약

프로페셔널은 프로페셔널로서의 윤리의식과 행동수칙이 있다. 좋은 프로페셔널은 고객에게 해가 되는 일이라면 고객이 돈을 지불하고 그것을 원한다고 하더라도 하지 않는다. 고객이 내리는 결정이 소프트웨어 프로젝트에 전체적으로 어떤 파급효과가 있을지 고객 스스로 이해하고 있다고 기대하기는 어렵다. 이 부분을 파악해서 알려주는 것은 우리들의 몫이다. 의도한 대로 동작할 수 없거나, 실행 불가능한 무리한 일정에 대해서 “아니오”라고 답하는 것은 우리의 의무다. 이는 변호사, 회계사, 의사와 같은 다른 프로페셔널들에게 기대하는 바와도 완전히 동일하다. 이들 프로페셔널들에게 무엇을 어떻게 하라고 고객이 하나하나 지시하지는 않는다. 애초에 프로페셔널들은 고객이 그렇게 하도록 내버려두지도 않는다. 고객은 문제를 들고 프로페셔널을 찾아간다. 프로페셔널들이 그들의 경험과 지식을 활용해 그 문제를 다룰 방법들에 어떤 것들이 있고 각각의 장단점은 무엇인지를 알려주길 기대한다. 고객의 결정은 프로페셔널이 제공한 충분한 정보와 이해를 기반으로 이루어져야 한다. 프로페셔널이 생각하기에 올바르지 않은 결정을 고객이 밀어붙이려 한다면 당연하게도 프로페셔널은 그것을 거부한다. 우리도 그래야 한다.

 

 

 

Chapter 6. 동작하는 소프트웨어

전통적인 관리자들과 비즈니스 컨설턴트들이 절차와 문서의 중요성을 아무리 강조하고 싶어하더라도 소프트웨어 프로젝트에는 소스 코드 그 자체만큼 중요한 것은 없다. 나머지는 모두 부차적이다.

 

정원 돌보기

프로그래밍은 집을 짓는다기보다는 정원을 돌보는 것에 더 가깝다.

 

코드는 기계장치라기보다는 유기물이다. 코드는 정원처럼 지속적인 유지보수가 필요하다.

 

짧은 기간이라도 돌보기를 게을리하면 다시 아름답게 가꾸는 데 훨씬 더 많은 노력을 해야 한다. 오래 방치할수록 다시 보고 즐길 수 있는 상태로 되돌리는 데 더 많은 수고가 필요하다. 코드도 마찬가지다. 정기적으로 살피지 않으면 변화가 있을 때마다, 새 기능을 추가할 때마다 상태가 나빠진다. 잘못된 설계, 테스트 부족, 프로그래밍 언어나 도구의 미숙한 활용도 코드를 더 빨리 썩게 만든다. 점점 다른 파트의 코드들도 오염되고 결국 유지보수에 드는 비용과 노력이 감당할 수 없을 만큼 커져버린다.

 

보이지 않는 위협

코드의 품질에 제대로 신경을 쓸 시간이 없다고 말하는 사람들이 많다. 저품질의 코드 때문에 추가로 발생하는 버그 수정 시간과 테스트 시간은 어디서 갑자기 나타나는지는 알 수 없다. “원래 소프트웨어 프로젝트가 그런거 아닌가? 처음에는 개발하면서 쌓아 올리지만 테스트와 안정화 단계를 거칠 수밖에 없는 거 아닌가? 모든 소프트웨어 개발이 그렇지 않나?”라고 말하기도 한다.

 

자신이 만든 소프트웨어에 인질이 되는 상황

가장 큰 문제는 나쁜 코드가 개발자 외에 다른 사람들에게 보이지 않는다는 점이다. 개발자가 아닌 다른 사람이 문제를 인지했을 때는 이미 늦은 상태다. 코드의 품질을 돌보아야 하는 책임은 바로 개발자에게 있다.

 

평범한 개발자가 아닌 장인을 고용하라

우리 업계는 이제서야 코드의 품질이 프로젝트의 성공을 보증하지는 못하더라도 실패의 핵심 요인이 될 수 있다는 것을 배우고 있다.

 

기술적 부채에 대한 이야기

기술적 부채를 줄이는 것은 기존의 더러운 것을 청소하는 것이다. 이미 깨끗한 상태를 더럽혀서는 안 된다. 즉 어떤 상황이든 추가 코드로 인해 기술적 부채가 더해져서는 안 된다.

 

백로그에 기술적 부채를 더하는 행위는 개발자가 코딩을 하던 당시에 아무런 죄책감 없이 잘못된 코드를 그대로 반영했다는 것밖에는 설명이 안 된다.

 

우리는 올바른 것을 하길 원한다

상황을 솔직하고 투명하게 밝히고 며칠 더 늦게 안정적인 솔루션을 전달하기보다 버그가 좀 있더라도 일정 안에 전달하는 편이 더 낫다고 느낀다. 빨리 하는 것과 허술한 것은 다르다. 우리의 결정이 어떤 의미이고 어떤 결과를 가져오는지 우리는 잘 이해하지 못할 때가 많다.

 

단위 테스트 작성은 별개의 업무인가

첫 번째로, 단위 테스트는 우리가 코드를 작성하는 방식에 이미 녹아있는 것이지 별도의 작업이 아니다. 테스트하지 않았다면 코드 작성을 완료했다고 할 수 없다. 단위 테스트는 코드가 제대로 구현되었는지 확인하는 가장 좋은 방법이다. 테스트 주도 개발을 접해보지 못한 보통의 개발자들은 주어진 요구사항에 맞춰 동작할 거라고 ‘기대만 하는’ 상태로 코드를 작성하고는 바로 다음 요구사항의 구현에 들어간다. 즉 제대로 된 테스트 없이 코딩을 마무리한다. 기능 구현이 완료되었다고 할 수 있으려면 반드시 테스트까지 되어야 한다. 단위 테스트를 작성하도록 팀 단위에서의 합의가 있었다면, 기능 구현 완료에는 단위 테스트의 구현 및 테스트 완료까지 포함되어야 한다.

두 번째로, 우리가 공식적인 작업 일정표에 무언가를 올려 놓는다는 것은 제품 오너가 그중 중요하지 않다고 생각하는 것을 삭제할 수 있는 권리를 준다는 것과 같다. 단위 테스트 구현을 별개의 작업으로서 일정표에 올려놓게 되면 거의 대부분 기능 구현 자체와 맞먹는 규모로 시간표를 차지하게 된다. 경험이 부족해서 단위 테스트의 가치를 이해하지 못하는 제품 오너에게는 그 시간이 낭비로 비춰질 수도 있다. 제품 오너 나름의 역할에 충실히 하려는 차원에서, 더 가치 있는 다른 작업을 하고 싶은 욕심이 생길 수도 있다. 자신의 역할에 최선을 다하려는 선한 의도라도 결정의 파급 효과를 제대로 이해하지 못한 채 단위 테스트 구현 작업을 없애버릴 가능성이 높다. 이러한 일이 일어나지 않도록 소프트웨어의 품질에 책임을 지는 것은 우리 개발자들의 몫이다. 종국적으로 제품 오너가 원하는 것은 아무런 문제없이 의도대로 동작하는 시스템이고 그에 대한 책임은 우리에게 있다. 책임을 다하려면 단위 테스트뿐만 아니라 코드의 동작을 보증하기 위한 다른 복합적인 테스트들도 필요하다면 만들어야 한다. 제품 오너의 입장에서는 소프트웨어가 정상적으로 동작하는 한 개발자들이 세부적으로 어떤 일을 하든지 사실 별 상관이 없다.

 

항상 프로젝트에 다른 사람들도 있다는 사실을 인식하고 전체 프로젝트에 미치는 영향을 감안하여 책임있게 행동해야 한다. 자신이 짠 코드는 어떻게 동작하는지 잘 알고 있고 문제가 없을 터이니 테스트 코드를 따로 안 만들어도 된다고 주장하는 개발자는 대단히 자기 중심적이고 이기적인 사람이다. 소프트웨어 프로젝트는 팀워크다. 특정 개발자 한 사람을 위한 것이 아니다. 특정 개발자에게 쉽고 분명한 것이 팀내 다른 개발자에게는 난해하고 불분명할 수 있다. 시스템이 커짐에 따라 프로젝트에 관계된 모든 사람들이 개인의 작은 이기적 행동들 때문에 피해를 입게 된다.

 

레거시 코드

태도는 큰 차이를 가져올 수 있는 작은 요소다.

- 윈스턴 처칠Winston Churchill

 

그린필드 프로젝트 :: 백지상태에서 레거시 없이 시작하는 프로젝트

 

태도의 변화

무언가가 마음에 들지 않는다면 바꾸어라.

그것을 바꿀 수 없다면, 그에 대한 당신의 생각을 바꾸어라.

- 마리 엥겔브레이트Mary Engelbreit

 

아무리 한탄하고 불평하고 저주해보았자 삶이 쉬워지거나 나아지지 않는다는 점이다. 무언가 나아지길 원한다면 그에 맞는 행동을 취해야 한다.

 

보이스카웃 규칙 ‘처음 발견했을 때보다 더 깨끗하게’를 지속적으로 적용해야 한다.

 

남이 작성한 코드를 엉망이라고 그냥 말하기는 쉽다. 심지어 비웃을 수도 있다. 하지만 나라면 더 잘 만들 수 있는가? 라고 스스로에게 물어보아야 한다.

 

요약

회사와 개발자들은 정기적으로 도끼날을 가는 시간이 낭비가 아니라는 사실을 이해해야 한다. 바로 그것이 시간을 절약하고 끊임없이 빨리 움직일 수 있는 최선의 방법이다.

 

 

 

Chapter 7. 기술적 실행 관례

올바른 일 vs 올바른 실행

애자일 방법론은 변화와 싸우는 것이 아니라 변화 자체를 내재화한다.

 

실행 관례와 가치

사람은 우리가 원하는 대로 행동하도록 프로그램할 수 있는 기계가 아니다. 단순히 준수할 실행 관례를 공표했다고 해서 기대하는 결과가 나오지 않는다. 실행 관례는 우리가 매일 같이 습관처럼 해야 하는 것이다. 테스트 주도 개발(TDD)을 한다면 그것을 하거나 하지 않거나 둘 중 하나다. 지속적인 통합도 하거나 하지 않거나 둘 중 하나다.

 

어떤 가치를 중요시한다고 말하는 것만으로는 부족하다. 우리는 그 사람이 말하는 가치와 행동이 일치하는지 봐야 한다.

 

실행 관례를 통한 가치 창출

 

테스트 주도 개발

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

 

테스트가 코딩 방향을 주도하면 복잡한 코드를 작성하는 것 자체가 어려워진다. 그 첫 번째 이유는 정확히 요구사항만큼만 만족시키는, 즉 테스트로 규정된 부분만 작성하게 되기 때문이다. 첫 설계 단계에서는 요구사항을 확대 해석하고 미래에 있을지 모를 부가 조건들이 추가되기 쉬워 설계가 커지고 복잡해지는(BDUF: Big Design Up Front) 경향이 있다. TDD는 그렇게 되지 않도록 막아 준다. 두 번째는 코드가 복잡하고 방대하면 테스트 자체가 어렵기 때문이다. 테스트 대상 코드가 잘못된 설계와 과도한 복잡도를 가지고 있으면 새로운 테스트 코드를 작성하기가 점점 어려워진다. 이렇게 테스트 자체가 어려우면 설계를 재검토하고 코드를 더 단순하게 리펙토링하는 긍정적인 원인이 된다.

 

설계 리뷰는 물론 좋은 것이지만 TDD와 비교하면 두 가지 면에서 단점이 있다. 첫 번째는 설계 리뷰가 너무 잦으면 무엇이라도 기여하고픈 참여자의 욕구로 인해 객관성을 잃고 오버 엔지니어링이 되기 쉽다. 설계 리뷰 미팅은 주제가 구체적으로 잘 정의되었을 때 효과가 있다.

 

설계 리뷰는 반드시 큰 변화가 시작되기 전에 있어야 하고, 큰 모듈의 작업 진행 중에 몇 차례 정도가 적당하다. 설계 리뷰 미팅을 자주 하는 것은 바람직하지 않다. 변경 사항이 너무 크다면 더 작은 단위, 점진적인 단계로 나누어서 다루어야 한다. 반면에 TDD는 코드 한 줄마다 유용하게 활용되어 문제가 발생하는 즉시 피드백을 준다. TDD와 설계 리뷰 미팅이 서로 배타적인 것은 아니다. 둘 다 필요하다. 하지만 각각이 제공하는 가치와 피드백 루프의 주기가 다름을 이해하고 있어야 한다.

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

 

지속가능한 통합

실행 관례는 ‘일단 멈추고 버그부터 수정한다’는 태도가 필요하다. 팀원들은 어떤 일을 하고 있었던지 간에 하던 일을 멈추고 마지막 변경점에서 문제 부분을 수정하는 데 집중해야 한다. 시스템이 항상 배포 가능한 상태로 유지되고 버그가 누적되지 않는다는 점에서 효율이 높다는 장점이 있다.

 

페어 프로그래밍

코드 리뷰를 아예 하지 않는 팀은 버그를 가득 안은 코드가 문제를 일으킨 몇 달 뒤에나, 손을 쓸 수도 없는 상태에서 피드백을 받을 것이다.

페어 프로그래밍을 하면 코드가 작성되자마자 그 품질에 대해 피드백을 받을 수 있다(보통 ‘4개의 눈’으로 검증한다고 말한다). 개발자가 테스트를 작성하거나 변수 이름을 짓는 순간 다른 개발자가 즉시 “이 부분은 이해가 안 됩니다. 어떤 의미죠? 변수명을 notLoggedIn이 아니라 guest로 바꾸면 어떨까요? 이 메서드는 하나가 너무 많은 일을 합니다. 몇 가지 private 메서드로 분할하면 어떨까요?”라고 말하며 유지보수 용이성과 명료성에 대해서 피드백을 한다.

같은 페어끼리 너무 오래 있으면 효과가 적다. 하루 이틀 단위로 주기적으로 페어를 바꾸는 것이 좋다. 그렇게 하면 전체 시스템에 대한 이해도나 개발자의 스킬이 팀 차원에서 누적되어 올라간다. 더불어 코딩 표준을 정의하고 유지하는 데도 도움이 된다. 이러한 것들이 바로 가치다. 즉각적인 피드백 루프가 만들어진다.

 

리펙토링

보이스카웃의 ‘캠핑 장소를 처음 발견했을 때보다 더 깨끗하게 남겨두라’는 규칙은 소프트웨어 장인이 코드를 바라볼 때도 마찬가지로 적용된다.

개발자들은 이해하기 어려운 코드를 만났을 때 그것을 개선해보려 하기 보다는 그대로 내버려둔다. 괜히 수정했다가 코드를 망가뜨릴 수 있기 때문이다. 그래서 작은 워크 어라운드들과 중복 코드들을 만들면서 작업한다. 엉망인 코드가 많을수록 엉망인 코드가 늘어나는 속도도 빨라진다. 이것은 ‘깨진 유리창 법칙’으로도 알려져 있다. 지저분하고 엉망인 애플리케이션은 개발자들을 느리게 만들고 그로 인해 비즈니스도 느려진다.

 

전체 시스템을 더 좋게 만들 수는 있겠지만 그럴 필요 자체가 없을 수 있다. 몇 년 동안 바뀐 적이 없는 부분을 리펙토링하는 것은 의미가 없다. 애당초 코드를 수정할 필요가 없다면, 리펙토링해야 할 이유도 없다. 리펙토링은 더 자주 변경되는 부분을 대상으로 시작해야 한다. 보이스카웃 규칙은 모든 것이 아니라 해당 부분을 이해하여 변경할 필요가 있을 때, 적용해야 한다.

 

책임감

개발자이든 프로젝트 매니저이든, 비즈니스 담당이든, 이러한 실행 관례를 원하지 않는다고 하면 귀담아 들어야 한다. 기분 나쁘게 생각하거나 그 사람의 지식 부족을 의심할 이유는 전혀 없다. 우리는 그런 사람들과의 대화에서 배워야 한다. 하지만 앞선 섹션에서 설명된 가치들을 이야기 한 후 다음과 같이 되물어야 한다. “이러한 가치와 최소한 동등한 수준의 가치를 만들어 내기 위해 당신은(혹은 우리는) 무엇을 하고 있습니까? 이러한 실행 관례보다 더 나은 방법이 있습니까?”

우리의 의사 결정에 책임감을 가져야 한다. 여기에는 실행 관례를 도입하지 않는 결정도 포함된다. 이것은 개발자만의 이야기가 아니다. 관리자들 역시 팀이 특정 실행 관례를 따르지 못하도록 할 때 그에 대한 책임감이 있어야 한다. 우리는 이러한 결정들을 기록하고 문제가 있을 때 에스컬레이션 해야 한다.

 

실용주의

무언가를 절대적인 진리로 바라보는 것은 바람직하지 않다. 항상 우리가 무엇을 하고 있고 그것을 왜 하고 있는지 질문해야 한다. 지금 하는 방법보다 더 나은 다른 방법이 없는가? 우리가 선택한 실행 관례가 우리 프로젝트에 적합한가? 그 실행 관례의 가치는 무엇인가? 무언가 다른 것을 시도해볼 시점인가? 어떤 실행 관례가 다른 실행 관례보다 더 나은지 알아보는 가장 좋은 방법은 프로젝트에 어떤 가치를 주는지, 피드백 루프가 얼마나 긴지 비교해 보는 것이다. 나머지는 상관이 없다. 만약 검토 중인 실행 관례가 우리에게 어떤 가치를 주는지 판단되지 않는다면 도입을 보류해야 할 수 있다. 만약 비교 중인 두 실행 관례가 비슷한 가치를 준다면 팀에서 좀더 편하게 받아들일 수 있는 것을 선택하면 된다. 기억해야 할 것은 꼭 이렇게 해야만 한다라는 법은 없다는 점이다.

어떤 실행 관례를 도입했다고 해서 영원히 사용해야 하는 것은 아니다. 많은 애자일 원칙들이 이야기하고 있듯이 항상 점검하고 적응해야 한다. 특정 실행 관례가 더 이상 우리에게 가치를 주지 못한다면 그 실행 관례를 버려야 한다. 소프트웨어 장인으로서, 우리의 일에 항상 최선의 기술, 도구, 절차, 방법론 그리고 실행 관례를 선택할 수 있도록 개방적인 사고 방식을 가져야 한다.

 

 

 

Chapter 8. 길고 긴 여정

브라질 어느 십대 소년의 이야기

편안하고 익숙한 상태에서 벗어나 나를 발전시키고 배울 수 있는 기회를 지속적으로 찾아야만 한다는 것을 깨달았다. 나의 인생이고 나의 커리어이고, 내가 주인이어야 했다.

 

결단과 집중

요기 베라Yogi Berra는 ‘어디로 가고 있는지 모르고 있다면, 결국 가고 싶지 않은 곳으로 간다.’라는 말을 남겼다.

 

요기 베라 :: 향년 90세. 뉴욕 양키스의 전설적인 포수로 2015년 9월 23일(한국시간) 노환으로 타계했다. 1925년 미국 세인트루이스에서 이탈리아계 이민자 2세로 태어나 43년 뉴욕 양키스와 계약하고 46년 데뷔 무대를 치렀다. 1940~60년대 양키즈의 황금기를 이끈 대표 포수로 활동하며 홈런 358개, 타율 0.285를 기록했다. 현역 시절 그의 소속팀 양키즈가 월드시리즈에서 10번 우승을 차지해 챔피언 반지 10개를 획득했는데, 이 기록은 2015년 기준 아직 깨지지 않았다. 이 밖에 148게임 연속 무실책 기록을 달성하며 MVP 선수로 3번 선정되기도 했다. 1963년 선수로서 은퇴하자 양키즈는 베라가 사용했던 등번호 8번을 영구 결번시켰다.
이후 1964년 양키스의 감독으로 데뷔했으나 1년 만에 경질되고, 65년 뉴욕 메츠에서 플레잉 코치로 지내다가 72년 감독으로 승격하고 같은 해 메이저리그 명예의 전당에 입성했다. 1984년 다시 양키스 감독이 됐으나 조지 스타인브레너 구단주와의 불화로 2년 만에 물러났고 99년까지 양키스와 관련된 일을 하지 않았다. 1989년 휴스턴 애스트로스의 코치 생활을 끝으로 지도자 생활을 마무리했다.
그는 감독을 맡으면서 요기즘(Yogism)이라 불리는 많은 명언을 남겼고 은퇴 후에는 활발한 사회봉사 활동으로 존경을 받았다. 대표적인 요기즘으로는 ‘끝날 때까지 끝난 게 아니다(It ain’t over till it’s over).’ ‘어디로 가고 있는지 모른다면 결국 거기로 가지 못할 것이다(If you don’t know where you’re going, you might not get there).’ ‘기록은 깨질 때까지만 존재한다.’ 등이 있다.
[네이버 지식백과] 요기 베라 (시사상식사전, pmg 지식엔진연구소)

 

어디로 가기를 원하는지 커리어의 방향을 정하는 것이 중요하다. 이것은 장기적인 목표이고 중간에 많은 것이 바뀔 수 있다. 커리어를 몇 년짜리 프로젝트라 여기고 어떻게 관리할지 생각해보자. 프로젝트의 비전과 종국적인 목표를 이해했다면 가장 중요한 요구사항은 전달받은 것이다. 그것을 작은 단위로 나누고 점진적인 반복 작업으로 만든다. 작은 작업 단계마다 프로젝트의 목표를 재평가하고 필요한 경우에는 수정해야 한다. 우리의 커리어도 마찬가지다.  

 

어디로 가야 할지 모른다면

어디로 가고 싶은지 나조차도 모를 수 있다. 사실 우리의 커리어 방향을 정의한다는 것은 대단히 어려운 일이다. 딱 한번 결정하고 나면 그 이후로는 아무 생각없이 내달리기만 하면 되는 그런 것이 아니다. 우리는 지속적으로 그 결정을 재평가하고 다시 목표를 세워야 한다. 이때 단지 나의 열정만 고려하는 것이 아니라 개인적인 삶, 프로페셔널한 삶 속에 나타나는 모든 사건들을 고려해야 한다.

어디로 가고 싶은지 커리어의 방향을 확신할 수 없을 때는 모든 문들을 열어보기 시작해야 한다. 우리에게 기회가 나타날 수 있는 상황들을 만들어낼 필요가 있다. 다른 세상으로부터 고립되어 집안이나 사무실에만 웅크려 있기만 하는데 제발로 찾아와 노크를 하고 기회를 가져다 줄 사람은 없다. 좋은 기회를 제공해줄 수 있는 사람들이 나를 모른다면, 내가 어떤 사람이고 무엇을 하는지, 특히 얼마나 재능이 있는지 모른다면 그 사람이 나에게 기회를 제안할 턱이 없다. 밖으로 나가서 교류를 해야 한다. 세상이 나에게 접근할 수 있어야 한다. 다른 사람들이 나에게 다가오고 나와 이야기하는 것이 불편하지 않아야 한다. 커리어의 다음 여정을 어디로 해야 할지 모를 때 다른 사람 다른 회사들에서 나에게 선택지를 제안할 수 있는 환경을 만들어야 한다.

 

다음은 기회를 만들어 내기 위해 할 수 있는 몇 가지 활동들이다.

• 익숙하고 편한 것에서 벗어나 새로운 것을 공부하고 기술적 지식을 확장한다. 예를 들어 새로운 프로그래밍 언어나 기술들을 배운다.

• 지역 커뮤니티에 정기적으로 출석하거나 행사에 참여한다.

• 다른 개발자, 비즈니스맨들과 교류한다.

• 새롭게 배운 것, 지금 하고 있는 것들에 대해 블로깅한다.

• 오픈 소스 프로젝트에 참여한다.

• 프로젝트를 만들고 공개한다.

• 콘퍼런스에 참석한다.

• 콘퍼런스에서 연사로 나선다.

 

투자로서의 일터

거쳐 가는 모든 직장, 프로젝트들 하나 하나를 투자로 인식하는 것이 가장 중요하다. 직장은 단순히 돈을 버는 곳이 아니라 큰 목표를 향해 다가가는 단계 중 하나다. 소프트웨어 장인은 거치는 자리마다 끊임없이 지식과 열정과 몰입 그리고 프로페셔널로서의 태도를 키워나간다.

 

스스로를 낯선 환경에 노출시켜서 새로운 것을 배우고, 일을 수행하는 다른 방법들을 알게 되는 것도 기대가 됐다. 이러한 것들이 그 회사에서 내가 얻고자 했던 투자 이익이었다.

 

당부의 말 

일에서 투자 이익을 얻는다는 개념을 이기적이고 프로페셔널하지 않은 이력서 채우기로 오해해서는 안 된다. 업무에 대한 기여는 생각하지 않고 개인적인 이유로 이력서에 채워 넣을 기술과 방법론들을 쫓아 다니는 것은 비윤리적이다. 소프트웨어 장인이라면 프로페셔널로서 자신의 고객을 생각해야 한다.

지식은 일에서 얻을 수 있는 가장 흔한 투자 이익이다. 개발자들은 그들이 배우고 싶은 것을 따라서 일을 선택한다. 그 일을 떠날 때는 생각하는 커리어 방향과 맞지 않아서일 때도 있지만 배울 것이 더는 없기 때문에도 그렇게 한다.

 

커리어에서 옮고 그른 것은 없다. 지식은 영원하고 돈과 안정은 영원할 수 없다는 것만은 마음에 새기고 있어야 한다. 어떤 이유에서든 직장을 떠날 때 남는 것은 오로지 지식과 경험뿐이다. 항상 배우고 더 나은 소프트웨어 장인이 되는 것에 집중한다면, 단순히 돈만 좇을 때보다 좋은 직장을 얻기가 오히려 더 수월하다.

 

자율성, 통달, 목적의식

다니엘 핑크Daniel Pink의 저서 『원동력: 동기부여에 대한 놀라운 진실Drive: The Surprising Truth about What Motivates』에서 돈은 충족되어야 할 기본 조건이고, 지식 노동자를 움직이는 것은 자율성, 통달, 목적의식 이렇게 세 가지라고 이야기하고 있다.  

• 자율성: 우리가 무엇을, 어떻게, 언제할지 통제할 수 있는 상태를 뜻한다. 제대로 된 애자일 개발 환경이라면 이러한 것들이 보장되어야 한다.

• 통달: 더 나은 프로페셔널, 더 나은 인간이 되기 위해 계속 배우고 진화하는 것을 뜻한다.

• 목적의식: 지금 하고 있는 일이 중요하고 무언가를 더 나아지게 하고 있다고 느끼는 것을 뜻한다. 아무런 이해없이 시키는 대로 일하는 것의 반대 개념이다.  

돈은 기본적으로 충족되어야 하는 조건이라는 것이 매우 중요하다. 기본적인 생활 요건이 만족되지 않는 상황에서는 일에 집중하기가 상당히 어렵다. 저임금으로 싸게 부려지고 있다고 느끼면 항상 씁쓸한 느낌으로 일하게 된다. 회사를 좋아하더라도 결국은 정당하게 대우받고 있는지 의문을 품을 수밖에 없다.

소프트웨어 장인은 항상 자율성, 통달, 목적의식을 따라 일할 곳을 선택한다. 이러한 것들은 소프트웨어 장인으로서 성공적인 커리어를 오랫동안 지속하기 위해 핵심적이다. 돈만을 쫓아 일할 곳을 선택하면 커리어가 중단되기 쉽고, 제 궤도로 돌려놓기가 거의 불가능하다.

 

회사 안에서의 커리어

우리의 커리어는 매우 긴 계단이고 특정 직업이나 직장은 한 계단에 지나지 않는다. 어떤 계단은 더 낮고 길고, 어떤 계단은 더 높고 짧을 수 있다. 어떤 계단을 밟느냐는 새로운 직장을 얻기 전에 숙제를 얼마나 잘 해놓았느냐에 달려 있다. 어떤 때는 개인적인 상황이나 커리어 방향 변화에 영향을 받기도 한다.

일반적인 대규모 조직에서 커리어를 유지하려 할 때 잘못된 방향으로 가는 것을 많이 보았다. 그 회사를 위해 최선의 것이 무엇인지에 집중하는 대신에, 승진과 보너스에 필요한 것들에만 집중한다. 프로페셔널이 되기 위해 노력하는 대신 주어진 규칙과 질서를 지키는 데 에너지를 쏟는다. 사내 정치 게임을 위해서 스스로의 가치는 제쳐둔다. 자신의 승진에 영향력이 있는 사람들과 다툼을 피하기 위해 정직한 의견을 말하지 않고 회사에 해가 되더라도 승진에 도움이 되는 일이라면 기꺼이 한다. 회사 안에서 잘못된 일에 집중하고 있는 동안 업계는 계속해서 진화한다. 어느 날 문득 높은 직위에 있다하더라도 다른 회사에서는 좋은 조건으로 갈 수 없는 퇴물이 되어 다니는 회사에만 목을 매는 붙박이 신세가 된다. 할 수 있는 것이라고는 그저 경기가 나빠지거나, 회사가 어려워지지 않기를 기도하는 것뿐이다.

이러한 행동을 하게 되는 조직이라면 관리자 층이 관료주의와 무능함으로 가득한 상태일 것이다. 이러한 조직의 관리자들은 그들보다 더 역량 있는 부하직원들이 수행하는 정교한 업무를 제대로 이해하지 못한다. 이러한 현상을 ‘피터의 원리’라고 한다. ‘자신의 무능력이 드러날 때까지 승진하려는 경향’으로도 표현된다. 다르게 말하면 어떤 사람들은 정치 게임, 권한 남용, 책임 전가와 비난, 부정직하고 프로페셔널하지 않은 태도를 통해 감당할 능력이 전혀 없는 자리까지 승진한다.

기술이 퇴보한 사람들은 현재의 급여 수준과 생활 안정을 유지할 수 있는 다른 직장을 찾을 수 없어 근심하게 된다. 직설적으로 말하면 역량이 부족한 사람들만이 일자리 걱정을 한다. 소프트웨어 장인은 직업을 잃는 것에 대해 걱정하지 않는다. 소프트웨어 장인은 자신의 커리어 방향과 일치하는 경우에만 회사 안의 커리어를 수용한다. 소프트웨어 장인은 그들의 커리어가 긴 여정이며, 어떤 종착지에 도달하는 것보다 그 여정 자체가 훨씬 더 중요함을 알고 있다.

 

피터의 원리 :: 컬럼비아대학교 교수였던 로렌스 피터(Laurence J. Peter)와 작가인 레이몬드 헐(Ramond Hull)이 1969년 공저한 책 《피터의 원리》(The Peter Principle)에서 주장하였다.
우리 사회에서 많이 볼 수 있는 무능력, 무책임으로 인해 우리는 많은 불편을 겪으며 막대한 비용을 지출하게 된다. 그렇지만 이러한 무능력은 사라지지 않고 있으며, 오히려 무능한 사람들이 계속 승진하고 성공하는 모순이 발생하고 있다. 대부분의 사람들은 무능과 유능은 개인의 역량에 달려 있다고 생각하기 쉬우나, 로렌스 피터와 레이몬드 헐은 우리 사회의 무능이 개인보다는 위계조직의 메커니즘에서 발생한다고 주장하였다.
이들은 수백 건에 달하는 무능력 사례를 분석한 뒤 무능력의 원인을 해명한 피터의 원리를 제시하였다. 이들이 제시한 원리의 핵심은 "조직체에서 모든 종업원들은 자신의 무능력이 드러날 때까지 승진하려는 경향을 보인다"는 것이다. 즉, 위계조직 내의 구성원들은 한 번 또는 두 번의 승진을 통해 자신이 능력을 발휘할 수 있는 상위 직책을 맡게 된다.
그리고 승진된 직책에서 능력을 발휘하면 다시 상위 직급으로 승진할 기회를 잡게 된다. 따라서 모든 개인들은 자신의 무능력이 드러나는 단계까지 승진하게 되고, 시간이 지남에 따라 모든 직위는 그 업무를 수행하는 데 필요한 능력을 가지고 있지 않은 구성원들에 의해 채워지는 경향을 갖는다는 것이다.
자신의 능력을 넘어서는 지위까지 승진하게 되면 그 사람은 그것이 자신의 최종 직위임을 직감적으로 알게 된다. 그러나 그들은 자신의 무능력을 인정하지 않으려 하며 현재의 무능력은 자기가 게을러진 탓이라고 생각하게 된다. 그들은 더 열심히 일함으로써 새로운 직위에 따른 어려움을 극복하고자 하며, 때문에 점심시간에도 일을 하고 일거리를 집에 가지고 가기도 한다.
또한 자신의 무능을 감추려고 다양한 시도를 한다. 어떤 이가 무능의 한계에 도달했을 때 보이는 증상들은 책상을 깨끗하게 정리해야 안심하는 종이공포증, 반대로 서류를 산처럼 쌓아놓는 문서중독증, 책상기피증, 전화중독증, 도표집착증, 아무 의미 없이 말만 길게 하는 만연체 증상 등 다양하다.
피터의 원리는 구체적 상황별로 수많은 파생원리를 낳는다. 예를 들면, 위계조직 내 사원들이 단지 승진한 사람들에 대한 부러움을 숨기기 위해 무능력을 들먹이는 것이라는 '피터의 역설', 직장 위계조직에서 무능력의 한계에 도달한 사람이 앞길을 막고 있다면 장애가 없는 곳으로 옮겨야 한다는 '피터의 우회' 등이 있다.
피터의 원리에 근거하면, 행복한 삶은 자신의 능력을 충분히 발휘할 수 있는 수준의 성공에 만족하는 것이다. 이를 위해서는 적절한 수준 이상의 승진은 바람직하지 않다고 할 수 있다. 자신을 무능력하게 만들고 마는 승진에 집착하기보다는 유능한 구성원으로 남을 수 있는 수준에 머무르는 것이 더 높은 만족감을 얻을 수 있다는 것이다.
[네이버 지식백과] 피터의 원리 [The Peter Principle] (두산백과 두피디아, 두산백과)

 

요약

역량이 더 높아질수록, 스스로에게 기쁨을 주는 일을 찾기가 쉬워진다. 좋은 일감을 얻을 수 있는 위치에 도달하려면 커리어의 개발 과정 중에 많은 집중과 결단력이 필요하다. 성공적인 커리어는 공짜로 오지 않는다. 스스로 만들어 나가야 한다. 특정 회사 안에서의 커리어보다 개인으로서 우리 자신의 커리어가 항상 우선해야 한다. 물론 회사 안에서의 커리어가 개인의 커리어와 일치한다면 대단한 행운이지만 회사가 개인의 커리어를 통제하는 경우가 대부분이다. 일을 신중히 선택하고 고객들을 만족시켜 나가면, 소프트웨어 장인으로서 매우 성공적이고 즐거운 커리어를 만들 수 있다.

 

 

 

Part 2. 완전한 전환

Chapter 9. 인재 채용

새로운 인재를 채용할 때 현재의 문제를 더 키우지 않아야 한다는 것을 우선으로 고려해야 한다. 현재 업무가 제대로 진행이 안 되고 잘못된 행동들을 하고 있는 기존 개발자들이 문제라면, 그와 똑같이 행동할 사람을 또 채용하는 일이 없도록 해야 한다. 지속적으로 배우고 혁신하고 효율적인 실행 관례를 도입하고, 프로젝트의 성과와 코드의 품질에 주의를 기울이고, 문제를 풀기 위해 스스로 협력하고, 무엇이든 더 나은 방법을 추구한다면 이러한 훌륭한 개발자들과 비교해 기준에 미달되는 개발자를 채용하는 것도 어리석은 일이다. 너무나 당연해 보이는 일이지만 인사부서의 채용 담당자에게는 그렇지 않은 일이기도 하다. 모든 회사들이 최고의 인재를 원한다고 표방하지만 최고의 인재가 실제로 어떤 의미인지는 잘 모르는 경우가 허다하다.

 

전형적인 채용 공고

대형 은행의 외환 IT 시스템 개발을 담당할 자바 개발자를 모집합니다. 

장기 계약직으로 일하게 되며 아래와 같은 기술과 경험이 있어야 합니다. 
• 자바 프로그래밍 경력(5년 이상)-(멀티스레딩, 병렬처리 구현 경험 필수) 
• 스프링 프레임워크 경험(스프링 integration, batch job, MVC, IoC) 
• 금융권 IT 업무 경험(2년 이상) 
• low latency, high frequency 트레이딩 시스템 개발(외환 거래)
• FX 호가(동시, 선물, 파생) 
• 프론트 오피스 위험 관리, FX 가격 결정 
• 전산 전공(석박사 우대) 
• 솔라리스, 리눅스, RMDS, 29 West, Kx/Q, SQL(오라클), Coherence 
• 우대 경력: C#, C++, MQ 메시징, 애자일 방법론, 분산/복제 캐시, Sybase, DB2   

대우 수준은 아래와 같습니다. 
• 80~90k 파운드(원화: 1억 2천~1억 5천), 급여 외 보너스 최대 30% 
   년간 26~30일 유급 휴가, 가족을 포함한 의료보험 제공, 퇴직금 제공 기타 복리후생 제공   
상기 요구 경력에 합치하고 대우 수준에 관심이 있는 개발자께서는 바로 지원바랍니다.

 

개인적인 경험과 지인들을 통해 접하는 업계 이야기를 종합하면 이러한 채용 공고를 낸 회사는 자바 개발자만 필요한 것이 아닐 거라고 확신한다. 이러한 회사는 프로젝트 그 자체와 함께 절차, 문화에 훨씬 큰 문제가 있고 실제로 풀려는 문제도 그러한 것들일 가능성이 높다.

 

투자 은행들의 채용 공고는 틀에 박은 듯이 다들 비슷하다. 한 은행에서 시스템을 엉망으로 개발하고 떠난 개발자가 또 다른 은행에서 쉽게 일자리를 구할 수 있다는 이야기도 된다. 이러한 개발자는 더 많은 돈만을 쫓고, 일하는 방법을 개선하거나 자기계발에는 공을 들이지 않는다. 이 공고에서는 전산관련 학위, 보유 기술 목록(그 기술을 정말 잘 활용할 능력이 있는지는 알 수가 없다) 그리고 투자 은행에서의 업무 경력을 요구하고 있다. 이 목록에 합치만 되면 더 대우가 좋은 은행으로 얼마든지 옮겨 다닐 수 있다. 그 와중에 은행에서는 더 역량 있는 사람이 필요하다고 성화다. 모든 것을 더 나아지도록 변화시킬 수 있는 사람, 더 품질 좋은 소프트웨어를 효율적으로 만들어 내고 비용을 낮출 수 있는 사람을 원한다. 하지만 더 나은 사람을 고용하기 위해서는 채용 방식을 바꾸어야 한다는 것을 모른다. 훌륭한 개발자를 유인하려면 먼저 채용 공고의 직무 요건을 바로잡아야 한다. 앞의 채용 공고 직무 요건들은 잠재적으로 실력있는 개발자 다수를 제외시킨다. 투자 은행에서 근무한 적이 있고, 전산학 학위가 있으면서 나열된 모든 기술들을 경험해본 사람으로 한정시키면 그 중에서 소프트웨어 개발자로서 유능한 사람의 숫자가 얼마 남지 않는다.

 

종국적인 목적이 소프트웨어 개발/납품 역량을 개선하고, 일하는 방식을 바꾸어 문화를 혁신하는 것이라면 앞과 같은 채용 공고는 아무런 의미가 없다. 이 채용 공고의 요구 조건 목록은 엉뚱한 것에 집중하고 있고 회사의 가치와 후보자에게 기대되는 태도에 대해서는 아무것도 말하지 않는다. 회사에서 내보내고 싶은 사람과 같은 부류의 사람을 또 채용하게 될 수도 있다.

 

면접관들은 본인이 후보자 면접에 얼마나 미숙한지 알지 못할 때가 많다. 정확히 어떤 사람을 찾는지, 어떻게 찾을 수 있는지도 잘 모르는 경우가 흔하다. 회사와 면접관들이 훌륭한 개발자를 잘 선별해서 채용할 능력이 있었다면 지금 사내에 있는 개발자들에 대해 불평하는 상황 자체가 없어야 한다. 문화가 바뀌어야 한다는 아우성도 없어야 했다.

큰 조직에서 일하던 시절, 다른 국가에 있는 다른 부서의 팀들로 정기적인 출장을 갔었다. 나의 역할은 해당 지역의 개발자들과 함께 일하고, 기술 토론을 하고, 페어 프로그래밍을 하고, 좀더 효율적인 실행 관례를 도입할 수 있도록 돕는 것이었다. 출장에서 돌아오면 고위 관리자들과 그 해외 조직에서의 경험에 대해 이야기를 나누었다. 고위 관리자는 보통 해당 해외 조직의 책임자일 때가 많았고 가장 흔한 질문이 “어느 정도 형편 없는가?”였다. 그리고 내가 미처 대답하기도 전에 “개발자들 역량이 충분한 것 같지가 않다. 뭔가 하나 시키면 언제 끝날지 알 수가 없다. 도대체 뭘 하고 있는지 모르겠다. 누가 가장 문제인지 말해 달라. 조치를 취하겠다.”라고 부연을 한다. 나는 일반적인 상황에 대해서는 설명을 했지만 한번도 특정 개발자의 이름을 말한 적은 없다. 해고할 개발자의 이름을 받아 내기 위해 나를 몰아세우고 윽박지른 관리자도 있었다. “나는 이름을 댈 수 없다. 당신이 나를 출장보낸 이유는 그 개발자들을 돕게 하기 위함이었지 그 개발자들을 해고하기 위한 것이 아니었다. 나는 그들을 더 나아지게 하기 위해 이 자리에 있다. 나는 그 개발자들과 며칠 동안 함께 시간을 보냈고 그들의 신뢰를 얻었다. 나 역시 개발자로 그들과 가까워졌고 그들도 나와 가까워졌다. 그들을 배신할 수 없다. 당신이 가진 불만들은 그 개발자들의 문제가 아니다. 그 개발자들은 어느 날 갑자기 회사 문을 박차고 들어와서 여기서 일하겠다고 한 사람들이 아니다. 그들은 채용 과정을 거쳤다. 이력서를 보내고 당신의 선별 과정을 거쳤다. 당신의 문제는 미숙한 개발자들이 아니다. 당신의 문제는 채용 과정이고 그것에 권한과 책임이 있는 사람이 문제다. 바뀔 것은 채용 절차이고, 해고될 사람은 그것에 책임있는 사람이다.”라고 답할 수밖에 없다.

어떤 조직의 문화와 정체성은 CEO가 보낸 이메일이 아니라 회사의 구성원이 결정한다. 인사부서나 회사 밖의 HR 에이전시에 채용을 맡기고 내버려 둔다는 것은 개발팀의 문화와 정체성에 별 관심없는 사람의 손에 개발팀의 새로운 구성원에 대한 선별권을 넘긴다는 의미다.

 

인터뷰할 시간이 없다는 변명

우리는 가족이나 연인보다 회사 동료들과 훨씬 많은 시간을 보낸다. 신뢰할 수 있고 좋은 관계를 맺을 수 있는 사람을 동료로 두는 것은 대단히 중요하다. 면접에 투자할 시간이 없다는 것은 훌륭한 팀을 구성하는 것을 소홀히 한다는 것과 같다.

 

기간을 정해 놓고 채용을 하거나, 정규적인 공채 절차를 거치는 것은 해법이 아니다. 부적합한 지원자를 면접하는 데 낭비되는 시간은 반드시 대응이 필요하다.

 

틀에 박힌 직무 요건

로 애들러는 기술과 경험을 나열하는 전통적인 직무 요건이 “재능에도 반하고, 다양성에도 반하며, 성공적인 채용과의 상관관계도 최악이다라고 말하고 있다.

다음은 왜 그런지에 대한 몇 가지 이유다.

• 절대적인 숫자: 숫자는 임의적이고 오해하기 쉬우며 변덕스럽다. 5년 간의 자바 경력 또는 얼마 이상의 대학 학점은 후보자를 제대로 선별하는 데 별 도움이 안 된다. 5년 간 경험했다는 것은 1년의 똑같은 경험을 5번 반복하는 것과는 다르다. 채용된 후에 새롭게 배우는 것 없이 같은 기술만으로 오랫동안 일하는 개발자들이 많다. 대학 학점 또한 아무런 의미가 없다. 대다수의 학생들이 졸업 직후에는 프로페셔널 소프트웨어 개발자가 될 준비가 안 되어 있다. 필요한 기술은 일을 통해서 또는 자발적인 자기계발을 통해서 배울 수 있지 학점이나 자격증을 통해서 얻는 것이 아니다.

• 키워드 매칭: 채용 담당자들은 특정 기술이나 플랫폼에 대한 약어들을 선호하지 않는다. 채용 담당자는 해당 업무의 본질적인 부분을 잘 모르기 때문에 선무당에게 굿을 맡기는 결과가 된다.

• 기술 목록의 나열: 불필요하게 너무 많은 기술 목록을 나열하면 재능 있고 정직한 개발자가 스스로 지원을 포기하게 만들 수 있다. 보통 더 나은 개발자를 선별하려는 욕심에 필요한 기술뿐만 아니라 희망 기술까지 더해지기 일쑤다. 좋은 개발자를 선별하기는 커녕 후보군만 줄일 뿐이다. 나열된 기술이나 경험 목록이 실제 그 업무를 잘하기 위한 것과 전혀 관계 없는 경우도 있다.

• 잘못된 기업 문화 설명: 채용 공고에 기업의 가치와 기대되는 태도, 책임을 잘못 설명하는 경우가 많다. 보통 그 누구도 부정할 수 없는 아주 당연한 가치들을 나열한다. 팀워크, 긍정적 태도, 배움에 대한 열정, 지혜로움과 같은 단어들을 나열하지 않도록 한다. 이러한 것들 중 어느 하나라도 자신이 해당하지 않는다고 스스로를 배제할 지원자는 없다.

• 잘못된 요구 항목: 더 훌륭한 개발자를 유인하기 위해서는 기술, 경력 년수, 일한 산업군, 출신학교, 학점 이런 것들 보다 그 직무에서 무엇을 책임져야 하는지 설명하는 것이 훨씬 낫다. 해가 갈수록 화려한 기술 항목(그냥 종이 위의 글자에 지나지 않는), 학점, 학위, 업무 경력으로 채워진 이력서가 넘쳐나고 있다. 그 내용들과 실제 역량은 전혀 일치하지 않는 것이 현실이다.

• 잘못된 선별 조건: 직무 요건들은 최고의 인재를 끌어들이는 것이 아니라 최악의 인재를 걸러내기 위한 목적으로 설계되어 있다. 최고의 개발자들은 경험 년수에 기반한 채용 공고에는 지원하지 않는다. 최고의 개발자들은 대단히 신중하게 일을 찾는다. 특정 기술의 사용 유무보다 회사의 문화, 업무에서의 책임, 프로젝트의 종류를 훨씬 더 중요하게 여긴다. 수준 이하의 개발자를 걸러내기 위한 직무 요건 내용들이 최고의 개발자들을 배척하는 부작용을 만들 수 있다.

• 승진 요건과의 불일치: 승진심사 때, 특정 프레임워크의 API를 알고 있다거나 자바 경력이 몇 년 이상이라서 승진하지는 않는다. 대신 그가 이룬 성과와 리더십, 팀워크와 같은 다른 중요한 이유들 때문에 승진을 한다. 채용 공고의 직무 요건이 이러한 승진 요건과 합치되는 부분이 없다면 그 직무 요건으로 필터링된 사람들이 회사 안에서 좋은 성과를 낼 것으로 기대하는 자체가 앞뒤가 안 맞는 일이다.  

 

참고 정보로 필요한 직무 요건

채용 공고에 직무 요건 목록을 나열하는 것은 지양한다. 직무 요건을 꼭 작성해야 한다면 태도와 책임, 프로젝트 종류, 사용 기술(요구 조건이 아니라 참고 정보로서) 그리고 가치관과 회사의 문화에 집중된 내용으로 채워져야 한다.

 

<채용 공고 1>
금융 소프트웨어 자바(J2SE/J2EE) 개발자 채용

당사는 성공적으로 성장 중인 금융 소프트웨어 전문 업체로, SQL에 경험이 있는 정규직 자바(J2SE 또는 J2EE) 개발자를 채용합니다. 기술에 대한 열정과 함께 금융 서비스 분야에 더 많은 경험과 배움을 얻고자 하는 개발자를 환영합니다.
• 급여 수준: 50,000 ~ 60,000 파운드(원화 8000만 원~1억 원), 보너스 별도  

직무 요건
지원자는 자바 코어에 능숙해야 하며 상용 환경에서 아래와 같은 기술과 경험을 필수로 보유하고 있어야 합니다.
• 5년 이상의 자바 개발 경험(J2SE 또는 J2EE)
• 3년 이상의 SQL 활용 경험(더불어 SQL 서버와 오라클에 대한 기본적인 이해 필요)
• 웹 기술 경험(HTML 5, CSS 3, jQuery, Spring MVC 등)
• 객체지향 분석 및 설계 경험
• 소프트웨어 개발 생애 주기 전반에 대한 경험
• 동료 개발자 및 비즈니스 분석가와 전문적인 내용에 대한 원활한 커뮤니케이션 능력  

필수 요건은 아니지만 다음의 기술과 경험들을 보유한 지원자를 우대합니다.
• 고성능 분산 시스템 개발(Java 기반)
• 실시간 및 배치 시스템 경험
• 분산 시스템 기술 경험(Oracle Coherence등)
• Spring, Hibernate 활용 경험
• 애자일 개발 환경 경험(TDD, JUnit 등)  

자바 개발자의 역할은 시스템 아키텍트, 자바 팀 리더, 그리고 다른 개발팀의 사람들과 긴밀히 협력하여 상위 수준 설계, 코드 구현, 성능 개선을 하는 것입니다.
본 직무를 통해 뱅킹과 투자 관리 업무 분야에 대한 기술적 경험뿐만 아니라 관련 비즈니스에 대해서도 폭넓게 경험을 쌓을 수 있는 기회가 주어집니다.

 

이 자리를 지원하는 사람이라면 거의 비슷한 배경을 가지고 있을 것이다. SQL을 사용할 줄 아는 자바 개발자, 5년 이상의 J2SE 또는 J2EE 경력, 3년 이상의 SQL 사용 경력, 이러한 것들은 이 회사가 고참 개발자의 기준을 개발자가 가진 지식이 아니라 특정 기술을 얼마나 오래 사용했었는가를 판단한다는 것을 알 수 있다. 새로운 JEE 대신 오래된 J2EE라는 용어를 사용하고 있다는 것이 눈에 띈다. 이 회사는 구 버전의 자바 엔터프라이즈 에디션을 쓴다는 뜻일까? 아니면 오래된 채용 공고를 그냥 ‘copy & paste’해서 재활용하다 보니 그렇게 된 것일까? 어느 쪽이건 간에 바람직하지 않다.

우대 요건에 ‘애자일 개발 환경 경험(TDD, JUnit 등)’이 있는데 마치 애자일이 TDD나 JUnit과 같은 것처럼 취급하고 있다. ‘JUnit 등’이라고 표현한 부분은 이 회사가 애자일이나 익스트림 프로그래밍에 대해 진지한 입장은 아니라는 강한 의심이 생긴다. 애자일은 여러 가지 직무 요건들 중 하나일 뿐이다.

‘시스템 아키텍트, 자바 팀 리더, ...긴밀히 협력하여‘라는 부분은 자기 조직화되는 팀이 아닌 계층 구조임을 암시한다.

시작과 마지막 부분에서는 ‘금융 서비스, 뱅킹, 투자 관리 및 관련 비즈니스를 배우고 경험을 쌓을 기회가 있다‘는 것을 강조하고 있다. 은행 업계에서 일해 본 경험을 바탕으로 비즈니스를 더 배워서 관리자가 되는 커리어 개발 기회를 얻을 수 있다는 의미임을 알 수 있다.

마지막으로 ‘기술에 대한 열정과 ... 배움을 얻고자 하는 개발자를 환영’ 한다는 부분을 뒷받침하는 내용을 직무 요건에서 전혀 찾을 수 없다. 그러한 열정이 어떻게 보상받고 가치를 부여받는지, 회사의 개발 문화와는 어떻게 연결되는지 아무런 내용이 없다.

 

<채용 공고 2>
음악과 기술에 대한 열정이 넘치는 사람들로 가득한 규모는 작지만 빠르며 혁신적인 회사입니다. 우리는 빠르게 성장하고 있습니다. 이에 따라 열정적이고 창의적으로, 즐겁게 함께 일할 사람들을 찾고 있습니다. 비록 힘은 들지만 재미있게 일할 수 있고 내가 기여한 부분이 즉각적으로 회사의 성공에 영향을 끼치는 것을 볼 수 있는 환경입니다.  

개발팀: (경력) 개발자
아주 특별한 개발팀에서 일할 똑똑하고, 자발적으로 동기가 부여된 개발자를 찾습니다. TDD를 능숙하게 수행해본 경험이 반드시 있어야 합니다.  

이런 분을 찾습니다
• 소프트웨어 자체를 중요시하고 돌볼 줄 알아야 합니다. 글자에 지나지 않는 이력서의 공허한 다짐들이 아니라, 자신의 업무를 명확히 하고 그 행동에 책임질 수 있는 열정이 있어야 합니다.
• 소프트웨어 설계에 대한 안목이 있어야 하며 여러 주제들에 대해 당신의 경험이나 자료, 실험을 바탕으로 유창하게 의견을 개진할 수 있어야 합니다.
• 당신에게 있어서 일은 단순히 직장에 출퇴근하는 것 이상의 의미가 있어야 합니다.  

TDD
다른 무엇보다도 우리는 TDD를 지지하고 따르고 있습니다. TDD로 일하는 데 충분한 경험이 있고 TDD 스타일의 사고방식에 능숙하다면 우리는 당신을 고참 개발자 자리로 모실 것 입니다. TDD로 일한 경험이 있습니까? 그렇다면 아주 좋습니다. 얼마나 경험이 있는지, TDD를 어떻게 실행했는지, 최근 프로젝트에서 TDD가 어떻게 이용되었는지, 어떤 문제들이 있었는지 등 많은 이야기를 듣고 싶습니다.  

직무 역할
우리 팀은 크로스펑셔널, 자기 조직화 팀이며 자유로운 분위기입니다. 아키텍트도, 프로젝트 관리자, 중간 관리자도 없습니다. 당신은 제품 관리자 및 이해 관계자들과 직접 대면하며 긴밀한 상호 협력 방식으로 일하게 됩니다. 상당히 높은 수준의 팀워크와 성숙도가 필요합니다. 그러한 역량은 흔하지 않습니다. 하지만 우리는 이러한 역량이 최고의 소프트웨어를 만들기 위한 최선의 방법이라고 믿습니다.
여러 가지가 있지만 그 중에서도 페어 프로그래밍, TDD/BDD, 리펙토링, 연속된 제품 릴리즈가 우리의 일하는 방식에 깊게 녹아 있습니다. 이러한 방법들을 개선하기 위해 지속적으로 노력하고 있습니다. 우리는 코드 타이핑이 일의 병목점이 아니라는 것을 알고 있습니다. 여러 가지 중에서도 다음과 같은 것을 수행합니다.  
• 한 주에 두 번씩 카타(Kata), 도조(Dojo)를 하거나, 실행 관례나 기술에 관해 토론합니다.
• 한 달에 한 번씩 ‘이노베이션 타임’이 있습니다. 이틀의 시간을 할애하여 새로운 장난감을 가지고 놀거나 제품 아이디어를 토론합니다.
• 정기적으로 콘퍼런스나 커뮤니티 이벤트에 참석합니다. 단순한 참관일 때도 있고 서포터 또는 발표자일 때도 있습니다(최근에는 ‘QCon London 2012’, ‘소프트웨어 장인정신 2012’, ‘SPA 콘퍼런스 2012’에서 발표 세션을 맡았습니다).
• 우리는 완전하지 않습니다. 많은 문제가 있음을 인정합니다. 우리는 개선하기 위해 끊임없이 노력 중이며 아직 해결해야 할 문제들이 많이 남아 있습니다.

사용 중인 기술
대부분의 코드 스택이 C#과 .Net으로 되어 있습니다. 다른 언어와 기술들(예를 들어 Ruby, 서버사이드 JavaScript, C++, Python)도 사용하고 있고 탐색 중입니다. 객체지향 언어를 깊이 이해하고 다루는 데 능숙하다면 경험한 배경 기술이 무엇이든 관계없이 우리의 일원이 되는데 문제가 없습니다. 아래는 현재 사용 중인 기술 목록입니다(이 기술들 외에 다른 기술들도 얼마든지 사용될 수 있습니다).  
• C#, Ruby, JavaScript
• ASP.Net MVC, OpenRasta, Nancy, ServiceStack, Nhibernate, Windsor, StructureMap, NUnit, RhinoMocks, ReSharper, NDepend
• Cucumber, Rails, RSpec, Rake, Capybara, Selenium, Watir
• REST, OAuth
• Git
• MS SQL, ElasticSearch, Solr
• Mono, Windows, IIS, Nginx
• RabbitMQ
• TeamCity  

오픈 소스에 대해서도 적극적입니다. 위에 나열된 기술 중 일부에 실제 기여하고 있으며 fork한 프로젝트도 우리의 GitHub 계정에서 관리하고(우리가 만든 다른 기능들을 공개하는 것을 포함하여) 있습니다.

 

‘당신에게 일은 단순히 직장에 출퇴근하는 것 이상의 의미가 있어야 합니다.’

 

효과적인 선별 조건의 정의

열정은 기술적인 역량이나 프로그래밍 언어에 대한 이해보다도 더 중요한 조건이었다. 나는 항상 새로운 것을 시도하고, 배우고, 지식을 공유하고, 커뮤니티 활동에 적극적인 사람을 원했다.

 

많은 개발자들과 이 주제에 대해서 오랫동안 이야기를 나누어 왔지만 그중 단 한번도 특정 기술에 대한 지식이나 경력년수 또는 학위가 훌륭한 개발자의 조건이라고 말하는 사람은 없었다. 그러한 조건들이 훌륭한 개발자와 전혀 상관이 없다면 왜 계속해서 선별 조건으로 내걸어야 할까?

 

앞의 투자 은행 사례에서는 열정을 가장 중요한 요건으로 보았다. 하지만 기존의 일반적인 이력서만으로는 열정 수준을 가늠할 방법이 없었다. 그래서 다른 형태의 이력서를 요구했고 다음 사항들 중에 해당되는 것이 있다면 기술하도록 했다.  

• GitHub 계정

• 블로그

• 오픈 소스 활동

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

• 펫 프로젝트 내용

• 트위터 계정

• 좋아하는 기술서적 목록

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

그 투자 은행의 개발자들과 나의 생각에는 열정이 있는 개발자라면, 심지어 초보 개발자라 하더라도 이중 하나 정도는 해당사항이 있을 것이라고 보았다. 이 정도 요건이면 자신의 커리어를 위해 개인 시간을 들여서 스스로에게 투자하는 사람, 즉 열정이 있는 사람을 구분하기에 충분해보였다.

 

적극적인 리쿠르팅

회사는 시급하게 채용해야 하는 상황을 절대 만들어서는 안 된다. 급하게 채용해야만 하는 상황에서는 잘못된 사람이 조직에 들어오기 쉽다.

 

요약

선별 조건으로서 특정 기술에 대한 경험이나 업무 경력년수, 전공, 학위, 인증같은 것들은 적합하지 않다. 대신 열정에 집중해야 한다.

미래의 성공 가능성을 높이기 위해서는 열정적인 개발자를 찾아야 한다. 열정적인 개발자는 개방된 사고로 항상 무언가를 배우기를 원하기 때문이다. 그들은 스스로 동기가 부여되어 혁신하고 기술 변화를 이끈다. 그들은 누가 무엇을 하라고 할 때까지 기다리지 않는다. 무언가를 시킬 때까지 그저 가만 있는 사람들은 회사를 정체 상태로 이끌어 피해야 할 사람들이다. 열정적인 개발자는 성장하기 위해 개인 시간을 기꺼이 투자한다. 당장 오늘은 미숙하더라도 그리 길지 않은 시간이 지나면 훌륭한 프로페셔널이 될 가능성이 매우 높다.

 

 

 

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

비즈니스 협상

좋은 파트너십은 양쪽 모두에게 가치있어야 한다.

 

생산적인 파트너십을 알아보는 방법

지원자에게 질문이 있냐고 물었을 때 ‘아니오’라는 대답이 더 많았다. 어떤 때는 그런 태도가 너무 실망스러워서 탈락시킨 적도 있다.

 

어떤 식으로 일하는지, 무엇을 성취하길 원하는지, 당면한 문제가 무엇인지 등에 대해 면접 때조차 아무런 질문도 하지 않은 사람이, 실제 업무 현장에서 갑자기 적극적으로 질문을 하리라고 기대할 수 있을까?

재능있는 개발자를 채용한다는 의미는 그의 의견을 중요하게 생각하고 일하는 방식을 개선하는 데 그의 도움을 받겠다는 것이다. 개발자의 의견이 중요하지 않다면 굳이 높은 급여를 제공하면서까지 실력있는 개발자를 채용할 이유가 없다. 협업과 권한부여는 성공적인 팀이 되기 위해 반드시 필요하다. 면접관의 역할은 지원자가 협업을 잘 할 수 있을지, 권한부여를 잘 감당할 수 있을지 판별하는 것이다. 지원자가 얼마나 많은 질문을 하느냐는 면접관 입장에서 그 사람의 협업 능력과 비즈니스 기여 가능성을 가늠할 수 있는 중요한 단서가 된다. 지원자가 일과 회사에 대해 아무런 질문도 하지 않는다면 단지 ‘아무 일자리’나 찾고 있을 뿐이라는 신호가 될 수 있다. 지원자가 많은 질문들을 쏟아낸다면 그가 그의 커리어를 소중히 하고 올바른 직장을 찾는 중이라고 짐작할 수 있다.

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

 

첫 번째 힌트는 관리층이 개발자들을 신뢰하는지의 여부다. 면접관들이 실무 개발자들이 아니라 관리자, 아키텍트, 팀 리더들로만 구성되어 있다면 계층 구조로 운영되는 회사이고 개발자를 신뢰하지 않을 가능성이 높다. 이것만으로도 개발자들에게 합당한 권한 위임이 되고 있는지 아니면 몇몇 고위 직급들에 의해서 모든 결정이 이루어지는지 의문을 갖기에 충분하다.

다단계 면접이 아닌 원샷 면접으로 채용하는 회사는 좀더 우려스럽다. 너무 급해서 적합한 인재를 채용할 시간이 없을 가능성이 높다. 반면에 다단계 면접은 회사에서 지원자의 서로 다른 여러 측면을 보려는 것이다. 즉 제대로 된 프로페셔널을 채용하는 데 진지하게 임한다는 징표일 수 있다.

 

면접 참관이 끝났을 때, 면접관은 질문지의 내용에 대해 비밀로 해줄 것을 요청했다. 그는 질문이 지원자들에게 유출될 것을 걱정했다.

면접에서 다루는 내용이 사전에 지원자에게 알려질까 걱정된다면, 그 면접 방법은 잘못된 것일 가능성이 높다. 잠깐 동안 구글을 검색해보거나 API, 도구들의 레퍼런스 문서를 읽는 것만으로 쉽게 대답할 수 있는 질문들로 좋은 개발자와 그렇지 않은 개발자를 가려낼 수 있을까? 면접에서 그런 질문들은 전혀 의미가 없다.

그런 식의 면접은 팀의 창의성 부족과 폐쇄적인 회사 문화의 일면을 볼 수 있다. 그 팀에서는 소프트웨어 개발을 할 때 몇 가지 제한된, 늘 써오던 익숙한 도구들만 이용한다는 의미일 수도 있다.

 

바람직한 면접 방법

좋은 면접은 자유 토론과도 같아야 한다. 소프트웨어 개발과 관련하여 지식과 정보를 교환하고, 기술/도구/방법론들에 대해서도 의견을 나누어야 한다.

 

면접관은 “당신의 블로그 글들을 읽어 보았습니다. 글들의 주제들은 모두 마음에 들었지만 몇몇 부분은 생각이 다릅니다. 그것에 대해서 이야기를 나누고 싶습니다.”라고 말했다.

내 글들에 대해서 1시간 넘게 토론했고 그중 업무 현장에 반영될 수 있는 시나리오와 그럴 수 없는 시나리오를 찾아 나갔다. 접근 방법 몇 가지는 의문이 있었지만 면접관과 내가 동의하는 부분과 그렇지 않는 부분들을 알아보는 것 자체가 즐거웠다. 특히 서로 처음 알게 된 부분이 나올 때는 더욱 흥미진진했다. 5단계의 면접 중에서 첫 번째에 지나지 않았지만, 이미 그러한 면접관과 함께 일하고 싶다는, 그 회사에서 일하고 싶다는 생각이 마음에 가득 차올랐다. 이런 종류의 면접은 지원자 입장에서 미리 준비할 수 있는 성격의 것이 아니다. 토론 주제에 대해 경험이 있을 수도, 없을 수도 있다. 면접 전에 구글에서 관련 내용을 검색해서 읽어 볼 수는 있지만 자유 토론에 대응하기에는 부족하다. 바로 이 부분이 자유 토론 방식 면접의 백미다. 바로 지원자의 실제 경험을 알아낼 수 있다.

 

올바른 집중

우리의 핵심 가치는 무엇인가? 우리에게 필요한 주요 기술은 무엇인가? 더 잘하고 싶은, 더 나아지고 싶은 것들은 무엇인가? 새로운 사람을 채용하기 전에 이러한 질문들에 스스로 대답을 준비해야 한다.

 

마인드 맵핑 대화

면접관으로서 면접을(사실 대화에 가까운) 진행할 때 마인드 맵을 이용하면 매우 편리했다. 펜과 종이 몇 장을 두고서 지원자에게 특정한 답변이 없는 주관식의 개방형 질문을 던진다. 예를 들면 “잘 작성된 소프트웨어란 어떤 것이라고 생각합니까?“ “소프트웨어 프로젝트에서 가장 어려운 부분은 무엇이라고 생각합니까?“ 이 질문들에서 ’잘 작성된 소프트웨어’와 ’가장 어려운 부분’이 마인드 맵의 뿌리가 된다.

 

페어 프로그래밍 면접

지원자가 작성한 코드를 보지 않는다면 대단히 큰 실수이다. 그 어떤 기술 면접도 지원자와의 페어 프로그래밍만큼 좋을 수는 없다.

 

한 가지 쉬운 방법은 공개된 프로그래밍 연습문제 카타를 이용하거나 직접 카타를 개발하는 것이다. 카타는 지원자의 TDD 역량을 시험하거나 일반적인 클린 코드 원칙을 얼마나 지키는지 알아보는 데 좋다.

또 다른 방법은 회사에서 실제 사용 중인 코드 베이스에서 일부를 발췌하는 것이다. 테스트 코드가 만들어지지 않았고 가장 엉망으로 작성된 부분을 고르면 더욱 좋다. 지원자에게 그 코드를 개선하고 테스트를 작성해보도록 한다. 레거시 코드가 많은 프로젝트라면 이러한 면접을 통해 지원자가 실제 프로젝트에서 어떤 능력을 발휘할 수 있을지 알아볼 수 있다.

 

지원자가 어디까지 해낼 것인지 현실적인 기대를 가져야 한다. 면접관은 해당 문제를 이미 알고 있어서 익숙하겠지만 지원자는 그렇지 않다. 지원자가 곧바로 결론을 내거나 솔루션을 찾을 것이라고 기대해서는 안 된다. 면접관들은 자기가 일을 배울 때 얼마나 오랜 시간을 걸렸는지 잊어버릴 때가 많다.

도구(컴퓨터, IDE, 테스팅/목업 프레임워크)를 제공한다면 지원자가 그 도구들에 익숙해질 때까지 기다려 주어야 한다. 익숙해지는 데 시간이 걸린다는 것은 나쁜 것이 아니다.

 

개인 컴퓨터를 지참한 면접

한 가지 재미있는 방법은 지원자에게 GitHub 프로젝트를 클론하고 인터넷 연결을 통해 작업하게 하는 것이다. 이 방법은 지원자에 대해서 많은 것을 알려줄 수 있다. Git에 익숙한지? Git가 이미 설치되어 있는지? 컴퓨터 설정이 어떻게 되어 있는지? 어떤 도구를 선호하는지? 프로젝트를 금방 시작할 수 있는지? 테스팅/목업 프레임워크를 이미 모두 가지고 있고 사용할 수 있게 설정되어 있는지? 업무 외 시간에도 코딩을 하는 개발자라면 이러한 것들이 항상 준비되어 있다.

 

맞춤형 면접

지원자의 면접을 보기 전에, 스스로에게 다음과 같은 질문을 던져보아야 한다. 우리가 소중히 하는 가치가 무엇인가? 동료들로부터 어떤 종류의 태도를 기대하는가? 채용하려는 직무의 핵심 스킬은 무엇인가? 이 질문들에 대한 답은 지원자가 채용되기 위한 기본 요건을 규정한다. 다른 특성들을 보지 말아야 한다는 것은 아니다. 지원자의 다재다능한 면을 알아보는 것은 바람직한 행위다. 단, 그 부분이 지원자를 배제할 요건으로서 작용하지는 말아야 한다.

 

사전 선별 절차는 극히 중요하다. 사전 선별은 회사의 핵심 가치에 따라 지원자를 걸러내는 단계다. 업무와 전혀 관련 없는 기술들에 대한 객관식 온라인 시험으로 지원자를 평가하는 것은 최악의 방법이다.

 

번트 홈런

우리가 사용 중이던 기술들이나 TDD에 대한 경험 수준은 낮았지만, 나는 그가 새로운 것을 시도하는 데 얼마나 열정적인지 알 수 있었다. 그는 업무 시간에는 허락되지 않는 배움의 욕구를 채우기 위해 개인 시간을 투자하고 있었다. 올바른 환경과 기회만 주어진다면 아주 훌륭한 개발자로 빛날 매우 전형적인 스타일이었다.

경력 개발자를 위한 채용이었지만 나는 그를 그냥 보낼 수 없었다. 1년 후 그는 우리 팀에 합류했고 지금은 팀의 가장 훌륭한 개발자 중 한 명이 되었다.

면접을 할 때 특정 기술에 대한 지식이 아니라 지원자의 재능, 태도, 열정 그리고 잠재성을 보아야만 한다.

 

사전 면접용 코딩 시험

지원자에게 면접 전에 코드를 제출하게 하는 것도 사전 선별을 위한 좋은 방법이다. 단, 지원자에게 충분한 시간을 주어야 한다. 제출 마감 몇 시간 전에야 문제를 주고 코드를 제출하게 하는 것은 바람직하지 않다. 코드를 통한 선별에서는 지원자가 작성할 수 있는 최선의 코드가 어떠한지 알아보는 것이 목적이지 주어진 문제를 얼마나 빨리 코드로 구현하느냐를 시험하는 것이 아니다. 시간 제한을 짧게 하면 지원자로 하여금 좋은 코드를 작성하는 것이 아니라 문제 해결에만 집중하게 만든다.

한 가지 좋은 방법은 시간 제한을 아예 두지 않는 것이다. 아무 때나 지원자가 준비되었을 때 코드를 제출하게 한다. 이런 방법은 계속해서 채용이 필요한 큰 회사나 좋은 지원자들을 누적해서 확보하는 데 특별히 관심이 있는 작은 회사들에게 적합하다.

 

이력서나 전화 인터뷰보다 제출된 코드를 보는 편이 훨씬 더 낫다.

어떤 지원자는 채용될지 모를 상황에서 코드를 제출하느라 긴 시간을 소모하기를 꺼릴 수도 있다. 이 경우 회사 입장에서는 오히려 바람직하다. 최소한 코드를 제출한 지원자들은 그만큼 채용 전형을 진지하게 생각하고 있고 회사에 들어오길 원하는 사람이라고 볼 수 있다.

 

지원자와 회사 모두 면접을 어떻게 하는지 알아야 한다

보통 회사의 몇몇 고참 개발자들만이 기술 면접을 수행한다. 그런 방식이 합리적인 듯 보이고 얼마 간은 동작할 수 있지만 계속되지 못한다. 강한 팀은 각 개발자들 모두 면접을 진행할 수 있어야 한다. 모든 개발자들이 팀이 기대하는 인재를 발굴해 낼 수 있어야 한다.

경험 많은 개발자는 면접을 진행할 때 반드시 경험이 적은 주니어 개발자를 대동하여 참관하게 해야 한다. 노련한 개발자가 면접을 어떻게 진행하는지 지켜본 경험은 나중에 그 주니어 개발자가 면접을 수행할 때 많은 도움이 될 수 있다.

 

개발자 채용 면접은 개발자가 보아야 한다

함께 일할 동료가 새롭게 채용될 때, 그 선발 과정에 아무런 의견도 반영할 수 없으면 개발자들은 무력감에 빠진다. 어느 날 갑자기 팀장이 나타나서 “오늘부터 새로운 개발자가 충원되었습니다. 여기는 김아무개씨입니다. 잘 해 보세요.“라고 하면 그저 당황스러울 뿐이다.

좋은 개발자는 나쁜 개발자를 채용하지 않는다. 좋은 개발자는 그들 자신보다도 더 훌륭한 개발자를 찾으려 노력한다. 좋은 개발자는 훌륭한 팀을 구성하는 것이 얼마나 중요한지 잘 알고 있다. 훌륭한 팀은 회사뿐만 아니라 개발자들 자신에게도 이익이 된다.

회사는 개발자 채용 면접을 할 때 반드시 개발자로 하여금 면접관 역할을 하도록 해야 한다. 지원자 입장에서도 개발자가 아닌 사람이 면접을 하고 있다면 다른 회사를 찾아보는 것이 좋다.

 

 

 

Chapter 11. 잘못된 면접 방식

경험 많고 재능있는 개발자들은 자신이 일할 회사 또는 고객을 신중하게 가려서 선택한다. 금전적인 보상 수준보다도 자율성, 배움, 목적, 생산적 파트너십, 열정적인 사람들, 좋은 업무 환경과 같은 것들을 더 우선해서 따진다. 어떤 채용 절차를 거치는지, 특히 면접에서 어떤 사람을 만나는지는 그 회사에 들어갈 것이냐 말 것이냐를 결정짓는 매우 중요한 요소다.

 

똑똑한 척하는 면접관을 세운다

면접관이 지원자보다 똑똑하거나 더 우월해보이고 싶어해서는 안 된다. 면접관의 사사로운 즐거움을 위해 지원자를 힘든 상황으로 몰아붙이고, 자신의 직함, 권한, 지식같은 것들로 지원자를 압도하고 싶어 해서는 안 된다.

지원자 앞에서 자신이 세상에서 제일 높은 사람인 듯 위세를 부려서는 안 된다. 다시 말해, 거만하고 오만한 사람이 되어서는 안 된다.

상황에 맞지도 않고 배배 꼬인 질문으로 똑똑한 척 하는 것은 금물이다. 어느 정도 경험이 있고 실력있는 개발자라면 면접관의 성향을 즉시 알아채고 같이 일하기 싫다는 생각을 할 것이다.

사람을 채용할 때는 파트너가 될 사람을 찾아야 한다. 그냥 고분고분하게 맹목적으로 시키는 대로만 하지 않고, 당신의 팀이 더 나아질 수 있도록 도와줄 수 있는 사람이어야 한다. 지원자 앞에서 겸손하고 정직해야 한다.

지원자를 프로페셔널 개발자로서 대하고, 채용을 위한 평가나 취조가 아니라 당신이 존중하는 누군가와의 유익한 기술 토론이 되도록 면접을 이끌어야 한다. 무엇보다도, 지원자의 이야기를 경청하고 그에게 마음을 여는 것이 중요하다. 실제로 무언가 새로운 것을 배울 가능성이 높다.

 

수수께끼식 질문을 던진다

직무와 전혀 관계 없는 바보 같은 질문은 하지 말아야 한다. 비행기에 골프 공이 몇 개나 들어갈까? 정육점 점원은 키가 180cm이고 280mm 스니커즈를 신고 있다. 그의 몸무게는 얼마일까? 이런 수수께끼 같은 질문들에 답할 수 있느냐 없느냐는 좋은 코드를 작성하고, 좋은 팀 플레이어가 되고, 프로페셔널다운 태도를 가지는 것과 전혀 관계 없다. 이런 두뇌 장난같은 질문들은 완전히 시간 낭비다. 구글의 면접관들도 잘못된 것을 깨닫고 이런 질문을 그만둔 지 오래되었다.

 

답을 모르는 질문을 한다

면접 전에 구글에서 질문과 답변을 검색해보는 것은 의미 없는 행위다. 면접관으로서 어떤 질문에 어떤 답변이 나와야 하는지 잘 모르겠다면 채용 중인 직무와 관련해서는 그다지 중요한 질문이 아닐 가능성이 높다. 해당 직무에 대해서 잘 알고 있다면 무엇이 중요하고 무엇이 중요하지 않은지 이미 알고 있을 것이다.

엉뚱한 질문으로 지원자를 혼란스럽게 하거나 잘못 이끌지 말자. 팀 동료에게 흔히 하지 않는 질문이라면, 팀 동료가 짜증을 낼 질문이라면, 지원자에게도 삼가해야 한다.

 

지원자를 바보를 만든다

면접관의 대화 내용, 몸짓과 표정들을 보고 그 임원과 내가 잘 맞을 거라는 생각이 들었다. 하지만 수석 아키텍트는 심기가 불편해 보였다. 그는 대화 중간에 끼어들며 이전 프로젝트에서 내가 설계하고 구현했던 아키텍처에 대해서 일부분 설명해줄 것을 요청했다. 즉시 일어나서 화이트보드에 전에 개발했던 시스템에 대해서 그림을 그리며 설명을 했다. 내가 설명을 마치자 수석 아키텍트는 임원을 잠깐 쳐다보고는 다시 나를 향해 “너무 단순하네요. 그건 제대로 된 실제 아키텍처가 아닙니다.”라고 무시하는 말투로 말했다. 경멸하는 태도를 확실히 느꼈다.

심호흡을 하고 마음속으로 숫자를 헤아리며 마음을 가라앉혔다. 그 시점에서 그 수석 아키텍트와 함께 일할 수 없을 거라는 생각이 들었다. “감사합니다. 저는 그 말씀을 큰 칭찬이라고 생각하겠습니다. 이 단순한 아키텍처가 3개 대륙에 걸쳐 2천만 명이 넘는 가입자를 서비스하고 있습니다. 이 보다 더 복잡하게 만들지 않고서도 해냈다는 것을 기쁘게 생각합니다.” 거기까지가 마지막이었다. 이 말을 하기 전까지는 그 수석 아키텍트가 나를 그저 좋아하지 않는 수준이었겠지만 이제는 나를 증오하고 있을 것이 뻔했다.

임원은 면접을 되살리려고 애썼지만 파트너십은 물 건너 갔다는 것이 분명했다. 나는 그 임원에게 면접을 계속하는 것이 의미가 없음을 설명했고 면접 기회를 준 것에 감사를 표하고 자리를 떠났다.

 

인터넷 접속을 막는다

코딩 면접을 할 때 인터넷을 사용하지 못하도록 접속을 막는 회사들이 있다. 인터넷을 사용할 수 없어야 지원자의 실제 실력을 알 수 있다는 게 이유다. 지원자들이 채용되어 실제 업무 현장에 투입될 때 인터넷 접속이 안 되어도 일을 할 수 있을까? 코딩에 필요한 모든 것을 머릿 속에 외우고 있을까? 온라인에서 아무것도 검색할 수 없어도 시스템 개발이 가능할까? 나는 아니라고 본다.

솔루션들을 탐색하고 더 나은 문제 대응 방법을 찾는 것은 소프트웨어 개발자로서 갖추어야 할 핵심적인 능력이다. 인터넷 접속을 막는 것은 전혀 합당하지 않다. 인터넷 검색때문에 코딩 면접이 변별력을 잃을 수 있다면 면접 과제 자체에 문제가 있다고 본다.

 

종이에 코드를 작성하게 한다

지원자에게 종이나 화이트보드에 코드를 작성토록 하는 것은 참으로 바보같은 면접 방법이다. 면접관 스스로도 할 수 없는 일이나 실제 업무 현장에서 부딪히지 않을 상황을 지원자에게 요구해서는 안 된다. 실제 업무에서도 종이에 테스트 코드 작성, 코드 리펙토링을 하는가? 종이에 작성한 코드를 리펙토링하기 위해 종이를 찢어서 이리저리 맞추어 보는가? 정말 쓸데없는 일이다.

고등학교 교사가 학생들에게 알고리즘의 의사 코드를 작성하라고 하는 것과 프로페셔널 소프트웨어 개발자를 채용하는 것은 다르다. 자신의 도구와 기술을 마스터하고 테스트와 리펙토링을 통해 잘 작성된 코드를 만들 수 있는 개발자를 찾아야 한다. 종이나 화이트보드에 불편하게 끄적인 코드가 아니라 실제 도구를 이용해서 생산된 실제 코드를 평가해야 한다.

 

알고리즘 문제를 낸다

알고리즘 연습문제를 코딩 면접 과제로 선택하는 면접관들이 많다. 시스템 개발에 필요한 상당수의 업무들이 알고리즘에 대한 깊은 이해를 필요로 하지 않는다. 그럼에도 불구하고 “지원자의 문제 해결 능력을 보아야 한다.”라고들 이야기한다. 물론 틀린 이야기는 아니지만 알고리즘 문제 대신 회사의 실제 프로젝트와 가까운 다른 연습문제를 통해서도 ‘문제 해결 능력’을 평가할 수 있다.

여러 시스템들의 문제들 중 거의 대부분이 알고리즘이 어떻게 작성되었느냐와는 관계가 없었다. 테스트가 덜 되었거나 또는 좋은 테스트 방법이 준비되지 못했거나, 잘못된 설계, 떨어지는 응집성, 깊은 종속성, 새 기능 추가 시 부족했던 리펙토링, 지속적인 요구사항 변경, 도메인 모델이 꼼꼼하지 못했거나 등이 가장 흔한 문제였다. 이러한 것들이 ‘실제 문제’였다. 알고리즘은 절차적이고 함수적인 형태로 구현된다. 알고리즘을 만들 때 비즈니스 도메인 모델이나 클래스를 만들지는 않는다.

시스템의 주요 문제가 알고리즘이 아니라면 코딩 면접 때 알고리즘 문제 대신 실제 문제에 가까운 과제를 제시해야 한다. 지원자가 비즈니스 도메인을 표현하고 솔루션을 설계할 역량이 있는지에 집중해야 한다. 테스트 주도 개발이나 설계에 스킬이 뛰어난 개발자를 찾고 있다면 그 부분을 반영할 수 있는 코딩 문제를 제시해야 한다.

애플리케이션이 온통 알고리즘에 대한 것이라면 당연히 알고리즘 개발 역량을 평가해야 한다. 요지는 코딩 면접에 알고리즘 문제를 내야 하느냐의 여부가 아니라 프로젝트를 위해 실제 필요한 역량이 무엇인지, 무엇이 가장 가치 있는지를 면접용 코딩 문제에 잘 반영하고 있어야 한다는 것이다.

 

전화 면접을 한다

모국어를 사용하는 사람들 간에는 전화로 의견을 나누기가 쉽지만 그렇지 않으면 전화로 이야기를 하는 것 자체가 상당한 고욕이다. 서로 마주보고 이야기하는 것이 아니기 때문에 말하는 단어마다 제대로 알아들었는지 알 수가 없다. 몸짓이나 표정 없이, 종이나 화이트보드를 이용하지 않고서는 원하는 의도를 표현하기가 쉽지 않다.

해외에 있는 지원자를 면접해야 할 경우와 같이 어쩔 수 없을 때만 전화 면접을 사용하자. 오프라인에서 직접 얼굴을 마주보는 면접이 가장 바람직하다.

 

요약

진정 보고 싶은 것은 그 지원자가 할 수 있는 최선의 모습이다. 지원자와 짝을 이루어 좋은 도구로 무언가를 만들어 내는 모습을 지켜보자. 테스트를 어떻게 작성하는지, 리펙토링을 어떻게 하는지, 좋은 네이밍을 할 줄 아는지 등을 평가해야 한다. 지원자가 함께 일할만한 동료인지 알아보기 위해 자연스럽게 대화하자.

좋은 개발자에 대한 수요는 매우 높다. 뛰어난 개발자와 일하고 싶다면 그들과의 면접을 어떻게 수행해야 좋은지 알고 있어야 한다. 면접은 지원자의 입장에서 회사를 가늠하는 자리라는 것을 잊지 말아야 한다. 즉 좋은 개발자들은 거꾸로 회사를 면접하여 평가하고 나쁜 회사들을 걸러낸다.

 

 

 

Chapter 12. 낮은 사기의 대가

애자일 행오버: 낮은 사기

오랫동안 많은 애자일 팀들과 일하면서 수많은 개발자들이 동기부여 없이 일에 자부심을 느끼지 못하는 것을 봤다. “단순히 밥벌이일 뿐입니다. 그냥 출근해서 일하는 거예요”. 왜 자신의 일을 즐기지 못하는 사람들과 함께 일해야 하는 상황이 그토록 흔할까? 왜 좀비처럼 일하면서 퇴근 시간만 바라보는 불행한 개발자들을 매일같이 봐야만 할까? 왜 동료들은 프로젝트와 회사를 위해 최선을 다하지 않는 것일까? 나는 진정으로 동기 부여가 되어 일을 즐기고 있나?

 

애석하게도 현실은 애자일 도입을 새로운 절차 정도로 이해하는 회사들이 많다. 그런 회사들은 개발자들이 새로운 절차를 기계적으로 따르기만 하면 애자일스럽게 일이 되는 줄로만 안다. 하지만 개발자들은 여전히 과거에 하던 것과 똑같은 방식으로 소프트웨어를 개발한다. 애자일 도입 이전에도 동기 부여가 되어 있지 않았다면 애자일 도입 이후에도 마찬가지다.

 

그저 ‘출퇴근‘만 하는 개발자들로 인한 대가

사람들은 서로 다른 것들을 즐거워하고 그들만의 방법으로 열정을 표현하다.

열정의 부재 자체가 열정적인 개발자들을 화나게 것은 아니다. 열정적인 개발자들을 화나게 하는 것은 열정을 다해서 애플리케이션을 더 나아지게 하고 일하는 방식을 개선하려고 온갖 노력을 쏟는 동안 다른 개발자들이 그저 뒤에서 팔짱만 끼고 구경하거나 심지어 방해하는 것이 화가 날 뿐이다.

 

항상 그렇지만 상황이 안 좋아지면 제일 먼저 가장 능력 있는 개발자들이 떠나간다.

 

낮은 수준의 동기가 만드는 제약

• 자신에게 아무런 권한이 없다고 생각한다.

• 그런 일을 이끌어가야 할 당사자가 되고 싶지 않다.

• 그렇게 되기에는 복잡한 장애요인이 너무 많다.

• 뭔가 바뀌는 것이 가능하다고 믿지 않는다.

• 무엇이 더 나은 일인지 사람들의 동의를 받기 힘들다

• 아무 상관 없다. 그냥 출퇴근만 하면 된다.

 

일을 제대로 할만한 동기 부여가 되어 있는가? 스스로의 일을 개선하는 데 진정 관심을 가지고 있는가? 일을 더 잘 할 수 있도록 지속적으로 자기계발을 하고 있는가? 회사가 하는 일이 사회에 기여하고, 해야 할 가치가 있다고 느끼고 있는가? 회사가 해내는 일을 좋아하는가?

 

개발자들에게 열정을 불어넣기 

소프트웨어 장인에게 항상 최선을 추구하는 것은 내재된 본능과도 같다.

 

소프트웨어 장인은 다른 사람에게 무엇을 하라고 명령하는 대신 다른 개발자들과 함께 앉아 페어 프로그래밍을 하면서 그들의 지식과 경험 열정을 나눈다. 단순히 일을 완료하는 것 외에도 소프트웨어 장인은 항상 다른 여러 개발자들의 멘토로서 행동하는 데 주의를 기울인다. 소프트웨어 장인은 항상 소프트웨어에 대해서 이야기하고 자신의 자기계발 활동을 다른 사람들과 공유하려 한다.

 

가장 먼저 했던 것들 중 한 가지는 몇 명의 소프트웨어 장인을 새로 합류 시킨 것이었다. 소프트웨어 장인을 팀에 들이는 것은 기술적인 문제 해결에 도움이 될뿐만 아니라 열정을 불어 넣고 혁신을 일으키는 데 지지자이자 동맹이 되어 준다는 것이다.

우리는 스크럼을 하고 있었다. 스크럼 일일 스탠딩업 미팅 때 서로에게 “지난 미팅 이후 뭔가 새롭게 배운 것을 공유할 분 있습니까?”라고 물었다. 첫 번째 주에는 나와 다른 개발자 한 명만이 손을 들고 배운 것을 공유했다. 책이나 블로그에서 읽었던 글이나 지난 주에 시도했던 기술 또는 코딩 내용에 대해서 이야기했다. 회의가 거듭될수록 점점 더 많은 개발자들이 동기가 부여되어 일일 스탠딩업 미팅에서 자신이 배운 내용을 공유하거나 다른 개발자에게 새로운 것을 배우려고 하였다. 블로그 글에 대한 링크나 비디오, 책들도 공유하기 시작했다. 어느 날부터 갑자기 소프트웨어, 기술, 방법론, 실행 관례, 업무와 관련해 당면한 문제들을 점심 시간이나 휴식 시간에 점점 더 많이 이야기하기 시작했다. 이것이 가능했던 이유는 기존의 개발자들이 새로 합류한 소프트웨어 장인들에게서 열정과 전문성을 엿볼 수 있었고 자신들도 그렇게 되고 싶다는 동기가 부여되었기 때문이다.

 

그들 입장에서도 개발자들과 함께 일하는 것이 훨씬 더 행복해졌음은 물론이다. 개발자들이 스스로 만든 제품의 품질에 얼마나 신경을 쓰는지, 회사를 생각해서가 아니라 그 일 자체를 즐기기 때문에 그렇게 한다는 것을 모두가 느낄 수 있었다.

 

 

 

Chapter 13. 배움의 문화

잘못된 방향으로 동기 부여하기

잘못된 테스트는 아예 테스트가 없는 것보다 못하다.

 

사람들에게 새로운 절차나 새로운 실행 관례를 강제한다고 조직을 변화시킬 수 없으며 우리는 배움의 문화를 만들어 내야 한다. 사람들 스스로 모든 것을 더 나아지게 하고 싶어하는 동기를 부여할 수 있어야 한다.

 

배움의 문화 만들기

개발자들이 훌륭해지는 만큼, 회사도 혁신적이고 기민해진다. 개발자들이 행복한 회사라면 외부의 훌륭한 개발자들을 유인할 수도 있을 것이다.

 

• 기존 결정들에 대한 재검증: 새로운 사람은 기존 결정이 이루어진 맥락을 이해한 후 그 결정이 올바른 것이었는지 확인해 줄 수 있다.

• 지식의 공유: 새로운 개발자는 특정 문제들이 어떤 식으로 해결되었는지 배울 수 있다.

• 개선: 새로운 개발자는 문제들을 해결할 더 나은 방법을 제안할 수도 있다.

• 공동 학습: 서로 현재의 해결책을 토론하고 지식들을 공유하고 나면 기존 멤버와 새로운 개발자 모두 더 나은 해결책이 떠오를 수 있다.

 

그룹 코드 리뷰하기

• 주석은 주관적, 개인적으로 표현되어서는 안 된다.

• 누가 코드를 작성하느냐는 중요하지 않다.

• 그룹 코드 리뷰 시간에 커밋 히스토리를 뒤지지 않는다. 비난할 사람을 찾기 위해 과거를 파헤치지 말고 미래를 변화시키는 데 집중한다.

• 주석은 반드시 객관적이고 생산적이어야 한다. 왜 그것이 엉망인지가 아니라 어떻게 코드를 개선할지에 집중해야 한다.

• 퍼실리테이터의 도움이 필요할 수도 있다. 퍼실리테이터의 역할은 모두에게 발언권을 주고 누군가를 비난하는 상황이 생기지 않도록 하는 것이다.

• 큰 진전을 이룰 것이라 기대하지 않는다. 이슈 한 가지에 대해서 너무 오랫동안 이야기되더라도 개발자들이 원한다면 그냥 그렇게 한다.

 

코딩 실습하기

다음은 좋은 코딩 실습을 하기 위한 몇 가지 지침이다.

• 퍼실리테이터는 반드시 연습문제를 잘 알고 있어야 한다. 사전에 문제를 두 번 이상 풀어 보았어야 한다.

• 개발자는 페어 프로그래밍으로 연습문제를 푼다. 이때 이전에 페어 프로그래밍을 같이 한적이 없는 개발자들을 선정하는 것이 좋다.

• 퍼실리테이터가 별도로 지정하지 않은 한 기본 원칙으로서 반드시 TDD를 지켜야 한다.

• 모든 개발자들이 같은 연습문제를 풀어야 한다. 이렇게 하면 문제의 해답들을 서로 비교하여 잘한 것과 못한 것을 되새길 수 있고 문제 풀이가 아니라 훈련으로써의 의도에 더 집중할 수 있다.

• 퍼실리테이터는 개발자를 살피고 도와주어야 한다. 훈련으로써 의미있는 비판적인 질문을 던지는 것이 좋다. 정답이나 직접적인 힌트를 주지 않도록 않다.

• 연습문제 풀기가 끝나면 퍼실리테이터는 반드시 리뷰 시간을 갖는다. 모든 개발자들의 결과물을 공유하여 어떻게 했는지 무엇을 배웠는지 이야기하게 한다.

• 실습이 끝난 후 개발자들은 서로의 페어 프로그래밍 파트너에게 감사를 표해야 한다.

 

다음은 회사 안에서의 코딩 실습에서 고려해야 할 중요한 요소들이다.

• 코딩 실습을 업무의 연장으로 만들지 않는다. 코딩 실습의 의도는 안전한 환경에서의 훈련과 배움이다.

• 한 실습에 2시간 정도를 할당한다. 한 시간은 회사의 업무 시간을 부여하고 다른 한 시간은 개발자 개인 시간을 들이도록 한다. 예를 들어 업무 시간이 9-18시라면 17-19시를 코딩 실습 시간으로 잡는다. 이렇게 함으로써 회사와 개인 모두 배움의 문화를 만드는 데 투자하도록 한다.

• 퍼실리테이터 스스로 사전에 코딩 실습을 수차례 반복 연습한다. 다른 개발자들이 코딩 실습을 위해 사전에 준비할 일은 거의 없다. 퍼실리테이터는 코딩 실습을 주관할 때 최대한 친근해야 한다. 그래야만 다음 코딩 실습에 개발자들이 부담 없이 참여할 수 있다.

 

아무도 참여하려 하지 않는다면

더 나은 일터로 만들기 위해 모든 사람을 바꿀 필요는 없다. 배움의 문화를 만들려는 대다수의 시도들이 실패하는 이유도 거기에 있다.

 

모범을 보여라

“나는 TDD를 좋아하지만 팀의 다른 개발자들은 관심이 없다. 그래서 나도 안 하고 있다.” 어떤 개발자는 이렇게 불평한다. 이것은 그냥 변명일뿐 소프트웨어 장인으로서의 태도는 아니다. 당신 스스로도 하지 않으면서 어떻게 다른 사람들을 설득할 수 있겠는가?

 

특별히 경험이 많지는 않더라도, 새로운 길을 추구하는 열정적인 사람의 존재 자체가 팀 전체에 자극을 주는 열쇠일지도 모른다.

 

허락을 구하지 마라

개인 시간을 들여 공부하고 연습하는 데 상사의 허락을 구할 필요는 없다. 대부분의 회사들에서 그렇다. 심지어 업무 시간에 공부를 하더라도 상사에게 허락을 구하지 않는다. 책임있게 행동하면 될 뿐이다. 팀이 스스로 더 나아지기 위해서 훈련하는 것에 대해 민감하게 반응하고 불평할 관리자는 없다.

 

리듬을 만들라

핑곗거리를 찾지 말고 나 자신부터 그런 개발자가 되자.

 

 

 

Chapter 14. 기술적 변화의 실행

회의론의 종류

테렌스 라이언Terrence Ryan은 그의 저서 『기술적 변화 추진하기Driving Technical Change』에서 회의론의 종류를 ‘무지’, ‘대중’, ‘냉소주의’, ‘트라우마’, ‘너무 바쁜’, ‘상사’, ‘몰상식’으로 구분했다.  

• 무지: 특정 도구나 실행 관례를 쓰지 않는 주요한 이유가 단지 잘 몰라서인 경우다. 그러한 것이 존재하는지도 알지 못한다. 무지에 대한 본능적인 두려움 때문에 새로운 아이디어가 제안되면 깊이 고민해보지 않고 거부부터 한다. 이런 개발자들은 책이나 블로그를 읽는 데 그다지 시간 투자를 하지 않는다. 자신이 일하고 있는 좁은 책상에만 갇힌 채 밖에서 어떤 일이 일어나고 있는지 이해하려 노력하지 않는다.

• 대중: 어떤 결정을 내리기에 자신의 경험이 충분치 않다고 생각한다. 자신감이 부족하여 중요한 결정들을 더 똑똑하고 경험 많은 개발자들에게 맡기려 한다. 누군가 시키지 않았다면 스스로 일을 벌일 권한은 없다고 생각한다. 누군가가 특정 실행 관례나 도구를 사용하도록 압박을 가하면 쉽게 수용한다. 이러한 종류의 개발자들은 팔로워들로 리더들은 아니다.

• 냉소주의: 논쟁을 좋아하고 지속적으로 자신이 남보다 잘났음을 증명하려 든다. 사사건건 딴지를 걸고, 사소한 것을 꼬투리 잡아 작은 문제를 큰 문제로 이슈화시킨다. 개인적인 감정이 있어서가 아니라 과거 잘못된 경험 때문에 새로운 것의 장점을 보지 못하는 것일 수도 있다. 이런 종류의 개발자들은 똑똑하게 행동하는 것보다 똑똑해 보이는 것을 더 중요하게 여긴다. 새로운 것을 받아들이지 않는 이유 중 하나가 그들 스스로의 약점을 드러내고 싶지 않아서일 수도 있다. 새로운 것을 도입하게 되면 그들의 권위가 위협받는다고 생각한다. 이들에게 있어서는 새로운 환경에 스스로를 시험에 들게 하는 것보다 꼬투리를 잡고 방해하는 것이 더 쉽다.

• 트라우마: 과거 특정 실행 관례나 도구를 사용하려 시도했으나 실패한 경험이 있는 사람들이다. 새로운 것에 대한 좋은 경험이 없기 때문에 다시 반복하고 싶어하지 않는다. TDD의 경우 팀에 노련한 경험자가 없었다면 꽤 긴 기간 동안 제대로 되지는 않고 문제만 겪었을 가능성이 높다. 테스트가 너무 길고 작성하기도 어려웠을 것이다. 어쩌면 어떤 테스트들은 수행하는 데 너무 오래 걸리거나 쉽게 망가졌을 수도 있다. 이런 것들은 TDD를 처음 실행하는 개발자들이 흔하게 부딪히는 문제들이다. 이런 나쁜 경험들이 있으면 또 다시 그런 경험을 할 수도 있는 상황을 피하려 한다.

• 너무 바쁜: 너무 바빠서 뭔가를 할 시간이 전혀 없는 사람들이다. 어떤 일의 장기적인 비용을 보지 못하고 근시안적인 판단을 한다. 무언가 일을 올바르게 할 시간은 없지만 똑같은 일을 계속해서 반복할 시간은 있다. 이들에게 있어서 TDD 같은 실행 관례는 시간이 너무 오래 걸리고, 별도로 시간을 내야만 하는 일이다. 하지만 전체 시스템을 매번 수동으로 테스트하고 문제를 분석하고 버그를 수정하는 시간은 보지 못한다. 테스트의 부재로 인해 코드 수정을 극도로 조심하느라 소모하는 시간도 보지 못한다. 특히 시스템이 망가질까 두려워 큰 규모의 개선은 엄두도 못 낸다는 사실이 얼마나 큰 비용인지 알지 못한다. 이들의 눈에 보이는 것은 너무 바빠서 일하는 방식을 바꿀 시간이 없다는 것뿐이다.

• 상사: 상사가 기술 배경이 없다면 당신이 제안하는 것들이 어떤 장점이 있는지 이해하지 못할 가능성이 높다. 상사는 관리상의 문제들을 안고 있고, 당신은 개발상의 문제가 있다. “뭔가 자동화하는 도구를 만들자”라고 설명하지 말고 “프로젝트 운영 비용을 줄이자”라고 이야기해야 한다. “코드를 지금보다 유지보수하기 쉽게 만들자” 대신 “프로젝트 딜리버리 주기를 줄이자”라고 말해야 한다. 상사가 개발자 출신이라면 더 큰 어려움에 봉착할 수도 있다. “내가 개발할 때는 TDD 같은 것을 안 해도 소프트웨어를 제때 개발하는 데 아무런 문제가 없었다.”라고 말할 수 있다. 기술 관리자들이 소프트웨어 개발 스킬 때문에 승진한 경우는 극히 드물다. 물론 동의하지는 않을 것이다. 여전히 코딩을 하는 관리자들이라면 위에서 설명된 ‘너무 바쁜’류에 속하는 경우도 있다.

• 몰상식: 가장 최악의 타입이다. 다른 타입들의 경우 새로운 아이디어가 내세우는 전제들에 대한 거부감과 의심이 원인이며 오류가 있더라도 합리적이고 논리적인 판단을 한다. 상대방이 합리적이거나 논리적이라면 적어도 하나하나 따져서 의미 있는 합의를 도출할 수 있다. 하지만 몰상식한 사람들을 대상으로는 불가능하다. 논리적으로 반대할 내용이 없으면 이 문제에서 저 문제로 끊임없이 옮겨 다닌다. “그렇게 하면 성능 문제가 있을 것 같다. 자동화 테스트로는 사람이 하는 것만큼 효과를 낼 수 없다. 그리고 그 프레임워크는 보안 문제가 있다고 들었다.” 말이 막힐 때마다 이 부분에서 저 부분으로 아무런 합리적 근거도 없이 생트집을 잡는다. 그들의 하는 말의 내용은 아무런 상관이 없다. 단지 제안 내용을 받아들이기 싫을 뿐이다. 제안자를 그냥 개인적으로 싫어하는 것일 수도 있다. 어쩌면 퇴사를 생각하고 있거나, 다른 벌여 놓은 일이 많아서 더 이상 새로운 일을 만들기 싫은 경우일 수도 있다. 실제 내막을 알기는 어렵다.

 

일하는 동안 추가로 분류한회의론자들의 목록이다.

• 무념무상: 이들은 그냥 뭐가 어떻게 되든 아무런 상관을 하지 않는다. 이런 종류의 개발자들은 어떤 제안이나 제안을 하는 사람에 대항할 필요를 느끼지 못한다. 그냥 남들과 같이 흘러갈 뿐이다. 이들의 문제는 좋은 아이디어를 대충 엉망으로 구현해서 결과적으로 좋은 아이디어를 나쁜 아이디어로 만든다는 것이다. 예를 들어 나쁜 테스트 코드는 아예 테스트가 없는 것보다 못하다. 나쁜 테스트가 여기저기 생기도록 내버려 두면 TDD의 전체 개념 자체가 무력화된다. 애자일이 동작하지 않는 회사들은 TDD 뿐만 아니라 다른 실행 관례들도 그런 식으로 무력화된다.

• 피해망상: 위험한 개발자들이다. 이런 개발자들은 회사가 자신에게 피해를 주고 있다고 생각한다. 고과나 급여, 복리 후생 등에서 불공정한 대우를 받고 있다고 느낀다. 자신이 일하고 있는 회사를 싫어하고 불평불만과 회사에 대한 험담이 잦다. 자신이 담당한 프로젝트를 일부러 망치면서 “회사도 한번 당해봐야 돼”라고 혼잣말을 할지도 모른다. 이런 사람의 존재는 팀을 파괴하고 개발자들끼리 서로 비난하게 한다. 더 최악인 것은 이런 개발자들은 절대 회사를 나가지 않는다. 대신 회사가 자신을 해고해서 거꾸로 회사를 고소할 수 있을 때까지 기다린다.

• 무능력: 이들은 제안의 본질을 파악하지 못한다. 앞서 언급한 ‘무지’에 속한 사람들과는 확연히 구분되는 인지능력, 이해능력의 부족을 보인다. 이들은 상황을 명확하게 보지를 못한다. 막연하게 생각하며 이들이 하는 제안은 왜곡된 사실을 기반으로 한 어디선가 주워들은 설익은 아이디어들뿐이다. 이런 종류의 개발자들은 소프트웨어 개발을 그냥 월급을 받기 위한 노동으로만 본다. 그리고 무언가 노력을 하더라도 소프트웨어 개발자라는 직업이 그들의 적성에 맞지 않다는 것을 계속해서 증명할 뿐이다. “TDD는 좋지 않아요. 우리는 애자일을 해야 한다고 들었습니다. 모든 것을 최대한 기민하게(애자일) 해야 해요. 고객이 불평하면 바꿔야 합니다. 테스트를 작성하는 것은 안티 패턴입니다. 왜냐면 더 많은 코드를 작성해야 하고 그럼 느려질 거거든요.” 이들을 상대하면 한숨만 나온다.

• 상아탑 아키텍트: ‘몰상식’과 함께, 소프트웨어 장인이 부딪힐 수 있는 최악의 회의론자들 중 하나다. 모든 것을 알고 있다고 생각한다. 이들은 그 어느 개발자보다도 자기가 더 똑똑하다고 자신한다. 자신이 제일 높은 지위를 차지하고 있다고 생각하나 수년 동안 상용 시스템의 코드를 단 한 줄도 만들어 본 적이 없는 경우가 대부분이다. 코딩을 했다고 해도 현실과는 동떨어진 개념 설명용(Proof of concept) 코드 밖에 없다. 이들은 모든 기술적 결정에 자신이 책임져야 한다고 이야기하길 좋아하지만 실제로 책임을 지는 일은 극히 드물다. 일이 잘되면 자신의 덕이고, 일이 잘못되면 그들의 지시를 ‘제대로’ 따르지 않은 개발자 탓이다. 이들은 자신의 아이디어가 아니면 나쁜 아이디어로 취급한다. 이들은 코드를 작성하지 않기 때문에 항상 자신의 존재 이유를 증명해야 한다는 압박이 있다. 이들이 취미로 하는 일은 인터넷에서 새로운 기술 약어를 찾는 것이다. 이들은 어느 비싼 기술에 대한 광고 자료를 읽고서 멋진 파워 포인트 문서를 만들고, 신참 개발자들에게 프로토타입을 만들어 보라고 시킨다. 그리고 관리자를 꼬드겨 개발자들이 자신의 가이드를 따르도록 명령하게 만든다. 이들은 아직 비즈니스 담당과 개발팀 간에 요구사항 정리조차 되지 않은 시점임에도 프로젝트를 위한 기술 스택을 정의하는 것이 자신의 업무라고 믿는다.

• 좌불안석: 이들은 자신이 다른 사람으로 대체되어 직무를 잃거나 해고될까 봐 걱정한다. 이러한 개발자들은 사업의 핵심이 기술이 아닌 회사들, 즉 개발자들의 능력을 제대로 평가할 사람이 없는 조직에서 흔하게 만날 수 있다. 그들 스스로가 조직 내에서 유일한 기술 담당이기 때문에 단순히 ‘IT 부서 사람’으로만 알려져 있고 사내 IT 시스템과 모든 문제를(고장난 프린터의 수리도 포함해서) 해결하고 약간의 코딩까지 하는 해결사로 취급된다. 이들은 언젠가 회사에서 자신의 실제 가치를 알게 될까봐 두려워한다. 그리고 이들 앞에 나타나는 소프트웨어 장인을 그들의 실체를 폭로할 위협으로 바라 본다.

• 팬보이: 특정 주제나 관점에 광적으로 완전히 전념하는 사람들이다. 어떤 경우에는 아주 강박적이기까지 하다. 이런 종류의 개발자들은 특정 도구나 언어 프레임워크에만 아주 오랫동안 전념해서 해당 기술에는 전문가다. 자신이 잘 아는 분야가 그것 밖에 없기 때문에 자신이 전념하고 있는 그것만이 모든 것에 대한 최고의 해결책이라고 믿고 다른 모든 대안들을 거부한다. 강박증의 대상이 특정 도구나 프레임워크가 아닌 특정 디자인 테크닉이나 방법론, 절차같은 것일 수도 있다. 만약 이러한 사람들의 반대에 부딪힌다면 아주 긴 시간 동안 뜨거운 논쟁을 벌일 준비를 해야 한다.

 

상아탑 :: 세속적인 생활에 관심을 갖지 않고 정적(靜寂)·고고(孤高)한 예술지상주의 입장을 취한 19세기의 프랑스 시인 A.드 비니를 평론가 생트뵈브가 평할 때 사용한 말에서 비롯되었다.한편, 대학 또는 대학의 연구실을 지칭하는 말로 전용되기도 한다.
[네이버 지식백과] 상아탑 [象牙塔] (두산백과 두피디아, 두산백과)

 

준비

자기가 하는 말이 무엇인지 스스로도 제대로 모르면서 다른 사람을 설득할 수는 없다.

• 단순함을 추구해야 한다. 아이디어나 제안은 아주 명료하고 단순해야 한다. 어떤 제안을 말하기 전에 명료하게 정리부터 해야 한다. 누구든지 이해하기 쉽게 만들어야 한다. 가능하면 예제를 이용하는 것이 좋다. 제안이 받아 들여지느냐의 여부는, 그 내용도 중요하지만 커뮤니케이션을 얼마나 잘 하느냐가 큰 영향을 미친다.

• 상대방의 언어로 말해야 한다. 제안 내용에 따라서 설득해야 하는 상대방이 개발자, 관리자, 아키텍트, 투자자, 제품 오너, 비즈니스 분석가 등 성격이 다른 직무의 사람일 수 있다. 그 상대방이 사용하는 언어를 배우고 활용해야 한다. 관리자나 제품 오너에게 소스 코드나 프레임워크의 세세한 부분을 이야기하려 들어서는 안 된다. 대신 당신의 제안이 가져올 이익을 그들의 관점에서 그들의 언어로 말해야 한다. 관리자나 제품 오너가 대상이라면 유지보수 비용 절감이나, 릴리즈 주기 단축, 릴리즈 신뢰성 증대 이런 것들을 말한다.

• 말할 내용에 대해 스스로 제대로 이해하고 있어야 한다. 연구하고, 실험하고, 연습해야 한다. 어떤 반대 의견이나 문제 지적이 있을지 미리 생각하고 수용될만한 답을 미리 준비해둬야 한다. 제안이 가진 단점이나 예상되는 문제 상황은 질문이 나오기 전에 미리 밝혀야 한다. 특정 부분에 충분한 정보가 없다면 그 부분을 미리 투명하게 고백해야 한다. 제안이 가진 결점들을 미리 밝히는 것은 당신이 충분히 깊이 생각했다는 것을 보여주고 제안 자체에 대한 신뢰성을 높인다.

• 상대방을 존중해야 한다. 제안을 듣는 상대방을 바보처럼 느끼게 해서는 안 된다. 무례하고 공격적인 태도는 사람들을 방어적으로 만들어 설득 자체가 불가능해진다.

• 경청하는 법을 배운다. 당신만이 좋은 아이디어를 갖고 있다고 오판해서는 안 된다. 같은 문제더라도 사람들은 관점이 서로 다르다. 당신이 인지하지 못한 것들이 많이 있을 가능성이 다분하다. 당신만의 결론을 내리기 전에 모두의 말을 경청하고 정리해보아야 한다.

 

신뢰를 쌓으라

열정을 보여주는 것으로 부족하다. 무엇보다도 신뢰를 쌓으려면 역량이 있어야 한다.

 

신중하게 싸울 곳을 정하라

당신이 준비되어 있지 않다면 조직의 소프트웨어 개발 절차를 바꿀 수 없다. 모든 부분에서 싸움을 시작하지 말자. 모든 이슈들이 똑같이 중요하지는 않다. 정말 의미 있는 곳에 노력을 집중하고 더 빨리 가치를 얻을 수 있는 싸움에 우선순위를 두자.

 

두려움과 자신감 부족

두려움은 프로페셔널로서 행동하고 자신의 의견을 표현하는 것을 막고, 무능함은 우리를 둘러싼 일들을 올바른 방향으로 변화시키기 위한 싸움을 할 수 없게 한다.

무능한 사람들만이 일자리를 불안해 한다. 무능하고 비겁한 사람들은 일을 제대로 해내는 것보다 다른 사람의 뒤에 숨어서 실수를 떠 넘기고, 승진을 위한 정치 게임에 몰두하기를 좋아한다. “상사를 기분좋게 하는 것이 내가 승진하는 길이다. 회사가 어떻게 되든지 상관없다. 내 연봉과 보너스가 중요할 뿐이다.” 이런 태도는 매우 이기적이고, 프로페셔널하지 않을 뿐만 아니라 부도덕하다. 프로페셔널 개발자라면, 진정한 소프트웨어 장인이라면, 그에 맞는 윤리의식과 행동원칙이 있다. 소프트웨어 장인은 자신의 일과 커리어를 스스로 통제한다. 승진하기 위해 정치 게임을 해야 할 이유도, 일자리 하나에 목을 매야 할 이유도 없다.

당신의 주변을 바꾸고 싶다면, 두려움을 버려야 한다. 준비하고, 연습하고, 독서하고, 공부해서 스스로 도달할 수 있는 최고의 개발자로 거듭나야 한다. 무슨 일이 일어나든 항상 진실을 말해야 한다. 유일한 충고는 인격적으로 못되먹은 사람이 되지 말라는 것 하나뿐이다.  

 

상사를 설득하는 방법

용서를 구하는 것이 허락을 구하기보다 쉽다. 그냥 가서 하고 싶은 것을 하면 된다. 기술적 실행 관례라면 굳이 관리자가 관심을 가질 이유가 없다. 관리자들은 일정에 맞추어서 제품이 딜리버리되고, 예산을 지키고, 버그가 없는 것에 관심을 가질 뿐이다. 관리자들이 원하는 것은 고객과 이해관계자들의 만족이다. 개발자들이 TDD를 하든 페어 프로그래밍을 하든 지속적인 통합을 하든 상관하지 않는다.

 

관리자에게 있어서는 당신이 일을 완료했다고 보고하는 시점에 당신이 작업한 코드가 비즈니스 요구사항과 상용 시스템의 내용을(또는 사용자 인수 시험 내용을) 정확히 따르고 정상 동작한다는 것이 중요하다. 테스트와 리펙토링은 어떤 종류의 코딩 업무이든 당연히 내재되어 있는 사항이다.

 

팀이 TDD를 수용하도록 설득하는 방법

핑퐁 코딩은 TDD의 한 방법으로 한 사람은 기능 구현을, 다른 사람은 테스트를 작성하는 것이다. 테스트가 하나씩 통과될 때마다 역할을 바꾼다.

 

실행 관례를 전파하는 가장 효율적인 방법은 모범을 보이는 것이다.

 

회의론을 상대하는 방법

커뮤니케이션을 상대방의 수준에 맞게 잘 하는 것도 중요하다. 상사를 내편으로 만들려면 상사의 언어로 이야기를 해야 한다. 개발의 수준 문제를 끄집어 내어서는 안 된다. 상사의 수준에 맞게 대화의 수준을 올려야 한다. 생산성 향상, 비용 절감, 매출 증대, 일정 준수, 버그 감소, 예측 가능하고 꾸준한 개발 속도, 비즈니스 요구사항의 충족 등 이런 것들이 상사의 사항이다. 무언가 바꾸고 싶다면 그 변화들이 상사가 관심을 가지는 요소들에 어떤 영향을 미치는지 생각해야 한다.

 

열정을 공유하고, 모범을 보임으로써 사람들을 이끌고, 정직하고 투명해야 한다. 자신감을 축적하고 당신이 아는 것을 다른 사람들에게 가르쳐 주는 행위는 주변 사람들에게 신뢰를 쌓는 최선의 방법이다. 종국적으로는 롤 모델이 되어야 한다. 누군가가 따르고 싶어하고, 조언을 듣고 싶어하는 사람이 되어야 한다.

 

인수시험 :: ① 기준을 시스템이 만족하고 있는지 어떤지와, 고객이 시스템을 인수해서 좋은지 나쁜지를 결정할 수 있도록 하기 위해 행해지는 정식 시험.
② 시스템이 인수 기준을 만족하고 있는가의 여부를 판단하기 위해서 고객이 시스템을 인수하는가의 여부를 판단 가능하게 하기 위해 시행되는 형식 검사.
[네이버 지식백과] 인수 시험 [acceptance test, acceptance testing, 引受試驗] (전자용어사전, 1995. 3. 1., 월간전자기술 편집위원회)

 

프로페셔널이라면 자신의 결정에 책임을 질 수 있어야 해요. 뭔가 잘못되었을 때 누군가가 책임을 묻는다면 기꺼이 받아들일 것입니다.

 

진정한 소프트웨어 프로페셔널은 권한에는 항상 책임이 따른다는 것을 이해하고 있다. 권한을 갖고 싶다면, 책임질 수 있는 준비를 해야 한다. 이미 책임이 주어져 있다면, 관련된 의사결정에 권한도 가질 수 있도록 해야 한다. 상아탑 아키텍트들은 그들의 커리어에 해를 입을까봐 자신의 의견에 책임지기를 두려워한다. 관료주의와 정치 뒤에 숨는다. 그들이 당신 앞을 가로막는 것을 피하고 싶다면, 그들의 결정에 책임지도록 만들어야 한다.

 

이 모든 것을 다 챙겨야만 하는가

소프트웨어 장인이라면, 기술적인 역량뿐만 아니라 주니어 개발자들을 위한 롤 모델 역할도 할 수 있어야 한다. 소프트웨어 장인은 정직하고 투명해지기를 두려워하지 않는다. 고객을 속이거나 문제를 숨기는 방법으로 일을 하지 않는다. 소프트웨어 장인은 사람들이 듣고 싶어 하는 말이 아니라 진심을 말하며 자신의 행동에 책임을 지고 프로젝트를 위해 최선이라면 싸우기를 주저하지 않는다.

 

요약

신뢰야말로 변화를 이끌기 위한 핵심적인 요소다. 대화하는 상대방을 이해하고, 그 사람의 생각의 바탕에 어떤 이유들이 있는지 공감할 수 있어야 한다. 자신을 준비시키고 용감해지고, 주도하자.

 

 

 

Chapter 15. 실용주의 장인정신

품질은 선택사항이 아니다

가장 근본적인 문제는 싸고 그저 그런 코드로도 충분하다는 매우 잘못된 가정을 할 때가 많다는 것이다. 단기적으로는 그럴 수도 있다. 하지만 중장기적으로는 절대 그렇지 않다. 보통 품질의 코드를 목표로 하는 회사들은 형편없는 코드를 결과물로 내놓는 경우가 대부분이다. 쓰레기 더미가 굴러 점점 커지면 싼 것이 더 이상 싸지 않게 된다. 버그의 숫자가 늘어나고 새로운 기능을 추가하는 데 시간이 늘어나며 전체 애플리케이션을 다시 만들자는 이야기가 수면 위로 떠오른다. 관리자와 프로젝트 투자자는 그런 상황을 보지 못한다. 그들은 개발자가 아니다. 그들에게 소프트웨어 개발은 다른 분야의 서비스와 마찬가지로 그냥 돈을 내고 받는 서비스일 뿐이다. 다른 서비스 제공자와 마찬가지로 개발자들에게 좋은 품질의 결과물을 기대한다. 고객들은 돈을 지불한 그 이상의 가치가 제공되기를 당연시할 것이다.

 

어떤 결정을 하든지 간에, 심지어 저품질을 선택해야 하는 경우에서도 항상 품질이 좋기를 희망한다. 그 어떤 경우에도 비용을 지불한 서비스의 결과물에 문제가 발생하는 일은 좋아하지 않는다.

 

좋은 품질은 비싸고 시간이 오래 걸릴까

기능 구현을 완료했다는 의미는 그 기능이 상용 시스템이나 상용 시스템과 비슷한 내부 검증 환경에(아직 소프트웨어를 공개 배포할 수 없는 경우) 전개되었다는 의미다.

 

XP 실행 관례를 도입하면 개발자의 작업 속도가 늦어지지 않는다는 전제가 있다면 XP 실행 관례의 활용을 반대할 관계자가 있을까? 아마도 없을 것이다. 어떤 실행 관례를 배우고 마스터하는 데는 시간이 필요하다. 배우는데 시간이 든다고 해서 그 실행 관례가 나쁘다고 할 수는 없다. 실행 관례를 무시하는 대신 경험 많은 소프트웨어 장인을 더 많이 확보하여 팀 구성원들의 학습 곡선을 당기고 멘토링하는 데 관심을 기울여야 한다.

 

테트스 주도 개발이 항상 필요할까

나를 포함해서 경험이 많은 XP 개발자들은 TDD를 둘러싼 논란이 시간낭비라고 생각한다. 유능한 개발자라면 TDD 때문에 개발 일정이 지연되지 않는다. 그것이 진실이다. 논란은 아무런 의미가 없다. 경험 많은 XP 개발자들은 모든 것을 테스트 기반으로 수행한다. 그들에게 테스트를 먼저 생각하는 것은 전혀 어려운 일이 아니다.

 

TDD에 능숙한 개발자들은 TDD 때문에 개발이 지연되었다거나 시간이 없어서 테스트를 작성하지 못했다는 변명은 절대 하지 않는다. TDD등 XP 실행 관례를 전파하고 싶다면 먼저 스스로 충분히 능숙해져야 한다.

 

리펙토링

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

새롭게 추가할 기능이 레거시 코드에 큰 영향을 준다면 사전에 영향이 가해지는 부분을 리펙토링하는 것이 바람직하다. 새로운 기능을 추가하기 전에 다음과 같은 질문들을 던져 보아야 한다. 레거시 코드는 새 기능을 받아들일 준비가 되어 있는가? 수정해야 할 코드량은 어느 정도 되는가? 이 두 질문에 대한 답이 ‘아니오’와 ‘아주 많이’라면 먼저 레거시 코드를 리펙토링하여 새로운 기능을 받아들이기 쉬운 상태로 만들어야 한다. 받아들이기 쉽다는 것의 의미는 기존의 동작 방식을 전부 파헤치거나 변경하지 않고 새로운 기능으로 인한 영향을 최소화한다는 것을 의미한다. 즉 ‘확장에는 열려있고 변경에는 닫힌’ OCP 원칙을 준수할 수 있도록 코드를 리펙토링한 후에 신규 기능을 추가한다.

 

소프트웨어 개발 방법의 한 가지 예

실행 관례와 절차들은 그보다 더 나은 실행 관례와 절차가 나타나기 전까지만 가치가 있다. 프로그래밍 언어나 개발 도구에서도 마찬가지다. 이러한 개념은 자동차나 전자제품 등 거의 모든 것에 있어서 마찬가지로 적용된다.

 

래쇼날 통합 프로세스(RUP) :: 래셔널 통합 프로세스(Rational Unified Process, RUP)는 IBM의 래셔널 소프트웨어 부서에서 만든 객체 지향 개발 방법론이다. RUP는 하나로 고정되어 쓰인 프로세스가 아니라, 적응이 가능한 프로세스 프레임워크이다. 개발 조직과 소프트웨어 프로젝트 팀이 필요한 바에 따라서 프로세스의 요소들을 선택하여 조절할 수 있도록 설계됐다.
역사
래셔널 소프트웨어사는 래셔널 통합 프로세스(RUP)라는 소프트웨어 프로세스 제품을 개발했다. 이 회사는 IBM에 2003년 2월에 합병되었다. 이 회사의 제품은 샘플 산출물과 다양한 활동에 대한 자세한 설명을 바탕으로 한 서로 연결된 지식-베이스를 포함한다. RUP는 사용자가 쉽게 개발 과정을 수정할 수 있는 IBM Rational Method Composer (RMC) 라는 제품에 포함되어 있다.
1997년, 래셔널은 Verdix, Objectory, Requisite, SQ, Performance Awareness, 그리고 Pure-Atria 회사를 인수했다. 이 회사들의 경험을 바탕으로 하여, 래셔널은 현대 소프트웨어 공학에 필요한 여섯가지 우수 교훈들을 선정하였다.
1. 발견된 위험 요소를 원동력으로 반복적으로 개발하라.
2. 필수사항을 관리하라.
3.컴포넌트 기반의 구조를 도입하라.
4. 소프트웨어를 시각화하라.
5. 품질을 지속적으로 확인하라.
6. 변화를 통제하라.
이러한 우수 교훈들을 바탕으로 래셔널의 제품들을 개발할 수 있었다. 그리고 래셔널의 실무진들이 고객들을 도와 소프트웨어 개발의 품질과 예측성을 높였다. 필립 크루첸은 이러한 지식을 보다 쉽게 접근할 수 있도록 만들기 위해서 현대 소프트웨어 공학에 맞는 구체적인 프로세스 프레임워크들을 종합하는데 노력을 기울였다. 이 과정에서 Objectory의 HTML 바탕의 프로세스 전달 메카니즘을 적용했다. 그 결과로 탄생한 래셔널 통합 프로세스 (RUP)는 래셔널의 세 가지 전략적인 목표를 완수했다.
- 개발을 돕는 맞춤형 프로세스
- 이 프로세스를 자동으로 적용하는 도구
- 프로세스와 도구를 쓰도록 촉진하는 서비스
[위키백과] 래셔널 통합 프로세스 [Rational Unified Process, RUP]

 

장인이라면, TDD와 같은 XP 실행 관례들을 절대 불변의 진리라고 믿어서는 안 된다. 지금 당장 우리가 XP를 추구한다고 해서 더 나은 다른 방법을 찾아 보는 것을 멈춰서는 안 된다. 소프트웨어를 개발하는 방법이 하나밖에 없다고 생각하는 순간, 다시 말해 우리가 활용해야 할 실행 관례들이 정해져 있다고 믿는 순간 우리는 진화를 멈추게 된다. 특정 기술이나 실행 관례, 도구들에 대해 개별 상황에 대한 이해 없이 절대적, 교조적으로 판단하는 것은 소프트웨어 장인정신이라 할 수 없다. 소프트웨어 장인은 여러 가지 훌륭한 도구들을 포용하면서 맡은 일의 맥락에 가장 적합한 것을 꺼내어 적용할 수 있어야 한다.

 

소프트웨어 프로젝트는 우리를 위한 것이 아니다

프로페셔널로서, 소프트웨어 프로젝트가 개발자를 위한 것이 아니라는 사실을 이해할 필요가 있다. ‘나는 내가 뭘 하는지 알고 있고 나는 테스트를 작성할 필요가 없다’라는 태도는 이기적이고 오만한 것이다. 심지어 그것이 사실이라 하더라도 프로젝트가 당신을 위한 것은 아니다. 프로젝트는 한두 명의 슈퍼 개발자를 위한 것이 아니다. 프로젝트를 수행한 사람들이 떠나간 후 그것을 유지보수할 사람들을 고려해야만 한다. 원저작자들 없이 소프트웨어를 진화시켜야 하는 회사의 어려움을 이해해야 한다. 어떤 개발자들이 프로젝트에 추가하는 가치들이, 바로 그 개발자들의 참여를 조건부로 한다면 그것은 가치가 아니다. 그것은 실패 요인이다.

 

비범함과 평범함

그 어떤 바보 같은 개발자도 뭔가를 동작하게 만들 수는 있다. 비범한 개발자와 평범한 개발자를 가르는 기준은 어떤 방식으로 그것을 동작하게 만드느냐이다. 비범한 개발자는 요구사항을 충족하는 가장 단순한 코드를 만들어 경험이 적은 개발자가 이해하는 데 아무런 문제가 없도록 한다. 문제를 단순하고 우아한 방법으로 해결하는 것은 복잡하고 과잉된 방법으로 해결하기보다 훨씬 더 어렵다. 여기저기 넘쳐나는 그 모든 끔찍한 레거시 코드들이 바로 그 증거라고 믿는다. 비범한 개발자들은 심지어 단순하고 짧은 솔루션 이상의 것을 추구한다. 그들은 코드 한 줄도 짜지 않고 문제를 해결할 방법을 찾는다. 가장 훌륭한 코드는 작성할 필요가 없는 코드다.

잘 작성된 코드는 단순하고, 작고, 테스트 가능하며 이해하기 쉽다. 그리고 가장 중요한 부분으로 코드가 해야 할 일을 해낸다. 코드는 버그와 고통의 근원이다. 더 적게 작성할수록 더 좋다.  

 

단순한 설계를 위한 네 가지 원칙

소프트웨어 장인이라면 아키텍처, 디자인 패턴, 제네릭 솔루션 등을 떠올리기 전에 켄트 벡이 말한 ‘단순한 설계를 위한 네 가지 원칙’을 먼저 생각해야 한다. 작성되는 모든 코드들이 이 원칙들을 따를 수 있도록 노력해야 한다.

1 모든 테스트를 통과해야 한다.   

2 명료하고, 충분히 표현되고, 일관되어야 한다.   

3 동작이나 설정에 중복이 있어서는 안 된다.   

4 메서드, 클래스, 모듈의 수는 가능한 적어야 한다.

많은 사람들이 이 네 가지 원칙을 다른 방식으로 표현하고 있다. 나는 J.B. 레인스버거J. B. Rainsberger의 버전을 선호한다.     

1 모든 테스트의 통과   

2 중복의 최소화   

3 명료성의 최대화   

4 구성요소의 최소화

 

SOLID :: 컴퓨터 프로그래밍에서 SOLID란 로버트 마틴이 2000년대 초반에 명명한 객체 지향 프로그래밍 및 설계의 다섯 가지 기본 원칙을 마이클 페더스가 두문자어 기억술로 소개한 것이다. 프로그래머가 시간이 지나도 유지 보수와 확장이 쉬운 시스템을 만들고자 할 때 이 원칙들을 함께 적용할 수 있다. SOLID 원칙들은 소프트웨어 작업에서 프로그래머가 소스 코드가 읽기 쉽고 확장하기 쉽게 될 때까지 소프트웨어 소스 코드를 리팩터링하여 코드 냄새를 제거하기 위해 적용할 수 있는 지침이다. 이 원칙들은 애자일 소프트웨어 개발과 적응적 소프트웨어 개발의 전반적 전략의 일부다.
S SRP 단일 책임 원칙 (Single responsibility principle)한 클래스는 하나의 책임만 가져야 한다.
O OCP 개방-폐쇄 원칙 (Open/closed principle)“소프트웨어 요소는 확장에는 열려 있으나 변경에는 닫혀 있어야 한다.”
L LSP 리스코프 치환 원칙 (Liskov substitution principle)“프로그램의 객체는 프로그램의 정확성을 깨뜨리지 않으면서 하위 타입의 인스턴스로 바꿀 수 있어야 한다.” 계약에 의한 설계를 참고하라.
I ISP 인터페이스 분리 원칙 (Interface segregation principle)“특정 클라이언트를 위한 인터페이스 여러 개가 범용 인터페이스 하나보다 낫다.”
D DIP 의존관계 역전 원칙 (Dependency inversion principle)프로그래머는 “추상화에 의존해야지, 구체화에 의존하면 안된다.” 의존성 주입은 이 원칙을 따르는 방법 중 하나다.
[위키백과] SOLID (객체 지향 설계)

 

디자인 패턴

TDD에 능숙한 개발자는 개발 초기부터 디자인 패턴을 적용하는 일이 극히 드물다. 테스트 코드는 비즈니스 요구사항에 맞추는 것이지 디자인 패턴에 맞추는 것은 아니다. 코드는 테스트 통과에 꼭 필요한 만큼만 작성된다. 이러한 작업 방식은 구체적이고 특정적이면서도 매우 단순한 솔루션을 만들어낸다. 꼭 필요한 만큼의 코드만 작성되고 그 이상은 없다.

 

당장의 합당한 이유 없이 단지 ‘미래를 대비해야 한다’는 모호한 전제로, 초기부터 추상화를 하면 애플리케이션이 엉망이 된다. 미래에 어느 부분에서 수정이 필요할지 모르기 때문에 모든 부분에서 추상화(복잡도 증대)를 적용해버린다. 애플리케이션이 진화 및 변경할 수 있도록 모든 가능성에 대비하는 것을 똑똑한 대응이라고 생각할 수도 있다. 진실은, 반대로 매우 바보같은 짓이다.

초기부터 추상화를 도입해서 이득을 볼 수 있는 부분이 일부 있을 수 있다. 코드 베이스 전체적으로는 그 추상화때문에 불필요한 고통이 유발된다. 실용적인 접근 방법은 실제로 필요한 상황이 생겼을 때만 추상화를 도입하는 것이다. 그렇게 하면 전체적인 복잡도를 낮추는 데 도움이 된다. 당연하지만 복잡도가 낮은 시스템이 높은 시스템보다 유지보수 비용이 낮다.

디자인 패턴 자체가 나쁜 것은 아니다. 분명 우리가 활용해야 할 도구 중 하나다. 무조건 사용해야 할 도구는 아니다. 레이어를 추가하거나 추상화를 위해 코드를 리펙토링할 때 한걸음 더 나아가서 해당 문제에 흔하게 적용되는 패턴을 찾아서 적용할 수도 있다. 하지만 패턴이 먼저가 아니다. 내가 좋아하는 패턴에 문제를 끼워 맞추기 전에, 문제에 적합한 리펙토링을 단순한 설계와 SOLID 원칙을 따라서 먼저 시도해야 한다. 그 다음에 리펙토링으로 만들어진 솔루션이 특정 디자인 패턴과 거의 동일하다면 그 패턴을 지향하도록 리펙토링할 수도 있다. 범용 코드는 확장성이 더 좋을지는 몰라도 특정된 코드보다 더 복잡하다. 무조건적으로 범용 코드를 추구해서는 안 된다. 대신 주어진 문제에만 특정된 코드로 먼저 솔루션을 찾은 후 나중에 필요한 상황이 생겼을 때 범용화하는 것이 좋다.

 

장인정신과 실용주의

실용주의가 없는 장인정신은 장인정신이 아니다. 장인이 가장 중요하게 초점을 맞추는 것은 고객의 만족이다. 품질은 물론이고 시간과 비용도 고객 만족을 위한 구성요소다. 고객에게 가치를 전달할 수 없다면 잘 작성된 코드라고 할 수 없다.

 

요약

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

 

 

 

Chapter 16. 소프트웨어 장이능로서의 커리어

소프트웨어 개발자는 멋진 직업이다. 주변을 둘러보자. 오늘날 생산되는 거의 모든 것들이 소프트웨어의 뒷받침으로 가능하다. 심지어 당신이 앉아 있는 의자도 공장에서 생산될 때 소프트웨어를 이용한다. TV, 냉장고, 자동차같은 것들도 소프트웨어가 움직인다. 당신이 먹는 음식들도 소프트웨어와 연관이 있다. 식품/농산물 회사들도 수백 만 라인의 코드로 만들어진 소프트웨어가 없다면 그 많은 공급자들과 국가들에서 당신이 사는 동네의 슈퍼마켓 진열대까지 먹을거리를 올려놓을 수가 없다. 소프트웨어는 생명을 구하기도 한다. 의약 분야의 성과들 중 많은 부분이 소프트웨어로 인해서 가능했다. 교통, 통신, 엔터테인먼트, 스포츠 등 모든 분야의 배경에는 소프트웨어가 있다. 소프트웨어는 기업 및 자선재단들이 공익 사업을 성공에도 기여한다. 소프트웨어는 우리가 세상을 글로벌한 관점에서 볼 수 있도록 해준다. 정부의 정책 담당자들과 자원봉사자들이 도움이 필요한 사람들을 찾을 수 있도록 하거나 자연재해로부터의 피해를 최소화하는 데도 소프트웨어의 영향이 미친다. 소프트웨어는 불의를 막기도 하고 법이 집행될 수 있도록 한다. 물과 전기를 공급하고, 이런 저런 이유로 멀리 떨어진 가족과 친구들을 묶어 지구반대편의 사람들과 대화를 손쉽게 하도록 한다. 차가운 맥주를 마시거나 TV에서 수백 개의 채널을 볼 수 있는 것또한 소프트웨어 덕분이다. 어떻게 우리의 일을 자랑스럽게 생각하지 않을 수 있을까? 어떻게 우리의 일을 그저 출퇴근하는 생계수단으로만 치부할 수 있나? 이토록 중요한 일을, 어떤 때는 생명에 영향을 미치는 그런 일을, 어떻게 소중히 여기지 않을 수 있나? 소프트웨어 개발자들은 우리가 살고 있는 세상이 진화해 나가는 데 꼭 필요한 존재다.

 

장인의 길

열정. 이 단어 하나가 모든 것을 요약한다. 소프트웨어 장인은 소프트웨어 개발과 자신의 직무에 열정적이다. 문제를 단순한 방법으로 푸는 데 열정적이다. 배우고 가르치고 공유하는 데에도 열정적이다. 소프트웨어 산업이 진화하도록 돕는 데도 열정적이다. 그들의 코드를 공유하고, 초보 개발자들을 멘토링하고, 블로그/책/동영상/대화 등을 통해 그들의 경험을 공유하는 데도 열심이다. 기술 커뮤니티 활동에도 열정적이다. 뿐만 아니라 소프트웨어 장인은 겸손하다. 항상 더 나은 개발자에게 무언가를 배울 자세가 되어 있고, 경험이 적은 개발자들을 돕기를 주저하지 않는다.

 

단순히 좋은 코드를 작성하고 비즈니스 가치를 전달하는 것만으로는 좋은 개발자는 될 수 있지만 장인은 될 수 없다. 장인은 일종의 삶의 철학이다. 우리의 삶 전체에 걸쳐서 최선을 다해 역량을 마스터할 과업으로 소프트웨어 개발을 선택한 것이다. 항상 최고의 코드를 만들도록 다른 것들을 희생해서라도 계속해서 배우고 남을 도우리라는 각오를 하는 것이다. 소프트웨어 장인으로서의 삶은 아름다운 코드를 작성하기 위한 일생에 걸친 헌신과도 같다. 소프트웨어를 통해 가치를 창출할 수 있는 더 나은, 더 효과적인 방법을 찾는 끊임없는 노력의 길이다.

장인이 된다는 것은 새로운 것에 대해 호기심을 가지고 실험한다는 것과 같은 의미다. 장인은 특정 도구, 개발 언어, 프레임워크에 독단적인 고집을 부리지 않는다. 항상 주어진 문제에 가장 적합한 도구를 찾고 단순한 해결책을 추구한다. 특정 도구를 종교적으로 신봉하지는 않더라도 최선이라고 알려진 몇몇 조합들에 대해서는 완전하게 마스터하고 있어야 한다. 마스터한 도구들이 없다면 장인이라고 할 수 없다.

진정한 소프트웨어 장인은 가장 먼저, 코드 작성이 아니라 문제 해결에 집중한다. 코드를 짤 때는 높은 품질의 코드를 작성하는 데 집중한다. 테스트 가능하고 쉽게 이해할 수 있으며 수월하게 유지보수할 수 있는 코드를 작성하는 데 집중한다.

장인은 자신이 떠나고 난 후 스스로 부끄러운 일로 떠올리는 상황을 만들지 않는다. 엉망인 코드, 작성자 본인 외에는 아무도 이해할 수 없는 코드로 하여금 남아 있는 개발자들의 지탄을 받을 일을 만들지 않는다. 반대로 장인은 긍정적인 일들로 연상되는 존재여야 한다. 통찰력 있는 기여, 열정, 지식, 훌륭한 동료로서 인정받는다면 더할나위 없다.

 

정직과 용기

정직과 용기는 소프트웨어 장인이 갖추어야 할 핵심적인 자질이다. “글쎄요. 그건 누구든지 해당하는 거 아닌가요?“라고 말할 수도 있다. 맞다. 여기서 말하는 정직과 용기란 필요한 상황에서 고객에게 ‘아니오’라고 말할 수 있는 것을 의미한다. 고객이 비현실적인 요구를 할 때 고객과의 껄끄러운 상황이 발생할 것을 알면서도 그 요구가 제대로 반영되기 힘들다라고 전달하는 것이다. 즉 고객이 나쁜 의사결정을 할 때 그것이 적절치 못하다고 지적하는 정직함과 용기를 말한다. 장인은 스스로 판단하기에 무언가 올바르지 않은 결정을 그대로 추진하거나 책임지지는 않을 것이라는 점을 고객에게분명히 밝힌다.

그저 ‘아니오’라고 답하는 것만이 장인으로서의 태도는 아니다. 모든 ‘아니오’에는 항상 대안을 제시해야 한다.

 

장인의 커리어는 정직과 용기 위에 세워진다. 장인은 고객에게 무언가를 숨기지 않는다. 장인과 고객의 동반자 관계는 정직과 용기, 완전한 투명성에 의해서 이루어진다.

 

커리어의 진전

개발자들이 더 나은 코드를 작성할 수 있도록 돕는 것 외에 또 하나의 목표는 개발자들에게 열정을 불어 넣고 배움의 문화를 만들도록 하는 것이었다.

 

개발자들을 모아놓고 “당신의 커리어 목표는 무엇입니까? 몇 년 안에 어떤 위치에 있기를 바랍니까?”라고 물었다. 잠깐의 침묵이 흐르고 어느 개발자가 목소리를 냈다. “나는 관리자가 되고 싶습니다.” 또 다른 개발자들은 팀 리더, 부서장, 제품 오너같은 자리에 오르고 싶다고 했다. 계속해서 개발자이고 싶다라고 대답하는 사람은 없었다. 나는 “왜 개발자는 안 됩니까?”라고 반문했다. 다소 당혹스러운 침묵 뒤에 어느 개발자가 강한 어조로 대답했다. “서른이 넘어서도 아직 개발을 하고 있다면 낙오자로 취급받을 겁니다.” 어떤 개발자들은 고개를 숙였고, 동의의 표시로 고개를 끄덕이는 이도 있었다. 긴 침묵이 이어지고 누군가 큰 목소리로 이야기했다. “저는 서른 다섯입니다. 저는 낙오자인 것이 매우 자랑스럽습니다.”

그 다음날부터 상황이 바뀌었다. 개발자들은 더 행복하고 자유로워진 듯 했으며 그들의 일을 즐겼다. 페어 프로그래밍을 하고 테스트를 먼저 작성하기 위해 노력했다. 그들의 코드를 이해하기 쉽게 만들 방법들을 시도했다. 내부 학습 모임도 하면서 코드 작성 능력을 키우려고 공을 들였다. 그들은 자신이 사랑하는 일을 하면서도 성공적인 커리어를 가질 수 있다는 것을 알게 되었다.

 

오늘날 회사들은 사실상 소프트웨어 회사다. 그점을 이해하지 못하는 회사는 미래에 경쟁력을 가지는 데 어려움을 겪게 될 것이다. 개발자들을 고급 기술을 가진 프로페셔널로 인지하지 못하는 회사들은 그들을 위해 일할 장인을 구할 수 없을 것이다.

 

다른 커리어 사다리

관리자나 아키텍트가 되는 개발자는 소프트웨어 개발 직능의 사다리를 오른 것이 아니라 사다리 자체를 바꾼 것이다.

 

여정과 이정표

성공한 소프트웨어 장인은 스스로의 커리어를 매우 신중하게 계획한다. 무언가를 배우고 더 나은 프로페셔널이 되기 위한 기회들을 찾는다. 사람들은 서로 다른 열망들을 품고 있다. 그 열망들은 시간이 감에 따라 변한다. 다음 단계를 위해 앞서 보고, 계획하는 것은 성공적인 커리어를 위해 핵심적이다.

 

오래 지속되고 성공적인 커리에 관심을 기울이는 프로페셔널이라면 직장은 급여 이상의 의미가 있다. 직장은 그들의 커리어를 위한 지속적인 투자다.

급여를 대가로 해서 일을 하는 것 말고도 우리의 열정과 헌신 그리고 업무 외 개인 시간을 들여 확보한 지식들을 투자하여 일터를 더 나은 곳으로 만든다. 단순히 일을 하는 곳이 아니라 배우고 성장하는 장이 되게 한다. 일터를 더 나은 곳으로 만드는 데 투자한다는 의미는 우리의 커리어를 더욱 풍요롭게 할 수 있는 기회를 늘린다는 것과 같다.

나는 단순히 주어진 업무에만 집중한 적은 한번도 없다. 언제 어디서도 “그건 내 업무가 아닙니다.”라고 말한 적이 없다. 사실 나는 고용 계약서나 업무 목록을 되돌아 본 적도 없다. 나는 항상 더 많은 것을 제공하고 더 많은 일을 수행해서 내 주변의 모두가 더 나아지도록 노력했다. 내 역할과 직급이 무엇이든 상관없이 내가 할 수 있는 최선의 도움을 주려 노력했다. 이런 것들은 나의 투자라고 생각한다. 내 일을 위한 투자일 뿐만 아니라 개인의 커리어를 위한 투자이기도 하다. 모든 종류의 투자가 그러하듯이 나 역시 투자에 따른 이익을 바라고 있다. 기대하는 이익의 종류는 나의 개인적인 또는 업무적인 삶의 변화에 따라 매번 달라진다. 특정 기술이나 산업을 접하거나, 새로운 형태의 프로젝트를 경험하거나, 다른 스킬을 개발할 수 있는 기회를 얻거나, 다른 역할 또는 다른 형태의 책임을 수행하거나, 그리고 더 많이 금전적 이익이 생기거나 하는 것들이 기대하는 이익들의 종류다. 여기서 금전적인 이익은 우선순위에서 높지 않다. 훌륭한 소프트웨어 프로페셔널이라면 생활비가 부족해서 어려움을 겪고 있을 경우는 드물 것이다. 나는 어떤 회사에서 일하든, 내가 줄 수 있는 최대의 가치를 주기 위해 최선을 다했다(출퇴근 길에 회사 로고가 들어간 티셔츠를 입고 다니기도 했다). 그러한 노력들에 대한 보상을 받았다.

 

커리어 전반에 걸쳐, 항상 신중하게 다음 직장을 찾았다. 낚시하듯이 여러 회사에 맹목적으로 이력서를 보내는 일은 하지 않았다. 그 대신 집중했다. 내가 일하고 싶은 회사의 형태가 어떠해야 하는지 항상 생각했다. 현실에 부딪혀, 내가 아직 그런 일을 하기에는 부족하다는 이야기를 들었을 때에도 나는 시간을 두고 다시 준비하고 도전했다. 내가 겪어온 모든 업무들은 나의 커리어를 진전시키는 데 도움이 됐다. 각각의 업무들은 나의 커리어가 놓인 긴 사다리의 계단이었고 프로가 되기 위한 여정이었다.

 

커리어 만들어 나가기

나는 일을 선택하기 전에 아래와 같은 질문들을 스스로에게 던졌다.  

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

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

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

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

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

• 그러한 투자는 대략적으로 얼마 동안 지속되어야 하는가?

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

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

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

위의 질문들은 계약 형태와는 아무런 관련이 없다. 나는 대부분 정규직으로 고용되었었지만 계약직이나 컨설턴트라고 해서 위의 질문들이 달라질 것은 없다.

 

면접 과정은 회사의 입장만 있는 것이 아니다. 지원자 입장에서도 회사를 평가할 수 있는 기회다. 고용 관계를 맺기 전에, 그 기회를 최대한 이용하여 정보를 얻어야만 한다.

 

시간에 지나면서 나의 커리어 열망이 바뀌었다. 개인적인 삶도 바뀌었다. 일부는 회사가 바뀌기도 했다. 무엇이든 변한다. 무엇인가가 바뀌면 나는 회사에 이야기를 했고 회사는 회사가 할 수 있는 범위 안에서 내가 원하는 것들을 최대한 주려 했다. 프로젝트나 부서를 바꾸어 주거나 새로운 것을 할 수 있게 해주거나 내게 더 많은 권한을 주었고, 어떤 회사들은 급여 인상이나 승진을 시키기도 했다. 그럼에도 불구하고 내가 찾고 있는 것을 줄 수 없을 때가 있다. 반대로 내가 커리어에 대해 고민하는 와중에 내가 회사에 더 기여할 무언가가 없을 때도 있다. 내가 무언가 매우 큰 변화를 원할 수도 있다. 컨설팅 회사에서 일하고 싶다거나, 창업을 하고 싶다거나, 세계 여러 곳에 분산된 팀들이 있는 글로벌 회사에서 일하고 싶다거나, 외국에 살고 싶다거나, 개발팀을 넘어서서 더 큰 변화를 만들어 낼 수 있는 위치에 서고 싶다거나 할 수 있다.

 

회사도 항상 내가 원하는 것을 줄 수 있는 것은 아니었다. 한두 가지 예외를 제외하고는 모두 훌륭한 회사였다. 하지만 어떤 시점에서는 서로 다른 길을 갈 수밖에 없다.

나의 커리어를 돌아 보면 길고, 거칠고, 굽이 많은 여정이었다. 그 여정의 끝에는 약속의 땅, 통달의 경지가 있다. 이 여정에는 장애물도 있고 숨어 있는 위험도 있고 혼란스런 이정표도 있고, 완전히 다른 길로 이끄는 갈림길들도 있다. 언제 어디서 잘못된 길을 들게 될지 알기가 매우 힘들 때도 있다. 한쪽 길로만 너무 오래 간다면 다른 길로 되돌아가기가 불가능하거나 상당히 어려울 수도 있다. 날씨가 나빠서 멀리 볼 수 없을지도 모른다.

소프트웨어 개발을 업으로 삼은 지 몇 년이 지났을 즈음, 나는 내가 일을 대단히 잘 한다고 생각했다. 마스터의 경지에 거의 다다른 줄 알았다. 개발자들을 만나면 만날수록, 익숙한 공간을 벗어나 바깥 세상을 경험할수록 나는 아직 한참 멀었다는 것을 깨달았다. 독일의 아우토반 고속도로를 달리고 있는 줄 알았지만 현실은 브라질 시골의 비포장 도로 위였다. 나는 통달의 단계에서 아직 한참이나 떨어져 있었고 그 너머로 무엇이 있는지조차 볼 수 없었다. 꽤 실망하여 그 충격에서 벗어나기까지 상당한 시간이 걸렸다. 내가 무언가 행동을 해야 할 때라고 깨달은 시기였다. 감고 있던 눈을 크게 뜨고 무언가를 배우고 발전할 수 있는 기회를 찾아야만 했다.

거쳐 간 회사들, 수행한 프로젝트들 하나하나가 마일스톤이었고 사다리의 한걸음이었다. 일들 하나하나가 여정에서 우리가 더 멀리 나아갈 수 있게 해준다. 일을 선택하는 것은 매우 신중해야 한다. 재직하는 기간은 회사마다 매우 크게 다를 수 있다. 몇 달 혹은 몇 년이 될 수도 있다. 나는 개인의 커리어 열망과 방향이 합치하는 한 그 회사에 가능한 오랫동안 머무르길 권한다. 회사에서 하는 일이 당신이 가진 커리어 열망과 방향에서 틀어진다면 회사와의 동반자 관계가 약해지고 서로로부터 얻을 수 있는 이익이 적어진다.

앞으로 나아가지 못하고 정체되어 있다고 느낀다면, 무언가를 배우거나 스스로 일을 즐기지 못한다면, 그때는 움직여야만 한다. 회사와 동료들을 사랑한다는 것만으로는 그 일을 계속해야 하는 충분한 이유가 되지 못한다. 사람들도 움직이고 회사도 움직인다. 우리도 움직여야 한다. 원하는 커리어 방향에 더 적합한 길을 찾아나서는 것은 자신은 물론 회사에도 도움이 된다. 회사 입장에서는 불행한 직원이 줄어서 좋을 뿐만 아니라, 새로운 사람을 들일 기회가 된다. 새로운 사람은 새로운 아이디어와 더 많은 에너지로 정체된 상황에 도전하고 훌륭한 일을 해낼 수도 있다. 경험으로 볼 때, 매년 15%에서 30%정도씩 구성원이 바뀌는 것은 회사에 매우 득이되는 일이라고 생각한다. 새로운 사람들은 회사를 최신의 정보에 밝아지게 하고 경쟁력 유지와 분위기 쇄신에 도움이 된다.

 

원하는 바를 모른다면 어떻게 해야 할까

언뜻 생각하기에는 바보 같은 질문같지만, 사실 누구에게나 일어나는 일이다. 내가 무엇을 원하는지, 어디로 가기를 원하는지, 다음에 무엇을 했으면 하는지 항상 알고 있을 수는 없다. 어떤 때는 길을 잃고 그저 혼란스럽기만 할 수도 있다. 그 사실을 인정하는 데는 상당한 용기가 필요하다. 하지만 한번 인정하고 나면 모든 것이 더 나아진다. 내가 원하는 것을 나도 모른다는 것을 인정하고 나면 나의 길을 찾는 데 좀더 객관적으로 집중할 수 있다.

 

껍질을 벗고 뛰쳐 나와 할 수 있는 한 최대한 많은 문들을 열어 보아야 한다.

 

다양성

그것이 유일한 방법이라는 것은 아니다. 하지만 분명 매우 좋은 방법이다.

 

여러 종류의 프로젝트에서 일해보는 것은 미래의 장인을 준비시키는 것과도 같다.

 

소프트웨어 장인의 사명

소프트웨어 장인은 자신만의 사명이 있다. 더 나아지는 데 집중하고, 계속해서 자신의 커리어에 투자하며, 배우고, 가르치고, 공유한다. 그가 맡은 고객에게 항상 가치를 전달할 수 있도록 해야 한다. 이러한 사명은 고객만을 위한 것은 아니다. 고객을 위한 가치 창출은 사명의 일부일 뿐이다. 소프트웨어 장인의 진정한 사명은 프로페셔널리즘, 열정, 관심으로 소프트웨어 산업의 수준을 높이는 것이다. 소프트웨어 장인은 그냥 일을 하기 위해 고용된 평범한 개발자가 아니다. 장인은 다른 개발자들이 더 나은 코드를 만들고 스스로가 하는 일에 자부심을 갖도록 돕는 데 관심을 둔다. 최종적인 목표는 전 세계적으로 소프트웨어 프로젝트들의 품질과 성공 비율을 오늘날보다 높아지도록 하는 것이다.

 

소프트웨어 장인은 주변의 것들을 더 나아지게 하고 우리가 사는 세상을 변화시킬 것을 생각한다. 소프트웨어 장인이 된다는 것은 잘 짜여진 코드를 만드는 소프트웨어 개발자가 되는 것에서 훨씬 더 나아간다. 그것은 삶의 철학이다. 탁월함에 헌신하고, 탁월함의 추구를 본성처럼 만든다. 우리 사회의 진화를 이끄는 일에 무한한 자부심을 갖는다.

 

 

 

Appendix

보통의 개발자와 장인의 차이점은 스스로의 직업을 대하는 태도에 있다. 누그든 자기 자신을 장인이라고 부를 수는 있지만 그것만으로 장인이 되었다고 할 수는 없다. 특정한 가치를 말하는 것과 그것을 항상 실천하는 것은 완전히 별개의 이슈다. 추구하는 가치는 말이 아니라 행동에 의해 규정된다.

 

누군가가 스스로를 장인이라고 부른다면 그가 추구하는 가치와 프로페셔널한 태도를 지칭하는 것이지 능력을 지칭하는 것이 아니다. 반대로 누군가가 스스로를 장인이라 하지 않는다고 해서 그가 장인이 추구하는 가치와 태도를 가지지 않았다는 의미도 아니다.