GDSC 1st 팀 프로젝트 회고

GDSC KNU에서 진행한 첫 번째 프로젝트인 “네컷앨범”에 대한 회고입니다. 서비스를 목표로 진행한 개발 과정에 대해 소개합니다.

1. 프로젝트 개요

이번 프로젝트는 GDSC KNU에서 2023년 2월부터 5월까지 4개월간 진행한 프로젝트입니다. 해당 프로젝트를 진행하기 이전, GDSC KNU에서는 프론트엔드, 백엔드, 안드로이드, AI로 세션을 나누고 해당 세션 내에서 다시 소규모로 그룹을 지어 본인이 속한 세션에 대해서 2022년 9월부터 2023년 2월까지 스터디를 진행했습니다.

프로젝트에는 두 가지 주요 목표가 있었습니다. 하나는 본인의 세션에 대해서 스터디한 것을 토대로 다른 세션과의 협업을 하는 것에 있었습니다. 둘은 이미 구글 플레이스토어에 출시되어 있는(2023년 5월 30일 기준) "네컷앨범"을 고도화를 통해 서버에 배포하는 것에 있었습니다.

요구 사항

• 사용자 본인이 올린 사진 조회 기능
• 공유된 사진 조회 기능
• 좋아요 기능
• 필터 조회 기능
• 회원가입, 로그인 기능

사용기술스택

안드로이드

• Kotlin
• Retrofit2
• Coroutines
• Glide
• Flow

백엔드

언어

• JDK17

프레임 워크

• SpringBoot

DB

• MariaDB

그 외

• EC2
• S3
• data JPA
• JPQL
• Querydsl

2. 시스템 구조

백엔드의 시스템 구조도는 다음과 같이 나타낼 수 있습니다. 본 프로젝트에서 구현하고자 하는 기능은 게시물에 대한 단순 CRUD가 전부이기에 하나의 서버(이하 비즈니스 서버)에 전부 구현했습니다.

사용자의 요청에 따른 비즈니스 로직이 진행되는 순서대로 설명하겠습니다. 사용자는 핸드폰 어플을 통해서 서버에 구현해놓은 REST API를 호출합니다. 서버는 사용자로부터 온 Request에 따라 DB에 데이터를 저장, 조회, 수정, 삭제를 하고 경우에 따라 S3에 이미지를 저장하고 삭제를 합니다.

3. 네컷앨범을 통해 배운점

이번 “네컷앨범”이라는 토이프로젝트를 진행하며 백엔드가 아닌 다른 분야와 협업을 했다는 점, 실제 배포를 위해 프로젝트를 진행했다는 점 덕분에 너무나도 많은 것들을 경험하고 배웠으며 여전히 모르는 것이 산더미이라는 것을 알게 되었습니다.

치밀한 설계

과거 토이프로젝트를 진행할때도 개발을 시작하기전 기획을 하였습니다. 그러나 이전에는 실제 배포를 목적으로 두는 것이 아닌 공모전이나 해커톤을 나가기 위해 기획을 하였습니다. 그렇기에 이전에 기획을 할 때 상세하게 기획을 하지 않고 개발을 진행하며 수정사항이 생길경우 그때 그때 상황에 맞게 수정해나가며 개발을 진행했습니다.

이번 토이프로젝트 “네컷 앨범”의 기획단계에서 역시 기획을 상세하게 진행하지 못하였습니다. 그 결과 API 명세서는 물론 제대로 작성하지 않았으며 어떤 식으로 구현할지 조차 제대로 논의가 되지 않은 상태에서 개발을 착수하였습니다. 그 이후 안드로이드에서 원하는 API스펙과 서버에서 작성한 API 스펙이 서로 달라 결국 다시 개발해야하는 일이 종종 생겼습니다.

같은 일을 여러번 하게 되는 번거로움을 직접 체험한 저는 이후 회의에서 안드로이드에서 원하는 API스펙에 대해서 자세하게 물어보고 또 API스펙을 따로 정리하여 팀원들과 공유하기도 하였습니다.

그러나 이 역시 시행착오가 존재하였습니다. 이에 대한 일례로 특정 API에서 사용자의 ID를 주고 받아야 했었는 상황이 존재했었습니다. 저는 이전 API스펙을 자세하게 명시하지 않았을때의 번거로움을 직접 경험했기에 개발에 착수하기전 미리 API 스펙을 정하고 개발을 하였으며 이후 정상적으로 동작하는 것을 확인하였습니다. 그러나 실제로 클라이언트에서 서버로 요청을 보낼경우 자꾸 에러가 났었습니다. 에러의 원인으로는 클라이언트는 문자열의 형태로 서버에 보내고 서버는 이를 정수형으로 변환하는 과정에서 typemismatchexception 이 발생했었습니다. 그리고 이를 해결하기 위해 DTO와 엔티티를 수정하고 관련 로직을 전부 바꿨어야 했었습니다.

소프트 스킬

본 토이프로젝트는 23년 2월부터 23년 5월까지 약 5개월간 진행한 프로젝트 입니다. 물론 팀원들이 내향적인 성향을 지닌탓도 있겠지만, 프로젝트를 진행하기 위해 모인 첫 만남부터 프로젝트를 마무리하는 최종 발표회까지 서로 서먹서먹한 상태로 시작해 서먹서먹한 상태로 프로젝트를 끝냈습니다. 프로젝트가 종료된 시점에서 생각해보면 설계를 위해 이야기를 하거나 개발 도중 생긴 이슈에 대해서 이야기를 할때 이 서먹서먹한 관계가 자유롭게 의견을 주고 받는데 걸림돌이 되었다고 생각합니다.

CI/CD

저는 이번 프로젝트에서 AWS의 EC2에 인스턴스를 생성하였고 해당 인스턴스 내에 JDK와 DB등을 직접 설치하였습니다. 이번 프로젝트에서 수정사항이 생길때마다 깃에 푸시를 하고 로컬에서 빌드한 이후 직접 서버에 SSH를 통해서 파일을 올리고 과정을 통해서 재배포 하는 과정을 거쳤습니다. 그리고 이러한 과정들은 수정사항이 많으면 많을수록 기계적으로 느껴졌습니다. 향후 프로젝트를 수행할때는 이를 자동화하는 파이프 라인을 구축해보고 싶습니다.

보안

보안에 대해서 전적으로 프론트엔드에서 처리해서 백엔드는 단순히 해당 정보를 주고 받기만 하였습니다. 그렇기에 보안을 미흡하게 처리하였고 이는 프로젝트를 실제로 배포했을 경우 문제가 되었습니다. 그렇기에 향후 프로젝트를 진행할때 스프링 시큐리티를 이용해서 세션 혹은 JWT를 이용해서 보안에 대한 대비를 하고 싶습니다.

예외처리

개발은 항상 원하는 방향대로 흘러가지 않기에 만약의 경우를 생각해 해당 흐름까지 생각하면 코드를 작성해야 합니다. 그러나 스프링에 대한 낮은 숙련도로 인해 에러가 발생시 원인을 직접 찾아가며 해결하고 유추해야 했습니다. 이러한 과정을 반복하니 피로감이 쌓였고 이후에 프로젝트를 진행할때는 에러를 핸들링하는 로직을 추가해서 어디서 오류가 발생했고 또 왜 발생했는지를 보다 명확히 하는 예외 처리를 해야겠다는 생각을 하였습니다.

개발 환경과 배포 환경의 분리

저희는 하나의 DB를 사용하였기에 로컬에서 개발을 하며 사용하였던 데이터들이 배포 하는 DB에도 들어가 있는 상황이 발생했습니다. 이는 초기에는 감당할 수 있는 수준이였으나 시간이 흐름에 따라 겉잡을 수 없을만큼 데이터의 양이 불어났습니다. 그렇기에 향후 프로젝트를 할때에는 DB를 분리해서 개발용과 배포용을 나누어 작업을 해야겠다 생각하였습니다.