개발하우스

코딩 테스트 합격자 되기 - week 1

leejunkim — Fri, 23 Jan 2026 17:22:18 +0900

1) 배열 정렬하기

정수 배열의 길이는 2 이상 10^5 이하입니다.
제약조건
- 정수 배열의 길이는 2 이상 10^5 이하
- 정수 배열의 각 데이터 값은 -100,000 이상 100,000 이하

public static int[] solution(int[] arr) {
    int[] copy = arr;
    Arrays.sort(copy);
    return arr;
}

문제 분석
- 데이터의 최대 갯수는 10^5.
- 컴퓨터가 1초당 하는 연산은 1억 (10^8).
- 만약에 제한 시간이 3초면, 총 3억번의 연산 이하로 해야함..!
  - O(N^2) = O(10^5)^2 = O(10^10) -> 100억
    - 제한시간이 3초였으면 3억번의연산 이하로 해야하는데, O(N^2) 알고리즘을 사용하면 10^10 (100억)으로 최대 연산이 갈 수 있음! 그래서 O(N^2)는 제외.
  - O(N log N) = O(10^5 log 10^5) -> O(10^5 * 17)-> 170만번
    - 170만번은 3억번의 연산 이하여서 O(N log N)의 알고리즘(혹은 그 이하)를 사용할 수 있음!
그래서 실제 문제를 풀 때는 문제지에 적힌 실제 제한 시간(Time Limit)을 확인하고, 그 시간 안에 N을 넣었을 때 연산 횟수가 1억~수억 번을 넘지 않는지 체크하는 습관을 들이는 것이 중요함

2) 배열 제어하기

public static int[] solution(int[] arr) {
    return Arrays.stream(arr)
            .distinct() // 중복 제거
            .boxed()// 내림차순 하기 위해 reference type으로 변환
            .sorted(Collections.reverseOrder()) // 내림차순
            .mapToInt(Integer::intValue) // reference -> primitie
            .toArray();
}

자바에는 이런식으로 코테에 유용한 표준 API들이 많고 굳이 직접 적지 않아도 됨
시간 복잡도
- 중복 제거 (distinct) -> O(N)
- 정렬(sort) -> O(N log N)
- 최종 시간 복잡도는 O(N log N)

3) 두개 뽑아서 더하기

public static int[] solution(int[] arr) {
    Set<Integer> set = new HashSet<>();
    for (int i = 0; i < arr.length; i++) {
        for (int j = i + 1; j < arr.length; j++) {
            set.add(arr[i] + arr[j]);
        }
    }
    return set.stream()
            .sorted()
            .mapToInt(Integer::intValue)
            .toArray();
}

시간 복잡도
- 이중for문
  - 총 실행 휫수는 (N(N-1))/2 = (N^2)/2 - N/2 -> 최종적으로 O(N^2)
- 정렬
  - 정렬할 데이터는 N^2
  - 정렬 알고리즘 (.sorted)의 시간복잡도는 O(N log N)
  - 데이터는 N^2이므로 최종적으로 O(N^2 log N^2)가 됨
- 그래서 이중for문 + 정렬은 O(N^2) + O(N^2 log N^2). 하지만 가장 큰 텀안 중요해서 최종적으로 O(N^2 log N^2)만 남음.
- 최종 시간 복잡도는 O(N^2 log N^2)

[코딩 테스트 합격자 되기] 코딩테스트 사전 준비 (+ 알고리즘 효율 분석)

leejunkim — Fri, 9 Jan 2026 19:38:31 +0900

코딩테스트 사전 준비

프로그래머스 활용
- 다른 사람의 풀이 보기
- 테스트 케이스 직접 추가
  - 충분한 시간을 들여 문제를 분석한 후, 코드 구현하기 전에 예외 상황을 충분히 확인할 수 있도록 나만의 테스트 케이스 만드는 연습을 해야함
공부 습관
- 기록하기!
  - 문제를 보면 어떤 알고리즘을 적용하려 했는지, 근거는 무엇인지, 문제를 푸는 과정에서 내가 떠올린 알고리즘을 어떻게 코드로 만들려 했는지 등
  - 전 기록을 보면서 복기
  - 이 과정에서 무엇을 모르는지 알 수 있게 됨
- 시험 보듯 공부하기
  - 평소에 시간 배분하면서 코딩 테스트 공부하기
  - 시간 배분 연습 안함/함 차이가 나중에 결과가 많이 다를 것임
- 2-3개월은 걸릴거임
  - 무조건 짧은 시간 내에 할 수 없음, 꾸준히 해야함
- 나만의 언어로 요약
  - 내가 정말로 이해하고 있는지 알아보기 위해서
코딩테스트 효율적으로 공부하기
- 언어 선택 - 자바 (자바 공부 동행하기)
- 문제 분석 연습하기
  - 문제를 쪼개서 분석
  - 제약사항을 파악하고 테스트 케이스 추가
  - 입력값 분석
    - 보통 알고리즘 시간 복잡도는 입력값이 결정하는 경우가 많음
    - 입력값의 크기를 확인하면 문제를 제한시간 내에 풀 수 있는 알고리즘과 그렇지 않은 알고리즘을 미리 걸러낼 수 있음!
  - 그리디하게 접근할 때는 근거를 명확하게
  - 데이터 흐름이나 구성을 파악
- Pseudocode (의사 코드)
  - 세부 구현 X, 동작 O
  - 문제 해결 순서 적기
  - 테스트하기

알고리즘의 효율 분석

코딩테스트 문제에는 제한 시간이 있으므로 문제를 분석한 후에 빅오 표기법을 활용해서 해당 알고리즘을 적용할 때 제한 시간 내에 출력값이 나올 수 있을 지 확인할 수 있음
컴퓨터가 초당 연산할 수 있는 최대 휫수는 1억 번 (10^8)
연산 횟수는 1000~3000만 정도로 고려해서 시간 복잡도를 생각하면 됨
- 예) 제한 시간이 1초인 문제는 연산 횟수가 3000만이 넘는 알고리즘은 사용하면 안됨
제한 시간이 1초인 문제에 각 시간 복잡도별로 허용할 수 있는 N의 가용범위:

시간 복잡도	N의 가용 범위
O(N!)	10
O(2^N)	20~25
O(N^3)	200 - 300
O(N^2)	3,000 - 5,000
O(N log N)	100만
O(N)	1,000 - 2,000만
O(logn)	10억 이상

예를 들면, 처음부터 끝자기 배열을 순회해서 숫자를 찾는 알고리즘은 O(N)이다.
- O(N)이 허용하는 연산 횟수는 2,000만으로 데이터의 개수가 2,000만 이하면 이 알고리즘은 사용해도 괜찮다!
이렇게 시간 복잡도를 활용하여 불필요한 알고리즘을 제외하면 된다

[모두의 플리] JMeter로 OS 성능 테스

leejunkim — Mon, 5 Jan 2026 15:17:06 +0900

OS과 원본 QueryDSL의 성능 차이를 재보고 싶어서 JMeter를 사용해봤다.

로컬 DB에는 약 1000개의 컨텐츠 데이터를 넣어주고 시작했다.

1. Thread Group 추가

Number of Threads (user) - 유저 갯수
Ramp up period (seconds) - 몇초 후에 모든 유저가 시작하는지
Loop count (user) - 각 유저가 몇번 하는지

나는 테스트할때 이렇게 설정했다:

- 유저 수 - 100

- ramp up - 20

- loop count - 5

2. Thread Group에서 HTTP Request 추가

3. Header Manager 추가

- bearer 토큰을 넣어줬다.

4. 결과

QueryDSL

결과적으로... OpenSearch가 QueryDSL보다 약 ~15 정도 빨랐다!!

테이블로 정리하자면:

	QueryDSL	OS (OpenSearch)
Avg Latency	10631 ms (10.6 s)	690 ms (0.69 s)
Max Latency	30968 ms (30.9 s)	2640 ms (2.6 s)
Throughput	6.2 req/s	22.7 req/s

[모두의 플리] watcherCount를 Redis로 리팩토링

leejunkim — Tue, 23 Dec 2025 13:48:01 +0900

상황

프로젝트에서 실시간 콘텐츠 시청 세션 기능을 구현했다. 사용자가 영상 페이지에 들어오면 시청자로 집계되고, 나가면 집계에서 빠져야 한다. 이 숫자는 웹소켓을 통해 모든 사용자에게 실시간으로 브로드캐스팅되어야 했다.

문제점

프론트에서 콘텐츠를 불러올 때, 요구하는 dto에 watcherCount가 들어있다.

그래서 기존 코드는 콘텐츠 엔티티에 watcherCount 필드를 사용했다. 그래서 WatchingSessionService에서 watchingSession이 업데이트 될때마다 이 콘텐츠의 필드도 업데이트 하는 방식으로 했다:

contentRepository.incrementWatcherCount(content.getId());

contentRepository.decrementWatcherCount(content.getId());

public interface ContentRepository extends JpaRepository<Content, UUID>, ContentRepositoryCustom {
  @Modifying
  @Query("UPDATE Content c SET c.watcherCount = c.watcherCount + 1 WHERE c.id = :contentId")
  void incrementWatcherCount(@Param("contentId") UUID contentId);

  @Modifying
  @Query("UPDATE Content c SET c.watcherCount = c.watcherCount - 1 " +
      "WHERE c.id = :contentId AND c.watcherCount > 0")
  void decrementWatcherCount(@Param("contentId") UUID contentId);
}

여기서 생각해보면, 사용자 한명한명 들어올 때마다 매번 디스크 기반의 DB write 작업을 수행해야 한다.

현재 @Transactional을 메서드에 붙히긴 했지만, 트랜잭션의 원자성(성공 아니면 롤백)을 보장할 뿐, 여러 스레드가 동시에 같은 데이터에 접근하는 동시성 문제까지는 해결해주지 못한다.
만약에 시청자 A, B가 0.0001초 차이로 동시에 입장했으면 lost update가 생길 수 있다.
- Transaction A: DB에서 현재 인원 조회 -> 10명
- Transaction B: DB에서 현재 인원 조회 -> 10명 (A가 아직 저장을 안 했으므로)
- Transaction A: 10 + 1 = 11명으로 저장 (UPDATE)
- Transaction B: 10 + 1 = 11명으로 저장 (UPDATE)
- 결과적으로 두 명이 들어왔으니 12명이 되어야 하는데, DB에는 11명만 남는다. A의 업데이트 내역이 B에 의해 덮어씌워져 사라진 것이다 (Lost Update)
이를 막으려면 비관적 락을 걸어야하는데, A가 끝날때까지 B는 대기하게 하는 것이다. 그러면 데이터는 정확해지지만 만약에 100명이 들어오게 되면 100명이 줄을 서게 되어서 성능이 급격하게 저하된다.

해결 - Redis

Redis는 구조적으로 이 문제를 완벽하게 회피한다.

Single Thread: Redis는 한 번에 하나의 명령어만 처리한다. 아무리 많은 요청이 동시에 몰려도 내부적으로는 줄을 세워 하나씩 순서대로 처리한다.
Atomic Operation: Redis의 INCR(증가) 명령어는 "값을 읽고 -> 더하고 -> 저장하는" 과정이 분리되지 않고 한 방에 일어난다.
이제 100명이 동시에 INCR을 날려도 1부터 100까지 순서대로 빠르게 처리해서 정확히 +100을 만들어낸다.

바뀐 것들

이제 Content 테이블의 watcher_count 컬럼은 제거되고 실시간 용도로 쓰지 않는다.
Redis는 실시간 조회수를 관리한다.

private static final String COUNT_KEY_PREFIX = "watching:count:";

public Long increaseWatcherCount(UUID contentId) {
    String key = COUNT_KEY_PREFIX + contentId;
    // DB 조회 없이 메모리에서 즉시 +1
    return redisTemplate.opsForValue().increment(key);
}

public Long decreaseWatcherCount(UUID contentId) {
    String key = COUNT_KEY_PREFIX + contentId;
    // 메모리에서 즉시 -1
    return redisTemplate.opsForValue().decrement(key);
}

결과

DB 부하 감소: 단순 조회수 갱신을 위한 UPDATE 쿼리가 완전히 사라졌다. DB는 이제 중요한 비즈니스 데이터(결제, 유저 정보 등) 처리에만 집중할 수 있게 되었다.
그 위워별도의 락(Lock) 구현 없이도 Redis의 원자적 연산 덕분에 100명이 동시에 들어와도 정확하게 +100이 카운팅된다.

[코드잇 스프린트] Spring 백엔드 4기 수료 후기 및 회고

leejunkim — Fri, 19 Dec 2025 20:32:16 +0900

어느새 7개월이 지나갔고...긴 시간처럼 느꼈던 부트캠프가 끝났다.

5월부터 12월까지 수강했었고, 그 동안 정말 많은 일이 일어났다. 그래서 오늘은 반년동안 코드잇 스프린트 Spring 백엔트 4기 후기를 작성해보자 한다!

정보보다는 개인적인 생각과 회고가 많이 담겨있는 글이다.

‍ 왜 코드잇 부트캠프를 선택했을까?

일단 나는 전공자이지만, 스스로가 느끼기에는 기본기가 많이 부실한 편이었다.

아직 졸업은 하지 않았지만 졸업을 하면 바로 취직 준비를 해야한다는 생각에, 자신이 너무 너무 준비가 안됐다고 느꼈다.

그래서 4학년으로 올라가기 전에 휴학을 하기로 선택했고, 이 기간 동안 스스로가 무엇을 좋아하는지 탐색해보려고 했다.

(나중에 든 생각이지만 휴학은 정말 잘한 선택이었던 것 같다.. 학교 커리큘럼이 개인적으로 좀 빡세다고 생각하는 편인데, 학교 과목만 따라가기도 벅차서 어차피 학교 도중에 백엔드 프로젝트를 배우려고 했었다면 이도저도 아닌 상태가 되어 정말 큰일 났을 것 같다.... ㅜㅜ)

혼자 유튜브 보면서 토이 프로젝트 만들어본 결과, 프론트보다 백엔드 쪽이 더 재미있다고 느꼈고, 복학하기 전에 깊게 공부해보고 싶었다. 다른 분야를 알아보기는 했지만, 취직의 길이 가장 열린 쪽이 백엔드라고 생각하기도 했었고, 많은 회사들이 Spring 사용하고 있어서 안정적으로 느껴지는 만큼 Spring을 공부해야겠다고 마음을 다짐했다.

하지만... 혼자서 백엔드 분야를 공부하자니까 갑자기 너무 막막했고 스스로 자신감도 없었다. 또한 혼자 공부하기보다는 제대로 된 커리큘럼과 멘토링, 잡혀진 환경 속에서 공부를 하고 싶었고, 특히 사람들과 협업하면서 프로젝트에 몰입할 수 있는 기간이 필요하다고 느꼈다.

계속 방황하는 나...

그래서 부트캠프를 알아봤는데, 부트텐트라는 웹사이트를 이용한 기억이 있다:

부트텐트 속 수많은 부트캠프들

그래서 여러 부트캠프를 알아보던 와중에, 코드잇 스프린트가 눈에 띄었다. 일단 가장 마음에 들었던 점을 나열해보자면:

인턴십 기회 - 나는 복학하기 전에 무조건 백엔드 인턴십이 있었으면 좋겠다는 생각을 했다. 코드잇에 지원해주는 프로그램에 적극 참여해보기로 했다.
코딩테스트 - 많은 부트캠프를 알아보면서 협업을 할때 잠수를 타거나 문제가 생기는 상황을 여럿 후기를 통해 접했었는데, 코딩테스트로 어느 정도 배울 의지가 있는 사람들을 골라내는 것 같아서 신뢰가 갔다.
커리큘럼 - 스프링, AWS, 도커 등 실무에서 사용하는 기술을 배우는 커리큘럼이 마음에 들었다.
후기 - 부트텐트, 여러 티스토리/블로그 글을 참고했었는데, 대부분 만족스럽다는 내용이 많았다.

이런 이유들로 코드잇을 선택하게 되었다!

배운 것들

백엔드 개발의 기초
- Git과 Githb를 활용한 협업과 Java 기초 학습
- 자료구조, 알고리즘, Big-O로 데이터 성능 최적화
- Spring과 Spring Boot로 애플리케이션 개발 및 관리
중급 백엔드 개발
- RESTful API 설계와 SQL을 활용한 데이터 처리
- Spring Data JPA와 Transaction으로 데이터 처리
- Spring으로 RESTful API 설계 및 구현
- 기초 프로젝트
고급 백엔드 개발과 배포
- TDD로 Spring 서비스의 안정성 및 품질 관리
- Docker로 컨테이너화 및 배포 자동화 학습
- AWS ECS, S3, RDS로 클라우드 애플리케이션 운영 학습
- 중급 프로젝트
고급 기술과 안정적 시스템
- Spring Security로 보안 기초와 인증/인가 학습
- 비동기 처리와 Spring Cache로 대용량 트래픽 관리
- 디자인 패턴으로 효율적인 네트워크 구조 설계
- 고급 프로젝트

커리큘럼은 노션에 정리되어있었고, 또 코드잇 계정을 따로 받기 때문에 웹사이트에서 동영상 강의로 복습할 수도 있었다.

일단 수업 내용에 대해서는 정말 좋다고 느꼈다. 사실 고급 백엔드 개발과 배포 쪽까지만 해도 됐었을 텐데, 더 나아가서 spring security나, spring batch, redis, websocket, kafka 등 고급 심화 기술들을 많이 다뤘어서 실무가 어떤건지 조금 체험(?)하게 된것 같아서 좋았다.

하지만 동시에 굉장히 많은 것들을 배워서 스스로 깊이가 부족하다고 느꼈다.. 이부분은 앞으로 계속 복습하면서 공부할 예정이다.

참고로... 나는 스프링에 대해 진짜 거의 아무것도 모른 채 들어갔다. 전에 언급했던 토이 프로젝트는 사실 노드를 사용했었는데, 스프링으로 선택하게 된 계기가 안정성이라는 이유였다. 그래서 Spring Boot, Bean, MVC, Layered architecture, data jpa, TDD등을 배웠을 때 정말 무슨 신세계(?) 같았다. 내가 모르는 세계가 따로 있었다는 것을 알게 되고, 사실 한국은 기본적으로 스프링을 많이 사용하고 있고 커뮤니티가 꽤 커서 새삼 혼자 놀랐던 적이 있다. 이런 의미로 사실 운이 엄청 좋았다고 생각했다.
자바에 대해서 굉장히 깊게 공부할 수 있었다.
DB를 좀 깊숙히 잘 알아야 한다고 생각했다. 이번 부캠동안 디비를 사용하긴 했지만 아직 디비에 잘 모르는 것 같다...

또한 이 외에도 많은 과제가 있었다:

성취도 평가
- 파트가 끝날때 코드잇 사이트에서 시험 형식으로 문제를 풀었어야 했다. 대체로 괜찮은 점수를 받을 수 있었는데 동시에 복습도 할 수 있었고, 세삼 말로 꺼내서 설명하는 게 얼마나 연습이 많이 필요한지 깨닫게 되었다.
코드잇 위클리 페이퍼
- 매주 2가지의 주제로 위클리페이퍼를 쓰고 팀원들과 공유하는 방식이었다. 먼지만 싸이던 티스토리에 글도 좀 생기고 배운것을 정리하니까 머릿속에 개념이 좀 더 잘 잡히는 느낌이었다. 하지만 9-7에 과제랑 노트정리랑 다같이 시간 관리 하는게 좀 어려웠던 것 같다. 그래도 마지막에 기록만 이렇게 남으니까.. 역시 기록을 꾸준히 하는건 중요하구나..

매주 쓴 위클리 페이퍼

코드잇 과제
- 과제는 총 12개 진행했고, 과제를 진행할때마다 새 브랜치를 만들고 메인 리포로 PR을 날리는 방법으로 제출했었다. 리뷰는정해진 멘토님이 코드리뷰를 해주셨는데, 그 과정에서 코드를 수정하거나 바꾸기도 했다. 때로는 칭찬을 해주시거나 피드백을 꼼꼼히 주셔서 많이 배울 수 있었다.

멘토님의 피드백

그 외에도:

멘토링 시간
- 팀별로 멘토링 시간을 가졌는데, 다양한 경력의 현직자 분들을 만날 수 있었다. 부트캠프에만 찌들어 있으면 원가 세속과 단절(?)되는데, 매주 이런 시간을 가지면서 시야를 좀 넓힐 수 있었다 ㅎㅎ
깃과 깃허브 사용법
- 드디어 좀 미스터리 같았던 깃이랑 깃허브를 좀 이해할 수 있었다. 매일은 채우지 못했지만.. 깃허브 잔디도 꽤 채울 수 있었다!
  깃헙 잔디 ㅎㅎ

프로젝트

뻔한 이야기지만.. 팀원들과 프로젝트를 했었던 것이 너무 좋았다.

1️⃣ 기초 프로젝트 - Findex (핀덱스)

https://github.com/Sprint-team-3/sb4-findex-team3

첫 프로젝트에 얼떨결에 사다리뽑기로 팀장을 맞게 되었다. 하지만 다들 협업이 생소하고, 아직 초반이여서 대체로 시행착오가 많았던 것 같다. 그래도 팀원분들은 다들 착하시고, 다들 최선을 다했다고 생각했다.

지금 되돌아보면, 팀장으로서 부족한 부분이 많았던 것 같은데 잘 따라와주시는 팀한테 고마웠다. 또 기술적으로 아쉬운 부분이 많았는데, 지금 생각해보면 리팩토링하거나 고도화 하면 좋을 것 같은 부분들이 꽤 있었다. (예를 들면 쿼리문, 로깅, DB 배포, 모니터링 등등)

또 중간에 git이 꼬이기도 하였고, railway로 배포하려고 했을 때 ORM 에러때문에 꼬박 밤을 새운 기억이 났다..ㅋㅋ 그래서 이 프로젝트 이후 중급/고급 프로젝트도 이럴지 벌벌 떨면서(?) 생각했던 적도 있는데 보니까 사실 초급 프로젝트가 가장 힘들었던 것 같다 (허허) 하지만 그만큼 특별한 기억으로 남았고 마지막에 배로 뿌듯했던 기억이 있다. 다들 너무 고생이 많았던 것 같고 또 고맙기도 하다. 코드잇 부트캠프 중 가장 기억에 남는 순간이라고 하면 핀덱스 프로젝트를 떠올릴 것 같다.

2️⃣ 중급 프로젝트 - MoNew (모두의 뉴스)

https://github.com/sb04-team02/sb04-MoNew-team02

이번 프로젝트에서는 다들 초급 이후여서 그런지 훨씬 스무스하게 프로젝트를 완성할 수 있었고, 능력자 분들이 많았다. 그래서 그런지 동기부여도 굉장히 많이 됐던 시기다. 또, 팀장님이 팀을 굉장히 잘 이끌어 주셔서 일정관리도 원할하게 잘 되었다.

이때는 몽고디비, 배치/스케쥴러, 그리고 AWS CICD 배포쪽을 맡게 되었는데 정말 한꺼번에 새로운 것을 많이 가져가는 기분이었다. 특히 AWS 콘솔을 만지면서 인스턴스를 만들고 프로젝트를 실행했었는데 디버깅은 배로 어려웠지만 굉장히 흥미로웠던 기억이 있다. 이때 정말 많이 배웠고, 이때부터 클라우드 엔지니어링 쪽에도 관심을 가지게 되었다.

3️⃣ 고급 프로젝트 - Mopl (모두의 플리)

https://github.com/sb04-mopl-team2/sb04-mopl-team2

고급 프로젝트 답게 심화 기능을 많이 담은 프로젝트이다 (며칠 전에 끝나서 아직 프레시하다). 이때 웹소켓을 사용한 실시간 채팅이랑 시청 세션을 관리하는 기능, 그리고 OpenSearch로 콘텐츠 서치 고도화하는 역할을 맡았었다. 아 그리고 TDD 기반으로 진행했는데 사실 전 프로젝트에서는 시간상 못했기 때문에 이번에는 적용할 수 있어서 뿌듯했다.

팀원 분들은 모뉴때처럼 다 능력자분들이셔서 나만 좀 헤매는 듯 했다 (ㅋㅋㅋ.. ~~사실 안웃김~~ ㅜㅜ). 동기부여도 많이 되었고, 팀원분들과 라포트도 쌓을 수 있어서 재밌었다. 그리고 회의를 되게 꼼꼼하게 길게 하는 편이었는데, 중간에 많이 배우고 토론할 수 있어서 굉장히 좋았다.

모플 팀 노션 프로젝트

결국 기간 내에 완성할 수 있었고 블로그에도 트러블슈팅 대목을 정리해두어서 다행이라고 생각한다.

이때부터 슬슬 초반에 배운 것들을 잊어버리기 시작해서 면접 준비랑 복습도 동시에 병행했던 기억이 있다.. 다시 생각해도 좀 타이트하게 공부했었어서 중간중간에 꽤 지치고 힘들었던 적이 있다.

그동안 함께했던 팀원분들께 감사하다는 말을 전하고 싶다 :))

마무리

기본 학습 외에 코딩테스트 준비, 노트 정리, 이력서/포트폴리오 정리 등 중간에 스스로 굉장히 조급해하거나 스트레스 받은 적이 있다. 주위를 보면 뛰어난 친구들이 많아서 이미 취업했거나 여유 있는 사람들을 보면 너무 너무 부러웠다. 그래서 가끔씩 우울해하거나 의욕을 잃을 때가 있었다.

이때 강사님이 해주신 말이 기억하는데, 남들과 비교하지 말고 과거에 나랑만 비교하라는 말씀이셨다. 정말 맞는 말인 것 같다. 이제부터라도 그냥 계속 꾸준히 가는 방법 밖에 없지만, 남들과는 비교하지 말고 과거의 나만 비교하자.

나는..할 수 있어..!!

부트캠프가 12월에 딱 끝나니까 올해를 마무리하는 느낌도 들고 뭔가 기분이 조금 싱숭생숭하다.

7개월 전에 비해 나를 비교한다면:

부트캠프 이전에는 그냥 두루뭉실 벡엔드라는 분야를 알고 있었지만 이 분야가 얼마나 큰지 체감하지 못했다. (약간 그 빙산 짤? 처럼 내가 얼마나 모르고 있었는지 체감하게 되었다..).
학습하는 습관이 생겼고, 코딩이나 협업에 대해서 더 자신감이 생겼다.

아쉬웠던 점도 있다.

체력과 건강 문제로 가끔씩 빠졌던 것이 생각나는데, 시간을 좀 더 효율적으로 잘 썼었더라면 하는 후외가 조금 있다.
초급, 중급 프로젝트 리팩토링을 시간상 문제로 하지 못한게 아쉽다. (프로젝트들을 끝내면 바로 9-7 강의가 이어진다).

개인적으로 이 모든 것을 종합해보면 아쉬운 부분도 있지만 그래도 결과적으로 만족스럽게 마칠 수 있었다.

하지만 아직 주니어 개발자로서 준비는 덜 된 것 같다. 그동안 못해왔던 기술 모의 면접, 코딩테스트 공부, 이력서/포폴 다듬기 등 해야할 일이 꽤 많이 남았다.

그래서 앞으로는:

포트폴리오랑 이력서 완료하기
면접 연습과 기본적인 기술 질문들 복습
꾸준히 코딩테스트 준비

가 일단... 내 계획이긴 하다.

마지막에 온라인 수료식이 있었는데, 젭에서 아바타로 모이니까 너무 귀여웠다 ㅋㅋ

마지막 mopl 팀!

아이스브레이킹부터 퀴즈 세션, 수료식까지 마지막까지 재미있게 시간을 보낼 수 있었다.

온라인 수료식 스크린샷

ㅋㅋ 중간에 웃겨서 스샷함

퀴즈부분 상품을 타서 받은 기프티콘 ㅋㅋ

마지막에는 진짜 뿌듯했다ㅎㅎ.

하지만 개발자로서 여정은 아직 끝나지 않았으므로 계속 열심히 달릴 예정이다!

마지막까지 함께했던 스프린터 분들이랑 강사님이랑 멘토님들께 다시 한번 감사의 말씀을 드립니다!!

다들 멋진 개발자가 되는 날까지 화이팅입니다 :)

[모두의 플리] ES 성능 테스트!

leejunkim — Tue, 9 Dec 2025 17:53:12 +0900

ES 검색기능을 구현 후, 성능 테스트를 해봤다.

먼저 TimeConfiguration을 빈드로 수동 등록해줘야 했다:

@Configuration
public class TimerConfiguration {
  @Bean
  public TimedAspect timedAspect(MeterRegistry meterRegistry) {
    return new TimedAspect(meterRegistry);
  }
}

ContentController:

  @Timed("search.sql")
  @GetMapping("/test/sql")
  public CursorResponseContentDto findContentsRepository(@Valid @ModelAttribute ContentSearchRequest request) {
    log.info("[콘텐츠 목록 조회 요청] contentRepository - request={}", request);

    CursorResponseContentDto response = contentService.findContents(request);

    log.info("[콘텐츠 목록 조회 응답] contentRepository - resultCount={}",
        response.data() != null ? response.data().size() : 0);
    return response;
  }

  @Timed("search.request")
  @GetMapping("/test/es")
  public CursorResponseContentDto findContentsEsRepository(@Valid @ModelAttribute ContentSearchRequest request) {
    log.info("[콘텐츠 목록 조회 요청] contentEsRepository - request={}", request);

    CursorResponseContentDto response = contentService.findContentsEsRepository(request);

    log.info("[콘텐츠 목록 조회 응답] contentEsRepository - resultCount={}",
        response.data() != null ? response.data().size() : 0);
    return response;
  }

테스트용 컨트롤러 엔드포인트 2개를 만들었다. 하나는 sql db를 조회하고, 하나는 es db를 조회한다.

테스트 환경이었는데, ddl-auto: update로 해놔서 데이터를 새로 불러올 필요가 없었고, sql db와 es db는 동기화를 마친 상태였다.

마지막으로 actuator에 metrics를 추가했다

management:
  endpoints:
    web:
      exposure:
        include: health, info, metrics, prometheus
  endpoint:
    health:
      show-details: always

테스트를 해야하므로 Postman으로 각 엔드포인트에 리퀘스트를 3번 보내봤다:

http://localhost:8080/api/contents/test/sql?keywordLike=안녕&limit=10&sortBy=createdAt&sortDirection=DESCENDING

http://localhost:8080/api/contents/test/es?keywordLike=안녕&limit=10&sortBy=createdAt&sortDirection=DESCENDING

SQL (http://localhost:8080/actuator/metrics/search.sql)

ES (http://localhost:8080/actuator/metrics/search.request)

총 3번 리퀘스트를 각 엔드포인트로 보냈는데, 평균 시간을 계산해보면

SQL: 평균 = TOTAL_TIME / COUNT = 1.841346299/3 = 0.61378209966 초 (613 ms)
ES: 평균 = TOTAL_TIME / COUNT = 0.529007001/3 = 0.176335667 초 (176 ms)

3개의 리퀘스트 기준으로 보니까 ES가 약 3.5배 정도 빠르다는 것을 확인했다!

[모두의 플리] 트러블슈팅 - 실시간 시청 세션 동기화와 Race condition

leejunkim — Tue, 2 Dec 2025 14:33:27 +0900

내가 짰던 코드 흐름

WatchingSessionController
- 현재 시청자 목록을 조회(GET)하여 화면에 렌더링하는 역할
WebSocketEventListener
- SessionSubscribeEvent 발생시 여기서 시청 세션 (WatchingSession 엔티티)를 생성하고, 그 정보를 가져다 payload로 보내서 실시간 입장 브로드캐스트
- SessionUnsubscribeEvent / SessionDisconnectEvent 발생 시 삭제된 WatchingSession 의 정보를 가져다 payload로 보내서 실시간 퇴장 브로드캐스트
- 결국 화면에 보이는 실시간 참여자 수를 실시간으로 업데이트가 되게 해준다.
컨트롤러의 조회 API는 이미 들어와 있던 사람들 정보를 볼 수 있게 해주고, WebSocketEventListener는 새로 들어온 "나"의 정보를 목록조회에 더한다.

문제 상황

페이지 진입 시, DB에는 데이터가 있는데 화면에는 시청자 수가 잘못 표시되는 현상이 발생했다. 보니까 watchingSession을 GET할때 빈 데이터를 받아오지만, DB를 확인해보면 또 데이터는 정상적으로 저장되어 있었다.

원인 분석

HTTP 요청(Controller)과 WebSocket 연결(Listener) 간의 실행 순서 불일치(Race Condition)가 원인이었다.
- 초기 진입 시 - WebSocket 핸드셰이크 비용으로 인해 연결이 늦게 맺어지고 SessionSubscribeEvent도 늦게 발행된다.그래서 HTTP GET 요청이 먼저 실행될때 아직 DB 저장 전이므로, 빈 목록을 조회했던 것이다.
- 이후 WebSocketEventListener의 SessionSubscribeEvent가 실행됨 - 뒤늦게 DB에 저장되지만, 클라이언트는 이미 빈 목록을 받은 상태.
- 로그를 확인해보니까 순서가 이렇게 되어있었다.

2025-12-01T13:59:56.790+09:00  INFO 17648 --- [mopl] [nio-8080-exec-4] .w.r.CustomWatchingSessionRepositoryImpl : [Repository] findWatchingSessions called with: userId=1e084ee4-95aa-4346-b8c5-1fab1ea9c2d5, contentId=0d07f1d0-e2d2-45c3-a964-1f525b32d7a4, watcherNameLike=null, cursor=null, idAfter=null, limit=51
2025-12-01T13:59:56.803+09:00  INFO 17648 --- [mopl] [nio-8080-exec-4] .w.r.CustomWatchingSessionRepositoryImpl : [Repository] Total sessions in DB for contentId 0d07f1d0-e2d2-45c3-a964-1f525b32d7a4: 0
...
2025-12-01T13:59:57.161+09:00  INFO 17648 --- [mopl] [nio-8080-exec-5] c.c.m.e.w.WebSocketEventListener         : [WebsocketEventListener] handleSessionSubscribe 시작 - sessionId: nzlculvh, destination: /sub/contents/0d07f1d0-e2d2-45c3-a964-1f525b32d7a4/watch
2025-12-01T13:59:57.161+09:00  INFO 17648 --- [mopl] [nio-8080-exec-5] c.c.m.e.w.WebSocketEventListener         : [WebsocketEventListener] getContentId 시작 - destination: /sub/contents/0d07f1d0-e2d2-45c3-a964-1f525b32d7a4/watch
2025-12-01T13:59:57.161+09:00  INFO 17648 --- [mopl] [nio-8080-exec-5] c.c.m.e.w.WebSocketEventListener         : [WebSocketEventListener] 컨텐트 아이디 파싱 완료: contentId=0d07f1d0-e2d2-45c3-a964-1f525b32d7a4
2025-12-01T13:59:57.161+09:00  INFO 17648 --- [mopl] [nio-8080-exec-5] c.c.m.e.w.WebSocketEventListener         : [WebsocketEventListener] getUser 시작 - sessionId: nzlculvh
2025-12-01T13:59:57.169+09:00  INFO 17648 --- [mopl] [nio-8080-exec-5] c.c.m.e.w.WebSocketEventListener         : [WebsocketEventListener] getUser 완료 - userId: 1e084ee4-95aa-4346-b8c5-1fab1ea9c2d5
2025-12-01T13:59:57.169+09:00  INFO 17648 --- [mopl] [nio-8080-exec-5] c.c.m.e.w.WebSocketEventListener         : [WebsocketEventListener] 서비스 - DB 저장 시작: sessionId=nzlculvh
2025-12-01T13:59:57.289+09:00  INFO 17648 --- [mopl] [nio-8080-exec-5] c.c.m.e.w.WebSocketEventListener         : [WebsocketEventListener] 서비스 - DB 저장 성공: sessionId=nzlculvh
2025-12-01T13:59:57.331+09:00  INFO 17648 --- [mopl] [nio-8080-exec-5] c.c.m.e.w.WebSocketEventListener         : [WebsocketEventListener] handleSessionSubscribe 완료 - userId: 1e084ee4-95aa-4346-b8c5-1fab1ea9c2d5, contentId: 0d07f1d0-e2d2-45c3-a964-1f525b32d7a4, watcherCount: 1

시도 1

시도 1 (책임 분리): 세션 생성을 HTTP 요청 시점으로 이동하고, WebSocket은 SubscribeEvent가 발행할때 세션을 조회하는 로직으로 바꿨다 (여기서 이제 생성+저장은 안함).
- 결과: 첫 진입은 해결되었지만, 그 이후 다른 컨텐츠 클릭 시 WebSocket 이벤트가 HTTP 요청보다 먼저 터졌다.
  - 이때 SubscribeEvent시 DB에 데이터가 없어 실시간 시청자 수와 정보가 제대로 업데이트가 안됐었다.

그 이유는 웹소켓은 최초 연결 시에만 느리고, 그 이후에는 GET보다 빠르게 실행됐었다.
- 최초 진입때는 브라우저가 서버와 TCP 연결을 맺고, 다시 HTTP 업그레이드 요청을 보내서 웹소켓으로 전환하는 과정이 필요하고 단순 HTTP 요청보다 무겁다.

시도 2 (해결)

최종적으로, HTTP와 WebSocket 중 누가 먼저 도착할지 보장할 수 없다는 점을 인지하고 로직을 변경했다.
- 양쪽 진입점(Controller, EventListener) 모두에서 joinSession() 메서드를 호출하게 했다.
- joinSession 메서드
  - 이미 세션이 존재하면 반환하고, 없으면 새로 생성하는 로직을 구현해서 실행 순서와 관계없이 데이터 정합성을 보장했다.

정리
- 초반에 최초 연결할 때는 컨트롤러로 GET 메서드가 먼저 불려서 joinSession을 호출하면 새로운 WatchingSession이 생성+저장된다. 그리고 이제 최초 웹소켓 연결이 맺어질때 SessionSubscribeEvent가 발행하고 마찬가지로 joinSession을 부른다. 이때 이미 컨트롤러가 데이터를 저장했으므로 그냥 있는 데이터를 가져온다.
- 그 이후에는, 이미 웹소켓 연결이 됀 상태라 SessionSubscribeEvent가 GET 보다 더 빨리 호출된다. 그래서 이떄는 웹소켓 쪽에서 먼저 joinSession을 호출하고 데이터를 생성+저장하고, 그 이후 컨트롤러의 GET이 호출되서 이미 저장된 데이터를 조회한다.
결과적으로, 새로고침(Cold Start)과 페이지 이동(Warm Connection) 모든 상황에서 시청자 목록 조회 및 실시간 입장 알림이 정확하게 동작함을 확인했다.

Elastisearch 토이 프로젝트 만들어보기 (프로젝트를 위한 준비..)

leejunkim — Thu, 27 Nov 2025 17:00:50 +0900

https://www.youtube.com/@liliumbosniacumcode/videos

Lilium Code

Trying to share my knowledge as best as I can. All code is available on github https://github.com/liliumbosniacum

www.youtube.com

이분이 올리신 강의를 따라하면서 받아적은 노트들이다!

elasticache를 사용하기 위해 일단 docker compose를 만들었다:

version: '3.7'

services:
  elasticsearch:
    image: docker.elastic.co/elasticsearch/elasticsearch:7.17.10
    container_name: elasticsearch
    environment:
      - node.name=elasticsearch
      - discovery.type=single-node
      - cluster.name=docker-cluster
      - bootstrap.memory_lock=true
      - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
      # 보안 설정 (비밀번호 설정하고 싶으면 true, 귀찮으면 false)
      # 공부용/로컬용은 보통 끄고 하거나, 켜더라도 간단하게 설정
      - xpack.security.enabled=false
    ports:
      - "9200:9200"
    ulimits:
      memlock:
        soft: -1
        hard: -1
    volumes:
      - es_data:/usr/share/elasticsearch/data

# http://localhost:5601
  kibana:
    image: docker.elastic.co/kibana/kibana:7.17.10
    container_name: kibana
    environment:
      - ELASTICSEARCH_HOSTS=http://elasticsearch:9200
    ports:
      - "5601:5601"
    depends_on:
      - elasticsearch

volumes:
  es_data:
    driver: local

RegisterConfig:

@Configuration
@EnableElasticsearchRepositories(basePackages = "personal.estoyproject.repository")
public class RegisterConfig extends ElasticsearchConfiguration {

  @Value("${register.elasticsearch.user}")
  private String username;

  @Value("${register.elasticsearch.password}")
  private String password;

  /*
  where u put all things u need to connect to elastisearch
  - includes address, port, authorization, etc
  - use builder for client config
   */
  @Override
  public ClientConfiguration clientConfiguration() {

      return ClientConfiguration.builder()
          .connectedToLocalhost() // in production use smth else
          .build();
  }
}

그리고 이런 식으로 간단하게 Person이라는 Document와 인덱스를 설정할 수 있다:

@Document(indexName = "person")
@Getter
@Setter
public class PersonDocument {
  private String id;
  private String name;
}

그리고 이어서 간단하게 PersonDocument를 저장하는 컨트롤러, 서비스, 리포지토리를 만들어줬다.

/*
  Controller
*/
@RestController
@RequiredArgsConstructor
@RequestMapping("/api/person")
public class PersonController {

  private final PersonService personService;

  @PostMapping
  public void save(@RequestBody final PersonDto personDto) {
    personService.save(personDto);
  }
}

/*
  Service
*/
@Service
@RequiredArgsConstructor
public class PersonService {

  private final PersonRepository personRepository;
  private final PersonMapper personMapper;

  public void save(final PersonDto dto) {
    final PersonDocument document = personMapper.convertToDocument(dto);
    if (document == null) return;
    personRepository.save(document);
  }
}


/*
  Repository
*/
public interface PersonRepository extends ElasticsearchRepository<PersonDocument, String> {
}

이제 docker compose up 명령 + 어플리케이션을 실행을 하고 http://localhost:5601 (키바나) -> console에 들어갔다.

여기에서 GET _cat/indeces를 하면 아직 INSERT해서 document를 넣지 않았는데도 person index가 존재하는 것을 볼 수 있다.

person만 Yellow다
- Green - 모든 데이터(primary)와 복제본 (replica)이 안전하게 저장됨
- Yellow - 데이터는 있는데 복제본을 저장할 곳이 없다
  - person 만 Yellow인 이유: ES는 기본적으로 인덱스를 만들 때 백업본을 1개 만든다. 하지만 현재 토이 프로젝트에서는 docker compose로 노드 1대만 띄우고 있는데, ES의 원칙상 원본과 복제본은 절대 같은 노드에 두지 않는다. 그래서 원본은 저장했는데 복제본을 저장할 다른 노드가 없어서 yellow 상태로 대기중인 것이다.
- Red - 데이터 유실

Postman으로 PersonDto를 테스트로 생성해봤다:

저렇게 데이터가 들어온 것을 볼 수 있다.

하지만 @Document를 사용하는건 명확한 한계가 있다. 이건 자동 방식 (automatic)쪽에 속한다.

tokenizer, filter, analyzer (분석기) 설정을 정교하게 넣기가 어렵다.
- 수동 방식 (client를 사용)은 settings.json 파일을 따로 만들어서 분석기 설정을 우너하는 만큼 복잡하게 넣을 수 있다.
운영 안정성도 있다
- 만약 팀원 A가 실수로 @Document 설정을 바꾸고 배포했다가, 기존 데이터 매핑이 꼬여버리면 그냥 대형 사고가 일어나는 것이다.
- 그래서 실무에는 인덱스 생성은 배포 전에 관리자가 따로 (kibana나 script로) 하고, 스프링 앱은 이미 만들어진 인덱스를 쓰기만 하는 원칙을 많이 따른다.

새로 만든 IndexService

@Slf4j
@Service
@RequiredArgsConstructor
public class IndexService {

  private final ElasticsearchClient client;

  public void createIndices() {
    List<IndexInfo> indexInfos = getIndexInformation();

    if (CollectionUtils.isEmpty(indexInfos)) { // exception or no docs
      return;
    }

    for (IndexInfo indexInfo : indexInfos) {
        deleteIndex(indexInfo);
        createIndex(indexInfo);
      }
  }


  // ======================

  private void deleteIndex(IndexInfo indexInfo) {
    try {
      BooleanResponse exists = client.indices().exists(e -> e.index(indexInfo.indexName()));
      if (!exists.value()) {
        return;
      }

      client.indices().delete(d -> d.index(indexInfo.indexName()));
    } catch (Exception e) {
      log.error("{}", e.getMessage(), e);
    }
  }

  private void createIndex(IndexInfo indexInfo) {
    try {
      // can add mapping here
      client.indices().create(c -> c.index(indexInfo.indexName()));
    } catch (Exception e) {
      log.error("{}", e.getMessage(), e);
    }
  }
  private List<IndexInfo> getIndexInformation()  {
    final var scanner = new ClassPathScanningCandidateComponentProvider(false);

    // ======== include filter ========
    // class of annotation we want to scan
    scanner.addIncludeFilter(new AnnotationTypeFilter(Document.class));

    // tells where to scan
    final Set<BeanDefinition> beanDefinitionSet = scanner.findCandidateComponents("personal.estoyproject");

    // iterate over bean definitions
    // - extract info from bean def, like index name
    return beanDefinitionSet.stream()
        .map(IndexService::getIndexName)
        .filter(Objects::nonNull)
        .map(IndexInfo::new)
        .toList();
  }


  private static String getIndexName(BeanDefinition definition)  {
    try {
      final Class<?> documentClass = Class.forName(definition.getBeanClassName());
      Document annotation = documentClass.getAnnotation(Document.class);
      return annotation.indexName();
    } catch (ClassNotFoundException e) {
      log.error("{}", e.getMessage(), e);
      return null;
    }
  }
}

강의를 따라하면서 IndexSerivice를 구현하게 되었다. 메인 함수는 createIndices()다:

먼서 @Document라고 붙은 class를 다 찾아내서 List<IndexInfo> 형태로 받아온다
그 리스트를 순회하면서, 이미 같은 이름의 인덱스가 있으면 삭제하고 새로 만든다.

짧은 IndexController

@RestController
@RequestMapping("/api/index")
@RequiredArgsConstructor
public class IndexController {

  private final IndexService indexService;

  @PostMapping
  public void create() {
    indexService.createIndices();
  }

}

어플리케이션 실행 -> Delete person (키바나) -> 포스트맨으로 POST http://localhost:8080/api/index를 부름 -> 키바나에서 GET _cat/indices을 실행할때 person이 보인다

이렇게 하는 이유는 깨끗한 상태 보장 -> 테스트 데이터를 다시 초기화 하고 싶을때 유용한 것 같다. (중간에 Document 설정이 바뀌었을 수도 있고, 스키마 변경이 까다로워서 그냥 밀고 다시 만드는게 편함).

하지만 운영 환경에서는 절대 이렇게 쓰지 않는다.

이제 매핑을 추가해보자:

PersonDocument

@Document(indexName = "person")
@Getter
@Setter
@Mapping(mappingPath = "static/person.json")
// if we use repos to create documents, this is enough
// but if we're using indexservice (like creating our own)
public class PersonDocument {
  private String id;
  private String name;
}

이제 @Document를 단 모든 클래스를 뒤질 때 @Mapping이 static/person.json이라고 되어있는 걸 인식한다.
이제 person이라는 index를 만들때 person.json파일을 사용한다

IndexInfo

public record IndexInfo(
    String indexName,
    String mappingPath
) {

}

/static/person.json

{
  "properties": {
    "id": {
      "type" : "keyword"
    },
    "name" : {
      "type" : "text"
    }
  }
}

수정된 IndexService

@Slf4j
@Service
@RequiredArgsConstructor
public class IndexService {

  private final ElasticsearchClient client;
  private final ResourceLoader resourceLoader;

  public void createIndices() {
    List<IndexInfo> indexInfos = getIndexInformation();

    if (CollectionUtils.isEmpty(indexInfos)) { // exception or no docs
      return;
    }

    for (IndexInfo indexInfo : indexInfos) {
        deleteIndex(indexInfo);
        createIndex(indexInfo);
      }
  }


  // ======================

  private void deleteIndex(IndexInfo indexInfo) {
    try {
      BooleanResponse exists = client.indices().exists(e -> e.index(indexInfo.indexName()));
      if (!exists.value()) {
        return;
      }

      client.indices().delete(d -> d.index(indexInfo.indexName()));
    } catch (Exception e) {
      log.error("{}", e.getMessage(), e);
    }
  }

  private void createIndex(IndexInfo indexInfo) {
    try {
      // can add mapping here
      client.indices()
          .create(c -> c.index(indexInfo.indexName())
            .mappings(t -> t.withJson(getMappings(indexInfo.mappingPath())))
          );
    } catch (Exception e) {
      log.error("{}", e.getMessage(), e);
    }
  }

  private List<IndexInfo> getIndexInformation()  {
    final var scanner = new ClassPathScanningCandidateComponentProvider(false);

    // ======== include filter ========
    // class of annotation we want to scan
    scanner.addIncludeFilter(new AnnotationTypeFilter(Document.class));

    // tells where to scan
    final Set<BeanDefinition> beanDefinitionSet = scanner.findCandidateComponents("personal.estoyproject");

    // iterate over bean definitions
    // - extract info from bean def, like index name
    return beanDefinitionSet.stream()
        .map(IndexService::getIndexInfo)
        .filter(Objects::nonNull)
        .toList();
  }


  private static IndexInfo getIndexInfo(BeanDefinition definition)  {
    try {
      final Class<?> documentClass = Class.forName(definition.getBeanClassName());
      Document document = documentClass.getAnnotation(Document.class);
      Mapping mapping= documentClass.getAnnotation(Mapping.class);
      return new IndexInfo(
          document.indexName(),
          mapping.mappingPath()
      );
    } catch (ClassNotFoundException e) {
      log.error("{}", e.getMessage(), e);
      return null;
    }
  }
  
  private InputStream getMappings(final String mappingPath) {
    Resource resource = resourceLoader.getResource("classpath:" + mappingPath);
    try {
      return resource.getInputStream();
    } catch (IOException e) {
      log.error("{}", e.getMessage(), e);
      return null;
    }
  }
}

이제 키바나로 가서 GET person/_mappings를 해주면 아까 static/person.json 파일이 나온다:

[AWS] Elastisearch Analyzer- 데이터가 검색되는 원리(텍스트 분석/처리)

leejunkim — Thu, 27 Nov 2025 11:00:37 +0900

근본 - 검색이 잘되도록 데이터를 저장하면 된다..!

문서는 ES DB에 저장되기 전에, 분석기(Analyzer)라는 과정을 한번 거친다.

[10분 테크톡] 다로의 Elasticsearch - https://youtu.be/0r0-R8NhINs?si=g5YVVlwOVGTQOUXa

정확하게 말하면, 문서의 필드 타입 중에 TEXT라는 문장들은 분석기를 거치고 DB에 저장된다!
분석기에는 Character Filter, Tokenizer, Token Filter이 있다

여기서 잠깐 - TEXT vs KEYWORD

ES에서 문자열을 저장하는 타입은 크게 두가지다 - 그냥 분석기를 거치냐 안거치냐의 차이다.
TEXT
- 분석기를 통해 문장이 토큰 (단어)로 쪼개진다.
- 전문 검색 (full text search)에 쓰이는데, 예를 들면 "애플 맥북 프로"라고 저장해두고 "맥북"만 검색해도 찾고 싶을 때 사용된다.
- 이 블로그 글은 TEXT 기반의 예시로 작성됐다.
KEYWORD
- 분석기를 거치지 않고 문장 통째로 하나의 토큰으로 저장된다!
- 용도는 정확한 일치 검색, 필터링, 정렬, 집계 등이 있다.
- 보통 카테고리("가전"), 브랜드명("Apple"), 상태("판매중") 같은 데이터에 사용된다.
보통 제목이나 내용은 text로, 카테고리나 태그는 keyword로 설정한다고 한다.

Analyzer (분석기)

Analyzer(분석기)
- 분석기는 텍스트를 처리하는 전체 파이프라인이다.
- Character Filter, Tokenizer, Token Filter로 이 3가지의 과정을 거친다
다양한 분석기가 있음
- 모든 분석기는 위의 파이프라인이 포함되고, 분석기마다 다른 filter/tokenizer를 사용함
- Standard analyzer (기본, 영어에 최적)
- Nori Analyzer (한국어)
- Whitespace Analyzer
  - 오직 공백 (띄어쓰기)만 기준으로 함
- Keyword Analyzer
  - 자르지 않고 입력된 문장 전체를 하나의 토큰으로 함
- Custom Analyzer (커스텀)
  - 실무에서는 기본 세트를 쓰는 것보단 필요한 것들을 조립해서 커스텀 분석기를 만드는 경우가 많음

1단계 - Character Filter

원본 문자 스트림을 입력받아 문자 단위의 전처리 (추가, 제거, 변경)를 수행한다.

[10분 테크톡] 다로의 Elasticsearch - https://youtu.be/0r0-R8NhINs?si=g5YVVlwOVGTQOUXa

2단계 -Tokenizer

Character Filter가 전처리한 문자 스트림을 받아 검색의 기본 단위인 토큰으로 분리한다. 텍스트 분석 과정 중 가장 큰 영향을 끼치는 단계이다!

[10분 테크톡] 다로의 Elasticsearch - https://youtu.be/0r0-R8NhINs?si=g5YVVlwOVGTQOUXa

분석 과정 중에서 토크나이저는 딱 한 개만 사용 가능하다.
standard (공백 기준, 특수 문자 제거), letter (공백,기호,숫자), whitespace(오직 공백), 한글 형태소 분석기(nori) 등
- 다양한 토크나이저 형태는 이 블로그에 잘 정리되어있다: https://m.blog.naver.com/shino1025/222313469941
- 커스텀 토크나이저를 만드는 것도 가능하다!

3단계 -Token Filter

Tokenizer가 생성한 토큰 스트림을 입력받아 토큰 자체를 수정/추가/제거하는 후처리 (post processing)을 담당한다.

[10분 테크톡] 다로의 Elasticsearch - https://youtu.be/0r0-R8NhINs?si=g5YVVlwOVGTQOUXa

만약에 사용하가 "셔츠"라고 검색했지만 판매자는 상품명을 "shirt"라고 영어로 등록했을 수도 있다.
- 이때 개발자가 직접 사전을 넣어주어야 한다. 현재 Token Filter 단계에서 synonym 필터를 끼워 넣고, 개발자가 설정 파일에 셔츠, shirt라고 적어둔다.
- 그러면 만약에 ["블루", "셔츠"] 라는 토크나이저 데이터가 들어올 때, 토큰 필터는 "셔츠"랑 "shirt"가 동의어로 인식해서 ["블루", "셔츠", "shirt"] 로 토큰을 추가한다. 그 결과 인덱스에 "shirt'도 같이 저장된다.
- 이제 사용자가 "shirt"로 검색해도 "블루 셔츠"가 검색된다.
이제 결과를 저장하는 것만 남았다.

역색인 저장

낱말이나 숫자와 같은 내용물로부터의 매핑 정보를 데이터베이스 파일의 특정 지점이나 문서 또는 문서 집합 안에 저장하는 색인 데이터 구조다. (포스팅 1에서 잠깐 다뤘다 - https://leejunkim.tistory.com/68)
토큰들을 역색인을 하면, 단어를 기준으로 문서 아이디를 배열 형태로 가지고 있다

[10분 테크톡] 다로의 Elasticsearch - https://youtu.be/0r0-R8NhINs?si=g5YVVlwOVGTQOUXa

위에 보이는 Term | Document 구조는 한 샤드 내부의 데이터 구조라고 생각하면 된다.

검색이 이루어 지는 과정

영어 단어 "shirts"로 검색을 한다
Term에서 shirts를 찾고, 문서 아이디 1,2를 찾는다
아이디 1,2를 가진 문서들을 찾아서 반환한다

더 큰 시나리오로 이해하기

데이터가 100만 개가 있다고 치고, 이 데이터를 한번에 관리하기 힘들어서 이걸 5개로 쪼갰다고 치자.

저장 과정:
- 문서 1~20만 -> 1번 샤드 안에 작은 역색인 테이블로 저장
- 문서 21~40만 -> 2번 샤드 안에 작은 역색인 테이블로 저장
- ... (이렇게 분산됨)
- 그리고 이 샤드들은 여러 노드(컴퓨터)에 분산되어 저장된다
검색 과정 (분산 처리):
1. 사용자가 "shirts"를 검색함
2. 요청을 받은 노드는 모든 샤드에게 각자 가지고 있는 테이블 (역색인) 안에서 "shirts"찾으라는 명령을 내림
  - 1번 샤드의 테이블에는 1, 5번 문서에 있고 2번 샤드의 테이블엔 25번 문서에 있다는 걸 발견
3. 결과를 취합해서 사용자에게 1, 5, 25번 문서를 반환함

자료

[10분 테코톡] 다로의 Elasticsearch
- 이 포스팅은 주로 이 영상의 내용을 정리한 글이다 ㅜㅜ! 정말 많이 도움이 됐다.
[Elasticsearch 입문] 토크나이저 - Tokenizer

[AWS] Elastisearch - 인프라 기본 개념 정리

leejunkim — Wed, 26 Nov 2025 17:41:56 +0900

모두의 플리 프로젝트를 하는 도중 Elastisearch를 사용해서 고도화하는 부분을 맡게 되었다.

컨텐츠 검색 리팩토링 - Elastisearch의 Full Text Search 기능을 활용하여 개선
Elastisearch 배포 - Docker을 사용하여 로컬 환경에 구축하거나 AWS OpenSearch 서비스를 활용

Elastisearch

데이터가 json 문서 (document) 형태로 저장되는 분산형 NoSQL 데이터베이스
수평적 확장이 가능하고 데이터베이스를 여러 서버 (노드)에서 실행할 수 있음
텍스트, 숫자, 지리 공간(Geo-spatial) 데이터, IP 주소 등 다양한 데이터 타입을 지원

인덱스(Indexes), 문서 (Document)

위에서 언급했듯이, Elasticsearch는 문서형 데이터 베이스다 (NoSql).

인덱스 (Index)
- 문서로 이루어짐
- 하나 이상의 물리적 샤드들의 논리적 그룹
- 예) Employee라는 전체 데이터
- 테이블 같은 구조
문서 (Document)
- 인덱스 안에 있는 개별 데이터 (가장 작은 단위의 데이터)
- 예) {"name":"John", "location":"Mumbai", "Age":24, "Email":"abc@gmail.com"}
- 레코드 같은 구조
장점: JSON을 색인(삽입) 하면 ES는 문서를 불변으로 저장을 한다!
- 동시 읽기 -> 불변이여서 Lock 메커니즘이 없고 높은 수준의 동시 읽기 성능 제공 + 여러 스레드가 동기에 동일한 문서를 읽을 때 데이터 충돌 발생할 위험도 없음
- 효율적인 시스템 캐시 활용 -> 오랫동안 데이터가 변하지 않아 OS 캐시와 ES 내부 데이터 구조 캐시를 오랫동안 재활용하는 것이 가능
단잠: 높은 쓰기 비용
- UPDATE시 필드 하나만 바꾸는 것이 아닌 문서 전체를 삭제하고 새로운 문서로 재색인

Forward VS Inverted Index

데이터 문자가 그대로 검색을 위해 저장되는 형태다 -> 그래서 쿼리 속도가 매우 빠르다.

샤드 (Shard)

데이터베이스 시스템에서 데이터를 수평으로 분할 (partitioning)하여 저장하는 가장 작은 물리적 단위
- 실제로 문서들이 저장될 때 사용되는 물리적인 공간이라고 생각하면 됌
위에서 언급했듯이, Index는 하나 이상 샤드로 이루어져 있음
샤드의 종류
- 프라이머리(Primary) 샤드 - 원본 데이터가 저장되는 샤드
- 레플리카(Replica) 샤드 - 데이터 이중화(Redundancy)와 검색 쿼리 처리를 위한 복제본
샤드 하나는 그 자체로 완전한 기능을 갖춘 루씬(Lucene) 검색 엔진임!
- Elasticsearch는 Java로 작성된 Apache Lucene 라이브러리를 사용
- 하나의 샤드 안에는 독자적인 역색인(Inverted Index) 구조, 문서 저장소, 검색 로직이 모두 들어있음

Elasticsearch가 클러스터 환경에서 데이터를 관리할 때 이동시키거나 복제하는 단위가 바로 샤드다
- 문서(Document)가 저장될 때, Elasticsearch는 문서 ID의 해시값을 계산하여 어떤 샤드에 저장할지 결정(Routing)함 (예: shard_num = hash(_id) % total_primary_shards)

사용자가 검색 요청을 보내면, Elasticsearch는 이 요청을 해당 인덱스를 구성하는 모든 샤드에 병렬로 전송한다. 각 샤드는 자신이 가진 데이터 내에서 독립적으로 검색을 수행하고, 그 결과를 반환한다.
- 위 예시처럼 노드가 2대 있고 하나의 인덱스에 샤드게 3개 있다면, Elasticsearch는 이 샤드들을 각 노드에 분배해준다.
- 이때 유저가 이 cluster에 query를 날린다면, 두 노드 다 이 쿼리를 병행으로 받고 결과를 반환한다.

수평 확장과 Cluster

Cluster
- ES에서 사용되는 가장 큰 단위, 여러대의 서버를 가지고 있음
Node
- ES를 실행하는 컴퓨터(서버) 한 대
- 샤드들을 가지고 있음

예시 1: Product 레코드가 90개가 있고 샤드를 3으로 나눌 때, 인덱스가 저장될 때 3등분 해서 저장이 됨

[10분 테크톡] 다로의 Elasticsearch - https://youtu.be/0r0-R8NhINs?si=g5YVVlwOVGTQOUXa

이렇게 서버가 여러개이기 때문에, 검색을 할 때 한번에 90건을 검색하는게 아니라 각각 30건을 검색하기 때문에 검색 속도가 빠르다!
여기서 P는 원본 데이터를 저장하는 Primary shard다

예시 2: Product 레코드 90개와 샤드 3, 그리고 User

먼저 샤드들을 설정을 하고, 그 샤드에 맞게 노드들이 샤드들을 분배받고 있는 상황 (남는 샤드가 있음)

[10분 테크톡] 다로의 Elasticsearch - https://youtu.be/0r0-R8NhINs?si=g5YVVlwOVGTQOUXa

Product의 index부터 샤드에 저장되기 시작
- 예시 1와 같이 P1-P3 (primary shard)가 각각 A-C 노드에 저장됨
- 그 이후에 R1-R3 (replica shard)가 각각 A-C 노드에 저장됨
  - 서버에서 문제가 생기면 각 서버 안에 있는 레플리카에서 문서를 찾을 수 있음
Users도 저장하기 시작
- User 같은 경우 노드B에 primary shard, 노드 C에 replica shard가 저장

인덱스 템플릿 (Index Template)

인덱스가 생성될 때 적용되는 설정값이다 (blueprint)

샤드/레플리카의 갯수, 우선순위 등 설정 포함
데이터 매핑 - 인덱스에 저장될 문서의 스키마/구조 정의
- 동적 매핑 (dynamic) - 데이터가 수집되는 시점에 스키마를 유추하고 생성 (Schema on Write)
- 엄격 매핑 (strict) - RDBMS처럼 미리 정의된 매핑 속성을 따르지 않는 문서가 들어오면 거부(reject)하도록 설정 가능

예시:

PUT _index_template/template_1
{
  "index_patterns": ["te*", "bar*"], // 이 패턴에 맞는 인덱스 생성 시 템플릿 적용
  "template": {
    "settings": {
      "number_of_shards": 1
    },
    "mappings": {
      "_source": {
        "enabled": true
      },
      "properties": {
        "host_name": {
          "type": "keyword"
        },
        "created_at": {
          "type": "date",
          "format": "EEE MMM dd HH:mm:ss Z yyyy"
        }
      }
    },
    "aliases": {
      "mydata": { }
    }
  },
  "priority": 500, // 우선순위
  "composed_of": ["component_template1", "runtime_component_template"], 
  "version": 3,
  "_meta": {
    "description": "my custom"
  }
}

인덱스 별칭 (Index Alias)

여러 인덱스를 묶어서 부르는 그룹명

별칭을 사용하여 인덱스 그룹에 문서를 삽입할 수 있음 (쓰기 인덱스 (Write Index)로 지정된 인덱스에만 문서가 저장됨
패턴 사용
- 특정 인덱스 패턴 (예: logs-*)를 따르는 모든 인덱스를 포함하도록 별칭을 지정할 수 있음

예시:

POST _aliases
{
  "actions": [
    {
      "add": {
        "index": "logs-*",
        "alias": "logs"
      }
    }
  ]
}

활용법 - 인덱스 수명 주기 관리(ILM)와 함께 사용하여, 특정 기간이나 크기 임계값에 도달하면 데이터를 새로운 인덱스로 롤오버(Rollover) 하도록 자동화할 수 있다