애플리케이션 주도 인프라 배포: 소프트웨어 전달 효율성 높이기

Kief Morris는 ThoughtWorks의 Distinguished Engineer로서 다양한 조직의 '시계'를 보며 이야기를 전달하는 역할을 합니다. 그는 여러 고객사에서 배운 바를 공유하며, '시간이 몇 시냐'고 물을 때 '경우에 따라 다르니 몇 가지 이야기를 해드리겠습니다'라고 답할 수 있는 전문가로서 활동합니다. 그의 목표는 배우고 공유하는 것입니다.

Kief Morris는 2016년에 'Infrastructure as Code' 초판을 저술했습니다. 그는 이 개념을 만들어낸 것은 아니지만, 고객들과의 경험을 통해 배운 내용을 더 많은 사람들과 공유하는 데 책이 유용할 것이라고 판단했습니다. 올해 초에는 이 책의 3판이 막 출간되었습니다.

클라우드와 Infrastructure as Code가 처음 등장했을 때, 이들은 인프라스트럭처를 주문형으로 즉시 얻을 수 있고, 코드를 통해 인프라스트럭처가 일관되고 신뢰할 수 있게 될 것이라고 약속했습니다. 이는 한 환경에서 배포했을 때 작동하다가 다른 환경에서 문제가 생기는 상황을 방지할 수 있을 것이라는 기대를 모았습니다.

궁극적으로 우리가 원하는 것은 소프트웨어 팀이 필요할 때 필요한 인프라를 확보하는 것입니다. 동시에 인프라 전문가는 그 인프라가 고품질이고, 올바른 기능을 수행하며, 최상의 방식으로 구축되고, 잘 관리되도록 하는 데 시간을 집중해야 합니다. 이러한 역할 분담을 통해 전반적인 효율성을 높이는 것이 목표입니다.

클라우드 제공업체들이 탁월하게 해낸 한 가지는 '기본적인 것'이 무엇인지 식별하고 이를 API 뒤에 숨겨 개발자들이 더 이상 걱정할 필요가 없게 만든 점입니다. 예를 들어, 과거에는 하드웨어 브랜드 선택이 중요한 문제였지만, 이제는 더 이상 고민할 필요가 없는 영역이 되었습니다.

비즈니스 전략 및 제품 의사 결정권자들은 원하는 바를 달성하기까지 인프라에 너무 오랜 시간이 걸리고, 문제가 발생하며, 비용이 많이 든다고 불만을 표합니다. 반대로 인프라 담당자들은 일을 더 잘하게 만들 수 있는 시간, 우선순위, 투자를 받지 못한다고 말합니다. 이러한 언어의 간극을 소통하는 방법의 일부가 측정이라고 생각합니다. 측정을 통해 양측의 불만을 해소하고, 비즈니스 전략과 인프라 운영 사이의 간극을 줄일 수 있습니다.

비용은 인프라 운영에서 매우 큰 요소입니다. 지출을 줄이는 방법을 찾는 것도 중요하지만, 종종 그 지출에서 나오는 가치를 간과하는 경우가 많습니다. 예를 들어, 한 조직이 한 달에 1천만 유로를 클라우드 비용으로 지출해도 그것이 엄청난 가치를 제공한다면 이는 좋은 투자일 수 있습니다. 반대로 1만 유로를 지출하는 조직도 그 비용 때문에 어려움을 겪을 수 있습니다. 따라서 비용을 가치와 함께 파악하는 것이 중요합니다.

소프트웨어 전달의 성과, 가용성, 보안과 같은 비기능적이고 교차 기능적인 요구사항들은 중요한 측정 지표가 됩니다. 이러한 모든 지표들은 우리가 만들어내는 절충점들이 어디에 있는지 확인하고 균형을 맞추는 데 도움을 줍니다.

인프라 관리에서 중요한 역량 중 하나는 다양한 시점에서 빌드를 배포할 환경을 제공하는 것입니다. 여기에는 개발, 테스트, 스테이징 환경 등이 포함됩니다. 또한 인프라가 배포된 후 업데이트, 업그레이드, 패치, 개선 사항 또는 새 버전과 같은 변경 사항을 어떻게 적용할지 관리하는 것도 핵심적인 역량입니다.

애플리케이션 빌드를 배포할 때 문제가 발생하여 사람들이 시간을 들여 조사하고 수정하며 재시도해야 하는 경우가 빈번합니다. 이러한 문제는 엔드투엔드 프로세스의 핵심 지표인 배포 실패율, 리드 타임 등과 밀접하게 관련되어 있으며, 가치 흐름의 사이클 타임에도 영향을 미칩니다. 이러한 문제의 주요 원인 중 하나는 충분한 환경이 부족하거나, 환경이 공유되어 충돌이 발생하는 것입니다.

각 팀에 전용 환경을 제공하는 방식은 비용이 많이 들고 활용률이 낮다는 문제가 있습니다. 예를 들어, 최근 협업했던 클라이언트의 팀들은 각 팀마다 두 개의 개발 환경을 가졌음에도 여전히 문제가 발생했습니다. 더 많은 환경을 실행할수록 비용은 증가하며, 환경이 사용되지 않을 때는 유휴 상태로 방치되어 불필요한 비용을 발생시킵니다.

현재의 인프라 구축 방식은 여전히 수작업 프로세스에 의존하고 있습니다. 인프라 팀이 코드를 실행하고 모든 것이 작동하는지 확인한 후, 개발 팀에 넘겨주면 개발 팀은 소프트웨어를 배포해야 합니다. 이 과정에서 문제가 발생하면 '인프라에 문제가 있다'는 식의 논쟁이 자주 발생하여 비효율성을 초래합니다.

많은 팀이 실제로 사용하거나 제안하는 접근 방식은 인프라를 관리하고 배포하는 방식에 더 애플리케이션 중심적인 접근 방식을 취하는 것입니다. 이는 애플리케이션 개발자가 직접 필요한 인프라를 정의하고 요청하며, 인프라 팀은 이를 위한 서비스와 도구를 제공하는 모델을 의미합니다. 이러한 전환을 통해 인프라 프로비저닝의 속도를 높이고, 개발 팀의 자율성을 강화하며, 인프라와 애플리케이션 간의 마찰을 줄일 수 있습니다. 궁극적으로는 소프트웨어 전달의 전반적인 효율성을 향상시키는 것을 목표로 합니다.

오케스트레이션 도구 환경은 아직 매우 초기 단계에 있습니다. 다양한 도구들이 이 문제를 다양한 방식으로 접근하고 있지만, Kief Morris가 함께 일했던 대부분의 팀은 이런 종류의 도구를 직접 구축했습니다. 그러나 이 문제를 더 나은 방식으로 해결해야 한다는 압력을 느끼며, 점점 더 많은 팀들이 솔루션을 모색하고 있습니다.

애플리케이션 개발자로서 필요한 것은 단순히 데이터베이스 인스턴스가 아니라, 어떤 종류의 데이터를 저장할 것인지에 대한 명확한 이해입니다. 예를 들어, 개인 정보를 저장하는 경우와 다른 유형의 데이터를 저장하는 경우에 따라 적용해야 하는 정책이 다릅니다. 따라서 구축되는 구성 요소는 올바른 작업을 수행할 수 있어야 하며, 데이터 종류에 맞는 정책을 자동으로 적용할 수 있어야 합니다.

AI와 같은 새로운 기술이 등장하면서, 다른 팀에서 아직 사용하지 않는 벡터 데이터베이스와 같은 인프라가 필요한 팀이 생길 수 있습니다. 이때 중앙 플랫폼 팀이 모든 인프라를 구축해야 한다면 병목 현상이 발생합니다. 대신, 해당 팀이 인프라를 구축하는 방법을 알거나 도움을 받을 수 있는 사람이 있다면 더 효율적입니다. 하지만 인프라 구성 요소가 사용 가능하게 되기 전에 유효성을 검사하는 파이프라인과 프로세스를 반드시 거쳐야 합니다. 이는 자율성과 안정성 사이의 균형을 맞추는 데 중요합니다.

Terraform 모듈은 유용한 구성 요소 유형이지만, 본질적으로 배포 단위는 아닙니다. Terraform 프로젝트를 모듈로 분리하더라도 전체 배포 시간이 크게 단축되지 않는 경우가 많습니다. 예를 들어, 적용하는 데 한 시간이 걸리는 모놀리식 프로젝트를 모듈로 분해해도 여전히 한 시간이 걸리거나, 여러 모듈을 조율해야 하므로 오히려 시간이 더 걸릴 수도 있습니다. 따라서 단순히 모듈로 분해하는 것만으로는 충분하지 않으며, 배포 단위를 재고해야 합니다.

환경이 더욱 복잡해지는 상황에서 인프라를 어떻게 배포할 것인지가 중요한 과제입니다. 특히 여러 애플리케이션이나 마이크로서비스가 각각 독립적으로 배포되고 테스트되어야 할 때, 단순히 애플리케이션 배포 시 인프라를 함께 배포하라고 말하는 것만으로는 부족합니다. 각 서비스의 독립적인 배포 및 테스트 요구사항을 충족시키면서 전체 인프라의 일관성과 효율성을 유지하는 방안이 필요합니다.

플랫폼 서비스를 배포하는 방법은 설계 접근 방식을 고려할 때 애플리케이션에 속하는 것과 플랫폼 서비스 배포를 분리하여 생각하는 것입니다. Kief Morris는 플랫폼 서비스 역시 단순한 소프트웨어이며, 그들도 하나의 애플리케이션로 간주해야 한다고 말합니다. 이러한 관점은 플랫폼 서비스를 개발하고 운영하는 데 있어 소프트웨어 개발 원칙을 적용하여 더욱 효율적이고 일관된 관리를 가능하게 합니다. 궁극적으로 플랫폼 서비스를 일반 애플리케이션과 동일하게 버전 관리, 테스트, 배포 파이프라인을 거쳐 관리함으로써 안정성과 품질을 높일 수 있습니다.

주문형(on-demand) 및 최소한의 환경을 활용하면 멋진 일들이 가능해집니다. 하나의 애플리케이션 또는 마이크로서비스가 있을 때, 파이프라인을 통해 프로덕션까지 완전히 독립적으로 푸시하고, 시스템의 다른 부분과 독립적으로 릴리스하는 것이 가능합니다. 이를 위해 먼저 자체적으로 테스트하고 싶을 때, 파이프라인 단계에 대한 사양에서 나머지 것들을 모의(mock)할 수 있습니다. 인프라 배포는 데이터베이스 인스턴스, 네트워킹, 그리고 필요한 공유된 것들을 요청할 수 있으며, 배포 오케스트레이션은 필요한 적절한 것들을 선택하고 나머지는 배포하지 않을 수 있습니다. 이는 효율성을 극대화하고 독립적인 개발 및 배포를 지원합니다.