죽을 때까지 코딩하며 사는 법

많은 대가들의 이야기를 모아 읽기 좋게 정리한 거 하나만으로도 가치가 충분한 좋은 책

개인적으로 시간을 낼 수도 없고, 회사도 기회를 제공하지 않은 상태로 시간만 보내게 되는 겁니다.

(지금 이 문제로 내가 싸우고 있어서 정말 와닿는다)

소프트웨어 개발 프로젝트의 복잡도는 크게 두 가지 변수의 영향을 받습니다. 그것은 바로 ‘사용자 요구사항’과 ‘개발기술’인데요.

먼저 ‘사용자 요구사항’ 의 경우를 보죠.

폭포수개발방식은 프로젝트 초기에 요구사항을 고정시킵니다. 사용자와 철저한 인터뷰를 하고 문서를 만들며, 여기에 확인 서명을 받기도 하죠. 이에 반해, 애자일 방식은 요구사항의 변화를 그대로 수용합니다. 다만 반복적인 프로세스를 돌려서, 각 프로세스(이터레이션 또는 스프린트) 안에서는 요구사항이 변하지 않도록 보호하는 조치를 합니다.

그럼 기술의 변화는 어떻게 수용할까요? 프로젝트 초반에 개발 기술을 검토하여 고정시킵니다. RUP/UP 같은 방식에서는 도입(Inception) 단계에서 인프라 환경을 조성하게 되는데요. 이때 개발기술을 검토할 수 있습니다. 애자일 개발 방식에서는 첫 번째 이터레이션 (스프린트) 에서 개발환경 세팅 및 개발기술 검토에 대한 작업을 따로 둘 수 있습니다.

그러나, 이런 건 어디까지나 책에 있는 내용입니다… 다시 말해서 요구사항을 통제할 방법이 없다는 건데요. 그렇기 때문에, 요구사항의 변화는 아무런 제재없이 프로젝트에 영향을 미칩니다. 요구사항이 지속적으로 변하므로 프로젝트는 어느 정도의 복잡도를 내재한 상태로 진행하게 됩니다. 그러니, 개발기술이 변화하면, 프로젝트의 복잡도는 바로 ‘혼돈’ 상태로 진입하게 되겠죠. 그래서, 경험있는 관리자들은 개발자들의 기술변화에 대한 열망을 억제하려고 노력하게 됩니다.

근본적인 문제는 요구사항을 관리하지 않음에 있지만, 새로운 기술을 도입하고, 학습을 일으켜서 열정을 유지하고자 하는 개발자의 본능이 프로젝트를 망치는 원인이 된 것이죠. 그 결과, 프로젝트에서 학습 기회가 줄어들고, 개발자의 열정은 점점 식어갑니다.

하지만, 소프트웨어 개발 분야는 그렇지 않습니다. 소프트웨어 공학이라는 학문 자체가 60여 년밖에 안 되었고 그동안 수없이 많은 진화가 이루어졌습니다. 개발 방법론이나 패러다임에 대한 이해가 아닌 이상 시니어 개발자가 주니어 개발자에게 전달해주는 정보가 다른 분야의 그것과는 질적인 차이가 있을 수밖에 없습니다.

(비개발자들에게 개발에 대해 이야기할 때 꼭 필요한 이야기를 잘 설명했다)

개발자가 일하는 환경 자체가 바뀌는 변화가 일어나야 가능합니다.

하지만, 기술과 패러다임이 변화해도, 사람은 변하지 않습니다.

기존 관리자들이 은퇴하고 새로운 세대가 그 자리를 물려받을만큼 긴 시간인 30년이 흐른 뒤에야 비로소 공장의 배치가 바뀌었다.

에릭 블린욜프슨, 앤드루 맥아피, 제2의 기계시대, 134쪽

(그래서 나도 고민중. 과연 사람이 바뀌기를 기대하면서 참아야 하는가)

직원에게 자율성을 부여하는 쪽이 그렇지 않은 쪽보다 더 효율성이 높다는 연구 결과입니다… 제임스 서로위키는 <대중의 지혜>에서 ‘권한을 가진 느낌을 갖는 것만으로도 ‘퍼즐을 푸는 속도가 5배 증가’하는 결과를 낳았다고 소개하고 있습니다. 사람들이 근무 조건을 스스로 결정할 수 있기만 해도, 성과에 실질적 차이가 생기는 겁니다.

대부분의 회사는 직원들을 ‘통제’하고 자율성을 ‘배제’하는 쪽으로 운영방침을 만들어 갑니다. 정반대로 가고 있는 거죠. 따라서, 회사가 이윤 추구에 방해되는 쪽으로 정책을 만들어가는 원인에는 합리적인 경영진의 판단을 마비시키는 뭔가 중대한 영향력이 있다고 봐야 할 것입니다.

‘프로세스’ 라는 개념조차 희박했던 시대에 나온 이론이기 때문에 이 이론을 적용한 회사는 업무 효율이 크게 늘어났고, 테일러주의는 현대 경영학과 산업공학 등의 분야의 배경이 되었습니다. 따라서, 테일러주의의 영향력이 현재까지 이르게 되었는데요. 다니엘 핑크는 그 영향력을 유령’ 이라고 표현하고 있습니다.

다니엘 핑크가 테일러를 ‘유령’ 이라고 표현한 이유는 테일러주의가 제공하는 동기부여 방식이 잘못되었다고 보기 때문인데요. 다니엘 핑크는 테일러의 동기부여 방식을 ‘당근과 채찍’이라고 했습니다. 일을 열심히 하면 인센티브를 주고 그렇지 않으면 벌을 줬기 때문이죠.

테일러가 생각했던 노동자는 무감각한 사람입니다. 누군가의 제어가 필요한 동물이었습니다. 1907년 테일러는 “생각은 근로자들의 몫이 아니다” 라고 말하기도 했다는군요. 자신을 동물로 취급하는 사람을 신뢰하는 사람은 없을 겁니다. 근본적으로 테일러주의는 노동쟁의를 유발할 수밖에 없습니다. 이런 조직은 신뢰를 바탕으로 운영되지 않습니다. 오로지 당근과 채찍으로 운영되죠. 목표를 정해놓고 달성하면 당근을, 그렇지 못하면 채찍을 대는 겁니다.

테일러주의는 변화에 취약합니다. 업무에 대한 ‘연구’는 상당히 오랜 시간 공들여서 해야 하는 일인데요. 이 방식으로 체계를 만들면 시장의 변화에 따라서 제품을 변화시키는 데 애를 먹게 됩니다.

의사결정 과정도 복잡해집니다. 테일러주의는 조직구조를 피라미드식으로 만들어 놓는데요. 결정의 중요도에 따라서 더 높이 올라가서 의사결정을 해야 할 겁니다. 만약 복잡한 사항이라면 회의를 많이 하고 결론을 맺겠죠.

(내가 지적했던 그 부분을 이렇게 책에서 설명하는 걸 보니 나의 지적이 정확했다는 만족과 함께, 과연 해결이 될까?하는 불안감이 엄습한다)

테일러주의 조직은 이걸 장려합니다. 다른 사람을 부품으로 이용하고 ‘통제’하는 것을 장려한다는 거죠.

<사회지능>에서 소개하고 있는 ‘어둠의 인간 유형’은 총 세 가지입니다. 나르시스형, 마키아벨리형, 그리고 사이코패스형인데요. 아마 이 책이 근래에 나왔다면 ‘소시오패스’도 포함시켰을 거라 추측해봅니다.

썩은 사과는 무례한 행동이나 말을 하는 사람입니다…여기에 대항할 수 있는 힘이 없을 때, 우리가 취하게 되는 행동은 그를 피하는 겁니다. 그러나 그가 팀장이라면, 그가 원하는 일만은 제대로 해줘야겠죠. 왜냐하면, 인격적 모욕을 당하기는 싫거든요. 그러니 ‘통제’가 잘 되는 팀이 되는 겁니다.

각 패러다임은 프로그래머에게서 권한을 박탈한다. 로버트 C 마틴, 클린 아키텍처, 27쪽

나는 매일 품새를 한두 개씩 푼다. 보통 업무를 시작하기 전에 푸는 일이 많다. (중략) 품새를 아침에는 준비운동 10분으로, 저녁에는 마무리 운동 10분으로 생각하자. 로버트 C 마틴, <클린 코더>, 59쪽

하루를 연습하지 않으면 내가 알고, 이들을 연습하지 않으면 평론가들이 알지, 사흘을 연습하지 않으면 관객들까지 알게 돼. — 파데레프스키(폴란드의 피아니스트, 작곡가, 총리) — 이재규, <무엇이 당신을 만드는가>, 61 쪽

(습관의 중요성. 하기도 어렵고 지속하기는 더 어렵다)

복잡한 현실을 지나치게 단순화시켜 받아들이기 편한 이야기로 바꾸어버리는 인간의 생물학적 성향 브래드 스톤, <아마존, 세상의 모든 것을 팝니다〉, 20쪽

논리의 전체적인 흐름은 유지될지 모르지만, 사실을 지나치게 단순화시키기 때문에 세세한 부분은 오류를 만들기 쉽고, 결과가 나올 때까지 논리를 추가 확장해 나가기 때문에 결과물은 정리를 할 수 없이 꼬이게 되는 거죠… 다시 말해, 중간 모듈들의 상태는 고려하지 않고 목표하는 동작이 있는지만 돌려보는 거죠.

외과 의사가 꼭 손을 씻어야 하듯이 프로그래머도 TDD 를 꼭 적용해야 한다고 생각한다. 로버트 C 마틴, <클린 코더>, 129쪽

외과 의사가 손을 씻지 않으면, 환자는 죽습니다. 마찬가지로 TDD를 쓰지 않으면 프로젝트는 실패하게 됩니다. 이게 로버트 C 마틴의 주장이죠. TDD는 ‘테스트 주도 개발’을 말합니다. 유닛 테스트(즉 가장 기본 단위 함수나 클래스를 테스트하는 코드)를 먼저 넣고 그다음 실제 구현 코드를 넣는 식으로 작업하는 개발 방식을 말하는데요.

로버트 C 마틴은 TDD를 원초적인 안전장치로 여기고 있습니다. 이는 ‘순차적 논리 전개의 문제점’ 이라는 화두를 놓고 볼 때 아주 정확한 지적입니다. 함수를 만들 때마다 테스트를 만들어야 하므로 TDD를 사용하면 순차적인 논리 전개 방식을 쓰기 힘들어집니다. 그러면 문제를 만들어내는 근본적인 고리가 끊어집니다. ‘이야기 짓기 오류’가 만들어내는 문제점, 다시 말해서 상황을 단순화시키는 버릇도 극복할 수 있습니다.

테스트 루틴이 없는 코드는 나쁜 코드다. 코드가 얼마나 훌륭하게 작성돼 있는지 여부와는 상관없다. 아무리 깔끔하고 객체지향적이며 캡슐화가 잘돼 있어도 소용없다. 테스트 루틴이 있으면 코드의 동작을 빠르게 검증하며 수정할 수 있다. 테스트 루틴이 없으면 우리가 작성하고 있는 코드가 좋아지고 있는지 나빠지고 있는지 제대로 알 수 없다. 마이클 C 페더스, <레거시 코드 활용 전략〉, 12쪽

설계자들은 대부분 우뇌형이고 시공 감각을 지향하는 사람들이다. 프레더릭 브룩스, <디자인 오브 디자인>, 39쪽

여기서 설계자들을 우뇌형이라고 이야기합니다. 우리가 소프트웨어를 개발할 때 코딩만 있는 건 아닙니다. 전체적인 그림을 만들어 내는 식견도 필요하죠. 그걸 할 때는 우뇌형 개발자가 유리하다고 볼 수있겠군요.

조합보다 상속을 많이 쓴다면, 클래스지향일 가망성이 높습니다. 객체지향의 선구자로 알려진 엘런 케이는 “객체란 서로 메시지를 주고 받는 생물학적 세포와 비슷해야 한다” 라고 말했거든요. 객체는 상속이 아니라 조합에 의해서 그리고 메시지에 의해서 사용되어야 합니다. 물론, 상속의 대상도 언제나 인터페이스 또는 추상 클래스이어야 합니다.

어떤 프로그래밍 언어를 사용하든, 변수는 최소화해야 합니다. 우리가 함수를 수학적 모델로 사용하는 건 꼭 함수형 언어가 아니라도 가능하거든요. 그럼 변수 사용이 자연스럽게 줄어들게 됩니다.

코드가 길어져서 화면을 넘어간다면 순차적 논리에 잠식되고 있는건 아닌지 스스로 의심해봐야 합니다. 들여쓰기가 너무 많은 것도, 함수 파라미터가 너무 많은 것도, 판단문이 너무 많은 것도, 역시 순차적 논리 전개의 결과일 가망성이 높습니다.

코드는 세 가지 기능이 있다고 하는데요. 첫째는 구현한 목적에 맞게 실행 가능해야 하고, 둘째는 유지보수가 가능해야 하고, 셋째는 코드를 읽는 사람이 코드를 작성한 사람이 뭘 하려고 했는지 이해하도록 해줘야 합니다. 그래서, 코드가 사용자 요구사항이라는 지식을 전달하는 문서의 역할을 해야 하거든요.

새로운 네트워크에 가입하는 건(이직하는 건), 결국 새로운 환경에 적응해야 한다는 거죠. 모든 네트워크는 고유의 특성이 있습니다. 네트워크만의 생리가 있고, 문화가 있는데요. 따라서 새로운 네트워크에 가입해야 한다면, 우리는 여기에 적응해야만 합니다. 이때 발생하는 학습효과가 또 상당하다는 것을 알 수 있습니다… 익숙한 영역을 벗어나 낯선 것을 익혀라.

인류가 깊은 생각을 하기 시작한 건, 띄어쓰기’가 생기고 나서랍니다… 따라서 독서는 우리의 생각을 깊게 하게 해주는 훈련도구입니다.

(띄어쓰기에 대해 깊이 아는 건 아니지만, 이건 너무 큰 비약 아닌가? 더구나 동양 문화권에 띄어쓰기가 들어온 건 굉장히 후대의 일이고, 한자는 아직도 띄어쓰기가 없는데 한자 문화권의 과거를 전부 부정하지 않고서는 이런 이야기를 할 수는 없다고 본다)

전문적인 지식 노동자로서 발언한 것이고 전문적인 지식 노동자라면 자기 두뇌의 정신 에너지를 아껴 쓰는 방법을 알고 있어야 한다는 겁니다. 심지어 옷도 고르지 않을 정도로요.

프로그래밍은 지적인 행위로 긴 시간 정신을 모아 집중해야 한다. 집중력은 소중한 자원으로 마나와 비슷하다. 집중력 마나를 다 쓰고 나면 몇 시간 정도 집중이 필요 없는 행동으로 마나를 충전해야 한다. 또한 집중력 마나는 차츰 사라지는 자원이다. 있을 때 사용하지 않으면 사라진다. 이게 바로 회의가 사람을 황폐하게 만드는 이유다. 회의에서 집중력 마나를 다 써버리면 코딩에 쓸 마나가 남아나지 않는다. 근심이나 주의 산만 또한 집중력 마나를 소비한다. 지난밤 배우자와 했던 싸움, 아침에 자동차에 생긴 흠집, 지난주에 깜빡하고 처리하지 않는 고지서 같은 일들이 집중력 마나를 순식간에 빨아들인다. (중략) 수면은 아무리 강조해도 지나치지 않다. 하룻밤 잘 자고 나면 집중력 마나가 가득 찬다. 7 시간 자면 8시간 분량의 집중력 마나가 찬다. 로버트 C 마틴, <클린 코더>, 186쪽

집중력도 훈련으로 향상시킬 수 있다… 우리의 집중을 방해하는 것은 스트레스, 인터럽트 같은 것이 있습니다. 스트레스는 마나를 빨리 소진시키기 때문에 집중력 있는 일을 하기 어렵게 만들고요. 인터럽트는 집중하는 걸 방해하기 때문에 인터럽트가 없도록 환경을 잘 구축해야 합니다.

조직문화

<대중의 지혜>의 제임스 서로위키도 역시, “상명하달식 조직이 억압적이며 좋지 않은 결과를 낳는다”라고 했습니다. 또한, 이런 조직문화에서는 “똑똑한 개인도 무능해진다”라고 하는데요.

…비현실적인 예산과 일정에 맞추도록 강압되는 상황에서 기술적 전문성을 가졌으나 힘없는 사람들의 목소리는 완전히 밟혀버렸습니다. 사고 조사 위원회는 조직 체계가 바뀌지 않는 이상 비슷한 사고가 또 생길 수밖에 없다고 결론 지었습니다. 품질 석학 에드워드 데밍은 직원들이 문제가 아니라 그 사람들이 속한 시스템, 그리고 그걸 만들고 책임지는 경영진이 문제라고 했습니다.

결국 환경이 문제이고, 환경을 그렇게 만든 경영진의 문제라는 겁니다.

또한, 조직문화에서 사람의 존재는 큰 비중을 차지합니다.

(중략) 알버트 아인슈타인이 책상에 앉아 턱을 괴고 사색에 잠겨있는 상황을 상상해보자. 그의 매니저가 ‘알버트! 상대성 이론이 지금 당장 필요하니까 빨리빨리 서둘러! 가만히 앉아 만 있지 말고 말이야! (쾅쾅!)”하고 다그치고 있다. 더 이상 무슨 말이 필요하겠는가? 아마도 대부분의 소프트웨어 개발자는 아인슈타인처럼 똑똑하지는 않으리라. 그렇다면 아인슈타인보다는 더 나은 개발 환경이 필요하지 않을까?

스티브 맥코넬, <소프트웨어 프로젝트 생존 전략>, 79쪽

최인철 교수님은 <프레임>이라는 저서에서 “누군가에게는 내가 바로 프레임이 된다는 사실을 직시해야 한다”라고 이야기했습니다.

테일러주의 조직이라면, 상명하복, 침묵강요가 만연하게 되다가 똑똑한 사람들의 목소리가 묻히고 참사가 발생하는 상황에 이르게 될 겁니다.

마리사 메이어는 세간의 기대와는 전혀 다른 행보를 보입니다. 특히, 재택근무 전면 폐지’, ‘텀블러 매각’ 같은 정책 판단은 많은 사람의 고개를 갸우뚱하게 만들었고요. 결국 2017년 야후의 인터넷 사업부를 매각시키고 퇴직하는 CEO가 되었습니다. 사실상 야후몰락의 종지부를 찍었던 겁니다.

구글 성공의 한 축을 담당했던 마리사 메이어입니다. 그런데 어떻게 거대한 실수를 남발하며 야후의 종지부를 찍는 CEO가 되었을까요? 이런 문제의 원인을 마리사 메이어 개인에게서 찾는 건, 합리적이지 않습니다(사람은 어느 순간 이렇게 갑자기 많이 바뀌지 않거든요). 마리사메이어가 일했던 환경을 봐야 맞을 겁니다.

샘 라이트 스톤이 쓴 <프로그래머로 사는 법>이라는 책에서, 마리사 메이어가 뛰어난 능력을 발휘했을 때의 환경을 엿볼 수 있습니다. <프로그래머로 사는 법>은 IT업계 유명인들을 찾아가서 인터뷰한 것을 엮은 책인데요. 인터뷰 대상에 마리사 메이어도 있기 때문입니다. 성장 방법에 대한 질문에 마리사 메이어는 본인이 성장한 환경을 이야기합니다(책 본문을 요약했습니다).

• 사고의 자유를 만끽하고 자기 의견과 생각을 자유롭게 공유할 수 있는 곳에 있기

• 자신에게 투자해주고 도전거리를 주는 사람과 있기

• 똑똑한 사람과 일할 수 있는 곳에 있기

• 아직 준비되지 않은 일을 할 수 있는 곳에 있기

마리사 메이어가 성장하고 성과를 보여줬던 환경이 대략 어떤 분위기였는지 짐작할 수 있습니다. 몰락해 가는 야후의 CEO로서는 이런 환경을 누리지는 못했겠죠. 하는 일에 자유도가 있을 리도 없고, 마리사 메이어에게 투자하는 사람도 없었고, 주변에 모든 사람은 마리사 메이어만 보고 있는 상황이었을 테니, 본인이 이미 가진 능력조차도 발휘할 수 없었겠군요.

‘평범한 사람이 비범한 일을 할 수 있도록 만드는 것’이 곧 조직의 목적이다. (중략) 조직은 천재에게 의존할 수가 없다. 이 세상에 천재의 공급은 늘 부족하고 또 언제 공급될는지 전혀 예측할 수도 없다. 그러나 평범한 사람들로 하여금 그들 자신의 능력 이상으로 일을 하도록 하고, 구성원들이 가진 역량이면 그 무엇이라도 이끌어내고는 구성원들 모두가 그것을 이용하여 보다 많은, 그리고 보다 더 큰 성과를 이룩하고 있는가 하는 것은 조직을 평가하는 기준이다. 조직이 그 구성원들이 가진 약점을 무력화시키는가 하는 여부 역시 조직을 평가하는 기준이 된다.

피터 드러커, <경영의 실제, 13장 조직 정신(조직문화)〉, 217쪽

그럼, 구성원들이 천재성을 보이게 만드는 방법은 뭘까요?

피터 드러커가 제시하는 방법은 간단합니다. “중요한 것은 당신이 갖고 있는 능력이지, 당신이 갖고 있지 않는 능력이 아니다.”

구성원들이 가진 능력에 주목하고, 그 능력을 최대한 발휘하게 하면 되겠군요. 여기서, 마리사 메이어의 이야기를 다시 상기해 보죠. 자유를 주고, 멘토와 본받을 사람을 주고, 책임을 주는 것, 바로 그 사람이 가진 능력을 최대한 발휘하게 하는 방법이 아닐까요.

마리사 메이어가 한 말을 상기해볼까요? ‘자유를 주고, 멘토와 함께 일하도록 하고, 책임을 주는 회사에 있다면, 우리는 회사가 우리에게 기대하고 있다고 느낄 수 있겠죠. 조직문화 속에서 ‘기대감’이 흐르고 있다면, 어떻게 될까요? 서로를 존중하고 서로에게 기대하는 과정에서 모두의 IQ가 상승하는 분위기가 되겠죠.

마리사 메이어의 성공 조건 두 번째입니다. 마리사 메이어의 멘토들은 어떤 멘토링을 했을까요?

‘몰입’하게 해 줬네요. 멘토가 멘티에게 도전거리를 주고 학습하도록 유도하는 건, 결국 몰입 상태에 머물게 해주는 건데요. 마리사 메이어의 멘토들은 이걸 아주 잘했던 것 같습니다.

‘조언’도 했군요. 마리사 메이어는 ‘강력한 조언자’라고 표현하고 있는데요. 아마도 인생을 바꾸어 놓을 만한 조언이 있었던 것 같습니다. 막히는 게 있을 때, 그걸 풀어주는 사람이 옆에 있다는 건 엄청난 행운입니다. 혼자 있어도 풀 수 있을지 모르지만, 그러려면 상당히 오랜 시간 노력해야 하거든요. 경험해보지 않아도 되는 것에 대해 시간을 낭비하는 것보다, 멘토의 목소리를 듣는 게 더 빠른 성장을 가져올 수 있겠죠.

그다음 ‘책임’을 부여해줬습니다. 조직 내에서 적절한 책임을 갖고 일할 수 있는 건 빠르게 성장할 수 있는 기회입니다. 책임과 권한은 그걸 가진 사람의 능력을 배가 시키거든요.

다마고야는 직원의 잠재력을 최대한 끌어올리기 위해 현장에 적극적으로 권한을 위임해 왔다. 스가하라 유히치로, <사업을 키운다는 것>. 87쪽

유명한 물리학자인 로버트 오펜하이머의 동생인 프랭크 오펜하이머는 “무언가를 배우는 가장 좋은 방법은 그것을 가르치는 것이다” 라고 말했다.

라즐로 복, <구글의 아침은 자유가 시작된다>, 348쪽

… 이런 조직은 자연스럽게 정보가 공유되고 서로에게 멘토가 되어줍니다. 성장할 수 있는 환경이 조성되어 있어서 여기에 속한 구성원은 빠른 성장을 보일 겁니다.

테일러주의였고요. 피라미드 조직구조였습니다. 모든 정보는 피라미드 꼭대기에서 관리되고, 일부 정보만 흘러 내려오는 구조입니다

<대중의지혜>라는 제목의 책에서 제임스 서로위키는 또 다른 이야기도 들려주는데요. 1986년 1월 28일에 발생한 우주왕복선 챌린저호의 폭발 사고에 대한 이야기입니다. 사고 직후 30분 만에 이 우주왕복선에 0링이라는 부품을 제공하던 회사의 주식이 폭락하기 시작했습니다. 즉, 주식시장의 대중이 우주왕복선 폭발 사고의 원인을 O링이라는 부품이라고 판단했다는 말인데요. 이는 그 후 몇 개월 동안 이루어진 조사로 사실임이 밝혀졌습니다.

서로위키는 대중의 지혜’를 갖추게 해주는 요소를 다음 네 가지로 규정하고 있습니다.

• 의견의 다양성 : 다양한 개개인 만의 정보를 가질 것
• 독립성 : 각자 독립적으로 의견을 가질 것
• 분권화 : 개개인의 개별적 지식에 의존할 것
• 통합의 메커니즘 : 각자의 의견을 집단 결정으로 전환시키는 구조를 가질 것

(소 몸무게에 대한 이야기는 워낙 유명해서 예전부터 알고 있었지만 챌린저호 O링 이야기는 처음 알았다)

양치기 소년은 ‘그 기능은 이틀이면 충분히 짭니다’라고 말한다. 프로젝트 전에 예측하는 개발 비용과 일정은 농담에 불과하다. 이런 헛소리를 진심으로 믿는 사람은 바보 아니면 풋내기 관리자다. (중략) 진실을 말하자면, 10줄짜리 코드를 짜거나 옛날 코드를 그대로 복사하는 경우가 아니라면 프로젝트가 실제로 얼마나 걸릴지 예측하는 일은 불가능하다. 에릭 브리히너, <HARD CODE>, 35쪽

(그럼에도 불구하고 예측이 필요하다는 현실)

그럼 왜 MBO 를 하지 말라고 했을까요? “변화가 없다”, “성과를 단순하게 정의할 수 있다”는 두 가지 가정을 기틀로 MBO가 만들어졌기 때문이라는군요.

(그러나 사실 OKR을 MBO에서 왔다는 게 아이러니)

2007년 <비즈니스 위크>는 3M에서의 식스시그마 흥망을 다뤘다. 3M은 2000년에 식스시그마를 도입하면서 GE에서 잭 웰치의 부관이었던 사람 중 하나를 CEO로 고용했다. 4년 후 3M이 새 CEO를 임명할 때 3M은 식스시그마에 대한 지원 수준을 낮췄다. 3M은 식스시그마 체제 아래서 창의성이 줄어드는 것을 경험했던 것이다.

게리 클라인, <통찰, 평범에서 비범으로>, 345쪽

대규모 조직들은 식스시그마와 종합적 품질 관리 같은 완벽한 체제를 따르는 것을 좋아하고, 회의실이나 조립라인에서 실수를 없애는 일에 온 힘을 집중시키지만 신규 인터넷 기업의 목표 가운데 하나가 “더 빨리 실패하자!” 인 것은 우연이 아니다.

스티븐 존슨, <탁월한 아이디어는 어디서 오는가>, 164쪽

식스시그마 같은 접근법은 특정 상황에서만 효율적이다.

토마스 슐츠, <구글의 미래>, 244

(내가 식스시그마 그린벨트를 했던 거도 벌써 20년 전의 일. 설마 요즘에도 식스시그마같은 기법으로 sw 품질을 따지려는 조직은 없겠지?)

예전보다 10퍼센트 더 나은 결과를 얻고 싶다면 당연히 과거의 수단이나 증명된 방법을 선택하면 됩니다. 그러나 10배 더 나은 것을 만들고 싶다면 다른 사람들이 시작한 것에서 출발하면 안 됩니다. 유일한 방법은 기존의 전제들을 버리고 모든 것에 새로운 방식으로 접근하는 것입니다. 토마스 슐츠, <구글의 미래>, 112쪽

‘기존의 전제들을 버린다’는 부분이 우리에게 중요한 교훈이 될 것 같습니다.

(그러나 대부분의 경영자들은 여전히 개발팀에는 혁신을 요구하지만 그 외의 것들을 바꾸는 건 항상 주저한다. ‘현실적인 이유’로 어렵다면서)

알렉스, 기업의 목표가 무엇인지 확실하게 인지하지 못한다.면, 자넨 생산성의 의미도 이해할 수 없을 걸세. 단지 숫자놀이나 말장난에 불과한 거지.

엘리 골드렛, 제프 콕스, <The Goal>, 80~81쪽

병목구간이 있었기 때문입니다.

공장의 공정은 여러 단계를 거쳐서 결과를 만들어내는 시스템입니다. 따라서 그 단계 중 하나가 늦어지면 다른 모든 공정이 영향을 받게 됩니다. 결국 가장 늦어지는 공정 때문에 전체 결과가 나쁘게 나오는 겁니다. 다른 모든 공정에서 열심히 해도, 자동화 기계를 돌려도, 아무런 개선 효과가 없었죠. 전체 공정의 생산속도는 가장 늦은 공정의 생산속도를 넘을 수 없거든요..

병목 자원에서 생산자원의 시간이 낭비되지 않도록 하는 것이 첫 번째 원칙입니다.
두 번째 원칙은 병목 자원의 부하량을 덜어내 비 병목 자원으로 옮기는 것입니다.

엘리 골드렛, 제프 콕스, <The Goal>, 282쪽, 283쪽

엘리 골드렛의 이론은 ‘제약 이론(Theory of Constrations)’이라는 이름으로 알려졌습니다.

(그리고 요즘의 병목 자원은 바로 개발자, 개발자의 시간)

엘리 골드렛이 책을 쓰게 만들었던 ‘기존 패러다임과 멘탈 모델’은 무얼까요?

아마 공정 중심적 사고일 겁니다. 돈을 벌려면, 공정이 아니라 기계가 빨리 만들어지는 방법을 찾아내야 하지만, 기존 멘탈 모델은 각 공정에만 신경 썼을 겁니다. 그러면 병목을 발생하는 공정이 있다고 해도 알아차리기 힘들겠죠.

1919년 헨리 간트라는 사람이 쓰기 시작하면서 ‘간트 차트’라는 이름으로 불리게 된 차트입니다. 공정별로 일정을 기입하고 그 일정을 연결하는 방식으로 차트를 그리기 때문에, 우리가 공정에 집중하게 만들죠.

로버트 C 마틴은 <클린 소프트웨어>라는 책에서 ‘초보 관리자’는 간트 차트를 벽에 붙여 놓는 쪽으로 마음이 끌리겠지만, 현실에서는차트 구조가 붕괴되는 경험을 하게 된다고 이야기했습니다.

첫째, 어떤 공정을 끝내도 그걸로 고객에게 어떤 가치를 제공했는지 알 수 없습니다. 둘째, 계획 수립 후 검토할 때, ‘어떤 기능을 빠뜨렸나’가 아니라 ‘무얼 하지 않았나’가 검토 관점이 됩니다. 다시 말해서 공정 개수만 맞으면 소프트웨어의 질은 별로 문제가 되지 않게 된다.는 거죠. 셋째, 만약 예정된 일정을 어기게 되면, 공정을 시간 안에 맞춰야 하기 때문에 소프트웨어의 질을 포기하게 됩니다.

결국, 간트 차트로 만들어낸 일정으로 개발팀을 관리하면 소프트웨어의 질은 떨어지고, 요구사항에는 빈틈이 생길 겁니다. 그러면, 우리의 목표가 흔들립니다. 우리의 목표는 제대로 된 소프트웨어를 출시해서 돈을 버는 것이기 때문이죠.

다음 절에서는 애자일에 대해 이야기하겠습니다.

지난 50년간 발전해온 소프트웨어 공학의 마지막 지점에 애자일이 있습니다. 애자일은 ‘좋은 소프트웨어 만들기’라는 목표를 정조준하고 있는 개발 방식입니다.

폭포수 개발방식이 바로 이와 같습니다.

상류의 오물이 하류에 그대로 전달됩니다. 잘못된 요구사항 분석은 잘못된 설계로 연결되고 잘못된 코드를 만들어 냅니다. 그다음 테스트 단계에서 잘못되었다는 것을 인지하고, 다시 처음부터 시작해야 하니, 부드러운 것 (소프트웨어)을 만드는 절차라고 보기에 어렵습니다.

그러나 브룩스는 ‘폭포수 모델은 틀렸으며 해롭기까지 하다고 말합니다. <맨먼스 미신 20주년 기념판>에서도 “폭포수 모델은 틀렸다”라고 했습니다.

1950년대 후반에 폭포수 모델보다는 진화적, 반복적, 점진적 개발 (IID)이 ‘Mercury space’ 프로젝트에 적용되었고, 1960년대 초반에는 ‘Trident submmarine 프로젝트 및 다른 많은 대형 시스템에 적용되었다. 폭포수 모델 기반 개발보다 반복적 개발을 진척시키기 위한 최초의 논문이 1968년 IBM T J. Waton연구센터에서 발표되었다… 크레이그 라만이 정리한 걸 보면, 폭포수 모델을 버리기가 대세였던 것 같습니다. 1950년대부터 폭포수 모델을 버리려는 노력이 시작되어서, 1987년부터는 미국 국방부 프로젝트에서 제외되었습니다.

(생각보다 오래된 점진적 개발 방법론. 이와 함께 한 번 정착된 관행을 버리기가 얼마나 어려운지도 함께 알 수 있다. 아직도 waterfall을 좋은 개발방법론으로 알고 있는 사람을 만날 수 있으니)

다시 말해, 애자일은 지난 50년간 발전해온 소프트웨어 공학의 마지막 스냅샷인 셈입니다. 따라서, 소프트웨어를 체계적으로 개발하기 위해서 공학적 접근을 하게 된다면, 결국 애자일을 검토할 수 밖에 없는 겁니다.

소프트웨어 개발 목표

고객은 뭘 원하는지 말해줄 수 없다.

Guy Kawasaki, What I learned from Steve Jobs

헨리 포드도 비슷한 이야기를 했습니다. “내가 고객의 말을 들었더라면 그들에게 더 빠른 말을 주었을 것이다.”

우리는 우리가 아는 것 이상으로는 상상할 수 없습니다. 그러니 새로운 무언가를 만들어 내야 할 때는 소비자의 요구가 걸림돌이 되어버리는 거죠… 소프트웨어 요구사항을 작성하는 고객도 비슷합니다.

동작하는 소프트웨어를 보기 전까지, 고객은 스스로 원하는 것이뭔지 모릅니다. 그러니 동작하는 소프트웨어를 보여주면, 정말 자기가 원하는게 뭐였는지 이해하기 시작하고 요구사항을 변경하게 되는 거죠. 따라서 고객이 최대한 만족하게 하려면, 요구사항 변경을 못하도록 못박는 게 아니라, 변경이 가능하도록 동작하는 소프트웨어를 최대한 많이 보여줘야 합니다. 그렇게 해서 고객이 스스로 무얼 원하는지 알아가게 하는 거죠.

내용을 축약하면, ‘작동하는 소프트웨어’로 ‘고객과의 협력’을 하며’변화에 대응하겠다’는 건데요. 이건, 소프트웨어 개발의 목표를 정확하게 정조준하고 있는 이야기입니다.

프로젝트 리더가 처음 해야 할 일은 쓸데없는 부분을 알아차리고 현재 개발 프로세스의 가치 흐름도를 그린 다음 가장 심각한 병목 부분을 공략하는 것이다.

포피딕 부부, 〈린 소프트웨어 개발>, 181쪽

“작업들은 제약 지점 앞에 쌓이게 된다” 라고 설명해주는데요. 앞선 린 소프트웨어 개발이나 칸반처럼 병목을 찾아내서 해결하게 하는 겁니다.

목표가 정확하면 그것을 기준으로 전체 공정에 대한 그림을 그릴 수 있죠. 전체 공정에 대한 그림을 그릴 수 있으면, 병목구간이 어딘지 파악할 수 있습니다. 애자일 개발방식들은 병목구간을 해소하는 나름의 노하우를 가지고 있고요. 따라서 진지하게 애자일 개발방식을 적용하면, 점차 프로세스가 개선되는 겁니다.

병목이 바뀌고 개선을 반복하면 프로세스 내부 또는 프로세스 사이에서 간과되고 있던 낭비 요소가 드러나기 시작합니다. 프로세스 내부 낭비를 검토하는 과정에서 프로세스를 분석하고 상세화해야만 하는 시기가 올 것입니다. 가치 흐름 맵은 점점 변하므로 표현의 완벽함에 집중하기보다 개선을 통해 대기 시간과 리드타임이 줄어드는 것을 즐기십시오.

이치 타니 토시히로, <카이젠 저니>, 166쪽

문제는 ‘테일러주의’ 입니다. 우리가 당연하게 여기는 것들 상당수가 대중의 지혜나 애자일 관점에서는 당연하지 않거든요. 따라서, 애자일이 얼마나 제대로 조직에서 영향력을 발휘하냐는 일종의 리트머스 종이 역할을 할 수 있을 겁니다. 그 조직이 얼마나 테일러주의를 떠났는지, 그리고 얼마나 대중의 지혜를 잘 사용하는 조직이 되었는지, 알 수 있을 테니까요.

(그런데 애자일을 조직에 적용하기 위해서는 기술로는 말이 통하지 않는 경우가 대부분이다. 혹은 자의적으로 애자일을 가져다가 오용하는 경우 — HDC 현대산업개발 — 거나. 아직 시작하지도 않은 경우 — 신한은행 — 에 악담을 하고 싶진 않지만, 그 동안의 역사로 볼 때 전망이 밝지는 않다)

캐롤 드렉은 인간의 마음가짐을 ‘마인드 세트’라는 용어로 표현합니다. 인간을 ‘고착 마인드 세트를 가진 사람’과 ‘’성장 마인드 세트를 가진 사람’으로 나눕니다.

<칭찬은 고래도 춤추게 한다>라는 책에서 켄 블랜차드 등은 칭찬의 대상은 ‘과정’ 이라고 했습니다.

(결과가 아니라 과정에 칭찬하라. 정말 쉬운 이야기이나 실천하기는 정말 어렵다)

“업무란 주로 단순하고 별로 흥미롭지 않는 일로 이루어져 있네, 사람들에게 적절한 자극을 주고 세밀하게 감시해야만 이런 일을 하게 할 수 있지.”

다니엘 핑크, <드라이브>, 42쪽

단순한 일을 하게 통제하는 것이 테일러주의의 근간인 셈인데요. 단순한 일은 도전적인 일도, 성취감을 주는 일도 아닙니다. 성장 마인드 세트와는 아무런 관련이 없는 거죠.

…근래 지식산업사회의 근간을 이루는 IT 기술은 3년 주기로 바뀐다고 하고요. 다시 말해, 지속적으로 공부하고 도전하고 노력하며 살아야 하는 시대가 된 겁니다. 구시대적인 고착 마인드 세트는 버리고 성장 마인드 세트로 바꿔야 하는 거죠.

엄밀히 말했을 때, 팀이 승리를 하기 위해 필요한 건, 유능한 선수가 아닙니다. 팀이 승리하기 위해 필요한 능력을 가진 선수입니다… 이 영화에서 눈여겨볼 부분은 데이터의 많고 적음이 아니라, 데이터로부터 어떤 지혜를 얻는가이다.

“중요한 것은 당신이 갖고 있는 능력이지, 당신이 갖고 있지 않는 능력이 아니다.” 그렇습니다. 빌리 빈은 피터 드러커의 조직 운영 전략을 활용한 셈이네요.

빌리 빈에게 돈이 별로 없었던 것처럼, 우리에게는 개발자 인력이 부족합니다. 그러니 빌리 빈처럼 다른 방법을 찾아내야 합니다. 일단, 우리가 프로젝트를 진행하는 방식을 추려보면, 다음과 같습니다.

• R&R (Roll and Responsibilities)을 나눕니다.
• 프로젝트는 R&R에 맞게 작업을 분배하여 진행합니다.
• 관리자는 일정을 모니터링합니다.
• R&R에 맞게 일을 열심히 하면 프로젝트는 성공할 것이라고 기대합니다.

이런 방식에는 개선의 여지가 없습니다. 병목구간을 찾을 수 없기 때문입니다. 이 상태를 그대로 놔두는 건, 빌리 빈 이전의 메이저리그 팀들이 선수를 운영하는 방법과 같은 겁니다. 빌리 빈의 방법을 가져오려면, 목표’를 정하고, 목표에 따라 공정을 재배열해야 합니다.

우리의 목표는 ‘자기가 뭘 원하는지 모르는 고객이 원하는 걸 이해하고 가치를 충족하게 하는 겁니다. 하지만 고객이 뭘 원하는지 모르기 때문에 요구사항은 지속적으로 변화할 것이고, 이를 개발 목표로 삼아서, 병목을 찾는 구도를 만들기는 힘듭니다. 그래서, 스프린트가 필요합니다.

(이런 이야기할 때 머니볼 예를 드는 건 이제 흔한 일이다. 다만 사실 관계가 잘못된 경우가 많은데 저자도 이걸 몰랐거나 — 아마 mlb 팬이 아니라서 — 내용을 강조하기 위해 일부러 그렇게 쓴 듯 하다. 당시 오클랜드의 페이롤은 뒤에서 3위였으므로 가장 가난한 구단은 아니었고, 팀 로스터에는 멀더 허드슨 벌리같은 투수 3인방에 테하다를 비롯한 강타자들이 있는 결코 약하지 않은 팀이었으며, 빌리 빈과 감독, 스카우팅 디렉터와의 관계도 나쁘지는 않은 편으로 알려져 있다)

스크럼

스크럼 개발 방식은 애자일 개발 방식 중 하나입니다. 스크럼에는 스프린트라고 부르는 개발 주기가 있는데요. 일정을 2주 단위로 끊어서 진행하는 겁니다. 그리고 스프린트 내에서는 요구사항의 변화를 막습니다. 그러면 우리는 흔들리지 않는 목표를 2주간 가질 수 있게 되는 거죠. 목표가 정해졌으니 병목구간을 찾아서 개선할 수 있게 되었습니다.

병목구간은 어떻게 찾을까요?

스크럼은 스프린트 중에 매일, 데일리 스크럼’이라는 이름으로 스탠드 업 미팅을 합니다. 이때 ‘한 일, 할 일, 방해요소’를 이야기하게 되어 있거든요. 스프린트 목표를 이루기 힘들게 만드는 방해요소는 결국 병목구간을 가리키고 있게 됩니다. 병목구간을 찾아낸 거죠. 프로세스 개선이 가능해졌습니다.

한편, 애자일 이야기를 하면, 관리자들은 ‘그거 안 해도 우린 방법이 있어…’라고 생각할지도 모릅니다. 그게 바로 인력 충원인데요. 안타깝지만 그건 아주 제한적으로 효과가 있는 방법입니다. 특히 일정이 늦어진 경우에는 역효과가 납니다. ‘브룩스의 법칙’ 이죠.

브룩스의 법칙

관리자가 되어, 간트차트와 R&R을 보면서 소프트웨어 프로젝트를 진행할 생각을 하면 정말 난감합니다. 사람이 너무 많이 부족하거든요. 하지만 인력 충원이 쉬운 조직은 없습니다. 그럼, 어쩔 수 없이 프로젝트를 진행하게 되는데요. 관리자가 간트차트와 R&R에 집착하고 있으면 개선방향을 찾을 수 없으니, 결국 예정대로 프로젝트는 망해가게 됩니다. 그럼 관리자가 생각할 수 있는 해결책은 한 가지입니다. 바로 팀에 인력을 더 밀어 넣는 거죠.

일정이 늦어진 소프트웨어 프로젝트에 인력을 추가하는 것은 일정을 더욱 늦추는 결과를 낳을 뿐이다.

브룩스, <맨먼스 미신>, 48쪽

사람을 더 투입하면 그 사람은 바로 일할 수 없습니다. 적응할 시간이 필요합니다. 요구사항이 무엇이고, 어떤 기술을 써야 하고, 그 팀에서 어떤 식으로 작업을 진행하고 있었는지 먼저 알아야 하니까요. 따라서 당장 프로젝트에 투입할 수 없고, 프로젝트 일정에 보탬이 되는 일을 할 수 없습니다.

그런데, 일을 하려면 업무 인수를 받아야 합니다. 다시 말해 이미 프로젝트에서 일을 하고 있던 다른 개발자의 도움이 필요합니다. 그러니 그 시간만큼 프로젝트 진행은 늦어지게 됩니다. 게다가 사람이 늘어나면 커뮤니케이션 비용도 늘어납니다. 회의도 좀 더 해야 하고, 회의 시간도 좀 더 길어집니다. 역시 그만큼 더 느려지겠죠.

따라서, 원하는 결과가 나오지 않는 겁니다.

… 브룩스는 IBM 역사상 전무후무한 도박성 프로젝트를 진행하고 성공시킨 인물입니다… 그러니, 브룩스의 법칙’은 이론이 아니라 실제입니다. 따라서, 인원충원보다 확실한 개선 방법을 찾아내야 합니다. 그건 결국 프로젝트의 목표를 명확히 하고 병목구간을 찾아내고 이를 해소하는 방법입니다. 그러니, 애자일 개발 방식을 들여다볼 수밖에 없게 됩니다.

물론, 프로세스 개선 외에 방법도 있습니다. 코드를 제대로 만드는 겁니다. 하지만 그게 쉬운 일은 아닙니다.

하지만 프로그램을 제대로 만드는 일은 전혀 다르다. 소프트웨어를 올바르게 만드는 일은 어렵다. 소프트웨어를 제대로 만들려면 적정 수준의 지식과 기술을 겸비해야 하지만 대다수의 젊은 프로그래머는 이 수준에 도달하지 못했다. 또한 사고력과 통찰력을 갖춰야 하지만 대다수의 프로그래머는 시간을 들여 이러한 능력을 개발하지 않는다. 그리고 어느 정도의 훈련과 헌신이 필요하지만, 대다수의 프로그래머는 훈련과 헌신이 필요하리라는 생각조차 하지 않는다. 소프트웨어를 올바르게 만들려면 무엇보다도 기술을 향한 열정과 전문가가 되려는 열망이 필수다.

반면 소프트웨어를 제대로 만들게 되면 마법과도 같은 일이 벌어진다. 소수의 프로그래머만으로 프로그램이 지속적으로 동작하도록 만들 수 있다. 거대한 요구사항 문서와 이슈가 수없이 등록된 이슈 추적 시스템도 필요가 없다. 전 세계의 칸막이로 나뉜 작은 사무실에서 휴일도 없이 일해야 하는 프로그래머가 없어도 된다.

제대로 된 소프트웨어를 만들면 아주 적은 인력만으로도 새로운 기능을 추가하거나 유지보수할 수 있다. 변경은 단순해지고 빠르게 반영할 수 있다. 결함은 적어지고 잦아든다. 최소한의 노력으로 기능과 유연성을 최대화할 수 있다.

나를 포함해서 우리 대다수는 대체로 이러한 경험을 했다. 훌륭한 소프트웨어 설계를 바탕으로 작업하면서 즐거움을 느끼기보다는, 형편없는 소프트웨어 설계와 맞서 싸우는 일을 일을 훨씬 더 자주 맞닥뜨린다.

로버트 C 마틴, <클린 아키텍서>, 29쪽

변연계는 신뢰와 충성심 따위의 모든 감정을 담당한다.

사이먼 사이넥, <나는 왜 이 일을 하는가>, 89쪽

비전이 변연계 (Limbic System)에 심어지면, 뇌의 다른 부분을 움직여서 그 일을 하게 만들어 갑니다. 변연계는 신뢰와 충성심을 담당하기 때문에, 변연계에 스며들어 있는 비전은 우리 마음을 송두리째 쏟아붓는 열정으로 나타나게 되는 겁니다… 그러니 테일러주의 아래에서는 라이트 형제가 나올 수 없는 겁니다.

양육 소홀이 아주 심할 경우에는, 파충류의 기능에 신피질의 영악함이 더해진 존재가 나올 것이다. 그러한 동물은 같은 종에게 해를 입혀도 양심의 가책을 느끼지 않고, 사소한 좌절이나 작은 이익 때문에 우발적인 살해를 저지르는 일에 대해서도 이를 억제하는 내적 동기를 갖지 못한다.

토머스 루이스, <사랑을 위한 과학>, 311쪽

…파충류 같은 사람이 된다는 겁니다. 파충류는 변연계가 부실하기 때문에 동족을 잡아먹으면서도 거리낌이 없습니다.

그럼, 이걸 회사의 조직문화로 강요하면 어떻게 될까요?(테일러주의가 그런 조직문화를 강요하죠.) 자기에게 이익이 되지 않는 일은 하려 들지 않게 될 겁니다. 조직문화도 그렇게 되겠죠. 비전이나 열정을 가진 사람은 소외되게 될 겁니다. 결국 관리자들은 일을 시키기 위해서 R&R을 열심히 짜놓겠죠. 그다음 일정 관리는 간트 차트로 하게 될 겁니다.

앞서 언급했지만, R&R과 간트차트에 집착하면 개선방향을 찾아낼 수 없습니다. 목표에 따라 전체 프로세스를 볼 수 있어야만 병목구간이 보이고, 병목구간을 해소하는 법 외에는 개선 방향이 없기 때문이죠. 따라서, 개선의 노력은 하고 있지만 결과는 없는 조직이 될 겁니다. 그럼 변화하는 시장 상황에 대처하기 힘들겠죠. 즉, 진화가 힘든 생물이 되는 겁니다.

아름다움과 초월성 같은 것을 소비자들이 추구하는 시대가 되었습니다. 그러니, 이를 제품에 담아낼 수 있는 기업이 경쟁력과 생존력 있게 되겠죠. 다니엘 핑크는 이런 시대를 ‘하이 컨셉’ 시대라고 이야기했습니다.

… 차이가 있었다면 크리에이티브는 자사 제품의’무엇을’을 내세웠고, 애플은 그것이 우리에게 ‘왜’ 필요한지를 말했을 뿐이다.

사이먼 사이넥, <나는 왜 이 일을 하는가?>. 73쪽

애플은 이미 ‘왜’에 대해서 말할 수 있는 기업이었고, 하이 컨셉 시대로 진입한 회사였습니다. 그러니, 이제 막 산업화 시대를 거처 정보화 시대를 바라보고 있던 우리나라 휴대폰 대기업들은 아이폰의 파괴력을 이해할 수 없었던 거죠. 여기서 우리는 ‘기본적 귀인 오류’에 빠지지 않아야 합니다(3장에서도 이야기했죠.).

산업화 시대에서 아직 하이 컨셉 시대로 넘어가지 못한 건, 대기업 임원들만의 문제가 아니거든요. 우리 사회 전반의 문제입니다. 우리도 마찬가지죠. 그래서, 우리나라 소프트웨어 개발 조직들은 산업화 시대공장을 운영하듯 운영되어 왔습니다. 그러다 보니, 개발자들이 코드에 대한 열정을 가지는 건, 회사 입장에서는 거추장스러운 것이었고요. 이런 조직문화에 적응하다 보니, 개발자들 스스로도 그런 열정은 버리고, 회사가 만들어 달라는 것 빨리 만들어 주다가, 적당히 나이 먹으면 이 지긋지긋한 일을 때려쳐야겠다고 마음먹게 된 거죠.

죽을 때까지 코딩할 만한 시대가 열리고 있으니 우리만 준비되면, 죽을 때까지 코딩할 수도 있을 테니까요.

먼저, 자기계발의 습관을 가져야 합니다. L-모드 코딩은 R-모드로 전환해야 합니다. 순차적 논리 전개는 빈틈이 많으니 공간적, 직관적, 총체적 방식으로 코딩하는 법을 익혀야 합니다. 이는 TDD를 사용하고, 소프트웨어 개발 패러다임을 공부하고 익히는 것으로 해낼 수 있습니다. 모닥불 기업은 스스로 진화하는 방법으로 애자일을 선택할겁니다. 그러니 애자일에 대해서도 익숙해야겠죠.

하이 컨셉 시대에서 소프트웨어 개발은 지금보다 더 힘들어질 전망입니다. 창조와 공감이 필요한 소프트웨어가 되어야 하기 때문인데요. 결국은 자기가 뭘 원하는지 모르는 고객들이 뭘 원하는지 알게 만들고, 자기 가치를 충족할 수 있도록 이끄는 프로세스가 보편화될 겁니다. 물론 애자일은 지금도 그렇게 하고 있습니다.

Etc.

sample pdf file 참고 도서 리스트가 매우 좋음