💡 정책서란?
정책
서비스를 관리하는 원칙이나 규율
정책서
서비스를 관장하는 용어와 운영정책과 원칙을 정의한 산출물
문화, 역사, 인프라는 서비스 기획에 많은 영향을 준다!
- 지역적 인프라, 문화적 특성 ⇨ 서비스 기획 발전의 시작
- 현지 문화나 인프라를 잘 이해하지 못하면 기획을 실패할 수 있음
✔️ 서비스 기획자들은 문화와 역사, 다양한 인프라에 대한 이해와 그런 인프라가 어떻게 바뀌는지, 그 변화에 따라 운영하는/새로 만들어갈 서비스에 어떤 영향을 주는지를
잘 판단해서 서비스 정책을 세워야 한다! ✔️
정책서 작성을 위해 고려해야하는 법률
✒️ 서비스 정책서 작성
불가항적인 요소를 우선 고려하여 정책 결정하고 문서 작성
작성된 정책 문서를 공유하여 합의를 이룰 때까지 수정/피드백 반복
01. 우선적으로 서비스의 지역과 특성에 맞는 법령에 대한 고려가 최우선!
WHY> 법과 제도는 가장 바뀌기 어려운 부분!BUT> 법과 제도의 변화를 잘 살펴보한 포거나 기존의 법과 제도의 허점을 파악한다면 그것은 중요한 포인트가 될 수 있음
02. 외부 환경이라 할 수 있는 산업 생태계와 인프라에 대한 부분 고려
WHY> 산업 생태계와 인프라는 쉽게 바뀔 수 없다!
03. 경쟁사를 살펴보며 그들의 강점/약점 등을 살펴보고 분석
WHY>이를 분석하는 것만으로도 관련 법령과 생태계에 대해 많은 것을 파악할 수 있음
04. 내부 환경 및 리소스 고려
🔎 IT 기획자라면 알아야 하는 기본적인 법령과 직업 윤리 교육
" 서비스 기획은
법의 테두리 안에서 현행법을 준수하면서
우리 서비스의 수많은 정책을 만들고, 가치판단을 해야 하는 과정의 연속! "
⇨ 하나의 정책을 세우기 위해 하나의 법령만 봐야 하는 것이 아니라, 다양한 법률이 엮여 있는 경우도 많음
⇨ 기존에는 정의가 안 되어 있지만, 이후에 시행령 등을 통해 새롭게 정의하고 준수해야 하는 경우도 있음😮만약 이러한 법령에 대한 이해도가 없다면?😮
- 서비스가 커진 다음에 고치고 보완하려면 더 많은 비용이 들 수 있음
- PMF를 찾은 이후에는 성장과 동시에 정책 준수를 위한 계획을 세우고,
그렇게 하기 위한 인프라를 준수 해야 나중에 문제가 될 때 빠르게 대응 가능💡 성문법 vs 불문법
성문법(= 대륙법)
- 독일의 바이마르 헌법을 기반으로 관리된 법률
- 열거법이라고 하는데, 법이 열거되어 있는 것을 기반으로 판단
- 기존 열거되어 있는 것을 어떻게 해석하느냐에 따라서 법률의 규정이 바뀔 수 있음
- 법이 없으면 기존의 법을 광의적으로 해석해서 끼워맞추는 형태로 진행
- 기존에 열거되어 있는 법을 해석해서 진행하다 보니,
그만큼 해석하는데 시간이 걸리기 때문에 혁신을 하는 데 불리
⇨ 해결하기 위해 나온 것 > ‘규제 샌드박스'
불문법
- 원칙적으로는 법문을 작성해놓지 않은 불문법
- 기존의 판례를 바탕으로 해석하고 배심원 제도도 활용
- 판례가 없으면 문제가 안 되는 것이고,
문제가 생겨 판례가 생기면 그 때부터 법에 대한 부분이 결정한국이 대륙법을 기반으로 만들어졌지만,
국회에서 우리나라 실정에 맞게 법을 수정하고 제정✅ 서비스 기획자들은 대략적인 한국 법에 대한 이해만 있으면 됨
커머스 서비스를 기획하기 위한 기본, 전자상거래법
🛍️ 전자상거래법
- 금융 거래 또는 서비스 및 물품 거래를 할 때 영향을 받는 법률
- 원래 법률의 이름은 ‘전자상거래 등에서의 소비자보호에 관한 법률’
⇨ 서비스 규정에 맞게 소비자 보호를 위해 지켜야 하는 법률
❗최근 IT 서비스의 발전에 따라, 전자상거래법의 중요성도 증가❗
서비스를 직접 제공하는 업체 뿐만 아니라, 당근마켓 등 각 소비자와 판매자를 이어주는 중개업체도 전자상거래법 대상으로 포함시켜서 판매자의 귀책을 중개업자에게도 부과
이 외 다양한 책임을 플랫폼 중개업자에게 부과한다고 함
데이터 3법으로 바뀌는 미래와 서비스 기획
👤 개인정보 보호법
- 개인정보의 처리와 보호에 관한 법률
- 개인정보의 수집, 이용, 제공, 관리, 파기 등을 규정하여 개인정보 주체의 권익을 보호하고 개인정보를 처리하는 기업이나 단체의 책임을 명확히 하는데 목적
🔐데이터 3법
개인정보 보호법,신용정보법,정보통신망법3가지 법률에 대한 중복 규제를 없애, 개인정보와 개인정보가 아닌 정보로 구분해서 가명정보를 활용해서 데이터를 활용할 수 있도록 하고, 본인이 개인정보의 주체가 되어서 관리할 수 있도록 하는 마이데이터 사업의 근간이 되는 법률
- 마이데이터 플랫폼 사업은 다양한 비즈니스 기회를 만들어줄 것
- 기업이 개인의 상황과 필요에 맞게 개별적인 금융 서비스도 제공하는 초개인화 비즈니스도 가능
큰 IT 회사에서는 꼭 거쳐야 하는 관문, ISMS
🗃️ ISMS(Information Security Management System)
- 정보보호 관리체계, 정보보안 경영 시스템
- 기업이나 특정 조직에게 적용
- 회사의 기술/물리적 보호 조치를 포함한 종합 관리 체계가 방송통신위원회에서 고시한 기준에 적합한 지를 한국인터넷진흥원 KISA에서 인증하는 것
ISMS의 종류
🤔 ISMS, 왜 할까요?
목적
정보 보호 대책을 세우고 위험에 대응하는 등 여러 보안 대책을 유기적으로 통합해서 관리
- 비즈니스 안정성 강화
- 정보 보호 법적 준거성 확보
- 기업의 높은 보안과 안정성 보유 인증 ⇨ 기업 신뢰도 향상
해외 인증 사례 - PCI-DSS, GDPR
💳 PCI-DSS(Payment Card Industry-Data Security Stand ard)
- 해외에서 통용하고 있는 지불 카드 산업 데이터 보안 표준
- 카드 소유자의 데이터 저장/처리/전송하는 모든 이해관계자가 준수해야할 규칙을 정의
- 최근 카드 정보에 대한 노출이나 사고 규모 및 빈도가 늘어나게 되면서, 이에 대한 공동 대응으로
American Express,Discover,JCB,Mastercard,Visa다섯 개 글로벌 카드사가 협력해서 만든 위원회 - 데이터, 응용 프로그램, 하드웨어, 암호화라고 하는 네 가지 표준을 수립,
이 중 데이터 관련 보안 표준이 PCI-DSS - PCI-DSS에서 보호하고자 하는 데이터
-카드 소유자의 데이터: 소유자 이름, 카드 번호, 유효기간 만료일, 서비스 코드
-민감 인증 데이터: 마그네틱, 칩 데이터, CVC 데이터
🌐 GDPR(General Data Protection Regulation)
- 유럽연합의 일반 개인정보보호법
- 디지털 단일 시장에서 EU 회원국 간의 개인정보의 자유로운 이용/이동을 보장하는 동시에, 정보 주체의 개인정보 보호 권리를 강화하는 일반 정보 보호법
- GDPR의 7대 처리 원칙
적법성, 공정성, 투명성의 원칙,목적 제한의 원칙,개인정보처리 최소화,정확성의 원칙,보관기간 제한의 원칙,무결성 및 기밀성의 원칙,책임성의 원칙
⇨ 7가지 원칙에 의해 개인정보는 필요에 의해서 마음대로 처리되는 것이 아닌, 반드시 법적 근거에 의해서만 처리 - 잊혀질 권리, 개인정보 이동권, 프로파일링을 포함한 자동화된 처리에 대한 선택권 등 다양한 권리를 명문화해서 훨씬 더 정보 주체에 대한 권리를 강화
- EU에 사업장을 가지고 있는 기업뿐만 아니라, EU에 사업장을 갖고 있지 않더라도 EU의 정보 주체인 거주자에게 재화나 서비스를 제공하거나 그들의 행동을 모니터링 하는 기업 규제
규제와 서비스 기획자
⇨ 스타트업 생태계 발전을 위해서는 규제 완화를 해야한다!
⇨ 규제에 맞춰 새로운 서비스에 대한 정책을 기획하고 사업의 기회를 보는 것이 기획자 마인드 !
스타트업과 이득단체 간 갈등
- 기존의 비즈니스 모델에서 혁신을 추구하고 있는 스타트업에게 레거시 사업자들이 자기네들의 이권을 침해한다고 하면서 다양한 법률 해석을 달리하면서 고발
대형 IT 플랫폼 회사에 대한 규제
- 기업은 시장을 독점해서는 안됨, 건전하게 경쟁 ⇨ 생산성 향상, 소비자 가격 낮춤
- 수많은 생산자, 플랫폼 노동 대상 확장
정부 정책 방향
- 불공정 거래의 개선 문제, 문어발 식 사업 확장 ⇨ 온라인 플랫폼 법 재정 필요
- 국내와 대형 플랫폼의 의무 부여 갑질 ⇨ 과징금 추징
⇨ 서비스 정책, 협력, 데이터/어드민 관리 하며 서비스 발전시키는 것이 기획자의 역할
규제 샌드박스의 이해
🥪 규제 샌드박스
- 신기술과 신서비스의 원활한 시장 진출을 지원하기 위해,
혁신성과 안정성을 바탕으로 시장 진출의 기회를 주거나
시간과 장소, 규모의 제한을 두고 실증 테스트를 허용하는 혁신의 실험장
ex) 모바일 전자 고지서, 모바일 운전 면허증, 금융 규제 샌드박스
서비스 약관과 정책서
- 새로운 서비스/기능 만들 시, 신규 약관 및 개인정보 동의서 추가 및 변경 작업 필요
⇨ 법무팀 등 정책 가이드라인이 있는 지 확인 필요 - 경쟁사의 서비스와 이용약관 등을 비교/분석하여 검토
⇨ 서비스의 정책에 들어가는 법률의 근거까지 확인 필요
⇨ 어떤 법의 어떤 항목/개정 공고에 따라서 정책이 정해졌는지를 알아야 문제가 생기지 않음 - 대략적인 서비스 개요 및 고객 정보 흐름 비슷한 업체에 대한 리스크 전달
⇨ 법무팀 검토 요청
01. 표준 이용 약관
- 공정거래위원회에서 만든 표준 약관 양식 각 서비스 카테고리에 따라
서비스에 맞게 업그레이드/수정 - 보통 전자상거래나 전자금융거래 이용약관 등을 활용
02. 경쟁사 약관 확인
- 약관과 개인정보 동의서를 보면 회사의 제휴 업체, 중요 데이터, 서비스 플로우 등을 인지할 수 있음
03. 약관 업데이트 필요
- 제휴사가 늘어나거나 법이 바뀌거나 우리가 다루는 업무가 늘어나면, 바뀐 만큼 약관 업데이트를 추가해야 함!
고지
개인정보 처리에 대한 동의를 받는 경우 해당 내용에 대해서 동의서 등에 명시하거나 구두로 정보 주체에게 알려주는 행위
ex) 서비스 공지사항, 팝업 등**통지
개인정보 보호법이 정하는 일정 사항을 정보 주체 개개인에게 도달되도록 알리는 행위 고객에게 직접 푸쉬를 보내서 버튼 등을 통해 동의를 받거나 공지사항을 주더라도 읽었다는 동의를 받도록 통지문을 전달
✔️ 서비스 기획자는 이런 법령을 지키면서 고객이 최대한 불편해하지 않지만
해당 내용을 인지할 수 있도록 공지나 통지에 대한 문구 등에 대해서도 설계해야 한다!✔️
정책서 작성 사례
⌨️ 정책서
- 서비스의 용어와 기본 운영정책을 정의한 프로젝트 산출물
- 정책서를 통해서 서비스의 용어를 통일, 비즈니스에 대한 방향성을 이해
정책 정의를 위해
서비스의 비즈니스 구조와 운영 프로세스가 먼저 확정되어야 함
⇨ 관련 담당자들과 어떤 프로세스로 운영할지 충분히 협의해서 서비스 방향과 전략이 포함되어야 함
👩🏻💻 회원 정책
B2B 기업 고객과 B2C 개인 고객이 있는 마켓플레이스 모델에 대한 회원 정책서
회원 유형 정의
- 고객
B2C고객↔B2B고객의 연결지원 - 관리자
특수 권한 관리자,개인정보 책임자,일반 관리자
회원 가입 및 생성
점유인증
- 사전에 약속한 물리적 물체를 기반으로 인증
ex) 휴대폰 점유 인증 : 일회성 비밀번호를 수신해서 입력 ⇨ 휴대폰 소유자가 실시간증명
본인인증- 공동 인증서 등을 활용해서 진짜 본인임을 증명
- 점유 인증은 법적으로 이를 본인인증으로 보지는 않음
그 외, 회원 가입 정책 / 회원 가입 방식 -카카오싱크 / 회원 인증 정책 / 개인 고객 가입 절차 / 기업 고객 및 관리자 가입 절차 / 휴대폰 번호 중복 인증 처리 절차 / 비밀번호 찾기 절차 / SSO 정책 등이 있음
SSO(Single Sign-On) 정책
- 통합인증(ex - OAuth 로그인)
- 한 번의 로그인으로 다른 사이트들을 자동 접속해서 이용할 수 있는 것
- 하나의 사용자 정보 기반으로 여러 시스템에서 하나의 통합 인증을 사용할 수 있게 되는 것
요구사항 정의서(PRD) 작성하기
✅ PRD(Product Requirement Document)
- 요구사항 정의서
- 신규 서비스나 기능 등 업데이트와 기존 서비스의 변경 등 서비스에 대한 변화를 가져오기 위해서 변경 요구사항을 정의하는 것
내부 요구사항: 개발팀 내부에서 정의한 것외부 요구사항: 서비스를 운영하는 운영팀이나 새로운 상품을 만들어야 하는 사업개발팀, 영업팀에서 문의 많이 들어 옴- 다양한 업무 대응 측에서 중요도가 높다고 판단되는 내역에 대해서, 요구사항 정의서부터 작성해서 업무 시작
- 요구사항 정의서가 없으면 서비스 방향성이 틀어질 수 있으며, 가독성이 떨어지거나 충분하지 못할 시 개발팀과의 커뮤니케이션 힘듦
도입배경 및 목적
- 문제가 무엇이며, 이를 통해 어떤 개선을 원하는지
타겟 고객 (내부 사용자일 수 도 있음)
- 해당 문제를 겪고 있는 타겟 고객이 누군지
기대 효과 (매출 혹은 생산성 향상)
- 이를 통해 예상하는 효과
고객 기준의 플로우차트
- 변경 이후 고객은 서비스를 어떻게 사용할 수 있을 지
기능 정의
- 실제로 문제를 해결하기 위한 방안, UI를 제안하면 안됨
ex) 기능 정의서 샘플
예시나 참조 수준을 넘는 메뉴 트리나 화면을 그리면 안 됨!
WHY) 직접 화면을 구성하는 디자이너의 창의성을 제한할 가능성이 높기 때문
✒️ 요구사항 정의서 작성 순서
요구사항 정의 > 초안 작성 > 협업 논의 > 초안 수정 > 개발조율- 빠르게 초안을 만들어서 해당 업무 담당자들과 협업 진행
- 법적인 문제가 될 만한 것이 있으면 법무팀에도 확인
- 정보 보안 이슈가 생길 수 있으면 정보 보안 팀의 검토 필요
- 이후 요구사항이 맞는지 개발자 및 디자이너들과도 계속 논의해가면서 요구사항 정의서 업데이트
😮 정책서 vs 요구사항 정의서
정책서 기반으로 요구사항 정의서를 맞춰나가는 형태로 진행하기는 하지만, 일정의 시급함 및 요구사항의 중요도로 인해서 기존 정책서의 정책이 어긋나는 경우도 있음
그 경우, 해당 정책을 지키지 못했을 때의 리스크와 해당 요구사항을 통한 기능 추가로 얻게 되는 사업적 이득을 잘 판단해야함
🐣 오늘자 일기
법적 이야기가 나오니까 이과인 나한텐 ㄴㅓ무 머리 아프다,,,😣😣😣
이런 부분도 기획자가 다 확인을 해야 되구나,, 따로 법무팀이 있어서 해당 팀에서 해주는 줄 알았는 데 그게 아니었다니,, 하긴 전 회사에서도 PG사를 운영했는데 법무팀 부서는 없었던 걸로 기억하는 걸로 보면 이런 건 해당 부서 사업팀이나 운영팀이 관리하는 것일지도,,
배운 점! 정책서 만들 때 다양한 법률적 이해, 시스템/인프라 이해, 서비스의 비전과 현재 상태에 대한 깊은 이해도가 필요하다. 또한 정책서는 지속적을 업데이트/관리해야 된다!
