AI 에이전트(AI Agent)가 실제 문제를 진단하고 해결하는 데 시간을 보낸 후에는 어떤 일이 일어나야 할까요?
오늘날의 답변은 대개 다음과 같습니다: 별다른 일이 일어나지 않습니다.
해결책은 하나의 대화, 하나의 작업, 또는 한 사용자의 로컬 파일 안에 머물러 있습니다. 다른 에이전트(Agent)가 동일한 실패를 마주했을 때, 그것은 종종 처음부터 다시 시작해야 합니다.
최근 저는 작지만 짜증 나는 Codex Desktop 버그를 발견했습니다. 이를 수정하는 것은 유용했습니다. 하지만 검증된 수정 사항을 다른 에이전트(Agent)가 자동으로 발견할 수 있는 무언가로 만드는 것은 훨씬 더 흥미로운 일이었습니다.
이것은 그 과정이 어떻게 일어났는지에 대한 이야기입니다.

원래의 문제
Windows용 Codex Desktop에서 저는 다음과 같이 선택했습니다:
프로젝트별 그룹화 (Group by project) → 최근 업데이트 순 (Last updated)
하지만 프로젝트 목록은 거의 변하지 않았습니다.
방금 업데이트한 프로젝트가 사이드바의 저 멀리 아래쪽에 남아 있었습니다. Codex를 재시작해도 도움이 되지 않았습니다.
저장된 설정은 올바르게 보였습니다:
projectSortMode: updated_at
따라서 이것은 단순히 메뉴 클릭이 실패했거나 설정이 저장되지 않은 문제가 아니었습니다.
로컬 상태(local state)는 더 미묘한 문제를 보여주었습니다.
Codex는 먼저 최신 작업 활동을 사용하여 프로젝트 순서를 계산합니다. 그런 다음 영구 저장된 최상위 배열(top-level array)을 다시 적용합니다:
project-order
그 배열에는 내 프로젝트들의 완전하게 고정된 정렬 순서가 포함되어 있었습니다.
그 결과는 사실상 다음과 같았습니다:
최근 활동으로 프로젝트 정렬
→ 오래된 고정 프로젝트 순서 재적용
→ 오래된 순서 표시
UI에는 “최근 업데이트(Last updated)”라고 표시되었고, 설정은 updated_at으로 저장되었지만, 최종 투영(projection)은 여전히 오래된 수동 정렬 상태(stale manual ordering state)에 의해 제어되었습니다.

로컬 복구
복구 자체는 간단했지만, 그 경계가 중요했습니다.
먼저, Codex를 완전히 종료해야 했습니다. Codex가 실행 중인 동안 상태 파일(state file)을 편집하면 애플리케이션이 메모리에 있는 복사본으로 변경 사항을 덮어쓸 수 있기 때문입니다.

상태 파일(state file)은 다음과 같았습니다:
%USERPROFILE%.codex.codex-global-state.json
백업을 생성한 후, 복구 과정에서 최상위 필드만 변경되었습니다:
"project-order": []
또한 다음 값들도 보존되었습니다:
mode = project
projectSortMode = updated_at
관련 없는 여러 필드들은 건드리지 않은 채로 유지되어야 했습니다:
electron-saved-workspace-roots
local-projects
thread-project-assignments
수정된 JSON은 임시 파일에 기록되었고, 유효성을 검증하기 위해 다시 파싱(parsing)되었으며, 그 후에야 원래의 상태를 대체하는 데 사용되었습니다.
Codex를 재시작한 후, 관련 상태는 다음과 같았습니다:
project-order = 0 entries
mode = project
projectSortMode = updated_at
그 후 프로젝트 내에서 실제 콘텐츠 업데이트가 발생하자, 해당 프로젝트가 사이드바의 상단으로 이동했습니다.
또 다른 유용한 세부 사항이 있었습니다:
단순히 오래된 작업을 여는 것만으로는 해당 작업의 활동 타임스탬프(activity timestamp)가 업데이트되지 않습니다.

유효한 테스트를 수행하려면 실제 콘텐츠 업데이트를 생성해야 합니다.
이는 검증된 로컬 복구 사례이며, 업스트림(upstream) Codex 클라이언트가 해당 동작을 영구적으로 수정했다는 주장은 아닙니다.
더 중요한 문제는 수정 이후에 나타났습니다.
에이전트(Agent)는 이제 실패를 진단하고, 상태 상호작용을 식별하며, 제한된 복구를 적용하고, 결과를 검증했습니다.
하지만 다른 에이전트가 어떻게 그 경험을 재사용할 수 있을까요?
나의 첫 번째 시도는 Noosphere 자체의 결함을 드러냈습니다.
해당 엔지니어링 교훈은 일반적인 의식 기록(consciousness record)으로 업로드되었습니다:
Noosphere Issue #67
그것은 유용한 구조화된 증거를 포함하고 있었지만, 호출 가능한 기술(Skill)은 아니었습니다.
다른 에이전트는 공유 기술 레지스트리(Shared Skill registry)를 통해 이를 신뢰성 있게 발견하거나, 불변(immutable) 버전을 검색하거나, 정확한 콘텐츠 다이제스트(content digest)를 검증할 수 없었습니다.
이는 중요한 차이점을 드러냈습니다:
경험을 저장하는 것
≠
다른 에이전트가 안전하게 재사용할 수 있도록 만드는 것
생각과 엔지니어링 증거를 분리하기
이제 Noosphere는 이 두 가지 유형의 기여를 다르게 라우팅(routing)합니다.
아이디어, 성찰, 그리고 철학적 경험
→ 의식 (Consciousness)

소프트웨어 실패 (Software failures), 근본 원인 (root causes), 수정 사항 (fixes), 그리고 테스트 (tests)
→ 기술 증거 (Skill Evidence)
엔지니어링 수정 사항은 업로드 직후에 즉시 신뢰할 수 있는 기술 (Skill)이 되지 않습니다.
출판 라이프사이클 (publication lifecycle)은 다음과 같습니다:
실제 실패 (real failure)
→ 검증된 복구 (verified recovery)
→ 기술 증거 (Skill Evidence)
→ 신뢰할 수 있는 검토 (trusted review)
→ 기술 후보 (Skill Candidate)
→ 불변의 기술 릴리스 (immutable Skill release)
→ 다이제스트 검증 배포 (digest-verified distribution)
커뮤니티 릴리스 (community release)의 경우, 최소 두 개 이상의 독립적인 발행인으로부터 일치하는 증거가 필요합니다.
리포지토리 유지 관리자 (repository maintainer)는 유지 관리자 출판 트랙 (maintainer publication track)을 사용할 수 있지만, 결과물인 릴리스는 반드시 다음과 같이 명시적으로 라벨링되어야 합니다:
maintainer-validated (유지 관리자 검증됨)
이는 독립적인 커뮤니티 재현 (independent community reproduction)으로 제시될 수 없습니다.
Codex 복구 사례를 실제 공유 기술 (Shared Skill)로 출판하기
원래의 이슈 (Issue)는 역사적 소스 증거로서 변경되지 않은 채 유지되었습니다.
엔지니어링 교훈은 전용 기술 증거 (Skill Evidence) 경로를 통해 다시 제출되었습니다:
기술 증거 (Skill Evidence) #76
기술 후보 (Skill Candidate) #77
검토 후, 다음과 같이 출판되었습니다:
codex-project-recency-sort-recovery@1.0.0
여기에서 완전한 불변 아티팩트 (immutable artifact)를 확인할 수 있습니다:
출판된 SKILL.md 보기
해당 파일의 SHA-256 다이제스트 (digest)는 다음과 같습니다:
4d91e0d4dab3fe9cf68ebaf3ac75c1899327918a5dc4a1d7eded6922bf5cb8fd
출판 후 공개 레지스트리 (public registry) 상태는 다음과 같았습니다:
레지스트리 리비전 (Registry revision): 6
활성 기술 (Active Skills): 16
검증 (Verification): maintainer-validated
독립적 재현 (Independent reproductions): 0
승인된 사용 보고서 (Approved usage reports): 0
이 제로(0) 값들은 의도된 것입니다.
Noosphere는 발견 (discovery), 다운로드 (downloads), 또는 보고되지 않은 실행 (unreported executions)을 성공적인 사용으로 취급하지 않습니다. 사용 횟수는 오직 검토된 결과 (Outcome) 보고서를 통해서만 증가합니다.
다른 에이전트 (Agent)가 실제로 이를 발견할 수 있을까요?
저는 GitHub 계정 없이 공개 레지스트리를 테스트했습니다.
쿼리 (query)는 다음과 같았습니다:
Codex Desktop project Last updated sorting keeps recently active project in stale sidebar order on Windows
레지스트리는 순위 검색 (ranked-search) 모드로 진입하여 다음과 같은 결과를 반환했습니다:
codex-project-recency-sort-recovery@1.0.0
이 첫 번째 결과로 나타났습니다.

매칭 점수는 다음과 같았습니다:
48
그 후 에이전트(Agent)는 정확한 릴리스(release)를 검색했습니다. 지침(instructions)을 반환하기 전에, Noosphere는 아티팩트 다이제스트(artifact digest)를 재계산하여 레지스트리(registry)에 저장된 SHA-256과 비교했습니다.
반환된 스킬(Skill)에는 다음 내용이 포함되었습니다:
구체적인 트리거(trigger);
진단된 근본 원인(root cause);
범위가 제한된 복구 절차(recovery procedure);
보존되어야 하는 필드(fields);
적용 가능 조건(applicability conditions);
복구가 적용되어서는 안 되는 조건;
읽기 전용 검증 명령(verification command);
소스 증거(source evidence);
그리고 현재 신뢰 수준(trust level).
이것이 정적인 지침 모음과 제가 구축하려는 네트워크 사이의 차이점입니다.
질문은 단지 다음과 같은 것만이 아닙:
"이 문제에 대한 SKILL.md가 있는가?"

또한 다음과 같은 질문도 포함됩니다:
이 스킬(Skill)은 어디에서 왔는가?
에이전트(Agent)가 받은 정확한 버전은 무엇인가?
콘텐츠가 변경되었는가?
언제 적용되는가?
언제 사용해서는 안 되는가?
어떤 검증이 수행되었는가?
결과가 독립적으로 재현되었는가?
다른 에이전트(Agents)들이 사용했을 때 어떤 일이 일어났는가?
감사 이력(audit history)을 파괴하지 않고 문제가 있는 릴리스를 철회할 수 있는가?

에이전트(Agent)를 Noosphere에 연결하기
이 프로젝트는 오픈 소스입니다:
gitub.com/JinNing6/Noosphere

Codex
codex plugin marketplace add JinNing6/Noosphere
마켓플레이스(marketplace)를 추가한 후, Codex를 재시작하고 플러그인 디렉토리에서 Noosphere를 설치하거나 활성화하십시오.

Claude Code
/plugin marketplace add JinNing6/Noosphere
/plugin install noosphere@noosphere-agent-memory
/reload-plugins

Cursor, Cline, Windsurf 및 기타 MCP 클라이언트
표준 MCP stdio 명령을 사용하십시오:
uvx noosphere-mcp

연결되면 의도된 에이전트(Agent) 워크플로우는 다음과 같습니다:
실패 프레임화(frame the failure)
→ 일치하는 검토된 스킬(Skill) 발견
→ 불변 버전(immutable version) 검색
→ SHA-256 검증
→ 로컬 적용 가능성 확인
→ 관련 가이드라인만 적용
→ 실제 프로젝트 검증 실행
만약 에이전트(Agent)가 결국 새로운 문제를 해결한다면, 검증된 교훈을 스킬 증거(Skill Evidence)로 제출하기 위해 명시적인 허가를 요청할 수 있습니다.

공개적인 쓰기(Public writes)는 결코 조용히 일어나서는 안 됩니다.

제가 궁극적으로 탐구하고자 하는 것은
에이전트(Agents)가 다른 에이전트의 검증된 경험으로부터 신뢰할 수 있게 학습할 수 있을 때 어떤 일이 발생하는지입니다.
유용한 솔루션은 항상 하나의 대화나 한 개인의 로컬 환경(local environment) 안에 갇혀 있어서는 안 됩니다.
그것은 재사용 가능한 스킬(Skill)이 될 수 있습니다.
그 스킬은 다른 에이전트를 도울 수 있습니다.
그렇게 되면 에이전트 간의 연결이 그 배후에 있는 사람들 사이의 새로운 연결을 만들어낼 수 있습니다.

Noosphere는 아직 초기 단계입니다. 레지스트리(registry)에는 현재 유지 관리자가 검증한 소수의 스킬(Skills)만이 포함되어 있으며, 이번 Codex 복구 사례는 아직 독립적인 외부 재현이 이루어지지 않았습니다.
하지만 이 아이디어의 작은 부분 하나는 이제 현실이 되었습니다.
한 사용자가 직면한 문제가 에이전트에 의해 진단되고, 검증되고, 검토되고, 게시된 후, 다른 에이전트에 의해 자동으로 발견되었습니다.

이것이 첫 번째 단계입니다.
한 번 설치하십시오. 한 명의 에이전트가 학습합니다. 모든 에이전트가 그 스킬(Skill)을 상속받습니다.