← ~/notes · 5 min read

MECA 논문지 확장 — 원본 테스트베드가 사라져서 AWS에 처음부터 다시 지은 이야기

학회 우수작을 논문지 6~7p로 확장하는 과제. 근거 재현하려니 실험 환경이 이미 삭제돼 있었다. AWS에 다시 짓고 $0.3에 정리했다.

securityresearchebpfcloudpublished
목차
  1. 문제 — 원본 테스트베드가 이미 삭제돼 있었다
  2. 재구현 — eBPF/BCC로 처음부터
  3. AWS에서 실측 — 인스턴스 두 개, 비용 $0.3
  4. 세 개의 실험 — exp1, exp2, exp3
  5. exp1: 애플리케이션 로그 vs MECA (위조 저항성)
  6. exp2: 처리량과 지연시간 오버헤드
  7. exp3: 마스킹 재현율
  8. 참고문헌 20편 전수 검증
  9. 위협 모델·Algorithm 1 추가
  10. Cohen’s d와 95% CI
  11. 다섯 개 docx로 분할 집필
  12. 재게재된 뒤 배운 것들
  13. 반복해서 맞은 지적
  14. 서지정보

MECA 초기 논문이 한국융합보안학회 2026 하계학술대회 Best Paper를 받은 뒤, 지도교수님이 논문지 확장을 지시했습니다. 3페이지짜리 학회 원고를 6~7페이지 학술지 원고로 늘려서 7/31까지 초고 송부.

  • 원본 학회 발표 → Best Paper 수상기 참고
  • 학술지 게재 확정 — 융합보안논문지 (KCI), 2026년 9월
  • 재제목: “MECA: 의료 클라우드 접속기록 가시성을 위한 eBPF 기반 규제 감사 아키텍처”
  • 저자: 임현빈, 김아람, 전상훈

교수님 방침이 명확했습니다: “핵심은 간결하게, 부연설명 + 참고문헌 추가로 3p → 6~7p”. 새 실험은 필요 없고 기존 결과를 더 자세히 설명하면 된다.

시작해보니 그게 안 됐습니다.

문제 — 원본 테스트베드가 이미 삭제돼 있었다

학회 발표를 위해 만들었던 EC2 인스턴스, VPC, OpenEMR 컨테이너, Synthea 데이터 — 발표 끝나고 비용 아끼려고 다 지웠습니다. 정말 다 지웠습니다.

논문지 확장에는 부연설명이 필요한데, 부연설명의 근거가 되는 실험 원시 데이터(로그, 시간 측정치, 마스킹 재현율 계산)를 다시 얻어야 했습니다. 원본 테스트베드가 없으니 방법은 하나:

MECA를 처음부터 다시 구현해서 다시 측정한다.

이걸 “라이브 재구축 실험”이라 부르기로 했습니다.

재구현 — eBPF/BCC로 처음부터

MECA 핵심 구성 요소:

1. eBPF SSL uprobe
   - OpenSSL의 SSL_read / SSL_write에 uprobe 부착
   - TLS 복호화 직후 평문 페이로드 캡처

2. eBPF kprobe
   - tcp_recvmsg에 kprobe 부착
   - 5-tuple(src/dst IP, port, timestamp) 수집

3. eBPF Maps
   - PID 조인으로 L4 5-tuple + L7 페이로드 상관
   - 결과 → 사용자 공간 수집기로 전송

4. In-kernel PII masking
   - 주민번호/비밀번호/전화번호 정적 unrolling으로 마스킹
   - eBPF verifier가 무한 루프 금지 → 정적 크기 256B 창

BCC(BPF Compiler Collection)로 파이썬 프론트엔드 + C 코드 조합. 초기 학회 원고에 있었던 알고리즘 표기를 실제 코드로 옮겼습니다.

AWS에서 실측 — 인스턴스 두 개, 비용 $0.3

Host EC2:  m5.xlarge (Ubuntu 22.04, Linux 6.8)
  ├── OpenEMR 7.0.3 (호스트 네트워크)
  ├── MECA 에이전트 (eBPF SSL uprobe + XDP + 마스킹)
  └── 수집기 (사용자 공간 Python)

Load EC2: c5.xlarge (Ubuntu 22.04)
  └── Synthea 합성 환자 데이터 → HTTPS 요청

Synthea로 만든 합성 환자 1,000명을 대상으로 총 1,000건 트랜잭션. 전체 실험이 몇 시간 안에 끝나서 작업 후 즉시 인스턴스 삭제 → 총 비용 $0.30. 이건 다음번에 또 하고 싶어도 실측 근거를 즉시 확보할 수 있다는 뜻입니다.

세 개의 실험 — exp1, exp2, exp3

exp1: 애플리케이션 로그 vs MECA (위조 저항성)

질문: 애플리케이션 로그가 위조/삭제되어도 MECA가 살아남나?

시나리오:

  • S1: 정상 접근 → 둘 다 같은 이벤트 기록 (기준선)
  • S2: 공격자가 애플리케이션 로그 파일 삭제 → MECA만 생존
  • S3: 공격자가 애플리케이션 로그 위조 (가짜 계정 ID 삽입) → MECA만 진짜 기록 보유
  • S4: 공격자가 root 권한 획득 후 MECA 커널 후크 자체 제거 → 둘 다 무력화 (정직한 한계)

S4는 논문에 명시적 한계로 넣었습니다. root 잡히면 뭘 해도 소용 없다. 이건 감춘다고 감춰지지 않는 사실이니까.

exp2: 처리량과 지연시간 오버헤드

질문: MECA를 켜면 애플리케이션 성능이 얼마나 떨어지나?

측정:

OFF: 23,000 rps 처리량
ON:  12,000 rps 처리량 (≈ -50%)

절반. 정직한 숫자입니다. 학회 원고에는 “약 2% 오버헤드”라고 있었는데, 재실측 결과 그건 저부하 평균 아티팩트였다는 것도 확인. 논문지 원고에는 제대로 된 수치와 “왜 낮은 부하에서만 2%로 보였는지”까지 추가.

이벤트 유실도 실측:

저부하 (1k rps 이하): 유실 0%
고부하 (10k+ rps):    유실 2% (평균)

exp3: 마스킹 재현율

질문: In-kernel PII 마스킹이 실제로 얼마나 잡나?

세 번의 반복 실험:

1차: 100.0% (전수 마스킹)
2차:  31.2%  ← 왜 이렇게 낮지?
3차:  81.2%  ← 왜 이렇게 튀지?

3차에서 256B 창 크기 한계가 원인임을 발견. RRN(주민번호) 패턴이 256B 창 경계에 걸치면 놓칩니다. 학회 원고에는 이 한계가 없었습니다.

논문지에는 이 한계를 명시하고, 향후 과제로 “동적 창 크기 조정” 제안. 정직하게 놓치는 부분을 적는 게 논문의 신뢰도입니다.

참고문헌 20편 전수 검증

교수님 방침 “부연설명 + 참고문헌으로 3p → 6~7p”의 참고문헌 부분. 학회 원고에는 5편이었던 걸 20편으로 확장.

각 참고문헌에 대해 원문 웹 검증:

  • 실제 존재하나
  • 저자·연도·페이지 정확한가
  • 논문 본문과 맥락상 맞나
  • URL이 살아있나

참고문헌_검증근거.md라는 별도 문서에 각 20편의 검증 근거를 표로 정리. 이 검증만 이틀 걸렸습니다.

관련 연구 비교 매트릭스:

             MECA  A  B  C  D  E
계정ID        ✓    -  -  -  ✓  -
정보주체      ✓    -  -  -  -  -
수행업무      ✓    -  -  ✓  -  -
접속 일시     ✓    ✓  ✓  ✓  ✓  ✓
접속지 IP     ✓    ✓  ✓  ✓  ✓  ✓
위조 저항성   ✓    -  -  -  -  -

MECA만 모든 항목 ✓. 이게 5→20 확장의 근거이기도 했습니다. 각 선행 연구가 어떤 항목을 놓쳤는지 표로 명확히 보이면, “MECA가 왜 필요한가”가 자연스럽게 나옵니다.

위협 모델·Algorithm 1 추가

학회 원고에는 없었던 위협 모델을 추가.

공격자 능력 × 공격 범위 매트릭스
              애플리케이션  네트워크  커널
비인가 접근      T1          T2       T3
로그 위조        T4          -        -
로그 삭제        T5          -        -
서비스 마비      T6          T7       T8

각 위협에 대해 MECA가 어떻게 대응하는지 명시. T5(애플리케이션 로그 삭제)에 MECA가 저항, T3(커널 침해)는 방어 불가 — 이런 식으로 커버리지·한계를 표로 정리.

Algorithm 1 (MECA 상관 알고리즘)도 pseudocode로 추가.

Cohen’s d와 95% CI

exp2 처리량 저하가 유의미한지 통계적으로 확인.

  • Cohen’s d ≈ 1.1 (large effect)
  • 95% CI 재산출 (학회 원고 신뢰구간이 부정확했음)

학회 원고에는 t-test p-value만 있었는데, 논문지 심사자가 “effect size는?”이라 물을 게 뻔했습니다. 미리 넣어둠.

다섯 개 docx로 분할 집필

교수님이 원고를 한 번에 다 쓰지 말라고 하셨습니다. 섹션별로 별도 docx로 분할해서 순차 리뷰.

  • 1_서론.docx — 재프레임 + MECA 약자 풀이(Medical eBPF Compliance Architecture)
  • 2_관련연구.docx — 20편 참고문헌 + 비교 매트릭스
  • 3_위협모델.docx — 신뢰경계 그림 + 공격자×범위 표 + Algorithm 1
  • 4_결과보강.docx — Cohen’s d, 95% CI, 본문 문장 교체 지침
  • 5_논의.docx — 자기준수 표, 커버리지 표, Threats to Validity

각 절에 [삭제]/[교체] 박스를 넣어서 학회 원고의 어느 문장을 어느 논문지 문장으로 바꿀지 명확히 표시. 스플라이스(통합) 작업이 이걸 없으면 지옥이 됩니다.

재게재된 뒤 배운 것들

원본 인프라를 지우지 마세요. 학회 발표 끝나면 지우고 싶은 마음 이해합니다. AWS 비용 두려우니까. 그런데 논문지 확장 요청이 오면 재구축이 강제됩니다. 그럴 바엔 CloudFormation/Terraform으로 정의만 남겨두는 것이 답이었습니다. 다음엔 그렇게 합니다.

“실험은 안 늘리고 부연설명만”이라는 지시는 반쯤만 진실입니다. 실측 근거가 재현되지 않으면 부연설명 자체가 불가능. 학회 원고의 근사치·평균치를 논문지에서 부연설명 하려면 원본 수치 재산출이 필요한 경우가 대부분입니다.

참고문헌을 5 → 20으로 늘리는 건 저자 부담이 매우 큽니다. 각 논문을 실제로 읽고, 맥락에 맞게 인용하고, 원문 검증까지 해야 하니. 학회 원고 쓸 때 참고문헌을 미리 15편 이상 확보해두면 확장이 편합니다.

AWS 실험 $0.3의 정직함. 저비용이지만 재현 가능해야 실측이라 부를 수 있습니다. Terraform 없이 매번 콘솔로 재구축하면 다음번엔 안 하게 됩니다. 인프라를 코드로.

반복해서 맞은 지적

HADA와 같은 패턴이 나왔습니다:

  1. 제안 → 결과 매핑
  2. 비교군 없는 자체 수치 금지
  3. 기준 정량 근거
  4. 위협 모델 명확성
  5. 한계 정직 서술

이걸 정리해서 개인 논문 리뷰 체크리스트를 만들었습니다. 다음 논문 쓸 때 초안 완성 전 self-check로 사용. 이 체크리스트도 따로 정리해서 올릴 계획.

서지정보

  • 제목: MECA: 의료 클라우드 접속기록 가시성을 위한 eBPF 기반 규제 감사 아키텍처
  • 영문: MECA: An eBPF-Based Regulatory Audit Architecture for Medical Cloud Access-Log Visibility
  • 저자: 임현빈, 김아람, 전상훈
  • 저널: 융합보안논문지 (KCI)
  • 연도: 2026 (9월 게재 승인)

감사 인사: 김아람 선배님 공동 저자로 실험 설계 검토와 코드 리뷰 감사합니다. 전상훈 교수님 반복 지적 덕에 논문 형태가 갖춰졌습니다.