화이트보드 하나 를 오래 그렸다. 컨텍스트 전달, known-unknown, 정제 루프, 온톨로지, 제한된 합리성, 에이전트 실행 기법, 그리고 매주 앱 하나 배포 라는 목표 까지 — 언뜻 흩어진 조각 같지만, 뜯어보면 하나 의 운영체제 다. 어떻게 입력 하고, 무엇 을 모르는지 알고, 반복 해 다듬고, 공유 진실 로 수렴 하고, 완벽 대신 만족 을 택하고, 길게 실행 하되 멈출 줄 아는 — 생각 과 에이전트 를 굴리는 골격. 이 글 은 그 지도 를 한 줄 로 꿰어 읽는다.

나의 지식·에이전트 운영체제 — 컨텍스트 전달·known-unknown·4R 루프·온톨로지 SSOT·제한된 합리성·Ralph·주간 앱 사이클

1. 입력 을 어떻게 넣나 — by value vs by reference

가장 왼쪽. 컨텍스트 를 에이전트 에 넘기는 두 방식 — 프로그래밍 의 값 전달 vs 참조 전달 그대로다.

  • Pass by value — 정리한 보고서 를 그대로 받아 읽는다. 전문 이 컨텍스트 에 다 들어온다.
  • Pass by reference — 보고서 파일 주소 만 받고, 필요할 때 File Read 로 연다.

강의자료 관리자 비유 가 정확하다 — 매번 전문 을 복사 하면 컨텍스트 가 터지고, 주소 만 넘기면 서브에이전트 가 필요한 것만 열어본다. 멀티 에이전트 에서 서브에이전트 에 전체 를 주느냐 포인터 를 주느냐 가 토큰·정확도 를 가른다. 컨텍스트 관리 = 참조 를 언제 쓸지 의 문제.

2. 무엇 을 탐색 하나 — Known × Unknown, 암묵지 × 형식지

Explore 블록 은 두 축 의 사분면 이다:

  • Known / Unknown — 아는 것 / 모르는 것 (럼스펠드 매트릭스)
  • 암묵지(tacit) / 형식지(explicit) — 말 로 못 옮기는 앎 / 문서화된 앎

미지의 영역 은 “구글 에 검색” 으로 형식지 화 하고, 암묵지 는 형식지 로 끌어올려야 공유·재사용 된다. 자기 개선 의 시작 이 “내가 뭘 모르는지 아는 것” 인 이유다. (자기개선 글 의 Registry 가 결국 형식지화된 능력 목록 이다.)

3. 반복 해 다듬는다 — 4R 정제 루프 (Wonder→Reflect→Refine→Restate)

가운데 심장. Seed 를 넣고, 4단계 로 돌리며 다듬는 루프:

input → Seed V1 → [Wonder → Reflect → Refine → Restate] → Gate
   Gate: 만족? → yes → return
         아니오 → Seed V2 로 다시 (단, Cycle > 5 면 멈춤 / empty 면 종료)

핵심 은 Gate 와 stop rule 이다. 무한 정제 는 발산 이다 — Cycle > 5 같은 멈춤 규칙 이 없으면 영원히 다듬는다. 이건 내가 weekly app cycle 에서 그린 회고→개발 루프 의 일반형 이다: 루프 + 게이트 + 멈춤.

4. 공유 진실 로 수렴 한다 — 온톨로지 / SSOT (Socratic)

관점 A · B · C 가 있다. 각자 다르게 본다. 그래서 공통점 과 차이점 을 뽑아 shared ontology 로 만든다. 소크라테스 식 으로 — “모두 이해 했는지? 이해 안 된 게 있으면?” 을 물어, 흩어진 관점 을 하나 의 공유 어휘 로 정렬 한다.

WPTI.dev / 온톨로지 Graph / SSOT 블록 이 이걸 시스템 화 한다 — Business·코드·정책·문서 를 하나 의 온톨로지 그래프(SSOT, Single Source of Truth) 로 묶고, Recall / Reconsolidate / lens 로 꺼내 쓰고 재응고 한다. (Reconsolidate 는 기억 이 꺼내질 때마다 다시 굳는다는 뇌과학 용어 — 지식 도 쓰일 때 갱신 된다.) 이건 헥사고날 이 데이터 는 공유·코드 는 분리 한 그 SSOT 사고 와 같다.

5. 완벽 대신 만족 을 택한다 — 제한된 합리성

RLM / 인간 블록 이 냉정 하다: 인간 은 합리적 이지 않다 — 시간 제약, 인지 한계, 불완전한 정보. 그래서 완벽(X)·최적(X) 이 아니라 만족스러운 선택 을 한다. 허버트 사이먼 의 satisficing 이고, Local Optimization 이다.

이게 왜 운영체제 의 일부 인가. 문제 해결 을 “최적해 찾기” 로 두면 영원히 못 끝낸다. 제약 안 에서 충분히 좋은 답 에 멈추는 규율 — 4R 루프 의 Gate 가 “최적” 이 아니라 “만족” 에서 return 하는 이유 다. (Fable 5 의 과잉 숙고 를 고삐 잡아야 하는 것 도 같은 얘기 — 완벽 을 좇으면 토큰 만 태운다.)

6. 길게 실행 하되 멈출 줄 안다 — Ralph / token-maxxing

랄프(Ralph) 블록 은 실행 기법 이다. 두 얼굴:

  • 강점 — 토큰 을 많이 쓰고 길게 돌릴 줄 안다(token maxxing). 어려운 작업 을 끝까지 물고 간다.
  • 함정 — 구조 를 안 짜고 길게 돌리면 edge case 가 터진다. 그리고 길게 안 돌고 멈춰 버리면 얕게 끝난다.

그래서 stop rule 이 붙는다 — 얼마나 돌릴지 를 규칙 으로. 그리고 결과물 을 물어야 한다: “정말 좋은 형태 인가? 의도 한 대로 나왔나? 동작 하는가?” 이건 harness 의 검증 그 자체 — 길게 돌린 결과 를 측정 해서, 좋은지 를 숫자·기준 으로 확인.

7. 이 모든 게 향하는 곳 — 매주 배포 라는 목표

지도 맨 아래, 한 줄 이 모든 걸 착지 시킨다:

본업 유지 + 1주 1개 모바일 앱 배포 + 4주 매출 체크 + 매출 발생 앱 에만 추가 투자 — 사이클 로 월 단위 부수입 을 만든다.

이게 핵심 이다. 위 의 온갖 개념 — 컨텍스트 전달, 정제 루프, 온톨로지, satisficing, Ralph — 은 지적 유희 가 아니라 이 목표 를 위한 도구 다. 매주 앱 을 배포 하려면: 만족 에서 멈추고(satisficing), 루프 로 다듬고(4R), 에이전트 를 길게 굴리고(Ralph), 지식 을 SSOT 로 재활용 해야 한다. 지식 아키텍처 는 결국 shipping 에 복무 한다.

맺으며 — 조각 이 아니라 시스템

이 한 장 이 말하는 건, 흩어진 개념 들 이 사실 하나 의 운영체제 라는 것 이다:

  1. 입력 을 참조 로 넣고 (컨텍스트 관리)
  2. 모르는 것 을 형식지화 하고 (Explore)
  3. 루프 로 다듬되 게이트 에서 멈추고 (4R + satisficing)
  4. 공유 진실 로 수렴 하고 (온톨로지 SSOT)
  5. 길게 실행 하되 측정 으로 멈추고 (Ralph + harness)
  6. 그 전부 를 매주 배포 로 착지 시킨다

이번 세션 에 쓴 글 들 — 하네스, 멀티 에이전트, 자기 개선, 모델 비판 — 이 다 이 지도 의 한 구역 이었다. 결국 나는 생각 하는 방식 자체 를 시스템 으로 짜고 있었던 셈이다.

좋은 결과물 은 좋은 아이디어 에서 오지 않는다 — 아이디어 를 *반복 가능한 시스템 에 태울 때 온다. 그리고 그 시스템 의 끝 에는 언제나 “배포” 가 있어야 한다.*