교내 중고거래 백엔드 개발 복기(1) - 기획 및 개발 기술 선정(API, DB, 실시간 양방향 통신)

머리말

이전 포스팅 보기

교내 중고거래 백엔드 개발 복기(0) - 나는 무엇을 했고 해야 하는가

이번 포스팅에서는 개발을 시작하게 된 계기, 서비스의 기획과 기능 구현에 사용할 기술 비교 및 선정의 과정을 기록해보고자 한다.

서비스의 기획

우선 학교 내 커뮤니티에서 기존의 당근, 중고나라와 같은 온라인 거래 플랫폼을 이용할 때, 근처 동네에 직거래를 하러 가는 것이 너무나도 불편하였다. 시내까지 가려면 우선 기숙사에서 학교 밖까지 10분, 학교 앞의 넓은 공원을 지나 또 10분, 그리고 사람들이 많이 모이는 곳까지 가는데 또 5~10분 정도 걸린다. 최소 2~30분을 걸어서 나가야 하고, 학생들은 또 팔고자 하는 게 보통 냉장고, 전공서적 등 기숙사 내에서 거래하거나 다른 학생에게 팔기 적절한 물품들이 큰 비중을 차지하고 있었다.

직거래 하러 큰 고난을 이겨내야 할수도...

 

그렇다고 하기에는 다른학교도 다 있는 에브리타임의 중고거래 기능이 우리학교에는 없었다. 진짜 처음부터 없었다. 수업 시간표도 에브리 타임에 수강 과목들이 동기화가 안되어 있어서 시간표를 미리 짜볼 수 있는 서비스까지 나올 정도이니 중고거래도 충분히 도전해볼만한 과제라고 생각했다. 학생수가 적은 만큼 서비스 개발에 있어서 해볼 수 있는 사안이 많아서 좋은 것 같다.

교내 중고거래 기능이 없다

 

결국 아래 사항들의 서비스를 개발하여 교내 학생들의 중고거래 활성화를 도모하였다. 내가 개발한 기능도 이 서비스를 위해 구현되었다고 보면 되겠다.

• 게시물 기능으로 중고거래할 물품 업로드
• 각 판매 물품에 해당하는 게시물에 대해서 채팅 기능 - 거래 완료 과정까지
• 오프라인 사물함을 통한 비대면 거래 기능

벡엔드 개발의 시작

제대로 배포까지 하는 것을 목표로 하는 서비스를 구축하는 것은 이번이 처음이었다. 또한 단순하게 게시물, 사물함 거래에 대한 RESTful API만 구축하는 것이 아니라, 서비스 내 채팅 기능을 위한 실시간 통신을 위한 기술 활용이 필요했다. 이를 위해서 필요한 기술 스택 범위를 아래처럼 설정했다.

• RESTful API 서버
  • 사용자, 게시물, 채팅방, 사물함 거래 관리
• 데이터베이스
  • API 서버를 통해서 서비스의 기록과 관리
• 실시간 통신
  • 채팅 기능에 필요한 기술
  • 실시간 사용자 접속 관리
  • 채팅 송수신
  • 채팅 상대가 미접속 시, 알림 송신

이제 구체적인 기술 스택을 정해보자.

 

어떤 기술로 개발할 것인가?

API서버 : FastAPI vs Java Spring

우선 API서버이다. Java Spring현업에서도 많이 사용하고 있으며, 안정적인 성능에 기반하여 대규모 서비스 확장에 적합하다. 하지만 지금 내 상태로써는 Java 언어를 다뤄본 경험은 있지만, 언어 자체의 복잡한 특징과 프레임워크의 생태계에 대한 기반 지식 부족 때문에 학습곡선이 높았다.

반면에 FastAPI는 Python 기반의 간단하고 명료하게 API 서버를 구축할 수 있다는 장점과 더불어, 빠른 속도의 비동기도 지원하며 Pydantic을 통해서 타입 검사도 가능하기에 기존 Python의 동적 타이핑의 단점을 보완할 수 있다. 추가적으로 API 문서의 자동 생성이나, Spring만큼은 아니지만 의존성 주입도 가능했기에 FastAPI를 선택할 이유가 충분했다.

최종적인 결정에서 고려했던 부분이 '적은 사용자(한 학년 전교생이 200명이다.)', '(Python 기반)AI 기능 도입'이였기 때문에, 단일 FastAPI 서버 성능으로도 충분히 커버 가능하다고 생각하여 FastAPI를 선택하였다. 

아래는 줄글의 내용을 표로 정리해본 내용이다.

특징	FastAPI	Java Spring
언어	Python	Java
코드 간결성	간결하고 명료하게 가능	언어 특성상 복잡할 수 있음
타입 검사	Pydantic 기반	Java 강타입 시스템
문서화	자동 생성(Swagger, OpenAPI)	별도의 설정 필요
배포(MSA)	경량에 적합	대규모 아키텍쳐에 적합
학습곡선(개인 기준)	낮음(Python 친화적)	높음(Spring 생태계 학습 필요)

추후에 서비스가 커지게 된다면 AI 서비스 부분은 FastAPI로, 나머지 백엔드 구현에는 Spring으로 대체하면 좋지 않을까 생각하였다.

DB : MariaDB

데이터 베이스를 고르는 과정에서는 초기 프로젝트인 점을 고려해서 아래의 사항을 중점적으로 살펴보았다.

• 학습 곡선: 초기에 쉽게 배울 수 있는 데이터베이스 
• 커뮤니티 지원: 문제 해결을 위한 커뮤니티의 지원 
• 성능 및 확장성: 중소 규모 프로젝트에 적합한 성능과 확장성 
• 비용: 무료 또는 저비용의 솔루션

이 조건을 충족하면서, 이전에 사용 경험도 있는 MySQL과도 쉽게 호환되고 완전 오픈 소스인 MariaDB를 사용하기로 결정하였다. 또한 버전으로는 LTS버전으로 장기 지원이 가능한 10.5버전을 사용하였다.

실시간 통신: WebSocket vs Socket.io

채팅을 구현하는 데 있어서, 1대1 채팅 방식만을 지원하는 서비스이기 때문에 각 채팅방과 해당 방에 연결된 사용자들의 상태 관리가 필요한 상황이었다.

처음 시작에서는 이벤트 핸들링, 메시지 포맷을 구체적으로 정하지 못했기 때문에 자동 재연결 같은 폴백 기능을 활용하지 못하더라도 FastAPI에 WebSocket결합을 선택하여 기초적인 기능들을 구현해 가며, 필요성이 느껴질 때 Socket.io로 전환하고자 하였다.

아래에는 각 기술의 비교를 표로 정리해보았다.

특징	WebSocket	Socket.io
개념	브라우저와 서버 간의 실시간 양방향 통신 프로토콜	WebSocket 프로토콜을 기본으로 하는 라이브러리
구현	네이티브 구현 필요	자체 서버 라이브러리 제공
메시지 포멧	텍스트 기반	JSON - 구조화 가능
폴백(Fallback)	없음	HTTP Long Polling, AJAX 등
이벤트 기반	직접 구현 필요	이벤트 기반 메시징 (emit, on) 제공

 

일단 정리한 내용만 살펴보더라도 필요한 기능에 따라서 Socket.io로 전환하는게 당연하지만, 날것의 WebSocket을 음미하여 라이브러리의 필요성을 제대로 느껴보고자 하였다.

 

마무리

이러한 고민들이 이제 막 프로젝트 시작하는 다른 분들에게도 도움이 되면 좋겠다.

다음 포스트에서는 API 서버 구축과 관련해서 포스팅하고자 한다. 응원 부탁드립니다!

 

• 다음 포스트 보기

https://sundaekugbab.tistory.com/12

교내 중고거래 백엔드 개발 복기(2) - 기본 CRUD 구성, 게시물 API