altair의 프로젝트 일기

서론 데이터의 관리와 저장은 언제나 큰 화두였다. 데이터를 어떻게 안정적으로 저장할 것인지, 얼마나 많이 저장할 것인지, 얼마나 오래 유지할 수 있는지 같은 질문은 대용량 데이터를 다루는 사람에게 중요한 기준점들이 된다. 많은 경우 이런 저장소 특징을 바탕으로 저장할 데이터가 정해진다. 예를 들어 16GB만 저장 가능한 USB 스틱에 평생 보관할 사진들을 저장할수는 없다. USB 스틱 특성 상 망가지기 쉽기도 하고, 계속 늘어날 사진들을 16GB에 앞으로도 계속 저장할 수는 없을 것이기 때문이다. 그동안 많은 매체에 데이터를 저장, 백업해왔다. 이번 글에서는 데이터 저장에 대해 지금까지 느낀 생각들을 적어보려한다. 어디에 저장해야 하는가? 모든 저장소는 여기에서부터 시작한다. SSD에 저장해서 빠른 ..

서론요새 업무를 하던 개인 사이드 프로젝트를 하던, 거의 항상 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)은 서버, 네트워크, 프로그램 등의 정보 시스템이 상당히 오랜 기간 동안 지속적으로 정상 운영이 가능한 성질을 말한다. 고(高)가용성이란 "가용성이 높다"는 뜻으로서, "절대 고장 나지 않음"을 의미한다. - 위키백과 그렇지만 내 서버에 올린 서비스는 언제든지 접속 불가능해질 수 있다. 버그..