IBM의 개발자 대상 이벤트인 'IBM TechXchange 2026 Atlanta'에 참가했습니다.
인생에서 두 번째 미국 방문입니다!
20261027_124906740_iOS.jpg
이벤트는 전날 파트너를 위한 프로그램으로 시작되었고, 오늘(2026년 10월 27일)부터 일반 참관객을 위한 세션이 본격적으로 시작되었습니다.
글이 상당히 길어졌기 때문에, 먼저 요약본을 작성하겠습니다.
- 2025년은 'AI 에이전트를 만드는' 단계였다면, 2026년은 '기업에서 안전하게 운영하고 확장하는(Scale)' 단계로 넘어갔습니다.
- 공통 데모에서는 AI 여행 컨시어지인 OneKey를 활용하여 데이터, 개발, 통합, ID, 인프라, 운영을 하나의 스토리로 소개했습니다.
- Confluent의 Streamhouse가 최신 업무 컨텍스트를 제공하며, IBM Bob이 개발을 담당하고 watsonx Orchestrate가 에이전트 관리 및 평가를 지원합니다.
- IBM Agent Identity, HashiCorp Vault/Terraform, IBM Concert까지 포함하여 AI 에이전트를 엔터프라이즈 레디(Enterprise Ready)로 만드는 전체 그림이 제시되었습니다.
오늘의 제너럴 세션 영상은 이미 이 링크에 업로드되어 있습니다.
별도의 창에서 열어 영상을 보면서 읽으시면 내용을 더 쉽게 이해하실 수 있을 것 같습니다.
AI가 코드를 작성해주는 시대가 되면서 개발자의 역할도 변화하고 있습니다. 중요한 것은 코드의 줄 수가 아니라 시스템 전체의 설계입니다. 뛰어난 개발자는 더 이상 단순한 '코드 작성자'가 아니라, '전체를 지휘하는 오케스트레이터(Orchestrator)'로서 움직이고 있다는 화두로 시작되었습니다.
TechXchange는 85개국에서 모인 데이터, 인프라, 애플리케이션 등 다양한 분야의 기술자들이 한자리에 모이는 이벤트입니다.
이번 제너럴 세션을 통해 핵심적으로 다루어진 주제는 'AI 에이전트를 어떻게 **엔터프라이즈 레디(Enterprise Ready)**로 만들 것인가'였습니다. 2025년에는 AI 에이전트를 만드는 것이 하나의 목표였다면, 2026년에는 이를 '안정화하고 확장하는(Scale)' 단계에 접어들었다는 설명이었습니다.
여기서 데이터 이야기로 넘어가며, 에이전트가 올바르게 작동하기 위해서는 최신이며 태스크와 관련된 업무 컨텍스트가 필요하다고 설명되었습니다.
주요 논점은 다음과 같습니다.
- 정보의 양이 많다고 좋은 것은 아니다.
- 컨텍스트란 작업을 완료하는 데 필요한 정보이다.
- 에이전트에게는 '현재 무엇이 진실인지'와 '무엇이 변화했는지'가 필요하다.
- 오래된 데이터는 더 빠른 오류를 유발한다.
- 에이전트별로 데이터 연동을 개별적으로 만드는 방식은 확장성이 떨어진다.
여기서는 기존의 두 가지 데이터 연동 방식도 비교되었습니다.
데모에서 보여진 API Federation 방식에서는 에이전트가 필요한 정보를 얻기 위해 여러 시스템에 반복적으로 질의합니다. 따라서 에이전트 수가 증가함에 따라 요청 수와 연동 복잡성이 커집니다.
Bronze, Silver, Gold 단계로 데이터를 가공하면, 에이전트가 필요로 하는 시점에는 정보가 오래되었을 가능성이 있습니다.
데모에서 보여진 기존 구성에서는 호텔 예약 업데이트가 투어 예약 측에서 참조 가능해지기까지 최소 15분이 걸리는 사례가 소개되었습니다.
그 해결책으로 Streamhouse를 통해 최신 예약 상태를 여러 에이전트에게 제공하는 흐름이 설명되었습니다.
이는 Lakehouse 자체를 부정하는 설명이 아니라, 분석 용도를 중심으로 한 단계적인 데이터 가공만으로는 즉시성이 필요한 에이전트 처리에 대응하기 어려운 경우가 있다는 비교입니다.
Streamhouse와 OneKey에 대한 초기 설명이 끝난 후, 화제는 에이전트나 도구를 어떻게 구축할 것인가로 넘어갑니다.
여기서 IBM Bob 이야기가 시작되었습니다.
- IBM 사내에서 다수의 도구와 스킬이 생성되고 있음
- Bob 2.0을 통해 IDE나 Shell 외의 환경에도 Bob을 전개함
- 개발자뿐만 아니라 지식 노동자도 소프트웨어를 만들게 됨
이러한 흐름으로 Bob Desktop이 소개되었습니다.
Bob Desktop은 다음과 같은 지식 노동자를 위한 경험으로 설명되었습니다.
- Python 코드나 파일을 전면에 내세우지 않음
- 자연어 프롬프트를 중심으로 함
- 도구와 데이터 테이블을 업무 공간에 제시함
- 조직 내에서 도구나 스킬을 발견하고 공유함
- 거버넌스된 표준 이용 장소를 제공함
Bob Desktop 이후, 개발부터 배포, 유지보수까지의 라이프사이클을 지원하는 DevSecOps 관련 Bob 기능이 소개되었습니다.
- AI가 제안하는 파일 편집이나 패키지 도입을 디스크 쓰기 전에 확인
- 코드 취약점, 설정 오류, 시크릿(secret), 위험한 의존성을 탐지
- 탐지된 문제의 수정을 지원
- AI 기반 공격 표면 분석
- watsonx.governance 연동
이 기능들은 AI가 생성한 코드를 나중에 검사할 뿐만 아니라, 생성, 편집, 리뷰 각 단계에서 리스크를 줄이기 위한 기능으로 소개되었습니다.
다음으로, 에이전트를 구축하는 이야기에서 구축된 에이전트를 어떻게 관리할 것인가로 넘어갑니다.
watsonx Orchestrate와 관련하여 다음 3가지 영역이 설명되었습니다.
- 서드파티 에이전트 관리
- AgentOps를 통한 평가, 가시화, 최적화
- 거버넌스를 컨트롤 플레인에 통합
여기서는 다음과 같은 메시지가 전달되었습니다.
- 에이전트를 배포 전후에 평가함
- 신뢰성, 스케일, 속도를 관측함
- 품질, 성능, 비용을 최적화함
- 보안, 컴플라이언스, 리스크 관리를 나중에 추가하지 않음
watsonx Orchestrate 설명 후, 화제는 기존 기업 시스템과의 통합으로 진행됩니다.
여기서 IBM Integration Intelligence Hub가 발표되었습니다.
주요 메시지는 다음과 같습니다.
- 기업에는 이미 API, 메시지, 이벤트, 워크플로우가 존재함
- AI 에이전트를 위해 그것들을 처음부터 다시 만들 필요는 없음
- 기존 통합 자산을 발견 가능하게 함
- AI가 기존 자산의 의미와 활용 방법을 이해할 수 있도록 함
- 에이전트로부터 재사용 가능하게 함
여기서 OneKey 앱 데모로 돌아가, 고객의 로열티 정보를 얻기 위해 이미 존재하는 고객 프로필 획득 플로우를 발견하고 재사용하는 흐름이 제시되었습니다.
다음으로, 화제는 에이전트의 ID, 자격 증명(Credential), 권한 위임으로 넘어갑니다.
여기서는 다음과 같은 내용이 설명되었습니다.
- 에이전트가 인간의 ID를 빌려 쓰는 문제
- 에이전트 고유의 ID
- OAuth 2.0을 통한 권한 위임 및 OpenID Connect를 이용한 ID 연동
- 태스크 단위의 최소 권한
- Just-in-Time 자격 증명
- HashiCorp Vault를 이용한 시크릿 관리
- 인간의 승인
- 감사 추적(Audit Trail)
OneKey 데모에서는 호텔 객실을 업그레이드하는 장면이 사용되었습니다.
추가 요금이 발생하기 때문에, 다음 흐름이 제시되었습니다.
- OneKey가 업그레이드를 제안함
- 인간에게 승인을 요청함
- 승인 후, 해당 작업에 한정된 권한을 부여함
- OneKey가 업데이트를 실행함
- 작업을 감사 가능한 형태로 기록함
Agent Identity와 HashiCorp Vault에 이어, 화제는 Terraform을 사용한 인프라 관리로 옮겨갔습니다.
Terraform은 서버나 네트워크, 클라우드 서비스 등의 구성을 코드로 정의하고, 동일한 환경을 반복적으로 생성할 수 있게 하는 시스템입니다. 이는 Infrastructure as Code라고 불립니다.
AI 에이전트가 인프라 구축에 관여하게 되면, 단순히 자연어만으로 환경을 만들 수 있는 것을 넘어, 기업의 보안 기준, 비용 제약, 운영 규칙 등을 준수하도록 해야 합니다.
이에 Terraform에서는 조직이 승인한 인프라 구성이나 정책을 사전에 정의하여, 개발자와 AI 에이전트 모두가 동일한 규칙 하에서 이용할 수 있도록 합니다.
이번에 소개된 주요 기능은 다음과 같습니다:
- Terraform Policy: Terraform과 같은 HCL(HashiCorp Configuration Language)로 규칙을 작성하고, 인프라 구성이 조직의 기준을 충족하는지 확인합니다.
- Terraform Search: Terraform으로 관리되지 않는 기존 클라우드 리소스를 발견하고, 관리 대상으로 가져오기 전에 정책을 확인합니다.
- Terraform Developer Portal: 개발자나 AI 에이전트가 조직에서 승인된 인프라 구성을 셀프서비스로 이용할 수 있게 합니다.
- Remote Terraform MCP Server: IBM Bob과 같은 AI 개발 도구로부터 Terraform의 승인된 모듈이나 워크플로우에 연결합니다.
이 부분에서는, AI 에이전트가 인프라를 자유롭게 조작하는 것이 아니라, 기업이 마련한 안전한 설계도와 규칙의 범위 내에서 조작하도록 하는 관점이 제시되었습니다.
Terraform 다음으로는 화제가 일일 IT 운영으로 옮겨갔고, IBM Concert가 소개되었습니다.
배경으로는 다음과 같은 문제들이 제기되었습니다:
- 운영 업무가 사후 대응적인 알림(reactive alert) 처리에서 실시간 분류(real-time triage)로 변화하고 있음
- AI 관련 비용을 월 단위가 아닌 더 짧은 단위로 파악할 필요성이 생김
- 대량의 CVE와 알림이 발생하고 있음
- 애플리케이션, 인프라, 네트워크, 보안이 분산되어 있음(분절화)
- 도메인 전반에 걸쳐 영향을 이해할 필요가 있음
IBM Concert는 다음과 같은 영역의 데이터와 컨텍스트를 연결하는 플랫폼으로 설명되었습니다.
마지막으로, Concert, Bob, Terraform을 연결한 취약점 복구 데모가 진행되었습니다.
실제 흐름은 다음과 같습니다:
- Concert에서 취약점을 확인
- 애플리케이션에 대한 영향을 확인
- 공격 경로와 관련 인프라를 특정
- Bob에게 복구 방법을 문의
- Terraform의 템플릿 후보를 확보
- Terraform Developer Portal에서 템플릿을 선택
- 조직 정책 및 산업 표준 준수 여부를 확인
- 비용 거버넌스(Cost Governance)를 확인
- 리소스를 배포
- Concert로 돌아가 취약점이 감소했음을 확인
세션에서는 IBM과 Confluent, HashiCorp의 제품군을 조합함으로써, AI 에이전트 개발, 실시간 데이터 연동, ID/권한 관리, 인프라 구축, 운영까지를 일관되게 지원하는 전체 그림이 제시되었습니다.
저는 지난 몇 년 동안 IBM의 AI 기반인 watsonx, 데이터 플랫폼 제품 및 BI(Business Intelligence)를 담당해 왔습니다. 그 입장에서 볼 때, AI가 이용하는 데이터의 신선도뿐만 아니라, AI 에이전트의 품질을 지속적으로 관리하는 시스템까지 여러 제품을 조합하여 구체적인 구성으로 제시된 점이 인상 깊었습니다.
개별 제품 기능뿐만 아니라, 그것들을 연결하여 AI 에이전트의 라이프사이클 전체를 지원하는 스토리로 보여주었기 때문에, IBM이 지향하는 방향성을 이해하기 쉬운 세션이었습니다.
