2024.12.20 Deadline-driven development

뭔가 새롭게 생각난게 없고 약간 정체상태인 것 같다. 쓰고 싶은 주제도 딱히 없고 하던 차에, 기분전환을 위해 점심식사 대신 예전부터 보고 싶던 영화 <서브스턴스>를 보고 왔다. 최근 극장에서 본 영화 3개가 <에브리씽 에브리웨어 올 앳 원스> - <보 이즈 어프레이드> - <서브스턴스> 였으니 진짜 1년에 딱 한번씩 극장을 가는 것 같은데, 그 와중에도 취향의 일관성이 좀 있는 것 같다.. 나이를 먹으며 몸상태도 꺾이고 하니 자주 드는 생각인데, 엔지니어로서의 나도 정점은 이미 지났고 계속 내려오고 있다는 생각을 자주 한다. 그렇게 되어서 슬프다 혹은 위기감을 느낀다 이런 차원은 아니고, 더 이상 젊었을때처럼 활발하게 에너지를 쏟아 이것저것 공부하고 해보고 하는 반짝반짝 빛나던 시절이 지나갔고 이 사실을 인정해야 한다는 생각이 든다. 낮에 본 영화도 결국 그것을 인정하지 못하는 사람들에 관한 이야기인데, 그렇다면 내리막의 나는 무엇을 할 수 있고 또 해야 하는가 이런 고민이 자연스럽게 생기는데, 결국 고민해봐도 결론은 '지금 내가 할 수 있는 것을, 나 자신을 너무 과신하지 말고, 스테디하게 하자' 정도인 것 같다.

복잡하고 거대한 시스템이 오작동할 때가 있다. 사실 복잡하고 거대하기 때문에, 단순한 시스템보다 오작동될 여지가 더 많다. 이 때 사고가 나면 여러가지 분석을 하고 재발방지를 위한 대책을 세우게 된다. 대부분 원인 분석을 해 보면, 예컨대 실수 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를 빼먹었네' 하고 다시 돌리고.. 이게 글로 들으면 엄청 비효율적으로 느껴지지만 생각보다 코딩 자체에 쏟는 시간은 많지 않고, 코파일럿 이후로 더욱 줄었기 때문에 결국 일하는 시간의 절반 이상은 설계에 대한 의사결정, 혹은 그 의사결정을 위한 근거자료를 모으는데 쓰게 되는 것 같다. 그리고 나머지의 절반정도는 리팩토링에 쓰게 되고.. 그렇기 때문에 어설프게 여러 컨텍스트를 동시에 돌리기보다는 그냥 피드백 루프가 한싸이클 도는 동안 머리를 식히는 것도 꽤 만족스럽고 효율적으로 느껴진다.