사내에 AI 도구를 구축하고 운영할 때 기술적인 설치 못지않게 중요한 것이 보안과 관리 체계다. Dify나 Continue 같은 도구는 내부 코드, 문서, 사용자 데이터를 직접 다루기 때문에 인증·권한·로그 전략이 미비하면 데이터 유출이나 무단 접근 같은 심각한 보안 리스크가 현실이 된다. 특히 온프레미스 환경은 퍼블릭 클라우드처럼 플랫폼 레벨의 보안 장치가 자동으로 제공되지 않는다. 운영팀이 직접 설계하지 않으면 아무도 대신해 주지 않는다는 의미다.
이 글은 Dify + Continue 조합을 온프레미스로 운영하는 팀을 위해, 인증(Authentication)·권한(Authorization)·로그(Log)의 세 축을 어떻게 설계하고 구성할지를 실무 기준으로 정리한다. 이미 설치된 환경을 가정하고, 보안 관리 레이어를 추가하는 관점으로 읽으면 된다.
1. 인증(Authentication) 전략
A. Dify — 이메일 기반 인증과 SSO 연동
Dify는 기본적으로 이메일 + 비밀번호 방식으로 계정을 관리한다. SMTP를 연동하면 이메일 인증 절차를 추가할 수 있어 외부 접근을 1차로 걸러낼 수 있다. 그러나 자체 SSO(Single Sign-On)는 기본 내장이 아니기 때문에, 사내 LDAP/Active Directory 계정과 묶으려면 추가 구성이 필요하다.
- SMTP 인증 설정:
docker-compose.yml의 환경 변수에MAIL_TYPE=smtp,SMTP_SERVER,SMTP_USERNAME,SMTP_PASSWORD를 지정하면 가입·초대 시 이메일 인증이 활성화된다. - OAuth2 프록시 연동: Keycloak이나 Authentik 같은 오픈소스 IdP 앞에 Nginx 리버스 프록시를 배치하고,
oauth2-proxy를 통해 Dify 접근 전에 사내 SSO 인증을 강제할 수 있다. 별도 코드 수정 없이 인증 레이어를 씌우는 방식이라 도입이 비교적 쉽다. - 초대 기반 가입 제한: Dify 설정에서 자유 가입(sign-up)을 비활성화하고 관리자 초대 방식으로만 계정을 생성하면, 내부망을 뚫더라도 계정 없이는 진입이 불가능하다.
B. Continue — API 키 기반 인증과 중앙 프록시
Continue 자체에는 사용자 인증 기능이 없다. VSCode 확장이 .continue/config.json에 저장된 API 키로 LLM 서버에 직접 호출하는 구조이기 때문이다. 이 구조의 위험은 API 키가 개발자 로컬 머신에 평문으로 저장될 수 있다는 점이다.
- 내부 LLM 프록시 도입: LiteLLM Proxy나 자체 Nginx 기반 API 게이트웨이를 두고, Continue의 API 엔드포인트를 외부 LLM이 아닌 내부 프록시로 향하게 한다. 프록시에서 요청자 IP, 사용자 토큰, 요청량을 제어할 수 있다.
- 팀 배포용 config 스크립트: 개인이 API 키를 직접 관리하지 않도록, Git 저장소에 설정 템플릿을 관리하고 온보딩 스크립트가 팀 공용 프록시 주소만 주입하도록 자동화한다. 실제 키는 프록시 서버에만 존재하게 된다.
- 키 교체 주기: 프록시 레이어가 있으면 키 교체 시 프록시 설정 하나만 바꾸면 된다. 개발자 로컬을 일일이 순회할 필요가 없어진다.
2. 권한(Authorization) 관리
A. Dify 권한 구조
Dify는 워크스페이스 단위로 역할(Role)을 구분한다. 실무에서는 이 구조를 팀 조직도에 맞춰 설계하는 것이 중요하다.
| 역할 | 주요 권한 | 권장 대상 |
|---|---|---|
| Owner | 워크스페이스 전체 관리, 모델 설정, 결제 | 인프라 담당자 1~2명 |
| Admin | App 생성·삭제, 사용자 초대·관리, 지식베이스 관리 | 팀 리드 또는 AI 운영 담당 |
| Member | App 사용·테스트, 채팅 이력 조회 | 일반 개발자·기획자 |
- 워크스페이스 분리: 팀별(개발팀/마케팅팀/데이터팀)로 워크스페이스를 나눠 App과 지식베이스를 격리한다. 한 팀의 내부 문서가 다른 팀에 노출되지 않도록 하는 가장 확실한 방법이다.
- App별 퍼블릭 접근 통제: Dify App 설정에서 “공개(Public)” 여부를 반드시 확인한다. 사내 전용 챗봇을 실수로 퍼블릭으로 열어두면 외부에서도 접근 가능해진다.
- API 키 스코프: App별로 발급되는 API 키는 해당 App에만 유효하다. 시스템 연동 시 필요한 App의 키만 사용하고, 불필요한 키는 즉시 폐기한다.
B. Continue 권한 통제 방안
Continue 자체의 권한 체계는 없지만, 프록시 레이어와 IDE 정책으로 실질적인 통제가 가능하다.
- 프록시 기반 접근 제어: LLM 프록시에서 요청자 토큰별로 허용 모델·일일 토큰 한도를 설정한다. 인턴·계약직 계정은 GPT-4급 모델 접근을 막고, 특정 팀에만 고비용 모델을 허용하는 식의 세분화가 가능하다.
- 컨텍스트 소스 제한:
config.json의contextProviders항목에서 팀원이 사용할 수 있는 컨텍스트 소스를 중앙에서 정의한다. 민감한 저장소나 데이터베이스는 컨텍스트 소스에서 제외한다. - Git 정책 연계: 팀 공용
config.json을 별도 내부 저장소에서 관리하고, 개인 수정을 금지하는 브랜치 보호 규칙을 적용한다. 설정 파일 자체가 권한 정의서 역할을 한다.
3. 로그(Log) 및 모니터링 전략
A. Dify 로그 설정
Dify는 Docker Compose 기반이라 로그 수집이 비교적 단순하다. 기본은 stdout/stderr로 출력되므로, 이를 중앙 로그 스택으로 흘려보내는 구성을 초기부터 잡아두는 것이 좋다.
- 로그 레벨 조정:
docker-compose.yml에서LOG_LEVEL=info(기본), 이슈 트래킹 중에는debug로 변경. 프로덕션에서debug를 상시 켜두면 로그 볼륨이 폭증하니 주의. - Loki + Grafana 스택: Promtail이 Docker 컨테이너 로그를 수집 → Loki에 저장 → Grafana 대시보드에서 시각화. 오픈소스 조합으로 설치 비용 없이 중앙 로그 관리가 가능하다.
- 요청 추적: Dify의
app_log_histories테이블에는 각 App 호출 이력이 남는다. 주기적으로 쿼리해 이상 사용 패턴(야간 대량 호출, 특정 계정의 급증 등)을 탐지하는 스크립트를 배치로 돌린다. - 알림 연동: Grafana 알림 규칙을 Slack 채널이나 이메일로 연결해 에러율 급증, 응답 지연 임계치 초과 시 담당자에게 즉시 통보되도록 구성한다.
B. Continue 로그 처리
Continue 자체에는 중앙 로그 저장 기능이 없다. VSCode 개발자 도구(Cmd+Shift+P → “Open Extension Logs”)에서 확장 로그를 확인할 수 있지만, 이는 개인 머신의 임시 로그다. 팀 차원의 감사 추적(Audit Trail)이 필요하다면 프록시가 유일한 해결책이다.
- 프록시 요청 로깅: LiteLLM Proxy의 경우
success_callback·failure_callback에 로깅 핸들러를 연결해 모든 LLM 요청/응답을 DB나 파일로 남길 수 있다. 사용자별 토큰 소비량, 에러율, 지연 시간을 자동 집계한다. - 프롬프트 내용 로깅 주의: 코드 내용이 포함된 프롬프트를 전문 저장하는 것은 개인정보·영업비밀 관점에서 법적 리스크가 있다. 메타데이터(요청 시각, 사용자 ID, 토큰 수, 응답 코드)만 로깅하고 내용은 해시 처리하는 정책을 내부적으로 정해두는 것이 권장된다.
- 이상 탐지 기준: 단일 사용자의 시간당 요청이 임계치를 넘거나, 비업무 시간대에 대량 요청이 발생하면 알림을 트리거하도록 프록시 규칙을 설정한다.
4. 보안 정책 권장 구성
인증·권한·로그 세 축을 종합한 최소 권장 구성을 아래 표로 정리한다. 규모가 작은 팀이라면 우선순위 “필수” 항목부터, 조직이 커지면 “권장” 항목을 순차 도입하면 된다.
| 항목 | 권장 방식 | 우선순위 |
|---|---|---|
| API 키 저장 | 환경 변수 또는 HashiCorp Vault / AWS Secrets Manager | 필수 |
| 네트워크 접근 | 내부망 전용 + 외부 포트 차단 (Nginx 80/443만 노출) | 필수 |
| HTTPS 적용 | Nginx + Let’s Encrypt 또는 사설 CA 인증서 | 필수 |
| LLM API 제어 | 내부 프록시 경유, IP/토큰별 요청 제한 | 필수 |
| SSO 연동 | Keycloak + oauth2-proxy로 Dify 앞단 인증 강제 | 권장 |
| 로그 중앙화 | Promtail + Loki + Grafana 스택 | 권장 |
| 이상 행위 탐지 | Grafana 알림 규칙 + Slack/이메일 통보 | 권장 |
| 정기 키 교체 | 90일 주기 API 키 로테이션 (프록시 레이어에서 1회로 완료) | 권장 |
5. 실전 구성 흐름 예시
위 전략들이 실제로 어떻게 연결되는지, 10인 규모의 개발팀 기준으로 흐름을 그려보면 이렇다.
- 개발자 로컬(VSCode) → Continue가 내부 LLM 프록시(LiteLLM)로 요청 전송. API 키는 프록시가 보유, 개발자 로컬에는 없음.
- LLM 프록시 → 요청자 토큰 검증 → 허용 모델 확인 → 외부 LLM API 호출 → 메타데이터 로그 저장.
- Dify 서버 → Nginx(HTTPS) → oauth2-proxy(Keycloak SSO) → Dify 앱 진입. 사내 LDAP 계정으로만 로그인 가능.
- Dify 워크플로 → 실행 이력을 PostgreSQL에 저장 → Promtail이 수집 → Loki 전송 → Grafana 대시보드에서 팀 전체 사용 현황 가시화.
- 알림 채널 → 에러율 5% 초과 또는 특정 계정 일일 10만 토큰 초과 시 Slack #ai-ops 채널로 자동 알림.
이 구성에서 개발자는 Continue를 평소처럼 쓰면 되고, 관리자는 Grafana 한 곳에서 전체 사용량과 이상 징후를 모니터링한다. 보안과 편의성을 둘 다 잡는 균형점이 여기에 있다.
마치며
온프레미스 AI 시스템을 안정적으로 운영하려면 도구 설치 이후의 단계가 더 중요하다. 인증은 “누가 들어올 수 있는가”, 권한은 “들어온 사람이 무엇을 할 수 있는가”, 로그는 “무슨 일이 있었는가”를 각각 답하는 세 개의 질문이다. 이 셋이 설계되어 있어야 AI 도구가 팀의 생산성 자산으로 안착할 수 있고, 감사 대응이나 보안 사고 시 명확한 추적 경로가 만들어진다.
작은 팀이라면 처음부터 모든 항목을 완성할 필요는 없다. “필수” 항목 4개로 시작해 팀이 성장하면서 레이어를 하나씩 추가하는 방식이 현실적이다. 다음 글에서는 이 시리즈의 마지막으로, 온프레미스 AI 환경의 운영 및 유지보수 팁을 정리한다.