<함께 자라기> 2편
우리는 결국 사람과 일합니다
🚀 들어가며
🤝 인간(人)은 서로의 등을 기대고
- 협력을 통한 추상화
- 객관성의 주관성
- 쾌속 학습팀
📗 마치며
들어가며
<함께 자라기> 2부는 '함께'라는 키워드를 다룬다. 우리는 협력을 제대로 배워본 적이 거의 없다. 1부의 '자라기'는 학교를 다녀본 사람이라면 어떻게든 해본 적이 있는 내용이다. 주입식 교육이든 야생 학습이든 공부하고 성장하려고 노력하는 것은 대다수의 사람이 해봤다. 책에서 나오는 좋은 학습법, 마인드셋 등을 본인의 삶에 적용해보진 않았어도 읽으면 이해할 수 있다. 하지만 협력이라... 협력을 제대로 배운 적이 있던가? 당장 떠오르는 기억은 대학교 조별과제 절망편이다. 총대 메기 싫어서 어떻게든 팀원을 닦달해보고 달래보고 화도 내봤지만 결국 몇 명의 희생(?)으로 굴러가는 팀플, 열심히 하고 싶었지만 능력이 부족해 남들의 노력에 버스 승객이 되버린 경험 등.
애초에 자라기에 비하면 협력 경험이 현저히 적었기 때문에 이번 2부의 내용이 얼마나 이해가 될지 걱정이 되었다. 그렇지만 2부를 읽으면서 그런 걱정은 사라졌다. 하나된 팀으로 일하는 것의 중요성을 다양한 사례를 들어 설명해주었고, 현실에서 어떻게 실천하면 좋은지 예시도 나와있었다.
책 내용의 일부를 간략하게 소개해본다. <소프트웨어 관리자의 개선 우선순위>에서는 '관리' 부분에서 상당한 개선을 이뤄내면 비용 측면에서 64배 정도 개선된다고 했다(관리 > 시스템 > 사람 > 도구 순으로 비용 개선 효과). 팀이나 리더에 관한 내용이 주를 이루기 때문에 조직을 관리하는 팀장급 개발자가 읽으면 많은 인사이트를 얻을 수 있다.
인간(人)은 서로의 등을 기대고
협력을 통한 추상화
둘 이상이 협력해 문제를 푸는 경우를 살펴보자. 협력하는 사람 간의 시각이 다르기 때문에, 그들의 다른 시각을 하나로 묶어줄 연결다리가 필요하다. 거기에는 필연적으로 추상화의 요소가 존재한다. 혼자서 작업하면 추상화의 필요가 덜하다.
전산학은 추상화의 과학이다.
- 알프레드 아호와 제프리 울먼
소프트웨어 공학의 전체 역사는 추상화 수준을 높이는 것으로 특징지을 수 있다.
- 그래디 부치
추상화는 프로그래머에게 중요한 주제다. 소프트웨어 추상화 관련 명언도 여럿 존재한다. 앞 문단에서 발견했듯 추상화를 높일 수 있는 방법은 '다른 시각을 가진 두 사람이 협력하기'다. 특히 짝 프로그래밍은 협력을 통한 추상화 방법으로 최적이다. 두 사람이 대화함으로써 추상화를 높이게 한다. 하나의 컴퓨터로는 구체화를 통해 검증하게 한다. 이 과정에서 지식을 넓혀갈 수 있다.
위키 백과사전의 기반이 된 워드 커닝햄의 위키위키는 핵심이 기술력에 있지 않고 사람들 간의 대화에 있다. 사람들이 모여 집단지성으로 만들어내는 결과물이야말로 최고의 결과물이다. 혼자서는 불가능한 것이 함께 하면 가능해진다.
나는 독학을 주로 해왔다. 스스로 일정을 계획하고 주도적으로 해나간다는 점에서 독학의 장점은 확실하다. 하지만 혼자서는 도저히 안 되는 것도 있다. 그럴 때 동기부여가 되어준 것이 개발 커뮤니티였다. 학습을 위해 참여한 커뮤니티, 자기계발과 취미를 위한 모임 등에서 많은 개발자 분들이 올려주는 정보와 소식을 듣고 독학의 늪에서 고립되지 않을 수 있었다.
오프라인 모임을 가지기도 했다. 모니터 뒤에 사람이 있다는걸 몸소 느끼고 오면 확실히 리프레쉬가 된다. 서로 고민을 얘기하다 보면 다른 이들도 나와 비슷한 고민을 하고 있음을 깨닫는다. '나의 국지적 고민'이 '다른 이들 대부분의 고민'으로 확장된다. 고민의 추상화가 이루어지고, 마음은 한결 가벼워진다. 우리는 이 추상화를 겪고 나면 다시 시작할 에너지를 얻게 된다.
객관성의 주관성
품질이란 누군가에게 가치가 되는 것이다.
- 품질 전문가 제럴드 와인버그
고품질을 얻으려면 인간에 대한 이해가 필수적이다. 누군가를 설득하려면 객관성이 필요하다고 생각하겠지만, 객관성이란 개념 자체가 매우 주관적이다. 최종 결정은 사람이 한다. 감정과 완전히 분리시킨 이성만을 가지고는 의사결정을 제대로 할 수 없다. 애초에 객관성이 필요하다고 할 때 객관성이란, 설득하고싶은 '나'의 객관성인가? 설득시키려는 '고객' 입장에서의 객관성인가? 설득의 출발은 자료가 아닌, 내가 설득하려는 사람에게서 시작된다.
<함께 자라기> 책을 읽고 마음에 들어서 다른 사람들에게 추천하는 상황을 상상해봤다. 어떤 방식으로 추천하면 좋을까? 나는 이 책을 개발자 지인에게 '개발자들이 읽으면 좋은 바이블격의 책'이라고 추천받았다. 책 선물을 받으면서 함께 들은 얘기다. 나는 읽기만 하면 됐다. 그렇지만 목차를 쓱 훑어보고 읽지 않았다. 개발자에게 이 책이 좋다는 얘기는 들었지만, 업계 선배의 추천이었지만, 내가 '왜' 읽어야 하는지 마음으로 와닿지 않았다. 내가 자발적으로 이 책을 읽게 된 계기는 기술적인 지식 외에도 개발자에게 필요한게 무엇인지 궁금해졌기 때문이다. 어느정도 개발을 할 수 있게 된 후로는 개발 문화나 학습법, 협업 등에 관심이 생겼다.
이 챕터를 읽지 않았다면 나 또한 이 책을 '개발자들에게 필요한 책'이라고 추천했을 것 같다. 팀으로 일하는 법, 개발 문화, 마인드셋 키워드를 포함해서 간략한 책 소개를 하고 읽어보라고 할 것이다. 그 말로 누군가에게 책을 구입하고, 읽게 만들 수 있을까? 책에서 서술한 바에 따르면 추천하려는 사람과 대화를 나눠보고 그의 성향을 파악해야 한다. 그 사람의 고민과 관심사에 책 내용을 엮어서 흥미를 유발해볼 수 있다. 그 후에 나의 얘기도 나눈다. 이 책으로 변화한 습관이라든가 얻은 점 등을 공유한다.
아무리 좋은 주제를 가져와도 내가 상대방에게 비호감으로 비춰진다면 괜히 추천하려는 대상(책, 기술 등)도 밉보일 수 있다. 많은 자료를 가져와 팩트로 승부하는 전략이 좋은 방법이 아닌 이유다. 설득은 논리와 객관성으로만 이루어지지 않는다.
쾌속 학습팀
패러다임의 전환, 즉 기술적 변화 상황에서 낙오되지 않고 빠른 학습을 하려면 어떻게 해야할까? 다양한 실험의 결과로 교육 배경, 경험, 경력 연차는 학습 속도와 상관이 없음이 밝혀졌다. 중요한 핵심은 학습 환경을 만들 수 있는 리더였다. 빠르게 성장하는 팀은 팀원을 뽑을 때부터 협동적으로 선발이 진행되었고, 협력과 소통을 선발 기준으로 세웠다. 기술적 변화를 개인의 도전이 아닌 조직 단위의 도전으로 받아들이고, 함께 일하는 새로운 방법을 만들어 나갔다. 또한 팀원들은 심적으로 보호되었다. 새로운 방식으로 실험하고, 공유하고, 학습과 실행이 동시에 이루어졌다.
애사심에 대해 얘기해보고 싶다. 꼭 회사가 아니더라도 공동체 의식으로 확장시켜 생각할 수 있다. 학교, 학원, 동아리, 회사 등 단체적으로 협력해야 하는 상황이 있을 때 공동체 의식의 유무에 따라 능률이 달라지는 것을 경험한 적이 있다. 나는 이전 회사에서 애사심이 강한 편이었는데, 동료 분들도 너무 좋고 일도 재밌어서 회사 다니는 것이 행복했다. 당시 코로나 상황이 심해져 재택을 해야했는데 동료를 못 만난다고 생각하니 우울했다. 재택이 끝나기만 기다렸다. 일할 맛이 안 났다. 한창 회사에 심취해있을 때는 금요병에 걸렸다. 주말에는 회사를 못 간다는 점에서 슬펐던 것이다. 그때는 퇴근해도 자발적으로 일을 찾아서 하고, 자기계발도 했다. 동료 분들도 업무 관련 기사, 아티클을 공유하며 자발적으로 성장해 나갔다. 우리는 쾌속 학습팀이었다.
냉소주의는 전염성이 강하다. 다같이 규칙을 정하고 지켜나가기는 어려운데, 한 번 무너지면 열심히 하던 사람들까지 물들어버린다. '인사? 그거 한다고 뭐가 달라져. 중간 보고하기 귀찮은데 그런거 안 해도 결과물 보면 알잖아.' 등의 예시가 있다. 공동의 규칙을 안 지켜도 별 문제가 없음을 깨닫고나면 그렇지 않던 사람도 하나 둘씩 포기해 버린다. 이런 공동체가 만든 최종 결과물이 좋을리 없다. 결국 깨진 유리창 법칙처럼 되어버린다. 책에서도 학습 속도가 느린 팀은 새로운 기술을 비꼬고 조소했다. 낙오의 위험성을 강조하고, 다른 팀원을 탓하기 바빴다.
반면 본인이 속한 조직에 만족감을 느끼고 동료들과 함께하는 것에 즐거움을 느끼면 능률은 저절로 좋아진다. 내 일이 일찍 끝나면 동료의 업무를 도와주고, 모르는 문제는 서로 물어보고 논의하고, 지위의 높낮이에 상관 없이 의견을 표출할 수 있다. 이런 분위기는 억지로 조장한다고 해서 되지 않고 구성원의 애사심, 공동체 의식에서 나온다. 결국 냉소적인 전문가 여럿이 모인 팀보다, 애사심 높은 팀원 여럿이 모였을 때 더 빠르게 성장한다.
마치며
2부를 다 읽고 든 생각은, 결국 사람은 사람과 일한다는 점이었다. 미디어에서 그려지듯 혼자 골방에 틀어박혀 천재 해커처럼 문제를 해결하는 나홀로 전문가는 없다. 설득도, 협력도, 프로젝트도, 회사도 다 사람이 함께한다.
그러면 우리는 이왕 해야하는 일을 협력적으로 해서 능률을 높이면 좋지 않을까? 팀원 혼자서는 그런 분위기를 조성하기 어려울 수 있으므로 <함께 자라기> 책을 동료에게 추천하는 것부터 시작해보자. 냉소는 줄이고 냉소보다 강력한 유대감을 쌓아보는건 어떨까? 남을 포용하고 서로에게 기댈 수 있는 자가 진정으로 강한 사람이다.
'독서' 카테고리의 다른 글
<함께 자라기> 1편 - 자라기를 잘 하는 개발자가 되려면? (0) | 2024.03.17 |
---|---|
<Docs for Developers 기술 문서 작성 완벽 가이드> 리뷰 (0) | 2023.05.26 |