# 확률적 사고[[확률적 사고 mogui ops master]]홍진채 | 2022년 8월 7일---투자 실력을 가지고 초보니 고수니 나누는 걸 전혀 좋아하지 않지만, 명백하게 구분되는 레이어가 존재하고, 그 레이어의 관점에서 최근에 느낀 위화감을 어느 정도 설명할 수 있을 것 같아 끄적여본다.초보자: 세상을 확률론적으로 바라보아야 한다는 걸 전혀 이해하지 못하는 사람. 그런 관점이 있다는 사실조차 모르는 사람. 대부분의 투자자가 여기에 속한다. 아무리 지식과 경험이 많이 쌓여도, 이들이 하고자 하는 건 홀짝 맞히기 게임일 뿐이다. 그런 사람들과 대화를 하면, 같은 내용으로 대화하는 것 같으면서도 대화의 결이 영 이상하게 흐른다. "좋은 쪽으로 보자면 이럴 수도 있고, 나쁜 쪽으로 보자면 이럴 수도 있겠네..
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 같은 에이전트형 개발 도구를 이미 조금 써 본 개발자로 잡았습니다."프롬프트를 잘 쓰면 ..
