tidoly PaaS 소개
클라우드처럼 편하게, 내 인프라에서
좋은 오픈소스는 이미 많습니다. 문제는 설치하는 것에서 끝나지 않는다는 것입니다.
데이터베이스를 연결하고, 계정을 만들고, 도메인을 붙이고, 인증서를 발급하고, 백업하고, 문제가 생기면 다시 살려야 합니다.
tidoly PaaS 는 이 일을 대신 처리합니다. 내 서버에 필요한 서비스를 올리고, 연결하고, 운영하는 일을 클라우드처럼 간단하게 만들어 줍니다.
오픈소스를 쓰고 싶지만, 운영이 문제입니다
오픈소스에는 좋은 서비스가 많습니다. Git 저장소, 채팅, 문서, 파일 저장소, 업무 시스템, 데이터베이스까지 필요한 거의 모든 것을 직접 구성할 수 있습니다.
하지만 서비스 하나를 설치할 때마다 따라오는 일이 있습니다.
- 서버를 준비해야 합니다.
- 데이터베이스를 연결해야 합니다.
- 로그인과 계정을 관리해야 합니다.
- 도메인과 HTTPS 를 설정해야 합니다.
- 서비스마다 필요한 자원을 확인해야 합니다.
- 백업과 복구 방법도 준비해야 합니다.
여러 서비스를 운영하면 이 작업이 계속 반복됩니다. 결국 서비스를 사용하는 시간보다 서비스를 운영하기 위한 시간이 더 커집니다.
tidoly 는 바로 이 지점을 줄이기 위해 만들어졌습니다.
이런 팀이라면 특히 잘 맞습니다
| 지금 겪고 있는 문제 | tidoly 가 하는 일 |
|---|---|
| 데이터를 외부에 둘 수 없습니다 | 자체 인프라 안에서 서비스를 운영하면서 클라우드처럼 관리할 수 있게 합니다 |
| 클라우드 비용이 부담됩니다 | 하나의 서버에서 여러 서비스가 자원을 함께 사용하도록 구성할 수 있습니다 |
| 서비스마다 구독과 계정이 늘어납니다 | 필요한 오픈소스를 한 곳에 설치하고 하나의 계정 체계로 관리합니다 |
| DevOps 를 전담할 사람이 없습니다 | 설치·연결·주소·인증서·백업 등 반복적인 운영 작업을 줄입니다 |
| 이미 여러 오픈소스를 사용하고 있습니다 | 흩어진 서비스와 자원을 한 곳에서 관리할 수 있게 합니다 |
결국 문제는 어떤 서비스를 쓸 것인가가 아니라, 그 서비스를 어떻게 계속 운영할 것인가입니다.
tidoly 는 서비스 자체를 대신 만드는 것이 아닙니다. 이미 잘 만들어진 오픈소스를 가져와 설치하고, 연결하고, 운영하기 쉽게 만드는 역할을 합니다.
무엇을 대신 처리하는지 하나씩 → 특장점
여러 서비스를 설치해도, 하나씩 관리하지 않아도 됩니다
예를 들어 팀에서 다음과 같은 서비스를 사용한다고 생각해 보세요.
Git 저장소 + 사내 채팅 + 문서 + 파일 저장소 + 데이터베이스
기존에는 서비스마다 설치 방법이 다르고, 계정도 따로 만들고, 필요한 데이터베이스와 저장소도 각각 연결해야 합니다. 팀원이 들어오면 여러 서비스에 초대해야 하고, 나가면 여러 곳에서 계정을 정리해야 합니다.
tidoly 에서는 필요한 서비스를 한 곳에서 설치하고 하나의 프로젝트 안에서 함께 관리할 수 있습니다.
특히 여러 서비스를 처음부터 한꺼번에 시작할 때 차이가 큽니다. 서비스마다 계정을 만들고 팀원을 따로 초대하는 대신, 설치한 서비스가 처음부터 하나의 계정 체계로 연결됩니다. 사람이 들어오고 나갈 때도 한 곳에서 관리하면 됩니다.
앱은 데이터베이스 주소를 몰라도 됩니다
tidoly 의 핵심은 단순히 서비스를 설치하는 것에 그치지 않습니다. 서비스와 서비스를 연결하는 일까지 대신합니다.
앱에서 데이터베이스를 사용한다고 해서 직접 주소·계정·비밀번호를 입력할 필요가 없습니다. 무엇에 연결할지만 선택하면 됩니다.
예를 들어 Gitea 를 설치하면 필요한 데이터베이스 스키마와 로그인 연동이 함께 연결됩니다.
| 받은 자원 | 제공 위치 | 상태 |
|---|---|---|
SCHEMA gitea_509655 | 설치된 PostgreSQL | BOUND |
OIDC_CLIENT gitea | 로그인 서버 | BOUND |
앱은 데이터베이스가 실제로 어디에 있는지 알 필요가 없습니다. 내 서버에 설치한 데이터베이스든, 기존에 사용하던 외부 클라우드 자원이든 앱이 연결되는 방식은 같습니다.
연결된 값이 바뀌면 앱이 다시 시작되고, 비밀번호 같은 민감한 값은 화면에 다시 노출되지 않고 앱에만 전달됩니다. 따라서 나중에 자원의 위치를 바꾸더라도 앱 코드를 수정할 필요가 없습니다.
그래서 운영은 이렇게 단순해집니다
tidoly 를 사용하면 복잡한 인프라 작업을 다음과 같은 흐름으로 줄일 수 있습니다.
서버 준비 → tidoly 설치 → 프로젝트 생성 → 서비스 선택 → 필요한 자원 연결 → 사용
서비스가 늘어나도 기본적인 방식은 같습니다. 데이터베이스가 필요하면 연결하고, 로그인이 필요하면 연결하고, 외부 서비스가 필요하면 등록합니다.
필요한 서비스를 선택하면 tidoly 가 서비스 사이의 연결과 운영에 필요한 작업을 처리합니다. 이것이 tidoly 가 말하는 "클라우드처럼 편하게, 내 인프라에서" 입니다.
서버 한 대로 시작할 수 있습니다
처음부터 복잡한 클러스터를 만들 필요는 없습니다. 베타에서는 서버 한 대를 기준으로 안내합니다.
| 시작 | 확장 |
|---|---|
| 서버 한 대에 필요한 서비스를 설치합니다 | 필요해지면 여러 서버로 확장할 수 있습니다 |
| 자원을 여러 서비스가 함께 사용합니다 | 클러스터 구축은 문의를 통해 지원합니다 |
| 백업하고 필요하면 복구합니다 | → 지원 범위 |
처음부터 큰 인프라를 만들기보다 서버 한 대에서 우리 팀의 스택이 실제로 돌아가는지 확인하는 것을 권장합니다. 필요해졌을 때 장비를 추가해도 늦지 않습니다.
서버를 꺼두면 그동안 서비스에 접속할 수 없지만, 다시 켜면 설치한 서비스와 데이터는 그대로 유지됩니다.
처음부터 전부 옮길 필요도 없습니다
tidoly 를 도입한다고 해서 기존 환경을 한 번에 바꿀 필요는 없습니다. 가장 부담이 적은 방법은 개발·스테이징 환경부터 시작하는 것입니다.
| 단계 | 무엇을 하나요? |
|---|---|
| 1. 먼저 올려봅니다 | 현재 팀에서 사용하는 개발·스테이징 환경을 tidoly 에 구성합니다 |
| 2. 직접 확인합니다 | 필요한 서비스가 모두 올라오는지, 운영에 얼마나 손이 필요한지 확인합니다 |
| 3. 하나씩 옮깁니다 | 충분히 검증한 서비스부터 prod 환경으로 옮깁니다 |
| 4. 필요할 때 확장합니다 | 서비스나 사용자가 늘어나면 그때 서버와 인프라를 확장합니다 |
개발 환경이라면 필요한 시간에만 서버를 켜두는 것도 가능합니다. 서버를 껐다 켜더라도 설치한 서비스와 데이터는 그대로 유지됩니다. 항상 외부에서 접속해야 하는 서비스만 계속 켜두면 됩니다.
설치부터 운영까지, 필요한 만큼만 하면 됩니다
tidoly 의 기본 설치 과정은 복잡하지 않습니다.
| 단계 | 무엇을 하나요? | 건너뛸 수 있나요? |
|---|---|---|
| 0 | 서버 준비 — Ubuntu 를 설치합니다 | Linux 서버가 이미 있다면 건너뜁니다 |
| 1 | 라이선스 발급 및 도메인 등록 — 사용할 주소를 정합니다 | 필수 |
| 2 | 시스템 설치 — 설치 마법사로 tidoly 를 설치합니다 | 필수 |
| 3 | 프로젝트와 상태 보기 — 작업 공간을 만들고 상태를 확인합니다 | 필수 |
| 4~5 | 묶음으로 설치하거나 서비스를 하나씩 설치합니다 | 필요한 만큼 |
| 6 | 내가 만든 앱 올리기 — Git 저장소를 연결하고 빌드·배포합니다 | 필요할 때 |
| 7~9 | 외부 서비스 등록 · 자원 연결 · 주소와 인증서 설정 | 필요할 때 |
| 10 | AI 도구로 앱 만들기 — 편집기의 AI 가 자원 설치부터 주소까지 만듭니다 | 필요할 때 |
| + | 오픈소스 소개 — 설치할 수 있는 오픈소스와 공식 사용법 | 필요할 때 |
필요한 장비도 크지 않습니다
이미 가지고 있는 서버가 있다면 그대로 사용할 수 있습니다. 여러 서비스를 함께 운영한다면 다음 정도의 사양을 권장합니다.
| 항목 | 권장 사양 |
|---|---|
| CPU | 8코어 |
| 메모리 | 8GB |
| 디스크 | 100GB |
빌드와 배포까지 같은 서버에서 처리한다면 메모리 10GB 이상을 권장합니다.
실제 필요한 사양은 설치할 서비스의 종류와 개수, 데이터 용량, 트래픽 등에 따라 달라질 수 있습니다.
비용도 줄일 수 있습니다
tidoly 를 사용하는 가장 큰 이유 중 하나는 여러 서비스를 하나의 인프라에서 함께 운영할 수 있다는 것입니다.
예를 들어 데이터베이스나 저장소처럼 여러 서비스가 함께 사용하는 자원은 서비스마다 별도의 관리형 서비스를 사용할 필요 없이 하나의 서버에서 필요한 만큼 나눠 사용할 수 있습니다. 이를 통해
- 서비스마다 발생하는 관리형 서비스 비용을 줄이고
- 여러 서비스의 인프라를 한 곳으로 통합하고
- 사용하지 않는 개발 환경은 서버를 꺼두고
- 필요한 만큼만 서버를 확장할 수 있습니다.
환경에 따라서는 기존 클라우드 비용의 1/10 수준까지 낮아질 수도 있습니다.
다만 실제 비용 절감 폭은 서버 사양, 트래픽, 데이터 용량, 백업 방식, 운영 방식 등에 따라 달라집니다.
직접 서버를 준비하기 어렵다면
서버를 직접 준비하는 것이 부담스럽다면 호스팅 구성 상담을 받을 수도 있습니다. 현재 사용 중인 클라우드 환경과 필요한 기능을 확인하고 다음을 함께 검토합니다.
- 어떤 서버 사양이 적합한지
- 현재 클라우드에서 무엇을 옮길 수 있는지
- 서버 한 대에 얼마나 통합할 수 있는지
- 이전 후 예상 비용이 어느 정도인지
- 직접 운영할 부분과 지원받을 부분을 어떻게 나눌지
| 문의 | info@tidoly.com |
|---|---|
| 상담 내용 | 서버 사양 선정 · 기존 클라우드 이전 · 설치 대행 · 클러스터 구축 · 운영 문의 |
어디까지 직접 하고 어디부터 지원받을 수 있는지 → 지원 범위
결국 tidoly 가 하는 일
tidoly 는 새로운 오픈소스를 만드는 서비스가 아닙니다. 이미 잘 만들어진 오픈소스를 내 인프라에서 쉽게 설치하고 연결하고 운영할 수 있도록 만드는 PaaS 입니다.
복잡한 인프라 작업은 뒤로 숨기고, 사용자는 필요한 서비스에 집중할 수 있도록 합니다.
서버를 준비하고 → tidoly 를 설치하고 → 필요한 서비스를 선택하면 됩니다.
데이터베이스가 어디에 있는지, 서비스끼리 어떻게 연결되는지, HTTPS 인증서를 어떻게 발급받는지와 같은 세부적인 작업은 tidoly 가 가능한 한 대신 처리합니다. 그 결과,
- 개발자는 서비스에 집중하고,
- 팀은 필요한 시스템을 직접 운영하고,
- 조직은 클라우드 비용과 운영 부담을 줄일 수 있습니다.
클라우드의 편리함이 필요하지만, 인프라까지 클라우드에 맡길 필요는 없습니다. tidoly PaaS 로 내 인프라에서 필요한 만큼 시작해 보세요.