🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 결론

Claude AI 웹사이트를 올바르게 배포하려면 런타임에 맞는 호스팅을 선택하고, 비밀정보를 분리한 뒤 GitHub 자동 배포와 운영 환경의 전체 기능 검증까지 완료해야 한다.

📌 핵심 요점

1. 배포 경로 판별: 프로젝트가 정적 사이트인지, Next.js·React·Vite 같은 Node.js 앱인지, Flask·Django·FastAPI 같은 Python 백엔드인지 먼저 확인해야 한다. 영상에서는 Node.js 앱은 Hostinger Unlimited 이상, Python 프로젝트는 VPS 경로가 필요하다고 설명한다.
2. 배포 전 사전 점검: 로컬 개발 서버에서 주요 기능이 정상 작동하는지 확인하고, 프로덕션 빌드까지 성공시켜야 한다. 로컬에서 발생하는 오류는 호스팅에 올린다고 자동으로 해결되지 않는다.
3. 비밀정보 보호: API 키와 자격 증명은 .env와 호스팅 환경변수에만 저장하고, .gitignore를 통해 GitHub 커밋에서 제외해야 한다. 특히 프런트엔드에는 공개용 키만 포함하고 관리자·서비스 역할용 비밀 키를 노출해서는 안 된다.
4. GitHub 기반 자동 배포: 프로젝트를 비공개 GitHub 저장소에 올리고 Hostinger와 연결하면, 이후 변경 사항을 푸시할 때마다 자동으로 새 빌드가 실행된다. Git 이력은 장애가 발생했을 때 정상 버전으로 되돌리는 복구 지점으로도 활용된다.
5. 운영 환경 검증과 진단: 홈페이지가 열리는지만 확인하지 말고 문의 양식, AI 기능, 예약, 대시보드, 데이터베이스 저장 등 모든 핵심 기능을 실제 도메인에서 시험해야 한다. 빌드 실패는 빌드 로그를, 배포 후 5xx·빈 화면·기능 무응답은 런타임 로그를 기준으로 진단한다.

🧩 배경과 문제 정의

• Claude로 만든 웹사이트가 로컬 컴퓨터에서만 실행되면 컴퓨터가 꺼진 동안 외부 사용자가 접속할 수 없다. 이를 공개 서비스로 전환하려면 상시 운영되는 호스팅 서버와 실제 도메인이 필요하다.
• 배포 방식은 프로젝트가 정적 사이트인지, 프레임워크 기반 앱인지, Node.js 런타임이 필요한지에 따라 달라진다. 로컬 실행 오류, 잘못된 빌드 설정, 누락된 의존성을 해결하지 않은 채 배포하면 운영 환경에서도 같은 문제가 이어질 수 있다.
• API 키와 데이터베이스 자격 증명을 코드나 GitHub 저장소에 포함하면 보안 사고로 이어질 수 있다. 따라서 로컬에서는 .env, 운영 환경에서는 호스팅 서비스의 환경변수 기능을 사용해 소스 코드와 비밀정보를 분리해야 한다.
• GitHub와 Hostinger를 연결하면 코드 변경 사항을 푸시할 때마다 자동으로 새 빌드와 배포가 실행된다. 배포 이력과 Git 변경 기록은 문제가 발생했을 때 마지막 정상 버전으로 되돌아갈 수 있는 복구 기반이 된다.
• 별도 검증 필요: Hostinger 요금제별 Node.js 지원 범위와 앱 개수 제한, 관리 화면의 메뉴명, DNS 반영 시간은 영상에서 안내된 내용이다. 실제 배포 시점의 정책과 화면에서도 동일한지 확인해야 한다.

🕒 시간순 섹션별 상세정리

1. 로컬 프로젝트를 공개 웹사이트로 전환하는 구조

• 로컬에서만 실행되던 사이트를 실제 도메인에 공개하기 위해 호스팅 설정, GitHub 연결, 도메인 연결, 자격 증명 등록, 자동 동기화를 하나의 배포 흐름으로 구성한다. [00:03]
• 영상에서는 Claude가 기술적인 작업을 담당하도록 프롬프트를 제공하고, 사용자는 주로 설정 버튼을 누르거나 준비된 명령을 복사해 실행하는 방식으로 진행한다. [00:24]

2. 런타임에 맞는 호스팅 요금제 선택

• 영상의 안내에 따르면 Node.js 기반 자바스크립트 웹사이트는 Premium 요금제로 호스팅할 수 없으므로 Unlimited 이상의 요금제가 필요하다. 실제 지원 범위는 가입 전에 다시 확인해야 한다. [02:16]
• Unlimited는 일반 웹사이트 수가 무제한이지만 Node.js 웹 앱은 계정당 5개로 제한된다고 보여준다. 5개를 초과할 계획이라면 Cloud Startup을 대안으로 제시한다. [02:44]

3. 프로젝트 프레임워크와 배포 호환성 확인

• Claude Code 데스크톱 앱의 작업 디렉터리를 실제 프로젝트 폴더로 지정해야 Claude가 파일 구조와 설정을 정확히 검사하고 배포 준비 작업을 수행할 수 있다. [05:06]
• 프로젝트가 순수 HTML·CSS·JavaScript로 구성된 정적 사이트인지, 특정 프레임워크를 사용하는 앱인지, Node.js에서 실행되는지를 묻는 프롬프트로 적합한 배포 경로를 판별한다. [05:16]

4. 로컬 실행·비밀정보·프로덕션 빌드 사전 점검

• 로컬에서 정상 작동하지 않는 프로젝트는 서버에 올린다고 해결되지 않으므로, 개발 서버를 먼저 실행한 뒤 주요 화면과 기능이 의도대로 동작하는지 확인한다. [07:02]
• API 키와 자격 증명은 프로젝트의 .env 파일에 저장해 코드와 분리하고, GitHub에는 소스 코드만 올리며 비밀정보는 저장소에서 제외한다. [07:24]

5. GitHub를 통한 자동 배포와 버전 관리

• GitHub에 변경 사항을 푸시할 때마다 Hostinger가 이를 감지해 자동 배포하도록 연결하면, 수정할 때마다 파일을 수동으로 다시 업로드할 필요가 없다. [09:20]
• GitHub의 변경 이력은 업데이트로 장애가 발생했을 때 마지막으로 정상 작동하던 버전을 찾아 되돌릴 수 있는 복구 지점 역할을 한다. [09:30]

6. 비공개 저장소 생성과 최초 인증

• Claude에 GitHub 사용자명을 전달하고 새 비공개 저장소 생성, 프로젝트 푸시, .env와 API 키를 제외할 .gitignore 구성을 요청한다. [10:53]
• 비공개 저장소는 코드 접근 범위를 제한하고, .gitignore는 로컬 비밀정보가 실수로 GitHub에 공개되는 것을 막는 안전장치로 사용한다. [11:17]

7. GitHub CLI 인증과 비공개 저장소 검증

• 터미널에서 gh auth login을 실행해 일회성 인증을 시작한다. Claude Code의 실행 버튼이 작동하지 않으면 명령어를 직접 복사해 터미널에 붙여 넣는다. [12:00]
• 인증 대상은 github.com, Git 작업 프로토콜은 HTTPS, 인증 방식은 웹브라우저 로그인을 선택한 뒤 일회용 코드를 입력해 GitHub CLI의 접근을 승인한다. [12:28]

8. Hostinger 사이트와 GitHub 저장소 연결

• Hostinger에서 새 사이트 생성을 시작한 뒤 일반 사이트 옵션 대신 고급 사용자용 Node.js 웹 앱을 선택한다. 영상에서는 해당 항목이 보이지 않을 경우 사이트 이전 절차에서도 찾을 수 있다고 안내한다. [14:32]
• 새 도메인을 등록하거나 기존 도메인을 연결할 수 있다. 외부 등록기관의 도메인은 Hostinger가 제시하는 DNS 설정을 적용해야 하며, 영상에서는 네임서버 변경에 최대 하루나 이틀이 걸릴 수 있다고 보여준다. [15:23]

9. 프레임워크 설정과 환경변수 가져오기

• 빌드 설정 단계에서 프레임워크 프리셋과 환경변수를 구성하고, Hostinger가 자동 감지한 프레임워크가 실제 프로젝트 구성과 일치하는지 점검한다. [16:52]
• 로컬 실행은 프로젝트 폴더의 .env 파일을 사용하지만 Hostinger 운영 환경은 관리 화면에 등록한 환경변수를 사용하므로, 필요한 값을 두 실행 환경에 각각 설정한다. [17:48]

10. 비밀 키 보호와 첫 배포

• 데이터베이스 인증정보에는 공개 사용이 허용된 키와 관리자·서비스 역할용 비밀 키가 있을 수 있으므로, 프런트엔드 프로젝트에는 공개용으로 지정된 키만 포함해야 한다. [19:19]
• 환경변수 값은 로컬 .env와 Hostinger 설정에만 저장하고 GitHub에는 커밋하지 않는다. .gitignore를 통해 로컬 비밀정보가 저장소에 유입되지 않도록 한다. [19:49]

11. 빌드 실패와 런타임 오류 진단

• 배포는 누락된 의존성, 잘못 선택한 프레임워크 프리셋, 운영 환경과 호환되지 않는 설정 파일 등의 이유로 실패할 수 있으며, 오류 유형에 따라 확인해야 할 로그가 달라진다. [20:47]
• 빌드가 실패하면 Hostinger의 빨간 실패 상태에서 빌드 로그 전체를 복사해 Claude에 전달하고, 로그에 기록된 실제 중단 원인을 기준으로 프로젝트를 수정한다. [21:14]

12. 운영 환경의 실제 기능 검증

• 홈페이지가 표시되는 것만으로 배포가 완료된 것은 아니다. 문의 양식, AI 기능, 예약 시스템, 대시보드 등 프로젝트의 핵심 기능을 실제 도메인에서 직접 실행해야 한다. [23:11]
• 영상의 테스트 프로젝트에서는 즉석 견적 기능에 야구공 크기의 벽 구멍 수리비를 질문해 AI 응답 생성과 데이터베이스 저장까지 이어지는 전체 흐름을 점검한다. [23:37]

13. 문의 흐름과 데이터베이스 저장 검증

• 생성된 견적 결과에는 예상 가격대와 설명, 사용자가 직접 수리를 시도할 때 참고할 수 있는 링크가 함께 표시되어 다음 행동을 선택할 수 있게 한다. [24:04]
• 실제 작업자 예약 버튼을 누르면 앞서 입력한 수리 정보가 문의 폼의 메모 필드로 자동 전달되어, 사용자가 같은 내용을 반복해서 입력하지 않아도 되는지 확인한다. [24:13]

14. Hostinger 대시보드의 운영·보안 기능

• 도메인 등록을 완료하려면 대시보드에 표시된 이메일 인증을 정해진 시간 안에 처리해야 하며, 받은 편지함의 인증 버튼을 눌러 절차를 마친다. [24:54]
• Deployments에는 성공과 실패를 포함한 배포 이력이 기록된다. Environment Variables에서 키, 서비스, 데이터베이스 설정을 변경하면 Hostinger가 사이트를 자동으로 다시 배포한다. [25:21]

15. GitHub 자동 배포와 캐시·롤백 처리

• 수정 규모와 관계없이 Claude에서 코드를 변경한 뒤 GitHub로 푸시하면 Hostinger가 후속 빌드와 배포를 처리하는 동일한 작업 흐름을 사용한다. 문제가 생기면 앞서 확보한 GitHub 변경 기록과 배포 이력을 복구 판단에 활용한다. [26:34]
• 홈페이지 헤드라인을 수정한 뒤 Claude Code에 커밋과 푸시를 요청하면 Hostinger가 자동으로 새 빌드를 시작한다. 영상 시연에서는 변경 사항이 약 2~3분 뒤 공개되는 과정까지 확인하며 전체 배포 흐름을 마무리한다. [27:23]

🧾 결론

• 올바른 배포는 단순히 코드를 서버에 올리는 작업이 아니라, 프레임워크 확인부터 로컬 테스트, 보안 점검, GitHub 연결, 환경변수 등록, 도메인 연결까지 이어지는 연속된 과정이다.
• 첫 배포에 성공했더라도 실제 사용자 흐름과 데이터 저장까지 확인하지 않았다면 운영 준비가 끝난 것으로 볼 수 없다.
• 수정 사항은 Claude에서 반영한 뒤 GitHub에 커밋·푸시하고, Hostinger의 자동 빌드 결과와 실제 도메인을 다시 확인하는 동일한 절차로 관리할 수 있다.
• 장애가 발생하면 빌드 실패와 런타임 오류를 구분해 해당 로그를 확인하고, 필요하면 Git 이력을 이용해 마지막 정상 상태로 복구해야 한다.

📈 투자·시사 포인트

• GitHub 연동형 자동 배포는 반복적인 수동 업로드를 줄이고 변경 이력과 롤백 경로를 남기므로, 소규모 웹 프로젝트에서도 운영 효율과 복구 가능성을 높이는 기반이 된다.
• 도메인·SSL·CDN·이메일·데이터베이스를 묶어 제공하는 호스팅은 초기 구성을 단순화할 수 있지만, 프로젝트 런타임과 앱 수 제한이 맞지 않으면 VPS나 다른 호스팅 경로가 필요할 수 있다.
• AI가 코드 작성과 배포 준비를 지원하더라도 GitHub 인증, 비밀 키 분류, 운영 기능 테스트처럼 사용자가 직접 승인하고 검증해야 하는 단계는 남는다.
• 배포 품질의 핵심 지표는 홈페이지 공개 여부가 아니라 핵심 기능의 정상 작동, 데이터 저장 성공, 로그를 통한 장애 추적 가능성, 정상 버전으로의 복구 가능성이다.
• 별도 검증 필요: 영상에서 제시한 Hostinger의 요금제별 Node.js 지원 범위, 계정당 앱 제한, 무료 도메인·메일 제공 조건과 가격은 변경될 수 있으므로 실제 가입 전 공식 최신 요금제와 약관을 확인해야 한다.

⚠️ 불확실하거나 확인이 필요한 부분

• Hostinger의 요금제 명칭, Node.js 앱 개수 제한, 무료 도메인·이메일 제공 조건은 영상 업로드 시점의 안내이므로 결제 전 공식 요금표와 약관을 다시 확인해야 한다.
• 지원 프레임워크, 자동 감지 범위, 기본 빌드 명령 및 Node.js 버전은 프로젝트와 Hostinger 환경에 따라 달라질 수 있으므로 실제 배포 설정에서 검증해야 한다.
• 외부 도메인의 DNS·네임서버 변경에 최대 하루나 이틀이 걸릴 수 있다는 설명은 일반적인 예상치이며, 실제 전파 시간은 등록기관과 DNS 환경에 따라 달라질 수 있다.
• 자막 기반 정리: 타임스탬프가 있는 자막을 기준으로 정리했으며, 고유명사·수치·인용은 원문 확인 필요 시 별도 검증한다.
• 영상 속 주장: 발표자의 해석·전망·비교는 확인된 외부 사실이 아니라 영상 속 주장으로 분리해 읽는다.
• 검증 필요: 수치, 기업 실적, 정책·시장 전망은 발행 전 최신 자료로 별도 검증이 필요하다.

✅ 액션 아이템

• 프로젝트가 정적 사이트, Node.js 프레임워크 앱, Python 백엔드 중 어디에 해당하는지 확인하고 호환되는 호스팅 경로를 선택한다.
• 로컬 개발 서버와 프로덕션 빌드를 실행해 주요 화면과 핵심 기능이 정상 작동하는지 점검한다.
• 클라이언트 코드에 관리자 키나 서비스 역할용 비밀 키가 포함되지 않았는지 전체 프로젝트를 검사한다.
• .env와 기타 자격 증명 파일이 .gitignore에 포함됐는지 확인하고, GitHub 저장소의 현재 파일과 기존 커밋 기록도 함께 점검한다.

❓ 열린 질문

• 배포하려는 프로젝트의 실제 프레임워크, Node.js 버전, 빌드 명령 및 시작 명령은 무엇인가?
• 브라우저에 노출해도 되는 공개 키와 서버에서만 사용해야 하는 비밀 키가 명확히 구분돼 있는가?
• .env 또는 API 키가 과거 Git 커밋에 포함된 적이 있으며, 포함됐다면 키 교체와 기록 정리가 필요한가?