SaaS(Software as a Service) 기업은 애플리케이션 안정성, 확장성, 보안 및 고객 만족도 측면에서 선두에 서있다. 데브섹옵스(devsecops) 리더가 적용할 수 있는 SaaS의 원칙 12가지를 소개한다.
필자는 SaaS 기업의 CTO 역할에서 스타트업 개발 프로세스, 기술 및 문화를 조직에 도입하는 것을 목표로 하는 포춘 100대 기업의 사업부 CIO로 자리를 옮긴 적이 있다. 경영진은 고객 대면 애플리케이션, 획기적인 분석 기능, 보다 자동화된 워크플로우 개발의 중요성을 인지하고 있었다.
이때 애자일 개발과 민첩한 아키텍처에 대해 많은 교육을 진행했다. 하지만 데이터센터에 안정적이고 성능이 뛰어나며 안전한 애플리케이션을 배포하는 방법에 대해서도 배울 점이 많았다. 클라우드 컴퓨팅과 데브섹옵스가 등장하기 전의 일이다.
오늘날 많은 기업이 강력한 소프트웨어 개발 및 데브옵스(devops) 역량을 갖추고 있지만, SaaS 기업은 애플리케이션을 확장하고, 이질적인 고객 사용 사례를 처리하고, 성능 및 보안 인시던트가 고객 문제로 번지기 전에 식별하는 데 있어 전문성을 더 강화하고 있다.
SaaS 기업 주퍼(Zuper)의 CTO인 라가브 구루마니는 “CTO는 기능적으로 견고할 뿐만 아니라 일관되게 사용할 수 있고 초고속이며 보안 위협에 안전한 제품의 가치를 잘 알고 있다. CTO는 안정성, 성능, 보안이라는 3가지 요소의 균형을 맞추고 반복적인 접근 방식의 중요성을 강조해 기업이 그 역량을 갖추도록 지원할 수 있다”라고 말했다.
이 글에서는 SaaS 기술 리더가 추천하는, 비즈니스 IT 리더가 데브섹옵스에 적용할 수 있는 12가지 원칙을 소개한다. 원칙은 3개 영역으로 구분했다.
• 고객 우선 사고방식을 채택하는 것부터 시작해 ‘시프트 레프트’ 운영 관행을 요구 사항과 개발에 적용한다.
• 데브섹옵스팀은 특히 사용량이 많고 사용자 유형이 많은 애플리케이션의 안정성과 성능을 보장하기 위해 단위 테스트를 넘어 더 많은 테스트 자동화를 수행해야 한다는 점을 인식한다.
• SLO(서비스 수준 목표)를 정의하고 통합 가시성, 모니터링 및 클라우드 자동화를 위한 도구를 활용해 더 높은 성능과 안정성을 얻는다.
1. 고객 우선 사고방식 채택
고객 중심적인 사고방식과 고객의 니즈에 대한 민감도를 키우는 것은 고객을 유지하고 성장을 지원하기 위해 반드시 필요하다. 많은 기업이 고객을 대상으로 애플리케이션을 개발하지만, 데브섹옵스팀도 내부 애플리케이션을 개발할 때 동료 직원을 고객으로 대하는 방법을 배워야 한다.
런치다클리(LaunchDarkly)의 최고 제품 책임자인 클레어 보는 고객 우선 사고방식에 “고객 문제를 신속히 파악하고 해결하는 데 있어 타협하지 않는 태도”가 포함된다고 말했다. 그는 “엔지니어는 제품, 디자인, 영업, 지원만큼이나 고객 중심적이야 한다. 이는 엔지니어가 고객과 직접 대화하고 고객처럼 제품을 사용하며, 고객을 대신해 높은 수준의 기준을 제시해야 한다는 의미다. 경험에 따르면 고객과의 긴밀한 관계는 탄력적인 문화와 중요한 상관 관계가 있었다”라고 설명했다.
권장 사항: 데브섹옵스팀은 최종 사용자와 정기적인 미팅을 진행해 애플리케이션 사용 방식을 관찰하고 애플리케이션 성능을 개선할 방법에 귀 기울여야 한다.
2. 버전 관리를 애자일 유저 스토리에 연결
대부분의 기업이 버전 관리(version control)를 도입하고 있지만, 코파도(Copado)의 에반젤리즘 담당 수석 부사장인 데이비드 브룩스는 개발자들이 리포지토리의 브랜치 관리에만 너무 집중하는 경향이 있다고 지적했다. 그는 “최신 개발은 애자일을 기반으로 하며, 많은 데브옵스 도구가 유저 스토리를 바탕으로 변경 사항을 직접 관리한다”라고 말했다.
브룩스는 애자일 개발팀이 유저 스토리에서 시작해 변경 사항을 추적한다면 가치 제공에 더 집중하고 테스트 중심 개발을 지원하며 자동화된 병합 충돌을 해결할 수 있다고 말했다.
권장 사항: 데브섹옵스팀은 애자일 도구와 버전 관리 간의 워크플로우 연결 외에도 CI/CD 파이프라인 표준화, 기능 플래그를 사용한 개발, 카나리아 릴리스 전략 활용 등을 고려해야 한다.
3. 알파 그룹에 새 기능 출시
데브섹옵스 자동화에 투자하면 소규모 사용자 그룹에 기능을 출시하고 기능 구현에 대한 A/B 테스트를 수행할 때 유연성을 확보할 수 있다. 자동화는 지속적인 배포도 지원할 수 있지만, 과도한 투자를 하기 전에 기능을 검증하고 개발 중 최종 사용자의 피드백을 얻을 수 있다는 점이 더 중요하다.
콜레일(CallRail)의 공동 창립자이자 CTO인 엘리엇 우드는 “새로운 기능을 알파 그룹에 공개적으로, 빠르게 테스트해 피드백을 얻고 있다. 팀은 제한된 고객 그룹에 작은 변경 사항을 적용하고 개별 실험의 위험을 최소화할 수 있기 때문에 빠르게 움직일 수 있다”라고 말했다.
권장 사항: 알파 테스트는 조직 내부에서, 베타 테스트는 사용자 환경에 초점을 맞춰 진행하는 오랜 소프트웨어 개발 관행이다. 데브섹옵스는 자동화 및 확장성 측면에서 기술 운영을 최적화하도록 지원한다. 알파 및 베타 프로그램은 참가자를 모집하고, 목표를 전달하며, 실행 가능한 피드백을 얻고, 보상을 제공하는 것이 핵심이다.
4. 설계 단계부터 보안 구현
강력한 정보 보안 프로그램을 갖춘 기업은 많지만, 소프트웨어 개발 프로세스에서 설계 단계부터 보안을 구현하기란 여전히 어려운 과제다. 보안 모범 사례에는 침투 테스트 자동화, CI/CD 파이프라인에서의 코드 스캔 트리거, 인젝션, 인증 결함, 사이트 간 문제, API 유출 및 액세스 제어 중단으로부터 API 보호 등이 포함된다.
이뮤타(Immuta)의 CTO인 스티브 토우는 “설계 단계부터 보안을 구현하고 제품 개발 초기에 보안을 적용하자 취약점 관리 관점에서 백엔드 유지 및 관리 업무가 눈에 띄게 줄어들었다”라고 말했다.
권장 사항: CIO, CISO 및 제공 관리자는 프로덕션 경로를 자동화할 때 필요한 보안 관행, 테스트 및 메트릭에 있어 협상 불가능한 요구 사항을 명확하게 정의해야 한다.
5. 단위 테스트가 불충분하다는 인식
자동차 운전자는 타이어 공기압을 확인하고, 오일 수준을 확인하고, 엔진에 대해서도 수많은 테스트를 진행할 수 있다. 하지만 자동차가 실제로 곡선 도로나 요철 같은 다양한 도로 조건을 달릴 때도 운전자의 기대에 완전히 부응할 수 있을까?
소프트웨어 애플리케이션도 마찬가지다. 단위 테스트는 구성 요소와 인터페이스의 유효성을 검사하는 데는 도움이 되지만, E2E(End-to-End) 기능이나 사용자 경험의 유효성을 검사하는 데는 충분하지 않을 수 있다.
소나(Sonar)의 개발자 관계 커뮤니티 책임자인 피터 맥키는 “개발자는 시프트-레프트 접근 방식을 수용하면서 종종 기능이 올바르게 작동하는지 확인하기 위해 단위 테스트를 우선시한다. 하지만 단위 테스트에만 의존하면 품질 보증에 공백이 생겨 눈에 띄지 않는 버그가 발생할 수 있다. 이는 배포 시에 소프트웨어 품질과 보안을 모두 손상시킨다”라고 설명했다.
권장 사항: 많은 도구가 프론트엔드 사용자 경험 테스트를 자동화할 수 있다. 애자일 개발팀이 강력한 기능 테스트를 보장하려면 책임을 할당하고, 기술을 개발하고, 시간을 투자하는 것을 핵심 요구 사항으로 삼아야 한다.
6. SME의 테스트 자동화
더 많은 기능 테스트를 위한 노력은 개발된 테스트 사례만큼 중요하다. 품질 보증 엔지니어는 대부분 경계 조건을 식별하는 역량과 오류 조건을 테스트할 기술을 갖고 있지만, 최종 사용자의 목표와 워크플로우 및 여정을 더 잘 이해하기 위해서는 최종 사용자의 안내가 필요하다.
코파도의 브룩스는 “개발자는 요청대로 작동하는 코드를 제공하는 데 주력하지만, 다양한 고객 구성에서 소프트웨어 작동을 보장하려면 SME(subject matter expert)가 실제 환경에서 사용자가 기능을 사용하는 방식을 보여주는 테스트를 생성해야 한다. 가장 좋은 방법은 SME가 단계를 캡처한 뒤 자동화된 테스트를 생성하는 도구를 사용해 탐색 테스트를 수행하는 것이다”라고 설명했다.
권장 사항: 알파 및 베타 그룹을 앱 테스트 커뮤니티로 활용하되, 테스터가 반복적인 UAT(User Acceptance Test)를 수행할 것이라고 기대하지 말라. 도구를 사용해 테스트 패턴을 캡처하고, 가장 중요한 테스트를 자동화하며, 지속적인 테스트 전략을 개발하고 합성 데이터를 활용해 테스트 패턴을 확장해야 한다.
7. 보안 및 품질에 대한 코드 검증
코파일럿 및 기타 생성형 AI 코드 생성기의 사용으로 인해 코드 취약점을 검토하고 미래에 기술 부채가 될 수 있는 문제의 플래그를 지정하는 작업이 더 중요해졌다. 코드가 프로덕션에 적용되기 전에 플래그를 지정해야 하는 코드 품질 문제로는 적절한 문서화, 오류 조건, 로깅 및 명명 규칙 확인 등이 있다.
소나의 맥키는 “QA 노력을 강화하기 위해 개발자는 정적 코드 분석(static code analysis)을 워크플로우에 통합해야 한다. 자동화된 정적 분석은 애플리케이션의 내부 구조를 검사하고, 추가적인 문제를 발견해 단위 테스트를 보완한다. 이 2가지를 결합하면 개발자는 개발 수명 주기 전반에 걸쳐 코드 품질을 선제적으로 관리하고 버그를 신속하게 식별하고 해결할 수 있다. 이를 통해 전반적인 소프트웨어 안정성과 보안을 강화할 수 있다”라고 조언했다.
권장 사항: 기술 부채를 줄이는 것이 기업의 주요 이슈이기 때문에 보안 및 코드 품질 문제를 스캔하고 CI/CD의 단계를 통합하는 도구를 찾는 것은 타협할 수 없는 요구 사항이 돼야 한다.
8. 비기능적 운영 요구 사항(nonfunctional operational requirements) 수립
성능, 안정성, 보안의 삼각형을 고려할 때 허용 가능한 운영 조건을 구체화하는 요구 사항을 파악하는 것이 중요하다. 개발팀은 종종 이런 요구 사항을 애자일 유저 스토리 안에서 수용 기준(acceptance criteria)에 따라 설명할 수 있는 ‘비기능적 요구 사항’으로 표현한다. 비기능적 요구 사항도 인프라 구성 요소를 선택하고 관리하는 방법을 안내할 수 있다.
IBM의 소프트웨어 네트워킹 제품 관리 부사장이자 NS1 최고 제품 책임자인 데이비드 코피는 “비기능적 운영 요구 사항도 기능적 요구 사항만큼이나 중요하다. 클라우드 서비스의 기술 스택에서는 모든 것이 중요하며, 특정 DNS 서비스나 네트워크 연결 같은 세부 사항을 간과하면 클라우드 서비스의 가용성과 확장에 부정적인 영향을 미칠 수 있다”라고 말했다.
권장 사항: 설계자, 운영 및 보안 전문가는 애자일 개발팀이 유저 스토리에서 참조할 수 있는 비기능적 요구 사항 및 수용 기준에 대한 표준 초안을 작성해야 한다.
9. 유의미한 결과를 낼 수 있는 채널 SLO 및 알림 우선순위 설정
예전에는 애플리케이션 성능에 대한 기대치를 설정할 때 99.9% 가동 시간과 같은 운영 메트릭으로 목표 SLA(서비스 수준 계약)를 표현했다. 보다 현대화된 접근 방식에서는 SLO와 오류 예산을 정의해 데브섹옵스팀이 운영 개선의 우선순위를 정해야 하는 시점을 관리한다.
Logz.io의 공동 창립자이자 제품 부사장인 아사프 이갈은 “엔지니어가 사용자 만족도 수익과 연결된 중요 SLO에 대해 폭넓은 비전을 갖지 않고 성능 개선을 추진한다면 통합 가시성 플랫폼에서 기대할 수 있는 성공이 제한된다. CTO는 엔지니어링팀으로부터 유의미한 결과를 이끌어낼 뿐만 아니라, 비즈니스 성공에 중요한 역할을 명확하게 식별하는 알림 우선순위를 설정해 엔지니어의 스트레스를 줄여야 할 책임이 있다”라고 말했다.
권장 사항: 제품 관리자는 SLO 설정에 참여하고 고객 세그먼트, 여정 유형 및 중요 기간을 통해 중단이나 성능 저하가 비즈니스에 큰 영향을 미치는 시기를 나타내야 한다.
10. 통합 가시성 구현 및 데이터 파이프라인 모니터링
오늘날 대부분의 애플리케이션은 데이터 파이프라인을 활용해 다른 데이터 소스를 연결하고 애플리케이션 환경 안팎으로 데이터를 이동한다. 이때 워크플로우가 손상될 수 있으며, 파이프라인 지연 및 데이터 품질 문제가 발생하면 잘못된 의사 결정을 내릴 위험도 있다.
액셀데이터의 공동 창립자이자 CTO인 애슈윈 라지바는 “데이터 신뢰성 검사에 시프트-레프트 접근 방식을 활용하면 데이터 품질과 무결성을 소스에서 조기에 검증할 수 있고 비용이 많이 드는 결과를 피할 수 있다. 지속적인 모니터링과 사고 관리는 잠재적 데이터 사고에 대해 선제적으로 대응할 기회를 주기 때문에 데이트 흐름을 중단 없이 유지하고 데이터 공급망 전반에서 데이터의 신뢰성을 보장한다”라고 설명했다.
권장 사항: 라지바는 전체 데이터 공급망에 걸쳐 포괄적인 모니터링을 구현하고, 파이프라인 성능 문제와 데이터 품질 이상을 식별하기 위해 사전 예방적인 자동 점검 및 알림을 활용할 것을 권했다.
11. 관리자 제어 및 외부 액세스 봉쇄
SaaS 기업은 고객 데이터 노출이나 애플리케이션 가용성 저하를 막기 위해 애플리케이션과 환경에 대한 관리자의 액세스를 차단한다. 다른 기업도 마찬가지여야 하며, 보안 전문가는 특히 민감한 데이터가 포함된 경우 기업 독점 애플리케이션의 관리 기능, 관리자 역할, 액세스 권한 및 감사 제어를 재검토해야 한다.
프리온(Pryon)의 창립자이자 CEO인 이고르 자블로코프는 “애플리케이션의 중요 기능에 대한 이중 관리자 제어 기능을 만들어 관리자가 한 번의 실수로 플랫폼 가동 시간과 가용성을 완전히 변경할 수 없도록 하라”라고 조언했다.
자블로코프는 또한 다단계 인증 구현, 불필요한 외부 액세스 차단 등 다른 기본 사항도 언급했다.
권장 사항: 정보 보안 전문가는 OWASP 상위 10개 취약점 및 SANS 위험 소프트웨어 오류 25가지 등의 최신 취약점을 검토해야 한다. 이를 통해 보안 체크리스트, 교육 및 지원을 데브섹옵스팀에 제공할 수 있다.
12. 핫 스탠바이 환경 구성
애플리케이션을 배포하는 기업은 견고한 클라우드 인프라를 보장해야 한다. 이를 위해 인프라를 코드로 배포하고, 클라우드 자동화를 사용해 환경을 확장하고, 멀티존 배포를 구성하고, 장애 조치를 자동화할 수 있다. 이는 엔터프라이즈 애플리케이션 배포의 표준 관행에 가깝지만, 사업부 및 부서에서 개발된 많은 애플리케이션이 이런 인프라 모범 사례 없이 배포됐을 가능성이 있다.
자블로코프는 “하이퍼스케일러에 아무리 많은 중복 및 장애 복구 기능이 내장돼 있어도 자체적인 장애에 대해서는 영향을 미치지 않는다. 따라서 다른 클라우드 서비스 업체에서 애플리케이션을 핫 스탠바이로 실행해야 한다”라고 조언했다.
권장 사항: 표준 아키텍처, 플랫폼, 구성을 개발하는 데브섹옵스팀이라면 고가용성 사례를 인프라 패턴에 더 쉽게 적용할 수 있다.
핵심은 균형
제시된 원칙과 모범 사례는 데브섹옵스팀을 위한 가이드라인이다. 애플리케이션 안정성, 성능 및 보안을 개선하는 데 있어 어려운 부분은 투자가 필요한 운영 영역의 우선순위를 정하고 기능적 요구 사항과 균형을 맞추는 작업이다. 운영 메트릭을 추적하고, 우선순위를 논의하며, 투자할 부분을 파악하는 애자일 개발팀이 더 나은 경험과 운영 성과를 제공할 가능성이 높다.
* Isaac Sacolick는 애자일, 데브옵스, 데이터 과학을 다룬 ‘Driving Digital: The Leader’s Guide to Business Transformation through Technology’의 저자다. dl-ciokorea@foundryco.com
