2024.12.31 올해의

스타얼라이언스가 더 나은 것 같아서 아주 오랫동안 여행이나 출장때마다 아시아나 마일리지를 모으고 있었는데, 여러가지 인류사와 개인사로 인해 19년 4월 이후로 한국 영토를 벗어난 적이 없었다. 그 사이에 스얼 등급과 마일리지는 다양한 방식으로 녹아내리고, 올해 말에 꽤 큰 마일리지를 소진해야 할 일이 있어 뉴욕행 비행기를 끊었다. 아시아나는 거의 '우리 장사 이제 접습니다' 수준으로 마일리지 승급을 복잡하게 하고 있어서 고객센터 전화연결에만 거의 두시간을 썼고.. 4월로 티켓을 끊었는데, 뉴욕에서 해야할 일들을 정리해 보니 그 전까지 만들어놓아야 할 것들이 제법 많다. 110일쯤 남았는데, 이제는 바야흐로 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