IT 영어 읽기를 위해 알아야 할 영문법

IT개발자의 영어 필살기

• 문법

  • 가장 큰 단위 : 문장

  • 가장 작은 단위 : 단어

  • 가장 작은 단위와 가장 큰 문장 사이에는 구 와 절이라는 단위가 있다.

  • First, you upload a new file that you created locally to the server.
    (우선 로컬 컴퓨터에서 만든 새 파일을 서버에 업로드합니다.)
    

    • 단어 : 명사, 동사, 형용사, 부사, 관사, 전치사 등의 종류(품사)
    • 구 : 복수의 단어가 모여 특정 품사와 같은 기능을 한다.
    • 절 : 복수의 단어가 모여 문장의 구성요소가 되며, 절 안에는 '주어+술어' 관계가 포함된다.

문장 전체의 담화 구조에 주목

• 순서/열거
  • 작동 순서를 설명하거나 복수의 항목을 언급할 때
    • first, second/ third
    • then, next
    • finally
• 강조
  • 글쓴이가 특히 말하고 싶은 부분을 강조하는 경우
    • 사실, 실제로 : in fact, actually
    • 특히, 그중에서 : specifically, especially, particularly
    • 아무튼 : anyway
• 추가
  • 정보를 추가하는 경우
    • 또한 : also
    • 덧붙여, 게다가 : in addition, besides
    • ~뿐만 아니라 a도 : not noly ~ but also (a)
    • 반면 : on the other hand
• 역접
  • 앞에서 이야기한 것과 반대 내용을 이야기할 때
    • 그러나 : but, however
    • ~지만 : although ~, a, though ~, a
    • ~라고 하더라도 : even if ~,
• 예시
  • 예를 들 때
    • 예를 들면 : for example, for instance, such as, e.g.
    • ~도 포함해서 : including ~
• 다른 말로 바꾸기
  • 앞에서 말한 내용을 다른 표현으로 말할 때
    • 다시 말해 : in other words
    • 즉 : namely, i.e, or
• 이유
  • 쓰고 있는 내용의 이유나 근거를 말할 때
    • ~이므로 : because ~, since ~, as ~
    • ~때문에 : because of ~, due to ~
• 결론/결과
  • 지금까지 말한 내용의 결론이나 결과를 말할 때
    • 그래서, 따라서 : so, therefore, thus
    • 그 결과, 따라서 : as a result, consequently
    • 요약하면 : in summary, in short

영어 속독 테크닉

• 영어 어순으로 이해하기
  • 영어 어순 그대로 이해하기
• 몇 개의 단어로 묶어 의미를 파악
  • /로 끊어 읽기
  • 전치사(구를 구성하는), 관계사(절을 구성하는), 접속사에 유의해서 끊어 읽으면 된다.
• 원하는 정보만 골라서 읽기
  • 스캐닝(Scanning) : 문서 전체에서 본인이 원하는 정보만 골라 읽는 방법
• 요점만 파악하며 읽기
  • 스키밍(Skimming) : 문서 전체의 요점을 파악하며 읽는 것

API 문서

• 메소드는 동사로 간결하게 설명한다.
• 필요한 부분만 골라서 찾아 읽는 것이 일반적이다.
• 개요와 세부설명으로 구성된다.
  • 필요한 정보를 빨리 찾기 위해서는 우선 개요에 주목해야한다.
• 메소드는 동사로 간결하게 설명한다.
  • 이 문서 유형의 언어적인 특징은 동사로 시작하는 문장이며, 기능을 간결하게 설명한다.
  • 문서를 읽을 때 생략을 고려해 주의해야한다.
• Key Point
  • 전체를 다 읽지 않고 필요한 부분만 골라 읽는다.
  • 주로 개요와 세부설명으로 구성된다.
  • 메소드는 동사로 간결하게 설명한다.

법률 문서 성격이 강하다

• 사용약관은 서비스나 소프트웨어 공급자가 서비스 이용자를 대상으로 쓴 문서이다.
• 용어 정의는 맨앞에서
  • 문서에서 사용되는 용어는 맨 처음에 정의해 둔다.
• shall은 의무, 규칙, 금지, may는 허가를 나타낸다.
  • shall
    • 의무(~해야한다.)
    • 규칙(~하기로 한다.)
    • 금지(shall not으로 '~해서는 안 된다')
  • may
    • 허가(~해도 좋다.)
• 같은 의미의 단어를 중복하거나 대문자로 표기해 강조한다.
  • 중요한 항목을 강조할 경우에는 모두 대문자로 기술한다.
• 쉼표와 세미콜론으로 구분해 수준을 분류한다.
  • 작은 수준 구분 : ,
  • 큰 수준 구분 : ;

이메일

• 인사말, 본론, 맺음말 등의 패턴으로 구성된다.
• 다양한 내용. 요청 사항을 읽어내야 한다.
• 제목, 인사말, 본론, 맺음말, 서명의 구성이 가장 보편적
  • 메일(전형적인 패턴, 담화 구조)
    • 제목
      • 제목을 잘 쓰면 그것만으로 내용을 알 수 있다.
    • 인사말
      • 격식을 갖춘 표현
        • Dear Kangho Kim,
        • Dear Staff, (친애하는 직원 여러분)
      • 다소 가벼운 표현
        • Hello,
        • Hello ABCD Photos Team, (안녕하세요. 제품개발팀 여러분)
      • 가벼운 표현
        • Hi
        • Hi Jane,
        • Hi Developer, (개발자분께)
    • 본론
      • 상대의 의도를 확실히 파악함
    • 맺음말
      • 격식을 갖춘 표현
        • Best regards,
        • Kindest regards,
        • Sincerely,
      • 다소 가벼운 표현
        • Regards,
        • Thanks,
        • Thank you,
      • 가벼운 표현
        • Bye,
        • Cheers,
        • Good luck!
    • 서명
      • 이름 외에도 메일 주소, 웹사이트 주소, 회사명 등이 들어갈 수 있다.
• IT엡계에서는 비교적 가벼운 표현이 어울린다.
  • 수신자 이름을 적는 것 보다는 Dear Developer, Hello Team 과 같이 가벼운 표현을 사용한다.
• POINT
  • 다양한 내용, 요청 사항을 읽어내야 한다.
  • 제목, 인사말, 본론, 맺음말, 서명의 구성이 가장 보편적
  • IT 업계에서는 비교적 가벼운 표현이 어울린다.

앱 사용자 후기

• 사용자 후기와 평가 글에서 유익한 정보를 얻는다.
• '사용자 이름', '날짜', '평점', '후기 내용'으로 구성된다.
  • 실제로 읽게 되는 부분 : 사용자 후기 부분
  • 앱 개선에 도움이 될 만한 구체적인 후기 : 문제점, 개선점을 쓴 글
• 일상 회하체, 줄임말, 이모티콘이 많이 쓰이고, 철자나 문법 오류도 있다.
  • 일상 회화체 같은 표현을 쓴다.
  • 줄임말을 쓴다.
    • 단어 철자를 줄임
    • 두문자어나 약어
  • 이모티콘이 많다.
  • 문법이나 철자 오류가 많다.
  • 후기에서는 격식을 차린 영어와는 거리가 멀다.
• 긍정 또는 부정적인 평가를 읽어낸다.
  • 후기에서는 긍정적이거나 부정적인 감정 표현이 많이 보인다.
• POINT
  • 사용자 후기를 읽고 유익한 정보를 얻어낸다.
  • 일상 회화체, 줄임말, 이모티콘이 많이 쓰이고, 철자나 문법 오류도 있다.
  • 긍정 또는 부정적 평가를 읽어낸다.

뉴스

• 제목에 주목해서 정보를 수집한다.
• 폭넓은 화제를 다루기 때문에 다양한 어휘가 사용된다.
  • 다양한 어휘가 사용된다.
• '개요 -> 세부 설명'의 전개가 일반적
  • 본문은 첫 단락에 전체 기사의 개요가 정리되어 있을 때가 많다.
• 제목에 주목해 정보를 수집하자. 뉴스 기사 특유의 글쓰기 방법이 있다.
  • 뉴스 기사에서 효율적으로 정보를 수집하기 위해 주의해야 할 것은 기사 제목이다.
  • 뉴스 기사 제목 특징
    • 관사나 be 동사가 생략됨
      • ex) Fans angry over 'missing' iPhone 7 headphone socket
        • be 동사를 살린다면 'Fans are angry ~', 관사를 문법대로 살린다면 '~over the 'missing' iPhone ~'이 된다.
    • 수동태에서 be동사가 생략됨
      • ex) Police Scotland IT programme abandoned
        • be 동사를 살린다면 is abandoned 혹은 has been abandoned가 된다.
    • 과거 사실 보도에 현재형이 사용됨
      • ex) Google acquires Anvato, a media streaming and monetization platform for broadcasters
        • 구글이 안바토를 이미 인수했으므로 원래는 'has acquired' 또는 'acquired'가 맞다.
    • 미래의 일을 표현하는데 to 부정사가 사용됨
      • ex) Kevin Turner, Microsoft Executive, to Join Citadel Securities
        • 터너의 입사가 발표된 것이므로 원래는 'will join'이다.
• 고유명사를 다른 표현으로 바꿔 쓰는 경우가 있다.
  • ex) KRlangTech Inc. 라는 한국 기업 => The Korean company라고 바꿔 부른다.
  • 뉴스 내에서 'the ~ '가 무엇을 가리키는지 감이 안올 때는, 다른 말로 바꿔서 표현했을 가능성을 생각하고 해당하는 단어를 찾아 본다.
• POINT
  • 폭넓은 화제를 다루기 때문에 다양한 어휘가 사용된다.
  • '개요 -> 세부 설명'의 전개가 일반적
  • 제목에 주목해 정보를 수집하자. 기사 특유의 글쓰기 방법이 있다.
  • 고유명사를 다른 표현으로 바꿔 쓰는 경우가 있다.

기술 블로그

• 제목이나 표제어에서 내용을 효율적으로 파악한다.
• 주로 개발자가 기술 이슈에 대해 작성하지만, 글의 소재는 다양하다
  • 기술 블로그 : 소프트웨어 개발자나 네트워크 기술자들이 기술 이슈를 소재로 쓰는 문서이다.
• 제목, 요약, 표제어 등에서 내용을 효율적으로 파악하자
  • 긴 글이라면 처음에 결론이나 요약, 정리 부분을 확인하고 그 뒤에 본문을 자세히 읽는 것이 좋다.
  • 글이 긴 경우 표제어만을 보고 전체를 파악하는 것도 효과적이다.
  • 처음에 결론이나 요약, 정리를 확인한다든가, 표제어만을 따라가며 읽으면 전체 글의 요점을 파악할 수 있다.
  • 블로그 글은 처음부터 순서대로 읽을 필요가 없다.
  • 'In summary'나 'In short'와 같은 표현은 결론이나 결과를 나타낼 때 사용한다.
  • 표제어가 없는 글은 단서가 되는 담화 표지가 없는지를 주의해서 살펴봐야 한다.
• 글쓰기에 능숙하지 않은 사람의 블로그 글은 이해하기 어려울 수도 있다.
• 댓글에서도 정보를 얻는다.
  • 댓글에 유익한 정보가 담겨 있기도 한다.
  • 괌심이 가는 블로그를 발견하면 댓글에도 주목해야 한다.
• POINT
  • 주로 개발자가 기술 이슈에 대해 작성하지만, 글의 소재는 다양하다
  • 제목, 요약, 표제어 등에서 내용을 효율적으로 파악하자
  • 글쓰기에 능숙하지 않은 사람의 블로그 글은 이해하기 어려울 수도 있다.
  • 댓글에서도 정보를 얻는다.

매뉴얼

• 사용법 순서나 표제어에 사용되는 동사 읽기
• 사용법을 설명하는 문서로서 목적에 따라 종류가 다르다.
  • 메뉴얼 : 제품이나 서비스의 사용법을 설명하는 문서이다.
  • 목적에 따라 몇 가지 종류가 있다.
    • 일반 사용자 : User guide(사용자 가이드)
    • 개발자나 전문가가 대상 : Configuration guide(구성 가이드)
    • 서비스 메뉴얼 : Service manual
    • 설치 메뉴얼 : Installation manual
    • 등이 있다.
• 목차와 찾아보기를 활용해 필요한 정보를 찾는다.
  • 독자가 필요한 정보를 빨리 찾을 수 있도록 구성된다.
  • 목차를 보면 장과 절의 제목을 확인할 수 있다.
  • 목차를 활용하면 문서의 전체 요점을 빠르게 파악할 수 있다.
  • 키워드로 정보를 찾고 싶을 때는 찾아보기를 이용한다.
• 사용법은 명령형으로 간결하게 적는다.
  • 메뉴얼은 문서의 성격상 주로 사용법이나 작동 순서 설명이 핵심 부분이다.
  • 사용법은 숫자를 이용해 차례대로 서술하는 것이 일반적이다.
  • 작동 설명에서는 주로 동사의 명령형을 쓴다.
  • 영어에서는 간결한 표현이 더 중요하다.
  • 메뉴얼의 설명은 'you'로 시작하는 경우가 일반적이다.
  • 사용자의 소유물은 'your'로 지시한다.
• 사용법을 설명하는 표제어는 to 부정사나 동명사로 표현한다.
  • 작동 순서나 사용법 설명 앞에는 표제어가 붙어 있다.
  • 표제어에는 to 부정사나 동명사를 주로 사용한다.
  • 사용자의 시점에서 사용자의 행위를 동사로 표현하기 위해서이다.
  • 표제어를 따로 정리해 '목차'를 만든다.
    • to 부정사나 동명사에 주목해 파악해야한다.

기술 사양서

• 목차로 전체 내용을 파악하고, 용어 정의로 오해를 피한다.

• 제품이나 서비스가 충족해야 하는 요건이나 기준을 설명한다.

  • 기술 사양서는 제품이나 서비스가 충족해야 하는 요건과 기준을 설명하는 문서이다.

• 목차로 전체 내용을 파악할 수 있도록 구성된다.

  • 대규모 사양서의 경우 우선 SAMPLE 영문 [가]처럼 목차로 전체 내용의 밑그림을 보여주는 것이 일반적이다.
  • 목차가 있는 사양서는 무조건 본문부터 읽지 말고 우선 목차에 주목해 전체적인 구성을 파악한다.
  • 개요 -> 세부설명 형태로 읽기 쉽게 구성된 사양서가 가장 흔하다.

• 조동사로 의무, 금지, 권장 사항 등을 표현한다.

  • 사양서에는 모호하지 않고 명확한 표현을 써야 한다.
  • RFC에서 사용되는 조동사의 의미
    • 
    • shall은 사양서에서는 자주 사용되지만 일상 영어에서는 별로 사용되지 않는, 매우 강한 표현이다.

• 용어 정의나 찾아보기를 활용해 이해를 돕는다.

  • 용어 정의
    • 용어 : 글을 쓰는 사람과 읽는 사람 사이에 오해가 생기지 않도록 의미를 명확히 정의한 단어이다.
    • 사양서를 읽다가 해석하기 어려운 단어를 만나면 용어 정의 부분을 먼저 확인한다.
  • 찾아보기
    • 필요한 정보를 효율적으로 찾기 위해 찾아보기를 사용하면 편리하다.

Q&A 사이트

• 어떤 Q&A인지 질문 제목에서 유추해보자
• 개발자들끼리 서로 질문하고 답한다. 회화체이거나 문법 오류도 있다.
• '앱 사용자 후기' 문서 유형과 마찬가지로 화회체나 두문자어, 약어가 자주 보인다.
• 신조어
  • 어빈딕셔너리(Urban Dictionary)등의 신조어 사이트 활용하기
• 방법, 정의, 원인 등 어떤 Q&A인지 제목으로 먼저 유추한다.
  • Q&A 사이트에서 도움되는 게시물을 효율적으로 찾으려면, 질문 제목으로 내용을 짐작해야 한다.
  • 어떤 '방법'에 대해 질문하는 경우
    • How can I (How do I) ~ ?
    • How to ~ ?
  • 어떤 '정의'를 묻는 경우
    • What is(are) ~ ?
  • 에러의 '원인'이나 '이유'를 묻는 경우
    • Why ~ ?
• 방법을 묻는 경우, 상황 설명에 이어 질문 내용이 뒤따른다.
  • 방법을 묻는 질문에서는 우선 질문자가 처한 상황을 설명하고 그다음에 질문 내용이 나오는 담화 구조가 가장 흔하다.
  • 구체적이고 자세한 예를 보여줄 때는 '다음과 같이~'의 의미인 'following'이나 콜론(:)이 많이 사용된다.
• 질문과 답변의 신뢰도는 투표나 '좋아요' 수로 측정한다.
  • 답변의 신뢰도를 가늠하기 위해 투표수를 활용한다.
  • Q&A 사이트에서 답변자의 프로필을 확인할 경우, 레벨, 뱃지, 기타 활동이력에 대한 정보도 참고할 수 있다.