개발을 하다 보면 영어를 피하기 어렵다.
프로그래밍 언어의 문법부터 API 문서, 에러 메시지, Git 커밋, 이슈 트래커, Stack Overflow, 공식 문서까지 대부분 영어로 되어 있다.
그렇다고 영어 회화를 잘해야 개발을 할 수 있는 것은 아니다.
개발에서 필요한 영어는 일반적인 영어와 조금 다르다.
문장을 완벽하게 해석하는 능력보다 기술적인 문장에서 핵심 정보를 빠르게 뽑아내는 능력이 중요하다.
개발 영어의 기본 구조
개발 문서는 대체로 다음 구조를 가진다.
문제 또는 목적 -> 조건 -> 동작 -> 결과 -> 예외
예를 들어 다음과 같은 문장이 있다고 하자.
This method returns the cached value if one exists.
Otherwise, it fetches the value from the server.
문법을 하나하나 해석하기보다 핵심 동작을 잡으면 된다.
캐시 값이 존재한다 -> 캐시 값 반환
캐시 값이 없다 -> 서버에서 가져옴
개발 영어에서는 이런 식으로 읽는 것이 효율적이다.
반드시 알아야 하는 동사
개발 문서에서 반복해서 등장하는 동사는 따로 익혀두는 것이 좋다.
| 영어 | 의미 | 개발에서의 의미 |
|---|---|---|
| create | 생성하다 | 객체, 파일, 리소스 생성 |
| initialize | 초기화하다 | 초기 상태 설정 |
| configure | 설정하다 | 옵션이나 환경 설정 |
| define | 정의하다 | 변수, 함수, 타입 등을 정의 |
| declare | 선언하다 | 변수나 함수 등을 선언 |
| implement | 구현하다 | 기능이나 인터페이스 구현 |
| invoke | 호출하다 | 함수나 메서드 호출 |
| execute | 실행하다 | 코드나 명령 실행 |
| return | 반환하다 | 값을 반환 |
| retrieve | 가져오다 | 데이터 조회 |
| fetch | 가져오다 | 서버나 외부 저장소에서 데이터 가져오기 |
| update | 갱신하다 | 기존 값 변경 |
| modify | 수정하다 | 기존 데이터나 동작 변경 |
| remove | 제거하다 | 항목 제거 |
| delete | 삭제하다 | 데이터를 삭제 |
| handle | 처리하다 | 이벤트, 예외, 요청 등을 처리 |
| throw | 발생시키다 | 예외를 발생 |
| catch | 잡다 | 예외를 처리 |
| validate | 검증하다 | 입력값이나 데이터 검증 |
| parse | 분석하다 | 문자열 등을 구조화된 데이터로 변환 |
| serialize | 직렬화하다 | 객체를 데이터 형식으로 변환 |
| deserialize | 역직렬화하다 | 데이터를 객체로 복원 |
| resolve | 해결하다 | 문제, Promise, 의존성 등을 해결 |
| reject | 거부하다 | 요청이나 Promise 등을 거부 |
| prevent | 방지하다 | 특정 동작이 발생하지 않도록 함 |
| support | 지원하다 | 기능이나 환경을 지원 |
| provide | 제공하다 | 기능이나 API 등을 제공 |
| require | 요구하다 | 특정 조건이나 값이 필요 |
| depend | 의존하다 | 다른 요소에 의존 |
| inherit | 상속하다 | 부모 타입의 특성 상속 |
| override | 재정의하다 | 상속된 동작 변경 |
| expose | 노출하다 | 외부에서 사용할 수 있도록 공개 |
| consume | 사용하다 | API, 데이터, 리소스 등을 소비 |
| subscribe | 구독하다 | 이벤트나 스트림 등을 구독 |
| publish | 발행하다 | 이벤트나 메시지를 발행 |
특히 handle, provide, support, require, depend는 문서에서 굉장히 자주 등장한다.
개발에서 자주 나오는 명사
기능과 동작
feature 기능
behavior 동작
operation 연산 / 작업
process 처리 / 프로세스
workflow 작업 흐름
lifecycle 생명주기
state 상태
condition 조건
requirement 요구사항
코드 구조
variable 변수
constant 상수
parameter 매개변수
argument 인자
return value 반환값
property 속성
field 필드
method 메서드
function 함수
class 클래스
interface 인터페이스
implementation 구현
instance 인스턴스
dependency 의존성
데이터
value 값
data 데이터
input 입력
output 출력
result 결과
response 응답
request 요청
payload 전달 데이터
metadata 메타데이터
resource 리소스
reference 참조
비슷해 보이지만 다른 단어
개발하면서 가장 많이 헷갈리는 부분이다.
parameter vs argument
parameter -> 함수가 정의될 때 사용하는 변수
argument -> 함수를 호출할 때 전달하는 실제 값
void Move(Vector3 position)
{
}
여기서 position은 parameter다.
Move(playerPosition);
여기서 playerPosition은 argument다.
property vs field
일반적으로 C# 기준으로 보면 다음과 같이 구분할 수 있다.
private int health;
public int Health { get; set; }
health는 field이고 Health는 property다.
언어에 따라 개념과 표현 방식이 달라질 수 있으므로 문맥을 같이 봐야 한다.
create vs initialize
둘은 비슷하지만 같은 의미가 아니다.
create -> 무언가를 새로 만든다
initialize -> 만들어진 대상의 초기 상태를 설정한다
예를 들어 객체를 생성한 뒤 초기값을 넣는 과정은 다음과 같다.
create object -> initialize object
compile vs build
compile -> 소스 코드를 다른 형태의 코드로 변환
build -> 프로그램을 실행 가능한 결과물로 만드는 전체 과정
실제 개발 환경에서는 여러 작업이 함께 수행되기 때문에 build가 더 넓은 의미로 사용되는 경우가 많다.
error vs exception
error -> 문제가 발생했다는 넓은 개념
exception -> 프로그램 실행 중 발생하는 예외 상황
모든 error가 exception인 것은 아니다.
문서에서 자주 나오는 표현
개발 문서에서는 특정 표현이 반복된다.
must
The value must not be null.
값은 null이어서는 안 된다.
must는 강한 요구사항이다.
should
The method should return a valid result.
해당 메서드는 유효한 결과를 반환해야 한다.
should는 일반적으로 권장 또는 기대되는 동작을 나타낸다.
may
This operation may fail.
이 작업은 실패할 수 있다.
가능성을 나타낸다.
can
This method can be called from multiple threads.
이 메서드는 여러 스레드에서 호출할 수 있다.
가능하거나 허용되는 동작을 나타낸다.
unless
The cache is used unless it has expired.
캐시가 만료되지 않았다면 캐시를 사용한다.
unless는 개발 문서에서 조건을 표현할 때 상당히 자주 나온다.
대부분 다음과 같이 이해하면 된다.
A unless B
= B가 아니라면 A
otherwise
Return the cached value. Otherwise, fetch the data.
캐시 값을 반환한다. 그렇지 않으면 데이터를 가져온다.
코드의 else와 비슷한 흐름을 만든다.
조건 만족 -> A
otherwise -> B
either / neither
Either value can be used.
둘 중 어느 값이든 사용할 수 있다.
Neither value is valid.
두 값 모두 유효하지 않다.
에러 메시지 읽는 방법
에러 메시지를 영어 문장처럼 처음부터 끝까지 번역할 필요는 없다.
다음 정보를 먼저 찾는다.
무슨 문제가 발생했는가
-> 어디에서 발생했는가
-> 무엇이 기대되었는가
-> 실제로 무엇이 들어왔는가
예를 들어:
ArgumentException:
Expected a positive value, but received -1.
핵심만 뽑으면 된다.
ArgumentException
-> 인자 문제
Expected a positive value
-> 양수여야 함
received -1
-> 실제 값은 -1
따라서 문제는 단순하다.
잘못된 인자 전달
Stack Trace 읽기
Stack Trace에서는 문장보다 구조를 보는 것이 중요하다.
NullReferenceException
at PlayerController.Update()
at GameManager.Tick()
at GameLoop.Run()
호출 흐름을 보면:
GameLoop.Run() -> GameManager.Tick() -> PlayerController.Update()
실제 예외가 발생한 위치와 호출한 위치를 구분해야 한다.
가장 아래에 있는 함수가 반드시 원인이라는 보장은 없다.
예외가 발생한 지점과 잘못된 상태를 만든 원인은 다를 수 있다.
API 문서 읽는 방법
API 문서는 보통 다음 정보를 포함한다.
이름
-> 설명
-> Parameters
-> Return Value
-> Exceptions
-> Example
-> Remarks
예를 들어:
GetComponent<T>()
Retrieves the component of the specified type
from the GameObject.
Parameters:
T
The type of component to retrieve.
Returns:
The component if found; otherwise, null.
중요한 부분만 뽑으면:
무엇을 하는가
-> 특정 타입의 Component를 가져온다
입력
-> T
결과
-> Component 또는 null
모든 문장을 번역하는 것보다 API의 계약을 파악하는 것이 중요하다.
Return Value를 읽는 습관
개발 문서에서는 Returns 또는 Return Value 부분을 반드시 확인하는 것이 좋다.
Returns the requested object.
Returns null if the object does not exist.
이 문장은 단순히 “객체를 반환한다”가 아니다.
성공 -> object
실패 -> null
즉 호출한 쪽에서 null 처리가 필요한 API라는 의미다.
Exception을 읽는 습관
API 문서에 다음과 같이 적혀 있다면:
Throws ArgumentNullException if input is null.
다음처럼 이해하면 된다.
input == null -> ArgumentNullException
Throws, Raises, May throw 같은 표현은 예외 발생 조건을 설명하는 경우가 많다.
Git에서 자주 사용하는 영어
Git을 사용하다 보면 개발 영어가 압축된 형태로 많이 등장한다.
commit 커밋
branch 브랜치
merge 병합
rebase 리베이스
checkout 전환
switch 전환
stash 임시 저장
fetch 원격 변경사항 가져오기
pull 원격 변경사항 가져오고 병합
push 원격 저장소에 업로드
clone 저장소 복제
fork 저장소를 복제하여 별도 저장소 생성
커밋 메시지에서도 자주 사용한다.
Add player movement
Fix collision bug
Update UI layout
Remove unused code
Refactor inventory system
Improve loading performance
이 정도 패턴만 익혀도 커밋 내용을 빠르게 읽을 수 있다.
Issue에서 자주 나오는 표현
bug 버그
issue 이슈
reproduction 재현
reproduce 재현하다
expected 예상 결과
actual 실제 결과
regression 기존 기능이 다시 깨지는 문제
workaround 임시 해결책
root cause 근본 원인
fix 수정
patch 패치
특히 버그 리포트에서는 다음 구조가 자주 사용된다.
Steps to reproduce
-> 버그 재현 절차
Expected behavior
-> 예상 동작
Actual behavior
-> 실제 동작
Environment
-> 발생 환경
성능 관련 영어
게임 개발에서는 특히 많이 나온다.
performance 성능
optimization 최적화
bottleneck 병목
overhead 추가 비용
latency 지연 시간
throughput 처리량
memory usage 메모리 사용량
allocation 할당
deallocation 해제
garbage collection GC
frame time 프레임 처리 시간
예를 들어:
This operation introduces significant overhead.
핵심은:
이 작업의 추가 비용이 크다.
The CPU is the bottleneck.
CPU가 병목이라는 의미다.
네트워크에서 자주 나오는 영어
client 클라이언트
server 서버
request 요청
response 응답
connection 연결
disconnect 연결 종료
packet 패킷
protocol 프로토콜
timeout 시간 초과
retry 재시도
reliable 신뢰성 있는
unreliable 신뢰성이 보장되지 않는
synchronize 동기화하다
replicate 복제하다
serialize 직렬화하다
deserialize 역직렬화하다
게임 서버에서는 다음 표현도 자주 접한다.
authoritative server
-> 서버 권위 구조
client prediction
-> 클라이언트 예측
server reconciliation
-> 서버 기준으로 상태 보정
lag compensation
-> 지연 보상
state synchronization
-> 상태 동기화
객체지향에서 자주 나오는 영어
abstraction 추상화
encapsulation 캡슐화
inheritance 상속
polymorphism 다형성
composition 구성
coupling 결합도
cohesion 응집도
dependency 의존성
interface 인터페이스
implementation 구현
특히 coupling과 cohesion은 설계 문서에서 자주 등장한다.
high coupling
-> 높은 결합도
low coupling
-> 낮은 결합도
high cohesion
-> 높은 응집도
low cohesion
-> 낮은 응집도
동의어를 묶어서 외우기
개발 영어는 단어 하나씩 외우기보다 비슷한 의미를 묶어두는 편이 좋다.
생성
create / generate / instantiate
삭제
remove / delete / destroy
변경
change / modify / update
가져오기
get / fetch / retrieve
실행
run / execute / invoke
오류
error / exception / failure
단, 동의어라고 완전히 같은 것은 아니다.
문맥에 따라 기술적인 의미가 달라진다.
접두사와 접미사
개발 영어는 단어 자체보다 접두사와 접미사를 알면 훨씬 빨라진다.
un- ~하지 않은
re- 다시
pre- 이전
post- 이후
sub- 하위
super- 상위
inter- 사이
multi- 여러
auto- 자동
de- 제거 / 반대 동작
예:
initialize
-> 초기화
reinitialize
-> 다시 초기화
serialize
-> 직렬화
deserialize
-> 역직렬화
connect
-> 연결
disconnect
-> 연결 해제
개발 문장을 읽는 핵심
개발 문장을 볼 때는 다음 순서로 읽는 것이 좋다.
주어 -> 동작 -> 대상 -> 조건 -> 예외
예:
The system automatically retries the request
when the connection is lost.
핵심만 보면:
system -> retries request -> connection lost
즉:
연결이 끊기면 시스템이 요청을 자동으로 재시도한다.
영어를 한국어 어순으로 완벽하게 변환할 필요가 없다.
코드로 바꿔 생각하면 된다.
if connectionLost:
retry(request)
개발 영어의 핵심은 번역이 아니다
개발 영어를 공부한다고 해서 영어 문장을 전부 한국어로 번역하는 능력을 키울 필요는 없다.
중요한 것은 다음과 같다.
문서 -> 요구사항 파악
API -> 사용 조건 파악
에러 -> 문제 원인 파악
Git -> 변경 내용 파악
Issue -> 문제 상황 파악
코드 -> 동작 파악
결국 개발 영어의 목적은 영어를 잘하는 것 자체가 아니라 기술 정보를 빠르게 이해하는 것이다.
문장 하나를 완벽하게 번역하지 못해도 상관없다.
무엇을 하는가
-> 언제 동작하는가
-> 무엇을 입력받는가
-> 무엇을 반환하는가
-> 언제 실패하는가
이 다섯 가지를 파악할 수 있으면 대부분의 개발 문서는 읽을 수 있다.
핵심 정리
개발 영어에서 우선순위를 잡으면 다음과 같다.
기본 동사 -> 기술 명사 -> 조건 표현 -> API 표현 -> 에러 표현 -> 문서 읽기
그리고 실제 개발에서는 다음 정도의 영어만 빠르게 읽을 수 있어도 상당히 많은 정보를 처리할 수 있다.
create / initialize / configure
get / fetch / retrieve
update / modify / remove
execute / invoke / return
handle / validate / parse
require / support / provide
throw / catch / fail
expected / actual
request / response
input / output
dependency / implementation
performance / overhead / bottleneck
개발 영어는 별도의 교양 과목이라기보다 개발 도구를 다루기 위한 인터페이스 언어에 가깝다.
영어 자체를 공부하는 것보다 개발 문장을 많이 읽고, 반복해서 등장하는 표현을 익히는 것이 훨씬 효율적이다.
영어 문장 해석 -> 기술 정보 추출 -> 코드와 개념으로 연결
이 과정이 익숙해지면 영어 문서에 대한 의존도가 문제가 아니라 오히려 개발 정보에 접근할 수 있는 범위가 넓어진다.