플랫폼 엔지니어링에 대한 짧은 생각

회사에서 새로운 역할을 맡게 되고 오늘로 딱 6개월이 되는 날입니다. 4월 1일부터 시작했으니 거짓말처럼 오늘이 정말 딱 6개월이 되는 날이네요. 그동안 조직의 방향을 어떻게 잡으면 좋을지 많은 고민들을 했고 그런 고민들을 한 차례 정리도 했었습니다.

 

당근마켓 인프라실, 새로운 비전을 소개 합니다.

당근마켓 인프라실, 새로운 비전을 소개 합니다.

 

위 글에서는 호기롭게 DevSecOps 문화를 실현하겠다고 이야기는 했는데, 그렇다면 DevSecOps 문화를 실현한다는 것은 어떤 것일까에 대해 사실 지금도 계속 생각하고 있습니다. 그리고 오늘 글은 오랫동안 저의 머릿속을 둥둥 떠다니던 여러 가지 생각들을 가볍게 정리해 보는 의미에서 작성해 봤습니다. 

 

그럼.. 시작해 보겠습니다.

---

DevOps와 인지부하

 

DevSecOps 문화에 대해 구글링을 하다 보면 DevOps에 대한 이야기가 자연스럽게 함께 나옵니다. 그리고 이런 DevOps에 대한 여러 가지 글들을 읽다 보면 반쪽짜리 DevOps, 실패한 DevOps에 대한 이야기들도 심심치 않게 나오는데, 그런 글들을 읽다 보면 반복적으로 등장하는 단어가 있습니다. 바로 인지부하입니다. 인지부하에 대한 정의는 아래와 같습니다.

 

인지 부하(cognitive load)는 학습이나 과제 해결 과정에서의 인지적 요구량을 말한다. 어떤 정보가 학습되기 위해서는 작동기억 안에서 정보가 처리되어야 하는데, 작동기억이 처리해 낼 수 있는 정보의 양보다 처리해야 할 정보가 많으면 문제가 생기며 인지부하가 생기게 된다.

- 발췌 : https://ko.wikipedia.org/wiki/%EC%9D%B8%EC%A7%80_%EB%B6%80%ED%95%98

인지 부하 - 위키백과, 우리 모두의 백과사전

 

DevOps는 말 그대로 개발과 운영을 함께 하는 것, You build it, you run it 을 의미합니다. 그리고 이런 DevOps 문화를 잘 실현할 수 있도록 다양한 도구들이 존재하고 이런 도구들을 사내에 도입하는 역할을 하는 엔지니어가 존재합니다. 잘 짜인 파이프라인과 좋은 도구들을 이용해서 DevOps 문화를 실현할 수 있을 것으로 기대하지만 실제로는 그렇지 못합니다. 바로 개발자들의 인지부하 때문이죠. 

 

한 번 생각해 볼까요? 쿠버네티스 환경에서 배포를 효율적으로 하기 위해 누군가 ArgoCD를 구축했다고 가정해 보겠습니다. 그럼 쿠버네티스 환경에서 배포해야 하는 많은 개발팀들은 ArgoCD를 이용해서 배포하게 될 텐데 사실 ArgoCD를 이용해 배포를 위한 매니페스트를 만드는 것은 꽤 어렵습니다. (개인차는 있습니다.) 쿠버네티스에 대한 경험이 많은 엔지니어들이 교육도 하고 더 쉽게 사용할 수 있도록 다양한 템플릿, 예제 등을 만드는 이유도 사실 인지부하를 줄이기 위한 노력의 일환인 거죠. 개발팀들이 ArgoCD를 이용해 직접 배포할 수 있도록 , 즉 개발자들의 인지부하를 줄여주기 위해 노력합니다. 하지만 그럼에도 불구하고 이런 방법은 인지부하를 줄이는 것에 크게 도움이 되지 않습니다. 인지부하를 얼마나 줄일 수 있느냐가 개발자 개개인의 역량과 환경에 무척 많은 영향을 받기 때문이죠. 상대적으로 쿠버네티스와 같은 좀 더 낮은 레이어의 환경에 많은 관심을 가지고 지식이 많은 개발자들이 있는 반면, 그보다는 좀 더 높은 레이어에 관심이 있고 비즈니스 로직을 구현하는 것을 더 선호하는 개발자들도 있기 때문입니다. 모든 개발자가 동일한 역량, 동일한 환경이 아니기 때문에 교육이나 잘 짜인 템플릿 등을 이용한 인지부하 감소 노력은 효과를 보기 어렵습니다. 그렇다고 모든 개발자들의 환경에 맞춰 개인화된 교육을 할 수도 없는 노릇이죠. 할 수는 있겠지만 전혀 지속 가능한 방법이라고 생각되진 않습니다.

 

그러다 보면 결국 ArgoCD를 구축한 엔지니어가 개발팀의 배포를 위한 매니페스트를 대신 작성하거나 배포에 직접적인 도움을 주게 되고 이런 것들이 지속되면서 DevOps 문화를 구현하려는 노력은 더 어려워집니다. 많은 문서에서 바로 이 부분을 반쪽자리 DevOps 문화가 되는 원인으로 이야기하고 있습니다.

---

플랫폼 엔지니어링의 등장

 

그리고 바로 이 대목에서 플랫폼 엔지니어링이라는 이야기가 나오기 시작합니다. 개발자의 인지부하를 줄이기 위한 노력을 교육이나 가이드에서 시스템으로 가져오는 방향입니다. 복잡해 보이는 DevOps를 위한 도구들을 한 단계 더 추상화해서 회사의 상황이나 맥락에 맞게 한 번 감싸는 거죠. 그리고 개발자들은 이 플랫폼을 이용함으로써 모든 개발자가 동등한 위치에서 DevOps 문화를 실현하기 위한 You build it, you run it 을 진행할 수 있게 됩니다. 이 플랫폼을 만드는 것을 플랫폼 엔지니어링이라고 부르고 플랫폼 자체는 Internal Developer Platfotm (이하 IDP) 라고 부릅니다. 

 

추상화를 통해 시스템적으로 인지부하를 줄일 수 있게 노력하는 것이 앞선 다른 방법들보다 훨씬 지속 가능하고 구현하는 입장에서도 더 많은 동기부여가 됩니다. 교육이나 가이드로는 인지부하를 줄이는데 얼마나 효과적인지, 그리고 나의 노력이 얼마나 많은 사람들에게 도움이 되는지 잘 느끼기 어렵지만 플랫폼으로 만들어서 제공한다면 나의 노력이 얼마나 효과를 보고 있는지 훨씬 더 잘 알 수 있습니다. 하지만 그렇다고 해서 교육이나 가이드가 전혀 필요 없는가라고 묻는다면 그렇지 않습니다.

 

추상화는 많은 것들을 추상화했기 때문에 사용하기 쉽게 하는 것이 핵심이지만 경우에 따라서는 기술을 좀 더 깊게 다뤄야 할 경우들이 있습니다. 이런 니즈를 해결하는 것에는 교육이나 가이드가 효과적이라고 생각합니다. 이미 깊게 다뤄야 할 니즈가 있다는 것은 기술에 대한 인지부하가 낮은 상태이고 대상자들도 배우려고 하는 의지가 강하기 때문에 교육과 가이드가 상당한 효과를 만들어 낼 수 있습니다. 또한 플랫폼을 이용해 추상화하기 어려운 부분도 여전히 남아 있습니다. 자동화, 규격화하기 어려운 영역이 여기에 해당하겠죠. 이런 부분들은 여전히 교육과 가이드를 통해 지속적으로 인지부하를 줄이기 위해 노력해야 합니다.

---

다음 단계는 무엇일까

 

그럼 플랫폼 엔지니어링이 지금 우리가 나아가야 할 방향일까요? 여기에 대해서는 그럴 수도, 그렇지 않을 수도 있다고 생각합니다. 생각해 보면 DevOps 라는 개념이 나온 지 꽤 되었는데 플랫폼 엔지니어링이라는 이야기가 등장하기 시작한 건 얼마 되지 않았습니다. 제가 찾아보며 읽은 글들도 대부분 2021년~2022년에 발행되는 글들이었던 걸 보면 이제야 조금씩 이야기가 시작되는 걸음마 단계라고 생각합니다.

 

사실 플랫폼 엔지니어링이라는 개념에 주의를 기울이기보다는 인지부하라는 단어에 조금 더 집중 해야 할 필요가 있다고 생각합니다. 저의 에전 경험들도 돌이켜 보면 인지부하 라는 것을 전혀 고려하지 않고 도구를 도입하고 사용하기를 강요 했다고 생각 합니다. 당장 서비스에 필요한 기능을 구현하기도 바쁜데, 언제 어려운 PromQL을 배워서 필요한 메트릭들에 대한 알람을 설정하고 언제 대시보드를 생성하고 그럴까요. 저도 이런 부분에 대한 이해가 부족했기 때문에 결국 반쪽자리 DevOps 문화를 만들어 내지 않았을까 반성해 봅니다.

 

그래서 제일 중요한 건 인지부하가 있다는 것을 이해하고 어떻게 하면 이것을 줄일 수 있을까, 그래서 그 의미에 충실한 DevOps 문화를 만들어 낼 수 있을까 이것을 고민하는 게 가장 중요하다고 생각합니다.

그리고 플랫폼 엔지니어링은 이를 위한 여러가지 방법 중에 하나일 뿐 이라고 생각 합니다. 다만 개인적으로는 추상화된 플랫폼을 만들어서 인지부하를 줄이는 것, 이 방향이 현재로서는 가장 나아가고자 하는 방향과 가깝지 않나라고 생각하고 있습니다.

 

이 글이 같은 고민을 하고 있는 많은 분들에게 도움이 되기를 바라며 혹시라도 저와 다른 생각들이 있으시다면 댓글을 통해서 이야기 나눠 보는 것도 좋을 것 같습니다. 감사합니다.

---

참고 자료

 

https://www.itworld.co.kr/topnews/251626

글로벌 칼럼 | 데브옵스 시대는 끝났다

https://blog.realkinetic.com/scaling-devops-and-the-revival-of-operations-d647ba6e2374

Scaling DevOps and the Revival of Operations

https://thenewstack.io/how-is-platform-engineering-different-from-devops-and-sre

How Is Platform Engineering Different from DevOps and SRE?