AI 에이전트가 소프트웨어의 1차 사용자로 떠오르는 지금, 기존 UI 중심 소프트웨어 패러다임은 어떻게 바뀌고 있을까요? 핵심은 단순히 “챗봇을 붙였다”가 아니라, 소프트웨어 인프라(Software Infra) 자체가 ‘사람이 클릭하는 제품’에서 ‘에이전트가 호출하는 시스템’으로 재설계되고 있다는 점입니다.
Software Infra 패러다임 전환: UI-first에서 Invocation-first로
전통적인 엔터프라이즈 소프트웨어는 UI를 중심으로 설계되어 왔습니다. 사람이 화면에서 폼을 채우고, 버튼을 누르고, 예외 상황은 매뉴얼로 처리하는 방식이 자연스러웠죠. 하지만 에이전트는 다릅니다. 에이전트에게 UI는 느리고 불확실한 우회로에 가깝습니다. 에이전트가 원하는 건 다음입니다.
- 호출 가능한 명확한 인터페이스(API)
- 기계가 이해할 수 있는 스키마와 제약 조건(메타데이터)
- 예측 가능한 결과(결정론적 동작)와 되돌리기(롤백) 전략
- 권한 위임과 통제(RBAC, 스코프 제한), 감사 로그
- 실패 원인까지 추적 가능한 관찰성(로그·메트릭·트레이스)
이 요구사항이 합쳐지면, 소프트웨어는 “headless”를 넘어 invocation-first(호출 우선)로 진화합니다. 즉, 눈에 보이는 UI가 중심이 아니라 에이전트가 기능을 탐색하고(discover), 조합하고(compose), 실행하는(invocation) 방식이 중심이 됩니다.
Software Infra가 달라져야 하는 이유: 에이전트는 ‘사용’이 아니라 ‘운영’한다
에이전트는 단순한 자동화 스크립트가 아닙니다. 업무를 쪼개고, 순서를 정하고, 예외를 처리하며, 여러 시스템을 묶어 하나의 엔드투엔드 워크플로를 운영합니다. 예를 들어 “구매 요청 생성 → 승인 요청 → 예산 확인 → 발주 생성” 같은 흐름을 사람이 UI로 처리하던 시대에는 중간에 멈추거나 예외가 생겨도 사람이 판단하면 됐습니다.
하지만 에이전트가 주체가 되면 이야기가 달라집니다.
- 중간 상태가 모호하면 다음 액션을 선택할 수 없고
- 에러 코드가 일관되지 않으면 재시도/대체 플로우 설계가 어렵고
- 어떤 권한으로 무엇을 실행했는지 추적할 수 없으면 거버넌스가 붕괴합니다
그래서 에이전트 시대의 Software Infra는 “편한 UI”보다 명세 가능한 동작, 상태 모델, 트랜잭션 안정성을 더 우선시하게 됩니다. 사람 중심 SaaS가 “사용성(UX)”을 경쟁력으로 삼았다면, 에이전트-네이티브 인프라는 “호출성(Invocation UX)”—즉, 모델이 읽고 실행하기 쉬운 시스템 설계가 경쟁력이 됩니다.
Software Infra 설계 체크리스트: 에이전트-네이티브가 되려면
에이전트가 1차 사용자라면, 최소한 아래 조건을 만족해야 합니다(단순 API 제공만으로는 부족합니다).
- Programmatically discoverable: OpenAPI/JSON Schema 등으로 기능·입력·제약·에러 모드를 기계가 해석 가능해야 함
- Instantly operable: 인간 온보딩 없이도 에이전트가 문서/예제로 즉시 실행 가능해야 함
- Reliable & deterministic: 같은 입력에 대한 일관된 출력, 예측 가능한 상태 전이가 있어야 함
- Permissioned & governed: 역할 기반 권한과 세밀한 스코핑, 승인 체계, 강한 감사(audit)가 필수
- Observable: 호출 단위의 로그·메트릭·트레이스가 남아 디버깅과 책임 추적이 가능해야 함
결론적으로, “에이전트가 소프트웨어를 쓴다”는 말은 기능을 대리 실행한다는 수준을 넘어, Software Infra의 인터페이스와 운영 철학이 통째로 바뀐다는 뜻입니다. 이제 제품은 사람의 클릭을 최적화하는 대신, 에이전트의 호출과 조합을 최적화하는 방향으로 이동하고 있습니다.
Software Infra 관점의 Invocation-First: UI를 넘어선 새로운 소프트웨어 인프라
‘헤드리스(headless)’가 프론트엔드와 백엔드를 분리해 UI 교체의 자유를 준 혁신이었다면, 지금은 한 단계 더 나아가 Invocation-first라는 흐름이 등장하고 있습니다. 핵심은 간단합니다. 사람이 클릭하는 UI가 아니라, AI 에이전트와 LLM이 “호출(invocation)”하는 인터페이스가 소프트웨어의 중심이 되는 것입니다. 이제 Software Infra의 1차 사용자는 점점 “사용자(직원)”가 아니라 “모델/에이전트”로 이동하고 있습니다.
Software Infra의 패러다임 전환: Headless에서 Invocation-first로
기존 headless 아키텍처는 “프론트엔드가 없어도 되는 백엔드”에 가까웠습니다. 반면 Invocation-first는 “주 인터페이스가 시각적 UI가 아닌 소프트웨어”를 뜻합니다. UI는 남아도 됩니다. 다만 우선순위가 바뀝니다.
- 과거(UI-first SaaS): 사람이 화면에서 폼을 채우고 버튼을 누른다 → API는 보조 수단
- 현재/미래(Invocation-first): 에이전트가 API/워크플로를 호출해 작업을 끝낸다 → UI는 모니터링/예외 처리 중심
이 변화는 단지 “API를 더 잘 만들자” 수준이 아니라, 제품과 플랫폼의 설계 목표 자체가 ‘에이전트 친화성’으로 재정의되는 것을 의미합니다.
Software Infra가 Invocation-first가 되기 위한 6가지 조건
에이전트는 사람처럼 UI를 탐색하지 않습니다. 대신 문서·스키마·정책·에러 규약을 바탕으로 기능을 발견하고, 호출하고, 실패를 복구하며, 여러 서비스를 조합합니다. 그래서 Invocation-first Software Infra는 다음 요건을 사실상 “기본값”으로 요구합니다.
1) Programmatically discoverable (기계가 발견 가능)
- OpenAPI/JSON Schema 같은 스키마로 “무엇을 할 수 있는지”가 표현돼야 합니다.
- 각 액션의 입력 파라미터, 제약, 상태 전이, 에러 타입이 구조적으로 정의돼야 LLM이 안전하게 호출합니다.
2) Instantly operable (즉시 실행 가능)
- 사람 온보딩을 전제로 한 복잡한 설정 절차는 에이전트 환경에서 병목이 됩니다.
- “토큰 발급 → 최소 권한 부여 → 샘플 호출 → 결과 검증”까지가 자동화 가능한 형태여야 합니다.
3) Well-documented (모델이 읽을 수 있는 문서)
- 인간 친화적 설명만으로는 부족합니다.
- 모델이 파싱하기 쉬운 예제(요청/응답), 실패 케이스, 재시도 가이드, 멱등성(idempotency) 규칙이 필요합니다.
4) Reliable & deterministic (신뢰 가능하고 결정론적)
- 에이전트는 여러 단계를 계획하고 실행합니다. 중간 단계가 흔들리면 전체 플로우가 무너집니다.
- 같은 입력에 대해 결과가 일관되어야 하고, 상태 기반 워크플로(예: 요청 생성→승인→발주)는 예측 가능한 상태 모델로 제공돼야 합니다.
5) Permissioned & governed (권한과 거버넌스)
- 에이전트가 결제, 조달, 권한 변경을 수행하는 순간부터 보안 모델이 달라집니다.
- RBAC(역할 기반), 세밀한 스코프 제한, 승인 체인, 감사 로그는 “옵션”이 아니라 핵심 기능입니다.
6) Observable (관찰 가능성)
- “에이전트가 무엇을 호출했고, 왜 실패했고, 어떤 부작용을 남겼는지”를 추적할 수 있어야 합니다.
- 호출 로그, 분산 트레이싱, 이벤트 타임라인, 롤백/보상 트랜잭션 정보까지 연결돼야 디버깅이 가능합니다.
Software Infra에서 벌어지는 실제 미래: 에이전트가 ‘조합’하는 업무
Invocation-first가 중요한 이유는, 에이전트가 단일 API만 호출하는 게 아니라 여러 시스템을 묶어 하나의 업무를 끝내는 “조합자(composer)”로 움직이기 때문입니다. 예를 들어 조달 업무를 생각해 보면:
- 계약/CRM 서비스에서 조건에 맞는 공급사 후보를 검색하고
- 조달 시스템에서 견적 요청(RFQ)을 자동 생성·발송한 뒤
- 재무 시스템에서 예산을 확인하고
- 승인 워크플로를 트리거하고
- 모든 과정을 감사 로그와 이벤트로 남긴다
이때 UI는 “업무를 수행하는 장소”가 아니라, 에이전트가 만든 결과를 검토하고 예외를 처리하는 관제 콘솔로 이동합니다. 즉, Invocation-first Software Infra는 “자동화”가 아니라 업무 실행 주체가 사람에서 에이전트로 바뀌는 구조적 변화를 전제합니다.
왜 지금 Software Infra에서 이 전환이 가속되는가
이 흐름이 갑자기 가능해진 배경에는 두 가지가 겹칩니다.
- LLM 에이전트의 확산: 단순 챗봇이 아니라, 실제 시스템을 호출해 업무를 처리하는 에이전트가 늘었습니다.
- AI 런타임/오케스트레이션의 성숙: Kubernetes 기반 모델 서빙, GPU 오케스트레이션, 운영 자동화가 갖춰지면서 “에이전트가 쓸 수 있는 안정적 실행 토대”가 생겼습니다.
정리하면, 이제 Software Infra는 UI를 잘 만드는 경쟁에서, 에이전트가 안전하게 호출하고 조합할 수 있는 ‘호출 중심 인프라’를 제공하는 경쟁으로 이동하고 있습니다. Invocation-first는 그 변화의 이름입니다.
Software Infra 관점에서 본 AI 데이터센터부터 에이전트-네이티브 앱까지, 인프라의 새로운 층위
NVIDIA GPU 오퍼레이터부터 Kubernetes 기반 AI 워크로드 관리까지. 지금 벌어지는 변화의 핵심은 “GPU가 몇 장이냐”가 아니라, AI 데이터센터 스택 전체가 에이전트-네이티브 아키텍처를 떠받치는 실행 토대(런타임)로 재정의되고 있다는 점입니다. 다시 말해, AI 에이전트가 기업 시스템을 ‘사용자’로서 호출·조합하기 시작하면서, Software Infra는 UI 중심 SaaS를 보조하던 레이어에서 에이전트 호출(invocation) 중심의 1차 인터페이스를 지탱하는 레이어로 올라섰습니다.
Software Infra의 바닥층: AI 데이터센터 스택이 “에이전트 런타임”이 되는 과정
에이전트가 업무를 수행하려면, 결국 아래에서 안정적으로 돌아가는 연산/네트워크/클러스터가 필요합니다. 최근의 AI 데이터센터 스택은 이 기반을 Kubernetes-네이티브 방식으로 표준화하고 있는데, 그 이유는 간단합니다. 에이전트 워크로드(LLM 서빙, 임베딩 생성, RAG 파이프라인, 배치 추론)는 트래픽과 자원 수요가 요동치고, 실패·재시도·롤백을 전제로 운영돼야 하기 때문입니다.
이때 핵심 구성요소는 다음처럼 “레이어드(층위화)”됩니다.
- Infra Layer (데이터센터 하부): GPU/CPU, 스토리지, 네트워크, 드라이버
- AI Platform & Orchestration: Kubernetes, GPU 스케줄링, 모델 서빙 운영
- Invocation-first App/Service: 에이전트가 호출하는 업무 API(결정론/권한/감사/관찰성 포함)
- Agent Layer: LLM·에이전트가 위 서비스들을 탐색·선택·조합
중요한 포인트는, 에이전트-네이티브 앱의 품질(신뢰성/재현성/거버넌스)이 위쪽 레이어만으로 결정되지 않는다는 점입니다. 아래쪽 AI 인프라가 제공하는 일관된 실행 환경과 운영 통제력이 곧 상위 레이어의 “결정론”을 가능하게 합니다.
Software Infra의 실전 핵심: Kubernetes에서 GPU를 ‘운영 가능한 리소스’로 만드는 NVIDIA Operator들
AI 데이터센터 스택의 성숙을 상징하는 키워드가 바로 Operator(오퍼레이터)입니다. 오퍼레이터는 Kubernetes에서 특정 하드웨어/소프트웨어 스택을 “클러스터가 관리하는 제품”으로 승격시킵니다. 특히 NVIDIA 생태계에서 자주 등장하는 세 가지 축은 다음과 같습니다.
NVIDIA GPU Operator
Kubernetes 노드에 GPU 드라이버, CUDA 관련 구성요소 등을 정책 기반으로 배포·업데이트하고, GPU를 스케줄러가 인식 가능한 리소스로 노출합니다. 결과적으로 GPU는 “수동 설치가 필요한 장비”가 아니라, 클러스터가 선언적으로 관리하는 자원이 됩니다.NVIDIA Network Operator
고속 네트워크, RDMA 등 AI 워크로드의 병목을 좌우하는 네트워킹 경로를 최적화합니다. LLM 서빙은 단일 GPU 성능만큼이나 노드 간 통신/스토리지 경로에 민감하기 때문에, 네트워크 운영이 곧 서빙 안정성으로 직결됩니다.NVIDIA NIM Operator (NIM 마이크로서비스 운영)
LLM·임베딩 등 모델 실행을 마이크로서비스 형태로 운영할 때, 배포/업데이트/스케일링/헬스체크 같은 운영 단위를 Kubernetes 방식으로 묶어줍니다. 이는 상위 레이어의 에이전트 입장에서 “모델 호출”을 예측 가능한 서비스 호출로 바꿔주는 장치입니다.
여기에 Run:ai 같은 Kubernetes-네이티브 GPU 오케스트레이션이 결합되면, 조직은 GPU를 팀/워크로드 단위로 할당하고, 우선순위·큐잉·공유 정책을 통해 GPU 활용률과 납기(시간) 예측을 동시에 개선할 수 있습니다. 에이전트가 늘어날수록 호출량이 폭증하는데, 이때 “운영 가능한 GPU”는 곧 비용과 안정성을 동시에 지키는 Software Infra의 핵심 역량이 됩니다.
Software Infra가 연결하는 중간층: “모델 서빙”에서 “에이전트 호출 가능한 플랫폼”으로
AI 플랫폼 레이어가 성숙하면, 상위의 업무 시스템도 자연스럽게 바뀝니다. 기존에는 CRM/ERP/조달/ITSM 같은 엔터프라이즈 시스템이 사람의 클릭과 폼 입력을 전제로 설계되었습니다. 그러나 에이전트-네이티브 세계에서는 이 앱/서비스 레이어가 invocation-first로 재설계되어야 합니다.
구체적으로는 다음 조건을 만족하는 방향으로 진화합니다.
- Programmatically discoverable: OpenAPI/JSON Schema 등으로 액션·파라미터·에러 모드를 기계가 이해
- Reliable & deterministic: 동일 입력에 대한 일관된 결과와 명확한 상태 전이(워크플로 단계)
- Permissioned & governed: 에이전트에 위임되는 권한을 역할·범위·시간 단위로 제한하고 감사 가능
- Observable: 호출 로그, 트레이스, 부작용(데이터 변경/결제/발주)까지 추적 가능
이 네 가지가 맞물리면, 에이전트는 더 이상 “불안정한 자동화 스크립트”가 아니라 기업 시스템을 안전하게 호출·조합하는 실행자가 됩니다. 그리고 여기서 Software Infra의 역할은 API 게이트웨이나 런타임을 제공하는 것을 넘어, 결정론/권한/관찰성을 포함한 운영 규격 자체를 플랫폼으로 제공하는 쪽으로 확장됩니다.
Software Infra로 보는 전체 그림: 왜 ‘층위’가 중요해졌나
에이전트-네이티브는 한 개의 제품 트렌드가 아니라 스택 전체의 재배치입니다.
- 아래에서는 GPU·네트워크·드라이버가 Kubernetes 오퍼레이터로 표준화되고
- 그 위에서는 모델 서빙이 운영 가능한 마이크로서비스(NIM 등)로 정제되며
- 더 위에서는 업무 시스템이 invocation-first로 재설계되어
- 최상단에서 에이전트가 이 모든 것을 “툴 체인”으로 호출·조합합니다.
결국 경쟁력의 핵심은 “에이전트를 붙였다”가 아니라, 에이전트가 믿고 호출할 수 있는 결정론적 실행 환경과 통제 가능한 운영 체계를 end-to-end로 제공하느냐에 달려 있습니다. 그리고 그 중심에, 지금 가장 빠르게 진화하는 Software Infra가 있습니다.
Software Infra 관점에서 본 기존 엔터프라이즈 인프라와의 결정적 차이점과 도전 과제
사람을 1차 사용자로 삼던 전통적 시스템과 완전히 다른, 에이전트-네이티브 소프트웨어가 마주한 리스크와 표준 부재, 보안 이슈는 무엇일까요? 결론부터 말하면, UI 중심의 “사용자 경험 최적화” 문제가 아니라, 에이전트가 호출(invocation)해 조합하는 순간 발생하는 “시스템 신뢰성·통제·증명 가능성” 문제가 Software Infra의 핵심 과제가 됩니다.
Software Infra에서 바뀌는 전제: “사람의 클릭”이 아니라 “에이전트의 호출”이 기준선
기존 엔터프라이즈 앱은 사람이 화면을 보며 맥락을 보완합니다. 입력 폼이 조금 불친절해도, 상태가 다소 모호해도 “눈치”로 진행이 됩니다. 반면 에이전트-네이티브 환경에서 1차 사용자는 LLM/에이전트입니다. 즉, 인터페이스는 대화형 UI가 아니라 기계가 이해하고 실행할 수 있는 API·스키마·워크플로가 됩니다.
이 전제 변화는 곧바로 다음 요구로 이어집니다.
- 결정론(determinism): 같은 입력이면 같은 결과/상태 전이가 재현돼야 함
- 관찰 가능성(observability): “에이전트가 무엇을 호출했고 어떤 부작용을 만들었는지”를 추적 가능해야 함
- 권한 위임과 통제(governance): 에이전트가 대신 실행하는 트랜잭션을 안전하게 제한해야 함
- 기계가독 문서·메타데이터(discoverability): 에이전트가 기능을 탐색·선택·조합할 수 있어야 함
이는 단순 기능 추가가 아니라, Software Infra 설계 철학 자체를 갈아엎는 변화입니다.
Software Infra 리스크 1: “환각”이 아니라 “부작용(side effect)”이 사고의 본질이 된다
에이전트가 다루는 업무는 조회로 끝나지 않습니다. 조달 요청 생성, 승인 라우팅, 권한 변경, 결제 등 외부 상태를 바꾸는 액션이 많습니다. 이때 위험은 단순히 “답변이 틀렸다”가 아니라, 잘못된 호출이 실제 시스템에 변경을 남긴다는 점입니다.
기술적으로는 다음 장치가 중요해집니다.
- 명시적 상태 모델링: 요청이
draft → submitted → approved → ordered처럼 상태 기계로 정의돼야 에이전트가 안전하게 다음 단계를 판단할 수 있습니다. - 멱등성(idempotency)과 재시도 전략: 네트워크 실패나 타임아웃이 있어도 중복 발주/중복 결제를 막아야 합니다.
- 롤백/보상 트랜잭션(Saga): “부분 성공”이 발생하는 분산 환경에서, 실패 시 어떤 보상 동작을 할지 API 수준에서 설계해야 합니다.
- 시뮬레이션/드라이런(dry-run): 실제 반영 전에 영향 범위를 미리 계산해 에이전트가 검증 단계를 거치도록 해야 합니다.
즉, 에이전트-네이티브 전환은 “LLM 품질”만의 문제가 아니라, 실행 계층의 안전장치가 포함된 Software Infra로의 확장입니다.
Software Infra 리스크 2: 표준 부재—OpenAPI만으로는 “에이전트가 실행 가능한 시스템”이 되기 어렵다
전통적 API 문서(OpenAPI 등)는 사람 개발자에게는 충분했지만, 에이전트가 “스스로” 호출·조합하기에는 빈틈이 많습니다. 예를 들어 에이전트가 진짜로 필요로 하는 정보는 다음과 같습니다.
- 입력 파라미터의 타입뿐 아니라 제약 조건(허용 범위, 금지 조합, 선행 조건)
- 실패했을 때의 에러 모드 분류(재시도 가능/불가능, 사용자 확인 필요, 권한 부족 등)
- 호출이 만드는 부작용의 종류(결제 발생, 권한 변경, 외부 이메일 발송 등)
- 비용·쿼터·레이트리밋 및 안전한 호출 빈도
- 단계적 워크플로의 선후관계와 상태 전이 규칙
이 때문에 에이전트-네이티브 생태계는 당분간 “각 벤더가 제각각의 캡빌리티 서술 방식”을 내놓는 과도기를 겪을 가능성이 큽니다. Software Infra 관점에서 이는 통합 비용 증가로 직결됩니다.
- 에이전트가 툴을 “발견”하는 방식이 제각각이면, 툴 레지스트리/카탈로그 통합이 어려워집니다.
- 에러·상태·권한 모델이 통일되지 않으면, 에이전트 오케스트레이션은 결국 “커스텀 코드/프롬프트”에 의존하게 됩니다.
- 결과적으로 “범용 에이전트”가 아니라 “시스템별 전용 에이전트”가 양산되어 유지보수가 악화됩니다.
Software Infra 리스크 3: 보안·거버넌스—에이전트는 ‘새로운 직원’이 아니라 ‘새로운 런타임’이다
기존 RBAC는 “사람 사용자 계정”을 기준으로 설계되어 왔습니다. 하지만 에이전트는 다음 특성 때문에 보안 모델을 흔듭니다.
- 다수 시스템(CRM/ERP/조달/결제)을 횡단 호출한다
- 한 번 부여된 토큰/키가 자동화 흐름에서 연쇄적으로 사용된다
- 프롬프트 인젝션, 도구 오용 등으로 의도치 않은 호출 경로가 열릴 수 있다
따라서 권한은 “사람이 무엇을 할 수 있나”가 아니라, 워크플로/행위 단위로 최소 권한을 어떻게 위임할 것인가가 핵심입니다.
실무적으로는 다음이 중요해집니다.
- 세분화된 스코프: “결제 실행”과 “결제 초안 생성”을 분리하고, 에이전트에는 기본적으로 초안 권한만 부여
- 승인 게이트(Policy/Approval): 특정 금액 이상, 특정 공급사, 특정 데이터 접근은 사람 승인 또는 별도 정책 엔진 통과
- 비밀 관리(Secrets)와 실행 환경 격리: 토큰을 프롬프트/로그에 남기지 않도록 런타임 차원에서 차단
- 감사 추적(Audit trail): 누가(어떤 에이전트가) 언제 무엇을 왜 호출했는지, 입력·출력·근거를 남겨 사후 분석 가능하게 함
여기서 중요한 포인트는, 에이전트-네이티브 전환이 “보안팀 체크리스트 추가”로 끝나지 않고, Software Infra에 정책·감사·관찰성을 기본 내장해야 하는 구조 변화라는 점입니다.
Software Infra 운영 도전: 관찰 가능성이 “옵션”에서 “디버깅의 생명줄”로 바뀐다
전통적 서비스는 사용자 행동이 UI 이벤트로 남고, 장애는 서버 로그/메트릭으로 추적하면 됐습니다. 하지만 에이전트는 한 번의 목표 달성을 위해 여러 툴을 연쇄 호출하며, 중간에 재시도·분기·대체 경로를 선택합니다. 따라서 운영 관점에서 필요한 것은 단순 로그가 아니라:
- 분산 트레이싱 기반의 호출 체인(어떤 계획에서 어떤 API들이 어떤 순서로 실행됐는지)
- 실패 원인 분류(모델 추론 오류 vs 권한 거부 vs 외부 시스템 타임아웃)
- 부작용 추적(어떤 호출이 어떤 데이터 변경/외부 알림을 만들었는지)
- 리플레이/재현 가능성(동일 입력과 상태에서 같은 흐름을 재현해 원인 분석)
즉, 에이전트-네이티브 시대의 Software Infra는 “실행을 잘하게 하는 인프라”를 넘어 “실행을 증명하고, 추적하고, 통제하는 인프라”까지 포함해야 합니다.
Software Infra 관점에서 본 플랫폼 팀과 엔지니어가 반드시 주목해야 할 변화와 실전 팁
‘Infrastructure as Software’와 AI 인프라 오케스트레이션, 그리고 에이전트-네이티브 시스템 구축은 더 이상 “미래 이야기”가 아닙니다. 플랫폼 팀이 제공하는 대상이 개발자만이 아니라 LLM·에이전트로 확장되면서, Software Infra의 설계 기준도 함께 바뀌고 있습니다. 핵심은 사람의 클릭이 아니라 에이전트의 호출(invocation)을 중심으로 플랫폼을 재구성하는 것입니다.
Software Infra의 관점 전환: 플랫폼의 1차 사용자가 “사람 → 에이전트”로 바뀐다
기존 내부 플랫폼은 “개발자가 셀프서비스로 쓰는 제품”에 가까웠습니다. 하지만 에이전트가 1차 사용자가 되면 요구사항이 달라집니다.
- UI-first에서 Invocation-first로: UI는 보조 채널이 되고, 에이전트가 호출하는 API/워크플로가 주 인터페이스가 됩니다.
- 문서의 목적이 바뀜: 사람에게 친절한 가이드보다, 모델이 파싱 가능한 구조적 문서(스키마·예제·에러 모드)가 중요합니다.
- 운영의 목표가 바뀜: “서비스가 살아있다”를 넘어, 에이전트가 여러 툴을 조합하는 과정에서 실패를 복구하고 재시도할 수 있을 만큼 결정론적이고 관찰 가능해야 합니다.
즉, 플랫폼 팀은 이제 에이전트가 안전하게 탐색하고 실행할 수 있는 ‘기계가독형 제품’을 만든다고 생각해야 합니다.
Software Infra 실전 전략 1: Infrastructure as Software(IaS)로 “플랫폼을 코드가 아닌 제품”으로 만든다
에이전트-네이티브 환경에서는 인프라가 더 자주 바뀌고(모델/서빙/클러스터 구성), 더 엄격한 안전장치(권한/감사/롤백)가 요구됩니다. IaS는 이 복잡성을 견디게 해주는 실전 해법입니다.
IaS로 반드시 가져가야 하는 엔지니어링 요소
- 타입/스키마 우선 설계: 리소스를 “문자열 설정”이 아니라 타입으로 모델링해 잘못된 조합을 컴파일/리뷰 단계에서 차단합니다.
- 추상화와 패키징: GPU 노드풀, 추론 서빙, 비밀 관리, 정책(RBAC) 등을 재사용 가능한 모듈로 패키징합니다.
- 테스트 가능한 인프라: 변경이 잦은 AI 인프라에서 회귀를 막으려면, 정책/네트워크/권한/리소스 쿼터를 테스트 대상으로 포함해야 합니다.
- CI/CD와 승인 게이트: 에이전트가 호출하는 워크플로(예: “조달 요청 생성”)까지 포함해, 배포 파이프라인에 정책 검사와 변경 승인 단계를 넣습니다.
정리하면, 에이전트가 호출할 플랫폼은 ‘코드로 정의된 인프라’가 아니라 ‘소프트웨어 공학으로 운영되는 인프라’여야 합니다.
Software Infra 실전 전략 2: AI 인프라 오케스트레이션을 “쿠버네티스 + GPU 운영” 관점에서 표준화한다
에이전트-네이티브 시스템이 확산될수록, LLM/임베딩/벡터 검색 같은 워크로드는 상시 운영 대상이 됩니다. 따라서 플랫폼 팀은 GPU를 포함한 AI 인프라 스택을 안정적으로 오케스트레이션해야 합니다.
현장에서 자주 필요한 구성 축
- 드라이버/런타임 표준화: GPU 드라이버, 네트워크 최적화, 컨테이너 런타임 호환성을 먼저 고정해야 상위 레이어가 흔들리지 않습니다.
- Kubernetes 오퍼레이터 기반 운영: GPU/네트워크/모델 서빙 컴포넌트를 오퍼레이터로 관리하면, 선언적 운영(Desired State)과 업데이트 전략을 일관되게 가져갈 수 있습니다.
- GPU 스케줄링/쿼터/공정성: 학습/추론/배치가 섞이면 GPU는 항상 부족합니다. 팀/서비스/워크로드 단위의 스케줄링 정책과 우선순위 체계가 핵심입니다.
- 서빙 계층의 운영성: 모델은 “올리는 것”보다 “바꾸는 것(버전, 라우팅, 롤백)”이 더 어렵습니다. 카나리, A/B, 자동 롤백이 가능한 형태로 표준화해야 합니다.
여기서 중요한 포인트는, AI 인프라 오케스트레이션이 단순한 성능 문제가 아니라 플랫폼 신뢰성의 기반이라는 점입니다. 에이전트가 여러 호출을 연쇄적으로 실행할수록, 하위 인프라의 작은 불안정이 상위 비즈니스 플로우 장애로 증폭됩니다.
Software Infra 실전 전략 3: 에이전트-네이티브 시스템을 위한 “호출 설계 규격”을 강제하라
에이전트가 잘 동작하는 조직은 공통점이 있습니다. “에이전트가 알아서 하겠지”가 아니라, 에이전트가 호출하기 좋은 시스템 규격을 플랫폼 레벨에서 강제합니다.
Invocation-first 설계 체크리스트
- Programmatically discoverable: OpenAPI/JSON Schema 등으로 액션, 파라미터, 제약, 에러 모드를 기계가 이해 가능하게 제공합니다.
- Deterministic & reliable: 동일 입력에 대한 일관된 결과, 명확한 상태 전이(생성/진행/완료/실패), 멱등성(idempotency)을 보장합니다.
- Permissioned & governed: 에이전트 권한은 사람 권한을 그대로 복제하지 말고, 업무 단위로 스코프를 최소화합니다. 토큰 수명, 실행 한도, 승인 단계(예: 결제 전 human-in-the-loop)도 정책화해야 합니다.
- Observable: “에이전트가 무엇을 호출했고 어떤 부작용을 만들었는지”를 추적할 수 있어야 디버깅이 됩니다. 로그/메트릭/트레이스에 더해, 호출 체인과 최종 의사결정 근거를 남길 수 있는 이벤트 모델이 필요합니다.
팁 하나만 꼽자면, 에이전트 호출을 ‘분산 트랜잭션’으로 취급하세요. 재시도·타임아웃·부분 실패·보상 트랜잭션(롤백/취소)을 설계에 포함하지 않으면, 자동화 수준이 올라갈수록 사고도 커집니다.
Software Infra 실전 팁: 플랫폼 팀이 이번 분기에 바로 할 수 있는 5가지
- API/워크플로의 스키마 표준 정하기: “문서 잘 쓰자”가 아니라, 스키마와 예외 모델을 표준으로 고정합니다.
- 권한 모델을 에이전트 기준으로 재설계: RBAC에 “에이전트 역할”을 추가하고, 작업 단위 최소 권한과 감사 로그를 의무화합니다.
- 관찰 가능성(Observability) 기준을 올리기: 에이전트 호출 ID로 전 구간 트레이싱이 되도록 로그·트레이스 상관관계를 강제합니다.
- GPU/서빙 운영을 제품화: 클러스터/서빙을 “요청하면 만들어주는” 수준이 아니라, 쿼터·비용·SLO가 포함된 셀프서비스로 만듭니다.
- IaS 모듈화로 변경 속도 확보: AI 워크로드는 변동이 크므로, 인프라 변경을 “안전하게 자주” 할 수 있는 구조가 경쟁력이 됩니다.
결론적으로, 에이전트-네이티브 전환은 애플리케이션만의 변화가 아니라 Software Infra의 운영 철학 자체를 바꾸는 사건입니다. 플랫폼 팀이 지금 이 흐름을 선점하면, 에이전트가 늘어날수록 조직의 자동화 능력과 운영 안정성이 함께 올라가게 됩니다.
