포트폴리오 — 배준건
공개 범위 안내
본 문서에 수록된 프로젝트는 모두 재직 중인 회사의 상용 제품입니다. 소스코드, 내부 모듈명·함수 시그니처, 고객사 식별 정보, 실제 운영 파라미터는 일절 포함하지 않았습니다. 다이어그램은 공개 가능한 기술 구성요소와 구조 수준으로만 재구성했으며, 각 항목은 "어떤 문제를 어떤 근거로 어떻게 풀었는가"를 설명하는 데 목적이 있습니다.
수록 항목
| # | 항목 | 형태 | 관련 기간 |
|---|---|---|---|
| 1 | PrivacyKMS 제품 아키텍처 | 시스템 구성도 | 2021.12 – 현재 |
| 2 | 키 저장 구조 전환 (파일 → DB) | Before/After 비교 | 2023.09 – 2023.12 |
| 3 | 고가용성(HA) 이중화 아키텍처 | 인프라 구성도 · 장애 시퀀스 | 2024.11 – 2025.11 |
| 4 | PKCS#11 표준 라이브러리 구조 | 계층 구조도 · 세션 시퀀스 | 2024.07 – 2026.06 |
| 5 | 공공 KMS 다중 사이트 연동 설계 | 연동 아키텍처 · 키 갱신 흐름 | 2026.04 – 현재 |
| 6 | 생성형 AI 보안 제품 파이프라인 | 학습/추론 파이프라인 | 2025.10 – 2026.06 |
| 7 | 설계 문서 산출물 | 문서 목록 | 2022 – 현재 |
1. PrivacyKMS 제품 아키텍처
암호키관리 제품의 전체 구성입니다. 웹 관리 콘솔과 서버 코어를 동일 담당자가 설계했기 때문에, 양쪽 통신 프로토콜을 한 관점에서 정의할 수 있었습니다.
flowchart TB
subgraph consumer["키 사용 주체"]
APP["고객 애플리케이션"]
DBE["DB 암호화 에이전트"]
TDE["Oracle TDE<br/>(PKCS#11 연동)"]
end
subgraph console["myKms · 웹 관리 콘솔"]
DASH["대시보드<br/>CPU/메모리 모니터링"]
MGMT["사용자 · 키 · 키서버 · 정책 관리"]
APPR["결재 워크플로우<br/>승인 / 반려"]
ACL["IP 기반 접근통제<br/>로그인 내역"]
end
subgraph core["OwlKMS · 서버 코어"]
PROTO["소켓 통신 프로토콜 계층"]
LIFE["키 라이프사이클 엔진<br/>생성·주입·추출·삭제<br/>상태변경·조회·백업·복구"]
CRYPTO["OWLCrypto<br/>자체 암호 라이브러리"]
MK["마스터키 · KEK 관리"]
WD["Watchdog<br/>프로세스 감시·재기동"]
end
subgraph store["저장 계층"]
PG[("PostgreSQL<br/>키 · 정책 · 이력")]
HSM["HSM<br/>하드웨어 보안 모듈"]
end
APP --> PROTO
DBE --> PROTO
TDE --> PROTO
console --> PROTO
PROTO --> LIFE
LIFE --> CRYPTO
LIFE --> MK
CRYPTO --> PG
MK --> HSM
WD -.감시.-> PROTO설계 시 판단한 것
결재 워크플로우를 왜 넣었는가
키 관리 제품에서 실제 위험은 외부 침입보다 내부 운영자의 무단 키 변경입니다. 키 등록·수정·삭제를 즉시 반영하지 않고 승인/반려 단계를 거치도록 설계해, 모든 변경에 요청자와 승인자가 함께 남도록 했습니다. 이 구조가 이후 CC 인증 대응 시 감사 요구사항을 충족하는 근거가 됐습니다.
웹과 코어를 분리한 이유
관리 UI와 키 연산을 같은 프로세스에 두면, 웹 취약점이 곧 키 노출로 이어집니다. 콘솔은 프로토콜 계층을 통해서만 코어에 접근하도록 하고, 실제 암호 연산은 코어 내부에서만 수행되도록 경계를 그었습니다.
자체 암호 라이브러리로 교체한 이유
→ 2번 항목 참조.
2. 키 저장 구조 전환 (파일 → DB)
운영 중인 제품의 기반 저장 구조를 바꾼 작업입니다. 동작을 멈추지 않고 전환하는 것이 전제 조건이었습니다.
flowchart LR
subgraph before["Before · 2023.09 이전"]
direction TB
B1["애플리케이션"] --> B2["KeySharpCrypto<br/>외부 구형 라이브러리"]
B2 --> B3["정책 파일"]
B2 --> B4["키 파일"]
B3 -.-> B5["백업: 수동 파일 복사<br/>이중화: 불가<br/>감사: 이력 없음"]
end
subgraph after["After · 2023.12"]
direction TB
A1["애플리케이션"] --> A2["OWLCrypto<br/>자체 암호 라이브러리"]
A2 --> A3["통신 프로토콜 계층"]
A3 --> A4["저장 프로시저"]
A4 --> A5[("PostgreSQL<br/>키 · 정책 · 상태 · 이력")]
A5 -.-> A6["백업/복구: 기능화<br/>이중화: 복제로 가능<br/>감사: 이력 조회 가능"]
end
before ==>|"전면 전환"| after전환 범위
| 구분 | 전환 내용 |
|---|---|
| 암호 라이브러리 | 초기화 로직, 자가시험(무결성 검증), 마스터키 생성·관리, 정책 생성 로직을 전 모듈 교체 |
| 저장 구조 | 파일 기반 정책·키 저장 → DB 스키마 + 저장 프로시저 |
| 키 라이프사이클 | 생성 / 주입 / 추출 / 삭제 / 상태변경 / 조회 / 백업 / 복구 — 전 기능 DB 기반 재구현 |
| 통신 | 서버–클라이언트 프로토콜 재정의 |
| 외부 인터페이스 | JNI 학습 후 Java 라이브러리용 키 API 추가 |
이 전환이 만든 것
두 가지를 동시에 풀어야 했습니다. 구형 외부 라이브러리에 전 모듈이 묶여 있어 표준 대응 자체가 불가능했고, 파일 저장 구조라 백업·이중화·감사에 구조적 한계가 있었습니다. 라이브러리만 바꾸면 저장 구조 한계가 남고, 저장 구조만 바꾸면 라이브러리 종속이 남기 때문에 한 사이클에 함께 처리했습니다.
이후 실제로 이 전환 위에서 확장이 이뤄졌습니다.
flowchart LR
T["2023<br/>라이브러리 교체<br/>+ DB 전환"] --> A["2024<br/>KEK·마스터키 백업<br/>PKCS#11 구현"]
T --> B["2025<br/>이중화(HA)<br/>RSA 비대칭키"]
T --> C["2026<br/>HSM 연동<br/>자동 키 갱신"]3. 고가용성(HA) 이중화 아키텍처
단일 서버 구성이던 제품을 Active-Standby 구조로 전환했습니다. 인프라 구성만으로는 부족했고, 제품 코어 측 로직까지 함께 손봐야 했던 것이 이 작업의 핵심입니다.
flowchart TB
CLIENT["연동 클라이언트"]
VIP["VIP<br/>keepalived"]
LB["HAProxy<br/>부하 분산 · 헬스체크"]
subgraph active["Active 노드"]
A_KMS["OwlKMS 코어"]
A_WD["Watchdog<br/>프로세스 감시"]
A_DB[("PostgreSQL<br/>Primary")]
end
subgraph standby["Standby 노드"]
S_KMS["OwlKMS 코어"]
S_WD["Watchdog"]
S_DB[("PostgreSQL<br/>Replica")]
end
PAT["Patroni<br/>자동 failover / failback"]
CLIENT --> VIP --> LB
LB --> A_KMS
LB -.대기.-> S_KMS
A_KMS --> A_DB
S_KMS --> S_DB
A_DB ==>|"스트리밍 복제"| S_DB
PAT -.제어.-> A_DB
PAT -.제어.-> S_DB
A_WD -.감시·재기동.-> A_KMS
S_WD -.감시·재기동.-> S_KMS장애 발생 시 처리 흐름
sequenceDiagram
participant C as 클라이언트
participant V as VIP / HAProxy
participant A as Active 노드
participant W as Watchdog
participant P as Patroni
participant S as Standby 노드
C->>V: 키 요청
V->>A: 라우팅
Note over A: 프로세스 비정상 종료
W->>W: 공유메모리 상태 체크 실패 감지
W->>A: 프로세스 자동 재기동 시도
alt 노드 자체 장애
V->>V: 헬스체크 실패 감지
P->>S: DB Primary 승격
V->>S: VIP 전환 · 트래픽 라우팅
S->>S: 제품 측 DB 재접속 로직 동작
C->>V: 키 요청 (서비스 연속)
V->>S: 라우팅
end
Note over A,S: 장애 노드 복구 시 Patroni 자동 failback직접 구현한 부분과 그 이유
| 구성요소 | 선택 | 판단 근거 |
|---|---|---|
| keepalived + VIP | 채택 | 클라이언트 측 설정 변경 없이 엔드포인트 유지 |
| HAProxy | 채택 | 헬스체크 기반 라우팅으로 장애 노드 자동 제외 |
| Patroni | 도입 | 수동 failback은 운영 부담이 크고 야간 장애 대응이 불가 |
| 제품 측 DB 재접속 · 상태 체크 | 직접 구현 | 인프라가 전환돼도 제품이 끊긴 커넥션을 잡고 있으면 서비스는 복구되지 않음 |
| Watchdog 자동 실행 | 직접 개발 | 노드 장애가 아닌 프로세스 단위 장애는 인프라 레이어가 감지하지 못함 |
| 부팅 스크립트 자동화 | 직접 구현 | 재부팅 후 수동 기동이 필요하면 복구 시간이 사람 대기 시간에 묶임 |
검증 결과
- 2025.11.29 고객사 원격 이중화 구축 완료 (2024.11 착수, 1년)
- 이중화 구성에서 3,500 TPS 검증 — 케이스별 TPS 성능 테스트 수행 및 오류 분석
- Patroni 자동 failback 테스트로 운영자 개입 없는 복귀 확인
- RDS 환경 키 백업·복구 기능 설계·구현 및 복구 오류 수정
4. PKCS#11 표준 라이브러리 구조
국제표준 명세를 읽고 소켓 통신 계층부터 C로 직접 구현한 라이브러리입니다. 2년 뒤 Oracle TDE 연동 형태로 고객사에 기술이전됐습니다.
flowchart TB
subgraph app["표준 소비자"]
ORA["Oracle TDE<br/>Wallet"]
ETC["PKCS#11 지원 애플리케이션"]
end
subgraph lib["PKCS#11 라이브러리 (C · 자체 구현)"]
API["표준 API 계층"]
subgraph fn["구현 함수군"]
F1["초기화 · 토큰<br/>GetInfo / GetSlotList"]
F2["세션 수명주기<br/>OpenSession / CloseSession"]
F3["키 연산<br/>GenerateKey"]
F4["암복호화<br/>Encrypt / Decrypt"]
end
VAL["유효성 검증 계층"]
SOCK["Client 소켓 통신"]
end
subgraph srv["KMS 서버"]
SSOCK["Server 소켓 통신"]
KEY["키 라이프사이클 엔진"]
DB[("키 저장소")]
end
ORA --> API
ETC --> API
API --> fn
fn --> VAL
VAL --> SOCK
SOCK <==>|"자체 정의 프로토콜"| SSOCK
SSOCK --> KEY --> DB세션 수명주기
sequenceDiagram
participant O as Oracle TDE
participant L as PKCS#11 라이브러리
participant S as KMS 서버
O->>L: C_Initialize
O->>L: C_GetInfo / C_GetSlotList
L-->>O: 토큰 · 슬롯 정보
O->>L: C_OpenSession
L->>S: 세션 수립 요청
S-->>L: 세션 컨텍스트
L-->>O: 세션 핸들
O->>L: C_GenerateKey
L->>L: 파라미터 유효성 검증
L->>S: 키 생성 요청
S->>S: 키 생성 · 저장
S-->>L: 키 핸들
O->>L: C_Encrypt / C_Decrypt
L->>S: 암복호화 연산 요청
S-->>L: 연산 결과
L-->>O: 결과 반환
O->>L: C_CloseSession
L->>S: 세션 해제접근 방식
① 명세 → 구조 파악 (2024.07 – 2024.09)
표준 문서만으로는 실제 구현 형태가 잡히지 않아, 관련 오픈소스를 분석·빌드해 동작을 확인한 뒤 객체 다이어그램과 프로세스 흐름도를 직접 작성했습니다. 이 문서를 기준으로 함수 단위 설계를 진행했습니다.
② 전체 구현이 아닌 선별 구현 (2026.01 – 2026.06)
PKCS#11 표준 함수를 전부 구현하는 것은 비용 대비 효율이 낮습니다. Oracle이 TDE 연동 시 실제로 호출하는 함수를 역으로 조사해 필요한 범위를 특정하고, 그 범위에 집중해 연동을 완성했습니다.
③ 구현자가 기술이전까지 담당
Oracle TDE 설치·마이그레이션 문서를 직접 작성해 공공 연구기관 고객사에 기술이전했습니다. 설계한 사람이 이전 자료를 작성했기 때문에 문서와 실제 동작 사이 간극이 없었고, 납품 이후에도 코드리뷰와 추가 기술이전을 이어갔습니다.
5. 공공 KMS 다중 사이트 연동 설계
연동 사이트 100여 개 규모의 공공 플랫폼에 키관리를 도입하는 사업의 설계입니다. 사이트마다 개별 대응하면 사업이 성립하지 않는 조건이었습니다.
flowchart TB
subgraph sites["연동 사이트 · 100여 개"]
S1["사이트 A<br/>에이전트"]
S2["사이트 B<br/>에이전트"]
S3["..."]
SN["사이트 N<br/>에이전트"]
end
subgraph api["표준 연동 계층 · REST API"]
AUTH["인증 · 인가"]
GRP["그룹별 키 조회"]
ROT["키 갱신 요청"]
LIFE["키 유효기간 정책"]
end
subgraph kms["KMS 중앙"]
PROC["키 관리 프로세스"]
VER["키 버전 관리"]
STORE[("키 저장소")]
KCMVP["KCMVP 검증 대상 범위"]
end
S1 --> AUTH
S2 --> AUTH
S3 --> AUTH
SN --> AUTH
AUTH --> GRP & ROT & LIFE
GRP --> PROC
ROT --> PROC
LIFE --> PROC
PROC --> VER --> STORE
KCMVP -.적용 범위.-> PROC자동 키 갱신 · 키 버전 관리 흐름
키를 갱신하면 기존 키로 암호화된 데이터를 복호화할 수 없게 됩니다. 버전 관리가 전제되지 않은 키 갱신은 곧 데이터 유실이므로, 두 기능을 함께 설계했습니다.
flowchart LR
A["키 생성<br/>v1"] --> B{"유효기간<br/>도래"}
B -->|"미도래"| A
B -->|"도래"| C["신규 버전 생성<br/>v2"]
C --> D["신규 암호화는<br/>v2 사용"]
C --> E["기존 데이터 복호화용<br/>v1 보존"]
E --> F{"v1 참조<br/>데이터 존재"}
F -->|"있음"| E
F -->|"없음"| G["v1 폐기"]
D --> B설계 판단
| 항목 | 판단 |
|---|---|
| 연동 방식 | 사이트별 개별 규격 대신 REST API 단일 규격으로 표준화 — 100여 개 사이트를 개별 대응하는 것은 불가능 |
| 인증 요건 | 사업 초기에 KCMVP 적용 범위 먼저 검토 — 설계 완료 후 검증 요건을 확인하면 아키텍처 재작업이 발생 |
| 문서화 | Java 구현가이드 등 연동 가이드를 사업 산출물로 포함 — 플랫폼사가 문의 없이 붙을 수 있어야 100여 사이트 연동이 성립 |
| 키 갱신 | 자동 갱신과 키 버전 관리를 동시에 설계 — 분리하면 갱신 시점에 기존 데이터 복호화가 불가 |
진행 상황: 제안 미팅 참여 → 아키텍처·API 설계 → 수주 → 2026.09.02 착수보고회 완료 → 연동 가이드 문서 작성 진행중
6. 생성형 AI 보안 제품 파이프라인 (PrivacyAIFilter)
LLM 입력 데이터에서 개인정보를 탐지·처리하는 제품입니다. AI 개발 경험이 없는 상태에서 리서치·학습·파이프라인 구성을 직접 담당했습니다.
flowchart TB
subgraph train["학습 파이프라인"]
D["학습 데이터"] --> V["DVC<br/>데이터 버전 관리"]
V --> FT["NER · BERT-CRF<br/>fine-tuning"]
FT --> TRK["MLflow<br/>실험 추적"]
TRK --> CONV["ONNX 변환<br/>경량화"]
ORCH["Apache Airflow<br/>파이프라인 오케스트레이션"] -.제어.-> V
ORCH -.제어.-> FT
end
subgraph serve["추론 파이프라인"]
REQ["LLM 입력 데이터"] --> API["FastAPI<br/>추론 서버"]
API --> MODEL["ONNX Runtime<br/>개인정보 개체 탐지"]
MODEL --> RULE["탐지 규칙 엔진"]
RULE --> OUT["처리 결과 반환"]
RULE --> LOG["로그 기록"]
end
subgraph pkg["패키징"]
DOCKER["Docker 컨테이너<br/>백엔드 + AI 모델"]
end
CONV ==>|"모델 배포"| MODEL
serve --> DOCKER기술 선택의 근거
왜 ONNX 변환인가
고객사는 온프레미스 환경에 제품을 설치합니다. 학습 프레임워크 전체를 고객 환경에 올릴 수는 없으므로, 모델을 ONNX로 변환해 추론에 필요한 최소 런타임만으로 동작하도록 구성했습니다.
왜 개발 초기에 MLOps부터 구축했는가
모델은 한 번 만들고 끝나지 않고 탐지 규칙과 데이터가 계속 바뀝니다. 학습–배포 경로가 수작업으로 남으면 출시 이후 개선 속도가 떨어지기 때문에, MLflow·Kubeflow·DVC·Airflow를 먼저 설치·검증해 파이프라인 기초를 마련한 뒤 모델 작업에 들어갔습니다.
왜 MVP를 먼저 확정했는가
3인 팀 중 2명이 기존 업무를 병행해 투입 리소스가 유동적이었습니다. 기능을 다 갖춘 뒤 내는 전략은 일정 리스크가 컸기 때문에, 출시 범위를 먼저 잘라내고 이후 단계적으로 추가하는 방향을 택했습니다. 결과적으로 2025.09 착수 → 2026.04 정식 출시로 8개월 만에 완주했고, 출시 후 탐지 규칙 UI 고도화와 로그 기능을 추가했습니다.
외부 확인: 데일리시큐, 「아울시스템즈, LLM 데이터 보안 솔루션 '프라이버시 AI 필터' 출시」 (2026.04.03)
https://www.dailysecu.com/news/articleView.html?idxno=206084
7. 설계 문서 산출물
코드와 별개로, 직접 작성한 설계·인증 문서입니다. 보안 제품 특성상 문서 자체가 검증 대상이자 납품 산출물입니다.
시스템 설계 문서
| 문서 | 대상 | 작성 시기 |
|---|---|---|
| 시스템 아키텍처 (구성도 · 모듈 · 기술스택) | PrivacyKMS 이중화 | 2025 |
| 요구사항 명세서 | PrivacyKMS 이중화 | 2025 |
| 주요 함수 명세서 | PrivacyKMS 이중화 | 2025 |
| 데이터 흐름 다이어그램 | PrivacyKMS 이중화 | 2025 |
| 기획서 · 상세설계서 (소스 영향도 분석 포함) | HSM 연동 | 2026 |
| 객체 다이어그램 · 프로세스 흐름도 | PKCS#11 라이브러리 | 2024 |
| 구성도 · 아키텍처 · 스토리보드 | 공공 KMS 도입 사업 | 2026 |
| Java 구현가이드 등 연동 가이드 | 공공 KMS 도입 사업 | 2026 (진행중) |
| Oracle TDE 설치 · 마이그레이션 문서 | PKCS#11 기술이전 | 2026 |
| 보안요구사항 문서 · 테스트 시나리오 · 데모 장비 명세 | 공기업 PoC | 2026 |
국가 인증 제출문서
| 문서 | 인증 | 대상 |
|---|---|---|
| 보안목표명세서 (국문 · 영문) | CC | PrivacyDB V2.1 / V3.0 |
| 기능명세서 | CC | PrivacyDB V2.1 / V3.0 |
| 사용자 운영설명서 | CC | PrivacyDB V2.1 / V3.0 |
| 준비절차서 | CC | PrivacyDB V2.1 / V3.0 |
| 형상관리서 | CC | PrivacyDB V2.1 / V3.0 |
| 시험서 | CC | PrivacyDB V2.1 / V3.0 |
| SFR 항목별 매핑 문서 (FAU/FCS/FDP/FIA/FMT/FPT/FTA) | CC | PrivacyDB V2.1 |
| 형상관리지침서 · 시험서 | KCMVP | 암호모듈 |
| 기본설계서 · 상세설계서 | KCMVP | 암호모듈 |
| 관리자 · 비관리자 안내서 | KCMVP | 암호모듈 |
| API · callexe 테스트 시나리오 | GS | PrivacyDB V3.0 |
| 결함리포트 | GS | PrivacyDB V2.1 / V3.0 |
직접 개발한 검증 도구
| 도구 | 목적 | 시기 |
|---|---|---|
| Plug-in 성능 테스트 프로그램 | GS 인증 성능 시험 요건 충족 | 2025 |
| 다중스레드 · BMT 테스트 코드 | GS 인증 벤치마크 시험 | 2023 |
| HSM 연동 테스트 프로그램 | 단위 · 연동 테스트 검증 | 2026 |
| 네트워크 패킷 분석 (TLS · 재사용 방지 인증메커니즘) | CC 인증 증적 확보 | 2025 |
정리
이 포트폴리오의 항목들은 신규 개발보다 이미 돌아가고 있는 시스템의 구조를 바꾸거나, 표준·인증 요건을 제품에 반영하는 작업에 몰려 있습니다. 5년간 반복적으로 맡아온 문제 유형은 세 가지입니다.
- 기반 구조를 무중단으로 교체하기 — 암호 라이브러리 전면 교체, 파일→DB 전환, 단일 서버→이중화 전환
- 외부 규격을 제품 안으로 들여오기 — PKCS#11·KMIP 표준 구현, Oracle TDE 연동, 타사 HSM 연동, CC·GS·KCMVP 인증 요건
- 설계한 사람이 끝까지 가져가기 — 설계 → 구현 → 고객 구축 → 기술이전/인증 대응까지 동일 담당자가 수행
각 항목의 상세 수행 내역과 정량 지표는 경력기술서를 참고 부탁드립니다.