부트스트랩 (Bootstrap)

현재 저장소에 문서 기반 컨벤션 세트를 설치(또는 적용)하고 있습니다. 최종 상태는 인간과 코딩 에이전트 모두가 적은 수의 표준 파일을 기반으로 저장소를 운영할 수 있는 상태입니다. 여기에 설명된 메커니즘만 따르세요. 다른 프로젝트에 대한 내용은 포함하지 마세요.

1단계 — 상황 감지

질문하기 전에 저장소를 검사하세요. 이 세션에서 이미 제공된 명확한 답변과 승인을 재사용하고, 이를 프로필 기본값으로 대체하거나 다시 묻지 마세요. 쓰기 전에 확인된 아티팩트 루트, 깊이, 큐, 게이트 및 조정/통합 모드를 해당 답변에 대해 요약하세요. 호스트가 선택한 폴더를 샌드박스에 미러링하는 경우, 실제 대상 경로와 확인된 출력물이 선택한 폴더에 도달하는 방식을 식별하세요. 스크래치 미러가 통과했다고 해서 대상이 변경되지 않은 상태로 완료되었다고 절대 간주하지 마세요.

새 저장소(소스 코드나 문서 없음): 처음부터 구성(Scaffolding)합니다.
기존 저장소: 적용(Retrofitting)합니다.
- 변경을 제안하기 전에 현재 README.md, CONTRIBUTING.md, AGENTS.md, CLAUDE.md, docs/, adr/, .github/를 읽으세요.
- 기존 내용을 보존하세요. 병합하고 덮어쓰지 마세요. 기존 컨벤션이 아래 컨벤션과 충돌하는 경우, 평가 요약에서 충돌을 표시하세요.
- ADR이 다른 형식으로 이미 존재하는 경우, 병렬 트리를 생성하지 말고 마이그레이션 계획(번호 재지정, 유지, 변환)을 제안하세요.
이미 Docflow 저장소(AGENTS.md + CONVENTIONS.md + ADR 카탈로그 보유): 구성(Scaffolding)이 아닌 기존 설정에 추가하는 것입니다. 핵심을 다시 구성하거나 이미 결정된 질문을 다시 묻지 마세요. CONVENTIONS.md/AGENTS.md에서 기록된 선택 사항(ADR 형상, 상태 수명 주기, 아티팩트 루트, 다중 에이전트 모드 및 이미 존재하는 선택적 레이어)을 읽으세요. 그런 다음 아직 존재하지 않는 선택된 선택적 레이어(plan/, _agent/, GLOSSARY.md, domains/ 또는 두 번째 ADR 형상(기술 템플릿))를 활성화하는 옵션을 제공하고, 기록된 아티팩트 루트 아래에 병합 방식으로 선택된 것만 작성하고 다른 모든 것은 그대로 두세요. 새 레이어에 필요한 질문만 하세요(예: _agent/ 활성화 시 조정 질문 — 기록된 검증 게이트와 계획 큐가 모두 없는 단일 작성자는 _agent/가 전혀 없게 되며, 해당 레이어가 단순히 필요하지 않습니다). 이것은 처음 부트스트랩에서 연기했던 레이어를 추가하기 위한 진입점입니다. 이전 구성에서 작성한 조정 파일을 여전히 보유한 저장소는 그대로 두고, 감사 스킬이 레이아웃을 보고하도록 하세요.

GLOSSARY.md 활성화는 표준 셸을 작성하며, 절대 다시 쓰지 않습니다. 레이어가 선택되고 파일이 없으면 templates/GLOSSARY.md에서 작성합니다. 선택적 제목과 본문, 그 다음 생성된 CONVENTIONS.md §용어집(Glossary)에 기록된 하나의 용어 | 정의 테이블을 작성합니다. 파일이 이미 존재하면 그대로 둡니다. 레이어를 활성화해도 아무것도 추가되지 않으며, add-convention은 기존 파일을 표준 형식으로 확장하거나 audit이 동의된 마이그레이션을 제공합니다.

두 번째 ADR 형상 활성화는 파일 복사가 아닌 체계 전환입니다. 이미 기록된 선택을 변경하는 유일한 연기된 레이어이므로, 한 번에 모두 작성하거나 전혀 작성하지 마세요. CONVENTIONS.md의 §ADR 형상(ADR Shapes)을 두 형상 텍스트로 바꾸고, 기술 섹션 순서와 형상 글머리 기호를 AGENTS.md에 추가하고, adr/0000-template-technology.md를 작성하고, 형상(Shape) 열과 함께 INDEX.md를 재생성하세요. 기존 ADR은 번호를 유지하고 기능(Capability) 상태를 유지합니다. shape: 필드가 없으면 이미 기능(Capability)을 의미하므로, 어떤 ADR도 다시 작성되지 않고 번호가 재지정되지 않습니다. 전환의 절반만 수행하면 저장소가 4.5단계 상호 검증에서 모순이라고 부르는 상태(단일 형상 체계에서 절대 선택하지 않을 기술 템플릿)에 빠집니다.

이미 레거시 범위 인코딩을 사용하는 저장소에는 마이그레이션 제안이 대신 제공됩니다. 형상이 선언된 필드가 되기 전에 구성된 일부 두 형상 저장소는 이를 번호로 인코딩합니다. §ADR 형상(ADR Shapes)은 기준점(capability는 그 아래, technology는 그 이상)을 기록하고, adr/는 0000 이외의 번호가 매겨진 템플릿(예: adr/0100-template.md)을 보유합니다. 두 신호 중 하나만으로 이를 식별할 수 있습니다. 이러한 저장소는 레이어가 누락된 것이 아니라 이미 두 형상을 모두 가지고 있으므로, 위의 체계 전환을 제공하지 마세요. 이는 저장소를 두 개의 경쟁 인코딩으로 이끌 것입니다. 대신 감사 스킬이 사용하는 것과 동일한 조건으로 선언된 필드로의 마이그레이션을 제공하세요.
- 먼저 이전-새 번호 맵을 예비 실행(dry run)으로 보여주세요. 기능(Capability) ADR은 번호를 유지하고, 기술(Technology) ADR은 가장 높은 기능 ADR 다음 번호를 원래 상대 순서대로 가져옵니다. 함께 따르는 참조(depends-on, supersedes / superseded-by, 상대 adr/NNNN-*.md 링크, INDEX.md, 도메인 README.md 목록, plan/todo/ 소유 ADR 라인)와 역사로 남는 항목(plan/done/ 바닥글, 커밋 메시지, 태그)을 나열하세요.
- 해당 맵에 대한 명시적 확인 없이는 아무것도 작성하지 마세요. 거절도 유효한 결과입니다. 저장소는 범위 인코딩을 유지하고 자체 규칙을 계속 통과합니다.
- 확인 시, audit 스킬의 마이그레이션 단계에 지정된 대로 정확히 마이그레이션을 적용하세요. 번호 재지정, 모든 ADR에 shape: 스탬프, 카탈로그 내 모든 참조 다시 쓰기, 경계 템플릿을 adr/0000-template-technology.md로 교체, §ADR 형상(ADR Shapes)을 선언된 필드로 다시 쓰고 시드 ADR 예외 조항 제거, 형상(Shape) 열과 함께 INDEX.md 재생성 — 그리고 커밋 메시지가 모든 이전-새 쌍을 나열하는 하나의 커밋으로 저장하세요. 그 절차가 단일 진실 공급원입니다. 여기서 두 번째 변형을 의역하지 마세요.
- 그런 다음 정상적으로 실제로 없는 레이어(plan/, _agent/, GLOSSARY.md, domains/)에 대해 재실행을 계속하세요.

평가 질문을 하기 전에 한 줄로 해당되는 상황을 명시하세요.

2단계 — 대상 레이아웃

<repo>/
  AGENTS.md              # 코딩 에이전트를 위한 하드 규칙 — 진입점
  CLAUDE.md              # 한 줄: @AGENTS.md
  README.md              # 사람 대상 프로젝트 요약 (존재 시 보존)
  CONVENTIONS.md         # 제작 규칙: ADR, 명명, 상태, 감사, git
  INDEX.md               # 모든 ADR의 생성된 테이블
  GLOSSARY.md            # 공유 용어 (선택 사항 — Q7 참조)
  adr/
    0000-template.md     # 기능 ADR 템플릿 (항상)
    0000-template-technology.md  # 기술 ADR 템플릿 (두 형상인 경우에만 — Q2 참조)
    NNNN-<kebab-slug>.md # 결정당 하나의 ADR, 연속 번호
  domains/<slug>/README.md   # 선택 사항 (Q7 참조)
  plan/
    README.md
    todo/NNNN-<slug>.md
    done/<YYYY-MM-DD>-<slug>.md
  _agent/                # 에이전트 운영 계약 (Q5 참조) — 선택 사항
    ROLES.md             # 누가 무엇을 쓰는지 (여러 작성자만)
    LOCKS.md             # 파일 클레임 뮤텍스 (공유 체크아웃만)
    prompts/autonomous.md  # 무인 실행이 작동하는 방식 (검증 게이트 — Q8 — AND 계획 큐 — Q4a가 있는 경우에만)
  federation.md          # 다중 저장소만 (Q11): 이 저장소의 역방향 포인터
  federation-index.md    # 다중 저장소만 (Q11): 멤버 인덱스 — 홈 저장소만

배치. 위 트리는 루트 옵션을 보여줍니다. AGENTS.md와 CLAUDE.md는 항상 저장소 루트에 있습니다. adr/, plan/, _agent/, INDEX.md, CONVENTIONS.md는 Q12에서 선택된 아티팩트 루트 아래에 위치합니다(기본값 .docflow/, 예: .docflow/adr/, .docflow/plan/).

검색. 도구는 CONVENTIONS.md를 먼저 읽지 않고 아티팩트 루트를 찾습니다. 저장소 루트에 있는 .docflow/ 디렉토리가 루트입니다. 다른 루트의 경우, 부트스트랩이 저장소 루트에 .docflow 파일을 작성합니다. 이는 한 줄 포인터(root: <path>, 예: root: docs/, root: .)입니다. 둘 다 없으면 사전 계약 저장소(도구가 docs/, 그 다음 저장소 루트에서 아티팩트 루트를 명명하는 CONVENTIONS.md를 찾음)이거나 Docflow 저장소가 아닙니다.

_agent/는 에이전트 운영 계약입니다. 누가 무엇을 쓰는지, 하나의 실제 뮤텍스, 그리고 무인 실행이 작동하는 방식을 정의합니다. git이 이미 기록하는 것은 아무것도 보유하지 않습니다. 중복된 배송 기록, 진행 중인 작업 대시보드, 현재 상태 스냅샷, 핸드오프가 없습니다. 위 세 파일 중 어떤 것이 존재하는지는 Q5, Q8 및 Q4a에 전적으로 따르며, _agent/ 디렉토리가 전혀 없는 저장소도 유효한 결과입니다.

핵심(Core) 대 선택적(Optional) 레이어. 핵심만 항상 작성됩니다. AGENTS.md, CLAUDE.md, CONVENTIONS.md, adr/0000-template.md, INDEX.md. 이것만 있는 저장소는 유효하고 가벼운 Docflow 저장소입니다. 클래식 ADR 카탈로그와 컨벤션을 갖춘 것입니다. 다른 모든 것은 옵트인 레이어입니다. plan/ 큐(Q4a), _agent/ 계약(Q5 + Q8 + Q4a — 검증 게이트와 계획 큐가 모두 없는 단일 작성자는 전혀 얻지 못함), GLOSSARY.md 및 domains/(Q7). 선택적 레이어를 생략하는 것은 유효한 상태이지 오류가 아닙니다. 누락된 레이어가 필요한 수명 주기 스킬은 깔끔하게 거절하고 무엇이 누락되었는지 명명합니다.

다중 저장소 제품(Q11 참조 — 여러 저장소에 걸쳐 있는 하나의 제품)의 경우 두 개의 추가 파일이 나타납니다. federation.md는 모든 멤버 저장소가 가지고 있는 작은 역방향 포인터이고, federation-index.md는 홈/설립 저장소에만 있는 권위 있는 멤버 목록입니다. 모든 연합 아티팩트(federation.md, federation-index.md, 파생된 롤업 ROLLUP.md)는 구성된 아티팩트 루트 아래에 배치됩니다. 독립형 저장소에는 이들 중 아무것도 없습니다.

3단계 — 설치할 컨벤션

ADR은 진실의 원천입니다. ADR당 하나의 결정. 분할은 이를 대체하는 새로운 ADR이 됩니다. 기존 ADR 내에서 범위를 확장하지 마세요.
최대 두 개의 ADR 형상, 필드로 선언. 두 가지를 구분하는 저장소는 각 ADR의 shape: 메타데이터 필드(capability 또는 technology, 필드가 없으면 capability를 의미)에 구분을 기록합니다. 번호 범위가 아닙니다. 모든 ADR은 형상에 관계없이 다음 연속 번호를 가지며, 각 형상은 자체 템플릿(둘 다 0000으로 번호가 매겨짐)을 가집니다.
- 기능(Capability) ADR(시스템이 수행해야 하는 작업). 섹션 순서: 메타데이터 → 컨텍스트 → 기능 설명 → 사용자 스토리/시나리오 → 승인 기준 → 범위 외 → 미결 질문 → 참조 → 개정 이력 → 승인.
- 기술(Technology) ADR(구축 방법). 섹션 순서: 메타데이터 → 컨텍스트 → 결정 → 근거 → 결과 → 승인 기준 → 범위 외 → 미결 질문 → 참조 → 개정 이력 → 승인. 근거는 고려된 대안을 명명하고 구체적인 거부 이유를 제시해야 합니다("더 간단함" / "더 관용적임"이 아님).
상태 수명 주기: 제안됨(Proposed) → 수락됨(Accepted) → 구현됨(Implemented) → (대체됨(Superseded) | 사용 중단됨(Deprecated)). 이전 상태에서 도달 가능한 최종 상태. 상태는 계획 폴더 배치를 결정합니다. 수락됨(Accepted) → plan/todo/, 구현됨(Implemented) → plan/done/.
파일명: adr/NNNN-kebab-slug.md, 4자리 제로 패딩, 연속, 예약된 간격 없음. 상호 참조는 상대 경로를 사용합니다.
승인 기준은 테스트 가능하고 번호가 매겨져야 합니다. 테스트는 실용적인 경우 이에 매핑됩니다.
감사 규율. 실질적인 ADR 변경은 개정 이력 행을 추가합니다. 편집상 변경(오타, 서식, 링크 수정)은 제외되지만 커밋 메시지에 editorial로 표시됩니다. 승인 테이블은 ADR이 수락됨(Accepted)일 때 채워지고 이후의 각 실질적 개정 시 업데이트됩니다.
INDEX.md는 ADR 변경 후 ADR 메타데이터에서 재생성됩니다. 파생된 것으로 취급하고, 수동 편집하지 마세요.
plan/은 작업 큐입니다. 작업이 출시될 때, git mv plan/todo/X plan/done/<date>-X, 계획 항목 상태 제거, 소유 ADR 상태 진행 및 INDEX.md 재생성이 완료 커밋에 그룹화됩니다. 메인에 직접 통합 시 해당 커밋은 통합 브랜치로 푸시되고 이동된 파일의 바닥글은 HEAD SHA(및 해당하는 경우 배포 아티팩트 ID)를 명명합니다. 풀 리퀘스트 통합 시 이러한 변경 사항은 풀 리퀘스트 브랜치가 준비됨(ready)으로 표시되기 전의 마지막 커밋이며, 바닥글은 풀 리퀘스트를 명명하고, 병합이 완료 이벤트입니다.
조정은 계약이지 로그가 아닙니다. _agent/는 git이 알려줄 수 없는 것만 보유하며, 각 모드(Q5)는 정확히 자체 파일만 규정합니다. 다른 것은 거기에 기록되지 않습니다. 공유 체크아웃에서 에이전트는 편집 전에 _agent/LOCKS.md에 행을 추가하고(<agent-id> | <path> | <ISO-8601 timestamp>) 커밋 시 제거합니다. 이 원장이 유일한 실제 뮤텍스이며, 큐 항목은 항목 자체에 대해 클레임됩니다. 별도 작업 트리에서 큐 항목은 claim/<item-key>(확장자 없는 큐 파일 이름)를 푸시하고, 통합이 풀 리퀘스트 기반인 경우 여기에서 초안 풀 리퀘스트를 통해 클레임됩니다. 푸시가 두 번째 작성자를 배제하며, 원장은 유지되지 않습니다. 단일 작성자 아래에서는 직렬화할 것이 없고 클레임할 것도 없습니다. 어떤 모드도 중복된 배송 상태, 진행 중인 작업 대시보드 또는 현재 상태 스냅샷을 유지하지 않습니다. git 기록과 plan/done/이 기록이며, 라이브 브랜치와 풀 리퀘스트가 진행 중인 작업입니다.
Git 계약. 컨벤셔널 커밋(Conventional Commits). ADR을 건드리는 커밋에는 필수 Rationale: 바닥글. 사용자가 거부하지 않는 한 서명된 커밋. 사용자가 요청하지 않는 한 에이전트 작업에 Co-Authored-By 트레일러 없음.
AGENTS.md는 하드 규칙 진입점입니다. CLAUDE.md는 이를 읽는 호환 가능한 에이전트를 위한 한 줄 @AGENTS.md입니다.
ADR은 내부 아티팩트입니다. 절대 사용자에게 표시되지 않습니다. ADR 번호, ADR 제목 및 ADR 카탈로그의 존재는 사용자에게 도달하는 제품 코드 경로(UI 문자열, API 응답 본문, 오류 메시지, 고객에게 발송되는 로그 라인, 공개 문서, 릴리스 노트, 마케팅 자료, 지원 커뮤니케이션)에 절대 나타나서는 안 됩니다. ADR은 구축자를 위한 것이지 사용자를 위한 것이 아닙니다. 코드 주석(// see adr/NNNN-slug.md), 내부 개발자 문서, 커밋 메시지에서의 참조는 허용됩니다.
용어집(Glossary)은 공유 용어에 대한 단일 진실 공급원입니다. GLOSSARY.md는 각 용어에 대한 정의를 한 줄로 제공하는 단일 용어 | 정의 테이블을 유지합니다. 용어는 해당 파일에 정의된 대로 모든 컨벤션, ADR, README 및 에이전트 프롬프트 전반에 걸쳐 일관되게 사용되어야 합니다. 섹션 머리글과 같은 선택적 구조 콘텐츠가 있을 수 있지만, 핵심 계약은 용어당 하나의 행입니다. add-convention 명령어는 이 파일을 확장합니다. 감사(Audit)는 사용자 동의 하에 마이그레이션을 제공합니다.
domains/README.md는 하위 도메인 매핑입니다. 각 하위 도메인은 디렉토리를 가져오며, 그 디렉토리에는 도메인의 문서 기반 의사 결정을 위한 자체 ADR 카탈로그가 포함될 수 있습니다. 하위 도메인과 애그리게이트 간의 경계는 이 문서에 정의된 대로 컨텍스트 맵을 통해 명시적으로 모델링되어야 합니다.
INDEX.md는 파생된 아티팩트입니다. 모든 ADR 변경 후 ADR 메타데이터에서 재생성됩니다. 수동으로 편집하지 마십시오. 형상(Shape) 열이 있는 형식은 두 ADR 형상이 모두 활성화된 경우에만 나타납니다. 두 형상이 모두 활성화되지 않은 경우 생략됩니다.

4단계 — 질문 (Quick / Guided / Full Depth)

선택한 깊이에 따라 사용자에게 묻는 질문이 결정됩니다. 이전에 질문하고 답변한 모든 것은 다시 묻지 않습니다.

Express (빠른) — 질문 없음, 모든 기본값 사용

모든 기본값을 가정하고 아무것도 묻지 않고 직접 작성합니다.

Guided (안내) — 기본 질문

저장소 이름 (Q0)? 보통 README.md 또는 리모트 URL에서 가져옵니다. 기본값: 저장소 이름.
ADR 형상 (Q2)? 하나 또는 둘. 기본값: 하나.
계획 큐 (Q4a)? plan/ 디렉토리 사용? 기본값: 예.
조정 모드 (Q5)? 단일 작성자(Single writer) / 공유 체크아웃(Shared checkout) / 별도 작업 트리(Separate worktrees). 기본값: 단일 작성자.
용어집 및 도메인 (Q7)? GLOSSARY.md 및/또는 domains/ 사용? 기본값: 아니요.
검증 게이트 (Q8)? 무인 실행을 위한 검증 게이트 필요? 기본값: 아니요.
Git 서명 (Q9)? 서명된 커밋 사용? 기본값: 예.
다중 저장소 (Q11)? 이 저장소가 여러 저장소로 구성된 제품의 일부입니까? 기본값: 아니요.
아티팩트 루트 (Q12)? .docflow/ (루트) 또는 경로? 기본값: .docflow/.

Full Depth (전체 심층) — 모든 질문

안내(Guided) 모드의 모든 질문 + 추가 질문.

라이선스 (Q3)? LICENSE.md 생성? 어떤 라이선스?
ADR 번호 시작 (Q4b)? 기본값: 0001.
계획 항목 템플릿 (Q4c)? plan/todo/ 항목에 대한 템플릿 사용자 정의.
역할 정의 (Q6)? _agent/ROLES.md에 기록된 명시적 역할? 기본값: 없음.
메트릭스 (Q10)? 추적할 메트릭스? 기본값: 없음.
기타 아티팩트 (Q13)? 생성할 다른 파일이나 디렉토리?

5단계 — 파일 작성

모든 답변을 수집한 후, 순서대로 파일을 작성하세요.

CONVENTIONS.md — 준수할 규칙.
adr/0000-template.md — 기능(Capability) ADR 템플릿.
adr/0000-template-technology.md — 기술(Technology) ADR 템플릿(해당하는 경우에만).
AGENTS.md — 에이전트 규칙.
CLAUDE.md — @AGENTS.md.
INDEX.md — 빈 ADR 인덱스.
plan/ — 디렉토리 및 README.md(해당하는 경우).
_agent/ — 파일(해당하는 경우).
federation.md 및 federation-index.md(해당하는 경우).
GLOSSARY.md(해당하는 경우).
domains/ — 디렉토리 및 README.md(해당하는 경우).
.docflow — 포인터 파일(해당하는 경우).

중요: 질문(Q0-Q13)에 대한 답변을 기반으로 파일을 사용자 정의하세요. 모든 것을 그대로 복사하지 마세요. 컨텍스트에 맞게 내용을 조정하세요.

병합 규칙: 기존 파일의 내용을 완전히 대체하지 마세요. 특히 README.md, CONTRIBUTING.md 및 기존 ADR의 경우 더욱 그렇습니다. 대신 필요에 따라 섹션을 읽고, 구문 분석하고, 병합하세요.

6단계 — 작성 후 요약

작성 후, 생성된 내용에 대한 간결한 요약을 제공하세요.

## Docflow 부트스트랩 완료

| 구성 요소 | 상태 |
|---|---|
| 핵심(Core) 파일 | ✅ `AGENTS.md`, `CLAUDE.md`, `CONVENTIONS.md`, `INDEX.md` |
| ADR 템플릿 | ✅ `adr/0000-template.md` (capability) |
| 계획 큐(Plan queue) | ✅ `plan/todo/`, `plan/done/` |
| 조정(Coordination) | ✅ `_agent/` (`<mode>`) |
| 용어집(Glossary) | ✅ `GLOSSARY.md` |
| 도메인(Domains) | ✅ `domains/<slug>/` |
| 연합(Federation) | ✅ `federation.md`, `federation-index.md` |
| 아티팩트 루트 | `.docflow/` |

**다음 단계:** `adr/0001-my-first-decision.md` 작성을 시작하려면 `new-adr`를 사용하거나, `audit`을 실행하여 구성을 확인하고 개선 영역을 찾으세요.

7단계 — 시드 ADR (ADR 번호가 0001부터 시작하는 경우)

ADR 번호가 0001에서 시작하는 경우, 부트스트랩의 마지막 단계로 시드 ADR 0001을 작성하는 것을 고려하세요. 이 시드 ADR은 "ADR 체계 채택" 결정을 문서화해야 합니다.

시드 ADR은 다음을 포함해야 합니다.

제목: ADR-0001: 아키텍처 결정 기록(ADR) 체계 채택
상태: 수락됨(Accepted)
컨텍스트: 프로젝트에 구조화된 의사 결정이 필요한 이유.
결정: CONVENTIONS.md에 설명된 대로 이 Docflow 체계를 채택하기로 결정했습니다.
근거: 체계의 이점: 추적 가능성, 병렬 작업, 감사.
결과: 긍정적인 결과와 잠재적인 과제.
영향을 받는 파일: 생성된 파일 목록.

사용자가 시드 ADR 작성을 요청하지 않았거나 Q4b가 0001이 아닌 경우, 이 단계를 건너뜁니다.

EvolveHQ/docflow

docflow란 무엇인가요?

즐겨 사용하는 AI에게 물어보기

문서