Notes
개발 노트
제품별 개발기와 공통 기술 노트를 나눠서 기록합니다. 결과뿐 아니라 왜 만들었고, 어디에서 막혔고, 어떤 기준으로 바꿨는지까지 남깁니다.
날짜는 글을 한꺼번에 정리한 날이 아니라, 해당 문제와 결정을 실제 개발 흐름에서 다룬 시점을 기준으로 정리합니다.
Category
BABY DAY
BABY DAY를 만들고 실제 사용자에게 공개하면서 겪은 제품·PWA·알림·계측 이야기
수유 기록 시간이 한꺼번에 이상해졌을 때 데이터 복구를 먼저 한 이유
BABY DAY에서 일부 수유 종료 시간이 비정상적으로 보였을 때 코드 수정보다 데이터 보존·원인 범위·선택 복구를 먼저 확인한 운영 기록입니다.
BABY DAY 운영 배포에 승인 게이트를 둔 이유
코드 수정 완료와 운영 배포를 분리하고, 환경·백업·헬스체크를 통과한 뒤에만 운영에 반영하도록 바꾼 과정을 정리했습니다.
PWA를 배포했는데 어떤 사용자에게는 이전 화면이 보였던 이유
BABY DAY 새 버전을 배포했는데 일반 창에는 구버전이 남고 시크릿 창에는 최신 버전이 보였던 상황에서 확인한 Service Worker 업데이트 흐름입니다.
BABY DAY 수유·수면 알림을 고정 시간이 아니라 평균 텀으로 만든 이유
모든 아기에게 같은 간격을 강요하지 않고, 초기에는 권장 기준을 보여준 뒤 기록이 쌓이면 개인 평균으로 전환한 알림 설계를 정리했습니다.
가입자는 늘었는데 방문자는 몰랐다: BABY DAY에서 Analytics를 늦게 붙인 대가
BABY DAY 초기 사용자가 늘어나는 동안 웹 Analytics를 연결하지 않아 유입과 행동을 제대로 해석하지 못했던 경험을 정리했습니다.
BABY DAY를 만든 이유: 임신 기록과 육아 기록이 끊기지 않았으면 했다
임신 중 준비하던 정보와 출산 후 수유·수면 기록이 서로 다른 도구로 흩어지는 불편에서 BABY DAY를 만들기 시작한 이유를 정리했습니다.
Category
DevWeave
바이브코딩 프로젝트를 구조화하고 coding agent와 연결하는 DevWeave 제작 기록
DevWeave의 GitHub 쓰기를 ‘항상 허용’이 아니라 승인 뒤에 여는 이유
기존 GitHub 프로젝트를 이어서 작업할 때 DevWeave가 사용자 저장소를 직접 덮어쓰지 않고 작업 브랜치와 PR을 기본 handoff로 삼는 이유를 정리했습니다.
DevWeave에서 GitHub를 durable handoff 지점으로 잡은 이유
프로젝트 맥락을 특정 AI 채팅이나 서비스 내부에 가두지 않고 사용자 소유 저장소에 남기는 구조를 택한 이유를 정리했습니다.
DevWeave가 또 하나의 AI 코드 생성기가 아닌 이유
직접 코드를 생성하는 경쟁보다 기능·화면·데이터 관계와 변경 영향을 정리해 어떤 coding agent에게도 넘길 수 있게 하는 범위를 택한 이유입니다.
DevWeave를 만든 이유: 바이브코딩이 빨라질수록 프로젝트는 더 쉽게 꼬였다
AI가 코드를 잘 만드는 것과 프로젝트가 오래 유지되는 것은 다른 문제라는 경험에서 DevWeave를 만들기 시작한 이유를 정리했습니다.
Category
바이브코딩
기능을 빠르게 추가하면서 프로젝트가 복잡해지는 순간과 구조를 다시 잡는 방법
Category
AI Coding
여러 AI coding agent를 실제 개발 자동화에 사용하며 확인한 장단점과 guard
무료 AI 여러 개를 이어 붙였더니 PM보다 Reviewer가 먼저 필요했다
무료 모델만으로 PM·Worker·QA·Reviewer를 연결하면서, 장문의 보고보다 먼저 PASS·FAIL 판정을 고정한 verdict-first 흐름을 만든 이유입니다.
무료 AI fallback을 붙이니 모델보다 검증 계층이 더 중요해졌다
한 모델이 실패하면 다른 모델이 이어받는 구조를 운영하면서 fallback 자체보다 공통 검증 규칙이 중요했던 이유를 정리했습니다.
괄호 하나 고치는데 AI 셋이 출근한 이유
테스트 파일 끝의 괄호 하나를 고치는 단순 작업이 세 개의 AI 모델과 자동 복구 시스템까지 거치게 된 과정을 정리했습니다.
AI Agent가 시키지 않은 파일까지 만들 때 막는 방법
작업 목표만 검증하는 대신 변경 가능한 경로를 미리 제한해 예상 밖의 수정과 파일 생성을 자동으로 차단한 경험을 정리했습니다.
Task MD를 source of truth로 두니 긴 개발 대화가 덜 흔들렸다
대화 내용 대신 실제 task 문서를 기준으로 작업 상태와 요구사항을 이어가면서 생긴 장점을 정리했습니다.
Coding Agent를 바꿀 때 프로젝트를 처음부터 설명하지 않으려면
Codex, Claude Code, OpenCode처럼 도구를 바꿔도 프로젝트 컨텍스트를 유지하기 위해 저장소에 남겨야 했던 정보를 정리했습니다.
Category
GitHub·자동화
GitHub Actions, self-hosted Runner와 자동 복구 흐름을 운영한 경험
Windows Runner를 AWS로 옮기면서 자동화를 끊지 않기 위해 확인한 것
기존 Windows self-hosted Runner를 유지한 채 AWS Ubuntu ARM64 Runner를 병행하고, 격리·경로·도구·복구 흐름을 확인하며 전환한 기록입니다.
Windows Runner에서 Linux 명령이 나왔을 때 알게 된 것
AI agent가 실행 환경을 잘못 추측해 Linux 명령을 사용했던 경험을 통해 runner 환경 정보를 작업 입력에 포함해야 하는 이유를 정리했습니다.
집 PC를 GitHub Actions Runner로 쓰면서 먼저 정한 것들
항상 켜진 개발 PC를 자동화 러너로 사용할 때 편의성보다 먼저 분리해야 했던 권한, 비밀값, 작업 범위를 정리했습니다.
Category
서비스 운영
로컬 QA, 배포, 운영 환경처럼 코드를 고친 뒤에도 남는 문제들