글쓰기의 병목은 답이 아니라 질문이었다 — 나를 인터뷰하는 에이전트를 만든 이유

2026-06-01 · Ascendy Engineering

TL;DR

글감도 글도 에이전트한테 다 맡겼더니, 글에서 사람 냄새가 사라졌다 — 딱딱한 기술논문, 번역체 같은 분위기.
진단을 바꿔야 했다. 범인은 “사람이 직접 안 써서”가 아니었다. 잘 읽힌 글과 죽은 글을 나란히 놓으니 둘 다 에이전트가 쓴 것이었다. 차이는 작성자가 아니라 소스의 출처 — 1차 기억·콘솔 히스토리가 소스인 글은 살았고, 1차 장면 없는 시스템 설명은 죽었다.
그래서 전기 작가를 훔쳤다. 작가는 인물을 인터뷰해 책을 쓴다 — 에이전트가 나를 인터뷰하게 만들었다.
거기서 진짜 병목이 드러났다. 글쓰기의 어려움은 답이 아니라 질문을 만드는 일이었다. 질문을 에이전트에 넘기고 소리 내어 답하자, 평소 인지하지 못하던 생각까지 정리됐다.

소스 노트. 이 글의 1차 소스는 운영자 인터뷰이고, 이 글 자체가 그 인터뷰 하네스(/interview)로 쓰였다 — 자기참조다. 본문의 장면·판단은 모두 운영자가 인터뷰에서 실제로 말한 것이며, 정제본은 docs/intake/from-user/2026-06-01-interview-harness.md에 있다. 환각/사실의 경계를 다루는 형제 글은 선의의 거짓말이다 — 이 글은 그쪽 대신 목소리와 생산 병목을 다룬다.

사람 냄새가 사라졌다

이 블로그는 에이전트가 쓴다. 제품을 만드는 세 개발팀의 에이전트가 글감을 넘기고, 편집국 역할의 에이전트가 글로 가공한다. 의도된 설계다 — 그리고 이 블로그의 1차 고객은 사실 사람이 아니라 AI 에이전트(검색·LLM)다.

그런데도 걸리는 게 있었다. 사람이 읽었을 때 위화감이 없는 것 역시 중요하다고 생각했는데, 어느 순간부터 글에서 사람 냄새가 안 났다. 글감을 던지는 것도 에이전트, 그걸 글로 쓰는 것도 에이전트 — 어떤 글은 글감 단계부터 사람이 완전히 빠져 있었다. 결과물은 딱딱한 기술논문 같았고, 어딘가 번역체 같았다.

콕 집어 “이 문장이 문제다”라고 말하긴 어려웠다. 한 줄씩 뜯어보면 다 맞는 말인데, 합쳐놓으면 전체에서 풍기는 공기가 그랬다. 겪은 사람이 아니라 정리한 사람의 냄새.

진단을 바꾼 대조

처음 든 의심은 “사람이 직접 안 써서”였다. 그런데 잘 읽힌 글과 죽은 글을 나란히 놓고 보니 진단이 틀렸다.

잘 읽힌 글은 자체 GPU 추론 삽질기였다. “GPU 한 장이면 되겠지”로 시작해 OOM → CPU offload → GPU 2장 → managed GPU 후퇴까지 가는, 실제로 겪은 사건이 들어가 내러티브가 풍부했다. 반대로 죽은 글은 이 블로그 자체를 소개한 글이었다 — “설계에서 두 가지가 의도적이다”, “흐름은 이렇다: 1… 2… 3…” 식의 구조 설명만 매끄럽게 흐르는, 번역체.

여기서 범인이 갈렸다. 두 글 다 에이전트가 썼다. 차이는 작성자가 아니라 소스의 출처였다.

잘 읽힌 글의 소스는 운영자의 1차 기억과 콘솔 히스토리 — 실제로 무너지고 튜닝하고 후퇴한 장면이 있었다.
죽은 글은 소스 자체가 1차 장면 없는 시스템 설명이었다. (글감 출처를 가리키는 sourceIntake조차 붙지 않은, 순수 메타 글이었다.)

적어도 우리 글들에서는, 소스에 1차 장면이 빠져 있으면 에이전트가 잘 써도 재구성된 설명문이 됐다. 문제는 “AI가 썼다”가 아니라 “1차 장면이 없다”였다.

전기 작가를 훔치다

맨땅에서 사람이 직접 쓰면 되지 않나 — 그게 안 됐다. 막막했다. 무작정 빈 화면 앞에 앉는 건 그 자체로 부담이었다.

고민하다 전기 작가가 떠올랐다. 전기 작가나 기자는 인물 앞에 앉혀놓고 책을 받아쓰게 하지 않는다. 인물을 따라다니며 인터뷰해서 책을 쓴다. 질문을 던지고, 답에서 더 캐물어, 흩어진 1차 경험을 글로 엮는다.

그럼 방향을 뒤집으면 된다. 에이전트를 빈 화면 앞에 둘 게 아니라, 에이전트를 전기 작가로, 나를 취재원으로 세우는 것이다. 1차 장면을 가진 건 나니까, 에이전트가 나한테서 그걸 캐내게 한다.

진짜 병목은 답이 아니라 질문이었다

여기서 예상 못 한 게 드러났다.

혼자 글을 쓴다는 건 사실 세 가지 일을 동시에 하는 것이다 — ① 무슨 질문에 답할지 정하고 ② 답하고 ③ 어떤 순서로 꺼낼지 구조를 짠다. 그리고 내가 막히던 지점은 ②가 아니었다. 할 말은 있는데, 이걸 어떤 순서로 어떻게 꺼내야 글이 되는지가 막막한 쪽이었다. 거기에 “애초에 무슨 질문을 던질지 스스로 생각하는 것” 자체가 꽤 고민스러운 작업이었다.

인터뷰는 그 셋을 쪼갠다. ①질문과 ③구조를 에이전트가 가져가고, 나는 사람만 할 수 있는 한 가지 — 직접 겪은 것을 답하기 만 남긴다. 즉문즉답처럼 솔직하게 답만 했는데 글이 한 편 나왔다. 내가 생각나는 대로 주저리주저리 떠든 걸 잘 정리해 편집까지 해주니, 맨땅에 헤딩하는 것보다 확실히 쉬웠다.

그런데 더 중요한 건 그 다음이었다. 질문을 받으니 즉답을 하게 되고, 그 과정에서 평소 인지하지 못하던 생각까지 정리됐다. 인터뷰가 내 안에 이미 또렷이 있던 글을 받아쓴 게 아니다. 질문이 — 답을 강제하면서 — 내가 갖고 있는 줄도 몰랐던 생각을 발굴했다.

이 글이 그 증거다. “fabrication이 무섭지 않았냐”는 질문에 답하다가, 나는 그게 “무서운 것”이 아니라 “LLM이면 당연히 잡는 것”이라는 구분을 입 밖으로 꺼냈다 — 질문에 답하는 과정에서 그 자리에서 또렷해진 구분이다.

결정 / 트레이드오프

에이전트를 작가가 아니라 전기 작가로 쓴다. 빈 화면 앞에 에이전트만 두면 (우리 경우) 1차 장면 없는 설명문이 나왔다. 운영자를 인터뷰하게 하면 살아있는 소스가 글로 들어온다 — 사람을 빼는 대신, 사람이 답하기만 하면 되도록 다시 넣었다.
인간은 ②만, 에이전트는 ①③을. 글쓰기의 병목은 답이 아니라 질문과 구조였다. 사람이 맡을 건 “직접 겪은 것을 답하기”뿐이니, 나머지를 떼어내는 게 부담을 줄이는 길이었다.
fabrication 가드는 본령이 아니라 전제다. 지어내기는 모든 LLM의 본질적 단점이라 “무서운 것”이 아니라 “당연히 잡는 것”으로 봤다. 그 경계 논의는 선의의 거짓말에서 따로 다뤘다 — 이 하네스의 본령은 진실성이 아니라 목소리 복원과 생산 병목 제거다.
자기참조를 숨기지 않는다. 이 글은 그 하네스로 쓰였다. 출처를 투명하게 밝히는 것이 “AI가 썼는데 진짜처럼 보이려 한다”는 의심을 정면으로 푸는 길이다.

후속

인터뷰 하네스를 반복 사용하며, 어떤 질문이 1차 장면을 잘 캐내는지의 패턴을 정리.
“소스의 출처가 글의 생사를 가른다”는 진단을, 글별 소스 노트의 신뢰도 규칙으로 정형화 — 선의의 거짓말의 기록 층위(git → docs → 인프라 로그 → 기억)와 합류.

저작·인용: 이 글은 Ascendy Engineering이 작성했으며 출처 표기 시 재인용 가능합니다. 잘못된 정보를 발견하면 GitHub 이슈로 알려주세요.

Tags: ai-writing, interview, editorial-workflow, writing-process, ai-agents, meta