LEFT ON

Flask와 Django, PostgreSQL에 대하여

LEFT — Mon, 5 Jan 2026 00:09:23 +0900

인턴십 프로젝트

[25.08.06-25.09.05]

Flask

Python으로 구동되는 웹 어플리케이션 프레임워크
Django 프레임워크보다 가볍고 스케일이 작은 서버 → 큰 서버까지 만들 수 있음
가상환경/가상서버를 만든다는 개념

❓Flask vs Django

Django

장고는 모델이라는 개념을 사용
모델 : 우리가 처리하고자하는 데이터들이 어떤 정보를 가지고 있는지를 정의한 것 (=스키마)
이 모델의 규칙을 따라서 생성된 데이터들이 실제로 저장되는 공간이 “데이터베이스”
따라서 모델은 추상적 개념이고, 데이터베이스는 구체적 개념
처음 서비스 설계시
ex)
- 종류 (정보) : 맛집, 평가, 회원
- 속성 :
➡️맛집의 세부적인 속성으로 (주소, 명칭, 전화)
➡️평가의 세부적인 속성으로 (별점, 회원, 코멘트)
➡️회원의 세부적인 속성으로 (이메일, 닉네임)

- 자료형 결정 : 주소, 명칭, 전화 = str, 별점 = int, 회원 = str
(하지만 다른데이터를 참조하고있는 relationship (=참조형 레퍼런스)는 장고에서 relation (릴레이션) 이라고함)
▶️즉 회원은 릴레이션 타입

Django 설치

파이썬이 필요

pip install django

각 파이썬 서버마다의 가상 서버
(즉 개인, 회사, 토이플젝용)으로 나누어서 환경설정을 세팅해야하기때문에 virtualenv 이 필요

이처럼 myenv 가상환경 안에 pip install Django 로 장고를 설치할 수 있음
myenv 가상환경 안에서 python → import django 를 입력했을때 아무 반응이 없어야 제대로 설치가 완료된 것

가상환경 설치

가상환경 만들기

명령프롬프트에서는 dir로 myenv 디렉토리를 확인한 후
cd myenv → cd Scripts → activate.bat 을 실행하면 가상 환경이 만들어짐
이를 통해 이 안에 설치되는 패키지들은 전역(글로벌)로 설치되는 것이 아닌 가상으로 설치할 수 있어
여러개의 가상서버에 각기 다른 패키지들을 환경으로 구성할 수 있다는 장점

데이터베이스

데이터베이스를 읽기위해서 DBeaver 사용
데이터베이스 모델링은 pgAdmin 4를 통해 구조 보기

테이블 구조 보기
- pgAdmin 4의 좌측 Object Explorer에서
Databases > [데이터베이스 이름] > Schemas > public > Tables

- product 테이블을 클릭하여 테이블의 속성들 확인
- product 테이블 아래의 Columns 폴더를 열면 id, name, brand, price 등 테이블의 컬럼 구조를 확인 가능
ERD(ER Diagram) 보기
- pgAdmin 4의 ERD 기능은 DBeaver처럼 ER Diagram이라는 별도 탭으로 바로 제공되진 않음
- Tools 메뉴에서 Schema Diff나 Query Tool을 사용하여 스키마를 비교하거나,
SQL 쿼리를 직접 실행하여 스키마 정보를 추출

- 하지만 DBeaver처럼 시각적인 ERD 기능을 기본으로 제공하지는 않기 때문에, ERD 확인은 DBeaver가 더 편리

pgAdmin4의 첫 사용으로 샘플DB를 만들어 테스트해보는 것 진행

[멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_113일차_"2차 팀 프로젝트 마무리"

LEFT — Mon, 8 Dec 2025 10:37:58 +0900

멋쟁이사자처럼 백엔드 부트캠프 13기
TIL 회고 - [113]일차

113일차에는 프로젝트의 최종 마무리를 위해 개발된 기능들을 테스트하고 수정 및 기능추가를 진행하였다. (2025.05.27)

이메일 인증 및 게스트 회원가입 테스트

이메일 인증완료 확인완료

로컬 설정파일 수정

MAIL_USERNAME: 이메일 주소
MAIL_PASSWORD: 이메일 패스워드

이메일 관련 설정에 대해 추가해준 후 위의 정보들로 수정해주어야함

API 명세 테스트

백엔드와 프론트엔드 간의 API 명세 공유의 중요성

프론트엔드 개발자가 작업을 시작하기 위해서는 백엔드 개발자(서버 로직 담당)가 만든 API의 명세(Specification)가 필요

- 백엔드 개발자 : 특정 URL(api/v1/auth/login), 요청 방식(POST), 필요한 데이터(email, password)를 정의하고 구현
- 프론트엔드 개발자 : 백엔드 개발자가 만든 명세에 따라 정확한 주소로 데이터를 전송하고, 서버가 보낸 응답 데이터를 받아
화면에 로그인 성공/실패 메시지를 표시

정리 :

프론트엔드 파트 담당 :
ex. API를 만들어서 달라는 요청 ➡️ 백엔드 개발자에게 API 엔드포인트(auth/login)의 구현을 완료해달라는 것
ex. Swagger를 만들어달라는 요청 ➡️ 백엔드 개발자가 API 명세를 Swagger 도구를 사용해 문서화해 달라는 요청

Swagger는 API의 모든 엔드포인트, 필요한 입력 값, 예상되는 응답을 자동으로 시각화해주는 도구이므로
프론트엔드 개발자는 이 Swagger 문서를 보고 curl 요청에 필요한 모든 정보를 바로 파악할 수 있게됨

따라서 curl 요청은 '백엔드 개발자가 만든 API 명세에 따라 요청을 테스트하는 행위'

회원가입된 정보로 로그인

curl -X POST "http://localhost:8090/api/v1/auth/login" \
-H "Content-Type: application/json" \
-d '{
"email": "xxx@xxx.com",
"password": "xxxxxx1!"

예를 위해 임의로 넣어놓은 이메일과 패스워드
curl 명령어를 통해 CLI 환경에서 호스트 로그인을 테스트 진행 (위의 회원가입에서 등록된 회원정보)
이를 통해 토큰값이 반환

DB에서는 패스워드가 이처럼 암호화되어서 저장되어있는데 이는 BCrypt 방식을 사용하여 암호화한 것

BCrypt (비크립트)

비밀번호를 안전하게 저장하기 위해 사용되는 해시 함수
Spring Security를 사용하는 Spring Boot 백엔드에서 기본적으로 채택하는 암호화 방식

BCrypt 구조 = (알고리즘 + 비용계수 + 솔트/해시된비밀번호)

ex. $2a$ + $10$ + lof.R4/Bq.....Fy

- 알고리즘 : BCrypt 알고리즘을 사용했음을 나타냄 (ex. $2a$ 또는 $2b$, $2y$)

- 비용계수 (Cost Factor) : 해시를 생성하는 데 필요한 계산 횟수(강도), 숫자가 높을수록 더 안전하지만, 해시 생성 시간이 길어짐
(ex. $10$)

- 솔트(Salt) + 해시된 비밀번호 : 무작위로 생성된 솔트(22자리)와 최종 해시된 비밀번호가 Base64 인코딩되어 결합
(ex. lof.R4/Bq.z9PZnVinwEYukhhWe5mKp6h1/QKV6xXmbGpUFajhaFy)

최종 예시 비밀번호 문자열 : $2a$10$lof.R4/Bq.z9PZnVinwEYukhhWe5mKp6h1/QKV6xXmbGpUFajhaFy

이미지 업로드

curl -X POST "http://localhost:8090/api/v1/spaces/images/upload" \
-H "Authorization: Bearer 반환된토큰" \
-F "files=@/c/Workspace/Lion_Project/loco_project/test_image.jpg" -v

로그인을 통해 얻은 토큰으로 이미지 업로드의 헤더에 주입
이 curl 명령어를 통해 data의 이미지 URL을 반환받음
["global/data/image/534231e3-76a0-402b-9970-dec78db296b3.jpg"]
(내용 정리를 위해 임의로 작성된 이미지 URL)

공간 등록

curl -X POST "<http://localhost:8090/api/v1/spaces>" \\
-H "Content-Type: application/json" \\
-H "Authorization: Bearer 반환된토큰" \\
-d '{
  "name": "DB연동 테스트공간",
  "description": "curl 명령어로 등록한 테스트 공간입니다.",
  "address": "서울시 강남구",
  "detailAddress": "역삼동 123-45",
  "zipCode": "06130",
  "latitude": 37.498095,
  "longitude": 127.027610,
  "price": 50000,
  "openingHours": "09:00",
  "closingHours": "18:00",
  "phoneNumber": "010-1234-5678",
  "imageUrls": ["global/data/image/534231e3-76a0-402b-9970-dcdasd296b3.jpg"],
  "type": "PHOTO",
  "maxCapacity": 10,
  "parkingAvailable": true,
  "petAvailable": false,
  "smokingAvailable": false,
  "hasKitchen": true,
  "hasRestroom": true,
  "facilities": ["WIFI", "PROJECTOR"]
}' -v

이제 공간까지 등록하고나면

1) 백엔드 서버에서의 공간 등록 성공

200 응답코드와 함께 공간 등록이 성공되었다는 로그메시지 출력

2) Git Bash에서의 공간 등록 성공 로그

$ curl -X POST "<http://localhost:8090/api/v1/spaces>" \\
-H "Content-Type: application/json" \\
-H "Authorization: Bearer 반환된토큰" \\
-d '{
  "name": "DB연동 테스트공간",
  "description": "curl 명령어로 등록한 테스트 공간입니다.",
  "address": "서울시 강남구",
  "detailAddress": "역삼동 123-45",
  "zipCode": "06130",
  "latitude": 37.498095,
  "longitude": 127.027610,
  "price": 50000,
  "openingHours": "09:00",
  "closingHours": "18:00",
  "phoneNumber": "010-1234-5678",
  "imageUrls": ["global/data/image/534231e3-76a0-402b-9970-dcasdasd96b3.jpg"],
  "type": "PHOTO",
  "capacity": 10,
  "parkingAvailable": true,
  "petAvailable": false,
  "smokingAvailable": false,
  "hasKitchen": true,
}' -vcilities": ["WIFI", "PROJECTOR"]
Note: Unnecessary use of -X or --request, POST is already inferred.
* Host localhost:8090 was resolved.
* IPv6: ::1
* IPv4: 127.0.0.1
*   Trying [::1]:8090...
* Connected to localhost (::1) port 8090
* using HTTP/1.x
> POST /api/v1/spaces HTTP/1.1
> Host: localhost:8090
> User-Agent: curl/8.10.1
> Accept: */*
> Content-Type: application/json
> Authorization: Bearer 반환된토큰
> Content-Length: 653
>
* upload completely sent off: 653 bytes
< HTTP/1.1 200
< Vary: Origin
< Vary: Access-Control-Request-Method
< Vary: Access-Control-Request-Headers
< X-Content-Type-Options: nosniff
< X-XSS-Protection: 0
< Cache-Control: no-cache, no-store, max-age=0, must-revalidate
< Pragma: no-cache
< Expires: 0
< X-Frame-Options: SAMEORIGIN
< Content-Type: application/json
< Transfer-Encoding: chunked
< Date: Wed, 28 May 2025 04:46:34 GMT
<
{"resultCode":"S-1","msg":"공간 등록 성공","data":{"id":2,"hostId":3,"imageId":null,"spaceName":"DB연동 공간테스트1","description":"curl 명령어로 등록한 테스트 공간입니다.","uploadDate":"2025-05-28T13:46:34.8586441","spaceType":"PHOTO","price":50000,"address":"서울시 강남구","latitude":37.5665,"longitude":126.978,"maxCapacity":10,"isActive":true,"spaceRating":0,"isFavoritedByMe":null,"imageUrl":"global/data/image/534231e3-76a0-402b-9970-dce79db296b3.jpg","additionalImageUrls":[]},"success":true,"fail":false}* Connection #0 to host localhost left intact

공간 등록 성공이라는 로그를 확인할 수 있음

프로젝트 마무리

팀원들과 매일 아침 전날의 이슈사항 및 오늘 해야할 일들에 대해 정리하는 데일리 스크럼 시간을 가짐
git 통합의 경우에는 기능브랜치를 분기한 팀원들이 기능개발을 완료하면 부팀장 (개발팀장)으로써 Git 통합을 진행함
➡️코드 리뷰 및 이 코드가 왜 쓰였는지 등등 (on Discord)

최종적으로는 MySQL DB로의 마이그레이션에 성공했고, Amazon S3를 통해 이미지 업로드 구현 및 Spring 으로써 블로그 서비스의 전반적인 환경을 개발해낼 수 있었음

기능정의서, 요구사항 계획 단계에서 기본으로 지정해놨던 기능과
서비스를 개발하면서 필요해진 기능까지 추가하며 업데이트했던 요구사항 정의서 시트지
팀원들과 각자 해낸 기능개발이 생기면 바로 체크해놓을 수 있도록함
중요도 (MVP)를 나누어서 중요한 기능부터 개발해내는 과정에서 이러한 시각적인 자료가 필수적이었음
⚠️요구사항 정의서에 정의된 기능을 꼭 개발해내야겠다는 생각을 하다보니
기능 하나하나의 안정성 및 테스트에는 신경을 쓰지 못했음

전체적인 구조의 ERD는 중간 피드백과 팀원들간의 기능개발에 중점을 두어 최종적으로 완성할 수 있었음

유저 및 채팅/공간 부분에 대한 ERD도 여러번의 개선 끝에 필요한 부분을 남기고 불필요한 부분은 제거해낼 수 있었음'
중간 피드백 내용 중 유저가 어드민/게스트/호스트로 나눌지
유저가 게스트/호스트로만 나누어지고 어드민은 따로 둘지 등을 고민하는 과정이 있었음
✅최종적으로는 어드민은 분리하여 관리자페이지 (백오피스)에서 권한을 토대로 활용할 수 있도록 설계하였음

트러블 슈팅

도메인 주소는 유효한 기간으로 구입해놓은 상태이지만 배포 관련하여 부족한 부분이 많아 추가하고 싶은 기능에 넣음

LoCo 블로그 서비스 페이지

게스트 페이지

1. 메인 페이지

메인화면으로 들어오면 로그인 버튼이 활성화되어있고, 지금까지 등록된 공간들 보여짐
공간을 카테고리 별로 분류하여 빠르게 필요한 공간을 찾을 수 있고
검색기능에서 필터 및 검색어를 통해 원하는 공간을 상세하게 찾을 수도 있음

2. 로그인 페이지

로그인 버튼을 누르면 게스트 로그인 (공간을 이용하는 유저) 화면으로 이동하고,
회원가입이 되지 않은 상태이면 아래의 "회원가입"버튼을 눌러 회원가입을 진행

3. 회원가입 페이지

이메일 인증 기능과 이메일, 전화번호, 비밀번호 유효성 검증을 통해 회원가입을 원활히 진행
소셜로그인 기능 ➡️카카오 로그인 구현

4. 로그인된 메인페이지

우측 상단으로 로그인이 성공한 유저 정보를 확인할 수 있음

5-1) 검색 페이지 (카테고리 : "카페")

메인 페이지에서 "카페" 카테고리를 클릭하여 "카페" 카테고리로 등록된 공간을 확인할 수 있는 검색 페이지
URL에서 /spaces/search?purpose=CAFE 로 API 요청 확인 가능

5-2) 검색 페이지 (검색어 : "인천")

메인 페이지에서 검색창에 원하는 검색어로 검색하게 되면 해당 검색어가 포함된 공간을 확인할 수 있는 검색 페이지
URL에서 /spaces/search?query=인천 으로 API 요청 확인 가능

6) 사이드탭

좌측 상단 메뉴 버튼을 눌러 사이드탭을 활성화시킬 수 있음
프로필 관리를 누르게되면 프로필 정보를 변경할 수 있는 마이페이지로 리다이렉트됨

7) 마이페이지

마이페이지에서 닉네임 및 연락처, 비밀번호, 프로필 사진까지 변경할 수 있음

호스트 페이지

1) 호스트센터 페이지

호스트페이지에서는 공간 등록/관리, 예약 및 정산 관리를 할 수 있는 페이지로 구성하였음
호스트에 대한 접근은
1) 게스트로 회원가입 후 호스트로 전환할것인지,
2) 호스트 자체 회원가입을 별도로 구분할지에 대한 고민들도 있었음
➡️현재는 호스트 자체 회원가입을 별도로 두는 방향으로 설계
게스트와 호스트의 페이지를 분리한 이유는 각 유저의 역할 별로의 기능 구분이 명확히 필요함과
동시에 유지보수의 용이성을 고려했고 게스트와 호스트가 하는 역할이 다르다고 판단하여 이러한 설계로 진행

2) 호스트 로그인 페이지

상단 메뉴의 공간작성을 클릭하면 "로그인이 필요한 서비스입니다" 문구를 통해 인증이 필요한 로직을 구현

호스트 로그인 페이지에서도 게스트 로그인 페이지와 같이 소셜로그인 (현재는 카카오 구현) 및 회원가입 페이지로 리다이렉트 할 수 있게 구현

3) 호스트 회원가입 페이지

게스트 회원가입 페이지와 마찬가지로 이메일 인증 로직과 전화번호, 비밀번호 유효성 검증 후 회원가입이 이루어짐

4) 공간 등록 페이지

kakao:
  map:
    javascript-key: API키값

application-secret.yml 부분에서 카카오맵 API 키를 발급 받아 사용하여 공간의 상세주소검색이 가능하도록 구현

이처럼 모든 공간의 정보 입력 및 등록을 완료한 후에는 호스트의 공간 정보 페이지 내에서 등록한 공간을 확인할 수 있도록 구현

공간을 눌러 공간정보 페이지에 들어가면 해당 공간의 정보 및 예약을 확인할 수 있음

예약 페이지

1) 메인 페이지 (등록된 공간들 확인)

2) 공간 상세 페이지

날짜 선택 및 시간을 선택 후 예약하기 버튼을 클릭하여 예약 페이지로 리다이렉트

2-1) 공간 예약 확인 페이지

2-2) 예약 확인 및 결제하기 버튼 활성화 페이지

3) 결제 페이지

toss:                           # 토스페이먼츠 파트
  payments:
    secret-key: 테스트키 # LoCo 프로젝트 토스페이먼츠 시크릿키
    success-url: "http://localhost:8090/api/v1/payments/success"
    fail-url: "http://localhost:8090/api/v1/payments/fail"

토스페이먼츠 API 와 연동하여 시크릿키를 발급받아 application-secret.yml 에 적용
그 결과 토스페이먼츠를 통해 다양한 은행을 통해 결제할 수 있도록 구현

ex. KB국민카드의 경우 KB Pay 앱을 실행하여 QR스캔 후 결제할 수 있도록 구현
배포되기 전 서비스이기때문에 실제 결제까지는 이루어지지 않음

관리자 페이지 (=어드민 페이지, 백오피스)

1) 대시보드 페이지

대시보드에서는 사이드탭에서 이동가능한 메뉴들과, 관리자 대시보드의 요약 부분을 한눈에 확인할 수 있도록 구현

2) 사용자 관리 페이지

토글 후 GUEST > HOST 로 변경

사용자 관리페이지에서는 해당 사용자의 권한을 변경할 수 있는 토글 버튼 (GUEST ➡️ HOST 혹은 HOST ➡️ GUEST)과
전체 유저 정보가 담겨있음

3) 예약 결제 관리 페이지

예약 내역 및 결제 내역을 관리할 수 있는 페이지

기능 시연 영상

전체 발표 영상은 개인채널에 별도 업로드 완료

https://www.youtube.com/watch?v=dQzQO2KjDYg

팀원분이 업로드한 기능시연 영상

프로젝트를 마무리하며 :

팀 프로젝트를 진행해보며 Github Project에서의 협업 및 Git 명령어에 익숙해질 수 있었고

데일리 스크럼을 통해 기능 개발 및 요구사항 정의를 기획해나가는 과정도 뜻깊었다.

Git branch를 분기하여 팀원들이 각각 기능을 개발하고 추후 병합할때 충돌된 부분들을 함께 해결해나가는 부분도

도전의식과 함께 희열, 뿌듯함도 느낄 수 있었다.

어려움이 없던 프로젝트라고한다면 거짓말이겠지만 어려웠던 만큼 어떤 부분이 부족한지, 어떤 부분에 강점인지를 파악할 수 있어

개발 공부에 큰 원동력이 될 수 있었다.

[멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_108일차_"DB 마이그레이션 및 중간 피드백"

LEFT — Sat, 6 Dec 2025 16:51:38 +0900

멋쟁이사자처럼 백엔드 부트캠프 13기
TIL 회고 - [108]일차

108일차에는 빠른 디버깅 및 테스트용으로 쓰던 H2 데이터베이스에서 MySQL 데이터베이스로 마이그레이션하는 작업과 application.yml 설정 수정, 관리자페이지 즉 백오피스의 개념 및 필요성에 대해서 팀원들과 회의 (2025.05.20)

H2 DB ➡️ MySQL DB 마이그레이션 작업

show tables; 로 마이그레이션된 테이블들 확인 완료

application.yml

  datasource:
    url: jdbc:mysql://localhost:0000/loco_db
    username: nenomdeul
    password: xxxx
    # url: jdbc:h2:./db_dev;MODE=MySQL
    # username: sa
    # password:
    # driver-class-name: org.h2.Driver

포트번호, DB명, 유저명, 비밀번호 설정 변경

백오피스 Backoffice 필요성

관리자 결제 내역 조회, 환불 처리, 통계 관리 등 기능이 필요

❓LMS, PMS, 백오피스의 차이

1) LMS : Learning Management System(학습 관리 시스템)
- 교육/강의/수강생 관리 중심

2) PMS : Property Management System(부동산/공간 관리 시스템)
- 호텔, 공간, 예약, 청소 등 자산 관리 중심

3) 백오피스 : 서비스 운영자(관리자)가 전체 시스템을 관리하는 내부 시스템
(ex. 회원, 예약, 결제, 통계, 신고, 환불 등)

정리 :

LoCo 프로젝트는 공간 예약/결제/회원/호스트/게스트/통계/환불/신고 등 다양한 관리가 필요하므로
LMS, PMS라기보다는 "백오피스"가 포함된 공간 서비스로 개발이 필요

관리자 페이지 기능 개발 (LoCo 프로젝트)

프로토타입

중간 피드백

1) 관리자 엔드포인트에는 반드시 관리자 권한 검증이 필요
➡️Spring Security의 @PreAuthorize("hasRole('ADMIN')") 같은 어노테이션 사용 추천

2) Swagger 문서화 정보가 보충될 필요 ➡️@Operation 관련 내용

3) 잘못된 ID나 이미 처리된 공간에 대한 예외 처리를 추가 필요

4) PR에서 팀원 간 상세한 코드 리뷰의 필요성
➡️Repository에 리뷰 과정이 기록되어있는 것이 좋음
➡️구체적으로는 PR에서 File Changed 탭에서 코드에 대한 의견과 개선점과 같은 것들을 Comment로 첨언해서 기록하는 것

5) 주석 관련하여 메서드나 필드 자체를 설명하기 위한 Docs 주석은 좋았지만 일부 다른 구간에서 불필요 주석 및 업데이트 되지 않은 주석이 있는 부분 수정 필요
➡️주석으로 구분하기보다 기능을 메서드로 분리하여 가독성을 향상시키는 것이 필요

6) 테스트 코드에 대한 내용 필요
➡️테스트를 위한 개발을 하는 것은 좋지 않지만, 현재 개발되어있는 기능들에 대한 테스트와 명세를 남기는 것도 도움이 됨

회고 결과 :

데이터베이스의 마이그레이션에서 application.yml 설정파일들에 대한 공부를 진행할 수 있었음

관리자페이지의 필요성에 대해 알고 백오피스 페이지 개발에 대해 팀원들과 상의할 수 있었음

중간 피드백을 통해 프로젝트 개발 중간의 개선사항과 방향성에 대해 파악할 수 있었음
(특히 어노테이션의 부재 및 주석 관리 필요성)

[멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_103일차_"Git Projects 이슈 관리 및 게시판 Board"

LEFT — Tue, 18 Nov 2025 13:03:51 +0900

멋쟁이사자처럼 백엔드 부트캠프 13기
TIL 회고 - [103]일차

103일차에는 각자 만든 기능 브랜치들의 병합을 위해 Git Projects로 팀원들의 이슈를 관리할 수 있도록 구축해보았다. 또한 게시판 Board 담당으로 게시글 관련 엔티티 및 Repository, Service, Controller를 설계하였다. (2025.05.13)

103일차 기능개발 Log

깃허브 - 프로젝트 - 이슈생성

이슈번호 #15 확인 (본인이 만든 이슈번호 확인)

git switch develop

현재 브랜치가 develop 브랜치인지 확인

git pull

원격의 develop 브랜치 작업내용 가져오기 - 팀원들이 병합한 코드 최신화

git checkout -b feature/#15

아까 만든 이슈번호로 새 브랜치 생성
최신화된 develop 브랜치 내용을 기반으로 feature/#15브랜치가 분기

git branch

(현재 어느 브랜치에 위치해있는지 확인
[* feature/#15] 처럼 표시됨
feature/#15 브랜치 확인 후 기능 개발 진행

git status
git add .
git commit -m “feat: 댓글 엔티티 설계 (#15)”

기능 개발 진행 후 (#15)처럼 이슈번호를 적어야 이슈트래킹 용이

git push --set-upstream origin main

원격 저장소에 feature/#15 브랜치와 함께 feature/#15 브랜치 작업내용을 push
기능 개발이 끝났으면 저장소에서 Compare & Pull Request로 눌러 PR 날리기

Board 게시판 개발

Board - Controller - 게시글 작성

웹에서 사용자가 새 게시글을 작성할 때, 프론트엔드(웹 페이지나 앱)에서 백엔드 서버로 보내는 요청을 받아서 처리하는 부분

@PostMapping // HTTP POST 요청 처리
public ResponseEntity<BoardResponseDto> createBoard(
        @Valid @RequestBody BoardRequestDto boardRequestDto, // 요청 본문을 BoardRequestDto 객체로 매핑하고 유효성 검사 수행
        @AuthenticationPrincipal UserDetails userDetails // 현재 인증된 사용자의 UserDetails 객체 주입
) {
    // 프로젝트의 UserDetails 구현체에서 사용자 ID(Long)를 String으로 반환한다고 가정합니다.
    Long userId = Long.parseLong(userDetails.getUsername()); // UserDetails에서 사용자 ID 가져와 Long으로 변환

    // BoardService의 createBoard 메소드 호출하여 게시글 생성 비즈니스 로직 수행
    BoardResponseDto createdBoard = boardService.createBoard(boardRequestDto, userId);

    // 생성된 게시글 정보(DTO)와 함께 HTTP 상태 코드 201 (Created) 반환
    return ResponseEntity.status(HttpStatus.CREATED).body(createdBoard);
}

게시글 작성 API : POST /api/v1/boards
@param boardRequestDto : 게시글 생성 요청 데이터 (JSON 형태)
@param userDetails : 인증된 사용자의 정보 (Spring Security 제공)
@return : 생성된 게시글 정보와 함께 HTTP 상태 코드 201 (Created) 반환
@throws ResourceNotFoundException : Space (공간) 또는 Host (공간 공유자)를 찾을 수 없을 때 발생
@throws AccessDeniedException : 사용자가 호스트가 아니거나 권한이 없을 때 발생
@PostMapping 클라이언트(ex. 웹 브라우저)가 /api/v1/boards 라는 주소로
새로운 데이터를 생성해달라는 요청을 보낼 때, 이 createBoard 메소드가 실행
public ResponseEntity<BoardResponseDto> createBoard(...)
: 반환 타입이 ResponseEntity<BoardResponseDto>인 객체로
Spring에서 HTTP 응답을 유연하게 다룰 수 있게 해주는 객체
응답 본문(BoardResponseDto)과 HTTP 상태 코드(ex. 성공 201, 에러 400 등)을 함께 보낼 수 있음
BoardResponseDto
: 게시글 생성 요청이 성공했을 때, 클라이언트에게 돌려줄 게시글 정보를 담는 데이터 형태(DTO)
@Valid
: BoardRequestDto 객체에 설정된 유효성 검사 규칙(ex. 제목은 비어있으면 안됨)을 자동으로 실행해주는 어노테이션
만약 유효성 검사에 실패하면 Spring이 에러 응답을 자동으로 보내 메소드 내부에서 별도로 검사할 필요가 없음
@RequestBody
: 클라이언트가 HTTP 요청의 본문(body)에 담아 보낸 데이터를 BoardRequestDto 객체로 자동으로 변환(매핑) 후 boardRequestDto 변수에 넣음
(ex. 클라이언트가 JSON 형태로 게시글 제목, 내용 등을 보내면 Spring이 BoardRequestDto 객체로 만들어줌)
@AuthenticationPrincipal UserDetails userDetails
- @AuthenticationPrincipal : Spring Security를 통해 현재 로그인(인증)된 사용자의 정보를 가져와서
userDetails 변수에 넣어주는 어노테이션
UserDetails
: Spring Security에서 사용자 정보를 나타내는 표준 인터페이스
객체 안에 로그인한 사용자의 아이디, 비밀번호, 권한 등의 정보가 담김
Long userId = Long.parseLong(userDetails.getUsername());:
- userDetails.getUsername(): UserDetails 객체에서 사용자의 식별자(ex. 아이디 / 이메일)를 문자열(String) 형태로 가져옴
- Long.parseLong(...): 가져온 문자열 형태의 사용자 ID를 숫자(Long) 타입으로 변환
- 현재 게시글을 작성하려는 사용자의 ID를 userId 변수에 저장
BoardResponseDto createdBoard = boardService.createBoard(boardRequestDto, userId);:
실제로 게시글을 데이터베이스에 저장하고 비즈니스 로직을 처리하는 부분은 BoardService라는 다른 클래스에 위임

- boardService.createBoard() 메소드 호출
: 클라이언트로부터 받은 게시글 정보(boardRequestDto)와 현재 로그인한 사용자의 ID(userId)를 넘김

- BoardService에서 게시글을 성공적으로 생성하면, 그 결과를 BoardResponseDto 형태로 받아 createdBoard 변수에 저장
return ResponseEntity.status(HttpStatus.CREATED).body(createdBoard);:
- 게시글 생성 비즈니스 로직이 성공적으로 완료되면, 클라이언트에게 응답을 반환

- ResponseEntity.status(HttpStatus.CREATED): HTTP 상태 코드를 201 (Created, 생성됨)으로 설정
(새 데이터가 성공적으로 생성되었음을 의미하는 표준 상태 코드)
.body(createdBoard):
- 응답 본문에 BoardService로부터 받은 createdBoard 객체(생성된 게시글 정보)를 담아서 보냄

정리 :

클라이언트로부터 새 게시글 작성 요청(POST)이 오면, 요청 본문에 담긴 게시글 정보와 현재 로그인한 사용자의 정보를 받아서, Service 계층에 게시글 생성을 요청하고, 서비스에서 성공적으로 게시글을 만들면 생성된 게시글 정보와 함께 '생성됨(201)' 상태 코드를 클라이언트에게 응답으로 돌려주는 역할을 하는 메소드

❓AWS S3에서의 이미지 업로드 방식 차이점

2가지 방식 : Multipart vs Presigned URL

1. Multipart 이미지 업로드 (클라이언트 ➡️ 서버 ➡️ S3)

동작 방식
1) 클라이언트(ex. 브라우저) 이미지 파일을 HTTP 요청의 본문(multipart/form-data)에 담아
2) 애플리케이션 서버로 보냄
3) 서버는 이 파일을 받아 S3 SDK를 사용하여 S3 버킷으로 업로드
장점
- 구현이 간단함 (클라이언트 쪽에서는 일반적인 파일 업로드 요청만 보내면 되는 구조)
- 서버에서 파일 내용을 직접 처리하므로 업로드 전 서버에서 추가적인 유효성 검사/가공(ex. 리사이징, 워터마크 추가)이 용이
단점
- 대용량 파일이나 많은 수의 파일이 동시에 업로드될 경우, 서버가 파일 데이터를 직접 처리 및 S3로 전송하므로 서버 부하 증가
➡️서버의 확장성(Scalability)에 병목 가능성

- (클라이언트 ➡️ 서버, 서버 ➡️ S3) 처럼 두단계이므로 업로드 시간이 길어질 수 있음

- 서버에 AWS 인증 정보가 필요

2. Presigned S3 이미지 업로드 (클라이언트 ➡️ S3 직접)

동작 방식
1) 클라이언트가 파일 자체를 서버로 보내지 않고 (올릴 수 있는 권한이 담긴 임시 URL)을 요청
2) 서버는 그 요청을 받아 S3 SDK를 사용하여 특정 버킷의 특정 경로에 파일을 업로드할 수 있는 Presigned URL을 생성
3) 클라이언트는 응답받은 이 Presigned URL을 사용하여 S3 버킷에 파일을 직접 업로드
장점
- 서버가 파일 데이터를 직접 처리하지 않고 Presigned URL만 생성해주므로, 서버 부하없이 효율적
- 대용량 파일 업로드나 트래픽이 많은 상황에서의 서버 확장성에 용이
- 업로드 시간이 단축 (클라이언트 ➡️ S3 한 단계)
- 클라이언트는 AWS 인증 정보 없이 서버로부터 받은 Presigned URL만으로 안전하게 S3에 접근 가능
- 임시 URL에 제한된 권한과 유효 기간 설정이 가능해 보안성이 높음
단점
- 클라이언트 쪽에서 Presigned URL을 받아 S3에 직접 업로드하는 로직 구현이 필요
- 업로드 전 서버에서 파일 내용을 기반으로 하는 유효성 검사나 가공이 어려움
➡️가공을 위해서는 업로드 후 S3 이벤트 처리

정리 :

- 큰 규모의 서비스 및 대용량 파일 업로드나 높은 트래픽이 예상된다면 Presigned S3 이미지 업로드 방식

- 개발 초기 단계이거나 파일 크기가 작고 트래픽이 많지 않다면, 구현이 간단한 Multipart 이미지 업로드 방식으로 시작 후
서비스 규모가 커지면 Presigned URL 방식으로 전환

- 블로그 서비스처럼 사용자가 직접 이미지를 업로드하는 경우, Presigned URL 방식도 가능

✅만약 LoCo 프로젝트에 적용한다면 소규모의 회원이 이용하는 프로젝트이므로
호스트가 공간 정보 등록/수정 시에만 이미지를 업로드하게 됨

✅이럴경우 구현이 더 간단한 Multipart 이미지 업로드 방식을 선택하는 것도 방법

LoCo 프로젝트 - S3 Multipart 기술 도입 테스트

호스트 게시판에 이미지 도입

버킷 이름이과 S3 객체 키 (data/image/abc-123.jpg)를 통해 이미지의 접근을 공개로 허용한 경우에는
이미지 URL이
https://버킷이름.s3.ap-northeast-2.amazonaws.com/data/image/abc-123.jpg
와 같은 형태
클라이언트는 이 URL을 사용하여 이미지를 로드

액터 (Actor)

웹 애플리케이션 개발에서 현재 요청을 수행하는 사용자(Actor)와 관련된 정보를 캡슐화하여 편리하게 사용하기 위한 패턴
(ex. User Rq)
Rq (Request): 웹 요청 자체
User Rq: 현재 웹 요청을 보내고 있는 사용자(User)와 관련된 정보를 담고 있는 객체
액터 (Actor): 시스템과 상호작용하는 주체 (ex. 현재 로그인하여 요청을 보내는 사용자)

액터 패턴의 목적

컨트롤러나 서비스 메소드를 개발할 때,
현재 요청을 보낸 사용자가 누구인지, 어떤 권한을 가지고 있는지, 해당 사용자의 ID는 무엇인지 등의 정보가 자주 필요
이러한 사용자 정보를 얻기 위해 매번
@AuthenticationPrincipal UserDetails userDetails를 메소드 인자로 받거나, SecurityContextHolder.getContext().getAuthentication().getPrincipal()와 같은 코드를 사용하는 것은
반복적이고 비효율적인 코드
"User Rq" 또는 "액터" 객체 도입 시 이 객체 하나만 주입받거나 접근하여 현재 사용자의 모든 관련 정보를 쉽게 얻을 수 있음

// 기존 방식 (UserDetails 사용)
public ResponseEntity<?> createBoard(@Valid @RequestBody BoardRequestDto boardRequestDto, @AuthenticationPrincipal UserDetails userDetails) {
    Long userId = Long.parseLong(userDetails.getUsername()); // UserDetails에서 ID 가져와 변환
    // ... 비즈니스 로직 ...
}

// User Rq / Actor 객체 사용 방식 (예시)
public ResponseEntity<?> createBoard(@Valid @RequestBody BoardRequestDto boardRequestDto, RqUser rqUser) { // RqUser 객체 주입
    Long userId = rqUser.getUserId(); // RqUser에서 사용자 ID 바로 가져옴
    boolean isHost = rqUser.isHost(); // RqUser에서 권한 확인
    User currentUser = rqUser.getUser(); // RqUser에서 User 엔티티 가져옴 (구현 방식에 따라 다름)
    // ... 비즈니스 로직 ...
}

액터 패턴의 장점

- 코드 간결화 : 컨트롤러 및 서비스 메소드가 간결해짐, 사용자 정보를 얻는 코드가 반복되지 않아 효율적
- 정보 캡슐화 : 사용자 ID, 권한, 심지어 연관된 User 엔티티 객체까지 하나의 객체에 담아 관리 가능
- 유지보수 용이성: 사용자 정보를 가져오는 로직이 변경되어도 "User Rq" 객체 내부만 수정

액터 패턴의 단점

- 초기 구현 비용 : "User Rq" 객체를 정의하고, 요청 스코프 빈으로 등록하거나
Spring MVC의 Argument Resolver를 구현하여 컨트롤러 메소드 인자로 주입되도록 설정하는 초기 작업이 필요

- 추상화 레이어 추가 : 시스템에 새로운 객체가 추가되므로 낯선 구조가 될 수 있음

액터 패턴의 도입 가능성 (LoCo 프로젝트)

게시글 작성은 호스트만 가능
공간 등록/수정은 해당 공간의 호스트만 가능
예약 확인은 게스트와 호스트 모두 관련 예약에 대해서만 가능
관리자 기능은 관리자만 접근 가능

- 이처럼 사용자 역할과 권한에 기반한 로직이 많을 경우
현재 요청을 수행하는 사용자의 정보를 중앙에서 관리하고 쉽게 접근할 수 있는 "User Rq" 또는 "액터" 객체 패턴을 도입하여
코드의 가독성과 유지보수성을 향상 가능

- 특히 @AuthenticationPrincipal UserDetails userDetails에서
userId를 Long.parseLong(userDetails.getUsername()) 형태로 변환하는 과정이 반복되는 것을 줄이고,
사용자 역할(GUEST, HOST, ADMIN)을 확인하는 헬퍼 메소드(rqUser.isHost(), rqUser.isAdmin()) 등을
객체 내에 포함시켜 편리하게 사용 가능

정리 :

아직 프로젝트 규모가 작고 사용자 역할 구분이 단순하다면 필수는 아닐 수 있지만 사용자 역할이 나뉘고 권한 관리가 필요한 서비스에서는 "User Rq" 또는 "액터" 객체 패턴 도입을 생각해볼 수는 있음

회고 결과 :

Github Project로 템플릿을 작성하여 개발일지 및 이슈사항에 대해 팀원들과 공유할 수 있는 환경을 만들 수 있었음

게시판을 개발하기 위한 Board 엔티티에 관련해 Controller, Repository, Service 등 구현을 할 수 있었음

이미지 업로드를 위한 AWS S3 기술에 대해 공부해볼 수 있었음

[멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_102일차_"Git 협업 및 CI 구축"

LEFT — Thu, 6 Nov 2025 21:03:50 +0900

멋쟁이사자처럼 백엔드 부트캠프 13기
TIL 회고 - [102]일차

102일차에는 Git 협업과 관련해 히스토리를 남기는 것과 브랜치 관리에 대해 배움 (2025.05.09)

Git 추적 파일 지우기

git에 원치않게 추적되고 있는 파일 지우기

git rm -r --cached .
git add .
git commit -m "gitignore 적용"
git push origin main

팀원들이 이 상태에서 다시 pull을 받으면 사라진 상태에서 최신화가 되므로 사라진 상태가 원격 브랜치에 적용되어있을 것

브랜치 생성 및 이동

1. 브랜치를 만들면서 바로 이동하는 방법

git checkout -b enhancement/#1

2. 브랜치를 먼저 생성 후 checkout으로 이동하는 방법

git branch enhancement/#1
git checkout enhancement/#1

git log

커밋 확인하는 방법의 명령어

위 Log에서 표시된 "HEAD →" 의 의미는 현재 가리키고 있는 브랜치를 의미
그 뒤 "develop" 은 어느 원격 브랜치와 연결되어있는지를 표시
⭐HEAD 부분이 중요 (현재 로컬에서 어딜 가리키는지 중요)

협업에서의 코드 리뷰 및 Merge 과정

1) 개발: 팀원은 develop 브랜치에서 분기한 자신의 기능 브랜치(ex. feature/기능명 또는 feature/#이슈번호)를 생성

2) 개별 브랜치에서 기능을 개발하고 커밋

3) 푸시: 기능 개발이 완료된 후

 git push origin feature/기능명

자신의 기능 브랜치를 원격 저장소에 푸시

4) Pull Request 생성: GitHub에서 자신의 기능 브랜치(feature/기능명)를 develop 브랜치로 병합하겠다는 Pull Request 생성

5) 자동화된 확인 (CI/CD): PR이 생성되면 설정된 CI 워크플로우가 자동으로 코드 빌드, 테스트, 린트 검사 등 수행
결과는 PR 페이지에 상태 체크(Status Checks) 로 표시

6) 코드 리뷰 (동료 검토): 팀원들이 해당 PR 페이지에서 코드 변경 내역을 확인하고 리뷰 댓글을 남기거나 수정 사항을 제안
필요한 경우 코드를 로컬로 가져와 테스트

7) 수정 및 업데이트: 리뷰를 통해 수정 요청이 있으면, 개발자는 로컬 기능 브랜치에서 코드를 수정하고 커밋한 후 다시 푸시
푸시하면 PR이 자동으로 업데이트되고, 자동화된 확인(CI)이 다시 실행

8) 승인 (Approval): 코드에 문제가 없고 리뷰어들의 요청 사항이 반영되었다면, 리뷰어들은 PR에 'Approve' 승인 클릭

9) 병합 조건 충족: Ruleset에 설정된 모든 병합 조건 (ex. 최소 승인 수 충족 (4명 이상), 모든 상태 체크 통과 등)이 충족
⚠️팀장의 경우 Bypass 권한을 설정하여 승인 수와 상관없이 바로 병합 가능

10) 병합 (Merge): 병합 조건을 만족하거나, Bypass 권한이 있는 사용자(ex. 팀장)가 'Merge pull request' 버튼을 클릭

11) 브랜치 정리: 병합이 완료되면 기능 브랜치는 더 이상 필요 없으므로 삭제
(GitHub 설정에서 PR 병합 시 자동으로 기능 브랜치 삭제 옵션을 켤 수도 있음

결론 : [기능 브랜치 푸시] -> [PR 생성] -> [자동 검증(CI)] + [동료 리뷰] -> [승인] -> [조건 충족 시 병합] 순으로 진행

로컬에서 직접 코드 리뷰

팀원의 기능개발 코드를 로컬로 가져와서 직접 테스트
해당 팀원의 기능 브랜치를 가져옴

# 기능 브랜치 : feature/#5

# 1. 원격의 최신 정보를 가져옴 (각자의 환경에서 생성되었던 브랜치가 가져와짐)
git fetch origin

# 2. 해당 팀원이 생성했던 기능 브랜치로 이동
git checkout feautre/#5

이렇게 checkout을 해보면 해당 팀원이 작성했던 코드의 브랜치로 이동하여 본인의 환경에서 로컬로 테스트할 수 있음

CI 구축하기

https://aistudio.google.com/

Google AI Studio

The fastest path from prompt to production with Gemini

aistudio.google.com

구글 AI 스튜디오 접속 후 에서 API Key 발급받기

발급받은 Google AI Studio API Key를 기억해놓기 (⚠️클라우드 저장 금지)
Settings > Secrets and variables > Actions > "New repository secret" 버튼 클릭
이처럼 Github에 적절한 이름으로 API Key를 추가

코드리뷰 CI 파일 등록

.github/workflows/gemini-code-review.yml

name: Gemini Code Review

on:
  push:
    branches: [ feature/gemini ]
    paths:
      - 'backend/**'
  pull_request:
    types: [opened, synchronize]

jobs:
  code-review:
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3
        with:
          fetch-depth: 0

      - name: Set up Node
        uses: actions/setup-node@v3

      - name: Install GoogleGenerativeAI
        run: |
          npm install @google/generative-ai

      # PR 이벤트에서의 변경사항 처리
      - name: Get git diff for PR
        if: github.event_name == 'pull_request'
        run: |
          git fetch origin "${{ github.event.pull_request.base.ref }}"
          git fetch origin "${{ github.event.pull_request.head.ref }}"
          git diff --unified=0 "origin/${{ github.event.pull_request.base.ref }}" > "diff.txt"
          echo "EVENT_TYPE=pull_request" >> $GITHUB_ENV

      # Push 이벤트에서의 변경사항 처리
      - name: Get git diff for Push
        if: github.event_name == 'push'
        run: |
          git diff --unified=0 HEAD^ HEAD > "diff.txt"
          echo "EVENT_TYPE=push" >> $GITHUB_ENV

      # Gemini를 사용한 코드 분석
      - name: Run Gemini-1.5-flash
        id: gemini_review
        uses: actions/github-script@v7
        with:
          script: |
            const fs = require("fs");
            const diff_output = fs.readFileSync("diff.txt",'utf8');
            
            const { GoogleGenerativeAI } = require("@google/generative-ai");
            const genAI = new GoogleGenerativeAI("${{ secrets.GEMINI_API_KEY }}");
            const model = genAI.getGenerativeModel({ model: "gemini-1.5-flash"});
            
            // PR과 Push에 따라 다른 프롬프트 사용
            let prompt;
            if (process.env.EVENT_TYPE === 'pull_request') {
              prompt = `Explain in korean. You are a senior software engineer and need to perform a code review based on the results of a given git diff. Review the changed code from different perspectives and let us know if there are any changes that need to be made. If you see any code that needs to be fixed in the result of the git diff, you need to calculate the exact line number by referring to the "@@ -0,0 +0,0 @@" part. The output format is \[{"path":"{ filepath }", "line": { line }, "text": { review comment }, "side": "RIGHT"}\] format must be respected.\n<git diff>${diff_output}</git diff>`;
            } else {
              prompt = `Explain in korean. You are a senior software engineer and need to perform a code review based on the results of a given git diff. Provide a detailed review of the code changes, focusing on code quality, readability, performance, and security. Format your response in Markdown with clear headings for each file reviewed.\n<git diff>${diff_output}</git diff>`;
            }
            
            const result = await model.generateContent(prompt);
            const response = await result.response;
            const text = response.text();
            
            fs.writeFileSync('review_result.txt', text);
            console.log('Review results saved!');

      # PR 이벤트: 라인별 리뷰 코멘트 추가
      - name: Format and add PR review comments
        if: env.EVENT_TYPE == 'pull_request'
        id: store
        run: |
          COMMENT=$(sed '/^```/d' review_result.txt | jq -c .)
          echo "comment=$COMMENT" >> $GITHUB_OUTPUT

      - name: Add Pull Request Review Comment
        if: env.EVENT_TYPE == 'pull_request'
        uses: nbaztec/add-pr-review-comment@v1.0.7
        with:
          comments: ${{ steps.store.outputs.comment }}
          repo-token: ${{ secrets.GITHUB_TOKEN }}
          repo-token-user-login: 'github-actions[bot]'
          allow-repeats: false

      # Push 이벤트: 액션 로그에 리뷰 결과 출력 및 아티팩트 업로드
      - name: Display review results in workflow log
        if: env.EVENT_TYPE == 'push'
        run: |
          echo "===== Gemini Code Review Results ====="
          cat review_result.txt
          echo "======================================"

      - name: Upload review results as artifact
        if: env.EVENT_TYPE == 'push'
        uses: actions/upload-artifact@v4
        with:
          name: gemini-code-review
          path: review_result.txt

회고 결과 :

코드리뷰 과정을 협업을 통해 직접 경험해보고 팀원들과 적절한 규칙 및 기능 개발 분담을 수행해볼 수 있었음

CI 구축에 대해 더 공부해봐야겠다는 생각을 함

[멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_101일차_"2차 팀 프로젝트 : 공유 공간 매칭"

LEFT — Tue, 19 Aug 2025 17:55:37 +0900

멋쟁이사자처럼 백엔드 부트캠프 13기
TIL 회고 - [101]일차

101일차에는 프로젝트의 방향성을 확정하고 그 프로젝트에 맞게 기획서 및 정의서, ERD 설계 방법을 배움 (2025.05.08)

프로젝트명은 LoCo 프로젝트 - Location (공간) + Connect (연결)로 확정.

"공간을 잇고, 가치를 나누다"
도심 속 유휴 공간과 이를 필요로 하는 사용자들을 매칭하는 공간 기반 공유 서비스

ERD 수정내역 (v1 -> v2)

[기존] LoCo_ERD_v1

[개선] LoCo_ERD_v2

ERD 플랫폼 변경

ERDCloud.com ➡️ dbdiagram.io

서비스 배포에 사용되는 기술

주로 프론트엔드 Vercel
백엔드 AWS EC2 등 사용

프론트엔드 배포 기술

Vercel: Next.js 개발팀이 만든 서비스로, Next.js 프로젝트 배포에 최적화
➡️서버리스 함수, 자동 스케일링 등을 편리하게 사용
Netlify: Vercel과 유사하게 프론트엔드 배포에 특화된 서비스
➡️정적 사이트, SPA, 서버리스 기능 등을 지원
AWS S3 + CloudFront: 정적 웹사이트 호스팅에 적합
➡️S3에 빌드된 파일을 올리고 CloudFront를 통해 CDN(Content Delivery Network)을 구성하여 빠르게 서비스
AWS Amplify: 프론트엔드 및 모바일 앱 개발/배포를 위한 통합 서비스
➡️CI/CD, 백엔드 기능(인증, API 등) 연동까지 편리하게 지원
AWS EC2 또는 컨테이너 서비스 (ECS, EKS): 전통적인 서버 방식
➡️EC2 인스턴스에 직접 Node.js 환경을 설정하고 Next.js 앱을 실행하거나, Docker 컨테이너화하여 ECS나 EKS에 배포 ➡️Vercel이나 Netlify보다 설정 및 관리가 복잡하지만, 더 많은 제어권을 가짐

백엔드 배포 기술

Spring Boot와 관련하여 백엔드 애플리케이션은 AWS EC2 외에도 다른 옵션들도 존재

AWS EC2: 가장 기본적인 가상 서버 인스턴스
➡️OS를 선택하고 직접 미들웨어(Java, Spring Boot 등)를 설치하여 애플리케이션을 실행
AWS Elastic Beanstalk: 웹 애플리케이션 배포 및 관리를 자동화해주는 서비스
➡️코드만 올리면 환경 설정, 로드 밸런싱, 오토 스케일링 등을 자동으로 처리, EC2 위에 추상화된 형태
AWS ECS (Elastic Container Service): 도커 컨테이너를 관리하고 배포하는 서비스
➡️EC2 인스턴스 클러스터 위에서 도커 컨테이너를 실행
AWS EKS (Elastic Kubernetes Service): AWS에서 제공하는 관리형 쿠버네티스 서비스
➡️쿠버네티스 클러스터를 쉽게 구축하고 관리할 수 있으며, 대규모 컨테이너화된 애플리케이션 배포 및 관리에 용이
AWS Lambda: 서버리스 함수 서비스
➡️짧게 실행되는 백엔드 로직을 함수 형태로 배포하고, 요청이 있을 때만 실행되어 비용이 효율적
Spring Boot 애플리케이션 전체를 Lambda로 배포하기에는 구조 변경 필요

❓백엔드 AWS EC2 배포 시 도커/쿠버네티스(무중단배포) 사용은 필수적인지

AWS EC2에 백엔드 애플리케이션을 배포할 때 도커나 쿠버네티스를 반드시 사용해야 하는 것은 아님

도커나 쿠버네티스를 사용하지 않을때는 EC2 인스턴스에 접속하여 직접 Java, Spring Boot 실행 환경을 설치하고,
빌드된 Spring Boot JAR 또는 WAR 파일을 업로드하여 java -jar your-app.jar 와 같은 명령어로 직접 실행
Nginx나 Apache와 같은 웹 서버를 앞에 두고 리버스 프록시 설정도 가능 ➡️기본적인 배포 형태

도커나 쿠버네티스를 사용할때는
➡️ 도커 사용 : 애플리케이션과 그 종속성을 컨테이너라는 독립적인 환경에 패키징하여 환경 일관성을 확보하고 배포를 표준화 가능, 여러 애플리케이션을 하나의 서버에 배포할 때 충돌을 방지하는데에 유용

➡️쿠버네티스: 도커와 같은 컨테이너화된 애플리케이션을 자동화된 방식으로 배포, 스케일링, 관리해주는 오케스트레이션 플랫폼
,여러 대의 서버(EC2 인스턴스 클러스터)에 걸쳐 애플리케이션을 효율적으로 분산시키고, 서비스 디스커버리, 로드 밸런싱, 자동 복구 등을 제공하여 안정성과 확장성을 향상

➡️소규모 프로젝트나 학습 목적으로는 EC2에 도커 없이 직접 배포하는 것도 가능하지만 프로젝트 규모가 커지고, 여러 대의 서버를 사용하며, 안정적인 운영과 확장이 중요해진다면 도커와 쿠버네티스를 사용하는 것이 권장

CI/CD (Continuous Integration / Continuous Deployment (or Delivery))

코드를 지속적으로 관리하고 배포하는 것의 약자
소프트웨어 개발 및 제공 과정을 자동화하여, 변경된 코드를 신속하고 빈번하게 테스트하고 프로덕션 환경에 배포하는 DevOps 방법론
'지속적 통합(CI)' : 여러 개발자의 코드를 자동으로 병합하고 검증
'지속적 배포(CD)' : 테스트가 완료된 코드를 자동으로 운영 환경에 릴리스하는 과정을 포함
때때로 '지속적인 제공'이라는 의미로 'Continuous Delivery' 라고 씀

Tailwind CSS

미리 정의된 유틸리티(Utility) 클래스들을 사용하여 HTML 코드 내에서 직접 스타일을 적용할 수 있게 해주는 CSS 프레임워크

이처럼 클래스명에 스타일을 정의하는 방법을 “테일윈드 tailwind” 기법

ex. grid, grid-rows, items-center ...

목적 :
- Tailwind는 특히 디자인 시스템을 빠르게 구축하거나, UI를 유연하게 커스터마이징해야 하는 프론트엔드 프로젝트에서 많이 사용
- 복잡한 UI를 직접 구현해야 할 때나, 기존의 컴포넌트 라이브러리 디자인이 마음에 들지 않을 때 유용
- CSS 파일을 관리하는 대신, HTML 파일에서 직접 스타일을 제어하여 개발 속도와 생산성을 크게 향상

CSS 프레임워크와 Tailwind CSS의 차이점

➡️일반적인 CSS 프레임워크(ex. Bootstrap)가 미리 만들어진 컴포넌트(버튼, 카드 등)를 제공하는 것과 달리,

➡️ Tailwind CSS는 flex, pt-4, text-center, bg-blue-500과 같은 원자 단위의 CSS 클래스를 제공
또한 Tailwind CSS는 CSS 파일을 직접 작성하는 대신, HTML 클래스 속성 안에 유틸리티 클래스들을 나열하는 방식으로 사용

1. HTML + 일반 CSS 방식

<!DOCTYPE html>
<html>
<head>
    <link rel="stylesheet" href="style.css">
</head>
<body>
    <button class="my-button">버튼</button>
</body>
</html>

.my-button {
  display: flex;
  align-items: center;
  justify-content: center;
  padding: 1rem 2rem;
  border-radius: 0.5rem;
  background-color: #3b82f6;
  color: #ffffff;
  font-size: 1rem;
}

2. Tailwind CSS 사용

<!DOCTYPE html>
<html>
<head>
    <script src="https://cdn.tailwindcss.com"></script>
</head>
<body>
    <button class="flex items-center justify-center p-4 rounded-lg bg-blue-500 text-white text-base">
        버튼
    </button>
</body>
</html>

button class = "flex items-center..." 처럼 사용

Git에서 일반 Merge와 Squash Merge의 차이점

️일반 Merge의 Git Flow

Normal Merge

1. main 브랜치의 흐름에서 기능을 개발할 feature/#1 브랜치를 생성

2. feature/#1 의 커밋 내역들 F1, F2, F3, F3(수정) 등 이 각각 존재

2-1) 예를들어
feature/#1 브랜치에서 첫번째 기능을 개발 (F1) - 첫번째 커밋 : "feat: add a button" = 버튼 추가
두번째 기능을 개발 (F2) - 두번째 커밋 : "fix: fix button style" = 버튼 스타일 수정
세번째 기능을 개발 (F3) - 세번째 커밋 : "refactor: modify button logic: = 버튼 로직 정리

3. 이제 이 F1, F2, F3 기능 개발한 것들이 feature/#1 브랜치에서는 내역이 실려있는데 main 브랜치에는 반영이 되지 않은 상태

4. 이 경우 Pull Request를 통해 feature/#1 브랜치의 작업 내역을 main 브랜치에 병합해도되는지에 대한 요청

5. 이 PR (Pull Request)가 승인되면 일반 Merge가 실행되는데 이때 main 브랜치에 Merge Commmit (M4)가 새로 생성되는 흐름

장점 : 개발 과정의 완전한 기록과 원본 브랜치 복원 용이
단점 : 히스토리가 복잡해지고 불필요한 커밋이 많아질 수 있음

️SquashMerge의 Git Flow

feature/#1의 각각의 커밋내역들이 하나로 뭉쳐져서 병합되는 것이 Squash Merge
Squash Merge의 장점은 깔끔해지는 것
feature/#1 같은 브랜치는 “하나의 기능”을 커밋한 것이기때문에 하나로 합쳐서 병합하는 것이 좋다고 느낄때 사용

Squash Merge

1. 브랜치 생성 및 작업: feature/#1 브랜치가 main 브랜치에서 생성되고, 그 위에서 F1, F2, F3 커밋이 순차적으로 발생
(공통점 : 일반 Merge와 동일한 브랜치 생성 및 작업)

2. Pull Request (PR): 작업 완료 후 PR을 생성하여 통합을 요청

3. Squash Merge: PR이 승인되고 Squash Merge가 실행
- feature/#1의 모든 커밋 F1, F2, F3이 하나의 새로운 커밋 S1으로 통합
- 이후 이 단일 커밋 S1이 main 브랜치에 추가

4. 히스토리 결과: main 브랜치의 히스토리에는 F1, F2, F3의 개별 흔적 없이, 오직 하나의 깔끔한 커밋 S1만 남음
(차이점 : Merge Commit이 생성되지 않음. (단일 커밋으로 처리))

장점 : main 브랜치 히스토리가 깔끔하고 이해하기 쉬움
단점 : 세부 작업 과정을 잃어버리고 원본 브랜치 히스토리가 main 브랜치와 분리됨

❓일반 Merge vs Squash Merge 명령어 비교

구분	일반 (Standard) Merge	Squash Merge
명령어	git merge <브랜치명>	git merge --squash <브랜치명>
결과	Merge Commit 생성	변경 사항이 Staged 상태로 들어옴
커밋 필요 여부	자동으로 커밋됨 (별도 git commit 불필요)	수동으로 커밋해야 함 (필수)
히스토리	feature 브랜치의 모든 커밋을 남기고 Merge Commit 추가	feature 브랜치 커밋들을 하나로 합쳐 새 커밋으로 추가

일반 Merge 로직

# main 브랜치로 이동
git checkout main

# feature 브랜치를 main에 병합 (Merge Commit 자동 생성)
git merge feature/#1

Squash Merge 로직

# main 브랜치로 이동
git checkout main

# feature 브랜치의 모든 변경사항을 하나의 작업으로 가져와 Staged 상태로 만듦
git merge --squash feature/#1

# 수동으로 커밋 (이 때 하나의 커밋이 생성됨)
git commit -m "feat: feature/#1 커밋이 Squash Merge"

main 브랜치의 히스토리는 '누가', '어떤 기능'을 넣었는지에 대한 '요약'만으로 충분
복잡한 개발 과정의 세부 내용은 해당 PR 페이지나 feature 브랜치에 남겨두고,
main 브랜치는 오직 중요한 기능 단위로만 깔끔하게 기록

결론 :
- 오픈 소스 프로젝트, 라이브러리에서는 Squash Merge 또는 Rebase Merge가 선호
>> main 브랜치의 히스토리를 깔끔하고 선형적으로 유지하여 추적에 용이

- 규모가 크고 복잡한 엔터프라이즈 앱에서는 일반 Merge (Merge Commit)가 선호
>> 특정 릴리스 브랜치나 버그 픽스의 병합 시점 자체를 중요하게 기록하고, 히스토리의 완전한 복원이 필수적일 때 사용

Rebase Merge

GitHub에서 제공하는 'Rebase and Merge' 옵션을 사용하여 main 브랜치에 통합이 가능
(자동으로 Rebase를 처리하고 Fast-forward Merge를 수행)

Rebase Merge

feature/#1 브랜치 커밋들 F1, F2, F3을 main 브랜치의 최신 커밋 M4 위에 재배치(Rebase)
이 과정에서 새로운 커밋 ID를 가진 커밋들 F1', F2', F3'이 생성
이후 main 브랜치는 Fast-forward 방식으로 통합되어 선형 히스토리를 만듦

Rebase Merge 로직

# 1. 브랜치 이동 후 Rebase
git checkout feature/#1

git rebase main

# 2. 병합 (Merge) - Fast-forward
git checkout main
git merge feature/#1

결과
- main 브랜치의 끝에 feature 브랜치의 모든 커밋(F1', F2', F3')이 합쳐짐
- Merge 단계에서 자동으로 커밋 (Fast-forward)
- Merge Commit 없이, feature의 모든 커밋이 선형적으로 이어진 히스토리

장점 : 선형 히스토리의 장점과 세부 커밋 보존의 장점을 모두 갖추고 있어, 핵심 브랜치(main/master) 통합 전략으로 매우 선호
단점 :
- Rebase 시 커밋 ID가 모두 바뀌어, 이미 원격 저장소에 푸시된 브랜치에 적용하면 협업자들에게 심각한 문제 야기
- 충돌 해결의 어려움: 병합 시 발생할 충돌을 각 커밋이 Rebase될 때마다 해결해야 함

⚠️주의사항 :
- 이미 다른 사람이 작업하는 공용 브랜치에 로컬 git rebase 명령 직접 사용하지 않기
- PR단계에서 Github 플랫폼의 기능을 이용하는 방식 권장

❓Squash Merge vs Rebase Merge

특징	Squash Merge	Rebase Merge
최종 커밋 개수	단 하나의 커밋 (압축/요약)	원본 커밋 개수 (F1′,F2′,F3′)
히스토리 형태	선형적 (하나의 커밋으로 인해)	선형적 (모든 커밋이 순차적으로 이어짐)
원본 커밋 보존	main 브랜치에서 사라짐 (단일 커밋으로 요약)	main 브랜치에서 보존됨 (새 ID로 재생성)
커밋 ID 변경	새로운 단일 커밋 ID 생성	Rebase 시 모든 커밋 ID가 변경됨

git fetch

로컬(IDE 환경)에서 원격 환경(GitHub 등)의 최신 변경 사항을 확인하고 비교하는 데 사용되는 핵심 명령어
즉 로컬 저장소를 훼손하지 않고 원격 저장소(origin 등)의 최신 정보를 조회하고 다운로드하는 명령어
(= 원격 저장소의 최신 브랜치, 커밋, 태그 등의 정보만 가져와서 로컬에 업데이트)
병합(Merge)기능이 아니므로 로컬 작업 공간(Working Directory)이나 로컬 브랜치의 내용은 전혀 변경되지 않음
git fetch를 실행하면, 로컬 저장소는 원격 저장소의 최신 상태를 알게되는 것

git fetch origin

명령어를 실행하게되면 로컬의 remotes/origin/main 브랜치가 GitHub의 main 브랜치 최신 커밋을 가리키게됨
로컬 IDE나 CLI 명령(git log, git status)을 통해 현재 작업 중인 로컬 브랜치와 원격의 최신 상태인 원격 추적 브랜치 간의
차이점(ex. 몇 개의 커밋이 뒤처져 있는지)을 쉽게 비교 가능

장점 : 병합 충돌이나 작업 내용 유실 없이 안전하게 최신 정보만 확인 가능

fetch --prune 옵션

git fetch --prune

원격에서만 지우고 로컬의 브랜치는 지우지 못했을때 원격의 지워진 브랜치를 로컬도 동기화시켜주는 기능 (로컬자동삭제)
즉 두 브랜치를 맞춰주는 명령어

❓git fetch vs git pull

명령어	기능	결과 (로컬 브랜치)
git fetch	가져오기만 수행 (정보 다운로드)	변경 없음 (origin/<branch>만 업데이트)
git pull	가져오기 + 병합 수행 (정보 다운로드 후 로컬 브랜치에 통합)	업데이트 및 변경 (원격 내용이 로컬 브랜치에 병합됨)

따라서 로컬 브랜치와 원격 브랜치의 작업을 비교/확인 하는 방법이 3가지

1. 최신 정보 확인만 수행

git fetch

2. 확인 후 로컬 브랜치에 병합

# (fetch + merge와 동일)
git pull

3. fetch 후 수동으로 병합 (안전한 통합)

git fetch
git merge origin/main # 또는 git rebase origin/main

git branch

브랜치 관련 역할을 수행할 수 있는 Git 명령어

git branch -D feature/#1

-D 옵션 : 브랜치 지우는 명령어

❓원격과 로컬의 브랜치를 맞춰주는 방법

1. 원격 브랜치가 삭제되었을때 로컬에서도 삭제하려면 (⭐권장)

 git fetch --prune

2. 원격 브랜치는 삭제하지 않았지만 로컬에서 로컬 브랜치 삭제 후 원격 저장소에 push하게되면

로컬에서 로컬 브랜치가 삭제된 것이 원격 저장소의 원격 브랜치에 반영

회고 결과 :

Git 명령어에 대해 흐름에 따라 공부하여 협업 환경에서의 원활한 프로젝트 구현에 도움이 될 수 있도록 노력했다.
git 명령어의 fetch, merge, pull, branch 등에 대해 개념을 제대로 이해하고 팀 프로젝트를 시작하는 것이 중요할 것 같았다.

[멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_100일차_"2차 팀 프로젝트 시작"

LEFT — Thu, 22 May 2025 19:53:51 +0900

멋쟁이사자처럼 백엔드 부트캠프 13기
TIL 회고 - [100]일차

100일차에는 LMS 시스템이나 PMS 시스템, 혹은 백오피스가 있는 서비스 중 하나를 2차 팀 프로젝트로 기획하는 과정을 회고로 작성해보고자 한다. (2025.05.07)

LMS (Learning Management System)

"학습 관리 시스템"
즉, 온라인 학습을 지원하고 관리하는 시스템을 가리킴
1차 프로젝트에서의 블로그 서비스는 누구나 접근하는 범용적 소프트웨어이지만
2차 프로젝트에서의 LMS는 시스템적이기때문에 기업적, 특정 그룹에서 사용하는 소프트웨어일 수 있다.
➡️혹은 [사용자 UI 부분 + 관리자 대시보드 부분]까지 개발
예를 들어보면
1) B2C (비즈니스 to 커스토머)
➡️ ex. 블로그 (백오피스까지 구현해야함)

2) B2B (기업적인 것)
➡️ ex. 물류관리시스템 (사용자에게 노출된 영역이 아님, 백오피스를 따로 만들필요없음, 관리시스템 자체가 백오피스)

ex. 교육 콘텐츠를 관리하고 학습자를 관리하는 시스템 (대표적으로 '구글 클래스룸')

회원가입 / 로그인 (학생, 관리자, 강사 등 권한 분리)
강의 등록 및 조회, 수강 신청
과제 / 시험 제출 및 채점
학습 이력 관리, 진도율 추적
관리자 페이지 (강좌 관리, 사용자 관리)

PMS (Project Management System)

프로젝트를 계획하고 관리하는 시스템

ex. 노션과 같은 일정 관리 시스템 (대표적으로 'Jira, Trello, Asana, Notion 등')

팀원 등록 / 역할 설정
프로젝트 생성 / 관리
작업(Task) 등록, 상태 변경 (예: 할당, 진행 중, 완료)
캘린더 / 간트 차트
커뮤니케이션 로그 / 코멘트 기능

백오피스(Back Office)

사용자가 직접 보지 않는 ‘관리자용 시스템’
ex.
- 사용자 관리
- 게시글 / 상품 / 주문 등 DB CRUD 인터페이스
- 통계 조회 (매출, 사용자 수, 클릭 수 등)
- 권한 관리
주로 Admin 페이지 형태로 구현되며, 서비스의 데이터를 내부적으로 운영하는 용도

✅ 주제 확정: 공유 로케이션 매칭 플랫폼

목적 : 공간이 필요한 사용자(게스트)와 공간을 제공하는 호스트를 매칭시켜주는 플랫폼
ex. Airbnb for studios / rooms / creators

주요 기능 예상

1. 사용자 (게스트) :
- 공간 검색 (지역, 시간, 타입 필터)
- 공간 예약 및 결제
- 리뷰 작성
- 예약 취소 및 환불

2. 공간 제공자 (호스트) :
- 공간 등록 (사진, 설명, 가격, 이용가능 시간)
- 예약 관리 (수락/거절)
- 수익 정산 내역 조회

사용자(게스트)	- 공간 검색 (지역, 시간, 타입 필터)- 공간 예약 및 결제- 리뷰 작성- 예약 취소 및 환불
공간 제공자(호스트)	- 공간 등록 (사진, 설명, 가격, 이용가능 시간)- 예약 관리 (수락/거절)- 수익 정산 내역 조회
관리자(Back Office)	- 사용자/호스트 관리- 공간 검수 승인/반려- 통계 관리 (예약 수, 정산 등)- 신고 관리 (리뷰, 사용자, 공간 신고 등)

추가할만한 기능 예상

카테고리 기반 공간 분류	연습실 / 촬영 / 회의실 / 파티룸 등
시간 단위 예약 (스케줄링 UI)	캘린더 기반 시간 선택 기능
결제 시스템 연동 (가상결제 or 모의)	결제 흐름 연습 or TossPayments 연동
찜 기능 / 즐겨찾기	자주 보는 공간을 따로 저장
공간 리뷰 및 평점 시스템	후기 기반 추천 구조
정산 기능 (호스트 기준 수익 정리)	호스트에게 월별 정산 내역 제공
알림 기능	예약 확정/취소/정산 안내 알림

관리자 기능은 status 속성들을 중심으로 구현 (승인/반려, 예약 상태, 리뷰 검토 등)

UI 구성 예상

[사용자 화면]
  - 홈 / 검색 / 공간 상세 / 예약
  - 마이페이지 (예약 목록, 후기 작성, 찜한 공간)

[호스트 화면]
  - 공간 등록 / 수정 / 예약 현황 확인
  - 수익 정산 페이지

[관리자 화면 (BackOffice)]
  - 공간 목록 (승인/반려)
  - 사용자 관리
  - 통계 (월 예약 수, 수익)
  - 신고 관리

프로젝트 관련 용어

용어 간단 설명 주로 누가 참여? 사용 빈도

Daily (Stand-up)	매일 15분 내외 진행 상황 공유 (어제, 오늘, 장애 여부)
Sprint Planning	이번 스프린트 동안 할 일 선정하고 분배
Sprint Review	스프린트 종료 후 개발한 기능 시연
Retrospective	회고. 잘한 점/개선점/다음 스프린트 개선 논의
Tech Talk	기술 지식 공유 발표 (자율 주제)
Demo	기능을 실제로 보여주는 시연. 내부 or 외부 대상

회고 결과 :

1차 팀프로젝트에서의 부족했던 점을 개선하여 2차 프로젝트에서도 기능 구현에 힘써야겠다고 생각했다.

프로젝트 주제를 선정할때 평소 숏폼 영상, 사진 촬영 스튜디오, 연습실, 회의 공간 등에 대한 서비스의 필요성을 느끼고 있었는데

이것들을 충족할 수 있는 공유 공간 매칭 플랫폼을 생각해내면서 프로젝트의 방향성을 잡을 수 있었다.

[멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_99일차_"1차 블로그 프로젝트 마무리"

LEFT — Thu, 22 May 2025 19:01:21 +0900

멋쟁이사자처럼 백엔드 부트캠프 13기
TIL 회고 - [99]일차

99일차에는 1차 프로젝트로 블로그 프로젝트를 개발하면서 팀프로젝트의 중요성과 각자의 업무분담을 깃허브에서 관리하는 방법, Git Branch 생성 및 이슈 관리 등에 대해 회고해보고자 한다. (2025.05.02)

모먼트리 블로그 저장소

GitHub - pickipi/momentree_blog: 멋쟁이사자처럼 백엔드 부트캠프 13기 1차프로젝트 결과 저장소입니다.

멋쟁이사자처럼 백엔드 부트캠프 13기 1차프로젝트 결과 저장소입니다. Contribute to pickipi/momentree_blog development by creating an account on GitHub.

github.com

시연 영상

1) 회원가입

2) 로그인 및 좋아요

3) 검색 및 좋아요

4) 마이페이지

5) 게시글 작성

6) 팔로우

프로젝트 개선점

개인적으로 느낀 개선점

1) 업무 분담의 불명확성

✅개선 방안

프로젝트 시작 전, 각 팀원의 역할과 책임(R&R)을 문서화
기능 단위로 작업을 나누고, 담당자와 마감 기한 지정
GitHub Issue/Project 보드를 활용하여 작업 추적 및 리뷰 주기 설정

2) 스프린트 및 일정 관리 부족

✅개선 방안

매주 or 격주 단위의 스프린트를 계획
매일 or 이틀에 한 번 미팅 (15분 이내)으로 진행 상황 공유

3) 기능 위주의 개발로 인한 구조적 한계

✅개선 방안 : 아키텍처 위주 설계

프로젝트 초반에 DB 설계, API 명세, 주요 클래스 다이어그램 등 기본 설계 문서 작성은 완료했지만
기초 구축 완료 후 기능 개발에 들어가는 단계적 개발 전략이 부족했음
PR 시 설계 방향과 일치 여부 확인하는 리뷰 기준 마련 (ex. Comment 작성 및 PR 승인 인원 수 제한)

4) 시간 부족으로 인한 기능 미완성

✅개선 방안 : MVP 우선 개발 전략

꼭 필요한 기능부터 우선 구현하는 MVP(Minimum Viable Product) 전략 적용
➡️요구사항 정의서를 통해 MVP (상, 중, 하)로 나누고 개발을 진행했지만 핵심 기능들에서 오류가 발생했던 문제
중간 점검을 위한 데모 일정 확보
➡️일정 초과 방지

팀원들이 느낀 개선점

1) 이슈 사항들 (Issues)

게시글 저장 때 시간이 다른 시간대
회원 수정 시에 수정이 되면 다시 입력란에 빈 칸이 되는 문제
팔로우 하면 새로고침하기 전에는 언팔로우도 가능하지만, 새로고침하면 언팔로우 대신 팔로우로 되어있고 오류가 발생
로그아웃 환경시에 인기 블로거 클릭하면 fetch 오류 발생
이메일 형식을 지키지 않더라도 "사용 가능한 이메일" 문구 발생 문제
시간이 다 돼서 로그아웃 되었을 때 다른 링크로 접근하면 fetch 오류 발생
➡️메인화면으로 리다이렉팅 하도록 해야할 것 같음
다크모드 UI 개선
화면 여백 조정

2) 추가할 사항들 (Additional)

인기 블로거 정렬 : 인기 블로거 외에 다른 사람 블로그를 들어갈 수 있는 방법 부재
상세 게시글에서 블로그로 들어갈 수 있게 개선 필요검색 기능: +블로거, 게시글 제목
게시글 댓글, 조회수 표시(실시간 인기글 기준)
최신 게시물 페이징 기술 적용해서 여러개 볼 수 있도록 구현 (ex. 스크롤 Left, Right 버튼)
게시물 모아놓은 페이지 구성 필요
댓글이나, 글 작성시, 프로필을 누르면 그 유저의 나의 나무( 또는 유저의 글 목록 페이지)로 가도록 하는 기능
이메일 인증 강화 : 실제 사용하는 이메일을 사용하도록 하여 가짜 계정 생성제한
홈 화면에서 댓글, 조회수 표시되도록 하기.
비공개, 공개 설정 만들기.
관리자 페이지
신고하기 기능
비밀번호 찾기 시에 이메일로 비밀번호를 보내어 임시 비밀번호를 받을 수 있도록 하는 기능
태그 기능

회고 결과 :

1차 팀프로젝트가 마무리되었다. Readme를 통해 지금까지 만들어낸 프로젝트를 정리해보니

모두가 고생했던 프로젝트임을 느낄 수 있었다.

부족한 기능들도 많고 도움을 받은 곳도 많지만 서비스 개발의 흐름을 이해하고 협업에 진지하게 임하는 것으로

팀프로젝트를 열심히 마무리할 수 있었다.

서비스 유지보수가 필요할때 팀원들과도 종종 컨택해야겠다는 생각을 하게되었다.

[멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_96일차_"블로그 프로젝트의 에디터 도입"

LEFT — Wed, 21 May 2025 19:36:28 +0900

멋쟁이사자처럼 백엔드 부트캠프 13기
TIL 회고 - [96]일차

96일차에는 블로그 프로젝트를 개발하면서 필요했던 에디터 (Editor, 게시글을 작성할때 필요한 텍스트 박스 관련)에 대해 회고해보고자 한다. (2025.04.29)

❓블로그 프로젝트에서 에디터를 사용하는 이유

기존에는 input 태그(textarea)를 사용해 글을 입력받음

텍스트 꾸미기 (굵게, 기울임, 색상) 지원 안 됨
이미지 삽입 어려움
코드 블록, 표 삽입 불가
➡️이처럼 기본 input/textarea는 한계가 있음

✅전문적인 블로그 기능을 위해서는 "WYSIWYG 에디터" 도입 필요

WYSIWYG: "What You See Is What You Get"
➡️작성하는 화면이 결과물과 똑같이 보이는 편집기
대표적인 라이브러리 종류
- CKEditor
- TinyMCE
- Toast UI Editor
- Quill 등

작동 원리

프론트엔드	WYSIWYG 에디터(ex. CKEditor, TinyMCE)를 설치하고 게시글 작성 UI에 적용
백엔드	에디터가 생성한 HTML 포맷의 콘텐츠를 수신하여 데이터베이스에 저장
실행결과	사용자는 직관적인 에디터로 텍스트, 이미지, 표, 링크 등을 삽입 가능

CKEditor vs TinyMCE 차이점

	CKEditor	TinyMCE
라이선스	무료/유료 버전 모두 존재	오픈소스/유료 기능 별도 제공
배포 안정성	매우 안정적 (많은 사례)	추가 설정 필요할 수 있음
이미지 업로드	자체 플러그인 제공	플러그인 설치 필요
커스터마이징	유연함 (플러그인 다양)	고급 설정 시 약간 복잡할 수 있음

CKEditor 설치 및 연동 (Next.js)

패키지 설치

npm install --save @ckeditor/ckeditor5-react @ckeditor/ckeditor5-build-classic

연동 방법 (Next.js 컴포넌트) >> components/MyEditor.tsx

import React, { useState } from 'react';
import { CKEditor } from '@ckeditor/ckeditor5-react';
import ClassicEditor from '@ckeditor/ckeditor5-build-classic';

const MyEditor = ({ onChange }: { onChange: (data: string) => void }) => {
  const [editorData, setEditorData] = useState('');

  return (
    <div>
      <CKEditoreditor={ClassicEditor}
        data={editorData}
        onChange={(event, editor) => {
          const data = editor.getData();
          setEditorData(data);
          onChange(data);
        }}
      />
    </div>
  );
};

export default MyEditor;

import로 CKEditor를 사용할 수 있다.

게시글 작성 페이지

import React, { useState } from 'react';
import MyEditor from '@/components/MyEditor';

const PostCreatePage = () => {
  const [content, setContent] = useState('');

  const handleSubmit = () => {
    console.log('작성된 게시글 내용:', content);
    // 백엔드로 content 전송
  };

  return (
    <div>
      <h1>게시글 작성</h1>
      <MyEditor onChange={setContent} />
      <button onClick={handleSubmit}>제출</button>
    </div>
  );
};

export default PostCreatePage;

MyEditor로 받아와서 필요한 form 부분에 사용할 수 있다.

CKEditor vs Toast UI Editor 차이점

마크다운 변환 필요시 Toast UI Editor 고려

	CKEditor	Toast UI Editor
렌더링 방식	HTML 기반 (WYSIWYG)	Markdown 기반 (WYSIWYG + Markdown 동시지원)
이미지 업로드	자체 플러그인, S3 연동 등 가능	커스터마이징 필요 (직접 핸들러 작성)
Next.js 호환성	SSR 미지원 → dynamic import 필요	SSR 잘 작동
사용 편의성	워드같은 편리한 UI	개발자 친화적 UI (양방향 모드)
출력 형태	HTML	Markdown + HTML

정리하자면

블로그 스타일 게시판, 다양한 사용자 대상 ➡️CKEditor
개발 블로그, 기술문서, 마크다운 중심 ➡️Toast UI Editor

Toast UI Editor 설치 및 연동 (Next.js)

npm install @toast-ui/react-editor

import { Editor } from '@toast-ui/react-editor';
import '@toast-ui/editor/dist/toastui-editor.css';

export default function MyToastEditor() {
  return (
    <EditorinitialValue="내용을 입력하세요"
      previewStyle="vertical"
      height="500px"
      initialEditType="markdown"
      useCommandShortcut={true}
    />
  );
}

Next.js에서는 Toast UI가 설정과 SSR 대응 측면에서 더 편리

회고 결과 :

회고를 통해 블로그 프로젝트의 게시글 작성 부분을 일반 input태그 등으로 처리하는 것이 아닌

외부 Editor를 설치하여서 사용하는 방법을 공부할 수 있었다.

각각의 Editor별로 스타일이 달라 기획하고자하는 서비스에 맞게 도입하는 것도 회고를 통해 알 수 있었다.

[멋쟁이사자처럼 부트캠프 TIL 회고] BE 13기_92일차_"프론트엔드 팔로우 기능 오류 해결 (2)"

LEFT — Tue, 20 May 2025 19:10:20 +0900

멋쟁이사자처럼 백엔드 부트캠프 13기
TIL 회고 - [92]일차

92일차에 발생했었던 오류해결과정 및 수정사항을 회고하고자한다. (2025.04.23)

유저 생성 후 팔로우를 하여도 해당 유저의 팔로잉 목록은 비어있는 문제

⚠️오류원인

- userId와 Id 경로 문제
- LazyInitializationException 오류 발생
➡️JPA의 지연 로딩(Lazy Loading) 관련 문제로, 트랜잭션 범위 밖에서 지연 로딩된 엔티티에 접근하려고 할 때 발생

⌛진행과정

1. 새로운 유저 생성 (기존에 가입된 유저가 "팔로우할" 유저를 새로 생성함)

curl -X POST http://localhost:8090/api/v1/members/signup -H 'Content-Type: application/json' -d '{"email":"test3@test.com","password":"Test123!@#","name":"테스트3","blogName":"테스트블로그3"}'

2. 기존 유저로 로그인 (새로운 유저를 팔로우 하기 위함)

curl -X POST http://localhost:8090/api/v1/members/login -H 'Content-Type: application/json' -d '{"email":"test2@test.com","password":"Test123!@#"}'

3. 기존 유저로 새로운 유저 팔로잉

curl -X POST 'http://localhost:8090/api/v1/follows/follow?followingid=2' -H 'Authorization: Bearer 키값'

4. 기존 유저의 팔로잉 상태 확인

프론트엔드 UI에서는 팔로잉이 "1" 증가된 것을 확인 가능하지만

팔로잉을 눌러서 모달 팝업을 열게되면 여전히 팔로우하는 사용자가 없다고 표시되는 오류가 발생 중이다.

✅해결 방법

- 새 토큰을 받고 새 토큰으로 다시 팔로우 요청

curl -X POST 'http://localhost:8090/api/v1/follows/follow?followingid=2' -H 'Authorization: Bearer 키값'

이전 토큰이 만료되어 새로운 토큰을 받기 위해 로그인을 수행했고, 성공적으로 새 토큰을 발급
새 토큰을 사용하여 팔로우 요청을 보냈고, "팔로우 성공" 응답을 받음

테스트 결과 요약

팔로잉 목록 조회 테스트
- ID 2번 유저("유저입니다")가 팔로잉 목록에 정상적으로 표시됨
- 상태는 "ACTIVE"로 정상
언팔로우 테스트
- 언팔로우 요청 성공
- 팔로잉 목록이 빈 배열 []로 변경되어 정상적으로 언팔로우됨
다시 팔로우 테스트
- 새 토큰으로 팔로우 요청 성공
- 팔로잉 목록 재확인 시 ID 2번 유저가 다시 표시됨
ID 2번 유저의 팔로워 목록 확인 - UI화면

curl http://localhost:8090/api/v1/follows/members/2/followers -H 'Authorization: Bearer 키값'

ID 2번 유저의 팔로워 목록을 확인한 결과
- ID 1번 유저("테스트2")가 팔로워로 표시됨
- 팔로워의 상태는 "ACTIVE"로 정상
- 현재 프로필 사진은 없음(null)

➡️팔로우 작업이 성공적으로 반영된 것
ID 1번 유저(테스트2)가 ID 2번 유저를 팔로우했기 때문에 팔로워 목록에 정상적으로 표시

팔로워/팔로잉 목록이 반대로 표시되고 있는 문제

⚠️오류원인

- 백엔드 API 응답은 정상적으로 오지만 프론트엔드에서 표시되는 방식이 잘못됨

✅해결 방법

user_follower_tsx (유저 팔로워 관련 스크립트)

// 팔로워와 팔로잉 목록을 가져오는 함수
const fetchFollowData = async () => {
  setLoading(true);
  try {
    // 팔로워 목록 가져오기
    const followersResponse = await fetch(`http://localhost:8090/api/v1/follows/members/${userId}/followers`, {
      credentials: 'include'
    });
    
    // 팔로잉 목록 가져오기
    const followingResponse = await fetch(`http://localhost:8090/api/v1/follows/members/${userId}/followings`, {
      credentials: 'include'
    });

    if (followersResponse.ok) {
      const followersData = await followersResponse.json();
      setFollowers(followersData);  // 팔로워 데이터 설정
    } else {
      setFollowers([]);
    }

    if (followingResponse.ok) {
      const followingData = await followingResponse.json();
      setFollowing(followingData);  // 팔로잉 데이터 설정
    } else {
      setFollowing([]);
    }
  } catch (error) {
    ...
  }
};

// 현재 탭에 따른 사용자 목록
const currentUsers = activeTab === 'followers' ? followers : following;

1. API 호출과 상태 설정은 올바르게 되어있지만, 화면에 표시할 때 followers와 following 배열을 반대로 사용중인 문제발견
2. 다른 문제로 백엔드의 FollowServiceImpl에서 팔로워/팔로잉 목록을 조회하는 로직이 반대로 되어있는 문제발견
3. 또한 FollowRepository의 메소드와 FollowServiceImpl의 구현이 불일치하는 문제발견

FollowServiceImpl 에서

findAllByFollowerId(Long followerId) - 내가 팔로우하는 사람들 목록
findAllByFollowingId(Long followingId) - 나를 팔로우하는 사람들 목록

메소드를 수정함으로써 해결

회고 결과 :

회고를 통해 팔로우 관련 기능에서 모달 팝업의 출력문제를 해결할 수 있었다.

백엔드 단에서의 호출과 프론트엔드 단에서의 처리에서 꼬여있는 것 같았다.

팔로우, 팔로워, 팔로잉 등에 대한 용어 개념 정리가 필요하여서

팔로우 기능이라는 전체 범주 안에 (팔로워, 팔로잉)을 포함시키는 것으로 개념을 정리할 수 있었다.