설치 후 정상동작 확인
설치가 끝났으면 ① 모니터링 화면 확인 → ② AI 모델 연결 두 가지면 바로 쓸 수 있습니다.
화면이 안 뜨거나 빨간 항목이 있을 때만 ③ 명령어로 점검합니다.
모니터링 화면에서 서비스 확인
관리자 계정으로 로그인한 뒤, 아래 경로로 모니터링 화면을 엽니다. 핵심 서비스가 한 화면에 모두 표시됩니다.
좌측 하단 관리자 › 시스템 설정 › 시스템 & 모니터링 › 모니터링
모니터링 화면은 관리자 권한 계정에서만 보입니다.
모니터링 화면 - 상단 ‘서비스 상태 6/6’ 와 ‘서비스 / 실시간’ 6개 카드.
가운데 서비스 / 실시간 영역에 6개 카드가 있습니다. 각 카드가 정상이면 그 서비스는 살아있는 것입니다.
| 카드 (화면 명칭) | 확인하는 것 | 정상 표시 예 |
|---|---|---|
| Repository | 데이터베이스(PostgreSQL) 연결 | PostgreSQL 16.x |
| LLM API | AI 모델 연결 (2단계에서 설정) | gpt-oss-120b |
| OLAP Engine | 분석, 집계 엔진 | In-Memory OLAP |
| Elasticsearch | 검색 엔진, 노드, 인덱스 | 노드 1, 인덱스 N |
| Redis 캐시 | 캐시 연결 | Redis 7.x |
| 임베딩 모델 | 임베딩 모델 로드 | BAAI/bge-m3 |
6개가 모두 정상이면 설치 완료입니다. 데이터베이스, AI 모델, 분석, 검색, 캐시, 임베딩까지 모두 살아있다는 뜻입니다.
상단 ‘서비스 상태’ 배지가 6 / 6 이면 동일한 의미이고, 그 옆 CPU, 메모리, 디스크, PG 풀로 서버 자원 여유도 함께 봅니다. 모든 값은 실시간 실측 - 각 서비스에 실제로 연결을 확인(ping)해 받아온 결과입니다.
AI 모델 서버는 PRISM에 포함되지 않아 2단계에서 연결을 설정해야 켜집니다.
나머지 5개(DB, OLAP, 검색, 캐시, 임베딩)가 정상이면 설치 자체는 잘 된 것입니다.
AI 모델(LLM) 연결
지금 받은 것은 PRISM 단독 설치 파일입니다. AI 모델은 포함되지 않고, 설치 시 모델 목록(연결 정보)만 등록됩니다. 따라서 gpt-oss-120b 를 쓰려면 사내에 LLM 모델 서버(vLLM)가 먼저 떠 있어야 하며, 설치 직후 어느 서버에 연결할지 한 번 지정해야 AI 분석 기능이 켜집니다.
좌측 하단 관리자 › 시스템 설정 › AI & 모델 › LLM 모델
LLM 모델 화면 - 설치 시 기본 등록된 모델 4종, 각 카드에 [연결 확인], [수정].
PRISM 분석은 도구 호출로 동작하므로 둘 다 통과해야 그 모델로 분석을 실행할 수 있습니다. 서버 연결만 되고 도구 호출이 안 되는 모델은 분석에 쓸 수 없습니다.
설치하면 모델 4종이 등록되어 있습니다. 상태는 활성(지금 쓰는 모델), 대기, 키 필요 로 표시됩니다.
| 모델 | 종류 | 기본 상태 |
|---|---|---|
| gpt-oss-120b (우리 120B) | OpenAI 호환, 로컬/사내 서버 | 활성, 키 불필요 |
| GPT-4o | OpenAI | 대기, API 키 필요 |
| Claude Opus 4.7 | Anthropic | 키 필요 |
| Gemini 2.5 Pro | 키 필요 |
하단 ‘새 모델’ 버튼으로 다른 모델을 추가할 수도 있습니다 (OpenAI, OpenAI 호환, Anthropic, 사용자 정의). 온프레미스 Qwen(3.8 권장, 3.6 이상), Gemma(사내 vLLM)나 외부 Gemini 등도 이렇게 추가하며, 표의 시드 모델은 키만 넣으면 바로 쓸 수 있습니다.
환경에 맞는 한쪽으로 설정합니다.
A. 온프레미스 LLM (사내 모델 서버)
사내 vLLM 서버에 gpt-oss-120b, Qwen, Gemma 가 떠 있는 경우
- gpt-oss-120b 카드의 [수정] 클릭
- 엔드포인트를 모델 서버 주소로 변경 (예:
http://<모델 서버 주소>:<포트>/v1) - 저장 후 [연결 확인] → 성공
- API 키는 보통 불필요
B. 네이티브 LLM (외부 API)
GPT-4o, Claude, Gemini 등 외부 모델을 쓰는 경우
- 쓰려는 모델 카드의 [수정] 클릭
- API 키 입력 후 저장
- [연결 확인] → 성공
- 카드 모델 메뉴(⋯) › 활성으로 전환 으로 기본 모델 지정 (외부 API 사용료 발생)
AI 모델이 아직 연결 안 됐으면 로그인 시 안내 창이 떠서 이 화면으로 안내합니다. 연결 후 1단계 모니터링의 LLM API 카드가 정상으로 바뀌면 완료입니다.
화면이 안 뜨거나 빨강일 때
모니터링 화면 자체가 안 열리거나 특정 카드가 빨강일 때만 서버 터미널에서 아래를 확인합니다. 정상이면 건너뛰어도 됩니다.
docker 로 시작하는 명령은 Podman 환경이면 docker 를 podman 으로 바꿔 실행하세요(예: docker logs 는 podman logs). 설치 위치도 Docker 는 /opt/prism-cosmos, Podman(일반 계정)은 ~/prism-cosmos 로 다릅니다.엔진과 상관없이 가장 간단한 점검은 함께 설치되는 운영 스크립트 한 줄입니다 - 컨테이너 상태와 서비스 헬스를 한 번에 보여 줍니다.
bash <설치경로>/prism-ctl.sh status # 컨테이너 상태 + 서비스 헬스 (Docker·Podman 공통)A. 로그인 화면조차 안 뜰 때 - 컨테이너 기동 확인
PRISM은 9개 컨테이너로 동작합니다. 외부 입구는 gateway(8200) 하나뿐이고 나머지는 내부 통신입니다.
cd /opt/prism-cosmos/ops/docker # 설치 루트(기본 /opt/prism-cosmos)
docker compose -f docker-compose.yml ps| 컨테이너 | 역할 | 정상 상태 |
|---|---|---|
| trinity-prism-gateway | 웹/API 입구 (포트 8200) | Up (healthy) |
| trinity-prism-tap | 질문, 분석 AI | Up (healthy) |
| trinity-prism-core | 메타, 임베딩, 그래프 | Up (healthy) |
| trinity-prism-tve | OLAP, 차트, 피벗 | Up (healthy) |
| trinity-prism-report | 정형 보고서 생성 | Up (healthy) |
| trinity-prism-updater | 버전 업데이트 | Up (healthy) |
| trinity-prism-pg | PostgreSQL 데이터베이스 | Up (healthy) |
| trinity-prism-es | Elasticsearch 검색 | Up (healthy) |
| trinity-prism-redis | Redis 캐시 | Up (healthy) |
9개가 모두 Up (healthy) 인지 봅니다. 웹 입구 응답도 함께 확인합니다.
curl http://<서버주소>:8200/health
# 정상: {"status":"ok","service":"prism-cosmos-tap"}B. LLM API 카드가 빨강일 때 - 모델 서버 도달 확인
설정(2단계)은 맞는데도 빨강이면, 모델 서버 자체가 떠 있는지 확인합니다. 아래는 우리 120B 기본 주소 예시입니다.
curl http://<모델 서버 주소>:<포트>/v1/models
# 응답이 없으면 모델 서버가 안 떠 있거나 사내망에서 안 닿는 것C. 증상별 대응
| 증상 | 원인 / 확인 | 조치 |
|---|---|---|
| 컨테이너가 Restarting / 목록에 없음 | 해당 서비스 기동 실패 | docker logs trinity-prism-<이름> --tail 50 |
| 8200 접속 안 됨 | gateway 미기동 또는 포트 / 방화벽 | gateway 상태, ss -tln | grep 8200 |
| LLM API 카드 빨강 | 모델 미연결(2단계) 또는 서버 미도달 | 2단계 설정, 위 B 확인 |
| 그 외 특정 카드 빨강 | 그 서비스 컨테이너 문제 | 해당 컨테이너 로그 확인 후 재기동 |
| Elasticsearch 카드 빨강 | 검색 엔진 미기동 | trinity-prism-es 상태, 로그 확인 |
전체 로그 보기
cd /opt/prism-cosmos/ops/docker # 설치 루트(기본 /opt/prism-cosmos) docker compose -f docker-compose.yml logs -f # 전체 docker compose -f docker-compose.yml logs -f tap # 특정 서비스
D. 설치/패치 중 막혔을 때
관리자 화면의 시스템 업데이트 로 패치하다 멈추거나 설치가 중간에 끊겼을 때, 웹 화면에 못 들어가도 서버 터미널에서 직접 확인합니다.
| 상황 | 확인 / 조치 (서버 터미널) |
|---|---|
| 설치 시작하자마자 중단 | 사전 점검(preflight) 미달 - 출력된 사유(CPU 4 vCPU, 메모리 28 GB, /var/lib/docker 여유 50 GB) 보강 후 재실행 |
| 패치 실행(RUN) 누르자마자 500 | 구버전을 최신으로 처음 올릴 때 일부 환경에서 발생합니다. 아래 복구 도구를 호스트에서 한 번 실행한 뒤 다시 패치하면 됩니다(데이터 변경 없음, 여러 번 실행해도 안전). |
| 자동 패치가 진행 안 됨 / 멈춤 | docker logs trinity-prism-updater --tail 100 - 적용 단계, 오류 확인 |
| 스키마(DB) 적용 이력 확인 | docker exec trinity-prism-pg psql -U cosmos -d cosmos -c "SELECT version, name, applied_at FROM prism_schema_migrations ORDER BY applied_at DESC LIMIT 10;" |
| 패치 후 특정 서비스만 비정상 | 해당 컨테이너 로그 확인 후 docker restart trinity-prism-<이름> (Podman 은 podman restart) |
Podman - 관리자 화면 시스템 업데이트 가 동작하지 않음 | 컨테이너 관리 소켓 또는 로그아웃 유지 설정이 꺼져 있을 수 있습니다. 아래를 확인·설정 후 다시 시도하세요. systemctl --user status podman.socket (비활성이면 systemctl --user enable --now podman.socket), loginctl show-user "$USER" | grep Linger (Linger=no 이면 loginctl enable-linger "$USER") |
| 패치 적용 후 문제 - 직전 버전으로 되돌리기 | 업데이트가 실패하면 적용 직전 스냅샷으로 자동 롤백됩니다. 수동 복원은 관리자 화면 시스템 업데이트 › 이력 에서 해당 업데이트의 [롤백] - 코드가 직전 버전으로 복원됩니다(데이터는 변경되지 않음). |
설치가 중간에 실패했을 때는 화면 캡처 대신 설치 로그 파일 하나만 기술연구소에 보내면 됩니다. 위치는 설치 패키지를 푼 폴더 안 install_log/prism-install-<날짜>-<시각>.log 입니다. 비밀번호 등 민감 정보는 자동으로 가려집니다.
패치 실행(RUN) 시 바로 500 이 뜰 때는 아래 복구 도구를 호스트에서 한 번 실행한 뒤 화면에서 다시 패치하세요. 데이터는 바뀌지 않고(컬럼 하나만 보강), 여러 번 실행해도 안전합니다.
bash recover_run500.sh # 호스트에서 실행 → 끝나면 화면에서 다시 패치trinity-prism- 로 시작하고 접미사가 붙지 않으며, 그 전에 설치한 기존 운영본은 cosmos- 로 시작하고 끝에 -prod 가 붙습니다. 이름은 설치 때 한 번 정해지고 패치/업데이트해도 그대로 유지됩니다.위 표는 신규 설치 기준
trinity-prism- 예시이며, 기존 cosmos-*-prod 인스턴스는 이름이 다릅니다. docker compose -f docker-compose.yml ps 로 실제 이름을 먼저 확인하세요.E. 재부팅 후 서비스가 안 올라올 때
새로 설치한 서버는 재부팅해도 자동으로 다시 켜지도록 설치기가 맞춰 둡니다. 다만 이 기능이 들어가기 전에 설치한 Podman 서버는 재부팅 후 서비스가 안 올라올 수 있습니다. 이때만 아래를 한 번 실행한 뒤 다시 기동하면 됩니다. (Docker 는 해당 없음)
systemctl --user enable podman-restart.service # root 계정으로 설치했다면 --user 없이 bash <설치경로>/prism-ctl.sh up # 그 다음 수동으로 한 번 기동
샘플 데이터로 분석까지 확인
설치 파일에는 확인용 샘플 데이터(매출 10건)와 그 데이터 원본 연결(‘데모 매출 DB’)이 기본으로 들어 있습니다. 메타만 직접 한 번 만들면(②) 질문/분석까지 한 바퀴 돌려, 화면이 뜨는 것뿐 아니라 실제 데이터 분석까지 잘 되는지 확인할 수 있습니다.
cosmos) 안 demo 스키마에 demo_sales 테이블(10건)이 자동으로 들어가고, 이 DB로 연결되는 데이터 원본 ‘데모 매출 DB’도 자동 등록됩니다.① 데이터 원본 확인 (자동 등록됨)
좌측 하단 관리자 › 시스템 설정 › 데이터 › 데이터 원본
설치하면 샘플 데이터베이스 연결 ‘데모 매출 DB’가 자동으로 등록됩니다. 데이터 원본 화면에 데모 매출 DB(PostgreSQL, 호스트 pg)가 보이는지 확인만 하면 됩니다. 따로 추가할 필요 없습니다.
호스트가
pg인 이유 - 외부 DB가 아니라 PRISM 안에 함께 들어 있는 데이터베이스라 내부 이름을 씁니다.② 메타 만들기 (메타 디자이너)
시스템 설정 › 데이터 › 메타 디자이너 (새 창으로 열림)
메타는 자동으로 만들어지지 않습니다. 아래 순서로 직접 한 번 만들면 됩니다.
- 상단 [파일] › [새 메타] - 빈 메타 탭이 생깁니다
- 오른쪽 속성 패널의 [데이터 원본 선택] 에서 데모 매출 DB 선택
- 가운데 [테이블 추가] 클릭 → 신규 메타라 ‘새 메타 저장’ 창이 먼저 뜹니다. 메타 이름을 넣고 카테고리를 ‘기본’으로 골라 [저장] (카테고리를 골라야 대화 화면 목록에 보입니다)
- 다시 [테이블 추가] → 테이블 선택에서 스키마
demo의demo_sales→ 모드는 자동 주행 → [메타 생성] → 완료 (유의어, 예상질문도 이때 같이 만들어집니다) - [실행] 탭에서 데이터 10건이 보이면 연결/조회 정상
- 왼쪽 메타 목록에서 만든 메타를 오른쪽 클릭 → [발행] (발행해야 대화 화면에서 쓸 수 있습니다)
③ 질문해서 답 확인
메인 대화 화면으로 가서, 방금 만든 메타가 들어 있는 업무 카테고리와 메타를 선택한 뒤 아래처럼 질문합니다.
| 이렇게 질문하면 | 이런 답이 나오면 정상 |
|---|---|
| 지역별 매출 합계를 보여줘 | 지역(서울, 부산, 대구, 인천)별 매출 합계 표, 차트 |
| 제품별 판매수량을 많은 순으로 보여줘 | 제품별 판매수량 막대 차트 |
| 월별 매출 추이를 보여줘 | 1~3월 매출 흐름 |
설치가 제대로 된 것입니다.
설치 완료 확인
1단계(모니터링 6/6 정상)와 2단계(AI 모델 연결)가 모두 정상이면 설치가 완료된 것입니다.
결과를 아래 확인서에 기록해 기술연구소, 프로젝트 PM에게 보고하세요.
설치 후 운영 - 백업과 정리
평소 운영에 필요한 것은 정기 백업과 보관 위치 정도입니다. 아래는 호스트에서 한 번씩 확인, 실행하는 명령입니다.
정기 백업
데이터베이스와 설정을 주기적으로 백업해 두면 장애나 서버 이전 시 그대로 복구할 수 있습니다. 운영 중에도 안전하게 실행됩니다.
# 데이터베이스 백업 (Docker) docker exec trinity-prism-pg pg_dump -U cosmos cosmos | gzip > /backup/prism-$(date +%F).sql.gz # Podman 은 docker 를 podman 으로: podman exec trinity-prism-pg pg_dump -U cosmos cosmos | gzip > ...
# 설정, 데이터 디렉터리 백업 (Docker) tar -czf /backup/prism-config-$(date +%F).tar.gz /opt/prism-cosmos /var/lib/prism # Podman 은 설치 폴더만: tar -czf /backup/prism-config-$(date +%F).tar.gz ~/prism-cosmos (데이터는 위 pg_dump 로 대체)
설치 위치, 중지 / 재시작
| 구분 | 위치 / 명령 |
|---|---|
| 설정 파일 | /opt/prism-cosmos/.env (Docker) · ~/prism-cosmos/.env (Podman) |
| 데이터 | /var/lib/docker (Docker 관리 볼륨) · ~/.local/share/containers (Podman) |
| 로그 보기 | bash <설치경로>/prism-ctl.sh logs <서비스> (Docker·Podman 공통) |
| 중지 / 재시작 | bash <설치경로>/prism-ctl.sh down 후 up (Docker·Podman 공통) |
docker compose up 같은 명령을 직접 부르면 기동 순서가 보장되지 않아 로그에 불필요한 오류가 쌓입니다.완전 제거 (필요 시)
아래 명령은 데이터베이스, 검색, 캐시 데이터를 모두 삭제하며 되돌릴 수 없습니다.
uninstall.sh 입니다. Docker · Podman 을 자동으로 판별해 컨테이너·볼륨·설치 폴더까지 한 번에 지웁니다. 먼저 --dry-run 으로 무엇이 지워질지 확인한 뒤 실행하세요(설치 안내의 완전 초기화 항목에서 받을 수 있습니다).
sudo bash uninstall.sh --dry-run # 무엇이 지워질지 먼저 확인 sudo bash uninstall.sh # 확인 후 전량 삭제 (Podman 은 sudo 없이)
스크립트 없이 수동으로 지울 때는 아래처럼 합니다. Docker 기준이며, Podman 환경이면 docker 를 podman 으로 바꾸고 경로도 /opt/prism-cosmos 대신 ~/prism-cosmos 입니다(데이터는 ~/.local/share/containers).
docker compose -p prism-cosmos-prod -f /opt/prism-cosmos/ops/docker/docker-compose.yml down
docker volume rm $(docker volume ls -q | grep cosmos_prod_) # 데이터 삭제 (복구 불가)
rm -rf /opt/prism-cosmos /var/lib/prism데이터 연결
서비스와 AI 모델이 모두 정상이면, 분석할 회사 데이터베이스를 연결해 사용을 시작합니다. (설치 검증과는 별개입니다.)
시스템 설정 › 데이터 › 데이터 원본 › 새 연결 에서 회사 DB를 등록합니다. 이름, 종류, 호스트, 포트, 계정을 입력하고 연결 테스트 후 저장합니다.
연결 가능한 데이터 원본 - 네트워크 DB 연결 9종(PostgreSQL, Amazon Redshift, Oracle, MS SQL Server, MySQL, MariaDB, IBM Db2, SAP OData, i-AUD)과 파일 업로드(Excel , CSV). (DuckDB는 내부 분석 엔진으로 외부 연결 대상이 아닙니다.)
연결 후 시스템 설정 › 데이터 › 메타 디자이너 에서 메타를 만들면 대화 화면에서 질문, 분석을 시작할 수 있습니다.