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 확장성 한계에 부딪힌다고 함