mrlatte.net은 어떻게 혼자 18개 서비스를 운영하는가 — 서비스 페이지에 적힌 구조 그대로

1. 핵심 요약

이해관계를 먼저 밝힙니다. 이 글을 발행하는 이즐러(Eazler)는 mrlatte.net 운영자가 2015년 8월부터 2016년 12월까지 임원 겸 개발자로 일했다고 소개 페이지에 적은 회사입니다 [2]. 이 글은 운영자에게 묻지 않고 공개된 페이지만으로 썼고, 운영자의 검토를 거치지 않았습니다.

용어를 정합니다. 정적 사이트 생성(SSG)은 요청이 올 때 서버가 페이지를 만드는 대신, 빌드 시점에 HTML 파일을 미리 만들어 두는 방식입니다. Firestore는 Google Firebase의 문서형 데이터베이스이고, 한 프로젝트 안에 이름을 붙인 데이터베이스를 여러 개 둘 수 있습니다. Firebase Hosting은 정적 파일을, Firebase App Hosting은 서버 렌더링이 필요한 앱을 배포하는 서비스입니다. 크래딧은 이 패밀리에서 유료 기능을 여는 데 쓰는 공용 포인트이며, 운영자의 표기(크래딧)를 그대로 따릅니다.

이 글의 수치와 인용은 mrlatte.net의 페이지에 적힌 값 그대로이며, 응답 헤더와 HTML 흔적은 이 글이 2026-09-19에 직접 확인한 것입니다. 자체 성능 측정은 없습니다.

2. 무엇을 운영하나 — 18개 서비스 전체

mrlatte.net의 서비스 목록 페이지 [1]에 실린 18개입니다. 소개 페이지의 첫 문단을 한 줄로 줄였고, 언어와 수익 장치는 각 페이지에 적힌 것만 옮겼습니다. 이름을 누르면 실제 서비스로, 소개 링크를 누르면 mrlatte.net의 소개 페이지로 갑니다.

18개 중 16개가 "운영 중", Pawtelier와 ToonBooth 두 모바일 앱은 "아카이브"로 표시돼 있어 링크를 소개 페이지로만 걸었습니다. Weple은 제품이 아니라 외주 창구이지만 운영자가 18개에 넣어 세므로 그대로 두었습니다. 언어 열의 "hreflang 기준"은 소개 페이지에 언어 목록이 없어, 이 글이 실제 서비스의 hreflang 태그를 보고 확인했다는 뜻입니다.

3. 인프라는 한 벌 — 같은 Firebase 위에 서비스별 데이터베이스

스택은 Weple 페이지가 한 문장으로 밝힙니다. "18개 서비스를 직접 만들고 운영하며 검증한 스택(Astro/React/Firebase/Expo)" [4]. 개별 서비스 페이지의 "현재 상태와 운영 신호" 절은 더 구체적입니다.

여섯 페이지가 같은 방향을 가리킵니다. 인프라를 밝힌 여섯 서비스가 모두 Firebase이고, Libsac과 DeepThought 두 페이지는 프로젝트 이름 mrlatte를 명시합니다. 나머지 서비스가 같은 프로젝트에 있는지는 페이지에 없어 이 글의 추정입니다. 공통점은 서비스마다 이름 붙은 Firestore 데이터베이스와 호스팅 사이트를 하나씩 받는다는 것입니다. 정적으로 충분한 서비스는 Firebase Hosting에, 로그인 뒤 상태가 필요한 서비스는 App Hosting에 올립니다. 배포는 GitHub Actions입니다. 새 서비스를 하나 더 내는 일이 "새 인프라를 세우는 일"이 아니라 "같은 틀에 데이터베이스와 사이트를 하나 더 붙이는 일"이 됩니다.

이 글이 응답 헤더로 확인한 것도 그 방향과 맞습니다. 라이브 도메인 17곳 중 12곳은 server: envoy와 via: 1.1 google을 돌려줬습니다. 나머지 5곳은 Fastly 계열 캐시 헤더(x-served-by: cache-icn…)를 돌려줬습니다. mrlatte.net, startupxo.com, reputo.net, bunn.kr, theweple.com입니다. 페이지가 "Firebase Hosting 정적 지면"이라고 적은 StartupXO와 Reputo가 후자, "App Hosting"이라고 적은 Typdit와 DeepThought가 전자에 속합니다. 두 헤더 무늬가 Firebase Hosting과 App Hosting을 그대로 가리키는지는 이 글의 추정이며, 페이지의 진술과 어긋나는 곳은 없었습니다. HTML에서는 6개 사이트에 Astro island 마크업이 있었고, Forkarium에는 Next.js를 쓴 흔적이 있었습니다.

4. 정적 우선 — 서버 대신 새벽 스케줄러

서비스 페이지들이 가장 자주 쓰는 말은 "정적"입니다. 이 글이 18장의 본문을 저장해 세었을 때 50회였습니다. 서버가 요청마다 일하는 대신, 데이터를 빌드 시점에 HTML에 심어 두고 하루에 한 번 다시 짓습니다. Libsac 페이지가 그 이유와 구조를 함께 적었습니다.

같은 원칙이 다른 서비스에도 있습니다. StartupXO는 "서버 없는 검색"이라고 적었습니다. "빌드 과정에서 지면에 심어 둔 데이터를 브라우저에서 검색해 뉴스와 아이디어, 인재를 한 번에 찾습니다" [7]. DeepThought의 발행본은 미리 렌더링한 정적 페이지와 사이트맵으로 검색엔진에 색인되며, 페이지의 표현으로 "패밀리 AI/테크 인사이트의 비주얼 목차 겸 내부 SEO 허브"로 쓰입니다 [8]. Reputo는 "포기한 것"에 "실시간 추천 / 알고리즘 피드(정적 사이트 강점 유지)"를 올렸습니다 [9].

정적 우선은 다국어와 짝을 이룹니다. 언어를 서버에서 고르는 대신 /ko /en /ja /zh처럼 경로로 나누고, 빌드가 언어 파일을 검사합니다. Reputo는 "어떤 페이지든 다섯 언어 파일이 모두 있어야 빌드를 통과합니다"라고 적었습니다 [9]. 이 글이 확인한 hreflang 태그는 GameSnapshots·Bessatsu가 5개, DeepThought가 5개(중국어 표기 중복 포함), DoYouBox가 5개, Weple이 9개였습니다. 반대로 Libsac은 "이벤트, 공모전, 공연이 국내 정보라 다국어, 언어 선택기를 의도적으로 두지 않음"이라고 적었습니다 [5]. 다국어가 기본이지만 원칙보다 대상이 먼저입니다.

5. AI는 생산과 판정에 — 화면에 나갈 문장은 사람이 검수한다

소개 페이지는 "AI를 목적에 맞게 씁니다. 유행이라서가 아니라 실제 사용자 가치를 높일 때"라고 적었습니다 [2]. 서비스 페이지에서 그 말이 어떻게 구현됐는지 보면 두 가지 역할로 갈립니다. 하나는 다국어 리포트처럼 사람이 직접 쓸 수 없는 규모의 생산 파이프라인이고, 이때는 운영자의 검수가 뒤에 붙습니다. 다른 하나는 화면에 나갈 문장을 만들지 않는 판정기입니다. 사용자와 만나는 편집기 안에는 AI를 두지 않습니다.

두 사례가 방향을 보여 줍니다. StartupXO의 회고에는 "다시 한다면: 아이디어를 자동 생성으로 시작한 점이 아쉽습니다. 양은 늘었지만 읽을 이유가 약했고"라고 적혀 있습니다 [7]. DeepThought는 "빈 캔버스를 채우는 문제를 AI가 아니라 읽을 만한 발행본으로 풀어서, 에디터가 다시 살아났음"이라고 적고, 에디터에 붙였던 AI를 뗀 것을 "다시 한다면"에 올렸습니다 [8]. 열여덟 개를 굴리는 사람이 AI를 어디서나 더 쓰는 쪽이 아니라, 사용자가 직접 만지는 자리에서는 빼는 쪽으로 움직였습니다. 남긴 자리는 검수가 뒤에 붙는 대량 생산과, 번역·정규화·판정·검증처럼 틀린 것을 기계적으로 잡을 수 있는 곳입니다.

모델 선택도 실용적입니다. Reputo는 "자체 LLM 호스팅(외부 API가 비용 / 품질 모두 우위)"을 포기 목록에 올렸고 [9], Libsac은 정규화에 가장 싼 축의 모델을 씁니다 [5]. 이 블로그가 앞서 정리한 판정 전용 모델의 논리와 같은 맥락입니다. 답의 형태가 정해진 일에는 큰 모델이 필요 없습니다.

6. 서로를 먹여 살리는 패밀리 — 공용 계정, 크래딧, 교차 링크

페이지들은 열여덟 개를 "Mr. Latte 패밀리"라고 부릅니다(같은 방식으로 세어 8회). 이름만이 아니라 세 가지가 공유된다고 적혀 있습니다.

• 공용 계정과 결제 허브. BootSignal의 결제는 "Polar로 받고, 결제창은 accounts.mrlatte.net을 거칩니다" [6]. Typdit의 상위 티어도 "패밀리 공용 계정 허브를 경유해 외부 결제 제공자의 구독 상품으로 처리하고, 웹훅이 서비스별 사용자 문서의 플랜 필드를 갱신합니다. 결제 인프라를 새로 만들지 않고 이미 있는 것을 재사용했습니다" [13]. 결제 알림을 받은 웹훅이 각 서비스의 사용자 문서에서 요금제 필드를 바꾼다는 뜻입니다. BootSignal은 "별도의 빌드나 백엔드 없이 로그인(공유 Google 계정), 저장, 다국어 기능"을 쓴다고 적었습니다 [6]. 이 글이 확인한 2026-09-19 기준 accounts.mrlatte.net은 200을 돌려줍니다.
• 공유 크래딧 경제. DeepThought는 "공유 크래딧 경제는 mrlatte 패밀리 전반과 연동됩니다"라고 적었습니다 [8]. InverseOne은 종목 언락 과금을 붙이면서 "게임 흐름의 결제 코드를 재사용(신규 결제 코드 없음)"이라고 적었습니다 [14]. GameSnapshots·Bunnkr·Libsac·ToonBooth 페이지에도 크래딧이 나옵니다. 크래딧을 쓰는 서비스들이 지갑 하나를 나눠 쓰는 셈이며, Weple처럼 크래딧과 무관한 서비스도 있습니다.
• 교차 링크와 역할 분담. DoYouBox의 수익 장치에 "테스트 흐름에서 관련 서비스(패밀리 포함)로의 자연스러운 연결"이 있고 [15], DeepThought는 "패밀리(특히 startupxo) 인사이트로의 내부 유도"를 모니터링 지표로 둡니다 [8]. Out of Stealth에 있던 AI 프롬프트 마켓은 BootSignal로 분리·이전됐습니다 [10]. 이 글이 라이브 HTML을 훑었을 때 17개 도메인 중 8곳에서 BootSignal이, 8곳에서 mrlatte가 언급됐습니다.

수익 모델도 한 줄로 통일돼 있습니다. 읽기는 무료, 계정에 남는 도구만 유료. StartupXO는 "읽기를 잠그면 이 사이트가 존재하는 이유가 사라집니다"라고 적었고 [7], Reputo는 "읽기 페이월(SEO 퍼널과 제휴 수익이 무료 리포트에서 나옴)"을 포기 목록에 올렸습니다 [9]. BootSignal은 요금이 하나뿐이고 "구독 여부는 위젯 이름이 아니라 만료일만 확인하므로 카탈로그가 늘어나도 요금이 따로 붙지 않습니다" [6]. 가격표를 관리하는 일 자체를 없앤 설계입니다.

7. 재편을 기록한다 — 잘 된 것, 다시 한다면, 포기한 것

열여덟 페이지의 형식이 같습니다. 포지셔닝, 시장과 문제 정의, 핵심 타깃, 가치 제안, 수익, 현재 상태와 운영 신호, 회고와 다음 가설. 특히 "잘 작동한 것 / 다시 한다면 / 포기한 것" 세 칸이 서비스마다 채워져 있고, 결정에는 날짜가 붙습니다. 2026년 한 해 동안 기록된 재편만 추려도 이렇습니다.

회고에는 실패도 적혀 있습니다. Typdit의 "다시 한다면"은 "서비스 성격을 바꿀 때 지면 정리와 신규 지면 발행을 같은 순서로 묶었을 것입니다. 컷오버 직후 남은 구 지면이 검색 결과와 내부 링크에서 잠시 어긋났습니다"입니다 [13]. 운영자의 2026-09-01 블로그 글은 이 습관의 뿌리를 보여 줍니다. 하루를 "롤백이 없는 배포"라 부르며, "무엇이 바뀌었는지 커밋 메시지처럼 남기라"고 적었습니다 [3]. 열여덟 개를 굴리는 사람이 기억에 의존하지 않고 문서에 의존한다는 뜻입니다. 그리고 그 문서가 공개돼 있어서 이 글이 가능했습니다.

8. 1인 스튜디오가 오늘 가져갈 것

• 두 번째 서비스를 내기 전에 첫 서비스의 틀을 뽑습니다. 프로젝트 하나, 서비스별 데이터베이스와 사이트, 같은 배포 파이프라인. 두 번째가 "인프라 없이" 나갈 수 있어야 세 번째가 있습니다.
• 정적 파일로 제공할 수 있는 것은 정적 파일로 둡니다. 하루 한 번 갱신으로 충분한 정보는 새벽 스케줄러로 다시 짓습니다. 서버가 없으면 장애 대응도 없습니다. Reputo처럼 "실시간 피드"를 포기 목록에 올려 두면 기능 요청이 와도 흔들리지 않습니다.
• AI는 검수가 붙는 자리에만 둡니다. 대량 생산에는 검수 단계를, 판정에는 번역·정규화·분류·누락 검사처럼 틀리면 기계적으로 잡히는 일을 맡깁니다. 사용자가 직접 만지는 편집기 안에는 두지 않습니다.
• 빌드가 완성도를 검사하게 합니다. 다섯 언어 파일이 다 있어야 통과하는 빌드는 사람의 기억보다 믿을 만합니다.
• 계정·결제·포인트는 한 번만 만듭니다. 서비스마다 결제를 새로 붙이지 않고 허브를 경유합니다. 요금은 가능하면 하나로, 만료일만 확인하는 구조로 둡니다.
• 읽기는 열고 도구만 팝니다. 검색 유입이 무료 지면에서 나오는 서비스라면 페이월이 유입을 끊습니다.
• 서비스마다 "잘 된 것 / 다시 한다면 / 포기한 것"을 날짜와 함께 적습니다. 재편할 때 어디까지 지워도 되는지가 거기서 나옵니다. 공개해 두면 외주 견적과 채용 대화에서도 쓰입니다.
• 패밀리를 만들려면 이름보다 지갑을 먼저 공유합니다. 교차 링크는 나중에도 붙일 수 있지만, 크래딧과 계정을 나중에 합치는 일은 마이그레이션입니다.

9. 아직 결론이 아닌 것

• 근거는 전부 운영자가 쓴 페이지입니다. 인프라·자동화·회고는 운영자의 자기 기술이며, 코드나 대시보드로 확인한 것이 아닙니다. 이 글이 독립적으로 확인한 것은 응답 헤더, HTML 흔적, hreflang 태그, 도메인 응답 여부뿐입니다.
• 성과 수치가 없습니다. 트래픽, 매출, 구독자, 투입 시간이 어느 페이지에도 없습니다. 이 글은 "어떻게 굴리는가"를 정리했을 뿐 "잘 굴러가는가"는 판단하지 않습니다.
• 정말 혼자인지는 확인하지 못했습니다. 제목의 "혼자"는 운영자의 소개를 따른 것입니다. Libsac·Reputo 페이지는 "1인 운영"이라고 적었지만, Weple 페이지는 "작은 팀"이라는 표현도 씁니다. 외주 협업이 얼마나 섞였는지는 알 수 없습니다.
• 호스팅 추정은 헤더 무늬에서 나온 것입니다. Fastly 계열 헤더를 Firebase Hosting으로, Google 프런트엔드 헤더를 App Hosting으로 읽었고 페이지의 진술과 어긋나지 않았지만, 헤더만으로 확정되는 것은 아닙니다.
• 출시일은 페이지 날짜와 본문 날짜가 섞여 있습니다. 세 서비스의 페이지 날짜가 2024-01-01로 동일해 실제 출시일로 쓰지 않았습니다. 표의 "시작"은 본문에 적힌 것만 옮겼습니다.
• 이해관계가 있습니다. 운영자는 2015~2016년 이 블로그의 발행사 이즐러에서 일했습니다. 이 글은 운영자에게 묻지 않았고, 발행 전 검토도 받지 않았습니다.
• 페이지는 자주 바뀝니다. 2026년에만 재편이 일곱 건 기록돼 있습니다. 이 글의 인용은 2026-09-19 시점의 문구이며, 링크의 내용은 달라질 수 있습니다.
• 일반화의 한계. 이 구조는 콘텐츠·큐레이션·도구형 서비스에 맞춰져 있습니다. 실시간 협업이 필요하거나 트랜잭션 처리량이 많은 서비스에 같은 틀이 맞는다는 근거는 없습니다. 운영자 자신도 DeepThought에서 "실시간 협업"을 포기 목록에 올렸습니다.

10. 참고자료

모두 2026-09-19 확인했습니다. [1]~[15]는 운영자가 자기 서비스를 설명한 mrlatte.net 페이지라 이해관계가 있습니다. 응답 헤더와 HTML 흔적은 이 글이 직접 확인했습니다.

편집 기준: 운영자의 자기 기술과 이 글의 직접 확인을 표마다 구분했고, 성과를 말하는 문장은 쓰지 않았습니다. 발행사와 운영자의 과거 관계를 본문 첫머리에 밝혔습니다.