Hostinger는 Web Apps Hosting 을 하나의 단순한 메시지로 내세웠습니다. GitHub, ZIP 파일, 또는 AI 코딩 에이전트에서 코드를 푸시하면, 관리할 서버 없이 약 1분 만에 실사용 가능한 프로덕션 앱이 실행된다는 것이죠. 그 약속이 실제로 어느 정도까지 맞는지 직접 배포 버튼을 눌러 확인해 보고 싶었고, 아래는 그 결과입니다.

Hostinger와 함께 Web Apps를 더 빠르게 배포하세요

자동 빌드, 관리형 인프라, 글로벌 CDN, SSL, 보안 도구, 30일 환불 보장과 함께 Hostinger에서 최신 웹 앱을 배포하세요.

Hostinger 방문

장단점

평가 세부 내역

Hostinger의 Web Apps Hosting 점수를 매기기 위해 HostAdvice의 평가 방법론을 적용했습니다. 이는 사이트의 모든 리뷰에 동일하게 사용되는 표준화된 방식으로, 마케팅 문구가 아니라 실제 테스트에 기반한 점수가 되도록 하기 위한 것입니다. 각 항목별 점수는 아래와 같습니다.

번거로운 DevOps 없이 Web Apps를 호스팅하세요

자동 배포, 관리형 SSL, 글로벌 CDN, 내장 보안을 갖춘 완전 관리형 호스팅으로 최신 웹 애플리케이션을 배포하세요.

Hostinger 방문

요금제 및 가격

Hostinger는 Web Apps Hosting을 Business 와 Cloud Startup 두 가지 계층으로 판매하며, 둘 다 전통적인 웹사이트 제작이 아니라 Node.js 및 최신 JavaScript 앱 배포를 위해 특별히 설계되었습니다.

내가 테스트한 Cloud Startup 요금제는 Business에 비해 앱 허용 개수와 CPU 코어 수가 두 배이며, 두 요금제 모두 체크아웃에 무료 도메인, 무료 비즈니스 이메일, 관리형 SSL이 첫 1년 동안 기본 포함됩니다.

주문 전에 알아둘 몇 가지 사항이 있습니다:

• 환불 보장: Web Apps Hosting은 Hostinger의 표준 호스팅 환불 조건에 따라, 구매일로부터 30일 동안 환불이 가능합니다. 이는 추가로 180일 쿨다운이 붙는 Hostinger의 VPS 요금제와는 확연히 다릅니다. 여기에는 그런 쿨다운이 적용되지 않습니다.
• 무료 체험: 별도의 무료 체험은 찾지 못했습니다. 대신 30일 환불 보장이 평가 기간 역할을 합니다.
• 결제 방법: 체크아웃에서는 카드 결제가 기본으로 표시되었고, Visa, Mastercard, Amex, Discover 로고가 보였으며, 다른 결제 수단을 추가할 수 있는 옵션도 있었습니다.
• 포함 항목: 1년 무료 도메인, 1년 무료 메일박스, 관리형 SSL이 추가 비용 없이 요금제 가격에 포함되므로, 표시된 가격은 실제로 보안이 갖춰진 배포를 실행하는 데 필요한 거의 전체 비용에 가깝습니다.
• 유일한 업셀: 이메일 마케팅 추가 옵션인 Hostinger Reach는 별도의 월 가격이 표시된 채 장바구니에 나타납니다. 쉽게 건너뛸 수 있고 기본으로 포함되거나 미리 선택되지 않습니다.

Web Apps Hosting 요금제를 30일 이내에 취소하면, Hostinger의 환불 정책상 제외 목록에 포함되지 않으므로 VPS나 도메인 구매에 붙는 추가 조건 없이 일반적인 30일 환불 대상에 해당합니다.

기능

• 프레임워크와 Node 버전 자동 감지
• 관리형 MySQL 데이터베이스 생성 도구
• 기본 활성화된 글로벌 CDN
• WAF 및 DDoS 보호 포함
• 일일 및 수동 백업
• 멀웨어 스캐너 및 취약점 검사
• 자동 배포가 가능한 GitHub 통합
• 무료 도메인, 이메일, SSL
• 고급 사용자를 위한 SSH 접근

코드에서 라이브 앱까지 Hostinger와 함께

관리형 인프라, 자동 배포, 일일 백업으로 GitHub 저장소를 연결하거나 프로젝트를 업로드해 온라인에 올리세요.

Hostinger 방문

성능

Web Apps Hosting은 완전 관리형이기 때문에, VPS 리뷰처럼 CPU, RAM, 디스크를 직접 벤치마크할 수 있는 셸 접근 권한이 제공되지 않습니다.

대신 측정할 수 있는 것은 배포된 앱 자체가 실제 전 세계 위치에서 얼마나 빠르게 로드되고 응답하는지입니다. 저는 두 대륙에서의 GTmetrix, 50개가 넘는 글로벌 일관성 확인, 그리고 Hostinger 자체 내장 속도 도구를 데스크톱과 모바일 각각에서 테스트했습니다.

테스트 대상 앱은 아래 사용 편의성 섹션에서 다루는 Next.js 배포본이며, ivory-llama-856835.hostingersite.com에서 실행 중이고 Cloud Startup 요금제(4 CPU 코어, 4096 MB RAM, 100 GB NVMe 스토리지), CDN 기본 활성화 상태입니다.

1. 두 대륙에서 테스트한 GTmetrix

결과가 한 번의 운 좋은 위치에서만 좋게 나온 것인지, 아니면 일관되게 유지되는지 보기 위해 서로 다른 지역에서 GTmetrix를 두 번 실행했습니다.

두 번의 실행 모두 Performance와 Structure에서 100% 만점을 기록했고, 어느 위치에서도 레이아웃 이동은 0, 블로킹 시간도 0이었습니다. 즉, 페이지 로드 중 브라우저의 주의를 끄는 요소나 화면을 흔드는 요소가 전혀 없었다는 뜻입니다.

정말 흥미로운 점은 서버가 실제로는 미국에 있는데도, Frankfurt가 Chicago보다 모든 타이밍 지표에서 더 빨랐다는 것입니다. 이 결과는 CDN을 고려하면 설명됩니다.

CDN이 활성화되어 있으면, 이 사례처럼 기본으로 켜져 있는 경우 방문자는 원본 서버에 직접 연결되지 않을 수 있습니다.

가장 가까운 캐시 엣지 노드에 연결되므로, 서버가 미국에 있어도 유럽의 테스트 지점이 미국보다 더 빠를 수 있습니다. 이는 Hostinger의 기본 활성 CDN이 단순한 마케팅 문구가 아니라 실제로 의미 있는 일을 하고 있음을 보여주는 실질적인 확인입니다.

2. 글로벌 일관성(Check-Host)

Check-Host가 제공하는 모든 체크포인트, 6개 대륙에 걸친 54개 지역에서 라이브 URL에 대해 HTTP 확인을 실행했습니다. 전체 결과는 다음과 같습니다:

성공한 모든 확인에서는 깨끗한 200 OK가 반환되었고, 오류나 부분 실패, 예기치 않은 리다이렉트는 없었습니다.

응답 시간은 CDN 캐시가 실제 거리에서 어떻게 동작하는지 분명하게 보여주었습니다:

유럽 체크포인트는 일관되게 가장 빠른 시간을 반환했으며, 일부는 50밀리초 미만이었습니다. 반면 어떤 엣지 노드와도 물리적으로 가장 멀리 떨어진 체크포인트인 Tokyo, Singapore, Ho Chi Minh City는 모두 유효한 200 응답을 돌려주었지만, 0.3초에서 0.8초 사이로 더 느렸습니다.

이는 CDN 기반 배포에서 기대되는 형태입니다. 엣지 근처에서는 빠르고, 멀리 떨어진 곳에서도 여전히 완전히 정상 동작합니다.

Kazakhstan, Romania, 그리고 네 개의 러시아 체크포인트 중 두 곳에서 발생한 네 번의 타임아웃은 Hostinger 인프라의 문제로 보지는 않습니다.

같은 국가의 다른 체크포인트는 성공했습니다(Saint Petersburg는 0.063s로 정상 응답, 반면 Moscow의 두 체크포인트는 타임아웃). 이는 배포된 앱의 문제라기보다 체크포인트 쪽의 지역 네트워크 필터링을 시사합니다.

3. Hostinger 자체 속도 도구, 데스크톱 및 모바일

Hostinger는 앱 대시보드 내부에서 자체 Page Speed 테스트를 실행하므로, 어느 한 쪽만 믿지 않기 위해 그 수치를 독립적인 GTmetrix 결과와 비교했습니다.

두 기기 유형 모두 100점을 받았고, 데스크톱 수치는 GTmetrix가 독립적으로 측정한 값과도 상당히 잘 맞았습니다. 두 개의 서로 다른 도구, 두 가지 서로 다른 측정 방식이 서로 일치한다는 점이 바로 핵심입니다.

모바일은 더 느린 연결과 약한 프로세서를 가정한 환경이므로 모든 타이밍 지표에서 더 느렸지만, 여전히 100 점수가 나올 만큼 실제 모바일 성능이 강력하다는 뜻입니다. 그냥 느슨한 채점 기준이 아니라는 의미입니다.

도구 자체에서 한 가지 불일치가 있었습니다. 점수는 데스크톱과 모바일 모두 깔끔하게 100인데, 아래 Diagnostics 패널은 network dependency tree, document request latency, avoiding multiple redirects 같은 항목에 문자 그대로 0점을, unused JavaScript와 legacy JavaScript에는 50점을 표시합니다.

이 낮은 세부 점수들이 전체 점수를 끌어내리지는 않았으므로, 배포에 문제가 있다기보다 실제로 존재하는 사소한 최적화 여지 정도로 보면 됩니다.

또한 Hostinger가 이 Diagnostics 옆에 띄워주는 “도움이 되는 링크”는 모두 WordPress용입니다. “WordPress 속도를 9가지 쉬운 단계로 개선하기”, “WordPress 사이트의 이미지를 최적화하는 방법”처럼 말이죠. 하지만 이건 WordPress가 전혀 없는 Node.js 앱입니다. 이는 이 제품에 맞춰 만든 콘텐츠가 아니라 공유 진단 템플릿이 남아 있는 것입니다.

성능에 대한 종합 결론

Hostinger와 함께 관리형 Web 앱 호스팅

Hostinger가 배포, 인프라, 보안, SSL, 백업, 글로벌 전송을 맡는 동안 앱 개발에 집중하세요.

Hostinger 방문

사용 편의성

저는 랜딩 페이지부터 체크아웃까지, 그리고 새 계정에서 완전히 작동하는 Node.js 배포까지 Hostinger의 Web Apps Hosting을 테스트했습니다.

그 과정에는 요금제 선택, 결제, 빌드 방식 선택, GitHub 연결, 그리고 빌드가 실시간으로 완료되는 모습을 확인하는 모든 단계가 포함되었습니다. 실제 경험은 다음과 같았습니다.

1. 가입

저는 Web Apps Hosting 랜딩 페이지에서 시작했는데, 여기에는 Start deploying라는 하나의 콜 투 액션만 있습니다.

이를 클릭해도 가입 양식이 열리지 않습니다. 바로 아래 요금제 섹션으로 스크롤되므로, 첫 번째로 하게 되는 결정은 계정 정보를 입력하는 것이 아니라 어떤 요금제를 구매할지입니다.

두 요금제는 나란히 표시되어 있었습니다:

저는 앱 허용 개수와 CPU 여유가 엔트리 티어보다 두 배인 Cloud Startup을 선택했습니다. 하나 작은 불일치도 짚어둘 만한데, 가격 페이지에서는 “Cloud Startup”으로 표시되지만 장바구니에 들어가면 같은 요금제가 “Startup plan”으로 표시됩니다. 기능상의 문제는 아니지만, 같은 체크아웃 흐름 안에서 이름이 다르게 나오는 셈입니다.

장바구니는 깔끔했습니다. 48개월 약정, 할인 금액, 1년 무료 도메인, 무료 메일박스를 보여주고, 한 개의 업셀인 Hostinger Reach 이메일 마케팅이 강조된 박스로 표시되어 있었지만 기본 선택은 아니었습니다.

저는 이를 건너뛰고 Continue를 눌렀고, 아무 문제 없이 진행됐습니다.

새 고객이라면 기존 고객이 아닌 경우, 결제 주소와 결제 페이지에 도달하기 전에 계정 생성 단계가 추가됩니다.

그 다음에는 청구 주소를 입력하고, 결제 수단을 선택한 뒤, 카드나 PayPal 또는 다른 옵션 중 하나로 결제하면 됩니다. Submit payment를 클릭한 지 몇 분도 지나지 않아 구매 확인 이메일이 도착했고, hPanel에 바로 접속되어 요금제가 이미 프로비저닝된 상태였습니다.

내 생각: 체크아웃은 짧고, 업셀은 숨은 건너뛰기 링크를 찾지 않아도 쉽게 거절할 수 있습니다. 다만 요금제 이름이 가격 페이지와 장바구니에서 다르게 표시되는 점은 작지만, 처음 구매하는 사람이라면 자신이 올바른 요금제를 선택했는지 다시 확인하게 만드는 요소입니다.

2. 대시보드

결제가 완료되면 Hostinger가 모든 제품을 관리하기 위해 자체적으로 만든 인하우스 컨트롤 패널인 hPanel로 이동합니다. 이는 새 Web App에만 특화된 페이지가 아닙니다.

가장 먼저 보이는 페이지는 Home이며, 상단에는 “Hi, [your name]! How can I help you today?”라는 AI 프롬프트 바와 입력창, 그리고 Get domain, Create website, Get email, Migrate site, Get VPS, Try email marketing 여섯 개의 바로가기 버튼이 있습니다.

아래로 스크롤하면 다음이 나옵니다:

• 기능 홍보 타일 AI Builder, 온라인 스토어 도구, 무료 비즈니스 이메일, AI 에이전트, 자동화 앱, 무료 도메인 청구 안내
• 할 일 체크리스트 Reach 설정 완료, 무료 이메일 청구, 무료 도메인 청구 등으로 유도
• Your business, 계정에 연결된 모든 사이트, 앱, VPS 인스턴스를 나열하는 목록으로, 각 항목에 Manage site 버튼이 있음
• VPS, 그 아래에 IP 주소, 상태, 만료일별로 VPS 인스턴스를 나열하는 별도 표가 있음

Agent 패널도 Home뿐 아니라 모든 hPanel 페이지의 오른쪽 상단에 고정되어 있습니다. 이는 동일한 Kodee 지원 도우미이지만, 여기서는 “Deploy my Node.js app”이나 “Harden VPS updates” 같은 미리 만들어진 프롬프트를 바로 실행할 수 있는 일반 작업 도구처럼 배치되어 있습니다.

Home는 앱이 이미 존재할 때는 실제로 유용합니다. Your business에 있는 모든 항목이 앱으로 바로 연결되기 때문입니다. 하지만 새 Web App을 만들거나 Setup 버튼에 접근하는 곳은 아닙니다. 그 작업을 하려면 왼쪽 사이드바를 통해 다른 경로로 들어가야 합니다:

1. Websites 를 왼쪽 사이드바에서 클릭합니다
2. 아래에 하위 메뉴가 펼쳐집니다: WordPress, AI Builder, Web Apps, PHP/HTML, Migrations
3. Web Apps 를 클릭합니다

이 클릭을 하면 Home과는 완전히 다른 화면으로 이동하며, AI 프롬프트 바가 아니라 실제 호스팅 요금제를 중심으로 구성되어 있습니다.

여기서는 보유한 각 요금제가 카드 하나씩을 차지합니다. 내 계정에서는 세 개의 카드가 세로로 쌓여 있었습니다:

Business 카드에는 이미 이전 테스트에서 생성된 활성 앱인 orange-walrus-700988.hostingersite.com도 아래에 표시되어 있었고, Tools와 Dashboard 버튼이 함께 있었습니다.

이것도 알아둘 만한 점입니다. Web App이 한 번 생성되면 그 카드에 이렇게 라이브 사이트가 직접 표시되는 행이 추가되며, Cloud Startup 카드도 설정을 마치면 바로 이런 모습이 됩니다.

내가 막 구매하고 아직 설정하지 않은 요금제는 Cloud Startup이었으므로, 그 카드에는 단일 Setup 버튼만 표시되었습니다. 이것이 실제로 Web App 생성 마법사를 시작하는 버튼이며, 처음 접속했을 때 보이는 Home 화면이 아니라 Websites → Web Apps 아래에만 나타납니다.

내 생각: hPanel은 올바른 화면을 찾고 나면 명확하지만, Web Apps Hosting에는 분명한 정문이 없습니다. Home에 도착하면 프롬프트 바와 바로가기만 보일 뿐, 앱 생성으로 가는 경로는 보이지 않으며, Websites를 클릭한 다음 Web Apps로 들어가야 Setup 버튼이 나타납니다. “1분 만에 라이브”를 내세우는 제품치고는 몇 번 더 클릭해야 하는 셈입니다. 하지만 그곳에 도착하면 요금제 카드가 깔끔하고 상태를 솔직하게 보여 주며, 이미 앱이 실행 중인 요금제는 카드에서 바로 확인할 수 있습니다.

3. 앱 배포

Setup 을 눌러 요금제 카드에서 시작하면 짧은 온보딩 흐름이 열립니다. Where would you like to start? 에서 Create a new site, Migrate an existing site, I hired someone to build my site 세 가지 옵션이 있으며, 저는 Create a new site를 선택했습니다.

그다음에는 How do you want to build your website? 화면으로 이동하며, 상단에는 초보자용 옵션 두 개, Hostinger AI Builder와 WordPress + AI가 있고, 아래에는 별도의 “for advanced users” 제목 아래 Node.js web app 과 PHP/HTML website 두 가지가 있습니다. Node.js web app을 선택해야 실제로 Web Apps Hosting 제품으로 들어가게 됩니다.

이는 제품 비교를 하는 사람에게 중요한 구조적 정보입니다. Web Apps Hosting에는 별도의 전용 가입 흐름이 없습니다.

AI Builder와 WordPress가 함께 들어 있는 같은 일반 사이트 생성 마법사의 한 분기일 뿐입니다.

저는 Node.js web app 옆의 원을 클릭한 뒤 Next를 눌렀습니다.

그 다음 과정은 다음과 같았습니다:

• 도메인 화면: 테스트 배포였기 때문에 실제 도메인 대신 Use temporary domain을 선택했습니다.

• 서버 위치 화면: Hostinger는 내 청구 국가와 가장 가까운 지역인 France를 미리 선택해 두었고, 167ms 지연 시간을 보여 주었습니다. United States 옵션으로 스크롤하면 364ms가 표시되어 두 배가 넘었습니다.

그럼에도 저는 United States, Massachusetts를 선택했습니다. 그리고 이 위치 선택기는 Hostinger의 모든 제품에서 동일하게 보여 주는 교훈이기도 합니다. 목록에서 가장 낮은 수치가 아니라, 실제 방문자가 어디에 있는지를 기준으로 선택하세요.

내 테스트 앱의 예상 사용자는 미국 기반이므로, 미국 서버가 프랑스 서버보다 실제 사용자에게 더 빠르게 서비스를 제공합니다. 화면에 보이는 숫자는 Hostinger의 테스트에 서버가 얼마나 빨리 응답하는지를 보여 줄 뿐, 실제 사용자에게 얼마나 빠를지를 뜻하는 것은 아닙니다.

• 배포 방식 화면: 주요 옵션 두 개, Import Git repository(Recommended 표시)와 Upload your files, 그리고 아래에는 Claude Code, Cursor, VS Code에서 Hostinger Connector를 통해 직접 배포할 수 있다는 안내가 있습니다. 저는 Import Git repository를 선택하고 Connect with GitHub를 눌렀습니다.

이미 로그인되어 있지 않았다면 실제 GitHub 로그인 창이 열리고, 이어서 Install & Authorize Hostinger라는 권한 화면이 나타나며 다음 중 하나를 선택하라고 합니다:

• 미래에 생성될 저장소까지 포함해 내가 소유한 모든 repositories에 설치, 공개 저장소에는 읽기 전용 접근
• 선택한 repositories만 개별적으로 설치하고, 부여되는 권한을 정확히 표시: actions, metadata, repository hooks에 대한 읽기 권한과 administration, code, pull requests에 대한 읽기 및 쓰기 권한. Install & Authorize를 클릭하면 GitHub는 자동으로 hPanel로 돌아갑니다.

그러면 Select Git repository to import 화면으로 이동하며, GitHub 계정에 연결된 모든 저장소가 스크롤 가능한 목록으로 나타나고 각 저장소 옆에 Deploy 버튼이 있습니다. 저는 이전에 푸시해 둔 테스트 저장소 hostadvice-webapps-test를 찾아 Deploy 옆 버튼을 눌렀습니다.

그 버튼을 누른 뒤 다음 페이지가 뜨기까지 진행 표시가 전혀 없는 상태로 약 30초가 걸렸습니다. 클릭이 제대로 인식되었는지 의심하게 될 정도였습니다.

그다음에야 로드되는 페이지의 제목은 Review build settings이며, 커밋하기 전에 앱이 어디에 배포될지 정확히 알려 줍니다: “Deploys to ivory-llama-856835.hostingersite.com.” 아래에는 아무것도 입력하지 않았는데도 다음이 자동으로 감지되어 있었습니다:

이 다섯 개 항목마다 옆에 Change 또는 Add 버튼이 있어서, 감지가 잘못되더라도 여기서는 아무것도 고정되지 않습니다.

저는 Environment variables 옆의 Add를 클릭해, 나중에 실제 실행 앱에 제대로 전달되는지 확인할 수 있도록 키-값 쌍 하나를 설정한 뒤, 대화상자의 Finish를 눌렀고, 이어서 페이지 하단의 मुख्य Deploy 버튼을 클릭했습니다.

빌드 확인

화면은 Deploying… 보기로 전환되며, “Deployment from GitHub”라는 라벨이 붙은 진행 바가 단계별로 올라갑니다. 저는 28%, 51%를 거쳐 완료로 가는 과정을 지켜봤습니다. 진행 바 아래에는 접을 수 있는 Build logs 패널이 있고, 펼치면 스피너가 아니라 실제 라이브 터미널 출력이 보입니다:

> hostadvice-webapp-test@1.0.0 build

> next build

▲ Next.js 16.3.1 (Turbopack)

✓ Running next.config.mjs took 22ms Creating an optimized production build …

배포 완료

빌드가 끝나면 Deployment completed! 화면으로 이동하며, 카드 안에 실제 작동 중인 앱의 라이브 미리보기 썸네일이 표시되고, 저장소 이름과 할당된 라이브 URL 요약이 함께 나옵니다.

이 페이지에서 바로 Go to dashboard를 클릭해 이후 관리를 진행할 수 있습니다.

내 생각: 자동 감지가 가장 인상적이었습니다. 프레임워크, 브랜치, Node 버전이 모두 수동 입력 없이 정확히 잡혔고, 실시간 빌드 로그 덕분에 진행 과정이 불투명하지 않았습니다. 유일하게 아쉬운 점은 설정 화면에 들어가기 전 약 30초 정도 멈추는 구간인데, 뭔가 멈춘 것처럼 느껴질 만큼 길었습니다.

4. 라이브 배포 확인

관리 도구를 살펴보기 전에, 배포가 실제로 되었고 작동하는지, 단순히 화면에 “Completed”라고만 표시된 것은 아닌지 확인하고 싶었습니다.

Deployment completed 페이지에서 대시보드의 미리보기 썸네일만 믿지 않고, 라이브 URL인 ivory-llama-856835.hostingersite.com으로 바로 들어갔습니다.

라이브 페이지는 앱이 의도한 그대로 표시했습니다:

• Server build time, 페이지가 오래된 캐시가 아니라 방금 새로 빌드된 것임을 보여 주는 라이브 타임스탬프
• 환경 변수 확인, 배포 화면에서 설정한 사용자 정의 변수가 대시보드가 아니라 실제 라이브 사이트에서도 올바르게 확인됨

그다음 앱 자체의 Ping the API route 버튼을 클릭했는데, 이는 단순한 정적 콘텐츠가 아니라 실제 백엔드 엔드포인트를 호출합니다. 응답은 깨끗한 JSON이었습니다:

json

{

  “status”: “ok”,

  “serverTime”: “2026-08-19T13:44:05.234Z”,

  “nodeVersion”: “v22.18.0”

}

이 응답은 생각보다 더 중요합니다. 페이지가 정상적으로 열린다는 것은 정적 파일이 업로드되었다는 사실만 보여 줄 뿐입니다.

API 호출이 실제로 작동한다는 것은 그 아래에서 실제 Node.js 서버가 돌아가며 진짜 요청에 응답하고 있음을 뜻합니다. 즉, “Node.js web app” 호스팅의 핵심인데, 이는 정적 파일 하나로는 쉽게 속일 수 있지만 버튼을 누르는 순간 정확히 생성된 라이브 서버 타임스탬프로는 속일 수 없습니다.

내 생각: 이 확인 절차는 이 플랫폼이든 비슷한 플랫폼이든 배포를 믿기 전에 꼭 하라고 권하고 싶은 방식입니다. 초록색 “Completed” 상태와 미리보기 썸네일은 빌드가 끝났다는 뜻일 뿐입니다. 라이브 URL로 들어가서 API 호출, 데이터베이스 읽기처럼 캐시된 정적 페이지로는 속일 수 없는 동적 작업을 실행해 보는 것이야말로 서버가 실제로 살아 있고, 당신이 만든 것을 제대로 실행하고 있음을 보여 줍니다.

5. Web App 관리

라이브 앱이 정상 동작함을 확인한 후, 저는 hPanel로 돌아가 이 제품의 실제 서버 관리 계층인 앱 자체의 관리 대시보드를 끝까지 살펴보았습니다. 이는 앞서 다룬 일반 hPanel Home 화면과는 별개의 것입니다.

대시보드 개요. 여기에 들어오면 네 개의 상태 배지가 한눈에 현재 상태를 알려 줍니다:

네 개 모두 기본적으로 초록색이었고, 따로 켤 것은 없었습니다. 그 아래에는 상태, 저장소, 작성자, 커밋, 배포 시각, 감지된 스택, Node 버전을 확인할 수 있는 Last deployment 카드가 있어, 로그를 깊이 파고들지 않고도 한눈에 검증할 수 있었습니다.

자동으로 실행된 Page Speed test도 있었고, 제가 따로 시작하지 않았는데도 라이브 사이트에 대해 데스크톱 99/100 점수를 반환해 있었습니다. 그 옆에는 데이터베이스 연결, 백업, 파일 관리자, 런타임 로그, 캐시로 가는 빠른 링크가 있는 Essentials 패널이 자리하고 있었습니다.

배포, 환경 변수, 로그. 이 부분은 세 개의 별도 페이지로 나뉩니다:

• Deployments 는 푸시, 작성자, 브랜치, 커밋 해시, 완료 상태의 전체 기록을 보관하며, 최신 것 하나만이 아니라 실제 기록으로 남습니다
• Environment variables 는 배포 중에 설정한 변수를 정확히 표시해, 한 번 설정 화면에서만 보이고 잊혀진 것이 아니라 저장되고 적용되었음을 확인시켜 줍니다
• Runtime logs 는 실제 서버 출력을 실시간으로 스트리밍하며, Next.js 시작 로그, ready 타임스탬프, 문제와 오류 수를 보여 줍니다. 제가 지켜보는 동안 두 값 모두 0이었습니다

보안. Malware Scanner는 “Your website is safe”라는 깨끗한 결과를 보여 주었지만, 한 가지 주의 문구도 분명히 적혀 있었습니다. 웹사이트 파일만 검사하며 데이터베이스 내용은 검사하지 않는다는 점입니다. 더 깊은 검사를 원하면 데이터베이스까지 포함하는 유료 정리 옵션도 있었습니다. Vulnerabilities 검사 역시 깨끗했습니다.

데이터베이스. 여기서 제품의 마케팅과 실제 사이에는 반드시 이해해야 할 차이가 있습니다. 요금제는 관리형 MySQL을 핵심 기능처럼 내세우지만, 실제로는 자동으로 아무것도 프로비저닝되지 않습니다.

Databases 섹션을 열면 수동 Create a New MySQL Database And Database User 양식이 보이며, 앱이 데이터베이스를 사용하려면 먼저 직접 이름을 지정해 생성해야 합니다. 저는 아래 Support 섹션에서 다룬 Kodee를 통해 이를 직접 확인했고, 답변은 분명했습니다. 관리형이란 Hostinger가 데이터베이스 인프라를 뒤에서 운영한다는 뜻이지, 앱이 바로 실행되는 순간 데이터베이스가 자동으로 생성된다는 뜻은 아니라는 것입니다.

고급 접근. Advanced 아래에는 SSH 접근이 있으며, IP, 포트, 사용자명이 제공되지만 기본적으로 Inactive 상태이고, 사용하려면 수동으로 Enable을 눌러야 합니다. File Manager에서는 이 앱의 파일만 볼지, 전체 호스팅 플랜의 모든 파일을 볼지 선택할 수 있습니다.

내 생각: 일상적인 대시보드는 매우 잘 정리되어 있습니다. 특히 보안과 배포 기록은 찾기 쉽고 정말 유용했으며, 문제 없는 런타임 로그와 깨끗한 멀웨어 스캔 덕분에 앱이 단순히 온라인인 수준이 아니라 실제로 건강하다는 확신이 들었습니다.

다만 인터페이스가 과장하는 부분은 데이터베이스 영역입니다. “managed MySQL”은 요금제 페이지에서 보면 앱이 살아나는 순간 바로 준비되어 있을 것처럼 보이지만, 실제로는 직접 만들어야 하는 관리 화면이라는 점입니다.

사용 편의성에 대한 종합 결론

Hostinger와 함께 구축, 배포, 확장하세요

GitHub 통합, 관리형 MySQL, 글로벌 CDN, 무제한 대역폭, 내장 보안 도구가 있는 Hostinger에서 최신 웹 앱을 호스팅하세요.

Hostinger 방문

지원 수준

저는 hPanel에 내장된 AI 도우미 Kodee를 통해 Hostinger의 Web Apps Hosting 지원을 테스트했고, 이어서 도움말 센터를 살펴보며 문의 없이 어느 정도까지 커버되는지 확인했습니다. Kodee는 구분해서 볼 만한 두 곳에 나타납니다. 하나는 공개 마케팅 사이트의 Ask AI이고, 다른 하나는 hPanel 내부의 어떤 페이지에서도 사용할 수 있는 Agent 패널입니다. 이 패널은 Web App 자체 대시보드에서도 바로 볼 수 있습니다.

1. AI 지원(Kodee)

저는 테스트 중 발견한 실제 공백을 바탕으로, 단순히 문서를 복붙해도 답할 수 있는 일반적인 질문이 아닌 두 가지를 물었습니다.

질문 1 은 배포 실패 시 동작과 환경 변수 적용 시점을 시험한 것으로, 이 플랫폼에 배포하는 모든 사람에게 실제로 중요한 프로덕션 문제입니다:

If my app’s build fails partway through a GitHub deployment, does the app revert to the last successful version automatically, or does it go down until I fix and redeploy? And can I set custom environment variables before the first deploy, or only after?

Kodee는 두 가지 모두에 대해 직접적이고 정확하게 답했습니다. 빌드가 실패해도 이미 실행 중인 앱이 있다면 그 앱은 마지막 성공한 버전을 계속 제공합니다. 첫 배포이고 되돌아갈 성공한 버전이 없다면, 앱은 문제를 수정하고 다시 배포할 때까지 내려가 있는 상태로 남는다고 명확하고 솔직하게 설명했습니다. 애매한 위로나 둘러대는 표현이 아니었습니다.

환경 변수에 대해서는 첫 배포 전에 배포 설정에서 미리 설정할 수 있고, 이미 실행 중인 앱의 경우에는 정확히 세 단계를 안내했습니다. Settings와 Redeploy를 열고, Environment variables에서 변수를 추가하거나 수정한 뒤 저장하고 다시 배포하라는 것입니다.

질문 2 는 내가 직접 대시보드를 살펴보며 발견한 두 가지 공백, 즉 “managed MySQL”이라는 표현과 수동 생성 양식의 차이, 그리고 SSH가 기본적으로 비활성화되어 있는 점을 시험했습니다:

This plan advertises managed MySQL, but the dashboard shows a manual ‘Create a New MySQL Database’ form rather than a database provisioned automatically. Is a database created for every Web App by default, or only if I create one myself? Also, SSH access is listed as available but shows as Inactive by default. If I never enable it, does that change anything about how my app actually runs, or is SSH purely an optional extra for advanced users?

Kodee의 답변은 내가 인터페이스에서 직접 확인한 내용과 정확히 일치했으며, 그것을 부드럽게 돌려 말하지도 않았습니다. 데이터베이스는 모든 Web App에 자동으로 생성되지 않으며, “managed”는 Hostinger가 데이터베이스 서비스와 인프라를 관리한다는 뜻일 뿐, 실제 데이터베이스 생성과 설정은 사용자가 같은 Create a New MySQL Database 화면에서 직접 해야 하고, 이후 연결 정보도 앱의 환경 변수에 직접 추가해야 한다고 설명했습니다.

SSH에 대해서는 비활성 상태로 두어도 앱의 실행, 배포, 데이터베이스 연결에는 아무런 영향이 없다고 확인했습니다. CLI 명령, 마이그레이션, 직접적인 파일 디버깅을 위한 선택적 도구일 뿐, 플랫폼이 배경에서 반드시 필요로 하는 기능은 아니라는 설명이었습니다.

내 생각: 두 답변 모두 내가 대시보드에서 이미 직접 확인한 내용과 일치했고, 애매하게 돌리지 않았습니다. 그것이야말로 지원 도구가 일반적인 스크립트를 읽는 것이 아니라 실제 제품 상태를 확인하고 있다는 증거입니다. 두 질문 모두 일반 FAQ를 복붙해서는 답할 수 없는 것이었고, Kodee는 각각 약 1분 내외로 구체적이고 구조화된 두 부분짜리 답변을 제공했습니다.

2. 지식 베이스

Hostinger의 지식 베이스는 카테고리 그리드로 시작되며, 총 20개 카테고리가 있고 각 카테고리에는 문서 수가 표시됩니다. 가장 큰 몇 가지는 AI Builder가 330개, VPS가 276개, Email이 127개, Website가 103개입니다.

Web Apps Hosting에는 전용 카테고리가 없습니다. 관련 콘텐츠는 Getting Started, hPanel, Website 등에 흩어져 있으며, 이는 VPS나 Email처럼 별도의 전용 공간을 기대한 사람에게는 실제로 중요한 발견입니다.

“Web Apps”를 직접 검색하면 71개의 결과가 8페이지에 걸쳐 표시되었습니다. 상위 결과는 직접적으로 관련된 것과 주변적이거나 거의 관계없는 것이 섞여 있었습니다:

• How to deploy apps built with Codex on Hostinger, 직접 관련 있음
• Hostinger AI Builder: How to create a web app in agentic mode, 인접하지만 다른 제품
• How to add a Node.js Web App in Hostinger, 직접 관련 있음
• How to install Flutter Web on a VPS at Hostinger, 다른 제품
• 몇몇 Website Builder 결제 수단 관련 문서(PayPal, WeChat Pay, BLIK), “web”과 “app”이라는 단어가 본문 어딘가에 함께 들어가 있다는 이유 외에는 관련 없음

상위 결과 중 하나인 How to deploy apps built with Codex on Hostinger를 열어 깊이를 확인해 보았습니다. 결과는 꽤 탄탄하고 체계적인 안내서였습니다. 지원되는 프레임워크를 앞부분에 나열하고, GitHub 가져오기와 ZIP 업로드 경로 모두에 대한 단계별 스크린샷, 빌드 설정 구성 예시 명령, 배포 후 파일 구조 설명, 데이터베이스 연결 마법사 설명, 취약점 모니터링 섹션, FAQ 블록까지 포함되어 있었습니다.

Codex 전용으로 쓰여 있지만, 기반 플랫폼은 일반 Node.js Web App 제품과 동일하므로 대부분의 내용이 직접 적용됩니다.

내 생각: 검색 결과 수는 겉보기엔 강해 보입니다. 하나의 검색어에 71개 결과가 나온다는 점은요. 하지만 그 양의 상당 부분은 비슷한 표현을 공유하는 다른 제품의 잡음입니다. 내가 실제로 연 문서는 품질 면에서 훌륭했습니다. 명확한 단계, 실제 스크린샷, 진짜 FAQ 섹션이 있었지만, 그 문서를 찾으려면 내가 실제로 배포하려던 것과 전혀 관련 없는 결과들을 지나쳐야 했습니다.

고객 지원에 대한 종합 결론

간단한 현대적 Web 앱 호스팅

React, Next.js, Vue, Node.js 및 기타 최신 애플리케이션을 서버나 복잡한 인프라를 직접 관리하지 않고 배포하세요.

Hostinger 방문

Hostinger Web Apps Hosting을 추천할까요?

네. 이 제품에서 가장 강한 부분은 배포 과정입니다. 내 스택, 브랜치, Node 버전을 정확히 자동 감지하고, 스피너 대신 실제 스트리밍 빌드 로그를 보여 주며, 앱은 내가 던진 모든 성능 테스트를 통과했습니다. 두 개의 서로 다른 대륙에서 GTmetrix 만점, 54개 지점 글로벌 확인의 깨끗한 결과, Hostinger 자체 도구에서 데스크톱과 모바일 모두 100/100을 받았습니다. Kodee도 추상적인 스크립트가 아니라 실제 기술 질문에 대해 정확하고 구체적으로 답했습니다.

주의할 만한 사소한 부분도 있습니다. “Managed MySQL”은 요금제 페이지에서는 앱이 살아나는 즉시 준비되어 있는 것처럼 보이지만, 실제로는 수동 생성 폼을 뜻합니다. 또한 대시보드에는 Web Apps Hosting으로 들어가는 명확한 진입점이 없어서, 먼저 Websites 안으로 들어가야 합니다.

프레임워크에 구애받지 않고 빠르게 배포하면서, 그에 걸맞게 성능이 검증된 인프라를 원하는 개발자라면 쉽게 추천할 수 있습니다. 결제 직후 모든 기능이 자동으로 켜져 있을 것이라고 기대하는 사람이라면, 데이터베이스를 직접 설정할 몇 분 정도는 여유를 두는 편이 좋습니다.

Hostinger

5.0

2,471 사용자 리뷰

₩2,130 /mo

시작가

Hostinger 방문

전문가 리뷰 기반 평점

• 사용자 친화성
  4.9
• 기술 지원
  4.9
• 기능
  4.8
• 신뢰도
  4.7
• 요금제
  4.5