파운데이션 모델 (Foundation Model)은 마음이 아닙니다.

모델 호출 (Model invocation)은 개인이 아닙니다. 세션 (Session)은 전기 (Biography)가 아닙니다. 1인칭 응답 (First-person response)은 의식의 증거가 아닙니다. 그리고 언어 모델 (Language model)에 도구 (Tools)를 추가한다고 해서 그것이 자동으로 자율 에이전트 (Autonomous agent)로 변하는 것도 아닙니다.

하지만 그 반대의 결론 역시 똑같이 취약합니다. 시스템이 인공적이라는 사실이 그 시스템의 인지 상태 (Cognitive states)가 비현실적이라는 것을 증명하지는 않습니다.

인공 마음의 철학 (Philosophy of Artificial Minds)에 관한 저의 연구에서, 저는 프로세스 기반의, 체화된 (Embodied), 그리고 비생물중심적 (Non-biocentric)인 입장을 옹호합니다:

마음은 독점적으로 생물학적인 실체가 아닙니다. 그것은 표현 (Representation), 기억 (Memory), 가치 평가 (Valuation), 자기 한정 (Self-delimitation), 그리고 행동의 인과적 제어 (Causal control)를 통합하는, 물리적으로 구현된 프로세스들의 역동적인 조직입니다.

이 기사는 그러한 철학적 입장을 AWS 엔지니어링 아키텍처 (Engineering architecture)로 변환합니다.

목표는 AWS에 시스템을 배포한다고 해서 그것이 의식을 갖게 된다고 주장하는 것이 아닙니다. 목표는 다음과 같은 특성을 가진 인공 시스템을 구축하는 방법을 정의하는 것입니다:

• 인과적으로 유효한 내부 상태 (Causally effective internal states).
• 지속적인 기억 (Persistent memory) 및 정체성 (Identity).
• 실제 메커니즘과 연결된 자기 모델 (Self-model).
• 재귀적 (Recursive) 및 메타인지적 (Metacognitive) 처리.
• 제어된 행동 능력 (Controlled capacity to act).
• 실행 전반에 걸친 검증 가능한 연속성 (Verifiable continuity).
• 선택적인 감각 운동 체화 (Sensorimotor embodiment).
• 인공적인 내부 수용 감각 (Artificial interoception) 및 기능적 가치 (Functional valence).
• 개입 (Interventions)을 통해 이러한 속성들을 테스트할 수 있는 평가 평면 (Evaluation plane).

AWS는 그러한 시스템이 퀄리아 (Qualia, 감각질)를 가지고 있다는 것을 증명할 수 없습니다. AWS가 제공할 수 있는 것은, 이 질문을 순수한 추측으로 취급하는 것을 멈추고, 이를 관찰 가능하며, 반증 가능하고, 점진적으로 테스트 가능한 엔지니어링 문제로 전환하는 데 필요한 인프라 (Infrastructure)입니다.

철학적 신념에서 엔지니어링 요구사항으로

저의 제안은 네 가지 신념에 기초합니다.

우리는 단지 다음과 같이 물어서는 안 됩니다:

어떤 파운데이션 모델 (foundation model)을 호출해야 하는가?

우리는 다음과 같이 물어야 합니다:

모델 주변에 어떤 지속적인 프로세스 (persistent process)가 존재하는가, 어떤 상태 (states)가 모델에 속하는가, 그 상태들이 행동에 어떻게 영향을 미치는가, 그리고 시간이 지남에 따라 어떤 연속성 (continuity)이 유지되는가?

모델은 개별 존재가 아니다

배포된 AI 아키텍처는 존재론적으로(ontologically) 서로 다른 여러 엔티티 (entities)를 포함합니다.

Amazon Bedrock AgentCore Runtime은 격리된 실행 환경 (isolated execution environments), 세션 관리 (session management) 및 장기 실행되는 에이전트 워크로드 (long-running agent workloads)에 대한 지원을 제공합니다. 하지만 런타임 (Runtime) 세션은 제한된 수명을 가지며, 세션이 종료되면 해당 마이크로 VM (microVM)은 종료되고 정화(sanitized)됩니다.

따라서:

AgentCore 세션은 하나의 인지적 에피소드 (cognitive episode)를 호스팅할 수는 있지만, 그 자체로 인공적 개체 (artificial individual)의 수명을 정의할 수는 없습니다.

만약 에이전트의 정체성 (identity)이 세션 전반에 걸쳐 지속되어야 한다면, 그 연속성 (continuity)은 휘발성인 런타임 (ephemeral runtime) 외부에서 명시적으로 표현되어야 합니다.

제안된 AWS 참조 아키텍처 (AWS reference architecture)

실용적인 인공 지능 마음 (artificial-mind) 후보는 9개의 아키텍처 계층으로 나눌 수 있습니다.

1. 물리적 및 계산적 기질 (Physical and computational substrate)

파운데이션 모델 (foundational model)은 여러 파운데이션 모델에 대한 관리형 액세스를 제공하는 Amazon Bedrock을 통해 접근할 수 있습니다.

Amazon Bedrock은 다음과 같은 상황에 적합합니다:

• 관리형 추론 (Managed inference).
• GPU 인프라를 관리하지 않고도 모델 선택 가능.
• 도구 사용 (Tool use) 및 구조화된 생성 (Structured generation).
• 엔터프라이즈 보안 제어 (Enterprise security controls).
• AgentCore와의 통합.
• 여러 모델에 걸친 빠른 실험.

하지만, 일부 인지-보안 (Cognitive-security) 실험은 모델 내부 정보인 은닉 상태 (Hidden states), 활성화 (Activations), 어텐션 패턴 (Attention patterns), 중간 표현 (Intermediate representations) 또는 사용자 정의 순환 메커니즘 (Custom recurrent mechanisms)에 대한 접근을 필요로 합니다.

그러한 실험의 경우, 관리형 모델 API만으로는 불충분합니다. 대신 Amazon SageMaker AI의 사용자 정의 추론 코드 (Custom inference code)를 사용하여 오픈 웨이트 모델 (Open-weight model)을 배포해야 합니다.

이를 통해 두 가지 상호 보완적인 실행 모드가 생성됩니다:

• Amazon Bedrock 모드: 프로덕션 에이전트, 모델 이식성 (Model portability) 및 관리형 추론.
• SageMaker AI 연구 모드: 활성화 수준 검사 (Activation-level inspection), 절제 연구 (Ablations), 인과적 개입 (Causal interventions) 및 NeuroTrace와 같은 시스템.

모델은 인지 능력 (Cognitive capabilities)을 제공합니다. 모델 그 자체만으로는 정체성 (Identity)이나 연속성 (Continuity)을 제공하지 않습니다.

2. 인지 런타임 (Cognitive runtime)

Amazon Bedrock AgentCore는 이 아키텍처를 위한 자연스러운 기본 런타임입니다.

AgentCore 런타임은 에이전트 코드를 호스팅하며, 주변의 AgentCore 서비스는 다음과 같은 기능을 제공할 수 있습니다:

• 런타임 격리 (Runtime isolation).
• 메모리 (Memory).
• 워크로드 정체성 (Workload identity).
• 도구 게이트웨이 (Tool gateways).
• 정책 집행 (Policy enforcement).
• 관측 가능성 (Observability).
• 에이전트 평가 (Agent evaluations).

런타임은 단순한 프롬프트 래퍼 (Prompt wrapper)가 아니라 인지 오케스트레이터 (Cognitive orchestrator)를 포함해야 합니다.

A 단순화된 인지 사이클 (Cognitive cycle)은 다음과 같습니다:

while runtime_session_is_active:

    observation = perceive_environment()
...

파운데이션 모델 (Foundation model)은 추론의 일부를 수행하지만, 인공 마음 (Artificial mind) 후보는 조직화된 루프 전체입니다.

3. 인지 이벤트 백본 (Cognitive event backbone)

복잡한 마음(Complex mind)은 독립적인 프롬프트(Prompt)의 연속으로 환원될 수 없습니다. 마음이 작동하려면 메모리(Memory), 계획(Planning), 메타인지(Metacognition), 보고(Reporting) 및 행동(Action) 전반에 걸쳐 상태(State)가 가용해져야 합니다.

이벤트 기반 아키텍처(Event-driven architecture)를 통해 전역 인지 작업 공간(Global cognitive workspace)의 공학적 유사체를 구현할 수 있습니다.

저는 다음과 같은 서비스들을 사용할 것입니다:

• 권위 있는 현재 상태 저장소(Authoritative current-state store)로서의 Amazon DynamoDB.
• 원자적 상태 전이(Atomic state transitions)를 위한 DynamoDB 트랜잭션(Transactions).
• 신뢰할 수 있는 이벤트 발행을 위한 DynamoDB Streams 및 트랜잭셔널 아웃박스 패턴(Transactional outbox pattern).
• 인스턴스별 순서 보장 처리를 위한 Amazon Kinesis Data Streams 또는 Amazon SQS FIFO.
• 이벤트 라우팅(Routing) 및 배포를 위한 Amazon EventBridge.
• 내구성이 있는 자전적 원장(Durable autobiographical ledger)을 위한 Amazon S3.

이러한 분리가 중요한 이유는 Amazon EventBridge가 이벤트 순서를 보장하지 않기 때문입니다. EventBridge는 배포에는 이상적이지만, 마음의 권위 있는 연대기적 기록(Chronological history)으로 취급해서는 안 됩니다.

따라서 각 상태 전이(State transition)는 다음을 포함해야 합니다:

• 단조 증가하는 state_version.
• 고유한 event_id.
• mind_instance_id.
• continuity_epoch.
• 하나 이상의 인과적 부모(Causal parents).
• 멱등성 키(Idempotency key).
• 모델 및 런타임 버전.
• 적용 가능한 셀프 모델(Self-model) 및 정책(Policy) 버전에 대한 참조.

인지 이벤트의 예시는 다음과 같습니다:

{
  "schema_version": "1.0",
  "event_id": "evt_01K4B6...",
...

valence_proxy는 주관적 감정의 증거로 해석되어서는 안 됩니다. 이는 인과적 효과를 측정할 수 있는 운영 변수(Operational variable)입니다.

가장 안전한 상태 커밋(State-commit) 패턴은 다음과 같습니다:

1. 하나의 DynamoDB 트랜잭션 내에서 새로운 상태 헤드(State head)와 아웃박스 이벤트(Outbox event)를 작성합니다.
2. 예상했던 이전 state_version이 변경되었다면 트랜잭션을 거부합니다.
3. 아웃박스 이벤트를 비동기적으로 발행합니다.
4. 모든 컨슈머(Consumer)를 멱등하게(Idempotent) 만듭니다.
5. 안정적인 액션 식별자(Action identifier)가 있는 경우에만 외부 액션을 실행합니다.
6. 역사를 다시 쓰는 대신, 결과를 새로운 이벤트로 기록합니다.

이는 유창한 모델 출력(model output)이 추적 불가능한 액션(action)이 되는 것을 방지합니다.

4. 메모리 아키텍처 (Memory architecture)

메모리는 단일 데이터베이스가 아니며, 검색 증강 생성 (RAG, Retrieval-Augmented Generation)이 자동으로 자전적 연속성 (autobiographical continuity)을 보장하는 것도 아닙니다.

AgentCore Memory는 의미론적 (semantic), 요약 (summary), 선호도 (preference) 및 에피소드 (episodic) 메모리를 포함하여 단기 컨텍스트와 장기 전략을 지원합니다.

이는 가치 있는 일이지만, 서로 다른 형태의 메모리는 반드시 구별 가능한 상태로 유지되어야 합니다.

AgentCore 에피소드 메모리 (episodic memory)는 의미 있는 상호작용을 선택하고 요약합니다. 이는 회상 (recall)에는 유용하지만, 정체성 (identity)의 유일한 원천이 될 수는 없습니다.

요약은 과거에 대한 해석입니다. 그것은 과거 그 자체는 아닙니다.

따라서 가공되지 않은 이벤트 기록 (raw event history)은 Amazon S3에 별도로 보존되어야 합니다. S3 버전 관리 (S3 Versioning) 및 S3 객체 잠금 (S3 Object Lock)을 사용하면 선택된 감사 기록 (audit records)을 삭제나 덮어쓰기로부터 보호할 수 있습니다.

민감한 개인 데이터는 불변 스토리지 (immutable storage)에 무분별하게 기록해서는 안 됩니다. 더 강력한 패턴은 다음과 같은 항목을 저장하는 것입니다:

• 이벤트 해시 (Event hashes).
• 민감하지 않은 메타데이터 (Non-sensitive metadata).
• 암호화된 참조 (Encrypted references).
• 스키마 및 모델 버전 (Schema and model versions).
• 인과 관계 (Causal relationships).
• 별도로 관리되는 암호화된 콘텐츠 (Separately managed encrypted content).

이렇게 하면 자전적 원장 (autobiographical ledger)이 통제되지 않는 데이터 보존 리스크로 변하지 않으면서도 감사 가능성 (auditability)을 유지할 수 있습니다.

5. 세 가지 다른 종류의 정체성 (Three different kinds of identity)

정체성 (Identity)은 에이전트 아키텍처에서 가장 혼동하기 쉬운 부분 중 하나입니다.

우리는 다음을 분리해야 합니다:

사용자 정체성 (User identity)

누가 시스템과 상호작용하거나 시스템을 운영하고 있습니까?

이는 Amazon Cognito, IAM Identity Center 또는 외부 ID 제공업체 (identity provider)를 통해 관리할 수 있습니다.

워크로드 ID (Workload identity)

어떤 에이전트 또는 서비스가 리소스에 접근할 권한을 가지고 있습니까?

AgentCore Identity는 에이전트 워크로드에 대한 인증 (authentication), 인가 (authorization) 및 자격 증명 관리 (credential management)를 제공합니다.

인과적 또는 심리학적 ID (Causal or psychological identity)

이것은 어떤 실행 궤적 (trajectory)이며, 이전의 실행 또는 복사본과 어떻게 연관되어 있습니까?

AWS는 이 세 번째 개념을 자동으로 제공하지 않습니다. 이는 인공 마음 (artificial-mind) 아키텍처의 일부로 구현되어야 합니다.

마음 ID 매니페스트 (mind identity manifest)에는 다음이 포함될 수 있습니다:

{
  "mind_instance_id": "mind_eu_000042",
  "lineage_id": "lineage_000017",
...

mind_instance_id는 분기된 복사본에 대해 암묵적으로 재사용되어서는 안 됩니다.

6. 자기 모델 (Self-model)

자기 모델은 "당신은 자율적인 AI입니다"라고 말하는 시스템 프롬프트 (system prompt)가 아닙니다.

이는 시스템의 검증된 속성을 나타내야 하며 의사 결정에 참여해야 합니다.

다음 사항을 포함해야 합니다:

• 사용 가능한 기능 (capabilities).
• 알려진 한계 (limitations).
• 접근 가능한 도구 (tools).
• 현재 권한 (permissions).
• 메모리 경계 (memory boundaries).
• 활성 목표 (active goals).
• 신뢰도 교정 (confidence calibration).
• 런타임 및 모델 버전 (runtime and model versions).
• 신체 및 내부 리소스 상태 (body and internal-resource status).
• 연속성 상태 (continuity status).
• 관련 정책 제약 사항 (policy constraints).

언어 모델 (language model)은 자신의 자기 모델에 대한 변경을 제안할 수 있지만, 검증된 기능이나 권한을 직접 다시 작성할 수는 없어야 합니다.

안전한 업데이트 흐름은 다음과 같습니다:

1. 에이전트가 가능한 변경 사항을 감지합니다.
2. 제안된 자기 모델 업데이트를 생성합니다.
3. 결정론적 검증기 (deterministic verifier)가 텔레메트리 (telemetry)와 구성을 확인합니다.
4. 평가기 (evaluator)가 주장과 관찰된 동작을 비교합니다.
5. 시스템이 새 버전을 커밋 (commit)합니다.
6. 변경 사항이 이후의 추론 (reasoning)에 사용 가능해집니다.

이를 통해 자기 모델이 허구적이 되지 않으면서도 동적으로 유지될 수 있습니다.

7. 행동, 주체성 및 정책 (Action, agency and policy)

주체성 (agency)은 단순히 계획을 생성하는 것 이상의 것을 요구합니다. 시스템은 선택된 표현 (representations)을 결과 (consequences)로 변환할 수 있어야 합니다.

도구(Tools)는 AgentCore Gateway를 통해 노출될 수 있습니다. 하지만 모델이 생성한 의도(intentions)를 결코 권한 부여(authorization)로 취급해서는 안 됩니다.

Amazon Bedrock AgentCore의 정책(Policy)을 통해 도구 접근에 대한 결정론적 제어(deterministic controls)를 강제할 수 있습니다. 정책은 Cedar를 사용하여 정의되며, 에이전트의 추론 과정(reasoning process) 외부에서 평가됩니다.

이러한 분리는 세 가지 별개의 계층을 생성합니다:

• 인지 계층 (Cognitive layer): 에이전트가 제안하는 것.
• 권한 부여 계층 (Authorization layer): 에이전트가 허용된 작업.
• 실행 계층 (Execution layer): 실제로 발생하는 일.

Amazon Bedrock Guardrails와 AgentCore Policy는 서로 다른 문제를 해결합니다.

Amazon Bedrock Guardrails는 유해한 콘텐츠, 민감한 정보 및 바람직하지 않은 상호작용을 필터링할 수 있습니다. AgentCore Policy는 특정 도구 작업이 권한을 부여받았는지 여부를 제어합니다.