Econo Beep (에코노 삡) - 1.0 (Summer Dev Ver) - 개발 회고록

1.  기획

전남대학교 개발동아리, 에코노베이션은 관리부가 다양한 자재들을 보유 및 관리, 대여를 해주고 있다. 22년도부터 관리부원이 되면서 느낀점은 마음대로 사용하는 여타 동아리와 다르게 엑셀을 통해 관리함으로서 최소한의 장치가 있기는 하지만 개선의 여지가 있다는 것이였다.

 

파악한 문제점은 다음과 같다.

• 대여/반납에 관리부의 수작업이 요구됨 (기존 자재 대여/반납 프로세스는 다음과 같다.)
  
  1. 슬랙을 통해 관리부에게 대여/반납을 요청
  2. 관리부가 자재 관리 엑셀에 기록
  3. 자재를 동방에서 대여/반납
• 현재의 상태만 엑셀에 기록하기 때문에 분실 혹은 파손되는 경우 역추적이 불가능
• 자재를 조회하기 위해서는 직접 동방에서 찾거나 다른 부원에게 물어봐야 함

 

우리는 개발 동아리가 아니던가, 디지털화해서 문제점을 스마트하게 해결해보자.

 

 

2.  설계

특징

• 프로젝트 목표

이번 프로젝트에서 핵심은 클린 코드와 테스팅였다. 동아리를 위한 프로젝트이므로, 관리부원이 바뀌더라도 프로젝트가 유지보수 가능해야하기 때문이다. 따라서, 프론트는 클린 코드 작성과 문서화에 신경을 썼고, 백엔드는 클린 코드 작성과 테스트 코드 커버리지, 문서화에 신경썼다. 여러 리팩토링 또한 감수하면서 프로젝트 개발을 시작하였다.

• Econo Auth Universe

같이 에코노 서머데브를 진행한 Tcono 프로젝트(부원들을 위한 기술블로그) 팀과 논의해 본 결과, Tcono와

EconoBeep

을 시작으로 부원들을 대상으로 하는 프로젝트의 경우 공유된 Auth 서비스를 사용해보기로 했다. 당장은 Tcono 팀이 제작하는 임시 Auth 서비스에 의존하면서 개발하고, 차후에 SSO를 통한 Econo Auth Universe 서비스를 개발하여 도입하기로 했다.

 

기술 스택

기획 : Notion

디자인 : Figma

프론트 : React, styled-components, axios

백엔드 : SpringBoot, Gradle, Junit

 

 

3.  어려웠던 점

• Book 테이블과 Equipment 테이블 설계

기자재는 책과 장비 나뉜다. 현물로서는 상당히 다른 두 기자재이지만, 데이터로서 보면 책은 장비에서 몇몇 데이터가 추가된 것 뿐이였다. 객체지향 관점에서 보면 다형성과 상속을 통해 중복을 없애야하지만, RDB 관점은 또 달랐다. 따라서 두 가지 방법으로 나뉘었는데,

1. 기자재라는 하나의 테이블로 통합하되, (책의 여부, 책을 위한 추가적인 데이터)에 대한 컬럼을 추가하여 구분한다.
2. 책과 장비 테이블로 분할한다.

1번은 테이블이 깔끔하지만 책 구분을 위한 컬럼 사용이 스마트해보이지 않았고, 2번은 자재 테이블과 대여/반납 테이블이 종속되므로 중복이 상당했다. 중복이 있더라도 RDB 관점에서는 2번이 적합한 것 같아서 2번을 채용했지만, 큰 문제가 있었다. 이는 4.리팩토링 에서 후술한다.

 

• Swagger의 불완전성

문서화의 수고로움을 덜기위해서 많이들 Swagger을 사용하지만, Swagger의 불완전성은 꽤 크다. Java의 Short와 같이 작은 단위의 숫자 자료구조를 문자형으로 인식한다던가, Controller의 @RequestBody나 @PathVariable와 같은 요구하는 입력을 구별하지 못한다는 점은 Api문서가 있음에도 프론트간의 소통 문제를 일으켰다.

• No Offset 페이징의 일관성

페이징 특유의 성능 문제를 해결하기 위해 No Offset 활용을 도입하였다. 하지만 이 방법은 id를 통해 페이징하기 때문에, id로 정렬되지 않는 다른 기준의 정렬 데이터의 경우에는 이 방법을 사용할 수 없었다. 이로인해 프론트는 두 가지 방법의 페이징 데이터를 준비해야 했다.

• Controller 설계의 어려움

비슷하지만 분리된 Book과 Equipment 테이블로 인해 각각 별도의 요청 생성 + 다양한 데이터 조회 정렬에 해당하는 요청 생성 => 복잡하고 난잡한 Controller가 작성되었다.

 

---