DevOps Korea 좌담회 2024.4.15.

GS약 7 분

DevOps Korea 좌담회 2024.4.15.

일시 : 2024년 4월 15일 (월) 19:00
안내 :
- Facebook : DevOps Korea - DevXOps로의 확장에 따른 이해와 토론
- GitHub : https://github.com/ralfyang/DevOps_Korea_sitting_talking/tree/main/20240415
장소 : 교보타워 - 당근마켓
주요 아젠다
- DevXOps란?
- DevOps engineering 역할의 확장
- 개발/검증/운영에 관련한 자동화 영역의 확장
- 기술 방법론을 넘어 산업의 Needs로의 확장 → XXOps

🚀 DevOps를 한다는 것은?

🤝🏻 내부 고객의 만족

A: DevOps는 "잡부" 죠.
B: 그래서 저는 "스티브 잡부"라고 말합니다.

DevOps가 지향하거나, 그 효과가 무엇이냐고 묻는다면 요구하는 '내부 고객'의 요구사항을 대응하는 활동에 대한 전달이 빨라지는 것 이라고 볼 수 있다. 최종적으로는 비즈니스와 맞닿은 요구사항의 전달이 빨라지는 것을 기대할 수 있다.

DevOps, BizOps, AIOps, DevSecOps 등 수많은 XXOps 용어들이 있다. 특이한건 모두 Ops로 끝난다는 점이다. DevOps가 개발(Development)과 운영(Operations)의 합성어라고 하지만 Ops가 기존에 우리가 알던 그 운영은 아닌것 같다. 요구사항을 실행하는 것이라는 표현 하에, XXOps는 그 XX를 위한 엔지니어링에 가깝다고 보여진다. XX의 요구사항을 실행하는 행위 또는 조직 같은 설명에 더 가깝다.

DevOps : 개발을 위한 무엇인가의 요구사항을 실행하는 것
BizOps : 비즈니스를 위한 무엇인가의 요구사항을 실행하는 것
AIOps : AI를 위한 무엇인가의 요구사항을 실행하는 것

XXOps를 하기위해서는 XX에 대한 이해도가 필요하다. XX가 요청하는 바를 이해할 수 있어야 하고, 그들이 추상적으로 생각하는 요구사항을 구체화할 수 있는 지식이 필요하다. 이것은 XXOps 이전에도 중요한 역량이라고 알려진 도메인 지식과 메타 인지에 해당된다 보여진다.

🤖 자동화와 AI의 일자리 위협에 대해

DevOps하면 자동화 이야기가 빠질 수 없고, AI에 대한 이야기도 지난 좌담회에 이어 언급되었다. 이런 발전이 일자리에 대해 위협이 되는 분야도 있고, 이미 그 영향을 받는 영역도 생기고 있다.

Stable Diffusion 을 활용하여 기존 일러스트레이터의 업무가 생산에서 평가로 변경된 사례가 언급됨
비슷한 내용의 기사 : 블리자드, 인공지능 활용해 게임 개발한다

하지만 반면 자동화와 AI가 일을 줄일것인가에 대한 이야기에서는 일이 줄어드는게 아니라 일을 할 수 있는 범위와 처리 능력이 증가한다는 관점으로 볼 수 있다고도 했다.

팁

자동화는, AI는, DevOps는 ~~우리를 더 많이~~ 우리가 더 많은 일하게 합니다.

🔮 구슬이 서 말이라도 꿰어서 팔아야 보배

구슬이 서 말이라도 꿰어야 보배

구슬이 많아 봐야 실에 꿰지 않으면 쓸모없다는 표현인. 아무리 좋은 것이라도 쓰기 좋게 다듬어 놓지 않으면 소용없다는 의미인 속담이 있지만, 좌담회에서 언급되었듯, 이제는 보기에만 좋은게 아닌 팔리는 것 까지에도 신경을 써야 한다. 운영, 보안 등을 위한 활동은 기업 내에서 잘해야 본전 정도로 취급받는 경우가 있다. 실제 수익을 발생시키는 행위(영업, 개발)에 비해 그 효과를 측정하기가 어려운 부분이기도 하다. 국내에서는 인건비와 소프트웨어 개발 활동에 대해 인색한 편이기도 하다.

XXOps를 해서 얼마가 줄었는지, 어느정도의 비용 효과가 있는지 증명하기도 어렵거니와, 증명 하더라도 비즈니스와 맞닿아있는 조직에서 XXOps의 성과를 평가절하 할 수도 있다. 😢

📊 DevOps의 수준

DevOps를 기준으로, 우리 조직이 얼마나 잘 DevOps를 하고 있는지 안다면 그 가치를 입증할 수 있을까? 조직 내에서 DevOps를 해야 하는것이라고 설득할 수 있을까?

DevOps를 정의하는 방식과 행위는 다양하다. 이전 좌담회에서 언급했듯, DevOps란 대상간의 간극을 줄이는 행위라고도 할 수 있고, CI/CT/CD의 수준, 혹은 문화라고도 정의할 수 있다.

Google Cloud에서 발행한 The ROI of DevOps Transformation에서도 언급된것 처럼 전통적으로 IT는 비용을 '쓰는' 조직으로 여겨져 왔다. DevOps에 투자 대비 수익을 계산하는데 그 조직이 수익에 대한 영역을 어디까지 확장할 수 있는가가 DevOps의 가치에 큰 영향을 끼칠 것으로 예상된다. (관련 리포트를 정리한 글(한글)도 좋은 참고가 된다. : DevOps 로 전환 시의 ROI (The ROI of DevOps Transformation))

ROI는 투자와 수익에 기반한다.
투자에는 교육, 학습, 통합, 그리고 과정상 발생하는 생산성 저하, 유지보수, 교체에 따른 소요 시간 등이 포함된다.
수익은 가치 중심 접근(서비스 전달 속도)과 비용 중심 접근(비용 절감과 업무 효율성)으로 나뉜다.

좌담회 자리에서 측정 방식과 관련하여 DevOps 수준을 평가하는데 있어 Flow framework에 대해서도 언급해주셨다.

Flow Framework ®이란?
Flow Framework는 병목 현상을 해결할 수 있도록 제품 가치 스트림 전체에서 작업이 흐르고 느려지는 위치를 식별합니다. 이 프레임 워크는 또한 기술 리더에게 비 기술적 (및 비 민첩한) 언어를 제공하여 우선 순위를 설정하고 결과를 측정 할 때 비즈니스 이해 관계자와 효과적으로 의사 소통 할 수 있도록합니다.
https://flowframework.org/

💰 DevOps의 가치는 입증되었는가?

DevOps를 시작하는 이유는 다양할 수 있고, 현실적인 문제로 인해 아직 방법론을 적용하지 못한 사례도 있다. 좌담회 중에서는 게임 쪽의 특수성에 대한 이야기도 있었다.

게임에서의 DevOps의 한계 및 어려움 - SanAh Kang

반면에 DevOps로 논의되는 범위와 방법이 너무 많고 다양하다보니 어떤식으로 시작해야 하는지에 대한 질문도 있었다. 여기에 대해서는 "불편함을 제거하고 위험을 최소화" 할수있는 것부터 시작해보는것에 대해 조언을 주시기도 했다.

DevOps가 시작되고 언급된지 국내에서도 꽤 오랜 시간이 흘렀지만 그 수준과 정도에 대한 차이는 여전히 크다 보여진다. 문득, 자동차 정비업을 하는 친구 이야기가 떠올랐다.

... 아직까지도 종이에다가 부품 재고를 관리하고 있더라고, 내가 엑셀로 정리해서 딱 보여줬더니 사장이 깜짝 놀라는거야. 내가 거기선 컴퓨터 제일 잘하는 녀석이 됐더라고. - 2023년 겨울 어느날

아직은 국내 많은 기업의 정서상, 앞선 ROI이야기에서처럼 IT에 대한 투자는 곧 비용인것 처럼 보인다. 그나마 강력한 브랜드가 있는 기술 기업에서 지속적으로 기술에 대한 중요성과 나아가야할 방향에 대해 언급해주는 것이 인식의 변화에 도움이 된다 생각된다.

DevOps가 중요한 이유 - 소프트웨어와 인터넷은 쇼핑에서 엔터테인먼트 그리고 뱅킹에 이르기까지 전 세계와 산업을 변화시켰습니다. 이제 소프트웨어는 비즈니스를 지원하는 것에 그치지 않고, 비즈니스의 모든 부분에서 핵심적인 구성 요소가 되었습니다. 기업은 온라인 서비스 또는 애플리케이션으로 제공되는 소프트웨어를 통해 온갖 종류의 디바이스에서 고객과 상호 작용합니다. 또한, 소프트웨어를 사용하여 물류, 통신, 운영 등과 같은 가치 체인의 모든 부분을 혁신함으로써 운영 효율성을 향상합니다. 20세기에 실제 상품을 제조하는 기업이 산업 자동화를 통해 제품의 설계, 생산 및 전달 방법을 혁신한 것과 마찬가지로, 오늘날의 기업은 소프트웨어를 구축하고 제공하는 방법을 혁신해야 합니다. - AWS - DevOps란 무엇입니까?

기술 혁신이 기업의 차별화를 가져오고, 속도가 보장되어야 변화하는 시장에서 앞서 나가고, 곧 돈을 만들어낸다는 연결고리가 만들지는 것도 '문화'의 일부일 것으로 보인다.

🪑 좌담회를 다녀와서

월요일이라 그런지, 좌담회가 길어져서 그런지 아쉽게도 그날은 뒷풀이할 분위기는 아니였던것 같아 아쉬웠지만, 이런저런 현실적인 이야기들을 들을 수 있어 좋았다. 아쉬운건 DevOps Korea 공간이 더 널리 퍼지지 못했다는 아쉬움도 있다. 주변에 젊은(?) 엔지니어 분들은 요샌 커뮤니티 활동도 거의 안하는듯 한데, 어떻게 하면 이런 모임에서 같이 생각을 나눌 수 있을지 고민이다.

서버 없이, 개발 없이 필요한 대시보드와 데이터 스토어를 만들어나가는 이야기와, Kubernetes를 검토하다가 '왜'에대한 물음을 다시금 던지면서 보류했다고 하는 이야기를 들으면서, 어느때보다 도구가 넘쳐나는 때에 어떤 것이 요구사항의 만족에 적합한지에 대해 한번더 생각해봐야할 필요가 있다고 생각되었다.

Google Looker를 사용하면 굳이 개발안해도 적절한 대시보드를 얻을 수 있다.

DevOps는 진행중이고, XXOps를 뒷받침하는 Engineering 영역과 이를 뒷받침하는 역량도 끊임 없이 배움과 확장의 연속 '그만 배우고 싶다...놀고 싶다...그럼 더 배워야 하나?'

📋 별첨 - Nomad Case Study (Game)

게임 산업쪽 이야기가 많이 나온김에, 이전에 WEB/WAS, 게임 서버 개발, OpenShift 때문에 Kubernetes(K8s)를 반강제적으로 학습 해보면서 범용적인 오케스트레이션 툴은 없나 찾다 지금의 일을 하게 된 일이 다시금 생각났다. 모든걸 만족할 수는 없겠지만, 다양한 분야의 다양한 사람들의 애플리케이션 실행 요구사항을 만족할만한게 있으면 좋겠다고 생각했다. 여전히 Windows만의 강점이 있고, 누군가는 웹앱이 중요하고, Java 앱이, Python이, 또 누군가는 빌드된 바이너리를 실행해야 하는 등, 그래서 난 Nomad의 장점을 느꼈다고 생각된다. Terraform도 모르고 Vault도 몰랐지만 어디에나 잘 실행되고, 쉽고, 아무거나 올려도 되는 유들유들한 오케스트레이터. (K8s가 워낙 유명해서 잘 안알려졌다는게 단점이랄까.) Nomad를 사용하는 사례들을 보면 현실적인 이야기들이라 더 그정도까지의 플랫폼은 필요 없거나 아직 컨테이너까지 안해도 되는, 그리고 Windows, ARM Cpu를 사용하는 사례들을 만난다. 특히나 게임 이야기는 더 재미있고 즐겁다.