도구/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 로그로 해결한 방법.
백엔드/Prisma findUnique → create의 함정: Prisma get-or-create 패턴의 P2002 레이스 컨디션과 3줄짜리 해법 '없으면 만들어'는 간단해 보이지만 동시 요청 2개가 들어오면 둘 다 'findUnique가 없다'를 거쳐 둘 다 create를 호출합니다. unique constraint에 걸려 P2002가 터지는 전형적인 get-or-create 레이스. try/catch 3줄로 우아하게 풀었습니다.
백엔드/API설계 Docker는 UTC, 사용자는 KST: Intl.DateTimeFormat만으로 만든 tz-aware ISO Week 유틸리티 주간 리포트의 주차 경계가 서버 컨테이너(UTC)와 사용자(KST) 사이에서 어긋났다. date-fns-tz나 luxon을 도입하는 대신, Node 22의 full-ICU Intl.DateTimeFormat만으로 IANA 타임존 ISO week 유틸리티를 구현한 기록.
백엔드/API설계 API 에러 처리 표준화: withErrorHandler 패턴으로 중앙집중화하기 API 엔드포인트가 늘어나면서 에러 처리 코드가 중복되고 응답 형식도 제각각이었습니다. withErrorHandler 래퍼와 세분화된 에러 클래스로 문제를 해결한 경험을 공유합니다.
백엔드/API설계 TypeScript Branded Types로 타입 안전성 높이기 모든 ID가 string 타입이라 인자 순서를 바꿔도 컴파일 에러가 안 났습니다. Branded Types 패턴으로 런타임 오버헤드 없이 타입 안전성을 확보한 방법을 공유합니다.
백엔드/API설계 Promise.all vs Promise.allSettled: 부분 실패를 허용하는 벌크 처리 100명에 대해 데이터를 생성하는데 1명이 실패하면 전체 99명도 실패로 처리되었습니다. Promise.allSettled로 부분 실패를 허용하는 벌크 처리를 구현한 방법을 공유합니다.
백엔드/API설계 API 에러 추적 개선하기: errorId 패턴으로 디버깅 시간 단축 "서버 오류가 발생했습니다" 메시지만으로는 어떤 에러인지 특정할 수 없었습니다. errorId 패턴으로 디버깅 시간을 90% 단축한 방법을 공유합니다.
백엔드/API설계 JavaScript 타임존 함정 피하기: UTC vs Local 날짜 처리 1월 31일을 선택했는데 1월 30일로 저장되는 버그를 발견했습니다. JavaScript Date 생성자의 타임존 해석 방식을 이해하고, 정오(12:00) 패턴으로 해결한 방법을 공유합니다.
백엔드/API설계 Next.js API에 Rate Limiting 구현하기 (메모리 기반) API 보안을 위해 Rate Limiting이 필요했습니다. Redis 없이 메모리 기반으로 구현하고 HTTP 429 표준을 준수한 방법을 공유합니다.
