검색

② 제1항에 따라 사업자가 보존하여야 할 거래기록 및 그와 관련된 개인정보(성명ㆍ주소ㆍ전자우편주소 등 거래의 주체를 식별할 수 있는 정보로 한정한다)는 소비자가 개인정보의 이용에 관한 동의를 철회하는 경우에도 「정보통신망 이용촉진 및 정보보호 등에 관한 법률」등 대통령령으로 정하는 개인정보보호와 관련된 법률의 규정에도 불구하고 이를 보존할 수 있다. → 따라서 현재 전자상거래법상 거래기록의 보존 의무가 있으나, 이를 사업자가 본인인증 의무를 부여하는 것으로 해석하기는 어려움. → 19세 미만 사용자 (청소년) 에 대해서는 법적 보호와 연령 기반 접근 제어를 위해 본인인증이 더욱 중요하게 적용됨. (보호자 동의 절차가 포함되는 경우도 있음)

본인인증은 시스템에 정당한 사용자가 접근했는지를 확인하는 절차로, 서비스 보안과 사용자 정보 보호를 위해 필수적으로 고려되어야 함. 단, 서비스의 목적과 민감도에 따라 인증 절차의 적용 필요 여부 및 수준을 합리적으로 판단하는 것이 중요.

3. 본인인증 vs 점유인증, 차이점 알아보기

본인인증 : ‘사용자가 진짜 본인이 맞는지?’ 확인하는 절차이며, 실명기반으로 법적 효력이 필요한 경우 본인인증을 필수로 진행

본인인증 특징

외부 인증기관과의 연동
실명 정보 기반으로 DB 대조하여 인증

본인인증 API 제공 회사

NICE 평가정보
한국모바일인증 (KMC)
다날
드림시큐리티
KG 모빌리언스

점유인증 : ‘사용자가 특정기기를 소지하며 있고 실제로 사용하고 있는지?’ 일회성으로 확인하는 절차이며, 개인정보 외에 해당 PC/모바일 기기를 물리적으로 갖고있거나 접근이 가능한지 증명하는 방식

점유인증 특징 → 인증하는 과정에서 실명확인은 생략 → 현재는 본인인증 + 생체 점유인증 조합으로 활용하여 2단계 인증을 구성하는 추세
인증 구현 방식

사용자 기본정보 입력: 이름, 생년월일, 성별, 통신사, 전화번호 등 입력
인증 요청 전송: 서버에서 무작위로 임시 인증코드 생성 및 1회성 인증번호(SMS,카카오톡 등)가 발송
SMS 전송: SMS 및 카카오톡 메시지 발송 API(KT, LG U+, 알림톡, 토스트 등)를 통해 인증번호 전송
입력 검증 절차: 사용자가 인증번호 입력 → 서버에서 임시 저장된 값과 비교 → 일치 시 인증 성공 처리
인증 처리 결과 : 코드가 일치하고 시간내에 기입했을 경우 성공 처리 및 성공 여부에 따라 다음 프로세스(예: 로그인 성공, 비밀번호 재설정)로 연결 : 반환된 인증번호 식별값은 회원가입, 로그인, 중복 가입 방지 등의 로직에 활용

회원가입/본인인증 프로세스에서 기획자의 역할 ~ 기획자의 핵심 역할 ~ 가입 전환율을 높이되, 사용자에게 인증하는 과정을 간소화하여 부담을 최소화하고, 본인인증을 통해 보안과 법적 요건을 충족하는 흐름을 만들어내는 것.

회원가입 수단 및 인증 방식 정의

서비스 특성과 법적 요건에 따라 가입 방식을 명확히 정의.
: 예를 들어, 금융·헬스케어 등 민감 정보를 다루는 서비스는 본인인증을 필수로 적용
외부 인증 수단 도입 검토 및 벤더사(예: KCB, NICE 등) 선정 업무를 수행.
인증번호 발송, 유효 기간, 재시도 횟수 제한 등 인증 절차 구체화 및 인증 실패 및 재시도 정책, 보안 취약점 대응 방안 마련. → 사용자 경험(UX) 설계 과정 필요.

약관 동의 및 개인정보 수집 구조 UX/UI 설계
- 서비스 이용 약관과 개인정보 수집 동의 절차를 UI상에 반영하여 설계.
- 전체 동의, 개별 동의, 펼침·접기 기능 등을 포함하여 사용자 편의성을 극대화.
- 이용자의 선택권을 보장하는 UX 설계를 통해, ex) 선택 약관 체크 해제 시에도 회원가입이 가능하도록 프로세스 구축.
본인인증 프로세스 설계
- 외부 인증 모듈(API) 연동에 필요한 요구사항을 도출하고, 안정적인 연동 방안을 설계.
- 서비스 유형에 맞는 인증 방식에 따라 본인인증 필요 여부를 파악 후 서비스 정책 설계.
- 유지보수와 확장성을 고려한 재사용성 높은 인증 플로우를 설계함으로써, 향후 인증 수단 추가 및 변경에 유연하게 대응.
가입 완료 후 데이터 연동 및 보안 강화
- 회원 정보 저장, 외부 인증 시스템 API 연동 및 데이터 암호화 규약 문서화하여 접근 권한 관리 정책을 수립.
- 자동 로그인, 온보딩 프로세스 등 사용자 후속 동선 설계

본인인증 제공 정보 특이사항

CI (Connecting Information)
- 동일인의 식별을 위한 암호화 고유값. 플랫폼 간 사용자 연동 가능.
- 주민번호와 같이 사람에 주어지는 고유 값이므로 다른 플랫폼간 회원 매칭 또는 회원 중복 여부 체크용으로 사용하며, 금융권에서는 사실상 필수값으로 쓰임.
DI (Duplication Information)
- 중복 가입 방지용 암호화 ID.
- 특정 서비스에 한정하여 동일값으로 제공됨.
- 타 플랫폼, 서비스 간 모두 다른 값이므로 상호 비교는 어렵고, 동일 서비스 내 재가입 체크 용도로 쓰임.

KISA 및 통신사 연동으로 제공되며, 전자서명법 및 정보통신망법의 보호 대상임.
CI와 DI의 차이점 ※ CI/DI는 주민등록번호를 대체하는 비식별 고유값이므로 보안등급이 높음. [전자상거래법 제6조 (거래기록의 보존 등)]

CI/ DI의 차이점

기획서 (화면설계서, 기능정의서 등) 버전업은 어떤 기준으로 하면 좋을까요?기획/PM

기획서의 버전업 기준을 설정할 때는 명확한 기준과 일관성이 중요합니다. 다음과 같은 기준을 적용하면 효율적으로 관리할 수 있습니다.

버전 구분

Semantic Versioning (SemVer) ● Major.Minor.Patch (예: 1.2.3)
- Major (주버전): 큰 방향성 변화, 신규 기능 추가 또는 대규모 개편 시
- Minor (부버전): 기능 추가, UX/UI 개선, 개선 사항 반영 시
- Patch (수정버전): 오탈자 수정, 경미한 버그 수정 시

예시) SRS_v1.0.0: 초기 기획서 배포 SRS_v1.1.0: 신규 기능 추가 SRS_v1.1.1: 오타 및 사소한 수정

Calendar Versioning (CalVer)

YYYY.MM.DD 형식 사용
날짜 기반으로 관리하는 방식이며, 정기 업데이트 시 유리합니다.
특히, 기능 정의서처럼 릴리스 주기가 정해진 문서에 적합합니다.

예시:

SRS_2024.03.01 → 2024년 3월 1일 버전
SRS_2024.03.15 → 3월 15일 기능 추가 버전

효율적 관리 방법

파일명 규칙: 프로젝트명_버전명_날짜 (예: 당근심부름_기획서_v1.1_20240312)
변경 이력 관리: 주요 변경 사항을 간략히 기록
백업 체계: 기존 버전은 보관하고, 최신 버전만 공유
프로세스: 초안 작성 → 피드백 반영 → 최종 확정 및 기록

이러한 기준을 적용하면 기획서의 버전 관리가 체계적으로 이루어지며, 수정 및 업데이트 이력을 명확하게 정리할 수 있습니다.

기획 정책은 어떤 방식으로 정리해야하나요?개발/기술

서비스 정책서는 불가항력적인 요소를 우선 고려하며 정책을 결정하고 문서로 작성해야 합니다.

서비스를 기획하기 위해 참고해야 할 관련 법령을 먼저 검토합니다.
관련 산업의 생태계나 인프라 등의 외부 환경을 고려해야 합니다.
서비스 이용자의 성별, 연령, 행동에 대한 특성을 체크해야합니다.
벤치마킹 과정에서 경쟁사를 고려해야 합니다.
내부 환경 및 리소스를 고려해야 합니다.

**정책서 작성시 **

제품에 대한 생애 주기 관점의 프로세스 단위로 작성할 수 있습니다. *기능 개발에 대한 로직은 서비스 정책서 X, 기획서 내의 스토리보드에 포함 *주기적으로 업데이트 되어야 함.

정책서 작성 방법(아래 외에도 다양한 방법이 있음)

UseCase를 활용한 서비스 정책 방법
표 형식으로 각 케이스별 정책 정리 방법

*팀 구성원 모두가 확인하기 편한 방식으로 정리

IA 구성과 와이어프레임, UI 구성에 대해서 기획자/디자이너 간의 R&R이 헷갈립니다기획/PM

해당 부분은 회사/조직별로 다르며, R&R 정리 및 협업 프로세스 협의를 통해 가장 최선의 방법을 찾아나가야 함. 아래 내역은 참고하시기 바라며, RACI 프레임워크 참조한 적용도 좋은 방법임

협업 기준 명시

기획자 : IA / 와이어프레임 1차 설계
디자이너 : 디자인 요소/컴포넌트 관점에서 해석 & UX 요소 강화
필요 시 RACI 테이블 등 프레임워크 기준 R&R 구분도 가능.

⚠️ 리스크 요소

기획자의 기획서가 과도한 완성형으로 전달되면 디자이너는 경험 개선 여지를 찾기 어려움 → 와이어프레임은 정답이 아님. 더 나은 서비스를 위해 변동될 수 있음을 모두가 인지.

역할 정의 (R&R)

[서비스 제안 & 요구사항 도출]

기획자 : 고객 / 비즈니스 / 기능 요구 수집 및 정의, 타겟 유저 페르소나 설정 및 유저 스토리 구성
디자이너 : UX 리서치 결과 제공, 유저 페르소나 공유

[서비스 기획]

기획자 : IA 설계 및 플로우 차트 정의 (depth에 따른 계위 / 기능 흐름 구성)
디자이너 : IA 구조에 기반한 UX 관점의 구조 피드백, 디자인 관점에서 플로우 보완 제안

[와이어프레임]

기획자 : 기능 흐름 중심의 와이어프레임 설계, 화면 간 전환, 상태 흐름 정의 포함
디자이너 : 초기 비주얼 스케치 및 UX 개선안 적용, 인터랙션 및 사용성을 고려한 재구성 제안

[UI 디자인]

기획자 : CTA 및 기능 요구 명확히 정의
디자이너 : 유즈케이스(초기/이용/로딩/에러 등)에 따른 화면 디자인, 디자인 시스템 및 컴포넌트 적용 => 최종 Figma 완료본 제작

[피드백 / 수정]

기획자 : 사용자 시나리오 기반 피드백 수렴 및 정리
디자이너 : 시각적 힌트, 정보 과부하, 사용성 중심 피드백 반영, 디자인 개선안 적용

[개발 전달 (핸드오프)]

기획자 : 기능 정의서 작성, 상태 / 예외 처리 정의
디자이너 : 디자인 가이드(Figma) 제공, 스타일 가이드 포함

[공동 리뷰 & 개선]

기획자 : 개발 및 QA 결과 반영하여 기획 수정,
디자이너 : 개발 및 QA 결과 반영하여 디자인 수정

[Release 기준 정리]

기획자 : 최종 Release 기준 기획 내용 정리, 백로그 항목 검토
디자이너 : 최종 Release 기준 디자인 정리

2. 프로세스 문서화

- 프로세스
    [요구사항 정의] → [IA 구조 작성 ]→ [UX 구조 검토] → [와이어프레임 작성]→ [UI 디자인 및 비주얼 구성] → [기획자-디자이너 상호 피드백] → [최종안 확정] → [개발 진행 ] → [추가 이슈 반영 & 업데이트] 
    
- 커뮤니케이션 가이드
    - 피그마 코멘트 활용 기준
        - 모든 피드백은 @이름 태그 + 목적 명시 → 개발자가 양쪽의 의도 파악하는 것도 가능.
        - 기획자 : 기능 목적 및 기획 의도 공유
        - 디자이너 : 개선 사유 및 의도 공유
        
        (예시)
        @디자이너 기존에 정의된 팝업 대신 다른 형태의 팝업이 필요한 이유가 뭔가요? 
        @기획자 여기서 다른 형태의 팝업을 띄우는 것은 유저에게 다른 액션을 유도하기 위함입니다
        
    - 정기 Sync 및 일일 스크럼을 통해 지속 업데이트

3. 체크리스트 기반 QA

- 각 기능별 기획 의도 vs 실제 구현 내용 비교 가능하도록 UI QA 기준 정리
- 기능 QA & 디자인 QA 일정도 반영 필요
- Tip : Figma  dev mode 이용 시 개발자와의 효율적 커뮤니케이션 가능 (유료)

4. 적용 시사점

당신의 조직이 기획자 주도 조직이라면?

→ 기획자가 기능 명세 및 IA 구조, 플로우 구성, UX 디자이너에게 피드백 우선권과 리디자인 권한을 부여해야 함
당신의 조직이 디자이너 중심 조직이라면?

→ IA는 디자이너가 가져가고, 기획자는 비즈니스 로직과 기능 명세에 집중해야 함 raci 프레임워크

사이드 프로젝트에서 회원 가입을 위한 개인정보 수집할 때 꼭 사업자 등록을 해야하나요? 개인으로 수집하면 안될까요?기획/PM

사업자등록 여부와 무관하게 개인도 개인정보처리자가 될 수 있습니다. 다만, 수집·이용·보관·파기 전 과정에서 개인정보보호법 제15조, 제29조, 제30조 등 주요 조항을 반드시 지켜야 합니다.

★개인정보보호법 제15조(개인정보의 수집·이용) ① 개인정보처리자는 다음 각 호의 어느 하나에 해당하는 경우에는 개인정보를 수집·이용할 수 있다.

정보주체의 동의를 받은 경우

*기본 개념 정보주체 = 개인정보의 주인, 즉 회원가입하는 사람 동의 = “내 정보를 이렇게 쓰는 것에 괜찮다”라고 허락하는 것

사이드 프로젝트 상황에 맞추면

회원 가입 프로세스에 꼭 동의 절차를 넣어야 합법적입니다.

★개인정보보호법 제29조(수집한 개인정보를 제대로 보호할 책임) 개인정보처리자는 개인정보가 분실ㆍ도난ㆍ유출ㆍ위조ㆍ변조 또는 훼손되지 아니하도록 내부 관리계획 수립, 접속기록 보관 등 대통령령으로 정하는 바에 따라 안전성 확보에 필요한 기술적ㆍ관리적 및 물리적 조치를 하여야 한다.

사이드 프로젝트라도 회원가입을 받는 순간, 최소한 위와 같은 보안 조치를 해야 합법적인 개인정보처리가 됩니다. 사이드 프로젝트 상황에 맞추면

비밀번호 평문 저장 금지 → 반드시 해시 처리
DB 접근 제한 → 최소한 관리자만 접근 가능
데이터 최소 보관 → 서비스 운영에 필요 없는 개인정보는 받지 말 것
탈퇴 시 즉시 삭제 → 사용자가 원하면 바로 파기

★개인정보보호법 제30조 (개인정보 처리방침의 수립 및 공개) ① 개인정보처리자는 개인정보의 처리 목적, 보유 및 이용기간, 제3자 제공 등에 관한 사항을 포함하는 개인정보 처리방침을 수립하여야 한다. ② 개인정보처리자는 개인정보 처리방침을 정보주체가 쉽게 확인할 수 있도록 인터넷 홈페이지 등에 공개하여야 한다. ③ 개인정보처리자는 개인정보 처리방침을 변경하는 경우에는 그 내용을 공개하여야 한다.

개인정보를 모으는 사람(개인·사업자 불문)은 “우리 서비스는 개인정보를 이렇게 다룬다”라는 안내문(개인정보 처리방침)을 반드시 작성해야 합니다. 그리고 이걸 사용자(회원)가 쉽게 볼 수 있도록 홈페이지, 앱 화면, 가입 화면 등에 공개해야 합니다. 바뀌면 바뀐 사실을 공지해야 합니다. 사이드 프로젝트 상황에 맞추면 회원가입을 받는다면 간단한 개인정보 처리방침을 만들어서 공개해야 합니다.

수집하는 항목: 이메일, 비밀번호
이용 목적: 회원 식별 및 로그인 서비스 제공
보유 기간: 회원 탈퇴 시 즉시 삭제
제3자 제공: 없음
보안 조치: 비밀번호 암호화 저장

※추가로 고려해야 할 것들

보유기간 & 파기 (제21조)

필요 이상 오래 보관 금지.
보관 기간이 끝나면 지체 없이 파기해야 함.

정보주체 권리 보장 (제4조, 제36~38조)

사용자가 “내 정보 보여줘/삭제해줘”라고 하면 응해야 함.

민감정보/주민등록번호 금지 (제23조, 제24조)

주민등록번호, 건강정보 같은 민감정보는 특별한 경우 외에는 절대 수집 금지.
사이드 프로젝트라면 이메일/비밀번호/닉네임 정도만 모으는 게 안전.

주민등록번호, 고유식별정보, 민감정보(건강, 신념 등)를 다루면 별도의 관리·보호 조치가 추가로 필요하며, 위반 시 과태료 등 제재가 있습니다.

★최종 요약★ 사업자 등록 없이도 개인정보 수집 가능 (개인도 개인정보처리자) 하지만 **15조(동의) · 29조(보안) · 30조(처리방침)**는 반드시 지켜야 함 여기에 **21조(파기), 36~38조(권리보장), 23·24조(민감정보 금지)**까지 챙기면 실무에서 안전 개인정보보호법

제15조, 제29조, 제30조
제21조, 제23~~24조, 제36~~38조