12/22/2025

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

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



Share:

잠깐, 글이 유익했나요?

Donate!

0 Comments:

댓글 쓰기