Spring Boot 초기 세팅: JPA Auditing + GitHub Actions CI (초기 빌드 실패 해결까지) + Figma 와이어프레임 정리

배달 앱 프로젝트를 이제 막 시작하면서(엔티티도 아직 없음) JPA Auditing, BaseEntity 패키지 구조, GitHub Actions CI를 초반에 어떻게 잡을지 정리했다.
또, CI에서 build가 실패했는데 원인이 무엇이었는지도 함께 기록한다.
추가로, 개발 전에 Figma로 모바일 앱 와이어프레임을 제작하면서 Figma 사용법도 익혔다.

✅ (UI 설계) Figma로 와이어프레임 제작 & 화면 흐름 정리

개발을 바로 들어가기 전에, Figma로 핵심 화면 와이어프레임을 먼저 만들었다.
이 과정에서 “어떤 화면이 필요하고”, “각 화면에서 어떤 데이터가 필요할지”를 더 명확히 정리할 수 있었다.

와이어 프레임 설계(미완)

홈 화면: 검색바 + 카테고리 그리드 + 하단 탭(홈/주문내역/마이)

회원가입/로그인 화면: 카카오/네이버 소셜 로그인 + 이메일 로그인 진입

이메일 로그인 화면: 이메일/비밀번호 입력 + 계정 찾기 동선

정리 포인트:

• 와이어프레임을 먼저 만들어두니, 이후 API 설계 / 엔티티 설계 범위(MVP) 를 잡는 데 도움이 됨

• Figma에서 컴포넌트 배치/정렬/아이콘 활용 등 기본 사용 흐름을 익힘

figma를 어떻게 예쁘게 할 수 있지라는 생각이 들었었는데 드디어 실행을 조금 한 것 같다.

✅ createdAt / updatedAt은 JPA Auditing으로 처리하는 게 정석

엔티티마다 createdAt, updatedAt을 직접 세팅하는 건 반복이 많아서, 보통 Spring Data JPA Auditing으로 자동화한다.

(1) Auditing 활성화

스프링부트 메인 클래스 또는 별도 Config에 아래를 붙인다.

@EnableJpaAuditing

(2) BaseTimeEntity 예시

@MappedSuperclass: 상속받는 엔티티 테이블에 컬럼으로 들어감

@EntityListeners(AuditingEntityListener.class): auditing 작동 핵심

@CreatedDate, @LastModifiedDate: 자동 세팅/갱신

(3) @Column의 의미

• @Column은 “DB 컬럼으로 매핑”을 명시하는 애노테이션

• 옵션 없이 @Column만 붙이는 건 기능적으로 큰 차이가 없다(JPA는 기본 매핑을 해줌)

@Column(updatable=false)는 UPDATE 쿼리에서 해당 컬럼을 업데이트 대상에서 제외한다
→ createdAt에 자주 붙임(생성 후 변경 방지 목적)

✅ CI는 언제 붙이는 게 좋나?

프로젝트가 “완전 초기(엔티티도 없음, dev 브랜치도 없음)”라도 최소 CI는 초반부터 붙이는 게 좋다.

초기 CI의 목적은 거창한 자동배포가 아니라,

“커밋이 빌드 깨지는 상태로 쌓이는 걸 막기”

“컴파일/의존성/기본 테스트가 정상인지 자동 확인”

이 정도만으로도 가치가 크다.

✅ GitHub Actions CI 워크플로우 (Gradle + JDK 17)

(1) 브랜치 트리거 YAML 작성 팁

아래처럼 쓰는 게 가장 안전/직관적이다.

on:
  push:
    branches:
      - main
  pull_request:
    branches:
      - main

(2) Corretto 17 설정

with:
  distribution: 'corretto'
  java-version: '17'
  cache: 'gradle'

(3) permissions: contents: read 는 뭔가?

GitHub Actions가 사용하는 GITHUB_TOKEN 권한을 최소로 제한한다.

permissions:
  contents: read

• CI는 보통 “레포 읽기(체크아웃)”만 하면 되므로 read면 충분

• 불필요한 쓰기 권한을 막는 보안/권장 설정

✅ “테스트 코드 없는데 왜 build 실패?” → 기본 contextLoads() 때문

CI에서 ./gradlew clean build를 실행하면 build에 test가 포함된다.
Spring Initializr가 만든 기본 테스트 클래스가 1개 존재한다.

DeliveryPlatformApplicationTests > contextLoads()

그런데 여기서 스프링 컨텍스트를 띄우는 과정에서,

DataSourceBeanCreationException

이 발생하며 실패했다.
즉, DB(DataSource) 설정이 아직 없어서, 스프링부트가 datasource를 만들지 못하고 테스트가 깨진 것.

초기 단계에서 해결 방법

1. 가장 간단 방법: CI에서 테스트 스킵

엔티티도 없고 DB도 아직이라면, 초반에는 빌드만 확인해도 충분하다.

./gradlew clean build -x test

• -x test는 Gradle에서 test 태스크를 제외(exclude) 하는 옵션

CI 워크플로우에서 다음처럼 바꾸면 된다:

- name: Build (skip tests for now)
  run: ./gradlew clean build -x test

2. 추후 선택지: 테스트 환경을 잡고 싶다면

테스트용 H2 적용 + test 프로필 구성 등으로 contextLoads가 DB 없이도 뜨게 만들 수 있다.

하지만 “완전 초기”엔 일단 스킵이 제일 빠르고 현실적이다.

일단은 회원가입/로그인부터 묶어서 백엔드 로직과 프론트 화면 연동을 1순위로 잡고 점차 확장할 예정입니다.

✨ 정리

초기 단계에서 정리한 핵심:

• Figma 와이어프레임으로 화면 흐름/기능 범위를 먼저 정리

• createdAt/updatedAt은 Auditing으로 자동화

• CI는 초반부터 “빌드/테스트(또는 빌드만)”로 가볍게 시작

• build 실패는 대부분 기본 contextLoads + datasource 설정 없음 때문에 발생할 수 있음

• 초기엔 -x test로 스킵하고, DB 붙일 때 테스트 환경을 다시 잡는다