로그인 기능 관련 질문

안녕하세요! 통통한 연어님 저의 경우 회원 가입 & 로그인이 필요한 서비스가 필요한 서비스의 경우 보통은 커뮤니티 기능이 포함된 경우 이를 사용하고 있습니다. 앱을 실행하자마자 로그인/회원가입이 필수인 서비스는 운영해보진 않았습니다. (아무래도 허들이 매우 클것으로 판단되어) 그리고 회원 기능 구현 관련하여 제 경험을 공유드리고자 합니다.현재 제가 개발하고 있는 앱들 중에서 실제로 회원 기능을 제공하는 비중은 약 10% 정도입니다. 대부분의 앱은 회원 가입 없이도 핵심 기능을 사용할 수 있도록 설계했습니다. 개인정보 및 법적 이슈에 대해서는 최대한 리스크를 줄이는 방향으로 접근하고 있습니다. 실제 회원 정보를 직접 받는 대신, 구글 로그인이나 카카오톡 로그인과 같은 OAuth 기반의 소셜 로그인을 활용하고 있습니다. 이는 검증된 인증 시스템을 활용함으로써 보안 리스크를 줄일 수 있는 장점이 있습니다. 서버에서 관리하는 정보도 최소화하여, OAuth 제공자로부터 받은 고유 식별자와 서비스 운영에 필수적인 닉네임 정도만 저장하고 있습니다. 이메일, 이름, 나이, 성별과 같은 추가적인 개인정보는 수집하지 않음을 원칙으로 하고 있습니다. 또한 개인정보처리방침에도 이러한 원칙을 명확히 명시하여, 어떠한 민감정보도 수집하지 않는다는 점을 강조하고 있습니다. 이를 통해 사용자들의 개인정보를 보호하면서도 필요한 서비스는 충분히 제공할 수 있었습니다.

사업자 등록을 언제 해야할까요?

안녕하세요!세금 관련 문제로 신경이 쓰이실텐데요, 저 또한 직장다니면서 사업자를 내도 될까 부터 많은 고민을 했었답니다. 사업자 등록은 소득이 조금이라도 발생하고 있다면 왠만해선 하는게 좋습니다. 저 또한 회사 다니면서 사업자에 대한 개념이 전혀 없을때 별도로 세금 신고를 못했다가 국세청으로 부터 연락을 받은적이 있습니다. (그 때 몰라서 못낸 세금이 과징금이 포함되어 더 많은 세액을 납부해야됐던 기억이...) 그리고 앱을 여러개 만드는것과 사업자는 별개의 문제인것 같습니다. 사업자가 없더라도 앱을 여러개 만드는것은 가능하니까요!세금 관련 감면 혜택을 받으실 수 있으면 이걸 무조건 받으면 좋은데, 사업자를 내시기 전, https://www.tosspayments.com/blog/articles/tax-3 이거 관련해서 한번 살펴보시고 관련해서 해당된다면 무조건 저걸 받는게 좋습니다.세금 처리는 회사 다닐 때는 연말정산을 통해 급여소득을 정리했지만, 사업소득은 따로 종합소득세 신고를 해야 합니다. 저는 세무사를 끼고 일정 수수료를 지불하고 처리하였습니다.(현재도 마찬가지)

서버 대용 프레임워크에 대하여

또 한가지, 서버 개발을 학습해서 도입해야되는 단계라면 러닝커브와 거기에 들어가는 시간또한 필요할테니 이것또한 중요한 선택 요소가 될 수 있겠죠. 장기적으로는 서버를 직접 운영하는게 좋다고 생각하고,단기적, 서비스가 그리 크지 않을땐 Firebase나 Supabase도 충분하다 생각합니다!

서버 대용 프레임워크에 대하여

안녕하세요!Firebase, Supabase와 같은 BaaS(Backend as a Service) 솔루션들은 백엔드 개발을 간소화할 수 있는 훌륭한 도구입니다. 특히 초기 개발 단계나 프로토타입 제작시 빠른 개발이 가능하다는 큰 장점이 있죠.하지만 저는 현재 서버를 직접 구축하여 운영하고 있습니다. Spring Boot + Kotlin 기반으로 서버를 개발하고 AWS 환경(EC2 + RDS)에 배포하여 사용 중입니다. 이러한 선택을 하게 된 주된 이유들은 다음과 같습니다.비용 효율성Firebase/Supabase는 사용량이 증가할수록 비용이 선형적으로 증가하는 경향이 있습니다반면 직접 구축한 서버는 t2.micro/t3.micro 정도의 낮은 사양으로도 수천 명의 일간 활성 사용자를 처리할 수 있으며, 비용이 월 $20-30 정도로 예측 가능하고 안정적입니다데이터 처리의 자유도복잡한 비즈니스 로직 구현이 자유로움외부 API 연동, 웹 크롤링, 데이터 가공 등의 작업을 제약 없이 수행 가능실행 시간 제한 없이 장시간 실행이 필요한 작업 처리 가능시스템 최적화캐싱 전략을 상황에 맞게 세밀하게 구현 가능스케줄러를 활용한 배치 작업의 자유로운 구현데이터베이스 쿼리 최적화와 인덱싱 전략 수립 가능저의 경우, 이전에 Firebase를 사용했던 경험이 있습니다. 초기에는 빠른 개발과 간편한 관리가 매력적이었지만, 서비스가 성장하면서 몇 가지 한계점을 경험했습니다.복잡한 데이터 처리 시 제약사항 발생사용자 증가에 따른 급격한 비용 상승커스텀 기능 구현의 제한Cloud Functions의 실행 시간 제한 (9분)이러한 경험을 바탕으로 현재는 서버를 직접 구축하여 운영하고 있으며, 이를 통해 더 나은 서비스 품질과 비용 효율성을 달성할 수 있었습니다.다만, 이는 절대적인 정답이 아닙니다. Firebase나 Supabase도 다음과 같은 상황에서는 훌륭한 선택이 될 수 있습니다.MVP 개발이나 프로토타입 검증이 필요한 경우백엔드 개발 리소스가 제한적인 경우실시간 데이터 동기화가 중요한 경우기본적인 CRUD 작업이 주를 이루는 경우결론적으로, 서비스의 특성, 개인의 개발적 역량, 달성하고자 하는 개발 일정, 그리고 비즈니스 요구사항을 종합적으로 고려하여 적절한 선택을 하는 것이 중요할 것 같습니다.

강의 ppt 제공받을 수 있을까요? 필요합니다.

안녕하세요 gogo님!가장 마지막 강의인 마무으리 영상에 수업자료로 첨부해두었습니다.비밀번호는 강의노트 참고 부탁드려요 😀