첫 회고록
2021년 6월 7일부터 16주간 진행되는 항해99 부트캠프에 등록 후 한주가 지나게 되었고, 내가 무엇이 부족하고 필요한지를 잘 알게된 시간이였다. 그리고 새로운 도전을 하고 있다는 사실에 굉장히 즐겁고 흥분된 시간이였다. 또한 부트캠프를 도전하면서 10년간 한가지에 미쳐있었던 과거의 나를 떠올리며, 그때의 나의 모습이 떠올라 살짝 미소를 짓는 순간이 많았다. 비록 조금 늦은 나이에 도전했지만 해보지도 않고 포기하는 것은 내가 살아온 방식이 아니므로 도전해보고 후회하고자 한다. 다만, 지금껏 도전하고 후회한 적이 없지 않은가.
이번 미니프로젝트를 진행하면서 공부한 기술에 대한 회고를 할까도 생각했지만, 그 지식을 제대로 습득했다고 말할 수 없었고, 내가 자신있게 쓸 수 있을때 제대로 적어보고 싶었다.
그리고 회고록은 말 그대로 내가 배우고 느낀 것에 대한 회고의 시간을 가지는 것이기에 1주일에 한번 WIL 적는 시간에는 내 생각을 온전히 풀어보고 싶다. 공부만큼 중요한 것이 나를 돌아보는 것이지 않는가.
그리고 공부에 대한 부분은 TIL 부분에서 다루면 충분하다고 생각하기에 TIL에서 적겠다.
나는 왜 개발자가 되고 싶은가?
부트캠프에 들어와 프로젝트를 진행하면서 머릿속에 한가지의 의문이 이전보다 더 나를 자극하게 되었는데, 그것은 바로 "나 자신이 왜 개발자가 되고 싶은가?"를 전보다 더 깊게 생각하는 계기가 되었다. 이것은 개발의 시작함에 있어 가장 중요한 부분이라서 더욱 느끼게 된 것 같다. 이것을 명확히 하는 것과 아닌 것의 차이는 굉장히 크단 것을 너무나 잘알고 있기 때문이다.
사실 부트캠프에 들어오기 전 개발공부를 독학하면서 정의내렸던 부분이기도 한데, 프로젝트를 진행하다보니 내가 내렸던 정의는 단순히 목적을 이루기 위한 수단의 도구로 개발이란 것을 택한 느낌이 강하게 들었다. 이 느낌이 든다는 것은 내가 제대로 깊게 생각한 것이 아니란 것을 몸에서 신호를 보내는 것이므로...
부트캠프를 진행하면서 앞으로 20년, 30년, 혹은 평생동안 해야할 개발을 도구로만 인식하게 된다면 결국 개발에 대한 흥미를 잃거나 매너리즘에 빠져 현실에 안주하게 되었을 때 굉장히 힘들 것이라는 것을 경험을 통해 잘 알고 있기에 이것을 더욱 깊게 생각해봐야 할 문제이다.
단순히 '개발하는 것이 재미있어서', '개발문화가 좋아서', '새로운 도전을 위해' 등의 정의로서는 나의 업에 대한 정의가 너무 초라하지 않은가...
이것에 대한 정의를 내리는 것이 그 무엇보다 중요하단 걸 알지만 이것을 정의하는데 절대 짧은시간 안에는 할 수 없다는 것을 잘 알고 있다.(개발자에 도전하기 전까지 했던 일에 대한 정의를 명확히 내린 것도 거의 10년이 걸렸었다.)
지금까지 일을 해보면서 명확히 알 수 있는 것은,
이것을 깊게 생각해본 사람들과 함께 모여 일하는 것이 얼마나 즐겁고 행복한지에 대해서 잘알고 있고 나또한 그런 사람이 되고 싶기에, 이 부분에 대해서는 부트캠프가 끝나기 전까지 계속 깊게 생각해보고자 한다.
그래서 개발이 뭐라고??
개발을 공부하면서 개발에 대한 정의를 내린 것을 찾아보게 되었는데 많은 곳에서 개발을 <문제를 해결하는 과정>이라고 설명하고 있었다. 그리고 부트캠프에 들어와서도 튜터님께서 말씀해주신 부분도 문제를 해결하는 것이 개발이라고 하셨다.
이것을 고민하게 된 이유는... 내가 정확히 무엇을 하는지에 대해 알고 싶어서이다. 개발자가 되려고 JavaScript, React, Node.js를 배워서 도대체 뭘 하려는 것인지를 정확히 알고 사용하고 싶어서이기도 하다.
몇가지 꼬리를 물고 고민했던 부분으로,
- 개발자는 문제를 해결하는 사람으로 정의를 하면 될 것인가?
- 문제를 어떻게 정의를 해야할까? 내가 알고 있는 문제(Problem)로 알면 될까?
- 개발을 한다고 하는 것은 지금보다 더 나은 개선된 것을 만들 때 개발한다고 하지 않을까?
- 그럼 개발에 대한 문제는 일상속에서 느끼는 작은 불편함 같은 것처럼 아무리 작은 것이라도 불편한 부분을 개선한다는 것을 개발이라고 할 수 있는가?
- 그럼 개발을 한다는 것은 우리에게 꼭 필요한 것을 만드는 것으로 정의할 수 있지 않을까?
- 그런데 왜 전문가들은 개발을 문제를 해결하는 과정으로 정의할까?
꼬리를 물고 개발에 대한 정의를 생각해보았으나, 이제 개발공부를 시작한 사람으로서 이것에 대한 정의를 내리는 것은 시기상조일지도 모르겠다. 나도 개발자가 되어 몇년간 개발공부를 해보면 나 또한 문제를 해결하는 과정이라고 할 수 있을 것이다.
다만 한가지는 확실히 알 수 있을 것 같다.
개발자가 되어 개발을 한다는 것은,
세상을 더욱 행복하게 만들어 줄 수 있는 사람인 것을.
좋은 팀워크란 무엇일까?
부트캠프에 들어오자마자 4명이 한팀을 이뤄 미니프로젝트를 시작했고, 여기서 팀장이 되어 프로젝트를 진행하게 되었다. 사실 이번 프로젝트에서 팀장의 역할이 필수적이지 않았지만, 그래도 최선을 다해보고싶었고 어떻게 좋은 팀워크를 이룰 수 있을지에 대해 고민해본 시간이였다. 또한 팀프로젝트를 진행하면서 팀장의 역할에 대해서도 고민해보게 되었는데 이부분에 대해서 회고록에 쓰면서 생각의 정리를 해보고 싶었다.
좋은 팀워크를 유지하기 위해선 해야할 것보다 하지 말아야하는 부분이 더 중요하다고 생각하기에, 하지 말아야겠다는 것을 정리해보겠다.
1. 차별하지 마라.
A는 JS를 잘해, B는 CS를 잘해, C는 JS과 CS를 다 잘해, D는 특별히 잘하는게 없다고 가정해보자.
팀프로젝트를 위해 어떻게 업무를 배분하고 진행할 것인가? 이것에 대한 명확한 기준이 없다면, 누군가는 원하지 않는 일을 하게될 수도 있으며, 팀의 동력이 떨어질 수도 있게 될 것이다.
한 팀이 되었다는 것은 결국 모두가 함께 나아가야지만 완성할 수 있기에 최대한 공평해야한다. 여기서 말하는 공평함이란 색안경을 끼지 않고 최대한 합리적인 결정을 하는 것을 말한다.
이번 팀프로젝트를 진행하면서 우리가 했던 방식은, 사다리타기였다. 나는 지금껏 사다리타기를 "커피 내기, 점심식사 내기 등" 게임적인 요소로만 사용하였고, 이것을 중요한 의사결정에서는 사용해본 경험이 없었고, 이번 팀프로젝트에 활용하면서 많은 것을 깨달았다.
사다리타기 게임은 누구나 공평하다는 것은 잘 알고 있을 것이다. 결정을 내리는 것에 대한 그 누구의 의견이 들어가지 않은, 순전히 운으로 결정하는 부분이므로 그 누구도 이 게임의 공평함에 이의를 제기할 수 없을 것이다. 물론, 구성원 전부가 사다리타기로 결정하는 것에 대해 동의를 했을 경우를 전제로 한다.
이번 사다리타기는 나의 편견을 깨어주었고, 부트캠프에서 정말 효율적인 방식이란 것이다.
그이유는,
- 굉장히 빠른 의사결정을 할 수 있어
- 결정하는 시간을 줄일 수 있으며,
- 팀원 누구도 차별하지 않고
- 공정한 결정을 내릴 수 있으며,
- 익숙한 것이 아닌 새로운 도전을 할 수 있어
- 팀원 모두가 다 함께 성장할 수 있다.
대게 직장에서는 새로운 도전기회를 주는 것보단 잘하는 것을 더 잘하게 하도록 할 수 밖에 없다. 그 이유는 결과물을 예상할 수 있고, 실패에 대한 Risk를 줄일 수 있기 때문이다.
다만, 대부분의 사람들은 자신의 발전에 대한 성취욕구를 가지고 있으므로, 예상되는 결과물보단 더 좋은 결과물을 내기 위해선 사람의 성취욕을 끌어내어 그것을 발휘하게 만들어야만 새로운 결과물이 나올 수 있다고 생각한다.
따라서 사다리타기도 잘 세팅을 해놓는다면 합리적인 의사결정을 내리는 도구로서 활용해볼 가치가 있다는 것을 팀프로젝트를 통해 깨닫게 되었다.
대게 팀워크가 흔들리는 경우는 의사결정에 대하여 팀원들이 불만을 가질 때 생겨나는 경우가 많은데, 이럴 때 과감히 사다리타기로 결정해보는(?) 도전을 해보는 것이 어떨까 한다.(혹시나 이 방법을 활용하고 있는 파격적인 회사가 있다면 그곳에 지원하고 싶네요.)
2. 바로 말하지 마라.
좋은 팀워크가 되기 위해서는 소통하는 문화가 굉장히 중요하다. 하지만 말 한마디로 인해 팀워크가 깨지는 경우도 굉장히 많기에 말을 잘하는 것이 무엇보다도 중요할 것이다.
팀원 중 누군가가 의견을 말했을 때, 그 의견이 나와 맞지 않거나 나의 의견과 대립하게 되었을 때 어떻게 말을 해야할 것인가? 의견이 대립한다면 당연히 자신의 생각에 대한 변론을 할 수 밖에 없을 것이다. 하지만 이경우 대부분 생각의 오류에 빠지는 경우가 되게 많은데 이때
상대방이 왜 이런 말을 했는지 생각해본다면 충분히 상대방의 말도 좋은 의견인 경우가 많다.
의견을 나누는 것은 팀의 발전과 더 나은 방향으로 나아가기 위해선 꼭 필요하고, 의견을 마음껏 내보이는 문화가 팀에 꼭 존재해야만 한다고 생각한다. 다만, 팀문화를 형성하는 시기에 의견을 내는 것에 대한 룰을 정하며 팀원들이 이를 인식한다면 되게 좋은 결과를 내었다.
이러한 부분을 나도 잘 지키고 있는지에 대해서는 나조차도 확신할 수 없다. 다만 이부분을 항상 생각하면서 말을 할 수 있도록 계속해서 연습을 하고 있으니 지금보다는 더 좋아지지 않을까 생각해 본다.
혼자하지 마라.
왜 프로젝트는 대부분 팀으로 구성하여 일하는 것일까? 업무를 잘게 나누어 개인에게 업무를 줘서 일하면 안되는 것일까?
팀으로 구성하는 이유가,
- 혼자 하기엔 업무량이 많아서?
- 혼자보단 팀으로 하는 것이 결과물이 좋아서?
- 빨리 일을 처리할 수 있어서?
가장 큰 이유는 한정된 시간에 개인이 할 수 없는 규모의 업무를 가졌고, 협업을 통해 시너지를 낼 수 있기에 팀으로 움직인다고 생각한다.
팀프로젝트 특성상 업무적인 부분과 비업무적인 부분까지도 서로에게 영향을 미칠 수 밖에 없다. 그렇기에 팀원들은 자신의 행동에 대해 끊임없이 점검을 해야하는 부분이 필요하며, 같이 일하는 동료가 어떤 어려움을 겪고 있는지를 알고 그것을 함께 공감해야 부분도 필요하다.
하지만 많은 사람들이 나에게 주어진 업무만을 잘한다면 괜찮다는 생각을 하고, 주변을 돌아보지 않는다. 상황에 따라 팀원 간에 서로를 도와가며 업무를 해결해나가야하고, 팀이 활력이 돌 수 있도록 분위기 메이커의 역할도 필요하다. 이러한 부분이 필요하단 것을 잘 알고 있지만 실천하기엔 굉장히 어렵다고 생각할 것이다.
이럴 때 필요한 것은, 구성원 모두가 혼자한다는 생각을 하지 않는다면 조금 더 주변을 돌아보지 않을까 한다. 업무시간에 20분 만이라도 팀 구성원들을 도와주는 시간이 강제로 할당되어 있다면, 더 좋은 팀워크를 유지할 수 있지 않을까? 도와줄 일이 없다면 서로를 더 알아가는 시간을 가질 수 있다면 그것으로도 충분히 가치가 있다고 생각한다.
좋은 팀워크란,
팀 구성원간 유대감을 형성하고 팀원 모두가 책임감을 가지며, 팀의 뚜렷한 목표를 항해 함께 나아가는 것이라고 생각한다.
미니프로젝트를 진행하면서 좋은 팀워크란 어떤 것인지 한번 정리할 수 있어 굉장히 의미있는 시간이었다. 앞으로 15주간 팀프로젝트를 여러번 경험할텐데 팀프로젝트에 대해 더 이해해보고, 오늘 정리한 부분을 잘 적용해보고 싶다.
오늘 적은 회고록이 6개월 뒤에도 똑같은 생각을 하고 있을지는 모르겠다.다만 지금의 생각과 미래의 나의 생각이 다르고 왜 다른지를 알게된다면, 오늘보다 더 나은 내가 되었다고 생각하는 계기가 되었으면 한다.
나중에는 또 어떤 생각이 들지 내심 기대가 되는 부분이기도 하다. 다음주에는 또 어떤 재미난 일이 있을지 기대가 된다.
