DevOps 엔지니어로서의 첫 3개월; 2024년 2분기 회고

첫 회고 #

결론부터 말하자면, 나는 지난 3개월동안 정말 먹고 자는 시간을 제외하고, 거의 대부분을 컴퓨터 앞에만 앉아있었다고 자신할 수 있다. 하지만, 그 시간들 모두가 즐거웠다.

사실 이번 회고가 내 첫 회고이다. 고등학교 때부터 일기를 매일 써오고, 옵시디언에 마크다운으로 업무 일지도 하루 간격으로 남기고 있지만, 이렇게 본격적으로 내 자신을 뒤돌아보는 시간을 가졌던 적은 많지 않았던 것 같다. 물론 이 또한 기록의 의미가 더 크다.

개발자 인턴, 창업팀을 거치고, 다시 작년에 대학교로 돌아왔다. 대학교에서, 대학생, 연구실 인턴 신분에 머물러있다가 다시 3월부터 본격적으로 새로운 직장에서 일하게 되었기 때문에, 아무래도 이번 회고에는 아무래도 적을 컨텐츠가 넘쳐난다. 이번 글에서 언급한 것 이외에도 분명 많은 일이 있었지만, 회고 자체에 너무 많은 힘을 들이면, 지속해서 적기 힘들 것 같아서, 일단은 이정도로 만족하고자 한다.

DevOps 엔지니어로서의 첫 3개월 #

나는 내 스스로 DevOps 엔지니어라는 포지션을 꽤 오랫동안 꿈꿔왔다. 대학교에 들어와서 처음으로 개발을 배우고, 프론트엔드로 시작했다가 백엔드로 넘어가며 굉장히 잡다하게 많은 기술 스택을 접해왔다 ~~(아무래도 새로운 언어와 프레임워크를 쓰는 게 취미인 것도 한몫했겠지만)~~. 그리고, 개발을 하면 할수록 1) 네트워크 및 분산 시스템과 2) 인프라에 흥미를 느꼈다. 더 나아가, 과분하지만 창업팀에서 테크리드라는 자리에 있으면서, CI/CD 파이프라인 및 인프라 구성에 집중하면서 자연스레 DevOps 라는 단어에 관심을 가지게 된 것 같다.

올해 초에는 산업기능요원 복무를 위해서 일자리를 찾고 있었다. 하지만, DevOps 엔지니어는 업무 특성상 많은 노하우와 경험을 요했고, 해당 포지션을 소화하기에는 현업 경험은 부족하다는 것이 내 판단이었다. 그럼에도 불구하고, 최소 2년 동안에 내가 몸담을 회사에서 내가 진심으로 즐겁게 몰입할 수 있는 일을 하고 싶다는 욕망이 더욱 컸던 것 같다. 그렇게 나는 백엔드 엔지니어로 지원할지 DevOps 엔지니어로 구직을 할지도 굉장히 오랜기간 고민했었다.

수많은 고민을 거듭한 이후에 3월 4일, 나는 채널톡이라는 멋있는 회사에 DevOps 엔지니어로 첫 출근을 할 수 있게 되었다. 채널톡에 입사하게 된 여정에 대해서는 이 글에서는 자세히 다루지 않는다. 왜냐하면, 말 그대로 이 글은 3월 ~ 6월, 2분기동안 있었던 일을 뒤돌아보는 글이기 때문이다.

일들을 진행하면서 고민했던 점, 느꼈던 점도 굉장히 많았지만 이번 회고에서는 주로 ‘기록’을 목적으로 일단은 했던 것을 나열하는 것에 집중하고자 한다.

1) 개발 서버 세팅 및 관리 #

DevOps 팀의 대표적인 R&R 중에 하나는 당연히도 인프라 관리이다. 이중에는 Production stage를 비롯하여 개발 서버들도 포함되어 있다. 채널톡은 현재 대부분의 인프라를 EKS와 Terraform으로 관리하고 있다. 두 개 모두 단순히 사용해본 경험은 꽤 있었기에 적응하는 데에 큰 어려움은 없었다. 하지만, 실서비스 레벨에서 이를 유지/보수하는 것은 매우 진귀한 경험이었다.

개발 서버를 세팅할 때에, 단일 서버뿐만 아니라 그와 연관된 요소들이 필요한 경우들이 있다. DB라던가, 로깅이라던가, dependency가 있는 다른 서버 등이 예시가 될 수 있겠다. 프론트엔드 및 백엔드 개발자 분들이 새로운 기능 개발에 새로운 개발 환경 및 서버가 필요하다면, 이를 구성해주는 것도 DevOps 팀의 역할 중 하나였다. 그래서, 실제로 코딩하는 시간보다도 Terraform(HCL)과 K8s를 위한 Yaml을 만지는 시간이 더 많은 경우가 잦았다.

하지만, 내가 평소에 사용하지 않았던 AWS 서비스들과 혼자 개발했을 때는 생각할 필요가 없었던 비용 최적화 및 zero-downtime 관련해서도 많은 고민을 하게 되었던 즐거운 시간이었다.

2) CircleCI 및 Docker base image 최적화 #

오늘날의 여느 테크 기업들처럼, 우리 회사에서도 대부분의 서비스들은 docker container로 빌드하여 운영된다. 그리고, 우리 회사같은 경우에는 Base image를 docker.io에서 public image를 그대로 가져다 쓰기보다 직접 base image를 빌드해서 사용하고 있다.

기존 Docker base image들에서 있었던 1) 수많은 CVE 취약점들 리뷰 혹은 native machine에 비해서 docker build 속도가 느린 2) buildx(QEMU emulator)를 제거하는 등의 작업을 도맡았었다. 그 당시에 사용하고 있는 메인 CI 파이프라인인 CircleCI를 경험했고, 수많은 CVE 취약점들과 Dockerfile들을 수정하면서, 여러 다른 Linux 들의 core 라이브러리들도 공부할 수 있었다 (e.g. glibc).

3) ARC; Github Actions를 쿠버네티스 self-hosted runner로 #

Github: https://github.com/actions/actions-runner-controller

기존에는 CircleCI를 사용하고 있었지만, 이제는 Github Actions로 하나둘씩 옮겨가고자 하는 시도를 하고 있다. 그리고, 이를 진행할 때에는 Github-hosted runner가 아닌 self-hosted runner를 사용하고자 했으며, 이에 대한 리서치 및 진행을 내가 도맡아서 하게 되었다.

Github Action self-hosted runner를 쿠버네티스와의 integration을 지원하는 컨트롤러는 이미 깃헙 자체적으로 지원하고 있다. 밑에 다이어그램은 이를 사용하기 이전에 PoC하고 리서치하는 단계에서 내가 직접 그린 그림 중 하나다.

이에 대해서 리서치하는 과정에서도 K8s에서 container job을 수행하면서 1) dind 혹은 2) k8s 모드 사이에서 굉장히 많이 고민했고, privileged 컨테이너가 가지는 위험성 등에 대해서도 깊이 공부할 수 있었다. 그리고, Docker daemon 없이 container를 빌드하는 수많은 방법들에 대해서도 알아보았다. 특히, Kaniko와 관련해서 많은 시간을 쏟았는데, 이와 관련해서 리서치한 내용도 다른 글에서 소개할 수 있으면 좋겠다.

4) 사내 배포 시스템 유지보수 #

현재 채널톡에는 별도의 사내 배포 시스템이 존재한다. 그리고, 이를 DevOps 팀에서 주로 관리한다. 내가 느끼기로는 현재 우리 회사의 DevOps 팀은 플랫폼 엔지니어링도 맡고 있다고 보면 될 것 같다. (플랫폼 엔지니어링에 대해 더 궁금하다면, 카카오페이에서 해당 개념을 설명한 글을 읽어보면 좋을 것 같다 . 본래, 채널톡에서 제작한 사내 배포 시스템은 채널톡의 기술 블로그에서도 관련 내용을 읽어볼 수 있다. 오늘날 채널톡의 배포 시스템은 해당 블로그와는 살짝 다른 점이 있지만 말이다.

오늘날 사내 배포 시스템은 팀에서 만든 쿠버네티스 오퍼레이터로 운영되고 있다. 그래서, 기존의 백엔드 개발을 진행할 때 개발하던 REST API 서버와는 또 다른 쿠버네티스 오퍼레이터 코드를 보고 만지는 것도 정말 소중한 경험이었다.

주말에는 1인 개발자 #

이 뒤로는 회사 업무와는 무관한 내 개인적인 이야기이다. 물론, 지난 내용과 같이 거의 대부분이 컴퓨터 이야기다 🤓. 평일에 일과시간에 회사 업무에 충실하고, 퇴근하고 매일 30분 ~ 1시간 30분 정도 취미로 개발을 한다. 그리고, 금요일 저녁부터 주말까지는 새벽까지 개발을 하는 것이 요즘 라이프스타일이다.

내 방에 메모리 120GB짜리 쿠버네티스 클러스터 구축 #

지금 내가 살고 있는 집 방 풍경이다. LED들을 당장에 끌 방법이 없어서, 잘 때 안대가 없으면 번쩍번쩍거려서 잠에 들기 어려움을 겪을 정도다. 현재 내 홈네트워크를 구성하고 있는 컴퓨터는 1) 데스크탑 2대, 2) 맥북 에어 1대, 3) Synology NAS 1대다.

현재 내 방에 세팅해놓은 on-premise 쿠버네티스 클러스터의 스펙은 총합 CPU 48 core, Memory 120GB, Storage 16TB에 달한다.

이 거대한 클러스터를 나는 어떻게 사용하고 있을까? 그건 나중에 기회가 될 때 차차 설명해보도록 하겠다. 홈서버를 세팅하면서도 굉장히 많은 난관이 있었고, 배운 점도 많았다. 특히, 지금 사진에 보이는 컴퓨터들은 모두 다른 운영체제가 설치되어있다. 오른쪽부터 1) Ubuntu server 24.04, 2) Asahi Linux (Fedora remix), 3) Arch Linux다. 그리고, 이 각각 다른 운영체제에서 on-premise 쿠버네티스를 세팅하는 것도 굉장한 고역이었다. 홈네트워크를 구성할 때, 신발장에 있는 단자함을 다 뜯어내기도 했고, 지금 돌아보면 눈이 반쯤 돈 채로 열중했던 것 같다.

이러한 과정들은 회사에서 사내 개발 세미나에서도 발표할 수 있었고, 관련한 자료나 내용도 이후에 다른 글에서 소개할 수 있으면 좋을 것 같다.

Neovim 적응 (완) #

오랜 기간동안 Jetbrains IDE와 Visual Studio Code 2개의 IDE 사이에서 방황해왔다. 하지만, 이제 이 고민을 완전히 끝내줄 애플리케이션을 만났다. 바로 Neovim이다.

아름답지 아니한가. 이제는 단순한 터미널에서도 곧바로 개발을 진행할 수 있다. 원래도 VSCode나 Jetbrains에 extension으로 VSCodeVIM이나 IntelliJ Vim등을 설치해서 vim 자체는 꾸준히 사용해왔다. Neovim은 기존 vim보다 훨씬 더 방대한 커뮤니티와 익스텐션 등을 지원하며, 실질적인 개발환경을 vim으로 구성할 수 있게 만들어준다.

이제는 Neovim을 사용한지 두 달 정도 되었고, 업무를 함에 있어서 전혀 어려움이 없는 단계에 이르렀다. 지금까지의 경험을 토대로 간략하게 장단점을 정리하자면 다음과 같다.

Neovim 장점

메모리 사용량이 굉장히 낮다. 기존 VSCode, 특히 Jetbrains 제품에 비해서 컴퓨터 리소스 사용량이 현저히 적다. 보통 Terminal을 사용하는 것과 크게 다르지 않다.
~/.config/nvim 을 Git으로 관리하면, 어떤 환경에서든 동일한 개발환경을 구성(재연)할 수 있다. 개인적으로 가장 큰 장점이라고 생각하는 부분이다.
Neovim 플러그인 매니저(e.g. lazy.nvim)를 주축으로, 수많은 오픈소스 등을 활용해서 개발 환경 세팅에 있어서 굉장히 높은 자유도를 제공한다.

Neovim 단점

모든 것을 커스텀 할 수 있다는 것은 다른 말로 모든 것을 직접 설정해야한다는 것이다. LSP, 키맵, UI 구성 및 그 모든 것을 직접 세팅해야한다.
애초에 VIM의 상위호환이기 때문에, VIM을 다루지 못한다면, 허들이 매우 높다.
IntelliJ IDEA가 제공하는 Java를 위한 모든 편의기능을 따라잡기에는 조금 무리가 있다. 하지만, Golang, Javascript, Python 등을 다루는데에는 아무 문제가 없다.

이런 장단점들을 막론하고, 난 현재 Neovim 사용경험에 매우 만족하는 중이다. 그리고, 이런 Neovim을 소개해주고 사용법들을 가르쳐준 우리 회사 팀원 @Claud에게 감사를 표한다. 오늘날까지 세팅한 Neovim 설정들은 내 Github에 올라와있다. (https://github.com/jaehong21/neovim-config)

Hibiscus; 첫 TUI 개발 #

Github: https://github.com/jaehong21/hibiscus

Neovim과 함께 제일 많이 사용하는 툴은 lazygit이다. lazygit은 터미널에서 GUI를 바로 보여주며, 자주 사용하는 git 커맨드 등을 단축키로 바로 실행할 수 있다. 이렇게 Terminal에서 UI를 보여주고, 마우스 없이 키보드로 interaction하는 UI를 흔히 TUI(Terminal UI)라고 부르기도 한다.

lazygit을 잘 활용하던 중에, 회사에서 개발환경을 세팅하고, AWS web console을 보며 너무 불편하다는 생각을 했다 (~~늘 그랬듯이~~). 반응도 조금 느리고, 특히 여러 account들을 왔다갔다하는 것이 굉장히 번거로웠다. 그래서 그 당시에는 docker build 관련 작업이 많았어서 ECR을 view/edit하는 TUI를 직접 만들어보았다.

우리 팀의 메인 스택인 Golang을 활용해서 구성했고, Golang으로 UI를 구성하는 경험도 좀 새로웠다. 다른 TODO 들에 밀려서 아직 해당 프로젝트는 Pending 상태이기는 한데, 앞으로 꾸준히 다른 AWS 서비스들도 지원하고자 한다.

+) 프로젝트 이름이 히비스커스인 이유는 요즘 사내 카페에서 내가 히비스커스 차를 즐겨 마신다.

너무나도 빠른 오늘날 프론트엔드 생태계 #

부제: 나의 첫 Svelte4 경험기

나는 이제 어떻게 보면, 프론트엔드와는 조금 멀어졌다. 하지만, 프론트엔드는 내가 처음 개발을 할 때 내가 입문했던 분야였다는 상징성을 가짐과 동시에 아직도 그 흥미를 잃은 것은 아니었다. 그저, 프론트엔드를 공부하기에 시간이 이제는 부족할 뿐.

요즘 JS 생태계가 너무 하루하루 급변하고 있다는 것은 모두가 알고 있을 것이다. 그 중에서 나는 슬슬 나의 메인 프론트엔드 기술 스택을 정하고 싶었다. 평소에 내가 가장 많이 사용한 프레임워크는 React 였고, 요즘 대세는 NextJS였지만, 내 개인적인 목적으로 NextJS를 쓰기에는 조금 과하다고 느껴졌다. 그래서, 난 2~3주동안 다음의 프레임워크들을 전부 체험해봤다.

HTMX
NextJS 14
Svelte4 + Svelte5 rc
QwikJS

이 프레임워크들로 또 사이드 프로젝트를 하나 더 만들었지만, 아직 완성은 아니고 demo 상태라서 공개하기에는 조금 부끄럽다. 위 프레임워크들을 사용해본 결과 가장 만족도가 높았던 것은 Svelete4 였다. 그리고, 사이드 프로젝트 또한 Svelte4로 완성시켰다. 하지만, Svelte5로 오면서 breaking change들이 많이 발표되었고, 개인적으로는 Svelte5가 추구하는 방향성이 내가 Svelte4에서 만족감을 느꼈던 방향성과는 많이 달랐다.

결론부터 말하자면, 현재 나는 일단 다시 React18로 정착한 상태이고, 이후에 React19가 발표되면, 또 다시 한 번 써봐야할 것 같다. JS, 특히 프론트엔드 생태계는 정말 요즘 눈 깜짝할 새 계속 변화하는데, 트렌드를 놓치지만 말아야지하는 생각으로 따라가려고 해도 너무 버겁다는 생각이 자꾸만 든다.

Git 프로토콜 Deep Dive #

나는 GitLab과 같이 Gitea 프로젝트를 이용해서 내 개인용 Git 서버를 내 방에 있는 홈서버에 셀프 호스팅하여 사용하고 있다. Gitea에 정착하기 이전에 GitLab이나 다른 self-hosting Git 프로젝트도 여러개 시도해보았다.

그리고, Gitea를 계속 쓰면서 들었던 생각은 그냥 아예 처음부터 나만의 Git을 만들 수는 없을까? 였다. 그래서, 바로 개발에 착수했고, 다음과 같은 서비스 아키텍쳐를 구성했다. 오늘날 보이는 다이어그램에서 Desk(클라이언트) 부분을 제외하고는 80% 정도는 이미 완성되었다.

flowchart LR client[Desk] --HTTP 1.1\nand\nGit Protocol--> api["Main API\n(golang)"] api <-.-> redis["Redis\n(cache)"] api <--> db[("Database\n(Postgres)")] api --proxy--> apache["git-http-backend\n(Apache)"] apache & api <--NFS--> fs[(.git filesystem)]

해당 아키텍쳐에서 git-http-backend가 궁금한 분들이 분명 있을 것이다. 이 부분에 대해서는 다른 블로그 글에서 따로 다룰 것이다.

해당 글에서 모든 내용을 다루기는 힘들지만, 나만의 Github/Gitea를 만들면서 정말 scratch부터 만들어나가기 시작했다. 그 과정에서 서로 다른 방식의 Git Protocol (SSH/HTTP/Local) 규격에 대해서 자세히 알 수 있었고, 어떤 기능이 git-core에 해당하고, 어떤 기능은 Github과 같은 호스팅 업체에서 제공하는지도 어렴풋이 구별할 수 있게 되었다.

이 서비스는 완성되면, 아무래도 나 혼자 쓰기에는 너무 아쉬워서 어떤 방식으로든 publish하고자 노력중이다.

개발 외적으로는? #

정말 뭐가 없다. 정말 2분기동안은 컴퓨터 앞에만 앉아있었던 것 같다.