DevOps의 한계와 대안 탐색

약 15년전 등장한 DevOps는 철학이 매우 좋았습니다. 자동화, 지속적 통합(CI), 지속적 배포(CD)는 마치 모든 것을 해결해 줄 것처럼 여겨졌습니다. 하지만, 요즘은 DevOps는 실패했다. 혹은 DevOps는 허구다. 라는 냉소적인 목소리가 나오고 있습니다. 무엇이 잘못되었을까요?

DevOps의 본질은 “문화”와 “협업”이었지 “직무”가 아니었습니다. DevOps는 개발자에게 “코딩부터 배포, 모니터링, 운영”까지 직접하라고 요구합니다. 그러나 이는 인간의 인지 능력을 너무 높게 평가한 것 같습니다. 이유는 Full-stack을 넘어 Full-lifecycle을 요구받는 형태이고 이는 결국 개발 생산성 저하와 번아웃으로 이어질 수 있습니다.

비즈니스의 목적은 “가치 전달”이지 “파이프라인 구축”이 아닙니다. 실용적인 플랫폼을 지향해야 함에도, 필요 이상으로 복잡한 시스템을 구축하며 이를 “DevOps”의 성과라고 착각할 수 있습니다. 고객에게 필요한 기능을 하나 더 만드는 것보다, K8S 클러스터를 얼마나 더 세련되게 구축하느냐에 집중되는 우려가 있을 수 있습니다.

그렇다고 DevOps는 나쁜 개념은 아닙니다. 모든 상황에 적합하지 않을 뿐입니다. 현대적인 DevOps 도구를 적용하기 힘든 오래된 시스템에 억지로 DevOps를 도입하려다가 문제가 발생할 수 있습니다. 그리고 아주 작은 스타트업이나 제품일 경우에는 복잡한 CI/CD 환경을 구축하는 것보다 단순한 배포가 비용 대비 훨씬 효율적일 수 도 있습니다.

위에서 언급한 한계를 극복하기 위해 요즘은 “플랫폼 엔지니어링”이 언급되고 있습니다. 쉽게 말해서 개발자가 인프라 걱정 없이 코드에만 집중할 수 있도록 편의 시설이 다 갖춰진 맞춤형 작업 공간을 만들어주는 일이라고 이해하면 됩니다.

현 Cloud 서비스는 강력함과 복잡함을 지니고 있습니다. 또한 범용 도구라 회사 보안 규정이나 배포 방식을 모릅니다. IDP는 회사 내부 정책을 미리 심어둡니다. 또한 Cloud는 실수를 하여 자원을 삭제할 가능성이 있지만, 잘 설계된 IDP는 안전한 범위내에서 활동하도록 제공됩니다.

DevOps와의 차이점은 아래와 같습니다.

1. 플랫폼을 “제품(Product)”로 인지

플랫폼 엔지니어는 단순히 도구를 설치하는 사람이 아닙니다. 내부 개발자를 “고객”으로 생각하고, 그들이 겪는 불편함을 해결해주는 제품을 만듭니다. 이를 위해 개발자들의 피드백을 받고 지속적으로 개선하지요.

2. 셀프 서비스 기반

개발자가 서버 리소스가 필요할때마다 요청을 보내고 기다릴 필요가 없습니다. 플랫폼에 접속해서 직접 생성하면 됩니다.

3. Golden Path 제공

모든것을 자유롭게 하세요. 라는 것은 막막할 수 있습니다. 플랫폼 엔지니어링은 현 조직에서 가장 안전하고 효율적이라고 검증된 표준경로를 제공합니다. 개발자는 이 길만 따라가면 보안, 성능 걱정없이 배포할 수 있습니다.

플랫폼 엔지니어링을 보면 Cloud와 같은 것 아냐? 라고 생각할 수 있습니다. 차이가 좀 있는데, Cloud는 원재료를 파는 거대한 마트라면, 내부 개발자 플랫폼(IDP)는 그 재료들을 모아 우리 회사 입맛에 맞게 만든 밀키트라고 보시면 됩니다. 그래서 손이 덜 가는 것이겠죠.

결론적으로 DevOps는 사라지지 않았습니다. 다만, 우리가 가졌던 “환상”은 어느정도 사라져야 합니다. 현재 시점은 개발자에게 모든 부담을 주는 대신, 개발자가 편하게 배포할 수 있는 플랫폼 엔지니어링으로 나아가고 있습니다. 중요한 것은 “어떤 도구를 쓰는가?” 가 아니라 “우리 조직이 고객에게 가치를 전달하는데 무엇이 병목인가?”를 객관적으로 직시하는 실용주의 태도라고 생각합니다.

즉, 개발자가 모든 것을 알아야 한다는 상황에서 개발자가 가치를 만드는데 방해되는 병목을 제거한다로 진화하고 있다고 생각합니다.

Read More

DevOps로의 전환을 앞두고

레거시 시스템은 오랫동안 존재해 왔고, 조직은 수년간 이를 사용하였다. 중간중간 어려움은 있었겠지만 익숙해졌다.

대부분 이런 시스템들은 수십년 전에 개발되었으며 현재 상황에 부응하도록 설계되지 않았다. 그 결과 현 시스템을 유지관리하려면 레거시 버전과 OS를 사용해야 했다. 이런 작업들은 현 시대에 개발을 하는 개발팀에게 큰 부담이 될 수 있다.

우선 DevOps에 대해서 모르시는 분도 계실테니, 개념부터 정리한다.

DevOps란 무엇인가?

DevOps는 배포를 더 자주 빈번하게, 신뢰 가능하도록, 시간 소모를 줄이는 것을 목표로 하는 업무의 집합이다. DevOps는 코드 변경과 배포 사이의 시간을 줄여준다.

기존 방식처럼 개발(Dev)팀과 운영(Ops)팀을 나누는 것이 아닌, 팀 간의 경계를 없애기에 이 조직에 소속된 사람은 개발과 운영을 모두 알고 있어야 한다.

기존 방식과 차이점은 라이프사이클을 더 자주 빠르게 진행할 수 있게 해주는 부분에 있다. 더 빠르게 피드백을 받고 더 유연해진다는 장점이 있다.

일반적인 DevOps pipeline을 구현하는 방식은 아래와 같다.

• 코드는 소스 리포지토리에서 관리된다.
• 모든 코드 변경 사항은 자동 빌드, 자동 테스트 등과 같은 자동화된 품질 검사와 코드 검토를 통과해야 한다.
• 다양한 환경에 대한 배포는 자동으로 수행되어야 한다. (수동 또는 로컬에서 수행되지 않음)
• 환경은 지속적으로 모니터링되며 장애 발생 시 회복성이 뛰어나야하고, 자체 복구 기능을 제공해야 하며, 수동 개입이 필요한 경우 개입할 수 있어야 한다.

이런 업무를 수행하려면 아래와 같은 지식을 지니고 있어야 한다.

• 애플리케이션 개발
• 스크립팅
• 네트워킹
• CI/CD에 대한 경험 혹은 최소 하나의 플랫폼을 사용할 수 있어야 함
• 다양한 클라우드 경험

DevOps는 조직내 프로세스의 문화적 변화를 요구한다. 개발자와 IT 운영을 단일 구조로 통합해야 하며, 서로 긴밀하게 협력해야 한다. 거의 모든 것을 자동화되는 DevOps 사고 방식으로 생각을 바꿔야 한다.

DevOps는 개발팀과 운영팀을 결합하여 원활한 소프트웨어 개발 프로세스를 만드는 방법론이다. 이는 계획 및 개발에서 테스트 및 배포까지 전체 라이프사이클을 함께 작업하는 것이다.

현재의 고민

현재 진행하는 프로젝트가 막바지에 다가왔기에, 오픈 이후 운용 모습에 대해서 DevOps를 고려하고 있다. 현재 진행하는 프로젝트는 모든 영역에 대해서 현대화를 하지 않았기에 Batch, 인터페이스 일부는 레거시가 공존하는 구조기에 직면하는 문제들이 존재한다.

내가 경험한 것중 가장 큰 문제는 “마인드셋”을 바꾸는 것이다. 현재 조직은 현대화를 하려고 모인 동료들이기에 큰 문제는 없다. 다만, 기존 시스템을 사용하는 사람들의 마음을 바꾸는게 어렵다는 것을 그동안의 경험으로 많이 느꼈다.

사람들은 레거시 시스템이 비효율적인 부분이 있고, 비즈니스 상황에 맞춰 대응하려고 할때 지연과 비용을 초래함에도 불구하고 변화를 좋아하지 않는다. 이러한 저항은 현재 현상 유지에 대한 집착보다는 미지의 것에 대한 두려움에서 비롯된다고 느껴진다. 그러나 행동하지 않았을 때 비용은 훨씬 더 클 수 있다.

레거시에 어떤 문제가 발생했을때, 문제가 발생한 부분만 들여다보고 해결한다면, 사일로화된 작업 방식일 것이다. 전체적인 관점에서 어떤 해결 방법이 좋을지, 중장기적으로 이 방법이 적절한지 등을 고려해야 한다.

레거시 시스템은 정말 오래된 기술 스택으로 만들어졌다. 현 시점에 관련 개발자를 구하려고 해도 쉽지않다. 아무래도 다들 치킨집 사장을 하고 있을 가능성이 높다. 코드야 그렇다쳐도 그 당시 도입된 솔루션들은 대부분 EOL(End Of Life)된 상황이다. 이런 시스템은 분해하고 리모델링을 하기가 정말 쉽지 않다.

그럼에도

DevOps팀과 레거시 팀 간의 러브스토리를 상상해본다.

DevOps팀이 진행하는 업무는 아마도 레거시팀이 관심을 가지고 지켜볼 것이다. 변화하고 싶은 사람들에게는 매력적이고 설득력 있는 파트너처럼 보일 수 있다.

레거시 팀은 설득이 필요한 완고한 파트너와 비슷하고, 설득이 필요하다. 이런 관점에서 DevOps는 협업과 지속적인 개선이라는 원칙 기반하에 이점을 보여주고 비즈니스의 요구를 충족하는 제품을 만들어 낼 수 있는 방법을 계속 보여줘야 한다.

레거시 시스템과의 결별은 어려울 수 있지만 DevOps의 도움으로 유익한 경험을 제공할 수 있지 않을까? 그래야 레거시 시스템을 현대화하고 개발 프로세스를 개선하는 문화를 만들 수 있을 것이다.

가장 중요한 점은 레거시 시스템의 해체를 두려워하면 안된다.

이제 하나를 현대화 하였으니, DevOps 문화를 만들어가며 언젠가는 남아있는 레거시 시스템에 작별 인사를 하는 날을 상상해본다.

Read More