인간, 조직, 권력 그리고 어느 SW 엔지니어의 변 by 이종국

[ 읽은 이유 ]

 

그냥 집어 들었다. SW개발자가 쓴 SW책들은 지천에 널려 있고 나는 SW를 만들지는 않고......SW개발자가 쓴 인문학이나 사회학 서적이 있다면 들어 보고 싶다...

 

하물려 국내 저자가 쓴 거라면 함께 사는 조직과 사회에 대해 무엇을 고민하고 어떻게 말하고 있는가?가 궁금했다......혹시 아나 임백준씨과 같은 보석을 건져낼 지....

 

또한 직장생활을 하면 할 수록 조직과 권력을 사이에 두는 정치라는 부분에 대하여 생각해 보지 않을 수 없다.. 저자와의 초점도 맞을 것 같고.....

 

[ 배운 점 ]

 

일반적으로 SW분야가 중요하다.

그럼 왜 우리는 이 모양인가? 창의적 교육이 없는 주입식 교육이 문제다 창의적 인재를 육성해야 한다.....

이런 방식이 대부분의 전문가라는 분들의 스토리 라인이다.

 

저자는

'SW분야가 발전하지 못하는 이유는 정보의 교류가 상당한히 미흡한 탓이라고 생각한다.

특히 SW산업을 우리가 제어하지 못하고 제어당한다면 산업적으로도 우리는 일개 노동자에 불과해 버린다.

SW산업은 정신노동이기 때문에 정신적인 활력, 즐거움만이 이 산업을 제어할 수 있다. 즉 나의 자아되 되찾고 일도 의미가 있어야 새로운 제품도 생산해 낼 수 있다...... SW산업은 제조업처럼 누군가 기획해서는 만들 수 없다. ....

 

SW 산업 종사자들이 이에 재미를 느껴야 새로운 제품도 나오고 시장도 활기를 띨 것이다. 개발자들이 자신의 삶을 되찾는 것은 그래서 개인적으로 뿐만 아니라 산업적으로도 매우 중요하다. '라고 생각한다.

 

이런 통찰로 보아 이 책을 읽고 다시 볼 필요가 있다.

 

어쭙지 않은 경험과 어디서 짜집기 한 case 사례로 자신이 마치 SW산업, 지식산업, 나아가 4차 산업 혁명을 떠들고 다니는 헛 전문가보다 저자가 확실히 더 고수임을 알게 될 것이다....

 

[ 주요 내용 ]

 

ㅇ 프로젝트 현장은 대단히 정치적인 곳이며 정치적인 감각이 없으면 생존할 수 없는 곳이다.

 

ㅇ 혼자서 살아남기 어렵기 때문에 강력한 팀을 만들어 팀의 능력을 극대화해야 한다. 내가 그런 팀의 리더가 되든지, 그런 팀에 들어가 자신을 보호해야 한다.

 

ㅇ SW의 특성을 이해하고 분석, 설계, 구현, 테스트까지 기본적인 것은 해낼 수 있는 능력을 키워야 한다. 또한 개인적인 생산성을 극대화시키는 방법을 찾아야 한다.

 

ㅇ 사람이 바라는 것과 시스템 능력 사이의 간격이 SW의 핵심 문제다.

 

ㅇ 프로젝트의 상황이 정상적으로 흘러가지 않기 때문에 정상적인 상황을 가정하고 만든 SW 공학이나 방법론은 소용이 없다. 차라리 프로젝트가 늘 비정상적이라고 생각하고 해결책을 찾는 것이 나을 것이다.

 

ㅇ 내가 발견한 것은 SW가 지닌 대부분의 특징은 인간 심리와 인식 능력의 한계에서 비롯된다는 것이다.

 

 

ㅇ 모든 프로젝트는 사업상 매력적인 이유 때문에 선택된다. 그래서인지 '기술적으로 이것이 가능한 일일까?'는 우선 순위에서 밀린다....대부분의 프로젝트 실패가 이미 처음부터 예견된 일이었음을 알게 될 것이다.

 

ㅇ 전산 시스템 관점에서 보면 여러 개의 컴퓨터가 상호 통신하는 분산 컴퓨팅 방식이다. 또한 정보 처리에 시간 제약이 있는 실시간 컴퓨팅 방식이다. 이런 분산 실시간 컴퓨팅 방식은 전산 아키텍처 상으로는 가장 구현하기 어려운 방식이다.

 

ㅇ 문제는 시스템의 규모가 커짐으로 인하여 발생하는 시스템 구축의 복잡성이 시스템의 규모에 선형적으로 비례하는 것이 아니라 지수함수적으로 커진다는 것이다. 즉 트랙이 10개였을 때 오류가 10개였다면 트랙이 100개면 오류가 100개 아닌 10의 10승개가 될 수 도 있다.

 

ㅇ 왜 뻔히 결과가 보이는데 시연회를 강행했을까? 여기서도 조직의 보편적인 매커니즘이 작동한다. 한번 시작한 일은 문제가 무엇이든지 완료해야 한다는 관성이 작용한 것이다.

 

ㅇ 총 비용이 59억 달러로 미국 항공 교통 통제시스템(AAS) 개발 프로젝트는 시스템 공학 역사상 가장 큰 실패 사례로 평가 받고 있다. 특히 ....실패 원인 중 하나는 오히려 SW공학을 너무 철저하게 지키려 한 데서 비롯된 것이다.

 

ㅇ 애초에 가능성이 낮은 프로젝트는 기술 검증과 대규모 예산, 신중한 스펙 작성과 생산성을 높여주는 신기술, 엄격한 품질검증 등 최고의 SW 공학 기법을 사용해도 성공하기 힘들다는 것이다...문제는 SW의 복잡성이 문제를 극복하기 위해 준비한 모든 방법을 삼켜버렸다는 것이다.

 

ㅇ  SW는 물과 같은 것이다.  SW는 SW를 담는 그릇에 따라 모양이 달라진다. 따라서 아무리 엄격하게 코드 리뷰를 하고 문서를 작성해도 SW를 사용하는 사람이나 개발하는 사람의 생각이 바뀌면 SW 내용이 금방 달라진다....SW를 담는 그릇은 결국 우리의 생각인데 우리의 생각이 구멍이 있고 계속 바뀌니 SW를 문서로 규정하려는 노력이 소용 없어지는 것이다.

 

ㅇ SW 경우는 SW 프로젝트 마다 독특하며 이전 프로젝트에서 했던 것을 가져다 활용할 수 있는 것이 많지 않다....SW 개발 프로젝트마다 다른 것은 문제 영역에서 많은 부분이 다르기 때문이다. 예를 들면 은행의 경우, 통장을 만들고 입금과 출금을 하고 대출하는 기능은 세계의 모든 은행이 동일하다. 그러나 그 일을 처리하는 방식은 많은 부분이 다를 수 있다. 마치 개인이 일 처리하는 방식이 다 같지 않듯이 은행도 일 처리하는 방식, 사용하는 용어, 조직에 차이가 있다.... 각 문제 영역이 같은 듯하지만 다르기 때문에 SW 프로젝트도 매번 유일한 프로젝트가 된다.

 

ㅇ 문제 영역은 유일할 뿐 아니라 인간적인 영역이며 기계는 엄격한 물리적인 영역이다. SW는 두 영역 사이에 존재한다. 문제 영역은 사람들의 고민과 희망의 영역이기 때문에 모호하다. 반면 CPU와 레지스터, 하드 디스크로 구성된 컴퓨터는 기계의 한계 때문에 문제 영역에서 사람들이 바라는 모든 것을 처리할 수 없다......문제 영역이 모호하기 때문에 문제 영역의 문제를 정확한 언어로 정의해야 한다.

 

ㅇ SW의 어려움은 사람들의 욕구가 계속 변한다는 것이다. 이럴 경우 가장 현실적인 방법은 시도해 보고 수정하는 것이다.

 

ㅇ 과학이 신학에서 분리된 첫 번째 이유는 모든 판단의 근거를 경험에서 찾았기 때문이다.....SW는 실험이라는 이론의 판단 기준을 세울 수 없다. 그렇다면 강제로라도 오류 판단 기준을 세워야 한다. 그래서 프로그램을 작성하기 전에 이런 것은 오류라고 선언해야 한다. 그리고 작성한 프로그램을 이렇게 선언한 오류에 비추어 맞는지 틀리는지 판단해야 한다... 이것이 테스트 주도 개발 (TDD, Test-Driven Development)....무엇이 오류인지 명확하기 때문에 프로그램도 즉각 수정된다.

 

ㅇ 우리가 대상으로 하는 것이 자연현상이 아닌 비즈니스라는 것이 문제이다. 비즈니스에서 정해진 규칙을 발견하기는 어렵다.....비즈니스 도메인에서 유일한 규칙은 비즈니스를 통해 성과를 내야 한다는 것이다. 돈을 벌든, 고객을 만족시키든 가치를 창출해야 한다. SW는 비즈니스를 지원하는 기능을 가지기 때문에 어떤 모순된 규칙들도 비즈니스에 필요하면 수용해야 한다.

 

ㅇ 프로그램은 어떤 순간이나 어떤 기간 동안 관찰한 문제 영역만을 표현할 수 있다. 따라서 프로그램은 가설에 대한 임시 해결책이라 언제든지 폐기될 수 있으며 문제 영역이 변하니 SW도 계속 변해야 한다.

 

ㅇ 분할 정복 외에는 뽀족한 다른 방법이 없는 것 같다.....자연 현상을 분할 정복하지 않고 해결하는 방법으로 내가 알고 있는 유일한 방법은 시뮬레이션이다. 시뮬레이션은 근본적인 복잡성을 인정하고 이것을 컴퓨터 프로그램으로 옮겨서 나타난 결과를 해석하는 방법이다.

 

ㅇ SW의 복잡성을 분할 정복하는 방법으로 해결할 수 없는 또 한가지 이유는 SW를 모듈화한다고 해서 로직도 모듈화되는 것이 아니기 때문이다....로직 자체를 클래스화하면 클래스의 개수가 증가하여 코드의 복잡성이 클래스의 복잡성으로 대체될 뿐이다....

 

ㅇ 근본적으로 도메인의 복잡성을 SW 서비스, 컴포넌트, 유스케이스, 클래스로 단순화시킬 수 없다. 코드의 복잡성이 클래스나 유스케이스의 복잡성으로 바뀔 뿐이다.

 

ㅇ 분류란 내가 생각하는 대상을 어느 곳에 위치시키고 어떤 묶음으로 묶을 것이냐는 것이다....분류 문제는 데이터 모델링에서는 정규화라고 불리고 프로세스 모델링에서는 프로세스 계층이라고 부른다. SW 아키텍처에서는 View라고 불리며, 코딩에서는 함수, procedure 클래스, 오퍼레이션이라고 부른다.

 

ㅇ SW공학에서의 분류는 프로젝트 내에서만 사용되는 폐쇄적인 성격을 갖고 있으며 보편성을 획득할 장치가 없다. 결국 SW 공학이 아니라 SW 공학이 적용되는 도메인이 폐쇄적인 성격을 갖고 있기 때문에 분류 체계가 보편성과 안정성을 갖지 못하게 된다. 이 문제를 해결하는 유일한 방법은 특정 도메인에서 수행한 프로젝트의 결과를 학회에서 즉시 공개하는 것이다. SW 개발자들도 의학자들과 비슷한 방식의 모임을 통해 서로의 문제점을 공개하는 방식을 택해야 한다.

 

ㅇ 엔트로피가 증가하는 이유는 질서라는 말을 우리가 임의로 정했기 때문이다. 무엇을 질서정연한 상태라고 하는가? 그것은 우리가 정한 기준이다.....질서 있는 상태는 몇 개 안되지만 질서를 벗어난 상태는 많을 것이다...

 

ㅇ 엔트로피 증가는 내가 분류 문제라고 한 것과 동일한 문제이다. SW 임의로 분류 기준을 정하여 속성과 오퍼레이션이 어느 클래스, 어느 모듈에 들어가야 하는지 결정한다. 엔트로피 증가 때문에 SW는 유지보수라는 작업이 필요하다. SW 엔트로피 증가 현상에 더하여 유지보수를 한층 어렵게 하는 것이 바로 이 분류 문제다. 유지보수를 담당한 개발자가 선임자의 분류 체계를 납득하지 못하는 경우가 흔하다.

 

ㅇ 엔트로피 증가로 인하여 SW 유지보수가 필연적이라면 우리는 유지보수를 불필요한 행위로 보아서는 안된다. 나는 유지보수가 SW의 가장 핵심적인 업무라고 본다. 왜냐하면 SW는 엔트로피 증가, 분류 문제, 도메인의 유동성 등으로 인해 개발이 완료되자마자 빠르게 불완전해지기 때문이다......유지보수 작업은 개발도 동시에 병행적으로진행되어야 한다.

 

ㅇ 엔트로피 증가에 따른 개발자의 대응은 창조적이고 예술적인 행위이다. 개발자는 코드를 유지보수하기 위해 프로그램의 동적, 정적 구조를 고민하게 된다. 이런 행위를 수행하는 기법들이 설계 패턴, 리팩터링이다.

 

ㅇ 정보의 차단은 어떤 개체의 성장을 중단시킨다. 성장은 빈번한 교류, 환경에 대한 적응을 통해 가능하다. 이것은 모든 생명의 특징이다...

 

ㅇ SW분야가 발전하지 못하는 이유는 정보의 교류가 상당한 미흡한 탓이라고 생각한다.  SW공학이나 새로운 프로그램 언어, 개발 도구는 SW 발전에 끼치는 영향이 미미하다. 필요한 것은 도메인에 대한 지식을 서로 교환하는 것이다. 심지어 홰외에도 프로젝트에서 사용한 기법을 다루는 책은 봤지만 프로젝트 수행 후 도메인 지식을 책으로 출판하는 것은 보지 못했다. 아마 도메인 지식 자체가 회사 소유라서 공개가 불가능한 탓일 것이다. 어쨌든 SW가 발전하기 위해서는 공학적인 기법보다 도메인 지식이 공유되어야 한다. 도메인 지식이 공유되면 도메인을 어느 정도 표준화하거나 참고하는 것이 가능하다.

 

ㅇ 조직은 문제점을 최대한 은폐하려는 속성이 있다. 아니면 희생양을 찾을 것이다. 조직은 자신의 생존을 위해 모든 수단을 총동원해서 시스템의 문제점이 노출되지 않도록 할 것이다.

 

ㅇ 개발자가 무엇을 하고 있는지 알 수 없다는 것이 프로젝트 관리의 큰 구멍이다. 특히 한국의 상명하복 문화, 동료들 간의 치열한 경쟁은 프로그래머가 자신이 만든 것에 대해 노출을 더욱 꺼리게 만든다. 그리고 PM과 PL의 전문성이 떨어진다는 점 때문에 개발자들이 관리자를 쉽게 속일 수 있다. 한국에서 그들의 전문성이 급격히 떨어지는 이유는 한국의 전산 시스템이 유행에 민감하기 때문이다.

 

ㅇ 이것을 SW의 비가시성이라고 부른다면, 이런 문제 때문에 PM은 자신 있게 프로젝트를 끌고 갈 수 없고 고객이 PM을 불신하는 원인이 된다. 이런 SW 비가시성을 내부 감리, 외부 감리를 동원하여 풀려는 것은 어리석은 행위다.

 

ㅇ 어떤 문제를 해결하는 방식은 가정하고 시도하고 다시 가정하고 시도하는 방식이지 정의하고 분석하는 방법이 아니다. 정의하고 분석하는 일은 문제가 해결된 후 해결한 문제를 설명할 때 어떤 일관성을 부여하기 위해 하는 것이다. 해결책을 설명하는 방식을 해결책을 찾기 위한 과정으로 착각하여 SW 개발에 혼돈을 일으킨다. SW개발할 때도 고객이 원하는 것이 이런 것이라는 가정을 세워서 해답을 찾고 고객에게 개발자가 만든 해답이 맞는지 고객에게 확인을 요청하지, 고객이 정의한 요구사항을 단어 하나하나까지 분석하여 모델을 만들고 개발까지 진행하지 않는다. 따라서 요구사항 분석이라는 말은 부적절한 말이며 '가설-임시해결책 제시'가 프로젝트 상황을 표현하는데 더 적절하다.

 

ㅇ 현실에서는 '시도하고-수정하기' 방식으로 작업이 진행된다.

 

ㅇ 요구사항 분석이라는 말은 부적절하며 가설-임시해결책 제시가 프로젝트 상황을 표현하는데 더 적절하다.

 

ㅇ 고객의 요구사항을 듣고 고객이 원하는 프로그램은 이런 것이라고 선언하는 것이다. 따라서 테스트 주도 개발에서 테스트 케이스는 가설의 역할을 담당한다.

 

ㅇ 과학의 방식은 시도하고 수정하는 것이다. test 주도 개발은 가설을 세우고 시도하고 수정하는 방식을 현실에 부합하는 개발 방식이다.

 

ㅇ 조망의 수준이 달라지면 우리가 관찰하는 대상과 대상 사이의 관계도 달라진다. 우리의 사고 방식은 항상 어떤 관찰 대상의 크기를 설정하고 이 대상 사이의 관계를 정의한다.

 

ㅇ 프로그램에서는 프로그램에서 만든 함수의 특징과 함수와 함수 사이의 관계가 중요하다......기존 시스템과 신규 시스템 사이를 연계해야 하는데 연계 방식도 소켓을 사용하는 방식, 웹 서비스를 사용하는 방식 등으로 다양하다.

 

ㅇ SW관점에서 최종 시스템의 모습을 조망하는 것을 SW 아키텍처라고 한다.

 

ㅇ 아키텍처의 목적은 구성요소의 조합에서 발생하는 문제점을 해결하는 것이다. 아키텍처는 구성요소 자체의 문제점에 대해서는 말하지 않는다. 구성요소를 어떻게 잘 만드는가는 개별 프로세스를 통해 해결할 문제이다. 아키텍처는 개별적인 구성요소들을 조합했을 때 어떤 문제가 발생하는지에 관심을 둔다.

 

ㅇ 제품의 구성요소는 문제가 생겨도 담당자를 불러서 고치면 되지만 구성요소의 연결관계는 누구의 책임인가? 담당자를 불러봤자 서로 책임 공방만 되고 해결책을 제시하지 못할 것이다. 즉 시스템의 구성요소 사이의 관계는 특정 담당자가 책임질 수 없으며 시스템을 만드는 팀 전체의 책임이 된다......구성 요소 사이의 관계에 품질에 대한 책임은 팀이나 회사가 지게 되며 여기에 팀과 회사의 역량을 집중해야 한다. 즉 회사의 품질 역량을 아키텍처에 집중시켜야 한다.

 

ㅇ  개인이 알고 있는 지식이 불안적하기 때문에 우리는 팀을 통해 서로 학습해야 하며 팀을 통해 배우는 것이 개인이 혼자하는 것보다 더 짧은 시간에 효율적인 학습이 가능하게 한다.

 

ㅇ 한국인은 팀으로 일하는 것을 배울 기회가 공식적으로는 거의 없다. (그래서인지 개인적으로는 능력 있는 사람이 팀에서는 팀을 파괴하는 행동을 하는 것을 많이 보았다.) 팀은 일사 분란하게 경영자가 원하는 대로 움직이는 조직과는 다르다. 팀은 개인의 개성이 조화를 이루는 것이며 자율적으로 움직이고 자율적으로 성장한다. 한국인들은 이런 진정한 팀에서 일해본 경험이 부족하다.

 

ㅇ ....이렇게 작업하는 것이 팀의 표준 절차였기 때문이다. 이상적인 팀은 자발적으로 움직인다. 자발적으로 행동하는 이유는 이렇게 일하는 것이 편하기 때문이다.

 

ㅇ 팀 작업이 품질로 이어졌다.....SW공학의 어떤 절차나 기법이 품질 향상에 기여하지 않았으며 오직 팀 작업만이 품질로 이어졌다는 것이 중요하다.

 

ㅇ 개인으로만 일했던 사람은 팀으로 일하는 것이 무엇인지 이해할 수 없다. 많은 사람들이 팀에 속하여 팀장이 지시를 받고 일하는 것이 팀으로 일하는 것이라고 생각한다. 그러나 팀은 상호 관계 속에서 일한다.

 

ㅇ 집단에 속한 사람은 특정한 권력자에게 충성하는 것이 아니라 집단에 충성하는 것이다. 권력자는 두려움과 공포와 불확실한 미래의 약속으로 개인을 통제하지만 집단은 충성할수록 더 큰 유대감과 만족감을 선사한다. 따라서 집단에 대한 인간의 충성심은 자발적이며 행동의 몰입도는 권력자의 명령을 이행할 때의 몰입도나 충성심보다 휠씬 크다. 이것이 응집력이 강한 팀이 생산성이 높은 이유다.

 

ㅇ  집단이란 개인으로는 숨기고 있는 나는 특별하다는 생각, 나에 대한 자부심, 그리고 내가 가지고 싶은 강한 권력에 대한 욕구가 집단에 투영된 것이라고 볼 수 있다. 사람은 집단과 자신을 동일시함으로써 억눌렸던 감정을 해소하는 것이다.

 

ㅇ 주의해야 할 것은 압력을 가하는 사람과 절대로 맞서거나 일을 거절하지 말라는 것이다. 그들에게는 생색내기용 결과만 주면 된다... 조직에 영향력이 없는 사람이 나에게 압력을 가하는 경우....그냥 무시하면 된다.....물론 감정이 상하지 않게 온갖 알아듣기 어려운 이론을 내세워 거절하면 된다.

 

ㅇ 개인은 생사여탈권을 가진 사람의 명령에만 압력을 느낀다. PM은 팀원의 생사여탈권을 가지고 있는가? 만일 가지고 있지 않다면 그런 권력을 만들어야 한다. 그리고 팀원에서 PM 이외에 압력을 가하는 사람이 있다면 모두 차단해야 한다.

 

1) 최소한의 충성스러운 사람들을 확보하라. 이 사람들을 최대한 PM에게 충성하도록 만들어야 한다.

 

2) 각 팀의 우두머리는 PM이 신뢰하는 사람을 앉혀라

 

3) 같은 외부 업체 또는 같은 부서에서 온 사람을 둘 이상 같은 팀원으로 놓지 마라. 즉 팀을 이루어 사적인 목적을 추구하지 않도록 하라.

 

ㅇ 리더십을 카리스마로 정의하려 한다면 가장 위대한 지도자는 히틀러나 스탈린, 마오쩌뚱일 것이다.....훌륭한 리더에게는 성격적으로 공통적인 특성을 찾을 수 없다.

 

ㅇ 내가 생각하는 좋은 리더는 문제를 해결하는 사람이고 팀의 목표를 달성하는 사람이다.  리더십은 목표지향적이다.

 

ㅇ  자신이 어떤 일에 대한 전문가일 필요도 없었다. 다만 어떤 일을 해결하기 위한 가장 효과적인 방법이 무엇인가를 고민하면 되었다.

 

ㅇ 리더가 모범을 보이는데도 따라 오지 않는 사람은 팀에서 나가게 하거나 중요하지 않은 일만 맡겨서 스스로 팀을 떠나도록 했다. 어찌 보면 냉정해 보이지만 목표를 달성하는 데 도움이 되지 않는 사람은 팀을 떠나야 한다.

 

ㅇ 팀원들에게 자신감 있게 행동할 수 있었던 배경에는 내가 누구보다 일에 대해 많이 알고 사람들에게 가르쳐 줄 것이 많기 때문이였다.

 

ㅇ 리더는 인간에 대해 더 많은 것을 공부해야 한다. 실패 사례를 보면 기술적인 문제 뒤에 사람의 문제가 있음을 알게 된다. 리더는 더욱더 정진하여 인간이 무엇인지를 파악해야 한다.

 

ㅇ 팀 구축을 위해 리더가 해야 할 첫 번째 일은 팀원을 관찰하는 것이다. 각 사람이 어떤 재능을 가지고 있으며 어떤 불만과 욕망을 가지고 있는지를 관찰했다.

 

ㅇ 인간을 파악하는 것은 부단한 관찰과 자기반성을 통해서만 가능하다.

 

ㅇ 불필요한 사람은 팀에서 솎아내라는 것.....솎아낼 사람은 무능한 사람이 아니라 티팀의 목표를 위해 일하지 않는 사람이다. 왜 가르쳐서 팀을 위해 일하도록 만들지 않을까? 가르쳐서 변할 수 있는 사람은 10명에 한 명 뿐이기 때문이다. 사람은 쉽게 변하지 않는다. 따라서 사람을 변화시키려고 노력하기보다 팀의 목표에 적합한 사람을 뽑아서 최적의 팀을 구성하는데 힘을 쏟아야 한다.

 

ㅇ 리더는 팀원의 개인 경력을 챙겨주는 사람이 아니다...리더는 오직 팀만 생각하며 최고의 팀을 만드는 데만 집중한다. 실제적인 성과는 팀이 내는 것이다.

 

ㅇ 행동이 발생하는 현장에서 팀의 행동을 교정한다....팀 구축은 교육시간이나 훈련시간에 하는 것이 아니며 일이 발생하는 현장에서 이루어진다.

 

ㅇ 사고의 변화가 행동의 변화로 이어지는 것이 아니다. 오히려 행동이 변해야 사고가 변한다. 인간은 환경에 대한 적응력이 빠른 동물이다. 인간은 주어진 환경에 맞는 행동을 하기 위해 자신의 사고를 바꾸고 자신이 하는 행동을 정당화시킨다. 따라서 팀의 일원으로 행동하도록 행동의 변화를 촉구해야 한다.

 

 

ㅇ  팀이 자발적으로 일하게 하고, 모든 방해 요소를 차단하라....리더가 할 일은 팀을 외부 방해 요소에서 적극적으로 차단하는 것이다.

 

ㅇ  보고서 작성의 핵심은 내용이 아니라 속도다. 얼마나 빨리 작업할 수 있느냐에 따라 보고서의 내용도 달라진다. 결국 SW 개발을 포함하여 지식 산업은 무엇을, 어떻게, 왜 할 것인지에 대한 생각을 정리하는 것이 핵심이다. 지식 산업에서는 속도가 품질을 결정한다.

 

ㅇ 범위와 입출력이 명확한 프로스세는 통제가 가능하며 이렇게 프로세스를 제어하는 방법론이 제어이론이다.....경험적 프로세스는 프로세스의 내부 행동을 알 수 없는 블랙박스 모델이다....

 

ㅇ 이론적 프로세스는 제어신호와 피드백 루프를 사용하여 제어할 수 있다. 그러나 SW 개발 프로세스는 이런 방법으로 제어할 수 없다. 왜냐하면 제어신호를 보낸다고 해서 제어신호대로 프로세스가 움직이지 않기 때문이다. 프로세스가 인간 중심으로 움직이기 때문이다.

 

ㅇ 실제 프로젝트에 개발 방법론이 하는 역할은 극히 미미하다.

 

ㅇ 나는 WBS를 작성할 때 프로젝트 팀이 프로젝트 성공 전략을 논의하는 것을 본 적이 없다. 또한 무엇을 구현할 것인가가 불분명한 상태에서 WBS를 작성하는 것도 이해할 수 없다. 그럼 왜 WBS 작성을 요청하는 것일까? 그것은 WBS를 사용하여 고객이 개발팀을 통제하려는 것이다......WBS가 작성된 다음 주부터 고객은 약속대로 작업을 하고 있는지 묻게 되고 개발팀은 일정 지연을 속이는 상황이 발생한다.

 

ㅇ WBS는 될 수 있으면 작성하지 않는 것이 좋다. WBS는 팀의 의욕을 떨어뜨린다. 작업 속도는 각 팀마다 고유한 것인데 WBS는 이것을 일정이라는 틀로 지시하려는 것이다.

 

ㅇ 일정을 작성하더라도 마일스톤만 정하되 한 달 이하로 작업을 쪼개서는 안 된다. WBS를 작성하더라도 팀 단위로만 작성.....WBS보다는 마일스톤

 

ㅇ 프로젝트 계획서도 고객이 경영층에게 과시하기 위한 용도로 사용된다.....핵심 사항은 프로젝트를 어떻게 진행할 것인가에 대한 PM과 프로젝트 팀원들 간의 합의다. 프로젝트 팀원들은 프로젝트가 어떤 순서로 어떻게 진행될 것인지를 분명히 알고 있어야 한다. 이것이 합의되지 않으면 프로젝트 계획서를 작성 완료한 후 프로젝트 팀원들은 무엇을 할 것인지 다시 고민하게 된다.

 

 

ㅇ  조직에서의 개인과 조직을 벗어난 개인은 분리해서 보아야 한다.... 고객사의 IT관리자가 고의로 프로젝트를 지연시키는 것이 아니다. 고객사의 조직 구조가 그런 행동을 원하기 때문이다.

 

ㅇ 조직에서 어떤 개인이 벌이는 행동은 조직 안에서 개인의 위치, 조직의 분위기와 목표, 개인의 경험이 복합적으로 작용한 결과다.

 

ㅇ 조직은 조직 대 조직이 해결해야 할 문제를 특정 개인에게 떠넘긴다는 것이다. 그것도 제일 권한이 없는 사람에게 떠넘긴다.

 

ㅇ 좋은 조직이란 문제를 조직 차원에서 해결하는 조직이고, 나쁜 조직이란 조직의 문제를 개인에게 떠넘기는 조직이다. 고객과의 모든 문제는 조직 차원에서 대응해야 한다. 고객과의 문제를 프로젝트 팀에서 해결하려고 하니 문제가 발생하는 것이다.

 

ㅇ 모든 조직의 목표는 살아남는 것이다.

    모든 조직은 자신을 유지하고 생존시키려는 속성이 있다...

    모든 조직은 권력구조상 상위로 올라가려 한다....

    모든 조직은 확대하려는 속성이 있다

    모든 조직은 다른 조직의 간섭을 받지 않고 문제를 해결하려고 한다.

    모든 조직은 조직의 커지면 조직의 문제를 조직 재정비를 통해 해결하려는

    경향이 있다.

    모든 조직의 권력자의 관심은 자신의 권력을 유지하고 행사하는 것이다.

    권력자는 이런 권력 행사를 방해하는 모든 것을 싫어하며 제거하려 한다.

 

ㅇ 경영진에게 프로젝트의 문제에 대한 올바른 해결책을 제시했을 때 경영진이 거부한다면 이유는 간단하다. 이런 해결책은 경영진의 권력 유지에 도움이 되지 않기 때문이다.

 

ㅇ 감독자는 문제 해결자가 아니다.....감독자는 자신이 개발을 할 줄 알거나 기술적인 내용을 잘 안다는 것을 부인한다. 왜냐하며 인정하는 순간 감독자에서 문제 해결자로 바뀌기 때문이다.....감독자...감리사가 문제 해결책을 제시하는 경우는 드물다. 감리사의 목표는 개발팀을 의심하고 거짓말을 폭로하는 것이다.

 

ㅇ 개발팀은 현재의 상황을 판단하여 자신의 자원을 가장 필요한 곳에 투입하려고 한다. 그러나 감독자는 지금 표준을 준수하는가가 더 중요한 문제이다. 감독작는 현재 프로젝트의 상황이 무엇인지 알려 하지 않는다.

 

ㅇ 현재의 상황에서 최선의 답을 내놓는 사람은 개발팀이고 개발팀이 상황을 누구보다 잘 알고 있기 때문이며 결국 프로젝트의 책임은 개발팀에게 있기 때문이다.

 

ㅇ  나는 현재의 대응책이 최선의 대응책이라고 늘 믿는다.

 

ㅇ 지원업무를 하는 동안에는 다음과 같은 원칙을 세웠다..."내가 하지 못할 일을 남에게 강요하지 말자!"' ...프로젝트 팀은 권한은 없으나 책임은 무한하다. 이런 상황에서는 품질관리, 개발 방법론, 심지어 테스트 등의 짐을 덜어 주는 것이 오히려 개발 프로젝트를 도와주는 길이다....역설적이지만...개발 프로젝트를 지원하기 위해 만들어진 도구들(감리, 개발 방법론 등)이 오히려 개발 프로젝트를 감시하는 도구로 쓰이게 된 것이다.

 

ㅇ 권력은 무엇을 하기 위한 수단일 뿐이다. 권력이 없다면 우리는 아무 일도 할 수 없다. 권력은 나쁜 것도 좋은 것도 아니며 우리가 일을 가장 빠르고 효과적으로 수행하기 위한 수단일 뿐이다.

 

ㅇ 프로젝트는 일을 마무리하는 것이 목적이기 때문에 일을 마무리 할 수 있다고 인정되는 사람이 권력을 획득하게 된다.

 

ㅇ 권력을 얻기 위해서는 권력을 행사할 수 있는 사람의 신임을 얻어야 한다......나는 권위나 학력, 자격증을 내세우는 사람이 프로젝트에서 권력을 얻는 경우를 보지 못했다. 프로젝트에서는 사람들이 실제로 필요로 하는 것을 줄 수 있는 사람이 권력을 얻는다.

 

ㅇ 권력은 상호적이다. 내가 줄 수 있는 것이 없다면 상대방도 나를 필요로 하지 않게 되고 나는 권력을 획득할 수 없게 딘다. 권력은 결코 공포나 카리스마에서 나오는 것이 아니다....권력을 획득하기 위해서는 내가 사람들에게 중요한 무언가를 줄 수 있는 사람이 되어야 한다. 최소한 사람들이 이 사람이 필요하다는 것을 인식키켜야 한다. 그래서 프로젝트에서는 학문적인 권력이나 학력이 통하지 않는다.

 

ㅇ 일을 할 때는 내가 다음 기회에 권력을 행사하는데 도움이 되는 부분을 뽑아서 내 것으로 만드는 데 신경을 써야 한다......권력의 방향과 이해득실을 철저히 따져서 일 해야 한다.

 

ㅇ 간섭을 받지 않으려면,,,,빠르게 일하고 확실한 결과물을 내놓음으로써 관리자에게 인정받아야 한다. 관리자에게 인정받아야 하는 더 중요한 이유는 간섭을 받지 않게되기 때문이다.

 

ㅇ 간섭받지 않는 시간을 늘려야 한다. 이렇게 해야 스스로의 생산성을 검토하고 최적화할 수 있다.

 

ㅇ  사람을 잘 이해하게 되면서 두려움이 극복되었다. 인간의 불안감, 나약함 등 사람의 내면을 파악하면서 사람은 두려워할 존재가 아니라 도와주고, 격려해줘야 할 존재라는 것을 알게 되었다.

 

ㅇ  굳건한 신념이나 편견은 같은 것이다. 프로젝트에서는 이런 신념을 가진 사람이 가장 위험하다. '우리는 해 낼 수 있다.' '우리는 반드시 성공할 것이다.' 이런 믿음을 가진 사람이 프로젝트를 망가뜨린다. 프로젝트에서는 냉정하게 실패할 가능성을 계산하고 대안을 세우는 사람이 필요하다. 즉 프로젝트에서는 부정적인 사고 방식을 가진 사람이 필요하다.

 

ㅇ  아키텍트는 기술 총괄이라고 볼 수 있으며 아키텍트가 되기 위해서는 SW, 시스템, 네트워크, 보안, DB 및 고객의 요구사항까지 총체적으로 볼 수 잇는 능력이 있어야 한다.....프로젝트를 진행할 능력도 있어야 하고 SW공학은 필수적으로 배워야 한다.....프로젝트 스케줄링에 대한 지식도 있어야 하고 고객의 업무를 파악하고 정리할 수 있는 모델링 및 문서화 능력도 있어야 한다....개발 프로세스를 이해하는 능력도 있어야 하고 팀원들을 파악하는 인간 이해에 대한 능력도 있어야 한다.

 

ㅇ  프로젝트에서 제일 말썽을 많이 일으키는 사람들은 자신의 전문성을 고집하는 ㅏ람들이다.

 

ㅇ  우리는 프로그램을 잘 다루는 법을 가르치는 것이 아니라 방법론을 가르친다. 우리는 장인이 되고 싶어 하는 사람들에게 표준을 가르쳐서 일 잘하는 노동자로 만들려 고 한다.....다행히 현재는 리팩터링과 테스트 주도 개발이라는 기술로 개발자들을 훈련시킬 수 있다.

 

ㅇ 나는 대화하는 법이라든지 팀장되는 법 같은 책들을 믿지 않는다. 이런 기술들을 배운다고 사람을 잘 다룰 수 있는 것이 아니다. 사람이 무엇을 원하는 지 알면 사람과의 문제는 쉽게 해결될 수 있다.

 

ㅇ 자본주의 사회에서 우리는 강박관념, 불안, 초조에 시달린다. 그래서 나는 자본주의 사회와 정신병은 깊은 관련이 있다는 것을 알게 되었다.

 

ㅇ  SW산업을 우리가 제어하지 못하고 제어당한다면 산업적으로도 우리는 일개 노동자에 불과해 버린다. SW산업은 정신노동이기 때문에 정신적인 활력, 즐거움만이 이 산업을 제어할 수 있다. 즉 나의 자아되 되찾고 일도 의미가 있어야 새로운 제품도 생산해 낼 수 있다...... SW산업은 제조업처럼 누군가 기획해서는 만들 수 없다. ....SW 산업 종사자들이 이에 재미를 느껴야 새로운 제품도 나오고 시장도 활기를 띨 것이다. 개발자들이 자신의 삶을 되찾는 것은 그래서 개인적으로 뿐만 아니라 산업적으로도 매우 중요하다.

 

ㅇ 먼저 권력을 획득해야 한다. 우리가 조직에서 권력을 장악할 수 있어야 우리에게 자유가 주어진다. 이 권력을 우리에게 주어진 일의 성공으로 이어지게 하기 위해서 권력을 팀에 행사할 수 있어야 한다. 우리는 조직과 팀 앞에서는 대담하게 행동해야 한다. 한편 SW 앞에서는 겸손해야 한다.

 

ㅇ 내가 관리자라면 가혹할 정도로 팀원을 몰아붙여서 일을 줄 수 도 있어야 한다. 그래야 팀원들의 생산성도 향상되고 다음에 더 어려운 일을 쉽게 해 낼 수 있다. 때때로 팀원들이 지독한 관리자, 피도 눈물도 없는 매정한 사람이라고 얘기하는 경우가 있더라도 그 정도는 되어야 관리자로서 능력을 갖춘 것이다.

 

ㅇ 너무 바쁘면 일 자체에 대해 생각할 시간이 없다. 일을 할 때, 그 일을 꼭 해야 하는지, 한다면 어떻게 해야 하는지 가장 최선의 방법을 모색하는 습관을 들여야 일을 잘한다고 할 수 있다.

 

ㅇ 새로운 과학적 진리는 그 반대자들을 납득시키고 그들을 이해시킴으로써 승리를 거두기보다는, 오히려 그 반대자들이 결국에 가서 죽고 그것에 익숙한 세대가 성장하기 때문에 승리하게 되는 것이다.

 

ㅇ 우선 광범위한 인문학적 소양을 쌓아야 한다. 실용적인 기법이나 측면을 강조하는 리더십, 자기계발, 경제경영 서적들이나 에세이식 심리학 서적들은 우리에게 빗나간 선입견을 심어줄 우려가 있다...고전을 읽어라..

 

ㅇ 1961년 밀그램 실험.....권위에 대한 복종에 대한 실험.....사람들이 파괴적인 복종에 굴복하는 이유가 성격보다 상황에 있다고 믿고, 굉장히 설득력 있는 상황이 생기면 아무리 이성적인 사람이라도 윤리적, 도덕적인 규칙을 무시하고 명령에 따라 잔혹한 행위를 저지를 수 있다고 주장했다..

 

ㅇ 아무도 자신에게 줄 수 없으며 아무도 자신에게서 빼앗을 수 없는 것- 만이 자신이 소유한 재산이며, 타인에게 어떻게 평가되고 있는가하는 문제보다 휠신 본질적인 것이다. - 쇼펜하우어..