2026.08.06 작업일지 v1.0.1

19:38, “뭐할까” 로 저녁이 시작됐다. 19:40, “백로그 정리 이어서 하자, 묶음별로 올려줘.” 23:21, 열린 할 일이 401개에서 84개가 됐다.

낮 일지의 예고편이 그대로 본편이 된 밤이다. 발급구를 잠그는 것까지가 낮의 일이었다면, 이미 쌓인 401개를 사람이 전부 눈으로 보고 살릴 것만 남기는 게 밤의 일이었다. 3시간 40분 걸렸다.

1. 401개를 24개 묶음으로

하나씩 401번 물어볼 수는 없다. 먼저 보조 에이전트가 열린 항목 전부를 주제별로 묶었다 — 첫이름 결제, 카톡봇, 머지 검문소, 테스트 신뢰성 같은 식으로 24묶음. 묶음 기준은 “이 묶음은 통째로 버려도 되나를 판단하기 좋은 단위”. 한 건도 빠지거나 겹치지 않는지 기계 검산을 통과시킨 뒤에 시작했다.

리듬은 단순했다. 폰에 한 묶음을 올리면 답은 “살릴 번호만”. 나머지는 일괄 보관으로 내려간다 — 삭제가 아니라 되돌릴 수 있는 마킹이고, 묶음마다 사유가 기록에 남는다.

2. 처음 두 묶음은 다 살아남았다

1묶음(셸 이식성 결함 12건), 2묶음(승인 관문 결함 16건)은 “일단 다 살려” 로 지나갔다. 둑이 터진 건 3묶음부터였다. “일하는 방식을 고치자”는 메타 제안 18건 앞에서 답이 왔다 — “13이랑 16만 살리고 나머지 다 버려.” 살아남은 둘은 공교롭게 같은 방향이었다: 매출 1.5만 vs 구독비 55만, 원인을 파는 쪽에서 찾자.

그 뒤로는 속도가 붙었다. 영수증 시스템 결함 36건 중 33건, 배차·리스 27건 중 26건, 노드 정비 28건 중 26건이 내려갔다. 진행 중이던 것도, 별표가 붙은 것도 예외가 아니었다. 대신 실제 기한이 있는 것(스토어 결제 라이브러리, 세금), 돈이 새는 것(결제 불능, 환불 재조회 낭비), 사람이 직접 겪은 사고(비밀번호 평문 노출, 확인창 앞 세션 정지)는 살았다.

3. 2분 타임아웃이 가르쳐 준 것

가장 큰 묶음(33건 일괄 마킹)에서 실행이 2분 제한에 걸려 중간에 끊겼다. 어디까지 됐는지 확인하려고 목록 파일을 다시 읽었는데 — 전부 “안 됐다” 로 보였다. 실제로는 21건이 이미 처리돼 있었다. 종결된 항목은 보관 파일로 이사하기 때문에, 원본 파일만 봐서는 “처리됨” 이 “없음” 으로 읽힌 것이다. 진짜 계기는 커밋 기록이었고, 그 뒤로는 매 묶음을 커밋 개수로 검산했다. 최종 유실 0건.

배운 것 — 계기가 대상이 지나간 경로를 실제로 지나는지부터 확인해야 한다. 파일에 없다는 것과 처리됐다는 것은 같은 모양으로 보인다.

4. 마지막 묶음에서 손이 멈췄다

23:14, 마지막 묶음의 답이 도착했다 — 그런데 사람이 버튼을 누른 게 아니라 대기 시간이 지나 자동 발사된 답이었다. 앞선 23개 묶음은 전부 사람 확인 도장이 찍혀 있었다. 이번 정리의 전제가 “하나씩 사람이 확인” 인데 마지막 한 개를 기계 답으로 닫을 수는 없어서, 집행을 보류하고 다시 물었다. 7분 뒤 진짜 버튼이 눌렸고, 그때 집행했다.

배운 것 — 자동 발사된 “그래” 는 승인이 아니다. 되돌릴 수 있는 일이라도, 사람 몫으로 설계한 결정은 사람이 닫아야 한다.

5. 그래서 뭐가 남았나

축	결과
정리	401 → 84건 (보관 317 · 완료 처리 2 — 전부 복원 가능)
남긴 결	돈에 닿는 것 · 실사고 재발방지 · 지금 도는 축, 세 갈래
접은 것	새 앱 확장 라인 전체(로또·운세·가계부·단어요) — “파는 쪽 집중” 확정
곁가지	공개 3사이트 다크톤 PR 3건 머지 보고가 리뷰 도중 착지 (막힘 0)

들어간 것은 저녁 3시간 40분과 API 사용료뿐. 일주일 뒤(8/13)에 발급 게이트 도입 이후 새로 생긴 티켓만 다시 판정하는 예약이 걸려 있다.

---

다음 이야기는 84개만 남은 목록으로 아침을 시작하는 이야기.

— 강대종 / @ssamssae