【지향 해야하는 엔지니어링 방향성】 부제: 기형적인 요즘 기업의 행보들

개요

추상적인 제목에 비해서 내용이 명확한 글이다 보니 미리 TL;DR을 적어보자면 아래와 같다.

DevOps, Site Reliability, Infra, Cloud, Platform, System Engineer들은 근무를 하다보면 상당한 레거시를 겪게 되지만 이게 현실 인프라 라는 이유로 변화나 혁신을 주도하는 새로운 인물을 배척해서는 안된다.

이 주제가 궁금하다면 글을 읽어보아도 좋을 것 같다.

 

생각의 근원지

이 생각을 하게된 이유는 그렇게 거창하지 않다.

 

최근 근무하고 있는 회사의 동료분이 밥을 먹다가 재밌는 제안을 먼저 해주셨다.

'혹시 현업 DevOps Engineer의 조언이 필요한 학생들이 있는데 조언을 해줄 수 있나요?'

별 부담없던 나는 흔쾌히 수락했다.

 

사실 어렵지 않은 제안이였고, 그냥 졸업 프로젝트를 보며 느낀점이나 먼저 준비해준 질문지에 답을해주고 내 견해나 생각 등을 통해 정보를 전달해주면되는 정도의 내용이였다.

 

제안해주신분, 그리고 그 학생분들 모두 부담스러울 정도로 감사를 표하셔서 당황하긴 했지만 말이다 ㅋㅋㅋ

 

근데 여기서 사소한 문제가 있었다.

나는 일반적인 대학에 다녀본적이 없고, 그분들은 현재 졸업을 앞둔 분들이였다.

실업계 출신인 나로써 사회에 빨리 나온 것 외에 공통점도 없고 내가 조언? 멘토링? 같은걸 해줄 수 있는 위치인지도 모르겠다는 생각이 스쳐지나갔다.

 

물론 티를 내지 않고 문자를 통해 최대한 정중하고 사회인 답게(?) 회신을 했다.

 

결국 구글 밋을 통해 잠시 1시간 정도 시간을 내어서 대화하기로 했다.

 

기대하던 만남

결국 구글밋으로 대화를 해보았다.

주제는 내가 만든 프로젝트가 아닌 만큼 여기서 다루지는 않겠다.

 

솔직히 나는 객관적인 평가를 했을때 상당히 좋은 프로젝트라고 생각했다.

그러다가 받은 질문이 이 글을 쓰게 만들었다.

간단히 요약하면

DevOps Engineer로 근무하고 있는 입장에서 현실적으로 저희 프로젝트를 사용하실 것 같나요?

 

너무나 아픈 질문일 수도 있고 너무 반가운 질문일 수도 있는 질문이였다.

크게 대답을 망설이지는 않았다.

 

"~~이 부분이 해결이 된다면 이런 프로젝트는 너무 환영이죠!"

진심이였다.

 

그리고 동시에 대한민국에서 발생하고 있는 레거시가 쌓인 현실적인 인프라에 대해서도 이야기해주었다.

그렇기에 특정 부분을 해결해야지 많은 기업에서 사용할 것 같다는 현실적인 조언까지도 해주었다.

 

예를 들면 LGTM 스택을 사용하면 OSS 생태계에 기여 + 상당수의 기업이 사용하는 스택이라는 점에서 두가지 장점을 가져갈 수 있어서 추천하기도 했다.

 

어째서일까 그런 레거시가 있는 기업들이 많다는 조언들을 하면서 과거에 내가 했던 말들과 생각들이 기억이 났다.

뭔가 정말 엔지니어로서 어디서 왔는지 알 수 없는 수치심과 부끄러움이 밀려왔기 때문이다.

 

결국 구글 밋을 마치고 생각들을 정리하고 나서 글을 적어본다.

과거의 나

나는 뭐든지 할 수 있을 것 같았다.

영재 소리를 매일 들어왔고, 주변에서 '넌 꼭 성공할거야' 라는 말을 들어와서일까 자아가 참 비대했다.

(그렇다고 지금 못난단건 아니고, 그런 비관적인 사람 아닙니다...ㅋㅋㅋㅋㅋ)

 

그리고 그런 비대했던 자아에 BP를 기반으로 운영되는 클라우드컴퓨팅 대회까지 겹치게 되니 머릿속에 나는 내가 하는 모든 엔지니어링이 모두의 귀감이 되는 정석이고 모든 걸 해내는 슈퍼 엔지니어가 되어 있었다.

 

이후 파란색 대기업 그룹사에 입사할때도 면접에서 당당하게 레거시를 뜯어고치겠다는 말을 했다.

사실 지금 생각하면 귀엽기도하고 동시에 좋은 의미에서 배짱 좋았다고도 생각한다.

결국 그걸 그곳에서 해냈느냐? 전혀 못했다 ㅋㅋㅋ

난 남을 기술로 설득할 수 있는 능력도 없었고 레거시 인프라에 이리 치이고 저리 치이면서 체념해갔던 것 같다.

 

어느순간 마음속에선 BP만을 지향하며 대회에 임하고 그렇게 만드리라 생각했던 포부는 줄어들었다.

그리고 그 자리에 '현업에선 이런거야 ㅋㅋ 현실적으로 이래;;' 같은 마음이 올라왔다.

 

그렇게 시간이 지난 뒤

현재 스타트업만 3군데를 다니고 대기업 1곳을 다니며 여러 컨퍼런스를 방문하여 커뮤니케이션하다보니 알게된 점이 있다.

 

어떤 회사에서는 레거시를 걷어내기 위해서 여러가지를 제안하면 모두 효율성, 비용 두가지를 들먹이며 레거시에서 현대적인 전환을 거부하는 회사가 있었다.

 

솔직히 한번씩 겪는 일이라고 생각했다.

 

그런데? 정작 AI가 발전하니 인프라 레거시 고치는데는 돈과 시간과 사람을 안쓰던 그런 문화가 갑자기 AI에는 매몰비용 발생해도 되고 토큰을 많이 쓸 수록 칭찬해주면서 사람은 줄여나가는 기형적인 행보를 보이기 시작했다.

 

AI가 있으니 인프라도 다 자동으로 운영하고 FinOps를 통해 비용절감도 해야한다고 한다.

이게 특정 회사에만 해당되는게 아니라 전반적인 스타트업과 대기업들의 문화가 이렇게 정착하던 시기였다.

 

당연히 그렇게 잘한 회사들도 많았다.

그런 회사들의 특징은 레거시가 레거시임을 인정하고 기술부채를 제거하는데 투자를 할 줄 아는 회사였다.

 

개발자가 인프라를 다루기 위해선 인프라를 다루던 사람이 만들어둔 IaC 코드가 있어야한다.

그냥 인프라의 지식이 하나도 없는 사람이 AI를 통해 인프라를 다루다간 정말 다양하게 서버가 죽을 수 있다.

 

인프라를 다루던 사람이 개발자의 영역을 하기 위해선? 반대로 개발과 도메인에 대한 지식이 있어야한다.

안그러면 어떤 기술부채 코드가 장애를 불러올지 모른다.

 

결국 레거시를 어떻게 대하고 있었는가에 따라서 AI시대에서 기업의 발전속도가 행 이동을 하거나 하락을 하거나 상승하는 형태가 되었다.

그 전까지 어떻게든 개발자와 인프라 엔지니어 갈아넣으면 해결되던 일들이 이제는 생산성이라는 벽에 막혀버린 것 이다.

 

그래서 현재 기업들의 모습은?

- 레거시를 치우고 싶은데 못치운 기업

- 레거시는 모르겠고 일단 계속 쌓는 기업

- 레거시를 모른척하는 기업

- 레거시를 만들지 않기 위해 노력하는 기업

- 레거시를 제거하고있는/제거한 기업

 

이 정도로 나뉜다. (물론 훨씬 많지만 얼추 교집합되는 곳이 많을 것이기에...?)

결국 레거시라는 키워드로 인해 발목을 잡히느냐, 그냥 달려나가느냐에 달린 것이다.

 

그래서일까? 새로운 사람을 뽑을때 대부분 '레거시를 제거하겠다, 인프라를 바꾸겠다.' 같은 포부를 오히려

'아직 쟤는 이걸 몰라서 그래' 같은 조금은 배타적인 태도를 취하는 사람들이 많아진 것 같다.

하지만 그렇게 배타적인 태도로 임한 결과가 그 레거시라는 점을 생각해본다면 정말 해서는 안되는 행동이다.

 

AI시대에 인당 생산이 늘어난 시대에서 자신이 가진 기술이 그들보다 나을 것이란 자신을 하는 것 자체가 상당히 오만한 생각이다.

경험과 방향성은 넘볼 수 없겠지만 그런 올바른 방향성을 제시했던 사람이라면....애초에 이런 글에서 반박 대상이 되지 않는다.

이미 고치고 있거나 고쳤거나, 배타적이지 않거나 이런 긍정적인 방향으로 나아가고 있을 것이기 때문이다.

결국

결국 인프라든 개발이든 모두 레거시를 제거하겠다고 오는 사람을 이제는 더 이상 배타적인 태도로 임하는 것은 구시대적인 생각이 된 세상이다.

 

레거시를 고치겠다는 사람을 믿는 태도와 맡길만한 사람을 찾고 그만한 권한과 책임을 위임할 대상을 선택하는 것 또한 Leader와 Boss의 역량이다.

 

그렇지 못한다면 평생 레거시 속에서 SRE, DevOps 뭐 이런 인프라 관련된 직무를 뽑아놓고 운영 발사대로 쓰면서 그 사람이 퇴사하면 새로운 사람을 찾고 하는 요즘 시대에서 말도 안되는 기업 운영 방식을 유지해야한다.

 

나는 어떻게 임할까?

난 사실 어렵게 생각하지 않는다.

 

대부분 운영단에서 발생하는 레거시는 먼저 보고 결정해야한다.

보기 위해선 시각화가 필요하고 데이터가 필요하다.

 

Data-Driven 의사결정이 괜히 튀어나온 말이 아니다.

https://toss.im/career/article/data_first_ai_native

Data First, 그리고 AI Native : 지금 토스가 일하는 방식

 

그 뛰어난 토스마저도 Data를 가장 중요하게 생각한다.

 

본인들의 레거시가 어디까지고 어떤 레거시가 있는지를 찾는 것 부터가 시작이라고 생각한다.

 

어떻게 보아야 할까? 한다면 당장 AI한테 '옵...져버...빌리티...툴...추천....' 검색하면 정말 많은걸 추천해준다.

LGTM, Datadog, Prometheus & Thanos, ELK, 와탭 등등 

어떤 툴이든 상관없다. 1년 아니 한달이라도 데이터를 모으며 현 상태를 지켜보는게 중요하다.

 

우리 트래픽은 언제 어디서 왜 튀고 어디에 병목이 있고 어떤 서비스가 얼마나 리소스를 먹고있고 등을 봐야한다는 이야기이다.

 

이후에 점진적으로 어떻게 어떤 시간에 서버를 개선해서 롤링하고 어떤 작업을 할지 결정하면 된다.

하다 못해 서버의 크기를 조정하여 비용이라도 줄일 수 있다.

 

그 다음에 DevOps철학과 SRE 기법을 공부해야한다.

어떤 회사가 되었든 어떤 환경이든 자신이 사용하는 기술에는 철학이 있다.

자신의 인프라가 기술부채라면 그 철학에 위배되는 구성을 했거나 자신 도메인과 맞지 않는 스택을 선택했을 가능성이 높다.

 

DevOps에서 이야기하는 철학 그리고 국내에서 DevOps로서 뛰어난 실력과 영향력을 행사한 송주영 연구위원이 이야기하는 DevOps 철학은 5가지가 있다.

• 문화 (Culture): 개발팀과 운영팀이 고립된 상태(사일로)에서 벗어나, 목표와 책임을 공유하는 협업 중심의 일하는 방식
• 자동화 (Automation): 반복적이고 수동으로 하던 빌드, 테스트, 배포 과정을 자동화하여 속도와 안정성을 향상
• 측정 (Measurement): 시스템 성능과 프로세스 지표를 수집하고 분석하여 문제점을 예측하고 개선
• 공유(Sharing): 팀 간의 지식, 피드백, 데이터를 투명하게 나누며 함께 성장하는 환경을 구성
• 축적 (Accumulation): 업무를 하며 얻은 성공과 실패의 경험 및 결과물을 지속적으로 쌓아 다음 단계의 자산으로 활용

사실 이 5가지를 잘 지키기만해도 레거시를 잘 치울 수 있고 레거시가 생겨나지도 않는다.

 

그리고 여기서 더 나아가 K8S에서 정말 기초적인 3요소인 Immutable, Declarative, Self healing부터 SLI, SLO, SLA 그리고 Error Budget, Toil제거 같은 다양한 현업에서 나올만한 요소를 섞어서 만들어둔 엔지니어링 철학과 기법이 참 많다.

그리고 그 기법들은 모두 경험에서 나온 것이고, 모두가 적용할 수 있는 요소이다.

 

평생 레거시로 있을 것인지 그 철학을 기반으로 밑바닥을 재설계할 것인지는 본인의 몫이다.

꼭 리더가 아니더라도 꼭 Boss가 아니더라도 엔지니어도 그런 생각을 해야한다.

 

결국 현실을 타협하며 레거시를 쌓는게 아니라 현실속에서 레거시를 제거해 나가는 것이 중요하다.

 

어떤 장애속에서도, 어떤 배포속에서도, 어떤 생산성의 특이점에서도 절대 무너지지 않는 견고하지만 동시에 정말 탄력적인 구조로 만드는 것이 중요하다.

 

내가 적어둔 내용이 환상같고 너무 BP만 추구하는 것 같다면 글을 잘 본 것이 맞다.

내가 만진 인프라들이 BP라고 절대 생각하지 않는다.

내가 구성한 인프라들이 BP라고도 절대 생각하지도 않는다.

 

하지만 적어도 바라보고 만드는 방향 자체는 BP로 만들어야 한다는 것 이다.

 

얼추 고쳐놨으니 이제 슬슬 밀린 다른거 하죠?

 

같은 안일한 태도로 레거시를 방임하고 놓치다보면 결국 화살이 돌아오게 된다.

 

다음 글

다음 글은 맨 처음에 봐야한다고 적은 만큼 SRE와 관련된 엔지니어링 기법에서 일부를 가져와 SLO, SLI, SLA를 조금 더 기술적으로 풀어볼 예정이다.