공개 브랜드 노트 · 2026.09.01

문제를 먼저 정의하고,
검증 가능한 시스템으로 번역합니다.

이지훈이 혼자서 기획·개발·심사·운영까지 맡아 온 23개월의 기록입니다. 사례 5건은 App Store 에서 판매 중인 앱, 라이브로 돌아가는 1인 회사 ERP, 심사 제출을 자동화한 파이프라인을 다룹니다.

아래 숫자와 사례의 모든 수치는 손으로 적지 않습니다 — 빌드할 때마다 git 과 API 에서 다시 잽니다.

사례 5건 보기 이지훈 소개

커밋: 2,008
저장소: 7
개월: 23
공개 문서: 15

만든 것 5건

각 사례는 문제 → 결정 → 만든 것 → 전후 지표 → 실패 순으로 같은 틀을 씁니다.

무엇을 만들었고, 어떻게 만드는가

만든 것9

여정 — 2024년 첫 커밋부터 지금까지의 전체 기록

2024년 11월 첫 커밋부터 지금까지, 흩어진 저장소에 쌓인 2,008커밋을 하나의 성장 서사로 엮은 기록. 실패와 시행착오도 증거로 남긴다.

git 실측 기반 연대기

읽기

에이전틱 엔지니어링 다섯 단계 — 만드는 방식이 바뀐 23개월

무엇을 만들었는지가 아니라, 만드는 방식이 어떻게 바뀌었는지의 기록. 2024-11 첫 커밋부터 오늘까지, 7개 저장소 실측으로만 그린다.

git 실측 · 경험 기록 대기

읽기

사례 1 — 기획서.hwp에서 App Store 판매중까지 (22개월)

문제: 혼자서 기획→백엔드→모바일→심사→배포→재심사까지 전부 해야 했다 (거절 3회 포함). 해결: Flutter 전환 + ASC API 제출 자동화 + 서명 파이프라인 구축. 결과: Moon Whisper App Store 판매중(READY_FOR_SALE), 재제출이 당일 처리되는 체계 확립.

22개월 · App Store 판매중 실측

읽기

사례 2 — 1인 회사 ERP (sfx-web-services, 189커밋)

문제: 1인 회사의 모든 상태(고객·재무·제작·전달)가 이메일과 머릿속에 있었다. 해결: 접수→인증→분류→제작→전달 상태 머신을 갖춘 웹 시스템 + 어드민 16화면. 결과: 189커밋, 테스트 35건, 라이브 사이트(solve-for-x.net 200), E2E 1건 실측 통과.

189커밋 · 어드민 16화면

읽기

문제: 여러 AI 에이전트가 같은 repo를 두고 충돌했고, 누가 무엇을 했는지 대화 기록으로는 판정이 안 됐다. 해결: AI에게 권한이 아니라 계약을 — 5부서 조직, handoff STATE 머신, 삼중 신호 판정기, 사람 승인 게이트 6종. 결과: 충돌이 8단계로 자동 판정되고, 부서 상태가 파일로 영속화되며, 위험 경계가 명문화된 조직이 됐다 (현재도 운영중).

운영중 · 판정기 실측

읽기

사례 4 — App Store 심사 자동화와 서명 지옥

문제: 3개 앱의 심사 제출이 웹 콘솔 수동 작업이었다 — 느리고, 기록이 안 남고, 반복될수록 실수가 쌓였다. 해결: ASC(iris) API 직접 호출로 제출 자동화 + GitHub Actions 서명 업로드 파이프라인. 결과: 제출 전문 9,100줄이 증거로 남고, 서명 실패 3단계를 커밋으로 극복 — 재제출이 절차가 아닌 명령이 됐다.

App Store Connect API 9,100줄 증거

읽기

사례 5 — 지식 플라이휠: 위키가 스스로 도는 구조

문제: 기록은 쌓이는데 다시 안 읽게 되는 — 노트의 운명을 바꾸고 싶었다. 해결: 원본 하나에서 화면·검색·공개가 자동 파생되는 구조 + 브라우저에서 바로 쓰는 기록 루프. 결과: 294문서가 15페이지 공개 사이트·FTS5 검색·이슈 기반 기록으로 자동 순환 — 이 케이스 스터디도 그 산출물이다.

3계층 라이브 실측

읽기