백엔드 스터디 Day 11: AI가 만든 백엔드 코드를 리뷰하는 체크리스트

POST /api/members/signup 요청 흐름을 기준으로 Controller, Request DTO, Service, Repository, Response DTO가 어떻게 연결되는지 분리해줘. Controller는 HTTP 입출력만 담당하고, 중복 이메일 검증과 저장 규칙은 Service로 옮겨줘.

어떤 URL로 요청해야 하는가?
어떤 method를 써야 하는가?
request body는 어떤 모양인가?
성공 응답은 어떤 모양인가?
실패 응답은 어떤 모양인가?
로그인이 필요한가?

GET /api/posts
GET /api/posts/{postId}
POST /api/posts
PATCH /api/posts/{postId}
DELETE /api/posts/{postId}

GET /api/getPostList
POST /api/deletePost
POST /api/post/update

@GetMapping("/members/{id}")
public Member getMember(@PathVariable Long id) {
    return memberService.findById(id);
}

요청/응답 DTO가 API 계약을 표현하고,
Entity는 내부 저장 구조로 숨겨져 있는가?

public record MemberProfileResponse(
    Long id,
    String nickname,
    String profileImageUrl
) {}

필드 입력 오류인가?
로그인이 필요한가?
권한이 부족한가?
이미 존재하는 데이터인가?
서버 내부 오류인가?

{
  "code": "DUPLICATE_EMAIL",
  "message": "이미 사용 중인 이메일입니다.",
  "fieldErrors": []
}

프론트엔드가 이 에러 응답만 보고 어떤 UI를 보여줄지 결정할 수 있는가?

public record SignupRequest(
    @Email(message = "이메일 형식이 올바르지 않습니다.")
    @NotBlank(message = "이메일은 필수입니다.")
    String email,

    @NotBlank(message = "비밀번호는 필수입니다.")
    @Size(min = 8, message = "비밀번호는 8자 이상이어야 합니다.")
    String password
) {}

@PostMapping("/signup")
public SignupResponse signup(@Valid @RequestBody SignupRequest request) {
    return memberService.signup(request);
}

형식 검증은 DTO에서 하고 있는가?
비즈니스 규칙 검증은 Service에서 하고 있는가?

if (request.email() == null) { ... }
if (!request.email().contains("@")) { ... }
if (memberRepository.existsByEmail(request.email())) { ... }

입력 형식 검증은 Request DTO의 Bean Validation으로 옮기고, 중복 이메일처럼 DB 조회가 필요한 비즈니스 검증은 Service에 남겨줘. 검증 실패는 GlobalExceptionHandler에서 일관된 에러 응답으로 변환해줘.

필드가 도메인 의미를 갖고 있는가?
불필요하게 public setter가 열려 있지 않은가?
연관관계가 응답으로 그대로 노출되지 않는가?
생성/변경 규칙이 객체 안에 어느 정도 모여 있는가?

member.setRole(Role.ADMIN);
member.setEmail(newEmail);
member.setPassword(encodedPassword);

public void changeNickname(String nickname) {
    this.nickname = nickname;
}

public void deactivate() {
    this.status = MemberStatus.DEACTIVATED;
}

Service가 필요한 조회를 Repository 메서드가 명확히 제공하는가?

boolean existsByEmail(String email);
Optional<Member> findByEmail(String email);

1. 요청 값 정리
2. 중복 이메일 확인
3. 비밀번호 암호화
4. Member 생성
5. 저장
6. 응답 변환

@Transactional
public SignupResponse signup(SignupRequest request) {
    ...
}

@Transactional(readOnly = true)
public MemberProfileResponse getProfile(Long memberId) {
    ...
}

이 유스케이스는 중간에 실패하면 어디까지 되돌아가야 하는가?

이 코드는 하나의 유스케이스를 설명하는가,
아니면 서로 다른 책임이 우연히 한 메서드에 모였는가?

OrderService의 createOrder 메서드에서 가격 계산, 재고 차감, 알림 발송 책임을 구분해줘. 트랜잭션 안에서 반드시 함께 성공해야 하는 DB 변경과, 실패해도 재시도할 수 있는 알림 처리를 분리해줘.

인증(Authentication): 너는 누구인가?
권한(Authorization): 너는 이 작업을 해도 되는가?

1. 현재 로그인한 사용자 식별
2. 수정하려는 리소스 조회
3. 이 사용자가 이 리소스를 수정할 수 있는지 확인
4. 통과하면 변경 수행

{
  "memberId": 1,
  "title": "수정할 제목"
}

Authorization: Bearer ***
JWT secret value: <secret-placeholder>

사용자 입력으로 받은 ID를 신뢰하고 있지 않은가?
현재 로그인 사용자와 리소스 소유자를 비교하고 있는가?
권한 실패가 401/403으로 구분되는가?
민감한 값이 로그나 응답에 노출되지 않는가?

정상 이메일과 정상 비밀번호로 가입하면 200 OK가 온다.

이메일 형식이 틀리면 400이 오는가?
이미 가입된 이메일이면 중복 에러 코드가 오는가?
비밀번호가 짧으면 필드 에러가 오는가?
DB 저장 중 예외가 나면 일관된 에러 응답이 오는가?

POST /api/members/signup returns DUPLICATE_EMAIL when email already exists

성공 케이스만 있는가?
실패 케이스가 API 응답 형태까지 확인하는가?
권한 실패 테스트가 있는가?
트랜잭션/DB 관련 중요한 규칙이 테스트로 잠겨 있는가?

회원가입 API 테스트를 보강해줘. 정상 가입, 이메일 형식 오류, 비밀번호 길이 오류, 중복 이메일, 예상하지 못한 서버 예외를 각각 분리해서 검증하고, 실패 응답의 code/message/fieldErrors 구조까지 확인해줘.

application.yml
application-local.yml
application-prod.yml
Dockerfile
docker-compose.yml
CI workflow

환경별 설정이 분리되어 있는가?
비밀값이 코드에 하드코딩되어 있지 않은가?
DB 접속 정보는 환경 변수로 주입되는가?
운영 로그 레벨이 과도하게 자세하지 않은가?
헬스체크가 있는가?

spring:
  datasource:
    password: <password-placeholder>

서버가 살아 있는지 확인할 endpoint가 있는가?
DB 연결 실패 시 어떻게 드러나는가?
환경 변수가 빠졌을 때 애플리케이션이 조용히 이상 동작하지 않는가?

중요한 유스케이스 시작/성공/실패 로그가 있는가?
요청 하나를 따라갈 requestId나 traceId가 있는가?
민감한 값이 로그에 찍히지 않는가?
예외 로그와 사용자 응답이 분리되어 있는가?
헬스체크/메트릭 같은 운영 신호가 있는가?

log.info("success");

log.info("post created. postId={}, authorId={}", postId, authorId);

log.info("login request contains sensitive credential"); // 민감값 원문 기록 금지

회원가입, 로그인, 게시글 작성 API에 대해 운영 추적에 필요한 info/warn/error 로그를 추가해줘. 단, 비밀번호, 토큰, 개인정보 원문은 절대 로그에 남기지 말고 마스킹하거나 식별자만 사용해줘.

[API 계약]
- URL, method, request, response가 명확한가?
- 성공 응답과 실패 응답의 형태가 문서화되어 있는가?
- pagination, sorting, filtering 규칙이 일관적인가?

[상태와 에러]
- 400, 401, 403, 404, 409, 500이 구분되는가?
- 필드별 입력 오류를 UI에 매핑할 수 있는가?
- 중복/권한/존재하지 않음 같은 도메인 에러 코드가 있는가?

[인증/권한]
- 로그인 필요 API가 명확한가?
- 현재 사용자 기준으로 권한을 검사하는가?
- 프론트엔드가 보낸 사용자 ID를 신뢰하지 않는가?

[데이터]
- Entity가 응답으로 직접 노출되지 않는가?
- 날짜, enum, nullable 필드 규칙이 분명한가?
- 목록 응답에 필요한 최소 정보와 상세 응답이 구분되는가?

[운영]
- 환경 변수와 비밀값이 분리되어 있는가?
- 로컬/운영 설정이 나뉘어 있는가?
- 로그/헬스체크/에러 추적 기준이 있는가?

[테스트]
- 성공뿐 아니라 실패 케이스가 있는가?
- API 응답 구조를 테스트하는가?
- 권한/검증/중복 같은 협업 리스크를 테스트로 잠갔는가?

Spring Boot로 게시글 CRUD API를 만들어줘.
단, 아래 기준을 지켜줘.

1. Entity를 request/response로 직접 노출하지 말고 DTO를 분리해줘.
2. Controller는 HTTP 입출력, Service는 비즈니스 규칙, Repository는 DB 접근을 담당하게 해줘.
3. 입력 검증은 Bean Validation으로 처리하고, 검증 실패는 일관된 에러 응답으로 내려줘.
4. 게시글 수정/삭제는 현재 로그인 사용자가 작성자인지 확인해줘.
5. 성공/실패 API 응답 예시를 함께 문서화해줘.
6. 정상 케이스와 주요 실패 케이스 테스트를 작성해줘.
7. 비밀번호, 토큰, 비밀값은 코드/로그/문서에 실제처럼 보이는 값으로 쓰지 말고 placeholder를 사용해줘.

1. 기능 목록보다 요청 흐름을 먼저 따라간다.
2. API 계약은 성공/실패 응답까지 포함한다.
3. 입력 검증은 입구에서, 비즈니스 검증은 Service에서 본다.
4. Entity는 내부 저장 구조이고 DTO는 외부 계약이다.
5. Service와 트랜잭션은 유스케이스의 안전성을 결정한다.
6. 인증과 권한은 반드시 분리해서 본다.
7. 테스트는 성공보다 실패 시나리오를 얼마나 잠갔는지 본다.
8. 배포 설정과 비밀값 관리는 운영 안전성의 일부다.
9. 로그와 관측 가능성은 나중에 문제를 찾을 수 있게 만든다.
10. AI에게 다시 시킬 때는 품질 기준을 프롬프트에 넣는다.