인간의 빅데이터는 잘 틀리지 않는다. 보통 그것을 우리는 본능이라 한다. 나의 본능은 2022년부터 위험신호를 보냈다.
나는 인지했지만 충분히 내 능력이라면 이겨낼수 있을거라 생각했다. 그건 내가 잘못 생각한것이었다. 일과 사람은 뗄수없으며, 사람의 문제는 조직의 문제로 발전하고, 건강할수 없다.
그렇지만 나는 최선을 다했다.
그 최선은 나의 마음을 갈아넣는 것이었고, 내 마음 또한 한계가 오는 시점들이 있었다. 이 시점들을 지나고 보니 그게 나는 슬럼프인걸 알았다. 사람은 변하지 않고, 나는 타인을 변하게 할수 없음을 안다. 사람이 변하지 않으면 조직이 변하지 않고, 나는 조직을 변화시킬수 없음을 슬럼프가 다가 왔을때 느꼈다.
그런데도 불구하고 나는 올해 정말 많은 일을 했다.
먼저 회사에서 멀티미디어를 서빙할때 Multi DRM을 사용하는데, 이 Multi DRM의 아키텍처를 내가 설계했다.
E-book 이라는 컨텐츠또한 DRM을 사용하는데 이 DRM을 고도화 하는 작업에서 누구도 납품받은 솔루션을 재대로 다룰수 없는 상태라 이 DRM을 설계하고 프로토 타입을 내가 만들었다. 이 기사 에서 말하는 DRM이 내가 만든거다. 그 다음으로 회사의 인프라는 많은 변화를 겪고있는데, DX를 통하여 서버기반의 인프라를 컨테이너 기반으로 이동중이다. 새로이 만들고 있는 플랫폼은 Gitops / Terraform / EKS 등등 맛있는 건 다들어가있고, 반년이상 지속적으로 관리하고 고도화하는 과정에서 결과물이 슬슬 나오고 있다.
또 팀의 리더로서 나의 동료들을 지키고 성장시키기 위해서 다양한 고민을 했다.
2022년은 같이 일하는 동료를 파악하기 위한 과정이었고, 2023년은 나의 동료들이 최고의 퍼포먼스를 낼수있도록 만드는 과정에 있었다. 그 과정에서 나는 많은 고통을 받았다. 하지만 내 동료들은 정말 많은 성장을 했다.
우리의 형 T. 나는 많은 DBA를 본건아니지만 이토록 방대한 범위를 꼼꼼하게 설계하는 사람을 본적이 없다. 차근차근 항상 꾸준하게 퍼포먼스를 뽑는다. 체계를 만들고 그 체계를 잘 활용한다. 이 과정에서 나오는 시너지가 어마어마 하다. 창의적으로 일하고 업무에 미학이 있다. 아름다운 데이터베이스 아키텍처를 설계한다.
동료인 S. 는 이제 시니어에 이르러서 막강한 퍼포먼스를 뽑아주기 시작했다. 나와는 결이 좀 다른데, 나는 레거시는 뜯어서 없애버리자는 주의인데, 이 동료는 레거시가 분포되어있는 영역을 파악하고 하나로 모아서 고도화 하는 작업을 스스로 시작했다. 또한 누구나 기피하는 운영의 영역에서 단한번도 싫은 내색없이 묵묵히 운영업무를 감내했다. 우리 팀의 최고의 인싸이자 로멘티스트로 정말 멋진 사람이다.
우리의 행동대장 칼잡이 D. 막내인데도 이미 두세사람 몫은 반드시한다. 협업능력 / 판단능력 다 좋다. 업무를 깔끔히 정리하고 이해안되면 죽어라 공부해온다. 그냥 적당히 설명만 하면 납득하거나 납득 안되는 부분은 물어온다. 나로서는 한가지 방식의 지시만 하면된다. 내가 생각하는 목적지를 구체적으로 보여주는것. 구체적인 그림을 보여주거나 내가 예측하는 그림을 보여주기 어려운 경우도 있지만 서로가 생각하는 방식이 비슷한점이 있어서 거의 대부분을 해결했다.
팀 전체로 우리는 올해 같은 목적을 가지고 뛰었고, 같이 분노하고 기뻐했다. 우리가 얻은 가장 큰것은 결속이 아닌가 싶다.
나는 여러번 리더로서 일했지만 성장하는 법을 이제야 배우고 있다.
다시 나의 이야기로 돌아가서 나는 이 과정에서 성장도 경험했지만, 나 스스로 무언가 억눌리고 심리적인 불안감이 있었다. 그건 슬럼프였고, 어느 순간 갑자기 슬럼프가 사라졌다. 그 결과 나는 다시한번 나의 한계를 부술수있는 강한 고양감을 느끼고 있다.
한 해의 마지막에서서 각성이 된다는건 참으로 이상한 일이다. 다른사람들이 마무리와 시작을 준비할때 나는 막 달리고 있는 순간이다. 이 감을 잃지않고 달려보려 한다.
ps -eLf 명령어는 중요한부분은 L 옵션입니다. 스레드를 출력하는 옵션입니다. 그다음 명령어는 httpd 스레드의 2번째 행만 발라낸뒤 숫자로 정렬하고 유니크 명령어로 각 카운트를 세었습니다. 뭔가 연관성이 보이지 않나요? 6번째 행에서 보여주는 값이 프로세스내 스레드 갯수입니다.
이렇게 하나의 프로세스는 여러개의 스레드를 가지고있는 것을 확인할수 있습니다.
그럼 시작하는 엔지니어의 글을 작성한다고 했던 제가 왜 스레드니 프로세스니 하는 이야기를 하고 있을까요?
프로세스는 오늘 할 이야기의 시작이자 끝이기 때문입니다.
프로세스의 정의는 실행 중인 프로그램의 인스턴스입니다. 이는 코드, 데이터, 스택, 힙과 같은 메모리 영역, 파일 디스크립터, 환경 설정 등을 포함합니다. 운영 체제에서 기본적인 실행 단위로, 시스템 자원과 작업을 관리하는 데 사용됩니다.
이 프로세스를 격리하는 메커니즘을 Namespace 라고 합니다. 네임스페이스는 리눅스에서 프로세스를 격리하는 메커니즘입니다. 각 네임스페이스는 특정 종류의 시스템 자원을 감싸고, 프로세스가 그 자원을 별도로 보도록 합니다. 예를 들어, 네트워크, 파일시스템 마운트 포인트, 사용자 ID 등이 있습니다.
마지막으로 Cgroup 는 프로세스 그룹의 시스템 자원 사용을 제한하고 격리하는 기능을 제공합니다. cgroups를 사용하면 CPU 시간, 시스템 메모리, 네트워크 대역폭 등의 자원을 제어할 수 있습니다. 시스템 자원의 공정한 분배 및 특정 프로세스 그룹의 자원 사용을 제한하여 시스템의 안정성을 보장하는 데 사용됩니다.
Namespace, Cgroup 이 둘은 함께 사용되어 프로세스의 격리 및 자원 관리를 향상시킵니다. 네임스페이스는 격리를 제공하고, Cgroup은 자원의 사용을 제한합니다. 이러한 조합은 효과적인 리소스 관리 및 격리된 환경을 제공하는 컨테이너 기술의 기반이 됩니다.
컨테이너는 가볍고, 이동이 쉬우며, 격리되고, 관리하기 편합니다.
컨테이너는 프로세스 입니다. 호스트 OS 내에서 앞서 보여드렸던, https 프로세스와 동일하다 보면 됩니다. 그러면 docker 에서 실행 중인 httpd 프로세스를 한번 확인해 보겠습니다.
docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
927717d2d026 httpd "httpd-foreground" 4 seconds ago Up 3 seconds 80/tcp stupefied_gagarin
182ddd3df992 httpd "httpd-foreground" 5 seconds ago Up 4 seconds 80/tcp relaxed_lovelace
4d50ad075f73 httpd "httpd-foreground" 6 seconds ago Up 5 seconds 80/tcp upbeat_goldwasser
cfb8c7c071b0 httpd "httpd-foreground" 8 seconds ago Up 7 seconds 80/tcp crazy_chandrasekhar
4개의 컨테이너가 구동중이고, 각자 격리된 형태입니다. 자원만 충분하다면 컨테이너를 ulimit 에 설정된 openfile 이 받아주는 한계에서 굉장히 많은 컨테이너를 실행할수 있습니다. 컨테이너 네트워크또한 호스트와 분리한다면 더욱더 많은 컨테이너를 실행할수 있습니다.
이러한 컨테이너의 형태는 우리 엔지니어들이 입이 마르고 닳도록 말하는 kubernetes 와 연결되어있습니다.
N+1개로 이루어진 Pod는 Node에 스케줄링됩니다. 위에서 예제로 보인 4개의 컨테이너의 실행은 네번이나 run 커멘드를 실행해야 하므로 아주 귀찮습니다. Kubernetes 에서 100개의 컨테이너를 생성하는 방법은 아래와 같습니다.
이러한 형태로 선언만 하면 이제 끝입니다. 이런 방법으로 우리는 httpd Container를 쉽게 만들수 있습니다. 그럼 프로세스에 이어서 바로 쿠버네티스로 넘어왔는데, 뭔가 빠져있다 생각하지 않나요? 바로 노드입니다. 쿠버네티스는 컨테이너 오케스트레이션이라 불립니다. 연결된 Node에 API를 이용하여 애플리케이션과 서비스를 구성하고 관리하고 조정합니다.
드디어 오늘의 이야기의 핵심에 다가가고 있습니다.
쿠버네티스는 결국 리눅스에 설치됩니다.
우리는 Pod와 Service 오브젝트는 간단히 다룰수있지만 추상화의 너머에 있는 Kubernetes의 프로세스와 노드에서 돌고있는 Kubelet 에 대해선 간단히 다룰수 없습니다.
우리는 다양한 것들이 추상화되어있는 시대를 살고있습니다. 그래서 그 심연을 들여다 보면 멘탈이 날아가는 일이 비일비재 합니다. 이러한 일들에 내성을 가지고 이겨내기위해선 결국엔 기본능력이 오르는 수밖에 없습니다.
기본능력이라 함은 리눅스 입니다.
항상 리눅스를 잘하려면 어떻게 해야하나요? 라는 질문을 듣습니다. 리눅서로서 사실 죄송한 말이지만 리눅스를 잘하는 기준은 어디에도 없고 리눅스 서버운영에는 많은 명령어가 필요하지 않습니다. 대부분 10개이내의 명령어를 사용합니다. 하지만 대부분의 일은 그 명령어들 내에서 처리됩니다.
그렇다면 리눅스를 잘하려면 어떻게 해야하냐? 결국엔 다양한 명령어들을 경험하고 손에 익어서 문제가 발생한 시점에 그 명령어를 사용해서 시스템을 점검하는것이 리눅스를 잘하는 것입니다.
저 같은 경우엔 처음보는 시스템도 30분이면 대부분 파악이 됩니다.
그 힘은 다양한 리눅스 환경에서 헤멘탓이 큽니다. 디렉토리 구조 패키지형태 명령어 스타일 배포판 마다 조금씩 다릅니다. 이런경우 저는 레드헷 계열 리눅스를 편하게 쓰지만 처음 보는 리눅스라 해서 어려워하지 않습니다. 이유는 간단합니다.
시작하는 엔지니어라면 리눅스의 구조 동작을 먼저 공부하시고 그 다음엔 명령어 프로세스 동작 그리고 간단한 스크립트도 짜보는것을 추천합니다. 또한 리눅스에선 다양한 명령어 들이 있습니다. 지금 이순간에도 누군가가 리눅스의 명령어를 만들고 있을 것입니다. 자신만의 명령어를 만들어도 좋습니다. 리눅스에 익숙해지고 많이 두드려 보세요.
손가락에 익은 명령어는 시스템을 배신하지 않습니다.
사실 가끔 합니다 (rm -rf *) 과 같은..누구나 하는 실수입니다.(저는안했습니다.)
기승전리눅스를 이야기하게 되었네요.
하지만 리눅스는 현대의 IT를 이끌고있는 근간이고 대부분의 시스템이 리눅스에서 구동된다는 사실을 안다면 근본인 리눅스를 하지 않을수 없다 생각합니다.
그러던중 현대의 컴파일러에선 XOR가 메모리를 사용하지 않지만 병렬처리에서의 문제로 성능이 떨어진다는 이야기를 들었다.
항상 자세한 설명과 함께 도움주시는 pr0gr4m 님.
느려지는게 맞다고 하셔서 궁금해서 돌려봤다.
import timeit
# temp 사용
def swap_temp():
a = 5
b = 10
temp = a
a = b
b = temp
return a, b
# XOR 사용
def swap_xor():
a = 5
b = 10
a ^= b
b ^= a
a ^= b
return a, b
# 성능 테스트
temp_time = timeit.timeit("swap_temp()", setup="from __main__ import swap_temp", number=1000000)
xor_time = timeit.timeit("swap_xor()", setup="from __main__ import swap_xor", number=1000000)
print(f"Using temp: {temp_time} seconds")
print(f"Using XOR: {xor_time} seconds")
코드를 여러번 실행해 봤고 결론을 얻었다.
linus@Linusui-MacBookPro python % /opt/homebrew/bin/python3 /Users/linus/Desktop/python/test.py
Using temp: 0.04701741598546505 seconds
Using XOR: 0.06559245800599456 seconds
linus@Linusui-MacBookPro python % /opt/homebrew/bin/python3 /Users/linus/Desktop/python/test.py
Using temp: 0.04990166565403342 seconds
Using XOR: 0.06569029204547405 seconds
linus@Linusui-MacBookPro python % /opt/homebrew/bin/python3 /Users/linus/Desktop/python/test.py
Using temp: 0.04502225015312433 seconds
Using XOR: 0.0672295419499278 seconds
linus@Linusui-MacBookPro python % /opt/homebrew/bin/python3 /Users/linus/Desktop/python/test.py
Using temp: 0.045115040615200996 seconds
Using XOR: 0.06622312497347593 seconds
linus@Linusui-MacBookPro python % /opt/homebrew/bin/python3 /Users/linus/Desktop/python/test.py
Using temp: 0.044884291011840105 seconds
Using XOR: 0.06595424981787801 seconds
linus@Linusui-MacBookPro python % /opt/homebrew/bin/python3 /Users/linus/Desktop/python/test.py
Using temp: 0.04486312484368682 seconds
Using XOR: 0.06613395782187581 seconds
linus@Linusui-MacBookPro python % /opt/homebrew/bin/python3 /Users/linus/Desktop/python/test.py
Using temp: 0.04502458404749632 seconds
Using XOR: 0.06623658305034041 seconds
linus@Linusui-MacBookPro python % /opt/homebrew/bin/python3 /Users/linus/Desktop/python/test.py
Using temp: 0.044890208169817924 seconds
Using XOR: 0.0665586250834167 seconds
linus@Linusui-MacBookPro python % /opt/homebrew/bin/python3 /Users/linus/Desktop/python/test.py
Using temp: 0.045562250073999166 seconds
Using XOR: 0.06695195799693465 seconds
linus@Linusui-MacBookPro python % /opt/homebrew/bin/python3 /Users/linus/Desktop/python/test.py
Using temp: 0.04477795818820596 seconds
Using XOR: 0.06620474997907877 seconds
네이버클라우드에서는 나는 주로 설계를하고 내부적문제를 분석하고 에스컬레이션하는 업무를 맡았다. 그리고 CSAP 인증관련 프로젝트를 하며, 기약없는 나날을 보내고 있었다. 성장에 목이 말랐고, 뭘해야할지 모르는 안타까운 날들이었다. 회사의 성장은 느껴지는데, 나의 성장은 멈춰있는 느낌이었다.
문제는 회사가 아니라 나에게 있었다.
일상에서의 자극들이 아이디어와 성장으로 이루어지는 나의 방식이 알맞지 않았다. 또 기술적 성장을 더욱 하고싶었다.
그래서 이직을 선택했다. 다양한 회사를 알아봤고, 그러다 밀리의서재로 오게되었다.
이력서를 제출전에 본부장인 리나와 커피챗을 했다.
밀리의 사용 스택과 필요한 부분등 여러가지가 나와 핏이 잘맞았다. 흔히 말하는 저스트핏. 바로 이력서를 작성했고 면접을 봤다. 1차면접부터 2차면접 합격까지 10일의 시간이 걸렸고, 바로 입사를 결정했다.
이렇게 빠른 결정이 가능했던건 정말 나와 밀리가 핏이 너무 잘맞았기 때문이라 생각한다.
인프라팀을 정돈해가며 스크럼에 적응하고, 내 서비스를 가지게 된 나는 서비스와 친해지기 위해 많은 정성을 쏟았다.
또 리더로서 다시 일하게 되어 더욱 동료의 생각에 공감하려 노력했고, 내가하는 일이 동료가 공감할수 있도록 노력했다.
기계처럼 일만하는게 아니라 동료의 신뢰를 얻고 싶었고, 내가 엔지니어로 같은 회사에 있을 때 느껴지는 든든함을 동료들이 가지길 원했다.
새로운 모니터링 시스템을 만들고 분석 플랫폼을 만들어서 이슈의 원인과 분석을 하는 속도를 높여갔다.
