데이터 과학 유망주의 매일 글쓰기 — 캡스톤 프로젝트 2–2
프로젝트의 트러블 슈팅(Troubleshooting)
# Troubleshooting, #프로젝트
오늘 한일:
드디어 두 번째 프로젝트가 시작되었다. 오늘은 어제 합의한대로 각자 주제를 생각해본 것을 공유하기로 했다. 다행히도 적절한 합의가 이루어졌고, 서로 기획서를 상세히 작성하여 내일 리뷰하기로 했다.
이번 프로젝트를 시작하기 전에, 도우미분들께서 트러블슈팅(Troubleshooting) 가이드라인을 주셨다. 문제의 원인을 파악하여 제거한다는 의미인데, 프로젝트 진행 중에도 활용될 수 있는 개념이라고한다. 프로젝트도 트러블 슈팅이 가능하다는 것이다.
그렇다면 프로젝트를 트러블슈팅 한다는 것은 어떤 의미일까?
프로젝트 트러블 슈팅
프로젝트 트러블 슈팅의 목적은 프로젝트를 진행하면서 생기는 수많은 변수들에 대해 효과적으로 대처하기 위함이다.
먼저 프로젝트를 진행하면서 발생할만한 일반적인 상황들을 확인하고, 진단하고, 수정하는 방법들에 대해 알아보자. 그렇다면, 프로젝트를 진행하면서 마주하게 되는 공통적인 어려움은 무엇일까?
데이터를 파악하기 어려울 때
데이터를 아무리 유심히 봐도 이해하기 어려울 때가 있다. 이럴 때는 데이터의 7V를 확인하는 것이 좋다(1). 지금 데이터에서 이해하기 어려운 문제가 7V에서 어디에 속하는지 확인한다. 먼저 데이터의 특성들을 이해하고, 이해하지 못하는 것들은 세부적으로 왜 이해하지 못하는지 문제를 구체화시킨다. 구체화한 문제를 세분화하는 방법은 하드웨어 문제인지, 소프트웨어 문제인지를 구분하면 좋다.
어려운 점을 파악하기 어려울 때
어려운 점들을 구체화 시켜 정리했지만, 그럼에도 불구하고 무엇을 어려워하는지 모를 수 있다. 그렇다면, 그 어려움을 또 작은 단위로 나눌 수 있는지 본다(모든 문제에서 분할정복(Divide and Conquer)이 왜 유용한 개념인지 알 수 있다.). 어려움은 속성을 가질 수 있는데, 어려움이 지속되는 지속성, 어려움이 반복되는 반복성, 지금 당장은 어려움을 느낄 수 없고 시간이 지나서야 알게되는 시간성, 시간에 관계없는 비시간성 등이 있을 수 있다. 각 속성에 따라 해결할 수 있는 기술적 문제가 다를 수 있기 때문이다.
필요한 배경지식이 부족할 때
정말 하고 싶은 프로젝트를 골랐는데, 그 프로젝트를 하기 위한 배경지식이나 기술적인 지식이 부족할 수 있다. 프로젝트를 위한 시간은 제한되어 있는데, 어떤 지식이 필요한지 감도 안오는 상황이 펼쳐질 수 있다.
이럴 때 해볼 수 있는 가장 좋은 것은, 프로젝트 기획서의 목차를 참조하는 것이다. 내가 어떤 주제를 가지고, 어떤 상황을 가정하여, 어떤 필요성에 의해 프로젝트를 진행하는지 돌아본다. 프로젝트를 통해 실험하고자하는 궁극적인 가설들을 돌아보면, 그 가설을 실험하기 위해 어떤 것들이 필요한지 더욱 파악하기 쉬워진다. 기획서에 들어갈 수 있는 목차를 구체화하고 세분화하는 것이 중요하다.
또한, 원대한 포부는 좋으나 현실적으로 주어진 시간에 할 수 있는 것들에 집중한다. 프로젝트의 규모를 최적화하는 것은 실질적인 완성도를 위해 중요하다. 지금 내가 알고 있거나 가지고 있는 리소스를 파악하여, 그것으로 최대한 할 수 있는 것이 무엇인지 집중한다. 프로젝트에 할당된 시간이 적을수록, 내가 해보고 싶은 것보다는 내가 할 수 있는 것에 조금 더 무게를 두어야한다. 해보고 싶은 것은 내가 할 수 있는 영역의 범위에서 너무 크게 벗어나지 않도록한다.
프로젝트 기획서 트러블 슈팅
프로젝트를 시작할 때는 필연적으로 기획서를 작성하기 마련이다. 그러나 처음에는 하고자 하는 것이 명확하다고 생각해도, 세부적으로 문제를 나눌수록 무엇을 적어야하는지, 특히 가설을 설정할 때 어떠한 기준으로 해야 적절할지 헷갈리는 경우가 생길 수 있다. 프로젝트 기획서는 프로젝트를 진행하면서 평행으로 수정을 해나가는 것이 좋은데, 중간에 필요한 정보가 떠오르거나 얻는 상황이 발생할 경우, 이를 반영하면 기획서가 좀 더 설득력있는 모습으로 변화할 수 있기 때문이다.
그렇다면 프로젝트 기획서를 다듬는데 어떤 문제들이 있으며, 어떻게 대처할 수 있을까?
프로젝트 주제를 구체화하기 어려울 때
막상 하고 싶은 것이 있는데, 그것을 프로젝트 주제로 구체화하기 어려운 경우가 생길 수 있다. 프로젝트 주제는 어떤 것을 원하는지에 따라 다를 수 있지만, 가장 중요한 것은 프로젝트를 통해 “답하고자 하는 질문"이나 “알고자 하는 것"을 명확히 해야한다는 것이다. 하고 싶은 프로젝트의 주제가 내가 프로젝트를 통해 “확인하고자 하는 것"과 거리가 멀다면, 초기 부터 방향 설정을 잘 못 잡을 수 있기 때문이다. 또한, 주제는 특정한 기술을 활용하는데 집중하기 보다, 선택한 주제와 관련이 있는 데이터에서 “어떠한 인사이트를 도출할 것인가?”라는 질문에 집중해야한다.
프로젝트의 분석 방법을 정하거나 해야할 일을 구체화하기 힘들 때
프로젝트를 기획하는데 있어 어떠한 흐름으로 보고서를 작성할 것인지를 염두해 두어야한다. 데이터 분석에 있어 가장 중요한 것은 스토리텔링(Storytelling)이기 때문이다. 내가 프로젝트를 통해 전체적으로 말하고자 하는 것이 무엇인지 집중하여, 그 결론에 다다르기 위해 어떠한 분석 과정을 거쳐야하는지 상상한다. 상상한 내용을 바탕으로 어떠한 흐름으로 프로젝트를 진행할 것인지 목차를 만들어 본다. 목차를 만들면, 전체적인 프로젝트의 틀을 잡을 수 있기 때문에, 어떤 순서로 어떤 방법으로 분석을 해야하는지가 보다 명확해진다. 프로젝트의 주제가 무엇이고, 그것을 설정한 이유를 명확히한다. 어떤 데이터를 선정했으며 그 이유는 무엇인지, 프로젝트를 통해 실험할 가설은 무엇이고 그 이유는 무엇인지, 가설을 실험하기 위해 해야할 분석은 무엇이고 왜 그 방법을 택했는지 등을 분명히한다. 그렇게 나아가면 어느 흐름으로 프로젝트를 진행해야하는지가 보다 명확해진다. 중요한 것은, 프로젝트의 목적과 모든 것이 연결되는 지를 보아야한다는 것이다. 목적이란 이전에 언급한 것처럼 “프로젝트를 통해 답하고자 하는 것"이라 할 수 있다.
프로젝트 주제에 대한 도메인 지식이 부족할 때
프로젝트를 진행하면서 설정한 주제에 대한 도메인 지식이 부족하여, 분석에 어떤 기술을 활용해야할지 모를 수 있다. 이럴 때는, 자신이 관심있는 도메인에서 알고있는 부분에 집중하여, 그곳에서 개선할만한 문제가 있는지 찾아본다. 도메인을 정확히 잘 몰라도, 그 안에서 내가 관심이 있는 분야가 있고, 내가 확실히 알고있는 해결되어야할 문제가 있다면 좀 더 프로젝트의 주제를 세밀화할 수 있다. 세밀화된 주제는 그만큼 알아야할 것들을 줄여주고 필요한 도메인 지식을 찾고 배우는데 시간을 줄여준다.
원하는 프로젝트 도메인이 없을 때
원하는 프로젝트 주제가 딱히 없는 경우는, 기술자체에만 집중하고 그 기술을 어떤 분야에 어떻게 활용해야할지 고민하지 않을 때 발생할 수 있는 문제이다. 프로젝트를 기획할 때 가장 중요한 것은, 기술이 아니라 “해결하고자 하는 문제"가 주제가 되어야한다는 것이다. 예를 들어, “딥러닝을 활용하기 위해 챗봇을 만든다.”가 아니라, “챗봇을 만들기 위해 딥러닝을 활용한다.”가 되는 것이 좀 더 옳다. 하지만, 좀 더 정확한 이유가 필요하다. “고객지원 부서의 수고를 덜어주기 위해, 응답 자동화 챗봇을 만들기 위한 딥러닝 모델을 만든다.” 정도로 만들려는 서비스와 서비스를 위해 사용할 기술을 궁극적인 목적에 기반하여 주제를 정해야한다. 아무리 최첨단 기술을 쓰더라도, 그것을 통해 해결하려고 하는 문제가 너무 쉽다면 오히려 훨씬 더 간단한 기술을 쓰는 것만 못하다.
관심있는 도메인이 명확하지 않은 상태에서는 무리하게 주제를 정해 진행하는 것은 좋지 않을 수 있다. 당장 관심있는 도메인이 없더라도, 평소에 자신이 관심을 가지고 해결해 볼만한 문제들을 생각하고 정리해 본다. 그 중 자신이 가장 잘 알고있는 주제나 해 볼만 하다고 생각하는 것을 주제로 삼는 것이 좋다. 프로젝트의 방향인 주제가 제대로 설정되어야 그에 맞는 방법을 찾거나 생각하는것도 훨씬 더 편해진다. 아직 특정한 도메인 지식이 없다면, 프로젝트의 주제를 최대한 자신이 관심있고 알고 있는 것을 선택한다. 자신이 가지고 있는 지식만으로, 적어도 무언가 해 볼 수 있다는 자신감을 가진 상태에서 시작하는 것이 좋다. 자신감을 어느 정도 가진 상태여야 프로젝트를 성공시킬 가능성이 가장 높기 때문이다.
어떤 기획서 양식을 사용해야 할지 잘 모를 때
기획서를 어떻게 써야하는지, 특히 포맷을 어떻게 가져가야하는지 모르는 경우가 있을 수 있다. 평소 글쓰기와 친하지 않은 사람들에게 발생할 수 있는 문제라고 할 수 있다. 일단 프로젝트의 기획서는 설득을 목적으로 한 문서이기 때문에, 일관성을 유지하여 깔끔하게 작성하는 것이 좋다. 폰트타입, 크기, 색상, 여백 등등을 일관되게 가져가 최대한 정돈된 형태를 보이게끔 하는 것이 좋다. 읽는 사람을 최대한 배려한 기획서 만이 바쁜 현대 사회에서 조금이라도 더 주목을 받을 수 있다.
기획서를 작성하는 팁은 인터넷을 조금만 검색해도 알 수 있는 내용이지만, 기획서의 모든 내용을 어떻게 설득력있게 작성할지에 대해서는 확실한 자료나 근거에 기반해야한다. 가설을 세울 때는 자신의 느낌과 예상에 따라 세우기보다는, 특정한 권위자의 발언이나 언론의 자료를 참조한다면 훨씬 더 설득력을 가질 수 있다. 예를 들어, “이직하는 사람의 비율이 20~30대가 가장 많을 것이다.”보다는, “[한경닷컴, 2020, “데이터 사이언티스트들의 이직"]에 따르면, 데이터 사이언티스트들이 가장 많이 이직한 연령대는 20~30대 이며, 설문에 참여한 이들 중 무려 50%를 차지했다. 그렇다면 ‘20~30대의 데이터 사이언티스트들의 이직율은 전체 연령대에서 50%가 넘을 것이다.’를 가정하고 이를 실험한다.” 처럼 어떤 가설을 세운 이유에 대해 신뢰할만한 근거를 보여주어, 그 가설을 실험하는 이유를 설득력있게 말할 수 있다.
가장 중요한 것은, 기획서 작성도 결국 글쓰기라는 것이다. 그러므로, 자신의 생각을 분명하게 자신의 언어로 정리할 수록 더 쉬워진다. 자신의 언어로 개념을 정리할 수 있는 가장 좋은 방법은 스스로 해당 개념에 대해 글을 쓰면서 자신이 이해한 것을 정리하는 것이다. 글쓰기 능력을 높이고 싶다면, 그만큼 많이 써보는 것이 가장 좋은 방법이다. 평소에 자신이 배운 것이나 관심있는 것에 대해서 블로깅을 해보는 것도 좋은 방법이다. 꼭 기술적인 것이 아니어도 좋다. 관심있는 사회현상이나 최근에 읽은 책이나 본 영화에 대한 리뷰를 할 수도 있다. 명심할 것은, 최대한 꾸준히 글쓰기를 하는 것이다. 그 어떤 형태의 문서화도 글쓰기를 많이 해볼 수록 유리하기 때문에, 글쓰기를 취미로 삼거나 꾸준히 연습한다면, 그 어떤 형태의 문서 작성을 하더라도 언젠가는 그 노력이 빛을 발할 것이라 확신한다.
무엇이 중요한지 모를 때
프로젝트 기획서를 작성하면서 어떤 것에 중점을 두어야하는지 잘 모를 수 있다. 어떤 것에 중점을 두어 분석을 해야 논리적으로 더 설득력 있을지를 헷갈릴 수 있다. 이럴 때는 내가 프로젝트를 통해 도출한 결과물이 실질적으로 어디에 활용될 수 있을지를 생각해 본다. 즉, 이 프로젝트의 결과물이 어디에 쓰일 수 있는지에 대한 실용성이 있어야한다. 프로젝트를 통해 도출한 결과물이 얼마나 더 중요한지는 실용성과 의미에 따라 결정된다. 비록 다른 사람들이 가치가 떨어진다고 생각할 수 있어도, 확실한 근거를 바탕으로 본인이 의미가 있다고 말할 수 있다면 괜찮다(만약 모든 사람에게 승인을 받아야한다면 기초과학에서의 그 많은 노벨상감 연구는 이루어지지 못했을 것이다.)
프로젝트에서 하고자 하는 분석이 얼마나 중요한지를 보아야한다. 해당 분석이 실험할 가설에 얼마나 연관이 있고, 실질적으로 전체 프로젝트에서 얼마나 의미가 있는지를 보아야한다. 전체 프로젝트와 관련성이 떨어지면 중요성이 떨어질 수 밖에 없고, 꼭 필요하지 않은 분석일수도 있다. 시간이 제한적이라면 중요한 분석이 무엇인지 구분하고 이에 집중할 수 있어야한다. 나머지 추가적인 분석은 의미가 있더라도 모든 중요한 업무가 마무리된 후에 수행하는 것이 좋다.
프로젝트에서 하고자 하는 분석이 얼마나 어려운지 가늠한다. 어려운 일일수록 시간이 많이 걸릴 수 있다. 어렵지만 꼭 필요한 분석이라면 중요도에 따라 우선순위를 세우고 각 업무에 따른 시간을 배분한다. 더 필요할수록 우선순위가 높을 것이고, 우선순위가 높을수록 배분되는 시간이 더 클 것이다. 우선순위가 높은 업무는 우선적으로 진행하되, 그것 때문에 다른 것이 진행이 되지 않는 상황이 벌어질수도 있다. 그럴 때는 우선순위를 중요도가 아닌 긴급도에 따라 다시 정리해본다. 그래서 지금 당장 해결해야하는 것을 그때 그때 우선순위에 따라 먼저 처리한다. 그리고 나서 중요한 업무로 돌아와 더 많은 시간을 쏟는 것이 좋다. 결국 프로젝트는 시간관리와의 싸움이다. 화려한 결과를 내는 것보다 하나를 하더라도 충분하고 설득력있는 분석을 하는 것이 중요하다. 너무 많은 분석을 하려하기보다는 꼭 필요한 것들 위주로 프로젝트의 완성도를 높여나가는 방식이 더 효율적일 수 있다.
프로젝트의 기술적 이슈에 대한 트러블 슈팅
프로젝트를 위해 사용하는 툴에 문제가 있을 때
일반적으로 데이터 사이언스에서는 GPU를 지원하는 Google Colaboratory나, 빠른 속도로 Jupyter Notebook의 실행이 가능한 Anaconda환경을 많이 사용한다. 또한, 실제 서비스를 만들어야 할 경우에는 VSCode로 작업을 하기도 한다. 각 환경에서 특정한 모듈을 불려와 사용할 때는 설치해야할 관련 라이브러리(dependencies라고도 한다)를 사용할 모듈에 맞게 설치해 주어야 하는데, 이 과정에서 호환 문제가 발생할 수 있다. 이럴 때는 사용할 모듈의 공식 문서를 참조하여 특정 환경에서 설치를 어떻게 해야하는지, 관련 모듈은 어느 것들이 있는지를 참조하면 좋다. 일반적으로 널리 활용되는 모듈(scikit-learn, tensorflow)같은 경우는 철저하게 업데이트가 되기 때문에 각 버전마다 더 이상 지원하지 않는 기능들이나, 호환되지 않는 라이브러리들을 명확하게 명시한다.
그러나, 활용하고자하는 라이브러리가 실제 회사에서 만든게 아니라 개인이 오픈소스 프로젝트 형태 등으로 만든 것이라면 관련 자료가 부족하거나 없는 상황도 있을 수 있다. 자주 업데이트 되지 않고, 많은 사람들이 자주 사용하지 않는 모듈의 경우에는 관련 싸이트를 반드시 방문하여 최대한 얻을 수 있는 정보들을 얻는다. 이후에는, 관련 모듈을 직접 설치하고 활용해 보면서 어떠한 기능이 지원이 안되고 어떠한 기능이 되는지를 직접 알아보아야한다. 호환성 문제에서 감이 잡히지 않는다면 구글링으로 찾아보면 대부분의 경우에는 어떻게든 비슷한 고민을 한 사람들이 StackOverflow등에 반드시 있을 것이다. 이렇게, 명확하게 설명되지 않은 모듈을 사용하면서 마주하게되는 문제들을 통해서 더 나은 데이터 사이언티스트로 거듭날 수 있다. 어떤 모듈은 무엇이 되고, 무엇이 안되는지, 어떤 것들과 호환이 되는지에 대한 정보를 알고 있으면 나중에 필요한 환경을 조성하여 같은 기술을 활용해 분석을 해야할 때 필요한 모듈을 더 빠르고 쉽게 불러올 수 있다. 결국 구글링이 개발자 뿐만 아니라 데이터 사이언티스트에게도 가장 좋은 문제 해결 도구인 셈이다.
하드웨어 성능이 부족할 때
프로젝트를 수행하는 환경에서 GPU가 없거나 부족할 수 있다. 컴퓨터의 사양이 충분히 따라 주지 않는다면, 현재 적합한 하드웨어를 사용하고 있는지 체크해야한다. 하드웨어 변경이 불가능하다면 사용하고 있는 소프트웨어를 바꿀 수 있는지 체크한다. 소프트웨어가 더 효율적이면 문제가 해결될 수도 있기 때문이다. 윈도우즈에서 안되면 맥OS를 활용하거나 Anaconda가 안되면 Google Colab을 활용해 볼 수도 있다(Colab은 무료로 GPU를 제공한다는 사실!). 프로젝트의 목적에 맞는 소프트웨어가 무엇인지 정의해본다. 어떠한 모듈이 설치되어야 하는지, 특정한 모듈이 성능을 지나치게 잡아먹지는 않는지, 또한 그 모듈이 정말 필요한 것인지 살펴본다.
소프트웨어에 문제가 있을 때
현재 사용하는 소프트웨어의 버전이 맞는지 체크한다. 설치한 dependencies에 문제가 있다면, 서로 호환이 되지 않는 것들을 가능성이 크다. 특정 라이브러리를 활용시 뜨는 에러 메시지를 잘 보면 보통 어떤 것에 문제가 있는지 알려준다. 해당 dependencies를 찾아 관련 documentation을 웹 상에서 찾아보면 보통 어떤 다른 것들과 어떤 버전에 호환되는지 알 수 있다. 때론 운영체제 자체가 소프트웨어의 호환성을 막기도 하는데, 사용하고자하는 소프트웨어가 지금 컴퓨터의 운영체제와 호환이 되는지를 확인하는 것도 중요하다. 만약 호환이 되지 않는다면, 동일한 기능을 제공하는 다른 소프트웨어를 찾아보아야 할 것이다. 예를 들어 맥북에서 한글과컴퓨터의 소프트웨어를 활용할 수 없다면, MS Office나 Google Docs를 활용할 수 있는지 알아본다.
처리할 데이터가 많을 때
선택한 데이터의 용량이 생각보다 너무 클 수 있다. 일반적으로 주어진 환경에서 처리할 수 있는 데이터를 선택하는 것이 좋지만, 매우 큰 사이즈의 데이터를 다루는 상황을 피할 수 없는 경우가 있을 수 있다. 이 때는 데이터에서 가장 중요한 특성들이 무엇인지 확인한다. 중요한 특성에 따라 PCA같은 기법을 활용하여 데이터의 차원을 축소하는 것이 가증할지도 모른다. 자신이 분석하고자 하는 문제에 맞는 특성들만 엄선하면 생각보다 필요없는 데이터를 많이 줄일 수 있을지도 모른다. 그렇다고 너무 많이 줄이면 왜곡된 분석 결과가 나올 수 있으므로, 필요한 특성을 고르되, 되도록이면 열(row)의 수를 줄이지는 않도록한다. 차원을 축소하는 것은 행(column) 단위에서 이루어지는 것이 가장 좋다.
어떤 툴울 활용해야할지 모르는 경우
어떤 툴을 사용해야 가장 좋은지에 대한 감이 안 올 수 있다. 사용하려는 툴이 프로젝트를 통해 답하려고 하는 문제와 어떤 관계가 있는지 확실히 모를 수 있다는 것이다. 가장 먼저 활용하려는 툴이 정말 프로젝트의 문제를 해결하는데 어떤 도움을 줄 수 있는지에 대해서는 답을 할 수 있어야한다. 이 것이 분명하지 않으면, 그 어떤 툴을 가져와도 효율적으로 쓰일 수 없다. 분류 문제에 왜 더 단순한 로지스틱 회귀(Logistic Regression)를 사용하지않고 결정트리(Decision Tree)를 사용하려하는가? 회귀 문제에 왜 더 복잡한 다중선형회쉬(Multi-Linear Regression)가 아닌 단순선형회귀(Single Linear Regression)를 사용하는가? 자신이 풀고자 하는 문제가 무엇이고, 왜 그 문제에 대해 특정 기술을 사용하려하는지 가장 먼저 확립이 되어 있어야한다.
왜 툴을 사용해야하는지에 대한 답을 찾았다고해도, 툴에 대한 정보가 부족해 어떻게 활용해야 할지 모르는 상황도 있을 수 있다. 이럴 때는 툴의 공식 홈페이지에 가서 관련 기술 문서를 읽어보면서 가장 많이 사용되는 버전은 무엇이고 해당 버전에 어떤 기능들이 있으며, 어떤 식으로 사용되는지에 대한 정보를 얻는 것이 좋다. 인기 있는 버전일 수록 더 안정적이기 때문에, 더 많이 쓰일 확률이 높다. 이전에 언급한 것처럼, 호환성도 반드시 체크해야한다. 현재 운영체제에서 사용하려는 툴을 설치할 수 있는지, 다른 툴들과 충돌을 일으키지는 않는지 확인하는 것이 좋다. 툴이 무료인지, 유료인지 확인하는 것도 중요하다.
프로젝트 협업과 커뮤니케이션에 대한 트러블 슈팅
아마도 프로젝트를 진행하면서 가장 중요한 부분일 것이다. 이 세상에 혼자서 모든 걸 다할 수 있는 원맨은 많지 않다. 그렇다 하더라도, 혼자 다 할 수 있을 정도로 현실의 일은 적지 않다. 결국, 다른 사람들과 일을 잘 배분하고 서로의 장점을 최대한 살려 전체적인 일을 잘 진행시키는 능력이 중요하다. 그러자면 팀워크가 중요한데, 팀워크를 하려면 기본적으로 협업을 할 수 있을 정도의 의사소통 능력이 요구된다.
기획시 서로 의견이 다를 때
각 팀원들끼리 같은 도메인이라도 프로젝트를 어떻게 진행해야할지에 대해서 의견이 갈릴 수 있다. 각자가 관심을 갖는 분야가 다르고, 같다고 하더라도 또 세부적인 부분에서도 흥미를 갖는 주제가 다를 수 있다. 이럴 때는, 반드시 어떤 주제를 가져갈지, 좀 더 정확하게는 어떤 문제를 가지고 분석을 할지에 대해서 서로 합의점을 찾아야한다. 프로젝트를 통해 답하고자 하는 질문이 확정되면, 그에 따른 가설이 확정될 것이고, 이에 따라 어떤 방식으로 분석을 진행할지에 대한 방향이 확고해질 가능성이 높아진다. 그렇게 전체적인 틀이 잡히고 방향이 잡히면, 같은 곳을 바라보는 사람들의 목표도 크게 달라지지 않을 가능성이 높다. 설사, 다르다 하더라도 서로 의견을 좁히기가 더 용이해진다.
물론, 모두의 의견이 최대한 존중되는 방향으로 나아가는 것이 좋으므로, 될 수 있는한 모든 사람을 만족할 수 있는데 필요한 분석을 하는 것이 좋다. 하지만, 그렇다고 너무 무리해서 너무 많은 질문에 답하려고 하면 전체적인 분석의 방향이 모호해질 수 있으므로, 서로 원하는 것을 정리하고, 현재 합의를 본 주제에서 서로의 의견이 얼마나 관련성이 있는지에 따라 수용여부를 결정하는 것이 좋다. 서로의 의견에 대한 공통점과 차이점을 정리하면, 그에따라 무엇을 하면 좋고 나쁠지를 알 수 있다.
서로 세부적인 주제에 대해 의견 일치를 보았다면, 어떤 방법으로 프로젝트를 분석할지에 대해서 서로 아이디어를 낸다. 프로젝트를 진행하면서 공통된 결과물을 합치기 전에 서로 분석을 개별적으로 진행하고 합치는 것이 아무래도 가장 효율적인 방법일 것이다. 그렇게 한다면, 서로 생각한 기법들을 활용하여 적용해보고, 그 것을 하나로 합칠 때 회의를 통해 어떤 방법을 통해 한 분석이 가장 효율적이고 문제와 관련성이 높은지를 결정할 수 있을 것이다. 즉, 공통된 부분에서는 어떤 분석 방법이 가장 효율적인지, 차이점에 대해서는 어떤 기술이 관련이 더 깊고 낮은지를 기준으로 서로 논의를 통해서 결과물을 합칠 수 있을 것이다.
중요한 것은, 혼자만 생각하는 것보다, 서로 충돌을 하더라도 활발한 논의와 토의를 통해 최대한 다양한 옵션을 확보하는 것이 좋다는 것이다. 혼자서만 진행한다면 팀플레이를 할 이유가 없을 것이다. 비록, 그 과정에서 의견을 맞춰나가는 것이 소모적으로 느껴지더라도, 이 기회를 통해 모두가 서로로부터 배울 수 있고, 성장할 수 있는 소중한 시간을 가질 수 있기 때문이다. 물론, 서로에 대한 존중을 바탕으로 피드백을 해야하며, 피드백을 주고 받는 것은 절대 개인적인 감정이 개입해서는 안 된다는 것을 전제로한다. 서로의 발전을 위한 말만 할 수 있도록하며, 인신공격이나 근거없는 비난은 하지않는다. 받아들이는 사람도 충분히 근거 있는 건설적 비판이라면 자신의 발전을 위한 기회라 생각하고 겸허히 수용하고 생각해본다. 그러나 절대 개인적으로 받아들여서는 안된다. 생각해보고 정말 고쳐야되는 점이라고 느낀다면, 조금씩 고쳐나가면 되는 것이다. 세상에 완벽한 사람은 없다. 서로 피드백을 주고 받기를 망설이거나 두려워하지말자. “타산지석"이라는 말이 있듯이, 우리가 만나는 모든 사람은 무언가를 가르쳐 줄 수 있는 선생님이다. 그런면에서 공동의 목표를 가지고 같이 일하는 팀원들만큼 좋은 선생님들도 없다.
기획 후 프로젝트 수행시 마찰이 있을 때
기획은 프로젝트의 가장 중요한 시작점이지만, 프로젝트 수행 중에도 서로 의견일치가 일어나지 않을 수 있다. 예를 들어, 특정한 분석방법이나 분석에 대한 해석에서도 서로 의견이 다를 수 있다. 또한 특정 정보의 부재나 설명의 부재가 생각보다 심각하지 않다고 생각하는 사람도 있는 반면, 그렇지 않은 사람도 존재할 수 있다. 또는, 어떠한 문제가 중요하다고 생각하는 사람도 있지만, 다른 문제가 더 중요하다고 생각하는 사람이 있을 수 있다. 이처럼 각자의 시선에 어떤 것이 얼마나 중요한지 우선순위가 다를 수 있다.
의견이 일치하지 않을 때는, 처음에 일어나는 불일치 때문에 초기에는 소통이 잘 안된다고 느낄 수 있다. 그러나, 한번 더 귀를 기울이려는 노력을 한다면, 다른 사람이 왜 그렇게 생각하는지에 대해 이해할 수 있는 가능성이 훨씬 높아진다. 서로의 의견을 듣지도 않고 말하려 하기보다, 최대한 말하고 싶은 사람의 의견을 들어보는 것이 중요하다. 내가 모르고 있거나 못 본 것을 다른 팀원들은 볼 수도 있기 때문이다. 모두가 최대한 발언권을 행사할 수 있게끔 하는 것이 좋다. 단, 서로 다른 의견에 대해 모두 끝까지 들어보는 태도를 갖추는 것을 전제로한다.
프로젝트에서 사람들끼리 이야기를 할 때 발원권을 중재하고 모두가 서로의 의견을 듣게끔 하려면, 한 사람을 프로젝트 매니저로 임명하여 중재 역할을 하게 하는 것도 좋은 방법이다. 열정이 많은 사람들이 모일 땐 정말 좋은 시너지 효과를 발휘하지만, 서로 소통이 잘 안된다면 배가 산으로 갈 확률이 높기 때문이다. 매니저가 중간에서 일정을 계획하고 미팅을 언제할 지, 어떤 것들을 이야기 할지 정리하게 하는 것이 좋다. 미팅에 오는 사람들은 무엇을 이야기할 것인지 알 것이고, 따라서 무엇을 이야기해야 할지 모르면서 시간을 낭비하지 않고, 미팅에 걸리는 시간을 최소화할 수 있기 때문이다.
무엇보다도, 팀원들간 하루에 한번 씩은 미팅을 하지 않더라도 지속적으로 소통을 하는 것이 프로젝트의 성공 확률을 높일 수 있다. 급한 이슈가 생기거나 모르는게 있을 때 미팅시간까지 기다리기 보다는, 단체 채팅 어플 등을 통해 그때 그때 바로 알려주면, 필요한 일을 더 빨리 처리하고 미팅에서 이야기 할 내용을 줄일 수도 있다. 정 필요하다면, 긴급 미팅을 소집할 수도 있다. 모두가 알 필요있는 내용은 아닐수도 있지만, 한 팀원이 무언가에 막혀 있을 때 모든 이들의 집단 지성을 요청하면, 모두가 그 문제에 대해 같이 고민해 볼 수 있다. 더 많은 사람들과 생각해 볼 수록 다양한 시선에서 더 많은 해결책이 나올 수 있기 때문이다.
물론, 너무 쓸떼없는 질문을 많이 하면 시간 낭비가 심할테니, 스스로 노력해서 답을 찾으려 해보고, 그래도 안되면 다른 팀원들의 도움을 구하는 것이 좋다. 물론, 어떻게 질문하느냐도 매우 중요하니, 최대한 어떤 문제인지, 자신이 무엇을 했는지, 무엇이 안 되었는지를 정리하여 물어보는 것이 좋다. 소통에 있어 비용을 줄이려면, 한번에 사람들이 알아들을 수 있도록 전달하는 것이 중요하니, 누군가에게 도움을 청할 때는 항상 이 점에 유의하자.
물어보려는문제를 스스로 최대한 정리하여, 다른 사람들이 나의 질문이 무엇인지 명확히 알 수 있도록한다. 이게 어렵다해도 최대한 질문을 구체화하기 위해 노력해보고, 자신이 어디까지했고 무엇이 필요한지를 분명히 한다면 그것만으로도 충분하다. 중요한 것은, 소통을 자주하되, 효율적으로 해야한다는 것이다.
또한, 팀마다 트러블슈팅 가이드를 문서화 하는 것도 좋은 방법이 될 수 있다. 의견 불일치가 생길 때 서로 돌아가면서 무조건 끝까지 들어본다던지, 결정할 때 투표를 한다던지 등등 내부적으로 상반된 입장에 대한 규정을 만드는 것도 좋다. 이런식으로 협업에 문제가 있을 때, 이를 어떻게 대처해야할지에 대한 합의를 본다면, 앞으로 비슷한 문제가 생겼을 때 어떻게 해야할지 몰라 시간을 낭비하지 않고 최대한 정해진 규칙에 따라 좀 더 효율적으로 프로젝트 미팅을 진행할 수 있다. 물론, 중간 중간에 좀 더 나은 방법을 찾게 된다면, 가이드는 언제든지 업데이트 할 수 있다. 팀 자체적으로 협업을 위한 규약을 통해, 프로젝트 진행시 생기는 문제를 효과적으로 해결할 수 있도록 한다.
프로젝트 기획서에 작성한 일정 및 계획을 계속 참고하면서, 어떤 문제가 우선순위가 높은지를 항상 리뷰하는 것이 좋다. 프로젝트 진행시 어떤 방향으로 나아가고 있는지 감이 잡히지 않는다면, 기획서에 있는 일정 및 계획대로 진행이 되는지를 확인한다. 프로젝트 기획서에 있는 일정과 업무는 반드시 모두 수행해야한다는 생각을 가지고, 기획서에 있는 업무들이 수행되고 있는지 체크하는 것이다. 기획서를 프로젝트 나침반으로 삼아 전체적으로 목표한대로 잘 가고 있는지 체크한다.
결과물 정리할 때 문제가 발생할 때
프로젝트의 마지막 결과물을 정리할 때도 문제가 발생할 여지가 있다. 결과물이 초기에 기획했던 방향과 조금 달라져 보이는 문제가 있을 수 있기 때문이다. 이럴 때는 보통, 기획서에 작성했던 예상결과가 실제 프로젝트를 수행하고나서는 다르게 나올 때라고 볼 수 있다. 어디까지나 기획서에 작성한 것은 “예상 결과"이기 때문에, 실제 결과와는 다르게 나올 수 있다는 점을 가정한 것으로 볼 수 있다. 그러므로 너무 당황해 하기보다는, 어떻게 해서 예상된 결과가 아닌 다른 결과가 나왔는지를 분석의 흐름을 다시 돌아보면서 파악하는 것이 중요하다. 다르게 나온 결과가 충분히 이해가능하고 다른 팀원들에게 설명이 가능하다고하면, 가장 먼저 해당 결과에 대해 자신의 해석을 논리적으로 펴는 것이 좋다. 어떻게 해서 다른 결과가 도출되었는지를 파악했거나 추론할 수 있다면, 팀원들에게 어떻게 해서 예상과 다른 목적지에 도달하게 되었는지에 대해 설명할 수 있다. 팀원들을 이해시킬 수 있다면, 서로가 문제의 원인이라고 생각하는 것들에 대해 아이디어를 공유하면서, 어떻게 하면 예상된 결과를 도출할 수 있을지에 대한 방향을 다시 잡아나갈 수 있다.
실제 결과가 수정 되지 않고 여전히 예상 결과와 다르다면, 도출한 결과가 논리적으로 설명이 가능한 것인지, 이해할 수 있는 것인지를 중점적으로 체크한다. 만약 확실한 근거를 바탕으로 해석이 가능한 결과라면, 예상 결과와 다르게 나오는 것이 옳을 수도 있기 때문이다. 분석에 활용한 데이터를 유심히 다시한번 체크하고, 거기서 발견된 어떠한 속성이 실제 결과를 도출하는데 있어 어떠한 영향이 있었는지를 읽어낼 수 있다면, 충분히 이를 근거삼아 결과를 논리적으로 해석할 수 있다. 즉, 실제 결과가 예상 결과와 “어떻게”다르고 “왜" 다른지에 대한 설명을 할 수 있다면, 프로젝트의 예상 결과를 부정하는 인사이트를 도출했다고 해도 충분히 의미가 있다고 볼 수 있다.
또한, 프로젝트의 일정이나 계획에 따라 결과물이 달라지는 경우도 발생할 수 있다. 생각보다 일정이 빠듯하고 분석이 잘 이루어지지 않을 때는 원래 계획했던 것만큼의 분석을 할 수 없을 가능성이 높아진다. 가장 좋은 것은 “큰 욕심을 내지 않는 것”이다. 즉, 내가 프로젝트를 통해 해결하고자 하는 문제를 정의했다면, 그 문제에 대한 답을 도출하는데 “정말 필요한 분석"들을 가장 우선시 해야한다. 내가 프로젝트를 통해 답하고자 하는 질문에 대해 수행할 분석을 리스트로 만들어, 그 안에서 “필요성"에 따라 우선순위를 정해본다. 내가 하고 싶어하는 것들 중에서 정말 “필요한" 것들이 무엇인지 정의한다. 이후에는, 필요하다고 생각되는 분석 기법들을 “중요성"에 따라 정렬해본다. 필요한 분석들 중 가장 중요한것부터 가장 중요성이 떨어지는 순으로 정리해보면, 내가 풀고자하는 문제에 정말 필요한 분석들을 중요도 순서에 따라 정리할 수 있다. 이렇게 하면, 결과물을 어느 흐름으로 작성해야할지에 대한 큰 틀이 잡힐 수 있기 때문에, 프로젝트를 더 효율적으로 수행하기 더 쉬워진다. 즉, 너무 많은 것들을 하느라 일정이 늦추어지는 상황을 방지할 수 있다는 것이다.
물론, 프로젝트의 완성도를 높이기 위해 시간이 남는다면 꼭 필요하지는 않지만 하고 싶었던 분석을 추가로 수행해 볼 수는 있다. 하지만, 어디까지나 이것은 필요한 분석을 모두 만족할 수준으로 수행했다는 것을 전제로한다. 프로젝트 결과물의 완성도를 신경쓰지않고 무조건 더 많은 분석을 한다고 해서 더 좋은 것이 아니다. 분석을 덜하더라도 그 결과를 논리적으로 설명할 수 있고, 이를 통해 발견한 인사이트의 가치를 보여줄 수 있다면 좋은 분석이며, 그런 분석으로 가득한 결과물이 최선의 품질을 가질 가능성이 높다.
이를 위해서 프로젝트 결과물을 만들기 전에 “목차"를 설정하는 것이 좋다. 목차는 결과물이 어떠한 구조로 되어있으며, 어떠한 흐름으로 결론에 도출하게 될지를 말해준다. 많은 사람들이 간과하지만, 책을 읽을 때 정말 중요하게 주의해서 읽어야하는 부분이 바로 목차다. 목차를 보면 이 책이 나에게 중요한지 그렇지 않은지를 파악할 수 있고, 어디를 중점적으로 봐야하는지 파악할 수 있게 해준다. 결과적으로, 독자로 하여금 필요한 정보를 어디서 찾을 수 있는지 알려준다. 목차를 잘 읽는 사람은 필요한 정보를 얻기 위해 어디에 집중해야 하는지 단번에 알 수 있어, 모든 콘텐츠를 읽지 않고도 효율적으로 시간을 활용해 필요한 정보를 취할 수 있다. 목차는 프로젝트의 흐름을 보여주는 것이기 때문에 프로젝트 기획서를 참조하면서 작성하면 좋다. 프로젝트 기획서에 작성한 흐름에 따라, 일정이나 계획에 있는 분석방법을 모두 활용하여 분석할 수 있도록 목차를 구성하면, 스스로 프로젝트에 대한 큰 틀을 잡고 가이드로 활용할 수 있다. 상대적으로 방향을 잃거나 시간을 낭비할 가능성을 줄임으로써 프로젝트의 일정을 맞추는 데에도 도움이 된다.
추가적으로, 프로젝트 기획서에 작성한 일정 및 계획에 작성한 분석 방법들은 모두 프로젝트 최종 결과물에서 볼 수 있어야한다. 프로젝트의 결과물이 기획서에 있는 모든 내용을 포함하지 않는다면 제대로된 프로젝트라고 볼 수 없다. 프로젝트 기획서에서 계획한 모든 분석 방법들이 수행되었는지, 가설은 제대로 실험했는지를 확인하여, 반쪽짜리 프로젝트가 되지 않도록하자.
발표 자료를 준비하는데 문제가 있을 때
마지막으로, 프로젝트의 발표를 위한 작업도 수행해야할 필요가 있을 수 있다. 일반적으로 파워포인트 프레젠테이션을 많이 활용하는데, 파워포인트를 만드는데 있어서도 서로 의견이 갈리거나 무엇을 발표할지에 대해서 이견이 있을 수 있다. 이럴때에는, 프로젝트 기획서를 바탕으로한 노트북 등의 결과물의 목차를 참조하여 발표 자료를 구성하는 것이 가장 이견을 좁히는 쉬운 방법일 수 있다. 프로젝트를 발표한다면, 기획서를 바탕으로 어떠한 질문에 대한 답을 하려고 했으며, 그에 따라 어떠한 가설을 세웠고, 그 것을 어떤 방법으로 실험했는지에 대한 내용을 명확하게 전달해야할 것이기 때문이다. 이렇게 한다면 프로젝트 발표에 필요한 내용을 전달할 수 있도록 발표 자료를 구성할 수 있으며, 발표 자료를 어떻게 구성할지에 대한 고민과 충돌도 상당 부분 해소할 수 있다.
발표 자료를 구성할 때 텍스트는 최소화하고, 꼭 필요한 내용만 들어갈 수 있도록한다. 프로젝트의 중심 내용을 모두 넣는 요약본으로써 발표 자료가 만들어지면 보는 사람의 입장에서 내용이 너무 많아질 수 있다. 프로젝트 결과물의 내용을 요약한 문장을 넣는 것 보다는, 텍스트를 최소화하고 효과적인 시각화 그래프 및 사진 등을 통해 보는 사람이 간결하고 확실하게 내용을 이해할 수 있도록 한다. 발표를 하는 사람이 프로젝트의 중심 내용을 이해하고 있어야하지 발표 자료가 그 내용을 담고 있어야하는 것이 아니다. 발표 자료는 간결한 텍스트와 시각화 자료등 확실하고도 간략하게 내용을 전달할 수 있는 필요한 콘텐츠만을 담고, 실질적으로 그것이 전달하려고 하는 내용을 해석하는 것은 발표자의 일이다.
또한, 발표를 진행하는 사람이 한 사람이거나 여러 사람일 수 있다. 한 사람이 발표하는 경우, 충분한 연습을 통해 발표의 완성도를 높이는 것이 무엇보다도 중요하다. 특히, 팀이 정리한 발표자료의 흐름을 잘 파악하고 그에 맞게 필요한 내용을 말할 수 있도록하는 것이 중요하다. 구성한 각 슬라이드에 맞는 내용을 말하는 것은 물론이고, 단순히 각 슬라이드에서 보여주는 내용을 읽어내려가는 수준이 되어서는 안 된다. 구성한 슬라이드의 간략한 텍스트 및 시각화 콘텐츠를 해석하여 말해주어야한다. 또한 너무 빠르게 말을 하거나 너무 느리다면 발표를 듣는 사람들의 주의를 잃기 쉽다. 적당한 톤과 충분한 목소리 크기를 유지하는 것도 중요하다. 이를 위해서는 연습 또 연습밖에는 없다.
연습을 할 때는 팀원들이 발표자의 발표를 같이 리허설할 수 있도록한다. 발표자 한 사람만 발표를 한다고 해서 다른 팀원들은 아무것도 하지 말아야하는 것은 절대아니다. 다른 팀원들도 발표를 같이 준비해야할 의무가 있으며, 발표할 사람이 충분히 자신감을 가지고 필요한 내용을 모두 말할 수 있게 같이 노력해야한다. 발표할 사람이 준비한 발표를 들어보고 좋았던 점과 고치면 좋을 점을 분명하게 정리해서 말해준다. 발표자가 긴장되서 말을 잘 못한다면 잘할 수 있다고 격려해주고, 실수한 점이 있더라도 따끔하게 지적하기 보다는 잘한 점을 분명히 말해주고 발전시키면 좋을 점을 확실하면서도 친절하게 이야기해주는 것이 좋다. 발표자는 다른 팀원들을 대표해서 모두를 대신하여 다른 사람 앞에서서 말을 해야할 짐을 지는 사람이니만큼, 그의 역할에 감사한 마음을 갖고 그가 잘 할 수 있도록 독려해주어야한다. 즉, 팀원들은 그의 발표에 대한 평가원들 이라기보다는, 그의 발표를 보완하고 그가 잘 할 수 있도록 지원하는 도우미들이다. 다시 말하지만, 발표는 한 사람만 준비하는 것이 아닌 팀 전체가 같이 준비하는 것이다.
만약 여러 사람이 발표를 진행한다면, 여러 사람이 진행하는 발표는 좀 어수선해지거나 흐름이 매끄럽지 않을 수 있는 가능성이 커지기 때문에, 만약 여러 사람이 같이 발표를 한다면 발표의 흐름이 끊어지지 않도록 서로 맡은 내용을 이어나갈 때 흐름을 유지할 수 있도록 충분히 연습한다. 서로 어느 정도 톤과 목소리 크기, 말의 빠르기 등이 너무 차이가 나지 않도록 하는 것이 좋다. 그 무엇보다도 가장 중요한 것은 연습 또 연습이다. 연습만이 완성도를 높이는 가장 효과적인 방법이며, 각 부분에서 한 사람이 발표하는 동안 다른 사람들은 유심히 그의 발표를 듣고 피드백을 한다. 서로 피드백을 통해 연습의 효율성을 극대화할 수 있도록 한다. 발표까지 잘 마무리 되어야 프로젝트가 잘 완수되었다고 할 수 있는 만큼, 마지막까지 최선을 다할 수 있도록 한다.
발표하는 날은 그 누구도 긴장할 수 있다. 한숨을 크게 쉬고 할 수 있다는 말로 스스로 주문을 외면 좋다. 열심히 준비해 온 만큼, 연습한대로 한다면 큰 문제는 없을 것이다. 실수하더라도 노력한 모습이 보인다면, 그것 그대로 가산점이 될 수 있다. 실수를 두려워 하지 말고 할 수 있다는 마음을 가지고, 모든 팀원들이 발표자와 서로를 독려하고 격려할 수 있도록 한다. 마지막 발표까지 끝난다면, 팀원들은 발표에 대해 지적을 하기보다는 잘했다고 격려해주고, 서로의 노고를 치하하고 축하할 수 있도록한다. 모든 사람이 승자이며 중요하지 않은 사람은 없다. 여기까지 왔다면 발표에 아무리 아쉬운 점이 남더라도 스스로를 자책하거나 서로를 비난해서는 안된다. 모두가 정말 노력한 만큼, 이 순간 만큼은 결과가 어떻더라도 당신은 충분히 즐길 자격이있다. 팀원들끼리 맥주한 잔 마시러 가면서 프로젝트의 피날레를 마무리할 수 있기를!
앞으로 할일:
이번 주 내내 프로젝트를 진행할 때 발생할 수 있는 문제를 트러블슈팅(troubleshooting)하는 방법에 대해 다루었다. 이렇게 정리해보고 나니 앞으로 프로젝트를 진행하는데 있어 주의해야할 것들에 대해 상세하게 알아볼 수 있어 기쁘다. 특히, 프로젝트를 시작하기 전에 팀에서 문제가 생길 때 어떻게 해결해야할지에 대한 규약을 만들어 트러블슈팅 가이드를 제작하는 것이 정말 좋은 방법일 수 있겠다는 생각이 들었다. 앞으로도 참조해 활용해볼 생각이다.
팀 프로젝트를 진행해보니, 여러 사람과 같이 무언가를 이끌어 나간다는 것이 결코 쉬운일이 아님을 많이 느낀다. 아무리 원대한 계획을 세워도 프로젝트의 각 세부적인 문제를 해결하는 것이 혼자할 때보다 시간과 노력이 더 많이 든다는 것을 느낀다. 서로의 이견을 맞추고, 서로의 의도를 효과적으로 소통하는 것이 중요한데, 그것이 결코 쉽지는 않고 서로 조율하는데 생각보다 시간이 많이 걸리기 때문이다. 그래서 소통하는 능력이 중요하다는 생각이 많이든다. 결국, 혼자서 일하는 것보다 훨씬 더 정신적인 소모가 큰 것 같다.
하지만 그럼에도 불구하고 결코 혼자서 모든 것을 다할 수는 없는 세상이다. 여러 사람이 일을 나누어서 분업을 해야하는 것이 일반적인 세상이니 만큼, 반드시 협업하는 법을 배워야 사회에서도 유용한 일꾼이 될 수 있다. 답답하더라도 조금 더 다른 사람의 말을 들어보려고 노력하자. 거기서 내가 생각하지 못한 , 새로운 것을 배울 수 있으며, 내가 미쳐 놓치고 확인 못한 것이 무엇인지 깨달을 수 있다. 항상 내가 틀릴 수 있다는 겸손함을 가진다면, 다른 사람의 말을 듣기도 더 쉬워지고, 더 빨리 발전할 수 있는 가능성도 커진다. 무엇보다도 “내가 항상 옳다”는 고집을 갖지 않는 것이 좋다.
중요한 것은 서로 건강한 피드백이 이루어지는 팀이 되어야한다는 것이다. 서로 의견이 다르더라도 감정적으로 상하게 할 수 있는 언행과 행동은 피한다. 팀원들은 프로젝트를 성공적으로 마무리하고 팀워크를 함양해 새로운 것을 배우고 경험할 목적으로 모인 사람들이지, 서로가 좋아서 감정적으로 모인 사람들은 아니라는 것을 기억하자. 만약 그렇다면, 처음부터 잘 못 짜여진 팀이다. 서로가 한 팀으로 모인 가장 큰 목적이 무엇인지 생각해보는 것이 좋다. 거기서 부터 한 팀의 성공 가능성이 상당부분 결정날 수 있다. 프로젝트를 진행하기 전에 서로가 “왜” 모였는지에 대한 확실한 답을 할 수 있다면, 프로젝트를 진행하는 동안 그 어떤 불일치가 생기더라도 협력하고 이해하며 나아갈 수 있는 가능성이 커진다. 이 것이 확립된다면, 이후부터는 이 글에서 설명한 방법들을 활용하여 프로젝트를 원활하게 진행하기가 더 쉬워진다.
이번 두 번째 프로젝트는 이전에 혼자했던 프로젝트에 비해 더 간단하면서도 명확한 문제를 다루었다. 처음에는 “이 것만으로 충분할까?”라는 생각이 들었지만, 시간이 지날수록 “이 정도도 잘된다면 정말 좋겠다.”는 생각이든다. 협업하는 과정에서 서로의 의견을 잘 반영하여 최대한 완성도 높은 프로젝트를 수행하는 것이 중요하다는 생각이 든다. 그것이 용이하기 위해서는 조금이라도 더 서로가 공통적으로 이해할 수 있는 명확한 문제에 대해 답을 하는 것이 좀 더 방향성을 갖기 쉽고, 서로 협업하기도 용이하기 때문이다. 프로젝트의 “화려함"보다는 “완성도"에 집중하여, 너무 어렵지 않으면서도 실용적인 인사이트를 내놓을 수 있다면 충분히 의미있는 프로젝트가 될 것이라고 생각한다. 모든 문제들은 일정 및 주어진 자원에 기반한 현실적인 조건을 고려해야한다. 그 안에서 최선의 결과를 내는 것이 최고의 프로젝트라고 생각한다. 이번 기회를 통해 나도 협업을 할 수 있는 사람이 되었다고 말하고 싶다. 아직 끝나지 않았지만, 앞으로 남은 1주일 동안 다른 팀원에게도, 또 나에게도 서로 만족스러운 프로젝트로 기억되었으면 한다. 서로가 서로에게서 새로운 것을 배우고 경험할 수 있는 시간이었다면, 그것 만으로도 이 프로젝트는 서로에게 값진 경험이 될 것이라 믿는다. 한 팀의 소중한 일원으로써, 이 세상에서 일하는 모든 이들에게 “화이팅"이라 외쳐주고싶다!
참조:
