결과
우수상 탔다!!!! ❤❤
짧은 시간이었지만 진행 과정을 회고해보고자 한다.
참가 계기
아... 재밌는거 개발하고 싶다...
생각을 하던 찰나, 친구에게 GDSC 해커톤에 백엔드로 같이 팀을 이뤄 나가보자는 연락이 왔다.
재밌을 것 같았지만, 팀장은 반드시 GDSC 회원이어야 한다는 제한이 있었다.
그래서 급하게 GDSC 두명을 구했는데, 웬걸!
딱 디자인 한명, FE 한명이 새로 들어와줘서 포지션 구성이 딱 맞게 되었다.
다들 빠이팅 넘치는 팀원들이라 팀명도 '가보자고' 가 되었다..
주제도 하루 안에 일사천리로 정했겠다, 꼭 상 타서 가보자고~~!!!
해커톤 전까지는..
해커톤 때는 정말 개발에만 집중할 수 있도록, 최대한 설계를 많이 해두려 했다.
작년까지만 해도 어떻게든 코드 하나라도 더 짜두려고 했을거 같은데, 그게 오히려 비효율적이라는걸 이제는 알고 있다.
- 주제의 근거 정리
- 기능 flow 정의
- 기능 구현 가능성 검증
- 최소/중간/최대 구현치 정의
- UI/UX 디자인
- API 문서화
- 데이터베이스 구조
- FE, BE 기술스택 확립
- 서버 환경 확립
- 협업 환경 구성
Git전략 수립- 팀원 별 태스크 확립 및 우선순위 할당
등등...
대부분의 결정 사항은 협업 환경에 간단하게라도 문서화 했다.
물론 위 사항들을 100% 완벽하게 설계하고 개발만 한다면 정말 좋겠지만, 모든 부분에서 중간중간 변경사항이 있었다. 유연하게 대처할 수 있도록 discord, 단톡방 등을 통해 서로 변경사항을 빠르게 공유했다.
사전 설계 엿보기
주제에 대한 근거
- 개발이 급한 대회에서 뭐 이런거까지 하나 싶을 수 있는데..
- 개인적으로, 왜 개발해야 하는지를 모르면 개발이 잘 안 된다.
- 수학 공식 무식하게 외우라고 하면, 계속 왜냐면서 잘 못 외우는 애들 있었지 않나 ㅎㅎ (내가 그렇다...)
- 추후 발표자료에서 주제 소개 란에 반영되었다.
단계별 구현치 정의
- 못해도 최소 구현까지는 개발하자는 주의였다.
- 중간 구현까지 한다면, 조금은 높은 상도 기대할 수 있지 않을까? 싶었다.
- 최대 구현은 정말 '가능하다면'이다.
- 해커톤 후 발표에서 심사위원분께 주제 확장성에 대한 질문이 들어왔는데, 그때 최대 구현으로 구상한 내용을 술술 말씀드릴 수 있었다.
기능 flow
- 그룹마다 매겨진 번호는 우선순위다.
- 이렇게 간단하게나마, 서로 명확히 상상할 수 있을 정도로만 기능을 정리했다.
Swagger를 써보다!
그 동안 Swagger가 API 문서화 툴인줄만 알았지, 써본 적은 없었다.
이에 능숙한 팀원 덕분에 이번에 접해볼 수 있게 되었다.
결론적으로 대만족이다! 💕
API 문서화를 빠르게 할 수 있을 뿐만 아니라,
단순 Notion이나 word 문서로 작성할 때보다 작성 실수도 줄어든다.
(API 문서의 작은 실수 하나가 프론트의 엄청난 코드 수정을 불러온다..)
API 문서화의 중요성을 인지하지 못했을 때, 프로젝트 내내 정말 주먹구구로 프론트와 소통했던 프로젝트도 해봤다. 그와 비교하면 훨씬 편하게 진행했다...
역시 아무리 급해도, 문서화를 하는게 대부분의 경우에 더 효율적이라는걸 상기하게 되었다.
Docker로 데이터베이스를!?
데이터베이스를 도커라이징하여 관리하는 것에 대해 논란이 조금 있는 것으로 안다.
어차피 정말 극소수의 경우 제외하고는, 데이터들 자체는 볼륨에 관리할거다. 그렇지 않으면 데이터베이스 컨테이너가 종료되는 순간, 시작 이후로 쌓인 데이터는 모두 삭제될 것이기 때문이다. 운영 환경이라면 정말 끔찍한 일이다...
그렇다면 DBMS 자체, 혹은 DDL 정도만 포함하여 이미징을 할텐데, 고작 그 정도로 굳이 컨테이너화를 해야 하느냐는 의견도 봤던 기억이 있다.
그러나 우리는 도커로 데이터베이스를 관리했다. 그 이유는
- 팀원 간의 서로 다른 개발 환경으로 인한 디버깅 과정을 최대한 없애고 싶었다.
적어도 이 점에서는, 도커의 장점은 명확하다고 생각한다.
DBMS도 버전이나 환경변수 설정 등 서로 미세한 설정값이 다를 수 있다. 이로 인한 문제가 생길 시 디버깅에 얼마나 많은 시간이 걸리겠는가.
스키마 정의 또한 마찬가지다.
그러나 도커를 통한 데이터베이스라면, 모든 게 똑같은 환경일 수 밖에 없다!
회고
정말 급하게 짜여진 팀인데도 너무 좋은 결과를 얻었다!
우리가 정말 잘했던 점을 정리하자면,
- 주제가 해커톤에서 제시한
Climate Action을 해결하는 합리적인 근거를 가지고 있고, - 설계에 들이는 시간을 아까워 하지 않았으며,
- 팀원들 간 서로 이슈 사항을 빠르게 공유했다.
- 아니 그냥 팀원들이 너무 열심히 해줬다..!! 😀
개인적으로 하나 아쉬운 점이 있다면,
- 기능에 활용 가능한 외부 API가 존재한다는 것에서, 기능 구현이 가능하다고 속단해버린 적이 있다.
- 막상 그 API를 쓸 때 입출력 값을 보니, 우리가 원하는 동작을 하지 못했다.
- 좀 더 자세히 파악하고 전달했다면 API를 찾는 시간을 단축할 수 있었을텐데.. 반성하게 된다.
