고객의 질문에서 시작합니다.
사용자가 먼저 묻는 질문과 제품을 만드는 팀이 답해야 하는 질문을 나눴습니다. 현재 기능, 판단 근거와 남은 과제를 함께 확인하세요.
사용자 질문
설치, 지원 범위, 비용과 실제 문서 검토에 관한 답변입니다.
명령어 없이 ChatGPT·Claude에서 작성 원칙을 적용할 수 있나요?
계정 설정을 자동으로 변경하나요?
설정 위치와 지침을 제공하며 사용자가 직접 붙여 넣고 저장합니다. 기존 지침에는 필요한 부분을 합치세요. 파일 첨부만으로 지침 설정을 대신하지 마세요.
작성 지침과 검사 프로파일은 무엇이 다른가요?
작성 지침은 모델에 표·그림 제목, 서술식 문장, 사실 보존과 검토 절차를 안내합니다. 검사 프로파일은 CLI의 규칙과 심각도를 선택합니다. 0.3.0의 setup --target chatgpt|claude는 작성 지침을 내보내며 계정 설정을 자동 변경하지 않습니다.
누가 AI Doc Ready를 사용하면 좋나요?
Markdown 또는 HWPX로 보고서·계획서·제안서를 작성하는 실무자와, AI 에이전트의 초안을 검토하는 팀을 위한 도구입니다. 표 제목이나 항목 번호처럼 반복 확인하는 구조를 같은 규칙으로 점검하려는 경우에 적합합니다.
AI 친화적 보고서를 쓰면 무엇이 좋아지나요?
행안부는 시범운영에서 보고서 작성 시간 단축과 AI 요약·발표자료 작성 정확도 향상을 확인했고, Markdown 병행 제공으로 검색 편의성을 높였다고 발표했습니다. AI Doc Ready는 이 방향의 작성 원칙을 SKILL 지침과 구조 검사로 적용하도록 돕습니다. 제품 자체의 시간 절감이나 AI 정확도 개선 수치를 측정한 것은 아닙니다. 실제 작성·요약·발표자료 생성은 사용자의 에이전트·AI 도구가 수행합니다.
표와 목록을 모두 서술형으로 바꿔야 하나요?
정보의 역할에 맞게 형식을 선택합니다. 선택 이유·조건·판단의 흐름은 서술형, 할 일이나 준비물은 열거형, 여러 대상을 동일한 항목으로 비교하는 정보는 표가 적합할 수 있습니다. 같은 확인 항목을 표와 열거형으로 비교한 예시를 확인하세요. 공식 원칙도 표 자체를 금지하지 않습니다. 정적 검사 결과만으로 어떤 형식이 가장 읽기 좋은지 판정하지는 않습니다.
지금 어떤 문제를 해결하나요?
표·그림 상단 제목과 순서 표시, 항목 단계, 중첩 표, 양방향 셀 병합 검토 후보를 찾습니다. 진단에 위치·규칙·발췌를 남겨 작성자가 수정 여부를 판단하도록 돕습니다. 사용자 프로파일, 일괄 검사와 JSON 출력을 지원합니다.
hwp2md로 변환하면 AI Doc Ready 검사는 필요 없나요?
hwp2md는 HWP/HWPX를 Markdown으로 변환하고, AI Doc Ready는 변환된 문서의 구조를 검사합니다. 복잡한 표의 선별 사례에서 원본 해당 부분·자동 변환·검사 결과를 볼 수 있습니다. 전체 결과는 별도 페이지에서 확인합니다. 변환 후에도 표 제목·번호·미지원 구조를 확인하고, 사실과 수치는 원문과 대조해야 합니다. HWP 입력은 먼저 변환해야 하며 AI Doc Ready의 직접 입력 범위는 Markdown/HWPX입니다.
AI Doc Ready가 표를 서술형으로 자동 변환하나요?
공개된 0.3.0 CLI는 문서를 자동 작성하거나 변환하지 않습니다. SKILL은 작성 원칙과 작성→검사→수정 흐름을 안내하고 호스트 에이전트가 실제 문장을 작성합니다. 소개 페이지의 비교는 동일한 가상 사실 목록으로 만든 열거형 초안과 공개 SKILL 지침을 적용한 서술형 초안입니다. 두 작성본을 실제 CLI로 검사했으며, 제품 성능 실험이나 실제 기관 사례로 제시하지 않습니다.
AI 모델이나 API 키가 필요한가요?
정적 CLI 검사에는 필요하지 않습니다. Node.js 20 이상에서 로컬로 실행합니다. Codex·Claude Code·pi와 함께 문서를 작성하면 해당 에이전트의 모델·서비스 조건은 별도로 적용됩니다.
문서를 웹사이트에 올려야 하나요?
문서를 업로드할 필요가 없습니다. 이 사이트는 안내와 고정된 예시를 제공합니다. 실제 문서는 사용자의 로컬 CLI에서 읽습니다. 호스트 AI 에이전트를 함께 사용할 때는 그 에이전트의 외부 전송 설정을 따로 확인하세요.
가격과 라이선스는 어떻게 되나요?
AI Doc Ready는 MIT 라이선스로 공개한 오픈소스 소프트웨어이며, 사용을 위한 구독이나 CLI API 키를 요구하지 않습니다. 호스트 AI 서비스 비용과 컴퓨팅 환경은 사용자가 선택한 서비스의 조건을 따릅니다.
행안부의 공식 인증 도구인가요?
행안부의 공식 인증 도구가 아닙니다. 공식 발표의 작성 원칙을 근거로 삼되, 규칙 ID·검사 문법·심각도·프로파일은 프로젝트가 정의합니다. 공식 원칙 기반 검사와 자체 보완 규칙을 구분해 표시합니다.
검사를 통과하면 사실이나 수치가 맞다는 뜻인가요?
구조 검사 결과만으로 사실·수치·의미 보존을 보장할 수 없습니다. 원문의 단위·날짜·조건·주체·고유명사를 사람이 대조해야 합니다. 검사하지 못한 구조와 수동 검토 항목도 함께 읽어 주세요.
표를 없애거나 모든 병합을 풀어야 하나요?
표는 필요한 정보를 담는 구조로 유지할 수 있습니다. 셀 병합을 전면 금지하지 않으며, 양방향 병합은 단순화 가능성을 검토할 후보로 제안합니다. 제목 존재와 순서 표시를 별도로 검사합니다.
HWP·PDF·Word도 검사할 수 있나요?
0.3.0의 직접 입력 범위는 Markdown(GFM)과 HWPX입니다. Kordoc이 다른 형식을 지원하더라도 AI Doc Ready가 모두 검사하는 것은 아닙니다. HWP 문서는 HWPX로 저장한 작업 사본을 준비하고 내용 보존을 확인하세요.
검사 후 자동으로 문서를 고쳐 주나요?
lint는 원본을 수정하지 않습니다. 사람이 또는 호스트 에이전트가 결과와 원문을 보고 작업 사본을 수정한 뒤 다시 검사합니다. 결과 파일로 원본이나 설정 파일을 덮어쓰는 경로도 차단합니다.
인터넷이 없는 환경에서도 사용할 수 있나요?
준비된 패키지와 의존성이 설치되어 있으면 정적 CLI를 로컬에서 실행할 수 있습니다. npm 설치나 일반 npx의 첫 실행은 레지스트리 접근이 필요할 수 있습니다. 오프라인에서는 설치된 CLI 또는 npx --no-install aidocready를 사용하세요.
어디서 시작하고 문제를 제보하나요?
사용 매뉴얼에서 예제를 내려받아 첫 검사를 실행하세요. 오류 재현과 기능 제안은 GitHub Issues를 사용합니다. 공개 제보에는 민감한 원문 대신 재현 가능한 최소 예제를 준비하세요.
제품 전략 질문
고객 가치에서 출발해 구현 선택과 검증 방법을 설명합니다.
왜 이 제품을 만들었나요?
행정안전부의 AI 친화적 보고서 전면 도입을 계기로, 작성 원칙을 여러 AI 에이전트에서 동일한 정적 검사로 활용하려는 문제에서 시작했습니다. 작성 도구와 검사 기준을 분리하는 것이 제품의 출발점입니다.
사용자가 얻는 핵심 가치는 무엇인가요?
보고서 구조를 반복 점검할 때 같은 검사 엔진과 근거를 사용할 수 있습니다. 어떤 위치를 살펴봐야 하는지, 어떤 항목은 확인하지 못했는지 보여 주어 검토와 재검사를 연결합니다. 시간 절감이나 오류 감소의 실사용 수치는 아직 제시하지 않습니다.
문서 작성과 구조 검사는 어떻게 연결하나요?
ChatGPT·Claude용 작성 지침과 로컬 에이전트 스킬이 작성 원칙을 안내하고, CLI가 재현 가능한 구조 검사를 담당합니다. 명령어 없이 지침을 적용할 수 있으며, 문서 파일의 구조 검사는 CLI에서 별도로 실행합니다.
Kordoc과는 어떤 관계인가요?
Kordoc은 문서 파싱을 맡는 라이브러리 의존성입니다. AI Doc Ready는 Kordoc을 포크하지 않고 추출된 구조에 보고서 규칙을 적용합니다. 파싱과 보고서 정책의 책임을 분리합니다.
현재 품질은 무엇으로 검증하나요?
0.3.0 릴리스 기준 128개 자동 테스트와 Node.js 20·22·24 CI, 메타데이터 정합성, 깨끗한 패키지 설치 검사를 수행했습니다. 사람이 기대 진단을 검토한 초기 회귀 사례는 8개입니다. 이 작은 코퍼스가 전체 행정문서의 정확도나 공식 준수율을 나타내지는 않습니다.
가장 중요한 제품 위험은 무엇인가요?
문서 서식에 따른 오탐과 누락, 정적 검사와 의미 검토를 혼동하는 것이 핵심 위험입니다. 검사 상태·근거·한계를 표시하고, 독립 기대 진단을 가진 사례를 늘려 버전별 회귀를 확인하는 방식으로 대응합니다.
업스트림 변경에는 어떻게 대응하나요?
주간 GitHub Actions가 Kordoc의 안정 릴리스를 확인하도록 구성했습니다. 새 버전이 있으면 pi·DeepSeek Flash로 호환성을 점검하고, 테스트를 통과한 변경을 draft PR로 준비합니다. 병합과 npm 게시는 별도로 검토합니다.
다음 단계의 성공은 무엇으로 판단하나요?
새 기능 수보다 실제 문서의 오탐·누락, 새 사용자의 첫 검사 재현, 배포본의 동작과 버전별 회귀를 우선 확인합니다. 원문 비교와 더 넓은 연동은 별도의 근거와 검증을 갖춘 후 확장할 과제입니다.