개발자의 글쓰기 실력, 편집과 피드백으로 늘린다

출처: The Pragmatic Engineer (Gergely Orosz)
원문: https://newsletter.pragmaticengineer.com/p/becoming-a-better-writer
작성자: 팔복소프트-김팔복

한눈에 보기

• 시니어 이상으로 갈수록 글쓰기 실력이 승진을 가로막는 벽이 될 수 있다는 게 Gergely Orosz의 진단입니다.
• 잘 읽히는 글은 재능보다 과정의 결과이며, 그 과정은 초안 → 편집 → 피드백 세 단계입니다.
• 편집의 핵심은 문단 쪼개기, 군더더기 빼기, 짧은 문장, 목록과 굵은 글씨, 그림 활용, 그리고 읽는 사람의 시간을 내 시간보다 귀하게 여기는 태도입니다.
• 피드백은 "어때요?" 대신 구체적인 질문으로 요청해야 쓸모 있는 답이 돌아옵니다.
• 실력을 올리는 방법으로는 좋은 글을 모아 따라 쓰기와, 주간 보고·회의록·설계 문서처럼 매주 반복되는 글쓰기 습관을 제안합니다.

배경

The Pragmatic Engineer는 Gergely Orosz가 운영하는 뉴스레터입니다. 이 글은 "동료보다 글을 못 쓰는 것 같은데 어떻게 늘리느냐"는 독자 질문에 답하는 형식입니다. 2022년 유료 글로 나왔다가 2026년 10월 무료로 풀렸는데, 저자는 그 이유로 AI 없이 자기 경험을 글로 쓰는 엔지니어가 줄어드는 것 같다는 점을 들었습니다. AI가 문장을 대신 써 주는 지금 더 시의적절한 글입니다.

왜 개발자에게 글쓰기인가

저자는 고성장 스타트업이나 Big Tech의 엔지니어라면 하루에 코드보다 글을 더 많이 쓸 가능성이 높다고 봅니다. 커밋 메시지, 코드 리뷰 댓글, 채팅, 설계 문서, 포스트모템, 동료 평가와 승진 문서가 모두 글입니다. 리드나 매니저가 되면 회의록과 현황 보고까지 더해집니다.

채용에서도 글쓰기를 봅니다. Amazon은 엔지니어링 매니저 채용을 글쓰기 과제로 시작하고, Stripe는 Staff 이상 엔지니어, TrueLayer는 Principal 엔지니어 면접에서 글쓰기 과제를 냅니다. 조직이 클수록 글은 팀 밖에 닿고 결정을 기록으로 남기는 수단이 됩니다.

편집: 초안을 읽히는 글로 바꾸는 단계

그림 1. 원문이 정리한 글쓰기의 세 단계 (팔복소프트 작성)

편집의 출발점은 받는 사람 입장에서 다시 읽기입니다. 긴 글이라면 원문은 다음을 권합니다.

Amazon이 기획 문서를 6쪽으로 제한하는 것도 같은 맥락입니다. 분량 제한이 있으면 문단 하나하나가 귀해지고, 쓰는 사람은 오히려 더 많은 시간을 들여 덜어냅니다.

피드백: 묻는 방식이 답을 정한다

그림 2. 원문에서 소개한 피드백 경로 세 가지 (팔복소프트 작성)

저자가 강조하는 건 질문의 구체성입니다. "가장 헷갈린 부분이 어디였나요?", "중복이라고 느낀 부분은?"처럼 범위를 좁혀 물어야 답이 돌아옵니다. 중요한 문서는 매니저와 통화하며 같이 쓰라고도 권합니다. 자동 도구는 가독성을 크게 높여 주지만, 틀리거나 내 스타일과 맞지 않는 제안은 거절해도 된다고 말합니다.

습관: 매주 쓰는 글을 연습장으로

원문이 꼽는 연습 대상은 15분 들여 쓰고 5분 만에 읽히는 주간 보고(5-15 update), 이해관계자용 프로젝트 요약, 회의록 자원하기, 새 프로젝트 제안서, 설계 문서입니다. 모든 글에 공을 들일 수는 없으니, 가장 널리 읽히는 글을 골라 그것만 편집과 피드백 과정을 거치라는 조언이 현실적입니다.

글쓰기는 내 생각을 설명하는 일이 아니라, 읽는 사람의 생각을 바꾸는 일이다.
— Stefan Buck (원문에서 소개한 Leadership Lab 강연 요약)

팔복소프트 관점

• 국내 팀에도 그대로 통합니다. 슬랙·잔디 같은 메신저와 Notion·Confluence 문서로 일하는 팀이 많아지면서, 국내에서도 "말로 하면 되는 일"이 점점 글로 넘어오고 있습니다. 비동기 협업 비중이 높을수록 글이 곧 영향력입니다.
• 도구는 한국어 기준으로 바꿔 생각해야 합니다. Hemingway Editor와 Grammarly는 영어 도구입니다. 한국어 문서라면 맞춤법 검사기로 기본을 챙기고, 문장 길이·중복 표현 점검은 LLM에게 맡기는 쪽이 현실적입니다. 다만 원문의 원칙은 여기에도 적용됩니다. 제안이 내 의도를 흐리면 거절해야 하고, AI가 다듬은 매끈한 문장이 정작 결정 사항을 흐리게 만드는 경우가 생각보다 많습니다.
• 가장 효과가 큰 건 '구체적으로 묻기'입니다. 국내 조직에서는 "검토 부탁드립니다" 한 줄로 리뷰를 요청하는 경우가 흔하고, 그러면 "좋네요"만 돌아옵니다. 문서 리뷰에도 질문을 붙이는 습관 하나로 체감이 큽니다.
• 아쉬운 점도 있습니다. 영어권 저자의 글이라 추천 도서와 강의가 모두 영어 글쓰기 기준이고, 승진 문서나 6쪽 문서처럼 글쓰기가 평가 제도에 녹아 있는 미국 Big Tech 문화를 전제로 합니다. 국내에서는 개인 노력만으로는 한계가 있으니, 팀 리드라면 설계 문서 템플릿이나 포스트모템 양식처럼 '좋은 글의 틀'을 팀 차원에서 먼저 깔아 주는 편이 낫습니다.

정리

글쓰기는 타고나는 게 아니라 초안 → 편집 → 피드백을 반복하며 키우는 기술이라는 게 이 글의 메시지입니다. 당장 하나만 해 본다면, 이번 주에 가장 많은 사람이 읽을 문서 하나를 골라 받는 사람 입장에서 다시 읽고, 동료에게 구체적인 질문 한두 개와 함께 리뷰를 부탁해 보세요. AI가 문장을 써 주는 시대일수록, 무엇을 전할지 정하고 덜어내는 판단은 쓰는 사람에게 남습니다.

• 글쓰기
• 개발자커리어
• 기술문서
• 엔지니어링리더십
• 협업