vibePulse, 바이브크루를 비롯해서 이것저것 계속 만들고 있습니다.

처음에는 그냥 서버 하나 잡아서 올리면 끝이었습니다. 또 하나 만들면 빈 서버 찾아서 올렸고, 필요한 DB 붙이고 Redis 붙이고 또 다음 걸 만들었습니다.

일단 돌아가니까.
일단 배포됐으니까.
일단 다음 거 만들어야 하니까.

그렇게 하나씩 쌓이다 보니 어느 서버에 뭐가 올라가 있는지, 어디까지 백업되고 있는지, 빌드는 어디에서 해야 하는지까지 점점 복잡해졌습니다.

M4 16GB 한 대로 너무 많은 걸 했습니다

지금 쓰는 맥미니 M4는 16GB / 1TB입니다.

코드도 여기서 짜고, Codex와 Claude도 돌리고, 브라우저도 잔뜩 열고, Docker 컨테이너도 띄우고, 이미지 빌드와 테스트까지 여기서 했습니다.

16GB도 처음엔 충분했습니다. 문제는 제가 하는 일이 계속 늘어났다는 겁니다.

AI 에이전트 몇 개 띄우고, 브라우저 여러 개 열고, Docker까지 돌리기 시작하면 메모리는 거의 항상 꽉 찹니다.

그래서 결국 질렀습니다.

이 정도면 한동안 걱정 없겠지 싶었는데, 주문하고 나서 서버 구성을 다시 보다 보니 생각이 조금 바뀌었습니다.

그래서 기초공사부터 다시 하기로 했습니다

지금 제가 가지고 있는 장비를 한번 다 펼쳐봤습니다.

리눅스 노트북은 배터리가 죽었습니다.

이제 노트북이라고 부르기도 좀 애매합니다. ㅋㅋ

대신 64GB 메모리에 GPU도 있어서 계속 전원 물려놓고 작업 서버로 쓰기에는 아직 꽤 쓸 만합니다.

장비마다 딱 하나의 역할을 주기로 했습니다

예전에는 남는 컴퓨터가 있으면 거기에 이것저것 올리는 방식이었습니다.

이번에는 반대로 가려고 합니다.

먼저 역할을 정하고, 그 역할에 맞는 것만 올립니다.

Oracle 3대는 운영 클러스터로

목표는 단순합니다.

한 서버에 서비스가 묶이는 구조를 최대한 줄이고, 특정 서버에 문제가 생겨도 다른 노드에서 서비스를 이어갈 수 있는 구조를 만드는 겁니다.

물론 서버 3대를 Kubernetes로 묶는다고 자동으로 모든 게 고가용성이 되는 건 아닙니다.

PostgreSQL, Redis, 파일 스토리지처럼 상태를 가지는 서비스는 따로 고민해야 합니다.

이 부분도 실제로 옮겨가면서 하나씩 정리해볼 생각입니다.

M5 Pro는 운영 서버가 아닙니다

처음에는 새 M5 Pro에 서비스를 많이 올릴 생각도 했습니다.

그런데 집 인터넷은 아무리 잘 구성해도 클라우드 데이터센터와 같을 수는 없습니다.

정전이 날 수도 있고, 인터넷이 끊길 수도 있고, 제가 공유기를 잘못 만질 수도 있습니다. ㅋㅋ

그래서 M5 Pro는 운영보다 스테이지와 빌드 머신으로 쓰기로 했습니다.

특히 M5 Pro와 Oracle 운영 서버가 같은 ARM 계열이라 운영과 같은 아키텍처 계열에서 이미지를 검증할 수 있다는 점도 마음에 들었습니다.

앞으로 배포는 이렇게

개발은 M4에서 합니다.

코드를 올리면 M5 Pro의 GitHub Actions Runner가 이미지를 빌드하고, 스테이지에 먼저 올립니다.

거기서 실제로 확인한 다음 운영으로 넘깁니다.

스테이지는 외부에 공개하지 않고 Tailscale 안에서만 접근하게 할 생각입니다.

그러면 밖에서도 휴대폰으로 실제 운영과 거의 같은 환경을 바로 확인할 수 있습니다.

그러면 기존 M4는 오히려 한가해집니다

오히려 이게 제가 M5 Pro를 산 가장 큰 이유가 될 것 같습니다.

M4를 버리는 게 아니라 M4가 하던 일을 나누는 것.

개발 화면은 가볍게 유지하고, 실제 빌드와 실행은 다른 머신으로 넘깁니다.

리눅스 머신은 막일 담당입니다

제가 만드는 것 중에는 웹서비스 말고도 계속 돌아가야 하는 작업들이 있습니다.

시세 데이터를 계속 수집하거나, 브라우저를 10개 이상 띄워놓고 CDP로 자동화하거나, 많은 데이터를 가지고 지표를 계산하는 작업들입니다.

이런 것까지 운영 Kubernetes에 집어넣으면 오히려 운영 서비스와 자원을 두고 싸우게 됩니다.

그래서 이런 무거운 작업은 리눅스 머신으로 빼려고 합니다.

죽어도 실제 서비스가 같이 죽지는 않는 구조입니다.

앞으로 서비스 20~30개를 기준으로 잡았습니다

지금 서비스 개수에 맞춰 설계하면 또 몇 달 뒤 뜯어고칠 것 같습니다.

그래서 아예 20~30개 정도의 서비스가 돌아간다고 생각하고 기준을 잡았습니다.

서버 한 대가 바뀌어도 서비스를 옮길 수 있고, 새로운 서버가 추가돼도 구조를 크게 바꿀 필요가 없게 만드는 게 목표입니다.

이번 기초공사에서 지킬 것 5개

580만 원짜리 맥미니 사고 기초공사부터 합니다

처음에는 그냥 빠른 컴퓨터 하나 더 사는 거였습니다.

그런데 정리하다 보니 일이 커졌습니다.

네트워크도 다시 보고, 서버 역할도 다시 나누고, Kubernetes도 정리하고, CI/CD도 다시 만들고, 백업 방식도 다시 봐야 합니다.

그래도 지금 한번 제대로 해두는 게 낫다고 생각합니다.

서비스가 더 늘어난 뒤에 손대면 그때는 진짜 못 건드릴 것 같거든요.

물론 지금 적은 구조가 최종 정답은 아닙니다.

직접 옮겨보다가 생각과 다른 부분이 나오면 바꿀 겁니다. 빌드 인 퍼블릭이니까 잘된 것만 올리지 않고 삽질한 것도 같이 남겨보려고 합니다.

홈서버와 클라우드를 같이 운영하시는 분들이 있다면 구성하면서 얻은 팁도 알려주세요.

580만 원이 아깝지 않으려면 열심히 굴려야죠. ㅋㅋ