지난 몇 주간의 빌드 과정에서 발견한 가장 놀라운 사실에 대해 말씀드리고자 합니다.

저는 멀티 에이전트 시스템 (multi-agent system)에 대한 절제 연구 (ablation studies)를 진행하고 있었습니다. Planner, Coder, Reviewer, Tester, Verifier 에이전트들이 함께 작동하는 다양한 구성을 비교하는 작업이었죠. 가설은 명확했습니다. 더 전문화된 에이전트가 많을수록 더 나은 결과를 낼 것이라는 점이었습니다. 인간 팀도 그렇게 작동하지 않나요?

하지만 제가 실제로 발견한 결과는 다음과 같습니다:

최소 구성 (Coder → Tester만 존재): 20개 중 19개 해결, 27,476 토큰 소모, $0.014
전체 파이프라인 (5개 에이전트 모두 사용): 20개 중 18개 해결, 37,118 토큰 소모, $0.009
review_first 순서: 20개 중 18개 해결, 45,591 토큰 소모, $0.009

Reviewer 에이전트는 해결률을 -1 감소시키고 토큰 사용량을 +9,642 증가시켰습니다. 상황을 더 악화시키고 있는 것입니다.

제가 실수했을지도 모른다는 생각에 서로 다른 시드 (seed)를 사용하여 이 실험을 세 번 반복했습니다. 매번 같은 결과가 나왔습니다. 그 후, 독립적인 검증을 위해 220개의 실행 궤적 (execution trajectories)을 바탕으로 Q-Learning 에이전트를 학습시켰고, 그 결과 최소 정책 (minimal policy)이 태스크 상태의 89%를 지배한다는 것을 확인했습니다.

에이전트가 많아질수록. 성능은 저하되고. 비용은 더 많이 듭니다.
진심으로 예상치 못한 결과였습니다.

이것이 어떻게 시작되었나
몇 주 전, 저는 자율 에이전트 (autonomous agents)에서 반복되는 패턴 때문에 좌절하고 있었습니다. 에이전트가 무언가에 실패하면 다시 시작하게 되는데, 정확히 똑같은 부분에서 다시 실패하는 것이었습니다. 메모리 (memory)가 없습니다. 학습 (learning)도 없습니다. 모든 세션이 차갑게 시작됩니다.

마치 하룻밤 사이에 모든 것을 잊어버리는 사람을 고용하는 것과 같았습니다. 엔지니어에게 매일 아침 똑같은 버그가 존재한다고 말해야 하는 상황을 상상해 보세요.

그래서 저는 이상한 질문을 던졌습니다. 만약 메모리가 에이전트가 아닌 환경 (environment)에 존재한다면 어떨까?

에이전트에게 메모리를 갖도록 수정하는 대신, 환경이 모든 실패 사례를 저장하고 다음번에 이를 컨텍스트 (context)로 다시 주입하는 방식입니다. 이렇게 하면 에이전트를 전혀 변경할 필요가 없습니다. 어떤 LLM이든, 어떤 RL 에이전트든, 어떤 규칙 기반 시스템 (rule-based system)이든 자동으로 메모리를 무료로 얻게 됩니다.

그것이 바로 CogniCore가 된 통찰이었습니다.

내가 구축한 것
지난 몇 주 동안 이것은 단순한 메모리 실험에서 NEXUS라고 부르는 무언가로 진화했습니다. 이는 자율형 AI 에이전트 (autonomous AI agents)를 위한 런타임 인지 계층 (runtime cognition layer)입니다.
이것이 수행하는 역할은 다음과 같습니다:
지속적인 세션 간 메모리 (Persistent cross-session memory)
모든 실패가 저장됩니다. 모든 성공도 저장됩니다. 유사한 작업이 나타나면, 에이전트는 이번 세션뿐만 아니라 이전의 모든 세션에 걸쳐 무엇이 작동했고 무엇이 작동하지 않았는지에 대한 컨텍스트 (context)를 얻습니다. 영구적으로 말이죠.

# 에이전트가 null_handling에 대해 guard_fix가 6번 실패했음을 기억함

# 대신 자동으로 재작성(rewrite)을 제안함

# 에이전트 자체에는 아무런 변경 없이

from cognicore import Memory, ReflectionEngine

mem = Memory()  
ref = ReflectionEngine(memory=mem)

# 충분한 실패가 발생한 후...

action, reason, confidence = ref.suggest_override("null_handling", "guard_fix")

# → action="rewrite", confidence=0.87

# → reason="guard_fix failed 6/6 times, rewrite succeeded 3/3"

복리 효과 (The compounding effect)
이 부분이 저를 진정으로 설레게 하는 지점입니다. NEXUS가 더 많은 작업을 처리할수록, 비용은 더 저렴해지고 속도는 더 빨라집니다:
1주 차: 수정당 비용 $0.05 (메모리 없음, 모든 것을 시도함)
4주 차: 수정당 비용 $0.02 (무엇이 작동하지 않는지 알고 있음)
8주 차: 수정당 비용 $0.01 (실패한 접근 방식을 즉시 건너뜀)
저는 이것을 측정했습니다. 이것은 실제입니다. 여러분의 코드베이스 (codebase)에 대해 6개월 치의 메모리를 가진 에이전트는 아무런 정보 없이 시작하는 에이전트와 근본적으로 다르며, 그 차이는 매일 복리로 쌓입니다.

NEXUS 멀티 에이전트 런타임 (NEXUS multi-agent runtime)
여기서부터 흥미로워집니다. NEXUS는 특화된 에이전트들을 조정합니다:
Planner (플래너) → 문제를 분해함
Coder (코더) → 패치 (patches)를 생성함
Tester (테스터) → 샌드박스 (sandbox)에서 검증함
Memory (메모리) → 각 시도 전에 과거의 실패를 확인함
그리고 저의 어블레이션 연구 (ablation research) 결과에 따르면 — Reviewer (리뷰어)는 필요 없습니다. 데이터는 명확합니다.

에이전트 면역 체계 (Agent Immune System)
프롬프트 인젝션 (prompt injection), 탈옥 (jailbreaks), 토큰 폭탄 (token bomb) 공격을 차단하는 법을 배우는 DQN 기반의 위협 탐지기입니다. 공격을 마주할 때마다 더 발전하며, 알려진 위협에 대한 "항체"를 개발합니다.

from cognicore.immune import NexusShield

agent = NexusShield(agent=your_agent)

이제 보호됩니다. 모든 상호작용으로부터 학습합니다.

리플레이(Replay) 및 타임 트래블(Time travel)
모든 에이전트의 결정은 이벤트 소싱(Event-sourced)됩니다. 어떤 작업이든 원하는 단계로 되돌릴 수 있으며, 그 시점에서 다른 전략으로 분기(Branch)할 수 있습니다. 강화학습 (RL) 내비게이터는 시간이 지남에 따라 어떤 분기가 성공으로 이어지는지 학습합니다.
bashcognicore replay --task abc123 --from-step 3
cognicore branch --task abc123 --step 3 --policy minimal

6가지 엔터프라이즈 통합
GitHub Issues 자동 트리거 (label nexus → 자동 수정 → PR), CI 실패 수정, Slack 실시간 업데이트, Linear 통합, 야간 예약 실행, 메모리 기반 PR 리뷰.
bashcognicore integrations setup

대화형 위저드(Wizard)가 GitHub, Slack, Linear를 연결합니다.

그런 다음 이슈에 'nexus' 라벨을 붙이고 스스로 수정되는 것을 지켜보기만 하면 됩니다.

벤치마크 결과
정책 비교 (20개 작업, 3개 시드, SWE 스타일):

minimal 19/20 (95%) 27,476 tokens $0.014
full_pipeline 18/20 (90%) 37,118 tokens $0.009

review_first 18/20 (90%) 45,591 tokens $0.009

RL 정책 학습:
220개의 궤적(Trajectories) → Q-Learning → 11,000번의 업데이트
학습 결과: minimal이 상태(States)의 89%에서 승리
예외: 긴 설명(long-description) 작업에서는 test_first가 승리
솔직한 주의사항: 이것들은 선별된 작업에 대한 규칙 기반(Rule-based) 에이전트이며, 실제 운영 저장소(Production repos)에서의 실제 LLM은 아닙니다. 이 아키텍처는 LLM 대체(Substitution)를 위해 설계되었습니다. 현재 그 작업을 진행 중입니다. 하지만 오케스트레이션(Orchestration)에 대한 발견은 실제이며 통계적으로 유의미합니다.

CognitiveMemory 시스템
이 부분은 기술적으로 제가 가장 자랑스럽게 생각하는 부분입니다. 이는 3계층 생물학적 메모리 모델입니다:
pythoncog = cc.CognitiveMemory()

20번의 경험 이후...

result = cog.recall(category='null_handling')

반환값:

recommended_action: 'rewrite'

confidence: 0.75

sources_used: ['episodic', 'semantic', 'procedural']

episodic: 3개의 과거 null_handling 수정 사례

semantic: 이 카테고리에 대한 정확도(accuracy)=0.75

procedural: 반복을 통해 학습된 규칙

작업 기억 (Working memory, 최근 7개 항목), 일화 기억 (Episodic memory, 특정 과거 경험), 의미 기억 (Semantic memory, 카테고리 수준의 패턴), 절차 기억 (Procedural memory, 반복을 통해 학습된 규칙). 각 계층은 추천에 기여합니다. 에이전트는 단순히 기억하는 것에 그치지 않고, 반복된 경험으로부터 규칙을 학습합니다.

이것이 무엇이 될 수 있는가
저는 이 프레임링(framing)에 대해 계속 생각하고 있습니다: 모든 인프라 기업은 모두가 겪고 있지만 아무도 적절한 도구를 만들지 않은 문제를 해결하는 것부터 시작합니다.
AWS는 "서버가 필요하지만 직접 관리하고 싶지는 않다"는 문제를 해결했습니다.
Docker는 "내 컴퓨터에서는 잘 작동한다"는 문제를 해결했습니다.
Kubernetes는 "컨테이너를 오케스트레이션(orchestration)해야 한다"는 문제를 해결했습니다.
현재 자율 에이전트(autonomous agent) 분야는 Docker 이전의 시기처럼 느껴집니다. 모든 팀이 메모리, 재시도 로직(retry logic), 오케스트레이션(orchestration)을 처음부터 다시 만들고 있습니다. 모든 배포는 취약합니다. 아직 아무도 "인지 인프라 (cognition infrastructure)" 계층을 점유하지 못했습니다.
그것이 바로 NEXUS가 되고자 하는 것입니다. 에이전트가 아닙니다. 래퍼(wrapper)도 아닙니다. 시간이 지남에 따라 어떤 에이전트든 더 똑똑하고, 저렴하며, 더 신뢰할 수 있게 만드는 하위 계층입니다.

솔직한 고백
저는 한 사람입니다. 이것은 알파(Alpha) 버전입니다. 버그가 있습니다. 리포지토리(repo)에 알려진 4개의 버그를 문서화했으며 최대한 빨리 수정하고 있습니다. 면역 체계(immune system)는 아직 프롬프트 인젝션(prompt injection)을 잡아내지 못합니다. SemanticMemory의 퍼지 매칭(fuzzy matching)은 제가 원하는 만큼 뛰어나지 않습니다.
하지만 핵심 아키텍처(architecture)는 작동합니다. 메모리는 복리로 쌓입니다. 절제 연구(ablation) 결과는 실제입니다. CognitiveMemory 추천 시스템은 충분한 경험을 쌓은 후 실제로 올바른 행동을 제안합니다.
첫 주에 1,700회 이상의 다운로드를 기록했습니다. r/reinforcementlearning에서 좋은 반응을 얻고 있습니다. 에이전트 메모리 분야의 몇몇 사람들과 흥미로운 대화가 시작되고 있습니다.

사용해 보기
bashpip install cognicore-env

빠른 데모

python -c "
import cognicore as cc

env = cc.make('SafetyClassification-Easy-v1')
agent = cc.AutoLearner()
cc.train(agent=agent, env=env, episodes=30)
score = cc.evaluate(agent=agent, env=env, episodes=5)
print(f'Score: {score:.2%}')
"

또는 대시보드 열기

cognicore ui
GitHub: github.com/Kaushalt2004/cognicore-my-openenv

리뷰어의 발견은 제가 그것을 볼 때마다 여전히 놀라움을 줍니다. 저는 논문이 "다중 에이전트 협업 (multi-agent coordination)이 성능을 향상시킨다"라고 말할 것이라 예상했습니다. 대신 논문은 "어떤 에이전트를 추가할지 매우 주의해야 한다"라고 말합니다.
솔직히 말해서, 저는 그것이 더 흥미로운 발견이라고 생각합니다.