• mattpocock/skills는 TypeScript 교육자 Matt Pocock이 만든 에이전트 스킬 38개 모음. 스킬은 코드가 아니라 에이전트에게 주입되는 작업 절차 지침서(SKILL.md)
• 저장소 공식 분류 기준으로 engineering 16개 / productivity 5개 / misc 4개 / personal 2개 / in-progress 7개 / deprecated 4개. 즉 실전용은 절반 정도, 나머지는 실험작·개인용·폐기
• code-review 스킬로 통제된 A/B 테스트 진행. 결론: 버그 탐지력 향상이 아니라(탐지율 무승부), 리뷰 프로세스의 구조화·감사가능성·재현성 확보
• 핵심 방법론 스킬은 언어 중립이라 Go/Python 프로젝트에도 그대로 적용 가능. 단 3개(misc 카테고리)는 TS/Node 툴링이 전제

1. mattpocock/skills 소개

Matt Pocock은 Total TypeScript로 유명한 TS 교육자인데, 이 저장소는 TS 강의가 아니라 "AI 에이전트로 실제 엔지니어링을 할 때 반복적으로 망가지는 지점"을 잡기 위한 스킬 모음. README가 꼽는 4가지 실패 모드:

1. 정합성 붕괴(Misalignment) — 개발자가 원한 것과 에이전트가 만든 것의 괴리
2. 장황한 출력(Verbose output) — 도메인 용어 없이 장황하기만 한 결과물
3. 동작하지 않는 코드 — 피드백 루프 부재
4. 아키텍처 붕괴 — AI로 빨리 짜다 구조가 썩는 것

각 실패 모드에 대응하는 스킬: 인터뷰로 요구사항을 못 박는 grilling, 도메인 용어를 강제하는 domain-modeling, 피드백 루프를 먼저 만드는 tdd/diagnosing-bugs, 깊은 모듈 설계를 유도하는 codebase-design 등.

2. 스킬이란 — SKILL.md 한 장이 전부다

각 스킬은 실행 파일이 아니라 마크다운 지침서 한 장. 프론트매터(name, description)와 본문(작업 절차, 판단 기준, 금지사항)으로 구성. 호출 시 이 내용이 에이전트 컨텍스트에 주입되고, 에이전트는 그 절차대로 동작.

호출 방식은 스킬마다 두 갈래:

• 자동 호출 가능 (18개) — 프론트매터에 별도 설정이 없으면, 에이전트가 세션 시작 시 description을 읽어두고 요청이 맞으면 알아서 끌어다 사용. "이 버그 진단해줘" → diagnosing-bugs가 자동으로 걸리는 식
• 수동 전용 (20개) — disable-model-invocation: true가 설정된 스킬. 반드시 /이름으로 직접 호출 필요. PRD 작성, 이슈 분해처럼 사용자가 명시적으로 시작하는 워크플로우

참고: "자동"은 보장이 아니라 에이전트의 판단. 확실히 쓰려면 직접 호출이 안전.

3. 설치

# vercel-labs의 skills CLI로 설치 (Claude Code 기준)
npx skills@latest add mattpocock/skills

# 설치 후 Claude Code 재시작 → 최초 1회 설정
/setup-matt-pocock-skills

# 뭘 쓸지 모르겠으면 라우터부터
/ask-matt

설치하면 .claude/skills/에 SKILL.md 저장. 재시작 시 슬래시 명령으로 인식.

설치 시 주의할 점 2가지:

• --all 플래그를 쓰면 Claude Code뿐 아니라 약 48개 타 에이전트 디렉터리(.goose, .cursor, .windsurf...)에 전부 복사. Claude Code만 쓸 땐 그냥 npx skills@latest add mattpocock/skills로 대화형 설치하거나, 설치 후 .claude/와 skills-lock.json만 남기고 정리
• 스킬은 에이전트 전체 권한으로 실행. 낯선 스킬은 SKILL.md를 열어보고 쓰기를 권장

4. 38개 전체 분류

아래 분류는 임의로 나눈 게 아니라 저장소 자체의 디렉터리 구조(skills-lock.json의 skillPath)를 따른 것. 저자 스스로 in-progress(미완성) 7개, deprecated(폐기) 4개, personal(개인용) 2개를 표시해뒀다는 점이 중요 — 그만큼 38개 중 실전 추천 대상은 engineering + productivity를 합친 21개로 좁혀짐.

아래 요약은 38개 SKILL.md 전문을 직접 읽고 작성했고, 표본 5개는 원문 대조 검증까지 진행. [자동] = 자동 호출 가능, [수동] = 수동 전용.

먼저 전체를 한눈에 훑을 수 있는 표부터. 상세 설명은 표 아래 각 소단원에 배치.

4.1 engineering — 핵심 엔지니어링 워크플로우 (16개)

ask-matt [수동] — 이 저장소 스킬 중 뭘 써야 할지 알려주는 라우터.

스킬들을 "flow" 개념으로 정리해서 상황에 맞는 스킬을 안내. 아이디어 다듬기부터 PRD 작성, 이슈 분할, 구현으로 이어지는 메인 플로우와 세션 관리 규칙까지 지도처럼 설명. 38개를 못 외우겠으면 이것만 기억.

code-review [자동] — 고정 지점 이후 diff를 표준·스펙 두 축으로 병렬 리뷰.

git diff <fixed-point>...HEAD를 잡고, Standards(코딩 표준 + Fowler 코드 스멜 12종 체크리스트)와 Spec(원 이슈/PRD 요구사항 충족) 두 서브에이전트를 병렬로 실행. 두 축을 합치거나 재순위화하지 않고 나란히 보고 — 한 축의 통과가 다른 축의 실패를 가리지 않게 하기 위함. 스펙 소스는 커밋 메시지의 이슈 참조 → 사용자 지정 경로 → docs/specs 폴더 순으로 자동 탐색, 없으면 질의. (6장에서 이 스킬로 진행한 A/B 테스트 결과 참고)

codebase-design [자동] — 깊은 모듈 설계를 위한 공유 어휘와 원칙 모음.

module, interface, seam, depth 같은 용어를 정확히 정의하고 일관된 설계 언어를 강제. 작은 인터페이스 뒤에 많은 동작을 숨기는 "깊은 모듈"이 목표. 직접 코드를 고치는 스킬이 아니라 다른 스킬들이 참조하는 어휘 레이어.

diagnosing-bugs [자동] — 어려운 버그를 6단계 진단 루프로 잡는 디버깅 규율.

피드백 루프 구축 → 재현+최소화 → 가설 3~5개 → 계측 → 수정+회귀 테스트 → 포스트모템. 핵심은 1단계: 버그에만 빨간불이 켜지는 빠르고 결정적인 pass/fail 명령을 만들기 전에는 가설조차 금지. "추측으로 고치기"를 구조적으로 차단하는 스킬.

domain-modeling [자동] — 설계 중 용어 사전(CONTEXT.md)과 ADR을 실시간으로 정비.

사용자가 쓰는 용어가 용어집과 충돌하면 즉시 지적, 확정된 용어는 그 자리에서 CONTEXT.md에 반영. ADR은 "되돌리기 어렵고, 맥락 없이는 의아하고, 실제 트레이드오프의 결과"라는 세 조건이 모두 맞을 때만 제안.

grill-with-docs [수동] — 계획을 집요하게 인터뷰하며 ADR과 용어집을 함께 작성.

grilling + domain-modeling 조합 스킬. 인터뷰로 계획을 다듬으면서 그 과정을 문서(ADR, 용어집)로 기록. 코드베이스가 있는 프로젝트면 grill-me 대신 이걸 쓰는 게 메인 플로우.

implement [수동] — PRD나 이슈 기반으로 실제 구현을 진행.

가능하면 사전 합의된 seam에서 tdd 방식으로 진행하고, 타입체크와 테스트를 수시로 실행하며, 완료 후 code-review로 검토 후 커밋. 다른 스킬들이 만든 산출물(PRD, 이슈)을 소비하는 실행 단계.

improve-codebase-architecture [수동] — 코드베이스에서 얕은 모듈을 찾아 리팩터링 후보를 제안.

서브에이전트로 코드베이스를 탐색해 "인터페이스가 구현만큼 복잡한 모듈"을 찾고, 후보별 문제/해결/이점과 before-after 다이어그램이 담긴 HTML 리포트를 생성. 후보를 고르면 grilling으로 설계를 심문.

prototype [자동] — 디자인 질문에 답하기 위한 버리는(throwaway) 프로토타입을 제작.

로직/상태 모델 검증이면 터미널 TUI로 상태 전이를 직접 눌러보게 하고, UI 탐색이면 구조적으로 전혀 다른 변형 3개를 생성. 테스트·에러 처리 없이 제작하며, 질문에 답하면 삭제하거나 검증된 결정만 실제 코드에 흡수.

research [자동] — 백그라운드 에이전트가 1차 출처를 조사해 MD 파일로 기록.

공식 문서, 소스 코드, 스펙 같은 1차 출처만 근거로 삼고 각 주장을 출처까지 추적. 블로그 같은 2차 자료는 근거로 배제. 조사를 위임하고 본인은 계속 작업하는 구조.

resolving-merge-conflicts [자동] — 진행 중인 git merge/rebase 충돌을 끝까지 해결.

충돌의 원 출처(커밋, PR, 이슈)를 읽고 변경 의도를 파악한 뒤, 양쪽 의도를 최대한 보존하는 방향으로 hunk별 해결 → 자동 검사 실행 → 커밋까지 진행. 절대 --abort 하지 않는 방침.

setup-matt-pocock-skills [수동] — 엔지니어링 스킬들이 쓸 저장소별 설정을 초기 세팅.

이슈 트래커(GitHub/GitLab/로컬 마크다운), 트리아지 라벨 어휘, 도메인 문서 레이아웃 세 가지를 사용자와 확인하며 docs/agents/ 아래 설정 문서를 생성. 다른 엔지니어링 스킬 쓰기 전에 저장소당 1회 실행하는 전제 조건.

tdd [자동] — red-green 루프로 남길 가치 있는 테스트를 만드는 TDD 가이드.

실패하는 테스트 하나 → 최소 구현 하나를 반복하는 수직 슬라이스 방식. 테스트는 사전에 사용자와 합의한 seam(공개 인터페이스 경계)에서만 작성하고, 구현 결합·동어반복 테스트 같은 안티패턴을 명시적으로 금지. mocking 가이드(시스템 경계에서만 mock)도 동봉.

to-issues [수동] — 계획/스펙을 트레이서 불릿 방식의 이슈들로 쪼개 발행.

레이어별 수평 분할이 아니라 스키마·API·UI·테스트를 관통하는 얇은 수직 슬라이스로 구분. 각 슬라이스는 단독 데모·검증이 필수. 사용자 승인 후 의존성 순서대로 이슈 트래커에 발행.

to-prd [수동] — 현재 대화 내용을 인터뷰 없이 PRD로 합성해 이슈 트래커에 발행.

추가 질문 없이 지금까지의 대화와 코드베이스 이해만으로 PRD를 작성. 파일 경로나 코드 스니펫은 금방 낡으므로 PRD에서 배제. 충분히 논의된 대화를 공식 문서로 굳히는 단계.

triage [수동] — 이슈와 외부 PR을 상태 머신 기반 역할로 분류·처리.

이슈를 카테고리(bug/enhancement) + 상태(needs-triage, needs-info, ready-for-agent, ready-for-human, wontfix) 라벨로 관리하는 상태 머신을 실행. 버그 재현 검증, 중복/과거 거절 이력 확인까지 진행, 트래커에 남기는 모든 코멘트에 AI 디스클레이머를 첨부.

4.2 productivity — 범용 생산성 (5개)

grilling [자동] — 계획을 빌드 전에 집요한 질문으로 검증.

설계 트리의 각 분기를 따라 내려가며 결정 간 의존성을 하나씩 해소. 질문은 한 번에 하나씩, 각 질문마다 추천 답변을 함께 제시. 코드베이스 탐색으로 답할 수 있는 건 묻지 않고 직접 탐색. 여러 스킬이 이걸 기반으로 동작하는 핵심 프리미티브.

grill-me [수동] — 인터뷰 세션을 시작하는 진입점.

본문이 "Run a /grilling session." 한 줄뿐인 얇은 래퍼. 코드베이스 없는 상황(아이디어 단계)에서 사용. 코드베이스가 있으면 문서까지 남기는 grill-with-docs가 권장.

handoff [수동] — 현재 대화를 다음 에이전트용 핸드오프 문서로 압축.

새 세션이 작업을 이어갈 수 있는 요약 문서를 OS 임시 디렉터리에 저장. 기존 산출물(PRD, 이슈, 커밋)은 중복 없이 경로/URL로만 참조, 민감 정보는 마스킹. 컨텍스트 윈도우가 길어졌을 때의 세션 위생 도구.

teach [수동] — 현재 디렉터리를 학습 워크스페이스로 전환해 여러 세션에 걸쳐 학습 지도.

MISSION.md(학습 동기), 학습 기록, HTML 레슨 파일로 상태를 저장하고, 회상 연습·간격 반복·인터리빙 같은 인지과학 개념을 명시적으로 적용. 프로그래밍뿐 아니라 주제 무관하게 적용 가능.

writing-great-skills [수동] — 스킬을 예측 가능하게 작성·편집하는 원칙 모음.

스킬의 근본 미덕을 "예측 가능성"(매 실행마다 같은 프로세스)으로 정의하고, 자동/수동 호출 선택 기준, 정보 계층화, 프루닝 원칙과 5가지 실패 모드를 정리. 직접 스킬을 만들고 싶을 때 읽는 메타 스킬.

4.3 misc — 특정 툴링 유틸리티 (4개)

4개 중 3개는 TS/Node 특정 툴 종속 — 38개 전체에서 사실상 유일한 언어 종속 그룹.

git-guardrails-claude-code [자동] — 위험한 git 명령을 실행 전에 차단하는 훅을 설치.

Claude Code의 PreToolUse 훅으로 git push, reset --hard, clean -f, branch -D 같은 파괴적 명령을 실행 전에 차단하는 스크립트를 설치하고, 설치 후 차단 동작까지 검증. 언어 무관, Claude Code 전용.

migrate-to-shoehorn [자동] — 테스트의 as 단언을 shoehorn 함수로 교체. (TS 전용)

as Type을 @total-typescript/shoehorn의 fromPartial()로 교체하는 마이그레이션. 테스트 코드 전용이며 프로덕션 사용 금지가 전제.

setup-pre-commit [자동] — Husky + lint-staged + Prettier 프리커밋 훅을 세팅. (Node 전용)

lockfile로 패키지 매니저를 감지하고 훅 설치 후 스모크 테스트까지 진행.

scaffold-exercises [자동] — 강의 실습 디렉터리 구조를 스캐폴딩. (Matt 강의 인프라 전용)

pnpm ai-hero-cli 린트를 전제로 하는 AI Hero 강의 리포 전용이라 일반 사용자에게는 의미가 없음.

4.4 personal — Matt 개인용 (2개)

edit-article [수동] — 아티클 초안을 섹션별로 재구성하고 문장을 정돈. 정보를 DAG로 보고 의존 관계에 맞게 섹션 순서를 정리하는 접근은 참고할 만.

obsidian-vault [자동] — Obsidian 볼트의 노트를 검색·생성·정리. 볼트 경로가 Matt의 개인 경로로 하드코딩돼 있어 그대로 쓰려면 수정 필요.

4.5 in-progress — 미완성/실험작 (7개)

저자가 아직 작업 중이라고 표시한 것들. 흥미로운 아이디어가 많지만 완성도는 보장 안 됨.

• claude-handoff [수동] — handoff 요약을 파일이 아니라 claude --bg로 백그라운드 에이전트에 바로 넘김
• loop-me [수동] — 삶의 반복 패턴을 찾아 위임 가능한 워크플로우 스펙으로 제작
• wayfinder [자동] — 한 세션에 안 담기는 큰 작업을 이슈 트래커 위 "지도"(research/prototype/grilling/task 티켓)로 계획하고 세션당 티켓 하나씩 해결. 아직 질문으로 표현 못 하는 영역은 "Fog" 섹션에 둠. 개인적으로 이 모음에서 가장 야심찬 아이디어라고 봄
• wizard [수동] — 수동 절차(서드파티 설정, 마이그레이션)를 안내하는 인터랙티브 bash 마법사를 생성
• writing-fragments [수동] / writing-beats [수동] / writing-shape [수동] — 글쓰기 3단계 파이프라인: 인터뷰로 글감 파편 수집 → 비트 단위로 골라가며 조립 → 문단 단위로 다듬어 완성. 각 단계가 명확히 구분

4.6 deprecated — 폐기됨 (4개)

저자가 더 이상 권장하지 않는 것들. 설치돼도 쓰지 않는 게 맞음.

• design-an-interface — 병렬 에이전트로 다른 설계안 여러 개를 뽑아 비교 (codebase-design의 Design It Twice로 흡수된 것으로 보임)
• qa — 대화로 버그를 말하면 GitHub 이슈로 등록 (triage로 대체)
• request-refactor-plan — 인터뷰로 리팩터 계획을 다듬어 이슈화
• ubiquitous-language — 대화에서 DDD식 용어집 추출 (domain-modeling으로 대체)

5. 스킬은 따로 노는 게 아니라 "플로우"로 엮여 있음

이 모음의 진짜 설계는 개별 스킬이 아니라 스킬 간 연결. ask-matt이 설명하는 메인 플로우(idea → ship):

아이디어
  → /grill-with-docs   (인터뷰로 다듬기 + ADR/용어집 기록)
  → /to-prd            (대화를 PRD로 굳히기)
  → /to-issues         (독립적인 수직 슬라이스 이슈로 분해)
  → 이슈당 새 세션에서 /implement   (내부에서 tdd 사용)
  → /code-review       (표준/스펙 2축 검토)

여기에 온램프 두 개(triage로 이슈 정리, diagnosing-bugs로 버그 잡기)가 메인 플로우에 합류하고, grilling·domain-modeling·codebase-design은 다른 스킬들이 깔고 쓰는 어휘/프리미티브 레이어로 동작. 이슈 단위로 세션을 끊어 컨텍스트를 초기화하는 것까지 플로우에 명시.

6. 직접 해본 A/B 테스트 — code-review 스킬이 바꾸는 것

주장만으로는 근거가 부족해 직접 통제된 실험으로 검증.

설계

• 서브에이전트 2개를 병렬로 띄움. 둘 다 완전히 동일한 자료(원본 이슈 + 코딩 표준 + 리뷰 대상 diff)를 받음
• 대조군: "이 변경 리뷰해줘"만 줌. 스킬 존재를 모름
• 실험군: 동일 자료 + code-review SKILL.md 지침 주입
• 서로의 존재를 모르는 격리 상태 → 유일한 변수는 스킬 주입 여부

리뷰 대상은 장바구니 쿠폰 할인 함수(11줄)이며, 여기에 결함 7개를 의도적으로 삽입: 스펙 위반 3개(음수 방지 없음, 반올림 없음, 유효성 검증/throw 없음) + 표준 위반 4개(JSDoc 없음, 매직 넘버, 공용 반올림 헬퍼 미사용, 입력 검증 없음).

export type Coupon = {
  type: 'percent' | 'fixed'
  value: number
}

export function applyCoupon(subtotal: number, coupon: Coupon): number {
  if (coupon.type === 'percent') {
    return subtotal - (subtotal * coupon.value) / 100
  }
  return subtotal - coupon.value
}

결과

해석 — 스킬은 모델을 똑똑하게 만드는 게 아님

가장 중요한 발견: 스킬을 붙인다고 버그를 더 찾은 게 아님. 강력한 모델은 작은 diff에선 스킬 없이도 결함을 전부 포착. 심지어 대조군이 더 실용적인 제안(exhaustive never 체크)을 한 지점도 있었음.

스킬이 실제로 바꾼 건 프로세스:

1. 커버리지 보장 — 실험군은 통과한 요구사항까지 "MET"로 확인. 대조군은 문제만 나열해서, 나머지를 검토했는지 건너뛰었는지 리포트만 봐선 알 수 없음. 감사 가능성(auditability)의 차이
2. 관심사 분리 — 스펙 축과 표준 축을 나눠서 한 축이 다른 축을 가리는 것을 방지
3. 재현성 — 매번 같은 형태로 나옴. 리뷰어(사람이든 에이전트든)가 여럿일 때 이 일관성이 값어치

즉 스킬의 값은 "똑똑함"이 아니라 "규율"이고, diff가 크고 팀이 클수록 이득이 커지는 종류.

한계 (정직하게)

• 표본은 리뷰 1건. 통계가 아니라 정성적 관찰
• 대조군도 같은 강력한 모델이라 탐지율이 붙었음. 약한 모델이나 더 크고 미묘한 diff였다면 커버리지 보장의 격차가 탐지율로도 드러났을 가능성이 큼

7. 결론 — 골라서 쓰기를 권장

쓰는 걸 추천하되, 38개를 통째로 설치하기보다는 골라서 쓰기를 권장.

• 바로 쓸 만한 것: code-review, tdd, diagnosing-bugs, grilling(+grill-with-docs), domain-modeling, research. 전부 언어 중립이라 TS가 아니어도 됨
• 팀/멀티세션 규모면 추가: to-prd, to-issues, implement, triage, handoff — 단 이슈 트래커 설정(setup-matt-pocock-skills)이 전제
• 거를 것: deprecated 4개, Matt 개인용 2개, 강의 인프라 전용 1개(scaffold-exercises). in-progress 7개는 아이디어 구경용
• 주의: 이미 자체 CLAUDE.md 규칙이 촘촘한 프로젝트면 스킬의 자체 컨벤션(영어 출력, docs/agents/ 문서 레이아웃, 이슈 트래커 전제)과 부딪힐 수 있으니 조정 필요

이 모음에서 개별 스킬보다 더 배울 만한 건 설계 철학이라고 생각: 에이전트에게 "잘해줘"라고 비는 대신, 검증된 작업 절차를 문서로 인코딩하고, 절차끼리 플로우로 엮고, 세션 경계까지 설계하는 것. 스킬을 직접 만들 사람이라면 writing-great-skills 하나만 읽어도 본전은 뽑음.

네트워킹 소개

• 커피숍 비유를 통한 네트워킹 개념
  • 커피숍 바리스타와 계산원 비유
    • 계산원 (퍼블릭 서브넷 역할)
      • 정의
        • 고객과 직접 마주하며 주문을 받고 결제를 처리하는 대외적 접점
    • 바리스타 (프라이빗 서브넷 역할)
      • 정의
        • 고객과 직접 상호 작용하지 않고, 격리된 내부 영역에서 음료 제조에만 몰입하는 내부 자원
• 네트워킹 구성 요소
  • Amazon Virtual Private Cloud (VPC)
    • 정의
      • AWS 클라우드 내부에서 사용자가 정의한 가상 네트워크를 실행할 수 있도록 마련된 논리적으로 격리된 영역
  • 서브넷 (Subnet)
    • 정의
      • 리소스를 역할 및 보안 수준에 따라 그룹화하고 분할하기 위해 VPC를 관리 가능한 크기인 특정 IP 주소 범위로 쪼갠 세그먼트
    • 특징/이점
      • 프라이빗 서브넷은 외부 인터넷 직접 노출을 차단하여 민감한 정보(데이터베이스 등)를 보관함
      • 퍼블릭 서브넷은 고객용 웹 사이트와 같이 인터넷 직접 액세스가 필요한 리소스를 배치함
• 네트워킹 구성 요소: 다이어그램을 통해 연결에 대해 이해
  • 아키텍처 다이어그램 (Architecture Diagram)
    • 정의
      • AWS 클라우드 내에 구축된 네트워크의 구조와 리소스 간의 연결 관계 및 데이터 이동 경로를 나타낸 시각적 맵
    • 특징/이점
      • 시스템의 이중화, 보안성, 확장성을 직관적으로 확인하고 최적의 설정을 검증하는 설계 청사진으로 활용함

• AWS 클라우드 (AWS Cloud)
  • 정의
    • 아키텍처 다이어그램상에서 시스템 전체 영역을 감싸는 가장 바깥쪽에 위치하는 상자
• 리전 (Region)
  • 정의
    • AWS 클라우드 하위에 표시되는 지리적으로 격리된 독립된 물리적 영역 상자
  • 특징/이점
    • 지연 시간, 규정 준수, 가용 서비스, 비용 등을 복합적으로 고려하여 적합한 리전을 결정함
• Amazon VPC
  • 정의
    • 리전 내부의 격리되어 논리적으로 분할된 네트워크 환경을 나타내는 실선 상자
  • 특징/이점
    • 네트워크 내부의 리소스 제어 및 보안 정책 설정을 관리함
• 가용 영역 (Availability Zone, AZ)
  • 정의
    • 리전 내에서 1개 이상의 개별 데이터 센터로 구성되고 각각 별도의 시설에 구축된 물리적 인프라 영역 상자
  • 특징/이점
    • 독립된 전력, 네트워킹, 연결 기능을 갖추고 있으며 다중 AZ 아키텍처는 단일 장애 상황으로부터 서비스를 보호함

• 서브넷 (Subnet)
  • 정의
    • VPC의 세그먼트로서 VPC 내의 특정 IP 주소 범위를 가지며 VPC를 관리하기 쉬운 섹션으로 나누는 단위 상자
• 프라이빗 서브넷 (Private Subnet)
  • 정의
    • 퍼블릭 인터넷에 직접 노출되면 안 되는 리소스를 안전하게 격리하도록 설계된 실선 상자

• 퍼블릭 서브넷 (Public Subnet)
  • 정의
    • 내부에 배치된 리소스에 인터넷과의 양방향 통신을 제공하도록 설계된 파선 상자
  • 특징/이점
    • 외부 인터넷의 통신을 허용하기 위해 인터넷 게이트웨이(IGW)에 연결되어 동작함

aws 클라우드의 네트워크 구성 요소

aws 클라우드 리소스 구성

• Amazon Virtual Private Cloud (VPC) 및 서브넷 기본 개념
  • Amazon VPC 개요
    • 정의
      • AWS 클라우드 내부에서 고객이 소유하고 격리시켜 프로비저닝하는 사설(프라이빗) 가상 네트워크 영역
    • 특징/이점
      • 리소스의 프라이빗 IP 범위를 정의하고, EC2 및 ELB 등의 자원을 그 안에 배치하여 경계를 설정함
      • 가상 네트워크의 설정, 관리, 검증 시간을 단축하여 온프레미스 대비 효율성을 높임
      • 보안 강화: 인스턴스 액세스 제한, 트래픽 스크리닝, 연결 보호 및 모니터링을 통한 강력한 통제권 제공
  • 서브넷 (Subnet)
    • 정의
      • 리소스를 그룹화하고 세부적으로 격리하기 위해 VPC의 IP 주소를 적절한 청크로 쪼갠 하위 섹션
    • 특징/이점
      • 나중에 설정할 네트워킹 보안 규칙과 연계하여 특정 리소스를 퍼블릭 또는 프라이빗 상태로 제어함
      • EC2 인스턴스 등 실제 구동할 컴퓨팅/네트워크 자원들을 포함하는 실질적 공간임
• 외부 인터넷 및 사설 네트워크 연결 수단 (게이트웨이)
  • 인터넷 게이트웨이 (Internet Gateway, IGW)
    • 정의
      • VPC 내부의 리소스와 퍼블릭 인터넷 간의 직접적인 통신(양방향 연결)을 허용하는 전용 출입구
    • 특징/이점
      • 커피숍의 현관문과 같은 비유로서, 이것이 VPC에 연결되어 있지 않으면 외부에서 퍼블릭 리소스에 접근이 절대 불가능함
      • 퍼블릭 웹 사이트, 퍼블릭 로드 밸런서 등 대외용 서비스 배치 시 반드시 장착해야 함
  • 가상 프라이빗 네트워크 (VPN) 및 가상 프라이빗 게이트웨이 (VGW)
    • 가상 프라이빗 네트워크 (VPN)
      • 정의
        • 일반 공개망인 인터넷을 사용하면서도 데이터 유출을 막기 위해 가상의 보안 암호화 터널을 생성해 트래픽을 통과시키는 가상 사설망 기술
      • 특징/이점
        • 패킷을 완전 암호화하여 통신 내용을 외부 감시자로부터 보호함
        • 퍼블릭 네트워크 선로를 공유하여 사용하므로 트래픽이 몰릴 때 대역폭 저하 및 속도 지연이 발생할 수 있음
    • 가상 프라이빗 게이트웨이 (Virtual Private Gateway, VGW)
      • 정의
        • 암호화된 VPN 보안 트래픽이 VPC 내부로 유입되거나 밖으로 나갈 수 있도록 보장하는 AWS 측의 전용 사설 통신 출입구
      • 특징/이점
        • 커피숍의 비공개 사옥 보안 게이트 비유로서, 사원증(인증)을 확인한 승인된 사내 네트워크 트래픽만 내부 VPC에 들어오게 허용함
        • 온프레미스 데이터 센터나 본사/지사 사내 네트워크와 AWS VPC 간에 안전한 하이브리드 VPN 터널링을 설정할 수 있음
  • AWS Direct Connect
    • 정의
      • 고객의 온프레미스 데이터 센터에서 AWS 영역까지 인터넷망을 경유하지 않고 완전한 프라이빗 전용 광케이블 회선을 연결하는 서비스
    • 특징/이점
      • 커피숍으로 바로 이어지는 비밀 전용 통로(마법의 문) 비유로서, 네트워크 혼잡이나 공유 회선 문제를 완전히 우회함
      • 매우 안정적이고 일관된 초고속 고대역폭 전송 성능과 높은 보안 성능을 제공함
      • 데이터 주권 등 법률적 규정 준수(Compliance)를 강하게 충족하며 전용 통신망 파트너를 통해 물리 전용선을 구축함

aws 클라우드에 연결할 수 있는 추가적인 방법

• AWS 클라우드 연결 개요

  • 정의
    • 네트워크, 온프레미스 데이터 센터, 원격 작업자의 다양성에 맞춰 기업이 AWS 클라우드 리소스에 접속할 수 있도록 제공되는 다양한 연결 방식

• AWS Client VPN

  • 정의
    • 원격 작업자와 온프레미스 네트워크를 AWS 클라우드에 보안 연결할 수 있게 지원하는 클라이언트 기반 VPN 서비스
  • 특징/이점
    • 탄력적인 완전관리형 서비스로서 사용자 수요에 맞춰 자동으로 리소스 규모를 스케일 업/다운함
    • 별도의 물리 하드웨어를 구매 및 관리할 필요가 없으며 OpenVPN 기반 클라이언트를 채택함
    • 고급 인증 방식과 안전한 원격 액세스를 신속히 제공해야 하는 대기업 원격 근무 환경에 적합함

• AWS Site-to-Site VPN

  • 정의
    • 기업의 온프레미스 데이터 센터나 지사(Site) 네트워크와 AWS 클라우드 VPC 간에 안전하고 암호화된 터널링 세션을 맺어주는 IPsec VPN 서비스
  • 특징/이점
    • 고가용성, 강력한 보안, 비공개 세션을 생성하며 가상 프라이빗 게이트웨이(VGW)를 거쳐 VPC로 유입됨
    • 주로 원격 지사 위치 간의 애플리케이션 마이그레이션이나 암호화 보안 통신에 필수적으로 적용됨

• AWS PrivateLink

  • 정의
    • 인터넷 게이트웨이, NAT 디바이스, 퍼블릭 IP, Direct Connect 또는 VPN을 거치지 않고, VPC를 다른 VPC나 AWS 서비스에 사설망(비공개)으로 가용성 높게 직접 연결해 주는 프라이빗 연결 기술
  • 특징/이점
    • 마치 고객이 독자적으로 보유한 VPC 내부에서 직접 서비스와 자원을 이용하는 것과 동일한 보안성을 제공함
    • 다른 클라이언트와의 트래픽 정체 현상을 방지하고 비공개 API 엔드포인트 연결을 중앙 제어하여 관리 복잡성을 줄임

• AWS Direct Connect

  • 정의
    • 고객의 온프레미스 데이터 센터나 사무실에서 AWS 인프라 영역까지 인터넷을 완전히 우회하여 물리적인 전용 광케이블 회선으로 직결하는 서비스
  • 특징/이점
    • 인터넷 공유 회선을 사용하지 않아 트래픽 정체 요인이 없고 네트워크 비용이 대폭 절감됨
    • 지연 시간에 민감한 애플리케이션: 일관되게 지연 시간이 극도로 짧은 환경을 조성해 동영상 스트리밍이나 실시간 처리에 최적화됨
    • 대규모 데이터 마이그레이션: 실시간 빅데이터 분석, 신속 백업, 고용량 미디어 브로드캐스트 전송을 위한 신뢰성 있는 대역폭을 보장함
    • 하이브리드 클라우드 아키텍처: AWS와 온프레미스 네트워크를 유기적으로 직결하여 성능 저하 없는 분산 애플리케이션 가동 환경을 형성함

• 추가적인 게이트웨이 서비스

  • AWS Transit Gateway
    • 정의
      • 중앙 집중식 가상 라우터(허브) 역할을 수행하여 수많은 VPC들과 온프레미스 네트워크를 그물망 피어링 대신 일대다(1:N) 형태로 통합 연동해 주는 게이트웨이 서비스
    • 특징/이점
      • 클라우드 인프라가 전 세계로 확장될 때 리전 간 전송 게이트웨이를 피어링하여 관리를 획기적으로 간소화함
  • Network Address Translation (NAT) 게이트웨이
    • 정의
      • 프라이빗 서브넷에 속한 인스턴스가 VPC 외부의 인터넷이나 다른 서비스로 아웃바운드 연결은 수행하게 돕되, 외부에서 해당 프라이빗 인스턴스로의 최초 인바운드 접속 시도는 전면 차단해 주는 주소 변환(NAT) 서비스
  • Amazon API Gateway
    • 정의
      • 소프트웨어 시스템 간 통신을 정의하는 API를 개발자가 손쉽게 대규모로 생성, 게시, 유지 관리, 모니터링 및 보안 제어할 수 있게 돕는 완전관리형 API 호스팅 서비스

서브넷, 보안 그룹, 네트워크 엑세스 제어 목록

• VPC 네트워크 보안 개요

  • 정의
    • 외부 위협으로부터 클라우드 내부 자원을 보호하기 위해 VPC 내부와 서브넷, 인스턴스 등 각 계층별로 적용되는 다층 방어 네트워킹 보안 설계
  • 특징/이점
    • 게이트웨이 경계 보안 외에도 방화벽, DDoS 방지, 암호화, 패킷 스크리닝 등 다양한 보안 계층 도구를 종합 활용함

• 네트워크 액세스 제어 목록 (Network ACL)

  • 정의
    • 서브넷 수준에서 인바운드 및 아웃바운드 트래픽을 제어하는 스테이트리스(Stateless) 기반의 가상 방화벽
  • 특징/이점
    • 출입국 심사 직원 비유: 서브넷 경계를 드나드는 모든 데이터 패킷의 발신 정보와 포트를 규칙 목록(승인/거부 목록)과 대조해 검사함
    • 기본 네트워크 ACL은 기본적으로 모든 인바운드/아웃바운드 트래픽을 허용함
    • 사용자 지정 네트워크 ACL은 명시적 규칙을 추가하기 전까지 모든 트래픽을 차단함 (마지막에 매칭되지 않는 패킷을 전면 드롭하는 명시적 거부 규칙 존재)
    • 한계: 패킷이 서브넷 경계를 통과할 때만 동작하며, 동일 서브넷 내부에서 인스턴스 간에 주고받는 트래픽 흐름은 통제할 수 없음

• 보안 그룹 (Security Groups)

  • 정의
    • Amazon EC2 인스턴스 등 개별 리소스 수준에서 인바운드 및 아웃바운드 트래픽을 세밀하게 제어하는 스테이트풀(Stateful) 기반의 가상 방화벽
  • 특징/이점
    • 아파트 건물의 도어맨 비유: 인스턴스 단위로 동작하며, 들어올 때만 허가 목록을 확인하고 나갈 때는 검사하지 않음
    • 기본적으로 모든 인바운드 트래픽을 차단(거부)하고, 모든 아웃바운드 트래픽을 허용하도록 설정되어 시작됨
    • 허용(Allow) 규칙만 정의할 수 있으며, 거부(Deny) 규칙은 작성할 수 없음 (규칙에 없는 트래픽은 자동으로 모두 차단됨)

• 패킷 필터링 방식 비교 (스테이트풀 vs 스테이트리스)

  • 스테이트풀 패킷 필터링 (Stateful Packet Filtering)

    • 정의
      • 아웃바운드로 나간 요청의 연결 상태(세션)를 메모리에 기억해 두었다가, 해당 요청의 반환 트래픽이 들어올 때 인바운드 규칙 검사를 생략하고 무조건 허용하는 방식 (보안 그룹에 적용)

  • 스테이트리스 패킷 필터링 (Stateless Packet Filtering)

    • 정의
      • 과거에 나간 아웃바운드 요청 상태를 전혀 저장(기억)하지 않고, 인바운드와 아웃바운드 양방향에 대해 매번 독립적으로 규칙 목록과 대조하여 통과 여부를 검사하는 방식 (네트워크 ACL에 적용)

• 서브넷 간 패킷 이동 시나리오 (인스턴스 A에서 다른 서브넷의 인스턴스 B로 송수신 시 검사 순서)

  • 1. 송신 과정 (A -> B)
    • 인스턴스 A 보안 그룹: 아웃바운드 트래픽 자동 통과 (기본 설정상 모든 발신 허용)
    • 서브넷 1 네트워크 ACL: 송신(발신) 규칙에 따라 패킷 검사 후 통과 결정
    • 서브넷 2 네트워크 ACL: 수신(입산) 규칙에 따라 패킷 검사 후 통과 결정
    • 인스턴스 B 보안 그룹: 인바운드 허용 규칙 목록과 대조하여 패킷 진입 허용 여부 판정
  • 2. 반환 과정 (B -> A)
    • 인스턴스 B 보안 그룹: 요청에 대한 회신이므로 아웃바운드 필터 자동 통과
    • 서브넷 2 네트워크 ACL: 스테이트리스이므로 송신 규칙에 따라 패킷 재검사 실행
    • 서브넷 1 네트워크 ACL: 스테이트리스이므로 수신 규칙에 따라 패킷 재검사 실행
    • 인스턴스 A 보안 그룹: 스테이트풀이므로 아웃바운드 요청에 대한 반환 트래픽임을 기억하고 규칙 검사 없이 자동으로 패킷 최종 수용

• 보안 그룹과 네트워크 ACL 핵심 요약

  • 보안 그룹
    • 작동 범위: 인스턴스 수준 (개별 리소스 제어)
    • 연결 상태 유지: 스테이트풀 (Stateful)
    • 규칙 성격: 허용(Allow) 규칙만 정의 가능
    • 반환 트래픽 처리: 인바운드가 허용되면 반환 트래픽은 자동 허용됨
  • 네트워크 ACL
    • 작동 범위: 서브넷 수준 (광범위한 서브넷 경계 제어)
    • 연결 상태 유지: 스테이트리스 (Stateless)
    • 규칙 성격: 허용(Allow) 및 거부(Deny) 규칙 모두 정의 가능
    • 반환 트래픽 처리: 아웃바운드와 인바운드 각각 개별 규칙 통과가 요구됨

• 공동 책임 모델상의 네트워크 보안 책임

  • 정의
    • AWS 인프라의 기본 환경은 AWS가 책임지지만, 그 내부의 가상 네트워크(VPC) 서브넷과 리소스를 안전하게 설계하고 방화벽 규칙을 적용할 책임은 고객에게 있다는 원칙

amazon vpc 데모

• AWS 클라우드에서 Amazon VPC 구축 개요

  • 정의
    • AWS Management Console을 활용해 VPC, 가용 영역별 서브넷, 인터넷 게이트웨이, 라우팅 테이블을 설계하고 구성하는 실제 네트워크 구축 프로세스
  • 특징/이점
    • 고가용성 네트워크의 기본 구성 요소들을 순차적으로 연계 설정하여 인터넷 직접 통신이 가능한 퍼블릭 영역과 차단된 프라이빗 영역을 분리함

• 1단계: Amazon VPC 생성

    ![](https://velog.velcdn.com/images/oi_24/post/92431302-d3d6-406e-a707-39f862d7ec02/image.png)

  • 정의
    • 클라우드 내에 격리된 사설 네트워크의 기본 주소 공간을 프로비저닝하는 작업
  • 설정 세부정보
    • Resource to create: VPC only 선택
    • Name tag: my-vpc
    • CIDR(IPv4 주소 블록 범위): 10.0.0.0/16 지정 (해당 VPC에서 생성되는 모든 리소스는 10.0으로 시작하는 고유 프라이빗 IP를 할당받음)

• 2단계: 가용 영역별 서브넷 생성

    ![](https://velog.velcdn.com/images/oi_24/post/ec535b71-b80e-4d91-a085-99a36fd12edd/image.png)

  • 정의
    • 고가용성(High Availability) 모범 사례에 따라 단일 리전 내의 서로 다른 2개의 물리 가용 영역(AZ)에 퍼블릭 및 프라이빗 서브넷을 각각 분산 배치하는 작업
  • 설정 세부정보
    • 프라이빗 서브넷 생성:
      • private-subnet-1: 가용 영역 us-east-1a, CIDR 블록 10.0.1.0/24 지정
      • private-subnet-2: 다른 가용 영역(예: us-east-1b), CIDR 블록 10.0.2.0/24 지정
      • 주의 사항: 외부 인터넷 접근이 불가능하도록 퍼블릭 IPv4 자동 할당(Auto-assign IP settings)을 활성화하지 않음
    • 퍼블릭 서브넷 생성:
      • public-subnet-1: 가용 영역 us-east-1a, CIDR 블록 10.0.3.0/24 지정
      • public-subnet-2: 다른 가용 영역(예: us-east-1b), CIDR 블록 10.0.4.0/24 지정
      • 필수 설정: 외부 접속용 퍼블릭 IP를 부여하기 위해 퍼블릭 IPv4 자동 할당(Auto-assign public IPv4) 옵션을 명시적으로 활성화(Save)함
    • 주의 사항
      • 단순히 서브넷 이름에 'public'이나 'private'을 기재하는 것만으로는 실제 퍼블릭/프라이빗 기능이 활성화되지 않으며, 인터넷 게이트웨이 연결 및 라우팅 설정이 완료되어야 실질적으로 동작함

• 3단계: 인터넷 게이트웨이 생성 및 연결

  • 정의
    • VPC가 외부 인터넷과 직접 양방향 통신을 처리하기 위한 논리적 출입문을 생성하여 장착하는 작업
  • 설정 세부정보
    • Name tag: my-ig로 인터넷 게이트웨이 생성
    • VPC 연결: Actions 메뉴의 VPC에 연결(Attach to VPC)을 실행하여 대상 VPC(my-vpc)에 게이트웨이를 정상 부착함

• 4단계: 라우팅 테이블 생성 및 서브넷 연결

  • 정의
    • 네트워크 패킷이 올바른 목적지로 이동할 수 있도록 라우팅 규칙(경로)을 정의하고, 이를 특정 서브넷들과 맵핑하는 작업
  • 설정 세부정보
    • 라우팅 테이블 생성: Name을 public-route-table로 정하고 대상 VPC(my-vpc)를 지정하여 생성
    • 라우팅 규칙 추가 (Edit routes):
      • 대상(Destination)에 0.0.0.0/0(모든 외부 트래픽) 입력
      • 대상(Target)에 방금 생성하여 연결한 인터넷 게이트웨이(my-ig)를 지정 및 저장
    • 명시적 서브넷 연결 (Subnet associations):
      • 생성한 라우팅 테이블의 서브넷 연결 탭에서 public-subnet-1과 public-subnet-2를 연결함
      • 이 연결을 거친 서브넷은 인터넷 게이트웨이로 향하는 유효 경로를 가져 실질적인 퍼블릭 서브넷으로 승격되며, 경로가 없는 프라이빗 서브넷들은 격리 상태를 계속 유지함

• 5단계: 보안 규칙 구성 및 리소스 배포 준비

  • 정의
    • 구축된 네트워크 환경의 트래픽을 안전하게 필터링하기 위해 보안 제어를 설정하고 리소스를 추가할 최종 단계를 준비하는 작업
  • 특징/이점
    • 앞서 생성한 CIDR 블록 범위를 소스/대상 정의용으로 활용하여 보안 그룹 및 네트워크 ACL에 정밀한 허용/차단 규칙을 명시함
    • 필터링 정책이 완벽히 구성되면 해당 서브넷에 EC2 인스턴스, 데이터베이스 등의 실제 비즈니스용 리소스를 최종 배포함

글로벌 네트워킹

• 엣지 네트워킹 (Edge Networking) 개요
  • 정의
    • 콘텐츠를 소비하는 사용자 및 데이터를 생성하는 디바이스에 물리적으로 더 가까운 위치에서 정보 저장 및 컴퓨팅 서비스를 수행하는 인프라 아키텍처
  • 특징/이점
    • 로컬에 데이터를 캐싱하거나 연산 태스크를 수행하여 네트워크 통신의 지연 시간(Latency)을 획기적으로 감축함
    • 최종 사용자에게 정체 없는 빠른 응답 속도를 보장하여 전반적인 애플리케이션 인터랙션 만족도를 향상시킴
• Amazon Route 53
  • 정의
    • 최종 사용자를 AWS 내부 및 외부의 인터넷 애플리케이션으로 신뢰성 있게 안내하는 고가용성 및 확장성을 갖춘 클라우드 도메인 이름 서비스 (DNS)
  • 특징/이점
    • 인터넷의 전화번호부/번역기 비유: 사람이 읽을 수 있는 도메인 주소를 컴퓨터가 해석할 수 있는 IP 주소로 신속 변환함
    • 다양한 지능형 라우팅 정책 지원: 지연 시간 기반 라우팅, 지리적 위치(고객의 대륙/국가 위치에 따른 분기), 지리적 근접성, 가중치 기반 라운드 로빈(Weighted Round Robin) 등
    • 도메인 이름 구매 및 등록 관리를 Route 53 한 곳에서 일원화하여 통합 관리할 수 있는 도메인 레지스트라 기능 지원
• Amazon CloudFront
  • 정의
    • 웹 콘텐츠, 동영상, 이미지, 애플리케이션, API 등을 글로벌 엣지 로케이션망을 활용하여 전 세계 사용자에게 신속하게 분배하는 콘텐츠 전송 네트워크 (CDN) 서비스
  • 특징/이점
    • 글로벌 배달 트럭 네트워크 비유: 중앙의 오리진 서버에 매번 직접 패킷을 요청하지 않고, 엣지 로케이션에 사본(캐시)을 미리 보관해 빠르게 반환함
    • 동영상 스트리밍: 동시 대규모 접속자가 몰리는 피크 시간에도 버퍼링을 차단하고 끊김 없는 전송 신뢰성을 확보함
    • 전자상거래 웹 사이트: 대규모 쇼핑 시즌에도 고용량 상품 이미지와 제품 세부 정보를 사용자 부근 엣지에서 즉각 띄워 이탈률을 저하시킴
    • 모바일 앱: 실시간 변동이 잦은 위치/지도 데이터나 미디어 자산을 모바일 디바이스에 지체 없이 안정적으로 로드함
• AWS Global Accelerator
  • 정의
    • 지능형 트래픽 라우팅 및 신속한 장애 조치(Failover) 기술과 AWS의 프라이빗 글로벌 백본 네트워크망을 활용해 글로벌 애플리케이션의 가용성, 보안 및 전송 성능을 극대화하는 서비스
  • 특징/이점
    • 정체가 발생하기 쉬운 공용 인터넷 고속도로망 대신, 트래픽을 위한 독점 보안 고속 차선을 구축하여 기동함
    • 글로벌 온라인 게임: 전 세계 플레이어(예: 도쿄, 뉴욕, 런던 등) 간의 지연 편차를 좁혀 동등하고 매끄러운 반응성의 게임플레이 환경을 보장함
    • 금융 및 은행 서비스: 접속자가 대거 밀리는 피크 타임이나 지역 네트워크 불안 상황에서도 가동 중지 및 지연 없이 신뢰할 수 있는 속도로 금융 거래 및 계좌 액세스를 보장함

실제 환경에서의 클라우드

글로벌 아키텍처

• 실제 환경의 글로벌 네트워크 요구사항
  • 정의
    • 전 세계 사용자를 지원하기 위해 여러 계정, 여러 리전, 다중 VPC 및 온프레미스를 통합하는 복잡한 하이브리드 네트워킹 구조
  • 특징/이점
    • 비즈니스 규모 확장과 지리적 이중화를 실현하여 가동 중지 시간을 방지하고 고성능 가용성을 보장함
• 하이브리드 연결 방식 비교 (Site-to-Site VPN vs Direct Connect)
  • AWS Site-to-Site VPN
    • 정의
      • 퍼블릭 인터넷 위에 보안 암호화 프라이빗 터널을 생성하여 온프레미스 네트워크와 AWS VPC를 가상 프라이빗 게이트웨이(VGW)로 연결하는 서비스
    • 특징/이점
      • 안전하고 유연하며 설정이 신속해 소규모 데이터 전송 및 원격 리소스 액세스에 최적화됨
      • 한계: 공용 인터넷 대역폭을 공유하므로 대용량 데이터 전송 시 속도가 저하되며, 특정 보안 규정 준수 충족에 제약이 있을 수 있음
  • AWS Direct Connect
    • 정의
      • 인터넷을 우회하여 고객 데이터 센터에서 Direct Connect 로케이션을 거쳐 가상 프라이빗 게이트웨이(VGW)까지 물리적인 전용 광케이블 회선을 직결하는 서비스
    • 특징/이점
      • 일관되게 지연 시간이 짧고 대규모 데이터 전송 속도를 대폭 높여 중요한 애플리케이션 성능을 극대화함
      • 동영상 스트리밍, 실시간 백업, 하이브리드 연산 등 고대역폭과 강력한 보안 규정 준수가 필요한 비즈니스에 필수적임
• Direct Connect 장애 조치 및 가용성 설계
  • VPN 장애 조치 (Backup & Failover)
    • 정의
      • 비용 효율성을 극대화하기 위해 Direct Connect 전용선 단선 장애 시 백업 연결용으로 Site-to-Site VPN을 설정해 자동 복구(Failover)하는 이중화 방식
    • 특징/이점
      • 평소에는 전용선을 쓰고 비상시에만 인터넷망 VPN을 사용해 보조 회선 비용을 줄이지만, 장애 복구 시에는 대역폭이 VPN 성능 수준으로 한정됨
  • 보조 Direct Connect 구성
    • 정의
      • 핵심 시스템의 성능 저하 없는 고가용성을 유지하기 위해 또 다른 물리적 Direct Connect 회선을 평행하게 구축하여 상호 백업하는 구조
    • 특징/이점
      • 단선 사고가 일어나더라도 고대역폭과 초저지연 성능을 일관되게 유지하는 강력한 내결함성을 확보함
  • 대역폭 집계 (Bandwidth Aggregation)
    • 정의
      • 네트워크 처리 용량을 물리적으로 증가시키기 위해 여러 개의 Direct Connect 전용선 연결을 하나로 결합하는 기술
    • 특징/이점
      • 회선 여러 개를 묶어 집계 대역폭을 향상시킴으로써 한 번에 대용량 트래픽 전송이 가능한 네트워크 파이프라인을 형성함
  • 하이브리드 아키텍처 연결 경로
    1. 고객 네트워크: 고대역폭 연결을 요구하는 클라이언트 및 백엔드 서버
    2. 콘텐츠 라우터 / 방화벽: 온프레미스 최경계에서 Direct Connect 선로에 유입을 중계하는 전용 게이트 장비
    3. 다중 Direct Connect 연결: 내결함성과 대역폭 향상을 위해 이중화로 연결된 물리 전용 회선
    4. 가상 프라이빗 게이트웨이 (VGW): VPC 관문에서 암호화되거나 격리된 사설 트래픽 통신을 안전하게 최종 수용하는 허브
    5. Amazon VPC: 전용선을 경유해 들어온 트래픽으로 실제 서비스를 처리하는 여러 프라이빗 서브넷 내 컴퓨팅 리소스
• Route 53 & CloudFront 연동을 통한 글로벌 콘텐츠 배포
  • 정의
    • 전 세계 사용자에게 낮은 지연 시간으로 웹 사이트와 미디어를 서비스하기 위해 Route 53 DNS와 CloudFront CDN을 상호 연계하는 통합 글로벌 아키텍처
  • 작동 흐름
    1. 사용자 요청: 사용자가 브라우저를 통해 도메인 주소로 웹 사이트에 접속을 시도하면 Route 53 DNS 서버가 이를 수신함
    2. 라우팅 정책 판정: Route 53가 지연 시간 기반 라우팅 정책 등을 활용해 사용자에게 가장 가까운 리전을 즉각 판정함
    3. 엣지 로케이션 연동: Route 53의 제어에 따라 사용자는 해당 리전과 연동된 최적의 CloudFront 엣지 로케이션으로 연결됨
    4. 다중 AZ 오리진 서버 콘텐츠 인출: 엣지 로케이션은 해당 리전의 다중 가용 영역(AZ)에 안전하게 배포된 고가용성 오리진 서버에서 원본 자원을 불러와 최종 가동시킴

글로벌 시장 진출 소개

• 글로벌 시장 진출 개요
  • 정의
    • 비즈니스가 전 세계 고객에게 서비스를 제공하고 물리적/가상 인프라를 확장하는 과정
  • 특징/이점
    • 현지 수요, 규정 준수, 비용 등 여러 요인을 고려하여 확장 계획 수립 필요
    • AWS는 전 세계 어디서나 강력하고 확장 가능하며 고가용성을 갖춘 애플리케이션을 구현할 수 있도록 지원
• AWS 글로벌 인프라 비유
  • 리전(Region) 선택
    • 정의
      • 새로운 물리적 매장을 열 위치를 결정하는 것과 같이 실제 클라우드 리소스를 배포할 리전을 선택하는 것
    • 고려 사항
      • 현지 수요, 규정, 비용 등 여러 비즈니스 및 기술적 요인
  • AWS 엣지 로케이션(Edge Location)
    • 정의
      • 이동식 커피 카트처럼 전 세계 사용자에게 지연 시간을 최소화하여 콘텐츠를 신속하게 제공하는 소규모 물리적 시설
    • 특징/이점
      • 이미지, 동영상, 정적 자산 등 자주 액세스하는 콘텐츠를 캐시하여 사용자에게 빠르게 제공
      • 중앙 서버(리전)로부터 매번 데이터를 가져오는 대기 시간 단축
  • 코드형 인프라(IaC) 및 AWS CloudFormation
    • 정의
      • 전 세계 모든 지점에서 일관된 프로세스와 커피 맛을 유지하기 위해 레시피 및 장비를 표준화하는 것처럼, 코드로 인프라를 정의하고 배포하는 방식
    • 특징/이점
      • 환경 및 글로벌 배포 전체에서 일관성 있고 신뢰할 수 있는 설정을 구현
      • 비즈니스 성장에 맞춰 신속하고 책임감 있게 리소스 스케일링 가능

aws 글로벌 인프라

aws 리전 선택

• AWS 리전의 중요한 보안 및 데이터 격리
  • 정의
    • 각 AWS 리전은 다른 리전과 완벽하게 격리되어 독립적으로 가동되는 물리적 인프라의 집합
  • 특징/이점
    • 사용자가 명시적으로 데이터를 이동할 권한을 부여하지 않으면 리전의 경계를 벗어날 수 없으므로 철저한 데이터 주권 및 보안을 제공함
• AWS 리전 선택 시 4가지 주요 고려 사항
  • 1. 규정 준수 (Compliance)
    • 정의
      • 특정 국가나 지역의 현지 법률 및 법규(예: 데이터 보호법, 데이터 거버넌스 규제 등)를 준수하기 위해 데이터를 특정 지리적 영역 내에 보관해야 하는 법적 요구사항
    • 특징/이점
      • 리전을 선택할 때 가장 먼저(최우선적으로) 검토해야 하는 결정적인 요인임
      • 예시: 유럽 연합(EU)의 일반 데이터 보호 규정(GDPR) 준수 요구 사항에 따라 프랑크푸르트 등의 EU 리전에 고객 데이터를 저장하고 외부 반출을 차단하는 경우
  • 2. 근접성 (Proximity)
    • 정의
      • 실제 서비스를 이용하는 사용자 기반(고객)의 지리적 위치와 리전 데이터 센터 사이의 물리적 거리
    • 특징/이점
      • 사용자 기반과 지리적으로 가까운 리전을 택할수록 데이터 전송 시 지연 시간(Latency)이 최소화되며 애플리케이션의 반응성과 만족도가 대폭 향상됨
  • 3. 기능 가용성 (Feature Availability)
    • 정의
      • 배포하고자 하는 AWS의 특정 서비스, 신기능 혹은 특정 요구사항을 위한 하드웨어 세팅이 해당 리전에 준비되어 있는지의 여부
    • 특징/이점
      • AWS는 지속적으로 서비스를 신규 리전에 출시/확장하고 있으나 특정 신기능이나 특수 목적의 격리된 서비스(예: 미국 정부 전용 규정 준수를 위한 AWS GovCloud 리전) 등은 특정 리전에서만 선제적으로 제공될 수 있음
  • 4. 요금 (Pricing)
    • 정의
      • 리전별로 운영에 따른 전반적인 서비스 및 인프라의 청구 단가가 다르게 책정되는 과금 특성
    • 특징/이점
      • 동일한 사양의 AWS 서비스 및 기능이라 하더라도, 리전 데이터 센터가 위치한 국가의 현지 조세 체계(세법), 전력/에너지 공급 비용, 토지 비용 등의 운영 인프라 차이에 따라 청구 금액에 상당한 편차가 발생할 수 있음

aws 글로벌 인프라 자세히 살펴보기

• 고가용성 아키텍처 설계
  • 고가용성 (High Availability)
    • 정의
      • 시스템이 장애 없이 지속적으로 가동되어 서비스를 원활하게 제공할 수 있는 능력
    • 특징/이점
      • 특정 물리적 하드웨어나 구성 요소에 결함이 발생하더라도 비즈니스 연속성이 끊기지 않고 심각한 가동 중지 시간을 방지함
  • 민첩성 (Agility)
    • 정의
      • 급격하게 변화하는 비즈니스 요건이나 시장 조건에 맞춰 인프라 서비스를 신속하게 개발, 테스트 및 배포하는 능력
    • 특징/이점
      • 복잡한 하드웨어 수급 절차 없이 가상 자원을 즉각적으로 조달하여 인적/시간적 리소스 효율성을 극대화함
  • 탄력성 (Elasticity)
    • 정의
      • 실제 서비스 수요의 변동 폭에 따라 필요한 리소스 용량을 자동으로 확장(Scale-up)하거나 축소(Scale-down)하는 구조적 특성
    • 특징/이점
      • 트래픽이 폭증할 때는 자원을 확장하여 부하를 분산시키고, 사용량이 적을 때는 리소스를 줄여 불필요한 과금을 절감함
  • 이중화 아키텍처 (Redundancy Architecture)
    • 정의
      • 인프라 중단 사고에 사전 대응할 수 있도록 물리적으로 복제된 다중 백업 장치 및 자원을 상시 유지하는 아키텍처 기법
    • 특징/이점
      • 다중 가용 영역(Multi-AZ) 배포: 하나의 가용 영역에 장애가 일어나더라도 시스템이 이중화된 백업 영역으로 자동 장애 조치(Failover)되어 최종 사용자에게 무중단 서비스를 보장함
      • 다중 리전(Multi-Region) 배포: 한 국가 규모의 물리적 재난이 닥쳐 특정 리전 전체가 마비되더라도 다른 국가의 리전으로 트래픽을 안전하게 장애 조치(Failover)함
• AWS 글로벌 인프라 핵심 구성 요소
  • AWS 리전 (Region)
    • 정의
      • 전 세계에 지리적으로 분산되어 데이터 센터들을 물리적으로 호스팅하고 있는 거대한 독립 영역
    • 특징/이점
      • 개별 리전은 타 리전과 규정, 네트워크상으로 완전히 격리되어 운영됨
      • 모든 AWS 리전은 격리된 전력망과 연결망을 가지는 가용 영역(AZ)을 최소 3개 이상 보유함
  • 가용 영역 (Availability Zone, AZ)
    • 정의
      • 하나의 리전 내부에서 독립적인 물리 전력망, 공조 시스템, 통신 네트워크 연결을 지니도록 상호 격리 설계된 단일 또는 그 이상의 데이터 센터들의 집합
    • 특징/이점
      • 리전 내 다른 가용 영역들과는 초고속 전용 광케이블망으로 긴밀히 소통함
      • 특정 데이터 센터 시설의 화재나 단전 등 내결함성(Fault Tolerance) 시나리오에서 시스템 전반의 붕괴를 예방함
  • 엣지 로케이션 (Edge Location)
    • 정의
      • 유저에게 콘텐츠를 가장 빠른 속도로 전달(캐싱)하기 위해, 리전이나 가용 영역과는 별개로 전 세계 주요 도시 구석구석에 흩어져 있는 소규모 서버 거점
    • 특징/이점
      • 이미지, 비디오, 정적 자산 등 빈번히 조회되는 데이터를 최종 사용자 부근의 캐시에 보관하여 원천 리전 서버로 향하는 통신 거리를 획기적으로 낮추고 전송 속도를 단축함
      • Amazon CloudFront, Amazon Route 53, AWS Global Accelerator 등 핵심 엣지 네트워킹 서비스를 호스팅함
• 주요 엣지 및 관련 서비스
  • Amazon CloudFront
    • 정의
      • 웹 페이지, 비디오, 이미지, API 등 모든 동적/정적 웹 리소스를 낮은 지연 시간과 높은 속도로 최종 사용자에게 제공하는 글로벌 콘텐츠 전송 네트워크(CDN)
    • 특징/이점
      • 전 세계 엣지 로케이션망을 활용하여 밈 이미지나 대용량 파일 배포 속도를 향상시키고 트래픽 급증을 효과적으로 수용함
  • Amazon Route 53
    • 정의
      • 최종 사용자의 트래픽을 원활하게 AWS의 목적지 인프라로 연결 및 안내해 주는 클라우드 기반 고가용성 도메인 이름 시스템(DNS)
    • 특징/이점
      • 인간이 기억하기 편한 도메인 도식 문자열을 컴퓨터용 숫자형 IP 주소로 신속 변환하며 지연 시간이 최저인 최적의 서버 경로로 사용자를 라우팅함
  • AWS Outposts
    • 정의
      • AWS 인프라 서비스, API, 개발 도구를 고객의 자체 온프레미스 데이터 센터나 사무실 내부로 물리적으로 연장하여 직접 실행하게 지원하는 하이브리드 인프라 솔루션
    • 특징/이점
      • 극단적으로 높은 초저지연 로컬 데이터 처리가 필수적이거나, 특정 물리적 국가 경계 내에서만 데이터를 보관하고 동작시켜야 하는 엄격한 법률 규정을 완벽하게 만족함

인프라 및 자동화

• 코드형 인프라 (Infrastructure as Code, IaC)
  • 정의
    • 수동 클릭이나 개별 명령 실행 대신, 인프라의 모든 구성을 텍스트 파일(YAML, JSON 등)로 코딩하여 설계 청사진을 만드는 개발 방식
  • 특징/이점
    • 동일한 설정을 변경 없이 여러 차례 반복하여 신속하게 배포 가능
    • 콘솔 수동 조작 시 발생하는 인적 실수(오류)를 예방하고 재현하기 쉬운 환경 제공
    • Git 등의 소스 제어 도구를 활용하여 인프라 변경 이력을 체계적으로 관리 및 추적할 수 있음
• AWS CloudFormation
  • 정의
    • YAML 또는 JSON 형식의 CloudFormation 템플릿을 생성하여 대규모 AWS 리소스를 선언적 방식으로 정의하고 일괄 모델링/프로비저닝해 주는 AWS의 핵심 IaC 서비스
  • 특징/이점
    • 세부 빌드 명령어 대신 생성하고자 하는 리소스 스펙만 명시하면, CloudFormation이 알아서 백그라운드에서 AWS API를 호출하여 자원을 프로비저닝함
    • 여러 리전(Multi-Region)이나 다중 계정 전체에 동일 템플릿을 적용하여 오차 없는 고가용성 동일 환경을 손쉽게 복제하고 구축 시간 및 비용을 획기적으로 감축함
• AWS 리소스와의 상호 작용 (AWS API 호출 수단)
  • AWS Management Console
    • 정의
      • 웹 브라우저를 기반으로 시각적 UI 환경에서 마우스 클릭을 통해 AWS 리소스를 제어하고 조작하는 그래픽 관리 인터페이스 (GUI)
    • 특징/이점
      • 클라우드를 처음 다루는 초보자 또는 비개발자 직군도 진입장벽 없이 빠르게 액세스하여 조작할 수 있음
      • 청구 및 비용 대시보드 모니터링이나 시각 그래픽 중심의 특화 서비스(예: QuickSight, Neptune) 운영에 매우 유리함
  • 프로그래밍 방식 액세스 (Programmatic Access)
    • AWS CLI (Command Line Interface)
      • 정의
        • 로컬 컴퓨터 터미널이나 쉘 명령줄에서 명령어를 수동 입력하거나 스크립트 파일을 실행하여 AWS 리소스를 통제하는 도구
      • 특징/이점
        • 반복되는 인프라 관리 및 관리 태스크를 쉘 스크립트 자동화 작업(예: Amazon EBS 볼륨의 정기 백업 수행 스크립트)으로 구성할 수 있음
    • AWS SDK (Software Development Kit)
      • 정의
        • 개발자가 사용하는 프로그래밍 언어(Java, Python 등)에 호환되는 라이브러리 API를 제공하여, 자체 구축한 애플리케이션 소스 코드 내에서 AWS의 기능을 내재화하고 통합하게 돕는 소프트웨어 개발 키트
      • 특징/이점
        • 앱 백엔드 프로세스의 일부분으로 실시간 AWS 서비스를 기동할 수 있음 (예: SDK를 활용해 애플리케이션에 유입된 사용자의 파일을 Amazon S3 스토리지에 즉시 자동 저장)

서버리스 컴퓨팅 소개

• AWS 컴퓨팅 옵션 비교 (비관리형, 관리형, 서버리스)
  • 비관리형 서비스 (Unmanaged Services)
    • 정의
      • 기본적인 물리적 인프라만 AWS가 제공하고, 운영 체제(OS) 패치, 애플리케이션 설치, 네트워크/방화벽 구성 등 나머지 모든 구성과 관리를 고객이 직접 제어하는 서비스
    • 대표 서비스
      • Amazon EC2
    • 특징
      • 인스턴스 전체에 대해 아주 높은 수준의 사용자 지정 제어 권한(Control)을 제공하지만, 사용자의 유지보수 및 관리 오버헤드가 큼 (수동 관리)
  • 관리형 서비스 (Managed Services)
    • 정의
      • 사용자가 자신의 요구사항에 맞춰 초기 설정을 구성하면, 가동 유지, 패치, 업그레이드, 장애 극복 등의 운영 작업을 AWS가 백그라운드에서 직접 처리해주는 서비스
    • 대표 서비스
      • Elastic Load Balancing (ELB), Amazon SQS, Amazon SNS 등
    • 특징
      • 인프라 관리 부담을 줄여주므로 사용자는 인프라 유지보수보다 애플리케이션 구축 및 비즈니스 로직 설계에 집중할 수 있음
  • 서버리스/완전관리형 서비스 (Serverless / Fully Managed)
    • 정의
      • 사용자가 애플리케이션을 구동하기 위한 가상 서버나 리소스를 직접 보거나 관리할 필요가 전혀 없는 서비스
    • 대표 서비스
      • AWS Lambda 등
    • 특징
      • 리소스 프로비저닝, 고가용성, 하드웨어 유지 관리, 자동 스케일링이 모두 완전 자동 처리되며 사용자는 작성한 코드 자체만 배포하고 관리함 (편의성에 최적화)

aws 서버리스, 컨테이너, 솔루션 개요

aws lambda

• AWS Lambda
  • 정의
    • 서버를 별도로 프로비저닝하거나 직접 관리하지 않고도, 특정 이벤트(트리거)에 반응하여 코드를 바로 실행하는 대표적인 서버리스(Serverless) 컴퓨팅 서비스
  • 작동 원리
    • 사용자가 코드를 작성하여 Lambda 함수로 업로드하고 이벤트 소스(S3 파일 업로드, SQS 메시지 생성, HTTP 요청 등)를 트리거로 세팅함
    • 해당 이벤트가 발생할 때만 코드가 가동되며, 평상시 유휴 상태에는 하드웨어 리소스나 비용 소모가 없음
  • 요금 체계
    • 실제 코드가 수행된 시간(밀리초 단위로 정확히 계산) 및 함수에 할당한 메모리 용량 크기에 따라 비용이 부과됨
  • 실행 제한 (매우 중요)
    • 최대 지속 시간 제한: 15분
    • 15분 이내에 완료되지 않는 장기 프로세싱 작업에는 적합하지 않으며, 이 경우 다른 컴퓨팅 인스턴스를 선택하거나 작업을 15분 단위 세그먼트로 분리해야 함
  • 프로그래밍 언어 지원
    • Java, Python, Node.js 등을 런타임 환경으로 기본 지원하며, 기타 언어는 사용자 지정 런타임(Custom Runtime)을 구축하여 가동 가능
  • AWS 서비스 통합 및 데모 (SQS 트리거 기반 Lambda 작동 프로세스)
    • 1. 큐 및 메시지 준비
      • SQS 콘솔에서 대기열을 생성한 뒤 테스트 메시지(페이로드)를 전송하여 대기시킴
    • 2. 청사진 (Blueprint) 활용
      • 빠른 연동 테스트를 위해 SQS와 연계된 검증된 템플릿(청사진)을 활용하여 Node.js, Python 등의 런타임 환경으로 Lambda 함수(예: Lambert)를 신속하게 생성함
    • 3. 실행 역할 (Execution Role) 설정
      • Lambda 함수가 SQS 대기열을 지속적으로 감시하고 메시지를 가져올 수 있도록 Amazon SQS 폴러 정책 템플릿 권한이 인가된 전용 실행 역할(예: Demo_Lambert_Role)을 반드시 지정해 주어야 함
    • 4. 트리거 (Trigger) 매핑
      • 대상 SQS 대기열을 Lambda 함수의 유효한 트리거 소스로 구성하여 연결 설정을 완료함
    • 5. 메시지 폴링 및 자동 삭제
      • SQS 대기열에 새로운 메시지가 유입되면 Lambda 함수가 이를 인지하여 지극히 빠른 속도로 메시지를 가공/처리하며, 처리가 성공한 메시지는 SQS 대기열에서 자동으로 영구 소멸됨
    • 6. 모니터링 및 로깅 감사
      • Lambda 콘솔의 Monitor 탭을 통해 지표를 조회하거나, 연동된 Amazon CloudWatch Logs의 로그 그룹(Log Groups) 및 로그 스트림(Log Streams)을 열어 함수가 처리한 실제 데이터 내용과 ID 로그를 검증하고 감사 추적할 수 있음
• Lambda 사용 사례
  • 실시간 이미지 처리
    • 정의: 소셜 미디어 등에 사진 업로드 시 Lambda가 트리거되어 썸네일 크기로 변환 및 필터 처리 자동화
  • 개인화 콘텐츠 전송
    • 정의: 뉴스 피드 접속 등의 이벤트 트리거 시 사용량에 따라 개인 추천 엔진을 자동 가동 및 최적 데이터 송신
  • 온라인 게임의 실시간 이벤트 처리
    • 정의: 점수 획득, 업적 해제 등의 이벤트를 수천 명의 플레이어로부터 실시간으로 받아 서버리스 상태에서 갱신 및 처리

aws 기반의 컨테이너 및 오케스트레이션

• 컨테이너 (Containers)
  • 정의
    • 애플리케이션의 코드, 런타임, 라이브러리, 종속성, 설정 파일 등을 단일 패키지로 묶어 어떤 컴퓨팅 환경에서든 동일하게 작동하도록 격리하는 이식성 높은 가상화 환경
  • 컨테이너 vs 가상 머신(VM)
    • 컨테이너는 호스트 OS 커널을 공유하여 가볍고 부팅 속도가 매우 빠르며 리소스 효율성이 우수함
    • VM은 하이퍼바이저 위에서 각각 별개의 전체 OS를 가동하므로 속도가 느리고 인프라 자원을 상대적으로 많이 소모함
• 컨테이너 오케스트레이션 (Container Orchestration)
  • 정의
    • 수십~수천 개에 이르는 컨테이너의 전체 수명 주기(시작, 중지, 업데이트, 네트워킹, 오토 스케일링, 오류 복구 등)를 자동화하여 통합 관리해 주는 서비스
• AWS 컨테이너 서비스 분류
  • 1. 레지스트리 (Registry)
    • Amazon ECR (Elastic Container Registry): 컨테이너 이미지를 보관하는 ‘창고’
      • 정의: 안전하게 컨테이너 이미지를 보관, 관리, 배포하는 완전 관리형 OCI 표준 준수 레지스트리 서비스
  • 2. 오케스트레이션 (Orchestration)
    • Amazon ECS (Elastic Container Service)
      • 정의: Docker 컨테이너를 가동 및 관리할 수 있도록 지원하는 AWS 독자적인 고성능 컨테이너 오케스트레이션 서비스
      • 특징: 간소하고 통합된 기능 제공. 소규모 팀이나 트래픽 유동성이 있는 애플리케이션 구축에 적합
    • Amazon EKS (Amazon Elastic Kubernetes Service)
      • 정의: 오픈소스 컨테이너 관리 프레임워크인 Kubernetes를 AWS 환경에서 쉽게 다룰 수 있게 보장하는 관리형 서비스
      • 특징: 오픈소스 생태계 통합 및 하이브리드/대규모 배포 시 우수한 통제력과 유연성을 제공함
  • 3. 컴퓨팅/호스팅 플랫폼 (Compute Platforms)
    • Amazon EC2 시작 유형
      • 정의: 가상 서버 인프라를 사용자가 직접 구성하고 가상 머신 수준의 세부 설정을 제어하는 방식
      • 특징: 하드웨어 및 특수한 네트워크 설정의 커스터마이징이 가능하나 서버 유지 관리 오버헤드가 수반됨
    • AWS Fargate 시작 유형
      • 정의: 서버를 프로비저닝하거나 관리할 필요가 없는 컨테이너 전용 서버리스(Serverless) 컴퓨팅 엔진
      • 특징: 컨테이너의 배치 및 가동 스케일링을 AWS가 100% 관리해주며 사용자는 사용한 컨테이너 자원에 대해서만 지불함 (ECS와 EKS 모두 Fargate 시작 유형을 지원함)

추가 컴퓨팅 서비스

• AWS Elastic Beanstalk
  • 정의
    • Java, Python, Node.js, Docker 등으로 작성된 웹 애플리케이션 및 서비스를 신속하게 배포, 관리, 스케일링할 수 있도록 돕는 완전 관리형 서비스 (PaaS)
  • 특징
    • 사용자가 소스 코드와 구성 설정만 업로드하면 인프라 프로비저닝, 오토 스케일링, 로드 밸런싱, 애플리케이션 상태 모니터링을 자동으로 대행함
    • 인프라를 직접 구축할 필요는 없지만, 프로비저닝된 하위 AWS 기본 리소스(EC2 등)에 대한 세부적인 제어 및 수정 권한은 여전히 소유함
  • 적합한 대상
    • 인프라 설정 복잡성을 줄이고 즉시 배포하려는 웹 애플리케이션, RESTful API, 마이크로서비스
• AWS Batch
  • 정의
    • AWS 인프라 리소스를 직접 관리할 필요 없이 대규모 병렬 배치(Batch) 컴퓨팅 워크로드를 자동으로 예약하고 실행해 주는 완전 관리형 서비스
  • 특징
    • 작업의 우선순위와 컴퓨터 리소스 사양에 맞춰 필요한 최적의 컴퓨팅 인프라(EC2 등) 풀을 자동으로 증설, 스케일링, 배포 및 회수함
  • 적합한 대상
    • 과학 계산 시뮬레이션, 대용량 빅데이터 및 유전체 분석 처리, 미디어 트랜스코딩, 기계 학습 모델 훈련
• Amazon Lightsail
  • 정의
    • 저렴하고 예측 가능한 정액제 월별 요금으로 가상 프라이빗 서버(VPS), 인스턴스, 스토리지, DB, 네트워킹을 간편하게 패키지로 제공하는 서비스
  • 특징
    • 복잡한 AWS 관리 콘솔의 설정 없이도 매우 간단한 제어판을 제공하여 인프라 구축의 허들을 대폭 낮춤
  • 적합한 대상
    • 소규모 비즈니스 웹사이트, 저트래픽 개인 블로그(예: WordPress), 개발자 학습용 샌드박스, 단순한 개발/테스트 환경
• AWS Outposts
  • 정의
    • AWS 클라우드 인프라, 서비스, API, 도구를 고객 온프레미스 데이터 센터나 로컬 물리 서버 환경으로 확장하여 서비스하는 완전 관리형 하이브리드 솔루션
  • 특징
    • AWS 퍼블릭 클라우드 환경과 자사 온프레미스 로컬 인프라 간에 완전히 일관된 작동 경험과 도구 세트를 제공함
  • 적합한 대상
    • 규정 준수 및 현지 법률로 인한 물리적 데이터 보존(Data Residency) 요구 충족, 로컬 레거시 시스템과의 연동을 위한 극도로 짧은 지연 시간(Low Latency) 요구 상황

0. 용어설명

• 워크로드

  • 어떤 하나의 완전한 서비스 시스템 단위

• 테넌시(Tenancy)

  • 가상 서버(EC2 인스턴스)가 물리적인 하드웨어(호스트 서버)에 배치되는 방식과 격리 수준을 결정하는 설정

1. amazon ec2 개요 및 기본 개념

• Amazon EC2 (Elastic Compute Cloud)
  • 정의
    • AWS 클라우드에서 크기 조정이 가능한 가상 서버(인스턴스)를 온디맨드로 임대하여 실행할 수 있는 서비스
  • 이점 및 작동 특징
    • 온프레미스 대비 물리적인 서버 인프라 구축 비용과 조달 시간이 전혀 들지 않음
    • 인스턴스가 실행 중(Running) 상태일 때만 사용한 시간만큼 비용을 지불하며, 중지(Stopped) 또는 종료(Terminated) 시 요금 부과가 중단됨
• 가상 머신(VM) 및 멀티테넌시 (Multi-tenancy)
  • 정의
    • 하나의 물리적인 호스트 컴퓨터 리소스를 여러 대의 독립적인 가상 머신(VM) 인스턴스가 분할하여 공유하는 환경
  • 하이퍼바이저 (Hypervisor)
    • 정의
      • 물리 호스트 컴퓨터 위에 가상 머신을 생성하고, 가상 머신 간 리소스 분배 및 철저한 격리를 보장하는 소프트웨어
    • 특징
      • AWS가 물리 호스트 하드웨어와 하이퍼바이저를 완전히 관리하므로, 고객은 복잡한 인프라 관리 없이 운영체제(OS) 수준에서 인프라를 통제함
  • 공유 테넌시 (Shared Tenancy)
    • 정의
      • 하나의 거대한 물리 서버 위에서 내 가상 서버(EC2)와 다른 고객들의 가상 서버가 이웃집처럼 함께 구동되는 방식(일반적인 멀티테넌시 형태)
  • 전용 테넌시 (Dedicated Tenancy)
    • 정의
      • 하드웨어 수준에서 다른 고객과 섞이는 것이 싫을 때, 해당 물리 서버 전체를 우리 회사 가상 서버들만 쓰도록 통째로 임대하는 방식(싱글 테넌시에 가까운 형태)
• EC2 제어 권한 및 스케일링
  • 통제 범위
    • Windows 또는 Linux 운영체제(OS) 선택 및 소프트웨어, 웹 애플리케이션, 데이터베이스 등의 완전 제어 및 설치 권한 보유
  • 수직적 스케일링 (Vertical Scaling)
    • 정의
      • 가동 중인 EC2 인스턴스의 리소스 한계를 넘었을 때, 해당 인스턴스의 사양(CPU, 메모리 크기 등)을 직접 더 크게 변경하는 방식 (스케일 업 / 스케일 다운)

2. amazon ec2 인스턴스 유형

• 인스턴스 패밀리 (Instance Families)
  • 정의
    • 특정 워크로드에 최적화하여 CPU, 메모리, 스토리지, 네트워킹 자원을 다양하게 배합한 가상 서버 규격 그룹
• 5가지 인스턴스 패밀리 분류 (시험 단골 주제)
  • 범용 (General Purpose)
    • 정의
      • 컴퓨팅, 메모리, 네트워킹 자원을 균등하고 균형 있게 제공하는 인스턴스
    • 적합한 태스크
      • 웹 서버, 코드 리포지토리 등. 워크로드의 자원 요구 수준을 사전에 잘 모르는 상태에서 시작할 때 권장됨
  • 컴퓨팅 최적화 (Compute Optimized)
    • 정의
      • 강력한 프로세서(CPU) 연산 파워에 고도로 집중된 인스턴스
    • 적합한 태스크
      • 게임 서버, 고성능 컴퓨팅(HPC), 배치 작업, 기계 학습(ML) 연산, 과학 모델링
  • 메모리 최적화 (Memory Optimized)
    • 정의
      • 대규모 데이터셋을 메모리(RAM) 위에서 빠르게 처리하기 위해 고용량 메모리를 장착한 인스턴스
    • 적합한 태스크
      • 메모리 내 데이터베이스(In-memory DB), 실시간 빅데이터 분석
  • 가속화된 컴퓨팅 (Accelerated Computing)
    • 정의
      • CPU 이외에 그래픽 카드(GPU)나 FPGA 등 하드웨어 가속기(보조 프로세서)를 장착하여 전용 가속 기능을 제공하는 인스턴스
    • 적합한 태스크
      • 부동 소수점 수 계산, 3D 그래픽 처리, 데이터 패턴 매칭
  • 스토리지 최적화 (Storage Optimized)
    • 정의
      • 로컬 스토리지에 존재하는 초대형 데이터셋에 대해 매우 높은 순차적 읽기/쓰기(I/O) 성능을 보장하는 인스턴스
    • 적합한 태스크
      • 분산 파일 시스템, 데이터 웨어하우스용 고성능 스토리지, 대용량 DB
• 인스턴스 크기 선택 및 가상화 유연성
  • 특징
    • 인스턴스 크기가 커질수록 컴퓨팅 용량이 늘어나지만 비용 또한 함께 증가하므로, 비즈니스 예산과의 균형을 맞추는 것이 중요함
    • 한 번 프로비저닝한 인스턴스 유형과 크기에 영구적으로 종속되지 않으며, 요구 성능에 따라 다른 규격으로 신속하게 변경 및 전환할 수 있음

3. aws 리소스를 프로비저닝하는 방법

• AWS API (Application Programming Interface)
  • 정의
    • AWS 서비스와 상호 작용하는 규칙을 사전에 정의해 둔 인터페이스
  • 특징
    • 리소스 생성, 변경, 삭제 등 AWS에서 수행되는 모든 관리 작업은 백그라운드에서 API 직접 호출 (API Call)을 통해 이루어짐
• AWS API 상호 작용 방법 3가지 (시험 단골 주제)
  • AWS Management Console (AWS 관리 콘솔)
    • 정의
      • 웹 브라우저를 기반으로 마우스 클릭을 통해 리소스를 제어하는 그래픽 사용자 인터페이스 (GUI)
    • 특징
      • 시각적이고 직관적이어서 클라우드 학습 초기 단계, 테스트 환경 구축, 예산/청구서 조회, 리소스 모니터링에 매우 적합함
      • 프로덕션 환경에서 대규모 리소스를 반복적으로 수동 배포할 경우, 체크 실수나 오타 등 휴먼 에러(수동 오류)가 발생할 위험이 있음
  • AWS CLI (Command Line Interface)
    • 정의
      • 운영체제의 터미널/명령줄을 사용하여 텍스트 기반 명령어로 AWS 서비스를 호출하는 도구
    • 특징
      • 텍스트 명령어(예: aws ec2 run-instances로 인스턴스 생성)를 통해 작동하므로, 셸 스크립팅 등을 이용한 자동화가 가능하여 오류 없는 예측 가능한 인프라 배포에 유리함
      • 브라우저 기반의 사전 설치 터미널인 AWS CloudShell을 통해서도 간편하게 실행할 수 있음
  • AWS SDK (Software Development Kit)
    • 정의
      • 특정 프로그래밍 언어(Python, Java, C# 등)용 라이브러리와 API 모음집을 제공하여 코드로 AWS 리소스를 다룰 수 있게 해주는 소프트웨어 개발 키트
    • 특징
      • 사용자의 애플리케이션 소스 코드 자체에 AWS 리소스 제어(인스턴스 목록 조회, 파일 업로드 등) 기능을 내장하여 고도로 정교한 프로그래밍 제어를 구현할 때 사용됨
• 컴퓨팅 및 공동 책임 (Shared Responsibility in Computing)
  • 대전제
    • AWS는 클라우드 자체의 보안(하드웨어, 물리 인프라, 하이퍼바이저)을 담당함
    • 고객은 클라우드 내부의 보안(애플리케이션, 데이터, 액세스 제어)을 책임짐
  • 비관리형 서비스 (Unmanaged Services)의 책임 모델
    • 정의
      • 사용자가 필요한 인프라의 세부 설정, 보안 구성 및 관리 태스크를 직접 수행해야 하는 서비스
    • Amazon EC2 인스턴스 배포 시 고객의 책임 범위
      • 가상 가상 방화벽인 보안 그룹(Security Groups) 설정
      • 게스트 운영 체제(OS) 관리, 보안 패치 및 업데이트 적용
      • 데이터 암호화 및 인스턴스 내 구동 소프트웨어 보안 구성

4. 데모: amazon ec2 인스턴스 시작

• EC2 인스턴스 생성 시 주요 구성 요소 (시험 연계 포인트)
  • AMI (Amazon Machine Image)
    • 정의
      • 인스턴스를 시작하는 데 필요한 운영 체제(OS)와 기본 애플리케이션 구성이 들어 있는 템플릿
    • 구성 요소
      • 운영 체제 (OS), 스토리지 설정, 하드웨어 아키텍처 유형, 인스턴스 시작 권한, 사전 설치된 추가 소프트웨어
      • 단 1개의 AMI를 템플릿으로 사용하여 완전히 동일한 설정을 가진 다수의 EC2 인스턴스를 동시에 시작할 수 있음
    • AMI를 사용하는 3가지 방법 (획득 경로)
      • 자체 AMI 생성 (사용자 지정)
        • 필요에 따라 특정 소프트웨어 및 구성을 미리 세팅하여 빌드하는 나만의 맞춤형 이미지
      • 사전 구성된 AWS AMI
        • 일반적인 운영체제 및 핵심 소프트웨어가 탑재되어 AWS에서 기본 제공하는 표준 이미지
      • AWS Marketplace 구매
        • 특정 사용 사례에 맞추어 전문 서드 파티 공급업체가 소프트웨어를 구성하여 제공하는 인증된 이미지를 구매하여 사용
    • AMI의 반복성 (Repeatability)
      • 정의
        • 모든 새 인스턴스에 일관된 환경을 보장하여 재현 가능하게 만드는 특성
      • 이점
        • 개발 및 테스트 환경이 완벽히 일치하여 배포 규모 조정에 유리하고, 설정 누락 등 휴먼 에러를 대폭 줄이며, 대규모 클라우드 환경 관리가 매우 단순해짐
  • 인스턴스 유형 (Instance Type)
    • 정의
      • 인스턴스에 할당할 CPU 및 메모리 사양 결정 (예: t2.micro는 1 vCPU, 1GB RAM 제공)
  • 키 페어 (Key Pair)
    • 정의
      • 생성된 인스턴스에 안전하게 원격 접속하기 위한 비밀키 인증 방식
    • 특징
      • AWS 클라우드에 삽입되는 퍼블릭 키(Public Key)와 사용자가 다운로드하여 로컬에 안전하게 보관하는 프라이빗 키(Private Key) 한 쌍으로 작동함
  • 네트워크 설정 (Network Settings)
    • 특징
      • 인스턴스로 들어오고 나가는 네트워크 트래픽 규칙 설정 (예: 외부 인터넷 사용자의 웹 서비스 접속을 위해 HTTP 트래픽 허용 옵션 활성화)
  • 스토리지 구성 (Configure Storage)
    • 특징
      • 인스턴스에 가상 디스크 공간을 추가하는 설정 (예: gp3 EBS 볼륨을 할당하여 저장 공간 제공)
  • 사용자 데이터 (User Data)
    • 정의
      • 인스턴스가 최초 부팅(시작)될 때 백그라운드에서 자동으로 딱 한 번 실행되는 셸 스크립트
    • 특징
      • 부팅 시점에 소프트웨어 자동 설치 및 환경 설정 작업을 자동화할 수 있음 (예: Nginx 웹 서버 자동 설치 및 기동 스크립트 구동)
• 가동 확인
  • 특징
    • 인스턴스가 실행 중(Running) 상태가 되면, 할당된 퍼블릭 IP 주소를 웹 브라우저 주소창에 입력하여 Nginx 등 가동 중인 웹 서버의 작동 여부를 즉시 검증할 수 있음

5. amazon ec2 요금

• EC2 6가지 핵심 요금 옵션 (시험 필수 출제)
  • 온디맨드 인스턴스 (On-Demand)
    • 정의
      • 장기 약정이나 선불금 없이, 인스턴스가 실행(Running)되는 동안 사용한 컴퓨팅 용량에 대해서만 비용을 지불하는 모델
    • 특징
      • 사용 패턴의 기준치(Baseline)를 파악하지 못한 초기 단계, 단기 테스트 및 실험, 예측이 불가능한 워크로드에 가장 권장됨
  • 절감형 플랜 (Savings Plans)
    • 정의
      • 1년 또는 3년 기간 동안 시간당 일정 수준의 컴퓨팅 사용량(예: 시간당 $10 등)을 유지하기로 약정하여 최대 72%의 비용을 절감하는 요금제
    • 특징
      • 유연성이 매우 높음. 인스턴스 패밀리, 크기, OS, 테넌시, 리전 변경에 제약을 받지 않고 EC2 할인 적용 가능
      • EC2뿐만 아니라 Fargate, Lambda, SageMaker 사용량에도 동일하게 공유하여 할인이 적용됨
  • 예약 인스턴스 (Reserved Instances - RI)
    • 정의
      • 꾸준하고 예측 가능한 상태(Steady-state)의 워크로드에 대해 1년 또는 3년 기간으로 사용 약정을 체결하여 온디맨드 대비 최대 75% 비용을 절감하는 옵션
    • 특징
      • 3가지 결제 옵션 제공: 전액 선결제(All Upfront), 부분 선결제(Partial Upfront), 선결제 없음(No Upfront)
      • 동일 인스턴스 패밀리 내에서 유연한 크기 조정 및 리전 내 여러 가용 영역(AZ)에 할인이 자동 적용됨
  • 스팟 인스턴스 (Spot Instances)
    • 정의
      • AWS 내부의 미사용 예비 컴퓨팅 용량을 요청하여 온디맨드 가격 대비 최대 90% 할인된 가격으로 사용하는 인스턴스
    • 특징
      • AWS에 용량이 부족해지면 인스턴스가 언제든지 강제 회수(중단)될 수 있으며, 회수 전 2분의 경고(알림)가 제공됨
      • 시스템이 중단되어도 무방한 유연한 시작/종료 일괄(배치) 처리 작업, 데이터 분석, 대규모 테스트 워크로드에 매우 적합함
  • 전용 호스트 (Dedicated Hosts)
    • 정의
      • 고객이 독점적으로 사용할 수 있도록 완전히 분리된 실제 물리적 서버 전체를 예약하는 방식
    • 특징
      • 인스턴스의 하드웨어 물리 배치 및 리소스 할당을 직접 완벽하게 제어할 수 있음
      • 기존 소프트웨어 라이선스(BYOL - Bring Your Own License, 예: Windows, SQL Server)를 그대로 유지해야 하거나, 극도로 엄격한 물리 격리 및 규정 준수 요구가 있는 경우 사용
  • 전용 인스턴스 (Dedicated Instances)
    • 정의
      • 다른 AWS 계정 고객의 인스턴스와 물리적으로 격리된 단일 테넌트 하드웨어에서 실행되는 인스턴스
    • 특징
      • 전용 호스트와 달리 실제 물리 서버의 인스턴스 배치나 리소스 세부 할당 제어 권한은 갖지 못하지만, 계정 수준의 물리적 격리 혜택과 공유 인프라의 유연성을 동시에 가질 수 있음
• Amazon EC2 용량 예약 (Capacity Reservations)
  • 정의
    • 특정 가용 영역(AZ)에서 컴퓨팅 용량을 확실하게 미리 확보해 두는 설정
  • 특징
    • 예약한 리소스를 실제로 실행하지 않고 비워두더라도 온디맨드 요금과 동일하게 요금이 청구됨
    • 용량 요구 사항이 엄격하고 절대 서비스 중단이 발생하면 안 되는 중요한(비즈니스 크리티컬) 워크로드에 사용됨

자동 스케일링 및 로드 밸런싱

1. Amazon EC2 스케일링

• 확장성 (Scalability) vs 탄력성 (Elasticity)
  • 확장성 (Scalability)
    • 정의
      • 늘어난 로드를 정상 처리하기 위해 자원을 추가할 수 있는 시스템의 구조적 능력
    • 특징
      • 단기적인 스케일링보다 주로 예상되는 성장을 감당하기 위한 장기적인 용량 계획에 활용됨
  • 탄력성 (Elasticity)
    • 정의
      • 실시간 수요의 변화에 따라 필요 리소스를 자동으로 확보하거나 불필요 리소스를 차단하는 동적 조절 기능
    • 특징
      • 피크 트래픽 타임에는 자동 증설(스케일 아웃)하고, 한적한 밤 시간 등 수요가 적어지면 자동 해제(스케일 인)하여 최상의 비용 효율성을 보장함
• 수평적 스케일링 (Horizontal) vs 수직적 스케일링 (Vertical)
  • 수평적 스케일링 (스케일 아웃 / 스케일 인)
    • 정의
      • 인프라 자원 풀에 동일한 규격의 서버 인스턴스를 추가하거나 삭제하는 방식 (병렬 처리 개수를 증가시킴)
  • 수직적 스케일링 (스케일 업 / 스케일 다운)
    • 정의
      • 구동 중인 개별 단일 가상 서버 자체의 사양(CPU 파워, 메모리 용량 등)을 높이거나 낮추는 방식
• 고가용성을 위한 다중 가용 영역(AZ) 이중화 배포
  • 특징
    • 단일 장애점(SPOF - Single Point of Failure)을 방지하기 위해, 동일 아키텍처의 중복 인스턴스들을 서로 다른 가용 영역(AZ)에 분산 배포하는 것을 모범 설계 사례로 규정함
• Amazon EC2 Auto Scaling
  • 정의
    • 서비스 수요 변화에 발맞춰 실행 중인 EC2 인스턴스의 개수를 자동으로 증감시켜 가용성을 확보하는 완전 관리형 서비스
  • 작동 조건
    • Amazon CloudWatch가 수집한 핵심 지표(CPU 사용률, 네트워크 입출력 등) 데이터를 모니터링하여 자동으로 스케일링 작업이 트리거됨
  • 2가지 조정 접근 방식 (시험 출제율 높음)
    • 동적 스케일링 (Dynamic Scaling)
      • 실시간 수요 및 트래픽 변동치(예: CPU 점유율 80% 초과)에 즉각 반응하여 자원을 늘림
    • 예측 스케일링 (Predictive Scaling)
      • 과거 데이터 패턴과 기계 학습을 통해 예상되는 트래픽 패턴을 예측하고 미리 적절한 수의 인스턴스를 선제적으로 확보함
  • Auto Scaling 그룹 (ASG)의 3가지 핵심 설정값 (시험 빈출)
    • 최소 용량 (Minimum Capacity)
      • 정의: 워크로드를 상시 가동하기 위해 유지해야 하는 물리적 최소 인스턴스 수. 시스템이 이 수치 이하로는 축소되지 않음
    • 원하는 용량 (Desired Capacity)
      • 정의: Auto Scaling이 최적의 상태로 가동하기 위해 목표로 삼는 이상적인 인스턴스 수. 기본적으로 최소 용량과 연동됨
    • 최대 용량 (Maximum Capacity)
      • 정의: 트래픽 폭발 시 비용 과다 지출 및 초과 스케일링을 제한하는 인스턴스 개수의 상한선 임곗값

2. Elastic Load Balancing을 사용하여 트래픽 전달

• Elastic Load Balancing (ELB)
  • 정의
    • 들어오는 애플리케이션 트래픽을 EC2 인스턴스, 컨테이너, IP 주소 등 여러 대상에 자동으로 분산시켜 시스템 성능과 신뢰성을 최적화하는 완전 관리형 부하 분산 서비스
  • 특징
    • 외부 인터넷 트래픽(퍼블릭)뿐만 아니라 내부 백엔드 아키텍처 티어 간의 트래픽(프라이빗)도 관리할 수 있음
    • 로드 밸런서 자체의 스케일링이 자동으로 수행되어, 트래픽 유동성에 탄력적으로 대응함
• ELB의 핵심 이점 (시험 연계)
  • 효율적인 트래픽 분산
    • 정의
      • 여러 가용 서버들로 트래픽을 고르게 나누어 단일 서버의 오버로드를 예방하고 전반적인 리소스 사용을 극대화함
  • Auto Scaling과의 연동 및 고가용성 보장
    • 정의
      • Auto Scaling 그룹과 직접 유기적으로 연동하여, 백엔드 인스턴스가 생성되거나 해제될 때 동적으로 라우팅 풀에 추가 및 제외시킴
      • 사용 가능한 정상 서버(인스턴스)로만 요청을 분산하여 무중단 상태를 유지함
  • 시스템 결합 해제 (Decoupling) 및 관리 간소화
    • 정의
      • 프런트엔드 서비스가 개별 백엔드 인스턴스의 유동적인 IP를 직접 추적할 필요 없이, ELB가 제공하는 단일 웹 URL(단일 접점)만 바라보도록 설계하여 시스템 의존성을 완전히 분리함
      • 하드웨어 패치, 유지 보수, 장애 복구 등의 수동 운영 오버헤드를 경감시킵니다.
• ELB의 4가지 주요 라우팅 방법
  • 라운드 로빈 (Round Robin)
    • 정의
      • 가동 중인 사용 가능한 모든 서버에 순차적으로 트래픽을 균등하게 분산시킴
  • 최소 연결 (Least Connections)
    • 정의
      • 현재 활성화된 세션/연결 수가 가장 적은 서버를 식별하여 새 트래픽을 라우팅함
  • IP 해시 (IP Hash)
    • 정의
      • 클라이언트의 IP 주소를 고유값으로 매핑하여 항상 지정된 동일 서버로 일관되게 트래픽을 보냄 (세션 유지 필요 시 유용)
  • 최소 응답 시간 (Least Response Time)
    • 정의
      • 응답 대기 시간이 가장 신속한 서버를 찾아 트래픽을 우선 전달하여 대기 시간을 최소화함

3. 메시징 및 대기열 처리

• 애플리케이션 아키텍처와 결합도 (Coupling)
  • 긴밀한 결합 (Tightly Coupled) / 모놀리스 (Monolith) 아키텍처
    • 정의
      • 애플리케이션의 모든 구성 요소(데이터베이스, 웹 서버, 비즈니스 로직 등)가 서로 직접 연결되어 동기적으로 통신하는 방식
    • 단점
      • 단 하나의 구성 요소에 장애가 발생하더라도 전체 시스템이 중단되는 연쇄 실패가 발생할 위험이 큼
  • 느슨한 결합 (Loosely Coupled) / 마이크로서비스 (Microservices) 아키텍처
    • 정의
      • 각 구성 요소가 독립된 엔터티로 분리되어 메시지 대기열이나 이벤트를 통해 비동기적으로 간접 통신하는 방식
    • 장점
      • 특정 서비스에 장애가 발생해도 버퍼(대기열)가 메시지를 안전하게 보관하므로, 전체 시스템으로 장애가 전파되지 않고 가용성과 복원력이 유지됨
• 느슨한 결합을 지원하는 3대 AWS 통신 서비스 (시험 단골 주제)
  • Amazon SQS (Simple Queue Service)
    • 정의
      • 소프트웨어 구성 요소 간에 모든 대규모 메시지를 전송, 저장, 수신할 수 있도록 지원하는 비동기식 메시지 대기열 서비스 (Pull 방식)
    • 작동 원리
      • 보낸 쪽(송신자)이 메시지 데이터를 대기열에 담아두면, 받는 쪽(수신자)이 원할 때 대기열에서 이를 꺼내(검색) 처리한 뒤 메시지를 명시적으로 삭제함
    • 장점
      • 수신 서버가 일시적으로 가동 중단되거나 트래픽이 급증(버스트)해도 대기열에 메시지가 안전하게 보존되므로 데이터 유실을 완전 방지함
  • Amazon SNS (Simple Notification Service)
    • 정의
      • 게시자-구독자(Pub-Sub) 모델을 기반으로, 하나의 주제(Topic)에 등록된 다수의 구독자들에게 알림 메시지를 즉시 전송하는 완전 관리형 서비스 (Push 방식)
    • 작동 원리
      • 게시자가 특정 메시지를 게시하면, 대기하지 않고 모바일 푸시 알림, SMS 문자, 이메일, HTTP 웹훅 또는 Lambda 함수 등의 구독자들에게 즉각 전달(팬아웃)함
    • SQS와의 결정적 차이점
      • SQS는 메시지가 처리될 때까지 대기열에서 수령을 기다리지만, SNS는 수령 대기 없이 즉각적인 푸시 응답 및 다중 전송을 수행함
  • Amazon EventBridge
    • 정의
      • 다양한 소스(자체 커스텀 앱, AWS 서비스, 서드파티 SaaS 소프트웨어)에서 발생하는 실시간 데이터를 이벤트 버스(Event Bus)를 통해 다른 타깃 애플리케이션으로 안전하게 라우팅하는 서버리스 이벤트 버스 서비스
    • 장점
      • 이벤트 기반 시스템(Event-Driven System)의 중앙 허브 역할을 하여 서비스 간 통신 흐름의 수신, 필터링, 변환, 라우팅 처리를 극도로 단순화함

aws 클라우드

1. 클라우드 컴퓨팅 개요

• 클라우드 컴퓨팅의 정의
  • 인터넷을 통해 IT 리소스(컴퓨팅 파워, 스토리지, 데이터베이스 등)를 온디맨드(On-Demand)로 제공하고 사용한 만큼 종량제(Pay-as-you-go) 요금으로 지불하는 모델
• 세부 핵심 개념 (시험 빈출 포인트)
  • 온디맨드 (On-Demand)
    • 필요한 만큼 즉시 리소스를 사용하고, 불필요해지면 즉시 삭제하여 요금 청구를 중단할 수 있는 유연함
  • 인터넷을 통한 원격 액세스
    • 인터넷 연결과 웹 브라우저만 있으면 전 세계 어디서든 AWS 계정에 로그인하여 물리적 접촉 없이 인프라를 프로비저닝하고 관리할 수 있음
  • 종량제 요금 (Pay-as-you-go)
    • 약정 계약이나 복잡한 승인 절차 없이 사용하지 않는 인프라는 프로비저닝을 해제하여 비용 낭비를 방지
• 인프라 관리 부담 해소
  • 과거
    • 자체 데이터 센터(온프레미스)를 구축하여 하드웨어 구매, 전원, 냉각, 물리 보안 등을 직접 관리해야 했음
  • AWS 도입 후
    • 사용자는 물리적 인프라를 관리할 필요가 없어짐. 이로 인해 반복적이고 리소스 소모적인 인프라 유지 관리 태스크에서 벗어나 팀이 비즈니스 혁신과 가치 창출에만 집중할 수 있음
• 클라우드 배포 모델 (Cloud Deployment Models)
  • 클라우드 기반 배포 (Cloud-Based Deployment / Public Cloud)
    • 정의
      • 모든 애플리케이션 리소스를 클라우드(예: AWS)에 구축하거나 기존 시스템을 클라우드로 마이그레이션하여 운영하는 모델
    • 특징
      • 리소스가 클라우드 서비스 제공업체의 데이터 센터에 존재하므로, 물리적 인프라 및 가상화 제어에 대한 관리 부담이 전혀 없음. 온디맨드 스케일링과 유연한 비용 구조의 이점을 극대화할 수 있음
  • 온프레미스 배포 (On-Premises Deployment / Private Cloud)
    • 정의
      • 자체 데이터 센터 내부에서 가상화 및 자원 관리 도구(Hypervisor 등)를 활용하여 사설 인프라를 운영하는 모델
    • 특징
      • 하드웨어와 가상화 인프라를 자사가 완전히 소유하고 직접 통제하므로 규정 준수나 보안 통제력은 높지만, 시스템 구축 및 유지 보수에 필요한 모든 기술/자본 비용을 직접 부담해야 함. 탄력성과 유연한 확장은 제한적임
  • 하이브리드 배포 (Hybrid Deployment)
    • 정의
      • 클라우드 기반 리소스와 기존 온프레미스 레거시 시스템을 네트워크(VPN, Direct Connect 등)로 결합하여 상호작용하도록 하는 모델
    • 특징
      • 두 배포 방식의 이점을 결합. 예컨대 규정 준수와 데이터 보안이 중요한 레거시 데이터베이스는 온프레미스에 유지하고, 트래픽 유동성이 심한 프런트엔드 애플리케이션은 퍼블릭 클라우드에 배포하여 리소스를 유연하게 연동함

2. aws 클라우드의 이점

• 고정 비용을 가변 비용으로 대체 (Trade upfront expense for variable expense)
  • 정의
    • 전통적인 온프레미스는 서버, 공간, 유지 관리 등 대규모 선행 투자(고정 비용)가 필요하며 자원 사용률과 관계없이 비용이 나감
  • 특징
    • AWS는 대대적인 투자 없이 소규모로 시작할 수 있고, 매달 실제 사용한 만큼만 지불(가변 비용)하여 유연하게 예산을 절감함
• 거대한 규모의 경제로 이익 달성 (Benefit from massive economies of scale)
  • 정의
    • AWS가 전 세계 수백만 고객의 자원을 위해 대량의 하드웨어를 대규모로 구매하므로 단가가 낮아짐
  • 특징
    • 하드웨어 단가 절감 효과는 고객에게 더 저렴한 가격(종량제 요금 절감)의 혜택으로 직접 환원됨
• 용량 추정 불필요 (Stop guessing capacity)
  • 정의
    • 온프레미스는 향후 예상치를 예측하여 과도한 용량의 하드웨어를 선구매(낭비 우려)하거나, 과소 예측 시 서버 부족으로 서비스 장애 및 고객 이탈을 겪음
  • 특징
    • AWS는 예측이 필요 없으며, 필요할 때 즉시 리소스를 프로비저닝하고 스케일링 메커니즘을 사용해 몇 분 만에 자원을 늘리거나 줄일 수 있음
• 속도 및 민첩성 향상 (Increase speed and agility)
  • 정의
    • 테스트 환경을 즉각 가동하여 새로운 혁신을 위한 실험을 수행할 수 있음
  • 특징
    • 시도가 실패하면 해당 자원을 즉시 삭제하고 비용 발생을 멈출 수 있어, 인프라 획득 시간을 획기적으로 단축하고 개발 생산성을 높임
• 데이터 센터 운영 및 유지 관리 비용 투자 불필요 (Stop spending money running and maintaining data centers)
  • 정의
    • 데이터 센터의 서버 랙 장착, 전원 공급, 냉각 유지 등 물리적인 하드웨어 유지 보수는 모두 AWS가 전담함
  • 특징
    • 기업은 비즈니스 가치와 직접적인 관련이 없는 기계적이고 물리적인 데이터 센터 관리에 시간과 인력을 허비하지 않고 자사 비즈니스에만 집중 가능
• 몇 분 만에 전 세계에 배포 (Go global in minutes)
  • 정의
    • 해외 진출 시 현지 데이터 센터를 구축할 필요 없이, 전 세계의 AWS 리전에 즉시 애플리케이션을 배포 가능
  • 특징
    • 수개월~수년이 걸리던 전 세계 서비스 확장을 단 몇 분 만에 낮은 대기 시간(Latency)으로 실현함

3. aws 글로벌 인프라 소개

• 고가용성 및 내결함성의 정의
  • 고가용성 (High Availability)
    • 정의
      • 가동 중지 시간을 최소화하면서 시스템 및 애플리케이션에 계속 액세스할 수 있도록 보장하는 설계 방식
    • 특징
      • 단일 구성 요소의 실패(장애) 시 다른 구성 요소가 자동으로 그 역할을 대신하여 서비스를 유지함
  • 내결함성 (Fault Tolerance)
    • 정의
      • 시스템의 일부 구성 요소가 여러 개 실패하더라도 데이터 손실이나 서비스 중단 없이 완전히 정상 작동할 수 있도록 아키텍처에 복원력을 구축하는 수준
    • 특징
      • 단일 실패 지점(SPOF)을 제거하기 위해 이중화(Redundancy)를 극대화하는 방식
• AWS 글로벌 인프라 구성 요소
  • 리전 (Regions)
    • 정의
      • 전 세계 여러 지리적 영역에 독립적으로 분산되어 있는 물리적인 인프라 위치 그룹
    • 특징
      • 전 세계 고객과 가깝게 배치하여 네트워크 대기 시간(Latency)을 낮춤
      • 기업은 극단적인 재난 대처를 위해 여러 리전에 인프라를 분산하여 다른 리전으로 장애 조치(Failover)를 수행할 수 있음
  • 가용 영역 (Availability Zones - AZ)
    • 정의
      • 하나의 AWS 리전 내에서 지리적으로 분리되고 격리된 데이터 센터의 클러스터(위치 그룹)
    • 특징
      • 각 리전은 가동 중지 대비 및 고가용성(이중화)을 위해 최소 3개 이상의 AZ를 포함함
      • 한 AZ의 자연재해나 정전이 다른 AZ에 영향을 주지 않도록 충분한 물리적 거리를 두고 설계됨
  • 데이터 센터 (Data Centers)
    • 정의
      • 서버와 네트워크 하드웨어가 설치된 개별적인 물리 건물
    • 특징
      • 각 가용 영역(AZ)은 하나 이상의 독립된 데이터 센터로 구성됨
      • 각 데이터 센터는 중복된 전력(발전기 등), 냉각 시설, 그리고 물리 및 네트워크 연결망을 보유함

4. aws 공동 책임 모델

• 모델의 기본 개념
  • 정의
    • AWS와 고객이 클라우드 환경의 보안을 보장하기 위해 각자의 역할을 분담하는 책임 모델
  • 대전제
    • AWS의 책임
      • 클라우드 자체의 보안 (Security OF the Cloud)
    • 고객의 책임
      • 클라우드 내부의 보안 (Security IN the Cloud)
• AWS의 책임 영역 (Security OF the Cloud)
  • 물리적 인프라 계층
    • 정의
      • 실제 하드웨어 서버, 데이터 센터 건물, 물리적 진입 보안 조치 및 하드웨어 액세스 제어
  • 글로벌 인프라 및 네트워크 계층
    • 정의
      • 전 세계 리전, 가용 영역, 엣지 로케이션에 구축된 네트워크 장비 및 케이블링 제어
  • 가상화 하이퍼바이저 계층
    • 정의
      • 물리적 서버 위에 격리된 가상 환경을 생성하여 각 고객의 워크로드를 안전하게 분리하는 소프트웨어 계층
• 고객의 책임 영역 (Security IN the Cloud)
  • 게스트 운영 체제 (OS)
    • 정의
      • 인스턴스에 탑재되는 운영 체제에 대한 관리 및 암호화 키 소유권
    • 특징
      • AWS는 고객 OS에 진입할 수 있는 백도어나 키가 없으므로, OS의 보안 패치 적용 및 취약점 조치 책임은 100% 고객에게 있음
  • 애플리케이션 및 플랫폼 보안
    • 정의
      • 고객이 직접 탑재하여 실행하는 웹 앱, 비즈니스 로직, 타사 소프트웨어 보안
  • 데이터 관리 및 접근 제어
    • 정의
      • 저장되는 데이터(소비자 정보, 금융/의료 데이터 등)의 외부 공개 범위 제어와 권한 설정
    • 특징
      • 데이터 암호화 설정 및 해독 키(KMS) 관리, IAM을 통한 계정 액세스 권한 제어는 전적으로 고객의 몫임

실제 환경에서의 클라우드

1. 클라우드 개념을 실제 사용 사례에 적용

• 글로벌 인프라 활용 (예: 글로벌 전자 상거래 회사)
  • 지연 시간 (Latency) 최적화
    • 특징
      • 인프라와 사용자의 물리적 거리가 멀어질수록 지연 시간이 길어짐
      • 아일랜드(eu-west-1) 또는 싱가포르(ap-southeast-1) 등 고객의 주요 기반에 가장 가까운 리전을 선택해 배포하여 성능을 극대화함
  • 초기 투자 배제 및 스타트업 경쟁력 확보
    • 특징
      • 대규모 사전 투자금 없이 즉시 글로벌 급 인프라를 확장하여, 소규모 기업이나 스타트업도 대기업과 대등하게 글로벌 비즈니스를 수행할 수 있음
  • 고가용성 및 복원력 설계
    • 특징
      • 최소 2개 이상의 가용 영역(AZ)에 완전히 동일한 환경을 배포함
      • 한 AZ에 장애가 나도 즉시 다른 AZ로 장애 조치(Failover)를 수행하여 중단 없는 서비스를 유지함
• 공동 책임 모델 활용
  • 보안 및 규정 준수 집중화
    • 특징
      • 기업은 물리 데이터 센터의 자물쇠 관리나 하드웨어 폐기 등 클라우드 자체의 보안을 직접 결정할 필요가 없음
      • 대신 결제 시스템의 신용카드 데이터 보안, 고객 접근 권한 제어 등 비즈니스에 직접적으로 중요한 고차원적인 보안(클라우드 내부의 보안)에 인력을 집중할 수 있음

• 하나의 Git 저장소 안에 다른 Git 저장소를 하위 디렉토리로 포함시켜 관리하는 기능임
• 메인 프로젝트에서 공통 라이브러리나 외부 모듈을 독립적으로 관리하고 싶을 때 사용함

왜 쓰는가?

• 공통 코드 관리: 여러 프로젝트에서 똑같이 사용하는 모듈이 있을 때, 매번 복사해서 붙여넣는 대신 서브모듈로 등록해서 코드 중복을 피할 수 있음
• 독립적인 버전 관리: 서브모듈은 특정 커밋 해시를 가리킴. 서브모듈 원격 저장소에 새로운 커밋이 올라가도 메인 프로젝트가 자동으로 영향을 받지 않음. 원하는 시점에 직접 업데이트를 결정할 수 있어 안전함
• 권한 분리: 메인 프로젝트 개발자와 서브모듈 개발자의 접근 권한을 다르게 설정할 수 있음

핵심 명령어 정리

1. 서브모듈 추가하기

git submodule add <서브모듈_저장소_URL> <로컬_디렉토리_경로>

• 명령어를 실행하면 메인 저장소 루트에 .gitmodules 파일이 생성됨
• 해당 파일에 서브모듈의 경로와 URL 정보가 기록되며, 메인 프로젝트는 서브모듈의 특정 커밋 해시를 가리키게 됨

2. 서브모듈이 포함된 프로젝트 클론하기

• 단순히 git clone <메인_저장소_URL>만 하면 서브모듈 디렉토리는 빈 폴더로만 나타남
• 서브모듈의 실제 소스코드까지 정상적으로 가져오려면 아래 두 가지 방법 중 하나를 선택해야 함

방법 A: 클론할 때 한 번에 가져오기

git clone --recursive <메인_저장소_URL>

방법 B: 이미 메인 프로젝트를 클론한 상태에서 가져오기

git submodule init
git submodule update
# 또는 한 줄로 해결
git submodule update --init --recursive

3. 서브모듈 업데이트하기

• 서브모듈 원격 저장소의 최신 커밋을 가져와서 업데이트하고 싶을 때 사용함

  git submodule update --remote

4. 서브모듈 변경사항 저장하고 푸시하기

• 서브모듈 디렉토리 내부에서 코드를 직접 수정한 경우의 프로세스임

1. 서브모듈 디렉토리로 이동하여 변경사항을 커밋하고 서브모듈 원격 저장소에 푸시함
2. 메인 프로젝트 디렉토리로 돌아와서 서브모듈의 변경된 커밋 해시 상태를 확인하고 메인 프로젝트 저장소에도 커밋 및 푸시를 진행함

• 메인 저장소에만 푸시하고 서브모듈 푸시를 깜빡하면 다른 팀원들이 코드를 당겨올 때 에러가 발생하므로 주의해야 함

주의할 점과 단점

• 커밋 해시 기반 관리: 메인 프로젝트는 서브모듈 내부 파일의 세부 변경 사항을 직접 관리하지 않고 특정 '커밋 해시'만 기록함. 이 구조를 이해하지 못하면 협업할 때 꼬이기 쉬움
• 싱크 맞추기 귀찮음: 팀원이 서브모듈 업데이트를 푸시한 경우, 다른 팀원들은 단순히 git pull만 해서는 안 되고 git submodule update를 추가로 실행해 주어야 함. 주기적으로 명령어를 쳐야 해서 번거로움
• 히스토리 추적의 한계: 메인 프로젝트 커밋 로그만 봐서는 서브모듈 내부에서 정확히 어떤 코드가 어떻게 바뀌었는지 파악하기 어려움

한 줄 요약

• 여러 프로젝트에서 공통으로 쓰는 핵심 모듈을 분리해서 깔끔하게 관리하고 싶다면 귀찮음을 감수하고 도입할 가치가 충분함. 단, 협업 시 팀원들과 서브모듈 동기화 규칙을 확실히 정해두어야 삽질을 막을 수 있음

개발자의 역할이 바뀌고 있다고 생각함.

지금까지 개발자는 이슈를 읽고, 분석하고, 구현하고, 검증하는 전 과정을 직접 담당했음. dev-nobiya는 이슈 확인부터 구현, 검증까지 Claude AI가 처리하고, 개발자는 최종 검토만 함.

이제 개발자는 짜는 사람이 아니라 보는 사람임.

dev-nobiya가 뭔데

이슈 트래커에 구현 명세를 작성하고 dev-nobiya run만 실행하면, 브랜치 생성부터 구현, 코드 리뷰, push, 이슈 상태 업데이트까지 자동으로 처리됨.

npm install -g dev-nobiya@beta
cd your-project
dev-nobiya setup   # 이슈 트래커 연동 (대화형)
dev-nobiya run     # 실행

Linear, GitHub Issues, Jira 세 가지를 지원하고, 현재 npm에 베타 버전으로 배포되어 있음.

파이프라인이 어떻게 돌아가냐

이슈 등록 (Todo 상태)
    ↓
브랜치 자동 생성 + 이슈 → In Progress
    ↓
플래닝: Claude가 work-plan.md 작성 → 검증 → 재플래닝  (최대 3회)
    ↓
구현: 태스크 순서대로 구현 → 자기검증 → 재구현  (최대 3회)
    ↓
코드 리뷰: 전체 diff 검토 → PASS/WARN/FAIL → 보완 후 재리뷰  (최대 5회)
    ↓
브랜치 push + 이슈 → Done + 알림 발송

모든 단계에 사이클 상한선이 있어서 AI가 루프에 갇히는 일이 설계상 발생하지 않음.

설계 포인트: 플래너와 검증자를 분리함

플래닝을 작성하는 Claude 세션과 그 플랜을 검증하는 Claude 세션이 분리되어 있음. 같은 세션이 스스로 검증하면 자기 결과물에 관대해지기 때문에, 독립된 세션이 "이 플랜이 요구사항을 제대로 반영했나"를 다시 확인함.

실제로 어떻게 쓰이냐

예를 들어 운영자가 Jira에 이런 이슈를 올렸다고 하면:

"메인 페이지 상단에 있는 dev-nobiya 로고 글자가 좀 작아 보입니다. 조금 더 크게 키워주시면 좋겠습니다."

개발자는 이걸 보고 구현 명세로 변환해서 별도 이슈를 등록함:

views/index.ejs에서 네비게이션 상단의 dev-nobiya 로고 텍스트 폰트 크기를 현재보다 10px 증가시킴. 완료 조건: 로고 텍스트가 기존보다 10px 크게 표시됨, 다른 레이아웃에 영향 없음.

이 상태에서 dev-nobiya run을 실행하면:

1. 이슈 ID 기반으로 브랜치가 자동 생성됨
2. Claude가 이슈를 읽고 work-plan.md를 작성함
3. views/index.ejs의 로고 클래스를 수정함
4. 코드 리뷰 세션이 diff를 검토하고 PASS 판정을 내림
5. 브랜치가 원격으로 push되고 이슈 상태가 Done으로 바뀜

코드는 한 줄도 직접 건드리지 않았음.

파이프라인 외에 붙어있는 것들

멀티 이슈트래커 Linear, GitHub Issues, Jira를 모두 지원함. 어느 트래커를 쓰든 dev-nobiya run 명령어 하나로 동작함.

한국어 / 영어 dev-nobiya setup 실행 시 언어를 선택할 수 있음.

실시간 알림 (Discord / Slack) 단순히 "완료됐습니다" 수준이 아님. 어떻게 구현했는지, 리뷰에서 어떤 문제가 발견됐는지, 왜 PASS 또는 FAIL 판정이 났는지까지 구체적인 내용이 메시지로 옴. 터미널을 켜놓고 기다릴 필요 없이 알림만 보고 AI가 지금 어디서 무엇을 하는지 파악할 수 있음.

만들면서 배운 것

Claude Code를 API가 아닌 CLI로 쓴 이유

처음에는 Anthropic API를 직접 호출하는 방식을 고려했음. 그런데 API는 파일 읽기/쓰기, 터미널 실행, 코드베이스 탐색 같은 도구 호출을 직접 구현해야 함. Claude Code CLI는 그 도구들이 이미 내장되어 있고, claude --print 옵션으로 비대화형 실행이 가능함. 별도 API 키 없이 Claude Code 구독만으로 동작하는 것도 장점임.

세션 분리가 품질을 높임

하나의 긴 세션이 전부 처리하는 것보다, 역할을 명확히 나눈 짧은 세션 여러 개가 더 나은 결과를 냄. 플래너, 검증자, 구현자, 리뷰어가 각자 독립된 컨텍스트에서 판단하게 하면 이전 단계의 편향이나 실수를 다음 단계가 잡아낼 수 있음.

루프에는 반드시 상한이 필요함

AI 세션을 루프로 돌릴 때 탈출 조건만 있으면 이론적으로 무한 루프에 빠질 수 있음. 플래닝 3회, 구현 3회, 리뷰 5회로 사이클 상한을 박아두고, 상한에 도달하면 현재 상태를 기준으로 무조건 다음 단계로 넘기는 구조가 필요함.

마치며

현재 로컬 환경 전용 베타 버전임. 별도 서버나 인프라는 필요 없음.

앞으로 추가하고 싶은 것들이 있음. 원격 실행, 웹 대시보드, 더 많은 이슈트래커 지원 등. 그런데 지금 당장 가장 필요한 건 실제로 써본 사람들의 피드백임.

써보고 불편한 점, 안 되는 케이스, 궁금한 점 GitHub Issues에 남겨주면 반영하겠음.

GitHub: https://github.com/csw9261/dev-nobiya npm: npm install -g dev-nobiya@beta

npm에 배포하기 전에 package.json을 제대로 채워야 함. 빠뜨리면 npm 페이지가 허전하거나 검색에 안 잡힘.

{
  "name": "패키지명",
  "version": "0.1.0-beta.1",
  "description": "패키지 설명 (영어 권장)",
  "license": "MIT",
  "author": "깃헙유저명",
  "homepage": "https://github.com/유저명/레포명",
  "repository": {
    "type": "git",
    "url": "https://github.com/유저명/레포명.git"
  },
  "bugs": {
    "url": "https://github.com/유저명/레포명/issues"
  },
  "keywords": ["키워드1", "키워드2"],
  "files": ["dist/", "prompts/"],
  "bin": {
    "명령어명": "./dist/index.js"
  }
}

각 항목 설명:

• keywords — npm 검색 노출에 직결됨. 핵심 키워드 10개 이내로
• files — npm에 올라갈 파일/디렉토리만 명시. src/, node_modules/ 등은 제외
• bin — CLI 툴이라면 필수. 명령어명으로 터미널에서 실행 가능해짐

2. 버전 관리 (semver)

npm은 major.minor.patch 형식의 semver를 따름.

베타 배포 시엔 프리릴리즈 태그를 붙임:

0.1.0-beta.1
0.1.0-beta.2

3. prepublishOnly 스크립트 추가

TypeScript 프로젝트라면 publish 전에 빌드가 자동으로 돌도록 설정해두는 게 좋음. 빌드 까먹고 올리는 실수 방지.

"scripts": {
  "build": "tsc",
  "prepublishOnly": "npm run build"
}

4. .gitignore vs npm 배포 파일

.gitignore와 npm에 올라가는 파일은 별개임.

• GitHub에 올라가는 것 → git이 추적하는 파일 전체
• npm에 올라가는 것 → package.json의 files 필드에 명시한 것만

즉 src/를 GitHub에 공개하면서 npm엔 dist/만 올리는 구조가 가능함.

배포 전 확인:

npm pack --dry-run  # 실제로 올라갈 파일 목록 미리 확인

5. npm 계정 및 2FA 설정

npm login  # 로그인
npm whoami  # 로그인 상태 확인

2FA가 활성화된 계정이라면 publish 시 인증이 필요함. npmjs.com에서 Granular Access Token을 발급받아 사용하면 편함:

1. npmjs.com → 프로필 → Access Tokens
2. Generate New Token → Granular Access Token
3. bypass two-factor authentication 체크
4. 토큰 복사

publish 시 토큰 사용:

npm publish --tag beta --//registry.npmjs.org/:_authToken=<토큰>

6. 베타 배포

--tag beta를 붙이면 @beta 없이는 설치가 안 됨. 일반 사용자가 실수로 불안정한 버전을 설치하는 걸 방지.

npm publish --tag beta

설치:

npm install -g 패키지명@beta   # beta 태그
npm install -g 패키지명        # stable (태그 없음)

7. 패치 배포 (업데이트)

코드 수정 후 배포할 때는 버전을 올리고 다시 publish:

# package.json version 수정 후
npm publish --tag beta

같은 버전으로 재배포는 불가. 반드시 버전을 올려야 함.

8. 배포 취소

• 72시간 이내 → npm unpublish 패키지명@버전 으로 완전 삭제 가능
• 72시간 이후 → 삭제 불가, deprecated 처리만 가능

npm deprecate 패키지명@버전 "This version is no longer maintained."

마치며

처음엔 복잡해 보이지만 한 번 해보면 별거 없음. 핵심은:

1. package.json 꼼꼼히 채우기
2. files 필드로 올라갈 파일 제어하기
3. 베타는 --tag beta로 안전하게 배포

1. 결론부터 — 거의 같은 도구임

두 환경은 같은 Claude Code 엔진을 공유함. 버전만 약간 다를 수 있음(앱은 번들된 버전, 터미널은 별도 설치).

확인 방법:

# 터미널 버전
which claude
# /Users/choi/.local/bin/claude
claude --version
# 2.1.145 (Claude Code)

# 앱이 번들한 Claude Code
ls ~/Library/Application\ Support/Claude/claude-code/
# 2.1.142  ← 앱 안에 Claude Code가 통째로 들어 있음

즉 앱은 Claude Code를 내장해서 GUI로 감싸 보여줄 뿐이고, 본질은 같음.

2. 무엇이 같은가 — ~/.claude/ 디렉토리 공유

가장 중요한 부분. 두 환경 모두 ~/.claude/ 를 똑같이 읽고 씀. 한쪽에서 만든 설정이 다른 쪽에 그대로 적용됨.

~/.claude/
├── CLAUDE.md                ← 전역 규칙 (양쪽 동일하게 로드)
├── settings.json            ← 설정 (양쪽 공유)
├── projects/
│   └── -Users-choi-Developer-dev-nobiya/
│       └── memory/          ← 자동 메모리 (양쪽 공유)
├── plugins/                 ← 플러그인
└── sessions/                ← 터미널 세션

따라서 다음은 양쪽에서 동일하게 동작함:

• ~/.claude/CLAUDE.md (전역 규칙)
• 프로젝트 루트의 CLAUDE.md (프로젝트 규칙)
• 자동 메모리 (~/.claude/projects/{경로}/memory/)
• Skills, Hooks, MCP 서버 설정
• 권한 / 환경변수 / 슬래시 커맨드

즉 터미널에서 정한 규칙을 앱에서도 그대로 쓸 수 있고, 반대도 마찬가지임. 메모리도 한쪽에서 쌓이면 다른 쪽에서 자동으로 로드됨.

3. 무엇이 다른가

UI / 렌더링

세션 저장 위치

이건 분리되어 있음:

같은 작업을 양쪽에서 하면 세션 히스토리는 따로 쌓임. 다만 메모리·규칙은 공유되므로 컨텍스트 자체는 이어서 사용 가능.

환경적 제약

• 터미널 — shell 환경 그대로. tmux, ssh, 원격 서버 작업과 자연스럽게 결합됨. 백그라운드 프로세스 다루기 편함.
• 앱 — 로컬 GUI 환경. 그래픽 출력(이미지, 다이어그램)이 더 직관적. 원격 서버 작업은 불편함.

4. 실용 가이드

규칙은 한 번만 작성하면 됨

같은 ~/.claude/CLAUDE.md를 양쪽이 읽으므로 중복 작성 불필요함. 프로젝트 규칙도 마찬가지로 프로젝트 루트의 CLAUDE.md 하나면 됨.

메모리도 자동으로 공유됨

앱에서 작업하면서 쌓인 메모리가 터미널에도, 또 그 반대도 자동 반영. 사용자가 직접 옮길 필요 없음.

어떤 걸 언제 쓰는 게 좋은가

팀 공유 관점

CLAUDE.md를 프로젝트 루트에 두고 git으로 커밋해두면 팀원이 어느 환경에서 Claude Code를 쓰든 같은 규칙으로 동작함. 환경별로 따로 공유할 필요 없음.

5. 한 줄 요약

• 터미널 Claude Code와 앱 Claude Code 탭은 같은 엔진, UI만 다름
• ~/.claude/ 디렉토리를 공유하므로 CLAUDE.md·메모리·Skills 모두 자동으로 양쪽에 적용됨
• 다른 건 세션 저장 위치와 UI/환경적 제약뿐
• 그래서 규칙은 한 번만 작성하면 됨

처음에는 별개의 도구처럼 보이지만, 실제로는 하나의 Claude Code를 두 가지 방식으로 띄운 것에 가까움. 환경에 맞춰 골라 쓰되, 규칙·메모리 관리는 한 곳에서 하면 됨.

OpenTelemetry Collector 같은 대형 프로젝트를 분석할 때 한 세션에서 전부 처리하려고 하면 문제가 생긴다.

LLM은 컨텍스트 윈도우 안에서 처리하는 정보가 많아질수록 집중도가 떨어지고, 분석 퀄리티도 함께 낮아진다. 소스가 클수록 "전체를 다 보여주는" 방식은 오히려 역효과다.

[X] 한 세션에서 전부 처리
소스 전체 → [단일 에이전트] → 퀄리티 낮은 분석

[O] 멀티에이전트
소스 전체 → 파트 분할 → [스페셜리스트 A] → 검토/검증
                       → [스페셜리스트 B] → 검토/검증  → 최종 합성
                       → [스페셜리스트 C] → 검토/검증

핵심 원칙은 단순하다. 좁은 컨텍스트 = 깊은 분석

접근법: 오케스트레이터 + 스페셜리스트

구조

오케스트레이터 (메인 세션)
  ├── 전체 구조 파악 및 분석 단위 확정
  ├── 서브에이전트들에게 파트 위임
  ├── 결과 검토 및 cross-cutting 검증
  └── 최종 합성
       ↑
스페셜리스트 에이전트들 (병렬 실행)
  ├── Agent A: 핵심 인터페이스 담당
  ├── Agent B: 데이터 수집/전송 담당
  ├── Agent C: 데이터 처리/라우팅 담당
  ├── Agent D: 서비스/확장 담당
  └── Agent E: 설정/인프라 담당

역할 분리

오케스트레이터는 깊이 파지 않는다. 스페셜리스트가 가져온 결과를 검토하고 검증하고 보완 요청하는 게 주 역할이다.

OpenTelemetry Collector에 적용

프로젝트 구조

OpenTelemetry Collector는 멀티모듈 Go 프로젝트로, 컴포넌트 경계가 명확하게 디렉토리로 나뉘어 있어 에이전트 분할에 적합하다.

opentelemetry-collector/
├── component/      # 핵심 인터페이스
├── pdata/          # 텔레메트리 데이터 모델
├── pipeline/       # 파이프라인 시그널 타입
├── consumer/       # 컨슈머 인터페이스
├── receiver/       # 데이터 수집
├── exporter/       # 데이터 전송
├── processor/      # 데이터 처리
├── connector/      # 파이프라인 라우팅
├── extension/      # 확장 기능
├── service/        # 서비스 오케스트레이션
├── otelcol/        # 메인 바이너리
├── confmap/        # 설정 처리
├── featuregate/    # 피처 플래그
└── internal/       # 내부 유틸리티

에이전트 분할 (5개)

구현: Claude Code Agent 툴

Claude Code에서 이 패턴은 별도 인프라 없이 내장 Agent 툴만으로 구현된다.

병렬 실행

# 메인 세션에서 여러 서브에이전트를 한 번에 호출
Agent(subagent_type="Explore", prompt="Core 분석: component, pdata...")
Agent(subagent_type="Explore", prompt="Receiver/Exporter 분석: receiver, exporter...")
Agent(subagent_type="Explore", prompt="Processor/Connector 분석: processor, connector...")
# → 병렬로 실행, 결과가 메인 세션으로 반환

결과 흐름

스페셜리스트 결과 반환
    ↓
오케스트레이터가 검토
    ↓
cross-cutting concerns 교차 검증
    ↓
누락 부분 보완 요청 (필요시 추가 에이전트 실행)
    ↓
최종 합성

프롬프트 설계 원칙

각 스페셜리스트 프롬프트에 반드시 포함해야 할 것:

1. 담당 범위 명시 - 어떤 디렉토리/패키지만 볼 것인지
2. 분석 포인트 - 인터페이스, 의존성, 핵심 로직 중 무엇에 집중할지
3. 결과 형식 - 오케스트레이터가 검토하기 좋은 구조화된 포맷
4. 경계 명시 - 다른 에이전트 담당 영역은 깊이 들어가지 않도록

오케스트레이터 프롬프트에 반드시 포함해야 할 것:

1. cross-cutting 체크리스트 - 각 에이전트 결과 간 연결 포인트
2. 검증 기준 - 누락/모순 여부 판단 기준
3. 보완 요청 조건 - 어떤 경우에 추가 분석을 요청할지

마치며

이 접근법의 핵심은 컨텍스트 관리다. LLM에게 많은 정보를 한꺼번에 주는 것보다, 적절히 쪼개서 각자 깊이 파게 하고 메인이 검증하는 구조가 실제로 더 나은 결과를 만든다.

대형 오픈소스 프로젝트 분석뿐 아니라, 복잡한 버그 디버깅이나 아키텍처 리뷰에도 같은 패턴을 적용할 수 있다.

핵심 개념

Alloy는 컴포넌트를 연결하는 방식으로 동작함.

[소스 컴포넌트] → [처리 컴포넌트] → [목적지 컴포넌트]
     (input)          (process)          (output)

설정 파일(.alloy)에서 컴포넌트를 선언하고 연결하면, Alloy가 그 흐름대로 데이터를 처리함.

역할 1: 수집 (Producer)

앱 서버에 에이전트로 설치되어 로그/메트릭을 읽어서 Kafka 등으로 전송.

파일 로그, stdout, 메트릭
    → Alloy (읽기 + 변환)
        → Kafka

loki.source.file "app" {
  targets    = [{ __path__ = "/var/log/app.log" }]
  forward_to = [otelcol.exporter.kafka.default.input]
}

otelcol.exporter.kafka "default" {
  brokers  = ["kafka:9092"]
  topic    = "logs"
  encoding = "otlp_proto"
}

역할 2: 소비 (Consumer)

Kafka 토픽의 메시지를 읽어서 ClickHouse / Loki 등 백엔드로 적재.

Kafka 토픽
    → Alloy (소비 + 변환)
        → ClickHouse / Loki

otelcol.receiver.kafka "default" {
  brokers  = ["kafka:9092"]
  topic    = "logs"
  encoding = "otlp_proto"

  output {
    logs = [otelcol.exporter.otlphttp.clickhouse.input]
  }
}

지원 입출력

입력 (받을 수 있는 것)

• 파일 로그 (/var/log/...)
• Docker / Kubernetes 컨테이너 로그
• OpenTelemetry (traces, metrics, logs)
• Prometheus metrics
• Kafka 메시지

출력 (보낼 수 있는 것)

• Kafka
• Loki (로그)
• Tempo (트레이스)
• Prometheus / Mimir (메트릭)
• ClickHouse (OTel exporter 경유)
• OpenTelemetry 호환 백엔드 전반

Kafka + ClickHouse 조합에서의 구조

Alloy 없이

앱 서버 ──(직접 produce)──→ Kafka ──→ ClickHouse

• 앱 코드에 Kafka producer 로직 직접 구현 필요
• 포맷 변경 시 앱 코드 수정 필요

Alloy 추가 후

앱 서버
    → Alloy (에이전트, 각 서버에 설치)
        → Kafka
            → Alloy (게이트웨이, 중앙 서버)
                → ClickHouse

앱은 로그만 쓰고, 수집/변환/적재는 Alloy가 담당.

장단점

장점

단점

언제 쓸지 판단 기준

앱 코드를 건드리기 싫다          → Alloy 유용
여러 소스를 통합 수집해야 한다    → Alloy 유용
Kafka 전송 전에 변환이 필요하다   → Alloy 유용

앱이 1~2개이고 포맷이 단순하다    → 앱에서 직접 Kafka producer 써도 충분

Hook 이벤트 종류

설정 위치

~/.claude/settings.json          # 전역 (모든 프로젝트)
.claude/settings.json            # 프로젝트 공유
.claude/settings.local.json      # 프로젝트 로컬 (gitignored)

기본 구조

{
  "hooks": {
    "EventName": [
      {
        "matcher": "regex_pattern",
        "hooks": [
          {
            "type": "command",
            "command": "/path/to/script.sh",
            "timeout": 30
          }
        ]
      }
    ]
  }
}

Hook 타입

Exit Code 동작

Hook Input/Output

Input (stdin으로 전달되는 JSON)

{
  "session_id": "abc123",
  "cwd": "/Users/me/myproject",
  "hook_event_name": "PreToolUse",
  "tool_name": "Bash",
  "tool_input": {
    "command": "npm test"
  },
  "tool_use_id": "toolu_..."
}

Output (exit 0 + stdout JSON)

{
  "continue": true,
  "suppressOutput": false,
  "systemMessage": "optional message to Claude",
  "hookSpecificOutput": {
    "hookEventName": "PreToolUse",
    "permissionDecision": "allow|deny|ask",
    "permissionDecisionReason": "reason"
  }
}

Matcher 패턴

실용 예시

1. 민감 파일 보호

#!/bin/bash
# .claude/hooks/protect-files.sh

FILE=$(cat | jq -r '.tool_input.file_path // empty')

for pattern in ".env" "package-lock.json" ".git/"; do
  if [[ "$FILE" == *"$pattern"* ]]; then
    echo "Blocked: $FILE matches protected pattern '$pattern'" >&2
    exit 2
  fi
done

exit 0

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "\"$CLAUDE_PROJECT_DIR\"/.claude/hooks/protect-files.sh"
          }
        ]
      }
    ]
  }
}

2. 파일 편집 후 자동 포맷팅

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "Edit|Write",
        "hooks": [
          {
            "type": "command",
            "command": "jq -r '.tool_input.file_path' | xargs npx prettier --write"
          }
        ]
      }
    ]
  }
}

3. 권한 자동 승인

{
  "hooks": {
    "PermissionRequest": [
      {
        "matcher": "ExitPlanMode",
        "hooks": [
          {
            "type": "command",
            "command": "echo '{\"hookSpecificOutput\": {\"hookEventName\": \"PermissionRequest\", \"decision\": {\"behavior\": \"allow\"}}}'"
          }
        ]
      }
    ]
  }
}

4. 작업 완료 시 macOS 알림

{
  "hooks": {
    "Notification": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "osascript -e 'display notification \"Claude needs attention\" with title \"Claude Code\"'"
          }
        ]
      }
    ]
  }
}

5. Linux 알림

{
  "hooks": {
    "Notification": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "notify-send 'Claude Code' 'Claude needs your attention'"
          }
        ]
      }
    ]
  }
}

6. MCP 도구 호출 로깅

{
  "hooks": {
    "PostToolUse": [
      {
        "matcher": "mcp__github__.*",
        "hooks": [
          {
            "type": "command",
            "command": "echo \"GitHub tool called: $(jq -r '.tool_name')\" >> ~/.claude/tool-log.txt"
          }
        ]
      }
    ]
  }
}

HTTP Hook

{
  "type": "http",
  "url": "http://localhost:8080/hooks",
  "headers": {
    "Authorization": "Bearer $MY_TOKEN"
  },
  "allowedEnvVars": ["MY_TOKEN"],
  "timeout": 30
}

유용한 환경 변수

주의사항

• 무한 루프 방지: Stop hook에서 stop_hook_active 값 확인 필요

  if [ "$(echo "$INPUT" | jq -r '.stop_hook_active')" = "true" ]; then
    exit 0
  fi

• jq 설치 필요: JSON 파싱에 필수 (brew install jq / apt-get install jq)
• 실행 권한 설정: chmod +x .claude/hooks/my-hook.sh
• Shell 프로필 주의: ~/.zshrc의 unconditional echo는 hook 오작동 유발 가능

관리 명령어

/hooks                  # 설정된 모든 hook 확인 (읽기 전용)

모든 hook 비활성화:

{
  "disableAllHooks": true
}

1. fix_plan.md를 모호하게 적으면 모호하게 만든다

상황: fix_plan.md에 "Django API 연동"이라고만 적었다.

결과: Ralph가 localhost로 하드코딩해버렸다. WSL 환경에서 브라우저로 접근하면 동작하지 않는 코드였지만 지시에 환경 조건이 없었기 때문에 Ralph는 문제로 인식하지 못했다.

교훈: 환경 조건, 접속 방식까지 구체적으로 적어야 한다.

2. 테스트 통과 ≠ 실제 동작

상황: Jest 테스트 11개가 전부 통과했다.

결과: 테스트는 서버 내부에서 supertest로 직접 호출하는 방식이라 localhost가 당연히 동작했다. 실제 브라우저에서 외부 접근하는 케이스는 테스트하지 않았고 Ralph도 그걸 만들라는 지시가 없었으니 만들지 않았다.

교훈: 통합 테스트, E2E 테스트가 필요하면 fix_plan.md에 명시해야 한다.

3. 환경 차이를 알려줘야 한다

상황: WSL 환경에서 Django를 127.0.0.1:8000으로 실행했다.

결과: Windows 브라우저에서 접근이 불가능했다. 0.0.0.0:8000으로 바인딩해야 한다는 걸 Ralph는 몰랐고 CLAUDE.md나 fix_plan.md에도 적혀있지 않았다.

교훈: 실행 환경(OS, 네트워크 구성 등)을 CLAUDE.md에 명시해야 한다.

4. P3를 구체적으로 적지 않으면 껍데기만 나온다

상황: fix_plan.md P3에 "HTML 기본 구조", "API 연동" 수준으로만 적었다.

결과: 화면은 만들어졌지만 실제 동작하는 기능이 없는 껍데기였다.

교훈: "회원가입 → 로그인 → JWT 저장 → Todo CRUD" 처럼 흐름을 구체적으로 적어줬을 때 비로소 제대로 구현됐다.

1. 지시한 것만 한다

fix_plan.md에 적힌 것만 구현한다. 모호하게 적으면 모호하게 만들고, 누락한 건 신경 쓰지 않는다. 결국 품질은 fix_plan.md를 얼마나 잘 쓰느냐에 달려있다.

2. 테스트 범위를 스스로 설계하지 못한다

단위 테스트는 잘 작성하지만, 통합 테스트/E2E 테스트는 명시하지 않으면 안 만든다. 테스트가 통과해도 실제 환경에서 동작하지 않을 수 있다.

3. 환경 차이를 모른다

코드가 실행되는 환경(OS, 네트워크, 인프라)에 대한 맥락이 없다. 개발환경과 운영환경의 차이, 팀마다 다른 인프라 구성은 사람이 알려줘야 한다.

4. 도메인 지식이 없다

비즈니스 규칙, 팀 컨벤션, 히스토리는 CLAUDE.md나 fix_plan.md에 적어줘야 한다. 적지 않으면 일반적인 방식으로 구현한다.

5. 막히면 건너뛴다

연속 3회 같은 에러가 발생하면 해당 항목을 포기하고 넘어간다. 근본 원인을 해결하지 못하는 문제는 사람이 직접 봐야 한다.

6. 코드 리뷰를 스스로 못 한다

테스트와 린트를 통과하면 완료로 판단한다. 보안 취약점, 성능 문제, 유지보수성 같은 건 사람이 리뷰해야 한다.

한마디로

Ralph는 실행력은 뛰어나지만 판단력은 없다.

무엇을 만들지, 어떻게 검증할지, 어떤 환경에서 동작해야 하는지는 사람이 설계해줘야 한다. Ralph는 그 설계를 빠르게 구현하는 도구다.

프로젝트 구조

ralph-test/
├── CLAUDE.md                  # Claude가 자동으로 읽는 프로젝트 설명서
├── PROJECT_STRUCTURE.md       # 구조 설명 문서
├── RALPH_GUIDE.md             # 이 파일 — Ralph 사용 가이드
├── .gitignore
│
├── .claude/
│   └── settings.json          # Claude 권한 + Stop Hook 설정
│
├── .ralph/
│   ├── fix_plan.md            # Ralph 할 일 목록
│   └── PROMPT.md              # Ralph 지시문
│
├── scripts/
│   ├── ralph-loop.sh          # Ralph 실행 스크립트
│   └── ralph-stop-hook.sh     # 완료 조건 검증 Hook
│
├── django-api/
│   ├── .venv/                 # Python 가상환경
│   └── requirements.txt       # Python 패키지 목록
│
└── node-api/
    ├── node_modules/          # Node 패키지
    ├── package.json
    └── eslint.config.js

Ralph를 쓰기 위해 필요한 것

1. CLAUDE.md

"이 프로젝트가 뭔지" Claude에게 알려주는 파일. Claude는 세션 시작 시 이 파일을 자동으로 읽고 프로젝트 컨텍스트를 파악한다.

2. .ralph/fix_plan.md

"뭘 만들어야 하는지" 할 일 목록. Ralph가 이 파일을 보고 순서대로 구현한다.

## P1: 긴급 (반드시 완료)
- [ ] 미완료 항목  ← Claude가 구현
- [x] 완료 항목   ← 구현 + 테스트 통과 후 Claude가 직접 체크

## P2: 중요
- [ ] ...

## P3: 개선
- [ ] ...

3. .ralph/PROMPT.md

"어떻게 일해야 하는지" Claude에게 주는 지시문. 역할, 작업 순서, 완료 조건, 절대 금지 사항을 정의한다.

4. .claude/settings.json

Claude가 실행할 수 있는 명령어(allow)와 없는 명령어(deny), 그리고 Stop Hook 연결을 정의한다.

{
  "permissions": {
    "allow": ["pytest 실행", "git commit", ...],
    "deny": ["rm -rf", "git push force", ...]
  },
  "hooks": {
    "Stop": [{ "command": "bash scripts/ralph-stop-hook.sh" }]
  }
}

5. scripts/ralph-stop-hook.sh

Claude가 멈추려 할 때마다 자동 실행되는 검증 스크립트. 모든 조건을 통과해야만 Claude가 종료할 수 있다.

미완료 항목 있음?     → block (계속 작업하라)
Django 테스트 실패?  → block (고쳐라)
Django 린트 에러?    → block (고쳐라)
Node 테스트 실패?    → block (고쳐라)
Node 린트 에러?      → block (고쳐라)
전부 통과?           → allow  (종료 허용)
max-iterations 초과? → allow  (강제 종료)

6. 환경 세팅

Claude가 실제로 테스트/린트를 실행할 수 있는 환경.

Ralph 실행 방법

# 기본 실행 (최대 30회)
bash scripts/ralph-loop.sh

# 반복 횟수 지정
bash scripts/ralph-loop.sh --max-iterations 10

# 오버나이트 (백그라운드)
nohup bash scripts/ralph-loop.sh --max-iterations 50 > logs/ralph-session.log 2>&1 &

전체 실행 흐름

사람이 fix_plan.md 작성
        ↓
bash scripts/ralph-loop.sh 실행
        ↓
새 브랜치 생성 (ralph/run-YYYYMMDD-HHMM)
        ↓
PROMPT.md → Claude에게 전달
        ↓
┌─── Claude 루프 시작 ──────────────────────┐
│  fix_plan.md 읽기 → 미완료 항목 선택       │
│  테스트 먼저 작성 (TDD — Red)              │
│  구현 (Green)                             │
│  테스트 + 린트 실행                        │
│  통과 → fix_plan.md [x] 표시 + git commit │
│  완료 시도                                 │
│         ↓                                 │
│  ralph-stop-hook.sh 실행                  │
│  ├─ 미통과 → block → 루프 계속 ───────────┘
│  └─ 통과   → allow → 종료
└───────────────────────────────────────────

max-iterations란?

Ralph가 최대 몇 번 반복할지 제한하는 숫자. Claude가 작업 완료를 시도할 때마다 1회로 카운트된다.

결과 확인 방법

# 어디까지 커밋됐는지
git log --oneline

# 항목별 완료 상태 확인
cat .ralph/fix_plan.md

# [x] 완료
# [!] 3회 연속 실패로 건너뜀 → 사람이 직접 확인 필요
# [ ] 미완료 → fix_plan.md 그대로 두고 다시 Ralph 실행

S3 호환 오브젝트 스토리지다. AWS S3와 API가 동일해서 boto3 같은 S3 라이브러리를 그대로 쓸 수 있다. 로컬 또는 온프레미스 환경에서 S3처럼 파일을 저장하고 싶을 때 사용한다.

이 프로젝트에서는 Parquet 파일을 저장하는 스토리지로 사용한다.

Apache Parquet

데이터를 저장하는 파일 형식이다. 컬럼 기반으로 저장하기 때문에 특정 컬럼만 읽는 분석 쿼리에 유리하다. JSON이나 CSV보다 압축률이 높고 읽기 성능이 좋다.

Apache Iceberg

테이블 포맷 스펙이다. 실행되는 서비스가 아니다.

MinIO에 Parquet 파일이 쌓이면 그냥 파일 더미다. 어떤 파일이 어떤 테이블인지, 컬럼이 뭔지, 언제 추가됐는지 알 방법이 없다.

Iceberg는 Parquet 파일들을 테이블처럼 관리할 수 있게 해주는 규칙이다.

Iceberg가 관리하는 파일 구조

system_metrics/
├── data/
│   ├── 00000.parquet
│   └── 00001.parquet
└── metadata/
    ├── snap-001.avro        → 스냅샷 정보
    └── v1.metadata.json     → 테이블 메타데이터

스냅샷 정보

특정 시점에 어떤 Parquet 파일이 테이블에 속했는지 기록한다. 이게 있어서 특정 시점의 데이터를 조회하는 Time Travel이 가능하다.

테이블 메타데이터

컬럼 이름/타입, 파티션 방식, 스키마 변경 이력, 현재 스냅샷 정보를 담고 있다.

Iceberg를 쓰는 이유

Hive Metastore

Iceberg 테이블의 메타데이터 위치를 저장하는 서비스다.

Trino가 쿼리를 실행할 때 다음 순서로 동작한다.

1. Hive Metastore에 "system_metrics 테이블 메타데이터 파일이 어디있어?" 질문
2. Hive Metastore가 MinIO 경로 반환
3. Trino가 그 경로의 메타데이터 파일을 읽어서 어떤 Parquet 파일을 읽어야 하는지 파악
4. MinIO에서 실제 Parquet 파일을 읽어서 쿼리 실행

Hive Metastore 자체의 메타데이터는 DB에 저장된다. 토이 프로젝트에서는 Derby(내장 DB), 프로덕션에서는 PostgreSQL 또는 MySQL을 사용한다.

Trino

분산 SQL 쿼리 엔진이다. Iceberg 포맷을 이해하고 MinIO의 Parquet 파일을 SQL로 조회할 수 있다.

SELECT * FROM iceberg.windows_logs.system_metrics
WHERE timestamp > '2026-03-10'
LIMIT 100;

Trino 자체는 데이터를 저장하지 않는다. MinIO에 있는 파일을 읽어서 쿼리만 실행한다.

전체 흐름 요약

데이터 적재 시

Consumer가 PyIceberg로 Parquet 파일을 MinIO에 저장하고, Iceberg 메타데이터를 업데이트한 뒤 Hive Metastore에 위치를 등록한다.

쿼리 실행 시

Trino가 Hive Metastore에서 메타데이터 위치를 확인하고, MinIO에서 메타데이터와 Parquet 파일을 읽어서 쿼리 결과를 반환한다.

쇼핑몰 데이터 예시

DB (일반 데이터베이스)

쇼핑몰 서비스가 실시간으로 읽고 쓰는 운영 데이터.

users 테이블

orders 테이블

products 테이블

목적: 주문 처리, 재고 확인, 회원 인증 등 서비스 운영에 필요한 CRUD 작업.

데이터 웨어하우스

DB에서 추출한 데이터를 분석 목적에 맞게 변환·적재한 구조. 스타 스키마(Star Schema)를 주로 사용함.

fact_orders 테이블 (사실 테이블)

dim_date 테이블 (날짜 차원 테이블)

분석 쿼리 예시

-- 월별 매출 합계
SELECT
    d.year,
    d.month,
    SUM(f.revenue) AS monthly_revenue
FROM fact_orders f
JOIN dim_date d ON f.date_id = d.date_id
GROUP BY d.year, d.month
ORDER BY d.year, d.month;

-- 상품별 판매량 순위
SELECT
    p.name AS product_name,
    SUM(f.quantity) AS total_quantity
FROM fact_orders f
JOIN dim_product p ON f.product_id = p.product_id
GROUP BY p.name
ORDER BY total_quantity DESC;

목적: 월별 매출 집계, 상품 판매 순위, 유저 구매 패턴 분석 등 BI/리포팅 작업.

데이터 레이크

원시 데이터(로그, 이미지, JSON 등)를 그대로 저장. MinIO 또는 S3 기반.

디렉토리 구조 예시

s3://shopping-datalake/
├── raw/
│   ├── logs/
│   │   ├── 2025/03/01/access.log.gz      # 웹 서버 접근 로그
│   │   └── 2025/03/05/access.log.gz
│   ├── events/
│   │   ├── 2025/03/01/click_events.json  # 클릭 스트림 이벤트
│   │   └── 2025/03/05/click_events.json
│   └── db_snapshot/
│       └── 2025/03/01/orders.parquet     # DB 스냅샷
├── processed/
│   ├── user_behavior/
│   │   └── 2025/03/session_features.parquet
│   └── product_recommendation/
│       └── model_input_2025_03.csv
└── ml_models/
    └── recommendation/
        └── v1.2/model.pkl

활용 예시

목적: 머신러닝 학습, 대규모 로그 분석, 장기 데이터 아카이빙.

전체 데이터 흐름

[쇼핑몰 서비스]
      |
      | 실시간 읽기/쓰기
      v
  [DB (MySQL/PostgreSQL)]
      |
      |-- ETL/CDC --> [데이터 웨어하우스 (Redshift/BigQuery)]
      |                        |
      |                        v
      |                   BI 대시보드 / SQL 분석
      |
      |-- 로그/이벤트 --> [데이터 레이크 (S3/MinIO)]
                                  |
                                  v
                         ML 학습 / 대용량 배치 분석

이 글에서는 ListCreateAPIView가 요청을 받았을 때 내부에서 어떤 경로로 실행되는지 소스 코드를 따라가며 정리한다.

예시 코드

class ScrapeTaskListCreateView(generics.ListCreateAPIView):
    queryset = ScrapeTask.objects.all().order_by('-created_at')
    serializer_class = ScrapeTaskSerializer

이게 전부다. 근데 GET 요청을 보내면 목록이 나오고, POST를 보내면 생성이 된다. 어떻게?

상속 구조

View (Django 기본)
  └── APIView
        └── GenericAPIView
              └── ListModelMixin + CreateModelMixin
                    └── ListCreateAPIView

DRF의 generic view는 여러 클래스를 조합해서 만들어진다.

# rest_framework/generics.py
class ListCreateAPIView(mixins.ListModelMixin,
                        mixins.CreateModelMixin,
                        GenericAPIView):
    def get(self, request, *args, **kwargs):
        return self.list(request, *args, **kwargs)

    def post(self, request, *args, **kwargs):
        return self.create(request, *args, **kwargs)

get()은 self.list()로, post()는 self.create()로 위임한다. list()와 create()는 각각 ListModelMixin, CreateModelMixin에 정의되어 있다.

요청 흐름 추적

1. urls.py에서 .as_view() 호출

path("tasks/", ScrapeTaskListCreateView.as_view())

as_view()는 View(Django 기본)에 정의된 클래스 메서드다. 호출하면 클래스를 함수처럼 쓸 수 있는 view 함수를 반환한다. Django 라우터는 함수만 받기 때문에 이 변환이 필요하다.

2. 요청이 들어오면 dispatch() 실행

HTTP 요청이 들어오면 APIView.dispatch()가 호출된다.

# rest_framework/views.py
def dispatch(self, request, *args, **kwargs):
    request = self.initialize_request(request, *args, **kwargs)
    self.initial(request, *args, **kwargs)  # 인증, 권한, 쓰로틀 체크

    if request.method.lower() in self.http_method_names:
        handler = getattr(self, request.method.lower(), self.http_method_not_allowed)

    response = handler(request, *args, **kwargs)
    return self.finalize_response(request, response, *args, **kwargs)

request.method.lower()로 HTTP 메서드를 소문자로 변환한 뒤, 같은 이름의 메서드를 자기 자신에서 찾는다. GET이면 self.get, POST면 self.post.

3. get() → list() 실행

# rest_framework/mixins.py
class ListModelMixin:
    def list(self, request, *args, **kwargs):
        queryset = self.filter_queryset(self.get_queryset())
        serializer = self.get_serializer(queryset, many=True)
        return Response(serializer.data)

get_queryset()은 클래스에 선언한 queryset을 반환한다. get_serializer()는 serializer_class로 시리얼라이저 인스턴스를 만든다. serializer.data는 Python 딕셔너리로 변환된 데이터고, Response가 이걸 JSON으로 렌더링한다.

4. post() → create() 실행

# rest_framework/mixins.py
class CreateModelMixin:
    def create(self, request, *args, **kwargs):
        serializer = self.get_serializer(data=request.data)
        serializer.is_valid(raise_exception=True)
        self.perform_create(serializer)
        return Response(serializer.data, status=status.HTTP_201_CREATED)

    def perform_create(self, serializer):
        serializer.save()

request.data로 요청 바디를 받아서 유효성 검사 후 저장한다. perform_create()를 별도로 분리한 이유는 오버라이드하기 쉽게 하기 위해서다. 예를 들어 저장 후 Celery 태스크를 발행하고 싶다면:

def perform_create(self, serializer):
    task = serializer.save()
    scrape_url.delay(task.id)

get_serializer_class()는 언제 쓰나

serializer_class를 하나만 선언하면 GET/POST 모두 같은 시리얼라이저를 사용한다. GET 응답에는 전체 필드를 주고, POST 요청에는 일부 필드만 받고 싶다면 get_serializer_class()를 오버라이드한다.

class ScrapeTaskListCreateView(generics.ListCreateAPIView):
    queryset = ScrapeTask.objects.all()

    def get_serializer_class(self):
        if self.request.method == "POST":
            return ScrapeTaskCreateSerializer
        return ScrapeTaskSerializer

get_serializer()가 내부에서 get_serializer_class()를 호출하기 때문에, 메서드에 따라 다른 시리얼라이저가 선택된다.

함수형 뷰와 비교

같은 기능을 함수형 뷰로 작성하면 흐름이 훨씬 명확하다.

@api_view(["GET", "POST"])
def task_list(request):
    if request.method == "GET":
        tasks = ScrapeTask.objects.all().order_by("-created_at")
        serializer = ScrapeTaskSerializer(tasks, many=True)
        return Response(serializer.data)

    elif request.method == "POST":
        serializer = ScrapeTaskCreateSerializer(data=request.data)
        if serializer.is_valid():
            task = serializer.save()
            scrape_url.delay(task.id)
            return Response(ScrapeTaskSerializer(task).data, status=status.HTTP_201_CREATED)
        return Response(serializer.errors, status=status.HTTP_400_BAD_REQUEST)

Generic View는 이 코드를 추상화한 것이다. 코드량은 줄지만 내부 동작을 모르면 커스터마이즈할 때 막힌다.

정리

Generic View를 쓸 때 뭔가 안 되면 dispatch → get/post → list/create 순으로 소스 코드를 따라가면 대부분 원인을 찾을 수 있다.

Claude에서 MCP 서버를 구축하고 PostgreSQL 데이터베이스를 연동하는 실전 가이드

MCP란 무엇인가

MCP(Model Context Protocol) 는 Anthropic에서 개발한 표준 프로토콜로, Claude와 외부 데이터 소스를 연결하는 인터페이스임.

핵심 개념

MCP는 Claude가 외부 시스템과 통신할 수 있도록 하는 브릿지 역할을 함. 데이터베이스, API, 파일 시스템 등 다양한 데이터 소스에 접근 가능함.

┌─────────────┐         ┌─────────────┐         ┌──────────────┐
│             │         │             │         │              │
│   Claude    │ ◄─────► │ MCP Server  │ ◄─────► │  PostgreSQL  │
│             │         │             │         │              │
└─────────────┘         └─────────────┘         └──────────────┘
    자연어 질의          프로토콜 변환            SQL 실행

MCP의 장점

환경 구축하기

필수 요구사항

MCP 서버 구축을 위해 다음 도구가 필요함:

• Node.js: MCP 서버 실행 환경
• Claude Code CLI: Claude 명령줄 도구
• PostgreSQL: 연동할 데이터베이스 인스턴스

Node.js 설치 확인

node --version
npm --version

PostgreSQL 설치 확인

psql --version

MCP 서버 설정

1. 설정 파일 위치

Claude의 MCP 설정 파일은 다음 위치에 있음:

~/.claude/config.json

2. PostgreSQL MCP 서버 추가

설정 파일을 열고 다음 내용을 추가함:

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-postgres",
        "postgresql://localhost/mydb"
      ]
    }
  }
}

설정 항목 설명:

• "postgres": MCP 서버의 이름 (임의로 지정 가능)
• "command": 실행할 명령어 (npx는 npm 패키지를 즉시 실행)
• "args": 명령어 인자
  • -y: 자동으로 yes 응답
  • @modelcontextprotocol/server-postgres: PostgreSQL MCP 서버 패키지
  • postgresql://localhost/mydb: PostgreSQL 연결 URL

3. 연결 문자열 설정

PostgreSQL 연결 문자열 형식:

postgresql://[username[:password]@][host][:port][/database]

로컬 개발 환경:

"args": [
  "-y",
  "@modelcontextprotocol/server-postgres",
  "postgresql://localhost/mydb"
]

사용자 인증:

"args": [
  "-y",
  "@modelcontextprotocol/server-postgres",
  "postgresql://user:password@localhost/mydb"
]

원격 서버:

"args": [
  "-y",
  "@modelcontextprotocol/server-postgres",
  "postgresql://user:password@remote-host:5432/mydb"
]

SSL 연결:

"args": [
  "-y",
  "@modelcontextprotocol/server-postgres",
  "postgresql://user:password@remote-host:5432/mydb?sslmode=require"
]

4. 여러 MCP 서버 설정

여러 데이터베이스를 동시에 연결할 수 있음:

{
  "mcpServers": {
    "postgres-prod": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-postgres",
        "postgresql://user:pass@prod-server:5432/production"
      ]
    },
    "postgres-dev": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-postgres",
        "postgresql://localhost/development"
      ]
    },
    "postgres-test": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-postgres",
        "postgresql://localhost/test"
      ]
    }
  }
}

MCP 서버 시작 및 확인

1. Claude 재시작

설정 파일을 수정한 후 Claude를 재시작해야 함:

# Claude 프로세스 종료 후 다시 시작
claude

2. MCP 서버 연결 확인

Claude를 시작하면 MCP 서버가 자동으로 실행됨. 연결 상태 확인:

사용 가능한 도구 확인:

Available MCP Tools:
- mcp__postgres__query: Execute read-only SQL queries

3. 연결 테스트

간단한 쿼리로 연결을 테스트함:

자연어로 질의:

"테이블 목록 보여줘"

또는 직접 SQL 요청:

"SELECT * FROM pg_tables WHERE schemaname = 'public' 실행해줘"

정상적으로 테이블 목록이 출력되면 연결 성공임.

실전 사용 예제

기본 데이터베이스 조회

MCP 서버가 연결되면 자연어로 데이터베이스 조회 가능:

예제 1: 테이블 목록

사용자: "데이터베이스에 어떤 테이블이 있어?"
Claude: [자동으로 적절한 쿼리 실행 후 결과 제공]

예제 2: 테이블 구조 확인

사용자: "users 테이블 구조 알려줘"
Claude: [테이블 스키마 정보 제공]

예제 3: 데이터 조회

사용자: "users 테이블에서 최근 가입한 사용자 10명 보여줘"
Claude: [데이터 조회 및 분석 결과 제공]

자동 쿼리 생성

Claude가 자연어를 SQL로 자동 변환:

사용자: "이번 달 주문 건수가 몇 개야?"
Claude: → SELECT COUNT(*) FROM orders
          WHERE created_at >= DATE_TRUNC('month', CURRENT_DATE)

사용자: "가장 많이 팔린 상품 5개 알려줘"
Claude: → SELECT product_name, COUNT(*) as sales
          FROM orders
          GROUP BY product_name
          ORDER BY sales DESC
          LIMIT 5

고급 설정

환경 변수 활용

민감한 정보는 환경 변수로 관리하는 것이 좋음:

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-postgres",
        "${DATABASE_URL}"
      ],
      "env": {
        "DATABASE_URL": "postgresql://user:password@localhost/mydb"
      }
    }
  }
}

또는 시스템 환경 변수 사용:

# .bashrc 또는 .zshrc
export DATABASE_URL="postgresql://user:password@localhost/mydb"

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-postgres",
        "${DATABASE_URL}"
      ]
    }
  }
}

타임아웃 설정

장시간 실행되는 쿼리를 위해 타임아웃을 설정할 수 있음:

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-postgres",
        "postgresql://localhost/mydb"
      ],
      "timeout": 30000
    }
  }
}

연결 풀 설정

PostgreSQL 연결 풀링 옵션:

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-postgres",
        "postgresql://localhost/mydb?max_pool_size=10&min_pool_size=2"
      ]
    }
  }
}

트러블슈팅

MCP 서버가 시작되지 않는 경우

증상: Claude 시작 시 MCP 서버 연결 실패

해결 방법:

1. Node.js 설치 확인

   node --version
   npm --version

2. 설정 파일 확인

   cat ~/.claude/config.json

3. JSON 문법 오류 확인

• 콤마 누락 확인
• 괄호 짝 맞는지 확인
• 따옴표 올바른지 확인

4. PostgreSQL 연결 확인

   psql -h localhost -U user -d mydb

인증 오류

증상: password authentication failed 에러

해결 방법:

1. 사용자 계정 확인

   SELECT usename FROM pg_user;

2. 비밀번호 확인

   psql -h localhost -U user -d mydb

3. pg_hba.conf 설정 확인

   # PostgreSQL 설정 파일 위치 확인
   psql -c "SHOW hba_file"

연결 거부 오류

증상: Connection refused 에러

해결 방법:

1. PostgreSQL 실행 확인

   pg_isready
   # 또는
   sudo systemctl status postgresql

2. 포트 확인

   netstat -an | grep 5432

3. 방화벽 설정 확인

   sudo ufw status

쿼리 권한 오류

증상: permission denied 에러

해결 방법:

MCP 서버는 읽기 전용이므로 SELECT 권한만 필요:

GRANT SELECT ON ALL TABLES IN SCHEMA public TO user;

보안 고려사항

읽기 전용 접근

MCP 서버는 기본적으로 읽기 전용 쿼리만 지원:

전용 사용자 생성

MCP 전용 읽기 전용 사용자 생성 권장:

-- 읽기 전용 사용자 생성
CREATE USER mcp_readonly WITH PASSWORD 'secure_password';

-- SELECT 권한 부여
GRANT CONNECT ON DATABASE mydb TO mcp_readonly;
GRANT USAGE ON SCHEMA public TO mcp_readonly;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO mcp_readonly;

-- 향후 생성될 테이블에도 자동 권한 부여
ALTER DEFAULT PRIVILEGES IN SCHEMA public
GRANT SELECT ON TABLES TO mcp_readonly;

연결 정보 보호

민감한 연결 정보는 환경 변수나 별도 파일로 관리:

# .env 파일 생성
DATABASE_URL=postgresql://mcp_readonly:password@localhost/mydb

# 권한 설정
chmod 600 .env

SSL/TLS 암호화

프로덕션 환경에서는 SSL 연결 필수:

{
  "mcpServers": {
    "postgres": {
      "command": "npx",
      "args": [
        "-y",
        "@modelcontextprotocol/server-postgres",
        "postgresql://user:pass@host:5432/db?sslmode=require"
      ]
    }
  }
}

SSL 모드 옵션:

• disable: SSL 사용 안 함
• require: SSL 필수
• verify-ca: CA 인증서 검증
• verify-full: 호스트명까지 검증

실전 활용 사례

1. 데이터 탐색

자연어로 데이터베이스 구조와 내용 탐색:

"어떤 테이블이 있어?"
"users 테이블 구조 알려줘"
"users 테이블 레코드 몇 개야?"
"최근 생성된 데이터 10개 보여줘"

2. 비즈니스 분석

비즈니스 질문을 바로 데이터로 확인:

"이번 달 신규 가입자 수는?"
"어제 매출은 얼마야?"
"가장 인기 있는 카테고리는?"
"지역별 주문 분포 보여줘"

3. 데이터 검증

데이터 품질 확인:

"NULL 값이 있는 레코드 있어?"
"중복된 이메일 있어?"
"유효하지 않은 날짜 데이터 있어?"

4. 트러블슈팅

문제 발생 시 빠른 확인:

"최근 1시간 에러 로그 보여줘"
"실패한 트랜잭션 조회해줘"
"응답 시간이 긴 API 요청 찾아줘"

MCP vs 기존 방식 비교

기존 방식

# 터미널에서 psql 접속
psql -h localhost -U user -d mydb

# SQL 작성
mydb=# SELECT COUNT(*) FROM users WHERE created_at > NOW() - INTERVAL '7 days';

# 결과 확인
 count
-------
   143

MCP 방식

사용자: "지난 7일간 가입한 사용자 수 알려줘"
Claude: 지난 7일간 143명의 사용자가 가입했습니다.

장점:

• SQL 문법 몰라도 됨
• 자연어로 질의
• 결과 자동 해석
• 연속 질문 가능

마치며

MCP를 활용하면 Claude가 PostgreSQL 데이터베이스에 직접 접근하여 자연어로 데이터를 조회할 수 있음.

구축 요약:

1. ~/.claude/config.json 파일 생성
2. PostgreSQL MCP 서버 설정 추가
3. 연결 문자열 입력
4. Claude 재시작
5. 자연어로 데이터 조회

핵심 장점:

• 쉬운 설정: 설정 파일 하나로 연동 완료
• 자연어 지원: SQL 없이 데이터 조회
• 안전한 접근: 읽기 전용으로 데이터 보호
• 빠른 분석: 대화형으로 즉시 데이터 확인

MCP 서버 구축은 간단하지만, 데이터 분석 워크플로우를 혁신적으로 개선할 수 있음.

참고 자료

공식 문서:

• MCP 공식 문서
• Claude Code CLI
• PostgreSQL 문서

MCP 서버:

• MCP Server 저장소
• PostgreSQL MCP Server