같은 컴포넌트, 다른 세계: 하나의 코드베이스에서 만든 두 카드 게임

Source: Dev.to

해당 글의 내용을 번역하려면 텍스트를 제공해 주시겠어요? 현재는 링크만 전달받았으며, 실제 기사 본문이 포함되어 있지 않아 번역을 진행할 수 없습니다.
본문을 복사해서 보내주시면, 마크다운 형식과 코드 블록은 그대로 유지하면서 한국어로 번역해 드리겠습니다.

하나의 코드베이스로 두 제품 만들기

제가 Party Challenges 를 만들기 시작했을 때, 같은 코드를 사용해 두 번째 제품을 출시할 계획은 없었습니다. 하지만 약 2주 정도 진행하고 보니 뭔가를 깨달았습니다: 카드 컴포넌트, 덱 선택기, 게임 루프, PWA 설정… 이 모든 것이 카드에 무엇이 들어있는지는 신경 쓰지 않았습니다. 도전 과제와 깊은 질문이 React 컴포넌트에게는 전혀 같은 모습으로 보였습니다.

그래서 저는 같은 기반 위에 Here We Ask 를 만들었습니다—동일한 카드 뒤집기 애니메이션, 동일한 덱 네비게이션, 동일한 오프라인‑우선 아키텍처. 전혀 다른 제품이죠.

아래는 하나의 코드베이스로 두 제품을 출시하면서 배운 점과, 왜 더 많은 인디 개발자들이 이 방식을 시도해 보아야 하는지에 대한 내용입니다.

공유 레이어

두 제품 모두 Lovable(빠른 프로토타이핑을 위해 제가 사용하는 바이브 코딩 툴)로 만든 React SPA이며, 컴포넌트 트리의 약 **70 %**를 공유합니다:

• Card component – 플립 애니메이션 및 스와이프 제스처
• Deck selector – 카테고리 필터링
• Game modes – 핫 시트, 타임드, 클래식
• PWA service worker – 오프라인 플레이
• Daily content rotation 로직
• Premium gate & 결제 흐름 (양쪽 모두 $1.99 /월)

핵심 인사이트: 컴포넌트를 콘텐츠가 아니라 동작 중심으로 구축하면 재사용이 쉬워집니다. Card 컴포넌트는 “마지막 문자를 크게 소리 내어 부르라”와 같은 문구를 담고 있는지, “5년 전 강하게 믿었지만 이제는 바뀐 신념은 무엇인가요?”와 같은 문구를 담고 있는지 알 필요가 없습니다. 단순히 텍스트를 렌더링하고, 스와이프를 처리하며, 진행 상황을 추적합니다.

그들이 갈라지는 지점

The interesting part isn’t the shared code; it’s where the products must be different.

The same component renders both; the theming layer does all the heavy lifting. I use a config object per product that controls:

// Simplified example
const productConfig = {
  theme:            'party' | 'calm',
  cardAnimation:   'bounce' | 'fade',
  deckOrder:        [...],
  premiumDecks:    [...],
  dailyContentPool:'challenges' | 'questions',
  copyVariant:     'energetic' | 'reflective'
};

Switch the config and you get an entirely different product feel.

“Date Night”가 제품 포지셔닝에 대해 가르쳐 준 것

두 제품 모두 “Date Night.” 라는 덱을 가지고 있다. UI는 동일하지만 감성적 레지스터는 완전히 다르다. 두 제품을 사람들에게 보여줄 때, 그들은 종종 같은 코드베이스라는 것을 깨닫지 못한다—그것이 목표다. 기술은 눈에 띄지 않아야 한다; 사용자는 제품이 자신의 순간에 맞는지에 관심을 가진다.

포트폴리오 수학

두 번째 제품을 만드는 데는 첫 번째 제품 노력의 대략 30 % 정도가 들었습니다. 그 추가 작업의 대부분은 콘텐츠 제작(1,000개 이상의 질문 작성 vs. 1,000개 이상의 챌린지)과 테마/카피 작업이었습니다. 인프라, 배포, PWA 설정, 분석, SEO 패턴 등은 모두 재사용되었습니다.

저는 Inithouse 에서 여러 제품을 운영하고 있습니다. 아이디어는 간단합니다: 작고 집중된 도구들을 만들고 어떤 것이 성공하는지 보는 것이죠. 몇 가지 예시:

• Magical Song – 개인 맞춤형 AI 노래
• Pet Imagination – AI 반려동물 초상화
• Vibe Coderi – 체코어 vibecoding 포털

카드 게임을 통해 배운 점은 포트폴리오 구축이 단순히 별개의 제품을 출시하는 것이 아니라, 그들 사이의 공통된 핵심을 찾는다는 것입니다. 한 번 잘 만든 모든 컴포넌트는 다시 만들 필요가 없습니다.

Source: …

빌더를 위한 실용적인 요점

1. 동작을 먼저 생각하고, 콘텐츠는 나중에.
   무엇이 일어나는가 (플립, 스와이프, 필터, 게이트) 를 기준으로 컴포넌트 트리를 구성하고, 무엇을 말하는가 (도전, 질문, 인용) 보다 먼저 생각하세요. 리스킨이 빨라집니다.

2. 테마 설정이 기능 플래그보다 낫다.
   처음에 기능 플래그를 사용해 보았지만 금방 복잡해졌습니다. 제품별 전용 설정 객체를 두면 더 깔끔하고 이해하기 쉬워집니다—코드 안에서 현재 어떤 제품을 보고 있는지 항상 알 수 있거든요.

3. 콘텐츠가 진짜 작업이다.
   기술 구현은 몇 주, 콘텐츠 제작은 몇 달이 걸립니다. 1,000개의 좋은 파티 도전을 쓰는 것과 1,000개의 좋은 대화 시작 문구를 쓰는 것은 전혀 다른 스킬입니다. 이 부분을 과소평가하지 마세요.

4. 첫 번째 제품을 완벽히 다듬기 전에 두 번째 제품을 출시하라.
   파티 챌린지를 또 한 달 동안 다듬을 수도 있었지만, 아키텍처가 신선할 때 ‘Here We Ask’를 출시했습니다. 두 제품 모두 더 빨리 개선되었습니다—한 제품에서 수정한 내용이 종종 다른 제품에도 바로 적용되기 때문이죠.

What’s next

저는 이 패턴이 카드 게임을 넘어 확장되는지 탐구하고 있습니다. Verdict Buddy (AI 갈등 해결)와 Watching Agents (AI 예측 플랫폼)은 전혀 다른 아키텍처를 사용하지만, 일부 하위 레벨 패턴(SEO 훅, 분석 설정, PWA 구성)이 계속 나타납니다. 그 안에 공유 툴킷이 숨겨져 있을 수도 있습니다.

여러 제품을 만들고 있거나—아니면 단순히 생각하고 있든—코드 재사용을 어떻게 처리하고 있는지 듣고 싶습니다. 댓글을 남기거나 **Dev.to**에서 저를 찾아주세요.

*저는 **Inithouse*의 설립자 Jakub입니다. 우리는 작은 AI 및 웹 제품 포트폴리오를 구축하며 아이디어를 빠르게 테스트하고 반응을 확인합니다. Party Challenges와 Here We Ask가 그 중 두 가지입니다.

• 현재 진행 중인 실험은 약 열두 개 정도입니다.