공통 프로젝트 후기 정리

공통 프로젝트 JaNyang(자냥)

• SSAFY 에서의 2학기 1차 프로젝트인 공통 프로젝트가 내일이면 마무리된다.
• 기록을 위해 프로젝트의 시작부터 끝까지 어떤 것을 만들었고 만들면서 어떤 이슈가 있었는지에 대해 이야기해보려고 한다.

우리 프로젝트의 결과물 사진이다.

기획

주제 선정

• 프로젝트의 주제를 정하는 것은 여태까지 3번 정도의 프로젝트를 진행해 보았지만 개인적으로 가장 힘든 부분이라고 생각한다.
• 이것은 비단 나 뿐만이 아니라 같은 팀원들도 비슷했었다. 그래도 다행이었던 것은 어느 정도의 가이드라인이 제공되었다는 것이었다.
  • 가이드라인의 내용은 혹시나 몰라 공개하지 않지만 그래도 어느 정도의 방향성을 잡을 수 있는 부분까지는 제공되었다. 그래서 프로젝트 극초반에는 해당 가이드라인의 내용을 읽으면서 생각해본 것이 많았었다.
• 여러 주제들이 나왔었다. 기억하기로는 약 6개에서 7개 정도가 나왔었는데 몇몇은 재미로 할 만한 것이었지만 기술적으로 깊이가 부족하거나, 정돈되지 않았고 몇몇은 상세하고 왜 이런 기획이 필요한지가 잘 정리되어 있었지만 아쉽게도 법리적으로 문제가 있거나, 사용자가 이것을 필요로 할까? 라는 부분에서 아쉬움이 있었다.
• 그래서 계속 생각하다 기상 알람과 관련된 주제를 해보면 어떨까? 라는 의견이 나왔었고, 컨설턴트님과의 미팅에서도 꽤 좋은 반응이 있었기 때문에 해당 주제로 픽스를 하게 되었다.

명세서 작성

• 주제를 선정했으니 명세서를 작성해야 한다. 우리가 작성해야 할 명세서는 크게 다음과 같았다.
  • 기능 정의서 및 명세서
  • ERD
  • API 스펙 명세서
  • 요구사항 명세서
  • 와이어 프레임 및 목업 프로토타입
• 우리팀의 구성이 FE 2명 BE 4명으로 구성이 되어 있었기에 ERD, API 스펙은 BE 파트에서, 와이어프레임 및 목업 프로토타입은 FE 파트가 담당했었다.
• 나머지 부분은 FE 및 BE가 모두 같이 회의를 진행하면서 만들었었다.
• 나는 이전에 했던 프로젝트들이 모두 기능이 매우 커지면서 마감 시간 내로 맞추지 못한 경험을 했었다. 그래서 개인적으로 이 프로젝트의 크기가 커지는 것을 좀 경계하면서 회의를 참여했었다.
  • 팀원과의 회의에서 이 경험을 말했었고, 우리가 가진 프로그래밍에 투자할 시간은 길어도 3~4 주 정도가 될 것이라고 생각을 했었다. 그래서 가급적이면 가장 최소한도로 기능을 덜어내고 우리 서비스가 동작하는데 반드시 필요한 기능들만 선정하자고 주장했었다.
  • 다행히 컨설턴트님도 비슷한 의견을 이야기하셨었다. 사실 MVP 자체가 서비스가 성립하기 위한 최소한의 기능들을 정리한 것이니까... 그래서 다른 팀원도 공감하면서 수평적으로 기능이 늘어나는 것을 최대한 막을 수 있었던 것 같다.
• 프로젝트 마무리 시점에서 돌아보면 이렇게 필터링 하지 못했다면 아마 마감 시간에 엄청나게 쫓기고 있었지 않았을까 라는 생각이 든다. 바로 어제서야 전체적인 테스트와 디버깅이 끝났기 때문이다.
• 여튼 그래서 필수적인 기능인지를 계속 따져가면서 기획을 진행했고, ERD, API 스펙과 기능, 요구사항 명세서들이 하나 둘 씩 완성되기 시작했다.
  • 이때 많이 참고했던 것이 우리가 만드는 서비스와 꽤 비슷한 앱인 알라미 앱이었다. 알라미 앱을 설치해 사용하고, UI 분석과 기능을 살펴보면서 밴치마킹을 할 수 있었고, 구글 스토어 리뷰를 확인하면서 어떤 문제가 있는지 분석하고 정리해서 요구사항이나 기능에 반영했었다.
  • 개발이 끝난 지금 상황에서 보면 구글 스토어 리뷰에서 혹평했던 부분들 중 기술적인 부분들은 우리도 해결하지 못해서 매우 아쉬웠다.
• 와이어 프레임과 목업의 경우 FE 파트에서 Figma를 사용해서 만들고 있었다. 꽤 전문적이었고 예쁘게 디자인하고 있으셔서 감탄했던 기억이 난다.
  • 와이어 프레임의 경우 목업을 만들기 전에 먼저 수행했는데 BE 파트에서 사용자의 서비스 이용 플로우를 생각해내서 어떻게 흘러가는지 뼈대만 만들어 놓았고, FE 파트에서 이것에다 살을 덧붙여 목업으로 만드는 작업을 진행했었다.
• 이렇게 만들어진 목업은 이후에 내가 UI를 보면서 api를 어떻게 주면 좋을지에 대해 참고할 수 있는 자료가 되어서 꽤 많이, 자주 찾아보면서 개발을 진행했던 것 같다.

기술 스택 선정

• 우리 프로젝트에서 특이한 사항이 있느냐 라고 물어본다면 나는 아마 매우 도전적으로 진행한 것이 특이한 사항이었다 라고 말할 수 있을 정도로 기술 스택 선정 부분에서 도전적인 것들이 많았다.

FE

• 먼저 FE 부분으로 말할 것 같으면 프로젝트 주제 자체가 휴대폰 알람과 관련하여 모바일 어플리케이션으로 만들어야 하는 서비스였기 때문에 모바일 앱 개발 언어를 사용했었어야 했다.
  • 문제는 FE 파트가 JS/TS 을 위시한 웹 개발 쪽만 배웠고, 모바일 관련은 거의 아는 것이 없었다는 것이었다.
  • 그렇다고 Kotilin/Java의 네이티브 안드로이드를 하기에는 러닝 커브가 매우 커서 프로젝트 수행 일정에 차질이 생길 수 있을 것 같다고 생각했었다. 추가적으로 iOS 환경에서는 아에 서비스할 수 없었던 부분도 걸렸다.
• 그래서 나온 대안이 React Native와 Flutter였다. React Native의 경우 러닝 커브가 높고, 라이브러리가 많아 배울 수 만 있다면 매력적인 선택이 될 수 있었다. 하지만 알람과 관련해서 문제가 좀 있었고, 러닝 커브가 높은 것이 발목을 잡아 커트
• Flutter의 경우 Dart 라는 새로운 언어를 배웠어야 했으나 언어를 배우는 것 이외에는 (어디까지나 우리 프로젝트에 필요한 부분에서) 러닝 커브 자체가 어느 정도 낮았고, 성능적인 측면이나 문서화에서 여러모로 이점이 많아 Flutter를 선택하게 되었다.

BE

• 기본적인 API 서버의 경우에는 Spring Boot를 사용하기로 했다. BE 파트의 주 언어가 Java이기도 하고 Java 언어를 사용하는 프레임워크에서 Spring Boot만큼 유연하면서 좋은 프레임워크가 또 없다고 생각했기 때문이다.
• 사실 서버 프레임워크 이외에는 사용했던 라이브러리 말곤 없어서 라이브러리와 연관되는 기술들을 설명하면서 왜 사용했는지를 이야기해보도록 하겠다.
  • Spring Data JPA - JPA를 스프링과 통합해주는 라이브러리이다.
    • 사실 JPA를 쓰는 것에 대해 많은 생각을 했었다. 사실 MyBatis와 같은 ORM을 사용해서 프로젝트를 진행해도 괜찮을 것 같았지만 결국 JPA를 사용하게 되었다.
    • 이유 중 하나는 Java의 객체로 모델링이 가능하다는 이유이다. 객체지향적으로 접근이 가능하고, 유지보수나 리펙토링에서도 유리했다. 특히나 Data JPA를 사용할 시 기본 CRUD가 가능한 인터페이스를 제공하기 때문에 DAO를 구현하는데 있어 꽤 많은 시간을 절약할 수 있다.
    • 또다른 이유로는 Spring Boot 3.3버전대에서 더 이상 MyBatis를 옵션으로 넣어 주지 않는다는 것이다. 사실 Java 진영에서 JPA를 표준으로 밀어주고 있기 때문에 이를 따르기 위해서 사용한 것도 있었다.
    • JPQL과 같이 쿼리를 결국 적어줘야 하는 것도 QueryDSL과 같은 라이브러리를 통해 컴파일이 가능하도록 할 수 있기 때문에 사용을 결정하게 되었다.
  • Spring Data Redis - Redis를 스프링과 통합해주는 라이브러리이다.
    • Redis의 경우 나는 시큐리티에서 JWT를 저장하고 관리하는 DB로 사용할 것을 생각하고 있었고, 후에 데이터 캐싱을 진행하려는 목적도 있었기 때문에 사용을 확정하고 있었다.
    • 다른 인메모리 DB를 사용하는 것은 생각해보지 않은 것인가 라는 질문을 같은 팀원에게 받았는데 나는 이전에 경험했던 동시성 문제 이슈 때문에 Redis에서 제공하는 연산들 중 atomic하게 동작하는 것을 보장하는 부분에 매력을 느꼈다.
    • 그리고 혹시나 이후에 만약 MSA로 가게 된다면 메세지 큐(MQ)로써 사용할 수 도 있기 때문에 Redis를 사용하는 것으로 마음을 굳혔다고 이야기를 했었다.
• 아마 이것 이외에는 이후에 이야기를 하면서 설명할 기회가 있을 것 같아 이정도로만 설명을 하려고 한다.

화상 회의 기능

• 우리 기능 중 화상 회의와 같은 기능이 필요해 해당 기능을 제공해줄 수 있는 솔루션이 있는가를 살펴보게 되었다.

• 이전에 공통 프로젝트를 수행했던 기수들의 레포지토리를 살펴보면서 대부분 Open Vidu를 사용했다는 것을 알게 되었다. 그래서 왜 이것을 사용했는지를 확인해 보았다.

  • Open Vidu는 자체적으로 화상 기능과 관련된 것들을 제공해주는 일종의 솔루션으로 생각을 했었다. 실제로 Docker를 통해 설치를 해 본 결과 내부에 Nginx, Open Vidu 서버, Kurento Media Server 와 같이 화상 기능과 관련된 서버들을 다 가지고 있었다.
  • 결국 화상 회의 및 채팅과 관련된 기능들이 Open Vidu를 사용해서 설정만 좀 건드려 주면 바로 기능 사용이 가능했으므로 이 부분에서의 개발 시간이 극적으로 줄어드는 효과를 가질 수 있었다.

• 사실 Open Vidu 이외에 순수한 Kurento라는 화상 회의 서버를 사용해서 직접 구현을 하는 방법도 있었지만 굳이 이미 발명된 바퀴를 또 발명할 필요는 없을 것이다. 망설임 없이 해당 기술(솔루션)을 사용하기로 결정했다.

• 우리는 화상 회의 창에서 여러 기능들을 추가해야하기 때문에 해당 창을 조작할 수 있는 기술도 결정해야 했었다. 이 부분은 웹뷰로 보여줘도 상관없었기 때문에 FE 파트에서 필요할 시에 바로 지원을 해줄 수 있는 React를 사용해서 구현하는 것으로 결론을 내렸다.

• 배포의 경우에는 CI/CD로 Jenkins를, 띄우는 것 자체는 Docker를 사용해서 Spring 서버를 띄웠다가 내렸다가 하는 형식으로 하기로 했기 때문에 Docker 및 Jenkins, Docker-Compose를 사용해 진행하도록 결정을 했었다.

• 백엔드 서버 개발과 관련된 것은 다음 글에서 적어 보도록 하겠다.