세션 교체에도 이어지는 운영: 마스터 에이전트의 계보와 운영 하네스// 참고: 내부 제품은 본문에서 [Polsia] → 임의의 가상 B2B 프로덕트로 시각 기반 유사 상품 검색 서비스로 가상화하여 설명합니다.// 사례에 등장하는 일부 이름, 시각, 식별자는 공개 가능한 수준으로 일반화하였습니다.. 도구 이름과 구조는 그대로 유지하였습니다.// 사용자=Dorito=저 발단: 세 개의 문제이 시스템은 2026년 6월과 7월에 반복해서 부딪힌 세 종류의 실패에서 나왔다. 첫째는 컨텍스트 소진이었다. 세션 기록에 남아 있는 초기 핸드오프 문서의 첫 줄은 이랬다.너는 이 작업의 오너십을 이어받는다. context 0에서 시작하니 이 문서가 유일한 상태 소스다. 상태는 기억에 기대지 말고 git으로 실측한다. 당시..
오늘 세 번 헤맸고, 방향을 튼 건 매번 내가 아니었다 하네스 개발 후속 포스트 (2026-07-20 초안)1편은 재발방지를 코드로 강제하는 이야기였다. 이번엔 그 코드를 짜다 헤맨 이야기, 그리고 그 헤맴을 빠져나오게 한 지적들에 관한 것이다. 오늘 오케스트레이션 하네스의 유닛을 여러 개 구현했다. 부트스트랩, 복구, 승계, 계보 기록까지 열 개를 메인에 통합했고 통합 테스트도 통과했다. 성과만 놓고 보면 매끄러운 하루처럼 보인다.그런데 정작 기억에 남는 건 잘 된 부분이 아니라 세 번 헤맨 부분이다. 그리고 그 세 번을 빠져나오게 한 건 내 판단이 아니라, 그때마다 들어온 사용자의 지적이었다. 이 글은 그 기록이다. 에이전트가 얼마나 똑똑하게 짰는지가 아니라, 사람이 어디서 방향을 틀어줬는지에 관한..
기원 인용 소스 (ctx 실측 — 블로그 서두용) - 원문 그대로 넣음전부 실제 세션 기록에서 발굴한 1차 증거다. 날짜는 정확하고, 인용은 원문 그대로다. 블로그에서는 화자를 "나"(저자)와 "에이전트"로 표기한다.세 겹의 원인 (시간순)원인 1 — 컨텍스트 소진으로 운영이 끊기는 만성 고통2026-06 내내: "세션 종료할게 컨텍스트 너무 찼다" 류 발화가 반복됨 (만성 고질병)2026-07-13, 저자 발화: "야 너 컨텍스트 너무 찼다. ... 그 세션한테 핸드오프하고 컨텍스트 0부터 다시 드가자." → 컨텍스트 소진 → 새 세션 → 핸드오프 원형이 여기서 굳어짐2026-07-14, 첫 정식 은퇴 인계: "나(이전 오후 세션)는 컨텍스트가 가득 차 여기서 은퇴한다. 인계 상태 요약은 ... han..
// TODO: 가독성 개선 + 직역어투 제거 + humanize 진행할 예정 + em—dash 제거할 거임 (2026-06-24 기준) 들어가며시즌 1 "AI 메모리 시스템 적용기"에서는 살짝 얼기설기 아쉬운 점이 많았죠? 그래도 동작은 잘 되더군요. 자, 시스템을 완성했다면, 이제부터는 그 설계가 어떻게 제가 개선해나갔는지를 정리해볼 예정입니다. 저는 이 구조를 실제 프로젝트에 3개월간 운영했습니다. 먼저 이 글을 읽고 구조를 이해한 후, 회고 시리즈에서 "왜 이게 필요했나"를 보시면 더 명확합니다. (- 이 구조가 정말 작동했는지 - 어떤 부분을 더 개선했는지 - 도구를 바꾸면서 뭘 조심했는지 등등..)정말 솔직하게 말하자면, 시즌 1 "AI 메모리 시스템 적용기" 는 글을 작성하면서 시스템을 만들..
요즘 사실 블로그 시리즈 글 올린 이후로 더 좋게 시스템을 빌드업했고, 협업 플로우까지 더 개선했다.그렇게 LLM wiki, memory system, harness 같은 거 계속 깎고 있었는데 어느 순간 “아 결국 다 SSOT 만들려고 하는 거구나” 하는 느낌이 확 왔다.SSOT... 심오하다. 흠.. 그러다가 GPT랑 이것저것 고찰하다가,LLM 말고도 인간/조직/레거시/정체성까지 전부 eventual consistency처럼 보이기 시작해서 재밌었다. 계층만이 다를 뿐이다.그냥 내가 다시 보려고 올려둠2023:“와 AI가 코드 짜주네”2024:“와 context engineering 중요하네”2025:“어? 에이전트나 인간 조직이나 distributed system 같은데?”2026:“잠깐만 인간 i..
위키가 git 으로 관리된다면, 팀끼리 작업하다가 충돌이라던가 병합이라던가 등등.. 위키 자체는 어떻게 관리해야할까?뜬금없이 갑자기 생각난 웃긴 밈: 토르발즈 아저씨가 바이브코딩을 했다고??https://github.com/torvalds/AudioNoise/issues?q=label%3AGarbage리누스 토르발즈: 응 ~ 원래도 휴-먼한테 시키던거였어 ㅋㅋ(대충 웃긴 짤 주저리 끝)AI 에이전트 메모리, 파일 더미로는 왜 무너지는가프롤로그에서 인용했던 글을 다시 읽어보겠습니다.지금 많은 AI 에이전트 메모리는 사실 메모리가 아니라, 긴 프롬프트를 RAM 처럼 쓰는 것에 가깝다. 모든 히스토리와 결정 로그를 마크다운에 몰아넣고 장기 메모리라고 부르면 2주 안에 무너진다. 같은 사실의 버전이 여러 개 생..
위키 관리도 자동화하고 사람의 실수를 막자! karpathy llm wiki 위에 얹은 자동화 시스템 (2편)요약: 1편에서는 「문서 더미는 그 자체로 기억이 아니다」 와 「프롬프트만으로는 풀리지 않는 자리」 까지 짚었습니다.2편은 그다음 단계의 기록입니다. 같은 폴더를 어떻게 정리했더니 에이전트가 더 이상 두 버전을 같은 무게로 읽지 않게 됐는지에 대해서입니다. 제가 작업 중인 플젝 기준으로 시스템을 적용했는데요, 실제로 어떻게 워크플로우가 돌아갔는지에 대해서도 실제 예시를 통해 더 상세히 서술해보겠습니다.시리즈 3/4 · 본편 2편4편 시리즈, 지금은 어디프롤로그메모리 아키텍처 업그레이드는 왜 이제 선택이 아닌가시리즈 문제의식, 4편 안내본편 1편프롬프트만으로는 안 되는 순간, 문서 메모리는 왜 무너..
프롬프트만으로는 안 되는 순간, 문서 메모리는 왜 무너지는가 (1편)요약: 문서를 많이 쌓아도 AI 가 저절로 더 잘 기억하지는 않습니다. 같은 사실이 여러 버전으로 남고 오래된 맥락이 새 결정과 같은 무게로 읽히면, 답변은 더 정확해지기는커녕 오히려 오락가락합니다. 이 글은 그런 혼선이 사이드 프로젝트에서 어떻게 터졌는지 (하루 만에 14개의 문서 충돌) 본인 팀 사례로 짚고, 마크다운 파일 더미와 운영되는 메모리 시스템이 왜 다른지 정리합니다.시리즈 2/4 · 본편 1편4편 시리즈, 지금은 어디이 시리즈는 프롤로그와 본편 3편, 총 4편으로 묶입니다. 독자는 Claude Code, Cursor, Codex CLI 같은 에이전트형 개발 도구를 이미 조금 써 본 개발자로 잡았습니다."프롬프트를 잘 쓰면 ..
메모리 아키텍처 업그레이드는 왜 이제 선택이 아닌가시리즈 1/4 · 프롤로그요약: 문서를 많이 쌓아도 에이전트가 저절로 기억을 얻지는 않습니다. 이 글은 마크다운 기록 더미와 메모리 구조가 왜 다른지 설명하는 4편 시리즈의 프롤로그입니다.문제 의식 ..요즘 AI 생태계는 하루가 멀다 하고 새로운 소식이 쏟아집니다. skill, agent, MCP, 각종 프레임워크가 쉴 새 없이 등장하고, 지금 좋은 게 뭐냐는 이야기도 계속 달라집니다.하지만 정작 한 가지는 쉽게 보이지 않습니다. 이 다양한 도구들을 프로젝트에 차곡차곡 얹어 가다 보면, 에이전트는 과연 무엇을 기억하고 무엇을 잊어야 할까요?저는 처음엔 이게 단순한 문제라고 여겼습니다. 중요한 내용은 Markdown에 잘 정리해서 남겨 두면 충분하다고 생각..
벌써 4년 전이다. 내가 갓 스타트업을 차린 지 얼마 안 돼서 판교에 내려가 일할 때다. 서울 왔다 가는 길에, 강남역 근처 공유 오피스에서 열리는 AI 밋업에 들른 적이 있다. 강남역 사거리 뒷골목, 낡은 건물 반지하에 조그만 사무실을 열어 놓고 하네스를 깎아 파는 노인이 있었다. 이력서에는 아무런 직함도 없고, 깃허브에는 잔디 하나 없으며, 링크드인 프로필조차 없는 사람이었다. 다만 "하네스 엔지니어링"이란 간판 하나만 벽에 붙어 있었다.Claude Code를 쓰기 시작한 지 두 달쯤 되었을 때였다. 모델은 분명 Opus급인데 결과물은 영 시원찮았다. CLAUDE.md도 대충 써 봤고 프롬프트도 이리저리 고쳐 봤지만, AI는 매번 엉뚱한 파일을 고치고, 테스트는 통과 못 하고, 코드는 점점 스파게티가..
