# 모든 것을 코드로: 하나의 모노레포로 회사를 운영하는 방법

> Clean Markdown view of GeekNews topic #25477. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=25477](https://news.hada.io/topic?id=25477)
- GeekNews Markdown: [https://news.hada.io/topic/25477.md](https://news.hada.io/topic/25477.md)
- Type: GN+
- Author: [xguru](https://news.hada.io/@xguru)
- Published: 2026-01-01T09:12:44+09:00
- Updated: 2026-01-01T09:12:44+09:00
- Original source: [kasava.dev](https://www.kasava.dev/blog/everything-as-code-monorepo)
- Points: 3
- Comments: 1

## Topic Body

- **Kasava**는 제품 개발 전 과정을 하나의 **모노레포(monorepo)** 안에서 관리하며, 코드·문서·마케팅·운영 데이터를 모두 통합  
- 모든 변경이 **단일 커밋**으로 반영되어 백엔드, 프론트엔드, 웹사이트, 문서가 동시에 업데이트되는 구조  
- **AI 도구**가 코드·문서·웹사이트를 직접 참조해 일관성 검증, 자동 문서 갱신, 콘텐츠 검수 등을 수행  
- **CLAUDE.md**, **Selective CI/CD**, **독립 npm 프로젝트 구조** 등으로 대규모 저장소의 복잡성을 최소화  
- 이 접근은 **AI-네이티브 개발 문화**를 강화하며, 제품·콘텐츠·운영의 경계를 제거해 빠른 배포와 협업을 가능하게 함  

---

### AI-네이티브 개발과 모노레포의 의미
- Kasava는 모든 플랫폼 구성요소를 하나의 **Git 저장소**에 통합, 코드뿐 아니라 문서·마케팅·이메일·투자 자료까지 포함  
  - 예: `frontend/`, `backend/`, `website/`, `docs/`, `marketing/`, `external/` 등 5,470개 이상의 TypeScript 파일 구성  
- AI가 코드와 문서를 동시에 접근해 **맥락 기반 자동화**를 수행  
  - 문서 수정, 웹사이트 가격 변경, 블로그 검증 등이 AI의 단일 대화로 처리됨  
- 모든 변경은 동일한 **Git 워크플로우(`git push`)** 로 배포  
  - 코드, 콘텐츠, 문서, 마케팅이 동일한 리뷰·CI/CD·감사 절차를 거침  
- 이 방식은 **속도와 일관성**을 높이고, “모든 것을 코드로 관리”하는 문화를 정착시킴  

### 하나의 저장소로 통합하는 이유
- **경계 간 원자적 변경(Atomic Changes)**  
  - 백엔드 API 수정 시 프론트엔드 타입 정의와 문서가 같은 커밋에서 갱신  
  - 예: Asana 통합 기능 추가 시 백엔드·프론트엔드·문서·웹사이트가 한 PR로 병합  
- **단일 진실의 원천(Single Source of Truth)**  
  - `billing-plans.json` 하나로 요금제 제한을 정의, 모든 서비스가 이를 참조  
  - AI가 백엔드·프론트엔드·웹사이트 간 일관성을 자동 검증  
- **크로스 프로젝트 리팩터링**  
  - IDE에서 전체 코드·문서·블로그 예시까지 검색·수정 가능  
- **공유 도구와 파이프라인**  
  - 공통 CI/CD, 의존성, 검색 환경으로 관리 단순화  

### 저장소 구조와 구성 요소
- **Core Application**:  
  - `frontend/`는 Next.js 16 + React 19 기반, `backend/`는 Cloudflare Workers + Hono + Mastra 사용  
  - API 변경 시 타입 안정성과 테스트 유틸리티 공유  
- **Marketing**:  
  - `website/`, `marketing/blogs/`, `investor-deck/`, `email/` 포함  
  - 블로그·이메일·투자 자료 모두 코드로 버전 관리, `git revert`로 롤백 가능  
- **Documentation**:  
  - `docs/`는 Mintlify 기반 공개 문서, `docs-internal/`은 내부 아키텍처 문서  
  - 코드와 함께 검색 가능, 위키 대신 실시간 최신 정보 유지  
- **External Services**:  
  - Chrome 확장, Google Docs Add-on, GCP Functions 등 외부 배포 서비스 포함  
  - API 계약 공유로 변경 시 동시 반영  
- **Development Infrastructure**:  
  - `github-simulator/`, `infra-tester/`, `scripts/` 등 로컬 개발용 모의 서버 및 테스트 도구 포함  

### 운영 방식과 개발 문화
- **워크스페이스 미사용**  
  - 각 디렉터리를 독립 npm 프로젝트로 유지, 의존성 충돌 방지  
- **선택적 CI/CD(Selective CI/CD)**  
  - GitHub Actions가 경로 기반으로 트리거되어 관련 테스트만 실행  
- **CLAUDE.md 규칙**  
  - 각 주요 디렉터리에 기술 스택, 명령어, 아키텍처 결정을 문서화  
  - AI 도우미가 이를 읽어 프로젝트 맥락을 이해  
- **일관된 도구 설정**  
  - `.prettierrc`, `.eslintrc`, `tsconfig.json` 등 공통 설정 유지  

### 도전 과제와 대응
- **저장소 크기**: 현재 클론 시간 약 20초, Git 성능 문제 없음  
  - 대용량 자산은 R2/S3로 분리 예정  
- **빌드 시간**: 각 프로젝트 독립 빌드, Turbopack·Wrangler·WXT로 빠른 재빌드  
- **권한 경계**: 소규모 팀은 전체 접근 가능, 필요 시 CODEOWNERS·브랜치 보호 적용 가능  
- **맥락 전환**: 다양한 언어(TypeScript, Apps Script, MJML) 간 전환은 CLAUDE.md와 통일된 포맷으로 완화  

### 결론
- Kasava의 모노레포는 단순한 트렌드가 아니라 **맥락 통합을 통한 생산성 극대화 도구**  
- 백엔드·프론트엔드·문서·마케팅이 하나의 변경으로 동작하며, **AI가 이를 실시간 검증**  
- 결과적으로 “모노레포는 제약이 아니라 **가속 장치(force multiplier)** ”로 기능함

## Comments



### Comment 48538

- Author: neo
- Created: 2026-01-01T09:12:44+09:00
- Points: 2

###### [Hacker News 의견들](https://news.ycombinator.com/item?id=46437381)   
- 이건 회사 전체를 관리하는 게 아니라 그냥 **하나의 제품(monorepo)** 정도로 보임  
  재무, HR, 계약서, 팀 사진 같은 건 없고, 단지 프론트엔드+백엔드 구조에 마케팅 폴더가 조금 특이하게 포함된 수준임  
  - 링크된 글을 보면 이 회사는 사실상 **1인 기업**임을 알 수 있음  
    그래서 모든 게 하나의 repo에 들어가는 게 가능하지만, 그런 상황에서 얻을 수 있는 “인사이트”의 가치에는 의문이 생김  
  - “AI! AI!”  
  - repo 안에 **인프라 코드(IaC)** 도 포함되어 있지 않음  
  - 나는 진짜 모든 걸 GitHub repo 안에 넣은 사례를 보고 싶음  
    예를 들어 **암호화된 아티팩트**까지 포함해서 “암호키만 CEO가 물리적으로 보유”하는 식으로 말임  
    GitHub이 private folder 개념을 추가하면 좋겠지만, 그건 ACL 문제라 너무 과한 요구일 수도 있음  
  
- 나는 **monorepo와 no development branch** 철학을 지지함  
  하지만 개발과 릴리스는 구분되어야 함  
  안정적인 릴리스를 잘라서 cherry-pick할 수 있어야 하고, 프론트엔드와 백엔드 간 **API 안정성**은 반드시 유지해야 함  
  - “no development branch”가 무슨 뜻인지 묻는 사람도 있었음  
    메인 브랜치에서 직접 개발한다면, 다양한 규모의 작업을 어떻게 병행 관리하는지 궁금하다고 함  
  - cherry-pick이 필요한 구체적 사례를 묻는 사람도 있었음  
    자신은 3개 이상의 제품을 monorepo로 운영 중인데, 안정 릴리스 단위로 배포해도 문제 없었다고 함  
  - 어떤 사람은 **feature flag**로 배포 시점을 제어한다고 함  
  - 다른 사람은 오래된 브랜치를 유지하는 걸 좋아함  
    git squash를 싫어하고, **forking 방식**이 개발자에게 더 자유로운 환경을 준다고 말함  
  
- “한 번의 변경으로 모든 곳이 동시에 업데이트된다”는 말은 **위험한 환상**임  
  DB나 API가 있는 시스템에서는 항상 **하위 호환성**을 고려해야 함  
  여러 팀이 있는 조직에서는 한 팀이 업그레이드를 검증하지 못해 전체가 발목 잡히는 경우가 생김  
  그래서 점진적 롤아웃이 필수임  
  - 완전히 동의함. 작은 회사(Kasava)에서는 괜찮지만, 글로벌 SaaS에서는 **다운타임 몇 분**도 치명적임  
    monorepo 자체는 나쁘지 않지만, “한 번의 변경으로 모든 게 즉시 배포된다”는 건 불가능함  
    DB 스키마와 코드가 동시에 바뀔 수 없기 때문임  
    이런 글은 **AI가 쓴 블로그**처럼 보이고, 실제 고객도 거의 없을 것 같음  
  - 코드 저장 위치(repo)와 배포 방식은 분리되어야 한다는 반론도 있었음  
    조직 문제를 기술 문제로 착각하지 말고, **팀 간 정책과 리더십**으로 조율해야 한다고 함  
  - 어떤 사람은 monorepo와 **자동 코드 생성(openapi-generator)** 을 활용해 서비스 간 API 변경을 즉시 반영한다고 함  
    작은 팀이라 가능한 접근이라고 덧붙임  
  - “AI 컨텍스트를 한곳에 모으는 게 강점”이라는 말에, 여러 repo를 **workspace로 클론**하면 된다는 의견도 있었음  
  - 반대로, 모든 서비스가 각자 버전을 유지하며 업데이트하지 않는 상황이 더 나쁘다는 의견도 있었음  
  
- 예전엔 monorepo를 싫어했지만, **Claude Code**를 쓰면서 생각이 바뀌었음  
  프론트엔드와 백엔드가 한 repo에 있으면 동기화가 쉬움  
  - 부모 디렉토리에서 Claude를 열어도 잘 되지만, **단일 커밋으로 양쪽을 동시에 변경**할 수 있다는 점이 좋다고 함  
  - “monorepo를 쓰는 이유가 단순히 명령어 플래그를 줄이기 위한 거라면 좀 웃기다”는 반응도 있었음  
  - 나도 여러 **LLM 툴**을 연결하기 힘들어서 monorepo로 리팩터링했음  
  - React Native의 **hoisting 문제** 때문에 yarn workspace는 피하지만, PRD나 계획 문서를 repo에 넣는 건 AI 맥락 제공에 유용했음  
  - Claude Code는 사실 여러 디렉토리를 동시에 다룰 수 있어서 monorepo가 꼭 필요한 건 아님  
  
- 이 글은 **AI가 쓴 것처럼** 느껴짐  
  인간이 쓴 콘텐츠를 찾기 힘들어 피로함  
  - GPTZero로 돌려보면 거의 전부 AI 생성으로 보임  
    “This isn’t just for…”, “The Challenges (And How We Handle Them)” 같은 문장은 전형적인 **AI 어투**임  
  - 반대로, “AI 글이라고 불평하는 것도 지겹다”는 의견도 있었음  
    완벽하지 않아도 인간이 쓴 글보다 낫지 않냐는 식임  
  
- “Claude에게 가격 페이지를 업데이트하라”고 시킨다는 부분이 이상함  
  마케팅 페이지를 같은 repo에서 관리하면서, 단순히 **config 파일의 데이터**를 읽으면 될 일을 LLM에게 맡긴다는 게 납득되지 않음  
  - AI가 **중독이나 의존**으로 변하고 있다는 지적이 있었음  
  - “코드 리뷰는 여전히 존재한다”는 반박도 있었음  
    AI가 있다고 해서 사람이 검토하지 않는 건 아니라는 말임  
  
- “프론트엔드, 백엔드, 웹사이트”를 한 repo에 넣는 게 혼란스러움  
  커밋 단위 통합은 좋아 보이지만, **3개의 repo로도 충분히 관리 가능**함  
  monorepo를 제대로 운영하려면 **유지비용이 상당함**  
  
- 글은 AI가 쓴 것 같지만, **IaC를 극단적으로 확장한 아이디어** 자체는 흥미로움  
  그래서 감정이 복잡함  
  - 대부분의 댓글이 AI 작성 티를 못 알아본 게 신기함  
    앞으로 이런 **LLM 스타일**이 대중에게 익숙해지면, 지금의 글들은 촌스럽게 느껴질 것 같음  
  - “Why This Matters” 같은 표현만이라도 바꿨으면 좋겠다는 의견도 있었음  
  - AI 사용을 명시하지 않고 인간 이름으로 올리는 건 **지적 불성실**처럼 느껴진다는 말도 있었음  
  
- 회사 웹사이트를 같은 repo에 두면 **브랜딩 자료와 톤**을 쉽게 찾을 수 있음  
  그래서 고객용 슬라이드나 데모 영상을 자동 생성하기 좋음  
  나아가 **문서, 버그, 이슈**까지 한곳에 넣는 것도 흥미로움  
  
- 예전 스타트업 **Pangea**에서 비슷한 구조를 만들었음  
  전반적으로는 좋았지만 완벽하진 않았음  
  - 모든 걸 repo로 관리하려다 보니 **feature flag 변경**이 느리고, 브랜치 불변성 관리가 어려웠음  
  - 서비스가 20개쯤 되자 **GitLab CI가 느려지고 복잡해짐**  
  - **E2E 테스트**가 느리고 불안정해 파이프라인이 자주 깨졌음  
  그래도 ARM으로 전환해 **컴퓨팅 비용 70% 절감** 같은 성과도 있었음  
  [Pangea 링크](https://pangea.cloud/)  
  - 이에 대해 “**turbo, buck, Bazel** 같은 monorepo 툴을 썼는지” 묻는 사람도 있었음  
    이런 툴 없이는 CI 확장성 한계에 부딪힌다고 함