Context

Python 코드 작업 중 Pydantic을 접하고 정확한 개념을 정리했다.

What I Learned

Pydantic은 Python에서 **데이터 검증(Validation)과 직렬화(Serialization)**를 위한 라이브러리다. 타입 힌트를 기반으로 런타임에 실제로 값을 검사한다.

from pydantic import BaseModel

class User(BaseModel):
    id: int
    name: str
    age: int

user = User(id="123", name="Alice", age="25")
# → User(id=123, name='Alice', age=25)  # 자동 타입 변환

변환 불가능한 값은 생성 시점에 바로 에러:

User(id="abc", name="Alice", age="25")
# ValidationError: id - Input should be a valid integer

FastAPI에서의 역할

FastAPI는 사실상 Pydantic 위에서 돌아간다. 클라이언트 JSON을 받아 파싱 → 타입 검증 → Python 객체 생성까지 자동으로 처리한다.

class CreateUserRequest(BaseModel):
    email: str
    age: int

@app.post("/users")
async def create_user(req: CreateUserRequest):
    ...

Note

이름의 유래: Py(thon) + dantic(pedantic에서) — “꼼꼼하게 따지는”이라는 뜻. 데이터 검증 라이브러리 이름으로 딱 맞는 셈이다.

한 줄 요약: “Python 타입 힌트를 실제 런타임 검증 도구로 만들어 주는 라이브러리”

Context

코드 작업 중 “포팅한다”는 표현을 접하고 정확한 의미를 정리했다.

What I Learned

포팅(Porting)이란 기존 소프트웨어를 다른 플랫폼이나 환경으로 옮기는 작업이다.

종류	예시
플랫폼 포팅	Windows 앱 → Linux, iOS 앱 → Android
언어 포팅	C → Python, Java → C#
버전 포팅	Python 2 → Python 3, 구버전 라이브러리 → 신버전
아키텍처 포팅	32비트 → 64비트, x86 → ARM

“재작성”과 달리 기존 로직을 최대한 유지하면서 환경만 바꾸는 것이 핵심이다.

Context

retry 로직 설계 관련 AWS 아키텍처 블로그를 읽다가 jitter 개념을 제대로 이해하게 됐다.

What I Learned

Exponential Backoff만으로는 부족하다

실패 후 대기 시간을 지수적으로 늘리는 exponential backoff는 좋은 전략이지만, 클라이언트가 여럿이면 문제가 생긴다. 모두 같은 공식으로 대기하면 시간이 지난 뒤 동시에 다시 몰려서 요청이 집중된다. N개 클라이언트 경합 시 작업량이 N²에 비례하게 되는 것.

Jitter란

재시도 대기 시간에 무작위성을 추가해서 요청을 시간에 분산시키는 기법이다. 반직관적으로 들리지만, 의도적인 무작위성이 전체 시스템 부하를 낮춘다.

3가지 Jitter 전략

Full Jitter — 가장 효율적, 대기 시간이 0에 가까울 수 있음

sleep = random(0, min(cap, base * 2^attempt))

Equal Jitter — 최소 대기 시간 보장

sleep = base * 2^attempt / 2 + random(0, base * 2^attempt / 2)

Decorrelated Jitter — 직전 대기 시간 기반으로 계산

sleep = min(cap, random(base, sleep * 3))

결과

Full Jitter와 Decorrelated Jitter가 가장 우수. Jitter 없는 exponential backoff 대비 작업량 50% 이상 감소.

Note

retry 로직을 짤 때 backoff만 넣고 끝내지 말 것. 클라이언트가 여럿이면 jitter 없이는 thundering herd 문제가 그대로 남는다. 실용적으로는 Full Jitter가 간단하고 효과적이다.

Context

SSH 호스트에 접속하려다가 디스크가 96% 차서 무엇을 안전하게 지울 수 있는지 파악했다.

What I Learned

안전하게 지울 수 있는 것 3가지

셋 다 **“있으면 편하지만 없어도 동작에 지장 없는 캐시성 데이터”**다.

1. 저널 로그 (/var/log/journal)

systemd-journald가 쌓는 시스템 로그. 부팅 메시지, 커널 로그, 서비스 출력, 인증 시도 등을 기록한다.

journalctl --vacuum-size=100M   # 100M만 남기고 정리
journalctl -u ssh               # sshd 로그만
journalctl -b                   # 이번 부팅 이후 로그
journalctl -p err               # 에러만

영구 제한은 /etc/systemd/journald.conf에 SystemMaxUse=100M 추가.

2. apt 캐시 (/var/cache/apt, /var/lib/apt)

• /var/cache/apt/archives/ — apt install 시 다운로드한 .deb 파일 캐시
• /var/lib/apt/lists/ — apt update로 받아온 패키지 목록 메타데이터

sudo apt clean        # .deb 캐시 삭제 (100% 안전)
sudo apt autoremove   # 더 이상 필요 없는 패키지 제거 (옛날 커널 헤더 등)

3. snapd (/var/lib/snapd)

Snap은 의존성을 통째로 묶은 컨테이너 형식 패키지. 이전 리비전을 기본 3개씩 보관해서 금방 GB 단위가 된다.

snap list                          # 설치된 snap 확인
sudo snap set system refresh.retain=2  # 보관 리비전 수 3→2로 줄이기
sudo apt purge snapd               # 서버에서 아예 안 쓴다면 제거도 가능

서버(헤드리스 환경)에서는 snap 쓸 일이 거의 없다.

---

데몬(daemon)이란

백그라운드에서 계속 돌아가는 프로세스. 부팅 시 자동 시작되어 터미널 없이 동작한다.

	일반 프로그램	데몬
시작	사용자가 실행	부팅 시 자동 시작
종료	작업 끝나면 종료	계속 떠 있음
터미널	붙어 있음	없어도 동작
예시	ls, vim	sshd, cron, nginx

Unix 관례상 이름 끝에 d가 붙는다 — sshd, journald, crond.

# 현재 실행 중인 데몬 목록
systemctl list-units --type=service --state=running

# PPID=1인 프로세스가 대부분 데몬
ps -ef | head -20

어원은 그리스 신화의 daimon — 악마(demon)가 아니라 “보이지 않게 일을 돕는 정령” 쪽.

Note

디스크가 꽉 찼을 때 journal → apt → snapd 순으로 정리하면 보통 수백 MB~GB 확보 가능. apt autoremove는 오래된 커널 헤더까지 정리해줘서 효과가 크다.

Context

Shopify AJAX API 문서를 읽다가 “AJAX API”라는 명칭이 정확히 무엇을 뜻하는지 헷갈려서 찾아봤다.

What I Learned

AJAX 자체의 의미

AJAX = Asynchronous JavaScript And XML

페이지를 새로고침하지 않고 서버와 데이터를 주고받는 브라우저 패턴이다. XML은 이름에만 남아 있고, 현재는 JSON을 주로 사용한다. fetch, XMLHttpRequest 등이 AJAX를 구현하는 수단이다.

Shopify에서 말하는 “AJAX API”

일반 API와 달리 스토어 프론트엔드 JS에서 직접 호출하도록 열어둔 unauthenticated HTTP 엔드포인트 묶음이다. 이름에 AJAX가 붙은 건 역사적·용도적 이유에 가깝다.

	일반 API	Cart AJAX API
사용 주체	외부 시스템 / 백엔드	스토어 테마 JS
인증	필요	불필요 (guest cart 가능)
상태 관리	-	세션 기반 cart state

흔한 오해

• ❌ “AJAX API = 다른 종류의 API” → 그냥 HTTP 엔드포인트
• ❌ “fetch랑 AJAX는 다른 기술” → fetch는 AJAX를 구현하는 방법 중 하나
• ❌ “특별한 프로토콜” → 그냥 HTTP

Note

“AJAX API”라는 이름은 기술적 특이성보다 **설계 의도(프론트엔드에서 바로 쓸 수 있는 unauthenticated 엔드포인트)**를 나타내는 표현에 가깝다.