블로그에 글이 스무 편을 넘기니, 처음 들어온 분이 어디서부터 읽어야 할지 헷갈리겠다는 생각이 들었습니다. 그래서 이 페이지를 「1인 창업 AI 도구」 안내판으로 다시 만들었습니다. 최신순 목록이 아니라, 지금 어떤 고민을 하고 있는지에 따라 먼저 읽을 글을 고르실 수 있게 묶었습니다.

DP42에 쓰는 글은 대부분 혼자 제품을 만들고 운영하면서 실제로 막혔던 지점에서 출발합니다. 도구 소개도 “이게 좋다”로 끝내지 않고, 어떤 일을 맡겼더니 어디서 깨졌는지, 다시 한다면 어떤 순서로 할지까지 적으려고 합니다. 가격이나 기능처럼 자주 바뀌는 정보는 글마다 확인한 시점을 적어 두었으니, 결제나 도입 직전에는 공식 페이지를 한 번 더 확인해 주세요.

지금 상황별로 먼저 읽을 글

모든 글을 순서대로 읽을 필요는 없습니다. 아래 다섯 가지 중 지금 내 상황과 가장 가까운 줄 하나만 골라서 시작하시면 됩니다.

1. AI 코딩 도구: 무엇을 고르고 어디까지 맡길까

AI 코딩 도구는 비교 글이 넘쳐나지만, 혼자 제품을 만드는 입장에서 정말 궁금한 건 “내 프로젝트에서 어디까지 맡겨도 되나”입니다. 이 묶음의 글들은 기능 목록보다 작업 흐름과 권한, 그리고 맡기지 말아야 할 일을 중심으로 정리했습니다.

이 분야 글만 모아 보고 싶다면 AI 코딩 도구 카테고리로 가시면 됩니다.

2. 검증·출시: 만들기 전에, 그리고 내보내기 직전에

혼자 일하면 시간이 가장 비싼 자원입니다. 그래서 저는 “무엇을 만들까”보다 “무엇을 안 만들까”를 먼저 정하는 쪽이 결국 빠르다고 생각합니다. 이 묶음은 아이디어 단계와 출시 직전 단계, 두 시점에 필요한 글입니다.

  • B2B SaaS 검증, 코딩 전에 해야 할 일: AI를 고객 인터뷰 준비와 정리에 쓰는 세 가지 방법, 그리고 90일 동안 어떤 증거를 모아야 하는지 순서대로 적었습니다.
  • 회사 다니면서 창업 테스트하는 법: 주 7시간으로 돌리는 90일 루틴입니다. 고객에게 처음 말을 거는 문장, 기능 하나짜리 MVP, 돈을 낼 의향을 확인하는 기준, 회사 겸업 조항에서 확인할 부분까지 다룹니다.
  • Micro SaaS 아이디어 8선 (2026 하반기): 아이디어가 없어서 막혀 있다면 이 글의 표를 보고 난이도와 시장, 남들이 쉽게 따라 하기 어려운 지점을 비교해 보세요.
  • Supabase RLS 설정 방법: Lovable, Bolt, Cursor로 만든 Supabase 앱에서 다른 사람의 데이터가 보이는 사고를 막는 방법입니다. 정책 SQL 예제와 pgTAP으로 실제로 막히는지 시험하는 방법까지 넣었습니다.
  • Railway 요금과 사용법 2026: 백엔드를 처음 배포할 때 많이 고르는 Railway의 Free·Hobby·Pro 차이, 사용량 요금이 붙는 방식, 청구서가 갑자기 커지지 않게 걸어 둘 비용 한도 설정을 정리했습니다.
  • HTTP Toolkit 사용법: 배포 후에만 외부 API 호출이 실패할 때처럼 원인이 안 보이는 순간, 브라우저·터미널·안드로이드 앱의 요청을 가로채 직접 확인하는 방법입니다. 무료로 어디까지 되는지도 같이 적었습니다.
  • 포트폴리오에 ‘AI로 만듦’만 쓰면 탈락하는 이유: AI로 만든 프로젝트를 포트폴리오에 올릴 때 판단과 검증을 어떻게 보여 줄지, 바로 쓰는 프로젝트 설명 틀과 제출 전 점검표까지 정리했습니다.

전체 목록은 검증·출시 카테고리에 있습니다.

3. 자동화·운영: 혼자서도 서비스가 굴러가게

제품을 내놓은 뒤부터는 다른 종류의 일이 쌓입니다. 서버, 보안, 반복 업무, 브라우저에서 하는 잡무 같은 것들입니다. 이 묶음은 그 일들을 AI 에이전트와 자동화로 덜어 내되, 사고가 나지 않게 선을 긋는 방법을 다룹니다.

운영 관련 글은 자동화·운영 카테고리에 모여 있습니다.

4. 수익화·성장: 만든 걸 알리는 일

작은 제품은 광고비보다 검색과 콘텐츠로 사람을 모으는 경우가 많습니다. 다만 요즘은 검색 결과 맨 위에 AI 요약이 먼저 뜨기 때문에, 예전처럼 키워드만 맞춘 글로는 잘 읽히지 않습니다. 이 블로그를 운영하면서 직접 바꿔 본 방식을 정리했습니다.

  • AI 검색 시대의 블로그 전략: 글감을 고르는 법, 답을 먼저 쓰는 구조, 성과를 확인하는 측정 루프까지 1인 창업자 블로그 기준으로 적었습니다.
  • GEO 최적화 3대 전략: AI 검색이 답을 만들 때 내 글을 출처로 가져가게 하려면 무엇을 준비해야 하는지, 격주로 점검하는 방법과 함께 정리했습니다.
  • 유튜브 쇼츠 vs 인스타 릴스 vs 틱톡 2026 비교: 세 플랫폼의 영상 길이와 수익화 조건, 2027년 2월부터 바뀌는 YPP 기준을 공식 도움말로 확인하고, 1인 창업자가 숏폼을 제품 홍보에 쓰는 방법을 적었습니다.
  • 한국에서 Stripe 대안 찾기: 토스페이먼츠, Paddle, Polar, Lemon Squeezy를 수수료와 정산, 세금 처리 기준으로 나란히 놓고, 해외 결제를 처음 붙이는 1인 창업자가 어디서 시작하면 좋을지 정리했습니다.

이 주제는 수익화·성장 카테고리에서 계속 이어서 다룰 예정입니다.

5. 케이스 스터디: 직접 겪은 실패 기록

도구 이야기보다 오래 남는 건 결국 실제로 무엇이 잘못됐는지에 대한 기록이라고 생각합니다.

  • DriveRadio·MEMVIA 출시 직전 사후분석: 테스트는 다 통과했는데 출시할 수 없었던 다섯 가지 이유입니다. 성공 응답인데 내용이 비어 있던 API, 감상적으로 흐른 AI 멘트, 실기기에서만 드러난 문제, 사진 권한 없이 입력을 받는 구조, App Store Connect 업로드에서 막힌 부분을 적었습니다.
  • 토스 기술블로그(toss.tech) 읽는 법: 큰 팀의 기록에서도 혼자 일할 때 가져올 게 많습니다. AI 팀 규칙, 패키지 관리, 결제 레거시 시리즈처럼 1인 개발자가 꼭 읽어 볼 글과 배울 점을 골랐습니다.

사례 글은 케이스 스터디 카테고리에 쌓아 가고 있습니다.

처음 한 달, 이 순서로 읽어 보세요

아직 아무것도 시작하지 않은 상태라면, 저라면 이렇게 읽겠습니다. 한 주에 두세 편이면 충분합니다.

  1. 첫째 주: 검증 글 두 편(B2B SaaS 검증, 회사 다니면서 창업 테스트)으로 만들 것과 안 만들 것을 정합니다.
  2. 둘째 주: AI 공동창업자 스택과 Lovable vs Bolt 비교를 읽고, 도구를 한두 개만 골라 작은 버전을 만들어 봅니다. 약어 사전을 옆에 두면 프롬프트가 훨씬 짧아집니다.
  3. 셋째 주: 출시 전에 Supabase RLS 글과 프로덕션 가이드를 체크리스트처럼 쓰면서 구멍을 막습니다.
  4. 넷째 주: 블로그 전략과 GEO 글을 보고, 만든 것을 알릴 글 한 편을 직접 써 봅니다.

새 글이 나오면 이 페이지도 함께 고칩니다. 읽다가 틀린 정보나 바뀐 가격을 발견하시면 문의 페이지로 알려 주세요. 확인하고 본문에 반영하겠습니다.

DP42의 편집 기준

글은 공개 자료와 공식 문서를 먼저 확인하고 쓰며, 바뀔 수 있는 기능·가격·정책에는 원문 링크를 붙입니다. 직접 해 본 경험은 본문에서 따로 구분합니다. 운영자 소개는 소개 페이지에 있습니다.

전체 글 보기 · 소개 보기 · 문의하기