졸업작품 팀 프로젝트, Homes의 4주차까지

첫 졸업작품에 대한 이야기를 적어보려 한다. 끝나고 한번에 적을까 했는데, 소중한 기억들이 사라질까 싶어 생각이 날 때 마다 회고를 써볼까 한다. 프로젝트는 올해 12월까지 진행하고, 지금 4분의 1정도 왔다.

다르게 살아온 4명과 프로젝트를 한다는 것

우리 학교는 보통 4학년 1학기, 2학기에 캡스톤 디자인(졸업작품) 과목이 있다. 나는 3학년 2학기이지만 마지막 학기에는 실무에서 일하고 싶어서 미리 듣기로 했다.

2명과 협업은 해봤지만 4명과 한 학기동안 한 목표를 가지고 프로젝트를 하는 것은 처음이다. 나와 같은 16학번 3명과 15학번 1명으로 뭉쳤고, 당연히 각자가 가진 개발 지식이나 경험이 다르다.

팀 이름은 팀원들이 각각 서울, 강원도 홍천, 대구, 포항에서 온 꼭짓점을 이으면 사각형이 되고, 네모난 세상을 둥글게 바꾸자는 의미에서 “네모난 형제들”로 지었다.

역할 분담하기

우리는 침팬지에 뒤쳐질 수는 없었다. 각자 할 수 있는 위치에서 적절한 역할 분담이 필요했다.

우선 팀원들의 개발 지식을 간략하게 소개하자면,

나: 프론트엔드, 벡엔드, 서버 인프라에 대한 프로젝트 경력이 있음
팀원 A: 웹 공부를 시작한지 얼마 되지 않음
팀원 B: 생*코딩에서 노드 클론 코딩 경험, 프론트, 서버에 대한 지식은 전무
팀원 C: 웹에 대한 지식 전무, SQLD 공부로 데이터베이스나 SQL문은 짤 수 있음

모두가 참여할 수 있는 역할 분담의 방향을 잡다가, 하이브리드 앱으로 결정했다. 웹은 3명이 어떻게 하다보면 할 수 있겠다 싶었다. 나는 프로젝트 총괄, 팀원 A는 프론트엔드, 팀원 B는 벡엔드, 데이터베이스는 팀원 C에게 맡기면 될 것 같았다. 팀 리더는 하이브리드 앱을 만들어 봤고 장기간의 프로젝트에 자신이 있는 내가 하기로 했다.

프로젝트 구상하기

이제 뭘 만들까 고민했다. 구체적인 목표만 있다면 어떻게든 구현하는 것은 문제가 되지 않다고 지금까지 생각해왔기에 각자가 생각해 본 아이디어를 제시했다. “오 이거 괜찮다”고 생각한 아이디어는 대부분 시장에 나와 있다.

내 주변에서 느낄 수 있는 불편함이 뭐가 있을까 생각하다가 세 들어서 사는 나같은 대학생들이 평소에 느끼는 불편함이 떠올랐다. 거의 대학가의 모든 주택이 그런데, 유지보수가 엉망이다. 모두가 공감했고 어떻게 해소할 수 있을까 고민하다가 지금 진행하는 프로젝트 Homes가 탄생했다.

애자일 방법론

구체적인 목표를 정해서 단계별로 하기 보다는 프로젝트의 작은 요소들을 하나하나 모아서 트러블 슈팅하기 위해 애자일 방법론을 추구하기로 했다. 전반적인 프로젝트 목표는 정해져 있지만 처음 생각한 아이디어이므로 중간에 끼워넣거나 빼는 기능들이 많을 것이라고 생각했다.

협업 환경 만들기

절대 카톡같은 메신저로 협업하는 어리석은 짓은 하지 않기로 했다. 저번 외주를 하면서 느낀 것 중 가장 큰 것이 버전 관리였기 때문이다. 나중에 톡에서 코드를 보면 “이게 뭐더라”고 할 것이 분명하다. 나름 체계적인 협업 환경을 만들려고 노력했다.

그래서 Github를 코드 저장과 버전 관리에, Notion을 공지사항, 전파사항, 회의 내용 작성에, Google Docs을 발표 문서, PPT 작성에 사용하기로 했다. 깃허브에 익숙하지 않은 사람이 많았고, 노션은 나만 사용해봐서 팀원들에게 내가 아는 선에서 사용법과 기능을 알려주었다.

우여곡절 끝에 협업 환경이 갖춰졌다.

기술 스택 정하기

하이브리드 앱은 기본적으로 웹을 기반으로 만들어지기 때문에 벡엔드와 서버 인프라만 구상하면 된다. 프론트엔드는 React, Vue같은 프레임워크 없이 Vanilla Javascript로만 구현하기로 했다.

백엔드는 나와 팀원 B가 사용해본 Node.js를 쓰기로 했다. 자바스크립트 기반이므로 프론트엔드 담당인 팀원 A도 나중에 공부하다가 합류할 수도 있겠다 싶었다. 서버는 학교에서 NHN Toast 인스턴스를 신청하면 대여해주었고, 마침 나는 학교에서 Toast 서버 스터디를 마쳤기에 AWS 프리티어 인스턴스를 고민하던 나로서는 다행이었다. 모든 서비스를 Docker로 서비스하기로 했다.

어플리케이션으로 매핑하는 프레임워크는 React Native를 쓰기로 했다. 저번 외주에서와 마찬가지로 React Native와 Expo 툴을 사용하면 웹 앱 만들기가 정말 수월하고 테스트도 쉽다. 어플리케이션에서 푸시 알림 기능은 Firebase Push를 사용하기로 했다.

배포(테스트) 자동화하기

로컬 환경과 실제 배포된 환경은 분명히 다르다. 어플리케이션으로 매핑하는 것은 나중에 하더라도 그 기반이 되는 웹은 안드로이드던 iOS던 완벽에 가까워야 한다. 터미널에서 깃 클론하고, 도커 이미지 만들고, 컨테이너 연결하고 실행하고 이 모든 명령어들을 테스트할 때 마다 타이핑하다가는 어차피 올 터널 증후군이 더 일찍 올 수도 있다.

이전에도 사용한 배포 자동화 쉘 스크립트를 좀 더 체계적으로 변형하여 사용하기로 했다. 이전 포스트에 관련 내용을 포스팅했다. 이제 개발하고 서버에 배포해서 테스트하고 싶으면 터미널에 ./get_git.sh와 ./build_n_run.sh만 치면 된다.

이제 팀원들은 본격적으로 코드, 데이터베이스 작성에만 집중할 수 있다.

변수 이름 짓기부터 다른 우리

개발자는 많은 난관에 봉착하는데, 그 중 가장 심각한 난관이 “변수 네이밍”이다. 협업에서 변수 네이밍은 절대적으로 통일되어야 한다. 내 코드를 남이 봐도 이해할 수 있어야 하기 때문이다.

이름은 길어도 좋다

우리는 크게 건물주(host), 관리인(manager), 세입자(tenant) 3가지 범주로 나누어 코드를 작성하고 있는데, 한 팀원이 manager를 mgr로, management를 mgmt로 네이밍했다. 변수 작성 방법을 통일하자고 얘기한 찰나에 host_aden.html 파일을 보고 이게 대체 무슨 파일인가 싶어서 물어봤는데 건물주가 자신의 건물을 보는 상세 페이지라고 한다. 그래서 aden이 뭔지 물었더니 구글에 기능 이름을 검색해서 줄인 이름인데 까먹었다고 한다. 앞으로는 변수나 파일 이름을 길게 해도 좋으니 mgr_mgmt 보다는 manager_management로 작성하자고 모두에게 알렸다.

camelCase, snake_case

사실 카멜 케이스던 스네이크 케이스던 어떤 방법을 사용해도 좋지만 적어도 통일은 필요했다. 이게 혼용되면 가독성에서나 코드 리뷰에서나 최악의 코드가 만들어질 수 있다. 팀원 C의 Database 테이블을 생성하는 SQL을 보고, 이 경우도 강조해야겠다 싶어서 다시 모두에게 공지했다. 두 번의 실수는 없기를 바랄 뿐이었다.

var는 쓰지마

자바스크립트에서 정말 임시적으로 사용할 것이 아니라면 var로 변수를 선언할 일은 희박하다. 90%의 변수는 const를 써도 되고, 굳이 바뀔 변수라면 let을 사용하면 된다. 같은 이름으로 변수를 재할당하는 실수를 방지하기 위해 팀원들에게 var를 쓸 일은 최대한 줄여달라고 당부했다.

첫번째 회고를 마치며,

4주차까지 프로젝트가 진행되고 있고 전반적인 협업 개발 환경에서 각자의 임무에 어느정도 적응하고 나름 멋진 협업을 하고 있다. 대학교 졸업 작품을 뭐 이렇게까지 하냐는 말도 들었는데, 졸업 작품이라서 더 체계적이고 정확한 방법을 지향하는 것이다. 4년동안 쌓아온 경험을 교수님의 지도 아래 마음껏 표현할 수 있는 중요한 기회를 주먹구구식으로 하기는 싫었다. 그래도 깐깐한 리더의 말에 동감하고 노력해주는 팀원들에게 매주 얘기하지만, 정말 고마울 뿐이다. 최고의 팀 작품이 탄생할 것이라고 믿는다.