개발자 배트맨의 일상

[PostgreSQL] DB 복제하기

G_Batman — Sun, 4 Jan 2026 17:07:30 +0900

Production 서버와 Staging 서버를 동시에 운영하다 보면
두 DB의 sync를 맞춰야 하는 경우가 발생한다. 현재 운영 중인 서버에서 비슷한 경우가 반복되어
스스로 보려고 정리하는 포스팅

EC2 to EC2와 EC2 to Local 모두 가능하니 EC2 to Local을 기준으로 정리

환경 요약

Production Server

Ubuntu
PostgreSQL 16 (Docker 컨테이너)
컨테이너 이름: pg (예시)
DB 이름: appdb
DB 유저: appuser

Local

Windows + Docker Desktop (Linux engine)
PostgreSQL 16 (Docker 컨테이너)
컨테이너 이름: pg_local (예시)

1️⃣ EC2에서 plain SQL로 DB 덤프 뜨기

단순 SQL 텍스트로 덤프 (.sql)

파일 크기로 정상 여부 판단

EC2

docker exec -t pg pg_dump -U appuser -d appdb > appdb.sql

덤프 파일 크기 확인

ls -lh appdb.sql

대략 100 KB ~ 수 MB 이상 → 정상

2️⃣ EC2 → 로컬로 SQL 파일 가져오기

로컬 PowerShell

scp -i "C:\path\to\key.pem" ubuntu@<EC2_PUBLIC_IP>:/home/ubuntu/appdb.sql "Path to local Project"

3️⃣ 로컬 PostgreSQL 컨테이너 실행

로컬에 PostgreSQL이 없다면 Docker로 실행하는 게 가장 깔끔하다.

docker run -d --name {pg_local} ` -e POSTGRES_DB={appdb} ` -e POSTGRES_USER={appuser} ` -e POSTGRES_PASSWORD={localpass} ` -p 5432:5432 ` -v pg_local_data:/var/lib/postgresql/data ` postgres:16

확인

docker ps

4️⃣ SQL 파일을 컨테이너로 복사

docker cp "Path\Local\project\appdb.sql" pg_local:/tmp/appdb.sql

확인

docker exec -it pg_local ls -lh /tmp/appdb.sql

5️⃣ psql로 DB 복원

pg_restore ❌
plain SQL은 psql로 복원해야 한다

docker exec -it pg_local psql -U appuser -d appdb -f /tmp/appdb.sql

6️⃣ 복원 성공 여부 확인

테이블 목록 확인

docker exec -it pg_local psql -U appuser -d appdb -c "\dt"

Django 프로젝트라면

docker exec -it pg_local psql -U appuser -d appdb -c "select count(*) from django_migrations;"

정상적으로 row 수가 나오면 복제 완료

❗ 자주 겪은 문제

pg_restore: end of file

원인: custom format dump 손상 or 잘린 파일
해결: plain SQL 방식으로 다시 덤프

PowerShell에서 \ 줄 바꿈 에러

PowerShell은 \ 지원 안 함
한 줄 명령 또는 백틱(`) 사용

[Django] 배포 후 Admin 페이지 CSS 깨짐 현상

G_Batman — Thu, 24 Jul 2025 19:00:04 +0900

안녕하세요. 배트맨입니다.

오늘 내용은 트러블 슈팅 과정입니다.

Django 프로젝트를 Nginx와 Gunicorn으로 배포한 후, 다른 페이지는 정상적으로 보이지만 Admin 페이지의 UI(CSS)만 깨져 보이는 현상에 대한 원인 분석 및 해결 과정.

현상

웹사이트의 일반 페이지들은 CSS가 정상적으로 적용되어 보임.
Django 관리자 페이지(/admin/)에 접속하면 CSS가 전혀 적용되지 않은 순수 HTML 페이지만 나타남.
브라우저 개발자 도구(F12)의 '네트워크' 탭을 확인하면, admin 관련 CSS 파일들이 404 (Not Found) 오류를 반환함.

원인 분석

→ collectstatic 명령어는 프로젝트의 모든 정적 파일(앱 내부의 파일 + Django 자체의 admin용 파일)을 하나의 디렉토리(예: /home/ubuntu/project/staticfiles/)로 모은다.

→ Nginx는 /static/ URL로 들어오는 요청을 이 디렉토리로 연결해줘야 하는데, nginx 설정 파일에서 이 부분이 잘못되면 파일을 찾지 못한다.

→ Nginx가 Django Admin의 정적 파일을 찾지 못하기 때문이다.

진단 과정

collectstatic 실행 여부 확인

가장 먼저, admin의 정적 파일들이 staticfiles 디렉토리에 제대로 복사되었는지 확인한다.

ls -l [STATIC_ROOT 경로]/admin/css/
ls -l /home/ubuntu/[project]/staticfiles/admin/css/

결과: 첫 번째 명령어에서 base.css, dark_mode.css 등 다수의 CSS 파일 목록이 정상적으로 출력됨.

→ collectstatic 명령어는 성공적으로 실행되었고, 파일 자체는 올바른 위치에 존재한다.

Nginx 설정 파일 확인

현재 적용된 Nginx 설정 내용에서 static 파일 처리 로직을 점검한다.

cat /etc/nginx/sites-available/[project]

⚠️ 확인된 설정 (문제의 원인):

location /static/ {
   root /home/ubuntu/[project]/staticfiles/;
}

❌ 문제점:

Nginx의 root 지시어는 요청된 URI를 root 경로 뒤에 그대로 이어 붙인다.

(예시)

요청 URL:
/static/admin/css/base.css
Nginx가 찾는 파일 경로:
/home/ubuntu/[project]/staticfiles/ + /static/admin/css/base.css

결과:

/home/ubuntu/ [project] /staticfiles/static/admin/css/base.css 라는 잘못된 경로를 찾게 되므로 404 오류가 발생한다.

해결:

Nginx의 location 블록에서 root 대신 alias를 사용하여 정확한 경로를 매핑해준다.

sudo nano /etc/nginx/sites-available/[project]

# 수정 전:
location /static/ {
    root /home/ubuntu/[project]/staticfiles/;
}

# 수정 후:
location /static/ {
    alias /home/ubuntu/[project]/staticfiles/;
}

결과

브라우저에서 강력 새로고침을 실행한 후,

Admin 페이지의 CSS가 정상적으로 로드되어 UI가 잘 나온다!

[무의도] 우당탕탕 백패킹 일지 | 무렝게티, 주차, 화장실, 편의점, 맛집 정보

G_Batman — Fri, 16 May 2025 08:11:39 +0900

안녕하세요 배트맨 입니다.

살다 보면 계획대로 안 되는 일이 참 많죠.. 백패킹을 다니다 보면 그런 상황을 더 자주 마주하게 되는데 그런 경험이 기억에 더 오래 남는 것 같아요. 이번 포스팅도 우당탕탕 재미있을 테니 잘 봐주세요!

굴업도에 가보자 !!

한국 백패커라면 누구나 꿈꾼다는 한국 백패킹 3대 명소가 있죠!

제주 비양도, 통영 소매물도, 인천 굴업도
저는 비양도, 소매물도는 다녀왔는데 굴업도는 아직 못 가봤어요. 인기가 많아서 배편을 예약하기도 어려웠어요. 근데 2024년 12월부터 인천-굴업도 직항 배편이 생겨서 굴업도에 가는 게 조금은 더 쉬워졌어요. 그렇게 운 좋게 5월 10일-5월 12일 배편을 예매했는데, 당일에는 비 예보가 있었어요ㅋ.

What's in my bag

하루에도 몇 번씩 비 예보, 결항 여부, 바람 세기, 심지어 '구름 움직임'까지 체크한 저희는 '이 정도면 뜨겠다'는 생각으로 준비를 했습니다.

출바알!

아침 6시에 눈을 뜨고, 제일 먼저 날씨와 결항 여부 체크!

오케이 문제없어. 계획대로 추진해!

7시에 집을 나섰습니다.

출발 2분 뒤.... 결항.....
바로 갓길에 차 세우고, 0.3초 정적 후 한숨,,,

바로 대책회의 들어감. 궁평항을 가? 집에 가? 다른 데는 없나?

막 검색하다가 스쳐가는 섬 하나가 있는데, 바로

무의도..
“무의도는 한국의 세렝게티다.”

당장 가자. 무의도로.

무의도 도착

오전 9시 무의도 도착.
백패킹을 가는 분들은 주차에 두 가지 선택지가 있어요.
1. 등산로 초입 바로 앞에 있는 '초록 카페' 앞 도로에 주차 자리가 있고,

2. 자리가 없다면 '무의광명항 공영주차장' 여기에 주차를 해야 합니다.

초록 카페 앞 주차장에는 자리가 거의 없었고, 겨우 주차 자리 하나가 있어서 주차를 했다.

주차를 하자마자 피로가 몰려왔습니다. 그래서 “딱 30분만” 눈 붙이자고 했는데, 당연히 알람을 맞춘 사람은 없었고, 눈 떠보니 "아쉬워 벌써 12시~" 였습니다.

시간? 별로 중요하지 않고! 난 배 고프니까 눈앞에 보이는 칼국수집 가자!

선창회식당을 가려고 했으나, 만석 이슈로 맞은편 광명 어촌계 식당으로~

홍합에.. 가리비에.. 바지락에.. 국물이 되게 폭력적인 맛이었고, 덕분에 부활~

무의도 캠핑장 가는 길

PM13:00 드디어 출발하는 으네와 나

자 드가자아~~

등산로 입구는 초록 카페 뒤편에 있습니다잇!

꿀팁은 갈림길에서 거의 왼쪽 길로 가면 되는데, 무턱대고 왼쪽으로만 가면 이상한 해변에 다다른다...(이건 나도 알고 싶지 않았다)

첫번째 갈림길이었던가

난 그딴 거 모르겠고~

냅다 왼쪽으로 가잇!
( 이 표지판 기준으로 왼쪽으로 가는 게 맞습니다. 오해 노노)

그 이후로는 사진이 없지만, 중요한 스팟을 기준으로 보면
초입 - 산소 - 과수원 - 위 사진의 갈림길(왼) - 내리막과 오르막 갈래길(오) - 밧줄 타는 절벽

여기까지 가면 첫 번째 해변이 나옴

여기서 해안 or 산길 중 선택해야 하는데, 밀물 때는 해안길이 닫힌다.

(개인적으로 산길이 더 편하고 빠르다)

해안길은 누가 봐도 해안길이고, 산길은 찾기가 조금 어려울 수 있는데 입구 나무에 하얀 통을 묶어서 표시해 놓았다.

해안길이든 산길이든 다 지나면 드디어

백패킹 성지 도착!

손 끝에는 바다가 보인다,,

등산로 중간에 뷰가 좋은 포인트에서 찍은 사진이다.

이제 텐트 피칭을 해볼까!

시원한 바람,, 앗 이건,,

캠프사이트에 도착하자마자 바람이 장난이 아니었다.

'앗..이건..! 제주도다..!'
바람이 잦아들 때까지 무작정 기다리는 건 내 스타일이 아니고, 그냥 바람을 뚫고 텐트를 피칭한다.

강한 바람에 정신이 없었지만 우당탕탕 피치 완료!

그리고 제주에서 돌담을 수도 없이 본 짬바로 직접 돌담을 쌓아버린다.

돌담 장인,, 섬남,,

피칭 완료! 아래 사진을 보면 아직 구름이 잔뜩 껴있다.

자 이제 밥 먹자

텐트 치고 누웠는데 기절할 뻔했다,, 간신히 몸을 일으켜서 나왔고,

이른 저녁을 먹기로 했다.

챙겨간 음식은 지코바, 라면, 순대, 햇반, 연태고량주

근데

어라? 오늘의 메인 디쉬 지코바가 술 세 잔에 박살이 나부렀네?
이건 계획에 없던 건데..?

(대책 회의 진행)
편의점은 왔던 산길을 되돌아가야 하고, 왕복 4km 거리..!
정신을 차려보니 숨도 안 쉬고 2km 산길을 달리고 있었다..!

분명히 처음 올 때는 50분 걸렸는데, 25분 만에 도착했다ㅋㅋㅋㅋㅋㅋ

두 번은 못 온다며 삼겹살, 햇반, 맥주, 과자 등 필요한 걸 잔뜩 사들고 다시 2km를 복귀한다.

양손 가득. 다시 포토 스팟.

(~~삼겹살 생각에 눈이 돌아서~~배낭이 없어서 몸이 가벼웠던 거 같다.)

평화 그리고 낭만

바람이 잦아들면서 드디어 평화가 찾아왔어요. 저 멀리 해가 뉘엿뉘엿 넘어가고 있네요.

알록달록한 텐풍, 밤하늘, 멋진 세렝게티 풍경...

10시쯤까지 밖에서 잔잔하게 즐기다가 들어갔습니다.

(밤 사이에 고양이인지 쓰레기봉투를 다 헤집어놔서 식겁했어요.. 바로 텐트 안으로 들고 들어갔어요ㅎㅎ)

집 가자;

(feat. 해안길 포토 스팟)

다음날 아침엔 커피 끓여 먹고, 장비를 하나하나 정리하고, 천천히 출발했습니다.

돌아가는 길은 간조 타이밍이 잘 맞아서 산길 대신 해안 절벽길로 갈 수 있었어요.

유명한 포토 스팟에서 사진도 찍고!!

아 근데 저기 올라가는 게 생각보다 위험하더라고요,, 무거운 배낭을 메고 바위를 오르내리다 보면 안전사고가 있을 수 있으니 조심하셔야 해요!!!

또 해안길은 돌길로 되어있고 불규칙해서 생각보다 난이도가 있었지만, 한 번 정도는 감수하고 가볼 만했습니다.

마무리

계획이 다 틀어지고, 무의도는 급하게 결정된 목적지였지만, 너무 멋졌고 잊을 수 없는 곳이었습니다.
굴업도는 5월 말에 재도전! 그땐 배 뜨겠지~

“중요한 건 계획이 아니라 대응이다.”

– 배트맨

[Spring] DTO란? Class 방식과 Record 방식

G_Batman — Thu, 15 May 2025 21:13:53 +0900

최근 프로젝트에서 Spring 백엔드를 담당하며 Record로 DTO를 구현해 봤습니다.

Record를 처음 써봤고, 공식 문서를 보면 '고정된 값들을 담는 얕은 불변성의 투명한 매개체'라고 설명이 되어있습니다.

Java17 버전 공식문서

[Java] Shallow Immutable? Deep Immutable?

얕은 불변성과 깊은 불변성??Java Record Object의 공식 문서를 읽다가 등장한 Shallow Immutable... Deep Immutable과 어떤 차이가 있을까요?shallowly immutable 이란?공식 docs에서는 관련 내용을 찾기 어려웠고, 스

g-batman.tistory.com

Record (Java SE 17 & JDK 17)

Direct Known Subclasses: UnixDomainPrincipal public abstract class Record extends Object This is the common base class of all Java language record classes. More information about records, including descriptions of the implicitly declared methods synthesize

docs.oracle.com

제가 구현했던 DTO는 모임을 생성할 때 필요한 정보들을 담는 CreateMeetRequest dto입니다.

Class 방식으로 구현

public class CreateMeetRequest {
    private String meetIntro;
    private String meetType;
    private String address;
    private String addressDescription;
    private LocalDateTime meetAt;
    private int totalCost;
    private int memberLimit;

    public CreateMeetRequest(...) { ... }
    
    public String getMeetIntro() { return meetIntro; }
    ...
}

Record 방식으로 구현

public record CreateMeetRequest(
    String meetIntro,
    String meetType,
    String address,
    String addressDescription,
    LocalDateTime meetAt,
    int totalCost,
    int memberLimit
) {}

Record로 작성하면 내부적으로 멤버 변수가 private final로 선언이 됩니다. 그리고 getter, toString, equals 등의 메소드가 자동으로 생성이 됩니다. 덕분에 코드가 간결해지고, 불변성이 보장이 되는 장점이 있었습니다.

또 클래스를 사용했을 때는 @AllArgConstructor, @Getter 등의 어노테이션을 DTO마다 모두 선언해 주었습니다. 이러한 보일러플레이트 코드를 줄임으로써 핵심적인 구성요소만 남으니 편하고 가독성도 좋았습니다.

좋잖아?

로직 추가나 디폴트 생성자가 없다는 등의 단점이 있지만, 그럼에도 앞으로 자주 사용할 듯합니다.

단순 DTO나 응답 전용 객체 → record ✅

복잡한 유효성 검사나 상태를 가지는 도메인 객체 → class 사용이 안전 ✅

실제 코드

(Description, Validation 등을 추가)

@Schema(description = "모임 생성 요청 DTO")
public record CreateMeetRequest(
    @Schema(description = "모임 설명", example = "제주 올레길 탐방")
    @NotBlank
    @Size(max = 30)
    String meetIntro,

    @Schema(description = "모임 유형 ('이동', '운동', '빨래' 등)", example = "여행")
    @NotBlank
    @Size(max = 10)
    String meetType,

    @Schema(description = "주소", example = "제주특별자치도 제주시 월성로 4길 19")
    @NotBlank
    @Size(max = 40)
    String address,

    @Schema(description = "주소 설명", example = "노블레스 관광 호텔 로비")
    @NotBlank
    @Size(max = 20)
    String addressDescription,

    @Schema(description = "출발 시간", example = "2025-05-20T18:00:00")
    @NotNull
    @JsonFormat(shape = JsonFormat.Shape.STRING, pattern = "yyyy-MM-dd'T'HH:mm:ss")
    @Future(message = "모임 날짜는 현재보다 이후여야 합니다.")
    LocalDateTime meetAt,

    @Schema(description = "총 비용 (0~10,000,000)", example = "10000")
    @NotNull
    @Min(0)
    @Max(10_000_000)
    int totalCost,

    @Schema(description = "최대 인원 수 (1~30)", example = "5")
    @NotNull
    @Min(2)
    @Max(30)
    int memberLimit
) {}

[Java] Shallow Immutable? Deep Immutable?

G_Batman — Thu, 15 May 2025 11:19:34 +0900

얕은 불변성과 깊은 불변성??

Java Record Object의 공식 문서를 읽다가 등장한 Shallow Immutable... Deep Immutable과 어떤 차이가 있을까요?

shallowly immutable 이란?

공식 docs에서는 관련 내용을 찾기 어려웠고, 스택오버플로우에서 내용을 찾았습니다.

shallow immutability는 record 객체 자체의 필드 값은 변경할 수 없지만, 그 필드가 참조하고 있는 객체의 내부 상태는 변경될 수 있다는 의미라고 합니다.

무슨말이지??

다섯 번 정도 읽어보니 '필드가 Int라면 값을 변경할 수 없지만 List를 참조하고 있으면 그 내부의 값은 변경할 수 있다' 정도의 예시가 생각이 났습니다. 간단한 예시 코드를 작성해 봤습니다.

import java.util.List;

public record Person(String name, List<String> hobbies) {}

public class Main {
    public static void main(String[] args) {
        List<String> hobbyList = List.of("축구", "헬스");
        Person p = new Person("Batman", new ArrayList<>(hobbyList));

        System.out.println(p); // Person[name=Batman, hobbies=[축구, 헬스]]

        // hobbies 리스트 내부 데이터 추가
        p.hobbies().add("등산");

        System.out.println(p); // Person[name=Batman, hobbies=[축구, 헬스, 등산]]
    }
}

여기서 p.hobbies()는 final이기 때문에 다른 List로 대체할 수는 없습니다. 하지만 List 객체 자체는 mutable 하기 때문에, 그 내용은 수정할 수 있습니다.

반대로 Deep Immutable은 필드도, 필드가 가리키는 객체도 모두 바꿀 수 없는 속성입니다.

[DB] 우리 서비스에 가장 적합한 RDBMS는? MySQL편

G_Batman — Thu, 1 May 2025 16:57:35 +0900

테스트 목적

MODiE 서비스에서 가장 적합한 RDBMS를 선정하기 위해, 동일한 조건에서 MySQL, PostgreSQL을 대상으로 성능을 비교해보려고 합니다. 단순 수치 비교가 아닌, 실제 서비스 환경과 유사한 시나리오로 부하를 유발하며, 쿼리 튜닝 및 병목 요인 제거까지 포함한 실험입니다. 오늘은 MySQL편~

테스트 환경

항목	값
EC2 인스턴스	m5.large (2 vCPU, 8GiB RAM)
OS	Ubuntu 24.04.2 LTS
디스크	Amazon EBS (gp3, NVMe SSD)
네트워크	동일 VPC 내 private subnet
DB 서버 수	1대
구조	Controller, Worker, DB 용 EC2 별도 구성
모니터링 툴	JMeter, Netdata

테스트 시나리오

Test data

데이터 스키마 요약

서비스 운영 6개월~1년 차 수준의 데이터 규모를 가정

csv 파일을 사용해서 빠른 삽

테이블	설명	레코드 수
user	사용자 정보	500,000
meet	모임 정보	500,000
user_meet	유저-모임 참여 관계	500,000
chat	채팅 기록	500,000

사용한 최종 쿼리 - 아래 쿼리에서 Read 90% Create 10% 비율로 사용 (접은글)

-- 1. 모임 목록 조회
SELECT m.*
FROM meet m
WHERE m.owner_id = 'user_0000001'
  AND m.meet_type = '운동'
  AND m.completed_at IS NULL
  AND m.deleted_at IS NULL

UNION

SELECT m.*
FROM meet m
JOIN user_meet um ON um.meet_id = m.meet_id
WHERE um.user_id = 'user_000003'
  AND um.deleted_at IS NULL
  AND m.meet_type = '운동'
  AND m.completed_at IS NULL
  AND m.deleted_at IS NULL
ORDER BY meet_at ASC;

-- 2. 모임 상세 조회

SELECT 
  m.meet_id, 
  m.meet_intro, 
  m.meet_type, 
  m.address, 
  m.address_description, 
  m.meet_at, 
  m.total_cost, 
  m.member_limit, 
  m.created_at, 
  m.updated_at, 
  m.deleted_at, 
  m.completed_at,
  u.user_name AS owner_name
FROM meet m
JOIN user u ON m.owner_id = u.user_id
WHERE m.meet_id = ?;

-- 3. 모임 참여자 목록 조회
SELECT 
  u.user_id, 
  u.user_name
FROM user_meet um
JOIN user u ON um.user_id = u.user_id
WHERE um.meet_id = ?
  AND um.deleted_at IS NULL;

-- 4. 채팅 내용 조회
SELECT
  c.message_id,
  c.user_id,
  u.user_name,
  c.message_content,
  c.created_at,
  c.meet_id
FROM chat c
JOIN user u ON c.user_id = u.user_id
WHERE c.meet_id = ?
ORDER BY c.created_at DESC
LIMIT 25;

-- 5. 모임 생성
INSERT INTO meet (
  address,
  address_description,
  completed_at,
  created_at,
  deleted_at,
  meet_at,
  meet_intro,
  meet_type,
  member_limit,
  total_cost,
  updated_at,
  owner_id
)
VALUES (
  CONCAT('서울시_', ${__counter(FALSE)}),
  '건물 1층 로비',
  NULL,
  NOW(),
  NULL,
  NOW() + INTERVAL 1 DAY,
  CONCAT('소개글_', ${__counter(FALSE)}),
  '이동',
  FLOOR(5 + RAND() * 15),
  FLOOR(1000 + RAND() * 9000),
  NULL,
  'user_0000001'
);

VU Max 추정

2 vCPU → 2 * 1000 VU 수준에서 포화 예상

테스트 결과

Virtual User 수	Ramp-up 시간	CPU 사용량	QPS	특이사항
100	60초	4%	16
200	60초	8%	34
500	60초	12%	91
1000	60초	18%	182
3000	60초	53%	546	peek 94% (⚠️ 서버 불안정 판단)

전체 메모리 사용량 1 GiB 미만 → 병목 없음 확인

진행 중 트러블 슈팅

Trouble 1: 쿼리 성능 병목 (Index 미사용 + 불필요한 Full Scan)

상황

테스트 초반 10 VU / QPS 10 수준임에도 CPU 사용률이 99%에 육박

분석

의심 쿼리: 모임 목록 조회
Netdata로 확인한 결과, iowait 없이 user 영역이 급등 → 병목 지점 확인
EXPLAIN 명령어로 확인 시 Full Scan 탐색이었고, 50만 행을 순회한 것을 확인

시도한 해결책

쿼리 재작성 전: OR 조건이 포함된 경우, 인덱스가 완전히 무시됨
UNION 사용으로 분리 → 인덱스 타기 시작

✅ 최종 해결

아래 복합 인덱스 생성으로 완전히 해결

CREATE INDEX idx_meet_owner_type_completion ON meet(owner_id, meet_type, completed_at, deleted_at);

이후 EXPLAIN 결과에서 type = range, key = idx_meet_owner_type_completion 확인
CPU 사용률 99% → 1%로 감소

Trouble 2: MySQL 연결 수 초과 (max_connections)

상황

200 VU 이상부터 쿼리 Error 급증
500 VU에서 75% 이상 요청 실패

분석

JMeter 로그 분석

java.sql.SQLException: Too many connections

MySQL SHOW VARIABLES로 기본 max_connections 값이 151임을 확인
```
SHOW VARIABLES LIKE 'max_connections';
```

✅ 해결

1. 설정 변경 (영구 적용)

sudo vi /etc/mysql/mysql.conf.d/mysqld.cnf

[mysqld] max_connections = 5000 # 내용 추가

2. 서비스 재시작

sudo systemctl restart mysql

3. 적용 확인

SHOW VARIABLES LIKE 'max_connections';

4. VU 수변경 전 에러율변경 후 에러율

VU	기존 에러율	수정 이후 에러율
200	25%	0%
500	75%	0%
1000	미측정 (85% 예상)	0%

느낀 점

“쿼리 한 줄이 CPU를 잡아먹는다.”
인덱스가 빠진 쿼리 하나로 CPU가 99%를 점유하며 전체 서비스가 느려졌습니다.
EXPLAIN과 인덱스 튜닝은 선택이 아닌 필수임을 몸소 느꼈습니다.
“DB 설정은 ‘기본값’이면 안 된다.”
max_connections 기본값 151은 테스트 중 200VU부터 대규모 에러를 유발했습니다.
초기 설정값이 얼마나 보수적인지, 그리고 서비스에 맞는 튜닝이 얼마나 중요한지를 알게 되었습니다.
“부하 테스트는 단순 QPS 측정이 아니다.”
JMeter를 단순히 돌리는 것이 아니라, 요청 흐름을 잘 설계하고 트래픽 패턴과 쿼리 병목을 찾아내는 과정 그 자체가 실무에 가까운 훈련이었습니다.

다음은 PostgreSQL 이다잇!!

[OS] 교착상태와 데드락, 뮤텍스와 세마포어

G_Batman — Thu, 24 Apr 2025 01:24:01 +0900

임계영역(Critical Section)

임계영역(Critical Section)이란 여러 프로세스 또는 스레드가 동시에 자원에 접근할 경우 문제가 발생할 수 있는 코드 영역을 말합니다.

임계영역에서는 아래 3가지 조건을 만족해야 교착상태를 피할 수 있습니다

상호 배제(Mutual Exclusion)
하나의 프로세스가 임계영역에 있다면, 다른 프로세스는 들어갈 수 없다.
진행(Progress)
임계영역에 아무도 없는 상태라면, 진입을 요청하는 프로세스 중 어느 것이 들어갈지를 적절히 결정해주어야 한다.
한정 대기(Bounded Waiting)
한 프로세스가 계속해서 임계영역에 들어가지 못하는 일이 없도록 보장해야 합니다.

뮤텍스(Mutex)

뮤텍스(Mutual Exclusion Object)는 임계영역에 대한 접근을 제어하는 락(Lock)입니다.

하나의 스레드만 락을 획득할 수 있으며, 락을 획득한 스레드만 해제할 수 있습니다.
락을 통해 동시성 제어를 하며, 동시에 하나의 스레드만 접근 가능하도록 만듭니다.

세마포어(Semaphore)

세마포어는 뮤텍스보다 유연한 동기화 도구입니다. 자원의 동시 접근 가능 개수를 제어할 수 있습니다.

counting semaphore: 0 이상의 값을 가질 수 있음 → 동시에 여러 스레드 접근 가능
binary semaphore: 0 또는 1만 가짐 → 뮤텍스처럼 동작하지만 역시나 제어권은 스레드에 있다.

특징

세마포어는 다른 스레드가 signal로 값을 증가시킬 수 있음
wait() → 자원 접근 대기
signal() → 자원 해제 및 다른 프로세스에 접근 허용

교착상태(Deadlock)

교착상태란 여러 프로세스가 서로가 가진 자원을 기다리며 무한 대기에 빠지는 상태입니다.

교착 상태 발생 조건 (점순이 비상ㅋ)

상호 배제(Mutual Exclusion)
자원은 한 번에 하나의 프로세스만 사용할 수 있어야 함
점유와 대기(Hold and Wait)
자원을 가진 상태에서 다른 자원을 기다리는 상태
비선점(No Preemption)
자원을 강제로 빼앗을 수 없음
원형 대기(Circular Wait)
프로세스 간 자원 요청이 원형 구조를 이룸

교착 상태 해결 방법

예방(Prevention)
위 조건 중 하나를 사전에 제거하여 발생 자체를 막음
회피(Avoidance)
대표 알고리즘: 은행가 알고리즘(Banker's Algorithm)
시스템 상태를 계속 평가하여 안전한 경우에만 자원 할당
발생 후 회복(Recovery)
교착상태가 감지되면
→ 프로세스를 종료하거나 자원을 강제로 회수

[Jeju] 카카오테크 부트캠프 Hackathon

G_Batman — Sun, 9 Mar 2025 18:51:14 +0900

제주도에 와서 인생 첫 해커톤을 경험했습니다.

3박 4일간 진행했고, 총 7팀으로 진행되었습니다.

최종 2등으로 대회를 마쳤고, 이제 그 회고를 해보려고 합니다.

해커톤 개요

대회 이름: 카카오테크 부트캠프 해커톤

대회 기간: 2025.03.04 - 2025.03.07 (3박 4일)

대회 장소: 구름 스퀘어 in 제주

대회 규모: 42명 참가(7개 팀 각 6명)

대회 주제: 사회 문제(환경, 교육, 건강, 교통 등) 해결을 위한 맞춤형 데이터 활용 서비스

목표와 기대

처음 참가하는 해커톤이었기에 시작하기에 앞서 막연한 두려움과 목표에 대한 기대가 공존했다.

개인적인 목표로는 세 가지 정도를 꼽을 수 있는데, 깔끔하고 재밌는 발표와 기술적인 성장 그리고 팀원간 큰 충돌 없는 흐름 이렇게였다.

팀의 목표는 당연히 대회 우승..

그리고 어떻게든 배포까지 완성하는 거?

그래서 그냥 생산성만 보고 모든 걸 결정을 했다.

팀 빌딩이 끝나고 첫 회의에서, 주제에 대한 MVP를 정하고 불필요한 건 하나씩 다 떼버렸는데...

사람 1: "MVP인데 로그인 필요해요?"

전체: "뗄까요?"

사람 2: "로그인 떼면 저희 서비스에 DB가 필요해요?"

전체: "음.. 그럼 뗄까요?"

사람 3: "DB 뗄 거면 백엔드 서버 굳이 필요할까요?"

전체: "음.. 떼시죠?"

그렇게 백엔드 서버까지 떼버리고 서버 리스 구조가 되어버렸다..ㅎ

"목표와 기대" 목차에 대한 마무리는 아무래도 초기 목표에 대한 결과가 되어야겠지?

재밌는 발표 - 나는 발표하는 걸 참 좋아하는데, 그런 분이 한 분 더 계셔서 양보를 했다. 이게 반나절 동안은 속상했는데 이런 뭔가를 포기하는 경험마저 성장이라고 생각하고 난 시점부터는 괜찮았다. 그러고 나니 발표 연습에 피드백을 드리는 게 더 생산적이라고 판단했고 바로 실천했다.

그리고 저번 팀 회고 대회에서 1등을 하고 발표가 아주 인상적이었다는 피드백을 많이 받고 기분이 좋았었다. 근데 그런 칭찬들을 받으면서 조금 거만해졌을까 마음속으로 '내 발표 스타일이 짱이야'라는 생각을 하다가 이번 발표가 다 끝나고 느낀 점은 사람마다 발표 스타일은 다 다르고 그걸 인정할 줄 알아야겠다고 생각했다.

기술적인 성장 - 이 부분에 대해서는 조금 아쉬웠다. 이번에 써드 파티 API 세 가지를 써서 그것들을 합친 서비스를 개발했는데 기술적인 난이도가 아주 낮았었다. 그래서 추후에 서비스를 고도화한다면 백엔드 서버를 개발하면서 성장하고 싶다.

팀 분위기 - 100% 만족스럽지 못했다. 회고를 해보니 그 이유가 두 가지인 것 같은데, 첫 번째는 팀원 대부분이 해커톤에 익숙하지 않았고, 초기에 R&R에 대해서 제대로 정하지 않았었다. 그래서 서로가 무슨 작업을 하는지 잘 몰랐고, 공유가 잘 안 되고 리소스가 실제로 낭비된 순간이 있었다. 나랑 같은 생각이신 분이 있었는데 그분이 2일 차에 문제 제기를 해주셨고 그 이후로는 내가 컨트롤 타워 역할을 했다. (팀장이 분명히 계셨는데....ㅠ)

두 번째 이유는 팀장을 하셨던 분이 많이 조급해하셨었다. 그래서 작은 충돌이 있었다. 카페에서 새벽까지 하다가 다들 능률이 떨어지는 거 같아 세 시쯤 "오늘은 이쯤 하시죠" 하고 말씀드렸을 때 "저희 아무것도 안되었는데 어떻게 가요? 가실 분들은 가세요"라고 조금 예민한 반응을 하셨다. 팀장이라서 더 부담을 느끼셨을 수도 있다고 생각은 했지만 팀장이라면 팀 전체를 보는 능력이 필요하다고 생각한다. 해커톤이 끝나고 팀장으로서 역할을 안 하셔서 미안했다고 하시면서 훈훈하게 마무리됐다.

잘한 점

맥주 마시면서 아이디어톤 - 1일 차 저녁에 라포형성을 위해서 맥주를 마시는 자리가 있었는데, 그때까지 마음에 드는 아이디어가 안 나왔었다. 그래서 태블릿에 오만 아이디어를 다 적다가 콜 포비아라는 주제가 나왔고 다들 거기에 꽂혀서 기간 내내 주제에 대한 애정이 있었다.

생각 주저 없이 얘기하기 - 첫날 라포 형성이 잘 돼서 뭔가 불편하거나 다른 팀원들에게 요구하고 싶은 게 있을 때 조금 더 쉽게 얘기할 수 있었던 것 같다.

MVP 설정 - 전화 통화 시뮬레이션이라는 핵심 기능에 집중해서 필요 없는 기능을 다 버리는 걸 잘했다고 생각한다. 해커톤의 취지에 맞게 잘해서 수상할 수 있었다고 생각한다.

아쉬운 점

기술 수준 - 생산성에만 집중해서 기술적인 수준을 너무 낮게 잡았던 점

팀장 선정 - 사실 팀장을 맡으셨던 분한테 뭐라고 할 수도 없는 게 팀장을 하고 싶어 하셨던 것도 아니고 무슨 합리적인 이유 없이 우르르 여론 형성으로 얼떨결에 맡으셨다. 팀장의 리딩 없이 진행되다 보니 우왕좌왕할 일이 많았던 거 같다.

R&R 공수 선정 - 개인적인 생각이지만 어떤 업무에 더 무게를 실어야 할지를 잘못 설정해서 디자인만 하루종일 하신 분도 계셨다. 다행히 중간에 기술 멘토님한테 개발 공수에 대한 피드백을 받고 조금 방향성을 잡을 수 있었다.

배운 점

새로운 기술/도구 활용 경험: GPT API, Firebase, TTS/STT

협업 과정에서의 교훈 - 의견을 부드럽게 얘기하기, 억지 텐션으로 공감하기(?) 등의 소프트 스킬

해커톤 경험 - 일반 프로젝트와 해커톤에서의 개발은 명확히 차이가 있다는 걸 배웠다. 빠른 개발과 평가 요소 그리고 감정 컨트롤 등 신경 써야 할 부분이 많았다.

이번 해커톤에서는 하드 스킬보다 소프트 스킬을 더 많이 배운 거 같다.

다음 해커톤에서 개선할 점

시간 배분 및 공수 전략 변경: 기획 20%, 개발 60%, 발표 준비 20% 정도가 적당하다고 생각한다. 또 하나는 자잘한 디테일(디자인 등)부터 잡고 들어가면 결국 리소스 낭비로 이어진다는 생각이 조금 생겼다. 디테일은 몇 번이고 수정될 가능성이 많으니까?

의사소통 방식 개선 - 중간 공유가 필수다. 하루에 최소 두 번 이상은 스크럼을 하던지 해서 공유를 하면 좋을 거 같다!

총평

첫 해커톤이었는데 걱정했던 거보다 할만했다. 라포 형성이 아주 중요한 요소임을 알 수 있었다. 또 소프트 스킬을 많이 얻어가는 거 같아서 참 좋았다! 상 받아서 기분 좋았다!

[Java] 상속(Inheritance)

G_Batman — Thu, 27 Feb 2025 01:47:17 +0900

상속이란?

상속은 이미 존재하는 클래스를 바탕으로, 변수나 메서드를 물려받아 사용하는 개념입니다.

즉, 부모(상위) 클래스가 가진 기능을 자식(하위) 클래스가 이어받아서 재사용하거나 확장할 수 있습니다.

사용 이유

코드 재사용성 향상
- 이미 만들어진 클래스의 코드를 재사용하여 중복 코드를 줄일 수 있습니다
유지보수 용이
- 공통 기능은 부모 클래스에 모아두고, 수정이 필요할 때 부모 클래스만 수정하면 자식 클래스들이 한꺼번에 영향을 받습니다
확장성 증가
- 자식 클래스는 부모 클래스에서 받은 기능을 토대로 추가 기능이나 새로운 구현 방법을 적용할 수 있습니다

상속의 기본 문법

자바에서 클래스를 상속할 때는 extends 키워드를 사용합니다

(예시 코드)

// 부모 클래스
class Animal {
    String name;

    void eat() {
        System.out.println("먹고 있습니다");
    }
}

// 자식 클래스
class Dog extends Animal {
    void bark() {
        System.out.println("멍멍");
    }
}

public class Main {
    public static void main(String[] args) {
        Dog dog = new Dog();  // Dog는 Animal을 상속받았으므로
        dog.name = "마루";      // Animal 클래스의 name 필드 사용 가능
        dog.eat();            // Animal 클래스의 eat 메서드 사용 가능
        dog.bark();           // Dog 클래스에서 새로 정의한 bark 메서드
    }
}

자식 클래스 Dog는 extends Animal을 통해 Animal 클래스의 필드와 메서드를 물려받았습니다
Dog 객체를 만들면 Animal에서 정의된 기능(예: name, eat())도 그대로 사용할 수 있습니다

부모와 자식 클래스

부모(상위) 클래스: 다른 클래스에게 물려줄 공통된 기능을 가진 클래스
자식(하위) 클래스: 부모 클래스로부터 기능을 물려받아 쓰는 클래스

자식 클래스는 부모 클래스의 모든 멤버를 갖지만 접근 제어자(public, protected, private 등)에 따라 실제 사용 가능 여부가 달라집니다

// Parent.java
class Parent {
    public String publicField = "누구나 접근 가능";
    protected String protectedField = "자식 클래스에서 접근 가능";
    private String privateField = "해당 클래스에서만 접근 가능";
    
    public void publicMethod() {
        System.out.println("public 메서드");
    }
    
    protected void protectedMethod() {
        System.out.println("protected 메서드");
    }
    
    private void privateMethod() {
        System.out.println("private 메서드");
    }
}

// Child.java
class Child extends Parent {
    void accessTest() {
        System.out.println(publicField);      // 가능
        System.out.println(protectedField);   // 가능
        // System.out.println(privateField);  // 불가능 - 컴파일 에러
        
        publicMethod();      // 가능
        protectedMethod();   // 가능
        // privateMethod();  // 불가능 - 컴파일 에러
    }
}

위 두 개의 자바 코드를 같은 패키지에 넣고 테스트해보시면 그 차이를 금방 확인할 수 있습니다.

메서드 오버라이딩(Overriding)

상속을 받았을 때, 부모 클래스의 메서드를 그대로 사용할 수도 있지만, 자식 클래스에서 재정의(오버라이딩) 할 수도 있습니다.

재정의란 부모의 메서드를 자식이 덮어써서 새롭게 만드는 것을 말합니다

class Animal {
    void eat() {
        System.out.println("동물이 먹고 있습니다");
    }
}

class Dog extends Animal {
    @Override
    void eat() {
        System.out.println("강아지가 사료를 먹고 있습니다");
    }
}

@Override 어노테이션은 자식 클래스가 부모 클래스의 메서드를 재정의했다는 표시입니다.
메서드 이름을 일치시켜야합니다.
이렇게 재정의하면 자식 클래스의 메서드가 우선적으로 호출됩니다.

super 키워드

오버라이딩된 메서드 안에서 부모 메서드를 호출하고 싶다면 super 키워드를 사용할 수 있습니다

class Animal {
    void eat() {
        System.out.println("동물이 먹고 있습니다");
    }
}

class Dog extends Animal {
    @Override
    void eat() {
        super.eat(); // 부모의 eat() 호출
        System.out.println("강아지가 사료를 먹고 있습니다");
    }
}

이렇게 하면 부모의 기능을 살리면서 자식 클래스만의 새로운 로직을 추가할 수 있습니다

한 단계 더 나아가기

다중 상속이 불가능한 이유

자바는 단일 상속만을 지원합니다

즉, 한 클래스가 오직 하나의 부모 클래스만을 상속받을 수 있습니다

여러 부모 클래스를 동시에 상속받으면 같은 메서드 이름이 여러 곳에서 정의되어 충돌이 발생할 수 있기 때문입니다

이 문제를 피하기 위해 인터페이스를 사용해 다중 구현을 지원하는 방식으로 자바는 구조화되어 있습니다

관계형 데이터베이스 - 릴레이션(Relation), 튜플(Tuple), 속성(Attribute), 도메인(Domain)

G_Batman — Mon, 10 Feb 2025 16:29:22 +0900

안녕하세요 배트맨 입니다.

오늘은 정보처리기사 공부 중 DB과목에서 자주 출제되는 문제의 내용을 다루어보겠습니다.

Ai 생성 이미지

관계형 데이터베이스

- 관계형 데이터베이스(Relational Database, RDB)는 데이터를 2차원적인 표(Table)형식으로 저장하고, 데이터 간의 관계를 정의하는 데이터베이스이다.

- 개체(Entity)와 관계(Relationship)를 표현하는데, 이를 각각 개체 릴레이션과 관계 릴레이션이라고 한다. 여기서 릴레이션(Relation)은 표(Table)라고 보면 된다.

- 장점

데이터를 이해하기에 간결하고 편리하다
다른 데이터베이스 시스템과의 변환이 비교적 쉽다

- 단점

데이터가 복잡해질수록 성능이 다소 떨어짐

릴레이션 구조

릴레이션(Relation)은 데이터를 표 형식으로 표현한 것으로, 구조를 나타내는 릴레이션 스키마와 실제 값들인 릴레이션 인스턴스로 구성된다.

튜플(Tuple)

정의: 릴레이션을 구성하는 행(Row)으로, 여러 속성(Attribute)의 모임이다.
튜플의 개수: 카디널리티(Cardinality) 또는 기수라고 부른다.

속성(Attribute)

정의: 데이터베이스를 구성하는 가장 작은 논리적 단위로, 개체의 특성을 나타낸다.
속성의 개수: 디그리(Degree) 또는 차수라고 한다.

도메인(Domain)

정의: 하나의 속성이 가질 수 있는 값들의 집합.
역할: 속성 값이 허용된 범위를 벗어나지 않도록 검증하는 데 사용된다.

릴레이션의 특징

중복된 튜플이 존재할 수 없음
- 동일한 데이터를 여러 번 저장할 수 없다.
튜플 간의 순서는 의미가 없음
- 데이터가 저장된 순서는 중요하지 않다.
시간에 따라 릴레이션 인스턴스는 변화할 수 있음
- 데이터 삽입, 삭제 등의 작업을 통해 변경될 수 있다.
속성들의 순서는 중요하지 않음
- 릴레이션의 속성(열) 순서는 관계형 데이터베이스에서 의미를 가지지 않는다.
속성의 명칭은 유일해야 함
- 동일한 릴레이션 내에서는 속성의 이름이 중복될 수 없다.
속성 값은 동일한 값이 존재할 수 있음
- 특정 열에서 같은 데이터 값을 가질 수 있다.
튜플을 식별하기 위해 키(Key)를 설정
- 특정 속성 또는 속성의 부분집합을 활용하여 튜플을 식별한다.
속성의 값은 원자적(Atomic)이어야 함
- 하나의 속성 값은 논리적으로 더 이상 나눌 수 없는 단일 값이어야 한다.