일기 slecs

출시 전 이용약관·개인정보처리방침 초안을 버전 관리에 먼저 올린 이유

목차

서비스를 실제로 사용자 앞에 내놓기 전에 반드시 통과해야 하는 관문이 있다. 바로 이용약관과 개인정보처리방침이다.

왜 지금 이 작업인가

기능 개발에 집중하다 보면 이런 문서 작업은 자꾸 후순위로 밀린다. "나중에 하면 되지"라는 생각이 팀 전체에 깔려 있다가, 출시 직전에 터지는 게 이 작업이다. 그래서 이번엔 의도적으로 일찍 치고 들어갔다. docs 디렉토리에 TERMS.mdPRIVACY.md 두 파일로 v1.0 초안을 잡아놓는 것, 그게 오늘 커밋의 핵심이다.

"코드도 아닌데 커밋 로그에 남겨야 하나?" 라고 할 수 있는데, 나는 이게 오히려 더 중요하다고 본다. 약관은 버전 히스토리가 반드시 필요한 문서다. 언제 어떤 내용이 바뀌었는지, 사용자에게 고지한 내용이 정확히 무엇이었는지가 추후 분쟁이나 심사에서 증빙 자료가 된다. Git에 남겨두는 게 가장 깔끔한 방법이다.

두 파일의 역할 차이

파일 역할 주요 포함 내용
docs/TERMS.md 서비스 이용 계약 서비스 범위, 사용자 의무, 금지 행위, 면책 조항
docs/PRIVACY.md 개인정보 처리 고지 수집 항목, 수집 목적, 보유 기간, 제3자 제공 여부, 파기 방법

두 문서는 성격이 다르다. TERMS.md는 "서비스를 어떻게 쓸 수 있는가"에 대한 계약이고, PRIVACY.md는 개인정보보호법 기반의 법적 의무 고지다. 특히 PRIVACY.md는 국내 서비스라면 개인정보보호법 제30조에 따른 의무 사항이기 때문에, 형식 요건도 꽤 구체적으로 정해져 있다. 수집 항목, 목적, 보유 기간, 파기 절차 및 방법, 이용자 권리와 그 행사 방법 등이 모두 들어가야 한다.

초안(v1.0)이라는 표현을 붙인 이유

처음부터 완성본을 만들려고 하면 작업이 끝없이 늘어진다. 법무 검토나 외부 검수가 필요한 항목은 어차피 한 번 더 손을 봐야 하기 때문에, 지금 단계에서는 "골격을 잡는 것"이 목표다. 그래서 v1.0이라는 버전 표기를 명시적으로 달았다.

버전 표기를 다는 습관은 팀 관점에서도 중요하다. "이 약관이 지금 유효한 버전인지 아닌지"를 코드베이스 안에서 바로 확인할 수 있고, 나중에 내용이 변경될 때 v1.1 혹은 v2.0으로 올리면서 변경 이력을 명확하게 남길 수 있다. 사용자에게 약관 변경을 고지해야 하는 시점을 판단할 때도 버전 기준이 있으면 훨씬 깔끔하다.

docs/
├── PRIVACY.md   ← 개인정보처리방침 v1.0
└── TERMS.md     ← 이용약관 v1.0

구조 자체는 단순하다. 하지만 이 두 파일이 존재한다는 사실 자체가 서비스가 "공개 가능한 상태"를 향해 가고 있다는 신호다.

회고

문서 작업은 개발자 입장에서 체감 난이도가 낮아 보이지만, 실제로는 꽤 신경 써야 할 지점이 많다. 특히 개인정보처리방침은 실제로 수집하는 데이터 항목과 문서에 적힌 내용이 일치해야 한다. 나중에 앱 심사나 외부 감사에서 "문서엔 이렇게 적혀있는데 실제 코드는 다르게 동작한다"는 지적이 나오면 수습이 번거롭다. 초안 단계부터 실제 동작과 맞춰가는 습관이 중요하다.

팀장 입장에서는 이런 문서 작업을 누가 오너십 갖고 챙길 건지 역할을 명확히 해두는 것도 포인트다. 개발자가 초안을 잡고, 법무 혹은 대표가 검수하고, 최종 배포 전에 한 번 더 리뷰하는 플로우를 미리 합의해두면 나중에 "이거 누가 확인한 거야?" 하는 상황을 피할 수 있다.

끝.


🛒 이 글과 어울리는 추천 상품

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.

댓글 0

첫 댓글 달아줘.