Log
TimeTogether — 사용자 익명성을 보장하는 장소 추천 시스템 회고
2026.05.21
왜 이 글을 쓰는가
TimeTogether 는 그룹 약속 조율 서비스를 만들면서 "개인정보를 서버에 평문으로 두지 않고도 개인화 추천이 가능한가" 라는 문제를 풀어본 학부 연구 프로젝트다. 진행 결과를 정리해 「사용자 익명성을 보장하는 맞춤형 장소 추천 시스템」이라는 제목으로 한국정보처리학회(KIPS) 학술발표대회에 게재했다.
포트폴리오의 프로젝트 페이지는 내가 단독으로 구현한 프론트엔드의 기술 의사결정에 집중하느라 프로젝트 자체의 배경·팀 구성·추천 모델은 잘라냈다. 이 글에서 그 맥락을 함께 정리한다.
팀 구성과 내 역할
| 역할 | 인원 | 비고 |
|---|---|---|
| 지도교수 | 1 명 | 박소영 교수 |
| 보안 모델 설계 | 3 명 | 영지식 구조, 키 관리 |
| 추천 모델 | 2 명 | Funk SVD, 컨텍스트 가중합 |
| 프론트엔드 | 1 명 | 내가 단독 구현 |
| 백엔드 | 2 명 | 별도 팀원 |
나는 이 중 프론트엔드를 단독으로 담당했다. 보안 설계 회의에 함께 참여해 클라이언트가 책임져야 할 키 유도·암호화·익명 식별자 생성 절차를 같이 정리하고, 그 결과를 NextTimeTogether-Frontend 저장소에 구현했다.
추천 모델 쪽은 초기 학습 시도와 데이터 파이프라인 구성 단계에 합류해 입력 데이터 형식과 PSIDu(익명 식별자) 송신 방식을 맞췄다. 모델 자체의 심화 튜닝과 평가 실험은 추천 담당 팀원이 진행했으므로, 이 글에서 추천 모델 내부 동작은 팀이 작성한 논문 본문에 의존해 간략히 요약한다.
어떤 문제를 풀려 했는가
기존 그룹 약속·일정 조율 서비스(when2meet, 카카오 약속잡기 등) 는 사용자 ID, 이메일, 일정 시간, 장소 같은 정보를 모두 서버 평문 DB 에 저장한다. 이는 다음 두 가지 위험을 동반한다.
- DB 유출 위험. 서버 DB 가 한 번 유출되면 사용자 일정과 사교 관계가 그대로 노출된다.
- 서버 측 프로파일링 위험. 서비스 운영자조차도 누가 누구와 자주 만나는지, 어떤 장소를 자주 가는지 알 수 있다.
전통적인 익명성 보장 시스템은 이 문제를 풀기 위해 신뢰할 수 있는 제3의 기관(인증 기관, 익명 라우터 등) 을 끌어들인다. 우리 팀은 추가 신뢰 기관 없이도, 사용자 데이터 자체를 클라이언트에서 암호화해 서버를 "영지식(zero-knowledge) 상태" 로 유지하면서, 동시에 개인화 장소 추천을 제공할 수 있는지 검증하는 것을 연구 목표로 삼았다.
시스템 구성
전체 시스템은 다음 3 개 컴포넌트로 구성된다.
- 스케줄 컴포넌트 — 개인 일정 등록·조회
- 그룹/약속 관리 컴포넌트 — 그룹 생성·초대·시간 조율
- 추천 컴포넌트 — 약속 장소 후보를 사용자별로 추천
핵심은 클라이언트(브라우저)가 데이터를 서버에 올리기 전에 모두 암호화하고, 서버는 그 암호문만을 저장·조회하는 영지식 구조다. 추천 컴포넌트는 사용자 ID 대신 사용자 본인만 재현 가능한 익명 식별자(PSIDu) 를 키로 사용해 행동 이력을 누적한다.
핵심 아이디어: 영지식 구조와 익명 추천의 양립
1. 데이터 키 — 사용자 본인만 보유
사용자 비밀번호와 사용자 ID 를 결합해 PBKDF2 로 데이터 키를 유도한다. 이 키는 서버에 전송되지 않으며, 브라우저의 IndexedDB 에 추출 불가(extractable: false) CryptoKey 형태로 보관된다. 모든 개인정보(이메일, 전화번호 등) 와 일정 식별자는 이 키로 AES-GCM 암호화되어 서버에 올라간다.
2. 블라인드 인덱싱 — 서버는 일정 시간을 알 수 없음
일정 식별자(SID) 는 일정의 시작 시간을 데이터 키로 암호화해 만든다. 사용자가 특정 날짜의 일정을 조회할 때는 그 날짜를 다시 데이터 키로 한 번 더 암호화한 Tdate 를 키로 사용한다. 서버는 Tdate ↔ SID 매핑만 알 뿐, 어느 SID 가 언제의 일정인지는 모른다.
3. 그룹 키 분배 — 그룹장도 함부로 풀 수 없음
그룹 생성 시 클라이언트가 AES-GCM 256-bit 그룹 키(GSK) 를 생성하고, 그룹장의 데이터 키로 한 번 더 감싸 서버에 올린다. 그룹원 초대 시에는 GSK 가 포함된 토큰을 그룹원끼리만 주고받는다. 그룹 내에서의 사용자 식별자는 GSK 로 한 번, 다시 본인 데이터 키로 또 한 번 감싸 저장된다. 서버는 그 어디서도 평문 멤버 그래프를 재구성할 수 없다.
4. 익명 식별자(PSIDu) — 추천을 위한 일관된 가명
추천 모델이 학습하려면 같은 사용자의 행동 이력이 일관되게 누적되어야 한다. 그러나 사용자 ID 를 그대로 보내면 익명성이 깨진다.
이를 해결하기 위해 사용자 ID 를 본인만 알 수 있는 인덱스 키로 HMAC-SHA256 해시한 PSIDu 를 추천 요청 시 송신한다. HMAC 은 결정성이 있어 같은 사용자는 항상 같은 PSIDu 를 만들지만, 해시는 단방향이므로 서버는 PSIDu 에서 원본 사용자 ID 를 역산할 수 없다.
추천 모델
추천 모델은 팀의 추천 담당 팀원이 설계·구현한 영역이라, 내가 직접 짠 부분은 아니다. 다만 프론트엔드가 어떤 입력을 보내는지, 결과를 어떻게 받는지 맞추기 위해 구조는 함께 정했으므로 그 범위에서 요약한다.
전통적인 행렬 분해(SVD) 기반 추천은 정확도가 낮고, 딥러닝 기반 모델은 학습 자원이 과도하다는 한계가 있다. 팀은 Funk SVD 의 잠재 인자 학습에 사용자 컨텍스트 점수를 가중합하는 하이브리드 방식을 택했다.
최종 추천 점수는 다음과 같이 정의된다.
SC = w₁ · Funk_SVD(사용자, 장소, 평점)
+ w₂ · Distance(현재 위치, 장소 위치)
+ w₃ · Category(선호 카테고리, 장소 카테고리)
+ w₄ · History(사용자, 방문 횟수)
이때 사용자 키로는 앞서 설명한 PSIDu 가 쓰여, 행동 이력은 누적되지만 서버는 실제 사용자 신원과 그 이력을 결합할 수 없다.
학회 발표에서 보고된 측정 결과는 다음과 같다.
| 모델 | Precision@20 | NDCG@20 |
|---|---|---|
| 기본 SVD | 0.3505 | 0.3560 |
| NCF | 0.3740 | 0.3748 |
| 제안 모델 (Funk SVD + 컨텍스트) | 0.6305 | 0.6260 |
응답 시간 또한 로컬 환경에서 측정한 결과, 가장 무거운 동작인 캘린더 일정 등록이 평균 28 ms, 그룹 초대가 12 ms 수준으로 500 ms 이내 응답 목표를 충분히 달성했다.
내가 프론트엔드에서 책임진 것
논문이 정의한 보안 모델을 실제로 동작하는 모바일 웹으로 옮기는 일이 내 몫이었다. 핵심 작업은 다음과 같다.
- 종단간 암호화 파이프라인. 외부 암호 라이브러리 없이 브라우저 표준 Web Crypto API 만으로 PBKDF2 · HMAC-SHA256 · AES-GCM 흐름을 구성. 키 보관은 IndexedDB 의 추출 불가 CryptoKey.
- 그룹 키 분배와 다단계 암호화 식별자. 그룹 생성·초대·가입 시 그룹 키와 멤버 식별자가 서버 어디서도 평문으로 재구성되지 않도록 3 단계 복호화 체인을 구현.
- 추천 요청 시 익명 식별자 생성. 사용자 본인만 재현 가능한 결정성 HMAC 으로 PSIDu 를 만들어 송신.
- 실시간 시간표 조율 UX. TanStack Query 의 refetchInterval 을 드래그 입력 상태에 대한 함수로 두어 WebSocket 없이도 다중 사용자 동시 편집 충돌을 막음.
이 의사결정 4 건은 포트폴리오의 TimeTogether 프로젝트 페이지 에 상세 카드로 정리해두었다.
회고
잘한 것
보안 요구사항을 클라이언트 책임으로 흡수한 것이 결과적으로 단순한 구조를 낳았다. 영지식 구조라는 단어가 무겁게 들리지만, 결국 "서버는 암호문만 본다" 라는 한 줄 규칙이고, 그 규칙을 깨지 않도록 모든 송신 경로에서 키 유도·암호화·해시를 일관되게 적용했다. 클라이언트 코드 안에서만 보안 규칙을 검증할 수 있게 되어, 백엔드 팀원과의 인터페이스도 단순화됐다.
외부 암호 라이브러리를 도입하지 않은 결정이 옳았다. Web Crypto API 만으로 PBKDF2 / HMAC / AES-GCM 이 충분히 처리됐고, 번들 크기와 공급망 위험을 함께 줄였다. 모바일 브라우저에서의 키 유도 속도도 체감 가능한 수준의 지연이 없었다.
아쉬운 것
추천 모델의 심화 부분까지 함께 다루지 못한 것이 아쉽다. 초기 학습과 데이터 파이프라인 구성까지는 함께 했지만, 잠재 인자 차원 선택이나 가중치 w₁₋₄ 의 튜닝 같은 모델링 핵심 의사결정은 담당 팀원에게 맡겼다. 다음에 비슷한 협업을 한다면 모델 측 의사결정에도 더 깊이 들어가 보고 싶다.
블라인드 인덱싱(Tdate ↔ SID) 흐름의 클라이언트 측 구현이 미완. 논문 설계상 일정 시간 자체도 클라이언트 측에서 암호화해 송신해야 하지만, 현재 프론트엔드는 날짜 자체는 평문으로 보내고 서버가 매핑을 반환하는 절충안으로 동작한다. 정합성을 더 끌어올리려면 이 부분도 클라이언트 측 암호화로 옮길 필요가 있다.
실서비스 트래픽 측정이 없다. 모든 응답 시간은 로컬 환경에서의 인터셉션 측정값이다. 실제 모바일 셀룰러 네트워크와 PBKDF2 200k 회 반복의 디바이스 편차까지 포함한 측정이 다음 단계 과제다.
참고
- 편강, 이혜리, 방우혁, 윤희수, 강동윤, 박소영. 「사용자 익명성을 보장하는 맞춤형 장소 추천 시스템」, 한국정보처리학회 학술발표대회 논문집.
- 프론트엔드 저장소: NextTimeTogether-Frontend