macOS용 digna 설치 안내 Release 2026.11¶
릴리스: 2026.11
최종 업데이트: 2026년 11월 7일
목차¶
- 소개
- 시스템 요구사항
- 사전 설치 준비
- PostgreSQL 서버 설정
- 웹 서버 구성
- 초기 설치
- 백엔드 구성
- 대시보드 구성
- digna를 백그라운드 서비스로 실행하기
- 새 릴리스로 업그레이드하기
소개¶
digna에 관하여¶
digna는 데이터 웨어하우스, 데이터 레이크, 레이크하우스 등 다양한 데이터 환경에서 데이터 품질 관리를 최적화하도록 설계된 AI 기반 플랫폼입니다. 자동화, 실시간 모니터링 및 이상 탐지를 통해 현대 데이터 문제를 해결할 수 있도록 높은 확장성과 적응성을 갖추고 있습니다.
digna는 두 가지 주요 구성 요소로 이루어져 있습니다:
- digna: 애플리케이션의 핵심으로, 데이터 처리와 품질 검사 수행을 담당합니다. 백엔드와 명령줄 인터페이스를 단일 실행 파일로 통합하여 이전 릴리스의 별도 프로그램인
dignabackend와dignacli를 대체합니다. - dignadashboard: 웹 서버에 호스팅되는 웹 기반 인터페이스로, digna 플랫폼과 상호작용하고 데이터 품질 지표를 시각화하는 사용자 친화적 수단을 제공합니다.
Release 2026.11의 변경 사항¶
이번 릴리스는 digna Data Reconciliation, digna MCP Server를 포함한 digna Agentic, 그리고 digna Engine을 추가합니다. digna Engine은 digna 내부에서 데이터를 프로파일링하고 서로 다른 데이터베이스 기술 간의 참조 무결성을 검사할 수 있습니다. 전체 내용은 릴리스 노트를 참조하세요.
설치 측면에서 이번 릴리스는 새로운 리포지토리 마이그레이션 메커니즘, digna Engine을 위한 config.toml의 선택적 [duckdb] 섹션, 그리고 새 라이선스 파일을 도입합니다. 각각은 업그레이드 섹션에서 다룹니다.
Windows 또는 Linux용 안내를 찾고 계신가요?¶
이 가이드는 macOS를 다룹니다. 다른 플랫폼은 Windows 설치 안내 또는 Linux 설치 안내를 참조하세요.
시스템 요구사항¶
설치를 시작하기 전에 시스템이 다음 최소 요구사항을 충족하는지 확인하세요:
| 요구사항 | 사양 |
|---|---|
| 운영체제 | macOS 13 (Ventura) 이상 |
| 아키텍처 | Apple Silicon (arm64) 또는 Intel (x86_64) |
| 메모리 (최소 구성) | 16 GB RAM |
| 디스크 공간 | 10 GB 사용 가능 저장소 |
| 데이터베이스 | PostgreSQL Server 12 이상 |
| 웹 서버 | nginx, Apache httpd 또는 동등한 서버 |
| 명령줄 도구 | Xcode Command Line Tools (Homebrew에서 필요) |
digna Engine
프로파일링 위치로 digna Engine을 사용하는 데이터베이스 연결은 digna 호스트 자체에서 프로파일링됩니다. 이를 위한 추가 메모리와 디스크 공간을 계획하세요. 참조: [duckdb] 섹션.
데이터베이스 설치 옵션¶
PostgreSQL가 이미 설치되어 있는 경우: 기존 PostgreSQL 서버에 digna용 새 데이터베이스를 추가할 수 있습니다.
digna와 동일한 머신에 PostgreSQL을 설치하는 경우:
권장 사양
- 메모리: 32 GB RAM (16 GB 대신)
- 디스크 공간: 50 GB 사용 가능 저장소 (10 GB 대신)
이 권장 사양은 digna와 PostgreSQL 데이터베이스가 동시에 실행될 때를 고려한 것입니다.
아키텍처 확인 방법¶
이 가이드의 여러 경로는 Apple Silicon과 Intel Mac 간에 다릅니다. 어느 쪽인지 확인하려면 터미널을 열고 다음을 실행하세요:
arm64— Apple Silicon. Homebrew는/opt/homebrew에 설치됩니다.x86_64— Intel. Homebrew는/usr/local에 설치됩니다.
팁
어느 경로든 하드코딩하기보다는, 이 가이드에서는 $(brew --prefix)를 사용합니다. 이 명령은 두 아키텍처 모두에서 올바른 위치로 확장되므로 명령을 그대로 복사해서 사용할 수 있습니다.
사전 설치 준비¶
digna를 설치하기 전에 다음 세 가지 주요 필수 요소가 준비되어 있는지 확인하세요:
- Homebrew – 아래 구성 요소를 설치하는 데 사용되는 패키지 관리자
- PostgreSQL 서버 – 계산된 메트릭 및 성능 데이터를 저장하기 위한 데이터베이스
- 웹 서버 – digna 대시보드를 호스팅하기 위한 서버
이들 구성 요소가 아직 설정되어 있지 않다면, 아래 섹션을 따라 설치 및 구성하세요.
Homebrew 설치¶
Homebrew는 macOS의 표준 패키지 관리자이며 이 가이드 전반에서 PostgreSQL과 nginx를 설치하는 데 사용됩니다.
1단계: Homebrew가 이미 설치되어 있는지 확인¶
터미널을 열고(유틸리티에서 또는 Cmd + Space 후 Terminal 입력) 다음을 실행하세요:
버전 번호가 반환되면 PostgreSQL 서버 설정 섹션으로 건너뛰세요.
2단계: Homebrew 설치¶
명령을 찾을 수 없는 경우, 공식 Homebrew 사이트의 지침에 따라 Homebrew를 설치하세요. 설치 프로그램은 Xcode Command Line Tools가 없는 경우 이를 함께 설치합니다.
3단계: Homebrew를 PATH에 추가¶
Apple Silicon에서는 설치 프로그램이 Homebrew를 셸 환경에 추가하기 위한 두 명령을 출력합니다. 지시에 따라 해당 명령을 실행한 후 다음을 확인하세요:
Apple Silicon에서는 /opt/homebrew를, Intel에서는 /usr/local을 출력해야 합니다.
PostgreSQL 서버 설정¶
이미 PostgreSQL이 있는 경우¶
PostgreSQL이 로컬 머신에서 이미 실행 중이거나 관리형 원격 PostgreSQL 서버를 사용하는 경우, 다음 섹션으로 건너뛰세요.
설치 옵션¶
macOS에서는 PostgreSQL을 설치하는 두 가지 간단한 방법이 있습니다. 하나만 선택하세요:
- Homebrew — 명령줄 설치, 서버 배포에 권장
- Postgres.app — 그래픽 설치, 로컬 평가에 편리
Homebrew로 PostgreSQL 설치¶
1단계: PostgreSQL 포뮬러 설치¶
2단계: PostgreSQL을 PATH에 추가¶
버전 지정 포뮬러는 keg-only이므로 Homebrew가 자동으로 명령을 PATH에 연결하지 않습니다. 직접 추가하세요:
참고
macOS의 기본 셸인 zsh를 가정한 예입니다. bash를 사용하는 경우 동일한 줄을 ~/.bash_profile에 추가하세요.
3단계: PostgreSQL 서비스 시작¶
이 명령은 PostgreSQL을 즉시 시작하고 로그인할 때 자동으로 다시 시작되도록 구성합니다.
4단계: 설치 확인¶
설치가 성공했다면 PostgreSQL 버전이 표시됩니다.
5단계: 서버에 연결¶
중요 — macOS는 이 부분에서 Windows와 다릅니다
Windows 설치 관리자는 postgres 슈퍼유저와 비밀번호를 생성하도록 안내합니다. Homebrew는 그렇지 않습니다. 대신 macOS 계정 이름으로 된 슈퍼유저를 생성하며 비밀번호가 없고 로컬 머신에서만 접근할 수 있습니다.
따라서 초기 Homebrew 설치에는 postgres 역할이 없습니다. 슈퍼유저가 필요할 때는 자신의 계정 이름을 사용하고, 초기 설치에 설명된 대로 명시적인 digna 사용자를 생성하세요.
6단계: 포트 확인¶
기본 PostgreSQL 포트는 5432입니다. 서버가 어느 포트를 수신하는지 확인하려면:
이 값을 기록해 두세요 — digna 백엔드를 구성할 때 필요합니다.
Postgres.app로 PostgreSQL 설치¶
그래픽 설치를 선호하는 경우:
- Postgres.app을 다운로드하여 Applications 폴더로 드래그합니다.
- 앱을 열고 Initialize를 클릭하여 새 서버를 만듭니다.
- 앱의 지침에 따라 명령줄 도구를 PATH에 추가합니다.
- 설치 확인:
Postgres.app은 macOS 계정 이름으로 된 슈퍼유저도 생성합니다.
웹 서버 구성¶
digna는 대시보드를 호스팅하기 위해 웹 서버가 필요합니다. 다음 옵션 중 하나를 선택하세요:
- nginx — Homebrew로 설치, 권장
- Apache httpd — macOS에 포함
이 중 하나만 설치하고 구성하면 됩니다.
두 섹션 모두 대시보드가 의존하는 두 가지를 구성합니다:
- 단일 페이지 애플리케이션(fallback) — 대시보드 URL을 새로고침해도 404가 반환되지 않도록 함
.mdMIME 타입 — Markdown 파일이 올바르게 제공되도록 함
nginx 설정¶
개요¶
nginx는 정적 digna 대시보드를 제공하는 데 적합한 가볍고 고성능의 웹 서버입니다.
설치¶
nginx 시작¶
설치 확인¶
- 브라우저를 엽니다.
http://localhost:8080로 이동합니다.- nginx 환영 페이지가 표시되어야 합니다.
참고 — 기본 포트는 8080이며 80이 아닙니다
Homebrew는 관리자 권한 없이 실행할 수 있도록 nginx를 포트 8080으로 설정합니다. macOS에서 포트 80 또는 1024 미만의 다른 포트에 바인딩하려면 루트 권한이 필요합니다.
대시보드를 포트 80에서 제공하려면 아래 구성에서 listen 8080;을 listen 80;으로 변경하고 대신 sudo brew services start nginx로 시작하세요.
대시보드용 사이트 구성¶
Homebrew의 nginx 구성은 servers 디렉터리의 모든 파일을 포함합니다. digna용 전용 구성 파일을 생성하세요:
다음 내용을 붙여넣고 /path/to/digna/dashboard를 압축을 푼 dashboard 폴더의 실제 경로로 바꾸세요:
server {
listen 8080;
server_name localhost;
root /path/to/digna/dashboard;
index index.html;
# Serve Markdown files with the correct MIME type.
types {
text/markdown md;
}
# Single-page-application fallback: unknown paths return index.html
# instead of a 404, so dashboard routes survive a browser refresh.
location / {
try_files $uri $uri/ /index.html;
}
}
중요
try_files 지시어가 없으면 루트 URL이 아닌 대시보드 페이지를 새로고침할 때 404가 반환됩니다. 이는 Windows의 IIS에서 요구되는 URL Rewrite 모듈과 동등한 nginx 설정입니다.
구성 적용¶
구성 문법 오류가 없는지 테스트한 다음 nginx를 다시 로드하세요:
Apache httpd 설정¶
개요¶
macOS에는 Apache httpd가 포함되어 있어 별도 설치가 필요 없습니다. 기본적으로 비활성화되어 있습니다.
Apache 시작¶
설치 확인¶
- 브라우저를 엽니다.
http://localhost로 이동합니다.- "It works!" 메시지가 표시되어야 합니다.
필수: mod_rewrite 활성화¶
대시보드는 URL 재작성 기능이 필요합니다. Apache 구성 파일을 엽니다:
다음 줄을 찾아 앞의 #를 제거하여 주석을 해제하세요:
필수: .htaccess 재정의 허용¶
같은 파일에서 <Directory "/Library/WebServer/Documents"> 블록을 찾아 다음을 변경하세요:
다음으로:
필수: Markdown 파일용 MIME 타입¶
여전히 httpd.conf에서 Markdown 파일이 올바르게 제공되도록 다음 줄을 추가하세요:
중요
이 설정이 없으면 .md 파일이 제대로 제공되지 않을 수 있습니다.
구성 적용¶
구성 문법 오류를 검사한 다음 Apache를 다시 시작하세요:
초기 설치¶
1단계: digna 리포지토리 설정¶
digna 리포지토리는 digna가 계산한 모든 메트릭을 저장합니다. 분석 및 성능 데이터의 중앙 데이터베이스 역할을 합니다.
리포지토리 스키마 및 사용자 생성¶
PostgreSQL 클라이언트(psql, pgAdmin 등)를 열고 다음 SQL 명령을 실행하세요:
CREATE SCHEMA <digna_repo_schema>;
CREATE USER <digna_repo_user> WITH PASSWORD '<digna_repo_password>';
GRANT ALL PRIVILEGES ON SCHEMA <digna_repo_schema> TO <digna_repo_user>;
다음 플레이스홀더를 교체하세요:
<digna_repo_schema>— 원하는 스키마 이름(예:dignarepo)<digna_repo_user>— 원하는 사용자 이름(예:digna_user)<digna_repo_password>— 이 사용자의 안전한 비밀번호
예시:
CREATE SCHEMA dignarepo;
CREATE USER digna_user WITH PASSWORD 'YourSecurePassword123!';
GRANT ALL PRIVILEGES ON SCHEMA dignarepo TO digna_user;
터미널에서 한 번에 실행하려면:
그런 다음 postgres=# 프롬프트에 위 명령들을 붙여넣고 \q를 입력하여 종료하세요.
권장 사항
데이터베이스 사용자에는 강력하고 복잡한 비밀번호를 사용하세요. 쉽게 추측 가능한 자격증명은 피하세요.
2단계: digna 설치 패키지 압축 해제¶
- 제공된 digna 설치 ZIP 파일을 찾습니다.
- 예를 들어
/opt/digna또는~/digna와 같은 원하는 설치 위치에 압축을 풉니다. - 압축을 풀면 다음 항목이 보여야 합니다:
dashboard/— 웹 대시보드 인터페이스digna— 메인 실행 파일(백엔드 + CLI 통합)
구성 파일과 라이선스 파일은 패키지에 포함되어 있지 않습니다
config.toml과 dashboard/dashboard_config.toml은 모두 설치 패키지에 포함되어 있지 않습니다. 두 파일은 백엔드 구성 및 대시보드 구성에서 직접 생성합니다. license.toml도 포함되어 있지 않으며, 3단계에서 설명하는 것처럼 digna가 별도로 제공합니다.
터미널에서 압축을 풀려면:
실행 파일에 실행 권한 부여¶
아카이브 전송 방법에 따라 실행 비트가 유지되지 않을 수 있습니다. 명시적으로 설정하세요:
macOS가 애플리케이션을 차단하는 경우¶
브라우저나 메일 클라이언트를 통해 다운로드된 파일에는 격리(quarantine) 속성이 추가됩니다. macOS에서 앱을 "개발자를 확인할 수 없어 열 수 없습니다"라고 보고하면 설치 디렉터리에서 해당 속성을 제거하세요:
또는 시스템 설정 → 개인정보 및 보안을 열어 페이지 하단 근처에서 차단된 항목을 찾아 열기 허용(Open Anyway) 을 클릭하세요.
참고
이 단계는 macOS가 실제로 실행 파일을 차단할 때만 필요합니다. SSH로 전송되었거나 내부 파일 공유로 전달된 패키지는 일반적으로 격리되지 않습니다.
3단계: 라이선스 파일 설치¶
중요
라이선스 파일은 설치 패키지에 포함되어 있지 않으며 digna에서 별도로 제공합니다.
- 제공된
license.toml파일을 찾습니다. config.toml및digna실행 파일이 있는 digna 설치 루트 디렉터리에 복사합니다.
이유: 라이선스 파일에는 고객 정보, 라이선스 만료일 및 디지털 서명이 포함되어 있습니다. 이 파일을 수정하지 마세요 — 변경하면 무효화됩니다.
설치 후 디렉터리 구조 예시:
/opt/digna/
├── config.toml (configuration file)
├── license.toml (YOUR LICENSE FILE - copy here)
├── digna (main executable)
├── bin/ (service management scripts)
└── dashboard/ (web interface)
└── (dashboard files)
백엔드 구성¶
1단계: 구성 파일 생성 및 편집¶
config_template.toml 파일이 digna 설치 디렉터리에 제공됩니다. 이를 config.toml로 이름만 변경하면 됩니다.
위치: /opt/digna/config.toml
텍스트 편집기에서 config.toml을 열고 아래 각 섹션을 구성하세요.
[app] 섹션¶
이 섹션은 대시보드와 백엔드 간의 교차 출처 리소스 공유(CORS)를 구성합니다:
[app]
DIGNA_APP_CORS_ALLOW_ORIGINS = ["http://localhost:5173"]
DIGNA_APP_CORS_ALLOW_CREDENTIALS = true
| 매개변수 | 값 | 설명 |
|---|---|---|
DIGNA_APP_CORS_ALLOW_ORIGINS | 대시보드 URL | 대시보드가 제공되는 URL. 그 밖의 origin에서 오는 브라우저 요청은 거부됩니다 |
DIGNA_APP_CORS_ALLOW_CREDENTIALS | true | 필수. 브라우저가 요청마다 세션 쿠키를 함께 보내도록 하는 데 필요합니다 |
참고
Homebrew의 nginx 기본 포트에서 대시보드를 제공하는 경우 허용할 origin은 http://localhost:8080입니다.
[app] 섹션은 선택 사항입니다
릴리스 2026.11부터는 두 키와 [app] 섹션 전체를 생략할 수 있습니다. 리버스 프록시가 대시보드와 백엔드를 하나의 origin으로 제공하는 경우에 적합한 구성입니다. 이 경우 브라우저는 교차 출처 요청을 보내지 않으며, 기본적으로 어떤 교차 출처 요청도 허용되지 않습니다.
[repo] 섹션¶
이 섹션은 PostgreSQL 데이터베이스 연결을 구성합니다:
[repo]
DIGNA_REPO_HOST = "localhost"
DIGNA_REPO_PORT = 5432
DIGNA_REPO_DB = "postgres"
DIGNA_REPO_SCHEMA = "dignarepo"
DIGNA_REPO_USER = "digna_user"
DIGNA_REPO_PASSWORD = "YourSecurePassword123!"
DIGNA_REPO_SSLMODE = "prefer"
DIGNA_REPO_NUM_CONNS = 16
| 매개변수 | 값 | 설명 |
|---|---|---|
DIGNA_REPO_HOST | localhost 또는 IP | PostgreSQL 서버 호스트명/IP |
DIGNA_REPO_PORT | 5432 (기본) | PostgreSQL 포트 |
DIGNA_REPO_DB | postgres | 데이터베이스 이름 |
DIGNA_REPO_SCHEMA | dignarepo | 이전에 생성한 스키마 |
DIGNA_REPO_USER | digna_user | PostgreSQL 설정에서 생성한 사용자 |
DIGNA_REPO_PASSWORD | 비밀번호 | 스키마 생성 시 설정한 비밀번호 |
DIGNA_REPO_SSLMODE | prefer (기본) | 선택 사항. PostgreSQL SSL 모드: disable, allow, prefer, require, verify-ca 또는 verify-full |
DIGNA_REPO_NUM_CONNS | 16 (기본) | 선택 사항. digna가 리포지토리에 열어 두는 연결 수 |
[base] 섹션¶
이 섹션은 보안, 쿠키 및 검사 설정을 포함합니다:
[base]
DIGNA_FERNET_KEY = "DU4a0yJ-OqvbKCL4hNQn_CsknH-V1vWmHZqBUl-AY44="
DIGNA_COOKIE_DOMAIN = "localhost"
DIGNA_COOKIE_SECURE = false
DIGNA_COOKIE_HTTPONLY = true
DIGNA_TOKEN_EXPIRES_IN = 86400
DIGNA_MAX_WORKERS = 4
DIGNA_FRONTEND_BASEURL = "http://localhost/"
DIGNA_SOURCE_QUERY_TIMEOUT_SEC = 3600
DIGNA_SOURCE_LOGIN_TIMEOUT_SEC = 30
| 매개변수 | 값 | 설명 |
|---|---|---|
DIGNA_FERNET_KEY | 위에 표시된 값 | 이전 릴리스에서 사용하던 암호화 방식의 키. 반드시 있어야 하므로 위에 표시된 값을 그대로 유지하세요 |
DIGNA_COOKIE_DOMAIN | localhost | 대시보드에 접속하는 호스트. ""로 설정하면 도메인을 지정하지 않으며, 대시보드와 백엔드를 하나의 origin으로 제공하는 프록시 뒤에서는 이것이 올바른 설정입니다 |
DIGNA_COOKIE_SECURE | false (HTTP) / true (HTTPS) | digna를 HTTPS로 제공하는 경우 반드시 true여야 합니다 |
DIGNA_COOKIE_HTTPONLY | true | 스크립트가 세션 쿠키에 접근하지 못하도록 합니다 |
DIGNA_TOKEN_EXPIRES_IN | 86400 (24시간) | 세션 만료 시간(초) |
DIGNA_MAX_WORKERS | CPU 코어 수 - 1 | 동시에 실행할 수 있는 검사 수 |
DIGNA_FRONTEND_BASEURL | 대시보드 URL | 필수. 알림 메시지의 링크에 사용되므로 수신자가 열 수 있는 URL이어야 합니다 |
DIGNA_SOURCE_QUERY_TIMEOUT_SEC | 3600 (기본) | 선택 사항. 소스 데이터베이스에 대한 단일 쿼리가 중단되기 전까지 실행될 수 있는 시간(초). 0이면 타임아웃이 비활성화됩니다 |
DIGNA_SOURCE_LOGIN_TIMEOUT_SEC | 30 (기본) | 선택 사항. 소스 데이터베이스 연결을 기다리는 시간(초). 0이면 무기한 기다립니다 |
팁
Mac에서 사용 가능한 CPU 코어 수를 확인하려면 sysctl -n hw.ncpu를 실행하세요.
[encryption] 섹션¶
이 섹션에는 리포지터리에 저장된 민감한 값을 암호화하는 데 사용되는 키가 들어 있습니다. 필수입니다 — 키가 없으면 config check는 [encryption] 섹션을 FAILED로 보고합니다.
| 매개변수 | 값 | 메모 |
|---|---|---|
DIGNA_ENCRYPTION_KEY | Base64로 인코딩된 키 | digna 리포지터리에 저장된 민감한 값을 암호화합니다 |
config.toml 보호
이 키는 고정된 값으로 모든 digna 설치에서 동일하며, 리포지터리의 민감한 값을 복호화하는 것이 바로 이 키입니다. config.toml 접근을 digna를 실행하는 계정으로 제한하고, 버전 관리와 공유 드라이브에서 제외하며, 리포지터리 자체보다 덜 안전하게 보관되는 백업에서는 반드시 빼십시오.
[logging] 섹션¶
이 섹션은 로깅 동작을 구성합니다:
| 매개변수 | 값 | 설명 |
|---|---|---|
DIGNA_LOGGING_MODE | INFO 또는 DEBUG | 운영 환경은 INFO, 문제 해결 시 DEBUG. TRACE, WARN, ERROR도 사용할 수 있습니다 |
DIGNA_LOGGING_DIR | logs (기본) | 선택 사항. 순환되는 로그 파일을 저장할 디렉터리(작업 디렉터리 기준 상대 경로) |
DIGNA_LOGGING_MAX_FILES | 30 (기본) | 선택 사항. 보관할 순환 로그 파일 수 |
[duckdb] 섹션 (선택 사항)¶
릴리스 2026.11의 새 기능입니다. 이 섹션은 digna Engine의 리소스를 설정합니다. digna Engine은 프로파일링 위치가 digna Engine인 데이터베이스 연결에 대해 digna 내부에서 데이터를 프로파일링하고, 서로 다른 데이터베이스 연결에 있는 데이터 소스 간의 참조 무결성 검사를 실행합니다. 참조: 프로파일링 위치.
이 섹션은 선택 사항입니다. 이 섹션이 없으면 아래의 기본값이 적용됩니다.
| 매개변수 | 값 | 설명 |
|---|---|---|
DIGNA_DUCKDB_MEMORY_LIMIT_MB | 1024 (기본) | digna Engine 실행 한 번이 사용할 수 있는 메모리(MB). 최대 DIGNA_MAX_WORKERS개의 실행이 동시에 활성화될 수 있습니다 |
DIGNA_DUCKDB_TEMP_DIRECTORY | 기본값: 시스템 임시 디렉터리(digna를 실행하는 계정의 $TMPDIR) | 데이터가 메모리에 들어가지 않을 때 임시 파일을 저장할 디렉터리 |
digna Engine 용량 산정
digna 자체가 사용하는 메모리 외에, digna 호스트에 최대 DIGNA_MAX_WORKERS × DIGNA_DUCKDB_MEMORY_LIMIT_MB의 메모리를 추가로 계획하세요. 또한 임시 디렉터리에는 digna Engine을 사용하는 데이터 소스 중 가장 큰 검사 날짜의 데이터를 담을 수 있을 만큼의 여유 디스크 공간이 필요합니다. DIGNA_DUCKDB_TEMP_DIRECTORY가 그만한 공간이 있고 digna를 실행하는 계정이 쓸 수 있는 디스크를 가리키도록 설정하세요:
이 섹션은 하나 이상의 데이터베이스 연결이 digna Engine을 사용하거나, 참조 무결성 검사가 서로 다른 연결에 있는 데이터 소스를 비교하는 경우에만 필요합니다.
2단계: 구성 검증¶
리포지터리를 초기화하기 전에 config.toml이 완전하고 올바르게 구성되었는지 확인하십시오. digna 설치 디렉터리에서 다음을 실행합니다:
각 섹션은 개별적으로 검증되므로 하나의 오류가 나머지 상태를 가리지 않습니다:
Configuration validation report (source: config.toml):
- App config: OK
- Repository config: OK
- Base config: OK
- Logging config: OK
- Encryption config: OK
- OIDC config(s): OK
- Template overrides: OK
- Unknown keys: OK
Overall: OK
FAILED로 보고된 모든 항목을 수정한 뒤, 계속하기 전에 명령을 다시 실행하십시오. Unknown keys 아래의 WARNING은 config.toml에 있지만 digna가 읽지 않는 키를 나열합니다. 이 키들은 아무 효과가 없으므로 제거하거나 철자를 바로잡으십시오. 전체 옵션 목록은 CLI 참조에 있습니다.
3단계: 리포지토리 초기화¶
- 터미널을 엽니다.
- digna 설치 디렉터리(예:
config.toml과digna실행 파일이 있는 위치)로 이동합니다. - 연결 테스트를 실행하세요:
새 스키마에서는 명령이 연결한 다음, 아직 리포지토리가 설치되지 않았다고 보고합니다:
이 시점에서는 이것이 예상된 결과이며, digna가 PostgreSQL과 스키마에 도달할 수 있음을 확인해 줍니다. 대신 연결 오류나 인증 오류가 나타나면 [repo] 섹션 또는 PostgreSQL 설정을 확인하세요.
참고
macOS에서는 현재 디렉터리의 명령이 PATH에 포함되지 않으므로 실행 파일을 digna가 아닌 ./digna로 호출합니다. 모든 곳에서 짧은 형태를 사용하려면 설치 디렉터리를 PATH에 추가하세요:
4단계: 리포지토리 스키마 설치¶
같은 디렉터리에서 다음을 실행하세요:
이 명령은 리포지토리 스키마에 필요한 테이블을 설치하고 다음 메시지로 완료됩니다:
repo upgrade는 설치와 업그레이드를 모두 수행합니다
릴리스 2026.11부터 repo upgrade는 새 리포지토리를 설치하고 기존 리포지토리를 업그레이드합니다. repo install도 같은 명령의 다른 이름으로 계속 사용할 수 있습니다.
5단계: 관리자 사용자 생성¶
관리자 사용자는 리포지토리 스키마에 직접 생성되므로 아직 서버를 실행할 필요가 없습니다. digna 설치 디렉터리에서 다음을 실행하세요:
예시:
이렇게 하면 이메일 주소가 admin@example.com이고 전체 관리자 권한을 가진 사용자가 생성됩니다.
팁
비밀번호를 작은따옴표로 묶어 사용하세요. zsh는 !, $, * 같은 문자를 특별하게 처리하므로 따옴표로 묶지 않으면 의도한 대로 전달되지 않을 수 있습니다.
권장 사항
대소문자, 숫자 및 특수 문자를 혼합한 강력한 비밀번호를 사용하세요.
6단계: digna 서버 시작¶
digna 설치 디렉터리에서 서버를 시작하세요:
매개변수: - --address — 서버 호스트명/IP (기본값 127.0.0.1) - --port — 서버 포트 (기본값 8000)
서버가 시작되면 수신 대기 중인 주소를 출력합니다:
팁
서버를 처음 시작할 때 macOS가 애플리케이션의 수신 네트워크 연결 허용을 묻는 경우 허용(Allow) 을 클릭하세요. 허용하지 않으면 대시보드가 백엔드에 접근할 수 없습니다.
서버가 터미널을 점유합니다
serve는 포그라운드에서 실행되며 Ctrl+C로 중지할 때까지 계속 동작합니다. 설정을 마칠 때까지 실행 상태로 두십시오. 대신 부팅 시 자동으로 시작하려면 다음을 참조하십시오: digna를 백그라운드 서비스로 실행.
대시보드 구성¶
1단계: 대시보드를 웹 서버에 배포¶
digna 대시보드는 자체 구성을 dashboard/dashboard_config.toml에서 읽습니다. 이 파일은 설치 패키지에 포함되어 있지 않으므로, 대시보드 파일과 함께 dashboard/ 디렉터리에 직접 생성해야 합니다.
파일의 내용은 Single Sign-On에서 설명하며, 이 파일이 필요한 곳도 바로 그곳입니다. 이 파일에는 대시보드가 제공하는 로그인 옵션과, 다중 인스턴스 배포의 경우 백엔드 연결 정보가 담깁니다.
웹 서버를 선택한 다음 해당 배포 단계를 따르세요.
nginx에 배포¶
nginx 설정 섹션을 따랐다면 서버 블록이 이미 dashboard 폴더를 가리키므로 복사할 필요가 없습니다.
- 경로 확인
$(brew --prefix)/etc/nginx/servers/digna.conf파일을 엽니다.-
root가 압축을 푼dashboard폴더를 가리키는지 확인합니다. -
폴더가 읽기 가능하도록 설정
-
nginx 재로드
-
설치 테스트
- 브라우저를 엽니다.
http://localhost:8080(또는 구성한 URL)로 이동합니다.- digna 대시보드 로그인 페이지가 표시되어야 합니다.
Apache httpd에 배포¶
-
대시보드를 문서 루트로 복사
-
재작성 규칙 추가
대시보드 경로가 새로고침 시 유지되도록 배포된 폴더 안에 .htaccess 파일을 만듭니다:
다음 내용을 붙여넣으세요:
RewriteEngine On
RewriteBase /digna/
# Serve existing files and directories as-is.
RewriteCond %{REQUEST_FILENAME} -f [OR]
RewriteCond %{REQUEST_FILENAME} -d
RewriteRule ^ - [L]
# Everything else falls back to the single-page application entry point.
RewriteRule ^ index.html [L]
-
Apache 재시작
-
대시보드 접속
- 브라우저를 엽니다.
http://localhost/digna로 이동합니다.- digna 대시보드 로그인 페이지가 표시되어야 합니다.
digna를 백그라운드 서비스로 실행하기¶
왜 digna를 서비스로 실행해야 하나요?¶
digna 백엔드를 백그라운드 서비스로 실행하면 다음과 같은 이점이 있습니다:
- 머신 부팅 시 자동으로 시작됩니다.
- 열린 터미널 창 없이 백그라운드에서 실행됩니다.
- 충돌 시 자동으로 재시작됩니다.
- macOS의 서비스 관리자
launchctl을 통해 관리할 수 있습니다.
서비스 관리 파일¶
필요한 모든 파일은 digna 설치 디렉터리의 bin/ 아래에 있습니다.
다음 셸 스크립트들이 제공됩니다:
install_service.sh— digna를 launchd에 등록uninstall_service.sh— 서비스 등록 해제start_service.sh— 등록된 서비스 시작stop_service.sh— 실행 중인 서비스 중지
관리자 권한 필요
부팅 시 시작되도록 서비스를 등록하려면 /Library/LaunchDaemons에 기록해야 하므로 모든 스크립트는 sudo로 실행해야 합니다.
스크립트에 실행 권한 부여¶
추출 과정에서 실행 비트가 유지되지 않을 수 있습니다. 처음 사용하기 전에:
서비스 설치¶
-
터미널을 엽니다.
-
bin 폴더로 이동
-
설치 스크립트 실행
이제 digna 서버가 자동 시작이 활성화된 상태로 launchd에 등록됩니다. 서비스는 즉시 시작되지 않으니, 다음 섹션을 참조하여 시작하세요.
서비스 시작 및 중지¶
서비스를 시작하려면¶
- 터미널을 엽니다.
/opt/digna/bin으로 이동합니다.- 다음을 실행하세요:
서비스를 중지하려면¶
- 터미널을 엽니다.
/opt/digna/bin으로 이동합니다.- 다음을 실행하세요:
팁
애플리케이션 파일을 업데이트하기 전에 항상 서비스를 중지하세요.
서비스 확인¶
서비스가 등록되고 실행 중인지 확인하려면:
프로세스 ID로 시작하는 줄이 있으면 서비스가 실행 중입니다. 첫 번째 열에 -가 있으면 등록은 되어 있으나 중지된 상태입니다.
설치 위치를 변경하는 경우¶
launchd는 실행 파일의 절대 경로를 저장하므로 설치 위치를 옮기면 서비스를 다시 등록해야 합니다:
-
현재 서비스 제거
-
애플리케이션 파일 이동
-
서비스 재설치
-
서비스 시작
서비스 제거¶
-
실행 중인 서비스 중지
-
서비스 등록 해제
이제 digna 서버가 launchd에서 등록 해제되었습니다.
새 릴리스로 업그레이드하기¶
이 섹션에서는 릴리스 2026.06 설치를 릴리스 2026.11로 업그레이드합니다. 설치가 그보다 오래된 경우 먼저 릴리스 2026.06 이전 릴리스에서 업그레이드를 읽으십시오.
업그레이드 전에¶
digna 저장소 백업 생성은 필수입니다
digna를 업그레이드하기 전에 저장소(PostgreSQL)를 백업하여 데이터 손실에 대비하십시오. 백업이 있으면 업그레이드 중 예기치 않은 문제가 발생해도 복구할 수 있습니다.
터미널에서 백업을 생성하려면:
릴리스 2026.11용 라이선스 파일 요청
릴리스 2026.11에는 새 license.toml이 필요합니다. 시작하기 전에 digna 팀에 요청하고, 7단계에서 사용할 수 있도록 준비해 두십시오.
릴리스 2026.06 이전 릴리스에서 업그레이드¶
릴리스 2026.06에서는 세 가지 변경 사항이 도입되었으며, 이전 설치를 2026.11로 바로 업그레이드할 때에도 여전히 적용됩니다:
- ODBC 전용. digna는 모든 소스 기술에 ODBC로 접근합니다. 아직 ODBC를 사용하지 않는 모든 데이터베이스 연결은 업그레이드 후 ODBC로 변경해야 하며, 자동 변환은 없습니다. 미리 digna 호스트에 ODBC 드라이버를 설치하고(참조: digna 호스트에 ODBC 드라이버 설치), 기술별 안내서를 참고해 각 연결의 속성을 준비해 두십시오. Databricks Legacy 커넥터는 더 이상 존재하지 않습니다. 해당 연결은 Databricks 커넥터로 이전하십시오.
- 단일 실행 파일.
dignabackend와dignacli는 백엔드와 CLI를 통합한 단일 실행 파일digna로 대체되었습니다. - config.toml.
[encryption]섹션이 필수이며,DIGNA_APP_HOST와DIGNA_APP_PORT는 더 이상 읽지 않습니다. 서버는 주소와 포트를digna serve에서 받습니다. 사용 중인 파일을 백엔드 구성과 비교하십시오.
아래 단계에서는 이전 설치에서 다른 작업이 필요한 부분을 알려 줍니다. 8단계의 저장소 업그레이드는 이전 어느 릴리스의 저장소든 바로 2026.11로 업그레이드합니다.
업그레이드 절차¶
1단계: digna 서비스 중지¶
digna가 백그라운드 서비스로 실행 중이면 먼저 중지하십시오:
digna가 포그라운드에서 실행 중이면 해당 터미널 창에서 Ctrl+C를 누르십시오.
2단계: 현재 설치 백업¶
digna 설치 디렉터리에서 현재 설치의 실행 파일과 대시보드 폴더 이름을 변경하여, 새 릴리스를 나란히 배포할 수 있도록 하십시오:
digna_old는 업그레이드를 확인할 때까지, dashboard_old는 거기에서 구성 파일을 복원할 때까지 보관하십시오 (4단계 참조). 그 후에는 둘 다 삭제해도 됩니다.
릴리스 2026.06 이전 릴리스에서 업그레이드하는 경우
실행 파일 대신 dignabackend와 dignacli 폴더의 이름을 변경하십시오: mv dignabackend dignabackend_old 및 mv dignacli dignacli_old. 둘 다 릴리스 2026.11에서는 사용되지 않습니다.
3단계: 새 버전 압축 해제 및 배포¶
- 새 digna 설치 ZIP 파일을 압축 해제합니다.
- 새
digna실행 파일과dashboard폴더를 설치 디렉터리에 복사합니다. - 실행 권한 비트를 복원하고, 필요한 경우 격리(quarantine) 속성을 제거합니다:
중요
config.toml과 dashboard/dashboard_config.toml은 모두 설치 ZIP에 절대 포함되지 않습니다. digna 팀은 두 파일 중 어느 것도 제공하지 않습니다. 따라서 기존 구성은 업그레이드의 영향을 받지 않으며, 이름이 변경된 *_old 폴더에 있는 사본이 유일한 사본입니다.
4단계: 구성 파일 복원¶
릴리스 2026.11에서는 config.toml을 변경할 필요가 없습니다. 릴리스 2026.06에서 동작하는 파일은 계속 동작합니다. 다음 두 가지 변경은 선택 사항입니다:
- 데이터베이스 연결에서 digna Engine을 사용하고 그 기본값이 호스트에 맞지 않는 경우
[duckdb]섹션을 추가합니다. - 리버스 프록시가 대시보드와 백엔드를 하나의 오리진으로 제공하는 경우
[app]섹션을 생략합니다.
digna가 읽지 않는 설정
이 가이드의 이전 버전에는 digna가 읽지 않는 일부 설정이 나와 있었습니다. 이 설정들은 아무 효과가 없으며, 6단계에서 config check가 Unknown keys 아래에 나열합니다. 제거하거나 수정하십시오:
DIGNA_SCHEDULER_MAX_DELAY,DIGNA_CLEANUP_TIME,digna_COOKIE_PATH,digna_COOKIE_SAME_SITE,digna_APP_CORS_ALLOW_METHODS,digna_APP_CORS_ALLOW_HEADERS및digna_LOGGING_BACKUP_COUNT는 존재하지 않습니다. 제거하십시오.- 설정 이름은 대소문자를 구분합니다. digna는
digna_REPO_HOST가 아니라DIGNA_REPO_HOST를 읽습니다. 백엔드 구성에서처럼 모든 이름을 대문자로 작성하십시오.
Single Sign-On: [[oidc_clients]]를 유지하십시오
digna는 Single Sign-On 공급자를 [[oidc_clients]] 항목의 목록으로 읽으며, 각 항목에는 고유한 DIGNA_OIDC_KEY가 있습니다. 이 가이드의 이전 버전에 따라 공급자를 [oidc_clients.<key>] 섹션으로 변경했다면 다시 원래대로 되돌리십시오. 그 형식이 남아 있는 동안 config check는 OIDC config(s)를 FAILED로 보고합니다:
[[oidc_clients]]
DIGNA_OIDC_KEY = 'microsoft'
DIGNA_OIDC_CLIENT_ID = '<client_id>'
DIGNA_OIDC_CLIENT_SECRET = '<client_secret>'
DIGNA_OIDC_REDIRECT_URI = 'http://localhost:3000/oidc/callback'
DIGNA_OIDC_CONFIGURATION_URL = 'https://login.microsoftonline.com/<tenant_id>/v2.0/.well-known/openid-configuration'
공급자마다 이 항목을 반복하고, 각 DIGNA_OIDC_KEY를 dashboard_config.toml의 key와 동일하게 유지하십시오. Single Sign-On을 사용하는 설치에만 해당됩니다.
5단계: 웹 서버 다시 로드¶
대시보드는 정적 파일의 집합이므로, 웹 서버와 브라우저가 여전히 이전 버전을 제공하고 있을 수 있습니다. dashboard 폴더를 호스팅하는 웹 서버를 다시 로드하거나 재시작한 다음, 강력 새로 고침(Cmd+Shift+R)으로 페이지를 다시 로드하십시오.
6단계: 구성 검증¶
리포지터리를 건드리기 전에 config.toml이 완전한지 확인하십시오:
모든 섹션이 OK로 보고되어야 합니다. FAILED로 보고된 항목을 모두 수정하고 Unknown keys 아래에 나열된 키를 제거한 다음, 계속하기 전에 명령을 다시 실행하십시오.
7단계: 라이선스 파일 교체¶
라이선스 파일은 보통 한 릴리스에서 다음 릴리스로 그대로 이어집니다. 릴리스 2026.11은 예외입니다. 이 릴리스는 라이선스가 필요한 두 모듈, digna Data Reconciliation과 digna Agentic을 추가하며, 2026.11 이전에 발급된 라이선스에는 이 모듈들이 포함되어 있지 않습니다. digna 팀이 릴리스 2026.11용으로 제공한 license.toml을 설치 디렉터리에 복사하여 기존 파일을 교체하십시오:
이전 라이선스를 유지하지 마십시오
이전 라이선스로도 digna는 시작되지만, digna Data Reconciliation과 digna MCP Server는 비활성화된 상태로 남습니다. 라이선스를 확인하는 모든 명령(user, inspection, repo)은 확인에 실패하면 리포지터리를 건드리기 전에 중단됩니다. 다음 단계로 넘어가기 전에 새 라이선스를 확인하십시오:
8단계: 저장소 스키마 업그레이드¶
digna 설치 디렉터리에서 다음을 실행하십시오:
릴리스 2026.11은 버전이 지정된 마이그레이션으로 저장소 스키마를 관리합니다. 이전 릴리스에서 처음 업그레이드할 때는 스키마를 이전 방식의 마지막 버전으로 올리고, 이를 시작점으로 기록한 다음, 릴리스 2026.11의 마이그레이션을 적용합니다. 다음 메시지로 완료됩니다:
기존 데이터는 모두 보존됩니다. 언제든지 ./digna repo check를 실행하면 저장소 상태를 확인할 수 있으며, 마지막으로 적용된 마이그레이션과 대기 중인 마이그레이션이 나열됩니다.
저장소가 최신이 아니면 digna가 시작되지 않습니다
릴리스 2026.11부터는 저장소 업그레이드가 필요한 동안 서버가 시작을 거부하고 그 사실을 알려 줍니다. 예:
서버나 서비스를 시작하기 전에 repo upgrade를 실행하십시오.
9단계: 서비스 재시작¶
백그라운드 서비스로 실행 중인 경우:
수동으로 실행 중인 경우 서버를 재시작하십시오:
nginx 또는 Apache를 사용하는 경우 해당 웹 서버를 재시작하십시오:
10단계: 업그레이드 확인¶
-
새 실행 파일의 릴리스를 확인합니다:
첫 번째 줄이
Release: 2026.11이어야 합니다. -
digna 대시보드에 접속하여 인터페이스가 올바르게 로드되는지 확인합니다.
- 서버 출력과
logs디렉터리의 파일에 오류가 있는지 확인합니다. - 데이터베이스 연결을 테스트합니다. 참조: 연결 테스트. 릴리스 2026.06 이전 릴리스에서 업그레이드한 경우 먼저 아직 ODBC를 사용하지 않던 모든 연결을 ODBC로 전환하십시오.
새 모듈을 시작하려면 digna Data Reconciliation, digna MCP Server에 대해서는 AI 에이전트 연결, digna Engine에 대해서는 프로파일링 위치를 참조하십시오.