저 역시 클로드 코워크와 옵시디언으로 자료를 관리하면서 같은 벽에 부딪혔습니다. 리서치한 자료는 계속 쌓이는데, 막상 글을 쓰거나 강의를 준비할 때 그 원천 자료를 어떻게 다시 찾아 참조할지가 매번 숙제였습니다. 새 자료가 들어올 때마다 기존 노트와 연결하고 요약을 정리하는 뒤처리가 사람 손으로는 번거로워, 노트는 쌓이기만 하고 죽은 창고가 되곤 했습니다. 이 글은 그 문제를 푸는 이야기입니다. 옵시디언 볼트를 클로드 코워크가 직접 읽고 정리해, 쌓아 둔 자료를 원천 소스째 다시 꺼내 쓰는 방식, 그것이 LLM 위키입니다. 설명을 풀어가면서 제 경험도 조금씩 꺼내 보겠습니다.

LLM 위키는 검색이 아니라 누적이다

LLM 위키를 한 줄로 말하면, AI가 내 자료를 읽고 스스로 정리하고 연결해서 관리하는 나만의 위키백과입니다. 새 앱을 깔라는 말이 아닙니다. AI에게 자료 정리를 맡기는 운영 방식입니다. AI 연구자 앤드레이 카파시(Andrej Karpathy)가 2026년 4월 공개했습니다. 사람은 자료를 모으고 질문을 던지는 일만 하고, 요약·연결·정리는 AI가 전담합니다. 1945년 배니버 부시가 상상했던 ‘메멕스'(개인이 모든 지식을 연결해 보관하는 기계)를, 정리를 맡아줄 AI가 등장하면서 비로소 실현한 셈입니다.

자주 쓰는 RAG(검색 증강 생성)와 비교하면 차이가 분명합니다. RAG는 질문이 들어올 때마다 자료 더미에서 관련 조각을 그때그때 찾아옵니다. 미리 정리해 두지 않으니, 여러 문서를 묶어야 하는 질문이면 매번 조각을 새로 꿰맞춥니다. 위키는 자료를 넣는 순간 요약·연결·모순 정리를 끝내 둡니다. 도서관에 비유하면, RAG는 질문할 때마다 서가를 처음부터 뒤지는 사서이고, 위키는 미리 주제별로 분류하고 색인까지 붙여 둔 서가입니다. 한 번 정리해 두고 계속 최신 상태로 유지하는, 쌓일수록 단단해지는 지식입니다.

규모로 나누면 선택이 쉬워집니다. 경계가 분명한 개인 지식, 약 100개 자료 이하라면 위키가 맞습니다. 대규모이거나 실시간이거나 여러 사람이 함께 쓰는 지식이라면 RAG입니다. RAG를 버리라는 뜻이 아닙니다. 작으면 위키, 커지면 위키와 검색을 함께 쓰는 하이브리드입니다.

왜 옵시디언과 코워크인가

핵심 비유는 하나입니다. 옵시디언(Obsidian, 메모를 마크다운 파일로 저장하는 노트 앱)은 작업실, AI는 그 안에서 일하는 작업자, 위키는 작업 결과물입니다. 프로그래머가 코드를 다루듯, AI가 지식을 다룹니다.

코워크(Cowork)는 내 컴퓨터의 파일을 직접 읽고 쓰는 AI 도구입니다. 옵시디언 노트가 평범한 텍스트 파일이라, 따로 연동 작업 없이 코워크가 그대로 읽고 씁니다. 저는 일정 관리부터 글쓰기, 강의 준비, 리서치까지 옵시디언 볼트 하나에서 운영하는데, 코워크가 이 볼트를 통째로 읽고 쓰기 때문에 도구를 옮겨 다닐 일이 없습니다. 일반 챗봇과의 차이는 네 가지입니다. 일반 챗은 그때 올린 파일만 잠깐 보고, 대화가 끝나면 사라지며, 결과가 대화창 글에 그칩니다. 코워크는 내 노트 폴더를 직접 읽고, 노트로 영구 보관하고, 워드·PPT 같은 파일로도 만들어 내고, 노트와 규칙 파일로 맥락을 이어갑니다.

3계층으로 시작한다

세팅은 단순합니다. 폴더 두 개와 파일 하나면 시작합니다.

raw는 불변 원천입니다. AI가 읽기만 하고 수정하지 않는 진실의 출처입니다. wiki는 AI가 전적으로 소유하는 마크다운 페이지로, 요약·개념·비교가 여기 쌓입니다. CLAUDE.md는 스키마이자 계약으로, 페이지 명명·공통 섹션·출처 표기·모순 처리 규칙을 정의합니다.

CLAUDE.md가 핵심입니다. 이 파일이 AI를 규율 있는 위키 관리자로 만듭니다. 처음부터 완성하지 않습니다. 첫 자료를 넣으며 드러난 규칙을 누적해, 위키와 규칙을 함께 키웁니다. 저는 볼트 안에 ‘LLM 위키’ 폴더 하나를 만들어 이 구조를 두고, 따로 있던 리서치 노트 폴더까지 원천 자료로 등록해 두었습니다. 여기에 내용 목차 역할의 index.md와 시간 기록용 log.md를 빈 파일로 둡니다.

Ingest·Query·Lint 세 작업으로 굴린다

운영은 세 작업의 반복입니다.

Ingest는 넣기입니다. 자료를 정독하고, 쓰기 전에 핵심을 먼저 논의하고, 페이지를 작성하고, 관련 페이지에 링크를 걸고, 목차와 기록을 갱신합니다. 자료 한 건이 페이지 10~15개를 건드립니다. 카파시는 한 번에 하나씩 넣고 요약을 직접 확인하는 단건 방식을 권합니다. 한꺼번에 몰아 넣으면 품질 통제가 약해집니다. 저는 리서치 노트를 바로 위키로 올리지 않고, 같은 주제가 세 건 넘게 모이고 다시 쓸 일이 분명할 때만 정식 위키 페이지로 승격합니다.

Query는 끌어내기입니다. 목차를 먼저 읽어 후보를 좁히고, 본문을 정독해 출처와 함께 답을 만듭니다. 핵심은 재편입입니다. 좋은 답과 새로 발견한 연결을 대화 기록에 묻어두지 않고, 새 페이지로 편입해 누적합니다.

Lint는 점검입니다. 모순, 외톨이 페이지, 낡은 주장, 빠진 개념을 주기적으로 찾아 보강합니다. 구조 점검은 자동, 의미 점검은 AI, 시각 점검은 그래프뷰로 나눠 봅니다.

세 작업을 스킬 3종 세트로 고정한다

세 작업을 매번 손으로 지시하면 절차가 흔들립니다. 작업마다 스킬(반복 절차를 고정해 두는 코워크 기능)을 하나씩 붙여 두면 같은 품질로 반복됩니다. 저는 다음 세 가지를 한 묶음으로 씁니다.

첫째, wiki-ingest는 넣기 담당입니다. 리서치 노트나 웹 자료, 메모를 읽어 위키 페이지로 만듭니다. 개념 페이지와 경험 페이지를 나눠 만들고, 출처와 갱신일을 규칙대로 붙이고, 목차와 링크를 자동으로 정리합니다. “이 자료 위키에 넣어줘” 한마디면 페이지가 생기고 연결까지 끝납니다.

둘째, wiki-activate는 활용 담당입니다. 쌓인 위키를 읽어 답을 만들거나, 블로그·강의·책 원고로 풀어냅니다. 사실 이 글도 제 위키에 쌓아 둔 페이지 여섯 개를 wiki-activate로 읽어 작성했습니다. 위키 밖 지식을 섞지 않도록 막는 옵션이 있어, 답을 내 위키 범위 안으로 묶을 수 있습니다.

셋째, wiki-audit는 점검 담당입니다. 위키가 커지면 같은 내용이 겹치거나, 서로 어긋나거나, 오래된 페이지가 생깁니다. 중복·충돌·신선도·구조를 점검해 보고서로 보여주고, 병합이나 삭제 같은 위험한 작업은 확인을 받은 뒤에만 처리합니다.

세 스킬은 Ingest·Query·Lint 세 작업과 그대로 짝을 이룹니다. 넣을 때 wiki-ingest, 꺼내 쓸 때 wiki-activate, 건강을 볼 때 wiki-audit입니다. 작업을 기억해 두지 않아도, 스킬 이름만 부르면 절차가 매번 같게 돌아갑니다.

한 번 정제하면 비용이 사라진다

위키는 저장소가 아니라 정제된 생산 원천입니다. 한 번 정리한 페이지는 블로그·강의·책으로 후크와 문체만 바꿔 분기합니다. 실제로 저는 위키 페이지 하나에서 블로그 글과 강의 슬라이드가 동시에 갈라져 나오는 걸 자주 경험합니다. 그 산출물에서 나온 새 통찰은 다시 위키로 돌아옵니다. 콘텐츠를 만들수록 위키가 자라고, 위키가 자랄수록 다음 콘텐츠가 빨라집니다.

주의할 지점도 분명합니다. AI는 근거 없는 질문에 사실이 아닌 답을 지어낼 때가 있습니다. 자료가 약 5만~10만 토큰을 넘으면 탐색이 어려워집니다. 넣는 자료의 품질이 결과를 좌우합니다. 한 측정에서 위키가 RAG 대비 토큰 약 95% 절감, 응답 약 70배 향상을 보고했지만, 단일 업체 수치이므로 그대로 받아들이기보다 조건을 확인하는 편이 안전합니다.

기준을 옮기면 됩니다. 노트를 더 많이 쌓는 것이 목표가 아닙니다. 쌓은 노트를 AI가 유지하게 만들어, 저장할수록 똑똑해지는 구조로 바꾸는 것입니다.

06/10(수) 저녁 – (온라인 강의)옵시디언 + 코워크(초급+) — 내 AI 작업 환경 구축

The post 노트는 쌓는데 왜 다시 안 볼까 — AI가 정리하는 LLM 위키 first appeared on HONGS LAB — AI 글쓰기·콘텐츠 전략가 홍순성.

옵시디언을 설치하고 첫 화면을 엽니다. “Welcome to Obsidian” 노트 한 장이 떠 있지만, 그 다음에 무엇을 해야 할지 손이 멈춥니다. 노션처럼 미리 짜여진 템플릿이 없고, 에버노트처럼 노트북 구조도 보이지 않습니다. 도구가 단순한 만큼 시작점이 모호합니다.

1. 노트 한 장 = 텍스트 파일 한 개

옵시디언은 노트를 내 컴퓨터에 마크다운 평문(.md) 파일로 저장합니다. 노션·에버노트가 노트를 서비스 데이터베이스에 두는 것과 다른 지점입니다.

도구 독립이 가장 큰 차이입니다. 옵시디언이 사라져도 .md 파일은 그대로 남습니다. 메모장이나 다른 텍스트 편집기에서도 같은 노트가 열립니다. 인터넷 연결이 끊겨도 노트를 쓰고 읽습니다.

작성 방식도 단순합니다. #로 제목, **로 강조, -로 목록을 만듭니다. 워드처럼 메뉴 버튼을 누를 일이 없습니다.

2. 볼트(Vault) = 작업 공간 단위

볼트는 노트 파일과 옵시디언 설정이 담긴 하나의 폴더입니다. 볼트 한 개가 곧 작업 공간 한 개입니다.

초급자에게 권장하는 답은 분명합니다. 단일 볼트로 시작합니다. 옵시디언 사용자 대다수가 단일 볼트로 운영합니다. 업무·개인·리서치를 분리하고 싶다면 볼트를 나누지 말고 같은 볼트 안에서 폴더로 구분합니다.

다중 볼트의 비용이 분명합니다. 옵시디언은 한 번에 하나의 볼트만 다루고, 볼트끼리는 위키링크가 끊깁니다. 노트 사이 연결이 차단된다는 의미입니다. 분리가 필요한 경우는 공개 범위가 완전히 다르거나 보안 경계가 필요할 때로 제한합니다.

동기화는 두 갈래입니다. 본인 클라우드(iCloud·구글드라이브·드롭박스) 폴더에 볼트를 두면 별도 비용 없이 동기화됩니다. 옵시디언이 직접 제공하는 유료 Sync 서비스를 쓰면 종단간 암호화·기기 간 충돌 해결이 추가됩니다. 초급자에게는 본인 클라우드 방식이 부담이 적습니다.

3. 위키링크 = 노트끼리 연결

옵시디언이 다른 메모 앱과 결정적으로 다른 지점입니다. 메모 앱은 노트를 저장합니다. 옵시디언은 노트끼리 연결합니다. 노트 안에 [[다른 노트 이름]]이라고 쓰면 그 노트로 가는 링크가 자동 생성됩니다. 대소문자도 구분하지 않습니다.

한 번 링크를 걸면 두 가지가 동시에 작동합니다. 백링크는 “이 노트를 가리키는 다른 노트들”을 자동으로 표시합니다. 한 노트의 영향 범위가 즉시 확인됩니다. 그래프뷰는 노트를 점, 연결을 선으로 시각화합니다. 시간이 갈수록 노트가 그물망처럼 묶여 머릿속을 닮은 작업 공간이 만들어집니다.

셋이 토대, 나머지는 그 위에

옵시디언의 폴더 구조·태그·dataview·플러그인은 모두 평문 파일·볼트·위키링크 위에서 작동합니다. 토대를 먼저 잡으면 이후 학습이 한 단계씩 누적됩니다.

노트 5장을 만들고, 같은 볼트 안에서 위키링크로 연결하고, 그래프뷰로 결과를 확인합니다. 이 동선을 마친 뒤에 폴더와 태그를 추가합니다. 도구의 토대를 손으로 익힌 다음의 학습은 다음 단계로 자연스럽게 넘어갑니다.

The post 옵시디언 설치하고 가장 먼저 익혀야 할 3가지 first appeared on HONGS LAB — AI 글쓰기·콘텐츠 전략가 홍순성.

이 불편을 겪다 보면 생각이 한 방향으로 모입니다. 대화하면서 그때그때 따로 저장해 두고 싶다. 여러 주제로 나뉜 답을 한곳에 모아 두고 싶다. 이렇게 느끼는 사람이 늘고 있습니다. 도구를 골라 쓰는 단계는 지났고, 주고받은 것을 어디에 어떻게 모을지가 새로운 고민으로 떠올랐습니다. 저는 이 고민을 작업 방식이 옮겨가는 신호로 봅니다. 이 글을 쓰는 이유가 거기에 있습니다.

무엇을 쓰는가에서, 어떻게 다루는가로

얼마 전까지 가장 많이 받던 질문은 “무엇을 쓰는가”였습니다. 클로드(Claude)냐 GPT냐, 노트북LM(NotebookLM)이냐 나노바나나(NanoBanana)냐. 도구마다 강점이 갈렸기 때문에, 글은 클로드, 자료 요약은 노트북LM, 이미지는 나노바나나처럼 도구를 골라 쓰는 감각이 곧 활용 능력이었습니다. 한 번의 질문과 한 번의 답으로 끝나는 구조에서는 이 감각이 가장 중요했습니다.

지금은 질문이 달라졌습니다. “코워크(Cowork)를 어떻게 쓰느냐”, “에이전트(Agent)를 어디에 붙이느냐”로 옮겨갑니다. 같은 AI를 두고도 묻는 자리가 바뀌었습니다. 도구를 고르는 문제에서, 주고받은 것을 다루는 문제로 무게가 넘어간 것입니다.

지금 일어나는 이동 — 묻는 도구에서 쌓는 도구로

이 변화는 한 단계 더 나아갑니다. 사용자는 더 이상 한 번의 질문으로 끝내지 않습니다. AI와 주고받은 내용을 쌓고, 쌓인 자료를 다시 입력해, 원하는 결과물로 만들어 갑니다. 대화가 일회성 응답이 아니라 작업의 재료가 되는 구조입니다. 이 흐름에서 코워크와 에이전트가 중심으로 들어옵니다. 한 번 답하고 끝나는 도구가 아니라, 여러 단계를 이어 받아 처리하는 도구로 무게가 옮겨갔습니다.

핵심 축은 로컬 저장과 활용

이 변화의 중심축은 결국 로컬(Local)에 저장하고 활용하는 부분입니다. 주고받은 자료가 웹 대화창에만 남으면 쌓이지 않습니다. 흩어지고 사라집니다. 그래서 옵시디언(Obsidian) 같은 로컬 저장소의 역할이 커집니다. 작업의 앞단에서 자료를 로컬에 모아 두고, AI가 그 자료에 직접 접근해 바로 쓰는 방식입니다. 단순히 웹에 저장하는 것과, 로컬 파일을 열어 그대로 작업에 투입하는 것은 다른 층위의 일입니다.

앞단을 여는 도구 — 클로드 코드와 코덱스

여기서 클로드 코드(Claude Code)나 코덱스(Codex) 같은 도구가 중심 역할을 합니다. 이들은 대화창 안에 갇혀 있지 않습니다. 로컬 폴더에 접근하고, 파일을 읽고, 결과를 다시 파일로 남깁니다. GPT 계열의 코덱스도 같은 방향을 향합니다. 묻고 답하는 인터페이스를 넘어, 사용자의 작업 환경 안으로 들어와 자료와 저장소를 직접 다루는 단계입니다. 옵시디언 같은 저장소가 단순 보관함을 넘어 작업의 기반으로 확장되는 이유가 여기 있습니다.

블로그 글쓰기에서 본 변화

블로그 글쓰기가 이 변화를 잘 보여줍니다. 예전에는 주제만 던지고 “이 주제로 글 한 편 써 줘”라고 요청했습니다. 결과물은 매끄럽지만 어딘가 비어 있었습니다. 누구나 쓸 수 있는 일반론이었고, 제 경험도 제 관점도 담기지 않았습니다.

지금은 방식이 다릅니다. 평소에 강의 후기, 작업 메모, 수강생 질문, 실패한 시도까지 자료로 모아 둡니다. 한 폴더에 꾸준히 쌓아 둔 기록입니다. 글을 쓸 때는 이 자료를 AI가 읽게 합니다. 그러면 출발점이 달라집니다. 빈 화면에서 일반론을 만들어 내는 것이 아니라, 제가 실제로 겪은 사례 위에서 글이 세워집니다.

차이는 분명합니다. 한쪽은 도구가 채워 넣은 글이고, 다른 한쪽은 제가 쌓은 자료를 도구가 정리한 글입니다. 뒤쪽에는 제 시간과 경험이 들어가 있습니다. 그래서 같은 도구를 써도 결과가 갈립니다. 결국 글쓰기의 질은 도구의 성능이 아니라, 무엇을 얼마나 쌓아 두었는가에서 갈립니다.

사용자가 마주한 변수

변화의 폭이 넓고 속도가 가파릅니다. 사용자 입장에서는 어디에 발을 맞춰야 할지 변수가 늘어납니다. 도구 하나를 익히면 되던 시기와 달리, 지금은 코워크와 에이전트, 클로드 코드와 코덱스, 그리고 옵시디언 같은 저장소까지 함께 이해해야 하는 국면으로 들어섰습니다. 이 전체 그림을 파악하는 데에는 시간과 비용, 그리고 직접 부딪쳐 본 경험이 함께 쌓여야 합니다.

지금이 그 시점입니다

그래서 지금이 이 변화를 이해하고 몸에 익혀야 할 시점이라고 봅니다. 어떤 도구가 더 좋은가를 비교하던 질문은 이제 두 번째입니다. 자료를 어디에 쌓고, 그 자료를 AI가 어떻게 직접 다루게 할 것인가가 먼저입니다. 도구를 고르던 시대에서, 쌓아서 만드는 시대로 넘어가고 있습니다. 이 이동을 먼저 읽고 준비하는 사람과 그렇지 않은 사람의 작업 결과는 시간이 갈수록 벌어진다고 봅니다.

06/10(수) 저녁 – (온라인 강의)옵시디언 + 코워크(초급+) — 내 AI 작업 환경 구축

The post AI 도구를 고르던 시대에서, 쌓아서 만드는 시대로 first appeared on HONGS LAB — AI 글쓰기·콘텐츠 전략가 홍순성.

같은 작업을 반복하는 사람일수록 이 문제가 큽니다. 강의 자료, 책 챕터, 블로그 글, 고객 응대 메일까지 — 형식이 비슷한 작업인데 매번 톤·구조·근거가 흔들립니다. 도구는 빨라졌지만 일은 줄지 않습니다.

이 흐름을 뒤집으려면 도구 하나를 더 잘 쓰는 것으로 부족합니다. 스킬·코워크·옵시디언 세 도구를 한 동선 위에 올려야 합니다.

1. 세 도구의 역할 분담

세 도구는 각자 다른 일을 합니다. 한 도구가 다른 도구를 대체하지 않습니다.

옵시디언은 누적과 검색에 강합니다. 코워크는 실행과 자동화에 강합니다. 스킬은 절차 고정에 강합니다. 어느 하나가 빠지면 다른 둘로 채우기 어렵습니다. 옵시디언만 쓰면 자료는 쌓이지만 실행이 멈춥니다. 코워크만 쓰면 실행은 되지만 자료는 휘발됩니다. 스킬만 있으면 절차는 있지만 그 위에 올릴 자료가 없습니다.

세 도구가 한 동선 위에 있을 때 사용자 한 줄 지시가 자료 읽기 → 작업 실행 → 결과 저장까지 끊김 없이 흘러갑니다. “강의 노트의 R_03을 강의 슬라이드 1꼭지로 만들어줘” 한 줄이면 됩니다. [LINK: 코워크 사례 7건]

2. 3가지 관점 — 운영 구조·자산 누적·품질 전환

세 도구의 결합은 단순히 자료를 모으는 단계를 넘어, 그 자료를 시간이 갈수록 가치가 커지는 자산으로 만듭니다. 세 가지 관점에서 일하는 방식이 바뀝니다.

운영 구조 — 일이 흐르는 길을 만듭니다. 한 번의 대화가 아니라 작업이 이어지는 동선입니다. 오늘 결과가 내일의 입력이 됩니다. 강의 노트의 한 줄이 다음 주 슬라이드의 출발점이 되고, 그 슬라이드가 다시 책 챕터의 자료가 됩니다.

자산 누적 — 경험은 노트에, 노하우는 스킬에 쌓입니다. 작업이 끝날 때마다 결과가 옵시디언 폴더에 남고, 반복되는 절차는 SKILL.md 파일로 굳어집니다. 한 번 정리한 지식이 다음 작업에서 그대로 살아남습니다.

품질 전환 — 화두가 속도에서 품질로 이동합니다. AI 도입 초기의 감동은 “빨라졌다”였습니다. 그러나 어느 순간부터 더 빠른 속도가 더 좋은 결과로 이어지지 않습니다. 잘 만드는 자리는 자료가 누적된 곳, 절차가 고정된 곳, 작업 동선이 끊기지 않는 곳에서 만들어집니다.

세 관점은 따로 작동하지 않습니다. 운영 구조가 잡혀야 자산이 누적되고, 자산이 누적되어야 품질이 올라갑니다.

3. 자주 하는 오해 3가지

세 도구를 시도하는 사람들이 자주 막히는 지점이 있습니다.

오해 1. 스킬은 프롬프트의 다른 이름이 아닙니다. 프롬프트는 한 번 쓰고 사라집니다. 스킬은 SKILL.md 파일로 저장되어 트리거 한 단어로 반복 호출됩니다. 같은 작업의 결과가 매번 같은 품질로 나옵니다.

오해 2. 코워크는 챗봇의 확장이 아닙니다. 챗봇은 답을 줍니다. 코워크는 일을 합니다. 사용자 컴퓨터의 폴더를 직접 읽고, 파일을 만들고, 다단계 작업을 끝까지 수행합니다.

오해 3. 옵시디언은 메모 앱이 아닙니다. 메모 앱은 노트를 저장합니다. 옵시디언은 노트끼리 연결합니다. 위키링크와 백링크가 자동으로 그물망을 만들고, 그래프뷰가 그 구조를 보여줍니다. AI 시대에는 메모보다 연결된 노트가 자산으로 작동합니다.

세 오해를 풀면 도구 선택이 분명해집니다. 답을 받고 싶으면 채팅창, 일을 시키고 싶으면 코워크, 자산을 쌓고 싶으면 옵시디언입니다. 셋 다 필요한 사람에게는 한 동선이 답입니다.

도구는 늘었습니다. 자산도 늘어야 합니다. 세 도구를 한 동선 위에 올리면 매일의 작업이 그대로 자산이 됩니다. 오늘 어떤 도구 하나만 쓰고 있다면, 빠진 두 도구가 무엇인지 먼저 점검해 보십시오. 그 점검이 다음 한 달의 작업 방식을 바꿉니다.

06/10(수) 저녁 – (온라인 강의)옵시디언 + 코워크(초급+) — 내 AI 작업 환경 구축

The post 클로드 코워크와 옵시디언, 왜 함께 쓰는가 first appeared on HONGS LAB — AI 글쓰기·콘텐츠 전략가 홍순성.

문제는 프롬프트가 작업의 범위와 한계를 명시하지 않았기 때문입니다. “보강해줘”와 “최소 수정해줘”는 출발점부터 다른 작업인데, 같은 문장 구조로 요청하면 AI가 어느 쪽을 택할지 알 수 없습니다. 수정 모드 4종을 분리하고, 각 모드의 범위·금지 사항·분량 가드레일을 함께 명시한 이유입니다.

상황별 선택

• 원고가 짧고 빈약함, 살을 붙여야 함 → 1안 보강형
• 작가 톤이 강함, 거의 손대지 말고 다듬기만 → 2안 최소 수정형
• 구조가 흔들리거나 일관성이 약함 → 3안 논리 완성형
• 문장은 괜찮은데 단락 간 흐름이 끊김 → 4안 흐름·연결성

[1안: 보강형 수정 – 내용을 더 채워야 할 때]

이 원고를 보강하면서 문장을 다듬어줘.

수정 범위

• 핵심 메시지가 약한 곳에 근거·사례·판단 기준을 추가한다
• 한 문장으로 압축된 곳은 2~3 문장으로 풀어 설명한다
• 추상적인 표현은 행동·상태·결과를 설명하는 단어로 교체한다
• 문장 간 논리 연결이 끊긴 곳에 연결 문장을 삽입한다

금지 사항

• 작가의 관점·판단·결론을 바꾸지 않는다
• 새로운 주장·사례를 임의로 만들지 않는다 (원문에 단서가 있을 때만 확장)
• 분량을 1.5배 이상 늘리지 않는다
• 금지어 사용 금지: 혁신적인·획기적인·완벽한·매우·쉽게·빠르게·~할 수 있습니다

표시 방법

• 추가한 문장·구절: 굵게
• 삭제한 부분: 취소선
• 교체한 부분: 기존 → 신규

문체

• ~합니다체 유지, 축약형 금지(됐습니다 → 되었습니다)
• 능동형·단정형 우선, 감탄형 최소화

작업 후 첨부

• 보강한 항목 3~5개를 “어디를 / 왜” 1줄씩 정리
• 분량 변화: 원본 N자 → 수정 N자

[2안: 최소 수정형 – 원문을 거의 유지할 때]

이 원고의 변경을 최소화하면서 문장만 자연스럽게 다듬어줘.

수정 범위

• 문법 오류·오탈자·중복 표현만 정리한다
• 어색한 어순·접속어만 교체한다
• 의미가 모호한 문장은 명확하게 다듬되, 단어 1~2개 수준으로만 손댄다

금지 사항

• 문장을 새로 추가하지 않는다
• 문단 구조·순서를 바꾸지 않는다
• 원문에 없는 내용·사례를 만들지 않는다
• 작가 톤을 평탄화하지 않는다 (개성 있는 표현은 보존)

표시 방법

• 교체한 부분: 기존 → 신규
• 삭제한 부분: 취소선
• 손댄 문장 수가 전체의 30%를 넘으면 작업 중단, 사용자에게 확인 요청

문체

• ~합니다체, 축약형 금지
• 금지어 발견 시 자동 교체

작업 후 첨부

• 손댄 문장 수 / 전체 문장 수
• 가장 크게 바꾼 3개 문장과 이유 1줄

[3안: 논리 완성형 – 구조·일관성을 강화할 때]

이 원고의 논리적 완성도를 끌어올려줘.

점검 축

1. 핵심 메시지: 챕터 단위 또는 절 단위로 한 줄 요약이 가능한가
2. 논리 흐름: 주장 → 근거 → 사례 → 시사점 구조가 살아 있는가
3. 일관성: 앞 단락의 주장과 뒷 단락의 결론이 어긋나지 않는가
4. 중복: 같은 메시지가 다른 표현으로 반복되는가
5. 톤: 챕터 전체 톤(설명적·설득적·성찰적 중 어느 쪽)이 일관되는가

수정 작업

• 논리 비약 구간에 연결 문장·전환 문단을 추가한다
• 중복·반복은 한 번으로 통합한다
• 결론이 약한 단락은 판단 기준·시사점을 추가해 마무리한다
• 핵심에서 벗어난 곁가지 문장은 삭제한다

금지 사항

• 작가의 결론·관점을 임의로 바꾸지 않는다
• 새로운 주장·통계·인용을 만들지 않는다
• 챕터 분량을 70%~130% 범위 밖으로 변경하지 않는다
• 금지어·AI 흔적 표현 자동 제거

표시 방법

• 추가: 굵게
• 삭제: 취소선
• 교체: 기존 → 신규
• 단락 이동: [이동: 원래 N번째 단락 → 현재 위치] 주석

작업 후 첨부

• 점검 축 5개에 대해 수정 전/후 상태 1줄씩
• 구조 변경 사항 (단락 이동·통합·삭제) 목록
• 분량 변화

[4안: 흐름·연결성 수정형 – 문단 간 전환이 어색할 때]

이 원고의 문단 흐름과 논리 구조를 점검하고 수정해줘.

점검 순서

1. 각 단락의 핵심 메시지를 한 줄로 추출
2. 단락 간 전환이 매끄러운지 확인 (앞 단락 끝 → 뒤 단락 시작)
3. 첫 문장과 마지막 문장이 원고 주제와 연결되는지 확인
4. 중복된 표현·재진술이 있는지 점검

수정 작업

• 전환이 어색한 단락 사이에 연결 문장 1~2개를 삽입한다
• 같은 메시지가 반복되는 곳은 뒤쪽을 삭제하거나 변형한다
• 도입 문단이 본문 흐름과 어긋나면 도입 문단의 마지막 문장을 다리 문장으로 교체한다
• 마무리 문단이 결론을 회피하면 판단·시사점 1줄을 추가한다

금지 사항

• 단락 자체의 내용·주장을 바꾸지 않는다 (연결·전환만 손댄다)
• 새로운 사례·근거를 추가하지 않는다
• 작가 톤·문체를 평탄화하지 않는다

표시 방법

• 추가한 연결 문장: 굵게
• 삭제한 중복: 취소선
• 교체한 도입·마무리 문장: 기존 → 신규

작업 후 첨부

• 단락별 핵심 메시지 1줄 요약 (수정 후 기준)
• 추가한 연결 문장 목록과 삽입 위치
• 삭제한 중복 표현 목록

The post AI 글쓰기 원고 수정 프롬프트 4종 – 보강·최소·논리·연결 first appeared on HONGS LAB — AI 글쓰기·콘텐츠 전략가 홍순성.

웹 대화창은 첫 번째 시대의 도구다. 질문하면 답이 돌아온다. 매번 새로 시작하고 매번 새로 종료한다. 한 번의 답으로 끝나는 작업에 자연스럽게 맞춰져 있다.

코워크는 두 번째 시대의 도구다. 작업 폴더를 연결하면 클로드(Claude)가 그 폴더에서 직접 일한다. 어제 만든 파일을 읽고, 오늘 결과물을 폴더에 저장하고, 다음 작업의 입력으로 잇는다. 사람이 매번 첨부·다운로드 하지 않아도 작업이 누적된다.

같은 클로드지만 환경이 다르면 일하는 방식이 달라진다. 가장 큰 차이는 “대화 단위 vs 폴더 단위”다. 웹은 1채팅 = 1작업이라 종료하면 휘발성, 코워크는 폴더 = 작업 환경이라 결과물이 누적된다. 나머지 차이는 거기서 파생된다.

1. 기본 환경 — 한 번 쓰고 닫는 채팅 vs 매일 들어가는 작업 폴더

웹 대화창은 한 번 답을 받고 끝나는 구조에 맞춰 설계되었다. 채팅을 닫으면 그 안의 맥락은 다음 대화에 이어지지 않는다. 어제 첨부했던 PDF, 어제 받은 글 초안은 새 채팅에서 다시 첨부해야 한다.

코워크는 작업 폴더 자체를 환경으로 삼는다. 며칠 동안 같은 폴더를 열어 작업을 이어갈 수 있고, 어제 클로드가 만든 파일은 오늘 그 폴더에 그대로 있다. 클로드는 폴더 안 파일을 보고 어디까지 진행했는지 인식한다.

비유하자면 웹은 카페에서 짧은 대화를 나누는 것에 가깝고, 코워크는 본인 사무실에서 일하는 것에 가깝다. 단발 질문에는 카페가 가볍지만, 매일 출근하는 일터로는 사무실이 맞다.

2. 지침 — 1단계 설정 vs 폴더별 계층 설정

가장 큰 차이는 “지침 계층화”다. 웹의 Projects는 프로젝트별 1단계 지침만 설정 가능하지만, 코워크는 CLAUDE.md를 폴더 위계에 따라 여러 개 둘 수 있다.

예를 들어 옵시디언 볼트 루트에 전체 글쓰기 톤·금지어 룰을 두고, 책쓰기 폴더에는 챕터별 분량 규칙을, 강의 폴더에는 슬라이드 폰트·컬러 규칙을, 블로그 폴더에는 채널별 발행 포맷을 각각 둘 수 있다. 클로드는 작업 중인 폴더의 가장 가까운 CLAUDE.md부터 상위로 거슬러 올라가 모두 합쳐서 적용한다.

이 구조의 가치는 “작업 영역마다 다른 규칙”을 만들 수 있다는 점이다. 같은 클로드여도 책쓰기 폴더에서는 작가 톤으로, 보고서 폴더에서는 객관적 톤으로 동작한다. 웹의 Projects는 프로젝트 하나에 하나의 지침이라 영역이 늘어나면 매번 다른 프로젝트를 만들어야 한다.

3. 프로젝트·지식 관리 — 업로드 베이스 vs 폴더 베이스

Projects는 RAG(Retrieval Augmented Generation)를 사용해 “필요한 부분만 자동 검색”하는 방식이라 큰 자료도 다룰 수 있다. 다만 업로드 단계가 끼고, 자료는 클로드 클라우드에 보관된다. 자료가 자주 바뀌면 매번 재업로드가 부담된다.

코워크는 폴더에 파일을 두면 그대로 동작한다. 자료는 본인 컴퓨터에 그대로 있고, 옵시디언 볼트를 작업 폴더로 잡으면 별도 업로드 없이 모든 노트가 즉시 작업 대상이 된다. 1,000개의 노트가 있어도 폴더에 두는 것만으로 끝이다.

자료의 성격에 따라 갈린다. 한 번 만들어두면 거의 안 바뀌는 참조 자료(법령·매뉴얼 등)는 Projects의 업로드 모델이 무리 없다. 매일 갱신되는 작업 자료(글감·고객 노트·강의 기획안)는 코워크의 폴더 모델이 자연스럽다. 보안이 중요한 자료는 본인 컴퓨터에 두는 코워크가 안전한 선택이다.

4. 파일 관리 — 첨부·다운로드 사이클 vs 폴더 직접 작업

파일을 다루는 방식이 가장 직관적으로 갈린다. 웹은 매번 첨부·다운로드 사이클이 끼지만, 코워크는 폴더에 두면 그게 곧 입력이고 저장이다.

이 사이클의 비용은 작아 보이지만 누적되면 크다. 같은 보고서를 5번 수정한다면 웹에선 5번 첨부·다운로드, 파일명 5개 관리, 어느 게 최신본인지 확인하는 작업이 따라온다. 코워크에선 같은 파일을 5번 Edit으로 직접 수정한다. 버전 혼동도, 파일명 관리도 사라진다.

결과물이 다음 작업의 입력이 되는 구조는 코워크가 자연스럽다. 어제 만든 글감 노트가 오늘 글의 자료가 되고, 그 글이 다음 주 강의 사례가 된다. 옵시디언의 위키링크와 결합하면 작업 폴더가 곧 작업 히스토리가 된다.

5. 도구·자동화 — 도구 호출 vs 자동 워크플로우

스킬 자체는 양쪽에서 모두 동작한다. 차이는 “스킬이 결과물을 어디에 두느냐”다. 웹에서 스킬을 호출하면 결과물이 채팅 안에 남지만, 코워크에서 호출하면 폴더에 파일로 저장된다.

이 차이가 결정적이다. 같은 글쓰기 스킬을 호출해도 코워크에선 결과물이 옵시디언 노트로 누적되어 다음 작업의 자료가 된다. 매일 글감 스킬을 호출하면 한 달 뒤에는 30개의 글감 노트가 폴더에 쌓인다. 웹에선 그 30개를 본인이 따로 모아 관리해야 한다.

scheduled-tasks까지 결합하면 매일 아침 자동 작업이 가능해진다. 아침 6시에 오늘 일정 노트를 자동 생성하고, 7시에 관심 분야 뉴스 5건을 브리핑하고, 7시 15분에 1건을 골라 글감으로 만드는 흐름을 한 번 등록하면 매일 같은 결과로 반복된다. 다단계 파이프라인이 코워크에서 가능한 이유는 폴더·스킬·스케줄 세 가지가 한 환경에 묶여 있기 때문이다.

어떤 작업에 어느 환경을 쓰는가

웹 대화창이 적합한 경우

단발 질문·정보 검색 — “이 단어 영어로?”, “이 기능 어떻게 쓰지?” 같이 한 번 답으로 끝나는 작업. 폴더를 만들고 들어갈 이유가 없다.

한 편의 짧은 글쓰기 — 인사말, 공지 한 문단, 짧은 응답 메일 등. 결과를 한 번 받아 그대로 보내면 끝나는 글.

코워크가 적합한 경우

며칠 이어지는 프로젝트 — 책 한 챕터 집필, 강의 한 편 준비, 사업계획서 작성 등. 어제 진행 상황을 오늘 이어가야 하는 모든 작업이 여기 해당한다.

결과물 누적 작업 — 매일 글감 적립, 고객 미팅 노트, 학습 노트 등. 다음 작업에서 어제 결과물을 참조해야 하는 작업.

옵시디언과 묶는 작업 — 옵시디언 볼트를 작업 환경으로 삼는 모든 경우. 위키링크·태그·MOC 노트 구조가 그대로 살아 있어 결과물이 기존 노트망에 연결된다.

매일 반복하는 루틴 — 매일 아침 일정 노트 생성, 뉴스 브리핑, 글감 적립 같은 반복 작업. scheduled-tasks에 등록하면 사람 개입 없이 돌아간다.

다단계 파이프라인 — research-mega-topic → research-report, book-research → book-writing → book-editing 같이 여러 스킬을 차례로 잇는 작업. 각 단계 결과물이 다음 단계 입력이 되는 흐름이 폴더 안에서 자연스럽게 굴러간다.

한 가지 짚을 점

코워크가 항상 더 낫지는 않다. 단순 질문도 코워크에서 하면 폴더·파일 탐색 단계가 끼어 오버헤드가 생긴다. 어디서 어떤 작업을 하느냐가 결과 품질과 시간에 직접 영향을 준다.

판단 기준 두 가지가 명확하다.

1. 작업 폴더가 필요한가
2. 결과물을 누적할 가치가 있는가

이 둘 중 하나라도 “예”라면 코워크, 둘 다 “아니오”라면 웹이 빠르다.

처음 1주일은 한 가지 반복 업무에만 코워크를 적용한다. 매일 글감 적립이나 아침 루틴처럼 누적이 명확한 작업이 시작점으로 무리 없다. 익숙해지면 책쓰기·강의 준비·사업계획서 같은 다단계 프로젝트로 확장한다. 처음부터 모든 작업을 코워크로 옮기면 오히려 오버헤드가 커진다.

The post 클로드 웹 대화창 vs 코워크 — 대화 단위에서 폴더 단위로 first appeared on HONGS LAB — AI 글쓰기·콘텐츠 전략가 홍순성.

스킬을 만드는 이유는 분명합니다. 매번 같은 지시를 반복하지 않기 위해서. 한 번 만들어 두면 다음 작업은 그 위에서 시작하기 위해서. 같은 일을 맡길 때마다 비슷한 품질의 결과를 얻기 위해서입니다.

그런데 막상 만들어 보면 의도와 다르게 작동합니다. 지시가 모호하거나, 판단 기준이 적혀 있지 않거나, 머릿속에만 있던 단계가 빠져 있습니다. 결과의 차이는 스킬을 만든 방식에서 갈립니다. 스킬의 기본을 얼마나 갖추었는가의 문제입니다.

여기서 기본이란 스킬에 담길 작업의 순서, 판단 기준, 산출물의 표준을 가리킵니다. 이 기본을 어디서 가져오느냐에 따라 스킬을 만드는 방법이 두 갈래로 나뉩니다. 첫째는 사용자 자신의 경험에서, 둘째는 사전 조사에서 가져옵니다.

첫째, 경험이 있는 영역은 반복 작업에서 기본을 가져온다.

매일 또는 매주 반복하는 작업이 있다면, 그 안에 이미 기본이 들어 있습니다. 사용자가 할 일은 그것을 꺼내 정리하는 것입니다. 정리 대상은 세 가지입니다. 작업을 어떤 순서로 진행하는지, 각 단계에서 어떤 기준으로 판단하는지, 마지막에 어떤 형태의 산출물이 나와야 하는지.

여기서 함께 적어 두어야 할 것은 결과만이 아닙니다. “왜 이렇게 했는지”를 같이 적습니다. 판단의 이유가 빠지면 스킬은 체크리스트로 남고, 같은 작업을 해도 결과가 달라집니다. 경험을 자세하게 풀어 넣을수록, 스킬은 매번 같은 품질로 작동합니다.

출발점은 대화창입니다. 반복하는 작업을 한두 차례 함께 수행한 뒤, “이 작업을 스킬로 만들어 줘”라고 요청합니다. 그 시점에는 작업의 흐름과 판단 지점이 이미 대화에 드러나 있기 때문에, 그 맥락을 토대로 스킬 초안이 나옵니다. 이후 같은 작업을 반복하면서 부족한 부분이 보이면 그때마다 항목을 보강해 나갑니다. 스킬은 한 번에 완성되지 않고, 사용하면서 보강됩니다.

둘째, 경험이 없는 영역은 사전 조사에서 기본을 가져온다.

새로 시작하는 분야는 사용자가 가진 재료가 부족합니다. 이때는 스킬을 만들기 전에 자료를 모으는 단계가 먼저입니다. 조사 대상은 첫째 방법과 같은 세 가지입니다. 그 분야에서 어떤 작업이 반복되는지, 각 단계에서 어떤 판단이 필요한지, 어떤 산출물이 표준인지. 책, 튜토리얼, 전문가가 공개한 절차, 비슷한 일을 하는 사람의 작업 흐름이 모두 자료가 됩니다.

정리된 자료가 스킬의 기본이 됩니다. 자료 없이 만든 스킬은 일반론에 머무릅니다. 자료가 두꺼울수록 스킬은 구체적으로 작동합니다. 첫 산출물에서 사용자가 “이건 내 작업이 아니다”라고 느낀다면, 자료를 모으는 단계를 건너뛴 결과입니다.

조사는 두 갈래입니다. 먼저 해당 작업을 실제로 어떻게 진행하는지, 전문가의 절차와 노하우를 찾습니다. 그다음 같은 분야에 이미 공개된 스킬과 가이드 문서를 확인합니다. Anthropic이 공식 저장소에 올린 예시 스킬도 이때 함께 비교합니다. 두 자료를 모으면 그 분야의 작업 순서와 기록 기준이 드러납니다. 모은 자료는 스킬 본문에 다 담지 않고, 상세 내용은 별도 보조 파일로 분리해 둡니다. 그렇게 분리해 두면 스킬은 가벼워지고 자료는 두꺼워집니다.

좋은 스킬은 경험과 자료를 기반으로 만들어집니다. 경험이 있으면 자기 안에서 꺼내고, 경험이 없으면 자료에서 가져옵니다.

이후 대화창에 다음과 같이 입력하면 됩니다.

“나는 [작업/주제]에 대한 스킬을 만들고 싶다. 어떻게 구성하면 좋을지 추천해 줘.”

The post 좋은 클로드 스킬은 어떻게 만드는가 first appeared on HONGS LAB — AI 글쓰기·콘텐츠 전략가 홍순성.

이 모든 역할을 한 사람이 합니다. 그래서 화면에는 클로드 스킬, 코워크, 옵시디언, LIM-Wiki, 맥미니의 로컬 LLM까지 줄줄이 올라옵니다. 도구가 먼저 늘어난 것이 아닙니다. 한 사람이 맡는 일이 늘어났고, 도구는 그 뒤를 따라 들어왔습니다.

이 변화는 “AI 한 명”에서 “여러 도구가 맞물린 시스템”으로의 이동입니다. 작가 한 명의 작업 환경이 작은 출판사 수준의 인프라로 커지는 중입니다.

아래 세 가지 관점에서 그 이유와 기회를 살펴봅니다.

챗GPT 단독으로는 책이 끝나지 않습니다

가장 먼저 드러난 사실은 컨텍스트 윈도우와 작업 기억의 한계입니다. 책쓰기에서는 원고를 작성하는 일도 중요하지만, 참조 문서를 어떻게 다루느냐가 더 큰 관건입니다. 취재 노트, 인터뷰 기록, 참고 도서, 이전 챕터를 동시에 펼쳐 놓고 작업해야 책 한 권의 일관성이 유지됩니다. 챗GPT는 원고를 쓰는 데는 무리가 없지만, 이 참조 작업이 미비합니다. 챕터가 쌓일수록 앞쪽 내용이 기억 밖으로 밀려나고, 인물·논지·문체가 흔들립니다.

작가가 겪는 체감은 단순합니다. “같은 톤으로 끝까지 가지 못합니다.” 그 빈자리를 클로드 스킬·코워크·옵시디언·LIM-Wiki·맥미니가 나누어 채우는 구조가 만들어졌습니다.

작가의 머릿속을 시스템 밖으로 꺼내 둡니다

전문가들이 공통으로 짚는 것은 PKM(개인 지식 관리)의 오래된 문제, 즉 “이론은 아름답지만 유지가 안 된다”는 점입니다. 제텔카스텐·세컨드 브레인의 실패율이 높았던 이유는 사람이 직접 링크하고 분류해야 했기 때문입니다.

지금의 구성은 그 유지 비용을 도구에 떠넘깁니다. 옵시디언은 노트 폴더 자체가 클로드 코워크의 작업 폴더가 됩니다. 작가는 글을 쓰고, AI는 같은 폴더를 읽고 고칩니다. 카르파시(Andrej Karpathy)의 LLM-Wiki 패턴을 옵시디언에 이식한 사례가 있습니다. 새 자료가 들어올 때마다 위키 전체가 더 촘촘해지는 누적 효과가 보고됩니다.

클로드 스킬은 문체 규칙·금지어·분량 기준·5단계 책쓰기 절차를 마크다운 한 장에 박아 넣습니다. 한 번 만들면 “3장 초안 써줘” 한 마디로 같은 톤이 재생됩니다. 토큰 소비를 90% 이상 줄였다는 보고도 있습니다.

맥미니에 올린 로컬 LLM은 외부에 보내기 곤란한 미공개 원고·취재 노트를 다루는 경로입니다.

세 도구의 공통점은 분명합니다. 작가의 암묵지(절차·문체·자료)를 파일로 외화하는 일입니다. 한 번 외화되면 다음 책에서도 재사용됩니다.

1인 작가가 출판사처럼 일합니다

이 현상은 단순한 효율 개선이 아니라 작가의 “역할 합병”으로 보아야 합니다. 과거에는 자료조사원·교정자·편집자·디자이너가 각각 맡던 일이 한 사람의 워크플로우 안에 들어옵니다. 가트너 자료에 따르면 2026년 70% 조직이 AI 기반 KM을 사용합니다. 1인 저자의 인프라 수준이 조직 평균을 넘어서는 사례가 늘고 있습니다.

작가가 얻는 기회는 세 가지입니다.

첫째, 속도 차이가 아니라 일관성 차이입니다. 챗GPT만 쓰는 작가는 매번 새 결과물이 나오고, 스킬·옵시디언을 쓴 작가는 같은 문체·구조가 누적됩니다. 책 한 권에서 끝나지 않고 다음 책의 출발점이 됩니다.

둘째, 개인 자산화입니다. 노트·스킬·로컬 모델이 모이면 그 자체가 “두 번째 목소리”의 기반이 됩니다. 이런 작업 폴더 구조(스킬 생태계 + 옵시디언 볼트 + 책쓰기 파이프라인)가 자산화 흐름과 정확히 일치합니다.

셋째, 검증 가능한 작업입니다. 채팅창 답변은 사라지지만, 폴더 안의 노트·스킬·결과물은 출처 확인과 재현이 가능합니다. 전문가들이 “AI는 초안을, 사람은 검증을 한다”는 분업을 강조하는 흐름과 맞물립니다.

결국 남는 것은 구성입니다

이 현상은 “AI가 똑똑해져서”가 아니라 “AI가 충분히 똑똑하지 않아서” 일어났습니다. 컨텍스트도 짧고 기억도 휘발되고 같은 문체를 지키지 못하니, 작가가 도구를 직접 묶어 쓰는 쪽으로 갔습니다. 그 과정에서 PKM이 30년 동안 풀지 못한 “유지 비용 문제”가 풀렸습니다. 1인 작가가 출판 인프라를 갖는 새로운 기회가 열렸습니다.

단점도 분명합니다. 학습곡선이 가파릅니다. 도구 구성에 시간이 듭니다. 잘못 설계하면 도구가 작가를 부려먹습니다. 그래서 이 흐름이 우리에게 묻는 것은 “어떤 도구를 더 쓸까”가 아닙니다. “내 작업 자산이 누적되는 최소 구성은 무엇인가”입니다.

The post 작가 한 명 안에 여섯 사람이 있다 — AI 책쓰기가 시스템으로 가는 이유 first appeared on HONGS LAB — AI 글쓰기·콘텐츠 전략가 홍순성.

도구를 늘리면 부담이 되기 때문입니다. 그런데 막상 클로드만 쓰다 보면 다른 문제가 보입니다. 어제 클로드와 함께 만든 결과물이 오늘은 어디에 있는지 곧바로 보이지 않습니다.

클로드와 옵시디언은 같은 층의 도구가 아니다

혼란은 두 도구를 같은 자리에 놓고 비교할 때 시작됩니다. “클로드 vs 옵시디언” 구도에 들어가면 어느 한쪽을 골라야 할 것 같습니다. 그러나 두 도구는 같은 층에 있지 않습니다.

클로드는 일을 만드는 도구입니다. 글을 쓰고, 자료를 정리하고, 슬라이드를 짜고, 코드를 다듬습니다. 옵시디언은 그 일이 쌓이는 공간입니다. 일정과 메모, 강의 노트, 책 원고가 모이는 자리입니다. 하나는 흐름이고, 하나는 자리입니다.

흐름의 도구와 축적의 공간

이 구분이 잡히면 운영 방식이 달라집니다. 클로드는 흐름의 도구라 한 번의 대화가 끝나면 결과가 사라지기 쉽습니다. 같은 작업을 다음 주에 다시 하려고 하면, 같은 지시를 처음부터 다시 입력하게 됩니다.

옵시디언은 축적의 공간이라 다릅니다. 일정 노트에 오늘의 작업 항목을 두고, 작업이 끝나면 결과 노트로 연결합니다. 이 흐름이 반복되면 한 달 뒤에는 작업 노트가 서로 링크되어 남습니다. 같은 강의를 다시 준비할 때 처음부터 시작하지 않습니다. 지난번 강의 노트 위에서 다음 버전을 만듭니다.

코워크는 이 두 층을 연결하는 작업 방식입니다. 클로드에 일을 시키되, 결과는 옵시디언에 남깁니다. 일정 노트가 입구가 되고, 작업 결과 노트가 출구가 됩니다. 클로드가 만든 텍스트를 옵시디언에 정리하면, 그 노트가 다음 작업의 재료가 됩니다. 클로드 단독으로 쓸 때 사라지던 결과물이, 코워크와 옵시디언을 함께 쓰면 자산으로 남습니다.

코워크의 결과는 어디에 남는가

“왜 옵시디언인가”라는 질문은 도구 선택의 문제가 아닙니다. “내가 한 일을 어디에 남길 것인가”라는 질문의 다른 표현입니다. 클로드 하나로도 일은 됩니다. 다만 그 결과가 흘러가 버립니다. 옵시디언을 곁에 두면, 같은 일을 두 번 하지 않는 구조가 만들어집니다.

하루 단위로 보면 큰 차이가 없습니다. 클로드와 한 시간 작업해 결과를 받아 어딘가 붙여 둡니다. 한 주가 지나면 비슷한 작업을 또 합니다. 그런데 한 달, 6개월이 지나면 차이가 벌어집니다. 옵시디언을 곁에 둔 사람은 지난 작업 노트가 서로 연결되어 쌓입니다. 그렇지 않은 사람은 매번 같은 자리에서 다시 시작합니다.

질문은 여기서 한 번 더 이동합니다. 도구를 어떻게 고를 것인가에서, 내 일을 소비로 볼 것인가 자산으로 볼 것인가로. 클로드만 쓰면 일은 그날의 결과로 끝납니다. 옵시디언을 곁에 두면 같은 작업이 다음 작업의 입력값이 됩니다. 클로드 코워크와 옵시디언을 함께 쓴다는 말은 결국 내 일을 자산으로 다루겠다는 선언입니다.

The post 클로드 코워크와 옵시디언, 왜 함께 쓰는가 first appeared on HONGS LAB — AI 글쓰기·콘텐츠 전략가 홍순성.

그런데 이럴 때일수록 한 발 뒤로 물러서서 봐야 할 것이 있습니다. 2017년에 《나는 1인 기업가다》라는 책을 썼습니다. 1인 기업이라는 단어가 아직 낯설던 시기였고, 10여 년간의 경험을 처음으로 정리한 원고였습니다. 9년이 지난 지금, 그 책을 다시 펼쳤습니다. 에버노트와 워크플로위를 소개하던 챕터는 낡았습니다. 당시 소개한 생산성 도구 10가지 중 지금도 그대로 쓰는 것은 거의 없습니다. 그런데 도구 이야기를 걷어내고 남은 뼈대 — 이 책이 반복해서 말한 세 가지 원칙은 한 글자도 고칠 필요가 없었습니다.

도구에는 유통기한이 있지만, 원칙에는 유통기한이 없습니다. 변화의 속도가 빠른 시기일수록, 변하지 않는 것을 먼저 확인하는 일이 방향을 잡는 데 도움이 됩니다.

전문성이 있어야 AI도 제대로 작동합니다

1인 기업의 생존 키워드는 2017년에도 전문성이었고, 2026년에도 전문성입니다. 달라진 것은 이 단어의 무게입니다. AI가 범용 작업을 처리하면서, 대체 가능한 일의 시장 가치가 떨어졌습니다. 번역, 기초 디자인, 데이터 정리처럼 시간을 들이면 되는 일은 AI가 몇 분 만에 해냅니다. 전문성이 없는 1인 기업가는 AI와 같은 시장에서 경쟁하는 구도에 놓이게 되었습니다.

반대로, 특정 분야의 깊은 경험과 판단력을 가진 사람에게 AI는 생산성을 수배로 끌어올리는 도구가 됩니다. 같은 AI를 써도 결과물의 수준이 갈리는 이유는 프롬프트 기술이 아니라, 결과물을 평가하고 방향을 잡는 판단력에 있습니다. 2017년 원고에 이런 문장이 있습니다. “전문성을 확보하면 영업망은 자연스럽게 해결된다. 내가 나의 분야에서 잘하기만 하면 그들이 날 찾아온다.” 9년이 지나도 수정할 부분이 없습니다. AI 시대에는 여기에 한 줄을 더합니다. 전문성이 있어야 AI를 도구로 쓸 수 있고, 전문성이 없으면 AI에게 대체당합니다.

도구가 바뀌어도 감정의 구조는 바뀌지 않습니다

1인 기업을 시작하면 반드시 마주하는 세 가지 감정이 있습니다. 불안감, 외로움, 비교하는 마음입니다. 2017년 책에서 이 세 가지를 ‘반드시 극복해야 할 고통’으로 분류했고, 2026년에도 1인 기업가들의 고민 구조는 동일합니다. AI가 업무 시간을 줄여줬지만, 혼자 결정하고 혼자 책임지는 구조는 그대로이기 때문입니다.

원고에서 ‘잘하기’와 ‘버티기’를 구분한 부분이 있습니다. 잘하기는 공격형 전략이고, 버티기는 수비형 전략입니다. 1인 기업 초기에는 잘하는 일에 집중해 수익을 만들지만, 3년 차 이후부터는 버티는 힘이 생존을 결정합니다. 수익이 불규칙하고, 성장이 정체되고, 주변과 비교당하는 시기를 어떻게 통과하느냐가 5년, 10년을 가릅니다. AI가 생산성을 높여줘도, 방향을 잡고 지속하는 힘은 도구가 해결해주지 않습니다. 버티기는 온전히 사람의 영역입니다.

채널이 바뀌어도, 경험을 콘텐츠로 전환하는 공식은 같습니다

2017년 책에서 정리한 영업의 두 축은 ‘전문적인 콘텐츠 제작’과 ‘셀프 마케팅’이었습니다. 당시에는 블로그에 꾸준히 글을 올리는 것만으로 전문가로 인정받을 수 있었습니다. 2026년에는 상황이 다릅니다. AI가 글을 쓰고, 이미지를 만들고, 영상을 편집합니다. 콘텐츠를 만드는 행위 자체로는 차별화가 되지 않는 시대가 되었습니다.

그러나 공식의 구조는 그대로입니다. 콘텐츠로 전문성을 증명하고, 그 신뢰를 기반으로 고객을 만나는 흐름은 바뀌지 않았습니다. 달라진 것은 차별점의 위치입니다. 콘텐츠의 양이나 제작 속도가 아니라, 직접 겪은 경험과 현장에서 얻은 판단이 브랜드의 핵심이 되었습니다. AI가 만들어낼 수 없는 것은 강의실에서 수강생의 반응을 보며 커리큘럼을 고친 경험이고, 책을 열여섯 권 쓰면서 체득한 글의 구조이고, 20년 가까이 1인 기업을 운영하며 몸으로 익힌 생존의 감각입니다. 채널이 블로그에서 유튜브로, 도구가 에버노트에서 AI로 바뀌었을 뿐입니다.

2011년 스마트폰이 보급되면서 일하는 방식이 조금씩 바뀌기 시작했습니다. 모바일 오피스, 클라우드, 소셜 미디어로 이어진 변화는 10여 년에 걸쳐 서서히 진행되었습니다. 그런데 2022년 말 ChatGPT 등장 이후 AI가 만든 변화는 속도가 다릅니다. 몇 달 단위로 도구가 교체되고, 일하는 방식의 전제 자체가 흔들립니다. 변화의 폭과 속도가 이전과 비교할 수 없을 만큼 빨라진 지금, 1인 기업가들이 불안을 느끼는 것은 자연스러운 반응입니다.

그러나 10여 년간의 점진적 변화든, 지금의 급격한 전환이든, 1인 기업의 생존을 결정하는 축은 바뀌지 않았습니다. 전문성이라는 기반, 버티기라는 태도, 콘텐츠로 쌓는 신뢰. AI 시대의 생존 전략은 새로운 도구를 익히는 데서 시작하지 않습니다. 변하지 않는 축을 먼저 세우는 데서 시작합니다. 도구는 그다음입니다.

The post AI 시대, 1인 기업의 생존을 결정하는 세 가지 원칙 first appeared on HONGS LAB — AI 글쓰기·콘텐츠 전략가 홍순성.

챗GPT 메모리에 글쓰기 규칙을 저장하면, 이후 모든 글쓰기 요청에 동일한 기준이 자동 적용됩니다. 이 글에서는 메모리에 규칙을 단계별로 저장하는 과정을 다룹니다. 처음 설정하는 사람도 순서대로 따라 할 수 있도록 정리했습니다.

왜 글쓰기 엔진이 필요합니까

챗GPT에 “블로그 글 써줘”라고 요청하면 글이 나옵니다. 문제는 그 글의 품질이 일정하지 않다는 점입니다.

원인은 세 가지입니다. 첫째, 과장 표현입니다. “혁신적인”, “획기적인”, “최고의” 같은 단어가 근거 없이 반복됩니다. 둘째, 구조 부재입니다. 서론과 본론이 뒤섞이고, 결론에서 새로운 이야기가 등장합니다. 셋째, AI 특유의 문장 패턴입니다. “~할 수 있습니다”가 반복되고, “매우”, “쉽게” 같은 모호한 부사가 남발됩니다.

이 문제는 AI의 한계가 아닙니다. 사용자가 기준을 제시하지 않은 결과입니다. 챗GPT 메모리에 문장 규칙, 문서 구조, 스타일 기준을 저장하면 매번 같은 수준의 글이 나옵니다. 한 번 설정하면 이후 모든 글쓰기 요청에 자동 적용됩니다. 이것이 글쓰기 엔진의 역할입니다.

설치 전에 확인할 것

글쓰기 엔진은 챗GPT의 메모리(Memory) 기능을 활용합니다. 메모리는 대화 중 사용자의 선호와 기준을 기억하는 기능입니다. 설정 경로는 다음과 같습니다.

챗GPT 화면 왼쪽 하단 프로필 → 설정(Settings) → 개인화(Personalization) → 메모리(Memory) 항목에서 “켜기”를 확인합니다.

메모리가 켜져 있으면, 대화 중 “이 규칙을 기억해줘”라고 말할 때 챗GPT가 해당 내용을 저장합니다. 저장된 내용은 이후 새 대화에서도 자동으로 참조됩니다. 저장할 내용은 한꺼번에 넣지 않습니다. 주제별로 나누어 순서대로 저장해야 각 규칙이 정확하게 기록됩니다.

1단계. 문장 표현 규칙 저장하기

가장 먼저 저장할 것은 문장 수준의 규칙입니다. 이 규칙이 없으면 AI 특유의 과장된 문장이 반복됩니다. 챗GPT에 아래 내용을 입력하고, “이 규칙을 기억해줘”라고 요청합니다.

나의 글쓰기 문장 규칙을 기억해줘:

1. 과장 표현 제한: "혁신적인", "획기적인", "최고의" 사용 금지. 필요하면 근거와 함께 사용
2. 모호한 부사 최소화: "매우", "쉽게", "빠르게" → 삭제하거나 구체적 상황으로 대체
3. 추측/완곡 표현 금지: "~할 수 있습니다" → "~합니다"로 단정
4. 불필요한 연결어 제거: "전반적으로 볼 때", "일반적으로" → 삭제
5. 추상 명사 중심 문장 지양: "중요성", "필요성" → 동사 중심으로 재구성
6. AI 흔적 문장 구조 금지: 부사 + 형용사 + 가능성 + 추상 명사 조합 제거

저장을 확인한 뒤, 테스트합니다. “AI 글쓰기에 대해 3문장으로 설명해줘”라고 입력합니다. 결과에서 “혁신적인”, “~할 수 있습니다” 같은 표현이 사라졌는지 확인합니다.

저장 전: “AI 글쓰기는 혁신적인 기술로, 누구나 쉽게 고품질 콘텐츠를 빠르게 생성할 수 있습니다.”

저장 후: “AI 글쓰기는 초안 생성 속도를 높이는 도구입니다. 사용자가 구조와 기준을 지정하면 일관된 결과물이 나옵니다. 결과의 품질은 프롬프트 설계에 따라 달라집니다.”

2단계. 문서 구조 규칙 저장하기

문장 규칙 다음은 글 전체의 설계 기준입니다. 이 단계가 없으면 내용은 맞지만 읽기 어려운 글이 나옵니다.

나의 글쓰기 문서 구조 규칙을 기억해줘:

1. 기본 구조: 서론 → 본론 → 결론
2. 본문 구성: 개념 → 문제 인식 → 실행 기준 흐름 유지
3. 문단 구성: 3~5문장 단위
4. 결론 구성: 핵심 메시지 요약 + 실행 기준 2줄 제시
5. 전개 방식: 설명 중심이 아니라 사고 구조 정리 중심

이 규칙이 적용되면 글의 흐름이 “왜 이 주제를 다루는가 → 무엇이 문제인가 → 어떤 기준으로 실행하는가”로 정리됩니다. 단순히 정보를 나열하는 글이 아니라, 읽는 사람이 판단 기준을 갖게 되는 글이 됩니다.

3단계. 스타일과 톤 규칙 저장하기

문장 규칙과 구조 규칙만으로도 글의 품질이 올라갑니다. 여기에 스타일 규칙을 추가하면 “이 사람이 쓴 글”이라는 일관성이 생깁니다.

나의 글쓰기 스타일 규칙을 기억해줘:

1. 문체: 설명형·해설형 중심. 감정 절제, 논리 중심 서술
2. 문장 길이: 평균 18~24단어 내외
3. 문장 형태: 단정형 문장 유지 (~합니다)
4. 전개 구조: 도입 → 분석 → 전환 → 결론
5. 핵심 방향: 해결책 제시보다 기준 재정렬
6. 표현 방식: 형용사 최소화, 개념어 중심 (구조, 사고, 실행 등)

이 규칙의 핵심은 “해결책을 주는 글”이 아니라 “기준을 정리하는 글”을 쓰겠다는 선언입니다. 같은 주제를 다루더라도, 이 스타일이 적용되면 글의 성격이 달라집니다.

4단계. 집필 워크플로우 저장하기

1~3단계가 “글을 쓸 때 적용되는 규칙”이라면, 이 단계는 “글을 쓰는 순서”입니다. 성격이 다릅니다. 규칙은 저장하면 자동 적용되지만, 워크플로우는 트리거 문장이나 프롬프트에서 “이 순서대로 진행해줘”라고 지시해야 작동합니다. 그래도 메모리에 저장하는 이유가 있습니다. 5단계 트리거 문장과 결합하면, 한 문장으로 규칙과 순서를 동시에 호출하기 때문입니다.

나의 집필 워크플로우를 기억해줘:

1. 목적 정의: 글의 방향과 독자 설정
2. 구조 설계: 목차, 흐름, 논리 구조 구성
3. 초안 작성: 전체 틀을 빠르게 완성
4. 리라이팅: 논리 흐름 정리, 중복 제거
5. 최종 출력: 실행 가능한 문서 형태로 완성

워크플로우가 저장되면, 트리거 문장과 함께 사용할 때 챗GPT는 바로 문장을 생성하지 않습니다. 먼저 목적을 확인하고, 구조를 설계한 뒤, 초안을 작성하는 순서를 따릅니다.

5단계. 트리거 문장 설정하기

마지막 단계입니다. 저장한 모든 규칙을 한 문장으로 호출하는 트리거를 만듭니다.

다음 트리거 규칙을 기억해줘:

"책 원고 초안 작성해줘" → 글쓰기 스타일 + 문서 규칙 + 금지어 규칙 + 집필 워크플로우 모두 적용
"글 작성해줘" → 글쓰기 스타일 + 문서 규칙 + 금지어 규칙 모두 적용
"블로그 글로 작성해줘" → 글쓰기 스타일 + 문서 규칙 + 금지어 규칙 모두 적용

트리거를 설정하면 매번 긴 조건을 입력할 필요가 없습니다. “책 원고 초안 작성해줘”라는 한 문장에 저장된 규칙과 워크플로우가 동시에 적용됩니다.

실전 프롬프트 템플릿

5단계를 모두 저장했다면, 실제로 글을 쓸 때 아래 템플릿을 사용합니다. 매번 바꾸는 것은 주제, 타깃, 목적 세 가지뿐입니다.

주제: [작성할 주제]
타깃: [독자]
목적: [글의 목적]

책 원고 초안 작성해줘
- 실용서 스타일
- 서론-본론-결론 구조
- 각 문단 3~5문장
- 본론은 3개 소제목으로 구성
- 결론에 실행 기준 2줄 포함

예를 들어, AI 시대 글쓰기 변화에 대한 글을 쓴다면 이렇게 입력합니다.

주제: AI 시대 글쓰기 변화
타깃: 직장인 40대, AI를 활용해 생산성을 높이고 싶은 사용자
목적: 글쓰기 방식의 변화 이해 및 실행 기준 제시

책 원고 초안 작성해줘
- 실용서 스타일
- 서론-본론-결론 구조
- 각 문단 3~5문장
- 본론은 3개 소제목으로 구성
- 결론에 실행 기준 2줄 포함

이 구조로 요청하면 문장 규칙, 구조 규칙, 스타일 규칙, 워크플로우가 동시에 적용된 결과물이 나옵니다.

기준이 있는 글과 없는 글의 차이

글쓰기 엔진을 설치하면, AI가 매번 다른 판단으로 글을 생성하는 문제가 사라집니다. 동일한 기준이 자동 적용되어 결과물의 톤, 구조, 문장 수준이 일정하게 유지됩니다.

프롬프트는 길게 쓰는 것이 아니라, 기준을 명확하게 쓰는 것입니다. 글을 쓰기 전에 세 가지를 먼저 정합니다. 목적: 무엇을 전달할 것인가. 독자: 누구를 위한 글인가. 결과: 읽고 나서 무엇이 바뀌는가. 이 세 가지가 정해지면, 나머지는 엔진이 처리합니다.

The post 챗GPT 메모리에 글쓰기 엔진을 만드는 5단계 first appeared on HONGS LAB — AI 글쓰기·콘텐츠 전략가 홍순성.

[yes24 구매 링크] 

책의 소개

이 책은 AI 이미지 생성이 낯설거나, 만들 때마다 결과가 달라져서 피로를 느끼는 분들을 위해 기획되었습니다.

나노 바나나 프로를 단순히 “이미지를 잘 그리는 도구”로 소개하지 않습니다. 업무와 콘텐츠 제작 현장에서 안정적으로 반복 사용 가능한 이미지 작업 도구로 이해하도록 돕는 데 초점을 두었습니다.

프롬프트를 감각이나 요령이 아닌 구조와 기준으로 다루는 방법을 중심으로, 처음 생성보다 수정과 조정이 쉬운 작업 방식을 체계적으로 설명합니다. 텍스트, 레퍼런스, 수정 흐름을 분리해서 생각하는 방식은 이미지 작업에 대한 부담을 줄이고, 결과물의 일관성을 높입니다.

인물, 제품, 마케팅, 웹툰, 인포그래픽까지 이어지는 실습 구성은 실제 업무와 콘텐츠 제작 상황을 그대로 반영합니다.

이 책은 이런 분에게 필요합니다

• 업무용·홍보용 이미지를 직접 만들어야 하는 40·50대 직장인
• 콘텐츠·마케팅 이미지를 혼자 해결해야 하는 1인기업·프리랜서
• 제품·서비스 홍보에 이미지 활용이 필요한 자영업자
• AI 이미지 생성을 시도했지만 결과가 들쭉날쭉해서 포기한 경험이 있는 분
• 포토샵 후가공 없이 생성 단계에서 결과물을 완성하고 싶은 분

책의 목차

PART 1. 나노바나나 프로 이해와 기본 설계 원리

• 1장. 나노바나나 프로란 무엇인가
• 2장. 나노바나나 프로의 생성 철학
• 3장. 나노바나나 프로의 기본 설계 원리

PART 2. 나노바나나 프로 이미지 생성 기본 가이드

• 4장. 이미지 생성 방법 한눈에 이해하기
• 5장. 텍스트 기반 이미지 생성의 역할
• 6장. 레퍼런스 이미지 활용 구조
• 7장. 수정 중심 이미지 생성 방식
• 8장. 스타일·구도·비율·시점의 생성 기준

PART 3. 처음 만드는 AI 이미지 – 기본편

• ① 사진 한 장으로 ‘나 같은 인물’ 바로 만들어보기
• ② 같은 얼굴, 다른 표정으로 분위기 바꿔보기
• ③ 평범한 일상 사진을 ‘직업 콘셉트’로 바꿔보기
• ④ 인물을 떼어내 스티커처럼 써먹어보기
• ⑤ 인물 사진에 말풍선·아이콘 붙여 콘텐츠화하기
• ⑥ 오래된 흑백 사진을 컬러로 되살려보기
• ⑦ 한 장의 이미지를 여러 버전으로 바꿔보는 실험

PART 4. 인물 이미지 응용편 – 설계해서 활용하기

• ① 사진 한 장으로 ‘프로필 사진’ 만들기
• ② 여러 명을 한 장면에 자연스럽게 모아보자
• ③ 목적에 맞게 인물 분위기와 스타일 연출하기
• ④ ‘서 있는 사람’에서 ‘행동하는 사람’으로 포즈 바꿔보기
• ⑤ 두 사람의 장면을 한 장면에 담아보자

PART 5. 스타일 변환 이미지 생성 – 분위기를 바꾸고 기준을 만드는 단계

• ① 색만 바꿔도 분위기가 달라진다
• ② 사진 위에 그림을 입히다: 하이브리드 스타일 만들기
• ③ 필요한 부분만 콕 집어 바꾸기
• ④ 한 번 만든 스타일을 계속 써먹기
• ⑤ 자주 쓰는 스타일을 기준으로 고정하기

PART 6. 제품·마케팅 이미지 생성 – 팔리고 설명되는 이미지 만들기

• ① 사진은 그대로, 쓰임새만 바꿔보기
• ② 사람이 등장하니 메시지가 살아난다
• ③ 한 장으로 파는 상세 페이지 구성하기
• ④ 빈 공간에 가구를 놓아보기 (공간연출)
• ⑤ 브랜드 분위기를 한눈에 보여주기 (패션 무드보드)
• ⑥ 작게 만들면 더 눈에 띈다 (미니어처)
• ⑦ 굿즈처럼 꾸며 소장 욕구 자극하기
• ⑧ 먹고 싶게 만드는 음식 장면 만들기

PART 7. 콘텐츠 썸네일·포스터·캐릭터 – 한눈에 끌어당기는 단계

• ① 한눈에 멈추게 만드는 블로그 썸네일
• ② 클릭을 부르는 유튜브 썸네일 연출하기
• ③ 멀리서도 보이는 행사 포스터 만들기
• ④ 책의 성격이 드러나는 표지 만들기
• ⑤ 계속 써도 같은 캐릭터로 보이게 만들기

PART 8. 웹툰 콘텐츠 제작 – 이야기를 한 컷씩 전달하는 단계

• ① 말풍선만 붙여도 웹툰이 된다
• ② 순서대로 보면 이해되는 4컷 만들기
• ③ 홍보 내용을 스토리로 풀어내기
• ④ 제품 설명을 장면으로 보여주기
• ⑤ 자주 묻는 질문을 웹툰으로 정리하기
• ⑥ 블로그·SNS용 짧은 웹툰 콘텐츠 만들기

PART 9. 한 장으로 설명 끝내기 – 인포그래픽·그래픽레코딩·NotebookLM

• ① 글을 그림으로 바꾸는 한 장 요약 만들기
• ② 정보가 잘 읽히는 인포그래픽 스타일 쓰기
• ③ 설명 흐름을 그대로 그려내기
• ④ 제품 정보를 그림으로 설명하기
• ⑤ 복잡한 구조를 단계별로 쪼개기
• ⑥ NotebookLM 기본 활용: 글을 한 장 이미지로 요약하기
• ⑦ NotebookLM 응용 활용: 설명용 시각 자료로 확장하기

부록

• 프롬프트 구조 템플릿 / 실패와 수정 사례 비교 / 자주 묻는 질문

이 책의 핵심 접근 방식

이 책은 “한 번에 멋진 이미지를 생성하는 방법”을 가르치지 않습니다. 대신 세 가지 흐름을 분리합니다.

첫째, 텍스트 프롬프트로 방향을 잡습니다. 둘째, 레퍼런스 이미지로 기준값을 설정합니다. 셋째, 수정 도구로 원하는 결과에 도달합니다. 처음부터 다시 만들지 않고, 고쳐 쓰는 이미지 작업 방식입니다.

파트 1~2에서 이 구조를 이해하고, 파트 3부터 증명사진 한 장으로 바로 실습에 들어갑니다. 인물 사진 변환에서 시작해, 제품 마케팅 이미지, 썸네일, 포스터, 웹툰, 인포그래픽까지 단계적으로 확장됩니다. 9개 파트, 총 48개 챕터 구성입니다.

[yes24 구매 링크] https://www.yes24.com/product/goods/185472118

The post 출간 – ⑯실전 AI 콘텐츠 디자인 with 나노 바나나 first appeared on HONGS LAB — AI 글쓰기·콘텐츠 전략가 홍순성.