크리스마스가 되면 흔히 들리는 탄식이 있습니다. 지붕 위에서도, 뾰족한 솔가지 아래에서도 그 탄식이 터져 나옵니다.
"전구 하나가 나가면 전부 나가 버려!"
이는 직렬 회로로 연결된 전구 때문에 곤란을 겪는 사람의 절규입니다. 왜 그런지 장황하게 설명하지는 않겠지만, 전구 하나만 나가도 전체 회로가 끊긴다는 것만 알아두면 충분합니다.
병렬 회로로 연결된 전구를 쓰는 운 좋은 사람들에게는 해당되지 않는 이야기입니다. 전구 하나가 나가더라도 나머지는 계속 밝게 빛납니다.
이것이 가치 실현 시간 및 애플리케이션과 무슨 관련이 있을까요? 모든 면에서 관련이 있습니다. 알고 보니 기존 IT는 직렬 회로처럼 프로덕션 환경을 향해 나아가는 반면, 현대적인 애플리케이션 개발은 병렬 회로처럼 밤낮없이 활발하게 진행되기 때문입니다.
프로세스
최근 블로그 글에서, Pivotal 글로벌 현장 CTO인 James Urquhart는 제품보다 프로세스에 중점을 둔 지속적 IT의 중요한 청사진을 제시합니다. 그는 이를 '프로덕션으로 가는 길(Path to Production)'이라고 부릅니다.
프로덕션 전환 경로(Path to Production)의 핵심은 사실 프로세스이며, 전통적인 IT의 경우에는 병렬화입니다. 이 개념은 현대적인 애플리케이션 개발과 아키텍처의 핵심입니다. 애플리케이션을 각각의 특정 기능에 집중하는 개별 구성 요소(마이크로서비스라고도 함)로 분해하면 자연스럽게 병렬 개발로 이어집니다. 소규모 팀들이 서로 다른 구성 요소를 동시에 개발하기 때문입니다. 궁극적으로 애자일이 애플리케이션 개발 속도를 높이고 가치 실현 시간을 단축하는 메커니즘으로 작동할 수 있는 이유도 바로 여기에 있습니다. 핵심은 팀의 규모가 작다는 것도, 애플리케이션의 규모가 작다는 것도 아닙니다. 핵심은 이러한 개념을 애플리케이션 개발 및 제공에 활용함으로써 달성되는 병렬화입니다.
프로덕션 전환 경로에도 동일한 접근 방식이 적용됩니다. 즉, 애플리케이션의 확장성을 구현하고 보안을 보장하는 데 필요한 프로덕션 구성 요소(서비스)는 훨씬 더 큰 프로세스의 일부이며, 그중 일부는 병렬로 개발하고 제공할 수 있습니다.
이를 가로막는 것은 전통적인 IT입니다. 순차적 IT입니다. 개발 영역을 넘어 프로덕션 환경까지 스며든 폭포수식 개발 방법론입니다. 데이터가 네트워크를 통해 순차적으로 흐르기 때문에 우리는 네트워크를 직렬 채널로 구축합니다. 라우터에서 방화벽으로, 로드 밸런싱을 거쳐 애플리케이션 서버와 데이터베이스로 이어집니다. 데이터는 네트워크의 한쪽 끝에서 다른 쪽 끝까지 예측 가능한 경로를 따라 흐릅니다. 따라서 애플리케이션 서비스도 같은 방식, 즉 데이터 경로를 자연스럽게 따르는 예측 가능한 순차적 프로세스로 구현하고 제공합니다.
이제는 그런 방식이 통하지 않습니다.
첫째, 이제는 데이터 경로가 여러 개이기 때문입니다. 남북과 동서를 가로지르는 데이터 경로뿐만 아니라, 다른 방위로 뻗어 나가는 경로도 있습니다. 북동쪽의 클라우드에서 스크립트를 가져오고, 남서쪽에서 스프라이트와 웹 폰트를 가져오며, 서남동쪽에서 지도를 가져와 앱에 삽입합니다.
하지만 오늘날 프로덕션으로 가는 경로를 병렬화해야 하는 이유는 단지 데이터 경로가 분산되어 있기 때문만은 아닙니다. 효율성과 속도, 즉 최적화를 추구하기 때문이기도 합니다.
병렬화
오늘날 요구되는 가치 실현 속도에 부응하려면 병렬 개발이 필요합니다. 이는 애플리케이션 개발뿐만 아니라 핵심 IT 영역에도 해당합니다. 오늘날 조직에서 사용 중인 애플리케이션 서비스의 범위를 살펴보면 병렬화를 통해 배포 속도를 높일 수 있는 여러 영역을 확인할 수 있습니다.
전통적인 IT가 사일로화되어 있다는 점 자체가 문제인 것은 아닙니다. 결국 마이크로서비스 아키텍처를 도입하면 각각 매우 구체적인 애플리케이션 기능에 집중하는 수십 또는 수백 개의 소규모 사일로형 팀이 생겨납니다. 전통적인 IT는 이미 사일로 안에 또 다른 사일로가 있는 구조입니다. 문제는 애자일 개발 방식이 각 사일로 내에서 병렬 개발을 장려하는 반면, 전통적인 IT는 여전히 체계적이지만 순차적인 방식으로 프로덕션 프로세스를 이어가고 있다는 점입니다.
문제가 되는 것은 팀 간의 인계 과정과 프로덕션으로 전환하는 과정에서 네트워크 트래픽을 미러링하는 방식입니다. 이는 순차적인 프로세스가 아니므로, 가능할 때마다 서비스 개발과 제공을 병렬화해야 합니다.
이는 협업을 나중이 아니라 조기에 촉진하는 교차 기능 팀 구조를 의미합니다.
모든 영역에서 애자일 방식을 더욱 폭넓게 도입해 프로세스를 병렬화하면, 조직은 프로덕션 단계에 이르는 과정에서 속도와 효율성을 더욱 높일 수 있습니다.
프로세스가 곧 제품입니다
James가 암시하듯이, 프로덕션으로 가는 길은 사실 하나의 프로세스입니다. 그리고 프로세스는 여러 단계로 구성됩니다. 식스 시그마 블랙벨트급 프로세스 전문가라면 누구나 말하듯이, 프로세스의 속도를 높이려면 비효율적인 부분을 찾아 제거해야 합니다. 프로덕션 환경에서 이러한 비효율은 배포 프로세스의 경직되고 순차적인 단계 사이에서 발생하는 대기 시간(인계)으로 나타납니다.
도구가 도움이 될 수 있습니다. 하지만 궁극적으로 개선하려면 프로세스를 오랫동안 면밀히 검토하고, 프로덕션 전환 과정의 일환으로 애플리케이션 서비스 제공을 병렬화할 기회를 찾아야 합니다.
문화, 특히 협업 문화는 선택 사항이 아닙니다. 이는 행동과 업무 방식에 실질적인 영향을 미칩니다. 팀 구조만으로도 파이프라인 자동화 수준이 크게 달라지며, 전통적인 단일 기능 팀은 현대적인 DevOps 중심 팀에 뒤처지고 있습니다. 더욱 협업적인 팀 구조를 적극적으로 추진해야 합니다. 같은 맥락에서 협업 팀은 핵심 지표에 대한 공감대를 형성해야 합니다. 공통 지표를 사용하면 NetOps와 보안 팀이 불이익에 대한 우려 없이 지속적 배포를 추진할 수 있습니다. 현재 NetOps 팀의 약 4분의 3은 네트워크 가동 시간을 기준으로 평가받습니다. 배포 빈도는 이들에게 거의 평가 지표로 고려되지 않습니다. 이들은 네트워크를 안정적으로 유지하는 데 집중할 수밖에 없습니다. 그것이 바로 이들이 집중해야 하는 평가 기준이기 때문입니다. 공통 지표를 도입하면 NetOps 팀도 비즈니스에 필요한 것, 즉 더 빠르고 빈번한 배포에 집중할 수 있습니다.
마지막으로, 공감이 필요합니다. 여러분은 모두 같은 팀에 속해 있으며, 놀랍게도 같은 가치를 중요하게 생각합니다. NetOps 역시 DevOps만큼이나 파이프라인 자동화를 매우 중요하게 여깁니다. DevOps는 통합, 도구 및 기술 역량과 관련된 장애물을 헤쳐 나가고 극복하는 데 있어 NetOps보다 10년 앞서 출발했다는 점을 기억하세요. 협업하는 팀은 Jenkins 및 GitHub/GitLab처럼 딜리버리부터 배포까지 전 과정을 아우르는 도구의 표준화를 촉진함으로써 도움을 줄 수 있습니다.
프로덕션 환경으로 나아가는 길은 제품이 아니라 프로세스입니다. 가치 실현 시간을 단축하고 애플리케이션을 성공적으로 배포하려면, 이 프로세스는 협업을 기반으로 해야 하며 가능한 경우 병렬로 진행되어야 합니다.
작성자 소개
Lori MacVittie는 F5 CTO 오피스의 수석 엔지니어이자 최고 에반젤리스트로, 애플리케이션 딜리버리, 자동화 전략 및 인프라 분야에서 깊이 있는 전문성을 보유하고 있습니다. AI 에이전트를 위한 가드레일을 정의하고, 취약한 멀티클라우드 아키텍처를 분석하며, 확장 가능한 시스템의 한계를 탐구하는 등 복잡한 문제를 명확하게 풀어내는 것으로 잘 알려져 있습니다. 애플리케이션 개발, IT 아키텍처, 네트워크 및 시스템 운영 전반에 걸쳐 30년 이상의 업계 경험을 쌓았습니다. F5에 합류하기 전에는 수상 경력이 있는 기술 편집자로 활동했습니다. MacVittie는 컴퓨터 과학 석사 학위를 보유하고 있으며, 보안, 클라우드 및 엔터프라이즈 아키텍처 분야를 아우르는 다수의 저서를 집필한 작가입니다. 또한 보드게임과 비디오 게임을 열정적으로 즐기며, 치즈에 대해서는 거리낌 없이 확고한 견해를 갖고 있습니다.
Lori Mac Vittie의 다른 블로그 게시물관련 블로그 게시물
성평등을 향한 여정: 사이버 보안 분야에서 성공적인 커리어를 개척하는 방법에 관한 Jenn Gile과의 Q&A
F5의 ‘성평등을 향한 여정’ 시리즈 네 번째 Q&A에서는 Rachael Shah와 NGINX 제품 마케팅 책임자 Jenn Gile이 사이버 보안 직종에 대한 오해를 바로잡고, 사이버 보안 분야의 성별 격차를 해소하기 위한 조언과 그 이점에 대해 이야기합니다.
TLS 검사에서 피터 파커 원칙 다루기
“큰 힘에는 큰 책임이 따른다.” 볼테르와 처칠도 이와 비슷한 말을 남겼지만, 이 문구는 스파이더맨 코믹스에서 벤 삼촌의 말로 가장 널리 알려져 있습니다. 물론 이 문구가 문화적으로 널리 통용되는 이유 중 하나는 TLS 검사를 비롯해 수많은 상황과 주제에 적용할 수 있기 때문입니다.
Venafi와 F5를 통한 머신 아이덴티티 보호
‘머신 아이덴티티’란 간단히 말해 자동화된 프로세스가 자신의 신원을 식별할 수 있도록 하고, 다른 자동화 시스템과 프로세스가 관련 리소스에 적절한 수준의 접근 권한을 부여하도록 하는 방법을 의미합니다. 이 개념 자체는 새로운 것이 아닙니다. 비교적 새로운 점은 이를 구현해야 하는 규모입니다.
마이너와 미니언: 데이터 유출만이 비용을 초래하는 것은 아닙니다
물론 데이터 유출은 더 큰 비용을 초래할 수 있고(적어도 지금은), 실패 사실을 세상에 드러낼 수밖에 없게 합니다(통지 의무가 있으니까요). 하지만 보안을 단순히 데이터 노출 문제로만 봐서는 안 됩니다. 요즘은 데이터가...
내 클라우드에서 나가!
F5의 Jay Kelley가 전하는 최신 소식에는 Microsoft Office 365용 신규 ID 및 액세스 솔루션을 배포할 때 고려해야 할 사항이 정리되어 있습니다.
Shift(웹 앱) 보안 레터
웹 앱 보안을 개발 초기 단계로 앞당기세요. F5 블로그에서 DevOps 파이프라인 초기에 보안을 통합하여 취약점을 예방하고 시간을 절약하는 방법을 알아보세요.