figma first draft 기능에 관해 궁금한 점이 있어요.

Figma에서 AI 기능을 열어줄법도 한데 시간이 꽤나 흘렀음에도 불구하고 아직 기약이 없나 보네요 😢현재는 아래 디자인 툴을 사용해보시는것을 추천드려요.https://stitch.withgoogle.com/https://v0.dev/

앱 개발 시 해킹 방지, 보안 체크리스트 및 주의사항 문의

안녕하세요! 모바일 앱 백엔드 보안에 대한 체계적인 질문 감사합니다. 현재 계획하신 보안 대책들을 바탕으로 실무 관점에서 답변드리겠습니다. 초기 개발의 현실적 접근법 (가장 중요!)시간과 리소스의 한계를 인정하기처음 시작하는 단계라면 모든 보안 요소를 완벽하게 구축하는 것보다 개발 속도에 초점을 맞추는 것이 현실적입니다. 혼자서(팀으로 하더라도) 제로 베이스부터 모든 것을 갖추려면 많은 시간이 걸릴 수 있는데, 그렇게 완벽하게 만든 서비스가 시장에서 좋은 반응을 얻게될지, 사용자들에게 실제로 필요한지는 전혀 다른 문제입니다. MVP 우선 전략350개 이상의 앱을 개발하면서 느낀 점은, 처음 시작하는 서비스는 빠른 검증이 생명이라는 것입니다. 완벽한 보안 시스템을 구축하는 동안 시장 기회를 놓치거나, 아예 필요 없는 기능에 시간을 쏟을 수 있어요. 정작 보안과 탄탄한 서비스 구축을 위해 많은 시간을 쏟았는데 사람들이 아무도 사용해주지 않는다면 보안은 열심히 챙겼지만 아무도 사용하지 않을 서비스를 열심히 만든 결과가 되겠죠.(사용자가 있어야 보안도 의미가 있습니다.)단계적 접근1단계: 핵심 보안만 적용한 MVP (1-2주 내 완성 목표) 또는 보안은 배제하고 개발2단계: 사용자 반응 확인 후 필요한 부분만 보강3단계: 실제 사용자가 생기면 그때 본격적인 보안 강화현재 보안 대책에 대한 의견JWT 토큰의 선택적 사용모든 API에 JWT를 붙일 필요 없습니다. 공개 정보 조회, 기본 설정 등은 인증 없이 진행하고, 정말 필요한 부분(회원 정보, 결제 등)에만 적용하세요. 초기 서비스에는 개발 속도가 더 중요합니다. 질문별 답변1. 추가로 신경써야 할 보안 요소환경 변수 관리API 키, DB 접속 정보 등 민감한 정보는 코드가 아닌 환경 변수로 관리Git 저장소에 민감 정보가 포함되지 않도록 주의Spring Security 적용스프링 프레임워크를 사용하시니 Spring Security를 적극 활용역할 기반 접근 제어(RBAC) 구현클라이언트-서버 간 데이터 처리중요한 비즈니스 로직은 서버에서 처리클라이언트에서 받은 데이터는 항상 서버에서 재검증2. 실무에서 중요한 보안 포인트에러 처리와 정보 노출 방지에러 메시지에서 시스템 정보나 개인정보 노출 금지일관된 에러 응답 형식 구성로깅 전략보안 이벤트(로그인 시도, API 호출 등) 로깅개인정보는 로그에 포함하지 않되, 추적 가능한 식별자 활용인프라 보안서버와 DB 접근을 특정 IP로 제한방화벽 규칙을 통한 네트워크 접근 제어3. 자주 간과되는 보안 체크리스트개인정보 처리방침수집하는 개인정보에 대한 명확한 약관 작성사용자 동의 절차 구현입력 데이터 검증클라이언트와 서버 양쪽에서 데이터 유효성 검사파일 업로드 시 확장자, 크기, 내용 검증세션 관리JWT 토큰 만료 시간 적절히 설정로그아웃 시 토큰 무효화 처리모니터링비정상적인 API 호출 패턴 감지정기적인 보안 취약점 점검 드리고 싶은 당부의 말씀"완벽한 보안 시스템을 만들다가 앱 출시가 몇 달 늦어지느니, 기본 보안만 적용하고 빠르게 사용자 반응을 확인하는 것이 훨씬 현명합니다."서비스 시작 초기에는 특히 "일단 돌아가게 만들고, 필요하면 개선" 하는 마인드가 중요해요. 사용자도 없는데 완벽한 보안 시스템을 구축하는 것은 시간 낭비일 수 있습니다.현재 계획하신 수준이면 충분히 훌륭한 시작이라 생각합니다. 추가로..!꼭 보안이 필요한 정보인지 판단하시면서 개발하시는것도 필요할 것 같아요. 예를들어 날씨 정보를 나타내는 API를 만들었는데 해당 정보가 보안이 필요하여 jwt를 넣고 보안에 신경쓰거나 힘줄 필요는 없겠죠. 저의 경우 만든 API가 만약 100개라면, 80%는 보안을 신경쓰지 않고 만들고 운영하고 있습니다. 물론 해당 API들은 제 판단에는 굳이 보안이 필요없다고 느꼈기 때문이기도 합니다. 이렇게 8년 동안 앱들을 운영하고 있지만 보안적인 이슈로 앱들이 문제가 된적은 단 한건도 없었습니다. 다시 강조드리고 싶은것은 보안도 중요하지만 그것보다 더 중요한건 내가 만들 서비스가 시장에서 먹힐지 빠른 검증이라 생각합니다. 보안은 그 이후 챙겨도 절대 늦지 않다고 생각합니다. (물론 정말정말 민감 정보를 다루는 서비스라면 또 이야기가 다를 수 있습니다. e.g 고객 주식 관리 서비스, 은행 또는 개인 금융 서비스)

제가 강의 오픈 초반에 보고 다시 보고 있는중인데요

커리큘럼에 (사진)(사진)여기 부분들이 새로 추가되거나 내용이 조금씩 수정 되었습니다. 참고 부탁드립니다 🙂

컴퓨터 사양에 대해서

안녕하세요!제가 생각하는 개발하는데 최소 사항은RAM: 16GB 이상SSD: 256GB 이상입니다. 그리고 개인적 취향이지만, 맥이 개발하기는 편하더라구요 🙂위 정도만 맞춰지면 느릴순 있어도 할만할것 같습니다. 그리고 M1 이상만 되면 괜찮은것 같습니다. 그 이하는 발열도 심하고 성능도 그리 좋지 않습니다. 제 답변이 도움이 되셨길 바래요 🙂 개인앱 개발도 응원하겠습니다!

결제 관련하여 고민이 있어 글을 남겨봅니다

저의 경우 앱에서는 주로 애드몹(광고), 인앱 결제, 구독 결제 세 가지 방식으로 수익화를 하고 있습니다.애드몹(광고 수익)의 경우 사업자 등록 없이도 수익금을 받을 수 있어서 가장 진입장벽이 낮습니다. 광고 키를 발급받고 앱 내 적절한 위치와 타이밍에 광고를 노출하면, 사용자가 광고를 보거나 클릭할 때마다 수익이 발생합니다.인앱 결제와 구독 결제를 도입하려면 반드시 사업자 등록이 필요합니다. 다행히 iOS와 Android 모두 자체 결제 라이브러리를 제공하기 때문에 구현 자체는 그리 어렵지 않습니다. 웹 수익화와 사업자 등록웹의 경우 Lemon Squeezy, Paddle, 토스페이먼츠 같은 결제 대행 서비스를 활용할 수 있습니다. 다만 본격적인 수익화를 계획하신다면 사업자 등록을 미리 해두시는 것을 추천합니다.저의 경우 회사를 다니면서도 사업자를 등록해서 인앱 결제와 구독 결제 수익을 받아왔습니다. 사업장 주소는 집으로 등록했습니다. 그리고 추가로 사업자를 내실때 만 35세 이하시라면 중소기업 청년창업 소득세 감면에 대해서도 알아보시는것을 추천드립니다. 조건에 맞으시다면 세금적인 부분에서 많은 혜택을 받으실 수 있습니다. 제 답변이 도움이 되셨길 바래요 🙂 추가적으로 더 궁금하신 점이 있다면 언제든 질문주세요!

광고 제거 상품 고민

안녕하세요! 광고 제거 상품에 대한 니즈가 생겼다는 것 자체가 좋은 신호라고 생각해요 🙂그만큼 사용자가 자주 사용하고 싶은데 광고가 불편하다고 느끼고 있다는 뜻이거든요. (앱을 자주 사용하고 싶지 않다면 이런 피드백조차 하지 않고 그냥 떠나니까요) 가격 책정에 대해서는 딱 정해진 정답이 있는 건 아니지만, 제 경험상 광고 제거만 하는 상품의 경우 가격을 높게 책정하기엔 무리가 있을 수 있어요. 말 그대로 광고만 제거하는 것이기 때문이죠.말씀하신 것처럼 부가 기능을 더 넣고 업그레이드 느낌으로 접근한다면 조금 더 높은 가격을 책정해볼 수 있겠지만, 그게 아닌 상황에서는 보수적으로 접근하는 것을 추천드립니다.제가 추천하는 가격대:인앱 결제 (일회성): 최소 3만원 이상 (저의 경우 프리미엄 기능들을 얹혀서 5~9만원 사이를 받는 경우도 있습니다.)월 구독제: 3,900~5,900원 선다만 어떤 서비스를 운영하고 계신지 명확히 알 수 없어서 위 금액이 맞지 않을 수도 있어요.고려해야 할 요소들:서비스 운영에 고정 비용이 발생하는지 (서버, API 비용 등)서비스의 품질과 시장 경쟁력서비스의 복잡도와 차별화 요소예를 들어 운영 비용이 많이 든다면 더 높게 책정해야 하고, 품질이 뛰어나거나 경쟁력이 있다면 역시 더 높게 받아도 괜찮아요. 반대로 간단한 서비스나 경쟁력이 떨어진다면 위 금액도 비쌀 수 있고요 ㅎㅎ100% 정답은 없다고 생각합니다. 제 의견을 참고하셔서 적절한 값을 책정해보시는게 어떨까요!

동시 다량의 새 캠페인 생성에 관한 질문

안녕하세요~하나의 앱 기준이예요!말씀 주신것 처럼 여러개의 앱이라면 하루에 각 앱마다 캠페인을 만들어서 여러개가 되어도 괜찮습니다!물론 하루에 하나의 앱에 여러개의 캠페인을 만들더라도 큰 문제가 되진 않는데요, 다만 완전 동일한 내용의 예산과 광고 내용으로 여러개를 복제하는 경우는 그리 큰 효용을 얻지 못하는 경험을 많이했습니다. 그런 취지에서 아무래도 내부적으로 어뷰징과 같은 판단을 해서 그런것 같아 보인다는 의미였습니다! 여러 날에 나눠서 캠페인을 생성하시더라도 완전 동일한 예산과 광고 콘텐츠는 되도록 피하는것을 추천드립니다. 추가적으로 더 궁금하신 부분이 있으시다면 언제든 질문주세요!

EXPO로 개발해도 괜찮을까요?

안녕하세요! 제가 EXPO를 해본 경험이 없어 정확히 말씀드리긴 어렵지만,EXPO를 활용하여 Admob광고를 붙힐 수 있고, 푸시 알림을 붙힐 수 있고 Android 또는 iOS 스토어에 앱을 올릴 수 있다면 크게 상관없을것 같습니다. 사용자들이 원하는건 내가 원하거나 필요로 하는 기능이 있는가? 쓸만한가? 이지 어떤 기술을 사용해서 만들었는가는 중요하지 않기 때문입니다.

중복된 앱 캠페인 수정하기 라는 경고? 메시지가 뜹니다.

안녕하세요 🙂완전 동일한 캠페인을 만들면 중복으로 간주될 수 있어요!캠페인 복사 붙혀넣기를 통해 동일한 캠페인을 생성하거나, 콘텐츠 내용이 정확히 일치하는 경우 해당 문제가 발생될 수 있어요. 광고 콘텐츠를 한번 다른 느낌으로 세팅해보세요!

계정분산은 어떻게 하는건가요?

안녕하세요! 해당 부분에 대해 제 설명이 부족했을 수 있겠군요 (추후 추가 강의로 보강하도록 하겠습니다 🫡) 말씀하신것 처럼 전화번호만 같아도 줄줄이 사탕으로 같이 정지 될 수 있습니다. 연관된 계정 또는 동일한 명의의 계정은 하나의 사용자라고 내부적으로 판단하는것 같습니다. 따라서 계정 분산을 하기 위해서는 내 개인정보가 아닌 타인의 개인정보가 필요합니다. 저의 경우 가족이나 친척, 친구에게 부탁하여 계정 생성을 하였고. 다른 명의의 계정을 개설 했더라도 IP가 동일하거나 PC의 고유 값이 같은 환경에서 계정을 관리할 경우 마찬가지로 하나의 동일한 계정으로 엮일 수가 있기 때문에 저의 경우 AWS EC2에서 가상의 Windows 또는 리눅스 환경을 만들고 해당 계정들을 사용하고 있습니다. 앱 개수가 20개 이하이거나 위험도가 낮은 앱들 위주로 운영하신다면, 계정분산은 나중에 고려하셔도 됩니다. 우선은 안전한 앱 운영에 집중하시고, 규모가 커지면서 리스크가 증가할 때 계정분산을 검토하시는 것을 권합니다. 추가 궁금한 점이 있으시면 언제든 문의해 주세요!