ARCHITECTURE
제품의 실행 단위, 소유 주체, 협업 규칙, 거버넌스 — 네 계층이 쌓이면서 구조가 완성된다. 각 계층은 이전 계층이 답할 수 없는 질문에 답한다.
AI 네이티브 제품의 전제
reopt architecture는 AI 네이티브 제품이 전통적 소프트웨어와 근본적으로 다르다는 전제 위에 서 있다.
비결정적 실행
같은 입력에 다른 출력이 나온다. 따라서 결과를 보장하는 것이 아니라 판단 조건과 거절 경계를 선언하는 것이 설계의 핵심이다.
소유의 이중성
결과의 소유자는 사람일 수도, AI일 수도 있다. 사람이 소유하면 맥락적 판단이 가능하지만, AI가 소유하면 모든 조건이 명시적이어야 한다. 이 구분이 거버넌스의 엄격도를 결정한다.
자율성과 통제의 균형
AI의 가치는 자율적 판단에서 나오지만, 통제 없는 자율성은 에이전틱 부채를 만든다. 자율성을 높이려면 먼저 구조를 정의해야 한다.
속도는 기본값, 구조는 선택
AI가 MVP를 하루 만에 만들 수 있는 시대에, 속도는 차별화 요소가 아니다. 구조만이 지속 가능한 제품과 일회성 데모를 가른다.
구조가 곧 거버넌스
거버넌스를 별도 프로세스로 추가하면 팀은 이를 우회한다. 제품의 구조 자체가 거버넌스 역할을 해야 자연스럽게 작동한다.
이 아키텍처의 목표
- AI 제품이 커져도 누가 어떤 결과를 소유하는지 항상 설명 가능하게 한다.
- 판단 조건과 실패 경로를 계약으로 선언하여, 구조 자체가 거버넌스가 되게 한다.
- OCLS 루프를 통해 운영 데이터로 구조를 지속적으로 보정할 수 있게 한다.
- 팀 전체(프로덕트, 엔지니어링, 운영)가 같은 구조적 언어로 소통할 수 있게 한다.
이 아키텍처가 목표로 하지 않는 것
- 특정 프레임워크나 라이브러리의 사용법을 안내하지 않는다.
- 프롬프트 엔지니어링 기법을 다루지 않는다.
- 모델 선택이나 파인튜닝 전략을 제시하지 않는다.
- 조직 구조나 인사 체계의 변경을 요구하지 않는다.
구조 없는 속도의 함정
AI가 하루 만에 MVP를 만들 수 있다. 하지만 3개월 뒤 그 제품이 왜 그런 판단을 했는지 아무도 모른다면, 속도는 독이 된다.
프롬프트만으로는 구조가 되지 않는다
프롬프트를 아무리 다듬어도 누가 이 결과를 소유하는지, 실패하면 어떻게 되는지 답할 수 없다.
빠르게 만들수록 빠르게 블랙박스가 된다
데모는 하루면 되지만, 비용·품질·승인·책임이 뒤엉키면 3개월 안에 아무도 설명할 수 없는 제품이 된다.
데모에서 프로덕션으로 가는 길이 없다
초기 데모는 쉽다. 하지만 팀 단위 운영과 반복 개선으로 넘어가는 구조적 경로가 없으면 데모에서 멈춘다.
왜 4계층인가
각 계층은 이전 계층이 답할 수 없는 질문에 답한다. 실행 단위(Module)만으로는 '누가 이 결과를 소유하는가'를 알 수 없어 소유 주체(Agent)가 필요하다. 소유 주체만으로는 '서로 어떻게 협업하는가'를 알 수 없어 협업 규칙(Collaboration)이 필요하다. 협업 규칙만으로는 '제품이 안전하게 진화하는가'를 알 수 없어 거버넌스(Governance)가 필요하다.
| Layer | Responsibility | Contract | Operations | 관측 지표 예시 | 프로토콜 참조 |
|---|---|---|---|---|---|
| Module | 제품의 최소 실행 단위. 하나의 기능을 수행하고 결과를 반환한다. | 입력 조건, 출력 형식, 권한 범위, 거절 조건을 계약으로 선언한다. | 호출 횟수, 비용, 결과 품질, 실패 사유를 추적한다. | 호출당 평균 비용, 실패율, 평균 응답 시간, 계약 위반 횟수 | MCP Tool Definition — 입출력 스키마가 MCP의 tool schema와 동일한 역할 |
| Agent | 결과를 소유하고 판단하는 주체. 하나 이상의 모듈을 사용해 목표를 달성한다. | 목표, 권한 범위, 위임 가능 여부, 종료 조건을 선언한다. | 판단 근거, 실행 단계, 승인 이벤트를 기록한다. | 목표 달성률, 평균 처리 시간, 협업 빈도, 에스컬레이션 비율 | A2A Agent Card — 에이전트의 목표, 권한, 종료 조건을 선언 |
| Collaboration | 주체 간 역할 분담, 정보 전달, 흐름 조율을 정의한다. | 협업 규칙, 정보 전달 범위, 비용 배분 기준을 정의한다. | 병목, 대기 시간, 재작업, 협업 실패를 모니터링한다. | 협업 실패율, 평균 대기 시간, 재작업 발생 빈도 | A2A Task Lifecycle — 협업 흐름, 상태 전이, 정보 전달 |
| Governance | 제품이 안전하게 진화하도록 평가, 승인, 비용 통제, 정책을 집행한다. | 가드레일, 승인 정책, 평가 기준, 보정 기준을 제공한다. | 품질 편차, 정책 위반, 인간 개입 지점을 모니터링한다. | 가드레일 차단 횟수, 승인 대기 시간, 품질 점수 분포, 정책 위반율 | 인프라 레벨 가드레일(OPA, RBAC) — 프로토콜보다 정책 집행 계층 |
4계층의 목적은 제품을 잘게 나누는 것이 아니다. 결과를 누가 소유하고, 실패를 누가 감당하며, 개선을 어떻게 반복하는지를 설명 가능하게 만드는 것이다.
설계 원칙
아래 원칙이 유지되지 않으면 reopt architecture는 다시 기능 중심 자동화 묶음으로 퇴행한다.
Own Every Outcome
기능이 아니라 책임 단위로 설계한다
에이전트는 기능 호출기가 아니라 지속적으로 설명 가능한 책임 주체여야 한다.
Contract First
모듈은 호출 가능한 도구가 아니라 계약을 가진 실행 단위다
모듈이 계약을 가져야 평가, 교체, 권한 제어, 테스트가 가능한 구조가 된다.
Layer, Then Scale
확장은 분류·구조화를 통해 거버넌스될 때 가능하다
에이전트가 늘어날수록 카테고리·계층·경계로 구조화해야 거버넌스가 유지되고 확장이 지속 가능해진다.
Sharpen in Operation
아키텍처는 운영 중 진화하는 시스템이다
실패 로그와 평가 결과를 바탕으로 책임 경계와 정책을 계속 조정해야 한다.
Thinking Vocabulary
네 가지 사고 도구. 각 개념은 설계 결정의 렌즈이자, OCLS 거버넌스 루프의 한 단계에 대응한다.
OWN
Own Every Outcome
모든 결과를 소유하라
모든 결과물에 소유자를 지정하되, 소유자가 사람인지 AI인지 명시한다. 사람이 소유하면 맥락적 판단이 가능하고, AI가 소유하면 모든 조건을 계약으로 선언해야 한다. 소유 주체의 종류가 거버넌스의 엄격도를 결정한다.
구축 전에 모든 결과물에 소유자를 지정하고, 사람/AI 여부를 명시하라.
이 결과물의 소유자는 사람인가, AI인가? 그리고 문제가 생기면 누구에게 에스컬레이션하는가?
CONTRACT
Contract First
계약을 먼저 정의하라
구현 전에 입력, 출력, 권한, 거절 조건을 선언하면 평가·교체·통제가 가능해진다. AI가 소유하는 결과물일수록 계약이 더 엄격하고 명시적이어야 한다. 계약이 곧 거버넌스의 언어다.
계약을 쓸 수 있다면 책임을 이해한 것이다.
이 모듈이 거절해야 하는 입력은 무엇인가? 답할 수 있다면 계약이 완성된 것이다.
LAYER
Layer, Then Scale
계층이 확장을 만든다
에이전트가 늘어나도 카테고리·계층·경계로 구조화하면 거버넌스가 유지된다. 계층화가 곧 확장 전략이다. Google과 MIT의 멀티에이전트 스케일링 연구(2026, InfoQ 보도)는 태스크 의존성 구조가 핵심임을 실증했다 — 도구 협응이 많은 태스크에서는 멀티에이전트 오버헤드가 오히려 성능을 떨어뜨리며, 최적 협업 전략은 태스크에 따라 달라진다.
새 에이전트를 만들기 전에, 기존 카테고리의 어디에 속하는지 먼저 결정하라.
이 에이전트는 4계층 모델의 어느 계층에서 동작하며, 기존 에이전트와 어떤 관계인가?
SHARPEN
Sharpen in Operation
운영에서 경계를 조정하라
운영 데이터를 기반으로 경계를 조정하면 거버넌스가 현실에 맞게 진화한다. Anthropic의 [Demystifying Evals for AI Agents]는 평가를 먼저 정의하면 제품 요구사항의 모호함이 구현 전에 드러난다는 eval-driven development 관점을 제시한다. Capability eval이 regression eval로 졸업하는 시점이 경계가 안정화된 시그널이다.
잠정적 경계로 출발하고, 운영 데이터로 분할·병합·재분류를 결정하라.
최근 운영 데이터에서 경계 조정의 시그널이 있는가? 핸드오프 실패, 책임 공백, 비용 이상이 그 시그널이다.
OCLS Loop
Own → Contract → Layer → Sharpen. 거버넌스 설계의 순환 모델이다. 한 바퀴를 돌 때마다 거버넌스 경계가 선명해진다.
Contract First와 Sharpen in Operation은 모순이 아니다. 계약은 잠정적이다. 운영 데이터가 계약을 갱신한다. SHARPEN 단계에서 발견된 시그널(핸드오프 실패, 책임 공백, 비용 이상)이 다음 OWN 단계를 촉발하며, 이때 기존 계약과 경계가 재검토된다.
개발 수명주기에서의 OCLS
기존 SDLC는 에이전트의 비결정적 실행과 거버넌스 요구를 다루지 않는다. OCLS 루프는 Agentic SDLC(ASDLC)의 거버넌스 레이어로 동작한다. Design Loop에서 OWN + CONTRACT, Run Loop에서 LAYER, Governance Loop에서 SHARPEN이 각각 실행된다. 핵심 차이: ASDLC는 '에이전트가 해야 할 것'뿐 아니라 '절대 하면 안 되는 것'(거절 조건, 가드레일)을 설계 단계에서 명시한다.
설계 리뷰 체크리스트
One Question을 각 계층에 적용하면 구체적인 검증 질문이 된다. 설계 리뷰, 스프린트 시작, 장애 복기에서 이 체크리스트를 사용한다.
CONTRACT
Module모듈
- 이 모듈의 입력, 출력, 실패 조건이 명시적으로 정의되어 있는가?
- 이 모듈이 거절해야 하는 입력은 무엇인가?
- 계약 위반을 런타임에서 감지할 수 있는가?
OWN
Agent에이전트
- 이 에이전트의 책임 범위를 한 문장으로 설명할 수 있는가?
- 목표, 권한 범위, 종료 조건이 선언되어 있는가?
- 이 에이전트가 실패하면 누구에게 에스컬레이션하는가?
LAYER
Collaboration협업
- 핸드오프 시 전달되는 컨텍스트가 필요 최소한인가?
- 에이전트 간 협업 규칙(순서, 조건, 복구 경로)이 명시적인가?
- 핸드오프 실패 시 재시도 또는 대안 경로가 정의되어 있는가?
SHARPEN
Governance거버넌스
- 평가 기준이 정량적으로 정의되어 있는가?
- 고위험 작업의 인간 승인 기준이 명시적인가?
- 모든 의사결정을 사후에 추적할 수 있는가?
에이전틱 부채 — 속도가 구조를 앞서면 쌓이는 부채
기술 부채는 느린 속도에서 쌓였다. 에이전틱 부채는 빠른 속도에서 쌓인다. AI가 빠르게 만들어줄수록 구조 없는 제품은 더 빠르게 블랙박스가 된다.
OWN
Authority Sprawl
권한 확산
에이전트가 늘어나면서 누가 어떤 권한을 가지는지 추적할 수 없게 된다. 에이전트 ID, 접근 범위, 실행 권한이 암묵적으로 확장되어 보안 사고와 책임 공백이 동시에 발생한다.
CONTRACT
Contract Gap
계약 공백
모듈과 에이전트의 입출력, 거절 조건, 실패 모드가 문서화되지 않은 채 운영된다. 모듈 교체나 프롬프트 변경 시 부작용을 예측할 수 없고, 평가 기준도 세울 수 없다.
LAYER
Observability Gap
관측 부재
에이전트의 추론 경로, 의사결정 근거, 핸드오프 사유가 기록되지 않는다. 장애 발생 시 원인을 특정할 수 없고, 시스템 전체가 블랙박스가 된다.
SHARPEN
Validation Gap
검증 부족
평가 기준과 가드레일이 부재하거나 형식적으로만 존재한다. 품질 편차가 커지고, 위험한 동작이 사후에야 발견되며, 개선을 위한 피드백 루프가 끊어진다.
진화 경로
1. 단일 에이전트 시작
작은 범위에서 AI 자동화를 시작하며 기본 계약과 로그를 축적한다.
전환 시그널
- 하나의 에이전트가 여러 역할을 동시에 수행하면서 어떤 역할이 실패 원인인지 구분할 수 없을 때
- 프롬프트 변경이 의도하지 않은 다른 기능에 영향을 미칠 때
- 모듈별 성공률과 비용을 개별 추적할 수 있는 로그가 충분히 쌓였을 때
핵심 산출물
- 모듈별 입출력 계약 초안
- 기본 실행 로그 (호출 횟수, 비용, 성공/실패)
- 역할 간 충돌이 관측된 지점 목록
엔터프라이즈 보안 기준선 확보 — 에이전트 ID, 최소 권한 원칙, 기본 감사 로그
2. 책임 분리
플래닝, 실행, 검토, 배포처럼 충돌하는 역할을 분리해 책임 경계를 선명하게 만든다.
전환 시그널
- 분리된 에이전트 간 핸드오프에서 컨텍스트 누락이나 중복이 반복될 때
- 단일 에이전트로는 처리할 수 없는 병렬 작업이 필요할 때
- 각 에이전트의 독립적 평가와 개선이 가능한 상태가 되었을 때
핵심 산출물
- 에이전트별 책임 정의서
- 핸드오프 규칙과 컨텍스트 전달 스키마
- 에이전트별 독립 평가 기준
엔터프라이즈 컴플라이언스 경계 — 역할별 데이터 접근 범위, PII 처리 정책
3. 멀티에이전트 협업
협업 규칙과 정보 전달 체계를 정의해 제품 흐름을 안정화한다.
전환 시그널
- 협업 흐름이 안정적이지만 품질 편차가 크거나, 비용이 예측 불가능할 때
- 에이전트가 허용 범위를 넘는 동작을 하거나, 인간 승인이 필요한 상황이 자주 발생할 때
- 시스템 규모가 커져 거버넌스 규칙을 명시적으로 집행해야 할 때
핵심 산출물
- 안정화된 협업 흐름도
- 컨텍스트 라우팅 규칙
- 상태/기억 분리 정책
엔터프라이즈 기존 시스템 연동 — SSO/OIDC, 기존 승인 워크플로우 통합, API 게이트웨이
4. 거버넌스 내재화
평가, 승인, 비용 통제, 정책 집행을 제품의 기본 구조로 내재화한다.
전환 시그널
- OCLS 루프가 상시 운영 체계로 동작하며, 정기적으로 경계와 계약이 갱신될 때
- 거버넌스 지표(품질 점수, 비용, 정책 위반율)가 안정적으로 추적되고 있을 때
핵심 산출물
- 자동화된 평가와 가드레일 파이프라인
- 승인 분류 매트릭스와 에스컬레이션 규칙
- OCLS 루프 기반 정기 리뷰 프로세스
엔터프라이즈 자동화된 감사 — RBAC, 감사 추적 자동화, 정기 거버넌스 리뷰
운영 루프
Design Loop
역할 설계, 계약 정의, 실패 시나리오 명세를 통해 책임 경계를 먼저 고정한다.
Run Loop
실행 로그, 품질 점수, 비용 신호를 수집해 병목과 불필요한 협업을 식별한다.
Governance Loop
평가 기준, 승인 정책, 예외 처리를 조정하며 시스템을 안전하게 확장한다.