Published on

koyeb free 무료 플랜 배포 구조와 선택 기준

Authors
  • avatar
    Name
    Indo Yoon
    Twitter

koyeb free는 Koyeb이 제공하는 무료 플랜을 가리키며, 소규모 백엔드 API나 실습용 서비스를 비용 부담 없이 배포해 볼 때 유용해요. 다만 무료 플랜은 유료 플랜과 같은 자원을 주지 않기 때문에, 어떤 제약이 있는지 먼저 확인하고 배포하는 편이 안전해요. 이 글은 공식 문서와 공식 가격 페이지에서 확인한 범위 안에서 무료 플랜의 구조와 배포 절차, 판단 기준을 정리해요.

한눈에 보기

  • Koyeb은 GitHub 저장소나 컨테이너 이미지를 올려 웹 서비스와 워커를 배포하는 관리형 플랫폼이에요. 서버를 직접 만들고 SSH로 들어가 설정하는 방식이 아니라, 빌드와 실행 환경을 플랫폼이 맡는 구조예요.
  • 무료 플랜은 소규모 API, 포트폴리오용 백엔드, 배포 흐름을 익히는 연습용으로 적합해요. 트래픽이 몰리지 않는 개인 프로젝트에 잘 맞아요.
  • 무료 서비스는 사용하지 않는 동안 잠드는 방식으로 자원을 아끼는 경우가 많아요. 그래서 오랜만에 들어온 첫 요청에서 지연이 생길 수 있어요.
  • 세부 한도와 과금 기준은 시점에 따라 바뀌므로, 배포 전에 공식 가격 페이지를 직접 확인하는 습관이 필요해요.
  • 유료 전환 시점은 동시 접속 규모, 상시 가동이 필요한지, 관리형 데이터베이스를 붙여야 하는지로 나누어 판단하면 정리하기 쉬워요.

무료 플랜과 유료 플랜 비교

아래 표는 공식 문서에서 설명하는 배포 모델을 기준으로, 무료 플랜과 유료 플랜의 차이를 개념 수준에서 정리한 것이에요. 실제 수치와 한도는 가격 페이지에서 확인해야 해요.

항목무료 플랜유료 플랜
사용 목적학습, 소규모 API, 개인 프로젝트운영 서비스, 상시 트래픽
서비스 슬롯정해진 무료 슬롯 안에서 운영필요한 만큼 추가
자원 할당낮은 CPU와 메모리 조합플랜에 따라 상향 조정
절전 동작미사용 시 잠들 수 있음상시 가동 중심
데이터베이스외부 무료 데이터베이스를 붙이는 구성이 일반적관리형 데이터베이스 연동
과금 방식무료 한도 초과 시 제한 또는 유료 전환사용량 기반 과금
운영 부담플랫폼이 빌드와 실행을 담당플랫폼 담당, 모니터링 선택지 확대

표에서 눈여겨볼 지점은 자원의 크기가 아니라 동작 방식이에요. 무료 플랜은 자원을 조금 주는 대신 절전과 제한된 슬롯으로 비용을 통제하고, 유료 플랜은 상시 가동과 확장성을 제공하는 쪽에 초점이 있어요. 그래서 "무료로도 충분한가"라는 질문은 자원 크기보다 트래픽 패턴으로 답하는 편이 정확해요.

무료 플랜으로 배포하는 단계별 방법

절차 자체는 유료 플랜과 크게 다르지 않아요. 무료 슬롯 안에서 서비스를 만들고, 빌드 방식과 실행 방식을 지정하고, 환경 변수를 넣은 뒤 배포 결과를 확인하는 흐름이에요.

저장소와 빌드 방식 정리

먼저 배포할 저장소를 정리해요. Koyeb은 GitHub 저장소를 연결해 빌드하는 방식과 미리 만든 컨테이너 이미지를 사용하는 방식을 모두 지원해요. 저장소를 쓰는 경우에는 빌드팩이 언어를 자동으로 감지하지만, 감지가 애매한 프로젝트라면 Dockerfile을 두는 편이 결과를 예측하기 쉬워요. 모노레포라면 서비스별로 루트 디렉터리를 지정할 수 있는지도 함께 확인해요.

포트와 시작 명령 지정

애플리케이션이 어떤 포트로 요청을 받는지 명확히 해야 해요. 플랫폼은 서비스로 들어오는 트래픽을 지정한 포트로 넘기기 때문에, 코드에서 포트를 하드코딩하기보다 환경 변수로 받아 쓰는 편이 안전해요. 시작 명령은 빌드 결과물 위치와 일치해야 하고, 마이그레이션이 필요한 경우에는 시작 스크립트에서 처리할지 별도 작업으로 뺄지 미리 정해 두는 편이 좋아요.

Koyeb에서 서비스 생성

콘솔에서 서비스를 만들고 저장소와 브랜치를 선택해요. 이때 서비스 유형을 웹 서비스로 둘지 워커로 둘지 정해야 해요. 웹 서비스는 외부 요청을 받고, 워커는 큐 처리처럼 요청 없이 도는 작업에 써요. 무료 슬롯이 정해져 있으니 어떤 역할을 무료로 돌릴지 먼저 정하고 만들면 슬롯을 아낄 수 있어요.

환경 변수와 시크릿 등록

데이터베이스 접속 정보, 외부 API 토큰, 세션 키는 코드가 아니라 플랫폼의 환경 변수로 넣어요. 값이 노출되면 안 되는 항목은 시크릿으로 분리하고, 저장소에는 예시 값만 남기는 습관이 필요해요. 환경 변수를 바꾸면 재배포가 필요하므로, 배포 직전에 한 번에 정리해 넣는 편이 반복 배포를 줄여요.

헬스 체크와 첫 배포 확인

서비스가 정상인지 판단할 수 있도록 헬스 체크 경로를 지정해요. 헬스 체크가 없으면 프로세스는 떠 있어도 요청을 처리하지 못하는 상태를 놓치기 쉬워요. 첫 배포 후에는 응답 코드와 로그를 함께 확인하고, 절전에서 깨어나는 구간에서 지연이 얼마나 생기는지도 체감해 두면 이후 판단에 도움이 돼요.

로그와 재배포

배포가 끝났다면 로그에서 시작 메시지와 오류를 확인해요. 빌드는 성공했는데 런타임에서 죽는 경우가 흔하기 때문에, 시작 로그와 첫 요청 로그를 같이 보는 편이 좋아요. 이후에는 브랜치에 푸시하면 자동으로 재배포되는 흐름을 쓰면 되고, 급한 수정은 콘솔에서 재배포로 처리할 수 있어요.

상황별 선택 기준

무료 플랜을 계속 쓸지 판단하는 기준은 트래픽의 모양이에요.

  • 개인 사이드 프로젝트 API: 호출이 하루에 몇 번 수준이라면 무료 플랜으로 충분해요. 절전으로 인한 첫 요청 지연은 감수할 수 있는 범위예요.
  • 포트폴리오와 데모: 시연 직전에 한 번 호출해 서비스를 깨워 두면 지연 문제를 줄일 수 있어요. 링크를 공개하기 전에 미리 호출하는 습관이 도움이 돼요.
  • 배치와 워커: 요청을 받지 않는 작업은 웹 서비스와 분리해 워커로 두면 관리가 쉬워요. 다만 무료 슬롯이 줄어드는 점은 고려해야 해요.
  • 상시 운영 서비스: 사용자가 언제 들어올지 모르는 서비스라면 절전은 곧 이탈로 이어져요. 이 경우에는 유료 플랜이나 다른 상시 가동형 호스팅을 검토하는 편이 맞아요.
  • 데이터가 중요한 서비스: 컨테이너의 파일 시스템은 재배포와 재시작에서 유지된다고 가정하면 안 돼요. 외부 관리형 데이터베이스나 오브젝트 스토리지를 붙이는 구성이 필요해요.

정리하면, 무료 플랜은 "가끔 호출되는 작은 서비스"에 강하고 "항상 켜져 있어야 하는 서비스"에는 약해요. 이 경계만 기억해도 선택이 훨씬 빨라져요.

주의할 점

첫째, 절전과 콜드 스타트를 전제로 설계해야 해요. 첫 요청이 느릴 수 있으므로 클라이언트 타임아웃을 너무 짧게 두면 실패로 보일 수 있어요.

둘째, 무료 한도는 고정된 값이 아니에요. 플랜 구성과 과금 기준은 공식 가격 페이지에서 확인해야 하고, 블로그에 남은 오래된 수치를 그대로 믿으면 안 돼요.

셋째, 아웃바운드 트래픽을 살펴야 해요. 이미지나 파일을 외부로 많이 내보내는 서비스는 무료 범위를 빠르게 넘길 수 있어요.

넷째, 로컬 파일 저장을 피해야 해요. 업로드 파일을 컨테이너 안에 두면 재배포 시 사라질 수 있으니, 오브젝트 스토리지로 분리하는 구성이 안전해요.

다섯째, 리전 선택을 가볍게 보면 안 돼요. 사용자와 가까운 리전을 고르면 지연이 줄지만, 데이터베이스가 다른 리전에 있으면 왕복 지연이 늘어나요.

여섯째, 시크릿 관리 규칙을 정해야 해요. 저장소에 값을 커밋하는 사고는 대부분 급한 배포 과정에서 생기므로, 환경 변수 등록 절차를 문서로 남겨 두는 편이 좋아요.

자주 묻는 질문

koyeb free 플랜으로 상시 운영할 수 있나요?

기술적으로 배포는 가능하지만 권장하지는 않아요. 무료 서비스는 미사용 시 잠들 수 있어 첫 요청 지연이 생기고, 이는 사용자 경험에 바로 영향을 줘요. 항상 켜져 있어야 하는 서비스라면 유료 플랜이나 상시 가동형 호스팅을 검토하는 편이 맞아요.

무료 플랜에서 데이터베이스는 어떻게 쓰나요?

Koyeb은 관리형 데이터베이스 서비스를 별도로 제공하며, 무료 플랜에서 이를 그대로 쓰는 구성은 일반적이지 않아요. 보통은 외부의 무료 데이터베이스나 직접 운영하는 인스턴스를 환경 변수로 연결해요. 연결 정보는 반드시 시크릿으로 넣고 저장소에는 남기지 않아요.

카드 등록 없이 시작할 수 있나요?

결제 수단 등록 여부와 무료 한도는 계정 상태나 시점에 따라 달라질 수 있어요. 가입 화면과 공식 가격 페이지에서 직접 확인하는 것이 가장 정확해요. 무료로 시작했더라도 한도를 넘기면 서비스가 제한되거나 유료 전환이 필요할 수 있어요.

무료 서비스가 잠들면 어떻게 되나요?

요청이 들어오면 다시 깨어나 서비스를 시작해요. 이 과정에서 지연이 발생하고, 시작 시간은 애플리케이션의 부팅 속도에 따라 달라져요. 부팅이 느린 프레임워크라면 시작 시간을 줄이는 최적화를 함께 고려하는 편이 좋아요.

유료 전환 시점은 어떻게 판단하나요?

동시 접속이 늘어 응답 시간이 흔들릴 때, 절전이 사용자 이탈로 이어질 때, 관리형 데이터베이스가 필요할 때가 전환 신호예요. 반대로 호출이 드문 내부 도구라면 무료 플랜을 계속 쓰는 편이 합리적이에요.

출처

무료 플랜에서 유료 플랜으로 넘어가는 판단은 결국 운영 지표로 정리돼요. 응답 시간과 오류율, 절전에서 깨어나는 빈도를 함께 보고 있다면 배포 파이프라인 점검 글에서 이어서 확인할 항목을 정리해 두었으니 같이 읽어 보시면 좋아요.