시즌2 3편 — 배포 직전에 멈췄다, 주민번호가 '맨몸'으로 있었다

 

 

Dev Story · 시즌2 3편 — 개인정보 보안

배포 직전에 멈췄다 —
주민번호가 '맨몸'으로 있었다

개인정보를 시스템에 담을 때, 가장 먼저 막아야 했던 것

시스템을 다 만들고, 이제 실제 서버에 올리기(배포) 직전이었어요. 저는 올리기 전에 항상 한 번 점검을 돌리는데 — 그때 발을 멈추게 한 게 하나 걸렸습니다. 차주(車主)의 주민번호가, '맨몸'으로 누워 있었어요.

※ 이 글은 사건과 원리를 다루되, 실제 데이터·회사·내부 명칭 같은 식별 정보는 모두 가립니다. "법을 어겼다" 같은 단정 대신, 배포 전에 리스크를 발견해 막은 이야기로 읽어주세요.

1 배포 직전, 발을 멈추게 한 것

중고차를 수출하려면 차주의 주민번호가 들어가는 서류(말소·등록·양도 관련)가 필요해요. 문제는 그 주민번호가 시스템에 담긴 방식이었습니다.

• '맨몸'으로 저장돼 있었어요 — 누구나 보면 바로 읽히는 평범한 글자 그대로요(이걸 '평문'이라고 해요). 잠겨 있지 않았죠.
• 그 서류를 받는 화면에 잠금이 없었어요 — 정해진 주소(URL)만 알면, 결재 없이도 주민번호가 박힌 서류를 받을 수 있는 상태였습니다.

저는 배포 전에 AI 팀에게 여러 역할로 나눠 점검을 시키는데(이 방법은 다음 편들에서 자세히), 그 점검에서 이게 걸렸어요. 다행히 — 아직 실제 서버에 올리기 전이었습니다.

---

2 왜 큰일인가 — 주민번호는 '못 바꾸는' 정보다

비밀번호는 새어 나가도 바꾸면 돼요. 그런데 주민번호는 평생 못 바꿉니다. 한 번 새면, 되돌릴 방법이 없어요.

비밀번호 유출은 '복구'할 수 있지만, 주민번호 유출은 '복구'가 안 된다.

그래서 이런 정보(주민번호·계좌처럼 평생 따라다니는 식별 정보)는 그냥 두면 안 되고, 잠가서(암호화) 안전하게 보관하도록 정해져 있어요. "맨몸 저장 + 아무나 접근"은, 사고가 나면 돌이킬 수 없는 조합이었던 거예요. 그래서 배포 전에 반드시 바로잡아야 했습니다.

---

3 세 겹으로 막았다

한 군데만 막아선 부족했어요. 세 겹으로 둘렀습니다.

• ① 암호화 — 금고에 넣기. 저장 자체를 잠가서, 설령 데이터베이스가 통째로 새어 나가도 그 안의 주민번호는 못 읽게 했어요.
• ② 권한 + 감사 로그 — 누가 받아갔는지 기록. 서류를 받을 때마다 "누가, 언제, 무엇을" 전부 기록으로 남겼어요. (여기서 사람의 결정이 하나 있었는데, 뒤에서 다룰게요.)
• ③ 채널 격리 — 쓸 곳에서만. 수출용 영문 서류는 수출 건에서만 나오도록 막아, 엉뚱한 데서 새지 않게 했어요.

---

4 암호화의 함정 — 열쇠를 잃으면, 금고를 영영 못 연다

그런데 암호화엔 무서운 함정이 있어요. 암호화는 금고예요. 그리고 그 금고를 여는 열쇠가 딱 하나 있습니다(시스템의 마스터 키).

배포하다가 그 열쇠를 실수로 새로 만들거나 잃어버리면 — 금고 안의 주민번호 전부를 영원히 못 꺼냅니다. 보호하려던 암호화가, 데이터를 통째로 날려버리는 거예요.

그래서 안전장치를 따로 뒀어요.

• 열쇠를 별도의 안전한 곳에 백업 — 배포·이전 과정에서 절대 안 바뀌게.
• 잠그기 전 원본을 통째로 백업해 격리 — 최악의 경우를 위한 마지막 보루.

"암호화했으니 안전하다"가 끝이 아니라, "그 열쇠를 잃지 않을 장치까지" 있어야 진짜 안전이었어요.

---

반응형

5 이번 편의 산출물 — 개인정보를 다룰 때 체크리스트

민감한 개인정보를 시스템에 담을 때, 배포 전에 제가 짚는 기준이에요.

☑ 개인정보 다룰 때 — 배포 전 체크리스트

☐ 이 정보, 새면 '되돌릴 수 있나'? (주민번호·계좌 = 복구 불가 → 최우선 보호)

☐ 저장이 '맨몸'인가, 잠겨 있나(암호화)?

☐ 누가 받아갈 수 있나 — 화면뿐 아니라 주소(URL) 직접 입력도 막혀 있나?

☐ 누가 받아갔는지 기록(감사 로그)이 남나?

☐ 암호화의 '열쇠'를 따로 백업했나? (열쇠 잃으면 데이터도 끝)

☐ 이 모든 걸 배포 '전에' 점검했나?

---

6 AI가 갈린 지점 / 사람이 결정한 지점

이번 편엔 진짜 충돌이 있었어요. 그리고 그게 사고를 막았습니다.

🤝 보안 vs 현장 — 그리고 사람의 새 길

AI가 막았다(NO-GO): 점검에서 보안 역할이 "이대로는 절대 안 된다"고 강하게 막았어요. 무비판 통과가 아니라 거부해 준 덕분에, 배포 전에 잡혔죠.

그런데 역할끼리 갈렸다: 보안은 "관리자만 받게 잠가라", 현장 관점은 "영업·통관도 본인 차량 서류는 매일 쓰는 일이라 받아야 한다". 둘 다 맞는 말이라 부딪혔어요.

사람이 낸 '제3의 답': 관리자만으로 잠그지 않고 — 담당자는 다 받되, '누가 받았는지'를 전부 기록(감사 로그)하기로 했어요. 현장은 안 멈추고, 안전은 기록으로 지키는 길. 저장은 암호화로 잠그고요. AI가 준 A/B 말고 D를 새로 만든 셈이에요.

왜 사람의 몫이었나: "영업이 그 서류를 매일 쓴다"는 건 코드가 아니라 업무를 아는 사람이 아는 것. 보안만 보면 잠그는 게 맞지만, 일이 멈추면 안 되니까 — 그 균형은 사람이 책임지고 정했어요.

덤 — AI도 '틀린 가정'을 한다. 이 점검에서 AI들이 "다른 시스템이 이 데이터를 쓰는지 먼저 확인하라"며 신중하게 막았어요. 그런데 확인해보니 그 '다른 시스템'은 아예 존재하지 않았습니다 — 내부 문서에 잘못 적혀 있던 걸 AI가 곧이곧대로 믿은 거였죠. AI의 신중함도 자산이지만, 그 전제가 맞는지는 사람이 검증해야 한다는 걸 배운 순간이었어요.

---

핵심 한 줄 요약 — 개인정보 보안 편

발견배포 직전, 주민번호가 '맨몸(평문)' + 서류 잠금 없음

왜 큰일주민번호는 평생 못 바꿈 = 유출되면 복구 불가

세 겹 방어암호화(금고) + 권한·감사로그 + 채널 격리

암호화 함정열쇠(마스터 키) 잃으면 전부 영구 복호 불가 → 키·원본 백업

AI 갈림보안(관리자만) vs 현장(담당자도 필요)

사람 결정'제3의 답' — 다 받되 전부 기록(감사로그) + 암호화

교훈AI의 NO-GO도, AI의 틀린 가정도 — 둘 다 사람이 검증

다음 편권한 — 승인하는 사람과 실행하는 사람을 가르다(Finance-Gate)

Tags

#개인정보보호 #주민번호 #암호화 #보안 #감사로그 #접근권한 #APP_KEY #비개발자 #AI협업 #ERP #웹개발 #티스토리

▼ 티스토리 태그 입력란 복사용

개인정보보호, 주민번호, 암호화, 보안, 감사로그, 접근권한, APP_KEY, 비개발자, AI협업, ERP, 웹개발, 티스토리