dalgom.bami

@thingthingthin 음 텔레그램쪽과의 연결 세팅이 뭔가 문제가 있나보네요. 디스코드와는 상관없을것같습니다!

@dalgom_bami 저는 텔레그램만 연동했습니다!

오늘 업데이트된 클로드코드 채널 세팅완료👍

@thingthingthin 텔레그램이나 디코 중에 하나골라서 쓰는 식인것같던데 둘다쓰시려는걸까요?

@dalgom_bami 저는 코드창에서 텔레그램으로 메세지는 오는데 텔레그램에서 코드창으로 안가네요. 디스코드 연동 문제일까요?

@sangbeomkim80 뭔가비슷하네요 ㅋㅋ

@dalgom_bami 클로드 코드 아이콘이 왠지... 다마고치를 연상 시키네요..😂

@k1mjunyoung 네 똑같습니다. mcp기반이라 제약이 오히려 조금 더 있긴합니다 터미널에서쓸때보다

@dalgom_bami 디스패치는 클로드 앱에서, 채널은 서드파티 앱에서 하는거 외에 기능적으로는 동일한걸까요??

@happyhana99 어제 출시된 claude code channels 기능입니다!

@dalgom_bami 뭐죠! 어떻게 한거죠!

@van_winkle__ 맞습니다!

@dalgom_bami 클로드코드 - 디스코드 연동하신거죵~?

@dwkim01 넵 그게가능해졌어요 ㅎㅎ vscode내 터미널에서 실행하시면 될 것 같습니다

@dalgom_bami 오..디스코드-클로드코드(vscode) 연동해서 원격으로도 조정가능한가요??

@romantic_coding 한번 시도해봐야겠군요 ㅎㅎ 놀고있는 gpt 유료계정을 굴리기 위해서라도

@dalgom_bami 저는 추천합니다! 오픈소스 링크주면서 연동하라하면 혼자 셋팅해줘서 금방되실거에요 ㅎㅎ 그리고 저는 3사를 모두 구독하고 있는데, 야무지게 돌리기에도 좋은 것 같아요.

ohmyclaudecode(OMC)가 생각보다 리스크 관리를 잘해주네요 모르는 분야의 취약점이나 개선점을 꽤 날카롭게 짚어줍니다. 예전에는 인간의 직감으로 일일이 찾아야 했던 것들인데, 에이전트가 알아서 대신해주니 확실히 편하긴 합니다ㅎㅎㅎㅎ 제 일하는 방식이 요구사항을 계속 늘려놓고 계획서를 꼼꼼히 쓴 뒤에 시작하는 편인데, OMC의 deep interview 기능을 쓰니 결과가 꽤 만족스럽게 나오기도 하구요. 회사 다닐 때 몸에 익은 '리스크 최소화' 프로세스가 에이전트 환경에 맞게 잘 이식된 느낌이랄까요.. 다만 수정 ETA를 몇 시간씩 잡는 건 랄프 때문인지 몰라도 토큰 소모량이 좀 무섭긴 합니다. 그래도 직접 머리 싸매지 않아도 빈틈을 다 메워주니 세상 좋아졌다는 생각이 드네요. 얘보다 내가 더 잘 찾아낼 수 있을까 싶기도 하고요ㅎㅎㅎㅎ;

@DeepDive_KR 감사합니다! ㅎㅎ

@dalgom_bami 와 한줄 한줄 꿀팁이네요 지금 계획만 잡아놓고 그 단계까지는 가지도 못하고 있는데 😅북마크 했슴니다!

Supabase 관련 개발 팁 모음 1. MAU 5만까지는 Free로 쓸 수 있다. 그래서 mvp 및 PMF찾기전까진 db에 대한 비용을 아낄 수 있어서 최고다 2. 단, Storage는 1기가까지 무료다. 보통 이거 초과해서 유료 결제하게 되는 포인트 중 하나이고, 굳이 이거 쓸 필요가 없고 Cloudflare r2쓰면 월 10기가 무료 3. 구글로그인 연동 쉽다. 단 연동 시 {sdgjsagnsjg}.supabase. co 같은 도메인이 구글로그인 화면에 나온다. 이상한 사이트 같아보인다. 근데 이거 해결책 찾는다고 $10짜리 커스텀 도메인 내야되는줄 알고 지불하는 사람들 있는데, 그럴 필요 없다. GCP oauth에서 Branding에서 verification만 하라는거 잘 하면 저 이상한 url 대신 아이콘 + 서비스 이름으로 노출 가능 4. custom domain(+$10/월)은 주소창에 순간적으로 뜨는 리다이렉트 주소도 거슬리면 하는거 5. Free는 자동백업 안된다. 본인이 알아서 dump뜨거나 해야함. 보통 이거때문에 pro플랜 쓰기 시작함. pro는 하루 한 번 최근 7일간의 디비 데이터를 저장해두고 복구할 수 있게해준다. 서버 지식이 아직 없는 바이브코더면 이거라도 해두자.. 개발자들이 날아간 db 데이터 살려줄 수 있다. 6. 추후 다른 db로 마이그레이션 할 계획이 있으면 RLS로 클라이언트 <-> supabase 직접 연결 하는 로직 쓰면 나중에 엄청나게 고통받는다. 그냥 wrapping하는 서버 띄우고 service role로 권한체크 전통적인 백엔드 방식으로 하면 추후 스무스하게 마이그레이션 가능 7. local supabase 사용해서 개발 db로 쓰고, 디비 스키마 변경은 무조건 migration 파일 생성해서 로컬에서 반영 테스트 -> 운영(또는 스테이징)에 supabase client로 migration 파일 반영. supabase web dashboard에서 그냥 테이블 구조 막 바꾸면.. 8. 트랜잭션이 필요한 경우, RPC 써야하는데 파일이 아닌 db에 로직이 저장되다보니 유지보수하기 힘듦. 트랜잭션이 특히 중요한 어플리케이션이면 전통적인 방식의 Server <-> DB client 구조가 권장됨. 9. 무료플랜은 1주일간 트래픽 없으면 일시정지됨. 꾸준히 직접 들어가거나 cron같은걸로 호출해서 해결(cron 자동 정기 호출은 정책 위반이긴 함) 10. supabase 보안관련해서도 많이 나오지만 제대로 알고 쓰면 보안 이슈 거의 없음. 기가막힌 백엔드 스택을 가져와도 쓰는 사람이 제대로 모르면 보안 허점이 있음. 단, supabase는 권장사용방식으로 쓰다보면 보안적으로 실수하기 좋은 구조임 11. 놀랍게도 queue, cron도 supabase plugin쓰면 바로 쓸 수 있지만 유지보수가 지옥임 비추. 12. 로컬에 세팅해두고 쓰는 supabase db test가 진짜 사기임 한줄평) 검증되기 전 시작단계의 제품에는 추천. 이미 성숙한 서비스나 큰 기업프로젝트에선 비추 추후 supabase 도입계획이 있다면 저장해두고 나중에 보세요!

@willy_167 AI에 질문하면서 배워나가는게 정말 좋은 습관이라고 생각합니다!

@dalgom_bami 앗!! 감사합니다. 제 혼란의 첫번째는 저의 지식/역량 부족이 큰탓이라... 게시물을 보고 판단하고 나에게 적용하는 점을 찾는데에 어리숙함이 많습니다..ㅠ 초기단계, 성숙기에 대한 정의가 어떻게 되는지 궁금했는데, 많은 부분이 해소되었습니다ㅎ 감사합니다!

저는 월 50만트래픽까지도 supabase로 굴려봤습니다. 쓰지 말라는 의견은 아니고 제품 초기 단계부터 성숙기까지는 굉장히 좋은 제품입니다. 단 추후 트래픽이 엄청 커지면 migration을 해야하는 시점이 올 수도 있는데 (안올수도있음) 그 때 고생하지 않으려면 알아야하는 팁 들? 정도를 정리해뒀다고 보시면 됩니다 ㅎㅎ

터미널에 물어보니, 이런 답변을 받았습니다. 비개발자라 지식이 부족하지만, 서비스를 준비하고 있습니다. 올려주신 게시물 덕분에, 좀더 깊게 알아보게 되었는데, 해당 이미지 내용에 대해서도 의견 부탁드려봅니다! (저희회사 네트워크상.. 고객사는 50곳 이상정도는 사실 그리 어렵지 않게 모집가능합니다)

@Pakhus_xyz 고민하시는 부분에 도움이 되었으면 좋겠네요! 읽어주셔서 감사합니다

@dalgom_bami 일단 한번 쓱 읽었고 퇴근하면서 지하철에서 곱씹어보겠습니다..! 제가 지금 가장 고민하는 문제인데 미리 감사드립니자🙏🏻

@Sys_Dev_Crypto 주변지인도 언젠가 내 제품을 써줄수도있는 잠재고객이라면 얻을 수 있는 인사이트가 많은 것 같습니다 ㅎㅎ

@dalgom_bami 잘 읽었습니다. 저는 제 주위의 의견을 참고 많이 합니다. 그 분들도 저에게는 잠재적인 고객이라고 생각했을 때 생각보다 좋은 피드백이 오거든요. "내 제품은 정확히 누구의, 어떤 구체적인 문제를 해결하고 있는가?" 이 구문이 가장 중요했던 것으로 기억합니다.

추후 시장을 점점 넓히더라도 초기 진입은 니치타겟부터 시작하는게 초기유저를 만나기에 압도적으로 유리한 것 같습니다. 제품이 가야할 방향은 초기유저들이 답지를 다 줄것이기때문에 초반에 이들을 설득할 수 있는 제품을 만드는게 중요하다고 생각해요 ㅎㅎ 특히 작은팀이나 1인이면 더욱더요. 읽어주셔서 감사합니다!

@dalgom_bami 마케팅 스킬 이전에 전장 선택의 문제라는 말에 공감합니다. 저도 지금 마케팅에 혈안이 되어 있는데, 결국 제품의 본질로 돌아가서 진짜 니치한 기능 하나에 집중하고 있는지 자문하게 되네요ㅋㅋ 잘 읽었습니다ㅎㅎ

@neuradex_ysk 공감합니다. 과거에는 sw서비스 하나를 만들고 운영하는게 자본도 많이들고 진입장벽이 컸기에 큰 타겟 시장이아니면 ROI가 안나오는 경우가 많았지만 이제는 전보다 더 작은 시장도 개발비가 많이 저렴해졌기때문에 충분히 ROI가 나오는 경우가 많아진 것 같습니다!

공감합니다. 결론은 같지만 저는 좀 다른 방식으로 생각했는데요. 인공지능의 발전으로 개발행위의 가치가 내려갔고, 넓은 타겟을 노린 제품이 수도없이 쏟아져나온다는 점입니다. 옛날에는 개발의 가치가 너무 커서 비용을 뽑으려고 만인을 위한거 만들었다지만 지금은 그 전제도 무너졌죠. 심지어는 과제를 가진 사람들 스스로도 개발하고요. 애매한거 다 비슷해보이는거 쓰느니 좀 부족해도 본인에게 맞는걸 선택하겠죠? 가치분배의 중심이 점점 더 과제정의쪽으로 올라가고 있다고 생각합니다. 저는 일본에 있는데 일본에서 얼마전에 딱 예를 들어주신 ADHD 일정관리앱 만든 ADHD인 여성 1인 개발자가 한달만에 200만엔 매출을 올렸다고 화제가 됬었는데 그게 생각나네요. 좋은 글 잘읽었습니다! 마케팅쪽 관점으로는 생각해보지 못했었거든요. 감사합니다

주변에 1인개발자에 도전하는 분들의 이야기를 듣고 조언을 해줄 기회가 많이 있었습니다. 대부분 개발에는 문제가 없지만 마케팅에 다들 벽을 느끼고 있었는데요. 이 분들에게 항상 해드렸던 1인개발의 마케팅 관련 조언을 글로 정리해보았습니다! x.com/dalgom_bami/st…