도현의 AI 워크플로우

AI 초안에 링크가 있으면 보이는 문구와 실제 주소를 따로 읽어보세요. ‘공식 안내’라는 문구가 자연스럽다고 해서 주소가 해당 기관의 정확한 페이지라는 뜻은 아닙니다. Markdown 원문을 확인한 뒤 최종 게시 화면에서 클릭해 도착 페이지까지 확인합니다. 문법이 맞는지 확인하는 작업과 자료가 맞는지 확인하는 작업은 다릅니다. 주소를 열 수 있어도 제목·내용이 설명한 자료와 다르면 문구나 목적지를 다시 정해야 합니다. 세 번 나눠 봅니다. 문구가 독자에게 의미 있는가 → 주소가 확인한 원문인가 → 최종 화면에서 정확히 이동하는가. 링크가 파랗게 보이는 것만으로 검수를 끝내지 않습니다. 목차 1. 대괄호는 문구, 소괄호는 목적지 2. 주소 안의 괄호와 공백을 살펴보기 3. 최종 화면에서 목적지까지 검수하기 4. 자주 묻는 질문 1. 대괄호는 문구, 소괄호는 목적지 CommonMark 0.31.2의 링크 문법에서 인라인 링크는 대괄호에 담긴 링크 문구 뒤에 소괄호로 목적지와 선택적인 제목을 붙이는 구조입니다. 다음은 이 글에서 만든 실제 공식 문서 주소 예시입니다. CommonMark 링크 규격 [CommonMark 링크 문법](https://spec.commonmark.org/0.31.2/#links) 독자에게 보일 문구는 ‘CommonMark 링크 문법’이며 목적지는 소괄호 속 주소입니다. 마지막의 #links 는 문서 안의 해당 항목을 가리킵니다. 주소를 복사할 때 상세 경로나 이 부분이 빠졌는지도 확인합니다. AI가 쓴 문구를 그대로 믿기보다 확인한 페이지 제목에 맞춰 다듬으세요. 자료가 규격 설명인데 ‘최신 정책 발표’라고 이름 붙였다면 문법은 맞더라도 독자에게 다른 내용을 약속하는 링크가 됩니다. 2. 주소 안의 괄호와 공백을 살펴보기 CommonMark는 주소 안의 괄호를 짝이 맞도록 쓰거나 역슬래시로 처리하는 문법을 정하고 있습니다. 주소를 꺾쇠괄호로 감싸는 형태도 지원합니다. 다음 두 줄은 문법 구조를 설명하기 위한 가상 주소이며 실제 자료 링크...

AI가 만든 작업 목록에서 체크 표시가 있다고 해서 일이 끝난 것은 아닙니다. GitHub Markdown에서 - [ ] 는 미완료 항목, - [x] 는 완료 표시를 만드는 문법입니다. 문법이 맞는지와 실제 완료 근거가 있는지 를 각각 확인하세요. 검토 순서 항목 앞의 하이픈·공백·대괄호를 확인하고, 완료 표시를 결과 파일이나 확인 기록과 대조합니다. AI가 정리한 문장은 완료 증거를 대신하지 않습니다. 목차 1. 체크상자와 일반 목록의 차이 2. AI가 임의로 완료 표시를 붙이지 않게 요청하기 3. 완료에는 작은 근거를 붙이기 4. 코드 블록과 종료된 기능을 구분하기 5. 자주 묻는 질문 1. 체크상자와 일반 목록의 차이 GitHub 문서는 목록 항목 앞에 하이픈과 공백을 쓰고 [ ] 를 붙이면 작업 목록을 만들며, 완료 표시는 [x] 를 사용한다고 설명합니다. GitHub tasklists 안내(영어) 입력 예시 의도 - 자료 링크 확인 일반 목록 항목 - [ ] 자료 링크 확인 미완료 체크 항목 - [x] 자료 링크 확인 완료 표시 항목 대괄호 안이 비어 있어도 공백을 포함한 정확한 문법을 사용합니다. 다른 편집기에서 같은 기능을 지원한다고 추정하지 말고 실제 저장 대상의 미리보기로 확인하세요. 이 글의 코드 예시는 복사할 문법을 보여 주기 위해 글자로 표시했습니다. 2. AI가 임의로 완료 표시를 붙이지 않게 요청하기 초안 요청에는 ‘각 항목을 미완료 상태로 작성하고, 실제 확인 결과가 제공된 항목만 완료로 표시해 주세요’라고 조건을 붙일 수 있습니다. 이 문장은 결과를 보장하는 기능이 아니라 초안 검토를 돕는 자체 제안입니다. - [ ] 공식 자료의 날짜 확인 - [ ] 본문 숫자와 표 대조 - [ ] 공개 화면의 링크 목적지 확인 결과가 없는 단계는 미완료로 두고, 무엇이 필요한지 구체적인 동사로 적습니다. ‘원고 완벽하게 만들기’ 대신 ‘표의 합계를 계산해 본문 숫자와 비교하기’처럼 확인 가능한 항목으로 바꾸면 완료 여부를 판단하기 쉽습니다. 작...

AI가 만든 표를 붙였는데 열이 하나 더 생기거나 설명이 잘렸다면, 셀 안에 들어간 | 부터 살펴보세요. Markdown 표에서는 이 기호가 열 경계를 나누는 역할을 할 수 있습니다. 표의 내용이 맞는지와 표 문법이 맞는지는 따로 확인해야 합니다. 한 셀에 A|B를 쓰고 싶다면 GitHub Markdown 표에서는 내부 세로줄 앞에 역슬래시를 붙인 A\|B 로 표현합니다. 마지막 판단은 실제 게시할 곳의 미리보기에서 합니다. 목차 1. 공식 문서에서 확인한 범위 2. 두 열짜리 독립 예시 3. AI에 다시 요청할 때 보존할 것 4. 발행 전 점검과 FAQ 1. 공식 문서에서 확인한 범위 GitHub의 표 작성 안내는 세로줄과 하이픈으로 표를 만들며, 표 앞에는 빈 줄을 두도록 설명합니다. 셀 내용으로 세로줄을 넣으려면 그 앞에 역슬래시를 붙입니다. 이 설명의 적용 범위는 GitHub에서 쓰는 Markdown 표입니다. 모든 블로그 편집기가 Markdown을 같은 방식으로 해석하는 것은 아닙니다. HTML 편집기에 Markdown 문자열만 붙이면 표 대신 기호가 그대로 보일 수도 있습니다. 글을 올릴 편집기의 지원 형식을 먼저 확인한 뒤 그 형식에 맞게 옮기세요. 2. 두 열짜리 독립 예시 아래는 선택지 이름에 세로줄이 포함된 경우를 위한 자체 예시입니다. 목적은 선택지와 설명을 두 열로 유지하는 것입니다. | 선택지 | 설명 | | --- | --- | | A\|B | 같은 묶음의 이름 | 의도한 결과를 읽기 편한 표로 나타내면 다음과 같습니다. 위 소스의 역슬래시는 표시할 글자의 일부가 아니라 내부 세로줄을 구분하기 위한 문법입니다. 선택지 설명 A|B 같은 묶음의 이름 이 본문 표는 HTML로 구성했습니다. 독자가 결과의 두 열을 비교할 수 있도록 제시한 것이며 이 블로그가 Markdown을 자동 변환한다고 주장하지 않습니다. 3. AI에 다시 요청할 때 보존할 것 수정 요청은 “표를 예쁘게 고쳐 줘”보다 “두 열을 유지하고, 셀 내용인 세로...

AI 이미지의 대체텍스트는 생성 명령을 복사하는 칸이 아닙니다. 완성된 이미지가 글에서 전하는 정보를 짧게 설명하세요. 화면에 없는 대상을 적거나 추측한 상황을 사실처럼 설명하지 않도록 최종 결과와 문맥을 함께 확인합니다. 목차 1. 생성 프롬프트와 대체텍스트의 역할 2. 같은 그림도 본문에 따라 설명이 달라지기 3. 파일명·캡션·이미지 안내를 따로 관리 4. 게시 전 세 번의 대조 5. 자주 묻는 대체텍스트 질문 6. 공식 기준과 자체 점검을 함께 사용 1. 생성 프롬프트와 대체텍스트의 역할 프롬프트는 만들고 싶은 그림을 지시하는 문장이고, 대체텍스트는 완성된 이미지가 본문에서 전달하는 정보를 설명하는 문장입니다. 요청한 장면이 실제 결과물에 모두 나타났다고 가정하면 안 됩니다. 예를 들어 프롬프트에 “두 사람이 손을 흔드는 장면”이라고 썼는데 한 사람만 보이면 두 사람이라고 설명할 수 없습니다. W3C WAI는 정보를 전달하는 이미지의 대체텍스트가 짧은 문구로 핵심 정보를 전해야 한다고 안내합니다. 화면의 모든 작은 장식을 나열하는 일보다 해당 문맥에서 그림이 어떤 의미를 전하는지 파악하는 일이 먼저입니다. 2. 같은 그림도 본문에 따라 설명이 달라지기 다음은 실제 제품 사진이 아닌 가상의 작업 예시입니다. 책상 위 태블릿에 풍경 그림이 있고 사람이 펜을 들고 있다고 가정해 보세요. 태블릿 편집 도구를 설명하는 글에서는 화면과 펜의 관계가 중요할 수 있습니다. 그림의 구도를 설명하는 글에서는 풍경 안의 배치가 더 중요할 수 있습니다. 본문의 목적 설명 초점 가상 대체텍스트 초안 이미지 수정 작업 소개 작업 중인 사람과 도구 풍경 그림을 띄운 태블릿 앞에서 펜을 들고 수정하는 사람 풍경 구성 비교 그림에서 비교하는 배치 전경의 나무와 뒤쪽 언덕을 나누어 배치한 풍경 그림 단순 분위기 장식 정보를 실제로 더하는지 검토 주변 문장과 역할을 확인한 뒤 처리 방식 결정 두 번째 문장은 실제 그림에서 나무와 언덕을 확인한 경우에만 사용할 수 있습니다. 본문에 필요...

AI 초안을 고칠 때는 수정안과 적용 결정을 나눠 보세요. Google Docs 제안 모드로 바꿀 내용을 남기고, 날짜·수치의 근거는 별도로 확인하면 검토할 질문이 명확해집니다. 목차 1. 제안 모드는 수정안을 검토하는 도구 2. 컴퓨터에서 제안 내용을 남기는 순서 3. AI 원고를 볼 때 나누는 검토 항목 4. 가상 사례와 짧은 제안 메모 5. 적용 전 미리보기와 최종 문맥 확인 6. 자주 묻는 질문과 공식 자료 1. 제안 모드는 수정안을 검토하는 도구 Google Docs의 제안 기능은 원본 텍스트를 바로 바꾸지 않고 변경 내용을 제안하는 방식입니다. 소유자가 제안을 적용하면 원래 텍스트가 대체됩니다. AI가 쓴 문장을 더 자연스럽게 고쳤더라도 날짜와 수치가 맞는지 확인한 결과와는 구분해야 합니다. 이 글의 핵심은 문장을 다듬는 동안 확인되지 않은 사실이 최종 원고에 섞이지 않도록 검토 단위를 나누는 것입니다. 제안 모드를 사용했다고 공식 출처 검증이나 게시 승인이 자동으로 이루어지는 것은 아닙니다. 2. 컴퓨터에서 제안 내용을 남기는 순서 Google Docs에서 검토할 문서를 엽니다. 오른쪽 상단의 수정 메뉴에서 제안을 선택하거나, 텍스트 선택 뒤 표시되는 수정 제안 기능을 사용합니다. 바꿀 문장을 수정합니다. 변경된 내용은 색상으로, 삭제 내용은 취소선으로 구분됩니다. 수정 이유가 필요하면 해당 제안에 댓글을 덧붙입니다. Google 공식 안내상 댓글 작성자나 편집자 권한이 있는 사용자는 수정안을 제안할 수 있습니다. 제안 메뉴가 보이지 않으면 현재 권한과 문서 환경부터 확인하세요. 이 글은 검토 목적으로 불특정 다수에게 문서를 공개하도록 권하지 않습니다. 3. AI 원고를 볼 때 나누는 검토 항목 바꿀 내용 제안에 남길 것 따로 확인할 것 긴 문장 짧게 나눈 문장과 이유 핵심 조건이 빠지지 않았는지 날짜·가격 변경할 값과 원문 위치 공식 자료의 기준일·적용 대상 확정적인 표현 조건을 명시하는 수정안 근거가 실제로 확정을 뒷받침하는지 경험처럼 보이...

검수한 시점을 나중에 찾고 싶다면 Google Docs의 버전에 이름을 붙이고, 수정 이유는 별도로 남기세요. 이름을 붙이는 동작, 예전 내용으로 복원하는 동작, 예전 내용의 사본을 만드는 동작은 결과가 다릅니다. 초안을 비교하려다 공동 문서 전체를 되돌리지 않도록 목적부터 정합니다. 목차 1. 세 동작의 목적부터 정하기 2. 이름은 완료 범위가 보이게 쓰기 3. 비교 사본을 만들 때 남길 네 칸 4. 질문과 공식 도움말 1. 세 동작의 목적부터 정하기 Google은 이전 버전 확인에 편집 권한이 필요하다고 안내합니다. 버전 기록에서 이전 내용을 볼 수 있고, 그 버전을 복원하거나 사본으로 만들 수 있습니다. 이름을 지정한 버전은 버전 기록에서 식별하고 병합되지 않도록 남기는 데 쓰입니다. 목적 맞춰 볼 동작 먼저 적을 질문 검수 시점 찾기 버전 이름 지정 어떤 검수까지 끝났나? 현재 내용 되돌리기 이 버전 복원 공동 작업 중인 최신 내용은 무엇인가? 이전 안을 따로 비교 사본 만들기 새 문서를 어디에 두고 누구와 공유할까? 단순히 이전 문장을 읽는 일과 현재 문서를 바꾸는 일도 구분합니다. 이 표는 버튼을 누르기 전 목적을 정리하는 도구이며, 회사의 문서 보존·공유 정책을 대신하지 않습니다. 2. 이름은 완료 범위가 보이게 쓰기 “최종”만 반복하기보다 “10월2일_출처링크확인”이나 “표단위검수후_댓글반영전”처럼 범위를 드러낼 수 있습니다. 같은 문서에서 숫자와 출처를 확인했더라도 문체 검수는 아직일 수 있으므로 어떤 작업까지 끝났는지를 이름에 남기세요. 버전 이름은 사실 확인의 증거 그 자체가 아닙니다. 공식 자료 주소, 기준일, 바뀐 수치와 이유는 검수 노트나 댓글에 별도로 남겨야 다음 사람이 내용을 대조할 수 있습니다. Google 안내는 문서당 이름 있는 버전 최대 40개, 스프레드시트 최대 15개를 제시합니다. 모든 사소한 입력마다 이름을 추가하기보다 다시 찾을 필요가 있는 검수 지점을 선택하세요. 3. 비교 사본을 만들 때 남길 네 칸 기록 예...

AI 초안의 글자 색이나 배경이 Google Docs로 따라오면, 서식 없이 붙여넣기와 문서 구조 확인을 나눠 진행하세요. PC용 Google Docs 공식 단축키에는 Ctrl+Shift+V가 서식 없이 붙여넣기로 안내됩니다. 하지만 원본의 표·링크·목차까지 원하는 구조로 완성됐다고 뜻하지는 않습니다. 원고를 보존한 뒤 짧은 문단으로 표시 방식을 먼저 비교하고, 제목·표·출처 링크를 문서에서 다시 확인하는 작업 순서를 소개합니다. 초안의 사실 검증은 별도 단계로 유지합니다. 목차 1. 작은 문단으로 두 붙여넣기 비교 2. 서식 정리와 정보 손실 구분하기 3. 본문 확정 뒤 구조와 링크 확인 4. 자주 묻는 질문 1. 작은 문단으로 두 붙여넣기 비교 문서 전체를 한 번에 고치기 전에 새 작업 구간에 짧은 문단을 붙여넣어 보세요. 일반 붙여넣기와 서식 없는 붙여넣기의 글자 색·배경·줄바꿈을 비교합니다. 이미 작성한 중요한 원문을 덮어쓰지 않도록 원본과 작업 사본을 보존합니다. 방법 공식 PC 단축키 작업에서 확인할 것 일반 붙여넣기 Ctrl+V 원본의 표시가 따라오는지 서식 없이 붙여넣기 Ctrl+Shift+V 글자·문단의 기본 표시 실행 취소 Ctrl+Z 원하는 구간만 되돌아왔는지 Google은 언어와 키보드에 따라 일부 단축키가 작동하지 않을 수 있다고 안내합니다. 키를 눌렀는데 동작이 다르면 계속 반복하지 말고 Docs의 실제 메뉴와 단축키 도움말을 확인하세요. 2. 서식 정리와 정보 손실 구분하기 텍스트가 깔끔해 보여도 표의 열 구분이나 링크 목적지가 보존됐는지는 따로 확인해야 합니다. 특히 가격·날짜·수량이 있는 표는 제목과 값의 관계를 원문과 대조합니다. “원, 명, 일” 같은 단위가 다음 줄로 떨어져 의미가 달라지지 않았는지 살펴보세요. 대조할 부분 원문에서 남길 기준 작업 문서 확인 표 열 제목과 행의 대응 값이 어느 항목에 속하는지 제목 소제목의 순서 본문 문장과 구분되는지 출처 페이지 제목·주소 클릭 가능한 실제 목적지 강조 의미상 필요한 표...