Repository navigation
Home
한 줄로 적으면 날짜·시각·카테고리가 알아서 붙는 캘린더 할 일 앱.
7시 러닝이라고 치면 오늘 19:00에 '운동' 카테고리로 들어간다.
iOS 17.0+ · SwiftUI + SwiftData · 1인 개발 · App Store · 저장소
이 앱은 대부분 AI와 함께 만들었다. 최종 목표는 같은 결론에 토큰을 덜 쓰고 도달하는 것이고, 모든 판정은 프롬프트당 토큰(M12)으로 마무리한다.
그 과정을 버전마다 측정해서, 어떤 작업 규칙이 실제로 재작업을 줄였는지 채점하고 있다. 보고서는 기록이 아니라 하네스를 고치기 위한 것이다 — 읽고 나서 규칙이 안 바뀌면 그 보고서는 쓸 이유가 없었다는 뜻이다.
| 버전 | 내용 |
|---|---|
| v1.1.0 | 첫 보고서. 베이스라인과 규칙 R1~R10 도입 |
| v1.2.0 | 첫 채점. 프롬프트당 토큰 절반, 회귀 테스트 0→108 |
| v1.3.0 | 또 절반. 6.7M/프롬프트. 지표 셋이 측정 불능이 된 사건 |
PATCH를 포함해 태그를 찍는 모든 버전에 보고서를 쓴다. 안 쓰면 그 구간의 지표가 다음 MINOR에 섞여 무엇 때문에 움직였는지 못 읽는다. PATCH는 2·3·6절만 한 쪽으로.
태그를 찍는 모든 버전에 같은 절 구성으로 쓴다. 같은 자리에 같은 것이 있어야 버전 간 비교가 되기 때문이다.
| 절 | 다루는 것 |
|---|---|
| 1. 보고서 개요 | 목적 · 구성 · 대상 · 요약 |
| 2. 이전 사용 결과 | 적용돼 있던 하네스와 그 성적 |
| 3. 결과 분석 | 그 성적이 왜 그렇게 나왔나 |
| 4. 추후 사용될 하네스와 그 이유 | 앞으로 쓸 구성과 각각의 근거 |
| 5. 기대효과 | 무엇을 기대하며, 어떻게 성패를 가르나 |
| 6. 비용과 구성 | 토큰이 어디로 갔나 · 모델 구성 · 서브에이전트 구성 |
규칙 · CLAUDE.md
세션이 시작되면 자동으로 읽힌다. 각 규칙에는 담당 지표가 있고 버전마다 채점받는다. 두 버전 연속 효과가 없으면 폐기한다 — 지켜지지 않는 문장을 문서에 남겨두지 않는 것이 이 체계의 요점이다.
| 규칙 | 담당 지표 | |
|---|---|---|
| R1 | 빌드가 통과하기 전에는 보고하지 않는다 | M3 빌드 실패율 |
| R2 | 시뮬레이터를 직접 쓰지 않는다. 검증은 테스트 코드로 남긴다 | M11 시뮬레이터 호출 수 · M10 |
| R3 | 다 됐다고 판정하는 것은 사람이다 | M1 재지시율 · 검증 통과율 |
| R4 | 성능은 숫자 없이 말하지 않는다 | M4 감각 피드백률 |
| R5 | 목록은 쪼개고, 갈림길은 되묻고, 항목별로 돌려준다 | M2 배치 유발 배수 |
| R6 | 규범을 먼저 읽고, 어기게 되면 먼저 말한다 | M7 · M8 |
| R7 | 작업물마다 그것을 검증하는 테스트를 남긴다 | M10 회귀 테스트 수 |
| R8 | 작업 크기를 먼저 말하고, 위임할 때는 모델을 고른다 | M13 상위 모델 비중 |
| R9 | 넓은 조사는 서브에이전트에 위임한다 | M14 위임 비중 |
| R10 | 읽는 범위를 좁힌다 | M15 전체 읽기 비율 |
v1.2.0에서 처음 채점됐다. R2·R7·R10이 효과, R9가 무효, 나머지 여섯은 표본 부족으로 미확인이다. 프롬프트 35개는 비율 지표를 판정하기에 모자라고, "50개 미만이면 미확인"이라는 자기 기준을 그대로 적용했다 — 숫자가 좋게 나왔다고 예외를 두면 다음에 나쁘게 나왔을 때도 예외를 두게 된다.
하네스의 최종 목표는 같은 결론에 토큰을 덜 쓰고 도달하는 것이다. 규칙 열 개가 전부 여기로 모이고, 다른 지표가 다 좋아져도 M12가 안 내려가면 그 버전의 하네스는 실패로 적는다.
| v1.0.0 | v1.1.0 | v1.2.0 | |
|---|---|---|---|
| 프롬프트당 토큰 | 17.1M | 31.1M | 15.0M |
| 그중 캐시 읽기 비중 | 97% | 97% | 98% |
| 시뮬레이터 호출 | 1,015 | 716 | 26 |
| 회귀 테스트 | 0 | 0 | 108 |
캐시 읽기가 압도적이라는 것은 **"컨텍스트에 무엇을 들였나"가 아니라 "들인 것을 몇 번 다시 읽었나"**가 비용의 본체라는 뜻이다. 스크린샷 한 장은 찍는 턴에만 비싼 게 아니라 세션이 끝날 때까지 모든 턴에 다시 실린다.
폐기 기록. CONTRIBUTING.md의 "작은 단위로 PR을 나눈다"는 전 기간 한 번도
지켜지지 않아 지웠고, 대신 브랜치와 PR을 거친다만 남겨 되살렸다. 그리고 한 번
만들었다가 지운 규칙이 하나 있다 — "바꾼 화면을 직접 열어본 뒤에 말한다". AI가 화면을
확인하는 데 v1.0.0에서 1,015회, v1.1.0에서 716회의 시뮬레이터 호출을 썼고, 그렇게
사서 얻은 판정은 "그려졌다" 하나였다. 지금은 로직은 테스트, 화면은 사람이고
AI는 그 사이를 잇는 검증 카드를 쓴다.
경위는 규칙 원장의 폐기 절.
채점할 수 없지만 필요한 것들. 부를 때만 읽히므로 규칙을 짧게 유지할 수 있다.
| 스킬 | 내용 |
|---|---|
/intake |
목록 쪼개기 → 갈림길 되묻기 → 백로그 기록 → 항목별 결과 반환 |
/handoff |
검증 카드 — 어디서 / 무엇을 하고 / 통과 조건 / 실패 조건 |
/verify |
회귀 체크리스트 — AI가 아니라 사람이 밟는 목록 |
/report |
다음 보고서 쓰는 절차 |
| 규칙 원장 | 도입 시점 · 담당 지표 · 채점 이력 · 폐기 기록 |
| 지표 원장 | 버전별 지표 한 줄씩 |
| 추출 스크립트 | 지표 정의가 정규식으로 얼려 있다 |
하나. 채점할 수 없는 규칙은 넣지 않는다. 담당 지표가 없으면 효과를 알 수 없고, 효과를 모르면 문서는 계속 늘고, 늘어난 문서는 아무도 안 읽고, 안 읽히는 문서는 규칙이 아니라 장식이다. 절차가 필요하지만 채점할 수 없는 것은 규칙이 아니라 스킬로 넣는다.
둘. 규칙은 뺄 조건을 갖고 들어온다.
무효 두 번이면 폐기, 미확인 세 번이면 다른 지표를 찾거나 스킬로 내리거나 지운다.
넣는 절차만 있고 빼는 절차가 없으면 문서는 한 방향으로만 자란다 — CLAUDE.md가
이틀에 94% 커지는 동안 지운 문장이 하나뿐이었던 것이 그 증거다.
셋. 정확한 정의보다 안 바뀌는 정의가 낫다. 지표 정의는 노이즈를 품고 있다. 그래도 버전마다 같기만 하면 노이즈도 같은 크기로 들어가므로 추세는 살아 있다. 정의를 고치면 그 순간 이전 버전과 비교가 끊긴다 — 고쳐야 하면 스키마 번호를 올리고 전체를 다시 돌린다.
| 문서 | 내용 |
|---|---|
| CONTRIBUTING.md | 커밋 · 브랜치 · PR · 문서 갱신 규칙 |
| RELEASING.md | 버전 규칙 · 태그 · 릴리스 노트 쓰는 법 |
| docs/TRAPS.md | 한 번씩 크게 시간을 쓴 플랫폼 함정 |
| 디자인 시스템 | 색 · 컴포넌트 · 문구 규범 |
| PRIVACY.md | 개인정보 처리방침 |