이 글의 원본 포스트에 대하여
우선 이 글은 원본 포스트가 있다. 이 원본 포스트를 읽은 후에 일을 처리하는 방식이 어떻게 돌아가는지, 그리고 얼마나 약삭빠르게 돌아가는지 관찰하고 비교하는 것도 재미가 있는 부분이다.
계속해서 반복되는 추상적인 이야기들
일단, 최근의 개발 방법론들에 대한 언급을 보면 계속해서 추상적이고 갈피가 안 잡히는 이야기들이 넘쳐난다. 실효성 여부와 무관하게, 이것들은 문장 자체가 순수하게 이해하기 어렵기 때문에 마치 승정원일기의 필기체를 정갈한 현대 한국어로 다시 적는 것과 같은 고역을 치러야 반 정도 이해가 될 듯 말 듯하다.
DevOps란?
인테그로 테크놀로지스의 수석 DevOps 엔지니어인 ‘데니스 튜멘체프’는 DevOps는 ‘왜’에 대한 질문이고, SRE는 ‘어떻게’ 신뢰성을 보장할 것인가, 플랫폼 엔지니어링은 그것을 확장해 모두가 쉽게 사용할 수 있도록 만드는 방법이라고 언급했다. 이 3단의 논리에서 핵심을 추출해 보자.
- 1단: 왜
- 2단: 어떻게
- 3단: 그것을 확장해 모두가 쉽게 사용하도록
3단에서 확 이상해진다. 원래라면 왜->어떻게->무엇을->누가->언제->어디서를 알려줘야 하는데, 책임을 회피하는 듯 ‘그것을 확장해 모두가 쉽게 쓰게 한다’는 슬로건이 튀어나온다.
결국에는 이런 관리직들의 추상화된 언어에 대해서 ‘초서를 해서로 옮기는 작업’이 되고 나서야 ‘현대어’로 옮길 수나 있는 것이다.
분리해서 보면, 3단은 다시 4단 논법으로 나뉜다.
3단: 배포와 관리에 대한 감사를 4단: 관리자와 개발자 모두 5단: 작은 스프린트 단위 안에서 6단: 클라우드 및 협업 환경에서 진행한다.
결국 이것을 ‘노동자의 언어’로 쉽고 단순하게 풀어 보면 별로 어려운 개념도 아닌데, DevOps는 어렵고 똑똑한 사람들의 것이라고 생각하게 되는 것이다.
SRE란?
SRE에 대해서 코히어런트 솔루션즈의 ‘알렉산더 시모노프’는 신뢰성, 서비스 수준 지표, 서비스 수준 목표, 인시던트 대응, 에러 예산 등이 주요 개념이며, 운영을 엔지니어링적으로 바라보는 것이라고 언급했다. 그리고 프로그레스 소프트웨어어의 ‘프라샨스 난준다파’는 더 이상 불이 꺼지지 않게 유지하는 것을 넘어서 장애가 발생하더라도 우아하게 복구할 수 있는 소프트웨어를 구축하는 데 목표를 두게 됐다고 언급했다.
달리 말해서 SRE라는 것은 자동화하기 난해하고 엔지니어링이 필요한 복잡한 운영 상황에 대해서, 마치 소프트웨어의 ‘우아한 재시작, 자원 회수’같은 감각을 가져 오겠다는 소리로 들린다. 그러나 에러 예산을 집행한다던가, 인시던트 대응 시스템을 개발하겠다던가 하는 SRE의 접근이 절대적으로 옳은지는 비판적으로 사고할 필요가 있다.
예를 들어서 당신의 부서에서 보수하는 소프트웨어가 1000만 LOC이고, 장애 대응 시스템을 고도화하기 위해서 대략적으로 10만 LOC의 꽤 응집도 높은 코드를 작성했고, 장애 대응 전담 부서를 임직원 5000명 중에 20명 차출했다. 이러한 경우에는 전체 코드 베이스는 크지만, 10만 LOC의 가벼운 시스템만으로 상당한 부분의 자동화 및 인간 관리자로의 보고가 이루어진다면 가성비가 좋으니 SRE를 위한 전담 부서를 꾸려도 되겠다.
그러나 코드의 규모는 300만 LOC, 장애 대응 시스템이 30만 LOC이 필요하며, 원래 소프트웨어와 고도화 부분 모두 응집도가 높으며, 오히려 추가된 고도화 시스템에 대한 코드 유지 보수 지출이 추가 발생하고, 직원들의 내부 평가도 썩 좋지 못하다면 유지해야 할 까닭은 없을 것이다. 이러한 예외 상황을 기민하게 설정하고 현장의 말을 듣기 전까지는, SRE처럼 거대한 개념은 도입하기 전에 신중해야 하는 것이 당연한 것이다.
플랫폼 엔지니어링이란?
이것은 앞서 말한 관리직, 자본가들의 말을 인용할 필요도 없다. 즉 팀이 사용하는 내부 플랫폼과 프레임워크의 재사용성을 끌어 올려서, 바퀴를 재발명하는 일을 줄이겠다는 소리다. 이것에 대해서는 ‘내부에서 쓰겠다는 까닭으로 소프트웨어를 대충 짜서’ 생긴 문제를 적당한 용어로 감싼 듯한 느낌이 조금은 있다. 그러나, 플랫폼 엔지니어링도 모르겠고 ‘GOD 클래스’와 한 파일에 30000 LOC짜리 소스를 짜서 대충 유지하겠다는 것보다야, 용어라도 만들어서 효율적으로 일할 수 있으면 낫다.
정리
상징적이고 철학적인 운동을 다 빼고 실무에서 벌어지는 대로만 요약하겠다.
- DevOps: 너희는 이렇게 협업해야만 한다고 강제하는 협업 규율
- SRE: 고가용성 유지를 위해서 소프트웨어를 고도화하라
- 플랫폼 엔지니어링: 처음부터 재사용성, 개발 편의성 등을 고려해서 잘 다듬어서 코딩해라
이것 말고 달리 할 말이 있는가? 굳이 토를 달자면 코딩과 프로그래밍과 개발과 엔지니어링은 모두 다르고, 이런 관점은 어디까지나 코더의 관점이라고 비판할 수도 있겠지만 눈 앞에 놓여진 명시적인 사실에 대해 서술하면 누구도 다를 바 없이 서술할 것이라고 확신한다.
결론
- 결국에는 조직 관리 편의성을 위한 방법론이다
- 소프트웨어 운동이라기보단 여전히 관리자의 철학이다
- 조직의 평준화된 목표를 위해 기법은 꾸준히 발전한다
- 방법론을 공부하면 ‘적당히 봐 줄 만한’ 엔지니어로 살아남는 데에 도움이 된다
- 방법론은 메타적이고, 체득은 생존의 문제이다
달리 말할 것은 없다. 경험을 해 보면서 내가 느낀 바는 이것이다.