SaaS 데브옵스에서 배우는 기업 IT 회복탄력성 전략
제품 관리 관행, 테스트 자동화, Day 0 관찰가능성까지 SaaS 기업이 당연하게 여기는 것들이 기업 데브옵스의 다음 과제다.
많은 기업의 데브옵스 팀이 빈번한 배포, 테스트 자동화 확대, 안정적인 릴리즈 보장에 어려움을 겪고 있다. SaaS 기업은 무엇이 다를까? SaaS 기업에서 소프트웨어 개발과 배포는 수많은 고객을 대상으로 이뤄지며, 이는 곧 수익과 비즈니스 운영의 핵심이다.
SaaS 기업은 견고한 테스트, 관찰가능성, 배포, 모니터링 역량을 갖춰야 한다. 배포 한 번의 실수가 고객의 비즈니스 운영 중단, 영업 기회 손실, 부정적인 언론 보도로 이어질 수 있기 때문이다.
가장 까다로운 부분은 많은 SaaS 플랫폼이 사용자가 직접 구성할 수 있는 기능과 로우코드 개발 기능을 제공한다는 점이다. 배포가 고객의 기능을 망가뜨리지 않으려면 견고한 테스트 데이터 세트와 실시간 모니터링이 필수다. 극히 일부 고객에게라도 영향을 미쳐서는 안 된다.
데이터 입력 양식과 종단간 워크플로우를 검증하려면 견고한 데이터 세트를 구축하고 입력 패턴의 통계적 유의성을 테스트해야 한다. AI 에이전트와 언어 모델의 개발·통합·배포는 새로운 복잡성을 더한다. 서드파티 AI 에이전트를 활용하고 AI 실험을 프로덕션으로 이관하는 기업이 늘어나는 상황에서 비결정적 응답을 생성하는 개방형 AI 에이전트를 테스트하기란 여간 어려운 일이 아니다.
여러 SaaS 업체에 데브옵스의 핵심이 무엇인지 물었다. 미션 크리티컬 앱, 통합, 데이터 파이프라인을 개발·배포·지원하면서 회복탄력성을 높이려는 기업 데브옵스 팀이 얻을 수 있는 답을 정리했다.
스마트한 고객 업그레이드를 목표로
업그레이드를 배포했을 때 최종 사용자가 새 기능을 제대로 활용하게 될까, 아니면 프로덕션까지 유입된 결함에 좌절하게 될까. 기업은 단절 없이 자연스럽게 느껴지고, 자주 배포되고, 결함률이 낮고, 보안 문제가 없고, 새 기능 도입을 촉진하는 스마트한 고객 업그레이드를 목표로 해야 한다.
이 목표를 지속적으로 달성하려면 기업 데브옵스 팀은 낡은 IT 사고방식에서 벗어나 다음을 인식해야 한다.
최종 사용자는 고객이며 워크플로우가 중단되면 비즈니스 운영에 직접 영향을 미친다. 배포 빈도를 높이더라도 결함이 포함되면 SaaS 관점에서는 실패이며, 기업 IT도 마찬가지다.
배포한 기능을 거의 아무도 인지하지 못하고 사용 시도조차 하지 않는다면 심각한 문제다. 비즈니스 가치를 창출하지 못하는 곳에 시간과 자원이 투입됐다는 뜻이며, 새로운 기술 부채가 쌓였을 가능성이 크다.
소프트웨어 배포는 일회성 작업이 아니며, 각 애자일 팀은 서로의 릴리즈 관리 계획을 공유해야 한다.
소프트웨어 개발 전문 업체 잘라소프트(Jalasoft)의 선임 데브옵스 엔지니어 서지오 로드리게즈 인클란은 “가장 성공적인 데브옵스 팀은 사내 플랫폼이 사실상 개발자를 주 고객으로 두는 특화된 SaaS 제품이라는 점을 인식한다”며 “경직된 프로젝트 마감 기한을 지속적인 신뢰성과 셀프 서비스 자동화에 대한 약속으로 대체하면 IT는 기업의 병목 지점에서 경쟁 우위로 전환된다”고 말했다.
많은 기업이 현재 추진하는 변화 중 하나가 제품 기반 IT로의 전환이다. 애플리케이션을 제품 단위로 묶고 제품 관리자를 지정해 로드맵을 관리하는 방식이다. 대다수 SaaS 기업은 제품 관리자를 두고 제품 비전 전달, 사용자 페르소나 정의, 고객 요구 파악, 기능 우선순위화, 비즈니스 성과 측정을 맡긴다.
세일즈포스 자동화 플랫폼 전문 업체 코파도(Copado)의 로보틱스 부문 수석 부사장 에스코 하눌라는 “현대 기업 IT는 SaaS 사고방식을 받아들여야 한다”며 “소프트웨어는 종료 날짜가 정해진 프로젝트가 아니라 빈번하고 점진적인 릴리즈를 통해 지속적으로 개선되는 제품”이라고 말했다.
하눌라는 필요할 때 언제든 릴리즈할 수 있는 역량을 위해 고급 CI/CD, 지속적 테스트, 카나리아 릴리즈, A/B 테스트, 데이터 기반 제품 관리 등 SaaS 팀이 활용하는 데브옵스 관행을 도입할 것을 권했다. “이런 관행은 비즈니스 변화에 신속하게 대응하는 데 필요한 확신과 민첩성, 품질을 실현한다는 면에서 중요하다. 소프트웨어를 일회성 프로젝트가 아닌 장기적인 제품으로 취급하는 데 따라 자연스럽게 나타나는 결과”라고 덧붙였다.
코딩을 줄이고 테스트 늘리기
기업 IT 부서 개발자들은 이제 AI 코드 생성기를 활용하고 바이브 코딩 툴도 실험하고 있다. 연구에 따르면 이런 툴이 개발자 생산성을 30% 이상 끌어올릴 수 있다. 그러나 생산성 향상이 더 빠르고 안정적인 기능 배포라는 데브옵스 팀의 역량으로 이어질까.
기업 IT는 전통적으로 테스트 투자에 인색하고 대규모 단발성 배포를 선호한다. SaaS 기업은 정반대로 접근한다. 테스트 자동화에 분석을 적용하고 합성 테스트 데이터 세트를 구축하고 빈번한 배포에 따르는 위험을 줄이기 위해 기능 플래깅을 활용한다. 더 발전한 SaaS 기업은 지속적 배포도 사용하지만, 기업 환경에서 이를 구현하기는 쉽지 않다.
데이터 스트리밍 및 관찰가능성 플랫폼 전문 업체 크리블(Cribl)의 AI 연구개발 디렉터 니킬 뭉겔은 “테스트 자동화는 초기 비용처럼 느껴질 수 있지만, 회복탄력성이 높은 서비스는 장애, 지원 티켓, 운영 오버헤드 감소로 이어지는 만큼 투자 대비 효과는 빠르게 나타난다”고 말했다. SaaS 팀은 위험을 낮추기 위해 일반적으로 소규모 그룹에 먼저 기능을 릴리즈하고, 관찰가능성을 통해 시스템 상태와 사용자 경험을 확인한 뒤 전체 배포를 진행한다. 이 과정에서 기능 플래그와 버케팅이 사용된다. 기업 데브옵스 팀도 이를 본받아 ‘파워 유저’가 초기 단계에 참여하도록 함으로써 만족도를 높이고 지원 부담을 줄일 수 있다고 뭉겔은 강조했다.
설계·개발·배포에서의 보안
코드 생성기로 인한 생산성 향상에는 대가가 따를 수 있다. 앞서 언급한 연구에서는 개발자 생산성과 코드 유지보수 편의성이 개선된다는 결과와 함께, 생성된 코드에 보안 취약점이 23.7% 더 많이 발생했다는 점도 확인됐다.
보안의 ‘시프트 레프트’는 간단하게 들리지만, 보안에 개발·운영과 동등한 우선순위를 두려는 기업 데브옵스 팀에게는 상당한 과제다. 데브섹옵스를 구현하려면 애자일 팀은 애플리케이션 보안을 넘어 클라우드 인프라 강화, ID 관리, 데이터 보안, AI 모델 편향 등에 대한 보안과 규정 준수까지 챙겨야 한다.
애플리케이션 보안 솔루션 전문 업체 아크젯(Arcjet)의 CEO 데이비드 마이튼은 “SaaS 팀의 성공은 결국 종속성이 매끄럽게 업그레이드되도록 코드베이스에 보안을 내재화하는 것”이라고 말했다. 마이튼이 권장하는 네 가지 관행은 다음과 같다.
종속성이 손상되는 경우를 감지하는 자동화된 보안 및 개인정보 보호 점검이 포함된 테스트 스위트, 구조화된 트레이스와 맥락이 풍부한 로그를 갖춘 표준화된 관찰가능성, 개인정보 보호를 고려한 데이터 관리와 CI/CD 게이트를 통한 앱 내 개인식별정보(PII) 마스킹, 고객 서비스나 규정 준수에 지장 없이 신속하게 진행하기 위한 기능 플래그와 카나리아 롤아웃이다.
AI 기반 고객 서비스 플랫폼 전문 업체 ASAPP의 플랫폼 및 인프라 부문 GM 겸 부사장 프리야 사완트는 현대 SaaS 팀은 보안, 테스트, 액세스 제어, 관찰가능성을 사후에 덧붙이는 것이 아니라 설계와 CI/CD 파이프라인에 처음부터 내재화한다고 강조했다. “권한 자동화, 골든 패스 파이프라인 강제, 관찰가능성 내장은 마찰을 없애고 품질을 개선하고 전달 속도를 높인다. 이 모델을 도입하는 IT·데브옵스 팀은 수동 승인과 사후 대응적 워크플로우에 머무르는 팀보다 더 빠르게 움직이고 더 안정적으로 확장한다”고 말했다.
Day 0부터 탄력적인 운영 계획
필자는 CIO 재직 시절, 구축 중인 애플리케이션의 Day 2 모델이 무엇이냐는 질문을 받은 적이 있다. Day 2는 애플리케이션이 프로덕션에 배포돼 운영 지원이 필요한 단계를 가리키는 전통적인 용어다. Day 1은 개발, Day 0은 계획 단계다.
SaaS 팀의 운영 사고방식은 이와 다르다. 아키텍처 설계 단계부터 확장성, 보안, 성능, 장애 관리 계획을 수립하기 시작한다.
예를 들어 SaaS 기업은 개발자 경험에 상당한 비중을 둔다. 클라우드 구성, 수동 패치, 데이터 관리에 시간을 지나치게 소비하는 개발자는 고객 요구에 집중하기 어렵다.
오픈소스 관계형 데이터베이스 전문 업체 마리아DB(MariaDB)의 개발자 관계 엔지니어 알레한드로 두아르테는 “SaaS 엔지니어는 복잡성을 불필요하게 높이지 않으면서 업그레이드 경로로 인한 마찰 없이 빠르게 움직일 수 있는 기술을 선택한다”고 말했다.
두아르테는 개발자 속도를 늦추지 않는 인프라를 선택하는 것이 중요하다고 강조했다. 데이터 계층에서는 네이티브 복제, 벡터 스토리지, 빠른 분석, 자동 노드 복구를 지원하는 시스템을 우선시할 것을 권했다.
관찰가능성 전략 수립과 구현
SaaS에서 비롯된 또 하나의 사고방식 전환은 블랙박스식 Day 2 애플리케이션 모니터링에서 Day 0 관찰가능성으로의 이동이다. 이를 통해 운영 팀에 장애 관리와 근본 원인 분석에 필요한 세부 정보를 제공할 수 있다. 수백, 수천 개의 애플리케이션에 걸쳐 경보와 장애를 추적하는 기업 환경에서 관찰가능성 표준은 선택이 아닌 필수다.
클라우드 네이티브 관찰가능성 플랫폼 전문 업체 그라운드커버(Groundcover)의 창립 엔지니어 겸 CTO 노암 레비는 “IT 데브옵스 팀은 관찰가능성이 단순히 배포 후 시스템 모니터링이 아니라 개발의 모든 단계에 실제 맥락을 내재화하는 것임을 SaaS 개발자에게서 배울 수 있다”고 말했다. AI와 결합된 최신 관찰가능성 툴은 프로덕션 환경에서 문제가 발생하기 전에 이를 예측하도록 엔지니어를 지원해 더 안전한 코드 변경과 더 신뢰할 수 있는 릴리즈로 이어진다. 레비는 “사후 대응적 문제 해결에서 사전 예방적 신뢰성으로의 이 전환은 선도적인 SaaS 팀이 소프트웨어에 대한 신뢰를 지속적으로 강화하는 방식과 일치한다”고 덧붙였다.
관찰가능성의 중요성은 SaaS 리더들이 꾸준히 강조하는 주제이며, 많은 이가 타협 없이 표준화해야 할 데브옵스 요소로 꼽는다. 그러나 모든 정보를 로깅하면 비용과 복잡성이 커진다. AI 에이전트가 모든 상호작용을 기록하는 환경에서는 이 문제가 더 두드러진다.
실시간 데이터 분석 플랫폼 전문 업체 임플라이(Imply)의 수석 설계자 에릭 셰터는 “AI 기반 시스템이 생성하는 로그, 메트릭, 트레이스가 기하급수적으로 증가하는 상황에서 긴밀하게 결합된 관찰가능성 스택은 비용을 높이거나 느리고 조회하기 어려운 콜드 스토리지로 데이터를 옮기지 않고서는 충분한 양의 데이터를 빠르게 접근 가능한 상태로 유지하기 어렵다”며 “관찰가능성 웨어하우스를 확장 가능한 데이터 계층으로 활용하면 비용을 높이지 않고도 대규모 환경에서 텔레메트리 데이터의 접근성을 유지할 수 있다”고 말했다.
클라우드 관찰가능성 플랫폼 전문 업체 옵저브(Observe)의 엔지니어링 디렉터 앙 리는 SaaS 팀이 관찰가능성 표준에 무엇을 포함할지 결정할 때 따르는 좋은 원칙이 있다고 소개했다. “SaaS 엔지니어링 팀은 시스템 가동 여부뿐 아니라 사용자와 워크플로우에 대한 관찰가능성도 설계한다”며 “IT 데브옵스도 같은 사고방식을 적용해 가동 시간 모니터링을 넘어 핵심 비즈니스 트랜잭션을 계측함으로써 사용자 영향을 더 정확히 파악하고 문제 발생 시 피해 범위를 좁히고 더 빠르게 복구할 수 있다”고 말했다.
![[숨신소] 하데스 느낌, 멈출 수 없는 로그라이트 '신데리아'](https://lh3.googleusercontent.com/blogger_img_proxy/AEn0k_vmxA2BaOWjfwbusjtCAiiMDneUO8Z_EaiI6H_8O3IxPfn0E2pIhHWa5Dv5ufo-aTAdTrXCdthAkzWPcmxeUA2JSZ5EhwZKd4CvaaPgmF1PIvQ)
