안정적인 서비스 기반을 구축하고, 영구 데이터와 다시 만들 수 있는 아티팩트를 분리하며, 호스트 자체를 보존하지 않고도 모든 개발자 서비스를 복구할 수 있게 하세요.
집에서 개발자 한두 명이 사용하는 경우, Linux 서버 하나에서 Git, 이미지 레지스트리, 데이터베이스, 미리보기 애플리케이션을 호스팅할 수 있습니다. 서비스가 서로 의존하기 전에 사용자 인증, 스토리지 역할, 네트워크 노출, 백업, 복구를 계획해야만 설계를 관리하기 쉽게 유지할 수 있습니다.
하드웨어를 선택하기 전에 서비스 역할을 정하세요
Git, 컨테이너 레지스트리, 데이터베이스 엔진, 미리보기 애플리케이션은 한 호스트를 공유하더라도 별도의 서비스 역할로 취급하세요. Git은 소스 이력을 보존하고, 레지스트리는 다시 만들 수 있는 아티팩트를 저장하며, 데이터베이스는 변경 가능한 애플리케이션 상태를 보관하고, 미리보기 앱은 필요할 때마다 폐기할 수 있는 런타임입니다.
동시 빌드 수, 데이터베이스 작업 데이터 크기, 활성 미리보기를 기준으로 CPU와 메모리를 산정하세요. 저장 공간은 저장소, 레지스트리 보존량, 데이터베이스 증가량, 로그, 백업 준비 공간을 기준으로 산정하세요. 이렇게 하면 메모리가 먼저 병목이 되는데도 대용량 디스크를 구매하는 일을 피할 수 있습니다.
개발 환경에서 노드 장애를 감당할 수 있다면 처음에는 컴퓨팅 노드 하나를 사용하세요. 컴파일 작업이 몰려 데이터베이스나 대화형 미리보기의 성능이 저하되기 시작하면 빌드 워커를 분리하세요.
영구 데이터, 다시 만들 수 있는 데이터, 복구 데이터를 분리하세요
| 데이터 역할 | 예시 | 보호 |
|---|---|---|
| 영구 상태 데이터 | Git 저장소, 데이터베이스 볼륨 | 스냅샷 및 별도의 백업 |
| 다시 만들 수 있는 아티팩트 | 컨테이너 이미지, 빌드 캐시 | 보존 정책, 선택적 백업 |
| 비밀 정보 및 구성 | 배포 키, 환경 파일 | 암호화된 내보내기 파일 및 오프라인 복구 사본 |
| 복구 미디어 | OS 설치 프로그램, 복구 메모 | 서버 외부에 저장 |
모든 바이트를 똑같이 백업하지 마세요. 레지스트리는 대개 소스와 빌드 지침으로 다시 만들 수 있지만, 데이터베이스는 그렇지 않습니다. 데이터베이스 덤프나 일관된 스냅샷은 실행 중인 데이터베이스 볼륨과 별도로 저장하세요.
실용적인 셀프 호스팅 백업 계획은 NAS 자체를 백업이라고 여기는 대신 Git 자동화와 외부 사본을 별개의 작업으로 처리하는 것이 왜 중요한지 보여 줍니다.
비공개 접속 경로 하나 만들기
서버에 안정적인 LAN 주소와 로컬 DNS 이름을 지정하세요. Git, 레지스트리, 데이터베이스, 프리뷰 경로는 필요한 네트워크에서만 접근할 수 있도록 설정하세요. 원격 접근은 여러 서비스 포트를 포워딩하는 대신 사설 VPN이나 인증된 리버스 프록시 경로를 통해 허용해야 합니다.
별도의 서비스 계정과 배포 키를 사용하세요. 개발자가 관리자 비밀번호를 공유해서는 안 되며, 프리뷰 앱에 Git 저장소나 레지스트리를 수정할 수 있는 인증 정보를 물려주지 마세요.
공유 마운트가 꼭 필요한 파일 작업에만 SMB나 NFS를 사용하세요. SMB와 NFS 클라이언트 적합성 가이드를 참고하면 프로토콜 선택과 애플리케이션 서비스 접근을 별도로 고려할 수 있습니다.
배포 순서를 의존성 그래프에 맞추세요
스토리지 마운트, ID 관리, 데이터베이스, 레지스트리, Git, 프리뷰 앱 순서로 시작하세요. 애플리케이션이 아직 준비 중이라는 이유만으로 느린 데이터베이스를 재시작하지 않도록, 상태 확인은 실제 의존성을 테스트해야 합니다.
배포 정의, 스키마 마이그레이션, 리버스 프록시 경로는 버전 관리에 보관하세요. 비밀 정보는 저장소 밖에 두고 복원 위치를 명확하게 지정하세요. 대체 호스트는 정의와 보호된 상태 데이터만으로 서비스를 재현할 수 있어야 합니다.
깨끗한 체크아웃 상태에서 프리뷰 앱 하나를 다시 빌드하고, 이미지를 가져오고, 테스트 데이터베이스를 복원한 뒤, 의도한 클라이언트 경로에서 앱에 접근해 검증하세요.
수집이 아닌 복원을 위한 백업
저장소, 데이터베이스 네이티브 덤프, 서비스 설정, 암호화된 비밀 정보를 모든 서비스가 쓰기 마운트할 수 없는 대상으로 백업하세요. 서버의 전원 및 관리자 권한 범위 밖에도 사본을 하나 이상 보관하세요.
분기마다 격리된 네임스페이스에 복원하세요. 파일이 있는지만 확인하지 말고 사용자, 확장 프로그램, 예약 작업, 저장소 권한, 레지스트리 인증, DNS 경로까지 확인하세요.
빌드 대기열 때문에 대화형 작업이 지연되거나, 이미지를 푸시하는 동안 데이터베이스 지연 시간이 늘어나거나, 백업 시간이 업무 시간과 겹치면 확장하세요. 실험용 서비스 하나가 안정적인 서비스 영역에 필요한 리소스나 인증 정보를 고갈시킬 수 있다면 같은 호스트에 역할을 더 추가하지 마세요.
최종 설정 규칙
각 서비스에 명확한 역할이 있고, 상태 데이터가 보호되며, 접근 경로가 통제되고, 복원 테스트를 마쳤으며, 토폴로지를 분리하거나 확장할 측정 가능한 기준이 있으면 설정이 제대로 된 것입니다.
NAS 및 서버 설정
더 읽어보기

기숙사 서버는 잠을 자거나 공부하고 화상 통화를 할 때 방해되지 않을 만큼 조용하게 작동할 수 있을까요?
네, 전력 소비가 적은 하드웨어를 사용하고, 저장 장치의 진동을 제어하며, 부하가 큰 작업은 예약하고, 방 안에서 소음을 확인하면 기숙사 서버를 조용히 사용할 수 있습니다.

기숙사에서 첫 자취방으로 옮겨갈 수 있는 학생용 홈랩
서비스를 특정 공간의 네트워크 환경과 분리하고, 하드웨어를 최소화하며, 상태를 백업하고, 깔끔하게 이전하는 과정을 미리 연습해 학생용 홈랩을 휴대하기 편하게 유지하세요.

계정이나 개인 파일을 공유하지 않고 룸메이트와 하나의 홈 서버를 공유하는 방법
모든 룸메이트에게 이름이 부여된 계정과 개인 저장 공간을 제공하고, 필요한 공유 역할만 부여하세요. 관리, 백업, 계정 정리는 별도로 처리하세요.



