OCR로 개인정보를 찾기 시작했다, 하드코딩을 걷어낸 날 | RE:개발자 #6

하드코딩을 걷어내고, 진짜 분석을 시작했다

지난 편까지 Security Lens의 API는 잘 동작했다.

문제는 한 가지였다.

분석을 전혀 하지 않는 분석 API였다.

riskScore = 82
riskLevel = CRITICAL

사진에 무엇이 들어 있든 결과는 똑같았다.

오늘은 이 하드코딩을 하나씩 걷어내기 시작했다.

---

첫 번째 목표는 OCR

사진 안에서 개인정보를 찾으려면
일단 사진에 무슨 글자가 적혀 있는지 알아야 한다.

그래서 분석 흐름에 OCR을 추가했다.

전체 구조는 이렇게 가져가기로 했다.

이미지 업로드
      ↓
이미지 정보 분석
      ↓
메타데이터 분석
      ↓
OCR
      ↓
개인정보 탐지
      ↓
위험 점수 계산
      ↓
위험 등급 결정
      ↓
결과 반환

조금씩 진짜 서비스 같은 구조가 만들어지기 시작했다.

---

analyzer 패키지를 만들었다

그리고 오늘 새롭게 만든 것 중 하나가

analyzer

패키지다.

Service 안에 전화번호 정규식, 이메일 정규식, 주소 탐지 로직을 전부 넣어버릴 수도 있었다.

하지만 그렇게 시작하면 금방 코드가 커질 것 같았다.

그래서 역할을 분리했다.

service
 ├─ ImageAnalysisService
 ├─ ImageMetadataService
 └─ OcrService

analyzer
 └─ PiiAnalyzer

여기서 PII는

Personally Identifiable Information

즉, 개인을 식별할 수 있는 정보를 의미한다.

Security Lens에서 굉장히 중요한 개념이다.

---

OCR 결과에서 개인정보를 찾아보자

OCR이 이미지의 텍스트를 읽었다고 끝나는 것은 아니다.

예를 들어 OCR 결과가

홍길동
서울시 서초구 어딘가
010-1234-5678
hello@example.com

이렇게 나왔다고 하자.

이제 여기에서 개인정보를 찾아야 한다.

첫 번째 버전에서는 너무 복잡하게 가지 않고
정규식을 사용하기로 했다.

전화번호 → Pattern
이메일   → Pattern
주소     → Pattern

그래서 PiiAnalyzer가 OCR 결과를 받아
개인정보 후보를 찾아낸다.

---

처음부터 AI를 사용하지 않은 이유

사실 이런 프로젝트를 만들면 바로 이런 생각이 든다.

"그냥 LLM한테 보내면 되는 거 아닌가?"

물론 가능하다.

그리고 나중에는 AI 분석도 붙일 예정이다.

하지만 처음부터 모든 걸 AI에게 맡기고 싶지는 않았다.

전화번호처럼 규칙이 명확한 개인정보는
굳이 LLM에게 물어볼 필요가 없다.

예를 들어

010-1234-5678

같은 데이터는 정규식으로도 충분히 찾을 수 있다.

그래서 현재 방향은

규칙으로 찾을 수 있는 것
        ↓
정규식 / 로직

규칙으로 판단하기 어려운 것
        ↓
AI

이런 구조다.

개인적으로 이쪽이 더 재미있다.

단순히 AI API를 호출하는 서비스를 만드는 게 아니라

기존 프로그램 로직과 AI를 어디에서 나눌 것인지

고민할 수 있기 때문이다.

---

이제 점수도 계산한다

기존에는

82

라고 적혀 있던 위험 점수도
실제 분석 결과를 기반으로 계산하도록 구조를 바꿨다.

현재 ImageAnalysisService의 흐름은 대략 이런 식이다.

ImageAnalysisService

1. 이미지 정보 추출
2. Metadata 추출
3. OCR 실행
4. PII 분석
5. Risk Score 계산
6. Risk Level 결정
7. AnalysisResponse 생성

그리고 각 기능을 하나의 클래스에 몰아넣지 않았다.

OcrService
PiiAnalyzer
RiskScoreCalculator
ImageMetadataService

각자 하나의 역할을 담당하게 했다.

예전에는 이런 구조를 보면

"클래스가 왜 이렇게 많지?"

라고 생각했는데,

지금 다시 만들어보니 오히려 반대다.

역할이 나뉘어 있으니까
어디를 수정해야 하는지가 훨씬 명확하다.

---

아직 완성된 것은 아니다

현재 PII 탐지는 MVP 단계다.

전화번호, 이메일, 주소처럼
형식이 비교적 명확한 정보부터 찾고 있다.

그리고 OCR 자체도 항상 정확하지 않다.

예를 들어

010-1234-5678

을

O1O-1234-567B

처럼 읽어버릴 수도 있다.

그러면 정규식은 전화번호라고 판단하지 못한다.

앞으로 해결해야 할 문제가 꽤 많다.

하지만 그게 오히려 좋다.

이제부터는 단순히 CRUD 화면을 하나 만드는 것이 아니라

OCR 정확도
→ 개인정보 탐지
→ AI 분석
→ 위험도 산정
→ 결과 설명

같은 문제를 하나씩 해결해야 한다.

---

다시 개발자가 되어가는 느낌

오늘 개발하면서 재미있었던 부분은
단순히 코드가 돌아간다는 게 아니었다.

처음에는

riskScore = 82;

였던 코드가

이미지
 ↓
OCR
 ↓
분석
 ↓
점수 계산

이라는 구조로 변해가는 과정이었다.

작은 변화지만,

하드코딩된 숫자 하나가 실제 로직의 결과로 바뀌는 순간

프로그램이 조금 살아나는 느낌이 든다.

예전에 회사에서 개발할 때는
주어진 요구사항을 구현하는 데 집중했다.

지금은 내가 직접

어떤 구조로 만들어야 할까?
어디까지 Java가 해야 할까?
어디서 AI를 써야 할까?
개인정보를 어떤 기준으로 위험하다고 판단해야 할까?

를 결정해야 한다.

그래서 어렵지만 훨씬 재미있다.

오늘 Security Lens는
단순한 Mock API에서 한 단계 벗어났다.

아직 작은 분석기지만,

이제 정말 이미지를 보기 시작했다.