홈페이지가 신용도 라는데? — 개발자의 1인 창업 일지

들어가며

지난 편에서 사업자를 내고, 통신판매업, 게임제작업, 게관위 심의까지 끝낸 이야기를 했다.

사업자를 내고 나니까, 자연스럽게 다음 생각이 들었다.

"사업자인데... 좀 그럴듯해 보여야 하지 않나?"

 

스팀에 게임을 출시했고, 사업자도 냈고, 근데 이메일은 gmail.com이다.

뭔가 좀 아쉽다.

 

그래서 구글 워크스페이스를 만들었고, 홈페이지를 배포했고,

그러다 보니 운영툴도 만들게 됐고, 앱도 만들고 있고...

이걸 효율적으로 관리하려다 보니 모노레포까지 오게 됐다.

---

워크스페이스, 도메인 이메일이 필요했다

개인사업자로 활동하면서, 여기저기 이메일을 보낼 일이 생긴다.

스팀웍스, 구글플레이, 애플 개발자 계정, 각종 서비스 가입...

근데 이메일 주소가 xxx@gmail.com이면 좀 그렇다.

사업자인데 개인 Gmail을 쓰는 것과, xxx@mydomain.com을 쓰는 것은 느낌이 다르다.

 

특히 해외 서비스나 플랫폼에 문의할 때, 도메인 이메일이면 "이 사람 진짜 사업을 하고 있구나"라는 인상을 줄 수 있다.

이게 그냥 느낌만의 이야기가 아니라, 실제 데이터도 있다.

 

2024년 업계 보고서에 따르면, 커스텀 도메인 이메일은 일반 이메일(Gmail, Yahoo 등) 대비 약 60% 높은 고객 신뢰도와 연관이 있다고 한다.

그리고 기술적으로도, 커스텀 도메인에 SPF, DKIM, DMARC 인증을 제대로 설정하면 미인증 도메인보다 2.7배 더 높은 확률로 받은편지함에 도달한다.

 

쉽게 말하면 스팸으로 안 가고 메일이 잘 도착한다는 거다.

물론 60%라는 숫자가 인디 게임 개발자한테 그대로 적용되는지는 모르겠다.

 

이런 데이터는 대부분 이메일 호스팅 업체에서 나온 거라, 좀 뻥이 섞여있을 수도 있다.

근데 최소한 xxx@gmail.com보다는 나아 보이는 건 사실이고,

 

실제로 플랫폼이나 해외 서비스에 문의할 때 도메인 이메일이면 좀 더 진지하게 대해주는 느낌은 있었다.

느낌이다. 확실한 건 아니다. 근데 나쁠 건 없다고 판단했다.

그래서 구글 워크스페이스를 만들었다.

도메인을 사서, 비즈니스 이메일을 설정했다.

물론 비용이 나간다. 또 고정 지출이 늘었다...

대략.. 워크스페이스 비용은 1인기준 7.64달러,,

---

홈페이지, 이건 확실히 효과가 있다

워크스페이스를 만들었으면, 그 도메인에 홈페이지도 있어야 자연스럽다.

도메인만 있고 홈페이지가 없으면 오히려 더 이상해 보인다.

스팀에 게임을 출시했는데, 공식 홈페이지가 있으면 신뢰도가 올라간다.

스팀 스토어 페이지에 개발사 웹사이트 링크를 걸 수 있거든.

 

유저 입장에서 "이 개발사 홈페이지가 있네" 하면 좀 더 믿음이 가지 않겠나.

(1인 개발인 걸 알면 또 다른 이야기겠지만...)

 

홈페이지 효과는 도메인 이메일보다 데이터가 더 확실하다.

DreamHost가 2025년 11월에 미국 소비자 1,200명을 대상으로 조사한 결과에 따르면,

웹사이트가 있는 사업체는 없는 사업체보다 41% 더 신뢰받는다고 한다.

 

이건 온라인 리뷰 다음으로 강력한 신뢰 신호였다.

더 재밌는 건, 소비자의 69%가 "웹사이트는 사업체의 신뢰성에 필수적"이라고 답했는데,

18~24세 젊은 층에서는 오히려 72%로 더 높았다는 거다.

 

SNS 세대가 오히려 홈페이지를 더 중요하게 본다니, 좀 의외였다.

그래서 회사 홈페이지를 만들었다.

 

Next.js로.

나는 원래 React/Next.js가 주력이니까, 이건 익숙한 영역이었다.

Unity로 게임 만들 때처럼 삽질할 일은 없었다. 드디어 내 무기를 쓸 수 있었다.

---

근데 홈페이지만 만든 게 아니다

홈페이지를 만들다 보니까, 자연스럽게 다른 것들도 필요해졌다.

게임 데이터를 관리하는 운영툴도 만들어야 했고,

추후에 iOS 앱도 만들 계획이었다.

 

정리하면 이런 프로젝트들이 동시에 돌아가고 있었다.

회사 홈페이지 (Next.js), 운영툴/어드민, iOS/앱 관련 작업, API 서버.

이걸 각각 별도의 저장소(레포지토리)로 관리할 수도 있었다.

근데 1인 개발자가 레포를 4개, 5개씩 따로 관리하면? 지옥이다.

---

모노레포를 선택한 이유

모노레포(Monorepo)는 여러 프로젝트를 하나의 저장소에서 관리하는 방식이다.

 

반대로 각 프로젝트를 별도 저장소로 관리하는 건 멀티레포(Multirepo)라고 한다.

나는 모노레포를 선택했다. 이유는 간단하다. 혼자니까.

 

멀티레포로 하면 이런 일이 생긴다.

홈페이지에서 쓰는 API 타입을 바꿨다. 운영툴에서도 바꿔야 한다. 앱에서도 바꿔야 한다.

레포 3개를 돌아다니면서 같은 걸 3번 수정한다.

 

공통 유틸 함수를 하나 고쳤는데, 다른 레포에 반영하는 걸 까먹는다.

npm 패키지로 빼서 관리? 1인 개발자가 내부 패키지 버전 관리까지 하면 그것도 일이다.

모노레포로 하면 이런 문제가 사라진다.

 

공통 코드를 한 곳에서 관리하고, 모든 프로젝트가 그걸 바로 참조한다.

타입 하나 바꾸면 전체에 즉시 반영된다.

레포 하나만 관리하면 되니까, 관리 포인트가 확 줄어든다.

---

실제로 뭘 공유하고 있나

모노레포 툴은 Nx를 쓰고 있다.

모노레포 툴은 TurboRepo랑 Nx가 양대산맥인데, 나는 Nx를 선택했다.

 

TurboRepo는 설정이 간단하고 빌드가 빠르다. 설정 20줄이면 돌아간다는 말이 있을 정도.

근데 TurboRepo는 "빌드만 빠르게 돌려주는 도구"다. 프로젝트 구조나 아키텍처를 관리해주지는 않는다.

 

Nx는 설정이 좀 더 복잡하지만, 코드 제너레이터, 의존성 그래프 시각화, 아키텍처 규칙 강제 같은 기능이 있다.

나는 프론트엔드에 FSD(Feature-Sliced Design) 아키텍처를 쓰고, 백엔드(NestJS)에는 핵사고날(Hexagonal) 아키텍처를 쓰고 있다.

 

이런 아키텍처를 유지하려면 프로젝트 구조에 대한 규칙과 일관성이 중요하다.

Nx는 제너레이터로 일관된 구조를 만들어주고, 의존성 그래프로 어디서 뭘 참조하고 있는지 볼 수 있다.

혼자서 여러 프로젝트를 관리하면서 구조가 망가지지 않으려면, 이런 도구가 필요했다.

대략적인 구조는 이렇다.

monorepo/
├── apps/
│   ├── web/          # 회사 홈페이지 (Next.js, FSD 아키텍처)
│   ├── cms/          # 운영툴
│   ├── app-name/     # 운영툴 - 아직 출시를 못해서,,, 비공개다..
│   └── ...
├── libs/
│   ├── shared/       # 공통 유틸, axios 설정, 타입
│   ├── ui/           # 공통 컴포넌트
│   └── ...
└── ...

Nx의 기본 컨벤션은 packages/가 아니라 libs/다. (TurboRepo는 packages/를 쓴다.)

핵심은 libs/ 폴더다.

 

axios 설정을 공통으로 쓴다.

API를 호출하는 로직이 홈페이지에서도, 운영툴에서도, 앱에서도 필요하다.

이걸 각 프로젝트마다 따로 만들면 같은 코드를 3번 쓰는 거다.

모노레포에서는 libs/shared에 axios 인스턴스를 하나 만들어놓고, 각 앱에서 import해서 쓴다.

인터셉터, 에러 핸들링, 토큰 관리를 한 곳에서 관리할 수 있다.

 

공통 컴포넌트도 공유한다.

버튼, 모달, 인풋 같은 기본 컴포넌트를 매번 새로 만들 이유가 없다.

libs/ui에 만들어놓으면, 홈페이지에서도 운영툴에서도 그대로 쓸 수 있다.

디자인 일관성도 유지되고, 수정도 한 곳에서 하면 전체에 반영된다.

 

타입도 공유한다.

API 응답 타입을 libs/shared에 정의해놓으면, 프론트엔드 어디에서든 같은 타입을 참조한다.

타입 하나 바꾸면 전체 프로젝트에서 타입 에러가 뜨니까, 실수할 일이 줄어든다.

 

FSD 아키텍처와 모노레포의 궁합

각 앱(apps/web, apps/admin) 안에서는 FSD 아키텍처로 구성하고,

앱 간에 공유하는 코드는 libs/로 빼는 구조다.

FSD의 shared 레이어와 모노레포의 libs/가 자연스럽게 연결된다.

앱 고유의 feature는 각 앱 안에, 공통으로 쓰이는 건 libs/에. 이 구분이 명확해지니까 구조가 깔끔하게 유지된다.

---

혼자니까 더 필요하다

모노레포는 보통 큰 조직에서 쓰는 거라는 인식이 있다.

구글이 쓴다, 메타가 쓴다, 이런 이야기를 많이 들으니까. MFE도 많이 사용하고...

근데 나는 오히려 혼자니까 더 필요하다고 생각한다.

 

팀이 있으면 "야 이거 바꿨으니까 너도 반영해" 하고 말하면 된다.

혼자면? 아무도 안 알려준다. 까먹으면 버그다.

 

모노레포에서는 바꾸면 전체에 반영되니까, 까먹을 일이 없다.

물론 단점도 있다. 초기 설정이 멀티레포보다 복잡하다.

 

Nx 설정, 워크스페이스 설정, 빌드 설정... 처음에 세팅하는 데 시간이 좀 걸렸다.

TurboRepo였으면 15분 만에 끝났을 걸, Nx는 공식 문서를 몇 시간 읽으면서 설정했다.

FSD 아키텍처에 맞게 libs 구조를 잡는 것도 처음엔 고민이 많았다.

"이걸 libs/shared에 넣어야 하나, 앱 안에 둬야 하나?" 이런 경계를 정하는 게 은근 어려웠다.

근데 한 번 세팅해놓으면 그 위에 뭐든 올릴 수 있으니까, 초기 투자라고 생각했다.

https://nasapagym.com

https://namu.wiki/w/Nasapagym(%EB%82%98%EC%82%AC%EB%B9%A0%EC%A7%90)

Nasapagym(나사빠짐)

---

돌아보면

게임 출시 → 사업자 등록 → 워크스페이스 → 홈페이지 → 모노레포.

하나를 하면 다음 할 게 생기고, 그걸 하면 또 다음 할 게 생긴다.

게임 하나 만들었을 뿐인데, 어느새 인프라를 구축하고 있다.

 

근데 이게 1인 창업의 현실인 것 같다.

코드만 짜면 되는 게 아니라, 사업의 기반을 만드는 일도 해야 한다.

이메일, 홈페이지, 프로젝트 구조... 귀찮지만, 한 번 해놓으면 그 위에 뭐든 올릴 수 있다.

 

다음 편에서는 이 홈페이지를 실제로 어디에 어떻게 배포했는지 이야기하려고 한다.

처음에 AWS Amplify를 썼는데, 비용 때문에 Cloudflare로 갈아탄 이야기....

---

이번 편 요약

1. 홈페이지가 있으면 없을 때보다 41% 더 신뢰받는다는 조사 결과가 있다 — 느낌이 아니라 데이터다
2. FSD + 핵사고날 아키텍처를 유지하면서 여러 프로젝트를 관리하려면 Nx 기반 모노레포가 맞았다
3. 공통 axios, 컴포넌트, 타입을 libs/에서 관리하면 혼자서도 실수와 중복 작업이 확 줄어든다

---

여러분은 어떠신가요?

1인 개발자분들, 프로젝트 여러 개를 어떻게 관리하고 계신가요?

모노레포를 쓰고 계신 분들은 Nx vs TurboRepo 어떤 걸 쓰시는지, 그리고 프로젝트 내부 아키텍처(FSD, Clean Architecture 등)는 어떻게 잡고 계신지 궁금합니다. 댓글로 공유해주세요.

 

 

#모노레포 #Monorepo #Nx #FSD #핵사고날아키텍처 #1인개발 #인디개발자 #Nextjs #NestJS #개발자창업 #구글워크스페이스 #홈페이지신뢰도 #개발자인프라