5월 첫째 주 회고

2026년 5월 3일 | 끄적끄적

---

공개 URL 서른두 개를 한 줄짜리 표로 접어 보니, 이번 주의 밑줄은 무엇을 더 넣을까보다 어디서 멈추고 무엇을 남길까에 더 가까웠다. 트렌드 글은 제품과 인프라의 바깥 움직임을 계속 훑었고, 논문 리뷰는 에이전트의 기억·탐색·협업을 파고들었고, 프로젝트 글은 GraphRAG와 GNN의 실패 범위를 더 작게 잘랐다. 겉으로는 꽤 바쁜 주였는데, 다시 읽어 보니 이상하게도 전부 같은 질문 쪽으로 모였다.

집계는 내 발행 기록을 먼저 세고 Tistory RSS를 다시 대조했다. RSS에는 최신 10편만 노출되어 post 233부터 post 242까지는 피드에서 바로 확인됐고, 그 앞의 22편은 공개 URL과 로컬 메타를 같이 보며 다시 맞췄다. 그래서 이번 회고의 대상은 2026년 4월 27일부터 5월 3일까지 공개된 32편이다. 숫자만 보면 많은데, 실제로 남은 느낌은 양보다 판단을 줄이는 장치 쪽이었다.

1. 카테고리별로 접어 본 일곱 날짜

• [AI 최신 트렌드] 5편 — 4월 27일, 4월 29일, 4월 30일, 5월 1일, 5월 3일. Codex 자동화, 커넥터, 결제, 클라우드 병목, 커머스 에이전트까지 이어지며 AI가 모델 성능표보다 운영 표면과 비용 구조에서 더 선명하게 보인 주였다.
• [논문 리뷰]/[최신 논문] 5편 — HyLo, RecursiveMAS, RL 롤아웃 가속, 탐색 해킹, Learning When to Remember. 긴 문맥, 잠재 협업, speculative rollout, RL 안전, memory abstention이 모두 에이전트가 오래 돌 때 무엇을 통제해야 하는가로 묶였다.
• [바이브코딩 Tips] 5편 — Lovable handoff bundle, 도구 계약서, 세션 스냅샷, 종료 체크, 스킬 설명. 코딩 에이전트를 믿고 맡기려면 프롬프트보다 먼저 넘겨줄 단위, 허용 범위, 종료 증거를 작게 고정해야 한다는 쪽으로 계속 갔다.
• [개발 깨알 상식_Tips] 1편 — ClawSweeper review/apply 분리. 자동으로 닫는 것보다 먼저 제안과 적용을 갈라 두는 설계가, 작은 봇에서도 권한 경계를 얼마나 크게 바꾸는지 보여줬다.
• [개발 공부] 3편 — MLA KV Cache, Negative Sampling, MRR과 nDCG. 정의를 외우는 글이라기보다, cache 병목·없는 간선·첫 정답 위치처럼 평가와 해석이 갈라지는 지점을 다시 표시한 공부였다.
• [GNN 프로젝트/개발 일기] 3편 — failure-case report, edge별 실패 분석, threshold sweep. 평균 AUC보다 hardest seed, edge probability, FP/FN 균형을 따로 보며 실패를 더 작게 쪼갠 주였다.
• [GraphRAG 프로젝트/개발 일기] 7편 — mismatch report, 이유별 섹션, scope growth queue, namespace 분리, status streak, stale status queue, stale transition split. 좋은 결과를 더 자랑하기보다 같은 실패가 얼마나 오래, 어떤 범위로, 어떤 전이 뒤에 남는지를 추적하는 장부를 두껍게 만들었다.
• [끄적끄적] 3편 — 보류해 둔 자료가 쌓일 때, 판단 보류 칸, 월간 운영 회고. 감상보다 보류 이유, 폐기 조건, 운영 리듬처럼 나중에 다시 열 수 있는 기록을 남기는 쪽으로 이어졌다.

이렇게 놓고 보니 이번 주에는 "더 오래 기억하기"보다 "기억할 것과 내려놓을 것을 구분하기"가 더 자주 등장했다. GraphRAG의 stale queue도, GNN의 실패 edge 표도, 바이브코딩의 종료 체크도 전부 같은 손놀림을 하고 있었다. 큼직한 결론을 빨리 쓰기 전에, 애매한 상태를 애매한 채로 보존하고 다시 볼 조건을 붙이는 일이다.

2. 이 주의 베스트 1편

가장 오래 남은 글은 Learning When to Remember: LLM 코딩 에이전트가 기억을 거절하는 방법이었다. 기억을 더 많이 넣으면 좋아질 것 같다는 직관을 그대로 밀지 않고, 검색된 메모리를 쓰지 않는 행동까지 policy action으로 둔 점이 이번 주 전체 흐름과 잘 맞았다. 내가 GraphRAG history를 줄이고, GNN 실패 케이스를 나누고, 스킬 설명에 호출 조건을 박은 것도 결국 비슷한 문제였다. 유용해 보이는 것을 언제 안 쓸 것인가.

이 글이 좋았던 이유는 에이전트 메모리를 낭만적으로 보지 않았기 때문이다. 기억은 능력처럼 보이지만, 잘못 들어오면 다음 행동 전체를 기울게 만든다. 그래서 기억을 주입하는 순간보다 거절하는 순간을 먼저 모델링해야 한다는 관점이 꽤 세게 남았다. 논문 리뷰였지만, 읽고 난 뒤에는 내 작업 방식 쪽으로 바로 넘어왔다. 자료 보관함도, 프로젝트 queue도, 코딩 에이전트 handoff도 결국 같은 질문을 달고 있어야 했다. 이건 지금 쓸 기억인가, 아니면 보류 칸에 둬야 할 기억인가.

3. 이 주에 내가 배운 것

이번 주에 내가 배운 건 좋은 기록은 많이 남긴 기록이 아니라, 다시 열 조건과 버릴 조건이 같이 붙은 기록이라는 점이다. 예전에는 로그가 많으면 안심이 됐다. 하지만 일주일치를 다시 묶어 보니, 실제로 다음 행동을 가볍게 만든 건 양이 아니라 분기였다. 실패가 반복된 profile만 따로 뽑고, FP와 FN을 나눠 보고, 종료 전에 증거를 세 칸으로 확인하고, 기억도 필요 없으면 거절할 수 있게 두는 것. 전부 기록을 늘리는 일이 아니라 기록의 압력을 낮추는 일이었다.

그래서 다음 주로 가져가고 싶은 문장도 간단하다. 무언가를 저장할 때는 같이 적어야 한다. 언제 다시 열지, 언제 버릴지, 무엇이 바뀌면 판단을 바꿀지. 이 세 줄이 없으면 기록은 금방 보관함이 되고, 보관함은 다시 미루기의 다른 이름이 된다. 이번 주의 32편은 그걸 꽤 집요하게 알려준 묶음이었다.