작성
·
23
0
안녕하세요! 강의 잘 듣고 있습니다.
앱을 개발하시면서 필요하다면 로그인 기능이 필요할텐데 일반 사용자들이 로그인/회원가입 기능에 큰 거부감은 없었을까요?
iOS 같은 경우에는 CloudKit 등을 활용해서 별도 회원 구조에 대한 구현 없이도 사용자의 앱 데이터를 유지할 수 있었는데 서버 기반으로 구현하다보면 데이터 유지를 위해 불가피하게 회원 기능이 필요할 것 같아서 조금 고민이 되네요.
또한 회원 기능 추가 시에 개인정보나 법적인 문제들에 대한 문제는 없으셨는지도 궁금합니다.
혹시 대답이 가능하시다면 회원 기능을 제공하는 비중이 어느정도인지도 궁금합니다.
감사합니다!
답변 3
0
아하 그러면 추가적인 궁금증이 있는데요!
만약 단순한 개인 일기장 앱을 만든다고 가정할 때 서버의 용도는 서버 드리븐 UI를 그리기 위한 용도로만 사용하시는걸까요?
사실 회원 단위로 데이터 백업이 필요 없다고 볼 때 가장 최소 설계 기준에서는 서버가 필요 없을 것 같아서요.
0
안녕하세요! 통통한 연어님
저의 경우 회원 가입 & 로그인이 필요한 서비스가 필요한 서비스의 경우 보통은 커뮤니티 기능이 포함된 경우 이를 사용하고 있습니다. 앱을 실행하자마자 로그인/회원가입이 필수인 서비스는 운영해보진 않았습니다. (아무래도 허들이 매우 클것으로 판단되어)
그리고 회원 기능 구현 관련하여 제 경험을 공유드리고자 합니다.
현재 제가 개발하고 있는 앱들 중에서 실제로 회원 기능을 제공하는 비중은 약 10% 정도입니다. 대부분의 앱은 회원 가입 없이도 핵심 기능을 사용할 수 있도록 설계했습니다.
개인정보 및 법적 이슈에 대해서는 최대한 리스크를 줄이는 방향으로 접근하고 있습니다. 실제 회원 정보를 직접 받는 대신, 구글 로그인이나 카카오톡 로그인과 같은 OAuth 기반의 소셜 로그인을 활용하고 있습니다. 이는 검증된 인증 시스템을 활용함으로써 보안 리스크를 줄일 수 있는 장점이 있습니다.
서버에서 관리하는 정보도 최소화하여, OAuth 제공자로부터 받은 고유 식별자와 서비스 운영에 필수적인 닉네임 정도만 저장하고 있습니다. 이메일, 이름, 나이, 성별과 같은 추가적인 개인정보는 수집하지 않음을 원칙으로 하고 있습니다.
또한 개인정보처리방침에도 이러한 원칙을 명확히 명시하여, 어떠한 민감정보도 수집하지 않는다는 점을 강조하고 있습니다. 이를 통해 사용자들의 개인정보를 보호하면서도 필요한 서비스는 충분히 제공할 수 있었습니다.
0
안녕하세요, 인프런 AI 인턴입니다. 통통한 연어님.
로그인 기능에 대한 질문을 주셔서 감사합니다. 사용자들의 로그인/회원가입에 대한 거부감은 앱의 목적과 사용자 경험에 크게 좌우됩니다. 보통 다음과 같은 요소들을 고려하면 사용자들이 거부감을 덜 느끼고 자연스럽게 로그인 기능을 받아들이도록 할 수 있습니다.
사용자 가치 제공: 로그인을 통해 사용자 개인화된 서비스나 특별한 기능을 제공하는 경우, 사용자들은 로그인을 기꺼이 할 가능성이 높습니다. 예를 들어, 맞춤형 콘텐츠, 저장된 사용자 설정, 커뮤니티 기능 등이 포함될 수 있습니다.
대체 로그인 옵션 제공: 소셜 로그인(Google, Facebook 등) 같은 선택지를 제공하면 사용자들이 더 간편하게 로그인할 수 있습니다.
법적 및 개인정보 보호 문제: 회원 기능을 제공할 때는 항상 개인정보 보호 정책을 명확히 하고, 데이터 저장 및 처리 방식을 사용자에게 알리는 것이 중요합니다. 이는 GDPR이나 CCPA 같은 규제에 부합하게 됩니다.
사용 사례의 비중: 앱의 특성에 따라 회원 기능의 도입 비율이 달라지며, 일반적으로 다수의 앱에서는 쉽게 구현할 수 있는 소셜 로그인 등을 통합하여 사용하는 경우가 많습니다.
CloudKit 등을 활용하면 iOS 환경에서 사용자가 쉽게 데이터를 연동할 수 있지만, 안드로이드 등 다른 플랫폼과의 연동을 고려해야 하는 경우라면 서버 기반의 회원 시스템 구현이 필요할 수 있습니다.
비슷한 주제를 다룬 기존 답변으로 도움이 될 만한 것을 추천드리니 확인해 보세요:
- 로그인 기능 및 사용자 데이터 관리
저는 질문자님의 이해를 돕고자 지식공유자님의 기존 답변을 참고하여 유사한 답변 링크를 추천해드리고 있습니다.
현재 베타 기능으로 답변이 만족스럽지 않을 수 있는 점 양해 부탁드립니다. 🙏
추가적으로 궁금한 점이 있으시면, 이어서 질문해 주세요. 곧 지식공유자께서 답변해 주실 것입니다.
네 맞습니다!
정말 간단한 기능을 가진 앱이거나, UI 라면 서버 드리븐 UI의 경우가 필요없는 경우도 있죠 🙂
모든 앱의 내용을 서버로 내려줄 필요는 없으니까요.
(전 순수 네이티브만으로 구현된 앱들도 꽤나 많습니다)
전 보통의 경우 재활용이 가능할 것 같다라고 판단되는 경우는 서버에서 내려줘서 그리는 형태로 모듈화를 주로 하는편이고 1회성이거나, 자주 사용되지 않을것 같은 경우는 순수 클라이언트로만 해결하는 경우도 많습니다
그리고 제가 강의에서 설명드린 서버 드리븐 UI의 경우는 앱을 최대한 빠르게 만들기 위함이지
처음부터 강의에 내용처럼 설계하여 구조를잡은 뒤 앱을 개발하는것은 비효율적일 수 있습니다.
앱을 만드시면서 그때그때, "아 이런 기능 자주 사용되네? 그럼 이걸 서버로 구조를 옮겨가야겠다." 와 같이 점진적으로 발전시켜 나가는것이 좋아요!
당장 처음부터 모든걸 설계하긴 불가능에 가깝고 설령 미리 설계하고 준비한다고 하더라도 안쓰일 가능성도 있기 때문이죠