2024.12.17 내리막을 걷기

복잡하고 거대한 시스템이 오작동할 때가 있다. 사실 복잡하고 거대하기 때문에, 단순한 시스템보다 오작동될 여지가 더 많다. 이 때 사고가 나면 여러가지 분석을 하고 재발방지를 위한 대책을 세우게 된다. 대부분 원인 분석을 해 보면, 예컨대 실수 A, 실수 B, 부실함 C, 부실함 D가 모여서 일어나는 식이다. 그러면 이제 많은 경우 재발방지 대책이 이렇게 된다: - 실수 A를 방지할 수 있도록 절차 A01의 확인과 승인과정을 강화한다 - 실수 B를 방지할 수 있도록 B01을 하기 전에 테스트를 강화한다 - 부실함 C를 보완할 수 있도록 이중화 한다 - 부실함 D를 보완할 수 있는 D01 솔루션을 도입한다 그러나 아쉬운 것은, 시간과 돈을 들여 그런 사후대책을 적용하더라도 상황이 크게 나아지지는 않는다. 왜냐하면 ...

일은 계속 하고 있는데 일기는 오랜만에 쓴다. 별 특별한 이유가 있었던건 아니고 그냥 육아도 좀 지치고 컨디션도 그렇게 좋지도 않고 약속도 연말이라 많고.. 8월 9일에 둘째 태어난 날부터 지금까지 단 한순간도 마음 편하게 릴랙스한 적이 없었다. 언제까지 이렇게 살아야 하는지 모르겠음.. 보통은 당장 쓸 일이 없으니 IP Layer에 대한 공부를 많이 미뤄두고 있었는데 뒤늦게 이것저것 찾아보고 있다. 사실 첫 회사에서 몸으로 부딪혀가며 배울 기회가 있었는데 지금 돌아보면 너무 뺀질거렸던 것일까.. eBPF도 각잡고 공부해야 하는데 또 공부하고 있으면 '빨리 프로토타입 만들어야 하는데 뭐하는 짓인가' 싶고, 그렇게 좀 고민하다 보면 아이 데리러 가야 하고 육아하러 가야 하고.. 많이 지친다.

현대적 CI/CD의 방향성을 한마디로 이야기 하자면 '모든 것은 부수고 재현될 수 있다'는 것이 아닐까 한다. 배포되는 서버의 프로세스도, 서버 자체도, 서버를 둘러싼 인프라도 모든 것이 영원하지 않음, stateless함을 전제로 운영된다. (그리고 stateful한 부분은 몰아서 저 어딘가로 치워놓는 것이다.) 모든 것은 재현될 수 있기 때문에 수평적 오토스케일링을 통해 원하는 레플리카를 늘릴 수 있고, 모든 것은 부술 수 있기 때문에 레플리카가 줄어들기도 한다. 이를 서버 단위로 하면 고전적인 EC2 기반의 운영이 될 것이고, 이걸 좀 더 추상화하여 큰 컴퓨팅 풀 안에서 하면 k8s의 Pod들이 될 것이다. 그런데 오히려 PaaS를 준비하는 입장에서는 그러한 특성 때문에 해자를 만들기가 어려워진다. 물론 여러가지 부가가치를 제시하려고 노력하지만 근본적으로 서비스하는 모든 대상이 부수고 재현될 수 있다는 것은, 다른 서비스에서도 똑같이 재현될 수 있다는 것이기 때문에 고객을 락인시키기가 어려워진다. 그렇기 때문에 stateful한 서비스를 주고 락인시킨다. 아무래도 DB같은건 한번 박아놓으면 마이그레이션이 어렵기 때문에, 많은 회사들이 PaaS의 컴퓨팅 자원과 함께 매니지드 스토리지 서비스를 제공하곤 하는데 우리도 결국 그렇게 할 수밖에 없지 않을까 싶다. 더 획기적인 방법이 생각난다면 모르겠으나.. 그리고 역으로 PaaS가 유의미한 고객을 뺏어오기 힘든 이유도 스토리지의 존재 때문인데, 이 점에 대해서는 계속 고민을 하고 있다. ...야 근데 제목(은 보통 글을 다 쓰고 지음) 정하면서 찾아보니 삐딱하게가 11년도 넘은 노래였구나 우씨 추가: 현대적 CI/CD론의 본질을 꿰뚫은 사람이 한 명 있는데: https://www.youtube.com/watch?v=S9HJigQfuwk

결국 일을 하다 보면 자동화 할 수 있는 부분은 최대한 자동화 하고 넘어가게 되는데, 그 자동화가 예를 들어 k8s 클러스터를 하나 부쉈다가 만드는 일이라고 하면 한번 피드백 루프를 도는데 한 3~4분 정도가 걸린다. EC2 인스턴스를 임시로 생성하고 거기에 어떤 작업을 해 놓고 그 스냅샷을 떠서 AMI로 만들고 그 AMI를 통해 클러스터 런칭을 해서 되는지 확인하고.. 이 싸이클이 한 3~4분정도가 걸리는 것이다. 보통 익스트림 프로그래밍 진영에서는 피드백 루프를 최대한 짧게 가져가는게 좋다고 하는데, 아예 몇 초 단위로 피드백루프가 짧은 것은 나도 나쁘지 않다고 생각하는데 길거면 아예 저렇게 3~4분정도로 길어도 나쁘지 않은 것 같다. 한번 눌러놓고 기다리는 동안 책을 읽거나 쇼츠를 하나 보거나 뭐 그런 식으로 칠링 하다가, 결과가 나오면 '아 여기서 sudo를 빼먹었네' 하고 다시 돌리고.. 이게 글로 들으면 엄청 비효율적으로 느껴지지만 생각보다 코딩 자체에 쏟는 시간은 많지 않고, 코파일럿 이후로 더욱 줄었기 때문에 결국 일하는 시간의 절반 이상은 설계에 대한 의사결정, 혹은 그 의사결정을 위한 근거자료를 모으는데 쓰게 되는 것 같다. 그리고 나머지의 절반정도는 리팩토링에 쓰게 되고.. 그렇기 때문에 어설프게 여러 컨텍스트를 동시에 돌리기보다는 그냥 피드백 루프가 한싸이클 도는 동안 머리를 식히는 것도 꽤 만족스럽고 효율적으로 느껴진다.

최근에 흥했던 흑백요리사의 김학민 PD가 인터뷰하는 것을 알고리즘덕에 우연히 보게 되었는데, 프로그램을 만들 때마다 어떤 결정적인 '장면'을 먼저 생각하고 나머지 틀을 잡아나간다는 이야기였다. 흑백요리사의 경우에는 세 장면이 있었는데, 1) 처음에 백수저 요리사들이 위에서 등장하는 장면, 2) 안대를 쓴 심사위원에게 음식을 먹이는 장면, 3) 거대한 두부 더미가 하늘에서 내려오는 장면 이랬다고 한다. 셋 다 깊은 인상에 남았으니 의도한 성공이라 할 수 있겠다. 제품을 단단히 만들어나가는 것과 별개로, 키보드 앞에 앉아있지 않을 때도 제품의 와우팩터에 대해 계속 생각한다. 사용자가 이 제품을 쓰면서 결정적으로 했으면 하는 단 하나의 체험이 있다면 무엇일까? 만약 그것이 있고 의도대로 동작한다면 잘 팔릴지는 모르겠으나 좋은 제품이라 할 수 있을 것이다. 음악이든 영화든 대중예술이든 순수예술이든 모든 예술의 영역마다 만들 때 창작자가 이런 외우팩터를 다들 생각한다고 보는데, 엔지니어를 위한 제품을 만드는 엔지니어들은 상대적으로 이런 와우팩터를 크게 고민하지 않고 만드는 편인 것 같다. 그 덕에 직접적으로 그런 창의력 넘쳐나는 사람들과 경쟁하지 않아도 돼서 다행인 것 같다.