이 글에서는 첫 프로젝트 'DANDI' 의 백엔드를 맡으며 기획부터 배포까지 과정에 대해 적어 보려 합니다.

프로젝트 소개


그림3.png

저희 팀에서 만든 프로젝트 'DANDI' 는 학생들이 일정을 조금 더 쉽게 관리하고 공유 할 수 있도록 한 서비스입니다.

📝 기획

초,중,고 학생들이 학사일정을 포함한 각 그룹의 일정을 관리하기 위하여 자신의 학교에 맞는 학사일정을 포함한 자신이 가입한 채널의 일정을 공유 할 수 있도록 기획하였습니다.

웹, 안드로이드, 윈도우 플랫폼을 지원 하고자 하였고 Neis API를 이용하여 학교 관련 정보를 받아왔습니다.

⚡기능

1. 채널 개설 및 관리

  • 학교 내에서 채널을 개설할 수 있습니다.
  • 채널 가입신청한 회원들을 승인/거절 하거나 가입한 회원들을 관리 할 수 있습니다.

2. 일정 관리

  • 자신이 가입된 채널의 일정을 추가, 수정, 삭제등 관리 할 수 있습니다.
  • 공유 캘린더의 목적에 맞게 채널 가입유저라면 누구나 관리 할 수 있습니다.

3. 학사 일정

  • 자신의 학교에 맞는 학교의 일정을 조회 할 수 있습니다.

🔨 개발기술

  • Express.js

  • MySQL

  • AWS

👀 느낀점

1. RESTful API
REST API 에 대한 이해가 부족한 상태에서 프로젝트를 진행하여 RESTful 아키텍처에 맞지 않게 설계하였습니다.

기존

GET

 /channel/info?channel_id={channel_id}

POST

 /channel/create

개선

GET

 /channel/{channel_idx}

POST

 /channel

기존의 하나의 URI로 메소드를 달리 하여 제공 가능한 API를 다른 URI로 나누어 제공한 점이 잘못된 것 같습니다.

2. DB설계
처음 DB를 설계할 때 전체적으로 너무 큰 그림만을 봐 세세한 부분까지 생각하지 못했습니다. 또한 DB속성 이름작성을 camelCase와 snake_case을뒤죽박죽으로 사용하였다. 그 결과 프로젝트 중간쯤 DB속성 이름을 모두 같은 방식으로 바꾸어야 했습니다. 또한 미처 생각지도 못한 속성을 추가해야 되는 일도 생기게 되었습니다.

3. 상태 코드
HTTP 상태 코드를 보내주기 애매할 경우들이 많았다. 예를 들어 아이디 중복과 같은 처리는 400을 보내주어야 되는지 409를 보내주어야 되는지, JWT관련 오류는 어떤 status code를 보내주어야 하는지 정하는 것이 어려웠습니다. 이런 애매한 상황들 때문에 객체 없음과 컨텐츠 없음의 차이를 인지하지 못하여 없음을 모두 404를 보내었습니다. 이 부분도 이후에 컨텐츠 없음을 204로 변경하게 되었습니다.

4. 클라이언트와의 조율
가장 힘들었던 점이 이부분 이었습니다. 상태코드 또한 이 문제의 한 범주라고 볼 수 있었습니다. 애초에 기능 명세를 하는 시점이 방학 기간과 겹쳐 애매했기 때문에 제대로된 기능명세를 받을 수 없었고 이로 인해 기능을 하나 하나 물어가면서 API를 설계하였습니다. 또한 중간중간 바뀌는 API정보 를 제대로 전달하지 못한 적도 많았습니다.

🎉 결론

이번 프로젝트를 진행하며 백엔드 포지션에서 느낀 점에 대해 간단히 작성해 보았습니다. 이번을 계기로 아직 많이 부족하다는 것을 다시한번 느끼게 되었고 어떤것을 더 배우야 하는지 알게 되었습니다.

긴글 읽어주셔서 감사합니다