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

[ 밑줄/연결 ]

프로젝트는 늘 비정상적이라고 생각하고 해결책을 찾는 것이 나을 것이다.

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

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

분산 실시간 컴퓨팅 방식은 계산 아키텍처 상으로는 가장 구현하기 어려운 방식이다.

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

SW를 담는 그릇은 결국 우리의 생각인데 우리의 생각이 구멍이 있고 계속 바뀌니 SW를 문서로 규정하려는 노력이 소용 없어지는 것이다.

문제의 영역은 유일할 뿐 아니라 인간적인 영역이며 기계는 엄격한 물리적인 영역이다. SW는 두 영역 사이에 존재한다.

우리가 대상으로 하는 것이 자연현상이 아닌 비즈니스라는 것이 문제이다. 비즈니스에서 정해진 규칙을 발견하기는 어렵다.
---> 훌륭한 지적이다. 이걸 알면서도 우리는 계속 단순한 법칙이라는 허상을 찾아 헤맨다.

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

분류 문제는 데이터 모델링에서는 정규화라고 불리고 프로세스 모델링에서는 프로세스 계층이라고 부른다. SW 아키텍처에서는 View라고 불리며, 코딩에서는 함수, procedure, 오퍼레이션이라고 부른다.

엔트로피 증가 때문에 SW 유지보수라는 작업이 필요하다. SW 엔트로피 증가 현상에 더하여 유지보수를 한층 어렵게 하는 것이 바로 이 분류 문제다.

나는 유지보수가 SW의 가장 핵심적인 업무라고 본다. 왜냐하면 SW는 엔트로피 증가, 분류 문제, 도메인의 유동성 등으로 개발이 완료되자마자 빠르게 불완전해지기 때문이다.

SW가 발전하기 위해서는 공학적인 기법보다 도메인 지식이 공유되어야 한다. 도메인 지식이 공유되면 도메인을 어느 정도 표준화하거나 참고하는 것이 가능하다.

한국에서 PM, PL, 개발자 등의 전문성이 급격히 떨어지는 이유는 한국의 전산 시스템이 유행에 민감하기 때문이다.
---> 2021년 7월, 개나소나 '메타버스'를 한다고, 해야 한다고 난리다.
---> 가상화폐에 난리더니 또, 대한민국에 냄비근성 지랄병(??)이 생기는 구나 싶다.

어떤 문제를 해결하는 방식은 가정하고 시도하고 다시 가정하고 시도하는 방식이지 정의하고 분석하는 방식이 아니다. 정의하고 분석하는 일은 문제가 해결된 후 해결한 문제를 설명할 때 어떤 일관성을 부여하기 위해 하는 것이다.

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

아키텍처는 개별적인 구성요소들을 조합했을 때 어떤 문제가 발생하는지에 관심을 둔다.

시스템의 구성요소 사이의 관계는 특정 담당자가 책임질 수 없으며 시스템을 만드는 팀 전체의 책임이 된다.

빌과 매릴런이 작업했던 이유는 이렇게 작업하는 것이 팀의 표준 절차였기 때문이다.

대개 전문가를 자처하는 사람이나 조직에서 자기를 과시하기 좋아하는 사람들은 자신이 판단할 수 없는 결과를 받으면 입을 다물어 버린다.

프로젝트 팀이 일시적으로 조직되어 단기간에 성과 내기를 기대해서는 안 된다.

자기계발 서적이 이런 함정에 빠져 있다. 탁월한 성취를 이룬 팀이나 사람들이 갖춘 조건은 결과일 뿐이지 성취의 원인이 아니다. 그 조건을 일부러 가지려고 노력한다고 되는 것이 아니다.

오히려 행동이 변해야 사고가 변한다.....따라서 팀의 일원으로 행동하도록 행동의 변화를 추구해야 한다.

도스토예프스키는 "인간에게 자유를 준다면 인간은 그 자유를 견딜 수 없다."고 지적했다.

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

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

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

내가 하지 못할 일을 남에게 강요하지 말라.

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

잘 못 짜인 프로젝트는 이미 어떤 몸부림을 쳐도 실패가 예상되어 있습니다. 그걸 바로 잡겠다는 것은 헛된 일입니다.

[ 자평 ] 탁월한 정리와 생각이다. 이 분, 왜 책을 또 쓰지 않는지, 10년 후 얼마나 내공이 더 생겼는지 궁금하다.

자기 책이 꼭 읽어 봐야 할 책이라고, 있는 인맥 없는 인맥 다 동원해서 떠드는 사람이 있다.

심지어 어떤 사람은 '성숙한 삶'을 위해서 자기 책을 읽어야 한다고, 스스로를 '구루'라고 말하며 주접(?)을 떠는사람도 있다. 참으로 자기계발, 자기홍보만 있고 자기수신, 자기관조, 자기겸손이 사라진 시대다.

이 책은 2011년에 나온 책이다. 벌써 10년도 넘은 책이 되었다.
읽을 당시에도 충격적이었고, IT분야 책인데도 10년 후 다시 읽어도 배울 점이 역시 살아 있다.

이렇듯 책 한권을 냈을 뿐인데, 또 한권을 내줬으면 하는 저자가 있다.
이 책의 저자인 '이종국'님, 얼핏 또 기억이 나는 분은 '나는 먼지인가'를 쓰신 '이동기'님