soo_vely의 개발로그

[AI] Claude Code에 Figma MCP 설정

Kim-SooHyeon — Tue, 7 Apr 2026 16:40:36 +0900

오늘은 최근 AI 개발 생태계의 화두인 MCP(Model Context Protocol)를 활용해,

Figma와 Claude Code를 연동하는 방법을 공유하려 합니다.

디자인 파일을 보며 일일이 CSS 속성을 복사하던 번거로움에서 벗어나,

AI 에이전트가 내 디자인 컨텍스트를 직접 이해하게 만드는 생산성 혁명을 경험해 보세요.

1. Figma MCP란?

MCP(Model Context Protocol)는 AI 모델이 외부 데이터(GitHub, Figma, DB 등)와

직접 상호 작용할 수 있도록 돕는 표준 인터페이스입니다.

Figma MCP 서버를 연결하면 다음과 같은 작업이 가능해집니다.

디자인 컨텍스트 추출: 변수, 컴포넌트, 레이아웃 데이터를 IDE로 직접 가져오기
코드 생성: 선택한 프레임 기반으로 React, Tailwind 등 즉시 코드 변환
실시간 UI 캡처: 웹 앱의 실시간 UI를 캡처하여 Figma 파일로 저장

2. Claude Code에서 설정하기

방법 A: 공식 플러그인 설치

가장 표준적인 방법으로, 에이전트 스킬까지 포함된 설치 방식입니다. 터미널에서 아래 명령어를 실행합니다.

claude plugin install figma@claude-plugins-official

터미널에서 아래 명령어를 입력하여 figma가 정상 설치되었는지 확인합니다.

/mcp

방법 B: 수동 설정 (Manual Setup)

만약 플러그인을 설치했는데도 /mcp 목록에 Figma가 나오지 않는다면, 아래 수동 설정 방식을 추천합니다.

(제가 겪었던 문제와 해결책은 아래 트러블슈팅 섹션에 상세히 적어두었습니다.)

3. 잠깐! 플러그인 설치 후 /mcp 목록에 Figma가 보이지 않는다면?

저도 처음에 권장 방식인 claude plugin install을 시도했지만, /mcp 명령어를 입력했을 때 목록에 Figma가 노출되지 않는 현상이 있었습니다. 이는 클라이언트 버전 문제나 설정 파일 반영 지연 때문일 수 있습니다.

이럴 땐 당황하지 말고 아래 명령어를 통해 수동 설정을 진행해 보세요.

# --scope user 플래그를 통해 모든 프로젝트에서 사용 가능하도록 설정합니다.
claude mcp add --scope user --transport http figma https://mcp.figma.com/mcp

이렇게 직접 서버 주소를 등록하면 Claude Code가 즉시 인식하며,

전역 설정을 통해 어떤 프로젝트 폴더에서도 Figma 디자인 컨텍스트를 불러올 수 있게 됩니다!

4. 인증 및 최종 연결 확인

설정 명령어를 입력했다면 이제 실제 Figma 데이터에 접근할 권한을 부여해야 합니다.

Claude Code를 다시 시작합니다.
/mcp를 입력하고 목록에서 figma를 선택합니다.
인증(Authentication) 메뉴를 선택하면 브라우저가 열립니다.
Figma 로그인을 완료하고 [액세스 허용(Allow access)]을 클릭합니다.
터미널에 Authentication successful. Connected to figma 메시지가 뜨면 성공입니다!

5. 활용 가이드: 무엇을 물어볼까?

연결이 완료되었다면 이제 Claude Code에게 이렇게 요청해 보세요.

"지금 피그마 파일에서 '로그인 버튼' 컴포넌트의 스타일을 React 코드로 짜줘."
"디자인 시스템에 등록된 폰트 크기 변수들을 알려줘."
"선택한 프레임의 레이아웃 구조를 분석해서 HTML/CSS로 변환해 줘."

마치며

백엔드 개발자로서 프론트엔드 협업이나 개인 프로젝트를 진행할 때,

디자인 수치를 일일이 확인하는 게 가장 번거로운 일 중 하나였는데요

Figma MCP를 활용하니 '디자인이 곧 컨텍스트'가 되어 개발 속도가 비약적으로 상승했습니다.

저처럼 플러그인 설치 시 목록 노출이 안 되어 고생하셨던 분들께 이 글이 도움이 되길 바랍니다!

참고 문서: Figma Developers - Remote Server Installation

[AI] Claude - 커스텀 명령어로 커밋 프롬프트 자동화하기

Kim-SooHyeon — Wed, 25 Mar 2026 17:56:25 +0900

안녕하세요! 개발 과정에서 AI 어시스턴트를 활용하다 보면,

매번 비슷하거나 똑같은 프롬프트를 반복해서 입력해야 할 때가 많습니다.

특히 깃(Git) 커밋 메시지를 작성하거나 코드 리뷰를 요청할 때, 매번 긴 규칙을 설명하는 것은 상당히 번거로운 일입니다.

오늘은 이런 번거로움을 한 번에 해결해 줄 '커스텀 슬래시 명령어' 설정 방법에 대해 알아보겠습니다.

한 번만 설정해 두면 업무 효율을 비약적으로 끌어올릴 수 있습니다!

️ 커스텀 슬래시 명령어란?

커스텀 슬래시 명령어는 자주 사용하는 긴 프롬프트를 하나의 짧은 명령어로 단축하여 사용하는 기능입니다.

예를 들어, 길고 복잡한 커밋 생성 프롬프트를 /commit 이라는 짧은 명령어 하나로 호출할 수 있게 해줍니다.

⚙️ 설정 방법

설정 방법은 매우 간단합니다. 사용 중인 프로젝트 폴더 루트 영역에 폴더와 마크다운 파일만 추가해 주시면 됩니다.

1. 명령어 폴더 생성

프로젝트의 루트 디렉토리에 .claude/commands/ 폴더를 생성합니다.

2. 마크다운(`.md`) 파일 추가

해당 폴더 안에 명령어 이름으로 사용할 마크다운 파일을 생성합니다.

폴더 구조 예시

.claude/
└── commands/
    └── commit.md     <-- 이 파일이 /commit 명령어가 됩니다.

활용 예시 : 자동 커밋 및 푸시 명령어 (`commit.md`)

제가 주로 사용하는 커밋 메시지 자동화 프롬프트를 예시로 보여드리겠습니다. 아래 내용을 방금 만든 commit.md 파일에 복사해서 붙여넣어 보세요.

# Commit and Push

1. 변경된 파일들을 확인해줘 
2. 각 기능들을 나누어서 아래 컨벤션에 맞춰 의미 있는 커밋 메시지를 작성해줘 (한국어)
- feat : 새로운 기능 추가, 기존의 기능을 요구 사항에 맞추어 수정
- fix : 기능에 대한 버그 수정
- build : 빌드 관련 수정
- chore : 패키지 매니저 수정, 그 외 기타 수정 ex) .gitignore
- ci : CI 관련 설정 수정
- docs : 문서 수정 (README, 주석, 문서 파일 변경 시)
- style : 코드 스타일, 포맷팅에 대한 수정
- refactor : 기능의 변화가 아닌 코드 리팩터링 ex) 변수 이름 변경
- test : 테스트 코드 추가/수정
- release : 버전 릴리즈
3. 커밋하고 현재 브랜치에 푸시해줘

✨ 어떻게 사용하나요?

이제 설정이 모두 끝났습니다! 채팅창에서 다음과 같이 입력해 보세요.

/commit

AI가 자동으로 commit.md에 작성해둔 컨벤션 규칙을 읽어들이고, 현재 변경된 파일들을 분석하여 알맞은 커밋 메시지를 생성한 뒤 푸시까지 일괄적으로 처리해 줍니다.

마무리하며

이번 글에서는 커밋 메시지를 예시로 들었지만, 여러분의 작업 스타일에 맞춰 얼마든지 다양하게 응용할 수 있습니다.

/review : 사내 코드 리뷰 규칙을 정해두고 검사 목적으로 사용하기
/test : 특정 프레임워크 기반의 유닛 테스트 코드 템플릿 생성하기
/refactor : 회사 컨벤션에 맞춰서 일괄적으로 코드 리팩토링 지시하기

자주 반복되는 타이핑에 지치셨다면,

지금 바로 커스텀 명령어를 도입하셔서 개발 생산성을 한 단계 높여보시길 강력하게 추천합니다!

[AI] oh-my-claude code | Claude Code를 팀 오케스트레이션 플랫폼으로

Kim-SooHyeon — Wed, 18 Mar 2026 18:06:03 +0900

혼자 쓰던 AI 코딩 도구, 이제 19개 전문 에이전트가 협업하는 팀으로 쓴다

들어가며

Claude Code를 사용하다 보면 한 가지 아쉬운 점이 생깁니다.
복잡한 기능을 구현할 때, 코드 작성 → 리뷰 → 테스트 → 보안 검토까지 모든 걸 하나의 프롬프트 흐름에 때려 넣다 보면 컨텍스트가 뒤엉키기 시작하죠.

이 문제를 해결해주는 도구가 있습니다.

oh-my-claudecode(OMC) — Claude Code 위에 올라가는 멀티 에이전트 오케스트레이션 레이어입니다.

이 글에서는 OMC의 개념부터 설치, 핵심 기능까지 백엔드 개발자 관점에서 정리해보겠습니다.

1. oh-my-claudecode란?

oh-my-claudecode(OMC) 는 Anthropic의 Claude Code CLI를 팀 기반 멀티 에이전트 플랫폼으로 확장하는 플러그인 시스템입니다.

"Teams-first Multi-agent orchestration for Claude Code"

한 마디로, 혼자 일하던 Claude를 19개의 전문 에이전트로 구성된 팀으로 업그레이드하는 것입니다.

Claude Code vs oh-my-claudecode

항목	Claude Code	oh-my-claudecode
인터페이스	CLI 명령어 직접 입력	자연어 + 매직 키워드
에이전트	단일 에이전트	19개 전문 에이전트 자동 라우팅
실행 방식	순차적·선형	병렬 팀, 스마트 라우팅
검증 루프	없음	`ralph` 모드로 자동 재시도
멀티 프로바이더	Claude만	Claude + Codex + Gemini 동시 오케스트레이션
비용 최적화	수동 모델 선택	작업 복잡도별 자동 모델 라우팅

2. 핵심 개념

에이전트 카탈로그 (19개)

OMC는 역할이 명확히 분리된 전문 에이전트들을 보유하고 있습니다. 각 에이전트는 작업 복잡도에 따라 적절한 모델(haiku / sonnet / opus)로 자동 라우팅됩니다.

분류	에이전트	역할	모델
계획/설계	`planner`, `architect`, `analyst`	요구사항 분석, 시스템 설계	opus
구현	`executor`	코드 구현 실행	sonnet
검증	`verifier`, `qa-tester`, `test-engineer`	테스트, QA, 검증	sonnet
리뷰	`code-reviewer`, `security-reviewer`, `critic`	코드 리뷰, 보안 평가	opus/sonnet
분석	`debugger`, `tracer`, `explore`, `scientist`	디버깅, 코드 추적, 탐색	sonnet
문서/기타	`writer`, `document-specialist`, `designer`, `git-master`, `code-simplifier`	문서화, UI/UX, Git	haiku/sonnet

스킬(Skill)

스킬은 에이전트들을 조합한 워크플로우 템플릿입니다. / 로 시작하는 슬래시 커맨드로 호출합니다.

주요 스킬:

스킬	설명
`autopilot`	자연어 설명만으로 전체 구현 자율 실행
`ralph`	목표 달성까지 검증 루프를 포함한 지속 실행
`ultrawork`	최대 병렬 처리 모드
`deep-interview`	소크라테스식 요구사항 명확화 후 실행
`omc-plan` / `ralplan`	전략적 플래닝 (반복 합의 포함)
`ccg`	Claude + Codex + Gemini 삼중 병렬 실행 후 합성
`ai-slop-cleaner`	AI가 생성한 코드 슬랍(slop) 정제
`trace`	증거 기반 경쟁 가설 추적 디버깅
`ultraqa`	테스트-검증-수정 반복 QA 사이클

팀 파이프라인

내부적으로 다음 단계 파이프라인으로 동작합니다.

team-plan → team-prd → team-exec → team-verify → team-fix (루프)

검증 실패 시 team-fix가 자동 재실행되며, 최대 시도 횟수에 도달하면 중단합니다.

3. 설치 방법

사전 요구사항

Claude Code CLI 설치 완료
Claude Max/Pro 구독 또는 Anthropic API 키
tmux (brew install tmux / apt install tmux)
(선택) Codex CLI, Gemini CLI — 크로스 모델 오케스트레이션용

설치

방법 1 — Claude Code 플러그인 마켓플레이스 (권장)

/plugin marketplace add https://github.com/Yeachan-Heo/oh-my-claudecode
/plugin install oh-my-claudecode
/omc-setup

방법 2 — npm

npm install -g oh-my-claude-sisyphus@latest

팀 모드 활성화

내부 에이전트 팀 기능을 사용하려면 ~/.claude/settings.json에 다음을 추가합니다.

{
  "env": {
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1"
  }
}

초기 설정

설치 후 다음 명령으로 초기 설정을 진행합니다.

/oh-my-claudecode:omc-setup

4. 실제 사용 예시

기본 팀 실행

# 3개 executor 에이전트가 병렬로 TypeScript 오류 수정
/team 3:executor "TypeScript 컴파일 오류 모두 수정"

# 보안 리뷰 + 코드 리뷰 병렬 실행
/team 2:security-reviewer "전체 API 엔드포인트 OWASP Top 10 기준 보안 검토"

자율 실행 (Autopilot)

autopilot: 도서 대출/반납 REST API 구현, JPA + QueryDSL 사용, 동시성 제어 포함

요구사항이 모호할 때 (Deep Interview)

/deep-interview "검색 기능 개선"
# → OMC가 소크라테스식 질문으로 요구사항을 구체화한 후 실행

검증 루프 (Ralph)

ralph: 전체 테스트 통과할 때까지 대출 서비스 구현 및 수정 반복

크로스 모델 병렬 실행

# Claude + Codex + Gemini가 각자 분석 후 결과 합성
/ccg "이 아키텍처의 확장성 문제점 분석"

# Gemini CLI 워커 팀
omc team 2:gemini "API 응답 시간 병목 분석"

매직 키워드 트리거

명시적 슬래시 커맨드 없이도 키워드만으로 스킬이 자동 트리거됩니다.

ulw fix all errors          # ultrawork 모드 실행
ralplan 이 기능 계획 세워줘  # ralplan 스킬 실행
cancelomc                   # 실행 중인 OMC 작업 즉시 중단
deep-analyze 이 코드 분석해줘 # 심층 분석 모드

5. 백엔드 개발자가 느낀 실용 포인트

모델 비용 자동 최적화

단순한 코드 검색은 haiku, 일반 구현은 sonnet, 아키텍처 설계나 심층 코드 리뷰는 opus로 자동 라우팅됩니다. 직접 모델을 골라가며 쓰는 것보다 비용이 체감상 30~50% 절감됩니다.

컨텍스트 오염 방지

기존에는 하나의 대화에서 설계 → 구현 → 리뷰를 모두 하다 보면 초반 컨텍스트가 흐려지는 문제가 있었습니다. OMC는 각 단계를 전문 에이전트로 분리해서 실행하므로 이 문제가 해결됩니다.

IDOR, SQL Injection 등 보안 리뷰 자동화

/team 2:security-reviewer "전체 Controller 레이어 IDOR 취약점 점검"

매 PR마다 수동으로 하던 보안 체크를 팀 에이전트에 위임할 수 있습니다.

설계서-코드 정합성 검토

/team 2:critic "api_spec.md와 실제 Controller 코드 간 불일치 항목 모두 찾아라"

문서와 코드가 따로 노는 문제를 빠르게 잡아낼 수 있습니다.

6. 주의사항

tmux 필수: CLI 워커 팀(omc team) 기능은 tmux 없이 동작하지 않습니다.
API 비용 증가 가능성: 팀 모드는 여러 에이전트가 동시에 실행되므로 단일 실행 대비 토큰 소모가 많습니다. haiku 모델을 최대한 활용하는 방향으로 조정하세요.
Windows: psmux 사용 시 WSL 없이도 동작하나, 완전한 호환성은 macOS/Linux 환경을 권장합니다.
검증 루프 무한 방지: ralph 모드 사용 시 최대 재시도 횟수를 설정해두지 않으면 의도치 않게 많은 비용이 소모될 수 있습니다.

마치며

oh-my-claudecode는 "AI 코딩 어시스턴트"를 "AI 개발팀"으로 격상시키는 도구입니다.
특히 복잡한 도메인 로직 구현, 멀티 레이어 보안 검토, 문서-코드 정합성 관리처럼 단일 프롬프트로 처리하기 어려운 작업에서 진가를 발휘합니다.

Claude Code를 이미 사용하고 있다면 설치 비용이 거의 없으니 한 번 시도해보시길 권장합니다.

참고

GitHub: https://github.com/Yeachan-Heo/oh-my-claudecode
Claude Code 공식 문서: https://docs.anthropic.com/claude-code

[AI] Claude Code CLI 설치 가이드

Kim-SooHyeon — Tue, 17 Mar 2026 11:27:26 +0900

Claude Code CLI 설치 및 실행 방법

최근 개발 생산성을 높이기 위해 Claude Code CLI를 사용하는 분들이 많아지고 있습니다.
이번 글에서는 Windows와 Mac 환경에서 Claude Code를 설치하고, 초기 설정까지 진행하는 방법을 정리해보겠습니다.

1️⃣ Claude Code 설치

먼저 터미널(또는 명령 프롬프트)을 실행한 뒤 아래 명령어를 입력합니다.

✔ Windows

npm install -g @anthropic-ai/claude-code

✔ Mac

sudo npm install -g @anthropic-ai/claude-code

2️⃣ 초기 실행 및 색상 선택

설치가 완료되면 아래 명령어로 실행할 수 있습니다.

claude

먼저 인터페이스 스타일(색상 등)을 선택하는 화면이 나타납니다.

저는 기본값(1번)을 선택하였습니다.

3️⃣ 로그인 방식 선택

다음으로 로그인 방식을 선택하는 화면이 나타납니다.

1번: 계정 로그인 (권장)
2번: 사용량 기반 과금 방식

일반적으로는 1번(계정 로그인)을 선택하시는 것을 권장드립니다.

실제로 사용해보면 과금 방식은 사용량에 따라 비용이 발생하며,

간단한 코드 생성만으로도 비용이 빠르게 누적될 수 있습니다.

4️⃣ 브라우저 인증 진행

로그인 방식을 선택하면 웹 브라우저가 자동으로 열립니다.

화면에 표시되는 승인 버튼을 클릭해 주세요.

이 과정을 통해 CLI와 계정이 연결됩니다.

5️⃣ 설치 완료 및 초기 안내

설치가 정상적으로 완료되었다는 메시지가 표시됩니다.

터미널로 돌아와서 안내에 따라 Enter 키를 눌러 진행합니다.

이후 간단한 사용 가이드가 출력됩니다. Enter 키를 눌러 진행합니다.

6️⃣ 폴더 신뢰 여부 확인

Claude Code는 실행 시 현재 디렉토리를 기준으로 동작하기 때문에
폴더를 신뢰하는지 묻는 메시지가 표시됩니다.

일반적인 개발 환경이라면 Enter를 눌러 진행하시면 됩니다.

※ 해당 메시지는 실행할 때마다 표시될 수 있습니다.

7️⃣ 실행 확인 및 종료 방법

아래와 같이 CLI 화면이 정상적으로 표시된다면
이제 Claude Code를 사용할 준비가 완료된 것입니다.

테스트 후 종료하려면 아래 명령어를 입력합니다.

/exit

✅ 마무리

지금까지 Claude Code CLI 설치부터 실행까지 간단히 정리해보았습니다.

[Back end / 보안] 데이터 암호화의 이해: 대칭키, 비대칭키부터 SHA-256 해시까지

Kim-SooHyeon — Thu, 26 Feb 2026 16:59:26 +0900

비밀번호 보안은 현대 웹 개발에서 가장 중요한 주제 중 하나입니다

많은 개발자들이 "어떻게 비밀번호를 암호화할까?"라는 질문부터 시작하지만,

정답은 "암호화가 아니라 해싱"입니다.

오늘은 암호화의 세 가지 기법을 이해하고, 왜 비밀번호에는 해싱을 사용하는지,

그리고 비밀번호 분실 시 올바른 처리 로직이 무엇인지 알아보겠습니다.

1. 암호화 알고리즘의 분류

암호화 기술은 목적과 방식에 따라 크게 대칭키(Symmetric), 비대칭키(Asymmetric), 그리고 해시(Hash) 세 가지로 나뉩니다.

대칭키 암호화 (Symmetric Key Encryption)

암호화할 때와 복호화할 때 동일한 키를 사용하는 방식입니다.

장점
- 속도가 매우 빠릅니다.
- 처리 효율이 좋아 대용량 데이터 암호화에 적합합니다.
단점
- 키를 상대방에게 전달하는 과정에서 유출될 위험이 있습니다.
- N명이 통신할 때 N×(N-1)/2개의 키를 관리해야 합니다. (키 관리 부담)
- 한 사람의 키가 노출되면 모든 통신이 위험해집니다.
예시: AES, DES
활용 사례 : 파일 암호화, 데이터베이스 저장 데이터 보호

비대칭키 암호화 (Asymmetric Key Encryption)

공개키와 개인키라는 서로 다른 두 개의 키를 사용하는 방식입니다.

공개키: 누구나 접근 가능 (암호화용)
개인키: 본인만 보유 (복호화용)

장점
- 키 전달의 보안성이 높습니다. (공개키만 전송)
- 전자서명 등 다양한 용도로 활용 가능합니다.
단점
- 연산 속도가 대칭키에 비해 상대적으로 느립니다.
- 대용량 데이터 암호화에는 부적합합니다.
예시: RSA, ECC (Elliptic Curve Cryptography)
활용 사례 : HTTPS 통신, 전자서명, API 인증 토큰

2. 왜 비밀번호에는 해싱을 사용할까?

왜 비밀번호는 위 두 방식이 아닌 해시를 사용할까요?

정답은 "복호화가 불가능해야 하기 때문"입니다.

해시 알고리즘의 특징

단방향성 (One-way function)

평문 → SHA-256 → 해시값
해시값 → ??? → 평문 (불가능!)

비밀번호를 해시하면 원문을 알아낼 수 없습니다. 이것이 비밀번호 저장의 기본 원칙입니다.

"관리자도 사용자의 비밀번호를 모른다"는 것이 보안의 핵심입니다.

무결성 확인 (Integrity Verification)

입력값이 조금만 달라져도 결과값이 완전히 변합니다.

SHA-256("password") = 5e884898da28047151d0e56f8dc6292773603d0d6aabbdd62a11ef721d1542d8
SHA-256("passw0rd") = e38ad2143029da323b6b0c8f5f5a90b5f5c1b5f0d7d7e7f5f5f5f5f5f5f5f5f

이 특성 덕분에 데이터 변조를 즉시 감지할 수 있습니다.

3. 실무 구현 사례: SHA-256

실제 프로젝트에서 비밀번호를 암호화하는 로직을 살펴보겠습니다.

️ SHA-256 알고리즘

SHA-256은 "Secure Hash Algorithm 256-bit"의 약자로

어떤 길이의 문자열을 입력해도 256비트(32바이트)의 고정된 길이의 해시값을 만들어냅니다.

보안의 핵심: 솔트(Salt)

동일한 비밀번호(예: 1234)는 동일한 해시값을 가집니다.

user1 password: "1234" → SHA-256 → abc123...
user2 password: "1234" → SHA-256 → abc123...

수백만 명의 사용자가 있는 서비스라면, 같은 비밀번호를 사용하는 사람들이 있을 가능성이 높습니다.

해커들은 이 점을 이용해 해시값들을 미리 계산해둔 레인보우 테이블(Rainbow Table)로 공격합니다.

레인보우 테이블 (Rainbow Table)
해커들은 미리 수백만 개의 단어와 그 SHA-256 해시값을 계산해 테이블로 만들어둡니다.

이를 방지하기 위해 원문에 솔트(Salt)라는 임의의 문자열을 추가하여 같은 비밀번호이지만 다른 해시값이 생성되도록 보장합니다.

user1:
  password: "1234"
  salt: "x7k2p9"
  hash = SHA-256("1234" + "x7k2p9") = def456...

user2:
  password: "1234" (같은 비밀번호!)
  salt: "m3j1w8" (다른 솔트)
  hash = SHA-256("1234" + "m3j1w8") = uvw789...

최종 데이터 저장: Base64 인코딩

해싱된 결과물은 바이너리(바이트) 데이터입니다.

바이트 데이터: [0xFF, 0xA3, 0x2E, 0x91, ...]

이를 텍스트 기반 데이터베이스에 저장하려면 Base64로 인코딩합니다.

Base64: "fw+jLpE..."

4. 비밀번호를 분실했다면? "찾기"가 아닌 "재설정"

해시 알고리즘을 적용하면 관리자도 원문 비밀번호를 알 수 없습니다.

이는 보안의 장점이면서 동시에 "비밀번호 찾기 기능"을 기술적으로 불가능하게 만듭니다.

따라서 현대 보안 가이드라인은 '비밀번호 찾기' 대신 '비밀번호 재설정'을 권고합니다.

처리 프로세스

본인 인증: 이메일이나 SMS로 본인 확인을 진행합니다.
보안 토큰 생성: 일회성 재설정 링크(Token 포함)를 사용자에게 발송합니다.
새 비밀번호 입력: 사용자가 새 비번을 입력하면, 서버는 이를 다시 SHA-256 + Salt 조합으로 해싱하여 DB를 업데이트합니다.

요약 및 결론

비밀번호는 단순히 암호화하는 것을 넘어, "복호화가 필요 없는 구조"로 설계하는 것이 가장 안전합니다.

사용자가 비밀번호를 잊어버렸을 때 기존 값을 알려주는 서비스가 있다면, 그 서비스의 보안을 의심해 보세요!

[Java] JVM Garbage Collection 구조와 Promotion(승격) 조건

Kim-SooHyeon — Wed, 25 Feb 2026 10:57:01 +0900

1. JVM Garbage Collection(GC)이란?

Garbage Collection(GC)은 자바의 메모리 관리 기법 중 하나로, 힙(Heap) 영역에서 더 이상 참조되지 않는 객체들을 찾아 메모리에서 해제하는 과정을 의미합니다. C나 C++ 과 달리 개발자가 직접 메모리를 해제할 필요가 없으며, JVM이 자동으로 관리해줍니다.

GC의 장점

메모리 누수 방지: 프로그래머의 실수로 인한 메모리 누수를 자동으로 방지
개발 생산성 향상: 메모리 관리에 신경 쓰지 않고 비즈니스 로직에만 집중
안정성 보장: 메모리 부족으로 인한 프로그램 정지 위험을 감소

GC의 단점

GC 중단시간(Stop-The-World): GC 실행 중 모든 애플리케이션 스레드가 중단
성능 저하: GC로 인한 CPU 사용률 증가
예측 불가능성: GC 발생 시점을 미리 예측하기 어려움

2. JVM 힙 메모리 구조

JVM의 힙 영역은 객체의 생존 기간에 따라 크게 Young Generation과 Old Generation으로 나뉩니다.

┌─────────────────────────────────────────────────┐
│              JVM Heap 메모리                    │
├─────────────────────────────────────────────────┤
│                                                 │
│  ┌──────────────────────┐  ┌───────────────┐    │
│  │   Young Generation   │  │ Old           │    │
│  │   (Young Gen)        │  │ Generation    │    │
│  │                      │  │ (Old Gen)     │    │
│  │ ┌────────┐ ┌────────┐│  │               │    │
│  │ │ Eden   │ │Survivor││  │               │    │
│  │ │Space   │ │Spaces  ││  │               │    │
│  │ │        │ │S0 / S1 ││  │               │    │
│  │ └────────┘ └────────┘│  │               │    │
│  └──────────────────────┘  └───────────────┘    │
│                                                 │
└─────────────────────────────────────────────────┘

Young Generation (Young Gen)

새로 생성된 객체들이 할당되는 영역
전체 힙의 약 10-30% 차지
대부분의 객체가 이 영역에서 사라짐
세 개의 하위 영역으로 구성:
- Eden Space: 새로운 객체가 생성되는 공간
- Survivor Space 0 (S0): 첫 번째 생존자 영역
- Survivor Space 1 (S1): 두 번째 생존자 영역

Old Generation (Old Gen)

Young Gen에서 오래 생존한 객체들이 이동하는 영역
전체 힙의 약 60-90% 차지
GC가 덜 빈번하게 실행됨

3. Minor GC vs Major GC

GC는 발생하는 영역에 따라 크게 두 가지로 구분됩니다.

Minor GC

발생 지점: Young Generation
특징:
- 객체가 처음 생성되는 Eden 영역이 꽉 차면 발생합니다.
- 상대적으로 속도가 매우 빠릅니다.
- 살아남은 객체는 Survivor 영역으로 이동하며, 이 과정을 반복하며 생존 기간을 기록합니다.

Major GC (Full GC)

발생 지점: Old Generation
특징:
- Old 영역의 메모리가 부족해지면 발생합니다.
- Minor GC보다 훨씬 오래 걸립니다.
- Stop-the-world 현상이 발생하여, GC를 실행하는 스레드를 제외한 모든 애플리케이션 스레드가 중단됩니다.

4. Minor 영역에서 Major 영역으로의 승격(Promotion)

객체가 Young Generation에서 Old Generation으로 옮겨가는 과정을 Promotion(승격)이라고 부릅니다. 이 과정은 어떻게 결정될까요?

Age bit의 누적: Young 영역의 Survivor 공간에서 객체가 살아남을 때마다 객체 헤더의 age 값이 1씩 증가합니다.
- 새로운 객체 생성:
  ├─ Eden Space (Age: 0)
- 1차 Minor GC 후:
  ├─ Survivor S0 (Age: 1) ← 살아남은 객체
- 2차 Minor GC 후:
  ├─ Survivor S1 (Age: 2) ← S0에서 생존한 객체
- 3차 Minor GC 후:
  ├─ Survivor S0 (Age: 3) ← S1에서 생존한 객체
  
  ...
- Age >= Threshold (보통 15)에서:
  ├─ Old Generation ← 승격!
MaxTenuringThreshold: JVM은 이 age 값이 특정 기준(Threshold)에 도달하면 해당 객체가 "오래 살아남을 객체"라고 판단합니다.
이동: 기준치를 넘긴 객체는 비로소 Old Generation으로 복사(Promotion)됩니다.

참고: 너무 큰 객체가 생성되어 Eden 영역에 담기지 않을 경우, 바로 Old 영역으로 할당되기도 합니다.

5. 결론

GC가 자동으로 메모리를 관리해 주지만, Major GC가 빈번하게 발생하거나 길어지면 서비스 응답 속도가 떨어지는 성능 저하를 초래합니다. 따라서 적절한 힙 크기 설정과 서비스 특성에 맞는 GC 알고리즘(G1, ZGC 등) 선택이 중요합니다.

[Kafka] 카프카(kafka)란? (feat. 메세지 큐)

Kim-SooHyeon — Sat, 21 Feb 2026 15:49:28 +0900

✅ 카프카(kafka)란?

Apache Kafka는 수천 개의 회사에서 고성능 데이터 파이프라인, 스트리밍 분석, 데이터 통합 및 미션 크리티컬 애플리케이션에 사용되는 오픈 소스 분산 이벤트 스트리밍 플랫폼입니다.
- Apache Kafka 공식 홈페이지 -

즉, Kafka는 대규모 데이터를 처리할 수 있는 메시지 큐이다.

✅ 메시지 큐(Message Queue)란?

메시지 큐(Message Queue)는 큐(Queue) 형태에 데이터를 일시적으로 저장하는 임시 저장소를 의미한다.

메시지 큐를 활용하면 비동기적으로 데이터를 처리할 수 있어서 효율적이다.

✅ REST API 방식으로 통신 vs 메시지 큐를 활용한 통신

‘REST API 방식으로 통신하는 방식’과 ‘메시지 큐를 활용한 통신 방식’를 이메일 발송 시나리오를 예시로 비교해보자.

REST API 방식은 요청을 보낸 뒤에 모든 작업이 다 처리될 때까지 기다렸다가 응답을 받는 식으로 통신을 한다.

하지만 메시지 큐를 활용한 통신 방식은 비동기적으로 작업을 처리하기 때문에 모든 작업이 다 처리되는 것과 상관없이 응답을 받을 수 있다.

사용자가 REST API 방식으로 요청을 보낸다.
요청을 받은 서버는 메시지 큐(Message Queue)에 전달할 메시지를 만들어 전달한다.
- 메시지 안에는 처리해야 할 요청에 대한 정보들이 담겨있다.
- 메시지 큐(Message Queue)는 처리해야 할 메시지들을 보관하는 임시 저장소 역할을 한다.
- 메시지를 만들어 메시지 큐로 전달하는 서버를 보고 프로듀서(Producer)라고 얘기한다.
  - ‘메시지를 생산하는 주체’를 직관적으로 표현하기 위해 프로듀서(Producer)라는 용어가 만들어졌다.
Producer 서버는 메시지 큐에 메시지를 넣자마자 사용자에게 성공 응답을 한다.
- 이메일 작업이 끝날 때까지 기다렸다가 응답을 하는 것이 아니라, 메시지 큐에 메시지를 넣자마자 응답을 했다. 이렇게 처리하는 방식을 보고 ‘비동기 방식으로 처리했다’라고 표현한다.
- 비동기 방식으로 처리하기 때문에 요청을 효율적으로 처리할 수 있다. 이 때문에 대규모 트래픽을 처리할 때도 유리한 구조이다.
메시지 큐는 Producer로부터 받은 메시지(요청)를 보관하고 있다.
Consumer 서버가 메시지 큐에 들어있는 메시지(요청)를 꺼내서 실제 작업(ex. 이메일 발송 로직 처리)을 수행한다.
- 메시지를 꺼내서 처리하는 서버를 보고 컨슈머(Consumer)라고 얘기한다.
  - 메시지를 소비하는 주체’를 직관적으로 표현하기 위해 컨슈머(Consumer)라는 용어가 만들어졌다.
    cf.Consume: 소비하다

[Java] JDBC의 Statement와 PreparedStatement

Kim-SooHyeon — Thu, 22 Jan 2026 11:30:44 +0900

데이터베이스와 통신하는 Java 애플리케이션을 개발할 때, JDBC를 통해 SQL을 실행하게 됩니다. 이때 Statement와 PreparedStatement 중 어떤 것을 사용하느냐에 따라 애플리케이션의 성능과 보안이 크게 달라집니다.

Statement: 유연하지만 위험한 방식

Statement는 가장 기본적인 SQL 실행 방식입니다. 쿼리를 작성할 때 문자열 연결(String concatenation)을 통해 동적으로 SQL을 구성합니다.

String userId = "user123";
String sql = "SELECT * FROM users WHERE id = '" + userId + "'";
Statement stmt = connection.createStatement();
ResultSet rs = stmt.executeQuery(sql);

간단해 보이지만, 이 방식은 사용자 입력이 직접 쿼리 문자열에 포함되기 때문에 SQL 인젝션 공격에 매우 취약합니다.

만약 userId 변수에 ' OR '1'='1 같은 악의적인 입력이 들어온다면, 쿼리의 의도가 완전히 변조될 수 있습니다.

PreparedStatement: 안전하고 효율적인 방식

PreparedStatement는 이러한 문제를 해결하기 위해 설계된 방식입니다. 쿼리의 구조를 먼저 고정시키고, 나중에 실제 값들을 바인딩합니다.

String userId = "user123";
String sql = "SELECT * FROM users WHERE id = ?";
PreparedStatement pstmt = connection.prepareStatement(sql);
pstmt.setString(1, userId);
ResultSet rs = pstmt.executeQuery();

물음표(?)는 플레이스홀더(placeholder) 역할을 하며, setString() 같은 메서드로 실제 값을 나중에 바인딩합니다.

두 가지 핵심 차이점

1. SQL 인젝션 방지

PreparedStatement는 쿼리 구조가 이미 확정된 상태이기 때문에, 바인딩되는 데이터는 오직 파라미터로만 취급됩니다. 아무리 악의적인 입력이 들어와도 쿼리의 논리 구조를 변경할 수 없습니다. 반면 Statement는 문자열 연결 방식이므로 사용자 입력이 쿼리 구조 자체를 변경할 여지가 있습니다.

2. 데이터베이스 캐싱을 통한 성능 향상

데이터베이스는 SQL을 실행하기 전에 파싱과 실행 계획 수립이라는 비용이 큰 과정을 거칩니다.

이러한 작업의 결과는 캐시(cache)에 저장되어 재활용됩니다.

Statement를 사용하면 파라미터값이 달라질 때마다 전체 쿼리 문자열이 다르게 구성되므로, 매번 파싱과 계획 수립을 새로 진행해야 합니다.

SELECT name FROM tbl WHERE id = 1  -- 서로 다른 SQL로 인식될 가능성
SELECT name FROM tbl WHERE id = 2

반면 PreparedStatement는 SQL 구조가 고정되어 있기 때문에,
데이터베이스나 JDBC 드라이버, 커넥션 풀 설정에 따라
이러한 파싱 결과나 실행 계획을 재활용할 수 있는 여지가 생깁니다.

SELECT name FROM tbl WHERE id = ?  -- 파싱 후 캐싱
SELECT name FROM tbl WHERE id = ?  -- 동일한 SQL 구조로 재사용 가능

특히 같은 쿼리를 여러 번 실행하는 경우, PreparedStatement는 훨씬 빠른 응답 속도를 제공합니다.

연결 풀(Connection Pool)과의 관계

Connection Pool 환경에서는 커넥션이 반복 재사용되므로, PreparedStatement 캐싱을 지원하는 커넥션 풀(HikariCP 등)을 사용할 경우 동일한 SQL에 대한 PreparedStatement를 재사용할 수 있어 성능 이점을 더욱 극대화할 수 있습니다.

결론

PreparedStatement가 표준인 이유

현대의 자바 개발에서는 거의 항상 PreparedStatement를 사용해야 합니다. 보안과 성능 양쪽 측면에서 Statement보다 우수하기 때문입니다. 특히 반복적인 쿼리 실행이 이루어지는 환경에서는 그 차이가 더욱 두드러집니다.

Statement는 단순한 학습 목적이나 특수한 상황을 제외하고는 실제 프로덕션 코드에서 사용하지 않는 것이 좋습니다.

스프링 환경에서의 활용

참고로 스프링 환경에서는 JdbcTemplate, MyBatis, JPA 같은 추상화 계층을 사용하기 때문에, 개발자가 Statement나 PreparedStatement를 직접 다룰 일은 거의 없습니다.

그러나 이들 내부 구현은 대부분 PreparedStatement를 기반으로 동작합니다. 따라서 두 방식의 차이를 이해하는 것은 성능 튜닝이나 문제 분석에 큰 도움이 됩니다.

[Oracle] 테이블 통계정보 손실로 인한 배치 성능 저하 문제 해결 사례

Kim-SooHyeon — Tue, 20 Jan 2026 19:17:21 +0900

개요

대규모 데이터를 다루는 시스템에서 데이터베이스 최적화는 성능 유지의 핵심입니다.

최근 백업 시간 단축을 위해 데이터를 정제하는 과정에서,

역설적으로 배치 작업 성능이 급격히 저하되는 이슈를 겪었습니다.

이번 포스팅에서는 테이블 통계정보의 불일치가 시스템에 어떤 영향을 주는지, 그리고 이를 어떻게 해결했는지 공유합니다.

문제 상황: "백업을 최적화했더니 배치가 느려졌다?"

1. 시스템 배경

저희 시스템은 다음과 같은 데이터 처리 파이프라인으로 구성되어 있습니다.

Source: MSSQL (실시간 CRM 데이터)
Data Warehouse: Oracle 데이터베이스에 매일 정해진 시간에 스냅샷 적재
ETL: MSSQL → Oracle (스키마 및 형변환 적재)
배치 처리: 변환된 데이터를 기반으로 다단계 집계 프로세스를 통한 통계 데이터 생성
데이터 백업: 데이터 무결성을 위한 정기 Full Backup

2. 발생한 문제

시스템 운영이 4년을 경과하면서 데이터 규모가 급증했고, Full Backup에 10시간이 소요되면서 일일 배치 작업과 충돌하기 시작했습니다. 이를 해결하기 위해 다음 조치를 취했습니다.

미사용 임시/테스트 테이블 삭제
중간 처리 테이블의 데이터 정제 (배치 완료 후 TRUNCATE 처리)

백업 시간은 단축되었으나, 다음 날부터 평소 1시간이면 끝나던 배치 작업이 5시간 이상 소요되는 심각한 지연 현상이 발생했습니다.

근본 원인: 통계정보와 옵티마이저의 엇갈림

통계정보의 역할

Oracle 옵티마이저는 테이블의 행 개수, 데이터 분포도 등 통계정보를 바탕으로 최적의 실행 경로를 결정합니다.

문제의 발생

중간 처리 테이블을 배치 완료 후 TRUNCATE 하도록 변경했으나, 작업 순서와 Oracle의 자동 통계 수집 스케줄이 엇갈리면서 치명적인 문제가 발생했습니다.

시각	작업 내용	상태 및 문제점
15:00	Table TRUNCATE	데이터 정제 완료. 테이블은 비어 있고 통계는 '낡은 상태(Stale)'가 됨
22:00	자동 통계 수집	⚠️ [함정] Oracle이 0건인 상태를 기준으로 통계를 확정함
06:00	Data INSERT	대량(약 1억 건)의 데이터가 적재됨. 그러나 통계는 여전히 0건으로 기록됨
07:00	배치(SELECT) 실행	❌ [이슈] 옵티마이저는 데이터가 0건인 줄 알고 최악의 경로를 선택함

이로 인해 옵티마이저가 비효율적인 실행 계획을 수립하여 배치 성능이 급격히 저하된 것입니다.

현재 시스템 설정 확인

1. 자동 통계 수집 윈도우 설정

저희 시스템은 평일 밤은 짧게, 주말은 길게 통계를 수집하도록 설정되어 있습니다.

WINDOW_NAME	시작 시간	유지 시간 (DURATION)	상세 설명
평일(월~금)	밤 22:00	4시간	밤 10시 시작 ~ 새벽 2시 종료 (시간 제약 있음)
주말(토~일)	오전 06:00	20시간	아침 6시 시작 ~ 다음날 새벽 종료 (넉넉함)

2. 설정 확인용 쿼리

요일별 수집 시간대 및 유지 시간 확인

-- 자동 수집 작업이 활성화(ENABLED)되어 있는지 확인
SELECT CLIENT_NAME, STATUS
FROM DBA_AUTOTASK_CLIENT
WHERE CLIENT_NAME = 'auto optimizer stats collection';

-- 요일별 수집 시간대(Window) 확인
SELECT WINDOW_NAME, REPEAT_INTERVAL, DURATION
FROM DBA_SCHEDULER_WINDOWS;

특정 테이블의 마지막 통계 수집 시점 확인

SELECT OWNER, TABLE_NAME, NUM_ROWS, LAST_ANALYZED 
FROM DBA_TABLES 
WHERE TABLE_NAME = 'TARGET_TABLE_NAME';

해결 방법

수동 통계정보 갱신

정확한 실행 계획 유도를 위해 DBMS_STATS 패키지를 사용하여 통계정보를 수동으로 재계산했습니다.

BEGIN
    DBMS_STATS.GATHER_TABLE_STATS(
        ownname          => '[SCHEMA_NAME]',
        tabname          => '[TABLE_NAME]',
        estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,
        method_opt       => 'FOR ALL COLUMNS SIZE AUTO',
        cascade          => TRUE,   -- 인덱스 통계까지 함께 수집
        no_invalidate    => FALSE   -- 기존 커서 무효화 (즉시 반영)
    );
END;

주요 파라미터 설명

ownname: 스키마 이름
tabname: 대상 테이블 이름
estimate_percent: 통계 추정 방식 (AUTO_SAMPLE_SIZE는 Oracle이 자동 결정)
method_opt: 컬럼별 히스토그램 생성 방식 (AUTO는 필요한 컬럼만 자동 선택)
cascade: TRUE 설정 시 테이블의 인덱스 통계도 함께 수집하여 옵티마이저의 정확성 향상
no_invalidate: FALSE 설정 시 기존 커서를 무효화하여 새로운 통계정보가 즉시 반영됨

통계정보 갱신 결과, 배치 작업이 정상 속도로 복귀했습니다.

통계정보 상태 점검 쿼리

이후 통계정보 상태를 모니터링하기 위해 다음 쿼리를 작성했습니다.

SELECT 
    owner AS "스키마명", 
    table_name AS "테이블명", 
    num_rows AS "행(Row)개수", 
    last_analyzed AS "마지막통계수집일시"
FROM 
    all_tables
WHERE 
    owner NOT IN ('SYS', 'SYSTEM')
ORDER BY 
    owner, num_rows DESC;

이 쿼리를 통해

각 테이블의 현재 데이터 건수 파악
통계정보가 언제 마지막으로 갱신되었는지 확인
오래된 통계정보를 가진 테이블 식별

장기적 개선 전략

1. 백업 최적화 방안

현재 10시간에 소요되는 Full Backup 시간을 단축하기 위해 다음과 같은 개선안을 검토하고 있습니다.

단기 개선사항

미사용 테이블/인덱스 정리 (진행 완료)
데이터 적재 후 통계정보 자동 갱신: 배치 프로세스의 데이터 적재 완료 단계에서 명시적으로 DBMS_STATS.GATHER_TABLE_STATS()를 호출하여 옵티마이저가 항상 최신 통계정보로 실행 계획을 수립하도록 개선 예정

장기 개선사항

테이블 파티셔닝: 대용량 테이블을 연도별로 파티셔닝하여 백업 대상 축소 및 선택적 백업 지원 검토

결론

이번 사건을 통해 "데이터 적재만큼 메타정보 관리도 중요하다"는 교훈을 얻었습니다.

✅ 쿼리 성능이 갑자기 저하된다면, 가장 먼저 last_analyzed 날짜를 확인하세요.

✅ TRUNCATE 등 대량 데이터 작업 이후에는 반드시 통계정보를 갱신해야 합니다.

백업 최적화와 성능 안정화를 동시에 달성하기 위해, 위의 개선사항들을 단계별로 추진해 나갈 계획입니다.

AtomicInteger는 어떻게 동시성을 보장할까? - CAS 알고리즘 깊이 파헤치기

Kim-SooHyeon — Wed, 14 Jan 2026 18:57:43 +0900

들어가며

이런 질문을 받았습니다.

"일반 int에 synchronized를 걸지 않고 100개 스레드가 각각 +1을 하면 결과가 100이 안 나올 수 있습니다. 하지만 AtomicInteger.addAndGet()을 사용하면 락 없이도 정확히 100이 보장됩니다. 어떻게 이게 가능한가요?

당시에는 제대로 답변하지 못했지만, 이후 학습을 통해 그 원리를 정리해보았습니다.

문제 상황: Race Condition

먼저 문제를 명확히 해봅시다.

// 문제가 되는 코드
private int counter = 0;

// 100개의 스레드가 동시에 실행
public void increment() {
    counter++; // 이 한 줄이 사실은 3개의 작업!
}

counter++는 원자적(atomic) 연산이 아닙니다. 실제로는:

READ: 메모리에서 counter 값을 읽음
MODIFY: 값을 1 증가
WRITE: 증가된 값을 메모리에 씀

두 스레드가 동시에 실행되면:

Thread A: READ(0) -> MODIFY(1) -> WRITE(1)
Thread B: READ(0) -> MODIFY(1) -> WRITE(1)
결과: 2가 아니라 1!

기존 해결책: synchronized와 Lock

synchronized 방식

private int counter = 0;

public synchronized void increment() {
    counter++;
}

장점: 안전하고 간단합니다.

단점: 성능 오버헤드가 큽니다.

스레드가 락을 획득하지 못하면 블로킹됨
컨텍스트 스위칭 비용 발생
경쟁이 심할수록 성능 저하

AtomicInteger의 마법: CAS (Compare-And-Swap)

AtomicInteger는 락을 사용하지 않고도 동시성을 보장합니다. 그 비밀은 CAS 알고리즘입니다.

CAS란?

CAS는 하드웨어 레벨에서 지원하는 원자적 연산입니다.

CAS(메모리_주소, 예상값, 새값) {
    if (메모리_주소의_값 == 예상값) {
        메모리_주소의_값 = 새값;
        return true;
    } else {
        return false;
    }
}

이 비교와 교환이 하나의 CPU 명령어로 수행되므로 중간에 다른 스레드가 끼어들 수 없습니다.

AtomicInteger 내부 구조

public class AtomicInteger extends Number implements java.io.Serializable {
    private static final Unsafe U = Unsafe.getUnsafe();
    private static final long VALUE
        = U.objectFieldOffset(AtomicInteger.class, "value");

    private volatile int value;
    
    public final int addAndGet(int delta) {
        return U.getAndAddInt(this, VALUE, delta) + delta;
    }
}

// Unsafe 클래스의 실제 구현
public final class Unsafe {
    @IntrinsicCandidate
    public final int getAndAddInt(Object o, long offset, int delta) {
        int v;
        do {
            v = getIntVolatile(o, offset);
        } while (!weakCompareAndSetInt(o, offset, v, v + delta));
        return v;
    }
}

주요 포인트:

getIntVolatile(): 객체 o의 offset 위치에서 volatile 읽기 수행
weakCompareAndSetInt(): CAS 연산 수행
@IntrinsicCandidate: JVM이 이 메서드를 네이티브 CPU 명령어로 대체할 수 있음
메모리 offset을 직접 사용하여 성능 최적화

동작 과정 예시

100개 스레드가 동시에 addAndGet(1)을 호출할 때:

Thread A:
1. current = 0을 읽음
2. next = 1 계산
3. CAS(0, 1) 시도 -> 성공! (아직 0이므로)
4. 값이 1로 변경됨

Thread B:
1. current = 0을 읽음 (거의 동시에)
2. next = 1 계산
3. CAS(0, 1) 시도 -> 실패! (이미 1로 변경됨)
4. 루프 재시작
5. current = 1을 읽음
6. next = 2 계산
7. CAS(1, 2) 시도 -> 성공!

getIntVolatile()은 volatile 읽기를 수행하여
CPU 캐시 일관성 프로토콜을 통해 최신 값을 보장받고,
읽기/쓰기 재정렬을 방지합니다.

낙관적 락(Optimistic Lock)과의 유사성

낙관적 락의 특징

충돌이 드물 것이라 낙관적으로 가정
락을 미리 획득하지 않음
업데이트 시점에 충돌 검사
충돌 시 재시도

CAS도 동일한 철학

락 없이 작업 진행 (낙관적)
마지막에 값이 변경되었는지 확인
변경되었다면 재시도
충돌이 적을수록 효율적

직접 구현해보기

CAS를 직접 구현할 수는 없지만 (하드웨어 명령어 필요), 개념적으로 어떻게 100을 보장하는지 시뮬레이션해봅시다.

import java.util.concurrent.atomic.AtomicInteger;

public class CustomAtomicCounter {
    private final AtomicInteger value = new AtomicInteger(0);
    
    /**
     * CAS 기반 증가 연산
     */
    public int increment() {
        while (true) {
            int current = value.get();
            int next = current + 1;
            
            // CAS: 현재 값이 여전히 current라면 next로 변경
            if (value.compareAndSet(current, next)) {
                return next; // 성공
            }
            // 실패하면 루프 재시작 (다른 스레드가 값을 변경함)
        }
    }
    
    public int get() {
        return value.get();
    }
}

테스트 코드

import java.util.concurrent.CountDownLatch;
import java.util.concurrent.ExecutorService;
import java.util.concurrent.Executors;

public class ConcurrencyTest {
    public static void main(String[] args) throws InterruptedException {
        CustomAtomicCounter counter = new CustomAtomicCounter();
        int threadCount = 100;
        
        ExecutorService executor = Executors.newFixedThreadPool(threadCount);
        CountDownLatch latch = new CountDownLatch(threadCount);
        
        // 100개 스레드가 각각 1씩 증가
        for (int i = 0; i < threadCount; i++) {
            executor.submit(() -> {
                counter.increment();
                latch.countDown();
            });
        }
        
        latch.await();
        executor.shutdown();
        
        System.out.println("최종 값: " + counter.get()); // 항상 100!
    }
}

synchronized vs AtomicInteger 성능 비교

// 간단한 벤치마크
public class PerformanceTest {
    private static final int ITERATIONS = 1_000_000;
    
    // synchronized 버전
    private int syncCounter = 0;
    public synchronized void syncIncrement() {
        syncCounter++;
    }
    
    // AtomicInteger 버전
    private AtomicInteger atomicCounter = new AtomicInteger(0);
    public void atomicIncrement() {
        atomicCounter.incrementAndGet();
    }
}

일반적인 결과:

경쟁이 적을 때: AtomicInteger가 2-5배 빠름
경쟁이 심할 때: 성능 차이가 줄어들지만 여전히 AtomicInteger가 유리
synchronized는 블로킹되지만, CAS는 바쁘게 재시도 (스핀)

CAS의 장단점

장점

락 프리(Lock-Free): 데드락 불가능
높은 성능: 경쟁이 적을 때 매우 빠름
논블로킹: 스레드가 블로킹되지 않음

단점

ABA 문제: A→B→A로 변경될 때 감지 못함 (AtomicStampedReference로 해결)
CPU 사이클 낭비: 재시도 중 스핀으로 CPU 사용
경쟁이 심할 때: 재시도가 많아지면 오히려 비효율적

volatile의 역할

AtomicInteger 내부의 volatile int value에 주목해야 합니다.

private volatile int value;

volatile이 보장하는 것:

가시성(Visibility): 한 스레드의 변경이 즉시 다른 스레드에게 보임
재정렬 방지: 컴파일러/CPU의 최적화로 인한 명령어 순서 변경 금지

CAS만으로는 부족하고, volatile이 함께 있어야 올바른 동작이 보장됩니다.

실무에서 언제 사용할까?

AtomicInteger를 사용하면 좋은 경우

단순 카운터, ID 생성기
경쟁이 낮거나 중간 정도
락 오버헤드를 피하고 싶을 때

synchronized를 사용해야 하는 경우

복잡한 다단계 연산 (단일 원자성 보장 필요)
경쟁이 매우 심할 때
블로킹이 문제 없는 경우

// Atomic으로는 불가능한 예시
public synchronized void transferMoney(Account from, Account to, int amount) {
    from.balance -= amount;
    to.balance += amount;
    // 두 연산이 함께 원자적이어야 함
}

정리

AtomicInteger는 CAS 알고리즘을 사용합니다.
CAS는 하드웨어 레벨의 원자적 연산으로, 비교와 교환을 한 번에 수행합니다.
실패 시 재시도하는 낙관적 접근으로 100을 보장합니다.
volatile과 함께 사용되어 가시성도 보장합니다.
직접 구현한다면 AtomicInteger를 활용한 CAS 루프를 사용하면 됩니다.

참고 자료

Java Concurrency in Practice
Java Memory Model (JMM) Specification
CPU의 Compare-and-Swap 명령어 (x86의 CMPXCHG)

soo_vely의 개발로그

[AI] Claude Code에 Figma MCP 설정

1. Figma MCP란?

2. Claude Code에서 설정하기

방법 A: 공식 플러그인 설치

방법 B: 수동 설정 (Manual Setup)

3. 잠깐! 플러그인 설치 후 /mcp 목록에 Figma가 보이지 않는다면?

4. 인증 및 최종 연결 확인

5. 활용 가이드: 무엇을 물어볼까?

마치며

[AI] Claude - 커스텀 명령어로 커밋 프롬프트 자동화하기

️ 커스텀 슬래시 명령어란?

⚙️ 설정 방법

1. 명령어 폴더 생성

2. 마크다운(.md) 파일 추가

활용 예시 : 자동 커밋 및 푸시 명령어 (commit.md)

✨ 어떻게 사용하나요?

마무리하며

[AI] oh-my-claude code | Claude Code를 팀 오케스트레이션 플랫폼으로

들어가며

1. oh-my-claudecode란?

Claude Code vs oh-my-claudecode

2. 핵심 개념

에이전트 카탈로그 (19개)

스킬(Skill)

팀 파이프라인

3. 설치 방법

사전 요구사항

설치

팀 모드 활성화

초기 설정

4. 실제 사용 예시

기본 팀 실행

자율 실행 (Autopilot)

요구사항이 모호할 때 (Deep Interview)

검증 루프 (Ralph)

크로스 모델 병렬 실행

매직 키워드 트리거

5. 백엔드 개발자가 느낀 실용 포인트

모델 비용 자동 최적화

컨텍스트 오염 방지

IDOR, SQL Injection 등 보안 리뷰 자동화

설계서-코드 정합성 검토

6. 주의사항

마치며

참고

[AI] Claude Code CLI 설치 가이드

Claude Code CLI 설치 및 실행 방법

1️⃣ Claude Code 설치

✔ Windows

✔ Mac

2️⃣ 초기 실행 및 색상 선택

3️⃣ 로그인 방식 선택

4️⃣ 브라우저 인증 진행

5️⃣ 설치 완료 및 초기 안내

6️⃣ 폴더 신뢰 여부 확인

7️⃣ 실행 확인 및 종료 방법

✅ 마무리

[Back end / 보안] 데이터 암호화의 이해: 대칭키, 비대칭키부터 SHA-256 해시까지

1. 암호화 알고리즘의 분류

대칭키 암호화 (Symmetric Key Encryption)

비대칭키 암호화 (Asymmetric Key Encryption)

2. 왜 비밀번호에는 해싱을 사용할까?

해시 알고리즘의 특징

3. 실무 구현 사례: SHA-256

️ SHA-256 알고리즘

보안의 핵심: 솔트(Salt)

최종 데이터 저장: Base64 인코딩

4. 비밀번호를 분실했다면? "찾기"가 아닌 "재설정"

처리 프로세스

요약 및 결론

[Java] JVM Garbage Collection 구조와 Promotion(승격) 조건

1. JVM Garbage Collection(GC)이란?

GC의 장점

GC의 단점

2. JVM 힙 메모리 구조

3. Minor GC vs Major GC

Minor GC

Major GC (Full GC)

4. Minor 영역에서 Major 영역으로의 승격(Promotion)

2. 마크다운(`.md`) 파일 추가

활용 예시 : 자동 커밋 및 푸시 명령어 (`commit.md`)