사례글
AI와 함께 만든 과정의 기록 22편. 서재에서 책으로 보기 →
- 01#org-mode#대시보드#프로젝트관리
노션도 지라도 아니었다 — 20년 된 물건에서 내 대시보드의 답을 찾았다
프로젝트 관리 도구를 고르다 지라도 노션도 기각하고, org-mode라는 20년 검증된 패턴을 발견했다. Emacs는 안 배우고 "파일이 진실, 화면은 조립"이라는 원리만 훔쳐 마크다운+AI로 내 대시보드를 짓기 시작한 첫 이틀의 기록.
2026-08-03
- 02#org-mode#불렛저널#계획관리
AI가 분류하다 자꾸 틀리길래, 판단을 없애버렸다 — 폴더 = 카테고리
계획 파일 문법이 태어난 날의 기록. 목표 파일을 만들려다 "떨렁 있으면 안 쓰게 된다"는 한마디로 설계가 뒤집혔고, org-mode의 기능을 다 갖다 쓰는 대신 "화면을 바꾸는 속성만" 남겼다. 마지막엔 AI의 추상 분류 대신 "폴더 = 카테고리"라는 눈으로 보는 규칙이 이겼다.
2026-08-03
- 03#루틴#습관관리#자동화
이 글이 저장되면 오늘 루틴이 자동으로 끝난다
일지·루틴 시스템이 세 번 죽은 이유를 부검했더니 답이 하나였다 — 죽은 건 전부 "따로 실행해야 하는 것"이었다. 그래서 루틴의 판정을 기계에 넘겼다. 파일이 있으면 한 거다. 클릭조차 필요 없다. 지금 이 글이 저장되는 순간, 오늘의 글쓰기 루틴은 자동으로 완료된다.
2026-08-03
- 04#로드맵#측정#레벨제
내 사업 로드맵을 RPG 레벨제로 바꾼 이유
하루 종일 일해도 로드맵이 0%였다. 범인은 넷 — 층이 섞였고, %는 분모가 계속 커졌고, 숫자가 엉뚱한 걸 세고 있었고, 완료를 옮기면 진행이 증발했다. 마일스톤을 RPG 레벨로 바꾸고 "진행률 = 조건 충족률"로 재정의하자 로드맵이 움직이기 시작했다. 그리고 이 구조가 AI 업계의 루프 엔지니어링과 같은 것임을 알게 됐다.
2026-08-03
- 05#대시보드#UI#정보설계
대시보드가 안 보이는 이유는 정보량이 아니었다 — 한 장에 질문 하나
파일도 문법도 측정도 다 만들었는데 화면이 여전히 안 보였다. 나흘간 세 번 "안 보인다"를 말하며 찾은 범인들 — 어떤 날은 소스, 어떤 날은 뷰, 그리고 마지막 진짜 범인은 정보량이 아니라 "한 장에 여러 질문이 섞인 것"이었다. 장마다 질문 하나씩 주자 드디어 보이기 시작했다.
2026-08-03
- 06#org-mode#대시보드#총정리
파일이 진실, 화면은 조립 — 비개발자의 org-mode 대시보드 전체 설계도
메모 앱 무덤에서 plain text를 갈망하다 org-mode를 알게 됐던 게 옛날. AI 시대가 "텍스트로의 귀환"을 일으키자 그 기억이 돌아왔고, "한 줄 한 줄 태깅해두면 화면은 뿌리기만 하면 된다"는 가설을 6일간 검증했다. 시리즈 5편의 총정리이자, 오래된 가설이 검증된 회고. 이 글이 저장되는 순간 시리즈의 완료 조건이 기계 판정으로 찬다.
2026-08-03
- 07#기획#사업계획서#문서설계
위키를 사업계획서 양식으로 쌓기로 했다 — 기획이 탄탄해지는 부수 효과
위키 한 벌에서 슬라이드가 나오는 걸 확인한 뒤, 사업계획서와 할 일까지 뽑으려 했다. "문서를 잘 쓴다는 게 뭘까"를 파다가 사업계획서 양식에 도착했고, 따져보니 산출물보다 기획 자체가 좋아지는 물건이었다. 그리고 할 일을 뽑을 때는 AI 추론이 아니라 기계 파싱이어야 한다는 걸 숫자로 알게 됐다.
2026-08-10
- 08#회고#월간아루나#문서설계
요리하면서 설거지하는 시스템을 만들려다 — 문제는 부엌이 아니라 레시피였다
작업이 끝나면 정리할 힘이 남지 않았다. 그래서 만드는 동시에 결과가 되는 시스템을 한 달 동안 실험했다. 화면을 고치다 문서 구조가 먼저라는 결론에 닿았다.
2026-08-12
- 01#PKM#미니멀#정제
당신의 위키가 계속 망하는 이유 — 쌓지 말고 정제하라
쌓는 위키는 무너지고 정제하는 위키는 지속된다. 버려야 정리가 되는 6단계 정제 흐름.
2026-06-05
- 02#라이프위키#자동발행#Next.js
별거 없는 하루가 콘텐츠가 되고, 브랜딩이 되고, 강의가 되기까지
사소한 과정도 결과로 만드는 시스템. 정제한 글이 자동으로 발행되는 사이트 만들기.
2026-06-10
- 03#폴더구조#git#백업
폴더 구조를 대대적으로 갈아엎으려다, 아무것도 안 바꿔도 된다는 걸 알았다
폴더 구조가 문제라고 믿고 전면 개편을 하려다, 진짜 원인이 git을 백업 용도로 오용한 것임을 찾았다. 도구를 원래 자리로 되돌리니 그동안 덧붙였던 규칙들이 같이 사라졌다.
2026-07-28
- 04#AI협업#문서관리#발표자료
슬라이드를 따로 안 만들기로 했다 — 위키만 잘 쓰면 저절로 나온다
강의용 슬라이드가 필요해 위키를 자동 변환해봤더니, 안 되는 데가 하나같이 원래부터 안 읽히던 문단이었다. 변환 규칙을 다섯 번 손보다 방향을 바꿔 원문을 다듬자 한 챕터가 통째로 들어맞았다. 슬라이드를 위해 뭘 따로 만들 필요가 없었다.
2026-08-07
- 05#바이브코딩#리팩터링#ClaudeCode
같은 코드가 10곳에 복사돼 있었다 — 바이브 코딩, 언제 한 번 멈춰서 정리해야 할까
잘 굴러가던 사이트에 기능을 더 붙이기 전에 열어봤더니 같은 코드가 10곳, 색 지정이 477군데였다. 하루를 비워 정리하는 동안 몰랐던 버그 2개가 나왔고, 수업 중인 사이트가 갈릴 뻔한 것도 그때 알았다. 언제 멈춰서 정리해야 하는지의 신호 다섯 가지.
2026-08-08
낱편
콘텐츠를 따로 만들지 않기로 했다 — 구조도를 그렸더니 이미 하고 있었다
블로그 따로, 사례글 따로, 강의 따로 만들다 지쳤다. 메모장에 내 콘텐츠 구조도를 그려봤더니 흐름이 이미 있었고, 내가 그걸 모르고 있었을 뿐이었다. 그리고 어디가 비어 있는지도 그때 처음 보였다.
2026-09-14
커리큘럼을 새로 안 만들기로 했다 — 있는 걸 쪼개서 조립한다
기수가 쌓일수록 커리큘럼이 겹치기 시작했고, 제안서를 달라는 연락이 오면 하루를 통째로 비워야 했다. AI 강의는 미리 만들어 둬도 금방 낡는다. 완성본을 쌓는 대신 64개 부품으로 쪼개 조립하기로 한 과정과, 따라 할 수 있는 프롬프트.
2026-09-11
왜 나는 AI에게 일을 맡길 수 없었을까 — 에이전트보다 먼저 필요했던 업무의 틀
AI를 못 믿어서가 아니라 요구사항의 입구와 완료·검수의 출구가 없어서 매 단계 개입해야 했다. 브리프부터 완료 기준과 검수까지 이어지는 작은 업무의 틀을 만든 과정.
2026-08-28
새 AI가 나올 때마다 시스템을 갈아엎지 않으려면 — 오래가는 중심과 갈아 끼우는 바깥층
새 모델과 도구가 나올 때마다 작업환경 전체를 옮겨야 할 것 같아 지쳤다. 내가 계속 보유할 업무 기준과 교체 가능한 AI·도구를 나누고, 보이지 않던 시스템을 한 장의 지도로 이해한 과정.
2026-08-28
만들어보고서야 안 만들어도 된다는 걸 알았다 — AI용 문서 지도를 만들고 그날 버린 기록
AI가 문서를 다 읽지 않게 하려고 "지도"를 만들었다. 조사에선 이미 도구가 있다고 했는데 절반은 빈 껍데기였고, 직접 만들어 검증까지 마친 뒤 명령어 한 줄에 밀려 전부 지웠다. 그런데 지도를 버리고도 방식은 살아남았다 — 만들어봤기 때문에 그 둘을 가를 수 있었다.
2026-08-05
AI가 내 문서를 다 읽지 않아도 되게 — 색인부터 한 층씩 열리는 구조
AI에게 규칙을 적을수록 더 안 지켜졌다. 새벽에 같은 잘못을 세 번 적발하다 "애초에 청소할 게 없어야 한다"는 원리에 도달했고, 문서를 스킬처럼 필요할 때만 열리는 구조로 바꾸기로 했다. 그리고 그 설계를 AI 비평가 3명에게 부수게 했다.
2026-08-04
AI가 일하는 게 방치형 게임 같아서, 진짜 게임으로 만들었다
AI 에이전트가 바탕화면에서 캐릭터로 일하는 펫 게임. 8시간 막힌 버그를 모델 교체 한 번으로 푼 이야기.
2026-07-06