[회고] : 한이음 공모전 회고

회고 주제

---

처음으로 참여한 한이음 공모전, 참여 하면서 어떤 일이 있었는지 회고한다.

회고 내용

---

학교에서 참여하라고 강력 권장하는 나름 큰 공모전인 한이음 공모전에 참여하고 싶었다. 꼭 큰 공모전이라 참여하고 싶었던 것이 아니라 프로그래밍은 실전, 프로젝트! 라는 생각이 있었으므로 무조건 이런 것을 배움에 있어 공격적인 자세를 취하고 싶었다.

 

하지만 이제 막 입학한 1학년인 나는 프로그래밍 언어를 거의 알지 못 하는 수준이었고 학교 내에서 2학년 선배들이 팀을 꾸려 1학년을 영입하고 알려주며 프로젝트를 만들어 간다고 면접을 봤는데 하필 그 날에 목 뒤에 종양 제거 수술을 받느라 참여하지 못해 기회가 사라졌나 싶었다.

 

뭐..아쉽지만 떨어졌으니 따로 참여할 공모전이라도 찾아보고 있었는데 과대 친구가 와서 팀원을 급하게 구하는 곳이 있는데 해볼거냐 물어봐서 한다고 말 하고 참여하게 되었다.

 

원래는 우리팀이 2학년 3명, 1학년 2명으로 이루어졌는데 다른 팀에 시작부터 불화가 있어 팀이 깨져버려 우리 팀으로 흡수됐다. 흡수가 되면서 2학년 2명이 빠지고 1학년 2명이 들어와 총 2학년 1명, 1학년 4명으로 우리는 그렇게 시작했다.

처음에 우리는 서로를 잘 알지 못 했다. 지금도 잘 아는 사이는 아니지만 그때는 서로 존댓말 쓰며 서로 탐색전을 벌이고 있었을 것이다. 프로젝트의 팀장을 맡은 2학년 선배가 회의를 해야 한다 했고 우리는 학교가 끝나고 매일같이 남아서 아이디어 회의를 하고 우리의 실력으로 구현이 가능한지..(미래의 우리의 실력이다. 아직은 프로그래밍 언어 자료구조를 할 때이니 말이다.)판단하고 결정하는 시간을 가졌다.

 

아이디어 회의를 하면 알겠지만 처음에 다들 친하지 않고 어색하다 보니 소극적인 참여가 이어졌다. 그래도 다들 아이디어는 숙제처럼 생각해 와서 제의했고 그렇게 모아진 아이디어를 가지고 투표를 통해 뽑았다.

 

나는 아이디어 회의를 할 때 공격적인 자세를 취했다. 이건 내가 삐딱선을 타는 게 아니라 나중에 평가 받을 우리의 프로젝트가 더 완벽해 지기 위해 팀의 이득을 위해 팀의 약점을 공격했다. 그 중 받아들여진 부분도 있었고 나 혼자의 의견으로 갈 수는 없기 때문에 안 받아들여진 부분도 있었다.

 

내가 생각할 때 가장 큰 문제점이 안 받아들여졌다고 생각하지만..( 알레르기 성분 분석 서비스에서 소스에 들어간 알레르기를 캐치할 수 없고, 식당마다 다른 레시피에 대응할 수 있는 방안이 없다..이것은 아직도 아주 큰 문제점이자 프로젝트 주제에 모순되는 방향이라 본다.)어쩔 수 없었다. 대신 나중에 발표에서 공격 질문이 들어올 때 대비할 멘트를 준비하는 방향으로 프로젝트를 준비해 나갔다.

 

공모전에 참여하는 팀들은 학교가 끝나고 남는다 남아서 서류를 쓴다. 우리는 서류 공모전에 나간 것 같았다. 서류만 쓰고 자료를 찾고..마치 사업 계획서를 쓰듯이 공모전을 평가할 심사위원들에게 우리의 프로젝트는 이래서 반드시 필요합니다를 서류로써 어필해야 하는 상황이다.

 

아마 이때 처음으로 충돌이 있었다. 우리팀은 멘토인 2학년은 약간 선생님 역할과 방관자 역할을 겸했었고 1학년 2명은 자기 주장이 약한 팀원들이었다. 나머지 1명과 내가 그나마 적극적으로 주장하는 형태였고 내가 아닌 다른 한 명이 자기 주장이 강했다. 이 사람과 부딪히는 일을 피하고 싶었지만 가끔 있었다. 어쩔 수 없었다. 하지만 둘 다 프로젝트의 완성도를 위해 의견이 달랐고 그래서 부딪혔을 뿐이다 감정적인 다툼은 없었다. 애초에 있으면 안 된다. 여튼, 그렇게 그 사람과 내 의견이 갈렸고 나는 내 의견을 뒷바침할 서류를 어떻게 적을지 적어봤다. 그 사람도 적었다. 그리고 교수님에게 컨펌을 받아 결정했다. 내 방식이 맞았다. 나는 돌아갈 줄 아는 사람이다. 그 사람은 무조건 뚫어야 하는 사람이다. 누가 맞고, 누가 틀릴 수 없다. 무조건 뚫어야 하는 사람이 있어야 프로젝트 주제에서 벗어나지 않고 한 길로 갈 수 있고 나 처럼 돌아갈 줄 아는 사람이 있어야 예상치 못 한 상황에 유연하게 대처할 수 있다. 하지만 서로 다른 생각을 가진 두 사람이었기 때문에 서로가 서로의 방식을 잘 이해하지 못 했고 답답해 했고, 아쉬움을 느꼈다. 팀 프로젝트의 묘미는 이런 것이라고 생각한다. 부딪힐 수 있는 누군가가 있어 나와 대립할 수 있는 의견을 가지고 있을 때 우리가 과연 화합을 잘 할 수 있을까에 대한 의문을 계속 품으면서 발전해 나갈 수 있는 것 이것이 프로젝트를 위한 팀 내에서의 선의의 경쟁이 아닌가 싶었다. 답답했지만 지금와서 보면 만족스러운 형태의 무언가이다.

 

이후 우리는 일단 개발을 위해 학교 수업을 잘 듣고 복습을 하고 알고리즘 문제도 풀어가면서 노력했다. 그렇게 1학기가 끝나갈 때 프로젝트에서 적용할 수 있는 프로그래밍 언어를 어느 정도 배웠고 종강을 하고 여름 방학이 시작되면서 우리는 Spring Framework를 배우기 시작했다. MVC 패턴에 대해 배웠고 학교가 끝난 뒤 팀원 중 멘토인 선배가 “Controller에서 Service로 그리고 Database를 거쳐 View로” 라고 열강을 하면서 알려줬던 기억이 있다.

 

어떻게 움직이는지 이론을 설명하고는 로그인 로직, 회원가입 로직을 짰다. 처음 이었다. 내가 프로그래밍이란 것을 제대로 해 보는 것이 이때가 처음이었다. 6개월을 배우고 나서야 시작한 것이었다. 이때 이런 생각도 들었다. ‘ 국비 지원에 갔으면 이정도 공부하고 취업했을거 아니야? 난 할 수 있었을까? ‘ 이것에 대한 답은 아직도 모르겠다. 시간이 매우 짧았고 금방 지나갔고 우리는 이제 막 프로그래밍 언어에 익숙한 것도 아닌 어느 정도 할 줄아는 선에 그쳤으니 아직도 모르겠다. 여튼, 이제 Framework를 진행하면서 우리의 프로젝트도 탄탄대로만 걸을 줄 알았다.

 

이제 두 번째 사건아닌 사건 같은 일이 생겼다. 난이도 급 상승으로 인해 못 따라오는 팀원이 생겼던 것이다. 그 팀에 소극적이던 팀원 2명이 잘 못 따라왔고 나와 대립한 의견을 가지고 있던 사람과 내가 그나마 따라갔다. 그 사람이 나이가 제일 많았고, 제일 간절했고, 제일 급했기 때문인지 모르겠지만 방관자였던 멘토를 제외하면 거의 팀장과 같은 사람이었다. 그 사람이 내게 말 했다. “ 나머지 두 명은 개발이 어려우니까 프론트랑 서류로 빼버리고 너랑 나랑 둘이서 해야한다.” 나도 솔직히 나머지 두 명이 개발이 어려울 것 같다는 생각이 들었지만 그래도 나눠서 같이 하고 싶었다. 하지만 나한테 또 대책을 마련하라 하면 솔직히 아직 내가 두 사람을 책임 질 실력이 아니었기 때문에 다른 방도가 없어 그냥 수긍했다. 이제와 생각하면 여기서 우리 팀은 살짝 틀어졌지 않나 싶다. 그 사람의 주장이 강했고 우리는 따랐다. 우리의 의견은 애초에 잘 받아들여지지 않았고 나 혼자 항의를 하기엔 나머지 두 명이 너무 소극적이었고 참여 태도도 별로 좋지 못 했다. 그래서 거의 끌려다녔다. 하지만 어느 정도는 인정하고 있었다 그 팀원은 나와는 다르게 한 목표만 보고 뚫을 생각만 하는 사람이기 때문에 나는 그 팀원을 인정하면서 이끄는 대로 따라가고 만약 막히는 일이 있으면 그때 내가 돌아가자 제안해서 팀을 좀 유연하게 만들 생각이었다.

 

오산이었다. 이때부터 슬슬 힘들어졌다. 주장이 강해 내가 말 하는 것도 불편해졌다. 팀원이 이러면 안 된다 생각했다. 다른 소극적인 팀원들도 점점 더 소극적으로 변했고 초반과 달리 중 후반의 팀 분위기는 완전 그 팀원의 마음에 들어야 통과하는 느낌의 프로젝트가 되어가고 있었다. 나는 항상 말 했다 아닌 것 같은 부분엔 아닌 것 같다고 하지만 역시 받아들여지지 않았다. 그렇게 그 팀원의 기준에 맞춰 팀 프로젝트가 돌아가게 되었다.

 

방학이 끝나고 또 서류 작업이 있었다. 서류를 쓰기로 한 팀원이 쓴 서류가 1학년 팀장의 마음에 들지 않았다. 1학년 팀장은 그 자기 주장이 강한 팀원이다. 그냥 이 사람이 팀장 느낌이었다. 그래서 그냥 1학년 팀장이라 호칭하겠다. 이 1학년 팀장은 자기가 할 일에 더해 서류까지 봐줬다. 그러다 프론트 담당하는 팀원이 1학년 팀장이 원하는 아웃풋을 못 내기 시작했다. 1학년 팀장은 여기에도 관여했다. 결국 1학년 팀장은 나와 같이 로직을 담당하기로 했지만 추가로 서류와 프론트까지 관여했다. 나중에 말을 들어보면 얘네들 작업 물을 보면 못 믿어서 그렇다고 하는데 나는 그렇게 생각하지 않는다. 내가 잘 짰다고 생각하는 코드도 다른 사람들이 볼 때는 별로일 수도 있다. 프로그램의 고수가 짠 코드도 내가 봤을 때 별로 일 수도 있다. 물론 내가 잘 몰라서 그런거겠지만 주관적인 의견이란 그런 것이다. 옮고 그름을 한 사람의 주관적 의견에 몰아 넣은 팀원들과 팀장 그럼 당연히 수동적인 형태의 팀이 될 수 밖에 없고 그것을 주도하는 주관적 의견을 가진 사람은 당연히 모든 일에 관여하며 힘들 수 밖에 없다. 스스로 자초한 것이다. 라고 나는 생각했고 프로젝트가 끝나고 그 1학년 팀장에게 말하기도 했다.

 

그렇게 여차저차 해서 마무리가 되었고 2학기가 시작 되면서 우리는 AWS에 프로젝트를 올려야 했고 2학년 멘토가 맡은 Python으로 짠 Flask와 Tensorflow를 통해 머신러닝과 Tomcat 서버 통신을 구현하고 AWS에 DataBase와 프로젝트를 올리고 로컬과 연동한 Datasource 부분을 바꿔 AWS와 연결해 뒀고 프로젝트 제출을 했다. 뒤로 가면 갈 수록 1학년 팀장은 힘들었고 나와 부딪히는 일도 자주 있었다. 하지만 절대 감정적으로 부딪히진 않았다. 애초에 그 1학년 팀장은 흔히 학교에서 같이 다니는 무리에 한 명이었고 나보다 형이었고 나는 형들을 존중한다. 여튼, 결국 완성 시킨 못 한 파트도 있지만 800여팀 중 40여 팀 안에 들어 입선을 했다.

 

그렇게 끝이 났고 상금 40만원이 들어와 똑같이 나눴다.

 

사실 상금 부분에서는 일이 하나 있었는데 이 일은 한이음 공모전 회고가 아닌 파스타 공모전 회고에서 적어보겠다. 한이음 공모전과 파스타 공모전은 같은 프로젝트를 다듬어서 나간 것이라 거의 비슷하나 아쉬운 점이나 한이음에서 배운 것을 적용한 점이나 조금 다른 부분들이 있다.

 

이렇게 한이음 공모전 프로젝트 회고를 마친다...

되돌아보면서

---

팀 프로젝트라는 것이 그렇다.

 

개개인의 능력도 물론 중요하지만 어떤 사람이 어떻게 팀을 이끌어가고 팀원은 스스로의 주관적 의견을 제시하고 받아들여 호응할 줄 알아야 한다. 나 혼자 하면 되는 것이 아니라 모두 같이 적극적으로 해야 한다. 이게 되게 교과서적인 말인 것 같지만 팀 단위로 무언가 해 본 사람이라면 내 말이 이해가 갈 것이다.

 

프로젝트를 하면서 많은 것을 배우고 느꼈다. 프로그래밍 언어를 하나도 몰랐던 내가 7,8개월 만에 팀으로 프로젝트를 만들었다니 물론 완성도가 높은 것은 아니지만 해냈다는 것이 뜻을 두고 싶다.

 

Spring Framework를 공부하면서 프로그램이에 더 깊은 재미를 느꼈고 머리가 아프고 어려웠지만 무언가 아웃풋이 나올 땐 기분이 좋았고 뿌듯했다. 또, 처음 입할 할 때 프로그래머가 어떤 일을 어떤 식으로 하는지 궁금했는데 직접 해보니까 좋은 경험이 되었다. 결과나 과정을 떠나 배워가는 게 많았고 여기서 배운 내용을 토대로 빨리 내 다음 프로젝트를 진행해 보고 싶은 생각이 머리 속에 가득하다.

 

몇 가지 느낀 점이다.

• 서류의 버전 관리가 중요하다.
• Git Hub는 팀 프로젝트에 필수적이다.
• 누구 한 명 빼 놓고 일을 하면 안 된다.
• 팀원 모두가 공동으로 할애 할 시간이 정해져 있으면 좋다.
• 적극적 참여는 선택, 권장이 아닌 무조건, 필수이다.
• 구글링을 잘 해도 코드에 대한 이해도가 떨어지면 참고할 수가 없다.
• Clean Code란 것을 나중에 알아서 적용을 못 해 본 것이 아쉽다.

한 사람(1학년 팀장)과 서로 부족한 점을 말 하기로 했는데 그것에 대한 평가이다.

• 내가 언제 나를 “최소한의 노력으로 최대한의 결과를 추구한다”고 소개한 적이 있는데 딱 그 말이 맞다고 했다. 나 스스로에겐 효율성이라 생각한 부분이 다른 사람에겐 단점으로 보일 수 있었다. 하나 배웠다. 예를 들면 1부터 100까지 있을 때 80까지가 가성비가 좋고 그 뒤로는 하면 더 좋고 안 하면 그만인 수치가 있다고 하면 나는 80까지 하는 것을 선호한다. 더 완벽하기 보다 더 효율적인 면을 추구한다. 하지만 다른 누군가에겐 20이 아쉬운 경우가 있을 것이란 생각을 했는데 1학년 팀장이 이경우에 속했고 그런 사람들에겐 내가 아쉬운 사람이 될 수 있다는 부분도 인지했다.
• 유연한 대처가 언제나 득을 본 것이 아니다. 막혔을 때 뚫으려 하지 않고 돌아가려 하다 보니 아웃 풋이 잘 안 나오는 경우가 잦았다고 한다. 이 부분도 인정한다. 유연함은 다르게 말 하면 돌아가려함이다. 돌아갔는데 그 길도 막혀있다면 또 돌아갈테고, 또 막혀있다면 또 돌아갈테다. 그렇게 돌아가다 보면 오히려 뚫는 속도가 더 빠를 때가 있다. 다시 한 번 생각하게 되었다. 내가 기술에 대해 잘 알고 활용할 수 있고 대처 방안이 뚜렷한 게 아니라면 돌아가는 것이 오히려 독이 될 수 있음을 다시 한 번 느꼈다.

프로젝트를 돌아보면 참 많은 일이 있었고 좋은 경험이었다.

개발을 처음 시작하는 사람들이라면 첫 프로젝트는 팀 프로젝트로 하는 것을 추천한다. 어차피 개발자는 협업이 필수적이고 어디서나 인간 관계는 똑같기 때문에 여러 부류의 사람을 만나고 배우고, 버릴 건 버리고 하는 것이 좋다고 본다.

전체 회고를 마친다..

---

---