학습시간 09:00~02:00(당일17H/누적1079H)
우여곡절 끝에 첫 프로젝트가 끝났다. 문과+수포자+비전공+무경력+30대라는 모든 악조건을 달고 팀장 역할까지 해낸 스스로에게 칭찬을...
약 3주 동안 어떤 일이 있었는지, 무엇을 느꼈고 배웠는지 기록해 본다.
1. 프로젝트 개요
어떤 프로젝트가 주어질지 기대가 많았는데, 딱 기대를 충족하는 프로젝트가 주어졌다. 바로 객체 탐지!! (사실 배운 게 그것뿐이지만..)
최종 목표는 다양한 알약 이미지를 학습시켜서 어떤 알약인지 분류해 내는 인공지능 모델을 개발하는 것이었다. 잘 활용하면 실생활에서도 충분히 써먹을 수 있을 듯한 프로젝트여서 더 마음에 들었던 주제다.
물론 의학 관련 지식은 전무하지만, 괜찮은 성능의 모델을 만들 수 있지 않을까 하는 근거 없는 자신감을 가지고 시작했다. (내가 학습하는 게 아니니까,,,ㅎㅎ)
그러나 얼마 가지 않아 모델 만드는 게 중요한 것이 아니라는 사실을 깨달아버렸다.
2. 나의 역할
정신 차려보니 팀장이었다. 팀장을 맡는 건 부담스럽지 않았지만 실력이 없어 팀에게 민폐가 될 것 같아 걱정이 앞섰다. 똑같은 팀이어도 능력자가 이끄는 팀과 무능력자가 의지하는 팀은 하늘과 땅 차이기 때문이다. 내가 제일 싫어하는 상사가 무능력한 상사인데 딱 내가 그 꼴이라서 너무 한심하고 미안했다... 그래도 이왕 시작한 거 하는 데까진 해봐야지! 라고 생각하며 프로젝트 내내 마음을 다잡았다.
개발 프로젝트에서는 팀장이 어떤 역할을 해야 하는지 몰라서 계속 찾아봤다. 개발하는 것도 물론 중요하지만 팀장이 팀을 제대로 이끌지 못하면 팀 전체가 산으로 갈 수 있기 때문이다.
찾아보니 팀장은 직접적인 개발보다는 프로젝트 체계화에 초점을 두어야 하는 것 같았다. 팀원의 역할 분배, 의견 조율, 마감 일정 관리, 우선순위 설정 등에 신경 써야겠다고 생각했다.
나는 이중에서도 의견 조율이 가장 중요하다고 느꼈다. 직원이 많은 곳에서 근무해 보니, 아무리 좋은 의견도 반대하는 사람이 꼭 한 명쯤 있기 마련이었다. 게다가 대립 상황을 제때 해소하지 못하면 반대자가 둘이 되고 셋이 되고,,, 결국 무리가 나뉘어 팀이 붕괴되곤 했다.
개발자의 세계도 비슷하지 않을까. 원래 좋은 성과는 혼자서 만들 수 없는 법이니까. 그러므로 이번 프로젝트에서 나의 역할은 기술적인 문제와 관계적인 문제를 동시에 해결하는 것이리라 생각했다.
3. 준비 단계
원활한 소통을 위해 팀노션을 만들었다.
메인 페이지에는 프로젝트에 관한 내용을 다 모아두었고, 회의록 페이지에는 팀미팅 때 나눈 이야기를 공유 후 팀원이 모두 숙지할 수 있도록 했다. 지식창고에는 팀프로젝트에 도움이 될만한 포스팅을 모아두었다.
또한, 공지사항을 주기적으로 업데이트해서 프로젝트 진행 일정에 차질이 없도록 했다.
사실 팀명은 내 멋대로 SuperDog이라 지었는데 팀원분들이 그냥 넘어가주셨다 ㅎㅎㅎ
SuperDog 이라니,,, 귀여운데 강하기까지 하면 좋잖아...!?
프로젝트를 다 끝내고 돌아보니, 가장 어려웠던 단계는 개발이 아니라 계획과 준비 단계였다.
특히 Git이 어찌나 어렵던지... 파이썬을 처음 배우던 날들이 떠올랐다. 팀원이 Git의 늪에 빠져 헤매고 있을 때 슈퍼맨처럼 딱 등장해서 구해주고 싶었는데, 나도 아무것도 몰라서 멍 때리고 있어야 했던 게 아쉬웠다.
그래도 팀원분들이 인내심 있게 공부해 주신 덕분에 Pull Request도 정상적으로 진행할 수 있었다. 지금 생각해 보니 참 웃기다. 고작 add-commit-push 하는데 며칠을 소모했다는 게...
이후 디렉토리 구조, Branch 전략, 가상환경을 셋팅했다. 큰 규모의 프로젝트가 아니기 때문에 필요성을 느끼진 못했지만, 어차피 취업하면 필요하니 함께 천천히 해보기로 했다. 매도 먼저 맞는 게 나으니까.
귀찮은 작업 열심히 따라와 준 팀원분들에게 압도적인 감사를...!
이때쯤 다른 팀은 벌써 전처리 끝내고 모델 만들고 있다는 소식을 들었다.
어쩌겠어.. 팀장이 부족한 탓이지 ㅠㅠ
4. 개발 단계
개발 단계에서 가장 어려웠던 건 역할 분담이었다..... 팀프로젝트가 처음이다 보니 어떤 역할이 어느 정도의 비중을 담당하는지 가늠할 수가 없었기 때문이다.
크게 전처리 & 학습 & 평가로 나누면 괜찮지 않을까 해서 한 파트에 2명씩 담당하기로 했다. 근데 진짜 문제는 비중을 어느 정도 맡느냐가 아니었다. 일단 서로의 코드가 어떻게 연결될지를 모르니 시작조차 할 수가 없었다.
강사님에게 여쭈어 보니, 큰 규모의 프로젝트가 아니기에 모든 팀원이 전 과정을 경험해 보면 좋을 것이라 말씀하셨다. 아! 왜 그 생각을 못했지...!!
개별적으로 전처리 코드를 짠 다음, 자동화 효율성을 고려해 코드를 하나로 통일했다. 사실 6인의 코드 중 무엇으로 진행해도 딱히 문제는 없었을 것 같다. 코딩 스타일이 다른 것일 뿐이니까.
그렇게 어찌어찌 개발을 완료했지만, 곧장 두 번째 시련을 마주했다. 바로 .py 파일을 사용해야 한다는 것이었다. 지금까지 쭉 코랩이나 주피터노트북으로 강의를 진행했기에 .ipynb 파일 말고는 써본 적이 없었다.
VSCode에서 파일을 생성하는 것까진 괜찮았는데, 노트북처럼 코드를 한 셀씩 실행시킬 수가 없어서 너무 불편했다. 주로 터미널에 명령어를 입력해 실행한다는데, Git 명령어를 갓 배워서 그런지 더 헷갈렸다.
그래도 밤새도록 복습하고 주말에도 공부한 결과 .py 파일 사용하는 것에 많이 익숙해졌다. 특히 if __name__ == __main__: 분기를 이용해 터미널 명령어로 인자값을 조절하는 방법을 터득했다.
이걸 이용해서 이번 프로젝트의 모든 과정을 원스톱으로 실행할 수 있을 것 같다는 느낌이 들었고, 프로젝트가 끝날 무렵 main.py 파일을 통해 원스톱 스크립트를 구현할 수 있었다.
다음 프로젝트 때도 여유가 된다면 다시 적용해 보고 싶은 부분이다.
5. 평가 단계
(Valid set의 모든 알약을 탐지한 모습)
최종적으로 개발한 모델에서 mAP@0.5: 0.9 정도의 성능이 나왔다.
나름 준수한 결과라 생각했는데 꼴등이다 ㅠㅠ...
어떻게 해야 성능을 끌어올릴 수 있을까 고민하면서 하이퍼파라미터를 다 뜯어보았다. 서치까지 적용해 가며 최적의 조합을 맞추어 보았지만 그럼에도 mAP@0.5: 0.91 이상은 높이지 못했다.
결국 선택한 방법은 모델의 성능 상승에 한계가 있다고 가정 후, 동일한 mAP에서 더 많은 객체를 탐지할 수 있도록 일부 하이퍼파라미터를 조정하는 것이었다. (다시 돌아간다면 데이터 정제에도 더 많은 시간을 쏟았을 것 같다.)
이 전략이 먹혔는지, 프로젝트 종료 후 Private 점수로 변경되면서 우리 팀이 1등을 차지했다!
6. 보고 단계
대망의 발표...!
개인적으로 발표를 중요하게 여긴다. 아무리 좋은 성과를 내도 그 성과를 제대로 표현하지 못하면 (부장님에게) 인정받을 수 없기 때문이다.
그래서 발표 단계에 주말 제외 4일 정도 투자한 것 같다. 리허설만 6번 정도 진행했는데,, 지루한 반복 노가다에 적극 참여해 준 팀원분들에게 다시 한번 압도적인 감사를 전한다...!
매 리허설 후에는 각자 준비한 자료를 피드백하는 시간을 가졌다. 개별로 발표를 준비하기에 분명 논리적으로 어긋나는 부분이 있을 거라 판단했기 때문이다.
피드백을 거듭하면서 개연성도 좋아지고 자료도 보완되는 것이 느껴져서 참 좋았다. 사공이 많으면 배가 산으로 간다는데, 좋은 사공이 모이면 문제 없는 것 같다.
7. 느낀 점
팀장으로서 느낀 점
개발의 세계에서 팀장이란 단순히 내 역량만 뛰어난 사람이 아니라, 팀원의 역량까지 끌어올릴 수 있는 사람이 아닐까 생각하게 되었다. 어차피 팀프로젝트는 혼자서 하는 게 아니라 여럿이서 하는 것이다. 내가 열심히 노력해서 2인 몫을 한다고 한들 10인 몫까지 해낼 수는 없다. 규모가 커지면 더욱 그럴 것이고. 그러므로 팀장에게 필요한 능력은 팀원들이 본인의 능력을 십분 발휘할 수 있도록 적절한 환경을 제공하는 것일 테다. 큰 틀을 잡고, 일정을 짜고, 분위기를 관리하고, 의견을 제시하고, 갈등을 조율하는 것. 어쩌면 이것들이 팀장에겐 개발 역량보다 더 중요한 역량이 아닐까. 좋은 성과를 내기 전에 좋은 팀에 머물고 싶다. 좋은 팀에 있다면 좋은 성과도 자연스럽게 나오지 않을까.
개발자로서 느낀 점
솔직히 이번 프로젝트에서는 개발에 대해 많이 배우지 못했다. 팀장 역할을 해내는 것과 동시에 Git, GitHub, branch 전략, py 파일 적응, 디렉토리 구조에 적응하는 것만으로도 여유가 없었기 때문이다. 그래도 나열한 것에 큰 진전이 있어서 만족한다. 다음 프로젝트 때는 헤매지 않을 자신이 있다. 한 가지 아쉬운 점은, FastAPI를 이용해 모델을 배포하고 실시간으로 탐지하는 구조로 확장해 보고 싶었는데 못했다는 점이다. 시간과 능력이 받쳐준다면 다음 프로젝트 때는 도전해보고 싶다.
개인적으로 느낀 점
내 능력이 너무 부족했던 탓에 여러 모로 아쉬움이 많이 남는 프로젝트였다. 개발에 대해 조금만 더 잘 알고 있었더라면, 프로젝트 경험이 한 번이라도 있었더라면, 이해력이 조금만 더 따라주었다면 참 좋았을 텐데. 시간을 쏟아붓는 것 말곤 재주가 없어서 슬프다. 하지만 나는 10,000 시간의 법칙을 믿는다. 이번 프로젝트를 끝내고 보니 개발을 공부한 시간이 어느덧 1,000 시간을 넘었다. 이제 10% 왔다. 1,000 시간에 도달하면 그동안 모르던 것을 알게 된다고 하던데 정말 맞는 말인 것 같다. 이제 나에게 무엇이 부족한지 알았다.
많이 부족했는데 좋은 말 남겨주셔서 감사합니다.
#코드잇스프린트 #코드잇스프린트후기 #AI부트캠프 #AI프로젝트 #AI포트폴리오 #AI엔지니어 #AI엔지니어취업 #AI프로젝트
