▲

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

 (kasava.dev)
2P by GN⁺ 6일전 | ★ favorite | 댓글 1개
  • 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) ”로 기능함
▲
GN⁺ 6일전  [-]
Hacker News 의견들

  • 이건 회사 전체를 관리하는 게 아니라 그냥 하나의 제품(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 링크
    • 이에 대해 “turbo, buck, Bazel 같은 monorepo 툴을 썼는지” 묻는 사람도 있었음
      이런 툴 없이는 CI 확장성 한계에 부딪힌다고 함
답변달기