2024.11.14 기반의 기반

코드 스멜이 좀 있어서 전반적으로 리팩토링을 하는데 생각보다 길어져서 하루만에 못끝냈다. 초벌을 작성할 때는 오히려 코파일럿이 도와줄만한 부분이 훨씬 많다고 보는데, 좀 길어진 함수나 클래스를 리팩토링하는건 LLM에게 시켜봐도 뭔가 삐걱삐걱하고 영 미덥지가 못하다. 제일 흔한 패턴은 긴 컨텍스트를 주었을 때 뒷부분을 좀 빼먹거나 뒤로 갈수록 코드의 해상도(?)가 약간 흐려지는 현상이 있는데, 결국 리팩토링될 대상을 또 눈으로 검증하고 테스트도 그에 맞춰서 좀 잡아주고 해야 해서 그냥 손으로 하는 것보다 딱히 빠르다는 느낌이 들지 않았고.. 또 리팩토링을 하는 과정에서 API 포맷이 묘하게 바뀌어 창작되는 경우도 있었다. 특히 다른 파일로 넘어가면 컨텍스트 유지가 되는듯 마는듯 잘 안되고.. 계속 써 보면서 느끼는 것은, LLM이 가장 실수를 많이 하는 경우는 주로 마이너한 언어나 라이브러리를 사용할 때 자꾸만 API 형식을 지 맘대로 창작하는 경향이 있는데, 이걸 그냥 공식문서 전체 링크를 읽으라고 던져놓고 참고하게 하는 방법은 없을까 궁금했는데, 블스에 올렸더니 어떤 분이 답을 주셨다. https://docs.github.com/en/copilot/building-copilot-extensions/about-building-copilot-extensions 이런 식으로 서드파티들이 알아서 문서 먹여서 만들 수 있는 인터페이스를 주는 방식인 것 같은데, 올해 5월에 처음 발표되고 9월에 베타로 들어갔으니 곧 혜택을 볼 수 있는 여지가 있을 것 같다. 서드파티들이 안움직이면 좀 곤란하지만..

쿠버네티스는 클러스터의 데이터나 상태를 저장하기 위해서 내부적으로 etcd라는 DB를 쓰는데, 내가 원하는 전체적인 시스템 설계를 이리저리 그려보다가 etcd에 데이터를 저장할거면 왜 쿠버네티스 클러스터 노드 안에 있어야 하지? 시스템이 죽으면 etcd를 이용해서 살려야 할거고 etcd가 죽으면 클러스터가 죽어버려서 서로 강결합 되어 있는데, 밖에 있는게 맞는게 아닌가? 이런 생각을 하고 찾아 보니 문서에 'High Availability 구성을 하기 위해서는 etcd를 밖으로 뺄 수도 있어요'라는 대목을 찾았다. 한편 fault-tolerant한 시스템을 만들기 위한 여러 가지 재료들이 있는데 분산처리도 그 중 하나이다. 노드를 세대 ...

쿠버네티스를 좀 여유를 가지고 뜯어보고 있다. 원래 사용할 때는 주로 현업에 급해서 좀 피상적으로 쓰면서 쓸데없는 의문을 갖지 않고 쭉쭉 구현하기에 급급했었는데, 이번에는 쿠버네티스에 대한 이해가 제품 성패에 바로 연결될 것 같아서 허투루 넘기지 않고 문서나 책들을 찬찬히 보고 있다. 보통 새로운 기술을 공부할 때 내가 신경쓰는건, 이 기술을 개발한 사람들은 1) 어떤 문제를 풀고 싶은가, 2) 어떤 방식으로 풀고 싶은가, 3) 그렇게 결정한 배경이나 이유는 무엇인가 이다. 그래서 API 설계든 아키텍쳐든 보다 보면 처음 쿠버네티스를 만든 사람이 왜 이런 설계에 이런 선택을 한 것인지, 중간에 어떤 컴포넌트를 아예 갈아엎고 deprecate 시킨 역사가 있다면 처음엔 어떤 생각이었고 어떤 실패를 겪은 것인지, 그리고 어떻게 해결해야 한다고 생각했는지 이런 것들을 볼 수 있어서 좋은 것 같다. 학계에 있는 사람들은 주로 마지막 최종_진짜최종_진짜진짜최종 결과물들을 접하게 될 경우가 많은데, 이 업계는 그런 히스토리들이 문서로 계속 공개되고 남아있다는 점에서 좀 더 좋은 것 같다.

어젯밤에 첫째가 자꾸 발로 나를 차대서 거의 잠을 못잤는데 아침에 땡깡까지 부려서 컨디션이 완전히 망가졌다. 그 핑계로 일 하기 싫어서 오래 전 봤던 책을 다시 꺼내서 읽었다. [Release의 모든 것] 이라는 책(원제는 아마 Release it! 이었던듯)은 나름 이 분야에서는 고전, 혹은 정석과도 같은 책인데, 서비스를 배포하고 운영하기까지의 그 모든 과정에서 일어날 수 있는 일과 주의해야 할 일들을 모두 담아놓은 책이다. 원서는 2018년에 최신판인 2판이 나온 책이라 실제 기술 도구를 소개할 때는 약간 타임머신을 탄 기분이 들지만, 이 책에서 이야기하는 원칙들은 아직까지 모두 유효한 것들이다. 다루는 내용이 대단히 방대하면서도 압축적인 책인데, 번역의 단어선택들 중 몇 가지가 아주 야아악간 아쉽다는 느낌은 있다. 약간 단순화해서 이야기 하면, 내가 만들려는 제품의 궁극적인 목표의 형태가 이 책에 나오는 이야기와 원칙들을 전부 자동화해서 대신해주는 플랫폼이라고 해도 큰 과장은 아닐 것이다. https://www.hanbit.co.kr/store/books/look.php?p_code=B1820128661

IR자료 작성을 접고 2주만에 리포에 들어가 기억을 되살려 보는데 그간 외부 라이브러리나 패키지들이 많이 업데이트 되어 dependabot이 PR을 많이 만들어 놓은 것을 확인했다. 아직은 코드베이스가 크지 않아 모두 테스트를 통과해 있었고 딱히 깨지는 곳 없이 바로 올릴 수 있었다. 실제로 다른 회사들은 이걸 어떻게 대처하는지 궁금한데, 아예 워킹하는 버전에 고정해 놓고 올리지 않는 것을 택하는 경우가 절대다수일거라 생각한다. 내 현직장도 이런 모습에 가까운데, 괜히 올렸다가 어딘가 깨질 수도 있고 또 그런게 반복되다 보면 아예 breaking change를 몇 차례 ...