From b4d508bb85ca9dee8ee313657df58cc7acf5bc71 Mon Sep 17 00:00:00 2001
From: karnelll <165611407+karnelll@users.noreply.github.com>
Date: Wed, 11 Sep 2024 22:39:39 +0900
Subject: [PATCH 1/8] =?UTF-8?q?Create=20=EC=B5=9C=EC=84=9C=ED=9D=AC.md?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .../\354\265\234\354\204\234\355\235\254.md"  | 59 +++++++++++++++++++
 1 file changed, 59 insertions(+)
 create mode 100644 "1\354\236\245/\354\265\234\354\204\234\355\235\254.md"

diff --git "a/1\354\236\245/\354\265\234\354\204\234\355\235\254.md" "b/1\354\236\245/\354\265\234\354\204\234\355\235\254.md"
new file mode 100644
index 0000000..8b83093
--- /dev/null
+++ "b/1\354\236\245/\354\265\234\354\204\234\355\235\254.md"
@@ -0,0 +1,59 @@
+# Book Review
+
+## 📖 Book Information
+- **Title**: 함께 자라기 애자일로 가는 길
+- **Author**: 김창준 지음
+- **Publisher**: 인사이트 
+
+---
+
+## 📝 Review Outline (1장. 자라기)
+
+### 1. 중요하다고 생각한 내용 (Key Takeaways)
+
+- **야생 학습**  
+  학교에서 배운 전통적인 학습 방식과는 달리, 야생 학습은 협력적이고 비순차적이다. 제한된 자료나 명확한 평가 기준도 없고, 정답도 없다. 목표는 불분명할 수 있고 변화도 잦다. 이는 학습이 더 자유롭고 유연하게 이루어질 수 있는 환경을 의미한다.
+
+- **의도적 수련**  
+  자신의 기량을 발전시키기 위해 의도적으로 훈련하는 과정이다. 작업의 난이도가 자신의 실력과 적절히 맞아야 몰입을 경험할 수 있다. 반복된 수련을 통해 최고 수준의 집중력과 학습 능력을 발휘할 수 있다. 특히 단순한 작업이라도 난이도를 조절하여 자기만의 방법을 개발하는 것이 중요하다.
+
+- **회고**  
+  자기 성찰과 회고는 시간이 지날수록 복리 효과를 일으킨다. 성장을 위한 꾸준한 성찰과 회고는 자신을 계속해서 발전시킬 수 있는 중요한 습관이다.
+
+- **부트스트래핑**  
+  외부의 도움 없이 스스로 문제를 해결하고 상황을 개선해나가는 과정이다. 작은 변화에서 시작해 점진적으로 자신을 둘러싼 환경과 도구를 개선해 나가며 학습의 효율성을 높인다.
+
+- **학습 프레임**  
+  학습 프레임은 '잘하기'가 아닌 '자라기'에 초점을 맞춘다. 주어진 과업을 통해 내가 무엇을 배우고 있는지에 초점을 맞추는 방식으로 접근하면, 더 나은 학습과 성장이 가능해진다.
+
+- **협력**  
+  혼자서 모든 것을 처리할 수 있는 환경이 더 이상 축복이 아니다. 오히려 협력을 통해 암묵지와 직관을 배우고 수련하는 과정이 중요하다. 현대 사회에서 사람과 인공지능, 혹은 팀과 팀 간의 협력이 핵심적인 경쟁력이 될 수 있다.
+
+- **달인이 되는 2가지 비결**  
+  첫째는 실력을 발전시키려는 동기, 둘째는 적절한 시기에 구체적인 피드백을 받는 것이다. 단순한 반복이 아닌, 동기 부여와 피드백이 있어야만 진정한 달인으로 거듭날 수 있다.
+
+- **알아차림**  
+  메타인지 전략이라고도 불리며, 자신의 감정 상태와 상황을 인지하고 이를 통해 필요한 조치를 반복적으로 취하는 과정을 의미한다.
+
+- **실수 관리**  
+  실수는 누구나 겪는 것이므로, 중요한 것은 이를 빠르게 인지하고 고치는 것이다. 전문가에게 실수 대처법을 배우고, 실수를 통해 배울 수 있는 기회로 삼는 것이 학습을 더욱 촉진시킨다.
+
+- **사회적 자본과 사회적 기술**  
+  마이크로 인터랙션에 신경 써야 한다. 인사, 짧은 대화, 간단한 질문과 같은 일상적인 상호작용이 중요한 사회적 자본을 형성하는 데 큰 역할을 한다.
+
+### 2. 경험적인 내용 (Personal Experience)
+
+1장을 읽으며 공감한 부분 중 가장 인상 깊었던 것은 **회고**에 관한 내용이었다. 전공의 특성상 여러 팀 프로젝트를 경험하면서, 성공적이지 못했던 프로젝트와 성공적인 프로젝트를 되돌아보게 되었고, 그 과정에서 팀 협업의 효과적인 점과 부족했던 점을 분석하게 되었다. 이를 바탕으로 프로젝트를 개선하려는 노력이 반복될수록, 이러한 회고 과정은 매번 나를 성장시키는 중요한 밑거름이 되었다.
+
+특히 첫 번째 개발 프로젝트에서 겪은 팀원 간의 소통 부족 문제는 큰 어려움으로 다가왔다. 소통이 원활하지 않으니 업무 효율이 떨어지고 문제 해결에도 시간이 오래 걸렸다. 이를 계기로 소통의 중요성을 절실히 느꼈고, 이후 프로젝트에서는 디스코드, 카카오톡과 더불어 노션을 활용하여 의견을 체계적으로 공유할 수 있도록 했다. 이 덕분에 팀 내 커뮤니케이션이 개선되어 문제 해결이 더 효율적으로 이루어졌고, 팀 분위기도 자연스럽게 좋아졌다. 이 경험을 통해 협업에서 **소통의 중요성**을 다시 한 번 깨닫게 되었다.
+
+### 3. 이해가 되지 않는 내용 (Unclear or Confusing Concepts)
+
+특정 내용이 이해되지 않거나 혼란스러운 부분은 없었으며, 저자가 제시한 다양한 개념들이 명확하게 설명되어 있어 읽는 동안 큰 어려움 없이 내용을 받아들일 수 있었다.
+
+---
+
+## 💬 Conclusion
+
+- **총평**:  
+  저자는 자신의 생각을 다양한 연구 사례와 개인적인 경험을 바탕으로 설명하여 독자가 편안하게 읽을 수 있도록 했다. 이러한 구체적인 예시들은 나의 경험과 연결되면서 많은 부분에서 공감할 수 있었고, "나만 이렇게 생각한 것이 아니구나"라는 생각이 들며 흥미롭게 1장을 읽어나갔다. 특히 내가 경험하며 고민했던 부분들에 대해 저자가 제공하는 근거와 설명이 명확하여, 내 생각과 경험을 뒷받침해주는 느낌이 들어 매우 유익했다.

From bd02350728bbb7caec4f7c7d0db04f76d4ce4811 Mon Sep 17 00:00:00 2001
From: karnelll <165611407+karnelll@users.noreply.github.com>
Date: Thu, 12 Sep 2024 22:51:28 +0900
Subject: [PATCH 2/8] =?UTF-8?q?Create=201=EC=9E=A5=20=EC=84=9C=EA=B8=B0?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 "1\354\236\245/\354\204\234\352\270\260" | 75 ++++++++++++++++++++++++
 1 file changed, 75 insertions(+)
 create mode 100644 "1\354\236\245/\354\204\234\352\270\260"

diff --git "a/1\354\236\245/\354\204\234\352\270\260" "b/1\354\236\245/\354\204\234\352\270\260"
new file mode 100644
index 0000000..948ed5b
--- /dev/null
+++ "b/1\354\236\245/\354\204\234\352\270\260"
@@ -0,0 +1,75 @@
+# 1장 서기
+
+---
+
+## **예영님**
+
+책의 문구와 통계를 보고 자극을 받아 자기계발에 신경을 써야겠다는 생각이 들었습니다.
+대학교에 입학하고 처음 개발을 시작할 때, 야생학습보다 순차적인 학습을 했던 것이 실패로 이어졌던 경험이 있습니다. 미리 알았다면 좋았을 것 같다는 생각이 들었습니다.
+'의도적 출현법'에도 깊이 공감했습니다. 하지만 즉각적인 피드백을 받는 것이 현실적으로 어려울 것 같다고 생각했습니다.
+"잘하려고 하기보다 성장해야 한다"는 메시지가 큰 위로가 되었다.
+협상과 설득 역량 부분에서는 평소 추상적으로만 생각했던 것을 작가가 직설적으로 설명해줘서 좋았습니다.
+다만, '부트스트래핑' 부분이 다소 추상적이었는데, 관련 예시가 있었으면 좋았을 것 같다는 생각이 들었습니다.
+
+---
+
+## **은학님**
+
+"강한 놈이 오래 가는 것이 아니라, 오래 가는 놈이 강하다"라는 문장이 가장 인상 깊었습니다.
+최근 데이터 분석을 하면서 단순히 분석에만 집중하기보다, 왜 데이터를 만들고 가공했는지 그 의미에 대해 생각하는 것이 중요하다고 느꼈습니다.
+팀 협업에서 피드백이 중요하다고 생각했는데, 책에서 이를 골프에 비유한 설명이 인상적이었습니다.
+취업 준비 과정에서 하나의 프로젝트를 깊이 파는 것이 좋다는 말에 깊이 공감했습니다.
+뛰어난 개발자는 협업을 많이 언급하지만, 실력이 부족한 개발자는 그러지 않는다는 점에도 동의했습니다.
+
+---
+
+## **연주님**
+
+책을 읽으면서 마치 좋은 멘토를 만난 것 같은 느낌을 받았습니다.
+가장 인상 깊었던 부분은 면접자 두 명의 답변이었는데, 한 명은 혼자 공부했고 다른 한 명은 다른 사람들과 함께 공부하며 성장했다는 이야기가 기억에 남는다.
+이를 통해 실력이 부족한 것을 부끄러워하지 않고, 다른 사람들과 함께 성장해 나가야겠다고 결심했습니다.
+전문가는 능력뿐 아니라 사회적 기술과 자본이 중요하다는 점에 공감했습니다.
+결과보다는 성장을 중시해야 한다는 깨달음을 얻었고, 실제로 피드백의 중요성을 깨달아 선배에게 피드백을 요청하게 되었습니다.
+
+---
+
+## **호영님**
+
+연주님과 마찬가지로 면접관 질문에 대한 내용에 크게 공감했습니다.
+개발자가 되면 혼자서가 아닌 조직에서 일하게 되는데, 조직에 맞지 않는 사람이 들어오면 뛰어난 사람이 나갈 수 있다는 점에서 깊이 생각하게 되었습니다.
+개발자와 소프트웨어 엔지니어의 차이에 대한 이야기를 읽으며, 동아리 프로젝트에서 항상 가이드라인에 맞춰 개발했지만, 더 다양한 기술을 찾아 개발했다면 더 많이 성장하지 않았을까 생각했습니다.
+좋은 코드는 초보자도 쉽게 이해할 수 있는 코드라고 생각합니다.
+
+---
+
+## **동준님**
+
+책을 통해 학습이 지혜로운 방법이라고 느껴 스터디에 참여하게 되었습니다.
+'야생학습'에 크게 공감했으며, 실제로 다양한 활동을 통해 많은 경험을 쌓을 수 있었다고 생각했습니다.
+자기계발을 하루에 1시간도 투자하지 않으면 직장에서 하위 1/3에 속한다는 말에 충격을 받았습니다.
+인공지능 시대에는 배우기 어려운 것에 집중해야 한다는 내용에 깊이 공감하며, 더 몰입해서 읽었습니다.
+실력과 직업의 난이도에 대해 새롭게 깨달으며 반성하게 되었습니다.
+
+---
+
+## **희수님**
+
+책을 읽으며 평소 어떤 프레임으로 일을 하고 있었는지 돌아보게 되었습니다.
+처음에는 학습 프레임으로 일을 했지만, 시간이 지나면서 실행 프레임으로 전환되었고, 그 결과 처음보다 얻는 것이 적었다고 느꼈습니다.
+‘왜 우리는 세수와 양치의 달인이 안될까요?’라는 내용에서 여러 가지 생각이 들었습니다. 
+‘꾸준히 해라. 하다 보면 는다.’는 말은 많이 들어봤겠지만, 그 말 속에는 ‘어떻게?’가 빠져있다는 것을 깨달았습니다. 실제로 친구들이 조언을 얻을 때 그러한 답변을 많이 했던 것 같습니다.
+"나는 열심히 했는데 왜 실력이 늘지 않았을까?"라는 의문을 갖기 전에 자기 점검이 필요하다고 생각하게 되었고, 앞으로는 질문을 더 똑똑하게 해야겠다고 다짐했습니다.
+
+---
+
+## **혜성님**
+
+'부트스트래핑'의 예시 두 가지:
+1. [Turbo Build 예시](https://turbo.build/repo/docs/guides/generating-code)
+2. 선호하는 eslint
+
+좋은 코드는 일관성이 높은 코드라고 생각합니다.
+
+다른 사람에게 물어보는 것은 정말 좋은 방법입니다. 실제로 만든 개발자에게 메일이나 깃허브를 통해 디테일하게 답변을 구하면 많은 도움이 된다고 생각합니다.
+
+책에서 말하는 적당한 난이도의 과제가 좋지만, 어려운 과제를 하면서도 성장할 수 있다는 의견에 동의합니다. 꼭 책의 내용에 완전히 동의하지 않아도 된다고 생각합니다.

From 2ed039fbbfc42ecc14dba93cf3c9c37b5a1a1d45 Mon Sep 17 00:00:00 2001
From: karnelll <165611407+karnelll@users.noreply.github.com>
Date: Thu, 19 Sep 2024 20:59:59 +0900
Subject: [PATCH 3/8] =?UTF-8?q?Create=20=EC=B5=9C=EC=84=9C=ED=9D=AC?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .../\354\265\234\354\204\234\355\235\254"     | 37 +++++++++++++++++++
 1 file changed, 37 insertions(+)
 create mode 100644 "2\354\236\245/\354\265\234\354\204\234\355\235\254"

diff --git "a/2\354\236\245/\354\265\234\354\204\234\355\235\254" "b/2\354\236\245/\354\265\234\354\204\234\355\235\254"
new file mode 100644
index 0000000..230e1f8
--- /dev/null
+++ "b/2\354\236\245/\354\265\234\354\204\234\355\235\254"
@@ -0,0 +1,37 @@
+# 📝 Review Outline (2장. 함께)
+
+## 1. 중요하다고 생각한 내용과 경험적인 내용
+
+- **“자신을 돌아보고 관리 방식 자체에 문제가 없는지 살펴보고 개선하는 것이 그 출발이 되지 않을까 합니다.”**  
+이 문장이 인상 깊었습니다. 저자는 비용 원인 범주의 순위를 **관리 > 시스템 > 사람 > 도구**로 설명하고 있습니다. 
+책을 읽기 전에는 좋은 도구를 사용할수록 일이 효율적으로 처리될 거라고 생각했지만, 도구를 통한 개선 효과는 3배에 그치고, **관리를 통해서는 64배**의 개선이 가능하다는 점에 놀랐습니다.  
+저 역시 그동안 비효율적인 회사 관리자들처럼 눈에 보이는 부분, 즉 쉽게 교체할 수 있는 도구에만 집중했던 것 같습니다. 하지만 앞으로는 **도구보다 관리**가 더 중요한 개선 요소라고 생각하게 되었습니다.
+
+- **“전산학은 추상화의 과학이다.”**  
+이 명언 또한 강렬하게 남았습니다. 저자는 소프트웨어 공학의 역사가 **추상화를 발전시키기 위한 과정**이었다고 말합니다. 특히, 추상화를 높이는 방법으로 **서로 다른 시각을 가진 사람들이 협력하는 것**을 제안했는데, 이 부분이 매우 흥미로웠습니다.  
+
+- **“의사결정을 하는 과정에서 감정적이고 직관적인 부분이 큰 역할을 하며, 그런 감정적 부분이 배제된다면 의사결정을 제대로 할 수 없다.”**  
+이 구절을 읽으며, 지금까지 제가 해왔던 의사결정 과정을 다시금 돌아보게 되었습니다. 저는 항상 **감정을 배제**하고 **이성적으로** 결정하려 노력해왔고, 대부분 그런 방식으로 결정했다고 믿어왔습니다.  
+그러나 책에서는 우리가 **감정과 이성이 섞여 있는 상태를 받아들이지 않으려 한다**고 지적합니다. 저 역시 이런 혼합 상태를 인정하지 않으려 했던 것 같습니다. 이제는 **감정과 이성의 상호작용**을 인정하고, 누군가를 설득할 때 **객관적 자료**를 제시하는 것보다 **상대방의 입장을 이해**하는 것부터 시작해야겠다고 다짐했습니다.
+
+- **“분석, 설계, 구현, 테스트, 전개를 1년이라는 프로젝트 기간 동안 어떻게 배치할지 고민하지 말고, 첫 달부터, 아니 첫 주부터 분석, 설계, 구현, 테스트, 전개를 모두 반복할 수 있도록 해야 한다.”**  
+이 부분에 많은 공감을 느꼈습니다. 저도 장기 계획을 단기 계획으로 나누어 실행했을 때, 작업 결과에 대한 검토와 개선을 반복함으로써 더 나은 성과를 얻었던 경험이 있습니다.  
+책에서 설명하는 것처럼 **사다리를 오르락내리락하듯** 작업을 반복해야 결과물의 품질이 향상된다는 말에 매우 공감이 갔고 동의했습니다.
+
+- **“속도가 빠른 팀은 도전 자체를 팀의 학습 능력에 대한 도전으로 받아들였고, 같이 학습해야 한다고 생각했습니다. 반면, 속도가 느리거나 낙오된 팀은 학습을 개인의 과제로 치부했습니다.”**
+이 내용에 공감하는 부분도 있지만, 팀워크에 지나치게 의존할 경우 **개인의 책임감**이 떨어질 수 있다고 생각합니다. 그래서 이 주제는 100% 이해하기는 어려웠습니다.
+하지만 이어지는 **“애자일은 좋은 일에 대해서는 '그리고' 확률을 '또는' 확률로 바꾸고, 나쁜 일에 대해서는 '또는' 확률을 '그리고' 확률로 바꾼다”**는 문장을 읽고, 팀원들과 **업무를 공유**함으로써 긍정적인 결과를 더욱 확실히 만들고, 부정적인 상황을 최소화할 수 있다는 의미로 어느 정도 이해할 수 있었습니다.
+
+
+## 2. 이해가 되지 않는 내용 (Unclear or Confusing Concepts)
+
+- 책에서는 **하나 공유**, **최고 공유**, **복수 공유**라는 세 가지 조건에 따라 **공유 전후의 신뢰**가 어떻게 변하는지 설명하고 있습니다. 아마 우리가 일반적으로 사용하는 공유 방식인 **하나 공유**나 **최고 공유**는 신뢰를 저하시킬 수 있다고 지적합니다.  
+그러나 저는 **최고 공유**가 신뢰를 저하할 수 있다는 것에 대해 동의하기 어려웠습니다. 왜냐하면 일을 마친 후 후련한 기분으로 피드백을 주고받는 과정에서 더 높은 신뢰를 쌓았던 경험이 있기 때문입니다.
+이 부분에 대해서는 다른 사람들의 의견을 듣고 싶습니다.
+
+## 3. Conclusion
+
+- **총평**:  
+  **“애자일은 좋은 일에 대해서는 '그리고' 확률을 '또는' 확률로 바꾸고, 나쁜 일에 대해서는 '또는' 확률을 '그리고' 확률로 바꾼다”**는 문장이 이번 2장을 요약하는 중요한 구절이라고 생각합니다.  
+  이 모든 내용을 한 단어로 표현한다면 **“공유”**일 것입니다. 저 역시 과거에 해결해야 할 일을 **공유하기보다는 혼자 처리하는 것이 더 효율적**이라고 생각하며, 종종 혼자서 일을 진행해왔습니다.  
+  그래서 이 문장을 통해 많은 깨달음을 얻을 수 있었습니다.

From 676cc256d19cd838f3021437f1abe2c7a43ba302 Mon Sep 17 00:00:00 2001
From: karnelll <165611407+karnelll@users.noreply.github.com>
Date: Thu, 19 Sep 2024 22:36:20 +0900
Subject: [PATCH 4/8] =?UTF-8?q?Update=20and=20rename=20=EC=B5=9C=EC=84=9C?=
 =?UTF-8?q?=ED=9D=AC=20to=20=EC=B5=9C=EC=84=9C=ED=9D=AC.md?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .../\354\265\234\354\204\234\355\235\254.md"                      | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename "2\354\236\245/\354\265\234\354\204\234\355\235\254" => "2\354\236\245/\354\265\234\354\204\234\355\235\254.md" (100%)

diff --git "a/2\354\236\245/\354\265\234\354\204\234\355\235\254" "b/2\354\236\245/\354\265\234\354\204\234\355\235\254.md"
similarity index 100%
rename from "2\354\236\245/\354\265\234\354\204\234\355\235\254"
rename to "2\354\236\245/\354\265\234\354\204\234\355\235\254.md"

From 32cadd5bc43fb306cb38ebb7ba9e0804328e4855 Mon Sep 17 00:00:00 2001
From: karnelll <165611407+karnelll@users.noreply.github.com>
Date: Thu, 19 Sep 2024 22:37:44 +0900
Subject: [PATCH 5/8] =?UTF-8?q?Rename=20=EC=84=9C=EA=B8=B0=20to=20?=
 =?UTF-8?q?=EC=84=9C=EA=B8=B0.md?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .../\354\204\234\352\270\260.md"                                  | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 rename "1\354\236\245/\354\204\234\352\270\260" => "1\354\236\245/\354\204\234\352\270\260.md" (100%)

diff --git "a/1\354\236\245/\354\204\234\352\270\260" "b/1\354\236\245/\354\204\234\352\270\260.md"
similarity index 100%
rename from "1\354\236\245/\354\204\234\352\270\260"
rename to "1\354\236\245/\354\204\234\352\270\260.md"

From 00752b16da9adbeec7eefaa26e4ef50c8ed317a1 Mon Sep 17 00:00:00 2001
From: karnelll <165611407+karnelll@users.noreply.github.com>
Date: Thu, 19 Sep 2024 23:16:03 +0900
Subject: [PATCH 6/8] =?UTF-8?q?Create=20=EC=84=9C=EA=B8=B0.md?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 "2\354\236\245/\354\204\234\352\270\260.md" | 88 +++++++++++++++++++++
 1 file changed, 88 insertions(+)
 create mode 100644 "2\354\236\245/\354\204\234\352\270\260.md"

diff --git "a/2\354\236\245/\354\204\234\352\270\260.md" "b/2\354\236\245/\354\204\234\352\270\260.md"
new file mode 100644
index 0000000..ec9bd66
--- /dev/null
+++ "b/2\354\236\245/\354\204\234\352\270\260.md"
@@ -0,0 +1,88 @@
+# 2장 서기
+
+---
+
+## **은학님**
+
+톱니바퀴 실험에 큰 감명을 받았습니다.  
+사수와 부사수 간 대화에서 첫 번째 대화는 극단적이었지만, 두 번째 대화에서는 더 나은 세 번째 대화가 있다는 점이 놀라웠습니다.  
+이번 프런트엔드 프로젝트 경험에서 짧은 기간으로 인해 후반부에 힘든 경험을 했습니다. 앞으로 프로젝트 초기부터 시간을 낭비하지 않고 어떤 부분에 중점을 둘지 논의하고 싶습니다.
+
+---
+
+## **연주님**
+
+"팀에 뛰어난 사람이 많다고 성공하는 것이 아니라, 정보 공유와 협력이 중요하다"는 내용에 깊이 공감했습니다.  
+과거에 개발 리드를 맡았을 때, 초반에는 협력을 강조했지만 되돌아보니 개인적으로 일을 처리했던 것 같습니다.  
+협력의 본질에 대해 고민하며, 앞으로는 소통과 공유를 통해 협력하는 방식으로 진행해야겠다는 깨달음을 얻었습니다. 하지만 현실적인 장애물로 인해 이를 실현하기 어려운 상황이 있다고 생각한다. 이에 대해 논의하고 싶습니다.
+
+---
+
+## **상호님**
+
+“도구 개선은 3배, 관리 개선은 64배의 효과를 낸다”는 문장에 놀랐습니다.  
+프로젝트를 진행하며 병목 현상은 없었지만, 발생할 경우 관리 방식을 되돌아봐야겠다고 생각했습니다.  
+또한, 하나 공유와 최고 공유가 오히려 신뢰도를 떨어뜨릴 수 있다는 점이 흥미로웠습니다. 설득에 대한 내용에서 많은 공감을 했으며, 인간에 대한 이해를 높이기 위해 더 많은 책을 읽어야겠다고 느꼈습니다.
+
+---
+
+## **호영님**
+
+함께 일하고 싶은 동료의 특성을 정리해봤습니다:  
+1. 질문을 잘하는 사람  
+2. 사회성이 좋은 사람  
+3. 자신의 의견을 잘 표현하는 사람  
+4. 의견을 잘 듣는 사람  
+5. A를 정확히 수행하는 사람  
+
+설득에 대한 내용을 읽고, 지금까지의 생각들이 객관적이었는지 의문이 들었고 많은 깨달음을 얻었습니다. 또한, "어려운 문제를 해결할 때 전문가는 계획을 수정하는 경우가 많다"는 점이 인상 깊었습니다.  
+현재 새로운 기술을 배우고 있는데, 책의 내용을 적용하여 목표 지향보다는 학습의 즐거움을 느끼며 학습해야겠다고 생각했습니다.
+
+---
+
+## **예영님**
+
+팀이 함께 사용하는 '시끄러운 공간'에 대해 깊이 공감했습니다.  
+프로젝트를 진행하며 혼자 일하는 것을 선호하는 팀원이 있어 이를 조율하는데 고민이 많았지만, 면대면 소통이 효율적이라는 점을 깨달았습니다.  
+개발에서 추상화는 이해가 되었지만, 협업에서 추상화가 다소 모호하게 다가왔습니다. 품질과 결함이 상대적이라는 점도 인상 깊었습니다.  
+설득에 대해 고민이 많았는데, 상대방의 중요성을 파악하고 선호하는 설명 방식을 이해하는 것이 중요하다는 것을 배웠습니다.  
+진행 상황을 공유하면서 시간을 절약한 경험이 있었으며, 실시간으로 정보를 효율적으로 공유하는 방법에 대해 논의하고 싶습니다.
+
+---
+
+## **희상님**
+
+과거 프로젝트에서 '내 파트만 열심히 만들면 되겠지'라는 생각으로 임했기 때문에 협력의 이점을 제대로 경험해본 적이 없었던 것 같습니다. 앞으로는 협력을 중점적으로 진행해봐야겠다고 느꼈습니다.  
+실수에 대한 두려움과 질문이나 의견 제시에 소극적이었던 태도를 반성하고 고치고자 합니다.  
+수평적 조직 구조에 대한 책의 내용은 동의하지만, 때로는 강압적인 부분도 필요하다고 생각합니다.  
+혜성님의 직장 생활에서 열심히 하지 않거나 이상한 팀원이 있었는지 궁금합니다.
+
+---
+
+## **혜성님**
+
+목표지향적인 사고를 하려고 노력하고 있으며, 현실적인 개발 가능성을 바탕으로 일을 진행하고 있습니다.
+예를 들어, 모든 팀원이 즉시 사용할 수 있는 기술 스택을 선택하고, 인터페이스도 팀원들과 함께 결정합니다. (ex. json-server)
+또한, 워터폴 방식을 최대한 줄이려 하고 있습니다.
+
+프로젝트의 목적에 따라 접근 방식이 달라질 수 있다고 생각합니다. 학생 시절의 프로젝트는 학습과 성장이 목표일 수 있지만, 직업으로서의 프로젝트는 사용자에게 가치를 전달하는 것이 최우선입니다. 더 많은 경험이 해결책이 될 수 있다고 생각합니다.
+
+추상화는 인간의 한계를 극복하기 위한 것이라고 생각합니다.
+
+### 추천 도서:
+- [구글 관련 책](https://product.kyobobook.co.kr/detail/S000061352347)  
+
+정보 공유의 경우 친밀한 관계가 많은 도움이 된다고 생각합니다. 또한 어떤 것을 물어볼 때 적절한 리소스를 활용하는 것도 중요한 센스라고 생각합니다. 예를 들어 하이퍼링크를 사용하는 것.
+
+주석을 활용하여 소통하는 것도 중요합니다. 코드 자체에 대한 설명보다는, 작성 의도에 대한 이유를 담은 주석이 더 바람직하다고 생각합니다.
+
+### 추천 도서 (주석):
+- 실용주의 프로그래머
+- 읽기 좋은 코드가 좋은 코드다
+
+"만약 조직에 적합하지 않은 사람이 채용되었다면, 그 사람의 문제가 아니라 채용 과정의 문제일 수 있다. 그 채용 과정을 점검해야 한다"는 말이 있습니다.
+
+또한 만약 열심히 하지 않는 팀원이 있다면, 동기 결여의 원인을 찾아 적절한 동기부여를 해야한다고 생각합니다.
+
+### 추천 도서 (설득:
+- 설득의 심리학

From ccb0d38b0b546ad939b5701861b878588cb08056 Mon Sep 17 00:00:00 2001
From: karnelll <165611407+karnelll@users.noreply.github.com>
Date: Thu, 19 Sep 2024 23:27:07 +0900
Subject: [PATCH 7/8] =?UTF-8?q?Delete=202=EC=9E=A5/=EC=B5=9C=EC=84=9C?=
 =?UTF-8?q?=ED=9D=AC.md?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 .../\354\265\234\354\204\234\355\235\254.md"  | 37 -------------------
 1 file changed, 37 deletions(-)
 delete mode 100644 "2\354\236\245/\354\265\234\354\204\234\355\235\254.md"

diff --git "a/2\354\236\245/\354\265\234\354\204\234\355\235\254.md" "b/2\354\236\245/\354\265\234\354\204\234\355\235\254.md"
deleted file mode 100644
index 230e1f8..0000000
--- "a/2\354\236\245/\354\265\234\354\204\234\355\235\254.md"
+++ /dev/null
@@ -1,37 +0,0 @@
-# 📝 Review Outline (2장. 함께)
-
-## 1. 중요하다고 생각한 내용과 경험적인 내용
-
-- **“자신을 돌아보고 관리 방식 자체에 문제가 없는지 살펴보고 개선하는 것이 그 출발이 되지 않을까 합니다.”**  
-이 문장이 인상 깊었습니다. 저자는 비용 원인 범주의 순위를 **관리 > 시스템 > 사람 > 도구**로 설명하고 있습니다. 
-책을 읽기 전에는 좋은 도구를 사용할수록 일이 효율적으로 처리될 거라고 생각했지만, 도구를 통한 개선 효과는 3배에 그치고, **관리를 통해서는 64배**의 개선이 가능하다는 점에 놀랐습니다.  
-저 역시 그동안 비효율적인 회사 관리자들처럼 눈에 보이는 부분, 즉 쉽게 교체할 수 있는 도구에만 집중했던 것 같습니다. 하지만 앞으로는 **도구보다 관리**가 더 중요한 개선 요소라고 생각하게 되었습니다.
-
-- **“전산학은 추상화의 과학이다.”**  
-이 명언 또한 강렬하게 남았습니다. 저자는 소프트웨어 공학의 역사가 **추상화를 발전시키기 위한 과정**이었다고 말합니다. 특히, 추상화를 높이는 방법으로 **서로 다른 시각을 가진 사람들이 협력하는 것**을 제안했는데, 이 부분이 매우 흥미로웠습니다.  
-
-- **“의사결정을 하는 과정에서 감정적이고 직관적인 부분이 큰 역할을 하며, 그런 감정적 부분이 배제된다면 의사결정을 제대로 할 수 없다.”**  
-이 구절을 읽으며, 지금까지 제가 해왔던 의사결정 과정을 다시금 돌아보게 되었습니다. 저는 항상 **감정을 배제**하고 **이성적으로** 결정하려 노력해왔고, 대부분 그런 방식으로 결정했다고 믿어왔습니다.  
-그러나 책에서는 우리가 **감정과 이성이 섞여 있는 상태를 받아들이지 않으려 한다**고 지적합니다. 저 역시 이런 혼합 상태를 인정하지 않으려 했던 것 같습니다. 이제는 **감정과 이성의 상호작용**을 인정하고, 누군가를 설득할 때 **객관적 자료**를 제시하는 것보다 **상대방의 입장을 이해**하는 것부터 시작해야겠다고 다짐했습니다.
-
-- **“분석, 설계, 구현, 테스트, 전개를 1년이라는 프로젝트 기간 동안 어떻게 배치할지 고민하지 말고, 첫 달부터, 아니 첫 주부터 분석, 설계, 구현, 테스트, 전개를 모두 반복할 수 있도록 해야 한다.”**  
-이 부분에 많은 공감을 느꼈습니다. 저도 장기 계획을 단기 계획으로 나누어 실행했을 때, 작업 결과에 대한 검토와 개선을 반복함으로써 더 나은 성과를 얻었던 경험이 있습니다.  
-책에서 설명하는 것처럼 **사다리를 오르락내리락하듯** 작업을 반복해야 결과물의 품질이 향상된다는 말에 매우 공감이 갔고 동의했습니다.
-
-- **“속도가 빠른 팀은 도전 자체를 팀의 학습 능력에 대한 도전으로 받아들였고, 같이 학습해야 한다고 생각했습니다. 반면, 속도가 느리거나 낙오된 팀은 학습을 개인의 과제로 치부했습니다.”**
-이 내용에 공감하는 부분도 있지만, 팀워크에 지나치게 의존할 경우 **개인의 책임감**이 떨어질 수 있다고 생각합니다. 그래서 이 주제는 100% 이해하기는 어려웠습니다.
-하지만 이어지는 **“애자일은 좋은 일에 대해서는 '그리고' 확률을 '또는' 확률로 바꾸고, 나쁜 일에 대해서는 '또는' 확률을 '그리고' 확률로 바꾼다”**는 문장을 읽고, 팀원들과 **업무를 공유**함으로써 긍정적인 결과를 더욱 확실히 만들고, 부정적인 상황을 최소화할 수 있다는 의미로 어느 정도 이해할 수 있었습니다.
-
-
-## 2. 이해가 되지 않는 내용 (Unclear or Confusing Concepts)
-
-- 책에서는 **하나 공유**, **최고 공유**, **복수 공유**라는 세 가지 조건에 따라 **공유 전후의 신뢰**가 어떻게 변하는지 설명하고 있습니다. 아마 우리가 일반적으로 사용하는 공유 방식인 **하나 공유**나 **최고 공유**는 신뢰를 저하시킬 수 있다고 지적합니다.  
-그러나 저는 **최고 공유**가 신뢰를 저하할 수 있다는 것에 대해 동의하기 어려웠습니다. 왜냐하면 일을 마친 후 후련한 기분으로 피드백을 주고받는 과정에서 더 높은 신뢰를 쌓았던 경험이 있기 때문입니다.
-이 부분에 대해서는 다른 사람들의 의견을 듣고 싶습니다.
-
-## 3. Conclusion
-
-- **총평**:  
-  **“애자일은 좋은 일에 대해서는 '그리고' 확률을 '또는' 확률로 바꾸고, 나쁜 일에 대해서는 '또는' 확률을 '그리고' 확률로 바꾼다”**는 문장이 이번 2장을 요약하는 중요한 구절이라고 생각합니다.  
-  이 모든 내용을 한 단어로 표현한다면 **“공유”**일 것입니다. 저 역시 과거에 해결해야 할 일을 **공유하기보다는 혼자 처리하는 것이 더 효율적**이라고 생각하며, 종종 혼자서 일을 진행해왔습니다.  
-  그래서 이 문장을 통해 많은 깨달음을 얻을 수 있었습니다.

From e7130276c49a2fe959d31045158b2fe70d296b07 Mon Sep 17 00:00:00 2001
From: karnelll <165611407+karnelll@users.noreply.github.com>
Date: Thu, 19 Sep 2024 23:27:17 +0900
Subject: [PATCH 8/8] =?UTF-8?q?Delete=202=EC=9E=A5/=EC=84=9C=EA=B8=B0.md?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

---
 "2\354\236\245/\354\204\234\352\270\260.md" | 88 ---------------------
 1 file changed, 88 deletions(-)
 delete mode 100644 "2\354\236\245/\354\204\234\352\270\260.md"

diff --git "a/2\354\236\245/\354\204\234\352\270\260.md" "b/2\354\236\245/\354\204\234\352\270\260.md"
deleted file mode 100644
index ec9bd66..0000000
--- "a/2\354\236\245/\354\204\234\352\270\260.md"
+++ /dev/null
@@ -1,88 +0,0 @@
-# 2장 서기
-
----
-
-## **은학님**
-
-톱니바퀴 실험에 큰 감명을 받았습니다.  
-사수와 부사수 간 대화에서 첫 번째 대화는 극단적이었지만, 두 번째 대화에서는 더 나은 세 번째 대화가 있다는 점이 놀라웠습니다.  
-이번 프런트엔드 프로젝트 경험에서 짧은 기간으로 인해 후반부에 힘든 경험을 했습니다. 앞으로 프로젝트 초기부터 시간을 낭비하지 않고 어떤 부분에 중점을 둘지 논의하고 싶습니다.
-
----
-
-## **연주님**
-
-"팀에 뛰어난 사람이 많다고 성공하는 것이 아니라, 정보 공유와 협력이 중요하다"는 내용에 깊이 공감했습니다.  
-과거에 개발 리드를 맡았을 때, 초반에는 협력을 강조했지만 되돌아보니 개인적으로 일을 처리했던 것 같습니다.  
-협력의 본질에 대해 고민하며, 앞으로는 소통과 공유를 통해 협력하는 방식으로 진행해야겠다는 깨달음을 얻었습니다. 하지만 현실적인 장애물로 인해 이를 실현하기 어려운 상황이 있다고 생각한다. 이에 대해 논의하고 싶습니다.
-
----
-
-## **상호님**
-
-“도구 개선은 3배, 관리 개선은 64배의 효과를 낸다”는 문장에 놀랐습니다.  
-프로젝트를 진행하며 병목 현상은 없었지만, 발생할 경우 관리 방식을 되돌아봐야겠다고 생각했습니다.  
-또한, 하나 공유와 최고 공유가 오히려 신뢰도를 떨어뜨릴 수 있다는 점이 흥미로웠습니다. 설득에 대한 내용에서 많은 공감을 했으며, 인간에 대한 이해를 높이기 위해 더 많은 책을 읽어야겠다고 느꼈습니다.
-
----
-
-## **호영님**
-
-함께 일하고 싶은 동료의 특성을 정리해봤습니다:  
-1. 질문을 잘하는 사람  
-2. 사회성이 좋은 사람  
-3. 자신의 의견을 잘 표현하는 사람  
-4. 의견을 잘 듣는 사람  
-5. A를 정확히 수행하는 사람  
-
-설득에 대한 내용을 읽고, 지금까지의 생각들이 객관적이었는지 의문이 들었고 많은 깨달음을 얻었습니다. 또한, "어려운 문제를 해결할 때 전문가는 계획을 수정하는 경우가 많다"는 점이 인상 깊었습니다.  
-현재 새로운 기술을 배우고 있는데, 책의 내용을 적용하여 목표 지향보다는 학습의 즐거움을 느끼며 학습해야겠다고 생각했습니다.
-
----
-
-## **예영님**
-
-팀이 함께 사용하는 '시끄러운 공간'에 대해 깊이 공감했습니다.  
-프로젝트를 진행하며 혼자 일하는 것을 선호하는 팀원이 있어 이를 조율하는데 고민이 많았지만, 면대면 소통이 효율적이라는 점을 깨달았습니다.  
-개발에서 추상화는 이해가 되었지만, 협업에서 추상화가 다소 모호하게 다가왔습니다. 품질과 결함이 상대적이라는 점도 인상 깊었습니다.  
-설득에 대해 고민이 많았는데, 상대방의 중요성을 파악하고 선호하는 설명 방식을 이해하는 것이 중요하다는 것을 배웠습니다.  
-진행 상황을 공유하면서 시간을 절약한 경험이 있었으며, 실시간으로 정보를 효율적으로 공유하는 방법에 대해 논의하고 싶습니다.
-
----
-
-## **희상님**
-
-과거 프로젝트에서 '내 파트만 열심히 만들면 되겠지'라는 생각으로 임했기 때문에 협력의 이점을 제대로 경험해본 적이 없었던 것 같습니다. 앞으로는 협력을 중점적으로 진행해봐야겠다고 느꼈습니다.  
-실수에 대한 두려움과 질문이나 의견 제시에 소극적이었던 태도를 반성하고 고치고자 합니다.  
-수평적 조직 구조에 대한 책의 내용은 동의하지만, 때로는 강압적인 부분도 필요하다고 생각합니다.  
-혜성님의 직장 생활에서 열심히 하지 않거나 이상한 팀원이 있었는지 궁금합니다.
-
----
-
-## **혜성님**
-
-목표지향적인 사고를 하려고 노력하고 있으며, 현실적인 개발 가능성을 바탕으로 일을 진행하고 있습니다.
-예를 들어, 모든 팀원이 즉시 사용할 수 있는 기술 스택을 선택하고, 인터페이스도 팀원들과 함께 결정합니다. (ex. json-server)
-또한, 워터폴 방식을 최대한 줄이려 하고 있습니다.
-
-프로젝트의 목적에 따라 접근 방식이 달라질 수 있다고 생각합니다. 학생 시절의 프로젝트는 학습과 성장이 목표일 수 있지만, 직업으로서의 프로젝트는 사용자에게 가치를 전달하는 것이 최우선입니다. 더 많은 경험이 해결책이 될 수 있다고 생각합니다.
-
-추상화는 인간의 한계를 극복하기 위한 것이라고 생각합니다.
-
-### 추천 도서:
-- [구글 관련 책](https://product.kyobobook.co.kr/detail/S000061352347)  
-
-정보 공유의 경우 친밀한 관계가 많은 도움이 된다고 생각합니다. 또한 어떤 것을 물어볼 때 적절한 리소스를 활용하는 것도 중요한 센스라고 생각합니다. 예를 들어 하이퍼링크를 사용하는 것.
-
-주석을 활용하여 소통하는 것도 중요합니다. 코드 자체에 대한 설명보다는, 작성 의도에 대한 이유를 담은 주석이 더 바람직하다고 생각합니다.
-
-### 추천 도서 (주석):
-- 실용주의 프로그래머
-- 읽기 좋은 코드가 좋은 코드다
-
-"만약 조직에 적합하지 않은 사람이 채용되었다면, 그 사람의 문제가 아니라 채용 과정의 문제일 수 있다. 그 채용 과정을 점검해야 한다"는 말이 있습니다.
-
-또한 만약 열심히 하지 않는 팀원이 있다면, 동기 결여의 원인을 찾아 적절한 동기부여를 해야한다고 생각합니다.
-
-### 추천 도서 (설득:
-- 설득의 심리학