Tom's Note

MySQL Connection.isValid() 최적화

크크크크 — Mon, 30 Mar 2026 22:44:35 +0900

HikariCP에서 Connection.isValid() 이 실행되는 시점

커넥션 풀에서 커넥션을 꺼낼 때
정확히는 두 가지 시점이 있습니다:

시점	조건	설명
커넥션 획득 시	항상	getConnection() 호출 시 풀에서 꺼낸 커넥션이 유효한지 검증
유휴 커넥션 검사	keepaliveTime 설정 시	풀에 놀고 있는 커넥션을 주기적으로 검증 (기본값: 0 = 비활성)

즉, 애플리케이션에서 DB 요청할 때마다 SELECT 1 → 실제 쿼리 이렇게 매번 2개의 쿼리가 나가고 있었던 상황.
COM_PING으로 전환하면 이 검증이 SQL 파서를 거치지 않는 프로토콜 명령으로 대체된다.

참고로 HikariCP 설정 중 관련된 것들:

설정	기본값	역할
connectionTestQuery	없음 (JDBC4 isValid 사용)	커넥션 유효성 검증 쿼리
`validationTimeout`	`5000ms`	검증 타임아웃
`keepaliveTime`	`0` (비활성)	유휴 커넥션 주기적 검증 간격

connectionTestQuery가 실행되는 시점

상황	connectionTestQuery 설정됨	connectionTestQuery 미설정
getConnection() 호출 시	SELECT 1 실행	isValid() → COM_PING
유휴 커넥션 주기 검사 (`keepaliveTime > 0`)	`SELECT 1` 실행	`isValid() → COM_PING`
유휴 커넥션 주기 검사 (`keepaliveTime = 0`)	검사 안 함	검사 안 함

keepaliveTime이 0이든 아니든, getConnection() 할 때마다 커넥션 유효성 검증은 항상 실행됩니다.
connectionTestQuery가 설정되어 있으면 매번 SELECT 1이 나가고, 미설정이면 COM_PING이 나가는 구조입니다.

HikariCP 헬스체크 전환: SELECT 1 → COM_PING

배경

기존에 HikariCP의 connectionTestQuery("SELECT 1")을 사용하여 커넥션 유효성을 검증하고 있었다.
이 방식은 커넥션 풀에서 커넥션을 꺼낼 때마다 SELECT 1 쿼리를 DB에 실행하므로, 불필요한 DB 조회 부하가 발생한다.

조사 결과, HikariCP는 JDBC4 드라이버 사용 시 connectionTestQuery를 설정하지 않으면
Connection.isValid()를 호출하고, MySQL Connector/J는 이를 내부적으로 COM_PING 프로토콜 명령으로 처리한다.
COM_PING은 SQL 쿼리가 아닌 MySQL 프로토콜 레벨의 경량 명령(1바이트)으로, SELECT 1 대비 오버헤드가 적다.

변경 내용

변경 사항

connectionTestQuery("SELECT 1") 설정을 제거(주석 처리)하여
HikariCP 기본 동작인 JDBC4 Connection.isValid() → COM_PING 방식으로 전환했다.

// Before
hikariConfig.setConnectionTestQuery("SELECT 1");

// After (제거)
// hikariConfig.setConnectionTestQuery("SELECT 1");

동작 원리

항목	SELECT 1 방식	COM_PING 방식
설정	connectionTestQuery("SELECT 1")	설정 없음 (기본값)
동작	SQL 쿼리 실행	MySQL 프로토콜 명령 (`0x0e`)
패킷 크기	수십 바이트 (SQL 문자열)	5바이트 (헤더 4 + 명령 1)
DB 파서	SQL 파서 경유	프로토콜 레벨 처리
HikariCP 조건	JDBC4 미지원 드라이버용	JDBC4 드라이버 사용 시 기본값

환경 정보

HikariCP: Spring Boot 내장
MySQL Connector/J: 8.0.33 (JDBC4 지원)
MySQL: 8.0.42 (AWS RDS)

검증

1단계: profileSQL 로그를 통한 간접 검증

JDBC URL에 profileSQL=true를 추가하면 MySQL Connector/J가 실행하는 모든 SQL을 stderr로 출력한다.

connectionTestQuery("SELECT 1") 설정 시 → 로그에 SELECT 1 출력됨
connectionTestQuery 미설정 시 → 로그에 SELECT 1 미출력 (SQL이 아닌 COM_PING 사용)

테스트 코드:
connector/src/test/java/com/eximbay/datasource/HikariConnectionHealthCheckTest.java

2단계: tcpdump + Wireshark를 통한 직접 검증

네트워크 패킷 캡처로 COM_PING (0x0e) 패킷이 실제로 전송되는 것을 확인했다.

tcpdump 캡처

# 패킷 캡처 (en0 인터페이스, RDS 포트 지정)
sudo tcpdump -i en0 port 23306 -w /tmp/mysql_comping.pcap

# 별도 터미널에서 테스트 실행
./gradlew :connector:test --tests "com.eximbay.datasource.HikariConnectionHealthCheckTest.withoutTestQuery_logDoesNotContainSelect1"

# Ctrl+C로 캡처 중지

tcpdump 분석

# 클라이언트→서버 방향, length 5 패킷의 MySQL command byte 확인
tcpdump -r /tmp/mysql_comping.pcap -nn -X 'src {클라이언트IP} and dst port 23306' | grep -B2 -A4 "length 5"

MySQL 프로토콜 패킷 구조 (5바이트):

01 00 00 00 0e
│        │  └─ command byte: 0x0e = COM_PING (14)
│        └──── sequence id: 0
└───────────── payload length: 1

캡처 결과:

⚪ COM_QUIT (0x01): 커넥션 종료
  COM_PING (0x0e): isValid() → COM_PING 호출 확인
  COM_PING (0x0e): isValid() → COM_PING 호출 확인
⚪ COM_QUIT (0x01): 커넥션 종료

Wireshark 확인

.pcap 파일을 Wireshark에서 열기
비표준 포트이므로 Analyze → Decode As...에서 TCP port 23306을 MySQL로 설정
Display Filter에 mysql.command == 14 입력
COM_PING 패킷만 필터링되어 표시됨

mysql.command == 14는 Wireshark가 패킷 바이너리를 MySQL 프로토콜 규격으로 파싱한 내부 필드를 기준으로 필터링한다.
화면에 보이는 텍스트 검색이 아니라, 디코딩된 프로토콜 필드 값으로 매칭한다.

참고 필터:

필터	설명
mysql.command == 14	COM_PING
`mysql.command == 1`	`COM_QUIT`
`mysql.command == 3`	`COM_QUERY` (SELECT 등)

결론

connectionTestQuery("SELECT 1") 제거만으로 HikariCP가 자동으로 COM_PING 기반 헬스체크로 전환되며,
profileSQL 로그와 네트워크 패킷 캡처 양쪽에서 이를 검증 완료했다.

SELECT 1 검증 쿼리 확인 방법

운영 중인 MySQL에서 SELECT 1 헬스체크가 실제로 얼마나 실행되고 있는지 쿼리로 확인할 수 있다.

Com_select 카운터 확인

-- SELECT 문 실행 횟수 (서버 시작 이후 누적)
SHOW GLOBAL STATUS LIKE 'Com_select';

connectionTestQuery("SELECT 1") 제거 전후로 이 값의 증가 속도를 비교하면 효과를 확인할 수 있다.

일정 시간 동안 SELECT 1 발생량 측정

-- 1) 현재 값 기록
SELECT VARIABLE_VALUE INTO @before
FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Com_select';

-- 2) 일정 시간 대기 (예: 10초)
DO SLEEP(10);

-- 3) 차이 계산
SELECT VARIABLE_VALUE - @before AS select_count_in_10s
FROM performance_schema.global_status WHERE VARIABLE_NAME = 'Com_select';

General Log로 SELECT 1 직접 확인

-- General Log 활성화 (운영 환경에서는 짧은 시간만 사용)
SET GLOBAL general_log = 'ON';
SET GLOBAL log_output = 'TABLE';

-- 일정 시간 후 SELECT 1 쿼리 확인
SELECT event_time, command_type, argument
FROM mysql.general_log
WHERE argument LIKE 'SELECT 1%'
ORDER BY event_time DESC
LIMIT 20;

-- General Log 비활성화
SET GLOBAL general_log = 'OFF';

General Log는 모든 쿼리를 기록하므로 성능에 영향을 준다.
운영 환경에서는 짧은 시간만 활성화하고 반드시 끌 것.

Performance Schema로 확인

-- SELECT 1 쿼리의 실행 통계 확인
SELECT DIGEST_TEXT, COUNT_STAR, AVG_TIMER_WAIT/1000000000 AS avg_ms
FROM performance_schema.events_statements_summary_by_digest
WHERE DIGEST_TEXT LIKE 'SELECT ?%'
ORDER BY COUNT_STAR DESC
LIMIT 10;

SELECT ?는 MySQL이 SELECT 1을 정규화한 형태다.
COUNT_STAR가 커넥션 풀 크기 × 요청 수에 비례하면 헬스체크 쿼리일 가능성이 높다.

참고

HikariCP 공식 문서 — JDBC4 드라이버 사용 시 connectionTestQuery 설정하지 않을 것을 권장
https://github.com/brettwooldridge/HikariCP#frequently-used

한글이 왜 깨질까? 캐릭터셋과 인코딩에 대해서 알아보자

크크크크 — Sun, 28 Sep 2025 01:29:11 +0900

1. 깨진 한글과의 첫 만남

개발을 하다 보면 영어는 멀쩡한데, 한글만 ��처럼 깨져 보이는 경험을 하게 된다.

“같은 요청인데 왜 영어는 괜찮고, 한글만 깨질까?”

그 해답은 바로 문자셋(Character Set)과 인코딩(Encoding)에 숨어 있다.

2. 문자셋과 인코딩의 차이

문자셋(Character Set): 문자에 번호를 붙인 목록 (예: 가 = U+AC00)
(사전 같은 개념이라고 생각해보자)
인코딩(Encoding): 그 번호를 실제 바이트로 바꾸는 규칙

예시 – "가" (U+AC00):

UTF-8 → EA B0 80 (3바이트)
UTF-16LE → AC 00 (2바이트)
EUC-KR → B0 A1 (2바이트)

즉, 같은 문자라도 인코딩 방식에 따라 바이트가 달라진다.

영어는 ASCII 영역(0~127) 덕분에 어느 인코딩에서나 값이 같아 깨지지 않는 반면, 한글은 인코딩 차이로 쉽게 깨진다.

3. 실제 바이트 비교 – “가나다”

아래 표는 "가나다"라는 문자열을 다양한 인코딩으로 표현했을 때의 바이트 값이다.

문자	유니코드 코드 포인트	UTF-8(hex)	UTF-16LE(hex)	EUC-KR(hex)
가	U+AC00	EA B0 80	AC 00	B0 A1
나	U+B098	EB 82 98	98 B0	B3 AA
다	U+B2E4	EB 8B A4	E4 B2	B4 D9

같은 "가나다"라도 UTF-8은 9바이트, UTF-16LE는 6바이트, EUC-KR은 6바이트를 차지한다.
이 차이 때문에 시스템마다 다르게 해석되면 “깨짐” 현상이 발생하는 거죠.

4. 문자셋의 역사적 배경

ASCII: 7비트, 영어/숫자/기호만 표현 가능
ISO-8859 계열: 유럽 언어 확장 (라틴-1, 키릴, 아랍 등)
EUC-KR, CP949: 한국어 문자 집합 (완성형 한글 지원)
Shift_JIS: 일본어 문자 집합
GB2312, GBK, GB18030: 중국어 문자 집합

→ 결국 언어별로 각자 표준을 만들어 쓰다 보니, 다국어 환경에서 충돌이 생기고 “문자 깨짐”이 일상이 되고 있다.

5. 유니코드와 UTF 시리즈

이 문제를 해결하기 위해 등장한 게 유니코드(Unicode)다

유니코드: 전 세계 모든 문자를 하나의 코드 포인트 체계로 통합 (0x0000 ~ 0x10FFFF)

유니코드를 바이트로 변환하는 인코딩 방식이 UTF (Unicode Transformation Format)이다.

UTF-8: 가변 길이 1~4바이트, ASCII 호환 → 웹/네트워크 표준
UTF-16: 대부분 2바이트, 동아시아 문자 효율 ↑ → Windows, Java 내부 표현
UTF-32: 고정 4바이트, 단순하지만 메모리 낭비 심함

Unicode의 다른 이름들
UCS (Universal Coded Character Set): ISO/IEC 10646 국제 표준에서 쓰는 이름. 사실상 Unicode와 동일한 개념.
코드 페이지(Code Page): 유니코드 이전 시대, Windows/IBM에서 문자셋을 부르던 이름 (예: CP949, CP1252).
BMP (Basic Multilingual Plane): 유니코드 첫 평면 (U+0000 ~ U+FFFF). 예전에는 “16비트면 충분”하다고 했던 배경.

6. 실무에서 만난 문제와 해결

기존 서버: 인코딩을 느슨하게 처리 → 어떤 charset이 와도 잘 받아줌
차세대 서버: UTF-8 전제 → 다른 인코딩 오면 깨짐
라우트 서버: 요청을 한 번 디코딩 후 다시 UTF-8로 인코딩 → 기존 서버가 받으면 이미 깨진 상태

해결책:

Content-Type 헤더에서 charset 확인
UTF-8이면 차세대 서버로 전달 대상
아니면 레거시 서버로 라우팅
전달할 때는 반드시 raw bytes 그대로 넘겨야 깨지지 않음

7. 보안과 시스템 설계에서의 중요성

문자셋과 인코딩은 단순히 “깨짐 방지” 이상의 의미가 있다.

보안: 인코딩 불일치를 이용한 공격 → XSS, SQL Injection 우회 (%uXXXX 등)
시스템 설계: 글로벌 서비스는 기본적으로 UTF-8 통일
소프트웨어 공학: 국제화(i18n), 지역화(l10n)에서 필수 지식
CS 기본기: 데이터 표현(문자 → 코드포인트 → 바이트)의 이해

보안 & 국제화 & 지역화에 대해서 더 정리하자면

( 보안 )

무슨 문제인가? 입력이 여러 번 디코딩/재인코딩되거나, 서버, 프록시, 앱이 서로 다른 문자셋을 가정하면 필터/검증을 우회할 수 있음.

문자열 = 바이트의 해석 결과
네트워크/스토리지 레벨은 바이트. 사람이 읽는 문자열은 바이트를 어떤 인코딩으로 해석해서 얻은 결과.
중간 컴포넌트가 임의로 디코딩/재인코딩하면 의미가 바뀜
예) 프록시가 URL 디코딩을 한 번 하고, 웹 앱은 또 디코딩을 하면(또는 다른 charset으로 디코딩하면) 원래 숨겨진 문자가 드러남.
검증기는 보통 ‘지금 보이는 문자열’만 검사
검증 시점에선 무해해 보여도, 나중에 또 디코딩되면 악성 코드가 됨 → 우회 성공.

예시 A) 이중(중첩) 인코딩으로 XSS 우회

공격자 전송(이중 인코딩):(이건 "<" → "%3C" → "%253C" 처럼 한 번 더 인코딩한 것)
%253Cscript%253Ealert(1)%253C/script%253E
흐름:
1. 프록시(또는 웹서버)가 URL 디코딩을 한 번만 수행 → 결과: %3Cscript%3Ealert(1)%3C/script%3E
2. → 이 문자열은 아직 <로 변하지 않아서 필터(“금지 문자열 <script> 포함 여부”)를 통과할 수 있음.
3. 앱 레이어에서 추가로 디코딩(또는 템플릿이 무심코 디코드) → 결과: <script>alert(1)</script> → 브라우저에서 실행 → XSS 성공.

한 번만 검사하면 안 된다. 여러 계층에서의 디코딩 타이밍을 고려해야 함.

예시 B) %uXXXX (옛 JS 이스케이프) 우회

구형 코드/라이브러리에서 unescape('%u003C') → < 로 해석되는 경우가 있음.
공격자가 %u003Cscript%u003E처럼 보내면 일부 필터에서 걸리지 않다가, 브라우저/JS에서 해석되면 XSS 발생.

예시 C) 인코딩 불일치로 인한 SQL 우회(개념적)

공격자가 의도적으로 바이트열을 구성해서,
- 방화벽/프록시가 UTF-8로 디코딩하면 안전한 문자로 보이고,
- 백엔드가 CP949/EUC-KR로 디코딩하면 '(따옴표)나 ; 같은 문자가 나와 SQL 쿼리를 끊는 경우.
  (구체적 바이트 값은 인코딩별 매핑에 따라 달라지므로, 원리는 “다른 인코딩에서는 다른 문자로 보일 수 있다”는 점.)

검증필터가 어떤 인코딩/타이밍에서 작동하는지 반드시 명확해야 한다.

우선순위 실무 체크리스트 방어 방법

입력 정규화(입력 지점에서 canonicalize)
- 수신한 원본 바이트(raw bytes)를 한 번만 정해진 방식(예: UTF-8)으로 디코딩 → 정규화(Unicode NFC) → 그 결과로만 검증/필터 적용.
- 즉, “정규화 → 검증 → 처리” 순서를 강제.
- (중요) 중간 컴포넌트가 임의로 디코딩하지 않게 아키텍처 설계.
전 구간 인코딩 통일(또는 명시적 계약)
- 클라이언트 → 프록시 → 앱 → DB → 로그까지 UTF-8 강제(또는 명확히 문서화된 인코딩).
- Content-Type에 charset=utf-8을 명시하고, 다른 charset은 거부하거나 엄격히 로깅/검사.
디코딩/디코드 연산을 최소화
- 프록시나 게이트웨이가 쿼리스트링과 본문을 임의로 디코딩하지 않도록 설정.
- 가능한 raw bytes를 그대로 전달하고, 애플리케이션 단에서 한 번만 처리.
검증을 바이트 레벨이 아니라 ‘정규화된 유니코드 문자열’ 레벨에서 수행
- unicodedata.normalize('NFC', text) 같은 정규화를 통해 동등성 문제(NFKC/NFC)를 제거한 뒤 필터 적용.
출력 인코딩(escaping) 철저
- HTML context → HTML escape (e.g., <, >)
- JS context → JS escape
- SQL → 파라미터화(PreparedStatement) 등.
- 이건 입력 검증이 뚫려도 최종 공격 실행을 막는 마지막 방패.
파라미터화된 쿼리 사용
- 문자열 연결로 쿼리를 만들지 마라. SQL Injection 근본 차단.
의심스러운 인코딩/이상 패턴 차단 로깅
- %uXXXX, 중첩 인코딩(%25 sequences), 이상한 대량 non-UTF-8 바이트 등은 탐지를 거부하거나 심층 검사.
테스트 케이스로 ‘이중 디코딩’ 시나리오 포함
- CI 유닛/통합 테스트에 double-encoding, unicode-escape, legacy-encoding 사례 포함.

입력이 여러 번 디코딩되거나(또는 서로 다른 컴포넌트가 서로 다른 인코딩 전제로 디코딩하면),
한 컴포넌트에서는 “안전한 값”으로 보이지만 최종적으로는
악성 문자열(<script>, ' OR 1=1 -- 등)이 되어서 필터를 우회하여 침투할 수 있다.

( 국제화 & 지역화 )

i18n (internationalization): 소프트웨어를 다국어 대응 가능하게 만드는 과정.
i10n (localization): 특정 언어/문화권에 맞게 현지화하는 과정.

❓무엇을 조심할까 (i18n에서의 위험 요소들)

문자 길이 문제
- 예: "가"는 UTF-8에서 3바이트, UTF-16에서 2바이트 → “문자 수 제한”과 “바이트 크기 제한”이 달라질 수 있음.
- 특히 DB 칼럼 정의(VARCHAR(10) vs VARCHAR(30 BYTE))에서 혼동.
정렬(Collation)
- "가나다"와 "가 나다"를 사전순으로 정렬할 때, 한국어 사전 규칙과 단순 유니코드 코드포인트 정렬이 달라질 수 있음.
- MySQL, PostgreSQL도 collation을 설정하지 않으면 기대와 다른 정렬 결과가 나옴.
대소문자 규칙
- 영어: User == user
- 터키어: "I".lower() → "ı" (점 없는 i)
- 단순 toLowerCase()로는 언어별 규칙을 반영 못함.
날짜/숫자 포맷
- 한국: 2025-09-28, 미국: 09/28/2025, 독일: 28.09.2025
- 통화: 1,234.56 (미국) vs 1.234,56 (독일)
- 지역화를 고려하지 않으면 잘못된 값 파싱 가능.
방향성 (RTL, Right-to-Left)
- 아랍어, 히브리어 등은 오른쪽→왼쪽으로 작성.
- UI 레이아웃, 입력 필드, 문자열 붙임 위치(예: 따옴표·괄호)도 영향을 받음.

‼️ 실무 원칙

저장/전송은 UTF-8 통일
- DB, API, 메시지 큐, 로그 → 전부 UTF-8로 강제.
- 이유: 호환성, ASCII fallback, 네트워크 효율.
입력은: 바이트 → 정규화(NFC) → 유효성 검사 → 저장
- é → 단일 문자(U+00E9) / e+́ 조합(U+0065 + U+0301) → 시각적 동일
- 정규화를 안 하면 “동일하게 보이는 문자열이 DB에서는 다르다”는 문제 발생.
- 저장은 NFC, 보안 검사 시는 NFKC + casefold 활용.
문자 길이 vs 바이트 길이 분리
- UI 제한(예: 닉네임 10글자): 문자 단위(grapheme cluster)
- DB 저장/네트워크 패킷 제한: 바이트 단위
- “이모지 하나 = 2~4 code units” 문제를 꼭 고려해야 함.
로케일 기반 처리
- 문자열 비교, 정렬은 반드시 collation을 지정해야 함.
- 자바: Collator, Python: locale.strxfrm, DB: COLLATE 절.
이모지·보조 평면 지원
- 이모지는 UTF-8에서 4바이트, UTF-16에서 surrogate pair(2 code units).
- Java String.length()는 code unit 수 → " ".length() == 2 (혼동 주의).
- UI는 grapheme cluster 단위로 길이 계산해야 올바름. (Python regex\PLG, ICU 라이브러리 사용)
RTL 언어 테스트
- UI에서 텍스트 정렬·플로우가 깨지지 않게 해야 함.
- HTML: <bdo dir="rtl">, CSS: direction: rtl
- 숫자·기호·이모지 섞이면 혼란 생기므로 반드시 QA 필요.

✅ 배포 전 체크리스트

Content-Type: text/html; charset=UTF-8 헤더 강제.
DB 문자셋 utf8mb4(MySQL) / UTF8(Postgres) 확인.
로그/백업도 UTF-8로 통일 (혼합 인코딩 방지).
외부 연동(API, 메일, SFTP 등) 시 인코딩 계약서/명세 확인.
이모지/보조 평면 저장 가능한지 확인 (MySQL의 utf8 vs utf8mb4 차이).
UI/UX 테스트에 RTL 언어 포함(아랍어/히브리어 샘플 텍스트).
다국어 정렬, 검색 동작 확인 (예: “김영희” vs “김 영희”).

인코딩이 틀어지면 보안 필터가 무력화될 수 있고, 국제화, 지역화는 단순 인코딩 통일을 넘어 문자 단위의 처리, 정렬, 표시까지 고려해야 안전하고 올바르게 동작한다.

결국, 우리가 맞닥뜨린 한글 깨짐은 단순한 버그가 아니라,

컴퓨터가 문자를 이해하는 방식 자체를 탐험하는 여정이었던 셈이다.
한글이 꺠지는 순간, 나는 비로소 유니코드와 UTF-8의 위대함을 깨달았다.

macOS에서 계정명(short name) 변경하기 - Sequoia 15.1 경험 정리

크크크크 — Sun, 21 Sep 2025 15:02:31 +0900

1. macOS 계정 구조 이해하기

macOS에는 계정과 관련된 세 가지 이름이 있다:

Full name (전체 이름)
- 로그인 화면이나 Finder에 표시되는 이름. 단순히 표시용이다.
Short name (계정명, RecordName)
- 시스템이 계정을 식별하는 핵심 값. UID와 연결되어 파일 권한까지 좌우한다.
Home directory (NFSHomeDirectory)
- /Users/shortname 형태로, 실제 데이터와 설정이 저장되는 경로.

파일 권한은 UID(숫자)에 묶여 있기 때문에 UID를 건드리지 않는 한 short name을 바꿔도 권한은 깨지지 않는다.

2. 예전(macOS Catalina ~ Big Sur) 방식

과거에는 계정명 변경이 번거로웠다.

1. 변경 하기 전 상태를 확인

dscl . -read /Users/newname

2. dscl 명령어로 short name(RecordName) 수정

sudo dscl . -change /Users/oldname RecordName oldname newname

3. dscl로 홈 디렉토리 경로(NFSHomeDirectory)도 수정

sudo dscl . -change /Users/newname NFSHomeDirectory /Users/oldname /Users/newname

4. Finder/터미널에서 실제 /Users/oldname 폴더명을 /Users/newname 으로 변경

sudo mv /Users/oldname /Users/newname

5. chown 으로 권한 보정

sudo chown -R newname:staff /Users/newname

즉, short name과 홈 디렉토리, 실제 폴더 세 군데를 모두 맞춰줘야 했다.

더 예전에는 계정명과 디렉토리 명을 수동으로 변경한 적도 있다...

dscl은 macOS전용

풀네임은 Directory Service command line utility 라고 해서, macOS가 내부적으로 계정을 관리하는 DirectoryService / opendirectoryd DB에 접근하는 도구

특징

macOS에만 기본 탑재돼 있음 (/usr/bin/dscl)
전통적인 UNIX/Linux 계열은 /etc/passwd, /etc/shadow, /etc/group 같은 텍스트 파일을 직접 수정하지만,
macOS는 이걸 다 opendirectoryd가 관리 → dscl로 접근해야 함
예전 macOS 서버 시절(Open Directory 기반 LDAP)에서도 동일하게 쓰였고, 지금은 로컬 사용자/그룹 관리에도 그대로 사용됨

Linux랑 비교

Linux → useradd, usermod, passwd, vipw 같은 명령어로 /etc/passwd 수정
macOS → dscl (ex: dscl . -read /Users/username)

3. Sequoia(15.x) 이후 달라진 점

Sequoia에서는 계정 관리가 단순화되었다.

RecordName만 바꿔도 자동으로:
- NFSHomeDirectory 값이 /Users/newname 으로 변경
- 실제 /Users/oldname 폴더명이 /Users/newname 으로 rename
- UID는 그대로 유지되어 권한도 자동으로 newname으로 보정

즉, 예전에는 3~4단계가 필요했지만, Sequoia에서는 단 한 줄로 끝나는 경우가 많다:

sudo dscl . -change /Users/oldname RecordName oldname newname

재부팅 후 확인:

id -un       # newname
echo $HOME   # /Users/newname

4. 주의할 점

버전에 따라 동작 차이: Ventura나 Sonoma에서는 자동 보정이 일부만 적용되기도 한다. (홈 디렉토리 경로는 남아 있는 경우가 있음)
Keychain: short name 변경 시 꼬일 수 있다. 앱 로그인 문제 발생 시, 키체인 접근에서 로그인 키체인을 재설정하면 해결된다.
보안 앱: 안랩, 백신, Docker 등은 Library/Keychain 데이터를 강하게 묶어두는 경우가 있어 정상 동작을 반드시 확인해야 한다.

결론

Sequoia 15.1에서 계정명 변경을 직접 해본 결과,

과거에는 몇 단계 수작업이 필요했지만, 이제는 dscl 명령 한 줄이면 short name, 홈 디렉토리, 폴더명, 권한까지 자동으로 맞춰졌다.

그래도 버전별 차이를 고려해 “정석 절차”를 알고 있는 게 중요하다.

맥 계정 관리 = UID는 건드리지 말고, short name과 홈 디렉토리만 맞추자!

리눅스는 어떤 CPU 스케쥴링 알고리즘을 사용할까?

크크크크 — Fri, 22 Aug 2025 15:03:00 +0900

1. 왜 이걸 알아야 할까?

백엔드 서버, 컨테이너, 마이크로서비스를 운영할 때 시스템이 느려지는 원인을 파악하려면 CPU가 어떻게 태스크를 선택해서 실행하는지 알아야한다.
top, htop, pidstat, pref 등 시스템 모니터링 도구에서 나오는 load average, context switch, CPU 사용률은 결국 스케줄링 알고리즘의 결정 결과값이다.
멀티스레딩, 병렬처리, 비동기 서버 개발 시 스케줄링 정책의 특성을 모르면 CPU 낭비, starvation, 성능 저하 발생이 이어진다.

즉, CPU 알고리즘은 성능 디버깅, 병렬 시스템 설계, 실시간 서비스 운영을 위해 꼭 알아야 한다.

2. 어떤 알고리즘이 있고, 리눅스에는 어떤걸 쓸까?

이해의 출발을 위해 고전 알고리즘을 알아보자

알고리즘	특징
FCFS (First-Come First-Served)	단순하지만 비효율적, Convoy 효과 발생
SJF (Shortest Job First)	이론상 최적이지만, 실행 시간 예측 어려움
Round Robin	시분할 시스템의 기본, 일정 시간마다 태스크 전환
Priority Scheduling	우선순위에 따라 실행, starvation 가능

그래서 리눅스의 알고리즘은?

리눅스 우분투에서는 기본적으로 CFS(Completely Fair Scheduler)를 사용한다. 이는 Round Robin + Weight 기반 Priority Scheduling을 조합한 현대적 알고리즘이다.

음… 말이 어렵고 잘 와닿지 않는다… 완전히 공정한 스케줄러라는거 같다. 도대체 뭐가 공정하고 어떻게 스케줄링하는지 알아보자

3. CFS(Completely Fair Scheduler)란?

리눅스 커널 2.6.23부터 기본 스케줄러로 채택된 CPU 스케줄러이며 Round Robin처럼 번갈아 주지만, 사용한 시간(vruntime)을 고려해서 덜 쓴 놈에게 먼저 기회를 주는 구조
즉, 공정하게 CPU를 나눠 쓰도록 만드는 알고리즘이다.

왜 만들어 졌을까?

기존의 스케줄러들은 문제점이 많았다고 한다.

Round Robin: 모든 프로세스에 똑같은 시간 주는데, 작업량 차이가 커도 무시해버림
Priority Scheduler: 높은 우선순위가 낮은 우선순위를 굶기기도 함(starvation)
O(1) Scheduler: 매우 빠르지만 비선형적인 스케줄러 동작과 CPU 사용률 편향 문제
그래서 등장한게 CFS라고 합니다.

공정하게 동작하는 과정

가상 실행 시간 vruntime을 통해 파악하고 균형을 맞춥니다.

모든 태스크는 CPU를 사용한 시간이 저장됩니다. → vruntime
이 값이 작은 프로세스일 수록 CPU를 적게 썻다는 뜻입니다. → 우선 실행 대상
즉, CPU를 적게 쓴 프로레스를 먼저 실행 시켜서 균형을 맞추는 겁니다.

“CPU 사용량을 추적하고, 가장 적게 사용한 놈부터 돌려준다”

태스크 관리는 어떻게 할까?

모든 태스크는 vruntime 기준으로 Red-Black Tree에 정렬됩니다.
루트 노드 = 가장 vruntime이 작은 태스크 → 이걸 먼저 실행
실행되면 vruntime이 늘어나고, 다시 트리 재정렬 되며 위 과정을 반복합니다.

키워드: Red-Black Tree

Time Slice가 없습니다??!

기존 Round Robin은 “10ms씩 돌아가자” 식이었는데, CFS는 그런 고정 time slice 개념이 없습니다.
대신:

sched_latency_ns: 전체 프로세스가 한 바퀴 도는데 걸리는 총 시간
min_granularity_ns: 한 태스크가 최소로 보장받는 실행 시간

CFS는 이 값을 기준으로 동적으로 태스크를 교체합니다.

조정 가능한 CFS 파라미터

파일	의미
/proc/sys/kernel/sched_latency_ns	전체 태스크가 한 번씩 실행되는 주기 (기본: 6ms)
/proc/sys/kernel/sched_min_granularity_ns	한 태스크가 최소 실행할 시간 (기본: 750µs)
nice 값	우선순위 가중치 (vruntime 계산 시 반영됨)

예시: CFS 동작 방식

프로세스 3개: A, B, C

A: CPU-bound(연산 많은)
B: I/O-bound(대기 많음)
C: 중간 정도

CFS는 A가 CPU를 오래 쓰면 vruntime이 빨리 증가하고
→ B, C는 상대적으로 vruntime이 작아져 우선 배정됨

실전 명령어

ps -eo pid,ni,psr,cmd --sort=ni  # nice 우선순위 확인

4. CPU, I/O bound에 적합한 스케줄러 무엇인가?

이런 고민을 해볼 것이다.

CFS는 둘중에 어디에 적합하다고 생각하는지 고민해보자
vrutime 이 적은 값이고 자주 태스크가 스위칭 되면 vruntime이 작아질것이다.
.
.
.
.
.
그렇다면 I/O bound이다, 비동기나 외부 자원 대기, API 요청 등 Waiting 상태가 많은 작업에 적합하다.
즉, 짧고 자주 실행되는 작업이 유리하다.
그래서 CFS는 I/O-bound 태스크를 더 자주, 더 빨리 실행시키는 구조로 되어있다.

어떻게 판단할 수 있을까?

리눅스 기준 명령어

명령어	설명
top, htop	CPU 사용률, 상태 (R: Running / S: Sleeping 등)
pidstat -p 1	특정 프로세스의 사용자/시스템 CPU 사용률
iostat -xz 1	디스크 I/O 대기율 확인
vmstat 1	us, sy, wa → CPU, 시스템, 대기 비율 분석

"wa"(IO Wait)가 높으면 I/O-bound 프로세스가 많은 것

us(User CPU)가 높으면 CPU-bound 작업이 많다는 뜻

반대로 CPU-bound는?

Real-Time Priority 기반 스케줄링으로 실시간 우선순위 기반인 스케줄러를 이용하는 것이다.

추가적으로 공부해볼것들

Convoy 효과
Red-Black Tree

[암호화] 웹 보안은 SSL!

크크크크 — Tue, 19 Aug 2025 23:25:29 +0900

1. SSL(Secure Socket Layer)이란?

인터넷 상에서 데이터 통신을 암호화하기 위한 보안 프로토콜입니다.

→ 현재는 SSL이 진화한 TLS(Transport Layer Security)가 사용되고 있지만, 실무에서는 여전히 SSL이란 표현을 널리 사용합니다.

2. SSL의 목적, 암호화!

제 3자가 내용을 볼 수 없도록 암호화하는 기밀성, 전송 중 데이터가 변조되지 않았는지 확인하는 무결성, 서버 또는 클라이언트의 신원을 확인하는 인증이 있습니다.

3. SSL 동작 방식 요약

2종류의 키를 사용 비대칭키와 대칭키를 혼합하여 사용합니다.

암호 방식	특징	사용 이유
비대칭키 암호화	느림, 공개키로 암호화 → 비밀키로 복호화	대칭키 전달 시 사용
대칭키 암호화	빠름, 같은 키로 암복호화	이후 데이터 통신에 사용

즉, 비대칭키는 클라이언트의 대칭키를 가져오기 위한 것이고 대칭키는 전달할 데이터를 암호화 하기 위한 것입니다.

4. 일반적인 SSL 핸드쉐이크 과정( HTTPS 시 사용)

2종류의 키를 사용해서 대칭키를 서버로 전달하는 과정이 SSL 핸드쉐이크 입니다.

→ 이 과정을 SSL Handshake라고 하며, 이 후에는 빠른 대칭키 기반 암호화로 HTTPS 통신이 진행됩니다.

5. 클라이언트가 웹페이지를 읽을 수 있는 이유는?

클라이언트가 서버로부터 받는 HTML, CSS, JS 등의 응답은 대칭키로 암호화되어 전송됩니다. 클라리언트는 자신이 생성한 대칭키를 서버의 공개키로 암호화해서 전달했기 때문에 클라이언트 역시 대칭키를 알고 있습니다. 따라서 같은 대칭키로 응답을 복호화해서 웹페이지를 표시할 수 있습니다.

클라이언트의 대칭키는 어떻게?

사용자가 브라우저를 통해 따로 키를 만들지 않았는데 어떻게 대칭키를 만들어서 서버에 전달할 수 있지?라고 생각을 하셨을 겁니다.

브라우저는 내부에서 자동으로 대칭키를 생성하고 기능(SSL/TLS 스택을 내장)을 탑재하고 있습니다. 그래서 자동으로 이루어지는 보안 동작으로 사용자는 개입하지 않으면서 https를 사용할 수 있게 됩니다.

”브라우저가 안전한 난수 생성기(CSPRNG)를 통해 대칭키를 생성합니다.”

내장된 SSL 스택의 기능

공개키 인증서 검증
대칭키 생성
키 교환 및 암호화
세션 암호화

결론

많은 웹들은 HTTPS를 사용되어지면 우리도 모르게 자동으로 SSL Handshake를 통해 보안을 유지하고 있다는 것입니다.
SSL Handshake는 다양한 암호화 알고리즘으로 다를 수 있지만 여기서는 흔히 사용되는 방식으로 설명하였습니다.
더 깊이 있는 인증 과정을 공부하시려면 DH/ECDHE나 Perfect Forward Secrecy(PFS)를 참고하시면 좋을거 같습니다.

[암호화] 대칭키란?

크크크크 — Tue, 19 Aug 2025 23:18:49 +0900

1. 대칭키란?

같은 키로 암호화와 복호화를 수행하는 방식입니다.
속도는 빠르고 구현이 간단하지만,
키가 노출될 경우 모든 통신이 해독 가능하다는 보안상 리스크가 있습니다.

2. 대칭키를 이용하는 방법

단순하게 대칭키만을 사용해서 사용하지 않고 흔히 비대칭키와 혼합해서 사용됩니다.

방식 1: RSA 기반(TLS 1.2 이하)

1. 클라이언트는 서버 인증서를 받고 → 공개키를 추출
2. 브라우저가 임의로 세션키(대칭키)를 생성
3. 이 세션키를 서버의 공개키로 암호화해서 전송
4. 서버는 자신의 비밀키로 복호화 → 세션키 확보
5. 이후 통신은 이 세션키(대칭키)로 암호화 진행

이 방식은 RSA를 사용해 클라이언트가 대칭키를 생성하고 서버의 공개키로 암호화하여 전송하는 구조이며, 서버는 비밀키로 복호화하여 대칭키를 획득합니다.

방식 2: DH/ECDHE 기반(TLS 1.2 ~ 1.3)

요즘은 성능과 보안상의 이유로 Diffie-Hellman 키 교환 방식이 더 많이 사용됩니다.

1. 클라이언트와 서버는 서로 공개키 정보를 교환
2. 서로의 정보를 조합하여 동일한 대칭키를 계산
- 직접 키를 전달하지 않고도, 수학적 방식으로 같은 키를 공유
3. 이후 해당 키를 통해 암호화 통신

이 방식은 키를 직접 전달하지 않고, 공개값과 개인키를 조합해 서로 같은 대칭키를 계산합니다.
이 과정을 통해 중간자 공격(MITM)에 강하고, Perfect Forward Secrecy(PFS)를 보장합니다.
특히 TLS 1.3에서는 RSA 기반 방식이 제거되고, ECDHE 방식만을 사용하도록 명시되어 있습니다.

UUID(Universally Unique Identifier) 버전과 사용법

크크크크 — Sun, 10 Aug 2025 17:53:34 +0900

전 세계적으로 유일한 식별자를 생성하기 위한 표준 형식입니다.
업무에 적용해보자면, “다른 시스템과 충돌 없이 고유한 ID를 만들 수 있는 규격”입니다.

UUID는?

분산환경에 걸쳐 ID 충돌 없이 식별자를 생성하기 위해 나타났습니다. (멀티 스레드, 멀티 프로세스 등등)
특징으로는 126비트(16바이트)의 길이로 표기되며 32개의 16진수와 하이픈(-)의 조합 표현됩니다.

예) 12341234-1234-1234-1234-123412341234
특성상 전역적으로도 고유성을 띔으로 중앙 서버 없이도 가기 시스템이 독립적으로 ID 생성이 가능하게 되었습니다.
대표적으로 DB PK, 분산 시스템 메시지 ID, 세션 토큰, 객체 식별자 등 다양하게 사용됩니다.

UUID 버전이 있는데…

버전별 생성 방식이 다름으로 레거시를 조심합시다.
RFC 4122 표준에서 정의된 대표 버전과 최근 채택된 v6, v7을 다음과 같이 정리했습니다.

버전	생성 방식	특징과 사용 용도
v1	시간(60비트) + MAC 주소(48비트) + 시퀀스	시간 순 정렬 가능, 하드웨어 주소 노출 위험 있음 로그·이벤트 타임라인, 순차 PK
v2	v1 + POSIX UID/GID	거의 사용되지 않음, DCE Security 전용 오래된 DCE 시스템
v3	네임스페이스 + MD5 해시	같은 입력 → 같은 UUID, 재현 가능 URL, 도메인 기반 ID
v4	난수 기반 (122비트 랜덤)	단순, 충돌 확률 매우 낮음 범용 ID, 세션 토큰
v5	네임스페이스 + SHA-1 해시	v3과 동일하지만 SHA-1 사용 URL, 도메인 기반 ID
v6	v1 변형 (시간 필드를 비트 순서 변경해 정렬 친화성↑)	DB 인덱스·정렬 최적화, MAC 주소 포함 가능
v7	Unix Epoch 타임스탬프(밀리초) + 랜덤 비트	가독성·정렬성↑, MAC 주소 사용 안 함, 충돌 방지 로그, 타임라인, PK 생성 (v4 대체 후보)

UUID의 역사에 대해 조사한 내용

1980년대 초반
UUID 개념은 Apollo Computer의 네트워크 OS에서 처음 사용됨. 당시에는 “NCS Identifier”라는 이름.
1988년
DCE(Distributed Computing Environment) 표준에 채택. 이 시기부터 “UUID”라는 용어 사용.
1997년
UUID 규격이 ISO/IEC 11578 표준으로 지정됨. v1 형식(시간+MAC) 기반.
2005년
RFC 4122가 발표되며 현재 우리가 사용하는 UUID 형식(버전 1~5) 정의.
최근
- UUIDv4 (랜덤 기반) 사용이 가장 보편적.
- UUIDv7 같은 시간 기반 + 랜덤 혼합 규격이 IETF에서 논의 중(정렬성 + 난수 안정성 확보 목적).
- 대규모 분산 시스템에서는 ULID, KSUID 등 더 정렬 친화적인 대안도 등장.

많이 사용되는 UUID의 Bit 구성을 보면

노랑 → 시간 정보(타임스탭프 기반)
보라 → 버전 비트(UUID 버전 식별)
파랑 → variant나 Clock Sequence
연두 → MAC 주소나 랜덤 비트

이걸 보면

MSB는 주로 시간, 버전
LSB는 랜덤, MAC
쪽에 위치한다는 걸 직관적으로 확인할 수 있습니다.

그래서 어느 버전을 사용할까?

v1을 보면 시간순으로 정렬 가능하지만, 비트 순서가 DB 인덱스에 친화적이지 않으며 MAC 주소 노출 문제가 있습니다.
V4는 순서성이 전혀 없어 인덱스 성능이 떨어집니다.
v6은 v1의 시간 기반 구조를 재배열하여 정렬성과 성능 최적화를 하였습니다.
v7은 v4 + 시간 순서성을 결합해 MAC 주소 없이 안전하게 정렬 가능합니다.

자바의 UUID는 v4를 사용하고 있습니다. 앱 내부적으로 사용하고 시간과 무관한 값이면 UUID v4를 사용해도 됩니다.
다만, 시간과 정렬 최적화가 필요하다면 UUID v7을 사용하는 것이 바람직하다고 할 수 있습니다.

v6, v7의 시간 기준은 다르다.

v7을 현재 시스템 구조에 맞게 생성된 ID이며 유닉스기반 시간으로 작성하고 로그, 메트릭 등 다양한 시스템 통합에 장점이 있습니다.
v6과의 차이는 시간 기준과 타 시스템 연계가 다릅니다.
v6 시간은 그레고리안 에폭(1582-10-15) 기준이며 최신 시스템과의 시간 연동을 하려면 추가 변환이 필요합니다.
그렇다면 v7은 유닉스 에폭(1970-01-01) 기준입니다. 레거시에 따라 적용하되 신규 시스템은 v7을 권장합니다.

UUID v7에서 값 뽑는 방식

UUID v7는 시간순 정렬 가능하고 랜덤성이 보장됩니다.
랜덤 부분에서 하위 일부 비트만 사용해서 짧은 값 생성도 용이합니다.

UUID를 어떻게 사용해야할까?

대게 실무에서는 UUID를 ID로 저장하는 경우 BINARY(16)로 DB에 저장합니다.
UUID v7 자체적으로 고유성과 시간정렬이 가능하기 때문입니다.
또한, 사람이 보기 좋은 짧은 값으로도 전환하여 저장하기도 합니다.

사용방법 예시

규칙 및 조건

UUID ID 생성하고 저장합니다.
위 기반으로 사람이 읽기 좋은 값으로 0-9, A-Z(36자리)의 조합으로 6자리로 표현한다고 해봅시다.
- 예) yyyyMMdd-ABCDEF
UUID 비트 일부를 잘라서 사용
- UUID의 동시대 기준 많이 변화되는 LSB를 잘라서 인코딩용으로 사용합니다.
- 참고) MSB XOR LSB로 사용하면 추가적으로 랜덤성을 극대화 시킬 수 있습니다.
36^6 = 약 21억 → 하루 수천만 건 이상 주문 처리에도 안전합니다.
6자리 미만이 나올 경우 맨 앞자리에 “0”을 붙여 줍니다.

구현을 해보겠습니다.

불변성으로 값 객체용인 record를 활용했습니다.
UUID v7을 사용하기 위해 외부 라이브러리를 사용했습니다.
- java 내부 기능으로 UUID v4를 사용합니다.
- com.github.f4b6a3:uuid-creator 라이브러리를 추가합니다.

import com.github.f4b6a3.uuid.UuidCreator;  
import java.time.*;  
import java.time.format.DateTimeFormatter;  
import java.util.UUID;    

public record OrderId(  
        UUID uuid  
) {  
    private static final DateTimeFormatter FORMATTER = DateTimeFormatter.BASIC_ISO_DATE;  
    private static final char[] BASE36 = "0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ".toCharArray();  

    public String createNo() {  
        // UUID의 적용된 시간을 가져옵니다.
        long epochMillis = (uuid.getMostSignificantBits() >>> 16) & 0x0000_FFFF_FFFF_FFFFL;  
        String ymd = Instant.ofEpochMilli(epochMillis)
                    .atZone(ZoneId.systemDefault())
                    .toLocalDate()
                    .format(FORMATTER);
        // 랜덤성을 향상 시키기 위해 MSB xor LSB 이후 하위 32bit를 가져옵니다.
        long randomBits = (uuid.getLeastSignificantBits() ^ uuid.getMostSignificantBits()) 
                        & ((1L << 32) - 1);  
        // 최대 자리 수를 맞추기 위해 remainder를 이용하여 값 도출합니다.(랜덤성 데이터라 무관)
        long value = randomBits % (long) Math.pow(36, 6);  
        // 나름? 인코딩된 값을 가져옵니다.
        String enc = toBase(value);
        // 5자리 이하는 맨 앞자리에 "0"을 붙여줍니다.  
        if (enc.length() < 6) enc = "0".repeat(6 - enc.length()) + enc;  
        // yyyyMMdd-ABCDEF 형태로 반환합니다.
        return ymd + "-" + enc;  
    }  

    private String toBase(long value) {  
        if( value == 0 ) return "0";  
        StringBuilder sb = new StringBuilder();  
        long v = value;  
        int length = BASE36.length;  
        while( v > 0) {  
            sb.append(BASE36[(int) (v % length)]);  
            v /= length;  
        }  
        return sb.reverse().toString();  

    }


    public static OrderId of(UUID value) {  
        Assert.notNull(value, "uuid must not be null");  
        return new OrderId(value);  
    }  

    public static OrderId create() {  
        return of(UuidCreator.getTimeOrderedEpoch());  
    }  
}

UUID의 적용된 시간을 가져옵니다.
랜덤성을 향상 시키기 위해 MSB xor LSB 이후 하위 32bit를 가져옵니다.
최대 자리 수를 맞추기 위해 remainder를 이용하여 값 도출합니다.(랜덤성 데이터라 무관)
toBase를 통해 나름? 인코딩된 값을 가져옵니다.
5자리 이하는 맨 앞자리에 "0"을 붙여줍니다.
yyyyMMdd-ABCDEF 형태로 반환합니다.

[알고리즘] DFS(Depth-First Search, 깊이 우선 탐색) 문제 풀이 가이드

크크크크 — Mon, 14 Jul 2025 13:53:31 +0900

개념

DFS(Depth-First Search,깊이 우선 탐색) 는 그래프나 트리와 같은 자료구조에서 탐색을 진행할 떄 사용하는 대표적인 알고리즘입니다.
특정 노드를 시작점으로 잡고 최대한 깊은 경로까지 탐색하다가, 더 이상 탐색할 곳이 없으면 백트래킹을 통해 돌아오며 탐색하지 않은 경로를 다시 탐색합니다.

즉, 깊게 먼저 들어가며 탐색하는 방식입니다.

DFS의 핵심 원리

하나의 노드를 선택해 방문한 후, 인접한 노드를 따라 갈 수 있는 곳까지 깊이 들어갑니다.
더 이상 이동할 곳이 없으면 이전 노드로 돌아와서 다시 탐색을 시작합니다.
방문한 곳을 기록해, 이미 방문한 노드는 재탐색하지 않습니다.

즉, “한쪽 방향 끝까지 먼저 파고든다”라는 생각하면 직관적으로 이해할 수 있습니다.

DFS 탐색 순서 예시

      1 (root node)
    /   \
   2     5
  / \   / \
 3   4 6   7

탐색 순서: 1 → 2 → 3 → 4 → 5 → 6 → 7

DFS의 시간 복잡도

일반적으로 O(N) ~ O(N²) 까지 다양합니다. 다만, 각 문제의 요구조건에 따라 가지치기(pruning) 기법으로 활용하여 탐색 횟수를 크게 줄일 수 있습니다.
즉, 조건에 부합하지 않은 탐색 경로를 미리 차단(return)하여 불필요한 탐색을 방지할 수 있습니다.

Java 코드로 DFS 알고리즘 가이드 보기

// 그래프를 인접리스트로 표현 (예시)
List<Integer>[] graph = new ArrayList[5];
for (int i = 0; i < graph.length; i++) {
    graph[i] = new ArrayList<>();
}
// 간선 연결 예시 (0→1, 0→2, 1→3, 2→4)
graph[0].add(1);
graph[0].add(2);
graph[1].add(3);
graph[2].add(4);

boolean[] visited = new boolean[5];  // 방문 여부 체크

dfs(0, graph, visited, 0);  // 0번 노드에서 DFS 탐색 시작, 초기 깊이는 0

// DFS 재귀 메서드 구현
public void dfs(int node, List<Integer>[] graph, boolean[] visited, int depth) {
    // 특정 조건에 따라 탐색을 중단할 수 있음 (가지치기)
    // 예시: 깊이가 3 이상이면 탐색 중지
    // if (depth >= 3) return;

    visited[node] = true; // 현재 노드를 방문 처리, 다음 깊이를 위해
    System.out.println("방문 노드: " + node + ", 현재 깊이: " + depth);

    // 현재 노드와 연결된 모든 인접 노드를 탐색
    for (int next : graph[node]) {
        if (!visited[next]) { // 방문하지 않은 노드만 탐색
            dfs(next, graph, visited, depth + 1);
        }
    }

    // 다른 경로 탐색을 위한 백트래킹 처리
    visited[node] = false;
}

코드 흐름 간략 정리

현내 노드 방문 처리(visited[node] = true)
현재 노드의 모든 인접 노드 탐색
방문하지 않은 인접 노드가 있다면 재귀적으로 방문
모든 인점 노드를 탐색하면 이전 호출로 되돌아가 계속 탐색(백트래킹)
조건에 따라 가지치기하여 탐색 성능 향상 가능

DFS가 유용한 문제

그래프 탐색 및 경로 탐색 관련 문제
- 길찾기: 특정 노드에서 도달 가능한 모든 노드 찾기
모든 경우의 수를 고려해야하는 완전탐색 및 백트래킹 문제
- 미로 찾기, 조합(Combination), 순열(Permutation) 등
트리 순회 문제
- 전위(Pre-order)
- 정위(Post-order)
- 후위(In-order)
연결 요소(Connected Component) 개수 찾기 문제

요약

DFS는 그래프나 트리처럼 특정 노드부터 최대한 깊이 들어가면서 탐색하는 알고리즘이며 가능한 깊게 탐색을 진행하고, 더 이상 탐색할 수 없을 때 이전으로 되돌아가 탐색하지 않은 노드를 다시 방문하는 방식입니다.

DFS는 탐색 대상의 전체 구조를 파악하거나 완전 탐색할 때 유용합니다.

반면, 최단거리와 같이 최적의 경로를 찾는 문제에서는 일반적으로 BFS가 더 효율적이며, 그래프가 매우 깊고 넖을 때 DFS는 스택 오버플로우가 발생할 가능성이 있습니다.

[알고리즘] 슬라이딩 윈도우 풀이 가이드

크크크크 — Mon, 14 Jul 2025 11:34:12 +0900

개념

창문을 한칸 씩 이동해서 문제가 요구하는 조건을 체크하는 것입니다.
가이드 순서는 아래와 같습니다.

윈도우에 담을 기존 원소(데이터)를 확인합니다.
윈도우의 left, right 포인터를 0부터 시작합니다.
- left는 윈도우의 왼쪽 끝, right는 왼도우의 오른쪽 끝을 나타냅니다.
- 조건에 따라 시작 지점은 변경합니다.
right를 하나씩 증가시키면서 배열을 순회합니다.
- right가 증가할 때마다 기존 데이터를 기반으로 새로운 원소(데이터)를 반영합니다.
윈도우에 추가된 원소를 문제의 조건에 맞춰 처리합니다.
- left ~ right를 순회해서 처리합니다.
- 예 빈도수 계산, 함계 계산, 최댓값/최솟값 업데이트 등
문제의 조건을 벗어나면(right 로직 마지막) 조건을 만족할 때까지 left 포인터를 오른쪽으로 이동시킵니다.
- 이 과정에서 윈도우에서 원소가 갱신됩니다.
- 윈도우의 유효셩을 체크합니다.
매번 윈도우를 업데이트할 때마다 결과를 저장하거나 갱신합니다.

Java 코드로 확인해보자

윈도우 내의 합 문제

int[] arr = {1, 3, 2, 5, 1, 1, 2, 3};
int targetSum = 8;

// 슬라이딩 윈도우의 두 포인터 left, right 선언
int left = 0, windowSum = 0;

// right를 기준으로 배열 전체를 순회
for (int right = 0; right < arr.length; right++) {

    // right가 가리키는 원소를 윈도우에 포함
    windowSum += arr[right];

    // 윈도우 내 합이 조건(targetSum)을 초과하면, 초과하지 않을 때까지 left를 오른쪽으로 이동
    while (windowSum > targetSum) {
        windowSum -= arr[left]; // left 원소를 윈도우에서 제거
        left++;                 // left 포인터 이동
    }

    // 조건을 만족하면 현재 윈도우 범위를 출력
    if (windowSum == targetSum) {
        System.out.println("조건 만족 윈도우: [" + left + ", " + right + "]");
    }
}

코드 흐름을 간단하게 정리하면

right로 원소 추가 → 윈도우 합 증가하고
조건을 만족하지 않으면 left로 원소 제거 → 윈도우 합 감소
조건 만족 시 현재 윈도우 범위 출력

슬라이딩 윈도우가 유용한 문제 유형은?

연속된 구간의 합 또는 특정 조건을 만족하는 부분 배열 찾기
최대 길이 부분 배열, 최소 길이 부분 배열 찾는 문제
문자열 또는 배열에서 중복 제거 후 연속 구간 찾기 문제

요약

두 포인터로 윈도우 범위를 유지하고 right 순회에서 원소 추가하고, left로 조건을 유지하는 것입니다.

단방향 암호화(해시 알고리즘)

크크크크 — Sat, 12 Jul 2025 14:14:06 +0900

단방향은 왜 해싱을 사용할까? 해싱은 복호화가 불가능한 방식이 때문에 사용하는 것입니다.

단방향 해싱의 특징

입력값을 일정한 길이의 공전된 값으로 변환하여 DB컬럼 길이를 일정하게 유지가 가능합니다.
복호화가 불가능하므로 원본으로 돌릴 수 없기에 데이터 탈취해도 무의미 합니다.
항상 같은 입력값은 항상 같은 출력값을 나옵니다. 그래서 이러한 입력에 대한 출력 테이블 있으면 해킹이 될거 같은데라고 생각할 수 있습니다. 그래서 레인보우 테이블이란 데이터 집합으로 보안에 문제가 발생한 적이 있었죠… 이후에는 salt 라는 기법으로 이 방법을 해결합니다.

해시로 저장해야 할까?

비밀번호 등 복호화하지 않아야 할 데이터입니다. 즉, 누가 탈취해도 알 수 없기에 굉장히 안정적입니다. 예로 앱의 패스워드가 해싱을 적용한다면 앱의 관계자는 패스워드 복호화 할 수 없기 때문에 사용자 측면에서 안정성 & 신뢰성이 생깁니다.

사용 가능한 해시 알고리즘

알고리즘	복호화 가능 여부	비밀번호에 적합 여부	비고
MD5	❌ 단방향	❌ 위험 (빠름, 충돌 다발)	X
SHA-256	❌ 단방향	⚠️ 보완 필요 (솔트 없음)	단독 사용 금지
bcrypt	❌ 단방향	✅ 권장	솔트 + 느린 계산 = 안전
scrypt	❌ 단방향	✅ 권장	메모리 의존성 ↑
Argon2	❌ 단방향	✅ 최신 권장	2015년 비밀번호 해시 대회 수상

(참고) Spring Security 에서는?

일반적으로 bcrypt를 사용합니다. 스프링에서는 bcrypt 암호화를 하게 되면 {bcrypt} 라는 접두어로 암호화된 값 앞에 알고리즘 식별용으로 접두어를 적용합니다.

DelegatingPasswordEncoder를 통해 암호흘 생성할 떄만 {암호화 알고리즘} 접두어 추가됩니다.
BCryptPasswordEncoder 직접 사용하면 {암호화 알고리즘}은 붙지 않습니다.

PasswordEncoder encoder = PasswordEncoderFactories.createDelegatingPasswordEncoder();
String encoded = encoder.encode("password");
System.out.println(encoded); // {bcrypt}로 시작하는 문자열 출력

정리

항목	내용
단방향 암호화 = 해싱?	✅ 맞음. 복호화 불가
해시만으로 충분한가?	❌ Salt 필수 (충돌, 무차별 대입 방지)
비밀번호 해싱 추천 알고리즘	✅ bcrypt, ✅ Argon2, ✅ PBKDF2
{bcrypt} 의미	Spring Security의 알고리즘 식별자 prefix
직접 {bcrypt} 붙이나?	❌ 아님. PasswordEncoder가 자동으로 붙임