시스템은
우연히 안정되는 것이 아니다.
안정은
결과가 아니라
의도의 반영이다.
Intent-Driven Architecture는
성능을 높이는 구조도 아니고,
문제를 즉시 해결하는 구조도 아니다.
이 구조의 목적은 단 하나다.
설계자가 의도한 방향이
시간이 지나도
물리 흐름에서 사라지지 않게 하는 것.
1. 대부분의 시스템은 ‘의도’를 잃는다
처음 설계될 때
모든 시스템에는 분명한 의도가 있다.
- 어떤 조건을 우선할 것인가
- 무엇을 보호할 것인가
- 어디까지 허용할 것인가
- 언제 양보할 것인가
하지만 시간이 흐르면
시스템은 다른 모습이 된다.
부하가 늘고
패치가 쌓이고
예외 처리가 누적되고
운용 조건이 바뀌면서
초기의 의도는 점점 흐려진다.
결국 많은 시스템은
이 상태에 도달한다.
“왜 이렇게 동작하는지
아무도 정확히 설명하지 못하는 구조”
Intent-Driven Architecture는
이 붕괴를 막기 위해 등장한다.
2. Intent-Driven Architecture는 규칙이 아니다
중요한 전제가 있다.
Intent-Driven Architecture는
규칙(rule)을 추가하지 않는다.
정책(policy)을 늘리지 않는다.
제어 로직을 위에 덧붙이지 않는다.
대신
의도를 구조로 바꾼다.
즉,
- “이렇게 해야 한다”가 아니라
- “이 방향으로 흐르게 만든다”
의도는 명령이 아니라
물리적 경향성이 된다.
3. 의도는 선언이 아니라 경로다
많은 설계 문서에는
이런 문장이 있다.
- 안정성을 최우선으로 한다
- 성능 저하는 허용하지 않는다
- 오류는 국부화한다
하지만 선언은
흐름을 바꾸지 못한다.
Intent-Driven Architecture에서
의도는
선언문이 아니라 경로 선택 기준이다.
시스템이 선택의 기로에 섰을 때
어느 쪽으로 흘러갈지를
구조적으로 강제한다.
4. Intent가 사라지는 순간들
의도는 보통
다음 순간들에서 사라진다.
- 정상 상태가 아닌 구간
- 경계 조건에 진입했을 때
- 복구 중인 상태
- 예외 처리 루트
- 확장·증설 직후
아이러니하게도
가장 중요한 순간에
의도는 가장 먼저 무너진다.
그래서 Intent-Driven Architecture는
정상 상태가 아니라
비정상 전환 구간에 초점을 둔다.
5. Intent-Driven Architecture의 핵심 질문
이 구조는
다섯 가지 질문에 답한다.
- 이 시스템은 무엇을 지키기 위해 만들어졌는가
- 어떤 상황에서도 절대 양보하지 않을 기준은 무엇인가
- 불안정이 발생했을 때 무엇을 먼저 포기할 것인가
- 회복 과정에서 무엇을 우선 복원할 것인가
- 확장 시에도 이 선택 기준이 유지되는가
이 질문의 답이
코드가 아니라
흐름에 녹아 있을 때
의도는 유지된다.
6. 핵심 구성 요소
① Intent Definition Layer
— 설계 의도 정의 계층
이 계층은
성능 수치나 조건이 아니라
우선순위 관계를 정의한다.
- 안정 > 속도
- 지속성 > 순간 효율
- 전체 신뢰도 > 국부 성능
이 정의는
정책이 아니라
이후 모든 구조 판단의 기준점이 된다.
② Flow-Biasing Structure
— 흐름 편향 구조
의도는
중립적인 시스템에서는
항상 패배한다.
그래서 이 구조는
특정 방향으로
흐름이 더 쉽게 가도록 만든다.
- 위험한 경로는 길게
- 안전한 경로는 짧게
- 복구 경로는 항상 열어둠
시스템은
가장 저항이 적은 쪽으로 흐른다.
Intent-Driven Architecture는
저항 분포를 설계한다.
③ Conflict Resolution Matrix
— 의도 충돌 해소 구조
현실의 시스템에서는
의도가 충돌한다.
- 성능 vs 안정
- 응답성 vs 보호
- 확장성 vs 단순성
이 구조는
충돌 시
미리 정해진 선택 방향으로만
해결되게 만든다.
즉,
운용자가 고민하지 않아도
시스템이 대신 선택한다.
④ Intent Persistence Layer
— 의도 지속 계층
시간은
모든 구조를 변형시킨다.
이 계층은
다음 요소를 감시한다.
- 설계 당시 의도와 현재 흐름의 괴리
- 반복적으로 의도가 무시되는 구간
- 예외 처리 루트의 비정상 확대
의도가 훼손되기 시작하면
경고가 아니라
구조적 수정 신호를 발생시킨다.
⑤ Intent Recovery Interface
— 의도 복원 인터페이스
의도는
깨질 수 있다.
하지만 복원되지 않으면
설계는 끝난다.
이 인터페이스는
시스템 회복 시
단순한 정상화가 아니라
의도 기준 복원을 수행한다.
- 성능이 아니라 방향을 복구
- 수치가 아니라 관계를 회복
7. Intent-Driven Architecture의 실제 흐름
1단계
운용 중 예외 발생
2단계
의도 기준에 따라 경로 분기
3단계
불안정 국부화 및 영향 제한
4단계
회복 시 의도 우선순위 재적용
5단계
정상 상태 복귀 후 의도 일관성 검증
이 과정에서
시스템은 변하지만
방향은 바뀌지 않는다.
8. 이전 Architecture들과의 연결
Intent-Driven Architecture는
독립 구조가 아니다.
- Transient Load Absorption
→ 충격을 흡수한다 - Threshold Protection
→ 한계를 넘지 않게 한다 - Waveform Normalization
→ 흐름을 정상화한다 - Fast Recovery
→ 빠르게 돌아온다 - Instability Isolation
→ 퍼지지 않게 막는다
그리고 마지막으로
Intent-Driven Architecture
→ 왜 이 선택을 했는지를 끝까지 유지한다
즉,
이 구조는
모든 안정화 구조의 의미를 고정한다.
9. 이 구조가 없을 때 벌어지는 일
Intent-Driven Architecture가 없으면
시스템은 이렇게 변한다.
- 점점 복잡해진다
- 설명할 수 없는 예외가 늘어난다
- 유지보수가 설계자를 배신한다
- “일단 돌아가게 하자”가 기준이 된다
결국 시스템은
작동하지만
설계되지 않은 상태가 된다.
10. Intent-Driven Architecture가 만드는 차이
이 구조가 있는 시스템은
- 오래 운용될수록 설명이 쉬워지고
- 확장할수록 방향이 명확해지며
- 문제가 생길수록 설계 의도가 드러난다
변하지 않아서가 아니다.
변하면서도
방향을 잃지 않기 때문에
신뢰가 쌓인다.
정리
설계는
완성되는 순간 끝나지 않는다.
운용이 시작되는 순간부터
설계는 시험대에 오른다.
Intent-Driven Architecture는
그 시험에서
끝까지 버티는 구조다.
의도를 말로 남기지 않는다.
의도를 문서에 남기지 않는다.
의도를
전력의 흐름으로,
신호의 경로로,
복구의 순서로
직접 새겨 넣는다.
그래서 이 구조가 있는 시스템은
시간이 지나도
설계자의 그림을 배신하지 않는다.
여기까지 오면
이것은 철학이 아니다.
완결된 설계 체계다.
—
이 글은
현재 기술 구조를 판단하기 위한 기준 기록의 일부입니다.
전체 기준 구조는 Current Architecture Overview에 정리되어 있습니다