기고 | 클라우드 속 정체 상황을 막아줄 12가지 원칙

스타워즈에 등장하는 거대한 도시 혹성 코르산트(Coruscant)를 기억하는가? 이 곳에서 모든 이들은 하늘을 날아 다니며 3차원 교통 흐름을 구성한다. 덕분에 이 공상 과학 세계 속에서는 어떠한 교통 체증도 발생하지 않는다.

그러나 현실 세계 속 도로의 모습은 이와는 매우 다르다. 진정한 스릴을 경험하길 원하는 이들이라면, 뱅갈로나 로마의 도로를 달려보기를 추천한다. 그곳의 택시들은 반대편 차선을 역 주행하거나 인도를 심지어는 그곳이 자갈밭일지라도 달리곤 한다.

그렇다면 클라우드의 세계에서도 부드럽고 원활한 공상 과학적 배치가 가능할까? 물론 외부 시스템이나 써드 파티 어플리케이션과의 상호 작용이 적은 간단한 애플리케이션들에서는 이러한 배치가 큰 문제로 다가오지 않을 것이다. 그러나 규모와 구조가 복잡해지면 이야기는 달라진다. 이제부터 소개하는 사항들에 귀를 기울인다면, 복잡한 클라우드 배치 과정에서도 원활한 흐름을 구현할 수 있을 것이다.

1. 운전 면허를 확인하라. 배치 작업에서의 정체와 사고를 예방하기 위해서는, 관리 증명(administrative certification)을 반드시 확인해야 한다. (많은 경우에서 이는 개발자 인증서(developer certification)보다 중요한 역할을 한다.)

2. 제안된 변화 사항에 대한 아키텍처 리뷰(architectural review)를 진행하는 절차를 포함시켜라. 접근 통제나 비준 규정, 혹은 옵션집합 밸류(picklist value)에 대해 이루어지는 변화들은 일면 사소한 것으로 보여지곤 하지만, 사실 커다란 영향력을 지니는 요소들이다. 그리고 그 영향은 한 개 이상의 팀이 동시 작업을 진행할 경우 더욱 확대될 것이다.

3. 클라우드 테크놀로지 전반에 걸쳐 작업이 가능한 구성 관리 (혹은 적어도 회계) 툴을 찾을 수 있다면, 사용하라. 혹, 이들의 발견이 어렵다면, 버전(version) 관리 문서를 통해 변화 과정을 추적해야 한다. 이때 구글 문서도구는 좋은 해답이 될 수 있다. 특히 주 단위의 기록을 위한 고정 파일(static file)로 문서를 저장하는 경우, 이것의 역량은 극대화될 것이다.

4. 모든 모듈들이 90% 이상의 테스트 커버리지(test coverage)를 담보하는지 확인하기 위한 유닛 테스트(unit test)를, 그리고 주요한 긍정적, 부정적 테스트 사례들을 파악하기 위한 검증 테스트를 시행하라. 비즈니스의 핵심 논리는 간단하다. 언제나 테스트에 기반한 개발법을 적용하는 것이다.

5. 코드에 변화가 없었더라도, 매일 모든 유닛에 테스트를 진행하고 그 결과를 기록하라. SaaS 플랫폼이나 써드 파티 소프트웨어의 요소들은 알아차리지 못하는 사이 변화될 수 있다. 만일 어떠한 유닛 테스트가 실패했다면, 여기에 가장 큰 집중을 쏟아야 할 것이다.

6. 정기적으로 ANT나 다른 유사한 스크립터블 배치 시스템(scriptable deployment system)을 사용하라. 그리고 애자일 지속적 통합 베스트 프랙티스(CI(Continuous Integration) best practice)를 따라야 한다.

7. 대표 테스트 데이터를 통해 모든 외부 인터페이스에 시스템 수준 테스트(system-level test, 예를 들자면직전 테스트 시행 이후 신규 고객 추가 확보 현황(통과 기준 50%))를 진행하라. 이는 데이터베이스에 통계적 정확성을 담보해 줄 것이다.

8. 코드에 변화가 없었더라도, 적어도 일주일에 한번은 모든 시스템을 테스트하고 그 결과를 기록하라. 플랫폼이나 써드 파티 소프트웨어 요소들에서 발생하는 변화뿐 아니라, 시스템의 데이터에 발생한 확장과 변화 역시 과거에 테스트 되지 않은 방식으로 코드 경로에 변화를 야기할 수 있기 때문이다. 이 과정에서의 테스트 실패 역시 중요한 문제로 인식되어야 한다.

9. 정기적으로 동기화와 재생이 이뤄지는 복수의 샌드박스(sandbox)를 확보하라(기본적으로, 서브 팀당 한 개씩). 동기화/재생 사이클은 확실하게 관리되어야 하는 팀의 주요 주제다.

10. 시스템 관리 증명 관리 작업은 지속적으로 이루어지는 실험 과정에서 실험적 변화가 발생하지 않도록 해 줄 것이다.

11. 샌드박스나 생산 시스템에 문서화되지 않은 변화가 발생하지 않도록 관리하라.

12, 각종 변화가 생산 시스템에 직접적으로 적용되지 않도록 관리하라.

현실 세계에서 필요한 작업
공상은 좋다. 그러나 클라우드 벤더들은 무서운 속도로 혁신을 계속하고 있고, 배치 인프라와 원칙은 아직 성숙 단계에 접어들지 못한 상황이다. 시장의 선진적 클라우드 벤더들은 그들의 직접적 고객들에겐 만족을 주고 있지만, 그들이 다른 벤더들의 테크놀로지에 대하여 무언가를 제공하는 것은 아직 기대하기 힘든 상황이다.

그리고 위에 소개된 배치 인프라와 원칙을 적용하는 작업들 역시 많은 팀들에게는 여전히 어려움으로 남아있다. 이는 누구에게나 적용될 수 있는 이야기다. 직면한 위협이 무엇인지 평가하고 이 문제를 적절히 해결하는데 역량을 최우선적으로 투자해야 한다.

팀이 당장의 문제에 직면해 있다면(예: 버그 수정판 배치의 실패 등), 우선 그 자갈밭에서 빠져 나오는데 집중하라. 상황을 관리하는 데에도 실패한 채 다음 목적지를 생각하는 것은 이치에 맞지 않는 행동이다.

다음으로, 불필요한 변수를 줄여 문제를 간소화할 방법을 고민해보라. 급한 불을 끈 후라면, 다른 새로운 기능의 배치에 앞서 기존의 배치 인프라와 작업들을 정돈하는 게 현명한 선택일 것이다. 갚아야 할 기술 부채(technical debt)가 남아있다는 사실을 기억하자.

모든 새로운 프로젝트에는 ‘배치세(deployment tax)’가 부과됨을 명심하여 배치 인프라와 원칙이 자원에 굶주리지 않도록, 그리고 상황의 변화로부터 생겨나오는 새로운 과제들에 대응할 수 있도록 하라. 그렇지 않는다면, 정체 상황에서 벗어날 수 없을 것이다.