2022년 2월, 3-1학기 개강을 앞둔 시점까지 방학동안 한 창 Spring을 공부 하던 중이었다.
독학이 전부였던 나에겐 협업과 커뮤니티라는 기회는 항상 목말랐지만, 부끄러운 실력 탓에 엄두가 나질 않았다.
방학동안 진행한 공부를 바탕을 스스로의 부끄러움이 조금씩 사라질 무렵, 팀 프로젝트에 대한 갈증이 더욱 커져갔다.
그렇게 개강을 앞두고 기회를 탐방하던 중, 에브리타임에서 대학 연합동아리인 UMC를 알게 되었다.
UMC..?
공식 홈페이지 : https://www.makeus.in/umc
University Makeus Challenge 로 대학생 대상으로 하는 앱 런칭 IT동아리 입니다
그렇게 좋은 기회를 발견하여 같이 프로그래밍 공부를 하는 동기와 함께 신청했다.
간략하게 면접 내용을 복기해보자면,
채용 면접 처럼 기술적인 질문은 없었고, 프로그래밍과 사람에 대한 질문이 많았던 것 같다.
- 좋은 개발자란 뭐라고 생각하시나요?
- 학교 생활과 UMC활동이 겹친다면 어떻게 하실 건가요?
- 팀원과의 마찰이 생긴다면 어떻게 해결하실 건가요?
요정도 질문들이 기억나는데, 질문도 그렇고 분위기 또한 전공 / 비전공자 구분이나 실력, 학년 상관없이 열정이나 태도를 중요시 했던 것 같다.
나는 Spring 파트로 지원하였고, 잘 봐주셨는지 최종적으로 합격했다는 연락을 받게 되었다.
활동
OT
오미크론 변이 코로나가 제일 왕성한 시기이다 보니 OT도 비대면으로 진행하였는데, 처음으로 게더를 활용하여 귀여운 캐릭터로 앞으로의 활동을 들었다. 10주간의 팀별 스터디가 이루어지고, 이후 8월 말까지 스터디 한 내용을 바탕으로 앱런칭을 하는 내용이었다.
발표 세션이 끝난 뒤, 다른 참가자들과 함께 얘기하며 즐겁게 OT가 끝났다.
10주간의 스터디
스터디 진행은, UMC 운영진에서 제공되는 강의와 일종의 워크북을 기반으로 하는데,
강의를 먼저 수강한 뒤, 해당 워크북을 기반으로 공부, 조사를 한 후에 팀 단위로 주 1회씩 스터디(?) 형식으로 공유 및 발표를 진행한다.
스터디 방식
나는 Spring 1팀 리더로 참여하여 스터디를 진행 및 참여하였다.
우리팀의 방식은 각자 워크북 내용을 발표하고 피드백하는 형식이었다.
이 방식의 재미있었던 점은 동일한 워크북을 기반으로 공부하는데, 그 내용들이 조금씩은 각자마다 달랐다는 것이다. 각자 메인 주제에 대한 +α 가 다르다는 말이다.
단점으로는, 발표를 각자 하다보니 스터디 시간이 길어지고, 중복되는 내용들이 많아 자칫 지루해질 수 도 있었다. 스터디가 길어지면 단순히 시간을 많이 쓰는 문제가 아니라, 참여가 저조해 질 수 있다는 걸 느꼈다. 나조차도 뒤로 갈 수록 쳐지고, 질문이나 피드백에 소극적으로 변했다는 것을 느꼈기 때문이다. 그래서 5명의 팀원 중 랜덤으로 2, 3명만 발표하기로 추후 변경되었다.
강의와 워크북
우선 강의는 프로그래밍 강의 답게 친절하지 않다. 불쾌한 불친절이 아니라, 모든 걸 알려주지 않는 다는 말이다. 내가 알아야 하는 개념, 키워드, 결과 정도 간단하게 설명해준 뒤 직접 찾아보고 부딪히며 학습하라는 성격이 강하다. 이 야생성 있는 교육방식(?)에 공감하는 나는 좋았다. 열정이 받쳐준다면, 이 만큼 도움되는 학습방법도 없다는 생각이다.
1 ~ 3주차 강의 내용이 제일 좋았다.
그 동안 독학으로 도메인 역량만 공부하던 나는 서버, 포트 포워딩, 웹서버, 프로토콜 등 당장 사용하지 않는 지식들에 대해선 정말 무지했다는 걸 깨달았다. 서버의 역할, 그 역할을 수행하기 위해서 단순히 내가 작성한 코드의 동작이 전부가 아니라는 것도 깨달았다.
그 이후로는 자주 사용되는 ERD 설계부터 Spring 그리고 실습까지 이루어졌다.
강의 내용에서 아쉬웠던건, Spring을 실습과 함께 설명해주는데 전반적인 동작 방식에 대한 설명이 많이 부족했다고 생각한다. 핵심 원리보단 "어떻게 사용할 수 있는가"에 초점이 맞추어져 있었다.
Jwt나 Jdbc에 대한 개념 설명 역시 매우 부족하고, 사용법에 초점이 맞추어져 있었다. 실제로 실습을 할 수 있는 프로젝트파일이 제공되었는데, 원리 없이 사용법이 적혀있었다.
사실 10주 안에 사용되는 코드를 모두 설명하기엔 무리가 있다는 점에 공감한다. 이러한 강의와 프로젝트 파일을 받았을 때, 본인이 얼마나 흡수하고 공부하는지에 달린 것 같긴하다. 확실한 건, 10주간의 스터디만으로 다음에 있을 앱런칭을 준비하기 위해선 정말 많이 공부해야 한다는 생각이 들었다.
앱 런칭 프로젝트
위 진행하는 스터디는 6월 중순에 마무리가 된다. 스터디 마무리와 함께 앱 런칭 프로젝트 PM을 모집받는다. 실현하고 싶은 아이디어가 있다면 누구든! 신청할 수 있다고 하여 나 역시 신청하였다.
PM은 프로젝트 매니저로 팀장의 역할과 함께 기획의 업무도 맡는다. UMC 프로젝트의 PM은 추가로 개발에도 참여하게 된다.
내가 기획한 아이디어는 아래와 같다.
팀 빌딩이 이루어 지고, 7월의 시작과 함께 해커톤을 시작으로 앱런칭이 시작하게 된다
우리 팀은 안드로이드 (2), 서버(Spring) (4), 디자이너(1)의 구성원으로 이루어졌다.
8월 25일, 26일에 진행되는 데모데이까지 개발을 이어나가면 된다.
결론적으론 내 프로젝트는 데모데이에 부스를 열기에 완성도가 너무 낮다고 판단하여 참여하지 못하였다.
안드로이드 진행도가 다른 파트에 비해 너무나도 느렸기 때문이다.
서버팀은 인원이 4명인데다, API만 개발하면 되기 때문에 진도가 매우 빨랐지만, 안드로이드 팀은 뷰와 함께 API 연결하는 부분까지 책임져야 했는데, 팀원분이 API 요청 경험이 없으셔서 학습과 함께 진행되다 보니 더 늦어졌다.
아쉽게도 참여는 못했지만, 매주 회의를 하며 진행도를 노션을 통해 공유하며 어느정도 진행이 되긴 했었다.
디자인 작업
프로젝트 회고
PM으로서의 회고
PM의 가장 매력적인 포인트는, 내가 생각한 아이디어를 주도적으로 실행 할 수 있다는 점이다.
그리고 아무것도 모르는 나는 PM을 만만하게 생각했었던 것 같다.
기획은 단순히 "이거 좋지 않아?" 로 끝나는게 아니었다. 아이디어의 구체화 뿐만 아니라, 아이디어의 근거와 유저 리서치, 시나리오 및 유저 페르소나 등 해당 아이디어를 검증하는 기획이라는 분야에서의 넓은 지식에 대해 굉장히 무지한체 덤벼들었기 때문이다. 거창하게 준비하지 않아도 실행할 순 있다. 하지만, 중간중간 바뀌는 기획 내용이 곧 개발 기간에도 영향을 줄 뿐더러, 좋게 말하면 "팀원들의 의견을 적극적으로 수용", "같이 만들어가는 아이디어" 이지만 반대로는 "구체적이지 않은, 완성되지 않은 아이디어"인 셈이다.
디자이너분과 협의 할 때도, 완성되지 않은 기획안을 토대로 회의를 하다보면, 7주차까지 새로운 구현 하나하나마다 새로운 아이디어를 반영하게 되었다. 회의시간이 길어지고, 결정하는데 오래 걸리다 보니 단점들이 보이기 시작했다. 항상 같이 정하는게 좋은 것만은 아니라는 생각이 들었다.
또, 개발 기간 중에 생기는 아이디어에 대해 개발자적인 개입이 항상 존재했었다. 물론 구현 가능성도 중요하지만, 그게 기획 단계에 영향을 크게 미친다면 새로운 기능/서비스/아이디어는 더디게 등장했을 것이다. 기획과 개발의 분리의 긍정적인 부분을 자꾸 생각하게 되는 경험을 자주 했다...
백엔드 개발자로서의 회고
- JDBC
평소 공부를 할 땐, ORM 기술인 JPA를 사용하여 DB에 접근하였었는데, 이번 프로젝트에서는 UMC에서 배운 내용을 바탕으로 하다보니, 팀원들이 모두 배웠다고 생각하는 JDBC를 사용하기로 했다.
JDBC를 옛날 기술(?)로 치부하는 경향이 있다는데, 이유는 잘 모르겠다. 길어지는 SQL쿼리문에 실증이 나서 그런걸까..? 관련해서 찾아보니 옛날 기술이라기 보단 장단이 존재하는 것 같았다. 크게 비교하면 ORM의 사용이유에 대한 논란까지 이어지더라. 막상 JDBC를 직접 사용해보니 JPA를 무조건 사용해야 하는 이유를 체감하진 못했다. 그래도, JDBC를 사용해보면 서 느낀점을 몇가지 정리해보면,
-
SQL 쿼리문을 자주 사용한다
문자열로 작성되기 때문에 오류를 놓치는 경우가 종종 있었다(공백이나 줄바꿈에서 특히...) 그래도, SQL을 직접 작성하다 보니 쿼리문에 조금 더 친숙해진 것 같다. 추가로 join에 대해 ORM과 다른 점이 있다면, FK를 두개 가진 Entity에 대해서 매번 2번의 조인이 이루어지지 않도록 사용할 수 있다는 점이었다. 더 나아가서, 쿼리에 더욱 친숙하게 접근할 수 있다. (exist, like, count 등등..)
물론 JPA도 JPQL이나 QueryDsl 기술을 통해 세부적인 쿼리문 작성도 가능하지만, JPA의 핵심 개념이 아니라 단점을 보완하는 기술이라는 점에서 조금 다르다는 생각이 들었다. -
코드가 매우 길다....
-
DB에 더 친화적이다. ORM기술이 이 점을 탈피(?) 하고자 했다는 점을 고민했다고 한다.
- 배포
도커를 사용하여 EC2에 배포하였다. Github을 통해 공통으로 코드를 공유하는데, OAuth Key값이나 S3 프로퍼티 등 민감한 정보도 public Repository에 올릴 순 없었다. 그래서 gitignore에 추가했고, 그냥 Github에 있는 코드를 그대로 빌드하면 당연히 정상적으로 작동하지 않는다. 그래서 자동 배포환경을 위해 여러 가지 조사를 한 결과 다음과 같은 결과를 얻었다
- 프로퍼티 파일을 여러개 만들어서, include를 통해 관리한다 (기본적인 개념이지만... 이때 알게 되었다)
- CI/CD 구축에 자주 사용하는 jenkins를 사용하려면, EC2 인스턴스가 2개 필요하여 포기...
- Github Actions와 Runners를 통해 구성, 이때, workflows에 민감한 정보가 담긴 프로퍼티 파일을 주입한다!!
위 과정을 거쳐 구성하게 되었다. Github Actions는 무궁무진한 기능을 가진 것 같다. 메일이 자주 와서 조금 그렇긴 하지만, 그래도 테스트 제약등을 걸어 무분별한 Merge를 방지 할 수 있고, 여러 플러그인들이 존재하여 ssh까지 조작할 수 있어서 놀라웠다.
- 협업
매번 목말라했던 협업. 혼자하는 것과는 많이 다르다. 내가 당연하게 생각하고 있던 개념들은 나만 당연하게 생각하고 있다는 것을 알아야 한다. 또, 그게 항상 정답이 아니라는 것도 유연하게 가지고 있어야 한다. 그렇기에 항상 문서화 하며 규칙을 정해두어야 하며 (code convention, git branch strategy, ... ) 역할 분담과 소통이 중요하다는 생각이 들었다. 이번 프로젝트는 솔직히 혼자하는 게 더 좋았을 거란 생각이 들었다. 팀원들은 좋지만... 항상 좋은 영향을 주진 않는다고 깨달았다. 여러 IT동아리, 해커톤에서 열정을 중시하는 지 알 것 같다. 매주 약속한 각자의 업무를 누군가는 하고, 누군가는 항상 안한다면... 단순히 진도의 문제로 끝나지 않는다. 팀 전체에 영향을 주더라...
협업에 필요한 기술은 충분히 배울 수 있다. 기능 구현에 있어서 의견 충돌을 해결하고, 나아가는 것도 좋았다. 하지만, 열심히 하는 사람과 그렇지 않는 사람이 분명하게 보이는 게 너무나도 힘들었다.
이 갈등도 극복해야하는 것이라면, 난 팀장의 자질이 없었다. 하는 사람들만 하는 팀이 되어버린 기분이 들었을 땐, 하는 사람들 마저도 열정이 식는 느낌을 받았다.
항상 이 팀에 맞는 사람을 모을 순 없다. 하지만, 팀의 분위기나 시스템이 그런 부분을 보완할 수 있다고 생각한다. 괜히 팀 문화와 소통을 중요시 하는게 아니라 느꼈다.
팀에 합류한다는 건, 개인 뿐만 아니라 팀에게도 큰 이벤트이다. 항상 이벤트의 결과는 + / - 로 구분되는데, 긍정적인 부분을 기대하기 보단, 부정적인 부분이 없길 기대하는 것이 중요할 것 같다. 나는 그럼 결과를 가져올 팀원이 되기 위해선 팀을 어떤 관점으로 봐라봐야 할 지 조금 느낀점이 있다.
팀의 문화는 생각보다 중요하다. 어떤 사람들이 있고, 어떤 분위기와 문화인지 확인해보고 합류하도록 하자. 이건 개인 뿐만 아니라 해당 팀에 대한 예의라고 생각한다.
