← 서재

월간 아루나

8

2026

2026년 8월 · 14

월간 아루나

2026년 8월

이달에 쓴 기록 14편. 만들던 것끼리 묶어 실었습니다.

이번 호 이어읽기 →
  1. 01

    노션도 지라도 아니었다 — 20년 된 물건에서 내 대시보드의 답을 찾았다

    프로젝트 관리 도구를 고르다 지라도 노션도 기각하고, org-mode라는 20년 검증된 패턴을 발견했다. Emacs는 안 배우고 "파일이 진실, 화면은 조립"이라는 원리만 훔쳐 마크다운+AI로 내 대시보드를 짓기 시작한 첫 이틀의 기록.

    2026-08-03

  2. 02

    AI가 분류하다 자꾸 틀리길래, 판단을 없애버렸다 — 폴더 = 카테고리

    계획 파일 문법이 태어난 날의 기록. 목표 파일을 만들려다 "떨렁 있으면 안 쓰게 된다"는 한마디로 설계가 뒤집혔고, org-mode의 기능을 다 갖다 쓰는 대신 "화면을 바꾸는 속성만" 남겼다. 마지막엔 AI의 추상 분류 대신 "폴더 = 카테고리"라는 눈으로 보는 규칙이 이겼다.

    2026-08-03

  3. 03

    이 글이 저장되면 오늘 루틴이 자동으로 끝난다

    일지·루틴 시스템이 세 번 죽은 이유를 부검했더니 답이 하나였다 — 죽은 건 전부 "따로 실행해야 하는 것"이었다. 그래서 루틴의 판정을 기계에 넘겼다. 파일이 있으면 한 거다. 클릭조차 필요 없다. 지금 이 글이 저장되는 순간, 오늘의 글쓰기 루틴은 자동으로 완료된다.

    2026-08-03

  4. 04

    내 사업 로드맵을 RPG 레벨제로 바꾼 이유

    하루 종일 일해도 로드맵이 0%였다. 범인은 넷 — 층이 섞였고, %는 분모가 계속 커졌고, 숫자가 엉뚱한 걸 세고 있었고, 완료를 옮기면 진행이 증발했다. 마일스톤을 RPG 레벨로 바꾸고 "진행률 = 조건 충족률"로 재정의하자 로드맵이 움직이기 시작했다. 그리고 이 구조가 AI 업계의 루프 엔지니어링과 같은 것임을 알게 됐다.

    2026-08-03

  5. 05

    대시보드가 안 보이는 이유는 정보량이 아니었다 — 한 장에 질문 하나

    파일도 문법도 측정도 다 만들었는데 화면이 여전히 안 보였다. 나흘간 세 번 "안 보인다"를 말하며 찾은 범인들 — 어떤 날은 소스, 어떤 날은 뷰, 그리고 마지막 진짜 범인은 정보량이 아니라 "한 장에 여러 질문이 섞인 것"이었다. 장마다 질문 하나씩 주자 드디어 보이기 시작했다.

    2026-08-03

  6. 06

    파일이 진실, 화면은 조립 — 비개발자의 org-mode 대시보드 전체 설계도

    메모 앱 무덤에서 plain text를 갈망하다 org-mode를 알게 됐던 게 옛날. AI 시대가 "텍스트로의 귀환"을 일으키자 그 기억이 돌아왔고, "한 줄 한 줄 태깅해두면 화면은 뿌리기만 하면 된다"는 가설을 6일간 검증했다. 시리즈 5편의 총정리이자, 오래된 가설이 검증된 회고. 이 글이 저장되는 순간 시리즈의 완료 조건이 기계 판정으로 찬다.

    2026-08-03

  7. 07

    위키를 사업계획서 양식으로 쌓기로 했다 — 기획이 탄탄해지는 부수 효과

    위키 한 벌에서 슬라이드가 나오는 걸 확인한 뒤, 사업계획서와 할 일까지 뽑으려 했다. "문서를 잘 쓴다는 게 뭘까"를 파다가 사업계획서 양식에 도착했고, 따져보니 산출물보다 기획 자체가 좋아지는 물건이었다. 그리고 할 일을 뽑을 때는 AI 추론이 아니라 기계 파싱이어야 한다는 걸 숫자로 알게 됐다.

    2026-08-10

  8. 08

    요리하면서 설거지하는 시스템을 만들려다 — 문제는 부엌이 아니라 레시피였다

    작업이 끝나면 정리할 힘이 남지 않았다. 그래서 만드는 동시에 결과가 되는 시스템을 한 달 동안 실험했다. 화면을 고치다 문서 구조가 먼저라는 결론에 닿았다.

    2026-08-12

  1. 01

    왜 나는 AI에게 일을 맡길 수 없었을까 — 에이전트보다 먼저 필요했던 업무의 틀

    AI를 못 믿어서가 아니라 요구사항의 입구와 완료·검수의 출구가 없어서 매 단계 개입해야 했다. 브리프부터 완료 기준과 검수까지 이어지는 작은 업무의 틀을 만든 과정.

    2026-08-28

  2. 02

    새 AI가 나올 때마다 시스템을 갈아엎지 않으려면 — 오래가는 중심과 갈아 끼우는 바깥층

    새 모델과 도구가 나올 때마다 작업환경 전체를 옮겨야 할 것 같아 지쳤다. 내가 계속 보유할 업무 기준과 교체 가능한 AI·도구를 나누고, 보이지 않던 시스템을 한 장의 지도로 이해한 과정.

    2026-08-28

  1. 01

    슬라이드를 따로 안 만들기로 했다 — 위키만 잘 쓰면 저절로 나온다

    강의용 슬라이드가 필요해 위키를 자동 변환해봤더니, 안 되는 데가 하나같이 원래부터 안 읽히던 문단이었다. 변환 규칙을 다섯 번 손보다 방향을 바꿔 원문을 다듬자 한 챕터가 통째로 들어맞았다. 슬라이드를 위해 뭘 따로 만들 필요가 없었다.

    2026-08-07

  2. 02

    같은 코드가 10곳에 복사돼 있었다 — 바이브 코딩, 언제 한 번 멈춰서 정리해야 할까

    잘 굴러가던 사이트에 기능을 더 붙이기 전에 열어봤더니 같은 코드가 10곳, 색 지정이 477군데였다. 하루를 비워 정리하는 동안 몰랐던 버그 2개가 나왔고, 수업 중인 사이트가 갈릴 뻔한 것도 그때 알았다. 언제 멈춰서 정리해야 하는지의 신호 다섯 가지.

    2026-08-08

그 밖의 기록

2
  1. 01

    AI가 내 문서를 다 읽지 않아도 되게 — 색인부터 한 층씩 열리는 구조

    AI에게 규칙을 적을수록 더 안 지켜졌다. 새벽에 같은 잘못을 세 번 적발하다 "애초에 청소할 게 없어야 한다"는 원리에 도달했고, 문서를 스킬처럼 필요할 때만 열리는 구조로 바꾸기로 했다. 그리고 그 설계를 AI 비평가 3명에게 부수게 했다.

    2026-08-04

  2. 02

    만들어보고서야 안 만들어도 된다는 걸 알았다 — AI용 문서 지도를 만들고 그날 버린 기록

    AI가 문서를 다 읽지 않게 하려고 "지도"를 만들었다. 조사에선 이미 도구가 있다고 했는데 절반은 빈 껍데기였고, 직접 만들어 검증까지 마친 뒤 명령어 한 줄에 밀려 전부 지웠다. 그런데 지도를 버리고도 방식은 살아남았다 — 만들어봤기 때문에 그 둘을 가를 수 있었다.

    2026-08-05