[Spring Boot] 71. 스프링부트 블로그 v3 (RestAPI) (16) 빌드

김주희

May 13, 2025

[Spring Boot] 71. 스프링부트 블로그 v3 (RestAPI) (16) 빌드

Contents

로그남기기

통합테스트 목적

로컬 컴퓨터에서 돌아가는게 실제 서비스 환경에서도 잘 돌아가는지 확인하기 위해

코드를 수정하게 될 수 있는데 의존성 때문에 다른데 영향을 미칠 수 있음 → 근데 다시 실행해보면서 확인하기 번거롭기 때문에 테스트 코드로 확인 가능

application.properties를 여러개 나눈 이유

application-dev : 로컬 컴퓨터에서 개발자가 개발할 때 필요한 환경 - 가짜 데이터 가짜 환경

application-local : 최종 배포 전에 서버 환경과 똑같을 수는 없지만 구조 등 최대한 똑같이 맞추기 위해서 MySQL로 설정해두는 것. 환경(OS같은 것)은 똑같이 할 수 없지만 최대한 비슷하게 - 윈도우

application-prod : 진짜 환경이므로 local에서 통과해도 여기서 문제가 생길 수도 있긴 함. - 리눅스

→ 도커 : 윈도우 위에 리눅스를 만들 수 있음

로그를 남기는 이유

서비스할 때 문제 생기면 로그를 보고 고쳐야 하기 때문

sout → 로그에 레벨이 있고 레벨별로 해결해야 하므로 sout 사용X

info : 보관해뒀다가 특정한 일이 생겼을 때 꺼내 보는 것

gradle로 라이브러리 다운받고 관리 → 원래는 윈도우에 설치해야되지만 스프링은 내장되어있음

gradlew - 리눅스

gradle2.bat - 윈도우

git bash는 리눅스 하위 어쩌구라서 gradlew 로

= 빌드

내 소스코드도 .class로 컴파일

라이브러리는 어차피 .class로 제공됨

이미 되어있음 왜? 저장만 하면 .class로 컴파일 도 ㅣ어있음

내가 쓰고 있는 라이브러리들만 뽑아내서 (용량 줄이기)

안쓰는거 import 정리해야됨

⇒ 아무튼 실행될 때 필요한 파일들만 다 뽑아내서 패키징 → .jar라는 파일로 만듦


./gradlew clean build

→ ctrl+c 하면 서버 꺼짐

jar를 구워서 던져야 됨 → 서비스 환경에서 테스트 못함 → 테스트 코드를 실제 서비스 환경과 동일하게


1. 프로파일 설정 - 빌드(해당 프로파일로 테스트하고 jar가 생성됨)
2. 프로파일별 실행 (명령어)
3. 로그 레벨별 남기기 
--------------------------
25.05.15 예정
4. CORS 설정 및 개념
5. Devops 세상
6. API 문서 만들기

로그남기기

로그에 레벨이 있음

exception 터질때 e 객체

e.printStackTrace → 에러 로그 중 가장 상세한 설명 (→ 너무 길고 불필요하지 하지 않나?)

에러의 핵심만 알면 나중에 디버깅할때 간단하게만 보고 싶지 않을까?

근데 상세한 설명이어야 해결 가능한 경우도 있긴 함

내가 잡아챈 에러는 아니까 e.getMessage만 해도 충분

근데 500 터지면(내가 모르는) 메세지만으로는 분석이 안될 수도 있음 → trace가 필요함


# log (trace -> debug -> info -> warn -> error)
logging.level.shop.mtcoding.blog=INFO
logging.level.org.hibernate.type=TRACE

trace라고 쓰면 trace -> debug -> info -> warn -> error 전부 볼 수 있음

debug라고 쓰면 debug -> info -> warn -> error 볼 수 있음

error=치명적인거

warn = 나중에 고쳐야하는 언젠간 문제가 생길지도

info = 정상적 (언제 누가 로그인을 했고 어디까지 읽었으며 이런걸 기록

sout인데 레벨만 다르게 있다고 생각하면 됨(?

(서버 실행시 spring.jpa.open-in-view warn → dto가 아니라 모델을 넘기면 뷰 렌더링중에 lazy 로딩에 의해 db 쿼리가 발생할 수 있다는 경고 - 끄면 service까지만 되고 controller에서는 X - 뷰에서 lazy 로딩에 의해 터지는 일X)

application-prod.properties

application-dev : 개발(h2) → build (test, jar 생성)

test할때 deb profile을 땡겨씀 → application에서 spring.profiles.active=dev 라고 설정해뒀기 때문

만들어진 jar는 dev든 local이든 똑같으므로 실행할때 prod (=다른 profile 땡겨 쓸 수 있음)

application-prod : 실제 서비스 실제 db로 연결

application-local : 실제 서비스 로컬 db로 연결

집중력 다뒤짐 와

테스트는 dev로 하면 됨

근데 application에서 active를 local로 바꾸면 테스트 다 터짐

→ db가 없어서 터짐

jar 파일이 만들어지고 실행될 때는 properties 중에서 하나 선택해서 실행할 수 있음

jar 파일이 만들어지는 거지 실행이 되는게 아님 테스트할때 어떤 모드로 테스트할지는 application.properties가 결정

jar를 그냥 실행할거면 dev로 하고

통합테스트 코드 다 만들고 나서

profile 설정해야됨

그다음 빌드 해봐야됨 잘 되는지

로컬에서 잘 되는지 확인해보고 던져야 되니까

잘 되니까 로컬에서 실제 db도 연결해봐야 됨

다 확인 되면 배포

파일을 고치면서X 파일을 만들어두고 하는게 편하다 → application-local 같은 파일 만드는 것

data.sql이 실행되고 테스트 실행되면 됨

뭐 세팅하라고여..?

목적지 jar

그니까 local에서도 똑같이 해봐야 됨 서버 환경에서는 툴로 실행하는게 아니니까!

build해서 jar로 실행해봐야됨

근데 local은 테스트 파일 실행 안되므로 test 없이 jar 파일을 구워보자


 ./gradlew clean build -x test

blog-1.0.jar 가 있는 폴더에서 git bash로


java -jar blog-1.0.jar

jar 파일이 구워지는건 무슨 설정이든 똑같음

테스트를 하고 안하고의 차이

실행을 local로 하도록 application에 설정되어있지만 다른걸로 변경해서 실행가능하다.


특정 모드로 실행시키는 방법

java -jar blog-1.0.jar --spring.profiles.active=dev 
=> dev 모드로 실행돼서 더미가 있음
-> 테스트 환경만 바꿔보는 것
-> 실제 서비스 환경에서는 dev가 아닌 prod로 하겠지

local로 실행

⇒ 그냥 실행하지 말고 무조건 지정해서 실행하도록 하기

dev - h2

local - mysql

mysql → 테스트 코드+더미 없음 : local에서 더미데이터 실행되게 설정 가능 → 근데 테스트가 끝났을때 영구적으로지워주는 세팅 필요

최소 local에서는 잘돌아가는지 확인하고 던져야됨 리눅스 존잘이어야 거기서 수정 가능함 그니까 로컬에서 확인 잘 하고 테스트 다 해봐야 귀찮아서 안하는거 안됨 학생때는 ㄱㅊ지만 실제로 들어가면 개발 완료 = 테스트까지 다 돼서 잘 돌아가는 것 → 귀찮아서 생략햇다가 위약금 물고 어쩌구

로그 남기기

bad_request - warning 정도니까

info도 남겨야

→ filter에서 남겨야 본 코드에 영향을 안미치고 필터 들어오고 나갈때 남김

근데 지금은 콘솔에 남고 나중에는 파일에 남겨야됨 (dbX)

json db에

수집 목적이라서 수정/삭제/일관성 등 중요하지 않으므로 정규화 되지 않은 noSQL을 사용해서

라이브러리 돈주고 쓰는 aws cloud watch / sentry io 것 같은거

sout과 똑같은데 레벨 지정이 가능해서 debug에 적고 막 나중에 주석처리 안해도 됨

log.debug(reqDTO.toString()); 이런식으로 하면 ㄴ중에 주석처리 안해도 됨

jar로 던질때 upload 폴더 안들어감

따로 던져줘야..?