👈 이전 글: [7탄] Gradle 기반 JBoss 자동 배포 스크립트 완성
💡 00. 왜 Ollama와 DeepSeek Coder인가?
요즘 Claude, Gemini 같은 AI 어시스턴트 없이는 불안해하는 개발자들이 많습니다. 하지만 금융권 같은 폐쇄망 환경에서는 이러한 SaaS 기반 AI 서비스에 접근 자체가 불가능합니다.
금융감독원 등 규제 기관의 지침 아래 폐쇄망은 외부 오픈을 원칙적으로 허용하지 않습니다. 아무리 좋은 AI 도구라도 외부 API를 호출하는 순간 보안 심의에서 바로 차단됩니다.
이러한 현실 때문에 최근에는 삼성(code.i), LG CNS(AI 코딩 어시스턴트), 슬렉슨(CodeCenter) 같은 국내 업체들이 폐쇄망에서 동작하는 온프레미스 AI 어시스턴트를 제안하고 있는 추세입니다. 저도 이러한 흐름에 맞게 폐쇄망 환경에서 AI 어시스턴트를 직접 구축하여 개발 효율성을 높이는 작업을 해보고 싶었습니다.
물론 상용 제품만큼의 완성도는 아닐 수 있습니다. 하지만 오픈소스 기반으로 직접 구축하고 그 아키텍처를 이해하는 과정 자체가 이 강좌의 핵심 가치입니다.
📌 왜 Ollama인가?
- ✅ 완전 오픈소스 (무료)
- ✅ REST API 기본 제공
- ✅ 폐쇄망 환경 완벽 지원
- ✅ 설치 간단 (ZIP 배포 방식 가능)
- ✅ 다양한 LLM 모델 지원
- ✅ Windows / Linux 모두 지원
📌 왜 DeepSeek Coder 6.7b인가?
- ✅ 코딩 특화 모델 (87% 코드 + 13% 자연어로 학습)
- ✅ Java / Spring / SQL 코드 이해력 우수
- ✅ 6.7b = 폐쇄망 서버 사양으로 충분한 가벼움
- ✅ 완전 무료 오픈소스
- ✅ GPU 없이 CPU만으로 구동 가능
💡 참고:
더 큰 모델(13b, 33b 등)은 성능이 좋지만 서버 사양 요구치가 급격히 올라갑니다. 금융권 폐쇄망 POC 용도로는 6.7b가 현실적인 최적의 선택입니다.
🖥️ 01. AI 서버 (Ollama) 권장 사양 가이드
⚠️ 주의: 아래 가이드는 GPU 없는 CPU 전용 환경 기준입니다. GPU가 있다면 훨씬 빠른 응답이 가능하지만, 금융권 폐쇄망 특성상 고가의 GPU 반입이 어려운 현실을 고려한 사양입니다.
📊 DeepSeek Coder 6.7b 기준 사양표
| 구분 | 동시 사용자 | CPU | RAM | 디스크 | 응답속도 |
| 최소 | 1~5명 | 8 Core | 16GB | SSD 50GB | 느림 (5~10초) |
| 권장 | 10명 | 16 Core | 32GB | SSD 100GB | 보통 (3~5초) |
| 안정 | 20명 | 32 Core | 64GB | SSD 200GB | 빠름 (1~3초) |
| 고성능 | 30명 이상 | 64 Core | 128GB | SSD 500GB | 매우 빠름 |
🏢 사용자 규모별 권장 구성
1️⃣ 10명 이하 (소규모 팀)
- CPU : Intel Xeon 16 Core 이상 (또는 AMD EPYC 16 Core 이상)
- RAM : 32GB (DDR4 이상)
- DISK: SSD 100GB 이상
- OS : Rocky Linux 8.x / Windows Server
- 모델: deepseek-coder:6.7b (약 4GB)
2️⃣ 20명 이하 (중규모 팀)
- CPU : Intel Xeon 32 Core 이상 (또는 AMD EPYC 32 Core 이상)
- RAM : 64GB (DDR4 이상)
- DISK: SSD 200GB 이상
- OS : Rocky Linux 8.x 권장
- 모델: deepseek-coder:6.7b + ChromaDB Vector DB 추가 고려
3️⃣ 30명 이상 (대규모 팀)
- CPU : Intel Xeon 64 Core 이상 (또는 AMD EPYC 64 Core 이상)
- RAM : 128GB 이상
- DISK: SSD 500GB 이상
- OS : Rocky Linux 8.x
- 모델: deepseek-coder:6.7b (또는 13b 대형 모델 검토)
- 비고: 로드밸런서 + AI 서버 이중화 검토 필수
💡 실무 팁: 금융권 POC 목적이라면 10~20명 기준 사양으로 시작하고, 반응 속도를 확인한 후 증설하는 것을 권장합니다. 처음부터 과투자(Over-provisioning)하면 예산 승인받기가 매우 어렵습니다!
🎯 02. AI 서버 주요 목적
폐쇄망 AI 서버의 핵심 목적은 단순한 '코드 자동완성'이 아닙니다.
1. 개발 표준 학습 및 준수 가이드
금융권 개발 표준(보안 코딩 가이드라인, 공통 모듈 사용 규칙, 네이밍 컨벤션, 예외 처리 표준 등)을 AI에게 학습시킵니다. 개발자가 표준에서 벗어난 코드를 작성하려 할 때 즉시 올바른 방향을 가이드합니다.
2. RAG (Retrieval-Augmented Generation) 활용
개발 표준 문서, 설계 문서, API 명세서, 기존 소스코드 등 사내 문서를 임베딩하여 ChromaDB(Vector DB)에 저장합니다. 개발자가 질문하면 환각 없이 관련 사내 문서를 기반으로 정확하게 답변합니다.
📈 기대 효과
| 항목 | 기대 효과 |
| 코드 표준 준수율 | AI의 실시간 가이드로 비약적 향상 |
| 신규 개발자 온보딩 | 사내 표준에 대한 AI 학습으로 적응 시간 단축 |
| 코드 리뷰 부담 | AI의 1차 검토로 시니어의 리뷰 시간 감소 |
| 반복 코드 작업 | AI 자동 생성으로 개발 공수 절감 |
| 보안 취약점 | 커밋 전 AI를 통한 사전 감지 가능 |
🏗️ 03. 전체 시스템 아키텍처
📂 프로젝트 폴더 구조
C:\projects\
├─ AI\ ← Ollama LLM 서버 (AI 엔진 서버)
├─ FinAI\ ← AI 코딩 어시스턴트 POC 프로젝트 (중계 서버 역할)
├─ FinVault\ ← 메인 개발 프로젝트 (JBoss EAP WAS)
└─ was\ ← JBoss EAP 서버 (향후 was1, was2로 이중화)
💡 중요: 윈도우 탐색기에서 보면 다 붙어 있는 폴더 같지만, 실제 운영 환경에서는 전혀 다른 구조입니다. 각 폴더는 물리적/논리적으로 독립된 서버로 분리되어 운영됩니다.
🌐 04. 네트워크 구성도 (폐쇄망 환경)
[외부 / 인터넷]
↓
[방화벽]
↓
[DMZ Zone : Web Server]
↓
[방화벽]
↓
[내부망 - 개발 영역]
┌─────────────────────────────┐
│ AI\ FinAI\ │
│ (Ollama) (POC 중계) │
│ │
│ FinVault\ was\ DB │
└─────────────────────────────┘
↓
[방화벽]
↓
[기간계 : 핵심 업무 시스템]영역별 역할
| 영역 | 역할 |
| DMZ Zone | 외부 요청을 1차로 받는 Web Server 위치 |
| 내부망 (개발) | 개발 서버 전체 영역. AI 엔진과 WAS가 위치함 |
| AI (Ollama) | 외부와 차단된 오프라인 상태에서 동작하는 LLM 엔진 서버 |
| FinAI | AI 코딩 어시스턴트 POC 중계 프로젝트 |
| FinVault + was | 메인 개발 프로젝트 및 JBoss EAP 실행 환경 |
| 기간계 (Core) | 핵심 업무 원장 시스템 (별도의 방화벽으로 강력 격리) |
🤖 05. AI 서버 간 통신 구조
POC 성공 시 데이터 흐름
개발자 IDE (코드 작성 및 AI 도움 요청)
↓
FinAI (POC 프로젝트 / 중계)
↓ (요청)
AI 서버 (Ollama LLM)
↓ (JSON 응답 반환)
FinAI (POC 프로젝트)
↓
FinVault + was (최종 코드 반영 및 구동)
📡 통신 방식 (REST API)
FinAI 중계 서버와 AI(Ollama) 서버 간의 통신은 철저히 HTTPS 기반의 REST API를 사용합니다.
POST http://AI서버IP:11434/api/generate
Content-Type: application/json
{
"model": "deepseek-coder:6.7b",
"prompt": "코드 작성 요청"
}
⚠️ 왜 단순 HTTP가 아닌 HTTPS인가?
폐쇄망이라도 내부 통신 암호화는 필수입니다. 금융권 보안 규정상 1) 서버 간 통신 암호화, 2) 인증서 기반 신뢰 검증, 3) 통신 로그 기록이 엄격하게 요구됩니다.
🔐 06. mTLS (상호 인증) 구성
mTLS란?
- 일반 HTTPS: 서버 인증서만 검증합니다. (클라이언트 → 서버 단방향)
- mTLS (Mutual TLS): 서버와 클라이언트가 서로의 인증서를 모두 검증합니다. (양방향 인증) "너도 증명해, 나도 증명할게"
인증서 구성 절차
- 내부 CA (Certificate Authority) 구축
- AI 서버 및 was1 서버용 인증서 발급
- 상호 인증서 교환 및 신뢰 저장소(Truststore) 설정
⚠️ 중요: 금융권에서는 외부 망과 단절되어 있으므로 공인 CA가 아닌 내부 사설 CA를 직접 구축하여 사용합니다. 외부 CA 호출 시도 시 보안 심의에서 차단됩니다.
📋 07. 방화벽 신청서 작성
⚠️ 경험: 아무리 시스템을 잘 만들어도 방화벽이 막혀 있으면 통신 자체가 불가능합니다. 개발을 시작하기 전, 네트워크 담당자에게 방화벽 신청부터 해야 전체 일정 지연을 막을 수 있습니다!
🚨 팩트 폭격: 왜 방화벽 신청부터 당장 해야 하는가?
신청서를 낸다고 당일이나 다음 날 바로 통신이 뚫릴 것이라 생각한다면 크나큰 오산입니다. 금융권은 보안 정책(스크립트)이 방화벽 장비에 일괄 적용되는 '방화벽 오픈 데이'가 주 1~2회(보통 화요일, 목요일 새벽)로 엄격하게 정해져 있습니다.
만약 화요일 오전에 신청서를 올렸다면? 이미 새벽에 스크립트가 돌았기 때문에 목요일까지 손가락을 빨며 기다려야 합니다. 결재가 늦어져서 목요일 타이밍마저 놓치면? 개발 한 주가 그냥 통째로 날아갑니다.
🗣️ 금융권 SI 프로젝트의 씁쓸한 현실 (PMO를 믿지 마라)
이런 인프라 종속성과 오픈 일정을 유기적으로 챙겨주는 경험 많은 PMO를 만나면 프로젝트가 참 편합니다. 하지만 요즘 SI 바닥의 현실은 그렇지 않죠.
자금력과 네임밸류로 사업을 수주한 대형 IT 서비스 기업(갑)은 실제 개발을 수행하지 않고, 수행사(을)에게 턴키(Turn-key) 구조로 통째로 넘겨버립니다. 그러면서 관리 명목으로 중간 마진을 챙기기 위해 PMO 조직에 자기네 인력들을 은근슬쩍 끼워 넣는 관행이 있습니다.
이들이 똑똑해서 방화벽 오픈 주기나 인프라 환경을 미리 세팅해 주면 다행이지만... 제가 현장에서 겪어본 대다수의 낙하산 PMO들은 그저 주간 회의 때 앉아서 **"그래서 개발 잘 되고 있죠? 진척률 몇 프로입니까?"**라고 앵무새처럼 묻는 사람들이 전부였습니다.
결론은 하나입니다. 내 개발 일정은 내가 챙겨야 합니다. 아키텍처 설계가 떨어지면 코딩 창을 열기 전에 방화벽 신청서부터 쓰십시오.
OUTBOUND 정책 (WAS → AI 서버)
| 출발지 IP | 출발 PORT | 목적지 IP | 목적 PORT | 프로토콜 | 용도 |
| was1 서버 IP | ANY | AI 서버 IP | 11434 | TCP / HTTPS | AI LLM API 요청 |
INBOUND 정책 (AI 서버 → WAS)
| 출발지 IP | 출발 PORT | 목적지 IP | 목적 PORT | 프로토콜 | 용도 |
| AI 서버 IP | 11434 | was1 서버 IP | ANY | TCP / HTTPS | AI LLM API 응답 |
✅ 08. 신규 서버 오픈 전 SAT 체크리스트
**SAT(System Acceptance Test)**는 신규 서버나 시스템을 오픈하기 전 모든 항목을 검증하고 공식 인수하는 절차입니다.
💡 금융권 실무 경험: SAT를 대충 넘기고 오픈한 시스템은 반드시 대형 장애를 냅니다. 귀찮더라도 무조건 꼼꼼히 거쳐야 하는 관문입니다!
- [ ] 1. 자산 등록: 서버 자산 등록, IP 할당 신청, MAC 주소 등록, 서버 용도 기술서 제출
- [ ] 2. 보안 검토: 취약점 스캔, 보안 진단(Hardening), OS 보안 설정, 불필요 포트 차단, 백신 설치
- [ ] 3. 네트워크: 방화벽 IN/OUT 정책 확인, VLAN 설정, DNS 등록
- [ ] 4. 인증서: 사설 CA 인증서 발급 신청 및 설치, mTLS 설정 확인
- [ ] 5. 변경관리: 변경요청서(RFC) 제출, 변경 심의 통과, 오픈 일정 확정
- [ ] 6. 테스트: 통신 테스트(Telnet/Curl), 부하 테스트, 장애 복구 테스트, 롤백 계획서 작성
🔄 09. DR (재해복구) 개념
💡 솔직한 시선: 저도 실제 DR 인프라 장비를 직접 만지며 운영해 본 경험은 없습니다. 철저히 개발자/AA(Application Architect) 관점에서 알아야 할 개념과, 직접 참여했던 DR 훈련 절차 위주로 설명합니다.
DR 유형 비교
| 구분 | COLD DR | HOT DR |
| 평소 상태 | 꺼져 있음 (Standby) | 켜져 있음 (Active) |
| 데이터 동기화 | 주기적 백업 | 실시간 복제 (Mirroring) |
| 복구 시간 | 수 시간 ~ 수 일 | 수 초 ~ 수 분 |
| 비용 | 저렴 | 매우 비쌈 |
| 적용 대상 | 비핵심 지원 시스템 | 계정계 등 최상위 핵심 시스템 |
실제 DR 훈련 절차 (경험 기반)
- 메인 시스템 종료 (장애 시뮬레이션)
- DR 시스템 기동
- 각 시스템 정상 동작 확인 (WAS 기동, DB 접속, 주요 업무 화면 확인)
- 증적 수집 (화면 캡처, 시스템 로그 추출, 담당자 서명)
- 메인 시스템 복구 (원복)
- DR 결과 보고서 제출
(참고: Hitachi VSP, F5 BIG-IP 등 물리적 DR 장비의 세부 설정은 인프라/운영 팀의 영역이므로 본 강좌에서는 다루지 않습니다.)
🚀 다음 편 예고
엔터프라이즈급 네트워크 설계와 보안 정책 수립을 마쳤습니다. 이어지는 다음 탄에서는 드디어 폐쇄망 내 실제 AI 환경 구축의 첫 단추를 끼웁니다!
[Step 1] 폐쇄망(Air-Gapped) 환경에 Ollama 오프라인 설치 및 세팅, GGUF 모델 로드, REST API 정상 동작 확인 (※ FinAI 배포 및 Vector DB(ChromaDB)를 활용한 RAG 구현, VS Code 연동 등은 9탄의 오프라인 뼈대 완성 후 이어지는 시리즈에서 단계별로 딥다이브할 예정입니다!)
'온프레미스 개발환경' 카테고리의 다른 글
| [9탄] 폐쇄망에서 Ollama 오프라인 설치 완전 가이드 (GGUF + Modelfile 설정) (0) | 2026.04.09 |
|---|---|
| [7탄] Gradle 기반 JBoss 자동 배포 스크립트 완성 (0) | 2026.04.02 |
| [6탄] WAR 배포 실패 2 - spring-web 누락 & tomcat-runtime (0) | 2026.04.01 |
| [5탄] WAR 배포 실패 1 - Logback 충돌 (0) | 2026.04.01 |
| [4탄] STS 설치 & JBoss 서버 연동 (0) | 2026.04.01 |