비비빅을 좋아하는 개발자

[LG CNS 6기] 29일차 TIL : Spring Boot JPA Entity·연관관계·CRUD 테스트와 LAZY Loading

bbbicsan — Tue, 8 Sep 2026 17:07:11 +0900

[LG CNS 6기] 29일차 TIL : Spring Boot JPA Entity·연관관계·CRUD 테스트와 LAZY Loading

한 줄 요약
Spring Boot JPA를 중심으로 Entity → DTO 변환, Spring Data JPA Repository 기반 CRUD, MariaDB 외부 DB 연동, User → Blog → Comment 연관관계 설정을 실습했다. 특히 FetchType.LAZY로 인해 발생한 LazyInitializationException을 통해 Transaction과 Persistence Context의 생명주기를 이해하고, Validation과 인증·인가 흐름까지 함께 연결했다.

오늘 학습한 커리큘럼

Spring Boot JPA 환경 구성
        ↓
MariaDB 외부 DB 연동
        ↓
Entity Mapping
@Entity
@Table
@Id
@Column
@GeneratedValue
        ↓
User 1 : N Blog
Blog 1 : N Comment
        ↓
@ManyToOne
@OneToMany
@JoinColumn
mappedBy
fetch
orphanRemoval
cascade
        ↓
Spring Data JPA Repository
        ↓
SimpleJpaRepository 자동 구현
        ↓
JUnit CRUD 테스트
        ↓
UserRequestDTO
→ UserEntity
→ Repository
→ DB
→ UserEntity
→ UserResponseDTO
        ↓
Entity → DTO Factory Method
        ↓
LAZY Loading
        ↓
LazyInitializationException
        ↓
Transaction / Session 경계
        ↓
JPA 기반 Service 전환
        ↓
Validation
        ↓
JWT
        ↓
Authentication / Authorization

오늘의 학습 키워드

Spring Boot
Spring Data JPA
Hibernate
MariaDB
Entity
DTO
Factory Method
Repository
SimpleJpaRepository
JUnit
@Entity
@Table
@Id
@Column
@GeneratedValue
GenerationType.IDENTITY
@OneToMany
@ManyToOne
@JoinColumn
mappedBy
cascade
orphanRemoval
FetchType.LAZY
Transaction
Persistence Context
Proxy
LazyInitializationException
@Transactional
Validation
JWT
Authentication
Authorization

1. JPA 프로젝트 의존성 구성

오늘 프로젝트에는 JPA를 중심으로 여러 기능을 함께 사용할 수 있도록 의존성을 구성했다.

implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
implementation 'org.springframework.boot:spring-boot-starter-web'

runtimeOnly 'org.mariadb.jdbc:mariadb-java-client'

implementation 'org.springframework.boot:spring-boot-starter-validation'

implementation 'org.springdoc:springdoc-openapi-starter-webmvc-ui:2.7.0'

implementation 'io.jsonwebtoken:jjwt-api:0.11.5'
runtimeOnly 'io.jsonwebtoken:jjwt-impl:0.11.5'
runtimeOnly 'io.jsonwebtoken:jjwt-jackson:0.11.5'

compileOnly 'org.projectlombok:lombok'
annotationProcessor 'org.projectlombok:lombok'

기능별 역할은 다음과 같다.

의존성	역할
Spring Data JPA	Entity와 Repository 기반 ORM
Spring Web	REST API
MariaDB Driver	외부 MariaDB 연결
Validation	DTO 요청값 검증
Springdoc	Swagger / OpenAPI
JJWT	JWT 처리 기반
Lombok	Builder, Getter 등 Boilerplate 감소

기존 프로젝트에는 MyBatis도 존재했지만, 오늘 실습은 JPA/Hibernate 중심으로 전환해서 진행했다.

2. application-dev.yml에서 MariaDB 연결

개발 프로필에서는 MariaDB DataSource를 설정했다.

spring:
  config:
    activate:
      on-profile: dev

  datasource:
    driver-class-name: ${DB_DRIVER}
    url: ${DB_URL}
    username: ${DB_USER}
    password: ${DB_PASSWORD}

DB 접속정보는 코드에 직접 넣기보다 외부 설정에서 가져오는 방향으로 구성했다.

.env
  ↓
Spring Config
  ↓
DB_DRIVER
DB_URL
DB_USER
DB_PASSWORD
  ↓
DataSource
  ↓
MariaDB

실제 DB 비밀번호와 같은 민감정보는 블로그에 기록하지 않는다.

3. Hibernate DDL 자동 생성

JPA 설정에서는 다음 옵션을 사용했다.

spring:
  jpa:
    hibernate:
      ddl-auto: create

수업에서 함께 언급된 주요 옵션은 다음과 같다.

create
→ Entity 기준으로 테이블 생성

create-drop
→ 생성 후 Application 종료 시 삭제

update
→ 기존 Schema를 기준으로 변경

none
→ 자동 DDL 처리 사용하지 않음

오늘은 create를 사용했기 때문에 애플리케이션 실행 시 기존 테이블을 정리하고 Entity 정의를 기준으로 다시 생성하는 Hibernate SQL을 확인할 수 있었다.

4. Hibernate SQL 확인

spring:
  jpa:
    show-sql: true

    properties:
      hibernate:
        format_sql: true

show-sql을 사용하면 JPA가 내부적으로 어떤 SQL을 실행하는지 직접 확인할 수 있다.

예를 들어 회원 저장 과정에서:

Hibernate:
    select
        ...
    from
        spring_jpa_user_tbl
    where
        email = ?

Hibernate:
    insert
    into
        spring_jpa_user_tbl
        (name, password, role, email)
    values
        (?, ?, ?, ?)

형태의 SQL이 실제로 출력됐다.

JPA를 사용한다고 SQL이 사라지는 것이 아니라 Hibernate가 SQL을 생성해서 DB와 통신한다는 것을 다시 확인했다.

5. Hibernate Dialect 설정

MariaDB 환경에서는:

spring:
  jpa:
    properties:
      hibernate:
        dialect: org.hibernate.dialect.MariaDBDialect

을 사용했다.

H2 환경에서는 수업 중 비교 예제로:

org.hibernate.dialect.H2Dialect

도 언급됐다.

Dialect는 사용하는 DBMS에 맞는 SQL을 Hibernate가 생성할 수 있도록 도와주는 역할을 한다.

6. Physical Naming Strategy

spring:
  jpa:
    properties:
      hibernate:
        naming:
          physical-strategy: org.hibernate.boot.model.naming.PhysicalNamingStrategyStandardImpl

물리적 Table / Column 이름 변환 정책을 명시적으로 설정하는 방법도 확인했다.

7. 일반 Java 객체를 JPA Entity로 변경

처음 UserEntity는 단순한 Java 클래스였다.

@Builder
@Getter
@ToString
public class UserEntity {

    private String email;
    private String password;
    private String name;
    private String role;

}

이 상태에서는 JPA가 해당 객체를 영속성 객체로 관리하지 않는다.

8. @Entity

@Entity
public class UserEntity {
}

@Entity를 적용하면 이 클래스는 JPA가 관리하는 Entity가 된다.

일반 Java Object
      ↓
@Entity
      ↓
JPA Persistence Object

9. @Table

@Entity
@Table(name = "SPRING_JPA_USER_TBL")
public class UserEntity {
}

@Table을 통해 Entity가 실제 어떤 DB Table과 연결되는지 지정했다.

UserEntity
      ↓
@Table
      ↓
SPRING_JPA_USER_TBL

10. JPA Entity의 식별자

JPA Entity에는 반드시 식별자가 필요하다.

오늘 UserEntity에서는 email을 Primary Key로 사용했다.

@Id
@Column(
    name = "email",
    length = 50,
    nullable = false
)
private String email;

의미:

@Id
→ Primary Key

name = "email"
→ 실제 Column 이름

length = 50
→ VARCHAR(50)

nullable = false
→ NOT NULL

11. Hibernate가 실제 Table 생성

ddl-auto: create 설정으로 Hibernate가 다음과 같은 구조를 생성하는 것을 로그에서 확인했다.

CREATE TABLE SPRING_JPA_USER_TBL (
    email VARCHAR(50) NOT NULL,
    name VARCHAR(255),
    password VARCHAR(255),
    role VARCHAR(255),
    PRIMARY KEY (email)
);

즉:

Java Entity Metadata
        ↓
Hibernate
        ↓
DDL 생성
        ↓
MariaDB Table

흐름이 실제로 동작했다.

12. BlogEntity 생성

Blog 역시 JPA Entity로 구성했다.

@Entity
@Table(name = "SPRING_JPA_BLOG_TBL")
@Builder
@Getter
@ToString
public class BlogEntity {

    @Id
    @GeneratedValue(
        strategy = GenerationType.IDENTITY
    )
    private Integer blogId;

    private String title;

    private String content;

    private String category;

}

13. GenerationType.IDENTITY

Blog ID는:

@GeneratedValue(
    strategy = GenerationType.IDENTITY
)

를 사용했다.

MariaDB에서는 실제로:

AUTO_INCREMENT

기반 PK가 생성됐다.

INSERT
  ↓
DB가 PK 생성
  ↓
blogId

14. category에 DB Constraint 적용

Blog의 category에는 DB 레벨의 제약을 지정하는 예제도 사용했다.

@Column(
    columnDefinition =
        "VARCHAR(20) DEFAULT '전체' " +
        "CHECK(CATEGORY IN ('전체','개발','생활','취미','일상'))"
)
private String category;

이전 SQL 수업에서 직접 작성했던:

DEFAULT
CHECK

조건을 이제 JPA Entity에 선언하고 Hibernate가 DDL로 생성하게 됐다.

15. User : Blog = 1 : N

사용자 한 명은 여러 개의 Blog를 작성할 수 있다.

User
  1
  │
  │
  N
Blog

JPA에서는 양쪽 Entity에 관계를 표현했다.

16. UserEntity의 @OneToMany

@OneToMany
private List<BlogEntity> blogs =
    new ArrayList<>();

User는 Blog 목록을 가진다.

UserEntity
└─ List<BlogEntity>

17. BlogEntity의 @ManyToOne

실제 FK를 가진 Blog 쪽에서는:

@ManyToOne(
    fetch = FetchType.LAZY,
    optional = false
)
@JoinColumn(name = "email")
private UserEntity author;

를 사용했다.

18. @ManyToOne의 의미

@ManyToOne
→ 여러 Blog가 하나의 User를 참조

@JoinColumn(name = "email")
→ Blog Table에서 FK Column 생성

optional = false
→ 작성자 User가 반드시 존재해야 함

실제 MariaDB에서도 spring_jpa_blog_tbl에 email FK가 생성된 것을 확인했다.

19. FetchType.LAZY

fetch = FetchType.LAZY

는 연관된 Entity를 처음부터 모두 가져오지 않고 실제로 필요한 순간에 조회하는 지연 로딩 전략이다.

Blog SELECT
   ↓
User 정보까지 당장 필요 없음
   ↓
Proxy 유지
   ↓
author를 실제 사용
   ↓
User SELECT

오늘은 이 LAZY Loading이 이후 트러블슈팅의 핵심이 됐다.

20. Blog : Comment = 1 : N

Blog 하나에는 여러 Comment가 존재할 수 있다.

Blog
  1
  │
  │
  N
Comment

Blog 쪽에는:

@OneToMany(
    mappedBy = "blog",
    orphanRemoval = false
)
private List<CommentEntity> comments =
    new ArrayList<>();

관계를 설정했다.

21. mappedBy

mappedBy = "blog"

는 반대편 CommentEntity의 blog 필드가 관계를 관리한다는 의미다.

BlogEntity.comments
→ 관계의 반대편

CommentEntity.blog
→ FK를 가진 관계의 주인

22. orphanRemoval

오늘 코드에서는:

orphanRemoval = false

를 사용했다.

즉 컬렉션에서 Comment 객체를 제거했다고 해서 해당 Comment Row를 자동으로 삭제하지 않는 설정이다.

orphanRemoval = false
→ 연관 Collection 제거
≠
자동 DB DELETE

수업 주제에 포함된 cascade, orphanRemoval, fetch는 JPA 연관 객체의 생명주기와 조회 시점을 제어하기 위한 중요한 옵션이다.

23. CommentEntity 생성

Comment도 JPA Entity로 구성했다.

@Entity
@Table(name = "SPRING_JPA_COMMENT_TBL")
@Builder
@Getter
@ToString
public class CommentEntity {

    @Id
    @GeneratedValue(
        strategy = GenerationType.IDENTITY
    )
    private Integer commentId;

    private String comment;

    private String email;

}

24. Comment : Blog = N : 1

@ManyToOne(
    fetch = FetchType.LAZY,
    optional = false
)
@JoinColumn(name = "blogId")
private BlogEntity blog;

즉 Comment Table에는 blogId FK가 만들어진다.

전체 관계는:

User
  1
  │
  N
Blog
  1
  │
  N
Comment

형태가 됐다.

25. Spring Data JPA Repository

다음으로 Repository 계층을 만들었다.

@Repository
public interface UserRepository
        extends JpaRepository<UserEntity, String> {
}

핵심은 구현 클래스를 직접 만들지 않는다는 점이다.

26. SimpleJpaRepository

JUnit 실행 로그에서:

org.springframework.data.jpa.repository.support.SimpleJpaRepository@...

가 출력됐다.

즉:

UserRepository Interface
        ↓
Spring Data JPA
        ↓
Proxy / 구현체 자동 생성
        ↓
SimpleJpaRepository
        ↓
Spring Bean

구조로 동작한다.

27. MyBatis와 JPA Repository 비교

기존 MyBatis에서는:

Mapper Interface
+
Mapper XML
+
SQL 직접 작성

방식이었다.

JPA에서는 기본 CRUD의 경우:

Repository Interface
+
JpaRepository

만으로도 많은 기능을 제공받는다.

MyBatis
→ SQL 중심

JPA
→ Entity 중심

이라는 차이도 체감할 수 있었다.

28. JUnit으로 Repository Bean 확인

테스트에서는:

@Autowired
private UserRepository userRepository;

를 주입했다.

그리고:

System.out.println(
    "debug >>>> signUp repository : "
    + userRepository
);

를 실행했다.

결과:

SimpleJpaRepository

구현체가 출력되어 Repository Bean이 정상적으로 주입된 것을 확인했다.

29. 회원가입 JUnit 테스트 데이터

UserRequestDTO request =
    UserRequestDTO.builder()
        .email("admin@naver.com")
        .password("123456789")
        .name("임정섭")
        .role("admin")
        .build();

형태로 테스트 데이터를 준비했다.

처음에는 null 값을 넣어 구조를 만들고 이후 실제 테스트 값으로 변경하면서 테스트를 확장했다.

30. JPA 회원 저장 과정

실행 로그에서는:

SELECT
FROM spring_jpa_user_tbl
WHERE email = ?

이 먼저 실행되고,

이후:

INSERT
INTO spring_jpa_user_tbl
(name, password, role, email)
VALUES (?, ?, ?, ?)

가 실행됐다.

즉 Repository 수준의 Java 코드가 Hibernate에 의해 실제 SQL로 변환됐다.

31. Entity → DTO Factory Method

저장된 Entity를 외부 응답 DTO로 변환할 때:

UserResponseDTO.fromEntity(entity)

형태의 정적 팩토리 메서드를 사용했다.

오늘 수업 주제 중 하나였던:

xxxEntity
   ↓
xxxDTO

변환을 별도의 Factory Method로 분리한 것이다.

32. Entity와 DTO를 분리하는 이유

이번 흐름에서는:

Database
    ↕
Entity

Controller / Response
    ↕
DTO

로 역할을 구분했다.

Repository는 Entity를 반환하고, API 응답에 필요한 데이터는 DTO로 변환한다.

Repository
→ UserEntity

Factory Method
→ UserResponseDTO.fromEntity()

Controller
→ UserResponseDTO

33. 회원가입 테스트 결과

실행 로그에서:

entity :
UserEntity(
    email=admin@naver.com,
    ...
    role=admin,
    blogs=[]
)

와:

response :
UserResponseDTO(
    email=admin@naver.com,
    ...
    role=admin
)

가 연속으로 출력되는 것을 확인했다.

즉:

RequestDTO
   ↓
Entity
   ↓
JPA Repository
   ↓
MariaDB
   ↓
Entity
   ↓
ResponseDTO

전체 흐름이 동작했다.

34. 로그인 JUnit 테스트

로그인에서는 Email과 Password를 준비했다.

UserRequestDTO request =
    UserRequestDTO.builder()
        .email("admin@naver.com")
        .password("123456789")
        .build();

그리고 Repository의 Query Method를 호출했다.

Optional<UserEntity> optional =
    userRepository
        .findByEmailAndPassword(
            request.getEmail(),
            request.getPassword()
        );

35. Spring Data JPA Query Method

메서드 이름:

findByEmailAndPassword

을 통해 조건을 표현했다.

개념적으로:

SELECT *
FROM USER
WHERE EMAIL = ?
  AND PASSWORD = ?

와 같은 조회가 수행된다.

36. Optional

로그인 사용자가 존재하지 않을 수도 있으므로:

Optional<UserEntity>

로 결과를 받았다.

사용자 존재
→ Optional<UserEntity>

사용자 없음
→ Optional.empty()

37. 로그인 Entity → DTO

조회 후:

UserResponseDTO.fromEntity(
    optional.get()
);

로 Entity를 Response DTO로 변환했다.

오늘 Entity → DTO Factory Method가 회원가입뿐 아니라 로그인 흐름에서도 사용됐다.

문제 해결 과정 1. LazyInitializationException

로그인 조회 테스트 중 다음 오류가 발생했다.

org.hibernate.LazyInitializationException

failed to lazily initialize a collection of role:
UserEntity.blogs

could not initialize proxy - no Session

오늘 JPA 수업에서 가장 중요한 트러블슈팅이었다.

38. 왜 User 조회인데 blogs에서 오류가 발생했을까?

UserEntity에는 Blog 목록이 존재한다.

private List<BlogEntity> blogs;

연관관계 데이터는 LAZY 방식으로 처리될 수 있다.

사용자를 조회했다고 해서 Blog까지 즉시 조회하는 것은 아니다.

User SELECT
      ↓
UserEntity 생성

blogs
      ↓
아직 조회 안 함
      ↓
Lazy Proxy

39. LAZY Proxy

LAZY Loading에서는 실제 연관 데이터를 즉시 조회하지 않고 Proxy를 사용한다.

UserEntity
├─ email
├─ password
├─ name
├─ role
└─ blogs
    ↓
    Proxy

실제 blogs 값이 필요한 순간 Hibernate가 추가 SELECT를 실행한다.

40. Transaction과 Session 경계

수업에서는 이 과정을 시간 순서로 설명했다.

1. Repository 호출

2. Transaction Start

3. User SELECT

4. Repository Method 종료

5. Transaction End

6. Session / Persistence Context 종료

7. 이후 blogs 접근

8. 추가 SELECT 필요

9. Session 없음

10. LazyInitializationException

핵심은 LAZY 자체가 오류가 아니라 LAZY 데이터를 접근하는 시점이었다.

41. toString()도 LAZY Loading을 발생시킬 수 있다

테스트에서는 단순히:

System.out.println(
    optional.get()
);

으로 Entity를 출력했다.

그러나 UserEntity에 Lombok:

@ToString

이 붙어 있다면 내부적으로 blogs까지 접근할 가능성이 있다.

println(entity)
      ↓
entity.toString()
      ↓
blogs 접근
      ↓
LAZY 초기화 시도

따라서 단순 로그 출력도 연관 Entity 조회를 발생시킬 수 있다는 점을 배웠다.

42. 실제 추가 SELECT 확인

실행 결과에서는 실제로:

SELECT
...
FROM spring_jpa_blog_tbl
WHERE email = ?

형태의 Blog 추가 조회도 확인했다.

즉:

User SELECT
      ↓
blogs 필요
      ↓
Blog SELECT

이 실제 SQL로 발생한다.

43. JPA에서 Transaction이 중요한 이유

LAZY Loading은 Persistence Context가 살아 있는 동안 연관 데이터를 가져올 수 있다.

@Transactional
      ↓
Persistence Context 유지
      ↓
Entity 조회
      ↓
LAZY 연관 Entity 접근
      ↓
추가 SELECT 가능
      ↓
Transaction 종료

따라서 JPA에서는 Transaction이 단순한 Commit/Rollback 개념뿐 아니라 Entity와 Persistence Context의 생명주기와도 매우 밀접하게 연결된다.

44. 연관관계와 fetch 전략

오늘 fetch 옵션을 실제 문제를 통해 이해할 수 있었다.

LAZY
→ 필요할 때 조회

즉시 모든 연관 객체를 조회하지 않음
→ 불필요한 SQL 감소 가능

하지만
→ Session 종료 후 접근하면 문제 발생 가능

즉 단순히 LAZY가 좋다, EAGER가 좋다의 문제가 아니라 업무 흐름과 Transaction 범위를 고려해서 선택해야 한다.

45. 외부 설정 파일을 Spring Config로 읽기

기존에는 메인 클래스에서 Dotenv를 사용했다.

Dotenv env =
    Dotenv.configure()
        .ignoreIfMissing()
        .load();

env.entries()
    .forEach(entry -> {
        System.setProperty(
            entry.getKey(),
            entry.getValue()
        );
    });

오늘은 Spring Config가 .env를 직접 읽도록 구성하는 방법도 실습했다.

46. spring.config.import

spring:
  config:
    import:
      - optional:file:.env[.properties]

또는 설정 파일의 위치에 맞게 외부 파일 경로를 지정했다.

흐름:

.env
 ↓
spring.config.import
 ↓
Spring Environment
 ↓
${DB_*}
 ↓
DataSource

47. Environment로 설정값 테스트

JUnit에서는 Spring의 Environment를 주입했다.

@Autowired
private Environment env;

그리고:

env.getProperty("DB_DRIVER");
env.getProperty("DB_URL");
env.getProperty("DB_USER");
env.getProperty("DB_PASSWORD");

로 실제 값이 들어왔는지 확인했다.

실행 로그에서 MariaDB Driver와 URL 등이 출력되어 설정이 정상 로딩된 것을 확인했다.

실제 Password는 블로그에서는 마스킹한다.

문제 해결 과정 2. Failed to load ApplicationContext

외부 설정 파일을 import하는 과정에서:

Failed to load ApplicationContext

오류도 발생했다.

원인

spring.config.import에 지정한:

파일 이름
파일 경로

가 실제 .env 위치와 맞지 않으면 Spring Context 자체가 시작되지 못할 수 있다.

JUnit 실행
      ↓
Spring ApplicationContext 시작
      ↓
Config Import
      ↓
파일 찾지 못함 / 설정 문제
      ↓
ApplicationContext 실패

해결 흐름

외부 설정 파일 경로를 올바르게 맞춘 후:

Environment
→ DB_DRIVER
→ DB_URL
→ DB_USER
→ DB_PASSWORD

를 정상적으로 읽는 것을 확인했다.

48. JPA 기반 UserService로 전환

기존 프로젝트는 MyBatis 기반이었다.

UserService
 ↓
UserMapper
 ↓
Mapper XML

오늘은 이를 JPA Repository 기반 구조로 변경했다.

UserService
 ↓
UserRepository
 ↓
Spring Data JPA
 ↓
Hibernate

49. Service에 @Transactional

@Transactional
public UserResponseDTO signUp(
        UserRequestDTO request
) {
    ...
}

로그인에도:

@Transactional
public Map<String, Object> signIn(
        UserRequestDTO request
) {
    ...
}

를 적용했다.

JPA Service의 업무 단위를 Transaction 안에서 처리하는 구조다.

50. 로그인 Repository 조회

현재 평문 Password 버전은:

UserEntity entity =
    userRepository
        .findByEmailAndPassword(
            request.getEmail(),
            request.getPassword()
        )
        .orElseThrow(
            () -> new LoginFailException(
                "SignIn Fail!!"
            )
        );

형태다.

51. 향후 Password Hashing 방향

수업 코드에는 향후 Password Hashing 방향도 주석으로 남겼다.

현재

findByEmailAndPassword(
    email,
    password
)

향후에는:

findById(email)
      ↓
UserEntity 조회
      ↓
DB에 저장된 Hash Password
      vs
입력 Password
      ↓
비교

하는 방향으로 발전할 예정이다.

즉 Password를 평문 그대로 조회 조건으로 사용하는 현재 방식은 학습용 단계이고, 인증 기능이 확장되면서 변경될 예정이다.

52. Entity 기반 Token 발급

로그인 성공 후에는 요청 DTO 값보다 실제 DB에서 조회한 Entity 정보를 사용한다.

String at =
    jwtProvider.createAT(
        entity.getEmail()
    );

String rt =
    jwtProvider.createRT(
        entity.getEmail()
    );

흐름:

로그인 요청
      ↓
Repository
      ↓
실제 UserEntity
      ↓
Authentication 성공
      ↓
Entity Email
      ↓
AT / RT 발급

53. 로그인 Service 반환값

Map<String, Object> map =
    new HashMap<>();

map.put("response", response);
map.put("at", at);
map.put("rt", rt);

Controller에서 필요한:

사용자 정보
Access Token
Refresh Token

을 한 번에 전달한다.

54. JPA로 변경되어도 GlobalExceptionHandler는 재사용

DB 접근 기술이:

MyBatis
→ JPA

로 변경됐지만 예외 처리 계층은 그대로 사용할 수 있었다.

UserRepository
      ↓
조회 실패
      ↓
LoginFailException
      ↓
GlobalExceptionHandler
      ↓
401 Unauthorized

계층별 책임이 분리되어 있기 때문에 Persistence 기술을 변경해도 상위 API 구조를 대부분 유지할 수 있었다.

55. User Controller 로그인 응답

Controller에서는 Service 결과에서 Token을 꺼낸다.

Map<String, Object> map =
    userService.signIn(request);

그리고 Header를 구성한다.

HttpHeaders headers =
    new HttpHeaders();

headers.add(
    "Authorization",
    (String) map.get("at")
);

headers.add(
    "Refresh-Token",
    (String) map.get("rt")
);

headers.add(
    "Access-Control-Expose-Headers",
    "Authorization, Refresh-Token"
);

56. 최종 로그인 ResponseEntity

return ResponseEntity
        .status(HttpStatus.OK)
        .headers(headers)
        .body(
            (UserResponseDTO)
                map.get("response")
        );

즉:

200 OK

Headers
├─ Authorization
└─ Refresh-Token

Body
└─ UserResponseDTO

구조다.

57. 회원가입 Validation 확인

회원가입 요청에서는 DTO가 정상적으로 Controller에 바인딩되고 Validation 결과도 로그로 확인했다.

UserRequestDTO(
    email=user@naver.com,
    password=*********,
    name=임섭순,
    role=user
)

bindingResult
→ 0 errors

즉:

Client Request
      ↓
DTO Binding
      ↓
Validation
      ↓
0 errors
      ↓
Service
      ↓
JPA Repository

흐름이 정상적으로 이어졌다.

58. Swagger 로그인 테스트

Swagger에서:

GET /users/signIn

API를 직접 실행했다.

입력:

email
password

Request URL은:

/users/signIn
?email=admin@naver.com
&password=*********

형태로 생성됐다.

즉 기존 API의 Query Parameter 방식이 JPA 전환 이후에도 그대로 유지됐다.

59. Authentication과 Authorization

오늘 수업에서는 인증과 인가 개념도 함께 다뤘다.

Authentication
→ "누구인가?"

Authorization
→ "무엇을 할 수 있는가?"

예를 들어:

Email / Password 로그인
      ↓
사용자 확인
      ↓
Authentication

그 후:

role = user
role = admin

등의 권한을 기준으로 접근 가능한 기능을 결정하는 과정이 Authorization이다.

60. User의 role

현재 UserEntity에는:

private String role;

필드가 존재한다.

수업 코드에서도:

user
admin

권한을 고려하는 방향이 언급됐다.

향후 Spring Security와 연결되면:

Authentication
→ Login / Token

Authorization
→ Role / Permission

구조로 발전할 수 있다.

오늘 전체 구조

오늘 실습한 내용을 하나로 연결하면 다음과 같다.

Client
  ↓
UserRequestDTO
  ↓
Controller
  ↓
Validation
  ↓
Service
  ↓
@Transactional
  ↓
Spring Data JPA Repository
  ↓
Hibernate
  ↓
MariaDB
  ↓
Entity
  ↓
Factory Method
  ↓
ResponseDTO
  ↓
JWT
  ↓
ResponseEntity

그리고 데이터 관계는:

UserEntity
    1
    │
    │
    N
BlogEntity
    1
    │
    │
    N
CommentEntity

로 연결됐다.

오늘의 핵심 트러블슈팅 정리

1. LAZY 연관 Collection 접근 시 LazyInitializationException

증상

failed to lazily initialize a collection
could not initialize proxy - no Session

원인

User 조회
→ Transaction 종료
→ Session 종료
→ blogs LAZY Proxy 접근
→ 추가 SELECT 불가능

배운 점

JPA에서는 Entity 조회뿐 아니라 연관 Entity를 언제 사용할지와 Transaction 경계까지 함께 설계해야 한다.

2. 단순 로그 출력이 LAZY Query를 발생시킴

System.out.println(entity);

가 단순 출력처럼 보여도:

@ToString
→ blogs 접근
→ LAZY 초기화
→ SQL 발생

할 수 있다.

Entity의 toString()이나 JSON 직렬화 시 연관관계 필드를 조심해야 한다.

3. .env를 JUnit이 읽지 못해 ApplicationContext 실패

증상

Failed to load ApplicationContext

원인

Spring Test Context가 읽어야 할 외부 설정 파일 경로 문제.

해결

spring:
  config:
    import:
      - optional:file:.env[.properties]

형태로 경로를 맞추고 Environment를 통해 값이 로딩됐는지 직접 확인했다.

✨ 오늘 배운 점

오늘 가장 크게 느낀 부분은 JPA는 단순히 SQL을 안 쓰게 해주는 기술이 아니라 객체와 DB의 관계를 관리하는 기술이라는 점이었다.

MyBatis에서는:

SQL
→ Mapper
→ DTO

흐름에 집중했다면 JPA에서는:

Entity
→ Persistence Context
→ Association
→ Fetch Strategy
→ Transaction

까지 함께 생각해야 했다.

특히 FetchType.LAZY 문제를 직접 경험하면서 Entity가 단순히 SELECT 결과를 담는 객체가 아니라 Hibernate가 관리하는 상태와 Proxy를 가진 객체라는 점을 이해할 수 있었다.

Entity와 DTO를 분리하며

오늘은:

UserResponseDTO.fromEntity(entity)

형태로 Entity를 DTO로 변환했다.

처음에는 Entity와 DTO의 필드가 거의 같기 때문에 굳이 나눠야 하나 싶을 수도 있지만 역할을 생각하면 차이가 명확했다.

Entity
→ DB Persistence Model

DTO
→ API / Layer 간 데이터 전달

Entity의 연관관계와 LAZY Proxy를 그대로 외부 응답에 노출하면 의도하지 않은 SQL이나 직렬화 문제가 발생할 수 있기 때문에 DTO 변환이 더 중요하게 느껴졌다.

Spring Data JPA Repository

Repository Interface만 정의했는데:

SimpleJpaRepository

구현 객체가 자동으로 생성되는 것도 인상적이었다.

기존 MyBatis에서는 SQL과 Mapper XML을 직접 작성했지만 JPA에서는:

findByEmailAndPassword(...)

같은 Query Method를 통해 조회 조건을 표현했다.

다만 SQL을 작성하지 않는다고 해서 SQL을 몰라도 되는 것은 아니었다.

오늘 show-sql로 Hibernate가 생성한 SQL을 보면서 결국 DB에서 어떤 Query가 실행되는지를 이해해야 JPA도 제대로 사용할 수 있다는 점을 확인했다.

Transaction의 의미

이전에는 Transaction을 주로:

COMMIT
ROLLBACK

관점에서 생각했다.

하지만 JPA에서는:

Transaction
        ↓
Persistence Context
        ↓
Entity 관리
        ↓
LAZY Loading 가능 범위

와 연결돼 있었다.

오늘 발생한 LazyInitializationException 덕분에 왜 Service 계층에서 @Transactional을 중요하게 사용하는지 더 구체적으로 이해할 수 있었다.

다음 학습 방향

오늘까지는 JPA Entity와 관계 설정, Repository 기반 CRUD, DTO 변환, LAZY Loading을 실습했다.

다음에는 다음 내용을 더 확인해봐야겠다.

cascade 옵션별 차이

orphanRemoval=true / false 비교

LAZY / EAGER 비교

N+1 문제

Fetch Join

EntityGraph

JPA 변경 감지
Dirty Checking

JPQL

Repository Query Method

JPA Transaction

H2 In-Memory Test

JUnit Repository Test

Password Hashing

JWT 실제 Claim / Signature

Spring Security

Authentication

Authorization

특히 오늘 발생한 LAZY Loading 문제를 기반으로 Fetch Join과 N+1 문제까지 연결해서 학습하면 JPA 조회 전략을 이해하는 데 도움이 될 것 같다.

[FinGuardOps #6] 금융 업무와 AI 계산을 분리한 Spring Boot·FastAPI Rule 분석 연동

bbbicsan — Mon, 7 Sep 2026 17:03:45 +0900

FinGuardOps Project Series #6

앞선 글에서는 외부에서 들어오는 거래와 행동 이벤트를 어떤 기준으로 검증하고, 중복 요청과 충돌을 어떻게 구분할지 정리했습니다. 이번에는 그다음 단계인 Spring Boot와 FastAPI 사이의 Rule 분석 연동을 다룹니다.

다른 서비스의 API를 호출해 JSON 응답을 받는 것 자체는 연동의 시작일 뿐입니다. 분석 중 행동 이벤트나 Rule이 바뀌면 어떤 기준으로 계산한 결과일까요? HTTP 상태가 200이어도 다른 거래의 결과가 들어오면 어떻게 해야 할까요? 분석 결과를 저장하다 실패하면 근거와 거래 상태가 따로 남지는 않을까요?

저는 이 문제를 입력 고정 → 분석 계산 → 응답 검증 → 결과 저장·채택으로 나누었습니다. 특히 외부 HTTP 호출을 DB 트랜잭션 안에 오래 붙잡아 두지 않으면서, 분석 시작과 결과 반영에는 각각 명확한 정합성 경계를 두는 데 집중했습니다.^{[1] [6]}

FastAPI가 분석 결과를 반환했다는 사실만으로 금융 업무 처리가 완료되는 것은 아닙니다.
Spring Boot는 분석 입력과 Rule 버전을 먼저 고정하고, 응답이 그 입력에 대응하는지 검증한 뒤 탐지 결과와 근거를 하나의 트랜잭션으로 저장·채택합니다.

분석 입력을 고정하고 계산·검증·영속화 책임을 분리한 Spring Boot·FastAPI Rule 분석 흐름

그림의 PostgreSQL 저장·채택 단계는 Spring Boot가 수행하는 DB 쓰기입니다. FastAPI가 업무 DB에 직접 연결하거나 거래 상태를 변경한다는 뜻은 아닙니다. 또한 이 글의 AI Service는 Rule v1 계산 경로를 가리키며, 생성형 AI나 LLM은 이 분석에 참여하지 않습니다.^{[1] [3]}

금융 업무 처리와 Rule 계산을 분리한 이유
거래 접수 범위와 Rule 분석 범위를 구분하기
분석 입력을 Snapshot으로 고정하기
HTTP API 버전과 Rule 엔진 버전 구분하기
FastAPI에서 Rule·점수·Evidence를 계산하는 흐름
DB 트랜잭션과 HTTP 호출을 분리한 이유
HTTP 200 응답을 그대로 채택하지 않기
탐지 결과와 Evidence를 함께 저장·채택하기
실패를 정상 분석 결과로 바꾸지 않기
본문 읽기 오류를 구분한 구현·리뷰 사례
테스트로 확인하는 경계와 검증의 한계
운영 관점의 의미와 다음 글

1. 금융 업무 처리와 Rule 계산을 분리한 이유

금융 거래의 업무 상태를 관리하는 코드와 분석을 계산하는 코드를 분리하되, 두 서비스가 같은 데이터를 제각각 확정하지 않도록 책임을 나눴습니다. Spring Boot가 거래와 분석 시도의 상태, 결과 채택과 영속화를 소유하고, FastAPI는 전달받은 Snapshot으로 Rule 결과를 계산합니다.^{[1] [3]}

☕ Spring Boot — 업무 상태와 결과 채택

분석 대상 거래를 확인하고, 필요한 거래·행동 이벤트·RuleVersion을 고정합니다. 분석 시도와 버전을 기록한 뒤 FastAPI를 호출하고, 응답을 검증하여 탐지 결과와 Evidence를 저장합니다. 어떤 결과를 거래의 현재 분석 결과로 채택할지도 Spring Boot가 결정합니다.

FastAPI — Rule 분석 계산

요청 DTO를 내부 도메인 입력으로 변환하고, 실행 가능한 RuleVersion인지 재검증합니다. 실행 계획에 따라 Rule을 평가한 뒤 점수·위험 등급·Evidence를 계산해 반환합니다. 업무 DB 조회·수정, 거래 대응 확정, 사건 최종 판정은 수행하지 않습니다.

이 구조에서 Spring Boot는 금융 업무의 소유권을 유지하고, FastAPI는 분석 계산의 경계를 가집니다. Python의 분석 경로를 수정할 때도 거래·사건의 저장 책임이 함께 이동하지 않도록 한 선택입니다. 다만 서비스를 분리한 만큼 통신 실패, 계약 호환성, 배포 버전 차이를 명시적으로 다뤄야 한다는 비용도 받아들였습니다.

계산 책임을 분리하는 것과 업무 상태의 최종 책임을 분산하는 것은 다른 문제입니다.

2. 거래 접수 범위와 Rule 분석 범위를 구분하기

거래 API의 입력 계약과 분석 엔진의 처리 범위는 같은 목록이 아닙니다. 거래 접수 모델은 계좌이체, 오픈뱅킹 이체, ATM 인출, 대출 실행 Mock을 표현하지만, 이 글에서 다루는 Rule v1은 두 이체 유형만 평가합니다. 입력 검증을 통과할 수 있다는 사실을 모든 유형의 분석·최종 처리까지 지원한다는 뜻으로 해석하지 않습니다.^{[3] [4]}

Rule v1 분석 대상
ACCOUNT_TRANSFER
OPEN_BANKING_TRANSFER

Rule v1 분석 대상이 아닌 유형
ATM_WITHDRAWAL
LOAN_DISBURSED

행동 이벤트도 접수 API의 9개 유형 전체를 분석 요청에 그대로 복제하지 않았습니다. Rule v1에 필요한 다음 네 유형 중, 실제 실행할 Rule이 요구하는 이벤트를 조회해 사용합니다.^{[2] [4]}

DEVICE_REGISTERED
PASSWORD_CHANGED
TRANSFER_LIMIT_CHANGED
BENEFICIARY_REGISTERED

지원하지 않는 입력은 정상 미적중이 아닙니다

Rule v1이 지원하지 않는 거래 유형을 임의의 0점·LOW로 통과시키지 않습니다. “분석했지만 적중한 Rule이 없음”과 “이 엔진으로 분석할 수 없음”은 구분해야 하기 때문입니다. 새 거래 유형 지원에는 별도의 Rule 계약과 검증이 필요합니다.^[3]

3. 분석 입력을 Snapshot으로 고정하기

분석이 시작된 뒤에도 DB를 계속 조회하면, 거래를 읽은 시점과 행동 이벤트를 읽은 시점, Rule 버전을 읽은 시점이 달라질 수 있습니다. FinGuardOps에서는 한 번의 분석이 사용할 데이터를 먼저 고정하고, 이후의 HTTP 호출은 DB Entity가 아닌 독립된 요청 객체로 수행하도록 구성했습니다.^{[1] [2]}

3.1 평가 기준 시각을 하나로 고정하기

T = FinancialTransaction.occurredAt
evaluationCutoffAt = T

행동 이벤트 시간 범위
T - 24시간 ≤ event.occurredAt ≤ T

평가 기준은 서버의 현재 시각이나 FastAPI 호출 시각이 아니라 저장된 거래의 발생 시각입니다. 예를 들어 거래가 10시에 발생하고 분석 요청이 10시 2분에 시작되더라도, 이 실행의 기준 시각은 10시로 유지합니다. 거래 시각, 행동 이벤트 조회 범위, Rule 적용 기간과 응답의 cutoff 검증이 같은 기준을 사용합니다.^{[1] [4]}

최근 24시간 시간창은 양 끝을 포함합니다. 정확히 T - 24시간 또는 T에 발생한 이벤트는 포함하고, 범위를 벗어난 이벤트는 제외합니다. 분석 시작 후 늦게 들어온 이벤트가 발생 시각상 범위 안에 있더라도, 이미 고정한 이번 요청의 Snapshot에는 다시 끼워 넣지 않습니다.^{[1] [4]}

3.2 필요한 행동 이벤트만, 정해진 순서로 가져오기

같은 고객의 이벤트
+ 실행할 Rule에 필요한 이벤트 유형
+ 포함 범위 안의 occurredAt

ORDER BY occurredAt DESC, eventId ASC
최대 1,000건

시각이 같은 이벤트에도 업무 식별자인 eventId를 보조 정렬로 사용합니다. 같은 시각의 여러 이벤트 중 하나를 근거로 선택할 때 입력 순서가 임의로 달라지지 않도록 하기 위해서입니다. Snapshot 상한은 요청 크기와 분석 입력을 제한하는 경계이며, 적격 이벤트가 1,000건을 초과하면 더 오래된 이벤트는 이번 분석에 포함하지 않습니다.^{[1] [2] [4]}

Snapshot의 범위가 곧 이번 분석의 범위

1,000건 제한을 두었다고 해서 고객의 전체 이력을 분석했다고 말할 수는 없습니다. 이 글의 분석은 해당 실행에서 고정한 입력을 기준으로 합니다. 상한과 늦게 도착한 이벤트 처리 방식은 탐지 품질과 연결되는 제약으로 남겨 둡니다.

3.3 실행 가능한 RuleVersion 집합 고정하기

FraudRule.lifecycleStatus = ACTIVE
RuleVersion.status = PUBLISHED

effectiveFrom ≤ T < effectiveTo
※ effectiveTo가 null이면 상한 없음

실행 가능한 버전 전체를 한 번에 고정하고, 같은 Rule의 복수 버전이나 지원하지 않는 설정·의존성을 정상 결과로 보정하지 않습니다. 실행 집합이 비어 있는 경우도 “모두 미적중”이 아니라 실행 계획 오류로 구분합니다. Spring Boot는 이 집합으로 예상 ruleSetVersion을 계산해 분석 시도에 기록합니다.^{[1] [2]}

여기서 Snapshot을 고정한다는 말은 요청용 불변 값을 구성한다는 뜻입니다. 거래·행동·외부 Provider의 전체 원문을 모두 하나의 JSON 컬럼에 영구 보관한다는 의미는 아닙니다. 특히 ExternalRiskSnapshot은 이 HTTP 분석 입력을 위한 인메모리 값이며, 원문 복제 저장과는 구분합니다.^{[1] [3]}

4. HTTP API 버전과 Rule 엔진 버전 구분하기

Rule 분석에는 /api/v1/rule-analysis와 /api/v2/rule-analysis가 있습니다. 여기서 v2는 Rule 알고리즘을 Rule v2로 바꿨다는 뜻이 아니라, 필수 externalRisk를 추가한 HTTP 요청 계약의 버전입니다. 계산 엔진은 Rule v1 R001~R004를 유지합니다.^[3]

POST /api/v2/rule-analysis
Content-Type: application/json
X-Trace-Id: trace_rule_analysis_demo_01

Rule Analysis 요청 v1
├─ evaluationCutoffAt
├─ transaction
├─ behaviorEvents
└─ ruleVersions

Rule Analysis 요청 v2
├─ evaluationCutoffAt
├─ transaction
├─ behaviorEvents
├─ ruleVersions
└─ externalRisk  ← 필수·non-null

기존 v1에 optional 필드를 덧붙이거나, 외부 조회가 빠졌을 때 기본 UNMATCHED를 넣어 호환되는 척하지 않았습니다. 상위 거래 처리 흐름이 External Risk를 먼저 조회하고 성공한 Snapshot을 고정한 뒤 v2 입력에 전달합니다. Provider 조회·실패 분류의 상세는 다음 편에서 다룹니다.^[3]

동시에 정보를 전달한다는 것과 점수에 사용한다는 것도 구분했습니다. v2는 외부 위험정보의 입력 계약을 검증하지만 기존 Rule v1 점수 정책에 외부 위험 점수를 더하지 않습니다. 관련 통합 테스트도 Snapshot 전달과 기존 점수 유지 조건을 함께 확인하도록 작성되어 있습니다.^{[3] [9]}

같은 “버전”이라는 이름이어도 소유하는 의미가 다릅니다

HTTP API version
→ 서비스 간 요청·응답 형식

ruleSetVersion
→ 어떤 불변 RuleVersion 집합을 어떤 순서로 실행했는가

detectionResultVersion
→ 같은 거래에서 몇 번째 분석 시도인가

scoringPolicyVersion
→ 어떤 점수 합산·그룹 상한·등급 정책인가

이 값을 하나로 합치지 않으면 통신 형식을 바꾸는 작업과 탐지 정책을 바꾸는 작업을 구분할 수 있습니다. 과거 결과가 참조한 버전을 최신 정책 이름으로 덮어쓰지 않는 것도 같은 이유입니다.^{[1] [4]}

⚙️ 5. FastAPI에서 Rule·점수·Evidence를 계산하는 흐름

FastAPI Endpoint는 HTTP 요청을 받고 응답 DTO로 변환하는 역할에 집중합니다. 분석 서비스는 요청 매핑, 실행 계획, Rule 평가, 점수 계산, Evidence 변환을 순서대로 조합합니다.^[5]

요청 DTO
→ RuleAnalysisRequestMapper
→ RuleExecutionPlanBuilder
→ RuleExecutionPlanRunner
→ RuleScoringCalculator
→ RuleEvidenceTransformer
→ RuleAnalysisResponseMapper

실제 코드 발췌 · ai-service의 RuleAnalysisService.analyze()

def analyze(self, request: RuleAnalysisRequest) -> RuleAnalysisResult:
    execution_input = RuleAnalysisRequestMapper.to_domain(request)
    plan = self.plan_builder.build(
        execution_input.evaluation_cutoff_at,
        execution_input.rule_versions,
    )
    planned_results = self.plan_runner.execute(plan, execution_input.rule_input)
    scoring_result = RuleScoringCalculator.calculate(plan, planned_results)
    return RuleEvidenceTransformer.transform(plan, planned_results, scoring_result)

계획을 만드는 단계는 RuleVersion의 상태·기간·의존성을 확인하고, Runner는 그 계획에 따라 evaluator를 실행합니다. Scoring은 이미 나온 적중 결과를 합산하며, Evidence 변환은 평가에 사용한 근거를 응답 계약에 맞춰 구성합니다. 점수를 계산하는 단계에서 행동 이벤트를 다시 선택하거나 Rule 적중 여부를 보정하지 않습니다.^{[4] [5]}

5.1 네 Rule이 실제로 판단하는 것

R001 — 절대 고액 이체. 대상 이체에서 KRW 1,000만 원 이상인지 확인합니다. 고객의 평균 금액이나 과거 거래 합계와 비교하는 Rule은 아닙니다.^[4]

R002 — 최근 기기 등록 이벤트가 있는 고액 이체. R001 적중을 전제로, 같은 고객·같은 기기의 DEVICE_REGISTERED 이벤트가 최근 24시간 안에 있는지 확인합니다.^[4]

R003 — 최근 보안정보 변경 시퀀스가 있는 고액 이체. R001 적중을 전제로, 같은 고객의 비밀번호 변경과 해당 출금 계좌의 한도 변경이 비밀번호 변경 ≤ 한도 변경 ≤ 거래 시각 순서로 존재하는지 확인합니다. 두 이벤트 모두 시간창 안에 있어야 합니다.^[4]

R004 — 최근 등록 수취인 이체. 같은 고객·출금 계좌·수취인에 대응하는 BENEFICIARY_REGISTERED 이벤트가 최근 24시간 안에 있는지 확인합니다. 이 Rule에는 고액 조건이 없습니다.^[4]

관측한 신호보다 강한 의미를 붙이지 않기

최근 기기 등록 이벤트가 있다는 사실만으로 “실제로 처음 사용하는 기기”를 완전히 증명하지는 못합니다. 한도 변경 이벤트도 변경 전후 값이 없으므로 실제 한도 상향 여부를 뜻하지 않습니다. 최근 수취인 등록 역시 과거 거래 관계가 전혀 없었음을 보장하지 않습니다. Rule의 설명은 입력으로 확인할 수 있는 사실에 맞췄습니다.^[4]

5.2 Evidence 합계와 최종 위험 점수가 다를 수 있는 이유

Rule v1은 개별 Rule의 원래 기여도와 그룹 상한 적용 결과를 따로 유지합니다. R001은 amount 그룹, R002~R004는 security 그룹으로 묶습니다. 아래는 네 Rule이 모두 적중했다고 가정한 정책 계산 예시이며, 실제 금융 데이터로 성능을 측정한 결과가 아닙니다.^[4]

원래 Rule 기여도
R001 = 15
R002 = 20
R003 = 40
R004 = 10
합계 = 85

amount 그룹   : min(15, 15) = 15
security 그룹 : min(60, 70) = 60

최종 riskScore = min(100, 15 + 60) = 75
scoring-policy-v1의 riskLevel = HIGH

Evidence의 scoreContribution은 그룹 상한 적용 전 값입니다. 따라서 Evidence 합계가 85이고 최종 점수가 75인 것은 오류가 아닙니다. 그룹에서 차감한 10점을 개별 Evidence에 임의로 나눠 적지 않고, 그룹 summary로 설명합니다. 이 가중치와 위험 등급 경계는 구현·검증을 위한 초기 실험 정책이며, 운영 데이터로 최적화된 탐지 성능을 의미하지 않습니다.^[4]

6. DB 트랜잭션과 HTTP 호출을 분리한 이유

외부 서비스가 응답할 때까지 하나의 DB 트랜잭션을 유지하면, 분석 지연을 기다리는 동안 업무 잠금과 트랜잭션 자원을 오래 붙잡을 수 있습니다. FinGuardOps에서는 분석 시작과 결과 채택을 각각의 트랜잭션으로 처리하고, 그 사이에 HTTP 호출을 배치했습니다.^{[1] [6]}

분석 시작과 결과 채택의 DB 트랜잭션 사이에 외부 HTTP 호출을 분리한 처리 구조

6.1 분석 시작 — 입력과 분석 시도를 함께 확정

startAnalysisV2()는 REQUIRES_NEW와 REPEATABLE_READ를 사용합니다. 거래를 먼저 잠그고 시작 가능한 상태인지 확인한 뒤, Snapshot을 조립하고 External Risk를 v2 요청으로 매핑합니다. 매핑이 성공한 다음에만 새 분석 버전을 할당하고 분석 시도와 거래 상태를 저장합니다.^[6]

실제 코드 발췌 · RuleAnalysisPersistenceService.startAnalysisV2()

@Transactional(
        propagation = Propagation.REQUIRES_NEW,
        isolation = Isolation.REPEATABLE_READ
)
public StartedRuleAnalysisV2Execution startAnalysisV2(
        UUID transactionId,
        ExternalRiskSnapshot externalRiskSnapshot,
        String scoringPolicyVersion,
        String featureVersion,
        String modelVersion,
        String analysisTraceId,
        Instant startedAt
) {
    PreparedRuleAnalysisStart prepared = prepareStart(transactionId);
    RuleAnalysisRequestV2 request = requestV2Mapper.map(
            prepared.snapshot().request(),
            externalRiskSnapshot
    );
    StartedRuleAnalysis started = persistStart(
            prepared,
            scoringPolicyVersion,
            featureVersion,
            modelVersion,
            analysisTraceId,
            startedAt
    );
    return new StartedRuleAnalysisV2Execution(started, request);
}

이때 거래는 RECEIVED → ANALYZING, 탐지 결과는 같은 시작 트랜잭션 안에서 PENDING → IN_PROGRESS로 전이합니다. HTTP 호출은 이 시작 경계의 Commit 이후에만 실행됩니다. 입력 조립이나 v2 매핑이 실패하면 생성하지 못한 분석 시도를 실패 결과로 억지로 만들지 않습니다.^{[1] [6] [9]}

6.2 HTTP 호출 — 활성 DB 트랜잭션 없이 실행

오케스트레이터에 @Transactional을 붙이지 않는 것에서 끝내지 않았습니다. 상위 호출자가 이미 트랜잭션을 시작했을 가능성도 있으므로, 진입 시점과 HTTP 호출 전 활성 트랜잭션이 없는지 검사합니다.^[6]

실제 코드 발췌 · RuleAnalysisOrchestrationService

private void requireNoActiveTransaction() {
    if (TransactionSynchronizationManager.isActualTransactionActive()) {
        throw new IllegalStateException(
                "Rule analysis orchestration requires no active transaction"
        );
    }
}

REQUIRES_NEW만으로 외부 트랜잭션 문제가 없어지지는 않습니다

Spring 공식 문서의 전파 의미를 함께 보면, REQUIRES_NEW는 독립된 물리 트랜잭션을 사용하지만 기존 외부 트랜잭션의 자원은 유지된 채 내부 트랜잭션이 별도 연결을 얻을 수 있습니다. 즉 “내부 메서드를 REQUIRES_NEW로 만들었으니 외부 호출 동안 DB 자원도 모두 해제된다”는 해석은 맞지 않습니다.^[11]

이 프로젝트에서는 활성 외부 트랜잭션이 있는 오케스트레이션 호출 자체를 거부하고, DB 쓰기 경계를 분리한 뒤 HTTP 호출로 넘어갑니다. Connection Pool 고갈 개선률을 측정했다는 주장이 아니라, 트랜잭션 수명을 통제하기 위한 구조입니다.^[6]

6.3 결과 채택 — 다시 짧은 쓰기 경계로 진입

검증된 응답을 받은 뒤에는 completeAndAdopt()의 별도 REQUIRES_NEW 트랜잭션으로 들어갑니다. 이 메서드에는 시작 경계와 달리 REPEATABLE_READ가 명시되어 있지 않습니다. 거래와 탐지 결과를 잠그고 상태·소유 관계를 다시 확인한 뒤 결과를 반영합니다.^[6]

동기 HTTP 요청 하나 안에서 처리하더라도 전체 흐름이 단일 DB 트랜잭션인 것은 아닙니다. 분석 시작, HTTP 호출, 결과 채택의 경계를 분리한 만큼 중간 상태와 실패 기록을 명시적으로 관리해야 한다는 Trade-off가 생깁니다.

️ 7. HTTP 200 응답을 그대로 채택하지 않기

FastAPI가 200을 반환했다는 사실은 통신 수준의 성공 신호입니다. 다른 거래의 결과, 요청과 다른 Rule 집합, 맞지 않는 점수와 Evidence까지 그대로 업무 결과로 받아들이지는 않습니다. Client의 HTTP 검증과 별도 RuleAnalysisResponseValidator를 통해 응답을 검증합니다.^[7]

7.1 통신 형식과 Trace 확인

요청 X-Trace-Id
= 응답 X-Trace-Id
= 응답 body.traceId

응답 Content-Type: application/json
알 수 없는 필드·필수값 누락·타입 강제 변환 거부
잘못된 JSON·후행 JSON 토큰 거부

Client 전용 strict ObjectMapper를 사용해 분석 응답 계약을 검증합니다. Trace 헤더가 누락·중복되거나 body의 Trace와 다르면 정상 응답으로 채택하지 않습니다. 내부 서비스라고 해서 요청과 응답의 연결을 확인하지 않아도 된다고 가정하지 않았습니다.^{[7] [10]}

7.2 분석 대상과 Rule 집합의 정확한 일치

response.transactionId == request.transaction.transactionId
response.analysis.evaluationCutoffAt == request.evaluationCutoffAt
response.analysis.ruleSetVersion == expectedRuleSetVersion

위 표현은 검사 항목을 요약한 것입니다. ruleSetVersion은 64자리 해시 형식만 맞으면 통과하는 값이 아닙니다. 요청의 RuleVersion 집합으로 계산한 예상 값과 정확히 같은지 비교합니다. 형식이 올바르지만 다른 집합의 해시라면 거부합니다.^[7]

7.3 점수와 Evidence의 일관성

응답의 Rule contribution 개수·순서·중복, 적중 여부와 원래 기여도, 그룹별 상한과 최종 점수, 위험 등급의 조합을 검사합니다. Evidence 역시 적중 Rule에 대응해야 하며, Reason Code별 허용 필드와 요청 Snapshot의 행동 이벤트 ID·시각·관측값이 맞는지 확인합니다.^[7]

여기서 Rule 재판정과 결과 정합성 검증을 구분했습니다. Spring Boot가 Python evaluator를 별도로 실행해 적중 여부를 다시 만드는 것은 아닙니다. 반환된 contribution의 합계와 그룹 상한, 근거의 대응 관계는 검산하되, 틀린 응답을 재정렬하거나 누락 항목을 보충해 성공으로 바꾸지 않습니다.^[7]

내부 서비스의 결과도 검증 대상입니다. 검증 실패는 응답을 고쳐 쓸 계기가 아니라, 그 결과를 업무 데이터로 채택하지 않을 근거입니다.

8. 탐지 결과와 Evidence를 함께 저장·채택하기

검증을 마친 결과를 저장할 때에는 탐지 결과와 근거가 서로 분리되어 남지 않도록 했습니다. completeAndAdopt()는 거래와 탐지 결과를 순서대로 잠그고, 거래가 ANALYZING, 결과가 IN_PROGRESS인지 확인합니다. 잠긴 거래의 분석 결과인지, 시작 당시의 식별자·버전 정보와 맞는지도 검증합니다.^[6]

실제 코드 발췌 · completeAndAdopt()의 검증 이후 저장 부분

evidenceRepository.saveAllAndFlush(evidence);

result.complete(riskScore, riskLevel, completedAt);
detectionResultRepository.saveAndFlush(result);

transaction.adoptDetectionResult(result);
transactionRepository.saveAndFlush(transaction);

위 코드는 별도 Commit 세 번이 아니라 같은 메서드의 한 트랜잭션 안에서 수행되는 flush 순서입니다. 뒤 단계에서 실패해 이 트랜잭션이 Rollback되면 앞서 flush한 Evidence도 함께 되돌아가야 합니다. 관련 통합 테스트는 이 저장 경계를 검증하도록 구성되어 있습니다.^{[6] [9]}

근거의 표시 정보도 소유권을 나눴습니다

FastAPI가 반환하는 Evidence에는 Rule·Reason Code와 관측 근거가 포함됩니다. 내부 DB 식별자, evidenceId, 표시 설명과 영속 정렬 순서는 Spring Boot의 매핑 계층에서 다룹니다. 특히 FastAPI의 1부터 시작하는 executionOrder와, 적중 Evidence에 대해 0부터 연속으로 부여하는 영속 sortOrder를 같은 값으로 취급하지 않습니다.^{[3] [4]}

분석 완료와 최종 거래 성공은 다릅니다

DetectionResult = COMPLETED
Transaction = ANALYZED

→ 분석 결과를 저장·채택한 상태
→ 위험 대응·고위험 사건 연결·최종 멱등 응답 확정과는 구분

Rule 분석 경계가 성공한 뒤에도 상위 흐름의 위험 대응과 사건 연결이 남아 있습니다. 따라서 FastAPI의 200 OK나 거래의 ANALYZED를 공개 거래 API의 최종 성공과 같은 의미로 쓰지 않습니다. 최종 성공과 Snapshot 완료 간극은 별도 계약으로 관리합니다.^[1]

9. 실패를 정상 분석 결과로 바꾸지 않기

실패를 다룰 때는 오류 이름뿐 아니라 분석 시도가 생성되기 전인지, 생성된 뒤인지, 결과를 채택하던 중인지를 구분했습니다. 같은 예외 처리 블록에서 모두 LOW로 변환하면 정상적인 미적중 결과와 분석 불능 상태를 구분할 수 없기 때문입니다.^{[1] [6]}

9.1 시작 단계의 실패

Snapshot 조립이나 v2 매핑이 실패하면 시작 트랜잭션은 Rollback되고 HTTP 호출은 실행하지 않습니다. 시작 트랜잭션이 정상적으로 Rollback된 경계에서는 거래가 RECEIVED에 남고 새 DetectionResult·Evidence가 생성되지 않습니다. 존재하지 않는 분석 결과에 FAILED를 기록하려고 하지 않습니다.^{[6] [9]}

9.2 시작 이후 호출·변환·채택 단계의 실패

시작이 Commit된 뒤 Client 호출이 실패하면 Client 오류 범주를 사용하고, 일반 호출 오류·응답 매핑 오류·채택 오류도 별도로 구분합니다. 결과 채택이 실패해 Rollback되면 별도의 실패 기록 트랜잭션을 호출합니다. 이 실패 경계도 거래·탐지 결과의 소유 관계와 처리 중 상태를 확인한 후 변경합니다.^[6]

HTTP 호출 일반 실패
→ RULE_ANALYSIS_HTTP_CALL_FAILED

응답 매핑 실패
→ RULE_ANALYSIS_RESPONSE_MAPPING_FAILED

결과 채택 실패
→ RULE_ANALYSIS_ADOPTION_FAILED

이 문자열은 내부 분석 단계의 실패 분류입니다. 외부 REST API가 같은 원문을 그대로 공개한다는 뜻은 아닙니다. 공개 오류와 내부 진단 정보를 분리하는 것은 #5에서 다룬 오류 계약과 같은 원칙입니다.^{[1] [6]}

9.3 실패 기록도 실패할 수 있습니다

실제 코드 발췌 · RuleAnalysisOrchestrationService.recordFailure() 본문

try {
    persistenceService.failAnalysis(
            started,
            failureCode,
            clock.instant()
    );
} catch (RuntimeException recordingFailure) {
    if (recordingFailure != original) {
        original.addSuppressed(recordingFailure);
    }
}
return original;

실패 기록 과정의 예외가 최초 장애를 덮어쓰지 않도록 원래 예외를 유지하고 보조 예외로 연결합니다. 이는 실패 상태가 항상 저장된다는 보장이 아닙니다. 프로세스 종료나 저장소 장애로 확정 여부를 확인할 수 없는 중간 상태는 자동 재분석이나 임의의 성공 변환으로 해결하지 않고, 별도의 복구 계약에서 다뤄야 합니다.^{[1] [6]}

정상 미적중과 분석 실패를 구분합니다

유효한 Rule 실행 결과가 미적중
→ 0점·LOW·빈 Evidence 가능

HTTP·입력 계약·응답·영속화 실패
→ 0점·LOW·빈 Evidence로 대체하지 않음

분석 Client에는 자동 retry와 fallback을 두지 않았습니다. 호출 구간에 도달한 분석 시도는 HTTP 요청을 한 번 수행합니다. 시작 전 실패는 0회, 정상 호출 경로는 1회라는 의미이며, 시스템 전체의 모든 장애 상황에서 “정확히 한 번 실행”을 보장한다는 주장은 아닙니다.^{[1] [9]}

생성형 AI 리포트의 템플릿 fallback은 별도 기능입니다. Rule 분석 실패를 정상 탐지 결과로 바꾸는 fallback과 혼동하지 않습니다.

10. 본문 읽기 오류를 구분한 구현·리뷰 사례

HTTP Client 구현·리뷰에서 보강한 사례는 응답 헤더를 받은 뒤 본문을 읽는 동안 발생하는 오류의 분류였습니다. JSON 역직렬화 중 예외가 났다고 해서 원인이 모두 잘못된 JSON인 것은 아닙니다. 정상 응답을 전송받던 중 연결이 끊기거나 읽기가 지연된 경우도 구분해야 합니다.^{[8] [10]}

검토한 문제

본문 읽기 예외를 전부 AI_SERVICE_INVALID_RESPONSE로 묶으면, 전송 장애와 응답 계약 오류가 같은 실패로 보입니다. 반대로 Jackson 예외를 모두 Timeout으로 취급하면 잘못된 응답 형식이 네트워크 장애처럼 보입니다. 따라서 “어느 라이브러리에서 예외가 나왔는가”뿐 아니라 cause chain에 실제 전송 I/O 오류가 있는지를 확인했습니다.^{[8] [10]}

분류기는 먼저 Jackson 자체가 아닌 IOException이 있는지 확인합니다. 이 조건이 없으면 본문 transport 오류 분류를 적용하지 않고, Client가 잘못된 응답으로 처리하게 둡니다. 조건이 있으면 요청의 monotonic timeout budget 경과 여부로 응답 Timeout과 가용성 실패를 구분합니다.^[8]

실제 코드 발췌 · classifyBodyReadFailure()의 분류 부분

if (!hasNonJacksonIOException(exception)) {
    return Optional.empty();
}
return Optional.of(responseTimeoutExpired.getAsBoolean()
        ? RuleAnalysisClientErrorCategory.AI_SERVICE_RESPONSE_TIMEOUT
        : RuleAnalysisClientErrorCategory.AI_SERVICE_UNAVAILABLE);

Jackson 자체의 형식·매핑 오류만 존재
→ AI_SERVICE_INVALID_RESPONSE

본문 읽기 cause chain에 non-Jackson I/O 존재
├─ response timeout budget 경과 → AI_SERVICE_RESPONSE_TIMEOUT
└─ budget 경과 전               → AI_SERVICE_UNAVAILABLE

예외 메시지에서 “timeout” 같은 문자열을 검색해 판단하지 않습니다. 같은 오류가 다른 메시지로 감싸져도 같은 범주로 분류되도록 하고, cause chain이 순환하는 경우에도 탐색이 끝나도록 identity 기반 방문 집합을 사용합니다.^[8]

회귀 테스트에 남긴 조건

doesNotClassifyJacksonOnlyFailuresAsBodyTransportErrors
→ 순수 Jackson 실패는 transport 오류로 분류하지 않음

classifiesWrappedBodyTransportIoWithoutReadingExceptionMessages
→ 감싸진 I/O 오류를 메시지 문자열과 무관하게 분류

stopsBodyReadCauseTraversalWhenTheCauseChainContainsACycle
→ 원인 체인이 순환해도 탐색 종료

이 사례는 운영 환경에서 장애가 발생했다고 꾸민 이야기가 아니라, HTTP Client 구현·리뷰와 회귀 테스트에 남아 있는 예외 경계 보강입니다. 네트워크 장애와 계약 오류를 구분해야 로그·메트릭을 읽을 때도 원인 후보를 다르게 좁힐 수 있다는 점을 보여줍니다.^{[8] [10]}

11. 테스트로 확인하는 경계와 검증의 한계

테스트는 통과 개수뿐 아니라 어떤 경계를 실제로 실행하고 무엇을 대체했는지까지 함께 봐야 합니다. Rule 계산, HTTP Client, PostgreSQL 영속 경계와 실제 서비스 간 E2E는 서로 다른 검증입니다. 이 글에서는 테스트 코드의 기대 조건과 구현 당시 PR에 남긴 실행 결과를 분리해 설명합니다.^{[9] [10]}

11.1 고정 입력·Rule 계약

시간창 양 끝, 동일 시각의 이벤트 선택 순서, R001 선행 조건, R003의 시퀀스, 그룹 상한과 Evidence 대응이 검증 기준입니다. 정해진 입력과 버전에서 같은 계산 결과를 얻어야 하며, 실행 계획 오류를 부분 성공으로 보정하지 않는지도 확인 대상으로 둡니다.^[4]

11.2 HTTP 호출 시점의 Commit과 트랜잭션 상태

RuleAnalysisOrchestrationIntegrationTest는 PostgreSQL을 사용하는 영속 경계에서 Client 호출 시점의 거래·분석 상태를 조회하도록 구성되어 있습니다. 아래는 v2 테스트에 정의된 assertion 일부입니다.^[9]

실제 테스트 assertion 발췌 · v2CallsOnlyV2ClientAfterCommitAndDoesNotScoreExternalRisk()

assertThat(transactionActive).isFalse();
assertThat(committedState.get())
        .containsEntry("processing_status", "ANALYZING")
        .containsEntry("analysis_status", "IN_PROGRESS");
assertCompletedState(completed, 15, RiskLevel.MEDIUM, 1);

이 테스트에서 확인하려는 것은 “응답이 나왔다”가 아니라, HTTP Client를 호출하기 전에 시작 상태가 Commit되었고 그 호출 시점에는 활성 트랜잭션이 없다는 조건입니다. v2 Client만 한 번 호출하고 v1 Client는 호출하지 않는 조건, 전달한 External Risk Snapshot 때문에 기존 Rule 점수가 바뀌지 않는 조건도 포함합니다.^[9]

11.3 Rollback·무호출·정상 미적중

v2MapperFailureRollsBackBeforeHttpAndFailurePersistence
→ 매핑 실패 시 새 분석 결과·Evidence 없음, HTTP 무호출

rollsBackFlushedEvidenceBeforeRecordingAdoptionFailure
→ 채택 실패 시 앞서 flush한 Evidence도 Rollback

rejectsAnOuterTransactionBeforeCreatingAnAnalysisAttempt
→ 외부 트랜잭션이 있으면 분석 시도 생성 전에 거부

adoptsValidatedZeroLowResultWithEmptyEvidence
→ 정상적인 0점·LOW·빈 Evidence는 채택 가능

이 메서드명과 조건은 저장소의 통합 테스트에 정의되어 있습니다. 단, 이 테스트는 RuleAnalysisHttpClient를 @MockitoBean으로 대체합니다. 따라서 PostgreSQL 쓰기·Rollback 경계를 검증하는 테스트이지, 실제 FastAPI 프로세스와 DNS·TLS까지 연결한 E2E 테스트는 아닙니다.^[9]

11.4 구현 당시 기록한 실행 결과

HTTP Client 구현 당시 PR에는 아래 두 테스트 클래스를 대상으로 실행한 결과가 기록되어 있습니다. 해당 변경을 검증한 시점의 기록이며, 이후 추가된 v2·전체 오케스트레이션 테스트까지 같은 수치로 검증했다는 의미는 아닙니다.^[10]

HTTP Client 구현 PR에 기록된 명령·결과 발췌

.\gradlew.bat test --tests *RuleAnalysisHttpClientTest --tests *RuleAnalysisTransportErrorClassifierTest --console=plain

2 suites
33 tests
33 success
0 failures
0 errors
0 skipped
BUILD SUCCESSFUL

실제 OS 네트워크에서의 connect timeout은 당시 검증 범위에서 제외했고, 설정값 적용과 HttpConnectTimeoutException 우선 분류 등을 결정적으로 검사했다고 기록했습니다. 이를 실제 네트워크 전체의 장애 복구 검증으로 확대해 해석하지 않습니다.^[10]

재실행할 수 있는 PostgreSQL 경계 테스트

.\gradlew.bat integrationTest --tests "*RuleAnalysisOrchestrationIntegrationTest" --rerun-tasks --console=plain

위 명령은 backend 디렉터리에서 Java 17과 Docker/Testcontainers 실행 환경을 준비한 뒤 사용하는 재검증 명령입니다. 실행 결과는 해당 코드 버전과 환경에서 나온 테스트 리포트로 확인해야 합니다. 위의 33개 성공 기록과 이 명령의 실행 결과를 합쳐 적지 않습니다.^{[9] [12]}

☁️ 12. 운영 관점의 의미와 다음 글

이번 연동에서 중요하게 본 것은 기술 스택 사이에 화살표를 하나 더 그리는 일이 아니라, 어떤 입력을 신뢰하고 어떤 결과를 언제 업무 상태로 확정할 것인지였습니다. Spring Boot와 FastAPI를 분리한 뒤에도 거래 상태와 검증된 결과의 소유권은 분명하게 유지해야 했습니다.

운영에서 읽을 수 있는 정보로 남기기

분석 입력의 cutoff와 버전은 어떤 기준으로 계산했는지를 설명하고, Trace는 요청과 응답을 연결합니다. HTTP 호출·매핑·채택 실패를 구분하면 같은 “분석 실패”라도 어느 단계부터 확인할지 정할 수 있습니다. 오케스트레이터의 메트릭 기록은 업무 결과를 덮어쓰지 않도록 분리되어 있으며, 상세 대시보드와 수집 환경은 Observability 편에서 다룹니다.^{[1] [6] [7]}

이 구조만으로 모든 장애가 해결되었다고 말하지는 않습니다. 서비스 분리에는 통신 계약 관리가 필요하고, 엄격한 응답 검증은 버전 불일치에 대한 명시적 대응을 요구합니다. 자동 재시도를 제외한 대신 일시적 실패도 사용자 오류 응답과 운영 절차로 이어질 수 있으며, 입력 상한을 두면 그 범위 밖의 근거는 분석에 포함되지 않습니다. 이러한 제한을 감추지 않는 것이 이후 확장 기준이 됩니다.^{[1] [2] [3]}

이번 글에서 확정한 경계

분석 입력과 버전을 고정하고, 외부 HTTP 호출은 DB 트랜잭션 밖에서 수행합니다. 반환된 결과는 요청과의 대응을 검증한 뒤 한 쓰기 경계에서 저장·채택하며, 실패를 정상 미적중 결과로 바꾸지 않습니다.

이 설계는 애플리케이션을 여러 인스턴스로 배포할 때도 유지해야 할 기본 조건입니다. 다만 이번 글의 코드·테스트만으로 Kubernetes 확장, 클라우드 네트워크 장애나 운영 수준의 복구 성능까지 검증했다고 주장하지 않습니다. 실제 배포와 장애 실험은 해당 환경의 증거로 따로 기록합니다.

다음 글에서는 이 Rule 분석보다 먼저 실행되는 External Risk 조회를 다룹니다. 조회 실패를 “위험정보 없음”으로 취급하지 않기 위해 Timeout·가용성 장애·잘못된 응답을 어떻게 구분하고, 어떤 성공 Snapshot만 다음 단계로 넘기는지 정리하겠습니다.

[FinGuardOps #5] 중복과 잘못된 입력을 막는 거래·행동 이벤트 API와 Validation 설계

bbbicsan — Sat, 5 Sep 2026 23:35:02 +0900

FinGuardOps Project Series #5

앞선 글에서는 거래·사건 상태와 멱등성 규칙을 나누고, 이를 PostgreSQL의 관계와 제약조건으로 표현하는 기준을 정리했습니다. 이번에는 그 모델의 바깥쪽, 외부 요청이 처음 들어오는 REST API 경계를 살펴보겠습니다.

계좌이체인데 수취 계좌가 없거나, ATM 인출인데 이체 채널이 지정되거나, 같은 이벤트 식별자에 서로 다른 내용이 전달된다면 어떻게 처리해야 할까요? JSON을 읽을 수 있다는 사실만으로 업무적으로 유효한 요청이라고 볼 수는 없습니다.

저는 이 문제를 형식 검증, 업무 규칙 검증, 요청 동일성 확인, 저장 시 경쟁 제어로 나누었습니다. 특히 거래 생성과 행동 이벤트 수집은 모두 중복을 다루지만, 같은 멱등성 구조를 그대로 적용하지 않았습니다.

Validation은 DTO에 어노테이션을 붙이는 작업에서 끝나지 않습니다. 잘못된 입력이 금융 업무 상태로 들어오는 것을 막고, 재전송과 충돌을 구분하는 첫 번째 정합성 경계입니다.

이 글은 POST /api/v1/transactions와 POST /api/v1/behavior-events의 계약 및 구현 구조를 중심으로 설명합니다. Rule 계산, 외부 위험정보 장애 처리의 상세와 사건 최종화는 다음 글에서 이어갑니다.^[1]

Client 요청부터 후속 분석 연결까지의 거래 API 입력 검증 흐름과 오류 분류

그림 보충: 재생은 충돌 응답과 구분합니다

그림의 ‘중복 / 충돌’ 카드에 있는 ‘같은 Key + 같은 Fingerprint → 기존 결과 재생’은 처리가 완료된 경우입니다. 재생 자체가 409라는 뜻은 아닙니다. 같은 요청이 IN_PROGRESS이면 409 IDEMPOTENCY_REQUEST_IN_PROGRESS, COMPLETED이면 저장된 성공 응답, 확정 실패이면 저장된 실패를 반환합니다. 위 가로 흐름은 신규 요청이 진행하는 경로이며, 재생 분기는 거래 저장과 분석을 다시 실행하지 않습니다.^[4]

또한 마지막 카드의 500 예시에 표시된 ‘데이터베이스 연결 실패’를 모두 500으로 분류하지는 않습니다. 본문에서 설명하는 행동 이벤트 저장소 오류 경계는 확인된 Timeout·일시적 가용성 실패는 503, 그 밖의 내부 오류는 500으로 구분합니다.^[5]

인증·인가 거절은 401·403으로 별도 구분합니다. 거래 접수 구현의 필수 Provider 가용성 점검은 멱등 선점보다 앞에 있으며, 실제 External Risk 조회는 신규 업무 처리 경로에서 수행됩니다.^{[4] [8] [9]}

유효하지 않은 요청을 거래 상태로 만들지 않기
거래 API와 행동 이벤트 API의 책임 구분
금액·시간·식별자를 명확하게 표현하기
거래 생성 요청과 최종 성공 응답
⚙️ JSON 파싱·필드 검증·교차 필드 검증 나누기
행동 이벤트 API와 조건부 필드
거래가 존재한다는 사실만으로 연결을 허용하지 않기
같은 중복 방지에 서로 다른 전략을 적용한 이유
동시 INSERT와 실패 트랜잭션의 재조회 경계
오류 응답도 클라이언트와의 계약으로 다루기
성공 응답뿐 아니라 거절·중복·무저장을 확인하는 테스트
☁️ 운영 관점의 의미와 남겨 둔 경계
마치며: 검증된 데이터를 분석 경계로 넘기기

1. 유효하지 않은 요청을 거래 상태로 만들지 않기

거래 상태는 시스템이 접수한 유효한 금융 업무를 표현해야 합니다. 요청 형식부터 잘못된 데이터를 저장하기 위해 임의의 거래를 생성하면, 정상 접수 건수와 입력 거절 건수가 같은 데이터에 섞이게 됩니다.

형식 또는 도메인 Validation 거절
→ 새 Transaction / IdempotencyRecord / BehaviorEvent를 저장하지 않음
→ External Risk·FastAPI 분석을 시작하지 않음
→ 오류 응답과 현재 요청의 traceId로 원인을 구분

여기서 “저장하지 않는다”는 해당 요청으로 신규 업무 행을 생성하지 않는다는 뜻입니다. 이미 존재하던 거래나 멱등 기록을 삭제한다는 의미는 아닙니다. 잘못된 요청의 관측에는 오류 응답·로그·메트릭을 사용하고, 거래 상태에 VALIDATION_FAILED를 추가하지 않았습니다.^{[1] [4]}

검증을 통과한 거래는 먼저 RECEIVED로 저장되지만, 접수되었다는 사실과 분석·위험 대응까지 성공했다는 사실도 구분합니다. 최종 성공 응답의 시점은 뒤의 거래 API 응답에서 다시 설명하겠습니다.

2. 거래 API와 행동 이벤트 API의 책임 구분

금융 거래 생성

POST /api/v1/transactions

계좌이체·오픈뱅킹 이체·ATM 인출·대출 실행 Mock을 접수합니다. 금액·기준 계좌·채널을 검증한 뒤 금융 업무 처리로 연결합니다.

행동 이벤트 수집

POST /api/v1/behavior-events

로그인·기기 등록·비밀번호 변경 등 관측된 행동을 저장합니다. 필요한 경우 기존 거래에 연결하지만, 이벤트 접수 자체가 새 금융 거래나 분석 실행을 뜻하지는 않습니다.

대출 실행 사실을 나타내는 LOAN_DISBURSED는 행동 이벤트가 아니라 금융 거래 유형으로 두었습니다. 반대로 PASSWORD_CHANGED는 거래 금액이 없어도 독립적으로 발생하는 행동입니다. 두 입력을 하나의 범용 JSON API로 합치지 않은 이유입니다.^[1]

호출 권한과 입력 검증은 서로 다른 검사

거래 접수: SERVICE / TRANSACTION_INGESTOR / transaction:intake
행동 수집: SERVICE / BEHAVIOR_INGESTOR / behavior-event:intake
거래 조회: USER / transaction:read

수집 API는 승인된 Mock 금융·인증 시스템이나 수집 어댑터의 호출을 대상으로 합니다. 호출할 권한이 있어도 본문 검증을 통과해야 하며, 필드가 올바르다고 호출 권한이 생기는 것도 아닙니다.^{[1] [9]}

3. 금액·시간·식별자를 명확하게 표현하기

금액은 양의 10진 정수 문자열로 받기

{
  "amount": "1250000",
  "currencyCode": "KRW"
}

금액은 문자열로 받아 허용한 형식을 검사하고 BigDecimal로 변환합니다. JSON 숫자를 어떤 언어와 중간 타입으로 처리하는지에 의존하기보다, API 경계에서 10진 표현을 명시하려는 선택입니다. 문자열이라는 이유만으로 모든 값이 유효해지는 것은 아닙니다.^{[1] [3]}

허용: "1250000"
거절: 1250000       ← 문자열이 아닌 JSON number
거절: "1250000.00"  ← 소수점 표현
거절: "1.25e6"      ← 지수 표현
거절: "-1000", "0" ← 음수 또는 0

거래 Validator는 1부터 999999999999999까지의 값을 허용합니다. DB의 NUMERIC(19,4) 저장 범위에 맞춘 상한이며, 통화는 KRW로 제한합니다. 반올림이나 자동 절삭으로 잘못된 입력을 교정하지 않습니다.^{[3] [4]}

발생 시각과 저장 시각을 분리하기

시각 필드의 의미를 설명하기 위한 예시

{
  "occurredAt": "2026-07-23T01:15:30Z",
  "createdAt": "2026-07-23T01:15:31Z"
}

occurredAt은 업무가 발생한 시각이고, createdAt은 서버에서 저장한 시각입니다. 입력은 UTC ISO-8601의 Z 표기로 제한합니다. 같은 순간을 나타내더라도 +09:00 같은 offset 표현을 자동 수용하지 않는 것은 이 프로젝트의 입력 계약입니다.^{[1] [3]}

검증 기준: occurredAt ≤ validationClock + 5분
정확히 +5분: 허용
+5분 초과: 거절

검증 시각은 주입한 Clock에서 얻습니다. 시간 경계 테스트가 실제 현재 시각에 흔들리지 않게 기준 시각을 고정할 수 있는 구조입니다. 다만 초과 요청의 HTTP 분류는 거래와 행동 이벤트 코드가 다르므로, 10절에서 따로 짚겠습니다.^[3]

업무 ID와 참조값의 의미 유지하기

transactionId와 eventId는 호출자가 전달하는 UUID v4 업무 식별자입니다. DB 내부 PK를 받지 않으며, 요청 추적용 traceId와도 대체하지 않습니다. 고객·계좌·기기에는 실제 원문 대신 제한된 외부 참조값을 사용합니다.^[1]

참조값은 제공될 때 1~128자이며 빈 값과 앞뒤 공백을 거절합니다. 서버가 임의로 trim()하거나 대소문자를 바꾸지는 않습니다. 반면 검증된 UUID·시각·금액은 Fingerprint를 만들 때 정해진 형태로 직렬화합니다. 잘못된 입력을 교정하는 것과, 유효한 입력을 정규화하는 것은 다른 단계입니다.^{[1] [3]}

4. 거래 생성 요청과 최종 성공 응답

토큰은 설명용 자리표시자이며 실제 자격증명이 아닙니다.

POST /api/v1/transactions
Content-Type: application/json
Authorization: Bearer <TRANSACTION_INGESTOR_TOKEN>
Idempotency-Key: tx-create-demo-001

계약에 맞춘 요청 예시. 실제 고객·계좌 원문은 포함하지 않습니다.

{
  "transactionId": "2f4c0a4e-8a9d-4c2f-9a1b-7d6e5f430001",
  "transactionType": "ACCOUNT_TRANSFER",
  "amount": "1250000",
  "currencyCode": "KRW",
  "occurredAt": "2026-07-23T01:15:30Z",
  "externalCustomerRef": "cust_ref_demo_a7f2",
  "senderAccountRef": "acct_ref_demo_s91c",
  "recipientAccountRef": "acct_ref_demo_r44d",
  "channel": "MOBILE_BANKING",
  "deviceRef": "device_ref_demo_18b3"
}

입력은 위의 10개 업무 필드로 제한했습니다. 클라이언트가 riskLevel, processingStatus, caseId를 보내 결과를 지정하도록 하지 않습니다. 결과는 서버의 분석과 위험 대응 정책이 결정합니다.^{[1] [2]}

계좌이체

ACCOUNT_TRANSFER
수취 계좌 필수
channel = MOBILE_BANKING

오픈뱅킹 이체

OPEN_BANKING_TRANSFER
수취 계좌 필수
channel = OPEN_BANKING

ATM 인출

ATM_WITHDRAWAL
수취 계좌는 null
channel = ATM

대출 실행 Mock

LOAN_DISBURSED
수취 계좌는 null
channel = CORE_BANKING

senderAccountRef는 네 유형에서 모두 기준 계좌를 뜻합니다. 특히 대출 실행 Mock에서는 대출금이 입금되는 대상 계좌를 이 필드로 표현합니다. 일반적인 송금의 발신 계좌라는 의미로만 읽지 않도록 계약에 명시했습니다.^[4]

201 Created가 의미하는 완료 범위

신규 거래의 성공 응답은 단순 INSERT 완료를 뜻하지 않습니다. 분석 결과의 저장·채택, 위험 대응, 필요한 사건 연결과 감사 기록을 확정하고, 성공 응답 Snapshot을 저장한 뒤 반환합니다. RECEIVED나 ANALYZED는 이 응답의 최종 성공 상태가 아닙니다.^{[1] [4]}

HTTP/1.1 201 Created
Content-Type: application/json
X-Trace-Id: trace_blog_tx_0001

LOW로 분석·최종화된 경우의 응답 구조 예시입니다. 실제 실행 로그나 특정 입력의 고정된 분석 결과를 뜻하지 않습니다.

{
  "transactionId": "2f4c0a4e-8a9d-4c2f-9a1b-7d6e5f430001",
  "processingStatus": "APPROVED",
  "riskLevel": "LOW",
  "riskResponseOutcome": "APPROVED",
  "adoptedDetectionResultId": "7f4c0a4e-8a9d-4c2f-9a1b-7d6e5f430101",
  "caseId": null,
  "createdAt": "2026-07-23T01:15:31Z",
  "traceId": "trace_blog_tx_0001"
}

LOW·MEDIUM은 caseId: null을 명시하고, HIGH·CRITICAL은 사건 ID를 포함합니다. 상세 상태 조합은 #3의 계약을 따릅니다. 이 글에서는 결과를 만들어 내는 내부 분석 알고리즘보다, 클라이언트가 받는 응답의 의미에 집중합니다.

⚙️ 5. JSON 파싱·필드 검증·교차 필드 검증 나누기

필수 필드에는 @NotNull을 사용하지만, 그것만으로 전체 계약을 표현하지는 않았습니다. DTO는 요청의 모양을 드러내고, 역직렬화기는 허용한 JSON 구조를 검사하며, 전용 Validator는 형식과 업무 조합을 판단하도록 나누었습니다.^{[2] [3]}

저장소 TransactionCreateRequest 발췌. package와 import는 생략했습니다.

@JsonDeserialize(using = TransactionCreateRequestDeserializer.class)
public record TransactionCreateRequest(
        @NotNull String transactionId,
        @NotNull String transactionType,
        @NotNull String amount,
        @NotNull String currencyCode,
        @NotNull String occurredAt,
        @NotNull String externalCustomerRef,
        @NotNull String senderAccountRef,
        String recipientAccountRef,
        @NotNull String channel,
        String deviceRef
) {
}

허용하지 않은 JSON을 자동으로 흡수하지 않기

역직렬화기는 최상위 객체, 허용 필드 목록, 중복 키 여부와 각 값의 JSON 토큰을 확인합니다. 문자열·null 이외의 숫자·boolean·배열·객체를 문자열 필드에 자동 변환해 넣지 않습니다. null을 읽을 수 있다는 사실은 필수 필드의 null을 허용한다는 뜻이 아니며, 필수 검사는 다음 단계에서 수행합니다.^[2]

거절해야 할 입력 조각: 같은 키를 두 번 보내 앞선 값을 덮어쓰게 하지 않습니다.

{
  "amount": "1250000",
  "amount": "1"
}

이 정책은 잘못된 필드명이나 예상하지 않은 데이터를 빨리 발견하는 데 유리하지만, 클라이언트가 새 필드를 먼저 보내는 변경에는 엄격합니다. 따라서 필드 확장은 서버·클라이언트 계약을 함께 검토해야 합니다. 엄격한 검증이 호환성 검토를 대신하는 것은 아닙니다.

각 필드가 유효해도 조합은 잘못될 수 있다

교차 필드 검증을 설명하기 위한 요청 일부

{
  "transactionType": "ATM_WITHDRAWAL",
  "recipientAccountRef": "acct_ref_demo_recipient",
  "channel": "MOBILE_BANKING"
}

여기서 거래 유형과 채널은 각각 정의된 Enum에 속할 수 있습니다. 하지만 ATM 인출에 이체 채널과 수취 계좌를 함께 지정한 조합은 허용하지 않습니다. 이런 검사는 공통 필드 형식 검사와 구분한 도메인 검증에서 수행합니다.^{[1] [3]}

TransactionCreateRequest
→ 엄격한 JSON 해석
→ @NotNull 및 UUID·금액·시간·참조 형식 검사
→ 거래 유형별 수취 계좌·채널 조합 검사
→ ValidatedTransactionCommand
→ 멱등 처리와 업무 실행

검증을 통과한 값은 ValidatedTransactionCommand로 전달합니다. 문자열 상태의 외부 입력과 파싱된 업무 입력을 구분해, 후속 처리에서 같은 형식 해석을 반복하지 않도록 구성했습니다.^[3]

6. 행동 이벤트 API와 조건부 필드

POST /api/v1/behavior-events
Content-Type: application/json
Authorization: Bearer <BEHAVIOR_INGESTOR_TOKEN>

신규 수취인 등록 행동을 수집하는 요청 예시

{
  "eventId": "e54cbf7e-d857-4ca0-bff3-8d4321b7722a",
  "eventType": "BENEFICIARY_REGISTERED",
  "occurredAt": "2026-07-29T04:10:00Z",
  "externalCustomerRef": "cust_ref_demo_a7f2",
  "accountRef": "acct_ref_demo_s91c",
  "deviceRef": "device_ref_demo_18b3",
  "transactionId": null,
  "beneficiaryRef": "acct_ref_demo_r82a"
}

행동 이벤트 요청은 위 8개 필드만 받습니다. accountRef는 수취인을 등록한 고객 측 기준 계좌이고, beneficiaryRef는 새로 등록된 수취인입니다. 둘을 하나의 계좌 필드로 합치면 Rule이 비교할 대상의 의미가 달라집니다.^{[1] [5]}

LOGIN
LOGIN_FAILED
DEVICE_REGISTERED
PASSWORD_CHANGED
OTP_REISSUED
BENEFICIARY_REGISTERED
TRANSFER_LIMIT_CHANGED
TRANSFER_REQUESTED
ATM_WITHDRAWAL_REQUESTED

모든 이벤트에는 eventId, eventType, occurredAt, externalCustomerRef가 필요합니다. 나머지 필드는 이벤트 유형에 따라 필수·선택·금지로 나뉩니다.^{[1] [5]}

기기 식별이 필요한 행동

LOGIN과 DEVICE_REGISTERED에는 deviceRef가 필요합니다. 계좌와 거래 연결은 선택 사항입니다.

계좌 문맥이 필요한 행동

BENEFICIARY_REGISTERED는 accountRef와 beneficiaryRef가 모두 필요합니다. TRANSFER_LIMIT_CHANGED에는 accountRef가 필요합니다.

거래 연결이 필요한 행동

TRANSFER_REQUESTED와 ATM_WITHDRAWAL_REQUESTED에는 accountRef와 transactionId가 모두 필요합니다.

추가 필드가 선택인 행동

LOGIN_FAILED, PASSWORD_CHANGED, OTP_REISSUED의 계좌·기기·거래 참조는 선택입니다. 제공한 값에는 형식과 연결 검증이 적용됩니다.

beneficiaryRef는 BENEFICIARY_REGISTERED에서만 허용합니다. 다른 이벤트에서 보내면 무시하지 않고 거절합니다. 또한 자유 형식 eventDetails, observedSignals, 위험 점수 같은 필드를 받지 않아 수집 데이터와 서버 판단의 책임을 섞지 않았습니다.^{[1] [5]}

수집 응답은 필요한 정보만 반환하기

최초 저장 시 201 Created로 반환하는 응답 구조 예시

{
  "eventId": "e54cbf7e-d857-4ca0-bff3-8d4321b7722a",
  "eventType": "BENEFICIARY_REGISTERED",
  "transactionId": null,
  "occurredAt": "2026-07-29T04:10:00Z",
  "createdAt": "2026-07-29T04:10:01Z",
  "traceId": "trace_blog_event_0001"
}

응답은 이벤트 ID·유형·선택적 거래 ID·발생 시각·저장 시각·현재 Trace의 6개 필드입니다. 내부 PK와 Fingerprint, 고객·계좌·기기 참조값을 그대로 되돌려 주지 않습니다. 거래가 없는 경우에도 transactionId: null을 명시합니다.^{[1] [5]}

행동 이벤트에 transactionId가 있으면 거래 존재 여부뿐 아니라 업무상 연결 가능성도 검증합니다. FK가 보조하는 참조 무결성과, 어떤 고객·계좌의 어떤 거래에 연결할 수 있는지는 구분해야 합니다.^{[3] [5]}

참조 거래가 없음
→ 404 RESOURCE_NOT_FOUND

거래는 있지만 고객·계좌·거래 유형이 맞지 않음
→ 422 VALIDATION_ERROR

우선 externalCustomerRef는 거래의 고객 참조와 정확히 같아야 합니다. 일반 이벤트에서 accountRef를 제공했다면 거래의 기준 계좌 또는 수취 계좌에 해당하는지 확인합니다.

거래 요청 행동에는 더 좁은 조건을 적용합니다. TRANSFER_REQUESTED는 계좌이체 또는 오픈뱅킹 이체를 참조하고, accountRef가 반드시 senderAccountRef와 같아야 합니다. ATM_WITHDRAWAL_REQUESTED는 ATM 인출 거래와 출금 기준 계좌를 요구합니다.^{[3] [5]}

“존재하는 거래인가?”와 “이 이벤트가 그 거래에 속할 수 있는가?”는 서로 다른 질문입니다.

거래 연결이 선택적인 이벤트까지 모두 거래를 요구하지는 않습니다. 비밀번호 변경이나 신규 기기 등록처럼 거래 이전에 발생하는 행동을 독립적으로 수집할 수 있어야 하기 때문입니다. 단, 거래 연결을 명시한 신규 이벤트에는 위 검증을 적용합니다.

8. 같은 중복 방지에 서로 다른 전략을 적용한 이유

두 API 모두 업무 ID가 있지만 처리의 수명과 반환할 결과가 다릅니다. 거래는 여러 단계를 거치는 명령의 진행 상태와 최초 응답을 보존해야 합니다. 반면 행동 이벤트 접수는 저장한 불변 이벤트에서 반환할 결과를 다시 구성할 수 있습니다. 그래서 거래에는 별도 멱등 레코드를, 행동 이벤트에는 eventId와 Fingerprint 기반 자연 멱등성을 사용합니다.^{[1] [4] [5]}

거래 생성 명령과 불변 행동 이벤트에 서로 다른 중복 처리 전략을 적용한 구조

왼쪽의 ‘같은 Key + 같은 Fingerprint → 기존 결과 재생’은 완료된 요청을 기준으로 단순화한 표현입니다. 처리 중이면 409로 구분하며, 확정 실패는 저장된 실패를 반환합니다. 반면 오른쪽 행동 이벤트는 같은 eventId와 같은 정규화 요청이면 기존 불변 행을 바탕으로 200 OK를 반환합니다.^{[1] [4] [5]}

거래: 자원 ID와 명령 ID를 구분하기

Idempotency-Key는 거래 생성 명령과 재시도를 식별하고, transactionId는 거래 자원을 식별합니다. 키는 8~128자의 영문·숫자·._:- 조합이며, 작업 범위 POST:/api/v1/transactions와 함께 Unique로 관리합니다.^{[1] [4]}

동일 키라고 모두 재생하지는 않습니다. 입력 Fingerprint를 먼저 비교하고, 같을 때도 IN_PROGRESS라면 다시 실행하지 않고 409를 반환합니다. COMPLETED일 때 저장된 결과를 재생하며, 확정된 FAILED도 자동 재실행 대신 저장한 실패 분류 또는 실패 Snapshot을 사용합니다.^{[1] [4]}

재생 응답이 항상 200인 것은 아니다

최종 성공 Snapshot의 완료 재요청은 저장된 201 Created를 재생합니다. 과거 무버전 legacy Snapshot은 200을 사용하는 별도 호환 규칙이 있습니다. 응답의 업무 값은 저장 결과를 유지하고 traceId만 이번 요청 값으로 결합합니다. 재생은 최신 거래 조회나 새 분석이 아닙니다.^{[1] [4]}

이 분기는 인증·인가와 입력 검증, 필수 Provider 가용성 점검을 통과해 멱등 판별에 도달한 요청을 기준으로 합니다. 접수 Service는 Provider 구성이 사용 불가하면 멱등 재생보다 먼저 가용성 오류를 반환하는 경계를 갖습니다. 원격 조회를 재실행한다는 의미와는 구분해야 합니다.^{[4] [8]}

행동 이벤트: 같은 사실의 재수신을 식별하기

같은 eventId와 같은 Fingerprint면 기존 이벤트를 반환하고, 같은 ID에 다른 내용이 오면 기존 행을 수정하지 않고 409로 거절합니다. 비슷한 시각의 같은 행동이어도 eventId가 다르면 별도 사실로 저장합니다. 패턴이 유사한지 분석하는 일과 수신 중복을 판정하는 일은 다른 책임입니다.^{[1] [5]}

행동 이벤트는 별도 멱등 응답 JSON을 영속화하지 않고 기존 행에서 응답을 구성합니다. 코드에 등장하는 BehaviorEventIntakeSnapshot은 응답 구성에 사용하는 값 객체이며, 거래의 영속 Response Snapshot과 같은 저장 전략이라는 뜻은 아닙니다.^{[5] [6]}

Fingerprint는 해석이 끝난 업무 입력으로 계산하기

거래는 10개, 행동 이벤트는 8개의 지정 필드를 고정 순서 JSON으로 직렬화해 SHA-256을 계산합니다. 원문 JSON의 공백이나 키 순서가 아니라 검증·정규화된 업무 내용이 비교 대상입니다. 선택 필드의 누락과 명시적 null은 같은 null로 표현하고, Trace·내부 PK·서버 생성 시각은 제외합니다.^{[1] [4] [5]}

9. 동시 INSERT와 실패 트랜잭션의 재조회 경계

저장 전에 같은 이벤트가 있는지 SELECT하는 것만으로 동시 요청을 막을 수는 없습니다. 두 요청 모두 아직 없는 행을 확인한 뒤 INSERT를 시도할 수 있기 때문입니다. 행동 이벤트 경계에서는 사전 조회와 별개로 DB의 UNIQUE(event_id)가 경쟁 쓰기를 제한합니다.^[5]

요청 A: eventId 조회 → 없음 → INSERT 성공
요청 B: eventId 조회 → 없음 → 같은 eventId INSERT 충돌

B의 저장 트랜잭션 종료·rollback
→ 별도 읽기 트랜잭션에서 기존 행 조회
→ Fingerprint 같음: 기존 결과 반환
→ Fingerprint 다름: 충돌 응답

구현은 저장 역할의 BehaviorEventIntakeWriter와 재조회 역할의 BehaviorEventReplayReader를 별도 Bean으로 나누고, 두 메서드에 독립 트랜잭션 경계를 둡니다. 충돌은 Writer 밖에서 처리하고, 실패한 저장 트랜잭션 안에서 다시 조회하는 구조를 피했습니다.^{[5] [6]}

두 클래스의 메서드 어노테이션만 발췌한 비교입니다. 독립 실행 가능한 클래스 전체는 아닙니다.

// BehaviorEventIntakeWriter.create()
@Transactional(propagation = Propagation.REQUIRES_NEW)

// BehaviorEventReplayReader.findByEventId()
@Transactional(
        readOnly = true,
        propagation = Propagation.REQUIRES_NEW
)

또한 모든 DataIntegrityViolationException을 이벤트 중복으로 해석하지 않습니다. 구현은 SQLSTATE 23505와 uq_behavior_event_event_id 제약 이름을 함께 확인한 경우에만 기존 행 재조회 분기로 들어갑니다. 다른 무결성 오류를 정상적인 중복 재생으로 숨기지 않기 위한 구분입니다.^[5]

이 사례는 실제 장애가 발생했다는 회고가 아니라, 저장 Service와 통합 테스트에 나타나는 경쟁 처리 설계입니다. 동시 요청에서 기대하는 결과는 뒤의 테스트 코드로 확인할 수 있습니다.

10. 오류 응답도 클라이언트와의 계약으로 다루기

오류는 모두 같은 400이나 500으로 합치지 않았습니다. 클라이언트가 입력을 고쳐야 하는지, 기존 요청이 처리 중인지, 의존성을 사용할 수 없는지를 구분하도록 HTTP 상태와 공개 오류 코드를 함께 제공합니다. 아래 분류는 FinGuardOps의 계약이며 모든 API에 강제되는 유일한 분류 방식이라는 뜻은 아닙니다.^{[1] [7]}

400 · 형식 검증 실패

잘못된 JSON, 알 수 없는 필드, 중복 JSON 키, 허용하지 않은 타입, UUID·금액·필수 헤더의 형식 위반을 VALIDATION_ERROR로 반환합니다.

422 · 도메인 검증 실패

거래 유형별 필드 조합, 이벤트 조건부 필드, 연결된 거래의 고객·계좌·유형 불일치 등을 구분합니다.

404 · 참조 거래 없음

행동 이벤트가 지정한 거래가 없으면 RESOURCE_NOT_FOUND를 반환합니다.

409 · 처리 중 또는 충돌

키 충돌, 처리 중인 동일 명령, 거래 ID 중복, 이벤트 ID의 내용 충돌을 각각 공개 오류 코드로 구분합니다.

503과 500을 구분하는 경계

행동 이벤트 저장 경계는 확인된 Query Timeout을 DEPENDENCY_TIMEOUT, 분류된 일시적 저장소 가용성 실패를 DEPENDENCY_UNAVAILABLE로 매핑합니다. 그 밖의 DataAccess 오류나 모순된 내부 데이터까지 모두 503으로 바꾸지는 않습니다. 거래의 External Risk·분석 실패는 해당 단계의 별도 계약을 따릅니다.^{[1] [5] [7]}

형식과 도메인의 경계가 실제 코드에서도 같은지 확인하기

코드를 대조하면서 주의한 부분은 미래 발생 시각의 분류입니다. 두 API 모두 5분 초과 입력을 거절하지만, 거래 Validator는 FORMAT, 행동 이벤트 Validator는 DOMAIN 예외를 만듭니다. 공통 예외 처리기는 이를 각각 400과 422로 변환합니다.^{[3] [7]}

동일한 조건: occurredAt > validationClock + 5분

TransactionRequestValidator
→ FORMAT → 400 VALIDATION_ERROR

BehaviorEventRequestValidator
→ DOMAIN → 422 VALIDATION_ERROR

따라서 “미래 5분 초과는 두 API 모두 422”라고 일반화하지 않았습니다. 허용 범위가 같다는 것과 오류 분류까지 같다는 것은 다릅니다. 이 차이를 유지할지 통일할지는 API 계약과 테스트를 함께 검토할 항목이며, 설명을 위해 구현 결과를 임의로 바꾸지는 않습니다.

필드 오류와 내부 원문을 분리하기

HTTP/1.1 400 Bad Request
Content-Type: application/json

amount가 "1.25e6"인 요청에 대한 Validator·예외 매핑 구조 예시. 실제 호출을 캡처한 로그는 아닙니다.

{
  "code": "VALIDATION_ERROR",
  "message": "요청 필드를 확인해 주세요.",
  "traceId": "trace_blog_amount_0001",
  "fieldErrors": [
    {
      "field": "amount",
      "code": "INVALID_AMOUNT_FORMAT",
      "reason": "amount must be an unsigned decimal integer string"
    }
  ]
}

필드 오류는 field, code, reason으로 구성됩니다. 화면은 필드에 오류를 연결할 수 있고, 공개 오류 코드는 입력 원문을 응답에 복사하지 않고도 원인을 분류하는 데 사용할 수 있습니다.^[7]

응답에 SQL, DB 제약 이름, 스택 트레이스, 원본 토큰, Fingerprint나 실제 계좌 원문을 넣지 않습니다. 내부 진단에 사용하는 상세와 외부에 제공할 안전한 설명을 분리합니다. 인증 실패와 권한 부족 역시 Validation과 혼합하지 않고 401·403 경계에서 처리합니다.^{[1] [7] [9]}

11. 성공 응답뿐 아니라 거절·중복·무저장을 확인하는 테스트

입력 검증 테스트는 “예외가 발생한다”는 사실만 확인해서는 부족하다고 보았습니다. 어느 필드가 어떤 분류로 거절되는지, 오류 응답 이후 신규 업무 행이 남지 않는지, 중복 요청에 새 결과가 생기지 않는지까지 검증 조건으로 두었습니다.

테스트 코드와 실행 결과의 구분

아래는 저장소에 정의된 테스트와 assertion을 설명한 것입니다. 새로 실행해 얻은 성공 건수·실패 로그·성능 측정값은 제시하지 않습니다. 특히 여러 스레드의 DB 경쟁 테스트를 실제 Kubernetes 다중 Pod 부하 실험과 동일하게 표현하지 않습니다.

① JSON 경계: 중복 키가 값을 덮어쓰기 전에 거절되는가

TransactionCreateRequestJsonTest의 테스트 메서드 발췌. fixture·assertion helper는 원본 파일에 있습니다.

@Test
void rejectsDuplicateJsonKeyBeforeAnyValueCanBeOverwritten() {
    String json = completeJson().replace(
            "\"amount\": \"0001\"",
            "\"amount\": \"0001\",\n  \"amount\": \"2\""
    );

    assertFormatFailure(json, "amount", DUPLICATE_JSON_FIELD);
}

같은 테스트 클래스는 객체가 아닌 JSON root, 알 수 없는 필드, 숫자·boolean·배열·객체 토큰도 검사합니다. 선택 필드의 누락과 명시적 null은 같은 null로 다루되, 숫자 토큰을 문자열로 바꾸는 입력 교정은 허용하지 않습니다.^[8]

② HTTP와 DB 경계: 거절 뒤에 업무 행이 남지 않는가

TransactionIntakeControllerIntegrationTest에는 짧은 멱등성 키를 보낸 요청이 400으로 거절되고, 거래와 멱등 레코드의 개수가 모두 0인지 확인하는 테스트가 있습니다. Provider가 없는 환경에서도 요청 Validation이 먼저 적용되는지 함께 확인합니다.^[8]

requestValidationStillReturns400BeforeAvailability()의 assertion 부분 발췌

.andExpect(status().isBadRequest())
.andExpect(jsonPath("$.code").value("VALIDATION_ERROR"));

assertThat(transactionRepository.count()).isZero();
assertThat(idempotencyRepository.count()).isZero();

③ 동시성: 여러 요청에서 최초 생성과 재생이 구분되는가

BehaviorEventIntakeIntegrationTest는 8개의 작업을 latch로 대기시킨 후 같은 요청을 동시에 전달하도록 작성되어 있습니다. 검증 조건은 Created 하나, 나머지 Replay, 그리고 DB 행 하나입니다.^[8]

동시 요청 통합 테스트의 assertion 발췌. taskCount는 8입니다.

assertThat(results.stream().filter(
        BehaviorEventIntakeResult.Created.class::isInstance
)).hasSize(1);
assertThat(results.stream().filter(
        BehaviorEventIntakeResult.Replay.class::isInstance
)).hasSize(taskCount - 1);
assertThat(rowCount()).isEqualTo(1);

이 테스트는 중복 방지를 메모리 플래그에만 의존하지 않고 PostgreSQL 저장 경쟁과 결과 재생으로 검증한다는 점에서 의미가 있습니다. 배포 환경에서의 네트워크 단절·프로세스 종료·여러 Pod 경쟁은 별도의 조건으로 추가 검증해야 합니다.

동일 검증을 다시 실행할 수 있는 명령

Windows PowerShell에서 저장소 루트 기준으로 아래 명령을 사용할 수 있습니다. Java 17을 사용할 수 있어야 하며, PostgreSQL Testcontainers 통합 테스트에는 Docker 실행 환경이 필요합니다. 단위·웹 테스트와 PostgreSQL 통합 테스트는 Gradle 작업을 분리했습니다.^[9]

cd backend

# JSON 파싱·형식 검증
.\gradlew.bat test --tests "com.aifds.backend.transaction.dto.TransactionCreateRequestJsonTest" --rerun-tasks

# 거래 / 행동 이벤트 Validator
.\gradlew.bat test --tests "com.aifds.backend.transaction.validation.TransactionRequestValidatorTest" --tests "com.aifds.backend.behavior.validation.BehaviorEventRequestValidatorTest" --rerun-tasks

# PostgreSQL 저장·중복·동시 요청
.\gradlew.bat integrationTest --tests "com.aifds.backend.persistence.BehaviorEventIntakeIntegrationTest" --tests "com.aifds.backend.persistence.TransactionIntakeControllerIntegrationTest" --rerun-tasks

# 전체 회귀 검증
.\gradlew.bat test integrationTest

실행 뒤에는 backend/build/reports/tests/test/index.html과 backend/build/reports/tests/integrationTest/index.html에서 결과를 확인합니다. 개별 수정의 통과 여부뿐 아니라 전체 회귀 테스트와 해당 테스트가 실제로 실행되었는지도 함께 확인하는 기준으로 삼습니다.

실제 실패 로그와 수정 전후 기록이 있는 문제는 별도 Troubleshooting 글에서 다룹니다. 이 글의 경쟁 요청 예시나 경계값 테스트를 과거 운영 장애가 발생했던 것처럼 바꾸어 설명하지는 않습니다.

☁️ 12. 운영 관점의 의미와 남겨 둔 경계

재전송을 정상적인 입력 조건으로 보기

응답을 받지 못한 호출자는 같은 요청을 다시 보낼 수 있습니다. 이때 키를 새로 만드는 것과 기존 키로 재전송하는 것은 다른 의미입니다. 거래는 동일 명령의 키와 내용을 유지해야 저장된 결과를 재현할 수 있으며, 입력 내용이 바뀌면 같은 명령으로 취급하지 않습니다.^{[1] [4]}

행동 이벤트 역시 재전송 시 같은 사실의 eventId를 유지해야 합니다. 유사한 이벤트에 매번 새 ID를 부여한 뒤 서버가 알아서 중복으로 묶어 주기를 기대하지 않습니다. 호출자와 서버가 동일성 기준을 함께 지켜야 합니다.^{[1] [5]}

공유 DB 설계와 다중 인스턴스 실험을 구분하기

공유 PostgreSQL의 Unique와 영속 레코드를 사용하는 구조는 JVM 하나의 메모리만을 기준으로 중복을 판단하지 않습니다. 다만 이것만으로 모든 배포 장애에서 외부 호출까지 전역적으로 정확히 한 번 실행된다고 주장하지 않습니다. 이미 확정한 결과의 재생, 처리 중 요청의 재실행 제한, 불확실한 상태의 복구는 각 계약으로 다뤄야 합니다.^{[4] [5]}

관측 정보에 금융 원문을 실어 보내지 않기

API의 traceId는 오류 응답과 서버 진단을 연결하는 값입니다. 이를 업무 ID나 금융 데이터로 대체하지 않습니다. 멱등 키·Fingerprint·고객·계좌 참조값을 메트릭 label로 무분별하게 넣지 않고, 오류 분류와 처리 결과 중심으로 관측합니다.^[1]

이 글에서 설명한 Trace 필드는 API의 추적 계약입니다. 필드가 있다는 사실만으로 분산 Trace 수집 환경까지 모두 구축되었다는 의미는 아닙니다. 상세 메트릭·로그·트레이싱 연결은 Observability 편에서 다룹니다.

계약을 엄격하게 만들 때의 비용

Z 시각, 정수 문자열 금액, 허용 필드 목록과 고정 채널 조합은 입력을 명확하게 만드는 대신 호출자의 자유도를 제한합니다. 새 통화·채널·필드를 추가하려면 Validator뿐 아니라 Fingerprint, 응답 호환성, DB 제약과 테스트의 영향도 함께 확인해야 합니다. 편리하게 받아 주는 API보다 해석이 달라지지 않는 API를 우선한 선택입니다.^{[1] [4] [5]}

또한 기록된 만료 시각이 있다는 사실과 키 재사용 정책이 실행된다는 사실은 구분합니다. 거래의 expiresAt 값만 보고 “24시간 뒤 같은 키를 다시 사용할 수 있다”고 설명하지 않습니다. 만료 판정과 정리 정책은 저장 필드와 별개의 동작 계약입니다.^{[1] [4]}

13. 마치며: 검증된 데이터를 분석 경계로 넘기기

FinGuardOps에서 거래·행동 이벤트 API를 설계하며 중요하게 본 것은 입력 필드의 개수보다 어떤 요청을 업무로 받아들이고, 어느 지점에서 거절하며, 반복 요청에 무엇을 돌려줄 것인가였습니다.

형식 검증으로 해석을 고정하고, 도메인 검증으로 잘못된 조합을 막으며, 업무의 성격에 맞는 멱등성과 DB 제약으로 중복 실행을 통제합니다.

거래는 멱등성 키와 최초 응답 기록을 중심으로, 행동 이벤트는 불변 이벤트 ID와 저장된 사실을 중심으로 처리합니다. 같은 중복 방지라도 모든 요청에 같은 테이블과 같은 상태 모델이 필요한 것은 아니었습니다.

이 입력 경계 위에서 다음으로 필요한 것은 검증된 거래·행동·RuleVersion을 분석 Snapshot으로 묶고, FastAPI 응답을 다시 검증하는 과정입니다. 다음 글에서는 Spring Boot와 FastAPI 사이의 요청·응답 계약과 분석 결과 채택 경계를 정리하겠습니다.

[LG CNS 6기] 28일차 TIL : React 댓글 부분 리렌더링·Spring Validation·전역 예외 처리

bbbicsan — Fri, 4 Sep 2026 18:05:29 +0900

[LG CNS 6기] 28일차 TIL : React 댓글 부분 리렌더링·Spring Validation·전역 예외 처리

한 줄 요약
React의 댓글 컴포넌트를 List → Item 구조로 분리하고, 댓글 추가·삭제·수정 시 전체 데이터를 다시 조회하지 않고 필요한 부분만 상태 갱신하여 리렌더링했다. Spring Boot에서는 DELETE/PATCH API를 MyBatis와 연결하고, @Valid 기반 DTO 검증과 사용자 정의 예외·@RestControllerAdvice를 이용한 전역 예외 처리까지 구현했다.

오늘 학습한 커리큘럼

Spring MVC 요청/응답 흐름 복습
        ↓
DispatcherServlet
        ↓
Controller Mapping
        ↓
@RequestParam
@PathVariable
@RequestBody
@RequestHeader
        ↓
Service / Repository
        ↓
ResponseEntity
Status + Header + Body
        ↓
React Blog 상세 화면
        ↓
BlogCommentList
        ↓
BlogCommentItem
        ↓
댓글 추가
→ 배열 append
        ↓
댓글 삭제
→ filter()
        ↓
댓글 수정
→ map()
        ↓
필요한 댓글 영역만 부분 리렌더링
        ↓
Spring Boot Comment API
        ↓
DELETE /comments/delete/{id}
PATCH /comments/update/{id}/{comment}
        ↓
CommentController
        ↓
CommentService
        ↓
CommentMapper
        ↓
MyBatis
        ↓
Validation
@Valid
@Email
@NotBlank
@Size
        ↓
Custom Exception
LoginFailException
        ↓
@RestControllerAdvice
        ↓
GlobalExceptionHandler
        ↓
401 Unauthorized
        ↓
React Validation Error UI

오늘의 학습 키워드

React
Spring Boot
Spring MVC
DispatcherServlet
ResponseEntity
@RequestParam
@PathVariable
@RequestBody
@RequestHeader
MyBatis
Partial Rendering
filter()
map()
Spread Operator
Props
useState
useEffect
@DeleteMapping
@PatchMapping
@Valid
Jakarta Validation
@Email
@NotBlank
@Size
Custom Exception
@RestControllerAdvice
@ExceptionHandler
401 Unauthorized
204 No Content
DTO
Builder

1. Spring MVC 전체 요청 흐름 복습

오늘 수업 초반에는 지금까지 학습했던 Spring MVC의 요청 처리 흐름을 다시 한 번 전체 구조로 정리했다.

Browser / React
      ↓ HTTP Request
WAS
Tomcat / WebLogic
      ↓
DispatcherServlet
      ↓
Controller
      ↓
@GetMapping
@PostMapping
@DeleteMapping
@PatchMapping
      ↓
Parameter Binding
      ↓
Service
      ↓
Repository / Mapper
      ↓
Database
      ↓
Controller
      ↓
ResponseEntity
      ↓
HTTP Response
      ↓
Browser / React

Spring MVC에서는 모든 요청이 Controller 메서드로 바로 들어가는 것이 아니라, DispatcherServlet이 Front Controller 역할을 담당한다.

2. Controller Parameter Binding

지금까지 사용했던 주요 요청값 바인딩 방식도 함께 복습했다.

@RequestParam
→ Query String

@PathVariable
→ URL Path 값

@RequestBody
→ JSON Body → DTO

@RequestHeader
→ HTTP Header

예를 들어:

GET /blogs/read/1

에서는:

@PathVariable("id") Integer id

를 사용할 수 있고,

Authorization: Bearer ...

는:

@RequestHeader("Authorization") String at

으로 받을 수 있다.

3. ResponseEntity로 HTTP Response 구성

Controller에서는 ResponseEntity<?>를 통해 HTTP 응답을 직접 구성할 수 있다.

ResponseEntity
├─ Status
├─ Header
└─ Body

Status Code는 크게:

2xx
→ 성공

3xx
→ Redirect

4xx
→ Client Error

5xx
→ Server Error

로 나눌 수 있다.

오늘 댓글 수정·삭제와 로그인 실패 처리에서도 이 상태코드를 직접 활용했다.

4. React 댓글 컴포넌트 분리

Blog 상세 페이지에서 댓글 렌더링 책임을 별도의 컴포넌트로 분리했다.

구조:

BlogReadPage
      ↓
BlogCommentList
      ↓
BlogCommentItem

BlogReadPage에서는 댓글 데이터와 이벤트 핸들러를 전달한다.

<BlogCommentList
    comments={comments || []}
    handler={commentDeleteHandler}
    updateHandler={commentUpdateHandler}
/>

5. BlogCommentList

BlogCommentList에서는 댓글 배열을 순회한다.

comments.map((comment, idx) => {
    return (
        <BlogCommentItem
            key={idx}
            comment={comment}
            handler={handler}
            updateHandler={updateHandler}
        />
    );
});

즉 부모 컴포넌트로부터 전달받은 데이터와 함수가:

BlogReadPage
      ↓ props
BlogCommentList
      ↓ props
BlogCommentItem

형태로 내려간다.

6. BlogCommentItem의 수정 상태 관리

각 댓글 Item은 자신의 수정 상태를 관리한다.

const [isEdit, setIsEdit] =
    useState(false);

const [mention, setMention] =
    useState('');

역할:

isEdit
→ 현재 댓글이 수정 모드인지 여부

mention
→ 수정 중인 댓글 내용

7. 기존 댓글을 수정 입력값으로 설정

useEffect(() => {
    setMention(comment.comment);
}, []);

최초 렌더링 시 기존 댓글 내용을 mention 상태에 복사한다.

comment.comment
      ↓
setMention()
      ↓
수정 Input 초기값

8. 작성자만 수정/삭제 버튼 표시

로그인 사용자 Email을 가져온다.

const user =
    localStorage.getItem('user');

그리고 댓글 작성자와 비교한다.

user === comment.email

조건이 true일 때만 수정/삭제 UI를 보여준다.

로그인 사용자
      ↓
localStorage user

댓글 작성자
      ↓
comment.email

같음
→ 수정 / 삭제 버튼 표시

다름
→ 버튼 숨김

9. 수정모드 전환

수정 버튼은 isEdit 상태에 따라 동작이 달라진다.

<Button
    title={
        isEdit
            ? '수정완료'
            : '수정'
    }
/>

즉:

isEdit = false
→ "수정"

클릭
→ 수정모드 ON

isEdit = true
→ "수정완료"

로 UI가 변한다.

10. 댓글 추가 후 부분 리렌더링

이전 수업에서 구현했던 댓글 추가 로직도 오늘의 부분 리렌더링 개념과 연결된다.

댓글 등록 성공 시:

setComments(ary => {
    return [
        ...ary,
        response.data
    ];
});

setComment('');

기존 댓글을 다시 조회하지 않고 새 댓글만 추가한다.

기존 comments[]
      +
새 Comment
      ↓
새 comments[]
      ↓
setComments()
      ↓
댓글 영역만 리렌더링

11. 댓글 추가에서는 Spread Operator

댓글 추가의 핵심은:

[...ary, response.data]

이다.

...ary
→ 기존 댓글 모두 유지

response.data
→ 새로 등록된 댓글 추가

즉 새로운 배열을 만들어 React 상태를 갱신한다.

12. 댓글 삭제 Handler

삭제에서는:

const commentDeleteHandler =
    async (e, id) => {

    console.log(
        `debug >>>> comment id ${id}`
    );

};

처럼 삭제 대상의 댓글 ID를 전달받는다.

13. 기존 json-server 댓글 삭제

기존 json-server에서는:

await api.delete(
    `/comments/${id}`
);

형태였다.

14. Spring Boot 댓글 삭제

Spring Boot 연동 후에는 endpoint를 변경했다.

await api.delete(
    `/comments/delete/${id}`,
    {
        headers: {
            Authorization:
                at ? at : ""
        }
    }
);

요청 구조:

DELETE /comments/delete/{id}

Header
Authorization: Access Token

15. CommentController DELETE

백엔드에서는 댓글 ID를 PathVariable로 받는다.

@DeleteMapping("/delete/{id}")
public ResponseEntity<?> delete(
        @PathVariable("id")
        Integer id
) {

    System.out.println(
        "debug >>>> comment controller delete"
    );

    int flag =
        commentService.delete(id);

    ...
}

흐름:

/comments/delete/3
          ↓
@PathVariable
          ↓
id = 3

16. CommentMapper DELETE

Mapper Interface에는:

public int delete(Integer id);

메서드를 추가했다.

MyBatis XML:

<delete id="delete"
        parameterType="java.lang.Integer">

    DELETE FROM
        SPRING_COMMENT_TBL
    WHERE
        ID = #{id}

</delete>

17. 댓글 삭제 전체 Backend 흐름

CommentController
      ↓
CommentService.delete(id)
      ↓
CommentMapper.delete(id)
      ↓
CommentMapper.xml
      ↓
DELETE
FROM SPRING_COMMENT_TBL
WHERE ID = #{id}

18. 삭제 후 React에서 전체 재조회하지 않기

삭제 성공 후:

setComments(
    comments.filter(
        c => c.id !== id
    )
);

를 사용했다.

핵심은 filter()이다.

기존 comments
      ↓
filter()
      ↓
삭제 ID와 다른 댓글만 유지
      ↓
새 comments
      ↓
setComments()

19. 댓글 삭제와 filter()

예를 들어:

comments

[
  id=1,
  id=2,
  id=3
]

에서 id=2를 삭제하면:

comments.filter(
    c => c.id !== 2
)

결과는:

[
  id=1,
  id=3
]

이 된다.

React에서는 새로운 배열로 상태가 변경되기 때문에 화면에서도 해당 댓글이 제거된다.

20. 댓글 삭제 전체 흐름

삭제 버튼 클릭
      ↓
commentDeleteHandler(id)
      ↓
Axios DELETE
      ↓
Spring CommentController
      ↓
CommentService
      ↓
MyBatis DELETE
      ↓
Database
      ↓
HTTP Response
      ↓
React filter()
      ↓
setComments()
      ↓
삭제된 댓글만 UI에서 제거

21. 댓글 수정 Handler

댓글 수정 기능은:

const commentUpdateHandler =
    async (id, mention) => {

    console.log(
        `debug >>>> id ${id},
         mention ${mention}`
    );

};

형태로 수정 대상 ID와 수정 내용을 받는다.

22. 기존 json-server 수정

기존에는:

await api.patch(
    `/comments/${id}`,
    {
        comment: mention
    }
);

방식을 사용했다.

23. Spring Boot 댓글 수정 요청

Spring Boot 버전에서는:

await api.patch(
    `/comments/update/${id}/${encodeURIComponent(mention)}`,
    null,
    {
        headers: {
            Authorization:
                at ? at : ""
        }
    }
);

형태로 변경했다.

24. encodeURIComponent

수정할 댓글 내용은 URL Path에 들어간다.

댓글에는:

공백
한글
특수문자

등이 포함될 수 있기 때문에:

encodeURIComponent(mention)

을 사용했다.

사용자가 입력한 댓글
      ↓
encodeURIComponent()
      ↓
URL-safe 문자열
      ↓
PathVariable

25. CommentController PATCH

@PatchMapping(
    "/update/{id}/{comment}"
)
public ResponseEntity<?> update(

        @PathVariable("id")
        Integer id,

        @PathVariable("comment")
        String comment
) {

    ...
}

URL:

PATCH
/comments/update/3/수정내용

에서 각각:

id
→ 3

comment
→ 수정내용

으로 바인딩한다.

26. Controller에서 Map 생성

두 값을 Service로 전달하기 위해:

Map<String, Object> map =
    new HashMap<>();

map.put("id", id);
map.put("comment", comment);

형태로 Map을 생성했다.

이후:

int flag =
    commentService.update(map);

을 호출한다.

27. MyBatis parameterType = Map

Controller에서 Map을 전달하기 때문에 Mapper XML에서는:

<update id="update"
        parameterType="java.util.Map">

</update>

형태로 정의했다.

XML에서는:

#{id}
#{comment}

가 DTO Property가 아니라 Map Key와 연결된다.

map.put("id", id)
→ #{id}

map.put("comment", comment)
→ #{comment}

28. 댓글 수정 HTTP Status

댓글 수정 결과는:

return flag != 0
    ? ResponseEntity
        .status(
            HttpStatus.NO_CONTENT
        )
        .build()

    : ResponseEntity
        .status(
            HttpStatus.NOT_FOUND
        )
        .build();

로 반환했다.

UPDATE 성공
→ 204 No Content

수정할 댓글 없음
→ 404 Not Found

29. React 댓글 수정에서는 map()

댓글 수정 성공 후에는:

setComments(ary => {

    return ary.map(comment => {

        return comment.id === id
            ? {
                ...comment,
                comment: mention
            }
            : comment;

    });
});

로 상태를 갱신한다.

30. 댓글 수정과 map()

comments[]
      ↓
map()
      ↓
수정 대상 ID인가?
   ├─ YES
   │   → 기존 객체 복사
   │   → comment 값만 변경
   │
   └─ NO
       → 기존 객체 유지

즉 전체 데이터를 다시 받아오지 않고 수정된 객체 하나만 교체한다.

31. 댓글 추가·삭제·수정 비교

오늘 React 부분 리렌더링에서 가장 중요했던 부분이다.

기능	React 처리
댓글 추가	Spread + append
댓글 삭제	`filter()`
댓글 수정	`map()`

흐름으로 보면:

CREATE
→ [...comments, newComment]

DELETE
→ comments.filter(...)

UPDATE
→ comments.map(...)

모두 기존 상세 데이터를 서버에서 다시 조회하지 않고 상태만 변경한다.

32. 부분 리렌더링의 의미

예전 방식이라면 댓글 하나를 변경할 때마다:

댓글 변경
      ↓
Blog 상세 API 다시 요청
      ↓
Blog 다시 조회
      ↓
Comment 다시 조회
      ↓
전체 상태 재설정

해야 할 수도 있다.

오늘 방식은:

댓글 변경 API
      ↓
성공 응답
      ↓
해당 comments State만 변경
      ↓
댓글 UI 리렌더링

으로 처리했다.

불필요한 API 호출과 DB 조회를 줄일 수 있다.

33. Spring Boot Custom Exception

오후에는 Spring의 예외 처리 구조도 학습했다.

로그인 실패를 처리하기 위해 사용자 정의 예외:

LoginFailException

을 만들었다.

기존에는:

.orElseThrow(
    () -> new RuntimeException(
        "로그인 실패"
    )
);

였다.

34. LoginFailException으로 구체화

이제는:

.orElseThrow(
    () -> new LoginFailException(
        "로그인 실패"
    )
);

로 변경했다.

RuntimeException
        ↓
LoginFailException

으로 예외 의미가 명확해졌다.

35. Service에서 업무 예외 발생

UserResponseDTO response =
    userMapper
        .signIn(request)
        .orElseThrow(
            () ->
                new LoginFailException(
                    "로그인 실패"
                )
        );

즉 로그인 사용자를 찾지 못하면 Service가 직접 HTTP 응답을 만드는 것이 아니라 업무 예외를 발생시킨다.

36. GlobalExceptionHandler

공통 예외 Handler를 만들었다.

@RestControllerAdvice
public class GlobalExceptionHandler {

}

@RestControllerAdvice는 여러 REST Controller에서 발생한 예외를 한 곳에서 처리할 수 있도록 한다.

37. @ExceptionHandler

@ExceptionHandler(
    LoginFailException.class
)
public ResponseEntity<?> handleLoginFail(
        LoginFailException e
) {

}

특정 예외가 발생하면 해당 Handler Method가 실행된다.

LoginFailException
      ↓
@ExceptionHandler
      ↓
handleLoginFail()

38. ErrorResponse

예외 메시지를 공통 응답 객체로 생성했다.

ErrorResponse error =
    new ErrorResponse(
        e.getMessage()
    );

최종 응답:

return ResponseEntity
        .status(
            HttpStatus.UNAUTHORIZED
        )
        .body(error);

39. 로그인 실패 응답

Swagger에서 잘못된 로그인 정보를 전송했다.

결과:

401 Unauthorized

Body:

{
  "message": "로그인 실패"
}

이 출력됐다.

40. Global Exception 처리 전체 흐름

GET /users/signIn
      ↓
UserController
      ↓
UserService
      ↓
UserMapper
      ↓
사용자 없음
      ↓
LoginFailException
      ↓
GlobalExceptionHandler
      ↓
@ExceptionHandler
      ↓
ErrorResponse
      ↓
401 Unauthorized

41. 전역 예외 처리의 장점

Controller마다:

try {

} catch (...) {

}

를 반복할 필요가 없다.

Controller
→ 정상 요청 처리에 집중

Service
→ Business Exception 발생

GlobalExceptionHandler
→ HTTP Error Response 담당

로 책임을 분리할 수 있다.

42. 회원가입 DTO Validation

회원가입 요청에는:

@Valid
@RequestBody
UserRequestDTO request

를 적용했다.

JSON Request
      ↓
@RequestBody
      ↓
UserRequestDTO
      ↓
@Valid
      ↓
Validation

43. @Email

@Email(
    message =
        "이메일 형식을 지켜주세요!!"
)
private String email;

올바른 Email 형태인지 검사한다.

44. @NotBlank

@NotBlank(
    message =
        "비밀번호는 필수입력 항목입니다."
)
private String password;

@NotBlank(
    message =
        "이름은 필수입력 항목입니다."
)
private String name;

빈 문자열이나 공백만 입력한 요청을 허용하지 않는다.

45. @Size

Password에는:

@Size(
    min = 4,
    max = 20
)
private String password;

를 적용했다.

즉:

Password 최소 길이
→ 4

Password 최대 길이
→ 20

으로 제한한다.

46. Validation Annotation

수업에서는 대표적으로 다음 Annotation들을 확인했다.

@NotNull

@NotEmpty

@NotBlank

@Pattern

@Email

@Size

각각 데이터 특성에 맞춰 사용할 수 있다.

47. Password @Pattern

비밀번호 정규식을 이용한:

@Pattern(...)

예제도 코드에 주석으로 작성했다.

현재 실습 코드에서는 @NotBlank + @Size가 실제 적용된 상태이고, @Pattern은 추가적인 Password 정책을 적용할 수 있는 예제로 확인했다.

48. role 필드 준비

UserRequestDTO에:

private String role;

필드도 추가됐다.

코드 주석:

optional
(spring security role)

로 표시되어 있었기 때문에 향후 Spring Security에서:

USER
ADMIN
...

과 같은 Role과 연결하기 위한 준비 단계로 볼 수 있다.

현재 수업에서는 아직 실제 인증/인가 로직까지 연결되지는 않았다.

49. DTO와 Lombok

UserRequestDTO에는 다음 Lombok Annotation이 적용됐다.

@Builder
@Getter
@ToString
@NoArgsConstructor
@AllArgsConstructor

오늘 커리큘럼에 있었던:

Builder
NoArgsConstructor
AllArgsConstructor
DTO 직렬화 이슈

와 연결되는 부분이다.

50. DTO 생성과 역직렬화

Spring에서는 JSON 요청을:

JSON
 ↓
@RequestBody
 ↓
DTO

형태로 변환해야 한다.

DTO를 어떻게 구성하느냐는 Spring/Jackson의 객체 생성 및 직렬화·역직렬화 과정과 연결된다.

오늘은:

@Builder
→ 개발자가 DTO를 편리하게 생성

@NoArgsConstructor
→ 기본 생성자

@AllArgsConstructor
→ 전체 필드를 받는 생성자

를 함께 사용하는 구조를 확인했다.

51. React Validation Error UI 준비

프론트에서도 Validation 실패 메시지를 사용자에게 표시하기 위한 컴포넌트를 만들었다.

const ErrorMessage = styled.p`
    color: red;
    font-size: 13px;
    margin: 6px 0 0 2px;
`;

52. Backend Validation → React UI

최종적으로 목표하는 흐름은:

SignUpPage
      ↓
POST /users/signUp
      ↓
Spring @Valid
      ↓
Validation 실패
      ↓
Error Response
      ↓
Axios catch
      ↓
Error State
      ↓
<ErrorMessage>
      ↓
사용자에게 검증 메시지 표시

이다.

오늘 화면에서는 프론트에 ErrorMessage 스타일 컴포넌트를 추가하고 Axios Validation Error가 들어오는 흐름까지 확인했다.

53. Blog 화면 정상 동작 확인

React Blog 화면도 계속 정상 동작했다.

화면에서는:

로그인 사용자 환영 문구
글 작성하기
로그아웃
기상예보
OpenAPI

전체 / 개발 / 생활 / 취미 / 일상

첫번째 글

이 정상적으로 렌더링됐다.

Console에서도 Blog API 요청이 200으로 처리되는 것을 확인했다.

오늘 전체 흐름

오늘 배운 내용을 한 번에 정리하면:

React
│
├─ Comment Create
│   ↓
│   [...comments, newComment]
│
├─ Comment Delete
│   ↓
│   filter()
│
└─ Comment Update
    ↓
    map()
        │
        ↓
Axios
        ↓
Spring Controller
        ↓
Service
        ↓
Mapper
        ↓
MyBatis
        ↓
MariaDB

그리고 요청 검증과 오류 처리는:

React Request
      ↓
Controller
      ↓
@Valid
      ↓
DTO Validation
      ↓
Service
      ↓
Custom Exception
      ↓
@RestControllerAdvice
      ↓
ErrorResponse
      ↓
HTTP Error
      ↓
React Error UI

로 연결된다.

오늘의 문제 해결 과정

1. 댓글 하나를 변경할 때 Blog 전체를 다시 조회해야 할까?

기존 방식에서는 댓글이 변경될 때마다 상세 데이터를 다시 요청할 수도 있다.

댓글 변경
→ GET Blog 상세
→ Blog SELECT
→ Comment SELECT
→ 전체 상태 재설정

하지만 댓글 데이터 하나 때문에 전체를 다시 조회하는 것은 비효율적이다.

해결

React State만 변경했다.

추가
→ Spread

삭제
→ filter()

수정
→ map()

결과

필요한 댓글 영역만 변경되고 React가 다시 렌더링했다.

2. 댓글 삭제 후 화면에서도 바로 제거하기

Backend

DELETE /comments/delete/{id}

Frontend

setComments(
    comments.filter(
        c => c.id !== id
    )
);

DB에서 삭제된 ID를 React State에서도 제거하면서 서버와 화면의 상태를 맞췄다.

3. 댓글 수정 후 전체 데이터를 다시 받아오지 않기

Backend

PATCH /comments/update/{id}/{comment}

Frontend

setComments(ary =>
    ary.map(comment =>
        comment.id === id
            ? {
                ...comment,
                comment: mention
            }
            : comment
    )
);

수정 대상 하나만 새로운 객체로 교체했다.

4. URL에 한글 댓글을 그대로 넣어도 될까?

댓글 수정 내용이 PathVariable에 포함됐다.

/comments/update/{id}/{comment}

한글, 공백, 특수문자 때문에 URL 문제가 생길 수 있다.

해결

encodeURIComponent(mention)

을 사용했다.

5. 로그인 실패 처리 코드가 Service에 섞임

기존에는:

new RuntimeException("로그인 실패")

를 사용했다.

문제

어떤 종류의 RuntimeException인지 의미가 명확하지 않고, HTTP 응답 처리까지 각 Controller에 분산될 수 있다.

해결

LoginFailException
+
GlobalExceptionHandler

를 만들었다.

결과

LoginFailException
→ 401 Unauthorized
→ {"message":"로그인 실패"}

형태로 통일된 API 오류 응답을 만들었다.

6. 회원가입 Request 값이 잘못되었을 때

잘못된 Email이나 빈 Password 등이 그대로 Service까지 들어가면 이후 계층에서 불필요한 처리가 발생한다.

해결

@Valid
@RequestBody
UserRequestDTO request

와 DTO Validation을 적용했다.

@Email
@NotBlank
@Size

를 통해 Controller 진입 시점에 요청 데이터의 유효성을 검사할 수 있게 됐다.

✨ 오늘 배운 점

오늘 가장 중요했던 부분은 React의 상태와 서버의 데이터를 어떻게 일치시키는가였다.

댓글 하나를 추가하거나 삭제할 때마다:

서버 전체 재조회

를 하지 않고:

추가
→ 배열에 추가

삭제
→ 배열에서 제거

수정
→ 배열의 특정 객체 교체

방식으로 React 상태를 변경했다.

이를 통해 React의 선언적 UI와 상태 기반 렌더링이 왜 중요한지 더 명확하게 이해할 수 있었다.

React 부분 리렌더링을 학습하며

오늘 댓글 CRUD를 비교해보니 JavaScript 배열 메서드가 React 상태 관리에서 각각 명확한 역할을 하고 있었다.

Create
→ Spread

Delete
→ filter

Update
→ map

특히 기존 배열을 직접 수정하는 것이 아니라 새로운 배열/객체를 생성해 상태를 변경하는 것이 중요했다.

{
    ...comment,
    comment: mention
}

처럼 Spread Operator를 통해 기존 값을 유지하면서 필요한 필드만 수정하는 방식도 반복해서 사용됐다.

Spring 계층 분리를 학습하며

댓글 삭제 하나만 해도:

React
→ Axios
→ Controller
→ Service
→ Mapper
→ MyBatis
→ DB

라는 계층을 거친다.

처음에는 단순한 기능에 코드가 많아 보였지만, 각 계층을 나눠두니:

Controller
→ HTTP 책임

Service
→ 업무 처리

Mapper
→ DB 접근

React
→ 화면 상태

처럼 책임이 명확했다.

전역 예외 처리

@RestControllerAdvice를 사용하면서 예외 처리도 계층화할 수 있다는 점을 배웠다.

기존에는 Controller마다 실패 응답을 직접 만들었다면:

Service
→ 의미 있는 Exception 발생

GlobalExceptionHandler
→ HTTP Error 변환

구조로 분리할 수 있었다.

특히:

LoginFailException
→ 401 Unauthorized

처럼 도메인/업무 예외와 HTTP 상태를 명시적으로 연결하는 흐름이 인상적이었다.

Validation과 DTO

DTO는 단순한 데이터 저장 객체가 아니라:

Request Data 구조
Validation 정책
JSON 직렬화/역직렬화
계층 사이 데이터 전달

을 담당한다는 점을 다시 확인했다.

@Email
@NotBlank
@Size

같은 Validation을 DTO 가까이에 선언함으로써 API가 어떤 요청 데이터를 허용하는지 코드로 표현할 수 있었다.

다음 학습 방향

오늘 안내에서는 JPA 관계 설정, H2, JUnit까지 예정되어 있었지만 오늘 공유된 실습에서는 React 댓글 부분 리렌더링과 Spring Validation·예외 처리를 중심으로 진행됐다.

다음 수업은 Docker를 사용할 예정이라고 들었기 때문에, 지금까지 만든 구조가 컨테이너 환경에서 어떻게 실행되는지 연결해서 보면 좋을 것 같다.

복습할 내용:

React
→ npm 기반 실행환경

Spring Boot
→ Java / JAR 실행환경

MariaDB
→ DB 실행환경

Docker
→ 각각의 실행환경을 Container로 구성

그리고 이후에는 다음 주제들도 계속 확인해야겠다.

JPA Entity

@OneToMany
@ManyToOne

User - Blog - Comment 관계

H2 In-Memory DB

JUnit

Transaction Rollback

JWT 실제 검증

Spring Security

Global Exception Handling 확장

Validation ErrorResponse 통일

오늘 배운 React/Spring 연동 구조를 Docker와 JPA에서도 그대로 연결해서 보는 것이 다음 학습의 핵심이 될 것 같다.

[LG CNS 6기] 27일차 TIL : React·Spring Boot 연동과 MyBatis 1:N·Transaction·CORS

bbbicsan — Thu, 3 Sep 2026 17:32:51 +0900

[LG CNS 6기] 27일차 TIL : React·Spring Boot 연동과 MyBatis 1:N·Transaction·CORS

한 줄 요약
React의 Blog·Comment 화면을 Spring Boot API와 실제로 연결하고, MyBatis를 이용해 Blog 1 : N Comment 관계를 조회·조립했다. 또한 @Transactional(readOnly = true)로 여러 조회를 하나의 논리적 작업 단위로 묶고, Access Token 전달, CORS, Builder 기반 DTO 조립, 댓글 등록 후 React 상태 갱신까지 연결했다.

오늘 학습한 커리큘럼

Session vs JWT
        ↓
SPA에서 사용자 상태 유지
        ↓
React localStorage
user / AT / RT
        ↓
Blog DB Schema
SPRING_BLOG_TBL
        ↓
User 1 : N Blog
        ↓
Blog DTO / Mapper / Service / Controller
        ↓
React GET /blogs
        ↓
Blog 목록 조회
        ↓
React POST /blogs/insert
        ↓
Blog 등록
        ↓
Blog 상세조회
GET /blogs/read/{id}
        ↓
@PathVariable
@RequestHeader Authorization
        ↓
@Transactional(readOnly = true)
        ↓
Blog 1건 SELECT
+
Comment N건 SELECT
        ↓
BlogResponseDTO + comments[]
        ↓
Builder / toBuilder()
        ↓
React BlogReadPage
        ↓
Comment 등록
POST /comments/insert
        ↓
201 Created
        ↓
React comments 상태만 부분 갱신

오늘의 학습 키워드

React
Spring Boot
Axios
MyBatis
1:N
Blog
Comment
@RestController
@Service
@Mapper
@RequestBody
@PathVariable
@RequestHeader
ResponseEntity
HttpStatus
@Transactional
readOnly
Spring Proxy
CORS
JWT
Session
Access Token
Refresh Token
localStorage
@RequiredArgsConstructor
Builder
toBuilder()
DTO
Sequence
Foreign Key

1. Session과 JWT를 이용한 상태 유지

오늘 수업 초반에는 클라이언트의 이전 상태정보를 유지하는 방법으로 Session과 JWT를 다시 살펴봤다.

Client 상태 유지
      ↓
Session
또는
JWT

Session 방식은 서버가 사용자의 상태를 관리하는 방식이고, JWT는 클라이언트가 발급받은 Token을 이후 요청에 함께 전달하는 방식이다.

Session
→ 서버가 사용자 상태를 보관
→ Session ID를 기준으로 사용자 식별

JWT
→ Client가 Token 보관
→ 이후 요청 Header에 Token 전달

특히 React나 Vue 같은 SPA 환경에서는 로그인 이후 페이지 이동과 API 요청이 계속 이어지기 때문에 Token을 이용한 인증 흐름을 함께 이해할 필요가 있었다.

2. 로그인 후 React에서 상태정보 유지

이전 수업에서 로그인 성공 시 다음 값을 localStorage에 저장했다.

localStorage.setItem(
    'user',
    response.data.email
);

localStorage.setItem(
    'at',
    response.headers.get('Authorization')
);

localStorage.setItem(
    'rt',
    response.headers.get('Refresh-Token')
);

저장되는 값은:

user
→ 로그인 사용자 Email

at
→ Access Token

rt
→ Refresh Token

이다.

오늘 Blog 기능에서는 이 값들이 실제로 사용되기 시작했다.

3. BlogIndexPage에서 로그인 사용자 조회

React Blog 화면에서는 로그인 사용자 정보를 다음처럼 가져왔다.

const user =
    localStorage.getItem('user');

즉 로그인 화면과 Blog 화면 사이의 사용자 상태를 localStorage를 이용해 유지한다.

SignInPage
   ↓
localStorage.setItem('user', email)
   ↓
BlogIndexPage
   ↓
localStorage.getItem('user')

4. Blog 카테고리 정의

Blog 화면에서는 다음 카테고리를 관리했다.

const CATEGORIES = [
    "전체",
    "개발",
    "생활",
    "취미",
    "일상"
];

이 값은 이후 DB의 CATEGORY 제약조건과도 동일하게 맞춰졌다.

React Category
        ↕

Database CHECK Constraint

즉 Front와 DB 양쪽에서 같은 도메인 값을 사용한다.

5. Blog Table 생성

MariaDB에 Blog 테이블을 생성했다.

CREATE SEQUENCE BLOG_SEQ;

CREATE TABLE SPRING_BLOG_TBL (
    ID       INT PRIMARY KEY,
    TITLE    VARCHAR(50) NOT NULL,
    CONTENT  VARCHAR(200) NOT NULL,

    CATEGORY VARCHAR(50)
             DEFAULT '전체'
             CHECK (
                 CATEGORY IN (
                     '전체',
                     '개발',
                     '생활',
                     '취미',
                     '일상'
                 )
             ),

    EMAIL VARCHAR(50)
          REFERENCES SPRING_USER_TBL(EMAIL)
);

6. Blog Table 구조

각 컬럼의 역할은 다음과 같다.

ID
→ Blog 식별자
→ Sequence 사용

TITLE
→ 제목

CONTENT
→ 본문

CATEGORY
→ Blog 분류
→ DEFAULT '전체'
→ CHECK Constraint

EMAIL
→ 작성 사용자
→ SPRING_USER_TBL.EMAIL 참조

7. User 1 : N Blog 관계

SPRING_BLOG_TBL.EMAIL은 회원 테이블의 Email을 참조한다.

SPRING_USER_TBL
EMAIL (PK)
      1
      ↓
      N
SPRING_BLOG_TBL
EMAIL (FK)

즉:

회원 한 명
→ Blog 여러 개 작성 가능

Blog 한 개
→ 한 명의 작성자와 연결

되는 구조다.

8. Spring Boot Blog 기능 Package

Blog 기능도 기능 단위로 계층을 만들었다.

features
└─ blogs
   ├─ ctrl
   │  └─ BlogController
   │
   ├─ domain
   │  └─ dto
   │     ├─ BlogRequestDTO
   │     └─ BlogResponseDTO
   │
   ├─ repository
   │  └─ BlogMapper
   │
   └─ service
      └─ BlogService

그리고 MyBatis XML은:

resources
└─ mappers
   └─ blogMapper.xml

에 위치한다.

9. BlogMapper - 전체 조회

Mapper Interface에는 전체 Blog 조회 메서드를 정의했다.

@Mapper
public interface BlogMapper {

    public List<BlogResponseDTO> findByAll();

}

흐름은:

BlogMapper.findByAll()
        ↓
blogMapper.xml
        ↓
SELECT
        ↓
List<BlogResponseDTO>

이다.

10. BlogService - 목록 조회

Service에서는 Mapper를 생성자 주입받는다.

@Service
@RequiredArgsConstructor
public class BlogService {

    private final BlogMapper blogMapper;

    public List<BlogResponseDTO> list() {

        System.out.println(
            "debug >>>> blog service list"
        );

        return blogMapper.findByAll();
    }
}

여기서 다시:

@RequiredArgsConstructor
+
final BlogMapper

를 이용한 생성자 주입을 사용했다.

11. Blog 목록 전체 요청 흐름

React BlogIndexPage
      ↓
GET /blogs
      ↓
BlogController
      ↓
BlogService.list()
      ↓
BlogMapper.findByAll()
      ↓
blogMapper.xml
      ↓
SPRING_BLOG_TBL
      ↓
List<BlogResponseDTO>
      ↓
JSON
      ↓
React setBlogs()

12. React에서 Blog 목록 요청

React에서는 기존 json-server 코드와 동일하게 /blogs를 호출했다.

await api.get('/blogs')
    .then(response => {

        console.log(
            'debug >>>> axios request success',
            response
        );

        if (response.status === 200) {
            setBlogs(response.data);
        }
    })
    .catch(error => {

        console.log(
            'debug >>>> axios request error',
            error
        );
    });

응답 데이터는 React 상태에 저장한다.

response.data
      ↓
setBlogs()
      ↓
React Rendering

13. Blog 데이터가 없을 때 화면 확인

처음 Blog 테이블에는 데이터가 없었다.

React 화면에서도:

등록된 글이 없습니다!

라는 메시지가 출력됐다.

즉:

GET /blogs
→ 요청 성공

HTTP 200
→ 정상

response.data
→ []

UI
→ 등록된 글이 없습니다!

상태였다.

서버 오류와 빈 데이터는 구분해야 한다는 점을 다시 확인할 수 있었다.

14. Blog 목록 ResponseEntity

Controller에서는 목록을 다음과 같이 반환했다.

return ResponseEntity
        .status(HttpStatus.OK)
        .body(list);

수업 중에는:

데이터 없음
→ 204 NO_CONTENT

데이터 있음
→ 200 OK

로 분기하는 방식도 살펴봤지만, 현재 구현에서는 빈 List라도 200 OK와 함께 반환하는 형태를 사용했다.

15. BlogMapper 등록 기능 추가

Blog 등록 기능도 Mapper에 추가했다.

@Mapper
public interface BlogMapper {

    public List<BlogResponseDTO> findByAll();

    public int save(
        BlogRequestDTO request
    );
}

조회와 등록의 반환형 차이는:

findByAll()
→ SELECT
→ List<BlogResponseDTO>

save()
→ INSERT
→ 영향받은 Row 수
→ int

이다.

16. Blog 등록 React 요청

BlogWritePage에서는 다음 데이터를 Spring Boot에 전송했다.

await api.post('/blogs/insert', {
    title,
    content,
    category,
    email: user
});

요청 JSON은:

{
  "title": "첫번째 글",
  "content": "우와~ 성공히팅!!ㅎㅎ",
  "category": "일상",
  "email": "jslim9413@gmail.com"
}

형태가 된다.

17. Blog 작성자 Email

여기서 email은 직접 입력받지 않고 로그인 사용자를 사용했다.

const user =
    localStorage.getItem('user');

email: user

즉:

로그인
→ user Email localStorage 저장
        ↓
BlogWritePage
        ↓
Blog 작성자 Email로 전달

구조다.

18. BlogRequestDTO 바인딩

실제 Spring Boot 로그에서도 React가 보낸 데이터가 DTO로 들어오는 것을 확인했다.

BlogRequestDTO(
    title=첫번째 글,
    content=우와~ 성공히팅!!ㅎㅎ,
    category=일상,
    email=jslim9413@gmail.com
)

즉:

React JSON
      ↓
@RequestBody
      ↓
BlogRequestDTO

가 정상 동작했다.

19. BlogController 등록 API

@PostMapping("/insert")
public ResponseEntity<?> insert(
        @RequestBody
        BlogRequestDTO request
) {

    System.out.println(
        "debug >>>> blog controller insert"
    );

    System.out.println(
        "debug >>>> blog controller insert params : "
        + request
    );

    int flag =
        blogService.insert(request);

    return flag != 0
        ? ResponseEntity
            .status(HttpStatus.CREATED)
            .build()

        : ResponseEntity
            .status(HttpStatus.BAD_REQUEST)
            .build();
}

20. Blog 등록 Response

INSERT 성공
→ flag != 0
→ 201 CREATED

INSERT 실패
→ flag == 0
→ 400 BAD_REQUEST

REST API의 실행 결과를 HTTP Status로 표현하는 구조를 다시 확인했다.

21. Blog 등록 성공 후 React 이동

React에서는:

if (response.status === 201) {
    moveUrl('/blogs/index');
}

으로 작성 성공 후 목록 화면으로 이동한다.

POST /blogs/insert
      ↓
201 CREATED
      ↓
/blogs/index

22. Sequence 복습

Blog ID를 만들기 위해 Sequence도 다시 복습했다.

CREATE SEQUENCE SEQ_TEST;

다음 값:

SELECT NEXTVAL(SEQ_TEST);

최근 값:

SELECT LASTVAL(SEQ_TEST);

그리고 옵션:

CREATE SEQUENCE SEQ_TEST
START WITH 1000
INCREMENT BY 2
MAXVALUE 1005;

을 다시 확인했다.

23. Blog 상세보기와 1:N 관계

오늘 핵심 주제는 Blog 상세조회였다.

한 개의 Blog에는 여러 Comment가 존재할 수 있다.

Blog
  1
  ↓
  N
Comment

즉 상세 페이지에서는:

Blog 1건
+
Comment N건

을 함께 내려줘야 한다.

24. 기존 json-server의 1:N 처리

json-server에서는:

await api.get(
    `/blogs/${id}?_embed=comments`
);

형태로 _embed=comments를 사용했다.

응답은 개념적으로:

{
  "id": 1,
  "title": "...",
  "comments": [
    {},
    {},
    {}
  ]
}

처럼 Blog 객체 안에 comments 배열이 포함된다.

25. json-server 응답을 React State에 저장

if (response.status === 200) {

    setBlog(response.data);

    setComments(
        response.data.comments
    );
}

즉:

response.data
→ Blog State

response.data.comments
→ Comments State

로 나눈다.

26. Spring Boot 상세조회 API로 변경

기존 json-server 요청을 Spring Boot endpoint로 변경했다.

await api.get(
    `/blogs/read/${id}`,
    {
        headers: {
            Authorization:
                at ? at : ""
        }
    }
);

27. Access Token을 후속 요청에 사용

로그인할 때 저장했던 Access Token:

localStorage.setItem(
    'at',
    response.headers.get('Authorization')
);

을 Blog 상세조회 요청에 넣는다.

Login
   ↓
AT 발급
   ↓
localStorage
   ↓
BlogReadPage
   ↓
Authorization Header
   ↓
Spring Boot

JWT가 저장용 데이터가 아니라 이후 인증 요청에 사용되는 값이라는 점을 확인했다.

28. BlogController 상세조회 Endpoint

@GetMapping("/read/{id}")
public ResponseEntity<?> read(

        @PathVariable("id")
        Integer id,

        @RequestHeader("Authorization")
        String at
) {

    ...
}

두 가지 파라미터 바인딩이 동시에 사용됐다.

/blogs/read/1
       ↓
@PathVariable
       ↓
id = 1

Authorization: Bearer ...
       ↓
@RequestHeader
       ↓
at

29. Blog 단건 MyBatis 조회

blogMapper.xml에는 다음 쿼리가 추가됐다.

<select id="findById"
        parameterType="java.lang.Integer"
        resultType="com.example.inspire_mybatis.features.blogs.domain.dto.BlogResponseDTO">

    SELECT
        ID,
        TITLE,
        CONTENT,
        CATEGORY,
        EMAIL
    FROM
        SPRING_BLOG_TBL
    WHERE
        ID = #{id}

</select>

30. CommentMapper - Blog별 댓글 조회

댓글 Mapper에서는 Blog ID를 기준으로 댓글 목록을 조회한다.

<select id="findByBlogId"
        parameterType="java.lang.Integer"
        resultType="com.example.inspire_mybatis.features.comments.domain.dto.CommentResponseDTO">

    SELECT
        ID,
        COMMENT,
        EMAIL,
        BLOGID
    FROM
        SPRING_COMMENT_TBL
    WHERE
        BLOGID = #{blogId}
    ORDER BY
        ID DESC

</select>

즉:

Blog ID = 1
       ↓
SPRING_COMMENT_TBL
       ↓
BLOGID = 1
       ↓
Comment 여러 건

을 가져온다.

31. MyBatis 1:N 관계 조립

이번 실습에서는 하나의 JOIN 결과를 자동 관계 매핑하는 방식이 아니라:

SELECT Blog 1건
+
SELECT Comments N건

을 각각 실행한 뒤 Service에서 하나의 DTO로 조립했다.

BlogMapper.findById()
      ↓
BlogResponseDTO
      ↓

CommentMapper.findByBlogId()
      ↓
List<CommentResponseDTO>
      ↓

BlogResponseDTO.comments에 조립

32. @Transactional - 논리적인 작업의 단위

상세조회 Service에는:

@Transactional(readOnly = true)

를 적용했다.

@Transactional(readOnly = true)
public BlogResponseDTO read(
        Integer id
) {

}

이번 상세조회 내부에서는:

Blog SELECT
+
Comment SELECT

두 번의 DB 작업이 이루어진다.

하지만 사용자의 관점에서는:

"게시글 상세보기"

라는 하나의 업무다.

따라서 이 전체를 하나의 논리적인 작업 단위(Transaction) 로 묶는다.

33. Transaction을 논리적 업무로 이해하기

게시글 상세조회 시작
        ↓
Blog SELECT
        ↓
Comment SELECT
        ↓
DTO 조립
        ↓
상세조회 완료

여러 SQL이 존재해도 하나의 Service 업무라면 하나의 Transaction으로 관리할 수 있다.

이전 SQL 수업에서 배운 단순한 COMMIT / ROLLBACK 개념이 Spring의 Service 계층으로 연결되기 시작했다.

34. readOnly = true

@Transactional(readOnly = true)

는 현재 메서드가 조회 중심 Transaction이라는 것을 명시한다.

readOnly = true
→ 조회 작업

INSERT
UPDATE
DELETE
→ 이 Transaction의 목적과 맞지 않음

수업에서도 이 영역에서 Update 같은 쓰기 작업을 수행하는 상황과 구분해서 설명했다.

35. Spring Transaction과 Proxy

오늘 커리큘럼에서 Transaction은 Proxy Transactional이라는 관점으로도 다뤘다.

Spring에서는 @Transactional이 붙은 메서드를 기준으로 트랜잭션 경계를 적용한다.

개념적으로는:

Client / Controller
       ↓
Spring Proxy
       ↓
Transaction Start
       ↓
Service Method
       ↓
DB 작업
       ↓
Transaction 종료

형태로 이해할 수 있다.

오늘 실습에서는 BlogService.read()라는 Service의 논리적 작업 단위를 Transaction 범위로 잡았다.

36. Blog 상세조회 구현

Service에서는 먼저 Blog를 찾는다.

BlogResponseDTO blog =
    blogMapper
        .findById(id)
        .orElseThrow(
            () -> new RuntimeException(
                id + " BLOG NOT FOUND"
            )
        );

즉 Blog가 존재하지 않으면 예외를 발생시킨다.

37. 댓글 목록 조립 - 첫 번째 방식

처음에는:

blog.setComments(
    commentMapper.findByBlogId(
        blog.getId()
    )
);

형태로 기존 DTO의 상태를 직접 변경했다.

BlogResponseDTO
       ↓
setComments()
       ↓
기존 객체 변경

38. Builder를 이용한 조립 방식

이후 다음 방식으로 변경했다.

return blog.toBuilder()
        .comments(
            commentMapper.findByBlogId(
                blog.getId()
            )
        )
        .build();

흐름:

기존 BlogResponseDTO
        ↓
toBuilder()
        ↓
comments 추가
        ↓
build()
        ↓
새 BlogResponseDTO

기존 객체를 직접 수정하지 않고 새로운 응답 DTO를 조립하는 방식으로 바뀌었다.

39. Builder와 DTO 구성

오늘 커리큘럼에는:

@Builder
@NoArgsConstructor
@AllArgsConstructor

등 DTO 생성 관련 내용도 포함됐다.

오늘 실습에서는 특히 toBuilder()를 이용해 기존 Blog 데이터를 유지하면서 comments만 추가하는 방식이 실제로 사용됐다.

Blog 정보 유지
+
Comments 추가
        ↓
새 DTO

DTO를 어떻게 생성하고 조립하는지가 JSON 응답 구조와 직접 연결되기 때문에 DTO 생성 방식의 중요성을 확인할 수 있었다.

40. Blog 상세조회 최종 Service

핵심 로직은 다음 흐름이었다.

@Transactional(readOnly = true)
public BlogResponseDTO read(
        Integer id
) {

    BlogResponseDTO blog =
        blogMapper
            .findById(id)
            .orElseThrow(
                () -> new RuntimeException(
                    id + " BLOG NOT FOUND"
                )
            );

    return blog.toBuilder()
            .comments(
                commentMapper.findByBlogId(
                    blog.getId()
                )
            )
            .build();
}

41. 1:N Response DTO

최종 JSON은 개념적으로 다음 구조가 된다.

{
  "id": 1,
  "title": "첫번째 글",
  "content": "우와~ 성공이당 ㅎㅎ",
  "category": "일상",
  "email": "jslim9413@gmail.com",
  "comments": [
    {
      "id": 2,
      "comment": "마무리",
      "email": "jslim9413@gmail.com",
      "blogId": 1
    }
  ]
}

즉:

BlogResponseDTO
└─ comments : List<CommentResponseDTO>

의 1:N 응답 구조가 완성된다.

42. Blog 상세조회 실행 결과

실행 로그에서도:

blog controller read
blog controller read access token : Bearer ...
blog controller read params : 1

blog service read
blog service read params : 1

이 출력됐다.

결과 객체에도:

BlogResponseDTO(
    id=1,
    title=첫번째 글,
    ...
    comments=[]
)

형태가 확인됐다.

이후 댓글 데이터가 존재하면 comments 배열에 댓글이 포함됐다.

43. 상세조회 HTTP 상태 분기

Controller에서는:

return response != null
        ? ResponseEntity
            .status(HttpStatus.OK)
            .body(response)

        : ResponseEntity
            .status(HttpStatus.NOT_FOUND)
            .build();

형태로 반환했다.

Blog 존재
→ 200 OK

Blog 없음
→ 404 NOT_FOUND

44. Comment 기능 Package

댓글 기능도 Blog와 같은 계층 구조를 만들었다.

features
└─ comments
   ├─ ctrl
   │  └─ CommentController
   │
   ├─ domain
   │  └─ dto
   │     ├─ CommentRequestDTO
   │     └─ CommentResponseDTO
   │
   ├─ repository
   │  └─ CommentMapper
   │
   └─ service
      └─ CommentService

45. CommentController 생성

처음에는 골격부터 작성했다.

@RestController
@RequestMapping("/comments")
public class CommentController {

    @PostMapping("/insert")
    public ResponseEntity<?> insert() {
        return null;
    }
}

이후 DTO와 Service가 연결됐다.

46. React 댓글 등록

기존 json-server에서는:

await api.post('/comments', {
    blogId: Number(blogId),
    comment,
    email
});

를 사용했다.

Spring Boot 연동에서는:

await api.post(
    '/comments/insert',
    {
        blogId: Number(blogId),
        comment,
        email
    },
    {
        headers: {
            Authorization:
                at ? at : ""
        }
    }
);

로 변경했다.

47. 댓글 등록 요청 구조

POST /comments/insert

Headers
Authorization: Bearer ...

Body
{
    blogId,
    comment,
    email
}

즉 Blog 상세조회뿐 아니라 댓글 작성에도 Access Token을 같이 보내기 시작했다.

48. CommentService

Service도 생성했다.

초기 골격:

@Service
public class CommentService {

    public int insert(
            CommentRequestDTO request
    ) {

        System.out.println(
            "debug >>>> comment service insert"
        );

        System.out.println(
            "debug >>>> comment service insert params : "
            + request
        );

        ...
    }
}

이후 @RequiredArgsConstructor를 적용하며 Mapper 주입 구조로 확장됐다.

49. 댓글 등록 Controller → Service

Controller에서는:

int id =
    commentService.insert(request);

를 호출한다.

즉 댓글 INSERT 결과로 단순 영향 행 수가 아니라 새로 생성된 댓글 ID를 받아 사용하는 방향으로 구현했다.

50. Comment Insert 성공 응답

return id != 0
    ? ResponseEntity
        .status(HttpStatus.CREATED)
        .body(
            CommentRequestDTO
                .builder()
                .blogId(
                    request.getBlogId()
                )
                .email(
                    request.getEmail()
                )
                .comment(
                    request.getComment()
                )
                .id(id)
                .build()
        )

    : ResponseEntity
        .status(
            HttpStatus.BAD_REQUEST
        )
        .build();

51. 새 댓글 ID를 Response에 포함

댓글 등록 성공 시:

201 CREATED

뿐 아니라 생성된 댓글의 ID까지 포함한 객체를 Body로 반환한다.

{
  "id": 2,
  "blogId": 1,
  "email": "jslim9413@gmail.com",
  "comment": "마무리"
}

형태가 된다.

이렇게 하면 React가 추가 요청 없이 바로 새 댓글 객체를 상태에 넣을 수 있다.

52. MyBatis selectKey

댓글 INSERT에서는 MyBatis의 <selectKey>를 사용했다.

<insert id="save"
        parameterType="com.example.inspire_mybatis.features.comments.domain.dto.CommentRequestDTO">

    <selectKey
        keyProperty="id"
        resultType="int"
        order="BEFORE">

        SELECT NEXTVAL(COMMENT_SEQ)

    </selectKey>

    INSERT INTO SPRING_COMMENT_TBL
    VALUES(
        #{id},
        #{comment},
        #{email},
        #{blogId}
    )

</insert>

53. selectKey 동작 흐름

Comment Insert 요청
        ↓
SELECT NEXTVAL(COMMENT_SEQ)
        ↓
새 ID 생성
        ↓
request.id에 저장
        ↓
INSERT
        ↓
생성된 ID를 Java에서도 사용

즉 Sequence로 생성한 PK 값을 INSERT 전 Java DTO에 다시 넣을 수 있다.

54. order="BEFORE"

order="BEFORE"

이므로 INSERT보다 먼저 Sequence를 조회한다.

1. NEXTVAL
2. DTO.id 설정
3. INSERT

순서다.

55. React 댓글 상태 부분 갱신

댓글 등록 성공 후:

if (response.status === 201) {

    setComments(ary => {
        return [
            ...ary,
            response.data
        ];
    });

    setComment('');
}

를 실행한다.

56. 전체 재조회 대신 부분 업데이트

댓글 하나를 추가한 뒤 Blog 전체를 다시 조회하지 않는다.

기존 comments[]
       +
새 response.data
       ↓
새 comments[]

즉:

[...ary, response.data]

로 새 댓글만 추가한다.

React의 상태 변화에 따라 해당 영역만 다시 렌더링된다.

57. 댓글 입력 초기화

등록 성공 후:

setComment('');

으로 입력창을 비운다.

댓글 작성
→ POST 성공
→ comments 상태 추가
→ input 초기화

사용자 UI 흐름도 자연스럽게 연결됐다.

58. 실제 댓글 등록 확인

React 화면에서 댓글 "마무리"를 작성한 뒤 실제로 댓글 목록에 추가되는 것을 확인했다.

Chrome DevTools의 Axios 응답에서도:

status: 201

과 함께 새 Comment 데이터가 반환되는 것을 확인했다.

즉:

React
→ Spring Controller
→ Comment Service
→ Mapper
→ DB INSERT
→ Response
→ React State
→ 화면 리렌더링

전체 흐름이 정상 작동했다.

59. WebConfig를 이용한 CORS

React와 Spring Boot는 각각:

React
localhost:3000

Spring Boot
localhost:8000

에서 동작한다.

Port가 다르므로 다른 Origin이다.

따라서 기존 CorsConfig를 사용했다.

@Configuration
public class CorsConfig
        implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(
            CorsRegistry registry
    ) {

        registry
            .addMapping("/**")
            .allowedHeaders("*")
            .allowedOriginPatterns(
                "http://localhost:3000"
            )
            .allowedMethods(
                "GET",
                "POST",
                "DELETE",
                "PUT",
                "PATCH",
                "OPTIONS"
            );
    }
}

Blog와 Comment API에도 같은 설정이 적용됐다.

오늘 완성한 전체 구조

오늘 구현한 내용을 하나로 연결하면 다음과 같다.

React
│
├─ BlogIndexPage
│   └─ GET /blogs
│
├─ BlogWritePage
│   └─ POST /blogs/insert
│
└─ BlogReadPage
    ├─ GET /blogs/read/{id}
    │      + Authorization
    │
    └─ POST /comments/insert
           + Authorization
           ↓
Spring Boot
           ↓
Controller
           ↓
Service
           ↓
@Transactional
           ↓
Mapper
           ↓
MyBatis XML
           ↓
MariaDB
           ↓
Blog 1 : N Comment
           ↓
Response DTO
           ↓
JSON
           ↓
React State

오늘의 문제 해결 과정

1. json-server의 `_embed`를 Spring Boot로 어떻게 바꿀까?

기존 방식

GET /blogs/1?_embed=comments

json-server가 자동으로 Blog와 Comment를 묶어줬다.

Spring Boot에서는?

직접:

BlogMapper.findById()
+
CommentMapper.findByBlogId()

를 실행하고 Service에서 조립했다.

해결

BlogResponseDTO blog =
    blogMapper.findById(id)
        .orElseThrow(...);

return blog.toBuilder()
        .comments(
            commentMapper.findByBlogId(
                blog.getId()
            )
        )
        .build();

배운 점

Spring/MyBatis에서는 관계 데이터의 조회와 응답 DTO 조립 책임을 직접 설계해야 한다.

2. 여러 SELECT는 어디까지 하나의 Transaction인가?

상황

게시글 상세보기에는:

Blog SELECT
Comment SELECT

두 번의 DB 요청이 필요했다.

해결

@Transactional(readOnly = true)

를 Service 메서드에 적용했다.

배운 점

Transaction은 SQL 한 줄이 아니라 업무 관점의 논리적인 작업 단위로 보는 것이 중요하다.

게시글 상세보기
=
Blog 조회
+
Comment 조회
+
응답 조립

3. 기존 DTO를 직접 수정할 것인가?

기존 방식

blog.setComments(...);

변경

blog.toBuilder()
    .comments(...)
    .build();

배운 점

기존 DTO를 직접 변경하기보다 Builder로 새로운 응답 객체를 만들어 반환할 수 있다.

오늘 학습 주제였던 Builder와 DTO 구성 문제가 실제 1:N 응답 조립에서 사용됐다.

4. 로그인 후 Token은 어디에 사용하는가?

이전까지는 로그인 성공 후 AT를 저장하기만 했다.

오늘은:

headers: {
    Authorization: at ? at : ""
}

로 Blog 상세조회와 Comment 작성 요청에 실제로 Token을 전달했다.

Login
→ Token 발급
→ localStorage
→ 이후 API Authorization Header

즉 JWT가 실제 후속 요청과 연결되기 시작했다.

5. 댓글 등록 후 Blog 전체를 다시 조회할 필요가 있을까?

전체 Blog 상세를 다시 요청할 수도 있지만 오늘은:

setComments(ary => [
    ...ary,
    response.data
]);

를 이용했다.

결과

DB INSERT
→ 새 댓글 Response
→ 기존 comments 배열에 추가
→ 부분 리렌더링

불필요한 전체 재조회 없이 UI 상태를 갱신할 수 있었다.

✨ 오늘 배운 점

오늘은 지금까지 따로 배웠던 개념들이 실제 Blog 기능 안에서 하나로 연결됐다.

특히:

Database Relationship
MyBatis
Transaction
DTO
JWT
CORS
React State

가 하나의 Blog 상세화면 안에서 모두 사용됐다.

Blog와 Comment의 1:N 관계를 보면서 DB의 관계형 모델이 단순히 테이블 설계에서 끝나는 것이 아니라:

SQL 조회
→ Java DTO
→ JSON
→ React State

까지 계속 영향을 준다는 점이 명확해졌다.

오늘의 회고

오늘 가장 중요한 개념은 “하나의 사용자 기능은 여러 계층과 여러 DB 작업의 조합으로 완성된다”는 점이었다.

사용자 입장에서 게시글 상세보기는 단순한 클릭 한 번이다.

하지만 내부에서는:

Blog ID 전달
      ↓
Authorization Token 전달
      ↓
Controller
      ↓
Service
      ↓
Blog 조회
      ↓
Comment 조회
      ↓
DTO 조립
      ↓
JSON 직렬화
      ↓
React 상태 저장
      ↓
화면 렌더링

이라는 많은 과정이 실행된다.

그래서 @Transactional에서 말하는 논리적인 작업 단위가 왜 필요한지도 이전보다 훨씬 이해하기 쉬웠다.

MyBatis 1:N을 구현하며

json-server에서는:

?_embed=comments

한 줄이면 관계 데이터가 자동으로 붙었다.

하지만 Spring Boot에서는 직접:

BlogMapper
+
CommentMapper
+
Service

를 이용해 Blog와 댓글을 조립해야 했다.

처음에는 코드가 더 많아 보이지만, 오히려 어떤 데이터가 어디에서 만들어지고 어떤 책임을 갖는지가 더 명확해졌다.

Mapper
→ DB 조회

Service
→ 업무 흐름 및 관계 데이터 조립

Controller
→ HTTP 요청/응답

React
→ 화면 상태

로 각 계층의 역할이 분명했다.

DTO와 Builder

오늘 toBuilder() 방식이 특히 인상적이었다.

return blog.toBuilder()
        .comments(...)
        .build();

기존 객체에 Setter로 값을 추가하는 것과 달리, 기존 값을 기반으로 새로운 응답 객체를 생성했다.

DTO는 단순히 데이터를 담는 클래스라고만 생각했지만, 오늘은 API가 어떤 JSON 구조를 만들어낼지를 결정하는 중요한 계약 객체라는 점을 다시 확인했다.

오늘 커리큘럼에 포함된 Builder, NoArgsConstructor, AllArgsConstructor, DTO 직렬화 이슈도 결국 Spring이 DTO를 생성하고 JSON으로 변환하는 과정과 연결해서 복습해야겠다.

다음 학습 방향

현재 Blog와 Comment는 조회와 작성까지 실제 React와 연결됐다.

다음 단계에서는 다음 흐름을 집중해서 살펴보면 좋을 것 같다.

Blog Update / Delete

Comment Update / Delete

@Transactional
→ 쓰기 Transaction
→ Rollback

Exception Handling

JWT 실제 검증

Access Token 만료

Refresh Token 재발급

Spring Security

작성자 권한 검사

DTO Validation

Serialization / Deserialization

1:N MyBatis
→ ResultMap / Collection Mapping 방식 비교

특히 오늘 사용한:

Blog SELECT
+
Comment SELECT
+
Service에서 조립

방식과 MyBatis의 resultMap, collection을 이용한 관계 매핑 방식의 차이도 이후 비교해보면 좋을 것 같다.

[LG CNS 6기] 26일차 TIL : Spring Boot·MyBatis·Swagger·JWT·React 연동

bbbicsan — Wed, 2 Sep 2026 17:54:10 +0900

[LG CNS 6기] 26일차 TIL : Spring Boot·MyBatis·Swagger·JWT·React 연동

한 줄 요약
기존 Spring Boot + MyBatis 회원 기능을 새로운 프로젝트 구조로 옮기고, .env 기반 환경설정, Swagger/OpenAPI 문서화, 회원가입/로그인 API, Service/Mapper 계층, JWT 형태의 토큰 응답, CORS 설정, React Axios 연동까지 연결하며 프론트엔드와 백엔드가 실제로 통신하는 전체 흐름을 구현했다.

오늘 학습한 커리큘럼

Spring Boot + MyBatis 복습
        ↓
Mapper namespace / id
        ↓
Browser → Backend → DB → JSON
        ↓
Spring DI
plain / encryption Bean 교체
        ↓
로그인 성공/실패 ResponseEntity
        ↓
Optional 로그인 테스트
        ↓
새 inspire_mybatis 프로젝트 생성
        ↓
.env 환경변수 로딩
        ↓
MyBatis XML package 경로 오류
        ↓
패키지 정합성 수정
        ↓
Spring Boot 정상 기동
        ↓
Swagger / OpenAPI
        ↓
@Tag
@Operation
@ApiResponses
@RequestBody / Schema
        ↓
회원가입 계층 구현
Controller → Service → Mapper
        ↓
JWT Provider
Access Token / Refresh Token
        ↓
회원가입 중복 PK 오류
        ↓
로그인 Header 구성
Authorization / Refresh-Token
        ↓
@RequestParam QueryString 로그인
        ↓
React SignUp / SignIn
        ↓
Axios baseURL + .env
        ↓
CORS 설정
        ↓
React → Spring Boot 실제 요청
        ↓
로그인 성공
        ↓
localStorage에 user / AT / RT 저장

오늘의 학습 키워드

Spring Boot
MyBatis
Mapper XML
namespace
parameterType
resultType
Spring DI
@Resource
@RequiredArgsConstructor
Optional
.env
dotenv
Swagger
OpenAPI
@Tag
@Operation
@ApiResponse
@Schema
@RequestBody
@RequestParam
ResponseEntity
HttpHeaders
JWT
Access Token
Refresh Token
CORS
Axios
React
localStorage

1. MyBatis Mapper 연결 구조 복습

오늘은 먼저 기존 MyBatis XML과 Java Mapper의 연결 구조를 다시 확인했다.

<mapper namespace="com.example.testcase.features.users.repository.UserMapper">

    <insert id="save"
            parameterType="com.example.testcase.features.users.domain.dto.UserRequestDTO">

        INSERT INTO SPRING_USER_TBL(
            EMAIL,
            PASSWORD,
            NAME
        )
        VALUES(
            #{email},
            #{password},
            #{name}
        )

    </insert>

</mapper>

핵심 연결은 다음과 같다.

Java Mapper Interface
UserMapper
       ↕
XML namespace

Java Method
save()
       ↕
XML statement id="save"

즉 MyBatis에서는 Java Mapper 메서드명과 XML의 id가 일치해야 한다.

2. MyBatis의 parameter binding

VALUES(
    #{email},
    #{password},
    #{name}
)

이 값들은 DTO의 property와 연결된다.

#{email}
→ getEmail()

#{password}
→ getPassword()

#{name}
→ getName()

이전 JDBC에서 직접 작성했던:

pstmt.setString(...);

부분을 MyBatis가 대신 처리해주는 구조다.

3. 요청 처리 전체 흐름 복습

강의에서는 프론트와 백엔드, DB의 관계도 다시 연결했다.

Browser / React
      ↓
HTTP Request
      ↓
Spring Boot Backend
      ↓
Controller
      ↓
Service
      ↓
Mapper
      ↓
MyBatis
      ↓
Database
      ↓
DTO
      ↓
JSON Response
      ↓
Browser / React

이제 각각의 개념을 따로 보는 것이 아니라 하나의 요청 사슬로 보기 시작했다.

4. 기존 Java 생성자 주입과 Spring DI 비교

이전에 Java 콘솔 Blog 프로젝트에서는 직접 생성자를 통해 의존성을 전달했다.

public class DeleteController {

    private BlogReactService service;

    public DeleteController(BlogReactService service) {
        this.service = service;
    }

    public int delete(int blogId) {
        return service.delete(blogId);
    }
}

이 구조는:

객체를 직접 생성
      ↓
생성자로 Dependency 전달
      ↓
this.service = service

였다.

Spring에서는 이 역할을 Container가 대신 수행한다.

Java 직접 연결
→ 개발자가 객체 생성/전달

Spring DI
→ Spring Container가 Bean 생성/주입

이전에 배운 객체지향의 느슨한 결합, 인터페이스, 다형성이 Spring DI에서 실제로 활용된다는 점을 다시 확인했다.

5. Bean 이름으로 Service 구현체 교체

기존에는:

@Resource(name = "plain")
private UserService userService;

를 사용했다.

오늘은:

@Resource(name = "encryption")
private UserService userService;

로 변경하는 예제도 확인했다.

구조:

UserService
├─ plain
└─ encryption

Controller는 여전히:

userService.signIn(request);

만 호출한다.

즉 구체 구현체를 직접 참조하지 않고 Bean 이름만 바꿔 실행 구현을 교체할 수 있다.

@Resource(name="plain")
→ Plain 구현체

@Resource(name="encryption")
→ Encryption 구현체

이것이 인터페이스 기반 다형성과 DI의 장점이었다.

6. 로그인 성공/실패 ResponseEntity 분기

로그인 Service 호출 결과에 따라 HTTP 응답을 다르게 반환하는 구조도 확인했다.

UserResponseDTO response = userService.signIn(request);

if (response != null) {

    return ResponseEntity
            .status(HttpStatus.OK)
            .header("access-token", "12345")
            .body(response);

} else {

    return ResponseEntity
            .status(HttpStatus.NOT_FOUND)
            .body(null);
}

흐름:

로그인 성공
→ response != null
→ 200 OK
→ Header
→ UserResponseDTO Body

로그인 실패
→ response == null
→ 404 NOT_FOUND

이후 코드는 더 발전했지만, 이 단계에서 Service 결과에 따라 Controller가 HTTP 응답을 설계한다는 점을 확인했다.

7. Optional을 이용한 로그인 조회

로그인 Mapper의 반환형은:

Optional<UserResponseDTO>

형태로 변경됐다.

Optional<UserResponseDTO> response =
        userMapper.login(request);

의미:

조회 결과 있음
→ Optional<UserResponseDTO>

조회 결과 없음
→ Optional.empty()

이다.

8. Optional 로그인 테스트

테스트는 Given-When-Then 구조를 유지했다.

@Test
public void signIn() {

    // given
    UserRequestDTO request =
        UserRequestDTO.builder()
            .email("jslim@gmail.com")
            .password("1234")
            .build();

    // when
    Optional<UserResponseDTO> response =
        userMapper.login(request);

    // then
    Assertions.assertNotNull(response.get());

    Assertions.assertEquals(
        "jslim9413@gmail.com",
        response.get().getEmail()
    );
}

또한 다음 방식도 확인했다.

response.orElseThrow(
    () -> new RuntimeException("이메일 또는 패스워드가 불일치")
);

Optional 값 있음
→ 정상 사용자 반환

Optional.empty()
→ RuntimeException

9. 테스트 데이터와 실제 DB 값 확인

MariaDB에서 회원 데이터를 직접 확인했다.

EMAIL                    PASSWORD   NAME
jslim9413@gmail.com      1234       ...
jslim9413@naver.com      1234       ...

테스트 작성 시:

Given의 입력값
vs
DB에 실제 저장된 값

이 정확히 일치해야 한다.

특히 이메일처럼 WHERE 조건으로 사용되는 값은 오타 하나만 있어도 로그인 조회가 실패하기 때문에 테스트 데이터 정합성이 중요했다.

10. Controller → Encryption Service 실제 실행 확인

실행 로그에서는 다음 흐름까지 확인했다.

user controller signIn get mapping

user controller signIn params :
UserRequestDTO(...)

user controller signIn service binding :
UserEncryptionServiceImpl...

user encryption service signIn

params :
UserRequestDTO(...)

즉:

HTTP Request
      ↓
Controller
      ↓
@Resource(name="encryption")
      ↓
UserEncryptionServiceImpl
      ↓
signIn()

이 실제 런타임에서도 정상 연결되는 것을 확인했다.

11. 브라우저에서 로그인 API 직접 호출

브라우저에서 실제 요청을 실행했다.

http://localhost:8000/users/signIn
?email=jslim9413@gmail.com
&password=1234

응답은 JSON으로 정상 반환됐다.

{
  "email": "jslim9413@gmail.com",
  "name": "임정섭",
  "password": "1234"
}

즉 전체 흐름이 실제로 연결됐다.

Browser
   ↓
GET /users/signIn
   ↓
UserRequestDTO
   ↓
Controller
   ↓
Service
   ↓
Mapper
   ↓
MariaDB
   ↓
UserResponseDTO
   ↓
JSON

12. ResponseEntity로 로그인 응답 구성

Controller에서는:

return ResponseEntity
        .status(HttpStatus.OK)
        .header("access-token", "12345")
        .body(response);

형태로 응답을 반환했다.

구조:

Status
→ 200 OK

Header
→ access-token

Body
→ UserResponseDTO

이후 실제 JWT 형태의 Access/Refresh Token 응답으로 발전했다.

13. 새로운 inspire_mybatis 프로젝트 생성

기존 프로젝트와 별도로:

inspire_mybatis

Spring Boot 프로젝트를 새로 생성했다.

메인 클래스:

@SpringBootApplication
public class InspireMybatisApplication {

    public static void main(String[] args) {

        SpringApplication.run(
            InspireMybatisApplication.class,
            args
        );
    }
}

새 프로젝트로 기존 코드를 옮기면서 패키지 경로와 환경설정을 다시 맞추는 작업이 필요했다.

14. .env 환경변수 로딩

민감 정보를 코드에 직접 넣지 않기 위해 .env를 사용했다.

Dotenv env = Dotenv.configure()
        .ignoreIfMissing()
        .load();

env.entries().forEach(entry -> {

    System.setProperty(
        entry.getKey(),
        entry.getValue()
    );

    System.out.println(
        "debug >>>> env : "
        + entry.getKey()
        + "\t"
        + entry.getValue()
    );
});

흐름:

.env
 ↓
dotenv-java
 ↓
key / value 읽기
 ↓
System.setProperty()
 ↓
Spring 설정에서 참조

15. .env를 사용하는 이유

DB 비밀번호처럼 민감한 값은 코드에 직접 넣거나 GitHub에 올리지 않는 것이 좋다.

DB PASSWORD
API KEY
TOKEN
SECRET

등을:

.env

파일로 분리한다.

코드
→ 공개 가능

민감정보
→ .env
→ Git 제외

오늘 TIL에서는 실제 비밀번호나 토큰 값은 기록하지 않고 구조만 남겼다.

문제 해결 과정 1. 새 프로젝트에서 MyBatis ClassNotFoundException

새 프로젝트 실행 중 MyBatis Mapper XML을 읽으면서 오류가 발생했다.

BuilderException
Error resolving class

TypeException
Could not resolve type alias

ClassNotFoundException
Cannot find class:
com.example.testcase.features.users.domain.dto.UserRequestDTO

증상

Spring Boot가 시작되는 과정에서 MyBatis Mapper를 생성하지 못했다.

원인

새 프로젝트의 package는:

com.example.inspire_mybatis

인데 Mapper XML에서는 이전 프로젝트의:

com.example.testcase

경로를 그대로 사용하고 있었다.

현재 Java Package
com.example.inspire_mybatis...

XML
com.example.testcase...
        ↓
불일치

확인할 부분

<mapper namespace="...">

parameterType="..."

resultType="..."

세 곳 모두 Java의 실제 package와 맞아야 한다.

해결

Mapper XML의 package를 새 프로젝트 기준으로 수정했다.

com.example.testcase...
        ↓
com.example.inspire_mybatis...

검증

수정 후 재실행하자:

MariaDB Connection
HikariPool Initialization
Hibernate ORM Initialization
Started InspireMybatisApplication

로그가 출력됐다.

즉 Spring Boot가 정상 기동됐다.

16. Swagger UI 연결

Springdoc을 추가한 뒤 Swagger UI에 접속했다.

http://localhost:8000/swagger-ui/index.html

화면에서:

POST /users/signUp
GET  /users/signIn

두 API가 자동으로 문서화된 것을 확인했다.

17. Swagger/OpenAPI 의존성

build.gradle에는 다음 의존성이 추가됐다.

implementation 'org.springdoc:springdoc-openapi-starter-webmvc-ui:2.7.0'

.env용 라이브러리도 추가했다.

implementation 'io.github.cdimascio:dotenv-java:3.0.0'

springdoc-openapi
→ Swagger UI

dotenv-java
→ .env 로딩

18. @Tag

Controller에 API 그룹 정보를 추가했다.

@Tag(
    name = "User API",
    description = "사용자 생성과 로그인 관련 API 명세서"
)
@RestController
@RequestMapping("/users")
public class UserController {
}

Swagger UI에서 실제로:

User API
사용자 생성과 로그인 관련 API 명세서

가 표시됐다.

19. @Operation

회원가입 API에 설명을 추가했다.

@Operation(
    summary = "회원가입",
    description = "신규가입(email, password, name)"
)
@PostMapping("/signUp")

Swagger UI에서는 endpoint 옆에:

회원가입

이라는 의미 있는 설명이 표시됐다.

20. @ApiResponses

회원가입 API 응답을 문서화했다.

@ApiResponses({
    @ApiResponse(
        responseCode = "201",
        description = "가입성공"
    ),
    @ApiResponse(
        responseCode = "400",
        description = "유효성검사실패"
    ),
    @ApiResponse(
        responseCode = "500",
        description = "가입실패"
    )
})

즉 API 명세에서:

201
→ 가입 성공

400
→ 유효성 검증 실패

500
→ 가입 처리 실패

를 명확하게 표현했다.

21. Swagger RequestBody와 Spring RequestBody

회원가입 API에서는 같은 이름의 두 RequestBody를 함께 사용했다.

Swagger 문서용:

@io.swagger.v3.oas.annotations.parameters.RequestBody(
    description = "사용자 정보를 담는 DTO",
    required = true,
    content = @Content(
        schema = @Schema(
            implementation = UserRequestDTO.class
        )
    )
)

실제 Spring 바인딩용:

@org.springframework.web.bind.annotation.RequestBody
UserRequestDTO request

22. 두 RequestBody의 역할 차이

Swagger @RequestBody
→ API 문서 명세

Spring @RequestBody
→ 실제 JSON → Java DTO 바인딩

즉:

Swagger
"이 API는 이런 JSON을 받습니다"

Spring
"실제로 들어온 JSON을 DTO로 변환합니다"

라는 차이가 있다.

23. 회원가입 요청값 실제 바인딩 확인

실제 회원가입 요청 로그에서:

user controller signup

user controller signup params :
UserRequestDTO(
    email=jslim9413@naver.com,
    password=1234,
    name=임정섭
)

이 출력됐다.

즉:

HTTP JSON Body
     ↓
@RequestBody
     ↓
UserRequestDTO

가 정상 동작했다.

24. 회원가입 계층 구현 시작

회원가입 기능을 Controller에서 Service/Mapper 구조로 분리했다.

UserController
     ↓
UserService
     ↓
UserMapper
     ↓
MyBatis XML
     ↓
MariaDB

UserService:

@Service
public class UserService {

    public int signUp(UserRequestDTO request) {

        System.out.println(
            "debug >>>> user service signUp"
        );

        return 0;
    }
}

이 단계에서는 아직 골격 코드였다.

25. UserMapper 기능 정의

Mapper는 이후 다음 형태로 확장됐다.

@Mapper
public interface UserMapper {

    public int save(UserRequestDTO request);

    public Optional<UserResponseDTO> signIn(
        UserRequestDTO request
    );
}

역할:

save()
→ 회원가입 INSERT
→ int

signIn()
→ 로그인 SELECT
→ Optional<UserResponseDTO>

26. 회원가입 Controller → Service 연결

Controller에서는:

int signUpFlag =
        userService.signUp(request);

를 호출하게 됐다.

if (signUpFlag != 0) {

    return ResponseEntity
            .status(HttpStatus.CREATED)
            .body(null);
}

흐름:

POST /users/signUp
      ↓
Controller
      ↓
Service
      ↓
Mapper.save()
      ↓
INSERT
      ↓
1 반환
      ↓
201 Created

27. @RequiredArgsConstructor 기반 생성자 주입

Service는 다음 구조로 변경됐다.

@Service
@RequiredArgsConstructor
public class UserService {

    private final UserMapper userMapper;
    private final JwtProvider jwtProvider;

    ...
}

final 필드를 선언하면 Lombok이 생성자를 만들어준다.

final UserMapper
final JwtProvider
       ↓
@RequiredArgsConstructor
       ↓
Constructor 자동 생성
       ↓
Spring DI

28. Service에서 Mapper 호출

회원가입 로직은 최종적으로:

public int signUp(UserRequestDTO request) {

    System.out.println(
        "debug >>>> user service signUp"
    );

    return userMapper.save(request);
}

형태가 됐다.

즉 Service가 직접 SQL을 처리하는 것이 아니라 Repository/Mapper에 위임한다.

29. JwtProvider Bean

공통 token 기능을 담당하는 클래스를 만들었다.

@Component
public class JwtProvider {

    public String createAT(String email) {
        return "Bearer XXXXXXX";
    }

    public String createRT(String email) {
        return "XXXXXXXXXXXXXX";
    }
}

현재는 실제 JWT 서명 알고리즘 구현이 아니라 토큰 발급 흐름을 만들기 위한 골격 코드였다.

30. 로그인 실패 처리

Service에서:

userMapper
    .signIn(request)
    .orElseThrow(
        () -> new RuntimeException("로그인 실패")
    );

형태로 로그인 실패를 처리했다.

DB 사용자 존재
→ 로그인 성공

DB 사용자 없음
→ Optional.empty
→ orElseThrow
→ RuntimeException

31. 로그인 성공 후 Token 발급

로그인 성공 시:

String at =
    jwtProvider.createAT(request.getEmail());

String rt =
    jwtProvider.createRT(request.getEmail());

을 통해 토큰을 생성했다.

로그인 성공
      ↓
JwtProvider
      ↓
Access Token
Refresh Token

32. 향후 Token 저장 방향

강의 코드 주석에서는:

inMemory DB
→ Redis
→ H2

등에 AT/RT를 저장해 관리하는 방향도 언급됐다.

즉 현재는 토큰 생성까지만 구현하고, 실제 저장/만료/재발급 등의 인증 인프라는 이후 단계로 남아 있다.

문제 해결 과정 2. 회원가입 중복 이메일

회원가입 실행 중 다음 오류가 발생했다.

Duplicate entry 'inspire@lgcns.com'
for key 'PRIMARY'

Spring에서는:

DuplicateKeyException

으로 변환되어 올라왔다.

원인

회원 테이블의:

EMAIL VARCHAR(50) PRIMARY KEY

때문이다.

이미 존재하는 EMAIL을 다시 INSERT하면 PK 중복 오류가 발생한다.

동일 Email 존재
      ↓
회원가입 재요청
      ↓
INSERT
      ↓
PRIMARY KEY 중복
      ↓
DuplicateKeyException

배운 점

DB 제약조건은 Spring/MyBatis를 사용하더라도 그대로 적용된다.

이후에는:

중복 이메일 사전 조회

또는

DuplicateKeyException 처리

같은 예외 처리 전략이 필요하다.

33. 로그인 Service 결과를 Map으로 반환

사용자 정보와 토큰을 모두 Controller에 전달하기 위해 Service의 반환형을:

Map<String, Object>

로 변경했다.

개념적으로:

Map<String, Object> map = new HashMap<>();

map.put("at", at);
map.put("rt", rt);
map.put("response", response);

return map;

형태다.

34. Controller에서 HttpHeaders 생성

Controller에서는:

Map<String, Object> map =
        userService.signIn(request);

HttpHeaders headers =
        new HttpHeaders();

로 Service의 로그인 결과를 받았다.

35. Access Token / Refresh Token Header

headers.add(
    "Authorization",
    (String) map.get("at")
);

headers.add(
    "Refresh-Token",
    (String) map.get("rt")
);

응답 Header는:

Authorization
→ Access Token

Refresh-Token
→ Refresh Token

으로 구성했다.

36. Access-Control-Expose-Headers

브라우저의 JavaScript에서 커스텀 Response Header를 읽을 수 있도록:

headers.add(
    "Access-Control-Expose-Headers",
    "Authorization, Refresh-Token"
);

설정을 추가했다.

Spring Response
      ↓
Authorization
Refresh-Token
      ↓
Access-Control-Expose-Headers
      ↓
React Axios에서 Header 접근 가능

37. 로그인 최종 ResponseEntity

return ResponseEntity
        .status(HttpStatus.OK)
        .headers(headers)
        .body(
            (UserResponseDTO)
                map.get("response")
        );

최종적으로:

HTTP 200 OK

Headers
Authorization: AT
Refresh-Token: RT

Body
UserResponseDTO

형태의 응답이 완성됐다.

38. Swagger 로그인 응답 명세

로그인 API에도 응답 시나리오를 문서화했다.

200
→ 로그인 성공

400
→ 로그인 실패

Swagger 문서가 실제 Controller 구현과 함께 발전하는 흐름을 확인했다.

39. 로그인 Query String 방식으로 변경

로그인 API는 GET 요청이므로 Query String 방식으로 변경했다.

@GetMapping("/signIn")
public ResponseEntity<?> signIn(

    @RequestParam("email")
    String email,

    @RequestParam("password")
    String password
) {
    ...
}

요청:

/users/signIn
?email=...
&password=...

40. @RequestParam

흐름:

Query String

email=aaa
password=1234
      ↓
@RequestParam
      ↓
String email
String password

회원가입의 @RequestBody와 비교하면:

회원가입
POST JSON
→ @RequestBody DTO

로그인
GET QueryString
→ @RequestParam

으로 구분됐다.

41. React 환경별 .env

React 프로젝트에서도:

.env
.env.development
.env.production

파일을 분리했다.

백엔드의:

application-dev.yml
application-prod.yml

과 같은 목적이다.

Development
→ 개발 API URL

Production
→ 운영 API URL

을 분리할 수 있다.

42. Axios 공통 Instance

src/api/axios.js에서 Axios 인스턴스를 만들었다.

import axios from 'axios';

const endPoint =
    process.env.REACT_APP_BACKEND_ENDPOINT;

const api = axios.create({
    baseURL: endPoint
});

export default api;

흐름:

.env
 ↓
REACT_APP_BACKEND_ENDPOINT
 ↓
process.env
 ↓
axios.create
 ↓
baseURL

43. URL 하드코딩 제거

이제 React 각 컴포넌트에서:

api.post('/users/signUp', data);

처럼 작성할 수 있다.

실제 요청 URL은:

REACT_APP_BACKEND_ENDPOINT
+
/users/signUp

로 구성된다.

환경별 endpoint 변경이 훨씬 쉬워졌다.

44. React form과 Backend DTO 연결

회원가입 화면의 form 상태는:

const [form, setForm] = useState({
    name: '',
    email: '',
    password: ''
});

형태다.

이 구조가 백엔드의:

UserRequestDTO
├─ name
├─ email
└─ password

와 대응된다.

React form
     ↓ JSON
UserRequestDTO

따라서 프론트와 백엔드 간 필드명 정합성이 중요하다.

45. 공통 Input Handler

const keyHandler = (e) => {

    const { name, value } = e.target;

    setForm({
        ...form,
        [name]: value
    });
};

핵심:

...form
→ 기존 값 유지

[name]
→ 현재 Input의 name을 key로 사용

value
→ 입력된 새로운 값

하나의 handler로 여러 input을 처리할 수 있다.

46. React 회원가입 API 호출

await api.post(
    '/users/signUp',
    data
)
.then(response => {

    console.log(
        'debug >>>> axios request success',
        response
    );

    if (response.status === 201) {
        moveUrl('/users/signIn');
    }
})
.catch(error => {

    console.log(
        'debug >>>> axios request error',
        error
    );
});

흐름:

SignUpPage
      ↓
form
      ↓
Axios POST
      ↓
Spring /users/signUp
      ↓
201 Created
      ↓
SignIn Page 이동

47. CORS 문제

React는:

http://localhost:3000

Spring Boot는:

http://localhost:8000

에서 실행된다.

Origin은:

scheme + host + port

로 구분되므로:

localhost:3000
≠
localhost:8000

이다.

따라서 브라우저 CORS 정책을 통과시키기 위한 설정이 필요했다.

48. CorsConfig

@Configuration
public class CorsConfig
        implements WebMvcConfigurer {

    @Override
    public void addCorsMappings(
            CorsRegistry registry
    ) {

        registry
            .addMapping("/**")
            .allowedHeaders("*")
            .allowedOriginPatterns(
                "http://localhost:3000"
            )
            .allowedMethods(
                "GET",
                "POST",
                "DELETE",
                "PUT",
                "PATCH",
                "OPTIONS"
            );
    }
}

49. CORS 설정 의미

addMapping("/**")
→ 모든 Backend API에 적용

allowedOriginPatterns(...)
→ React Origin 허용

allowedHeaders("*")
→ 모든 요청 Header 허용

allowedMethods(...)
→ 허용 HTTP Method

OPTIONS는 Preflight Request와 연결된다.

50. Preflight Request

브라우저는 조건에 따라 실제 요청 전에:

OPTIONS

요청을 먼저 보낼 수 있다.

Browser
   ↓
OPTIONS
"이 요청 보내도 됩니까?"
   ↓
Spring CORS 정책
   ↓
허용
   ↓
POST / GET 실제 요청

51. React → Spring 회원가입 실제 요청 확인

React에서 회원가입 요청을 보낸 뒤 Spring 로그에:

user controller signup

UserRequestDTO(
    email=...,
    password=1234,
    name=...
)

user service signUp

이 출력됐다.

즉:

React
 ↓
Axios
 ↓
CORS
 ↓
UserController
 ↓
UserService

까지 실제 통신이 성공했다.

52. React 로그인 API 호출

로그인 화면에서는:

await api.get(
    `/users/signIn?email=${form.email}&password=${form.password}`
)

방식으로 요청했다.

또한 Axios에서는 다음 방식도 가능하다.

await api.get('/users/signIn', {
    params: {
        email: form.email,
        password: form.password
    }
});

53. Query String 직접 조립 vs params

직접 조립

/users/signIn?email=${...}&password=${...}

Axios params

api.get('/users/signIn', {
    params: {
        email,
        password
    }
})

둘 모두 동일한 Query String 요청을 만든다.

params 방식을 사용하면 URL 문자열을 직접 조립하지 않아도 된다는 차이가 있다.

54. Axios Response 확인

.then(response => {

    console.log(
        'debug >>>> axios request success',
        response
    );

})

Chrome DevTools에서 실제 response 객체를 확인했다.

status: 200

data:
→ 사용자 정보

headers:
→ authorization
→ refresh-token

55. Authorization / Refresh-Token 브라우저 확인

DevTools에서 실제로:

authorization:
Bearer ...

refresh-token:
...

헤더가 보였다.

즉 백엔드의:

Access-Control-Expose-Headers

설정이 실제로 동작하고 있었다.

Spring
→ JWT Header 반환

CORS expose
→ Header 공개

Axios
→ response.headers 접근 성공

56. 로그인 Response Data 구조 수정

기존 프론트 코드에는:

response.data[0].email

이 남아 있었다.

하지만 현재 Spring 로그인 응답은 배열이 아니라 단건 DTO 객체다.

따라서:

response.data.email

로 수정했다.

기존 가정
Array Response

현재 Backend
Single Object Response

프론트와 백엔드 응답 구조의 정합성을 맞춘 사례였다.

57. localStorage에 사용자 정보 저장

로그인 성공 후:

localStorage.setItem(
    'user',
    response.data.email
);

로 로그인 사용자의 email을 저장했다.

58. Access Token 저장

localStorage.setItem(
    'at',
    response.headers.get('Authorization')
);

59. Refresh Token 저장

localStorage.setItem(
    'rt',
    response.headers.get('Refresh-Token')
);

즉 로그인 성공 후:

localStorage

user
→ 로그인 email

at
→ Access Token

rt
→ Refresh Token

을 저장한다.

60. 로그인 성공 후 전체 흐름

SignInPage
      ↓
GET /users/signIn
      ↓
@RequestParam
      ↓
Controller
      ↓
Service
      ↓
Mapper
      ↓
MariaDB
      ↓
JwtProvider
      ↓
Access Token
Refresh Token
      ↓
ResponseEntity
      ↓
Axios Response
      ↓
localStorage
├─ user
├─ at
└─ rt

현재 /blogs/index로 이동하는 코드는 주석 처리되어 있어, 우선 토큰 저장까지 검증한 상태였다.

오늘의 문제 해결 과정

1. MyBatis Mapper package 경로 불일치

증상

ClassNotFoundException
Could not resolve type alias

원인

새 프로젝트로 코드를 복사했지만 XML에는 기존 com.example.testcase package가 남아 있었다.

해결

namespace
parameterType
resultType

경로를 새 com.example.inspire_mybatis 기준으로 수정했다.

검증

Spring Boot 정상 기동.

2. 회원가입 중복 이메일

증상

Duplicate entry ... for key PRIMARY
DuplicateKeyException

원인

EMAIL이 PRIMARY KEY인데 이미 존재하는 이메일로 INSERT했다.

배운 점

Spring/MyBatis를 사용해도 DB 제약조건은 그대로 적용된다.

향후 중복 확인 또는 예외 응답 처리가 필요하다.

3. React ↔ Spring CORS

증상/문제

React : localhost:3000
Spring: localhost:8000

포트가 달라 다른 Origin이다.

해결

CorsConfig
→ allowedOriginPatterns("http://localhost:3000")

를 추가했다.

검증

React 회원가입 요청이 Controller와 Service 로그까지 정상 도달했다.

4. Response 구조 불일치

기존 코드

response.data[0].email

실제 Backend Response

{
  "email": "...",
  ...
}

해결

response.data.email

로 변경했다.

배운 점

Front와 Backend 간에는 단순 endpoint뿐 아니라 JSON 구조까지 계약이 맞아야 한다.

5. JWT Header 접근

백엔드에서 토큰을 Header로 내려줬지만 브라우저 JavaScript에서 읽으려면 커스텀 Header 노출 설정이 필요했다.

해결

Access-Control-Expose-Headers
→ Authorization, Refresh-Token

검증

Chrome DevTools Axios response에서 두 Header를 실제로 확인했고 localStorage 저장 코드까지 연결했다.

✨ 오늘 배운 점

오늘은 지금까지 배웠던 Spring Boot 개념들이 실제 프론트엔드와 연결되면서 하나의 애플리케이션 흐름으로 완성되기 시작했다.

이전에는:

Controller
Service
Mapper
Swagger
React
JWT
CORS

를 각각 따로 학습했다.

오늘은 이 개념들이 모두 다음과 같이 하나의 요청에서 연결됐다.

React Form
    ↓
Axios
    ↓
CORS
    ↓
Spring Controller
    ↓
Service
    ↓
Mapper
    ↓
MyBatis
    ↓
MariaDB
    ↓
JWT Provider
    ↓
ResponseEntity
    ↓
Axios Response
    ↓
localStorage

특히 백엔드 코드만 잘 작성한다고 끝나는 것이 아니라 프론트가 어떤 방식으로 요청하고 어떤 응답 구조를 기대하는지까지 맞춰야 API가 실제로 동작한다는 점을 직접 확인할 수 있었다.

오늘의 회고

오늘 가장 크게 느낀 부분은 계층 분리가 실제로 왜 필요한지였다.

회원가입 하나만 보더라도:

Controller
→ HTTP 요청 해석

Service
→ 회원가입 로직

Mapper
→ SQL 실행

DB
→ 데이터 저장

으로 책임이 분리된다.

로그인은 여기에:

JwtProvider
→ 토큰 발급

이라는 추가 책임이 들어갔다.

그리고 Controller가 모든 일을 직접 하지 않기 때문에 각 객체의 역할이 명확해졌다.

이 구조는 이전 Java 수업에서 배운:

Interface
Polymorphism
Loose Coupling
Factory
DI

개념들이 실제 Spring 프로젝트에 적용된 결과라는 점도 다시 확인할 수 있었다.

Swagger를 사용해보며 느낀 점

Swagger를 사용하면서 API가 단순히 코드에 존재하는 메서드가 아니라 프론트엔드와 공유해야 하는 계약이라는 점도 명확해졌다.

HTTP Method
Endpoint
Request Body
Request Parameter
Response Status
Response Body

를 문서로 남기면 프론트에서도 어떤 방식으로 요청해야 하는지 알 수 있다.

특히:

@Tag
@Operation
@ApiResponses
@Schema

를 통해 코드와 API 문서를 함께 관리하는 방식이 실무적인 느낌이 강했다.

환경변수의 중요성

백엔드와 프론트 모두 환경별 설정을 분리했다.

Backend
.env
application-dev.yml
application-prod.yml

Frontend
.env
.env.development
.env.production

이 구조를 통해:

Local
Development
Production

환경마다 URL이나 DB 설정을 다르게 가져갈 수 있다는 점을 이해했다.

또한 비밀번호나 Secret 같은 값을 GitHub에 직접 올리지 않도록 .env를 사용하는 이유도 확인했다.

다음 학습 방향

다음에는 현재 만든 로그인 구조를 기반으로 실제 인증/인가를 더 확장할 가능성이 높다.

복습할 흐름은:

회원가입
POST /users/signUp
→ JSON
→ @RequestBody
→ Service
→ Mapper
→ DB
→ 201

로그인
GET /users/signIn
→ QueryString
→ @RequestParam
→ Service
→ Mapper
→ JWT
→ Header + Body
→ React
→ localStorage

추가로 다음 개념을 집중해서 확인해야겠다.

JWT 실제 생성/검증

Access Token 만료

Refresh Token 재발급

Authorization Header 사용

Axios Interceptor

Spring Security

로그인 실패 Exception 처리

회원 중복 가입 처리

Validation

Redis 기반 Token 관리

React 로그인 상태 유지

보호된 API 요청

현재는 JwtProvider가 임시 문자열을 반환하는 수준이므로, 실제 JWT 서명과 인증/인가가 적용되면 오늘 만든 흐름과 비교하면서 학습하면 이해하기 좋을 것 같다.

[LG CNS 6기] 25일차 TIL : Spring MVC Controller·REST API·IoC/DI·MyBatis·TDD

bbbicsan — Tue, 1 Sep 2026 20:21:10 +0900

[LG CNS 6기] 25일차 TIL : Spring MVC Controller·REST API·IoC/DI·MyBatis·TDD

한 줄 요약
Spring Boot 서버를 직접 기동한 뒤 Controller → Service → Mapper → MyBatis → MariaDB로 이어지는 요청 처리 흐름을 구현했고, @Controller와 @RestController, RequestMapping, DTO 바인딩, ResponseEntity, IoC/DI, MyBatis XML Mapper, JUnit 기반 Given-When-Then 테스트까지 연결했다.

오늘 학습한 커리큘럼

Spring Boot Server 실행
        ↓
Embedded Tomcat
DispatcherServlet
        ↓
localhost:8000 접속
        ↓
Whitelabel 404 확인
        ↓
@Controller
@RequestMapping
@GetMapping
        ↓
JSP View Rendering
WEB-INF/view/index.jsp
        ↓
@RestController
        ↓
DTO → JSON
        ↓
ResponseEntity
Status / Header / Body
        ↓
기능 단위 Package 구조
users
├─ ctrl
├─ domain
├─ service
└─ repository
        ↓
Spring IoC / Bean / DI
        ↓
@Autowired
@Resource
@Qualifier
@RequiredArgsConstructor
        ↓
MyBatis
Mapper Interface
Mapper XML
        ↓
SpringBootTest
Given - When - Then
        ↓
BindingException 발생
        ↓
mapper-locations 수정
        ↓
INSERT 성공
assertEquals()
        ↓
findByAll()
login()
        ↓
Controller → Service DI
        ↓
@Resource(name = "plain")
        ↓
UserPlainServiceImpl Bean 주입 확인

오늘의 학습 키워드

Spring Boot
Spring MVC
Embedded Tomcat
DispatcherServlet
@Controller
@RestController
@RequestMapping
@GetMapping
@RequestParam
DTO Binding
JSP
ViewResolver
ResponseEntity
HttpStatus
Spring Bean
IoC
DI
Dependency Lookup
@Autowired
@Resource
@Qualifier
@RequiredArgsConstructor
MyBatis
@Mapper
Mapper XML
parameterType
resultType
mapper-locations
@SpringBootTest
JUnit
TDD
Given / When / Then
Assertion

1. Spring Boot 서버 기동

오늘 수업은 전날 생성한 Spring Boot 프로젝트를 실제로 실행하는 것부터 시작했다.

터미널 로그에서:

Tomcat initialized with port 8000 (http)
Tomcat started on port 8000 (http)
Started DemoApplication

이 출력되는 것을 확인했다.

즉 흐름은:

DemoApplication 실행
        ↓
SpringApplication.run()
        ↓
Spring Boot Context 생성
        ↓
Embedded Tomcat 시작
        ↓
8000 Port에서 요청 대기

였다.

2. DispatcherServlet 초기화

브라우저에서 서버에 접속하자 DispatcherServlet도 초기화됐다.

Initializing Spring DispatcherServlet
Completed initialization

Spring MVC 요청 흐름에서 DispatcherServlet은 모든 요청의 Front Controller 역할을 한다.

Browser
   ↓
Tomcat
   ↓
DispatcherServlet
   ↓
Controller 탐색
   ↓
Controller Method 실행

예전에 Java MVC 구조를 배울 때 만들었던 Front Controller 개념이 Spring MVC 내부에서 실제로 사용되고 있었다.

3. localhost:8000 접속과 Whitelabel Error Page

브라우저에서:

http://localhost:8000

으로 접속했더니 다음 화면이 나왔다.

Whitelabel Error Page

status=404
No static resource for request '/'

처음 보면 서버 실행 실패처럼 보일 수 있지만, 실제로는 반대였다.

Spring Boot 실행 성공
        ↓
Tomcat 실행 성공
        ↓
브라우저 요청 도착 성공
        ↓
DispatcherServlet 실행 성공
        ↓
하지만 "/"에 연결된 Controller / Resource 없음
        ↓
404

즉 서버 자체는 정상 동작하고 있었다.

문제 해결 과정 1. 404가 나왔는데 서버가 실패한 걸까?

증상

Whitelabel Error Page
404 Not Found
No static resource for request '/'

확인

서버 로그에서는:

Tomcat started on port 8000
Started DemoApplication
DispatcherServlet initialized

이 모두 정상적으로 출력됐다.

원인

/ 경로에:

Controller Mapping
또는
static/index.html

이 존재하지 않았다.

결론

404
≠ 서버 기동 실패

404
= 요청 경로에 대응하는 자원이 없음

이라는 점을 확인했다.

4. Spring Controller와 Bean 등록

먼저 기본 Controller를 생성했다.

@Controller
public class DemoController {

}

Spring에서는 객체가 필요할 때 직접:

new DemoController();

를 호출하지 않는다.

대신 @Controller 같은 애너테이션을 통해 Spring이 객체를 생성하고 관리한다.

DemoController Class
       ↓
@Controller
       ↓
Component Scan
       ↓
Spring Container
       ↓
Bean 등록

5. Spring에서 사용하는 역할별 Bean

수업에서는 다음 애너테이션들이 함께 등장했다.

@Component
├─ @Controller
├─ @RestController
├─ @Service
└─ @Repository

MyBatis
└─ @Mapper

역할을 정리하면:

Annotation	역할
`@Controller`	MVC 요청 처리 + View 반환
`@RestController`	REST 요청 처리 + Data/JSON 반환
`@Service`	Business Logic
`@Repository`	DB Access
`@Mapper`	MyBatis Mapper Interface

6. @Controller와 @RestController 차이

강사님이 특히 강조한 부분이었다.

@Controller
→ 액션 수행
→ Page / View 반환

@RestController
→ 액션 수행
→ Data / JSON 반환

즉:

Browser + JSP
→ @Controller

React / API Client
→ @RestController

처럼 생각하면 이해하기 쉬웠다.

7. Endpoint와 Controller Method 연결

Spring MVC에서는 사용자의 endpoint가 Controller의 action method와 연결된다.

User Endpoint
     ↓
Controller
     ↓
Action(Method)

이를 위해:

@RequestMapping
@GetMapping
@PostMapping
...

등을 사용한다.

8. @RequestMapping + @GetMapping

@Controller
@RequestMapping("/demo")
public class DemoController {

    @GetMapping("/index")
    public String getMethodName() {
        return "index";
    }
}

최종 요청 주소는:

/demo + /index
=
/demo/index

이다.

GET /demo/index
      ↓
DemoController
      ↓
getMethodName()

으로 연결된다.

9. Query Parameter를 @RequestParam으로 받기

메서드에서:

@GetMapping("/index")
public String getMethodName(
        @RequestParam String param
) {
    ...
}

처럼 선언하면 다음 요청의 값을 받을 수 있다.

/demo/index?param=hello

param
→ "hello"

즉:

Query String
      ↓
@RequestParam
      ↓
Java Method Parameter

로 바인딩된다.

10. JSP View Rendering

@Controller에서는 JSP 페이지를 반환하는 흐름을 실습했다.

프로젝트에 다음 경로를 생성했다.

src
└─ main
   └─ webapp
      └─ WEB-INF
         └─ view
            └─ index.jsp

11. JSP 관련 Dependency 추가

Spring Boot에서 JSP를 사용하기 위해 관련 라이브러리를 추가했다.

providedRuntime 'org.apache.tomcat.embed:tomcat-embed-jasper'

implementation 'jakarta.servlet.jsp.jstl:jakarta.servlet.jsp.jstl-api'
implementation 'org.glassfish.web:jakarta.servlet.jsp.jstl'

역할:

tomcat-embed-jasper
→ JSP 컴파일 / 렌더링

JSTL API
→ JSP 표준 태그 API

JSTL 구현체
→ 실제 JSTL 동작

12. ViewResolver 설정

application-dev.yml에 View 경로를 설정했다.

server:
  port: 8000

spring:
  mvc:
    view:
      prefix: /WEB-INF/view/
      suffix: .jsp

  config:
    activate:
      on-profile: dev

이제 Controller에서:

return "index";

라고 반환하면:

prefix
/WEB-INF/view/

+
index

+
.jsp

=
/WEB-INF/view/index.jsp

가 된다.

13. Controller → JSP 전체 흐름

Browser
   ↓
GET /demo/index
   ↓
DispatcherServlet
   ↓
DemoController
   ↓
@GetMapping("/index")
   ↓
return "index"
   ↓
ViewResolver
   ↓
/WEB-INF/view/index.jsp
   ↓
HTML Rendering
   ↓
Browser Response

터미널에:

debug >>>> user endPoint : /index

로그도 출력되어 실제 Controller 메서드가 호출됐음을 확인했다.

14. @RestController 생성

REST API를 위한 별도 Controller도 만들었다.

@RestController
@RequestMapping("/rest")
public class ReactController {

}

@RestController는 JSP View가 아니라 데이터를 반환한다.

15. DTO를 JSON으로 반환

@GetMapping("/index")
public MessageDTO getMethodName() {

    return MessageDTO.builder()
            .message("테스트")
            .build();
}

Controller가 Java DTO를 반환하면 Spring이 이를 JSON으로 변환한다.

MessageDTO
      ↓
Spring Message Converter
      ↓
JSON

논리적인 응답:

{
  "message": "테스트"
}

16. ResponseEntity

DTO 직접 반환에서 한 단계 더 나아가 ResponseEntity를 사용했다.

@GetMapping("/index")
public ResponseEntity<?> getMethodName() {

    return ResponseEntity
            .status(HttpStatus.OK)
            .body(
                MessageDTO.builder()
                        .message("테스트")
                        .build()
            );
}

ResponseEntity를 사용하면 HTTP Response를 직접 제어할 수 있다.

HTTP Response
├─ Status
├─ Header
└─ Body

17. Status + Header + Body 구성

이후 다음 형태까지 확장했다.

return ResponseEntity
        .status(HttpStatus.CREATED)
        .header("access-token", "12345")
        .body(
            MessageDTO.builder()
                    .message("테스트")
                    .build()
        );

응답 구조:

Status
→ 201 Created

Header
→ access-token: 12345

Body
→ {
     "message": "테스트"
   }

18. ResponseEntity를 사용하는 이유

DTO를 직접 반환하면 Spring이 기본 응답을 만들어준다.

DTO
→ 기본적으로 200 OK
→ JSON

반면 ResponseEntity는:

Status
Header
Body

를 모두 직접 설정할 수 있다.

즉 REST API의 응답 명세를 좀 더 명확하게 표현할 수 있다.

19. 기능 중심 Package 구조

새 프로젝트에서는 기능 단위 패키지 구조도 확인했다.

features
├─ blogs
├─ test
└─ users
   ├─ ctrl
   ├─ domain
   │  └─ dto
   ├─ repository
   └─ service

기존처럼:

controller
service
repository

를 프로젝트 전체에 하나씩 만드는 것이 아니라:

users
blogs
orders
...

처럼 기능별로 먼저 분리한 뒤 내부에서 계층을 나누는 방식이다.

20. User 기능의 계층

users
├─ ctrl
│  → UserController
│
├─ domain
│  └─ dto
│     → UserRequestDTO
│     → UserResponseDTO
│
├─ service
│  → UserService
│  → UserPlainServiceImpl
│  → UserEncryptionServiceImpl
│
└─ repository
   → UserMapper

요청 흐름은:

Client
  ↓
Controller
  ↓
Service
  ↓
Repository / Mapper
  ↓
DB

가 된다.

21. IoC - Inversion of Control

Spring Framework 핵심 개념으로 IoC를 학습했다.

일반 Java에서는:

UserService service = new UserService();

처럼 객체의 생성 책임이 개발자에게 있다.

Spring에서는:

객체 생성
객체 보관
객체 연결
객체 생명주기

를 Spring Container가 관리한다.

Developer
   ↓
Class 작성

Spring Container
   ↓
Object 생성
   ↓
Bean 관리

제어권이 개발자에서 Framework로 넘어갔기 때문에 제어의 역전(IoC) 이라고 한다.

22. Spring Bean

Bean은 Spring Container가 생성하고 관리하는 객체이다.

@Controller
@Service
@Repository
@Component
@Mapper

등으로 등록된 객체들이 Bean이 된다.

Spring Container
├─ UserController Bean
├─ UserService Bean
├─ UserMapper Bean
└─ ...

23. Dependency Injection

Bean끼리 필요한 관계를 연결하는 것이 DI이다.

Controller
   ↓ 필요
Service
   ↓ 필요
Repository

Spring이 필요한 객체를 주입해준다.

24. Dependency Lookup

DI와 함께 Dependency Lookup도 배웠다.

Dependency Injection
→ Spring이 알아서 객체를 넣어줌

Dependency Lookup
→ 직접 Container에서 Bean 조회
→ getBean()

예:

applicationContext.getBean(UserService.class);

25. DI 관련 방식

강의에서는 다음 방식들이 나왔다.

@RequiredArgsConstructor + final
@Autowired
@Inject
@Resource
@Qualifier

26. 생성자 주입

@RequiredArgsConstructor
public class UserService {

    private final UserMapper userMapper;
}

final 필드에 대해 Lombok이 생성자를 만들어주고, Spring이 해당 생성자를 이용해 Bean을 주입한다.

final Field
      ↓
@RequiredArgsConstructor
      ↓
Constructor 생성
      ↓
Spring DI

27. @Autowired를 이용한 Bean 주입

테스트 코드에서:

@Autowired
private UserMapper userMapper;

를 사용했다.

UserMapper 타입 Bean 탐색
       ↓
Spring Container
       ↓
주입

28. MyBatis Mapper Interface

@Mapper
public interface UserMapper {

    public int save(UserRequestDTO request);
}

@Mapper를 붙이면 MyBatis가 해당 Interface의 구현 객체를 만들어 Spring Bean으로 등록한다.

UserMapper Interface
       ↓
@Mapper
       ↓
MyBatis Proxy 생성
       ↓
Spring Bean

29. 회원 테이블 생성

MariaDB에 다음 테이블을 생성했다.

CREATE TABLE SPRING_USER_TBL (
    EMAIL    VARCHAR(50) PRIMARY KEY,
    PASSWORD VARCHAR(50) NOT NULL,
    NAME     VARCHAR(50) NOT NULL
);

30. MyBatis XML Mapper

src/main/resources/mappers/userMapper.xml을 만들었다.

<mapper namespace="com.example.testcase.features.users.repository.UserMapper">

    <insert id="save"
            parameterType="com.example.testcase.features.users.domain.dto.UserRequestDTO">

        INSERT INTO SPRING_USER_TBL(
            EMAIL,
            PASSWORD,
            NAME
        )
        VALUES(
            #{email},
            #{password},
            #{name}
        )

    </insert>

</mapper>

31. Mapper Interface와 XML 연결

연결 규칙이 매우 중요했다.

Java Interface 전체 경로
      ↕
XML namespace

Java Method
save(...)
      ↕
XML id="save"

즉:

UserMapper.save()
        ↓
userMapper.xml
        ↓
<insert id="save">

가 된다.

32. parameterType

INSERT에서는:

parameterType="...UserRequestDTO"

를 사용했다.

의미:

UserRequestDTO
      ↓
SQL에 전달할 Parameter Object

이다.

33. #{property} Parameter Binding

VALUES(
    #{email},
    #{password},
    #{name}
)

수업에서는 이 값이 DTO getter와 연결된다고 설명했다.

#{email}
→ getEmail()

#{password}
→ getPassword()

#{name}
→ getName()

즉 JDBC에서 직접:

pstmt.setString(...)

을 하던 작업을 MyBatis가 대신 처리한다.

34. Spring DataSource 설정

application-dev.yml에 DB 설정을 추가했다.

spring:
  config:
    activate:
      on-profile: dev

  datasource:
    driver-class-name: org.mariadb.jdbc.Driver
    url: jdbc:mariadb://localhost:3306/lgcns
    username: root
    password: ********

Spring Boot
   ↓
DataSource
   ↓
MariaDB

로 연결된다.

35. MyBatis Mapper XML 경로 설정

mybatis:
  mapper-locations: classpath:/mappers/**/*Mapper.xml

이 설정으로:

resources/mappers
        ↓
하위 디렉터리 탐색
        ↓
*Mapper.xml 로딩

하도록 설정했다.

36. @SpringBootTest

MyBatis 기능을 실제 Spring Context에서 테스트했다.

@SpringBootTest
public class UserApplicationTests {

}

@SpringBootTest는 Spring Application Context를 실제로 실행한 상태에서 테스트할 수 있게 한다.

37. TDD - Given / When / Then

테스트 코드는 다음 구조로 작성했다.

Given
→ 데이터 준비

When
→ 기능 실행

Then
→ 결과 검증

38. signUp 테스트

@Test
public void signUp() {

    // given
    UserRequestDTO request =
        UserRequestDTO.builder()
            .email("jslim9413@naver.com")
            .password("1234")
            .name("임섭춘")
            .build();

    // when
    int flag = userMapper.save(request);

    // then
    System.out.println("result : " + flag);
}

문제 해결 과정 2. MyBatis Invalid bound statement

테스트를 처음 실행했을 때:

org.apache.ibatis.binding.BindingException

Invalid bound statement (not found: ...)

오류가 발생했다.

증상

userMapper.save(request);

를 실행했지만 MyBatis가 SQL을 찾지 못했다.

원인 분석

다음 연결을 확인해야 했다.

UserMapper
↕
namespace

save()
↕
id="save"

Mapper XML 위치
↕
mapper-locations

Interface Bean 자체는 생성됐지만 XML Statement가 등록되지 않은 상태였다.

해결

application-dev.yml에 Mapper XML 위치를 명시했다.

mybatis:
  mapper-locations: classpath:/mappers/**/*Mapper.xml

검증

테스트를 다시 실행하자:

result : 1

이 출력됐다.

즉:

INSERT 성공
→ 영향받은 Row 1

을 확인했다.

39. Assertion으로 테스트 자동 검증

처음에는:

System.out.println("result : " + flag);

처럼 사람이 결과를 확인했다.

이후:

Assertions.assertEquals(1, flag);

를 추가했다.

expected = 1
actual   = flag

값이 같으면 테스트 성공, 다르면 실패한다.

40. 출력 확인에서 자동 검증으로

Before

System.out.println()
→ 사람이 결과 확인


After

Assertions.assertEquals()
→ 테스트 코드가 자동으로 성공/실패 판단

이 차이를 확인하면서 테스트의 목적을 좀 더 명확하게 이해할 수 있었다.

41. findByAll()

회원 전체 조회 기능도 추가했다.

public List<UserResponseDTO> findByAll();

XML:

<select id="findByAll"
        resultType="com.example.testcase.features.users.domain.dto.UserResponseDTO">

    SELECT
        EMAIL,
        PASSWORD,
        NAME
    FROM
        SPRING_USER_TBL

</select>

42. parameterType vs resultType

오늘 MyBatis에서 중요한 차이였다.

parameterType
→ Java → SQL
→ SQL에 넣어줄 객체 타입

resultType
→ SQL → Java
→ SELECT 결과를 만들 객체 타입

예:

INSERT
UserRequestDTO
→ parameterType

SELECT
UserResponseDTO
→ resultType

43. ResultSet 매핑도 MyBatis가 처리

이전 JDBC에서는:

while(rset.next()) {
    ...
}

를 직접 작성했다.

MyBatis에서는:

resultType="UserResponseDTO"

만 지정하면 SELECT 결과를 DTO로 매핑한다.

JDBC

ResultSet
→ getString()
→ DTO Builder
→ List


MyBatis

SELECT
→ resultType
→ DTO/List 자동 매핑

44. Login Mapper 추가

로그인 기능도 추가하기 시작했다.

<select id="login"
        parameterType="..."
        resultType="...">

    SELECT
        EMAIL,
        PASSWORD,
        NAME
    FROM
        SPRING_USER_TBL
    WHERE
        EMAIL = #{email}
        AND PASSWORD = #{password}

</select>

흐름:

email
password
   ↓
UserRequestDTO
   ↓
UserMapper.login()
   ↓
MyBatis
   ↓
SPRING_USER_TBL
   ↓
UserResponseDTO

45. 로그인 테스트 골격

@Test
public void singIn() {
    System.out.println("debug >>>> 사용자 로그인 검증");
}

현재는 테스트 메서드의 시작 단계까지 작성했다.

46. Service Interface와 여러 구현체

Service 계층에서는 하나의 인터페이스에 여러 구현체가 등장했다.

UserService
├─ UserPlainServiceImpl
└─ UserEncryptionServiceImpl

Java에서 배운 인터페이스와 다형성이 Spring Service 구조에 그대로 적용됐다.

47. UserEncryptionServiceImpl

public class UserEncryptionServiceImpl implements UserService {

    @Override
    public UserResponseDTO signIn(UserRequestDTO request) {

        System.out.println(
            "debug >>>> user encryption service signIn"
        );

        System.out.println(
            "debug >>>> params : " + request
        );

        return null;
    }
}

현재 화면에서는 실제 암호화 기능을 구현하기 전의 골격 단계였다.

48. UserController 로그인 Endpoint

@RestController
@RequestMapping("/users")
public class UserController {

    @GetMapping("/signIn")
    public ResponseEntity<?> signIn(
            UserRequestDTO request
    ) {

        System.out.println(
            "debug >>>> user controller signIn get mapping"
        );

        System.out.println(
            "debug >>>> params " + request
        );

        return null;
    }
}

endpoint는:

GET /users/signIn

이다.

49. Query Parameter → DTO 자동 바인딩

요청 예:

/users/signIn
?email=jslim9413@gmail.com
&password=1234

Controller에서는:

signIn(UserRequestDTO request)

만 선언했다.

Spring이 Query Parameter를 DTO 필드에 자동으로 바인딩한다.

실제 로그:

UserRequestDTO(
    email=jslim9413@gmail.com,
    password=1234,
    name=null
)

를 확인했다.

50. Controller → Service DI

처음에는:

@Autowired
private UserService userService;

로 타입 기반 DI를 시도했다.

하지만 현재 UserService 구현체는:

UserPlainServiceImpl
UserEncryptionServiceImpl

두 개가 존재한다.

UserService Bean 필요
      ↓
후보 2개
      ↓
어느 Bean을 주입할까?

라는 문제가 생길 수 있다.

51. @Resource(name = "plain")

이 문제를 Bean 이름을 지정하는 방식으로 해결했다.

@Resource(name = "plain")
private UserService userService;

이제 Spring은 "plain"이라는 이름의 Bean을 찾아 주입한다.

UserService
      ↓
@Resource(name="plain")
      ↓
plain Bean
      ↓
UserPlainServiceImpl

52. 실제 Bean 주입 검증

Controller에서:

System.out.println(
    "debug >>>> user controller signIn service binding "
    + userService
);

를 출력했다.

실행 로그에서:

UserPlainServiceImpl@...

이 출력됐다.

즉:

@Resource(name="plain")
        ↓
UserPlainServiceImpl Bean
        ↓
실제 주입 성공

을 확인했다.

53. Bean + DI + 계층 구조 연결

오늘 배운 내용을 전체적으로 합치면 다음과 같다.

Spring Container
      ↓
Bean 생성

UserController
      ↓ DI
UserService
      ↓
UserPlainServiceImpl
      ↓
UserMapper
      ↓
MyBatis XML
      ↓
MariaDB

개발자가 각 객체를 직접 new로 생성하지 않고 Spring이 객체 생성과 연결을 담당한다.

오늘 전체 요청 흐름

오늘 구현한 구조를 하나로 연결하면:

React / Browser
        ↓
HTTP Request

/users/signIn
?email=...
&password=...
        ↓
Embedded Tomcat
        ↓
DispatcherServlet
        ↓
UserController Bean
        ↓
UserRequestDTO Binding
        ↓
UserService Bean
        ↓
UserPlainServiceImpl
        ↓
UserMapper
        ↓
MyBatis Mapper XML
        ↓
MariaDB
        ↓
UserResponseDTO
        ↓
ResponseEntity
        ↓
Status + Header + JSON Body
        ↓
Client

오늘의 문제 해결 과정

1. localhost:8000에서 404 발생

증상

Whitelabel Error Page
404

확인

Tomcat과 DispatcherServlet은 정상적으로 동작했다.

원인

/ endpoint가 구현되지 않았다.

배운 점

404
→ Server Down이 아니라
→ Resource Not Found일 수 있음

2. MyBatis BindingException

증상

Invalid bound statement

원인

Mapper Interface는 Bean으로 등록됐지만 MyBatis가 대응되는 XML Statement를 로딩하지 못했다.

확인한 부분

namespace
id
Mapper XML 경로
mapper-locations

해결

mybatis:
  mapper-locations: classpath:/mappers/**/*Mapper.xml

설정을 추가했다.

검증

result : 1

이 출력되면서 INSERT가 정상 동작했다.

3. 같은 Service Interface 구현체가 여러 개인 문제

상황

UserService
├─ UserPlainServiceImpl
└─ UserEncryptionServiceImpl

문제

타입만으로 DI하면 어떤 Bean을 사용할지 결정하기 어렵다.

해결

@Resource(name = "plain")
private UserService userService;

검증

UserPlainServiceImpl@...

로그를 통해 실제 Bean을 확인했다.

✨ 오늘 배운 점

오늘은 Spring Boot에서 하나의 요청이 어떤 과정을 거쳐 처리되는지 실제 코드로 연결하기 시작했다.

처음에는:

Controller
Service
Repository

라는 단어가 단순한 폴더 구조처럼 느껴졌는데, 오늘 수업을 통해 각 객체가 Spring Bean으로 등록되고 DI를 통해 실제로 연결되는 구조라는 점이 보이기 시작했다.

특히:

@RestController
→ 요청 진입점

Service
→ Business Logic

Mapper
→ SQL 연결

MyBatis XML
→ 실제 SQL

MariaDB
→ 데이터 저장

로 역할이 분리되는 흐름이 인상적이었다.

오늘의 회고

오늘 수업에서 가장 중요했던 개념은 Spring이 객체를 대신 관리한다는 것이었다.

Java에서는 객체가 필요하면:

new Object();

로 직접 생성하는 것이 익숙했다.

하지만 Spring에서는:

Class
→ Annotation
→ Bean
→ Spring Container
→ DI

라는 구조가 중심이었다.

이 때문에 Controller가 Service 구현체를 직접 생성하지 않고:

private UserService userService;

처럼 인터페이스에 의존할 수 있었다.

그리고 구현체를:

Plain
Encryption

처럼 교체할 수도 있었다.

즉 이전에 Java OOP에서 배웠던:

Interface
Polymorphism
Loose Coupling

이 Spring DI 구조에서 실제로 사용되고 있었다.

JDBC와 MyBatis 연결

이전 수업에서 JDBC를 직접 구현했을 때는:

Connection
PreparedStatement
executeQuery
ResultSet
DTO Mapping
close

를 전부 직접 작성했다.

오늘 MyBatis에서는:

Mapper Interface
+
Mapper XML
+
parameterType
+
resultType

으로 많은 반복 코드가 줄어들었다.

특히:

JDBC
pstmt.setString()

↓

MyBatis
#{email}

그리고:

JDBC
ResultSet → DTO 직접 변환

↓

MyBatis
resultType → DTO 자동 매핑

으로 연결해서 보니 MyBatis를 사용하는 이유가 이해되기 시작했다.

다음 학습 방향

오늘은 Controller → Service → Mapper 구조를 만들기 시작했고 로그인 흐름의 골격까지 만들었다.

다음 학습에서는 다음 부분을 집중해서 확인해야겠다.

1. UserController에서 Service Method 실제 호출

2. UserService Interface와
   Plain / Encryption 구현체 차이

3. Service에서 UserMapper 호출

4. login Mapper 실제 결과 반환

5. UserResponseDTO 구성

6. ResponseEntity를 이용한
   Login 성공 / 실패 응답 처리

7. @Resource / @Qualifier / @Primary 차이

8. Controller Parameter Binding
   @RequestParam
   @PathVariable
   DTO

그리고 오늘 수업 목표에 있었던 Swagger/OpenAPI:

@Tag
@Operation
@Parameter
@ApiResponse

도 이후 Controller API와 연결해서 학습하게 될 것으로 보인다.

[LG CNS 6기] 24일차 TIL : DML 실습·쇼핑몰 DB·JDBC·Spring Boot 시작

bbbicsan — Mon, 31 Aug 2026 18:21:58 +0900

[LG CNS 6기] 24일차 TIL : DML 실습·쇼핑몰 DB·JDBC·Spring Boot 시작

한 줄 요약
DML 문제와 쇼핑몰 ERD 기반 종합 SQL 실습을 통해 INSERT / UPDATE / DELETE / JOIN / Subquery를 복습하고, Java JDBC로 MariaDB의 조회·DTO 매핑까지 직접 구현한 뒤 Spring Initializr를 이용해 Spring Boot + Spring MVC 백엔드 개발 환경으로 넘어갔다.

오늘 학습한 커리큘럼

DML Workshop Q1 ~ Q8
        ↓
INSERT / UPDATE / DELETE
        ↓
CREATE TABLE ... SELECT
        ↓
UPDATE + JOIN
UPDATE + Subquery
        ↓
쇼핑몰 ERD DDL/DML 실습
        ↓
customers
orders
products
orderdetail
        ↓
주문 INSERT
주문상세 INSERT
재고 UPDATE
        ↓
4개 테이블 JOIN
        ↓
GROUP BY + SUM
일별 매출 집계
        ↓
Java JDBC
        ↓
MariaDB JDBC Driver
Connection
PreparedStatement
ResultSet
DTO Mapping
        ↓
JDBC UPDATE 준비
PreparedStatement ?
RequestDTO
        ↓
Spring Boot & Spring MVC
        ↓
Spring Initializr
        ↓
Gradle / Java 17
Spring Web MVC
JPA
MyBatis
MariaDB
Lombok
        ↓
Spring Boot 프로젝트 구조
        ↓
application.yml
dev / prod Profile
        ↓
@SpringBootApplication
SpringApplication.run()
        ↓
Embedded Tomcat
        ↓
Controller
Service
Repository

오늘의 학습 키워드

DML
INSERTUPDATEDELETE
CREATE TABLE ... SELECT
Subquery
JOIN UPDATE
ERD
PK / FK
Composite Primary Key
GROUP BY
SUM
JDBC
MariaDB Driver
Connection
PreparedStatement
ResultSet
DTO
Builder Pattern
Spring Boot
Spring MVC
Spring Initializr
Gradle
Spring Data JPA
MyBatis
MariaDB Driver
Lombok
application.yml
Spring Profile
Embedded Tomcat
Controller / Service / Repository

1. DML 실습 Q1 ~ Q8

오늘 첫 수업은 이전에 배운 DML을 실제 문제로 다시 구현하는 것으로 시작했다.

INSERT
→ 새로운 데이터 추가

UPDATE
→ 기존 데이터 수정

DELETE
→ 기존 데이터 삭제

단순 문법 문제뿐 아니라 Subquery, JOIN, 문자열 함수 등을 함께 사용하는 문제들이 포함됐다.

2. Q1 - TB_CLASS_TYPE 데이터 입력

먼저 TB_CLASS_TYPE에 여러 행을 한 번에 INSERT했다.

INSERT INTO TB_CLASS_TYPE
VALUES
('01', '전공필수'),
('02', '전공선택'),
('03', '교양필수'),
('04', '교양선택'),
('05', '논문지도');

한 번의 INSERT 문으로 여러 Row를 저장할 수 있다.

INSERT INTO
      ↓
VALUES (...),
       (...),
       (...)
      ↓
다중행 INSERT

문제 해결 1 - Table doesn't exist

처음 실행 과정에서는 다음 오류가 발생했다.

SQL 오류 (1146)

Table 'lgcns.tb_calls_type' doesn't exist

증상

INSERT 대상 테이블을 찾지 못했다.

원인

실제 테이블은:

TB_CLASS_TYPE

인데 잘못된 테이블명이 사용된 것이 원인이었다.

해결

실제 존재하는 테이블명을 확인한 후:

INSERT INTO TB_CLASS_TYPE ...

로 수정했다.

배운 점

SQL 오류가 발생하면 가장 먼저:

Database 선택
Table 이름
Column 이름
Alias

부터 확인하는 습관이 필요하다.

3. Q2 - 기존 데이터를 이용해 새로운 테이블 생성

tb_student의 데이터를 이용해 새로운 학생 일반정보 테이블을 만들었다.

CREATE TABLE TB_학생일반정보
SELECT S.STUDENT_NO      AS '학번',
       S.STUDENT_NAME    AS '학생이름',
       S.STUDENT_ADDRESS AS '주소'
FROM tb_student S;

이 방식은:

CREATE TABLE
+
SELECT

를 결합한다.

즉:

기존 테이블 SELECT
        ↓
조회 결과 구조 생성
        ↓
새로운 TABLE 생성
        ↓
조회 데이터까지 함께 저장

하는 방식이다.

실행 후 588행의 데이터가 생성된 것을 확인했다.

문제 해결 2 - Unknown Column

작성 과정에서:

SQL 오류 (1054)
Unknown column 'S.STUDENT_NO' in 'SELECT'

오류도 발생했다.

이처럼 CREATE TABLE ... SELECT에서도 일반 SELECT와 마찬가지로 테이블 별칭과 컬럼이 올바르게 연결되어 있는지 확인해야 한다.

최종적으로:

FROM tb_student S

와:

S.STUDENT_NO
S.STUDENT_NAME
S.STUDENT_ADDRESS

의 관계를 올바르게 맞춰 정상 생성했다.

4. Q3 - JOIN 결과로 새로운 테이블 생성

이번에는 여러 테이블을 JOIN한 결과를 새 테이블로 만드는 실습이었다.

핵심 구조는 다음과 같았다.

CREATE TABLE TB_국어국문학과
SELECT S.STUDENT_NO AS '학번',
       S.STUDENT_NAME AS '학생이름',
       CONCAT('19', SUBSTRING(S.STUDENT_SSN, 1, 2)) AS '출생년도',
       P.PROFESSOR_NAME AS '교수이름'
FROM tb_student S
JOIN tb_department D
  ON S.DEPARTMENT_NO = D.DEPARTMENT_NO
JOIN tb_professor P
  ON S.COACH_PROFESSOR_NO = P.PROFESSOR_NO
WHERE D.DEPARTMENT_NAME = '국어국문학과';

여러 개념이 함께 사용됐다.

학생
+
학과
+
교수
        ↓
JOIN
        ↓
국어국문학과만 WHERE
        ↓
SUBSTRING
        ↓
출생년도 가공
        ↓
새 TABLE 생성

5. Q4 - 학과 정원 10% 증가

모든 학과의 정원을 10% 증가시켰다.

UPDATE tb_department
SET CAPACITY = ROUND(CAPACITY * 1.1);

핵심은 WHERE가 없다는 점이다.

WHERE 없음
→ 특정 행이 아니라 전체 행 UPDATE

따라서 실행 전에는 항상:

SELECT *
FROM tb_department;

처럼 대상 범위를 확인하는 것이 안전하다.

6. Q5 - 특정 학생의 주소 수정

UPDATE tb_student
SET STUDENT_ADDRESS = '서울시 종로구 숭인동 181-21'
WHERE STUDENT_NO = 'A413042';

이번에는 WHERE를 이용해 하나의 학생만 정확하게 지정했다.

UPDATE
→ 무엇을 수정할 것인가?

SET
→ 어떤 값으로 수정할 것인가?

WHERE
→ 누구를 수정할 것인가?

7. Q6 - 전체 학생 주민번호 앞 6자리만 유지

UPDATE tb_student
SET STUDENT_SSN = SUBSTRING(STUDENT_SSN, 1, 6);

SUBSTRING()을 이용해 주민번호의 앞 6자리만 남겼다.

전체 주민번호
      ↓
SUBSTRING(..., 1, 6)
      ↓
생년월일 6자리

이 역시 WHERE가 없기 때문에 전체 학생 데이터가 수정된다.

8. Q7 - 특정 학생의 특정 과목 평점 수정

조건은 여러 테이블에 흩어져 있었다.

학생 이름
→ tb_student

학생 소속 학과
→ tb_department

과목 이름
→ tb_class

평점 / 학기
→ tb_grade

이 문제는 두 가지 방식으로 풀었다.

CASE 01. JOIN UPDATE

UPDATE tb_grade G
JOIN tb_student S
  ON G.STUDENT_NO = S.STUDENT_NO
JOIN tb_department D
  ON S.DEPARTMENT_NO = D.DEPARTMENT_NO
JOIN tb_class C
  ON G.CLASS_NO = C.CLASS_NO
SET G.POINT = 3.5
WHERE S.STUDENT_NAME = '김영훈'
  AND D.DEPARTMENT_NAME = '의학과'
  AND C.CLASS_NAME = '피부생리학'
  AND G.TERM_NO = '200501';

흐름:

성적
→ 학생 JOIN
→ 학과 JOIN
→ 과목 JOIN
        ↓
대상 행 특정
        ↓
POINT = 3.5

CASE 02. Subquery UPDATE

UPDATE tb_grade
SET POINT = 3.5
WHERE STUDENT_NO IN (
    SELECT STUDENT_NO
    FROM TB_STUDENT
    WHERE STUDENT_NAME = '김영훈'
)
AND CLASS_NO = (
    SELECT CLASS_NO
    FROM TB_CLASS
    WHERE CLASS_NAME = '피부생리학'
)
AND TERM_NO = '200501';

같은 문제를:

JOIN으로 대상 탐색
vs
Subquery로 필요한 Key 탐색

두 방식으로 구현할 수 있었다.

9. Q8 - 휴학생의 성적 처리

휴학생의 성적 데이터를 처리하는 문제에서는 두 방법을 비교했다.

방법 1. POINT만 NULL 처리

UPDATE tb_grade
SET POINT = NULL
WHERE STUDENT_NO IN (
    SELECT STUDENT_NO
    FROM tb_student
    WHERE ABSENCE_YN = 'Y'
);

결과:

성적 Row
→ 유지

POINT
→ NULL

방법 2. 성적 Row 삭제

DELETE FROM tb_grade
WHERE STUDENT_NO IN (
    SELECT S.STUDENT_NO
    FROM tb_student S
    WHERE S.ABSENCE_YN = 'Y'
);

결과:

성적 Row 자체
→ 삭제

두 방식의 차이를 명확하게 볼 수 있었다.

방식	결과
`UPDATE POINT = NULL`	행 유지
`DELETE`	행 자체 제거

10. DML에서 WHERE의 중요성

오늘 실습 중 여러 번 확인한 핵심이었다.

UPDATE + WHERE
→ 특정 Row 수정

UPDATE without WHERE
→ 전체 Row 수정

DELETE + WHERE
→ 특정 Row 삭제

DELETE without WHERE
→ 전체 Row 삭제

따라서 실제 데이터 변경 전에는:

SELECT ...
WHERE ...

로 먼저 대상 행을 확인한 후 같은 조건을 UPDATE / DELETE에 적용하는 것이 안전하다.

11. 쇼핑몰 ERD 기반 DDL/DML 종합 실습

이어서 지난 시간 마지막에 문제만 제시됐던 쇼핑몰 ERD 실습을 실제로 구현했다.

구조는 다음과 같다.

CUSTOMERS
   1
   ↓
   N
ORDERS
   1
   ↓
   N
ORDERDETAIL
   N
   ↑
   1
PRODUCTS

ORDERS와 PRODUCTS의 N:M 관계를 ORDERDETAIL이라는 중간 테이블을 통해 해소한다.

12. ORDERDETAIL과 복합 Primary Key

CREATE TABLE orderdetail (
    orderno INT,
    pno INT,
    qty INT DEFAULT 0,
    cost INT DEFAULT 0,

    PRIMARY KEY (orderno, pno),

    FOREIGN KEY (orderno)
        REFERENCES orders(orderno),

    FOREIGN KEY (pno)
        REFERENCES products(pno)
);

핵심은:

PRIMARY KEY (orderno, pno)

이다.

ORDERNO 하나만으로는
→ 어떤 상품인지 식별 불가

PNO 하나만으로는
→ 어떤 주문인지 식별 불가

ORDERNO + PNO
→ 하나의 주문 상세 항목 식별

13. Customers 데이터 입력

INSERT INTO customers(cno, cname, address, email, phone)
VALUES
(101, '김철수', '서울 강남구', 'cskim@naver.com', '899-6666'),
(102, '이영희', '부산 서면', 'yhlee@empal.com', '355-8882'),
(103, '최진국', '제주 동광양', 'jkchoi@gmail.com', '852-5764'),
(104, '강준호', '강릉 홍제동', 'jhkang@hanmail.com', '559-7777'),
(105, '민병국', '대전 전민동', 'bgmin@hotmail.com', '559-8741'),
(106, '오민수', '광주 북구', 'msoh@microsoft.com', '542-9988');

실행 후 6명의 고객 데이터가 정상적으로 저장된 것을 확인했다.

14. 주문 생성 시 고객번호를 Subquery로 조회

김철수의 주문을 입력했다.

INSERT INTO orders(
    orderno,
    orderdate,
    address,
    phone,
    status,
    cno
)
VALUES(
    1,
    DATE_SUB(CURDATE(), INTERVAL 3 DAY),
    '서울 강남구',
    '899-6666',
    '결제완료',
    (
        SELECT CNO
        FROM customers
        WHERE CNAME = '김철수'
    )
);

CNO = 101을 직접 넣지 않고:

김철수
 ↓
Subquery
 ↓
CNO = 101
 ↓
orders INSERT

구조로 구현했다.

15. 상품 재고 차감

김철수가 삼양라면 50개를 주문한 후:

UPDATE products
SET STOCK = STOCK - 50
WHERE PNO = 1001;

로 재고를 차감했다.

결과:

삼양라면
200 → 150

단순히:

SET STOCK = 150

으로 변경하기보다:

SET STOCK = STOCK - 주문수량

형태로 처리했다.

16. 한 주문에 여러 상품 입력

이영희는 한 주문에서:

새우깡 100개
월드콘 150개

를 주문했다.

orders에는 주문 자체가 1건 들어간다.

INSERT INTO orders(
    orderno,
    orderdate,
    address,
    phone,
    status,
    cno
)
VALUES(
    2,
    DATE_SUB(CURDATE(), INTERVAL 2 DAY),
    '부산 수영구',
    '337-5000',
    '결제완료',
    (
        SELECT CNO
        FROM customers
        WHERE CNAME = '이영희'
    )
);

반면 orderdetail에는 상품별로 2건을 입력한다.

INSERT INTO orderdetail(orderno, pno, qty, cost)
VALUES
(
    2,
    (
        SELECT PNO
        FROM products
        WHERE PNAME = '새우깡'
    ),
    100,
    1500
),
(
    2,
    (
        SELECT PNO
        FROM products
        WHERE PNAME = '월드콘'
    ),
    150,
    2000
);

orders
→ 주문 1건

orderdetail
→ 주문 상품 N건

이라는 관계가 실제 SQL에서 확인됐다.

17. JOIN UPDATE를 이용한 재고 차감

새우깡과 월드콘의 주문수량을 orderdetail에서 가져와 재고를 차감했다.

UPDATE products P
JOIN orderdetail D USING(pno)
SET stock = P.stock - D.qty
WHERE pno = (
    SELECT PNO
    FROM products
    WHERE PNAME = '새우깡'
);

월드콘도 같은 방식으로 수행했다.

결과:

새우깡
500 → 400

월드콘
350 → 200

18. 주문 단위로 여러 상품 재고 일괄 차감

오민수의 3번 주문에는:

빼빼로 100개
코카콜라 50개

가 존재했다.

이때는 상품을 각각 UPDATE하지 않고 주문번호를 이용해 한 번에 처리했다.

UPDATE products P
JOIN orderdetail OD
  ON P.pno = OD.pno
SET P.stock = P.stock - OD.qty
WHERE OD.orderno = 3;

결과:

빼빼로
700 → 600

코카콜라
550 → 500

이 방식은 주문 상세정보에 있는 상품 수만큼 재고를 한 번에 변경할 수 있다는 점이 인상적이었다.

19. 전체 주문 목록 조회

전체 주문 정보를 조회하기 위해 4개 테이블을 JOIN했다.

SELECT O.orderdate,
       C.cname,
       O.address,
       O.phone,
       O.status,
       P.pname,
       D.cost,
       D.qty,
       D.cost * D.qty AS 'cost*qty'
FROM orders O
JOIN orderdetail D
  ON O.orderno = D.orderno
JOIN products P
  ON D.pno = P.pno
JOIN customers C
  ON O.cno = C.cno;

관계:

CUSTOMERS
    ↓
ORDERS
    ↓
ORDERDETAIL
    ↓
PRODUCTS

조회 결과:

김철수 | 삼양라면 |  50,000

이영희 | 새우깡   | 150,000
이영희 | 월드콘   | 300,000

오민수 | 빼빼로   | 200,000
오민수 | 코카콜라 |  90,000

20. 일별 매출 집계

전체 주문정보에서 날짜별 매출을 계산했다.

SELECT O.orderdate,
       SUM(D.cost * D.qty) AS 'sum(cost*qty)'
FROM orders O
JOIN orderdetail D
  ON O.orderno = D.orderno
JOIN products P
  ON D.pno = P.pno
JOIN customers C
  ON O.cno = C.cno
GROUP BY O.orderdate;

실행 결과:

2026-08-28 →  50,000
2026-08-29 → 450,000
2026-08-30 → 290,000

예를 들어 8월 29일 매출은:

새우깡
1,500 × 100
= 150,000

월드콘
2,000 × 150
= 300,000

합계
= 450,000

으로 계산된다.

21. 신규 상품 추가

INSERT INTO products
VALUES(
    1007,
    '목캔디',
    3000,
    500
);

실행 후 상품 테이블은 7건이 됐다.

22. 최진국의 목캔디 주문

마지막 주문까지 추가했다.

INSERT INTO orders(
    orderno,
    orderdate,
    address,
    phone,
    status,
    cno
)
VALUES(
    4,
    CURDATE(),
    '제주 동광양',
    '352-4657',
    '결제완료',
    (
        SELECT cno
        FROM customers
        WHERE cname = '최진국'
    )
);

주문 상세:

INSERT INTO orderdetail
VALUES(
    4,
    1007,
    200,
    3000
);

재고 차감:

UPDATE products
SET stock = stock - 200
WHERE pno = 1007;

결과:

목캔디
500 → 300

23. 쇼핑몰 DML 실습의 전체 흐름

이번 실습을 실제 서비스 흐름처럼 정리하면 다음과 같다.

고객 확인
     ↓
orders INSERT
     ↓
orderdetail INSERT
     ↓
products STOCK UPDATE
     ↓
JOIN으로 주문결과 확인
     ↓
GROUP BY로 매출 집계

특히:

주문 생성
주문 상세 생성
재고 차감

은 논리적으로 하나의 작업 단위라는 점도 확인할 수 있었다.

이후 Transaction을 사용할 때 이 작업들을 하나로 묶는 이유와도 연결될 수 있다.

24. Java JDBC

오후에는 SQL에서 Java 애플리케이션으로 넘어가 JDBC를 이용해 MariaDB에 직접 접근했다.

강의에서 정리한 JDBC 절차는 다음과 같다.

1. Driver Loading
2. Connection
3. Statement / PreparedStatement
4. execute
5. ResultSet
6. close

25. JDBC Driver Loading

MariadbDao에서 MariaDB JDBC Driver를 로딩했다.

public MariadbDao() {
    try {
        Class.forName("org.mariadb.jdbc.Driver");
        System.out.println("debug >>>> driver loading ok!!");
    } catch(Exception e) {
        e.printStackTrace();
    }
}

문제 해결 3 - ClassNotFoundException

처음 실행했을 때:

java.lang.ClassNotFoundException:
org.mariadb.jdbc.Driver

오류가 발생했다.

원인

Java 코드에서는:

Class.forName("org.mariadb.jdbc.Driver");

를 호출했지만 프로젝트의 classpath에 MariaDB JDBC Driver가 존재하지 않았다.

해결

MariaDB JDBC Driver 라이브러리를 추가했다.

검증

다시 실행하자:

debug >>>> driver loading ok!!

가 출력됐다.

Driver Class 없음
        ↓
ClassNotFoundException
        ↓
MariaDB JDBC Driver 추가
        ↓
Driver Loading 성공

26. JDBC Connection

DB 연결 정보를 상수로 정의하는 구조를 만들었다.

private static final String DRIVER   = "...";
private static final String USER     = "...";
private static final String PASSWORD = "...";
private static final String URL      = "...";

그리고 실제 Connection을 생성했다.

conn = DriverManager.getConnection(
    URL,
    USER,
    PASSWORD
);

URL
USER
PASSWORD
   ↓
DriverManager
   ↓
Connection

27. DAO에서 부서 목록 조회

departments() 메서드를 구현했다.

public List<DepartmentResponseDTO> departments() {

    Connection conn = null;
    PreparedStatement pstmt = null;
    ResultSet rset = null;

    String sql = """
        select *
        from department
        """;

    List<DepartmentResponseDTO> list = new ArrayList<>();

    ...
}

28. PreparedStatement와 executeQuery()

pstmt = conn.prepareStatement(sql);
rset = pstmt.executeQuery();

역할:

Connection
→ DB 연결

PreparedStatement
→ SQL 준비

executeQuery()
→ SELECT 실행

ResultSet
→ 결과 반환

29. ResultSet → DTO Mapping

while(rset.next()) {
    list.add(
        DepartmentResponseDTO.builder()
            .dept_id(rset.getString(1))
            .dept_name(rset.getString(2))
            .loc_id(rset.getString(3))
            .build()
    );
}

흐름은:

ResultSet Row
      ↓
getString()
      ↓
DepartmentResponseDTO
      ↓
ArrayList

였다.

이전 Java 수업에서 학습한:

DTO
Builder
List
Stream

이 JDBC와 연결되는 것도 확인할 수 있었다.

30. DTO List 출력

JdbcApp에서는 DAO가 반환한 리스트를 출력했다.

MariadbDao dao = new MariadbDao();

List<DepartmentResponseDTO> list = dao.departments();

list.stream()
    .forEach(System.out::println);

터미널에서는 실제 DTO가 출력됐다.

DepartmentResponseDTO(
    dept_id=50,
    dept_name=해외영업1팀,
    loc_id=U1
)

DepartmentResponseDTO(
    dept_id=60,
    dept_name=기술지원팀,
    loc_id=OT
)

DepartmentResponseDTO(
    dept_id=80,
    dept_name=해외영업2팀,
    loc_id=A2
)

DepartmentResponseDTO(
    dept_id=90,
    dept_name=전략기획팀,
    loc_id=A3
)

즉 최종 데이터 흐름은:

MariaDB
   ↓
JDBC SELECT
   ↓
ResultSet
   ↓
DTO
   ↓
List<DTO>
   ↓
Stream
   ↓
Console

로 이어졌다.

31. JDBC DML - UPDATE 준비

SELECT 이후에는 JDBC로 UPDATE를 실행하는 메서드를 만들기 시작했다.

SQL:

String sql = """
    update department
    set dept_name = ?
    where dept_id = ?
    """;

여기서 ?는 실제 값을 나중에 넣기 위한 Placeholder이다.

첫 번째 ?
→ 변경할 DEPT_NAME

두 번째 ?
→ 대상 DEPT_ID

32. Request DTO로 수정값 전달

JdbcApp에서 수정 요청 DTO를 만들었다.

DepartmentRequestDTO request =
    DepartmentRequestDTO.builder()
        .dept_id("90")
        .dept_name("교육팀")
        .build();

int flag = dao.update(request);

System.out.println("result flag : " + flag);

흐름:

RequestDTO
dept_id = 90
dept_name = 교육팀
       ↓
DAO
       ↓
PreparedStatement
       ↓
UPDATE
       ↓
영향받은 행 수 반환

SELECT와 DML 실행 차이도 연결됐다.

SELECT
→ executeQuery()
→ ResultSet

INSERT / UPDATE / DELETE
→ executeUpdate()
→ int

현재 수업 화면에서는 UPDATE 메서드를 기존 SELECT 코드를 기반으로 수정하는 중간 단계까지 확인했다.

33. Spring Boot & Spring MVC 시작

JDBC를 직접 구현한 뒤 수업은 Spring Boot & Spring MVC로 넘어갔다.

프로젝트 생성은:

https://start.spring.io/

또는 VS Code에서:

Ctrl + Shift + P
→ Spring Initializr

로 진행할 수 있었다.

34. Spring Initializr

VS Code Command Palette에서는:

Spring Initializr: Create a Gradle Project...
Spring Initializr: Add Starters...
Spring Initializr: Create a Gradle Project with Kotlin DSL...
Spring Initializr: Create a Maven Project...

등의 기능을 확인했다.

35. Spring Boot Dependency

수업에서 선택한 의존성은 다음과 같다.

Spring Boot DevTools
Spring Configuration Processor
Spring Web
Spring Data JPA
MyBatis Framework
MariaDB Driver
Lombok

각 역할:

Dependency	역할
Spring Boot DevTools	개발 편의 기능
Configuration Processor	설정 프로퍼티 지원
Spring Web MVC	Web / REST / MVC
Spring Data JPA	ORM 기반 DB 접근
MyBatis Framework	SQL Mapper 기반 DB 접근
MariaDB Driver	MariaDB 연결
Lombok	반복 Java 코드 감소

36. build.gradle

생성된 프로젝트는 실제로 다음 환경을 사용했다.

Spring Boot 4.0.8
Java 17
Gradle

주요 설정:

plugins {
    id 'java'
    id 'org.springframework.boot' version '4.0.8'
    id 'io.spring.dependency-management' version '1.1.7'
}

group = 'com.example.demo'
version = '0.0.1-SNAPSHOT'

java {
    toolchain {
        languageVersion = JavaLanguageVersion.of(17)
    }
}

주요 의존성:

implementation 'org.springframework.boot:spring-boot-starter-data-jpa'
implementation 'org.springframework.boot:spring-boot-starter-webmvc'
implementation 'org.mybatis.spring.boot:mybatis-spring-boot-starter:4.0.1'

runtimeOnly 'org.mariadb.jdbc:mariadb-java-client'

compileOnly 'org.projectlombok:lombok'
annotationProcessor 'org.projectlombok:lombok'

developmentOnly 'org.springframework.boot:spring-boot-devtools'

Spring Initializr에서 선택했던 Starter가 실제 build.gradle 의존성으로 들어가는 것을 확인했다.

37. Spring Boot 프로젝트 구조

src
├─ main
│  ├─ java
│  │  └─ Spring Java Code
│  │
│  └─ resources
│     ├─ static
│     ├─ templates
│     ├─ application.yml
│     ├─ application-dev.yml
│     └─ application-prod.yml
│
└─ test

build.gradle
gradlew
gradlew.bat
settings.gradle

각 역할:

src/main/java
→ Spring Application Code

resources/static
→ 정적 리소스
→ HTML / CSS / JS / Image

application.yml
→ Spring 설정

build.gradle
→ Build + Dependency 관리

38. Spring Profile

개발 환경과 운영 환경의 설정을 분리했다.

application.yml
→ 공통 설정

application-dev.yml
→ 개발 환경

application-prod.yml
→ 운영 환경

application.yml에서는:

spring:
  profiles:
    default: dev

로 기본 환경을 dev로 설정했다.

39. application-prod.yml

spring:
  config:
    activate:
      on-profile: prod

의미:

prod Profile 활성화
        ↓
application-prod.yml 적용

즉:

공통 환경설정
+
개발 환경설정
+
운영 환경설정

을 분리할 수 있다.

40. Spring Boot Application 진입점

프로젝트의 시작점은 다음 클래스였다.

@SpringBootApplication
public class DemoApplication {

    public static void main(String[] args) {
        SpringApplication.run(
            DemoApplication.class,
            args
        );
    }
}

흐름:

main()
   ↓
SpringApplication.run()
   ↓
Spring Boot Application Context
   ↓
Bean / Configuration Loading
   ↓
Embedded Tomcat
   ↓
Web Server Start

실제 실행 로그에서도:

Spring Boot (v4.0.8)
Starting DemoApplication

이 출력되며 정상적으로 애플리케이션이 기동되는 것을 확인했다.

41. Embedded Tomcat

Spring Boot의 중요한 특징 중 하나로 내장 Tomcat을 확인했다.

전통적인 방식은:

Application
     ↓
WAR
     ↓
외부 Tomcat / WebLogic
     ↓
Deploy

구조라면 Spring Boot는:

Spring Boot Application
+
Embedded Tomcat
     ↓
Executable JAR
     ↓
직접 실행

구조로 사용할 수 있다.

42. Spring Boot Build와 배포

강의 주석에서:

React
→ npm start

Spring Boot Build
→ ./gradlew bootJar

Build Result
→ xxxx.jar

Deploy
→ JAR 실행
→ Embedded Tomcat Start

흐름을 확인했다.

즉 Gradle의 bootJar를 통해 실행 가능한 Spring Boot JAR를 만들 수 있다.

43. Spring MVC 기본 계층

Spring Boot 프로젝트에서는 앞으로 다음과 같이 역할을 나누는 구조를 사용한다.

Client
React / Browser
       ↓ HTTP
Controller
       ↓
Service
       ↓
Repository
       ↓
Database

각 역할:

Controller
→ HTTP Request / Response

Service
→ Business Logic

Repository
→ Database Access

오늘은 아직 각 계층을 실제 코드로 구현하기보다 Spring Boot 프로젝트의 기본 구조와 역할을 이해하는 단계까지 진행했다.

44. JDBC에서 Spring Boot로 넘어가는 흐름

오늘 수업에서 가장 자연스럽게 연결된 부분이었다.

직접 JDBC에서는:

Driver Loading
Connection
PreparedStatement
executeQuery
ResultSet
DTO Mapping
close

를 모두 개발자가 직접 작성해야 한다.

하지만 Spring Boot 프로젝트에는:

Spring Data JPA
MyBatis
MariaDB Driver

가 추가되어 있다.

앞으로는:

직접 JDBC
        ↓
Spring Repository
        ↓
JPA / MyBatis
        ↓
DB Access 추상화

로 발전하게 된다.

JDBC를 먼저 직접 구현해봤기 때문에 Spring이 어떤 반복 작업을 대신 처리해주는지 더 명확하게 비교할 수 있을 것 같다.

오늘의 문제 해결 과정

1. 잘못된 테이블명으로 INSERT

증상

SQL 오류 1146
Table doesn't exist

원인

실제 테이블 이름과 작성한 테이블 이름이 달랐다.

해결

실제 TB_CLASS_TYPE 테이블명을 확인하여 수정했다.

2. CREATE TABLE SELECT에서 컬럼 오류

증상

Unknown column 'S.STUDENT_NO'

해결 과정

FROM 절 확인
→ Alias 확인
→ SELECT 컬럼 확인
→ CTAS 재실행
→ 588행 생성

3. WHERE가 없는 UPDATE

UPDATE tb_department
SET CAPACITY = ROUND(CAPACITY * 1.1);

UPDATE tb_student
SET STUDENT_SSN = SUBSTRING(STUDENT_SSN, 1, 6);

두 쿼리 모두 WHERE가 없기 때문에 전체 행이 변경된다.

배운 점

UPDATE / DELETE 실행 전
→ 같은 WHERE를 적용한 SELECT로
   대상 Row를 먼저 확인하는 습관이 중요하다.

4. 같은 UPDATE를 JOIN과 Subquery로 구현

특정 성적을 수정하는 문제를:

JOIN UPDATE
vs
Subquery UPDATE

두 방법으로 구현했다.

배운 점

SQL은 같은 결과를 여러 구조로 만들 수 있으며 문제의 관계와 가독성에 따라 적절한 방식을 선택할 수 있다.

5. JDBC Driver ClassNotFoundException

증상

ClassNotFoundException:
org.mariadb.jdbc.Driver

원인

MariaDB JDBC Driver가 Java classpath에 없었다.

해결

JDBC Driver를 추가했다.

검증

debug >>>> driver loading ok!!

출력을 확인했다.

✨ 오늘 배운 점

오늘은 SQL에서 Spring Boot까지 범위가 크게 확장된 날이었다.

오전에는 기존에 배운:

DDL
DML
JOIN
Subquery
GROUP BY

를 실제 쇼핑몰 ERD와 연결해 종합적으로 사용했다.

특히 주문이라는 하나의 기능도 데이터베이스 내부에서는:

orders
orderdetail
products
customers

여러 테이블의 관계로 이루어진다는 점을 실제 INSERT와 UPDATE를 통해 확인할 수 있었다.

이후 Java JDBC에서는 SQL에서 조회한 데이터를 Java 객체로 변환했다.

Database Row
→ ResultSet
→ DTO
→ List
→ Stream

이라는 흐름을 직접 구현하면서 DB 데이터가 Java 애플리케이션으로 들어오는 과정을 이해할 수 있었다.

마지막에는 Spring Boot 프로젝트를 생성하면서 기존 JDBC 방식에서 한 단계 더 높은 수준의 백엔드 개발 환경으로 넘어갔다.

오늘의 회고

오늘 가장 크게 연결된 부분은 DB → JDBC → Spring Boot의 흐름이었다.

처음 SQL만 공부할 때는 DB 내부에서 쿼리가 실행되는 것만 생각했지만 JDBC를 통해:

Java
→ SQL 전달
→ MariaDB
→ ResultSet
→ Java DTO

형태로 실제 애플리케이션과 DB가 어떻게 통신하는지 확인했다.

그리고 JDBC에서는:

Connection
PreparedStatement
ResultSet
Exception Handling
Resource Close

등을 직접 작성해야 한다는 점도 알게 됐다.

이후 Spring Boot 프로젝트에:

JPA
MyBatis
MariaDB Driver

를 추가하는 것을 보면서 앞으로 Spring이 이러한 DB 접근 코드를 어떤 방식으로 추상화할지 연결해서 공부할 수 있을 것 같다.

또 Spring Boot 자체도 단순 라이브러리가 아니라:

Configuration
Profile
Embedded Tomcat
Gradle Build
Executable JAR
MVC Layer

등 백엔드 애플리케이션 실행 전반을 구성한다는 것을 처음 확인했다.

다음 학습 방향

다음 수업에서는 현재 생성한 Spring Boot 프로젝트를 기준으로 실제 Spring MVC 구조를 구현할 가능성이 높다.

복습할 흐름은:

Browser / React
        ↓
HTTP Request
        ↓
Embedded Tomcat
        ↓
Controller
        ↓
Service
        ↓
Repository
        ↓
JPA / MyBatis
        ↓
MariaDB

이다.

특히 다음 개념을 중심으로 이어서 학습해야겠다.

@SpringBootApplication

Controller
Service
Repository

Dependency Injection

application.yml
Profile

Spring Web MVC

Spring Data JPA
MyBatis

MariaDB Connection

JDBC 직접 구현
vs
Spring DB 접근

오늘 직접 만든 JDBC 코드와 앞으로 구현할 Spring Repository 코드를 비교하면서 Spring이 어떤 반복 작업을 대신 처리해주는지 이해하는 것이 다음 학습의 핵심이 될 것 같다.

[FinGuardOps #4] 금융 업무 정합성을 지키는 ERD·PostgreSQL·Flyway 설계

bbbicsan — Mon, 31 Aug 2026 12:17:00 +0900

FinGuardOps Project Series #4

지난 글에서는 거래 처리 상태, 위험 등급, 위험 대응 결과, 사건 진행 상태와 최종 판정, 멱등 처리 상태를 서로 분리해 설계했습니다.

하지만 애플리케이션의 Enum과 Service 검증만으로는 금융 업무 데이터의 정합성을 끝까지 보장하기 어렵습니다. 여러 Pod가 동시에 같은 요청을 처리하거나, 잘못된 SQL과 운영 실수가 애플리케이션 검증을 우회할 수도 있기 때문입니다.

예를 들어 같은 transactionId가 두 번 저장되거나, 하나의 거래에 같은 분석 버전이 중복 생성되거나, 최종 판정이 없는 사건이 CLOSED 상태로 저장된다면 애플리케이션의 상태 모델과 실제 데이터가 서로 다른 이야기를 하게 됩니다.

그래서 FinGuardOps에서는 ERD를 단순한 테이블 목록이 아니라 업무 규칙과 데이터 소유권을 관계형 모델로 표현하는 설계도로 정의했습니다. Spring Boot의 검증과 PostgreSQL의 제약을 중첩하고, Flyway로 배포 중에도 호환 가능한 스키마 확장 경로를 관리하는 것이 핵심입니다.

FinGuardOps에서 PostgreSQL은 단순 저장소가 아니라, 거래·탐지·사건의 관계와 허용 가능한 상태 조합을 보조 검증하는 마지막 정합성 방어선입니다.

거래 접수부터 탐지·사건·감사·AI 운영까지의 데이터 관계를 네 영역으로 분리한 FinGuardOps 핵심 도메인 ERD

이번 글은 특정 날짜의 테이블 구현 현황을 나열하는 글이 아니라, 상태 모델을 PostgreSQL에 어떻게 옮기고 Cloud Native 배포 환경에서 스키마를 어떻게 안전하게 확장할 것인지 설명합니다.

상태 모델을 데이터베이스로 옮길 때의 설계 질문
FinGuardOps의 데이터 모델링 원칙
️ 전체 도메인 ERD와 데이터 영역
거래·행동 이벤트·멱등성 모델
탐지 결과·Evidence·RuleVersion 모델
️ 사건·조사 메모·감사 로그 모델
AI 리포트·실행·Provider 사용량 모델
️ PostgreSQL을 정합성 방어선으로 사용한 방법
⚡ 조회 패턴을 기준으로 설계한 Index
동시성·잠금·버전 관리
Flyway와 Rolling Update를 고려한 스키마 확장
☁️ Cloud Native 환경의 DB 운영·검증 기준
마치며: 데이터 모델 위에 API 계약을 올리기

1. 상태 모델을 데이터베이스로 옮길 때의 설계 질문

상태 전이 규칙을 Java 코드에 정의했다고 해서 실제 데이터베이스의 모든 쓰기 경로가 그 규칙을 자동으로 따르는 것은 아닙니다.

JPA가 아닌 직접 SQL, 배치 작업, 운영 복구 도구 또는 경쟁 요청이 애플리케이션이 예상하지 못한 데이터 조합을 만들 가능성도 고려해야 합니다.

❓ 중복 식별자

같은 transactionId, eventId 또는 동일한 멱등 Key가 동시에 저장되는 것을 어디에서 막을 것인가?

❓ 잘못된 상태 조합

CLOSED 사건에 최종 판정이 없거나, 완료된 탐지 결과에 점수와 등급이 없는 상태를 어떻게 거부할 것인가?

❓ 잘못된 관계

다른 거래의 탐지 결과를 현재 거래가 채택하거나, 존재하지 않는 거래에 행동 이벤트가 연결되는 것을 어떻게 막을 것인가?

❓ 과거 근거의 변경

게시된 Rule 조건과 과거 Evidence가 이후 정책 변경으로 이력 없이 바뀌지 않도록 어떻게 보존할 것인가?

❓ 동시 요청

여러 Pod가 같은 거래의 다음 분석 버전 또는 사건을 동시에 만들 때 단 하나의 결과만 확정하려면 무엇이 필요한가?

❓ 배포 중 스키마 변경

구버전 Pod와 신버전 Pod가 함께 실행되는 동안에도 하나의 PostgreSQL Schema를 안전하게 사용할 수 있는가?

FinGuardOps는 이 질문을 애플리케이션 코드 한 곳에만 맡기지 않습니다. API 검증, 도메인 검증, JPA 불변식과 PostgreSQL 제약을 계층별로 배치합니다.


    API Validation
    → Domain Validation
    → JPA 불변식·동시성 제어
    → PostgreSQL Constraint·Trigger

2. FinGuardOps의 데이터 모델링 원칙

테이블을 나누는 기준은 기술적인 편의보다 각 데이터가 대답해야 하는 업무 질문과 변경 이유입니다.

1. 상태와 결과 분리

거래 처리 단계, 위험 등급과 위험 대응 결과를 서로 다른 속성으로 관리하고, 사건 진행 상태와 최종 판정도 분리합니다.

2. 현재값과 이력 분리

목록 조회에 필요한 현재값은 주요 Entity에 유지하고, 분석 버전과 주요 변경 이력은 별도 행으로 누적합니다.

3. 내부 PK와 업무 ID 분리

관계와 Join에는 BIGINT Identity를 사용하고, API·로그·Trace에는 UUID v4 업무 식별자를 사용합니다.

4. 불변 버전 보존

과거 분석에 사용한 Rule·Feature·모델 조건을 덮어쓰지 않고, 변경된 실행 정의는 새로운 버전으로 추가합니다.

5. 업무 원본과 보조 데이터 분리

PostgreSQL을 업무 원본으로 사용하고, Redis 캐시와 Observability 데이터가 원본을 대신하지 않도록 합니다.

6. 민감정보 최소화

실제 고객·계좌·기기·IP 원문을 반복 저장하지 않고, 연결용 참조값과 제한된 탐지 요약만 보존합니다.

내부 PK와 외부 업무 식별자를 나눈 이유

financial_transaction.id
→ DB 내부 관계용 BIGINT

financial_transaction.transaction_id
→ API·로그·추적용 UUID v4

fraud_case.id
→ DB 내부 관계용 BIGINT

fraud_case.case_id
→ 화면·API·감사용 UUID v4

내부 PK를 API에 노출하지 않으면 데이터베이스 구현을 바꾸더라도 외부 계약의 업무 식별자를 안정적으로 유지할 수 있습니다. 동시에 관계형 Join에서는 compact한 내부 키를 사용할 수 있습니다.

️ 3. 전체 도메인 ERD와 데이터 영역

FinGuardOps의 핵심 데이터는 네 개의 업무 영역으로 나눌 수 있습니다.

거래·행동·멱등성

Transaction
BehaviorEvent
IdempotencyRecord

탐지·정책

DetectionResult
DetectionEvidence
FraudRule
RuleVersion

️ 사건·감사

FraudCase
CaseTransaction
CaseNote
AuditLog

AI 운영

AiReportRequest
AiReportExecution
ProviderCallAttempt
AiReport

핵심 Cardinality

Transaction 1 : N DetectionResult
DetectionResult 1 : N DetectionEvidence
FraudRule 1 : N RuleVersion
FraudCase N : M Transaction
FraudCase 1 : N CaseNote
FraudCase 1 : N AiReportRequest
AiReportExecution 1 : N ProviderCallAttempt
AiReportExecution 1 : 0..1 AiReport

외부 위험정보 조회 결과는 모든 원문을 별도 Entity로 영속화하는 대신, 분석 요청을 구성하는 동안 필요한 최소 Snapshot으로 취급합니다. 저장 필요성과 감사 정책이 확정되기 전에는 업무 원본 테이블을 무분별하게 늘리지 않습니다.

FastAPI와 LLM Provider가 반환한 값 자체는 FinGuardOps의 업무 원본이 아닙니다. Spring Boot가 요청·버전·정합성을 검증하고 PostgreSQL에 연결해 저장한 결과만 감사 가능한 업무 기록으로 취급합니다.

4. 거래·행동 이벤트·멱등성 모델

4.1 Transaction — 거래의 현재 업무 상태

Transaction은 FinGuardOps가 접수한 금융 거래의 식별 정보와 현재 처리 상태, 채택한 탐지 결과와 적용된 대응 결과를 소유합니다.

주요 속성

transactionId
transactionType
amount
currencyCode
occurredAt
externalCustomerRef
senderAccountRef
recipientAccountRef
channel
deviceRef
processingStatus
riskLevel
riskResponseOutcome
adoptedDetectionResultId
version
createdAt / updatedAt

금액은 API에서 문자열로 받아 정밀도 손실 없이 파싱하고, PostgreSQL에서는 NUMERIC(19,4)를 사용하되 0보다 큰 정수만 허용하는 Check를 둡니다.

recipientAccountRef와 channel은 거래 유형에 따라 필수 또는 금지되는 조합이 다르므로 애플리케이션과 DB가 같은 규칙을 검증합니다.

ACCOUNT_TRANSFER
수취 계좌 필수
MOBILE_BANKING

OPEN_BANKING_TRANSFER
수취 계좌 필수
OPEN_BANKING

ATM_WITHDRAWAL
수취 계좌 금지
ATM

LOAN_DISBURSED
수취 계좌 금지
CORE_BANKING

4.2 BehaviorEvent — 거래 전후 행동 타임라인

행동 이벤트는 거래 없이 먼저 발생할 수 있으므로 거래 참조를 선택적으로 둡니다.

Transaction 1
→ BehaviorEvent 0..N

BehaviorEvent
→ Transaction 0..1

행동 이벤트는 별도 Idempotency-Key를 요구하지 않고, 호출자가 생성한 eventId와 정규화한 Request Fingerprint로 자연 멱등성을 구성합니다.

새 eventId → 새로운 행동 이벤트 저장
같은 eventId + 같은 Fingerprint → 기존 이벤트 반환
같은 eventId + 다른 Fingerprint → 충돌로 거부
동시 Insert → event_id Unique가 최종 단일 승자를 결정

이벤트 유형별로 필요한 계좌·기기·수취인·거래 참조가 다르므로 유형별 null 조합은 Check Constraint로 방어합니다. 고객·계좌·거래 유형처럼 여러 행을 비교해야 하는 규칙은 Service에서 검증합니다.

4.3 IdempotencyRecord — 거래 상태와 명령 처리 상태 분리

operationScope
+ idempotencyKey
→ Unique

requestFingerprint
processingStatus
financialTransactionId
responseSnapshot
failureCode
expiresAt
createdAt / updatedAt / finishedAt

멱등 상태를 거래 행에 직접 넣지 않고 별도 Entity로 두면 처리 중 요청, 완료 결과 재생, 실패 결과와 보존 기간을 거래 업무 상태와 독립적으로 관리할 수 있습니다.

거래 상태는 금융 업무가 어디까지 진행됐는지를 표현하고, IdempotencyRecord는 동일 명령의 실행권과 최초 응답 재생을 관리합니다. 두 상태를 하나의 컬럼으로 합치지 않습니다.

5. 탐지 결과·Evidence·RuleVersion 모델

5.1 DetectionResult — 거래별 분석 버전

같은 거래도 Rule·Feature·모델 조건이 바뀌면 다시 분석할 수 있습니다. 기존 결과를 덮어쓰지 않고 새로운 버전으로 보존합니다.

Transaction 1
→ DetectionResult 0..N

UNIQUE(
  financial_transaction_id,
  detection_result_version
)

실패한 분석도 실행 사실을 보존하기 위해 하나의 버전을 소비합니다. 늦게 도착한 중복 응답이 같은 버전을 다시 저장하거나 기존 결과를 바꾸지 못하도록 합니다.

PENDING
실행 조건과 버전 고정

IN_PROGRESS
분석 시작 시각 필수

COMPLETED
점수·등급·완료 시각 필수

FAILED
실패 코드·완료 시각 필수

5.2 DetectionEvidence — 설명 가능한 개별 근거

DetectionResult 1
→ DetectionEvidence 0..N

Evidence Type
→ RULE
→ ML
→ EXTERNAL_RISK
→ BEHAVIOR_PATTERN

Evidence는 단순 설명 문자열이 아니라 안정적인 reasonCode, 점수 기여도, 사용한 RuleVersion과 제한된 관측 요약을 보존합니다.

observationSummary 저장 원칙

Reason Code별 허용 Key만 저장
JSON Object만 허용하고 배열·중첩 객체 금지
원문 행동 로그와 전체 Feature Vector 저장 금지
실제 계좌·기기·IP 원문 저장 금지
화면과 재현에 필요한 최소 관측값만 보존

5.3 FraudRule과 RuleVersion — 논리 정책과 불변 실행 정의

FraudRule 1
→ RuleVersion N

DRAFT → PUBLISHED
DRAFT → WITHDRAWN

FraudRule은 논리적인 Rule의 정체성을 소유하고, RuleVersion은 실제 실행 조건·가중치·Reason Code·적용 기간을 소유합니다.

게시된 버전의 실행 정의를 수정하지 않습니다. 정책을 바꿔야 하면 기존 행을 업데이트하는 대신 새로운 versionNumber를 생성합니다.


    PUBLISHED 적용 기간
    = [effectiveFrom, effectiveTo)

시작 시각은 포함하고 종료 시각은 제외하는 반개방 구간을 사용합니다. 동일 Rule의 게시 기간이 겹치지 않도록 PostgreSQL Exclusion Constraint를 사용하고, 인접한 두 기간은 허용합니다.

️ 6. 사건·조사 메모·감사 로그 모델

6.1 FraudCase와 CaseTransaction

하나의 사건은 여러 거래를 조사할 수 있고, 하나의 거래도 시간에 따라 여러 종료 사건 이력을 가질 수 있으므로 중간 Entity로 다대다 관계를 표현합니다.

FraudCase 1
→ CaseTransaction N
→ Transaction 1

UNIQUE(
  fraud_case_id,
  financial_transaction_id
)

동일 사건과 거래의 중복 연결은 Unique로 막습니다. 다만 “한 거래에 활성 사건은 최대 하나”라는 규칙은 다른 테이블의 사건 상태까지 확인해야 하므로, 거래를 먼저 잠근 뒤 활성 사건을 조회·검증하는 Service 경계에서 보장합니다.

활성 사건
OPEN
IN_REVIEW
ADDITIONAL_INFORMATION_REQUIRED

종료 사건
CLOSED
finalDisposition 필수
closedAt 필수

검토 중 사건
IN_REVIEW
assigneeRef 필수
finalDisposition = null

6.2 CaseNote — 조사 메모의 정정 이력

조사 메모는 과거 기록을 직접 덮어쓰기보다 append-only를 기본 방향으로 둡니다.

기존 메모 직접 수정·삭제
→ 지양

정정 필요
→ correctionOfNoteId로 원 메모 참조
→ 새로운 정정 메모 추가

메모에는 불필요한 고객·계좌 원문이나 인증정보를 기록하지 않고, 담당자의 조사 근거에 필요한 최소 정보만 남깁니다.

6.3 AuditLog — 현재 상태가 아닌 변경 이력

감사 로그는 거래나 사건의 현재 상태를 대신하는 테이블이 아닙니다. 누가, 언제, 어떤 이유로 무엇을 변경했는지 별도로 기록합니다.

actorType / actorId
action / reasonCode
targetType / targetId
beforeValueSummary
afterValueSummary
metadata
transactionId / caseId / traceId
changedAt

자유 형식 JSON을 무제한 저장하지 않고, Action별 허용 Key·Scalar Type·크기를 제한합니다. Prompt, LLM 입출력, 내부 예외와 금융 원문을 감사 로그에 그대로 복제하지 않습니다.

Application 방어
INSERT 전용 Repository
수정·삭제 메서드 없음
Typed JSON 계약

PostgreSQL 방어
UPDATE·DELETE 차단 Trigger
ON DELETE RESTRICT
Action 조합 Check

사건 생성·거래 최종화·AuditLog append가 하나의 업무 변경이라면 감사 기록 실패를 무시하지 않고 같은 트랜잭션 전체를 Rollback합니다.

7. AI 리포트·실행·Provider 사용량 모델

AI 리포트 영역을 하나의 테이블로 합치면 외부 요청, 논리 실행, 실제 Provider 호출과 최종 결과의 의미가 섞입니다.

AiReportRequest

사용자가 리포트를 요청한 사실, 멱등성, 요청자와 최종 해결 결과를 보존합니다.

AiReportExecution

정확 일치 조건에 대해 실제로 공유되는 하나의 논리 실행을 관리합니다.

ProviderCallAttempt

실제 Provider 호출별 모델, 토큰, 지연시간, 비용과 실패를 기록합니다.

AiReport

검증을 통과한 LLM 결과 또는 템플릿 fallback 결과의 본문을 보존합니다.

FraudCase 1
→ AiReportRequest N

AiReportExecution 1
→ ProviderCallAttempt N

AiReportExecution 1
→ AiReport 0..1

♻️ 정확 일치 캐시를 데이터로 표현하는 방법

caseId
+ detectionResultVersion
+ promptVersion
+ modelVersion

완료된 결과를 정확 일치 캐시로 재사용할 때도 새로운 외부 요청 이력은 남길 수 있습니다. 하지만 새 실행, 새 Provider 호출, 가상 토큰과 가상 비용을 만들지 않습니다.

캐시 적중 요청 → 기존 AiReport 참조
새 AiReportExecution 생성 안 함
새 ProviderCallAttempt 생성 안 함
캐시 자체를 reportSource로 기록하지 않음
측정하지 못한 토큰·비용을 0으로 단정하지 않음

하나의 실행에서 Timeout으로 재시도하거나 모델을 라우팅하면 실제 Provider 호출이 여러 번 발생할 수 있습니다. 그래서 사용량과 비용은 논리 실행이 아니라 ProviderCallAttempt 단위로 기록합니다.

️ 8. PostgreSQL을 정합성 방어선으로 사용한 방법

애플리케이션 검증과 PostgreSQL 제약을 중첩하고, Flyway로 호환 가능한 스키마 확장을 관리하는 구조

데이터 정합성은 한 계층의 검증에만 의존하지 않습니다.

API 검증 → 도메인 검증 → JPA 불변식 → PostgreSQL 최종 방어

Foreign Key

존재하지 않는 거래 참조 방지
RuleVersion과 Evidence 관계 보장
거래·사건·감사 데이터 삭제 제한

Unique

transactionId·eventId 중복 방지
멱등 Scope·Key 단일 승자
거래별 분석 버전 중복 방지
사건–거래 연결 중복 방지

✅ Check

허용 Enum과 UUID v4
금액·시간·문자열 범위
상태별 nullable 조합
거래·이벤트 유형별 필드 조합

Trigger

AuditLog UPDATE·DELETE 차단
PUBLISHED RuleVersion 불변성
Evidence Snapshot 일치 검증
직접 SQL 우회 변경 방어

Exclusion Constraint

같은 FraudRule의 PUBLISHED 적용 기간이 겹치는 것을 막고, 인접한 버전 기간은 허용합니다.

Typed JSONB

자유 형식 문서 저장소처럼 사용하지 않고, 허용 Key·Scalar Type·크기를 제한합니다.

애플리케이션 검증은 사용자에게 이해 가능한 오류를 제공하고, PostgreSQL 제약은 경쟁 쓰기와 우회 저장을 막는 최종 방어선으로 사용합니다.

⚡ 9. 조회 패턴을 기준으로 설계한 Index

Index는 Entity나 FK가 존재한다는 이유만으로 무조건 추가하지 않습니다. 실제 업무 조회의 Filter, 정렬과 Pagination 순서를 기준으로 설계합니다.

행동 이벤트 Rule 조회

externalCustomerRef
eventType
occurredAt DESC
eventId ASC

사건 목록 조회

caseStatus
lastChangedAt
id

감사 이력 조회

caseId
changedAt DESC
id DESC

탐지 장애 조회

analysisStatus
updatedAt

장기 IN_PROGRESS 복구 후보

operationScope
updatedAt
id
WHERE status = IN_PROGRESS

⚖️ Index도 비용이 있는 설계 선택

얻는 것
조회 범위 축소
정렬 비용 감소
운영 검색 속도 향상

지불하는 것
INSERT·UPDATE 비용
추가 저장 공간
Migration 시간과 잠금

따라서 실제 Query와 실행계획 없이 계좌·기기·Reason Code별 Index를 선제적으로 계속 추가하지 않습니다. 느린 조회가 확인되면 Filter 선택도, 정렬과 Pagination을 함께 분석합니다.

10. 동시성·잠금·버전 관리

모든 동시성 문제를 하나의 잠금 방식으로 해결하지 않습니다. 사용자 업무의 수정 충돌과 짧은 단일 승자 경쟁은 성격이 다릅니다.

낙관적 잠금

사용자가 읽고 나중에 수정하는 비교적 긴 업무 흐름에서 @Version으로 선행 변경을 감지합니다.

FraudCase 상태 변경
FraudRule 메타데이터 변경
RuleVersion DRAFT 수정
동시 편집 충돌 검출

비관적 잠금

같은 거래를 기준으로 단 하나의 생성·버전 할당·최종화가 필요한 짧은 경쟁 구간에서 사용합니다.

거래별 DetectionResult version 할당
HIGH·CRITICAL 사건 생성
활성 사건 중복 방지
멱등 완료·복구 단일 승자

잠금 순서를 고정한 이유


    Transaction
    → FraudCase
    → CaseTransaction

같은 데이터 집합을 요청마다 다른 순서로 잠그면 Deadlock 가능성이 커집니다. 거래를 먼저 잠근 뒤 활성 사건과 연결을 일관된 순서로 잠그도록 설계합니다.

☁️ 여러 Pod가 공유해야 하는 기준

Kubernetes에서 Pod가 여러 개 실행되면 JVM 메모리 Lock은 다른 Pod와 공유되지 않습니다. 따라서 단일 승자는 PostgreSQL의 Unique, Row Lock과 Version을 기준으로 결정합니다.

Pod A ─┐
       ├→ PostgreSQL Row / Unique Constraint
Pod B ─┘

→ 하나의 거래 버전
→ 하나의 활성 사건
→ 하나의 멱등 완료 결과

11. Flyway와 Rolling Update를 고려한 스키마 확장

데이터 모델은 한 번 만들고 끝나는 구조가 아닙니다. 거래·탐지·사건·AI 운영 기능이 추가되면서 Schema도 계속 확장됩니다.

11.1 적용된 Migration은 수정하지 않는다

이미 공유 환경에 적용된 Migration
→ 내용 수정 금지

새로운 스키마 변경
→ 다음 버전 Migration으로 추가

기존 Migration을 수정하면 개발자마다 동일한 버전 번호가 서로 다른 Schema를 의미하게 됩니다. Flyway Checksum과 재현 가능성을 유지하기 위해 변경 이력을 앞으로만 추가합니다.

11.2 Additive Migration 우선

새 테이블 추가

새 nullable 컬럼 추가

새 Index 추가

호환 가능한 제약 추가

구버전 애플리케이션이 모르는 필드를 즉시 필수로 만들거나 기존 컬럼을 바로 Rename·Drop하면 Rolling Update 중 오류가 발생할 수 있습니다.

11.3 Expand–Migrate–Contract

1. Expand

신·구 버전이 함께 사용할 수 있도록 새 컬럼·테이블을 호환 가능한 형태로 추가합니다.

2. Migrate

애플리케이션을 배포하고 필요한 데이터 이관과 이중 읽기·쓰기를 검증합니다.

3. Contract

구버전 사용 중단과 데이터 이관 완료를 확인한 뒤 오래된 컬럼·계약을 제거합니다.

11.4 Rolling Update 호환성

구버전 Pod
+ 신버전 Pod
+ 하나의 PostgreSQL Schema

새 컬럼을 처음부터 NOT NULL로 추가하지 않기
구버전이 모르는 Enum 값을 즉시 저장하지 않기
컬럼 Rename보다 새 컬럼 추가 후 단계적 전환
삭제·축소는 모든 Pod 전환 이후 수행
Application 배포 전에 Schema 호환성 검증

AI Agent가 DB 계약을 임의로 바꾸지 못하게 한 이유

AI Agent는 ERD, Migration SQL과 테스트 초안을 만들 수 있지만 다음 변경을 독자적으로 확정할 수 없습니다.

적용된 Migration 수정
컬럼·테이블 삭제
대규모 Backfill과 데이터 변환
새 상태값·제약조건 확정
Production Migration 실행

ERD 영향 검토
→ API 호환성 검토
→ Migration Review
→ 구·신버전 공존 확인
→ PostgreSQL 통합 테스트
→ 사용자 최종 승인

☁️ 12. Cloud Native 환경의 DB 운영·검증 기준

데이터베이스 설계는 DDL이 적용되는 것으로 끝나지 않습니다. 여러 인스턴스, Connection Pool, Migration과 장애 상황에서 같은 정합성 규칙이 유지되는지 검증해야 합니다.

Connection Pool과 트랜잭션 보유 시간

외부 API 호출 중 DB Connection과 Row Lock을 장시간 보유하지 않기
짧은 상태 확정 트랜잭션과 외부 호출 경계 분리
Pool 사용량과 Connection 획득 대기시간 관측
Transaction Timeout과 Lock 대기시간 구분


    짧은 DB Commit
    → Connection 반환
    → External Risk·FastAPI 호출
    → 새 트랜잭션에서 결과 확정

Migration Gate

Flyway Validate
→ Migration 적용
→ Hibernate Schema Validation
→ 애플리케이션 기동
→ Health Check
→ 핵심 업무 Smoke Test

Migration Checksum이 다르거나 JPA Mapping과 실제 Schema가 일치하지 않으면 애플리케이션이 조용히 동작하도록 두지 않고 배포를 중단합니다.

운영에서 관측할 항목

DB Connection Pool 사용량

Connection 획득 대기시간

Query 지연시간

Lock 대기와 Deadlock

Transaction Rollback

Migration 성공·실패

Table·Index 크기

장기 IN_PROGRESS 수

Backup과 복구 원칙

파괴적 Migration 전에 Backup과 복구 경로 확인
Rollback SQL 하나에만 의존하지 않기
복구 이후 FK·상태·사건·감사 정합성 재검증
복구 작업의 실행 주체와 결과 감사
보존·파기 정책과 복구 목표를 별도 운영 문서로 관리

검증 기준

빈 PostgreSQL에 모든 Flyway Migration이 순서대로 적용되는가
기존 데이터가 있는 Schema에도 Additive Migration이 적용되는가
JPA Mapping과 실제 Schema가 일치하는가
Unique·FK·Check·Trigger가 우회 SQL도 거부하는가
동시 Insert에서 단 하나의 요청만 성공하는가
구버전과 신버전이 공존해도 Schema를 함께 사용할 수 있는가
AuditLog와 PUBLISHED RuleVersion의 직접 변경이 거부되는가
업무 Query가 예상한 Index와 정렬 전략을 사용하는가
DB Pool 고갈·Lock 대기·Migration 실패를 지표와 로그로 확인할 수 있는가

13. 마치며: 데이터 모델 위에 API 계약을 올리기

FinGuardOps의 ERD는 거래·탐지·사건 데이터를 단순히 연결한 그림이 아닙니다.

상태와 결과, 현재값과 이력, 외부 요청과 실제 AI 실행, 업무 원본과 캐시를 분리하고, PostgreSQL 제약을 통해 허용 가능한 관계와 상태 조합을 보조 검증하는 설계입니다.

FinGuardOps 데이터 설계의 핵심


    업무 관계
    → ERD

    중복·상태 조합
    → Unique·Check·FK

    불변 이력
    → 버전 Entity·Append-only

    동시 쓰기
    → Lock·Version·DB Constraint

    배포 중 스키마 변경
    → Flyway·Expand–Migrate–Contract

    운영 검증
    → Testcontainers·Metrics·Backup·Recovery

데이터 관계와 제약을 정의한 다음에는 외부 요청이 이 모델에 어떤 형식으로 들어오고, Validation 실패와 업무 충돌을 어떤 HTTP 계약으로 반환할지 결정해야 합니다.

[FinGuardOps #5] 중복과 잘못된 입력을 막는 거래·행동 이벤트 API와 Validation 설계
금융 거래와 9개 행동 이벤트의 Request·Response, Validation, 자연 멱등성, 오류 계약, Trace ID와 Rolling Update 중 API 호환성을 정리합니다.

GitHub에서 FinGuardOps 저장소 보기

[FinGuardOps #3] 재시도와 장애에도 안전한 거래·사건 상태 전이와 멱등성 설계

bbbicsan — Mon, 31 Aug 2026 11:14:51 +0900

FinGuardOps Project Series #3

금융 거래 요청을 처리할 때 가장 위험한 상황 중 하나는 서버가 업무를 완료했지만 클라이언트가 응답을 받지 못하는 경우입니다.

사용자는 요청이 실패했다고 판단해 같은 거래를 다시 전송할 수 있습니다. 별도의 통제가 없다면 거래뿐 아니라 탐지 결과, 외부 위험정보 조회, 고위험 사건과 감사 이력까지 중복으로 생성될 수 있습니다.

거래 요청 전송
→ 서버의 금융 업무 처리 완료
→ 응답 전송 중 네트워크 연결 종료
→ 사용자는 실패로 판단
→ 같은 요청 재전송
→ 중복 거래·탐지·사건·외부 호출 위험

단일 서버라면 메모리 Lock으로 해결할 수 있어 보이지만, 여러 Pod가 동시에 요청을 처리하거나 애플리케이션이 재시작되는 Cloud Native 환경에서는 메모리 상태만으로 안전성을 보장할 수 없습니다.

그래서 FinGuardOps에서는 상태 전이로 업무가 어디까지 확정되었는지 표현하고, 멱등성으로 동일한 명령의 중복 실행을 통제하도록 설계했습니다.

멱등성은 중복 요청을 단순히 무시하는 기능이 아니라, 동일한 명령에 대해 최초로 확정한 업무 결과를 다시 재현하는 계약입니다.

거래 처리 단계, 위험 대응, 사건 진행 상태와 최종 판정을 서로 다른 개념으로 분리한 FinGuardOps 상태 모델

이번 글은 특정 시점의 구현 현황보다 재시도·동시성·재시작·Rolling Update 환경에서 금융 업무 정합성을 유지하기 위해 어떤 상태와 멱등 계약을 설계했는지 설명합니다.

왜 상태 전이와 멱등성이 필요한가
하나의 status로 합치지 않은 여섯 가지 개념
거래 처리 상태 전이
️ 위험 등급과 위험 대응 결과
️ 사건 상태와 최종 판정
상태 변경의 동시성·감사 원칙
Idempotency-Key와 Request Fingerprint
멱등 처리 상태와 중복 요청 판단
Response Snapshot과 최초 결과 재생
️ 최종 성공 경계와 완료 간극 복구
☁️ Cloud Native 환경의 운영·검증 기준
마치며: 상태 모델을 데이터베이스로 옮기기

1. 왜 상태 전이와 멱등성이 필요한가

상태 전이와 멱등성은 비슷해 보이지만 서로 다른 문제를 해결합니다.

상태 전이

거래와 사건이 업무 흐름의 어느 단계에 있으며, 현재 상태에서 어떤 다음 상태로 이동할 수 있는지를 표현합니다.

멱등성

동일한 금융 명령이 반복되더라도 실제 업무를 다시 실행하지 않고 최초 결과를 재현하도록 통제합니다.

예를 들어 거래가 ANALYZING이라는 사실은 분석 중이라는 업무 단계만 설명합니다. 같은 HTTP 요청을 다시 실행해도 되는지는 멱등 레코드와 요청 동일성 검증을 통해 따로 판단해야 합니다.

반대로 멱등 레코드가 IN_PROGRESS라고 해서 거래가 접수 단계인지, 분석 단계인지, 최종 업무 Commit 이후 응답만 누락된 상태인지까지 모두 설명할 수 있는 것은 아닙니다.


    거래 업무 상태
    + 사건 업무 상태
    + 멱등 명령 처리 상태
    → 서로 분리해서 관리

☁️ Cloud Native 환경에서 문제가 더 커지는 이유

Pod A
→ 최초 거래 요청 수신

Pod B
→ 같은 요청의 네트워크 재시도 수신

Rolling Update
→ 구버전과 신버전이 동시에 요청 처리

Pod 재시작
→ 프로세스 메모리의 Lock과 처리 정보 소멸

따라서 특정 인스턴스의 메모리가 아니라 모든 애플리케이션 인스턴스가 공유하는 영속 저장소를 기준으로 단일 처리 승자와 결과 재생 여부를 판단해야 합니다.

2. 하나의 status로 합치지 않은 여섯 가지 개념

FinGuardOps에서는 거래와 사건을 하나의 status 필드로 표현하지 않습니다. 각각의 값이 답해야 하는 질문이 다르기 때문입니다.

1. TransactionProcessingStatus

거래가 접수·분석·최종 대응 중 어느 단계에 있는가

2. RiskLevel

Rule·ML 분석 결과의 위험 수준은 무엇인가

3. RiskResponseOutcome

위험 등급에 따라 어떤 Mock 대응을 적용했는가

4. CaseStatus

사건 조사가 어느 업무 단계에 있는가

5. FinalDisposition

담당자의 최종 조사 결과는 무엇인가

6. IdempotencyProcessingStatus

동일 명령이 처리 중인지, 완료됐는지, 실패가 확정됐는가

개념을 분리해야 하는 이유

MEDIUM 거래

거래 처리 상태 = APPROVED
위험 등급 = MEDIUM
위험 대응 결과 = APPROVED_WITH_MONITORING
사건 = 생성하지 않음

조사 중인 사건

사건 상태 = IN_REVIEW
최종 판정 = null

업무는 완료됐지만 응답 Snapshot 저장이 누락된 경우

거래 상태 = APPROVED
             또는 ADDITIONAL_AUTH_REQUIRED
             또는 HELD

멱등 상태 = IN_PROGRESS

Transaction FAILED ≠ Idempotency FAILED ≠ AI Report FAILED
각 실패는 원인, 영향 범위와 복구 방식이 서로 다릅니다.

3. 거래 처리 상태 전이

거래 상태는 요청 검증, 분석, 위험 대응과 최종 처리 결과를 구분합니다.

요청 형식 또는 도메인 Validation 실패
→ 거래 미생성
→ 400 또는 422 오류 응답
→ 로그·Trace·메트릭으로 관측

Validation 성공
→ RECEIVED
→ ANALYZING
   ├─ 분석 결과 확정 → ANALYZED
   └─ 분석 처리 실패 → FAILED

ANALYZED
├─ LOW      → APPROVED
├─ MEDIUM   → APPROVED
├─ HIGH     → ADDITIONAL_AUTH_REQUIRED
└─ CRITICAL → HELD

RECEIVED

요청 검증을 통과해 거래가 최초 저장된 상태입니다. 접수 성공은 분석 성공이나 거래 승인을 의미하지 않습니다.

ANALYZING

거래·행동 이벤트·RuleVersion과 외부 위험정보를 바탕으로 이상거래 분석이 진행 중인 상태입니다.

ANALYZED

탐지 결과와 Evidence가 저장되고 위험 등급이 정해진 상태입니다. 위험 대응과 사건 연결까지 끝난 최종 성공 상태는 아닙니다.

✅ APPROVED

LOW 또는 MEDIUM 거래의 Mock 승인이 완료된 상태입니다. MEDIUM의 모니터링 여부는 별도 대응 결과로 관리합니다.

ADDITIONAL_AUTH_REQUIRED

HIGH 위험 거래에 Mock 추가 인증이 필요하다는 최종 처리 결과입니다.

⏸️ HELD

CRITICAL 위험 거래를 Mock 보류한 상태입니다. 실제 고객 자금 동결이나 금융기관 거래 차단을 의미하지 않습니다.

❌ FAILED

Rule 분석이나 분석 오케스트레이션을 정상적으로 완료하지 못한 상태입니다. AI 리포트 생성 실패는 거래 FAILED의 원인이 아닙니다.

ANALYZED = 분석 완료 ≠ 전체 금융 업무 성공

️ 4. 위험 등급과 위험 대응 결과

위험 등급과 최종 상태는 서로 독립적인 값을 아무렇게나 조합하지 않습니다. 승인된 정책이 허용하는 조합만 최종 결과로 사용합니다.

LOW

status = APPROVED
outcome = APPROVED
caseId = null

MEDIUM

status = APPROVED
outcome = APPROVED_WITH_MONITORING
caseId = null

HIGH

status = ADDITIONAL_AUTH_REQUIRED
outcome = ADDITIONAL_AUTH_REQUIRED
caseId = 필수

CRITICAL

status = HELD
outcome = HELD
caseId = 필수

MONITORING을 거래 상태로 두지 않은 이유

MEDIUM 거래는 승인 자체는 완료된 상태입니다. 따라서 거래 처리 상태는 APPROVED로 유지하고, 승인 후 모니터링한다는 정책만 APPROVED_WITH_MONITORING으로 분리합니다.

거래 상태 = APPROVED
위험 등급 = MEDIUM
대응 결과 = APPROVED_WITH_MONITORING

⏸️ BLOCKED 대신 HELD를 사용한 이유

FinGuardOps는 실제 금융기관의 거래 차단이나 고객 제재를 수행하지 않습니다. 따라서 CRITICAL 대응은 실제 차단을 의미하는 BLOCKED보다 프로젝트 내부의 Mock 보류를 뜻하는 HELD로 표현합니다.

️ 5. 사건 상태와 최종 판정

사건은 거래 처리와 별개의 조사 Workflow입니다. 사건이 열려 있다는 사실과 이상거래로 최종 확정됐다는 사실을 같은 값으로 표현하지 않습니다.

OPEN
→ IN_REVIEW
→ ADDITIONAL_INFORMATION_REQUIRED
→ IN_REVIEW
→ CLOSED

OPEN

고위험 거래로 사건이 생성되어 검토를 기다리는 상태입니다. 최초에는 담당자가 없을 수 있습니다.

IN_REVIEW

담당자가 거래, Evidence, 행동 타임라인과 연관 정보를 검토하는 상태입니다. 이 상태에는 담당자가 필요합니다.

❓ ADDITIONAL_INFORMATION_REQUIRED

현재 정보만으로 판정하기 어려워 추가 자료가 필요한 상태입니다. 이 상태 자체가 이상거래 확정을 의미하지 않습니다.

✅ CLOSED

조사와 필요한 기록이 완료된 상태입니다. 사건을 종료하려면 최종 판정이 반드시 필요합니다.

⚖️ 최종 판정

NORMAL
정상 거래로 확인

FALSE_POSITIVE
오탐으로 확인

CONFIRMED_FRAUD
이상거래로 확정

조사 진행 중
caseStatus = OPEN
             또는 IN_REVIEW
             또는 ADDITIONAL_INFORMATION_REQUIRED
finalDisposition = null

조사 종료
caseStatus = CLOSED
finalDisposition = NORMAL
                   또는 FALSE_POSITIVE
                   또는 CONFIRMED_FRAUD

초기 범위에서 허용하지 않는 전이

OPEN → CLOSED
ADDITIONAL_INFORMATION_REQUIRED → CLOSED
CLOSED → IN_REVIEW
최종 판정 없이 CLOSED
생성형 AI가 사건 상태 또는 최종 판정을 확정하는 동작

6. 상태 변경의 동시성·감사 원칙

상태 전이는 DB 문자열 하나를 바꾸는 작업이 아닙니다. 요청 당시의 현재 상태, 허용 전이, 변경 주체와 동시 수정 여부를 함께 검증해야 합니다.

✅ 모든 상태 변경에서 확인할 조건

현재 상태가 요청자가 예상한 상태인가
요청한 다음 상태가 허용되는가
다른 요청이 먼저 값을 변경하지 않았는가
변경 주체에게 필요한 권한이 있는가
필수 사유와 연관 거래·사건 정보가 존재하는가

예를 들어 두 분석 담당자가 같은 사건을 동시에 종료하려고 할 때, 나중 요청이 먼저 저장된 최종 판정을 조용히 덮어써서는 안 됩니다.

현재 상태·동시성 버전 확인
→ 허용 전이 검증
→ 상태와 관련 데이터 변경
→ 감사 로그 생성
→ 하나의 정합성 경계에서 Commit

감사 로그에 남길 정보

변경 주체

변경 시각

이전 상태

변경 후 상태

변경 사유

transactionId

caseId

traceId·실행 식별자

같은 상태로 다시 변경하는 요청도 무조건 성공시키지 않습니다. 실제 변경이 없는 정상 요청인지, 중복 명령인지, 오래된 화면에서 전송한 충돌 요청인지 구분할 수 있도록 명시적으로 검증합니다.

7. Idempotency-Key와 Request Fingerprint

Idempotency-Key만 비교해서는 동일한 금융 요청인지 안전하게 판단할 수 없습니다. 같은 Key가 전혀 다른 거래 내용에 재사용될 수도 있기 때문입니다.

Idempotency-Key

하나의 업무 명령과 그 명령의 재시도를 식별합니다.

Request Fingerprint

Key와 함께 전달된 금융 업무 내용이 실제로 동일한지 확인합니다.

여러 Pod와 재시작 환경에서도 동일 요청의 중복 실행을 막고 최초로 확정한 결과를 재생하는 FinGuardOps 멱등 처리 흐름

Fingerprint에 포함하는 업무 필드

transactionId
transactionType
amount
currencyCode
occurredAt
externalCustomerRef
senderAccountRef
recipientAccountRef
channel
deviceRef

원본 JSON 문자열을 그대로 해시하지 않고, Validation과 정규화를 마친 업무 값을 고정된 순서로 직렬화한 뒤 SHA-256 Fingerprint를 계산합니다.

UUID → canonical 문자열
금액 → canonical 10진 문자열
시간 → UTC ISO-8601 Instant
Nullable 값 → JSON null
필드 순서 → 고정
Hash Algorithm → SHA-256

Fingerprint에서 제외하는 값

traceId
Idempotency-Key 자체
서버 생성 시각
내부 DB Primary Key
현재 처리 상태

Idempotency-Key와 transactionId의 차이

Idempotency-Key
= 하나의 명령과 재시도를 식별

transactionId
= 생성되거나 처리되는 금융 거래 자원을 식별

두 식별자는 목적이 다르므로 서로 대체하지 않습니다.

8. 멱등 처리 상태와 중복 요청 판단

멱등 레코드는 동일한 업무 명령이 어느 상태인지 다음 세 값으로 표현합니다.

IN_PROGRESS
처리 중 또는 결과 확정 여부가 불분명

COMPLETED
최초 업무 결과와 Snapshot 확정

FAILED
재생 가능한 업무 실패가 확정

새로운 Key

새 IN_PROGRESS Claim 생성
→ 실제 업무 처리 시작

같은 Key + 같은 Fingerprint

IN_PROGRESS

같은 명령이 처리 중이므로 업무를 다시 실행하지 않고 처리 중 충돌을 반환합니다.

COMPLETED

External Risk·FastAPI·위험 대응·사건 생성을 다시 실행하지 않고 저장된 Response Snapshot을 재생합니다.

FAILED

자동 재처리하지 않고 저장된 안전한 실패 분류를 재생합니다.

⚠️ 같은 Key + 다른 Fingerprint


    IDEMPOTENCY_KEY_CONFLICT

기존 멱등 상태가 무엇이든 같은 Key를 다른 거래 내용에 재사용할 수 없도록 거부합니다.

처리 완료 여부가 불확실한 요청을 자동 재실행하지 않습니다. 불확실 상태에서의 자동 재실행은 중복 거래·사건·외부 호출을 만들 수 있기 때문입니다.

9. Response Snapshot과 최초 결과 재생

같은 거래 생성 명령이 다시 들어왔을 때 PostgreSQL에서 거래와 사건의 최신 상태를 조회해 반환하지 않습니다.

멱등 재생 = 최초 명령 결과 재현
현재 상태 조회 = 별도의 조회 API 책임

거래 생성 이후 사건 조사가 진행되거나 사건 상태가 변경되더라도, 같은 거래 생성 명령의 재시도에는 당시 최초로 확정한 응답을 반환합니다.

Snapshot Envelope

responseBody
httpStatus
responseSchemaVersion
codecVersion
finalizedAt

업무 응답에 포함할 값

transactionId
processingStatus
riskLevel
riskResponseOutcome
adoptedDetectionResultId
caseId
createdAt

Snapshot에 저장하지 않을 값

Idempotency-Key
Request Fingerprint
내부 DB Primary Key
Credential과 Secret
민감한 금융 참조값
traceId

traceId는 최초 요청과 재요청마다 달라질 수 있으므로 Snapshot에는 저장하지 않고, 저장된 업무 결과와 현재 요청의 Trace를 결합합니다.

Schema와 Codec에 버전을 두는 이유

구버전 Pod
→ Snapshot v1 생성

신버전 Pod
→ 기존 v1을 읽을 수 있음
→ 신규 요청에는 v2 생성

Rolling Update
→ v1·v2가 일정 시간 함께 존재

응답 Schema와 Codec 버전을 명시하면 과거 요청 결과를 최신 구조로 잘못 해석하거나 소급 변경하는 문제를 방지할 수 있습니다.

️ 10. 최종 성공 경계와 완료 간극 복구

다음 거래 상태에서는 성공 Response Snapshot을 확정하지 않습니다.

RECEIVED

ANALYZING

ANALYZED

최종 성공은 분석 결과가 존재한다는 사실만으로 결정하지 않습니다. 다음 업무가 모두 확정되어야 합니다.

Rule 분석 결과 저장
DetectionResult 완료
Evidence 저장
거래가 탐지 결과 채택
위험 등급 확정
위험 대응 결과 확정
최종 거래 상태 전이
HIGH·CRITICAL이면 사건 생성 또는 기존 사건 연결
감사 로그와 필수 업무 Commit 완료

⚠️ 완료 간극

거래·탐지·위험 대응·사건 Commit 성공
→ Response Snapshot 저장 또는 COMPLETED 전이 실패

이미 금융 업무 결과가 Commit되었다면 응답 저장 실패를 이유로 거래나 사건을 되돌리거나 업무를 다시 실행해서는 안 됩니다.

유지할 것

최종 거래 상태
탐지 결과와 Evidence
위험 대응 결과
사건과 감사 기록
멱등 상태 IN_PROGRESS

금지할 것

External Risk 재호출
FastAPI 재호출
새 DetectionResult 생성
위험 대응 재실행
새 사건 생성

복구는 새로운 업무 실행이 아니다

PostgreSQL의 확정 상태 검증
→ 위험 등급·최종 상태·사건 연결 조합 확인
→ 동일한 Response Snapshot 결정적 재구성
→ 기존 멱등 Record를 COMPLETED로 전이

완료 간극 복구는 거래를 재분석하거나 새 사건을 만드는 작업이 아니라, 이미 확정된 결과를 확인해 누락된 응답 기록만 복원하는 운영 작업입니다.

☁️ 11. Cloud Native 환경의 운영·검증 기준

멱등성은 코드 한 곳에 if 문을 추가하는 것으로 끝나지 않습니다. 여러 인스턴스, 재시작, 배포 전환과 장애 상황에서 같은 계약이 유지되는지 검증해야 합니다.

여러 Pod의 동시 요청

Pod A와 Pod B가 같은 요청을 동시에 받더라도 애플리케이션 메모리가 아니라 PostgreSQL의 공유 멱등 Record와 Unique Constraint를 기준으로 실제 처리 승자를 하나만 정합니다.

애플리케이션 재시작

인스턴스가 종료되더라도 다음 정보는 영속 저장소에 남아야 합니다.

Request Fingerprint
멱등 처리 상태
연결된 transactionId
Response Snapshot
안전하게 공개할 실패 분류

Rolling Update

신버전이 구버전 Snapshot을 읽을 수 있는가
새 응답 Schema가 기존 Snapshot을 손상하지 않는가
상태 Enum 추가가 구버전과 충돌하지 않는가
DB Migration이 구버전·신버전의 공존을 허용하는가

관측할 지표

동일 요청 재생 횟수

Idempotency-Key 충돌 수

IN_PROGRESS 체류 시간

장기 IN_PROGRESS 수

완료 간극 발생 수

복구 성공·거부·실패 수

거래 최종 처리시간

금지된 상태 전이 요청 수

️ 운영 복구 원칙

불확실 상태의 자동 재분석 금지
Scheduler·Batch로 무조건 반복 복구하지 않기
승인된 내부 Record 하나만 대상으로 처리
복구 과정에서 외부 서비스 재호출 금지
실행 주체·시각·판정·결과를 감사 가능하게 기록

검증할 Acceptance Criteria

같은 Key·같은 요청을 동시에 두 번 보내도 거래는 하나만 생성되는가
같은 Key에 다른 거래 내용을 보내면 충돌하는가
COMPLETED 재요청에서 External Risk와 FastAPI가 다시 호출되지 않는가
애플리케이션 재시작 뒤에도 Snapshot을 재생할 수 있는가
Rolling Update 중 구버전 Snapshot을 신버전이 해석할 수 있는가
업무 Commit 뒤 Snapshot 저장이 실패해도 거래와 사건을 다시 실행하지 않는가
허용되지 않은 거래·사건 상태 전이가 거부되는가
동시 사건 종료 요청이 서로의 판정을 조용히 덮어쓰지 않는가
AI 리포트 실패가 거래 상태와 사건 최종 판정을 변경하지 않는가
복구 실행의 주체·판정·결과가 감사 가능하게 남는가

상태 계약을 AI Agent가 임의로 바꾸지 못하게 하는 이유

거래 상태, 사건 상태, 허용 전이, Fingerprint 구성과 Snapshot 버전은 API·DB·테스트·운영 복구 절차에 동시에 영향을 주는 핵심 계약입니다.

AI Agent는 구현·테스트·문서 초안을 만들 수 있지만, 새로운 상태 추가, 허용 전이 변경, Fingerprint 필드 변경, Snapshot 버전 전환과 DB Migration을 임의로 확정할 수 없도록 합니다.

ADR 승인
→ API 영향 검토
→ DB Migration 검토
→ 구버전 호환성 확인
→ 단위·통합·동시성 테스트
→ 사용자 최종 승인
→ Pull Request merge

생성형 AI와 AI Agent는 상태 계약을 구현하는 도구이며, 금융 업무 규칙과 호환성·배포 승인 권한을 대신하지 않습니다.

12. 마치며: 상태 모델을 데이터베이스로 옮기기

FinGuardOps에서는 거래 처리 단계, 위험 분석 결과, 대응 정책, 사건 조사 단계, 최종 판정과 멱등 명령 상태를 서로 분리했습니다.

이를 통해 하나의 status에 여러 의미가 섞여 모순된 상태 조합이 만들어지는 문제를 줄이고, 각 상태의 변경 조건과 책임자를 명확하게 정의할 수 있습니다.

FinGuardOps의 정합성 설계


    상태 전이
    → 업무가 어디까지 확정됐는지 표현

    멱등성
    → 같은 명령의 중복 실행 통제

    Response Snapshot
    → 최초 확정 결과 재현

    완료 간극 복구
    → 업무를 재실행하지 않고 누락된 응답만 복원

    영속 멱등 Record
    → 여러 Pod·재시작·Rolling Update에서도 계약 유지

상태와 멱등성 규칙을 정의한 다음에는 이 규칙을 애플리케이션 코드뿐 아니라 데이터베이스 제약조건으로도 강제해야 합니다.

다음 글에서는 거래, 행동 이벤트, 탐지 결과, RuleVersion, 사건, 감사 로그와 멱등성 Record를 어떤 관계로 설계했는지 PostgreSQL ERD와 Flyway Migration 기준을 정리하겠습니다.

[FinGuardOps #4] 금융 업무 정합성을 지키는 ERD·PostgreSQL·Flyway 설계
거래·행동 이벤트·탐지 결과·사건·감사 로그·멱등성 Record의 관계와 Foreign Key, Unique, Check Constraint, Index와 Migration 전략을 정리합니다.

GitHub에서 FinGuardOps 저장소 보기

[FinGuardOps #2] 전체 시스템 구성과 기술별 역할을 어떻게 나눴는가

bbbicsan — Sun, 30 Aug 2026 19:14:25 +0900

FinGuardOps Project Series #2

지난 글에서는 금융 이상거래 탐지에서 끝나지 않고 위험 대응, 사건 처리와 AI 운영까지 연결하는 FinGuardOps를 기획한 이유를 정리했습니다.

프로젝트의 주제와 범위를 정한 다음에는 각 구성요소가 무엇을 책임하고, 어떤 데이터의 원본을 어디에서 관리할지 결정해야 했습니다.

금융 업무 상태와 AI 계산을 하나의 애플리케이션에 모두 넣을지, 처음부터 전체 시스템을 마이크로서비스로 분리할지, PostgreSQL·Redis·Kafka는 각각 어떤 역할을 가져야 할지 고민했습니다.

이 과정에서 기술을 많이 사용하는 것보다 금융 업무 정합성, 계산 책임, 데이터 소유권과 장애 경계를 명확히 나누는 것 을 우선했습니다.

금융 업무 상태의 최종 책임은 Spring Boot가 가지고, FastAPI는 분석 결과 계산을 담당하며, PostgreSQL은 영속 업무 데이터의 원본이 되도록 전체 구조를 설계했습니다.

그림 1. 금융 업무, AI 분석, 데이터, 인프라와 Observability의 책임을 계층별로 구분한 FinGuardOps의 목표 시스템 구성

이 글은 특정 날짜의 구현 현황을 정리하는 글이 아니라, FinGuardOps를 기획하면서 정한 목표 아키텍처, 기술별 책임과 Cloud Application Modernization 전략을 소개하는 글입니다. 실제 운영 중인 레거시 시스템을 직접 이전했다고 주장하기보다, 금융 업무 애플리케이션을 컨테이너·CI/CD·Observability·Kubernetes·AWS 기반으로 단계적으로 현대화하는 기준을 설명합니다.

전체 구조를 설계하며 세운 기준
️ FinGuardOps의 전체 시스템 흐름
☕ Backend — Spring Boot Modular Monolith
AI Service — FastAPI
️ Frontend — React와 TypeScript
️ Data와 External Service
☁️ Infra·DevOps·Cloud와 Observability
시스템 사이의 책임과 장애 경계
처음부터 전체 MSA로 구성하지 않은 이유
️ 단계별 개발 로드맵과 검증 방향
마치며: 다음은 상태 전이와 멱등성

1. 전체 구조를 설계하며 세운 기준

FinGuardOps의 아키텍처는 사용하고 싶은 기술을 먼저 정한 뒤 기능을 끼워 맞추는 방식으로 설계하지 않았습니다.

먼저 금융 이상거래 탐지와 사건 처리 과정에서 반드시 지켜야 할 원칙을 정하고, 각 원칙을 실현하는 데 적합한 구성요소와 기술을 선택했습니다.

☁️ Modernization은 단순 Cloud 이전이 아니다

애플리케이션을 클라우드에 올리는 것만으로 Modernization이 완성된다고 보지 않았습니다. 실행 환경 표준화, 자동화된 검증과 배포, 관측 가능성, 장애 격리, 서비스별 확장, 데이터 소유권과 운영 비용까지 함께 바꾸는 것을 목표로 구조를 설계했습니다.

금융 업무 정합성

거래, 탐지 결과, 위험 대응, 사건과 감사 로그가 중복되거나 일부만 반영되어서는 안 됩니다.

중복 거래와 중복 사건 방지
허용된 상태 전이만 수행
연관 업무 데이터의 함께 Commit 또는 Rollback
최종 결과와 감사 이력의 일관성 유지

계산과 업무 결정의 분리

Rule·ML과 생성형 AI는 분석 결과를 계산하지만 금융 업무 상태를 직접 확정하지 않습니다.

FastAPI는 위험 점수와 탐지 근거 계산
Spring Boot는 분석 결과 계약 검증
승인된 위험 대응 정책 적용
거래·사건 상태의 최종 변경

️ 명확한 데이터 소유권

각 저장 기술의 역할을 분리하고, 업무 데이터의 원본이 여러 곳에 흩어지지 않도록 설계했습니다.

PostgreSQL은 영속 업무 데이터 원본
Redis는 재생성 가능한 캐시와 집계
Kafka는 비동기 이벤트 전달
Observability는 기술 상태 관측

장애 범위의 분리

의존성마다 시스템에 미치는 영향이 다르므로 모든 장애를 하나의 실패로 처리하지 않습니다.

DB 장애와 분석 서비스 장애 구분
캐시 장애와 업무 데이터 유실 구분
LLM 실패와 Rule·ML 판단 실패 구분
관측 시스템 실패와 금융 업무 실패 구분

핵심 업무부터 단계적으로 확장

Docker, Kafka, Kubernetes와 AWS를 사용하는 사실보다 각 기술이 어떤 문제를 해결하기 위해 필요한지를 설명할 수 있어야 한다고 판단했습니다.


    핵심 거래·탐지·사건 흐름
    → PostgreSQL 기반 업무 정합성
    → Docker Compose 기반 통합 실행
    → Observability
    → Redis·Kafka 기반 확장
    → Kubernetes 운영
    → AWS 클라우드 배포

처음부터 모든 기술을 동시에 적용하면 금융 업무 로직보다 인프라 설정과 분산 시스템 문제가 프로젝트의 중심이 될 수 있습니다.

따라서 핵심 거래·탐지·사건 흐름을 먼저 설계하고, 그 위에 로컬 통합 환경, 관측, 비동기 처리, 컨테이너 오케스트레이션과 클라우드 운영을 단계적으로 확장하는 방향으로 구상했습니다.

️ 2. FinGuardOps의 전체 시스템 흐름

FinGuardOps는 FDS 분석 담당자와 플랫폼·클라우드 운영자가 React 관리자 화면을 통해 금융 업무와 플랫폼 운영 정보를 확인하는 구조로 구상했습니다.

Spring Boot는 금융 업무 처리의 중심에서 PostgreSQL, External Risk와 FastAPI AI Service를 조정합니다.

FDS 분석 담당자 / 플랫폼·클라우드 운영자
                    ↓
            React + TypeScript
                    ↓ REST API
       Spring Boot Modular Monolith
          ├─ PostgreSQL
          ├─ External Risk Service
          ├─ Redis
          ├─ Kafka
          └─ FastAPI AI Service
                 ├─ Rule Engine
                 ├─ ML Inference
                 └─ AI Report·Fallback

Spring Boot / FastAPI / Data / Messaging
                    ↓
          Metrics · Logs · Traces
                    ↓
Prometheus · Grafana · Loki · OpenTelemetry

서비스 실행·배포 환경
→ Docker Compose · Kubernetes · AWS · GitHub Actions

거래 요청의 기본 처리 흐름

핵심 거래 처리 흐름은 다음과 같이 설계했습니다.

거래 요청과 Idempotency-Key를 검증합니다.
동일 요청을 식별하기 위한 Request Fingerprint를 계산합니다.
동일 멱등 요청 중 하나만 실제 업무 처리를 수행하도록 제어합니다.
금융 거래를 PostgreSQL에 저장하고 초기 상태를 확정합니다.
External Risk Service에서 외부 위험정보를 조회합니다.
거래·행동 이벤트·RuleVersion을 분석 Snapshot으로 구성합니다.
FastAPI에 Rule·ML 분석을 요청합니다.
Spring Boot가 분석 결과의 버전과 완전성을 검증합니다.
위험도별 대응을 적용하고 필요한 사건을 생성합니다.
최종 결과와 감사 이력을 저장하고 중복 요청에는 동일한 응답을 재생합니다.

External Risk와 FastAPI 호출은 긴 DB 트랜잭션 안에서 실행하지 않는 방향으로 설계했습니다.

외부 응답을 기다리는 동안 거래 잠금과 DB Connection을 계속 점유하지 않도록 짧은 영속화 트랜잭션과 외부 호출 경계를 분리합니다.

☕ 3. Backend — Spring Boot Modular Monolith

Spring Boot는 FinGuardOps에서 요청을 전달하기만 하는 단순 API Gateway가 아닙니다.

거래·탐지·위험 대응·사건·감사로 이어지는 금융 업무의 최종 책임 을 담당하도록 설계했습니다.

☕ Spring Boot가 담당할 책임

거래·행동 이벤트 요청 검증
거래 요청 멱등성 처리
거래와 탐지 결과 상태 전이
External Risk 조회 오케스트레이션
FastAPI 분석 요청과 Trace 전달
분석 응답의 요청 연결·버전·완전성 검증
위험 등급별 대응 정책 적용
HIGH·CRITICAL 거래의 사건 생성과 연결
상태 변경과 의사결정의 감사 로그 기록
최종 응답 Snapshot 저장과 멱등 재생
AI 리포트 상태와 사용량·토큰·비용 영속화

왜 Modular Monolith로 시작하는가

거래, 탐지 결과, 위험 대응, 사건과 감사 로그는 서로 완전히 독립적인 데이터가 아닙니다.

고위험 거래를 추가 인증 상태로 전환하면서 사건을 생성하고 감사 로그를 남겨야 한다면, 이러한 변경은 함께 성공하거나 함께 Rollback되어야 합니다.

이를 처음부터 여러 서비스로 분리하면 다음 문제를 핵심 업무 구현과 동시에 해결해야 합니다.

분산 트랜잭션과 최종 일관성
중복 이벤트와 Consumer 멱등성
서비스 간 네트워크 실패
부분 성공에 대한 보상 처리
독립 배포와 장애 대응 체계
서비스별 데이터 소유권 분리

초기 구조에서는 이 복잡성보다 금융 업무 흐름의 완성도를 우선하기 위해 하나의 Spring Boot 애플리케이션 안에서 논리적인 모듈 경계를 유지하는 Modular Monolith를 선택했습니다.

transaction
거래 접수·검증·멱등성

behavior
사용자 행동 이벤트

detection
분석 요청과 결과 관리

risk response
위험도별 대응 정책

case management
사건 생성·조사·판정

audit
주요 변경 이력

rule management
Rule·정책 버전 관리

AI operations
리포트·사용량·비용

Spring Boot는 FastAPI가 반환한 위험 점수를 그대로 거래 상태에 적용하지 않습니다. 거래 처리 상태, 분석 결과 버전, 탐지 근거와 승인된 대응 정책을 검증한 뒤 금융 업무 상태를 변경합니다.

4. AI Service — FastAPI

FastAPI AI Service는 금융 업무 상태를 직접 변경하는 서비스가 아니라 분석 결과를 계산하는 독립 서비스로 구성합니다.

Python의 데이터 처리와 AI 생태계를 활용하면서도 AI 코드 변경이 금융 업무 상태를 직접 변경하지 못하도록 Spring Boot와 별도 프로세스로 분리했습니다.

✅ FastAPI의 책임

Feature 계산
Rule 실행
ML 추론
위험 점수와 위험 등급 계산
Reason Code와 Evidence 생성
모델 라우팅
AI 사건 리포트 생성
Rule·ML 기반 템플릿 fallback

FastAPI가 하지 않는 일

거래 상태 직접 변경
사건 직접 생성
사건 상태 직접 변경
최종 이상거래 판정
거래 승인·보류·추가 인증 결정
Spring Boot 업무 데이터 직접 영속화
Rule 활성 상태와 버전 원본 변경

⚙️ 초기 Rule 분석 범위

고액 거래와 주요 행동 이벤트를 분석하는 초기 Rule 집합
RuleVersion 기반 실행 계획
같은 입력에 같은 결과를 반환하는 결정적 Rule 평가
가중치와 그룹 상한을 이용한 위험 점수 계산
Reason Code와 설명 가능한 Evidence 생성
Spring Boot와 통신하기 위한 내부 분석 API
Trace와 요청·응답 계약 검증

확장할 AI 분석 범위

복합 패턴을 보완하는 ML 모델 추론과 평가
HIGH·CRITICAL 사건 중심 생성형 AI 리포트
LLM Provider 연동
사건 복잡도 기반 모델 라우팅
LLM 실패 시 Rule·ML 기반 템플릿 fallback
입력·출력 토큰과 호출 비용 측정
리포트 형식과 품질 검증

AI Service는 설명 가능하고 테스트하기 쉬운 Rule 분석을 첫 단계로 두고, 이후 ML과 생성형 AI 리포트를 추가하는 방향으로 구성합니다.

생성형 AI는 위험 판단을 대신하는 것이 아니라 고위험 사건을 검토하는 담당자의 이해를 돕는 보조 수단으로 사용합니다.

️ 5. Frontend — React와 TypeScript

Frontend는 FinGuardOps의 두 사용자 역할에 맞춰 FDS 업무 화면과 플랫폼 운영 화면으로 구분합니다.

️ FDS 분석 담당자 화면

거래 모니터링과 위험 거래 필터링
위험 점수와 위험 등급 확인
Rule·ML 탐지 Evidence
사용자 행동 타임라인
사건 대기열과 사건 상세
조사 메모와 담당자 관리
정상·오탐·이상거래 판정
감사 이력과 AI 사건 리포트

️ 플랫폼·클라우드 운영자 화면

서비스 Health와 배포 버전
오류율·처리량과 지연시간 요약
External Risk·Rule·ML·LLM 상태
AI 모델별 호출량과 비용
캐시 적중률과 fallback 비율
장애·대응·복구 이력
배포 이력과 업무 영향 요약

React와 Grafana의 역할 구분

️ React 관리자 화면

거래와 사건 업무 상태
조사 메모와 최종 판정
Rule과 운영 정책
AI 비용·장애·배포 이력 요약

Grafana

서비스별 응답시간
오류율과 처리량
DB Connection Pool
Kafka Consumer Lag
런타임·인프라 시계열 지표

React는 금융 업무와 운영 이력을 처리하는 제품 화면을 담당하고, Grafana는 기술 지표를 시계열로 분석하는 관측 화면을 담당합니다. 동일한 대시보드를 두 영역에 중복 구현하지 않는 것이 원칙입니다.

️ 6. Data와 External Service

FinGuardOps에서는 PostgreSQL, Redis와 Kafka를 모두 같은 종류의 데이터 저장소로 취급하지 않습니다.

영속 업무 데이터의 원본, 재생성 가능한 캐시, 비동기 이벤트 전달 책임을 명확하게 구분했습니다.

PostgreSQL — 영속 업무 데이터의 원본

PostgreSQL은 거래·탐지·사건과 감사 데이터를 보관하는 FinGuardOps의 정합성 기준으로 사용합니다.

금융 거래와 행동 이벤트
멱등성 Record와 응답 Snapshot
탐지 결과와 Evidence
Rule 정의와 RuleVersion
사건과 거래 연결
조사 메모와 Append-only 감사 로그
AI 리포트와 사용량·토큰·비용

External Risk — 외부 위험정보 경계

실제 금융권 위험정보 API와 데이터를 사용할 수 없는 제약을 보완하기 위해 위험계좌·위험 기기·위험 IP 등의 정보를 제공하는 외부 의존성을 별도 경계로 둡니다.

로컬·테스트용 결정적 Mock
실제 연동 구조를 재현하는 HTTP Provider
Port와 Adapter 기반 외부 연동 분리
Timeout·Unavailable·Invalid Response 시나리오
외부 위험정보 실패와 Rule 분석 실패의 분리

Redis — 재생성 가능한 캐시와 집계

Redis는 거래와 사건의 원본 저장소로 사용하지 않습니다. PostgreSQL의 원본에서 다시 계산하거나 조회할 수 있는 데이터만 보관합니다.

동일 사건·동일 분석 조건의 정확 일치 AI 리포트 캐시
재생성 가능한 운영 집계
필요성과 장애 정책이 확정되면 External Risk 캐시 검토

caseId
+ detectionResultVersion
+ promptVersion
+ modelVersion

Reason Code가 같거나 내용이 유사하다는 이유만으로 다른 사건의 AI 리포트를 재사용하지 않습니다.

⚫ Kafka — 비동기 이벤트 전달

Kafka는 핵심 동기 금융 판단을 대신하는 것이 아니라, 사용자 응답 경로에서 분리해야 하는 작업을 비동기로 전달하기 위해 사용합니다.

AI 사건 리포트 생성 요청
사건 관련 도메인 이벤트
운영 통계 집계 이벤트
장애와 배포 관련 운영 이벤트

Kafka를 도입할 때는 Producer와 Consumer만 구현하는 데서 끝내지 않고 Consumer 멱등성, 중복 이벤트, 순서, Consumer Lag, 재처리와 DLQ를 함께 검증합니다.

PostgreSQL은 업무 데이터의 원본이고, Redis는 재생성 가능한 캐시이며, Kafka는 비동기 이벤트 전달 수단입니다. 세 기술은 서로 대체 관계가 아닙니다.

☁️ 7. Infra·DevOps·Cloud와 Observability

FinGuardOps에서 인프라는 애플리케이션을 마지막에 배포하기 위한 부가 요소가 아닙니다.

장애 복구, 반복 가능한 실행 환경, 배포 안정성, 서비스 확장과 운영 상태 관측을 검증하기 위한 프로젝트의 핵심 영역으로 포함했습니다.

애플리케이션 실행 → 컨테이너 통합 → 자동화된 검증 → 오케스트레이션 → 클라우드 운영 → 장애·성능·비용 검증

Docker Compose

Spring Boot, FastAPI, PostgreSQL, Redis, Kafka와 Observability 구성요소를 동일한 로컬 환경에서 반복 실행합니다.

개발·테스트 환경 재현
서비스 간 네트워크 구성
환경 변수와 Volume 관리
Health Check와 시작 순서 검증

☸️ Kubernetes

컨테이너 기반 구성을 서비스 단위로 배포하고 복구·확장·Rolling Update를 검증합니다.

Deployment와 Service 구성
Replica와 장애 복구
Rolling Update와 Rollback
Config·Secret 분리
Resource Request·Limit

☁️ AWS

로컬과 Kubernetes 환경에서 검증한 구조를 클라우드 운영 환경으로 확장합니다.

애플리케이션과 데이터 계층 배포
네트워크·보안·접근 경계
관리형 데이터베이스와 저장소 검토
클라우드 로그·메트릭 연계
배포 전후 운영 상태 검증

GitHub Actions

Issue와 Pull Request 흐름에 자동 테스트, 이미지 생성과 배포 검증을 연결합니다.

Backend 단위·통합 테스트
AI Service lint·format·pytest
Container Image Build와 보안 검사
Image Registry Push
Kubernetes 배포와 이력 관리
승인된 Issue를 기준으로 한 AI Agent 작업
테스트·리뷰·사용자 승인 Human Gate

Observability

거래 요청이 어느 단계에서 지연되거나 실패했는지 확인하기 위해 메트릭, 로그와 분산 추적을 서로 다른 관측 신호로 사용합니다.

Prometheus
API·Rule·ML·LLM 지연시간, 오류율, 처리량과 비용 메트릭 수집

Grafana
기술 시계열 대시보드, 장애 분석과 배포 전후 비교

Loki
Spring Boot·FastAPI·인프라의 구조화 로그 수집과 검색

OpenTelemetry
거래 요청이 여러 구성요소를 거치는 흐름과 지연 구간 추적

인프라와 Observability는 단순히 서비스가 실행된다는 사실을 보여주기 위한 것이 아닙니다.

Timeout, DB Pool 고갈, Kafka Consumer 중단, LLM 장애와 비용 급증 같은 시나리오를 주입하고, 어떤 지표로 탐지했는지와 어떻게 복구했는지를 검증하기 위해 사용합니다.

8. 시스템 사이의 책임과 장애 경계

FinGuardOps에서 가장 중요하게 정한 원칙은 계산, 업무 결정, 원본 저장, 캐시와 관측 책임을 섞지 않는 것입니다.

계산 책임 ≠ 업무 결정 책임 ≠ 데이터 원본 ≠ 캐시 ≠ 기술 관측

☕ Spring Boot
검증·상태 전이·위험 대응·사건·감사·영속화

FastAPI
Rule·ML·점수·Reason Code·Evidence·AI 리포트 계산

PostgreSQL
거래·탐지·사건·감사 업무 데이터 원본

Redis
정확 일치 캐시와 재생성 가능한 집계

⚫ Kafka
비동기 사건·리포트·통계·운영 이벤트

⚛️ React
분석 담당자와 운영자를 위한 업무 화면

Observability
지연시간·오류율·처리량·로그·Trace·비용 관측

☁️ Infra·Cloud
실행·배포·복구·확장과 운영 환경 제공

장애를 정상 결과로 바꾸지 않는 원칙

External Risk 실패 ≠ 위험정보 없음

FastAPI 실패 ≠ 정상 거래

Redis 실패 ≠ 업무 데이터 유실

LLM 실패 ≠ Rule·ML 판단 실패

메트릭 기록 실패 ≠ 금융 업무 실패

External Risk와 FastAPI가 실패하면 이를 정상 또는 저위험 결과로 바꾸지 않습니다. 오류가 발생한 단계와 종류를 보존하고 해당 업무 경계에 맞는 실패 상태로 처리합니다.

반대로 Redis와 LLM은 핵심 금융 업무 데이터의 원본이 아닙니다. 캐시나 AI 리포트가 실패해도 이미 계산된 Rule·ML 판단과 확정된 거래·사건 결과를 변경하지 않습니다.

9. 처음부터 전체 MSA로 구성하지 않은 이유

프로젝트 초기부터 모든 기능을 마이크로서비스로 분리하면 기술적으로 더 복잡한 구조를 보여줄 수는 있습니다.

하지만 거래, 탐지 결과, 위험 대응, 사건과 감사 로그는 강한 업무 정합성을 요구합니다.

이를 여러 서비스와 데이터베이스로 분리하면 핵심 금융 업무를 구현하기 전에 분산 트랜잭션과 이벤트 일관성 문제부터 해결해야 합니다.

⚠️ 처음부터 전체 MSA일 때 생기는 문제

분산 트랜잭션
서비스 간 부분 실패
이벤트 중복과 순서
보상 트랜잭션
서비스별 배포·관측 환경
데이터 소유권 조정

✅ 초기 아키텍처

Spring Boot Modular Monolith
독립 FastAPI AI Service
PostgreSQL 업무 데이터 원본
External Risk Mock·HTTP 경계
로컬 트랜잭션 기반 정합성 관리
명확하게 구분된 장애 경계

서비스를 분리할 기준

다음 조건이 실제로 발생했을 때 특정 논리 모듈을 별도 서비스로 분리합니다.

독립 배포 요구가 반복적으로 발생하는가
특정 모듈만 독립적으로 확장해야 하는가
서비스 분리로 얻는 장애 격리 효과가 명확한가
데이터 소유권을 독립적으로 분리할 수 있는가
독립 팀이 해당 영역을 운영하는가
분산 트랜잭션과 운영 비용을 감수할 근거가 있는가

MSA를 고려하지 않은 것이 아니라, 핵심 금융 업무 정합성을 먼저 검증한 뒤 분리가 필요한 영역만 단계적으로 확장하기로 한 것입니다.

️ 10. Cloud Application Modernization 로드맵과 검증 방향

FinGuardOps는 전체 목표 구조를 한 번에 구현하거나 단순히 클라우드로 옮기는 방식보다, 각 단계에서 해결해야 할 애플리케이션과 운영 문제를 정의하고 검증한 뒤 다음 영역으로 확장하는 방식으로 진행합니다.

1단계. 금융 업무 기반

거래와 행동 이벤트
상태 전이와 멱등성
Rule 기반 탐지
위험도별 대응
사건 생성과 감사 로그
PostgreSQL 트랜잭션 검증

2단계. 서비스 연동

Spring Boot와 FastAPI 연동
External Risk Service
RuleVersion과 Evidence
Timeout과 오류 계약
서비스 간 Trace 전달
장애 전파와 복구 경계

3단계. 로컬 운영 환경

Docker와 Docker Compose
서비스 Health Check
Prometheus와 Grafana
Loki와 OpenTelemetry
React 관리자 화면
CI 자동화

4단계. 비동기·AI 운영

Redis 정확 일치 캐시
Kafka 비동기 이벤트
ML 복합 패턴 분석
생성형 AI 사건 리포트
모델 라우팅과 fallback
AI 토큰·비용·품질 측정

5단계. Cloud Native 확장

Container Image Pipeline
Kubernetes 배포와 복구
AWS 클라우드 환경
Rolling Update와 Rollback
Config·Secret·리소스 관리
클라우드 E2E 검증

6단계. 장애·비용 실험

External Service Timeout
Redis·Kafka·DB 장애
Consumer Lag과 재처리
LLM 오류와 fallback
배포 전후 성능 비교
AI FinOps 실험과 회고

전 단계에 공통으로 적용하는 AI-assisted Delivery

Sprint Goal과 GitHub Issue
→ ADR·API·DB 계약 확인
→ AI Agent 구현·테스트·문서 초안
→ 자동 테스트와 정적 검사
→ 독립 Review
→ 사용자 승인
→ Pull Request merge
→ 배포와 운영 검증

AI Agent는 승인된 작업 범위 안에서 초안을 만들고 반복 작업을 지원하지만, API·DB·아키텍처 변경, Secret 접근, Production 배포와 최종 Merge를 임의로 수행하지 못하도록 Human-in-the-loop Gate를 유지합니다.

각 단계에서 확인할 기준

정상 흐름뿐 아니라 경계값과 실패 흐름을 테스트했는가
중복 요청과 동시성 충돌을 검증했는가
외부 장애가 어느 업무까지 영향을 주는지 구분했는가
로그·메트릭·트레이스로 장애 위치를 확인할 수 있는가
배포 후 Health와 핵심 업무 흐름을 다시 검증했는가
AI의 호출량·토큰·지연시간·비용을 실제로 측정했는가
측정하지 않은 향상이나 절감률을 성과로 표현하지 않았는가

이 로드맵의 핵심은 기술을 정해진 순서로 단순히 추가하는 것이 아닙니다.

앞 단계의 업무와 운영 문제를 충분히 검증한 뒤, 다음 기술이 해결해야 할 필요를 명확하게 만든 상태에서 확장하는 것입니다.

11. 마치며: 다음은 상태 전이와 멱등성

FinGuardOps의 전체 구조는 다양한 기술을 많이 사용하는 것을 목표로 설계한 구조가 아닙니다.

금융 업무 정합성, 사용자 화면, 분석 계산, 데이터 원본, 캐시, 비동기 처리, 실행·배포 환경과 기술 관측의 책임을 나누고 각 책임에 적합한 기술을 배치한 구조입니다.

이를 통해 Java·Spring Boot와 React 기반의 업무 애플리케이션, FastAPI 기반 AI Service, Cloud Native 운영 환경, 그리고 생성형 AI·AI Agent를 통제 가능한 개발 프로세스에 적용하는 방식을 하나의 Modernization 흐름으로 연결하고자 했습니다.

FinGuardOps의 핵심 책임 분리


    Spring Boot
    → 금융 업무 상태와 영속화

    FastAPI
    → Rule·ML·AI 분석 계산

    PostgreSQL
    → 영속 업무 데이터 원본

    Redis
    → 재생성 가능한 캐시

    Kafka
    → 비동기 이벤트 전달

    Docker·Kubernetes·AWS
    → 실행·배포·복구·확장 환경

    Observability
    → 장애·성능·비용 관측

전체 구성요소의 역할을 나눈 뒤에는 거래와 사건이 어떤 상태를 가지고, 어떤 조건에서 다음 상태로 이동할 수 있는지 정의해야 했습니다.

특히 동일한 요청이 반복되었을 때 중복 거래와 중복 사건을 방지하고, 처리 결과를 안전하게 재생하기 위한 멱등성 설계가 필요했습니다.

[FinGuardOps #3] 재시도와 장애에도 안전한 거래·사건 상태 전이와 멱등성 설계
거래와 사건의 상태를 어떻게 분리하고, Idempotency-Key·Request Fingerprint·Response Snapshot으로 중복 요청을 어떻게 통제할 것인지 정리합니다.

GitHub에서 FinGuardOps 저장소 보기

[FinGuardOps #1] 금융 이상거래 탐지를 넘어 FraudOps 플랫폼을 기획한 이유

bbbicsan — Sun, 30 Aug 2026 14:20:11 +0900

FinGuardOps Project Series #1

처음에는 금융 거래 데이터를 분석해 이상거래를 탐지하는 프로젝트를 만들려고 했습니다. 거래 정보를 입력하면 Rule이나 모델이 위험 점수를 계산하고, 그 결과를 화면에서 확인할 수 있는 형태를 생각했습니다.

하지만 프로젝트의 범위를 구체화할수록 위험 점수를 계산하는 것만으로 실제 FDS 업무가 완성되는 것은 아니다 라는 생각이 들었습니다.

위험하다고 탐지된 거래를 이후에 어떻게 처리할지, 담당자는 어떤 근거를 바탕으로 거래를 검토할지, 같은 요청이 여러 번 들어왔을 때 중복 거래와 중복 사건을 어떻게 막을지까지 함께 고민해야 했습니다.

AI와 외부 서비스를 시스템에 연결하면 또 다른 문제도 생깁니다. 외부 위험정보 조회가 지연되거나 AI 서비스가 응답하지 않을 수 있고, 생성형 AI를 사용한다면 호출량과 토큰 비용도 관리해야 합니다.

정상적인 분석 결과만 보여주는 것에서 끝나지 않고 장애, 복구, 성능과 비용까지 운영할 수 있는 구조가 필요했습니다. 이러한 문제를 하나의 흐름으로 구현하기 위해 단순 금융 이상거래 탐지 시스템에서 범위를 확장하여 FinGuardOps를 기획했습니다.

FinGuardOps는 금융거래와 사용자 행동을 기반으로 이상거래를 탐지하고, 위험 대응과 사건 처리를 지원하며, AI 서비스의 장애·성능·비용을 통합 관리하는 Cloud Native 금융 AI FraudOps 플랫폼입니다.

프로젝트를 시작하게 된 배경
왜 금융 이상거래 탐지를 선택했는가
단순 이상거래 탐지 프로젝트에서 느낀 한계
️ FDS에서 FraudOps 플랫폼으로
FinGuardOps가 해결하려는 문제
프로젝트의 주요 사용자
프로젝트의 목표와 제외 범위
생성형 AI를 개발에 활용하는 방식
마치며: 이제 전체 구조를 설계할 차례

1. 프로젝트를 시작하게 된 배경

백엔드와 클라우드를 공부하면서 각 기술을 개별 실습으로 끝내지 않고 하나의 서비스 안에서 연결해 보고 싶었습니다.

단순한 CRUD API를 만드는 것을 넘어 트랜잭션, 상태 전이, 동시성, 외부 서비스 연동과 장애 복구 같은 문제를 직접 다뤄 보고 싶었습니다.

서비스가 정상적으로 동작하는 모습만 구현하는 것도 중요하지만, 실제 운영 환경에서는 동일한 요청이 반복되거나 외부 서비스가 제한 시간 안에 응답하지 않는 상황도 발생합니다.

DB에는 일부 데이터만 저장되었는데 클라이언트에는 실패 응답이 전달될 수도 있고, 처리가 끝났지만 응답을 받지 못한 사용자가 같은 요청을 다시 보낼 수도 있습니다.

프로젝트 주제를 정할 때 세운 기준

데이터 정합성과 상태 관리가 중요한 도메인
중복 요청과 동시성 문제를 자연스럽게 다룰 수 있는 도메인
Java 백엔드와 Python 분석 서비스를 연결할 수 있는 도메인
정상 흐름뿐 아니라 장애와 복구 과정까지 검증할 수 있는 도메인
로그·메트릭·트레이싱과 클라우드 운영으로 확장할 수 있는 도메인

이 조건을 가장 잘 보여줄 수 있는 주제로 금융 이상거래 탐지 시스템을 선택했습니다.

금융 거래는 한 번의 중복 처리나 잘못된 상태 변경도 중요한 문제로 이어질 수 있습니다. 또한 Rule과 ML을 이용한 분석 결과를 실제 업무 흐름과 연결하기에도 적합하다고 판단했습니다.

2. 왜 금융 이상거래 탐지를 선택했는가

2.1 높은 데이터 정합성이 요구되는 도메인

게시글이나 댓글처럼 수정하거나 다시 생성할 수 있는 데이터와 달리, 금융 거래는 중복 처리와 잘못된 상태 변경을 더욱 엄격하게 통제해야 합니다.

클라이언트가 같은 거래 요청을 두 번 보냈다고 해서 거래가 두 건 생성되거나 고위험 사건이 중복으로 만들어져서는 안 됩니다.

또한 하나의 요청이 여러 처리 단계를 거치는 동안 각 상태가 일관성 있게 변경되어야 합니다. 거래 분석은 실패했는데 거래 상태가 정상 완료로 남거나, 사건은 생성되었지만 해당 거래와 연결되지 않는 상황도 방지해야 합니다.


      트랜잭션
      → 멱등성
      → 상태 전이
      → 동시성 제어
      → 중복 방지
      → 감사 로그
      → 장애 복구

2.2 위험 점수만큼 탐지 근거가 중요한 도메인

이상거래 탐지 결과가 단순히 위험 확률 87% 또는 위험 점수 70점으로만 제공된다면, 담당자는 해당 거래가 왜 위험한지 판단하기 어렵습니다.

실제 검토를 지원하려면 다음과 같은 근거를 함께 제공해야 합니다.

평소보다 큰 금액이 거래되었는가
최근 등록된 기기에서 발생한 거래인가
비밀번호나 이체 한도가 변경된 직후인가
최근 등록된 수취인에게 송금했는가
외부 위험계좌·IP·기기 정보와 일치하는가
짧은 시간 안에 유사한 거래가 반복되었는가

따라서 FinGuardOps에서는 위험 점수만 반환하는 것이 아니라 Rule·ML 판단 근거와 행동 타임라인을 함께 제공하는 구조를 목표로 정했습니다.

탐지 결과는 담당자의 판단을 지원하는 정보이며, 최종 이상거래 판정을 자동으로 대신하지 않습니다.

2.3 백엔드·AI·클라우드를 연결할 수 있는 도메인

금융 이상거래 탐지는 하나의 기술만으로 완성되는 기능이 아닙니다.

거래를 접수하고 상태를 관리하는 백엔드, Rule과 ML을 실행하는 분석 서비스, 업무 데이터를 저장하는 데이터베이스, 외부 위험정보와 운영 인프라가 함께 연결되어야 합니다.

하나의 업무 흐름에서 연결하고자 한 영역

Java·Spring Boot 백엔드
→ Python·FastAPI 분석 서비스
→ PostgreSQL 기반 업무 데이터
→ 외부 위험정보 연동
→ 로그·메트릭·트레이싱
→ Docker·Kafka·Kubernetes·AWS의 단계적 도입

☁️ Cloud Application Modernization 관점

FinGuardOps는 금융 FDS 기능을 구현하는 것뿐 아니라, 하나의 업무 애플리케이션을 컨테이너 표준화, CI/CD, Observability, 비동기 처리, Kubernetes와 AWS로 단계적으로 확장하는 과정을 함께 다루기 위해 기획했습니다.

실제 운영 중인 레거시 금융 시스템을 이전했다고 주장하는 프로젝트는 아닙니다. 대신 금융 업무 정합성을 먼저 확보한 뒤 실행 환경과 배포 방식, 관측 체계와 복구 전략을 점진적으로 현대화하는 Cloud Application Modernization 전략을 설계하고 검증하는 것을 목표로 합니다.

3. 단순 이상거래 탐지 프로젝트에서 느낀 한계

처음 구상했던 이상거래 탐지 프로젝트의 흐름은 비교적 단순했습니다.

거래 데이터 입력
→ Rule 또는 ML 모델 실행
→ 위험 점수 출력
→ 종료

이 구조만으로도 Rule이나 모델이 거래를 어떻게 분류하는지는 보여줄 수 있습니다. 하지만 실제 FDS 업무를 생각하면 탐지 이후에 많은 질문이 남습니다.

❓ 탐지 결과 이후에 남는 질문

위험하다고 판단된 거래에는 어떤 대응을 적용해야 하는가
담당자는 어떤 탐지 근거와 행동 이력을 확인해야 하는가
고위험 거래를 조사 대상 사건으로 어떻게 연결해야 하는가
동일 요청이나 이벤트가 반복되었을 때 중복 처리를 어떻게 막아야 하는가
누가 언제 거래 또는 사건 상태를 변경했는지 어떻게 추적해야 하는가
외부 위험정보나 AI 서비스가 실패하면 거래 상태를 어떻게 관리해야 하는가
처리 도중 장애가 발생했을 때 어디까지 저장하고 어떻게 복구해야 하는가
AI 호출량, 지연시간과 비용을 어떻게 측정하고 통제해야 하는가

위험 점수를 반환하는 데서 끝난다면 이상거래 탐지 모델의 데모는 될 수 있지만, 탐지 결과를 실제 업무 처리로 연결하는 시스템이라고 설명하기에는 부족했습니다.

그래서 프로젝트의 중심을 모델 정확도 자체보다 거래 접수부터 탐지, 위험 대응, 사건 처리와 운영까지 이어지는 전체 흐름 으로 옮겼습니다.

️ 4. FDS에서 FraudOps 플랫폼으로

초기 프로젝트의 목표는 금융 거래와 사용자 행동을 분석해 이상거래를 탐지하고 분석 결과를 제공하는 것이었습니다.

하지만 탐지 이후의 업무 처리와 AI 서비스 운영 문제까지 포함하면서 프로젝트를 다음과 같이 다시 정의했습니다.

이상거래를 탐지하는 데서 끝나지 않고, 탐지 결과를 위험 대응과 사건 처리로 연결하며, AI 서비스의 장애·성능·비용까지 통합 관리하는 FraudOps 플랫폼

FinGuardOps는 이를 크게 금융 FDS, AI 운영, Cloud Native 운영의 세 영역으로 나누어 설명합니다.

금융 FDS

금융 거래와 행동 이벤트 처리
Rule·ML 기반 위험도 계산
설명 가능한 탐지 근거 제공
위험도별 거래 대응
사건 생성과 담당자 검토
감사 이력 관리

AI 운영

고위험 사건 AI 리포트
탐지 근거와 행동 타임라인 요약
모델 라우팅
템플릿 fallback
입력·출력 토큰 기록
모델별 비용과 품질 관리

☁️ Cloud Native 운영

서비스 Health와 배포 상태
로그·메트릭·트레이싱
오류율과 처리량 관측
장애 격리와 복구
안전한 배포
비용과 운영 자동화

이 글에서는 특정 시점의 구현 현황보다 FinGuardOps가 지향하는 전체 제품 범위와 현대화 방향을 소개합니다. 금융 FDS, AI 운영과 Cloud Native 운영을 하나의 목표 구조로 정의하고, 이후 글에서는 각 문제를 어떤 설계와 검증 방식으로 해결하는지 단계별로 기록합니다.

5. FinGuardOps가 해결하려는 문제

FinGuardOps는 특정 기술을 사용하는 것을 목표로 시작한 프로젝트가 아닙니다.

먼저 해결해야 할 문제를 정의하고, 그 문제를 해결하는 데 필요한 기술을 단계적으로 선택했습니다.

탐지와 설명

어떤 거래를 위험하다고 판단할 것인가
Rule과 ML의 역할을 어떻게 구분할 것인가
위험 점수의 근거를 어떻게 설명할 것인가
재현 가능한 분석 결과를 어떻게 만들 것인가

️ 위험 대응과 사건 처리

위험도별 대응을 어떻게 구분할 것인가
고위험 거래를 사건으로 어떻게 연결할 것인가
사건 상태와 최종 판정을 어떻게 분리할 것인가
담당자의 조사 결과를 어떻게 기록할 것인가

정합성과 중복 방지

동일한 거래 요청을 어떻게 식별할 것인가
중복 이벤트를 어떻게 처리할 것인가
중복 사건 생성을 어떻게 방지할 것인가
일부 데이터만 반영되는 상황을 어떻게 막을 것인가

장애와 복구

External Risk와 FastAPI 실패를 어떻게 구분할 것인가
Timeout을 정상 결과로 처리하지 않으려면 어떻게 할 것인가
처리 완료와 응답 저장 사이의 간극을 어떻게 복구할 것인가
AI 리포트 실패를 금융 판단과 어떻게 격리할 것인가

Observability와 FinOps

요청이 거친 처리 단계를 어떻게 추적할 것인가
서비스별 지연시간과 오류율을 어떻게 측정할 것인가
LLM 호출량과 토큰을 어떻게 기록할 것인가
비용 급증과 fallback 증가를 어떻게 확인할 것인가

☁️ Application Modernization

서로 다른 실행 환경을 컨테이너로 어떻게 표준화할 것인가
검증되지 않은 변경이 배포되지 않도록 어떤 Gate를 둘 것인가
서비스별 확장과 복구를 어떻게 분리할 것인가
로컬 구성을 Kubernetes와 AWS로 어떻게 이전할 것인가

이 질문들은 이후 거래 상태 전이, 멱등성, ERD, API, External Risk, CI/CD, Observability, Kubernetes, AWS와 AI FinOps를 설계하는 기준이 되었습니다.

6. 프로젝트의 주요 사용자

FinGuardOps의 사용자는 FDS 분석 담당자와 플랫폼·클라우드 운영자로 구분했습니다.

두 사용자는 확인하는 정보와 수행하는 업무가 다르기 때문에 화면과 API의 책임도 구분할 계획입니다.

️ FDS 분석 담당자

위험 거래와 사건을 조회하고 탐지 결과를 검토하는 사용자입니다.

위험 점수와 위험 등급 확인
Rule·ML 탐지 근거 확인
사용자 행동 타임라인과 연관 거래 확인
외부 위험정보 확인
AI 사건 리포트 검토
조사 메모와 담당자 관리
정상·오탐·이상거래 최종 판정
사건 상태와 감사 이력 확인

️ 플랫폼·클라우드 운영자

FinGuardOps를 구성하는 서비스와 인프라의 상태를 확인하는 사용자입니다.

Spring Boot·FastAPI Health 확인
PostgreSQL과 향후 Redis·Kafka 상태 확인
API 응답시간·오류율·처리량 확인
External Risk·Rule·ML·LLM 처리시간 확인
DB Connection Pool과 Consumer Lag 확인
AI 호출량·토큰·비용 확인
캐시 적중률과 fallback 비율 확인
장애와 배포 이력 확인

FDS 분석 담당자 화면에서는 거래·사건·조사와 같은 업무 상태를 다루고, 플랫폼 운영 화면에서는 서비스 상태와 비용 요약을 다루도록 구분했습니다.

상세 시계열 기술 지표는 별도의 Observability 도구에서 확인하는 방향으로 계획했습니다.

7. 프로젝트의 목표와 제외 범위

✅ 7.1 프로젝트 목표

금융 이상거래 탐지와 사건 처리를 트랜잭션·멱등성·상태 전이·감사 로그를 갖춘 백엔드 시스템으로 구현합니다.
Spring Boot, FastAPI와 React를 연결하여 업무 애플리케이션의 전체 사용자 흐름을 구성합니다.
Docker, CI/CD, Observability, Kafka, Kubernetes와 AWS를 단계적으로 적용해 애플리케이션을 Cloud Native 구조로 확장합니다.
생성형 AI와 AI Agent를 활용하되 장애·비용·품질·권한과 최종 승인 경계를 사람이 통제합니다.

프로젝트에서 기술은 목적이 아니라 금융 거래의 정합성, 탐지 결과의 설명 가능성, 외부 의존성 장애와 운영 문제를 해결하기 위한 수단으로 사용합니다.

7.2 명확하게 제외한 범위

실제 금융기관 계좌와 실제 고객 거래 사용
실제 거래 승인·인증·차단·고객 제재
실제 금융기관 수준의 대규모 인프라
실제 운영 중인 레거시 금융 시스템을 직접 마이그레이션했다는 주장
처음부터 전체 시스템을 마이크로서비스로 분리하는 구성
핵심 기능보다 앞선 Kafka·Kubernetes 도입
생성형 AI를 통한 위험 점수 계산
생성형 AI를 통한 최종 이상거래 판정
생성형 AI를 통한 사건 상태 자동 확정
Reason Code만으로 다른 사건의 AI 리포트를 재사용하는 방식
시맨틱 캐시와 범용 FDS 챗봇
측정하지 않은 성능 향상이나 비용 절감률 주장

실제 거래 승인·인증·차단과 고객 제재는 Mock으로 처리하고, 생성형 AI는 담당자의 검토를 지원하는 보조 도구로만 사용합니다.

최종 업무 상태와 판단은 정해진 정책과 담당자의 검토를 통해 결정하도록 했습니다.

8. 생성형 AI를 개발에 활용하는 방식

FinGuardOps에서는 생성형 AI를 단순 코드 자동 생성기가 아니라 역할이 구분된 개발 도구로 활용하고 있습니다.

PM·Tech Lead, Backend, Frontend, AI Service와 Review 역할에 맞게 요구사항 분석, 구현 초안, 테스트 초안과 코드 리뷰를 요청합니다.

하지만 AI가 제안한 내용을 그대로 프로젝트에 반영하지는 않습니다.

프로젝트 범위와 우선순위를 정하고, API·DB·아키텍처의 기준을 검토하며, 테스트 결과와 변경 파일을 확인한 뒤 최종 반영 여부를 직접 결정합니다.

문제와 요구사항 정의
→ GitHub Issue 작성
→ 역할별 AI가 구현·문서화 초안 작성
→ API·DB·아키텍처 정합성 검토
→ 단위·통합 테스트 실행
→ 독립 코드 리뷰
→ 수정과 재검증
→ 사용자 최종 승인과 Pull Request merge

AI Agent와 Human-in-the-loop

승인된 GitHub Issue, ADR, API·DB 계약과 변경 허용 파일을 AI Agent의 작업 경계로 사용합니다. Agent는 구현·테스트·문서 초안을 만들 수 있지만, 요구사항과 계약을 임의로 바꾸거나 운영 배포를 확정할 수 없습니다.

main 직접 Commit과 자동 Merge 금지
API 계약과 DB Migration의 임의 확정 금지
Secret과 운영 Credential 접근 금지
Production 자동 배포 금지
테스트·리뷰·사용자 최종 승인 필수

프로젝트에서 직접 담당하는 역할

PM, Backend Lead, DevOps Engineer, Architecture Owner, Reviewer, Tester와 Final Approver 역할을 담당합니다. 생성형 AI는 구현과 문서화 생산성을 높이기 위한 도구이며, 요구사항과 기술 결정의 책임을 대신하지 않습니다.

생성형 AI를 역할별 개발 도구로 활용했으며, 요구사항 정의, API·DB 설계, 아키텍처 결정, 코드 검토, 테스트, DevOps와 최종 검증은 직접 수행했습니다.

이 과정을 GitHub Issue, 브랜치, Commit, Pull Request, 테스트 결과와 리뷰 기록으로 남겨 AI를 활용한 개발 과정도 재현하고 검토할 수 있도록 운영하고 있습니다.

9. 마치며: 이제 전체 구조를 설계할 차례

FinGuardOps는 단순히 이상거래 위험 점수를 보여주는 프로젝트가 아닙니다.

금융 거래가 접수되고, 거래와 사용자 행동이 분석되며, 위험도에 따른 대응과 사건 처리가 이루어지고, 그 과정의 상태와 장애를 추적할 수 있는 전체 흐름을 구현하는 것이 목표입니다.

FinGuardOps의 전체 흐름


      금융거래·행동 이벤트
      → Rule·ML 기반 이상거래 탐지
      → 위험 등급별 대응
      → 사건 생성과 담당자 검토
      → 생성형 AI 사건 리포트
      → 장애·성능·비용·배포 상태 운영

이 프로젝트를 통해 금융 이상거래 탐지와 사건 처리를 백엔드 시스템으로 구현하는 역량, Spring Boot·FastAPI·React를 연결하는 애플리케이션 설계 역량, Docker·CI/CD·Observability·Kubernetes·AWS 기반의 Cloud Application Modernization 역량, 그리고 생성형 AI와 AI Agent의 장애·비용·권한을 통제하는 운영 역량을 함께 검증하려고 합니다.

프로젝트의 목표와 범위를 정한 다음에는 금융 업무 상태와 AI 계산 책임을 어떻게 분리할지 결정해야 했습니다. 또한 프론트엔드, 데이터베이스와 인프라가 각각 어떤 정보를 소유하고 어떤 역할을 담당할지도 정해야 했습니다.

[FinGuardOps #2] 전체 시스템 구성과 기술별 역할을 어떻게 나눴는가
Spring Boot, FastAPI, React, PostgreSQL과 인프라 영역을 어떤 기준으로 나누었는지 정리합니다.

GitHub에서 FinGuardOps 저장소 보기

[LG CNS 6기] 23일차 TIL : DDL·DML·제약조건·VIEW·Sequence와 참조 무결성

bbbicsan — Fri, 28 Aug 2026 17:19:32 +0900

[LG CNS 6기] 23일차 TIL : DDL·DML·제약조건·VIEW·Sequence와 참조 무결성

한 줄 요약
DDL과 DML을 중심으로 FOREIGN KEY, CASCADE, CHECK, DEFAULT, ALTER TABLE, VIEW, UPDATE, Sequence, AUTO_INCREMENT를 실습하며 데이터베이스 구조를 정의하고 실제 데이터의 무결성을 유지하면서 변경하는 과정을 익혔다.

오늘 학습한 커리큘럼

SQL Day05 - DDL & DML
        ↓
Foreign Key
        ↓
참조 무결성
ON DELETE CASCADE
ON UPDATE CASCADE
NO ACTION
        ↓
PK / FK와 INDEX
SHOW INDEX
BTREE
        ↓
INSERT
DEFAULT / NULL
        ↓
Constraint
NOT NULL / CHECK
        ↓
ALTER TABLE
ADD / MODIFY / CHANGE / DROP
        ↓
쇼핑몰 ERD
1:N / N:M 관계
        ↓
VIEW
CREATE OR REPLACE VIEW
        ↓
DDL Workshop Q1 ~ Q15
강사님 풀이 확인
        ↓
DML
INSERT / UPDATE / DELETE
        ↓
UPDATE + Subquery
        ↓
Foreign Key 오류
참조 무결성 검증
        ↓
Sequence
NEXTVAL / LASTVAL
START WITH / INCREMENT BY / MAXVALUE
        ↓
Sequence + PK
        ↓
AUTO_INCREMENT
        ↓
쇼핑몰 ERD 기반 실습 과제
※ 문제만 제시, 수업 중 풀이는 진행하지 않음

오늘의 학습 키워드

DDL
DML
CREATEALTERDROP
INSERTUPDATEDELETE
COMMITROLLBACK
Foreign Key
Referential Integrity
ON DELETE CASCADE
ON UPDATE CASCADE
NO ACTION
PRIMARY KEY
NOT NULLCHECKDEFAULT
SHOW INDEX
BTREE
MODIFY COLUMN
CHANGE COLUMN
VIEW
CREATE OR REPLACE VIEW
WITH CHECK OPTION
Sequence
NEXTVAL
LASTVAL
START WITH
INCREMENT BY
MAXVALUE
AUTO_INCREMENT

1. Foreign Key와 참조 무결성

오늘 첫 번째 주제는 Foreign Key와 참조 무결성(Referential Integrity) 이었다.

부모 테이블
PK
 ↓
자식 테이블
FK

Foreign Key는 자식 테이블의 값이 부모 테이블에 존재하는 값을 참조하도록 제한한다.

즉 자식 데이터는 기본적으로:

부모 테이블에 존재하는 키 값
또는
NULL이 허용된 경우 NULL

을 가질 수 있다.

2. Foreign Key 옵션

외래키를 선언할 때 부모 데이터가 변경되거나 삭제되는 경우 자식 데이터를 어떻게 처리할지 설정할 수 있다.

ON DELETE CASCADE
→ 부모 데이터 삭제
→ 자식 데이터도 연쇄 삭제

ON UPDATE CASCADE
→ 부모 키 변경
→ 자식 FK도 함께 변경

NO ACTION
→ 참조 관계가 존재하면
   무결성을 깨는 삭제/수정을 허용하지 않음

예를 들어:

TB_DEPT
DEPT_ID = 10
     ↓
TB_EMP
DEPT_ID = 10

인 상황에서 부모 DEPT_ID = 10을 삭제하고 ON DELETE CASCADE가 설정되어 있다면 해당 부서를 참조하던 사원도 함께 삭제된다.

3. PK / FK와 INDEX 확인

부서 테이블을 생성했다.

CREATE TABLE TB_DEPT (
    DEPT_ID    VARCHAR(10),
    DEPT_TITLE VARCHAR(50),
    PRIMARY KEY(DEPT_ID)
);

이후:

SHOW INDEX FROM TB_DEPT;

를 통해 실제 인덱스를 확인했다.

결과에서:

Key_name   → PRIMARY
Column_name → DEPT_ID
Index_type → BTREE

가 확인됐다.

4. FK + CASCADE가 적용된 사원 테이블

CREATE TABLE TB_EMP (
    EMP_ID    VARCHAR(10) PRIMARY KEY,
    EMP_NAME  VARCHAR(50) NOT NULL,
    HIRE_DATE DATE DEFAULT SYSDATE(),
    DEPT_ID   VARCHAR(10) NOT NULL,
    JOB_ID    VARCHAR(10) NOT NULL,

    FOREIGN KEY(DEPT_ID)
        REFERENCES TB_DEPT(DEPT_ID)
        ON DELETE CASCADE,

    FOREIGN KEY(JOB_ID)
        REFERENCES TB_JOB(JOB_ID)
        ON UPDATE CASCADE
);

관계:

TB_DEPT
DEPT_ID(PK)
     ↓
TB_EMP
DEPT_ID(FK)

TB_JOB
JOB_ID(PK)
     ↓
TB_EMP
JOB_ID(FK)

다시:

SHOW INDEX FROM TB_EMP;

를 실행했더니:

PRIMARY
DEPT_ID
JOB_ID

관련 인덱스를 확인할 수 있었다.

5. INSERT와 DEFAULT

HIRE_DATE에는 다음과 같이 기본값이 선언되어 있었다.

HIRE_DATE DATE DEFAULT SYSDATE()

따라서 컬럼을 생략하고 INSERT하면:

INSERT INTO TB_EMP(
    EMP_ID,
    EMP_NAME,
    DEPT_ID,
    JOB_ID
)
VALUES(
    '100',
    'JSLIM',
    '10',
    'J1'
);

HIRE_DATE에는 자동으로 기본값이 들어간다.

HIRE_DATE 생략
        ↓
DEFAULT SYSDATE()
        ↓
현재 날짜 저장

6. DEFAULT를 명시적으로 사용

INSERT할 때 DEFAULT 키워드를 직접 사용할 수도 있었다.

INSERT INTO TB_EMP(
    EMP_ID,
    EMP_NAME,
    HIRE_DATE,
    DEPT_ID,
    JOB_ID
)
VALUES(
    '200',
    'JSLIM',
    DEFAULT,
    '10',
    'J1'
);

이 경우도 HIRE_DATE에 선언된 기본값이 적용된다.

7. DEFAULT와 NULL의 차이

이번 실습에서 중요했던 차이였다.

INSERT INTO TB_EMP(
    EMP_ID,
    EMP_NAME,
    HIRE_DATE,
    DEPT_ID,
    JOB_ID
)
VALUES(
    '300',
    'JSLIM',
    NULL,
    '10',
    'J1'
);

NULL을 명시적으로 넣으면 DEFAULT가 실행되는 것이 아니라 실제 NULL이 저장된다.

컬럼 생략
→ DEFAULT

DEFAULT 명시
→ DEFAULT

NULL 명시
→ NULL

즉 DEFAULT와 NULL은 같은 의미가 아니다.

8. NOT NULL과 CHECK

다음 테이블을 만들면서 제약조건을 다시 실습했다.

CREATE TABLE TB_EMPLOYEE (
    EMP_ID    VARCHAR(10),
    EMP_NAME  VARCHAR(50) NOT NULL,
    SALARY    INT CHECK(SALARY > 0),
    GENDER    CHAR(1) CHECK(GENDER IN ('F', 'M')),
    HIRE_DATE DATE DEFAULT SYSDATE(),
    JOB_ID    VARCHAR(10),
    DEPT_ID   VARCHAR(10)
);

각 제약조건의 의미:

EMP_NAME NOT NULL
→ 반드시 이름을 입력

SALARY CHECK(SALARY > 0)
→ 0 이하 급여 입력 방지

GENDER CHECK(GENDER IN ('F','M'))
→ F 또는 M만 허용

HIRE_DATE DEFAULT SYSDATE()
→ 값이 생략되면 현재 날짜

9. ALTER TABLE

이미 존재하는 테이블 구조를 변경할 때 ALTER TABLE을 사용한다.

강의에서 정리한 주요 형태:

ADD
→ 제약조건 등 추가

ADD COLUMN
→ 컬럼 추가

DROP CONSTRAINT
→ 제약조건 제거

CHANGE COLUMN
→ 컬럼 이름과 타입 변경

MODIFY COLUMN
→ 컬럼 이름은 유지하고 타입/속성 변경

DROP COLUMN
→ 컬럼 삭제

RENAME
→ 이름 변경

10. ALTER TABLE로 PK 추가

처음 EMP_ID에 PK가 없던 테이블에 나중에 PK를 추가했다.

ALTER TABLE TB_EMPLOYEE
ADD CONSTRAINT PRIMARY KEY(EMP_ID);

즉:

CREATE TABLE
→ 처음부터 구조 정의

ALTER TABLE
→ 만들어진 구조를 나중에 변경

이라는 차이를 확인했다.

11. MODIFY와 CHANGE 차이

이번 Workshop에서도 반복해서 사용했다.

MODIFY COLUMN
→ 기존 컬럼명 유지
→ 타입 / NOT NULL 등의 속성 변경

CHANGE COLUMN
→ 컬럼명 변경 가능
→ 데이터 타입도 함께 다시 지정

예:

ALTER TABLE TB_CLASS_TYPE
MODIFY COLUMN NAME VARCHAR(10) NOT NULL;

ALTER TABLE TB_CLASS_TYPE
CHANGE COLUMN NO CLASS_TYPE_NO VARCHAR(10);

12. 쇼핑몰 ERD

DDL 실습 중 쇼핑몰 ERD를 살펴봤다.

CUSTOMERS
   1
   ↓
   N
ORDERS
   1
   ↓
   N
ORDERDETAIL
   N
   ↑
   1
PRODUCTS

핵심은 ORDERS와 PRODUCTS의 관계였다.

한 주문
→ 여러 상품 포함 가능

한 상품
→ 여러 주문에 포함 가능

ORDERS N : M PRODUCTS

이 N:M 관계를 ORDERDETAIL이라는 중간 테이블로 해소한다.

ORDERS 1 : N ORDERDETAIL
PRODUCTS 1 : N ORDERDETAIL

ORDERDETAIL에는:

ORDERNO
PNO
QTY
COST

처럼 주문과 상품의 관계 자체에 필요한 데이터를 저장한다.

13. VIEW

VIEW는 SELECT 결과를 논리적인 테이블처럼 사용할 수 있도록 만든 객체이다.

기본 문법:

CREATE OR REPLACE VIEW VIEW_NAME
AS
SELECT ...;

실습:

CREATE OR REPLACE VIEW EMP_VIEW
AS
SELECT E.EMP_NAME,
       D.DEPT_NAME
FROM DEPARTMENT D
JOIN EMPLOYEE E
  ON D.DEPT_ID = E.DEPT_ID
WHERE E.DEPT_ID = '90';

이후:

SELECT *
FROM EMP_VIEW;

만으로 기존 JOIN + WHERE 쿼리의 결과를 다시 사용할 수 있었다.

복잡한 SELECT
       ↓
VIEW
       ↓
간단한 SELECT

14. TABLE과 VIEW 차이

TABLE
→ 실제 데이터를 저장

VIEW
→ SELECT 결과를 논리적인 테이블처럼 제공

VIEW를 통해 복잡한 쿼리를 재사용할 수 있다는 점이 장점이었다.

DDL Workshop 실습

오늘은 전날의 DDL Workshop 15문제를 강사님 풀이와 함께 일부 다시 확인했다.

Q1. TB_CATEGORY 생성

CREATE TABLE TB_CATEGORY (
    NAME   VARCHAR(10),
    USE_YN CHAR(1) DEFAULT 'Y'
);

Q2. TB_CLASS_TYPE 생성

CREATE TABLE TB_CLASS_TYPE (
    NO   VARCHAR(5) PRIMARY KEY,
    NAME VARCHAR(10)
);

Q3. TB_CATEGORY에 PK 추가

ALTER TABLE TB_CATEGORY
ADD PRIMARY KEY (NAME);

Q4. NAME 컬럼에 NOT NULL 추가

ALTER TABLE TB_CLASS_TYPE
MODIFY COLUMN NAME VARCHAR(10) NOT NULL;

Q5. 컬럼 수정

ALTER TABLE tb_category
MODIFY NAME VARCHAR(20);

ALTER TABLE TB_CLASS_TYPE
CHANGE COLUMN NO CLASS_TYPE_NO VARCHAR(10);

ALTER TABLE TB_CLASS_TYPE
CHANGE COLUMN NAME CLASS_TYPE_NAME VARCHAR(10);

Q6. 컬럼명 변경

ALTER TABLE tb_category
CHANGE NAME CATEGORY_NAME VARCHAR(20);

ALTER TABLE tb_class_type
CHANGE NO CLASS_TYPE_NO VARCHAR(10),
CHANGE NAME CLASS_TYPE_NAME VARCHAR(20);

CHANGE를 사용해 이름과 타입을 동시에 지정했다.

Q7. PRIMARY KEY 재정의

기존 PK를 제거한 뒤 새 컬럼 기준으로 다시 PK를 지정하는 흐름이었다.

ALTER TABLE tb_category
ADD CONSTRAINT PK_CATEGORY_NAME
PRIMARY KEY (CATEGORY_NAME);

ALTER TABLE tb_class_type
ADD CONSTRAINT PK_CLASS_TYPE_NO
PRIMARY KEY (CLASS_TYPE_NO);

Q8. 다중행 INSERT

INSERT INTO tb_category
VALUES
('공학', 'Y'),
('자연과학', 'Y'),
('의학', 'Y'),
('예체능', 'Y'),
('인문사회', 'Y');

한 번의 INSERT로 여러 Row를 넣었다.

Q9. 기존 테이블에 FK 추가

ALTER TABLE TB_DEPARTMENT
ADD CONSTRAINT FK_DEPARTMENT_CATEGORY
FOREIGN KEY(CATEGORY)
REFERENCES TB_CATEGORY(CATEGORY_NAME);

TB_CATEGORY.CATEGORY_NAME
          ↓
TB_DEPARTMENT.CATEGORY

관계를 ALTER TABLE로 사후 추가했다.

Q10. 학생 일반 정보 VIEW 생성

CREATE OR REPLACE VIEW
VW_학생일반정보(학번, 학생이름, 주소)
AS
SELECT S.STUDENT_NO,
       S.STUDENT_NAME,
       S.STUDENT_ADDRESS
FROM tb_student S;

VIEW 선언부에서도 결과 컬럼 이름을 지정할 수 있다는 것을 확인했다.

Q11. 지도면담 VIEW

CREATE OR REPLACE VIEW
VW_지도면담(학생이름, 학과이름, 지도교수이름)
AS
SELECT S.STUDENT_NAME,
       D.DEPARTMENT_NAME,
       P.PROFESSOR_NAME
FROM tb_student S
JOIN tb_department D
  ON S.DEPARTMENT_NO = D.DEPARTMENT_NO
LEFT JOIN tb_professor P
  ON S.COACH_PROFESSOR_NO = P.PROFESSOR_NO
ORDER BY D.DEPARTMENT_NAME;

지도교수가 없는 학생도 남겨야 하므로 LEFT JOIN을 사용했다.

Q12. 학과별 학생 수 VIEW

CREATE OR REPLACE VIEW
VW_학과별학생수(DEPARTMENT_NAME, STUDENT_COUNT)
AS
SELECT D.DEPARTMENT_NAME,
       COUNT(S.DEPARTMENT_NO)
FROM tb_student S
JOIN tb_department D
  ON S.DEPARTMENT_NO = D.DEPARTMENT_NO
GROUP BY D.DEPARTMENT_NO;

Q14. WITH CHECK OPTION

CREATE OR REPLACE VIEW
VW_학생일반정보(학번, 학생이름, 주소)
AS
SELECT S.STUDENT_NO,
       S.STUDENT_NAME,
       S.STUDENT_ADDRESS
FROM tb_student S
WHERE ...
WITH CHECK OPTION;

WITH CHECK OPTION은 VIEW를 통해 데이터를 변경할 때 변경된 데이터도 VIEW의 WHERE 조건을 만족하도록 제한한다.

VIEW 조건
   ↓
INSERT / UPDATE
   ↓
변경 후에도 조건 만족?
   ↓
YES → 허용
NO  → 거부

Q15. 최근 3년 수강생 수가 많은 3과목

SELECT C.CLASS_NO AS 과목번호,
       C.CLASS_NAME AS 과목이름,
       COUNT(*) AS '누적수강생수(명)'
FROM TB_CLASS C
JOIN TB_GRADE G
  ON C.CLASS_NO = G.CLASS_NO
WHERE SUBSTRING(G.TERM_NO, 1, 4)
      BETWEEN '2007' AND '2009'
GROUP BY C.CLASS_NO,
         C.CLASS_NAME
ORDER BY COUNT(*) DESC,
         C.CLASS_NO
LIMIT 3;

흐름:

과목 + 성적 JOIN
      ↓
2007 ~ 2009 필터링
      ↓
과목별 GROUP BY
      ↓
COUNT(*)
      ↓
누적 수강생 수 계산
      ↓
내림차순 정렬
      ↓
LIMIT 3

15. DML

후반부에는 DML로 넘어갔다.

DML
→ Data Manipulation Language
→ 테이블의 실제 데이터 조작

대표적인 명령은:

INSERT
UPDATE
DELETE

이고 트랜잭션 관련 명령으로:

COMMIT
ROLLBACK

도 함께 언급됐다.

16. INSERT / UPDATE / DELETE 비교

명령어	역할	행 개수
`INSERT`	새로운 행 추가	증가
`UPDATE`	기존 행의 값 수정	일반적으로 유지
`DELETE`	기존 행 삭제	감소

INSERT
→ Row 추가

UPDATE
→ Column 값 변경

DELETE
→ Row 제거

17. UPDATE 기본 문법

UPDATE TABLE_NAME
SET COLUMN_NAME = VALUE,
    COLUMN_NAME = VALUE
WHERE CONDITION;

또한 SET에 직접 값뿐 아니라 서브쿼리 결과를 사용할 수도 있다.

UPDATE TABLE_NAME
SET COLUMN_NAME = (
    SELECT ...
)
WHERE ...;

18. UPDATE + Subquery

문제

심하균의 직급과 부서를
성해교 사원과 같은 직급과 부서로 수정한다면?

UPDATE employee
SET JOB_ID = (
        SELECT JOB_ID
        FROM employee
        WHERE EMP_NAME = '성해교'
    ),
    DEPT_ID = (
        SELECT DEPT_ID
        FROM employee
        WHERE EMP_NAME = '성해교'
    )
WHERE EMP_NAME = '심하균';

성해교의 JOB_ID
→ 심하균 JOB_ID

성해교의 DEPT_ID
→ 심하균 DEPT_ID

19. 해외영업2팀 BONUS_PCT 변경

문제

해외영업2팀 사원의 BONUS_PCT를
0.3으로 수정한다면?

강사님 풀이:

UPDATE employee
SET BONUS_PCT = 0.3
WHERE DEPT_ID = (
    SELECT DEPT_ID
    FROM DEPARTMENT
    WHERE DEPT_NAME = '해외영업2팀'
);

흐름:

해외영업2팀
       ↓
DEPT_ID 서브쿼리
       ↓
해당 사원들 조회
       ↓
BONUS_PCT = 0.3

20. MariaDB CLI에서 UPDATE 확인

먼저 현재 데이터를 조회했다.

SELECT EMP_NAME,
       MARRIAGE
FROM EMPLOYEE
WHERE EMP_ID = '143';

실행 결과:

나승원 | Y

이후:

UPDATE EMPLOYEE
SET MARRIAGE = 'N'
WHERE EMP_ID = '143';

실행 결과:

Query OK, 1 row affected

Rows matched: 1
Changed: 1
Warnings: 0

의미:

Rows matched: 1
→ WHERE 조건에 해당하는 Row 1개 발견

Changed: 1
→ 실제 값이 변경됨

Warnings: 0
→ 경고 없음

문제 해결 과정 1. 존재하지 않는 FK로 UPDATE

다음 쿼리를 실행했다.

UPDATE employee
SET DEPT_ID = '65'
WHERE EMP_ID = '100';

오류:

SQL 오류 (1452)

Cannot add or update a child row:
a foreign key constraint fails

증상

DEPT_ID = '65'로 수정할 수 없었다.

원인

employee.DEPT_ID는:

department.DEPT_ID

를 참조하는 Foreign Key이다.

그런데 부모 테이블에 65라는 부서번호가 존재하지 않았다.

department
DEPT_ID = 65
→ 없음

employee
DEPT_ID = 65
→ 존재하지 않는 부모를 참조

→ 참조 무결성 위반

해결

먼저 부모 테이블에 존재하는 유효한 부서번호를 확인해야 한다.

SELECT DEPT_ID,
       DEPT_NAME
FROM department;

그 뒤 실제 존재하는 값으로 UPDATE한다.

배운 점

Foreign Key는 INSERT뿐 아니라 UPDATE에서도 참조 무결성을 강제한다.

21. FK와 NULL

이어서:

UPDATE employee
SET DEPT_ID = NULL
WHERE EMP_ID = '100';

도 확인했다.

FK 컬럼이 NULL을 허용한다면:

존재하지 않는 임의값
→ FK 위반

NULL
→ 특정 부모를 참조하지 않음
→ 허용 가능

이다.

즉:

FK 컬럼
→ 부모에 존재하는 값
또는
→ NULL 허용 시 NULL

을 가질 수 있다.

22. INSERT 기본 문법

INSERT INTO TABLE_NAME ([COLUMN_NAME])
VALUES (VALUES);

INSERT에서 특히 확인해야 할 것은:

데이터 타입
컬럼 순서
값의 개수

이다.

23. DELETE 기본 문법

DELETE FROM TABLE_NAME
WHERE CONDITION;

DELETE는 Row 자체를 삭제하기 때문에 실행 후 전체 행 수가 변경된다.

또한 WHERE를 생략하면 전체 데이터가 삭제될 수 있으므로 주의해야 한다.

24. Sequence

이후 자동 번호 생성을 위한 Sequence를 실습했다.

기본 생성:

CREATE SEQUENCE SEQ_TEST;

다음 값:

SELECT NEXTVAL(SEQ_TEST);

마지막 사용 값:

SELECT LASTVAL(SEQ_TEST);

그리고 Sequence 삭제:

DROP SEQUENCE SEQ_TEST;

25. Sequence 옵션

Sequence를 다시 생성했다.

CREATE SEQUENCE SEQ_TEST
START WITH 1000
INCREMENT BY 2
MAXVALUE 1005;

의미:

START WITH 1000
→ 시작값

INCREMENT BY 2
→ 2씩 증가

MAXVALUE 1005
→ 최대 허용값

따라서:

이 된다.

1006에서 오류가 발생한 이유는:

MAXVALUE = 1005

를 초과했기 때문이다.

문제 해결 과정 2. Sequence가 1006에서 실패

증상

NEXTVAL()을 계속 호출하자:

1000
1002
1004

까지 정상적으로 생성됐지만 다음 호출에서 오류가 발생했다.

원인

증가폭이 2이므로 다음 값은 1006이다.

1006 > MAXVALUE 1005

이므로 더 이상 값을 생성할 수 없었다.

배운 점

MAXVALUE 1005는 반드시 1005가 반환된다는 의미가 아니다.

START WITH
+
INCREMENT BY

에 따라 실제 생성되지 않는 값일 수도 있다.

26. Sequence를 PK 자동값으로 사용

Sequence를 테이블의 기본값과 연결했다.

CREATE TABLE TB_TEMP (
    ORDER_ID INT
             DEFAULT (NEXTVAL(SEQ_TEST))
             PRIMARY KEY,
    CUSTOMER_NAME VARCHAR(50)
);

INSERT:

INSERT INTO TB_TEMP(CUSTOMER_NAME)
VALUES('JSLIM');

ORDER_ID를 입력하지 않아도 Sequence 값이 자동으로 사용된다.

실행 결과:

ORDER_ID | CUSTOMER_NAME
1000     | JSLIM
1002     | JSLIM
1004     | JSLIM

흐름:

Sequence
       ↓
NEXTVAL
       ↓
ORDER_ID DEFAULT
       ↓
INSERT에서 PK 생략
       ↓
자동 식별자 생성

27. AUTO_INCREMENT

MariaDB에서는 자동 증가 식별자를 더 간단하게 만들 수도 있다.

CREATE TABLE TB_AUTO_TEMP (
    ORDER_ID INT AUTO_INCREMENT PRIMARY KEY,
    CUSTOMER_NAME VARCHAR(50)
);

INSERT:

INSERT INTO TB_AUTO_TEMP(CUSTOMER_NAME)
VALUES('JSLIM');

결과:

1
2
3
4
5
...

순서대로 PK가 자동 생성된다.

28. Sequence vs AUTO_INCREMENT

구분	Sequence	AUTO_INCREMENT
별도 객체	필요	필요 없음
시작값	직접 설정 가능	설정 가능
증가폭	자유롭게 설정	일반적으로 자동 증가
사용 방식	`NEXTVAL()`	컬럼 속성
활용	여러 곳에서 독립적으로 사용 가능	특정 컬럼과 연결

Sequence
→ 별도의 번호 생성 객체

AUTO_INCREMENT
→ 컬럼 자체의 자동 증가 기능

둘 다 목적은 식별자 자동 생성이라는 점에서는 같다.

오늘 배운 개념 연결하기

오늘 학습한 내용을 하나의 흐름으로 보면 다음과 같다.

ERD
→ 테이블 관계 설계
        ↓
DDL
→ 실제 테이블 구조 생성
        ↓
PK / FK / CHECK / NOT NULL
→ 데이터 무결성 규칙
        ↓
ALTER
→ 기존 구조 변경
        ↓
VIEW
→ 복잡한 조회 구조 재사용
        ↓
DML
→ 실제 데이터 입력/수정/삭제
        ↓
Foreign Key
→ 잘못된 관계 데이터 차단
        ↓
Sequence / AUTO_INCREMENT
→ 식별자 자동 생성

오늘의 문제 해결 과정

오늘 실습에서는 제약조건이 실제 데이터 변경을 어떻게 제한하는지를 여러 상황에서 확인했다.

1. 존재하지 않는 부모 키를 참조한 UPDATE

증상

UPDATE employee
SET DEPT_ID = '65'
WHERE EMP_ID = '100';

실행 시:

SQL 오류 1452
Cannot add or update a child row

오류가 발생했다.

원인

employee.DEPT_ID
→ Foreign Key

department.DEPT_ID = 65
→ 존재하지 않음

부모에 없는 값을 자식이 참조하려 했기 때문이다.

해결

부모 테이블의 실제 데이터를 먼저 확인하고 존재하는 값을 사용해야 한다.

검증 포인트

FK
→ INSERT뿐만 아니라 UPDATE에서도 검증됨

2. FK에는 왜 NULL이 가능한가?

상황

UPDATE employee
SET DEPT_ID = NULL
WHERE EMP_ID = '100';

이해

65
→ 존재하지 않는 부모를 참조하는 값

NULL
→ 아무 부모도 참조하지 않는 상태

따라서 컬럼이 NULL을 허용하면 FK에도 NULL을 넣을 수 있다.

배운 점

Foreign Key
≠ 무조건 값이 있어야 함

NOT NULL Foreign Key
→ 반드시 부모 참조 필요

Nullable Foreign Key
→ 관계가 없음을 NULL로 표현 가능

3. DEFAULT와 NULL을 같은 것으로 생각하면 안 됨

실습

컬럼 생략
→ DEFAULT

DEFAULT 명시
→ DEFAULT

NULL 명시
→ NULL

배운 점

DEFAULT는 값이 없을 때 자동으로 들어갈 대체 값이고, NULL은 값이 존재하지 않는 상태 자체이다.

4. Sequence 최대값 초과

증상

원인

MAXVALUE 1005

이므로 1006을 생성할 수 없었다.

배운 점

Sequence의 실제 값은:

START WITH
INCREMENT BY
MAXVALUE

세 옵션의 조합으로 결정된다.

✨ 오늘 배운 점

오늘은 DDL과 DML을 연속해서 배우면서 테이블을 만드는 것과 데이터를 사용하는 것이 별개의 단계가 아니라 서로 연결된 과정이라는 점을 이해할 수 있었다.

DDL에서는:

테이블 구조
PK
FK
CHECK
DEFAULT

등을 통해 어떤 데이터를 저장할 수 있는지를 정의했다.

이후 DML에서는 그 규칙 안에서:

INSERT
UPDATE
DELETE

를 실행했다.

특히 Foreign Key 실습이 기억에 남았다.

처음에는 FK가 단순히 테이블을 JOIN하기 위한 연결 컬럼이라고 생각하기 쉬웠지만, 실제로 존재하지 않는 DEPT_ID = '65'를 UPDATE하려고 했을 때 DB가 직접 오류를 발생시키는 것을 보면서 FK의 핵심 목적은 단순 연결이 아니라 참조 무결성 보장이라는 점을 체감할 수 있었다.

또 Sequence와 AUTO_INCREMENT를 통해 PK를 사람이 직접 관리하지 않고 DB가 자동으로 생성할 수 있다는 것도 확인했다.

오늘의 회고

오늘은 이전까지 배운 ERD, PK/FK, JOIN이 DDL과 DML을 통해 실제 DB 동작으로 연결된 날이었다.

쇼핑몰 ERD에서는:

CUSTOMERS
→ ORDERS
→ ORDERDETAIL
← PRODUCTS

관계를 보면서 N:M 관계가 왜 중간 테이블을 필요로 하는지 다시 확인했다.

그리고 그 구조를 실제 테이블로 만들려면:

CREATE TABLE
PRIMARY KEY
FOREIGN KEY
CHECK
DEFAULT

같은 DDL 문법이 필요하고, 만들어진 구조에 데이터를 넣고 수정하려면 DML이 필요하다.

특히 오늘은 오류가 발생한 이유를 직접 확인하는 과정이 좋았다.

존재하지 않는 FK 값
→ 참조 무결성 오류

NULL
→ 관계 없음으로 허용 가능

Sequence MAXVALUE 초과
→ 자동번호 생성 실패

처럼 DB가 단순히 데이터를 저장하는 공간이 아니라, 정해진 규칙을 기반으로 잘못된 데이터를 차단하는 시스템이라는 점이 더 명확하게 느껴졌다.

오늘 마지막 실습 과제

수업 마지막에는 쇼핑몰 ERD 기반 DDL/DML 실습 과제가 제시됐다.

과제는 수업 시간에 강사님이 문제만 제시했고, 오늘은 별도의 풀이를 진행하지 않았다.

실습 구조는:

CUSTOMERS
ORDERS
PRODUCTS
ORDERDETAIL

4개 테이블을 기반으로 구성되어 있었다.

주요 요구사항은:

테이블 생성
      ↓
상품 / 회원 데이터 INSERT
      ↓
주문 데이터 INSERT
      ↓
주문 상세 데이터 INSERT
      ↓
상품 재고 UPDATE
      ↓
전체 주문 목록 JOIN
      ↓
일별 매출 GROUP BY + SUM

형태였다.

특히 하나의 주문을 처리할 때:

ORDERS INSERT
+
ORDERDETAIL INSERT
+
PRODUCTS STOCK UPDATE

가 함께 수행되어야 한다는 점이 눈에 들어왔다.

현재는 문제만 확인한 상태이고, 다음 학습에서는 직접 쿼리를 작성하면서 테이블 관계와 DML 흐름을 구현해볼 예정이다.

다음 학습 방향

다음에는 오늘 마지막으로 제시된 쇼핑몰 실습을 직접 구현하면서 다음 부분을 집중적으로 확인해야겠다.

1. ERD에서 PK / FK 관계 먼저 확인

2. 부모 테이블부터 INSERT

3. 자식 테이블은 부모 PK가 존재하는지 확인

4. 주문 1건과 주문상세 N건의 관계 이해

5. 주문 시 재고 감소 UPDATE

6. 여러 테이블 JOIN으로 주문내역 조회

7. GROUP BY + SUM으로 매출 집계

또한 오늘 DML에서 COMMIT, ROLLBACK이 언급됐기 때문에, 주문 처리처럼 여러 SQL이 하나의 작업 단위로 묶이는 경우:

주문 INSERT
→ 주문상세 INSERT
→ 재고 UPDATE

중 하나라도 실패했을 때 전체 작업을 어떻게 되돌릴 것인지 Transaction 관점으로도 연결해서 복습해야겠다.

[LG CNS 6기] 22일차 TIL : Subquery & DDL

bbbicsan — Thu, 27 Aug 2026 18:00:13 +0900

[LG CNS 6기] 22일차 TIL : Subquery & DDL

한 줄 요약
단일행·다중행·다중열 서브쿼리와 IN / ANY / ALL, Inline View, 상호연관 서브쿼리까지 실습하고, 후반부에는 CREATE / DROP / ALTER과 PRIMARY KEY / FOREIGN KEY / NOT NULL / UNIQUE / CHECK 제약조건을 통해 테이블 구조를 직접 정의했다.

오늘 학습한 커리큘럼

Subquery
   ↓
단일행 서브쿼리
   ↓
다중행 서브쿼리
   ↓
IN / ANY / ALL
   ↓
단일컬럼 / 다중컬럼
   ↓
Nested / Correlated Subquery
   ↓
Scalar Subquery
Inline View
WHERE Subquery
   ↓
서브쿼리 성능 고려
   ↓
Inline View + JOIN으로 개선
   ↓
Additional SELECT - Option 실습
   ↓
DDL
   ↓
CREATE / DROP / ALTER
   ↓
CREATE TABLE
   ↓
Constraint
PRIMARY KEY
FOREIGN KEY
NOT NULL
UNIQUE
CHECK
DEFAULT
   ↓
DDL + DML 제약조건 검증

오늘의 학습 키워드

Subquery
Single Row Subquery
Multi Row Subquery
Single Column Subquery
Multi Column Subquery
INANYALL
Scalar Subquery
Inline View
Correlated Subquery
GROUP BYHAVINGRANK()LIMIT
OFFSET
TRUNCATE()
DDL
CREATEDROPALTER
Constraint
PRIMARY KEYFOREIGN KEY
NOT NULLUNIQUECHECKDEFAULT

1. Subquery란?

오늘 SQL Day04의 첫 번째 주제는 Subquery였다.

서브쿼리는 하나의 SQL 안에 또 다른 SQL이 포함되는 구조이다.

Main Query
    ↓
Subquery 실행
    ↓
Subquery 결과 반환
    ↓
Main Query가 결과를 이용

서브쿼리는 반환되는 데이터의 형태에 따라 다음처럼 구분할 수 있다.

단일컬럼(Single Column)
다중컬럼(Multi Column)

단일행(Single Row)
다중행(Multi Row)

또한 기술되는 위치에 따라:

SELECT 절
→ Scalar Subquery

FROM 절
→ Inline View

WHERE 절
→ Subquery

로 나눌 수 있다.

동작 방식에 따라서는:

Nested Subquery
Correlated Subquery

로 나눌 수 있었다.

2. 단일행 서브쿼리

단일행 서브쿼리는 서브쿼리 결과가 하나의 행만 반환하는 경우이다.

대표적으로:

=
>
<
>=
<=
<>

등의 일반 비교 연산자를 사용할 수 있다.

실습 1. 나승원과 같은 직급이면서 더 많은 급여를 받는 사원

문제

나승원 사원과 같은 직급이고
나승원 사원보다 많은 급여를 받는
사원의 정보를 검색한다면?

먼저 나승원의 기준값을 조회했다.

SELECT JOB_ID,
       SALARY
FROM employee
WHERE EMP_NAME = '나승원';

실행 결과:

JOB_ID → J5
SALARY → 2,300,000

즉 문제는 실제로:

JOB_ID = J5
AND
SALARY > 2,300,000

인 사원을 찾는 문제였다.

이를 서브쿼리로 바꾸면:

SELECT *
FROM employee
WHERE JOB_ID = (
        SELECT JOB_ID
        FROM employee
        WHERE EMP_NAME = '나승원'
      )
  AND SALARY > (
        SELECT SALARY
        FROM employee
        WHERE EMP_NAME = '나승원'
      );

풀이 흐름

나승원의 JOB_ID 조회
        ↓
같은 직급 필터

나승원의 SALARY 조회
        ↓
더 높은 급여 필터

내부 쿼리를 먼저 따로 실행해 몇 행이 반환되는지 확인한 뒤 외부 쿼리와 결합하는 과정이 중요했다.

3. MIN()을 이용한 단일행 서브쿼리

최저 급여를 받는 사원을 조회했다.

SELECT *
FROM employee
WHERE SALARY = (
    SELECT MIN(SALARY)
    FROM employee
);

흐름:

SELECT MIN(SALARY)
        ↓
1,500,000
        ↓
SALARY = 1,500,000
        ↓
해당 사원 조회

실행 결과는 3명이었다.

정지현 → 1,500,000
고승우 → 1,500,000
염정하 → 1,500,000

여기서 중요한 점은:

서브쿼리 결과
→ 값 1개

외부 쿼리 결과
→ 여러 행 가능

이라는 점이었다.

4. Inline View

FROM 절에 서브쿼리를 넣으면 그 결과를 가상의 테이블처럼 사용할 수 있다.

이를 Inline View라고 한다.

SELECT V.DEPT_NAME,
       V.TOTAL_SALARY
FROM (
    SELECT D.DEPT_NAME,
           SUM(E.SALARY) AS TOTAL_SALARY
    FROM department D
    JOIN employee E
      ON D.DEPT_ID = E.DEPT_ID
    GROUP BY D.DEPT_NAME
) V;

흐름:

내부 SELECT
→ 집계 결과 생성
        ↓
가상 테이블 V
        ↓
외부 SELECT
→ V를 실제 테이블처럼 사용

5. 부서별 급여총합이 가장 높은 부서 찾기

문제

부서별 급여총합이 가장 높은 부서의
부서명과 급여총합을 검색한다면?

처음 Inline View를 이용해 최대값을 구하는 흐름을 확인했다.

다만 단순히:

SELECT V.DEPT_NAME,
       MAX(V.SUM)

처럼 집계값과 일반 컬럼을 함께 조회하면 부서명과 최대 급여가 올바르게 짝지어지지 않을 수 있는 문제를 확인했다.

이후 더 간단하게:

SELECT D.DEPT_NAME,
       SUM(E.SALARY) AS S
FROM employee E
JOIN department D
  ON E.DEPT_ID = D.DEPT_ID
GROUP BY E.DEPT_ID
ORDER BY S DESC
LIMIT 1;

로 해결했다.

실행 결과:

해외영업3팀 → 18,100,000

흐름

부서별 GROUP BY
      ↓
SUM(SALARY)
      ↓
ORDER BY DESC
      ↓
LIMIT 1
      ↓
최대 급여총합 부서

6. LIMIT과 OFFSET

LIMIT은 조회할 행 개수를 제한하고, OFFSET은 앞에서 몇 개의 행을 건너뛸지 지정한다.

SELECT D.DEPT_NAME,
       SUM(E.SALARY) AS S
FROM employee E
JOIN department D
  ON E.DEPT_ID = D.DEPT_ID
GROUP BY E.DEPT_ID
ORDER BY S DESC
LIMIT 2 OFFSET 1;

OFFSET 1
→ 첫 번째 행 건너뜀

LIMIT 2
→ 그 다음 2행 조회

예를 들면:

1위 → 해외영업3팀
2위 → 해외영업1팀
3위 → 기술지원팀

이라면:

LIMIT 2 OFFSET 1
→ 2위, 3위 조회

가 된다.

페이징과도 연결할 수 있다.

1페이지 → LIMIT 10 OFFSET 0
2페이지 → LIMIT 10 OFFSET 10
3페이지 → LIMIT 10 OFFSET 20

7. 다중행 서브쿼리

다중행 서브쿼리는 내부 쿼리가 여러 행을 반환한다.

이때 일반적인 = 비교 대신:

IN
ANY
ALL

등을 사용할 수 있다.

8. ANY / ALL

오늘 중요한 비교 연산자였다.

> ANY
→ 결과 중 하나보다만 크면 TRUE
→ 최솟값보다 크면 TRUE

> ALL
→ 모든 값보다 커야 TRUE
→ 최댓값보다 커야 TRUE

< ANY
→ 결과 중 하나보다만 작으면 TRUE
→ 최댓값보다 작으면 TRUE

< ALL
→ 모든 값보다 작아야 TRUE
→ 최솟값보다 작으면 TRUE

실습 2. 과장보다 많은 급여를 받는 대리

먼저 과장과 대리의 급여를 따로 조회했다.

SELECT E.EMP_NAME,
       E.SALARY
FROM employee E
JOIN job J
  ON E.JOB_ID = J.JOB_ID
WHERE J.JOB_TITLE = '과장';

SELECT E.EMP_NAME,
       E.SALARY
FROM employee E
JOIN job J
  ON E.JOB_ID = J.JOB_ID
WHERE J.JOB_TITLE = '대리';

대리 결과:

김예수 → 2,100,000
나승원 → 2,300,000
박하일 → 2,600,000

강사님 풀이에서는 > ANY를 사용했다.

SELECT E.EMP_NAME,
       E.SALARY
FROM employee E
JOIN job J
  ON E.JOB_ID = J.JOB_ID
WHERE J.JOB_TITLE = '대리'
  AND SALARY > ANY (
      SELECT E.SALARY
      FROM employee E
      JOIN job J
        ON E.JOB_ID = J.JOB_ID
      WHERE J.JOB_TITLE = '과장'
  );

> ANY
→ 과장 중 한 명의 급여보다라도 높으면 통과
→ 과장 급여의 최솟값보다 높으면 TRUE

실습 3. 모든 과장보다 적은 급여를 받는 대리

SELECT E.EMP_NAME,
       E.SALARY
FROM employee E
JOIN job J
  ON E.JOB_ID = J.JOB_ID
WHERE J.JOB_TITLE = '대리'
  AND SALARY < ALL (
      SELECT E.SALARY
      FROM employee E
      JOIN job J
        ON E.JOB_ID = J.JOB_ID
      WHERE J.JOB_TITLE = '과장'
  );

실행 결과:

전우성 → 2,090,000

< ALL
→ 모든 과장 급여보다 작아야 함
→ 결국 과장 급여 중 최솟값보다도 작아야 함

9. 다중열 서브쿼리

다중열 서브쿼리는 하나의 컬럼이 아니라 여러 컬럼을 하나의 묶음으로 비교한다.

단일열
SALARY IN (...)

다중열
(DEPT_ID, SALARY) IN (...)

실습 4. 부서별 최소급여를 받는 사원

문제

부서별 최소급여를 받는 사원의
이름, 부서명, 급여를 검색한다면?

처음에는:

SELECT EMP_NAME,
       DEPT_ID,
       SALARY
FROM employee
WHERE SALARY IN (
    SELECT MIN(SALARY)
    FROM employee
    GROUP BY DEPT_ID
);

처럼 작성했다.

문제점

이 쿼리는:

"자기 부서의 최소급여인가?"

가 아니라:

"어느 부서든 최소급여 값 중 하나와 같은가?"

만 검사한다.

즉 부서와 최소급여의 관계가 사라진다.

해결

DEPT_ID와 SALARY를 한 쌍으로 비교했다.

SELECT EMP_NAME,
       DEPT_ID,
       SALARY
FROM employee E
WHERE (DEPT_ID, SALARY) IN (
    SELECT DEPT_ID,
           MIN(SALARY)
    FROM employee
    GROUP BY DEPT_ID
);

부서명까지 출력하면:

SELECT E.EMP_NAME,
       D.DEPT_NAME,
       E.SALARY
FROM employee E
JOIN department D
  ON E.DEPT_ID = D.DEPT_ID
WHERE (E.DEPT_ID, E.SALARY) IN (
    SELECT DEPT_ID,
           MIN(SALARY)
    FROM employee
    GROUP BY DEPT_ID
);

결과

고승우 | 본사 인사팀  | 1,500,000
김술오 | 회계팀       | 2,500,000
감우섭 | 회계팀       | 2,500,000
이중기 | 회계팀       | 2,500,000
정지현 | 해외영업1팀 | 1,500,000
정도연 | 기술지원팀   | 2,600,000
전우성 | 해외영업2팀 | 2,090,000
최만식 | 해외영업3팀 | 3,600,000

10. 중첩 서브쿼리

국어국문학과에서 평균 평점이 가장 높은 학생을 찾는 문제에서는 여러 단계의 서브쿼리를 중첩했다.

SELECT S.STUDENT_NO,
       S.STUDENT_NAME
FROM tb_student S
JOIN tb_grade G
  ON S.STUDENT_NO = G.STUDENT_NO
WHERE S.DEPARTMENT_NO = (
    SELECT DEPARTMENT_NO
    FROM tb_department
    WHERE DEPARTMENT_NAME = '국어국문학과'
)
GROUP BY S.STUDENT_NO,
         S.STUDENT_NAME
HAVING AVG(G.POINT) = (
    SELECT MAX(AVG_POINT)
    FROM (
        SELECT AVG(G2.POINT) AS AVG_POINT
        FROM tb_student S2
        JOIN tb_grade G2
          ON S2.STUDENT_NO = G2.STUDENT_NO
        WHERE S2.DEPARTMENT_NO = (
            SELECT DEPARTMENT_NO
            FROM tb_department
            WHERE DEPARTMENT_NAME = '국어국문학과'
        )
        GROUP BY S2.STUDENT_NO
    ) T
);

전체 흐름:

국어국문학과
     ↓
DEPARTMENT_NO 조회
     ↓
학생별 AVG(POINT)
     ↓
Inline View
     ↓
MAX(AVG_POINT)
     ↓
외부 HAVING에서 비교
     ↓
최고 평균 학생 조회

11. 같은 문제를 RANK()로 해결

동일 문제를 Window Function으로도 풀었다.

SELECT V.STUDENT_NO,
       V.STUDENT_NAME
FROM (
    SELECT S.STUDENT_NO,
           S.STUDENT_NAME,
           RANK() OVER(
               ORDER BY AVG(G.POINT) DESC
           ) AS `rank`
    FROM TB_GRADE G
    JOIN TB_STUDENT S
      ON G.STUDENT_NO = S.STUDENT_NO
    JOIN TB_DEPARTMENT D
      ON S.DEPARTMENT_NO = D.DEPARTMENT_NO
    WHERE D.DEPARTMENT_NAME = '국어국문학과'
    GROUP BY S.STUDENT_NO,
             S.STUDENT_NAME
    ORDER BY `rank`
) V
LIMIT 1;

또는:

WHERE V.`rank` = 1

로도 처리할 수 있다.

차이

LIMIT 1
→ 첫 1명만 반환

WHERE rank = 1
→ 공동 1등이 여러 명이면 모두 반환

12. 상호연관(Correlated) 서브쿼리

상호연관 서브쿼리는 내부 서브쿼리가 외부 쿼리의 컬럼을 참조하는 방식이다.

Outer Query
   ↓
현재 행의 값 전달
   ↓
Inner Query
   ↓
결과 반환
   ↓
현재 행과 비교

예:

SELECT E.EMP_NAME,
       D.DEPT_NAME,
       E.SALARY
FROM employee E
JOIN department D
  ON E.DEPT_ID = D.DEPT_ID
WHERE E.SALARY = (
    SELECT MIN(E2.SALARY)
    FROM employee E2
    WHERE E2.DEPT_ID = E.DEPT_ID
);

내부 쿼리에서:

E2.DEPT_ID = E.DEPT_ID

처럼 외부 E를 참조하기 때문에 상호연관 서브쿼리이다.

13. 상호연관 서브쿼리의 성능 고려사항

강의에서는 상호연관 서브쿼리를 단순 문법이 아니라 성능 관점에서도 살펴봤다.

예를 들어 사원이 8만 명이고 각 사원에 대해:

"자신의 부서 평균연봉보다 많이 받는가?"

를 검사한다면:

사원 1명
→ 부서 평균 계산

사원 1명
→ 부서 평균 계산

...

최대 8만 번 반복

될 수 있다.

즉 동일한 데이터를 반복 접근할 가능성이 있다.

개선 방식

부서별 평균을 미리 한 번 계산하고 JOIN한다.

부서별 AVG(연봉)
      ↓
Inline View
      ↓
사원 테이블과 JOIN

예:

SELECT A.사원명,
       A.사원번호,
       A.연봉,
       B.부서평균연봉
FROM 사원 A,
     (
         SELECT 부서번호,
                AVG(연봉) AS 부서평균연봉
         FROM 사원
         GROUP BY 부서번호
     ) B
WHERE A.부서번호 = B.부서번호;

핵심은:

반복 서브쿼리
→ 동일 계산 반복 가능

Inline View + JOIN
→ 계산 결과를 먼저 만들고 재사용

이었다.

14. Scalar Subquery 성능 고려사항

SELECT List에서 사용하는 Scalar Subquery도 결과 행마다 반복 실행될 수 있다.

예:

SELECT A.사원명,
       A.사원번호,
       A.연봉,
       (
           SELECT AVG(연봉)
           FROM 사원
           WHERE 부서번호 = A.부서번호
       ) AS 부서평균연봉
FROM 사원 A
WHERE A.부서구분 = '본부부서';

결과가 1,000명이면 같은 부서 평균을 최대 1,000번 반복 계산할 가능성이 있다.

이를:

부서별 평균을 먼저 계산
        ↓
Inline View
        ↓
JOIN

하는 방식으로 개선할 수 있다.

15. Nested Loop Join 실행 계획

서브쿼리와 JOIN을 설명하는 과정에서 실행 계획도 살펴봤다.

SELECT STATEMENT
   ↓
NESTED LOOPS
   ↓
TABLE ACCESS BY INDEX ROWID
   ↓
INDEX RANGE SCAN

Nested Loop Join은 한쪽 데이터를 기준으로 다른 테이블을 반복 탐색하는 방식으로 설명됐다.

힌트 예:

/*+ USE_NL(A B) */

USE_NL
→ Nested Loop Join 유도

오늘은 실행 계획 자체를 깊게 분석하기보다 SQL 작성 방식에 따라 실제 DB 내부 접근 방식과 성능이 달라질 수 있다는 점을 함께 확인했다.

16. 직급별 평균급여와 같은 급여를 받는 사원

문제

자기 직급의 평균급여를 받는 직원의
이름, 직급명, 급여를 검색한다면?

조건)
평균급여는 정수 5자리까지 절삭

이 문제는 무려 세 가지 방식으로 풀이했다.

CASE 01. 다중열 IN 서브쿼리

처음 작성 과정에서 오류가 발생했다.

WHERE (JOB_ID, SALARY) IN (...)

오류:

SQL 오류 (1052)
Column 'JOB_ID' in IN/ALL/ANY is ambiguous

원인

외부 쿼리에:

job J
employee E

가 모두 존재했고 두 테이블에 JOB_ID가 모두 있기 때문이었다.

DB 입장에서는:

JOB_ID
→ J.JOB_ID?
→ E.JOB_ID?

를 판단할 수 없었다.

해결

테이블 별칭을 명확하게 지정했다.

SELECT E.EMP_NAME,
       J.JOB_TITLE,
       E.SALARY
FROM job J
JOIN employee E
  ON J.JOB_ID = E.JOB_ID
WHERE (J.JOB_ID, E.SALARY) IN (
    SELECT JOB_ID,
           TRUNCATE(AVG(SALARY), -5)
    FROM employee
    GROUP BY JOB_ID
);

실행 결과:

한선기 | 대표이사 | 9,000,000
안석규 | 부장     | 3,500,000
김술오 | 차장     | 2,500,000
이중기 | 차장     | 2,500,000
감우섭 | 차장     | 2,500,000
나승원 | 과장     | 2,300,000

CASE 02. Inline View + JOIN

SELECT E.EMP_NAME,
       J.JOB_TITLE,
       E.SALARY
FROM (
    SELECT JOB_ID,
           TRUNCATE(AVG(SALARY), -5) AS `JOBAVG`
    FROM employee
    GROUP BY JOB_ID
) V
JOIN employee E
  ON V.JOB_ID = E.JOB_ID
 AND V.JOBAVG = E.SALARY
JOIN job J
  ON E.JOB_ID = J.JOB_ID;

흐름:

직급별 평균급여 계산
       ↓
Inline View V
       ↓
JOB_ID + 평균급여로 employee JOIN
       ↓
job JOIN
       ↓
직급명 출력

CASE 03. Correlated Subquery

SELECT E.EMP_NAME,
       J.JOB_TITLE,
       E.SALARY
FROM job J
JOIN employee E
  ON J.JOB_ID = E.JOB_ID
WHERE E.SALARY = (
    SELECT TRUNCATE(AVG(SALARY), -5)
    FROM employee EE
    WHERE EE.JOB_ID = E.JOB_ID
);

내부 쿼리가:

EE.JOB_ID = E.JOB_ID

로 외부 행의 직급번호를 참조한다.

세 풀이 비교

CASE 01
다중열 IN
→ (JOB_ID, SALARY) 쌍 비교

CASE 02
Inline View + JOIN
→ 직급별 평균을 먼저 만들어 JOIN

CASE 03
Correlated Subquery
→ 현재 사원의 JOB_ID를 내부 쿼리가 참조

같은 결과를 여러 방식으로 구현해보면서 SQL은 결과만 같다고 끝나는 것이 아니라 데이터량과 실행 방식까지 고려해야 한다는 점을 알 수 있었다.

Additional SELECT - Option 실습

오늘 강사님은 기존 과제 범위를 확장해서:

[Additional SELECT - Option]
Q1 ~ Q19

까지 풀어보라고 했다.

수업 중 일부 문제는 실제 코드도 확인했다.

Q9. 인문사회 계열 과목과 담당 교수

SELECT C2.CLASS_NAME,
       P.PROFESSOR_NAME
FROM TB_CLASS_PROFESSOR C1
JOIN TB_CLASS C2 USING(CLASS_NO)
JOIN TB_PROFESSOR P USING(PROFESSOR_NO)
JOIN TB_DEPARTMENT D
  ON P.DEPARTMENT_NO = D.DEPARTMENT_NO
WHERE D.CATEGORY = '인문사회';

흐름

TB_CLASS_PROFESSOR
      ↓
과목 연결
      ↓
교수 연결
      ↓
교수의 소속 학과 연결
      ↓
CATEGORY = 인문사회

실행 결과는 화면 기준 197행이었다.

Q10. 음악학과 학생 전체 평점

SELECT S.STUDENT_NO AS '학번',
       S.STUDENT_NAME AS '학생 이름',
       ROUND(AVG(G.POINT), 1) AS '전체 평점'
FROM tb_grade G
JOIN tb_student S
  ON G.STUDENT_NO = S.STUDENT_NO
JOIN tb_department D
  ON S.DEPARTMENT_NO = D.DEPARTMENT_NO
WHERE D.DEPARTMENT_NAME = '음악학과'
GROUP BY S.STUDENT_NO,
         S.STUDENT_NAME;

흐름

학생 + 성적 + 학과 JOIN
        ↓
음악학과 필터
        ↓
학생별 GROUP BY
        ↓
AVG(POINT)
        ↓
ROUND(..., 1)

실행 결과는 8명이었다.

Q17. 최경희 학생과 같은 과 학생 조회

SELECT S.STUDENT_NAME,
       S.STUDENT_ADDRESS
FROM tb_student S
WHERE DEPARTMENT_NO = (
    SELECT S.DEPARTMENT_NO
    FROM tb_student S
    WHERE S.STUDENT_NAME = '최경희'
);

흐름

최경희
  ↓
DEPARTMENT_NO 조회
  ↓
같은 DEPARTMENT_NO 학생 조회
  ↓
이름 + 주소

실행 결과는 17행이었다.

Q18. 국어국문학과 최고 평점 학생

앞에서 배운 중첩 서브쿼리와 RANK() 풀이를 적용한 문제였다.

국어국문학과 찾기
      ↓
학생별 평균 계산
      ↓
최고 평균 계산
      ↓
최고 평점 학생 조회

이 문제는 오늘 서브쿼리 단원의 종합 예제에 가까웠다.

Q19. 환경조경학과와 같은 계열 학과의 전공평점

SELECT D.DEPARTMENT_NAME AS '계열학과명',
       ROUND(AVG(G.POINT), 1) AS '전공평점'
FROM tb_student S
JOIN tb_department D
  ON D.DEPARTMENT_NO = S.DEPARTMENT_NO
JOIN tb_grade G
  ON S.STUDENT_NO = G.STUDENT_NO
JOIN tb_class C
  ON D.DEPARTMENT_NO = C.DEPARTMENT_NO
WHERE D.CATEGORY = (
    SELECT CATEGORY
    FROM tb_department
    WHERE DEPARTMENT_NAME = '환경조경학과'
)
  AND C.CLASS_TYPE LIKE '%전공%'
GROUP BY D.DEPARTMENT_NAME;

흐름

환경조경학과
      ↓
CATEGORY 조회
      ↓
같은 계열 학과 조회
      ↓
전공 과목 조건
      ↓
학과별 GROUP BY
      ↓
AVG + ROUND

실행 결과는 화면 기준 20행이었다.

17. DDL

서브쿼리 실습 이후에는 DDL로 넘어갔다.

DDL은 데이터 자체를 조회·수정하는 것이 아니라 데이터를 저장할 구조를 정의하는 SQL이다.

DDL
→ Data Definition Language

대표 명령어:

CREATE
→ 생성

ALTER
→ 수정

DROP
→ 삭제

DDL을 통해:

Database
Table
View
Constraint

등의 구조를 정의한다.

18. CREATE TABLE 기본 구조

강의에서 확인한 기본 형태:

CREATE TABLE TABLE_NAME (
    COLUMN_NAME DATATYPE(SIZE) [DEFAULT] [CONSTRAINT TYPE],
    [CONSTRAINT TYPE]
);

구조:

컬럼명
+
데이터 타입
+
기본값
+
제약조건

19. 제약조건

오늘 배운 주요 제약조건은 다음과 같다.

제약조건	의미
`PRIMARY KEY`	행을 유일하게 식별
`FOREIGN KEY`	다른 테이블의 키 참조
`NOT NULL`	NULL 입력 불가
`UNIQUE`	중복값 입력 불가
`CHECK`	지정 조건을 만족하는 값만 허용
`DEFAULT`	값이 생략될 때 기본값 사용

20. EMPLOYEE 테이블 생성

실제 EMPLOYEE 테이블을 생성하며 다양한 제약조건을 확인했다.

CREATE TABLE EMPLOYEE (
    EMP_ID     CHAR(3) PRIMARY KEY,
    EMP_NAME   VARCHAR(20) NOT NULL,
    EMP_NO     CHAR(14) NOT NULL,
    EMAIL      VARCHAR(25),
    PHONE      VARCHAR(12),
    HIRE_DATE  DATE DEFAULT NOW(),
    JOB_ID     CHAR(2),
    SALARY     INT,
    BONUS_PCT  INT,
    MARRIAGE   CHAR(1) DEFAULT 'N',
    MGR_ID     CHAR(3),
    DEPT_ID    CHAR(2) REFERENCES DEPARTMENT(DEPT_ID),

    FOREIGN KEY(JOB_ID) REFERENCES JOB(JOB_ID),
    CHECK (MARRIAGE IN ('Y', 'N')),
    UNIQUE(EMP_NO)
);

여기서:

EMP_ID
→ PRIMARY KEY

EMP_NAME
EMP_NO
→ NOT NULL

HIRE_DATE
→ DEFAULT NOW()

MARRIAGE
→ DEFAULT 'N'
→ CHECK ('Y', 'N')

JOB_ID
→ JOB 테이블 FOREIGN KEY

DEPT_ID
→ DEPARTMENT 테이블 참조

EMP_NO
→ UNIQUE

를 확인했다.

21. Column Constraint vs Table Constraint

제약조건은 컬럼을 선언하면서 작성할 수도 있고, 테이블 선언 마지막에 별도로 작성할 수도 있다.

Column Constraint

BLOG_ID VARCHAR(50) PRIMARY KEY

Table Constraint

PRIMARY KEY (BLOG_ID)

Column Constraint
→ 컬럼 옆에서 바로 선언

Table Constraint
→ 컬럼 정의 후 별도로 선언

22. DATABASE와 TABLE 생성 실습

DROP DATABASE IF EXISTS TABLEDB;
CREATE DATABASE TABLEDB;

USE TABLEDB;

DROP DATABASE IF EXISTS
→ DB가 존재하면 삭제

CREATE DATABASE
→ 데이터베이스 생성

USE
→ 사용할 데이터베이스 선택

이후 TB_BLOG 테이블을 만들었다.

DROP TABLE IF EXISTS TB_BLOG;

CREATE TABLE TB_BLOG (
    BLOG_ID   VARCHAR(50),
    TITLE     VARCHAR(100),
    CONTENT   VARCHAR(100),
    EMAIL     VARCHAR(100),
    CREATE_AT DATE,

    PRIMARY KEY (BLOG_ID)
);

23. PRIMARY KEY 중복 오류

TB_BLOG에 데이터를 INSERT하면서 PK 제약조건을 직접 확인했다.

INSERT INTO TB_BLOG(
    BLOG_ID,
    TITLE,
    CONTENT,
    EMAIL,
    CREATE_AT
)
VALUES(
    '1',
    '휴',
    '하루 마무리',
    'jslim9413@naver.com',
    SYSDATE()
);

같은 BLOG_ID = '1'을 다시 입력하자:

SQL 오류 (1062)
Duplicate entry '1' for key 'PRIMARY'

가 발생했다.

원인

BLOG_ID
→ PRIMARY KEY
→ 중복 불가

해결

다른 식별자를 사용하거나 기존 데이터를 제거해야 한다.

24. PRIMARY KEY NULL 오류

다음으로:

INSERT INTO TB_BLOG(BLOG_ID, TITLE, CONTENT, EMAIL)
VALUES(
    NULL,
    '휴',
    '하루 마무리',
    'jslim9413@naver.com'
);

을 실행했다.

오류:

SQL 오류 (1048)
Column 'BLOG_ID' cannot be null

원인

PRIMARY KEY는:

UNIQUE
+
NOT NULL

특성을 가진다.

따라서:

중복값 ❌
NULL ❌

이다.

25. DEFAULT

테이블을 다시 생성하면서:

CREATE_AT DATE DEFAULT SYSDATE()

를 지정했다.

그러면 INSERT에서 CREATE_AT을 생략해도:

INSERT INTO TB_BLOG(BLOG_ID, TITLE, CONTENT, EMAIL)
VALUES(
    '1',
    '휴',
    '하루 마무리',
    'jslim9413@naver.com'
);

현재 날짜가 자동으로 들어간다.

INSERT에서 CREATE_AT 생략
        ↓
DEFAULT SYSDATE()
        ↓
현재 날짜 자동 입력

26. CHECK 제약조건

CATEGORY 컬럼을 추가하고 입력 가능한 값을 제한했다.

CREATE TABLE TB_BLOG (
    BLOG_ID   VARCHAR(50),
    TITLE     VARCHAR(100),
    CONTENT   VARCHAR(100),
    EMAIL     VARCHAR(100),
    CATEGORY  VARCHAR(100)
              CHECK(CATEGORY IN ('전체', '취미', '일상', '코딩')),
    CREATE_AT DATE DEFAULT SYSDATE(),

    PRIMARY KEY (BLOG_ID)
);

허용되는 값:

전체
취미
일상
코딩

INSERT:

INSERT INTO TB_BLOG(BLOG_ID, CATEGORY)
VALUES('1', '전체');

실행 결과:

BLOG_ID   → 1
TITLE     → NULL
CONTENT   → NULL
EMAIL     → NULL
CATEGORY  → 전체
CREATE_AT → 2026-08-27

여기서 확인한 것은:

CHECK
→ CATEGORY 값 제한

DEFAULT
→ CREATE_AT 자동 입력

NOT NULL이 없는 컬럼
→ 값 생략 시 NULL 가능

이었다.

오늘의 문제 해결 과정

오늘은 서브쿼리와 DDL 모두에서 오류가 왜 발생했는지를 직접 확인하고 쿼리를 수정하는 과정이 많았다.

1. 부서별 최소급여를 SALARY만 비교했더니 잘못된 사원이 조회된 문제

증상

WHERE SALARY IN (
    SELECT MIN(SALARY)
    FROM employee
    GROUP BY DEPT_ID
)

로 작성했더니 각 부서의 실제 최소급여자가 아닌 사원도 포함됐다.

원인

서브쿼리는:

부서별 최소급여 "값"

만 반환했다.

외부에서는 부서번호를 확인하지 않았기 때문에:

다른 부서의 최소급여와 같은 급여

만 받아도 조건을 통과했다.

해결

WHERE (DEPT_ID, SALARY) IN (
    SELECT DEPT_ID,
           MIN(SALARY)
    FROM employee
    GROUP BY DEPT_ID
)

로 변경했다.

검증

DEPT_ID + SALARY가 같은 쌍만 비교되면서 각 부서의 실제 최소급여자만 조회됐다.

배운 점

여러 값의 관계가 중요한 문제
→ 단일컬럼 비교보다 다중컬럼 비교 고려

2. JOB_ID가 ambiguous하다는 오류

증상

SQL 오류 (1052)
Column 'JOB_ID' in IN/ALL/ANY is ambiguous

원인

외부 쿼리에:

employee E
job J

가 있고 둘 다 JOB_ID를 가지고 있었다.

그 상태에서:

WHERE (JOB_ID, SALARY) IN (...)

라고 작성하면 어느 테이블의 JOB_ID인지 DB가 알 수 없다.

해결

WHERE (J.JOB_ID, E.SALARY) IN (...)

처럼 별칭을 명확하게 지정했다.

배운 점

JOIN 후 동일한 컬럼명이 여러 테이블에 존재하면:

컬럼명만 사용 ❌
테이블별칭.컬럼명 ⭕

으로 작성하는 것이 안전하다.

3. Inline View에서 부서명과 MAX 값이 잘못 붙은 문제

부서별 급여총합의 최대값을 구하면서:

SELECT V.DEPT_NAME,
       MAX(V.SUM)

형태로 작성했을 때 최대 금액과 부서명이 정확히 대응되지 않는 문제가 발생했다.

원인

집계 함수의 최대값은 구했지만:

그 MAX 값을 가진 행

을 찾은 것이 아니었다.

해결

ORDER BY S DESC
LIMIT 1

로 최대값을 가진 행 자체를 조회했다.

SELECT D.DEPT_NAME,
       SUM(E.SALARY) AS S
FROM employee E
JOIN department D
  ON E.DEPT_ID = D.DEPT_ID
GROUP BY E.DEPT_ID
ORDER BY S DESC
LIMIT 1;

배운 점

MAX(value)
→ 최대값

최대값을 가진 행
→ 별도의 조건/정렬 필요

라는 차이를 구분해야 한다.

4. 상관 서브쿼리의 반복 실행 문제

문제

상관 서브쿼리는 외부 행을 참조하기 때문에 외부 행마다 내부 쿼리가 반복 실행될 수 있다.

사원 8만 명
→ 내부 평균 계산 최대 8만 번

개선

GROUP BY로 평균을 먼저 한 번 계산
        ↓
Inline View
        ↓
JOIN

하는 구조로 바꿀 수 있다.

배운 점

SQL은:

"정답이 나오는가?"

뿐 아니라:

"같은 계산을 얼마나 반복하는가?"

도 고려해야 한다.

5. PRIMARY KEY 중복 오류

증상

Duplicate entry '1' for key 'PRIMARY'

원인

이미 존재하는 BLOG_ID = '1'을 다시 INSERT했다.

해결

다른 PK를 사용하거나 기존 데이터를 삭제해야 한다.

배운 점

PRIMARY KEY
→ 중복 불가

라는 규칙이 실제 INSERT 시점에서 DB에 의해 검증된다.

6. PRIMARY KEY NULL 오류

증상

Column 'BLOG_ID' cannot be null

원인

PK 컬럼에 NULL을 넣었다.

배운 점

PRIMARY KEY
→ UNIQUE
→ NOT NULL

두 특성을 동시에 가진다.

✨ 오늘 배운 점

오늘은 서브쿼리의 종류를 단순히 외우는 것보다 어떤 값을 몇 개 반환하는지에 따라 어떤 연산자를 선택해야 하는지가 중요했다.

단일행
→ 일반 비교 연산자

다중행
→ IN / ANY / ALL

다중컬럼
→ (A, B) 형태로 값의 관계까지 함께 비교

특히 ANY / ALL은 처음에는 문장만 보면 헷갈렸지만:

> ANY
→ 최솟값보다 크면 됨

> ALL
→ 최댓값보다 커야 함

< ANY
→ 최댓값보다 작으면 됨

< ALL
→ 최솟값보다 작아야 함

으로 바꿔 생각하니 이해하기 쉬웠다.

또 하나의 요구사항을:

다중열 IN
Inline View + JOIN
Correlated Subquery

세 가지 방법으로 구현해보면서 SQL에는 하나의 정답만 있는 것이 아니라는 점도 확인했다.

오늘의 회고

오늘 수업에서 가장 인상적이었던 부분은 서브쿼리를 단순한 문법이 아니라 실행 방식과 성능까지 연결해서 배웠다는 점이었다.

처음에는:

WHERE 안에 SELECT를 넣는다.

정도로만 생각했는데, 오늘 수업을 통해:

서브쿼리가 몇 행을 반환하는가?
몇 컬럼을 반환하는가?
어디에 위치하는가?
외부 쿼리를 참조하는가?
몇 번 반복 실행될 수 있는가?

까지 고려해야 한다는 것을 알게 됐다.

특히 상관 서브쿼리에서는:

코드는 간단함
        ↓
하지만 외부 Row마다 반복 실행 가능
        ↓
데이터가 많으면 성능 문제 가능

이라는 흐름이 기억에 남았다.

이후 Inline View에서 먼저 집계한 뒤 JOIN하는 방식과 비교하면서 쿼리 구조가 실행 비용에도 영향을 준다는 점을 이해할 수 있었다.

DDL 파트에서는 이전까지 이미 만들어진 테이블을 조회하는 입장이었다면 오늘은 직접:

Database 생성
Table 생성
Column 정의
Constraint 정의

를 하면서 DB 구조 자체를 만드는 쪽으로 넘어갔다.

특히:

PRIMARY KEY 선언
        ↓
중복 INSERT
        ↓
오류

PRIMARY KEY 선언
        ↓
NULL INSERT
        ↓
오류

를 직접 확인하면서 제약조건이 단순한 문법이 아니라 잘못된 데이터가 DB에 들어가는 것을 실제로 차단하는 규칙이라는 점이 명확해졌다.

다음 학습 방향

오늘 마지막 기준 과제 범위는:

[Additional SELECT - Option]
Q1 ~ Q19

까지이다.

다음 학습에서는 특히 다음 기준으로 문제를 풀어봐야겠다.

1. 서브쿼리가 몇 개의 행을 반환하는지 먼저 판단
        ↓
2. 단일행이면 일반 비교 연산자
   다중행이면 IN / ANY / ALL 고려
        ↓
3. 컬럼 간 관계까지 비교해야 한다면 다중컬럼 서브쿼리 고려
        ↓
4. GROUP BY 결과 조건이면 HAVING
        ↓
5. 같은 집계를 반복한다면 Inline View + JOIN 검토
        ↓
6. 외부 컬럼을 내부 쿼리가 참조한다면 Correlated Subquery
        ↓
7. 결과만 맞는지보다 실행 구조도 확인

DDL에서는 다음 내용을 계속 복습할 예정이다.

CREATE
DROP
ALTER

PRIMARY KEY
FOREIGN KEY
NOT NULL
UNIQUE
CHECK
DEFAULT

Column Constraint
vs
Table Constraint

다음 수업에서는 오늘 생성한 테이블을 기준으로 ALTER를 이용한 구조 변경이나 다른 제약조건 실습이 더 이어질 것 같다.

[LG CNS 6기] 21일차 TIL : GROUP BY·HAVING·Window Function·정규화·JOIN

bbbicsan — Wed, 26 Aug 2026 17:41:13 +0900

[LG CNS 6기] 21일차 TIL : GROUP BY·HAVING·Window Function·정규화·JOIN

한 줄 요약
GROUP BY와 HAVING을 이용한 그룹 집계부터 ROLLUP, Window Function, 정규화, Mapping Rule, 다양한 JOIN 방식까지 학습하며 분리된 관계형 데이터를 집계하고 다시 연결하는 전체 흐름을 이해했다.

오늘 학습한 커리큘럼

GROUP BY
   ↓
그룹 함수
COUNT / SUM / AVG / MIN / MAX
   ↓
WHERE vs HAVING
   ↓
CASE + GROUP BY
   ↓
WITH ROLLUP
소계 / 전체 합계
   ↓
Window Function
OVER / PARTITION BY
   ↓
RANK()
전체 순위 / 부서별 순위
   ↓
Additional SELECT - 함수 실습
Q10 / Q12 / Q13 / Q14 / Q15
   ↓
정규화
1NF / 2NF / 3NF
   ↓
Mapping Rule
ERD → Relational Schema
   ↓
JOIN
Cartesian Product
INNER JOIN
USING / ON
Non-Equi Join
LEFT JOIN
Self Join
EXISTS
   ↓
Additional SELECT - Option
Q1 ~ Q14 과제

오늘의 학습 키워드

GROUP BY
HAVING
WHERE
COUNT()SUM()AVG()MAX()
CASE
WITH ROLLUP
Window Function
OVER()
PARTITION BY
RANK()
Normalization
1NF / 2NF / 3NF
Mapping Rule
PK / FK
JOIN
Cartesian Product
INNER JOIN
LEFT JOIN
USING
ON
Non-Equi Join
Self Join
EXISTS

1. GROUP BY

오늘 SQL Day03의 첫 번째 주제는 GROUP BY였다.

GROUP BY는 특정 컬럼에서 동일한 값을 가지는 행들을 하나의 그룹으로 묶어서 통계 또는 집계 처리할 때 사용한다.

여러 개의 Row
      ↓
같은 값을 기준으로 묶기
      ↓
GROUP BY
      ↓
COUNT / SUM / AVG / MIN / MAX
      ↓
그룹별 집계 결과

기본 형태는 다음과 같다.

GROUP BY column
GROUP BY expr
GROUP BY position

예를 들어 부서별 최고 급여를 구한다면 다음과 같이 작성할 수 있다.

SELECT DEPT_ID,
       MAX(SALARY)
FROM employee
GROUP BY DEPT_ID;

DEPT_ID
   ↓
같은 부서끼리 그룹화
   ↓
MAX(SALARY)
   ↓
부서별 최고 급여

DEPT_ID가 NULL인 사원들도 하나의 NULL 그룹으로 묶여 집계되는 것을 확인했다.

2. WHERE와 HAVING

오늘 가장 중요했던 개념 중 하나는 WHERE와 HAVING의 차이였다.

SELECT DEPT_ID,
       SUM(SALARY)
FROM employee
WHERE SALARY >= 3000000
GROUP BY DEPT_ID
HAVING SUM(SALARY) >= 4000000;

처리 흐름은 다음과 같다.

employee
    ↓
WHERE SALARY >= 3000000
    ↓
급여 300만원 이상인 개별 사원만 필터링
    ↓
GROUP BY DEPT_ID
    ↓
부서별 그룹 생성
    ↓
SUM(SALARY)
    ↓
부서별 급여 합계
    ↓
HAVING SUM(SALARY) >= 4000000
    ↓
집계 결과가 조건을 만족하는 부서만 조회

실행 결과:

DEPT_ID | SUM(SALARY)
60      | 7,300,000
90      | 18,100,000

정리하면:

구분	적용 시점	조건 대상
`WHERE`	`GROUP BY` 이전	개별 Row
`HAVING`	`GROUP BY` 이후	Group / 집계 결과

WHERE
→ "어떤 행을 그룹화할 것인가?"

HAVING
→ "만들어진 그룹 중 어떤 그룹을 남길 것인가?"

3. CASE + GROUP BY

CASE로 새로운 분류값을 만든 뒤 해당 값을 기준으로 그룹화할 수도 있었다.

SELECT CASE
           WHEN SALARY <= 3000000 THEN '초급'
           WHEN SALARY <= 4000000 THEN '중급'
           ELSE '고급'
       END AS GRADE,
       COUNT(*) AS COUNT
FROM employee
GROUP BY GRADE
ORDER BY COUNT DESC;

실행 결과:

초급 → 15명
중급 → 5명
고급 → 2명

흐름:

SALARY
   ↓
CASE
   ↓
초급 / 중급 / 고급
   ↓
GROUP BY GRADE
   ↓
COUNT(*)
   ↓
등급별 인원수

GRADE는 실제 테이블에 존재하는 컬럼이 아니라 CASE로 만들어진 파생 값이다.

SQL에서는 이렇게 가공한 결과를 다시 그룹화에 활용할 수 있다는 점이 인상적이었다.

4. WITH ROLLUP

WITH ROLLUP은 GROUP BY 결과에 소계와 전체 합계를 함께 추가한다.

SELECT GROUPNAME,
       NUM,
       SUM(PRICE * AMOUNT)
FROM buyTbl
GROUP BY GROUPNAME, NUM WITH ROLLUP;

결과 구조는 다음과 같다.

GROUPNAME + NUM
→ 상세 집계

GROUPNAME + NULL
→ 해당 GROUPNAME의 소계

NULL + NULL
→ 전체 합계

예:

의류 | 5    | 150
의류 | 9    | 50
의류 | NULL | 200

여기서:

의류 | NULL | 200

은 ROLLUP이 추가한 의류 그룹의 소계이다.

다만 원본 데이터에도 NULL이 존재할 수 있기 때문에 실제 NULL과 ROLLUP이 생성한 NULL의 의미를 구분하여 해석해야 한다.

5. Window Function

GROUP BY 이후에는 Window Function, 즉 분석 함수를 학습했다.

SELECT EMP_NAME,
       SALARY,
       DEPT_ID,
       AVG(SALARY) OVER(PARTITION BY DEPT_ID) AS 'DAVG'
FROM employee;

핵심은 기존 행을 유지하면서 집계 결과를 추가한다는 것이다.

employee 각 사원
      ↓
PARTITION BY DEPT_ID
      ↓
부서별 논리적 파티션 생성
      ↓
AVG(SALARY)
      ↓
부서 평균 계산
      ↓
기존 사원 행 옆에 평균값 추가

6. GROUP BY vs Window Function

두 방식의 차이를 비교하면 이해하기 쉽다.

GROUP BY

사원 A ┐
사원 B ├─ 부서 10
사원 C ┘
   ↓
GROUP BY
   ↓
부서10 | 평균급여

여러 행이 그룹별 한 행으로 축약된다.

Window Function

사원 A | 부서10 | 급여 | 부서평균
사원 B | 부서10 | 급여 | 부서평균
사원 C | 부서10 | 급여 | 부서평균

원래 행은 그대로 유지되고 분석 결과만 추가된다.

GROUP BY
→ 결과 행 수 감소 가능

Window Function
→ 기존 행 유지
→ 분석 컬럼 추가

7. RANK()

급여를 기준으로 전체 사원 순위를 매겼다.

SELECT EMP_NAME,
       SALARY,
       RANK() OVER(ORDER BY SALARY DESC) AS 'RANK'
FROM employee;

RANK()의 중요한 특징은 동점 처리이다.

2,600,000 → 9위
2,600,000 → 9위
2,500,000 → 11위

RANK()
→ 1, 2, 2, 4

DENSE_RANK()
→ 1, 2, 2, 3

ROW_NUMBER()
→ 1, 2, 3, 4

RANK()는 동점자에게 같은 순위를 부여하고 다음 순위를 건너뛴다.

8. PARTITION BY를 이용한 부서별 순위

강사님 Q)

부서별 급여 순위를 검색한다면?
부서마다 따로 순위를 정하고 싶다면?

SELECT EMP_NAME,
       DEPT_ID,
       SALARY,
       RANK() OVER(
           PARTITION BY DEPT_ID
           ORDER BY SALARY DESC
       ) AS 'RANK'
FROM employee;

PARTITION BY DEPT_ID
→ 부서마다 순위 계산 영역 분리

ORDER BY SALARY DESC
→ 부서 내부에서 급여 내림차순 정렬

RANK()
→ 순위 부여

따라서 부서가 변경되면 다시 1위부터 시작한다.

오늘의 실습 문제 풀이

오늘은 개념을 배운 뒤 강사님이 바로 문제를 제시하고 SQL로 구현하는 실습이 많이 진행됐다.

실습 1. 부서별 급여 총액 조건 검색

Q.

부서별 급여 총액이
9,000,000 이상인 부서만 검색한다면?

처음 시도

SELECT DEPT_ID,
       SUM(SALARY)
FROM employee
WHERE SUM(SALARY) >= 9000000
GROUP BY DEPT_ID;

실행 결과:

SQL 오류 (1111)
Invalid use of group function

최종 풀이

SELECT DEPT_ID,
       SUM(SALARY)
FROM employee
GROUP BY DEPT_ID
HAVING SUM(SALARY) >= 9000000;

핵심

SUM(SALARY)
→ GROUP BY 이후 만들어지는 값

따라서
WHERE ❌
HAVING ⭕

이 문제를 통해 WHERE와 HAVING의 차이를 가장 명확하게 이해할 수 있었다.

실습 2. 사용자별 총 구매액

Q.

사용자별 구매총액을 검색한다면?

풀이

SELECT USERID,
       SUM(PRICE * AMOUNT)
FROM buyTbl
GROUP BY USERID;

실행 결과

BBK → 1,920
EJW → 95
JYP → 200
KBS → 1,210
SSK → 75

풀이 흐름

PRICE * AMOUNT
→ 한 구매 건의 비용

GROUP BY USERID
→ 같은 사용자끼리 그룹

SUM(...)
→ 사용자별 전체 구매액

실습 3. 사용자별 평균 구매 개수

Q.

사용자별 평균 구매 개수를 검색한다면?

풀이

SELECT USERID,
       ROUND(AVG(AMOUNT))
FROM buyTbl
GROUP BY USERID;

실행 결과

BBK → 5
EJW → 1
JYP → 1
KBS → 2
SSK → 5

핵심

AVG()
→ 그룹별 평균

ROUND()
→ 평균 결과 반올림

복수행 함수의 결과를 다시 단일행 함수로 처리한 실습이었다.

실습 4. 특정 부서 + 부서 미배정 사원 조회

Q.

부서번호가 50번이거나
부서가 없는 사원의 이름, 주민번호, 급여를 출력하되
급여가 많은 사원부터 조회한다면?

풀이

SELECT EMP_NAME,
       EMP_NO,
       SALARY
FROM employee
WHERE DEPT_ID = '50'
   OR DEPT_ID IS NULL
ORDER BY SALARY DESC;

핵심

DEPT_ID = '50'
OR
DEPT_ID IS NULL

→ 두 조건 중 하나를 만족하는 사원

ORDER BY SALARY DESC
→ 급여 높은 순

총 8명의 사원이 조회됐다.

실습 5. 성별 평균 급여

Q.

위 결과를 바탕으로
성별에 따른 평균 급여를 검색한다면?

풀이

SELECT CASE
           WHEN SUBSTRING(EMP_NO, 8, 1) IN ('1', '3') THEN '남자'
           WHEN SUBSTRING(EMP_NO, 8, 1) IN ('2', '4') THEN '여자'
       END AS GENDER,
       AVG(SALARY)
FROM employee
WHERE DEPT_ID = '50'
   OR DEPT_ID IS NULL
GROUP BY GENDER
ORDER BY 2 DESC;

실행 결과

남자 → 2,400,000
여자 → 2,080,000

풀이 흐름

WHERE
→ 대상 사원 선택

SUBSTRING()
→ 주민번호 뒷자리 첫 숫자 추출

CASE
→ 남자 / 여자 분류

GROUP BY
→ 성별 그룹화

AVG()
→ 성별 평균 급여

실습 6. 사용자별 구매액이 일정 금액 이상인 사용자

Q.

사용자별 총 구매액이
100 이상인 사용자만 검색한다면?

풀이

SELECT USERID AS '아이디',
       SUM(PRICE * AMOUNT) AS '총 구매액'
FROM buyTbl
GROUP BY USERID
HAVING SUM(PRICE * AMOUNT) >= 100
ORDER BY 2 DESC;

실행 결과

BBK → 1,920
KBS → 1,210
JYP → 200

핵심

GROUP BY
→ 사용자별 그룹 생성

SUM
→ 총 구매액 계산

HAVING
→ 계산된 총 구매액 조건

ORDER BY
→ 집계 결과 정렬

실습 7. 그룹별 구매비용 + ROLLUP

Q.

구매한 목록 중
그룹이름별 구매비용을 검색한다면?

GROUP BY에서 더 나아가 WITH ROLLUP까지 실습했다.

SELECT GROUPNAME,
       NUM,
       SUM(PRICE * AMOUNT)
FROM buyTbl
GROUP BY GROUPNAME, NUM WITH ROLLUP;

핵심

상품별 구매비용
      ↓
GROUPNAME별 집계
      ↓
WITH ROLLUP
      ↓
상세
+ 그룹별 소계
+ 전체 합계

실습 8. Window Function으로 부서 평균 표시

Q.

각 사원의 정보는 유지하면서
부서별 평균 급여를 함께 출력한다면?

풀이

SELECT EMP_NAME,
       SALARY,
       DEPT_ID,
       AVG(SALARY) OVER(
           PARTITION BY DEPT_ID
       ) AS 'DAVG'
FROM employee;

핵심

GROUP BY
→ 행 축약

OVER(PARTITION BY ...)
→ 행 유지
→ 부서 평균 컬럼 추가

실습 9. 전체 급여 순위

Q.

급여 순위를 검색한다면?

풀이

SELECT EMP_NAME,
       SALARY,
       RANK() OVER(
           ORDER BY SALARY DESC
       ) AS 'RANK'
FROM employee;

핵심

RANK()는 동점자는 같은 순위를 가지고 다음 순위는 건너뛴다.

실습 10. 부서별 급여 순위

Q.

부서별 급여 순위를 검색한다면?
부서마다 따로 순위를 정하고 싶다면?

풀이

SELECT EMP_NAME,
       DEPT_ID,
       SALARY,
       RANK() OVER(
           PARTITION BY DEPT_ID
           ORDER BY SALARY DESC
       ) AS 'RANK'
FROM employee;

핵심

PARTITION BY
→ 순위를 다시 시작할 범위

ORDER BY
→ 해당 범위 안의 순위 기준

Additional SELECT - 함수 실습

전날 스킵했던 문제:

7 / 10 / 12 / 13 / 14 / 15

중 7번을 제외한 문제를 오늘 구현했다.

Q10. 학과별 학생 수

문제

학과별 학생 수를 검색한다면?

풀이

SELECT DEPARTMENT_NO AS '학과번호',
       COUNT(STUDENT_NO) AS '학생수(명)'
FROM TB_STUDENT
GROUP BY DEPARTMENT_NO;

실행 결과 일부

접근 과정

학생 수를 학과별로 알고 싶다.
      ↓
학과번호가 같은 학생끼리 그룹화
      ↓
GROUP BY DEPARTMENT_NO
      ↓
COUNT(STUDENT_NO)

Q12. 학생의 년도별 평점

문제

A112113 학생의 년도별 평점을 구한다면?

풀이 1

SELECT SUBSTRING(TERM_NO, 1, 4) AS '년도',
       ROUND(AVG(POINT), 1) AS '년도 별 평점'
FROM tb_grade
WHERE STUDENT_NO = 'A112113'
GROUP BY 1
ORDER BY 1;

실행 결과

다른 풀이

SELECT LEFT(TERM_NO, 4) AS '년도',
       ROUND(AVG(POINT), 1) AS '년도 별 평점'
FROM tb_grade
WHERE STUDENT_NO = 'A112113'
GROUP BY LEFT(TERM_NO, 4);

문제 해결 포인트

처음에는 TERM_NO가 학기까지 포함하고 있기 때문에 그대로 그룹화하면 년도별 평균을 구할 수 없다.

TERM_NO
→ 200101
→ 200102
→ 200201
...

따라서:

SUBSTRING 또는 LEFT
→ 앞 4자리만 추출
→ 2001 / 2002 / 2003 / 2004
→ 년도별 GROUP BY

로 해결했다.

Q13. 학과별 휴학생 수

문제

학과별 휴학생 수를 검색한다면?
휴학생이 0명인 학과도 표시한다.

풀이

SELECT b.DEPARTMENT_NO,
       COUNT(a.STUDENT_NO) AS 휴학생수
FROM tb_department b
LEFT JOIN tb_student a
       ON b.DEPARTMENT_NO = a.DEPARTMENT_NO
      AND a.ABSENCE_YN = 'Y'
GROUP BY b.DEPARTMENT_NO;

실행 결과 일부

문제 해결 포인트

단순히:

WHERE ABSENCE_YN = 'Y'

만 사용해서 학생 테이블을 그룹화하면 휴학생이 없는 학과는 애초에 결과에 나타나지 않는다.

그래서 기준을 tb_department로 잡았다.

모든 학과
      ↓
LEFT JOIN
      ↓
휴학생이 있으면 매칭
휴학생이 없어도 학과는 유지
      ↓
COUNT(a.STUDENT_NO)

또한 조건을 WHERE가 아니라 ON에 작성했다.

AND a.ABSENCE_YN = 'Y'

이를 통해 LEFT JOIN으로 유지해야 하는 학과가 사라지는 것을 방지했다.

Q14. 동명이인 학생 찾기

문제

학생들 중 동명이인의 이름과
동명인 수를 출력한다면?

풀이

SELECT STUDENT_NAME AS '동명이인',
       COUNT(*) AS '동명인 수'
FROM tb_student
GROUP BY 1
HAVING COUNT(*) > 1
ORDER BY 1;

실행 결과 일부

김경민 → 2
김명철 → 2
김영호 → 2
김보람 → 3
...

문제 해결 포인트

같은 이름끼리 그룹화
      ↓
COUNT(*)
      ↓
같은 이름이 몇 명인지 계산
      ↓
2명 이상만 필요
      ↓
HAVING COUNT(*) > 1

COUNT(*) > 1은 그룹화 후 알 수 있는 결과이므로 WHERE가 아니라 HAVING을 사용해야 했다.

Q15. 년도·학기별 평점 + 년도별 평점 + 총평점

문제

A112113 학생의

년도별
학기별
평점
년도별 누적 평점
총평점

을 출력한다면?

풀이

SELECT SUBSTRING(TERM_NO, 1, 4) AS '년도',
       SUBSTRING(TERM_NO, 5, 2) AS '학기',
       ROUND(AVG(POINT), 1) AS '평점'
FROM tb_grade
WHERE STUDENT_NO = 'A112113'
GROUP BY SUBSTRING(TERM_NO, 1, 4),
         SUBSTRING(TERM_NO, 5, 2)
WITH ROLLUP;

실행 결과 구조

2003 | 01   | 3.5
2003 | 02   | 4.5
2003 | 03   | 4.0
2003 | NULL | 4.0  ← 2003년 평균

2004 | 01   | 4.0
2004 | 02   | 3.0
2004 | NULL | 3.5  ← 2004년 평균

NULL | NULL | 3.2  ← 전체 평점

문제 해결 포인트

단순 GROUP BY만으로는:

년도 + 학기

단위의 평균만 구할 수 있다.

하지만 문제에서는:

학기별 평균
+
년도별 평균
+
전체 평균

이 모두 필요했다.

그래서 WITH ROLLUP을 이용했다.

년도 + 학기
→ 세부 평균

년도 + NULL
→ 년도별 평균

NULL + NULL
→ 전체 평균

9. 정규화(Normalization)

SQL 집계 실습 이후에는 데이터베이스 설계 개념인 정규화를 학습했다.

정규화의 목적은:

데이터 중복 방지
      ↓
효율적인 데이터 저장
      ↓
불필요한 NULL 감소
      ↓
각 속성을 적절한 테이블에 배치
      ↓
논리적으로 작은 단위의 테이블로 분리

하는 것이다.

10. 제1정규화(1NF)

제1정규화의 핵심은 반복되는 속성 또는 반복 그룹을 제거하는 것이다.

예를 들어:

과정코드
과정명
교재1
교재2
교재3
교재4
교재5

처럼 교재라는 동일한 의미의 컬럼이 반복된다면 별도의 테이블로 분리한다.

과정
- 과정코드 PK
- 과정명
- 교육내용
- 교육기간

        1 : N

교재
- 교재번호 PK
- 교재명
- 과정코드 FK

회원과 자격증 관계 역시 같은 예였다.

회원
회원번호 PK
   │
   │ 1
   │
   └──── N
        자격증
        자격증ID PK
        회원번호 FK

11. 제2정규화(2NF)

제2정규화는 복합키의 일부에만 의존하는 부분 함수 종속을 제거하는 것이다.

예:

동아리등록

PK = 동아리코드 + 학번

등록일자
등록사유

정상적인 구조에서는:

동아리코드 + 학번
        ↓
등록일자
등록사유

처럼 일반 속성이 복합키 전체에 의존해야 한다.

하지만:

학번 → 전화번호
학번 → 주소
학번 → 우편번호

처럼 복합키 일부에만 의존하는 속성이 있다면 별도 테이블로 분리한다.

12. 제3정규화(3NF)

제3정규화는 키가 아닌 컬럼이 다른 키가 아닌 컬럼에 의존하는 이행적 종속을 제거한다.

예:

사원번호(PK)
      ↓
우편번호
      ↓
시도명
구군명
읍면동명
나머지 번지

즉:

사원번호
→ 우편번호
→ 주소정보

라는 관계가 존재한다.

이를 분리하면:

사원
- 사원번호 PK
- 이름
- 주민번호
- 우편번호 FK
- 입사일

주소
- 우편번호 PK
- 시도명
- 구군명
- 읍면동명
...

와 같은 구조가 된다.

13. 1NF / 2NF / 3NF 한 번에 정리

1NF
반복되는 속성이 있는가?
→ 반복 속성 제거

2NF
복합키 일부에만 의존하는 속성이 있는가?
→ 부분 함수 종속 제거

3NF
비키 컬럼이 다른 비키 컬럼을 결정하는가?
→ 이행적 종속 제거

14. Mapping Rule

ER Diagram에서 설계한 내용을 실제 관계형 데이터베이스 구조로 변환하는 과정을 Mapping Rule이라고 한다.

Conceptual Model
      ↓
ER Diagram
      ↓
Mapping Rule
      ↓
Relational Schema

대응 관계:

ER Model	Relational Database
Entity	Table
Attribute	Column
Identifier	Primary Key
Relationship	Foreign Key

Entity
→ Table

Attribute
→ Column

Identifier
→ PK

Relationship
→ FK

15. JOIN

정규화를 통해 여러 테이블로 나누어진 데이터를 다시 하나의 결과로 조회하기 위해 JOIN을 사용한다.

정규화
→ 테이블 분리

PK / FK
→ 테이블 간 관계 표현

JOIN
→ 관계를 이용하여 필요한 데이터를 결합

관계형 데이터베이스에서는:

1 : 1
1 : N
N : M

과 같은 관계를 기준으로 데이터를 연결한다.

JOIN 실습 문제

실습 11. JOIN 조건이 없으면 어떻게 될까?

처음 다음 SQL을 실행했다.

SELECT E.EMP_NAME,
       D.DEPT_NAME
FROM employee E,
     department D;

실행 결과:

154행

왜 154행인지 계산하면:

employee 22행
×
department 7행
=
154행

즉 모든 사원과 모든 부서가 한 번씩 조합됐다.

이를 Cartesian Product라고 한다.

실습 12. JOIN 조건 추가

SELECT E.EMP_NAME,
       D.DEPT_NAME
FROM employee E,
     department D
WHERE E.DEPT_ID = D.DEPT_ID;

조인 조건을 추가하자 결과가:

154행
↓
20행

으로 줄었다.

E.DEPT_ID
=
D.DEPT_ID

인 실제 관계가 존재하는 데이터만 남았기 때문이다.

실습 13. USING()으로 여러 테이블 JOIN

SELECT EMP_NAME,
       JOB_TITLE,
       DEPT_NAME
FROM job J
JOIN employee E USING(JOB_ID)
JOIN department D USING(DEPT_ID);

JOB
 ↓ JOB_ID
EMPLOYEE
 ↓ DEPT_ID
DEPARTMENT

두 테이블의 조인 컬럼 이름이 동일할 때 USING()을 사용하면 SQL을 더 간결하게 작성할 수 있다.

실습 14. ON으로 4개 테이블 JOIN

SELECT E.EMP_NAME,
       J.JOB_TITLE,
       D.DEPT_NAME,
       L.LOC_DESCRIBE
FROM job J
JOIN employee E
  ON J.JOB_ID = E.JOB_ID
JOIN department D
  ON E.DEPT_ID = D.DEPT_ID
JOIN location L
  ON L.LOCATION_ID = D.LOC_ID;

관계:

JOB
 ↓
EMPLOYEE
 ↓
DEPARTMENT
 ↓
LOCATION

복잡해 보이지만 실제로는 테이블을 한 개씩 관계를 따라 연결하는 과정이었다.

실습 15. 5개 테이블 JOIN

국가 정보까지 추가했다.

SELECT E.EMP_NAME,
       J.JOB_TITLE,
       D.DEPT_NAME,
       L.LOC_DESCRIBE,
       C.COUNTRY_NAME
FROM job J
JOIN employee E
  ON J.JOB_ID = E.JOB_ID
JOIN department D
  ON E.DEPT_ID = D.DEPT_ID
JOIN location L
  ON L.LOCATION_ID = D.LOC_ID
JOIN country C
  ON L.COUNTRY_ID = C.COUNTRY_ID;

JOB
 ↓
EMPLOYEE
 ↓
DEPARTMENT
 ↓
LOCATION
 ↓
COUNTRY

한 사원의:

이름
직급
부서
지역
국가

정보를 하나의 결과로 조회할 수 있었다.

실습 16. Non-Equi Join

이번에는 SAL_GRADE 테이블까지 추가했다.

SELECT E.EMP_NAME,
       J.JOB_TITLE,
       D.DEPT_NAME,
       L.LOC_DESCRIBE,
       C.COUNTRY_NAME,
       S.SLEVEL
FROM job J
JOIN employee E
  ON J.JOB_ID = E.JOB_ID
JOIN department D
  ON E.DEPT_ID = D.DEPT_ID
JOIN location L
  ON L.LOCATION_ID = D.LOC_ID
JOIN country C
  ON L.COUNTRY_ID = C.COUNTRY_ID
JOIN sal_grade S
  ON E.SALARY BETWEEN S.LOWEST AND S.HIGHEST
WHERE DEPT_NAME LIKE '해외%'
  AND LOC_DESCRIBE LIKE '아시아%';

기존 JOIN은 대부분:

A.ID = B.ID

처럼 같은 값을 비교했다.

하지만 급여등급은:

E.SALARY BETWEEN S.LOWEST AND S.HIGHEST

처럼 값이 특정 범위 안에 있는지 확인해야 했다.

Equi Join
→ =

Non-Equi Join
→ BETWEEN / > / <

실습 17. JYP 사용자의 구매상품

Q.

사용자 아이디가 JYP인 유저의
이름과 구매상품을 검색한다면?

풀이

SELECT U.NAME,
       B.PRODNAME
FROM buyTbl B
JOIN userTbl U
  ON B.USERID = U.USERID
WHERE U.USERID = 'JYP';

결과

조용필 | 모니터

실습 18. 회원과 구매정보 JOIN

Q.

사용자의 아이디,
이름,
구매상품,
연락처를 검색한다면?

풀이

SELECT U.USERID,
       U.NAME,
       B.PRODNAME,
       CONCAT(U.MOBILE1, U.MOBILE2) AS '연락처'
FROM userTbl U
JOIN buyTbl B USING(USERID);

USING(USERID)
→ 회원과 구매정보 연결

CONCAT()
→ 연락처 생성

실습 19. 구매이력이 있는 회원만 검색

Q.

위 요구사항에서
구매이력이 있는 회원만 검색한다면?

풀이

SELECT DISTINCT U.USERID,
                U.NAME,
                B.PRODNAME,
                U.ADDR,
                CONCAT(U.MOBILE1, '-', U.MOBILE2)
FROM userTbl U
JOIN buyTbl B
  ON U.USERID = B.USERID;

INNER JOIN은 두 테이블 모두에 관계가 존재하는 행만 반환하므로 구매이력이 있는 회원만 조회된다.

DISTINCT를 사용했지만 PRODNAME이 SELECT 목록에 포함되어 있기 때문에:

KBS | 김범수 | 운동화
KBS | 김범수 | 노트북
KBS | 김범수 | 청바지

처럼 같은 회원이라도 구매상품이 다르면 서로 다른 행으로 유지된다.

실습 20. EXISTS로 구매이력 확인

SELECT U.USERID,
       U.NAME,
       U.ADDR,
       CONCAT(U.MOBILE1, '-', U.MOBILE2)
FROM userTbl U
WHERE EXISTS (
    SELECT *
    FROM buyTbl B
    WHERE U.USERID = B.USERID
);

EXISTS는 값을 가져오는 것이 아니라 조건을 만족하는 행이 존재하는지 여부만 확인한다.

userTbl 회원
      ↓
buyTbl에 같은 USERID가 있는가?
      ↓
YES
      ↓
조회

JOIN과 비교하면:

INNER JOIN
→ 구매 건마다 회원 데이터가 반복될 수 있음

EXISTS
→ 구매이력이 존재하는지만 검사
→ 회원 기준 결과 유지

실습 21. LEFT JOIN

SELECT E.EMP_NAME,
       D.DEPT_NAME
FROM employee E
LEFT JOIN department D
       ON E.DEPT_ID = D.DEPT_ID;

LEFT JOIN은 왼쪽 employee 테이블의 행을 모두 유지한다.

부서 매칭 성공
→ 부서명 출력

부서 매칭 실패
→ DEPT_NAME = NULL

실행 결과에서도 employee 전체 22행이 유지됐다.

실습 22. Self Join

Q.

사원이름과 사수의 이름을 검색한다면?

같은 employee 테이블을 서로 다른 역할로 다시 JOIN했다.

SELECT E.EMP_NAME,
       M.EMP_NAME,
       S.EMP_NAME
FROM employee E
LEFT JOIN employee M
       ON E.MGR_ID = M.EMP_ID
LEFT JOIN employee S
       ON M.MGR_ID = S.EMP_ID;

각 alias의 역할:

E
→ 현재 사원

M
→ 현재 사원의 사수

S
→ 사수의 사수

관계:

사원 E
 ↓ MGR_ID
사수 M
 ↓ MGR_ID
상위 사수 S

실행 결과 예:

전우성 → 한선기 → NULL
엄정하 → 전우성 → 한선기
심하균 → NULL   → NULL
박하일 → NULL   → NULL

Self Join은 같은 테이블을 여러 번 사용하는 것이 아니라 같은 테이블에 서로 다른 역할을 부여하여 관계를 추적하는 것이라고 이해하면 쉬웠다.

오늘의 문제 해결 과정

오늘 수업에서는 단순히 정답 SQL만 작성한 것이 아니라, 잘못된 결과나 오류를 확인하고 왜 그런 결과가 발생했는지를 다시 분석하는 과정이 많았다.

1. WHERE에서 SUM()을 사용했더니 오류 발생

증상

WHERE SUM(SALARY) >= 9000000

을 실행하자:

SQL 오류 (1111)
Invalid use of group function

오류가 발생했다.

원인

SQL의 논리적인 처리 흐름을 보면:

FROM
 ↓
WHERE
 ↓
GROUP BY
 ↓
HAVING
 ↓
SELECT
 ↓
ORDER BY

WHERE 시점에서는 아직 GROUP BY와 SUM()이 수행되지 않았다.

즉 존재하지 않는 집계 결과를 WHERE에서 사용하려고 한 것이 원인이었다.

해결

HAVING SUM(SALARY) >= 9000000

으로 이동했다.

검증

SELECT DEPT_ID,
       SUM(SALARY)
FROM employee
GROUP BY DEPT_ID
HAVING SUM(SALARY) >= 9000000;

정상적으로 조건을 만족하는 부서만 조회됐다.

배운 점

WHERE
→ 원본 Row 조건

HAVING
→ 그룹 함수 결과 조건

으로 구분하면 된다.

2. JOIN했는데 결과가 154개나 나온 문제

증상

SELECT E.EMP_NAME,
       D.DEPT_NAME
FROM employee E,
     department D;

를 실행했더니 예상보다 훨씬 많은 154행이 조회됐다.

원인

JOIN 조건이 없었다.

employee 22행
department 7행

22 × 7
= 154

즉 모든 가능한 조합이 생성되는 Cartesian Product가 발생했다.

해결

두 테이블의 관계를 확인한 뒤:

WHERE E.DEPT_ID = D.DEPT_ID

조건을 추가했다.

검증

154행
↓
20행

으로 줄어들었고 실제 부서가 매칭되는 사원만 조회됐다.

배운 점

JOIN 문제를 풀 때는 SQL을 먼저 작성하기보다:

1. 어떤 테이블을 연결하는가?
2. 두 테이블은 어떤 컬럼으로 관계가 있는가?
3. PK / FK가 무엇인가?

를 먼저 확인해야 한다.

3. 휴학생이 0명인 학과가 사라지는 문제

학과별 휴학생 수를 구하는 Q13에서는 단순히 휴학생만 WHERE로 필터링하면 문제가 생길 수 있었다.

요구사항

학과별 휴학생 수 출력
+
휴학생이 0명인 학과도 출력

문제점

학생 테이블에서 휴학생만 필터링하면:

휴학생이 있는 학과
→ 존재

휴학생이 없는 학과
→ 행 자체가 없음

이 되어 0명이라는 결과를 표현할 수 없다.

해결

모든 학과가 존재하는 tb_department를 기준 테이블로 선택했다.

FROM tb_department b
LEFT JOIN tb_student a
       ON b.DEPARTMENT_NO = a.DEPARTMENT_NO
      AND a.ABSENCE_YN = 'Y'

그리고:

COUNT(a.STUDENT_NO)

로 실제 매칭된 휴학생만 계산했다.

검증

처럼 휴학생이 없는 학과도 0으로 표시됐다.

배운 점

"없는 데이터도 보여야 하는가?"

를 먼저 확인하면 INNER JOIN과 LEFT JOIN 중 무엇이 필요한지 판단하기 쉬워진다.

4. 년도별 평점을 구하려는데 TERM_NO가 학기까지 포함된 문제

문제

TERM_NO는 다음처럼 저장되어 있었다.

년도별 평균이 필요한데 TERM_NO 전체를 그룹화하면 학기별 그룹이 만들어진다.

해결

SUBSTRING(TERM_NO, 1, 4)

또는:

LEFT(TERM_NO, 4)

를 이용해 년도만 추출했다.

200101
 ↓
2001

그 후:

GROUP BY 년도

를 수행했다.

배운 점

DB에 저장된 원본 값이 문제에서 요구하는 단위와 다르다면 문자열 함수 등을 이용해 새로운 그룹 기준을 만들어야 한다.

5. GROUP BY만으로 년도별 소계와 전체 평균을 동시에 구하기 어려웠던 문제

Q15에서는:

학기별 평점
년도별 평점
전체 평점

이 모두 필요했다.

단순:

GROUP BY 년도, 학기

로는 학기별 평균만 구할 수 있다.

해결

WITH ROLLUP

을 추가했다.

년도 + 학기
→ 학기별 평균

년도 + NULL
→ 년도별 평균

NULL + NULL
→ 전체 평균

배운 점

ROLLUP은 단순 합계뿐 아니라 계층적으로 그룹을 묶은 결과의 소계와 전체 집계를 함께 표현할 때 유용하다.

6. 다중 JOIN이 복잡하게 느껴졌던 문제

테이블이:

JOB
EMPLOYEE
DEPARTMENT
LOCATION
COUNTRY
SAL_GRADE

까지 늘어나자 처음에는 하나의 SQL 안에서 모든 관계를 동시에 생각해야 하는 것처럼 느껴졌다.

하지만 관계를 하나씩 보면:

JOB
 ↓ JOB_ID
EMPLOYEE
 ↓ DEPT_ID
DEPARTMENT
 ↓ LOC_ID
LOCATION
 ↓ COUNTRY_ID
COUNTRY

이고,

급여등급만:

EMPLOYEE.SALARY
 ↓
SAL_GRADE.LOWEST ~ HIGHEST

로 별도로 연결된다.

배운 점

다중 JOIN은:

"테이블 6개를 한 번에 JOIN"

이라고 생각하기보다:

앞의 결과
+
다음 테이블 1개
+
다음 테이블 1개

처럼 관계를 한 단계씩 따라가는 것이 훨씬 이해하기 쉽다.

7. 같은 employee 테이블을 다시 JOIN해야 했던 문제

Self Join 문제에서는:

사원
사수
사수의 사수

가 모두 employee 테이블에 존재했다.

처음에는 같은 테이블을 여러 번 JOIN하는 것이 어색했지만 alias를 역할로 생각하니 쉬워졌다.

E = Employee
M = Manager
S = Superior

E.MGR_ID = M.EMP_ID
M.MGR_ID = S.EMP_ID

배운 점

Self Join은:

같은 테이블을 복사한다

가 아니라:

동일한 테이블의 데이터를
서로 다른 역할로 해석한다

라고 생각해야 한다.

✨ 오늘 배운 점

오늘 수업은 GROUP BY, HAVING, Window Function, 정규화, JOIN까지 범위가 상당히 넓었다.

처음에는 서로 다른 주제처럼 보였지만 하루가 끝나고 다시 연결해보니 모두 관계형 데이터베이스에서 데이터를 어떻게 저장하고, 묶고, 분석하고, 다시 연결할 것인가라는 하나의 흐름 안에 있었다.

오전에는:

GROUP BY
HAVING
ROLLUP
Window Function

을 통해 데이터를 묶고 분석하는 방법을 배웠다.

특히:

WHERE
→ Row를 필터링

HAVING
→ Group을 필터링

이라는 차이를 실제 오류까지 경험하면서 확실하게 이해할 수 있었다.

또:

GROUP BY
→ 행을 줄이며 집계

Window Function
→ 행을 유지하며 분석

이라는 차이도 중요했다.

오후에는:

정규화
→ Mapping Rule
→ PK / FK
→ JOIN

으로 연결됐다.

정규화를 통해 데이터를 작은 단위로 분리하는 이유와, 그렇게 분리한 데이터를 관계를 이용해 다시 JOIN하는 이유를 함께 배우니 관계형 데이터베이스의 구조가 훨씬 명확해졌다.

오늘의 회고

오늘 가장 크게 느낀 점은 SQL 문제는 문법을 많이 외운다고 바로 풀리는 것이 아니라 데이터의 구조와 문제의 요구사항을 먼저 분석해야 한다는 것이었다.

예를 들어:

"부서별"
→ GROUP BY 필요

"총액이 900만원 이상인 부서"
→ HAVING 필요

"휴학생이 0명인 학과도 출력"
→ LEFT JOIN 필요

"년도별 + 전체 평균"
→ ROLLUP 고려

"부서별 순위"
→ PARTITION BY 필요

"사원과 사수"
→ Self Join 필요

처럼 문제 문장 안에 어떤 SQL 문법이 필요한지 판단할 수 있는 단서가 있었다.

특히 오늘은 잘못 작성한 SQL의 결과를 확인하고 다시 수정하는 과정이 많았다.

WHERE에서 SUM 사용
→ 오류 발생
→ HAVING으로 수정

JOIN 조건 누락
→ 154개 행 생성
→ 관계 조건 추가

휴학생만 먼저 필터링
→ 0명 학과 표현 불가
→ LEFT JOIN으로 기준 변경

이런 과정이 단순히 정답 SQL을 보는 것보다 더 기억에 남았다.

그리고 정규화와 JOIN이 연결되는 과정도 인상적이었다.

정규화
→ 데이터 중복을 줄이기 위해 테이블 분리

Mapping Rule
→ ERD를 실제 PK/FK 구조로 변환

JOIN
→ 분리된 데이터를 관계를 따라 다시 결합

관계형 데이터베이스를 설계하고 사용하는 과정이 하나의 흐름으로 연결되기 시작한 느낌이었다.

다음 학습 방향

오늘 수업 마지막에는 강사님이:

[Additional SELECT - Option]
Q1 ~ Q14

를 직접 구현해보라고 하고 수업을 마무리했다.

오늘은 해당 문제들의 강사님 해설까지 진행하지 않았기 때문에, 다음 수업에서는 직접 작성한 쿼리를 확인하거나 다른 수강생들의 코드와 비교하면서 풀이를 진행할 가능성이 있다.

따라서 다음 수업 전에는 문제를 풀 때 다음 순서로 접근해봐야겠다.

1. 문제에서 최종적으로 필요한 컬럼 찾기
        ↓
2. 해당 컬럼이 어느 테이블에 있는지 확인
        ↓
3. 여러 테이블이 필요하다면 PK / FK 관계 확인
        ↓
4. INNER JOIN / LEFT JOIN 판단
        ↓
5. 일반 행 조건은 WHERE
        ↓
6. 그룹 기준이 있다면 GROUP BY
        ↓
7. 집계 결과 조건은 HAVING
        ↓
8. 정렬 조건은 ORDER BY

특히 다음 내용을 집중적으로 복습할 예정이다.

WHERE vs HAVING

GROUP BY vs Window Function

INNER JOIN vs LEFT JOIN

ON vs USING

Equi Join vs Non-Equi Join

JOIN vs EXISTS

Self Join

WITH ROLLUP

다음 수업에서 강사님 또는 다른 수강생의 풀이와 내가 작성한 SQL을 비교하면서 결과만 같은 SQL이 아니라 왜 그 방법을 선택했는지 설명할 수 있는 수준까지 이해해보고 싶다.

[LG CNS 6기] 20일차 TIL : SQL 함수(Function)와 그룹 함수, Additional SELECT 실습

bbbicsan — Tue, 25 Aug 2026 18:00:22 +0900

[LG CNS 6기] 20일차 TIL : SQL 함수(Function)와 그룹 함수, Additional SELECT 실습

한 줄 요약
MariaDB에서 문자·숫자·날짜·조건 함수를 실습하고, 단일행 함수와 복수행 함수를 구분한 뒤 여러 함수를 중첩하여 실제 데이터를 가공하는 SQL 문제를 풀었다.

오늘 학습한 커리큘럼

SQL Function
        ↓
단일행 함수
        ↓
문자 함수
LENGTH / CHAR_LENGTH
UPPER / LOWER
LPAD / RPAD
SUBSTRING / LEFT / RIGHT
INSTR / REPEAT / REPLACE
        ↓
함수 중첩
INSTR + LEFT
SUBSTRING + CAST
        ↓
숫자 함수
ABS / CEILING / FLOOR / ROUND
        ↓
날짜 함수
NOW / SYSDATE
CURDATE / CURTIME
ADDDATE / DATEDIFF
        ↓
조건 함수
IF / IFNULL / CASE
        ↓
복수행(그룹) 함수
COUNT / MIN / MAX / AVG / SUM
        ↓
Additional SELECT - 함수
Q1 ~ Q11 실습

오늘의 학습 키워드

SQL Function
단일행 함수
복수행 함수
LENGTH()
CHAR_LENGTH()
UPPER()LOWER()
LPAD()RPAD()
SUBSTRING()
LEFT()RIGHT()
INSTR()
SUBSTRING_INDEX()
REPEAT()
REPLACE()
CAST()
CONCAT()
ABS()
CEILING()FLOOR()
ROUND()
NOW()
SYSDATE()
CURDATE()CURTIME()
ADDDATE()DATEDIFF()
IF()IFNULL()
CASE
COUNT()MIN()MAX()AVG()SUM()
함수 중첩
ORDER BY

1. SQL 함수(Function)

함수는 반복적으로 사용하는 기능을 하나의 작은 기능 단위로 만들어두고 필요할 때 호출하여 결과를 반환하는 구조이다.

SQL 함수도 크게 두 종류로 나눌 수 있다.

SQL Function
│
├─ 단일행 함수
│   └─ 한 행마다 함수 실행
│
└─ 복수행 함수
    └─ 여러 행을 하나의 그룹으로 계산

단일행 함수

각 Row마다 함수가 실행되고 각 Row마다 결과가 반환된다.

ROW 1 → 함수 → 결과 1
ROW 2 → 함수 → 결과 2
ROW 3 → 함수 → 결과 3

문자, 숫자, 날짜, 변환 함수 등이 여기에 해당한다.

복수행 함수

여러 Row를 입력받아 하나의 집계 결과를 계산한다.

ROW 1
ROW 2 ──→ AVG() ──→ 평균 1개
ROW 3

대표적으로:

COUNT
MIN
MAX
AVG
SUM

이 있다.

2. 문자 함수 - LENGTH()와 CHAR_LENGTH()

첫 번째 실습에서는 사원의 이름 길이를 확인했다.

SELECT EMP_NAME,
       LENGTH(EMP_NAME)
FROM employee;

실행 결과 한글 이름이 3글자인데 결과가 9로 나왔다.

한선기 → 9
강중훈 → 9
최만식 → 9

처음에는 이름이 3글자인데 왜 9가 나오는지 의문이 생겼다.

MariaDB에서 LENGTH()는 문자 개수가 아니라 문자열의 바이트 길이를 반환한다.

UTF-8 계열에서 한글 한 글자는 일반적으로 3Byte이므로:

임정섭

3글자 × 3Byte
= 9Byte

가 된다.

실제로 비교해보았다.

SELECT LENGTH('임정섭'),
       LENGTH('JSLIM'),
       CHAR_LENGTH('임정섭'),
       UPPER('lgcns'),
       LOWER('LGCNS');

실행 결과:

LENGTH('임정섭')      → 9
LENGTH('JSLIM')       → 5
CHAR_LENGTH('임정섭') → 3
UPPER('lgcns')        → LGCNS
LOWER('LGCNS')        → lgcns

정리하면:

함수	역할
`LENGTH()`	문자열의 Byte 길이
`CHAR_LENGTH()`	실제 문자 개수
`UPPER()`	대문자로 변환
`LOWER()`	소문자로 변환

3. LPAD(), RPAD() - 문자열 채우기

문자열의 부족한 길이를 특정 문자로 채우는 함수이다.

SELECT LPAD('5', 3, 'A');

결과:

AA5

문법:

LPAD(문자열, 최종길이, 채울문자)
RPAD(문자열, 최종길이, 채울문자)

예를 들어:

SELECT LPAD('5', 3, 'A'),
       RPAD('5', 3, 'A');

LPAD → AA5
RPAD → 5AA

4. SUBSTRING(), LEFT(), RIGHT() - 부분 문자열 추출

문자열에서 원하는 부분만 잘라내는 함수이다.

SELECT SUBSTRING('ABCDEF', 1, 2),
       LEFT('ABCDEF', 2),
       RIGHT('ABCDEF', 2);

실행 결과:

SUBSTRING('ABCDEF', 1, 2) → AB
LEFT('ABCDEF', 2)         → AB
RIGHT('ABCDEF', 2)        → EF

차이는 다음과 같다.

SUBSTRING()
→ 시작 위치와 길이를 직접 지정

LEFT()
→ 왼쪽부터 자름

RIGHT()
→ 오른쪽부터 자름

5. INSTR() - 문자열 위치 찾기

INSTR()는 문자열에서 특정 문자열이 시작되는 위치를 반환한다.

SELECT INSTR('LGCNS CAMP', 'CAMP');

실행 결과:

문자열 위치는 1부터 시작한다.

L G C N S   C A M P
1 2 3 4 5 6 7 8 9 10
            ↑
          CAMP

6. 함수 중첩 - 이메일 ID 추출

이번 실습에서는 단순히 하나의 함수만 사용하는 것이 아니라 함수의 반환값을 다른 함수의 인자로 전달했다.

SELECT EMAIL,
       INSTR(EMAIL, 'c.'),
       LEFT(EMAIL, INSTR(EMAIL, '@') - 1)
FROM employee;

핵심은:

LEFT(EMAIL, INSTR(EMAIL, '@') - 1)

이다.

동작 순서:

sg_ahn@vcc.com
      ↓
INSTR(EMAIL, '@')
      ↓
@ 위치 검색
      ↓
@ 위치 - 1
      ↓
LEFT()
      ↓
sg_ahn

실제 결과:

sg_ahn@vcc.com  → sg_ahn
jh_park@vcc.com → jh_park
ms_choi@vcc.com → ms_choi

오늘 실습을 통해 함수는 단독으로 사용하는 것보다 여러 함수를 조합했을 때 훨씬 다양한 데이터 가공이 가능하다는 것을 확인했다.

7. REPEAT(), REPLACE()

REPEAT()

문자열을 원하는 횟수만큼 반복한다.

SELECT REPEAT('LGCNS', 3);

결과:

LGCNSLGCNSLGCNS

REPLACE()

문자열의 특정 부분을 다른 문자열로 변경한다.

SELECT REPLACE(
    '오늘은 즐거운 함수 수업',
    '함수',
    '메서드'
);

결과:

오늘은 즐거운 메서드 수업

8. SUBSTRING()으로 입사년도 추출

강사님 Q)

입사년도만 추출한다면?

같은 문제를 두 가지 SUBSTRING() 문법으로 작성했다.

SELECT SUBSTRING(E.HIRE_DATE FROM 1 FOR 4) AS '입사년도',
       SUBSTRING(E.HIRE_DATE, 1, 4) AS '입사년도'
FROM employee E;

결과:

MariaDB에서는 다음 두 문법을 모두 사용할 수 있다.

SUBSTRING(str FROM pos FOR len)

SUBSTRING(str, pos, len)

9. CAST() - 데이터 타입 변환

새로운 실습 데이터베이스 sqlDB도 생성했다.

sqlDB
│
├─ userTbl
│   └─ 회원 정보
│
└─ buyTbl
    └─ 구매 정보

관계는:

userTbl.userID (PK)
        ↓
buyTbl.userID (FK)

이며 buyTbl.num에는 AUTO_INCREMENT가 적용되어 있었다.

강사님 Q)

구매번호,
총 금액(PRICE * AMOUNT =),
구매액을 출력한다면?

조건: CAST() 활용

실제 풀이:

SELECT NUM AS '구매번호',
       CONCAT(
           CAST(PRICE AS VARCHAR(10)),
           ' * ',
           CAST(AMOUNT AS VARCHAR(10)),
           ' = '
       ) AS '총 금액',
       PRICE * AMOUNT AS '구매액'
FROM buyTbl;

예시 결과:

구매번호 | 총 금액      | 구매액
1       | 30 * 2 =     | 60
2       | 1000 * 1 =   | 1000
3       | 200 * 1 =    | 200
4       | 200 * 5 =    | 1000

동작 흐름:

PRICE / AMOUNT
      ↓
CAST()
      ↓
문자열 변환
      ↓
CONCAT()
      ↓
"30 * 2 =" 생성

PRICE * AMOUNT
      ↓
실제 구매액 계산

10. 숫자 함수

숫자를 처리하는 여러 함수를 실습했다.

SELECT ABS(-100),
       CEILING(4.7),
       CEILING(4.1),
       FLOOR(4.7),
       FLOOR(4.1),
       ROUND(4153.415354, 2),
       ROUND(4153.415354, -2);

실행 결과:

ABS(-100)             → 100
CEILING(4.7)          → 5
CEILING(4.1)          → 5
FLOOR(4.7)            → 4
FLOOR(4.1)            → 4
ROUND(4153.415354, 2) → 4153.42
ROUND(4153.415354,-2) → 4200

함수	역할
`ABS()`	절댓값
`CEILING()`	올림
`FLOOR()`	내림
`ROUND()`	반올림

특히 ROUND()의 두 번째 인자에 음수가 들어갈 수도 있다.

ROUND(4153.415354, 2)
→ 소수점 둘째 자리

ROUND(4153.415354, -2)
→ 백의 자리 단위 반올림

11. 날짜 함수

현재 날짜와 시간을 확인하는 함수를 실습했다.

SELECT NOW(),
       SYSDATE();

실행 당시:

2026-08-25 11:09:09

이 출력되었다.

함수	역할
`NOW()`	현재 날짜 + 시간
`SYSDATE()`	현재 날짜 + 시간
`CURDATE()`	현재 날짜
`CURTIME()`	현재 시간
`ADDDATE()`	날짜에 기간 추가
`DATEDIFF()`	두 날짜의 차이를 일 단위로 계산

12. DATEDIFF() - 근속년수 계산

강사님 Q)

오늘 날짜를 기준으로
근속년수가 30년 이상인 사원의
이름, 입사일, 근속년수를 검색한다면?

풀이:

SELECT EMP_NAME,
       HIRE_DATE,
       ROUND(DATEDIFF(CURDATE(), HIRE_DATE) / 365) AS '근속년수'
FROM employee
WHERE DATEDIFF(CURDATE(), HIRE_DATE) / 365 >= 30;

동작 흐름:

CURDATE()
        ↓
오늘 날짜

DATEDIFF(CURDATE(), HIRE_DATE)
        ↓
근무한 총 일수

/ 365
        ↓
연 단위로 변환

ROUND()
        ↓
근속년수 출력

WHERE >= 30
        ↓
30년 이상만 필터링

실행 결과:

한선기 | 1990-04-01 | 36
최만식 | 1995-12-30 | 31

이번 실습에서는:

날짜 함수 DATEDIFF()
+
숫자 함수 ROUND()
+
WHERE 조건

을 함께 사용했다.

13. IF() - 주민번호로 성별 판별

강사님 Q)

부서번호가 50번인 사원의
이름, 주민번호, 성별을 검색한다면?

풀이:

SELECT EMP_NAME,
       EMP_NO,
       IF(
           SUBSTRING(EMP_NO, 8, 1) IN ('1', '3'),
           '남자',
           '여자'
       ) AS 'GENDER'
FROM employee
WHERE DEPT_ID = '50';

흐름:

SUBSTRING(EMP_NO, 8, 1)
        ↓
주민번호 뒷자리 첫 숫자

1 또는 3
→ 남자

그 외
→ 여자

즉:

SUBSTRING()
+
IN
+
IF()

를 중첩하여 새로운 파생 컬럼을 만들었다.

14. WHERE 조건으로 특정 성별만 조회

같은 성별 정보라도 조건 함수를 사용하지 않고 WHERE에서 직접 필터링할 수도 있었다.

SELECT EMP_NAME,
       EMP_NO,
       '남자' AS GENDER
FROM employee
WHERE SUBSTRING(EMP_NO, 8, 1) = '1';

이 경우:

WHERE
→ 남자 데이터만 조회

'남자' AS GENDER
→ 조회 결과에 고정 문자열 출력

이다.

앞의 IF() 방식과 차이는:

IF()
→ 전체 행을 남/여로 분기

WHERE
→ 특정 조건의 행 자체만 조회

이다.

15. IF()와 IFNULL() - 빈 문자열과 NULL의 차이

강사님 Q)

JOB_ID가 J4인 사원의
이름, 사번, 사수번호를 조회

사수번호가 없는 경우
'관리자' 출력

실제 풀이:

SELECT EMP_NAME,
       EMP_ID,
       IF(MGR_ID = '', '관리자', MGR_ID) AS '사수번호'
FROM employee
WHERE JOB_ID = 'J4';

처음 생각할 수 있는 방법은:

IFNULL(MGR_ID, '관리자')

이지만 현재 데이터에서는 일부 사수번호가 NULL이 아니라 빈 문자열 '' 로 저장되어 있었다.

NULL
≠
''

따라서:

IFNULL()
→ NULL만 처리

IF(MGR_ID = '', ...)
→ 빈 문자열 조건 처리

라는 차이가 있었다.

16. CASE - 여러 조건 분기

강사님 Q)

급여등급을 구분한다면?

300 이하 → 초급
400 이하 → 중급
그 이상 → 고급

여러 조건을 분기해야 할 때는 CASE 표현식을 활용할 수 있다.

구조는 다음과 같다.

CASE
    WHEN 조건1 THEN 결과1
    WHEN 조건2 THEN 결과2
    ELSE 결과3
END

CASE는 위의 조건부터 순서대로 검사한다는 점이 중요하다.

17. 복수행 함수(Group Function)

이후 여러 행을 대상으로 계산하는 그룹 함수로 넘어갔다.

SELECT COUNT(*),
       COUNT(BONUS_PCT),
       COUNT(IFNULL(BONUS_PCT, 0)),
       MIN(SALARY),
       MAX(SALARY),
       AVG(SALARY),
       SUM(SALARY)
FROM employee;

COUNT()

COUNT(*)
→ 전체 행 개수

COUNT(BONUS_PCT)
→ BONUS_PCT가 NULL이 아닌 행 개수

COUNT(IFNULL(BONUS_PCT, 0))
→ NULL을 0으로 변환
→ 모든 행이 COUNT 대상

특히 그룹 함수에서는 NULL 처리 여부가 결과에 영향을 줄 수 있다는 점이 중요했다.

MIN / MAX / AVG / SUM

MIN(SALARY)
→ 최소 급여

MAX(SALARY)
→ 최대 급여

AVG(SALARY)
→ 평균 급여

SUM(SALARY)
→ 급여 총합

18. 일반 컬럼과 그룹 함수

그룹 함수를 배우면서 이후 GROUP BY와 연결되는 중요한 특징도 확인했다.

SELECT EMP_NAME,
       COUNT(*)
FROM employee;

처럼 일반 컬럼과 집계 함수를 아무 기준 없이 함께 조회하면 문제가 생길 수 있다.

EMP_NAME
→ 개별 Row 정보

COUNT(*)
→ 여러 Row의 집계 결과

서로 데이터의 기준이 다르기 때문이다.

따라서 이후:

일반 컬럼 + 그룹 함수
        ↓
GROUP BY

개념으로 연결될 예정이다.

Additional SELECT - 함수 실습

오늘은 Workbook의 Additional SELECT 함수 문제도 직접 풀어보았다.

스킵 문항:

7, 10, 12, 13, 14, 15

오늘 풀이 대상:

1, 2, 3, 4, 5, 6, 8, 9

19. Q1 - 영어영문학과 학생 조회

문제:

영어영문학과(002) 학생의
학번, 이름, 입학년도를
입학년도가 빠른 순으로 출력

강사님 풀이 1:

SELECT a.STUDENT_NO   학번,
       a.STUDENT_NAME 이름,
       a.ENTRANCE_DATE 입학년도
FROM tb_student a
WHERE 1 = 1
  AND a.DEPARTMENT_NO = '002'
ORDER BY 3 ASC;

다른 표현:

SELECT STUDENT_NO   AS '학번',
       STUDENT_NAME AS '이름',
       ENTRANCE_DATE AS '입학년도'
FROM tb_student
WHERE DEPARTMENT_NO = '002'
ORDER BY ENTRANCE_DATE ASC;

두 SQL은 같은 결과를 만든다.

ORDER BY 3
=
SELECT의 세 번째 컬럼
=
ENTRANCE_DATE

또한 AS는 컬럼 별칭에서 생략할 수도 있다는 것을 확인했다.

20. Q2 - 이름이 세 글자가 아닌 교수 찾기

첫 번째 풀이:

SELECT PROFESSOR_NAME,
       PROFESSOR_SSN
FROM tb_professor
WHERE CHAR_LENGTH(PROFESSOR_NAME) <> 3;

두 번째 풀이:

SELECT a.PROFESSOR_NAME,
       a.PROFESSOR_SSN
FROM tb_professor a
WHERE 1 = 1
  AND a.PROFESSOR_NAME NOT LIKE '___';

LIKE에서 _는 정확히 한 글자를 의미한다.

_   → 1글자
__  → 2글자
___ → 3글자

따라서:

NOT LIKE '___'
→ 정확히 3글자가 아닌 문자열

실행 결과:

강혁
박강아름

동일한 문제를:

CHAR_LENGTH()
→ 문자 개수를 계산하는 방식

NOT LIKE
→ 패턴으로 비교하는 방식

두 가지 방법으로 해결했다.

21. Q3 - 남자 교수의 이름과 나이

강사님 풀이:

SELECT PROFESSOR_NAME AS '교수이름',
       126 - CAST(
           SUBSTRING(PROFESSOR_SSN, 1, 2)
           AS INT
       ) AS '나이'
FROM tb_professor
WHERE LEFT(
          SUBSTRING_INDEX(PROFESSOR_SSN, '-', -1),
          1
      ) = '1'
ORDER BY '나이';

주민번호 앞 두 자리를 추출한다.

601004-1100528
 ↓
60

그 값을 CAST()로 숫자로 변환하고 2026년을 기준으로 나이를 계산했다.

남자 여부는:

601004-1100528
       ↓
SUBSTRING_INDEX(..., '-', -1)
       ↓
1100528
       ↓
LEFT(..., 1)
       ↓
1

을 이용해 판별했다.

이번 문제는:

SUBSTRING
+
CAST
+
SUBSTRING_INDEX
+
LEFT

까지 여러 문자·변환 함수를 중첩한 실습이었다.

수업에서는 126 - 출생년도 두 자리 방식으로 계산했다. 정확한 만 나이를 구하려면 실제 생일이 지났는지까지 고려해야 한다.

22. Q4 - 교수 이름에서 성 제거

강사님 풀이:

SELECT RIGHT(
           PROFESSOR_NAME,
           CHAR_LENGTH(PROFESSOR_NAME) - 1
       ) AS '이름'
FROM tb_professor;

흐름:

김진영
 ↓
CHAR_LENGTH() = 3
 ↓
3 - 1 = 2
 ↓
RIGHT(..., 2)
 ↓
진영

예:

김진영   → 진영
강혁     → 혁
박강아름 → 강아름

문제 조건에서 성이 두 글자인 교수는 없다고 가정했기 때문에 가능한 방식이었다.

23. Q5 - 재수생 입학자 찾기

문제에서는 19살에 입학하면 재수를 하지 않은 것으로 간주했다.

강사님 풀이:

SELECT a.STUDENT_NO,
       a.STUDENT_NAME
FROM tb_student a
WHERE LEFT(a.ENTRANCE_DATE, 4)
      - CONCAT('19', LEFT(a.STUDENT_SSN, 2)) > 19;

동작 흐름:

LEFT(ENTRANCE_DATE, 4)
→ 입학년도

LEFT(STUDENT_SSN, 2)
→ 출생년도 두 자리

CONCAT('19', ...)
→ 4자리 출생년도

입학년도 - 출생년도
→ 입학 당시 나이 계산

> 19
→ 재수 이상

이 문제에서는 문자열 함수로 데이터를 추출한 후 산술 연산에 연결했다.

24. Q6 - 2020년 크리스마스 요일

강사님 풀이:

SELECT DAYNAME('2020-12-25');

실행 결과:

Friday

즉 2020년 크리스마스는 금요일이었다.

관련 날짜 함수도 함께 확인했다.

WEEKDAY()
→ 월요일을 0으로 시작

DAYOFWEEK()
→ 일요일을 1로 시작

DAYNAME()
→ 요일 이름 반환

25. Q8 - 2000년도 이전 학번 학생 찾기

첫 번째 방법:

SELECT STUDENT_NO AS '학번',
       STUDENT_NAME AS '이름'
FROM tb_student
WHERE STUDENT_NO NOT LIKE 'A%';

두 번째 방법:

SELECT STUDENT_NO,
       STUDENT_NAME
FROM tb_student
WHERE SUBSTRING(STUDENT_NO, 1, 1) != 'A';

문제에서 2000년도 이후 학번은 A로 시작한다고 주어졌기 때문에:

A로 시작
→ 2000년도 이후

A로 시작하지 않음
→ 2000년도 이전

으로 판단했다.

동일한 조건을:

NOT LIKE
vs
SUBSTRING

두 방법으로 구현할 수 있었다.

26. Q9 - 학생의 총 평점 계산

문제:

학번 A517178 학생의
학점 총 평점을 계산

소수점 첫째 자리까지 반올림

강사님 풀이:

SELECT ROUND(AVG(POINT), 1) AS '평점'
FROM tb_grade
WHERE STUDENT_NO = 'A517178';

실행 결과:

3.6

이 문제에서는:

AVG()
→ 여러 학점의 평균

ROUND(..., 1)
→ 소수점 첫째 자리까지 반올림

으로 복수행 함수와 단일행 숫자 함수를 중첩했다.

성적 여러 건
    ↓
AVG()
    ↓
평균값
    ↓
ROUND()
    ↓
3.6

문제 해결 과정

1. 한글 이름이 3글자인데 LENGTH() 결과가 9가 나온 문제

증상

SELECT EMP_NAME,
       LENGTH(EMP_NAME)
FROM employee;

결과:

한선기 → 9

이름은 세 글자인데 예상했던 3이 아니라 9가 나왔다.

원인

MariaDB의 LENGTH()는 문자의 개수가 아니라 Byte 길이를 반환했다.

한글 3글자
×
UTF-8 기준 일반적으로 3Byte
=
9Byte

해결

문자 개수를 알고 싶은 경우 CHAR_LENGTH()를 사용했다.

SELECT CHAR_LENGTH('임정섭');

결과:

배운 점

함수 이름만 보고 동작을 추측하면 안 되고, 함수가 문자 개수를 반환하는지 Byte 수를 반환하는지 정확한 반환 기준을 확인해야 한다.

2. IFNULL()을 사용했는데 '관리자'가 출력되지 않는 경우

사수번호가 없는 사원에게 '관리자'를 출력하려고 했다.

처음 생각할 수 있는 방법은:

IFNULL(MGR_ID, '관리자')

였다.

하지만 데이터에서 사수번호가 없는 일부 행은:

NULL

이 아니라:

''

빈 문자열이었다.

따라서 IFNULL()만으로는 해결되지 않는다.

실제 수업에서는:

IF(MGR_ID = '', '관리자', MGR_ID)

로 처리했다.

핵심

NULL
→ 값 자체가 없음

''
→ 길이가 0인 문자열

두 값은 다르다.

이 실습을 통해 SQL에서 데이터의 실제 저장 상태를 먼저 확인하는 것이 중요하다는 것을 알게 되었다.

3. 같은 문제를 여러 방법으로 해결하기

Workbook 문제를 풀면서 하나의 요구사항을 여러 SQL로 표현할 수 있다는 점도 반복해서 확인했다.

이름이 세 글자가 아닌 교수

CHAR_LENGTH(PROFESSOR_NAME) <> 3

또는:

PROFESSOR_NAME NOT LIKE '___'

2000년도 이전 학번

STUDENT_NO NOT LIKE 'A%'

또는:

SUBSTRING(STUDENT_NO, 1, 1) != 'A'

Q1 정렬

ORDER BY 3 ASC

또는:

ORDER BY ENTRANCE_DATE ASC

결국 중요한 것은 특정 문법을 하나 외우는 것이 아니라:

요구사항 분석
        ↓
필요한 데이터 확인
        ↓
사용 가능한 함수 선택
        ↓
함수 조합
        ↓
SQL 실행
        ↓
결과 확인

의 과정을 스스로 만들 수 있는 능력이라는 것을 느꼈다.

✨ 오늘 배운 점

어제까지는 SELECT, WHERE, LIKE, IN, BETWEEN 등을 이용해 어떤 행을 조회할 것인지에 집중했다면, 오늘은 조회한 값을 어떻게 가공할 것인지를 집중적으로 배웠다.

특히:

문자열에서 위치 찾기
→ INSTR()

위치 기준으로 문자열 자르기
→ LEFT() / SUBSTRING()

문자열을 숫자로 변환
→ CAST()

평균 계산
→ AVG()

계산 결과 반올림
→ ROUND()

처럼 하나의 함수만 사용하는 것이 아니라 함수의 결과를 다른 함수의 입력으로 다시 사용하는 방식이 많이 등장했다.

이전에는:

SELECT *
FROM employee;

처럼 저장된 데이터를 그대로 가져왔다면 오늘은:

LEFT(EMAIL, INSTR(EMAIL, '@') - 1)

처럼 실제 테이블에는 존재하지 않는 정보를 SQL에서 만들어낼 수 있었다.

또 AVG()나 COUNT()를 배우면서 SQL이 단순 조회 언어가 아니라 여러 Row의 데이터를 집계하고 분석하는 도구라는 것도 체감할 수 있었다.

오늘의 회고

오늘은 SQL 함수의 종류가 많아서 처음에는 각각의 함수를 모두 따로 외워야 하나 싶었다.

하지만 실습을 진행하면서 함수 자체를 암기하는 것보다:

문자열 길이가 필요한가?
→ LENGTH / CHAR_LENGTH

문자 일부가 필요한가?
→ SUBSTRING / LEFT / RIGHT

문자의 위치가 필요한가?
→ INSTR

자료형을 바꿔야 하는가?
→ CAST

조건에 따라 출력해야 하는가?
→ IF / CASE

여러 행을 계산해야 하는가?
→ COUNT / AVG / SUM

처럼 문제를 먼저 보고 필요한 기능을 선택하는 것이 더 중요하다는 것을 느꼈다.

특히 Workbook 문제를 풀 때는 하나의 함수만 알고 있어서는 해결하기 어려운 문제가 많았다.

Q3에서는:

SUBSTRING
→ CAST
→ SUBSTRING_INDEX
→ LEFT

를 함께 사용했고,

Q9에서는:

AVG
→ ROUND

를 중첩해서 사용했다.

결국 SQL에서도 Java에서 메서드를 조합했던 것처럼 작은 기능들을 조합해서 하나의 요구사항을 해결한다는 점은 동일했다.

그리고 LENGTH()가 한글 이름에서 9를 반환한 문제나 IFNULL()이 빈 문자열을 처리하지 못했던 사례처럼, SQL 문법이 맞는 것만으로는 충분하지 않고 데이터 타입과 실제 저장된 값까지 확인해야 정확한 결과를 얻을 수 있다는 점도 기억에 남았다.

오늘은 많은 함수를 새로 배웠지만, 실제 Workbook 문제를 직접 풀면서 바로 사용해본 덕분에 각 함수가 어떤 상황에서 필요한지 연결해서 이해할 수 있었다.

다음 학습 방향

오늘 마지막에 복수행 함수까지 학습했기 때문에 다음에는 그룹별로 데이터를 집계하는 방법을 더 집중적으로 볼 것 같다.

COUNT / SUM / AVG / MIN / MAX
        ↓
GROUP BY
        ↓
그룹별 집계
        ↓
HAVING
        ↓
그룹 결과 조건 검색

특히 다음 내용을 중점적으로 복습해야겠다.

1. 단일행 함수와 복수행 함수의 차이

2. LENGTH와 CHAR_LENGTH의 차이

3. SUBSTRING / LEFT / RIGHT 구분

4. 함수 중첩 순서 읽는 연습

5. NULL과 빈 문자열의 차이

6. COUNT(*)와 COUNT(column)의 차이

7. 일반 컬럼과 그룹 함수를 함께 사용할 때
   GROUP BY가 필요한 이유

앞으로 GROUP BY, HAVING까지 배우면 단순히 한 명의 데이터를 가공하는 것에서 나아가 학과별 학생 수, 직급별 평균 급여처럼 그룹 단위로 데이터를 분석하는 SQL까지 연결해서 이해해봐야겠다.

[LG CNS 6기] 19일차 TIL : 데이터베이스 기초와 RDBMS·SELECT 조건 검색 실습

bbbicsan — Mon, 24 Aug 2026 18:02:53 +0900

[LG CNS 6기] 19일차 TIL : 데이터베이스 기초와 RDBMS·SELECT 조건 검색 실습

한 줄 요약
데이터베이스와 RDBMS의 기본 개념부터 무결성·관계·PK/FK·정규화까지 학습하고, MariaDB 실습 환경에서 SELECT, WHERE, LIKE, IN, BETWEEN, NULL, DISTINCT 등을 활용해 실제 데이터를 조건별로 조회했다.

오늘 학습한 커리큘럼

Database 기본 개념
        ↓
DBMS / RDBMS 이해
        ↓
Oracle · MySQL · MariaDB · NoSQL
        ↓
데이터와 정보의 차이
        ↓
데이터베이스 무결성
        ↓
관계형 데이터베이스
        ↓
Entity / Relationship
        ↓
PK / FK
        ↓
정규화
        ↓
참조 무결성
        ↓
MariaDB 실습 환경 구성
        ↓
SELECT 기본 문법
        ↓
WHERE 조건 검색
        ↓
AND / OR / NOT
        ↓
BETWEEN / IN
        ↓
LIKE / NOT LIKE
        ↓
IS NULL / IS NOT NULL
        ↓
DISTINCT
        ↓
Workbook Basic SELECT 실습

오늘의 학습 키워드

Database
DBMS
RDBMS
Oracle
MySQL
MariaDB
NoSQL
DBeaver
SQL
DDL / DML / DCL
Entity
Relationship
Primary Key
Foreign Key
Referential Integrity
Normalization
Index

1. 데이터베이스(Database)란?

데이터베이스는 여러 응용 시스템에서 사용할 수 있도록 데이터를 공유 가능한 형태로 통합하여 저장한 데이터의 집합이다.

강의에서는 특히 다음 세 가지가 중요하게 강조되었다.

공유
+
통합
+
중복 최소화

즉 조직에서 업무상 필요한 데이터를 각 프로그램마다 따로 저장하는 것이 아니라 하나의 데이터베이스에 모아 관리하는 것이다.

2. 데이터(Data)와 정보(Information)

데이터와 정보는 비슷해 보이지만 의미가 다르다.

구분	의미
Data	관찰이나 측정을 통해 얻어진 사실 또는 값
Information	데이터를 가공·해석하여 의미를 부여한 결과

예를 들면 다음과 같다.

학생 점수
90, 80, 70
        ↓
       Data
        ↓
평균 계산
        ↓
평균 점수 80점
        ↓
 Information

즉 데이터가 원재료라면 정보는 데이터를 처리해서 얻은 의미 있는 결과라고 볼 수 있다.

3. 데이터베이스의 특징

강의에서 데이터베이스의 주요 특징을 다음과 같이 정리했다.

데이터 독립성
→ Data Independence

데이터 무결성
→ Integrity

데이터 보안성
→ Security

데이터 불일치 배제
→ Inconsistency 방지

데이터 중복 감소
→ Redundancy 감소

데이터 공유
→ Share

이 중 오늘 수업에서는 특히 무결성(Integrity) 이 이후 관계형 데이터베이스 설계와 연결되는 중요한 개념이었다.

4. DBMS(Database Management System)

DBMS는 데이터베이스를 효율적으로 관리하기 위한 시스템이다.

사용자
  ↓
Application
  ↓
DBMS
  ↓
Database

사용자나 애플리케이션이 저장된 데이터를 직접 다루는 것이 아니라 DBMS가 중간에서 데이터의 저장·조회·수정·삭제 등을 관리한다.

정리하면:

Database
→ 실제 데이터의 집합

DBMS
→ Database를 관리하는 소프트웨어

DBMS는 데이터 모델에 따라 다음처럼 나눌 수 있다.

계층형 DBMS
망형 DBMS
관계형 DBMS
객체지향형 DBMS
객체관계형 DBMS

5. RDBMS와 관계형 데이터베이스

관계형 데이터베이스(Relational Database)는 데이터를 Table 형태로 관리하고 테이블 사이에 관계를 맺는 구조이다.

1969년 IBM 연구원이었던 E. F. Codd가 관계형 데이터베이스 모델을 제안했다고 학습했다.

관계형 데이터베이스의 핵심 구조는:

Table
 ↓
Column
 ↓
Row

그리고 여러 테이블을:

Primary Key
+
Foreign Key

를 이용해 연결한다.

예를 들면:

DEPARTMENT
DEPT_ID (PK)
     ↓
EMPLOYEE
DEPT_ID (FK)

처럼 부모 테이블의 키를 자식 테이블에서 참조할 수 있다.

6. 관계형 데이터베이스의 핵심 - PK와 FK

Primary Key

테이블의 각 행을 유일하게 식별할 수 있는 키이다.

Primary Key
→ 중복 X
→ NULL X
→ 하나의 행을 식별

Foreign Key

다른 테이블의 Primary Key를 참조하는 컬럼이다.

부모 Table
     ↓
Primary Key
     ↓
자식 Table
     ↓
Foreign Key

이를 통해 서로 분리된 테이블을 연결할 수 있다.

7. 데이터베이스 설계에서 중요한 무결성

오늘 강의에서는 데이터베이스 설계 시 참조 무결성(Referential Integrity) 이 중요하다고 강조했다.

예를 들어:

CUSTOMER
customer_id (PK)
        ↓
CAR
customer_id (FK)

처럼 자동차 테이블에서 고객을 참조하고 있다면 CAR.customer_id가 가리키는 고객은 실제 CUSTOMER 테이블에 존재해야 한다.

자식 FK
→ 존재하지 않는 부모 PK를 참조하면 안 됨

또 이미 자식 테이블에서 참조 중인 부모 키를 임의로 수정하거나 삭제하면 관계가 깨질 수 있으므로 제약조건이 필요하다.

8. 정규화가 필요한 이유

처음에는 고객정보와 자동차정보가 하나의 테이블에 들어 있는 예제를 확인했다.

고객정보
- 이름
- 주민번호
- 생년월일
- 전화번호
- 주소

자동차정보
- 차종
- 차명
- 년식
- 구입일

문제는 자동차를 가지고 있지 않은 고객이다.

자동차 없음

차종   → NULL
차명   → NULL
년식   → NULL
구입일 → NULL

서로 다른 주제의 데이터를 하나의 테이블에 넣으면 불필요한 NULL과 중복이 발생한다.

따라서 테이블을 분리한다.

개인신상
- 고객정보

자동차
- 차량정보

그리고 두 테이블 사이에 관계를 만들어준다.

CUSTOMER
    ↓
PK → FK
    ↓
CAR

이처럼 하나의 테이블이 하나의 명확한 주제를 갖도록 데이터를 분리하는 과정이 정규화의 중요한 목적 중 하나이다.

9. Relationship - 테이블 사이의 관계

강의에서는 관계를 업무적인 연관성이라고 설명했다.

예를 들면:

부서 ↔ 사원
고객 ↔ 자동차
고객 ↔ 주문

처럼 실제 업무에서 연관된 데이터 사이에 관계가 생긴다.

관계가 있는 두 테이블 중:

부모 테이블
+
자식 테이블

이 존재한다.

그리고:

부모 테이블 PK
        ↓
자식 테이블 FK

형태로 키가 전달된다.

10. 존재형 관계와 행위형 관계

관계는 크게 두 가지 관점으로 살펴봤다.

존재의 유형

부서
 ↓
사원

"부서에는 사원이 존재한다."

행위의 유형

고객
 ↓
주문

"고객이 주문한다."

부모와 자식을 판단하기 어려운 경우에는 관계를 문장으로 서술해보는 방법도 배웠다.

각 고객은 자동차를 소유한다.
각 자동차는 고객에 의해 소유된다.

이 경우 주체는 고객이므로:

고객
→ 부모

자동차
→ 자식

으로 판단할 수 있다.

11. 학사관리 ERD를 통해 관계 이해하기

학사관리 시스템 ERD에서는 다음 Entity들이 등장했다.

TB_DEPARTMENT
TB_STUDENT
TB_PROFESSOR
TB_CLASS
TB_CLASS_PROFESSOR
TB_GRADE

학과는 학생, 교수, 과목과 관계를 가진다.

TB_DEPARTMENT
DEPARTMENT_NO (PK)
        ↓
        ├─ TB_STUDENT.DEPARTMENT_NO
        ├─ TB_PROFESSOR.DEPARTMENT_NO
        └─ TB_CLASS.DEPARTMENT_NO

따라서:

학과 : 학생 = 1 : N
학과 : 교수 = 1 : N
학과 : 과목 = 1 : N

구조를 확인할 수 있었다.

12. N:M 관계와 연결 테이블

TB_CLASS와 TB_PROFESSOR 사이에는 TB_CLASS_PROFESSOR가 존재한다.

TB_CLASS
     ↓
TB_CLASS_PROFESSOR
     ↑
TB_PROFESSOR

TB_CLASS_PROFESSOR에는:

CLASS_NO (FK)
PROFESSOR_NO (FK)

가 존재한다.

이는 다대다(N:M) 관계를 중간 연결 테이블을 이용해 표현한 구조이다.

TB_GRADE도 비슷하다.

학생
 ↓
TB_GRADE
 ↑
과목

TB_GRADE
- TERM_NO
- CLASS_NO
- STUDENT_NO
- POINT

단순히 학생과 수업을 연결하는 것뿐만 아니라 관계 자체가 POINT라는 속성을 가지고 있다.

13. MariaDB 실습 환경 구성

오늘 SQL 실습을 위해 MariaDB를 설치했다.

MariaDB 설치
        ↓
lgcns Database 생성
        ↓
DB Client 연결
        ↓
SQL 실습

MariaDB

MariaDB는 관계형 데이터베이스 관리 시스템(RDBMS)이다.

MariaDB
→ 오픈소스 RDBMS
→ MySQL과 높은 호환성
→ Table 기반 데이터 저장
→ SQL을 이용한 데이터 관리

HeidiSQL

수업 화면에서는 HeidiSQL을 통해 MariaDB에 접속했다.

HeidiSQL
→ MariaDB / MySQL 등을 관리하는 GUI Client
→ Database / Table 확인
→ SQL 작성 및 실행
→ 데이터 조회 및 관리

즉:

MariaDB
→ 실제 데이터를 저장·관리하는 DBMS

HeidiSQL / DBeaver
→ DBMS에 접속하여 SQL을 실행하는 Client Tool

로 구분할 수 있다.

14. SQL의 종류

수업에서는 SQL을 다음과 같이 구분했다.

DDL
→ 정의

DML
→ 조작

DCL
→ 제어

SELECT
→ 데이터 검색

오늘은 그중에서도 데이터를 조회하는 SELECT를 집중적으로 실습했다.

15. SELECT 기본 문법

기본 구조는 다음과 같다.

SELECT [DISTINCT] 컬럼명 | * | 표현식 및 함수 [AS] 별칭
FROM 테이블명
[WHERE 행의 조건]
[GROUP BY 그룹 기준]
[HAVING 그룹 조건]
[ORDER BY 정렬 기준 ASC | DESC];

각 절의 역할은:

구문	역할
`SELECT`	조회할 컬럼 지정
`DISTINCT`	중복 제거
`FROM`	조회 대상 테이블
`WHERE`	행 조건
`GROUP BY`	그룹화
`HAVING`	그룹 조건
`ORDER BY`	결과 정렬

16. SELECT 기본 조회 실습

전체 컬럼을 조회할 때는 *를 사용한다.

SELECT *
FROM employee;

필요한 컬럼만 선택할 수도 있다.

SELECT emp_id,
       emp_name
FROM employee;

즉:

SELECT *
→ 모든 Column

SELECT emp_id, emp_name
→ 필요한 Column만

이다.

17. WHERE - 원하는 행만 검색하기

예를 들어 부서번호가 90인 사원을 검색했다.

SELECT *
FROM employee
WHERE dept_id = '90';

employee 전체 데이터
        ↓
DEPT_ID = '90'
        ↓
90번 부서 사원만 조회

18. AND - 여러 조건을 모두 만족

강사님 Q)

부서번호가 90번이고
급여가 4,000,000 이상인 사원의
모든 정보를 검색한다면?

풀이:

SELECT *
FROM employee
WHERE DEPT_ID = '90'
  AND SALARY >= 4000000;

AND는 두 조건을 모두 만족해야 한다.

조건 A
 AND
조건 B
 ↓
둘 다 TRUE인 행

19. OR - 여러 조건 중 하나라도 만족

강사님 Q)

부서번호가 60번이거나
90번인 사원을 검색한다면?

SELECT *
FROM employee
WHERE DEPT_ID = '60'
   OR DEPT_ID = '90';

A OR B
→ 둘 중 하나라도 TRUE이면 조회

20. BETWEEN - 범위 검색

강사님 Q)

급여가 3,500,000 이상
5,500,000 이하인 사원의
이름, 급여, 직급을 검색한다면?

SELECT e.EMP_NAME,
       e.SALARY,
       j.JOB_TITLE
FROM employee e,
     job j
WHERE e.JOB_ID = j.JOB_ID
  AND e.SALARY BETWEEN 3500000 AND 5500000;

BETWEEN은 양 끝값을 포함한다.

BETWEEN 3500000 AND 5500000

3500000 <= SALARY <= 5500000

21. CONCAT() - 문자열 연결

CONCAT()을 이용해 여러 문자열을 하나로 연결할 수 있다.

SELECT CONCAT(
    EMP_NAME,
    '님의 급여는 ',
    SALARY,
    '(원)입니다.'
) AS 급여정보
FROM employee;

결과는 다음과 같은 문장 형태가 된다.

한선기님의 급여는 9000000(원)입니다.

그리고 AS를 사용해 결과 컬럼의 별칭을 지정할 수 있다.

22. LIKE / NOT LIKE - 패턴 검색

문자열 패턴 검색에는 LIKE를 사용한다.

%
→ 0개 이상의 문자열

_
→ 정확히 한 글자

강사님 Q)

김씨 성을 가지는 사원의
모든 정보를 검색한다면?

SELECT *
FROM employee
WHERE EMP_NAME LIKE '김%';

반대로 김씨가 아닌 사원은:

SELECT *
FROM employee
WHERE EMP_NAME NOT LIKE '김%';

이다.

23. LIKE에서 실제 `_` 문자 검색

강사님 Q)

메일 ID에서
_ 앞의 문자가 정확히 3자리인
사원을 검색한다면?

_ 자체가 LIKE에서는 한 글자를 의미하는 와일드카드이므로 실제 _를 검색하려면 Escape가 필요하다.

SELECT *
FROM employee
WHERE EMAIL LIKE '___!_%'
ESCAPE '!';

패턴을 해석하면:

___
→ 정확히 3글자

!_
→ 실제 "_" 문자

%
→ 이후 문자열

이다.

24. NULL 검색

SQL에서 NULL은 일반 값과 다르기 때문에:

= NULL      ❌
IS NULL     ✅

!= NULL     ❌
IS NOT NULL ✅

로 작성해야 한다.

강사님 Q)

부서 배치를 받지 않은 사원은?

SELECT *
FROM employee
WHERE DEPT_ID IS NULL;

25. Index를 이용한 데이터 접근

Index를 이용한 데이터 접근 방식도 개념적으로 확인했다.

SQL 조건
   ↓
INDEX KEY 검색
   ↓
ROWID 확인
   ↓
실제 TABLE Row 접근
   ↓
결과 반환

즉 전체 Table을 처음부터 확인하는 것이 아니라 Index를 통해 필요한 데이터의 위치를 찾고 해당 Row에 접근할 수 있다.

오늘은 Index의 세부 구조보다는 Index가 데이터 접근 경로를 제공한다는 개념을 중심으로 이해했다.

Workbook Basic SELECT 실습

오늘은 춘 대학교 교육시스템의 테이블을 이용해 Basic SELECT 문제도 직접 풀었다.

Q1. 학과 이름과 계열 출력

SELECT DEPARTMENT_NAME AS '학과 명',
       CATEGORY AS '계열'
FROM tb_department;

학습 포인트

AS
→ 조회 결과 Column의 별칭 설정

Q2. 학과별 정원 문장으로 출력

SELECT CONCAT(
    DEPARTMENT_NAME,
    '의 정원은 ',
    CAPACITY,
    '명 입니다.'
) AS '학과별 정원'
FROM tb_department;

실행 결과:

국어국문학과의 정원은 20명 입니다.
영어영문학과의 정원은 36명 입니다.
사학과의 정원은 28명 입니다.
...

학습 포인트

Column
+
문자열
+
Column
        ↓
CONCAT()

Q3. 국어국문학과 여학생 중 현재 휴학생 찾기

먼저 학과번호를 조회했다.

SELECT DEPARTMENT_NO
FROM TB_DEPARTMENT
WHERE DEPARTMENT_NAME = '국어국문학과';

결과:

이후 학생 테이블에서 조건을 추가했다.

SELECT a.STUDENT_NAME
FROM tb_student a
WHERE 1 = 1
  AND a.ABSENCE_YN = 'Y'
  AND a.DEPARTMENT_NO = '001'
  AND (
       a.STUDENT_SSN LIKE '______-2%'
    OR a.STUDENT_SSN LIKE '______-4%'
  );

이 문제에서는 여러 개의 조건이 동시에 사용되었다.

국어국문학과
+
휴학생
+
여학생

26. WHERE 1=1

Q3 실습 중 WHERE 1=1 패턴도 확인했다.

WHERE 1 = 1
  AND 조건1
  AND 조건2
  AND 조건3

1=1은 항상 TRUE이므로 결과에는 영향을 주지 않는다.

대신 조건을 계속 추가할 때:

AND 조건
AND 조건
AND 조건

형태로 작성하기 편하다.

특히 동적 SQL을 구성할 때 사용할 수 있는 패턴이다.

27. AND와 OR의 우선순위 주의

다음처럼 작성하면:

WHERE 조건1
  AND 조건2
  OR 조건3

의도와 다르게 처리될 수 있다.

따라서 하나의 조건 그룹으로 처리해야 할 OR들은 괄호로 묶는 것이 중요하다.

WHERE 1 = 1
  AND a.ABSENCE_YN = 'Y'
  AND (
       조건1
    OR 조건2
  );

이번 Q3에서 조건식을 작성하면서 SQL에서도 논리 연산자 우선순위를 고려해야 한다는 점을 확인했다.

Q4. 지정된 학번의 학생 조회

SELECT STUDENT_NAME
FROM tb_student
WHERE STUDENT_NO IN (
    'A513079',
    'A513090',
    'A513091',
    'A513110',
    'A513119'
);

총 5명의 학생이 조회되었다.

학습 포인트

IN
→ 여러 후보 중 하나와 일치하는지 검사

아래처럼 여러 OR를 작성하는 것보다 간결하다.

STUDENT_NO = 'A513079'
OR STUDENT_NO = 'A513090'
OR ...

Q5. 정원이 20명 이상 30명 이하인 학과

SELECT DEPARTMENT_NAME,
       CATEGORY
FROM tb_department
WHERE CAPACITY BETWEEN 20 AND 30;

BETWEEN
→ 범위 검색
→ 시작값과 끝값 포함

Q6. 소속 학과가 없는 교수 찾기

총장을 제외한 모든 교수가 학과에 소속되어 있다는 조건을 이용했다.

SELECT PROFESSOR_NAME
FROM tb_professor
WHERE DEPARTMENT_NO IS NULL;

실행 결과:

임해정

즉 소속 학과가 없는 교수가 총장임을 확인했다.

Q7. 학과가 지정되지 않은 학생 확인

단순 조회가 아니라 몇 명인지 확인하기 위해 COUNT(*)를 사용했다.

SELECT COUNT(*) AS '학생 수'
FROM TB_STUDENT st
WHERE st.DEPARTMENT_NO IS NULL;

실행 결과:

학생 수
0

현재 데이터에는 학과가 지정되지 않은 학생이 없었다.

MariaDB에서는 다음 함수도 확인했다.

ISNULL(DEPARTMENT_NO)

IS NULL
→ SQL 조건식

ISNULL()
→ MariaDB/MySQL 함수

Q8. 선수과목이 존재하는 과목 조회

SELECT CLASS_NO
FROM tb_class
WHERE PREATTENDING_CLASS_NO IS NOT NULL;

실행 결과:

총 6개의 과목이 조회되었다.

IS NULL
→ 값 없음

IS NOT NULL
→ 값 있음

Q9. 대학에 존재하는 계열 조회

SELECT DISTINCT CATEGORY
FROM tb_department;

실행 결과:

인문사회
자연과학
공학
의학
예체능

DISTINCT를 사용하여 중복을 제거한 결과 5개의 계열이 조회되었다.

Q10. 02학번 전주 거주 재학생 조회

조건은 다음과 같았다.

휴학생 제외
+
전주 거주
+
2002년도 입학

실습 SQL:

SELECT a.STUDENT_NO,
       a.STUDENT_NAME,
       a.STUDENT_SSN
FROM tb_student a
WHERE 1 = 1
  AND a.ABSENCE_YN = 'N'
  AND a.STUDENT_ADDRESS LIKE '%전주%'
  AND a.ENTRANCE_DATE LIKE '2002-%';

실행 결과 총 11건이 조회되었다.

수업에서는 다음과 같은 ORDER BY 표현도 확인했다.

ORDER BY 2 ASC, 1, 3 DESC;

SELECT 결과의 컬럼 순번을 기준으로 보면:

2 ASC
→ STUDENT_NAME 오름차순

1
→ STUDENT_NO 오름차순

3 DESC
→ STUDENT_SSN 내림차순

처럼 정렬할 수 있다.

오늘의 SQL 실습 핵심 정리

오늘 사용한 조회 조건을 한 번에 정리하면:

SELECT
→ 데이터 조회

AS
→ 출력 컬럼 별칭

CONCAT()
→ 문자열 연결

WHERE
→ 행 조건

AND
→ 모든 조건 만족

OR
→ 하나 이상의 조건 만족

BETWEEN
→ 범위 검색

IN
→ 여러 값 중 하나와 일치

LIKE
→ 문자열 패턴 검색

NOT LIKE
→ 패턴과 일치하지 않는 데이터

%
→ 0개 이상의 문자열

_
→ 정확히 한 글자

IS NULL
→ 값이 없는 데이터

IS NOT NULL
→ 값이 존재하는 데이터

DISTINCT
→ 중복 제거

COUNT(*)
→ 행의 개수 계산

문제 해결 과정

1. Q3 - 한 가지 조건이 아닌 여러 조건을 조합해 조회하기

문제

국어국문학과
+
여학생
+
휴학생

이라는 세 가지 조건을 동시에 만족하는 학생을 찾아야 했다.

처음에는 하나의 조건만 생각하면 간단했지만, 실제 문제에서는 여러 Column의 조건을 조합해야 했다.

해결 과정

먼저 국어국문학과의 학과번호를 조회했다.

SELECT DEPARTMENT_NO
FROM TB_DEPARTMENT
WHERE DEPARTMENT_NAME = '국어국문학과';

그 결과를 이용해 학생 조회 조건을 만들었다.

WHERE 1 = 1
AND ABSENCE_YN = 'Y'
AND DEPARTMENT_NO = '001'

마지막으로 주민번호 패턴을 이용한 조건을 추가했다.

AND (
     STUDENT_SSN LIKE '______-2%'
  OR STUDENT_SSN LIKE '______-4%'
)

배운 점

한 문장을 바로 SQL로 옮기려고 하기보다 요구사항을:

학과 조건
휴학 조건
성별 조건

처럼 작은 단위로 나누고 하나씩 WHERE에 추가하면 훨씬 이해하기 쉬웠다.

또 AND와 OR를 함께 사용할 때는 괄호를 이용해 조건의 논리적 범위를 명확하게 만들어야 한다는 점도 확인했다.

2. 여러 값을 비교할 때 OR 대신 IN 사용

장기 연체자 5명을 찾는 문제에서는:

STUDENT_NO = 'A513079'
OR STUDENT_NO = 'A513090'
OR ...

처럼 작성할 수도 있었다.

하지만 같은 컬럼을 여러 값과 비교하는 경우:

WHERE STUDENT_NO IN (...)

으로 바꾸니 훨씬 읽기 쉬운 SQL이 되었다.

즉 SQL에서도 단순히 실행되는 코드를 만드는 것뿐만 아니라 조건을 어떤 형태로 표현해야 더 읽기 좋은지도 중요하다는 것을 확인했다.

✨ 오늘 배운 내용 정리

오늘 수업은 단순히 SELECT 문법만 배우는 시간이 아니었다.

먼저:

Database
→ DBMS
→ RDBMS
→ Table
→ Entity
→ Relationship
→ PK / FK
→ Referential Integrity
→ Normalization

이라는 데이터베이스의 전체적인 구조를 먼저 이해했다.

이후 실제 MariaDB에 데이터를 구성하고 SQL을 작성하면서 이론을 데이터 조회와 연결했다.

특히 관계형 데이터베이스에서 테이블을 무작정 하나로 합치는 것이 아니라:

하나의 명확한 주제
→ 하나의 Table

관련된 다른 데이터
→ 다른 Table

Table 연결
→ PK / FK

이라는 설계 방향이 중요하다는 것을 알게 되었다.

SQL에서는 처음에는:

SELECT *
FROM table;

처럼 단순한 조회에서 시작했지만 점차:

WHERE
→ 조건

AND / OR
→ 조건 조합

BETWEEN
→ 범위

IN
→ 여러 값

LIKE
→ 패턴

NULL
→ 값의 존재 여부

DISTINCT
→ 중복 제거

까지 조건을 구체적으로 표현할 수 있게 되었다.

Workbook 문제를 직접 풀어보면서 각각의 연산자를 따로 외우는 것보다 “어떤 데이터를 찾고 싶은가?”에 따라 적절한 조건식을 선택하는 것이 중요하다는 점을 확인할 수 있었다.

오늘의 회고

오늘부터 본격적으로 데이터베이스 수업이 시작됐다.

프로젝트를 하면서 PostgreSQL이나 JPA를 사용해 본 경험은 있었지만, 오늘처럼 데이터베이스 자체의 개념부터 관계와 무결성, 정규화까지 순서대로 다시 학습하니 이전에 사용했던 기술들이 왜 그런 구조를 가지고 있었는지 조금 더 명확하게 연결됐다.

특히 가장 기억에 남은 것은 테이블을 나누는 이유와 관계를 만드는 과정이었다.

처음 고객과 자동차 정보를 하나의 테이블에 넣었을 때는 단순히 컬럼이 많아지는 정도의 문제로 보였지만, 자동차가 없는 고객 때문에 여러 NULL 값이 발생하는 예제를 보면서 서로 다른 주제의 데이터가 한 테이블에 섞였을 때 어떤 문제가 생기는지 확인할 수 있었다.

이를:

고객
+
자동차

두 테이블로 분리하고:

부모 PK
→ 자식 FK

로 관계를 만드는 과정에서 이전에 ERD를 그릴 때 사용했던 PK와 FK의 의미도 다시 정리할 수 있었다.

SQL 실습에서는 WHERE 조건을 작성하는 것이 생각보다 중요했다.

단순히:

WHERE DEPARTMENT_NO = '001'

처럼 하나의 조건만 작성하는 것은 어렵지 않았지만, Workbook Q3처럼:

국어국문학과
AND
휴학생
AND
(
    여성 조건1
    OR
    여성 조건2
)

처럼 여러 조건이 섞이기 시작하자 조건의 우선순위와 괄호의 중요성이 보이기 시작했다.

또 Workbook Basic SELECT Q1~Q10을 직접 실행하고 결과까지 확인하면서:

문제에서 조건 추출
        ↓
필요한 Table 확인
        ↓
조회할 Column 결정
        ↓
WHERE 조건 작성
        ↓
SQL 실행
        ↓
결과 검증

이라는 문제 해결 흐름을 반복할 수 있었다.

앞으로 JOIN이나 GROUP BY, Subquery 등을 배우면 지금은 여러 단계로 조회했던 데이터도 하나의 SQL로 처리하게 될 것 같다.

오늘은 우선 SELECT의 기본기를 확실하게 잡고, 특히 WHERE, LIKE, IN, BETWEEN, NULL, DISTINCT를 문제 상황에 맞게 선택할 수 있도록 복습해야겠다.

다음 학습 방향

SELECT 기본 조회 복습
        ↓
WHERE 조건식 익숙해지기
        ↓
LIKE / IN / BETWEEN 정확히 구분
        ↓
ORDER BY
        ↓
SQL 함수
        ↓
GROUP BY / HAVING
        ↓
JOIN
        ↓
Subquery
        ↓
DDL / DML

특히 다음 수업부터 여러 테이블을 함께 조회하게 된다면 오늘 배운:

Entity
Relationship
PK
FK
참조 무결성

개념을 SQL의 JOIN과 연결해서 이해하는 것을 목표로 해야겠다.

[ADsP] 26년도 50회 ADsP 합격 후기 (Feat. 5일 벼락치기) & 공부법·교재·꿀팁

bbbicsan — Fri, 21 Aug 2026 20:25:40 +0900

2026년 8월 8일, 제50회 ADsP 데이터분석 준전문가 시험에 응시했고 최종 68점으로 합격했다.

1과목 : 16 / 20
2과목 : 16 / 20
3과목 : 36 / 60

총점  : 68 / 100
결과  : 합격 ✅

점수만 보면

“생각보다 안정적으로 합격했네?”

라고 생각할 수도 있다.

그런데 시험장에서 느꼈던 체감은 정말 달랐다.

‍ “이거 진짜 간당간당하게 붙거나 떨어지겠는데?”

50회 ADsP를 직접 응시한 입장에서 느낀 체감 난이도는 정말 높았다.

문제가 상당히 지엽적이었고 처음 보는 유형도 많았으며, 무엇보다 정답을 끝까지 고민하게 만드는 헷갈리는 선지가 많았다.

개인적으로는 기존의

“ADsP는 대충 준비해도 합격할 수 있는 시험”

이라는 인식에서 조금 벗어나려는 시도가 느껴진 회차였다.

나는 전공자 기준 총 5일을 준비했다.

기출과 모의고사를 풀 때는 못 봐도 70점대, 대부분 80점 이상이 나왔기 때문에 시험 전까지 불합격을 크게 생각하지 않았다.

그런데 막상 시험을 보고 나서는 생각이 완전히 달라졌다.

시험 이틀 정도 뒤 인터넷에 올라온 복원문제로 보수적으로 가채점했을 때는 약 64점 정도가 나왔고, 결과 발표 전까지는 생각보다 꽤 불안했다.

그래도 최종적으로는 68점으로 합격했고, 이번 글에서는 내가 실제로 했던

아답터 요약강의
        ↓
미어캣책 개념 1회독
        ↓
기출문제
        ↓
모의고사
        ↓
오답 + 개념 리마인드

공부법과 함께 전공자 기준 5일 벼락치기 공부법 + 실제 시험 후기 + 나만의 ADsP 꿀팁을 정리해보려고 한다.

50회 ADsP, 체감 난이도는?
‍ 먼저, 내 공부 베이스
사용한 공부 자료
내가 실제로 한 5일 공부법
STEP 1. 아답터 요약강의로 전체 흐름 잡기
STEP 2. 미어캣책으로 개념 1회독
STEP 3. 기출·모의고사 + 오답 정리
️ 실제 50회 시험 후기
실제 시험 결과
직접 준비하면서 느낀 ADsP 꿀팁 4가지
✅ 최종 정리

50회 ADsP, 체감 난이도는?

50회 ADsP 시험을 응시한 분들이나 이후 시험을 준비하면서 50회 후기를 찾아본 분들이라면 어느 정도 공감할 것 같다.

개인적인 체감으로는,

50회 시험은 정말 어려웠다.

물론 나중에 복원된 문제를 다시 차분하게 풀어보면 시험장에서 느꼈던 것만큼 어렵지 않다고 생각할 수도 있다.

하지만 실제 시험장에서 처음 문제를 봤을 때의 체감 난이도는 상당히 높았다.

특히 크게 느낀 점은 세 가지였다.

① 기존 기출에서 자주 보지 못했던 지엽적인 내용

② 처음 보는 유형의 문제

③ 끝까지 헷갈리게 만드는 선지

보통 ADsP에 대해 찾아보면

“기출 몇 번 돌리면 된다.”

“며칠이면 충분하다.”

“생각보다 쉬운 자격증이다.”

라는 이야기를 많이 볼 수 있다.

나 역시 기출과 모의고사 점수가 잘 나왔기 때문에 시험 전까지는 비슷하게 생각했다.

그런데 50회에서는 단순히 기존 기출의 정답이나 자주 나오는 개념만 외우는 방식으로는 당황할 만한 문제가 꽤 있었다.

개인적으로 이번 50회는 기존의 “ADsP는 대충 준비해도 합격한다”는 인식에서 벗어나려는 느낌이 강했다.

특히 방학 기간이라 응시자도 많았고 시험 자체가 변화하는 과정에서 나온 조금 특이한 회차라고 느꼈다.

그래서 이번 시험을 통해 느낀 건,

앞으로 ADsP를 준비한다면 빈출 개념은 확실하게 잡되, 기본서의 세부 내용도 최소한 한 번은 읽어보는 것이 좋다.

는 것이다.

‍ 먼저, 내 공부 베이스

단기 합격 후기에서 가장 중요한 것은 결국 어떤 상태에서 시작했는가라고 생각한다.

내 기준은 다음과 같다.

구분	내용
전공 여부	전공자
준비기간	5일
시험	제50회 ADsP
기출·모의고사	못 보면 70점대, 대부분 80점 이상
실제 시험	체감 난이도 매우 높음
복원 가채점	보수적으로 약 64점
실제 결과	68점 합격

시험을 준비하면서 기출과 모의고사에서는 점수가 꽤 안정적으로 나왔다.

못 봤다고 생각한 시험도 70점 이상, 대부분은 80점 이상을 유지했다.

그래서 솔직히 시험을 보기 전에는

“설마 떨어지겠어?”

라는 생각이 컸다.

그런데 실제 시험이 끝난 직후에는 정반대였다.

“와... 이거 진짜 간당간당하게 붙거나 떨어질 수도 있겠다.”

라고 느꼈다.

그만큼 기출·모의고사와 실제 50회 시험의 체감 차이가 컸다.

사용한 공부 자료

이번 시험에서는 크게 두 가지 자료를 사용했다.

① 2026 이지패스 ADsP 데이터분석 준전문가

흔히 미어캣책이라고 부르는 교재다.

② 유튜버 아답터 ADsP 요약강의

결론부터 말하면,

⭐ 둘 다 추천한다.

두 자료의 역할이 서로 다르기 때문이다.

아답터 요약강의
        ↓
전체 흐름 + 빈출 개념 빠르게 파악

미어캣책
        ↓
세부 개념 + 빈출도 + 기출 포인트 보완

기출 / 모의고사
        ↓
실제 문제 유형 적응 + 부족한 개념 확인

특히 준비기간이 5일밖에 없었기 때문에 처음부터 기본서만 정독하기보다는,

요약강의로 전체 구조를 먼저 파악한 뒤 기본서를 읽는 방식이 상당히 효율적이었다.

내가 실제로 한 5일 공부법

실제로 공부했던 5일을 정리하면 다음과 같다.

[1일차]

아답터 요약강의 전체 수강
        ↓
미어캣책 1과목 개념 1회독


[2일차]

미어캣책 2과목
        ↓
3과목 약 1/3까지 개념 1회독


[3일차]

미어캣책 3과목
나머지 약 2/3 개념 1회독


[4일차]

기출문제 약 3회분
        ↓
오답 정리
        ↓
문제를 통해 개념 리마인드


[5일차]

제공 모의고사 약 3회분
        ↓
오답 정리
        ↓
부족한 개념 최종 복습


[시험 당일]

아침 + 시험장 이동
        ↓
아답터 요약강의 재청취
        ↓
특히 1·2과목 집중 복습

정리하면,

3일 개념 + 2일 기출·모의고사

형태로 준비했다.

5일이라는 시간이 짧았기 때문에 모든 개념을 완벽하게 암기하려고 하기보다는,

전체 흐름 파악
        ↓
기본서로 빈틈 채우기
        ↓
문제를 풀며 자주 나오는 개념 확인
        ↓
오답으로 다시 개념 복습

이 사이클을 만드는 데 집중했다.

STEP 1. 아답터 요약강의로 전체 흐름 잡기

50회 시험이 어렵게 나온 이후, 아답터 요약강의에 대해

“이제 아답터 요약강의 의미 없어진 거 아니야?”

“50회에서는 강의에서 안 나온 게 너무 많았다.”

라는 반응도 많이 나왔다.

실제로 이번 50회는 상당히 지엽적으로 출제됐기 때문에 아답터 요약강의에서 다루지 않은 내용도 분명히 있었다.

하지만 그렇다고 해서 아답터 요약강의의 가치가 사라졌다고 생각하지는 않는다.

오히려 반대로,

가장 짧은 시간 안에 가장 자주 출제되는 개념들을 중심으로 전체 범위를 한 바퀴 돌 수 있다는 점

에서는 여전히 상당히 좋은 자료라고 생각한다.

특히 준비기간이 짧다면 더더욱 그렇다.

처음 강의를 들을 때의 목표는 모든 내용을 외우는 것이 아니었다.

“1과목에서는 이런 내용을 배우는구나.”

“2과목에서는 이런 개념들이 중요하구나.”

“3과목은 이런 분석 방법들이 나오는구나.”

정도로 전체적인 내용의 흐름을 잡는 것에 집중했다.

그리고 개인적으로는 아답터 요약강의의 핵심 내용을 제대로 숙지한다면 1·2과목에서 기본 점수를 확보하는 데 상당한 도움이 된다고 느꼈다.

특히 1·2과목은 핵심 개념을 묻는 문제가 많기 때문에 시험 직전 복습 자료로 활용하기에도 좋았다.

그래서 나는 시험 당일 아침과 시험장 이동 중에도 1·2과목 위주로 요약강의를 한 번 더 들었다.

짧은 시간에 전체 흐름과 빈출 개념을 잡는 용도로는 여전히 강력하게 추천한다.

STEP 2. 미어캣책으로 개념 1회독

요약강의로 전체 흐름을 잡은 뒤에는 미어캣책으로 개념을 1회독했다.

ADsP를 준비하는 사람들이 많이 사용하는 이유를 알 수 있을 정도로 개인적으로 만족도가 높은 교재였다.

특히 좋았던 점은,

개념 설명
+
중요 개념
+
빈출 포인트
+
기존 기출 관련 내용

을 함께 볼 수 있다는 점이었다.

그리고 50회처럼 지엽적인 시험을 경험하고 나니 더욱 강조하고 싶은 부분이 있다.

기본서 구석에 있는 내용도 가능하면 한 번씩 읽어보자.

대표적인 예가 MapReduce였다.

이번 50회에서 MapReduce와 관련된 문제가 출제됐는데, 기존 기출에서는 상대적으로 자주 접했던 주제가 아니었다.

그런데 미어캣책에서 해당 내용을 읽었던 기억이 남아 있었고, 시험장에서

“잠깐, 이거 책에서 봤던 내용인데?”

라는 기억을 활용해 결국 문제를 맞힐 수 있었다.

이 경험 때문에 ADsP도 앞으로는 단순히 빈출 개념만 반복하기보다 기본서의 세부 내용을 최소 한 번은 눈에 익히는 것을 추천하고 싶다.

정확한 정의를 전부 외우지 못하더라도,

“본 적이 있다.”

라는 기억 자체가 시험에서 생각보다 큰 도움이 된다.

특히 50회처럼 지엽적인 문제가 섞이는 시험에서는 이 차이가 더 크게 느껴졌다.

STEP 3. 기출·모의고사 + 오답 정리

개념 공부를 마친 뒤에는 바로 기출문제로 넘어갔다.

개인적으로 자격증 시험에서 가장 중요한 공부 중 하나가 바로 기출문제라고 생각한다.

ADsP 역시 마찬가지다.

기출을 반복하다 보면

어떤 개념이 자주 나오는지

어떤 방식으로 질문하는지

어떤 선지가 자주 헷갈리게 나오는지

가 조금씩 보이기 시작한다.

4일차

기출문제 약 3회분 + 오답 정리

5일차

제공 모의고사 약 3회분 + 오답 정리

이렇게 진행했다.

여기서 중요한 것은 단순히

“오늘 82점 나왔다.”

하고 점수만 확인하는 것이 아니다.

나는 문제를 틀렸다면 해당 문제의 개념을 다시 확인하면서 문제를 통해 개념을 리마인드하는 방식으로 공부했다.

문제 풀이
   ↓
오답 확인
   ↓
왜 틀렸는지 확인
   ↓
관련 개념 복습
   ↓
다음 문제에 적용

기출문제는 단순한 실전 연습이 아니라,

내 개념 공부에서 비어 있는 부분을 찾아내는 도구

라고 생각하면 좋다.

그리고 단기 준비에서는 기출문제를 통해 공부 범위를 다시 압축하는 과정도 중요하다.

처음 기본서를 볼 때는 모든 내용이 중요해 보이지만, 기출을 반복하다 보면

“아, 이 부분은 이런 식으로 자주 물어보는구나.”

라는 감이 생긴다.

그때부터 공부 효율이 훨씬 좋아졌다.

️ 실제 50회 시험 후기

시험 전까지만 해도 나는 ADsP 불합격을 크게 걱정하지 않았다.

기출과 모의고사에서

못 보면 70점대, 대부분 80점 이상

이 꾸준하게 나왔기 때문이다.

그런데 실제 50회 시험은 예상과 완전히 달랐다.

문제를 풀면서 계속 느낀 건,

“이런 것도 나와?”

“이건 기출에서 거의 못 본 것 같은데?”

“두 선지가 왜 이렇게 둘 다 맞는 것 같지?”

였다.

특히 지엽적인 내용과 헷갈리는 선지가 많아서 문제를 풀고 나서도 확신이 들지 않는 경우가 많았다.

시험을 다 보고 나왔을 때의 생각은 거의 하나였다.

“이거 진짜 간당간당하게 붙거나 떨어지겠다.”

시험 후 약 이틀 정도 뒤 인터넷에 올라온 복원문제를 바탕으로 가채점도 해봤다.

이때는 최대한 보수적으로 채점했다.

내가 어떤 답을 골랐는지 기억이 안 남
        ↓
오답 처리

복원 정답에 대한 의견이 갈림
        ↓
오답 처리

이런 식으로 애매한 문제는 전부 틀린 것으로 계산했다.

그 결과 약

64점 정도

가 나왔던 것으로 기억한다.

합격선은 넘었지만 워낙 시험 체감이 좋지 않았고 복원문제의 정답도 완전히 확정된 상태가 아니었기 때문에 결과 발표 전까지는 조금 불안했다.

실제 시험 결과

그리고 최종 결과는,

1과목 : 16 / 20
2과목 : 16 / 20
3과목 : 36 / 60

──────────────

총점 : 68점

✅ 합격

이었다.

복원문제로 보수적으로 가채점했을 때보다 조금 더 높은 점수가 나왔고, 결과적으로는 68점으로 안정적으로 합격했다.

특히 내가 시험 직전에 집중했던 1·2과목에서 각각 16점씩 확보한 것이 전체 점수를 만드는 데 꽤 큰 역할을 했다.

1과목 16점
+
2과목 16점
=
32점 확보

50회 시험을 보고 가채점까지 했을 때는

“내 공부 방법이 잘못된 건가?”

라는 생각도 조금 들었다.

하지만 결과적으로 내가 사용한

요약강의
   ↓
기본서
   ↓
기출
   ↓
모의고사
   ↓
오답 정리

공부법 자체는 충분히 유효했다고 생각한다.

직접 준비하면서 느낀 ADsP 꿀팁 4가지

이제부터는 이번 시험을 준비하고 직접 응시하면서 느낀 개인적인 ADsP 공략법을 정리해보려고 한다.

1. 과목 과락을 지나치게 걱정하지 말자

ADsP는 각 과목에서 40% 미만을 받으면 과락이 발생한다.

전체 점수가 합격 기준을 넘더라도 한 과목에서 과락이 발생하면 불합격이기 때문에 처음 공부하면 이 부분이 상당히 신경 쓰인다.

특히 가장 많이 걱정하는 것이 3과목이다.

나 역시 처음에는 3과목 과락이 가장 걱정됐다.

하지만 직접 공부하고 시험까지 본 입장에서는,

과락 자체를 너무 무서워할 필요는 없다고 생각한다.

먼저 1·2과목은 대부분 개념 관련 문제가 중심이기 때문에 기본적인 암기가 되어 있다면 최소 점수를 확보하기 상대적으로 수월하다.

문제는 3과목이다.

3과목은 확실히 어렵다.

다만 3과목은 30문제로 문제 수가 가장 많다.

과락을 피하려면 40% 이상이 필요하므로 최소 12문제 이상을 맞혀야 한다.

3과목 총 문제 : 30문제

과락 기준
→ 40% 이상

필요 정답 수
→ 최소 12문제

처음 보면 12문제가 많아 보일 수 있다.

하지만 3과목에도 개념만 알고 있으면 풀 수 있는 문제, 어렵지 않은 문제, 데이터 해석 문제 등 충분히 점수를 확보할 수 있는 유형이 섞여 있다.

또 문제 수가 30문제로 많다는 것도 오히려 장점이 될 수 있다.

모르는 문제가 조금 있더라도 나머지 문제에서 점수를 확보하거나, 완전히 모르는 문제에서도 선지를 줄여 찍어서 맞힐 가능성이 있기 때문이다.

그래서 결론은,

3과목에서 고득점을 노리기보다 우선 과락을 피하는 전략으로 접근하자.

과락을 지나치게 걱정하면서 3과목 하나에 모든 시간을 사용하는 것보다 전체 점수 전략을 짜는 것이 더 중요하다.

2. 1·2과목에서 최대한 점수를 확보하자

1번 팁과 바로 이어지는 내용이다.

ADsP에서 가장 안정적인 합격 전략 중 하나는

1·2과목에서 최대한 점수를 확보하고 3과목에서 과락을 피하는 것

이라고 생각한다.

공부해보면 1·2과목은 3과목과 비교했을 때 확실히 접근하기 쉽다.

개념 관련 문제가 많기 때문에 빈출 개념을 잘 암기하면 점수 확보가 상대적으로 쉽다.

실제로 내 점수도

1과목 : 16 / 20
2과목 : 16 / 20

→ 두 과목에서 총 32점 확보

였다.

예를 들어 1·2과목에서 각각 8문제씩 맞혔다고 해보자.

1과목 : 8문제 정답 → 16점
2과목 : 8문제 정답 → 16점

총 32점 확보

합격에 필요한 점수가 60점이라면, 남은 3과목에서 28점만 추가로 확보하면 된다.

3과목은 한 문제당 2점이므로,

28점 ÷ 2점
= 14문제

즉, 30문제 중 14문제를 맞히면 전체 60점을 만들 수 있다.

1과목 8문제
+
2과목 8문제
+
3과목 14문제

= 60점

이렇게 계산해보면 생각보다 합격 전략이 명확해진다.

그래서 나는 시험 당일에도 3과목 전체를 다시 보는 것보다 아답터 요약강의의 1·2과목을 우선적으로 복습했다.

개인적으로 1·2과목에서는 아직도 아답터 요약강의의 효과가 상당히 크다고 느꼈다.

✅ 1·2과목은 최대한 확실하게, 3과목은 과락을 피하면서 추가 점수를 확보하자.

단기 준비에서는 특히 추천하고 싶은 전략이다.

3. 가장 중요! 전부 이해하려 하지 말고 키워드를 중심으로 암기하자

이건 정보처리기사 필기를 준비할 때도 느꼈던 부분인데, ADsP에도 그대로 적용됐다.

우리의 목표를 다시 생각해보면,

우선은 ADsP 자격증 취득이다.

물론 개념을 제대로 이해하면 가장 좋다.

하지만 자격증 시험을 준비하면서 모든 개념을 100% 이해할 때까지 붙잡고 있을 필요는 없다.

특히 ADsP는 비슷하게 느껴지는 용어도 많고, 통계·분석 관련 개념을 처음 접한다면

“이게 도대체 무슨 말이지?”

싶은 부분도 분명히 생긴다.

나 역시 전공자이지만 모든 개념을 완벽하게 이해하면서 공부한 것은 아니다.

이럴 때는 완벽하게 이해하려고 시간을 지나치게 사용하기보다 문제에서 반복되는 핵심 키워드를 개념과 연결해서 암기하는 방식도 적극적으로 활용하는 것을 추천한다.

특정 단어 / 표현
        ↓
관련 개념 연결
        ↓
선지 판단

예를 들어 어떤 개념에 특정 단어나 특징이 반복해서 등장한다면, 그 단어를 보는 순간 관련 개념이 떠오르도록 연결해두는 방식이다.

이 방법의 장점은 크게 세 가지다.

✅ 공부시간을 크게 줄일 수 있다

어려운 개념 하나를 완벽하게 이해하기 위해 지나치게 많은 시간을 소비하지 않아도 된다.

특히 5일처럼 준비기간이 짧다면 이 차이가 정말 크다.

✅ 문제를 빠르게 풀 수 있다

특정 키워드를 보는 순간 관련 개념을 바로 떠올릴 수 있다.

✅ 모르는 문제에서도 선지를 줄일 수 있다

정답을 정확하게 모르더라도

“이 키워드는 이 개념이랑 관련 있었는데?”

        ↓

관련 없는 선지 제거

        ↓

남은 선지에서 판단

처럼 활용할 수 있다.

처음부터 4개 중 하나를 찍는 것과 2개까지 선지를 줄인 뒤 선택하는 것은 확률 자체가 다르다.

그래서 비전공자나 단기간에 ADsP를 준비하는 사람에게 상당히 유용한 방법이라고 생각한다.

물론 무조건 암기만 하라는 뜻은 아니다.

이해할 수 있는 내용은 이해하고, 단기간에 점수를 만들어야 하는 부분에서는 키워드 암기를 적극적으로 활용하자.

자격증 시험에서는 이것도 하나의 전략이라고 생각한다.

4. R·데이터 해석 문제는 생각보다 점수 챙기기 좋다

3과목을 처음 공부하면 가장 부담스러운 부분 중 하나가 R과 데이터 해석 문제다.

처음 보면 코드나 출력 결과가 길게 나오기 때문에

‍ “이걸 내가 어떻게 풀어...?”

라는 생각이 들 수 있다.

생긴 것부터 굉장히 어렵게 느껴진다.

그런데 직접 기출을 반복해서 풀어보니 오히려 점수를 챙기기 좋은 유형이라고 느꼈다.

중요한 건

R을 처음부터 끝까지 전부 공부할 필요가 없다는 것

데이터 해석 문제에서 자주 확인해야 하는 값들은 어느 정도 정해져 있다.

대표적으로,

p-value

계수의 부호
→ 양수 / 음수

R-squared

Adjusted R-squared

유의성 여부

출력 결과의 의미

등이다.

처음에는 표나 R 출력 결과 전체를 모두 이해해야 할 것 같지만, 기출을 반복해서 풀다 보면

“아, 이 유형에서는 여기만 보면 되는구나.”

하는 부분이 보이기 시작한다.

또 데이터 분석 내용을 지나치게 깊게 문제로 만들면 시험 난이도뿐 아니라 필요한 공부량도 크게 증가한다.

그래서 ADsP에서는 복잡한 코드를 직접 작성하는 것보다는 주어진 결과에서 필요한 값을 찾아 해석하는 유형에 익숙해지는 것이 중요하다고 느꼈다.

기출문제 반복
        ↓
어떤 값을 확인하는지 파악
        ↓
해석 방법 익히기
        ↓
비슷한 문제 반복

처음 생김새만 보고 포기하면 오히려 아까운 점수를 버리는 셈이다.

처음 생김새는 무섭지만, 유형에 익숙해지면 의외로 점수를 챙기기 좋은 파트다.

특히 3과목 과락이 걱정된다면 R·데이터 해석 문제를 처음부터 포기하지 않는 것을 추천하고 싶다.

✅ 최종 정리

내 공부 과정과 결과를 다시 정리하면 다음과 같다.

시험       : 제50회 ADsP
시험일     : 2026.08.08
준비기간   : 5일
베이스     : 전공자

사용 자료
→ 아답터 ADsP 요약강의
→ 2026 이지패스 ADsP 미어캣책

공부 방법
→ 요약강의 전체 1회독
→ 미어캣책 개념 1회독
→ 기출 3회분
→ 모의고사 3회분
→ 오답 + 개념 리마인드

기출·모의고사
→ 보통 80점 이상
→ 낮게 나오면 70점대

복원 가채점
→ 보수적으로 약 64점

실제 결과
→ 1과목 16 / 20
→ 2과목 16 / 20
→ 3과목 36 / 60

최종 점수
→ 68점

결과
→ ✅ 합격

이번 50회 시험은 개인적으로 기존 기출이나 모의고사를 풀 때보다 체감 난이도가 훨씬 높은 시험이었다.

시험이 끝난 직후에는

“진짜 떨어질 수도 있겠다.”

라고 생각했지만, 결과적으로는 68점으로 합격할 수 있었다.

이번 시험을 통해 가장 크게 느낀 것은 단순히 기출 답만 반복하는 것보다

요약강의로 전체 흐름 파악
        ↓
기본서로 세부 개념까지 확인
        ↓
기출로 빈출 유형 분석
        ↓
오답으로 부족한 개념 보완

과정을 만드는 것이 중요하다는 것이다.

그리고 개인적으로 ADsP 단기 합격에서 가장 중요하다고 생각하는 전략을 다시 정리하면,

① 3과목 과락을 지나치게 두려워하지 않기

② 1·2과목에서 최대한 점수 확보하기

③ 모든 내용을 100% 이해하려 하지 말고
   핵심 키워드 중심으로 암기하기

④ R·데이터 해석 문제를 처음부터 포기하지 않기

정도다.

특히 50회처럼 지엽적으로 출제되는 시험까지 생각한다면,

아답터 요약강의로 큰 틀을 잡고, 미어캣책의 세부 내용까지 최소 한 번은 읽어보는 것을 추천한다.

5일이라는 짧은 기간으로도 합격할 수 있었지만, 시험장에서 처음 보는 문제를 마주했을 때 결국 도움이 됐던 것은

“이거 책에서 한 번 봤는데?”

라는 기억이었다.

ADsP를 준비하고 있다면 기출 점수가 잘 나온다고 너무 방심하지 말고,

빈출 개념은 확실하게, 세부 개념은 최소한 눈에 익히고, 1·2과목에서 점수를 최대한 확보하는 전략으로 준비해보는 것을 추천한다.

[LG CNS 6기] 17일차 TIL : Spring Boot 아키텍처 이해와 Stream API·Optional·CRUD 실습

bbbicsan — Thu, 20 Aug 2026 19:04:06 +0900

[LG CNS 6기] 17일차 TIL : Spring Boot 아키텍처 이해와 Stream API·Optional·CRUD 실습

한 줄 요약

어제 직접 구현했던 FrontController · BeanFactory · Controller · Service · DAO 구조를 Spring Boot 아키텍처와 연결해 이해하고, Java Stream API와 Optional을 다양한 데이터 처리 문제에 적용한 뒤 전체조회 → 상세조회 → 검색 → 등록으로 Blog CRUD 구조를 확장했다.

오늘 학습한 커리큘럼

Spring Boot 아키텍처
        ↓
요청 처리 흐름
        ↓
Session Facade Pattern
(Front Controller)
        ↓
BeanFactory
(Controller 인스턴스 관리)
        ↓
Post CRUD Controller
        ↓
Stream API 메서드 실습
        ↓
조건 불만족 시 빈 리스트 반환
        ↓
Optional
        ↓
else 처리 개선

오늘은 어제 직접 구현했던 Blog Console 프로그램의 구조를 다시 살펴보면서 시작했다.

어제는 직접:

View
→ FrontController
→ BeanFactory
→ Controller
→ Service
→ DAO

구조를 만들었다면, 오늘은 이를 실제 Spring Boot 기반 웹 애플리케이션의 요청 처리 구조와 연결해서 이해했다.

이후 Java 공식 API 문서를 통해 Stream의 메서드 시그니처를 확인하고, filter, map, collect, groupingBy, average, distinct, anyMatch 등 다양한 메서드를 Blog 데이터에 직접 적용했다.

오후에는 오전에 학습한 Stream과 Optional을 다시 Blog CRUD 구조에 적용하여 상세조회와 검색 기능을 직접 구현하고, Insert 기능까지 확장했다.

오늘의 학습 키워드

Spring Boot Architecture
DispatcherServlet
Front Controller / Session Facade Pattern
BeanFactory
Singleton Pattern
Dependency Injection
Stream API
Predicate
Function
filter()
map()
collect()
Collectors.toList()
Collectors.groupingBy()
mapToInt()
average()
distinct()
sorted()
anyMatch()
allMatch()
noneMatch()
Optional
ifPresentOrElse()
orElse()
orElseThrow()
findAny()
CRUD
Constructor Injection

1. 직접 구현한 구조와 Spring Boot 아키텍처 연결

오늘 수업은 어제 만든 Blog Console 구조를 다시 확인하면서 시작했다.

어제 직접 만든 구조는 다음과 같았다.

BlogReactView
        ↓
BlogFrontController
        ↓
BlogBeanFactory
        ↓
Controller
        ↓
Service
        ↓
DAO

오늘은 이 구조를 실제 웹 애플리케이션 관점에서 다시 연결했다.

Client / React
        ↓
HTTP Request / URL
        ↓
DispatcherServlet
        ↓
Controller
        ↓
Service
        ↓
Repository / DAO
        ↓
DB
        ↓
JSON Response
        ↓
React Rendering

특히 어제 직접 구현했던 BlogFrontController의 역할이 Spring MVC에서는 DispatcherServlet과 같은 Front Controller 구조로 연결된다는 점이 중요했다.

2. 레이어별 책임

강의에서는 웹 애플리케이션을 역할에 따라 계층으로 나누어 설명했다.

Presentation Layer
        ↓
Controller

Business Layer
        ↓
Service

Persistence Layer
        ↓
Repository / DAO

각 계층의 역할을 정리하면 다음과 같다.

Controller
→ 사용자 요청을 받음
→ 요청 데이터 전달
→ 응답 반환

Service
→ 비즈니스 로직 처리

Repository / DAO
→ 데이터 저장 및 조회

어제 만든 콘솔 프로그램에서도 이미 비슷한 구조를 직접 구현했다.

3. BeanFactory와 객체 생성 구조 복습

BlogBeanFactory에서는 객체를 직접 생성하고 서로 필요한 의존성을 연결했다.

dao = new BlogReactDao();

service =
    new BlogReactServiceImpl(
        dao
    );

map.put(
    "list.inspire",
    new ListController(
        service
    )
);

의존성 흐름은:

BlogReactDao
        ↓
BlogReactServiceImpl
        ↓
ListController

형태였다.

또 Factory 생성자를 private으로 선언하고:

public static BlogBeanFactory getInstance() {

    if(instance == null) {

        instance =
            new BlogBeanFactory();
    }

    return instance;
}

를 사용하면서 Singleton 구조도 다시 확인했다.

즉 어제는 Spring 없이 직접:

객체 생성
+
객체 관리
+
Dependency Injection

을 구현했고, 오늘은 이런 작업이 이후 Spring의 객체 관리 구조와 연결된다는 흐름으로 이해했다.

4. Java 공식 문서에서 Stream API 확인

Stream API를 단순히 예제 코드로만 사용하는 것이 아니라 Oracle Java 17 공식 API 문서를 확인하면서 실제 메서드 시그니처를 살펴봤다.

먼저 filter()는:

filter(
    Predicate<? super T> predicate
)

형태였다.

즉 filter()는 Predicate를 전달받는다.

Predicate<T>
        ↓
조건 검사
        ↓
boolean
        ↓
true인 요소만 Stream에 유지

5. filter() - 조건에 맞는 데이터 추출

Blog 데이터 중 조회수가 30 이상인 게시글만 출력했다.

blogs.stream()
    .filter(
        blog ->
            blog.getViewCnt() >= 30
    )
    .forEach(
        blog ->
            System.out.println(blog)
    );

메서드 참조를 사용하면 다음처럼 줄일 수 있다.

blogs.stream()
    .filter(
        blog ->
            blog.getViewCnt() >= 30
    )
    .forEach(
        System.out::println
    );

실행 흐름은:

List<BlogResponseDTO>
        ↓
stream()
        ↓
filter(viewCnt >= 30)
        ↓
조건에 맞는 객체만 통과
        ↓
forEach()
        ↓
출력

이다.

6. map() - 데이터와 타입 변환

공식 API에서 map()은 다음 형태였다.

map(
    Function<? super T, ? extends R> mapper
)

즉 map()은 Function을 전달받아 하나의 값을 다른 값으로 변환한다.

Blog 객체에서 email만 추출해보았다.

blogs.stream()
    .filter(
        blog ->
            blog.getViewCnt() >= 30
    )
    .map(
        BlogResponseDTO::getEmail
    )
    .forEach(
        System.out::println
    );

이 코드에서 Stream 요소의 타입 자체가 변경된다.

Stream<BlogResponseDTO>
        ↓
filter()
        ↓
Stream<BlogResponseDTO>
        ↓
map(BlogResponseDTO::getEmail)
        ↓
Stream<String>
        ↓
forEach()

따라서:

filter()
→ 필요한 요소 선택

map()
→ 필요한 값으로 변환

이라는 차이를 다시 확인할 수 있었다.

7. Stream의 중간 연산과 최종 연산

공식 API를 살펴보면서 limit()도 확인했다.

limit(long maxSize)

limit()은 Stream에서 처리할 요소의 최대 개수를 제한하는 중간 연산이다.

오늘 확인한 메서드를 기준으로 보면:

중간 연산
│
├─ filter()
├─ map()
├─ limit()
├─ distinct()
└─ sorted()

최종 연산
│
├─ collect()
├─ forEach()
├─ average()
├─ anyMatch()
├─ allMatch()
└─ noneMatch()

형태로 볼 수 있다.

8. collect() - Stream 결과를 다시 List로 반환

강사님께서 collect()를 자주 사용하는 최종 연산 메서드라고 강조하셨다.

공식 API의 형태는:

<R, A> R collect(
    Collector<? super T, A, R> collector
)

이다.

이번 실습에서는 email이 "lim"인 게시글만 추출해 List로 반환했다.

List<BlogResponseDTO> result =
    blogs.stream()
        .filter(
            blog ->
                blog.getEmail()
                    .equals("lim")
        )
        .collect(
            Collectors.toList()
        );

result.forEach(
    System.out::println
);

흐름은:

List<BlogResponseDTO>
        ↓
stream()
        ↓
filter(email == "lim")
        ↓
Stream<BlogResponseDTO>
        ↓
collect(Collectors.toList())
        ↓
List<BlogResponseDTO>

이다.

filter()는 타입을 변경하지 않고 조건에 맞는 데이터만 유지하고, collect()에서 Stream의 결과를 실제 Collection으로 다시 반환한다.

9. Collectors.groupingBy() - 작성자별 그룹화

다음으로 email을 기준으로 게시글을 그룹화했다.

Map<String, List<BlogResponseDTO>> map =
    blogs.stream()
        .collect(
            Collectors.groupingBy(
                BlogResponseDTO::getEmail
            )
        );

결과 타입은:

Map<String, List<BlogResponseDTO>>

이다.

구조를 그림으로 보면:

"lim"
→ [
    react 게시글,
    msa 게시글
  ]

"kim"
→ [
    java 게시글
  ]

"lee"
→ [
    spring 게시글
  ]

"park"
→ [
    docker 게시글
  ]

특정 작성자만 다시 가져올 수도 있다.

map.get("lim")
    .stream()
    .forEach(
        System.out::println
    );

실행 결과 "lim"이 작성한 두 게시글이 함께 출력되는 것을 확인했다.

10. 조회수 평균 계산하기

다음 강사님 실습 문제는 다음과 같았다.

Q) 조회수의 평균을 확인하고 싶다면?

이를 위해 객체 Stream을 기본형 Stream으로 변환했다.

double avg =
    blogs.stream()
        .mapToInt(
            BlogResponseDTO::getViewCnt
        )
        .average()
        .orElse(0);

System.out.println(avg);

전체 흐름은:

Stream<BlogResponseDTO>
        ↓
mapToInt(getViewCnt)
        ↓
IntStream
        ↓
average()
        ↓
OptionalDouble
        ↓
orElse(0)
        ↓
double

이다.

average()는 바로 double을 반환하는 것이 아니라 OptionalDouble을 반환한다.

데이터가 존재하지 않을 수도 있기 때문에:

.orElse(0)

으로 값이 없을 때 사용할 기본값을 지정했다.

11. Primitive Stream

평균 계산을 하면서 객체 Stream과 기본형 Stream의 차이도 확인했다.

대표적인 기본형 Stream은:

IntStream
LongStream
DoubleStream

이다.

공식 API에서는:

asDoubleStream()
asLongStream()
average()
boxed()

등의 메서드도 확인했다.

특히 mapToInt()를 사용하면:

Stream<BlogResponseDTO>
        ↓
IntStream

으로 변경할 수 있다.

숫자를 이용한 합계나 평균 같은 계산에서는 기본형 Stream을 활용할 수 있다는 점을 확인했다.

12. distinct() - 중복 이메일 제거

다음 문제는 email만 추출하되 중복된 데이터는 한 번만 출력하는 것이었다.

blogs.stream()
    .map(
        BlogResponseDTO::getEmail
    )
    .distinct()
    .forEach(
        System.out::println
    );

흐름은:

Stream<BlogResponseDTO>
        ↓
map(getEmail)
        ↓
Stream<String>
        ↓
distinct()
        ↓
중복 제거
        ↓
forEach()

이다.

예를 들어 "lim"이라는 email이 여러 게시글에 존재하더라도 출력 결과에서는 한 번만 나타난다.

13. sorted() - 정렬

Stream의 정렬 기능도 확인했다.

blogs.stream()
    .sorted()
    .forEach(
        System.out::println
    );

sorted()는 Stream 요소의 정렬을 담당하는 중간 연산이다.

오늘은 distinct()와 함께 데이터의 중복 제거 및 정렬 관련 Stream 메서드까지 범위를 확장했다.

14. anyMatch / allMatch / noneMatch

이번에는 Stream 안의 데이터가 특정 조건을 만족하는지 boolean으로 확인했다.

anyMatch()

하나라도 조건을 만족하는 데이터가 있는지 확인한다.

boolean isEmail =
    blogs.stream()
        .anyMatch(
            blog ->
                blog.getEmail()
                    .equals("jslim")
        );

하나라도 만족
→ true

allMatch()

모든 데이터가 조건을 만족하는지 확인한다.

boolean isExists =
    blogs.stream()
        .allMatch(
            blog ->
                blog.getViewCnt() >= 20
        );

모든 데이터 만족
→ true

noneMatch()

조건을 만족하는 데이터가 하나도 없는지 확인한다.

boolean isUnder =
    blogs.stream()
        .noneMatch(
            blog ->
                blog.getViewCnt() < 10
        );

조건을 만족하는 데이터가 하나도 없음
→ true

세 메서드를 비교하면:

anyMatch()
→ 하나라도 만족?

allMatch()
→ 전부 만족?

noneMatch()
→ 하나도 만족하지 않음?

으로 정리할 수 있다.

15. Optional이 필요한 이유

Stream 실습 이후 Optional을 본격적으로 학습했다.

Optional은 주로 메서드의 반환값이 존재할 수도 있고 존재하지 않을 수도 있는 상황을 표현할 때 사용할 수 있다.

메서드 호출
    ↓
반환값 존재 여부 불확실
    ↓
Optional<T>

기존에 객체가 없을 때 null을 직접 반환하면:

result.method();

과 같이 사용할 때 NullPointerException이 발생할 위험이 있다.

Optional을 이용하면 값의 존재 여부를 명시적으로 표현할 수 있다.

수업에서는 Optional을 모든 곳에 사용하는 것이 아니라 용도에 맞게 사용해야 하며, 특히 메서드 반환값에서 활용하는 방향을 확인했다.

16. Optional.of()

값이 존재하는 Optional은 다음과 같이 만들었다.

Optional<String> optional =
    Optional.of("lgcns");

기존 방식으로는:

if(optional.isPresent()) {

    System.out.println(
        optional.get()
    );

} else {

    // 값이 없는 경우
}

처럼 값을 확인할 수도 있다.

17. ifPresentOrElse()

Java 9 이후 사용할 수 있는 ifPresentOrElse()도 실습했다.

optional.ifPresentOrElse(

    value ->
        System.out.println(
            value
        ),

    () ->
        System.out.println(
            "값이 없습니다."
        )
);

흐름은:

Optional
    ↓
값 있음?
│
├─ YES
│   ↓
│ value -> ...
│
└─ NO
    ↓
  () -> ...

이다.

기존의:

if
→ 값 존재

else
→ 값 없음

구조를 Optional API 내부에서 처리할 수 있었다.

18. Optional.empty()와 orElseThrow()

값이 없는 Optional도 직접 만들었다.

optional =
    Optional.empty();

이후:

String err =
    optional.orElseThrow(
        () ->
            new RuntimeException(
                "값이 없습니다."
            )
    );

를 실행했다.

실행 결과:

Exception in thread "main"
java.lang.RuntimeException:
값이 없습니다.

가 발생했다.

Stack Trace에서도:

Optional.orElseThrow(...)
        ↓
BlogStreamApp.main(...)

순서로 예외가 발생한 것을 확인했다.

Optional 관련 메서드를 정리하면:

Optional.of(value)
→ 값이 있는 Optional

Optional.empty()
→ 빈 Optional

ifPresentOrElse()
→ 값 있음 / 없음 분기

orElse(defaultValue)
→ 없으면 기본값 반환

orElseThrow()
→ 없으면 Exception 발생

이다.

19. Stream API 실습 전체 정리

오늘 실습한 Stream API를 목적별로 정리하면 다음과 같다.

조건 검색
→ filter()

값 변환
→ map()

개수 제한
→ limit()

Collection 반환
→ collect()

그룹화
→ groupingBy()

숫자 Stream 변환
→ mapToInt()

평균
→ average()

기본값 처리
→ orElse()

중복 제거
→ distinct()

정렬
→ sorted()

하나라도 만족
→ anyMatch()

모두 만족
→ allMatch()

아무것도 만족하지 않음
→ noneMatch()

각 메서드를 따로 외우는 것보다:

조회
→ 조건 검색
→ 변환
→ 수집
→ 집계
→ 조건 판단

처럼 데이터 처리 과정으로 이해하는 것이 중요했다.

20. Blog CRUD - 상세조회 기능 구현

오후에는 오전에 배운 Stream과 Optional을 기존 Blog 프로젝트에 다시 적용했다.

전체조회 다음으로 상세조회 기능을 구현했다.

View에서는 사용자의 blogId를 입력받았다.

public void read() {

    System.out.println();
    System.out.println(
        ">>>> 상세페이지 정보"
    );

    String endPoint =
        "read.inspire";

    System.out.print(
        "키(blogId) 입력 : "
    );

    int blogId =
        Integer.parseInt(
            scan.nextLine()
        );

    BlogResponseDTO response =
        front.read(
            endPoint,
            blogId
        );

    System.out.println(
        (response != null)
            ? response
            : "정보없음"
    );
}

흐름은:

사용자
   ↓
blogId 입력
   ↓
BlogReactView.read()
   ↓
BlogFrontController.read()

이다.

21. ReadController와 Service 연결

ReadController는 BlogReactService를 생성자 주입받는다.

private BlogReactService service;

public ReadController(
        BlogReactService service) {

    this.service =
        service;
}

Controller에서는 실제 데이터 조회를 직접 하지 않고 Service에 위임했다.

public BlogResponseDTO read(
        int blogId) {

    System.out.println(
        "debug >>>> read controller read params : "
        + blogId
    );

    return service.read(
        blogId
    );
}

즉:

ReadController
     ↓
Service

구조로 책임을 분리했다.

22. DAO에서 Stream으로 단건 검색

BlogReactDao.findById()에서는 오늘 배운 Stream API를 실제 상세조회에 활용했다.

public Optional<BlogResponseDTO>
        findById(int blogId) {

    System.out.println(
        "debug >>>> blog dao findById() params : "
        + blogId
    );

    return blogs.stream()
        .filter(
            blog ->
                blog.getBlogId()
                    == blogId
        )
        .findAny();
}

흐름은:

List<BlogResponseDTO>
        ↓
stream()
        ↓
filter(blogId 일치)
        ↓
findAny()
        ↓
Optional<BlogResponseDTO>

이다.

오전에 따로 학습했던 filter()와 Optional이 실제 DAO의 단건 조회 로직으로 연결되었다.

23. Optional 처리 방식 비교

DAO의 findById()는 Optional<BlogResponseDTO>를 반환한다.

Service에서는 이를 여러 방식으로 처리해봤다.

Case 01 - orElse(null)

return dao.findById(blogId)
    .orElse(null);

값 있음
→ BlogResponseDTO

값 없음
→ null

Case 02 - isPresent() + get()

Optional<BlogResponseDTO> result =
    dao.findById(blogId);

if(result.isPresent()) {

    return result.get();
}

return null;

동일한 동작을 직접 조건문으로 구현한 방식이다.

Case 03 - orElseThrow()

return dao.findById(blogId)
    .orElseThrow(
        () ->
            new RuntimeException(
                blogId
                + " 정보를 찾을 수 없습니다."
            )
    );

이번에는 데이터가 없을 때 null 대신 Exception을 발생시켰다.

정리하면:

orElse(null)
→ 없으면 null

isPresent() + get()
→ 존재 여부를 직접 확인

orElseThrow()
→ 없으면 Exception

이다.

Optional을 단순 예제로 끝내지 않고 실제 단건 조회 결과 처리에 적용했다는 점이 중요했다.

24. 상세조회 전체 요청 흐름

상세조회 기능의 전체 구조는 다음과 같다.

BlogReactView
      ↓
blogId 입력
      ↓
BlogFrontController
      ↓
BlogBeanFactory
      ↓
ReadController
      ↓
BlogReactService
      ↓
BlogReactServiceImpl
      ↓
BlogReactDao.findById()
      ↓
Stream.filter()
      ↓
findAny()
      ↓
Optional<BlogResponseDTO>
      ↓
Service에서 Optional 처리
      ↓
응답 반환

어제 전체조회 기능에서 구현한 계층 구조가 상세조회 기능까지 확장됐다.

25. 강사님 실습 문제 - Keyword 검색 구현

다음으로 강사님께서 직접 구현해보라고 다음 문제를 주셨다.

Q)
blog content 내용 중 해당 키워드를 포함하는 것들을
검색해서 가져와 본다면?

구현해야 할 단계도 함께 정리했다.

1. FrontController search() 정의

2. SearchController 클래스 정의

3. BeanFactory에
   "search.inspire" 등록

4. BlogReactServiceImpl에
   search() 정의

5. Service에서
   dao.findByKeyword() 호출

6. BlogReactDao에
   findByKeyword() 구현

기존 코드를 참고하면서 각 계층을 직접 연결하는 실습이었다.

26. View에서 검색 Keyword 입력

View에서는 검색 endpoint를 지정하고 사용자의 검색어를 입력받았다.

public void search() {

    System.out.println();
    System.out.println(
        ">>>> 검색페이지 정보"
    );

    String endPoint =
        "search.inspire";

    System.out.print(
        "키워드 입력 : "
    );

    String keyword =
        scan.nextLine();

    List<BlogResponseDTO> response =
        front.search(
            endPoint,
            keyword
        );

    response.stream()
        .forEach(
            System.out::println
        );
}

즉:

사용자 keyword 입력
        ↓
"search.inspire"
        ↓
FrontController

로 요청을 전달했다.

27. SearchController 구현

SearchController에서도 Service를 생성자 주입받았다.

private BlogReactService service;

public SearchController(
        BlogReactService service) {

    this.service =
        service;
}

View에서 전달된 String keyword는 Service에 바로 전달하지 않고 BlogRequestDTO로 변환했다.

public List<BlogResponseDTO> search(
        String keyword) {

    System.out.println(
        "debug >>>> search controller search params : "
        + keyword
    );

    return service.search(
        BlogRequestDTO.builder()
            .keyword(
                keyword
            )
            .build()
    );
}

데이터 흐름은:

View
→ String keyword

Controller
→ BlogRequestDTO

Service
→ BlogRequestDTO

DAO
→ request.getKeyword()

형태가 된다.

28. Factory에 SearchController 등록

Factory에도 새로운 endpoint를 추가했다.

map.put(
    "list.inspire",
    new ListController(
        service
    )
);

map.put(
    "read.inspire",
    new ReadController(
        service
    )
);

map.put(
    "search.inspire",
    new SearchController(
        service
    )
);

endpoint와 Controller의 관계는:

list.inspire
→ ListController

read.inspire
→ ReadController

search.inspire
→ SearchController

로 확장됐다.

29. Stream filter()를 이용한 실제 검색 구현

DAO에서는 입력받은 keyword를 이용해 데이터를 필터링했다.

public List<BlogResponseDTO>
        findByKeyword(
            BlogRequestDTO request) {

    System.out.println(
        "debug >>>> blog dao findByKeyword params : "
        + request
    );

    return blogs.stream()
        .filter(
            blog ->
                blog.getTitle()
                    .contains(
                        request.getKeyword()
                    )
                ||
                blog.getContent()
                    .contains(
                        request.getKeyword()
                    )
        )
        .toList();
}

강사님 문제에서는 content 검색을 중심으로 제시됐지만, 실제 구현에서는 조건을 확장해:

title에 keyword 포함
OR
content에 keyword 포함

인 게시글을 반환하도록 만들었다.

즉 오전에 학습한:

filter(Predicate)

가 실제 DAO에서:

title.contains(keyword)
        OR
content.contains(keyword)

이라는 검색 조건으로 사용됐다.

30. 검색 기능 실행 결과

BlogFrontController.search()의 최종 구현은 다음과 같이 Controller에 요청을 위임했다.

public List<BlogResponseDTO> search(
        String endPoint,
        String keyword) {

    System.out.println(
        "debug >>>> front controller endPoint : "
        + endPoint
        + ", keyword : "
        + keyword
    );

    Object controller =
        factory.getBean(
            endPoint
        );

    return (
        (SearchController) controller
    ).search(keyword);
}

실제로 검색 키워드로:

oop

를 입력했다.

Console에서는:

front controller
        ↓
search controller
        ↓
blog service search
        ↓
blog dao findByKeyword

순서로 로그가 출력됐다.

그리고 다음 데이터가 조회됐다.

title   = java
content = oop
email   = kim
viewCnt = 20

즉 직접 구현한 검색 기능이 전체 계층을 거쳐 정상적으로 동작하는 것을 확인했다.

31. Insert 기능 구현 시작

검색 기능 이후에는 게시글 등록 기능으로 넘어갔다.

InsertController 역시 Service를 생성자 주입받았다.

private BlogReactService service;

public InsertController(
        BlogReactService service) {

    this.service =
        service;
}

등록할 때는 여러 값이 필요했다.

title
content
email

이를 각각 Service에 전달하기보다 하나의 RequestDTO로 바인딩했다.

public int insert(
        String title,
        String content,
        String email) {

    System.out.println(
        "debug >>>> insert controller insert params : "
        + title
        + "\t"
        + content
        + "\t"
        + email
    );

    return service.insert(
        BlogRequestDTO.builder()
            .title(title)
            .content(content)
            .email(email)
            .build()
    );
}

강의에서는 이 부분에서:

여러 파라미터
        ↓
하나의 객체로 Binding
        ↓
RequestDTO
        ↓
유효성 검사

의 필요성을 강조했다.

32. Service에서 Insert 요청 DAO로 위임

Service에서는 Controller에서 전달받은 RequestDTO를 DAO로 넘긴다.

@Override
public int insert(
        BlogRequestDTO request) {

    System.out.println(
        "debug >>>> blog service insert params : "
        + request
    );

    return dao.save(
        request
    );
}

구조는 기존 기능들과 동일하다.

InsertController
        ↓
BlogReactServiceImpl
        ↓
BlogReactDao.save()

오늘 화면에서는 dao.save()까지 연결하는 단계가 진행됐으며, 실제 저장 메서드의 최종 구현과 실행 결과까지는 확인하지 않았다.

33. FrontController에 Insert 추가

FrontController에도 Insert 요청을 처리하는 메서드를 추가했다.

public int insert(
        String endPoint,
        String title,
        String content,
        String email) {

    System.out.println(
        "debug >>>> front controller endPoint : "
        + endPoint
    );

    Object controller =
        factory.getBean(
            endPoint
        );

    return (
        (InsertController) controller
    ).insert(
        title,
        content,
        email
    );
}

이제 기존:

list()
read()
search()

에서:

insert()

까지 Controller 구조가 확장되기 시작했다.

34. RequestDTO 변환 메서드

BlogRequestDTO에는 현재 다음과 같은 데이터가 들어 있다.

title
content
email
keyword

그리고 객체 변환용 정적 메서드도 작성했다.

public static BlogResponseDTO toEntity(
        BlogRequestDTO request) {

    return BlogResponseDTO.builder()
        .title(
            request.getTitle()
        )
        .content(
            request.getContent()
        )
        .email(
            request.getEmail()
        )
        .build();
}

강의에서는 JPA 환경에서 DTO를 Entity로 변환할 때 정적 메서드를 이용한 변환 패턴을 사용할 수 있다는 내용과 연결했다.

현재 콘솔 실습 코드에서는 메서드 이름이 toEntity()이지만 실제 반환 타입은 BlogResponseDTO이므로, 실제 JPA Entity 변환과는 구분해서 이해했다.

실습 기록

1. Stream filter 조건 검색

blogs.stream()
    .filter(
        blog ->
            blog.getViewCnt() >= 30
    )
    .forEach(
        System.out::println
    );

Stream
→ 조회수 30 이상 필터링
→ 해당 DTO만 출력

2. map()으로 email만 추출

blogs.stream()
    .filter(
        blog ->
            blog.getViewCnt() >= 30
    )
    .map(
        BlogResponseDTO::getEmail
    )
    .forEach(
        System.out::println
    );

BlogResponseDTO
→ email
→ String

객체 Stream의 타입이 String Stream으로 변경되는 것을 확인했다.

3. email이 lim인 데이터 List 반환

List<BlogResponseDTO> result =
    blogs.stream()
        .filter(
            blog ->
                blog.getEmail()
                    .equals("lim")
        )
        .collect(
            Collectors.toList()
        );

filter()
→ 조건 검색

collect()
→ List 반환

4. 작성자별 groupingBy()

Map<String, List<BlogResponseDTO>> map =
    blogs.stream()
        .collect(
            Collectors.groupingBy(
                BlogResponseDTO::getEmail
            )
        );

lim 작성자의 게시글 두 개가 동일 그룹으로 묶이는 것을 확인했다.

5. 조회수 평균 계산

강사님이 제시한:

Q) 조회수의 평균을 확인하고 싶다면?

문제를 다음과 같이 해결했다.

double avg =
    blogs.stream()
        .mapToInt(
            BlogResponseDTO::getViewCnt
        )
        .average()
        .orElse(0);

객체 Stream을 IntStream으로 변환한 뒤 평균을 구하고, 데이터가 없을 경우 0을 반환하도록 처리했다.

6. email 중복 제거

blogs.stream()
    .map(
        BlogResponseDTO::getEmail
    )
    .distinct()
    .forEach(
        System.out::println
    );

중복된 "lim" email이 한 번만 출력되는 것을 확인했다.

7. Stream Match 실습

anyMatch()
→ 하나라도 조건 만족?

allMatch()
→ 모두 조건 만족?

noneMatch()
→ 하나도 조건 만족하지 않음?

조건 검사의 결과가 모두 boolean으로 반환된다는 것을 확인했다.

8. Optional ifPresentOrElse()

optional.ifPresentOrElse(

    value ->
        System.out.println(value),

    () ->
        System.out.println(
            "값이 없습니다."
        )
);

Optional 값의 존재 여부에 따른 분기를 if / else 없이 처리했다.

9. Optional.empty() + orElseThrow()

optional =
    Optional.empty();

String err =
    optional.orElseThrow(
        () ->
            new RuntimeException(
                "값이 없습니다."
            )
    );

실행 결과:

java.lang.RuntimeException:
값이 없습니다.

가 발생하는 것을 확인했다.

10. DAO 상세조회에 Stream + Optional 적용

return blogs.stream()
    .filter(
        blog ->
            blog.getBlogId()
                == blogId
    )
    .findAny();

수업 초반 별도 예제로 학습했던:

filter()
+
Optional

이 실제 CRUD 조회 기능으로 연결됐다.

11. 강사님 검색 기능 구현 문제

Q)
blog content 내용 중
해당 키워드를 포함하는 게시글을
검색해서 가져와 본다면?

구현 흐름:

View
→ FrontController
→ SearchController
→ Service
→ DAO
→ Stream.filter()
→ List 반환

실제로 oop를 검색하여 content=oop인 게시글이 반환되는 것까지 확인했다.

문제 해결 과정

문제 1. Search FrontController 구현 중 ReadController 코드가 남아있음

증상

검색 기능을 구현하기 위해 BlogFrontController.search()를 추가하는 과정에서 상세조회 메서드의 코드를 복사한 흔적이 남아 있었다.

중간 코드에는:

return ((ReadController) controller)
    .read(blogId);

형태가 남아 있었고, 검색 메서드에는 존재하지 않는 blogId가 사용되면서 Error가 발생했다.

원인

상세조회 read() 구조를 기준으로 검색 메서드를 작성하면서:

ReadController
blogId
read()

부분을 검색 기능에 맞게 변경하지 않은 상태였다.

검색 기능에 필요한 것은:

SearchController
keyword
search()

였다.

수정

검색 endpoint에서 반환된 Controller를 SearchController로 Casting하고 keyword를 전달하도록 수정했다.

public List<BlogResponseDTO> search(
        String endPoint,
        String keyword) {

    Object controller =
        factory.getBean(
            endPoint
        );

    return (
        (SearchController) controller
    ).search(keyword);
}

검증

검색 키워드:

oop

를 입력했다.

Console에서는:

front controller
→ search controller
→ blog service search
→ blog dao findByKeyword

순서로 호출 로그가 정상 출력됐다.

최종 결과:

title=java
content=oop
email=kim
viewCnt=20

이 반환되는 것을 확인했다.

단순히 컴파일 오류만 수정한 것이 아니라 View → Controller → Service → DAO 전체 흐름이 정상적으로 연결됐는지 실행 결과까지 검증했다.

✨ 오늘 배운 내용 정리

오늘 가장 중요했던 것은 Stream과 Optional의 메서드를 많이 외운 것이 아니라, 각 문법이 실제 애플리케이션의 데이터 처리 코드에서 어떻게 사용되는지 연결해서 확인한 것이었다.

오전에는 다음과 같이 각각의 Stream API를 직접 실습했다.

filter()
→ 조건 검색

map()
→ 데이터 변환

collect()
→ Collection 반환

groupingBy()
→ 데이터 그룹화

mapToInt()
→ 숫자 Stream 변환

average()
→ 평균

distinct()
→ 중복 제거

anyMatch()
→ 하나라도 만족

allMatch()
→ 모두 만족

noneMatch()
→ 모두 불만족 여부 확인

그리고 오후에는 이 메서드들이 실제 DAO에서 그대로 사용됐다.

BlogReactDao.findById()
        ↓
stream()
        ↓
filter()
        ↓
findAny()
        ↓
Optional<BlogResponseDTO>

검색에서도:

BlogReactDao.findByKeyword()
        ↓
stream()
        ↓
filter()
        ↓
contains(keyword)
        ↓
toList()

형태로 사용됐다.

즉 오전에 학습한 Stream API가 단순 문법 실습에서 끝난 것이 아니라 Repository / DAO에서 실제 데이터를 조회하는 코드로 그대로 연결되었다.

Optional도 마찬가지였다.

처음에는:

Optional<String>

을 가지고:

ifPresentOrElse()
orElse()
orElseThrow()

를 연습했지만, 이후에는 실제 상세조회에서:

findById(blogId)
→ Optional<BlogResponseDTO>

형태로 사용됐다.

이 과정에서 단건 조회는 데이터가 반드시 존재한다고 보장할 수 없기 때문에 Optional을 사용하는 이유도 더 명확하게 이해할 수 있었다.

또 어제 직접 만든:

View
→ FrontController
→ BeanFactory
→ Controller
→ Service
→ DAO

구조가 오늘:

DispatcherServlet
→ Controller
→ Service
→ Repository

라는 Spring Boot 아키텍처와 연결되는 것도 중요했다.

Spring이 객체 생성이나 의존성 주입을 자동으로 처리하기 전에 직접 Factory와 Constructor Injection을 구현해본 덕분에 각 객체가 어떤 관계를 가지는지도 조금 더 명확하게 볼 수 있었다.

오늘의 회고

오늘은 Stream API와 Optional을 집중적으로 학습했지만, 가장 의미 있었던 부분은 각각의 문법을 실제 CRUD 코드까지 연결해본 것이었다.

처음 filter(), map(), collect()를 배울 때는 단순히 Collection 데이터를 편리하게 처리하는 문법처럼 보였다.

하지만 Blog 프로젝트의 DAO에서:

blogs.stream()
    .filter(...)
    .findAny();

를 이용해 실제 게시글을 조회하고,

blogs.stream()
    .filter(...)
    .toList();

를 이용해 검색 결과를 반환하면서 Stream이 실제 데이터 접근 로직에서도 자연스럽게 사용될 수 있다는 것을 확인했다.

특히 오전에 학습한 Optional이 오후 상세조회에서 바로 연결된 것이 기억에 남았다.

findById()
→ 데이터가 존재할 수도 있음
→ 존재하지 않을 수도 있음
→ Optional

이라는 흐름을 직접 구현해보니 Optional을 왜 사용하는지 단순 정의보다 훨씬 이해하기 쉬웠다.

orElse(null), isPresent() + get(), orElseThrow() 세 가지 방식을 비교한 것도 도움이 됐다.

null로 반환할 것인가?

직접 존재 여부를 확인할 것인가?

데이터가 없다면 Exception으로 처리할 것인가?

처럼 같은 조회 결과라도 이후 프로그램이 어떻게 처리할지에 따라 구현 방식이 달라질 수 있다는 것을 알게 됐다.

오늘 가장 실습다운 부분은 강사님께서 직접 풀어보라고 주신 검색 기능이었다.

Q)
blog content에 keyword가 포함된
게시글을 검색한다면?

라는 요구사항에서 시작해서:

View
→ FrontController
→ SearchController
→ Service
→ DAO

각 계층에 필요한 코드를 직접 추가했다.

구현 중에는 FrontController.search()에 기존 ReadController 코드가 남아 있어 오류도 발생했지만, 검색 요청에 맞게 SearchController와 keyword로 수정하고 실제 실행 로그를 확인하면서 해결할 수 있었다.

특히:

front controller
→ search controller
→ blog service
→ blog dao

로그가 순서대로 출력되고 content=oop인 데이터가 실제 조회되는 것을 확인하면서, 단순히 코드를 작성한 것보다 요청이 각 레이어를 제대로 통과하는지 검증하는 과정이 중요하다는 것을 다시 느꼈다.

등록 기능에서는 여러 개의 파라미터를:

title
content
email

처럼 계속 전달하는 대신:

BlogRequestDTO

하나로 묶어 Service에 전달하는 구조도 확인했다.

앞으로 Spring Boot를 본격적으로 사용하게 되면 오늘 직접 구현했던:

FrontController
BeanFactory
Constructor Injection
RequestDTO
Controller
Service
DAO

구조가 실제 Spring에서는 어떤 Annotation과 기능으로 대체되는지 비교해서 학습하면 이해가 더 잘 될 것 같다.

다시 복습할 부분은 Stream의 중간 연산과 최종 연산 구분, map() 사용 전후의 Stream 타입 변화, Optional의 각 처리 방식, 그리고 Controller → Service → DAO 계층에서 데이터와 책임이 어디까지 전달되는지이다.

특히 오늘처럼 새로운 기능을 구현할 때 단순히 메서드 하나만 만드는 것이 아니라:

요청은 어디서 시작되는가?
        ↓
어떤 Controller가 받아야 하는가?
        ↓
Service에는 어떤 형태로 전달할 것인가?
        ↓
DAO에서는 어떤 Stream 연산이 필요한가?
        ↓
결과는 어떤 타입으로 반환할 것인가?

까지 전체 흐름을 먼저 생각하는 습관을 들여야겠다.

[LG CNS 6기] 16일차 TIL : Java 예외 처리와 MVC·Factory·DI 실습

bbbicsan — Wed, 19 Aug 2026 18:13:04 +0900

[LG CNS 6기] 16일차 TIL : Java 예외 처리와 MVC·Factory·DI 실습

한 줄 요약

Java의 예외 처리 구조와 throw / throws, 사용자 정의 Exception을 학습하고, 콘솔 Blog 프로그램을 직접 구현하며 View → FrontController → Controller → Service → DAO로 이어지는 계층 구조와 Singleton·Factory·Dependency Injection의 흐름을 연결했다.

오늘 학습한 커리큘럼

전날 내용 복습
│
├─ Collection API
│  ├─ List
│  ├─ Set
│  └─ Map
│
├─ Generics
│  └─ <? extends PersonDTO>
│
├─ Stream API
│  ├─ filter()
│  ├─ map()
│  └─ forEach()
│
▼
Exception Handling
│
├─ Runtime Exception
├─ Checked Exception
├─ try - catch - finally
├─ throw / throws
├─ 사용자 정의 Exception
└─ BufferedReader / IOException
│
▼
웹 애플리케이션 구조
│
├─ Servlet
├─ MVC
├─ Controller
├─ Service
├─ DAO / Repository
└─ ORM → DB
│
▼
Blog Console 실습
│
├─ View
├─ FrontController
├─ BeanFactory
├─ Controller
├─ Service
├─ DAO
├─ Singleton Pattern
├─ Factory Pattern
└─ Dependency Injection

오늘은 전날 배운 Collection·Generics·Stream API를 간단히 복습한 뒤 Exception Handling을 학습했다.

이후에는 지금까지 배웠던 객체지향, 인터페이스, 다형성, Collection, Stream API를 하나의 프로그램 안에서 활용하기 위해 콘솔 기반 Blog 프로그램을 만들었다.

단순히 클래스를 여러 개 만드는 것이 아니라, 최종적으로는 사용자 요청이

View
→ FrontController
→ Controller
→ Service
→ DAO

순서로 전달되고 다시 조회 결과가 View까지 반환되는 흐름을 직접 구현하고 실행 로그로 확인했다.

오늘의 학습 키워드

Java Exception Handling
Runtime Exception
Checked Exception
try - catch - finally
printStackTrace()
BufferedReader
InputStreamReader
IOException
사용자 정의 Exception
throw
throws
MVC
Front Controller
Singleton Pattern
Factory Pattern
Dependency Injection
Constructor Injection
Service Interface / Implementation
DAO / Repository
Map<String, Object>
Stream API와 메서드 참조

1. Collection · Generics · Stream API 복습

수업 초반에는 전날 학습했던 Collection API와 Generics, Stream API를 다시 확인했다.

Collection의 대표적인 구조는 다음과 같다.

Collection API
│
├─ List
│  ├─ 중복 허용
│  ├─ 순서 존재
│  └─ index를 이용한 접근
│
├─ Set
│  ├─ 중복 허용 X
│  └─ 순서 보장 X
│
└─ Map
   └─ { key : value }

Generics의 타입 문자도 다시 정리했다.

T → Type
E → Element
K → Key
V → Value
N → Number

Generics를 사용하면 Collection의 요소 타입을 컴파일 시점부터 제한할 수 있다.

List<String> list = new ArrayList<String>();

list.add("String");

// generic 문법에 의한 error
// list.add(10);
// list.add(true);

즉,

Generics
→ 컴파일 시점 타입 안정성
→ 잘못된 타입 저장 방지
→ 불필요한 Casting 감소

라는 장점이 있다.

2. Wildcard를 이용한 여러 하위 타입 관리

StudentDTO, TeacherDTO, ManagerDTO처럼 PersonDTO를 상속한 객체들을 각각 List로 만들고 하나의 Map에 저장했다.

List<StudentDTO> studentList =
    new ArrayList<StudentDTO>();

List<TeacherDTO> teacherList =
    new ArrayList<TeacherDTO>();

List<ManagerDTO> managerList =
    new ArrayList<ManagerDTO>();

Map<String, List<? extends PersonDTO>> map =
    new HashMap<>();

Map에는 다음처럼 저장했다.

map.put("student", studentList);
map.put("teacher", teacherList);
map.put("manager", managerList);

Value 타입을

List<? extends PersonDTO>

로 선언했기 때문에 PersonDTO의 하위 타입을 담고 있는 여러 List를 하나의 Map에서 관리할 수 있었다.

이 부분은 이전에 학습한 상속 + Generics가 실제 자료구조와 연결되는 예제였다.

3. Collection에서 Stream까지 연결하기

전날 사용했던 Stream API도 다시 확인했다.

List<String> filteringList =
    personList.stream()
        .filter(
            s -> s.getName()
                  .startsWith("j")
        )
        .map(
            s -> s.getName()
                  .toUpperCase()
        )
        .collect(
            Collectors.toList()
        );

명령형 코드에서는 반복문과 조건문을 직접 작성했다.

for(int idx = 0;
    idx < personList.size();
    idx++) {

    PersonDTO person =
        personList.get(idx);

    if(
        person.getName()
              .startsWith("j")
    ) {

        filteringList.add(
            person.getName()
                  .toUpperCase()
        );
    }
}

Stream에서는 이를 다음처럼 연결할 수 있었다.

Collection
    ↓
stream()
    ↓
filter()
    ↓
map()
    ↓
collect()

오늘 오후 Blog 실습에서도 조회 결과를 출력할 때 다시 Stream API를 사용하게 되었다.

4. Exception Handling

오늘 오전의 핵심 내용은 Exception Handling이었다.

프로그램 실행 중 문제가 발생했을 때 무조건 프로그램을 종료시키는 것이 아니라, 예외 상황을 처리하여 이후 프로그램의 흐름을 제어할 수 있다.

수업에서는 크게 다음과 같이 구분해서 확인했다.

Exception
│
├─ Runtime
│  └─ 실행 중 발생
│
└─ Compile 시점에 처리를 요구하는 예외
   └─ IOException 등

예외 처리의 기본 구조는 다음과 같다.

try {

    // 예외가 발생할 수 있는 코드

} catch(Exception e) {

    // 예외가 발생했을 때 처리

} finally {

    // 예외 발생 여부와 관계없이 실행
}

5. Runtime Exception 직접 발생시키기

배열에 존재하지 않는 인덱스까지 접근하도록 코드를 작성하여 Runtime Exception을 직접 확인했다.

String[] strAry = {
    "jslim",
    "inspire",
    "lgcns"
};

try {

    for(int idx = 0;
        idx <= strAry.length;
        idx++) {

        System.out.println(
            strAry[idx]
        );
    }

} catch(ArrayIndexOutOfBoundsException e) {

    e.printStackTrace();
}

배열의 길이는 3이지만 사용할 수 있는 index는 다음과 같다.

0
1
2

그런데 반복문 조건을:

idx <= strAry.length

로 만들었기 때문에 마지막에는 다음 접근이 발생한다.

strAry[3]

결국:

ArrayIndexOutOfBoundsException

이 발생한다.

6. try - catch - finally의 실행 흐름

catch는 Exception이 실제로 발생했을 때 수행되고, finally는 Exception 발생 여부와 관계없이 수행된다.

try {

    // 예외 발생 가능 코드

} catch(Exception e) {

    System.out.println(
        "debug >>>> catch 예외발생시에만 수행"
    );

    e.printStackTrace();

} finally {

    System.out.println(
        "debug >>>> finally 예외발생 여부와 상관없이 수행"
    );
}

실행 흐름은 다음과 같다.

try 시작
   ↓
Exception 발생
   ↓
catch 실행
   ↓
finally 실행
   ↓
다음 코드 실행

Exception이 발생하지 않아도:

try
 ↓
정상 수행
 ↓
finally

가 된다.

수업에서는 JDBC Connection과도 연결해서 설명했다.

Connection
     ↓
try
     ↓
DB 작업
     ↓
catch
     ↓
예외 처리
     ↓
finally
     ↓
close()

즉 반드시 정리해야 하는 자원을 처리할 때 finally가 중요하다.

7. printStackTrace()로 예외 추적하기

예외가 발생했을 때 다음 코드를 사용했다.

e.printStackTrace();

printStackTrace()를 통해 단순히 Exception의 이름만 확인하는 것이 아니라 어떤 메서드를 거쳐 어느 코드에서 Exception이 발생했는지 확인할 수 있다.

main()
   ↓
메서드 호출
   ↓
다른 메서드 호출
   ↓
Exception 발생

실제 오후 Blog 실습에서 NumberFormatException이 발생했을 때도 Stack Trace를 통해:

Integer.parseInt(...)
        ↓
BlogReactView.landingPage(...)
        ↓
BlogReactApp.main(...)

라는 호출 흐름을 확인할 수 있었다.

8. InputStream과 BufferedReader

입력 처리에서는 BufferedReader도 사용했다.

BufferedReader br =
    new BufferedReader(
        new InputStreamReader(
            System.in
        )
    );

입력 흐름을 정리하면:

System.in
    ↓
InputStreamReader
    ↓
BufferedReader
    ↓
readLine()
    ↓
String

System.in은 표준 입력 Stream이고, InputStreamReader를 거쳐 문자 단위로 처리할 수 있도록 만든 뒤 BufferedReader로 입력을 받았다.

9. IOException 처리

BufferedReader.readLine()에서는 IOException을 처리해야 했다.

String line = null;

try {

    System.out.print(
        "메시지를 입력하세요 : "
    );

    line =
        br.readLine();

} catch(IOException e) {

    e.printStackTrace();
}

System.out.println(line);

Runtime Exception 예제와 달리 IOException은 컴파일 단계에서 예외 처리 여부를 확인한다는 차이가 있었다.

이 부분을 통해 예외의 종류에 따라 처리 방식이 다를 수 있다는 점을 확인했다.

10. 사용자 정의 Exception 만들기

Java가 기본적으로 제공하는 Exception 외에 직접 예외 클래스를 만들 수도 있다.

오늘은 InspireException을 만들었다.

public class InspireException
        extends Exception {

    public InspireException() {
    }

    public InspireException(
            String msg) {

        super(msg);
    }
}

Exception 클래스를 상속받고, 메시지를 전달받는 생성자에서는:

super(msg);

를 이용해 부모 Exception에 메시지를 전달했다.

11. throw와 throws의 차이

사용자 정의 Exception을 직접 발생시키면서 throw와 throws의 차이를 확인했다.

public void first(int x)
        throws InspireException {

    System.out.println(
        "debug >>>> first method start"
    );

    if(x < 0) {

        throw new InspireException(
            "양의 정수만 가능합니다!!"
        );
    }

    System.out.println(
        "debug >>>> first method end"
    );
}

throw는 실제 예외 객체를 발생시킨다.

throw new InspireException(
    "양의 정수만 가능합니다!!"
);

반면 throws는 해당 메서드에서 발생할 수 있는 Exception의 처리 책임을 호출한 쪽으로 넘긴다.

public void first(int x)
        throws InspireException

정리하면:

throw
→ Exception 발생

throws
→ Exception 처리 책임 전달

이다.

12. 사용자 정의 Exception 호출 흐름

호출하는 쪽에서는 다시 try-catch를 이용해 Exception을 처리할 수 있다.

ExceptionDemo demo =
    new ExceptionDemo();

try {

    demo.first(10);

} catch(InspireException e) {

    e.printStackTrace();
}

흐름은:

demo.first()
     ↓
조건 확인
     ↓
throw
     ↓
InspireException 발생
     ↓
throws
     ↓
호출부로 전달
     ↓
catch

이 된다.

13. 웹 애플리케이션의 계층 구조

Exception 실습 이후에는 앞으로 배우게 될 웹 백엔드의 전체 구조를 먼저 확인했다.

강의에서 설명한 흐름은 다음과 같았다.

Browser
   ↓
React
   ↓
Axios
   ↓
HTTP
   ↓
Servlet / Spring Boot
   ↓
Controller
   ↓
Service
   ↓
DAO / Repository
   ↓
ORM
   ↓
DB

계층으로 보면:

Presentation Layer
        ↓
Business Layer
        ↓
Persistence Layer

로 나누어 생각할 수 있다.

이후 단순히 그림으로 보는 데서 끝나지 않고, 이 구조를 이해하기 위한 Blog Console 프로그램을 직접 만들기 시작했다.

14. BlogReactView로 View 역할 분리

먼저 사용자에게 메뉴를 출력하는 BlogReactView를 만들었다.

public class BlogReactView {

    public void landingPage() {

        System.out.println();

        System.out.println(
            ">>>> Inspire Camp Blog Ver(1.0) <<<<"
        );

        System.out.println("1. 전체검색");
        System.out.println("2. 게시글 상세보기");
        System.out.println("3. 입력화면");
        System.out.println("4. 수정화면");
        System.out.println("5. 게시글 삭제");
        System.out.println("6. 검색");
        System.out.println("99. 프로그램 종료");
    }
}

실행 클래스에서는 View 객체를 만들고 landingPage()를 호출했다.

public class BlogReactApp {

    public static void main(
            String[] args) {

        BlogReactView view =
            new BlogReactView();

        view.landingPage();
    }
}

처음에는 main()에서 직접 모든 코드를 처리할 수도 있지만, 화면 출력 책임을 View로 따로 분리했다.

BlogReactApp
      ↓
BlogReactView
      ↓
화면 출력

15. Scanner를 이용한 사용자 입력

View에 사용자 입력을 받을 수 있도록 Scanner를 추가했다.

private Scanner scan;

public BlogReactView() {

    scan =
        new Scanner(
            System.in
        );
}

System.in에서 들어오는 입력을 Scanner를 이용해 처리했다.

또 메뉴를 한 번 출력하고 끝내는 것이 아니라 계속 사용할 수 있도록:

while(true)

구조를 사용했다.

public void landingPage() {

    while(true) {

        // 메뉴 출력
        // 사용자 입력
        // 기능 실행
    }
}

흐름은 다음과 같다.

메뉴 출력
   ↓
사용자 입력
   ↓
기능 실행
   ↓
다시 메뉴 출력

16. 메뉴 입력과 switch 분기

사용자가 입력한 메뉴 번호를 문자열로 받은 뒤 정수로 변환했다.

System.out.print(
    "원하시는 메뉴 번호를 입력하세요 : "
);

Integer number =
    Integer.parseInt(
        scan.nextLine()
    );

switch(number) {

    case 99:

        exit();
        break;

    default:

        break;
}

종료 기능도 별도의 메서드로 분리했다.

public void exit() {

    System.out.println();

    System.out.println(
        ">>>> 시스템을 종료하겠습니다."
    );

    System.exit(1);
}

17. FrontController 만들기

View가 각 기능별 Controller를 직접 찾아 호출하지 않도록 중앙 요청 처리 역할의 BlogFrontController를 만들었다.

private BlogFrontController front;

public BlogReactView() {

    scan =
        new Scanner(System.in);

    front =
        new BlogFrontController();
}

요청 흐름은:

사용자
   ↓
View
   ↓
FrontController

로 변경되었다.

FrontController는 사용자가 요청한 endpoint를 기준으로 실제 Controller를 찾아주는 역할을 한다.

18. Singleton Pattern으로 BeanFactory 구현

Controller 객체들을 관리하기 위해 BlogBeanFactory를 만들었다.

public class BlogBeanFactory {

    private Map<String, Object> map;

    private static BlogBeanFactory instance;
}

생성자를 private으로 선언했다.

private BlogBeanFactory() {

}

외부에서는 직접:

new BlogBeanFactory();

를 할 수 없다.

대신:

public static BlogBeanFactory getInstance() {

    if(instance == null) {

        instance =
            new BlogBeanFactory();
    }

    return instance;
}

를 이용한다.

흐름은:

BlogBeanFactory.getInstance()
        ↓
instance == null ?
        ↓
new BlogBeanFactory()
        ↓
instance 저장
        ↓
동일 객체 반환

이다.

19. Factory Pattern과 endpoint 매핑

BlogBeanFactory에서는 Map을 사용해 endpoint와 Controller를 연결했다.

map.put(
    "list.inspire",
    new ListController(service)
);

FrontController는 endpoint를 전달해서 해당 Controller를 얻는다.

public Object getBean(
        String endPoint) {

    return map.get(endPoint);
}

따라서:

"list.inspire"
       ↓
BlogBeanFactory
       ↓
Map
       ↓
ListController

라는 흐름이 만들어진다.

20. FrontController에서 실제 Controller 호출

BlogFrontController에서는 Singleton Factory를 가져왔다.

private BlogBeanFactory factory;

public BlogFrontController() {

    factory =
        BlogBeanFactory.getInstance();
}

전체검색 기능에서는:

public List<BlogResponseDTO> list(
        String endPoint) {

    System.out.println(
        "debug >>>> front controller endPoint : "
        + endPoint
    );

    Object controller =
        factory.getBean(
            endPoint
        );

    return (
        (ListController) controller
    ).list();
}

처럼 endpoint에 맞는 Controller를 찾고 실제 기능을 위임했다.

FrontController
      ↓
Factory
      ↓
Controller 찾기
      ↓
Controller.list()

21. Service Interface 정의

비즈니스 로직을 담당하는 Service 계층도 인터페이스와 구현 클래스로 분리했다.

public interface BlogReactService {

    public List<BlogResponseDTO>
        list();

    public BlogResponseDTO
        read(int blogId);

    public int
        insert(BlogRequestDTO request);

    public int
        update(BlogRequestDTO request);

    public int
        delete(int blogId);

    public List<BlogResponseDTO>
        search(BlogRequestDTO request);
}

기능 계약은 다음과 같다.

list()
→ 전체조회

read()
→ 상세조회

insert()
→ 등록

update()
→ 수정

delete()
→ 삭제

search()
→ 검색

실제 로직은 BlogReactServiceImpl이 담당하도록 했다.

public class BlogReactServiceImpl
        implements BlogReactService {

22. DAO에 인메모리 데이터 만들기

아직 실제 DB는 연결하지 않았기 때문에 BlogReactDao 내부에 List 형태의 테스트 데이터를 만들었다.

public class BlogReactDao {

    private List<BlogResponseDTO> blogs;
}

생성자에서 게시글 5개를 초기화했다.

blogs = new ArrayList<>(List.of(

    BlogResponseDTO.builder()
        .blogId(1)
        .title("react")
        .content("state")
        .email("lim")
        .viewCnt(10)
        .build(),

    BlogResponseDTO.builder()
        .blogId(2)
        .title("java")
        .content("oop")
        .email("kim")
        .viewCnt(20)
        .build(),

    BlogResponseDTO.builder()
        .blogId(3)
        .title("spring")
        .content("mybatis")
        .email("lee")
        .viewCnt(30)
        .build(),

    BlogResponseDTO.builder()
        .blogId(4)
        .title("docker")
        .content("devops")
        .email("park")
        .viewCnt(40)
        .build(),

    BlogResponseDTO.builder()
        .blogId(5)
        .title("msa")
        .content("kafka")
        .email("lim")
        .viewCnt(50)
        .build()
));

현재는 실제 DB 대신:

BlogReactDao
      ↓
List<BlogResponseDTO>

를 사용해 Repository / DAO의 역할을 연습했다.

23. Dependency Injection 직접 구현하기

오늘 Blog 실습에서 가장 중요한 부분 중 하나였다.

Factory에서 필요한 객체들을 생성한 뒤 하위 객체에 전달했다.

dao =
    new BlogReactDao();

service =
    new BlogReactServiceImpl(
        dao
    );

map.put(
    "list.inspire",
    new ListController(
        service
    )
);

객체의 의존관계는:

BlogReactDao
     ↓
BlogReactServiceImpl
     ↓
ListController

이다.

BlogReactServiceImpl에서는 DAO를 생성자로 전달받았다.

private BlogReactDao dao;

public BlogReactServiceImpl(
        BlogReactDao dao) {

    this.dao = dao;
}

Service 내부에서 직접:

new BlogReactDao();

를 호출하지 않고 외부에서 생성한 객체를 주입받았다.

즉 오늘은 Spring 없이 직접 Constructor Injection 기반의 DI 구조를 만들어본 셈이다.

24. 전체검색 요청을 DAO까지 연결

사용자가 메뉴에서:

1. 전체검색

을 선택했을 때 요청이 실제 DAO까지 전달되도록 연결했다.

실행 로그는 다음 순서로 출력됐다.

debug >>>> front controller endPoint : list.inspire

debug >>>> list controller list()

debug >>>> blog service list

debug >>>> blog dao findByAll()

이 로그를 통해 다음 호출 체인을 실제로 확인했다.

BlogReactView
      ↓
BlogFrontController
      ↓
BlogBeanFactory
      ↓
ListController
      ↓
BlogReactServiceImpl
      ↓
BlogReactDao

이전까지 그림으로만 보던 계층 구조가 실제 코드에서는 어떤 순서로 호출되는지 확인할 수 있었다.

25. DAO 결과를 다시 View까지 반환

DAO에서 조회한 데이터는 다시 반대 방향으로 전달된다.

BlogReactDao
      ↓
BlogReactServiceImpl
      ↓
ListController
      ↓
BlogFrontController
      ↓
BlogReactView

View에서는 다음처럼 데이터를 받았다.

public void list() {

    System.out.println();

    System.out.println(
        ">>>> 데이터 출력"
    );

    String endPoint =
        "list.inspire";

    List<BlogResponseDTO> response =
        front.list(
            endPoint
        );

    response.stream()
        .forEach(
            System.out::println
        );
}

수업 초반 복습했던 Stream API와 메서드 참조가 실제 Blog 조회 기능에서 다시 사용됐다.

response.stream()
    .forEach(
        System.out::println
    );

처리가 끝난 뒤에는 다시 메뉴가 출력되며 다음 사용자 입력을 기다렸다.

실습 기록

1. Runtime Exception 발생 확인

String 배열 생성
→ 반복문 실행
→ 잘못된 index 접근
→ ArrayIndexOutOfBoundsException
→ catch
→ printStackTrace()

배열 범위를 벗어난 접근을 통해 Runtime Exception이 실제로 발생하는 것을 확인했다.

2. BufferedReader 입력 처리

System.in
→ InputStreamReader
→ BufferedReader
→ readLine()
→ String

IOException을 try-catch로 처리하면서 입력 Stream 구조를 확인했다.

3. 사용자 정의 Exception

InspireException
→ Exception 상속

first(x)
→ x < 0 검사
→ throw new InspireException(...)
→ throws InspireException
→ 호출부 catch

throw와 throws가 실제 코드에서 어떻게 연결되는지 확인했다.

4. Blog 메뉴 View 구현

BlogReactApp
→ BlogReactView
→ landingPage()
→ 메뉴 출력

다음 메뉴가 정상적으로 출력되는 것을 확인했다.

>>>> Inspire Camp Blog Ver(1.0) <<<<
1. 전체검색
2. 게시글 상세보기
3. 입력화면
4. 수정화면
5. 게시글 삭제
6. 검색
99. 프로그램 종료

5. Scanner 기반 메뉴 입력

Scanner(System.in)
→ scan.nextLine()
→ Integer.parseInt()
→ switch(number)

사용자가 메뉴 번호를 입력하면 해당 기능으로 분기하도록 구성했다.

6. FrontController + BeanFactory 연결

View
→ FrontController
→ endpoint
→ BlogBeanFactory
→ Controller 반환

"list.inspire" endpoint를 기준으로 ListController를 조회하도록 만들었다.

7. Dependency Injection

Factory에서:

BlogReactDao 생성
        ↓
BlogReactServiceImpl(dao)
        ↓
ListController(service)

순서로 객체를 생성하고 의존성을 전달했다.

Spring의 DI를 사용하기 전에 객체가 실제로 어떤 의존관계를 가지는지 직접 코드로 확인할 수 있었다.

8. 전체검색 End-to-End 실행

사용자가 메뉴 1을 입력했을 때:

원하시는 메뉴 번호를 입력하세요 : 1

이후 다음 로그가 출력됐다.

debug >>>> front controller endPoint : list.inspire
debug >>>> list controller list()
debug >>>> blog service list
debug >>>> blog dao findByAll()

즉:

View
→ FrontController
→ Controller
→ Service
→ DAO

전체 흐름이 실제로 연결되었다.

9. 조회 결과 출력

DAO에서 반환된 List<BlogResponseDTO>를 View에서 Stream API로 출력했다.

response.stream()
    .forEach(
        System.out::println
    );

실제 게시글 DTO들이 Console에 출력되는 것을 확인했고, 이후 다시 메뉴로 돌아와 다음 입력을 기다렸다.

문제 해결 과정

문제 1. 메뉴에 문자열을 입력하면 NumberFormatException 발생

증상

메뉴 번호 입력란에 숫자가 아닌 문자열을 입력했다.

원하시는 메뉴 번호를 입력하세요 : jslim

그 결과:

Exception in thread "main"
java.lang.NumberFormatException:
For input string: "jslim"

이 발생했다.

원인

사용자 입력을 다음 코드에서 곧바로 정수로 변환하고 있었다.

Integer number =
    Integer.parseInt(
        scan.nextLine()
    );

Integer.parseInt()는 숫자 형태의 문자열만 정수로 변환할 수 있다.

"1"
→ 정상

"99"
→ 정상

"jslim"
→ Integer 변환 불가능
→ NumberFormatException

또 Stack Trace를 통해:

Integer.parseInt(...)
        ↓
BlogReactView.landingPage(...)
        ↓
BlogReactApp.main(...)

순서로 예외 발생 위치를 추적할 수 있었다.

해결 방향

수업에서는 사용자가 실수하거나 악의적으로 잘못된 데이터를 입력할 수 있기 때문에 Exception을 그대로 프로그램 종료로 이어지게 만들어서는 안 된다고 설명했다.

필요한 처리 흐름은 다음과 같다.

사용자 입력
   ↓
숫자가 아닌 문자열
   ↓
NumberFormatException
   ↓
예외 처리
   ↓
안내 메시지 출력
   ↓
다시 메뉴 입력

오늘 수업에서는 예외가 발생하는 상황과 원인, 예외 처리를 통해 다시 입력받도록 해야 한다는 방향까지 확인했다.

완성된 재입력 처리 코드까지 구현한 것은 아니기 때문에 실제 구현 여부를 과장해서 기록하지 않았다.

✨ 오늘 배운 내용 정리

오늘 가장 중요했던 부분은 Exception 문법이나 MVC 구조를 각각 따로 외우는 것이 아니었다.

지금까지 학습했던 여러 Java 개념들이 하나의 프로그램 안에서 연결되는 것을 직접 확인했다.

상속 / 다형성
        ↓
Interface
        ↓
Collection / Generics
        ↓
Stream
        ↓
Exception
        ↓
MVC 계층 구조
        ↓
Factory / Singleton
        ↓
Dependency Injection

특히 Blog 프로그램의 전체검색 기능에서는 다음 구조가 실제로 완성되었다.

                 사용자
                   │
                   ↓
            BlogReactView
                   │
                   ↓
         BlogFrontController
                   │
                   ↓
          BlogBeanFactory
                   │
          "list.inspire"
                   │
                   ↓
            ListController
                   │
                   ↓
          BlogReactService
                   │
                   ↓
       BlogReactServiceImpl
                   │
                   ↓
            BlogReactDao
                   │
                   ↓
       List<BlogResponseDTO>
                   │
                   ↓
            다시 View로 반환
                   │
                   ↓
       Stream API로 데이터 출력

객체 생성 관계는 Factory에서 다음과 같이 구성했다.

BlogReactDao
      │
      ↓
BlogReactServiceImpl
      │
      ↓
ListController

이를 코드로 보면:

dao =
    new BlogReactDao();

service =
    new BlogReactServiceImpl(
        dao
    );

map.put(
    "list.inspire",
    new ListController(
        service
    )
);

이 구조를 직접 구현하면서 DI란 객체가 필요한 의존성을 직접 생성하는 것이 아니라 외부에서 전달받는 방식이라는 점을 더 명확하게 이해할 수 있었다.

또 오전에 학습한 Exception Handling이 오후의 Blog 실습에서 바로 실제 문제로 나타났다.

사용자 입력
→ "jslim"
→ Integer.parseInt()
→ NumberFormatException

즉 Exception 처리는 단순한 문법이 아니라 예상하지 못한 사용자 입력에서도 프로그램의 흐름을 유지하기 위한 설계 요소라는 것을 확인했다.

오늘의 회고

오늘은 지금까지 학습했던 Java 문법들이 실제 백엔드 구조 안에서 처음으로 크게 연결된 수업이었다.

오전에는 try-catch-finally, throw, throws, 사용자 정의 Exception을 각각 코드로 실습했다. 배열 범위를 넘어가면서 발생한 ArrayIndexOutOfBoundsException이나 BufferedReader의 IOException을 직접 처리해보면서 Exception이 발생했을 때 프로그램의 흐름이 어떻게 바뀌는지 확인할 수 있었다.

특히 printStackTrace()를 단순히 에러 메시지를 출력하는 메서드로 보는 것이 아니라 호출 Stack을 따라 실제 예외가 발생한 지점을 추적하는 도구라는 점이 기억에 남았다.

오후 Blog 실습에서는 이전까지 그림으로만 봤던 MVC 구조를 직접 클래스 단위로 분리했다.

처음에는:

BlogReactApp
→ BlogReactView

정도였지만, 수업이 진행되면서:

View
→ FrontController
→ BeanFactory
→ Controller
→ Service
→ DAO

까지 계층이 계속 확장됐다.

무엇보다 각 계층에 넣어둔 로그가:

front controller
→ list controller
→ blog service
→ blog dao

순서로 실제 출력되는 것을 보면서 Controller, Service, DAO를 왜 나누는지 조금 더 명확하게 이해할 수 있었다.

이전에는 Controller → Service → Repository라는 구조를 외우는 느낌이 강했다면, 오늘은 사용자의 요청이 각 계층을 거쳐 내려갔다가 다시 데이터를 가지고 올라오는 흐름으로 이해하게 되었다.

BlogBeanFactory에서 객체를 직접 조립한 부분도 중요했다.

dao =
    new BlogReactDao();

service =
    new BlogReactServiceImpl(
        dao
    );

new ListController(
    service
);

이 코드를 직접 작성해보니 Service가 DAO를 필요로 하고, Controller가 Service를 필요로 한다는 객체 간 의존관계가 코드상으로 확실히 보였다.

아직 Spring을 사용하지 않고 직접 객체를 생성하고 주입하고 있지만, 오히려 이렇게 먼저 구현해보니 앞으로 Spring의 IoC Container와 DI를 배울 때 Spring이 어떤 작업을 대신 해주는지 비교하기 쉬울 것 같다.

또 메뉴에 "jslim"을 입력하면서 발생한 NumberFormatException도 오전에 배운 Exception Handling과 바로 연결됐다.

정상적인 입력만 가정하면 프로그램이 동작하지만 실제 사용자는 잘못된 값이나 예상하지 못한 값을 입력할 수 있다.

따라서 앞으로는 단순히:

기능이 정상적으로 동작하는가?

뿐만 아니라:

잘못된 입력이 들어와도
프로그램의 흐름을 유지할 수 있는가?

까지 생각하면서 코드를 작성해야겠다고 느꼈다.

다시 복습할 부분은 throw와 throws의 역할 차이, FrontController → Factory → Controller 요청 분배 흐름, 그리고 Factory에서 직접 구현한 생성자 기반 DI 구조이다.

특히 오늘 직접 만든:

View
→ FrontController
→ Controller
→ Service
→ DAO

구조를 코드 없이도 설명할 수 있을 정도로 다시 정리한 뒤, 이후 Spring에서 동일한 구조가 어떻게 변경되는지 비교해보려고 한다.