Git, Docker 이미지, 데이터베이스, 미리보기 앱을 위한 홈 개발 서버 구축 방법

Eva Wong 는 테크니컬 라이터 이자 상주 메이커 로 ZimaSpace에서 활동합니다. 평생 기술을 사랑해 온 그녀는 홈랩과 오픈 소스 소프트웨어에 열정을 품고 있으며, 복잡한 기술 개념을 누구나 이해하기 쉬운 실습 가이드로 풀어내는 데 전문성을 갖추고 있습니다. Eva는 셀프 호스팅이 어렵고 부담스러운 일이 아니라 즐거워야 한다고 믿습니다. 그녀는 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 어려움을 풀어내고, 첫 NAS를 조립하는 것부터 Docker 컨테이너를 능숙하게 다루는 것까지 도전하도록 돕습니다.

안정적인 서비스 기반을 구축하고, 영구 데이터와 다시 만들 수 있는 아티팩트를 분리하며, 호스트 자체를 보존하지 않고도 모든 개발자 서비스를 복구할 수 있게 하세요.

집에서 개발자 한두 명이 사용하는 경우, Linux 서버 하나에서 Git, 이미지 레지스트리, 데이터베이스, 미리보기 애플리케이션을 호스팅할 수 있습니다. 서비스가 서로 의존하기 전에 사용자 인증, 스토리지 역할, 네트워크 노출, 백업, 복구를 계획해야만 설계를 관리하기 쉽게 유지할 수 있습니다.

하드웨어를 선택하기 전에 서비스 역할을 정하세요

Git, 컨테이너 레지스트리, 데이터베이스 엔진, 미리보기 애플리케이션은 한 호스트를 공유하더라도 별도의 서비스 역할로 취급하세요. Git은 소스 이력을 보존하고, 레지스트리는 다시 만들 수 있는 아티팩트를 저장하며, 데이터베이스는 변경 가능한 애플리케이션 상태를 보관하고, 미리보기 앱은 필요할 때마다 폐기할 수 있는 런타임입니다.

동시 빌드 수, 데이터베이스 작업 데이터 크기, 활성 미리보기를 기준으로 CPU와 메모리를 산정하세요. 저장 공간은 저장소, 레지스트리 보존량, 데이터베이스 증가량, 로그, 백업 준비 공간을 기준으로 산정하세요. 이렇게 하면 메모리가 먼저 병목이 되는데도 대용량 디스크를 구매하는 일을 피할 수 있습니다.

개발 환경에서 노드 장애를 감당할 수 있다면 처음에는 컴퓨팅 노드 하나를 사용하세요. 컴파일 작업이 몰려 데이터베이스나 대화형 미리보기의 성능이 저하되기 시작하면 빌드 워커를 분리하세요.

영구 데이터, 다시 만들 수 있는 데이터, 복구 데이터를 분리하세요

데이터 역할 예시 보호
영구 상태 데이터 Git 저장소, 데이터베이스 볼륨 스냅샷 및 별도의 백업
다시 만들 수 있는 아티팩트 컨테이너 이미지, 빌드 캐시 보존 정책, 선택적 백업
비밀 정보 및 구성 배포 키, 환경 파일 암호화된 내보내기 파일 및 오프라인 복구 사본
복구 미디어 OS 설치 프로그램, 복구 메모 서버 외부에 저장

모든 바이트를 똑같이 백업하지 마세요. 레지스트리는 대개 소스와 빌드 지침으로 다시 만들 수 있지만, 데이터베이스는 그렇지 않습니다. 데이터베이스 덤프나 일관된 스냅샷은 실행 중인 데이터베이스 볼륨과 별도로 저장하세요.

실용적인 셀프 호스팅 백업 계획은 NAS 자체를 백업이라고 여기는 대신 Git 자동화와 외부 사본을 별개의 작업으로 처리하는 것이 왜 중요한지 보여 줍니다.

비공개 접속 경로 하나 만들기

서버에 안정적인 LAN 주소와 로컬 DNS 이름을 지정하세요. Git, 레지스트리, 데이터베이스, 프리뷰 경로는 필요한 네트워크에서만 접근할 수 있도록 설정하세요. 원격 접근은 여러 서비스 포트를 포워딩하는 대신 사설 VPN이나 인증된 리버스 프록시 경로를 통해 허용해야 합니다.

별도의 서비스 계정과 배포 키를 사용하세요. 개발자가 관리자 비밀번호를 공유해서는 안 되며, 프리뷰 앱에 Git 저장소나 레지스트리를 수정할 수 있는 인증 정보를 물려주지 마세요.

공유 마운트가 꼭 필요한 파일 작업에만 SMB나 NFS를 사용하세요. SMB와 NFS 클라이언트 적합성 가이드를 참고하면 프로토콜 선택과 애플리케이션 서비스 접근을 별도로 고려할 수 있습니다.

배포 순서를 의존성 그래프에 맞추세요

스토리지 마운트, ID 관리, 데이터베이스, 레지스트리, Git, 프리뷰 앱 순서로 시작하세요. 애플리케이션이 아직 준비 중이라는 이유만으로 느린 데이터베이스를 재시작하지 않도록, 상태 확인은 실제 의존성을 테스트해야 합니다.

배포 정의, 스키마 마이그레이션, 리버스 프록시 경로는 버전 관리에 보관하세요. 비밀 정보는 저장소 밖에 두고 복원 위치를 명확하게 지정하세요. 대체 호스트는 정의와 보호된 상태 데이터만으로 서비스를 재현할 수 있어야 합니다.

깨끗한 체크아웃 상태에서 프리뷰 앱 하나를 다시 빌드하고, 이미지를 가져오고, 테스트 데이터베이스를 복원한 뒤, 의도한 클라이언트 경로에서 앱에 접근해 검증하세요.

수집이 아닌 복원을 위한 백업

저장소, 데이터베이스 네이티브 덤프, 서비스 설정, 암호화된 비밀 정보를 모든 서비스가 쓰기 마운트할 수 없는 대상으로 백업하세요. 서버의 전원 및 관리자 권한 범위 밖에도 사본을 하나 이상 보관하세요.

분기마다 격리된 네임스페이스에 복원하세요. 파일이 있는지만 확인하지 말고 사용자, 확장 프로그램, 예약 작업, 저장소 권한, 레지스트리 인증, DNS 경로까지 확인하세요.

빌드 대기열 때문에 대화형 작업이 지연되거나, 이미지를 푸시하는 동안 데이터베이스 지연 시간이 늘어나거나, 백업 시간이 업무 시간과 겹치면 확장하세요. 실험용 서비스 하나가 안정적인 서비스 영역에 필요한 리소스나 인증 정보를 고갈시킬 수 있다면 같은 호스트에 역할을 더 추가하지 마세요.

최종 설정 규칙

각 서비스에 명확한 역할이 있고, 상태 데이터가 보호되며, 접근 경로가 통제되고, 복원 테스트를 마쳤으며, 토폴로지를 분리하거나 확장할 측정 가능한 기준이 있으면 설정이 제대로 된 것입니다.

NAS 및 서버 설정

더 읽어보기

Get More Builds Like This

Stay in the Loop

Get updates from Zima - new products, exclusive deals, and real builds from the community.

Stay in the Loop preferences

We respect your inbox. Unsubscribe anytime.