서버 아키텍처 동향: 새 기술보다 채택 조건을 먼저 보기¶

스무 가지 흐름을 한 번에 외우는 글이 아니라, 지금 겪는 문제와 가까운 항목을 찾기 위한 참조 지도입니다.

참조 지도 · 필요한 항목을 골라 읽으세요

어떤 유행을 믿어야 할까¶

아키텍처 트렌드는 새 제품의 인기 순위가 아니다. 여러 팀이 반복해서 겪은 운영 문제와, 그 문제를 다른 경계로 옮기려는 공통된 선택이다. 같은 구조도 조직 규모와 장애 비용이 다르면 해법이 되거나 과잉 설계가 된다.

2026년 CNCF 기술 레이더도 특정 도구 하나의 승리보다 플랫폼 엔지니어링 도구의 성숙과 AI 작업을 기존 플랫폼에 결합하는 여러 방식을 보여 준다. 조사에 참여한 조직의 상황이 모든 팀을 대표하는 것은 아니지만, “마이크로서비스를 더 늘린다”보다 개발 경로·격리·긴 작업 상태·AI 데이터 경계를 다시 설계하는 흐름이 중요해졌다는 근거로 읽을 수 있다.

이 페이지는 스무 항목을 모두 순서대로 읽는 긴 글이 아니다. 지금 겪는 문제와 가까운 항목을 골라 무엇이 없어서 어려웠는지, 새 구조가 상태와 비용을 어디로 옮기는지, 언제 쓰지 말아야 하는지를 확인하는 참조 지도다. 실제 도입 전에는 공식 문서의 최신 버전과 현재 팀이 소유할 제어 영역·복구 절차를 다시 확인한다.

채택 판단의 짧은 지도¶

트렌드를 세 방향으로 분류한다.

경계 재설계: 모듈형 모놀리스, 셀, 액터, 엣지
실행·연결 추상화: 이벤트, 지속 실행, 서버리스, 서비스 메시, WASM
개발·AI 데이터 영역: 플랫폼 엔지니어링, eBPF, 벡터 검색, 에이전트 통신 프로토콜

새 이름이 나와도 상태가 저장되는 위치, 장애가 멈추는 경계, 제어 영역과 데이터 영역, 일관성, 대기열과 소유 팀을 찾으면 기존 지식과 연결된다.

flowchart TB
  P["반복된 문제"] --> D{"주로 바꾸려는 경계"}
  D -->|"배포와 장애 범위"| B["모듈형 모놀리스 · 셀 · 엣지"]
  D -->|"실행과 비동기 상태"| E["이벤트 · 내구성 있는 실행 · 서버리스"]
  D -->|"서비스 연결과 관측"| N["서비스 메시 · eBPF · OpenTelemetry"]
  D -->|"개발자 경험"| I["플랫폼 엔지니어링 · IDP"]
  D -->|"인공지능 데이터 경로"| A["하이브리드 검색 · 에이전트 프로토콜"]
  B --> C["새 제어 영역과 운영 책임"]
  E --> C
  N --> C
  I --> C
  A --> C
  C --> J{"문제 감소가 복잡도 증가보다 큰가?"}
  J -->|"예"| AD["작은 범위에서 채택 후 지표로 확대"]
  J -->|"아니오"| KEEP["현재 구조 유지 또는 더 단순한 대안"]

검토할 스무 가지 변화¶

1. 모듈형 모놀리스¶

무엇과 왜: 마이크로서비스를 너무 일찍 나누면 아직 안정되지 않은 업무 경계가 네트워크 경계가 된다. 그 결과 단순한 기능 변경에도 서비스 간 호출, 분산 트랜잭션, 여러 배포와 관측 체계를 함께 다뤄야 한다. 모듈형 모놀리스는 하나의 배포 단위 안에서 업무 모듈의 경계를 강제해 로컬 호출과 단일 트랜잭션의 단순성을 유지한다.

내부 구조: 모듈마다 외부에 공개할 인터페이스와 내부 구현을 나누고, 데이터의 소유권과 허용할 의존 방향을 정한다. 이 규칙은 문서에만 두지 않고 아키텍처 테스트로 검증한다. Spring Modulith 같은 도구는 모듈 경계 검증, 모듈 사이의 이벤트 전달, 모듈 단위 테스트와 관측을 지원한다.

적합/부적합: 제품의 업무 경계가 계속 변하고 한 팀 또는 소수 팀이 운영할 때 잘 맞는다. 반대로 확장 규모, 보안 요구, 배포 주기가 서로 다르다는 사실이 이미 확인된 큰 영역은 일부를 독립 서비스로 분리할 이유가 충분할 수 있다.

운영·관측: 모듈별 지연과 오류, 금지된 의존성 위반, 트랜잭션 범위, 한 모듈 변경이 전체 빌드에 미치는 영향을 본다. Shopify가 대규모 모놀리스의 경계를 다시 세운 사례와 Spring 생태계의 지원 도구는 이 접근이 단순히 “작은 시스템용”만은 아니라는 점을 보여 준다.

2. 이벤트 기반 아키텍처¶

무엇과 왜: 동기 호출 사슬이 가용성과 배포를 서로 묶고 순간 부하를 그대로 전파하는 문제를 이벤트 로그와 대기열로 시간상 분리한다.

내부 구조: 생산자는 이미 일어난 사실을 이벤트로 발행하고, 브로커는 이를 보존하며 파티션 같은 순서 보장 경계를 제공한다. 소비자는 자신의 목적에 맞게 이벤트를 읽어 조회용 상태나 후속 작업을 만든다. 생산자는 소비자의 완료를 기다리지 않지만, 그 대신 중복 처리와 늦은 도착, 스키마 변경을 명시적으로 다뤄야 한다.

적합/부적합: 하나의 사건을 여러 후속 시스템이 사용하거나, 순간 부하를 완충하고, 과거 기록을 다시 처리해야 할 때 적합하다. 즉시 강한 일관성이 필요하고 한 번의 호출로 충분한 업무에는 비동기 상태와 운영 요소가 과하다.

운영·관측: 소비자가 최신 위치에서 얼마나 뒤처졌는지, 같은 이벤트가 몇 번 처리되는지, 반복 실패하는 이벤트가 있는지, 스키마 변경이 호환되는지, 발생부터 결과 반영까지의 최신성을 본다. Kafka는 이런 이벤트 스트리밍을 구현하는 대표 기반이다.

3. 셀 기반 아키텍처¶

무엇과 왜: 하나의 거대한 리전 클러스터에서는 잘못된 배포, 과부하, 비정상 요청이 전체 고객으로 번질 수 있다. 셀 기반 아키텍처는 시스템을 독립적으로 운영할 수 있는 작은 복제 단위로 나눠 한 번의 실패가 영향을 주는 범위를 제한한다.

내부 구조: 크기 상한이 정해진 독립 셀이 애플리케이션과 상태를 함께 포함하고, 얇은 라우터가 테넌트나 자원 키를 특정 셀에 연결한다. 셀 사이의 상태 공유와 호출은 최소화하고, 새 버전 시험 배포와 복구를 셀 단위로 자동화한다. 공통 제어 영역이 모든 셀의 단일 장애점이 되지 않도록 데이터 처리 경로와 분리하는 일도 중요하다.

적합/부적합: 많은 고객 조직을 함께 수용하는 큰 서비스에서 한 번의 실패가 전체 고객에 미치는 비용이 클 때 적합하다. 요청량이 작고 데이터베이스 하나로 충분한 시스템에는 별도 라우팅, 셀 재배치, 중복 용량이 과한 비용이 된다.

운영·관측: 셀마다 자원 포화도·오류·서비스 수준 목표(SLO)를 따로 보고, 라우터 상태, 테넌트 분포의 쏠림, 재배치 과정, 공통 제어 영역의 장애를 살핀다. AWS는 장애 영향 범위와 셀 크기 상한을 셀 기반 구조의 핵심 원칙으로 설명한다.

4. 지속 실행¶

무엇과 왜: 여러 API 호출, 타이머, 사람의 승인이 섞인 긴 업무를 일반 애플리케이션 코드와 예약 작업, 재시도 테이블만으로 구현하면 프로세스가 중단된 뒤 “어디까지 실행됐는가”를 정확히 복구하기 어렵다. 지속 실행은 진행 상태 자체를 영속적으로 기록해 중단된 작업을 이어 갈 수 있게 한다.

내부 구조: 워크플로의 사건 이력과 결정론적 재실행 또는 체크포인트로 실행 상태를 복원한다. 결제 승인이나 메일 발송처럼 외부에 영향을 주는 작업은 멱등성과 재시도를 따로 설계한 활동(activity)으로 분리한다. 타이머와 외부 신호도 메모리 안의 값이 아니라 영속 상태로 다룬다.

적합/부적합: 결제, 자원 준비, 에이전트 작업, 장기 승인처럼 수분에서 수개월까지 이어지고 보상·재시도가 중요한 업무에 적합하다. 상태 없이 짧게 끝나는 요청에는 별도 워크플로 시스템의 운영 비용이 더 크다.

운영·관측: 워크플로가 시작된 뒤 지난 시간, 작업 대기열 지연, 재시도 횟수, 멈춘 실행, 이력 크기, 재실행 결과가 달라지는 비결정성, 외부 활동의 멱등성을 본다. Temporal과 AWS Lambda Durable Functions가 대표적이다.

5. 액터 모델¶

무엇과 왜: 상태를 가진 수많은 개체의 동시 업데이트와 분산 위치, 생명주기를 잠금과 데이터 분할만으로 직접 관리하면 복잡해진다. 액터 모델은 개체마다 상태와 메시지 처리 경계를 묶어, 같은 개체에 대한 변경을 순차적으로 다루게 한다.

내부 구조: 액터는 고유한 식별자, 외부에서 직접 만질 수 없는 상태, 메시지함, 메시지에 반응하는 동작을 가진다. 한 액터는 메시지를 순서대로 처리하므로 내부 상태를 보호하기 위한 잠금이 줄어든다. 가상 액터 실행 환경은 필요한 액터를 메모리에 올리고 적절한 노드에 배치하는 일을 자동화한다.

적합/부적합: 게임 방, 기기, 사용자 세션, 협업 문서처럼 키별로 상태가 독립적인 대상에 적합하다. 전역 트랜잭션, 액터를 가로지르는 대규모 조인과 작은 메시지를 지나치게 자주 주고받는 그래프에는 비용이 크다.

운영·관측: 메시지함에 쌓인 개수, 활성화된 액터 수, 요청이 몰린 액터, 메시지 지연, 한 처리 중 다시 같은 액터를 호출하는 재진입, 상태 저장 실패를 본다. Microsoft Orleans의 그레인(grain)이 가상 액터의 대표 사례다.

6. 플랫폼 엔지니어링¶

무엇과 왜: 각 제품 팀이 Kubernetes, 지속적 통합·배포(CI/CD), 보안, 관측 체계를 매번 직접 조립하면 업무 기능보다 기반 시설에 더 많은 판단을 쓰게 된다. 지원 요청이 중앙 운영 팀에 몰리면 대기 시간도 길어진다. 플랫폼 엔지니어링은 반복되는 개발·운영 경로를 내부 제품으로 만들고 개발자가 스스로 사용할 수 있게 한다.

내부 구조: 플랫폼 API와 자동화 조정 계층, 검증된 기본 템플릿과 권장 경로, 서비스 목록, 정책, 관측 기능을 연결한다. 플랫폼 팀은 내부 개발자를 고객으로 보고, 기능 수보다 실제 사용률과 배포 시간 단축, 실패 감소 같은 결과를 측정한다.

적합/부적합: 여러 팀이 같은 배포와 운영 문제를 반복할 때 적합하다. 팀이 작거나 실제 병목을 찾지 않은 채 포털부터 만들면 새로운 유지보수 대상만 생긴다.

운영·관측: 권장 경로 사용률, 변경부터 배포까지 걸린 시간, 배포 성공률, 도움 없이 작업을 끝낸 비율, 지원 요청 수, 개발자 만족도를 본다. CNCF는 플랫폼 엔지니어링을 셀프서비스와 ‘플랫폼을 제품처럼 운영하는 방식’으로 설명한다.

7. 내부 개발자 플랫폼¶

무엇과 왜: 내부 개발자 플랫폼(IDP)은 플랫폼 엔지니어링을 실제로 제공하는 인터페이스와 기능의 묶음이다. 개발자가 기반 시설의 세부 구현을 모두 알지 않고도 서비스 생성, 배포, 관측, 복구를 수행하게 한다.

내부 구조: 포털이나 명령줄 도구는 입구일 뿐이고, 뒤에는 서비스 목록, 자동화 워크플로, 코드로 관리하는 인프라(IaC), 정책, 비밀 정보, 실행 환경 API가 있다. 권장 경로는 기본값이어야 하지만, 정당한 예외까지 금지하는 유일한 길이여서는 안 된다.

적합/부적합: 서비스 수가 많고 규정 준수 요구가 반복될 때 가치가 있다. 포털이 수동 지원 요청을 보기 좋게 감싸는 수준에 머물면 병목이 다른 화면으로 이동할 뿐이다.

운영·관측: 권장 경로의 성공률, 자원 준비 시간, 템플릿과 실제 환경의 차이, 플랫폼 자체의 SLO, 예외 경로를 택한 이유를 본다. Backstage는 서비스 목록과 포털을 만드는 대표 구성 요소이지 내부 개발자 플랫폼 전체와 같은 말은 아니다.

8. eBPF 기반 관측¶

무엇과 왜: 언어마다 관측 에이전트를 설치하거나 코드를 바꾸기 어려운 혼합 환경에서는 서비스 사이의 네트워크 지연과 운영체제 호출을 공통 방식으로 보기 어렵다. eBPF는 애플리케이션을 크게 수정하지 않고도 리눅스 커널 수준의 사건을 관측하게 한다.

내부 구조: 검증기가 안전성을 검사한 eBPF 프로그램이 커널의 지정 지점에서 사건을 수집하고, 사용자 공간의 에이전트가 이를 집계해 관측 저장소로 보낸다. OpenTelemetry의 eBPF 계측은 프로토콜 수준의 추적과 지표를 공통 OTel 형식으로 연결한다.

적합/부적합: Kubernetes 노드, 오래된 서비스와 여러 언어가 섞인 환경, 애플리케이션 계측이 놓친 네트워크 구간에 적합하다. 주문 상태나 사용자 등급 같은 업무 필드와 암호화된 애플리케이션 본문을 이해하려면 여전히 코드 안의 수동 계측이 필요하다.

운영·관측: 커널과 도구 버전의 호환성, 수집 중 유실된 사건, 에이전트의 CPU·메모리 사용량, 함수 이름 해석, 지나치게 많은 구분값으로 생기는 카디널리티를 본다.

9. 서비스 메시의 변화: 사이드카에서 앰비언트로¶

무엇과 왜: 모든 파드 옆에 별도 프록시를 두는 사이드카 방식은 일관된 상호 TLS(mTLS), 정책, 원격 측정을 제공하지만 프록시의 자원 사용량과 애플리케이션 생명주기 결합, 업그레이드 비용이 컸다. Istio의 앰비언트 모드는 전송 계층(L4)과 애플리케이션 계층(L7) 기능을 분리해 필요한 곳에만 무거운 기능을 둔다.

내부 구조: 노드별 ztunnel이 L4 보안 연결을 제공하고, 필요한 네임스페이스나 서비스에만 Envoy 웨이포인트를 두어 L7 정책과 라우팅을 적용한다.

적합/부적합: 많은 서비스의 신원, mTLS, 일부 L7 제어가 필요할 때 적합하다. 서비스 수가 적거나 애플리케이션 게이트웨이만으로 요구를 충족한다면 메시 자체가 과한 운영 계층이 된다.

운영·관측: ztunnel과 웨이포인트의 자원 포화, 인증서 상태, 정책을 우회하는 경로, 추가 네트워크 홉의 지연, L4와 L7 정책이 실제로 적용되는 범위를 본다.

10. 스트리밍 우선 아키텍처¶

무엇과 왜: 하루 한 번 실행하는 일괄 처리와 서비스마다 따로 만든 직접 연동은 데이터의 최신성과 재사용을 제한한다. 스트리밍 우선 구조는 변경을 끊임없는 사건 흐름으로 제공해 여러 소비자가 자신의 목적에 맞는 구체화된 조회 상태를 만들게 한다.

내부 구조: 변경 데이터 캡처(CDC) 또는 이벤트 로그, 스트림 처리기, 스키마 저장소, 처리 상태 저장소, 결과를 내보내는 대상이 하나의 데이터 제품을 이룬다.

적합/부적합: 이상 거래 탐지, 재고, 원격 측정처럼 최신성과 여러 소비자가 중요할 때 적합하다. 변화량이 적고 단순한 보고서만 필요하다면 일괄 처리가 더 싸고 이해하기 쉽다.

운영·관측: 사건이 실제 발생한 시각 기준의 처리 지연, 늦은 사건을 어디까지 기다릴지 나타내는 워터마크, 처리 상태 크기, 재처리, 스키마 변경과 늦게 도착한 사건을 본다.

11. 벡터 데이터베이스와 AI 검색 기반 구조¶

무엇과 왜: 키워드가 정확히 겹치는지만 보는 검색은 같은 뜻을 다른 말로 표현한 문장을 놓치기 쉽다. 임베딩과 근사 최근접 이웃(ANN) 검색은 의미가 비슷한 항목을 찾고, 하이브리드 검색은 이를 키워드 검색과 결합해 서로의 약점을 보완한다.

내부 구조: 문서 수집과 의미 단위 분할, 임베딩 생성, 벡터·어휘 인덱스, 메타데이터 접근 권한 검사, 두 검색 결과의 결합, 재순위화, 모델에 넣을 문맥 조립이 이어진다.

적합/부적합: 의미로 찾아야 하는 큰 문서 집합과 명확한 지연 목표가 있을 때 적합하다. 데이터가 작거나 주문 번호처럼 정확한 식별자를 찾는 일이 중심이라면 관계형 데이터베이스나 키워드 검색이 더 단순하다.

운영·관측: 상위 k개 결과 안에 필요한 근거가 포함된 비율, 필터 선택도, 인덱스 구축 시간, 메모리, 최신성, 재순위화 지연, 임베딩 모델 버전을 본다. pgvector 문서는 HNSW와 IVFFlat이 검색 속도와 재현율 사이에서 치르는 비용을 명시한다.

12. AI 게이트웨이¶

무엇과 왜: 여러 모델 제공자의 인증 키, 사용 한도, 감사 기록, 장애 시 대체 경로, 데이터 정책이 애플리케이션마다 흩어지면 통제하기 어렵다. AI 게이트웨이는 공통 정책과 라우팅을 한 경계에 모은다.

내부 구조: 제공자별 형식을 맞추는 어댑터, 모델 목록과 경로 선택기, 정책 검사와 민감 정보 제거, 사용량 제한과 캐시, 원격 측정이 실제 요청 처리 영역을 이룬다.

적합/부적합: 여러 팀이 여러 모델과 리전을 운영할 때 적합하다. 하나의 모델 주소만 사용하는 작은 서비스에는 공통 장애점과 추가 지연만 늘 수 있다.

운영·관측: 모델별 품질·지연·비용, 대체 경로, 토큰 사용량, 테넌트별 한도, 프롬프트 개인정보 보호와 게이트웨이 가용성을 본다.

13. 엣지 컴퓨팅과 엣지 AI¶

무엇과 왜: 중앙 리전까지 왕복하는 지연, 데이터를 특정 지역에 두어야 하는 요구, 불안정한 네트워크 문제를 사용자나 기기 가까운 곳에서 계산해 줄인다.

내부 구조: 전역 라우팅, 상태 없는 엣지 함수 또는 개체별 상태 객체, 지역 원본 서버와 데이터 동기화가 결합된다. 엣지 AI는 작은 모델의 추론과 필터링을 가까운 위치에서 수행한다.

적합/부적합: 개인화, 실시간 협업, 사물 인터넷(IoT) 전처리, 지연에 민감한 추론에 적합하다. 강한 전역 트랜잭션과 큰 모델·자원이 필요하면 중앙 또는 리전 단위 처리가 낫다.

운영·관측: 리전별 초기 구동 지연, 상태가 배치된 위치, 지역 간 일관성, 모델 배포 진행률, 위치별 자원 편차, 원본 서버로 되돌아가는 경로를 본다. Cloudflare Durable Objects는 개체별 상태를 엣지에 두는 대표 사례다.

14. HTAP¶

무엇과 왜: 추출·변환·적재(ETL)가 끝난 뒤 늦게 보는 분석이 아니라, 방금 바뀐 트랜잭션 데이터를 곧바로 분석하려는 요구다.

내부 구조: 행 중심 트랜잭션 엔진과 열 중심 복제본 또는 캐시, 로그 복제, 두 작업 부하가 서로 자원을 빼앗지 않게 하는 격리를 결합하는 경우가 많다.

적합/부적합: 운영 현황판과 실시간 의사결정에 적합하다. 오랜 이력, 여러 분석 엔진, 저렴한 대용량 저장소가 중심이라면 레이크하우스가 더 잘 맞을 수 있다.

운영·관측: 분석 복제본의 최신성, 분석이 OLTP에 미치는 영향, 분석 대기열과 비용을 본다.

15. 레이크하우스¶

무엇과 왜: 데이터 레이크의 저렴하고 개방된 객체 저장소와 데이터 웨어하우스의 트랜잭션·스키마·성능 관리 능력을 결합한다.

내부 구조: 열 형식 파일, 테이블 형식의 메타데이터와 변경 로그, 카탈로그, 저장소와 분리된 계산 엔진으로 스냅샷과 안전한 스키마 변경을 제공한다.

적합/부적합: 여러 분석 엔진이 큰 이력을 함께 사용할 때 적합하다. 밀리초 단위로 개별 행을 자주 업데이트하는 OLTP에는 맞지 않는다.

운영·관측: 작은 파일이 지나치게 늘어나는지, 파일 병합, 메타데이터 증가, 스냅샷 보존 기간, 카탈로그 일관성, 질의 비용을 본다.

16. WASM¶

무엇과 왜: 플러그인과 엣지 코드를 특정 언어에 묶이지 않은 형식으로 배포하고, 강하게 격리된 환경에서 빠르게 시작하려는 요구다.

내부 구조: 검증된 샌드박스 실행 환경에서 모듈의 바이트코드를 실행하고, 파일이나 네트워크 같은 호스트 기능은 허용한 것만 명시적으로 제공한다. WASI는 웹 브라우저 밖에서 필요한 시스템 인터페이스를 표준화한다.

적합/부적합: 프록시 플러그인, 엣지 함수, 신뢰할 수 없는 확장 코드를 격리해 실행할 때 적합하다. 성숙한 JVM 생태계 전체를 그대로 옮기는 목적에는 지원 기능과 디버깅 측면의 제약이 많다.

운영·관측: 모듈 버전, 호스트 기능 호출, 샌드박스 탈출 가능성, CPU 실행량 제한, 메모리, 초기 구동 시간을 본다.

17. 서버리스 실행 환경과 이벤트 워크플로¶

무엇과 왜: 간헐적으로 발생하는 이벤트를 위해 서버를 미리 준비하고 유휴 자원 비용을 내는 대신, 실행 환경의 준비와 확장을 클라우드 플랫폼에 맡긴다.

내부 구조: 이벤트 트리거, 짧게 실행되고 상태를 내부에 보존하지 않는 함수, 관리형 대기열·상태·워크플로가 결합된다. 오래 걸리는 실행은 한 함수가 계속 붙잡지 않고 워크플로와 체크포인트로 나눈다.

적합/부적합: 순간적으로 몰리는 시스템 연동, 파일과 이벤트 처리에 적합하다. 항상 높은 부하, 오래 유지되는 연결, 특수한 실행 환경에는 단가와 플랫폼 제약이 더 클 수 있다.

운영·관측: 초기 구동 지연, 동시 실행 한도, 재시도와 실패 메시지 보관함(DLQ), 이벤트가 대기한 시간, 비용과 공급자 제한을 본다.

18. 서버리스 이벤트 기반 워크플로¶

무엇과 왜: 함수를 이벤트로 많이 연결할수록 재시도, 조건 분기, 시간 제한, 실패를 되돌리는 보상 상태가 여러 코드와 설정에 흩어진다. 서버리스 워크플로는 이 제어 흐름을 하나의 명시적인 정의로 모은다.

내부 구조: 상태 기계 또는 워크플로 코드, 영속적인 진행 상태, 실행을 시작하는 사건, 실제 작업을 맡는 활동이나 함수를 결합한다.

적합/부적합: 여러 시스템 연동의 순서를 조정하고 오래 기다리는 업무에 적합하다. 매우 낮은 지연이 필요한 단순 요청에는 조정 계층을 거치는 비용이 과하다.

운영·관측: 실행 상태, 단계 전환 오류, 재시도, 데이터 크기 제한, 끝나지 않은 타이머, 비용을 본다. CNCF Serverless Workflow는 특정 공급자에 덜 묶이는 워크플로 규격을 제공한다.

19. 에이전트형 AI 아키텍처, MCP와 A2A¶

무엇과 왜: 모델이 한 번 답을 생성하는 데서 끝나지 않고, 필요한 도구를 고르며 여러 단계 작업을 수행하게 한다. MCP는 모델과 도구·자원의 연동 경계를, A2A는 독립된 에이전트끼리 작업을 주고받는 경계를 표준화한다.

2026년 변화: MCP 공식 로드맵은 전송 확장성, 에이전트 통신, 거버넌스와 기업 환경 준비를 주요 과제로 두고 있다. A2A도 능력 발견과 장기 작업 교환을 중심으로 규격과 검증 도구를 발전시키고 있다. 두 규격은 빠르게 바뀌는 단계이므로 미래 버전을 이미 확정된 계약처럼 쓰지 않고, 구현 시점의 공식 버전과 호환 범위를 고정해야 한다. MCP는 도구와 맥락의 경계, A2A는 독립 에이전트 사이의 작업 협업 경계라는 차이가 있다.

내부 구조: 계획 수립과 모델 호출의 반복, 도구 목록과 프로토콜 클라이언트, 정책과 승인, 영속 상태, 비용 예산, 결과 평가기가 필요하다. 프로토콜이 무상태여도 애플리케이션의 진행 상태와 장기 작업 복구까지 대신하지는 않는다. 따라서 작업 식별자, 체크포인트, 멱등성 키, 감사 로그를 별도로 둬야 한다.

적합/부적합: 해결 경로를 미리 고정하기 어려운 지식 작업에 적합하다. 순서와 결과가 엄격히 정해진 트랜잭션이나 되돌릴 수 없는 작업은 명시적인 워크플로가 더 안전하다.

운영·관측: 단계와 도구별 성공률, 반복 횟수, 토큰과 비용, 승인 상태, 멱등성, 연결한 프로토콜 서버의 신뢰 수준, 전체 작업 추적을 본다.

20. 지속 가능한 에이전트 실행¶

무엇과 왜: 에이전트 작업은 모델·제공자·도구의 실패와 사람의 승인을 기다리는 시간 때문에 오래 지속될 수 있다. 메모리 안의 반복문으로만 실행하면 프로세스가 중단될 때 진행 상태가 사라진다.

내부 구조: 각 모델 호출과 도구 실행 단계를 영속적인 워크플로 사건과 멱등한 활동으로 기록한다. 외부 신호나 승인을 기다릴 때는 자원을 붙잡지 않고 중단했다가 신호가 오면 이어서 실행한다.

적합/부적합: 장기 조사, 자원 준비, 여러 단계의 업무 에이전트에 적합하다. 한 번의 검색이나 짧은 응답에는 과하다.

운영·관측: 워크플로가 지속된 시간, 재실행 결과의 결정성, 도구의 중복 실행, 비용 예산, 취소 처리, 사람의 승인을 기다리는 시간 제한을 본다.

채택 전에 마지막으로 확인할 것¶

현재 실패와 비용을 먼저 기준선으로 남긴다. 새 구조가 상태·대기열·권한과 장애 범위를 어디로 옮기는지 그리고, 정상 요청보다 배포 실패·과부하·네트워크 단절·재처리·되돌리기를 대입한다. 마지막으로 소유 팀, 제거 전략과 성공을 판단할 SLO·비용·품질 지표를 정한다.

새 이름이 기존 구조를 자동으로 대체하지 않는다. 모듈 경계 검증, 길이 상한이 있는 대기열, 아웃박스, 애플리케이션 계측과 검증된 백업만으로 현재 문제가 해결된다면 그쪽이 더 좋은 설계다. 측정된 문제의 감소가 새 제어 영역과 운영 책임보다 클 때만 채택한다.