From 0f2b84a1bdd014757427d5d7d6c799670acda222 Mon Sep 17 00:00:00 2001
From: Jeongan Lee <84510455+fkdl0048@users.noreply.github.com>
Date: Sun, 21 Jan 2024 21:35:36 +0900
Subject: [PATCH] Docs: Add temp The Psychology of Computer Programming 02

---
 .../Chapter02.md                              | 274 ++++++++++++++++++
 1 file changed, 274 insertions(+)

diff --git a/The Psychology of Computer Programming/Chapter02.md b/The Psychology of Computer Programming/Chapter02.md
index 862ad12..94156ac 100644
--- a/The Psychology of Computer Programming/Chapter02.md	
+++ b/The Psychology of Computer Programming/Chapter02.md	
@@ -147,6 +147,280 @@ ex) 조언에 대해서 냉소적인 반응, 서로 협력하는 관계
 
 우리가 취하는 행동에서 상당 부분은 환경적인 영향을 많이 받기 때문에 프로그래밍 그룹에 새로 합류한 사람은 그 그룹의 철학에 맞춰 사회화된다.
 
+고위 관리자들이 비 자아적 프로그래밍 철학을 위협하는 경우도 종조 있다. (상업적 생각이 우선)
 
+- 그룹의 이전 사례
+  - 그룹(팀)은 덩어리다.
+  - 함께 일함으로써 얻는 성취감
 
+#### 요약
+
+프로그래머의 작업 환경은 복잡다단하며 인간관계와 그 변화 그리고 오해를 불러일으킬 만한 상황들로 가득 차있다.
+
+그 환경을 이해하라면, 공식적 구조와 비공식적 구조의 차이를 이해하고 물리적 환경에서 개인의 자아까지 환경에 영향을 미치는 다양한 요소들도 이해해야 한다.
+
+그리고 프로그래밍 환경에는 외부로부터 발생한 변화에 저항하는 자기보존성이 있다.
+
+특히, 그 변화가 공식적인 것과 비공식적인 것의 차이를 이해하지 못한 상태에서 이루어질 경우에는 더더욱 그렇다.
+
+이런 자기보존성은 모든 차원의 사회에 존재하는 현상이고, 본질적으로 좋지도 나쁘지도 않다.
+
+그저 프로그래밍의 현실일 뿐이다.
+
+#### 추가 (보태는 글)
+
+과거와 다르게 메일을 사용(지금은 메신저)한다.
+
+장점으로는 비가시성이 존재한다.
+
+3장의 생각 MBTI로 개발자들을 테스트내용
+
+#### 논의사항
+
+> 좋은 프로그램을 정의하기가 어렵다는 사실은 자치하고
+
+- 위 내용에서 스스로 생각하시는 열등한(Badcase)에 대한 논의는 저번에 다뤘는데 이번엔 책에서 말하는 '좋은 프로그램'을 정의하기 어려운 이유에 대해서 논의해보면 좋을 것 같습니다.
+
+### 5장 프로그래 팀
+
+**개발하려는 시스템의 크기가 클수록 프로그래밍 경험 부족이 더 여실하게 드러나기 마련이다.**
+
+**이상적으로는** 프로그래머들이 사소한 문제라도 결코 **혼자** 작업하지 않는다고 보았지만, 작은 프로그램과 큰 프로그램은 사회적 측면에서 서로 차이가 있다.
+
+어떤 한 명이 그룹 전체의 작업을 목표와 일반 체계부터 아주 작은 코드의 세부 사항까지 숙지할 수 있다면 프로그래밍 작업을 통합할 필요는 없다. (인간 문서)
+
+프로그램을 서로 모두 이해하고 있는 상태에서 함께 개발하는 두 프로그래머의 상호 작용과 한 사람이 맡기엔 너무 커서 프로그램을 둘로 나눠 작업하는 두 프로그래머의 상호 작용은 전혀 다르다.
+
+특히 요구사항의 충돌이 해소되는 방식이 다르다.
+
+전자의 경우에는 한 사람의 사고 과정 즉, 가끔 다른 이의 도움을 받기도 하지만 늘 스스로가 통제하는 사고 과정을 통해 충돌이 해소된다.
+
+반면 후자는 기술적인 요구사항이 충돌이 대인 관계의 갈등으로 번질 가능성이 있으며, 이 문제를 해결하기 위해서는 사회적인 장치를 갖추어야 한다.
+
+#### 팀을 어떻게 조직할 것인가
+
+한 사람이 감당할 수 없는 업무 요구사항을 만족시키려면 프로그래밍 팀을 조직해야 한다.
+
+그 필요성은 단순히 해야 할 작업의 요구 명세뿐만 아니라 그 일에 필요한 사람들의 능력과 할당될 시간과도 관련되어 있다.
+
+그 2가지 요소 즉, 팀 구성원의 능력과 가용 시간에는 작업을 수행하는 데 요구되는 최소치가 있다.
+
+예를 들어 어떤 프로그래밍 작업은 팀 크기가 아무리 크다 해도 초보자들만으로는 불가능하기 때문에, 경제에서 말하는 인력을 두 배로 늘려도 전혀 소용이 없을 것이다.
+
+개념상, 목적한 시스템을 개발하는 데 필요한 최소의 전문 기술과 최소의 시간이 있다.
+
+그러나 이 수치들은 정확하게 정의하기 어려울 뿐 아니라 프로그래밍에서 추정은 항상 불확실성이 개입되기 때문에, 관리자는 상식적으로 봤을 때 계획된 시간 내에 주어진 업무를 절대 수행할 수 없는 팀을 구성하곤 한다.
+
+십중팔구, 이런 팀은 마감 시한이 닥쳐 현실을 직시해야만 하는 상황이 되어서야 일정 연기를 요청한다.
+
+현실을 좀 더 일찍 깨달았더라면, 일정이 길어짐을 고려해 그에 맞춰 작업을 다르게 계획할 수 있었을 테고, 결국 일을 더 빨리 마칠 수 있었을 텐데 말이다.
+
+너무나 흔히 목격되는 이런 상황으로부터 능력과 일정 간의 상호 보완 관계를 알 수 있다.
+
+최단 일정은 오로지 최고의 팀을 프로젝트에 투입할 때에만 달성 가능하며, 팀의 인원을 최소로 투입하려면 프로젝트 일정이 늦어짐을 각오해야 한다.
+
+다시 말해서 프로그래밍 기술이 다소 부족하다 해도 일정을 연장해 줄 여유가 있고 능력이 최저 수준 이하만 아니라면, 어떤 프로그램이든 만들어 낼 수 있다.
+
+또 일정과 작업 진척 간의 중요한 관계도 알 수 있다. (파킨스의 법칙)
+
+*파킨스의 법칙이란 주어진 시간을 다 채울 때까지 작업을 지연시킨다.*
+
+파킨스의 법칙도 경계해야 할 대상이긴 하지만, **너무 빠듯한 일정을 핑계로 위험한 지름길을 택하는 것도 피해야 한다.**
+
+지름길을 통해도 시스템을 제 시간 내에 성공적으로 가동시킬 수 있을지도 모른다.
+
+반면에, 일정에 착오가 생길 가능성에 대비하려 한다면 팀에 정원 외 인력을 충원해야 한다.
+
+**그러나 작업을 더 많은 사람이 분담할수록 전체 작업의 통합이 더 어려워진다는 점을 고려해야 한다.**
+
+어림잡아, 프로그래머 3명으로 구성된 팀은 작업을 통합하는 데 소요되는 시간 때문에 동등한 능력을 지닌 프로그래머 한 명이 할 일의 2배 밖에 하지 못한다.
+
+더 나아가, 각각 프로그래머 3명으로 이뤄진 팀 3개는 마찬가지 이유로 팀 하나가 할 일의 2배, 또는 프로그래머 한 명이 할 일의 4배밖에 할 수 없다.
+
+따라서 프로그래머 한 명이 8달 안에 마칠 수 있는 프로젝트에 3명을 투입하면 4달만에, 9명을 투입하면 2달만에 끝낼 수 있다.
+
+*더 뛰어난 프로그래머도 있지만, PM의 역할도 중요하다고 생각된다.*
+
+**최소의 비용으로 최고의 프로그래밍을 원한다면, 가능한 한 최고의 프로그래머를 구하고 그들에게 최소한의 인원으로도 문제가 없을 만큼 충분한 시간을 주어야 한다.**
+
+이것이 프로그래밍 팀의 크기와 구성에 대해 언제나 통용되는 기본 원칙이다.
+
+일을 더 빨리 해야 하거나 덜 숙련된 사람들과 일해야 한다면 비용과 불확실성이 더 증가하게 된다.
+
+*최악의 방식은 초보자들만 고용한 뒤 스트레스만 주고 감독은 하지 않으면서 일을 시키는 것이다.*
+
+경험이 없는 프로그래머는 반드시 훈련이 필요하고, 미숙하더라도 팀에 포함시켜 업무 구조 자체를 생산과 훈련으로 변경해야 한다.
+
+프로그래밍 팀을 조직하는 방식을 결정하는 데는 목표 시스템의 구조와 팀의 구성이라는 두 가지 요소가 강력한 영향을 미친다.
+
+시스템의 구조에 접근하는 방식은 다양할 수 있는 데 반해 그 일에 투입할 수 있는 프로그래머들은 한정된 경우가 많기 때문에, 팀 구성원 개개인이 지닌 강점과 약점을 잘 살릴 수 있는 조직 구조로 선택하는 경우가 많다.
+
+*콘웨이의 법칙*
+
+이상적인 방향은 프로그램 구조를 먼저 계획하고 그 작업을 가장 잘 수행할 수 있는 사람들을 모으는 것이 옳은 순서다.
+
+그러나 재능 있는 프로그래머가 부족하기 때문에 현실적으로 그렇게 하기 힘들다.
+
+가장 중요한 요인 중 하나가 바로 **누가 누구의 작업을 비판하는가**이다.
+
+따라서 비자아적 프로그래밍을 실천한다면 팀원이 모두 언젠가는 모든 동료의 업무를 자세히 검토할 수 있는 기회를 갖게 되므로 조직의 계층성이 강해지는 것을 막을 수 있다.
+
+프로그래밍에서 팀원의 지위는 대체로 다른 사람들이 그의 능력을 어떻게 평가하는가에 큰 영향을 받는다.
+
+**서로 작업을 검토하면서 팀원에 대한 평가가 전체적으로 공유되면, 실력자가 윗자리로 올라가는 속도가 빨라진다.**
+
+다른 한편으로, 어떤 업무를 맡느냐에 따라 지위를 얻을 수도 혹은 잃을 수도 있다.
+
+#### 목표의 수립과 합의
+
+어떤 팀원이 사소한 업무를 할당 받아서 감정이 상한다면 팀 전체에 매우 나쁜 영향을 줄 수 있다.
+
+반면에 비자아적 프로그래밍을 실천하면, 프로그래머 각자가 전체 시스템에 대해 자기 나름의 몫을 하고 있다고 느끼게 되므로 그런 감정이 한층 완화된다.
+
+그렇다 해도, 팀이 프로젝트의 구조와 업무 분배에 대한 완전한 합의를 이끌어내기 전에 너무 성급하게 일을 시작한다면 어떤 형태로든 문제가 발생할 것이다.
+
+사회 심리학자들은 맥락은 좀 다르지만, **한 명 이상의 구성원이 그룹의 목표를 공유하지 못하면 그룹 전체의 업무 효율에 악영향을 미친다는 사실을 증명했다.**
+
+**목표를 공유하지 못하면 단지 그 구성원 한 사람의 문제로 끝나지 않고, 다른 구성원들이 그룹 내의 분열이나 일부 동료의 무관심한 태도를 피부로 느낄 수밖에 없기 때문에 업무 능률이 떨어지게 된다는 것이다.**
+
+프로그래밍 작업을 편견 없이 평가하는 데 꼭 필요한 건전한 논쟁을 억누르는 그릇된 합의와 팀의 생산적 활동을 원활하게 하는 팀의 목표에 관한 합의는 전혀 다르다는 것이다.
+
+그룹의 목표에 대한 진정한 합의를 얻기 위해서는 그 그룹이 목표를 직접 설정하도록 하는 것이 가장 좋은 방법이다.
+
+- 목표를 한층 분명하게 이해할 수 있다.
+- 목표 설정에 참여한 각 구성원은 그룹의 목표를 실현할 것을 공개적으로 약속한 셈이 되고, 그렇게 공개적으로 약속한 사람은 인지부조화 현상으로 인해 목표를 더 잘 인정하고 받아들이게 된다.
+
+그러나 무엇보다도 참여 자체가 다른 요소들과는 완전히 독립적으로, 어떤 개인이 진정으로 팀의 실제 목표를 인정하여 그만큼의 생산성 향상을 보일지 여부를 결정하는 중요한 요인인 것으로 보인다.
+
+팀원들이 협력을 통해 세부사항을 결정해야 하지만, 고위 관리자가 정의하려 한다면 팀원들은 단순 코더로 느껴질 수 밖에 없다.
+
+*프로그래머는 단순히 무엇을만이 아니라 왜인지도 알고 싶어한다.*
+
+프로그래밍 팀이 특정 시스템을 제작하는 일이 아니고 다른 프로그래밍 그룹에게 어떤 서비스 또는 지원 함수를 제공하는 일을 하는 경우, 분명하지 않은 목표의 문제는 한층 더 심각해진다.
+
+그러나 주 업무가 지원인 그룹은 끊임없이 자신이 맡은 바를 되새기지 않으면 더 구체적이지만 덜 생산적인 방향으로 흘러버릴 위험이 크다.
+
+사소한 논쟁이라도 쉽게 무시해서는 안된다.
+
+#### 팀 리더십과 팀 리더
+
+프로그래머의 리더는 강압적이거나 원칙적이면 안된다.
+
+사회학자들이 업무 집단의 만족도에 영향을 끼치는 요인들을 다음과 같이 크게 4가지로 분류했다.
+
+- 물질적인 보상과 기회
+- 일 자체가 불러일으키는 의욕과 흥미
+- 조직 전반의 일반적인 조건들 (근로자 복지, 근무 환경, 비슷한 조직들 사이의 상대적인 위치)
+- 관리자의 리더의 능력
+
+*과거와 다르게 이직율이 높은 지금은 성장을 좀 더 높게볼 것 같다.*
+
+프로그래머는 창조적인 사고와 전문 느력을 중요시하는 사람으로, 자신의 분야인 프로그래밍에 뛰어나다고 판단되는 사람을 신뢰하고 높이 평가하는 경향이 있다.
+
+리더가 할 수 있는 최악의 행동은 다른 팀원들과 프로그래밍 지식을 겨루려고 하는 것이다.
+
+**민주적인 집단에서 리더십은 한 사람에게 국한되지 않고 당시의 요구에 들어맞는 능력이나 생각을 소유한 구성원에게 계속 옮겨 다닌다.**
+
+그러나 사람이 모두 평등하게 태어날지 몰라도 똑같지는 않는다.
+
+따라서 민주적인 팀의 리더십도 절대 균등하고 나눠지지 않으며, 어떤 팀원은 상대적으로 많은 리더십을 행사한다.
+
+외부의 영향을 받지 않고 내부의 현실 상황에 맞춰 리더십이 정해지는 것이다. (계속 바뀌는 리더)
+
+하지만 적절한 리더를 찾을 수 있는가라는 측면에서 보면 어떤 프로그래밍 팀도 완벽하게 민주적일 수는 없다.
+
+우선, 팀 내에 적합한 인물이 없을 수도 있다.
+
+두번째로, 인성의 문제가 당면한 상황에 적절한 리더를 선택하는 데에 걸림돌이 될 수도 있다.
+
+마지막으로, 외부로부터 리더가 임명되어 들어오면 반드시 그 집단은 민주주의에서 멀어지게 된다.
+
+팀 리더가 반드시 명심해야 할 사항은 다음과 같다.
+
+- 경영자가 약속 이행을 아무리 강하게 요구한다 해도, 진정으로 원하는 것은 결과물 자체다.
+- 팀 전체가 참여하여 설정한 목표를 추구한다면 결과물을 훨씬 더 쉽게 얻을 수 있다.
+
+*외부에서 온 리더라도 위 사항을 잘 지킨다면 지배력을 지도력으로 대체할 수 있다.*
+
+리더로서 자신감이 있다면, 언제든 물러날 준비가 되어 있는 리더만이 진정한 성공의 열쇠를 쥐고 있다.
+
+#### 팀의 위기
+
+팀의 생명 주기는 팀원 고용을 시작으로, 목표를 설정하고 업무에 맞춰 내부를 조직하는 과정을 거쳐, 결국 업무가 완료되거나 새로운 목표를 받아들일 때 해산됨으로써 끝을 맺는다.
+
+편의상 팀 활동은 두 가지 범주 즉, 팀 목표를 성취하려고 수행하는 일과 위기가 닥쳤을 때 팀을 효율적으로 유지하고 관리하고자 행하는 일로 나누어 생각할 수 있다.
+
+사회 심리학에서는 이런 활동들을 각각 업무 지향적 그리고 관리 지향적이라고 부른다.
+
+민주적으로 조직된 팀은 승진, 사직, 병, 죽음, 임신, 출가 등 어떤 이유로든 구성원을 잃을 때 받는 충격을 잘 견디는 경향이 있다.
+
+팀원끼리 공유와 의사소통이 활발하기 때문에 업무에 대한 이해도가 높을 수 밖에 없다.
+
+하지만 새로운 구성원에 대해서는 받아들이기 힘든 것으로 알려져 있다.
+
+*이미 팀원끼리 강한 결합도를 가지고 있었기 때문에 (인간 문서와 같이) 이런 관계를 다시 맺는 것이 어려울 것이다.*
+
+반대로 권위적인 팀의 구성원들은 새로 온 사람에게 아주 친절하고 호의적인 반면, 민주적으로 조직된 팀은 다소 냉정하고 비우호적인 모습으로 비춰지곤 한다.
+
+모든 일을 오로지 단 한 사람의 리더가 조직하고 관리할 정도로 권위적인 성향이 강한 팀에서는, 구성원 중 하나가 이탈하여 생긴 구멍이 그대로 방치된다.
+
+오직 리더만이 남은 구성원들에게 일을 다시 분배하는 데 필요한 정보를 쥐고 있다.
+
+민주적인 집단에서는 철저하게 무능력한 구성원보다 유능하지만 다른 사람들과 잘 어울리지 못하는 구성원이 훨씬 더 심각한 문제가 될 수 있다.
+
+권위적인 집단이라면 구조적으로 무능력한 구성원이 업무에 관해 다른 사람들과 접촉할 기회가 많지 않을 것이다.
+
+따라서 리더와 원만하게 지내는 한 특별히 문제가 되지 않는다.
+
+수동적인 직원일수록 강력한 중앙 집권적 리더 아래에서 일하기를 선호하고, 능동적인 직원일수록 민주적인 리더에서 일하길 선호하는 것 같다.
+
+팀의 위기가 반드시 특정 개인과 연관되는 것이 아닌 발전 단계나 외부 환경의 변화에 의해서도 발생할 수 있다.
+
+일반적으로 팀의 조직 형성은 냉동실에서 얼음을 얼릴 때와 같이 아래쪽에서 위쪽으로 그리고 위쪽에서 아래쪽으로 동시에 진행된다.
+
+한 팀에 강력한 리더의 소질을 지닌 사람이 두 명 있다면, 위쪽으로부터 팀이 형성되는 과정이 오랫동안 진행되지 못하고 질질 끄는 경우가 있다. (비생산적이지만, 분리하면 해결)
+
+어떤 사람이 리더의 자질이 강한 사람인지는 팀에 주어진 작업 요구에 따라 다르다.
+
+*앞서 말한 기본적인 룰을 지킨 상태에서 리더는 계속 변경될 수 있어야 함.*
+
+집단 행동에 관한 보편적인 사회심리학 연구 결과 중에서 특히 다음 두가지는 위기로 점철된 프로그래밍 팀을 정확히 설명한다.
+
+- 위기 시에 비교적 강력한 리더십을 행사하려는 시도는 구성원들이 비교적 거부감없이 받아들인다.
+- 그러나 그와 동시에 그 자칭 리더가 집단의 문제에 대하 효과적인 해결책을 빨리 내놓지 못하면 나머지 사람들은 느긋하게 지켜보지 못하고 금세 조바심을 낸다.
+
+이러한 이유 때문에 민주적인, 기술주의적인 조직이 왜 프로그래밍 팀에 그토록 딱 맞는 조직 형태인지 알 수 있을 것이다.
+
+따라서 프로그래머를 뽑을 때 끊임없이 변하는 구조에 적합한 사람 즉, 너무 지배적이지도 너무 수동적이지도 않은 사람을 찾아야 한다.
+
+또, 프로그래머를 훈련시킬 때에는 유능한 리더를 어떻게 따라야 하는지 그리고 스스로 집단 내에서 리더로 가장 적입자일 때 어떻게 그 기회를 잡아야 하는지를 가르쳐야 한다.
+
+외부세력은 이러한 민주적인 활동에 간섭하지 않아야 한다.
+
+현명한 관리자라면 팀이 발족되어 활동을 시작하고 난 후에는 팀의 내부 구조와 그 변화에 관해 일종의 **무간섭** 정책을 펼칠 것이다.
+
+#### 요약
+
+대부분의 상황에서 프로그래밍의 가장 중요한 작업 단위는 팀이지 개인이 아니다.
+
+#### 보태는 글
+
+> 한 사람이 감당할 수 없는 업무 요구사항을 만족시키려면 프로그래밍 팀을 조직해야 한다.
+
+현대에는 업무 요구사항이란 용어를 좀 더 넓게 해석하여 팀과 팀원의 능력 개발을 포함하는 개념이라고 생각한다.
+
+#### 논의사항
+
+> 사회학자들이 업무 집단의 만족도에 영향을 끼치는 요인들을 다음과 같이 크게 4가지로 분류했다.
+
+- 물질적인 보상과 기회
+- 일 자체가 불러일으키는 의욕과 흥미
+- 조직 전반의 일반적인 조건들 (근로자 복지, 근무 환경, 비슷한 조직들 사이의 상대적인 위치)
+- 관리자의 리더의 능력
+
+과거와 다르게 이직률이 높아진 지금 여러 요인이 생기도, 우선순위가 달라지도 한 것 같습니다.
+
+우선순위와 추가할 만한 요인에 대해서 논의해보고 싶습니다.
+
+### 6장 프로그래밍 프로젝트