[MC3] AppleAcademy MC3 회고록 22주차: 함께 자라기

'함께 자라기'를 읽다

전에 함께 커피챗을 했던 오후 러너뿐만 아니라 같은 팀의 러너에게도 추천받은 책이었다. 개발자로서 어떻게 성장할 수 있는지에 대한 조언이 담겨있다는 말에 책을 읽기 시작했다. 하지만 책을 한 장 한 장 넘겨도 그들의 감상이 내게 와닿지는 않았다. 너무 당연한 이야기들을 하고 있지 않나 생각했기 때문이다. 책에서 제시하는 학습 방법들이 나에게는 익숙한 내용들이었다. 교육학 서적에서 자주 보던 개념들이 나타나 반가워하며 조금은 심드렁하게 책을 읽어갔다.

아이러니하게도 이런 생각은 'SQ3R'이라는 아주 익숙한 단어를 접하면서 달라지기 시작했다. 프로그래밍을 빠르게 학습하기 위해 적극적으로 읽기 목적을 설정하고 수행하는 사례를 보며 나의 독서 태도를 반성하게 되었다. 나는 이 책을 왜 읽고 있는 걸까? 단순히 추천받았기 때문인가? 그토록 잘 안다고 자부한 내용임에도 불구하고 학습과 실천이 일치하지 않는 나의 모습이 너무 부끄러웠다. 이후 나는 이 책에서 얻고자 하는 목적을 명확하게 설정한 후 다시 읽기 시작했다. 그제서야 러너들이 왜 이 책을 추천할 수 있었는지 알 수 있었다. '함께 자라기'는 정말 좋은 책이었다. 어떻게 하면 함께 자랄 수 있을까? 내가 이 책에서 배운 내용을 중점으로 글을 쓰고자 한다. 

 

 

함께 자라기를 읽는 목적: 나는 이 책에서 무엇을 배울 것인가?

이 책을 읽으면서 내가 얻고 싶은 인사이트에 대해서 정리해보았다. 

1. 개발을 잘하는 것이란 무엇일까? 
2. 내가 앞으로의 챌린지에서 협업을 더더욱 잘 하기 위해선 어떻게 해야할까?
3. 앞으로 개발자로 성장하기 위해선 어떻게 성장해야할까? 

 

그래서 이 책을 통해 무엇을 배웠나요?

앞서 이야기한 오후 러너분이 '글쓰기와 코딩이 닮았다'고 말한 적이 있다. 당시 나는 그 말이 전혀 와닿지 않았다. 어느 지점에서 글쓰기와 코딩이 닮았다는 건지 궁금했지만, 타이밍을 놓쳐 묻지 못했다. 그 말이 오랫동안 내게 남아있었다. 언젠가는 그 궁금증을 해결하고 싶었다. 그러다 이 책을 읽으며 그 말의 의미가 무엇인지 내 나름대로 이해할 수 있게 되었다.  

 

사람들에게 좋은 글을 쓰기 위해서 필요한 것이 무엇인지 묻는다면, 대부분의 사람들은 좋은 소재를 잡는 것이 중요하다고 대답한다. 특별한 소재가 특별한 이야기를 가져다 줄 것이라고 생각하는 것이다. 하지만 글을 목표지향적인 행위로 보는 이론에서는 좋은 글을 쓰기 위해선 수정을 잘 해야 한다고 주장한다. 해당 이론에서 작문은 계획, 자료 수집, 내용 생성, 개요 작성, 초고 작성, 고쳐쓰기의 과정을 거쳐 이루어지는 행위이다. 글쓰기에 능숙한 필자는 글을 쓰기 이전에 글을 어떻게 써내려 갈 것인지 충분한 시간을 들여 계획을 잡고, 내용을 구성하며 이를 토대로 개요를 작성한다. 그리고 초고를 작성한 후에도 여러 번 글을 읽어보며 고쳐쓰기에 많은 시간을 투자한다. 

또 다른 이론에선 글을 사회화의 행위로 본다. 필자는 공동체에 속하기 위해 해당 공동체의 글쓰기 관습과 규범을 배우고, 이를 따르기 위해 '합의'를 수행해야 한다. 즉, 자신의 담화 공동체와 대화, 협상을 통해 의미를 형성해 나가는 과정이 글쓰기인 것이다. 이 이론에서 좋은 글이란, 다른 사람들과의 협업과 대화를 통해 구성된 의미를 공동체의 관습과 규범에 맞게 작성된 글이다.

 

생각해보면 코딩도 이와 비슷하다. 좋은 코드를 작성하기 위해선 이 코드를 통해 어떤 프로그램을 만들어야 하는지 문제를 명확히 해야한다. 코드를 작성하기 전에는 어떤 로직을 써야 하는지 어떤 도메인 지식이 있는지 확인하고 계획하는 데 많은 시간을 투자해야 한다. 코드를 작성한 후에도 더 나은 코드로 개선하기 위해 리팩토링도 한다. 게다가 혼자서 하는 작업이 아니기 때문에 convention의 규칙을 정하며 어떤 의미를 어떻게 전달할 것인지 해당 팀과의 관습과 규범을 설정해야 한다. 그 과정에서 코드리뷰를 수행하며 팀원들과의 대화를 통해 코드의 의미를 파악하는 시간을 갖기도 한다. 위에서 이야기하는 글쓰기 이론과 코드를 작성하는 행위가 정말로 닮아있다! 심지어 나 혼자 코드를 작성할 때에도 미래의 '나'(독자)가 과거 '나'(필자)의 코드를 이해할 수 있도록 의미를 명확하고 깔끔하게 작성해주어야 한다. 이를 위해 혼자 작성하는 코드에서도 규칙을 설정하고 이에 맞춰 개발을 진행하기도 한다. 

결국 개발을 잘 하는 것이란, 좋은 글을 쓰는 것과도 같다. 각 단계 마다 충분한 시간을 들여 문제를 해결할 수 있어야 하고, 그 코드 의미를 다른 개발자와의 대화를 통해 이해하고 받아들일 수 있도록 작성해야 하는 것이다. 

 

개발과 글쓰기가 비슷하다는 생각이 들다보니 자꾸만 닮은 점만 들어온다. 글쓰기 이야기를 조금 더 해보자면, 협동 작문이라는 개념이 있다. 보통 글쓰기는 혼자 하는 활동을 이해하기 쉽다. (사실 인지주의 작문에서는 작문을 홀로 의미를 구성하는 행위로 정의하기 때문에 맞는 말이긴 하다.) 협동 작문은 하나의 모둠이 협의를 통해 하나의 글을 완성하는 활동을 의미한다. 작문 과정에서 구성원과의 협의와 공유를 통해 글쓰기라는 문제에 최선의 해결방안을 찾아내는 것이다. 이 협동 작문의 방식이 내가 앞으로의 챌린지에서 협업을 잘 하기 위해 노력해야 하는 방향과 닮아있다는 생각이 든다. '앱 만들기'라는 목적을 향해 팀원들과 함께 어떻게 문제를 해결할 수 있을지 끊임없는 협의와 공유해야 한다. 내가 이 지점에서 다른 사람들보다 조금 더 도움을 줄 수 있는 부분이라면, 구체적인 문제 상황을 설정할 수 있도록 적당한 틀을 잡아주는 것이나 공유, 협의 과정에서 상대방을 공감하고 이해하는 대화 방법에 대한 지식을 나눌 수 있을 것이다. 

 

이번 MC3를 진행하면서 팀원들에게 미안한 마음이 많이 들었다. 다른 팀원들이 나보다 훨씬 많은 일을 하고 있는 것을 알고 있기 때문이다. 어느 챌린지에서도 그러했지만, 이런 감정은 특히 구현 단계에 들어가면 더욱 강해진다. '내가 무엇을 할 수 있지?' 라는 고민이 많아지기 때문이다. 더 많은 개발을 하고 싶지만 개발이 아직 능숙하지 않고, 욕심을 내보려다가도 내가 공부한 지식이 도움이 되지 않을 것 같다는 생각에 결국 한 발짝 뒤로 물러서곤 한다. 누군가를 가르쳐가며 일을 진행하기 보다는 그냥 잘 하는 사람이 얼른 해버리는 게 나을 때가 있다는 것을 알고 있기 때문이다. 촉박한 시간에 쫓기다 보면 더더욱 그렇다. 그렇다면 내가 개발자로 성장하기 위해선 어떤 노력을 더 해야 할까? 결국 '함께 자라기'에 대한 노력일 것 깉다. 

 

마지막 3장에서 애자일하게 살아가는 방법에 대해 작가는 '고객에게 매일 가치를 전달하자'라고 이야기한다. 불확실성이 큰 상황에서 학습과 협력은 좋은 대응 전략이며 '매일' 학습할 수록 현재 위치와 목적지의 위치를 계속 확인하며 피드백을 얻을 수 있기 때문이다. 또한 '고객'뿐만 아니라 제품을 만들어가는 모든 이해관계자에게 진정한 가치를 전달하고 있는지 확인해야 한다고 강조한다. 이처럼 '매일' 학습하며 나의 학습이 목적과 일치하는지 확인하면서, 내가 다른 팀원들에게 배움을 얻는 만큼 어떤 가치를 전달할 수 있는지 '함께 자라'는 측면에서 고민해야겠다. 분명 나의 지식과 날것과도 같은 생생한 시선이 다른 팀원에게 도움이 될 수 있을 것이다. '두려워도 중요하다면 시도해야 한다'는 작가의 말처럼, 나도 이제는 도움이 되지 않는다는 두려움에 뒤로 물러서기 보다는 도움을 줄 수 있는 방향으로 적극적으로 시도해봐야겠다.

 

 

함께 자라기를 읽으면서 메모한 기록들

# 프로그래밍 언어 배우기의 달인 → CTA(인지적 작업 분석, Cognitive Task Analysis)
1. 튜토리얼을 읽을 때 뭘 만들지 생각하고 읽는다.

• 목적을 고려하며 질문을 만들고 적극적 읽기를 수행함 

2. 공부할 때 표준 라이브러리 소스코드를 읽는다 

• 좋은 코드를 읽기를 수행함과 동시에 해당 언어의 스타일을 익힘

3. 공부 중 다른 사람의 코드에 내가 필요한 기능을 추가한다.

• 실례를 통해 실제 코드의 감(읽고 쓰기)를 익힘 
• 유용하면서 작고 간단한 걸 생각해 내는 것 → 몰입을 위한 난이도 조절 

4. 전문성을 효과적으로 뽑아내는 전문가 되기 

• 구체적인 사건에 대해 말하도록 유도하기
• 뭔가 잘하고 싶다면, 이미 잘하는 사람을 관찰하고 인터뷰하는 것부터 시작하는 것이 큰 도움이 됨

# 실수는 예방하는 것이 아니라 관리하는 것이다 

• 전문가에게 실수를 관리하는 법을 배우는 것이 중요
• 나의 실수 문화를 예방에서 관리로 옮기려면 어떻게 해야할까? 

# 어떤 기술적 실천법이라도 그걸 현실에서 적용하기 위해서는 사회적 자본과 기술이 필요하다 
[참조] TDD: Test-Driven Development, 테스트 주도 개발 

• 그 조직원들이 선생님을 좋아하나요? 
• 동료들에게 내가 충분한 신뢰를 얻고 있는지, 얻으려 노력했는지 되돌아 봐야 함.

# 팀과 그룹 

• Team : 구성원간의 소통/협력 네트워크가 그물망에 가까움 
• Group : 네트워크가 중앙(팀장)에서 뻗어나가는 불가사리형 

→ 작업 불확실성이 높을수록 그룹보다 팀이 더 좋은 퍼포먼스를 보임 


# 코드의 추상화를 높이는 방법 → 협력, 대화 

• 다른 시각을 가진 두 사람이 협력하기
• 서로의 생각을 공유하는 과정에서 추상화가 더욱 필요하게 됨 

# 복수의 시안을 공유 : 신뢰를 높이는 공유 

• 상대적으로 덜 방어적 → 피드백 수용률이 높아짐, 최종 성과 역시 하나만 공유, 최고만 공유 보다 좋음

# 빠르고 빈번한 바통 터치가 가능한 전문가 조직

• 첫 주부터 분석, 설계, 구현, 테스트, 전개를 모두 왔다갔다할 수 있을까를 고민

# 비전문가 팀의 성공비결 → 협력 개입을 통한 빠른 정보 공유 

1. 정보를 공유하고 협력을 잘하기 위한 명시적인 도움이 필요
2. 소셜 스킬 등이 뛰어난 제너럴리스트가 있으면 도움 

# 심리적 안전감 

• 내 생각이나 의견, 질문, 걱정, 실수가 드러났을 때 처벌받거나 놀림받지 않을 것이란 믿음
• 팀원들에게 매일매일의 마이크로 인터랙션에서 신뢰감을 쌓게 해줄 것

# 리더가 팀 학습 속도에 미치는 영향
1. 팀원을 뽑을 때 

• 선발 자체가 매우 협동적 
• 업무 수행 능력뿐만 아니라 다른 사람과의 협력을 얼마나 잘하는지, 새롭고 애매모호한 상황을 즐길 수 있는지, 자기보다 지위가 높은 사람에게도 자신있게 의견을 제안할 수 있는지

2. 업무를 대하는 태도 

• 새로운 수술 도입 → 기술적 도전이라기보다 조직적 도전으로 받아드림

3. 심리적인 보호 

• 새로운 것을 제안하고 시도하는 데 열려있음
• 실패에 관대
• 잠재적 문제를 지적하고 실수를 인정하는 데 부담을 느끼지 않음
• 팀 퍼포먼스를 높이기 위해 새로운 방식을 실험하는 것을 강조 
• 모두가 공유하는 실험을 실행 
• 학습과 실행이 동시에 이루어짐 

⇒ 학습을 팀의 중대한 목표로 받아들이기, 기회와 가능성, 큰 변화의 흐름에 동참하는 중요성과 즐거움 강조



# 어떻게 하면 애자일스럽게 살아갈 수 있을까?

• 학습과 협력은 불확실성이 큰 상황에서 좋은 대응 전략 
• ‘고객에게 매일 가치를 전하라’ 
• 작은 성공이 주는 안도감에 취하지 말것 → 두려워도 중요하다면 시도해봐야 한다
• 프로젝트를 위해선 고객참여와 짧은 개발 주기가 핵심 (리팩터링, 코딩 후 자동화 단위 테스트 붙이기, 코드 공유 등)