[Claude 활용 24회 — AI에게 일을 위임하는 법] 22/24화: 익명 사업 4단계 — 실명 없이 신뢰를 만드는 법
지난 21화에서 Agent SDK로 내부 스크립트를 웹 폼이 붙은 서비스로 감쌌다. 상품의 형태가 갖춰졌다. 그런데 한 가지가 빠졌다. 누구 이름으로 팔 것인가.
익명 사업이라고 하면 뭔가 떳떳하지 못한 것처럼 들린다. 사실은 정반대다. 이력서도, 명함도, 링크드인 프로필도 아닌 — 결과물의 품질만으로 평가받겠다는 선언이다. 20년 넘게 코드를 짜면서 내가 배운 건, 내 이름보다 내가 만든 것이 오래 남는다는 사실이다. 이번 22화에서는 실명을 노출하지 않으면서도 사업자 등록부터 결제, 세금, 개발 환경까지 완전히 분리하는 4단계를 다룬다. 21화에서 만든 상품이 있다면, 이제 그 상품을 어떤 이름으로, 어떤 환경에서 세상에 내놓을지를 결정할 차례다.
실명을 걸었을 뿐인데 — 사이드 프로젝트가 무너진 날
3년 전, 같이 일하던 동료 이야기다. 그는 퇴근 후에 틈틈이 작은 자동화 도구를 만들었다. 특정 포맷의 로그 파일을 파싱해서 시각화하는, 꽤 잘 만든 도구였다. 주말마다 개인 시간을 쏟아 코드를 짰고, 어느 날 해외 마켓플레이스에 올렸다. 월 10달러 구독 모델이었다. 석 달 만에 유료 구독자가 80명 넘었다.
문제는 두 가지였다.
- 그 도구를 회사 노트북에서 만들었다.
- 마켓플레이스 계정을 회사 이메일로 만들었다.
코드를 전부 뜯어봐도 회사 자산은 한 줄도 없었다. 사내 라이브러리도 쓰지 않았고, 회사의 로그 포맷과도 무관했다. 순수하게 개인 시간에, 개인의 아이디어로 만든 도구였다. 하지만 인사팀에서 연락이 왔다. 근로계약서의 겸업 금지 조항. 그리고 회사 장비를 이용한 개인 사업 활동이라는 정황.
결국 서비스를 내렸다. 시말서를 썼다. 80명의 유료 구독자에게 환불 메일을 보냈다. 그리고 다시는 사이드 프로젝트를 하지 않았다.
이 이야기를 듣고 나는 두 가지를 결심했다.
- 사이드 프로젝트는 물리적으로 완전히 분리한다.
- 내 실명은 걸지 않는다.
동료의 도구는 기술적으로 완벽하게 깨끗했다. 법적으로도 회사 IP를 침해하지 않았다. 하지만 정황이 문제였다. 회사 장비에 개발 흔적이 남아 있었고, 회사 이메일이 결제 시스템에 연결되어 있었고, 회사 네트워크에서 접속한 로그가 있었다. 기술이 아니라 환경이 그를 잡은 것이다.
나는 그때부터 ‘분리’를 기술이 아니라 인프라로 접근하기 시작했다. 코드를 잘 짜는 것만큼, 코드를 짜는 환경을 설계하는 것이 중요하다는 걸 깨달았다. 그리고 AI에게 일을 위임하는 시대에, 이 분리는 오히려 더 쉬워졌다. 내가 직접 타이핑하는 시간이 줄어들수록, 어디서 타이핑했느냐는 질문의 의미도 바뀌기 때문이다.
익명 사업의 분리 4층 — 정체성·환경·재무·지식재산
왜 굳이 실명을 숨기냐고 묻는 사람이 있다. 떳떳하면 이름을 걸면 되지 않느냐고. 틀린 말은 아니지만, 현실은 다르다.
대한민국 근로자의 상당수는 근로계약서에 겸업 금지 조항이 들어 있다. ‘회사의 사전 서면 승인 없이 다른 영리 활동에 종사할 수 없다’는 문구다. 이 조항이 실제로 법적 구속력을 가지는 범위는 법제처 국가법령정보센터의 근로기준법 관련 판례를 참고해야 하지만, 핵심은 이것이다 — 실명이 노출되면 겸업 여부가 입증 가능해진다. 반대로, 필명으로 활동하면 결과물과 고용 관계 사이의 연결고리가 끊어진다.
두 번째 이유는 더 본질적이다. 디지털 경제에서 신뢰는 출처가 아니라 결과물에서 온다. GitHub에서 가장 많은 스타를 받은 프로젝트들 중 상당수는 필명이나 핸들 이름으로 운영된다. 기술 블로그 시장에서 가장 충성도 높은 독자층을 가진 필자들도 본명을 모르는 경우가 허다하다. 사람들은 ‘누가 만들었느냐’가 아니라 ‘이게 내 문제를 해결하느냐’를 본다.
세 번째는 위험 관리다. 초기 사이드 프로젝트는 실패 확률이 높다. 실명으로 실패하면 그 이력이 검색에 남는다. 필명으로 실패하면 깨끗하게 접고 다음을 시작할 수 있다. 이건 비겁한 게 아니라, 실험의 비용을 줄이는 전략이다.
이 세 가지 이유로, 나는 익명 사업을 4개의 분리 층으로 설계한다. 아파트의 방수층처럼 — 한 층이 뚫려도 다음 층이 버티는 구조다.
1층 — 정체성 분리: 필명, 이메일, 소셜 계정
가장 바깥층이다. 세상과 만나는 면이므로 가장 먼저 설계한다.
- 필명(Pen Name): 기억하기 쉽고, 검색했을 때 다른 사람과 겹치지 않는 이름. 한글보다 영문이 글로벌 플랫폼에서 유리하다. 필명을 정했으면 모든 플랫폼에서 동일하게 사용한다. GitHub, 마켓플레이스, 블로그, X(트위터), 이메일 — 전부 같은 이름. 일관성이 곧 브랜드다.
- 이메일: ProtonMail이나 Tutanota 같은 프라이버시 중심 이메일 서비스, 또는 Gmail도 무방하다. 핵심은 회사 이메일과 완전히 분리된 계정이라는 것. 이 이메일은 사이드 프로젝트 전용이다. 회사 업무에 절대 쓰지 않는다.
- 소셜 계정: GitHub, X, 블로그 플랫폼. 전부 필명 이메일로 가입. 프로필 사진은 본인 얼굴을 쓰지 않는다. AI 생성 아바타, 일러스트, 또는 로고를 쓴다.
- 도메인: 프로젝트 사이트나 랜딩 페이지를 만든다면, WHOIS 프라이버시 보호가 기본 포함된 레지스트라를 사용한다. Cloudflare Registrar, Namecheap 등이 무료 프라이버시 보호를 제공한다.
정체성 분리에서 가장 흔한 실수: 하나의 이메일로 개인/회사/사이드를 다 돌리는 것. 이메일 하나가 유출되면 세 개의 세계가 동시에 연결된다. 최소 두 개 — 회사용과 사이드용 — 는 물리적으로 다른 계정이어야 한다.
2층 — 환경 분리: 하드웨어, 네트워크, 계정
동료를 잡은 것은 코드가 아니라 환경이었다. 이 층이 가장 중요하다.
- 하드웨어: 사이드 프로젝트는 회사 장비가 아닌 개인 장비에서만 작업한다. 고사양이 필요 없다. 중고 노트북이면 충분하다. AI에게 위임하는 작업 방식에서는 GPU보다 안정적인 네트워크가 더 중요하다. 2화에서 다뤘듯 Cowork 세션은 클라우드에서 돌아간다 — 내 로컬 장비 성능은 지시를 내리는 데 필요한 정도면 된다.
- OS 계정: 개인 장비라도, 가능하면 사이드 프로젝트 전용 OS 사용자 계정을 만든다. 브라우저 히스토리, 쿠키, 클립보드, 파일 경로가 섞이지 않는다.
- 네트워크: 회사 VPN에 연결된 상태에서 사이드 프로젝트를 하지 않는다. 회사 네트워크를 경유한 트래픽은 로그가 남을 수 있다. 개인 인터넷을 사용한다.
- 클라우드 계정: AWS, GCP, GitHub 등 — 사이드용 계정을 따로 만든다. 회사에서 제공하는 클라우드 크레딧, 라이선스, 계정을 사이드에 쓰지 않는다. 무료 티어만으로도 초기에는 충분하다.
- 시간: 이건 회색 지대처럼 보이지만 사실 명확하다. 근무 시간에는 사이드 프로젝트를 하지 않는다. 점심시간 포함이다. Git 커밋 타임스탬프, 파일 수정 시각 — 이런 것들이 증거가 된다. 뒤에서 이걸 자동으로 관리하는 방법을 다룬다.
환경 분리는 귀찮다. 두 대의 장비를 오가야 하고, 두 개의 계정을 관리해야 한다. 하지만 이 귀찮음이 보험이다. 문제가 생겼을 때, 물리적으로 분리된 장비와 계정은 가장 강력한 증거가 된다.
3층 — 재무 분리: 사업자, 결제, 세금
⚠️ 법률·세무 안내: 이 절의 내용은 2026년 8월 기준 일반적인 정보 제공 목적이며, 개별 상황에 대한 법률 자문이나 세무 상담을 대체하지 않습니다. 사업자 등록, 세금 신고, 겸업 관련 판단은 반드시 변호사·세무사 등 전문가와 상담하세요.
돈이 오가기 시작하면 익명의 벽에 첫 번째 균열이 생긴다. 대한민국에서 합법적으로 수익을 얻으려면 결국 국세청과 만나야 하기 때문이다. 하지만 이건 ‘실명 노출’과 다르다. 세무 당국에 신고하는 것과 고객에게 실명을 보여주는 것은 별개의 문제다.
국내 판매 — 사업자 등록 경로
- 개인사업자 등록: 홈택스에서 온라인으로 가능하다. 상호(사업체 이름)는 자유롭게 정할 수 있다 — 필명을 상호로 써도 된다. 다만 대표자명은 본인 실명이 들어간다. 이 정보는 사업자등록증에 기재되고, 사업자등록번호 조회 시 상호는 보이지만 대표자 실명이 직접 검색되는 것은 아니다. 그래도 기업 간 거래(B2B)에서는 세금계산서에 대표자명이 찍힌다.
- 간이과세자 vs 일반과세자: 연 매출 1억 400만 원 미만(2025년 기준, 변동 가능)이면 간이과세자로 시작할 수 있다. 사이드 프로젝트 초기에는 대부분 여기 해당한다. 세금 계산이 단순하고, 세금계산서 발행 의무가 일부 면제된다.
- 통신판매업 신고: 온라인으로 디지털 상품을 파는 경우 필요하다. 관할 구청에서 처리. 이것도 대표자명이 들어가지만, 소비자에게 직접 보이는 건 상호명이다.
해외 플랫폼 판매 — 우회 경로
- Gumroad, Lemon Squeezy, Paddle: 해외 결제 대행 플랫폼은 판매자 표시명(Display Name)과 법적 등록명을 분리해서 관리한다. 구매자에게는 필명과 프로젝트 이름만 보인다. 세금 보고는 판매자의 거주국 법에 따르며, 한국 거주자라면 종합소득세 신고 시 해외 소득을 포함해야 한다.
- GitHub Sponsors, Open Collective: 오픈소스 프로젝트 후원을 받는 방식. 필명 계정으로 운영 가능하다.
- 크몽, 숨고 등 국내 프리랜서 플랫폼: 대부분 실명 인증을 요구하지만, 활동명(닉네임)으로 고객에게 노출된다. 실명은 플랫폼-판매자 사이에서만 관리된다.
재무 분리의 핵심: 사이드 프로젝트 수익 전용 통장을 하나 만든다. 모든 수입과 지출을 이 통장으로만 처리한다. 회사 급여 통장과 섞지 않는다. 연말 종합소득세 신고 시 사업 소득을 분리 신고하기 편하고, 만약 겸업 관련 이슈가 생기더라도 회사 업무와 자금 흐름이 완전히 분리되어 있다는 증거가 된다.
핵심은 이것이다: 세무 당국에는 실명으로 신고하되, 고객에게는 필명으로 서비스한다. 이 두 가지는 양립 가능하다. 합법적이면서도 익명인 사업이 가능한 이유다.
4층 — 지식재산 분리: 라이선스, 코드 출처
가장 기술적인 층이다. 개발자에게는 가장 익숙하지만, 가장 방심하기 쉬운 층이기도 하다.
- 회사 코드 재사용 금지: 이건 당연하다. 하지만 ‘재사용’의 범위가 생각보다 넓다. 회사에서 만든 유틸리티 함수를 가져오는 것은 물론이고, 회사 프로젝트의 아키텍처 패턴을 그대로 베끼는 것도 위험할 수 있다. 특히 회사에서 직접 개발한 독자적 알고리즘이나 비즈니스 로직은 영업비밀로 보호될 수 있다.
- 오픈소스 라이선스 준수: 사이드 프로젝트에 사용하는 오픈소스 라이브러리의 라이선스를 반드시 확인한다. MIT, Apache 2.0은 상업적 사용이 자유롭지만, GPL 계열은 파생 저작물의 소스 공개 의무가 있다. OSI(Open Source Initiative)에서 각 라이선스의 정확한 조건을 확인할 수 있다.
- 도메인 용어 주의: 회사 내부에서만 쓰는 용어, 약어, 데이터 스키마 구조를 사이드 프로젝트에 그대로 가져오면, 그것 자체가 ‘회사 자산을 활용했다’는 정황이 될 수 있다. 5화에서 CLAUDE.md에 도메인 용어를 정리한 것을 기억하는가? 사이드 프로젝트의 CLAUDE.md에는 회사 도메인 용어 사용 금지 규칙을 넣어야 한다.
- 학습과 재현의 경계: 회사에서 배운 기술을 사이드 프로젝트에 적용하는 것은 괜찮다. 특정 디자인 패턴, 아키텍처 원칙, 공개된 알고리즘 — 이런 것은 개인의 역량이다. 하지만 ‘회사 시스템의 구현 세부사항을 그대로 재현하는 것’은 다르다. 경계가 모호하다면, 처음부터 새로 설계하라. 깨끗한 룸(clean room) 구현이 최선이다.
이 4개의 층은 독립적으로 작동한다. 정체성 층이 뚫려도(필명이 밝혀져도) 환경 층이 깨끗하면 문제가 되지 않는다. 환경 분리가 완벽해도 회사 코드를 가져왔으면 끝이다. 각 층을 개별적으로 관리해야 하는 이유가 여기에 있다.
실습 — 완전 분리 개발 환경 구축 4단계
개념은 충분하다. 이제 실제로 설정한다. 아래는 모두 개인 장비에서 실행한다. 회사 장비에서는 이 글을 읽는 것까지만.
Step 1 — 필명 인프라 만들기
가장 먼저, 필명을 정하고 디지털 존재를 만든다.
# 1. 필명 전용 이메일 생성 (ProtonMail, Gmail 등)
# 예: [email protected]
# 2. GitHub 계정 생성 (필명 이메일로)
# https://github.com — 새 계정, 필명으로
# 3. 프로필 설정
# - Display name: 필명
# - Bio: 프로젝트 설명 (회사/직함 언급 없이)
# - Email: 필명 이메일
# - 중요: Settings → Emails → "Keep my email addresses private" 체크
# - 중요: Settings → Emails → "Block command line pushes that expose my email" 체크GitHub의 이메일 프라이버시 설정은 반드시 켜야 한다. 이 설정이 꺼져 있으면 모든 커밋에 실제 이메일이 기록되고, 누구나 git log로 확인할 수 있다. GitHub은 [email protected] 형태의 noreply 이메일을 제공하니, 커밋에는 이 주소가 찍히게 설정한다.
Step 2 — 물리적 환경 분리
개인 장비에 사이드 프로젝트 전용 공간을 만든다.
# 사이드 프로젝트 루트 디렉토리 구조
~/side-projects/
├── .gitconfig # 필명 전용 Git 설정 (Step 3에서 작성)
├── .claude/
│ └── settings.json # Claude Code 전역 설정 — 사이드 전용
├── my-saas-product/
│ ├── CLAUDE.md # 이 프로젝트의 AI 운영 규칙
│ ├── LICENSE # 명시적 라이선스
│ ├── pyproject.toml
│ └── src/
├── my-skill-pack/
│ ├── CLAUDE.md
│ ├── skills/
│ └── README.md
└── my-mcp-server/
├── CLAUDE.md
└── src/이 디렉토리 바깥에서는 사이드 프로젝트 작업을 하지 않는다. 반대로, 이 디렉토리 안에서는 회사 작업을 하지 않는다. 물리적 경로가 경계선이다.
Step 3 — Git과 Claude Code 설정
이 단계가 가장 실용적이다. Git의 includeIf 기능을 사용하면, 특정 디렉토리에서 작업할 때 자동으로 필명 설정이 적용된다.
# ~/.gitconfig (개인 장비의 전역 Git 설정)
[user]
name = 본명
email = [email protected]
# side-projects 디렉토리에서는 자동으로 필명 설정 적용
[includeIf "gitdir:~/side-projects/"]
path = ~/side-projects/.gitconfig# ~/side-projects/.gitconfig (필명 전용)
[user]
name = TechCrafter42
email = [email protected]
[commit]
gpgsign = false # 필명 계정 전용 GPG 키가 없다면
[init]
defaultBranch = main이렇게 하면 ~/side-projects/ 하위의 모든 Git 저장소에서 자동으로 필명과 필명 이메일이 커밋에 찍힌다. 일일이 git config --local을 칠 필요가 없다. 디렉토리 경계가 곧 정체성 경계가 된다.
다음은 실명 유출을 방지하는 pre-commit 훅이다. 6화에서 다룬 훅 기반 방어의 확장이다.
#!/bin/bash
# ~/side-projects/pre-commit-template
# 새 저장소마다 .git/hooks/pre-commit 으로 복사하거나 git template으로 등록
#
# 사용법:
# chmod +x ~/side-projects/pre-commit-template
# git config --global init.templateDir ~/side-projects/git-template
# mkdir -p ~/side-projects/git-template/hooks
# cp ~/side-projects/pre-commit-template ~/side-projects/git-template/hooks/pre-commit
# ── 여기에 본인의 실명, 회사 관련 키워드를 넣는다 ──
BLOCKED_PATTERNS="홍길동|gildong\.hong|acmecorp|acme-internal|사내시스템명"
# staged 파일에서 차단 패턴 검색
if git diff --cached --diff-filter=ACMR | grep -iE "$BLOCKED_PATTERNS" > /dev/null 2>&1; then
echo ""
echo "⚠️ 실명 또는 회사 관련 키워드가 포함된 변경이 감지되었습니다."
echo " 차단된 패턴: $BLOCKED_PATTERNS"
echo " 커밋을 중단합니다. 해당 내용을 제거한 뒤 다시 시도하세요."
echo ""
# 어떤 파일에서 발견됐는지 표시
git diff --cached --diff-filter=ACMR --name-only | while read -r file; do
if git show ":$file" 2>/dev/null | grep -iE "$BLOCKED_PATTERNS" > /dev/null 2>&1; then
echo " → $file"
fi
done
echo ""
exit 1
fi
exit 0이 훅은 커밋할 때마다 자동으로 실행되며, 실명이나 회사 관련 키워드가 코드·설정·문서 어디에든 포함되면 커밋을 막는다. 6화에서 강조했던 원칙 — “프롬프트로 ‘하지 마’는 통제가 아니다. 코드로 막아야 통제다” — 의 직접 적용이다.
이제 사이드 프로젝트에 사용할 CLAUDE.md 템플릿이다. 5화에서 만든 CLAUDE.md의 원칙을 사이드 프로젝트에 맞게 변형한 것이다.
# CLAUDE.md — [프로젝트명] (사이드 프로젝트 템플릿)
## 1. 프로젝트 소개
> [한 줄 설명]
## 2. 익명성 규칙 (최우선 — 위반 시 작업 중단)
- 실명, 회사명, 소속, 직책 일절 사용 금지
- 코드 주석, 커밋 메시지, README, 에러 메시지에 개인 식별 정보 포함 금지
- 회사 프로젝트의 코드, 설정, 아키텍처 패턴, 도메인 용어 사용 금지
- 예제 데이터는 전부 가상 도메인으로: example.com, bookstore, travel-app
- 파일 경로에 실명이나 회사명이 들어간 디렉토리 참조 금지
## 3. 라이선스 규칙
- 새 의존성 추가 전 라이선스 확인 필수 (MIT/Apache-2.0 우선)
- GPL 계열 사용 시 반드시 이 파일에 기록
- 회사 프로젝트에서 사용하는 사내 라이브러리 / 유료 SDK 사용 금지
## 4. 기술 스택
- [여기에 프로젝트별 스택 기재]
## 5. 빌드 & 테스트
- [빌드 명령]
- [테스트 명령]
## 6. 금지 사항
- [프로젝트별 금지 항목]핵심은 §2 익명성 규칙이다. 이걸 CLAUDE.md에 넣으면, AI가 코드를 생성할 때 자동으로 이 규칙을 따른다. 주석에 실명을 넣거나, 회사 도메인 용어를 사용하거나, 회사 프로젝트의 패턴을 답습하는 실수를 AI 레벨에서 차단한다. 이것이 AI에게 일을 위임하는 시대의 분리 전략이다 — 내가 실수할 수 있는 지점을 AI의 운영 규칙으로 막는다.
Step 4 — 라이선스 감사 자동화
의존성이 늘어나면 각 라이브러리의 라이선스를 수동으로 확인하기 어렵다. 자동화한다.
# Python 프로젝트 의존성 라이선스 확인
pip install pip-licenses
pip-licenses --format=table --with-urls --order=license
# 출력 예시:
# Name Version License URL
# ---------- ------- ----------- -------------------------
# fastapi 0.111.0 MIT License https://github.com/...
# pydantic 2.7.0 MIT License https://github.com/...
# uvicorn 0.30.0 BSD License https://github.com/...# Node.js 프로젝트 의존성 라이선스 확인
npx license-checker --summary
# 특정 라이선스만 허용하는 엄격 모드
npx license-checker --onlyAllow "MIT;Apache-2.0;BSD-2-Clause;BSD-3-Clause;ISC"
# 허용 목록에 없는 라이선스가 발견되면 exit code 1 → CI에서 실패 처리이 명령을 CI/CD 파이프라인에 넣으면, 누군가(또는 AI가) GPL 라이브러리를 의존성에 추가했을 때 자동으로 잡아낸다. 12화에서 다룬 플러그인 패키징의 품질 관리와 같은 맥락이다.
Python 프로젝트라면 pyproject.toml에 라이선스 정보를 명시하는 것도 잊지 않는다.
# pyproject.toml 발췌
[project]
name = "my-side-project"
license = {text = "MIT"}
authors = [
{name = "TechCrafter42", email = "[email protected]"}
]여기서도 저자명은 필명이다. 실명이 들어갈 자리가 없다.
보너스 — SSH 키 분리
GitHub 계정이 두 개(본명 계정 + 필명 계정)라면, SSH 키도 분리해야 한다. 같은 SSH 키를 두 계정에 등록할 수 없기 때문이다.
# 필명 계정 전용 SSH 키 생성
ssh-keygen -t ed25519 -C "[email protected]" -f ~/.ssh/id_ed25519_side
# ~/.ssh/config 에 호스트 별칭 추가
# 본명 계정 (기본)
Host github.com
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519
# 필명 계정
Host github-side
HostName github.com
User git
IdentityFile ~/.ssh/id_ed25519_side# 사이드 프로젝트 저장소에서 remote 설정
cd ~/side-projects/my-saas-product
git remote set-url origin git@github-side:techcrafter42/my-saas-product.git
# 이제 push/pull 시 자동으로 필명 계정의 SSH 키 사용
git push origin main이 설정까지 하면 ~/side-projects/ 하위에서의 모든 Git 작업은 — 커밋 저자, 이메일, SSH 인증까지 — 필명으로 완전히 분리된다. 실수로 본명 계정의 저장소에 push하거나, 필명 저장소에 본명으로 커밋하는 사고가 구조적으로 차단된다.
함정 — ‘회사 노트북으로 잠깐만’이 모든 걸 무너뜨린다
분리 환경을 아무리 잘 설계해도, 한 번의 예외가 모든 걸 무너뜨린다. 동료의 사례를 다시 떠올려보자. 그는 분명 자기 코드를 짰다. 하지만 ‘잠깐 편하니까’ 회사 노트북에서 작업했다. 그 한 번이 정황의 시작이었다.
이것은 물리적 분리 원칙이다. 예외 없이 지켜야 하는 규칙들이다.
함정 1: “잠깐 아이디어만 메모하려고”
회사 노트북에서 사이드 프로젝트 관련 메모를 한다. 노션에, 슬랙 DM에, 이메일 임시보관함에. ‘코드를 짠 건 아니니까 괜찮겠지’라고 생각한다. 하지만 디지털 포렌식에서는 의도가 아니라 흔적이 증거가 된다. 회사 장비에서 사이드 프로젝트 관련 활동을 했다는 로그가 남으면, 그것 자체가 정황이다.
대안: 아이디어가 떠오르면 개인 휴대폰의 메모 앱에 적는다. 회사 장비는 건드리지 않는다.
함정 2: “회사에서 쓰는 도구인데 익숙하니까”
회사가 제공하는 JetBrains 라이선스, Figma 팀 라이선스, GitHub Copilot Business 라이선스를 사이드 프로젝트에 쓴다. ‘어차피 같은 도구인데’라고 생각하지만, 이 라이선스는 회사가 업무 목적으로 구매한 것이다. 사적 사용은 라이선스 위반이자 회사 자산 유용이다.
대안: 무료 대안을 쓴다. VS Code는 무료다. Claude Code는 MAX 개인 구독으로 쓴다. 15화에서 만든 예약 작업을 21화에서 서비스로 감쌌다면, 그 전 과정이 개인 구독 도구로만 이뤄졌는지 확인한다.
함정 3: “근무 시간에 잠깐 배포만”
점심시간에 사이드 프로젝트의 버그 핫픽스를 배포한다. ’10분이면 되니까.’ 하지만 그 10분 동안의 커밋 타임스탬프, 서버 접속 로그, 채팅 기록은 근무 시간 중의 겸업 활동 정황이 된다.
대안: 사이드 프로젝트 작업은 퇴근 후, 주말, 또는 휴가 중에만 한다. 급한 버그라도 저녁까지 기다린다. 15화에서 만든 예약 작업 시스템이 있다면, 배포를 퇴근 후 시각으로 예약한다.
함정 4: “오픈소스니까 괜찮겠지”
회사 프로젝트에서 사용하는 오픈소스 라이브러리의 래퍼를 회사에서 만들었다. 그 래퍼를 사이드 프로젝트에 가져온다. ‘원래 오픈소스 위에 쓴 건데.’ 하지만 래퍼 자체는 회사의 저작물이다. 오픈소스 라이브러리의 라이선스와 회사가 그 위에 작성한 코드의 소유권은 별개 문제다.
대안: 오픈소스 라이브러리는 직접 사용한다. 래퍼가 필요하면 처음부터 새로 만든다. 회사 코드를 참조하지 않고, 해당 라이브러리의 공식 문서만 보고 작성한다. Clean room 구현이다.
함정 5: 시간 증명의 부재
모든 분리를 완벽하게 했지만, 문제가 생겼을 때 이 코드가 퇴근 후에 작성됐다는 증거가 없다. Git 커밋 타임스탬프는 로컬 시계에 의존하므로 조작이 가능하다고 반박당할 수 있다.
대안: GitHub에 정기적으로 push한다. GitHub의 서버 타임스탬프는 조작할 수 없다. push 기록이 모두 저녁 시간대와 주말에 집중되어 있다면, 그 자체가 강력한 정황 증거다. 매일 작업이 끝나면 push하는 습관을 들인다. 또한 Cowork 세션은 클라우드 서버에 타임스탬프가 찍히므로, 2화에서 다룬 클라우드 실행의 부수 효과로 시간 증명이 자동으로 남는다.
이 다섯 가지 함정의 공통점은 ‘한 번만 예외’라는 생각이다. 한 번의 예외가 패턴이 되고, 패턴이 증거가 된다. 물리적 분리는 기술이 아니라 습관이다. 그리고 습관이 무너지지 않게 돕는 것이 바로 앞에서 설정한 pre-commit 훅, CLAUDE.md 규칙, SSH 키 분리 같은 자동화된 방어선이다.
여기서 이 시리즈를 관통하는 원칙이 다시 등장한다. AI가 코드를 짜주는 시대가 아니라, AI에게 일을 위임하는 시대다. 위임할 줄 아는 사람이 하나의 회사가 된다. 하나의 회사가 되려면, 그 회사의 인프라 — 정체성, 환경, 재무, IP — 가 다른 어떤 회사의 것과도 섞이지 않아야 한다. 분리는 독립의 전제 조건이다.
이번 회차의 수익화 지점
이번 화에서 만든 것은 상품이 아니라 상품을 파는 인프라다. 하지만 이 인프라 자체가 수익화 대상이 될 수 있다.
- 익명 사업 셋업 가이드: 이 글에서 다룬 4단계 분리 환경을 한국 법률·세무 맥락에 맞춰 더 상세하게 풀어낸 전자책이나 노션 템플릿. 개발자뿐 아니라 디자이너, 콘텐츠 크리에이터, 프리랜서도 같은 고민을 한다. 대상을 넓힐 수 있다.
- 사이드 프로젝트 CLAUDE.md + pre-commit 훅 번들: 이 글의 코드 블록을 정리하고, 다양한 기술 스택(Python, Node.js, Go)별 변형을 추가한 템플릿 팩. 9화에서 다룬 Skill 형태로도 배포 가능하다.
- 익명 브랜딩 컨설팅: 필명 선정, 플랫폼 계정 구조, 결제 시스템 설계를 1:1로 도와주는 서비스. 1시간 세션 형태. 기술적 셋업은 Claude에게 위임하고, 사람은 전략 판단에 집중한다.
핵심은 이것이다: 분리 환경 구축은 한 번 하면 끝이지만, 그 경험을 템플릿화하면 반복 판매가 가능하다. 21화의 Agent SDK 상품을 이 인프라 위에서 운영하면, 상품과 인프라를 묶어서 ‘익명 SaaS 런칭 패키지’로 팔 수도 있다.
다음 23화에서는 이렇게 분리된 환경에서 실제로 돈을 버는 4가지 수익 유형 — 템플릿 판매, 마이크로 SaaS, 콘텐츠 파이프라인, 컨설팅 — 의 난이도·유지비·수익 구조를 비교한다. 이 시리즈에서 만든 모든 자산이 어떤 수익 유형에 투입되는지, 매핑 표를 하나 펼칠 것이다.
관련 회차: 5화 — CLAUDE.md 작성법 | 12화 — 플러그인 만들기와 판매 | 21화 — Agent SDK로 제품 만들기
◀ 이전 21화 (다음 차수는 아직 게시되지 않았습니다)
자주 묻는 질문
익명으로 사업하면서도 사업자 등록과 세금 처리를 합법적으로 할 수 있나요?
네, 이 글에서는 실명을 노출하지 않으면서도 사업자 등록부터 결제, 세금까지 완전히 분리하는 4단계 방법을 다룹니다. 정체성, 환경, 재무, 지식재산의 4개 층으로 나누어 각각을 독립적으로 설계하는 구조입니다.
필명으로 운영하는 사업도 고객 신뢰를 얻을 수 있나요?
글에 따르면 디지털 경제에서 신뢰는 출처가 아니라 결과물에서 옵니다. GitHub에서 높은 스타를 받은 프로젝트나 충성도 높은 독자층을 가진 기술 블로그 중 상당수가 필명으로 운영되며, 사람들은 누가 만들었느냐보다 자신의 문제를 해결하느냐를 기준으로 판단합니다.
[…] 시리즈: Claude 활용 24회 — AI에게 일을 위임하는 법 (총 24화 중 23화)◀ 이전 22화 (다음 차수는 아직 게시되지 […]
[…] […]
[…] […]