들어가기 앞서 🌱

DND는 디자이너와 개발자가 함께 8주 동안 협업하여 새로운 프로젝트를 만드는 IT 동아리이다. 2024년 1월 1일에 팀이 정해지고 새로운 슬랙방에 나를 포함한 모든 팀원들이 초대됐다. 그렇게 시작되었다. 1주일간 진행과정을 돌아보며 2주 차를 준비하려고 한다.

진행한 것

1. 4차례의 온라인 회의 
2. 동료 프런트엔드 개발자분과 함께 개발 멘토님께 찾아가, 테스트 코드 도입을 위해 Q&A 미팅 진행

학습한 것 

1. 기술적인 부분 
   1. 정보처리기사 실기 프로그래밍 학습 
      1. 프로그래밍 파트 
         1. 반복문, 배열과 문자열 (C, Java)
         2. C언어 포인터
   2. git 학습 for 협업
   3. 개인 프로젝트 알리고 올리고 v2로 리메이드

깨달은 것 

머리로 알고 있는 것과 삶에서 깨달은 것은 엄연히 다르다고 생각한다. 아무리 많은 레시피를 알고 있어도 요리를 직접 해보지 않으면 양파를 어떻게 까야 눈이 덜 아픈지 혹은 찌개는 왜 MSG가 최고인지 모른다. 

커뮤니케이션 부분

리더의 역할 

리더의 역할이 무엇인지 다시 한번 고민해 보는 시간이 됐다. 대학생시절까지 매번 회장과 부회장, 그리고 학생 회장까지 여러 경험이 있었고 졸업 후, 4번의 프로젝트에서 모두 팀장을 진행했다. 그런데 이번 DND 프로젝트에서는 사뭇 달랐다. 지금까지 모든 프로젝트에서도 열심인 팀원들이 함께 했지만 이렇게 모든 인원이 골고루 열정이 넘치고 실력이 뛰어난 프로젝트는 경험해보지 못했다. 그렇기에 팀장으로서 다른 시각과 태도로 임해야겠다는 것을 알게 됐다.

이전 경험

이전에는 약간 어깨가 무겁게 모든 것에 관여하고 진행했다. 그래서 결과물이 안 좋았던 경우도 태반이었다. 내 나름대로 열심히 했고 밤낮으로 고민했었는데 왜 결과가 좋지 않지?!라는 물음표 앞에서 도망치기 일쑤였다. 그리고 깊게 생각하기 힘들었다. 

오늘 일요일 마지막 주차 회의를 통해 조금 알게 됐다. 왜 그랬는지... 내가 다 잘할 수 없고 적절히 팀원에게 위임해야 하는 것을 더욱 깨달았다. 나의 부족함을 인정하고 부끄러워하지 않는 게 핵심인 것 같다. 과거의 경험을 바탕으로 모든 인원이 열정이 넘치는 프로젝트를 성공적으로 마치려고 한다면 어떻게 해야 할까?! 를 고민해 보는 시간을 가졌다. 우리 팀 한 명 한 명의 퍼포먼스는 아직 잘 모르겠으나 인턴 경험이 있거나 졸업 한지 1년 혹은 졸업 예정생이다. 객관적으로 누군가의 멱살캐리는 기대할 수도 없는 상황이다. 더욱 주도적으로 할 수밖에 없다. 그래서 더 기대된다. 

적용점

1. 나의 부족함에 집중하지 말자 

부족함을 인정하고 빠르고 수용하여 어떤 분야던 뛰어난 팀원에게 적절하게 부탁하는 것이 필요하다. 비록 첫 만남에 서로의 역할을 정했으나, 그건 서로의 강점을 모르는 상태에서 분배한 것이기에 충분히 바뀔 수 있다고 생각한다. 

2. 각 팀원의 장점을 빠르게 파악하자

나는 글쓰기를 좋아하지만 회의시간 화면 공유를 해서 빠르게 글을 정리하고 회의를 이끌며 적절한 질문을 하는 데는 아직 연습해야 하고 부족한 부분이 있다. 하지만 우리 팀원 중 한 분은 빠르고 정갈하게 회의록을 진행하며 작성하시는 것을 보고 팀원들의 장점을 빠르게 파악해야겠다고 생각했다. 

3. 희의 시간은 임팩트 있게 진행하자

분명 1주 차를 시작하기 전, 문서를 미리 읽고 회의에 참석해서 임팩트 있게 진행하려고 했으나 웬걸?! 그렇지 못했다. 나는 회의 시간에 여러 사람들의 생각과 새로운 시각을 통한 아이디어 획득에 진심이어 버렸다. 그래서 통통 튀는 질문과 다소 긴 회의 시간과 우리가 1주 차의 미션을 위해 정리해야 하는 것들 이상으로 치고 나가버렸다. 그래서 거의 2주 차에서 진행할 미션까지 해버린 셈이었다. 좋은 점도 있을 테지만 우선 우리 팀원들과 한 이야기는 회의 시간 이전에 함께 주차별 템플릿이 요구하는 질문에 대해 제대로 이해하고 회의에서 해당 내용에 대해 진행하자는 것이었다. 충분히 공감했고 그렇게 진행하기로 했다. 그래서 2주 차에는 미션 템플릿을 정확히 숙지한 후, 회의를 보다 임팩트 있게 진행하기로 했다. 

내가 항상 팀장을 할 수 있었던 이유

내가 뛰어나서 항상 팀장을 했었나? 아니다. 절대 아니다. 어느 프로젝트, 어느 공동체에서 나보다 대부분의 방면에서 뛰어난 인재들이 많았다. 그렇다면 왜 그런 합리적이지 않은 결정이 이루어졌을까!? 

내 성향 때문이 아닐까 싶다. 

1. 초면에 말을 잘 건다. 
2. 초면에 아이스 브레이킹을 위한 여러 노하우가 있다. 
3. 팀의 분위기와 사기를 끌어올리는 말을 잘한다. 
4. 밝고 긍정적이다. 

이런 성향 때문에 외부 활동과 학생회 그리고 학창 시절에는 대부분 팀장 혹은 회장을 도맡아 진행했다. 그렇다면 객관적으로 나에게 부족한 부분이 무엇일까?  프로젝트의 초반에는 강점이 있었으나 중반과 후반부에 스킬이 부족하다는 것을 알게 됐다. 생각해 보니 코오롱 글로벌 프로젝트 중반에 팀원들이 나의 능력에 대해 의문을 가졌던 경험이 있다. 그랬던 이유는 내가 너무 모든 것을 다 하려고 했고 거기에 따라오는 나쁜 결과로 인해 팀원들이 어려워했던 것 같다. 그래서 방법을 바꿔보려고 한다. 이제는 내가 다 하려고 하지 않을 것이고 잘하는 사람이 있다면 적절하게 위임해서 하려고 한다. 이 내용도 분명 고등학생때와 대학생 때 리더 교육을 통해 들었던 내용인데 난 그렇게 하지 못하고 있었음을 깨달았다. 이 경험이 분명 빛을 발할 것을 믿는다.

기술적인 부분 

jest와 react-testing-library를 활용한 테스트 코드 도입 

지금 8주라는 상황에서 우리 프런트엔드 개발팀의 현재 개발 실력을 바라본 결과, 테스트 주도 개발을 바로 실행하기는 어렵다고 판단하였다. 그렇다고 시도를 하지 않을 것인가?! 고민해 보고 내린 결론은 이것이다. 

최대한 공통적인 부분에 테스트 코드를 작성하자

예를 들어 게임 무기 아이템을 생각할 수 있다. 아이템 강화는 자원을 많이 요구한다. 그래서 매일 사용하는 아이템에 강화하는 게 당연하다고 우리는 알고 있다. 만약 자원이 넘쳐나면 모든 아이템을 미리 강화해도 된다. 하지만 시간과 생명이 유한한 이 세상에선 언제나 자원은 한정적이고 제약이 많은 수밖에 없다. 

그래서 우리는 atom 컴포넌트 혹은 가장 기본이 되는 컴포넌트에 우선적으로 테스트 코드를 도입하기로 했다. 예를 들어 input, button, textArea, Avatar 등으로 여러 컴포넌트에 재활용돼 사용하는 컴포넌트 위주로 테스트 코드를 짜기로 정했다. 

또한 함수에 테스트 코드를 적용하기로 했다. 함수의 용도는 코드의 중복을 막기 위함이라고 기억하고 있다. 그렇다면 함수도 마찬가지로 여러 스코프에서 사용될 수 있기에 해당 인풋과 아웃풋에 대한 테스트 코드도 작성하기로 했다. 

함수에도 여러 함수가 존재하고 내가 아직 모르는 것도 많을 텐데 우선 가장 만만한 유틸 함수(계산과 처리를 대신해 주는 함수)에 적용하려 고한다.  당연한 이야기일 수 있지만 처음으로 이해됐고 깨닫게 됐다. 

마치며 🌱

1주일 동안 개발에만 몰두하진 못했지만 개발에 몰두할 수 있는 환경을 구축했다. 개발도 마찬가지고 환경 설정의 중요성은 누구나 공감할 것이고 가장 어려운 부분일 수 있다고 생각한다. 프로젝트 규모가 커진 후 환경 설정 부분을 수정할 때는 예상하지 못한 에러와 압박감 그리고 두려움까지 몰려올 수 있다는 점에서 프로젝트 환경 설정은 언제나 중요하다.