Insights
AI가 자동으로 큐레이션·번역·정리하는 기술 동향 피드입니다.
CrescoDB는 개발자가 배포 후에도 애플리케이션의 상태를 완벽하게 파악할 수 있도록 프로덕션 모니터링 기능을 업데이트합니다. 이 기능은 경로별 오류 그룹화, p95 지연 시간, 느린 쿼리 추적 등 운영 가시성을 제공하여 문제 발생 시 디버깅 과정을 간소화하는 데 중점을 둡니다.
AI 자동 생성 콘텐츠
본 콘텐츠는 Dev.to AI tag의 원문을 AI가 자동으로 요약·번역·분석한 것입니다. 원 저작권은 원저작자에게 있으며, 정확한 내용은 반드시 원문을 확인해 주세요.
원문 바로가기백엔드를 구축하는 것은 작업의 일부일 뿐입니다.
데이터를 정의하고, API를 구축하고, 애플리케이션을 연결하고, 테스트한 다음, 결국 배포합니다. 여러분의 애플리케이션은 라이브 상태가 됩니다. 사용자들은 그것에 접근할 수 있습니다. 모든 것이 작동하는 것처럼 보입니다.
그러다가 무언가가 고장납니다.
어떤 경로(route)가 서버 오류를 반환하기 시작합니다. 쿼리가 예상치 못하게 느려집니다. 서버의 디스크 공간이 부족해지기 시작합니다. 애플리케이션이 응답을 멈추고, 누군가 보고하기 전까지는 알아차리지 못합니다.
문제는 반드시 무언가가 고장났다는 것이 아닐 수도 있습니다. 소프트웨어는 고장납니다. 문제는 무슨 일이 일어났는지 찾아내고, 어디서 발생했는지 식별하며, 수정하는 데 충분한 정보를 얻는 것입니다.
이것이 CrescoDB에서 작업하고 있는 개발자 경험의 다음 부분입니다.
저희가 곧 업데이트할 내용은 프로덕션 모니터링과 배포 후 개발자들이 필요로 하는 운영 가시성(operational visibility)에 초점을 맞추고 있습니다. 또한, 저희가 이 여정을 너무 복잡하게 만들었기 때문에 CrescoDB 자체의 시작하기 경험을 더 명확하게 만드는 작업도 진행하고 있습니다.
무엇이 바뀌는지, 왜 중요한지, 그리고 그동안 프로젝트를 실행하는 방법은 다음과 같습니다.
서버 모니터링 애플리케이션 건강 상태와 서버 건강 상태는 관련이 있지만, 같은 것은 아닙니다. 애플리케이션은 자체 코드 때문에 문제를 겪을 수도 있고, 실행되는 머신이 부하를 받고 있기 때문에 문제가 발생할 수도 있습니다. 저희는 개발자가 자신의 애플리케이션을 지원하는 인프라에 대해 가질 수 있는 가시성을 확장하고 있으며, 여기에는 다음 항목들이 포함됩니다:
14. CPU 사용량 및 시스템 부하.
15. 사용 가능한 메모리 및 스왑 공간.
16. 디스크 사용량 및 파티션.
17. 실행 중인 컨테이너와 그들의 리소스 사용량.
18. 서버 가용성.
19. 주의가 필요할 수 있는 운영 문제들. 예를 들어, 디스크 공간이 거의 가득 찬 서버를 고려해 보세요. 이는 배포(deployment), 백업 및 데이터베이스 작업에 방해가 될 수 있습니다. 배포가 실패했을 때만 발견하는 것은 조치할 시간이 남아 있을 때 발견하는 것보다 훨씬 늦습니다. 아이디어는 그러한 조건들이 더 큰 사고로 발전하기 전에 가시화하는 것입니다. 서버 외부에서의 업타임(Uptime) 확인 모니터링은 자신의 프로세스 내부에서 애플리케이션을 모니터링하는 것이 유용하지만, 방문자가 경험하는 모든 것을 알려주지는 못합니다. 서버가 실행 중일지라도 공용 도메인이 잘못 구성되었을 수 있습니다. 인증서에 문제가 있을 수도 있고, CDN이 오류를 반환할 수도 있으며, URL은 접근 가능하지만 응답 시간이 너무 오래 걸릴 수도 있습니다. 이것이 외부 업타임 확인이 중요한 이유입니다. CrescoDB의 모니터링 방향에는 서버 외부에서 공용 URL을 확인하는 것도 포함되어 있어, 도달 가능성(reachability), DNS, TLS, 응답 시간 및 제공되는 페이지와 관련된 문제를 식별하는 데 도움을 줍니다. 목표는 애플리케이션을 여러 관점에서 보는 것입니다: 앱 내부에서, 그 아래의 서버에서, 그리고 사용자가 접하는 외부에서 말입니다. 무언가 주의를 요할 때 알려주는 알림(Alerts) 모니터링은 하루 종일 대시보드를 열어두어야만 이점을 얻을 수 있다면 덜 유용합니다. 알림은 중요한 문제를 여러분의 주의에 가져와서 조사할 수 있도록 하는 것을 목적으로 합니다.
CrescoDB의 문서화된 모니터링 기능에는 이메일 알림이 포함되어 있으며, Slack과 Telegram은 유료 플랜에서 사용할 수 있습니다. 개발자들이 모든 메트릭을 수동으로 감시할 필요 없이 의미 있는 장애에 대응하는 데 도움을 주는 것이 목표입니다. 저희는 더 나은 운영 워크플로우를 구축하기 위해 노력하고 있습니다: 문제를 감지하고, 어디서 발생하는지 이해하며, 조사하고, 해결책을 마련합니다. 중요한 차이점은 개발자들에게 바라보게 할 숫자를 더 많이 제공하려는 것이 아니라는 점입니다. 프로덕션 문제를 이해하고 조치하기 쉽게 만드는 것이 목표입니다. 현재 CrescoDB 제품 개요 및 프로덕션 모니터링 문서를 통해 이 방향에 대해 더 자세히 읽어보실 수 있습니다.
배포는 워크플로우의 일부일 뿐, 끝이 아닙니다 저희는 또한 작동하는 로컬 프로젝트와 작동하는 프로덕션 애플리케이션 사이의 단계를 생각해 왔습니다. 개발자들은 각기 다른 워크플로우를 가지고 있습니다. 어떤 이들은 Git 기반 배포를 선호합니다. 또 다른 이들은 리포지토리 워크플로우를 먼저 설정하지 않고도 기존 프로젝트를 배포하기를 원합니다. 저희는 ZIP 기반 배포와 여러 애플리케이션이 서버를 공유할 때 디스크 할당을 관리하는 더 나은 방법을 포함하여 해당 프로세스의 마찰을 줄이는 작업을 진행하고 있습니다. 목표는 중요한 결정 사항들을 개발자들에게 숨기지 않으면서도 배포를 더욱 접근하기 쉽게 만드는 것입니다. CrescoDB는 사용자가 자신이 통제하는 인프라 위에서 애플리케이션을 실행할 수 있어야 한다는 아이디어를 중심으로 구축되었습니다. 코드가 플랫폼을 변경하기로 결정했다는 이유만으로 접근 불가능해서는 안 됩니다. 이는 배포가 이해하기 쉬워야 하고, 운영상의 문제는 진단하기 쉬워야 하며, 플랫폼을 떠나는 것도 실용적인 선택지로 남아있어야 함을 의미합니다. 이 워크플로우의 모든 부분이 완성되었다고 주장하지 않을 것입니다. 저희는 계속 개선해 나갈 것입니다.
또한 사과드릴 것이 있습니다 더 많은 기능에 대해 이야기하기 전에 현재 제품 경험에 대한 무언가를 인정해야 합니다. 저희 홈페이지와 온보딩 안내가 혼란스러웠으며, 죄송합니다.
저희는 CrescoDB에 대해 많은 것을 전달하려고 노력해 왔습니다. 로컬 개발 환경, 데이터베이스 및 API, 인증(authentication), 대시보드, AI 지원 기능, 배포(deployment) 방법, 그리고 운영 도구 등 프로덕션 단계에서 필요한 모든 것들입니다. 이러한 기능들은 중요합니다. 하지만 시작 지점을 명확하게 제시하지 않으면 새로운 개발자는 무엇부터 해야 할지 궁금해할 수 있습니다. 몇 가지 중요한 구분이 충분히 명확하지 않았습니다:
22. 설치해야 할 항목.
23. 로컬 프로젝트를 생성하고 실행하는 방법.
24. 로컬에서 작동하는 기능들.
25. 계정이 필요한 경우.
26. 배포하려 할 때 바뀌는 것들.
27. 프로젝트를 사용자가 통제하는 서버에 연결하는 방법. 저희가 이 단계를 더 쉽게 따라 할 수 있도록 만들었어야 했습니다. CrescoDB를 사용해 보고 싶은 개발자는 작동하는 API를 얻기 전에 전체 제품을 공부할 필요가 없어야 합니다. 또한, 로컬 개발과 클라우드 배포를 혼동할 필요도 없습니다. 이것은 커뮤니케이션 및 온보딩(onboarding) 문제입니다. 그리고 그것을 해결하는 것은 저희의 책임입니다. 저희는 홈페이지를 더 집중적으로 만들고 시작하기 여정(getting-started journey)을 더 직접적으로 만들기 위해 노력하고 있습니다. 그동안, 따라 할 수 있는 실용적인 가이드를 알려드립니다.
28. CrescoDB 프로젝트 실행 방법 CrescoDB 사용을 시작하기 위해 서버에 배포할 필요는 없습니다. 로컬 개발 환경의 전제 조건은 간단합니다. Node.js 20 이상 버전을 설치한 다음, CrescoDB를 설치하면 됩니다. 단계 1: Node.js 설치 CrescoDB는 Node.js 20 이상을 요구합니다. Node.js 22 LTS가 권장되는 시작점입니다. 설치된 버전을 확인하세요: node --version
Node.js를 설치해야 하는 경우, 공식 설치 관리자 또는 버전 관리자를 사용하십시오.
단계 2: CrescoDB 설치
CLI를 전역으로 설치합니다:
npm install -g crescodb
전역 설치하는 것을 원하지 않는다면 npx crescodb도 사용할 수 있습니다.
단계 3: 프로젝트 생성
프로젝트를 위한 새 폴더를 만들고, 그 안으로 이동한 다음, CrescoDB를 초기화합니다:
mkdir my-project
cd my-project
cresco init
이 과정은 스키마(schema), 설정 파일, 그리고 로컬 SQLite 데이터베이스를 포함한 기본적인 프로젝트 파일을 생성합니다.
중요 사항: 새로운 프로젝트는 비어 있는 상태로 시작됩니다. 이는 의도된 것입니다. 미리 채워진 애플리케이션을 받는 대신, 사용자가 직접 테이블과 데이터 모델을 정의해야 합니다.
만약 데모 테이블로 시작하고 싶다면, 대신 스타터 프로젝트를 초기화하세요:
cresco init --starter
새로운 프로젝트에는 두 가지 초기화 옵션 중 하나를 사용하십시오.
단계 4: 개발 서버 시작하기
프로젝트 디렉토리에서 다음을 실행합니다:
cresco dev
CrescoDB는 로컬 REST API와 개발 대시보드를 시작합니다.
단계 5: 대시보드 열기
다음 주소로 접속하세요:
[http://localhost:3000/studio]
대시보드에서 데이터를 탐색하고 편집하며, 스키마를 설계하고, SQL을 실행하고, 모델을 검사하며, 프로젝트를 구축하는 과정 전체를 살펴볼 수 있습니다.
이제 작업할 로컬 프로젝트가 생겼습니다.
이 단계에 도달하기 위해 임대한 VPS(Virtual Private Server), 클라우드 계정, 또는 Docker가 필요하지 않습니다.
단계 6: 데이터 모델 추가하기
스타터 옵션을 선택하지 않았다면, 프로젝트는 비어 있는 상태로 시작합니다.
스키마 파일을 통해 테이블을 정의하거나, 대시보드의 스키마 에디터를 사용하거나, 지원되는 AI 워크플로우를 통해 생성하려는 데이터를 설명할 수 있습니다.
예를 들어, 간단한 블로그는 게시물(posts)과 댓글(comments)에 대한 모델이 필요할 수 있고, 상점은 제품(products)과 주문(orders)에 대한 모델이 필요할 수 있습니다.
스키마가 준비되면, CrescoDB는 해당 API를 생성할 수 있습니다. 이후 프론트엔드나 다른 애플리케이션에서 HTTP를 통해 이 엔드포인트를 사용할 수 있습니다.
단계 7: 인증 추가 및 접근 규칙 확인하기
애플리케이션에 인증이 필요한 경우, 다음 명령어로 인증 코드를 생성할 수 있습니다:
cresco create auth
CrescoDB는 인증을 불투명한 블랙박스로 취급하도록 요구하는 대신, 프로젝트 내에 편집 가능한 코드를 작성합니다.
배포 전에 다음 명령어 또한 실행할 수 있습니다:
cresco audit
이는 스키마를 기반으로 접근 규칙을 확인하고 중요한 노출 문제를 식별합니다. CrescoDB의 배포 워크플로는 배포 준비 전에 감사(audit)를 실행하며, 명시적으로 재정의하지 않는 한 심각한 문제가 발견되면 진행을 거부합니다.
8단계: 준비가 되었을 때 배포하기 (Deploy when you're ready)
로컬 개발과 프로덕션 배포는 별개의 단계입니다. 애플리케이션이 로컬에서 작동하는 것이 확인되면, 배포 단계로 넘어갈 수 있습니다. CrescoDB는 사용자가 직접 제어하는 서버에 배포하는 것을 지원하며, 서버 연결, 프로젝트 배포 및 도메인 구성에 대한 워크플로우를 제공합니다.
지금 당장 이것들을 모두 할 필요는 없습니다. 배포 단계를 위해서는 홈페이지에서 프로세스를 추론하려고 하기보다는 공식 가이드(official guide)를 사용하여 자체 서버에 배포하는 방법을 이용하세요. 전체 로컬 퀵스타트(local quickstart)는 CrescoDB 시작하기 가이드(getting-started guide)에서 확인할 수 있습니다.