포트폴리오
02 · 포트폴리오
02 · 포트폴리오

포트폴리오 — 배준건

공개 범위 안내

본 문서에 수록된 프로젝트는 모두 재직 중인 회사의 상용 제품입니다. 소스코드, 내부 모듈명·함수 시그니처, 고객사 식별 정보, 실제 운영 파라미터는 일절 포함하지 않았습니다. 다이어그램은 공개 가능한 기술 구성요소와 구조 수준으로만 재구성했으며, 각 항목은 "어떤 문제를 어떤 근거로 어떻게 풀었는가"를 설명하는 데 목적이 있습니다.

수록 항목

#항목형태관련 기간
1PrivacyKMS 제품 아키텍처시스템 구성도2021.12 – 현재
2키 저장 구조 전환 (파일 → DB)Before/After 비교2023.09 – 2023.12
3고가용성(HA) 이중화 아키텍처인프라 구성도 · 장애 시퀀스2024.11 – 2025.11
4PKCS#11 표준 라이브러리 구조계층 구조도 · 세션 시퀀스2024.07 – 2026.06
5공공 KMS 다중 사이트 연동 설계연동 아키텍처 · 키 갱신 흐름2026.04 – 현재
6생성형 AI 보안 제품 파이프라인학습/추론 파이프라인2025.10 – 2026.06
7설계 문서 산출물문서 목록2022 – 현재

1. PrivacyKMS 제품 아키텍처

암호키관리 제품의 전체 구성입니다. 웹 관리 콘솔과 서버 코어를 동일 담당자가 설계했기 때문에, 양쪽 통신 프로토콜을 한 관점에서 정의할 수 있었습니다.

다이어그램 (mermaid)
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)

운영 중인 제품의 기반 저장 구조를 바꾼 작업입니다. 동작을 멈추지 않고 전환하는 것이 전제 조건이었습니다.

다이어그램 (mermaid)
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 추가

이 전환이 만든 것

두 가지를 동시에 풀어야 했습니다. 구형 외부 라이브러리에 전 모듈이 묶여 있어 표준 대응 자체가 불가능했고, 파일 저장 구조라 백업·이중화·감사에 구조적 한계가 있었습니다. 라이브러리만 바꾸면 저장 구조 한계가 남고, 저장 구조만 바꾸면 라이브러리 종속이 남기 때문에 한 사이클에 함께 처리했습니다.

이후 실제로 이 전환 위에서 확장이 이뤄졌습니다.

다이어그램 (mermaid)
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 구조로 전환했습니다. 인프라 구성만으로는 부족했고, 제품 코어 측 로직까지 함께 손봐야 했던 것이 이 작업의 핵심입니다.

다이어그램 (mermaid)
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

장애 발생 시 처리 흐름

다이어그램 (mermaid)
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 연동 형태로 고객사에 기술이전됐습니다.

다이어그램 (mermaid)
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

세션 수명주기

다이어그램 (mermaid)
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여 개 규모의 공공 플랫폼에 키관리를 도입하는 사업의 설계입니다. 사이트마다 개별 대응하면 사업이 성립하지 않는 조건이었습니다.

다이어그램 (mermaid)
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

자동 키 갱신 · 키 버전 관리 흐름

키를 갱신하면 기존 키로 암호화된 데이터를 복호화할 수 없게 됩니다. 버전 관리가 전제되지 않은 키 갱신은 곧 데이터 유실이므로, 두 기능을 함께 설계했습니다.

다이어그램 (mermaid)
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 개발 경험이 없는 상태에서 리서치·학습·파이프라인 구성을 직접 담당했습니다.

다이어그램 (mermaid)
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
보안요구사항 문서 · 테스트 시나리오 · 데모 장비 명세공기업 PoC2026

국가 인증 제출문서

문서인증대상
보안목표명세서 (국문 · 영문)CCPrivacyDB V2.1 / V3.0
기능명세서CCPrivacyDB V2.1 / V3.0
사용자 운영설명서CCPrivacyDB V2.1 / V3.0
준비절차서CCPrivacyDB V2.1 / V3.0
형상관리서CCPrivacyDB V2.1 / V3.0
시험서CCPrivacyDB V2.1 / V3.0
SFR 항목별 매핑 문서 (FAU/FCS/FDP/FIA/FMT/FPT/FTA)CCPrivacyDB V2.1
형상관리지침서 · 시험서KCMVP암호모듈
기본설계서 · 상세설계서KCMVP암호모듈
관리자 · 비관리자 안내서KCMVP암호모듈
API · callexe 테스트 시나리오GSPrivacyDB V3.0
결함리포트GSPrivacyDB V2.1 / V3.0

직접 개발한 검증 도구

도구목적시기
Plug-in 성능 테스트 프로그램GS 인증 성능 시험 요건 충족2025
다중스레드 · BMT 테스트 코드GS 인증 벤치마크 시험2023
HSM 연동 테스트 프로그램단위 · 연동 테스트 검증2026
네트워크 패킷 분석 (TLS · 재사용 방지 인증메커니즘)CC 인증 증적 확보2025

정리

이 포트폴리오의 항목들은 신규 개발보다 이미 돌아가고 있는 시스템의 구조를 바꾸거나, 표준·인증 요건을 제품에 반영하는 작업에 몰려 있습니다. 5년간 반복적으로 맡아온 문제 유형은 세 가지입니다.

  1. 기반 구조를 무중단으로 교체하기 — 암호 라이브러리 전면 교체, 파일→DB 전환, 단일 서버→이중화 전환
  2. 외부 규격을 제품 안으로 들여오기 — PKCS#11·KMIP 표준 구현, Oracle TDE 연동, 타사 HSM 연동, CC·GS·KCMVP 인증 요건
  3. 설계한 사람이 끝까지 가져가기 — 설계 → 구현 → 고객 구축 → 기술이전/인증 대응까지 동일 담당자가 수행

각 항목의 상세 수행 내역과 정량 지표는 경력기술서를 참고 부탁드립니다.

// 이 페이지는 03_portfolio.md로부터 자동 생성됩니다. 내용을 고치려면 03_portfolio.md를 수정한 뒤 node scripts/build.mjs 를 실행하세요.