🎯 웹 기반 문서 편집기 제작 프로젝트의 개발 환경 구성을 정리합니다.

📗 Today I Learned

전체 구성 개요

• Frontend

  • 사용자 인터페이스(UI)를 제공하는 React 앱입니다.

  • 사용자의 요청은 브라우저에서 실행되는 JavaScript를 통해 백엔드 API로 전달됩니다.

  • https://notes.prgms-fullcycle.com/api

• Backend

  • Express 프레임워크를 사용한 Node.js 기반 서버입니다.

  • JWT (JSON Web Token)를 이용한 사용자 인증을 통해 데이터 접근을 보호합니다.

  • CORS (Cross-Origin Resource Sharing) 정책을 통해 악의적인 접근을 방지합니다.

  • notes.prgms-fullcycle.com:3306

• Database

  • 데이터베이스 이름 : prgms_notes

  • 두 개의 테이블이 존재합니다. (상세 스키마는 후속 정리 예정)

---

서비스 모델 아키텍처

AWS EC2 인스턴스 위에 Minikube로 구성된 Kubernetes 클러스터를 올리고, 거기에 FE(Frontend), BE(Backend), DB를 각각 Pod로 배포한 구조입니다.

외부 사용자(Web Browser)는 Nginx Reverse Proxy를 통해 FE와 BE에 접근하게 됩니다.

Web Browser

• 사용자는 브라우저를 통해 서비스에 접속합니다.

• https://notes.prgms-fullcycle.com

• 포트는 HTTPS(443) 또는 HTTP(80)를 사용합니다.

Nginx Web Server (Reverse Proxy)

• EC2 인스턴스 내부에 위치한 리버스 프록시(Reverse Proxy) 서버입니다.

• 외부에서 들어오는 요청을 경로(/, /api)에 따라 분기해서 내부 서비스(FE/BE)로 전달합니다.

🤔 Reverse Proxy는 뭘까?

클라이언트(사용자)와 서버(실제 서비스) 사이에서 중간에서 요청을 받아서 적절한 서버로 전달해주는 중간 관리자 같은 역할을 합니다.

notes.prgms-fullcycle.com에 접속했지만, 사이트는 실제로 여러 서비스(FE, BE)로 나뉘어있고 포트도 다 다르기 때문에 요청 경로를 분석하고 알맞은 서비스로 자동으로 연결해주는 Reverse Proxy가 필요한 것입니다.

• / 경로 요청 → localhost:30030 → FE 서비스로 전달
• /api 요청 → localhost:30031 → BE 서비스로 전달

---

🔙 왜 Reverse(역방향) Proxy일까?

전통적인 Proxy는 사용자를 보호하는 역할이 중심이었다면, Reverse Proxy는 서버를 보호하고 대신 응답하는 구조로 요청 주제가 반대 방향에서 시작하기 때문에 역방향 프록시가 되었습니다.

• Proxy (정방향 프록시)
  
  
• Reverse Proxy (역방향 프록시)
  출처: cloudflare

Minikube k8s Cluster

• EC2 인스턴스 안에 Minikube 클러스터를 띄우고, 그 안에 FE, BE, DB 각각의 컴포넌트가 서비스됩니다.

  • Frontend

    • 내부 포트 : 3000

    • 외부로 노출된 NodePort : 30030

    • Nginx → 30030으로 요청을 포워딩

  • Backend

    • 내부 포트: 3031

    • 외부로 노출된 NodePort : 30031

    • Nginx → 30031으로 요청을 포워딩

  • Database (MariaDB)

    • 포트 : 3306 (MariaDB 기본 포트)

    • FE/BE가 직접 DB에 접속할 수 있도록 내부에서 연결

---

개발 환경 단계별 구성

단계 (환경)	내용
Dev (-)	코드 개발 단위 테스트 FE/BE 개발 테스트 수동 사용자 테스트
Dev docker (Docker)	BE부터 dockerize docker compose 빌드된 코드 이용 컨테이너 테스트
Test (Local k8s)	kubectl + yaml 클러스터 운용 테스트
Stage (AWS)	Acceptance Test 테스트 종료 후 파괴
Prod (AWS)	Smoke Test 서비스 제공

---

개발 환경의 운용

• 빠르게 피드백을 받을 수 있어야 합니다.

  • 코드 수정이 잦은 초기 단계에서는 눈으로 바로 결과를 확인할 수 있는 환경이 중요합니다.

  • 특정 기능 구현 전에, 관련 코드가 예상대로 동작하는지 가볍게 체크할 수 있는 구조가 유리합니다.

• TDD를 적용한다면?

  • 효율은 높지만, 구조 변경이 많을 경우 테스트 코드 유지보수가 어렵습니다.

  • 특히 사용자 인터페이스(UI)에 대한 테스트는 자동화에 한계가 있습니다. → UI나 변경이 많은 기능은 개발 서버에서 수동 테스트로 빠르게 확인할 수 있어야 합니다.

---

데이터베이스 준비

• DBMS : MariaDB v11.2.2

• 배포 위치 : 로컬 Kubernetes 클러스터

• 초기 상태 : 스키마와 테스트용 샘플 데이터 세팅 예정

• 스토리지 방식 : HostPath 볼륨으로 데이터 보존

---

✏️ 회고

개발 단계에서 너무 빨리 배포 환경을 염두에 두기보다, 빠르고 쉽게 실험할 수 있는 구조를 만드는 것이 오히려 생산성을 높이는 길이라는 것을 느꼈다.