PRO+ 공개 샘플 · 로그인 없이 전체 내용을 볼 수 있어요.
설치 전 시식 · 로그인 없이 공개
appwrite/appwrite 백엔드·DB
회원이 자기 기록과 사진을 보는 앱을 만든다고 생각해 볼게요. 로그인, 기록 저장, 파일 보관을 여섯 단계 손그림 영상으로 이해하고, 다른 회원에게 자료가 열리지 않게 무엇을 정해야 하는지 살펴봅니다.
69초 영상공식 화면 3장선택 가이드01 · 영상으로 한눈에
로그인과 접근 권한을 나누고, 글·사진을 저장한 뒤 두 계정으로 확인하는 과정을 한국어 나레이션과 손그림으로 설명합니다. 깃밥의 설명도이며 실제 앱의 실행·보안 테스트 결과는 아닙니다.
02 · 공식 화면 읽기
고객이 사용하는 앱 화면이 아니라, 개발·운영자가 보는 Appwrite 관리 화면이에요. 아래 활용 제안은 이 기능을 개인 기록 앱에 연결한다고 가정한 깃밥의 설명입니다.
01 / Auth · 회원 계정
화면의 영문·이름·이메일은 원작의 예시 데이터예요. 화면 속 Pro 표시는 Appwrite의 요금제이며 깃밥 PRO+와 달라요. 이 캡처만으로 필요한 요금제나 권한 설정을 판단하지 않습니다.
화면: Appwrite 및 기여자 · BSD-3-Clause. 손그림·해설·영상: 깃밥. 문서 확인: 2026. 10. 15. / 원본 화면 확인: 2026. 10. 11. 화면 자료 라이선스 ↗
03 · 선택 가이드
아래 상황을 가정한 선택 안내예요. 조건이 달라지면 잘 맞는 도구도 달라집니다.
이번 두 후보 가운데서는 Appwrite Cloud의 유료 운영부터 검토합니다. PocketBase도 회원·자료 기능을 제공하지만, 현재 팀이 맡을 수 없는 서버 관리와 업데이트 책임이 남습니다. 개인 자료의 공개 범위와 복구 대상은 앱에 맞게 정해야 합니다.
둘 다 회원·자료·파일 기능을 내 앱에 붙이는 후보입니다. 아래에서는 같은 질문으로 Appwrite Cloud와 직접 운영하는 PocketBase를 비교합니다. Appwrite 자체 설치는 Cloud와 운영 책임이 다릅니다.
내 선택에 대입하면가정한 팀에서는 기능 수보다 이 차이가 Appwrite Cloud를 먼저 고를 이유입니다.
내 선택에 대입하면둘 다 가능하므로 ‘개인 자료가 있다’는 이유만으로 한쪽을 고르지는 않습니다. 어느 쪽도 로그인만 연결해서 보호가 끝나지는 않습니다.
내 선택에 대입하면이 팀은 무료 여부보다 서비스가 멈추거나 버전이 바뀔 때 감당할 조건을 먼저 봐야 합니다. 유료 Cloud도 무중단을 측정·보증한 결론은 아닙니다.
내 선택에 대입하면둘 다 완성된 회원 사업이나 결제 서비스를 만들어주지는 않습니다. 기존 업무 코드가 있다면 실행 환경이 맞는지도 선택 조건입니다.
내 선택에 대입하면Cloud 이용료와 자체 서버 요금만 비교하면 운영 시간과 복구 비용을 빠뜨립니다. 실제 사용량을 모르는 지금 어느 쪽이 더 싸다고 정할 수는 없습니다.
새 회원 서비스를 만들 개발자는 있지만 서버를 운영할 사람은 없고, 관리형 서비스 비용을 낼 수 있다면 Appwrite Cloud를 먼저 봅니다.
작은 자체 서버를 맡을 사람이 있고, 업데이트·복구·버전 변경을 직접 다루며 가벼운 구성을 원한다면 PocketBase를 검토합니다.
PocketBase를 먼저 검토합니다.
하나의 실행 파일에 계정·자료 관리가 담겨 있어 작은 자체 서버를 꾸리기 좋습니다. 다만 1.0 이전의 버전 변경에 따라 필요한 수동 변경 작업도 맡아야 합니다.
기존 시스템을 유지하고 부족한 기능만 비교합니다.
두 후보의 기본 기능이 있다는 이유만으로 옮길 필요는 없습니다. 해결할 불편이 분명해야 계정·자료·업무 코드를 바꾸는 작업을 감수할 이유가 생깁니다.
둘 중 하나로 바로 확정하지 않습니다.
Appwrite Free는 개발 활동이 없으면 일시 중지될 수 있고, PocketBase는 운영 담당이 필요합니다. 무료라는 이유만으로 운영 조건이 충족되지는 않습니다.
Appwrite Cloud 추천을 거두고 직접 운영 후보를 다시 비교합니다.
Appwrite 자체 설치와 PocketBase 모두 후보가 될 수 있습니다. 어느 쪽이든 서버·복구 담당과 보관 위치 조건이 먼저 필요하므로 PocketBase로 자동 결론 내리지는 않습니다.
여기서는 답을 임의로 정하지 않았어요. 내 상황에 대입해서 읽어 보세요.
현재 쓰는 로그인·자료 저장 도구와 바꾸려는 불편 한 가지를 적고, 기존 기능이나 설정으로 해결 가능한지 확인하세요.
확인 후 선택기존 기능으로 해결되면 유지합니다. 교체해야 해결된다면 계정·자료·접근 권한의 이전 범위를 먼저 정한 뒤 다시 비교합니다.
업데이트 실패나 자료 삭제가 생겼을 때 복구를 맡을 사람과 허용할 중단 시간을 적어보세요. 코드 작성 가능 여부와 운영 담당 여부는 따로 확인합니다.
확인 후 선택담당자가 없으면 관리형 후보를 우선합니다. 담당자가 있고 중단·버전 변경 대응을 감수할 수 있으면 PocketBase도 남깁니다. 엄격한 가용성 보장이 필요하면 이 글만으로 확정하지 않습니다.
예상 활성 회원 수·월 저장량·전송량·메일 발송량을 적어 현재 Cloud 요금과 한도에 대입하세요. 자체 운영은 서버·메일·백업 비용과 담당자 시간을 함께 적고, 계정·기록·첨부파일의 복원 방법을 각각 확인합니다.
확인 후 선택예산 안에서 필요한 복구 범위까지 충족하는 후보를 남깁니다. 비용이나 복원 방법이 미확인이면 결정을 보류합니다. 설치·측정 전에는 속도나 최대 수용량의 우열을 확정하지 않습니다.
Appwrite는 앱 뒤에서 계정 확인·자료 저장·접근 허용을 맡는 개발 도구입니다. 회원이 자기 메모를 저장하고 다시 열어보는 앱을 만들 때 쓸 수 있어요. 방문자가 누르는 버튼과 메모 화면은 개발자가 만듭니다.
회원마다 자기 기록을 보관하고, 다른 회원에게는 보이지 않게 하고 싶어요.
로그인한 사람과 각 메모의 열람 범위를 연결해 개인 자료를 관리합니다.
회원이 저장한 글 제목과 주소를 자기 목록에서 다시 찾게 하고 싶어요.
회원별로 제목·주소를 저장할 수 있습니다. 글을 자동으로 읽거나 요약하는 기능은 별도로 만듭니다.
오늘 공부한 내용과 진도를 회원별로 남기고 싶어요.
기록을 저장하고 누가 볼 수 있는지 정합니다. 달력·진도 표시·학습 추천은 앱에서 만듭니다.
위 상황과 아래 흐름은 공식 로그인·개인 자료 예제와 조회·수정 문서를 이어 설명한 활용안입니다. 완성 앱의 시연은 아니며, 메모 화면을 만들어 연결한 상황을 가정합니다.
사용자가 보는 것은 내 메모 화면입니다. 그 뒤의 로그인 확인과 자료 보관을 Appwrite에 맡기는 방식이에요.
먼저 작은 기록 앱으로 로그인·권한·저장·복원을 연결해 보세요. 다른 회원의 기록과 사진이 막히는지까지 확인한 다음 기능을 넓히는 편이 좋습니다.
영상의 핵심은 로그인과 접근 권한을 나누는 것입니다. Auth는 누가 요청했는지 확인하고, 데이터베이스와 Storage는 설정된 권한에 따라 기록과 파일을 제공합니다. 화면·업무 규칙·공개 범위와 복구 방법은 앱을 만드는 팀이 정합니다.
접속할 서비스 주소와 프로젝트를 고르고 이메일·비밀번호로 세션, 즉 이후 요청에서 사용할 로그인 상태를 만듭니다. 이 결과가 “모든 데이터에 접근 가능”이라는 권한을 주는 것은 아닙니다.
이 행의 읽기·수정·삭제를 특정 회원에게 부여합니다. 공식 문서는 행 단위 권한을 켜는 Row Security, 테이블의 생성 허용, 전체 읽기·수정·삭제 권한을 주지 않는 설정을 함께 설명합니다.
내 조건에 맞춰 확인하기 위한 순서예요. 깃밥이 직접 실행한 결과를 뜻하지는 않아요.
확인 후 남길 것소유자만 세 작업을 허용하는 9칸 표와 공개 자료의 별도 정책.
확인 후 남길 것전체 읽기 권한이 개인 메모 정책을 넓히는지 즉시 보이는 권한 설정 목록.
확인 후 남길 것브라우저에 둘 값과 서버에만 둘 비밀값의 위치표 및 실제 구현에서 확인할 거부 응답 목록.
권한표의 모든 칸이 설정 항목과 연결되면 더미 계정·메모로 실제 접근 확인을 계획합니다.
테이블의 광범위한 허용이 남거나 서버 키를 브라우저에 넣어야만 되는 설계라면 공개하지 않습니다.
화면과 사용 예는 공식 자료에서 가져오고, 설명과 활용 제안은 깃밥이 덧붙였어요.
공식 예제는 연결할 앱을 지정하고, 이메일·비밀번호가 맞으면 로그인 상태를 만듭니다. 화면의 로그인 버튼을 눌렀을 때 연결할 처리에 해당합니다. 아래 계정 값은 설명용이며, 가입 화면이나 로그인 화면 자체를 만드는 코드는 아닙니다.
회원이 자기 자료를 보기 전에 누구인지 확인할 때.
import { Client, Account } from "appwrite";
const client = new Client()
.setEndpoint('https://<REGION>.cloud.appwrite.io/v1') // Your API Endpoint
.setProject('<YOUR_PROJECT_ID>'); // Your project ID
const account = new Account(client);
const result = await account.createEmailPasswordSession({
email: 'email@example.com',
password: 'password'
});
console.log(result);appwrite contributors · BSD-3-Clause
원본 자료 보기 ↗제목 한 개를 저장하면서 특정 회원에게 읽기·수정·삭제를 허용하는 공식 코드입니다. 개인 메모나 저장목록에 응용할 수 있습니다. 본인에게만 보이게 하려면 저장 공간 전체를 모두에게 열지 않고, 자료별 권한을 적용하는 Row Security도 켜야 합니다.
같은 앱을 쓰더라도 회원마다 자기 기록만 보게 하고 싶을 때.
let promise = tablesDB.createRow({
databaseId: '<DATABASE_ID>',
tableId: '<TABLE_ID>',
rowId: ID.unique(),
data: { 'title': 'My Private Row' },
permissions: [
Permission.read(Role.user('<USER_ID>')), // Only this user can read
Permission.update(Role.user('<USER_ID>')), // Only this user can update
Permission.delete(Role.user('<USER_ID>')) // Only this user can delete
]
});appwrite contributors · BSD-3-Clause
원본 자료 보기 ↗선정한 이유: 로그인과 접근 권한을 구분하고, Cloud·자체 운영의 책임과 두 계정으로 확인할 일을 연결해 설명합니다. 공식 화면은 이해를 돕는 별도 예제로 보존했습니다.
공식 자료를 읽고 해설한 편집 콘텐츠예요. 새로 설치해 검증하거나 도입 효과를 측정한 기록은 아니에요. 원본 화면의 언어와 수치는 그대로 유지했어요.