altair의 프로젝트 일기

서론요새 업무를 하던 개인 사이드 프로젝트를 하던, 거의 항상 ai 에이전트를 사용하는 것 같다. 그러다보니 대부분의 작업 내용을 내가 거의 모르는 상태로 마무리하곤 한다. 이럴 때 쓰는게 HTML 리포트인데, 사실 여러 귀찮음이 조금 있었다. 에이전트가 리포트를 HTML로 만들었다고 하자. 돌아오는 건 /tmp/claude-1000/.../report.html 같은 경로다. 나는 그 파일을 열어야 하는데, 에이전트가 도는 곳이 devbox나 WSL이거나 컨테이너 안이면 브라우저로 열기가 애매하다. 결국 cat으로 긁어서 보거나, 스크린샷을 찍어 달라고 하거나, scp로 끌어오게 된다.혼자 볼 때는 그럭저럭 참을 만하다. 문제는 그걸 남에게 보여줄 때다. 파일 경로는 공유할 수가 없다.그래서 leaf라는..

서론 입사하고 사회생활을 처음 시작한 신입사원 입장에서 가장 힘들었던 점은 업무 컨텍스트의 분산이었다. 되돌아 생각하면 강박에 가까운 팀원들의 문서화가 이미 있었던 것 같지만, 아무런 베이스 컨텍스트가 없었던 그땐 많이 혼란스럽고 어려웠다. 그 중에서도 서비스의 코드베이스보다, 거기까지 오게 된 의사결정 내용이 훨씬 찾기 어려웠다. 코드베이스의 함수와 API들을 살펴보는건 쉽고 어떤 라이브러리 스택을 쓰는지 밝히는 건 꽤나 분명한 작업이다. 그런데 왜 있는지 모르는 인가 로직이라던가, 최신 버전으로 올리지 않은 라이브러리에 대한 의사결정 기록은 코드에 없고 위키에 있거나, 특정 팀원의 회의록에 있거나, 심지어 누군가의 머릿속에만 있기도 한다. 이런 상황은 개발자들이 강박적으로 문서를 작성하게 된 이유이..

서론 맨 처음 프로그래밍 수업을 들었을 때가 생각난다. 사칙연산 계산기를 만들고 입출력 복사기를 만들면서 짜릿함을 느끼던 시절이 가끔은 벌써 그립기까지 하다. 그중에서도 제일은 별찍기가 아닐까 싶다. 알고리즘적 사고에 익숙하지 않았던 나에게 도전적이면서도 짧은 시간에 완성할 수 있고, 성취감까지 한 번에 느낄 수 있는 고전적인 과제였다. 요즘처럼 소위 "딸깍"만으로 고도의 작업까지 손쉽게 완료할 수 있는 시대에 별찍기가 불현듯 떠오르는 건, 어느 정도 향수병과 닮지 않았을까. 프로그램의 밑바닥까지 이해하고, 바이오 데이터베이스인 머릿속에 온갖 색인을 들고 자기효능감에 휩싸여 다니던 학창시절이 그리워지곤 한다. 하지만 업무·개인 프로젝트를 하다 보면 그러한 경험이 무색하게 AI 딸깍으로 많은 문제를 해결하..

서론 원래 계획은 NAS에는 DB, S3 같은 stateful 한 서비스를 컨테이너로 올리고, k8s 클러스터에는 이걸 네트워크로 연결해 사용하는 것이었다. NAS 자체가 용량이 무지막지하게 크기도 하고, RAID6로 failover도 마련되어 있기 때문이었다. 하지만 막상 앱들을 올리자니 NAS 자체가 SPOF가 되는 문제가 발생했다. 단 하나의 NAS에 여러 서비스가 의존하고 있다면, NAS의 실패가 곧 서버 전체의 실패를 야기할 것이었다. 그래서 statefulset으로 DB들을 올리기로 마음먹었다. 그러나 k8s 클러스터에 stateful 앱을 올리기 위해서도 결국 어떤 스토리지를 사용해야 한다. 그 때 마침 옆팀 팀원분이 추천해주신 Longhorn을 사용해보기로 했다. Longhorn 롱혼은 ..

HA란? 클라우드 서비스를 사용하지 않고 홈서버에 솔루션들을 올려 사용하다보면 가장 큰 문제가 되는 부분이 바로 HA, 고가용성이다. 구글 클라우드에 올려 놓은 파일을 다운로드 받지 못할거라고 걱정해본 적이 있는가? 클라우드플레어 DNS를 쓰며 그 DNS가 접속 불가능해질거라고 생각해본 적이 있는가?(최근 사고로 신뢰를 좀 잃은 듯 하지만...ㅋㅋㅋ) 고가용성(高可用性, 영어: high availability, HA)은 서버, 네트워크, 프로그램 등의 정보 시스템이 상당히 오랜 기간 동안 지속적으로 정상 운영이 가능한 성질을 말한다. 고(高)가용성이란 "가용성이 높다"는 뜻으로서, "절대 고장 나지 않음"을 의미한다. - 위키백과 그렇지만 내 서버에 올린 서비스는 언제든지 접속 불가능해질 수 있다. 버그..

서론재택근무를 자주하곤 한다. 그러다보면 아이러니한 경우가 자주 일어나는데, 방금 전까지 오퍼레이터 코드를 수정하며 k8s 파드의 노드 로그를 뚫어져라 살펴보다가퇴근을 찍고 나서 바로 내 k8s 클러스터를 관리하는 argocd와 그라파나를 들어가 이상이 없는지 살펴보곤 한다.가끔 내가 퇴근을 한 건지 안한 건지 헷갈릴 때가 있다.게다가 어쩔 수 없이 회사의 클러스터와 내 클러스터를 비교하게 된다.그 차이점 중 가장 눈에 띄는 것은 바로 베어베탈 k8s와 VM k8s다.아무래도 CPU, GPU 자원을 풀로 활용해야 하는 회사에서는 대부분 BM 서버에 k8s 노드를 올리지만나는 모두 VM 위에 올라가 있다.{{}}VM 위에 k8s?여기저기 이야기를 나누다보면 왜 그런 비효율적인 구성을 고집하는지 의문을 갖는..