2024 공개 SW 개발자 대회 회고

 

개발자 인생 처음으로 공모전에 참가하였다. 백엔드 개발자로서 잘하는 사람들과 프로젝트를 하며 한 단계 성장하고 싶었고 벽을 느껴보고 싶어서 참가하게 되었다. 어찌저찌 본선까진 갔지만 수상을 하진 못했다. 그 간의 5개월이 날아가버린 느낌도 들고... 많이 아쉬웠다. 팀원 중에서 직장 출퇴근하며 새벽까지 작업하던 분도 계시기도 했고, 그 분을 위해서라도 수상하고 싶었는데. 비록 뒤늦게 팀장을 맡긴했지만 어찌됐든 내가 이끌었던 팀이었고 높이 올라가지 못했던 것에 아직도 한참 부족함을 느꼈다. 팀의 성공은 거의 팀장이 결정한다고 생각하기 때문이다...

조금 더 착실하게 쌓았다면, 팀 문화가 더 좋았다면, 기술적 식견이 넓었다면, 좀 더 단호했다면 달랐을까? 아직도 놓쳤던 포인트들이 아쉽게 느껴진다. 원했던 실력적인 벽을 느끼진 못했지만 나름 많은 갈등과 어려움을 겪었던, 내가 더 잘했더라면 달랐을까 생각하게 되는 프로젝트였다. 5개월간의 많은 시행착오를 떠올리며 남겨서 다음엔 이 장애물들을 최대한 피해보고자 한다. 

 

 

1. 기획 단계

 

빈틈 없게 기획하라

기획, 설계 단계의 중요성을 이미 알고 있었지만 이번에 아주 뼈저리게 느꼈다. 개인적으로 프로젝트의 성공여부가 여기서 결정난다고 본다. 이 단계에서 절대 어떻게든 잘 되겠지를 허용해선 안된다. 팀장이 총대매고 단호해야 한다고 생각한다. 왜냐하면 지금 100% 강도로 정해도 시간이 지날수록 약속이 느슨해지고 더군다나 우린 주니어 개발자이기 때문에 약속을 간과하기 쉽다. 

우리 팀의 가장 큰 실수는 사람을 모아놓고 아이디어를 정한점이 아닌가 싶다. 이미 한정된 기술 스택에서 평범하지 않은 아이디어를 떠올리는 것은 거의 불가능에 가까웠다. 운이 좋아 하나 얻어 걸렸지만 아이디어 회의만 한달 내내 하다가 폭파될 뻔 했다. 

 

컨벤션은 멀리 가게 해주는 중요한 도구이다

Git, Code, 회의 convetion을 확실히 정해라. 먼저 회의 convention을 정하지 않고 그 회의의 틀을 정하지 않으면 회의를 하루종일 하게되는 시간의 마법에 걸리게 된다. 특히 회의 이전 팀원 모두의 예습?이 없다면 한명씩 이해시키는데 무지막지한 시간이 걸리고 이게 온라인 회의라면 더더욱 심하다. 팀장은 회의를 진행하고 사안에 결단을 내려야한다. Git, Code convention은 엄~청 중요한건 아니지만 확실히 하지 않으면 마지막 정리, 문서화 시점에서 둘러보면 아주 초라해보이는걸 알 수 있다... 사실 기능면에선 티가 나진 않지만 "오픈소스"라는 관점에선 가치가 확 떨어진다. 공유, 개선, 협업이 중요한 개발 문화에서 이러한 사소한 디테일이 개발에 대한 애정이 드러나는것 같기도 하다.

 

 

 

2. 구현 단계

 

오프라인의 힘을 무시하지마라

이번엔 정말 정말 하고싶지 않았는데 도중에 팀장을 맡게 되었다. 티는 잘 안냈지만 정신적으로 조금 힘들었다. 본선진출을 하긴했는데 그 당시 구현도 많이 안된 상태였고 취준을 하면서 팀의 존망의 경계에서 어떻게든 팀을 이끌어야 한다는게 너무 부담이었다. 이 과정에서 좋은 리더에 대해서 정말 많이 고민했던것 같다. 회의 분위기라든지 결과물 재촉이라든지 싫은소리 부드럽게하는 법이라든지... 얼굴도 모르고 표정도 안보이고 실제로 어떤 사람인지도 모르니 얘기할 때 분위기의 감을 잡기가 어려웠다. 나도 회식을 싫어하지만 오프라인 만남이 반드시 필요한것같다.

가장 어려운 건 역시 싫은 소리를 잘 하는것인 것 같다. 개발자도 결국 사람이고 감정이 상해버리면 일을 던져버리는 상황이 발생할 수도 있다. 특히 월급 받으며 일하는게 아닌 공모전, 프로젝트의 경우 더더욱. 자연스럽게 팀원을 유도해서 원하는대로 하는것... 항상 노력하지만 아직도 잘 모르겠다. 더욱이 난 거짓말 못하고 감정 숨기는게 너무 서툴러서... 김영한님 같이 항상 밝으신 분은 싫은 소리도 좋게좋게 하시겠지? 궁금하다.

 

 

시간부족으로 테스트 코드를 미루지마라

프로젝트가 항상 마감기한에 쫓기듯 진행됐다. 확실한 기획없이 구현을 무작정 시작한게 가장 큰 문제였지만 바쁘다고 테스트 코드를 도중에 던져버린 탓도 굉장히 컸다. 작성하지 않음으로 발생했던 버그수정이 결과적으로 더 큰 시간이 투자됐던것 같다. 그러니까 결국 테스트 코드도 작성하지 못하는 시간이라면 정확한 구현도 불가능한 시간이라는 것이다. 저번 프로젝트에서는 그래도 테스트 코드를 꼼꼼히 작성했었는데 그래서 문제가 훨씬 덜 생겼었나 싶다. 

 

 

주니어는 예상시간을 2배로 잡아라

업무가 주어졌을때 주니어면 자신이 업무를 마칠 수 있는 시간의 2~3배는 늘려서 팀원에게 알리는게 좋은것 같다. 간단한 업무라도 사용하는 툴의 버젼이나 여러 자질구레한 에러에 봉착하기 때문이다. 우린 주니어기 때문에 이런 에러를 예측하는 눈이 없고 정말 사소한 문제도 하루를 넘기는 경우도 많으니... 팀 전체 일정이 꼬이지 않게 하려면 차라리 시간이 남더라도 그렇게 설정하는 것이 맞다. 팀장은 어쨌든 로드맵대로 진행해야하고 재촉하게 되는데 열심히 하는 팀원에게 더 열심히하라고 할 수도 없고 참 난감하다... 

 

 

 

3. 마무리 단계

 

검증, 테스트 기간을 별도로 남겨두어라

구현은 마감일 직전까지 하는것이 아닌 최소 2주전엔 마무리해야 한다. 계획은 항상 지켜지기 어렵고 지연되는것이 다반사이기 때문에 여기서 1주를 더 쓰는 예비기간으로 두기도 좋다. 그리고 나서 꼭 검증과정을 거치고 문서화를 해야한다. 여기서 검증 방식은 여러가지가 있다. 보안, 병목지점 파악, 응답시간 개선, 코드 개선, 주석 개선 등 제대로 하려면 끝도 없긴 하지만 그래도 일단은 제출은 해야하는 상황에서 프로젝트의 완성도를 좀 많이 올려준다. 항상 프로젝트 발표든 면접이든 물어보는 질문이 어떤 문제가 있었고 어떻게 해결하였느냐인데 구현기간동안에는 나무만 보이고 숲은 보이지 않기 때문에 냉철한 분석을 위해 돌아볼수 있는 과정이 필요하다. 

 

 

 

 

할때 마다 느끼지만 어디서든 장의 역할은 언제나 어려운 자리다. 하지만 모든 주어니들이 먼 미래 언젠간 맡아야할 자리... 미래에 좋은 리더가 되고 싶어 웬만하면 자처해서 하려고 하고 있지만 점점 좋아지고 있는지 수치화가 안되는 영역이다 보니 괜히 하는짓인가 회의감도 들기도 한다. 미래의 나야, 나 잘하고 있는거 맞니? ㅠ