개발자 인사이트19 AI 부업 광고 보다가 이상한 걸 발견했습니다 AI 부업 광고 보다가 이상한 걸 발견했습니다요즘 SNS에서 "AI로 월 수백 버는 법" 식의 광고를 한 번쯤 보셨을 겁니다. 직접 몇 개를 들여다보니까, 서로 다른 광고인데도 이상하게 같은 장치들이 반복적으로 등장했습니다. 이 글은 특정 업체를 지목하지 않고, 이런 유형의 광고가 공통적으로 어떻게 설계되는지만 객관적으로 짚어봅니다.자주 등장하는 장치들몇 개의 AI 부업 광고를 연속으로 보면서 눈에 띈 건 이 세 가지였습니다.인위적 긴급성: "지금 000명이 보는 중", "잔여 00명" 같은 문구나 카운트다운 타이머. 새로고침하면 다시 리셋되는 경우가 흔해서, 실제 재고나 실시간 인원이 아니라 전환율을 위한 심리적 장치인 경우가 많습니다.가격 앵커링: 정가를 부풀려놓고 큰폭 할인된 것처럼 보이게 하는 방.. 2026. 8. 16. Claude·Gemini·ChatGPT 무료 플랜만으로 AI 콘텐츠 부업 시작하기 AI 콘텐츠 부업, 돈 한 푼도 안 들이고 시작할 수 있을까AI로 콘텐츠 부업을 시작하려면 Claude Pro나 ChatGPT Plus 같은 구독이 먼저라고 생각하는 분들이 많습니다. 직접 몇 달 동안 메이저 AI 도구들의 무료 플랜만으로 블로그 초안을 실제로 완성해본 결과, 구독료 없이도 시작하는 건 분명 가능했습니다. 다만 그 과정에서 분명히 번거로운 지점들도 함께 확인했고, 이 글은 그 과정을 그대로 공유합니다.왜 구독료부터 생각하게 되는가저도 처음에는 Claude Pro와 Gemini를 동시에 결제하고 시작해야 하는 줄 알았습니다. 블로그·쇼츠 자동화, 진짜 필수 비용은 Claude Pro 구독료 하나였습니다 하지만 그 이전 단계, 즉 "이게 나한테 맞는가"를 판단하는 단계에서는 구독료를 내기 전.. 2026. 8. 15. 트렁크 기반 개발(TBD), 원칙과 실무 적용 방법 정리 도입트렁크 기반 개발(TBD, Trunk-Based Development)은 모든 개발자가 단일 트렁크(메인 브랜치)에 짧은 주기로 계속 병합해 나가는 방식입니다. 기능별로 브랜치를 오래 띄워두는 대신, 작은 단위로 자주 통합하면서 미완성된 기능은 feature flag로 가려두는 게 핵심입니다. 이 글에서는 TBD를 GitFlow와 비교하기보다(그 비교는 별도 글에서 다뤘습니다), TBD 자체의 원칙과 실무 적용 방법을 자세히 다룹니다. TBD로 바꾸기 위해 확인해야할 3가지는 이전 블로그글을 확인해주세요. Git 브랜치를 TBD로 바꾸기 전에 확인해야 할 3가지도입Git 브랜치 전략을 TBD(Trunk-Based Development)로 바꿀까 GitFlow를 유지할까 고민하는 팀이라면, 결론부터 말.. 2026. 7. 30. Git 브랜치를 TBD로 바꾸기 전에 확인해야 할 3가지 도입Git 브랜치 전략을 TBD(Trunk-Based Development)로 바꿀까 GitFlow를 유지할까 고민하는 팀이라면, 결론부터 말씀드리면 "하루 여러 번 배포하고 싶고 CI를 믿을 수 있다면 TBD, 여러 버전을 동시에 유지보수해야 한다면 GitFlow"입니다. 이번 글에서는 TBD가 GitFlow와 구체적으로 무엇이 다른지, 그리고 도입하려면 무엇을 먼저 갖춰야 하는지를 정리해보겠습니다.TBD란 무엇인가Trunk-Based Development는 모든 개발자가 짧은 수명의 브랜치만 파고, 하루~이틀 안에 main(trunk)에 병합한 뒤 바로 삭제하는 방식입니다. GitFlow처럼 develop/release/hotfix 등 여러 종류의 장기 브랜치를 두지 않고, main은 언제든 배포 가.. 2026. 7. 29. AI 초안 자동화, 사람이 끝까지 놓지 말아야 할 검수 원칙 3가지 도입이 블로그 글은 이제 초안 단계부터 AI가 씁니다. 주제를 잡고, 문단을 나누고, 소제목까지 달아서 나오면 제가 하는 일은 그 아래에서 글을 고치는 것보다는, 틀린 부분을 찾아내는 것에 가깝습니다. 이 글을 쓰는 지금도 AI가 초안을 쓰고 제가 검수하는 중이고요. 몇 달 이 구조로 블로그와 쇼츠를 운영하면서, 사람이 끝까지 놓지 말아야 할 지점이 생각보다 명확하다는 걸 알게 됐습니다.처음에 가졌던 오해처음에는 "AI가 초안을 쓰고 사람이 오타를 잡는다" 정도로 생각했습니다. 오탈자를 찾고, 문장이 어색한 곳을 고치고, 제목이 본문과 맞는지 확인하는 정도면 충분할 줄 알았습니다. 실제로 파이프라인을 돌려보면 이 수준의 검수로는 안 될 때가 생깁니다. AI가 맞춤법은 잘 맞춥니다. 문장도 매끄럽게 씁니다.. 2026. 7. 27. 주니어 때는 몰랐던, 코드 리뷰에서 진짜 중요한 것 도입주니어 때는 코드 리뷰라고 하면 일단 스타일 가이드를 지켰는지, 변수명이 컨벤션에 맞는지, 들여쓰기나 네이밍처럼 눈에 바로 보이는 부분부터 확인했습니다. 리뷰 코멘트도 대부분 그런 지적이었고, 그게 꼼꼼한 리뷰라고 생각했습니다. 12년 정도 개발을 하고 나서 돌아보면, 그때는 정작 중요한 걸 놓치고 있었다는 생각이 듭니다.그때는 왜 스타일부터 봤을까돌이켜보면 이유는 단순합니다. 스타일 문제는 눈에 바로 보이고, 지적하기도 쉽고, 맞다 틀리다가 명확합니다. 반면 이 코드가 실제로 필요한 요구사항을 충족하는지, 나중에 유지보수할 사람이 이 구조를 보고 의도를 파악할 수 있을지 같은 질문은 훨씬 판단하기 어렵습니다. 판단하기 쉬운 것부터 손이 가는 건 자연스러운 일이었던 것 같습니다.지금 리뷰할 때 가장 .. 2026. 7. 25. 이전 1 2 3 4 다음 SMALL
