DAEMON Core
모듈러 모놀리스, Vertical Slice, 그리고 내가 Django를 계속 중심에 두는 이유를 다룹니다.
Start here: Python의 철학과 Django의 철학 — 왜 나는 이 조합을 계속 선택하는가블로그
영문과 한글을 모두 포함해, 아키텍처 결정과 배포 경험, 기술 노트를 정리합니다.
Series
평평한 글 목록보다, 반복되는 주제와 관점이 보이도록 시리즈 단위로 읽히게 구성했습니다.
DAEMON Backend
계약 중심 백엔드, PostgreSQL-first, lifecycle 규칙, 도메인 경계, 실용적 성능 선택을 정리합니다.
Start here: Django DRF vs Django Ninja vs FastAPI — 내가 무엇을 언제 고르는가DAEMON UI
SPA를 기본값으로 두지 않고 HTMX와 Alpine으로 서버 중심 UI를 만드는 방식을 다룹니다.
Start here: 왜 나는 Django에서 React 대신 HTML, CSS, HTMX를 먼저 골랐는가AI Contracts
왜 나는 자연어보다 스키마를 더 믿는지, 그리고 Pydantic과 PydanticAI를 어떻게 쓰는지 설명합니다.
Start here: Pydantic은 검증기가 아니라 계약서다Deployment Patterns
릴리스 흐름, 이미지 빌드 기준, 운영을 덜 흔들리게 만드는 배포 구조를 다룹니다.
Start here: Justfile vs Docker — 비교 대상이 아니라 같이 쓰는 도구Tooling
프로젝트 명령 인터페이스, Python 패키징 기본값, 개발 속도를 좌우하는 도구 선택을 다룹니다.
Start here: uv vs pip — 왜 나는 이제 pip를 기본 선택으로 두지 않는가SportsIQ
스포츠 도메인 AI, 포즈 추정, biomechanics, 제품 방향성을 기록한 시리즈입니다.
Start here: SportsIQ 아키텍처 — 스포츠과학과 포즈 추정이 만나는 방식DAEMON Core
- Python의 철학과 Django의 철학 — 왜 나는 이 조합을 계속 선택하는가 Python과 Django는 단순히 인기 있는 도구가 아니라, 읽기 쉬움과 실용성을 중심에 두는 철학적 연속선 위에 있다. 2026-03-17
- Modular Monolith vs Microservice — 왜 나는 먼저 모놀리스를 고른다 마이크로서비스는 멋있어 보이지만, 대부분의 초기 제품에서는 문제를 해결하기보다 운영 복잡도만 키운다. 2026-03-15
- 왜 나는 Vertical Slice를 고집하는가 기능별로 코드를 수직으로 묶는 Vertical Slice는 단순한 폴더 취향이 아니라, 응집도와 유지보수성을 지키는 구조적 선택이다. 2026-03-16
DAEMON Backend
- Django DRF vs Django Ninja vs FastAPI — 내가 무엇을 언제 고르는가 Django DRF, Django Ninja, FastAPI는 각각 잘하는 일이 다르다. 내가 실제 제품과 운영 기준에서 어떤 선택을 하는지 정리했다. 2026-03-18
- 왜 나는 FastAPI가 아니라 Django + Pydantic + HTMX를 택했는가 FastAPI가 나쁜 도구라서가 아니다. 제품 흐름, 관리자 화면, 서버 렌더링, 구조적 일관성까지 묶어 생각하면 Django + Pydantic + HTMX가 내 기준에 더 맞는다. 2026-03-22
- PostgreSQL 하나로 Redis를 버린 이유 100만 트래픽 미만에서는 Redis보다 PostgreSQL 하나로 단순한 아키텍처를 유지하는 편이 더 낫다고 판단한 이유를 정리했습니다. 2026-03-19
- PostgreSQL-first 아키텍처: Redis 없이도 꽤 멀리 갈 수 있다 처음부터 DB를 여러 개 깔기보다 PostgreSQL 하나를 깊게 쓰는 편이 운영과 개발 모두에서 더 강한 경우가 많다. 내가 PostgreSQL-first를 기본값으로 두는 이유를 정리했다. 2026-03-23
- signals를 버리고 django-lifecycle을 택한 이유 signals는 편리해 보이지만 로직의 위치를 흐리게 만들기 쉽다. 상태 변화가 중요한 시스템일수록 django-lifecycle 쪽이 읽기 쉽고 통제 가능했다. 2026-03-23
- 도메인 경계를 지키는 Django: interface.py를 강제하는 설계 도메인 간 직접 import를 허용하면 모놀리스는 금방 엉킨다. 나는 Django 안에서도 interface.py를 경계로 세워 결합을 통제하려고 한다. 2026-03-24
- JSON-LD를 백엔드 내부 계약에까지 끌어오는 이유 JSON-LD를 SEO 태그 정도로만 보면 반만 본 셈이다. 나는 도메인 간 데이터의 의미를 더 분명하게 만들기 위해 백엔드 계약에도 JSON-LD 관점을 가져온다. 2026-03-24
- Rust를 배우지 않고 Rust 성능 가져오기: granian, orjson, pydantic v2 직접 Rust를 쓰지 않아도 Rust로 만들어진 좋은 Python 생태계 부품을 조합하면 꽤 큰 성능 이점을 가져올 수 있다. 내가 선호하는 방식은 직접 구현보다 레버리지다. 2026-03-24
DAEMON UI
AI Contracts
- Pydantic은 검증기가 아니라 계약서다 나는 Pydantic을 단순한 입력 검증 도구로 보지 않는다. 사람 입력, 도메인 간 통신, AI 출력까지 같은 계약 위에 올리기 위한 구조적 도구로 본다. 2026-03-24
- AI 시대의 백엔드 설계: 자연어보다 스키마를 믿는 이유 LLM이 똑똑해질수록 오히려 스키마가 더 중요해진다. 자연어는 유연하지만, 시스템 경계에서는 결국 구조화된 계약이 더 신뢰할 만하다. 2026-03-24
- PydanticAI로 멀티에이전트를 붙일 때 중요한 건 모델이 아니라 결과 스키마다 에이전트 시스템에서 모델 선택은 중요하지만, 운영 안정성을 가르는 것은 결과 스키마다. 나는 좋은 프롬프트보다 검증 가능한 결과 계약을 더 믿는다. 2026-03-24
Deployment Patterns
Tooling
- uv vs pip — 왜 나는 이제 pip를 기본 선택으로 두지 않는가 pip은 설치 도구이고 uv는 프로젝트 전체 생명주기를 더 넓게 다룬다. 지금 내 기본값은 uv다. 2026-03-10
- pyproject.toml vs requirements.txt — 선언과 설치를 같은 것으로 보면 안 된다 pyproject.toml은 프로젝트 선언이고 requirements.txt는 설치 스크립트에 가깝다. 둘은 역할부터 다르다. 2026-03-11
- Justfile — 왜 나는 프로젝트 표준 명령어를 따로 만든다 Justfile은 단순한 명령어 단축키가 아니라, 팀과 프로젝트의 표준 실행 인터페이스를 만드는 도구다. 2026-03-13