From 349ca788fa848e4a6f4df2039141b3624b084500 Mon Sep 17 00:00:00 2001
From: Jeongan Lee <84510455+fkdl0048@users.noreply.github.com>
Date: Fri, 12 Jan 2024 21:17:10 +0900
Subject: [PATCH] Docs:
 2024/ThePsychologyOfComputerProgramming/Jeonglee/Chapter01.md

---
 .../Jeonglee/Chapter01.md                     | 381 ++++++++++++++++++
 1 file changed, 381 insertions(+)
 create mode 100644 2024/ThePsychologyOfComputerProgramming/Jeonglee/Chapter01.md

diff --git a/2024/ThePsychologyOfComputerProgramming/Jeonglee/Chapter01.md b/2024/ThePsychologyOfComputerProgramming/Jeonglee/Chapter01.md
new file mode 100644
index 00000000..fe4f6a5d
--- /dev/null
+++ b/2024/ThePsychologyOfComputerProgramming/Jeonglee/Chapter01.md
@@ -0,0 +1,381 @@
+## 1부 인간 행위로 보는 프로그래밍
+
+> 중요한 것은 질문을 멈추지 않는 것이다.  
+> 호기심에는 그 나름의 존재 이유가 있다.  
+> 영원과 인생 그리고 신비한 현실의 구조가 주는 불가사의를 생각해 보면 우리는 경외심을 느낄 수밖에 없다.  
+> 이러한 불가사의를 매일 조금씩 이해하려고 노력하는 것만으로 충분하다.  
+> 절대로 신성한 호기심을 잃지 말라.  
+> : 아인슈타인
+
+컴퓨터 프로그래밍은 인간의 행위다.
+
+수년에 걸쳐 경영자들은 자신의 사업에서 프로그래머라는 요소를 배제하기 위해 막대한 자금을 솓아 부었다.
+
+### 1장 프로그램 읽기
+
+- 왜 경영자가 프로그램을 읽을 수 있어야 하는가?
+
+프로그래머로써 자신이 맡은 업무가 아니더라도 프로그램을 읽는 것은 프로그래밍을 배운다는 의미에서 그다지 나쁜 일은 아니다.
+
+과거엔 프로그래밍 환경이 좋지 못했기 때문에 실습뿐만 아니라 학습(읽기)을 통해서도 능력을 길렀다.
+
+하지만 시대가 변함에 따라 컴퓨터와 씨름하느라 균형이 무너진다.
+
+프로그래머라면 다른 사람의 프로그램을 읽어서 뭔가를 얻을 수 있다.
+
+나쁜 예제라면 반면교사로 좋은 예제라면 프로그램의 흐름을 알거나 자신이 모르고 있는 부분을 명확하게 알 수 있을 것이다.
+
+*글쓰기에서도 badcase를 참고하는게 좋을 수 있다고 한다.*
+
+프로그램을 읽을 때 각 부분의 발단으로 구성된 개념적인 프레임워크를 토대로 읽어야 한다.
+
+즉, 코드를 한 줄 만날 때마다 "이 코드가 왜 여기에 있을까?"를 생각하는 것이다.
+
+문서화되지 않고 당시에 상황을 해결하기 위해 작성된 프로그램은 큰 단점이다.
+
+#### 기계의 한계
+
+다른 협업자(미래의 나)가 오용하거나 이를 한계로 인식하지 않고 단점을 사실로 인정해버리는 경향이 있다.
+
+#### 언어적인 한계
+
+언어의 한계로는 하이 레벨 언어를 사용하다 보면 하드웨어의 특정 기능을 사용할 수 없게 된다는 점이 있다.
+
+언어적인 한계로 필요 이상의 제약이 발생하고 이 때문에 코드의 덩치는 커진다.
+
+그러나 이런 제약이 사라지기 전까지 제약으로 인식되지 못할 수도 있다.
+
+*교외에 나가서야 도시의 공기가 혼탁했다는 사실을 깨닫게 되는 것처럼 말이다.*
+
+따라서 언어가 생겨남에 따라 현재에는 인식하지 못하는 새로운 한계가 드러날 수도 있다.
+
+#### 프로그래머의 한계
+
+프로그래머는 사용하는 컴퓨터와 언어, 프로그래밍에 대한 지식에 대한 부족으로 많은 코드를 쓸데없이 추가할 수 있다.
+
+특정 알고리즘에 대해 모르거나, 충분히 이해할 능력이 안 될 수도 있다.
+
+#### 역사의 흔적
+
+해당 프로그램의 개발 역사 때문에 여전히 존재하는 문제점들을 발견하는 경우도 있다.
+
+#### 명세
+
+명세는 프로그램, 프로그래머와 함께 진화한다.
+
+프로그램을 작성하는 것은 일종의 학습이다.
+
+**프로그램이 하는 일이 우리가 그 프로그램에게 원했던 바로 그것이길 바란다.** (프로그램은 동작헤야 한다.)
+
+#### 요약
+
+어떤 프로그램이 현재의 모습을 갖게 된 데에는 다 이유가 있다.
+
+코드를 세심히 읽기보다는 그저 훑기만 하기 때문에 그 이유를 모두 알아차릴 수는 없겠지만 읽다보면 기계, 언어, 프로그래머의 한계로 그런 모습이 되었거나 혹은 당시에 존재했던 외부 조건(사건), 주어진 명세 때문에 그렇게 작성되었음을 알 수 있다.
+
+최종 산출물에 포함된 코드에는 각각 나름의 이유가 있고, 그 이유에는 심리적인 면이 있다.
+
+- 콘웨이의 법칙
+
+#### 논의사항
+
+- 작업중인 프로젝트나 회사 코드 말고 다른 외부의 달인, 전문가가 작성한 코드를 많이 참고하시는 편인가요?
+
+### 2장 좋은 프로그램이란 무엇인가?
+
+프로그래밍을 인간의 행위로 연구하기 위해선 능률을 측정할 방법이 필요하다. (어떤 프로그래머가 우수한지)
+
+프로그래밍은 단순한 인간의 행위가 아니라 복잡한 인간의 행위이기 때문에 답을 도출하기 까다롭다.
+
+좋은 프로그램을 평가할 때 코드 자체만으로 좋다 나쁘다를 논할 수 없다.
+
+보편적인 좋은 프로그래밍은 개개인의 사상으로 존재할 수 있지만, 사실이라고 해도 좋은 프로그램의 존재를 말할 수 없다.
+
+즉, 프로그램을 개발하며 일어난 주변 환경과 실행 환경을 전혀 고려하지 않은 채 프로그램의 점수를 딱 정할 수 없다는 것
+
+프로그램 평가 기준에서 그 프로그램이 실행될 기계와 컴파일러, 비용 환경 등을 고려하지 않을 수 없다.
+
+프로그램 개발은 계획한 기간 안에 끝냈는가?, 개발 비용이 얼마나 들었는가? 주어진 환경 명세서를 만족 시키는 가 등등
+
+단지 코드만 보고서는 이런 요소를 알 수 없다.
+
+*상대적인 척도도 불가능하다.*
+
+최고의 프로그램은 동작하며 명서세에 부합하는 프로그램이다.
+
+#### 요구 명세
+
+프로그램에 요구하는 조건 중 가장 먼저 꼽히는 것은 정확성이다.
+
+프로그램이 작동하지 않는 상황에서 효율성이나 적응성, 개발 비용 등의 다른 척도는 전혀 의미가 없다.
+
+**세상에 완벽한 프로그램은 절대 없다.**
+
+따라서 프로그램이 주어진 요구 명세를 얼마나 만족시키느냐 즉, 얼마나 잘 작동하느냐가 문제가 되는 것이다.
+
+사용자 한 명을 위한 프로그램과 **진정한 소프트웨어** 사이에는 엄연한 차이가 있다.
+
+사용자가 여럿이면 요구 명세도 여러 벌이 된다.
+
+#### 일정
+
+요구 명세를 만족시키는가의 문제를 차지한다 해도 효율성이 최우선의 문제가 되지 않는다.
+
+프로그래밍에서 계속 반복되는 문제는 일정을 맞추는 일이다. (마라톤)
+
+개발 기간 중 크런치가 위험한 이유
+
+#### 적응성
+
+대다수의 프로그램들은 일정 기간 동안 생명을 유지한다.
+
+그리고 그 생명 주기 동안 대부분의 프로그램은 **수정**을 겪는다.
+
+그렇다면 왜 사람들은 원래 작성된 코드를 버리고 처음부터 몽땅 새로 작성해야겠다고 결정하는 상황이 많은 것일까?
+
+- 피셔의 기본정리
+  - 한 유전자 시스템이 특정 환경에 많이 적응되어 있을수록 다른 새로운 환경에 적응하기는 더 어렵다.
+
+프로그램이 효율적으로 동작하게 만들려면 주어진 문제와 프로그램을 실행할 기계의 특성을 잘 활용해야 한다.
+
+기계의 구조를 무시하면 프로그램은 잠재적으로 성능 면에서 큰 손해를 보게 되고, 문제의 특성을 잘 활용하면 프로그램을 더 작고 빠르게 만들 수 있다.
+
+효율성을 추구하면 보통은 코드가 빡빡해져서 수정하기 어렵게 된다.
+
+고수준 언어로 작업하다가 프로그램을 좀 더 효율적으로 만들려고 기계어로 내려가는 일도 가끔 있다.
+
+이는 프로그램을 고수준 언어로 작성하는 이점 중 하나를 포기하는 것이다.
+
+그리고 그렇게 하면 특정 기계에 얽매일 뿐 아니라, 당시의 만족스럽지 못한 프로그램 구현 상태에도 종속되는 것이다.
+
+거꾸로, 일반적이고 수정하기 쉬운 프로그램을 요구하는 관리자들도 나중에는 프로그램이 느리거나 너무 크다고 불평하곤 한다.
+
+우리는 이 사이에서 균형잡기를 해야 한다.
+
+#### 효율성
+
+프로그램의 진정한 효율성은 언뜻 생각하기와 달리 쉽게 측정할 수 없다.
+
+일단, 컴퓨터에서 실행시키는 데 필요한시간만이 효율성의 전부가 아니다.
+
+실행 전후에 드는 시간이 컴퓨터의 실행 시간에 영향을 미칠 수 있다.
+
+언어의 사소한 차이로도 컴파일러의 효율성은 크게 달라질 수 있다.
+
+컴퓨터가 소비하는 시간만이 비용의 모든 요소인 것은 아니다.
+
+사람이 소비하는 시간도 비용이다.
+
+*여기서 트레이드 오프 발생 앞서 다른 고수준 언어와 저수준 언어 그리고 효율성 측면의 생각*
+
+단순히 컴퓨터상의 실행 시간만 줄인다고 능사는 아닌 것이다.
+
+결론적으로 컴퓨팅에서 효율성은 점점 더 애매해지고 있다.
+
+현대에는 언어가 더 고수준에 가까워짐에 따라 최적화는 좀 나중의 문제로 보인다.
+
+시간이 지날수록 효율성보다 효용성이 더 증가할 것이다.
+
+#### 요약
+
+좋은 프로그램이란 무엇인가라는 물음에 다음과 같이 답할 수 있다.
+
+- 프로그램이 동작하는가? (추가)
+- 프로그램이 요구 명세서에 부합하는가?
+- 일정에 맞춰 개발하였는가?
+- 환경이 변한다면 그에 맞춰 프로그램을 수정할 수 있는가?
+- 프로그램이 얼마나 효율적인가?
+
+코드의 품질을 평가하는 방법을 결정하는 새로운 요소 가운데 가장 큰 것은 경제적 요소이다.
+
+이는 게임업계에서도 많이 증명된다.
+
+실제 코드의 구조가 좋지 못하더라도 100만장을 판 인디게임이라면 성공한 게임이다.
+
+고객을 만족시키고 소프트웨어적으로 성공했기 때문이다. (게임은 상품)
+
+#### 논의사항
+
+- 스스로 생각하시는 프로그래머로서의 성공, 최종 목표는 어디인가요?
+
+### 3장 프로그래밍이란 행위를 연구할 방법은 무엇인가?
+
+앞서 지적한 바와 같이, 프로그래밍은 엄연히 인간 행위(복잡한)의 한 형태임에도 그런 관점에서 프로그래밍을 연구한 사람은 거의 없다.
+
+인간의 지식은 필연적으로 불완전하다.
+
+우리는 앞으로 무엇을 알게 될지 그리고 무엇을 절대 알 수 없을지를 미리 알지 못한다.
+
+그러나 이것 하나는 확실하다.
+
+**알려고 시도하지 않는다면 절대 알 수 없을 것이다.**
+
+> "중요한 것은 질문을 멈추지 않는 것이다."
+
+프로그래밍은 인간 행위이므로 인간행동학을 참고하는 것이 현명해 보인다.
+
+#### 내성법
+
+현대 인간행동학에서는 내성법을 비과학적인 것으로 취급하지만, 내성법은 인간행동 연구에서 항상 기초가 되어 왔다.
+
+내성법을 통해 프로그래밍에서 뭘 관찰할 수 있을까?
+
+예제와 같이 한 문장의 적절한 길이, 자료 구조의 선택, 프로그램 내 코드의 배치, 괄호의 사용, 컴파일러와 실행 모니터링 기능의 설계, 프로그래밍 교수법 또는 학습 기술 등등.
+
+모두 내성법 아니고서는 인지하기 힘든 문제다.
+
+그러나 프로그래머는 매일 부딪히는 이런 문제를 단순히 **버그**라고 생각한다.
+
+내성법을 실천하지 않는다면 그 버그는 결국 그들을 잡아먹을 것이다.
+
+- 사람의 정신은 중첩된 괄혼가 다섯 단계를 넘으면 다룰 수 없다.
+- 컴파일러의 진단 기능이 좀 더 명확해져야 한다.
+- PL/1의 정밀도 규칙은 너무 복잡해서 사용하기 어렵다.
+
+위 같은 명제를 내성법을 통해 써봤자 법칙이 될리 없다.
+
+어떤 명제가 법칙이 되기 위해서는 그 적용 한계가 어디인지까지 밝혀야 한다.
+
+모든 법칙에는 한계가 있기 때문이다.
+
+사실 보통 그 한계가 법칙 자체보다 더 중요하다.
+
+그리고 법칙의 적용 한계는 다양한 경우를 **조사**해야 알 수 있다.
+
+따라서 내성법 없이 조사한 결과는 빈약하겠지만, 조사가 뒷받침되지 않은 내성법의 결과는 그 가치를 의심받을 것이다.
+
+#### 관찰
+
+내성법의 결과를 검증하는 방법 가운데 사람들이 자신이 어떻게 행동할것이라 생각하느냐가 아닌 그들의 실제 행동을 관찰하는 방법이 있다.
+
+또는, 관찰의 결과로 새로운 논제가 생겨날 수도 있다.
+
+관찰의 두번 째 문제점은 관찰은 관찰일 뿐이라는 것이다.
+
+관찰을 할 때에는 매우 신중해야 한다. 프로그래밍은 극도로 복잡한 행위이기 때문이다. (각 상황은 여러 가지 면에서 차이가 있기 때문이다.)
+
+세번 째 문제점은 관찰자와 피관찰자 사이에 생기는 간섭 현상이다. (불확정성 원리의 일종이다.)
+
+그런 현상을 만드는 원인은 관찰 행위 그 자체였던 것이다.
+
+이런 현상을 설명하는 **호손 효과**라는 이론이 있다.
+
+*피험자들이 실험에 참가하고 있다는 사실을 의식해서 평소와 다른 행동을 함으로써 결과에 영향을 미치는 현상을 말한다.*
+
+관찰자와 피관찰자 사이의 간섭 현상은 비단 산업심리학에서만 일어나는 것은 아닌 인간의 행동을 연구하는 모든 과학 분야에서 문제가 된다.
+
+실제 관찰자들은 철저히 투명인간이되려고 노력하고 이를 통해 은밀하게 관찰한다.
+
+컴퓨터 분야에서 사용하는 은밀한 관찰법으로는 사용자의 행동을 컴퓨터를 통해 직접 기록하는 것이다.
+
+컴퓨터의 로그는 매우 자세한 수준까지 기록되기 때문에 그 자료를 통해 사용자 개개인까지도 연구할 수 있다. (통계)
+
+#### 실험
+
+관찰해서 생긴 자료가 지나치게 방대하기 때문에 소요되는 비용을 줄이는 방법 가운데 실험 설계가 있다.
+
+실험을 이용하면 더 적은 자료로도 연구하려는 행동에 관한 더 많은 정보를 얻을 수 있다.
+
+그러나 실험 내재하는 가장 큰 문제은 실험이 지나치게 정제되어 가장 흥미로운 자료를 얻는 데 실패할 수도 있는다는 점이다.
+
+너무 제약되어 피험자가 자연스러운 상황에서는 절대 하지 않을 행동을 할 수 있다.
+
+다른 문제로는 실제 배치 시스템과 다를 수 있다던가 비용적인 문제가 있을 수 있다.
+
+보통 프로그래밍을 사회적 행위가 아닌 개인 행위로 취급한다.
+
+그러나 프로그래밍에 관한 연구는 프로그래머 그룹 차원에서 행하는 것이 적절하다는 증거가 여럿 있다.
+
+개인 차원이 중요하지 않다는 뜻은 아니지만, 일반적인 프로그래머는 작업 시간 중 3분의 2를 다른 사람과 협업하는 데 소비한다.
+
+#### 심리학의 측정법
+
+"프로그래밍을 몇 년이나 했는지"를 경험을 측정하는 척도로 삼는 것은 프로그래밍 심리학을 연구할 때 부딪히는 많은 측정 문제 중 하나에 불과하다.
+
+인간의 행동을 관찰하거나 연구하는 과정에서 측정해야 할지도 모르는 항목이 수백만까지는 아니더라도 족히 수천 개는 된다.
+
+이러한 많은 항목이 문제가 된다. (아직 심리학, 인간행동학이 중분히 성숙하지 못했기 때문)
+
+그러나 인간의 행동을 연구할 때는 그렇게 단순하게 할 수가 없다.
+
+심리학의 주제는 측정할 수 있는 것으로 정하는 게 아니라 알고 싶은 것으로 정한다. (따라서 가능한 많은 요소를 측정)
+
+그 중 몇 개만이라도 주어진 문제를 꿰뚫는 통찰을 얻는 데 도움이 되길 바라면서 말이다.
+
+실제로, 태어난 달이나 계절이 어떤 심리적 또는 물리적 변수와 상관관계가 있다는 취지로 시작한 연구가 있다. (통계적 사주 관점)
+
+민간 지식은 통찰을 얻는 한 방편이 될 수 있다.
+
+또 다른 방편이 있다면, 현재 다른 목적을 위해 사용되는 수단을 빌리는 것이다. (IQ검사 등)
+
+그러나 가장 표준적인 과정은 역시 그 반대 방향이다. (문제에서 수단으로)
+
+연구 대상을 잘 알지 못한다면 무엇을 측정해야 할지 미리 알 수 없는 노릇이다.
+
+프로그래밍 심리학의 현재 수준에서는 질문을 찾는 것이 주된 작업이다.
+
+기존 심리학의 측정 수단들을 이용할 수 있다지만, 그렇다 해도 아직 그 수단들을 시험하는 것이지 주제를 직접 다루는 수준은 되지 않는다.
+
+*논외로 궁금해진 MBTI와 개발자간의 상관성이 궁금해져서 알아봤다. 실제로 조사하고 이를 통해 통계를 작성하는 경우가 많다. 한국에서도 다양한 글이 있지만 아마 외국에서는 실제로 이를 통해 통찰을 얻기도 할 것 같다. [관련글](https://blog.naver.com/1strider/222922640011)*
+
+*하지만, MBTI특성이 사람의 평균 수에 비례하지 않기 때문에 경향성을 보는 것이지 이를 통해 심리학의 문제를 해결할 수는 없는 것 같다.*
+
+- [상관성에 관한 글](https://github.com/fkdl0048/BookReview/blob/main/Growing_Up_Together/Chapter01.md#%EC%A7%81%EC%9B%90%EC%9D%84-%EB%BD%91%EC%9D%84-%EB%95%8C-%EB%AC%B4%EC%97%87%EC%9D%B4-%EA%B7%B8-%EC%82%AC%EB%9E%8C%EC%9D%98-%EC%8B%A4%EB%A0%A5%EC%9D%84-%EA%B0%80%EC%9E%A5-%EC%9E%98-%EC%98%88%EC%B8%A1%ED%95%A0%EA%B9%8C)
+
+인간의 행동을 연구한 선배 과학자들이 이미 경험했던 함정을 인지하지 못한 상태에서 얻은 측정을 가지고 성급하게 결론을 내는 것은 누구나 지양해야 할 일이다. (마치 갈릴레이의 사고 실험)
+
+#### 인간행동학의 기존 연구 자료 이용
+
+기존의 인간행동학 연구에서 우리가 배울 부분은 주로 그 방법론이다.
+
+프로그래밍은 매우 특수하므로, 그 결과를 프로그래밍 심리학에 그대로 적용하길 바라기는 어렵다.
+
+기존 연구 결과는 답을 얻기보다는 통찰을 얻는 데 이용해야 한다.
+
+너무 특화된 이론에는 현혹되지 않는 것이 좋다.
+
+프로그래밍에 해당하지 않는 상황을 전제로 한 이론이기 쉽기 때문이다.
+
+프로그래밍에는 올바른 해답이 없기 때문에 설사 있다고 해도 피험자보다 더 올바른 해답을 알고 있다는 보장은 없다.
+
+컴퓨터 프로그래밍에 대한 가장 유용하고 포괄적인 모델을 제시하는 사회 과학은 인류학이다.
+
+커뮤니케이션, 사회적 구조관계이다.
+
+확실히 프로그래밍 관련 분야에서 심리학적으로 가장 많이 활용될 수 있는 부분이 인간관계론쪽이라 생각된다.
+
+이런 개인적, 사회적인 측면 이후에는 프로그래머의 도구를 심리학적 관점에서 검토해야 한다.
+
+도구는 잃어버린 프로그래밍 문명을 이해하기 위해 발굴하고 연구해야 할 유물인 것이다.
+
+마지막으로 이런 논의를 모두 성공적으로 마치고 나면, 프로그래밍에 대한 신화적인 사회 통념과 신조를 충분히 객관적인 관점에서 고찰할 수 있을 것이다.
+
+#### 요약
+
+프로그래밍은 복잡다단한 행위이기 때문에 우리는 인간행동학에서 가능한 많은 방법론과 연구 결과를 차용할 필요가 있다.
+
+그러나 그 과정에서 함정에 빠질 우려가 있으므로, 프로그래밍 심리학을 직접 연구하려 할 때에는 통상적인 함정에 미리 대비해야 한다.
+
+**주요 문제점**
+
+- 검증 없이 내성법을 사용하는 것
+- 지나치게 한정된 대상을 관찰하는 것
+- 잘못된 변수를 측정하는 것 또는 옳은 변수를 측정하지 못하는 것
+- 관찰 대상의 행동에 개입하는 것
+- 자료는 과도하게 모으고도 정보는 충분히 얻지 못하는 것
+- 실험에 지나치게 많은 제약을 가하는 것
+- 과도하게 초보 프로그래머들만 연구 대상으로 삼는 것
+- 집단 효과와 집단 행동을 연구하지 못하는 것
+- 측정하기 쉬워서 측정하는 것
+- 검증 되지 않은 정밀도를 사용하는 것
+- 기존 연구의 결과를 적절치 못한 대상에 적용하는 것
+
+그러나 아직 미숙한 분야에서 일어나는 최대 실수는 바로 지나친 신중함이다.
+
+실험을 전혀 하지 않는 것보다 실험을 한 후에 실패하는 편이 더 낫다.
+
+> 아마도 프로그래밍은 연구 대상으로 삼기에 너무나 복잡한 행위이기 때문에 커다란 불가사의로 남을 수밖에 없었을 것이다.
+
+#### 논의사항
+
+- 자신만의 내성법을 통한 명제가 있을까요?