채널별 런치 카피를 레포에서 버전 관리하는 법

런치 카피 초안을 직접 작성하고 레포에 커밋했다.

개발자가 마케팅 카피까지 손대는 게 이상하게 보일 수도 있는데, 팀 규모가 작거나 1인 체계로 굴러가는 프로젝트에서는 코드 못지않게 "어떻게 말할 것인가"가 런치 성패를 가른다. 이번에 marketing/launch-copy.md 한 파일에 HN, Reddit, GeekNews, ProductHunt 네 채널 각각의 카피를 한꺼번에 정리해서 올렸다.

왜 채널별로 카피를 따로 쓰는가

네 채널은 독자 성격이 완전히 다르다.

같은 제품을 소개하더라도 HN에 PH 스타일 카피를 붙여넣으면 바로 "Show HN: [내 제품] is the best tool ever" 식의 조롱 대상이 된다. 반대로 PH에 HN 스타일의 건조한 기술 설명을 올리면 업보트가 안 쌓인다. 채널별 관습을 무시하면 런치 당일 트래픽을 날리는 가장 빠른 방법이다.

카피를 코드 레포에 넣는 이유

마케팅 문서를 Notion이나 Google Docs에만 두는 팀도 많은데, 나는 의도적으로 marketing/ 디렉터리를 레포 안에 만들었다.

• 버전 관리: 런치 전후로 카피가 수십 번 바뀐다. diff로 무엇이 왜 바뀌었는지 추적 가능
• 리뷰 흐름 통일: 코드 PR과 동일한 프로세스로 카피 리뷰를 받을 수 있음
• 컨텍스트 보존: 기능 커밋 바로 옆에 해당 기능의 설명 문구가 있으면 나중에 히스토리 파악이 훨씬 빠름
• 배포 자동화 연결 가능성: 나중에 CI에서 카피 파일을 읽어 포스팅 자동화를 붙이는 것도 고려 중

<!-- marketing/launch-copy.md 구조 예시 -->

## HN (Show HN)
**제목**: Show HN: pdf2api – [한 줄 기술 설명]
**본문**: ...

## ProductHunt
**태그라인**: [동사] your [명사] in [숫자] seconds
**첫 댓글**: ...

## Reddit
**타겟 서브레딧**: r/...
**제목 패턴**: ...

## GeekNews
**제목**: ...
**본문**: ...

파일 하나에 채널을 섹션으로 나눠 관리하는 방식인데, 채널이 더 늘어나면 파일을 분리하는 게 맞겠지만 지금 규모에서는 한 파일이 오히려 전체를 한 눈에 비교하기 좋다.

런치 카피 작성에서 실제로 어려운 부분

기술적인 설명을 짧게 줄이는 것보다, "왜 이걸 만들었는가" 를 솔직하게 한 문장으로 만드는 게 제일 힘들었다. 기능 나열은 쉬운데, 커뮤니티 독자들이 실제로 반응하는 건 만든 사람의 동기와 고통 포인트다.

HN에서 잘 먹히는 Show HN 글들을 보면 공통 패턴이 있다.

• 내가 불편해서 만들었다는 구체적 경험
• 기존 솔루션이 왜 안 맞았는지 (경쟁사 디스 아님, 내 유스케이스 설명)
• 기술적으로 흥미로운 결정 한 가지

이 세 가지를 억지로 다 넣으려다 보면 카피가 길어지고 산만해진다. 결국 하나만 고르는 편집력이 필요한데, 그게 개발자 출신에게는 꽤 낯선 근육이다.

이번 커밋 자체는 파일 하나 추가지만, 거기까지 오는 데 드래프트를 몇 번 갈아엎었다. 런치 날짜가 정해진 이상 카피 완성도에 더 시간을 쓰는 것보다, 지금 수준으로 고정하고 실제 반응을 보면서 수정하는 쪽이 맞다고 판단했다. 어차피 git에 있으니까.

다음은 실제 포스팅 일정 조율.

🛒 이 글과 어울리는 추천 상품

• 노트북 쿠팡에서 보기 →
• 외장SSD 쿠팡에서 보기 →
• 기계식키보드 쿠팡에서 보기 →

*위 링크는 쿠팡파트너스 활동의 일환이며, 일정액의 수수료를 제공받을 수 있습니다.