AI‑Assisted Writing을 검색으로 활용 (초안 생성이 아니라)

발행: (2025년 12월 14일 오후 03:41 GMT+9)
12 min read
원문: Dev.to

Source: Dev.to

소개

나는 탐구하고 싶은 아이디어가 꾸준히 쏟아지지만, 대부분은 같은 곳에서 사라진다: 노트에 적힌 몇 개의 핵심 포인트, 혹은 레포에 있는 개요. 내 경우는 실제로 다음과 같은 파일 이름으로 보인다:

  • projects/personal/ideas/2025-12-10-blog-post-second-brain-experience.md
  • projects/personal/ideas/2025-12-13-ai-writing-process.md

그것들은 전혀 무가치한 것이 아니었다. 실제 시도였지만, 거의 출판할 수 있는 무언가로 이어지지는 못했다. 내가 말할 것이 없어서가 아니라, 글쓰기(나에게)는 이제 부서지기 쉬운, 동기화된 활동이 되었기 때문이다:

  • 나는 긴 시간 동안 방해받지 않고 다듬어야 한다.
  • 실시간으로 피드백을 줄 동료가 필요하다.
  • 영어(솔직히 프랑스어까지) 실력에 대한 충분한 자신감이 있어야 결과물이 “읽을 가치가 있다”고 느낀다.

그런 조건들은 내 삶에 안정적으로 존재하지 않는다. 나는 가족이 있는 창업가이고, 시간은 조각조각 나뉜다. 또한 나는 매일 고신호 피드백을 삼투압처럼 얻을 수 있는 밀집된 기술 생태계에 살고 있지 않다. 그래서 아이디어는 머리속을 맴돌고… 나는 계속해서 출시하지 못한다.

이 글은 그 문제를 해결하기 위해 만든 워크플로우를 설명한다. 의견이 강하게 반영된 것이지만, 과시적인 자신감은 아니다. 간단한 논지는:

글쓰기를 검색 문제로 생각하는 유용한 방법이 있다.
AI는 당신이 커밋하기 전에 검색 공간(다양한 프레이밍, 반론, 구조)을 탐색하도록 도와줄 때 유용하다.

내 제약 하에서의 약속

시간이 조각나고 즉시 활용할 수 있는 편집 동료가 없을 때, 이 워크플로우는 “돌아다니는 아이디어 소음”을 실제로 공유하고 싶어 하는 초안으로 신뢰성 있게 전환한다. 옵션을 먼저 확장하고, 그 다음 정밀성을 강제해 다듬는다.

대상 독자

  • 아이디어는 있지만 방해받지 않는 연속적인 시간이 제한적이고, 고신호 피드백도 제한적인 사람들.

대상이 아닌 사람

  • 이미 강력한 편집 동료와 깊은 연속 시간을 가진 사람.
  • 주요 목표가 “더 예쁜 문장”이나 다듬어진 AI 목소리인 경우.
  • 목표가 SEO/마케팅 결과인 경우.

짧은 인식론적 주석

나는 중요한 진술을 경험, 의견, 가정, 검증으로 라벨링하려고 한다. 이 글에서는 대부분의 주장이 경험이나 의견이다. “이게 작동한다”고 말할 때는 “내 제약 하에서 나에게는 작동한다”는 의미이며, 보편적인 방법이라는 뜻은 아니다. (전체 분류는 부록 A 참고.)

실제 실패 모드: 너무 일찍 커밋하기

바쁘면서 아이디어가 있다면, 기본적인 “한 번 초안” AI 워크플로우가 유혹적이다:

  1. 모델에 프롬프트를 보낸다.
  2. 통과 가능한 초안을 얻는다.
  3. 약간 편집한다.
  4. 출판(하거나 안 한다).

내 의견: 이것은 미묘하게 실패한다. 공간을 너무 일찍 축소한다. 첫 번째 일관된 프레이밍을 받아들이면, 물어보지 못한 대안 논제와 실제 토론에서 발견했을 반론을 놓치게 된다. 결과는 유창할 수 있지만 종종 얕거나 일반적이다.

“글쓰기를 검색으로 본다”는 의미는:

  • 아이디어를 프레이밍하는 타당한 방법이 많이 있다.
  • 첫 번째 프레이밍이 가장 좋은 경우는 거의 없다.
  • 작업은 텍스트를 생산하는 것이 아니라, 실제로 믿는 것을 선택하는 것이다.

왜 “검색”인가?

다른 은유도 있다(조각, 반복, 대화). 나는 여전히 “검색”을 사용한다. 왜냐하면 내 제약 하에서 중요한 커밋 전에는 되돌리기가 저렴하다는 트레이드오프를 강조하기 때문이다.

아직 Draft A를 3시간 다듬지 않았다면, Draft B가 더 좋은 논제를 보여줄 때 포기하기가 쉽다.

주의: 이것이 “무료”인 것은 아니다. 비용을 쓰기에서 읽기(그리고 주의)로 옮긴다. 읽기 세금을 내고 잘못된 초안을 다듬는 세금을 피한다.

따라서 워크플로우는 두 모드로 나뉜다:

  • 탐색: 가능한 에세이 공간을 확장한다.
  • 커밋: 프레이밍을 선택하고 정직하게 만든다.

5‑단계 루프 (선택적 4.5 단계 포함)

단계설명
1. 원시 덤프연료 – 자신과의 지저분한 인터뷰.
2. 관점 확장병렬 초안 – 글머리표가 아니라 전체 에세이 생성.
3. 종합선택 + 압축 (큐레이션, 평균이 아님).
4. 인간 명확화진실이 들어가는 곳 – 자신과의 Q&A.
5. 통합최종 초안 작성.
4.5 (선택)“X라면 뭐라고 할까?” 비판 – 반론 생성, 신중히 다룸.

한 줄 파이프라인:

Raw dump → Parallel drafts → Synthesis → Human Q&A → Draft

경험에 따르면 4단계(인간 명확화)가 가장 높은 레버리지를 제공한다. 2·3단계가 4단계를 가능하게 만든다.

단계 1: 원시 덤프 (시스템에 실제 연료 제공)

원시 덤프는 개요나 프롬프트가 아니다; 자신과의 지저분한 인터뷰에 가깝다.

경험: 나는 종종 음성 메모로 시작한다(타이핑은 “쓰기”와 동일하게 인식돼 완벽주의를 유발한다).

포함할 내용

  • 무슨 일이 있었는지(사건)와 왜 그것이 당신에게 중요한지.
  • 현재 당신이 믿는 바.
  • 확신이 서지 않는 부분.
  • 최적화 목표(명료성, 새로움, 설득 등).
  • 제약 조건(시간, 청중, 민감도).

이 글에서의 실제 예시: 내 원시 덤프는 프로세스 명세로 시작했다:

- “A technical blog post about a systematic approach to writing better technical blog posts…”
- “Step 1: Raw Information Dump”
- “Step 2: Multi‑Model Perspective Expansion”

원시 덤프가 얇으면, 이후 모든 단계가 일반적으로 변한다.

단계 2: 관점 확장 (글머리표가 아니라 전체 초안 생성)

모델에 개요만 요청하고 직접 쓰는 대신, 나는 병렬 초안을 만든다: 서로 다른 모델(또는 서로 다른 프롬프트/시각)에서 나온 여러 전체 에세이.

왜 전체 에세이인가?

완전한 초안은 논제, 정의, 전환, 결론, 그리고 암묵적인 가정들을 강제한다—글머리표가 숨길 수 있는 것들이다.

경험: 보통 3~4개의 모델을 실행한다. 모델이 적으면 너무 빨리 수렴하고, 더 많이 쓰면 읽는 시간 대비 새로운 구조가 거의 추가되지 않는다.

초안 비교를 위한 실용 체크리스트

  • 어느 초안이 가장 강력한 주장을 제시하고(그 가정은 무엇인가)?
  • 어느 초안이 최고의 반론을 제시하는가?
  • 어느 초안이 가장 깔끔한 구조를 가지고 있는가(내용이 틀려도)?
  • 어느 초안이 가장 “생생”하게 느껴지는가(구체적 제약, 실제 이해관계 포함)?

나는 이 초안들을 대안 프레이밍, 반론, 재사용 가능한 문구로 다루며, “정답”으로 보지는 않는다.

모델이 하나뿐인 경우

세 번에 걸쳐 세 가지 시각을 강제한다:

  1. 회의론자: 가장 강력한 반론 + 누락된 전제.
  2. 교사: 가장 단순한 설명 + 구체적 예시.
  3. 편집자: 구조 + 삭제 + “뭐를 빼야 할까?”

단계 3: 종합 (평균이 아니라 큐레이션)

병렬 초안을 만든 뒤, 나는 축소 단계를 수행한다. 대부분은 “문단을 합치라”고 생각하지만, 모든 것을 평균 내어 하나의 정중한 포스트로 만들려는 유혹은 보통 평범함을 낳는다.

내 의견: 종합은 의견이 강해야 한다. 선택 + 압축이다:

  • 가장 강력한 주장 추출.
  • 의견 차이 표면화.
  • 증거가 필요한 부분 식별.
  • 실제 포스트를 운반할 수 있는 서사 형태 제안.

이 글에서의 실제 예시: 내 종합은 핵심 위험을 짚었다:

“Missing ingredient: a concrete event… Without a real event/case study, it reads as generic advice.”

그 결과는 결정을 강요했다: 포스트는 구체적인 경험에 기반하지 않으면 “여기서 나는 …”라는 식으로만은 될 수 없었다.

Back to Blog

관련 글

더 보기 »