Eundms

[Kubernetes] ServiceAccount, Role, RoleBinding 관계

:해피래빗 — Sun, 24 May 2026 20:06:36 +0900

누가 무엇을 연결(누가 무엇을 한다)

- ServiceAccount : 권한을 사용할 주체

- Role : 어떤 리소스에 어떤 행동을 할 수 있는지 정의

- RoleBinding: ServiceAccount와 Role을 연결

apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-sa
  namespace: dev

apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  namespace: dev
  name: pod-reader

rules:
- apiGroups: [""]
  resources: ["pods"]
  verbs: ["get", "list", "watch"]

apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: read-pods
  namespace: dev

subjects:
- kind: ServiceAccount
  name: app-sa
  namespace: dev

roleRef:
  kind: Role
  name: pod-reader
  apiGroup: rbac.authorization.k8s.io

Role vs ClusterRole

Role : 특정 namespace 범위, 특정 namespace 안에서만 동작

ClusterRole: Node 조회, 모든 namespace pod 조회

RoleBinding vs ClusterRoleBinding

RoleBinding	namespace
ClusterRoleBinding	cluster 전체

[Kubernetes] Secret

:해피래빗 — Tue, 21 Apr 2026 08:29:19 +0900

시크릿의 특성과 사용이유

Kubernetes Secret은 단순 Base64 인코딩이다 (암호화가 아니다)

etcd에 평문으로 저장되며 API (access)접근 권한이 있는 모든 사용자 또는 etcd에 접근할 수 있는 모든 사용자는 시크릿을 조회하거나 수정할 수 있다. 네임스페이스에서 파드를 생성할 권한이 있는 사람은 누구나 해당 네임스페이스의 모든 시크릿을 읽을 수 있다 .

또한, kubectl get secrets -o yaml 로 보면 쉽게 복원 가능하다

그럼에도 Secret을 쓰는 이유는 운영 레벨에서 안전성을 높이는 구조가 있기 때문이다

예를 들어,

(1) 노드 단위로 제한하여 전달할 수 있다

- Secret은 필요한 Pod가 있는 Node에만 전달된다

- 전체 클러스터에 퍼지지 않으므로 공격 표면적(?)이 감소한다

(2) 디스크가 아니라 메모리(tmpfs)에 저장된다

- 디스크 탈취 공격을 방지할 수 있다

(3) Pod 삭제시 Secret도 같이 삭제된다

- Pod가 사라지면 Kubelet이 Secret도 정리한다

- 따라서, 잔존 데이터 리스크가 감소한다

(4) Git에 안 올리면 최소한의 사고 방지

- Secret YAML을 repo에 안 올리는 것만으로도 사람의 실수로 유출되는 사고를 방지할 수 있다

시크릿을 안전하게 사용하려면

https://kubernetes.io/ko/docs/concepts/security/secrets-good-practices/

etcd Encryption at Rest 활성화https://kubernetes.io/docs/tasks/administer-cluster/encrypt-data/

etcd에 저장될 때 실제로 암호화됨

RBAC으로 접근 제한 https://kubernetes.io/ko/docs/reference/access-authn-authz/authorization/

Secret 읽을 수 있는 권한 최소화

External Secret 관리 도구 사용https://secrets-store-csi-driver.sigs.k8s.io/concepts.html#provider-for-the-secrets-store-csi-driver

AI시대에 개발자에게 가장 필요한 역량이 무엇일까 (지극히 개인적인 생각)

:해피래빗 — Wed, 15 Apr 2026 21:23:39 +0900

AI 시대에 개발자에게 가장 필요한 역량은 '고유한 관점'이라고 생각한다.

생성형 AI는 확률에 기반하여 문제를 정의하고 해결하지만

같은 기술을 사용하더라도 문제를 바라보는 시각에 따라 전혀 다른 해결 방식이 나올 수 있다.

예를 들어, 엘리베이터 속도가 느리다는 문제에 대해 어떤 이는 속도를 개선하려 했고, 다른 이는 거울을 설치해 사용자의 체감 시간을 줄이는 방식으로 접근했다.

개발에서도 마찬가지라고 생각한다.

성능 개선, 시스템 구조 단순화, 운영 안정성 확보 등 어떤 관점에서 문제를 정의하느냐에 따라 해결 방향은 달라진다.

결국 중요한 것은 문제의 본질적인 맥락을 이해하고, 상황에 맞는 해결책을 설계하는 사고력이라고 생각한다.

이미 알려진 방식에 머무르기보다 다양한 관점에서 시도하고

그 과정과 생각을 팀과 공유하며 설득하는 과정이 앞으로 더욱 중요해질 것이라고 생각한다.

이러한 관점에서 오픈소스 활동은 좋은 환경이라고 생각한다.

[Kubernetes] 서비스 : NodePort, ClusterIP, Load Balancer

:해피래빗 — Sun, 5 Apr 2026 13:07:49 +0900

서비스

kubectl service {서비스이름} --url

https://kubernetes.io/ko/docs/concepts/services-networking/service/#publishing-services-service-types

서비스

외부와 접하는 단일 엔드포인트 뒤에 있는 클러스터에서 실행되는 애플리케이션을 노출시키며, 이는 워크로드가 여러 백엔드로 나뉘어 있는 경우에도 가능하다.

kubernetes.io

Pod 정의가 아래와 같다고 하자

# pod-definition.yml

apiVersion: v1
kind: Pod

metadata:
  name: myapp-pod
  labels:
    app: myapp
    type: front-end
  spec:
    containers:
    - name: nginx-container
      image: nginx

NodePort

Service 관점에서 내 포트(port), 노드에 달린 Port(노드포트), 타겟 포트(포트를 노출하고 싶은 컨테이너의 포트)

# service-definition.yml

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  type: NodePort
  ports:
    - targetPort: 80   # 1. 타겟 포트 (default, 2와 동일)
      port: 80         # 2. 서비스 오브젝트의 포트값 (필수)
      nodePort: 30008  # 3. 노드 포트 (default, 자동)
  selector:  # pod-definition.yml의 레이블 selector (모든 일치하는 레이블 찾아서 진행함) 
    app: myapp
    type: front-end

- 서비스는 모든 노드에 걸쳐서 동일한 레이블에 해당하는 파드에 대해 적용되고

이때 service 는 로드밸런서 역할을 하게 됨

ClusterIp

예시: frontend backend redis 각각 끼리 통신하기 위한 IP

https://kubernetes.io/ko/docs/concepts/services-networking/service/#%EB%8F%99%EA%B8%B0

# clusterIP for Backend

apiVersion: v1
kind: Service
metadata:
  name: back-end
spec:
  type: ClusterIP
  ports:
    - targetPort: 80
      port: 80
  selector: # pod-definition.yml의 lables.*의 내용 적기
    app: myapp
    type: backend

Load Balancer

HAProxy, Nginx등을 설치해서 LoadBalancer가 /voting 은 voting app으로 /dashboard는 dashboard app으로 가게 할 수 있다

AWS, GCP 등이 제공하는 LoadBalancer 서비스를 사용하기 위한 타입이다

apiVersion: v1
kind: Service
metadata:
  name: myapp-service
spec:
  type: LoadBalancer
  ports:
    - targetPort: 80
      port: 80
      nodePort: 30008

GC 튜닝 기본

:해피래빗 — Wed, 1 Apr 2026 23:42:38 +0900

1) JVM의 주요 default 설정

1. 서버용 머신 : G1GC가 사용, 그 외 : Serial Collector 사용

2. Initial heap size (JVM이 시작할 때 바로 확보하는 heap 크기) : RAM의 1/64

3. maximum heap size (JVM heap의 최대 크기) : RAM의 1/4

4. minimum heap size (JVM heap의 최소 크기) : 디폴트 값 설정이 약간 복잡하게 결정됨

=> 서버 애플리케이션의 경우 이 세가지 값을 동일하게 맞춤

5. 최대 GC thread 수 : heap size와 이용 가능한 CPU resources에 의해 결정됨

6. JIT 컴파일러 : C1과 C2를 사용하는 tiered compiler 사용

실행 중인 자바 프로세스의 JVM 기본 옵션 보기

jps -l # 현재 실행중인 자바 프로세스 ID 리스트

jcmd 프로세스아이디 VM.flags # 기본적으로 설정된 VM Option

2) 튜닝 대상

최대 일시 중지 시간(Maximum Pause-Time Goal) : -XX:MaxGCPauseMillis=밀리초

- 일시 중지 시간 : 가비지 컬렉터가 애플리케이션을 중지하고 더 이상 사용되지 않는 공간을 회수하는 데 걸리는 시간

- pause time이 아무리 길어도 `maximum pause-time goal`보다는 적어야 한다 
- GC는 pause time에 대한 가중평균과 분산을 계산해서 이 둘의 합을 maximum pause-time 으로 설정
- maximum pause-time goal의 디폴트 값은 collector마다 다름

>> heap size나 gc 관련 여러 파라미터들을 조정하여 pause time을 nnn milliseconds보다 작게 유지하려고 시도

Q. 일시 중지 시간을 줄이고 싶어+힙 관점에서는 어떻게 조절해야 하는가

힙 사이즈 줄이기 (탐색해야하는 힙내 데이터가 줄어들음)

처리량 목표(Throughput Goal) : -XX:GCTimeRatio=nnn

- GC time과 application time을 비교해서 특정 비율을 맞춘다

- `-XX:GCTimeRatio=nnn`로 지정. `GC Time Ratio = 1/(1+nnn)`로 목표를 설정한다

Q. throughput goal이 충족되지 않음

힙 사이즈 늘이기

풋프린트 (Minimum Footprint Goal)

- 처리량 및 최대 일시 중지 시간 목표가 충족되면, 두 목표 중 하나(대기 처리량 목표)를 더 이상 충족할 수 없을 때까지 힙 크기를 줄인다

(불필요하게 점유하는 메모리를 줄여서 다른 프로세스들도 메모리를 사용할 수 있게 해준다)

- 가비지 컬렉터가 사용할 수 있는 최소 및 최대 힙 크기는 다음을 사용하여 설정할 수 있다

-Xms=<nnn> : 최소 힙 크기

-Xmx=<mmm> : 최대 힙 크기

Q. 서버 애플리케이션은 최소 힙 = 최대 힙 . 왜 ?

런타임 중 힙 크기 변화를 막아서 GC 안정성과 성능을 확보하기 위해

서버는:

항상 트래픽 있음
latency 민감 (특히 API)
예측 가능한 성능 중요

힙이 늘어나면:

GC pause 시간 증가
요청 지연 발생
tail latency 튐 (이게 제일 위험)

3) 힙 사이즈 튜닝을 어떻게 해야 하는가

throughput goal을 잡고 max heap size를 잡는다 (swap 없이)

그럼에도 목표를 달성하지 못하면 RAM 이 이 throughput 을 감당하지 못하는 것이다

달성했는데 pause time이 너무 길면 maximum pause-time goal 을 지정한다

(단, throughput goal과 maximum pause-time goal은 트레이드 오프 관계이기 때문에 적당한 타협이 필요하다)

서버 애플리케이션은 동일하게 설정한다

[AWS] AWS Certified Cloud Practitioner 취득 후기

:해피래빗 — Mon, 9 Mar 2026 09:39:40 +0900

시험 개요

AWS Certified Cloud Practitioner를 취득하면 AWS 클라우드의 서비스 및 용어에 대한 기초 지식을 습득

시간

90분

가격

100USD (환율...)

할인 방법

1) 여러 방법

https://www.reddit.com/r/AWSCertifications/comments/1q0vu4p/2026_aws_vouchers_exam_discounts_coupons_other/

2) 100% 할인 - 포인트 교환 : 언제 열릴지 열리긴 할지 모름

https://www.awseducate.com/student/s/etc-home

Functional cookies help us provide useful site features, remember your preferences, and display relevant content. Approved third parties may set these cookies to provide certain site features. If you do not allow these cookies, then some or all of these se

www.awseducate.com

Requirements: 4,500 points for Foundational, 5,200 points for Associate level.
Actions: Complete surveys, training courses, and labs in the ETC.
Process: After accumulating enough points, redeem them in the "Rewards" tab of the ETC.
Limitations: Once an associate voucher is received, you cannot request another one immediately, but you can still earn points for a foundational voucher.
Validation: It may take up to three business days for reward requests to be reviewed.

해당 시험을 본 이유

이후 AWS Certified Solutions Architect - Associate 취득을 위한
1. 50퍼센트 할인 쿠폰을 얻기 위해
2. 다양한 AWS 클라우드 서비스의 역할을 익히기 위해 (기초 지식 쌓기 위한 목적)

준비기간

9시간 + 알파 (= 3시간 + 6시간 + 시험 직전)

준비 방법

1. AWS Skill Builder의
AWS Cloud Practitioner Essentials 강의
https://skillbuilder.aws

AWS Skill Builder

skillbuilder.aws

2. 어떤 블로그에 담겨 있는 기출 문제 정리 (이건 효과가 그렇게 있지 않았다)

오히려 개념을 이해하고
강의 내에서 제공해주는 기본 문제들을
개념에 기반하여 풀 수 있는 것이 중요하다

시험 준비 팁

해당 강의의 주제가 아래와 같은데
이게 출제 기준과 매우 일치하다고
개인적으로 생각된다

AWS 클라우드의 기본 기능 및 이점
AWS 클라우드에서 가상 컴퓨팅 리소스를 프로비저닝하고 관리하는 방법
AWS 컴퓨팅 서비스가 확장 가능한 서버리스 애플리케이션 환경을 지원하는 방법
AWS 글로벌 인프라의 기본 구성 요소 및 이점
AWS 네트워킹 구성 요소 및 서비스
AWS 스토리지 서비스, 스토리지 티어, 데이터 수명 주기 정책
AWS 데이터베이스 서비스 및 마이그레이션 도구
AWS AI/ML 서비스, AWS 생성형 AI 서비스, AWS ETL 데이터 파이프라인의 이점 및 목적
AWS 보안 서비스가 네트워크 공격으로부터 보호하고, 데이터를 보호하며, 보안 사고를 탐지하고 대응하도록 지원하는 방법
AWS 모니터링, 규정 준수, 거버넌스 서비스
AWS 요금 및 AWS Support의 기본 개념, 서비스, 기능
AWS 마이그레이션 전략 및 서비스
전문 AWS 서비스 및 AWS Well-Architected Framework의 6가지 핵심 요소

다음 글에서 아직도 헷갈리는 서비스들을 정리해보겠다.. (네트워크, 스토리지, 데이터처리, 마이그레이션, 모니터링)

[쿠버네티스] 쿠버네티스 리소스 구조 이해하기 - kind, metadata, spec

:해피래빗 — Tue, 24 Feb 2026 09:25:51 +0900

모든 쿠버네티스 리소스는 4가지 최상위 필드를 가진다

apiVersion:
kind:
metadata:
spec:

https://kubernetes.io/docs/concepts/overview/working-with-objects/#required-fields

Objects In Kubernetes

Kubernetes objects are persistent entities in the Kubernetes system. Kubernetes uses these entities to represent the state of your cluster. Learn about the Kubernetes object model and how to work with these objects.

kubernetes.io

spec은 리소스의 원하는 상태를 정의하는데 이 부분이 Kind마다 다르다

https://kubernetes.io/docs/concepts/overview/working-with-objects/#object-spec-and-status

Objects In Kubernetes

kubernetes.io

Kind 종류

Wokrload 관련 (앱 실행)

Pod : 컨테이너 실행의 최소 단위 (지금 사용 중)

Deployment: Pod를 여러 개 생성/업데이트/롤백 관리

ReplicaSet: Pod 복제본 수 유지 (보통 Deployment가 자동 관리)

StatefulSet: 상태가 있는 앱(DB 등) - 순서 보장, 고정 이름

DaemonSet: 모든 노드에 Pod 1개씩 실행 (로그 수집, 모니터링 등)

Job : 한 번 실행하고 끝나는 작업

CronJob : 스케줄에 따라 반복 실행하는 Job

Network (접근/통신)

Service: Pod에 안정적인 네트워크 접점 제공 (지금 사용중)

Ingress: 외부 HTTP 트래픽을 Service로 라우팅 (도메인/경로 기반)

NetworkPolicy: Pod간 네트워크 트래픽 제어 (방화벽)

Configration (설정/저장)

ConfigMap : 설정값 저장 (환경변수, 설정 파일)

Secret: 민감한 데이터 저장 (비밀번호, 토큰)

PersistentVolume (PV) : 물리 스토리지

PersistentVolumeClaim (PVC) : PV 요청 (Pod가 스토리지 사용 시)

Cluster Administration (클러스터 관리)

Namespace : 리소스를 논리적으로 분리

ServiceAccount : Pod의 인증 ID

Role/ClusterRole : 권한 정의

RoleBinding/ClusterRoleBinding : 권한을 SA/사용자에 부여

주요 Spec의 의미

Pod의 spec → "어떤 컨테이너를 실행할 것인가"

  spec:
    containers:
    - name: redis
      image: redis:alpine
      ports:
      - containerPort: 6379

Service의 spec → "어떤 Pod에 어떻게 네트워크를 연결할 것인가"

  spec:
    type: NodePort
    ports:
    - port: 8080         # 클러스터 내부에서 서비스 접근 포트 
      targetPort: 80     # Pod의 어느 포트로 보낼지 
      nodePort: 31000    # 외부에서 접근하는 포트
    selector:            # label이 일치하는 Pod를 찾아 연결
      app: redis

Deployment의 spec → "Pod를 몇 개, 어떻게 관리할 것인가"

  spec:
    replicas: 3
    selector:
      matchLabels:
        app: redis
    template:            # Pod 템플릿 (안에 또 metadata + spec)
      metadata:
        labels:
          app: redis
      spec:
        containers:
        - name: redis
          image: redis:alpine

Service -> Pod 연결 흐름

Service의 spec.selector.{key} : {value} == Pod의 metadata.labels.{key} : {value}

https://kubernetes.io/docs/concepts/services-networking/service/#defining-a-service

Service

Expose an application running in your cluster behind a single outward-facing endpoint, even when the workload is split across multiple backends.

kubernetes.io

https://kubernetes.io/docs/concepts/overview/working-with-objects/labels/

[테스트] 통합 테스트에서 테스트 간 DB 상태가 공유되는 문제 : @Transactional, 사용하면 안되는 상황, 그외 방식

:해피래빗 — Mon, 9 Feb 2026 22:10:52 +0900

상황

- 아래 테스트 코드를 실행 시켰다

@SpringBootTest
@Import(SplearnTestConfiguration.class)
public class MemberRegisterTest {
  @Autowired
  private MemberRegister memberRegister;

  @Test
  void register(){
    Member member = memberRegister.register(MemberFixture.createRegisterRequest());

    assertThat(member.getId()).isNotNull();
    assertThat(member.getStatus()).isEqualTo(MemberStatus.PENDING);
  }

  @Test
  void duplicateEmailFail(){
    Member member = memberRegister.register(MemberFixture.createRegisterRequest());

    assertThatThrownBy(
        () -> memberRegister.register(MemberFixture.createRegisterRequest())
    ).isInstanceOf(DuplicateEmailException.class);

  }
}

현상

duplicateEmailFail의 첫번째 register에서 예외가 발생했다

원인

통합 테스트에서 테스트 간 DB 상태가 공유되는 것이 문제였다.

해결

따라서, @Transactional 으로 테스트 메서드마다 실행 후 자동 롤백되도록 한다.

@Transactional 으로 롤백이 안되는 경우는 없을까?

1. 스프링 테스트가 아닐 때

Spring Test의 TransactionalTestExecutionListener가 @Transactional의 테스트 후 자동 롤백을 해준다.

2. HTTP 레벨 테스트

@SpringBootTest(webEnvironment=RANDOM_PORT) + RestTemplate/WebTestClient로 테스트하면

서버가 별도 스레드에서 별도 트랜잭션을 사용하므로,

테스트의 롤백이 서버 쪽 DB 변경에 영향을 못 준다.

3. DB가 원격이거나 분리된 경우

테스트의 애플리케이션이 서로 다른 DB 커넥션/트랜잭션을 사용하면 롤백이 불가능하다

테스트 코드와 애플리케이션 코드가 같은 트랜잭션을 공유하면 안되는 경우가 있을까?

@Transactional 테스트가 버그를 숨기는 경우

1) Lazy Loading 문제

- 테스트에 @Transactional이 있으면 영속성 컨텍스트가 테스트 끝까지 열려있음

- 서비스에서 지연 로딩(LAZY)을 호출해도 테스트에선 정상 동작

- 하지만 실제 운영에선 서비스 메서드가 끝나면 트랜잭션이 닫히므로 LazyInitializationException 발생

- 테스트는 통과했는데 운영에서 터지는 상황

// Member 엔티티
@Entity
public class Member {
  @OneToMany(fetch = FetchType.LAZY)
  private List<Order> orders;  // 지연 로딩
}

// 서비스
@Service
public class MemberService {
  @Transactional
  public Member findMember(Long id) {
    return memberRepository.findById(id).orElseThrow();
    // 여기서 트랜잭션 끝 → 영속성 컨텍스트 닫힘
  }
}

// 테스트에 @Transactional이 있으면
@Test
@Transactional
void test() {
  Member member = memberService.findMember(1L);
  member.getOrders().size(); // 테스트 트랜잭션이 아직 열려있어서 → 성공!
}

// 운영에서는
Member member = memberService.findMember(1L);
member.getOrders().size(); // 서비스 트랜잭션이 이미 닫혔으므로 → LazyInitializationException!

운영 환경
  컨트롤러 호출
    → 서비스 @Transactional 시작 → 영속성 컨텍스트 열림
      → memberRepository.findById(1L)  -- Member 로딩 (orders는 LAZY라 프록시)
    → 서비스 @Transactional 끝 → 영속성 컨텍스트 닫힘

    → member.getOrders().size()  -- 영속성 컨텍스트 이미 닫힘 → LazyInitializationException!

  테스트 환경 (@Transactional 있을 때)
  테스트 @Transactional 시작 → 영속성 컨텍스트 열림
    → 서비스 @Transactional (테스트 트랜잭션에 합류, 새로 안 만듦)
      → memberRepository.findById(1L)
    → 서비스 메서드 끝 (하지만 트랜잭션은 테스트 것이라 안 닫힘)

    → member.getOrders().size()  -- 테스트 트랜잭션이 아직 열려있음 → 성공!
  테스트 @Transactional 끝 → 롤백

  핵심은 서비스의 @Transactional이 독립 트랜잭션을 안 만들고 테스트 트랜잭션에 합류(기본 전파 =
  REQUIRED)하기 때문에, 서비스 메서드가 끝나도 영속성 컨텍스트가 살아있다.

운영에서는 서비스 트랜잭션이 진짜 끝나니까 터진다.

2) Flush 타이밍 문제 (ID 생성 전략에 따라 다름)

- 롤백할 거니까 JPA가 DB에 flush를 안 할 수 있음

GenerationType.IDENTITY는 save()시 즉시 INSERT 실행

GenerationType.SEQUENCE는 save()시 INSERT를 커밋 시점까지 미룰 수 있음 -> 이때 flush 생략 가능

- unique 제약 조건 위반 같은 DB 레벨 에러가 테스트에서 안 터짐

- 테스트는 통과, 운영에서 실패

예를 들어, 아래처럼 @Id의 @GeneratedValue(GenerationType.SEQUENCE)인 엔티티가 있고

@Entity
public class Member {
	@Id
  	@GeneratedValue(strategy = GenerationType.SEQUENCE) // 확인!
  	private Long id;
    
    // Member 엔티티에 unique 제약
	@Column(unique = true)
	private String email;
    
    //중략..
}

아래와 같은 @DataJpaTest 테스트 코드를 작성한다고 하자

@DataJpaTest
class MemberRepositoryTest {
  @Autowired
  MemberRepository memberRepository;
  
  // @Transactional - @DataJpaTest을 사용하게 되면 @Transactional이 이미 포함되어 있음
  @Test
  void duplicateEmailFail(){
    Member member = Member.register(createRegisterRequest(), createPasswordEncoder());
    memberRepository.save(member);

    Member member2 = Member.register(createRegisterRequest(), createPasswordEncoder());
    assertThatThrownBy(() -> memberRepository.save(member2))
        .isInstanceOf(DataIntegrityViolationException.class);

  }
}

2번째 save에서 예외가 났어야 했지만,

로그를 살펴보면, SEQUENCE 전략은 시퀀스에서 id만 미리 받아오고,

실제 INSERT는 flush/커밋 시점까지 미루기 때문에,

unique 제약 위반이 발생하지 않음을 알 수 있다. (IDENTITY는 flush되서 예외 발생함)

Hibernate: create sequence member_seq start with 1 increment by 50
Hibernate: create table member (id bigint not null, address varchar(255), nick_name varchar(255), password_hash varchar(255), status enum ('ACTIVE','DEACTIVATED','PENDING'), primary key (id), unique (address))
2026-02-09T21:44:16.147+09:00 INFO 10145 --- [splearn] [ Test worker] j.LocalContainerEntityManagerFactoryBean : Initialized JPA EntityManagerFactory for persistence unit 'default'
2026-02-09T21:44:16.276+09:00 INFO 10145 --- [splearn] [ Test worker] t.s.a.required.MemberRepositoryTest : Started MemberRepositoryTest in 0.878 seconds (process running for 1.221)
Mockito is currently self-attaching to enable the inline-mock-maker. This will no longer work in future releases of the JDK. Please add Mockito as an agent to your build what is described in Mockito's documentation: https://javadoc.io/doc/org.mockito/mockito-core/latest/org/mockito/Mockito.html#0.3
WARNING: A Java agent has been loaded dynamically (/Users/eundms/.gradle/caches/modules-2/files-2.1/net.bytebuddy/byte-buddy-agent/1.15.11/a38b16385e867f59a641330f0362ebe742788ed8/byte-buddy-agent-1.15.11.jar)
WARNING: If a serviceability tool is in use, please run with -XX:+EnableDynamicAgentLoading to hide this warning
WARNING: If a serviceability tool is not in use, please run with -Djdk.instrument.traceUsage for more information
WARNING: Dynamic loading of agents will be disallowed by default in a future release
Hibernate: select next value for member_seq // 첫 번째 save: 시퀀스 값만 가져옴
Hibernate: select next value for member_seq // 두 번째 save: 시퀀스 값만 가져옴

Expecting code to raise a throwable.
java.lang.AssertionError:
Expecting code to raise a throwable.
at tobyspring.splearn.application.required.MemberRepositoryTest.duplicateEmailFail(MemberRepositoryTest.java:38)
at java.base/java.lang.reflect.Method.invoke(Method.java:580)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)
at java.base/java.util.ArrayList.forEach(ArrayList.java:1596)

Hibernate: insert into member (address,nick_name,password_hash,status,id) values (?,?,?,?,?) // 실제 INSERT는 flush/커밋 시점까지 미룸

하지만, 운영에서 동일한 이메일을 두 번 입력하는 코드는 트랜잭션 커밋 시점에 flush 되어 예외가 발생한다

// 운영에서는
memberRepository.save(new Member("a@b.com"));
memberRepository.save(new Member("a@b.com"));
// 트랜잭션 커밋 시점에 flush → DB에서 unique constraint violation!

즉, 다시 설명하자면,

  운영 환경 (트랜잭션 분리)
  서비스 @Transactional 시작
    → save(member1)   -- 시퀀스 조회
    → save(member2)   -- 시퀀스 조회
    → 트랜잭션 커밋 → flush → INSERT 2건 → unique 위반 터짐!

  테스트 환경 (트랜잭션 공유)
  테스트 @Transactional 시작 (= 서비스도 이 트랜잭션에 참여)
    → save(member1)   -- 시퀀스 조회
    → save(member2)   -- 시퀀스 조회
    → 테스트 끝 → 롤백 → flush 안 함 → unique 위반 안 터짐!

  테스트가 트랜잭션을 감싸고 있으니까, 서비스의 @Transactional이 새 트랜잭션을 안 만들고 테스트
  트랜잭션에 합류한다. 그러면 커밋이 영원히 안 일어나고(롤백이니까), flush도 생략될 수 있어서
  운영에서만 터지는 버그를 숨기게 된다.

// 참고로 SEQUENCE 를 예외 터지게 하려면 명시적으로 Flush 해줘야 함

  @Test
  void duplicateEmailFail(){
      Member member = Member.register(createRegisterRequest(), createPasswordEncoder());
      memberRepository.save(member);

      Member member2 = Member.register(createRegisterRequest(), createPasswordEncoder());
      memberRepository.save(member2);

      assertThatThrownBy(() -> entityManager.flush())  // 여기서 실제 INSERT 발생 → 예외
          .isInstanceOf(DataIntegrityViolationException.class);
  }

>>> 실제 운영 환경과 동일한 트랜잭션 경계로 테스트하고 싶을 때는 @Transactional을 빼고 테스트를 진행하자

그렇다면, 테스트 간 데이터를 격리시키는 다른 방법에는 무엇이 있을까?

1) 각 테스트 마다 다른 데이터 사용하기

2) 각 테스트 실행전에 데이터 초기화

언제 해야 할까?

- 각 테스트 시작 전 : @BeforeEach에서 정리

어떻게 초기화해야 할까?

- @Sql / 로직 호출로 각 테스트에 적합한 데이터 입력

- 메타 데이터에서 전체 테이블 목록을 자동으로 조회해서 TRUNCATE하는 클래스를 만들어두고 호출

[테스트] No qualifying bean of type 'tobyspring.splearn.application.required.EmailSender' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}

:해피래빗 — Mon, 9 Feb 2026 19:36:32 +0900

에러 메시지 일부

Caused by: org.springframework.beans.factory.UnsatisfiedDependencyException: Error creating bean with name 'memberService' defined in file [/Users/eundms/IdeaProjects/splearn/build/classes/java/main/tobyspring/splearn/application/MemberService.class]: Unsatisfied dependency expressed through constructor parameter 1: No qualifying bean of type 'tobyspring.splearn.application.required.EmailSender' available: expected at least 1 bean which qualifies as autowire candidate. Dependency annotations: {}

상황

나는 @SpringBootTest를 활용한 테스트를 작성중이다

@SpringBootTest
public class MemberRegisterManualTest {
  @Autowired
  private MemberRegister memberRegister;

  @Test
  void register(){
    Member member = memberRegister.register(MemberFixture.createRegisterRequest());

    assertThat(member.getId()).isNotNull();
    assertThat(member.getStatus()).isEqualTo(MemberStatus.PENDING);
  }
}

아래와 같이 MemberService가 작성되어 있다

@Service
@RequiredArgsConstructor
public class MemberService implements MemberRegister {
  private final MemberRepository memberRepository;
  private final EmailSender emailSender;
  private final PasswordEncoder passwordEncoder;

  @Override
  public Member register(MemberRegisterRequest registerRequest) {
    Member member = Member.register(registerRequest, passwordEncoder);
    memberRepository.save(member);
    emailSender.send(member.getEmail(), "등록을 완료해주세요", "아래 링크를 클릭해서 등록을 완료해주세요");
    return member;
  }
}

에러 메시지 해석

Spring Context에 등록되어 있는 MemberRegister을 가져오는 데,

이 안에서 사용되는 EmailSender, PasswordEncoder가 스프링 빈으로 등록되어 있지 않다 (구현체 없는 인터페이스임)

public interface PasswordEncoder {
    String encode(String password);
    boolean matches(String password, String passwordHash);
}

public interface EmailSender {
  void send(Email email, String subject, String body);
}

해결 시도

- @Bean으로 emailSender, passwordEncoder를 Bean으로 등록한다

- 그리고 MemberTestConfiguration 은 독립된 파일로 존재한다

  @TestConfiguration
  class MemberTestConfiguration {
    @Bean
    public EmailSender emailSender(){
      return (email, subject, body) -> System.out.println("sending email" + email);
    }

    @Bean
    public PasswordEncoder passwordEncoder(){
      return MemberFixture.createPasswordEncoder();
    }
  }

그럼에도 동일한 에러가 난다

왜? @SpringBootTest 가 붙은 MemberRegisterManualTest가 MemberTestConfiguration 을 사용해야 함을 모르기 때문이다

따라서, @Import 로 사용함을 명시한다

@SpringBootTest
@Import(MemberTestConfiguration.class)
public class MemberRegisterManualTest {
  @Autowired
  private MemberRegister memberRegister;

  @Test
  void register(){
    Member member = memberRegister.register(MemberFixture.createRegisterRequest());

    assertThat(member.getId()).isNotNull();
    assertThat(member.getStatus()).isEqualTo(MemberStatus.PENDING);
  }
}

임시로 구현한 DummyEmailSender 와 @TestConfiguration으로 등록한 emailSender 중에 무엇이 우선시 될까?

https://www.inflearn.com/community/questions/1645701/testconfiguration-%EA%B4%80%EB%A0%A8-%EC%84%A4%EB%AA%85%EA%B3%BC-%EC%8B%A4%EC%A0%9C-%EB%8F%99%EC%9E%91%EC%9D%B4-%EB%8B%A4%EB%A5%B8-%EB%B6%80%EB%B6%84%EC%9D%B4-%EC%9E%88%EB%8A%94-%EA%B2%83-%EA%B0%99%EC%8A%B5%EB%8B%88%EB%8B%A4?_gl=1%2A1fsppw%2A_gcl_au%2AMjA1ODQxMTM2MS4xNzY0MDc3MDkxLjEyMjk2NzM3NjAuMTc2OTA4OTY5My4xNzY5MDkwMDYw%2A_ga%2AMjA5MTY0NzUxOC4xNzU1MjIxODA5%2A_ga_85V6SRKGJV%2AczE3NzA2MjkwNjQkbzUxJGcxJHQxNzcwNjQ0ODg2JGo1NSRsMCRoMA..&referrer=inflearn

@TestConfiguration 관련 설명과 실제 동작이 다른 ... - 인프런 | 커뮤니티 질문&답변

누구나 함께하는 인프런 커뮤니티. 모르면 묻고, 해답을 찾아보세요.

www.inflearn.com

히스토리 잘 남기기 : 커밋메시지, 지라, 회의

:해피래빗 — Wed, 4 Feb 2026 21:04:58 +0900

커밋 메시지에 남겨야 할 것들

이 변경이 왜 필요했고, 무엇을 바꿨고, 어떤 맥락(Story/Bug)에서 나왔는가

- 왜 이 변경이 필요했는지

- 무엇이 달라졌는지

버그 Fix 커밋 예시

[지라번호] 현상 명시

- 기대 : 재처리 시 정상 처리된 상품 상태는 유지되어야 함

- 실제 : 재처리 시 모든 상품이 PENDING으로 초기화됨

- 원인 : 처리 이력 초기 생성 로직이 전체 상품을 덮어씀

지라에 남겨야 할 것들

- 요구사항이 바뀐 순간 : AC 변경

- 성공/실패 기준 변경

- QA 판단이 개입된 순간

1) Bug triage 결과

- 재현 안됨

- 우선순위 낮춤

- 운영 영향 없음으로 판단

2) 지금은 안 한다는 결정 : 나중에 한다, 다음 버전, 범위 제외

회의에서 남겨야 할 것들 (결정 로그)

결정(Decision)	이렇게 하기로 했다
변경(Change)	기존 결정에서 바뀐 점
보류(Deferred)	지금은 안 하기로 했다
리스크(Risk)	나중에 문제 될 수 있는 점

장애 발생
↓
최근 배포 커밋 확인
↓
커밋 → 연결된 Bug / Story 확인
↓
Story → AC / 회의 결정 로그 확인
↓
“아, 이 결정 때문에 여기서 터졌구나”