standarda 생태계

standarda · standarda-core · standarda-template · standarda-devtools, 이 네 폴더가 각각 무엇이고, 어떻게 맞물려 프로젝트를 만드는지 이 챕터에서 다룹니다. 이번 강의는 그 출발점으로, 왜 이런 구조인지부터 짚습니다.

이 챕터를 마치면

• 이 구조가 왜 '집단지성'을 가능하게 하는지, 그리고 왜 저절로는 안 되는지 안다
• 네 폴더의 계층(도구·재료 vs 결과물)을 한 문장으로 설명할 수 있다
• template 은 왜 '복사'하고 core 는 왜 '설치'하는지 안다
• core 를 자동 업데이트하지 않는 이유와 그 대가를 안다
• devtools 가 왜 별도 repo 인지, 프로젝트 하나가 어떻게 태어나고 사라지는지 안다

대상은 standarda 구조를 처음 접하는 팀원(비개발자 포함)입니다. 위에서 아래로 순서대로, 개념을 하나씩 쌓아 올리도록 배치했습니다.

우리 팀은 비슷하게 생긴 AI 프로젝트를 여러 개 만듭니다. 겉보기엔 달라도 속을 열어 보면 똑같은 것을 반복합니다.

• 로그인·회원가입 화면 (거의 모든 서비스가 필요)
• PDF·엑셀 문서를 읽어 AI 에 넘기는 코드
• 구글 시트·메일·드라이브 연동
• 서버 설정, 배포 방식, 폴더 구조

이걸 프로젝트마다 처음부터 만들면 두 가지 문제가 생깁니다.

• 낭비: 같은 로그인 화면을 5번 만든다.
• 제각각: 5명이 각자 만들면 5개가 조금씩 다르다. 나중에 "이 프로젝트는 왜 저 프로젝트랑 구조가 다르지?" 하는 혼란.

그래서 팀은 "매번 반복되는 것"을 성격별로 세 묶음으로 분리해 두었습니다. 그리고 그 세 묶음으로 찍어낸 실제 제품들이 따로 있습니다.

앞의 두 문제(낭비·제각각)는 '손해를 막는' 이야기입니다. 그런데 이 구조에는 그보다 훨씬 큰 이득이 하나 더 있습니다. 이게 진짜 이유에 가깝습니다.

한 사람의 배움이 팀 전체의 자산이 됩니다.

예를 들어 PDF 읽는 코드를 사흘에 걸쳐 훨씬 정확하게 개선했다고 가정해 보겠습니다.

• 복사·붙여넣기 방식 (배움이 증발한다): 개선은 내 프로젝트 안에서 끝납니다. 옆 프로젝트는 옛 코드를 그대로 쓰고, 그런 개선이 있었다는 사실조차 모릅니다. 반년 뒤 다른 팀원이 같은 문제에 같은 사흘을 다시 씁니다.
• 분리 구조 (배움이 쌓인다): core 에 올리면 이후 설치하는 모든 프로젝트가 그 사흘치 개선을 그대로 받습니다. 내가 사흘 걸려 알아낸 것이 팀원에게는 import 한 줄이 되고, changelog 에 '왜 이렇게 했는지'까지 남아 맥락도 함께 전달됩니다.

배운 것의 성격에 따라 흘려보내는 곳이 다릅니다. 앞으로 배울 네 폴더는 그래서 단순한 코드 보관함이 아니라, 각기 다른 배움이 모이는 통로입니다.

마지막 줄이 특히 중요합니다. 코드만 공유하면 '무엇'만 전해지고, 기록까지 공유해야 '왜'가 전해집니다. 그래서 changelog 에 "이건 어느 프로젝트에서 필요해 만들어졌다"는 한 줄을 남깁니다.

팀원 5명이 각자 한 달에 재사용할 부품 1개씩 만든다고 하면:

복사 방식:  한 달 뒤 내가 가진 부품 = 1개  (내가 만든 것뿐)
분리 구조:  한 달 뒤 내가 가진 부품 = 5개  (팀 전체가 만든 것)

1년 뒤 →   복사 방식: 12개  /  분리 구조: 60개

차이는 더하기가 아니라 곱하기로 벌어집니다. 가장 큰 수혜자는 새로 합류한 사람입니다. 첫날부터 팀이 쌓아 온 부품을 전부 갖고 출발하기 때문입니다. 맨바닥이 아니라 팀이 이미 쌓아 온 것 위에서 시작하는 셈입니다.

그래서 이 구조는 '통제'가 아니라 '협업'에 가깝습니다. 내 코드를 core 에 올리는 것은 관리받는 게 아니라, 내 사흘이 동료의 사흘을 아껴 주는 일입니다. 반대로 지금 내가 편하게 쓰는 부품들도 누군가 먼저 만들어 올려둔 것입니다.

단, 저절로 되지는 않습니다. 구조는 통로를 열어 둘 뿐이고, 실제로 배움이 흐르게 하는 것은 사람의 행동입니다. 올리는 쪽은 core 승격 PR 과 changelog 를 남기고, 받는 쪽은 새로 만들기 전에 카탈로그와 changelog 를 먼저 확인해야 합니다. 둘 중 하나만 빠져도 통로는 막힙니다.

이 챕터 전체를 관통하는 열쇠는 두 가지입니다.

• ① 방어: 반복을 줄이고 일관성을 지킨다 (손해를 막는다)
• ② 성장: 한 사람의 배움을 팀 전체로 흘려보낸다 (집단지성)

앞으로 나오는 모든 설계 결정은 이 둘 중 하나에서 나옵니다. 어떤 결정을 만나면 "이건 방어인가, 성장인가?"를 물어보세요.

• 핵심 정리: 팀은 반복되는 것을 성격별로 세 묶음(core·template·devtools)으로 분리해 두었습니다. 목적은 두 가지, 방어(낭비·제각각 방지)와 성장(한 사람의 배움이 팀 전체로 흐르는 집단지성)입니다. 다만 통로가 열려 있어도, 올리고 찾아보는 사람의 행동이 있어야 흐릅니다.
• 다음 시간: 네 폴더의 아키텍처: 무엇이 '도구·재료'이고 무엇이 '결과물'인지 계층을 봅니다.

큰 그림을 프랜차이즈(체인점) 사업에 비유해 봅니다. 본사가 여러 매장을 여는 상황입니다.

앞의 셋은 "만드는 데 쓰는 것"(도구·재료)이고, 마지막 standarda 는 그것들로 "만들어진 결과물"입니다. 성격이 근본적으로 다릅니다.

즉 standarda 를 비롯한 여러 제품은 모두 같은 재료·도구로 찍어낸 형제 프로젝트입니다.

아닙니다. 이름 앞에 다 standarda 가 붙어 한 집안처럼 보이지만, 계층이 다릅니다.

• standarda-core·standarda-template·standarda-devtools (접두어 있음) = 공용 인프라(도구·재료)
• standarda (접두어 없음) = 그 인프라로 만들어진 제품 하나. 다른 제품들과 형제.

특히 헷갈리는 지점이 하나 있습니다. standarda 폴더 안에는 팀 공용 venv(가상환경)도 함께 얹혀 있어, 팀원들이 source ~/standarda/bin/activate 로 이 폴더의 venv 를 빌려 씁니다. 이렇게 공용 개발환경 역할까지 겸하다 보니 특별해 보이지만, 프로젝트로서의 정체성은 다른 제품들과 완전히 동등합니다. (venv 가 여기 얹힌 것은 역사적 사정이며, venv 가 무엇인지는 core 편에서 다룹니다.)

• 핵심 정리: template(표준 양식)·core(공통 기능)·devtools(자동화 도구)는 만드는 도구·재료이고, standarda 는 그것들로 만들어진 결과물(제품)입니다. 접두어 standarda- 가 붙으면 공용 인프라, 안 붙으면 제품입니다.
• 다음 시간: 네 폴더를 실제로 만들어 내는 실행 도구 devtools(자동화 도구) 부터 봅니다. 프로젝트가 어떻게 만들어지는지, 그 시작점입니다.

프로젝트의 생성·복제·삭제를 자동으로 처리해 주는 도구입니다. 특이하게 파이썬 코드가 0줄이고, Claude 에게 시키는 자연어 절차서(에이전트) 3개가 전부입니다. Claude 가 이 지시서를 읽고 실제 명령(cookiecutter·git·psql·certbot 등)을 대신 실행합니다.

standarda-devtools/
├── README.md              # 사용법 + '런처 디렉토리' 개념
└── .claude/agents/        # 핵심: 절차서 3개(전부 마크다운)
    ├── create-project.md   # 새 프로젝트 생성
    ├── clone-repo.md       # 기존 repo 를 표준 레이아웃으로 셋업
    └── delete-project.md   # 프로젝트 + 부수자원 일괄 정리(DESTRUCTIVE)

create-project (생성) slug 도출·이름 충돌 확인 → 포트 할당(dev+prod) → cookiecutter 실행(여기서 template 을 찍어냄) → 메모리 연결 → setup.sh 실행 → 초기 commit·push. template(표준 양식)과 포트·DB·메모리 설정을 한 번에 처리합니다. template·core 가 여기서 실제로 조립됩니다(각각 무엇인지는 바로 다음 두 강의에서 자세히 봅니다).

clone-repo (복제·가져오기) slug 결정 → 폴더 생성 → git clone → 메모리 연결 → .gitignore 정합성 → (Django 면) venv 생성·패키지 설치. 새로 만드는 게 아니라, 이미 있는 repo 를 표준 레이아웃($HOME/<project>/src/)으로 서버에 올릴 때 씁니다.

delete-project (삭제 · 가장 신중, DESTRUCTIVE) 수동으로 삭제하면 자원이 여기저기 남아 쌓이는 문제를 해결합니다. 3단계 안전장치로 동작합니다.

Phase 1 (읽기전용): 뭐가 있는지 스캔만 (절대 안 지움)
Phase 2 (확인):     삭제 목록 요약 → 사용자 'yes' 받기
Phase 3 (실행):     DB → 포트 → Apache → SSL → DNS → GitHub repo
                    → 위키 포트표 → 프로젝트 폴더 → 메모리 순서로 정리

프로젝트 하나에 딸린 8~9종의 흩어진 자원을 빠짐없이 정리합니다. (폴더 안 .env 에 DB 비밀번호·포트가 있어 폴더 삭제는 맨 마지막입니다.)

Q. devtools 를 왜 별도로 구분해?

A. devtools 는 프로젝트를 만드는 메타 도구라 어느 프로젝트·template·core 에도 소속될 수 없습니다. - template 안? 모든 프로젝트에 create/delete 에이전트가 복제돼 흩어짐(삭제 도구가 모든 집에? 위험). 게다가 template 은 복사 후 남남이라 개선도 반영 안 됨. - core 안? core 는 프로젝트가 import 하는 런타임 부품이고, devtools 는 Claude 실행 절차서입니다. 성격이 완전히 다릅니다. - 특정 프로젝트 안? 옆 프로젝트를 만들려고 이 프로젝트를 열어야 하는 모순.

→ 팀 전체가 같은 최신본을 안전하게 공유하려면 독립 repo(SSOT) 가 유일하게 깔끔한 자리입니다.

Q. 그럼 FDE 가 직접 안 해도 되게 해주는 거야?

A. 정확히는 "남이 대신"이 아니라 "본인이 직접 하되, 손으로 일일이 안 해도 되게" 자동화한 셀프서비스입니다. 실행 주체는 여전히 FDE 본인(자기 홈에 생성). 달라진 건 "어떻게": 포트 찾기·DB 생성·cookiecutter 옵션·vhost·인증서·DNS·삭제 시 자원 정리를 도구가 대신합니다. 장점: 수고 제거 · 표준화 · 실수/누락 방지(특히 삭제) · 셀프서비스(admin 요청 없이 즉시).

• 핵심 정리: devtools 는 프로젝트의 생성·복제·삭제를 자동으로 처리하는 도구입니다(파이썬 0줄, 자연어 절차서 3개). 프로젝트 안에 들어가지 않고 독립 repo로 존재하며, 실행하면 각자 홈에 프로젝트가 생깁니다. 특히 삭제는 3단계 안전장치로 흩어진 자원을 빠짐없이 정리합니다.
• 다음 시간: devtools 가 복제해 오는 template(표준 양식) 이 새 프로젝트의 뼈대를 어떻게 찍어내는지 봅니다.

새 프로젝트를 만들 때 복사해 쓰는 표준 양식입니다(실제로는 cookiecutter 라는 도구로 동작합니다). 매번 로그인·설정·폴더 구조·자동화 도구를 처음부터 만들지 않도록, 완성된 시작점을 통째로 제공합니다.

문서 양식을 복사해 새 문서를 만드는 것과 같습니다. 빈 양식을 복사한 뒤 프로젝트 이름·설정만 채워 넣으면, 매번 같은 구조의 프로젝트가 나옵니다.

cookiecutter 는 그냥 복사(cp)가 아니라, 복사하면서 이름·설정을 끼워 넣어 주는 도구입니다. 실제로 일어나는 3단계:

1. 물어봄:   "프로젝트 이름이 뭐야?"        → 당신: "Skyrocket Agent"
2. 복사함:   template 폴더를 통째로 복사
3. 채워넣음:  복사하면서 빈칸(변수)들을 답으로 치환

치환의 예:

[template 원본]                        [찍혀 나온 결과]
{{cookiecutter.project_slug}}/    ──▶   skyrocket_agent/
DB_NAME = "{{...db_name}}"        ──▶   DB_NAME = "skyrocket_agent"
TIME_ZONE = "{{...timezone}}"     ──▶   TIME_ZONE = "Asia/Seoul"

이 "빈칸 목록"이 바로 cookiecutter.json 파일입니다(프로젝트명·slug·DB명·타임존 등).

Q. {{cookiecutter.project_slug}} 는 예시 프로젝트명이야?

A. 아닙니다. {{ }} 는 "여기에 값을 채워라"는 빈칸(자리표시)입니다. 두 이름의 차이를 알아 두세요. - project_name = 사람이 읽는 이름 → "Skyrocket Agent" (띄어쓰기·대문자 OK) - project_slug = 그걸 컴퓨터용으로 변환 → skyrocket_agent (소문자, 공백→_)

slug 는 띄어쓰기가 있으면 안 되는 곳(폴더명·DB명·깃허브 repo명)에 쓰는 버전입니다.

Q. template 에서 직접 개발하는 거야?

A. 아닙니다. 이게 가장 중요한 구분입니다.

standarda-template/          ~/skyrocket_agent/  (찍어낸 결과물)
  (표준 양식·원본)    ──▶       (내 프로젝트)
 깨끗하게 유지                ← 여기서 기능 추가·수정

• 고유 기능은 찍어낸 프로젝트 폴더(~/skyrocket_agent)에 추가합니다.
• template(원본 양식) 은 손대지 않고 그대로 둡니다. cookiecutter 로 한 번 찍고 나면 원본과 남남이 되기 때문입니다(그래서 template 을 고쳐도 이미 찍어낸 프로젝트는 바뀌지 않습니다. 버그가 아니라 의도된 설계입니다).

그럼 template 은 언제 고칠까요? 딱 한 경우: "앞으로 새로 만들 프로젝트들이 물려받을 공통 뼈대를 개선" 할 때입니다.

그래서 CLAUDE.md 에 "공통 파일을 고치면 template 에도 반영(sync)하라"는 규칙이 있습니다.

{{cookiecutter.project_slug}}/ 폴더 안이 통째로 복사되어 새 프로젝트가 됩니다. 주요 구성:

{{cookiecutter.project_slug}}/
├── setup.sh              # 생성 후 첫 셋업 자동화(venv·DB·migrate)
└── src/
    ├── manage.py         # Django 조종석
    ├── {프로젝트}/settings/   # 설정 3분할(base/local/production)
    ├── accounts/ profiles/ emails/ sms/ projects/   # 공통 앱 5종(이미 완성)
    ├── utils/            # 공통 헬퍼(예외·응답·검증 등)
    ├── requirements.txt  # 설치 목록(Django + core + LLM 라이브러리)
    ├── templates/ static/   # 화면(HTML)·CSS/JS
    ├── docs/  e2e_tests/    # 문서 규격·기본 테스트
    └── .claude/          # 자동화(skills·agents·hooks)

• 공통 앱은 이미 완성돼 있습니다: 로그인·프로필·이메일/SMS 인증 등. 새 프로젝트는 고유 기능에만 집중하면 됩니다.
• .claude/ 의 자동화 도구(/dev·/release·pdf-parser·ui-tester 등)가 처음부터 장착된 채 시작합니다.

cookiecutter 는 찍어낸 직후 뒷정리 스크립트(hooks/post_gen_project.py)를 자동 실행합니다. 즉 "복사만" 하는 게 아니라:

cookiecutter 실행
├─ 1. 질문 → 답
├─ 2. 폴더 복사 + 빈칸 치환
└─ 3. 뒷정리 자동 실행
     ├─ ALLOWED_HOSTS 에 이 서버 IP 자동 주입
     ├─ git init + 원격 연결 + private repo 생성 시도
     └─ '다음 단계' 안내 출력

그다음 사용자가 ./setup.sh 를 실행하면: venv 생성 → pip install(Django+core) → SECRET_KEY 생성 → DB 생성·migrate → 관리자 계정 생성까지 이어집니다.

• 핵심 정리: template 은 cookiecutter 로 프로젝트 뼈대를 찍어내는 표준 양식입니다. 복사하면서 빈칸(이름·설정)을 채우고, 한 번 찍고 나면 원본과 남남이 됩니다(그래서 고유 기능은 찍어낸 프로젝트에서 추가하고, 원본 양식은 앞으로 만들 프로젝트를 위해서만 고칩니다).
• 다음 시간: template 과 달리 '설치'해서 쓰는 공용 기능 묶음 core(공통 기능) 를 봅니다.

이 강의가 이 챕터에서 가장 중요합니다. 왜 core 를 따로 뺐는지부터 시작합니다.

상황: 5개 프로젝트가 모두 "PDF 읽는 코드"(예: 200줄)를 필요로 합니다.

• ❌ 방법 A: 프로젝트마다 그 200줄을 복사·붙여넣기. 버그를 하나 발견하면 5군데를 전부 똑같이 고쳐야 하고, 하나라도 빠뜨리면 그 프로젝트만 옛 버그가 남습니다. 시간이 지나면 5개 복사본이 조금씩 달라져 제각각이 됩니다.
• ✅ 방법 B: 200줄을 딱 한 곳(core)에 두고 다 같이 씀. 각 프로젝트는 코드를 갖지 않고 설치해서 import 만 합니다. 버그를 고치면 core 한 곳만 고치고 버전을 올립니다. "원본이 하나"라 절대 제각각이 되지 않습니다 → SSOT(단일 출처).

❌ 방법 A: 복사본 5개              ✅ 방법 B: 원본 하나 + 설치
제품 A/    → pdf.py (200줄)         standarda-core/ → pdf.py (200줄)  ← 원본 "딱 하나"
제품 B/    → pdf.py (200줄)           │  pip install (버전 태그로)
제품 C/    → pdf.py (200줄)           ├──▶ 제품 A  (from standarda_core... import)
제품 D/    → pdf.py (200줄)           ├──▶ 제품 B
제품 E/    → pdf.py (200줄)           └──▶ 제품 C · 제품 D · 제품 E

from standarda_core... import ... 한 줄의 뜻은 "이 코드는 내 프로젝트 안에 없다. 별도 패키지(core)에 있는 걸 설치해서 불러 쓴다"입니다. 한 문장으로: "같은 걸 여러 번 만들지 말고, 한 번 만들어 다 같이 쓰자."

core 의 부품은 성격별로 세 갈래로 나뉩니다.

standarda_core/
├── clients/          ← 외부 서비스 연결 (구글과 통신)
│     gmail·sheets·drive·docs·auth
├── standard_utils/   ← 문서 → 텍스트 변환 (파일을 AI 가 읽게)
│     pdf/excel(text·vision)·document_text·sheets_text·llm_response
└── (루트)            ← LLM·워크플로우 엔진 (AI 두뇌)
      llm·llm_cache·tool_loop·verification·presentation

기억법: clients = 바깥세상(구글)과 통신, standard_utils = 파일을 AI 가 읽게 변환, 루트 = AI 두뇌·엔진.

Q. core 는 사용법 설명서야, 실제 실행 코드야?

A. 실제로 일하는 코드입니다. 설명서가 아닙니다. 예: gmail_client.py 의 send_email_with_attachment() 는 "메일 보내는 법을 적은 글"이 아니라, 호출하면 진짜로 구글에 접속해 메일을 발송하는 코드입니다.

단, 혼자 켜지지 않습니다. core 는 라이브러리(부품)라 "시작 버튼"이 없습니다. 프로젝트가 불러서 호출할 때만 작동합니다. (설명서가 아니라 실제로 도는 부품이지만, 프로젝트에 연결돼 호출될 때 비로소 작동한다는 뜻입니다.)

Q. 계정 같은 디테일은 어디서 관리하고, 실행은 누가 해?

A. 디테일(누구 계정이냐)은 프로젝트가 소유하고 core 에 인자로 넘깁니다. core 는 그 정보로 실제 실행만 합니다. - 프로젝트: "이 계정으로, 이 사람한테, 이 내용 보내줘" (디테일 제공) - core: 실제로 구글에 접속해 발송 실행 (계정 모르는 범용 기계)

프로젝트가 합쳐 쓰는 재료는 사실 3층입니다. 출처와 방식이 다 다릅니다.

집 짓기 비유:
① Django   = 공구·자재 (망치, 목재)   → 철물점에서 사 옴 (pip 설치)
② core     = 미리 만든 부품 (창틀, 문)  → 본사에서 배송 (pip 설치)
③ template = 설계도대로 지은 집 뼈대    → 설계도 복사해 시공 (cookiecutter)

Q. Django 는 standarda 폴더 중 하나야?

A. 아닙니다. Django 는 standarda- 어디에도 속하지 않는 외부 오픈소스(전 세계가 씀)입니다. 우리 깃허브가 아니라 인터넷(PyPI)에 있습니다. 재밌는 점은 core 도 Django 와 똑같은 방식(requirements.txt + pip install)으로 들어온다는 것입니다. 차이는 "누가 만들었나"(PyPI vs 우리 깃허브)뿐입니다.

💡 pip / venv - pip = 파이썬용 앱스토어(설치 도구). requirements.txt = 설치할 목록. - venv(가상환경) = 프로젝트 전용 창고. pip 으로 설치한 것(Django·core)만 여기 들어갑니다. template 코드는 안 들어가고 프로젝트 폴더에 그냥 놓입니다. 프로젝트마다 창고를 따로 둬야 서로 다른 core 버전을 품고도 안 싸웁니다.

Q. 왜 template 은 복사하고 core 는 설치해? 둘 다 공통인데?

A. 판단 기준은 딱 하나: "이 코드는 프로젝트마다 달라져야 하나, 영원히 똑같아야 하나?" - 달라져야 하는 것(뼈대: settings·URL·화면) → 각자 뜯어고쳐야 함 → 복사하고 관계를 끊는다 → template - 똑같아야 하는 것(공통 기능: PDF·메일) → 다 같아야 좋고 개선되면 다 받아야 함 → 설치하고 연결을 유지한다 → core

Q. 실행할 때마다 core 원본/GitHub 에서 가져와? 배포 후에도?

A. 아닙니다. 아주 중요한 포인트입니다.

[pip install 시점: 딱 한 번]
GitHub 의 core → 다운로드 → 프로젝트 venv 안에 '복사본' 설치
[실행 시점: 매번]
Python 은 그 venv 안의 '복사본'에서 실행  ← GitHub 도, 원본 폴더도 안 봄

증거: 원본 폴더는 최신(0.21.0)인데 어떤 프로젝트 venv 의 설치 사본은 옛날(0.1.0)일 수 있습니다. 재설치 전까진 계속 옛 사본을 씁니다. "core 는 연결 유지"라는 말은 실시간 연결이 아니라, requirements.txt 에 원본 주소+버전을 남겨 재설치 명령 한 번으로 갱신 가능하다는 뜻입니다(느슨한 연결).

Q. 설치된 사본을 자동으로 계속 업데이트하면 안 돼?

A. 일부러 안 합니다. 그게 오히려 안전합니다. 배포된 프로그램의 제1원칙은 "어제 되던 게 오늘도 똑같이 된다". core 가 한밤중에 자동으로 바뀌면 예고 없는 고장·재현 불가·운영 사고·호환성 파손이 생깁니다. - 업계 표준 = 버전 고정(pinning) + 사람이 원할 때 수동 갱신. 그래서 @v0.20.0 태그를 박아 둡니다. - 대가: 프로젝트가 옛 버전에 뒤처질 수 있음. 그건 안정성을 얻는 대가이며, 필요할 때 태그를 바꿔 재설치 → 테스트 → 배포합니다.

무엇을 넣나: 공통 + 범용 + 안정적인 것만. 많다고 좋은 게 아닙니다. core 는 모든 프로젝트에 설치되므로, 아무거나 넣으면 다들 안 쓰는 코드까지 떠안고 불필요하게 얽힙니다.

• ✅ 넣을 것: "PDF 읽기" (여러 프로젝트가 다 필요, 어디서든 동일)
• ❌ 넣지 말 것: "특정 제품에만 쓰는 화면 로직" (그 프로젝트만 씀 → 프로젝트 안에)

Q. 누가 결정하고, 중복 개발은 어떻게 막아?

A. 결정권자 = 코어 관리자(한 명). core 는 두 겹 장치로 승인을 강제합니다: CODEOWNERS(모든 변경에 그 관리자를 자동 리뷰어로 지정) + Branch protection(master 직접 push 금지, PR → 승인 → merge). 제안은 누구나 PR 로 올리되 문지기는 한 명입니다. 애매한 부품은 처음부터 안 넣고, 두 번째 프로젝트가 필요해질 때 core 로 승격합니다(PR → 승인 → 태그 → changelog).

Q. changelog 기록은 자동이야?

A. 아닙니다. 태그를 push 한다고 저절로 써지지 않습니다. core 변경은 태그 push 후 사람이 직접 엔트리를 추가합니다(강제 훅 없는 '규율 의존' 장치). 그래서 CLAUDE.md 가 "(필수)"로 강조합니다.

• 핵심 정리: core 는 여러 프로젝트가 함께 쓰는 공용 기능을 한 곳(원본 하나=SSOT) 에 모아 둔 것입니다. template 처럼 복사하지 않고 pip 로 설치해서 쓰며(연결 유지), 안전을 위해 버전을 고정하고 자동 업데이트하지 않습니다. 무엇을 넣을지는 코어 관리자 승인으로 통제됩니다.
• 다음 시간: 네 폴더가 어떻게 맞물려 프로젝트 하나를 태어나게·자라게·정리하는지 전체를 한 번에 봅니다.

이제 네 폴더가 어떻게 맞물리는지 전체를 한 번에 봅니다.

[생성]  ~/standarda-devtools 에서 create-project 실행   ← devtools = 자동화 도구(프로젝트에 안 들어감)
          devtools 가 아래 둘을 대신 수행:
          ├─ cookiecutter → standarda-template 복제·이름맞춤   → 내 프로젝트 뼈대(내 홈)
          └─ setup.sh → pip install → standarda-core 설치      → venv 안 부품 사본(+Django)
                        ▼
          ~/<내프로젝트>/src 탄생 (= standarda 같은 완성품)

[개발]  /dev 로 서버·dev도메인 → 고유 기능 작성(공통앱은 이미 완성). core 는 import 로 호출

[운영]  /release 로 prod 배포. core 갱신은 태그 올려 재설치(수동·의도적)

[삭제]  delete-project → DB·포트·vhost·SSL·DNS·repo·메모리 일괄 정리

devtools(자동화 도구, 프로젝트엔 안 들어감)를 실행하면, 그것이 template 을 복제·맞춤해 내 프로젝트 뼈대를 만들고 core 를 설치해 공용 기능을 넣어 줍니다. 그 결과 내가 본격적으로 개발할 프로젝트가 내 홈에 완성됩니다.

복제·설치를 실행하는 주체는 devtools 가 맞지만, devtools 자신은 결과물 안에 들어가지 않습니다. (집을 짓는 시공사가 그 집에 살지는 않는 것과 같습니다.)

• 핵심 정리: devtools(자동화 도구)가 template(표준 양식)을 복제하고 core(공통 기능)를 설치해 내 프로젝트를 완성합니다. 개발은 내 프로젝트 폴더에서, 공용 기능은 core 를 import 해서, 배포는 /release 로, 정리는 delete-project 로. 이 전체가 앞 강의의 두 열쇠, 방어(반복 제거·일관성)와 성장(집단지성)을 실현하는 구조입니다.
• 다음 시간: 이 챕터에서 나온 핵심 용어를 한곳에 모은 용어집과, 스스로 답해 보는 자가 점검 질문으로 마무리합니다.

이 챕터에서 나온 핵심 용어를 한곳에 모았습니다. 마지막으로 자가 점검 질문에 스스로 답해 보며 이해를 확인하세요.

답을 스스로 말해 보세요. (답은 각 강의의 Q&A 참고)

1. standarda 와 standarda-core 의 관계를 한 문장으로? (힌트: 결과물 vs 재료)
2. template 은 왜 '복사'하고 core 는 왜 '설치'하나?
3. {{cookiecutter.project_slug}} 는 예시 프로젝트명인가?
4. template 을 고치면 이미 만든 프로젝트도 바뀌나? 왜?
5. Django 는 어느 standarda 폴더에 들어 있나?
6. core 코드는 배포 후 실행할 때마다 GitHub 에서 가져오나? (증거는?)
7. core 를 자동 업데이트하지 않는 이유는? 그 대가는?
8. 새 유틸이 core 에 들어갈지 최종 결정하는 사람은? 애매한 부품은 언제 승격하나?
9. changelog 기록은 자동인가?
10. devtools 를 별도 repo 로 두는 이유는?

• 핵심 정리: 핵심 용어(cookiecutter·slug·pip·venv·SSOT·버전 고정·승격 등)와 네 폴더의 관계를 스스로 설명할 수 있으면 이 챕터를 충분히 소화한 것입니다.
• 이것으로 standarda 생태계 챕터를 마칩니다. 이제 프로젝트를 열었을 때 각 폴더가 왜 거기 있는지, 무엇이 도구·재료이고 무엇이 결과물인지 설명할 수 있습니다.