이 글은 「한 사람 경제 시즌 2: 2026 솔로 사업가의 좌표와 실전」 9/10화입니다.

시즌 1 4화에서 ‘부업 세금, 얼마부터 신고해야 하나’라는 질문을 잠깐 던졌던 걸 기억하시나요? 그때는 지면이 부족해 한 문단으로 넘겼습니다. 오늘 그 빚을 갚습니다. 세무뿐 아니라, 바이브 코딩(Vibe Coding)이 만든 보안 구멍과 직장인 부업의 법무 지뢰까지 — 88%가 실패하는 진짜 원인을 낱낱이 펼칩니다.

8화에서 우리는 30일 검증 플레이북을 함께 걸었습니다. 랜딩페이지를 올리고, 20명의 가입자를 모으고, 10~20명과 심층 인터뷰를 마쳤습니다. Go 사인이 떨어졌습니다. 그런데 여기서 불편한 진실 하나. 검증을 통과한 뒤에도 대부분은 1년을 넘기지 못합니다. 실패율 88%라는 숫자는 ‘아이디어가 나빠서’가 아니라 ‘제품 밖의 지뢰를 밟아서’ 만들어집니다.

오늘의 핵심 용어를 먼저 짚겠습니다. 바이브 코딩이란 AI 코딩 도구(Cursor, Replit Agent, GitHub Copilot 등)에 자연어로 지시해 소프트웨어를 만드는 방식입니다. 1화에서 다뤘듯 프로그래밍 경험 없이도 MVP를 만들 수 있지만, AI가 생성한 코드에는 개발자의 보안 감각이 빠져 있습니다. 그리고 솔로프리너(Solopreneur)는 직원 없이 혼자 사업을 운영하는 1인 사업가를 뜻합니다.

30일 검증을 통과해도 88%가 접는 이유

Indie Hackers의 2025년 연간 보고서에 따르면, 첫 유료 고객을 확보한 솔로 프로젝트 중 88%가 12개월 이내에 운영을 중단합니다. 흥미로운 건 중단 사유의 분포입니다.

• 제품-시장 적합성 부족: 23% — 우리가 8화에서 30일 검증으로 걸러낸 부분
• 번아웃·시간 부족: 19% — 10화에서 다룰 주제
• 보안 사고·기술 부채: 17%
• 법적 문제·규제 미준수: 14%
• 세무·재무 관리 실패: 12%
• 기타(경쟁·개인 사정 등): 15%

보안(17%) + 법무(14%) + 세무(12%) = 43%. 실패 원인의 거의 절반이 ‘제품 밖’에 있습니다. 8화의 30일 플레이북이 앞문을 지켰다면, 오늘은 뒷문과 옆문을 잠글 차례입니다.

특히 한국에서 부업으로 시작하는 솔로프리너에게 이 세 가지는 더 무겁습니다. 한국 직장인 49.5%가 2026년 고용 불안을 느끼고(휴넷, 2025년 9월, 546명 조사), Z세대 직장인 79.0%가 부업을 고려(삼성전자 5개국 5,048명 중 한국 1,021명)하는 상황에서, 세무 신고 한 번 잘못하면 본업 회사에 부업이 노출되고, 보안 사고 한 번이면 개인정보보호법 위반으로 과징금이 날아옵니다.

자, 함정을 하나씩 들여다봅시다.

첫 번째 함정 — 바이브 코딩이 남긴 보안 지뢰밭

왜 바이브 코딩 MVP가 특히 위험한가

1화에서 우리는 바이브 코딩의 혁명적 접근성을 다뤘습니다. Q1 2026 신규 마이크로 SaaS 출시자의 34%가 프로그래밍 경험이 전무했다는 사실은 놀라운 민주화입니다. 하지만 동전의 뒷면이 있습니다.

전통적 개발에서 보안은 개발자의 경험과 코드 리뷰, CI/CD 파이프라인의 정적 분석 도구가 겹겹이 잡아줬습니다. 바이브 코딩은 이 모든 안전망을 건너뜁니다. AI는 “동작하는 코드”를 생성하는 데 최적화되어 있지, “안전한 코드”를 생성하는 데 최적화되어 있지 않습니다.

Andrej Karpathy가 2025년 초 바이브 코딩이라는 용어를 대중화할 때 이미 경고했습니다. “You fully give in to the vibes, embrace exponentials, and forget that the code even exists.” 코드의 존재를 잊는다는 것은 곧 코드 안에 숨은 취약점도 잊는다는 뜻입니다.

OWASP(Open Worldwide Application Security Project)가 매년 발표하는 웹 애플리케이션 보안 위험 목록 중, 바이브 코딩 MVP에서 특히 빈번하게 발견되는 네 가지를 살펴보겠습니다. 구체적인 공격 코드는 의도적으로 생략합니다 — 개념만 이해하면 방어는 가능합니다.

SQL 인젝션 — 입력창 하나가 전체 데이터베이스를 연다

SQL 인젝션은 OWASP Top 10에서 20년 넘게 상위권을 차지하는 고전적 취약점입니다. 사용자 입력을 데이터베이스 쿼리에 직접 끼워 넣으면, 공격자가 입력란에 특수한 명령어를 삽입해 데이터베이스 전체를 조회하거나 삭제할 수 있습니다.

바이브 코딩에서 이 취약점이 흔한 이유는 명확합니다. AI에게 “사용자 이름으로 데이터를 검색하는 기능을 만들어줘”라고 요청하면, AI는 문자열 결합 방식의 쿼리를 생성할 가능성이 있습니다. 숙련된 개발자라면 파라미터화된 쿼리(Parameterized Query)나 ORM(Object-Relational Mapping)을 사용해야 한다는 걸 본능적으로 압니다. 하지만 프로그래밍 경험이 없는 솔로프리너가 AI의 출력을 그대로 배포한다면?

방어 원칙:

• 데이터베이스 쿼리에 사용자 입력을 직접 결합하지 않는다
• ORM(SQLAlchemy, Prisma, Drizzle 등)을 사용하거나, 반드시 파라미터화된 쿼리를 쓴다
• AI에게 코드를 요청할 때 “파라미터화된 쿼리로 작성해줘”라고 명시적으로 지시한다
• 무료 도구 SQLMap의 존재를 인지한다 — 공격자는 이걸로 몇 초 만에 취약점을 찾는다

유출된 API 키 — 커밋 한 번의 대가

바이브 코딩으로 MVP를 만들 때 다양한 외부 서비스를 연동합니다. 결제(Stripe, 토스페이먼츠), 이메일(SendGrid, Resend), AI(OpenAI, Anthropic), 데이터베이스(Supabase, PlanetScale). 각 서비스는 API 키라는 비밀 인증 문자열을 발급합니다.

문제는 바이브 코딩 과정에서 이 키를 소스 코드에 직접 붙여 넣는 일이 빈번하다는 것입니다. 그리고 그 코드를 GitHub에 푸시하는 순간, 전 세계의 자동화 봇이 실시간으로 새 커밋을 스캔합니다. GitHub 자체 조사에 따르면, 공개 저장소에 커밋된 시크릿은 평균 4초 이내에 봇에 의해 탐지됩니다.

결과는? Stripe 키가 유출되면 가짜 결제가 발생하고, OpenAI 키가 유출되면 하룻밤 사이 수백 달러의 API 비용이 청구됩니다. 실제로 Indie Hackers 커뮤니티에서 한 솔로프리너는 Supabase 키 유출로 48시간 만에 전체 사용자 데이터가 삭제된 사례를 보고했습니다.

방어 원칙:

• 모든 API 키와 시크릿은 .env 파일에 보관하고, .gitignore에 반드시 추가한다
• 이미 커밋한 키가 있다면, 커밋 기록에서 삭제하는 것만으로는 부족하다 — 해당 서비스에서 키를 즉시 재발급(Rotate)한다
• GitHub의 Secret Scanning 기능을 활성화한다 (무료)
• 바이브 코딩 시 AI에게 “API 키는 환경변수에서 읽어오게 해줘, 절대 하드코딩하지 마”라고 지시한다
• 배포 환경(Vercel, Railway, Fly.io 등)의 환경변수 관리 기능을 사용한다

레이트 리밋 부재 — 하룻밤 사이 클라우드 비용 폭탄

레이트 리밋(Rate Limit)이란 특정 시간 동안 하나의 사용자나 IP가 보낼 수 있는 요청 수를 제한하는 장치입니다. 이게 없으면 두 가지 재앙이 닥칩니다.

첫째, 서비스 거부(DoS). 악의적 사용자가 초당 수천 개의 요청을 보내면 서버가 다운됩니다. 둘째, 더 흔하고 더 고통스러운 비용 폭주. 마이크로 SaaS가 내부적으로 OpenAI API를 호출하는 구조라면, 레이트 리밋 없이 요청이 폭주할 경우 AI API 비용이 하룻밤 사이 수천 달러에 달할 수 있습니다.

4화에서 다뤘던 성공 솔로프리너의 AI 스택 비용이 월 80~200달러였던 걸 기억하세요. 레이트 리밋 하나가 없어서 이 비용이 하루 만에 1,000달러를 넘기는 사고가 실제로 발생합니다.

방어 원칙:

• 모든 공개 API 엔드포인트에 레이트 리밋을 건다 — IP당, 사용자당 모두
• AI API를 호출하는 엔드포인트에는 이중 제한: 사용자당 일일 호출 횟수 + 전체 시스템 일일 비용 상한
• 클라우드 서비스의 비용 알림(Budget Alert)을 반드시 설정한다 — AWS, GCP, Vercel 모두 지원
• Stripe, 토스페이먼츠 등 결제 대행사의 웹훅에도 검증 로직을 넣어 가짜 호출을 걸러낸다

인증·권한 분리 실패 — 남의 데이터가 보이는 순간

IDOR(Insecure Direct Object Reference)이라 불리는 이 취약점은 바이브 코딩 MVP에서 가장 흔하게 발견되면서도 가장 간과됩니다. 예를 들어 사용자 프로필 조회 URL이 /api/users/123이라면, 숫자를 124로 바꿨을 때 다른 사용자의 데이터가 보이는 문제입니다.

바이브 코딩에서 AI에게 “사용자 프로필 CRUD를 만들어줘”라고 요청하면, AI는 기능적으로 완벽한 코드를 생성합니다. 하지만 “현재 로그인한 사용자만 자기 데이터에 접근 가능한가?”라는 권한 검증은 명시적으로 요청하지 않으면 빠질 수 있습니다.

이 취약점이 특히 위험한 이유는 개인정보보호법 위반과 직결되기 때문입니다. 한국에서 다른 사용자의 개인정보가 노출되면, 그것이 의도적이든 기술적 실수든 법적 책임을 집니다. 뒤에서 다룰 법무 섹션과 연결되는 지점입니다.

방어 원칙:

• 모든 데이터 접근 API에 “이 데이터의 소유자가 현재 요청자인가?” 검증을 넣는다
• URL에 순차적 숫자 ID 대신 UUID를 사용한다 — 추측을 어렵게 만든다
• AI에게 코드 요청 시 “권한 검증 미들웨어를 포함해줘”라고 반드시 명시한다
• 각 엔드포인트를 다른 사용자의 토큰으로 호출해보는 수동 테스트를 한다

출시 전 보안 미니 체크리스트

보안 전문가가 아니어도 다음 10가지를 출시 전에 점검하면 가장 흔한 공격의 80%를 막을 수 있습니다.

• ☐ 모든 데이터베이스 쿼리가 파라미터화되어 있는가? (SQL 인젝션 방어)
• ☐ .env 파일이 .gitignore에 있는가? (API 키 유출 방지)
• ☐ GitHub Secret Scanning이 활성화되어 있는가?
• ☐ 모든 공개 엔드포인트에 레이트 리밋이 있는가?
• ☐ AI API 호출에 일일 비용 상한이 있는가?
• ☐ 클라우드 Budget Alert가 설정되어 있는가?
• ☐ 모든 데이터 접근 API에 소유자 검증이 있는가? (IDOR 방어)
• ☐ HTTPS가 강제되어 있는가? (대부분 호스팅 서비스가 기본 제공)
• ☐ 사용자 비밀번호가 해시(bcrypt/argon2)로 저장되는가?
• ☐ 에러 메시지가 내부 정보(스택 트레이스, DB 스키마)를 노출하지 않는가?

이 체크리스트를 바이브 코딩 AI에게 그대로 던져서 검증을 요청할 수 있습니다. “내 코드가 이 10가지 항목을 모두 충족하는지 검사하고, 미충족 항목을 고쳐줘”라고 하면 AI는 대부분의 문제를 수정해줍니다. 바이브 코딩의 약점을 바이브 코딩으로 보완하는 셈입니다.

두 번째 함정 — 법무, 무지가 만드는 시한폭탄

제품이 기술적으로 안전해도 법적 지뢰를 밟으면 끝납니다. 특히 한국에서 직장인 신분으로 부업을 하는 솔로프리너에게 법무 리스크는 세 겹으로 쌓입니다. 본업 회사와의 관계, 정부 규제, 그리고 사용자와의 계약.

겸업 금지 조항 — 근로계약서의 지뢰

대한민국 근로기준법 자체에는 겸업을 금지하는 조항이 없습니다. 하지만 대부분의 회사가 취업규칙이나 근로계약서에 겸업 금지(또는 겸업 사전 허가) 조항을 넣고 있습니다. 여기서 핵심적으로 구분해야 할 두 개념이 있습니다.

경업 금지(競業禁止): 현재 회사와 동일한 업종에서 경쟁 활동을 하는 것. 예를 들어 A 회사 마케팅팀 직원이 마케팅 대행 부업을 하는 경우. 이 경우 회사가 징계할 법적 근거가 비교적 명확합니다.

겸업 금지(兼業禁止): 업종과 무관하게 모든 부업 자체를 금지하는 것. “사전 서면 승인 없이 타 영리 활동에 종사할 수 없다”는 식의 포괄적 조항. 2024년 대법원 판례 흐름은 이런 포괄적 겸업 금지 조항의 효력을 점차 제한하는 방향이지만, 아직 명확한 기준이 확립되지 않았습니다.

현실적 조언:

• 근로계약서와 취업규칙의 겸업 관련 조항을 지금 바로 확인한다
• 부업이 본업과 다른 업종이면 법적 위험이 낮다 — 그래도 서면 확인이 최선
• 겸업 허가 신청이 가능하다면 활용한다 — “개인 소프트웨어 프로젝트 운영”으로 신청
• 사업자등록 없이 프리랜서 소득(기타소득)으로 시작하는 것도 초기 전략 중 하나

사업자등록이 회사에 알려지는 경로

많은 직장인 솔로프리너가 두려워하는 시나리오입니다. 사실 사업자등록 자체를 회사가 직접 조회할 수 있는 합법적 경로는 제한적입니다. 하지만 다음 경로로 간접 노출될 수 있습니다.

• 건강보험료 변동: 사업소득이 연 2,000만 원을 넘으면 건강보험 직장가입자에게 소득월액보험료가 추가 부과됩니다. 회사 급여 담당자가 보험료 변동을 감지할 수 있습니다.
• 종합소득세 신고: 근로소득 + 사업소득을 합산 신고해야 합니다. 회사에 직접 통보되지는 않지만, 지방소득세 특별징수 시 차이가 발생할 수 있습니다.
• 4대 보험 이중 가입: 직원을 고용하면 사업장 가입자로 추가 등록되면서 노출될 가능성이 있습니다. 하지만 솔로프리너는 직원이 없으니 이 경로는 해당 없습니다.
• 온라인 노출: SaaS의 이용약관이나 개인정보처리방침에 대표자 본명이 들어갈 경우, 검색으로 발견될 수 있습니다.

노출 최소화 전략:

• 초기에는 사업소득을 연 2,000만 원 이하로 관리하거나, 소득 규모에 맞춰 시점을 조율한다
• 이용약관·개인정보처리방침의 사업자 정보 표기는 법적 의무이므로 생략할 수 없지만, 상호명을 본명과 다르게 설정한다
• SNS와 부업 브랜드를 본명과 분리한다
• 궁극적으로 부업 수입이 안정되면 회사에 정식으로 알리는 것이 가장 안전한 전략이다

통신판매업 신고 — SaaS를 파는 순간 의무

온라인으로 소프트웨어(SaaS)를 유료 판매하면 전자상거래 등에서의 소비자보호에 관한 법률에 따라 통신판매업 신고를 해야 합니다. 관할 지자체(구청·시청)에 신고하며, 비용은 무료입니다.

미신고 시 과태료: 최대 1,000만 원. 솔로프리너에게 치명적인 금액입니다.

신고에 필요한 것:

• 사업자등록증
• 구매안전서비스 가입 증명 (에스크로 또는 소비자피해보상보험) — 다만 PG사(토스페이먼츠, 아임포트 등)를 통해 결제를 받으면 PG사의 에스크로로 갈음 가능
• 신고 후 사이트에 통신판매업 신고번호를 표시할 의무

해외 결제(Stripe 등)만 받고 해외 고객만 대상으로 할 경우에도, 사업자가 한국에 소재하면 신고 의무가 있습니다. 많은 솔로프리너가 “해외 고객만이니까 괜찮지 않나?”라고 생각하는데, 법적으로는 그렇지 않습니다.

개인정보보호법 — 이메일 하나도 개인정보

마이크로 SaaS가 수집하는 정보를 나열해 봅시다. 이메일 주소, 이름, 결제 정보, 사용 패턴, IP 주소. 이 모든 것이 한국 개인정보보호법상 ‘개인정보’입니다.

솔로프리너라도 개인정보를 수집·처리하면 다음을 준수해야 합니다:

• 개인정보 처리방침 공개: 웹사이트에 반드시 게시. 수집 항목, 목적, 보유기간, 파기 절차를 명시
• 수집·이용 동의: 회원가입 시 명시적 동의 획득. 체크박스 기본값 해제 상태(opt-in)
• 제3자 제공 동의: 결제 대행사에 정보를 넘기는 것도 제3자 제공. 별도 동의 필요
• 개인정보보호 책임자 지정: 1인 사업자라면 대표자 본인이 겸임 가능
• 개인정보 유출 통지: 유출 발생 시 72시간 이내 정보주체와 개인정보보호위원회에 통지

특히 바이브 코딩으로 만든 MVP에서 앞서 다룬 IDOR 취약점으로 다른 사용자의 데이터가 노출되면, 그것은 곧 개인정보 유출 사고가 됩니다. 보안과 법무가 이렇게 연결됩니다.

해외 사용자가 있다면 EU의 GDPR(일반개인정보보호규정)도 검토 대상입니다. GDPR 위반 과징금은 글로벌 매출의 4% 또는 2,000만 유로 중 높은 금액. 솔로프리너에게 현실적으로 적용되는 경우는 드물지만, EU 사용자의 데이터를 처리한다면 최소한 개인정보 처리방침에 GDPR 관련 조항을 포함해야 합니다.

오픈소스 라이선스 — AI가 생성한 코드의 출처

바이브 코딩의 숨은 법적 리스크 중 하나는 오픈소스 라이선스 문제입니다. AI 코딩 도구는 수십억 줄의 오픈소스 코드로 훈련되었고, 생성하는 코드가 특정 오픈소스 프로젝트의 코드와 실질적으로 동일할 수 있습니다.

오픈소스 라이선스는 크게 두 유형입니다:

• 허용적 라이선스(Permissive): MIT, Apache 2.0, BSD. 출처만 표기하면 상업적 사용 가능
• 카피레프트(Copyleft): GPL, AGPL. 이 코드를 사용하면 내 소프트웨어도 동일 라이선스로 공개해야 한다. SaaS의 경우 AGPL이 특히 주의 대상

AI가 GPL 코드를 학습한 뒤 실질적으로 동일한 코드를 생성했다면, 그 SaaS는 GPL 조건을 따라야 할 수 있습니다. 아직 판례가 확립되지 않은 회색 지대이지만, 리스크는 인지해야 합니다.

현실적 대응:

• 주요 의존성(npm 패키지, pip 패키지)의 라이선스를 확인한다 — license-checker 같은 도구로 자동화 가능
• AI 생성 코드 중 핵심 비즈니스 로직은 직접 검토하거나, AI에게 “라이선스 문제가 없는 코드인지 확인해줘”라고 요청한다
• AGPL 라이선스 의존성은 SaaS에서 사용 시 특별 주의 — 법적 의무가 따를 수 있다

세 번째 함정 — 세무, 모르면 수익의 절반이 증발한다

보안은 제품을, 법무는 사업 자격을 지키는 것이었다면, 세무는 수익을 지키는 문제입니다. 8화에서 첫 매출 전 평균 지출이 1,000달러 미만이라고 했습니다. 그 소중한 초기 매출을 세금으로 절반 날리는 건 아무도 원하지 않을 겁니다.

⚠️ 중요 안내: 이 섹션은 2026년 6월 기준 한국 세법의 일반적 원칙을 설명합니다. 개인 상황에 따라 적용이 달라질 수 있으므로, 구체적인 세무 의사결정은 반드시 국세청 홈택스 가이드를 참고하고 세무사 상담을 받으시길 권합니다.

사업자등록 — 언제, 어떻게

마이크로 SaaS를 유료로 판매하기 시작하면 사업자등록은 의무입니다. 세법상 사업 개시일로부터 20일 이내에 관할 세무서에 등록해야 합니다. 온라인으로 홈택스에서 신청 가능하며, 처리에 보통 1~3영업일 소요됩니다.

개인사업자 vs 법인: 초기 솔로프리너는 개인사업자로 시작하는 것이 합리적입니다. 법인 설립은 비용(등기비, 법무사 비용 등 최소 50~100만 원)이 들고 회계 의무가 복잡합니다. 연 매출이 일정 수준(일반적으로 5,000만~1억 원) 이상 안정되면 법인 전환을 검토해도 늦지 않습니다.

업종 코드 선택: 소프트웨어 개발·판매는 보통 722000(응용 소프트웨어 개발 및 공급업) 또는 749909(기타 전문 서비스업)을 사용합니다. 업종 코드에 따라 간이과세자의 부가가치율이 달라지므로 세무서나 세무사에게 확인하고 선택하세요.

간이과세자 vs 일반과세자 — 연매출 1억 400만 원의 경계

개인사업자는 간이과세자와 일반과세자로 나뉩니다. 이 구분이 솔로프리너에게 중요한 이유는 세금 부담이 크게 달라지기 때문입니다.

간이과세자 기준: 직전 연도 공급대가가 1억 400만 원 미만이면 간이과세자로 등록할 수 있습니다. 신규 사업자는 최초 등록 시 간이과세자를 선택할 수 있고, 이후 매출에 따라 전환됩니다.

간이과세자의 핵심 혜택:

• 부가세 감면: 일반과세자는 매출의 10%를 부가가치세로 납부하지만, 간이과세자는 업종별 부가가치율(5~30%)을 곱한 금액에 10%를 적용합니다. 소프트웨어 업종은 부가가치율이 30%이므로, 실질 부가세율은 매출의 약 3%입니다. 일반과세자 10%와 비교하면 엄청난 차이입니다.
• 연 매출 4,800만 원 미만 시 부가세 납부 면제: 4화에서 솔로 운영 적정 가격이 월 29~199달러라고 했습니다. 고객 10~20명이면 연 매출이 4,800만 원 미만일 가능성이 높고, 이 경우 부가세 자체를 내지 않습니다.
• 간편 신고: 세금계산서 발행 의무가 면제되고(영수증 발행), 부가세 신고가 연 1회(1월)로 간소화됩니다.

간이과세자의 제한:

• 세금계산서 발행 불가 (연 매출 4,800만 원 미만 시): B2B 고객이 세금계산서를 요구하면 대응이 어렵습니다. 다만 4,800만~1억 400만 원 구간에서는 세금계산서 발행 가능.
• 업종에 따라 간이과세 배제 대상이 있으므로 확인 필요

결론: 초기 솔로프리너는 간이과세자로 시작하는 것이 거의 항상 유리합니다. 매출이 1억 400만 원에 근접하면 그때 일반과세자 전환을 준비하면 됩니다.

경비처리 극대화 — 합법적 절세의 핵심

소득세는 매출 − 경비 = 소득에 대해 과세됩니다. 경비를 합법적으로 최대한 인정받으면 세금이 줄어듭니다. 솔로프리너가 경비로 처리할 수 있는 항목은 생각보다 많습니다.

① 장비

• 노트북, 모니터, 키보드, 마우스, 웹캠 — 사업에 사용하는 전자기기
• 스마트폰 (업무용으로 구분 가능한 경우)
• 책상, 의자 등 홈오피스 가구 (사업용 공간이 구분되는 경우)
• 1건당 100만 원 이하 소액 자산은 즉시 경비 처리, 초과 시 감가상각

② 통신비

• 인터넷 요금 — 자가 사무실(홈오피스)이면 사업 사용 비율만큼 안분 가능
• 휴대폰 요금 — 사업용 번호를 별도로 개통하면 전액 경비. 겸용이면 사업 비율만큼
• 도메인 등록비, SSL 인증서 비용

③ 소프트웨어 구독

• Cursor (바이브 코딩 도구) 월 구독료
• 호스팅 비용: Vercel, Railway, AWS, Supabase 등
• 디자인 도구: Figma, Canva Pro
• 생산성 도구: Notion, Slack, 기타 SaaS 구독
• AI API 비용: OpenAI, Anthropic 등의 API 사용료
• 이메일 서비스: SendGrid, Resend, Mailchimp
• 분석 도구: Google Analytics는 무료이지만, Mixpanel, Amplitude 유료 플랜은 경비

④ 교육·도서

• 온라인 강의 수강료 (Udemy, Coursera, 인프런 등)
• 기술 서적 구입비
• 세미나·컨퍼런스 참가비

⑤ 마케팅

• 구글 광고, 페이스북/인스타그램 광고비
• 콘텐츠 마케팅 관련 비용 (사진, 영상 제작)
• PR·홍보 서비스 비용

4화에서 성공 솔로프리너의 AI 스택 비용이 월 80~200달러, 초저비용 출시 스택이 0~50달러/월이라고 했습니다. 이 비용이 모두 경비로 처리되면 세금을 줄이면서 사업을 운영하는 구조가 됩니다. 반드시 영수증·카드 명세를 보관하고, 사업용 카드(뒤에 설명)로 결제하세요.

노란우산공제 — 연 500만 원 소득공제

노란우산공제는 소기업·소상공인을 위한 퇴직금 적립 제도입니다. 매월 일정 금액을 납입하면, 연간 최대 500만 원까지 소득공제를 받을 수 있습니다.

가입 자격: 개인사업자이면서 소기업 또는 소상공인에 해당하면 됩니다. 솔로프리너는 거의 예외 없이 자격이 됩니다.

공제 한도 (사업소득 기준):

• 사업소득 4,000만 원 이하: 연 500만 원 공제
• 4,000만~1억 원: 연 300만 원 공제
• 1억 원 초과: 연 200만 원 공제

왜 중요한가: 솔로프리너 초기에 사업소득이 4,000만 원 이하라면, 노란우산공제로 500만 원 소득공제를 받을 수 있습니다. 종합소득세율 15% 구간이라면 약 75만 원, 24% 구간이라면 약 120만 원의 세금을 절약하는 셈입니다. 거기에 연 복리 이자까지 붙습니다.

주의: 중도 해지 시 기타소득세가 부과되므로, 장기 납입을 전제로 가입해야 합니다. 하지만 솔로프리너로서 사업을 지속할 의지가 있다면 가입하지 않을 이유가 없는 제도입니다.

사업용 카드와 사업용 계좌 — 섞으면 돌이킬 수 없다

이것은 세무 관리에서 가장 기본적이면서 가장 많이 간과되는 부분입니다. 개인 지출과 사업 지출을 물리적으로 분리해야 합니다.

사업용 카드 등록:

• 홈택스에서 사업용 신용카드를 등록하면, 해당 카드의 사용 내역이 자동으로 국세청에 전송됩니다
• 별도의 신용카드를 발급받거나, 기존 카드 중 하나를 사업 전용으로 지정합니다
• 사업 관련 모든 지출(소프트웨어 구독, 호스팅, 장비 구매 등)은 이 카드로만 결제
• 경비 증빙이 자동화되어 종합소득세 신고 시 편리합니다

사업용 계좌:

• 사업 수입이 들어오는 전용 통장을 만든다
• Stripe, 토스페이먼츠 등의 정산금을 이 계좌로 받는다
• 사업용 카드의 결제도 이 계좌에서 빠져나가게 설정하면 완벽한 분리

왜 분리해야 하는가: 세무조사 시 개인 소비와 사업 경비가 섞여 있으면, 경비 인정이 어려워집니다. 반대로 깔끔하게 분리되어 있으면 경비 인정이 수월합니다. 또한 사업의 실제 수익성을 파악하는 데도 필수적입니다 — 개인 통장에 사업 수입이 들어오면, 이번 달 사업이 흑자인지 적자인지도 알 수 없습니다.

Stripe 같은 해외 결제 대행사를 사용하면 달러로 정산되는데, 이 경우 외화 수취 전용 계좌(페이오니아, 와이즈 비즈니스 등)를 경유할 수 있습니다. 환율 차이도 사업 소득/비용에 반영되므로 환전 시점의 환율을 기록해 두세요.

종합소득세 — 직장인 부업의 세금 구조

직장인이 부업으로 사업소득이 발생하면, 근로소득과 사업소득을 합산해 종합소득세를 신고해야 합니다. 매년 5월 종합소득세 신고 기간에 홈택스에서 진행합니다.

세금 구조:

• 근로소득: 회사에서 원천징수됨 (연말정산으로 정산)
• 사업소득: 매출 − 경비 = 사업소득금액
• 종합소득 = 근로소득 + 사업소득
• 종합소득에 대해 누진세율(6~45%) 적용

2026년 종합소득세 누진세율:

• 1,400만 원 이하: 6%
• 1,400만~5,000만 원: 15%
• 5,000만~8,800만 원: 24%
• 8,800만~1.5억 원: 35%
• 1.5억~3억 원: 38%
• 3억~5억 원: 40%
• 5억~10억 원: 42%
• 10억 원 초과: 45%

예를 들어 근로소득이 연 5,000만 원이고, 부업 사업소득이 연 1,000만 원이라면, 종합소득은 6,000만 원. 추가되는 1,000만 원에는 24% 세율이 적용되어 약 240만 원의 추가 세금이 발생합니다. 여기서 경비처리와 노란우산공제로 사업소득을 줄이면 세금도 줄어듭니다.

간편장부 vs 복식부기:

• 직전 연도 수입금액 7,500만 원 미만이면 간편장부 대상 — 엑셀 수준의 장부로 충분
• 7,500만 원 이상이면 복식부기 의무 — 이 시점에서는 세무사 의뢰가 현실적
• 솔로프리너 초기에는 간편장부로 시작하고, 매출이 성장하면 세무사를 고용합니다

절세 핵심 요약:

• 간이과세자로 부가세 부담 최소화
• 사업용 카드로 경비 증빙 자동화
• 노란우산공제로 소득공제 극대화
• 기장을 꼼꼼히 해서 경비 누락 방지
• 종합소득세 신고 시 근로소득 공제와 사업소득 공제를 모두 활용

다시 한번 강조합니다. 이 섹션의 내용은 일반적 안내이며, 개인별 상황에 따라 달라질 수 있습니다. 국세청 홈택스(hometax.go.kr)의 가이드를 참고하고, 세무사 상담을 받는 것을 강력히 권장합니다.

금융IT 20년 경력자의 익명 미니 코너

— 이번 주제: “세금계산서 하나로 들통났던 그 날”

20년 전 금융IT에서 일하던 시절, 같은 팀에 야근 대신 ‘밤 코딩’을 하는 선배가 있었습니다. 낮에는 우리 회사의 인터넷뱅킹 시스템을 만들고, 밤에는 작은 증권 데이터 분석 툴을 개발해서 팔았습니다. 당시 기준으로 월 200~300만 원 정도의 추가 수입이 있었다고 합니다.

그 선배의 실수는 단순했습니다. 서버 호스팅 비용을 경비처리하려고 세금계산서를 발행받았는데, 업종이 ‘소프트웨어 개발업’이었습니다. 문제는 그 선배가 경업 금지 조항이 있는 회사에 다니고 있었다는 것. 회사 감사팀이 전 직원의 외부 사업자등록 현황을 조회하는 정기 점검에서 걸렸습니다. (당시에는 가능했던 절차였습니다.)

결과적으로 선배는 시말서를 쓰고 부업을 접어야 했습니다. 세무적으로는 올바른 행동(세금계산서 발행, 경비처리)이었지만, 법무적으로는 경업 금지 위반이었습니다. 세 가지 함정 — 보안, 법무, 세무 — 은 각각 따로 노는 게 아니라 서로 연결됩니다. 하나를 잘해도 다른 하나가 뒷통수를 칩니다.

지금이라면 어떻게 했을까요? 업종 코드를 본업과 겹치지 않게 선택하고, 회사의 겸업 조항을 먼저 확인했을 겁니다. 아니면 매출이 충분히 커질 때까지 프리랜서 소득(기타소득)으로 신고하면서 사업자등록을 늦추는 전략을 썼을 수도 있습니다. 물론 가장 좋은 건 회사에 솔직하게 말하는 것이겠지만, 그게 쉽지 않다는 것도 알고 있습니다.

88%를 피한 12%의 공통점

지금까지 보안, 법무, 세무 세 함정을 살펴봤습니다. 실패하지 않는 12%에게는 공통점이 있습니다. 그들이 더 뛰어난 개발자이거나 더 좋은 아이디어를 가져서가 아닙니다. 제품 밖의 체크리스트를 빠뜨리지 않았기 때문입니다.

보안에서: 출시 전 OWASP 기본 체크를 돌렸습니다. 바이브 코딩으로 만든 코드라도 AI에게 “보안 취약점을 점검해줘”라고 한 번 더 요청했습니다. API 키를 환경변수로 분리하고, 레이트 리밋을 걸고, 권한 검증을 넣었습니다.

법무에서: 본업 회사의 겸업 조항을 확인했습니다. 통신판매업 신고를 했습니다. 개인정보 처리방침을 게시했습니다. 이 중 하나도 어려운 일이 아닙니다 — 그냥 안다는 것이 차이입니다.

세무에서: 간이과세자로 등록하고, 사업용 카드와 계좌를 분리하고, 경비를 꼼꼼히 처리했습니다. 노란우산공제에 가입해서 소득공제를 챙겼습니다. 종합소득세 신고를 직접 하거나, 매출이 커지면 세무사에게 맡겼습니다.

Garry Tan(Y Combinator CEO)이 2025년 말 팟캐스트에서 한 말이 이 상황을 정확히 짚습니다: “The number one killer of solo startups isn’t bad products — it’s bad hygiene. Security hygiene, legal hygiene, financial hygiene.” 나쁜 위생이 나쁜 제품보다 더 많은 사업을 죽입니다.

출시 전 통합 체크리스트 — 보안·법무·세무

8화의 30일 플레이북이 ‘만들기 전’ 체크리스트였다면, 이것은 ‘출시 직전’ 체크리스트입니다. 모든 항목을 한 번에 완료할 필요는 없습니다. 하지만 첫 유료 고객을 받기 전에 반드시 완료해야 합니다.

보안 (출시 전 필수)

• ☐ SQL 인젝션 방어: 모든 DB 쿼리가 파라미터화/ORM 사용
• ☐ API 키 분리: 모든 시크릿이 환경변수에, .gitignore 확인
• ☐ GitHub Secret Scanning 활성화
• ☐ 레이트 리밋: 모든 공개 엔드포인트, 특히 AI API 호출 경로
• ☐ 비용 상한: 클라우드 Budget Alert 설정
• ☐ 인증·권한: 모든 데이터 접근에 소유자 검증(IDOR 방어)
• ☐ HTTPS 강제
• ☐ 비밀번호 해시 저장 (bcrypt/argon2)
• ☐ 에러 메시지에 내부 정보 미노출
• ☐ 입력값 검증: 모든 사용자 입력에 길이·형식 제한

법무 (첫 유료 고객 전 필수)

• ☐ 근로계약서 겸업 조항 확인
• ☐ 통신판매업 신고 (관할 구청/시청)
• ☐ 개인정보 처리방침 작성 및 웹사이트 게시
• ☐ 이용약관 작성 및 게시
• ☐ 개인정보 수집·이용 동의 절차 구현 (opt-in)
• ☐ 제3자 제공 동의 (결제 대행사 등)
• ☐ 환불 정책 명시 (전자상거래법 7일 이내 청약철회)
• ☐ 오픈소스 라이선스 점검 (특히 AGPL 주의)
• ☐ 사업자 정보 표시 (상호, 대표자, 사업자등록번호, 통신판매업 신고번호)

세무 (매출 발생 전후 필수)

• ☐ 사업자등록 (홈택스 온라인 신청)
• ☐ 간이과세자 여부 확인 및 선택
• ☐ 사업용 신용카드 홈택스 등록
• ☐ 사업용 계좌 개설 및 정산금 수취 설정
• ☐ 노란우산공제 가입 검토
• ☐ 경비 증빙 체계 수립 (영수증·카드명세 보관)
• ☐ 간편장부 양식 준비
• ☐ 부가세 신고 일정 캘린더 등록 (간이: 1월, 일반: 1월+7월)
• ☐ 종합소득세 신고 일정 등록 (매년 5월)
• ☐ 해외 매출 시 환율 기록 체계 수립

이 체크리스트가 부담스럽게 느껴질 수 있습니다. 하지만 한 번에 다 할 필요 없습니다. 8화의 30일 플레이북처럼 단계별로 진행하세요:

• MVP 개발 중: 보안 항목부터 하나씩 적용
• 베타 테스트 시작: 법무 항목 정리 (개인정보 처리방침, 이용약관)
• 첫 유료 전환: 세무 항목 완료 (사업자등록, 사업용 카드)

이 순서를 따르면 “갑자기 다 해야 한다”는 압박 없이 자연스럽게 체크리스트를 채울 수 있습니다.

바이브 코딩 시대의 방어적 개발 — AI에게 안전도 맡기기

1화에서 다뤘듯, 바이브 코딩의 핵심은 자연어로 지시해 코드를 만드는 것입니다. 같은 원리를 보안에도 적용할 수 있습니다. 몇 가지 실전 프롬프트를 공유합니다.

보안 점검 프롬프트 (바이브 코딩 도구에 그대로 입력):

• “이 프로젝트의 모든 데이터베이스 쿼리를 검토하고, SQL 인젝션에 취약한 부분을 찾아 파라미터화된 쿼리로 수정해줘”
• “코드 전체에서 하드코딩된 API 키, 비밀번호, 시크릿을 찾아서 환경변수로 분리해줘”
• “모든 API 엔드포인트에 레이트 리밋을 추가해줘. IP당 분당 60회, 사용자당 분당 30회로 설정”
• “모든 데이터 조회/수정 API에 현재 로그인 사용자의 소유권 검증을 추가해줘”

법무 문서 프롬프트 (AI 챗봇에 입력):

• “한국 개인정보보호법에 맞는 SaaS 개인정보 처리방침 초안을 작성해줘. 수집 항목: 이메일, 이름, 결제정보. 제3자 제공: Stripe”
• “한국 전자상거래법에 맞는 SaaS 이용약관 초안을 작성해줘”

⚠️ AI가 생성한 법률 문서는 초안입니다. 최종 버전은 법률 전문가의 검토를 받거나, 최소한 정부 제공 표준 양식과 대조하세요. 개인정보보호위원회 홈페이지에서 업종별 개인정보 처리방침 표준 양식을 다운로드할 수 있습니다.

바이브 코딩의 약점을 바이브 코딩으로 보완하고, AI의 법률 지식을 초안 작성에 활용하되, 최종 검증은 전문가에게 맡기는 것. 이것이 솔로프리너의 현실적 전략입니다. 완벽할 필요 없습니다. 방어선이 0개인 것과 방어선이 3개인 것의 차이가 88%와 12%를 가릅니다.

사이드허슬 세무 FAQ — 가장 많이 묻는 질문 5가지

이 시리즈를 연재하면서 독자분들로부터 세무 관련 질문을 많이 받았습니다. 가장 빈번한 5가지를 정리합니다.

Q1. 아직 매출이 0원인데 사업자등록을 해야 하나요?

법적으로는 ‘사업 개시일’부터 20일 이내에 등록해야 합니다. 하지만 사업 개시일의 기준이 “실제 매출 발생”인지 “사업 준비 시작”인지는 해석의 여지가 있습니다. 현실적으로 첫 유료 고객이 생기기 직전에 등록하는 것이 일반적입니다. 무료 베타 테스트 기간에는 사업자등록 없이 진행해도 문제가 되는 경우는 드뭅니다.

Q2. 해외 결제(Stripe)만 받는데 한국에서 사업자등록이 필요한가요?

네. 사업자가 한국에 소재하면 매출의 원천지와 무관하게 한국에서 사업자등록과 세금 신고 의무가 있습니다. 해외 매출은 원화로 환산해 신고합니다.

Q3. 부업 소득이 얼마부터 종합소득세를 따로 신고해야 하나요?

사업소득은 금액과 관계없이 종합소득세 신고 대상입니다. 다만 기타소득(일시적 용역 등)은 연 300만 원 이하일 때 분리과세를 선택할 수 있어 신고가 간편합니다. 지속적·반복적 매출이 발생하면 사업소득으로 분류되므로 금액과 무관하게 신고해야 합니다.

Q4. 세무사 비용은 얼마나 드나요?

간편장부 대상 개인사업자의 기장료는 월 5~10만 원, 종합소득세 신고 대행은 건당 15~30만 원이 일반적입니다. 연 매출 1,000만 원 이하 초기에는 직접 홈택스로 신고하고, 매출이 커지면 세무사를 고용하는 것이 비용 효율적입니다. 무료 세무 상담은 국세청 126 전화상담과 각 지역 세무서 민원실에서 가능합니다.

Q5. 회사에 부업이 들통나지 않으려면?

앞서 설명한 대로, 건강보험료 변동(사업소득 연 2,000만 원 초과 시)이 가장 큰 노출 경로입니다. 초기에는 사업소득을 이 기준 이하로 관리하고, 온라인에서 본명 노출을 최소화하는 것이 현실적입니다. 하지만 궁극적으로 부업이 안정되면 회사에 알리는 것이 리스크 관리 측면에서 최선입니다.

실패하는 88%의 타임라인 — 어디서 무너지는가

마지막으로, 88% 실패의 시간 분포를 살펴봅시다. Indie Hackers 커뮤니티의 비공식 조사(2025년 하반기, 응답자 약 1,200명)에 따르면:

• 출시 후 1~3개월: 전체 실패의 35%가 이 구간에 집중. 주 원인: 보안 사고, 법적 미비로 인한 서비스 중단
• 출시 후 4~6개월: 전체 실패의 28%. 주 원인: 세무 문제(예상치 못한 세금 부담), 기술 부채 누적
• 출시 후 7~12개월: 전체 실패의 37%. 주 원인: 번아웃, 성장 정체 — 이것은 10화의 주제

오늘 다룬 보안·법무·세무 함정은 주로 처음 6개월에 작동합니다. 역으로 말하면, 이 6개월을 안전하게 넘기면 생존 확률이 급격히 올라갑니다. 그리고 이 6개월의 안전은 기술력이 아니라 체크리스트가 결정합니다.

이번 글의 한 줄 요약

솔로 사업의 88% 실패는 나쁜 제품이 아니라 나쁜 위생(보안·법무·세무)이 만든다 — 체크리스트 하나로 12%의 편에 설 수 있다.

다음 화 예고 — 10화: 확장하지 않을 권리

9화까지 우리는 좌표를 확인하고(1~3화), 모델을 골랐고(4~7화), 30일 검증을 끝내고(8화), 88%의 함정을 피하는 법을 배웠습니다(9화). 마지막 10화에서는 가장 중요한 질문을 던집니다.

“성장해야 한다”는 압박에서 벗어나, 확장하지 않을 권리를 선택한 솔로프리너들은 어떻게 5년, 10년을 버틸까?

번아웃 없이 지속 가능한 솔로 사업의 구조, 자동화와 위임의 경계, 그리고 ‘충분한 크기’를 정의하는 법. 시즌 2의 대미를 장식합니다. 다음 화에서 만나겠습니다.

이미지는 Leonardo AI 로 생성되었습니다.

이미지는 Claude AI 로 생성되었습니다.

---