React·FastAPI·MySQL을 Docker Compose로 통합하고 Naver Cloud에 배포
회원·게시글·댓글·추천 기능이 있는 커뮤니티 서비스를 구현하며 브라우저부터 데이터베이스·Linux·네트워크까지 이어지는 전체 흐름을 경험했고, 2026년에는 인증정보·인가·설정 문제를 다시 검토해 공개용 코드를 정리했습니다.
왜 이 프로젝트를 시작했는가
GamjaWeb 직전에 진행한 2023 뉴스빅데이터 해커톤에서는 짧은 기간 안에 기능을 완성하는 데 집중한 나머지 역할과 책임, 개발 순서, 완료 기준을 명확하게 나누지 못했습니다. 이 경험을 바탕으로 다음 팀 프로젝트에서는 초기에 담당 영역과 협업 방식을 구체적으로 정하고, 각자의 작업을 안정적으로 합칠 수 있는 개발 체계를 만들어 보고 싶었습니다.
마침 2023년 2학기 데이터베이스 과목에서 관계형 데이터베이스를 배웠습니다. 수업에서 익힌 개념을 이론에 그치지 않고 사용자·게시글·댓글·추천을 실제 테이블과 관계로 설계한 뒤 웹 기능으로 구현하며 더 깊이 이해하고자 했습니다.
또한 로컬 환경에서 기능을 구현하는 데서 끝내지 않고, 클라이언트·서버·데이터베이스를 하나의 서비스로 통합해 외부 환경에 직접 배포해 보고 싶었습니다. 브라우저의 요청이 서버와 데이터베이스를 거쳐 응답으로 돌아오고, 완성한 서비스가 외부 사용자에게 제공되기까지의 과정을 경험하며 실제 웹사이트가 작동하는 방식을 배우기 위해 React, FastAPI, MySQL을 Docker Compose로 통합하고 Naver Cloud에 배포하는 GamjaWeb을 시작했습니다.
PROJECT OVERVIEW
항목 | 내용 |
기간 | 2023.12.01–2024.02.20 · 2026년 공개용 보안 정리 |
수행 형태 | 3인 팀 토이프로젝트 |
문제 | 수업에서 개별적으로 배운 Linux·Docker·관계형 데이터베이스를 실제 웹서비스의 하나의 실행 흐름으로 연결하기 |
데이터·대상·환경 | 사용자·게시글·댓글·추천 관계 데이터 · Linux · Docker Compose · Naver Cloud Platform |
분석·구현 범위 | MySQL 관계 설계, JWT 인증, 커뮤니티 CRUD, 드래그 댓글, React–FastAPI 연동, 컨테이너 통합, 클라우드 배포, 2026년 보안 재검토 |
결과 | 브라우저–API–DB 전체 흐름 구현 · Docker Compose 통합 · Naver Cloud 외부 배포 · 공개용 코드 보안 정리 |
GamjaWeb
foxirain
핵심 질문 — 클라이언트·서버·데이터베이스·운영체제·네트워크를 어떻게 하나의 서비스로 연결하고, 각 경계에서 어떤 입력과 권한을 신뢰해야 할까?
Project Flow
단계 | 판단 기준 | 산출물·확인 결과 |
1. 데이터·기능 설계 | 화면 기능을 어떤 엔터티와 관계로 표현할 것인가 | 사용자·게시글·댓글·추천 관계와 API 범위 |
2. 백엔드 구현 | 요청이 인증·권한 판단을 거쳐 올바른 데이터 변경으로 이어지는가 | JWT 인증과 커뮤니티 CRUD API |
3. 클라이언트 연동 | React 상태와 서버 응답을 일관되게 연결할 수 있는가 | 회원·게시판·댓글·추천·프로필 사용자 흐름 |
4. 실행 환경 통합 | 클라이언트·서버·DB를 독립 서비스로 실행하고 연결할 수 있는가 | Docker Compose 기반 통합 환경 |
5. 외부 배포 | 공인 IP·포트·인바운드 규칙을 통해 필요한 경로만 열었는가 | Naver Cloud 외부 배포 경험 |
6. 보안 재검토 | 클라이언트 입력·소유권·비밀정보·로그를 서버가 안전하게 다루는가 | 2026년 공개용 보안 정리 버전 |
ROLE
Backend Developer · DevOps Contributor- 담당 역할: 3인 팀에서 MySQL 관계 설계, FastAPI 백엔드 API, React 클라이언트 연동, Docker Compose 실행 환경 구성을 담당했습니다.
- 데이터·백엔드 책임: 사용자·게시글·댓글·추천 관계를 설계하고, JWT 인증과 게시판·댓글·추천·프로필 API를 구현했습니다.
- 통합 책임: React 화면의 요청·응답을 FastAPI와 연결하고, 클라이언트·서버·MySQL을 Docker Compose에서 함께 실행할 수 있도록 구성했습니다.
- 배포 경험: Naver Cloud에서 공인 IP·서비스 포트·인바운드 접근 규칙을 다루며 외부 배포 과정에 참여했습니다.
TECH STACK
React · JavaScript · Python · FastAPI · MySQL · Linux · Docker Compose · Naver Cloud Platform MY WORK
1. 화면 기능을 관계형 데이터 구조와 API로 변환
회원·게시판 기능을 단순 화면 목록으로 보지 않고 사용자·게시글·댓글·추천 사이의 관계로 나누었습니다. 이 관계를 기준으로 가입·로그인부터 게시글·댓글·추천과 사용자 활동 조회까지 API 범위를 설계했습니다.
기능 | 구현 내용 | 데이터 관점 |
게시판 | 카테고리별 게시글 작성·조회·수정·삭제 | 사용자와 게시글의 작성자 관계 |
댓글 | 일반 댓글과 선택 문장에 연결되는 드래그 댓글 | 게시글·작성자·선택 위치·댓글 관계 |
사용자 활동 | 추천·조회 수·내가 쓴 글·추천한 글 조회 | 사용자와 콘텐츠 사이의 활동 관계 |
프로필 | 이름·GitHub 주소·비밀번호 변경 | 민감한 계정 데이터와 변경 권한 |
이 작업을 통해 화면의 한 기능이 데이터베이스에서는 여러 엔터티와 관계로 표현되고, API 요청은 그 관계를 조회하거나 변경하는 행위라는 점을 이해했습니다.
2. JWT 인증과 서버 측 권한 경계 구현
JWT 액세스·리프레시 토큰을 이용한 회원가입·로그인·로그아웃 흐름을 만들었습니다. 초기에는 토큰 발급과 기능 동작에 집중했지만, 이후 클라이언트가 보낸 사용자 번호를 서버가 그대로 신뢰하거나 수정·삭제 시 소유권을 다시 확인하지 않으면 인증된 사용자도 다른 사용자의 데이터에 접근할 수 있다는 점을 확인했습니다.
2026년 공개용 정리에서는 요청 본문의 사용자 식별자 대신 검증된 JWT의 식별자를 사용하고, 게시글 수정·삭제 등 소유권이 필요한 작업에 서버 측 인가를 적용했습니다. 이 과정을 통해 인증은 사용자가 누구인지 확인하는 일이고, 인가는 그 사용자가 해당 작업을 수행할 권한이 있는지 검증하는 일이라는 차이를 코드에서 확인했습니다.
3. 선택 문맥을 데이터로 저장하는 드래그 댓글 구현
일반 댓글 외에 게시글의 특정 문장을 선택해 의견을 남기는 드래그 댓글을 구현했습니다. 사용자가 선택한 문장의 시작·종료 위치를 저장하고, 화면을 다시 열었을 때 해당 범위와 댓글을 연결해 렌더링했습니다.
단순 CRUD에서 한 단계 더 나아가 화면의 선택 범위를 데이터 구조로 표현하고 다시 사용자 인터페이스로 복원하는 흐름을 경험한 기능입니다.
4. React·FastAPI·MySQL을 Docker Compose로 통합하고 배포
영역 | 담당한 핵심 | 확인한 경계 |
React Client | 화면 상태, 라우팅, API 요청·응답 연결 | 브라우저 입력과 서버 데이터의 경계 |
FastAPI Server | 인증, 게시판 API, 비즈니스 로직과 권한 처리 | 외부 입력을 검증하는 신뢰 경계 |
MySQL | 사용자·게시글·댓글·추천 관계 설계 | 보호해야 할 핵심 데이터 자산 |
Docker Compose | 세 서비스를 분리하고 하나의 환경으로 통합 | 서비스 간 주소·포트·실행 의존성 |
Naver Cloud | 공인 IP·포트·인바운드 접근 규칙 설정 | 애플리케이션 밖의 네트워크 접근 경계 |
코드만 동작한다고 서비스가 공개되는 것이 아니라, 운영체제·컨테이너·포트·방화벽 규칙이 함께 맞아야 한다는 점을 배웠습니다.
5. 2026년 보안 재검토로 기능 동작과 안전한 운영을 구분
당시 프로젝트를 현재 작업처럼 보이게 다시 쓰기보다 초기 구조와 기능을 유지하면서 공개에 필요한 문제를 정리했습니다.
초기 구현의 문제 | 2026년 공개본에서 정리한 내용 |
요청 본문의 사용자 식별자를 신뢰 | 검증된 JWT의 사용자 식별자를 서버에서 사용 |
일부 수정·삭제의 소유권 검사 부족 | 서버 측 인가와 소유권 검증 추가 |
소스에 JWT 비밀키와 고정 서버 주소 포함 | 비밀키·API 주소·CORS 설정을 환경변수로 분리 |
비밀번호·토큰이 출력될 수 있는 로그 | 민감 로그 제거 |
학습 편의를 위한 localStorage 토큰 보관 | 현재 한계로 명시하고 실제 서비스에 그대로 적용하지 않음 |
현재 공개 저장소는 2023–2024년의 커밋 이력을 복원한 원본이 아니라, 2026년에 민감정보와 인가 문제를 정리하고 실행 가능성을 다시 확인한 스냅샷입니다.
RESULTS
- 풀스택 구현: React 클라이언트·FastAPI 서버·MySQL 데이터베이스를 연결하고 JWT 인증, 커뮤니티 CRUD, 댓글·추천·프로필 기능을 구현했습니다.
- 차별 기능: 선택 문장의 위치와 댓글을 연결하는 드래그 댓글로 화면의 문맥을 데이터 구조로 표현했습니다.
- 실행 환경: 세 서비스를 Docker Compose로 통합하고 Naver Cloud의 공인 IP·포트·인바운드 규칙을 설정해 외부 배포를 경험했습니다.
- 보안 개선: 2026년에는 JWT 기반 서버 식별, 소유권 검증, 비밀정보·API 주소·CORS 환경변수화와 민감 로그 제거를 공개용 코드에 반영했습니다.
- 핵심 결과: 데이터베이스를 단순 저장소가 아니라 보호해야 할 자산으로 보고, 클라이언트·API·DB·운영체제·네트워크의 각 경계를 하나의 보안 흐름으로 이해하게 됐습니다.
- 한계: 자동화 테스트·운영 모니터링·배포 자동화가 없고, HTTP와
localStorage기반 토큰 보관 등 운영 서비스에 그대로 적용하기 어려운 선택이 남아 있습니다. 현재 공개본은 원 개발 이력이 아닌 2026년 보안 정리 스냅샷입니다.
배운 점과 다음 단계
GamjaWeb을 Docker Compose로 통합하고 Naver Cloud에 배포하면서, 클라이언트·서버·데이터베이스가 어떤 주소와 포트로 연결되고 외부 요청이 서버까지 전달되는지를 직접 확인했습니다. 공인 IP와 인바운드 규칙을 설정하는 과정에서는 방화벽이 단순히 접속 문제를 해결하기 위한 설정이 아니라, 외부에 공개할 서비스의 범위를 제한하는 중요한 보안 경계라는 점을 배웠습니다.
이 프로젝트에서는 이전보다 역할과 책임, 개발 순서와 완료 기준을 구체적으로 나누어 협업했습니다. 그러나 체계를 정하는 것만으로 의견 차이가 사라지지는 않았습니다. 기능의 우선순위와 구현 방향을 두고 서로 다른 판단이 생겼고, 각자의 근거를 설명하고 공통 기준을 정하면서 작업 범위와 방식을 조율하는 과정을 경험했습니다. 이를 통해 팀 개발에서는 역할 분담뿐 아니라 서로의 판단 기준을 맞추고 각자의 결과물을 지속적으로 통합하는 과정이 중요하다는 점을 배웠습니다.
한편, 기능 구현과 배포에 집중한 나머지 웹 보안을 충분히 고려하지 못한 점은 아쉬움으로 남았습니다. JWT 기반 로그인은 구현했지만 인증과 인가의 차이, 토큰 관리, 서버 측 권한 검증까지 깊이 있게 설계하지 못했습니다. 이후 코드를 다시 검토하며 기능이 동작하는 것과 안전하게 운영되는 것은 별개의 문제라는 점을 배웠습니다.
클라우드 서버에 원격으로 접속해 배포와 네트워크 설정을 직접 관리한 경험은 Linux 서버 운영에 관심을 갖게 한 계기가 되었습니다. 원격의 컴퓨터를 직접 구성하고 실제 서비스를 제공하는 과정에 매력을 느꼈고, 이후 SER8 8745HS 미니 PC로 개인 Linux 서버를 구축하며 그 관심을 확장했습니다.