멘토링 시스템 개발프로젝트, 8주간을 돌아보며

안녕하세요! 국민대학교 인턴 이인평 입니다.

시간이 정말 빠르네요..6월 29일 이노베이션 아카데미를 처음 방문할 때가 엊그제인것 같은데 벌써 인턴을 마무리할 때가 되어 마무리 문서 작업을 하고 있다니.

두 달동안 정말 열심히 인턴을 수행했습니다. 그래서 그런지 이번 방학이 학생으로 보냈던 방학 중 체감 상 가장 짧았던 것 같습니다..살면서 일주일이 이렇게 짧은 시간인지 처음 알게 되었네요.

그동안 이노베이션 아카데미 인턴을 수행하면서 이호준 멘토님, 그리고 같이 협업한 다른 국민대 인턴분들에게 소프트웨어 개발의 많은 지식들을 배울 수 있어 저에겐 너무나도 과분한 시간이었습니다. 배운만큼 코딩 실력, 문제 해결 능력도 인턴을 시작했을 때보다 많이 늘은 것 같아 기분이 좋네요!

그래서 만약 앞으로 기회가 된다면 다시 이노베이션 아카데미 인턴으로 들어와 소프트웨어 개발에 대해 더 많이 배우며 성장하고 싶습니다! (이미 대학교 졸업 반인데.. 힘들겠죠? ㅠ.ㅠ)

---

그러면 지금부터 제가 두 달동안 이노베이션 아카데미 인턴으로서 어떤 경험들을 하였는지 한번 알아볼까요? 지난 인턴 기간을 돌이켜 보고, 제가 수행했던 큰 이벤트 별로 기간을 나누어 함께 공유해보도록 하겠습니다!!

06.29 ~ 07.01

터미널과 VIM 세팅 그리고 멍…때렸던 기간..?

떨리는 첫 출근날, 국민대학교 인턴 8명은 개인마다 맥북을 지급받게 됩니다.(그것도 언박싱이 안된 맥북!) 저는 항상 맥북을 써보고 싶었는데 돼지 목에 진주 목걸이라는 생각으로 쓰지 않았었거든요. 가격도 비싸고… 계속 윈도우로만 작업했던 저였기에 너무나도 설렜습니다. 저는 지급받은 맥북을 갖고 정해진 자리로 돌아가 트랙패드, docker 설정, homebrew 설치 등 맥 자체 환경 설정을 하게 됩니다. 두근두근..

얼마 지나지 않아 이호준 멘토님께서는 앞으로 있을 개발을 위해 터미널과 VIM editor 환경을 개발이 편하도록 설정해야 한다고 하셨고, 저는 인터넷 블로그를 참고하여 저의 기호에 맞게 환경 설정을 진행했습니다.

보기만 해도 흐뭇해지는 알록달록한 터미널과 Vim..인턴이 끝난 후에도 제 성에 찰 때까지 계속 커스텀할 예정입니다. 커스텀 과정들을 저만의 블로그에 업데이트할 계획도 세워뒀습니다.

국민대 인턴 모두 환경 설정이 완료된 것을 확인한 이호준 멘토님은 우리에게 아젠다를 던져주셨습니다.

“멘티와 멘토를 매칭해주는 서비스를 각자 구상해보기”

앗 벌써 개발 시작인가..? 저를 포함한 국민대학교 인턴들은 개발할 생각에 부푼 마음을 접어두고 자리로 돌아가 각자가 생각하는 매칭 서비스를 그림 또는 글로 나타내기 시작합니다.

………………………..

………………………..

………………………..

‘왜 아무 말씀이 없으시지..?’

국민대 인턴들은 모두 멘붕이 오기 시작합니다. 분명 멘토님이 서비스를 구상하라고 하셨는데 그 뒤로는 우리에게 무엇을 해야 할지 얘기해주시지 않았습니다. 다음 해야 할 일들을 공지받지 못한 국민대 인턴들은 거의 이틀동안 대기 상태에 머무르게 됩니다.

그리고 첫 출근부터 2일이 지난 7월 1일 오후, 갑자기 이호준 멘토님은 국민대 인턴들을 세미나실로 부른 후 개인 맥북을 통해 한달 전 진행했던 우당탕탕 개발기 게시글을 보여주셨습니다. 우당탕탕 개발기를 진행하는 과정에서 나온 문서들을 소개 하시면서, 이 모든 것들이 앞으로 인턴분들이 해야 일이라고 말씀하셨습니다. 문서들은 정말 자세하고 꼼꼼 하면서 너무나도 전문적이더군요.. 보면서 경악을 금치 못했습니다..

2일동안 인턴들에게 해야할 것들을 얘기하지 않은 이유도 얘기해주셨는데요, 그것은 바로 ‘학생 관성’ 때문이라고 합니다. 이는 주어진 과제만 열심히 하는 학교 시스템에 익숙해져서 수동적인 자세를 유지한다는 뜻으로, 이호준 멘토님이 만드신 단어라고 합니다. 멘토님은 개발을 하기 위해선 ‘학생 관성’ 을 깨야 한다고, 인턴들 스스로 깨길 바랬다고 하셨습니다..(결국은 멘토님이 깨주신 걸로…ㅎㅎ)

이틀동안 대기만 하고 있던 저는 인턴을 너무 쉽게만 생각하고 있던건 아닌지 생각하며 스스로를 반성하게 되었습니다.. 이호준 멘토님의 설명이 끝난 후, 국민대 인턴들은 그동안 각자가 생각해왔던 매칭 서비스에 대해 다음 날 발표하고 발표 내용에 대해 토의 하기로 결정하였습니다.

---

07.02 ~ 07.06

서비스 구상 회의 시작!

개발을 시작하기 전, 어떠한 것을 개발할 것인지에 대한 회의를 본격적으로 시작하게 된 기간입니다. 이 기간에 진행했던 모든 회의 들의 내용은 구글 드라이브 공유된 폴더에 구글 시트와 문서로 정리하여 기록했습니다. 이때 진행했던 회의들이 ‘학생 관성’을 깨주는 아이스 브레이킹 역할을 많이 해주었습니다. 여러 사람들 앞에서 저의 생각을 설명하는 흔치 않은 경험도 할 수 있어서 저도 모르게 스스로 성장했다고 생각합니다!

첫 회의를 진행하기 전, 이호준 멘토님은 앞으로의 회의가 어떤 식으로 진행되어야 하는지 다음과 같은 방향성을 제시 해주셨습니다.

멘토님이 적으셨던 걸 지우고 저희가 다시 쓴거라 글씨가..ㅠㅠ

국민대 인턴들은 멘토님이 제시해주신대로 서비스 구상을 위한 회의를 제일 먼저 시작하기로 결정하였습니다!

드디어 7월 2일 처음으로 각자가 생각한 멘토링 매칭 시스템을 화이트 보드에 써가며 다른 사람들에게 설명하는 시간을 갖게 되었는데요, 하나의 주제로 이렇게 다양한 서비스가 도출될 수 있다는 것에 정말 놀랐습니다… 정말 각자 생각하는 서비스가 전부 다르더라고요. 이 많고도 너무나도 다른 내용을 어떻게 하나로 합쳐야 할지 처음에는 모두 막막했습니다..

하지만 회의를 오전과 오후로 나누어 몇 일에 걸쳐 꾸준히 진행한 결과, 7월 6일에는 개발할 매칭 서비스에서 제공할 행위를 어느 정도 추려낼 수 있었습니다!!

이와 같이 회의 내용들을 구글 문서에 기록하였습니다.

구글 시트를 통해서도 그 날의 회의 내용 및 결정 사항을 기록했습니다.

---

07.06 ~ 07.09

지금까지의 회의 내용 정리!

지금까지 구글 드라이브의 공유된 폴더에 회의 내용을 모두 기록하긴 했지만, 그 날의 회의 내용 raw 상태를 글로만 옮겼을 뿐, 정리된 문서로는 기록하지 않았었습니다. 서비스에서 제공할 행위가 도출된 걸 발견한 이호준 멘토님께서는 지금까지 기록했던 회의 내용들을 바탕으로 요구사항 명세서를 작성하라 하셨습니다. 작성 방법은..

서비스 행위를 기준으로 우선순위 / 주요문제 / 목적 / 문제 해결을 위한 방법 / 문제 해결 시퀀스 순으로 정리하라!

멘토님께서 설명 하시면서 진행한 판서 내용입니다.

멘토님이 말씀하셨듯이, 저희가 정했던 서비스 행위를 기준으로 각 항목들을 채워나갔습니다. 이 과정에서도 서로 의견이 엇갈리는 내용이 있어서 진행하는데 모두 애를 먹었던 기억이 납니다..

그래도 서로 합의점을 찾아가며 회의를 계속 진행하였습니다. 위 이미지처럼 구글 시트에 정리하기 전에 먼저 판서로 각 서비스 행위 아젠다마다 정리하였습니다. 그리고 마침내..!

행위 아젠다를 기준으로 정리한 구글 시트 이미지입니다!

두둥~~ 문서 정리가 완료되었습니다. 이렇게 정리하고 나니 안개속에 가려져있던 우리의 매칭 서비스가 서서히 보이는듯한 느낌이 드네요. 그동안 진행했던 회의들이 헛되지 않았다는 것을 보여주는 이미지입니다. ㅠ.ㅠ

서비스에 대한 모든 내용이 정리가 되었으니 이젠 서비스 시퀀스 다이어그램을 그릴 차례겠죠?

(시퀀스 다이어그램 기록들을 찾아보니 데이터 시퀀스 드리븐을 진행한 자료만 있네요..시퀀스 다이어그램을 그린 후 서비스 데이터를 도출하는 과정을 따로 기록해두진 않았군요 ㅠㅠ..데이터 시퀀스 드리븐을 한 이미지에 시퀀스 다이어그램과 데이터가 함께 나와있으니 그 점 고려해서 봐주시면 될 것 같습니다..!)

드디어 이호준 멘토님이 처음에 제시해주셨던 방향에 맞게 잘 온 것 같습니다! 각 아젠다 마다 작성한 시퀀스 다이어그램도 어느 정도 그림이 나왔네요!!

---

07.10 ~ 07.14

팀 빌딩, 백엔드를 건드려보자!

드디어 팀 빌딩 시간입니다. 팀 빌딩 전 이호준 멘토님께서 풀스택에 대해 간단히 판서로 설명해주셨습니다.

이 모든 것을 할 수 있다면 당신은 풀스택 개발자..

Node.js로만 웹 사이트를 구현하고 ‘저는 풀스택 개발자입니다!’ 라고 하면 큰일나겠네요.. 저는 정말 한참 멀었다는걸 한번 더 실감하게 되었습니다.

멘토님은 설명을 마친 후, 국민대 인턴들을 프론트, 백엔드(서비스), 백엔드(관리자) 팀으로 나눈 후 개발을 진행할 것이라 하셨습니다. 즉시 팀 빌딩 구글 시트파일을 만들어 인턴들 각자 하고 싶은 팀을 선택하고..마침내..

저는 백엔드 팀으로 들어가게 되었습니다! 인턴을 시작하기 전에 졸업 프로젝트에서 프론트를 맡았던 경험이 있어서..이번엔 백엔드를 해보고 싶었습니다! 자리를 양보해준 박종민 인턴님 감사합니다(__). 저와 김정식 인턴님, 윤준호 인턴님은 백엔드(서비스) 팀으로서 앞으로 매칭 서비스에서 제공할 서비스들을 구현하게 될 것입니다. 서비스팀 화이팅!!!

팀빌딩이 완료된 후 우리 서비스팀은 구현해야 할 아젠다들에 대해 생각해보았는데, 서비스를 구현하는데 있어서 작성 해놓은 시퀀스 다이어그램보다 훨씬 더 자세한 시퀀스 다이어그램이 필요할 것으로 판단했습니다. 따라서 서비스 팀은 지금까지 작성 해둔 시퀀스 다이어그램을 토대로 서비스팀 버전 시퀀스 다이어그램을 다시 작성하기로 결정했습니다.

당시 작성했던 멘토 탐색 시퀀스 다이어그램 입니다.

위와 같은 형식으로 다른 서비스 행위들도 시퀀스 다이어그램을 작성했습니다. 매우 간단한 시퀀스 다이어그램이지만, 활성박스를 구체화하여 마이크로 시퀀스 다이어그램을 그리면서 멘토님이 가르쳐주신 방법 그대로 실천하려 노력했습니다. 그리고 시퀀스 다이어그램에 명시되어있는 함수들은 구글 시트에 다음과 같이 명세서 안에 정리해두었습니다.

메소드명, 파라미터, 역할, 리턴 값 등을 명세해두었습니다!

이렇게 백엔드 서비스 팀은 서비스 구현 개발을 위한 준비를 슬슬 마쳐가고 있었습니다. 그런데 지금까지 해왔던 것들을 돌아보고 나니…정말 개발을 하기위해 사전에 준비해야 할 것들이 너무나도 많다는 것을 깨닫게 되었습니다. 저희도 이정도로 문서의 양이 많아지는데 현업에서는 과연 어느 정도로 많아질까요..? 멘토님 말씀으로는, 현업에서 개발 전에 이렇게 준비해두면 실제 코드를 작성하는 개발은 일주일 안에 끝난다고 하셨습니다. 아무래도 저희는 학생이니까 그것보단 더 오래 걸리겠죠? 그래도 친구들과 하는 프로젝트에서 개발할 때보다는 훨씬 효율적이고 잘 구현된 결과물이 나올거라 확신합니다!

---

07.15 ~ 07.17

페이즈 0 마이 페이지 시작!

백엔드 서비스팀 버전의 시퀀스 다이어그램을 계속 작성하고 함수 명세를 다듬던 중..! 이호준 멘토님께서는 때가 되었다며 국민대 인턴들을 휴게실로 모으신 후 전체 공지를 내리셨습니다.

“페이즈 0, 마이 페이지 시작!“

‘페이즈 0? 이게 뭐지?’ 멘토님의 설명을 계속 듣고 난 후, 소프트웨어 개발에서의 페이즈에 대해 이해할 수 있었습니다. 저는 지금까지 작성했던 모든 자료들을 바탕으로 개발을 시작한다는 추상적인 생각만 갖고 있었는데, 멘토님 왈 현업에서는 개발을 시작하는 단계에서도 페이즈 단위로 나누어 기능 하나하나씩 개발해 나간다고 합니다. 괜히 현업이 아닌 것 같네요..개발 과정에서 그냥 넘어가는 부분이 하나도 없네요. 정말 알면 알수록 어렵습니다 ㅠㅠ

(그리고 새삼 느끼는거지만, 이렇게 많은 지식을 알고 계신 멘토님도 정말 대단하다 생각했습니다. 과연 저도 멘토님 정도의 경력이 되면 저 정도의 지식을 머리에 담을 수 있을지..? 또 그 지식이 머리에 있다 하더라도 남들 앞에서 말로써 논리적으로 풀어낼 수 있을지..? 많은 생각들이 머리에 떠오르네요.. 일단은 멘토님이 가르쳐 주시는 대로 개발이나 진행합시다..ㅠㅠ)

멘토님께서 페이즈 0의 주제를 매칭 서비스의 ‘마이 페이지 구현’ 로 설정하셨습니다.

여기서 질문! 로그인도 구현하지 않았는데 마이페이지라뇨!?

멘토님 왈, 로그인 부분이 고려할 부분이 많기 때문에 오히려 다른 기능 개발보다 시간이 더 오래 걸린다고 합니다! 실제로 해커톤 대회에서 로그인만 구현하다가 끝나는 팀들을 많이 보셨다고 하네요. 멘토님께서는 저희의 원활한 개발을 위해 로그인 기능보다 마이 페이지 기능을 우선시 하셨다고 합니다.

그러면 서비스 개발 시 분명히 회원 정보가 필요할텐데 이는 어떻게 처리해야 할까요? 정답은 바로 더미 데이터입니다!…. 생각보다 간단하죠? 현업에서 실력있는 백엔드 개발자는 프론트 엔트 측에서 쉽게 초기 개발이 가능하도록 더미 데이터를 보내주는 API를 먼저 만들어 놓는다고 합니다. 그리고 차츰 비즈니스 로직이 실제로 돌아가는 API를 구현해 나가는 거죠!

비즈니스 로직이 사용되는 실제 API를 구현하는 동안, 프론트 엔드 측에서 갑자기 더미 데이터를 보내달라고 하면 어떻게 해야 할까요? 구현 코드들을 모두 주석처리하고 다시 더미 데이터를 보내주는 코드를 작성하면 될까요?….. 아닙니다! 멘토님은 이때를 대비해서 개인적인 설정값에 따라 API이 더미 데이터만 보내주도록 하는 별도의 스위치 기능이 필요하다고 하셨습니다. 환경 변수 등을 통해 구현할 수 있겠죠? ㅎㅎ

페이즈 0을 설정한 후, 이호준 멘토님은 7월 16일에 그동안 작성했던 시퀀스 다이어그램 자료를 바탕으로 각 팀마다 페이즈 0에 대한 자세한 개발 계획을 듣겠다고 하셨습니다. 헉.. 드디어 멘토님께 우리가 준비했던 내용을 공식적으로 보여드리는 순간입니다..!

두둥..근데 생각해보니..우리가 마이 페이지에 대해 생각해본 적이 있나? 알고보니 서비스의 행위로 선정해놓은 매칭 요청, 매칭 요청 조회, 매칭 결정, 알림 조회 , 추천 멘토 탐색 에 대해서만 시퀀스를 정의해두었고 마이 페이지는 생각을 미처 못했군요. 흑.. 망치로 머리를 맞은 기분입니다..

결국 페이즈 0에 대해서 서비스, 서비스 시퀀스, 서비스 데이터, 데이터 시퀀스 드리븐 과정을 다시 거쳐야 하겠습니다! 이전에 한 번 해봤으니 분명 예전보다 더 빠르고 정확하게 시퀀스 다이어그램을 작성할 수 있을 겁니다.

프론트팀, 서비스팀, 어드민팀은 마이 페이지 기능 구현을 위해, 마이 페이지 기능에 관한 서비스 행위 아젠다를 다음과 같이 도출하였습니다.

로그인 플로우, 내 프로필 접근, 내 프로필 수정, 계정 설정 변경, 멘토 검증 확인

그리고 아래 이미지는 위의 아젠다에 대해 데이터 시퀀스 드리븐을 완성한 시퀀스 다이어그램입니다.

저희 백엔드 서비스 팀은 프론트팀에서 호출하는 API에 대한 비즈니스 로직을 구현해야 하기 때문에, WA(Web Application), API server, DB(Database), Operation server 객체를 두어 시퀀스 다이어그램을 작성했습니다. 이호준 멘토님이 얘기하셨던 MVC 패턴과 비교하면 WA 객체가 Controller, API server 객체가 Model, DB 객체가 DAO와 Database를 합쳤다고 보면 되겠네요. Operation server는 운영팀이 담당하는 서버라고 보시면 됩니다.

확실히 시퀀스 다이어그램을 작성해본 경험이 있다보니, 페이즈0 마이페이지 구현의 시퀀스 다이어그램은 전보다 신속하게 작성되었습니다. 마이크로 시퀀스 단위로 더 들어갔어야 했는데 그러지 못한 점은 약간 아쉽네요..

세 팀 모두 각 팀에 대한 시퀀스 다이어그램 작성을 완료한 후, 지금까지 나왔던 서비스 데이터를 모두 긁어모아 데이터 베이스의 테이블과 컬럼 후보군을 구글 시트에 다음과 같이 정리하였습니다.

데이터베이스 후보군 일부 이미지입니다.

일부 추출된 이미지만 보더라도 데이터가 엄청 많아 보이네요.. 꾸준한 회의의 결과 일까요? ㅎ 저희는 매일 서로 많은 회의를 진행하다 보니, 예전에 결정했었던 사항에 대해 깜빡 잊어버리는 경우가 있었습니다. 특히 데이터베이스 테이블 컬럼에 대한 혼동이 많이 일어 났었는데, 이렇게 정리된 후부터 그런 문제점들이 많이 해결되었습니다. 정리의 중요성이 아닐까 생각합니다..

그리고 이때 어떤 형태의 데이터베이스를 사용해야 할 지 다같이 토의를 진행 했었는데, 데이터 후보군에는 NoSQL 보다는 RDB가 적합하다는 것에 모두가 동의했기 때문에 RDB로 결정하였습니다. 그리고 무료로 사용할 수 있으며 많은 사람들이 흔히 사용하고 있는 MySQL Opensource 버전을 사용하기로 하였습니다.

위와 같은 데이터 후보군 내용을 바탕으로 테스트 데이터 베이스에 테이블을 생성하여 컬럼들을 채웠습니다. 그리고 저희 서비스의 데이터 베이스 ER-Diagram을 도출할 수 있었습니다.

저희는 이제 페이즈 0에 대한 서비스 개발 준비를 마쳤습니다! 다음엔 코드 개발을 위한 준비를 진행합니다!

---

07.20 ~ 07.24

코드 컨벤션, 서버 사이드 스크립트 언어 및 프레임워크 정하기!

각 팀에게 페이즈 0 에 대한 개발 계획을 들으신 이호준 멘토님은 다음과 같은 과제를 부여하셨습니다.

서버 사이드 스크립트 언어 및 프레임 워크 선정,
코드 컨벤션 작성,
이에 대한 이유

드디어 인턴을 시작하고 처음으로 코드와 관련된 작업을 시작하게 되었습니다…! 보통 프로젝트를 친구들과 할 때는 프로젝트 폴더를 바로 생성해서 코드부터 작성했었는데..지금 다시 생각해보니 한 달동안 문서 작업을 하더라도 시간이 부족한 거였네요. 과거에 무식하게 프로젝트했던 날들이 후회스럽습니다 ㅠㅠ..

아무튼 위 과제를 받은 백엔드 서비스 팀은 서버 사이트 스크립트 언어와 프레임 워크를 정하기 위해 자료 조사를 진행하였습니다. 스크립트 언어 자료 조사 과정부터 소개해드릴게요!

저희가 생각했던 스크립트 언어의 후보군은 JSP, Ruby, Go, PHP, ASP, Python, Node.js 였습니다. 각 언어마다 장단점을 조사하여 저희 팀, 그리고 매칭 서비스에 가장 알맞은 것이 무엇인지 서로 많은 고민을 하였습니다.

이런 식으로 각 언어의 장단점을 조사하였습니다.

이와 같이 언어를 선택하지 않은 이유와 선택한 이유를 명시하였습니다.

저희는 최종적으로 서버 사이드 스크립트 언어로 Node.js를 선정하였는데요, 그 이유는 위의 이미지에 살짝 나와있듯이.. 가볍고 생산성이 높은 웹 개발 프레임 워크를 갖고 있으며, npm을 통한 다양한 모듈이 제공됨으로써 개발 속도와 효율성이 크게 향상된다는 장점이 있기 때문입니다. 그리고 무엇보다 가장 중요한 이유… 그건 바로.. 백엔드 서비스 팀원 모두 공통적으로 사용할 수 있는 언어가 Node.js 였습니다!

Node.js의 프레임 워크에 대해서도 많은 자료 조사를 했었는데요!

프레임 워크 정리 이미지입니다.

Node.js 의 프레임 워크로는 Express를 선정하였습니다. 그 이유는 위 이미지에 명시되어 있듯, 서버를 쉽게 실행/운행 가능하고 낮은 러닝 커브 때문이었습니다. 그리고 또 하나 가장 중요한 이유 하나는.. 김정식 인턴님이 예전에 Express 프레임 워크를 이용해보신 적이 있기 때문입니다!

앞서 말씀드린, 서버 사이드 스크립트 언어와 프레임 워크를 선정했던 이유 중 ‘가장 익숙한 언어이다.’, ‘누군가 해보았다.’ 라는 걸 보고 누군가는 실망하셨을 것 같다는 생각이 듭니다. 분명 이런 생각을 하시면서 말이죠.

‘뭐야, 장단점 다 조사 해놓고 결국 선택한 이유가 그거야?’

하지만 아무리 장점이 많은 서버 사이드 스크립트 언어나 프레임 워크라고 하더라도, 러닝 커브가 워낙 높거나 해본 경험이 없다면 선택하지 않을 이유는 충분합니다. 저희는 짧은 개발 기간안에 최대한 많은 산출물을 만들어내야 하기 때문에, 서로의 경험을 가장 우선시 하였습니다. 그렇다보니 모두가 경험했던 Node.js, 그리고 러닝 커브가 낮으며 누군가 경험해보았던 Express를 선정하게 되었습니다!

서버 사이드 스크립트 언어와 프레임 워크가 정해졌다면, 다음은 코드 컨벤션을 작성할 차례겠죠? 코드 컨벤션이란 또 다른 말로는 코드 작성 표준법 이라고도 합니다. 이를 작성하는 이유는 개발 중 나 외의 다른 사람이 내가 작성한 코드를 보고 쉽게 이해할 수 있도록 하기 위함 입니다.

처음 코드 컨벤션에 대해 들었을 때는 ‘변수명이나 함수명만 신경써주면 되겠지?’라는 생각을 갖고 있었는데 매우 큰 오산이었습니다. 제가 생각한 것보다 정….말 자세히 코드 컨벤션을 적어야 하더군요! 예를 들면 변수명과 함수명은 물론이고 else의 위치, 반복문 인덱스 선언 방법, 객체 복사, 객체 내 메소드 선언 방법, 주석, 삼항 연산자 등등.. 인턴분들과 코드 컨벤션을 만들 때 정말 머리 아파 혼났습니다 ㅠ.ㅠ

구글 시트에 기록해둔 코드 컨벤션 일부 내용입니다.

각자가 해왔던 코딩 방식이나 취향이 다 달랐기 때문에 의견 충돌이 정말 많았습니다. 그래도 서로 양보해주고 각자의 스타일을 인정해주면서 하나하나씩 정해갈 수 있었습니다. 그리고 이번 코드 컨벤션을 작성하며, 다음에 하는 프로젝트에서도 코드 컨벤션을 적용해봐야겠다는 생각을 했습니다. 이렇게 미리 코드 컨벤션을 정의하고 난다면, 후에 개발할 때는 코드 문제가 아닌 비즈니스 로직이나 서비스에 대한 내용을 다룰 수 있으니 더 좋은 결과물이 나오게 되겠죠?

---

07.27 ~ 07.31

개발 시작!

드디어…한 달 동안 준비했던 자료들을 토대로 개발을 시작합니다! 저희는 앞서 정의했듯이, Node.js의 대표 프레임 워크 Express에 MVC Pattern을 적용하여 백엔드 서비스를 구현할 것입니다.

먼저 서버를 정의하는 app.js, 라우팅 역할을 하는 route 폴더, 공용 폴더 public 등을 생성하여 Express 프레임 워크의 기반을 쌓았습니다. 그리고 이호준 멘토님이 말씀하셨듯이 개발 초기에 프론트 팀에게 데이터를 공급하기 위해 API에서 더미 데이터를 반환하도록 구현하였습니다.

저희 백엔드 서비스 팀은 이제 마이 페이지에서 사용될 ‘유저 정보 접근’, ‘유저 정보 수정’, ‘유저 커리어 정보 접근’, ‘유저 커리어 정보 수정’, ‘유저 키워드 정보 접근’ API들을 구현해야 했습니다. 페이즈 0 시작 공지를 받았을 시 작성했던 시퀀스 다이어그램이 있었기에, 우리는 따로 구현 방법을 생각할 필요 없이 시퀀스 다이어그램을 그대로 코드로 나타내면 되었습니다. 다만 시퀀스 다이어그램을 마이크로 단위로 나누어 작성하는 부분이 부족했기 때문에 비즈니스 로직 구현은 API 구현과 같이 진행하였습니다.

그리고 중간 점검 날…멘토님께서는 다음과 같은 피드백을 주셨습니다.

이러한 피드백을 받은 저희 백엔드 서비스 팀은 지금까지 만들어 놓은 API 들을 따로 백업해둔 후 express-generator를 이용하여 다시 프로젝트 폴더를 생성하였습니다. 그리고 구현하는 API마다 불러오는 모듈에서는 항상 파라미터가 undefined인지, null인지 확인해주도록 하였습니다. 그리고 dotenv 모듈을 이용하여 configuration 파일 내용을 전부 환경변수로 처리 하였으며, 해당 파일을 config 폴더에 모아두도록 했습니다.

중간 피드백을 적용한 후 백엔드서비스팀은 API를 계속 구현해나갔습니다. 그리고 구현했고 앞으로 구현해야 할 API 명세는 Notion을 이용하여 프론트 팀과 공유하였습니다.

메소드, URL, Body, StatusCode 등등을 명세하였습니다.

개발을 시작한 지 4일 되는 날, 마이 페이지에서 사용하게 될 API들을 모두 구현하게 되었습니다!! 멘토님이 직접 페이즈1을 정해주시진 않았지만, 우리 자체적으로 페이즈1을 메인 페이지 구현이라 생각하였고, 따라서 저희는 다음엔 메인 페이지에서 사용될 ‘모든 키워드 반환’, ‘추천 멘토 리스트 검색’ API를 구현하기로 결정하였습니다!

---

08.03 ~ 08.07

개발 2주차!

이제 개발 2주차에 접어 들었습니다. 저번주에 계획했던 대로 ‘모든 키워드 반환’, ‘추천 멘토 리스트 검색’ API를 구현할 차례입니다. 그런데 여기서 짚고 가야 할 내용이 있습니다. 우리는 API 개발 중 고려해야 할 점이 구현 말고도 하나 더 있었는데요..그건 바로 이것입니다!

‘서비스 퍼포먼스에 문제가 되지 않는가?’

저도 인턴을 시작하기 전에는 학생 관성이 있었기 때문에 ‘구현만 하면 되는거 아니야? 이게 왜 문제가 되는거지?’ 생각이었습니다. 하지만 나중에 다시 생각해보니, 만약 나중에 서비스가 배포 되었을 때 서비스 이용자가 매우 많아진다면..? 당연히 퍼포먼스에 문제가 생기다가 결국엔 서버 멈춤 등 일어나면 안될 일들이 발생할 것입니다.

저는 데이터베이스 테이블을 JOIN하는 과정에서 시스템 퍼포먼스에 대한 생각을 정말 많이 하게 되었는데요, 과도하게 JOIN 연산이 많아지면 VIEW 테이블을 따로 생성하여 문제를 해결하려고 노력하였습니다.

(물론 실제 JOIN 연산이 퍼포먼스에 얼마나 많은 영향을 주는지 경험해보는 못했기 때문에, VIEW 테이블과 비교했을 때 어느 것이 더 좋은 해결책인지는 모르겠네요..ㅠㅠ)

메인 페이지에서 필요한 API 구현을 모두 마친 후, Notion Page에 명세하였습니다.

멘토 리스트 접근 API에 대한 명세서입니다.

그 다음 저희는 우리 서비스의 가장 중요한 기능인 ‘멘토 멘티 매칭 생성’, 그리고 ‘유저 알림 조회’ API를 구현하기로 결정하였고, 미리 작성해둔 시퀀스 다이어그램을 기반으로 코드를 작성하였습니다!

그리고 대망의 중간 리뷰..!

코드 리뷰를 받는 장면입니다..ㅎ

프론트 팀, 백엔드 팀, 운영 팀 순서로 코드 리뷰를 진행했습니다. 각자 그동안 해왔던 것들을 검사 받기도 했고 코드의 많은 부분들을 지적받았습니다. 저희 백엔드 팀이 받은 피드백은 다음과 같습니다!

이래 저래 지적받은 부분이 많은 코드 리뷰 시간이었습니다. 그리고 저의 깃허브 병합 실수로 프론트 팀이 시연할 때 API가 작동하지 않아 너무나도 죄송했습니다.. 열심히 한다고는 했는데 항상 실수가 있기 마련이네요 ㅠㅠㅠ 프론트 팀 죄송합니다 ㅠㅠㅠ

이제 이호준 멘토님께 받은 피드백을 바탕으로 기존 코드들을 업그레이드 시켜야 하겠네요! API 디버깅, API 구현, 코드 리뷰 피드백 적용 등 할 것들이 산더미입니다~!

---

08.10 ~ 08.14

로그인 구현, 디버깅 기간!

드디어 대망의 개발 마지막주입니다.. 정말 하루하루가 어떻게 지나가는지 모를 정도로 열심히 살았네요. 얼마 전부터 분명히 얼마전까지 월요일이었는데 정신차리면 목요일이 되는 매직이 일어납니다. ㅋㅋㅋ…

백엔드 서비스 팀은 마이 페이지, 메인 페이지, 요청 리스트 확인 페이지에 이용되는 모든 API 기능 구현을 마치게 되었습니다. 이제 API 구현에 있어서는 알람 기능, 로그인 기능만 남겨두게 되었네요. 이것 또한 앞서 했던 것들처럼 인원 마다 자신의 파트를 정해서 구현을 진행했습니다. 저는 알람 생성, 접근 API구현을 맡았구요. 하지만 분명히 작동했었고 건드리지 않았는데 갑자기 작동이 되지 않는 API의 매직이 일어나서.. 우리 팀이 API로 주고 받는 데이터 형식에 대해 너무 소홀히 했던 것일까요…ㅠㅠㅠ 그래서 프론트 팀과 항상 붙어있으며 실시간 디버깅을 통해 오류를 잡는데 힘쓰며 API 구현을 했던 매우 바쁜 한 주였습니다.

그리고 저번 주에 받았던 중간 코드 리뷰의 피드백도 적용하는 과정을 거쳤습니다. 코드 리팩토링 과정 중 몇 가지를 보여드릴게요!

위 사진은 리팩토링 전 코드입니다. 무슨 코드인지 대략 설명하자면, 바인드 쿼리문을 생성하기 위해 프론트의 요청 몸체에 담긴 데이터의 개수만큼 바인딩 구문을 반복문으로 추가시키는 코드입니다. 하지만 코드가 불필요하게 길어지고, 저 코드는 다른 곳에서도 반복적으로 나타나는 경우였습니다. 따라서 백엔드 서비스팀의 김정식 인턴님은 아래와 같이 코드를 리팩토링하였습니다!

오!! 눈의 띌 정도로 코드 양이 줄어 보기가 좋네요. 모듈화하였기 때문에 반복되는 곳에서 모듈 호출을 통해 대량으로 전체적인 코드 양을 줄일 수 있었습니다! 그리고 라이브러리 폴더로 빼놓았던 모듈만 변경하면 모든 모듈에 변경 사항이 적용되기 때문에 이 또한 큰 이점이라 볼 수 있겠습니다~

그리고 위 사진은 이미 리팩토링을 완료한 코드인데요, 한번 같이 볼까요?

중간에 paramsCheck 모듈이 보이시나요? 그리고 이 모듈은 numberCheck와 omissionCheck라는 함수를 포함하고 있다는 걸 알 수 있습니다. 이 두 함수는 요청 몸체로부터 받은 데이터의 유효성을 검사하는 함수로, 인자에 배열 형태로 데이터를 채워 함수로 넘겨주면 boolean 형태로 결과를 나타냅니다. 원래 이 부분은 모든 Controller와 Model마다 유효성 검사를 해야 할 데이터를 || 연산자로 엮어서 검사하는, 매우 비효율적이면서 코드 양이 불필요하게 많아지는 상황이었습니다. 이렇게 모듈화 해서 검사하니 보기 좋네요! 이호준 멘토님께서는 지금 여기서 더 나아가, 유효성 검사를 하나의 함수로 할 수 있도록 하는 것이 시간이 지날 수록 더 편해진다고 하셨습니다!

그리고 아래 보시면, lib 모듈의 createReqDataObject 함수가 있습니다! 이 함수에 request의 params 객체와 body 객체를 인자로 넘겨주면, 두 객체가 갖고 있는 키와 값을 모두 포함하고 있는 한 객체를 리턴하게 됩니다. 따라서 Controller에서 Model의 DAO로 데이터를 전달할 때 모든 데이터를 하나씩 넘겨줄 필요없이 createReqDataObject의 리턴 객체만 넘겨주면 됩니다.

createReqDataObject의 구현 내용은 위 사진과 같습니다. 구현 내용은 별 거 없지만, 객체끼리 데이터를 넘겨주는 과정이 이러한 함수를 통해 굉장히 편리해지지 않았나요?

지금까지 리팩토링을 적용했던 여러 예시들을 보았는데요, 리팩토링에는 끝이 없듯이 저희 팀은 계속 리팩토링할 수 있는 부분을 찾아서 적용할 수 있도록 노력하였습니다!

API 구현과 디버깅을 마치고..드디어 마지막 코드 리뷰 시간!

코드 리팩토링을 진행했던 부분들 위주로 리뷰를 진행했습니다! 저희가 진행했던 리팩토링 부분을 멘토님께 보여 드렸는데요! 어느 정도 만족하시는 모습을 보여 리팩토링에 신경썼던 저희도 속으로 뿌듯했습니다..! 이호준 멘토님께서는 이렇게 리팩토링한 것들을 개인 블로그나 문서에 기록해두면서, 자신만의 라이브러리 폴더를 만들라고 하셨습니다. 경력이 어느 정도 되는 개발자들이 신입 개발자보다 업무효율성이 높은 이유는 바로 자신만의 라이브러리 폴더에 리팩토링 코드들이 있기 때문이라고..! 저도 앞으로 제가 리팩토링한 부분들을 정리하여 저만의 멋진 라이브러리 폴더를 만들 수 있도록 노력하겠습니다!

이렇게 마지막 코드 리뷰 시간이 끝나고.. 다음 주 학장님께 저희가 지금까지 했던 내용들을 발표하는 자리를 대비하여 여러가지 준비를 하는 것만 남았습니다!

---

08.17 ~ 08.21

마무리 문서 작업, 마지막 발표!

와..이제 마지막 주 입니다. 이번주는 그동안 해왔던 모든 작업들을 문서로 정리하는 시간을 가질 겁니다. 먼저 지금까지 구현했던 서비스에 대해 시퀀스 다이어그램을 재 작성할 것입니다. 다른 개발자들이 재 작성된 시퀀스 다이어그램을 참고하여 다음 시퀀스를 이어갈 수 있도록 말이죠.

완성된 서비스를 바탕으로 다시 시퀀스 다이어그램을 그려보니 더욱 세부적으로 나오게 되는군요. 위 이미지는 유저의 정보 접근의 시퀀스이구요, 각 서비스 아젠다마다 모두 다시 작성 해주었습니다. 은근히 오래 걸리더군요 ㅠ.ㅠ

그리고 멘토님께서 부탁하셨던 swagger docs도 따로 정리하였습니다.

user, main, matching, auth 로 총 4개 분류로 api를 분류하였습니다. 처음으로 yaml 파일을 수정하면서 swagger 문서를 작성해보았는데, 이렇게 정리를 해두니 정말 보기 좋군요! 나중에 프로젝트를 진행할 때도 꼭 적용해보겠습니다. 또 하나의 지식을 가르쳐 주신 멘토님께 감사합니다(__).

금요일날 있을 최종 발표를 대비해서 api 디버깅도 최종적으로 진행했습니다! 테스트 데이터베이스의 데이터를 모두 지우고 처음부터 시연 리허설을 해보며 오류를 찾고.. 끝없는 디버깅..

그리고 바로 발표 당일..!

다같이 모여 발표 대기 하는 장면입니다. 다들 발표를 잘 해주어서 저희가 지금까지 해왔던 모든 것들을 잘 나타낼 수 있었습니다. 정말 모두 고생 많으셨습니다! 이호준 멘토님, 김수보 멘토님, 이민석 학장님께서도 저희에게 도움이 되는 말씀들을 많이 해주셨습니다. 감사합니다!

---

08.24 ~

인턴 끝..

드디어 두 달간의 인턴 여정이 막을 내리게 되었습니다. 솔직히 저는 끝나면 홀가분하고 마음이 편해질 줄 알았는데, 그 사이에 회사에 정이 들었는지 왠지 마음이 먹먹해지는군요.

올해 1학기 때 인턴을 합격한 회사가 이노베이션 아카데미를 포함하여 세 곳이 있었는데, 그 중에서 이노베이션 아카데미를 선택한 것이 너무나도 옳은 선택이었습니다. 다른 곳에 인턴으로 들어가서 이 정도로 배워서 나올 수 있을까요? 항상 곁에서 인턴들에게 하나라도 더 가르쳐 주기 위해 항상 고생하셨던 이호준 멘토님과 김수보 멘토님께 너무나도 감사드립니다. 인턴 끝나고도 항상 연락 드리도록 하겠습니다!

그리고 이 글을 작성하는게 여간 쉬운 일이 아니었지만, 다 쓰고 나니 지금까지 내가 경험했던 것들을 복습하는 효과가 있는 것 같습니다. 최종 발표가 있던 날, 이민석 학장님께서 ‘지식은 경험으로부터 얻어지는 것이 아니라, 경험을 정리함으로써 얻어지는 것이다.’ 라는 말씀을 해주셨는데 지금에서야 그 말씀을 이해할 수 있었습니다. 앞으로도 소중한 경험들을 기록하여 제 것으로 만드는 작업을 습관화하도록 하겠습니다.

함께 고생해주신 인턴분들 정말 고생 많았고, 인턴인테도 불구하고 가족처럼 친근하게 대해주신 이노베이션 관계자 분들 모두 감사합니다.