저는 Project89에서 차세대 Agent 프레임워크를 보았습니다.
작성자: 0xhhh
결론부터 말하자면, @project_89는 게임 개발을 위한 고성능 에이전트 프레임워크인 Agent Framework를 완전히 새로운 방식으로 설계했습니다. 이 프레임워크는 기존의 Agent Framework에 비해 더욱 모듈화되어 있으며 성능 면에서도 우수합니다.
이 글은 작성하는 데 오랜 시간이 걸렸으며, 누구나 이 프레임워크가 전통적인 Agent 프레임워크보다 아키텍처 측면에서 어떤 점이 향상되었는지 이해할 수 있도록 하기 위해 여러 차례 수정하며 마무리한 버전입니다. 다만 일부 내용은 여전히 기술적으로 다소 어려워 보다 쉽게 풀어내지 못한 부분도 있습니다. 글의 개선에 대한 의견이 있으시면 댓글로 자유롭게 남겨주시기 바랍니다.
개발자 배경
이 글은 기술 블로그이므로 먼저 창립자의 기술 역량을 살펴보겠습니다.
Founder는 project89를 시작하기 전에 다음과 같은 프로젝트를 진행했습니다. https://github.com/Oneirocom/Magick. 이는 AI를 이용한 프로그래밍 도구이며, shaw 또한 해당 프로젝트의 4위 개발자였고, 그의 경력에도 이 프로젝트가 명시되어 있습니다.
좌측 상단: project89의 창립자, 우측 하단: ai16z의 shaw
오늘 우리는 project89 내부의 고성능 Agent Framework를 소개하겠습니다:
https://github.com/project-89/argOS
1. 왜 ECS로 Agent Framework를 설계했는가?
게임 분야에서 현재 ECS 아키텍처를 사용하는 사례는 다음과 같습니다. 블록체인 게임: Mud, Dojo / 전통 게임: 오버워치, 스타 시티즌 등. 또한 주요 게임 엔진들도 현재 ECS 방향으로 진화하고 있는데, 예를 들어 Unity가 대표적입니다.
ECS란 무엇인가요?
ECS(Entity-Component-System)는 게임 개발 및 시뮬레이션 시스템에서 널리 사용되는 아키텍처 패턴입니다. 데이터와 로직을 철저히 분리하여 대규모 확장 가능한 환경에서 다양한 실체(Entity)와 그들의 행동을 효율적으로 관리할 수 있게 해줍니다.
-
Entity(실체): 숫자 또는 문자열 형태의 ID일 뿐이며, 데이터나 로직을 포함하지 않습니다. 필요에 따라 다양한 컴포넌트를 추가해 속성이나 능력을 부여할 수 있습니다.
-
Component(컴포넌트): 실체의 구체적인 데이터나 상태를 저장합니다.
-
System(시스템): 특정 컴포넌트들과 관련된 로직을 실행합니다.
특정 에이전트의 행동 예시를 통해 이 구조를 이해해 봅시다. ArgOS에서는 각각의 Agent를 하나의 Entity로 간주하며, 다양한 컴포넌트를 등록할 수 있습니다. 아래 이미지에서 이 Agent는 다음과 같은 네 가지 컴포넌트를 가지고 있습니다:
- Agent Component: Agent 이름, 모델명 등의 기본 정보를 저장
- Perception Component: 외부로부터 인지된 데이터 저장
- Memory Component: Agent의 메모리 데이터, 예를 들어 수행한 작업 등을 저장
- Action Component: 수행할 액션 데이터를 저장
System의 작동 흐름:
- 게임 내에서 앞에 무기가 있는 것을 감지하면, Perception System의 실행 함수가 호출되어 해당 Agent Entity의 Perception Component 데이터를 갱신합니다.
- 그 후 Memory System이 트리거되며, Perception Component와 Memory Component를 함께 호출하여 인지된 데이터를 메모리에 영구 저장합니다.
- Action System이 Memory Component와 Action Component를 호출하여 주변 환경 정보를 기억에서 추출한 후, 적절한 동작을 최종적으로 수행합니다.
- 그 결과 모든 컴포넌트 데이터가 갱신된 Update Agent Entity를 얻게 됩니다. 즉, System은 특정 컴포넌트에 대해 어떤 처리 로직을 수행할지를 정의하는 역할을 합니다.
또한 project89 내부에는 다양한 유형의 Agent들이 존재하며, 단순한 기본 기능 외에도 계획 수립 능력을 갖춘 Agent도 있습니다. 아래 이미지는 이를 설명합니다.
하지만 실제 System의 실행 흐름은 우리가 일반적으로 생각하는 것처럼 Perception System이 완료된 후 Memory System을 호출하는 식의 전통적인 방식이 아닙니다. 서로 다른 System들 사이에는 호출 관계가 존재하지 않으며, 각 System은 일정한 주기마다 독립적으로 한 번씩 실행됩니다. 예를 들어:
- Perception System은 2초마다 외부에서 수신한 인지 정보를 갱신하고, 이를 Perception Component에 반영
- Memory System은 1초마다 Perception Component에서 데이터를 추출하여 Memory Component에 로드
- Plan System은 1000초마다 수신한 정보를 바탕으로 목표에 맞춰 최적의 계획을 수립할 필요가 있는지 판단하고, 결과를 Plan Component에 기록
- Action System은 2초마다 외부 정보에 신속하게 반응하며, Plan Component에 변경 사항이 있을 경우 이를 기반으로 자신의 Action Component를 갱신하여 초기 액션을 조정
지금까지 설명한 내용은 제가 ArgOS를 이해한 바를 바탕으로 아키텍처를 크게 단순화하여 설명한 것입니다. 이제 실제 ArgOS의 구조를 살펴보겠습니다.
2. ArgOS System 아키텍처
ArgOS는 Agent가 더 깊이 있는 사고를 하고 복잡한 작업을 수행할 수 있도록 하기 위해 많은 Component들과 System들을 설계하였습니다.
또한 ArgOS는 System을 "세 가지 계층(ConsciousnessLevel)"으로 나누었습니다:
1) 의식(CONSCIOUS) 시스템
- RoomSystem, PerceptionSystem, ExperienceSystem, ThinkingSystem, ActionSystem, CleanupSystem 포함
- 갱신 주기는 일반적으로 짧음 (예: 10초마다)
- 환경 인지, 실시간 사고, 동작 수행 등과 같이 '실시간' 혹은 '현시적인 의식' 수준의 처리를 담당
2) 잠재의식(SUBCONSCIOUS) 시스템
- GoalPlanningSystem, PlanningSystem
- 갱신 주기는 상대적으로 긺 (예: 25초마다)
- '사고' 로직을 처리하며, 주기적으로 목표 및 계획을 점검하거나 생성
3) 무의식(UNCONSCIOUS) 시스템
- 현재는 아직 활성화되지 않음
- 갱신 주기는 더 느림 (예: 50초 이상)
따라서 ArgOS에서는 각 System을 ConsciousnessLevel에 따라 분류하여 실행 주기를 결정합니다.
왜 이런 식으로 설계했을까요? 이유는 ArgOS 내부의 각 System들 간 관계가 매우 복잡하기 때문입니다. 아래 그림을 참고하세요.
- PerceptionSystem은 외부 또는 다른 실체로부터 '자극(stimuli)'을 수집하여 Agent의 Perception 컴포넌트에 업데이트합니다. 자극의 변화가 중요한지 여부를 안정도, 처리 모드(ACTIVE/REFLECTIVE/WAITING) 등을 기준으로 판단하고 적절히 업데이트합니다. 이후 ExperienceSystem, ThinkingSystem 등 후속 시스템들에게 '현재 인지 상태'를 제공합니다.
- ExperienceSystem은 PerceptionSystem이 수집한 자극(stimuli)을 더 추상적인 '경험(experience)'으로 변환합니다. LLM 또는 규칙 기반 로직(extractExperiences)을 호출하여 새로운 경험을 식별하고 Memory 컴포넌트에 저장합니다. 중복 제거, 필터링, 검증을 수행하며 eventBus를 통해 'experience' 이벤트를 다른 시스템이나 외부 리스너에게 발행합니다.
- ThinkingSystem은 Agent 자체의 '사고(thinking)' 시스템입니다. Memory, Perception 등의 컴포넌트에서 현재 상태를 추출하여 generateThought(...)를 통해 LLM 또는 규칙 로직을 활용해 '사고 결과(ThoughtResult)'를 생성합니다. 사고 결과에 따라 다음 작업을 수행할 수 있습니다:
- Memory 내 thoughts(사고 기록) 갱신
- 새로운 Action을 Action.pendingAction[eid]에 트리거
- Agent의 외형(Appearance, 표정, 자세 등) 변경 및 관련 Stimulus 생성하여 다른 실체가 변화를 '감지'하도록 함
- ActionSystem은 Agent의 Action.pendingAction이 비어 있지 않은 경우 runtime.getActionManager().executeAction(...)을 통해 실제로 동작을 실행합니다. 실행 후 결과를 Action.lastActionResult에 기록하고, 방(Room) 또는 다른 실체에게 알립니다. 동시에 CognitiveStimulus(인지 자극)를 생성하여 후속 시스템이 '해당 동작이 완료됨'을 인지하거나 메모리에 포함할 수 있도록 합니다.
- GoalPlanningSystem은 Goal.current[eid] 목록 내 목표들의 진행 상황을 주기적으로 평가하거나, 외부/내부 메모리에 중대한 변화가 발생했는지(detectSignificantChanges) 확인합니다. 새로운 목표가 필요하거나 목표 조정이 필요한 경우 generateGoals(...)를 통해 생성하여 Goal.current[eid]에 기록합니다. 진행 중(in_progress)인 목표의 진행 상황도 업데이트하며, 완료 또는 실패 조건에 부합하면 상태를 변경하고 관련 Plan에 완료/실패 신호를 보냅니다.
- PlanningSystem은 '기존 목표(Goal.current[eid])'에 대해 실행 계획(Plan)을 생성하거나 업데이트합니다. 특정 목표에 대응하는 활성(active) 계획이 없으면 generatePlan(...)을 통해 여러 steps를 포함하는 실행 로드맵을 생성하여 Plan.plans[eid]에 기록합니다. 또한 목표가 완료되거나 실패했을 때 관련 Plan의 상태를 업데이트하고, 인지 자극을 발생시킵니다.
- RoomSystem은 방(Room)과 관련된 업데이트를 처리합니다.
- 방 내 거주자 목록(occupants)을 가져와 각 agent에게 '외형(appearance)' 자극을 생성하여 다른 실체가 그들의 외모나 동작을 '볼 수' 있도록 함
- 방 환경 자극(Room environment Stimulus, 예: '방의 분위기')을 생성하고 연결
- Agent가 특정 공간에 위치할 때, 그 공간을 인지 중인 다른 실체들이 외형 변화를 감지할 수 있도록 보장
- CleanupSystem은 Cleanup 컴포넌트가 표시된 실체를 정기적으로 찾아 제거합니다. 더 이상 필요 없는 Stimulus나 기타 객체를 회수하여 ECS 내에 불필요한 실체가 쌓이는 것을 방지합니다.
- 예시: '물체를 보기'부터 '동작 수행'까지의 한 사이클
다음 시나리오는 각 System이 한 턴(혹은 몇 프레임) 내에 어떻게 협업하여 전체 프로세스를 완료하는지를 보여줍니다.
- 시나리오 준비: 월드(World) 내에 Agent(EID=1)가 존재하며, 'Active' 상태이고 특정 Room(EID=100)에 위치. 해당 Room에 새 아이템 'MagicSword'가 등장하며, 이에 따른 Stimulus가 생성됨.
- PerceptionSystem은 'MagicSword'의 등장을 감지하고, Agent(1)에게 type="item_appearance"인 Stimulus를 생성하여 Perception.currentStimuli[1]에 추가. 이전 Stimuli Hash와 비교하여 '중대한 변화'가 있음을 판단하고, Agent의 ProcessingState를 다시 'ACTIVE' 모드로 활성화.
- ExperienceSystem은 Agent(1)의 Perception.currentStimuli가 비어 있지 않음을 확인하고, 'Sword appears'와 같은 정보를 하나 이상의 새로운 Experience(type: "observation")로 추출. 이를 Memory.experiences[1]에 저장하고 'experience' 이벤트를 발행.
- ThinkingSystem은 Memory, Perception 등의 상태 정보를 읽어 generateThought를 호출함: '나는 매직 소드를 보았다. 집어서 어떤 기능이 있는지 확인해보자...' 이 사고 결과에는 { tool: "pickUpItem", parameters: { itemName: "MagicSword" } }라는 실행 대기 액션이 포함됨. ThinkingSystem은 이 액션을 Action.pendingAction[1]에 기록. 만약 표정 변화(예: '호기심 어린 표정')가 있다면 Appearance를 업데이트하고 시각 자극을 생성.
- ActionSystem은 Action.pendingAction[1] = { tool: "pickUpItem", parameters: ... }임을 확인. runtime.getActionManager().executeAction("pickUpItem", 1, { itemName: "MagicSword" }, runtime)을 통해 '아이템 집기' 동작을 실행. 결과: { success: true, message: "매직 소드를 집었습니다" }를 Action.lastActionResult[1]에 기록하고, 방(100)에 'action' 이벤트를 브로드캐스트. 동시에 type="action_result"인 인지 자극을 생성하여 Memory에 저장하거나 다음 턴에서 ThinkingSystem이 포착할 수 있도록 함.
- GoalPlanningSystem(해당 agent가 목표를 가진 경우): 주기적으로 agent의 목표를 평가. 만약 agent의 목표 중 하나가 '강력한 무기 획득'이고 MagicSword를 획득했다면, 해당 목표를 완료 상태로 표시. 또는 '방에 새로운 물체 출현'이 agent의 목표 달성에 영향을 미친다면 detectSignificantChanges를 통해 새 목표 생성 또는 기존 목표 포기.
- PlanningSystem(관련 목표가 있는 경우): '강력한 무기 획득'과 같은 완료되거나 새로 생성된 목표에 대해, 새로운 Plan이 필요하거나 기존 Plan을 업데이트해야 하는지 확인. 목표가 완료되면 관련 Plan [status]를 'completed'로 설정. 또는 목표가 확장되어 '매직 소드 연구' 등의 후속 작업이 필요하다면 추가 단계를 생성.
- RoomSystem(매 프레임 또는 매 턴): 방(100) 내 Occupants 목록과 가시 가능한 실체를 업데이트. agent(1)의 외형이 변경되었을 경우(예: Appearance.currentAction = "holding sword"), 새로운 'appearance' 시각 자극을 생성하여 같은 방에 있는 Agent2, Agent3에게 'agent1이 검을 들었다'는 사실을 알려줌.
- CleanupSystem: 마킹된(Cleanup) 실체나 자극을 제거. 'MagicSword'의 Stimulus가 더 이상 필요 없다면 CleanupSystem에서 해당 Stimulus 실체를 삭제.
이러한 시스템들의 연계를 통해 AI Agent는 다음 과정을 구현합니다: 감지(Perception) → 기록 또는 내면 경험으로 전환(Experience) → 자기 사고 및 의사결정(Thinking) → 행동 수행(Action) → 목표 및 계획 동적 조정(GoalPlanning + Planning) → 환경 동기화(Room) → 불필요한 실체 즉시 회수(Cleanup).
3. ArgOS 전체 아키텍처 분석
1. 핵심 아키텍처 계층화
2. 컴포넌트(Component) 분류
ECS에서 각 실체(Entity)는 여러 개의 컴포넌트(Component)를 가질 수 있습니다. 시스템 내에서의 성격과 수명주기에 따라 다음과 같이 분류할 수 있습니다:
- 핵심 신원 클래스 (Identity-Level Components)
- Agent, PlayerProfile, NPCProfile 등
- 실체를 고유하게 식별하고, 핵심 캐릭터 또는 유닛 정보를 저장. 일반적으로 데이터베이스에 영구 저장 필요
- 행위 및 상태 클래스 (Behavior & State Components)
- Action, Goal, Plan, ProcessingState 등
- 실체가 현재 수행 중인 작업이나 목표, 외부 명령이나 내부 사고에 대한 응답 상태를 나타냄
- pendingAction, goalsInProgress, plans, 큐에 있는 사고 또는 작업 등을 포함
- 대개 중단기 상태이며, 게임 턴 또는 비즈니스 주기에 따라 동적으로 변화
- 데이터베이스에 저장 여부는 상황에 따라 결정. 재개 실행(resume)을 원한다면 주기적으로 DB에 기록 가능
- 인지 및 메모리 클래스 (Perception & Memory Components)
- Perception, Memory, Stimulus, Experience 등
- 실체가 외부에서 인지한 정보(Stimuli) 및 이를 바탕으로 추출한 '경험'(Experiences)을 기록
- Memory는 대량의 데이터를 누적 가능(예: 대화 기록, 사건 역사 등). 일반적으로 영구 저장 필요
- Perception은 실시간 또는 임시 정보로 대부분 단기간 유효. DB 저장 여부는 필요에 따라 결정 (중요한 인지 이벤트만 저장)
- 환경 및 공간 클래스 (Room, OccupiesRoom, Spatial, Environment, Inventory 등)
- 방, 환경, 위치, 아이템 컨테이너 등의 정보를 나타냄
- Room.id, OccupiesRoom, Environment 등은 방의 홈 설명, 지도 구조 등과 같이 영구 저장 필요
- 지속적으로 변화하는 컴포넌트(예: 실체가 다른 방으로 이동)는 이벤트 기반 또는 주기적으로 저장 가능
- 외형 및 상호작용 클래스 (Appearance, UIState, Relationship 등)
- 실체의 외부에 '보이는' 또는 '상호작용'하는 부분을 기록. 예: 아바타, 자세(pose), 얼굴 표정(facialExpression), 다른 실체와의 사회적 관계망 등
- 일부는 메모리 내에서만 처리(실시간 표현), 일부(예: 핵심 사회적 관계)는 영구 저장 필요
- 보조 또는 운영 클래스 (Cleanup, DebugInfo, ProfilingData 등)
- 회수할 실체를 표시(Cleanup)하거나 디버깅 정보(DebugInfo)를 기록하여 모니터링 및 분석에 활용
- 일반적으로 메모리에만 존재. 로그 또는 감사(audit) 필요 시에만 DB에 동기화
3. System 아키텍처
위에서 이미 설명함
4. Manager 아키텍처
컴포넌트와 시스템 외에도 리소스 관리자가 필요합니다. 예를 들어 데이터베이스 접근 방법, 상태 갱신 충돌 시 처리 방법 등입니다.
왼쪽: Systems (PerceptionSystem, ExperienceSystem, ThinkingSystem 등)
- 각 시스템은 SimulationRuntime에 의해 ECS 루프 내에서 스케줄링되어 자신이 관심 있는 실체(컴포넌트 조건 기반)를 조회하고 처리
- 로직 실행 시 Managers와 상호작용 필요. 예:
- RoomManager(RM) 호출하여 방 정보 조회/업데이트
- StateManager(SM) 사용하여 월드/에이전트 상태(Memory, Goal, Plan 등) 가져오기 또는 저장
- EventBus(EB) 활용하여 외부에 이벤트 브로드캐스트 또는 리스닝
- 자연어 처리 또는 프롬프트 필요 시 PromptManager(PM) 호출
----------------
오른쪽: Managers (EventBus, RoomManager, StateManager, EventManager, ActionManager, PromptManager 등)
- 시스템 수준 기능을 제공하며, 기본적으로 로직을 '주도(drive)'하지 않고 Systems 또는 Runtime에 의해 호출됨
- 대표적 예시:
- ActionManager: 액션(Action)의 등록 및 실행을 전담 관리
- EventManager / EventBus: 이벤트 발행 및 구독 메커니즘 제공
- RoomManager: rooms, 레이아웃, occupant 관리
- StateManager: ECS와 데이터베이스 또는 저장소 간 동기화 책임
- PromptManager: LLM 프롬프트 템플릿, 컨텍스트 관리 등 확장 제공
- 중앙의 SimulationRuntime(R):
- 모든 Systems의 '스케줄러'. 의식(Conscious)/잠재의식(Subconscious) 등 계층별 시스템 루프를 시작/정지
- 생성 단계에서 Managers를 생성하여 각 System에 전달
- CleanupSystem:
- 특히 ComponentSync(CS)와 상호작용하여 실체 회수 시 컴포넌트 또는 이벤트 구독도 함께 제거
결론: 각 System은 필요 시 해당 Manager를 통해 데이터 읽기/쓰기 또는 서비스 호출을 수행하며, Runtime은 더 높은 수준에서 모든 System과 Manager의 수명주기 및 동작을 통합적으로 스케줄링합니다.
5. 벡터 및 데이터베이스와의 상호작용 방법
ECS에서 Systems는 로직을 실제로 실행하는 장소이며, 데이터베이스의 읽기/쓰기는 '영속성 관리자(PersistenceManager / DatabaseManager)' 또는 '상태 관리자(StateManager)'를 통해 수행됩니다. 대략적인 흐름은 다음과 같습니다:
- 시작 또는 로드 시 (Initial Load)
- StateManager / PersistenceManager가 데이터베이스에서 Agents, Rooms, Goals 등 핵심 영구 저장 컴포넌트 데이터를 로드하여 대응하는 실체(Entities)를 생성하고 관련 컴포넌트 필드를 초기화
- 예: agent 레코드를 읽어 ECS 월드에 삽입하고, Agent, Memory, Goal 등의 컴포넌트를 초기화
- ECS 실행 중 (Systems Update Loop)
- 각 프레임(또는 턴)마다 시스템이 동작: PerceptionSystem은 '인지(perception)'를 수집하여 Perception 컴포넌트에 기록(대부분 단기, DB 저장 안 함)
- ExperienceSystem은 새로운 '인지 경험(cognitive experience)'을 Memory.experiences에 기록. 중요한 경험은 즉시 StateManager를 호출하여 저장하거나 'needsPersistence' 마킹하여 후에 일괄 저장
- ThinkingSystem / ActionSystem / GoalPlanningSystem 등은 컴포넌트 내용에 기반해 의사결정을 내리고 ECS 내 필드를 업데이트
- 특정 컴포넌트(Goal.current 등)에 중대한 변경이 발생하고 영구 저장이 필요한 경우(예: 새로운 장기 목표), 컴포넌트 리스너 또는 시스템 이벤트를 통해 StateManager에게 DB 저장 요청
- 정기적 또는 이벤트 기반 영구 저장 (Periodic or Event-Driven)
- 목표 계획 업데이트 또는 Agent의 중요 이벤트와 같은 핵심 지점에서 PersistenceManager.storeComponentData(eid, "Goal") 인터페이스를 호출하여 DB 저장
- CleanupSystem 또는 타이머 내에서 StateManager가 'needsPersistence' 마킹된 컴포넌트 또는 실체를 스캔하여 일괄 DB 저장
- 또한 로그 또는 감사 데이터(액션 기록, 사고 로그 등)도 여기서 보관 저장 가능
- 종료 또는 체크포인트 저장 (Manual or Shutdown Save)
- 서버 또는 프로세스 종료 시 StateManager.saveAll()을 호출하여 아직 DB에 기록되지 않은 데이터를 모두 저장. 다음 로딩 시 ECS 상태를 복구 가능
- 일부 오프라인/단독 시나리오에서는 수동으로 저장 기능 트리거 가능
- 완전한 예시 흐름
다음은 컴포넌트와 데이터베이스 간 상호작용 방식을 보여주는 간단한 시나리오입니다:
- 시작 시: StateManager.queryDB("SELECT * FROM agents") → agent 레코드를 받아 각각에 대해 Entity(EID=x)를 생성하고, Agent, Memory, Goal 등의 컴포넌트 필드를 초기화. 동시에 "rooms" 테이블에서 방 정보를 로드하여 Room 실체 생성.
- 실행 중: PerceptionSystem이 특정 방에서 "MagicSword 등장" 이벤트를 감지하여 Perception.currentStimuli[eid]에 기록. ExperienceSystem이 Stimuli를 Experience로 변환하여 Memory.experiences[eid]에 할당. ThinkingSystem이 Memory, Goal 등의 정보를 기반으로 다음 동작 결정, Action.pendingAction[eid] 생성. ActionSystem이 해당 동작을 실행 후 결과를 Memory 또는 Action.lastActionResult에 기록. 이때 중대한 스토리 이벤트라면 Memory.experiences[eid]의 최신 부분에 needsPersistence 마킹. StateManager는 일정 시간 후 needsPersistence가 있는 Memory.experiences[eid]를 발견하여 데이터베이스에 기록(INSERT INTO memory_experiences ...).
- 종료 또는 체크포인트: ECS 또는 시스템 스케줄링에 기반하여 '서버 종료' 시 StateManager.saveAll() 호출. 메모리 내 남아 있는 핵심 컴포넌트 필드(Agent, Memory, Goal 등)의 최신 상태를 데이터베이스에 기록. 다음 재시작 시 데이터베이스에서 로드하여 ECS 월드 상태를 복구.
- 컴포넌트를 분류함으로써 프로젝트 내에서 실체 데이터를 명확하게 관리할 수 있고, '영구 저장 필요' 데이터와 '메모리 내 존재' 데이터의 경계를 효과적으로 통제할 수 있습니다.
- 데이터베이스와의 상호작용은 일반적으로 전담 매니저(예: StateManager)가 처리하며, Systems는 데이터베이스 읽기/쓰기 시 이를 통해 작업. 이렇게 하면 System 내에서 직접 SQL이나 저수준 문장을 작성하는 것을 피할 수 있습니다.
- 이를 통해 ECS의 논리적 효율성과 유연성을 유지하면서도, 데이터베이스의 영구 저장, 체크포인트 재개, 데이터 통계 분석 등의 이점을 동시에 누릴 수 있습니다.
5. 아키텍처 혁신 포인트
- 전체 아키텍처의 핵심 강점:
- 각 System은 독립적으로 실행되며, 다른 System과 호출 관계가 없습니다. 따라서 '환경 인지(Perception) → 경험으로 전환(Experience) → 사고 및 의사결정(Thinking) → 행동 수행(Action) → 목표 및 계획 동적 조정(GoalPlanning + Planning) → 환경 동기화(Room) → 불필요 실체 회수(Cleanup)'와 같은 복잡한 능력을 구현하더라도, 기능적으로 서로 의존하는 요소가 많지만 ECS 아키텍처를 통해 각 System을 완전히 독립된 구조로 만들 수 있습니다. 각 System은 여전히 독립적으로 실행되며, 다른 System과 결합도(coupling)가 전혀 없습니다. 이것이 바로 최근 Unity가 점점 ECS 아키텍처로 전환하는 가장 큰 이유라고 생각합니다.
- 또한, 지금 당장 Agent에게 기본 기능만 부여하고 싶다면, Entity 정의 시 등록하는 Component와 System 수를 줄이기만 하면 코드 수정 없이 쉽게 구현할 수 있습니다.
아래 이미지 참조:
- 개발 중에 새로운 기능을 추가하고 싶어도 다른 System에 전혀 영향을 주지 않으며, 원하는 기능을 쉽게 로드할 수 있습니다. 또한 현재의 아키텍처는 성능 면에서 전통적인 객체 지향 아키텍처보다 훨씬 뛰어납니다. 이는 게임 업계에서 공인된 사실이며, ECS 설계는 동시성(concurrency)에 더 적합하기 때문입니다. 따라서 복잡한 DeFi 환경에서도 ECS 아키텍처가 유리할 수 있으며, 특히 Agent를 이용한 양적 거래(Quant Trading) 시나리오에서도 ECS는 충분한 활용 가치가 있습니다(단순히 Agent 기반 게임 환경에 국한되지 않음).
- System을 의식, 잠재의식, 무의식으로 나누어 각 유형의 System이 얼마나 자주 실행되어야 하는지를 결정하는 것은 극도로 정교한 설계이며, 인간의 능력을 매우 구체적으로 모방한 것입니다.
개인적인 견해로는, 이는 극도로 모듈화되고 성능이 뛰어난 프레임워크이며, 코드 품질도 매우 높고 훌륭한 설계 문서도 포함되어 있습니다. 아쉽게도 $project89 프로젝트는 이 프레임워크에 대한 홍보가 부족했기 때문에 저는 이 글을 작성하는 데 4일이라는 긴 시간을 들였습니다. 좋은 기술은 반드시 발견되어야 한다고 생각합니다. 내일 영문판도 발표할 예정이며, 더 많은 게임 팀이나 DeFi 팀이 이 프레임워크를 접하고 새로운 잠재적 아키텍처 선택지로 활용해주길 바랍니다!
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News
@hhh69251498
