🦁 멋쟁이사자처럼 10기 해커톤

orange 프로젝트는 멋사 10기 해커톤에서 진행한 프로젝트이다. 팀은 기획/디자인(1), 프론트엔드(2), 백엔드 총 5명으로 이루어졌다.

팀빌딩

우리 학교의 경우는 기획/디자인 분들이 해커톤에서 진행할 아이디어를 발표하고 개발자들이 참여하고 싶은 아이디어에 참여하는 방식으로 팀을 구성했다. 나는 퍼스널 브랜딩이라는 주제의 프로젝트에 참여했다.

프로젝트 소개 및 설명 🍊

0'range는 간단하게 '자신의 가치를 브랜드화 하는 퍼스널 브랜딩 서비스'이다.
서비스 이름의 자세한 설명은 아래와 같다.
발표자료

'0'과 'Range'를 묶은 단어로, '0'이 보이지 않는 것을 나타내는 숫자임에 기반한다. 여기서 보이지 않던 것은 우리들의 '상념'이라고 정의한다. 'Range'는 '범위, 대, 다양성'을 뜻하는 단어이다. 따라서 0'Range, 오렌지는 사람들의 상념을 가시화하여 드러냄으로써 그범위와 다양성을 토대로 퍼스널 브랜딩을 하는 공간을 의미한다.

퍼스널 브랜딩?

나도 이번에 처음들은 단어였다. 그래서 더 흥미가 갔었던 것 같다.

자신을 브랜드화하여 특정 분야에 대해서 먼저 자신을 떠올릴 수 있도록 만드는 과정을 말한다. 특정 분야에서 차별화되는 나만의 가치를 높여서 인정받게끔 하는 과정을 말한다.

역할

나는 백엔드 개발자로서 이 프로젝트에 참여했다.

멋사 중앙에서 프론트는 React, 백엔드는 Django 교육 VOD 자료를 제공해준다. 그래서 해커톤 참여자 대부분은 위 기술 스택을 사용한다.

하지만 그냥 일반적인 Web Full Stack Framework로서 Django로는 React와 협업할 수가 없다. 프론트와 분리되어 협업하기 위에서 백엔드는 REST API를 만들 필요가 있다.

공부

Django에서 REST API를 만들기 위해서는 DRF(Django REST Framework)를 사용해야 한다. 하지만 멋사 중앙에서는 이에 관한 교육 자료를 제공해 주지 않았다.

그래서 DRF에 관한 공부할 자료를 찾다가 아래 책을 발견했다. 그때 당시에는 출판된지 2달 정도 밖에 되지 않은 따끈한 책이었다. 그리고 DRF에 관한 책은 이게 거의 유일했다. (책 내용도 만족)

https://www.django-rest-framework.org/ > 물론 공식 문서도 참고했다.

공유

나는 멋사 (백엔드 트랙)운영진이었고 아기사자(동아리원)들도 프론트와 협업을 위해 DRF에 대한 공부가 필요했다.

그래서 내가 아기사자분들에게 REST API의 개념 및 필요성과 DRF의 간략한 개념 그리고 공부 자료를 소개하는 세션(발표)를 진행했다. 나도 관련 개념들을 정리할 수 있어 좋은 기회였다.

발표자료

개발

멋사 해커톤은 어느정도 미리 개발을 해오는 특징이 있다. 그래서 해커톤 당일에는 자신들이 만든 프로젝트를 홍보하거나 마무리하지 못한 프로젝트를 마무리 한다.

그래서 개발에는 약 1.5달 정도 소요된 것 같다.

기능

기획한 서비스의 기능은 아래와 같다. 대부분 게시판 CRUD를 응용하면 간단하게 구현할 수 있는 기능들이었다.

• 회원가입, 로그인, 로그아웃
• 프로필 정보 보기, 편집
• 팔로우, 언팔로우, 팔로워&팔로잉 보기
• 내부 페르소나(value, weakness, strength, likes) CRUD
• 외부 페르소나(solve, career, literacy, language, mbti) CRUD
• 활동 추천(프리즘) 및 CRUD
• 태그 CRUD

설계

디자인

기획/디자이너분이 Figma로 디자인을 해주셨다 -> 보러가기

물론 개발자들과도 회의를 하면서 구현 가능성, 필요성 등을 따지며 같이 수정해 갔다.

전체 시스템 구조

전체 구조는 아래와 같다. 백엔드는 DRF로 API를 만들고 프론트는 React로 API를 사용해 화면을 구성한다.

데이터베이스

ER-Diagram 보러가기

당연히 무작정 개발을 시작하는것 보다 테이블을 설계하고 시작하는게 좋을 것 같아 ER-Diagram을 작성했다. 이때 처음으로 erdcloud라는 것을 알게 됐고 사용했다. (MySQL 사용)

배포

API 서버

이번 해커톤 후원사인 클라우드타입 에서 서버를 제공해 줘서 API 서버를 클라우드타입에 배포했다.

그리고 다른분들도 배포에 있어 어려움이 있을것 같아 아래와 같이 배포하는 방법을 포스팅 했었다.
Cloudtype에 Django drf RESTfull API 배포하기
Freenom 무료 도메인 생성 및 CloudFlare 등록, CloudType에 도메인 연결

클라우드타입은 컨테이너 기반의 클라우드서비스로서 복잡한 서버인프라 관리를 간편하게 할 수 있는 PaaS 클라우드를 제공한다. 배포시 필요한 여러 세팅과 준비를 자동화 해서 아주 간편하게 서비스를 배포할 수 있다.(굿)

DB 서버

데이터베이스는 AWS RDS에 배포했다. 처음 사용해 보는 것이었는데 여러 튜토리얼을 따라 하니 어렵지 않게 할 수 있었다.

API 문서

프론트와 협업을 위해서는 API 문서를 작성해야 한다. Swagger를 사용하면 간편하게 문서를 만들수 있었지만, 왠지 직접 작성해 보고 싶은 욕심(?)이 생겨 노션에 작성하게 됐다.

API 문서(배포 중단)

API 테스트

API를 만들었으면 요청했을 때 어떤 값을 반환 해주는지 확인할 필요가 있다. 이를 위해 Insomnia를 사용했다.(Postman이라는 것도 있다)

돌아보며

배웠던점

API에 대한 이해

가장 좋았던 것은 REST API에 대해 이해한 것이다. 이전에는 Kakao API, OpenAPI와 같이 여러 공개 API들이 있고 이것들을 이용하면 편리한 서비스를 만들 수 있다는 걸 익히 들어왔다. 하지만 어떻게 동작하고 사용하는지 그리고 왜 필요한지에 대해 정확히 이해하지 못했었다.

이번 기회에 REST API를 직접 설계하고 만들어 봄으로서 많은 것들을 이해할 수 있었다. (하지만 분명 아직 모르는 게 많을 것이다. 공부하자!)

Git flow 전략

기존에도 git을 사용하기는 했지만 그냥 main 브랜치에 commit하는 정도였다. 그동안 1인 개발이어서 문제가 없었지만 협업에서는 분업과 코드 병합 과정에서 문제가 생긴다.

다른 동아리원을 통해 git flow를 알게 되어 한 번 적용 시켜 보기로 했다. 물론 아래 이미지와 같이 세부적으로 사용하지는 않았다.

크게 아래와 같이 브랜치를 나누어 사용했다. feature 브랜치에서 기능을 개발하고 문제가 없다면 develop 브랜치에 merge하는 방식이었다.

• main
• develop(default)
• feature1
• feature2

현업에서도 사용된다 하니 앞으로 더 익힐 필요가 있다고 생각한다.

Secret Key 관리

SECRET_KEY

A secret key for a particular Django installation. This is used to provide cryptographic signing, and should be set to a unique, unpredictable value.

Github에 Django 프로젝트를 Public으로 올리니 보안 관련 메일이 왔었다. 이때 처음으로 여러 비밀키 관리의 중요성을 깨달았다. 그리고 이 문제를 해결하고 아래와 같이 기록을 해놨다.
Django secret key 재생성 및 분리

더불어 AWS RDS 데이터베이스 연결에 관련한 정보들 또한 분리하여 적용 시켰다.

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.mysql',
        'NAME': get_secret("DJANGO_DB_NAME"),
        'USER': get_secret("DJANGO_DB_USERNAME"),
        'PASSWORD': get_secret("DJANGO_DB_PASSWORD"),
        'HOST': get_secret("DJANGO_DB_HOST"),
        'PORT': get_secret("DJANGO_DB_PORT"),
        'OPTIONS':{
            'init_command' : "SET sql_mode='STRICT_TRANS_TABLES'"
        }
    }
}

아쉬웠던점

프론트와 연결

이번에 내가 만든 API를 프론트와 연결해 완성된 결과물을 보고 싶었지만 그러지 못했다. 😢 다들 이번에 React를 처음 공부하면서 프론트 작업을 진행했다. 그러다 보니 공부 시간이 길어져서 해커톤이 끝날 때까지 완성하지를 못했다.

내가 만든 API가 잘 동작하는지 확인을 못해 아쉬웠지만(물론 백엔드에서 테스트는 했다) 내가 부족한 점을 알 수 있었다. 이를 통해 느낀 것은 백엔드 개발을 하더라도 프론트에 대한 이해도 필요하다는 것이다. 백엔드는 배포까지 마무리되었는데 프론트를 도와주고 싶어도 React 관력 지식이 없다 보니 도와줄 수가 없어 아쉬웠다.

해커톤이 끝나고..

해커톤이 끝나고.. 학기도 끝나고.. 팀원들에게 "프로젝트 마무리하자!"라고 하고 싶었지만 각자 서로 다른 길에서 바쁘게 살고 있어 그러지 못했다. 그래서 0'range 프로젝트는 이렇게 마무리됐다.

마무리

아쉬웠던 것도 있었지만 정말 배운 게 많았던 프로젝트였다. 앞으로 개발하는 데 있어 이 경험은 매우 유용할 것이다. 배우고 아쉬웠던 점을 바탕으로 앞으로 더욱더 재밌는 프로젝트를 이어 나갈 것이다!!

Project Github repository