백엔드/Python-Flask 작지만 기억할 만한 네 가지: Alembic 빈 마이그레이션, 시뮬레이션 엔드포인트, F841 ignore, 'done' vs 'success' 시리즈 마지막 편은 작지만 기억할 만한 네 가지 수정을 묶었습니다. 빈 Alembic revision이 생기는 이유, "시뮬레이션" 주석이 남긴 엔드포인트, F841 ignore 뒤의 숨은 버그, 프론트/백엔드 상태 문자열 불일치 — 모두 "임시는 영구화된다"는 공통 교훈을 가집니다.
백엔드/Python-Flask 하나의 백엔드로 Detection/Classification/Segmentation 지원하기: task별 데이터셋 포맷 분기 UI의 task 드롭다운은 있었지만 백엔드는 항상 detection만 돌리고 있었습니다. 5 사이즈 × 3 task = 15 variant를 task별 데이터셋 포맷(bbox/ImageFolder/polygon)과 메트릭 컬럼 분기로 통합한 기록입니다.
백엔드/Python-Flask Python/SQLAlchemy N+1 쿼리 잡기: 이미지 라벨링 플랫폼 실전 편 코드 리뷰에서 발견된 세 곳의 N+1 쿼리. 이미지 100장이면 DB 라운드트립이 101회였던 이유와 `IN` 쿼리 + 벌크 DELETE로 2회로 줄인 실전 기록을 Python/SQLAlchemy로 정리했습니다. Prisma 편의 자매글입니다.
백엔드/Python-Flask JSON 파일 데이터베이스에서 PostgreSQL로: 서비스 시그니처를 유지하며 데이터 레이어 교체하기 `users.json`, `labels/*.json` 파일 저장소를 PostgreSQL로 교체하면서 라우트 9개는 한 줄도 수정하지 않았습니다. 계층 경계를 미리 뽑아 둔 지난 편 리팩토링의 보상을 그대로 보여 주는 실전 기록입니다.
백엔드/Python-Flask 1,932줄 app.py를 54줄로: 모놀리식 Flask를 Blueprint로 분해하기 인수인계 받은 Flask 백엔드의 `app.py`가 1,932줄 한 파일에 42개 API가 섞여 있었습니다. Application Factory 패턴과 Blueprint로 도메인을 분리하고, 42개 경로를 그대로 유지하며 프론트엔드 변경 없이 리팩토링한 실전 기록입니다.
백엔드/API설계 Subscription 모델링: 왜 planId는 불변이어야 하는가 (trialPlanId 분리 패턴) Trial은 구독의 한 종류가 아니라 구독 위에 얹힌 임시 레이어입니다. planId를 불변으로 유지하고 trialPlanId로 기능을 덧칠한 설계 이야기입니다.
백엔드/API설계 분산 트랜잭션이 없을 때: Payment Provider와 DB의 cancelFailed 롤백 패턴 DB + PG의 다단계 연산은 원자적이지 않습니다. Saga 보상 대신 마커를 저장하고 cron이 자동 복구하는 패턴으로 해결했습니다.
백엔드/API설계 스케줄 결제의 숨겨진 덫: PENDING Invoice를 먼저 만들어야 하는 이유 webhook을 Invoice 생성 트리거로 쓰면 세 가지 문제가 터집니다. 스케줄 등록 시점에 PENDING Invoice를 미리 만드는 구조로 해결한 방법을 정리했습니다.
도구/Obsidian E2E 스위트가 하나로 부족해진 날: Obsidian 플러그인에 두 번째 CDP 테스트 추가하기 첫 번째 CDP E2E 스위트 글의 속편. multi-config 리팩토링에서 Settings UI를 검증하기 위해 두 번째 E2E 스위트를 추가했고, 그 과정에서 51줄의 CDP 인프라 코드를 공유 모듈로 추출했습니다. 두 스위트를 하나의 Obsidian 인스턴스에서 돌리는 격리 규칙과 공유 경계 설계까지.
도구/Obsidian Singleton을 Per-Instance로 바꾼 뒤 찾아온 메모리 누수: 16줄로 잡은 Orphaned RateLimiter Obsidian 플러그인의 multi-config 리팩토링 중 발견한 조용한 메모리 누수: config를 삭제해도 그 config가 쓰던 RateLimiter가 공유 Map에 그대로 남았던 버그의 원인과 3파일 16줄짜리 fix. Per-instance 서비스 전환 시 주의해야 할 4가지 cleanup 함정을 정리했습니다.
도구/Obsidian Obsidian 플러그인을 Multi-Database로 리팩토링하기: DatabaseProvider 추상화와 FieldType 정규화 Airtable에 강결합돼 있던 Obsidian 플러그인 서비스 레이어를 provider-agnostic DatabaseProvider 인터페이스로 추상화한 2단계 리팩토링(PR #49, #50) 기록. 런타임 capability flag, 5-way discriminated union credential, 29→11 StandardFieldType 정규화까지 395/395 테스트를 유지하며 진행한 설계 결정을 공유합니다.
도구/Obsidian 하나의 Obsidian Vault에서 여러 Airtable 동시 싱크: Multi-Config 아키텍처 구현기 Airtable 플러그인을 단일 config에서 multi-config 멀티테넌트 구조로 확장한 경험. ConfigInstance와 ConfigManager의 역할 분리, credential-scoped RateLimiter 공유, defensive + idempotent 마이그레이션, 폴더 겹침 검증, Obsidian command palette의 dynamic re-registration까지.
백엔드/API설계 마크다운 3포맷 자동 감지 파서 설계: legacy, frontmatter, plain을 한 파서로 기존 사용자의 레거시 포맷을 깨지 않으면서 표준 frontmatter와 일반 마크다운까지 지원해야 했습니다. 감지 순서, fallback 설계, 그리고 strategy 패턴을 포기한 이유를 정리합니다.
백엔드/API설계 TypeScript로 읽기 전용 상태 표현하기: Ghost 'sent' 상태 타입 분리 설계 시스템이 자동 설정하는 상태를 타입으로 어떻게 강제할까요? Ghost 포스트의 sent 상태를 예시로, Read 타입과 Write 타입을 분리해 invariant를 컴파일 타임에 보장하는 설계 패턴을 정리합니다.
백엔드/API설계 Ghost API 태그 삭제가 안 되는 이유: 빈 배열과 PATCH 시맨틱의 함정 Ghost MCP 개발 중 발견한 태그 삭제 silent failure. spread-if 패턴이 PATCH 요청에서 왜 위험한지, 그리고 빈 배열을 명시적으로 전송해야 하는 이유를 정리합니다.
AI/Claude Code 실패도 캐싱하라: API 클라이언트 회복력을 위한 TypeScript 패턴 (negative caching + discriminated union) API hammering을 막으려면 실패도 캐시해야 합니다. 30초 negative caching, 1시간 stale fallback, 그리고 TypeScript discriminated union으로 "데이터 또는 에러" 불변식을 타입에 박아 넣는 세 단계 패턴을 정리합니다.
AI/Claude Code claude-dashboard v1.14~v1.24: stdin 우선, OSC8 링크, 그리고 파서를 한 번 더 100배 빠르게 claude-dashboard v1.14~v1.24의 변화를 정리합니다. Claude Code stdin이 새 필드를 추가하면서 API 호출을 0으로 줄였고, 트랜스크립트 파서를 두 번 더 100배 빠르게 만들었으며, lastPrompt 위젯의 데이터 소스를 history.jsonl로 옮겼습니다.
프론트엔드/React 한 기능을 수직으로 덮는 테스트 피라미드: Weekly Report 기능의 50+ 테스트 사례 연구 주간 리포트 하나를 출시하는 데 유닛 41개 + E2E 10개 = 51개 테스트가 필요했다. 같은 기능을 왜 여러 층위에서 반복 검증하는가? 피라미드 각 층의 역할과 '어떤 테스트를 어디에 둘지'의 구체적 선택.
백엔드/API설계 UI는 좁게, API는 넓게: 타임존 설정의 두 단계 검증 전략 조직별 타임존 설정에서 드롭다운은 6개만 보여주지만 API는 IANA 전체를 받습니다. 이 '좁은 UI, 넓은 API' 패턴이 왜 단순 화이트리스트보다 나은지, 그리고 Intl.DateTimeFormat으로 어떻게 구현하는지.
백엔드/API설계 메모 한 통에 10MB? API 입력 길이 제한으로 무제한 텍스트 남용 막기 리포트 메모 필드에 아무 제한 없이 문자열을 받고 있었다. 악의든 실수든 누군가 MB 단위 텍스트를 넣으면 DB와 네트워크가 먼저 비명을 지른다. 5분이면 추가할 수 있는 방어선을 PR 리뷰에서 발견한 기록.
백엔드/API설계 new Date(2026, 3, 6)의 9시간 드리프트: 테스트 픽스처는 왜 반드시 Date.UTC()여야 하는가 CI는 초록불인데 로컬에선 빨간불이 떴다. 원인은 테스트 픽스처의 new Date(2026, 3, 6) 한 줄. 로컬 타임존 생성자는 개발자 KST와 CI UTC 사이에서 9시간 어긋나고, 주차 경계 테스트를 조용히 깨뜨렸다.
백엔드/API설계 Active, Ongoing, Completed: 주차 기반 태스크 상태 쿼리의 3가지 의미론과 그 함정 '이번 주 진행중인 태스크'를 쿼리하는 방법이 세 가지나 있었다. '주 중에 전환된', '주 동안 어느 시점이라도', '주 시작 시점에'. 말로는 비슷하지만 SQL은 전혀 다르고, 틀리면 이전 주부터 계속 진행되던 태스크가 리포트에서 사라진다.
백엔드/API설계 과거 주차 조회에서 '그 당시 최신 스프린트'는 뭐였나: weekEnd 기준 latest sprint 설계 주간 리포트 API가 '이번 주의 latest sprint' 개념으로 태스크를 골라왔는데, 과거 주차를 조회하면 '그 당시'가 아닌 '지금의' latest sprint가 튀어나왔다. carry-over 없이 버려진 태스크까지 리포트에 다시 나타나는 버그였다.
백엔드/Prisma 순차 루프를 10배 빠르게: Promise.all 병렬화 + findMany distinct 배치화로 API 응답 시간 잡기 주간 리포트 API가 과제 수에 비례하여 느려졌다. for 루프의 sprint+task 쿼리를 Promise.all로 병렬화해 10배, findFirst N회를 findMany(distinct) + createMany 2쿼리로 바꿔 50배. 두 최적화를 한 커밋에 담은 기록.
백엔드/Prisma 과거의 진실을 기록하는 법: Append-only ProjectStatusLog로 구현한 historical 주간 리포트 이번 주 주간 리포트를 보는데, 지난 달에 완료된 과제가 목록에서 사라졌다. 현재 상태(status=완료)로 필터하면 과거 주차 리포트가 오염된다 — 이 문제를 append-only 로그로 해결한 방법.
