글을 편집할 때 드는 생각 (공감받는 글 잘 쓰는 법)

나는 이메일부터 단편 소설, 문서에 이르기까지 친구나 동료의 글을 편집해 달라는 요청을 자주 받습니다. 최근 누군가가 저에게 편집 방법을 물었습니다. 나는 무엇을 찾고 있나요? 어떤 변경 사항을 적용해야 하는지 어떻게 알 수 있나요? 그것은 나를 멈추고 내가 반 본능적으로 하고 있던 일에 대해 생각하게 만들었습니다.

 

이번 포스팅에서는 제가 믿고 있지만 지금까지 자세히 설명하지 못한 편집의 주요 포인트를 정리하고 싶습니다. 이 조언의 대부분은 장르 전반에 걸쳐 적용됩니다. 개인적으로 저는 대학에서 학술 논문을 쓰고, 여가 시간에 시와 단편 소설을 쓰고, 업무에 필요한 기술 문서를 작성하는데 모두 동일한 기본 편집 기술을 적용했습니다.

 

그리고 서로 다른 장르가 서로를 알려주는 것 같아요. 기술적인 언어를 더욱 명확하게 해주는 소설 쓰기에서 얻은 원칙이 있으며, 기술 문서를 읽을 때 사람들이 얼마나 훑어보는지 알게 되면서 이메일과 같은 항목의 형식을 지정하고 작성하는 방식이 향상되었습니다.

내 권장 사항은 다음과 같습니다.

---

 

실제로 무슨 말을 하고 있는지 결정하세요.

문장 수준에서 편집을 시작하기 전에 말하려는 내용을 말했는지 확인해야 합니다.

 

나는 당신이 작성하는 모든 것에 대해 당신 자신의 용도로만 서문 *을 작성하는 것을 권장합니다. 몇 분 정도 시간을 내어 당신이 말하려는 것이 무엇인지 생각해 보십시오. 당신의 요점은 무엇입니까? 누구를 위해 글을 쓰고 있나요? 그런 다음 실제로 이 정보를 문서(또는 노트북, 카페 냅킨) 상단에 적어 작업하는 동안 바로 확인할 수 있습니다. 글을 쓰거나 편집하면서 페이지에 있는 내용과 계획한 내용을 비교할 수 있습니다.

 

또한 메시지가 실제로 무엇인지 생각하게 만듭니다. 블로그 게시물을 작성하고 싶다고 가정해 보겠습니다. 전달하려는 요점을 한두 문장으로 요약할 수 없다면 어떻게 일관성 있는 게시물을 작성하겠습니까?

 

*이 이름은 뉴욕 작가 스튜디오 에서 진행하는 창작 수업에서 따온 것입니다. 모든 과제의 일부로 우리는 서문을 작성해야 합니다. 페이지 상단에 내레이터의 종류, 어조, 분위기를 포함하여 우리가 하려는 의도를 언급하는 몇 문장이 필요합니다. 다른 학생들이 수업 시간에 당신의 작업을 비평할 때, 그들은 이 모델을 고수하고 당신이 주인공을 좋아하는지가 아니라 공예 에 중점을 두고 목표를 달성했는지 평가합니다.

 

300x250

 

자신의 말을 반복하세요(합리적인 범위 내에서)

요점을 매우 명확하게 설명했다고 생각하더라도 독자가 이해할 수 있도록 작성 중인 내용의 시작과 끝에서 다시 설명하는 것이 좋습니다.

이 원칙은 대부분의 장르에 적용됩니다. 문서에서 좋은 튜토리얼은 수행할 작업에 대한 간략한 소개, 실제 절차, 그리고 마지막으로 작업을 올바르게 수행했는지 확인하는 방법을 포함합니다. 블로그 게시물에서는 게시물에서 논의할 내용을 소개한 다음 실제로 이를 수행하고 마지막에 간단한 요약을 작성해야 합니다. 등등.

 

“자신을 반복하세요”는 언어 수준에도 적용됩니다. 내가 얻은 최고의 글쓰기 요령 중 하나는 지시 대명사 사용을 피하는 것이었습니다. "이것"이나 "저것"이라고 말하는 대신, 방금 언급했더라도 정확히 무엇을 의미하는지 설명하기 위해 명사를 추가해야 합니다.

예: 상자가 두 개밖에 남지 않았습니다. 이 문제를 해결하려면 더 주문해야 합니다.

수정: 이제 상자가 두 개밖에 남지 않았습니다. 이 부족함을 해결하려면 더 주문해야 합니다.

예: 다음을 클릭하고 메시지가 나타나면 자격 증명을 입력합니다. 그러면 홈 화면으로 이동됩니다.

개정: 다음을 클릭하고 메시지가 나타나면 자격 증명을 입력합니다. 인증에 성공하면 홈 화면으로 이동합니다.

이러한 중복은 글을 쓸 때 반복적으로 느껴질 수 있지만 독자에게는 반복적인 느낌이 들지 않습니다. 이렇게 하면 글을 더 명확하고 이해하기 쉽게 만들 수 있습니다.

요약하자면, 편집할 때 요점을 다시 설명하고 명확하게 설명하거나 독자에게 마무리를 제공할 수 있는 방법을 찾으십시오.

 

단순화하다

다른 사람의 작업을 편집할 때 제가 가장 먼저 해야 할 일은 단어를 제거하는 것입니다. 보풀을 제거하십시오. 단축할 수 있는 공사가 있나요? 문장의 의미를 더하지 않는 불필요한 단어가 있나요?

예: 이 스크립트를 실행해야 합니다.

개정: 이 ​​스크립트를 실행하십시오.

예: 사물의 이름이 그 역할을 제대로 전달하는지 확인하면 가독성을 높일 수 있습니다.

수정: 사물의 이름이 그 역할을 전달하는지 확인하세요.

특별한 이유가 없는 한, 가능한 한 빨리 요점을 파악하려고 노력하십시오. 과도한 단어와 화려한 구성에 의미를 묻지 마십시오.

단순화하는 다른 방법:

“해야 해”/“할 수 있어”

지침을 작성할 때 " You should X " 또는 " You can X " 라고 말하는 곳 어디에서나 이를 동사의 명령형 으로 바꾸세요.

예: 파일을 홈 디렉터리에 저장해야 합니다.

개정: 파일을 홈 디렉터리에 저장합니다.

이러한 변경으로 몇 단어가 제거되어 문장을 더 쉽게 읽을 수 있으며 독자가 요점을 바로 이해할 수 있습니다.

 

반응형

 

"Of" 및 "for" 절

“of”나 “for”로 구성하는 대신 명사 앞에 더 많은 정보를 넣을 수 있도록 문장을 다시 작성하세요. 이 순서는 문장을 더욱 효율적으로 만듭니다.

예: 마케팅을 담당하는 팀의 관리자

개정 : 마케팅팀장

위의 재배열된 버전에서는 독자가 각 절 다음에 이해한 내용을 수정하는 대신 의미하는 바를 더 빨리 이해할 수 있습니다.

분할하세요

긴 문장을 여러 개의 짧은 문장으로 나눕니다.

예: Foobaz 환경에서 모든 비스테이징 서버를 실행하는 중요한 이정표를 막 완료한 Acme 프로젝트로 인해 이전에 XYZ 계획으로 실행할 때 1시간 이상 걸리던 빌드 시간이 이제 10분 미만으로 표시됩니다.

개정: Acme 프로젝트는 최근 중요한 이정표를 완료했습니다. 이제 모든 비스테이징 서버가 Foobaz 환경에서 실행됩니다. 이제 빌드를 완료하는 데 10분도 채 걸리지 않습니다. 이전에는 XYZ 계획을 기반으로 한 빌드를 완료하는 데 1시간 이상이 걸렸기 때문에 이러한 변경은 상당한 개선입니다.

또한 적절한 곳에 쉼표를 추가하여 문장을 분리하세요. 예를 들어, 나는 사람들이 종속절 뒤에 쉼표를 삭제하는 경향을 발견했습니다. 편집할 때 항상 다시 추가합니다.

예: 당신이 나를 찾고 있다면 나는 내 사무실에 있을 것입니다.

수정: 당신이 나를 찾고 있다면, 나는 내 사무실에 있을 것입니다.

예: 안개 때문에 비행기가 지연되었습니다.

수정: 안개로 인해 비행기가 지연되었습니다.

나는 이것이 우리가 구어체로 말할 때 문장의 그 지점에서 멈추지 않기 때문이라고 생각합니다. 그러나 문법적으로 종속절(또는 종속절)이 문장의 시작 부분에 올 경우에는 종속절 뒤에 쉼표가 필요합니다. "올바른" 것 외에도, 쉼표는 독자가 문장의 나머지 부분으로 넘어가기 전에 방금 읽은 내용을 잠시 멈추고 처리하는 데 도움이 됩니다. 종속절 뒤에 쉼표를 사용하면 독자의 이해력이 향상됩니다.

 

수동태 제거

당신은 전에 이런 조언을 들어본 적이 있을 것입니다. 하지만 글을 쓸 때 왜 수동태를 사용하면 안 되는지 이해해야 합니다. 단순히 '나쁜 스타일'이 아닙니다.

 

수동태는 누가 또는 무엇을 수행하고 있는지 모호하게 만듭니다. 수동태 구조를 능동태로 다시 작성하면 독자가 해당 행동을 올바른 사람이나 사물에 귀속시킬 수 있기 때문에 거의 항상 말하는 내용이 더 명확해지고 문장을 더 쉽게 읽을 수 있습니다.

예: 화재 경보기가 울리고 건물에서 대피했습니다.

수정: 소방서장이 경보를 울렸고 직원들은 건물에서 대피했습니다.

예: 회사로부터 수백만 달러가 횡령되었습니다.

수정: 두 명의 임원이 회사에서 수백만 달러를 횡령했습니다.

당신 이 말하는 내용을 더 잘 이해하는 데 도움이 될 수도 있습니다. 구축한 시스템을 설명하고 "경고가 트리거되고 작업이 시작되었습니다"라고 말한다면 이러한 일이 어떻게 발생하는지 알고 계십니까? 어떤 서비스가 경고를 트리거합니까? 작업 실행을 담당하는 구성 요소는 무엇입니까? 다시 작성하다 보면 뭔가가 예상대로 작동하지 않거나 작동 방식을 모른다는 사실을 깨닫게 될 수 있습니다.

 

기술 문서에서는 작업을 누군가 또는 사물의 탓으로 돌리지 않으면 정확성이 떨어집니다. 그리고 모든 글쓰기에서 언어를 다듬는 것은 세상에 대한 이해를 다듬는 것입니다.

 

부사를 사용하지 마세요

부사에 대한 이러한 혐오감은 제가 소설 쓰기에서 취한 원칙 중 하나입니다.

 

거의 항상 부사를 더 좋고 더 구체적인 동사로 바꾸거나 대신 의미하는 바를 설명할 수 있습니다. 소설에서는 더욱 구체적으로 작성하는 것이 특히 핵심이지만, 저는 모든 유형의 글쓰기에서 부사를 제거해야 한다고 믿습니다.

 

부사에는 본질적으로 잘못된 것이 없습니다. 그것들은 제가 쓰기에 게으른 것들의 범주에 속할 뿐입니다. 내가 "그가 크게 웃었다"고 말할 때, 나는 독자가 그의 웃음의 정확한 크기를 직관할 것이라고 믿고 있습니다. "시끄럽게"라는 말은 수많은 의미를 가질 수 있지만, 내가 정말로 염두에 두고 있던 것은 "그는 식당 전체를 돌아보게 만드는 그런 굉장한 포기로 웃었다"는 것입니다.

 

사람들은 또한 종종 부사를 울타리로 사용합니다: “기본적으로, 그것은 이것입니다.” "본질적으로, 이것이 제가 말하는 것입니다." 그렇습니까, 아닌가? 부사를 제거하고 당신이 말하는 내용을 말하는데 전념하십시오.

 

지식을 가정하지 마십시오

당신이 잘 알고 있는 것에 대해 글을 쓸 때 이런 함정에 빠지기 쉽습니다. 당신은 당신의 청중이 알지 못하는 것을 고려하는 것을 잊어 버립니다. 한발 물러나 관련 맥락을 제공하지 마십시오. 사람들이 실제로 TLA(세 글자 두문자어)를 표기한다면 이메일, 문서 등을 읽는 것이 얼마나 더 즐거울지 상상해 보십시오!

 

예제부터 시작하여 이를 개선할 수 있는 몇 가지 방법을 살펴보겠습니다.

예: 이 차트는 지난 주 웹사이트의 TTFB를 보여줍니다.

어떤 사람들에게는 이 문장이 완벽하게 이해됩니다. 많은 사람들에게… 그다지 많지는 않습니다.

• 처음 사용할 때 약어를 철자하세요. 문서에 약어나 두문자를 소개할 때마다 그 의미를 자세히 설명하고 약어를 괄호 안에 넣으세요. 이후에는 약어 자체를 사용할 수 있습니다.두문자어가 무엇을 의미하는지 분명하다고 생각할 수도 있지만, 새로운 독자는 그렇지 않을 수도 있습니다.
• 개정 1: 이 차트는 지난 주 웹사이트의 첫 번째 바이트까지의 시간(TTFB) 측정항목을 보여줍니다.

• 개념을 소개할 때 개념을 간략하게 설명하는 문구나 문장을 추가하세요.
• 개정 2: 이 차트는 지난 주 웹사이트의 첫 번째 바이트까지의 시간(TTFB) 측정항목을 보여줍니다. TTFB는 사용자가 HTTP 요청을 할 때부터 사용자의 브라우저가 데이터의 첫 번째 바이트를 로드할 때까지 걸리는 시간을 측정합니다. 이는 웹사이트의 반응성을 나타내는 지표로 사용됩니다.

• 추가 읽기를 위해 링크를 걸어보세요. 개념과 해당 약어를 정의한 후에는 독자가 여전히 궁금한 경우 해당 개념에 대해 자세히 알아볼 수 있는 링크를 제공하세요. 링크에 주의를 환기시킬 필요는 없습니다.
• 개정 3: 이 차트는 지난 주 당사 웹사이트의 첫 번째 바이트까지의 시간(TTFB) 측정항목을 보여줍니다. TTFB는 사용자가 HTTP 요청을 할 때부터 사용자의 브라우저가 데이터의 첫 번째 바이트를 로드할 때까지 걸리는 시간을 측정합니다. 이는 웹 사이트의 반응성을 나타내는 지표로 사용됩니다.

이제 독자들은 여러분과 함께 있고 여러분이 말하는 내용에 대해 확신을 갖고 계속 진행할 준비가 되었습니다.

 

당신의 어조에 주의하세요

어떤 톤을 원하는지 파악하고 일관성을 유지하세요. 구어체 또는 격식을 차릴 수 있지만 둘 다 사용할 수는 없습니다.

예: 우리는 약 1~2분 동안 발견한 이 새로운 프레임워크에 정말 빠져 있었지만 시스템에서 캡처한 측정항목은 우리의 조사 목표와 정확하게 일치하지 않아 유용하지 않았습니다.

수정: 처음에는 X 프레임워크에 열광했지만, 우리가 찾고 있던 측정항목을 포착하지 못했다는 사실을 발견했습니다.

원래 문장은 매우 구어체 로 시작한 다음 형식적이고 거의 학문적인 언어로 변합니다. 가장 좋은 경우에는 전환한 이유에 대해 독자를 혼란스럽게 할 것입니다. 최악의 경우에는 당신이 말하는 내용에서 상대방의 주의가 완전히 흐트러지게 될 것입니다.

 

전문 용어와 진부한 표현을 피하세요

비즈니스 세계에서 전문 용어는 "깊은 잠수" 및 "낮게 매달린 과일"과 같은 것을 의미합니다. 다른 곳에서는 진부한 표현을 사용하는 것을 좋아합니다. 특히 야구에 대한 비유는 어떤 이유에서든 "타석에 올라라", "공원 밖으로 쳐내다", "그네를 쳐라"와 같은 것입니다.

 

당신이 의미하는 바를 정확하게 말하면 항상 더 좋고 명확해질 것입니다. 전문 용어를 사용하는 것은 게으른 일이며 독자가 해당 전문 용어를 사용하는 그룹 내 일부라고 가정합니다 (위의 지식을 가정하지 마십시오 참조). 영어가 모국어가 아닌 사람(야구의 경우 미국인이 아닌 사람)이 전문 용어와 진부한 표현을 사용하면 글을 따라가는 것이 어려울 수 있습니다.

예: tl;dr, EOD로 함께 해킹할 수 있다면 좋을 것 같습니다.

수정: 오늘 말까지 프로토타입을 제공할 수 있습니까?

원문에는 이해하기 어려운 약어와 기술 속어가 포함되어 있고, 요청처럼 들리지도 않습니다. 두 번째는 간단하며 작가에게 필요한 것이 무엇인지, 언제까지 필요한지 묻습니다.

 

공백을 활용하라

공백은 기술 문서의 핵심이지만 블로그 게시물, 이메일 등에서 큰 효과를 내는 데 사용될 수도 있습니다. 특히 컴퓨터 화면에서는 사람들이 긴 문단을 읽는 것이 어렵습니다. 그들은 구역을 벗어날 것입니다. 페이지를 시각적으로 분할하고 핵심 사항을 쉽게 식별할 수 있도록 하여 독자가 계속해서 읽을 수 있도록 하세요.

 

몇 가지 제안:

• 긴 단락을 여러 개의 짧은 단락으로 나눕니다.
• 유용한 부제목을 사용하여 문서에 구조를 부여하고 독자가 관심 있는 섹션으로 건너뛸 수 있도록 하세요.
• 동일한 정보가 포함된 단락을 읽는 것보다 글머리 기호가 있는 항목 목록을 읽는 것이 더 쉽기 때문에 관련성이 있는 경우 목록을 사용하십시오.
  • 많은 양의 정보(예: 참조 문서)를 전달해야 하는 경우에는 목록보다 테이블이 훨씬 더 좋습니다.
• 훑어보는 독자(예: 모든 사람)가 주요 요점을 선택할 수 있도록 굵은 글씨를 사용하십시오. (예시를 보려면 이 게시물의 본문을 참조하세요.)

---

결론

방금 읽은 내용을 단순화하기 위해 내 편집 철학을 두 가지 원칙으로 축소할 수 있습니다.

• 의미하는 바를 정확히 말하십시오. 즉, 부사, 전문 용어, 진부한 표현, 울타리에 의존하지 말고
• 불필요한 단어는 모두 삭제하세요.

이 두 가지 원칙을 염두에 두는 것은 자신의 글쓰기에 도움이 될 것이며 다른 사람의 글을 평가하기 위한 틀을 제공할 것입니다. 시간이 지나면서 연습하면서 자신만의 스타일과 선호도가 형성될 것입니다. 당신은 결국 내 권장 사항 중 일부와 다를 수 있으며, 그렇게 하는 이유를 아는 한 그것은 좋습니다. 편집의 요점은 언어를 어떻게 사용하고 있는지 생각하고 전달하려는 메시지에 적합한 선택을 하는 것이며, 내 규칙이나 다른 사람의 규칙을 무조건 따르는 것이 아닙니다.

 

*참조한 원본 글: https://evaparish.com/blog/how-i-edit