인프라를 지망하게 된 계기 (Kubernetes & Golang 관련 계획) + 뻘글

일단 굉장히 자유로운 형식으로 일기마냥 글을 썻습니다.

기존 포스팅이랑 다르게 문체가 다소 산만할 수 있습니다. (다듬을 예정)

Wendy-Nam에게는 꿈이 있다

 

 

 

사실 인프라 쪽을 지망하게 되기까지 뭔가 많은 일이 있었는데...

이것저것 해보다보니까 나는 좀더 효율성을 중요시하면서, 사용자 서비스랑 연관되는 분야가 꽤 좋다고 느꼇다.

 

그래서 누가 시키지도 않았는데 졸업용 산학 프로젝트 이런데에서 모바일앱 배포 CI/CD 이런걸 fastlane으로 구축한다거나 등등...

다른 일을 다 하고도, 추가적으로 스스로 움직이게 되는 게 결국 그런 분야였다.

기존에 시스템/네트워크 쪽으로 활동경험이 더 많았기도 하고.

---

단순 구현 쪽은 좀 아쉬웠다.

 

사실 구현 쪽은 오히려 좀 안 맞는 느낌이었다.

 

재미는 있었다. 나는 관심이나 피드백을 아주 좋아하다보니까 특히 그랬다. 개발자 도구부터 뭔가 시각적인 요소가 들어가거나 아니면 사용성이 있을만한 분야를 파니까 흥미롭고 나름 열정이 생겼다. 다만 시간이나 비용적 제약이 있는 상황에서 결과를 만드는 거에 급급하게 움직이다보니, 막상 돌이켜보면 어떻게 구현했는 지 좀 기억이 어설프다.

 

예비창업이나 따로 학교 프로젝트, 산학 프로젝트 등등 내 이해관계를 넘어 집단이나 더 큰 목표가 있을 경우가 많았으니, 그때는 구현이 우선이지 내 지식을 쌓는 게 목적이 되어서는 안 됐다. 효율성보다는 일단 보이는 결과가 중요시 될 때도 많았다.

그래서 더 정신없이 움직였다. 어떻게든 뭔가를 만들어내려고.

'허둥지둥'이라는 말이 딱 맞았다.

 

당연히 그때도 내가 맡은 부분에서는 깊은 기술적 문제가 없게끔 최대한 많은 부분을 고려했다.

나는 여러모로 불안이 좀 많은 성격이라 리스크를 굉장히 예민하게 캐치하고 관리하기 때문이다.

그러나 돌이켜보면 스스로만큼은 그 퀄리티가 만족스럽지 않다. 당시엔 나름대로 최선을 다해 다듬은 코드라고는 해도 말이다.

당연히 내 지식에 전 만큼의 깊이도 없다. 물론 난 인수인계를 철저하게 하는 것만큼은 스스로 큰 원칙으로 삼고 있기에, 당시 내가 쓴 리드미나 인수인계 문서를 보면 다시 되살아나는 기억들이 좀 있기는 하지만 말이다.

 

그래도 이 질문만큼은 대답이 안된다.

1. '해당 제품이나 프로젝트에서 모든 기술적 책임을 다 질만큼의 능력이 되냐?'

2. '예상치 못한 이슈에, 1년도 안된 내가 해당 분야 미들/시니어급의 이슈를 커버할 수 있나? 아니면 최소한 미리 파악이라도 되나?'

-> 당연히 아니다.

-> 리스크를 대비하고 대비가 완벽해지려면, 경험과 함께 공부에 오랫동안 매진해야한다.

-> 그러면 정작 제일 중요한 당장의 구현은 밀린다. 

 

나는 어설픈걸 별로 안좋아한다. 확실하게 짚고 넘어가는 게 더 편하다.

내가 구현한 모든 부분에 대해, 내가 어떤 문제나 이슈나 아니면 확장 시의 이슈라도 전부 책임질 수 있을만큼 그 모든 걸 이해하고 싶다.

깊이가 없는 구현으로 껍데기만 만들어서 모래성을 쌓고 싶지는 않다. 

 

나 또는 팀이 만든 어떤 효율적인 표준을 기반으로, 뭔가 지속적인 확장이나 개선이 이뤄질 수 있으면 더 좋겠다.

이런 생각을 해오곤 했다.

 

그런데 내가 기획이나 그런 목적 면에서 프로젝트를 맡거나 팀을 리딩하면, '기술을 쌓자'는 나 하나의 욕심으로 결과물 자체를 양보할 수는 없게 되었다. 공부는 그 과정에서 따라오길 바라야 한다. 

당연히 우선순위는 팀의 결과물이여야한다. 나 혼자 이기적으로 굴 수는 없다.

회사가 아니라 사적인 프로젝트들이었다보니 더욱 여유가 없었고, 배울 기회도 갈수록 제한적이었다.

 

개인플젝용 팀이니 시니어가 잘 없던 적이 많아 스스로의 기술은 갈고 닦을 기회가 줄었다.

(시니어가 있으면 그래도 그 과정에서, 어께너머 보고 배우는 거라도 생긴다)

---

인프라 분야가 적성에 맞는 듯 하다

 

당장 시스템/네트워크 석박사를 하기엔 목표가 애매했다.

동시에 서비스나 그런 지속적인 사용성이 생기는 분야를 좀더 효율적인 시스템 면에서 커버할 수 있으면 좋겠다고 오랫동안 생각했다. 돌이켜보니 이게 인프라/데브옵스 분야라하고, 마침 이전에 시스템/네트워크 쪽에서 쓰던 리눅스 관련 커멘드, 쉘스크립트, 테스트 자동화, 도커, golang 등등이랑 겹치는 편이었다. 

 

이거다 싶어서 졸업 직후에 글로벌 해커톤을 나갔다. (2~4월)

실은 취미로 해외커뮤 디코서버 이런데 넘나들며 외국애들이랑 종종 게임잼을 해봤다보니, '이런거 분명 일반 개발분야에도 있을거같은데' 라는 확신이 들었다. 그래서 찾아봤다. 내가 원하는 플랫폼이 딱 있었다. 그렇게 거기 사이트를 탐방하며 외국인들한테 연락도 넣고 같이 팀업을 해서 마이크로소프트 azure 관련 대회를 나갔다. 상도 탔다. (오예)

 

해보니깐 클라우드도 그냥 앱을 올리는 것에서 끝나지 않고 은근히 배울 점도 많고 맘에 들었다.

시니어인 팀원들이 있어서 설계나 방법론, 그리고 새로운 프레임워크들에 대해서는 보게 되는 내용이 좀 새로웠다. 간단한 논의나 설계 관련 대화를 나눌 때도, c4 다이어그램이나 뭔가 이거저거 전문적인 프로세스를 엿보게 된다해야하나. 뭔가 신기했다. 

 

문익점씨가 목화씨를 훔치듯, 나는 시니어가 업무를 하는 방식을 어께너머로 은근히 훔쳐보게 되었다.

솔직히 테라폼은 시니어가 한번 이름만 알려준 건데도, 직접 써보니까 거의 신세계였고 말이다.

포탈에서 하나하나 딸깍이며 고생하던 작업이 싹 자동화된다니 말도 안된다. 진짜 눈물이 났다.

 

심지어 시니어는 보통 7~10년차다. 그럼 말할 것도 없이 무조건 충성해야한다.

시니어 말을 잘 들으면 자다가도 떡이 생기는 걸 경험해보니 그럴 수 밖에 없다.

(이 말을 전했더니 그분이 엄청 웃으시더라)

 

하여간 그분들의 방식에 대해 검색해볼수록 새로운 내용 투성이다. 

아주 솔직하게 말하자면, 어께너머로 알게 된 지식을 좀더 찾아보거나, 프로젝트의 기획적인 설계를 '기술적으로' 다듬는 데에는 gpt 도움을 좀 받기도 했다. 사실 iot 이미 해봤던 거고, 심지어 4학년 때는 해당 과목 aws iot 포함해 실습조교까지 했어서 이미 어느정도 설계는 머릿속에 있었는데 그래도 그럴듯한 형태로 다듬거나, 방법론적으로 각 역할 별 구현 task를 파악하고 나누는 건 다른 얘기였기 때문이다.

 

게다가 단순히 프론트-서버 배포를 넘어 라우팅이나 내부 서비스 설계, 리소스 구성 등 클라우드에서도 여러 내용들이 많이 새로웠다. 사실 나름대로 진로를 찾는답시고 이거저거 많이 찍어먹어 본 편인데, 재학 중에는 '이거다' 싶은 분야가 잘 없어서 고민이었는데 말이다. 이제 나름대로 적성이 느껴지는 분야를 찾았으니 더 준비를 해야겠다고 생각했다.

---

 

아직도 배울 게 산더미 (feat. 쿠버네티스 , golang - 복습)

 

그렇지만 회사 차원의 인프라에서는 당연히 쿠버네티스가 단골 소재다.

일단 인프라에 온 순간 무조건 배워야하는 관문과도 같다고 생각한다.

 

게다가 아직 기본기도 좀 허술하다는 생각이 들어서 자괴감이 들지만, 최대한 빨리 배워야 할 것이다.

동시에 배운 점을 착실하게 블로그나 노션 등에 정리해서 더 제대로/확실하게 익힐 수 있도록 해야겠다.

 

실은 golang을 2022년에 주로 썻으니 안쓴 지 벌써 3년이다. 

예전에 정말 열심히 공부했던 거랑 별개로 안 쓰니까 꽤 많이 까먹게 됐다. 그래도 이 분야 또는 k8s 관련 핵심 프로그래밍 언어인 만큼, 이젠 다시 연습을 좀 해야한다고 느낀다.

 

일단 인프런에 쿠버네티스 강좌도 좀 사뒀고, 유튜브로 좀 이거저거 개념들을 감이 잡히게끔 알아보는 것 먼저 해보고 있었다.

이제 실습 관련 강의를 위주로 빠르게 정주행해보려는 계획이 있다.

 

---

Operator Pattern?

 

요즘은 어쩌다보니 operator-pattern이라는 것도 알아보게 됐는데,

좀더 공부해보고 내용이 얼추 맞다싶으면 학습용 짤 만화 이런것도 그려보고 싶은 생각이 있다. 

 

대략 아래 같은 느낌으로 말이다.

 

 

 

일단 내가 이해한 내용을 기준으로 간단히 말하자면,

k8s라는 시스템에는 controller라는 '퉁퉁퉁사후르'가 존재한다. 

 

이놈은 교도관 같은 역할의 지독한 감시관 녀석인데, deployment라는 이름의 규율서를 맹신하는 아주 무서운 놈이다.

그래서 pod라는 생활관 입주민들이 규칙이랑 다른 짓을 하면, 또는 다른 상태가 되면, 갑자기 쫒아 와서는 'reconcile (화해)'이라는 몽둥이로 뚜들겨서 '교정' 치료를 한다.  pod 들이 계속 같은 상태로 유지되게끔 하고, 중간에 일이 잘못되도 controller 교도관이 계속 걔네를 교정시켜서 작업을 돌리게 된다. 

reconcile에 대한 내 뇌피셜 이미지 / controller는 말벌아저씨 or 퉁퉁퉁사후르?

 

 

그런데 이렇게만 하기엔 과정이 번거롭거나 제약사항이 생길 때가 있다.

이때는 특별히 특수 입소자(커스텀 리소스) 타입을 새로 정의(CRD)하고, 관문(API server)에 요청해서 걔네를 들여보내도록 하는 방법이 있는데, 동시에 그 친구들만을 위한 '퉁퉁퉁 사후르' 특수요원 버전(Operator)을 같이 투입하면 좀더 특수한 기준으로 동작하게 할 수 있다. 이 특수요원들은 새로운 규율수첩을 들고 다니는데, 거기엔 요원의 행동강령 또는 감시 규칙들이 client-go라는 언어로 적혀있다.

 

하여튼 이 놈들은 무서운 녀석들이다!!!

 

... 이걸 좀 이해하려고 노력했었다.

그렇지만 아직 개념이 정확하지 않다고 생각한다. 말그대로 '얼추' 넘겨짚는 수준.

 

controller라는 뭐시기가 있는데 걔가 뭔가를 수행하고 ~ 

<< 이런 식으로 이해하려니까 감이 영 안잡혀서, 좀 고민이었는데

여기서 뭔가 이미지를 붙여보니 얼추 맞고 재미가 있었다.

딱 맞아떨어지는 것이 맥락이나 인과관계를 붙여서 이해하는 데 도움이 됐다.

 

그래서 나름 스토리는 다 써져 있는데, 내가 오개념을 퍼트리고 싶지는 않아서 아직 안 그렸다.

나중에 이해가 좀더 완전해지거나 내 이해가 틀린 게 없는 지 검토를 해줄 사람이 생기면 그때 낙서만화 같은 느낌으로 그릴 것이다.

 

나는 여전히 부족하지만, 지금처럼 계속 배우고, 기록하고, 나만의 이해를 쌓아가고 싶다