엄지월드

[React] 간헐적으로 데이터가 나오지 않는 현상 수정

킨글 — Sun, 11 Jan 2026 18:20:16 +0900

모집글 진입 시 아래와 같이 간헐적으로 boardDetail 데이터가 나오지 않는 현상이 있었음.

response 데이터는 정상적으로 오고 있었음.

디버깅 확인 시 화면이 여러 번 렌더링 되는것을 확인함.

그래서 아래와 같이 조치를 취해서 해결됨.

1. 렌더링 점검

2. boardDetail이 변경 되면 다시 렌더링 되도록 수정

여러번 상세 페이지 진입하여 테스트 시 데이터가 잘 나오는 것을 확인함.

JPA 동시성 제어 주의점(ConstraintViolationException 에러)

킨글 — Tue, 23 Dec 2025 07:39:53 +0900

아래와 같이 ConstraintViolationException 에러가 발생했다.

문제를 확인해보니 특정 엔티티를 업데이트하거나 삭제하려 할 때, 데이터베이스에 저장된 해당 엔티티의 상태가 애플리케이션이 엔티티를 로드했을 때와 달라졌을 때 발생하는 것이었다. 즉, 다른 트랜잭션에 의해 이미 변경되었거나 삭제되었다는 뜻인 것이다.

Caused by: org.hibernate.exception.ConstraintViolationException: could not execute statement [(conn=1338) Duplicate entry 'ejy1024@-ejy1024@_test1234@_...' for key 'PRIMARY'] [/* insert for com.connect.service.chatting.entity.RoomMembership */insert into room_memberships (joined_at,room_name,room_id,user_id) values (?,?,?,?)]
Caused by: org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [com.connect.service.chatting.entity.RoomMembership#RoomMembershipId(userId=ejy1024, roomId=ejy1024test12341766307683336)]

코드로 보자면 existsById로 확인하는 시점과 save를 호출하는 시점 사이에 다른 트랜잭션이 먼저 동일한 기본 키로 RoomMembership 엔티티를 삽입했을 때 발생할 수 있다.

val exists = roomMembershipRepository.existsById(membershipId) // 해당 유저가 이미 이 방의 멤버인지 DB에서 확인

if (!exists) { // 아직 멤버가 아니라면
   val newMembership = RoomMembership(
       id = membershipId, // 복합 키
       chatRoom = chatRoom, // 관계 매핑된 ChatRoom 엔티티
       roomName = roomName,
       joinedAt = LocalDateTime.now() // 참여 시간 기록
   )
   roomMembershipRepository.save(newMembership) // 새로운 멤버십을 DB에 저장
   return true // 성공적으로 새로 추가됨을 반환
}

순서는 이렇다.

트랜잭션 A : roomMembershipRepository.existsById(membershipId)를 호출한다.
이 시점에는 해당 RoomMembership이 DB에 없어서 exists는 false를 반환한다. 그래서 if (!exists) 블록으로 진입한다.
트랜잭션 B (거의 동시에): 트랜잭션 A가 save를 호출하기 전에, 트랜잭션 B가 먼저 같은 membershipId를 가진 RoomMembership을 생성하고 DB에 INSERT하는 데 성공한다.
트랜잭션 A (다시): 이제 트랜잭션 A가 roomMembershipRepository.save(newMembership)를 호출하여 DB에 INSERT를 시도한다.
에러 발생: 하지만 이미 트랜잭션 B가 동일한 PRIMARY KEY를 가진 RoomMembership을 삽입했으므로, DB는 PRIMARY KEY 제약 조건 위반을 감지하고 Duplicate entry '...' for key 'PRIMARY' 에러를 발생시킨다. 하이버네이트는 이를 ConstraintViolationException으로 변환하여 던지게 된다.

해결을 위해서는 아래와 같이 existsById로 먼저 확인하고 save하는 방식(read-then-write) 대신, findById를 사용하여 엔티티의 존재 여부를 확실히 확인하고 그 결과에 따라 분기 처리하는 것이 가장 안정적이라고 한다.

이유는 existsById는 단순히 존재 여부만 확인하지만, findById는 실제 엔티티를 영속성 컨텍스트로 가져오려고 시도하기 때문이다.
다시 말하면 findById는 단순히 데이터베이스를 조회하는 것을 넘어, JPA/하이버네이트의 영속성 컨텍스트(Persistence Context)와 연동하여 동작한다.
만약 현재 트랜잭션 내에서 동일한 ID를 가진 엔티티가 이미 로드되어 영속성 컨텍스트에 관리되고 있다면, DB 쿼리 없이 해당 엔티티를 즉시 반환하게 된다.

val exists = roomMembershipRepository.findById(membershipId) // 해당 유저가 이미 이 방의 멤버인지 DB에서 확인

if (exists.isEmpty) { // 아직 멤버가 아니라면
   val newMembership = RoomMembership(
       id = membershipId, // 복합 키
       chatRoom = chatRoom, // 관계 매핑된 ChatRoom 엔티티
       roomName = roomName,
       joinedAt = LocalDateTime.now() // 참여 시간 기록
   )
   roomMembershipRepository.save(newMembership) // 새로운 멤버십을 DB에 저장
   return true // 성공적으로 새로 추가됨을 반환
}
return false // 이미 존재하는 멤버임을 반환

결론

[이전]
roomMembershipRepository.existsById(membershipId)

[이후]
roomMembershipRepository.findById(membershipId)

1. Race Condition 발생 가능성이 있는 "불필요한 INSERT 시도"를 더 효율적으로 차단한다. (이미 존재한다면 findById가 엔티티를 반환하므로, if (isEmpty) 로직에 의해 save가 호출될 기회 자체가 사라진다)
2. 하이버네이트의 영속성 컨텍스트와 더 깊이 통합되어 관리된다. (엔티티 객체 자체를 가져오기 때문에)

혹은 추가적으로 아래와 같이 낙관적 잠금을 활용해도 된다.

// ChatRoom.kt
@Entity
@Table(name = "chat_room")
class ChatRoom(
    @Id
    val roomId: String,

    // ... 다른 필드들 ...

    @Version // 이 부분을 추가 (Long 타입 필드를 선언하고 @Version 어노테이션 추가)
    var version: Long? = null,
) {
    // ...

Logstash 설치

킨글 — Wed, 17 Sep 2025 14:07:33 +0900

1. Elastic GPG 키 임포트

sudo apt-get update && sudo apt-get install -y apt-transport-https # HTTPS를 통해 저장소에 접근하기 위함
wget -qO - https://artifacts.elastic.co/GPG-KEY-elasticsearch | sudo gpg --dearmor -o /usr/share/keyrings/elastic-keyring.gpg

2. Elastic 저장소 추가

echo "deb [signed-by=/usr/share/keyrings/elastic-keyring.gpg] https://artifacts.elastic.co/packages/8.x/apt stable main" | sudo tee /etc/apt/sources.list.d/elastic-8.x.list

3. 패키지 목록 업데이트

sudo apt-get update

4. Logstash 설치 시도

sudo apt-get install logstash

5. 설치 확인

/usr/share/logstash/bin/logstash --version

/etc/logstash/data 디렉토리 생성 및 소유권 설정 (다시 한번 확실하게!)

# 디렉토리가 이미 있든 없든, 안전하게 생성하고 소유권을 설정하는 명령어
sudo mkdir -p /etc/logstash/data
sudo chown logstash:logstash /etc/logstash/data
sudo chmod 755 /etc/logstash/data # 디렉토리에 대한 일반적인 읽기/실행 권한 + 소유자 쓰기 권한

기존 .logstash_jdbc_last_run_job_mst.yml 파일 삭제 (혹시 있다면!)
만약 이전에 권한 문제 등으로 빈 파일이 잘못 생성되어 접근이 안 되던 경우를 대비해서 삭제하는 거야. 이 파일은 Logstash가 없으면 자동으로 다시 생성한단다.

sudo rm -f /etc/logstash/data/.logstash_jdbc_last_run_job_mst.yml

mariaDB 설정

sudo vi /etc/logstash/conf.d/logstash-mariadb-job_mst.conf

# Logstash JDBC Input Plugin을 사용하여 MariaDB에서 데이터 동기화 설정
input {
  jdbc {
    jdbc_driver_library => "/etc/logstash/mariadb-java-client-3.1.2.jar" # <-- 이 경로가 드라이버를 둔 실제 경로여야 해!

    # MariaDB JDBC 드라이버 클래스 이름
    jdbc_driver_class => "org.mariadb.jdbc.Driver"

    jdbc_connection_string => "jdbc:mariadb://domain:30121/travel?autoReconnect=true&serverTimezone=Asia/Seoul"
    jdbc_user => "id" # MariaDB 사용자 이름
    jdbc_password => "pw" # MariaDB 비밀번호

    # Logstash 스케줄: */5 * * * * (매 5분마다 실행)
    schedule => "*/5 * * * *"

    # 동기화할 데이터를 가져올 SQL 쿼리
    # 'job_mst' 테이블에 'updated_at' 컬럼이 있다는 전제로 증분 동기화 쿼리를 작성했어.
    # 실제 job_mst 테이블의 컬럼 이름과 매핑될 JobMstDocument의 필드 이름을 잘 확인해서 쿼리를 구성해줘.
    # 예: id, company_cd, anno_id 등 모든 필요한 컬럼을 명시해주는 것이 좋아.
    statement => "SELECT id, company_cd, anno_id, class_cd_nm, emp_type_cd_nm, anno_subject, sub_job_cd_nm, sys_company_cd_nm, job_detail_link, end_date, personal_history, personal_history_end, insert_dts, updated_at FROM job_mst WHERE updated_at > :sql_last_value ORDER BY updated_at ASC"

    # 'updated_at' 컬럼 값을 추적해서 :sql_last_value를 업데이트해.
    use_column_value => true
    tracking_column => "updated_at"
    tracking_column_type => "timestamp"

    # 초기 풀 로드: 처음 실행 시 'true', 이후 증분 동기화 시 'false'
    clean_run => true

    # 마지막 실행 시간과 추적 컬럼 값을 저장할 파일 경로
    last_run_metadata_path => "/etc/logstash/data/.logstash_jdbc_last_run_job_mst.yml" # <- 이 경로가 쓰기 가능한지 확인

    # 필드 이름 변환: DB 컬럼명이 엘라스틱서치 필드명과 다를 경우 대문자->소문자, 언더스코어->카멜케이스 등으로 변환 (선택 사항)
    # statement_filepath => "/etc/logstash/conf.d/your_query.sql" # 쿼리가 길 경우 별도 파일로 관리할 수도 있음
  }
}

# 데이터를 엘라스틱서치로 보내는 설정
output {
  elasticsearch {
    hosts => ["http://localhost:9200"] # 네 엘라스틱서치 서버 주소와 포트
    user => "elastic"
    password => "changeme"
    index => "job_mst" # 엘라스틱서치에 생성할 인덱스 이름 (네 JobMstDocument와 동일하게)
    document_id => "%{id}" # MariaDB `id` 컬럼 값을 엘라스틱서치 문서의 ID로 사용
                           # 이렇게 해야 MariaDB의 데이터 변경 시 엘라스틱서치에서도 해당 문서가 업데이트돼.
  }
  stdout { codec => rubydebug } # 개발 중에는 Logstash가 어떤 데이터를 처리하는지 터미널에 출력해서 확인
}

실시간 로그 확인

sudo tail -f /var/log/logstash/logstash-plain.log

재부팅 시 카프카 자동 실행(systemd)

킨글 — Wed, 17 Sep 2025 10:49:26 +0900

주키퍼 systemd 서비스 파일 생성

sudo vi /etc/systemd/system/zookeeper.service

[Unit]
Description=Apache ZooKeeper
After=network.target

[Service]
Type=simple
User=ec2-user # 네 서버의 카프카 실행 사용자 이름으로 변경 (보통 ec2-user)
Group=ec2-user # 네 서버의 카프카 실행 사용자 그룹으로 변경
ExecStart=/home/ec2-user/kafka_2.13-3.2.3/bin/zookeeper-server-start.sh /home/ec2-user/kafka_2.13-3.2.3/config/zookeeper.properties
ExecStop=/home/ec2-user/kafka_2.13-3.2.3/bin/zookeeper-server-stop.sh /home/ec2-user/kafka_2.13-3.2.3/config/zookeeper.properties # stop 스크립트가 있다면 사용 (없으면 비워도 됨)
TimeoutStartSec=60 # 시작 대기 시간
TimeoutStopSec=60  # 종료 대기 시간
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

카프카 브로커 systemd 서비스 파일 생성

sudo vi /etc/systemd/system/kafka.service

[Unit]
Description=Apache Kafka
After=zookeeper.service # 주키퍼가 먼저 시작된 후에 카프카가 시작되도록 설정
After=network.target

[Service]
Type=simple
User=ec2-user # 네 서버의 카프카 실행 사용자 이름으로 변경
Group=ec2-user # 네 서버의 카프카 실행 사용자 그룹으로 변경
ExecStart=/home/ec2-user/kafka_2.13-3.2.3/bin/kafka-server-start.sh /home/ec2-user/kafka_2.13-3.2.3/config/server.properties
ExecStop=/home/ec2-user/kafka_2.13-3.2.3/bin/kafka-server-stop.sh /home/ec2-user/kafka_2.13-3.2.3/config/server.properties
TimeoutStartSec=600 # 카프카 시작은 더 오래 걸릴 수 있으니 넉넉하게 설정 (600초 = 10분)
TimeoutStopSec=60
Restart=on-failure
RestartSec=10

[Install]
WantedBy=multi-user.target

파일을 모두 저장하고 나면 systemd에게 새로운 서비스 파일을 알리고 활성화

sudo systemctl daemon-reload # systemd 설정 새로고침
sudo systemctl enable zookeeper # 재부팅 시 자동 시작 활성화
sudo systemctl enable kafka     # 재부팅 시 자동 시작 활성화

서비스 시작

sudo systemctl start zookeeper # 주키퍼 서비스 시작
sudo systemctl status zookeeper # 주키퍼 서비스 상태 확인 (Active: active (running) 이면 OK)

# 주키퍼가 잘 떴으면 이제 카프카 시작
sudo systemctl start kafka     # 카프카 서비스 시작
sudo systemctl status kafka     # 카프카 서비스 상태 확인 (Active: active (running) 이면 OK)

카프카 실행 명령어

킨글 — Wed, 17 Sep 2025 10:42:34 +0900

주키퍼를 먼저 실행 시켜주어야 한다.

nohup bin/zookeeper-server-start.sh config/zookeeper.properties > zookeeper.out 2>&1 &

카프카 브로커 실행

nohup bin/kafka-server-start.sh config/server.properties > server.out 2>&1 &

jps 입력하여 실행 확인

[홈서버] DNS 자동 매핑 처리

킨글 — Tue, 16 Sep 2025 16:33:08 +0900

홈서버의 경우 고정 아이피가 아닌 경우가 대부분이라 아이피가 매번 바뀔 수 있기 때문에 DNS와 IP를 매칭시켜주어야 한다.

duckdns.org에 들어가서 domain을 생성한 후 token을 생성하고 아래와 같이 sh 파일을 만들어 스케줄러 돌리면 된다.

파일 생성

vi duck.sh

파일 내용

#!/bin/bash
#
# Simple shell script to run DuckDNS update
# Requires curl to be installed
#

# Configuration variables
# Set your domain or comma separated list of domains and subdomains
# (for example: mytestdomain.duckdns.org,other.duckdns.org)
DOMAIN="domain.duckdns.org"
# Set your token as per your account for example from the duckdns.org home page
TOKEN="111111-296e-4c07-9cab-222222"

# Check this file is actually being executed directly
[[ "$BASH_SOURCE" == "$0" ]] || return

# Check for root if using system-wide configuration
if [[ $EUID != 0 ]]
then
    echo 'ERROR: Requires root privileges (sudo).'
    exit 1
fi

# Check if curl is installed
if ! command -v curl &> /dev/null
then
    echo "ERROR: 'curl' command not found. Please install curl."
    exit 1
fi

# Get IP addresses, filter to current, filter to IPv4 & IPv6
WAN_IPS="$(ip -o -f inet addr | awk '{print $4}' | cut -d/ -f1)"

if [[ -z "$WAN_IPS" ]]
then
    echo 'ERROR: No public IP address was found for WAN interface.'
    exit 2
fi

for CURRENT_IP in $WAN_IPS
do
    # Check IPv4 and IPv6
    if [[ "$CURRENT_IP" == *.* ]] # Is this IPv4?
    then
        echo -n "Updating with IPv4 address ($CURRENT_IP)... "
        URL="https://www.duckdns.org/update?domains=$DOMAIN&token=$TOKEN&ip=$CURRENT_IP"
        RES="$(curl -s -L "$URL")"
    elif [[ "$CURRENT_IP" == *:* ]] # Is this IPv6?
    then
        echo -n "Updating with IPv6 address ($CURRENT_IP)... "
        URL="https://www.duckdns.org/update?domains=$DOMAIN&token=$TOKEN&ipv6=$CURRENT_IP"
        RES="$(curl -s -L "$URL")"
    fi

    if [[ "$RES" == "OK" ]]
    then
        echo 'OK'
    elif [[ "$RES" == "KO" ]]
    then
        echo 'ERROR: Server returned KO'
    else
        echo "ERROR: Unknown server response ($RES)"
    fi
done

# Re-check server status for this IP to confirm changes
echo -n 'Checking server status... '
CHECK_URL="https://www.duckdns.org/update?domains=$DOMAIN&token=$TOKEN&check=true"
CHECK_RES="$(curl -s -L "$CHECK_URL")"
if [[ "$CHECK_RES" == *"$CURRENT_IP"* ]]
then
    echo 'OK'
else
    echo "ERROR: Could not verify that IP ($CURRENT_IP) has been updated."
fi

echo 'Done.'

crontab 설정 진입

sudo crontab -e

맨 아래에 아래 명령어 추가

0 * * * * /home/kingle/duckdns/duck.sh > /var/log/duckdns_hourly_update.log 2>&1

0 * * * *: "매 시간 0분(정각)에 실행"
첫 번째 0: 매 시 정각 (분)
두 번째 *: 매 시간 (시)
세 번째 *: 매일 (일)
네 번째 *: 매월 (월)
다섯 번째 *: 매 요일 (요일)

우분투(Ubuntu) 노트북 덮개를 닫아도 절전모드가 안되도록 하기

킨글 — Sun, 14 Sep 2025 11:18:57 +0900

개인 홈 서버를 구축하였는데 노트북 덮개를 덮었을 때에 절전모드로 전환하는 현상이 생겼다.

그래서 절전모드를 풀어주기로 했다.

설정 진입

$ sudo vi /etc/systemd/logind.conf

#HandleLidSwitch=suspend 이라고 되어 있는 부분들을 HandleLidSwitch=ignore으로 변경해준다.

HandleLidSwitch=ignore
HandleLidSwitchExternalPower=ignore
HandleLidSwitchDocked=ignore

HandleLidSwitch 에서 설정할 수 있는 값

설정값	설정결과
poweroff	시스템 잠그고 꺼짐
hibernate	최대 절전모드
suspend	절전모드
ignore	정상적으로 서비스됨
lock	덮개가 닫힐 때마다 시스템 자동 잠금

아래 명령으로 변경한 설정을 적용해주면 노트북을 닫아도 정상적으로 서비스가 되는 것을 확인할 수 있다.

$ sudo systemctl restart systemd-login.service

ubuntu 절전 모드 처리

킨글 — Sun, 14 Sep 2025 11:15:56 +0900

ubuntu 노트북을 서버로 구축할 때 절전모드가 되어 불편한 상황이 생긴다.

그럴 때 해결하기 위한 방법이다.

절전 모드 확인

$ systemctl status sleep.target suspend.target hibernate.target hybrid-sleep.target

절전 모드 처리

$ sudo systemctl mask sleep.target suspend.target hibernate.target hybrid-sleep.target

이렇게 하면 절전모드가 된다.

지연 초기화 문제(Initializing Spring DispatcherServlet)

킨글 — Mon, 30 Jun 2025 16:17:08 +0900

아래와 같이 운영 환경에서 처음 요청이 와야 Initializing Spring DispatcherServlet 'dispatcherServlet'이 실행되는 현상이 있었다.

확인해보니 Spring Boot의 기본 설정에서는 DispatcherServlet이 지연 초기화(lazy initialization)되도록 설정되어 있다고 한다.

2025-06-30 05:24:27 2025-06-30T05:24:27.537+09:00  INFO 1 --- [] [           main] o.s.b.w.embedded.tomcat.TomcatWebServer  : Tomcat started on port 8080 (http) with context path ''
2025-06-30 05:24:27 2025-06-30T05:24:27.937+09:00  INFO 1 --- [] [           main]      : Started NklcbdtyApplication in 194.784 seconds (process running for 211.547)
2025-06-30 16:01:35 2025-06-30T16:01:35.742+09:00  INFO 1 --- [] [nio-8080-exec-6] o.a.c.c.C.[Tomcat].[localhost].[/]       : Initializing Spring DispatcherServlet 'dispatcherServlet'
2025-06-30 16:01:35 2025-06-30T16:01:35.841+09:00  INFO 1 --- [] [nio-8080-exec-6] o.s.web.servlet.DispatcherServlet        : Initializing Servlet 'dispatcherServlet'

이로 인해 첫 요청을 보내는 유저의 경우 사이트가 작동하지 않는 것으로 착각하여 이탈할 수가 있다.

그렇기 때문에 application.properties에 아래 설정을 통해 처리해준다.

spring.mvc.servlet.load-on-startup=1

Spring Data JPA 메서드 명명 규칙

킨글 — Tue, 3 Jun 2025 12:04:14 +0900

Spring Data JPA의 레포지토리 메서드 명명 규칙과 프로젝션을 함께 고려할 때, email만 반환하는 메서드의 이름으로 findEmailByUserId는 매우 일반적이고 권장되는 명명 방식입니다.

Spring Data JPA의 메서드 이름은 일반적으로 다음과 같은 구조를 따릅니다.

[Prefix][Distinct]By[Criteria][Keywords][Order]

[Prefix]: find, get, read, query, count, stream 등 조회 작업을 나타내는 접두사입니다.
[Distinct]: 결과에서 중복을 제거할 때 사용합니다.
By: 검색 조건(WHERE 절)의 시작을 나타내는 구분자입니다.
[Criteria]: By 뒤에 오는 부분으로, WHERE 절에 사용될 엔티티 필드 이름과 조건을 명시합니다 (UserId, UsernameAndAge, LastNameLike 등). 이것이 메서드의 파라미터와 연결됩니다.
[Keywords]: And, Or, LessThan, GreaterThan 등 조건을 결합하거나 상세화하는 키워드입니다.
[Order]: OrderBy 뒤에 오는 부분으로, 정렬 순서를 지정합니다.
여기서 중요한 부분은 **[Prefix] 바로 뒤에 오는 부분(혹은 Distinct 뒤)**이 레포지토리 메서드가 무엇을 반환하는지 나타낼 수 있다는 것입니다. 전체 엔티티를 반환할 때는 이 부분을 생략하거나 엔티티 이름을 포함할 수 있지만 (예: findUserVoByUserId), 프로젝션을 사용할 때는 조회하려는 필드나 프로젝션의 이름을 명시적으로 넣어주는 것이 일반적입니다.

따라서 findEmailByUserId라는 이름은 다음과 같이 해석됩니다.

find: 조회한다.
Email: (결과로) email 필드(또는 email 프로젝션)를 가져온다.
By: 조건은...
UserId: userId 필드를 기준으로 한다.
즉, 이 메서드 이름은 "userId를 기준으로 email 정보를 찾아온다"는 의미를 명확하게 전달합니다. 요청 조건(UserId)과 반환 데이터의 핵심(Email)을 모두 포함하고 있으며, 특히 반환되는 데이터가 전체 엔티티가 아닌 특정 필드(또는 프로젝션)임을 이름으로 표현하는 좋은 방법입니다.

다른 일반적인 명명 예시로는 findNameAndEmailByUserId, findUserEmailProjectionByUserId 등이 있을 수 있지만, findEmailByUserId는 간결하면서도 의미 전달이 확실하여 널리 사용됩니다.