---
title: "아키텍처"
description: "4계층 모델(Module → Agent → Collaboration → Governance), 설계 원칙, 기존 방법론과의 관계를 다룬다."
canonical: "https://architecture.reopt.ai/ko/architecture"
language: "ko"
alternate-markdown: "https://architecture.reopt.ai/architecture.md"
site-index: "https://architecture.reopt.ai/llms.txt"
source: "reopt architecture"
---

# 아키텍처

> 4계층 모델(Module → Agent → Collaboration → Governance), 설계 원칙, 기존 방법론과의 관계를 다룬다.

제품의 실행 단위, 소유 주체, 협업 규칙, 거버넌스. 이 네 계층이 쌓이면서 구조가 완성된다. 각 계층은 이전 계층이 답할 수 없는 질문에 답한다.

## 왜 4계층인가

각 계층은 이전 계층이 답할 수 없는 질문에 답한다. 실행 단위(Module)만으로는 '누가 이 결과를 소유하는가'를 알 수 없어 소유 주체(Agent)가 필요하다. 소유 주체만으로는 '서로 어떻게 협업하는가'를 알 수 없어 협업 규칙(Collaboration)이 필요하다. 협업 규칙만으로는 '제품이 안전하게 진화하는가'를 알 수 없어 거버넌스(Governance)가 필요하다.

## 4 Layers

### Module — 모듈

실행 단위의 조건과 경계를 정의한다.

- **Responsibility:** 제품의 최소 실행 단위. 하나의 기능을 수행하고 결과를 반환한다.
- **Contract:** 입력 조건, 출력 형식, 권한 범위, 거절 조건을 계약으로 선언한다. 계약을 모델과 분리했으므로 모델을 교체해도 계약은 그대로 남는다.
- **Operation:** 호출 횟수, 비용, 결과 품질, 실패 사유를 추적한다.
- **관측 지표 예시:** 호출당 평균 비용, 실패율, 평균 응답 시간, 계약 위반 횟수
- **프로토콜 참조:** MCP Tool Definition — 입출력 스키마가 MCP의 tool schema와 동일한 역할

### Agent — 에이전트

결과를 소유하고 판단하는 주체.

- **Responsibility:** 결과를 소유하고 판단하는 주체. 하나 이상의 모듈을 사용해 목표를 달성한다.
- **Contract:** 목표, 권한 범위, 위임 가능 여부, 종료 조건을 선언한다.
- **Operation:** 판단 근거, 실행 단계, 승인 이벤트를 기록한다.
- **관측 지표 예시:** 목표 달성률, 평균 처리 시간, 협업 빈도, 에스컬레이션 비율
- **프로토콜 참조:** A2A Agent Card — 에이전트의 목표, 권한, 종료 조건을 선언

### Collaboration — 협업

주체 간 협업과 정보 전달 규칙.

- **Responsibility:** 주체 간 역할 분담, 정보 전달, 흐름 조율을 정의한다.
- **Contract:** 협업 규칙, 정보 전달 범위, 비용 배분 기준을 정의한다.
- **Operation:** 병목, 대기 시간, 재작업, 협업 실패를 모니터링한다.
- **관측 지표 예시:** 협업 실패율, 평균 대기 시간, 재작업 발생 빈도
- **프로토콜 참조:** A2A Task Lifecycle — 협업 흐름, 상태 전이, 정보 전달

### Governance — 거버넌스

평가, 승인, 비용 통제, 정책 집행의 운영 계층.

- **Responsibility:** 제품이 안전하게 진화하도록 평가, 승인, 비용 통제, 정책을 집행한다. 모델은 교체 가능한 부품으로 다루고, 전문성은 내부 trace와 private eval에 축적해 모델 주권을 지킨다.
- **Contract:** 가드레일, 승인 정책, 평가 기준, 보정 기준을 제공한다.
- **Operation:** 품질 편차, 정책 위반, 인간 개입 지점을 모니터링한다.
- **관측 지표 예시:** 가드레일 차단 횟수, 승인 대기 시간, 품질 점수 분포, 정책 위반율
- **프로토콜 참조:** 인프라 레벨 가드레일(OPA, RBAC) — 프로토콜보다 정책 집행 계층

_4계층의 목적은 제품을 잘게 나누는 것이 아니다. 결과를 누가 소유하고, 실패를 누가 감당하며, 개선을 어떻게 반복하는지를 설명 가능하게 만드는 것이다._

## AI 네이티브 제품의 전제

reopt architecture는 AI 네이티브 제품이 전통적 소프트웨어와 근본적으로 다르다는 전제 위에 서 있다.

- **비결정적 실행** — 같은 입력에 다른 출력이 나온다. 따라서 결과를 보장하는 것이 아니라 판단 조건과 거절 경계를 선언하는 것이 설계의 핵심이다.
- **소유의 이중성** — 결과의 소유자는 사람일 수도, AI일 수도 있다. 사람이 소유하면 맥락적 판단이 가능하지만, AI가 소유하면 모든 조건이 명시적이어야 한다. 이 구분이 거버넌스의 엄격도를 결정한다. 그리고 사람의 소유는 방어적 책임에 그치지 않는다. 야심찬 목표를 세우고 도메인을 잇는 방향 설정 자체가 소유의 능동적 절반이다.
- **자율성과 통제의 균형** — AI의 가치는 자율적 판단에서 나오지만, 통제 없는 자율성은 에이전틱 부채를 만든다. 자율성을 높이려면 먼저 구조를 정의해야 한다.
- **속도는 기본값, 구조는 선택** — AI가 MVP를 하루 만에 만들 수 있는 시대에, 속도는 차별화 요소가 아니다. 구조만이 지속 가능한 제품과 일회성 데모를 가른다.
- **구조가 곧 거버넌스** — 거버넌스를 별도 프로세스로 추가하면 팀은 이를 우회한다. 제품의 구조 자체가 거버넌스 역할을 해야 자연스럽게 작동한다.
- **주권은 모델이 아니라 루프에 있다** — 모델은 교체되지만 학습 루프는 남는다. 인간이 방향을 정하고 AI가 그것을 확장하면, 그 전문성은 어떤 모델이 와도 우리 것으로 축적된다. 통제할 대상은 모델이 아니라 모델 위에 쌓는 구조다.

## 이 아키텍처의 목표

- AI 제품이 커져도 누가 어떤 결과를 소유하는지 항상 설명 가능하게 한다.
- 판단 조건과 실패 경로를 계약으로 선언하여, 구조 자체가 거버넌스가 되게 한다.
- OCLS 루프를 통해 운영 데이터로 구조를 지속적으로 보정할 수 있게 한다.
- 팀 전체(프로덕트, 엔지니어링, 운영)가 같은 구조적 언어로 소통할 수 있게 한다.

## 이 아키텍처가 목표로 하지 않는 것

- 특정 프레임워크나 라이브러리의 사용법을 안내하지 않는다.
- 프롬프트 엔지니어링 기법을 다루지 않는다.
- 모델 선택이나 파인튜닝 전략을 제시하지 않는다.
- 조직 구조나 인사 체계의 변경을 요구하지 않는다.

## 에이전틱 부채 — 속도가 구조를 앞서면 쌓이는 부채

기술 부채는 느린 속도에서 쌓였다. 에이전틱 부채는 빠른 속도에서 쌓인다. AI가 빠르게 만들어줄수록 구조 없는 제품은 더 빠르게 블랙박스가 된다.

- **권한 확산** (OWN) — 에이전트가 늘어나면 누가 어떤 권한을 쥐고 있는지 추적하기 어렵다. 에이전트 ID, 접근 범위, 실행 권한이 암묵적으로 넓어지면서 보안 사고와 책임 공백이 함께 발생한다.
- **계약 공백** (CONTRACT) — 모듈과 에이전트의 입출력, 거절 조건, 실패 모드를 문서로 남기지 않은 채 운영한다. 모듈을 교체하거나 프롬프트를 바꿀 때 부작용을 예측하기 어렵고 평가 기준도 세우지 못한다.
- **관측 부재** (LAYER) — 에이전트의 추론 경로, 의사결정 근거, 핸드오프 사유를 기록하지 않는다. 장애가 나도 원인을 짚지 못하고 추론 과정 전체가 불투명하게 남는다.
- **검증 부족** (SHARPEN) — 평가 기준과 가드레일이 없거나 형식만 갖춘다. 품질 편차가 벌어지고 위험한 동작은 사후에야 드러나며 개선으로 이어질 피드백 루프가 끊긴다.

## 설계 원칙

아래 원칙이 유지되지 않으면 reopt architecture는 다시 기능 중심 자동화 묶음으로 퇴행한다.

- **기능이 아니라 책임 단위로 설계한다** — 에이전트는 함수 호출기가 아니라 결과를 끝까지 책임지고 설명하는 주체다.
- **모듈은 호출 가능한 도구가 아니라 계약을 지키는 실행 단위다** — 모듈에 계약이 있어야 평가, 교체, 권한 제어, 테스트가 가능해진다.
- **확장은 분류하고 구조화해 거버넌스할 때 가능하다** — 에이전트가 늘어날수록 카테고리·계층·경계로 구조화해야 거버넌스가 유지되고 확장도 이어진다.
- **아키텍처는 운영 중 진화하는 시스템이다** — 실패 로그와 평가 결과를 보고 책임 경계와 정책을 계속 조정한다.

## 기존 방법론과의 관계

reopt architecture는 기존 소프트웨어 아키텍처의 통찰을 계승하되, AI 에이전트의 비결정적 실행과 거버넌스 요구에 맞게 확장한다.

### DDD — Bounded Context

- **공통점:** 책임 경계를 명시적으로 분리하고 경계 간 통신을 구조화한다는 점에서 Bounded Context와 Responsibility Boundary는 같은 문제를 다룬다.
- **차별점:** DDD의 Bounded Context는 도메인 모델의 일관성을 위한 정적 경계다. reopt architecture의 책임 경계는 비결정적으로 실행되는 에이전트를 위해 설계되며, 운영 데이터에 따라 동적으로 조정된다. 또한 DDD는 거버넌스를 아키텍처의 일부로 다루지 않지만, reopt architecture는 거버넌스 계층을 기본 구조로 포함한다.

### 마이크로서비스 — Service Contract

- **공통점:** 서비스 간 계약 기반 인터페이스를 정의한다는 점에서 Service Contract와 Module Contract는 동일한 원리를 공유한다.
- **차별점:** 마이크로서비스의 계약은 주로 성공 경로의 입출력 스키마에 집중한다. reopt architecture의 Module Contract는 실패 조건, 거절 로직, 권한 범위를 필수 요소로 포함한다. AI 에이전트는 결정론적이지 않으므로 '언제 거절해야 하는가'가 '무엇을 반환하는가'만큼 중요하다.

### Conway's Law

- **공통점:** 시스템 구조가 조직 구조를 반영한다는 관찰은 에이전트 시스템에도 적용된다. 에이전트 간 협업 구조가 곧 시스템 아키텍처가 된다.
- **차별점:** Conway's Law는 조직 구조가 시스템에 수동적으로 반영되는 현상을 설명한다. reopt architecture는 이를 뒤집어 에이전트 조직을 의도적으로 설계함으로써 시스템 구조를 결정한다. Responsibility Partitioning 패턴이 이 의도적 설계의 구체적 방법이다.

### Anthropic — Brain/Hands/Memory 분리

- **공통점:** 시스템을 독립적으로 진화할 수 있는 구성요소로 분리한다는 원칙을 공유한다. Anthropic의 Session(기억)·Harness(두뇌)·Sandbox(손) 3분리는 reopt architecture의 4계층 모델과 구조적으로 대응한다.
- **차별점:** Anthropic의 분리는 인프라 운영 관점(컨테이너 장애 복원, 보안 격리, 배포 독립성)에서 도출되었다. reopt architecture의 4계층은 거버넌스 관점(책임 귀인, 계약 검증, 협업 조율, 정책 집행)에서 도출되었다. 또한 reopt architecture는 Collaboration(협업 조율) 계층을 따로 분리해 에이전트 간 핸드오프와 컨텍스트 전달 규칙을 독립적 설계 대상으로 다룬다.

## 구현 패턴과의 관계

reopt architecture의 거버넌스 패턴은 Google의 멀티에이전트 구현 패턴 등과 상호 보완적이다. 거버넌스 패턴이 "무엇을 지켜야 하는가"를, 구현 패턴이 "어떻게 만들 것인가"를 답한다.

| 거버넌스 패턴 | 구현 패턴 | 연결 방식 |
| --- | --- | --- |
| Responsibility Partitioning — 책임 분할 | Hierarchical Decomposition, Parallel Fan-out/Gather | 상위 에이전트가 목표를 하위 책임으로 분해하고 위임하는 구조. 병렬 처리가 가능한 책임은 Fan-out으로, 순차 의존성이 있는 책임은 Hierarchical로 구현한다. |
| Module Contract — 모듈 계약 | Spec-Driven Development | 계약의 입출력 스키마가 실행 가능한 스펙이 되어 코드, 문서, mock을 자동 생성한다. MCP Tool Definition이 모듈 계약의 구현 형태가 될 수 있다. |
| Context Routing — 컨텍스트 라우팅 | Sequential Pipeline, Routing Pattern | 파이프라인의 각 단계에서 다음 에이전트에 전달할 컨텍스트를 필터링·구조화하는 규칙. Routing Pattern은 문의 유형에 따라 적절한 에이전트로 분기하는 구현. |
| State and Memory Control — 상태와 기억 제어 | Session Store / Vector Memory | 주로 인프라 설계 영역이다. 세션 스토어(단기)와 벡터 DB/지식 베이스(장기)의 분리, 읽기/쓰기 권한 제어가 핵심 구현 과제. |
| Evaluation and Guardrails — 평가와 가드레일 | Generator-Critic, Evaluator-Optimizer | 생성 에이전트의 출력을 검증 에이전트가 평가하는 구조. 사전 가드레일은 실행 전 차단, 사후 평가는 Generator-Critic 루프로 구현한다. |
| Human Approval — 인간 승인 | Human-in-the-Loop | 비동기 승인 큐와 승인/거절 콜백이 핵심 구현 요소. 승인 대기 중에도 다른 작업을 계속하는 비동기 구조를 기본으로 한다. |
| Cost Control — 비용 통제 | Token Budget Management, Model Routing | 경로별 모델 선택(고위험=고성능, 저위험=경량), 에이전트별 토큰 예산 할당, 캐시·배치 전략을 묶어 비용 곡선을 통제한다. |
| Decision Traceability — 의사결정 추적 | Structured Logging, Distributed Tracing | 에이전트별 의사결정 로그를 구조화된 형태(JSON, OpenTelemetry spans)로 수집하고 인과 관계까지 추적하는 트레이싱 인프라를 구현한다. |

---

_이 문서는 https://architecture.reopt.ai/ko/architecture 의 마크다운 표현이다. 전체 색인: https://architecture.reopt.ai/llms.txt HTML 원본: https://architecture.reopt.ai/ko/architecture · English: https://architecture.reopt.ai/architecture.md_