시리즈: “AI를 넘어서 — 사이버네틱스로 가는 길” (3/5)
2편에서 6개 레이어의 전체 그림을 조감도로 살펴봤습니다. 이번 편부터는 기술의 속살로 들어갑니다. 감각 계층(Layer 1)과 인지 계층(Layer 2), 즉 시스템이 세상을 감지하고 판단을 내리는 앞단 두 계층을 아키텍처 수준에서 상세히 다룹니다.
감각 계층을 왜 먼저, 그리고 깊이 다루는가
많은 AI 프로젝트가 “어떤 모델을 쓸 것인가”부터 시작합니다. 두뇌(인지 계층)를 먼저 고민하는 것입니다. 하지만 사이버네틱스 관점에서 보면 이것은 순서가 뒤집힌 것입니다.
아무리 뛰어난 두뇌도 눈과 귀가 부실하면 잘못된 판단을 내립니다. 그리고 사이버네틱 시스템에서 잘못된 판단은 단순한 오류로 끝나지 않습니다. 잘못된 판단 → 잘못된 실행 → 잘못된 결과 → 잘못된 피드백 → 더 잘못된 판단의 악순환, 즉 자기 강화적 오류 루프가 만들어집니다. 감각이 오염되면 피드백 루프 전체가 오염됩니다.
그래서 감각 계층이 먼저이고, 깊이 다뤄져야 합니다.
Part 1: 감각 계층 (Sense Layer) 기술 상세
이벤트 스트리밍 아키텍처
왜 배치가 아니라 스트리밍인가
전통적인 데이터 파이프라인은 배치(Batch) 방식입니다. 하루에 한 번, 또는 한 시간에 한 번 데이터를 모아서 한꺼번에 처리합니다. 이 방식은 분석 리포트를 만드는 데는 충분하지만, 사이버네틱 시스템에는 부족합니다.
피드백 루프의 속도는 감각의 속도에 의해 결정됩니다. 에어컨이 온도를 1시간에 한 번만 감지한다면, 방이 이미 찜통이 된 후에야 냉방을 시작할 것입니다. 마찬가지로, 고객 이탈 신호를 하루에 한 번 감지하는 시스템은 이미 떠난 고객에게 뒤늦은 대응을 할 수밖에 없습니다.
이벤트 스트리밍은 이벤트가 발생하는 즉시 시스템에 흘러들어오게 합니다. 고객이 장바구니를 비우는 순간, 센서가 이상치를 감지하는 순간, 경쟁사가 가격을 변경하는 순간. 이 실시간성이 피드백 루프를 빠르게 돌리는 전제 조건입니다.
Kafka 중심 아키텍처의 설계
Apache Kafka는 현재 이벤트 스트리밍의 사실상 표준입니다. 사이버네틱 시스템에서 Kafka를 설계할 때 고려해야 할 핵심 사항을 살펴보겠습니다.
토픽 설계가 첫 번째입니다. 토픽은 이벤트의 “채널”입니다. 설계 원칙은 “이벤트의 성격과 소비자에 따라 분리”하는 것입니다. 사용자 행동 이벤트(클릭, 조회, 구매), 시스템 이벤트(가격 변경, 재고 변동), 외부 이벤트(경쟁사 가격, 날씨, 환율)를 별도의 토픽으로 분리합니다. 토픽이 너무 세분화되면 관리가 복잡해지고, 너무 통합되면 소비자가 불필요한 이벤트까지 처리해야 합니다. 실무에서는 “하나의 엔티티(entity)의 상태 변화”를 하나의 토픽으로 묶는 것이 좋은 출발점입니다.
파티셔닝 전략이 두 번째입니다. 파티션은 병렬 처리의 단위입니다. 같은 키를 가진 이벤트는 반드시 같은 파티션에 들어가야 순서가 보장됩니다. 예를 들어, 특정 고객의 이벤트가 여러 파티션에 흩어지면, “조회 → 장바구니 추가 → 구매”의 순서가 뒤섞일 수 있습니다. 고객 ID를 파티션 키로 사용하면 같은 고객의 이벤트 순서가 보장됩니다. 파티션 수는 나중에 늘리기 어려우므로(키 재분배 필요), 초기에 넉넉하게 설정하는 것이 좋습니다.
보존 정책(Retention Policy)도 신중히 결정해야 합니다. Kafka의 이벤트를 얼마나 오래 보존할 것인가. 사이버네틱 시스템에서는 피드백 루프가 과거 데이터를 참조해야 하므로, 최소한 피드백 주기의 몇 배 이상은 보존해야 합니다. 마케팅 루프의 피드백 주기가 1일이라면 최소 1주일, 물류 루프가 1주일이라면 최소 1개월. 장기 보존이 필요한 데이터는 Kafka에서 데이터 레이크로 흘려보내고 Kafka 자체의 보존 기간은 적절히 제한하는 것이 일반적입니다.
Kafka Streams와 ksqlDB도 고려할 만합니다. 이벤트가 Kafka에 들어온 후 별도의 시스템으로 보내서 처리하는 대신, Kafka 내부에서 바로 스트림 처리를 할 수 있습니다. 실시간 집계(최근 5분간 특정 상품 조회 수), 이벤트 필터링(특정 조건을 만족하는 이벤트만 추출), 스트림 조인(사용자 이벤트 + 상품 정보 결합) 같은 작업을 데이터가 흘러가는 도중에 처리합니다. 이것은 감각 계층의 반응 속도를 크게 높여줍니다.
Kafka 대안: Pulsar와 Redpanda
모든 상황에 Kafka가 최선은 아닙니다. Apache Pulsar는 멀티 테넌시(multi-tenancy)와 지리적 분산(geo-replication)이 강점이고, 저장과 처리가 분리된 아키텍처라 탄력적 확장이 더 쉽습니다. 글로벌 서비스나 멀티 팀 환경에서 유리합니다. Redpanda는 Kafka 호환 API를 제공하면서 JVM 없이 C++로 작성되어 지연 시간이 더 짧습니다. 초저지연이 필요한 환경에서 고려할 만합니다.
어떤 것을 선택하든, 핵심은 “이벤트가 발생한 즉시 시스템에 도달하는 실시간 파이프라인”을 구축하는 것입니다.
범용 커넥터 허브 설계
어댑터 패턴의 적용
기업 환경의 데이터 소스는 놀랍도록 다양합니다. REST API를 제공하는 SaaS, Webhook을 보내는 서비스, 데이터베이스의 변경 로그(CDC), MQTT로 통신하는 IoT 센서, CSV로 내보내는 레거시 시스템. 이 모든 것을 하나씩 직접 연동하면 유지보수 지옥이 됩니다.
커넥터 허브는 어댑터 패턴(Adapter Pattern)으로 이 문제를 해결합니다. 각 데이터 소스와의 연동 로직을 “어댑터”라는 독립적인 모듈로 캡슐화하고, 어댑터의 출력은 모두 동일한 형식(표준 이벤트 포맷)으로 통일합니다. 새로운 데이터 소스를 추가할 때는 해당 소스용 어댑터만 하나 만들면 되고, 나머지 시스템은 전혀 수정할 필요가 없습니다.
Kafka Connect가 이 패턴의 대표적인 구현입니다. 수백 가지 소스/싱크 커넥터가 이미 존재하고, 커스텀 커넥터를 직접 만들 수도 있습니다. Debezium은 데이터베이스의 변경 사항을 실시간으로 캡처하는(CDC) 전용 커넥터로, RDB의 변경 로그를 Kafka 이벤트로 변환해줍니다.
표준 이벤트 포맷
모든 어댑터가 출력하는 이벤트의 형식을 통일하는 것이 중요합니다. CloudEvents 스펙이 좋은 출발점입니다. 이벤트의 소스, 타입, 시간, 데이터를 표준화된 구조로 정의합니다. 예를 들어 어떤 소스에서 오든 “누가(source), 무엇을(type), 언제(time), 어떤 데이터와 함께(data)” 형태로 통일되면, 하류 시스템은 소스의 종류에 상관없이 동일한 방식으로 이벤트를 처리할 수 있습니다.
통합 데이터 모델과 Schema Registry
왜 스키마 관리가 중요한가
데이터가 실시간으로 빠르게 흘러가는 환경에서, 데이터의 구조(스키마)가 일관되지 않으면 재앙이 됩니다. 마케팅팀이 “매출”을 부가세 포함으로 정의하고, 재무팀이 부가세 제외로 정의하면, 피드백 루프는 엉뚱한 데이터를 보고 엉뚱한 판단을 내립니다.
Schema Registry는 모든 이벤트의 스키마를 중앙에서 관리합니다. Confluent Schema Registry가 대표적이며, 다음 기능을 제공합니다.
스키마 등록과 버전 관리: 이벤트 타입별로 스키마를 등록하고, 변경될 때마다 새 버전을 관리합니다. 어떤 시점에 어떤 스키마가 사용되었는지를 추적할 수 있습니다.
호환성 검증: 스키마가 변경될 때, 기존 데이터와 호환되는지를 자동으로 검증합니다. 필드를 추가하는 것은 괜찮지만(하위 호환), 기존 필드를 삭제하거나 타입을 변경하면 호환성이 깨집니다. Schema Registry가 이런 비호환 변경을 사전에 차단합니다.
직렬화/역직렬화 자동화: 이벤트를 보내고 받을 때 스키마에 맞춰 자동으로 직렬화/역직렬화합니다. Avro, Protobuf, JSON Schema 등의 포맷을 지원합니다. Avro가 스키마 진화(schema evolution)에 가장 유연하여 많이 사용됩니다.
마스터 데이터 관리(MDM)
통합 데이터 모델의 또 하나의 축은 마스터 데이터 관리입니다. “고객”이라는 엔티티가 시스템마다 다르게 정의되어 있으면, 고객 단위의 피드백 루프가 성립하지 않습니다. CRM에서는 이메일 기준, 결제 시스템에서는 카드번호 기준, 물류에서는 배송지 기준으로 고객을 식별한다면, 같은 고객의 행동이 세 명의 다른 사람으로 분산됩니다.
MDM은 이런 엔티티 식별자를 통합합니다. 고객 마스터, 상품 마스터, 거래처 마스터 같은 핵심 엔티티에 대해 “정답(Golden Record)”을 정의하고, 모든 시스템이 이 정답을 참조하도록 합니다. 기술적으로는 ID 매핑 테이블, 유사도 기반 엔티티 매칭, 그래프 기반 엔티티 해소(Entity Resolution) 등의 방법이 사용됩니다.
데이터 레이크: 이중 파이프라인 설계
사이버네틱 시스템의 데이터 레이크는 두 가지 성격의 데이터를 동시에 다뤄야 합니다.
핫 데이터(Hot Data)는 실시간 스트림입니다. 지금 일어나고 있는 이벤트, 현재 상태, 최근 수 시간~수일의 데이터. 인지 계층이 즉각적인 판단을 내리는 데 사용합니다. Redis, Apache Druid, ClickHouse 같은 실시간 분석 데이터베이스에 저장됩니다.
콜드 데이터(Cold Data)는 배치 저장소입니다. 수개월~수년에 걸친 이력 데이터. ML 모델을 학습시키거나, 장기 트렌드를 분석하거나, 메타 피드백 루프가 루프 전체의 효과를 평가할 때 사용합니다. S3, GCS, BigQuery, Snowflake 같은 저장소에 보관됩니다.
이 두 파이프라인이 동시에 작동해야 합니다. Kafka에서 실시간으로 핫 데이터 스토어에 흘려보내는 동시에, 같은 데이터를 배치로 묶어 콜드 스토어에 적재합니다. Lambda Architecture 또는 Kappa Architecture가 이 이중 파이프라인의 대표적인 설계 패턴입니다.
Lambda는 실시간 경로(Speed Layer)와 배치 경로(Batch Layer)를 분리하여 운영하고, 결과를 서빙 레이어에서 합칩니다. 안정적이지만 두 경로의 로직을 동기화해야 하는 부담이 있습니다. Kappa는 모든 것을 스트리밍으로 처리하고, 배치는 스트림 로그를 재생(replay)하는 방식으로 대체합니다. 단순하지만 대규모 재처리 시 부하가 큽니다. 최근에는 Kappa 기반에 필요한 부분만 배치를 보완하는 하이브리드 접근이 많이 사용됩니다.
상태 관리: Event Sourcing과 State Machine
사이버네틱 시스템은 “지금 시스템이 어떤 상태인지”를 항상 알고 있어야 합니다. 어떤 AI가 어떤 판단을 내렸고, 그 실행이 어디까지 진행됐고, 결과가 어떻게 되었는지.
Event Sourcing은 상태를 직접 저장하는 대신, 상태 변화의 이벤트 시퀀스를 저장합니다. “현재 가격은 10,000원이다”가 아니라 “원래 가격 12,000원 → 1차 조정 -1,000원 → 2차 조정 -1,000원”으로 기록합니다. 이렇게 하면 어떤 시점의 상태든 이벤트를 순서대로 재생하면 복원할 수 있고, “왜 이 상태가 되었는지”의 이력이 완전히 보존됩니다. 감사 로그와 자연스럽게 통합되는 장점도 있습니다.
State Machine은 시스템의 가능한 상태와 전이 조건을 명시적으로 정의합니다. 가격 최적화 루프의 경우: 데이터 수집 중 → 판단 대기 → 판단 완료 → 승인 대기 → 실행 중 → 실행 완료 → 피드백 수집 중 → 다시 데이터 수집 중. 각 상태에서 어떤 조건이 충족되면 다음 상태로 전이하는지를 명확히 정의합니다. 이렇게 하면 시스템이 예측 불가능한 상태에 빠지는 것을 방지할 수 있습니다.
Part 2: 인지 계층 (Brain Layer) 기술 상세
LLM 오케스트레이션 — 범용성의 열쇠
오케스트레이션이 필요한 이유
LLM을 단독으로 호출하는 것과, 사이버네틱 시스템의 두뇌로 사용하는 것은 완전히 다릅니다. 단독 호출은 “질문 → 답변”의 일회성 상호작용입니다. 사이버네틱 시스템에서는 LLM이 데이터를 받아 판단하고, 그 판단이 실행으로 이어지고, 결과가 다시 LLM에 피드백되어야 합니다. 그리고 이 과정에서 LLM이 어떤 데이터를 참조하고, 어떤 도구를 사용하고, 어떤 형식으로 결과를 출력하는지를 체계적으로 관리해야 합니다.
이것을 관리하는 것이 오케스트레이션입니다. LangChain, LlamaIndex 같은 프레임워크가 이 역할을 하지만, 사이버네틱 시스템에서의 오케스트레이션은 일반적인 LLM 애플리케이션보다 더 복잡한 요구사항이 있습니다.
프롬프트 관리 시스템
사이버네틱 시스템에서 LLM의 행동을 결정하는 것은 모델 자체가 아니라 프롬프트입니다. 같은 LLM이라도 프롬프트에 따라 마케팅 판단을 하기도 하고, 재고 관리 판단을 하기도 합니다. 프롬프트가 곧 업무 정의이고, 프롬프트를 바꾸면 업무가 바뀝니다. 그래서 프롬프트 관리는 코드 관리만큼 중요합니다.
버전 관리가 기본입니다. 프롬프트의 모든 변경을 버전으로 관리하고, 어떤 버전이 어떤 성과를 냈는지를 추적합니다. 피드백 루프에서 성과가 떨어지면 이전 버전의 프롬프트로 롤백할 수 있어야 합니다.
A/B 테스트가 핵심입니다. 프롬프트를 변경할 때, 모든 트래픽에 즉시 적용하는 것이 아니라 일부 트래픽에만 새 프롬프트를 적용하여 성과를 비교합니다. 이것이 프롬프트 수준의 피드백 루프입니다.
구조화된 출력도 중요합니다. LLM의 응답을 자유 텍스트로 받으면, 실행 계층에서 파싱하기 어렵습니다. JSON Schema, Function Calling 같은 기법을 사용하여 LLM의 출력을 구조화된 형식으로 강제합니다. “가격을 3% 할인하라”라는 자유 텍스트가 아니라, 상품 ID, 변경 유형, 변경 비율, 적용 기간이 명확히 구조화된 데이터로 출력되어야 실행 계층이 바로 처리할 수 있습니다.
가드레일 프롬프트는 안전 계층과의 접점입니다. 메인 판단 프롬프트와 별도로, “이 판단이 다음 조건을 위반하는지 검증하라”는 검증 프롬프트를 두어 이중 체크합니다. 마진 하한선, 법적 제약, 브랜드 가이드라인 같은 조건을 프롬프트 수준에서 검증하는 것입니다.
RAG (Retrieval-Augmented Generation) 파이프라인
LLM은 학습 데이터에 기반하여 일반적인 지식은 갖고 있지만, 우리 회사의 구체적인 상황은 모릅니다. 우리 상품의 재고 현황, 지난 캠페인의 성과, 경쟁사의 최신 동향 같은 것을 LLM이 알려면, 판단 시점에 관련 데이터를 찾아서 프롬프트에 함께 넣어줘야 합니다. 이것이 RAG입니다.
사이버네틱 시스템에서 RAG는 일반적인 챗봇 RAG보다 복잡합니다. 챗봇은 사용자 질문에 맞는 문서를 찾으면 되지만, 사이버네틱 시스템은 현재 상태 데이터, 과거 판단 이력, 실행 결과, 외부 환경 데이터를 종합적으로 검색해야 합니다.
벡터 검색은 의미적으로 관련 있는 정보를 찾습니다. “가격 최적화”라는 판단을 내릴 때, 과거에 유사한 상황에서 어떤 판단을 내렸고 결과가 어떠했는지를 벡터 유사도로 검색합니다. Pinecone, Weaviate, pgvector 같은 벡터 데이터베이스가 사용됩니다.
구조화 검색은 정확한 조건으로 데이터를 가져옵니다. “상품 A의 현재 재고 수량”이나 “지난 7일간 상품 A의 일별 판매량” 같은 것은 벡터 검색이 아니라 SQL이나 API 호출로 정확히 가져와야 합니다.
하이브리드 검색이 현실적입니다. 벡터 검색으로 맥락적 관련성을 찾고, 구조화 검색으로 정확한 수치를 가져와서, 둘을 조합하여 프롬프트를 구성합니다. “과거 유사 사례에서는 3% 할인이 전환율 12% 상승을 만들었고, 현재 재고는 500개이며, 경쟁사 가격은 9,800원이다”처럼 맥락과 데이터가 결합된 프롬프트가 정확한 판단의 근거가 됩니다.
컨텍스트 윈도우 관리
LLM에는 한 번에 처리할 수 있는 텍스트의 양(컨텍스트 윈도우)에 제한이 있습니다. 사이버네틱 시스템은 판단에 필요한 데이터량이 많기 때문에, 이 제한을 효율적으로 관리하는 전략이 필요합니다.
정보 압축은 원본 데이터를 그대로 넣는 대신, 핵심만 요약하여 넣는 것입니다. 1,000건의 고객 이벤트를 전부 넣는 대신, “최근 24시간 방문 432회, 구매 전환율 3.2%, 평균 체류 시간 4분 12초”로 압축합니다.
계층적 요약(Hierarchical Summarization)은 데이터가 방대할 때 사용합니다. 원본 데이터를 먼저 작은 단위로 요약하고, 요약을 다시 요약하여, 최종적으로 컨텍스트 윈도우에 들어갈 수 있는 크기로 줄입니다. 정보 손실이 있을 수 있으므로, 어떤 정보를 보존하고 어떤 정보를 버릴지의 기준이 중요합니다.
동적 컨텍스트 선택은 판단 유형에 따라 필요한 데이터만 선별적으로 가져오는 것입니다. 가격 판단에는 가격·경쟁·재고 데이터가 필요하지만 고객 서비스 이력은 필요 없습니다. 판단 유형별로 어떤 데이터가 필요한지를 사전에 정의하고, 해당 데이터만 컨텍스트에 포함시킵니다.
ML 모델 서빙 인프라
LLM과 전통 ML의 공존
인지 계층이 LLM만으로 구성되지는 않습니다. LLM은 범용적 판단, 자연어 기반 추론, 복합적 상황 해석에 강하지만, 정밀한 수치 예측(내일의 판매량 예측), 대규모 패턴 인식(이상 거래 탐지), 고속 분류(밀리초 단위 실시간 분류)에는 전통적인 ML 모델이 여전히 우수합니다.
현실적인 인지 계층은 LLM + 전통 ML의 앙상블입니다. 전통 ML 모델이 정밀한 예측값을 산출하고, LLM이 그 예측값을 다른 맥락 정보와 종합하여 최종 판단을 내리는 구조입니다. 예를 들어 수요 예측 모델이 “내일 판매량 120개 예상”이라는 수치를 산출하면, LLM이 “하지만 내일 비가 온다는 날씨 예보와 경쟁사 할인 행사를 고려하면 실제로는 80개에 그칠 수 있으니, 발주량을 90개로 조정하자”라는 종합 판단을 내리는 식입니다.
모델 서빙의 핵심 요구사항
멀티 모델 동시 운영: 여러 업무의 피드백 루프가 동시에 돌아가므로, 가격 예측 모델, 수요 예측 모델, 이탈 예측 모델 등이 동시에 서빙되어야 합니다. 각 모델은 독립적으로 배포, 업데이트, 스케일링이 가능해야 합니다. Kubernetes 기반의 모델 서빙(KServe, Seldon Core)이 이런 요구사항을 충족합니다.
A/B 테스트와 카나리 배포: 피드백 루프에서 모델이 재학습되면, 새 모델이 정말 더 나은지를 검증해야 합니다. 전체 트래픽의 10%만 새 모델로 보내고(카나리), 성과를 비교한 후 문제가 없으면 전체로 확대합니다.
모델 레지스트리: 모든 모델의 버전, 학습 데이터, 하이퍼파라미터, 성과 메트릭을 중앙에서 관리합니다. MLflow Model Registry가 대표적입니다. 문제가 발생하면 이전 버전으로 즉시 롤백할 수 있어야 합니다.
추론 지연 시간(Latency) 관리: 피드백 루프의 속도는 가장 느린 구성 요소에 의해 결정됩니다. 모델 추론이 느리면 전체 루프가 느려집니다. 모델 최적화(양자화, 프루닝), 배치 추론, GPU 가속, 캐싱 등의 기법으로 추론 지연을 관리해야 합니다.
멀티 에이전트 시스템 설계
왜 단일 에이전트가 아닌 멀티 에이전트인가
하나의 LLM에 모든 것을 맡기면 몇 가지 문제가 생깁니다. 프롬프트가 지나치게 길어져서 성능이 떨어지고, 서로 다른 관점(비용 절감 vs 고객 만족)이 하나의 프롬프트 안에서 충돌하고, 디버깅이 어렵습니다.
멀티 에이전트는 이것을 분업으로 해결합니다. 각 에이전트가 하나의 명확한 역할을 맡고, 서로 소통하면서 합의에 도달합니다. 에이전트 수가 적어 프롬프트가 간결하고, 역할이 분리되어 추적이 쉽고, 새로운 관점이 필요하면 에이전트를 추가하면 됩니다.
역할 분담 패턴
사이버네틱 시스템에서 효과적인 에이전트 역할 분담 패턴 몇 가지를 소개합니다.
분석-전략-검증 패턴이 가장 기본적입니다. 분석 에이전트가 데이터를 해석하고 현황을 파악합니다. 전략 에이전트가 분석 결과를 받아 행동 대안을 제시합니다. 검증 에이전트가 각 대안의 위험성과 실행 가능성을 평가합니다.
토론 패턴은 동일한 문제에 대해 서로 다른 관점을 가진 에이전트들이 토론하는 방식입니다. “비용 절감” 관점의 에이전트와 “고객 경험” 관점의 에이전트가 각자의 주장을 펼치고, 중재 에이전트가 합의점을 찾습니다. 단일 관점의 편향을 줄이는 데 효과적입니다.
계층적 패턴은 복잡한 판단을 분해하는 방식입니다. 상위 에이전트가 문제를 하위 문제로 분해하고, 각 하위 문제를 전문 에이전트에 할당하고, 결과를 다시 상위 에이전트가 통합합니다. 복잡한 판단을 관리 가능한 단위로 나누는 데 유리합니다.
에이전트 간 통신 설계
에이전트들이 소통하려면 통신 프로토콜이 필요합니다. 핵심 고려사항은 다음과 같습니다.
메시지 형식의 표준화: 에이전트 간 주고받는 메시지의 형식을 통일합니다. 발신 에이전트, 수신 에이전트, 메시지 유형(요청/응답/알림), 내용, 신뢰도(confidence score)를 포함하는 표준 메시지 포맷을 정의합니다.
오케스트레이터 vs 자율 통신: 에이전트 간 통신을 중앙의 오케스트레이터가 관리하는 방식과, 에이전트들이 직접 소통하는 방식이 있습니다. 오케스트레이터 방식이 흐름을 추적하기 쉽고 디버깅이 편하지만, 오케스트레이터가 병목이 될 수 있습니다. 자율 통신은 유연하지만 복잡합니다. 사이버네틱 시스템 초기에는 추적 가능성이 중요하므로 오케스트레이터 방식이 권장됩니다.
실패 처리: 에이전트 하나가 응답하지 않거나 비정상적인 결과를 내놓았을 때의 처리가 중요합니다. 타임아웃, 재시도, 대체 에이전트 호출, 디폴트 판단(안전한 기본값)의 전략을 사전에 정의해야 합니다.
컨텍스트 메모리 설계
단기 기억과 장기 기억
사람의 기억이 단기 기억(작업 기억)과 장기 기억으로 나뉘듯, 에이전트의 컨텍스트 메모리도 두 층으로 설계합니다.
단기 기억(Working Memory)은 현재 진행 중인 판단 사이클의 맥락입니다. “지금 상품 A에 대해 가격 판단을 하고 있고, 분석 에이전트가 이런 결과를 냈고, 전략 에이전트가 이런 대안을 제시했다”는 현재 세션의 정보입니다. Redis나 인메모리 저장소에 보관하며, 판단 사이클이 완료되면 정리됩니다.
장기 기억(Long-term Memory)은 과거 판단의 이력과 학습된 패턴입니다. “지난 3개월간 상품 A에 대해 12번 가격을 조정했고, 3% 이상 할인은 전환율은 올렸지만 마진을 과도하게 깎았다”는 누적된 경험입니다. 벡터 데이터베이스에 보관하며, RAG를 통해 관련 기억을 검색하여 현재 판단에 활용합니다.
기억의 중요도 가중치(Memory Importance Scoring)도 고려할 만합니다. 모든 과거 판단이 동일한 가치를 가지는 것은 아닙니다. 큰 성과를 낸 판단이나 큰 실패를 한 판단은 높은 중요도를 가지고, 평범한 판단은 낮은 중요도를 가집니다. 기억을 검색할 때 중요도 가중치를 반영하면, 핵심적인 과거 경험이 우선적으로 참조됩니다.
망각 메커니즘
기억이 무한히 쌓이면 검색 성능이 떨어지고, 오래된 기억이 현재 판단을 왜곡할 수 있습니다. 6개월 전의 시장 상황에 기반한 판단 기억이 현재 판단에 과도한 영향을 미치면 안 됩니다.
시간에 따라 기억의 가중치를 점진적으로 낮추는 시간 감쇠(Time Decay)를 적용합니다. 최근 기억일수록 높은 가중치, 오래된 기억일수록 낮은 가중치. 그리고 일정 기간이 지나면 상세 기억은 삭제하고 요약만 보존하는 기억 압축(Memory Consolidation)도 적용합니다. 개별 이벤트의 상세 기록은 삭제하되, “상품 A에 대한 할인 전략은 3% 이하가 최적이었다”는 학습된 패턴은 보존하는 것입니다.
감각과 두뇌의 연결: 데이터에서 판단까지의 흐름
두 계층을 각각 살펴봤으니, 마지막으로 둘이 어떻게 연결되는지를 정리하겠습니다.
전체 흐름은 이렇습니다.
외부 이벤트 발생 → 커넥터가 캡처 → 이벤트 스트리밍(Kafka)에 유입 → Schema Registry로 유효성 검증 → 통합 데이터 모델로 정규화 → 핫 데이터 스토어 + 콜드 데이터 레이크에 동시 적재 → 상태 저장소에 현재 상태 갱신
판단 트리거 발생 (이벤트 조건 충족, 스케줄, 또는 외부 요청) → RAG가 관련 데이터를 검색 (벡터 검색 + 구조화 검색) → 컨텍스트 메모리에서 과거 판단 이력 참조 → 프롬프트 조립 → LLM + ML 모델 앙상블 판단 → 멀티 에이전트 검증 → 구조화된 판단 결과 출력
→ 실행 계층으로 전달 (다음 편에서 계속)
이 흐름에서 핵심은, 감각 계층이 “깨끗하고 빠른 데이터”를 만들고, 인지 계층이 그 데이터를 기반으로 “맥락 있는 판단”을 내린다는 것입니다. 감각이 오염되면 판단이 오염되고, 감각이 느리면 판단이 늦습니다. 두 계층의 품질이 사이버네틱 시스템 전체의 품질을 결정합니다.
다음 편 예고
이번 편에서는 감각 계층과 인지 계층의 기술 상세를 다뤘습니다. 이벤트 스트리밍 설계부터 LLM 오케스트레이션, 멀티 에이전트, 컨텍스트 메모리까지.
다음 편 “손과 신경 — 실행·피드백·안전 메커니즘”에서는 레이어 3(실행), 레이어 4(피드백), 레이어 5(안전)를 기술적으로 깊이 파고듭니다. 의사결정 라우터의 분기 로직 설계, 워크플로우 엔진의 다단계 흐름 패턴, 자동 재학습 파이프라인의 트리거 조건, 메타 피드백 루프의 구현 방법, 그리고 피드백 루프 충돌 방지와 카오스 엔지니어링까지. 시스템이 실제로 행동하고, 스스로를 수정하고, 안전하게 작동하는 메커니즘을 상세히 다룹니다.
핵심 정리
감각 계층
- 이벤트 스트리밍(Kafka)은 실시간 파이프라인의 중추이며, 토픽 설계·파티셔닝·보존 정책이 핵심 설계 포인트이다
- 범용 커넥터 허브는 어댑터 패턴으로 새 데이터 소스를 플러그인 방식으로 추가한다
- Schema Registry가 데이터의 일관성을 보장하고, MDM이 엔티티 식별을 통합한다
- 핫 데이터(실시간)와 콜드 데이터(배치)의 이중 파이프라인이 동시에 작동해야 한다
- Event Sourcing과 State Machine으로 시스템 상태를 명시적으로 관리한다
인지 계층
- LLM 오케스트레이션이 범용성의 열쇠이며, 프롬프트 관리(버전·A/B 테스트·구조화 출력)가 핵심이다
- RAG는 벡터 검색 + 구조화 검색의 하이브리드로 설계한다
- LLM과 전통 ML의 앙상블이 현실적인 인지 구조이다
- 멀티 에이전트는 분석-전략-검증, 토론, 계층적 패턴으로 역할을 분담한다
- 컨텍스트 메모리는 단기 기억(Redis) + 장기 기억(Vector DB)의 이중 구조이며, 시간 감쇠와 기억 압축으로 관리한다