IT 자동화 코드도 소처럼 다루세요.

IT 부서는 IT를 운영하는 데 필요한 코드의 표준화를 수용해야 하며, 그렇지 않으면 IT 자동화의 재정적, 효율성적 이점을 앗아가는 시스템을 만들 위험이 있습니다.

저는 거의 10년 동안 소프트웨어를 개발했습니다. 내장된 소프트웨어. 웹 소프트웨어. 클라이언트-서버 소프트웨어. 미들웨어 및 메인프레임 소프트웨어. 저는 9개의 다른 언어로 전문적으로 코드를 작성했습니다. 흥미로운 점은 제가 같은 조직에서 두 개 이상의 언어를 사용한 적이 없다는 것입니다.

대부분의 기업 조직에서는 서버, 플랫폼, 프레임워크뿐만 아니라 언어도 표준화합니다. 몇 분 이상, 때로는 수십 년 동안 수명이 지속되는 소프트웨어의 경우 유지 관리가 가능하다는 목표가 있습니다. 유지보수성은 소프트웨어의 특성으로, 다른 사람이 이를 인수하여 수명 주기 내내 지원할 수 있게 해주는데, 수명 주기를 어떻게 측정하든 상관없습니다. 이는 개발자 이탈률과 언어 능력에 대한 시장 가용성, 교육 비용 및 일반적인 유지 관리 비용 때문인 경우가 많습니다. 일반적으로 기업에서는 프로그래밍 언어를 표준화합니다.

이는 매우 다양한(다국어) 언어 세트를 지원할 수 있는 능력을 이점으로 내세우는 마이크로서비스 및 서버리스 컴퓨팅의 현재 추세에 어긋납니다. 밥과 그의 팀은 Go로 작성할 수 있고, 앨리스와 그녀의 팀은 C나 Java 또는 Lambda로 개발할 수 있습니다. 개발자에게는 확실히 보너스가 될 수 있지만(개발자들은 모두 자신만의 언어를 가지고 있습니다) 장기간 소프트웨어를 유지 관리해야 하는 기업 조직에는 그다지 좋지 않습니다. API를 사용하면 통합과 사용이 가능하므로 구현 언어는 애플리케이션 개발 측면에서 크게 중요하지 않지만 기업에서는 기본 코드를 계속 유지 관리해야 합니다.

IT 자동화(비즈니스의 생산 측면에서 발생하는 내부 디지털 변환)와 관련하여 조직에서는 이를 지원하기 위해 구축된 스크립트 및 시스템의 표준화의 이점뿐만 아니라 표준화를 수행하지 않을 경우의 함정도 인식하는 것이 중요합니다. 다음 주나 다음 달, 심지어 내년에 버릴 목적으로 이러한 시스템을 구축하지 않았기 때문입니다. 이는 향후 수년간 배포의 디지털화를 지원할 장기 투자입니다. 즉, 전 세계 기업의 앱 개발자들이 수십 년간 습득한 모범 사례를 바탕으로 유연하면서도 견고한 기반을 마련하는 것을 의미하는데, 그 중 첫 번째가 표준화입니다.

1. 유지 보수성

당신은 PERL로 글을 쓰는 걸 좋아하지만 다른 사람들은 모두 Python을 사용합니다. 자신이 좋아하는 언어로 자동화를 개발하면 그 언어는 자신의 애완동물이 되어, 앞으로 다른 사람이 유지보수할 수 없게 됩니다. 그건 당신에게 좋지 않아요. 8살 때 부모님께 간청해서 사줬던 금붕어처럼, 당신은 수년 동안 그걸 가지고 살아야 할 테니까요. 이는 조직에 좋지 않습니다. 조직을 이전하면 유지 관리할 수 없는 코드에 갇히고 지원에 어려움을 겪을 수 있습니다. SIG와 O'Reilly가 실시한 2016년 설문 조사 에 따르면 "응답자의 70%가 성능이나 보안과 비교해도 유지 관리가 코드 측정에 가장 중요한 측면이라고 생각한다"고 밝혔습니다.

그것이 정말 중요해요. 스크립트와 시스템을 현재와 미래에 IT 담당자 대부분이 쉽게 수정하고 지원할 수 있는 공유 리소스로 보세요.

2. 호환성

점점 더 많은 IT 서비스가 소프트웨어로 구현됨에 따라 이를 최신 상태로 유지하고 다른 시스템과 호환되도록 하는 작업이 커집니다. REST API가 "이전 버전과의 호환성" 문제를 해결한다고 생각한다면 잘못된 생각입니다. API는 제품이기 때문에 끊임없이 진화하고 있습니다. 그리고 "네트워크"에서는 상황이 더 심각합니다. 동일한 제품군 내에서도 차이가 있고, 버전 간 API 차이가 있어 표준화가 시시포스의 작업처럼 느껴집니다. API 표준화는 너무 널리 퍼진 문제로 , Smart Bear의 2016년 API 현황 보고서에 응답한 4명 중 1명에 따르면 향후 몇 년 동안 해결해야 할 기술 과제 목록에서 3위를 차지했습니다.  

IT에서 사용하는 많은 언어가 해석되기 때문에 버전 간 변경으로 인해 신중하게 설계된 자동화 스크립트와 시스템이 파괴될 수 있습니다. node.js를 한 버전에서 다른 버전으로 변경하면 스크립트 손상부터 예상치 못한 동작까지 엄청나게 부정적인 영향을 미칠 수 있습니다. 안정적인 버전의 스크립팅 환경과 언어를 표준화하면 이러한 변경으로 인한 영향을 최소화하는 데 도움이 됩니다.

그리고 여전히 자동화를 구동하는 모든 기본 시스템에 대한 패치와 업그레이드를 관리해야 하므로 적을수록 좋습니다.  

3. 문제 해결

표준화를 무시하면 문제 해결에 어려움이 따릅니다. 특히 IT KPI에 대해 해결 시간 기반 지표를 사용하는 경우 이 점이 중요합니다. 문제를 찾는 데 시간이 오래 걸릴수록 해당 지표는 더 나빠 보입니다. 표준화는 문제 해결 시간을 단축하는 데 중요한 요소입니다. 직원 중에서 유일한 Python 전문가가 밥이고, 휴가 중이어서 연락이 되지 않고, 그의 스크립트가 망가졌다면, 문제 해결을 맡은 사람은 일주일 동안 힘든 시간을 보내야 할 것입니다. IT 부서가 선호하는 언어를 사용하도록 장려하면 다른 사람들이 문제를 해결하고 해결하는 능력이 심각하게 제한됩니다. 밥이 휴가 중이 아니고 문제를 찾을 수 없더라도 도움을 줄 수 있는 사람은 거의 없습니다.

이건 당신이 엉뚱하게 손을 대고 싶어하는 분야가 아닙니다. InitialState 에 따르면, 버그를 수정하는 데는 코드 한 줄을 작성하는 데 걸리는 시간보다 30배나 더 오래 걸립니다. 익숙하지 않은 코드에서 버그를 찾아 수정 하는 동안 돈이 천천히 파쇄기로 들어가는 모습을 시각화할 수 있습니다. 그다지 보기 좋은 이미지는 아니다. 문제 해결에 드는 비용을 없앨 수는 없지만, 원래 언어를 모르는 사람이 처리해야 하는 추가 시간을 없앰으로써 비용을 제한할 수는 있습니다. 제작 과정에서는 시간이 곧 돈이므로 문제 해결 시간을 단축하기 위해 무엇이든 하는 것은 큰 의미가 있습니다.

그렇기 때문에 IT 부문이 스크립팅 언어, 도구, 시스템을 천천히 받아들이면서 앱 개발과 동기화하는 것이 나쁜 생각이 아닙니다. IT 부서가 동일한 시스템과 언어(또는 적어도 일부)를 표준화하면 문제 해결 및 코드 검토와 같은 다른 개발 관련 프로세스를 지원할 수 있는 많은 전문가를 확보할 수 있습니다. 버그가 문제를 일으키기 전에 버그를 찾는 수단으로 코드 검토를 구현하고 있는 게 맞나요? 오른쪽?

표준화는 비용 상승에 대처하는 수단으로 언급되며, 그러한 노력에 확실히 핵심적으로 기여합니다. 하지만 표준화에는 기술 부채 최소화, 해결 시간 단축, 일상적인 운영 유지 관리 간소화 등 다양한 이점이 있습니다. 전혀 표준화를 하지 않으면 예산과 시간에 오히려 반대 효과를 가져옵니다. 복잡성과 병목 현상이 생겨 자동화의 이점이 무효화되고, 기업이 성장에 필요한 수익과 생산성을 실현하지 못하게 됩니다. IT 자동화 여정을 시작하거나 계속할 때 해당 스크립트와 시스템을 개인 애완동물이 아닌 가축처럼 다루어야 한다는 점을 기억하세요. 애완동물은 지속적이고 개인적인 관심이 필요하기 때문에 IT가 이를 감당할 여력이 없습니다.