함께

이 책 제목이 "함께 자라기"인 이유가 바로 여기 있어. 1장에서 개인의 성장을 다뤘다면, 이번에는 왜 함께여야 하는지, 그리고 함께 일하는 것이 왜 이렇게 어려운지를 파고들지.

소프트웨어 프로젝트를 개선하려면 뭘 먼저 해야 할까? 대부분의 관리자는 기술적인 것 — 더 좋은 도구, 더 나은 프로세스, 코드 품질 향상 같은 걸 먼저 떠올리잖아. 그런데 연구 결과를 보면, 실제로 프로젝트 성과에 가장 큰 영향을 미치는 건 사람과 협력의 문제였어. 도구를 바꾸는 것보다 팀원들이 어떻게 소통하느냐가 더 중요했다는 거지.

소프트웨어 개발에서 기술적 요소와 사회적 요소 중 뭐가 더 중요하냐고 물으면, 대부분 기술이라고 대답해. 하지만 실제 데이터는 반대야. 탁월한 엔지니어들은 기술만 잘하는 게 아니라, 다른 사람들과 잘 소통하고, 경영진에게 적극적으로 다가가고, 동료 엔지니어를 도와주거든.

협력이 단순히 "일을 나눠서 하는 것"이 아니라 사고의 질을 높이는 행위라는 게 정말 흥미로워. 혼자 생각하면 구체적인 것에 매몰되기 쉽잖아. 그런데 다른 사람과 대화하면서 내 생각을 설명하다 보면, 자연스럽게 추상화가 일어나. 왜냐하면 상대방은 내 머릿속에 있는 맥락을 모르니까, 내가 알고 있는 것을 좀 더 보편적인 언어로 번역해야 하거든.

두 사람의 시각이 다르기 때문에, 그 시각을 연결할 다리가 필요하고, 그 다리에는 필연적으로 추상화가 들어가지. 이렇게 만들어진 추상화는 혼자 생각했을 때보다 더 탄탄해. 페어 프로그래밍이 왜 효과적인지를 이걸로 설명할 수 있어. 단순히 버그를 잡아주는 게 아니라, 대화를 통해 코드의 설계 자체가 더 좋은 추상화 수준으로 올라가는 거야.

팀에서 "공유"를 하라고 하잖아. 코드 리뷰도 하고, 회고도 하고, 지식 공유 세션도 하고. 그런데 같은 공유라도 신뢰를 쌓는 공유가 있고, 신뢰를 깎는 공유가 있어. 신뢰를 깎는 공유는 이런 거야 — 누군가 코드 리뷰에서 "이거 왜 이렇게 짰어요?"라고 공격적으로 물을 때, 회고에서 특정 사람의 실수를 공개적으로 지적할 때. 형식은 공유지만 실질적으로는 평가와 비난이 되어버리지.

신뢰를 쌓는 공유는 투명성과 인터랙션이 핵심이야. 자신의 작업물을 투명하게 보여주고, 그에 대해 상호적으로 피드백을 주고받는 것. 여기서 중요한 건 일방적인 평가가 아니라 쌍방향 대화라는 점이지. 결국 같은 코드 리뷰라도 "내가 너를 평가한다"는 느낌이면 신뢰가 깎이고, "우리가 같이 코드를 더 좋게 만든다"는 느낌이면 신뢰가 쌓여.

우리가 객관적이라고 생각하는 것도 실은 주관적이라는 이야기도 재밌어. 누군가를 설득할 때, "객관적인 데이터"를 가져오면 상대가 납득할 거라고 생각하잖아. 그런데 같은 데이터를 봐도 사람마다 해석이 다르거든. 내가 보기에 명백한 증거가 상대에게는 전혀 설득력이 없을 수 있어.

그래서 설득에 성공하려면 우선 그 사람을 이해하는 것에서 출발해야 해. 상대가 어떤 맥락에서 생각하고 있는지, 어떤 가치를 중요하게 여기는지를 먼저 파악해야 하는 거지. 기술적 논쟁에서도 마찬가지야. "이 아키텍처가 객관적으로 더 좋다"고 주장하는 건 안 먹혀. 상대가 왜 다른 선택을 하려 하는지 이해하고, 그 관점에서 출발해서 대화해야 실제로 합의에 도달할 수 있어.

"일단 전체 구조를 설계하고, 세부를 채워나가자" — 이게 하향식 접근이잖아. 논리적으로 완벽해 보이지만 이게 함정이야. 왜냐하면 현실은 복잡하고 불확실하니까. 위에서 아무리 멋진 계획을 세워도 현장에서 부딪히면 안 맞는 부분이 생기거든. 그런데 하향식으로 내려온 계획은 수정하기 어렵지. 이미 전체 구조가 정해져 있으니까.

제안하는 건 하향식과 상향식을 섞는 것이야. 큰 방향은 잡되, 세부는 현장에서 실험하고 피드백을 받으면서 채워나가는 거지. 이게 사실 애자일의 핵심 원리이기도 한데, 3장에서 더 자세히 다뤄.

전문가팀 이야기는 정말 뼈 때리는 내용이야. 각 분야 최고의 전문가들을 모아서 팀을 만들면 당연히 최고의 결과가 나올 거라고 생각하잖아. 근데 아니거든. 연구에 따르면, 올스타 팀이 오히려 평범한 팀보다 성과가 나쁜 경우가 있었어. 왜? 전문가들은 자기 방식이 확고하잖아. 서로 양보를 안 해. 각자 자기가 제일 잘 안다고 생각하니까 협력이 안 되는 거지.

축구로 치면 공격수 11명을 모아놓은 거야. 개인 기량은 최고인데 팀 플레이가 안 되는 상황. 결국 팀 성과는 개인 역량의 합이 아니라, 팀원들이 얼마나 잘 협력하느냐에 달려 있어.

구글이 수백 개 팀을 분석해서 "탁월한 팀의 비밀"을 찾으려 한 프로젝트 아리스토텔레스 이야기도 있어. 결론이 의외였거든. 팀의 성과를 결정하는 가장 중요한 요소는 누가 팀에 있느냐가 아니라, 팀원들이 어떻게 상호작용하느냐였어. 그리고 그 상호작용의 핵심은 바로 **심리적 안전감(Psychological Safety)**이었지.

심리적 안전감이란, 내 생각이나 의견, 질문, 걱정, 혹은 실수가 드러났을 때 처벌받거나 놀림받지 않을 거라는 믿음이야. 이게 높은 팀은 구성원들이 자유롭게 의견을 말하고, 실수를 빨리 공유하고, 도움을 요청할 수 있지. 구글 연구에서 심리적 안전감은 나머지 모든 성공 요소의 토대가 되는 가장 중요한 요소였어. 아무리 뛰어난 사람들이 모여 있어도 심리적 안전감이 없으면 각자 방어적으로 행동하게 되고, 팀 성과가 떨어지거든. 이건 앞에서 다룬 "실수는 관리"와도 연결돼. 심리적 안전감이 높아야 실수가 빨리 드러나고, 빨리 드러나야 빨리 고칠 수 있으니까.

마지막으로 이상적인 팀의 모습 — 쾌속 학습팀이야. 병원에서 새로운 수술법을 도입하는 팀들을 비교하는 연구 사례가 나오는데, 같은 수술법을 배우는데 어떤 팀은 빨리 숙달하고 어떤 팀은 더디게 배웠거든. 차이를 만든 건 팀원들의 개인 역량이 아니었어.

빠르게 학습한 팀의 특징:

• 리더가 우리가 함께 배우는 거다라는 프레임을 설정했어
• 팀원들이 자유롭게 질문하고 의견을 냈지
• 실수했을 때 비난이 아니라 **여기서 뭘 배울 수 있지?**로 접근했어
• 새로운 시도를 장려했고

결국 팀의 학습 속도를 결정하는 건 개인의 똑똑함이 아니라 팀의 학습 문화야. 심리적 안전감이 있고, 학습 프레임으로 접근하고, 빠른 피드백 루프가 있는 팀이 빠르게 자라지.

---

정리

2장 읽고 기억할 거 세 가지:

1. 팀 성과는 개인 역량의 합이 아니야. 전문가들만 모아놓으면 오히려 실패할 수 있거든. 핵심은 협력의 질이지
2. 심리적 안전감이 모든 것의 토대야. 실수를 두려워하지 않는 팀이 빠르게 배우고, 빠르게 성장해
3. 같은 공유라도 신뢰를 쌓을 수도, 깎을 수도 있어. 평가가 아니라 함께 만들어간다는 마인드가 중요하지