brunch

You can make anything
by writing

C.S.Lewis

by 승돌 Sep 15. 2019

조직 내의 팀 그리고 협업에 관한 생각

승돌 쓰다.

요즘의 저는 이러한 생각을 하며 지내고 있습니다. 


협업 그리고 팀 내 역할의 다양성


어떤 테크니컬 한 기술적 성장보다 팀이라는 곳 안에서 능력을 배로 올려주는 것은 팀 협업이 아닐까? 고민하면서, 팀 내에서 미스 커뮤니케이션으로 의도치 않게 충돌을 막는 역할이 중요하다는 생각이 들었다. 

(충돌을 무조건 막는 것보다 잘 정리하고, 앞으로 나아가게끔 하는 게 중요하다.


핵심은 결국, 충돌 속에서 그 해결책을 잘 찾아가는 것이 중요하고 서로의 마음이 상하지 않고 앞으로 나아가는 것이 제일 중요하다는 생각이 들었다. 


회사라고 감정을 배제해야 하는 것은 아니다. 개발자이기 전에 우리는 모두 사람이다.


기술적 성장은 무조건 회사에서 해야 하는 것은 아니다.
모든 것이 일치되면 좋겠지만, 그렇지 않아도 된다.


결국 팀 내에 감독, 코치, 매니저, 선수의 역할 레벨이 고루고루 섞이고, 때에 따라 유동적인 느낌으로 잘 순회가 되는 팀이 내가 생각하는 최고이다.


그러려면, 나는 어떤 역할을 쌓아갈지 고민이 되는데, 이는 해보면서 잘하는 것을 택하면 된다.

(내가 잘하는 부분에서 팀 동료들의 시너지를 올려주면 된다.)


"실리콘 밸리를 그리다"라는 책에서도 코드 리뷰를 잘하는 사람이 다른 일 보다 좀 더 그 시간을 많이 할애하는 것과 같다. 

코드를 작성하지 않는다고 그 역할을 가진 사람을 보고 "일을 덜 하네!"라고 생각한다면, 그 생각을 가진 사람과는 같이 일 하기 힘들다.


내 생각에는 팀 내의 페이스 메이커와 가이드 러너의 역할을 잘 키우는 것이 중요하다. 
그리고 작은 단위에서부터 의견을 위로 올라가야 한다. 그러한 문화를 만들어 가는 것이 좋다.


어떤 의견이든지 "~ 좋은 의견이네요."라고 말하는 습관을 가져 보는 것도 좋지 않을까? 그리고 실패에 칭찬하는 것도 좋은 방법이다.


우리는 대부분 "실패"에 너무 두려워한다. "성공은 실패의 어머니"라 배워 놓고, 정작 실패를 두려워한다. 

그 마인드에서 벗어나게 하는 것도 팀 내의 문화에 따라 달렸다.


그리고 커뮤니케이션은 결국 대화의 방법을 떠나, 상호 존중과 말투(어투) 그리고 종합적인 언어에 따라 달렸다. (음성 언어는 실제로 많이 차지하지 않음.)


내가 바라보는 권한을 가진 사람의 덕목


그리고 작은 결정 권한을 가진 이는 그에 맞게 블라인드 사이드를 항상 조심하고, 빠르게 인지 하여 벗어나는 것을 연습해야 한다.


내가 항상 쓰던 오른손으로 공을 들었을 때, 나의 왼편 시야는 마비된다. 

이를 미식축구에서 Blind Side라고 한다.


결국, 항상 하던 방식을 고집하는 것은
팀 내의 한 부분을 보지 못하게 할 수 있으므로,
그러한 권한을 지녔다면 조심스레 인지 하는 시간을
주기적으로 가져야 하지 않을까?


"급할수록 돌아가라"는 말이 있듯 모든 일은 순서가 있다는 것을 기억해야 한다.


개발자는 어떤 문화가 좋을까? 


일단 내 생각에는 성장할 수 있는 어떤 매개체들이 많아야 하는데, 각 경험치가 비슷한 사람들이 팀 내에 2-3명씩은 포진해 있어야 좋다고 생각한다. 


일단은 무엇을 하든지 열려있어야 하는 부분이 좋다고 생각한다.
그것이 어떤 라이브러리의 도입이라던지? 툴의 도입이라던지를 떠나 모든 의견에 열려야 한다고 생각한다. 

하지만, 안정성도 고려해야 할 포인트이고, 새로운 어떤 것을 도입 함에 있어서 모든 의사결정이 Bottom up approach 즉, 상향식으로 올라가야 하지 않을까? 


결국에는 개발 조직은 유기적으로 스스로 잘 동작해야 한다. 스스로 성장하고, 스스로 나아가는 어떤 시스템이 구축되어야 한다고 생각하는 편이다. 


다른 개발자분의 블로그의 글을 보고 느끼는 바가 많고, 공감이 많이 생겼다. 


개발자가 조직문화에 대해 관심을 가져야 하는 이유의 글을 읽고 나도 공감 많이 하게 되었다. 


개발자는 왜 개발 문화를 만들어 가는데 관심이 없는가? 결국에는 내가 속한 팀에서 어떤 행복도가 소프트웨어 품질에도 영향을 미치고, 일정이나 다른 모든 것들에 영향을 끼친다고 생각하는 편이다. 


그래서 나는 해피아워를 참 좋게 생각하고, 중요하다고 생각한다. 


내가 생각하는 조직 문화는 어떤 모습이어야 하는 걸까? 하는 고민을 항상 하곤 한다. 


어떤 사람들은 그냥 개발만 하면 되지 무엇이 필요하느냐?라는 말을 하곤 한다. 


그리고, 생각해볼 문제로는 다음과 같은데, 어떤 물질적인 것들이 있어야 개발자 문화가 좋은 것인가? 아니면 비물질적인 것들이 있어야 문화가 좋은 회사이고 팀인 것인지 모호할 때가 많다. 


일례로 개발 장비에 대해 금액 없이 지원하는 경우라면, 개발자에게 마냥 좋은 조건인가? 사실, 이 부분은 기본적인 업무 환경에 해당한다고 생각하는 부분이다. (하지만, 많은 회사가 잘 모른다.)


일단 개발자가 속한 곳의 문화가 좋아지려면, 다양한 사고를 가진 개발자들이 많아야 하고, 그들이 어떠한 말이든지 논할 수 있는 환경적인 요소가 준비되어야 한다. 


어떤 주제에 대해 긍정/부정의 의견이 서로 오고 가야 하고, 우리는 생각보다 결정하는 방식에 대해 서투르다고 생각한다. 


긍/부정의 모든 의견이 다 중요한데, 왜 안 좋은 말만 하느냐? 며 치부해버린다면, 부정 의견을 낸 이는 아마 앞으로 의견을 내지 않을 것이다. 

여러 가지 생각을 가진 개발자들이 모인 집단에서 의견이 없거나, 부정의 의견이 없다는 것은 그 대부분의 사람들이 보통 소수의 리드하는 사람의 의견을 따라간다는 말이다. 


한 번 생각해보자. 


나는 일 하면서 어떤 의견을 주로 내는지?
그리고 그 의견들은 팀원들이 어떻게 생각하고, 받아들이는지? 


그리고 조직 내에서 누가 주로 의사결정을 결정하는지?

가끔 팀원 모두 다 같이 생각해볼 법한 문제라고 생각한다. 


1. 우리는 지금 올바른 방향으로 잘 가고 있는지? 

2. 계획했던 일들은 잘 지켜지고 있는지? 

3. 부담스러운 일을 어느 한 사람만 하고 있지는 않은지? 

4. 일정이 너무 빡빡한 것은 아닌가? 

5. 등등..


위와 같은 일들이 대해서 일주일이나 주기적으로 생각해보는 시간을 가지면 좋겠다. (지속 가능한 행복 지수 체크라고 해야 할까?)


그리고, 정량적으로 판단할 수 있도록 체크를 하는 것은 어떨까? (너무 귀찮은 일일까?)


내가 좋아하는 책 중에 한 권인데, 프로그래머로 산다는 것이란 책이고, Deview 2013에서 발표도 하셨다. 


이 책들은 주니어 개발자만 읽는 것보다는 팀 내에서 꾸준히 한 해마다 읽는 것도 좋지 않을까? 

생각하곤 한다. 


이러한 사색 같은 정답 없는 이야기들도 잘 나눌 수 있어야 하는 문화가 준비되어 있다면 좋겠다. 


내가 나아가야 할 방향 


나는 아무래도 리누스 토발즈가 되긴 글렀고, 나는 개발자 인척 하는 직장인이 되기 싫다. 


그래서 내가 할 수 있는 만큼의 한 걸음씩 가고 싶다. 내가 어떤 언어로 개발을 하던지, 내가 하고 싶은 일들이나 해야 하는 일들은 잘 소화해내는 그런 팀원이자 개발자이고 싶다. 


나는 다른 이가 저 친구는 개발 참 잘해!라는 말보다, "저 친구랑 일하면, 뭘 하든 재밌고, 같이 또 하고 싶어!"라고 말할 수 있는 사람이고 싶다. 


요즘은 그런 재미난 일들을 찾기 위해 아이디어를 정리하고 있다. 


이 글을 쓰는 도중 재미난 사이드 프로젝트가 생각났다. 잘 구상을 해보고, 시도를 해보면 재밌을 것 같다. 는 생각을 했다. 




이 긴 글을 읽으신다면, 저와 비슷한 생각을 하지 않았을까? 하는 마음이 무럭무럭 자라납니다. 재미난 일이나 궁금한 이야기 어떠한 이야기도 좋습니다. 
저와 소통을 해주시면 좋겠습니다. 


브런치는 최신 브라우저에 최적화 되어있습니다. IE chrome safari