S3·IAM과 리버스 파이프라인 — 팀 프로젝트로 마무리하기

6. S3와 IAM 역할 — 키를 서버에 심지 않는 법

6.1 먼저 만나는 함정 — ARN이냐 이름이냐

플러터 카메라로 찍은 이미지를 S3에 업로드합니다. 여기서 첫 번째 벽에 부딪힙니다.

• 버킷의 ARN: arn:aws:s3:::example-bucket-10498
• .env 에 넣어야 할 값: 마지막 조각인 버킷 "이름"만

# ⭕ 올바름
VISION_S3_BUCKET=example-bucket-10498

# ❌ 틀림 — NoSuchBucket 에러
VISION_S3_BUCKET=arn:aws:s3:::example-bucket-10498

⚠️ ARN 전체를 넣으면 NoSuchBucket 으로 실패합니다. 에러 메시지가 "그런 버킷 없음"이라 버킷이 안 만들어진 줄 알고 콘솔을 헤매게 되는 대표적 함정입니다. 버킷은 있습니다. 이름이 틀렸을 뿐입니다.

ARN(Amazon Resource Name) 은 AWS 안의 모든 자원을 유일하게 가리키는 주소 체계입니다.

arn : aws : s3 : :  : example-bucket-10498
 │     │    │   │  │        └── 리소스 (여기서는 버킷 이름)
 │     │    │   │  └── 계정 ID (S3는 전역 고유라 비어 있음)
 │     │    │   └── 리전 (S3는 전역이라 비어 있음)
 │     │    └── 서비스
 │     └── 파티션
 └── 고정 접두어

DB의 주식별자(Primary Key) 와 같은 역할입니다(4주차). 전체 시스템에서 그 하나를 유일하게 지목합니다. 정책 문서에는 ARN을, 애플리케이션 설정에는 이름을 씁니다. 쓰이는 자리가 다릅니다.

6.2 환경변수 키 목록

.env 에 들어갈 S3 관련 키입니다.

VISION_S3_BUCKET=CHANGE_ME
AWS_REGION=ap-northeast-2
AWS_DEFAULT_REGION=ap-northeast-2
AWS_ACCESS_KEY_ID=CHANGE_ME
AWS_SECRET_ACCESS_KEY=CHANGE_ME

⭐ 그런데 이 마지막 두 줄이 이 절의 주제입니다. 로컬 개발에서는 액세스 키를 씁니다. 하지만 EC2 위에서 도는 서버에는 이 두 줄을 넣지 않는 것이 정답입니다. 왜 그런지, 대신 무엇을 쓰는지가 6.3절부터입니다.

6.3 버킷 정책 ↔ IAM 역할 — 어느 쪽에 권한을 붙이나

AWS에서 "이걸 해도 되는가"를 정하는 방식은 두 가지입니다.

⭐ 같은 계정 안의 EC2에서만 쓸 거라면 버킷 정책은 아예 필요 없습니다. 버킷 정책은 외부 계정·익명 사용자에게 열어줄 때 쓰는 리소스 기반 정책입니다. 내 계정 EC2 → 내 버킷은 IAM 역할이 표준이고, 액세스 키를 서버에 심을 필요가 없어 훨씬 안전합니다.

액세스 키를 서버에 심는 것이 왜 위험한지는 이미 여러 번 겪었습니다.

• 키가 .env 에 있고, .gitignore 를 나중에 만들면 public 저장소에 그대로 올라갑니다.
• 키가 유출되면 누구든 그 권한을 씁니다. 유출 사실도 늦게 압니다.
• 키를 바꾸려면 서버마다 들어가서 갈아야 합니다.

IAM 역할은 이 문제를 구조적으로 없앱니다. 키가 아예 존재하지 않습니다. EC2 인스턴스에 역할을 붙여두면, 인스턴스 메타데이터에서 짧은 수명의 임시 자격증명이 자동으로 발급·갱신됩니다.

6.4 IAM 역할 만들기 — 4단계

1단계. IAM 역할 생성

IAM 콘솔 → 역할(Roles) → 역할 만들기
  → 신뢰할 수 있는 엔터티 유형: AWS 서비스
  → 사용 사례: EC2

2단계. 권한 정책 (인라인 정책 생성)

역할 자체가 주체이므로 Principal 항목이 없습니다.

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowImageBucketAccess",
      "Effect": "Allow",
      "Action": ["s3:PutObject", "s3:GetObject"],
      "Resource": "arn:aws:s3:::example-bucket-10498/*"
    }
  ]
}

목록 조회가 필요하면 버킷 자체를 대상으로 하는 문장을 추가합니다.

{
  "Sid": "AllowListBucket",
  "Effect": "Allow",
  "Action": ["s3:ListBucket"],
  "Resource": "arn:aws:s3:::example-bucket-10498"
}

⚠️ ⭐ 가장 실수하기 쉬운 포인트 GetObject / PutObject 는 객체가 대상이라 ARN 끝에 /* 가 붙습니다. ListBucket 은 버킷이 대상이라 /* 가 없습니다. 두 ARN이 다릅니다. 이걸 같게 쓰면 "권한을 줬는데 안 된다"가 됩니다.

이 구분은 4주차의 개체(Entity) ↔ 그 개체들이 담긴 테이블 구분과 같은 층위 문제입니다. "행에 대한 권한이냐, 테이블에 대한 권한이냐." 층을 헷갈리면 정책이 안 먹습니다.

3단계. EC2에 역할 연결

EC2 콘솔 → 인스턴스 선택 → 작업 → 보안 → IAM 역할 수정

4단계. FastAPI 코드

boto3가 인스턴스 메타데이터에서 자격증명을 자동으로 취득하므로, 코드에 키를 명시할 필요가 없습니다.

import boto3

s3 = boto3.client("s3", region_name="ap-northeast-2")
s3.upload_file("local.png", "example-bucket-10498", "images/local.png")

세 줄입니다. 액세스 키가 한 글자도 없습니다.

💡 버킷은 "퍼블릭 액세스 차단"을 켠 그대로 둡니다. 흔한 오해가 "업로드가 안 되니 퍼블릭으로 열어보자" 입니다. 퍼블릭 차단은 인터넷 누구나 접근을 막는 설정이고, IAM 역할을 통한 접근과는 다른 통로입니다. 차단을 켜둔 채로 IAM 역할은 정상 동작합니다. 열지 마세요.

6.5 업로드 경로를 아키텍처로 그리면

[플러터 앱]
   │  사진 촬영
   ▼
[게이트웨이]                  ← 인증·라우팅 (퍼사드)
   ▼
[인바운드 라우터]              ← FastAPI 라우터 (인바운드 어댑터)
   ▼
[앱 유스케이스]                ← "영수증 이미지를 보관한다" (도메인)
   ▼
[아웃바운드 포트]              ← ImageStoragePort (추상)
   ▼
[S3 어댑터]                   ← boto3 구현 (구상)
   ▼
[S3 버킷]

포트/어댑터 방식으로 구현합니다. 이렇게 짜두면 저장소를 S3에서 다른 것으로 바꿔도 유스케이스는 한 줄도 바뀌지 않습니다. 6주차에서 배운 그대로입니다.

---

7. 리버스 파이프라인 — 영수증 가계부

7.1 방향이 거꾸로인 파이프라인

지금까지 우리가 만든 흐름은 전부 정방향이었습니다. 사용자가 화면에서 입력 → 라우터 → 유스케이스 → 저장소 → DB. 바깥에서 안으로 들어갑니다.

8월 4일의 과제는 역방향입니다.

[플러터] 영수증 촬영
   → [S3] 이미지 저장
   → [웹 프론트] 가계부 화면 진입
   → S3의 이미지를 서버로 로드          ← 여기서부터 역방향
   → 서버에서 OCR로 텍스트 인식
   → 웹 화면에 표시

9주차에서 배운 스타 토폴로지 위에 그리면 이렇게 됩니다.

S3(아웃바운드) → 앱(OCR) → 인바운드 → 웹 으로 나가는 방향의 역순 흐름.

역방향이 까다로운 이유는 출발점이 사용자 요청이 아니라 저장소에 이미 있는 것이고, 데이터가 나가면서 줄어드는 게 아니라 늘어나기 때문입니다(이미지 → 텍스트 → 구조화된 항목).

⭐ 여기가 3주차 동기/비동기 축이 실무에서 꼭 필요해지는 자리입니다. OCR은 시간이 걸립니다. 화면에 들어올 때마다 동기로 돌리면 사용자가 몇 초를 기다립니다. 실무에서는 업로드 시점에 미리 OCR을 걸어 결과를 저장해두고, 화면은 결과만 읽습니다. "언제 계산할 것인가"를 옮기는 것 — 5주차에서 배운 CQRS(읽기 모델과 쓰기 모델 분리) 의 씨앗입니다.

7.2 OCR은 어느 축에 꽂히는가

OCR(Optical Character Recognition) — 이미지 속 글자를 텍스트로 바꾸는 기술입니다.

10주차의 구문론 ↔ 의미론 축으로 보면 OCR은 구문론 쪽입니다. "이 픽셀 뭉치는 7이라는 글자다"까지만 합니다. 그것이 금액인지 날짜인지는 모릅니다.

의미를 붙이는 것은 그다음 층(LLM 또는 규칙)의 일입니다.

[이미지]  --OCR(구문)-->  ["2026-08-04  아메리카노  4,500"]  --LLM(의미)-->  {date, item, amount}

이 두 층을 한 덩어리로 뭉쳐서 "AI가 영수증을 읽는다"고 부르면, 정확도가 낮을 때 어디를 고쳐야 할지 알 수 없습니다. 하네스 엔지니어링에서 배운 원칙 그대로입니다 — 실패를 모델 탓으로 묶지 말고 먼저 분류하라. 글자를 잘못 읽었으면 OCR 문제, 글자는 맞는데 항목 분류가 틀렸으면 프롬프트·스킬 문제입니다.

---

8. 하네스 엔지니어링 심화 — 문서가 코드를 낳는다

8.1 DESIGN.md — 디자인도 하네스로

프론트엔드에서 스타일이 제각각이 되는 이유는 실력이 아니라 기준이 없어서입니다. DESIGN.md 를 하네스로 삼아 이 문제를 해결합니다.

• nextjs 프로젝트에 적용하여 tailwindcss와 shadcn으로 스타일링 라이브러리를 통일
• 색·간격·타이포·컴포넌트 규칙을 문서 한 장에 고정하고, 에이전트가 그 문서를 지키게 함

파울러의 분류로는 가이드(Guide) 입니다. 행동 전에 방향을 정하는 문서입니다.

8.2 CLAUDE.md, AGENTS.md — 팀의 하네스로 바꿔도 될까

8월 9일의 읽을거리 하나가 이 질문을 정면으로 던집니다(12절 참조). 개인이 쓰던 하네스 문서를 팀 표준으로 올릴 때 생기는 문제들입니다.

⭐ 하시모토의 원칙을 다시 꺼냅니다 — "AGENTS.md의 각 줄은 실제로 있었던 나쁜 행동에서 나온 것이어야 한다." 미리 상상해서 규칙을 쌓으면 문서만 길어집니다. 사고가 나면 한 줄 추가한다. 이것이 하네스를 관리하는 유일하게 지속 가능한 방법입니다.

8.3 지킬(Jekyll) — 세션 사이를 잇는 장치

8월 20일, fin-taylor/CLAUDE.md 에 전략을 반영하면서 규칙 하나를 정합니다.

다음 세션에서도 동일한 결과가 이어지도록, 프로젝트 진행사항을 지킬에 기록한다.

지킬(Jekyll) 은 마크다운 파일을 정적 웹사이트로 만들어주는 도구입니다. GitHub Pages의 기본 엔진이기도 합니다. 여기서는 블로그가 아니라 개발 로그 겸 산출물 저장소로 씁니다. Ubuntu에서 세팅했습니다.

이 규칙이 왜 중요한가:

하네스 이론의 인수인계 5항목 — 목표 / 완료 / 실패 / 위험 / 다음 행동 — 을 기록할 자리가 바로 여기입니다.

⚠️ 파일이 늘어나면 구조부터 정합니다. 8월 24일에 지킬 md 파일이 계속 늘어나자, jekyll 을 지킬 폴더의 루트로 정하고 폴더 깊이를 2로 정리했습니다. 깊이 2 규칙은 사람에게도 에이전트에게도 좋습니다. 경로가 짧아 참조가 쉽고, 어디에 넣을지 고민이 줄어듭니다.

8.4 ⭐ RFP 하네스 4원칙

8월 21일, 공공 SW사업 RFP 가이드라인을 반영해 .claude/rfp-harness.md 를 만듭니다. 여기에 적힌 Claude Code 준수 규칙 4가지는 이 부트캠프의 하네스 논의가 도달한 가장 구체적인 형태입니다.

요구사항 예시

실행 순서

Task 1  pnpm workspace 모노레포 템플릿 생성
Task 2  services/rag/retriever.py 에 RRF 기반 HybridRetriever + 테스트
Task 3  split-view UI

사용법은 이렇게 한 줄입니다.

claude "RFP_HARNESS.md를 읽고 [Task 1]을 먼저 수행해서 프로젝트 템플릿을 만들어줘."

⭐ 이 4원칙은 새로운 것이 아닙니다. 명확성은 "모호한 요청은 계획 세션과 실행 세션을 분리하라"의 문서판, 원자성은 "세션을 작고 명확한 단위로 쪼개라"의 문서판, 추적성은 관측성(Observability)의 문서판, 검증성은 "에이전트에게 스스로 검증할 수단을 주면 스스로 고친다"의 문서판입니다.

흥미로운 것은 이 네 단어가 공공 SW사업 RFP 가이드라인에서 왔다는 점입니다. AI 시대에 새로 발명된 것이 아니라, 발주와 검수라는 오래된 문제에서 이미 정립돼 있던 것입니다. 좋은 요구사항 문서의 조건과 좋은 하네스의 조건이 같습니다. 사람에게 시키든 에이전트에게 시키든 마찬가지이기 때문입니다.

8.5 이 부트캠프의 일관된 순서

① 하네스 md 작성 (코드 금지)
② md 검토 · 경계 확정
③ md를 참조시켜 코드 생성
④ 생성 코드를 클린 코드 관점에서 직접 검수 · 재편집
⑤ 결과와 실패를 지킬(개발 로그)에 기록
⑥ 그 기록이 다음 세션의 입력이 됨

④번을 빠뜨리면 안 됩니다. 7주차에서 확인했듯, 에이전트가 만든 DIP 코드가 절반만 DIP인 경우가 흔합니다. 생성은 자동화하되 검수는 자동화하지 않습니다. 그것이 지금 시점의 현실적인 경계선입니다.

---

9. 팀 프로젝트 — SI 산출물과 스크럼

9.1 가상 클라이언트 요구사항을 채용 공고에서 뽑는다

팀 프로젝트 주제를 정할 때 기준이 "만들고 싶은 것"이 아니라 "채용 공고의 키워드" 였습니다.

⭐ 이 순서가 중요합니다. 포트폴리오를 만든 뒤 맞는 회사를 찾는 것이 아니라, 가고 싶은 자리의 요구사항을 먼저 읽고 그것을 만드는 순서입니다. 10절의 포트폴리오 리프레이밍 전략과 같은 사고방식입니다.

9.2 선정 주제

"멀티 에이전트 기반 금융 리포트 & 미디어 브리핑 자동화 플랫폼" 을 강사 데모 버전으로 구현하기로 결정했습니다.

💡 3단계 멀티에이전트가 왜 3단계인가 — 수집·검증·생성을 한 에이전트에게 맡기면 팩트체크 실패와 문장 품질 실패를 구분할 수 없습니다. 나누면 어느 단계에서 틀렸는지 알 수 있습니다. 하네스 이론의 "실패를 먼저 4분류하라(모델/하네스/컨텍스트/스킬)" 가 워크플로우 설계로 내려온 것입니다. 그리고 이것 역시 하나 ↔ 여럿 축입니다. 쪼갠 대가는 단계 간 전달 비용입니다.

9.3 SI 표준 산출물 작성 순서

① 프로젝트 개요 · 추진 단계
     기획 → 아키텍처 → 미디어 파이프라인 PoC → 인프라/CI-CD → 테스트·QA
② 서비스 아키텍처 및 데이터 흐름도
③ 기능 요구사항 정의서 (표 형식)

기능 요구사항 정의서 예시

PoC(Proof of Concept) — "이게 되긴 되는가"를 최소 규모로 먼저 확인하는 단계입니다. 미디어 파이프라인처럼 처음 해보는 것을 먼저 PoC로 세우는 순서가 스파이럴(나선형) 방법론의 핵심입니다. 가장 위험한 것을 가장 먼저 확인합니다.

9.4 공공 SI 가상 시나리오와 스크럼

지킬 개발제안서 구성

• 1페이지 — 사업명
• 2페이지 — 목차 (개발자 4명, 개발기간)
• "단계별 개발일정" 페이지 — 애자일 스크럼 칸반 차트
  • 역할 분담: PM / 플러터(앱) / 파이프라인 / 에이전트
  • "스프린트 1주차 작업"을 클릭하면 일자별 진행사항 테이블로 이동

⚠️ 여러 명이 같은 지킬을 쓰면 충돌합니다. 3인 팀에서 스크럼 백로그를 지킬에 기록할 때, 칸반을 추가해 사용자별로 스케줄러를 구분했습니다. 이것도 판별 축입니다. 하나의 문서에 뭉치면 충돌하고, 사람별로 쪼개면 관리 대상이 늘어납니다. Git 브랜치 전략과 정확히 같은 문제이고, 같은 해법입니다.

9.5 인프라 준비 — RDS와 .env 규칙

스파이럴 개발방법론에 따라, DB URL을 먼저 확보하기 위해 AWS RDS를 구성했습니다.

# .env — 실제 값은 절대 커밋하지 않습니다
RDS_HOST=<클러스터명>.cluster-<식별자>.<리전>.rds.amazonaws.com
RDS_READER_HOST=<클러스터명>.cluster-ro-<식별자>.<리전>.rds.amazonaws.com
RDS_PORT=5432
RDS_DB_NAME=CHANGE_ME
RDS_USER=CHANGE_ME
RDS_PASSWORD=CHANGE_ME        # 운영에서는 IAM 인증 / Secrets Manager 권장
AWS_REGION=ap-northeast-2
AWS_ACCESS_KEY_ID=            # EC2/ECS/Lambda 에서는 비우고 IAM 역할 사용
AWS_SECRET_ACCESS_KEY=

.env 취급 규칙 세 줄

1. .env.example 에는 키 이름만 공유하고 실제 값은 금지합니다.
2. 받는 사람은 cp .env.example .env 로 복사한 뒤 값을 채웁니다.
3. .env · .env.local 은 .gitignore 에 먼저 등록합니다.

⭐ RDS_HOST 와 RDS_READER_HOST 가 왜 따로 있는가 Aurora는 쓰기용 writer 엔드포인트와 읽기 전용 reader 엔드포인트(cluster-ro- 포함)를 따로 줍니다. 5주차의 읽기 ↔ 쓰기 분리(CQRS) 축이 클라우드 DB 제품에 그대로 구현돼 있는 것입니다. 읽기 부하가 커지면 reader만 늘립니다. 엔드포인트를 잘못 복사하면 쓰기가 실패하니 writer를 확인하세요.

9.6 예산과 진행 현황

⚠️ 크레딧은 유한합니다. 유휴 상태에서도 과금되는 것들 — Provisioned Throughput, 파인튜닝/커스텀 모델 호스팅, Knowledge Base + OpenSearch Serverless 벡터 스토어 — 은 생성 자체를 하지 않습니다. 만들어두고 안 쓰면 된다는 생각이 요금 폭탄의 시작입니다.

---

10. 커리어 — 정량화가 사람을 뽑히게 한다

10.1 이전 기수 취업생의 개인 프로젝트 해부

AI 회사에 취업한 이전 기수 수강생의 이력서 4페이지짜리 개인 프로젝트를 통째로 뜯어봅니다. "이 정도면 붙는다"의 실물 기준입니다.

프로젝트: HR Insight (Success DNA) — 2026.02 ~ 03

아키텍처 설계 — 이 교재에서 배운 이름들이 그대로 나옵니다.

주요 기능

• 멀티 포맷 문서 파싱 → 텍스트 레이어 추출 + 스캔본 OCR → LLM 의미 분석 → 5대 핵심 역량 정량화(리더십·기술력·창의성·협업·적응력)
• 외부 메일 수신 → LLaMA LoRA 스팸 분류, 성과 데이터 통합 → 초기(이력서) 대비 현재 성장 추이 도출
• SSE 스트리밍 채팅형 인사 조회 — LangGraph 기반 RAG 에이전트, 12개 시나리오 Tool Calling 검증(평균 성공률 0.95)
• 역량 온톨로지 — 직무역량 원천(O*NET · NCS 등) 11.8만 건 → BGE-M3 임베딩 → FAISS K-Means · UMAP → 파인튜닝 EXAONE 자동 라벨링

10.2 문제해결 항목이 진짜 본체다

이력서에서 면접관이 실제로 파고드는 곳은 기술 나열이 아니라 "막혔던 것을 어떻게 뚫었는가" 입니다.

⭐ 마지막 줄을 보세요. "Neon 용량이 부족해서 못 했다"로 끝나지 않았습니다. 데이터의 성격에 따라 저장소를 둘로 갈랐습니다. 정적이고 큰 것은 메모리에, 동적이고 트랜잭션이 필요한 것은 DB에. 3주차의 디스크 ↔ 메모리 축, 7주차의 정적(Dataset) ↔ 동적(Database) 축이 실무 제약 앞에서 설계 결정으로 쓰인 사례입니다. 이것이 "축을 배운다"의 실제 효용입니다.

10.3 면접 포인트 — 말이 아니라 숫자

두 가지 사례가 있습니다.

1. "이거 누가 했냐" 는 질문을 받아 따로 면접 기회를 얻은 케이스.
2. 비용 절약을 말로만 하지 않고, LangSmith로 초기 비용 · 개선 비용 · 지연시간 개선 등 추적 지표를 수치화·정량화한 경험이 별도 면접 기회로 이어진 케이스.

⭐ "비용을 줄였습니다"는 아무 정보도 아닙니다. "초기 호출당 $0.012 → 개선 후 $0.0077, 평균 지연 3.1초 → 1.8초, 측정은 LangSmith 트레이스 500건 기준" 이 한 줄이 면접을 만듭니다.

하네스 이론의 TRACE + FEEDBACK 이 여기서 회수됩니다. "Trace만으로는 학습이 안 된다. 무엇이 일어났는지(TRACE)와 결과가 좋았는지(FEEDBACK)가 연결돼야 다음 실행이 개선된다." 측정 도구를 붙여두지 않으면, 개선했다는 사실 자체를 증명할 수 없습니다.

10.4 채용 공고 하나를 끝까지 읽기

LLM & RAG 엔지니어 공고를 예로 전형과 우대사항을 분해합니다.

⚠️ 우대사항 ④를 다시 읽으세요. "RAG를 써봤다"가 아니라 "RAG가 틀리는 원인을 데이터 설계로 고쳤다" 입니다. 표가 들어간 PDF를 그냥 청킹하면 숫자와 헤더가 분리돼 완전히 틀린 답이 나옵니다. 모델을 바꾸는 게 아니라 데이터를 구조화해서 고칩니다. 이것이 하네스 이론의 "실패 원인을 모델/하네스/컨텍스트/스킬로 먼저 분류하라" 의 채용 공고 판본입니다.

검색 품질 지표 사전

3주차에서 배운 정확도 · 정밀도 · 재현율 · F1 이 분류 문제의 지표라면, 이 셋은 검색·랭킹 문제의 지표입니다. 같은 자리에 꽂히는 형제 개념입니다.

10.5 포트폴리오 리프레이밍 — 제목부터 바꾼다

SI형 제목 대신 문제 해결형 제목으로.

제목이 바뀌면 본문 구성도 바뀝니다.

⭐ 마지막 줄이 가장 중요합니다. 한계를 적으면 감점될 것 같지만 반대입니다. 한계를 아는 사람만이 다음에 무엇을 할지 압니다. 면접에서 가장 좋은 질문거리가 되기도 합니다. 하네스 이론의 인수인계 5항목(목표/완료/실패/위험/다음 행동) 을 포트폴리오에 적용하면 정확히 이 구성이 됩니다.

하이브리드 검색은 10주차 축 1의 회수입니다.

11. 실습 — 이번 달에 손으로 한 것

(S3 + IAM 역할 실습 절차는 6.4절에 순서대로 정리해 두었습니다. 그대로 따라 하세요.)

11.1 RDS(Aurora PostgreSQL) 생성과 연결 (8/21)

RDS 콘솔 → 데이터베이스 생성 → Aurora (PostgreSQL Compatible)
  → 용량: 4
  → 백업기간: 7
  → 나머지는 기본값
생성 후 → 연결 & 보안 탭 → 엔드포인트 중 [writer] 복사

cp .env.example .env      # 값이 아니라 키 이름만 공유받아 채운다
echo ".env"       >> .gitignore
echo ".env.local" >> .gitignore

11.2 지킬(Jekyll) 개발 로그 (8/20~8/24)

# Ubuntu
sudo apt update && sudo apt install -y ruby-full build-essential zlib1g-dev
gem install jekyll bundler
jekyll new jekyll        # 폴더 루트를 'jekyll' 로 고정
cd jekyll
bundle exec jekyll serve  # http://127.0.0.1:4000

정리 규칙

• 지킬 폴더 루트를 jekyll 로 고정
• 폴더 깊이는 2까지만 — 그 이상 내려가지 않음
• 개발 로그에 남길 5항목: 목표 / 완료 / 실패 / 위험 / 다음 행동

11.3 RFP 하네스 사용 (8/21)

# .claude/rfp-harness.md 를 만든 뒤
claude "RFP_HARNESS.md를 읽고 [Task 1]을 먼저 수행해서 프로젝트 템플릿을 만들어줘."

Task 1  pnpm workspace 모노레포 템플릿
Task 2  services/rag/retriever.py — RRF 기반 HybridRetriever + 테스트
Task 3  split-view UI

11.4 컨테이너 정리와 Podman 대응

# 디스크가 찼을 때 (EC2)
docker rm -f $(docker ps -aq)
docker image prune -a -f

# Podman으로 같은 일
podman rm -f $(podman ps -aq)
podman image prune -a -f

# Podman으로 Pod 만들고 쿠버네티스 YAML 뽑기
podman pod create --name myapp -p 8000:8000
podman run -d --pod myapp --name api my-fastapi:latest
podman generate kube myapp > myapp-pod.yaml

11.5 CI 파이프라인 붙이기

mkdir -p .github/workflows
# 4.8절의 ci.yml 을 저장하고 push
git add .github/workflows/ci.yml
git commit -m "ci: 린트와 테스트 자동화"
git push
# → GitHub 저장소의 Actions 탭에서 실행 결과 확인

⚠️ 처음 붙이면 대부분 빨간 X가 뜹니다. 정상입니다. 로컬에만 있던 의존성, 하드코딩된 경로, .env 에 의존하던 코드가 한꺼번에 드러납니다. 그것이 CI의 존재 이유입니다. "내 컴퓨터에서는 되는데"를 없애는 것.

---

12. 이 달의 읽을거리와 그 맥락

💡 읽을거리가 이 달에 유난히 "취업"으로 기울어 있는 이유 — 8월은 부트캠프의 마지막 구간이고, 팀 프로젝트가 곧 포트폴리오이며, 포트폴리오가 곧 지원서이기 때문입니다. 만드는 일과 파는 일이 같은 작업이 되는 시점입니다.

---

13. 전 과정 되돌아보기

여기서부터가 이 책의 마지막 절입니다.

1주차 0절에서 이렇게 썼습니다.

"새 용어를 만나면 비유를 찾기 전에 아래 축 중 어디에 꽂히는지부터 정하세요. 비유부터 잡으면 경계가 흐려집니다. 축을 먼저 잡으면 아직 안 배운 것도 추론됩니다."

열다섯 장 동안 같은 문장을 반복했습니다. 이제 그 약속을 정산합니다. 축을 먼저 잡았기 때문에 아직 안 배운 것이 추론되었는가? 표로 확인합니다.

13.1 판별 축 총정리

⭐ 이 표의 오른쪽 끝 열을 세로로 읽어보세요. 여덟 축이 전부 이번 장에서 한 번 이상 다시 나왔습니다. 커널과 컨테이너 엔진과 프록시와 파이프라인은 이 교재에서 처음 배우는 주제였는데, 그것을 이해하는 데 필요한 축은 하나도 새로 만들지 않았습니다.

13.2 같은 축, 아홉 개의 배율 — 축 ⑤의 전체 지도

가장 자주 반복된 축 ⑤(하나 ↔ 여럿) 하나만 놓고, 이 교재가 다룬 모든 배율을 세로로 세워봅니다.

열세 줄이 전부 같은 한 문장입니다.

뭉치면 빠르지만 같이 죽고, 쪼개면 안전하지만 통신 비용을 낸다. 그리고 어느 쪽도 발전된 형태가 아닙니다. 규모와 실패 비용이 답을 정합니다.

13.3 프랙탈 — 3주차의 결론을 여기서 닫습니다

3주차 13.4절에서 프랙탈 이론을 소개하며 이렇게 적었습니다.

"객체지향의 근본 구조가 프랙탈이라는 이야기와 연결됩니다. 같은 구조가 크기만 바꿔 반복되기 때문에, 하나를 제대로 이해하면 아직 안 배운 것도 추론됩니다."

프랙탈(Fractal) — 같은 구조가 크기(배율)를 바꿔 반복되는 도형·구조입니다. 해안선을 1km 단위로 봐도, 1m 단위로 봐도, 1cm 단위로 봐도 비슷하게 들쭉날쭉합니다.

13.2절의 표가 정확히 그 모양입니다.

      배율 ↑
  ┌──────────────────────────────────────────────┐
  │  팀 조직        한 사람  ↔  스크럼 역할 분담      │
  │  AI 실행        단일     ↔  멀티에이전트         │
  │  네트워크        스타     ↔  메시                │
  │  애플리케이션    모놀리식  ↔  MSA                │
  │  코드 내부       퍼사드    ↔  책임 연쇄           │
  │  컨테이너 엔진   dockerd  ↔  Podman             │
  │  OS 커널        모놀리식  ↔  마이크로커널        │
  │  CPU 권한       Ring 0   ↔  Ring 0 / Ring 3    │
  └──────────────────────────────────────────────┘
      배율 ↓          (0)          (1)

맨 위(사람 조직)와 맨 아래(CPU 특권 레벨) 사이에 여덟 배율이 있는데, 판별 질문은 하나뿐입니다.

이 성질이 이 교재의 학습 전략 전체를 정당화합니다.

⭐ 이 책을 덮은 뒤 새 기술을 만났을 때 할 일

1. 이것은 무엇의 한 종류인가? (상위 범주)
2. 형제 개념과 무엇으로 갈리는가? (종차 — 여덟 축 중 어디에 꽂히는가)
3. 이건 아니다 — 반례는 무엇인가?
4. 그다음에야 비유를 찾는다. (기억 보조용으로만)

쿠버네티스도, 서비스 메시도, 아직 이름도 없는 다음 도구도 이 네 질문으로 열립니다. 축이 여덟 개뿐이기 때문입니다.

13.4 미국식 분류가 결국 무엇이었나

1주차에서 시작한 또 하나의 원칙을 정산합니다.

소프트웨어 개념은 전부 유(類)와 종차(種差) 정의법을 코드로 옮긴 것입니다. 그래서 이 교재는 늘 같은 형식을 썼습니다.

X — [상위 범주]인데, [종차]는 점에서 [형제 개념]과 구별된다.

그리고 그 종차 자리에 들어간 것이 여덟 개의 축이었습니다. 분류 우선 사고와 프랙탈 구조는 같은 것의 앞뒷면입니다. 분류가 되기 때문에 배율을 바꿔도 같은 질문이 통하고, 배율을 바꿔도 통하기 때문에 분류가 힘을 갖습니다.

13.5 번역어가 왜곡한 곳 모음

이 교재가 반복해서 바로잡은 한국어 번역 문제입니다. 마지막으로 모아둡니다.

13.6 그래서 이제 무엇을 할 수 있는가

마지막 한 문장

이 책이 가르친 것은 도구가 아닙니다. 도구는 바뀝니다. 이 책이 가르친 것은 모르는 것 앞에서 던질 질문의 순서입니다. 그 순서는 CPU 안에서도, 서버 백 대 위에서도, 사람 네 명의 팀에서도 같습니다. 그것이 프랙탈이고, 그것이 이 열다섯 장의 결론입니다.

---

부록 A. 용어 사전

---

부록 B. 스스로 확인하기

---

부록 C. 자주 하는 실수

---

부록 D. 날짜별 색인

---

부록 E. Gemini / NotebookLM 프롬프트

복습 문제 받기

이 15주차 교재만 근거로 8문제를 내줘. 비전공자 기준으로.
"커널 모드와 시스템 콜", "Continuous Delivery vs Deployment",
"포워드 vs 리버스 프록시"는 반드시 포함해줘.
답은 바로 주지 말고, 내가 답한 다음에 채점하고
틀린 이유를 교재의 어느 절을 근거로 설명해줘. 교재에 없는 내용은 꺼내지 마.

인포그래픽 ① — 커널과 두 개의 링

「1.4 동작 원리 — CPU 실행 모드」와 「1.5 시스템 콜」을 한 장으로 만들어줘.
- 동심원 두 개: 안쪽 Ring 0(커널 모드), 바깥 Ring 3(사용자 모드)
- 두 원 사이에 "시스템 콜"이라는 하나의 문만 그리기
- 각 원 안에 무엇이 도는지(응용 프로그램 / 커널·드라이버) 배치
- 아래에 open·read·write·socket·fork 를 실제 우리 코드와 짝지어 표시
- 전문용어는 한글(영문) 병기

인포그래픽 ② — 프랙탈 축 지도

「13.2 같은 축, 아홉 개의 배율」 표를 세로 인포그래픽으로 만들어줘.
- 위에서 아래로 배율이 작아지는 축(팀 → AI → 네트워크 → 앱 → 코드 → 컨테이너 → 커널 → CPU)
- 각 줄 왼쪽에 "하나로 뭉침", 오른쪽에 "여럿으로 쪼갬"
- 가운데 세로선 하나로 모든 줄을 관통시켜 "같은 축"임을 시각화
- 오른쪽 여백에 "쪼갠 대가"를 작게 표기
- 맨 아래에 한 문장: "뭉치면 빠르지만 같이 죽고, 쪼개면 안전하지만 통신 비용을 낸다"

막힐 때

15주차에서 "___" 가 이해가 안 돼.
이 교재의 판별 축 여덟 개(디스크↔메모리, 추상↔구상, 속성↔기능, 로컬↔원격,
하나↔여럿, 동기↔비동기, 무상태↔상태, 구문론↔의미론)만 써서 다시 설명해줘.
교재에 없는 새 비유는 만들지 마.

아직 안 배운 것 추론해보기

나는 이 교재로 커널·컨테이너·프록시·CI/CD까지 배웠어.
쿠버네티스를 아직 안 배웠는데, 교재의 판별 축 여덟 개만 써서
쿠버네티스가 어떤 축의 어느 쪽에 놓이는 도구일지 추론해줘.
새 용어를 설명하지 말고, 내가 이미 아는 개념(Pod, SPOF, 선언적 상태, GitOps)과
연결해서만 말해줘. 그다음 내 추론이 맞는지 채점해줘.