어제보다 성장한 오늘

Codex vs Claude Code, 뭘 언제 써야 할까 — 백엔드 개발자의 정리

Wings of Freedom — Wed, 8 Jul 2026 14:44:05 +0900

에이전트형 코딩 도구가 이제 '자동완성'을 한참 넘어섰다. 코드베이스를 읽고, 파일을 고치고, 테스트를 돌리고, PR까지 열어두는 걸 하나의 지시로 해낸다. 그중 실무에서 가장 자주 비교선상에 오르는 두 도구가 OpenAI의 Codex와 Anthropic의 Claude Code다.

팀에 공유하려고 둘을 나란히 정리하다 보니, 결론이 생각보다 단순했다. "어느 게 더 좋냐"가 아니라 "어떤 작업에 어느 걸 쓰느냐" 의 문제라는 것. 아래에 그 근거를 정리했다.

참고: 아래 수치·요금·기능은 모두 2026년 7월 기준이다. 이 바닥은 몇 주 단위로 바뀌니, 실제 도입을 결정할 땐 공식 페이지에서 한 번 더 확인하길 권한다.

먼저 용어 정리 — "GPT Pro Codex"는 별도 제품이 아니다

간혹 "GPT Pro Codex"라는 표현을 보는데, 이건 별도의 제품이 아니라 ChatGPT Pro 요금제에서 쓰는 Codex를 가리킨다. Codex 자체는 요금제와 무관한 하나의 도구이고, Pro는 사용량 한도가 큰 플랜일 뿐이다.

그리고 하나 더. Codex라는 이름은 OpenAI가 시기마다 다른 것에 붙여 와서 혼란스럽다. 2021년의 최초 Codex 코딩 모델(지금은 폐기), 2025년 5월의 Codex Cloud 프리뷰, 그리고 2026년 현재의 GPT-5.5 기반 통합 에이전트가 전부 같은 이름을 쓴다. 이 글에서 말하는 건 세 번째, 지금 버전이다.

Codex — 속도와 토큰 효율에 최적화된 위임형 에이전트

Codex는 하나의 제품이라기보다 여러 표면(surface)의 묶음에 가깝다. 하나의 계정·모델·엔진을 공유하는 여러 진입점을 우산처럼 아우른다.

CLI(터미널): Rust로 작성된 오픈소스, GitHub 스타 6.7만 개 이상, npm/Homebrew로 설치
데스크톱 앱: macOS / Windows
IDE 확장: VS Code, Cursor, Windsurf, JetBrains
ChatGPT 내 클라우드 에이전트: 작업을 클라우드에 위임
GitHub 봇, 컴퓨터 유즈(화면 조작)

현재 세대는 GPT-5.5 기반이다. GPT-4.5 이후 OpenAI가 처음으로 완전히 재훈련한 모델로, 2026년 4월 23일 '에이전트 우선' 훈련을 명시하며 나왔다. 출시 시점 기준 매주 약 400만 명의 개발자가 Codex를 쓰고 있다고 한다.

동작 방식의 특징은 세 가지로 요약된다. 첫째, 클라우드 샌드박스에서 저장소의 복제 스냅샷 위에 작업한다(그래서 저장소가 활발히 바뀌는 중이면 드리프트가 생길 수 있다). 둘째, 매니저-워커 구조의 서브에이전트를 최대 8개까지 병렬로 돌린다. 셋째, 설정은 AGENTS.md 파일로 하는데 기본 상한이 32 KiB이고 초과분은 조용히 잘리므로, 지시 세트가 크면 파일을 하위 디렉터리로 쪼개야 한다.

요금은 별도 구독 없이 ChatGPT 플랜에 번들된다.

플랜가격	Codex	사용량
Plus	$20/월	GPT-5.5 기준 5시간 창당 15~80 메시지 (가벼운 개인용)
Pro 5x	$100/월	Plus 대비 5배 한도
Pro 20x	$200/월	Plus 대비 20배 한도
API 키	토큰 과금	gpt-5.3-codex 기준 입력 $1.75 / 출력 $14 (100만 토큰)

2026년 4월 2일부터 메시지 단위 과금에서 API 스타일의 토큰 요율로 전환됐다.

Claude Code — 깊은 추론과 통제에 최적화된 로컬 우선 에이전트

Claude Code도 터미널 기반 에이전트로, 다단계 작업을 하나의 지시로 처리한다는 점은 같다. 다만 지향점이 다르다. Codex가 접근성과 비동기 실행에 무게를 둔다면, Claude Code는 깊이(depth)와 데이터에 대한 통제(control) 쪽이다.

기본 모델은 Opus 4.8(2026년 5월 28일 출시)이고, Claude 5 계열을 세션별로 바꿔 쓸 수 있다. 기본 1M 토큰 컨텍스트, 최대 12.8만 토큰 출력, 적응형 사고를 지원한다. Anthropic은 이 모델이 "자신이 작성한 코드의 결함을 그냥 지나칠 확률이 이전 대비 약 4배 낮다"고 밝혔다.

Codex와 대비되는 핵심 세 가지는 이렇다. 첫째, 실제 파일시스템에 직접 접근한다. 스냅샷이 아니라 실제 저장소 상태 위에서 동작하니 드리프트 걱정이 없다. 둘째, 멀티 에이전트가 Agent Teams 형태다. 팀원 에이전트들이 공유 작업 목록과 메일박스로 서로 직접 소통한다(Codex의 단일 오케스트레이터 보고 방식과 대비된다). 셋째, 설정 파일 CLAUDE.md가 계층형이다. 전역에서 코딩 표준을 잡고, 프로젝트 수준에서 제한하고, 모듈 수준에서 오버라이드를 허용할 수 있다. AGENTS.md는 이를 기본 지원하지 않는다.

거버넌스 관점에선 26개의 라이프사이클 훅으로 깊은 커스터마이징이 가능하고(Codex엔 직접 대응물이 없다), 리서치 프리뷰인 Workflows는 대규모 엔터프라이즈 코드 마이그레이션을 겨냥한다.

요금은 Claude 구독에 번들되며, 인증 경로가 두 가지라는 점이 핵심이다.

경로	가격	특징
Pro	$20/월	정액, 토큰 미터링 없음, 사용 상한 존재
Max 5x	$100/월	Pro의 5배
Max 20x	$200/월	Pro의 20배
API 키	토큰 과금	Opus 4.8 기준 입력 $5 / 출력 $25 (100만 토큰). CI·자동화용

한 가지 운영상 주의점. 확장 사고(extended thinking)가 기본 활성이고 사고 토큰은 출력 요율(입력의 5배)로 과금되므로, 단순 작업에선 낭비가 된다. MAX_THINKING_TOKENS로 상한을 낮추거나 /effort로 조절하는 습관을 들이는 게 좋다.

정면 비교

벤치마크 — 벤치마크마다 승자가 다르다

중요한 전제 하나. 아래 수치 대부분은 벤더가 자체 보고한 값이고, 스캐폴드 차이에 따라 흔들린다. 작은 격차는 동점으로 보는 게 맞다.

경로	Codex (GPT-5.5)	Claude Code (Opus)	승자
SWE-bench Verified	~88.7%	88.6% (4.8)	사실상 동점
SWE-bench Pro (더 어려움)	58.6%	69.2% (4.8)	Claude
Terminal-Bench 2.0	82.7%	69.4% (4.7)	Codex

참고로 "88.7% Verified, 1위"라는 널리 인용되는 수치는 OpenAI 공식 발표가 아니라 애그리게이터 리더보드에서 나온 것이라 조심해서 봐야 한다. 정리하면, 터미널·시스템 작업은 Codex가, 복잡한 멀티파일 실무 문제는 Claude가 강한 경향이다.

토큰 효율과 비용 — Codex의 결정적 강점

실무 도입에서 가장 크게 작용하는 지점이 여기다. Codex는 토큰 효율에 맞춰 튜닝돼 있고, 그 격차가 꽤 크다.

토큰 사용량: Figma-to-code 벤치마크에서 Codex는 약 150만 토큰, Claude Code는 약 620만 토큰. 대략 4배 차이.
실비용 사례: 문서화된 Express.js 리팩터 작업에서 Codex는 약 $15, Claude Code는 약 $155가 들었다.
품질이라는 대가: 대신 같은 리팩터의 블라인드 품질 평가에서는 Claude Code 출력이 67%, Codex가 25% 비율로 "더 깨끗하다"는 평가를 받았다.

한마디로 "같은 결과에 Codex가 훨씬 싸다. 대신 첫 결과물의 품질은 Claude가 낫다"는 트레이드오프다.

아키텍처와 거버넌스

구분	Codex	Claude Code
실행 위치	클라우드 샌드박스(복제 스냅샷)	로컬, 실제 파일시스템 직접 접근
저장소 드리프트	활발히 변경 중이면 발생 가능	실제 상태 기준이라 없음
설정 파일	AGENTS.md (평면, 32KiB 상한)	CLAUDE.md (계층형)
멀티 에이전트	서브에이전트(매니저-워커, 최대 8)	Agent Teams(팀원 간 직접 소통)
샌드박싱	OS 커널 레벨	애플리케이션 레이어 훅
공통점	둘 다 MCP 지원, 1M 컨텍스트, $20 진입	(동일)

그래서 Java/Spring 백엔드 팀은 어떻게 써야 하나

우리처럼 Spring Boot 기반 백엔드를 다루는 팀 맥락에서 정리하면 이렇다.

계층형 CLAUDE.md는 멀티모듈에서 확실히 유리하다. Maven/Gradle 멀티모듈에 전사 코딩 컨벤션까지 얹힌 구조라면, 전역/프로젝트/모듈 3단 설정이 실질적인 이점이 된다. AGENTS.md는 파일을 쪼개야 하는 제약이 있다.

로컬 파일 직접 접근은 상태 동기화가 중요한 작업에서 안전하다. 로컬 스테이징이나 멀티 인스턴스 환경처럼 실제 상태와의 동기화가 중요한 작업에선 스냅샷 방식보다 직접 접근이 안심된다.

MCP 연동은 양쪽 다 재활용 가능하다. 이미 Jira/Atlassian을 MCP로 붙여 쓰고 있다면, 프로젝트 스코프 .mcp.json 구성은 두 도구 모두 MCP 표준을 지원하므로 어느 쪽에서든 그대로 쓸 수 있다.

비용은 작업 성격으로 나눠 통제하는 게 답이다. 테스트 보일러플레이트, 단순 리팩터, 마이그레이션 스윕 같은 반복 대량 작업은 Codex의 토큰 효율이 유리하다. 반면 아키텍처 설계나 리뷰 품질이 중요한 작업은 Claude 쪽이 낫다.

결론 — 고르는 문제가 아니라 라우팅하는 문제

벤치마크는 사실상 백중세다. 실제 선택 기준은 결국 "토큰 효율(Codex) vs 코드 품질·통제(Claude)" 로 수렴한다. 단순·반복 작업은 Codex로, 설계와 복잡한 멀티파일 작업은 Claude로 — 업계의 정론도 "허드렛일은 Codex로 라우팅하고, 아키텍처와 오케스트레이션은 Claude에 남겨두라"는 쪽이다. 실제로 2026년 현재 잘 쓰는 개발자들은 둘 다 쓴다.

구분	Codex	Claude Code
성격	속도·토큰 효율·비동기 위임	깊은 추론·코드 품질·통제
실행	클라우드 샌드박스(스냅샷)	로컬 직접 파일 접근
설정	AGENTS.md(평면)	CLAUDE.md(계층형)
모델	GPT-5.5	Opus 4.8
강점 작업	터미널/시스템, 대량 반복	멀티파일 설계, 품질

둘 중 하나를 고르는 문제가 아니라, 작업 성격에 따라 나눠 쓰는 문제다. 아직 한쪽만 쓰고 있다면, 다음 스프린트에 같은 작업을 양쪽에 한 번씩 돌려보고 체감 차이를 직접 기록해보길 권한다.

ChatGPT란 무엇인가? 초보자를 위한 완벽 가이드

Wings of Freedom — Sun, 14 Jun 2026 23:26:25 +0900

AI가 뭔지 모르던 내가 직접 써보고, 공부하며 정리한 솔직한 이야기
읽는 시간 약 7분 · 입문자 대상

들어가며 — 솔직히 처음엔 그냥 채팅 앱인 줄 알았다

2022년 말, 주변에서 "ChatGPT 써봤어?"라는 말이 자꾸 들리기 시작했다. 처음엔 별 관심 없었다. 그냥 또 잠깐 유행하는 앱이겠지 싶었다. 근데 직접 써보고 나서 생각이 완전히 바뀌었다.

질문 하나를 입력했더니, 그냥 검색 결과를 복붙한 게 아니라 마치 옆에 있는 사람이 설명해주듯 답변이 나왔다. 그 순간 "아, 이건 다르구나"를 느꼈다. 이 글은 그때부터 내가 직접 공부하고 경험하면서 정리한 내용이다.

ChatGPT, 한 줄로 설명하자면

ChatGPT는 OpenAI라는 미국 AI 연구 회사가 만든 대화형 인공지능이다. 쉽게 말하면, 채팅창에 말을 걸면 사람처럼 대화해주는 AI다.

근데 단순히 미리 저장된 답변을 꺼내 보여주는 게 아니다. 수백억 개의 문장을 학습해서, 질문의 맥락을 파악하고 그에 맞는 답변을 그 자리에서 생성한다. 그래서 같은 질문도 상황에 따라 다르게 답변이 나오기도 한다.

GPT = Generative Pre-trained Transformer
번역하면 "사전 학습된 생성형 변환기". 쉽게 말해 엄청난 양의 글을 미리 읽고 학습해서 새로운 글을 생성할 수 있는 AI라는 뜻이다.

작동 원리를 아주 간단히 설명하면

검색엔진처럼 어딘가에서 답을 "찾아오는" 게 아니라, 매번 새롭게 "만들어내는" 것이 핵심이다.

ChatGPT는 어떻게 탄생했나

연도	사건
2015년	OpenAI 설립. 일론 머스크, 샘 올트먼 등이 "안전한 AI 개발"을 목표로 비영리 연구소 설립
2020년	GPT-3 공개. 놀라운 성능이었지만 일반인이 쓰기엔 문턱이 높았음
2022년 11월	ChatGPT 출시. 채팅 형태의 인터페이스로 누구나 쉽게 사용 가능. 출시 5일 만에 100만 유저 돌파
2023년	GPT-4 출시. 이미지 인식, 플러그인, 음성 대화까지 기능 대폭 확장
현재	전 세계 월간 활성 사용자 1억 명 이상. 계속 발전 중

내가 실제로 써본 방법들

처음엔 "이걸 어디다 쓰지?" 싶었는데, 쓰다 보니 생각보다 쓸 곳이 많았다.

✏️ 글쓰기 보조

이메일 초안, 보고서, 블로그 글 구성을 잡는 데 진짜 유용하다. "이 내용으로 정중한 거절 이메일 써줘" 같은 식으로 쓰면 초안이 금방 나온다.

코딩 도우미

코드 오류 설명, 함수 작성, 언어 문법 질문까지 빠르게 해결된다. 개발자가 아니어도 간단한 자동화 스크립트 정도는 뚝딱 만들 수 있다.

학습 파트너

모르는 개념을 "초등학생도 이해할 수 있게 설명해줘"라고 하면 정말 잘 풀어준다. 교과서보다 훨씬 쉽게 설명해주는 경우가 많다.

번역 & 요약

긴 영문 문서를 붙여넣고 "핵심만 한국어로 요약해줘"하면 끝이다. 번역 품질도 충분히 실용적인 수준이다.

️ 여행 계획

일정, 숙소 유형, 예산 조건을 주면 꽤 그럴듯한 여행 계획을 뽑아준다. 물론 최신 정보는 직접 확인해야 한다.

아이디어 발상

막혔을 때 "이런 주제로 아이디어 10개 줘"하면 바로 나온다. 브레인스토밍 파트너로 쓰기 좋다.

무료로도 충분할까?

항목	무료 버전	유료 버전 (Plus, $20/월)
사용 모델	GPT-4o mini	GPT-4o (최신)
사용량 제한	있음	대폭 완화
이미지 생성	❌	✅ DALL·E 3
파일 분석	❌	✅ PDF, 엑셀 등
응답 속도	보통	우선 접속, 빠름
음성 대화	제한적	✅ 고급 음성

처음 시작한다면 무료 버전으로도 충분히 체험해볼 수 있다. 자주 쓰게 되면 그때 업그레이드를 고민해도 전혀 늦지 않는다.

이렇게 쓰면 훨씬 잘 나온다

써보면서 깨달은 건데, 어떻게 질문하느냐가 답변 품질을 결정한다.

1. 역할을 줘라

❌ "도쿄 여행 일정 짜줘"
✅ "너는 10년 경력의 여행 플래너야. 예산 50만 원으로 도쿄 3박 4일 일정을 짜줘. 대중교통 위주로."

2. 조건을 구체적으로

❌ "글 써줘"
✅ "초등학생도 이해할 수 있게, 500자 내로, 핵심 3가지를 포함해서 써줘"

3. 마음에 안 들면 이어서 요청

"이 부분을 더 쉽게 바꿔줘"
"좀 더 짧게 요약해줘"
"2번 항목을 더 구체적으로 설명해줘"

4. 사실 확인은 직접 해야 한다

ChatGPT는 틀린 정보를 자신 있게 말하기도 한다. 이를 "환각(Hallucination)"이라고 부른다. 중요한 사실관계는 반드시 따로 확인해야 한다.

결국 "도구"라는 걸 잊지 말자

ChatGPT를 몇 달 써본 결론은 이거다. 완벽하지 않지만, 잘 쓰면 생산성을 몇 배로 올려주는 도구다.

글쓰기 속도가 빨라졌고, 모르는 개념도 빠르게 파악할 수 있게 됐다. 무엇보다 "이거 어떻게 하지?"라고 막힐 때 일단 물어볼 수 있는 상대가 생겼다는 게 크다.

AI가 내 일을 다 대신해준다는 기대보다, 내 생각을 빠르게 실행할 수 있게 도와주는 조수로 생각하면 딱 맞는 것 같다. 일단 한번 써보는 걸 추천한다.

시작하는 법
chat.openai.com 접속 → 구글 계정으로 무료 가입 → 채팅창에 한국어로 바로 질문하면 된다. 한국어 지원 잘 됩니다.

GitHub spec-kit: AI 코딩 에이전트를 제대로 쓰는 법

Wings of Freedom — Sun, 14 Jun 2026 22:28:11 +0900

Claude Code나 Cursor를 쓰다 보면 이런 경험이 한 번씩 있을 것이다. 원하는 걸 설명했고, 에이전트가 뚝딱 코드를 짜줬는데 — 컴파일도 되고, 언뜻 봐도 그럴싸한데 — 막상 돌려보면 내가 원했던 게 아니다. 그렇다고 에이전트가 못 만든 게 아니다. 내가 원하는 게 뭔지 제대로 알려주지 않은 거다.

GitHub에서 이 문제를 정면으로 다룬 오픈소스 툴킷을 내놨다. 이름은 spec-kit이다.

spec-kit이 말하는 문제: "바이브 코딩"의 한계

GitHub은 이 문제를 꽤 직접적으로 표현한다.

"우리는 AI 코딩 에이전트를 검색 엔진처럼 쓰고 있다. 그런데 에이전트는 검색 엔진이 아니라, 패턴 인식은 잘하지만 모호한 지시에는 취약한 '글자 그대로 받아들이는 페어 프로그래머'에 가깝다."

그래서 나온 개념이 Spec-Driven Development(SDD), 즉 스펙 주도 개발이다. 핵심 철학은 단순하다:

"스펙이 코드를 섬기는 게 아니라, 코드가 스펙을 섬긴다."

PRD나 스펙 문서를 구현의 참고 자료가 아니라, 구현을 생성하는 소스로 삼는다는 뜻이다.

spec-kit이란 뭔가

spec-kit은 두 가지로 구성된다:

Specify CLI — 프로젝트를 SDD 방식으로 부트스트랩해주는 커맨드라인 툴
템플릿 + 슬래시 커맨드 — AI 에이전트가 실행할 수 있는 스펙 구조, 기술 계획, 태스크 분해 방식을 정의한 파일들

Claude Code, GitHub Copilot, Gemini CLI, Cursor, Windsurf, Codex CLI 등 30개 이상의 AI 코딩 에이전트를 지원한다.

설치 방법

Python 3.11 이상이 필요하다. uv로 설치하는 게 공식 권장 방법이다.

# uv 설치 (없으면)
curl -LsSf https://astral.sh/uv/install.sh | sh

# specify CLI 설치
uv tool install specify-cli --from git+https://github.com/github/spec-kit

# 프로젝트 초기화
specify init

초기화하면 선택한 AI 에이전트와 플랫폼에 맞는 템플릿이 프로젝트 안에 생성된다.

핵심 워크플로: 4단계 슬래시 커맨드

spec-kit의 워크플로는 순서대로 실행하는 슬래시 커맨드로 구성된다.

1단계: /speckit.constitution

프로젝트의 불변 원칙을 세운다. 아키텍처 결정, 코딩 컨벤션, 보안 요구사항 같은 "무슨 일이 있어도 바꾸지 않을 것들"을 명문화한다.

2단계: /speckit.specify

무엇을(what) 만들 것인지, 왜(why) 만드는 건지를 기술한다. 이 단계에서는 기술 스택을 결정하지 않는다. 요구사항에 집중한다.

3단계: /speckit.plan

기술 계획을 세운다. 여기서 스택, 아키텍처, 구현 방향을 결정한다. specify에서 나온 "what"을 기반으로 "how"를 설계한다.

4단계: /speckit.tasks → /speckit.implement

계획을 AI 에이전트가 하나씩 실행할 수 있는 작은 태스크 단위로 쪼갠다. 그리고 에이전트가 태스크를 순서대로 구현한다.

이게 기존 방식과 뭐가 다른가

구분 기존 방식 (바이브 코딩) spec-kit (SDD)

시작점	프롬프트	스펙 문서
에이전트 역할	프롬프트 해석	스펙 실행
오류 원인	의도 전달 실패	스펙 불일치
변경 비용	높음 (맥락 재설명)	낮음 (스펙 수정)

특히 유용한 시나리오는 세 가지라고 GitHub이 강조한다:

그린필드 프로젝트: 처음부터 SDD로 시작하면 방향이 흔들리지 않는다
기존 시스템의 새 기능 추가: 기존 코드베이스의 맥락을 스펙에 담아 에이전트에게 전달한다
레거시 현대화: 기존 코드가 "무엇을 해야 하는지"를 스펙으로 먼저 정리한 뒤 마이그레이션

실제로 써보니

솔직히 처음엔 "그냥 문서 잘 쓰라는 거 아닌가?" 싶었다. 그런데 써보면 미묘하게 다르다.

기존에 Claude Code에 "이런 앱 만들어줘"라고 하면 에이전트가 스스로 가정을 채운다. 내가 생각하는 아키텍처가 아닐 수도 있고, 내가 원하는 라이브러리를 안 쓸 수도 있다.

spec-kit 방식은 먼저 스펙을 내가 직접 정의하고, 에이전트는 그 스펙 안에서만 움직인다. "무엇을 만들지"가 명확하게 고정되니 에이전트가 엉뚱한 방향으로 가는 일이 줄어든다. 태스크 단위로 나눠서 하나씩 구현하는 것도, 긴 컨텍스트에서 에이전트가 길을 잃는 걸 방지하는 데 효과적이다.

참고

GitHub 레포: github/spec-kit
공식 블로그: Spec-driven development with AI
현재 GitHub 스타 111k+, 릴리즈 55회 이상 (2026년 6월 기준)

Claude Code + CodeGraph: AI 코딩 비용을 절반으로 줄이는 방법

Wings of Freedom — Sun, 14 Jun 2026 22:20:37 +0900

Claude Code를 쓰다 보면 항상 마주치는 장면이 있다.

⏺ Explore("인증 미들웨어가 JWT를 어떻게 검증하지?")
⎿ Done (52 tool uses · 89.4k tokens · 1m 37s)

질문 하나 던졌을 뿐인데 Claude는 수십 번 파일을 뒤지고, 토큰을 잔뜩 태우고, 거의 2분이 지나서야 겨우 실제 작업을 시작한다. 이게 매 세션마다 반복된다.

이 문제를 깔끔하게 해결해 주는 오픈소스 도구를 발견했다. 바로 CodeGraph다.

문제의 본질: "탐색 세금"

Claude Code는 코드베이스에 대한 기억이 없다. 그래서 매번 Explore 에이전트를 띄워서 grep, glob, Read 호출로 파일을 샅샅이 뒤진다. 이 툴 호출 하나하나가 토큰을 소모하고, 파일을 스캔할수록 컨텍스트 윈도우가 줄어든다. Medium

실제로 측정해 봤더니 하나의 아키텍처 질문에 60번 툴 호출, 157,800 토큰, 거의 2분이 필요했다. 근데 이 중 대부분은 "어디에 뭐가 있는지" 찾는 탐색 작업이지, 실제 코드 분석이 아니다.

AI 코딩 에이전트가 코드베이스 아키텍처에 대한 질문을 받으면, 탐색 하위 에이전트들을 생성해서 심볼 정의를 찾기 위해 grep, 패턴으로 파일을 찾기 위해 glob, 파일 내용을 처리하기 위해 Read를 호출한다. 이 호출들은 각각 별도의 툴 인보케이션으로 토큰 비용이 발생하고 레이턴시를 추가한다. Tosea

이게 바로 **탐색 세금(discovery tax)**이다.

CodeGraph란 무엇인가?

CodeGraph는 코드베이스의 사전 인덱싱된 지식 그래프(심볼, 콜 그래프, 임포트, 상속, 코드 구조)를 빌드하는 오픈소스 도구다. 에이전트가 파일을 하나씩 스캔하는 대신 그 그래프를 한 번에 쿼리한다. Claude Code용 MCP 서버로 실행되며, MIT 라이센스, 19개 이상의 언어를 지원하고, 100% 로컬에서 동작한다. DEV Community

핵심 아이디어는 단순하다. 에이전트가 탐색하기 전에 지도를 먼저 건네주는 것이다.

CodeGraph는 로컬 코드 인텔리전스 라이브러리 + CLI + MCP 서버로, tree-sitter로 코드를 파싱하고 심볼/엣지/파일을 SQLite(FTS5)에 저장한 뒤, MCP를 통해 AI 에이전트에게 지식 그래프를 노출한다. 프로젝트별 데이터는 .codegraph/ 폴더에 저장되며, 추출은 LLM 요약이 아닌 AST 기반으로 결정적(deterministic)이다. GitHub

실제 성능 차이

7개의 실제 오픈소스 코드베이스, 7가지 언어를 대상으로 CodeGraph 유무를 비교한 공식 벤치마크 결과(Claude Opus 4.8, 2026년 6월 재검증): 평균 16% 비용 절감, 47% 토큰 감소, 22% 속도 향상, 58% 툴 호출 감소. GitHub

특히 VS Code 환경에서는 툴 호출이 최대 81%까지 줄어들었는데, 대형 레포일수록 파일 탐색 오버헤드가 크기 때문이다. 반대로 100개 미만의 소규모 프로젝트에서는 효과가 미미하다. DEV Community

설치 방법 (3줄이면 끝)

bash

# 1. 설치
npm install -g @colbymchenry/codegraph

# 2. 프로젝트 인덱싱
cd my-project
codegraph init

# 3. 상태 확인
codegraph status

CodeGraph v0.9.9는 프로그래매틱 라이브러리 사용을 위해 Node.js 22+가 필요하다. CLI와 MCP 서버는 자체 런타임을 번들링하므로, 글로벌 설치 시 Node 버전을 별도로 관리할 필요가 없다. DEV Community

Claude Code에서 MCP 서버를 활성화하려면 .claude/settings.json에 다음을 추가하면 된다.

json

{
  "mcpServers": {
    "codegraph": {
      "command": "codegraph",
      "args": ["mcp"]
    }
  }
}

실제로 어떻게 동작하나?

CodeGraph를 적용하면 Claude Code의 흐름이 완전히 달라진다.

Before (CodeGraph 없이):

⏺ Explore("JWT 검증 로직 찾기")
  → grep → glob → Read → Read → Read → ...
⎿ Done (52 tool uses · 89.4k tokens · 1m 37s)

After (CodeGraph 적용):

⏺ codegraph_explore("JWT validation middleware")
⎿ AuthMiddleware.kt:23 - validateToken()
  JwtService.kt:45  - verify(), decode()
  TokenRepository.kt:12 - findByToken()
Done (1 tool use · 3.2k tokens · 4s)

codegraph_explore는 관련 없는 구현들을 시그니처로 축약하면서도, 수천 줄짜리 파일 안에 묻혀 있어도 답을 완전히 보여준다. 응답 크기가 파일 수가 아닌 답변의 내용에 맞게 최적화된다. GitHub

언제 쓰면 좋을까?

CodeGraph는 토큰 소모와 툴 호출 빈도라는 AI 지원 개발의 핵심 문제를 해결한다. 100% 로컬에서 동작하기 때문에 민감한 코드가 외부로 나갈 걱정이 없다. AIToolly

쉽게 판단하자면, 아래 상황이면 바로 써볼 만하다.

파일이 100개 이상인 프로젝트를 Claude Code로 작업할 때
"Explore 에이전트가 같은 파일을 계속 반복 스캔한다"는 느낌이 들 때
Claude Code 비용이 부담될 때
코드베이스 아키텍처 질문을 자주 던질 때

반대로 작은 프로젝트나 파일 수가 적은 경우엔 효과가 제한적이다.

마무리

CodeGraph의 핵심 아이디어는 생각해 보면 당연하다. AI에게 코드를 탐색하게 두는 게 아니라, 미리 인덱싱된 지식 그래프를 주는 것. Spring Boot 쓸 때 Entity를 매번 파일로 뒤지는 게 아니라 DB 스키마를 보는 것과 비슷한 개념이다.

AI 코딩 도구의 중요한 방향을 보여주는 프로젝트다. 더 강력한 모델만이 답이 아니라, 모델에게 더 좋은 로컬 코드 컨텍스트를 제공하는 것도 하나의 답이다. KnightLi Blog

GitHub 레포는 colbymchenry/codegraph에서 확인할 수 있다. MIT 라이센스 오픈소스다.

Claude Code용 상태 표시줄 플러그인 - 한 줄로 컨텍스트, 속도 제한, 비용 확인

Wings of Freedom — Fri, 27 Feb 2026 18:29:29 +0900

https://github.com/uppinote20/claude-dashboard

이렇게 바로 클로드에서 생성 가능합니다.

이런 디스플레이 모드도 선택하고

모든 대답을 끝냅니다.

그럼 이와 같은 사용량을 확인 할 수 있어요.

소스트리 강제 푸시(force push)

Wings of Freedom — Thu, 15 Jan 2026 11:28:58 +0900

main 브랜치에 잘 못 머지하여, 소스트리로 이 전 상태로 되돌리는 방법입니다.

macOS 기준입니다.

설정 > 고급에서 강제 푸시를 허용 체크

9e56a49 잘 못 푸시하여 "b597627"로 원복하려고 합니다.

되돌리고자 하는 커밋을 오른쪽 마우스를 클릭하여, "이 커밋으로 초기화" 클릭

사용중인 모드에서 "Hard - 모든 작업 상태 내 변경 사항을 버림"을 선택 후, 확인

이렇게 1 아래 화살표가 표시되지만 푸시 버튼을 클릭

"강제 푸시" 체크박스를 선택하고 확인 버튼 클릭

이렇게 예전 상태로 돌아가는 것을 확인 할 수 있습니다.

React npx create-react-app npm error code EEXIST

Wings of Freedom — Fri, 26 Sep 2025 15:53:51 +0900

react 프로젝트를 만들기 위해 아래 명령어 입력

$ npx create-react-app .

입력시 아래와 같은 에러 발생

npm error code EEXIST
npm error syscall mkdir
npm error path /Users/{유저명}/.npm/_cacache/content-v2/sha512/6c
npm error errno EEXIST
npm error Invalid response body while trying to fetch https://registry.npmjs.org/typescript: EACCES: permission denied, mkdir '/Users/greencar/.npm/_cacache/content-v2/sha512/6c'
npm error File exists: /Users/{유저명}/.npm/_cacache/content-v2/sha512/6c
npm error Remove the existing file and try again, or run npm
npm error with --force to overwrite files recklessly.
npm error A complete log of this run can be found in: /Users/{유저명}/.npm/_logs/2025-09-26T05_31_22_425Z-debug-0.log

node.js를 삭제하고 설치해 보았지만 동일하게 에러

아래 명령어로 캐시를 삭제 시도

$ npm cache verify

위 명령어를 입력하면 아래와 같이 노출되는데,

'chown'은 'change owner'의 약자이다. 즉 해당 디렉토리 안에 있는 모든 파일에 대한 소유 권한을 그룹 ID 20, 사용자 ID 501에 할당한다는 의미였다.

npm error code EACCES
npm error syscall open
npm error path /Users/{유저명}/.npm/_cacache/index-v5/02/f5/edc1bbb9c74c3776beb4a96bd21991b46bb40507edd7be8d7c966577dcb5
npm error errno -13
npm error
npm error Your cache folder contains root-owned files, due to a bug in
npm error previous versions of npm which has since been addressed.
npm error
npm error To permanently fix this problem, please run:
npm error   sudo chown -R 501:20 "/Users/{유저명}/.npm"
npm error A complete log of this run can be found in: /Users/{유저명}/.npm/_logs/2025-09-26T06_36_08_194Z-debug-0.log

이렇게 알려준 명령어 입력

$ sudo chown -R 501:20 "/Users/{유저명}/.npm

다시 "npx create-react-app ."을 입력하니 정상적으로 react app이 생서되었다.

IntelliJ AI Pro / AI Ultimate 라이센스 구매 및 할당 방법

Wings of Freedom — Tue, 9 Sep 2025 18:00:30 +0900

회사에서 jetBrains AI 사용할 기회가 생겼습니다.

이 기회에 라이센스 할당 방법 기록합니다.

JetBrains AI Assistant 란?

공식문서에 따르면, JetBrain AI 서비스는 고객의 데이터 보안을 최우선으로 생각하며, 고개 데이터를 수집하거나 교육 목적으로 사용할 가능성이 있는 LLM 제공업체와 협력하지 않는다고 합니다. 그리고 OpenAI 및 JetBrain 자체적으로 개발한 다양한 소규모 LLM 모델들과 함께 작동한다고 합니다.
(주의)Intellj 2024.3 버전부터 사용할수 있습니다.

라이센스 구매 및 할당 방법

JetBrains 마스터 계정으로 로그인하여 라이센스 구매

구매하면 아래와 같이 Transactions / Invoices에 구매 목록이 보여집니다.

주문번호를 클릭하면 아래와 같은 화면이 보여지고, "View order licenses" 버튼을 클릭

라이센스ID가 보여지면 해당 구성원 계정으로 Assign 버튼으로 할당

이렇게 라이센스 할당 완료

AI Assitant 플러그인 설치

JetBrains Junie 설치

AI Chat에서 "Manage License"를 클릭하면

이렇게 라이센스 할당 된 것을 확인

이와 같이 intellij 안에서 AI와 채팅을 하며 사용 할 수 있습니다.

junie도 사용 가능한데, 정확히 뭔지 몰라서 AI Assistant에 물어보았습니다.

다음은 JetBrains Junie에 대한 요약입니다.
Junie가 무엇인가
- Junie는 JetBrains가 개발한 AI 코딩 에이전트로, 개발자와 함께 또는 독립적으로 코딩 작업을 수행합니다.
프로젝트 맥락을 이해하고 코드 검색·분석, 멀티파일 편집, IDE 인스펙션 기반 수정,
코드/테스트 실행, 변경 검증 등을 자동으로 처리할 수 있습니다.

무엇을 할 수 있나
- 프로젝트 구조와 컨텍스트를 활용해 관련 코드 탐색/분석
- IDE 인스펙션을 활용한 코드 수정 및 리팩터링
- 테스트/애플리케이션 실행, 경고·오류 감소를 위한 반복 작업 수행
- 변경사항 검토와 가이드 제공, 복잡한 작업 협업 지원

이용 가능 IDE와 제한
- 2025.1부터 AI Assistant와 함께 설치되지만, 지원 IDE가 제한됩니다
- 중국 본토에서는 지역 제한으로 제공되지 않으며, 현재 AI Enterprise 라이선스 티어에서는 제공되지 않습니다.

AI Assistant를 이용해 코딩 한번 해봐야겠습니다.

[Java] Map을 Key, Value로 정렬하기

Wings of Freedom — Mon, 8 Sep 2025 17:30:26 +0900

개요

Java에서 Map 정렬이 필요할 때, 그 방법에 대해 알아보겠습니다.

정렬 기준은 key, value 두가지로 나눌 수 있습니다.

1. Key 값을 기준으로 정렬하기

map 의 keySet을 이용하여 정렬합니다.
오름차순 시에는 Collection.sort(), 내림차순 시에는 Collection.reverse() 메소드를 사용하여 정렬합니다.

import java.util.*;

public class Sort {

    public static void main(String[] args) {

        Map<String, Integer> map = new HashMap<>();

        map.put("A", 10);
        map.put("D", 30);
        map.put("C", 20);
        map.put("B", 40);


        List<String> keySet = new ArrayList<>(map.keySet());

        // 키 값으로 오름차순 정렬
        Collections.sort(keySet);

        for (String key : keySet) {
            System.out.print("Key : " + key);
            System.out.println(", Val : " + map.get(key));
        }
       
        /*  결과
            Key : A, Val : 10
            Key : B, Val : 40
            Key : C, Val : 20
            Key : D, Val : 30
         */
        
        

        // 키 값으로 내림차순 정렬
        Collections.reverse(keySet);

        for (String key : keySet) {
            System.out.print("Key : " + key);
            System.out.println(", Val : " + map.get(key));
        }
        
        /*  결과
            Key : D, Val : 30
            Key : C, Val : 20
            Key : B, Val : 40
            Key : A, Val : 10
        */
	}
}

2.Value 값을 기준으로 정렬하기

Value 값을 기준으로 정렬할 때는 comparator를 사용하여 정렬합니다.

comparator는 람다 표현식으로 간단하게 표현할 수도 있습니다.

import java.util.*;

public class Sort {

    public static void main(String[] args) {

		Map<String, Integer> map = new HashMap<>();

        map.put("A", 10);
        map.put("D", 30);
        map.put("C", 20);
        map.put("B", 40);


        List<String> keySet = new ArrayList<>(map.keySet());

        // Value 값으로 오름차순 정렬
        keySet.sort(new Comparator<String>() {
            @Override
            public int compare(String o1, String o2) {
                return map.get(o1).compareTo(map.get(o2));
            }
        });

        for (String key : keySet) {
            System.out.print("Key : " + key);
            System.out.println(", Val : " + map.get(key));
        }

        /*
            결과
            Key : A, Val : 10
            Key : C, Val : 20
            Key : D, Val : 30
            Key : B, Val : 40
         */

        // Value 값으로 내림차순 정렬
        // 위 comparator 람다 표현식으로
        keySet.sort((o1, o2) -> map.get(o2).compareTo(map.get(o1)));

        for (String key : keySet) {
            System.out.print("Key : " + key);
            System.out.println(", Val : " + map.get(key));
        }

        /* 결과
            Key : B, Val : 40
            Key : D, Val : 30
            Key : C, Val : 20
            Key : A, Val : 10
         */
	}
}

Deployment Patterns

Wings of Freedom — Wed, 27 Aug 2025 17:02:50 +0900

기존 가상화 방식 -> 서버 가상화 -> 컨테이너 가상화

Containers Virtualization

Isolation
- 각 마이크로서비스는 자체 컨테이너에서 실행
- 다른 마이크로서비스와 호스트 운영 체제로부터 격리
Scalability
- 컨테이너화 된 마이크로서비스의 인스턴스를 더 많이 실행 -> 수평적 확장
Portability
- 컨테이너를 통해 마이크로서비스를 쉽게 배포
- 컨테이너 런타임을 지원하는 모든 컴퓨터나 클라우드 플랫폼에서 실행
Resiliency
- 마이크로서비스는 독립적으로 배포하고 확장할 수 있도록 설계
- 빠르게 시작 및 중지 -> 애플리케이션의 복원력이 향상

Container Orchestration tools

컨테이너화된 애플리케이션의 배포, 확장, 관리 자동화
- 기본 인프라 추상화
- 리소스 할당, 로드 밸런싱, 모니터링 작업처리
- 효율적, 확장 가능한 방식으로 실행, 관리
클러스터 전체에서 컨테이너화된 워크로드의 배포, 확장 및 운영 문제를 자동화
각 마이크로서비스를 컨테이너 이미지로 패키징 -> 컨테이너 레지스트리 푸시
컨테이너 오케스트레이터 -> 마이크로서비스를 노드 클러스터에 배포
컨테이너를 노드에 스케줄링, 상태 모니터링, 자체 복구 기능 처리

Kubernetes

오픈 소스 컨테이너 오케스트레이션 플랫폼
- 컨테이너화된 애플리케이션을 배포, 관리 및 확장 -> 프로세스 자동화
자체 복구
- Kubernetes는 실패한 컨테이너를 자동으로 재시작
자동 확장
- 필요에 따라 마이크로서비스를 자동으로 확장/축소
부하 분산
- 마이크로서비스의 트래픽 자동 분산
선언적 구성
- 구성 파일을 사용하여 마이크로서비스에 필요한 상태 지정 -> 애플리케이션 배포/관리 자동화

Reference
마이크로서비스 디자인 패턴 완벽 가이드
https://www.inflearn.com/course/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EB%94%94%EC%9E%90%EC%9D%B8%ED%8C%A8%ED%84%B4-msa

Scalability

Wings of Freedom — Wed, 27 Aug 2025 16:46:48 +0900

동시에 수용 가능한 요청 수는 얼마인가?

동시접속자 수	초당 요청 수 (RPS)	권장 시스템 설계 및 고려사항
500	50 RPS	단일 서버로 처리 가능하나, 향후 확장을 대비한 설계 필요
1K	100 RPS	로드 밸런서를 도입하여 두 대의 서버로 부하 분산 고려
2K	200 RPS	세션 상태 관리를 위한 분산 캐시 도입 검토
5K	500 RPS	데이터베이스 샤딩 또는 리플리케이션 고려
10K	1,000 RPS	콘텐츠 전송 네트워크(CDN) 활용하여 정적 자원 제공 최적화
20K	2,000 RPS	마이크로서비스 아키텍처 도입 검토
50K	5,000 RPS	서비스 메시 도입 및 오케스트레이션 도구 활용 고려
100K	10,000 RPS	글로벌 로드 밸런싱 및 멀티 리전 배포 검토
500K	50,000 RPS	대규모 분산 시스템 설계 및 데이터 일관성 유지 전략 수립 필요

Vertical Scaling – Scale up

기본적으로 노드를 더 강하게 구성
- 하드웨어를 더 추가하여 서버를 더 강하게
- 단일 노드에 더 많은 리소스를 추가
기존 인프라를 유지하면서 더 많은 컴퓨팅 파워 추가
- 최적화를 통해 더 많은 요청 처리
- 기존 코드에 대한 변경 X
- 증가하는 작업 부하 -> CPU, RAM 및 DISK 추가
확장성 제한
- 하드웨어에도 최대 용량 제한이 있음
- 수백만 개의 요청 처리 -> 수평적 확장 또는 더 많은 컴퓨팅 확장 필요

Horizontal Scaling – Scale out

서로 다른 서버 간에 부하 분할(분산)
- 기존 사양을 변경하지 않고 더 많은 머신 인스턴스를 추가
- 여러 머신에서 처리 능력과 부하 분산을 공유
- 리소스 풀에 더 많은 머신을 추가
확장성과 안정성을 모두 만족
- 분산 아키텍처의 확장
여러 서버로 분할할 때의 고려사항
- 상태가 있는지 여부
- 데이터베이스 서버 -> CAP 정리 / 관리 필요

Load Balancer

모든 애플리케이션 노드에 걸쳐 트래픽 분산
- 응답성과 가용성을 개선
- 다양한 알고리즘을 사용하여 여러 백엔드 서버에 트래픽 분산 -> 해싱 알고리즘
내결함성이 있어야 하며 가용성을 개선
수평적 확장성 문제를 해결
- 모든 키를 다시 정렬할 필요 없음

Distributed Caching

자주 액세스하는 데이터
- 메모리에서 빠르게 액세스할 수 있는 캐시에 저장
- 시스템 성능 개선
캐시로 대기 시간을 줄이고 애플리케이션을 더 빠르게 만듬
- 마이크로서비스의 성능, 확장성, 가용성을 높임
- 요청 수가 증가 -> 캐싱은 고가용성으로 요청 처리
애플리케이션 요청이 자주 변경되지 않는 데이터
- 캐싱이 매우 효율적
자주 액세스하는 데이터를 캐시에 로컬로 저장
- 마이크로서비스는 외부 시스템에 대한 반복적인 호출하는 대신 응답 시간이 더 빨라짐
향상된 성능
- 서비스는 DB 또는 기타 외부 시스템에 대한 반복적인 호출 줄임
복원성
- 외부 시스템을 사용할 수 없게 되어도 서비스가 계속 작동 가능
확장성
- 서비스가 외부 시스템을 확장할 필요 없이 증가된 트래픽을 처리 가능

Distributed Caching Type

In-memory cache
- 컴퓨터의 주 메모리에 데이터 저장
- 가장 빠른 유형의 캐시
- 캐시를 다시 시작하거나 컴퓨터를 종료하면 데이터가 손실
Disk cache
- HDD나 SDD에 데이터 저장
- 디스크 캐시는 메모리 내 캐시보다 느리지만 데이터 유지 가능
분산 캐시
- 여러 컴퓨터에 분산
- MSA와 같은 분산 시스템에서 사용
- 데이터를 여러 위치에서 저장하고 액세스
- 시스템의 성능과 확장성 개선

Caching Strategies

Cache Aside
- 클라이언트가 백엔드 서비스에 요청하기 전에 캐시에서 데이터 확인
- 마이크로서비스가 DB에서 데이터를 읽어야 하는 경우 먼저 캐시 확인
- 데이터가 사용 가능한 경우(Cache Hit) -> 캐시된 데이터가 반환
- 데이터를 사용할 수 없는 경우(Cache Miss) -> DB에 데이터를 쿼리
- 클라이언트는 백엔드 서비스에서 데이터를 검색 -> 다음 요청을 위해 캐시 저장
Read-Through
- Cache Miss 발생 -> DB에서 누락된 데이터를 로드하고 캐시를 채우고 애플리케이션에 반환
- 클라이언트가 캐시에서 찾을 수 없는 데이터를 요청 -> 캐시가 자동으로 DB에서 데이터를 검색
- 캐시는 항상 DB와 일관성 유지
Write-Through
- 데이터가 백엔드 서비스에 기록될 때마다 캐시 업데이트
- 캐시는 항상 최신 데이터를 보유하지만, 쓰기 작업 수가 더 많아질 수 있음
- 데이터는 먼저 캐시에 기록되고 그 다음 DB에 기록
Write-Back or Write-Behind
- 캐시 업데이트를 나중으로 미룸
- 쓰기 작업 수가 줄어들지만 캐시에 최신 데이터가 없을 수 있음

Authentication & Authorization

Wings of Freedom — Wed, 27 Aug 2025 16:10:48 +0900

Authentication (Verifying Identity)
- 사용자의 신원을 확인하는 과정 (Who are you?)
- 시스템 접근을 요청하는 사용자의 신원 판별
방법)
- Password-Based Authentication
- Passwordless Authentication
- 2FA/MFA (Two-Factor Authentication / Multi- Factor Authentication)
- Single sign-on (SSO)
- Social authentication
Ex) Authentication: ID/PW 로그인
MSA에서의 인증 인가의 중요성
- Microservices는 각각의 서비스가 독립적으로 동작  별도의 보안 영역 구성
- 서비스 간 보안 신뢰성 보장 및 확장 가능성 유지 필수
주요 역할
- 개별 서비스마다 별도의 보안 정책 수립 가능
- 서비스 간 안전한 데이터 교환 가능
- 개별 서비스 접근 시 사용자의 권한 및 역할 명확히 구분 가능

Basic Authentication

간단한 사용자 이름과 비밀번호 기반 인증 방식
장점: 구현 간단, 빠른 적용 가능
단점: 보안 취약, 암호화 필수(HTTPS 사용 권장)

OAuth 2.0

타사 서비스가 사용자를 대신하여 접근 권한을 얻을 수 있도록 허용하는 권한 위임 프로토콜
장점: 높은 보안, 다양한 권한 수준 설정 가능
단점: 구현 복잡성 증가

JWT (JSON Web Token)

무상태(Stateless) 방식의 인증 및 인가를 지원하는 토큰 기반 인증 방식
장점: 확장성 높음, 서비스 간 인증 정보 공유 쉬움
단점: 토큰 탈취 시 문제 발생, 토큰 관리 주의 필요

Rate Limiting

API에 유입되는 요청 수를 제한하여 시스템 과부하 및 남용 방지
공격, 과도한 트래픽으로 인한 서비스 장애 방지
서비스 안정성 및 가용성 보장 필수
장점
- 서비스의 과부하 방비, 악의적 공격 최소화, 안정성 향상
단점
- 과도한 제한 시 사용자 경험 저하 가능성, 관리 및 설정의 복잡성
구현 방법
- 요청 횟수 기반 제한 (예: 분당 요청수 제한)
- 토큰 버킷 알고리즘(Token Bucket), 리키 버킷(Leaky Bucket) 알고리즘 적용
- Redis 등 빠른 메모리 기반 저장소 사용해 구현

Rate Limiting Strategies

Throttling

정의: 단기간 과다 요청 시 속도를 제한하거나 요청을 거부하는 방법
장점: 급작스런 트래픽 스파이크 대응 가능
단점: 정상 사용자의 요청도 일시적 차단 가능성

IP Blocking

정의: 특정 IP에서 오는 요청을 차단하거나 제한
장점: 악성 IP로부터 보호 가능
단점: 정상 사용자가 VPN 등을 사용할 경우 차단 위험 존재

Quota Management

정의: 사용자나 앱 별로 명시적 요청 할당량 설정
장점: 서비스 제공자에게 효율적 관리, 비즈니스 모델 연동 가능
단점: 복잡한 사용자 관리 및 부가적 인프라 필요

Observability: Distributed Logging/Tracing

Wings of Freedom — Wed, 27 Aug 2025 15:47:25 +0900

마이크로서비스의 복잡한 종속성을 모니터링하고 관리하기 위한 전략 필요
마이크로서비스로 구성된 시스템의 동작과 성능을 모니터링, 이해, 관리 -> Observability
Distributed Logging
- 여러 서비스 인스턴스 -> 로그 수집, 저장 및 분석
- 시간 경과에 따른 시스템 동작, 패턴, 추세 식별
- 시스템 성능 확인 -> 병목 현상 식별 -> 문제 해결
Distributed Tracing
- 시스템을 통한 요청 흐름 추적 -> 분산 추적 구현
- 장바구니 항목 추가 -> 장바구니 서비스 -> 결제 처리 서비스 -> 제품 카탈로그 서비스 추적

Observability: Elastic Stack

로그 데이터 및 기타 유형의 데이터를 수집, 저장 및 분석하기 위한 오픈 소스 도구
Elasticsearch
- 로그 데이터 및 기타 데이터 저장, 인덱싱
- 분산 검색 및 분석 엔진
Logstash
- 다양한 소스에서 로그 데이터 수집 -> Elasticsearch로 전송
Kibana
- 데이터를 기반으로 대시보드와 시각화, 탐색 도구
Beats
- 로그 데이터를 수집하여 전송 (데이터 전송기 모음)
시간 경과에 따른 시스템 동작 파악 -> 패턴과 추세 식별 -> 문제 해결 유용

Observability: OpenTelemetry + Zipkin

OpenTelemetry
- 원격 측정 데이터, 추적, 메트릭 및 로그 수집
Zipkin
- 마이크로서비스에서 추적 데이터를 수집하고 저장
- 웹 UI를 제공하는 분산 추적 시스템
Zipkin + OpenTelemetry -> 마이크로서비스 분산 추적 (OpenTelemetry SDK)
- 요청이 시스템을 통과할 때 추적 데이터를 수집, 저장, 시각화
- OpenTelemetry SDK에서 수집한 추적 데이터 -> 각 서비스 인스턴스에 통합
- Zipkin 서버로 전송
- Zipkin UI를 사용하여 추적 데이터를 시각화, 분석, 패턴이나 추세 식별

Resilience Patterns

Wings of Freedom — Wed, 27 Aug 2025 15:36:22 +0900

Resilience Patterns

장애가 발생할 것이라고 가정 -> 장애 수용
- 특히 분산 시스템에서 예상치 못한 장애 처리 필요
- 네트워크 또는 컨테이너 장애 시 마이크로서비스는 요청을 다시 시도하기 위한 전략 필요
최악의 시나리오에 대비할 수 있는 장애를 허용(극복) 하는 마이크로서비스 설계
- 단일 마이크로서비스가 실패하거나 잠시 응답하지 못할 수 있음
- 서비스 과부하, 늦은 응답, 네트워크 문제 등
마이크로서비스의 회복성(Resilience) 설계
- 장애에 대한 복원성(회복성)
- 부분적 장애 허용
- 장애가 발생할 것이라고 가정하고 복원성(회복성)을 위한 마이크로서비스를 설계
장애 허용(Fault Tolerance)
- 다운타임이나 데이터 손실 없이 대응
- 장애 후 App을 완전히 작동하는 상태로 되돌림
- 장애를 우아하게 처리 (Graceful shutdown)
회복성(Resilience)
- 마이크로서비스 시스템은 장애 또는 중단하더라도 효과적으로 계속 작동 가능
내결합성(Fault tolerance)
- 일부 구성 요소 내에서 하나 이상의 오류가 발생하는 경우에는 시스템은 정상적으로 작동
서비스 간 통신은 분산되고 많은 내부 또는 외부 네트워크 트래픽이 트랜잭션을 위해 생성
- 모놀리식에 비해 내구성 보장이 어려움
- 서비스 간 통신 필요성과 외부 서비스에 대한 종속성 증가
- 오류가 발생할 가능성이 증가
Resilience Pattern (회복성 패턴)
- 중단 없는 마이크로서비스를 제공
회복성 패턴 종류
- Retry Pattern
- Circuit Breaker Pattern
- Bulkhead Pattern
- Timeout Pattern
- Fallback Pattern

Resilience: Retry Pattern

HTTP, gRPC 등을 사용하는 서비스 간 통신
- 네트워크, 서버 및 물리적 오류가 발생할 수 있음
- Tx의 서비스 중 하나가 500 Error Code 반환 -> Tx이 중단, 오류 반환
- 사용자가 동일한 Tx 다시 시작 -> 정상 작동
마이크로서비스는 일시적인 오류로 인해 실패 가능
- 이러한 오류는 짧은 시간 내에 발생, 이후에 수정 됨
Retry Pattern
- 실패할 경우 작업을 자동으로 재시도
- 마이크로서비스가 자체 수정 -> 스스로를 수정할 시간 허용
- 서비스에 지속적인 장애 발생, 장시간 사용할 수 없는 경우 -> 실패한 요청이 지나치게 많아지게 됨
- Circuit Breaker, Fallback 추가 구현 필요

Resilience: Circuit Breaker Pattern

전자시스템 회로를 보호하기 위해 시스템에 장애가 발생할 경우 더 이상의 부하 전달 중지하는 기능
Circuit Breaker Pattern
- 외부 의존성(종속성)에 대한 장애로부터 보호
- 한 서비스의 장애가 다른 서비스에 연쇄 효과를 미치지 않도록 차단
서비스 간 통신 모니터링 -> 오류 추적
- 시스템의 오류가 특정 임계값(Threshold)을 초과 -> Circuit Breaker가 작동되고(Open) 통신 차단 -> 미리 결정된 오류 메시지 반환
- Circuit Breaker가 열려 있는 동안 통신 트래픽을 계속 모니터링
- 요청된 서비스가 성공적인 결과를 반환하면 Circuit Breaker 종료(Close)

Close(닫힘)
- Circuit Breaker가 닫힘
- 모든 요청이 실행
Open(열림)
- Circuit Breaker가 열림
- 오류가 발생하는 동안 애플리케이션이 작업을 반복적으로 실행하려고 하지 않도록 처리
Half Open(반열림)
- Circuit Breaker는 오류가 계속 발생하는지 확인하기 위해 몇 가지 작업을 실행
- 오류가 발생하면 Circuit Breaker가 열림
- 오류가 발생하지 않으면 Circuit Breaker는 닫힘

Resilience: Bulkhead Pattern

Bulkhead Pattern
- 분산 시스템에서 장애를 격리하는 데 사용
마이크로서비스에서 개별 서비스 인스턴스 또는 서비스 인스턴스 그룹을 서로 격리
- 시스템의 한 부분에서 장애가 발생해도 전체 시스템에 영향을 미치지 않도록 함
- 한 위치에서 서비스를 격기하여 다른 서비스에 영향을 미치지 않도록 함
- 오류 장소를 격리하고 나머지 서비스를 보호
Use-case
- 서비스에 부하가 많고 다른 서비스 인스턴스와 리소스 경합 위험이 있는 경우
- 서비스가 연쇄 장애 위험이 있는 경우
- 다운스트림 서비스를 사용할 수 없게 되거나 성능 문제가 발생하는 경우

Resilience: Timeout Pattern

서비스 응답을 무한정 기다리지 않고 예외 발생
- 서비스 호출이 완료되는 데 예상보다 오래 걸리는 경우 사용
- 최대 시간 제한 설정
- Timeout 오류 발생
마이크로서비스에서 서비스 호출이 완료되는 데 너무 오래 걸리는 것을 방지
특정 서비스가 요청을 완료하는 데 예상보다 오래 걸리는 경우 -> 요청을 취소하고 오류

Resilience: Fallback Pattern

요청이 실패하거나 시간 초과될 경우 대체 동작이나 응답 제공
- 서비스를 사용할 수 없는 경우
- 클라이언트는 캐시 된 버전의 데이터 사용
- 사용자에게 기본 메시지 표시 -> 대체 처리
서비스 호출이 실패하거나 시간 초과될 경우 호출되는 Fallback 함수 정의
- Fallback 함수에서 대체 응답 제공
- 특정 서비스를 사용할 수 없거나 요청을 완료하는데 너무 오래 걸리는 경우
- 오류 메시지 표시 or 나중에 다시 시도할 수 있는 옵션 제공

EDA (Event-Driven Architecture)

Wings of Freedom — Wed, 27 Aug 2025 14:49:08 +0900

Event-Driven Architecture

마이크로서비스는 서로의 API를 직접 호출하는 것 대신
- 이벤트 메시지를 발행(Publish) / 구독(Subscribe) 하여 통신 가능
데이터가 필요할 때 요청 대신 서비스에서 이벤트 소비
이벤트를 통한 서비스 간 비동기 소통
- 느슨한 결합 (Loose Coupling)
분리된 통신 -> 독립적, 서비스간 의존성 최소화, 확장성 및 유연성 향상
실시간 메시징 플랫폼
- 메시지 큐나 이벤트 버스를 사용
- 이벤트가 발생하는 대로 Publish -> Subscribe
- CDC 사용 -> DB 변경 사항 추적 시스템 (실시간 이벤트)
대용량 처리 (이벤트)
- 필요에 따라 이벤트 소비자 추가 -> 수평적 확장 가능
- 이벤트 버스 -> 이벤트를 병렬로 처리, 분배
- 시스템의 다른 서비스들이 서로 간에 충돌 없이 사용 가능
이벤트 스트림 처리
- 실시간으로 이벤트 스트림 캡처/처리
- 데이터의 실시간 처리 -> 분석
이벤트 허브
- 데이터 수집/배포를 위한 중앙 허브 역할
- 마이크로서비스에 스트림 Publish / Subscribe
Publish 된 메시지들에 대한
- 실시간 메시징 플랫폼
- 스트림 처리
- 이벤트 허브
- 일괄 처리
- 데이터 Intelligence

Event-Driven Architecture 장점

이벤트 스트리밍
실시간 처리
대량 이벤트
서비스 분리, 확장성 증가
탄력성

Event-Driven Architecture 단점

복잡성 증가, 이벤트 구동으로 인해 시스템 설계가 더 복잡해짐
디버깅이 어려움
이벤트 게시 프로세스에 대기 시간 추가
분산 트랜잭션 처리 필요
설정 및 유지 관리가 어려움

Distributed Transaction(Saga Pattern, Outbox, CDC)

Wings of Freedom — Wed, 27 Aug 2025 11:22:00 +0900

Saga 디자인 패턴
- 분산 Tx -> 데이터 일관성 관리
- Pub/Sub 패턴
마이크로서비스를 순차적으로 업데이트
- 서비스들의 다음 Tx을 트리거 이벤트로 게시
- 여러 서비스들의 일련의 로컬 Tx -> 전체 실행 Tx 관리
Tx 단계 중 하나가 실패
- Saga 패턴을 통해 Tx을 롤백
- 이전 마이크로서비스에 롤백 이벤트 게시 (보상 트랜잭션)
Choreography / Orchestration - based SAGA

Choreography-based SAGA

Broker를 이용하여 다른 서비스와 통신
- Pub/Sub(게시-구독) 원칙
마이크로서비스가 실시간으로 다른 서비스에 이벤트 게시 -> 분산 + 유연한 방식 제공
각 마이크로서비스
- 자체 로컬 트랜잭션을 실행
- 이벤트 게시 (메시지 브로커 시스템)
- 다른 마이크로서비스에서 로컬 트랜잭션 트리거

Choreography-based SAGA 장점

분산화, 유연성
단일 장애 지점(SPOF)을 피할 수 있음
간단한 워크 플로우
Tx 많지 않은 간단한 경우 적합

Choreography-based SAGA 단점

복잡성 증가
순환 이벤트 소비 위험
분산 시스템의 특정 요구 사항과 제약 조건이 다르기 때문에, 일부 시스템에는 적합하지 않을 수 있음

Orchestration-based SAGA

중앙 Orchestrator 서비스를 사용하여 트랜잭션 구성
- Event를 중앙 Orchestrator가 구독 후 각
- 서비스 호출
- 개별 사가 또는 마이크로서비스를 조정/관리
Orchestrator
- 트랜잭션 시작 -> 각 Saga가 올바른 순서로 단계를 수행 하도록
Saga 중 하나가 단계를 완료하지 못할 경우
- Orchestrator 는 보상 트랜잭션 사용
- 변경 사항 롤백 -> 시스템을 원래 상태로 복원

Orchestration-based SAGA 장점

트랜잭션을 위한 명확하고 중앙 집중화 된 제어/관리 제공
시스템의 이해/디버깅/Tx 추가/수정 용이
많은 단계가 포함된 복잡한 워크플로우에 적합

Orchestration-based SAGA 단점

단일 장애 지점 발생 가능
Orchestrator 다운 시 전체 다운
모든 Tx가 Orchestrator를 거치기 때문에, 시스템에 부하 많이 걸릴 수 있음 (Bottleneck)

Compensating Transaction Pattern

Compensating Transaction Pattern
- SAGA 패턴의 Rollback 프로세스
- 이전에 실행된 Tx의 단계를 역순으로 제공
- 원래 작업의 단계별 실행 결과를 취소
최종적으로 일관된 작업이며 실패할 수 있음
- 시스템은 실패 지점에서 보상 트랜잭션을 재개하고 계속할 수 있어야 함
보상 트랜잭션의 단계
- Idempotent (멱등) 명령으로 정의

Transactional Outbox Pattern

마이크로서비스의 DB에 "Outbox" 테이블 저장
- 이벤트를 안정적으로 게시할 수 있도록 제공
- Outbox 테이블에 모든 이벤트가 포함
단일 트랜잭션으로 DB에 두 개의 별도 데이터 저장
- API가 이벤트 메시지를 직접 게시 X
- 메시지가 동일한 트랜잭션으로 DB 테이블에 저장
하나의 데이터가 관련 DB 테이블과 Outbox 테이블에 동시 저장
- 정의된 시간 간격으로 Message Broker에 이벤트 게시 (Event Bus)
메시지를 트리거한 트랜잭션이 실패
- 마이크로서비스에서 다른 마이크로서비스로 메시지가 안정적으로 전달 가능

CDC - Change Data Capture

CDC
- DB에서 삽입, 업데이트, 삭제 활동 캡처
- 다른 시스템에서 사용할 수 있도록 하는 DB의 데이터에서 발생하는 변경 사항 추적
일반적으로 DB의 Tx 로그를 지속적으로 모니터링
- 변경 사항 확인
- 변경 사항 추출
- 시스템 전파
일괄 처리 기반 데이터 동기화에 의존하지 않음
DB 간 데이터 복제, MSA 시스템 간 데이터 동기화, 실시간 데이터 분석 활성화에 사용

Distributed DB: CockroachDB

CockroachDB는 확장 가능하고, 복원력이 뛰어나며, 사용하기 쉬운 분산 DB 관리 시스템
작업 부하가 증가함에 따라 클러스터에 노드를 추가하여 수평적으로 확장 가능
다중 활성 가용성 및 분산 트랜잭션과 같은 기능을 통해 데이터 일관성 및 강력한 내구성 지원
CDC + Transaction Outbox Pattern
- Built-in CDC

Distributed DB: Azure Cosmos DB

Azure Cosmos DB는 전 세계적으로 분산된 다중 모델 DB 서비스
Document, Key-Value, Column-family, Graph 다양한 DB 모델을 지원
- SQL, MongoDB, Cassandra, Azure Table Storage와 같은 여러 API를 통해 액세스
- 변경 피드 API 사용 -> 데이터 변경 사항에 액세스하고 애플리케이션 처리
CDC를 기본적 지원
- 거의 실시간으로 DB에 적용된 데이터 변경 사항을 추적 -> 다른 시스템에 전파

SAGA + Transactional Outbox + CDC Pattern

장점

DB 무결성 유지 트랜잭션
실시간 동기화
데이터와 최신 상태를 유지
데이터 분리 및 이벤트 전파(Propagate)
마이크로서비스의 확장 및 유지 관리가 더 쉬움

단점

Outbox, CDC 설계로 인해 복잡성 증가
이벤트 게시 프로세스에 지연 시간 추가
데이터베이스의 성능 부담
설정 및 유지 관리가 어려움

CQRS - Command Query Responsibility Segregation

Wings of Freedom — Tue, 26 Aug 2025 18:07:03 +0900

CQRS

DB를 읽기 및 쓰기 작업 분리
- 비효율적인 조인이나 복잡한 쿼리를 피하기 위해 사용
Command
- 데이터 상태를 애플리케이션에 반영/변경
Query
- 복잡한 조인 작업 처리, 결과 반환
애플리케이션 성능 개선
- CQRS
- 이벤트 소싱 패턴

CQRS Level

단계	분리 수준	장점	단점	Usecase
1단계	Controller 및 Service 만 분리	간단한 구조, 구현 난이도 낮음	성능상 큰 장점 없음, 확장성 제한적	소규모, 프로토타입, MVP 프로젝트
2단계	Controller, Service, 데이터 모델 (DB Schema)	읽기 모델을 조회 최적화하여 성능 향상 가능	구현 및 관리 복잡성 증가	중간 규모 프로젝트 (조회 성능 중요)
3단계	Controller, Service, 데이터 모델 (DB Schema), 물리적 DB 분리	읽기/쓰기 성능 및 확장성 극대화	복잡성, 비용, 관리 난이도 증가	대규모, 고성능, 고확장성 필요 프로젝트

Event Sourcing Pattern

Application -> 엔티티의 상태 + 데이터 저장
빈번한 DB 업데이트 작업
- 데이터베이스 성능, 응답성 및 확장성 한계에 부정적인 영향으로 인해 상태관리를 별도 처리
Event Sourcing Pattern
- 데이터의 변경 이력(상태 변화)을 DB(Event Store) 저장
- 상태를 직접 저장하지 않고, 발생한 이벤트들을 저장
- 저장된 이벤트를 재생(Replay)해서 상태 복원
- 최신 데이터 상태만 DB에 저장 X
- 모든 이벤트를 순차적으로 DB에 저장 O
Event Store
- 이벤트 데이터베이스 -> 이벤트 저장소
데이터가 변경될 때마다 새 레코드 생성
- 발생한 이벤트의 순차적 기록
- 기록(저장) 된 이벤트를 재생(Replay)하여 현재 상태 복원
- Replay Events -> 데이터의 최신 상태로 빌드 가능
순차적 이벤트 목록
- Materialized View 생성
- 쿼리를 수행하기 위한 데이터의 최종 상태 사용
- 이벤트를 통한 상태 관리와 복원
이벤트 저장소
- Read DB로 변환
- 메시지 브로커 시스템의 Pub/Sub 패턴 사용

Reference
마이크로서비스 디자인 패턴 완벽 가이드
https://www.inflearn.com/course/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EB%94%94%EC%9E%90%EC%9D%B8%ED%8C%A8%ED%84%B4-msa

Database Sharding Pattern

Wings of Freedom — Tue, 26 Aug 2025 16:20:57 +0900

장점

K8s에 적합 -> 수평적 확장 분산 DB
데이터 분할 -> 수평 및 기능적 데이터 분할
DB Sharding Pattern -> 확장성, 가용성 등

단점

서비스 간 쿼리 -> 복잡한 JOIN에는 작업이 필요함
읽기-쓰기 DB 분리되기 어려움
분산 트랜잭션 관리

Problems

복잡한 JOIN 작업이 있는 크로스 서비스 쿼리
대규모로 읽기 및 쓰기 작업
분산 트랜잭션 관리

Solutions

마이크로서비스 데이터 쿼리 패턴
Materialized View Pattern
CQRS Design Pattern
Event Sourcing Pattern

Horizontal Partitioning

수평 분할 -> 샤딩
- 샤드는 데이터의 특정 하위 집합을 보유
- 파티션 키를 기준으로 테이블 데이터를 수평으로 분할
각 파티션은 별도의 데이터 저장소이지만 모든 파티션은 동일한 스키마를 갖고 있음
- 데이터 요청은 더 많은 서버에 부하를 분산하고 더 많은 성능을 제공
파티션 키는 모든 파티션에 데이터를 분배하는 데 제공
수평 분할의 단점
- 잘못된 파티션 키 설정

Vertical Partitioning

수직 분할은 "행 분할”
각 분할은 데이터베이스의 테이블에 대한 열의 하위 집합을 보유
열에 따라 분할된 데이터는 가장 많이 방문한 열과 다른 서버의 다른 열로 나눌 수 있음
Ex) 거의 변경되지 않는 열과 자주 변경되는 열로 다른 서버에 나눕니다.

Asynchronous Communications

Wings of Freedom — Tue, 26 Aug 2025 15:53:17 +0900

동기 통신 방식 문제점

장시간 실행되어야 하는 작업은 동기 통신으로 처리하기 어려움
여러 마이크로서비스를 호출 -> 지연 시간 증가
성능 ,확장성 및 가용성 문제

장점

새로운 Subscriber 서비스를 쉽게 추가
유연한 확장성 증가
수신된 메시지를 규모에 맞게 배포
Event Driven Microservice

단점

Message Broker의 SPOF(단일 장애 지점)
디버깅이 어려움
FIFO를 위해 별도의 구현 필요
정확히 한 번만 필요한 경우 성능 및 확장성 문제가 발생할 수 있음

Reference

마이크로서비스 디자인 패턴 완벽 가이드https://www.inflearn.com/course/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EB%94%94%EC%9E%90%EC%9D%B8%ED%8C%A8%ED%84%B4-msa

API Gateway Patterns

Wings of Freedom — Tue, 26 Aug 2025 15:32:08 +0900

API gateway patterns
- gateway routing
- gateway aggregation
- gateway offloding pattern
Backend for Frontend pattern
Service Registry / Discovery pattern

Gateway Routing Pattern

단일 Endpoint -> 여러 마이크로서비스로 요청
- Routing, Reverse Proxy
- 각 서비스에 대한 요청을 라우팅하는 Gateway의 Endpoint 필요
Client에서 여러 마이크로서비스 사용할 경우
- 마이크로서비스가 변경되어도 클라이언트의 코드 변경이 필요하지 않음
- Routing만 변경 (오류 수정 용이)
- 클라이언트 코드의 단순화
다양한 API 버전에 대해 Routing 가능

Gateway Aggregation Pattern

클라이언트 로직 수행에 여러 개의 다른 백엔드 마이크로서비스를 호출해야 하는 경우 사용
- 잦은 통신 발생 (Cost 증가)
단일 Endpoint를 노출 -> 여러 마이크로서비스로 요청 집계(Aggregate)
- 여러 백엔드 서비스에 요청을 전송한 다음 집계한 내용을 클라이언트로 전달
클라이언트 애플리케이션에서 복잡한 내부 백엔드 서비스 통신에 대한 추상화

Backend for Frontend pattern

단일 API Gateway -> SPOF
- 단일하고 복잡한 API Gateway는 아키텍처에 병목 현상 발생
특정 Frontend 애플리케이션에 따라 API Gateway 분리
BFF를 위한 여러 API gateway를 생성하고 클라이언트에 따라 경계를 구분
- 사용자 인터페이스에 따라 여러 API Gateway 생성
- 클라이언트 애플리케이션에 내부 마이크로서비스와 연결되는 집중 된 인터페이스 제공
대규모 시스템 -> 여러 API Gateway 노출
- Web / Mobile / Desktop
장점
- 클라이언트 중심 인터페이스
- Frontend 클라이언트 애플리케이션을 위한 집주오하 된 인터페이스
단점
- 지연 시간 증가
- 여러 클라이언트 애플리케이션이 있는 대규모 마이크로서비스에 적합

Reference

Microservice Architecture 통신

Wings of Freedom — Mon, 25 Aug 2025 14:27:26 +0900

MSA 통신 스타일

HTTP, REST, gRPC, GraphQL
- Request
- Response
HTTP, WebSocket
- Push
- Real time
HTTP, AMQP
- Polling (short / long)
Event-Driven Architecture (EDA)
- Publish
- Subscribe

1. Request/Response 통신 방법

HTTP, REST
- 동기식 요청/응답 방식
- 마이크로서비스 API
RESTful API
- HTTP protocol + method
- GET / POST / PUT / DELETE / PATCH
gRPC
- 내부 마이크로서비스 간 통신이 잦을 때
- 고성능 + 낮은 지연 시간
GraphQL
- 요청 시 사용하는 쿼리에 따라 다른 응답
- HTTP 요청 회수 및 응답 사이즈 줄임
- 필요한 데이터 구조 정의 -> 유연성 + 효율성

2. HTTP, WebSocket 기반의 Push + Real time 통신

WebSocket API
채팅 애플리케이션 (one to many)
스트리밍 대시보드 -> 양방향 통신 애플리케이션
클라이언트, 서버 모두 메시지 전송 가능
백엔드 서버는 연결 된 모든 사용자에 데이터 푸시 가능

3. AMQP

Polling (short, long)
일정한 시간 마다 새로 고침 (메일 등)
불필요한 통신 발생 가능
연결을 열고 닫는데 비용이 큼 -> 확장성에 취약

4. EDA

마이크로서비스 간 호출 대신 이벤트 생성
- 비동기 방식
- Message Broker System에서 메시지 소비
AMQP (Advanced Message Queuing Protocol)
- Publish / Subscribe
- Kakfa / RabbitMQ queue

Reference

Microservice Architecture

Wings of Freedom — Mon, 25 Aug 2025 11:02:43 +0900

Microservice Architecture 개요

MSA는 비즈니스 경계(역량)을 중심으로 구축
- 완전히 자동화된 배포 프로세스 + 독립적인 배포
MSA는 잘 정의 된 API를 통해 통신하며, 작고 독립적인 서비스로 분해
- 소규모 팀에 의해 관리
MSA 서비스는 클라우드 네이티브 아키텍처 방식으로 개발
- 독립적으로 배포 가능한 요소로 구성 (느슨한 결합)
MSA는 자체 기술 스택을 가지고 REST API 방식으로 통신
- 비즈니스 역량에 따라 제한된 컨텍스트로 구성
단일 책임 원칙(Single Responsibility Principle)에 따라 서비스의 책임 분리

Microservice Architecture 장점

민첩한 배포
- MSA는 애플리케이션을 더 쉽게 확장하고 빠르게 개발하며, 새로운 기능에 대한 배포 시간을 단축
유연한 확장성
- MSA는 전체 애플리케이션을 확장하지 않고, 하위 서비스를 독립적으로 확장 가능
소규모의 집중된 팀
- MSA의 서비스는 단일 팀에 의해 단일 기능을 개발, 빌드, 테스트 가능하도록 구성
소규모의 분리된 코드 관리
- MSA는 다른 서비스와 코드나 데이터 스토리지를 공유하지 않기 때문에 종속성이 최소화 -> 새로운 기능 추가 용이
CI/CD
- MSA는 CI/CD를 가능하게 하여 새로운 기능에 대해 쉽게 추가 또는 롤백이 가능
다양한 기술 스택
- 소규모 팀에 의한 서비스 개발을 위해 가장 적합한 기술 스택 사용
Resilience & Fault isolation
- MSA는 장애 허용(Fault tolerance)으로 서비스 오류 시 재시도 및 회로 차단 패턴 구현
Data isolation
- MSA 설계에 따라 스토리지의 분리되어, 데이터 변경에 따른 영향을 최소화

Microservice Architecture 단점

Complexity
- 각 서비스는 간단하지만 전체 시스템은 복잡
수십, 수백 개의 서비스들에 대한 배포 및 통신으로 인해 시스템 복잡
- Network latency
서비스 간 통신으로 인해 네트워크 지연 문제 증가
- Development & Testing
여러 서비스로 분산되어 개발
- 모놀리스 방식보다 개발과 테스트가 복잡하고 어려움
Data integrity
- 서비스 별로 고유한 데이터 스토리지를 갖음
- 데이터 일관성에 어려움
Deployment
- 서비스 개수가 늘어나기 때문에 생기는 배포의 어려움
- DevOps 자동화 프로세스 필요
Logging & Monitoring
- 분산 시스템으로 구성된 서비스들의 중앙 집중화 된 로그 필요
- 문제의 원인 파악을 위한 중앙 집중화 된 모니터링 필요
Debugging
- 서비스 별로 분리 된 개발 환경을 갖지 때문에 디버깅이 어려움
제한된 팀 규모, 소규모 팀
- MSA를 처리할 수 있는 팀 부재 -> 서비스 제공 시간 지연
- MSA 자체의 배포 및 관리만 처리하는 소규모 팀

Reference

Modular Monolithic Architecture

Wings of Freedom — Fri, 22 Aug 2025 11:26:46 +0900

Modular Monolithic Architecture 개요

애플리케이션 로직을 모듈별로 분리
- 각 모듈은 독립적이고 고립적, 자체 기능 캡슐화
- 자체 비즈니스 로직, 데이터베이스 스키마를 가짐
- 코드를 독립적인 모듈로 구분
각 모듈은 자체 논리적 분리, 계층적 아키텍처 스타일 또는 Clean Architecture로 구성
- 모듈은 애플리케이션 도메인의 Bounded Context를 나타냄
- 도메인 컨텍스트의 기능을 모듈로 그룹화
모듈 간의 종속성을 줄이고 다른 모듈에 영향을 미치지 않고 모듈을 개발하거나 수정 가능
분리 된 모듈은 나중에 아키텍처를 Refactoring 가능
- 독립적으로 배포, 확장
- 잠재적인 Microservice

Modular Monolithic Architecture 장점

Encapsulation
- 비즈니스 로직이 모듈에 캡슐화 -> 높은 재사용성 제공, 일관 된 데이터, 단순한 Communication pattern
- 모듈에 따른 코드 분리
- 재사용 가능한 코드, 리팩토링이 쉬움
Dependency
- 모듈식 모놀리스 아키텍처를 사용하면 애플리케이션 종속성이 더 체계적이고 직관적
- 개발자는 애플리케이션의 어느 부분에 어떤 종속성이 필요한지 쉽게 평가 가능
Complexity
- 수백 개의 마이크로서비스보다 모듈식 모놀리스를 관리하기가 더 쉬움
- 모듈식 모놀리스는 기본 인프라와 낮은 운영 비용으로 운영 가능
Team
- 개발자가 코드의 여러 부분에서 작업하기가 더 쉬움
- 개발자 팀을 효과적으로 나누고 서로에게 최소한의 영향을 미치는 비즈니스 요구 사항 구현 가능

Modular Monolithic Architecture 단점

Polyglot
- 기술 다양화의 어려움
- Polyglot 기술 스택은 Modular Monolithic Architecture와 함께 사용할 수 없음
- Microservice의 모든 이점을 제공하지 않음
Deployment
- 애플리케이션이 단일 단위 -> 독립적으로 확장 및 배포 불가
- 애플리케이션은 확장성 한계 -> 성능 문제 -> Microservice화 필요

Monolithic Architecture, Modular Monolithic Architecture 패키지 구조 비교

Monolithic Architecture

Modular Monolithic Architecture

Monolithic Architecture

Wings of Freedom — Thu, 21 Aug 2025 11:17:50 +0900

Monolithic Architecture 개요

소프트웨어 개발에 대한 기존 접근 방식
단일 단위로 완전한 애플리케이션 개발
- 대부분의 레거시 애플리케이션
단일 코드베이스 개발
- UI + Biz Layer + Data Layer -> 동일한 코드베이스
- 단일 패키지(jar/war) 파일로 대규모 배포
오랜 된 아키텍처 -> 특정 시나리오에는 여전히 유효
작은 애플리케이션
빌드 / 테스트 / 배포 / 문제 해결 / 수직 확장(Scale Up)
Microservice에 비해 개발이 간단
쉬운 배포 -> 단일 jar/war 파일

Monolithic Architecture 장점

개발이 간편
- 기존 개발팀은 모놀리식 애플리케이션을 개발할 수 있는 올바른 지식과 역량을 갖추고 있음
디버깅 및 테스트가 더 간편
- 디버깅 및 테스트가 훨씬 더 간편
- 단일 코드 기반 -> End-to-End 테스트를 훨씬 더 빠르게 실행 가능
배포 간편
- 여러 배포를 처리할 필요 없이, 파일이나 디렉토리 하나만 배포하는 형태
- 단일 jar/war 파일만 배포되므로 배포가 더 용이

Monolithic Architecture 단점

시간이 지남에 따라 복잡해짐 -> 이해하기 어려움
- 시간이 지남에 따라 크기가 너무 커져서 관리 어려워짐
새로운 변경을 하는 것이 어려움
- 매우 긴밀한 결합으로 인해 복잡한 애플리케이션에서 새로운 변경을 구현하는 것이 더 어려움
확장하기 어려움
- 구성 요소를 독립적으로 확장할 수 없음 -> 전체 애플리케이션을 확장
새로운 기술 도입에 대한 장벽
- 모놀리스에서 발견되는 상호 연결된 종속성 문제

reference

마이크로서비스 디자인 패턴 완벽 가이드

https://www.inflearn.com/course/%EB%A7%88%EC%9D%B4%ED%81%AC%EB%A1%9C%EC%84%9C%EB%B9%84%EC%8A%A4-%EB%94%94%EC%9E%90%EC%9D%B8%ED%8C%A8%ED%84%B4-msa

[Kafka Connect] Connector Rest API 정리

Wings of Freedom — Fri, 16 May 2025 13:53:01 +0900

Connector

connector 목록 조회

curl -X GET "http://localhost:8083/connectors/"

connector 상세 정보 조회

curl -X GET "http://localhost:8083/connectors?expand=status&expand=info"

connector config 조회

GET 으로도 동일하게 동작함

curl -X PUT "http://localhost:8083/connectors/{connector_name}/config

특정 connector 상태 조회

curl -X GET "http://localhost:8083/connectors/{connector_name}/status"

connector 재시작

※ task는 재시작되지 않음

curl -X POST "http://localhost:8083/connectors/{connector_name}/restart"

connector 일시중지 (pause)

비동기 방식이므로 상태 조회시 바로 PAUSE 를 리턴하지 않을 수 있음

curl -X PUT "http://localhost:8083/connectors/{connector_name}/pause"

connector 복귀 (resume)

pause 상태인 connector 를 복귀시킨다.
비동기 방식이므로 상태 조회시 바로 RUNNING을 리턴하지 않을 수 있음

connector 삭제

curl -X DELETE "http://localhost:8083/connectors/{connector_name}

Task

connector의 task 목록 조회

curl -X GET "http://localhost:8083/connectors/{connector_name}/tasks"

connector 의 task 상태 조회

curl -X GET "http://localhost:8083/connectors/{connector_name}/tasks/{task_id}/status"

connector 의 task 재시작

※ connector 가 RUNNING, task 가 FAIL 일 경우 사용

curl -X POST "http://localhost:8083/connectors/{connector_name}/tasks/{task_id}/restart"

Topic

connector topic 조회

curl -X GET "http://localhost:8083/connectors/{connector_name}/topics"

connector topic reset

curl -X PUT "http://localhost:8083/connectors/{connector_name}/topics/reset"

Connector Plugin

Kafka Connector Cluster 에 설치된 모든 plugin 목록 조회

curl -X GET "http://localhost:8083/connector-plugins"

Kafka Connector plgin validate

※ plugin 종류에 따라 필수 field가 다를 수 있음
ex) FileStreamSinkConnector 로 test-topic 에 대해 validate 할 경우

echo '{"connector.class": "org.apache.kafka.connect.file.FileStreamSinkConnector", "tasks.max": "1", "topics": "test-topic"}' | curl -X PUT -d -@ "http://localhost:8083/connector-plugins/FileStreamSinkConnector/config/validate

reference : 공식 Document

IntelliJ "Server's Certificate is not trusted" 메시지 노출 해결

Wings of Freedom — Wed, 5 Feb 2025 13:59:41 +0900

IntelliJ를 회사에서 사용하다 보면

SSL 통신을 할 때, 회사에서는 방화벽 문제로 인해서 Server Certificates 오류가 발생 할 수 있습니다.

"Server's Certificate is not trusted" 메시지가 계속 노출 됩니다.

아래와 같이 해결

File > Settings > Tools > Server Certificates 에서 Accept non-trusted certificates automatically 체크박스 체크

[Git] SSL certificate problem : self signed certificate 오류

Wings of Freedom — Fri, 31 Jan 2025 11:07:23 +0900

회사 업무용 PC에서 인터넷 공인망을 차단하여

SSL certificate problem : self signed certificate

메시지가 노출되었습니다.

원인은

SSL 보안서버 인증서를 구매하여 사용하지 않고, Open SSL 인증서를 사용한 경우 git push시 SSL에러가 발생합니다.

저의 경우는 인터넷을 차단하여 인증기관을 연결하지 못해 메시지 노출되었네요.

이를 해결하기 위해 CA에서 인증하는 절차를 무시하는 방법이 있습니다.

windows 경우 cmd에서, macOs는 terminal에서 아래 명령어를 입력

git config --global http.sslVerify false

명령어를 사용하여 global값을 설정합니다.

.gitignore 정상적으로 작동 안될 때

Wings of Freedom — Thu, 16 Jan 2025 03:14:14 +0900

.gitignore이란 ?

Project에 원하지 않는 파일들을(컴파일 된 파일, .gradle, .idea 등등) git에서 제외시키기 위해 필요한 파일

.gitignore의 파일 위치는 ?

프로젝트 최상단 디렉토리에 위치해야한다. 예를들어 git init 명령어를 실행했던 디렉토리에 .gitignore 폴더가 위치하게 된다.

intellij에서 자동으로 추가되는 .gitignore

HELP.md
.gradle
build/
!gradle/wrapper/gradle-wrapper.jar
!**/src/main/**/build/
!**/src/test/**/build/

### STS ###
.apt_generated
.classpath
.factorypath
.project
.settings
.springBeans
.sts4-cache
bin/
!**/src/main/**/bin/
!**/src/test/**/bin/

### IntelliJ IDEA ###
.idea
*.iws
*.iml
*.ipr
out/
!**/src/main/**/out/
!**/src/test/**/out/

### NetBeans ###
/nbproject/private/
/nbbuild/
/dist/
/nbdist/
/.nb-gradle/

### VS Code ###
.vscode/

근데 .gitignore를 추가했는데 파일들이 제외되지 않는 경우

git에 커밋을 한 후 뒤늦게 .gitignore파일을 생성하였는데 .gradle 파일이 계속해서 제외되지 않는 형상이 발생했다.

해결을 위해 나는 아래의 명령어를 사용해 보았다.

git rm --cached .gradle -r

그래도 .gitignore에서 선언된 파일들이 제외되지 않는다면 캐시를 날리고 .gitignore를 다시 생성하여 push

git rm -r --cached

REST API 사용을 위한 인증 방법 4가지

Wings of Freedom — Tue, 29 Oct 2024 17:48:58 +0900

REST API 사용을 위한 인증 방법 4가지

Stateless 한 REST API 를 사용하기 위해서는 4가지의 인증방법이 있다. Basic Authentication, Token Authentication, API Key & Secret Authentication, OAuth2.0(Open Authorization) 이 그것이다.

1. Basic Authentication

HTTP 표준 사양에 따라 매 요청시 헤더의 Authorization 필드에 아이디와 패스워드를 넘겨주는 방식으로 사용자를 인증하는 방식이다.
이 방식은 보안상 매우 취약하고 탈취가 쉽다.
- 특히 SAP 방식에서는 자바스크립트 코드가 그대로 드러나기 때문에 더 위험하다.

2. API Token Based Authentication

프로세스

API 클라이언트는 사용자의 아이디와 비밀번호로 로그인을 하여 API 토큰을 요청한다.
API 인증서버는 사용자의 아이디와 비밀번호를 바탕으로 사용자를 인증한다.
인증된 사용자에 대해서 유효시간이 정해진 API 토큰을 발급한다.
API 클라이언트는 매 API 호출시마다 해당 토큰을 포함하여 요청한다.
1. API 서버는 토큰이 유효한지 토큰관리서버에 문의하고 유효할 경우에만 API 호출을 허용한다.
2. 유효하지 않으면 다시 토큰을 발급받도록 처리한다.

특징

API Key 방식보다 보안적으로 뛰어나다.
- 아이디와 비밀번호가 노출되지 않으므로 토큰이 탈취당하더라도 사용자의 정보는 안전하다.
- 토큰에는 짧은 유효기간이 있기 때문에 탈취당한 토큰 마저도 일정 시간 이후에는 무효화된다.
  - 보통 토큰에 날자와 시간을 함께 인코딩하여 특정 시간 이후로 사용 불가하게 한다.
Stateless 하다. 서버에서 세션 등 상태를 기억하지 않으므로 클라이언트에서 오는 요청만 처리한다. 클라이언트와 서버가 완전히 때문에 확장성이 높아지게 된다.
- 모바일 어플리케이션은 쿠키나 세션 등의 인증시스템을 사용할 수 없는데, 토큰 인증 방식은 이를 간단하게 해결할 수 있다.
대표적으로 JSON Web Token(JWT)가 있다. key-value 페어로 이루어지고 claims 라고 불린다.

3. API Key & Secret Authentication

프로세스

API 제공자로부터 임의의 문자열을 발급받는다.
API 요청시 해당 문자열을 포함하여 요청한다.
서버는 메시지 내부의 API 키를 읽어서 누가 호출한 API인지를 확인한다.
해당 Key의 인증과 인가에 따라 사용자에게 응답한다.

특징

클라이언트가 API에 접근하기 위해서 API 에 가입하는 과정이 필요하다.
가입하면 API 서버가 Key와 Secret 을 각각의 가입된 클라이언트에게 부여한다. 이 부여된 Secret 으로 클라이언트는 서버에 접근할 수 있다.
구현이 간단하다.
보안상 취약하다.
- 웹, 모바일 등 모든 클라이언트가 같은 API 키를 공유하기 때문에 한번 API 키가 노출되면, 전체 API가 뚫려버린다. 높은 인증이 필요할 때는 권장하지 않는다.
- 통신구간이 암호화가 잘 되어있더라도 Key 가 유출될 경우 대비하기 힘들다.
- 이를 방지하기 위해 주기적으로 key도 업데이트 해야하는 번거로움이 있다.
- 그마저 클라이언트와 서버의 Key 업데이트 싱크가 맞지 않으면 서로 매치가 안되는 등 예기치 못한 상황이 발생할 수도 있다.
- 모든 클라이언트에게 매번 부여하기가 어렵다. 즉, 고정된 키이다.

4. OAuth2.0(Open Authorization)

프로세스

은행에 접근해서 아이디를 제출한다.
은행은 해당 아이디의 리소스 접근 권한이 필요하다고 요청한다.
은행은 다른 권한 제공 업체를 통해 엑세스 토큰을 마이크에게 제공한다.
마이크는 은행에 해당 엑세스 토큰과 함께 아이디를 다시 제공한다.
은행은 해당 토큰과 아이디로 마이크의 접근을 허용한다. 그리고 이를 권한 제공 업체가 보증한다.

특징

API Key 방식이나 API Token 방식에 비해 보안상 안전하다.

참고

출처 : https://wiki.mhson.world/cs/basic-knowledge/rest-api-4

Test 코드에서 @Slf4j 사용하기

Wings of Freedom — Fri, 23 Aug 2024 16:16:37 +0900

일반적으로 스프링 부트로 개발을 할 때 lombok 라이브러리는 거의 필수입니다.

@Slf4j를 쉽게 어노테이션 형식으로 사용합니다.

(@Slf4j는 Simple Logging Facade for Java의 줄임말)

사용법은 간단합니다. 일반 클래스에서는 아래 코드와 같이 사용합니다.

@Slf4j
@RequiredArgsConstructor
@RequestMapping("/v1/api/members")
@RestController
public class MemberController {

    @PostMapping
    public String createMember(@RequestBody @Validated MemberRequest memberRequest) {
        log.info("정보 확인 ->{}", memberRequest);
        return "success";
    }
}

프로젝트 경로에서 test 내부에 테스트 코드를 만들고 일반적인 서버에서 사용하듯 클래스 최상위에 동일하게 작성하면 됩니다.

@Slf4j
@SpringBootTest
class MemberControllerTest {

그런데 기본 세팅에서는 테스트코드에서는 @Slf4j라고 쓴다고 해서 바로 사용할 수 없습니다.

gradle설정이 추가로 필요합니다.

build.gradle 파일에 dependencies 항목에 다음과 같이 추가해야 사용 가능합니다.

testCompileOnly 'org.projectlombok:lombok'
testAnnotationProcessor 'org.projectlombok:lombok'

[JSP, HTML] 소스로 사용자 브라우져 캐시 삭제 또는 초기화하기

Wings of Freedom — Tue, 9 Apr 2024 11:12:41 +0900

화면을 수정했는데, 클라이언트의 브라우져에 캐시가 남아서 이전 화면이 나오는 경우가 있다.
직접 브라우져 설정 들어가서 캐시를 지워달라고 요청 할 수도 있지만, 그게 한두번이 아니게 되니 코드에서 캐시를 지울수 없는지 찾아보았다.
이럴수가...
크게 어렵지도 않지만, html한정으로 이게 꼭 필요한 화면이 아니면 아래 설정은 가급적 안 하는게 좋을 것 같다.

HTML 메타태그 이용하기

    <!-- 1990년 이후 이 페이지의 캐시를 만료시킴. -->
    <meta http-equiv="Expires" content="Mon, 06 Jan 1990 00:00:01 GMT" />

    <!-- 캐시를 바로 만료시킴. -->
    <meta http-equiv="Expires" content="-1" />

    <!-- 페이지 로드시마다 페이지를 캐싱하지 않음. (HTTP 1.0) -->
    <meta http-equiv="Pragma" content="no-cache" />

    <!-- 페이지 로드시마다 페이지를 캐싱하지 않음. (HTTP 1.1) -->
    <meta http-equiv="Cache-Control" content="no-cache" />

JSP, Java 사용시

자바 코드 지만 html과 같음.

    response.setHeader( "Pragma", "no-cache" );
    response.setDateHeader( "Expires", -1 );
    response.setHeader( "Cache-Control", "no-cache" );

JS, CSS 파일 캐시 사용 방지

js나 css등 정적파일도 종종 변경을 해도 캐시문제로 적용이 되지 않는 경우가 많다.
그럴 경우 파일의 url 뒤에 ?timestamp 형태를 넣어준다.

  <link rel="stylesheet" href="/css/common.css?20210512" />
  <script type="text/javascript" src="/js/common.js?20210512"></script>

출처 : https://jeaha.dev/114

[JSP, JSTL] fn function 정리 - 2

Wings of Freedom — Tue, 9 Apr 2024 11:11:02 +0900

jstl 내장함수

JSTL functions은 JSTL에서 제공하는 각종 함수를 사용해서 문자열이나, 컬렉션들을 처리함.
fn태그는 단독으로 사용할 수 없고 EL 표현식 내에서 사용해야함.
like ${fn:length(...)}

jsp 페이지 시작점에 다음 태그로 선언 해줘야 사용 할 수 있음.

  <%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions" %>

boolean contains(String sting, String substring)

string이 substring을 포함하면 return true.

boolean containsIgnoreCase(String string, String substring)

대소문자에 관계없이, string이 substring을 포함하면 return true.

  ${fn:contains("helloworld", "world")} // true

  ${fn:containsIgnoreCase("hello world!", "WoRLd")} // true

boolean startsWith(String string, String prefix)

string이 prefix로 시작하면 return true.

boolean endsWith(String string, String substring)

string이 suffix로 끝나면 return true.

  ${fn:startsWith("hello world!", "ld!")} // false

  ${fn:endsWith("hello world!", "ld!")} // true

String escapeXml(String string)

string에서 XML, HTML의 < >& ' " 문자들을 각각 < > & ' "로 치환하여 리턴.

  <c:out value="${fn:escapeXml('<>')}"/> // &lt;&gt;

int indexOf(String string, String substring)

string에서 substring이 처음으로 나타나는 인덱스 리턴.

  ${fn:indexOf("abcdefg", "f")} // 5

String[] split(String string, String separator)

string 내의 문자열을 separator에 따라 잘라내서 잘려진 문자열들을 배열로 리턴.

String join(String[] strings, String separator)

배열 요소들을 separator를 구분자로 하여 모두 연결해서 리턴.

// 예시를 위한 배열 생성
<c:set var="texts" value="${fn:split('Hi My name is waldo', ' ')}"/>
<c:out value="${fn:join(texts, '-')}"/> // Hi-My-name-is-waldo

int length(Object item)

item이 배열이나 컬렉션이면 요소의 개수를, 문자열이면 문자의 개수를 리턴.

<c:set var="texts" value="${fn:split('Hi My name is waldo', ' ')}"/>

${fn:length(texts)} // 5

${fn:length("123456")} // 6

String replace(String string, String before, String after)

string 내에 있는 before 문자열을 after 문자열로 모두 바꿔서 리턴.

${fn:replace("hi hello", "hello", "hi")} // hi hi

// replace 함수는 HTML에서 공백과 줄바꿈을 표현할 때 사용할 수 있다.
${fn:replace("hell            o          o       ~", " ", "&nbsp;")} // hell            o          o       ~

<% pageContext.setAttribute("enter","\n"); %>
${fn:replace(info.text, enter, '<br/>') // 엔터처리

<% pageContext.setAttribute("enter","\n"); %>
${fn:replace(fn:replace(fn:escapeXml(info.content_txt), enter, '<br/>') , ' ', '&nbsp;')} // 엔터와 공백 처리

String substring(String string, int begin, int end)

string에서 begin 인덱스에서 시작해서 end 인덱스에 끝나는 부분의 문자열을 리턴.

String substringAfter(String string, String substring)

string에서 substring이 나타나는 이후의 부분에 있는 문자열을 리턴.

String substringBefore(String string, String substring)

string에서 substring이 나타나기 이전의 부분에 있는 문자열을 리턴.

${fn:substring(text, 3, 19)} // My name is waldo

${fn:substringAfter(text, "Hi ")} // My name is waldo

${fn:substringBefore(text, "waldo")} // Hi My name is

String toLowerCase(String string)

string을 모두 소문자로 치환.

String toUpperCase(String string)

string을 모두 대문자로 치환.

<c:set var="text" value="Hi My name is waldo"/>

${fn:toLowerCase(text)} // hi my name is waldo

${fn:toUpperCase(text)} // HI MY NAME IS WALDO

String trim(String string)

string 앞뒤의 공백을 모두 제거.

<c:set var="text" value="          blank spcae          "/>
${fn:length(text)}  // 31

<c:set var="text" value="${fn:trim(text)}"/>
${fn:length(text)}  // 11

출처 : https://jeaha.dev/79

[JSP, JSTL] fn function 정리

Wings of Freedom — Tue, 9 Apr 2024 11:08:34 +0900

[JSP, JSTL] fn function 정리

jstl function (jstl fn) 정리

jsp 파일 최 생단에 다음과 같이 jstl functions를 사용하겠다고 선언 해야 함.

  <%@ taglib prefix="fn" uri="http://java.sun.com/jsp/jstl/functions" %>

함수들은 단독으로 사용할 수 없고 EL 표현식과 함께 사용해야 함.

  ${fn:length(list)}
  ${fn:contains(str, str)}

fn:contains(string, substr)

string이 substr을 포함하면 return true

fn:containsIgnoreCase(string, substr)

대소문자 관계없이 string이 substr을 포함하면 return true

fn:startsWith(string, prefix)

string이 prefix로 시작하면 return True

fn:endsWith(string, suffix)

string이 suffix로 끝나면 return True

fn:escapeXml(string)

string에 XML과 HTML에서 < >& ' " 문자들이 있으면, XML엔티티 코드로 바꿔준뒤 문자열 반환

fn:indexOf(string, substr)

string에서 substr이 처음으로 나타나는 인덱스 반환

fn:split(string, separator)

string내의 문자열 separetor에 따라 나눈 배열로 반환

fn:join(array, separator)

array요소들을 separator를 구분자로 하여 연결해서 반환

fn:length(item)

item이 배열이나 컬렉션이면 요소의 개수를 문자열이면 문자의 개수를 반환

fn:replace(string, before, after)

string내에 있는 before 문자열을 after 문자열로 모두 변경해서 반환

fn:substring(string, begin, end)

string에서 begin인덱스에서 시작해서 end인덱스에 끝나는 부분의 문자열 반환

fn:substringAfter(string, substr)

string에서 substr이 나타나는 이후의 문자열 반환

fn:substringBefore(string, substr)

string에서 substr이 나타나는 이전의 문자열 반환

fn:toLowerCase(string)

string을 모두 소문자로 변경 후 리턴

fn:toUpperCase(string)

string을 모두 대문자로 변경 후 리턴

fn:trim(string)

string앞뒤의 공백을 모두 제거한 후 반환

출처 : https://jeaha.dev/71

[JSP, JSTL] forEach 잘 사용하기

Wings of Freedom — Tue, 9 Apr 2024 11:07:13 +0900

[JSP, JSTL] forEach 잘 사용하기

Spring 개발을 하다 보면 jstl 의 forEach 를 많이 사용하게 된다.

간단하지만 varStatus 속성 사용을 잘 하면 보다 편하게 개발할 수 있는것 같아서 남겨본다.

<c:forEach items="${list}" var="item" varStatu="i">
  current (현재 객체)       : ${i.current}<br/>
  index (0부터의 순서)      : ${i.index}<br/>
  count (1부터의 순서)      : ${i.count}<br/>
  first (루프의 처음인가)   : ${i.first}<br/>
  last (루프의 마지막인가)  : ${i.last}<br/>
  begin (루프의 시작값)     : ${i.begin}<br/>
  end (끝값)                : ${i.end}<br/>
  step (증가값)             : ${i.step}<br/>
</c:forEach\>

출처 : https://jeaha.dev/70

[JSP, HTML] 코드로 사용자 브라우저 캐시 삭제

Wings of Freedom — Thu, 21 Mar 2024 17:49:04 +0900

화면을 수정했는데, 클라이언트의 브라우져에 캐시가 남아서 이전 화면이 나오는 경우가 있다.
직접 브라우져 설정 들어가서 캐시를 지워달라고 요청 할 수도 있지만, 그게 한두번이 아니게 되니 코드에서 캐시를 지울수 없는지 찾아보았다.

HTML 메타태그 이용하기

    <!-- 1990년 이후 이 페이지의 캐시를 만료시킴. -->
    <meta http-equiv="Expires" content="Mon, 06 Jan 1990 00:00:01 GMT" />

    <!-- 캐시를 바로 만료시킴. -->
    <meta http-equiv="Expires" content="-1" />

    <!-- 페이지 로드시마다 페이지를 캐싱하지 않음. (HTTP 1.0) -->
    <meta http-equiv="Pragma" content="no-cache" />

    <!-- 페이지 로드시마다 페이지를 캐싱하지 않음. (HTTP 1.1) -->
    <meta http-equiv="Cache-Control" content="no-cache" />

JSP, Java 사용시

자바 코드 지만 html과 같음.

    response.setHeader( "Pragma", "no-cache" );
    response.setDateHeader( "Expires", -1 );
    response.setHeader( "Cache-Control", "no-cache" );

JS, CSS 파일 캐시 사용 방지

js나 css등 정적파일도 종종 변경을 해도 캐시문제로 적용이 되지 않는 경우가 많다.
그럴 경우 파일의 url 뒤에 ?timestamp 형태를 넣어준다.

  <link rel="stylesheet" href="/css/common.css?20210512" />
  <script type="text/javascript" src="/js/common.js?20210512"></script>

출처 : https://jeaha.dev/114

IntelliJ 초기설정

Wings of Freedom — Wed, 20 Mar 2024 18:20:11 +0900

집, 회사, 노트북 인텔리J가 설치가 되어 있지만 모두 세팅이 조금씩 다르다.

세팅을 Export 해보기도 했지만 폰트가 설정이 안되거나 플러그인도 조금씩 에러가 있어서 블로그에 세팅 관련 글을 적어야 겠다고 생각했다.

▣ IntelliJ 프로젝트 SDK 설정

| 필자는 openJDK를 사용하고 있으며 openJDK는 하단의 링크에서 다운로드 받을 수 있다.

▶ File - Project Structure - Project Settings의 Project에서 Project SDK란을 설정하면 된다.

JDK home path가 설정이 안되어서 인텔리j가 JDK 위치를 모르면 Platform Settings에서 추가하면 된다.

< openJDK 다운로드 페이지 이동 >

▣ 개발자 폰트 추천

- D2 Coding

github.com/naver/d2codingfont

naver/d2codingfont

D2 Coding 글꼴. Contribute to naver/d2codingfont development by creating an account on GitHub.

github.com

| 다양한 폰트를 사용해 보았지만 돌고 돌아서 결국 D2 Coding 폰트를 선택하게 되었다.

영어 + 한글 조합에서는 개인적으로 최고라고 생각한다.

▣ 자동 import (추천) - Auto Import

| import를 자동으로 해주지 않을때 설정하면 좋다. 해당 설정을 하게 된다면 자동으로 찾아서 import 해주며, 만약 이름이 같을 경우 자동으로 하지 않고 사람이 직접 선택할 수 있어서 좋다.

▶ Editor - General - Auto Import

Optimize imports on thr fly 체크

▣ 대소문자 가리지 않는 자동완성 설정 (추천) - Code Completion

| 인텔리j 에서는 system이라고 하면 자동완성이 안되고 System이라고 해야 자동완성이 나오는데 대소문자를 구별한다.

생각보다 귀찮기 때문에 대소문자를 구별하지 않게 설정하면 좀 더 개발하기 편하다.

▶ Editor - General - Code Completion

Match case 체크 해제

▣ IntelliJ 한 줄 표시 해체(One-line Methods)

| 초기에 메소드 라인이 1줄이라면 심플하게 표시하기 위해 인텔리J에서 한줄로 표기하는데 익숙하지 않거나 저처럼 그냥 다 보여주는게 좋을 때 해당 옵션을 해제하면 된다.

▶ Setting - Editor - Code Folding

One-line methods 체크 해제

▣ IntelliJ 실행시 최근 프로젝트가 아닌, 프로젝트 목록으로 첫 화면 변경하기

| IntelliJ를 실행하면 처음 세팅은 마지막으로 열었던 프로젝트를 다시 열게 되어 있다.

여러 프로젝트가 있을 경우 불편하기 때문에 프로젝트 목록으로 변경한다.

▶ File - Settings - Appearance & Behavior - System Settings

Reopen projects on startup : 체크 해제

Open project in : Ask

▣ Line별 Commit History - 협업시 강추

| 여러분들이 다른 사람이랑 Git을 함께 사용하고 있을 때 누가 라인을 변경했는지 알고 싶을 때 유용하다.

특히 회사에서 생각보다 잘 사용하고 있다.

* 해당 날짜를 클릭하면 commit history를 보여주기 때문에 누가,언제,무엇을 commit했는지 확인할 수 있다.

~~(추궁도가능하다)~~

▶ Keymap

Version Control Systems > Annotate 우클릭 > Keyboard Shorcut > 키 설정

저는 ctrl + alt + shift + \ 사용중입니다.

▣ IntelliJ 세로줄 없애기(가이드 라인 없애기)

| Setting - Editor - General - Appearance에서

Show hard warp and visual guides(configured in Code Style options) 체크 해제

▶ 만약 가이드라인선은 유지한채 범위를 줄이거나, 늘리고 싶으면

Setting - Editor - Code Style를 120에서 줄이거나 늘리면 된다. 단, Show hard warp and visual guides(configured in Code Style options) 옵션은 체크해야 합니다.

▣ IntelliJ 터미널 Window CMD에서 Git Bash로 변경하기

| 해당 설정을 하는 이유는 개인적으로 리눅스를 많이 사용하다 보니 cmd 명령어에 익숙치 않기 때문도 있지만 Bash 명령어를 사용할 수 있다는 장점도 있습니다.

▶ Settings - Tools - Terminal

Shell path

"C:\Program Files\Git\bin\sh.exe" -login -i

git/bin/sh.exe 파일이 있는 곳을 path로 잡아주면 된다. 기본적으로 경로는 변경하지 않으면 해당 폴더에 가면 sh.exe.가 보일것이다.

출처 : https://adg0609.tistory.com/20

IntelliJ 함수가 한줄로 보일때

Wings of Freedom — Wed, 20 Mar 2024 18:03:03 +0900

IntelliJ 에서 사진처럼 한줄로 보여주는 기능이 있다.
개인적으로 가독성이 떨어져서 별로인데 설정에서 off 할수있다.

Setting > Editor > General > Code Folding > One-line methods 체크 해제

intellij 프로젝트 이름변경

Wings of Freedom — Tue, 30 Jan 2024 15:00:06 +0900

# 프로젝트명 변경
1. [File] > [Project Structure] > [Project] > (Project name) 이름을 변경한다.

2. IntelliJ 를 종료한다.

3. 프로젝트 root 디렉토리로 이동하여 아래 파일을 열어 프로젝트명을 동일하게 수정한다.
/settings.gradle

rootProject.name = 'api-project'

/.idea/.name ( 파일 내용에 프로젝트명과 다르게 저장되어 있다면 수정 )

api-project

4. IntelliJ 를 다시 실행하고 Gradle 프로젝트를 Refresh 한다.

관습적인 추상화 Service와 ServiceImpl 구조에 대해서

Wings of Freedom — Tue, 26 Dec 2023 18:48:57 +0900

스프링에 대해 공부하면서 그리고 프로젝트를 진행해보고 여러 예제 코드들을 접해보면서 느낀 것은 관습적으로 브릿지 패턴을 이용한 추상화를 사용하고 있다는 점입니다.

관습적인 추상화

계층화된 아키텍처인 MVC 패턴을 적용한 대부분의 프로젝트에서는 그 중에서도 Service 계층에서는 MemberService 와 같이 서비스를 인터페이스로 생성하고 MemberServiceImpl 이라는 구현체를 생성해서 사용하는 방식으로 대부분의 설계가 이루어집니다.

토비의 스프링이나 여러 객체지향과 스프링 관련 책들을 보면 이와 같은 패턴으로 설계를 해야하는 이유에 대해서 잘 설명하고 있습니다. 인터페이스와 구현체의 분리를 통해 특정 기술이나 외부환경에 독립적으로 보다 자유로운 확장이 가능해진다는 OCP 원칙에 입각한 분명한 장점이 존재합니다.

https://ko.wikipedia.org/wiki/브릿지_패턴

하지만 실제로 대부분의 프로젝트나 예제 코드를 보면 인터페이스와 구현체 클래스 사이의 관계가 1:1로 구성되어 실질적으로 인터페이스를 사용하는 것에 대한 이점을 전혀가져가지 못함에도 불구하고 관습적으로 이러한 추상화 패턴을 적용하고 있습니다.

이러한 관습적인 추상화의 장점과 단점은 무엇일까요? 맹목적으로 이러한 추상화 방식을 프로젝트에 적용하는 것이 올바른 설계 방법일까요? 이러한 질문들에 초점을 맞추어 한번 고민을 해보았습니다.

관습적인 추상화의 장점과 단점

이러한 추상화 방식은 브릿지 패턴이 가지고 있는 장점과 단점과 같다고 생각해도 무방할 것 같습니다.

앞서 언급했듯이 인터페이스와 구현체 클래스를 분리함으로써 구현체를 독립적으로 확장할 수 있으며, 구현체 클래스를 변경하거나 확장해도 이를 사용하는 클라이언트의 코드에는 영향을 주지 않습니다.

추상화를 통한 구현방식은 객체지향의 특징 중 하나인 다형성과 객체지향의 다섯가지 원칙 중 하나인 OCP 원칙을 가장 잘 실현해주는 설계방식이라고 할 수 있습니다.

https://www.journaldev.com/1491/bridge-design-pattern-java

관습적인 추상화의 많은 장점에도 불구하고 이러한 설계 방식은 구조가 복잡해진다는 단점을 가지고 있습니다. 복잡화된 구조인 만큼 코드를 분석하고 확인하는 과정에서도 인터페이스를 거쳐서 다시 그 인터페이스의 구현체들을 확인하는 단계가 추가되면서 가지는 불편함도 분명 존재할 것 입니다.

그리고 제가 생각했을 때의 가장 큰 단점은 인터페이스와 구현체가 1:1 관계로 이루어지는 설계에서는 이러한 장점들을 잘 살리지 못한다는 것입니다. 그럼에도 불구하고 반드시 관습적인 추상화를 적용해야 할까요?

관습적인 추상화를 통한 설계 방식을 꼭 적용해야 할까?

이와 관련해서는 크게 두 가지 의견으로 나누어지는 것 같습니다. 먼저 이러한 관습적인 추상화를 적용해야 한다는 입장에서의 의견은 토비의 스프링에 잘 나와있습니다.

세상에 변하는 것과 변하지 않는 것이 있지만, 객체지향의 세계에서는 모든 것이 변한다. 여기서 변한다는 것은 오브젝트에 대한 설계와 이를 구현한 코드가 변한다는 의미이다. 소프트웨어 개발에서의 끝이란 개념은 없고 사용자의 비즈니스 프로세스와 그에 따른 요구사항은 끊임없이 바뀌고 발전한다. 그래서 개발자가 객체를 설계할 때 가장 염두에 두어야 할 사항은 미래를 어떻게 대비할 것인가이다.

-토비의 스프링 3.1 1장 중-

책에 잘 나와있는 것 처럼 객체는 변화하며 개발자는 끊임없이 이에 대비해야 합니다. 미래를 위한 설계를 통해 변화에 효과적으로 대처할 수 있다는 것입니다.

그런 점에 있어서 우리가 설계한 인터페이스와 구현체 클래스가 당장에 1:1 관계를 맺고있을지 모르지만 서비스가 커지고 변화함에 따라서 얼마든지 구현체 클래스는 확장될 가능성을 가지고 있습니다. 그렇기 때문에 인터페이스와 구현체를 분리한 설계를 통해 미래의 변화에 유연하게 대처할 수 있어야 한다는 것입니다.

반면에 반대의 입장을 가지고 있는 의견은 LichKing님의 블로그의 글을 참고할 수 있었습니다.

서비스를 인터페이스로 만들었던건 관례로 굳어지게 되었는데 개발은 Transaction Script 형식으로 진행하다 보니까 관례는 관례대로 남고 애초에 그렇게 하자고 했던 이유는 사라져버리게 된 것이다. 그래서 내린 결론은 한 메서드에서 모든 역할을 다하는 이런 절차지향적인 코드에서는 사실 서비스를 인터페이스로 할 필요는 없다는 것이다. 물론 인터페이스를 만들지 말자 보다는 애초에 인터페이스를 만들었던 이유를 잘 살리는 것이 바람직 하다는 것이다.

-LichKing 블로그 중-

사실 반대의 입장이라기 보다는 정확히 그 의미를 잘 알고서 사용해야한다는 의미에 가깝습니다.

"관습적으로 그냥 원래 이렇게 해왔으니까?", "예제에 그냥 이렇게 나와있던데?", "이렇게 하래요" 와 같은 무책임한 말이 아니라 이러한 인터페이스와 구현체를 분리한 설계를 통한 이점들과 이유와 근거에 대해서 설계를 한 개발자 당사자는 명확히 이해하고 있어야 한다는 것입니다.

두 가지 글에서 알 수 있듯이 이러한 추상화 방법이 가지고 있는 장점들은 명확하게 존재합니다. 하지만 대부분이 관습적으로 이를 프로젝트에 적용하면서도 "왜?" 사용하는지에 대한 이유에 대해서 잘 인지하고 있지 못하고 있습니다. 그렇기 떄문에 이러한 추상화를 통한 설계방식을 적용한 이유와 장단점에 대해서 명확히 알고 사용하는 것이 중요할 것 같습니다.

추상화를 통한 설계 방식의 네이밍 컨벤션에 대해서

그렇다면 또 한가지 고민해볼 수 있는 점은 바로 Service 와 ServiceImpl 의 네이밍 컨벤션에 관한 문제입니다. 보통의 경우 인터페이스에는 Service를 그리고 이를 구현한 구현체 클래스에는 ServiceImpl 이라는 접미사를 붙인 네이밍을 사용하거나 접두사에 인터페이스임을 명시하기 위해 I 라는 접두어를 사용하고 있습니다.

과연 이러한 네이밍 방식은 적절한 방법일까요? 우리가 흔히 말하는 읽기 좋은 코드 클린 코드에 부합하는 네이밍 일까요?

Java에서 직접적으로 이러한 설계에 대해 네이밍을 적용하고 있는지 알 수 있는 대표적인 사례로 Collection 프레임워크를 들 수 있습니다.

Collection 프레임워크 중에서 List 의 구조에 대해서 간단하게 살펴보면, List 인터페이스와 이를 구현한 하위 구현체들에는 ArrayListImpl, LinkedListImpl 등이 아니라 ArrayList 와 LinkedList 라는 네이밍으로 표현하고 있는 것을 볼 수 있습니다.

해당 네이밍에서 Impl 을 접미사로 붙여서 사용하는 것은 불필요하고 무의미한 네이밍을 반복해서 사용하고 있을 뿐임을 잘 나타내 주고 있습니다.

사실 이러한 점에 있어서 단순히 클래스 이름을 고유하게 만들기 위해 Impl 을 접미사로 붙이는 것이 전부라면 인터페이스를 갖는 것에 대해 다시 한번 생각해볼 필요가 있는 것 같습니다.

이러한 문제가 발생하는 원인은 인터페이스와 구현체 사이의 1:1 관계에 있습니다. 즉, 인터페이스가 딱히 구현에 있어서 필요하지 않지만 설계 패턴을 만족시키기 위해서 위와 같은 네이밍을 사용하고 있기 때문에 발생하는 문제 입니다.

때문에 어떠한 방법이 옳다라고 딱 잘라서 정의내릴 수는 없지만, 이러한 점들을 고려해서 어떠한 방법으로 네이밍을 하는 것이 더 좋은 방법으로 코드를 작성하는 것인가에 대해서는 고민해볼 필요가 있을 것 같습니다.

프로젝트에 추상화 제대로 적용해봅시다

앞선 내용들을 통해서 프로젝트에 이러한 추상화를 적용하기 전에 고려할 두 가지 숙제가 주어졌습니다.

인터페이스와 구현 클래스가 1:1 관계를 가지고 있는 프로젝트 구조에서 추상화를 적용해야하는가
추상화를 적용한다면 네이밍을 어떻게 가져갈 것인가

이러한 고민들에 있어서 어떻게 프로젝트에 적용하는 것이 스프링을 스프링 답게 사용하면서도 읽기 좋은 코드, 객체지향적 특징을 잘 살릴 수 있는 코드가 될까? 라는 측면에서 답을 찾고자 노력했습니다.

당근마켓이라는 서비스는 일반 사용자도 존재하지만 지역 게시판에 자신의 가게를 홍보할 수 있는 사장님이라는 권한을 가진 사용자도 존재합니다. 떄문에 사용자 서비스는 일반 사용자들에 대한 서비스와 사장님으로 등록된 사용자들에 대한 서비스 등으로 구현을 달리 할 수 있으며, 서비스가 확장됨에 따라서 사용자의 유형도 얼마든지 확장될 가능성이 존재한다고 판단했습니다.

사용자 서비스는 사용자의 유형에 따라서 얼마든지 확장될 가능성을 가지고 있기 때문에 지금의 프로젝트가 1:1 관계를 가지고 있다고 하지만 얼마든지 1:N 관계를 갖는 서비스로 확장될 수 있습니다. 또한 이러한 확장에 있어서 사용자 유형이라는 고유의 특징을 구현체마다 가지고 있기 때문에 다음과 같이 구조를 변경할 수 있을 것 같습니다.

MemberService : 회원 서비스 인터페이스
- GeneralMemberService : 일반 회원 서비스 구현체 클래스
- CeoMemberService : 사장님 회원 서비스 구현체 클래스
- ...

코드에 정답이 존재하는 것은 아닙니다. 물론 제가 적용한 방법보다 좀 더 의미적으로 명확하고 좋은 방법들이 존재할 것입니다. 하지만 이러한 구조로 설계를 변경하면서 기존에 MemberService 와 MemberServiceImpl 로 설계했을 때 보다 누가봐도 충분히 이름만 가지고 동작과 역할이 유추가능한 클래스 이름을 가지고 있으며, 기존에 추상화를 사용함으로써 얻을 수 있는 장점을 그대로 유지할 수 있는 구조로 개선할 수 있게 되었습니다.

K&R, BSD, GNU 코딩스타일

Wings of Freedom — Tue, 26 Dec 2023 18:43:10 +0900

BSD, K&R 코딩 스타일

bsd와 k&r의 가장큰 차이는 중괄호( {} )의 위치입니다.

1. K&R 코딩 스타일

여는 블록을 조건에 한 줄로 같은 행에 배치합니다. 코드 줄 수를 절약하여 한눈에 많은 코드를 작성할 수 있습니다.

BSD 스타일로 작성한 코드를 K&R 스타일로 동일하게 작성해 보겠습니다.

if(조건){
   처리 로직
}

예시)

if(d == 1){	
   if(b == 1){
      처리로직	
   }else{
      처리로직
   }
}

2. BSD 스타일

BSD는 줄간격이 한눈에 들어오지만 단점은 코드가 길어진다는 단점이 있습니다.

if(조건)
{
   처리로직
}

예시)

if(d == 1)
{	
   if(b == 1)
   {
      처리로직	
   }
   else
   {
      처리로직
   }
}

3. GNU 코딩 스타일

블록을 조건문 아래에 작성합니다. 블록이 속한 블록임을 분명히 표시하여 구조가 잘 보입니다. 하지만 들여 쓰기를 많이 해서 처리하기에 수평으로 많은 코드를 작성할 수 없습니다.

위에서 작성한 동일한 코드를 예시로 들어 보겠습니다.

그리고 개인적으로 많은 사람들의 코드를 보아왔지만 이런 스타일로 작성하는 분은 아직 못 봤습니다.

if(조건)
    {
      처리 로직
    }

예시)

if(d == 1)
    {	
      if(b == 1)
         {
           처리로직	
         }
         else
         {
           처리로직
         }
    }

참고 :

https://namu.wiki/w/%EC%BD%94%EB%94%A9%20%EC%8A%A4%ED%83%80%EC%9D%BC

아톰 필수 플러그인 추천

Wings of Freedom — Fri, 22 Dec 2023 15:20:16 +0900

1. atom-beautify

(19.1.8 수정 deprecated 되었습니다)

아톰 필수 플러그인중 하나인 atom-beautify 저기 다운로드 수 보이시죠??

5백만이 넘는 사람이 다운한걸보면 확실히 필수가 맞는것 같아요.

atom-beautify 플러그인은

이름 그대로 이쁘게 만들어주는 플러그인입니다

인덴테이션(indentation)을 예쁘게 만들어줘서 보기좋게 합니다

코딩할때 indentation 깔끔하게 하는건 필수인거 아시죠???

2. auto close-html

3. code-peek

code-peek 플러그인은 함수를 구현하다가 보면 다른

파일에서 함수를 따로 구현할 경우가 있는데요

그럴 경우 함수가 정의되어있는 파일을 자동으로 열어서 보게해줍니다.

4. color-picker

html 태그 이름만 입력해도 자동으로 시작 및 종료 태그를

알아서 붙여주는 플러그인이에요.

5. emmet

html, CSS 파일들을 작성하기 쉽게 해주는 플러그인이에요

웹을 작성한다면 필수로 쓰이는 플러그인이라고 할 수있죠

저는 아직 html이랑 CSS쪽 개발은 해보지 않았지만

우선 깔아두었어요!!

위 처럼 이렇게 밑에 자동완성 기능도 있어서

태그를 쉽게 완성하는걸 볼 수 있어요 완전 편함...

안드로이드 xml 개발때 태그를 썼었는데

아톰이 더 이쁘고 편한것 같네요.

6. highlight-selected

이것도 나름 많은 사람들이 받은 플러그인이에요

간단하지만 있으면 나름 보기 좋아요

현재 자신이 편집하고 잇는 코드의 행을 밝게 보여주는 기능이에요

코딩하다보면서 별로 느끼지 못했을 수도 있지만

이게 없으면 또 이상할거에요.

7. minimap

아톰(atom) 필수 플러그인들 중 하나인 minimap이에요

이름그대로 mimimap을 보여주는 기능이에요

안드로이드 스튜디오에도 있었던 기능인것 같은데

코드가 만약 엄청~~~~길때 지금 코드의 위치가 현재 어디인지

minimap을 통해 확인 할 수 있어요

이렇게 코드를 작성하게 되면 오른쪽에 minimap이 나와서

쉽게 확인 할 수 있어요.

출처 : https://blog.naver.com/wlgh325/221399860316

맥(Mac)에서 모든 창 최소화 하는 방법

Wings of Freedom — Thu, 21 Dec 2023 18:50:25 +0900

Command + Option + H, M

윈도우를 사용할 때는 아주 오래전부터 [윈도우 키 + M]으로 모든 창 최소화를 하여 열려있는 모든 윈도우를 숨겼습니다.

바탕화면에 있는 아이콘을 클릭하기 위해서나 알트탭(Alt + Tab)보다 극단적으로 모든 창을 내리기 위한 수단이었는데
당연히 익숙한 동작이였기에 맥에서도 이러한 기능이 필요했습니다.

그래서 방법을 찾았습니다.

Command + Option 누른 채로 H 누르고 다시 M

정확하게는, cmd+option+h가 전면에 있는 앱을 제외한 나머지 앱을 모두 가리고,

여기에 cmd+m 해서 전면에 있는 앱을 최소화하는 것입니다.

[IntelliJ] Google Java Code Style 적용

Wings of Freedom — Thu, 21 Dec 2023 17:29:09 +0900

1. Code Style(Google Style) 다운로드

https://github.com/google/styleguide 에서 intellij-java-google-style.xml를 다운로드

2. File > Settings(mac : command + , / Windows : Ctrl + Alt + S)

Editor > Code Style > Scheme 편집 > Import Scheme > IntelliJ IDEA code style XML을 선택

3. 다운로드 받은 intellij-java-google-style.xml를 선택

4. Apply 클릭

5. Edittor > Code Style > Java 에서 Tab Size와 Indent를 4로 수정한 후 Apply 버튼을 클릭

5. 적용완료

맥 기준으로 Cmd + Option + L

윈도우 기준으로 Ctrl + Alt+ L

누르면 자동으로 코드 스타일이 정리

macOS에서 java(open jdk) 설치

Wings of Freedom — Mon, 11 Dec 2023 14:06:27 +0900

mac 사용자들은 대부분 homebrew를 통해 jdk를 설치하지만

직접 다운로드하여 설정하는 방법을 알아 보겠습니다.

https://jdk.java.net/archive/

에서 원하는 버전의 jdk를 os에 맞게 다운로드

다운로드 받은 파일의 압축 해제

/Library/Java/JavaVirtualMachines/ 아래에 디렉토리 이동

sudo mv jdk-17.0.2.jdk /Library/Java/JavaVirtualMachines

터미널에서 java -version 명령어를 통해 설치 확인

아래와 같이 출력되면 설치 성공

openjdk version "17.0.2" 2022-01-18
OpenJDK Runtime Environment (build 17.0.2+8-86)
OpenJDK 64-Bit Server VM (build 17.0.2+8-86, mixed mode, sharing)

설치된 jdk 목록 출력

/usr/libexec/java_home -V

설치된 jdk 목록을 확인한 후 원하는 jdk 버전을 아래 명령어를 통해 설정
예시에서는 17.0.2로 설정

export JAVA_HOME=`/usr/libexec/java_home -v 17.0.2`

다시 java -version 을 통해 잘 설정되었는지 확인

잘 되었으면 버전설정 명령어를 $HOME/.bashrc 나 $HOME/.zshrc 등에 작성

[JAVA] 빌더 패턴(Builder Pattern)을 사용해야 하는 이유

Wings of Freedom — Tue, 28 Nov 2023 16:14:20 +0900

1. 빌더 패턴(Builder Pattern)을 사용해야 하는 이유

빌더 패턴 장점

필요한 데이터만 설정할 수 있음
유연성을 확보할 수 있음
가독성을 높일 수 있음
불변성을 확보할 수 있음

1. 필요한 데이터만 설정할 수 있음

예를 들어 User 객체를 생성하는데 age라는 parameter가 필요 없는 상황이라고 가정.
생성자나 정적 메소드를 이용하는 경우라면 우리는 age에 더미 값을 넣어주거나 age가 없는 생성자를 새로 만들어주어야 한다.

// 1. 더미 값
User user = new User("테스트", 0, 181, 121);

// 2. 생성자 또는 정적 메소드를 추가하는 방법
@NoArgsConstructor
@AllArgsConstrctor
public class User{
	private String name;
    private int age;
    private int height;
    private int iq;
    
    public User(String name, int height, int iq){
    	this.name = name;
        this.height = height;
        this.iq = iq;
    }
    
    public User static of(String name, int height, int iq){
    	return new User(name, 0, 181, 121);
    }
}

이러한 작업이 한두번이면 괜찮지만 반복적인 경우 시간 낭비로 이어지게 된다. 하지만 빌더를 이용하면 동적으로 이를 처리할 수 있다.

User user = User.builder()
			.name("테스트")
            .heihgt(181)
            .iq(121).build();

그리고 이렇게 필요한 데이터만 설정할 수 있는 빌더의 장점은 생성자 또는 정적 메소드와 비교하여 테스트용 객체를 생성할 때 용이하게 해주고 불필요한 코드의 양을 줄이는 등의 이점을 안겨준다.

2. 유연성을 확보할 수 있음

예를 들어 User 클래스에 몸무게를 나타내는 새로운 변수 weight를 추가해야 한다고 하자. 하지만 이미 생성자로 객체를 만드는 코드가 있다고 가정

// ASIS
User user = new User("테스트", 19, 181, 121);

// TOBE
User user = new User("테스트", 19, 181, 121, 79);

그러면 우리는 새롭게 추가되는 변수 때문에 기존의 모든 코드를 수정해야 하는 상황에 직면하게 된다. 하지만 빌더 패턴을 이용하면 새로운 변수가 추가되는 등의 상황에 직면하여도 기존의 코드에 영향을 주지 않을 수 있다.

3. 가독성을 높일 수 있음

빌더 패턴을 사용하면 매개변수가 많아져도 가독성을 높일 수 있다. 생성자로 객체를 생성하는 경우에는 매개변수가 많아질수록 코드 리딩이 급격하게 떨어진다.

User user = new User("테스트", 19, 181, 121);

19, 181, 121이 무엇을 의미하는지 바로 파악하기 힘들고 파라미터의 개수가 많아질수록 코드를 읽기 더 힘들어진다. 하지만 다음과 같이 빌더 패턴을 적용하면 가독성을 높일 수 있고 직관적인 데이터를 파악할 수 있다.

User user = User.builder()
			.name("테스트")
            .age(19)
            .height(181)
            .iq(121).build();

4. 불변성을 확보할 수 있음

많은 개발자들이 수정자 패턴(Setter)를 흔히 사용한다. 하지만 Setter를 구현하다는 것은 불필요하게 확장 가능성을 열어두는 것이다. 이는 Open-Closed 법칙에 위배되고 불필요한 코드 리딩 등을 유발한다. 그렇기 때문에 클래스 변수를 final로 선언하고 객체의 생성은 빌더에 맡기는 것이 좋다.

@RequiredArgsConstructor
@Builder
public class User{
	private final String name;
    private final int age;
    private final int height;
    private final int iq;
}

출처 : https://velog.io/@bey1548/JAVA-%EB%B9%8C%EB%8D%94-%ED%8C%A8%ED%84%B4Builder-Pattern%EC%9D%84-%EC%82%AC%EC%9A%A9%ED%95%B4%EC%95%BC-%ED%95%98%EB%8A%94-%EC%9D%B4%EC%9C%A0

git 명령어

Wings of Freedom — Tue, 28 Nov 2023 11:00:02 +0900

용어

Committed: 데이터가 로컬 데이터베이스에 안전하게 저장됐다는 것을 의미
Modified: 수정한 데이터를 아직 로컬 데이터베이스에 커밋하지 않은 것을 의미
Staged: 수정한 파일을 곧 커밋한 것이라고 표시한 상태를 의미

설정

설정 정보는 3가지 형태로 관리가 되며, 우선순위는 local > global > system 순입니다.

system: /etc/gitconfig 파일에 저장되며 git config --system 명령으로 수정 가능
global: ~/.gitconfig, ~/.config/git/config 파일에 저장되며 git config --global 명령으로 수정 가능
local: 프로젝트 .git/config 파일에 저장되며 git config --local 명령으로 수정 가능

Git은 Commit을 할때 사용자 정보를 추가 합니다. 다음 명령으로 사용자 정보를 변경할 수 있습니다.

git config --global user.name "{이름}"
git config --global user.email "{이메일}"

상태

git status: 파일 상태 확인.- --ignored 옵션을 이용해서 제외된 파일 확인 가능
git status -s: 파일 상태를 간략히 표시

로그

git log: commit 로그를 확인 합니다.
git log --oneline --graph: commit 정보를 1줄로 표현하고, 커밋 그래프를 보여줍니다.

비교

git diff: Committed 와 Modified 상태를 비교 합니다.
git diff --cached: Committed와 Staged 상태를 비교 합니다.

병합

git merge {Branch Name}
- feat-forward merge: 서로 다른 브랜치중 1개가 다른 브랜치 base와 같을때 발생하며 별다른 커밋이 생성되지 않고 단지 브랜치 위치만 변경한다.
- 3-way merge: 서로 다른 브랜치가 공통된 커밋(base)가 있으며 공통된 커밋으로 부터 각자 커밋을 생성하였을 때 발생한다. 커밋 후에는 새로운 브랜치가 생성이 되고 자동 병합을 진행한다. 자동 병합이 실패한 변경에 내용에는 충돌(conflict)이 발생을 하며, 수동으로 수정을 한 후에 다시 커밋을 해야 한다.

cherry-pick

다른 브랜치 커밋 이력중 특정 커밋의 변경 내용을 가져와 현재 커밋에 추가 합니다.

git cherry-pick {commit ... }

stash

진행하고 있는 업무를 commit 없이 잠시 스택에 임시적으로 저장하여 다른 브랜치에서 작업을 할 수 있도록 합니다.

git stash: 작업 내용은 스택에 넣어 임시 저장 한다
git stash list: stash 목록을 확인한다
git stash apply {stash 이름}: 스택에 있는 작업을 가져와 적용한다.
git stash drop {stash 이름}: 스택에 저장되어 있는 작업 내역을 삭제 합니다.

Rebase

두 브랜치를 합치는 방법으로 이름에서 알 수 있듯이 두 브랜치의 공통 커밋(base)부터 작업 브랜치 까지 변경 내용을 기록하여 대상 브랜치에 동일한 순서대로 적용하는 방법 입니다.

git rebase {branch name}
git rebase -i {branch name}

Bisect

버그를 검색하는 방법으로 이진 탐색으로 오류가 있는 커밋을 찾습니다.

git bisect start: 이진 탐색을 시작 합니다.
git bisect bad: 이동한 커밋에 버그가 있을 경우 사용하는 명령입니다. 이후 찾을 커밋이 없을 경우 .. is first bad commit 메시지를 노출한다.
git bisect good: 이동한 커밋에 버그가 없을 경우 사용하는 명령입니다.
git bisect reset: 이진 탐색을 종료하고 start 명령을 사용한 커밋으로 이동합니다.

Blame

특정 파일에 줄단위로 수정자 정보를 노출 합니다.

git blame

[GitHub] GitHub Pages 사용하기

Wings of Freedom — Thu, 23 Nov 2023 18:10:38 +0900

들어가기 전

GitHub Pages : github를 활용하여 정적(jpg, html과 같은) 파일을 서비스하는 방법

repository 생성

루트 페이지로 생성시
- repository 이름 : <username>.github.io
- Root URL : http://<username>.github.io
하위 프로젝트로 생성시
- repository 이름 : <프로젝트명>
- Root URL : http://<username>.github.io/<프로젝트명>

GitHub Pages 활성화

프로젝트 > Settings
GitHub Pages > Source : 서비스할 브랜치를 지정하면 자동으로 활성화

서비스할 정적 파일 추가

프로젝트 루트에 index.html 파일 추가

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="UTF-8">
    <title>GitHub Pages</title>
</head>
<body>
    Hello World
</body>
</html>

페이지 접속 및 확인

루트 페이지로 생성한 경우 : http://<username>.github.io/index.html
하위 프로젝트로 생성한 경우 : http://<username>.github.io/<프로젝트명>/index.html

참고

https://dreamgonfly.github.io/2018/01/27/jekyll-remote-theme.html

출처 : https://sg-choi.tistory.com/242

[백준허브] 백준, 프로그래머스 문제 GitHub 로 자동 커밋

Wings of Freedom — Wed, 18 Oct 2023 19:21:18 +0900

백준허브는 Leetcode의 제출 코드를 자동 푸시해주는 LeetHub라는 프로젝트를 포크하여 만든 익스텐션으로, 백준, 프로그래머스, SWEA 문제를 해결하면 등록한 Github Repository에 자동으로 코드와 문제 요약을 푸시합니다.

백준허브는 내가 푼 문제가 정답일 경우 해당 코드뿐만 아니라 성능과 메모리, 구체적으로 어떤 문제였는지 까지 같이 커밋합니다.

1. 크롬 확장 프로그램 설치

크롬 웹스토어에서 백준허브 확장 프로그램을 설치합니다.

https://chrome.google.com/webstore/detail/%EB%B0%B1%EC%A4%80%ED%97%88%EB%B8%8Cbaekjoonhub/ccammcjdkpgjmcpijpahlehmapgmphmk?hl=ko

2. 깃허브 연동

크롬 확장 프로그램에서 백준허브 아이콘을 눌러 Authenticate 버튼을 클릭하여 깃허브 연동을 진행합니다.

3. 코딩테스트 문제(알고리즘) 레파지토리 생성

Pick an Option에서 Create a new Private Repository를 선택하였고, 새로운 레파지토리를 생성하였습니다.

Get Started 버튼을 클릭하여 시작

위와 같은 화면이 보인다면 repository가 생성되었고, 백준허브 연동이 최종적으로 완료

4. 코딩테스트 시작

프로그래머스에서 문제를 풀고 제출한 답이 정답일 경우, 위와 같은 알림창에서 초록색 V가 뜨는 것을 확인 가능합니다.

위와 같이 초록색 체크가 뜬다면 GitHub 커밋이 완료되었다는 뜻입니다.

프로그래머스에서 문제를 풀었을 경우 프로그래머스 폴더에, 백준에서 풀었을 경우 백준 폴더가 별도 생성되고 각 문제를 클릭해 보면 작성한 정답과 함께 문제, 성능, 소요 시간 등을 commit message에 입력되었습니다.

플레이 프레임워크 2.0 소개

Wings of Freedom — Tue, 10 Oct 2023 17:06:17 +0900

들어 있는 내용

Play 2.0을 소개합니다.
비동기 방식의 프로그래밍을 위해 만들었어요!
타입 안전성을 중요하게 여깁니다.
자바와 스칼라를 네이티브 방식으로 지원합니다.
강력한 빌드 시스템을 제공합니다!
데이터 저장과 모델 통합

Play 2.0를 소개합니다.

2007년부터 자바 웹 어플리케이션 개발을 쉽게 만들기 위해 연구해 와습니다.

플레이 프레임워크는 Zenexity의 내부 프로젝트로 개발하기 시작했습니다.
플레이 프레임워크는 우리가 웹 프로젝트를 수행하는 방식에 영향을 많이 받았습니다.

우리의 웹프로젝트 수행방식의 특성에는 다음과 같은 것이 있습니다 :

개발자의 생산성을 중요시하고,
웹 아키텍쳐를 존중하며,
JEE에서 사용하는 최고의 관행을 깨뜨리는 등 패키징에 관해 완전히 새로운 접근법을 시도합니다.

2009년에 우리는 이러한 생각들을 커뮤니티에 공유하기로 결심했고, 오픈소스 프로젝트로 진행하기 시작했어요.

커뮤니티에서는 즉각적으로 매우 긍정적인 반응이 왔고, 프로젝트는 박차를 가하게 되었어요.

플레이 프레임워크를 개발한 지 어느덧 2년이 되어가는 지금, 버전도 여러 개가 있고, 4000명의 회원이 참여하는 활기찬 커뮤니티도 생겼습니다. 그리고 제작에 사용되는 어플리케이션의 수는 전 세계적으로 계속 증가하고 있어요.

프로젝트를 전 세계에 공개하자 매우 많은 피드백을 받았습니다.
또한 새로운 사용예에 대해서도 알게 되었습니다.
새로운 사용예에 따르면 새로운 기능이 추가로 필요하기도 하고, 몰랐던 버그도 알게 되었습니다. 이러한 기능이나 버그는 초기에 설계할 당시에는 고려하지 않았던 부분들이죠.

2년동안 플레이 프레임워크를 오픈소스 프로젝트로 작업하는 동안, 우리는 이런 종류의 이슈들을 처리해왔고, 다양한 사용 시나리오를 위해 새로운 기능들을 통합해 왔습니다.

프로젝트가 커지면서, 우리는 커뮤니티로부터, 그리고 그간의 경험으로부터 많은 것을 배웠습니다. 더욱 복잡하고 다양한 프로젝트에 플레이 프레임워크를 사용하면서 말이죠.

그동안에 웹 기술은 지속적으로 발달해 왔습니다. 웹은 모든 어플리케이션의 핵심이 되었어요.
HTML, CSS 와 자바스크립트 기술은 빠르게 발전했습니다.

서버사이드 프레임워크가 따라잡기에 거의 불가능할 정도였죠.

웹 아키텍쳐는 실시간 처리를 하는 방향으로 빠르게 바뀌고 있습니다.
또한 요즘에는 프로젝트에 대한 요구사항이 많아져서, 데이터 저장기술로 SQL만 쓴다는 것은 옛날 얘기가 되었습니다.

프로그래밍 언어부문에서도 실로 놀라운 변화가 있었습니다. Scala 를 포함한 몇몇 JVM 언어가 인기를 얻고 있죠.

이처럼 새로운 시대가 왔기 때문에, 이에 걸맞는 새로운 웹 프레임워크인 플레이 2.0을 만들었습니다.

비동기방식의 프로그래밍을 위해 만들었어요!

오늘날 웹 어플리케이션에서는 병렬 실시간 데이터를 더욱더 많이 다룹니다.
그래서 웹 프레임워크에서는 비동기 HTTP 프로그래밍 모델을 전폭 지원해주어야 합니다.

‘플레이’는 원래 고전적인 웹 어플리케이션을 다루도록 설계되었어요. 고전적인 웹 어플리케이션에서는 HTTP 요청이 대부분 잠깐 동안만 유지되었었죠.

하지만 요즘에 이벤트 모델은 지속적인 연결을 사용하는 방식을 씁니다. Comet과 롱 폴링, 웹 소켓 등에서요.

플레이 2.0은 모든 요청이 오랫동안 지속된다는 가정 하에 처음부터 다시 개발되었습니다.

그러나 그것이 전부가 아니었습니다. 우리는 오랫동안 실행되는 작업을 스케쥴하고 실행하기 위한 강력한 방법이 필요했습니다.

액터(Actor)에 기반한 모델은 고도의 병렬 시스템을 다루는데 있어서 오늘날 의심할 여지없는 최고의 모델입니다.

플레이 2.0은 플레이로 만든 어플리케이션을 위해서 네이티브하게 Akka를 지원합니다. 이러한 Akka의 지원은 고도의 분산화된 시스템을 만들수 있게 해줍니다.

플레이 프레임워크는 타입 안전성을 중요하게 여깁니다.

(역자주 : 타입 안정성 - 타입의 오류를 막거나 방지하는 정도 http://en.wikipedia.org/wiki/Type_safety)

플레이 어플리케이션을 작성할 때 정적 프로그래밍 언어를 사용하면 한 가지 장점이 있는데요, 컴파일러가 코드의 자료형을 검사할 수 있다는 것입니다. (역자주: 정적 프로그래밍 언어: 컴파일 단계에서 자료형에 대한 검사를 수행하는 언어)

정적 프로그래밍 언어를 사용하면, 개발 진행 초기에 실수를 발견할 수 있어서 좋습니다. 뿐만 아니라 개발자들이 많이 참여하는 대형 프로젝트를 수행하기가 훨씬 수월합니다.

플레이 2.0에서 Scala를 추가적으로 지원하면서 컴파일러가 자료형을 더 확실하게 검사해준다는 장점이 분명 있습니다. 하지만 이것만으로는 충분하지 않죠.

플레이 1.x에서 템플릿 시스템은 동적이었습니다. 그리고 그루비 언어 기반이었기 때문에 컴파일러가 해줄 수 있는 게 별로 없었어요. (역자주 : Groovy Language : http://groovy.codehaus.org)

결과적으로 템플릿에서의 오류는 런타임시에만 발견될 뿐입니다.

마찬가지로 glue code with controllers의 오류도 런타임시에야 발견됩니다. (역자주: * Glue Code : http://en.wikipedia.org/wiki/Glue_code)

우리는 버전 2.0에서는 플레이가 대부분의 코드를 컴파일 타임에 검사할 수 있도록 하는 아이디어를 꼭 적용하고 싶었습니다.

그래서 플레이 어플리케이션을 위해서 Scala에 기반한 템플릿 엔진을 기본으로 사용하기로 했습니다. 심지어 자바를 주 언어로 사용하는 개발자들에게까지 말이죠.

그렇다고 해서 플레이 2.0에서 템플릿을 작성하려면 Scala 전문가가 되어야 하는 것은 아닙니다. 마치, 플레이 1.x에서 템플릿을 작성하기 위해 Groovy를 잘 알 필요는 없었던 것처럼 말이죠.

템플릿에서는, 여러분의 오브젝트 그래프(object graph)를 탐색하는데에 주로 스칼라가 쓰입니다. 자바의 문법과 매우 비슷하게 관련된 정보를 보여주죠.

하지만, advanced templates abstraction을 쓰는 데에, 스칼라의 강력함을 제대로 사용하려면, 스칼라가 템플릿 엔진에 얼마나 완벽한지 얼른 이해하시는 게 좋을 거에요. Scala is expression-oriented and functional.

템플릿 엔진의 경우에만 그런게 아닙니다.
routing system도 자료형을 모두 체크해주는 방식으로 돌아갑니다.

플레이 2.0에서는 경로 기술한 것을 확인해서, 모든 것이 일관적인지, reverse routing part까지도 일관적인지를 검증합니다.

이처럼 플레이 2.0에서 완전하게 컴파일 해주기 때문에 생겨나는 부수적인 이점이 있는데요, 템플릿과 경로 파일(route files)을 더욱 쉽게 패키지하고 재사용할 수 있다는 점입니다.

이런 부분 때문에 실행(run-time)할 때의 성능도 훨씬 더 좋아집니다.

자바와 스칼라를 네이티브 방식으로 지원(native support)합니다.

플레이 프레임워크 프로젝트 초기에 이미, 플레이 어플리케이션을 작성하는 언어로 스칼라를 사용하는 것에 대해서 고려하였습니다.

처음에는 스칼라를 외부 모듈로 사용했습니다. 이렇게 하면 프레임워크 전체에 영향을 주지 않으면서도 자유롭게 실험해볼 수 있었죠.

스칼라를 자바기반 프레임워크에 제대로 통합하는 것은 쉬운 일이 아닙니다.

스칼라가 자바와 호환성이 좋으니까, 자바 문법대신 스칼라의 문법을 사용해서 시험삼아 시도를 해볼 순 있겠죠.

하지만, 이것은 언어를 사용하는 최적의 방법은 분명 아닙니다.

스칼라는 진정한 객체기반언어와 함수적 언어의그래밍의 특징을 모두 가지고 있습니다.

스칼라의 힘을 극대화하려면 프레임워크 API를 거의 모두 다시 생각해봐야합니다.

얼마 지나지 않아서 별도의 모듈로 제공되는 Scala 지원을 갖고 할 수 있는 것에는 한계가 있다는 것을 알게 되었습니다.

Play 1.x 버전 때에는 자바 리플렉션 API와 바이트코드 조작(byte code manipulation)에 심하게 의존했습니다. 이때 설계한 방식 때문에, Play 내부의 핵심적인 부분들을 뒤집어어 엎어야만 진행할 수 있었습니다.

(역자주: Java Reflection API는 임의의 자바 클래스를 읽어 들이고 조사하고 실행시킬 수 있는 방법을 제공하는 API. 어떤 클래스를 이용할 지 개발 시점에는 알 필요가 없으므로, 임의의 코드를 실행해야 하는 프레임워크나 개발 및 테스트 도구를 개발할 때 유용하나, 성능이 떨어지고 보안상 문제를 초래할 수 있음

(역자주 : 바이트코드조작은 바이트코드로 컴파일된 자바 클래스를 실행시간에 직접 조작하는 것)

한편, 우리는 스칼라 모듈 용으로 멋진 컴포넌트를 몇 개 만들었습니다. 이를테면, 자료형을 자동으로 검사해주는 템플릿 엔진(type-safe template engine)을 새로 만들었고요, SQL 엑세스 콤포넌트인 Anorm을 완전히 새로이 만들었어요.

그래서 우리는 이렇게 판단했습니다. 플레이 프레임워크 내에서 스칼라의 강력함을 제대로 활용하기 위해서는, 별도의 모듈로 스칼라를 지원하는게 아니라, 플레이 2.0의 핵심으로서 지원해야 한다고요. 그래서 플레이 2.0을 설계할 때, 프로그래밍 언어로서 스칼라를 네이티브 방식으로 지원하도록 설계하였습니다. (역자주 : 네이티브 방식 지원 : 인터프리터나 컨버터를 사용하지 않고 스칼라 언어를 그대로 사용할 수 있도록 지원하는 것)

한편, 플레이 2.0에서 자바를 덜 지원한다는 의미는 절대 아닙니다. 오히려 그 반대죠.

자바 개발자가 플레이 2.0의 빌드를 사용하면, 개발을 할 때 새로운 경험을 하실 수 있습니다.

자바의 장점들을 모두 고려한 진정한 자바 API를 사용할 수 있습니다.

강력한 빌드 시스템을 제공합니다!

플레이 프로젝트를 시작하면서, 플레이 애플리케이션 실행 및 컴파일 그리고 배포를 하기 위한 새로운 방식을 선택하였습니다.

이러한 방식은 처음에는 난해하게 보일 수도 있습니다.
히지만 표준 서블릿 API가 아닌 비동기 HTTP API를 제공하는데 있어서 이러한 방식이 꼭 필요했습니다. 또한 실시간 컴파일을 통해 피드백 주기를 짧게 하기 위해서도 필요했습니다. 그리고 개발하는 동안 소스 코드를 새로 불러오는 것을 제공하기 위해서도 필요했습니다. 마지막으로 새로운 패키징 방식을 추진하기 위해서도 필요한 선택이었습니다.

그 결과, 표준 JEE 규약을 따르도록 플레이를 만들기가 어려웠습니다.

오늘날에는 컨테이너 없이 배포한다는 아이디어가 자바 세상에서 점점 더 받아 들여지고 있습니다.

이렇게 설계한 덕분에 플레이 프레임워크는 Heroku 같은 플랫폼에서 네이티브한 방식으로 돌아갈 수 있었습니다. Heroku는 신축적인 PaaS 플램폿에 자바 어플리케이션을 배포하는 것의 미래를 감안한 모델을 도입하였고요.

그러나 기존의 자바 빌드 시스템은 유연하지 않아서, 이런 새로운 접근 방법을 지원하지 못했습니다.

플레이 어플리케이션을 쉽게 실행하고 배포할 수 있도록, 플레이 1.x에서는 파이썬 스크립트 모음(collection)을 제작해서 빌드와 배포작업을 하도록 했습니다.

한편, 기업의 프로젝트처럼 큰 규모의 프로젝트를 진행할 때 플레이를 사용하는 개발자들은 좀 난처해졌죠. 왜냐하면 기업용 프로젝트에서는 빌드 프로세스를 조정할 수 있어야 하고(build process customization), 회사에서 기존에 쓰는 빌드 시스템하고 통합도 할 수 있어야 하거든요.

플레이 1.x에서 제공하는 파이썬 스크립트는 모든 기능이 다 갖춰진 빌드 시스템(fully-featured build system)하고는 거리가 멉니다. 그리고 조정(customize)하기에도 쉽지 않고요.

그래서 플레이 2.0에서는 좀 더 강력한 빌드 시스템을 제공하기로 했습니다..

우리에게는 현대적인 빌드 도구가 필요했습니다. 현대적인 빌드 도구는 플레이의 원래방식을 지원해줄 수 있도록 유연해야 하고, 자바와 스칼라 프로젝트를 빌드할 수도 있어야 했습니다. 그래서 우리는 플레이 2.0에 sbt를 통합시키기로 결정하였습니다.

하지만 플레이 빌드가 간편하다는 이유로 만족하시는 기존의 플레이 유저 분들은, 이 결정 때문에 겁내시지 않아도 됩니다.

우리는 이전과 같은 단순한 플레이 생성, 실행, 시작 경험을 확장된 모델의 위에 영향을 받도록 하였습니다다. 플레이 2.0에는 미리 설정된 빌드 스크립트가 포함되어 있는데요, 대부분의 사용자들에게는 아주 매끄럽게 작동합니다.

반면에 어플리케이션을 빌드하고 배포하는 방법을 바꿔야 하는 경우에는, 플레이 프로젝트가 sbt 프로젝트라는 사실이 유용할 것입니다. 빌드하고 배포하는 방법을 커스터마이징할 수 있기 때문입니다.

이러한 사실은 메이븐 프로젝트와 특별히 더 나은 통합을 할 수 있다는 것을 뜻합니다. 어떠한 저장소에도 간단히 JAR 파일들을 패키징하고 배포할 수 있는 능력과 배포 시점에 의존적인 프로젝트를 컴파일하고 다시 로딩할 수 있는 능력에 있어서 말입니다.

데이터저장과 모델 통합

‘데이터 저장’이라고 하면 예전에는 ‘SQL 데이터베이스’를 떠올리는 게 당연했는데요, 최근에는 새롭고 흥미로운 데이터 저장 모델이 인기를 얻고 있습니다. 이들은 여러 가지 가능한 상황에 적절한 다양한 속성을 각기 제공합니다.

그래서 플레이 같은 웹프레임워크로서는 개발자들이 어떤 종류의 데이터 저장방식(데이터베이스)을 사용하는지 가정하기가 어려워 졌습니다.

플레이 프레임워크의 일반적인 모델 개념(generic model concept)은 더 이상 유효하지 않습니다. 왜냐하면 단 하나의 API만으로 이 모든 종류의 (data store) 기술을 모두 다루기란 불가능하기 때문입니다.

플레이 2.0에서는 데이터 저장 드라이버나, ORM, 또는 다른 데이터 베이스 접근 라이브러리를 아주 사용하기 쉽게 만들고 싶었습니다. 플레이 2.0하고 특별히 통합시키지 않고서도 쉽게 사용할 수 있게 만들고 싶었습니다.

connection bounds를 관리하는 것 같은 흔한 기술적 이슈를 다루는 최소한의 헬퍼를 제공하고 싶습니다. (역자주 : 헬퍼 - 도와주는 역할을 하는 클래스, 모듈, 코드 등. 예를 들어 사용하기 어려운 클래스의 경우, 한꺼풀 더 씌워서 사용하기 편하게 만든 클래스)

또한, 플레이 2.0을 풀 스택 방식으로 유지하기 위해 고전적 데이터베이스에 접근할 수 있는 기본적인 도구들을 제공하기로 했습니다. 그래서 플레이 2.0에 Ebean, JPA, Anorm 같은 관계형 데이터베이스를 엑세스할 수 있는 라이브러리가 포함되어 있습니다. 데이터베이스에 관해 특별한 요구사항이 있는 경우가 아니라면 기본 라이브러리를 사용하면 됩니다.

(역자주 : full-stack: 프레임워크 내에 기본적으로 필요한 기반 라이브러리가 다 포함된 형태로 배포가 되면 full-stack이라고 부릅니다.)

출처 : https://opentutorials.org/module/123/1606

[IntelliJ] 테스트 코드 단축키 설정

Wings of Freedom — Thu, 5 Oct 2023 12:25:47 +0900

IntelliJ 테스트 코드 작성 시, 주로 given / when / then 패턴을 사용 합니다.

매번 반복 작업하기 번거로우니, 단축키를 만들어보겠습니다.

LiveTemplate 활용

1. MacOS에서는 preferences, Windows에서는 Settings

2. Editor -> Live Templates을 클릭한 후, Java를 선택한 다음 + 버튼을 누르면 Live Template

3. Abbreviation에 tdd라고 입력

4. Template text에 given / when / then 템플릿 입력

$END$ 의 의미는 해당 위치에 커서 이동

@Test
@DisplayName("")
void $END$() {
    //given
    
    //when
    
    //then
    
}

5. Define 버튼을 누르고, Java 선택

6. tdd라고 입력하면, 템플릿을 사용하여 테스트 코드 작성

7. test 템플릿도 동일하게 작성

5. test 입력 및 확인