TECH 으로 돌아가기
TECH HACKER NEWS 오늘 6분 읽기 30 READS

당신이 쓰지 않은 글을 읽고 싶지 않다, AI 시대 글쓰기와 신뢰에 대한 이야기

당신이 쓰지 않은 글을 읽고 싶지 않다, AI 시대 글쓰기와 신뢰에 대한 이야기
SOURCE IMAGE · HACKER NEWS
당신이 쓰지 않은 글을 읽고 싶지 않다, AI 시대 글쓰기와 신뢰에 대한 이야기

엔지니어링 리더로 오래 일해 온 콜린 브렉(Colin Breck)이 블로그에 짧지만 뼈 있는 글을 올렸어요. 제목이 곧 주장이에요. '당신이 쓰지 않은 글은 읽고 싶지 않다.' 요즘 회사에서 오가는 설계 문서, PR 설명, 슬랙 메시지, 이메일에 AI가 만든 글이 넘쳐나잖아요. 매끈하고 길고 형식은 완벽한데, 읽다 보면 이상하게 남는 게 없는 그런 글들이요. 브렉은 이런 글을 받는 입장에서 느끼는 불편함을 아주 정확하게 짚어요. 쓰는 데 노력이 안 들어간 글을 읽는 데 왜 내 노력을 써야 하냐는 거죠.

글쓰기는 생각하기다

이 글의 첫 번째 핵심은 글쓰기가 결과물이 아니라 과정이라는 거예요. 설계 문서를 예로 들어볼게요. 왜 이 구조를 골랐는지 문장으로 풀어 쓰다 보면, 머릿속에서는 그럴듯했던 논리가 사실은 구멍투성이였다는 걸 발견하게 되잖아요. '이 부분은 왜 이렇게 했지?' 하고 스스로 막히는 순간이 바로 글쓰기가 주는 가치예요. 그런데 AI에게 '이러이러한 설계를 문서로 정리해줘'라고 시키면 그 막히는 순간이 통째로 사라져요. 결과물은 나오는데 생각은 안 한 거죠. 브렉은 이걸 두고, 글을 쓰지 않았다면 그 사람은 아직 자기 생각을 정리하지 않은 것이고, 그렇다면 읽을 것도 없다고 말해요.

두 번째 핵심은 읽는 사람과 쓰는 사람 사이의 암묵적인 계약이에요. 우리가 동료의 글을 읽을 때는 '이 사람이 이 내용을 검토하고 책임진다'는 전제가 깔려 있어요. 그래서 문장 하나하나를 의심하지 않고 읽을 수 있죠. 그런데 AI가 만든 글을 그대로 보내면 그 전제가 깨져요. 그럴듯한 문장 속에 저자도 확인 안 한 주장이 섞여 있을 수 있으니, 읽는 사람이 모든 문장을 검증해야 하는 처지가 돼요. 만드는 데는 10초, 검증하는 데는 30분. 이 비대칭이 팀 전체의 시간을 갉아먹는 거예요.

노력이라는 신호가 사라진다

예전에는 긴 글 자체가 하나의 신호였어요. 누군가 세 페이지짜리 제안서를 썼다면 적어도 그만큼 고민했다는 뜻이었으니까요. 지금은 그 신호가 완전히 망가졌어요. 세 페이지가 프롬프트 한 줄에서 나올 수 있으니까요. 그래서 역설적으로 짧고 거친 글이 더 신뢰를 얻는 시대가 됐어요. 오타가 있고 문장이 좀 투박해도 '아, 이건 이 사람이 직접 생각해서 쓴 거구나'가 느껴지는 글이요. 이게 뭐냐면, 경제학에서 말하는 비용 신호(costly signal)와 같아요. 비용이 드는 행동만이 진심을 증명할 수 있는데, 비용이 0이 되면 신호도 0이 되는 거죠.

코드 리뷰에서 이미 벌어지고 있는 일

이 이야기는 글에만 해당하는 게 아니에요. 오픈소스 세계에서는 AI가 만든 PR과 버그 리포트가 쏟아져서 메인테이너들이 지쳐가고 있어요. curl 프로젝트는 AI가 만든 허위 취약점 보고 때문에 버그 바운티 정책을 손봐야 했고, 여러 프로젝트가 'AI 생성 기여는 명시하라'는 규칙을 넣고 있죠. 회사 안에서도 마찬가지예요. PR 설명이 AI로 생성된 장문이면 리뷰어는 '이 사람이 자기 코드를 정말 이해하고 있나?'부터 의심하게 돼요. 반대로 AI를 편집 도구로 쓰는 건 전혀 다른 문제예요. 초안은 내가 쓰고 문장을 다듬거나 오타를 잡는 데 쓰는 건 생각을 건너뛰는 게 아니니까요. 브렉이 반대하는 건 도구 자체가 아니라, 생각을 외주 주고 결과물만 보내는 행동이에요.

한국 개발자에게는 조금 다른 결이 있어요

한국 개발자에게는 이 문제가 한 겹 더 있어요. 영어로 소통해야 하는 글로벌 팀이나 오픈소스에서, AI는 언어 장벽을 낮춰주는 정말 고마운 도구거든요. 그렇다면 어디까지가 괜찮을까요? 기준은 생각보다 명확해요. 생각과 판단은 내가 하고, 언어만 도움을 받는 것. 한국어로 먼저 내 논리를 쓰고, 그걸 영어로 옮기는 데 AI를 쓰는 건 브렉의 기준으로도 문제가 없어요. 하지만 '이 PR 설명 써줘'라고 시키는 순간 선을 넘는 거죠. 팀 차원에서는 이런 규칙을 정해두는 게 좋아요. AI 생성 부분은 표시하기, 설계 문서의 '왜'는 반드시 직접 쓰기, 그리고 길이보다 밀도로 평가하기. 특히 마지막이 중요한데요, 긴 글을 칭찬하는 문화가 남아 있으면 사람들은 계속 AI로 분량을 채우게 되거든요.

마무리

한 줄로 정리하면, 쓰는 데 생각이 들어가지 않은 글은 읽는 사람의 생각을 낭비하게 만든다는 거예요. 여러분 팀에서는 AI로 쓴 글을 어떻게 다루고 있나요? 표시를 하나요, 아니면 아예 구분이 안 되나요? AI 글을 받고 '이건 좀 아니다' 싶었던 경험이 있다면 들려주세요.


🔗 출처: Hacker News

SOURCE · HACKER NEWS
원문 전체 보기 → https://blog.colinbreck.com/i-dont-want-to-read-what-you-did...
SHARE
NEXT · CHOOSE

변화를 읽었다면,
내가 만들 수익 구조를 고릅니다.

정보를 더 모으는 데서 멈추지 않고, 광고·외주·판매·중개·구독 중 내 상황에 맞는 출발점을 정해보세요.

21가지 수익 구조 살펴보기
처리 중...