diff --git "a/2\354\236\245/\353\254\270\355\235\254\354\203\201.md" "b/2\354\236\245/\353\254\270\355\235\254\354\203\201.md"
new file mode 100644
index 0000000..26f0199
--- /dev/null
+++ "b/2\354\236\245/\353\254\270\355\235\254\354\203\201.md"
@@ -0,0 +1,39 @@
+# 📑 내용 정리
+### 관리자가 가져야 할 자세
+
+- 업무를 단순히 **인원수대로 나누는 것**은 **협업에 최악**이다.
+- 각자 일하는 것이 아니라 **한 공간에서 소음을 만들며 일하는 것**은 **생산성 향상에 도움이 된다**.
+- 제럴드 와인버그는 **복잡한 상황을 이해, 관찰 그리고 행동하는 것**이 개발을 '**잘**'하는 능력이라 말한다.
+- 보통 **도구에 대한 개선 시도**가 가장 많지만, "**관리, 시스템, 사람, 도구**" 순으로 개선 효과를 누릴 수 있다.
+
+### 조직에서의 협력
+
+- 아무리 뛰어난 개인이라도 **협력하는 것**이 더 나은 결과물을 만든다.
+- **시각화 없이**(전화, 텍스트만) 협력하는 것보다 **중간 매개**(화이트보드, 종이)를 두고 협력하는 것이 도움이 된다.
+- 분리된 팀들이 깔끔한 탑 다운으로 **바통터치하듯이 협력**하는 것은 좋은 결과물을 만들기 힘들다.
+- 모든 팀들이 일의 많은 부분에 관심을 가지고 '**삼투압적 의사소통**'을 통해 빈번한 바통터치를 하는 협력이 큰 성과를 거둔다.
+- 내 생각이나 의견에서 실수가 드러났을 때 **처벌받거나 놀림받지 않을 거라는 믿음**인 '**심리적 안전감**'을 팀원 모두가 가질 수 있도록 해야 한다.
+- 자신의 일로 한정짓지 않고 **도움을 주고받는 협력**에서는 **학습 속도를 높이는 데**도 큰 도움이 된다.
+
+### 신뢰와 공감
+
+- **무조건적인 공유**가 신뢰를 쌓지는 않는다.
+- **하나 공유, 최고 공유**보다 '**복수 공유**'를 통해 불안감을 낮추고 신뢰를 쌓자.
+- 실수에 대한 비난을 하는 것이 아니라 **대화를 통해 공감하고 분석하면서 성장으로 이끌 수 있는 행동**을 유도하는 것이 중요하다. 이러한 과정에서 **신뢰는 쌓인다**.
+
+### 객관성의 주관성
+
+- 모든 결정은 결국 **사람이 하게 되고**, 이 부분에서 **감정이 배제될 수는 없다**.
+- 즉, **누군가를 설득하기 위해서는 그 사람에 대한 이해가 선행되어야 하고 그 사람의 성향에 맞는 대화**가 필요하다.
+
+# 🤔 느낀점
+- 프로젝트를 진행할 때, 내가 많이 알고 잘하는 것이 가장 중요하다는 생각이 강했는데, 나 자신의 성장을 위해서라도 활발한 의사소통을 하는 협력이 중요하다는 생각을 다시 한 번 해본다.
+- 평소 프로젝트를 진행하는 과정에서 업무를 혼자 끝내버려야 겠다는 생각, 실수가 두려워 질문과 의견 제시를 적극적으로 하지 않는 태도는 뜯어고쳐야겠다...
+- 협력 부분에서 중간매개 직접 대면으로 화이트보드를 활용해 이야기할 때 해결되는게 많았다고 무의식적으로 느끼고 있었는데 연구 결과가 있었다는 점에서 앞으로 더 많이 활용해보겠다고 생각했다.
+- 누군가를 설득하는 과정에서 논리적인 부분에서 결함이 없다면 누구나 설득시킬 수 있을 거라는 생각을 가지고 있었는데 결국 그 사람이 결정하는 부분이라는 점에서 사람에 대한 파악이 선행되는 것이 중요하다고 생각이 바뀌었다.
+- 플젝을 진행할 때, 그냥 파트를 나눠서 각자 할 거 하는 식으로 많이 진행했었고, 내 파트만 열심히 만들면 되겠지라는 생각으로 임했었는데 협력에 대한 이로운 효과를 제대로 경험해 본 적이 없어서 그랬던 것 같다. 앞으로 협력에 초점을 두어서 플젝을 해야겠다는 생각이 강하게 들었다.
+- pm을 맡았던 적이 있었는데 팀원들이 모르는 부분에 있어서 추가적인 학습은 각자 알아서 라는 생각을 가지고 있었다. 왜냐면 학습은 스스로 하는 것이 가장 높은 효율을 낼 수 있을 것이라 믿고 있었기 때문이다. 하지만 이번 2장에서 코칭에 대한 파트를 읽으면서 팀원이 어떤 상황인지 파악하고 신뢰를 쌓으면서 학습을 했더라면 더 좋은 성과를 만들어 낼 수 있지 않았을까 하는 후회와 아쉬움이 있다.
+ 
+# ✅ 궁금한 점
+- 팀원의 코드 리뷰를 진행할 때, 어떤 부분에 대해서 피드백을 남기시는 편인가요? (예를 들어, 코드 형식이나 로직)
+- 팀원이 나의 코드에 대해 이런 식으로 피드백을 주었으면 좋겠다고 생각하는 게 있는지 궁금합니다.