너와 나의 스토리

Spring JPA 트랜잭션 관리 - 낙관적 락, 비관적 락

노는게제일좋아! — Sun, 28 Sep 2025 12:42:21 +0900

Spring JPA Transaction 관리

JPA에서는 보통 @Transactional 어노테이션으로 트랜잭션을 선언적으로 관리한다.

기본적으로 Srping은 AOP 방식으로 메서드를 감싸서, 진입 시 begin, 정상 종료 시 commit, 예외 발생 시 rollback을 수행한다.

예제: 디바이스 조회 -> 점유 상태 변경 -> 디바이스 저장

@Service
public class DeviceService {

    private final DeviceRepository deviceRepository;

    @Transactional
    public void occupyDevice(Long deviceId, Long userId) {
        Device device = deviceRepository.findById(deviceId)
            .orElseThrow(() -> new IllegalArgumentException("존재하지 않는 디바이스"));

        if (device.isOccupied()) {
            throw new IllegalStateException("이미 점유 중");
        }

        device.occupy(userId); // 상태 변경
        deviceRepository.save(device); // flush 시점에 update
    }
}

JPA에서 제공하는 동시성 제어 전략

1) Optimistic Lock (낙관적 락)

충돌이 드물다고 가정하고 동작
엔티티에 버전(@Version)을 두고 업데이트 시점에 버전 비교로 충돌을 감지한다.
- 엔티티의 상태가 변경되어 update가 일어나면 version이 자동으로 증가함.
충돌 발생 시 예외를 던지고 재시도하거나 사용자에게 실패를 알린다.

@Entity
public class Device {
    @Id
    private Long id;

    private Boolean occupied;
    private Long occupiedBy;

    @Version
    private Long version; // JPA/Hibernate가 자동으로 관리

    public void occupy(Long userId) {
        if (Boolean.TRUE.equals(this.occupied)) {
            throw new IllegalStateException("이미 점유중");
        }
        this.occupied = true;
        this.occupiedBy = userId;
    }
}

@Service
public class DeviceService {
    private final DeviceRepository repo;

    public void occupyWithRetry(Long deviceId, Long userId) {
        final int maxAttempts = 3;
        for (int attempt = 1; attempt <= maxAttempts; attempt++) {
            try {
                tryOccupy(deviceId, userId); // 트랜잭션 단위 시도
                return;
            } catch (ObjectOptimisticLockingFailureException | OptimisticLockException e) {
                if (attempt == maxAttempts) throw new ConcurrentModificationException("동시성 충돌 — 재시도 초과");
                // 짧은 backoff
                try { Thread.sleep(100L * attempt); } catch (InterruptedException ignored) {}
            }
        }
    }

    @Transactional
    protected void tryOccupy(Long deviceId, Long userId) {
        Device d = repo.findById(deviceId).orElseThrow();
        if (Boolean.TRUE.equals(d.getOccupied())) throw new IllegalStateException("이미 점유중");
        d.occupy(userId);
        repo.saveAndFlush(d);
    }
}

시나리오
1. T1과 T2가 동시에 device(버전=1)를 읽음.
2. T1이 점유 후 commit → DB 업데이트, 버전 = 2.
3. T2가 점유하려고 저장 시도 → 업데이트문이 WHERE id=? AND version=1로 동작 → 영향된 row가 0이면 JPA가 OptimisticLockException 발생.
4. T2는 예외를 받아 재시도 로직을 실행하거나 사용자에 실패를 반환.
장단점
- 장점: 락을 걸지 않으므로 읽기 성능 유리, 확장성 좋음
- 단점: 충돌이 잦으면 재시도로 효율 저하

2) Pessimistic Lock (비관적 락)

충돌을 미리 막는다.
DB 수준에서 해당 row를 SELECT ... FOR UPDATE처럼 잠궈서 다른 트랜잭션의 접근을 미리 차단(블락킹)
충돌 가능성이 높은 경우 사용함.

public interface DeviceRepository extends JpaRepository<Device, Long> {

    @Lock(LockModeType.PESSIMISTIC_WRITE)
    @Query("SELECT d FROM Device d WHERE d.id = :id")
    @QueryHints({@QueryHint(name = "javax.persistence.lock.timeout", value = "3000")})
    Device findByIdForUpdate(@Param("id") Long id);
}

@Transactional
public void occupyPessimistic(Long deviceId, Long userId) {
    try {
        Device d = repo.findByIdForUpdate(deviceId); // DB에서 FOR UPDATE (잠금)
        if (Boolean.TRUE.equals(d.getOccupied())) throw new IllegalStateException("이미 점유중");
        d.occupy(userId);
        repo.save(d);
    } catch (LockTimeoutException | PessimisticLockException e) {
        // 잠금 획득 실패 -> 재시도 혹은 사용자에게 알림
        throw new IllegalStateException("다른 요청이 처리 중입니다. 잠시 후 다시 시도하세요.");
    }
}

시나리오
1. T1이 SELECT ... FOR UPDATE로 row 잠금 획득.
2. T2가 같은 row를 SELECT ... FOR UPDATE하려 하면 블록되거나(lock timeout 설정 시) 즉시 실패.
3. T1이 commit/rollback을 하면 잠금 해제 → T2가 진행.
장단점
- 장점: 충돌을 미연에 차단하여 절대적으로 한 번에 한 명만 수행되도록 보장
- 단점: 락 경함시 성능 저하&데드락 위험, 트랜잭션 짧게 유지해야함.

[SpringBoot] JPA 양뱡향 매핑은 불필요한 것인가? Fetch 전략과 N+1 문제

노는게제일좋아! — Sat, 27 Sep 2025 09:48:13 +0900

본 포스팅은 "[NHN Cloud 2019] Spring JPA의 사실과 오해" 강연 내용을 정리한 글입니다.

연관관계 매핑 - 단방향 vs 양방향

사실상 단방향 매핑만으로 연관관계 매핑은 이미 완료
- 어차피 연관관계 매핑은 내부적으로 foreign key를 이용하게 되는데, foreign key는 결국 하나이기 때문에
양방향 매핑은 양쪽에서 서로에 대한 설정을 해줘야 하기 때문에 복잡해짐.
- 그에 비해 반대쪽 방향으로 객체 그래프 탐색 기능 추가된 게 유일한 이점임.
결론
- 대개의 경우 단방향 매핑이면 충분하다
- 우선은 단방향 매핑을 사용하고 반대 방향으로의 객체 그래프 탐색이 필요할 때 양방향을 사용

다대일(N:1) 단방향 연관관계 매핑

@Entity
public class Member {
    @Id
    @Column(name ="member_id")
    private Long memberId;
    
    ...   
}


@Entity
public class MemberDetail {
    @Id
    @Column(name ="member_detail_id")
    private Long memberDetailId;
    
    @ManyToOne(cascade = CascadeType.ALL)
    @JoinColumn(name = "member_id")
    private Member member;
    
    ...
}

Cascade: 영속성 전이

Entity의 영속성 상태 변화를 연관된 Entity에도 함께 적용하는 것
Cascade Type
- PERSIST
  - Entity를 영속 객체로 추가할 때 연관된 Entity도 함께 영속 객체로 추가한다.
- REMOVE
  - Entity를 삭제할 때 연관된 Entity도 함께 삭제한다.
- DETACH
  - Entity를 영속성 컨텍스트에서 분리할 때 연관된 Entity도 함께 분리 상태로 만든다.
- REFRESH
  - Entity를 데이터베이스에서 다시 읽어올 때 연관된 Entity도 함께 다시 읽어온다.
- MERGE
  - Entity를 준영속 상태에서 다시 영속 상태로 변경할 때 연관된 Entity도 함께 변경한다.
- ALL
  - 모든 상태 변화에 대해 연관된 Entity에 함께 적용한다.

Case1: 연속성 전이를 통한 insert

@Transactional
public void createMemberWithDetails() {
    Member member = new Member("member1", LocalDateTime.now());
    
    MemberDetail memberDetail1 = new MemberDetail(member, "type1", "description1");
    MemberDetail memberDetail2 = new MemberDetail(member, "type2", "description2");

    membserDetailRepository.saveall(Arrays.asList(memberDetail1, memberDetail2));
}

실제 수행 결과
- members 테이블에 member INSERT
- member_details 테이블에 member_details1 INSERT
- member_details 테이블에 member_details2 INSERT

일대다(1:N) 단방향 연관관계 매핑

@Entity
public class Member {
    @Id
    @Column(name ="member_id")
    private Long memberId;
    
    @OneToMany(casecade = CascadeType.ALL)
    @JoinColumn(name = "member_id")
    private List<MemberDetail> details;
    
    ...   
}


@Entity
public class MemberDetail {
    @Id
    @Column(name ="member_detail_id")
    private Long memberDetailId;
 
    ...
}

Case2: 연속성 전이를 통한 insert

@Transactional
public void createMemberWithDetails() {
    Member member = new Member("member1", LocalDateTime.now());
    Member savedMember = memberRepository.save(member);
    
    MemberDetail memberDetail1 = new MemberDetail(member, "type1", "description1");
    MemberDetail memberDetail2 = new MemberDetail(member, "type2", "description2");

    member.getDetails().add(memberDetail1);
    member.getDetails().add(memberDetail2);
}

실제 수행 결과
- members 테이블에 member INSERT
- member_details 테이블에 member_details1 INSERT
- member_details 테이블에 member_details2 INSERT
- member_details 테이블에서 member_id UPDATE
- member_details 테이블에서 member_id UPDATE
추가적으로 업데이트 쿼리가 추가됨
즉, 일대다(1:N) 단방향 연관관계 매핑에서 연속성 전이를 통해 insert를 하게 되면
- 일대다 관계의 외래 키(FK) 지정을 위해 추가적인 update 쿼리가 발생하는 문제가 생김
- 이 경우에는 오히려 일대다 양방향 연관관계로 변경하면 추가적인 update 쿼리가 없어짐.

일대다(1:N) 양방향 매핑

@Entity
public class Member {
    @Id
    @Column(name ="member_id")
    private Long memberId;
    
    @OneToMany(casecade = CascadeType.ALL, mappedBy = "member")
    private List<MemberDetail> details;
    
    ...   
}


@Entity
public class MemberDetail {
    @EmbeddedId
    private PK pk;
    
    private String description;
    
    @ManyToOne
    @MapsId("memberId")  // 복합키의 memberId를 member 연관관계와 매핑 -> pk.memberId와 member.memberId는 항상 동일한 값이 됨.
    private Member member;
    
    @Embeddable
    public static class Pk implements Serializable {
    	@Column(name = "member_id")
        private Long memberId;
        
        private String type;
    }
    ...
}

양방향으로 설정하는 경우, 연관관계의 주인을 설정하는 게 중요하다. 내부적으로는 FK를 사용하기 때문이다.
결과적으로 FK를 가지고 있는쪽이 연관관계의 주인이 된다.
예제에서 보면 MemberDetail에서 MapsId
- Member는 연관관계의 주인이 아니기 때문에 join column을 쓰면 안 된다.
- @JoinColumn: 이 필드가 FK임을 명시.
- mappedBy: "나는 주인이 아니다"라는 선언
- @MapsId: 자식 엔티티의 PK와 FK를 공유할 때 사용
즉, member_detail의 PK는 (member_id, type) 복합키이고, 그 중 member_id는 member 테이블의 FK 역할을 동시에 한다.
이렇게 구현 후, 아까 예제를 수행하면, 업데이트 쿼리가 추가적으로 발생하지 않게 된다.

그렇다면 항상 ManyToOne 단방향만 쓰는 게 정답일까?

상황	추천 방식
대부분 MemberDetail 중심으로 접근하고, Member에서 details를 잘 안 쓰는 경우	ManyToOne 단방향
Member에서 details를 자주 조회해야하는 경우	양방향 (mappedBy 설정)
OneToMany 단방향	비추 (쿼리 비효율적)

FK는 항상 "다"쪽(@ManyToOne)에서 관리하는 게 정석이고, "일"쪽(@OneToMany)는 필요할 때만 컬렉션으로 접근할 수 있게 양방향을 열어주는 게 가장 실용적이다.

Fetch 전략

전략
- FetchType.EAGER
  - 하나의 entity를 가져올 때, 연관관계에 있는 entity를 즉시 가져오는 것
  - @OneToOne, @ManyToOne
- FetchType.LAZY
  - 실제 참조가 이뤄졌을 때 연관관계에 있는 entity 값을 가져오는 것
  - @OneToMany, @ManyToMany

N+1 문제

연관된 entity를 가지고 올 때, 우리가 의도한 것과 달리 추가적으로 쿼리를 N번 추가적으로 수행하는 문제
해결 방법
- Fetch Join
- Entity Graph

오해1: N+1 문제는 EAGER Fetch 전략 때문에 발생하는가?

Fetch 전략을 LAZY로 설정했더라도 연관 Entity를 참조하면 그 순간 추가적인 쿼리가 수행됨.
Fetch 전략은 시점 차이지, 똑같이 문제 발생.

오해2: findAll() 메서드 N+1 문제가 발생하지 않는가?

fetch 전략을 적용해서 연관 entity를 가져오는 것은 오직 단일 레코드에서만 적용
단일 레코드 조회가 아닌 경우 해당 JPQL을 먼저 수행하고 반환된 레코드 하나 하나에 대해 entity에 설정된 fetch 전략을 적용해서 연관 entity 가져옴.
- 예를 들어, findAll()로 Member 목록을 가져온 직후, JPA는 단순히 Member 객체들만 영속성 컨텍스트에 올린다.
- 이후, member.getDetails()를 호출하면 그때, fetch 전략을 수행함.
- 즉, 연관 entity를 조회하는 시점에서 결국 N+1이 발생.
그렇기 때문에 findAll() 메서드 호출도 역시 이 과정에서 N+1 문제 발생 가능

N+1 해결을 위해 Fetch Join 사용

흔히 하는 실수 1: Pagination + Fetch JOIN
- Pagination 쿼리에 Fetch Join을 적용하면 실제로는 모든 레코드르 가져와서 조인한 후에 Pagination처리가 됨.
- 즉, 분리해서 실행해야한다.

멀티모달 RAG 시스템 - 임베딩/인코딩/fusion

노는게제일좋아! — Mon, 4 Aug 2025 15:21:52 +0900

출처: https://fastcampus.co.kr/data_red_ragmaster

멀티 모달 RAG 시스템

멀티모달 RAG: 여러 형태의 데이터를 검색해 생성 AI에 연결하여 답변 개선
예: ChatGPT에 이미지를 보여주거나 음성으로 질문하는 다중모달 인터페이스 등장

Embedding

데이터(단어, 문장 등)의 의미를 보존하는 벡터 표현
유사한 의미의 데이터는 벡터 공간에서 가까운 위치에 맵핑됨
임베딩은 텍스트 외 이미지, 오디오 등에도 적용 가능

텍스트 임베딩 vs 이미지 임베딩 vs 멀티모달 임베딩

텍스트 임베딩	단어/문장의 언어적 의미를 벡터로 표현 (자연어 의미 공간)
이미지 임베딩	픽셀 데이터의 시각적 패턴을 벡터로 표현(훈련 데이터에 따라 의미적 특징 일부 반영)
멀티모달 임베딩	서로 다른 모달의 데이터(예: 이미지, 텍스트 등)를 공통 공간에 매핑하여 교차검색 가능 (ex: CLIP 모델)

두 가지 모달리티를 연결한 bimodal 모델(CLIP, ALIGN 등)이 등장하면서, 서로 다른 형태의 데이터라도 같은 벡터 공간에서 유사도 계산이 가능해짐
멀티모달 임베딩 예: "캠핑카"라고 입력하면 캠핑카 관련 책(텍스트)도 찾아오고, 관련 이미지도 찾아옴.
- 텍스트 데이터와 이미지 데이터를 같은 공간에 임베딩했기 때문
더 나아가 Meta의 ImageBind처럼 여러 모달(이미지, 오디오, 텍스트, 센서데이터 등)까지 한꺼번에 임베딩하는 다중모달 모델도 연구중

멀티 모달 모델 정리

CLIP(Contrastive Language-Image Pre-training)
- OpenAI에서 개발한 몰티모달 모델로, 텍스트와 이미지를 공통 임베딩 공간에서 연결하는 방식으로 학습된 모델이다.
- Contrastive Learning(대조 학습)을 사용하여 이미지-텍스트 쌍을 가까이 또는, 잘못된 쌍을 멀리 두는 형식으로 학습
Align
- Google에서 개발
- CLIP과 유사한 방식으로 이미지-텍스트 정렬
- 데이터셋 규모가 훨씬 큼
ImageBind
- Meta에서 개발
- 6개 모달리티(텍스트, 이미지, 오디오, 비디오, IMU 센서, 깊이 데이터) 하나의 벡터 공간으로 매핑.
BLIP / BLIP-2
- 멀티모달 rag에서 자주 쓰이는 모델 (텍스트-이미지 질의응답)

멀티 모달 데이터를 효과적으로 저장하는 법

멀티모달 검색 시스템에서는 각 데이터 유형에 맞는 전처리 및 임베딩 기법이 필요
- 예: OCR, 음성, 영상 데이터 임베딩
- 텍스트 기반 이미지의 경우, OCR(광학 문자 인식)로 텍스트를 추출하여 텍스트 임베딩으로 변환
  - 이미지를 텍스트로 정규화하면 더 효율적
- 음성 오디오의 경우, ASR(자동 음성 인식)로 텍스트로 변환하거나, 음향 자체의 특징 임베딩 사용
  - 가사가 별로 없는 노래같은 경우는 음성 인식이 의미 없기 때문에, 이런 경우 음향 자체의 특징을 이용해 임베딩해아함.
- 동영상의 경우, 프레임별 이미지 임베딩 + 자막/음성 텍스트 임베딩 등 복합 활용

메타데이터 관리: 연결 및 필터링

목적
- 데이터 컨텍스트 정보(출처, 유형, 시간 등) 저장 및 관리
연결 (Linking)
- 임베딩과 원본 데이터(객체 저장소 등) 및 관련 데이터 연결
필터링 (Filtering)
- 메타데이터 기준 사전/사후 필터링으로 검색 정확도 및 효율성 향상
저장 옵션
- 벡터 DB 내, 또는 별도 메타데이터 저장소(RDB, Document DB, Graph DB)
예: 엄마한테 전화로 혼난 적이 있다.
- 메타 데이터로, 전화 정보(통화 시간, 연락처 등)와 원본 음성 녹음, 요약 내용(엄마한테 혼남)을 링킹해서 저장

하이브리드 저장 아키텍처

벡터 db에 모든 걸 저장하는 건 비효율 적임. 그래서 메타데이터는 RDB 등에 저장해서 먼저 필터링한 후, 벡터 db에서 조회하는 게 효율적.
벡터 db 등을 활용하여 임베딩 벡터와 원본 데이터 식별자를 함께 저장

검색 아키텍처

듀어 인코더 (Dual-Encoder / Bi-Encoder)

쿼리와 문서를 각각 독립적인 인코더로 임베딩하고(같은 공간에 임베딩) 벡터 유사도로 매칭하는 방식
쿼리와 문서의 임베딩을 사전에 계산 가능하다 (특히 문서 쪽)
- 예: 소개팅 앱에서 일단 나이, 사는 곳, 종교 등 기본적인 정보로 상대방 필터링 -> 이런 정보들을 미리 계산해둠.
검색 속도가 빠르고, 데이터 용량이 클 때 스케일링하기 좋음.
결론: 대규모 데이터에서 빠른 1차 검색 (멀티모달 검색 핵심)

크로스 인코더

쿼리와 문서를 하나의 입력으로 합쳐서 모델에 넣고, 점수를 계산하는 방식
- 예: 직접 나가서 상대방 한 명 한 명 다 만나보는 것. 정확하지만 느리고 비용이 많이 듦
- 결론: Re-ranking 단계에서 정확도 향상 (비용 비쌈)
- 모든 쿼리-문서 조합을 모델에 넣어야 해서 대규모 데이터에서는 비효율적

멀티모달 데이터 효과적으로 검색하기

이미지나 오디오를 의미 수준으로 이해해서 사용자의 텍스트 쿼리랑 연결을 해야함.
주로 1차 검색 후 재순위화(re-ranking) 단계에서 rag를 사용함.

Re-Ranking 과정

쿼리 입력 → Dual Encoder로 빠른 검색 → top N 문서 추출
Re-ranking 단계:
- Cross Encoder 사용 → 쿼리와 각 문서를 하나의 입력으로 합쳐서 모델에 넣고, relevance score 계산
- score 순으로 다시 정렬 → 최종 top-k 결과 반환

데이터 융합(Fusion) 메커니즘

초기 융합 (Early Fusion)
- 저 데이터를 다른 모달리티 데이터 예를 들어, 텍스트랑 이미지가 있을 때, 텍스트랑 이미지를 모델 입력 전에 하나로 합치는 것.
- 저수준(픽셀 값이나 주파수 등 ) 데이터가 한 번에 모델에 들어가서, 모델이 처음부터 숨겨진 패턴을 발견할 수 있게 됨.
- 대신, 합치는 과정에서 어떤 부분의 텍스트가 어떤 부분의 이미지나, 어떤 순간의 오디오와 합쳐져야하는지를 알아야함.
  - 이렇게 맞추는 과정을 정렬이라고 함.
  - 자동 정렬이 어렵고 까다로운 과정임
후기 융합 (Late Fusion)
- 텍스트 전문 모델한테 뭐 찾아오라고 하고, 이미지 전문 모델한테 뭐 찾아오라고 하고, 데이터를 각각 찾아온 다음에 합치는 것.
- 장점:
  - 기존 단일 모달을 활용할 수 있고, 단일 모달에서 데이터 찾는 것을 잘함.
  - 데이터가 좀 누락되어도 괜찮.
  - 양식별 최적화 가능
- 단점:
  - 데이터간의 상호작용 손실
중간 융합 (intermediate / Hybrid Fusion)
- 데이터를 중간 계층에서 융합하는 것.
- 초기 융합과 후기 융합의 장점을 다 가져오는 대신, 설계가 어렵고 비용이 비쌈
- 예: 붉은 노을이 있는 해변에 소녀가 있는 사진을 찾으려고 함.
  - 텍스트로 "소녀가 해변에 앉아있었다"를 입력해서 데이터 찾아옴.
  - 이미지로 "붉은 노을이 지고 있는 사진"을 입력해서 데이터 찾아옴.
  - 둘을 따로 처리하다가 중간 지점에서 "소녀랑 해변"이라는 의미를 합쳐서 연관성을 포착한다.
- 중간 어디서 결합할 건지를 결정해야함.
- 이미지 한 장이랑 텍스트 한 문장을 비교하려고 해도, 이미지의 모든 픽셀 위치랑 텍스트의 모든 단어 쌍마다 매칭을 해야한다고 함.

중간 융합은 너무 복잡해서 특수한 경우 아니면 못 쓴다고 생각
그냥 초기 또는 후기 융합 선택하라.

멀티모달 RAG 구현을 위한 아키텍처 접근 방식

문서를 여러 타입으로 분리 - 이미지, 테이블, 텍스트
LLM을 이용해 각각의 데이터를 요약
원본 데이터 링크랑 같이 각 데이터 타입을 벡터 저장

이렇게 저장한 데이터를 검색할 때, 원본 이미지 검색, 요약 이미지 또는 요약된 이미지와 원본 데이터 전달 등 옵션을 선택할 수 있다.

최신 동향 및 미래 전망

고급 융합 기술
- gpt가 원래는 텍스트 기반이었다가, 요즘은 이미지도 잘 생산하고, code interpreter도 말하지 따로 않아도 잘 해줌
End-to-End 최적화
- 검색기로부터 추출한 데이터와 llm에게 전달하는 간극 해소.
에이전틱 RAG
- 동적 쿼리 분해

멀티모달 검색 시스템에서 자주 발생하는 문제 해결

문제 1: 모달리티 간 임베딩 불일치 문제

서로 다른 모달 데이터 간 의미 연결이 어려움
이미지와 텍스트 설명이 어울리지 않거나, 음성 내용과 자막 임베딩 불일치
크로스모달 검색 시 원하는 결과 미검색 또는 무관한 결과 매칭

해결 1: 임베딩 정합성 향상 방안

공통 모델 활용 (ex: CLIP)으로 임베딩 정렬
도메인 데이터로 파인튜닝
이미지나 음성도 텍스트 설명으로 변환한 후 텍스트 임베딩으로 통일

데이터가 크면 벡터 유사도 계산이 오래걸려서 실시간 검색이 어려움
-> 차원 축소해서 빨리 처리하도록 하면 됨

의학 데이터, 동물 소리처럼 특정 도메인에 맞게 파인튜닝하는 게 나음.

잡음은 노이즈 제거하고
사투리가 너무 심하거나, 글씨체가 안 좋은 경우, 일단 ocr 거친 다음에 언어 모델한테 한 번 더 이 텍스트 읽어보고 정상적인지 물어보고, 고칠부분 있으면 고치라고 하기

정확성 판단은 결국 사람 눈으로 판단하는 게 정확.

ui상 모달별 결과 분리 -> 이미지 별로, 텍스트 별로, 비디오 별로 나눠서 보여주는 것
- 서로 다른 모달 결과를 함께 정렬 및 표시하는 게 어렵기 때문에

새로운 데이터가 계속 유입되기 때문에 데이터 파이프라인이랑 자동화가 중요
새로운 지표를 계속 모니터링하면서 갱신해야함.
임베딩 모델 교체는 굉장히 조심스럽게 결정해야함.
- 언어 모델은 쉽게 바꿔도 임베딩 모델 한 번 바꾸면 벡터 부분이 전부 다 바뀌므로 신중해야함.

데이터에 개인 정보가 포함될 수 있으므로 데이터에 접근 제어 및 암호화해야함.
예: 부동산 사진이 사람 얼굴이 들어갈 수도 있음

같은 업계라고해도, 병원만해도 피검사, ct 검사 등을 분석하는 모델이 다르듯, 획일적 솔루션으로는 모든 요구 충족이 어렵기 때문에 모듈식 시스템으로 유연한 커스터마이징을 해야함.
도메인 전문가가 라벨링하도록 해야함.
- 예: 정형외과 의사가 엑스레이 사진 라벨링

멀티 모달 코드 샘플

[요즘 우아한 AI 개발] Part 3 내용 및 용어 정리

노는게제일좋아! — Wed, 9 Jul 2025 13:58:54 +0900

LLM 기반 ReAct 방법

LLM 기반의 프롬프트 설계 기법.
모델이 추론(Reasoning)과 행동(Action)을 반복하며 문제를 해결하도록 설계된 방식.
주로 지식 기반 시스템이나 에이전트 설계에서 사용되며, 모델이 논리적으로 문제를 해결하는 동시에 외부 도구(예: 검색기, 계산기 등)를 활용해 최적의 답을 도출할 수 있도록 한다.
LLM 기반 ReAct 방법은 다양한 벤치마크에서 모방 학습과 강화 학습에 비해 더 높은 답변 성능을 보여준다고 한다.

ReAct 방법

ReAct 방법은 문제 해결 과정을 위한 순차적 추론 단계(chain-of-thought, COT)와 특정 작업 수행을 위한 도구 또는 행동으로 나뉜다.

라고스(Regas)

RAG 파이프라인을 평가하는 프레임워크.
외부 데이터를 사용해 LLM의 컨텍스트를 확장하는 응용 프로그램을 평가하는 데 필요한 다양한 평가 지표를 제공.

폴라스로 데이터 처리를 더 빠르고 가볍게

Apache Spark

대규모 데이터 처리를 위한 분산 컴퓨팅 프레임워크로, 빠르고 확장 가능한 데이터 처리 및 분석을 지원한다.
스파크는 메모리 내에서 데이터를 처리하여 기존의 하둡(MapReduce)보다 훨씬 빠르게 데이터를 처리할 수 있으며, 데이터 스트리밍, 머신러닝, 그래프 분석 등 다양한 기능을 제공한다.

Trio

분산 SQL 쿼리 엔진으로, 여러 데이터 소스에서 데이터를 통합하여 실시간으로 쿼리할 수 있는 기능을 제공한다.
원래 PrestoSQL로 알려져 있었으며, 다양한 데이터베이스나 데이터 레이크에 걸쳐 효율적인 분석을 수행할 수 있는 오픈 소스 도구이다.

S3(아마존 Simple Storage Service)

AWS에서 제공하는 확정성 높은 객체 스토리지 서비스.
S3는 데이터를 파일 형태로 저장하며, 무제한의 데이터 저장을 지원하고 안정적인 백업, 데이터 아카이빙, 웹 애플리케이션 호스팅 등의 용도로 사용된다.

-> 대용량 분산 처리가 필요한 부분은 트리노나 스파크 기반 SQL을 사용해 1차 전처리를 하고, 이를 테이블 형태 또는 S3 내에 파일 형태로 저장한다.

폴라스 등장 배경

스파크의 문제점
- 대용량 데이터가 아닐 때는 오히려 오버헤드 발생(슬로우 스타트 문제)
- 비용 효율성이 낮다(비싼 리소스)
- 러닝 커브 존재
즉 데이터를 분석하고 처리하는 데에 있어 판다스는 너무 느리고 무겁고, 스파크는 과함.
원하는 것
- 로컬 환경에서도 편하게 개발 및 테스트가 가능
- 별다른 인프라 필요 없음
- 성능 좋고, 러닝 커브 적은 것
- 아파치 에어플로 환경 또는 컨테이너 기반으로 잘 패키징해서 운영 데이터 파이프라인에서 문제없이 돌릴 수 있는 것

Polars

빠르고 효율적인 데이터 프레임 라이브러리.
특히 대용량 데이터를 처리하는 데 최적화된 성능을 제공한다.
Rust로 작성된 폴라스는 판다스와 비슷한 기능을 제공하지만, 멀티스레딩을 활용해 더 빠른 연산 속도를 자랑하며, 메모리 효율성을 극대화합니다.
- 안전한 동시성과 병렬 처리 가능
- 메모리 캐싱과 재사용성 높음
판다스의 대안으로 주목받고 있으며, 특히 데이터 크기가 클수록 성능 차이가 두드러진다.

아파치 애로우(Apache Arrow) 모델

대규모 데이터를 효율적으로 처리하기 위한 칼람 기반 인메모리 형식으로, CPU 캐시 효율을 극대화하고 벡터화 연산을 지원한다.
이를 통해 다양한 시스템과 언어 간 데이터 공유를 빠르게 메모리 복사 없이 할 수 있다.

SIMD(Single Instruction, Mltiple Data)

단일 명령어로 여러 데이터를 동시에 처리하는 컴퓨터 아키텍처.
주로 벡터 연산에서 사용되며, 같은 연산을 여러 데이터에 병렬로 수행함으로써 처리 성능을 크게 향상시킨다.

Zero-copy

데이터를 복사하지 않고, 동일한 메모리 공간을 여러 프로세스나 시스템이 공유하여 직접 접근하는 방식.

출처

- [요즘 우아한 AI 개발]

[요즘 우아한 AI 개발] Part 2 프롬프트 엔지니어링

노는게제일좋아! — Wed, 2 Jul 2025 14:37:40 +0900

Part 2 - AI로 더 편리한 서비스 만들기

배민 검색

이제 "치킨"같은 음식 이름뿐만 아니라 "금요일", "매운", "해장음식" 등 키워드를 넣어도 추천해줌

프롬프트 엔지니어링

구체적인 프롬프트 작성

상황과 형식을 명확하게 제시
- 예: "첨부한 문서를 요약해주세요" -> "첨부한 회의록을 3가지 핵심 사항으로 요약하고 마크다운 형식으로 정리해주세요."
- 예: "저화질인지 판단하세요" -> "이미지 내부의 주요한 객체가 선명하지 않거나 화질이 깨졌는지 판단하세요."

프롬프트 일반화

프롬프트를 너무 구체화하면 예외 케이스를 놓칠 수 있다.
- 예: "워터마크처럼 합성된 글씨가 있는지 판단하세요"
- 워터마크는 잘 잡지만, 다른 합성 텍스트는 놓칠 수 있다.
- -> "워터마크와 같이 인위적으로 합성된 글씨가 있는지 판단하세요."

응답 최적화

구조화된 응답 유도
- 응답을 JSON 형식으로 포매팅하여 반환하도록 적용
생성 지식 프롬프트(Generated Knowledge Prompting)
- LLM이 자체적으로 생성한 지식을 활용하여 특정 질문에 대한 응답을 강화하거나 보완하는 프롬프트 설꼐 기법. 모델이 학습 데이터 외부의 지식을 포함한 질문에 답변할 때 활용된다.
- 이는 생각의 사슬(Chain of Thought, CoT)와 유사한 방식
  - 예: GPT가 이미지 내부의 모습 설명을 생성하고, 이 설명을 바탕으로 최종 응답을 도출하도록 하는 방법
  - 이렇게하면 응답의 일관성이 약 40% 향상됨
Latency 최적화
- input 프롬프트 최적화도 필요하지만, 불필요한 응답을 줄이는 것이 훨씬 중요하다.
- 예: 응답 사유를 한 문장으로만 반환하도록 하기

프롬프트 구조와 형식 개선

이미지와 테스트 순서
- 이미지와 텍스트를 함께 사용할 때는 이미지를 텍스트 프롬프트보다 먼저 배치하는 것이 도움된다. -> 응답 정확도 향상
마크다운과 코드 스타일 활용
- 텍스트 프롬프트를 구조화하기 위해 마크다운 형식을 활용
- 중요한 내용을 강조하기 위해 헤더(#)를 사용해 섹션을 구분
- 여러 정보나 정책 항목을 나열할 때는 목록 형태로 표시
- 프롬프트의 전체적인 구조를 코드 스타일로 정리(파이썬의 딕셔너리같은 데이터 구조로)

# instructions = '이미지를 정책(policies)에 따라 분석하고 지정된 JSON 형식으로 결과를 반환하세요.'
# policies = { 
	1: '주요한 음식에 초점이 맞지 않습니다.', 
	2: '해상도가 낮아서 픽셀단위로 질감이 보입니다.'
	# (생략) 
}

GPT 한계 극복: 하이브리드 접근의 필요성

이미지 속 객체 인식 잘 못 함 -> 정확한 객체 탐지 및 좌표 반환을 못 함
- gpt 파인 튜닝: https://openai.com/index/introducing-vision-to-the-fine-tuning-api/
저작권/상표권/초상권 등 이미지 속에 포함된 캐릭터나 로고에 저작권 문제 없는지 판단 못 함 -> 최신 캐릭터에 대한 정보를 몰라서

실시간 반응형 추천 시스템

어떻게 하면 짜장면을 먹고 싶은 사용자에게 중식 가게를, 아이스 아메리카노가 갑자기 당기는 사용자에게 카페를 추천할 수 있을까?

3 가지 컴포넌트를 개발
1. 실시간 행동 이력 스트리밍
2. 인코더 모델 학습 및 임베딩 추출
3. 벡터 유사도 검색 (Vector Similarity Search, VSS)

컴포넌트 1: 실시간 행동 이력 스트리밍

사용자가 클릭한 가게나 검색한 검색어 등의 행동 이력을 실시간으로 스트리밍해 몽고디비에 적재
실시간 행동 이력 조회 API를 통해 몽고디비에 적재된 사용자의 행동 이력을 조회
Apache Flink + Amazon EKS(Elastic Kubernetes Service)로 실시간 로그 파이프라인 구축

컴포넌트 2: 인코더 모델 학습 및 임베딩 추출

가게와 검색어를 같은 벡터 공간에 임베딩 형태로 표현하는 인코더 모델을 개발
가게의 메타 정보와 검색 로그 등을 활용해 가게와 검색어가 유사할수록 더 가까운 벡터 공간에 위치시키는 인코더 모델을 학습시킴.
학습된 인코더 모델로 가게 및 검색어의 임베딩을 추출하고, 이를 VSS 컴포넌트가 사용하는 VectorDB에 업로드

컴포넌트 3: 벡터 유사도 검색

사용자의 행동 이력과 추천 후보 가게 간의 유사도를 계산
사용자의 행동 이력과 추천 후보 가게 목록이 주어졌을 때 벡터디비에서 각 임베딩 값을 조회한 후, 이들 사이의 코사인 유사도를 계산해 응답하는 컴포넌트를 개발.
여기서는 AWS RDS PostgreSQL을 벡터디비로 사용.

벡터 유사도 검색

Exact-KNN(K-Nearest Neighbor)
- 임베딩 벡터 공간 내의 좌표 간 거리를 정확하게 계산하는 것
ANN(Approximate Nearest Neighbor)
- recall(재현율)을 합리적으로 희생하면서도 검색 성능을 올리는 알고리즘
- Exact-KNN보다 많이 쓰임
- IVFFlat이나 HNSW 같은 알고리즘이 이 예다.
- ANN 알고리즘은 미리 인덱스를 빌드해놓고, 검색 시점에서는 인덱스를 통해 성능을 향상시키는 방식의 알고리즘이다.
고려 사항
- 검색 대상 후보군을 좁힌 다음에 이 후보군에 대해서만 벡터 유사도 검색을 진행하면 인덱스 빌드 시점에 전체를 대상으로 만든 인덱스를 활용하기 어렵다.
HNSW 알고리즘에서 보는 pre filter의 문제
- HNSW는 일종의 그래프를 활용하여 가까운 검색 대상을 효율적으로 찾는 알고리즘이다.
- 모든 연결 그래프를 다 탐색하면 시간이 걸리니, 미리 검색에 사용할 밀도를 낮춘 그래프를 레이어 기반으로 인덱스 빌드 시점에 만들어둔다.
- ANN의 성능 개선은 대체로, 검색 전에 데이터를 기준으로 미리 인덱스를 만들고, 검색 시점에 인덱스를 사용하는 데서 나온다. 우리의 프리 필터 문제는 좁혀둔 후보군에 대응하는 인덱스가 없기 때문에 ANN을 사용할 수 없다.

기억에 남는 내용

벡터 유사도 검색에서 pre filter 문제

출처

- [요즘 우아한 AI 개발]

SSE(Server-Sent Events)란? WebSocket과의 차이

노는게제일좋아! — Tue, 10 Jun 2025 16:35:25 +0900

WebSocket

웹소켓은 단일 TCP 연결로 동시양방향통신 채널을 제공하는 컴퓨터 통신 프로토콜

SSE(Server-Sent Events)

SSE는 클라이언트(주로 브라우저)가 서버로부터 단방향 실시간 데이터를 스트리밍 방식으로 수신할 수 있게 해주는 기술이다.

WebSocket과 달리 양방향 통신이 아닌, 서버 -> 클라이언트 방향으로만 데이터를 전송한다.
주로 뉴스 속보, 주식 가격, 채팅 알림 등의 실시간 알림 시스템에 사용된다.

SSE 동작 방식

클라이언트가 text/event-stream 헤더로 서버에 요청
서버는 해당 요청을 끊지 않고, 스트리밍 방식으로 데이터를 지속적으로 전송 (HTTP 연결을 장시간 유지)
클라이언트는 전송받은 데이터를 이벤트로 처리

GET /events HTTP/1.1
Accept: text/event-stream

서버 응답:

data: Hello\n\n
data: Another message\n\n

JavaScript에서 처리 방식

const evtSource = new EventSource("/events");

evtSource.onmessage = function(event) {
  console.log("New event:", event.data);
};

고려 사항

SSE는 클라이언트가 자동으로 재연결을 시도하며, 이전 이벤트의 ID를 HTTP 헤더로 보낸다.
- 아래와 같이 이전 이벤트의 ID를 담아서 서버로 전달하기 때문에, 서버는 ID별로 이벤트를 저장하거나 복구 전략을 고려해야한다.

Last-Event-ID: 12345

클러스터 환경에서의 이벤트 공유
- SSE는 상태를 서버가 유지하므로, 서버가 여러 대일 경우 Sticky Session 또는 Pub/Sub 전략이 필요함.

SSE vs WebSocket

	SEE	WebSocket
통신 방향	단방향 (서버 → 클라이언트)	양방향
복잡도	낮음	높음 (핸드쉐이크 등 필요)
HTTP 기반	Yes (단순 GET 요청)	No (업그레이드 필요)
메시지 포맷	텍스트 전용 (text/event-stream)	바이너리, 텍스트 모두 지원
자동 재연결	기본 제공	수동 구현 필요
클라이언트 수용량	상대적으로 적음	더 많은 커넥션 가능 (비동기 IO 필요)

[MySQL] 예제로 이해하는 인덱싱(Indexing)과 정규와, 비정규화, 반정규화

노는게제일좋아! — Sun, 25 May 2025 15:48:07 +0900

인덱싱 (Indexing)

특정 컬럼의 값을 빠르게 찾을 수 있도록 도와주는 데이터 구조

인덱스 종류

인덱스 종류	설명
Primary Key	테이블의 고유 식별자. 자동으로 UNIQUE + NOT NULL 인덱스 생성
Unique Key	중복 허용 안 됨. 이메일, 주민번호 등에 사용
Index (또는 key)	일반 인덱스. 중복 가능
FullText Index	전문 검색용 인덱스 (MyISAM, InnoDB 5.6 이상에서 지원)
Spatial Index	공간 데이터(GIS) 전용 인덱스

인덱스 내부 구조

MySQL의 기존 스토리지 엔진인 InnoDB는 B+Tree 구조로 인덱스를 저장한다.
- Clustered Index: Primary Key 기준으로 실제 데이터도 정렬됨
- Secondary Index: 실제 데이터가 아닌 PK를 참조 (row lookup 필요)

Clustered Index

테이블 자체의 물리적 저장 순서를 결정하는 인덱스 -> 테이블의 데이터 자체가 인덱스 구조에 따라 정렬되어 저장된다.
테이블에 하나만 존재 가능
일반적으로 Primary Key가 자동으로 Clustered Index가 됨

CREATE TABLE users (
  id INT PRIMARY KEY,
  name VARCHAR(100),
  age INT
);

Secondary Index

데이터와 분리된 별도의 인덱스 구조
여러 개 생성 가능
secondary 인덱스를 통해 먼저 위치를 찾고, 실제 데이터를 Clustered Index를 통해 다시 읽음

CREATE INDEX idx_age ON users(age);

// 키는 age, 값은 해당 row의 id (즉, clustered index의 주소)
[ 22 ] → id=1 (users의 id)
[ 25 ] → id=3
[ 30 ] → id=2
이런식으로 저장됨.

즉, Primary key를 만들면 그게 Clustered Index가 되고, 나머지는 모두 Secondary Index다.

SELECT * FROM users WHERE age = 25;

위 쿼리가 실행되면
1. idx_age(보조 인덱스)에서 25라는 나이를 찾고, id=3을 발견
2. id=3으로 Clustered Index를 타고 가서 실제 row 데이터를 읽음

인덱스 설계 전략

언제 인덱스를 걸까?
- WHERE, JOIN, ORDER BY, GROUP BY에 자주 사용되는 컬럼
- FK, 유니크 값 검색
  - fk의 경우 자식 테이블에서 부모 테이블의 값을 찾기 때문에, 참조 대상 칼럼에 인덱스가 있어야 효율적.
- 큰 테이블의 범위 검색
  - 예: SELECT * FROM users WHERE age BETWEEN 30 AND 40;
    - age에 인덱스가 있다면, 30 이상인 위치로 바로 Jump하고, 거기서부터 40까지 선형 탐색만 함.
    - b-tree (균형 이진 트리) 구조라 이진 탐색으로 빠르게 찾음.
과도한 인덱싱은 오히려 성능 저하
- 쓰기 성능(Insert, Update, Delete) 저하
- 인덱스 저장공간 증가

예제 1: 블로그 시스템 DB 설계 (1:N 관계)

-- 사용자
CREATE TABLE users (
  id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  username VARCHAR(50) NOT NULL UNIQUE,
  email VARCHAR(100) NOT NULL UNIQUE,
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP
);

-- 게시글
CREATE TABLE posts (
  id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  user_id BIGINT UNSIGNED NOT NULL,
  title VARCHAR(255) NOT NULL,
  content TEXT NOT NULL,
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (user_id) REFERENCES users(id),
  INDEX idx_user_created_at (user_id, created_at)
);

-- 댓글
CREATE TABLE comments (
  id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  post_id BIGINT UNSIGNED NOT NULL,
  user_id BIGINT UNSIGNED NOT NULL,
  content TEXT NOT NULL,
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
  FOREIGN KEY (post_id) REFERENCES posts(id),
  FOREIGN KEY (user_id) REFERENCES users(id),
  INDEX idx_post_created_at (post_id, created_at)
);

user <-> posts는 1:N, posts <-> comments도 1:N 관계
posts.user_id, comments.post_id에 인덱스를 추가해 작성자별, 게시글별 조회 속도 향상
idx_user_created_at: 유저별 글을 시간순으로 정렬할 때 사용

SELECT * 
FROM posts
WHERE user_id = 42
ORDER BY created_at DESC
LIMIT 10;

예를 들어, 위처럼 "user 42가 작성한 최근 글 10 개 가져오기" 요청할 때,
- 인덱스가 없다면 mysql은 comments 테이블 전체에서 user_id = 42를 풀스캔(full table scan) 하거나, user_id만 인덱스에 있어도 filesort를 수행하게 된다.
- ORDER BY created_at 정렬 작업은 메모리 또는 디스크에서 수동으로 진행되기 때문에 느림.
- 그런데 INDEX (user_id, created_at) 설정을 하게 되면, mysql은 인덱스 자체가 정렬된 자료구조(B+ Tree)이기 때문에 (user_id, created_at) 순서로 인덱스가 잡혀 있으면, 정렬 없이도 빠르게 원하는 결과를 얻을 수 있다.
- MySQL은 복합 인덱스를 왼쪽부터 순차적으로 이용하기 때문에, 인덱스에 나열된 컬럼 순서가 쿼리 성능에 결정적인 영향을 준다.

예제 2: 팔로우 시스템 (자기참조 관계)

CREATE TABLE users (
  id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  username VARCHAR(50) NOT NULL UNIQUE
);

CREATE TABLE follows (
  follower_id BIGINT UNSIGNED NOT NULL,
  followee_id BIGINT UNSIGNED NOT NULL,
  created_at DATETIME DEFAULT CURRENT_TIMESTAMP,
  PRIMARY KEY (follower_id, followee_id),
  FOREIGN KEY (follower_id) REFERENCES users(id),
  FOREIGN KEY (followee_id) REFERENCES users(id),
  INDEX idx_followee (followee_id)
);

user <-> user 참조하는 형태
follower_id, followee_id를 각각 인덱싱 (팔로잉 / 팔로우 조회)
PRIMARY KEY (follower_id, followee_id): 두 사람의 관계는 중복되지 않도록 보장 + 빠른 조회

정규화(Normalization), 비정규화(Denormalization), 반정규화(Semi-denormalization)

데이터 저장의 구조와 효율성 사이의 균형을 조정하는 개념

정규화(Normalization)

정규화는 데이터 중복을 줄이고, 데이터 무결성(정합성)을 보장하기 위해 테이블을 분해하는 과정
목적
- 중복 제거
- 데이터 무결성 유지
- ANOMALY 방지 (삽입/삭제/갱신 시 문제 최소화)
  - 삽입 이상 (Insertion Anomaly)
    - 문제 상황: Physics 과목을 추가하려고 할 때, 수강생이 없다면 course_name과 professor만 입력해야 하는데, student_id가 Not Null 설정되어 있어서 입력 불가.
    - 문제 해결: 과목 정보를 별도 테이블로 분리 (정규화)
  - 삭제 이상 (Deletion Anomaly)
    - 문제 상황: 학생 Charlie가 수강 취소하면, English 과목 자체가 DB에서 사라진다. (과목이 학생에게 의존된 상황)
    - 문제 해결: 과목과 학생 정보를 별도 테이블로 분리해서 보존.
  - 갱신 이상 (Update Anomaly)
    - 문제 상황: 수학 교수님이 Dr. Kim -> Dr. Park으로 변경되었는데, 해당 과목을 수강 중인 모든 학생 레코드에 반영해야 함. 일부만 수정되면 데이터 정합성 깨짐 (누군가의 데이터는 과거 교수님 이름으로 기록됨)
    - 문제 해결: 교수 정보는 과목 테이블에 넣고, 참조로 관리갱신 이상 (Update Anomaly)

예: 학생이 여러 과목을 수강하는 데이터

1. 정규화 (Normalization)

2. 비정규화 (Denormalization)

정규화를 거쳐 나뉜 테이블을 성능 개선이나 실용적인 이유로 다시 합치는 과정
목적
- 조인 비용 감소
- 읽기 성능 감소
- 쿼리 구조 단순화
앞서 정규화된 구조에서 (학생 이름, 과목 이름) 쌍으로 조회하는 경우가 많은 경우, 쿼리가 느릴 수 있기 때문에 아래처럼 두 테이블을 합친 비정규화 테이블을 만들 수 있다.
- 중복이 생기지만 조회는 빨라짐.

3. 반정규화 (Semi-denormalization)

완전히 정규화된 구조와 완전히 비정규화된 구조 중간 정도로 타협하는 설계이다.
정규화는 유지하되, 자주 쓰이는 값을 중복 컬럼 또는 캐싱 컬럼으로 일부 테이블에 둠.
예: 게시글의 댓글 수를 coments 테이블에서 매번 COUNT 하지 않고 posts 테이블에 comment_count 컬럼을 둬서 캐싱
- 새로운 comments 값이 생길 때마다, posts의 comment_count 값을 업데이트

추가 배포 없이 API 케이스 통일하기: 카카오 사례 및 구현 가이드

노는게제일좋아! — Tue, 22 Apr 2025 20:16:52 +0900

카카오 기술 블로그 “추가배포 없이 API의 case 통일시키기”를 토대로 작성한 글입니다.

문제 정의

다양한 케이스 혼용
- "Admin에서는 Camel case를 써요", "외부 연동처에서는 Snake case로 내려달라고 하네요" 등 의도치 않게 서비스별로 JSON 케이스가 혼용되어 코드베이스에 여러 Naming 전략이 섞이게 된다.
DTO 중복
- 여러 대상 서버의 케이스 규칙에 맞추려면 DTO를 여러 벌 정의해야 하는 상황이 발생한다.

(Camel Case) -> SERVER -> (Snake Case)

동일한 값의 DTO지만 받을 때는 Camel case, 보낼 때는 Snake case가 필요한 상황이 있을 수 있다.
위와 같은 문제는 MSA 환경에서 더욱 빈번하게 발생할 수 있고, 무중단 서비스에서는 쉽게 고치기 어렵다.

추가 배포 없이 API 케이스 통일하기 3단계

출처: https://tech.kakao.com/posts/665

Case-Insensitive 파싱 모듈 도입
- 핵심 목표: 기존 API가 어떤 케이스로 값을 보내든 간에 정상 동작하도록 만들기
- 서버들이 camelCase 또는 snake_case JSON을 받아도 문제 없이 역직렬화할 수 있도록 Jackson의 기능을 활용.
- ObjectMapper 설정에 accept-case-insensitive-properties: true 옵션을 설정하면, 케이스 무관하게 필드를 바인딩할 수 있다.

spring:
  jackson:
    mapper:
      accept-case-insensitive-properties: true

2. snake_case 응답/요청으로 일괄 전환

핵심 목표: API를 외부에 snake_case로 일원화
요청(Request)은 스프링에서 제공하는 RequestBodyAdvice를 활용하여 AOP 방식으로 camelCase -> snake_case로 변환된 JSON을 강제 파싱
응답(Response)은 공통 ApiResponse<T> 래퍼를 사용해 내부 데이터를 가공한 뒤 snake_case로 직렬화.
서버 응답 시 ObjectMapper에 PropertyNamingStarategies.SNAKE_CASE를 적용해 snake_case가 강제된다.

@Bean
public ObjectMapper objectMapper() {
    ObjectMapper mapper = new ObjectMapper();
    mapper.setPropertyNamingStrategy(PropertyNamingStrategies.SNAKE_CASE);
    return mapper;
}

@ControllerAdvice
public class SnakeCaseRequestAdvice implements RequestBodyAdvice {

    private final ObjectMapper snakeCaseMapper;

    public SnakeCaseRequestAdvice(ObjectMapper defaultMapper) {
        this.snakeCaseMapper = defaultMapper.copy();
        this.snakeCaseMapper.setPropertyNamingStrategy(PropertyNamingStrategies.SNAKE_CASE);
    }

    @Override
    public boolean supports(MethodParameter methodParameter, Type targetType, Class<? extends HttpMessageConverter<?>> converterType) {

        // 모든 요청에 대해 Advice를 적용할지 여부
        return true;
    }

    @Override
    public HttpInputMessage beforeBodyRead(HttpInputMessage inputMessage, MethodParameter parameter, Type targetType,
                                           Class<? extends HttpMessageConverter<?>> converterType) throws IOException {
        // body를 직접 수정할 게 아니라면 그대로 반환
        return inputMessage;
    }

    @Override
    public Object afterBodyRead(Object body, HttpInputMessage inputMessage, MethodParameter parameter,
                                Type targetType, Class<? extends HttpMessageConverter<?>> converterType) {
        // 여기서는 실제 바디 파싱이 끝난 이후라 바꾸는 작업은 거의 안 함
        return body;
    }

    @Override
    public Object handleEmptyBody(@Nullable Object body, HttpInputMessage inputMessage, MethodParameter parameter,
                                  Type targetType, Class<? extends HttpMessageConverter<?>> converterType) {
        return body;
    }
}

3. 모듈 정리 및 경량화

핵심 목표: 호환 모듈을 제거하고 통일된 시스템으로 정리
1단계에서 도입했던 case-insentive 파싱 모듈(accept-case-insensitive-properties)을 제거 -> 더 이상 필요 없어서
Jackson 관련 설정(RequestBodyAdvice)도 정리

이 접근 방식의 장점

점진적 적용 가능
- 기존 API 사용자가 인지하지 못한 채로 변화를 적용할 수 있어 위험이 낮음.
코드 수정 최소화
- DTO를 복제하거나 대규모 수정 없이도 명명 규칙을 바꿀 수 있음.
플랫폼 일관성 확보
- 외부 연동, 프론트엔드 API 호출 시 명확한 포맷 통일 가능.
테스트/배포 비용 절감
- 기존 API의 동작을 유지하면서 새로운 형식으로 전환 가능.

쿠버네티스 CPU 리소스 관리 cpu.requests cpu.limits 설정 Throttling이란

노는게제일좋아! — Sat, 12 Apr 2025 23:51:55 +0900

LY Corporation Tech Blog의 당신의 CPU는 열심히 일하고 있나요? 글을 요약 및 기타 정보를 추가하여 작성한 글입니다. 자세한 내용은 링크를 참조해 주세요!

CPU 요청량(cpu.requests) vs CPU 상한(cpu.limits)

apiVersion: v1
kind: Pod
metadata:
  name: frontend
spec:
  containers:
  - name: app
    image: images.my-company.example/app:v4
    resources:
      requests:
        memory: "64Mi"
        cpu: "250m"
      limits:
        memory: "128Mi"
        cpu: "500m" # Can we remove this cpu limits field?

CPU 요청량 (cpu.request)
- Pod가 사용을 보장받는 최소 CPU 리소스 값
CPU 상한 (cpu.limits)
- Pod가 사용할 수 있는 최대 CPU 리소스 값

출처: https://techblog.lycorp.co.jp/ko/efficiently-using-cpu-in-kubernetes

예: 위 사진처럼 2코어 CPU를 가진 노드가 있다고 하자.
- 부하가 많이 발생하지 않는 평소에는 각 pod에서 각각 cpu 0.1 코어씩만 사용한다면, 이 노드에서 현재 사용 가능한 여유 코어는 1.8코어가 된다.
- 만약, A Pod의 트래픽이 증가하게 된다면, cpu.limits 값인 1.5 코어까지 사용할 수 있게 된다. 그러면 이 노드의 사용 가능한 코어는 0.4 코어만 남게 된다.
- 이 상황에서 B Pod의 트래픽이 증가하게 되면 CPU 리소스는 어떻게 배분될까?
  - cpu.requests는 해당 설정값만큼 CPU 리소스를 사용할 수 있도록 보장하는 것이기 때문에 B Pod는 최소 1.0 코어를 사용할 수 있어야 한다. 따라서, A Pod가 CPU 상한값에 맞춰 사용하던 리소스 중 0.5 코어를 반납해 B Pod가 사용할 수 잇도록 한다.
- 이러한 CPU 리소스 분배 과정은 쿠버넽티스 내부에서 진행되며, 이때 리소스 할당은 CFS(Completely Fair Scheduler) 알고리즘 기반으로 작동된다.

CFS(Completely Fair Scheduler): 리소스 스케줄링 알고리즘

CFS는 이름처럼 "공정하게 CPU를 나눠 쓰자"라는 철학을 가진 리눅스의 기본 CPU 스케줄러다.
전통적인 라운드로빈이나 우선순위 기반이 아니라, 각 태스크에게 동일한 실행 기회를 제공하는 데 초점을 맞춘다.
컨테이너에 cpu.limits를 설정하면 CFS는 두 가지 파라미터를 기반으로 CPU 리소스를 사용하도록 설정한다.
- cfs_period_us: CPU 리소스를 할당하는 기준 시간.
  - 기본값은 100ms이며, 일반적으로 이 값을 조정하는 경우는 흔치 않다.
  - 100ms마다 cpu 리소스를 어떻게 사용할지 새로 스케줄링 한다는 뜻.
- cfs_quota_us: 기준 시간 동안 CPU를 사용할 수 있는 최대 시간.
예를 들어, cpu.limit: 0.5로 설정한다면
- 100ms 주기 동안 50ms만 CPU 사용 허용 (fs_quota_us = 50000)
- 만약 이 걸 넘게되면 남은 시간 동안 CPU 사용이 스로틀링된다.

* 쿠버네티스 자체에 CFS가 있는 건 아니고, 컨테이너의 CPU 사용량을 제한할 때 리눅스 CFS 기능을 활용하는 것!

스로틀링 (Throttling)

어떤 프로세스나 컨테이너가 설정된 한도 이상으로 자원을 사용하지 못하도록 강제로 제한하는 것.
쿠버네티스에서 CFS 스로틀링이 발생하는 이유
- 트래픽이 증가했는데 남아 있는 CPU 리소스가 부족해지는 경우, CPU를 사용하지 못하고 cfs_period_us 시간까지 대기하게 된다.
- 여기서 cfs_period_us 시간까지 대기하는 상황, 즉 CPU를 사용하지 못하는 상황을 "CFS Throttling"이라고 한다.
CPU 코어 수가 많아도 CFS 스로틀링이 발생할 수 있다.
- CFS는 코어 수가 아니라 "시간" 기준으로 CPU 사용량을 제한한다.

출처: https://techblog.lycorp.co.jp/ko/efficiently-using-cpu-in-kubernetes

위 사진처럼, 4코어 노드에서 A Pod가 병렬처리로 각 코어의 25ms씩을 사용하는 상황이 있다고 가정해 보자.
- 이러면 총 CPU 사용 시간은 100ms이 된다.
- 만약 해당 pod의 cpu.limits이 1.0으로 설정되어 있다면, cfs_quota_us 설정 제한(100ms)에 걸리게 된다.
- 이러면 남은 75ms에 해당하는 시간 동안 CFS 스로틀링이 발생하게 된다.
이해하기 쉽게, 비유해보자면 다음과 같다.
- 당신이 편의점 사장이고 알바 4명을 고용했다고 해보자. 근데 본사에서 "이번 주에 일 시킬 수 있는 총 시간은 100시간까지만 허용"한다라고 했다.
- 그러면 4명이 동시에 1시간 일하면 총 4시간을 일한 것이 된다. 즉, 4명이 동시에 25분 일했더니, 총 100분을 다 써서, 이번주는 더 이상 일을 시킬 수 없는 상태가 된다.

CPU 상한 제거하기

주어진 자원을 최대한 활용하려면 CFS 스로틀링 발생을 최소화해야 하고, 이를 위해서는 cfs_quota_us로 인한 제한이 발생하지 않아야 하며, 그러려면 CPU 상한을 설정하지 않아야 한다.
cpu.limits를 제거하면 생길 수 있는 부작용
- limits을 아예 안 주면 CFS는 리미트가 없는 상태로 판단해서, 해당 컨테이너가 CPU를 무한정 사용할 수 있다고 판단한다.
- 이런 경우, 멀티 테넌시 환경에서는 noisy neighbor 문제가 생길 수 있다.
- 하나의 파드가 CPU를 독점해서 다른 파드가 CFS 스로틀링을 더 많이 겪게 된다.
따라서, 단일 파드만 사용하는 테스트 환경이나 모놀리식 구조에서는 limits 제거가 유리하지만, 프로덕션 환경이나 멀티 파드/멀티 테넌시 구조에서는 적절한 limits 설정이 중요하다.

* 테넌시 (Tenancy): 임차 또는 입주를 의미. 소프트웨어 아키텍처에서는 여러 사용자가 하나의 시스템을 어떻게 공유해서 사용하는가를 설명하는 개념.

Single Tenancy: 하나의 쿠버네티스 클러스터를 하나의 팀만 사용
- 쉽게 말하면, 하나의 건물(=시스템)에 여러 세입자(=사용자나 회사)가 같은 건물 구조를 사용하면서도, 각자 자기 공간처럼 분리되어 서비스를 사용하는 것
Multi Tenancy: 하나의 쿠버네티스 클러스터를 여러 팀이 공유

테스트 방법

성능 지표
- TPS(Transactions Per Second)와 최대 TPS, 평균 응답 시간(Average Response Time)을 선정
- 부하를 발생시키면서 그라파나를 통해 지표 확인
  - container_cpu_cfs_throttled_seconds_total: 해당 컨테이너가 CPU CFS에 따라 제한(스로틀링)된 총 시간을 의미.
    - 해당 값이 증가할수록 스로틀링이 많이 발생한 것.
  - container_cpu_usage_seconds_total: 컨테이너가 사용한 CPU 시간의 총합. 전체적인 CPU 사용량을 측정하는 지표.

출처:

- https://techblog.lycorp.co.jp/ko/efficiently-using-cpu-in-kubernetes

[D2] Elasticsearch 기반 로그 모니터링 시스템의 한계와 Apache Iceberg 요약 및 배경지식 정리

노는게제일좋아! — Mon, 24 Mar 2025 17:09:15 +0900

Naver D2 "NELO Alaska: 대용량 로그 데이터 저장을 위한 Apache Iceberg 도입기" 요약 및 배경 지식들을 정리해 두었습니다.

자세한 내용을 링크 글을 참고해 주세요.

Kafka와 Elasticsearch

로그 모니터링 시스템 구축에는 인덱스 기반의 빠른 검색을 제공하는 검색 엔진인 Elasticsearch가 널리 사용된다.

[ 클라이언트 ] 
    │
    ▼
[ Kafka (로그 데이터 수집) ] → 로그 데이터를 빠르게 수집하고 Elasticsearch로 전송
    │
    ▼
[ Elasticsearch ]
    │
    ├── [ Hot 계층 (SSD) ] → 최신 데이터 3일간 저장
    │
    ▼
[ Warm 계층 (HDD) ] → 최대 90일까지 저장

클라이언트로부터 수신된 로그 데이터는 Kafka에 적재된 후 Elasticsearch에 저장된다.

Kafka

분산 메시지 큐(Messafe Queue) 또는 이벤트 스트리밍 플랫폼
대용량 데이터를 빠르게 수집하고 처리하는 역할을 한다.
주요 특징
- Publisher-Subscriber 모델
  - 데이터를 보내는 Producer(생산자) 와 데이터를 소비하는 Consumer(소비자) 구조
  - Producer가 데이터를 특정 Topic(토픽)에 전송하면, Consumer가 해당 토픽을 구독하여 데이터를 가져감
- 고성능 & 대용량 처리
  - 로그 데이터, 트랜잭션 데이터, 실시간 이벤트 데이터 처리에 적합
  - 초당 수백만 개의 메시지를 처리할 수 있음
- 내구성과 장애 허용성(Fault-Tolerance)
  - 브로커(Broker) 여러 개로 구성하여 데이터를 복제(replication) 함으로써 장애에 강함
- 분산 아키텍처
  - 데이터가 여러 파티션(Partition) 으로 나뉘어 저장되므로 확장성이 뛰어남
Kafka가 하는 역할
- 클라이언트(앱, 서버) → Kafka에 로그 데이터 저장 → 이후 Elasticsearch로 전달

Hot/Warm 계층

Hot/Warm 계층(Hierarchy Storage, Tiered Storage) 개념은 Elasticsearch(ELK 스택)에서 데이터 저장 전략을 설명하는 공식 용어로 사용된다.

Hot 계층(Hot Tier)

빠른 검색과 실시간 분석이 필요한 데이터를 저장하는 계층
SSD를 사용하여 빠른 읽기/쓰기 성능을 제공
주로 최근 3일 이내의 최신 데이터가 저장됨
검색이 빈번하게 발생하는 데이터
Hot 계층의 역할
- 최신 로그 데이터 저장 → 빠르게 검색 → 일정 기간 후 Warm 계층으로 이동

Warm 계층 (Warm Tier)

검색이 자주 일어나지 않는 오래된 데이터를 저장하는 계층
상대적으로 느린 HDD를 사용하여 비용 절감
최대 90일까지 데이터 저장 가능
Warm 계층의 역할
- Hot 계층에서 3일 지난 데이터 이동 → 저장 공간 절약 & 비용 절감 → 필요할 때만 검색

비효율적인 Elasticsearch 사용

서비스의 법적 요구 사항 등의 이유로 예외적으로 1년 이상 장기간 로그 데이터를 저장하게 되다 보니 Warm 계층에 저장된 데이터의 크기가 급증하게 되었다.

사용자들의 검색 요청 로그를 분석한 결과 95% 쿼리가 당일에 발생한 데이터에 대한 것이었고, 99%의 쿼리가 일주일 이내의 데이터를 위한 것이었다.

Elasticsearch는 일반적으로 데이터 저장과 쿼리 계산을 위한 컴퓨팅을 같은 노드에서 담당하고 있기 때문에 이렇게 거의 검색되지 않는 데이터를 저장하는 것은 효율적인 일이 아니다.

문제 해결

이러한 문제를 해결하려면 Elasticsearch에는 검색이 자주 일어나는 단기간의 데이터만 저장하고, 장기간 데이터를 저장할 새로운 스토리지가 필요하다는 판단이 들었다.

Elasticsearch를 대체하는 신규 스토리지에서는 데이터 저장을 위한 스토리지와 검색을 위한 컴퓨팅을 분리한다는 아이디어를 기본으로 설계를 시작했다.

Iceberg를 이용해 로그 데이터 저장을 위한 새로운 타입의 스토리지를 구현한 컴포넌트인 Alaska를 개발해 적용했다.

Apache Iceberg

대규모 데이터 레이크에서 테이블 형식으로 데이터를 관리하는 오픈소스 테이블 포맷
- 데이터 레이크(Data Lake): 정형(structured), 반정형(semi-structured), 비정형(unstructured) 데이터를 원본 그대로 저장하는 대규모 저장소를 의미
- 쉽게 말하면, 기존 db는 정형화된 테이블 구조에 맞춰 데이터를 저장해야 하지만, 데이터 레이크는 모든 형태의 데이터를 가공하지 않고 원본 그대로 저장할 수 있는 저장소이다.
특징
- ACID 트랜잭셔 지원
  - Iceberg는 스냅샷을 기반으로 트랜잭션을 지원하여 데이터 정합성 유지.
- Schema Evolution
  - 테이블의 스키마를 중단 없이 변경 가능.
- Hidden partitioning
  - 자동 파티셔닝을 통해 사용자가 신경 쓰지 않아도 최적의 데이터 쿼리 성능을 제공함.

신규 로그 모니터링 시스템의 구조

Iceberg를 기반으로 개발한 새로운 로그 모니터링 시스템은 기존 Elasticsearch 기반의 로그 모니터링 시스템을 대체하는 것이 아니다.
Elasticsearch에는 실시간 모니터링이 필요한 짧은 기간의 로그를 저장하고, 장기간 보관이 필요한 데이터는 새로운 스토리지를 활성화해 저장하도록 설계했다.
기존 로그 모니터링 시스템에서는 Kafka에 적재된 로그 데이터를 Elasticsearch에 인덱싱하는 방식을 사용했었다. 신규 로그 모니터링 시스템도 동일한 Kafka 토픽으로부터 데이터를 읽어 Iceberg 테이블 포맷으로 저장한다.
- 실시간 검색/모니터링이 필요하지 않은 데이터는 Elasticsearch에 저장하지 않고 직접 Iceberg로 저장.

데이터 프로세싱

신규 로그 모니터링 시스템은 데이터 프로세싱을 위해서 Kappa Architecture를 따르고 있다.
- 즉, 실시간으로 저장되고 있는 로그 데이터 테이블에 사용자가 접근해 데이터를 조회할 수 있는 구조이다.
Iceberg의 오픈 테이블 포맷은 ACID 트랙잭션을 지원하기 때문에 실시간으로 읽고 쓰기 가능.
이러한 구조로 짧은 지연 시간 안에 데이터 조회가 가능해짐.

Kappa Architecture vs Lambda Architecture

전통적인 Lambda Architecture는 배치 처리(batch)와 스트림 처리(stream)를 동시에 사용하는 구조입니다.
하지만 Kappa Architecture는 배치 처리를 제거하고 스트림 처리만 사용하는 방식입니다.

비교 항목Lambda ArchitectureKappa Architecture

데이터 처리 방식	배치 + 스트림 병행	스트림 처리만 사용
데이터 저장소	배치용(보통 Hadoop) + 실시간용	단일 스트림 저장소
유지보수	복잡함 (이중 코드 필요)	단순함 (하나의 코드)
데이터 정합성	배치와 스트림 간 동기화 필요	실시간 데이터로 정합성 유지

* 데이터 적재, 데이터 최적화, Iceberg REST 카탈로그와 데이터 연동, 데이터 쿼리, 적용 결과에 대한 내용은 실제 해당 글을 참고해 주세요.