요즘 AI 업계 특히 프론티어 랩의 기술 혁신 속도를 보면 혀를 내두를 정도입니다. 하루가 멀다 하고 더 강력한 모델이 나오고 있고 선택지도 넓어지고 있습니다.
엔지니어링 유행도 하루가 다르게 바뀌고 있습니다. 이런 변화는 애플리케이션을 개발하고 운영하는 입장에서 반갑지만은 않습니다. 모델, 도구, 최적화 기법이 바뀌면 사용자 경험이 달라질까 하는 걱정이 앞섭니다. 그렇다면 너무 빠른 변화를 어떻게 수용해야 할까요?
구글에서 GKE를 이끄는 드루 브래드스톡(Drew Bradstock) 시니어 디렉터는 SixFive Summit 2026 대담에서 Adaptive Apps에 대한 질문에 이런 변화를 중심으로 답했습니다.
이번 포스팅에서는 Adaptive Apps 개념을 기준으로 AX 시대 엔터프라이즈 애플리케이션을 어떻게 운영하면 좋을지 알아보겠습니다.
Adaptive Apps란?
기존 애플리케이션은 개발자가 정한 기능과 화면을 사용자가 메뉴를 통해 이용하는 구조였습니다. 업데이트가 필요하면 요구 사항을 모으고, 코드를 바꾸고, 테스트한 뒤 새 버전을 배포했습니다. AX 전략을 중심으로 AI 기능을 다양한 애플리케이션에 적용하는 시대에는 예전 같은 방식을 지속하기 어렵습니다. 모델, 도구, 플랫폼 환경의 변화가 매우 빠르기 때문입니다. 드루 브래드스톡의 말을 풀이해보면 Adaptive Apps는 릴리스 주기, 평가 기준, 실패를 다루는 방식을 함께 바꿔 AX 시대에 맞게 애플리케이션을 운영하자는 방향이라고 볼 수 있습니다. 기술적으로는 모델과 데이터, 피드백을 바탕으로 행동을 조정하는 애플리케이션을 Adaptive Apps라고 부를 수 있습니다.
AX에서 Adaptive Apps가 중요한 이유는 사용자의 눈높이가 빠르게 높아지고 있기 때문입니다. 사용자는 메뉴를 여러 번 눌러 기능을 찾기보다 원하는 결과를 자연어 대화로 이어 가며 받아 보고 싶어 합니다. 일일이 메뉴를 찾아 가며 작업하던 방식을 넘어, 생산성·그래픽 등 다양한 도구에 탑재된 AI가 이전 대화와 현재 상황을 이해하고 필요한 정보를 찾아 작업을 마치기를 기대하는 것이죠.
성능 지표를 워크로드 수준의 사용자 경험과 연결해야 하는 이유
Adaptive Apps를 개념이 아니라 실제 동작하는 애플리케이션 수준으로 현장에 적용하려면 먼저 운영 기준을 마련해야 합니다. Adaptive Apps에서도 전통적인 엔터프라이즈 애플리케이션처럼 CPU 사용률, 지연 시간, 오류율은 중요한 운영 지표입니다. 그러나 이 지표만 보면 AI가 실제로 일을 잘 마쳤는지 알 수 없습니다. 답변이 빨라도 틀린 문서를 근거로 삼았다면 문제가 있는 것입니다. 에이전트가 도구를 열 번 호출해 결과를 냈다면 성공으로 보일 수 있지만 토큰 비용이 부담으로 따라옵니다.
그렇다면 Adaptive Apps의 운영 지표에는 어떤 요소를 새로 넣어야 할까요?
바로 워크로드 수준의 사용자 경험을 새로운 지표로 더해야 합니다. 예를 들어 고객 지원 에이전트라면 첫 응답 속도뿐 아니라 해결률, 상담원 이관률, 잘못된 정책 안내 비율을 봐야 합니다. 개발 에이전트라면 생성한 코드의 양보다 테스트 통과율, 리뷰 수정 횟수, 배포 후 결함률이 중요합니다. 이처럼 워크로드 수준에서 측정하려면 기술 지표와 경험 지표를 연결해야 합니다. 모델 호출 지연, 검색 상위 문서, 도구 실행 결과, 토큰과 가속기 사용량을 하나의 추적 정보로 묶고 최종 업무 결과와 연계해 보아야 합니다. 이것이 가능해야 “왜 이 사용자가 작업을 포기했는가”라는 질문에 검색 실패인지, 모델 지연인지, 도구 오류인지 답할 수 있습니다.
참고로 구글 클라우드에서는 Cloud Monitoring과 Cloud Trace, 로그 기반 지표를 활용해 애플리케이션과 에이전트의 실행 경로를 관찰할 수 있습니다. GKE나 Cloud Run의 자원 지표에 모델·검색·도구 호출 정보를 더하면 인프라 상태와 사용자 경험을 같은 흐름에서 볼 수 있습니다. 여기서 한 가지 짚고 넘어갈 것이 있습니다. 중요한 것은 지표를 많이 모으는 일이 아니라 개선할 의사결정과 직접 연결된 지표를 고르는 일입니다.
아무도 가 보지 않은 AX, 실패를 자산으로 바꾸기
Adaptive Apps 환경은 정답이 없는 시험지 같습니다. 프롬프트와 모델만 바꿔도 결과가 달라지고, 실제 사용자는 설계자가 예상하지 못한 방식으로 서비스를 이용하는 경우가 많습니다. 실패를 완전히 막겠다며 완벽을 추구하는 접근은 출시를 늦출 뿐 품질도 보장하지 못합니다. Adaptive Apps 환경에서 실패는 운영 최적화를 위한 자산으로 보아야 합니다. 그렇다면 실패라는 자산을 어떻게 쌓아 관리해야 할까요?
첫 단계는 실패를 기록하는 것입니다. 사용자가 입력한 프롬프트 내용을 무조건 저장하라는 뜻은 아닙니다. 개인정보와 민감정보를 통제하면서 입력 유형, 선택한 도구, 검색 결과, 모델 응답, 사람의 수정, 최종 성패를 재현 가능한 형태로 남깁니다. 두 번째는 실패를 분류하는 것입니다. 지식 부족, 검색 누락, 도구 오류, 정책 위반, 모호한 요구, 지연 초과처럼 원인을 나누어야 우선순위를 정할 수 있습니다.
세 번째는 평가 자산으로 전환하는 것입니다. 실제 실패 사례를 익명화해 회귀 평가 세트에 넣고, 모델이나 프롬프트, 검색 설정을 바꿀 때 같은 문제가 다시 생기는지 확인합니다. 반복해서 등장하는 판단은 프롬프트에 계속 붙이지 말고 정책, 함수, 스킬, 테스트로 구조화합니다. 실패 기록이 쌓일수록 조직만의 품질 기준과 운영 노하우도 함께 쌓입니다.
배포 방식도 바뀌어야 합니다. 작은 사용자 집단에 먼저 적용하고, 기존 방식과 결과를 비교하며, 이상이 생기면 빠르게 되돌릴 수 있어야 합니다. 모델 라우팅과 기능 플래그, 승인 단계를 활용하면 적응성을 유지하면서 위험 범위를 제한할 수 있습니다.
AX 시대에 맞는 엔터프라이즈 애플리케이션 운영 전략을 고민 중이라면?
Adaptive Apps 전략의 핵심은 기술 선택이 아닙니다. 앞서 언급한 바와 같이 릴리스 주기, 평가 기준, 실패를 다루는 방식을 모두 바꾸는 포괄적인 작업입니다. 빠른 모델 출시 속도에 유연하게 대응하면서 기업 고유의 업무 흐름, 평가 기준, 데이터 연결, 사용자 경험을 AX 전략에 맞춰 체계화하고자 한다면 메가존소프트 문의 포털을 통해 상담을 남겨 주세요.
