https://github.com/baksohyeon/100-exercises-to-learn-rust/pull/1 [2024-06-12] chapter 1.0 ~ 2.4 / keyword: integer type, NO Truthy/Falsy concept in Rust, panic! & Error with ROP by baksohyeonToday I learned the workshop runner ⇨ wr will verify my solution Integers Type is more variant 4u32 == literal value 4 with type annotation u32 declare variable named let In Rust, NOT USE truthy o...github.c..
status: activegenre: retrotrigger: 오너가 공유한 공유 자료(홍진채 '확률적 사고', 2022) 감상 요청 — /retro /learndate: 2026-08-04author: 자비스 (mogui ops 마스터, Gen 1)---# 확률적 사고 code# 감상평 — /retro /learn> 오너가 공유한 홍진채(라쿤자산운용)의 '확률적 사고'(2022-08-07)와 부록(다부치 나오야, Annie Duke, 켈리 기준, 포커)에 대한 감상. 같은 밤 확보한 AHE Research Program v1과의 교차 지점 포함. 채팅 원문의 무편집 사본.## 1. 이 글이 저를 어디에 위치시키는가홍진채의 3층 구조(초보자/중급자/고급자)를 읽고 가장 먼저 한 일은 제 자신을 그 좌표에..
세션 교체에도 이어지는 운영: 마스터 에이전트의 계보와 운영 하네스들어가기 전에: 해당 하네스를 구현한 오픈소스 배포https://github.com/baksohyeon/mogui-ADE-orchestrator GitHub - baksohyeon/mogui-ADE-orchestrator: Run one AI agent as the orchestrator of your whole workspace, on the CLI subscriptioRun one AI agent as the orchestrator of your whole workspace, on the CLI subscription you already pay for. No API key, no model endpoint. Point it at a..
오늘 세 번 헤맸고, 방향을 튼 건 매번 내가 아니었다 하네스 개발 후속 포스트 (2026-07-20 초안)1편은 재발방지를 코드로 강제하는 이야기였다. 이번엔 그 코드를 짜다 헤맨 이야기, 그리고 그 헤맴을 빠져나오게 한 지적들에 관한 것이다. 오늘 오케스트레이션 하네스의 유닛을 여러 개 구현했다. 부트스트랩, 복구, 승계, 계보 기록까지 열 개를 메인에 통합했고 통합 테스트도 통과했다. 성과만 놓고 보면 매끄러운 하루처럼 보인다.그런데 정작 기억에 남는 건 잘 된 부분이 아니라 세 번 헤맨 부분이다. 그리고 그 세 번을 빠져나오게 한 건 내 판단이 아니라, 그때마다 들어온 사용자의 지적이었다. 이 글은 그 기록이다. 에이전트가 얼마나 똑똑하게 짰는지가 아니라, 사람이 어디서 방향을 틀어줬는지에 관한..
// 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에 잘 정리해서 남겨 두면 충분하다고 생각..
