호스팅 관리는 보통 개발을 방해합니다. 에디터에서 코드를 작성하고, 호스팅 대시보드를 열어 웹사이트를 만든 뒤, 터미널로 전환해 프로젝트를 패키징하거나 푸시하고, 다시 대시보드로 돌아가 배포를 검토하고, DNS, 로그 또는 서버 리소스에 주의가 필요할 때는 더 많은 도구를 엽니다.

Hostinger Connector는 이러한 컨텍스트 전환을 줄여줍니다. 이는 Hostinger 서비스를 Model Context Protocol(MCP)을 통해 AI 코딩 도구에 연결하여, 에디터를 벗어나지 않고도 AI 어시스턴트에게 지원되는 호스팅 리소스를 검사하거나 관리하도록 요청할 수 있게 합니다.

그건 편리하게 들립니다. 하지만 더 중요한 질문도 제기합니다: AI 어시스턴트를 실제 호스팅 작업을 정확하게 수행하도록 믿을 수 있을까요?

이를 알아보기 위해, 저는 VS Code와 GitHub Copilot에서 Hostinger Connector를 실제 Hostinger 계정과 함께 테스트했습니다. PulseWatch라는 작은 Express.js 애플리케이션을 사용해 설치부터 라이브 배포까지의 워크플로우를 따랐습니다. 또한 반복 배포, 빌드 기록, 로그, 그리고 애플리케이션의 시작 명령을 의도적으로 망가뜨린 뒤의 복구도 테스트했습니다.

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

Hostinger 방문

Hostinger Connector 장단점

평가 세부 점수

다음은 Hostinger Connector를 개발자가 사용 여부를 결정할 때 가장 중요한 영역인 비용, 기능 범위, 일상적 사용성, 실제 작업을 얼마나 정확하게 수행하는지, 그리고 문제가 생겼을 때 이를 뒷받침하는 지원을 기준으로 제가 매긴 점수입니다. 각 점수는 마케팅 페이지가 아니라 실제 테스트에서 확인한 내용을 반영합니다.

Hostinger Connector 플랜 및 가격

Hostinger Connector는 독립 제품으로 판매되지 않습니다. Hostinger는 Connector가 모든 플랜에 무료로 포함된다고 밝혔으며, 이는 Hostinger 청구서에 추가되는 별도의 월별 Connector 요금이 없다는 뜻입니다.

하지만 “무료”에는 맥락이 필요합니다. Connector는 Hostinger 리소스를 관리할 뿐이며, 이를 대체하지는 않습니다. 수행하려는 작업에는 여전히 적합한 Hostinger 호스팅, 클라우드, VPS, 도메인, 이메일 또는 기타 서비스가 필요합니다.

이 리뷰 시점에 Connector 랜딩 페이지는 Business Web Hosting과 Cloud Startup을 강조했습니다.

가격은 적용 가능한 세금 전 기준으로 표시되었습니다. 프로모션 가격과 갱신 요금은 바뀔 수 있으므로, 광고된 월별 금액만 보지 말고 현재 결제 총액을 확인하세요.

가격 인사이트: Connector를 쓰기 위해 더 높은 플랜을 구매하지 마세요. 필요한 웹사이트 수, 웹 앱 수, 필요한 리소스, 원하는 지원 수준에 맞춰 플랜을 선택하세요. Connector는 가격이 매겨지는 मुख्य 상품이 아니라 포함된 관리 계층입니다.

Hostinger는 적격 호스팅 구매에 대해 30일 환불 보장을 광고합니다. Connector에는 별도의 요금이 없으므로, 따로 평가할 Connector 환불 정책은 없습니다.

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

Hostinger 방문

기능

• Node.js 애플리케이션 배포
• PHP 및 HTML 배포
• WordPress 웹사이트 관리
• Website Builder 및 Horizons 워크플로우
• GitHub 연결 배포
• 도메인 연결 및 정리
• DNS 검사 및 업데이트
• SSL 및 웹사이트 진단
• 데이터베이스 관리
• VPS 설정 및 관리
• Docker 프로젝트 배포
• CPU 및 메모리 모니터링
• 대역폭 및 디스크 확인
• 서비스 및 컨테이너 재시작
• 악성코드 검사
• 백업 복원
• 이메일 캠페인 설정
• 배포 및 빌드 검사

정확히 어떤 작업을 사용할 수 있는지는 계정에 있는 Hostinger 서비스와 연결된 AI 클라이언트에 노출된 도구에 따라 달라집니다.

Hostinger는 또한 속도 제한을 문서화합니다. Connector FAQ에 따르면 기본 허용량은 분당 60 요청, 시간당 1,000 요청이며, 속도 제한 정보는 응답 헤더에 반환됩니다.

이 정도 제한은 대화형 사용에는 넉넉하지만, 자동화되거나 매우 반복적인 워크플로우는 불필요한 중복 호출을 피해야 합니다.

사용 편의성

1. 설치 및 인증

Hostinger Connector가 배포와 호스팅 관리를 잘 수행하는지 판단하기 전에, 먼저 실행하는 데 무엇이 필요한지 알아야 했습니다.

에디터 안에 머무는 것을 전제로 한 도구는 설정에 구성 파일 편집, API 토큰 생성, 반복 인증이 필요하면 금세 매력이 떨어집니다. 이 섹션은 설정만 다룹니다. 실제 작업 테스트는 그 다음에 나옵니다.

확장 프로그램 설치

저는 VS Code Marketplace에서 Hostinger Connector를 설치했습니다. “Hostinger”를 검색하자 첫 번째 결과로 나타났고, 게시자는 Hostinger Official로 표시되었으며, 첫 시도에 2분 이내로 설치되었습니다.

마지막 행은 주의가 필요합니다. 5점 만점은 강해 보이지만, 리뷰 샘플이 2개뿐이면 일반적인 사용자 경험에 대해 거의 말해주지 않습니다. 리뷰 원고에서 이 숫자에 의존하지는 않을 것입니다.

한 가지 예상 밖의 전제 조건이 있었습니다: Hostinger Connector는 Hostinger 도구를 제공하지만, 실제로 호출하려면 편집기에서 이미 활성화된 AI 에이전트가 필요합니다.

확장 프로그램 자체는 홀로는 아무것도 할 수 없습니다. VS Code에서는 현재 MCP 도구 호출을 위한 AI 인터페이스로 GitHub Copilot Chat이 사용됩니다. 저는 이미 Copilot을 활성화해 두었기 때문에 이 점이 크게 느려지지는 않았지만, 독자들은 Connector가 뒤에서 받쳐 주는 AI 에이전트가 있어야만 유용하다는 사실을 알아야 합니다.

이를 설치하고 로그인한 AI가 없다면 연결할 대상이 없습니다.

설치에 필요하지 않았던 것:

• API 키
• hPanel에서 복사한 토큰
• MCP 구성 파일의 수동 편집
• 로컬 저장 자격 증명
• 맞춤 서버 명령

확장 프로그램 자체 설치는 전체 테스트에서 가장 매끄러운 부분 중 하나였습니다. 유일한 실제 주의점은 Hostinger가 앞세우지 않는 의존 요소가 있다는 점, 즉 이 확장 프로그램이 작동하려면 에디터에서 활성 AI 에이전트가 필요하다는 점입니다.

확장 프로그램을 설치한 뒤에는 실제 계정에 연결하는 일도 이만큼 간단할지 확인해야 했습니다.

계정 연결

계정 연결은 “1-Click Connect” 버튼을 통한 OAuth 방식이었습니다. VS Code는 브라우저에서 Hostinger 인증 페이지를 열었고, 기존 Hostinger 세션을 감지한 뒤 hostinger-mcp라는 이름으로 표시된 것에 대한 접근을 승인해 달라고 요청했습니다.

Allow를 클릭하자 VS Code로 돌아왔고 “Connected via OAuth”가 표시되었습니다.

인증 화면은 Connector가 웹사이트, 호스팅, 도메인, 구독 및 기타 Hostinger 서비스를 관리할 수 있다고 알려 주었습니다.

그것은 범주 목록이지 권한을 하나하나 구분한 세부 내역은 아닙니다. “구독 관리”와 “웹사이트 관리”는 매우 다른 수준의 위험을 포함하므로, 여기에는 더 세분화된 정보가 있었으면 했습니다.

하지만 어느 정도 통제권은 확장 프로그램 안의 별도 패널에서 얻을 수 있었습니다. 이 패널은 모든 도구 범주를 나열하고 각각을 개별적으로 활성화 또는 비활성화할 수 있게 해주었습니다:

총 199개 도구 중 125개가 기본으로 활성화되어 있었습니다. 저는 이커머스와 VPS는 직접 테스트할 준비가 될 때까지 꺼 두었고, 확장 프로그램은 테스트 전반에서 그 경계를 존중했습니다.

이것은 Hostinger의 마케팅 페이지에는 나오지 않지만, AI 어시스턴트에게 얼마나 많은 계정 접근 권한을 줄지 결정하는 사람에게는 중요한 보안 세부 사항입니다. 저는 이것을 실제 강점이라고 보겠습니다.

계정 연결 해제는 같은 패널에서 가능하며, Hostinger 비밀번호를 변경하거나 저장된 토큰을 찾을 필요가 없습니다.

인증은 빠르고 토큰 관리가 필요하지 않았지만, 권한 화면은 세분화되기보다는 광범위했습니다. 실제 위험을 제한하는 데는 OAuth 화면보다 확장 프로그램 안의 범주별 도구 제어가 더 큰 역할을 합니다.

지원되는 편집기

Hostinger는 확장 프로그램의 온보딩 화면에서 확인한 다음 클라이언트를 지원한다고 안내합니다:

저는 VS Code와 GitHub Copilot을 주된 테스트 환경으로 사용했습니다.

설정은 Connector가 접근하기 쉽다는 것을 보여주었습니다. 하지만 아직은 연결 후 실제 작업을 얼마나 잘 수행하는지, 즉 더 어려운 질문에는 답하지 못했습니다. 그다음에 그 질문으로 넘어갔습니다.

2. Hostinger Connector 실전 사용

확장 프로그램을 설치하고 연결하는 것은 쉬운 부분입니다. 정말 중요한 것은 실제 호스팅 작업을 올바르게 수행하는지 여부이므로, 저는 작은 Express.js 애플리케이션인 PulseWatch를 만들고, 개발자가 설치 후 따를 법한 동일한 경로로 Connector를 시험했습니다: 계정 살펴보기, 배포 대상 찾기, 프로젝트 배포하기, 업데이트하기, 결과 확인하기, 그리고 일부러 일으킨 실패에서 복구하기입니다.

PulseWatch는 의도적으로 단순하게 만들었습니다. Express 서버, 홈페이지, package.json start 스크립트, 그리고 JSON을 반환하는 /api/health 엔드포인트로 구성했습니다. 이 health 엔드포인트는 나중에 중요해졌습니다.

호스팅 플랫폼은 완료된 빌드를 보고할 수 있지만, 애플리케이션은 시작 시 실패할 수 있습니다. 라이브 엔드포인트는 배포된 프로세스가 실제로 응답하는지 확인할 수 있는 독립적인 방법을 제공했으며, 상태 배지를 맹신하지 않게 해주었습니다.

계정 데이터 읽기

저는 AI 어시스턴트에게 라이브 변경을 허용하기 전에 읽기 전용 프롬프트부터 시작했습니다. 계정을 정확하게 설명할 수 없다면, 배포, DNS 또는 VPS 작업을 맡길 이유가 거의 없기 때문입니다.

Connector의 웹사이트 목록 도구는 다섯 개 사이트를 반환했습니다:

• webhostpro.io
• hostinger-monitor.hostadvice.com
• hostingermonitor.hostadvice.com
• blog.webhostpro.io
• red-lapwing-356282.hostingersite.com

실제 계정에는 그보다 더 많은 것이 있었습니다. hPanel에는 Premium, Business, Growth 플랜 전반에 걸쳐 웹사이트가 있었고, WordPress 사이트, PHP/HTML 사이트, Website Builder 프로젝트, 그리고 여러 임시 도메인이 포함되어 있었습니다.

활성 호스팅 플랜에 대해 별도의 프롬프트를 보내자 어시스턴트는 “하나의 활성 호스팅 플랜”이 있다고 말했습니다. hPanel에는 Premium, Growth, Business의 세 개가 보였습니다.

Connector를 공정하게 보자면, 제가 불일치를 지적하며 반박하자 그것은 스스로를 바로잡았고, 확인한 내용과 추정한 내용을 분명히 구분했으며, 틀린 주장을 반복하지 않았습니다.

그건 잘못을 우기는 것보다 나은 실패 모드이지만, 플랜 관련 질문에 대한 첫 답변은 그대로 받아들이면 안 된다는 뜻이기도 합니다.

읽기 전용 접근은 작동했지만, 계정 전체 질문에 대한 첫 답변은 불완전했습니다. 반박을 받자 바로잡았다는 점은 중요하지만, 제가 반박까지 해야 했다는 사실은 여전히 문제입니다.

계정 가시성의 그 공백은 더 큰 문제의 예고편이었습니다. 새로 만든 사이트를 찾으려 할 때 그 차이가 얼마나 중요한지 다음 테스트에서 확인할 수 있었습니다.

배포 대상 찾기

여기가 테스트에서 가장 많은 것을 드러낸 부분입니다. 저는 어시스턴트에게 방금 만든 Node.js 웹사이트를 도메인 이름을 알려 주지 않은 채 식별하라고 요청했고, 기존 사이트는 건드리지 말라고 했습니다.

대상 선택은 라이브 계정에 작동할 수 있는 도구의 기본 안전 요구 사항이므로, 깨끗한 답이 아니라 불확실성을 어떻게 처리하는지 보고 싶었습니다.

다음은 일어난 일의 순서입니다:

근본 문제는 이 두 ID가 호스팅 주문 ID가 아니라 도메인 리소스 ID였다는 점입니다. 실제 웹사이트 생성 도구를 호출하기 전에 그 차이를 확인하지 않았습니다.

제가 그것에 대해 설명을 요구하자, 어시스턴트는 결국 정확한 설명을 했습니다. 사용 가능한 웹사이트 목록 도구를 처음부터 가지고 있었음에도, hPanel로 새 사이트를 만든 뒤 다시 목록을 호출하지 않아, 검증되지 않은 도메인으로 빈틈을 메운 것이었습니다.

그 목록 도구를 다시 실행해 새 레코드가 있는지 확인하라고 직접 요청했을 때, 오히려 관련 없는 배포 조회 도구 세 개를 호출하고 “새 웹사이트가 나타나지 않았다”고 보고했는데, 실제로 실행한 도구 호출만 보아서는 그 결론을 뒷받침할 수 없었습니다.

이 일로 계정에 엉뚱한 웹사이트가 생기지는 않았습니다. 실패한 호출은 아무것도 남기지 않았습니다. 하지만 패턴은 분명히 짚어야 합니다. 불완전한 데이터 앞에서 어시스턴트는 빈틈을 그럴듯한 가정으로 채우고, 약한 신호를 강한 증거로 취급하며, 그 가정을 확인하기 전에 라이브 계정에서 행동했습니다.

이 섹션에서 가장 중요한 발견입니다. Connector는 대상을 추측하고, 그 추측을 근거로 행동하며, 멈춰서 묻지 않습니다. 여기서는 안전하게 실패했지만, 약한 신호를 사실로 취급하는 습관은 여러분의 계정에서도 주의해야 할 부분입니다.

Connector가 새 대상을 스스로 찾지 못하자, 남은 선택지는 제가 직접 대상을 만들고 그것이 변화를 가져오는지 보는 것뿐이었습니다.

hPanel에서 설정 완료

Connector가 새 대상을 안정적으로 찾지 못했기 때문에, Hostinger가 Connector 기반 배포 전에 무엇을 준비하는지 확인하기 위해 hPanel에서 수동으로 초기 설정을 마쳤습니다.

경로는 다음과 같았습니다: 새 사이트 만들기 → Node.js 웹 앱 → 임시 도메인 → Hostinger가 영국 데이터 센터를 자동 선택하고 예상 지연 시간 147ms 표시 → 세 가지 배포 방법 중 선택.

세 번째 화면은 따로 언급할 가치가 있습니다. Hostinger는 “Build with Hostinger Connector”를 GitHub 가져오기와 수동 파일 업로드 옆의 배포 방법으로 제공합니다. 저는 이것이 Connector 자체로 설정을 끝내 줄 것이라 기대하고 선택했습니다.

대신 이미 완료한 Connector 설치 페이지로 이동했습니다. 이것은 실제 온보딩 공백입니다. Connector 기본 경로처럼 제시된 옵션이 실제로는 아무것도 프로비저닝하지 않았습니다.

저는 돌아가서 대신 수동 파일 업로드를 선택했습니다. Hostinger는 제 프로젝트 아카이브(11.46 KB, node_modules 제외)를 받아들였고, 설정 화면은 정확한 자동 감지를 보여주었습니다:

• 프레임워크 프리셋: Express
• Node 버전: 22.x
• 루트 디렉터리: ./

Deploy를 클릭했습니다. 성공적으로 완료되었고, Hostinger는 orange-walrus-700988.hostingersite.com이라는 실제 임시 도메인을 할당했습니다. 이것은 Connector가 앞서 지어낸 도메인과는 다릅니다. 저는 홈페이지와 /api/health 를 직접 열어 둘 다 작동함을 확인했습니다.

제가 Connector가 대상 찾기를 기다리지 않고 수동 경로로 돌아가자, 그 경로는 마찰 없이 잘 작동했습니다. 이 화면의 “Build with Hostinger Connector” 버튼은 수정되거나 제거되어야 합니다. 현재로서는 하지 않는 일을 약속하고 있습니다.

이제 실제로 확인된 웹사이트가 존재합니다. 다음 질문은 Connector가 이제 확실한 대상을 갖게 된 뒤 다르게 행동할지였습니다.

라이브 애플리케이션 배포 및 업데이트

실제 확인된 웹사이트가 생긴 뒤, 저는 Connector로 돌아가 그 정확한 도메인을 검사해 달라고 요청했습니다. 이번에는 깔끔하게 작동했습니다.

이로써 중요한 사실 하나가 확인되었습니다. 앞선 실패는 대상 위치 파악과 새 대상 생성에 관한 것이었지, Node.js 사이트가 이미 존재할 때 Connector가 그것을 다루지 못한다는 뜻은 아니었습니다.

다음으로 저는 Hostinger가 가장 강조하는 기능, 즉 로컬에서 코드를 변경하고 hPanel을 열지 않고 게시하는 기능을 테스트했습니다.

어시스턴트에게 홈페이지 문구 한 줄을 “Monitor Every Service. Catch Every Issue.”에서 “Monitor Every Service. Resolve Issues Faster.”로 바꾸라고 요청했습니다.

전체 업데이트는 약 1분이 걸렸습니다. 어시스턴트는 제출 직후 새 배포를 “pending”으로 표시했는데, 이는 Hostinger가 아직 처리를 마치지 않았기 때문이었습니다.

제가 직접 라이브 사이트를 새로 고침했을 때는 이미 새 헤더가 반영되어 있었습니다.

그 뒤에 가져온 빌드 로그는 구체적이고 유용했습니다. 패키지 67개 추가, 68개 감사 완료, 취약점 0개 발견, 오류 없음.

확립된 사이트에 대해서는 이것이 Hostinger가 약속한 워크플로우에 거의 가깝습니다. 편집하고, 로컬에서 확인하고, 배포하고, 검증하는 과정이 에디터를 벗어나지 않은 채 약 1분 만에 끝납니다. 이번 테스트에서 가장 강력한 결과였습니다.

깨끗한 배포만으로는 행복한 경로만 작동한다는 뜻일 뿐입니다. Connector가 압박 상황에서 실제로 무엇을 하는지 보려면, 제가 일부러 앱을 망가뜨려야 했습니다.

실패 복구 테스트

도구가 신뢰를 얻으려면 깨끗한 데모가 아니라 실제 실패와 마주했을 때도 버텨야 합니다. 저는 Connector의 상태 보고와 로그가 실제로 문제를 진단하는 데 도움이 되는지 보려고 애플리케이션을 일부러 망가뜨렸습니다.

변경하기 전에, 어시스턴트는 package.json 을 package.json.bak로 백업했습니다. 그 자체로도 좋은 습관입니다.

그다음 시작 스크립트를 “start”: “node server.js” 에서 “start”: “node missing-server.js”로 바꾸게 했습니다. 존재하지 않는 파일입니다.

로컬 실행으로 실제 재현 가능한 실패가 확인되었습니다: Error: Cannot find module ‘…/missing-server.js’.

그 망가진 버전을 일부러 배포하여 Hostinger가 무엇을 보고하는지 확인했습니다.

Connector를 통해 접근할 수 있는 빌드 로그는 의존성 설치 성공만 보여 주었고 그 외에는 없었습니다. missing-server.js 런타임 오류는 그 안에 나타나지 않았습니다. 상태 배지만 보던 개발자는 사이트가 망가졌을 거라고 전혀 의심하지 못했을 것입니다.

복구는 순조로웠습니다. 어시스턴트는 백업에서 package.json 을 복원하고, 로컬에서 앱을 검증한 뒤, 배포를 다시 했고, 배포 상태만 믿지 않고 직접 라이브 /api/health 엔드포인트를 호출하여 수정 사항을 확인했습니다.

그 엔드포인트는 정상 응답을 반환했으며, 이는 테스트 전체에서 애플리케이션이 실제로 실행 중임을 증명한 유일한 증거였습니다.

이것이 두 번째 주요 발견입니다. 완료 상태가 작동 중인 애플리케이션의 증거는 아니며, Connector 자체 로그도 그것을 알려 주지 않습니다. 문제를 알고 나서 복구하는 과정 자체는 잘 작동했습니다.

상태 배지가 드러내지 못한 실패를 겪고 나자, Connector의 자신감이 실제 능력을 얼마나 앞지를 수 있는지 다른 부분도 알고 싶었습니다. 환경 변수가 다음 테스트였습니다.

환경 변수 구성 시도

저는 어시스턴트에게 무해한 환경 변수를 추가하라고 하고, 손대기 전에 이것이 전용 Connector 기능인지 확인한 뒤, 그렇지 않으면 멈추라고 했습니다.

사용 가능한 도구를 검색했지만 Node.js 환경 변수를 관리하는 전용 작업은 찾지 못했고, 코드나 배포 변경 없이 멈췄습니다.

이것이 이 테스트 전반에서 보고 싶었던 행동입니다. 실제 한계에 직면했을 때, 추측하지 않고 멈췄습니다. 이 테스트에서 전용 환경 변수 지원 작업이 노출되지 않았다는 것만 말할 수 있으며, Hostinger Connector에 환경 변수 지원이 전혀 없다고 단정하지는 않겠습니다. 

실패 및 복구 테스트 요약

신뢰성에 대한 테스트가 알려 주는 것

Hostinger Connector는 일상적이고 결정적인 작업을 잘 수행했습니다:

• 알려진 배포 기록 읽기
• 특정 파일 편집
• 로컬 명령 실행
• 프로젝트 패키징
• 알려진 웹사이트에 배포
• 빌드 상태 확인
• 사용 가능한 로그 조회
• 정상 버전 복원 및 재배포

불완전한 계정 데이터를 해석해야 하는 작업에서는 더 약했습니다:

• 새로 만든 웹사이트 식별
• 도메인 접근성과 웹사이트 존재를 구분
• 완료된 빌드가 앱이 정상인지 판단하는지 여부 확인

이 패턴은 어시스턴트에게 얼마나 많은 자율성을 줄지 결정할 때 유용합니다.

저위험 검사에는 더 넓은 프롬프트를 사용하세요. 라이브 인프라를 변경하는 작업에는 더 정확한 프롬프트와 명시적인 확인 요구를 사용하세요.

예를 들어, 다음과 같이 말하기보다:

다음과 같이 말하세요:

두 번째 프롬프트는 어시스턴트가 추측할 여지를 좁혀 줍니다.

사용 편의성에 대한 종합 판단

Hostinger Connector를 실행하는 일은 쉬웠고, 일반적인 설정 마찰도 거의 없었으며, 세밀한 도구 범주 제어 덕분에 AI가 무엇을 건드릴 수 있는지 실제로 제어할 수 있었습니다.

실제 웹사이트가 이미 존재하고 도메인이 알려져 있을 때는 그 작업을 잘 처리했습니다. 한 줄짜리 카피 수정이 약 1분 만에 편집에서 라이브 반영으로 이어졌고, 유용한 빌드 로그가 이를 뒷받침했습니다.

문제는 그보다 앞 단계에서 나타났지, 뒤 단계에서 나타난 것이 아니었습니다. 새 대상이 생겼는데 찾지 못하자, Connector는 도메인을 만들어 내고 확인하기 전에 그 도메인에 대해 행동했습니다. 또한 망가진 배포를 앱이 실제로 다운된 상태인데도 “완료됨”으로 표시했고, 자체 로그에는 런타임 오류가 없었습니다. 이 두 가지는 기존 사이트에 대해 도구가 신뢰할 수 없다는 뜻은 아니지만, 새 배포와 배포 후 상태는 신뢰하기 전에 한 번 더 확인해야 한다는 뜻입니다.

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

Hostinger 방문

지원 수준

Hostinger는 지원을 전화 대신 실시간 채팅과 셀프 서비스 중심으로 구성해 두었기 때문에, 저는 대부분의 사용자가 실제로 접하게 될 곳, 즉 hPanel에 내장된 AI 어시스턴트, 그 뒤의 인간 에스컬레이션, 그리고 디버깅 전에 개발자가 찾게 될 지식 기반에 중점을 두고 테스트했습니다.

지원 채널

실시간 채팅은 Hostinger가 긴급한 사항에 대해 개발자에게 안내하는 채널이고, 디버깅 중 실제로 사용될 가능성이 가장 높으므로, 저는 이메일 티켓을 제출하는 대신 그 경로를 직접 테스트했습니다.

실시간 채팅: Kodee와 인간 인계

저는 hPanel의 “Ask AI”를 통해 실시간 채팅을 열고, 답을 틀리기 쉬운 실제 질문을 Kodee에 던졌습니다. 즉, Node.js 배포에서 완료된 빌드 상태가 앱이 실제로 실행 중이라는 보장을 주는지, 그리고 그 반대를 증명하는 증거는 어디서 찾는지였습니다.

Kodee의 첫 답변은 구체적이고 정확했습니다:

“Completed”는 일반적으로 빌드 단계가 성공적으로 끝났다는 뜻일 뿐이며, 앱이 시작 후 정상인지까지 보장하지는 않습니다. 잘못된 시작 명령이나 다른 런타임 충돌을 잡으려면 런타임 로그를 확인하세요. hPanel에서 Websites → Dashboard → Deployments로 가서 빌드 로그를 보고, 그다음 nodejs 폴더 안의 stderr.log 을 열어 Port already in use 나 Module not found 같은 시작 오류를 확인합니다.

이 한 가지 답변만으로도 이 리뷰 앞부분의 실패 복구 테스트에서 발생한 정확한 모호함이 해결되었을 것입니다. Kodee는 실제 로그 파일, 올바른 폴더를 지목했고, 빌드 성공과 런타임 정상성 사이의 차이를 제대로 설명했습니다.

하지만 실제 사람에게 연결될 수 있는지도 보고 싶어서, 지원 엔지니어와 직접 확인하고 싶다고 Kodee에게 말했습니다.

그런데 사람을 연결받기는 예상보다 어려웠습니다. 저는 직접 라이브 에이전트를 요청했고, 그때마다 더 빨리 해결할 수 있다며 Kodee에게 되돌려졌습니다:

그 점은 이해합니다. 여기서 빌드, 시작 명령, 런타임 로그를 확인해 드릴 수 있는데, 보통은 이렇게 하는 것이 문제를 가장 빨리 찾는 방법입니다.

전문가를 연결하기 전에. 기다림 없이 문제를 해결해 드릴 수 있습니다.

Kodee가 자신에게 다시 설명해 보라고 되돌려 보내는 것을 멈추기까지는 두 번의 직접적이고 분명한 요청이 필요했습니다. 직접 해결 가능한 질문이라면 그 정도 마찰은 사소할 수 있습니다. 그러나 장애 대응 중인 사람이 사람과 이야기하고 싶을 때는 실제 불만 요소가 됩니다.

다음에 일어난 일은 보통 “사람에게 연결해 달라”는 요청이 의미하는 방식의 실시간 전달이 아니었습니다. Kodee는 실제 모델을 분명하게 설명했습니다:

귀하의 요청을 우리 팀의 전문가에게 전달했으며, 해당 전문가가 채팅을 직접 검토한 뒤 답변을 저에게 보내면 제가 이곳에서 전달해 드릴 것입니다.

이것은 실시간 전환이 아니라 비동기 검토입니다. Kodee가 인터페이스를 유지하고, 인간이 백그라운드에서 대화를 검토한 뒤 답변이 오면 Kodee가 이를 전달합니다. 대부분의 실시간 채팅 시스템에서처럼 새 사람이 채팅창에 합류하는 것이 아니라는 점은, 에스컬레이션을 결정하는 독자에게 중요합니다.

기다리는 동안 같은 기술 주제를 더 밀어붙여, 정확한 로그 경로와 stderr.log 가 항상 채워지는지 Kodee에 확인을 요청했습니다. Kodee는 자체적으로도 괜찮은 답을 주었고, 앱이 완전히 시작되지 않았거나 다른 곳에 오류를 남겼다면 로그가 비어 있을 수 있다고 올바르게 설명했습니다.

전문가의 검토는 약 3분 후 도착했고, 채팅에서 Mayas라는 팀원이 제공한 답변으로 표시되었으며, 단순 반복이 아니라 Kodee의 답변보다 더 정밀했습니다:

domains/[your-domain]/nodejs/stderr.log 가 올바른 위치입니다. 항상 생성되거나 채워지는 것은 아닙니다. uncaught exceptions나 unhandled rejections처럼 앱이 stderr에 쓰는 경우에만 항목이 나타납니다. 시작 명령이 잘못되어 프로세스가 조용히 종료되면 stderr.log 는 비어 있거나 없을 수 있습니다.

Mayas는 Kodee가 언급하지 않은 두 가지 대체 확인 방법도 추가했습니다: 크래시 직전의 마지막 출력을 확인하기 위해 stdout.log 를 살펴보고, 앱이 전혀 시작되지 않았음을 알리는 시작 확인 줄이 없는지 확인하는 것입니다.

Knowledge Base

Hostinger의 지식 기반은 Getting Started, hPanel, Website Builder, Hostinger Horizons, Domains, DNS, Files Management, Email, MySQL Databases, Website, VPS, Agency Hosting Plans, Hostinger Reach, SSL Certificates, PHP, Profile Management, Billing, Affiliates and Referrals, Features, cPanel, About Hostinger 같은 광범위한 제품 범주로 구성되어 있습니다.

그중 어떤 범주도 Hostinger Connector 전용은 아닙니다. 제가 올바른 문서를 찾은 유일한 방법은 “Hostinger Connector”를 직접 검색하는 것이었고, 그 결과 대부분은 애초에 간접적으로만 관련된 다섯 개의 결과가 나왔습니다. 여기에는 제휴 마케팅 플러그인 가이드와 일반 Node.js 호스팅 문서가 포함되었습니다.

실제로 Connector 설정을 문서화한 문서의 제목은 “How to Set Up Web Hosting MCP on Local IDEs”이며, Features → General Information 아래에 있습니다.

제품의 마케팅 이름으로 검색하면 찾을 수 있지만, 범주를 둘러보거나 Hostinger의 브랜딩을 모른 채 “MCP”로 검색한 독자는 놓칠 수 있습니다. 마케팅 이름과 문서상의 이름이 다르다는 점은 찾아보기 전에 알아둘 가치가 있습니다.

문서 자체는 일단 찾으면 훌륭합니다. 테스트하기 6일 전에 마지막으로 업데이트되었고, 다음 내용을 다룹니다:

• 확장 프로그램을 통한 권장 원클릭 OAuth 설정
• 확장 프로그램이 직접 지원하지 않는 IDE를 위한 API 토큰 기반 수동 설정 경로
• Mac, Linux, Windows용 정확한 구성 파일 경로
• 전체 JSON 구성 예시
• 연결이 제대로 되었는지 확인하는 단계별 검증 프롬프트
• 지원되는 어떤 클라이언트는 연결을 자동 감지하고, 어떤 클라이언트는 수동 구성 입력이 필요한지

마지막 항목은 제가 테스트 중 실제로 겪은 것과 일치했습니다. Devin Desktop은 자동 감지되지만, OpenAI Codex는 수동 방법이 필요합니다. 문서는 그 차이를 정확히 설명합니다.

지원에 대한 종합 판단

Kodee의 어려운 기술 질문에 대한 첫 답변은 정확하고 구체적이었으며, 모든 AI 지원 어시스턴트가 그렇게 잘하는 것은 아닙니다. 그것을 뒷받침하는 지식 기반 문서도 찾기만 하면 최신이고 상세합니다. 다만 제품의 마케팅 이름과 문서 제목이 일치하지 않으므로, 범주를 둘러보는 것보다 검색이 더 신뢰할 만한 방법입니다.

약한 점은 인간 에스컬레이션 경로입니다. Kodee는 사람을 요청하는 제 요구를 두 번이나 자기 자신으로 되돌렸고, 결국 “human agent”는 실시간 전환이 아니라 같은 채팅을 통해 전달되는 비동기 검토를 의미했습니다. 일단 사람이 검토하자 답변은 Kodee의 것보다 더 좋았고, 더 정확했으며, Kodee가 제시하지 않았던 추가 진단 단계 두 가지도 포함되어 있었습니다.

대부분의 질문에서는 Kodee만으로도 빠르고 정확한 답을 얻을 수 있습니다. 하지만 실제로 사람이 답변을 검증해 주길 원한다면, 한 번 이상 요청해야 할 가능성을 염두에 두고, 실시간 대화가 아닌 짧은 지연 후 전달되는 답변을 기대하세요.

Hostinger Connector Plans with Hostinger

Integrate Hostinger with the apps and services you already use to automate tasks, improve workflows, and manage your website more efficiently.

Hostinger 방문

최종 판단: Hostinger Connector를 사용할 가치가 있을까?

예, Hostinger에서 이미 호스팅 중이며 에디터 안에서 일상적인 배포를 처리하고 싶은 개발자라면 그렇습니다. 설정은 몇 분이면 끝났고, OAuth 덕분에 API 키가 필요 없었으며, 실제 웹사이트와 알려진 도메인이 있는 상태에서는 Connector가 약 1분 만에 라이브 업데이트를 배포했고, 이를 뒷받침하는 로그도 제공했습니다. Kodee 자체 지원 답변도 실제 기술 문제를 첫 시도에서 해결할 만큼 날카로웠습니다.

다만 주의할 점은 편의성이 아니라 신뢰입니다. 찾지 못한 새 대상에 대해서는 Connector가 도메인을 지어 내고 확인 전에 그 대상에 대해 행동했습니다.

또한 망가진 배포를 앱이 실제로 다운된 상태인데도 “완료됨”으로 표시했고, 자체 로그에는 런타임 오류가 없었습니다. 이미 존재하는 사이트의 작업을 빠르게 처리하는 데는 유용하지만, 새 대상에서 하는 일은 검증하고, 중요한 배포 뒤에는 직접 라이브 사이트를 확인하세요.

Hostinger

5.0

2,470 사용자 리뷰

₩2,160 /mo

시작가

Hostinger 방문

전문가 리뷰 기반 평점

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