목표

✅ QA 리스트 작성
✅ 개발 맡기기
🔄 개인정보처리방침 작성
🔄 서비스 이용약관 작성
🔄 VOC 폼 작성

🌟 목표 달성률 : 70%

최종 프로젝트

디자인 → 개발 핸드오프 준비

• Claude Design에 있던 프로토타입을 Figma로 옮김
• QA 리스트 작성
• 기능명세서 수정 후 개발 튜터님께 전달
• 개발 러프본을 받아서 기능명세서 재수정

토큰 이슈로 클로드 디자인과 피그마 디자인을 둘 다 써보게 됐는데 아직 피그마가 나은 것 같다. 다음에는 클로드로 스케치하고 피그마로 픽스해야겠다. 토큰을 아껴쓸 것.

QA리스트 쓰는데 알고리즘 QA가 쉽지 않을 것 같다는 생각이 들었다. 단순히 버튼 기능 구현, 페이지 잘 넘어가는 지 뿐만 아니라 추천 결과가 우리가 넣은 알고리즘 수학식대로 도출되는지를 검증해야 되다보니... AI랑 어떻게 잘 해봐야지..

기능명세서는 쓰고 또 써도 매번 누락된 부분이 나온다. 러프본이라는 '실제 구현'과 대조하고 나서야 비어 있던 칸이 보였다. 명세서는 한 번에 완성되는 문서가 아니라 구현과 계속 왕복하며 채워지는 문서라는 걸 다시 체감.

법적 문서 2종, VOC 폼 분담 작성

팀에서 아래 세 가지를 나눠 작성했고, 나는 서비스 이용약관을 맡았다.

• 개인정보처리방침
• 서비스 이용약관 ✅
• VOC 폼

다른 서비스 약관을 참고하며 작성하던 중, 우리 서비스가 건강 상태 정보를 수집한다는 점이 걸렸다. 물론 질병 코드나 처방을 묻는 것이 아닌 단순 취미 추천을 위한 완전 러프한 질문들이지만...

질문 리스트

① 허리·무릎·발목이 불편해요
② 어깨나 팔을 쓰기 힘들어요
③ 손이나 손목이 불편해요
④ 쉽게 숨이 차거나 체력이 부족해요

이게 민감정보에 해당하나? 사업자 등록이 필요한 건가? 관련 법을 찾아보다가 팀 내에서 판단이 안 서서 튜터님께 질문했다.

💬 김소연 튜터님

① 사업자 여부는 무관하다

사업자 등록 여부와 개인정보 이슈는 별개다.
다만 개인정보 처리자로서 지켜야 하는 규제는 존재한다.

② 저장 여부가 핵심 분기

단순 설문으로 끝나고 저장하지 않으면 → 괜찮다. 추천에 쓰는 정도면 단순 설문으로 본다.
사용자 계정에 저장하고 활용하면 → 문제가 될 수 있다.

⚠️ 그런데 취미 마당은 마이페이지에서 수정 가능하도록 저장을 한다. 즉 "단순 설문"으로 끝나지 않는 구조라, 그냥 넘어갈 수 없는 지점이었다.

③ 그래서 어떻게 우회했나

우리가 받는 '건강 상태'는 질병 관련 정보가 아니다. 허리디스크 진단·처방 같은 걸 묻는 게 아니라, "불편함 / 어려움 정도"를 물을 뿐이다.
결론적으로:

'건강 상태' / '민감 정보'라는 워딩 자체를 쓰지 않는다.
'컨디션 체크'처럼 우회하는 단어를 쓴다.
질문도 최대한 우회하는 방향으로 설계한다.

배포를 하는 서비스인 만큼, 걸릴 수 있는 부분은 미리 제한하고 특히 건강 관련은 훨씬 보수적으로 잡는다.

튜터님이 처음엔 괜찮을 것 같다. 그래도 "컨디션 체크라는 표현으로 우회"하면 좋을 것 같다라고 하셨다가, 다시 와서 "최대한 우회하는 방향으로 질문하면 좋겠다 / 최대한 문제가 없게끔 하는 게 베스트"라고 하셨다. 결국 방향은 표현·설계 단계에서 리스크를 애초에 만들지 않는 것.

오늘의 회고

• 잘한 점: 개인 정보 처리에 대해 의문을 가지고 튜터님께 질문한 것
• 아쉬운 점: 목표를 완수 하지 못한 것
• 원인: 금방 끝날 줄 알았는데 생각지도 못한 부분에서 막혔다. 생각보다 개발이 빠르게 진행되어서 여유를 좀 가졌더니..
• 개선 액션 아이템: 전체적인 러프한 계획을 다시 그려보고 우선 순위를 정해서 매일 할 일 배정하기

오늘 약관 쓰다가 튜터님한테 물어본 게 은근 많이 남는다. 처음엔 그냥 "건강 정보 받아도 되나요?" 싶어서 물어본 건데, 돌아온 답이 "확인은 해봐야겠지만 보수적으로 본다"였다. 애매하면 일단 안전한 쪽으로 기운다는 그 감각이 좀 인상적이었다.
그리고 오늘 제일 크게 배운 건, '건강정보'라는 라벨 하나로 다 뭉뚱그리면 안 된다는 거였다. 같은 정보라도 질병에 관한 거냐 아니냐, 계정에 저장하고 활용하냐 그냥 설문으로 끝나냐, 워딩을 뭐라고 쓰냐에 따라 리스크 등급이 완전히 달라졌다. 나는 그냥 "건강 = 민감정보 = 위험"으로만 생각했는데, 실제론 훨씬 결이 여러 개였다.
또 하나는, 법적 리스크가 결국 기획이랑 문구 설계랑 딱 붙어 있다는 거였다. 약관은 법무팀이 알아서 하는 거라고 막연히 생각했는데, 오늘 보니까 "이 단어를 쓸까 말까", "이 정보를 저장할까 말까" 같은 기획 단계의 결정이 곧 법적 리스크로 이어졌다. 약관이 별개의 일이 아니라 서비스 설계의 연장선이라는 걸 몸으로 배운 느낌이다.
마지막으로, 아주 사소한 데서 문제가 생길 수 있어서 현업에서도 이런 걸 진지하게 따진다는 걸 알게 됐다. 별거 아닌 것 같은 단어 하나, 저장 여부 하나가 나중에 문제가 될 수 있다는 거. 앞으로 기획할 때 이런 디테일을 그냥 넘기면 안 되겠다는 생각이 들었다.

💭 오늘의 한 줄 평 : 기능 명세서란 영원히 수정하는 것...