셀프 호스팅 Trello 대안 비교: Planka, Vikunja, Wekan

어떤 셀프 호스팅 Trello 대안을 선택해야 할까요?

시간을 투자할 만한 셀프 호스팅 Trello 대안은 세 가지입니다. Trello의 보드 구성과 가져오기 파일을 그대로 사용하려면 Planka를, 팀 단위에서 싱글 사인온(SSO)과 보드 이상의 기능이 필요하다면 Vikunja를, VPS(가상 사설 서버) 사양이 낮다면 Kanboard를 선택하십시오. Focalboard로 새 프로젝트를 시작하지 마십시오. 독립형 서버는 783일 동안 새로운 소프트웨어 릴리스가 없었으며, 현재 README에는 유지보수 담당자를 구한다는 문구가 적혀 있습니다.

Wekan은 여기에 나열된 5개의 도구 중 다섯 번째입니다. 정상적으로 작동하지만, 다른 도구들에 비해 메모리 사용량이 몇 배나 많습니다. 아래의 모든 버전, 라이선스, 날짜는 2026년 8월 5일에 확인되었습니다.

각 보드 도구는 어느 정도의 RAM을 필요로 합니까?

[
  {
    "tool": "Planka + Postgres",
    "idle_memory_mb": 280
  },
  {
    "tool": "Vikunja + SQLite",
    "idle_memory_mb": 110
  },
  {
    "tool": "Focalboard + SQLite",
    "idle_memory_mb": 120
  },
  {
    "tool": "Wekan + FerretDB",
    "idle_memory_mb": 750
  },
  {
    "tool": "Kanboard + SQLite",
    "idle_memory_mb": 70
  }
]

이 수치는 아무도 사용하지 않는 초기 설치 상태의 일반적인 유휴(idle) 메모리 사용량이며, 스택이 올라온 직후 docker stats가 보고하는 값과 같습니다. 계획을 세울 때 참고용으로 사용하고, 실제 환경에서 직접 측정하십시오. 정확한 메가바이트 수치보다 전체적인 규모를 파악하는 것이 더 중요합니다.

Kanboard는 PHP와 SQLite를 사용하므로 70 MB가 최소 사양입니다. 장시간 실행되는 애플리케이션 프로세스가 보드 데이터를 메모리에 상주시키지 않으므로, 요청이 없을 때 컨테이너는 거의 메모리를 점유하지 않습니다. Vikunja는 110 MB를 사용하는 단일 Go 바이너리이며, 기본 데이터베이스로 SQLite를 사용하므로 컨테이너 하나가 전체 스택을 구성합니다. Planka는 Node 서버와 PostgreSQL이라는 두 개의 컨테이너로 항상 실행되므로 280 MB가 필요합니다. Planka는 SQLite 옵션을 제공하지 않으므로 데이터베이스 구성은 필수입니다.

Wekan은 Meteor 애플리케이션이므로 750 MB를 점유합니다. Meteor는 실시간 쿼리 계층을 Node 메모리에 유지하며, 모든 보드 변경 사항을 WebSocket을 통해 열려 있는 모든 브라우저로 푸시합니다. 따라서 메모리 사용량이 일정하게 유지되지 않고 접속자 수에 비례하여 증가합니다. 1 GB RAM을 가진 VPS에서 Wekan은 시작은 되지만, 여러 사용자가 큰 보드를 여는 즉시 종료됩니다. 이 경우 컨테이너가 사라졌다가 종료 코드 137과 함께 다시 시작되는 현상이 발생하며, docker compose ps에서 재시작 루프를 확인할 수 있습니다. 커널의 OOM(out-of-memory) 킬러는 애플리케이션에 아무런 알림을 보내지 않으므로, 호스트에서 dmesg -T | grep -i "out of memory" 명령어로 직접 확인하십시오.

데이터베이스 의존성은 백업 작업의 절반을 결정하므로, 각 도구별로 정리하면 다음과 같습니다. Planka는 PostgreSQL이 필수입니다. Vikunja는 기본적으로 SQLite를 사용하며 PostgreSQL, MySQL, MariaDB도 지원합니다. Kanboard는 기본적으로 SQLite를 사용하며 MySQL, MariaDB, PostgreSQL도 지원합니다. Kanboard 문서에서는 PostgreSQL 사용을 권장하며 NFS(network file system) 환경에서 SQLite 사용을 경고합니다. Focalboard는 기본적으로 SQLite를 사용합니다. Wekan은 MongoDB 와이어 프로토콜을 사용하며, 기본 Compose 파일은 실제 MongoDB 서버 대신 내장 SQLite 백엔드를 사용하는 FerretDB v1을 제공합니다. 별도의 MongoDB 7 Compose 파일도 선택할 수 있습니다.

이 프로젝트들 중 현재 유지보수되고 있는 것은 무엇입니까?

[
  {
    "tool": "Planka 2.1.1",
    "release_age": 109
  },
  {
    "tool": "Vikunja 2.5.0",
    "release_age": 1
  },
  {
    "tool": "Focalboard 8.0.0",
    "release_age": 783
  },
  {
    "tool": "Wekan 10.67",
    "release_age": 1
  },
  {
    "tool": "Kanboard 1.2.53",
    "release_age": 12
  }
]

Focalboard는 783일이라는 수치로 보아 예외적인 경우입니다. 마지막 독립형 릴리스인 v8.0.0은 2024년 6월에 나왔습니다. Mattermost는 보드 개발을 별도 저장소의 플러그인으로 옮겼으며, 독립형 README에는 해당 저장소가 현재 유지보수되지 않는다고 명시되어 있습니다. 이 비교에서 유일하게 확실한 "아니오"에 해당합니다. 그 외의 프로젝트들은 모두 트레이드오프가 존재합니다.

Planka의 109일이라는 수치는 일 년에 몇 차례 릴리스를 배포하는 프로젝트로서는 건전한 상태입니다. 버전 2.1.1은 2026년 4월에 출시되었습니다. Kanboard는 점검 시점 기준으로 12일 전에 v1.2.53을 배포했으며, 그 이전 두 번의 릴리스는 2026년 3월과 4월에 이루어졌습니다.

Vikunja와 Wekan은 모두 점검 시점으로부터 하루 이내에 릴리스를 진행했지만, 이 두 사실은 다르게 해석해야 합니다. Vikunja는 v2.5.0에 일반적인 마이너 릴리스 태그를 붙였습니다. Wekan은 같은 날 v10.65, v10.66, v10.67에 태그를 붙였는데, 이는 해당 프로젝트의 일반적인 배포 주기입니다. 잦은 릴리스가 반드시 안정적인 대상을 의미하지는 않습니다. Wekan을 선택한다는 것은 빠르게 변하는 버전 번호를 추적하겠다는 의미이므로, 태그를 고정하고 버전을 올릴 때마다 릴리스 노트를 확인해야 합니다.

단순한 보드 이상의 기능을 제공하는가?

대부분의 비교 게시물은 "Trello와 비슷하다"는 수준에서 멈춥니다. 보드는 마감 기한이 있는 업무를 관리하기에는 적합하지 않은 형태이므로, 이 기준은 RAM 용량보다 더 중요한 결정 요소가 됩니다.

• Planka는 오직 보드 도구로서의 기능만 제공합니다. 프로젝트, 보드, 리스트, 카드, 라벨, 체크리스트, 댓글, 첨부 파일이 포함됩니다. 2026년 8월 기준으로 달력 및 지도 뷰는 Pro 기능입니다.
• Vikunja는 하나의 작업 세트에 대해 리스트, 칸반, 테이블, 간트 차트라는 네 가지 뷰를 제공합니다. 작업은 한 번만 생성되며, 중복 생성할 필요 없이 뷰를 전환하여 사용합니다.
• Kanboard는 진행 중인 작업 제한(WIP limits), 하위 작업, 첨부 파일, 댓글, 자동화 작업, 필터링을 위한 간단한 쿼리 언어를 갖춘 보드 도구입니다. 공식 홈페이지에서도 "기능의 수를 의도적으로 제한했다"고 명시하고 있으며, 이는 해당 도구의 성격을 잘 설명합니다.
• Wekan은 스윔레인(swimlanes) 기능을 갖춘 보드이며, 체크리스트, 사용자 정의 필드, REST(representational state transfer) API, 웹훅을 지원합니다.
• Focalboard는 동일한 카드에 대해 보드, 테이블, 달력 뷰를 제공했습니다. 완전한 비교를 위해 여기에 포함했습니다.

만약 실제로 필요한 것이 작업 추적 기능이 포함된 위키라면, 이 비교는 적절하지 않습니다. BookStack, Wiki.js 및 Outline에서 해당 형태의 도구를 다루고 있으며, 자체 호스팅 가능한 Notion 대안에서 올인원 워크스페이스를 다루고 있습니다.

다중 사용자 접근 및 싱글 사인온(SSO)

Planka는 무료 커뮤니티 에디션에서 OpenID Connect를 지원합니다. 공식 Compose 파일에는 OIDC_ISSUER, OIDC_CLIENT_ID, OIDC_CLIENT_SECRET를 포함한 설정이 주석 처리되어 있으므로, 업그레이드할 필요 없이 주석만 해제하면 됩니다. 조직 외부 사용자를 위한 게스트 역할은 Pro 기능입니다.

Vikunja는 여러 공급자와 동시에 OpenID Connect를 사용할 수 있습니다. VIKUNJA_AUTH_OPENID_ENABLED=true을 설정한 다음, 공급자별로 VIKUNJA_AUTH_OPENID_PROVIDERS_<ID>_* 변수 블록을 하나씩 추가하십시오. 또한 20명 규모의 조직에서 실제로 필요한 팀 기능과 프로젝트별 공유 기능을 제공합니다.

Wekan은 LDAP(Lightweight Directory Access Protocol), OAuth2, OIDC 및 SAML을 지원합니다. Kanboard는 LDAP이 내장되어 있으며 그 외 모든 인증을 위한 범용 OAuth2 플러그인과 프로젝트별 역할 및 그룹 기능을 갖추고 있습니다. Focalboard 독립형 서버는 싱글 사인온을 전혀 지원하지 않으며, 이것이 Focalboard를 제외해야 하는 두 번째 이유입니다.

이들 중 어떤 것이든 직접 운영하는 Authentik ID 공급자와 연동할 수 있으며, 이는 20명의 사용자에게 앱마다 별도의 비밀번호를 부여하는 것보다 대개 더 나은 해결책입니다.

Trello 보드를 가져올 수 있습니까?

Planka가 가장 간단한 경로를 제공합니다. Trello에서 보드를 JSON으로 내보낸 뒤, Planka에서 보드를 생성하고 Import를 클릭하여 Trello를 선택하십시오. 먼저 제한 사항을 읽어보시기 바랍니다. 사용자 및 첨부 파일은 가져오지 않으며, 카드당 하나의 체크리스트만 가져올 수 있고, Trello의 기본 JSON 내보내기는 1,000개의 작업에서 경고 없이 중단되기 때문입니다. 결과를 신뢰하기 전에 파일을 직접 확인하십시오.

Vikunja는 Settings의 "Import from other services" 항목에서 Trello의 OAuth 흐름을 통해 가져옵니다. 각 마이그레이터는 설정에서 활성화해야 아이콘이 나타나며, OAuth 리다이렉트가 서버가 아닌 브라우저에서 발생하므로 VIKUNJA_SERVICE_PUBLICURL가 정확해야 합니다. Vikunja는 Todoist, Microsoft To Do, TickTick 및 Wekan 데이터도 가져올 수 있습니다.

Wekan은 가져오기 양식에 붙여넣은 Trello 보드 JSON을 허용합니다. Kanboard에는 내장된 Trello 가져오기 기능이 없으며, 이것이 수년간의 Trello 기록을 옮겨야 할 경우 Kanboard를 선택하지 말아야 할 주된 이유입니다.

모바일 환경은 어떤가요?

Vikunja는 이 5가지 서비스 중 유일하게 공식 모바일 앱을 제공합니다. Android 및 iOS 빌드는 각 릴리스와 함께 배포됩니다. 앱 저장소에서는 이를 알파 버전으로 명시하고 있으므로, 주된 접속 수단이라기보다는 웹 인터페이스의 보조 도구로 활용하는 것이 좋습니다. Planka는 프로젝트 차원의 공식 앱은 없지만, 웹 인터페이스가 반응형으로 설계되어 있으며 서드파티 클라이언트도 존재합니다. Wekan과 Kanboard는 웹 전용이며, 특히 Kanboard의 인터페이스는 데스크톱 화면에 최적화되어 있습니다.

라이선스 문제와 Planka가 다른 이유

Planka는 더 이상 오픈 소스가 아니며, 이는 대부분의 비교 자료에서 누락하는 사실입니다. 이 프로젝트는 MIT 라이선스로 시작했으나 2023년에 AGPL-3.0으로 변경되었고, 2.0 시리즈부터는 PLANKA Software GmbH가 보유한 페어 코드(fair-code) 라이선스인 PLANKA Community License를 따릅니다. 해당 라이선스는 OSI 승인을 받지 않았기 때문에 GitHub에서는 라이선스를 "Other"로 표시합니다. 개인, 내부, 비영리 및 교육적 용도를 포함하여 본인이나 조직 내부 인원을 위해 직접 호스팅하는 것은 무료이며 명시적으로 허용됩니다. 하지만 서비스 형태로 재판매하거나 다른 기업을 위해 운영하려면 상업용 라이선스가 필요합니다.

2인 규모의 팀에게는 합리적인 조건일 수 있습니다. 하지만 기업이라면 20명 이상의 인력이 투입되기 전에 반드시 해당 약관을 검토해야 합니다. 비교 대상인 나머지 4개 소프트웨어는 일반적인 오픈 소스입니다. Vikunja는 AGPL-3.0, Wekan과 Kanboard는 MIT, Focalboard는 Apache 2.0과 AGPL-3.0이 혼합된 라이선스를 사용합니다.

두 가지 선택을 위한 고정된 Compose 파일

이미지 태그를 고정하십시오. latest은 다음 docker compose pull이 메이저 버전을 넘나들게 할 수 있으며, 메이저 버전은 쉽게 되돌릴 수 없는 데이터베이스 마이그레이션을 실행합니다. 아래의 두 파일은 태그가 실제 릴리스로 고정된 업스트림 파일입니다.

SQLite를 사용하는 Vikunja, 단일 컨테이너:

services:
  vikunja:
    image: vikunja/vikunja:2.5.0
    restart: unless-stopped
    environment:
      VIKUNJA_SERVICE_PUBLICURL: https://tasks.example.com
      VIKUNJA_SERVICE_SECRET: replace-with-a-long-random-string
      VIKUNJA_SERVICE_TIMEZONE: Europe/Berlin
      VIKUNJA_DATABASE_TYPE: sqlite
      VIKUNJA_DATABASE_PATH: /app/vikunja/files/vikunja.db
    ports:
      - "127.0.0.1:3456:3456"
    volumes:
      - ./files:/app/vikunja/files

컨테이너가 UID 1000으로 실행되어 root 소유 디렉터리에 쓸 수 없으므로, 먼저 올바른 소유자로 데이터 디렉터리를 생성하십시오:

mkdir -p files && sudo chown 1000 files
docker compose up -d
docker compose ps
curl -sf http://127.0.0.1:3456/api/v1/info

정상적인 스택은 서비스를 running로 표시하며, 정보 엔드포인트는 version 필드가 포함된 JSON을 반환합니다. 여기서 연결이 거부된다면 컨테이너가 종료된 것입니다. docker compose logs vikunja은 그 이유를 나타내며, 데이터베이스 파일에 대한 권한 오류가 흔한 원인입니다.

PostgreSQL을 사용하는 Planka, 두 개의 컨테이너:

services:
  planka:
    image: ghcr.io/plankanban/planka:2.1.1
    restart: unless-stopped
    volumes:
      - data:/app/data
    ports:
      - "127.0.0.1:3000:1337"
    environment:
      - BASE_URL=https://boards.example.com
      - DATABASE_URL=postgresql://postgres@postgres/planka
      - SECRET_KEY=replace-with-openssl-rand-hex-64
    depends_on:
      postgres:
        condition: service_healthy

  postgres:
    image: postgres:16-alpine
    restart: unless-stopped
    volumes:
      - db-data:/var/lib/postgresql/data
    environment:
      - POSTGRES_DB=planka
      - POSTGRES_HOST_AUTH_METHOD=trust
    healthcheck:
      test: ["CMD-SHELL", "pg_isready -U postgres -d planka"]
      interval: 10s
      timeout: 5s
      retries: 5

volumes:
  data:
  db-data:

POSTGRES_HOST_AUTH_METHOD=trust은 PostgreSQL이 비밀번호 없이 모든 연결을 수락함을 의미합니다. 데이터베이스 포트가 호스트에 공개되지 않기 때문에 이것은 안전하며, 동일한 Compose 네트워크에 있는 다른 컨테이너만이 접근할 수 있습니다. postgres 서비스에 ports: 항목을 추가하지 마십시오.

어떤 스택도 인터넷에 직접 노출되어서는 안 됩니다. 둘 다 127.0.0.1에 바인딩되므로, 앞에 리버스 프록시를 두고 그곳에서 TLS(전송 계층 보안)를 종료하십시오. 여러 Compose 앱 앞의 Traefik은 하나 이상의 서비스를 호스팅할 때 사용하는 일반적인 방법이며, Docker Compose 기초 가이드는 이 페이지에서 생략된 파일의 세부 사항을 다룹니다.

보드는 데이터베이스이므로 백업하십시오

보드 도구는 조용히 실패합니다. 볼륨이 사라지기 전까지는 백업이 누락된 사실을 아무도 알아차리지 못하며, 손상된 SQLite 파일은 평소처럼 열리다가 database disk image is malformed주 뒤에야 오류를 보고할 수 있습니다.

cp를 사용하여 실행 중인 SQLite 파일을 복사하지 마십시오. 복사본이 쓰기 작업 도중의 상태를 캡처할 수 있으며, 이 경우 아카이브는 정상적으로 보이지만 복원 시 행이 누락된 데이터베이스가 됩니다. 복사에 필요한 몇 초 동안 서비스를 중단하십시오:

docker compose stop vikunja
tar czf vikunja-$(date +%F).tgz files
docker compose start vikunja

Planka의 경우, 실행 중인 클러스터의 데이터 디렉터리를 복사하는 대신 PostgreSQL을 덤프하고, 첨부 파일은 데이터베이스에 저장되지 않으므로 업로드 볼륨을 별도로 백업하십시오:

docker compose exec -T postgres pg_dump -U postgres -Fc planka > planka-db.dump
docker volume ls
docker run --rm -v planka_data:/data -v "$PWD":/backup alpine \
  tar czf /backup/planka-files.tgz -C /data .

docker volume ls은 실제 볼륨 이름을 출력하며, 이는 Compose 프로젝트 이름 뒤에 _data이 붙은 형태입니다. 존재하지 않는 이름을 전달하면 빈 볼륨이 생성되어 오류 없이 유효하지만 비어 있는 아카이브가 만들어지므로, 작업 후 파일 크기를 확인하십시오.

그런 다음 동일한 서버의 임시 스택에 한 번 복원해 보고 기억하는 카드를 열어보십시오. 한 번도 복원해 보지 않은 백업은 추측일 뿐입니다. 아카이브를 서버 외부로 전송하십시오. 보호 중인 VPS에 저장된 복사본은 백업이 아니기 때문입니다. VPS에서 restic 백업하기에서 해당 내용을 다룹니다.

두 가지 권장 사항

2 GB VPS에서 2명이 사용할 경우: Planka를 실행하십시오. 외관과 동작 방식이 Trello와 가장 유사하며, Trello 가져오기는 파일을 드래그하는 방식으로 이루어집니다. 유휴 메모리가 280 MB에 불과하여 2 GB 중 대부분을 리버스 프록시나 다른 호스팅 서비스에 할당할 수 있습니다. Community License는 2인 내부 팀에 무료로 제공됩니다. 소스 공개 라이선스에 의존하고 싶지 않다면, 110 MB를 사용하는 SQLite 기반의 Vikunja가 동일한 환경을 위한 오픈 소스 대안입니다.

조직 내 20명이 사용할 경우: PostgreSQL 기반의 Vikunja를 실행하십시오. 이 규모에서는 20개의 로컬 비밀번호 대신 OpenID Connect가 필요하며, 팀 및 프로젝트별 공유 기능이 필수적입니다. 또한 업무 대부분이 보드 형태에 맞지 않으므로 리스트, 테이블, 간트 차트 뷰는 단순한 부가 기능을 넘어 필수적인 요소가 됩니다. AGPL-3.0 라이선스는 인원수가 증가해도 라이선스 관련 문제를 발생시키지 않습니다. SQLite 대신 PostgreSQL을 사용하고, 리버스 프록시 뒤에 배치하며, 일일 덤프 파일은 해당 서버 외부의 안전한 곳에 보관하십시오.

서버의 RAM이 1 GB 미만인 경우, 위 답변은 적용되지 않습니다. 70 MB를 사용하는 Kanboard를 선택하십시오. Trello 카드를 직접 다시 입력해야 한다는 점을 감안하고, 절약한 메모리는 2026년 셀프 호스팅 추천 목록에 있는 다른 서비스에 활용하십시오. 선택한 도구의 상세 설치 방법은 각 가이드를 참조하십시오. 이 페이지는 오직 선택을 위한 가이드입니다.

FAQ

가장 적은 RAM을 사용하는 셀프 호스팅 Trello 대안은 무엇입니까?

Kanboard입니다. 유휴 상태에서 약 70 MB를 사용합니다. PHP와 SQLite 기반이며 요청 사이에 메모리에 아무것도 유지하지 않기 때문입니다. 그다음은 단일 Go 바이너리로 실행되는 Vikunja로 약 110 MB를 사용합니다. Wekan은 약 750 MB로 가장 무겁습니다. Meteor가 연결된 모든 브라우저를 위해 Node 메모리에 실시간 쿼리 계층을 유지하기 때문입니다. 이는 일반적인 수치일 뿐 보장되는 값이 아니므로, 스택이 유휴 상태일 때 docker stats을 사용하여 직접 측정하십시오.

셀프 호스팅 도구로 Trello 보드를 가져올 수 있습니까?

Planka와 Wekan은 Trello의 JSON 보드 내보내기 파일을 직접 가져올 수 있습니다. Vikunja는 Trello의 OAuth 흐름을 통해 가져오며, 인터페이스에 나타나기 전에 설정에서 마이그레이션 도구를 활성화해야 합니다. Kanboard에는 내장된 가져오기 기능이 없습니다. 고려해야 할 두 가지 제한 사항이 있습니다. Planka는 사용자나 첨부 파일을 가져오지 않으며 카드당 하나의 체크리스트만 처리합니다. 또한 Trello의 기본 JSON 내보내기는 데이터가 잘렸다는 경고 없이 1,000개의 작업에서 중단됩니다.

2026년에도 Focalboard는 좋은 선택입니까?

아닙니다. 마지막 독립형 릴리스인 v8.0.0은 2024년 6월에 나왔으며, 이는 2026년 8월 5일에 이 비교를 확인했을 때보다 783일 전입니다. README에는 해당 저장소가 현재 유지 관리되지 않는다고 명시되어 있습니다. Mattermost는 별도의 저장소에서 플러그인 형태로만 보드 개발을 지속했으므로, 사용자가 직접 호스팅할 서버 부분은 개발이 중단되었습니다. 대신 Planka나 Vikunja를 선택하십시오.

Planka는 여전히 오픈 소스입니까?

OSI 정의에 따르면 그렇지 않습니다. Planka는 MIT 라이선스였으나 2023년에 AGPL-3.0으로 변경되었고, 버전 2.0부터는 PLANKA Community License 하에 배포됩니다. 개인, 내부, 비영리 및 교육용으로는 무료로 셀프 호스팅할 수 있습니다. 제3자에게 접근 권한을 재판매하거나 서비스로 운영하려면 상용 라이선스가 필요하며, 달력 보기, 게스트 역할, 반복 카드 기능은 Pro 등급에 포함되어 있습니다. OSI 승인 라이선스가 필수 요구 사항이라면 Vikunja는 AGPL-3.0, Kanboard는 MIT 라이선스를 따릅니다.

PostgreSQL이 필요합니까, 아니면 SQLite로 충분합니까?

Vikunja, Kanboard, Focalboard는 기본적으로 SQLite를 사용하며, 한 서버에서 소수의 인원이 사용하기에는 충분합니다. Planka는 PostgreSQL이 필수이며 SQLite 옵션을 제공하지 않습니다. 여러 사람이 동시에 데이터를 작성하는 환경이라면 PostgreSQL로 전환하십시오. SQLite는 쓰기 작업을 직렬화하므로 사용량이 많은 인스턴스는 database is locked를 반환하기 시작합니다. 또한 SQLite 파일을 네트워크 공유 드라이브에 두지 마십시오. Kanboard 문서에서도 바로 이러한 이유로 NFS 환경에서 SQLite를 사용하는 것을 경고합니다.