[해커톤] CMC 2nd 해커톤: 서버 개발자 대상 입상후기

오늘은 지난 주말에 참가했던 CMC 해커톤에 대한 회고록을 작성하겠다.

해커톤은 20살의 첫 해커톤이자, 새로운 시도이기 때문에, 이 순간을 더욱 기억하고 싶고, 소중한 해커톤을 참가했던 느낌을 잊지않기 위해서 해당 글을 포스팅한다 ㅎㅎ

 

해커톤 회고는 해커톤 프로젝트를 진행했던 순서대로

프로젝트 기획, 설계부터 개발 그리고 배포까지 기록하도록 하겠다.

---

우리 팀의 해커톤 개발 키워드는 "멀티 페르소나"로 정하고 기획을 시작했다.

그래서 해커톤에서 완성한 개발 프로젝트는

"멀티 페르소나를 발전시키도록 돕는 기록형 안드로이드 앱 서비스"이다.

 

앱 서비스에 대한 설명 - 프로젝트 회고를 완료하고 구체화할 예정

1. 멀티 페르소나를 발전시키기 위해 자신의 자아마다 글을 기록할 수 있도록 기능을 제공했다.

2. 자신의 페르소나별 작성된 글을 시각적으로 볼 수 있게, 캘린더에 기록, 글 정렬 기능을 제공했다.

 

 

---

온앤오프 앱 서비스 - 기획

이번 해커톤에서 나는 서버 개발자로 node.js로 참가했다.
그래서 처음에는 team 4에 배정받았지만... team 1으로 재배정 받았다 ㅋㅋ..

모든 팀내의 서버 개발자에서 node.js 개발자는 1명씩 밖에 없고, Spring Boot는 3~4명씩 있어서..

node.js 개발자로 참가한 나는, 팀 재조정 과정을 거치게 되었다.

이번계기로, node.js 개발에 대한 수요가 적고, Spring Boot 개발에 대한 수요가 많다는 사실을 뼈저리게 느낄 수 있엇다..

 

어쨋든, 나는 프로젝트 기획 중간에 team1 (온앤오프) 팀에 참여하게 되어

프로젝트 아이템이 확립된 상태에서 기획을 참여했었다.

 

우리 팀은 "멀티 페르소나"를 키워드로 잡고,

카테고리 별(독서, 스포츠, 문화 및 예술 등)로 글을 기록할 수 있고, 기록한 카테고리에 따른

자신의 페르소나가 무엇인지 알려주는 앱 서비스로써 기획이 진행되고 있었다.

 

이 순간부터 나는 노드 개발자로 팀에 배정받았고, 함께 프로젝트 기획을 시작했다.

 

 

우리는 핵심 주제인 "멀티 페르소나"이자, 멀티 페르소나를 관리해주는 앱 서비스가 프로젝트 주 목적이다.

그렇기에, 멀티 페르소나를 관리해주고, 발전시켜주는 앱 서비스에 대한 핵심기능들을 나열하기 시작했다.

 

핵심기능을 나열하면서 우리는 프로젝트 방향성에 대해서 PM분께서 항상 잃지 않도록

팀원분들이 생각해낸 기능들이 프로젝트 방향성에 부합하는지를 체크하며

프로젝트 방향성을 잃지 않도록 해주었다.

(프로젝트 기획은 프로젝트 진행하는 팀원 모두 공통의 프로젝트 목적을 지니며 기능들을 선정해야되는 것이 핵심이다. - UMC 동네 프로젝트 중)

 

 

---

온앤오프 - 백엔드 설계

기획 후 우리는 백엔드 설계를 진행했다.

와이어프레임과 기능명세서가 나오지 않았던 터라.. 해커톤이기에, 기획 -> 기능명세서, 와이어프레임 고안을 하면 시간이 생각보다 많이 걸린다.

 

그렇기에, 우리는 기능명세서가 나올 때까지 기초 개발 템플릿을 구성했다.

우리의 개발 템플릿은 node.js로 이전에 프로젝트 해본 적이 있었던 "준" 님의 템플릿을 토대로 개발 템플릿을 확정지었다.

동네 | 템플릿으로 하지 않았던 이유는.. 솔직히 말해서 내 코드를 남에게 보여주고 싶지 않은 나만 소장하고 싶다는 생각이 들었기 때문이다..

생각이 짧았고, 성숙하지 않았던 사고였던 것 같다.

이번의 경험을 나의 실수이고, 이를 토대로 앞으로 똑같은 실수를 하지않도록 발전하는 자세를 지녀야겠다고 스스로 생각하게 되었다.
"시야를 넓히며, 그 순간에만 보지말고, 장기적으로 세상을 바라보자"

 

 

Github Organization 구축 & 개발 템플릿 Push

우리는 백엔드 개발 템플릿을 서버 개발자 팀원 한분의 개발 템플릿으로 확정짓고

개발을 시작했다.

 

확정을 짓고나서, 개발템플릿에서 해커톤 개발프로젝트에 필요한 폴더, 파일을 정돈하는 시간을 가졌다.

프로젝트 개발할 때 필요한 파일만을 나두어야 헷갈리지가 않음 ㅎㅎ..

 

아래는 우리가 해커톤에서 확정짓고 개발한 템플릿이다.

src 폴더에는 API를 개발할 수 있는 공간으로, 백엔드 메인 작업 공간이었다.

 

 

아키텍처 (Controller, Service, Dao, Router) 로 폴더를 나누고
하위 파일로 핵심기능별로 파일을 구성해두었다.

동네에서 구성한 템플릿과 다른 구성체계였지만, 막상 돌이켜 생각해보니깐
똑같은 구성임을 대회가 끝나고 깨달았다..

 

팀원 한분께서 개발템플릿을 해커톤 프로젝트에 따른 파일구성을 해주시고, Github Organization에
코드를 push 해주셨다.

프로젝트를 하기 전에 Pre-setting을 하니깐, 개발을 수월하게 할 수 있어서 좋았다.
핵심기능에 따른 작업공간인 개발파일을 생성해두고,
그에 따른 라우팅까지 해두니
작업하는 내내 헷갈리지 않고 체계적으로 개발을 진행할 수 있었다.

 

 

RDS 구축

기능 명세서가 나오지 않았던 터라 백엔드 개발 환경 Pre-setting을 진행했다.

RDS는 AWS의 RDS를 이용했고,

'이안'님께서 RDS를 구축해서 .env 파일까지 구성했다.

.env 파일은 DB 접근 정보를 지닌 파일로, 해당 파일을 통해 Database와 통신할 수 있도록 한다.

 

 

 

ERD 설계 - 기능명세서 & 와이어프레임의 등장

PM분과 디자인분께서 프로젝트 기획에 대해 완성을 지은 다음,

기능명세서 그리고 와이어프레임까지 제공해주셔서

백엔드 개발의 꽃 erd 설계에 대한 회의를 진행했다.

 

 

# 기능명세서

 

# 와이어프레임

 

 

 

기획이 끝이나고, 제공되어진 와이어프레임과 기능명세서를 토대로 우리는 백엔드 개발에 필요한 erd 설계를 진행했다.

erd 설계방식은

핵심기능별로 Table을 생성해두고, Table 간의 관계를 형성시켰다.

erd 설계는 '이안'님이 메인으로 맡으셨고, 설계방식은 우선 해보면서 조율해가는 방식이었다.

 

erd 설계방법에 대해 요약해보자면, 기능명세서와 와이어프레임을 토대로 기능 구현에 필요한 Table list를 우선적으로 설계했다.
그리고나서, Table간의 관계에서 Mapping Table을 추가해 이상적인 erd를 설계했다.

 

이번 해커톤에서 새로운 erd 설계 방법론을 배울 수 있었다.

처음부터 erd를 완벽하게 Table list부터 Mapping Table까지 생각 후 erd를 설계하는 것이 아닌,

Table list를 생각해낸 후 Table list를 aquery tool에 나열한 뒤

Table 간의 Mapping을 진행했다.

이때, 설계된 Table간의 관계를 보고 Mapping Table이 필요한 경우 (Mapping Table)을 추가하는 식으로 erd 설계를 진행했다.

 

# erd 설계한 방식에 대해 구체적으로 알아보자~!

Mapping Table을 사용한 Table은

Profiles - HashTags

Feeds - HashTags

Feeds - Categories

이다.

 

다음의 Table들은 M 대 N 관계라는 사실을 알 수 있다.

다대다 관계

 

해당 관계를 찾고나서 erd설계를 하는 것이 아닌, 프로젝트에서 필요한 Table을 설계하고,

구성된 Table간의 관계에서 Mapping의 필요성을 확인해줬다. - Mapping Table 없이 쿼리문 호출이 가능지를 확인해줌.

이러한 설계 방법은 새로운 설계 방법론이었고, 기존에 했엇던 모든 관계를 생각하고 erd 설계하는 방식보다
더 빠르게 설계할 수 있음을 깨달았다.
"처음부터 완벽할 필요는 없다." - erd 설계하며 배우는 인생 철학 ㅋㅋ..

 

아래는 온앤오프 백엔드의 erd 설계 완료한 사진이다 ㅎㅎ

ERD 설계한 게 궁금하다면 아래 링크를 타고 보면 된다!

AQueryTool

Password : vekbgn

 

 

 

---

온앤오프 - 백엔드 개발

백엔드 개발환경 템플릿 구성, erd 설계가 끝이나고, 프로젝트에 필요한 API의 List를 나열하기 시작했다.

 

백엔드 개발 목록 - API List UP 구성

API List UP을 구성할 때는 기능명세서와 와이어프레임을 바탕이 되어

필요한 API 리스트를 나열하기 시작했다.

 

우선, 백엔드에서 개발하는 API는 도메인으로 호출되기에,

도메인을 기준으로 API List를 분류를 했다.

 

# 핵심 도메인 선정 - 개발 템플릿 관리

온앤오프 앱서비스는 유저를 기준으로 글쓰기, 페르소나 생성하기, 페르소나 선택하기 가 있으므로,

핵심 도메인을 User로 정했다.

그리고, 온앤오프의 핵심기능이 "글쓰기" 게시물 기록이므로,

Feed 로 두번째 핵심 도메인을 정했다.

다음, 위에처럼 결정한 핵심도메인은 정답이 아니고, 어떻게 해서도 정답이 될 수 없다.
개발을 체계적으로 쉽게 구성하기 위해 백엔드 API 개발 규칙을 정한 것이다.
그렇기에, API List UP을 구성하는 것엔 정답이 없으며, 개발하며 상황에 따른 편한하고 쾌적하게
구성하면 된다 ㅎㅎ - 인생에는 정답이 없듯이, 백엔드 개발에도 정답이 없고 내게 편한대로 규칙을 정하고 개발을 하면된다.

 

# 핵심 도메인 선정완료 후 API List Up 구성

API List Up을 구성해본 경험은 이번을 통해

2번이었다.

그래서, 처음 할 때보다 수월하게 할 수 있었지만, 아직 많이 부족하다고 느꼈다.

하지만, 이번 경험을 통해 API List Up을 구성하는 방법에 대해 새로운 통찰을 할 수 있었다 ㅎㅎ

 

내가 기존에 했었던, API List Up은 모든 앱 뷰를 보고, 이해를 처음부터 끝까지 완료한 뒤

앱에 필요한 API를 나열했었다.

하지만, 이번 경험으로 새로운 방법을 알게 된 것은

처음부터 끝까지 이해를 완료한 뒤 API를 나열하는 게 아니라, 모든 뷰들을 독립적으로 생각하며

각 뷰마다 필요한 API를 나열하는 방식이다.

모든 뷰들을 처음부터 완벽하게 이해하고 API list를 구성하는 건
모든 뷰와 연결되어 있다고 생각이 들어 API list를 생각할 때 막상 어떤 API가 필요한지 생각을 못해 복잡하게 얽히게 된다.
하지만, 독립적으로 생각하게 되면, 해당 뷰에서 어떤 API가 필요한 지 뚜렷하게 보이게 된다.
결국, API List Up을 구성할 때도 처음부터 완벽할 필요없이, API에 살을 붙여가며 만들면 쉽게 구성할 수 있다.

 

 

구성한 API List

 

 

개발 시작 - API 개발

API List UP이 완료된 뒤 본격적인 개발을 시작했다.

하지만, 이번에 해커톤에서 아쉬웠던 점은.. API를 많이 만들지 못했다는 점이다.

내가 완벽주의자 성격이기에, 머릿속으로 API가 돌아간다 라는 생각이 들 때까지 개발을 진행하지 않는게
이번 해커톤에서 발목을 잡았다..

 

# 해커톤 백엔드 개발하며 어려웠던 점.. 그리고 이에 대한 극복

개발하며, 나는 많이 위축이 되었었다..

내가 API를 한 개 만들 때 팀원들은 3~4개씩 만들어 내니깐,

스스로 많이 위축이 되었었다. - 팀원과 나 자신과 비교

스스로 위축이 된 난, 개발 능력이 현저히 떨어졌음을 스스로 느낄 수 있었다..

그래서, 팀원들에게도 말 없이 혼자 끙끙되는 걸 보여주며,

눈치만 보고 혼자의 힘으로 해결하려고 했었다..

해커톤,, 팀 프로젝트인데, 혼자 힘으로 완벽하게 하려니깐, 초래된 딜레마인 듯하다.

 

해커톤 프로젝가 끝나고 이에 대해서 혼자 바람을 쐐보며 생각해본 결과

새로운 통찰을 하였다 ㅎㅎ

 

개발 능력이 떨어진 원인이 팀원과 나자신의 비교를 통해 초래된 결과인데, 자꾸만 나는 팀원과 나를 비교하며 나 자신을 위축시킬까? 라는 생각을 하였고,

결국 위축되지 않고, 궁금한 사항이 있으면, 팀원에게 질문하는 건 민폐가 아니고, 프로젝트를 더 잘 이끌어가는 방향임을
해커톤 프로젝트를 통해 또다시 깨닫게 되었다.

그리고, 팀에서 나와 팀원의 비교를 통해 스스로를 위축시킬 필요도 없다.
팀에서 위축되면 내 능력이 떨어질 뿐아니라, 팀내의 방향성도 잃어버릴 수 있게 되는 (팀에서 의견을 내지 않는)결과를 초래시키기 때문이다.
그렇기에,

팀에서 팀원과 비교하는 행위는 스스로를 위축하게 만들며, 위축된 나 자신은 팀에서 침묵을 하게되고,

팀 프로젝트에서의 침묵은 책임감없는 행위이며, 프로젝트를 앞으로 나가지 못하게 가로막는 행동이다.

 

따라서, 팀에서 팀원과 나 자신과 비교하는 행위는 나를 위축시키니,
비교하는 행위를 하지 않고, 스스로 최상의 개발능력을 유지하며
궁금한 게 있으면, 팀원에게 질문해서 팀 프로젝트가 공통의 방향으로 이어지도록 노력하자 ㅎㅎ
"실수했던 경험을 통해 성장하고 발전한다."

 

# (API를 비롯한 ) 개발에 대한 통찰

이번 해커톤을 통해 개발하면서의 나를 되돌아 볼 수 있는 기회가 되었다 ㅎㅎ

나는 지금까지, 개발을 할 때 머릿속으로 떠올린 개발로직을 생각을 옮기기 편한 코드 방식대로 코드를 작성해왔다.

하지만, 이러한 개발은 일회성 개발로 새로운 개발을 할 때는 또 다른 개발을 해야되었다.

그래서, 매번 개발을 할 때마다 시간도 많이 들고, 개발 비용이 많이들었었다.

 

하지만 이번 해커톤을 통해 나의 개발방법을 돌아볼 수 있는 기회가 되었다.

내가 개발을 하면서, 시간과 개발 비용이 많이드는 이유는

개발에 대한 나만의 개발 규칙을 정하지 않고 "일회성 개발"을 진행했기 때문이다.

 

이는,내가 API를 개발 할 때 별다른 규칙없이

API를 만들어야 되는 것에 대해 어떻게 개발할까에 대해서만 생각하고 코드로 구현했다.

하지만, 이렇게 개발을 하면, API 하나 개발하는데 시간이 너무 많이 든다는 생각이 들었고,

이번 해커톤을 통해 새로운 통찰을 할 수 있었다.

 

해커톤 백엔드 개발이 끝이나고, 나는 백엔드 팀원에게 API 개발할 때 어떻게 하시나요? 라는 간단한 질문을 하였고,

이 질문을 통해 나의 개발 방법에 대한 새로운 통찰을 했다.

 

팀원은 API 개발할 때는 DB 쿼리문을 우선적으로 설계한 뒤, 구현이 완료되면

코드로 구현합니다. 라고 답변을 해주셨다.

이 답을 듣고, 내가 평상시에 개발에 대한 나만의 규칙이 없어서 매번 개발할 때마다

시간, 개발 비용이 많이 들었다는 사실을 깨달았게 되었다.

 

그래서, 이번 해커톤을 통해 개발을 할 때에도 나만의 개발 규칙을 정한 뒤

개발을 시작해서 개발 비용을 줄여야 겠다는 통찰을 했다 ㅎㅎ

 

이번 경험을 토대로 생각해낸, API 개발에 대한 나만의 개발 규칙이다.

DB 쿼리 제작 ->-> Dao 설계 -> Service 설계 -> Controller 설계 -> Router 설계

개발 규칙에는 왕도가 없으며, 상황에 따라 적절한 개발 규칙을 정해서 개발을 하면 된다.
"인생도 답이 없듯이, 개발에도 답이 없다."

 

# API 개발 - 프론트엔드와의 협업

API는 프론트엔드에서 요청해서 사용하기에,
프론트엔드에서 뷰에 노출하기 쉬운형태로 API Response 객체를 만들면 된다.

 

그래서, API를 만들 때 생각해야 될 사항은

해당 뷰에서 프론트가 어떤 데이터를 지닐 수 있는 지를 확인해서

필수적인 (요약된) request 객체를 생각해낸다.

그리고, DB 쿼리문을 설계하고,

Response 객체는 프론트에서 최대한 활용도를 높이도록 인덱스 값은 모두 넣는 것이 좋다는 사실을 알게 되었다.

 

결국, API 개발은 프론트 입장이 되어보아 앱 사용자가 지니고 있을 수 있는

데이터 값을 생각 후 API 개발을 하면,

프론트 입장에서 최적화된 API를 제공할 수 있다 ㅎㅎ

 

Git에 대한 새로운 습득 - git branch -vv & git 으로 체계적인 협업관리하는 법

 

아래 명령으로 git branch에 대한 상세 정보를 조회할 수 있다.

$ git branch -vv

로컬에 생성한 브랜치가 원격 브랜치 중의 어떤 브랜치와 연결되어 있는지에 대한 정보를 확인할 수 있고,

로컬 브랜치가 원격 브랜치와 비교해 commit 상태 & 소스코드 버전상태가 어떻게 되어있는지 체크할 수 있다.

 

git branch -vv 명령을 통해 추가 작업을 이어나갈 때,
최신버전의 소스코드로 로컬환경에 코드가 pull 되어있는 지를 손쉽게 확인할 수 있다 ㅎㅎ
pull 되어있는 정보는 commit message를 통해 분류해낼 수 있다.

 

git으로 체계적인 협업관리하는 법 - 해당 부분은 정확한 사항이 아니므로, git에 대한 추가지식이 쌓아지면 수정하도록 하겠다.

첫번째 Github 소스코드 push 한 뒤 merge를 하고, 첫번째 개발 버전이 탄생했다.

나는, Ethan 브랜치를 생성해 개발을 한 뒤 원격 Ethan 브랜치에 소스코드를 Push했다.

그리고, Github로 가서 develop 브랜치에 소스코드를 merge시켜 개발 버전을 업그레이드 시켰다.

 

그럼, 원격 develop 브랜치는 첫번째 개발이 완료된 상태로
Ethan, Blue, Ayaan, Joon, JB의 소스코드가 업데이트 상태이다.

하지만, 로컬 develop 브랜치는 Ethan 소스코드만 업데이트 된 버전이다.

그럼, 개발을 할 때는 원격 develop 브랜치를 pull 받아 최신버전으로 업데이트 한다.

그리고, 로컬 Ethan 브랜치로 가서, 원격 develop 브랜치를 pull 받아 최신버전으로 업데이트 한 뒤

남은 작업을 진행한다.