1 들어가며

AI 에이전트를 효율적으로 양산하고 관리하는 플랫폼을 구축하려면 먼저 “어떤 관점으로 접근할 것인가”를 명확히 해야 한다. 같은 문제라도 Platform Engineering, Software Architecture, Systems Engineering 관점에서 보면 완전히 다른 질문과 해결책이 나온다.

이 글에서는 세 가지 관점의 정의와 차이점을 명확히 하고, AI Agent 플랫폼 구축에 가장 적합한 관점을 선택한다. 실제 글로벌 기업들(Spotify, Netflix, Airbnb)의 플랫폼 구축 사례를 통해 각 관점이 어떻게 적용되는지 살펴본다.

2 세 가지 관점의 용어 정의

2.1 소프트웨어 아키텍처 (Software Architecture)

소프트웨어 아키텍처: 시스템의 구조, 컴포넌트 간 관계, 설계 원칙을 결정하는 활동이다.
“10년 후에도 이 시스템이 유지 가능한가?”라는 장기적 관점에서 기술적 의사결정을 내린다.

2.1.1 “컴포넌트(Component)”란?

소프트웨어 공학의 표준 용어로, 독립적으로 배포/교체 가능한 시스템 구성 단위를 의미한다.
모듈, 라이브러리, 서비스, 클래스 등 다양한 수준에서 사용된다.

# 일반적인 웹 서비스의 컴포넌트 예시
웹 서비스/
├── Frontend (React)              # UI 컴포넌트
├── API Gateway                   # 인증/라우팅 컴포넌트
├── User Service                  # 사용자 관리 컴포넌트
├── Payment Service               # 결제 처리 컴포넌트
└── Database                      # 데이터 저장 컴포넌트

# AI Agent 플랫폼의 컴포넌트
ai-agent-platform/
├── core/                         # 플랫폼 핵심 컴포넌트
│   ├── base_agent.py            # BaseAgent 클래스
│   └── orchestrator.py           # Agent 관리자
│
├── shared/                       # 공통 라이브러리 컴포넌트
│   ├── llm_client.py            # LLM API 호출
│   └── monitoring.py             # 메트릭 수집
│
└── agents/                       # 도메인 Agent 컴포넌트
    ├── data_standardization/
    ├── code_analysis/
    └── knowledge_qna/

# 컴포넌트 간 관계 = 의존성 방향
agents/ → shared/  ✅  (Agent가 공통 라이브러리 사용)
agents/ → core/    ✅  (Agent가 BaseAgent 상속)
core/ → agents/    ❌  (Core는 Agent를 몰라야 함 - Dependency Inversion)

2.1.2 “설계 원칙”이란?

컴포넌트를 어떻게 배치하고 연결할 것인가에 대한 규칙: - “Core는 구체적인 Agent에 의존하지 않는다” (Dependency Inversion Principle) - “Agent는 표준 인터페이스를 따른다” (Interface Segregation Principle) - “공통 로직은 shared/에 둔다” (DRY - Don’t Repeat Yourself)

2.1.3 Architecture는 “구조적 결정”에 집중한다

# Software Architect가 묻는 질문들

"Monorepo vs Polyrepo 중 어느 것을 선택하는가?"
"마이크로서비스 vs 모놀리스 중 무엇이 적합한가?"
"Event-driven vs Request-response 패턴 중 무엇을 채택하는가?"
"모듈 경계와 의존성 방향을 어떻게 설정하는가?"
"10년 후 시스템 복잡도가 100배 증가해도 감당 가능한가?"

2.1.4 실제 사례: Twitter의 Monorepo 결정

배경 (2020년): - Twitter는 수백 개의 마이크로서비스를 운영 중 - 각 서비스가 별도 repo에 있어 의존성 지옥 발생 - 라이브러리 버전 불일치로 인한 장애 빈발

Architecture 결정: - Monorepo로 전환 (Bazel 빌드 시스템) - 모든 코드가 단일 repo에서 원자적 커밋(atomic commit) 가능 - 의존성 그래프를 컴파일 타임에 검증

결과: - 버전 충돌 90% 감소 - 리팩토링 시간 70% 단축 - 하지만 빌드 인프라 구축에 6개월 소요

교훈: Architecture는 구조적 결정(Monorepo 선택)이지만, 그것을 실제 작동하게 만드는 것(빌드 시스템, CI/CD)은 Platform Engineering의 영역이다.

2.1.5 담당 역할

Software Architect, Staff Engineer, Principal Engineer가 주로 담당한다.

2.2 플랫폼 엔지니어링 (Platform Engineering)

개발자가 셀프서비스(Self-Service)로 제품을 만들 수 있는 환경을 구축하는 활동을 말한다.
“개발자가 5분 안에 새로운 기능을 배포할 수 있는가?”라는 생산성 관점에서 접근한다.

2.2.1 핵심 개념: Internal Developer Platform (IDP)

개발자가 인프라, 공통 로직, 배포 파이프라인에 신경 쓰지 않고 비즈니스 로직(도메인 지식)에만 집중할 수 있도록 만드는 것이다.

AI Agent 플랫폼에 적용하면: - Agent 개발자는 도메인 로직(프롬프트, 데이터 처리)만 작성 - 플랫폼이 자동으로 제공: - LLM API 호출 (재시도, 에러 처리) - 모니터링 (실행 시간, 성공률) - 배포 (CI/CD 자동화) - 버전 관리 (프롬프트 버전 추적)

2.2.2 다루는 핵심 질문

Platform Engineering은 “개발자 경험(Developer Experience)”에 집중한다:

# Platform Engineer가 묻는 질문들

"새 Agent를 5분 안에 만들 수 있는가?"
"공통 모듈을 재사용하기 쉬운가?"
"배포가 자동화되어 있는가?"
"개발자가 인프라를 몰라도 되는가?"
"실험(A/B 테스트)이 쉬운가?"
"장애 발생 시 10분 안에 롤백 가능한가?"

2.2.3 실제 사례: Spotify의 Backstage

배경 (2016년): - Spotify는 1000+ 마이크로서비스 운영 - 새 서비스를 만들려면 10개 이상의 도구 설정 필요 - GitHub repo 생성 - CI/CD 파이프라인 구성 - 모니터링 설정 (Prometheus, Grafana) - 문서 작성 (Confluence) - 서비스 메시 등록 (Istio) - 문제: 신입 개발자가 첫 배포까지 2-3주 소요

Platform Engineering 솔루션: Backstage

# 개발자가 작성하는 설정 파일 (service.yaml)
apiVersion: backstage.io/v1alpha1
kind: Component
metadata:
  name: my-new-service
  description: "내가 만든 첫 서비스"
spec:
  type: service
  lifecycle: production
  owner: team-data

# 이것만 작성하면 플랫폼이 자동으로:
# 1. GitHub repo 생성
# 2. CI/CD 파이프라인 구성
# 3. Kubernetes 배포 설정
# 4. 모니터링 대시보드 생성
# 5. 서비스 카탈로그 등록

결과: - 새 서비스 배포 시간: 2-3주 → 30분 - 개발자가 알아야 할 도구: 10개 → 1개 (Backstage) - 2020년 오픈소스로 공개, CNCF 프로젝트로 채택

교훈: Platform Engineering은 “복잡함을 숨기고, 간단함을 제공하는 것”이다.

2.2.4 실제 사례: Netflix의 Conductor

배경 (2016년): - Netflix는 수천 개의 마이크로서비스로 구성 - 비디오 인코딩 워크플로우가 매우 복잡: 1. 원본 비디오 업로드 2. 여러 해상도로 인코딩 (720p, 1080p, 4K) 3. 썸네일 생성 4. 자막 처리 5. CDN 배포 - 각 단계가 다른 팀의 마이크로서비스 - 문제: 워크플로우 조율 코드가 각 팀마다 중복

Platform Engineering 솔루션: Conductor

// 개발자가 정의하는 워크플로우 (JSON)
{
  "name": "video_processing_workflow",
  "tasks": [
    {"name": "upload", "taskReferenceName": "upload_task", "type": "SIMPLE"},
    {"name": "encode_720p", "taskReferenceName": "encode_720p", "type": "SIMPLE"},
    {"name": "encode_1080p", "taskReferenceName": "encode_1080p", "type": "SIMPLE"},
    {"name": "encode_4k", "taskReferenceName": "encode_4k", "type": "SIMPLE"},
    {"name": "generate_thumbnail", "taskReferenceName": "thumbnail", "type": "SIMPLE"},
    {"name": "deploy_cdn", "taskReferenceName": "cdn", "type": "SIMPLE"}
  ]
}

// 플랫폼이 자동으로 제공:
// - 재시도 로직 (실패 시 자동 재실행)
// - 타임아웃 관리
// - 병렬 실행 (encode_720p, 1080p, 4k 동시 실행)
// - 모니터링 (각 단계별 실행 시간, 성공률)
// - 시각화 (워크플로우 진행 상황 UI)

결과: - 워크플로우 개발 시간: 2-3일 → 30분 - 중복 코드 제거: 각 팀이 독자적으로 작성하던 조율 로직 삭제 - 2017년 오픈소스로 공개

교훈: Platform Engineering은 “공통 패턴을 찾아 플랫폼으로 추상화하는 것”이다.

2.2.5 AI Agent 플랫폼에 적용

Spotify Backstage처럼:

# agents/my_agent/config.yaml
name: data_standardization_agent
description: "데이터 스키마 표준화"
owner: data-team
llm:
  provider: openai
  model: gpt-4

# 이것만 작성하면 플랫폼이 자동으로:
# - LLM 클라이언트 설정
# - 재시도 로직 적용
# - 모니터링 대시보드 생성
# - CI/CD 파이프라인 생성

Netflix Conductor처럼:

# 여러 Agent를 조합한 워크플로우
workflow = [
    DataStandardizationAgent(),
    CodeAnalysisAgent(),
    KnowledgeQnAAgent()
]

# 플랫폼이 자동으로:
# - Agent 간 데이터 전달
# - 실패 시 재시도
# - 병렬 실행 최적화
# - 전체 워크플로우 모니터링

2.2.6 담당 역할

Platform Engineer, DevOps Engineer, Infrastructure Engineer가 주로 담당한다.

2.3 시스템 엔지니어링 (Systems Engineering)

복잡한 물리적 시스템의 설계, 통합, 생명주기 관리를 다루는 활동이다.
하드웨어 + 소프트웨어 + 물리 법칙이 결합된 시스템이 대상이다.

2.3.1 다루는 핵심 질문

Systems Engineering은 “물리적 제약”에 집중한다:

# Systems Engineer가 묻는 질문들

"로켓의 추진 시스템과 제어 시스템을 어떻게 통합하는가?"
"자율주행차의 센서-소프트웨어-액추에이터를 어떻게 조율하는가?"
"요구사항을 하드웨어/소프트웨어로 어떻게 분해하는가?"
"시스템 전체의 안전성을 어떻게 검증하는가?"
"20년 후에도 부품 교체가 가능한가?"

2.3.2 실제 사례: 보잉 787 개발

시스템 복잡도: - 하드웨어: 엔진, 날개, 유압 시스템 - 소프트웨어: 비행 제어, 엔터테인먼트 시스템 - 네트워크: 항공전자 네트워크 (AFDX) - 인증: FAA 안전 인증 필수

Systems Engineering 프로세스: 1. 요구사항 분석 (10,000+ 요구사항) 2. 시스템 분해 (하드웨어/소프트웨어/기계) 3. 인터페이스 정의 (100+ 시스템 간 통신) 4. 통합 테스트 (5년 이상 소요) 5. 인증 및 검증

소요 시간: 8년 (2004-2011)

2.3.3 AI Agent 플랫폼에 왜 부적합한가

비교: AI Agent Platform vs 항공기 시스템

특성	AI Agent Platform	항공기 시스템 (Systems Engineering)
주요 제약	코드 복잡도, 확장성	물리 법칙, 안전 인증
변경 비용	낮음 (코드 수정)	매우 높음 (하드웨어 재설계)
실패 영향	서비스 장애	인명 피해
개발 주기	주 단위	년 단위
검증 방법	자동화 테스트	물리적 시험

결론: AI Agent 플랫폼은 순수 소프트웨어 시스템이므로 Software Architecture + Platform Engineering 관점이 적합하다.

용어 혼동 주의: - “시스템 엔지니어링”을 언급하면 항공, 국방, 하드웨어 인프라로 오해받기 쉽다 - 소프트웨어 플랫폼 기획에서는 명확성을 위해 이 용어를 배제하는 것이 전략적으로 유리하다

3 관점 비교 및 선택 기준

3.1 종합 비교표

용어	초점	핵심 질문	AI Agent 적합성	담당 역할
Software Architecture	구조 설계	“10년 후에도 유지 가능한가?”	⭐⭐⭐⭐⭐ 최적	Software Architect, Staff Engineer
Platform Engineering	개발자 경험	“5분 안에 배포 가능한가?”	⭐⭐⭐⭐⭐ 최적	Platform Engineer, DevOps Engineer
Systems Engineering	물리적 통합	“하드웨어와 소프트웨어 통합?”	⭐ 부적합	Systems Engineer (항공/국방)

3.2 각 관점이 답하는 질문의 차이

3.2.1 같은 문제, 다른 질문

상황: “새로운 AI Agent를 추가하려고 한다”

# Software Architect의 질문
"이 Agent가 기존 시스템 구조에 어떻게 통합되는가?"
"의존성 방향이 올바른가?"
"인터페이스가 확장 가능한가?"
"10년 후 Agent가 1000개로 늘어나도 이 구조가 유지되는가?"

# Platform Engineer의 질문
"개발자가 5분 안에 이 Agent를 배포할 수 있는가?"
"공통 모듈을 재사용하기 쉬운가?"
"CI/CD가 자동으로 작동하는가?"
"모니터링이 자동으로 설정되는가?"
"장애 시 10분 안에 롤백 가능한가?"

# Systems Engineer의 질문 (우리와 무관)
"센서 데이터를 어떻게 수집하는가?"
"하드웨어 제약은 무엇인가?"
"안전 인증이 필요한가?"

3.2.2 실제 사례로 본 차이

Uber의 ML Platform 구축 (2016-2019)

Phase 1: Architecture 결정 (Software Architecture 관점) - 문제: 각 ML 팀이 독자적으로 모델 학습 파이프라인 구축 - 결정: Michelangelo Platform으로 통합 - Monorepo 채택 - 표준 Model 인터페이스 정의 - Feature Store 아키텍처 설계 - 소요 시간: 6개월 (설계) - 결과물: 아키텍처 문서, 인터페이스 스펙

Phase 2: Platform 구축 (Platform Engineering 관점) - 문제: 설계는 완료했지만 개발자가 사용하기 어려움 - 해결: ```python # 개발자 경험 개선 - 3줄로 모델 배포 from michelangelo import Model

model = Model.load(“my_model”) model.deploy() # 자동으로 인프라 프로비저닝, 모니터링 설정 ``` - 소요 시간: 1년 (구현 + 자동화) - 결과: 모델 배포 시간 3주 → 1일

교훈: Architecture는 “무엇을 만들 것인가”, Platform Engineering은 “어떻게 쉽게 만들 것인가”를 다룬다.

3.3 AI Agent Platform에 적합한 관점

3.3.1 추천: Software Architecture + Platform Engineering 융합

왜 두 관점이 모두 필요한가?

# Architecture 없이 Platform만 구축하면
❌ 단기적으로는 빠르지만 장기적으로 붕괴
❌ 기술 부채 누적
❌ Agent가 늘어날수록 유지보수 불가능

# Platform 없이 Architecture만 설계하면
❌ 완벽한 설계도이지만 아무도 사용 안 함
❌ 개발자가 복잡도를 모두 떠안음
❌ 생산성 저하

융합 접근법:

영역	Software Architecture	Platform Engineering
저장소 구조	Monorepo 구조 설계	Bazel/Turborepo 빌드 시스템 구축
Agent 인터페이스	BaseAgent 추상 클래스 설계	Agent 템플릿 자동 생성 도구
공통 모듈	shared/ 모듈 구조 설계	패키지 매니저 설정, 의존성 자동 해결
배포	배포 전략 정의	CI/CD 파이프라인 자동화
모니터링	메트릭 정의	대시보드 자동 생성

3.3.2 실무 적용 단계

1단계: Architecture 먼저 (1-2개월) - Monorepo vs Polyrepo 결정 - 모듈 구조 설계 (core, shared, agents) - BaseAgent 인터페이스 정의 - 의존성 방향 규칙 수립

2단계: Platform 구축 (2-3개월) - Agent 템플릿 생성 스크립트 - CI/CD 파이프라인 구성 - 모니터링 자동화 - 개발자 문서 작성

3단계: 반복 개선 (지속) - 개발자 피드백 수집 - 병목 지점 자동화 - 새로운 공통 패턴 발견 시 플랫폼에 추가

3.4 용어 사용 권장사항

3.4.1 기획서/제안서에 쓸 표현

✅ 권장: - “AI Agent Platform 구축” - “Platform Engineering 관점에서 개발자 경험 최적화” - “Software Architecture 설계” - “AI Agent Platform Architecture”

❌ 피해야 할 표현: - “Systems Engineering 기반 설계” (하드웨어 시스템으로 오해) - “단순 DevOps 자동화” (너무 좁은 범위) - “LLMOps만으로 해결” (운영 측면만 다룸)

3.4.2 명확한 소통을 위한 용어 분리

프로젝트 단계별 용어 사용: 1. 기획 단계: “AI Agent Platform 아키텍처 설계” 2. 설계 단계: “Software Architecture - Monorepo 구조, 모듈 설계” 3. 구축 단계: “Platform Engineering - IDP 구축, 자동화” 4. 운영 단계: “DevOps/LLMOps - 배포, 모니터링”

4 다음 단계

이 글에서 “어떤 관점으로 접근할 것인가”를 정했다면, 다음 질문은:

“그럼 실제로 어떻게 설계하는가?”

다음 글 “AI Agent 플랫폼 설계의 5대 원칙과 점진적 추상화 전략”에서는: - 5대 설계 원칙: Interface Segregation, Dependency Inversion 등 - 점진적 추상화 전략: POC → 패턴 발견 → 추상화 (Phase 1-4) - 실제 코드 예시: BaseAgent 구현, LLM 클라이언트 추상화 등 - 실증 사례: Google Borg, Uber ML Platform, Airbnb Airflow

을 다룬다.

4.1 참고문헌

Platform Engineering: - Spotify Engineering (2020). “What the Heck is Backstage Anyway?” Spotify Engineering Blog. - Netflix Technology Blog (2016). “Netflix Conductor: A microservices orchestrator.” Netflix Tech Blog. - CNCF (2020). “Backstage: Spotify’s open platform for building developer portals.” CNCF Project.

Software Architecture: - Richards, M., & Ford, N. (2020). “Fundamentals of Software Architecture.” O’Reilly. - Martin, R. C. (2017). “Clean Architecture.” Prentice Hall.

Case Studies: - Uber Engineering (2017). “Meet Michelangelo: Uber’s Machine Learning Platform.” Uber Engineering Blog. - Twitter Engineering (2021). “Monorepo at Twitter.” Twitter Engineering Blog.