누가 내 일기를 읽는다면?!
완성된 일기웹을 친구에게 추천을 하려고 했습니다.
저는 친구에게 장난으로 말했습니다.
나: "네가 쓴 일기 내가 다 볼 수 있어!"
친구: "앗! 그럼 난 쓸 수가 없지!"
장난으로 말은 던져보았지만
생각해 보니, 일기는 자기만의 이야기를 작성하는 매우 개인적인 글쓰기의 일부인데
서버 담당자나 개발자가 나의 일기를 다 보고 있다는 사실을 다수의 사용자는 어떤 생각을 가질까요?
어떤 이들은 감정과 일상을 기록하는데 클라우드에 그 내용이 기록되는 것을
크게 문제라고 느끼지 못하는 사람도 있을 테지만
회의록 작성을 일기앱으로 사용한다는 애플일기앱 리뷰를 보고 나서 일기웹의 정보보안은 생각해 보면 굉장한 큰 이슈라고 생각되었습니다.
우리는 사적인 감정과 기록들을 이야기형태로 다른 이에게 알리기도 하지만
정말 나 자신만 알고 싶은 일기는 보여주고 싶지 않을 때가 더 많으니까요.
애플에서 제공하는 일기앱은 저에게 매우 유용한 앱이기도 하고 개인정보에 대해 특별히 노출된 내용들을 의식하며 적지는 않았어요. 은행계좌의 비밀번호들을 종종 클라우드 메모에 적어두기는 했었지만
가능하면 이 습관을 유지하는 것이 안전한가 싶었어요
저와 비슷한 궁금증을 갖고 있는 이용자들이 있는지 Reddit 해외 커뮤니티에 글을 찾아봤습니다.
일부 사용자들은 Apple의 개인정보 보호에 매주 철저하다고 했지만, 어떤 사용이든 가장 안전한 것은 로컬로 저장하는 것이라고 답변이 있고, 보안이 철저한 애플의 경우 모든 데이터가 암호화처리가 되어있다는 내용도 있었습니다.
보안은 최소한으로 할 것인가?
가장 안전하게 할 것인가?
이 두 가지 질문을 한다해도 적용할 수 있는 기술은 생각보다 어나더 레벨이었습니다.
(혼자 쓰는 앱으로 방치하자.. ^^;;)
우선 제가 만든 일기웹의 어드민 페이지는 별도로 없었지만 운영접근 관련 보안과 사용자
데이터 자체의 보안이 필요로 해 보였습니다
보안상 태도 어떤 기술과 정책을 사용하느냐에 따라 접근과 관리에 영향을 미친다는 것을 ChatGPT를 통해 알게 되었습니다.
[옵션 A- 보안 적정 상태 옵션 ]
사용자 단위 접근제어
Firestore라면 Rules로 “본인 것만 읽기/쓰기”를 강제.
관리자 콘솔 차단 및 최소화 프로덕션 프로젝트의 콘솔/쿼리 권한을 극소수 “읽기 전용”으로 분리. 운영자 계정 MFA 필수, 세션 타임아웃 짧게. App Check/Origin 제한으로 비인가 클라이언트 접근 방지.
접근 로그 전면 기록 & 알림
누가 / 언제 / 무엇을 조회했는지 불변 로그(append-only)로 남기고,
관리자 계정이 일기 컬렉션을 조회하면 Slack/Email로 즉시 알림.
백업 암호화
자동 백업은 KMS 키로 암호화. 키 접근권한은 백업 담당자에게만.
[ 옵션 B - 보안 철저상태]
Best (강력, 대신 기능 제약 존재)
8) 클라이언트 단 종단 간 암호화(E2EE)
브라우저에서 생성한 키로 내용 자체를 암호화해 저장 → 서버는 “암호문”만 보관.
장점: 운영자 포함 누구도 평문 열람 불가.
단점: 서버 검색/추천/콘텐츠 모 더레이션 어려움, 키 분실 시 복구 불가.
절충안: 제목/메타데이터만 서버 검색용으로 별도 저장(민감도 낮은 범위).
저는 옵션 B를 선택하여 개발을 시작해 보았습니다.
일기웹의 Firestore에 **E2EE(클라이언트 암호화)**가 돌아가도록 데이터 구조(필드 구성)를 바꾸는 작업을 합니다.
이유는 실제 일기 본문은 암호문으로, 복호화에 필요한 최소 메타만 저장하는 기술이기 때문이죠.
이 작업을 하게 되면 운영자/서버가 평문을 볼 수 없게 됩니다.
즉, 제(개발자, 기획자)가 친구의 일기(사용자의 일기)를 볼 수 없다는 것이죠
그런데 직접 개발을 해보니 패스프레이즈 모달 방식은 사용자에게 비밀번호와 같은 입력을 요구하는 것인데 UX상으로 너무 불편해 보이고 낯설어 보였어요.
따라서 이 모달을 채택하지 않고, UX사용성을 고려하여 다른 구현방식을 물어봤습니다.
개발난이도와 기술구현방식 및 UX를 고려해서 알려주었습니다.
보기만 했을 때, 3번 옵션이 좋아 보였습니다.
생체인식이야말로 사용자들이 원하는 인증 방식이고, 서버에서도 해당 데이터를 볼 수 없는 방식이니까요!
그러나 구현 난도가 높았습니다.
이쯤 되니, 애플 일기앱을 직접 사용하는 것이 안전하다고 생각되었습니다.
선행학습으로 보안에 대한 구현방식과 UX를 공부하는 차원에서 좀 깊이가 생긴 시간이었습니다.
앞으로 이 아키텍처로 실제로 연습을 해볼 것인지에 대해 고민을 해봐야 될 것 같습니다.
AI가 많은 것을 알려주어도 보안개발의 장벽은 높은 듯하였습니다. 그만큼 보안은 매우 중요하다고 생각되었고요,
여러분이 사용하고 있는 앱에 정말로 소중한 정보가 개발과정에 충분히 적용되었는지 생각할 수 있는 계기가 되었길 바랍니다.
감사합니다.