JeroCaller

쌓여만 가는 빈 캔

25 분 소요

팀 프로젝트를 하면서 기술적인 부분도 배운 점이 있지만, 팀플의 방향성, 태도 등 개발 외적인 부분에서도 많은 것을 고민하였고, 그 덕분에 조금이나마 배웠던 점들도 있었다. 이번 시간에는 이에 대해 서슴없이 말해보고자 한다. 참고로 어쩌면 조금 민감할 수도 있는 사안들도 여기서는 최대한 문제가 되지 않는 선에서 자유롭게 말해보려고 한다. 이것들도 사실 팀 프로젝트에 대해 나 개인적으로 배운 교훈들이기에 절대 무시할 수는 없다는 생각에서이다. 절대 누군가를 비방하려는 목적이 아니라 순수히 팀플과 개발에 대해 얻은 교훈을 기록하기 위한 목적임을 알아주길 바란다.

팀을 구성하는 요소 - 친밀감도 무시 못한다

팀플에 대한 내가 겪은 것들을 말하기에 앞서 먼저 배경지식으로 말하고자 할 게 있다. 사실 이전에 팀 프로젝트에 대한 글을 다룰 때에도 잠깐 언급한 내용이지만, 나는 학원을 다니면서 의도치 않게 총 3개의 팀을 겪었었다. 이는 학원 자체에서 3번의 팀 프로젝트의 기회를 제공해서가 아니었고, 안 좋은 이유로 팀이 2번이나 중도해체되어서 의도치 않게 팀을 이곳저곳 옮기게 되었기 때문이다. 그럼에도 세 번째 팀에서는 잘 정착하여 무사히 하나의 팀 프로젝트를 마칠 수 있었다.

이 챕터에서 내가 이야기하고자 하는 교훈은 첫 번째로 겪은 팀과 연관되어 있다.

처음으로 학원 개강일에 들어선 이후로 내 기억으로는 아마 두 달 후 쯤에 처음으로 팀 프로젝트를 위해 팀을 처음으로 구성할 때쯤이었다. 그 이전에 나는 이미 한 명의 수강생과 친해진 상태였다. 팀을 구성하기 전에 나는 그 친구와도 팀 구성에 대해 이야기를 나눴고, 나 스스로도 이에 대해 고민을 했던 게 있었다. 그것은 바로 “친밀감”이었다.

결론부터 말하자면, 원래는 강사님이 지정해주는 대로 팀에 들어가는 수밖에 없었다. 그러나 강사님께서는 최대한 친한 사람들끼리 팀을 구성해주것을 고려하겠다는 말씀을 하셔서 우리 둘은 결국 용기를 내어 따로 말씀을 드렸다. 그 덕분에 다행히도 우리 둘은 같은 팀에 들어갈 수 있었다.

이렇게 보면, 이러한 의문을 떠올릴지도 모르겠다.

“아니 팀 프로젝트면 성과와 실력을 올리는 게 중요하지 친한 사람들끼리 모여서 하는게 그렇게 중요한가요?“

이 질문에 나는 당당하게 이렇게 답하고 싶다.

“반은 맞고 반은 틀린 답이네요”

물론 친한 사람들끼리만 모여서 팀을 구성하면 그 팀에 실력 있는 사람이 있으면 모를까, 실력도 거의 비슷하다면 실력 발전의 여지가 없는 것은 기정 사실이라 봐도 무관할 것이다. 하지만 나는 굳이 애써가면서 친했던 학우와 같이 팀을 하려고 했던 이유가 있었다. 그리고 그 이유는 사실상 이 첫 번째 팀이 해제된 이유와도 직결된다.

나는 사실 처음 팀을 구성하기 전부터 예감했었다. 팀을 구성할 때 고려할 요인 중 하나로 친밀감도 무시 못한다는 것이다. 그래서 나는 친해졌던 그 친구와 같이 팀을 하고 싶었다. 그 친구는 실력과는 상관없이, 열심히 하려는 모습도 있었기에 나는 그 친구와 같이 팀을 하고 싶었었다. 그렇게 결국에는 같은 팀이 될 수 있었다. 내가 이 학원에 들어서면서 처음 맺은 이 팀을 편의상 여기서는 “퍼스트 팀”이라 부르겠다.

그런데 시간이 지나면서 “퍼스트 팀”에는 한 가지 문제가 생겼다. 바로 소통 부재였다. 사실 다른 팀들에 비해서 우리는 서로에 대해 친해질 시간을 별로 갖지 못했고, 어떻게 친해져야 할지도 모두 모르는 상황이었다. 게다가 지금와서 생각해보면 “퍼스트 팀”의 이러한 소통 부재 문제를 더 악화시킨 요건 중 하나로, 너무 많은 휴일이 있었다는 점이었다. 추석에 개천절에 무슨 휴일이 많이 껴있어서 서로 만날 기회가 별로 없었다. 나야 따로 친구와 같이 둘이서 카페에서 만나 팀프로젝트를 할 수 있었지만, 팀 전체적으로 만나진 않았다. 추석을 맞이하기 전에 서로 해야할 일들을 분담만 한 채 추석 내내 연락은 없었다. 나중에 다른 팀 이야기를 들어보니 다른 팀들도 추석 때에는 다들 고향에 내려가는 사람들이 있으니 팀플에 대한 이야기를 꺼내는 게 조심스러웠다는 이야기도 나왔었다.

그리고 이러한 소통 부재 및 소극적인 소통의 문제점은 학원에서 서로 모여서 팀플 회의를 할 때에도 드러났다. 나를 비롯한 모든 인원들이 내성적인 성격이라서인지, 아니면 팀플의 앞으로의 방향성을 우리 모두 몰라서였는지는 몰라도, 팀 회의를 할 때 모두 소극적이라는 느낌을 받았다. 물론 이는 나도 그랬었다. 그래서인지 생각보다 회의 진도가 잘 나아가지지 않았었다고 지금 되돌아보면 그리 생각된다. 각자가 그래도 할 일을 하긴 했다. 그래서 중간에 모여 어디까지 했는지 각자 발표할 때에 이미 자신의 작업을 완료한 사람들이 꽤 있었다. 그럼에도 소극적인 소통의 문제는 지속되었다.

사실 그 당시의 팀장님도 자신이 팀을 잘 이끌지 못한다는 생각이 들어 따로 강사님께 이에 대해 말씀을 드렸다고 한다. 그로 인해 “퍼스트 팀”은 강사님과 같이 모여서 이에 대해 의논을 했었다. 그리고 결국 팀을 해제하자는 옵션과, 팀장을 바꾸더라도 팀을 존속시키자는 옵션이 나왔었다. 이 때 당시가 아마 목, 또는 금요일이었던 걸로 기억한다. 그리고 결정은 다음 주 월요일?에 해달라고 강사님이 말씀하셨다.

주말이 껴 있었다. 그런데 지금 와서 생각해보면 그 주말에도 팀끼리 서로 소통을 하지 않았다. 나는 그 당시에는 “설마 정말로 팀이 해제되겠어? 왜냐면 그런 의사를 다들 명시적으로 표시하지 않았으니까”라는 생각이었어서 계속 하던 프로젝트를 지속하였다.

그리고 월요일 당일, 결국 투표에 의해 “퍼스트 팀”은 해체되었다. 나는 처음부터 해체에 반대 입장이었다. 그럼에도 해제 찬성에 표가 조금 더 많아서 어쩔 수 없이 그 팀은 해제되었다.

내 친구도 해제에 반대 입장이었었다. 나보다도 더 그 결정에 받아들일 수 없다는 입장이었다. 그래서 다시 강사님께 해제된 팀을 다시 결성하도록 할 수 없냐고 설득하자는 이야기도 했었다. 하지만 나는 그 때에는 입장이 뒤바뀌었었다. 사실 팀을 해체하고 싶다는 사람이 팀 내에서 한 명이라도 있다면 그 팀은 사실상 끝장난 것이나 다름없다. 팀을 해체하고 싶다는 사람과 어떻게 더 이상 같이 팀을 할 수 있단 말인가? 그런데 심지어는 해체하고자 하는 사람이 다수이다. 이 사람들과 어떻게 다시 팀을 할 수 있는가? 이미 “팀을 같이 하고 싶지 않다”라고 본심을 내뱉은거나 다름 없는 상황에서 다시 팀을 결성할 수 있겠는가? 하더라도 오래 가지 못해 또 똑같은 이유로 해체될 게 뻔했다. 그래서 나는 친구의 그런 입장을 극구 말렸다.

투표 결과가 있기 전까지 내가 팀 해제에 반대했던 이유는 다음과 같았다.

  • 팀 해제 시 기존에 있던 나머지 두 팀 중 한 팀으로 들어가야 했는데, 이것 자체가 그 팀에게는 민폐라 생각했기 때문이다. 그 팀들 입장에서는 가만히 있다가 갑자기 연대감이 생기지 않은 새로운 사람들과 같이 협업을 해야하는 갑작스런 상황에 놓이는 것이다. 그렇기에 팀을 해제하자는 건 나 살자고 남에게 피해를 끼치는 이기적인 행위라고 여겼기 때문이다.
  • 팀이 커질 수록 내가 팀에게 기여하는 바가 작아질 수밖에 없다. 1/n이라 생각하면 된다. 이 팀 프로젝트는 후에 포트폴리오로도 사용될 것이기에 걱정했었다. 물론 이는 나중에 강사님 말씀으로는 남의 코드도 이해할 수만 있다면 문제 없다고 하셨다. 차라리 그 팀 프로젝트를 나 혼자서도 구현할 수 있느냐를 면접관분들이 물어보신다고 한다.
    • 그런데 이 때 당시에는 알지 못했던 문제점이 “퍼스트 팀” 해제 후 “세컨드 팀”으로 재편성되었을 때 드러났는데, 팀의 팀원이 너무 많아져 코드 스타일의 통합 문제, 팀원들 간의 실력 차가 있어 학원에서 배운 내용 중 고급 기술을 프로젝트에서 제외시킬지 그대로 포함시킬지 등의 문제도 있었다.

참고로 내가 수강했던 과정은 전체 6개월 과정 중 전반 3개월을 담당한 강사님과 후반 3개월을 담당한 강사님이 다르다. “퍼스트 팀” 해제는 전반기에 일어났던 일로, 나중에 후반기 강사님이 이 사정을 들으시고는 “그 때 그 팀 해제되었으면 안됐어”라고 말씀하셨다. 그 말씀은 지금도 여전히 공감이 간다.

어쨌거나, “퍼스트 팀”이 해제된 이유로는 크게 두 가지라 볼 수 있다.

  • 소통의 부재 또는 소극적인 소통
  • 이러한 소통의 부재를 극복하고 팀을 규합할 수 있는 카리스마형 사람의 부재

솔직히 두 번째 문제에 대해서 나는 전혀 그 때 당시의 팀장님을 탓하고자 하는 마음이 추호도 없다. 그건 나를 비롯한 그 팀 모두의 문제라고 생각하니까. 팀장이 아니더라도 팀원 중에 적극적이고 팀원들을 규합할 수 있는 사람이 있다면 충분히 팀장의 자리를 대신할 수 있다고 생각한다. 그리고 그것은 실제로 그 당시 다른 팀에서도 일어나고 있던 일이었다. 그 팀은 회의만큼은 팀장이 아닌 다른 사람이 주도적으로 이끌어갔다. 그걸 보았기에 내가 이렇게 주장할 수 있는 것이다. 팀원이라고 해서 무조건 팀장이 하라는 거에만 따르고 소극적으로 임하라는 법은 없다. 그럼에도 그 당시 “퍼스트 팀”에는 나를 비롯하여 팀을 이끌어갈수 있는 사람이 한 명도 없었기에 결국은 해제되었다고 생각한다.

이 일련의 스토리를 통해 나는 더더욱 “친밀감의 중요성”을 깨닫게 되었다. 그리고 왜 회사에서 자꾸 팀원들과 회식을 하려는지도 감을 잡을 수 있었다. 회식도 모두 팀 내 팀원들간의 화합과 친해짐을 위해서였다. 이러한 화합이 결국에는 팀 협업으로도 이어져 원만한 의사소통을 할 수 있고, 불필요한 오해를 방지할 수 있다는 점을 이 일화를 통해 간접적으로 깨달았다.

만약 “퍼스트 팀”이 마치 나와 그 친구가 그랬던 것처럼 모든 팀원들이 서로 친밀해질 수 있었다면 그럼에도 과연 팀 해체라는 파국을 맞이했었을까? 팀을 구성하는 데에 있어 친밀감은 절대 무시 못하는 요소임을 분명하게 증명하는 일화라고 생각한다. 그래서 사실 서로 모르는 팀원들이 팀이 되었을 때 아이스 브레이킹부터 먼저 하는 게 중요한 것 같다. 이걸 하느냐 안하느냐에 따라 이후 팀 분위기가 너무 달라지는 것 같다.

이 일화로부터 몇 개월이 지난 후 멘토링에서 멘토님께서는 이런 말씀을 하셨다. 회사에서는 사실 내성적인 사람을 싫어한다고. 그리고 그 이유로 딱 소통 문제 때문이라고 꼬집으셨다. 내가 “퍼스트 팀”에서 몇 주간 겪었던 일을 그 분께서는 단 한 문장으로 날카롭게 지적하셨다. 물론 그 분은 내가 겪었던 “퍼스트 팀” 이야기를 듣고 하신 말씀은 아니셨다. 그 분은 이 히스토리를 전혀 알지 못하실 것이다. 그 분이 그런 말씀을 하실 수 있는 건 분명 멘토님도 현업에서 그러한 문제를 겪으셨기 때문이라 생각된다.

이러한 “퍼스트 팀”의 일화로 인해, 이후 중간 프로젝트 후부터는 나도 적극적으로 의견을 제시하고 소통을 하려고 노력했다. 강의 시간에는 누군가 에러가 발생하여 진도를 나가지 못할 때 적극적으로 앞서서 에러 원인을 파악하고 이를 알려드렸다. 이러한 과정 하나하나가 모두 협업에서의 소통 능력과도 직결된다고 생각한다. 그리고 마지막 세 번째 팀인 “써드 팀”에서는 나도 회의 때마다 적극적으로 아이디어를 내고, 모르는 것이나 막히는 점이 있다면 서슴없이 팀장님께 보고드리기도 했다. “퍼스트 팀” 경험 덕분에 이렇게 조금이나마 성장할 수 있었지 않나, 라는 생각이 든다.

아, 아까 회식 이야기가 나와서 말이지만, 그렇다고 누군가 너무 꼰대짓하거나 술만 펑펑마시려는 목적의 회식은 나도 피하고 싶다. 팀원들간의 친목을 위한거라면 기꺼이 가겠지만 그런 분위기의 회식은 정말 상상만 해도 싫다.

설령 코딩 잘한다고 해도 팀장이 될 수 있는 것은 아니다

학원에서는 강의 시간에 어떤 개념을 배우고 나면 꼭 그 개념에 대한 문제를 강사님께서 제시하셔서 모든 수강생들이 풀어야했었다. 푼 답을 그 강의실에서만 공유하는 온라인 메신저에 올려 강사님을 비롯한 모든 수강생이 볼 수 있도록 하는 구조였다. 이후에 강사님이 말씀하시길, 이 메신저에 올린 답들도 학생 평가에 반영할 거라고 하셨다. 푼 답이 정답이건 오답이건 상관없이 성실하게 문제를 풀어 올렸느냐에 중점을 두신 것 같았다.

그러다보니 자연스레 나도 그렇고 다른 이들의 코드를 볼 수 있었다.

그래서였을까… 어느 순간부터 내가 코딩을 잘한다는 소문(?)이 그 강의실 내에서 퍼지게 되었다. 이는 첫 팀 구성할 때부터 내 친구를 비롯한 다른 수강생 분들이 알려주셔서 알게 되었다. 나중에 듣기로는 같은 수강생들뿐만 아니라 전반부 강사님도, 후반부 강사님도 나에게 같은 평가를 하셨다고 한다.

강사님들도 그렇게 평하셨으니 거기에 대해 내가 “아뇨 전 실력 없습니다”라고 말하기도 애매했다. 난 실제로 내 실력이 그렇게 뛰어나다고 생각하진 않는다. 강사님께서 일전에 모든 수강생들에게 “자기가 잘한다고 너무 거들먹거리지 말아라. 나 같은 강사들과 현직자 입장에서는 다 거기서 거기다“라고 말씀하신 적이 있다. 나도 거기에 크게 공감하는 바였다. 내가 아무리 잘한다 한들, 설마 현직 5년차 개발차보다 잘할까.

그럼에도 그러거나 말거나 수강생들에겐 내가 “코딩 잘하는 사람 중 한 명”으로 각인되어버렸다. 그게 좀 솔직히 말하자면, 조금, 아니 많이 부담스러웠다. 차라리 팀 프로젝트 이전까지는 아무런 평가를 받지 않다가, 팀 프로젝트에서 “이야~ 님 되게 잘하시네요”라고 평가받는게 훨 낫다. 팀플 전에 괜히 코딩 잘한다는 이야기 듣다가 정작 팀플에서 삐긋하면 “아 뭐야, 실망이네”라고 할게 뻔하니까.

그 후부터 몇몇 분들이 나에게 팀장을 하라는 제의를 많이 하셨다. 내가 인생에서 팀장은 커녕 협업 자체를 한 일이 그리 많지 않았기에 자신이 없어 결국에는 팀장을 하지 않았는데, 이에 대해 오히려 아쉬워하거나 답답해하는 분들도 계셨다.

실제로 지금와서 나 자신에 대해 스스로 평가하자면 문제 풀 때보다 팀플할 때 더 실력을 발휘하지 못했다는 생각이 든다. 실제로 내가 설계를 잘못했었던 경험도 있고 하기 때문이다. 그리고 오히려 이전에는 아무런 평가가 없었던 몇몇 팀원 분들이 팀플에서 실력을 제대로 발휘하는 사례가 있었다. 문제와 실전은 좀 다르긴 한가보다.

‘아, 문제 적당히 풀걸, 매번 너무 진심으로 풀었어…’

그 당시나 지금이나 나에게는 코딩에 대해 일종의 “강박관념”이 있다. 코드를 최대한 깔끔하고 정돈있게 작성하려는 강박관념. 오죽했으면 문제 중에 자꾸 파일 입출력 코드가 반복되게 나와서 이 dirty한 코드의 반복에 그만 정신을 잃고 빡쳐버린(???) 나는 아예 그 부분을 라이브러리화하여 세 문제 연속 그 라이브러리를 이용하여 푼 적이 있었다. 참고로 그 라이브러리가 바로 아래에 첨부한 내 깃허브 레포지토리에 아직도 남아있다.

https://github.com/JeroCaller/jeca_java_libs

아무튼 그러한 것 때문에 내가 그런 평가를 받았나, 라는 생각이 든다.

서론이 길었는데, 이 챕터에서 내가 말하고자 하는 것은 이게 아니다. 내가 말하고자 하는 것은 이 챕터의 제목에도 나와있듯이, 설령 코딩을 잘한다고 해서 그 사람이 팀장도 잘할 수 있다는 것은 아니라는 것이다. 이건 나 자신을 저격하는 말이기도 하다.

내가 포함되어있었던 강의실에 나보다도 훨씬 실력이 좋다고 생각되는 사람이 한 명 있었다. 이는 다른 모든 이들도 동의했다. 이 분은 나와는 전혀 딴 판의 스타일이었는데, 그 짧은 시간 안에 코딩에 대해서 스스로 이런 저런 다양한 신기술들을 빠르게 발견하고 이를 그 짧은 시간안에 다른 이들에게도 쉽게 설명하는 스타일이었다. 내가 생각해도 이 분은 그냥 “괴물” 그 자체였다. 그리고 그 분은 후에 한 팀의 팀장이 되었었다. 나는 그 분의 팀원이 되지는 못했었지만 그래도 같은 강의실이었기에 항상 옆에서 보고 들을 수 있었는데, 팀도 정말 잘 리드하셨다. 항상 새로운 기술 또는 방법을 찾아내어 해결하고, 팀원들에게 앞으로의 프로젝트 방향을 명확하게 제시했다고 생각한다. 게다가 어떤 개념에 대한 설명도 정말 잘하셔서 우리 강의실 내에서 알게 모르게 모든 이들에게 인정받는 분이셨다. 후반부에 공식 팀 프로젝트가 끝나면 팀을 나눠서 서브 프로젝트를 하라는 강사님의 지시가 있었는데, 그 당시에 그 분의 모든 팀원들이 해제하기 싫다고 할 정도였다. 뭐 결국에는 다른 이유들로 인해서 그 팀은 해제가 되지 않고 수료 때까지 끝까지 함께 갔었다.

참고로 후반부 강사님이 요새 트렌드에 맞춰서 이왕이면 AI나 데이터 분석 같은 기술을 조금이라도 넣을 수 있으면 넣으라고 하셨는데, 그걸 유일하게 해낸 사람이다. 파이썬을 이용하여 AI 챗봇을 만들었다고 한다. 오죽하면 오히려 이후에 강사님께서 “우린 자바로 취업할 것이니 너무 AI에 많은 힘을 쏟지 말라”라고 할 정도였다. 그만큼 기존에 강의 시간에 배웠던 기술 뿐만 아니라 스스로 외부 기술도 탐구하고, 그걸 빠르게 프로젝트에 녹일 줄 아는 사람이었다.

나만 그런게 아니라, 다른 수강생들도 이 분에 대해 “넘사벽”이라고 극찬을 하였다. 그만큼 정말 넘사벽이었다. 이 분을 보니 나는 더더욱 이 생각을 굳힐 수 있게 되었다. “코딩만 잘한다고 팀장이 될 수 있는 건 아니다”라고.

정작 코딩을 잘한다는 평을 받던 나는 팀장은 되지 않았지만 그래도 중요한 작업을 맡았었는데 내가 설계를 잘못해서 시간이 오래 걸렸었다. 또한 ERD를 팀장님과 같이 설계를 할 때에도 내가 판단을 잘못해서 하나의 테이블을 두, 세개로 나눴는데, 이게 정작 프로젝트를 하다보니 오히려 코드를 복잡하게 하는 원인이 되어 멘토님의 조언을 듣고서야 문제점을 파악하고 이를 해결할 수 있었다. 나는 오히려 실전에서 실수를 했던 것이었다.

만약 이런 내가 팀장이었다면 과연 팀을 올바르게 이끌어갈 수 있었을까? 그런 의미에서 나는 더더욱 “코딩 잘한다고 팀장 역할도 잘한다는 건 아니다”라는 주장이 설득력 있다고 느껴진다. 애초에 리더 자질이 있는 사람이 리더 역할을 잘 수행한다고 생각한다. 팀장으로서 팀을 잘 이끄는 방법, 뭐 여러 번 연습하면 될 수도 있겠지만, 그걸 시간이 제한된 상황에서 포트폴리오에 올라갈 중요한 팀 프로젝트에서까지 연습하기엔 부담이 너무 컸다.

오해하지 않았으면 좋겠다. 내가 맡은 작업을 무책임하게 버리겠다는 의미는 전혀 아니다. 나는 팀원일 때 설령 설계를 잘못하는 실수를 저질렀더라도 무책임하게 다른 사람에게 내 할 일을 이유없이 위임해버린다든가 한 적은 절대 없다. 내가 한 실수 내가 책임지고 고치려고 노력했고, 내가 맡은 작업은 반드시 끝을 봤으며, 아이디어 회의 때에도 적극적으로 의견을 내어 여러 방향을 제시하려고 노력했다. 그리고 앞으로도 내가 맡은 일 최선을 다할 것이고, 적극적으로 임할 것이고, 실수를 최소화하기 위해 꾸준히 공부할 것이다. 다만 이 일화에서 내가 핵심적으로 이야기하고자 하는 것은 단 한 줄이다.

설령 코딩 잘한다고 해도 그것만으로 팀을 잘 이끌 수 있는 팀장이 될 수 있는 것은 아니다.

다시 한 번 말하지만, 난 생각보다 코딩을 잘하는 편이 아니다. 그렇기에 앞으로도 계속 노력할 것이다.

팀 분위기는 삼각 함수 그래프처럼 - 언제든 분위기는 역전될 수 있다

팀의 분위기가 항상 일정하지 않고 파도마냥 이랬다 저랬다할 수 있다는 걸 팀 프로젝트를 하면서 느꼈다. 다른 팀은 초반에는 갈등이 심해 학원을 그만두겠다는 사람까지 나왔다고 한다. 그런데 시간이 지나면서 이 갈등이 잘 해결되어 마지막까지 평화로운 분위기를 이어갔다. 나는 다른 팀이었기에 그 갈등을 구체적으로 어떻게 해결했는지는 모르겠지만, 처음에는 “와, 분위기 심각하네. 해결할 수 있을까?”란 의문이 들었는데 그게 또 가능하더라.

그런가하면 초반에는 분위기가 좋다가 나중에 가선 분위기가 험악해지기까지 하는 경우도 있었다. 불행히도 이는 내가 포함되어 있었던 “세컨드 팀”에서 벌어졌었다. 지금에 와서 돌이켜보면 몇몇 팀원들의 성격과 협업 방식을 생각해볼 때 이미 예정된 결과가 아니었을까, 생각이 들지만 그 때 당시에는 갑자기 그렇게 될 줄은 몰랐었다.

인생사 새옹지마라고 하더니 팀 분위기도 좋다가 나빠지기도, 나빠지다가 좋아지기도 한다. 그러니 혹시라도 이런 거에 일희일비하지 않는 것이 좋겠다.

태도와 분위기도 팀 프로젝트에 매우 중요하다 - 나는 누구와 일하고 싶은가

팀 프로젝트를 하다보면 누군가는 실수를 하기 마련이다. 또는 다른 이에게 대해 어떠한 답답함이 있을 수도 있겠다. 그러면 이를 어떤 “태도”로 임하여 풀어나갈 것인가? 그럼에도 예의를 지켜가며 차분하게 다른 이와 대화로 풀어가려고 할 것인가, 아니면 강압적인 태도로 화까지 내면서 비난하고, 얼굴엔 항상 불만인 상태를 대놓고 티내면서 임할 것인가? 아마 전자가 당연한게 아닌가 생각하는 분들도 계실 것이다. 하지만 현실에서는 생각보다 후자인 경우가 있다. 옆에서 경험한 이로써, 후자는 이유가 어찌되었건 협업을 하는 최악의 방식임을 명심했으면 좋겠다.

누군가 실수를 할 때 정 화가 난다면 단 둘이 있는 공간으로 이동하여 둘이서 따로 푸는 게 좋음을 깨달았다. 누군가 실수를 했다는 이유로 다른 팀들까지 있는 공용 공간에서 공개적으로 화를 내며 지적하는 이가 있었고, 한 두번이 아니었다. 당하고 있는 사람 입장에서는 얼마나 창피하고 모욕스러웠을까, 하는 안타까운 마음이 생겼었다. 그 뿐만 아니라 본의 아니게 다른 팀들에게도 갑분싸를 일으켰다. 순식간에 그 공간 자체의 분위기가 얼어붙었다. 이 얼마나 민폐인가! 정 안되겠으면 어떻게든 둘 만의 공간으로 대피하여 풀도록 하자. 공개적으로 남들이 있는 앞에서 지적하는 행위는 자신은 그런 의도가 아니었더라도 그 사람에 대한 인격적 모독이 될 수 있는 최악의 행위임을 알았으면 좋겠다.

또 한 편으로는 “왜 이걸 안하느냐”는 식으로 대놓고 특정인에게만 화를 내는 사람도 있었다. 회의를 할 때에도 항상 어딘가 불만인 태도를 가졌다. 한 번은 화가 난다는 이유로 다른 팀들이 있는 공용 공간에서 자신이 화가 났다는 티를 크게 내어 그 공간에 있던 모든 사람들에게 갑분싸를 내기도 하였다.

이를 통해 나는 여러 가지 교훈들을 깨달았다.

  • 자신의 감정 컨트롤이 중요함을 알았다. 아무리 화가 나더라도 적어도 다른 이들이 있는 앞에서 이를 크게 티내면 좋지 않음을 알았다. 정 못 참겠으면 다른 이들이 없는 공간으로 빨리 이동하는 것이 더 나을 수도 있다.
  • 팀 프로젝트와 협업도 인간과 인간끼리의 활동이다. 즉, 사회 생활이다. 어떤 상황이 오더라도 사람 간의 기본적인 예의를 지키자. 생각보다 이 기본적이고 당연한 상식을 잊는 이들이 적지 않다.
  • 너무 팀장에게만 의지하지 않는 소극적인 팀원이 되지 않는 게 좋겠다. 자신이 팀원이라도 이런 저런 의견을 주도적으로 내어 팀의 방향성에 기여하려고 하자. 아무리 팀장이라고 하더라도 팀장도 결정하기 힘든, 또는 어떻게 해야할지 전혀 알 수 없는 경우도 있다. 팀장에게만 의존하려고 한다는 것은 사실상 어미가 먹이 주기를 기다리며 목을 길게 빼고 입만 벌리는 아기새에 지나지 않게 된다. 이렇게는 문제가 해결되지 않는다.

이 교훈들을 토대로 이후에 마지막 “써드 팀”에 들어갔을 때도 나는 이 규칙들을 최대한 지키려고 했다. 때로는 답답할 때도 있었지만 최대한 예의를 지키려고 하였고, 대화를 할 때에도, 메신저를 이용하여 회의를 할 때에도 문장 하나하나, 말 하나하나까지도 다시 한 번 생각하면서 “음 이건 듣는 이가 기분 나쁘지 않을까?”를 항상 최우선으로 생각했었다. (그러다보니 슬랙과 같은 메신저를 이용하여 회의를 할때 항상 글을 썼다가 지웠다가를 반복했던 적이 많았다) 그러면서도, 팀장도 해결하기 힘든 문제가 왔을 때 정답은 아니더라도 내 의견을 서슴없이 제시하며 여러 가지 해결책을 떠올릴 수 있도록 적극적으로 임하려고 노력하였다.

말투의 경우, “아니 이거 이렇게 하면 안돼요? 왜 자꾸 이렇게 하는거에요?”라는 말투보다는 “이건 이렇게 했으면 좋겠습니다. 어떠신가요?”라면서 항상 적어도 중립적인 말투를 지키려고 애썼다.

가끔 SNS나 인터넷 커뮤니티를 보다보면 회사에서 같은 말이라도 어떻게 말하느냐에 따라 느낌이 달라진다는 이야기를 종종 보았는데, 이 과정을 몸소 겪으니 말의 중요성도 확연히 느끼게 되었다.

강압적인 분위기의 팀에서 활동하면 안 좋은 점이 하나 더 있다. 자유로운 의견도 내기가 힘들어지고, 내가 뭘 놓쳤는지 다시 물어보는 것조차 어렵다는 것이다. 이는 의사소통의 측면에서도 매우 안 좋은 결과를 낳는 셈이다.

이러한 일련의 과정을 거치고 나니 또 한 편으로는 “나는 어떤 회사와 일하고 싶은가”에 대한 어쩌면 근본적일 수도 있는 질문도 떠올랐다. 학원이고 배우는 입장이라지만 여기서의 팀 프로젝트는 어떻게 보면 회사에서 진행하는 협업과 큰 틀에서 차이점이 없을 것이라 생각한다. 단지 사용하는 기술의 전문성과 체계성 등이 다를 뿐 이것도 사람과 사람 사이의 인간 관계이자 사회 생활인건 다를바가 없을 것이라 생각한다.

어떤 회사는 뭐만 잘못하면 바로 화를 내고 분위기를 얼어붙게 만드는 곳도 있을 것이다. 또 어떤 회사는 그럼에도 차분하게 대화로 풀려고 하는 곳도 있을 것이다.

나는 확신할 수 있게 되었다. 누군가에게 결점이 있더라도 거리낌없이 서로 도우려고 하고 어떤 일이 있더라도 분위기를 좋게 유지하려는 회사에서 일하고 싶음을.

그리고 협업은 절대 “롤”이 아님을.

팀원이 많다고 좋은 게 아니다 - 팀원이 많을수록 오히려 퀄리티는 저하되고, 진행 속도는 더뎌진다

확실히 팀원의 수가 많으면 오히려 일을 효율적으로 끝내지 못하는 것을 경험하였다. 강사님 말씀대로 4~6명이 적당한 것 같다. 그 이상으로 많으니 다음의 문제점들이 있었다.

  • 프로젝트 전반적인 코드의 통합성이 부족했다. 예를 들어 스프링 부트를 이용하여 REST API를 제작할 때 누군가는 “서비스” 단에서 “Map” 자료구조를 이용하여 응답 데이터를 보내기도 하였고, 또 누군가는 “컨트롤러”단에서 “DTO” 클래스를 이용하여 응답 데이터를 보내기도 하였다. 그러다보니 전체적으로 통일되지 못한 인상을 주었다. 이러한 문제는 특히 팀원의 수가 많을수록 코드 컨벤션을 미리 엄밀하게 정하는 것의 중요성을 부각시켰다. 구현이 먼저라는 이유로 구현에만 힘을 쓰고 나중에 코드 스타일을 통합하려고 하니 인원도 많아서 오히려 더 힘들었다. (이렇게 보니 누구나 참여 가능한 오픈 소스 프로젝트는 어떻게 그렇게 잘 유지되는걸까, 신기하기도 하다)
  • 기술 난이도 선택에도 문제가 있었다. 어떠한 기술을 사용함에 있어서 누군가는 이를 이해하는게 쉽지 않다고 한다. 이럴 경우 다른 몇몇 팀원을 위해 기술 난이도를 낮출 지, 아니면 조금이라도 경쟁력 있는 포트폴리오를 위해 그대로 기술 난이도를 올린 채로 유지할지에 대해서도 충돌이 생길 수 있다.
    • 이에 대해서는 물론 너무 어려운 고난이도 기술의 적용은 부적절할 수도 있겠지만, 어느 정도는 난이도 있는 기술을 택할 수 있음에 문을 열어야 된다고 생각한다. 솔직히 단도직입적으로 말하자면, 어려우면 공부하면 된다. 무릇 개발자라면 그러한 마인드를 가져야한다고 생각한다. 반대로 난이도를 낮춰버리면 포트폴리오로서의 매력, 프로젝트의 퀄리티가 떨어져 이는 사실상 “다 죽게 되는 것”이나 다를바가 없다. 또한, 난이도가 있는 기술을 자꾸 회피하려고 하면 오히려 원하고자 하는 기능 구현에 한계가 온다. 조금 극단적인 예를 들어서, AI 기술이 너무 어렵다는 이유로 이 기술을 사용하려고 하지 않는다면, AI 챗봇, 사용자 추천 알고리즘, AI 생성 이미지 활용 등 여러 가지 가능한 기능들을 구현할 수 없게 된다.
  • 분담의 문제도 있었다. 인원이 많다보니 한 사람이 한 페이지를 구현할 수 있는 걸 여러 사람이 달라붙게 될 수밖에 없었다. 그러다보니 내가 할 수 있는 일이 적어지고, “내가 팀에 기여하고 있는게 맞나?”란 생각이 들기도 하였다. 더 많은 일을 할 수 없음에 오히려 아쉬웠었다. 또한, 인원이 많아 일을 최대한 잘게 분해하여 분담하다보니 내 입장에서 이해해야하는 다른 이들의 코드양이 훨씬 많아져 이것대로 힘들었다.

어쩔 수 없는 이유로 팀원의 수가 많을 수밖에 없었지만, 역시 너무 팀의 규모가 커도 좋지 않음을 몸소 느꼈다.

초보자가 팀플이란 고난을 헤쳐나가는 방식 - Greedy Search VS A-star

그래프 이론에서, 어떠한 target 노드를 찾기 위한 알고리즘들 중 하나로 Greedy Best-First Search (간단하게 Greedy라고 하겠다)와 A-star 알고리즘, 이 둘이 존재한다.

Greedy 알고리즘은 가장 인접한 노드들의 정보만을 토대로 target 노드를 찾는 알고리즘이다.

그림 1. 이진 트리 내에서 가장 큰 숫자 찾기. [1] 참조.

그림 1. 이진 트리 내에서 가장 큰 숫자 찾기. [1] 참조.

위와 같은 트리 구조가 있고, “2”라고 적힌 노드에서부터 출발하여 모든 노드들을 통틀어 가장 큰 숫자인 “100”이 적힌 노드로 나아가는 것이 목표이다. Greedy 알고리즘은 바로 인접한 노드들 중 가장 큰 수를 가진 노드로 이동하는 알고리즘이다. 즉, 눈 앞의 이익에만 집중하는 알고리즘이라 보면 되겠다.

그러다보니 위 그림의 경우, Greedy 알고리즘을 이용하면 결국에는 “100”에 도달하지 못함을 알 수 있다. “2”부터 시작할 때 가장 인접한 노드는 “4”, “25”뿐인데, 이 중에서 가장 큰 “25”로 나아가는 알고리즘이기 때문이다.

즉, Greedy 알고리즘은 그 방식이 단순하다는 장점이 있지만, 항상 최적의 해를 찾는다는 보장이 없는 단점을 가진 알고리즘이다.

이번에는 미로를 떠올려 보자. 이 미로 속에서 컴퓨터가 조종하는 캐릭터를 출발점에서 결승점으로 이동하도록 하는 것이 목표이다. 이러한 경로 찾기 문제를 해결하는 알고리즘 중 하나로 A-star 알고리즘이 있다.

이 알고리즘은 현재 캐릭터의 위치와 결승점의 위치라는 정보를 가지고 진행한다. 미로는 흔히 위에서 보면 x, y축이 있는 2차원 그래프로 그릴 수 있고, 각각의 위치들을 (x, y) 좌표로 나타낼 수 있을 것이다. 이 때, 현재 캐릭터의 위치 (x1, y1) 좌표와 결승점의 위치 (x2, y2) 좌표가 있을 때 이 두 위치의 거리 차를 |x2 - x1| + |y2 - y1| 로 계산한다. 이를 맨하탄 거리((Manhattan distance) 측정법이라 한다. 이 맨하탄 거리가 가장 작은 쪽으로 캐릭터를 움직이다보면 결승점에 빨리 도달할 수 있다는 것이 A-star 알고리즘의 핵심이다.

Greedy와 A-star의 차이점은 보면 알겠지만, 결국에 “정보를 가지고 있느냐”가 큰 차이점이라 볼 수 있다. 전자는 결승점에 대한 정보가 없어서 어쩔 수 없이 인접한 노드들의 정보만을 가지고 결승점을 찾아야했지만, 후자의 경우 이미 결승점의 위치 정보를 가진 상태에서 진행하기에 조금 더 정확하게 결승점에 도달할 수밖에 없을 것이다. 이러한 차이점 때문에 실제로 Greedy와 같은 알고리즘을 Uninformed Search라 하고, A-star와 같은 알고리즘을 Informed Search라고 분류하기도 한다.

팀 프로젝트와 협업에 대한 이야기를 하다가 왜 갑자기 뜬금없이 그래프 알고리즘을 얘기하느냐? 팀 프로젝트를 진행하는 방식도 이와 비슷하게 적용할 수 있다고 보기 때문이다.

사실 생각해보면 팀 프로젝트를 성공적으로 마치기 위해선 Greedy 알고리즘처럼 눈 앞에 바로 생각나는 대로 계획없이 진행시키는 것보다는 A-star 알고리즘처럼 체계적으로 계획을 세우는 것이 더 좋은 방법이라는 것은 상식적으로 생각해봐도 자명한 일일 것이다. 그런데 후자대로 하려면 한 가지 대전제가 따른다.

“우리가 뭘 알고 있고, 뭘 모르고 있는지를 제대로 알고 있다.”

내가 이 챕터에서 말하고자 하는 핵심은, 때로는 문제를 해결할 때 Greedy적인 사고방식도 필요하다는 것이다. A-star 방식처럼 모든 걸 처음부터 다 계획하려고 하는 방식이 오히려 때로는 모든 문제를 해결할 수 없음을 강력하게 말하고 싶다.

나를 비롯하여 거의 대부분의 수강생들은 당연히 IT, 개발 분야를 실무적으로 경험해본 적이 없기에 팀 프로젝트를 어떻게 이끌어야하는지조차 모르는 게 태반이었다. 특히나 팀플 초창기에는 팀플의 방향성에 대해 조언해줄 사람이 사실상 없었다. 그러다보니 과하다싶을 정도로 전체 회의를 하는 경우도 부지기수였다. 그렇게 전체 회의를 오랜 시간동안 거쳐도 해결되지 않는 문제들이 많았다.

전체 회의를 너무 많이 오랫동안 거친 이유 중 하나로 컨셉의 문제였다. 하필 ERP라는 전혀 처음 들어보는, 그리고 난이도도 꽤 있어보이는 주제를 가지고 진행하다보니 컨셉을 어떻게 확장할 지 몰라 기나긴 회의를 거쳤던 경험이 있다. Manager들을 관리하는 Admin 개념을 추가하는 것을 고려하여 어떻게 할지 구체적으로 그림을 그려나가다가 ERD 상에서 모순이 발생하여 오랜 시간의 회의가 무의미해진 경우도 있었다.

또 ERP의 가장 애매한 점은, 어떤 새로운 기능을 도입, 구현하려고 하면 그 새로운 기능과 ERP라는 테마가 어울리지 않는다는 것이었다. 어떤 회사의 인사, 자원 관리가 정체성인 ERP이다 보니 음식점 추천 사이트나 다른 테마의 사이트처럼 이런 저런 기능을 넣는 게 정체성의 일관성적인 측면에서 쉽지 않았다.

지금에 와서 생각해보면 ERP 정체성과 조금 맞지 않더라도 이런저런 기능들을 넣어보는게 어땠을까 싶긴 하다. 이런 저런 기능들을 넣는 것을 가정한다면 어떤 기능을 넣을지, 그리고 그 기능을 위해 페이지 내 버튼이나 링크와 같은 요소들을 어떻게 배치할지까지를 팀 전체가 모여서 하기보다는 각자 어떤 기능을 맡을지만 분담하고 페이지 구성 요소들은 각자가 자율적으로 판단했으면 더 좋지 않았을까 싶다. 너무 자세한 것까지도 팀 전체가 모여 결정하려고 하니 회의 시간이 더 길어지고 힘들어지기만 했다.

그래서 어느 정도부터는 Greedy처럼 진행하는 게 좋다고 생각한다. “어떤 기능을 넣을까, 또 페이지 구성은 어떻게 할까”에 대해서는 각자 팀원들이 자율적으로 생각해보는 Greedy 방식이 오히려 더 빠른 결과를 낳을 수 있지 않았을까, 란 생각이 든다. 자세한 것까지도 마치 중앙 정부가 모든걸 계획하려고 하는 것 같은 A-star 적인 방식을 취하니 오히려 아이디어가 나오지 않았다. 아이디어는 때로는 혼자서 고민해야 더 잘 나올 때도 있는 법이다.

이 외에도 어떤 팀원이 코드 상에서 어떤 기능이 구현되지 않고 막혀서 전체 회의를 할 때도 있었다. 노트북 없이 바로 모였는데, 솔직히 코드 문제는 직접 노트북으로 코드를 이것저것 작성해보면서 문제를 해결하는 Greedy 방식으로 했어야 했는데 이상하게도 “어떻게 할까요?”만 제시했을 뿐 문제되는 코드도 공유하지 않았고, 각자가 노트북으로 해결해보는 시간도 가지지도 않고 이조차도 너무 “계획”적으로 진행하려고 했던 게 지금 와서 생각해보면 의아하다.

이렇게 팀 프로젝트가 처음인 상태로 진행하다보면 뭘 어떻게 해야할 지 모르는 경우가 은근 많았다. 앞서 예를 들었던 알고리즘을 다시 예로 들면, 사전 정보조차 주어지지 않은 것이나 마찬가지이다. 그런데 이러한 문제를 마치 정보가 있는 것처럼 A-star 방식으로 진행하려고 하니 오히려 문제가 풀리지 않았다. 대부분 머리속으로만 구상하려고 했다. 그래서 어느 순간부터는 “일단 이것저것 해봐야하는 거 아닌가?”라는 Greedy 적인 방식의 필요성을 느끼기 시작했다.

우리가 만약 5~10년차 경력 개발자라면 한 눈에 봐도 “아 이건 이렇게 하면 되겠네”, “아, 이건 이렇게 하면 안되겠네”라고 바로 답이 나올 수도 있겠다. 그러나 우린 그런 경력이 없었다. 이렇게 경험이 부족하다면 오히려 “이판사판이다”식으로 이것저것 시도해보는 마인드가 필요하다고 생각한다. 그러면 분명 그로 인해 생성된 결과물이란 게 눈에 보이기 시작하고, 그걸 토대로 앞으로의 방향성에 대해서도 논의해볼 수 있기 때문이다. 경험없는 우리에게 필요했던건 다름 아닌 “눈에 보이는 것”이었다. 작성한 코드가 있었기에 코드의 문제점이 무엇이고 어떻게 리팩토링할 것인지 알 수 있는 것처럼, 너무 오랜 기간 고민할 시간에 이것 저것이라도 만들어보면서 눈에 보이도록 했으면 좋았지 않을까, 라는 생각이 든다. 어떤 기능이 떠올랐다면 이를 빠르게 프로토타입마냥 간단히 만들어서 이를 공유해보았다면 적어도 “아, 이건 ERP에 어울린다, 아니다 어울리지 않으니 빼자”라는 게 가능하지 않았을까. 그 때 당시 그 팀의 큰 문제점이 바로 이거라고 생각한다. 너무 아무것도 하지 않고 고민만 오래 했다는 것이다.

어느 순간부터 머리로 해결책을 떠올리려고 해도 전혀 안 떠오른다면 차라리 이런 저런 모든 가능한 경우의 수를 직접 부딪혀보는 건 어떨까. 그게 더 좋은 방법일 수도 있다. 장고 끝에 악수를 둘 수 있기 때문이다.

팀 운영 방식 - 중앙집권형 VS 지방분권형

한 가지 흥미로웠던 점이 있었다. 대부분 팀들이 운영 방식을 팀장의 권한이 높은 소위 “중앙집권형”으로 운영하려했던 반면, 다른 팀 하나는 반대로 팀 안에 소규모의 팀들을 다시 나누고 그 소규모 팀들끼리 협업하는 방식의 “지방분권형” 방식으로 진행되었다는 것이다. 그리고 놀랍게도 결과적으로는 “지방 분권형” 방식이 팀 내 갈등도 적었고, 진행 속도도 더 빨랐었다.

중앙집권형 방식으로 팀이 잘 운영되려면 팀장은 다음의 재능들이 있어야 한다고 생각한다.

  • 빠른 판단력
    • 어떤 일을 누구에게 분담하는 게 가장 적절한지를 아는 판단력
    • 어떤 문제가 있고, 이에 대해 팀원들 간의 의견이 첨예하게 갈릴 때 어떤 의견이 올바른지를 판단할 수 있는 능력
    • 마감기한이 얼마 남지 않은 것에 비해 남은 일이 많을 때 이를 어떻게 해야할 지 빠르게 판단할 수 있어야 한다.
  • 카리스마형 리더
    • 팀장의 의견을 모든 팀원들이 따를 수 있도록 하는 능력.
    • 물론 이 경우 팀원들도 팀장을 잘 따라야한다는 전제 조건이 붙긴 한다.

이렇다보니 오히려 팀장이 부담스러운 구조의 운영방식이 된다.

여기에 더해, 만약 어떤 팀원이 문제를 해결하지 못하고 있을 때 그 문제가 팀 전체에 얼마나 중요한지 그 중요성을 따지지 않고 무조건 팀장에게 보고하는 방식이 된다면 더더욱 팀장이 부담스러운 구조가 되고, 그렇다고 이럴 때마다 매번 전체 회의를 여는 것도 비효율적인 구조가 된다.

그런데 지방분권형 방식은 그 구조 자체만으로도 앞서 말한 문제점들을 간단하게 해결할 수 있다.

  • 어떤 팀원이 어떤 문제를 해결하지 못해서 도움을 요청할 때 해당 팀원이 속한 소규모 팀 내에서 해결할 수 있다. 만약 그 팀 내에서도 해결하지 못한다면 이 문제는 자동으로 심각성이 높은 문제라고 판명되는 것이나 마찬가지이다. 그래서 어떤 문제가 모든 팀원들과 모여 해결해야할 문제인지, 아니면 몇 명의 팀원들의 합심만으로 해결할 수 있는 문제인지 판별하기 쉬워진다. 이로 인해 불필요한 전체 회의를 줄일 수 있다는 효과까지 노릴 수 있다.
  • 팀장이 느끼는 부담이 중앙집권형에 비해 한층 적어진다. 이것이 중요한 이유는 단순히 팀장의 심적인 이유 뿐만 아니라, 부담이 적어진 팀장은 오히려 팀의 전체적인 진행 과정과 방향성과 같은 큰 틀을 볼 수 있게 되기에 팀을 위한 현명한 판단이 가능해지기 때문이다.

어떠한 팀이 성공적으로 프로젝트를 마치려면 오히려 팀장이 너무 많은 일을 짊어지면 안된다는 것을 깨달았다. 팀장의 부담이 적어야 오히려 팀장은 그 팀을 잘 이끌 수 있게 된다. 모험을 떠나는 한 척의 배를 떠올려보자. 만약 선장이 선원들의 끼니 해결을 위한 요리사의 역할도 하고, 배 내부에 있는 물자 관리의 역할도 하고, 선원이 할 수 있는 일까지 도맡아한다면, 과연 선장은 그 배를 올바른 방향으로 이끌 수 있을까? 암초에 충돌나지만 않으면 다행일 것이다.

학원 초창기 내가 다른 이들을 대했던 마인드 - 잠시 “실력”은 넣어두고

학원을 다니기 시작한지 아직 2개월도 되지 않았을 무렵, 단순히 개인적으로 강의를 들으며 학습하던 방식에서 조금씩 벗어나 팀을 구성해야하는 시기가 다가왔었다. 이 무렵 벌써부터 친해진 친구가 한 명 있었다. 그런데 그 친구는 벌써부터 자신의 실력이 부족함에 대해 스스로 안좋게 생각하고 있던 모양이었다. 나는 “우리 모두 처음인데 벌써부터 실력이 좋을 순 없잖아. 열심히 하려고 하는 태도만 있으면 돼”라는 식으로 설득을 하였다. 이는 실제 내 생각이기도 하다. 6개월을 지나 수료한 지금쯤이야 이젠 실력도 생각해야 하는 시기이긴 하지만 그 당시에는 고작 학원을 다니기 시작한지 1, 2개월밖에 지나지 않았던 참이었다. 그 시간은 아직 실력을 논하기에 충분치 않은 시기라 판단하였고, 모두 처음인데 실력이 미숙하다는 이유로 그 사람을 배척한다는 것은, 여기가 회사도 아니고 엄연히 무언가를 배우러 온 학원이란 곳인데 벌써부터 그런 사고방식을 가진다는 것은 굉장히 차별적이라는 것이 내 생각이었고, 지금도 그 생각은 틀리지 않았다고 생각한다.

물론 곁에 실력 있는 사람을 두는 것은 배울 점이 있기에 실력을 향상시키는 측면에서 좋은 방법이다. 실력 있는 사람과 같이 하고 싶은 본능과 실제로 그렇게 하는 것은 잘못된 것이 아니다. 하지만 너무 “실력”만을 바라보면 자연스레 실력이 상대적으로 안좋은 사람들은 팀 선택에서도 소외되기 마련이다. 회사였다면 회사는 당연히 이윤 추구를 제 1의 목표로 하기에 실적을 제대로 내지 못하는 직원을 해고시킬 수도 있을 것이다. 이건 잘못되었다고 생각하지 않는다. 하지만 학원이라면 이야기는 달라진다. 회사와 달리 학원은 말 그대로 무언가를 배우는 곳이다. 그렇다는 것은 당연히 해당 분야에 대해 잘 모르는 사람들이 오는 게 맞다. 만약 모든 걸 안다면 왜 학원에 오겠는가? 그런데 벌써부터 그 친구가 자신의 실력에 대해 의구심을 품었고, 이것이 설마 팀 선택 시 위축감으로 이어질까봐 걱정했었다. 그리고 설마 학원, 그것도 아직 초반기에 벌써부터 “난 실력없는 사람하고는 같이 하기 싫어”라는 마인드를 가진 사람이 혹여나 있을까봐 이에 대해서도 걱정이 되었었다.

처음 학원에 들어가는 분들에게 이것을 말하고 싶다. 실력 있는 사람과 같이하고픈 본능이 혹여나 다른 사람을 소외, 차별시키는 결과로 이어지지 않았으면 좋겠다는 것을. 학원은 회사가 아님을. 회사가 “실력 증명의 장”이라면 학원은 “기회의 장”임을. 그렇기에 이 시기에 벌써부터 지나친 “실력주의” 사고방식을 가지고 실력이 상대적으로 떨어지는 타인을 업신여기지 않기를.

References

[1] Greedy Algorithm

What Is a Heuristic Function? | Baeldung on Computer Science

[2] Greedy, A-star 알고리즘 (내 블로그 글)

[알고리즘][그래프] A* 알고리즘 & Greedy Best-first search

This content is licensed under CC BY-NC 4.0

댓글남기기

참고