Spring으로 API를 만들다 보면 ApiResponse<T> 같은 공통 응답 형식을 자주 보게 된다. 공통 응답 형식은 여러 API의 응답 구조를 일정하게 만들어주는 장점이 있지만, 모든 API에 무조건 적용해야 하는 것은 아니다. 핵심은 이것이다. 공통 응답 형식은 API를 일관되게 만들기 위한 도구이지, 모든 응답을 반드시...

백엔드 API를 만들다 보면 성공하는 경우만큼이나 실패하는 경우도 많이 생긴다. 예를 들어 이런 상황들이다. 존재하지 않는 사용자를 조회했다. 이미 가입된 이메일로 회원가입을 시도했다. 이메일 형식이 잘못됐다. 로그인하지 않은 사용자가 인증이 필요한 API를 호출했다. 서버에서 예상하지 못한 오류가 발생했다. 이런 상황에서 ...

백엔드 개발을 하다 보면 한 번쯤 이런 고민을 하게 된다. Validation은 Controller에서 해야 할까? 아니면 Service에서 해야 할까? Spring에서는 @Valid를 사용하면 요청 값을 쉽게 검증할 수 있다. 그래서 처음에는 이렇게 생각하기 쉽다. “DTO에 @NotBlank, @Email, @Size 붙이고 C...

Request DTO는 서버가 받기로 한 입력 계약이고, Response DTO는 서버가 공개하기로 한 출력 계약이다. 둘 다 데이터를 전달하는 객체이지만, 데이터가 이동하는 방향과 목적이 다르기 때문에 분리하는 것이 안전하다. DTO가 무엇인지부터 간단히 알아보자 DTO는 Data Transfer Object의 약자로, 데이터를 전달하기 위...

JPA Entity를 API 응답으로 그대로 반환하면 서버 내부 정보가 노출될 수 있고, Entity 변경이 API 변경으로 이어질 수 있다. 또한 연관관계로 인해 응답 데이터가 예상보다 커지거나, 순환 참조와 Lazy Loading 문제가 발생할 수 있다. 그래서 일반적으로 API 응답에는 Entity 대신 Response DTO를 사용한다. ...

DTO는 요청과 응답에 필요한 데이터만 담아 전달하는 객체다. 백엔드 API에서는 DTO를 사용해 외부에 공개되는 요청·응답 형식을 Entity와 내부 구현으로부터 분리할 수 있다. 처음에는 DTO가 이해되지 않았다 Spring으로 처음 API를 만들 때는 이런 생각이 들었다. “Entity가 이미 있는데 DTO를 왜 또 만들어야 하지...

Spring으로 처음 API를 만들다 보면 이런 생각이 들 수 있다. “Controller에서 요청도 받고, DB도 조회하고, 응답까지 바로 만들면 더 간단하지 않을까?” 실제로 작은 기능 하나만 만들 때는 Controller 안에서 모든 작업을 처리하는 편이 더 빠르게 느껴질 수 있다. 하지만 기능이 늘어나기 시작하면 Controller...

새로운 회사에 입사하거나 다른 사람이 만든 프로젝트를 처음 맡으면 가장 먼저 이런 생각이 든다. “파일이 너무 많은데 어디부터 봐야 하지?” 프로젝트를 열어보면 controller, service, repository, domain, config, common, infra 같은 폴더가 한꺼번에 보인다. 이때 눈에 띄는 파일부터 무작정 열기...

Spring Boot 프로젝트를 처음 만들다 보면 application.yml에 데이터베이스 접속 정보를 작성하게 된다. spring: datasource: url: jdbc:postgresql://localhost:5432/myapp username: app_user password: app_password 로컬에서 혼...

환경변수를 처음 알았을 때의 오해 처음 환경변수를 접했을 때는 단순히 비밀번호를 숨기기 위한 기능이라고 생각했다. DB 비밀번호나 API Key처럼 코드에 직접 적으면 위험한 값을 밖으로 빼놓는 용도라고만 이해했다. 물론 이것도 환경변수를 사용하는 중요한 이유다. 하지만 실제로 배포 환경을 구성해보니 환경변수의 역할은 그것보다 조금 더 넓었다. ...