AI로 기사를 작성했다면 스스로 읽어보고 길이를 조절해 주세요.

Qiita의 푸시 알림을 통해 추천 기사가 소개됩니다.

제목에 흥미를 느껴 무심코 열게 되지만, 열어본 기사가 다음과 같은 특징을 모두 가지고 있으면 흥이 깨집니다……

• 본문이 너무 길다 (읽기 시작하기도 전에 스크롤 바가 짧다)
• 말투나 정렬(Formatting)의 이론이 AI스럽다
• 중요한 정보가 불렛 포인트(Bullet points)로 전부 흡수되어, 정보량이 거의 사라진 단락들이 산재해 있다

2번은 단독이라면 무해한 특징입니다.

하지만 이 세 가지가 합쳐지면, 필자 본인이 자신이 발신한 문장을 읽고 있는 것인지 의구심이 듭니다……

Too Long; Didn't Read (TL;DR) 이라고 불릴 법한 긴 기사를 인력으로 작성했을 경우, 문제는 적습니다.

왜냐하면 작성자 본인은 자신의 문장을 읽으면서 쓰고 있기 때문입니다.

하지만 AI에게 쓰게 했을 경우…… 더 정확히 말해 **본문이 타력본원(他力本願, 남의 힘에 의존함)**인 경우에는 스킬 「감수 (Supervision)」를 발동해야 합니다.

• 자신이 구상하고 있는 것을 올바르게 언어화하고 있는가?
• 기뻐해 줄 만한 사람들을 위해 내용을 최적화했는가?
• 참고 문헌에 대한 경의나 크레딧 표시는 완벽한가?

전문을 직접 쓰는 경우, 이러한 품질은 쓰면서 보증하는 것이었습니다.

하지만 AI의 진화로 상황이 변합니다.

본래 「감수」는 출판 등 특정 업계 종사자들만이 요구받고 연마하는 기술이었습니다.

예를 들어 잡지를 만드는 경우, 전체적인 정책을 관리하는 **편집자 (Editor)**와는 별개로 내용을 쓰는 **필자 (Author)**가 있습니다.

「편집자가 독자에게 전달하고 싶은 것」과 「필자가 쓴 것」이 어긋나면 잡지의 내용이 파탄 나기 때문에, 그들은 아주 오래전부터 감수로 품질을 관리해 왔습니다.

지금은 AI로 누구나 논리 정연한 기사를 제공할 수 있는 시대……?

잠시만 기다려 주세요.

• 내용을 쓰는 것은 AI이다 ⇒ 내용을 쓰는 것은 자신이 아니다
• 내용을 쓰는 것은 자신이 아니다 ⇒ 품질 보증에 감수가 필요하다

즉, 내용을 쓰는 것은 AI이다 ⇒ 품질 보증에 감수가 필요하다는 것입니다.

감수도 하지 않고 무책임하게 기사를 쏟아내다 보면, 자신이 AI slop 문제의 가해자가 되고 있다는 사실조차 자각하기 어려울 것입니다.

그러므로 AI 시대에는 누구나 감수할 수 있어야 합니다.

어차피 AI를 쓸 거라면 스스로 **감수용 프롬프트 (Supervision Prompt)**를 키워 나가세요.

「우선 이것부터」라고 생각되는 포인트는 다음과 같습니다.

짧은 문장밖에 쓰지 못하던 소년 시절의 저에게 긴 문장은 동경의 대상이었습니다. 하지만 감수하기 위해서는 읽어야 합니다.

스크롤 바를 보는 순간 진저리가 날 정도의 길이는 내용을 확인하기도 전에 탈락입니다.

일반적으로는 글자 수나 행 수를 제한하는 경우가 많습니다.

1000자 이내

라든가 20자마다 자동 줄바꿈을 한다는 전제하에 80행 이내

라든가.

웹 페이지의 길이로 지정한다면 이런 느낌입니다.

1행당 전각 20자,
1화면당 20행을 기준으로
6화면 이내

시간 제한을 지정하는 방법도 있습니다.

직접 위에서 아래까지 읽는 시간을 측정하는 것입니다.

AI 감수라면 예를 들어 이런 식으로 읽는 속도를 설정하면 가능할 것이라고 생각합니다.

1모라 (mora)당 0.125초, 문장 구분 시 추가로 1초
라고 가정하여, 5분 이내에 다 읽을 수 있는 길이

모라 (mora)란

모 ー 라 를 か ぞ え る と い う の は、 (←13모라) こ の ぶ ん を ス ペ ー ス く ぎ り で (←13모라)

か ぞ え る よ う な こ と で す。 (←11모라)

か ん じ を よ む じ か ん の

め や す に ちょ う ど い い で す。

(↑21모라)

이 외에도 「코드 스니펫 (Code snippet)은 건너뛰며 읽는다는 전제로 기사 전체의 길이 제한에서는 제외한다」와 같이 다양한 요구를 할 수 있을 것이므로, 생각나는 대로 써 내려가면 됩니다.

도저히 줄일 수 없다면, 확 잘라서 연재 형식으로 만드는 것도 방법 아닐까요!

• 2개 이하의 불렛 포인트

나,

한 문장뿐인 인용 블록 (Quote block)

등은 그대로 문장에 포함시켜도 장황해지지 않습니다.

그것을 굳이 문장 중간에 단락을 나누어 정렬하는 것은 약간 영어식이라기보다, 게임 연출상의 이유로 페이지를 넘긴 것 같은 인상을 줍니다. 왜일까요?

영어로 쓰면 목적어를 문장 끝에 나열할 수 있으므로 확실히 깔끔한 불렛 포인트가 됩니다.

하지만 일본어에서 문장 끝에 연속될 수 있는 것은 목적어가 아니라 서술어입니다.

무리한 불렛 포인트 사용은 내용 없는 단락을 양산하므로, 꼭 불렛 포인트를 쓰고 싶다면 일단 문장을 끝내주세요.

이런 느낌입니다.

수집한 정보의 출처를 기사에 적어 넣으면:
(단락 변경)
(불렛 포인트…)
등, 좋은 점이 가득합니다!

↓

수집한 정보의 출처를 기사에 적어 넣으면, 좋은 점이 가득합니다!
(단락 변경)
(불렛 포인트…)

Qiita에 쓰는 이상, 주요 독자는 엔지니어일 것입니다.

엔지니어는 **1차 정보 (Primary Information)**를 중시합니다.

외부에서 정보를 수집하여 기사로 작성할 경우에는, 반드시 **참고 문헌 (References)**을 정리해 주세요.

수집한 정보의 출처를 기사에 적어 넣으면, 좋은 점이 가득합니다!

• 각 정보원에 대한 존중이 표현됨
• 1차 정보원의 발신자가 인용을 발견하면 기뻐함
• 문제가 발생했을 때 정보원을 알고 있으면 논의하기 쉬움
• 시대가 변한 뒤에 다시 읽어도 당시의 상황이 선명하게 보임
• 원문을 적절히 요약함으로써 읽기 쉽게 유지할 수 있음

참고 문헌을 쓰는 방법은 여기서 다루지 않겠습니다. 찾아보면 좋은 본보기를 발견할 수 있을 것입니다.

엣, 정보원을 적으면 페이지 뷰 (Page View)가 빠져나간다고요?

아니요, 2차 정보는 「목적」과 「수단」을 연결하는 **포털 (Portal)**입니다.

이야기라면, 아는 사람이 많은 주인공은 본인이 최강은 아니더라도 든든하죠?

현실에서도 유익한 1차 정보를 갑자기 찾아내는 것은 어렵기 때문에, 포털도 꽤 중요합니다.

이것만큼은 제안한 사람이 직접 읽는 것이 유일한 해결책입니다.

발신의 동기나 목적은 제안한 사람의 뇌 속에만 존재합니다.

설령 떳떳하지 못한 목적이라 할지라도, 수많은 선택지 중에서 기사 발신을 선택하기에는 나름의 이유가 있을 것입니다.

그 사상이 기사에 담겨 있는지를 열심히 읽어서 확인해 주세요.

……열심히 하지 않으면 읽을 수 없나요? 그렇다면, 그것은 틀림없는 TL;DR (Too Long; Didn't Read) 입니다.

「감수」라고 표현했습니다만, 엔지니어에게는 코드 리뷰 (Code Review)와 같은 공정이라고 설명하는 것이 가장 빠르겠네요(

서로 존중을 표하는 다정한 세상을 만들고 유지하기 위해, 언어화를 의뢰한 후에는 성과물을 리뷰합시다!