팀원 해체 및 느낀점
2024년 2월 말쯤 팀원들이 해체가 되었다.
해체 사유 :
- 회의 시간 때 팀원들의 노쇼 및 미공지
- 작업량 미완료
- 주제 선정 간 뚜렷하지 못한 주관
핵심 적인 이유 2가지와 서브 적인 이유 1가지가 있었다.
첫번째는 시간 약속이다. 많이 만날 때는 주 3회정도 디스코드에서 만났다. 이때는 오히려 노쇼를 하는 인원이 있었도 금방 또 만나기에 문제가 없었다. 문제는 주 1회 매주 금요일 오후 7시에 만나고부터 시작이었다. 모든 사람이 본업이 있고, 사정이 있기에 약속 시간을 늦거나 미참여는 이해를 했다. 하지만, 미참여 및 지각시 그 누구도 미리 공지를 하지 않았다. 항상 7시 되기 5분 전에 들어가면 총 4명 중에 가끔 1분이 계시고 나머지는 늦거나 노쇼를 했다. 현업에서 근무를 하시는 분도 지각하거나 노쇼를 하지 않았는데, 그 외 팀원들은 왜 그러지는 모르겠다. 이 이유로 현업자분께서 맨 처음 팀을 나가셨다.
두번째는 작업량 미완료이다. 현업자분께서 나머지 인원들의 수준을 알고 싶다기에 멀티모달에 필요한 텍스트(LLM), 오디오, 비디오 각 모달별로 피처를 추출 및 MIntRec 데이터셋으로 파인튜닝까지를 허깅페이스 파이프라인 사용하지 말고 Pytorch로 구현해보라고 하셨다. 난 이때 오디오를 받았고, W2V 2.0 Facebook 960h 모델로 다 진행했지만, 나머지 2명이 완성을 못했다. 사실 코드를 짜는 것이 익숙치 않으면 속도가 느릴 수 있다고 이해는 하지만 파이프라인 코드 짜는게 3주 걸리는건 아니지 않나? 싶었다.
세번째는 뚜렷하지 못한 주관이다. 이것은 내 개인적인 생각이 강하게 들어있기에 다른 사람들이 공감을 못 할수도 있다.
논문 주제거리를 다양하게 논의를 하게 되면 누군가는 아이디어를 내게된다. 그럼 그 아이디어에 대해 찬반? 장단점? 가능성유무? 등을 논의하게 된다. 그때 마다 아이디어를 내는 것은 ‘나’였고, 다른 인원들은 아이디어가 좋다고 했다. 물론 아이디어는 좋았다. 나왔던 아이디어들이 “Whisper(2023년 모델)을 이용하여 유튜브 자막 강화”, “영상 속 발화자 디텍션” 등이 있다. 이때 아이디어는 주로 논문이 아닌 프로젝트를 위한 아이디어였다. 여튼, 모든 아이디어에 대해 무조건(?) 적인 찬성들만 하였고, 현실적인 문제에 대해서는 깊이들 생각하지 않았다. 이로 인해, 주제 선정이 지속적으로 딜레이되며, 실제 프로젝트 기간이 많이 줄어들었다.(원래 4주인데, 2주만에 유튜브 자막강화 프로젝트 완료)
추가적으로 팀장 역할의 중요성이다. 본 작업에서는 팀장이 따로 있었다. 본 작업 이전에는 주로 팀장 및 서기를 담당하였고, 회의 간 진행과 진행 상황 보고 등을 직접 담당하였다. 하지만, 이번 작업에서는 다른 분이 팀장을 맡으셨고, 내가 원하는 진행을 하지 않은건지 못한건지 모르겠다. 예를 들어, 디스코드로 회의를 하게되면 팀장이 진행을 하며, 의사소통을 리드해야한다고 생각한다. 하지만 팀장은 7시 5분이 되어도 아무말도 안한다. 하는 수 없이 입을 먼저 여는건 나였고, 진행 및 서기를 자연스레 하게되었다. 뭐 사실 회의야 내가 리드하면 되는데, 각 사람들마다 진행 상황은 팀장이 알고 있었야 하지 않나? 싶다. 실제 프로젝트 하면서 다른 사람이 얼마나 진행을 하였고, 문제가 발생하면 미리 조치를 취하는 행위가 없었다. 물론 팀장도 파트가 있고, 그 파트를 구현 및 리뷰를 해야하지만 최소 1명은 PM처럼 작업의 큰 그림을 봐야 한다고 생각한다. 물론, 이를 보완하기 위해 노션의 작업량 캘린더(?) 같은 기능을 이용하긴 했지만, 사람이란게 일하기도 바쁜데 작업한 내역을 정리하는 것은 매우 귀찮다. 이를 팀장이 바로 잡아야 한다 생각한다.
팀원 해체 사건으로 인해 나의 장점을 다시 생각해보게 되었다.
- 시간 준수
- 문제 발생시 즉각 보고(실패 및 시간 내 미완료 예상시)
- 나의 코딩 수준(Pytorch)
사실 이 3가지는 장점이 아닌 디폴트(?)로 생각해왔다. 지금까지 작업을 했던 사람들은 시간 준수는 물론 문제가 발생하면 즉각 문제를 보고하였다. 하지만, 이번 일을 통해 모든 사람이 그렇지 않다는 것을 알게 되었고, 이는 프로젝트 진행에 있어서 큰 악영향을 미친다는 것을 몸소 느꼈다. 또한, 문제가 발생하면 숨기는 사람도 많다는 것을 알았다.
그리고… 나의 파이프라인을 구성하는 능력이 어느정도는 안정적인거 같다고 느꼈다. 사실 ML과 DL의 파이프라인은 크게 보면 비슷하지만, 세부적으로 보면 다른 점도 많고 헷갈리는 점도 많다. (DL은 옵티마이저, 스케쥴러, 트레이너, 로깅 등 할게 더 많다)그 동안 다양한 대회 참여 및 프로젝트를 하면서 부족하다고 느낀 내 실력이 더 이상 부족하지 않음을 느꼈다.