위로미 v3

일반적인 서비스 데이터라면 기능 구현과 운영 편의성을 먼저 볼 수도 있습니다. 그런데 위로미는 조달청 혁신제품으로 실제 기관에 납품되는 제품이었고, 사용자의 마음검사와 상담 내용을 다뤘습니다. 납품처에서도 DB 저장 위치, 저장 방식, 관리자 접근 범위를 중요하게 봤습니다.

상담 내용은 사용자가 직접 털어놓은 민감한 정보입니다. 그래서 누가 어떤 범위까지 볼 수 있는지, 전송·저장 구간에서 어떻게 보호되는지, 관리자 화면과 로그에 불필요하게 노출되지 않는지가 중요했습니다. 기능이 서로 얽혀 있으면 이런 책임을 설명하기 어려워지고, 운영 중 문제가 생겼을 때 어느 흐름을 봐야 하는지도 흐려집니다.

그래서 목표를 이렇게 잡았습니다. 기관별 접근 권한, 전송·저장 구간 암호화, 관리자 화면과 로그의 민감 정보 노출 최소화, 상담 기록 관리 기준, 위험 언어 필터를 백엔드 구조 안에서 추적 가능하게 만들자.

가장 먼저 본 것은 기능 이름이 아니라 데이터가 지나가는 경로였습니다. 키오스크와 모바일에서 들어온 상담 데이터가 서버에 도착하고, 저장되고, 관리자 화면에서 조회되는 흐름을 나눠 봤습니다. 그 위에서 기관별 접근 권한, 전송·저장 구간 암호화, 관리자 화면과 로그의 노출 최소화가 필요한 지점을 백엔드 구조 안에 반영했습니다.

1. 1

   접근 권한

   기관과 관리자 역할에 따라 볼 수 있는 상담 데이터 범위를 제한했습니다. 납품처별 데이터가 섞이지 않도록 API 요청 단계에서 접근 범위를 확인했습니다.

2. 2

   전송·저장 보호

   전송 구간과 DB 저장 구간에서 상담 데이터가 평문으로 노출되지 않도록 암호화 요구사항을 반영했습니다. 상담 데이터는 일반 로그처럼 흘러가지 않게 다뤘습니다.

3. 3

   노출 최소화

   관리자 화면과 서버 로그에서 상담 원문이나 식별 정보가 불필요하게 드러나지 않도록 조회 범위와 기록 방식을 조심스럽게 다뤘습니다.

이렇게 정리하고 나니, 상담 데이터가 들어오는 흐름과 관리자에게 보이는 흐름을 구분해서 볼 수 있었습니다. 변경 지점이 더 분명해졌고, 민감 데이터 처리 요구사항도 특정 기능 안에 묻히지 않게 됐습니다.

재설계에서 제가 함께 신경 쓴 또 하나는 상담 안전 필터였습니다. 정신건강 상담에서는 단순 금칙어뿐 아니라 위험 언어, 고위험군 신호처럼 놓치면 안 되는 표현이 있습니다. 이 흐름을 일반 상담 응답 로직에 섞어 두면, 나중에 기능이 바뀔 때 안전 요구사항이 함께 흔들릴 수 있습니다.

그래서 위험 언어·금칙어 필터를 별도 API 흐름으로 다루고, 상담 기록 관리 기준과 함께 보게 했습니다. 안전 필터는 부가 기능이라기보다, 정신건강 상담 제품에서 상담 데이터가 처리되는 방식의 일부라고 봤습니다.

이 방식은 손이 더 갑니다. 권한, 저장 방식, 로그, 관리자 화면을 함께 봐야 하니까요. 그래도 납품처가 민감하게 보는 정신건강 상담 데이터라면, 기능을 빠르게 붙이는 것보다 처리 책임을 설명할 수 있는 구조가 더 중요하다고 판단했습니다.

재설계를 거치며 상담 데이터가 들어오고 저장되고 조회되는 흐름을 더 분명히 설명할 수 있게 됐습니다. 기관별 접근 권한, 전송·저장 구간 암호화, 관리자 화면·로그의 노출 최소화, 상담 기록 관리 기준, 위험 언어·금칙어 필터를 함께 고려해 백엔드 구조를 정리했습니다.

이 프로젝트에서 가장 크게 남은 건 민감 데이터는 기능 단위가 아니라 흐름 단위로 봐야 한다는 점이었습니다. 상담 내용이 어디서 들어오고, 어디에 저장되고, 누가 볼 수 있고, 어디에 남지 않아야 하는지를 같이 봐야 했습니다.

물론 한 번 구조를 정리했다고 끝나는 일은 아닙니다. 납품처 요구사항, 운영 정책, 관리자 기능이 바뀌면 접근 범위와 저장 방식을 다시 확인해야 합니다. 상담 안전 필터도 운영하면서 계속 검증을 쌓아 가야 하는 영역이라고 봅니다.

첫 인턴 프로젝트에서 사용자가 보는 화면 뒤의 데이터 처리 흐름을 책임지고 정리해 본 경험은 제게 백엔드의 무게를 가르쳐 줬습니다. 앞으로도 기능을 붙이기 전에, 그 데이터가 어디로 흐르고 어디까지 노출되는지 먼저 확인하는 쪽으로 일하고 싶습니다.