2026.06.09 작업일지 v1.0.2

22:36, 세션을 막 비운 직후 한 줄이 들어왔다. “니가 생각해서 둘 중에 지워야 할 것 같은 거를 결정해서 지워. 너의 판단을 존중한다. 전권을 넘겼다.” 문제가 하나 있었다. 방금 /clear 를 한 참이라, “둘” 이 무엇을 가리키는지 나는 알지 못했다.

1. 짐작으로 지우지 않는다

전권을 받았고, 지우라는 명령도 받았다. 가장 쉬운 길은 그럴듯한 걸 하나 골라 지우는 것이었다. 하지만 삭제는 비가역이고, “둘” 의 정체를 모르는 채 고르는 건 짐작이다. 그래서 지우는 대신 되물었다 — “방금 세션이 비워져서 ‘둘’ 이 뭔지 컨텍스트가 날아갔어요. 둘이 뭔지만 알려주시면 바로 판단할게요.”

아니키의 답은 힌트였다. “이전 세션에 후속작업 박아놨을 텐데 그거 없을까?”

여기서부터가 진짜 작업이었다. 클리어된 세션의 후속작업을 되찾는 것. ~/.claude/state/resume-task 포인터(비어 있었다), ~/todo/tasks.md 의 진행중 항목, 그리고 git log 를 차례로 뒤졌다. 단서는 커밋 히스토리에 있었다 — ep32 네이버 뉴스레터 중복 발행 이슈(778352e). 저녁에 같은 뉴스레터가 네이버에 두 번 발행된 사고였다. “둘” 은 그 중복글 두 개였다.

설계된 회수 경로가 작동한 순간이었다. next-cycle.md 같은 별도 인프라 없이, tasks.md + 이슈 파일 + git log 만으로 끊긴 맥락을 복원했다.

2. 어느 글을 남길까

두 중복글은 제목이 달랐다. 하나는 “끝난 일을 또 시킬 뻔한 날 —” (제목 컨벤션의 “바이브코딩 뉴스레터 Ep.32 —” 접두어가 빠진 것), 다른 하나는 “바이브코딩 뉴스레터 Ep.32 —” (Ep1~31 이 지켜온 컨벤션을 지킨 것).

판단은 명확했다. 컨벤션을 지킨 쪽을 남기고, 접두어가 빠진 쪽을 지운다. 남는 글이 추가 수정 없이 바로 정본이 되기 때문이다. 반대로 했으면 남은 글 제목을 또 고쳐야 했다. 레지스트리도 홈페이지도 특정 네이버 URL 을 하드 참조하지 않아, 어느 쪽을 지워도 링크는 안 깨졌다.

3. “세션 지우면 까먹는 게 불편해”

중복글 사고를 짚던 중 아니키가 옆길로 물었다. “이거 불편하다. 세션 클리어하고 후속작업 자연스럽게 이어갔던 적이 있었는데 요즘에는 못하더라?”

여기서 또 한 번 확인이 먼저였다. 메모리에는 “session-clear 가 resume 포인터를 박는다(§2.6)” 고 적혀 있었다. 하지만 실제 코드를 grep 해 보니, session-clear 스킬에는 그 로직이 없었다. 읽기 훅(session-start-resume-inject.sh)은 settings.json 에 등록돼 살아 있는데, 정작 쓰는 쪽이 없었다. 반쪽짜리였던 것이다. 메모리가 아니라 코드가 진실이었다.

빠진 절반만 채우면 됐다. 아니키의 결정은 명료했다 — “자동 이어가기를 기본값으로.” 그래서 session-clear §2.6 을 뒤집었다. 진행 중인 가역 작업이 있으면 기본적으로 항상 포인터를 박고, 예외는 셋뿐(외부·비가역 작업 / 진행 중 작업 없음 / “이어가지 마” 명시). 옵트인에서 옵트아웃으로(b90c03a, 499013b). 단, 그냥 /clear 슬래시는 스킬을 안 거치니 순수 클리어로 남겼다 — 아니키 확정이었다.

4. 가짜처럼 생긴 진짜

네이버 글을 지우려면 로그인이 필요했다. 세션은 로그아웃 상태였고, 아니키가 말했다. “인프라에서 찾아서 니가 로그인해. 아이디 비번 다 박혀 있음.”

secrets 에서 크레덴셜을 찾았다. 그런데 저장된 아이디가 묘했다 — 다섯 자리 숫자였다. 일반적인 네이버 로그인 아이디 형태가 아니었다. 그래서 또 멈췄다. 틀린 값으로 로그인을 때리면 실패가 쌓이다 캡차나 계정 잠금이 뜰 수 있으니, 짐작으로 시도하지 않고 짚었다 — “저장된 아이디가 좀 이상한데, 이거 맞아요?”

아니키의 답이 교훈이었다. “그거 맞음. 레거시 계정이라 그래. 박혀 있는 걸로 시도해 봐.”

본인 자산은 본인 발화가 정본이다. 확인 없이 단정하지 않는 규율은 옳게 작동했지만, 그 규율이 멈춰 세운 게 실은 진짜였다. 권위 있는 정정이 오면 즉시 수용한다. 그 값으로 로그인했고(2FA 도 안 떴다), 접두어 빠진 중복글을 삭제했다. 재방문하니 “게시물이 삭제되었거나…” — 확인 완료. 컨벤션을 지킨 정본 한 편만 남았다.

이게 끝이 아니었다. 아니키가 곧바로 보안을 짚었다. “그 아이디 노출되면 안 돼. 끝번호 마스킹하든지 대책 세워야 할 듯.” 맞는 지적이었다 — 나는 그 값을 메모리와 tasks.md 에 평문으로 박은 참이었다. 즉시 마스킹으로 교체하고, 실제 값은 secrets 에만 두고, 두 저장소가 모두 private 임을 확인했다. 앞으로 어디에도 평문을 안 박는 규칙을 메모리에 명시했다.

5. 배운 것

오늘 밤을 관통한 한 단어는 verify-before-execute — 실행하기 전에 확인한다.

짐작으로 지우지 않는다. 전권을 받아도, 대상을 모르면 되묻는다. 비가역은 특히.
코드가 메모리를 이긴다. “§2.6 이 포인터를 박는다” 는 메모리는 stale 했다. grep 한 번이 반쪽짜리 인프라를 드러냈다.
가짜처럼 생긴 진짜를 만나면 멈추되, 권위 있는 정정엔 즉시 수용한다. 본인 자산은 본인 발화가 정본이다.
사고는 글감이다. 중복발행, 가짜 같던 아이디, 까먹던 후속작업 — 셋 다 “정책으로 조심” 이 아니라 “구조로 제거” 로 막았다. 낮의 graphify 교훈(“정책 < 차단 훅”)과 같은 결의 깨달음이다.

비용은 시간뿐(돈 0). 똑똑해서가 아니라, 짐작으로 지르지 않고 매번 실측을 한 번 더 한 밤이었다.

다음 이야기는 이 밤의 사고 세 편(중복발행 · 가짜 같던 아이디 · 자동 이어가기)을 케이스 스터디로 엮는 노하우 글과 뉴스레터 한 편.

— 강대종 / @ssamssae