개발자 영어, 이 정도면 충분하다

입사 초기에 팀 리드가 PR 리뷰에서 "이 부분은 React 공식 문서의 useEffect 섹션 읽어보면 좋을 것 같아"라고 코멘트를 남겼다. 링크를 열었다. 영어였다. 한국어 번역 페이지로 전환하려고 했는데, 번역이 아직 안 된 섹션이었다.

그때의 나는 영어 문서를 보면 반사적으로 뒤로 가기를 눌렀다. 영어를 못 하는 건 아닌데, 기술 문서를 영어로 읽으면 속도가 한국어의 3분의 1로 떨어졌다. 그래서 늘 한국어 블로그 글이나 번역본을 먼저 찾았다. 한국어 자료가 없으면 그냥 넘어가는 경우도 있었다.

이게 한계가 되기 시작한 건 입사 3개월 차쯤이었다.

에러 메시지가 영어인 건 어쩔 수 없다#

개발하면서 매일 마주치는 건 에러 메시지다. 그리고 에러 메시지는 전부 영어다.

text

TypeError: Cannot read properties of undefined (reading 'map')

이 정도는 괜찮다. 근데 이런 게 나오면 당황했다.

text

Hydration failed because the initial UI does not match what was rendered on the server.

Next.js hydration 에러. 처음 봤을 때는 "hydration이 뭐고 initial UI가 뭐지" 싶었다. 각 단어는 아는데 문장이 무슨 뜻인지 바로 와닿지 않았다. 지금은 보자마자 "서버에서 렌더링한 HTML이랑 클라이언트에서 렌더링한 결과가 다르다는 거구나"라고 이해하는데, 이건 영어 실력이 늘어서라기보다는 해당 개념을 반복해서 접했기 때문이다.

개발 영어의 핵심은 이거다. 단어 자체의 뜻보다 그 단어가 기술적으로 무엇을 의미하는지를 아는 것. property는 "속성"이 아니라 객체의 프로퍼티다. render는 "표현하다"가 아니라 컴포넌트를 DOM에 그리는 것이다. hydrate은 사전적으로 "수분을 공급하다"인데, 프론트엔드에서는 서버에서 보낸 정적 HTML에 이벤트 리스너를 붙이는 과정이다.

이런 용어들은 영어 공부를 해서 늘는 게 아니라, 개발 공부를 하면서 자연스럽게 쌓인다.

공식 문서는 사실 읽기 쉬운 편이다#

이상하게 들릴 수 있는데, 기술 공식 문서는 영어 원서 중에서 쉬운 축에 속한다. 문학적 표현이 없다. 비유가 거의 없다. 문장 구조가 단순하다. 그리고 코드 예시가 많다.

React 문서를 예로 들면 이런 식이다.

useEffect is a React Hook that lets you synchronize a component with an external system.

주어(useEffect) + 동사(lets you) + 목적(synchronize a component with an external system). 문장 구조가 뻔하다. 여기에 코드 예시가 바로 따라오기 때문에, 영어를 다 이해 못 해도 코드를 보면 감이 온다.

내가 영어 문서 읽는 습관을 들인 방법은 단순했다. 브라우저 번역 기능을 옆에 두고, 먼저 영어로 읽어보고, 모르는 부분만 번역을 확인하는 식이었다. 처음에는 문장마다 번역을 확인했는데, 한 달쯤 지나니까 단락 단위로 확인하게 됐고, 석 달쯤 되니까 번역을 거의 안 봤다. 특히 MDN 같은 사이트는 문서 구조가 일정해서, 몇 번 읽다 보면 패턴이 보인다. Syntax, Parameters, Return value, Examples. 이 순서로 되어있으니 영어를 다 읽지 않아도 필요한 정보를 빨리 찾을 수 있다.

Stack Overflow에서 질문하기#

영어 읽기가 좀 되기 시작하면 Stack Overflow에서 질문하는 것도 어렵지 않다. 사실 Stack Overflow 질문에는 특유의 템플릿이 있다.

text

I'm trying to [목표].
I expected [기대 결과].
But I'm getting [실제 결과].
Here's my code: [코드 블록]
I've already tried: [시도한 것들]
Environment: [환경 정보]

이 패턴만 알면 된다. 문법이 좀 틀려도 상관없다. Stack Overflow에서 중요한 건 문제를 명확하게 설명하는 거지, 영어를 잘 쓰는 게 아니다. 실제로 비영어권 개발자들이 쓴 질문을 보면 문법은 엉망인데 문제 설명이 명확해서 답변이 잘 달리는 경우가 많다.

내가 처음 Stack Overflow에 질문을 올린 건 Next.js에서 dynamic import 할 때 타입 에러가 나는 문제였다. 한 시간 동안 영어로 질문을 작성했다. 지금 보면 되게 어색한 영어인데, 코드 블록이랑 에러 메시지를 정확히 붙여넣었더니 30분 만에 답변이 달렸다. 그때 느꼈다. 영어를 잘 하는 게 아니라, 문제를 잘 설명하면 된다는 걸.

GitHub Issue와 PR 코멘트#

회사에서 오픈소스 라이브러리에 이슈를 올리거나, 외부 라이브러리의 PR을 리뷰할 일은 많지 않다. 하지만 가끔 있다. 우리가 쓰는 라이브러리에서 버그를 발견했을 때, GitHub Issue를 올려야 하는데, 이것도 패턴이 있다.

markdown

## Description
Brief description of the issue.

## Steps to Reproduce
1. Do this
2. Then this
3. See error

## Expected Behavior
What should happen.

## Actual Behavior
What actually happens.

## Environment
- Library version: x.x.x
- Browser: Chrome 120
- OS: macOS

이 템플릿을 따라서 쓰면 된다. 나는 라이브러리 이슈 두 번 올려봤는데, 두 번 다 메인테이너가 답장을 줬다. 문법 지적은 한 번도 없었다. 재현 가능한 버그 리포트를 올리면 고맙다고 한다.

불필요한 영어에 대해서#

여기서 하고 싶은 말은 "개발자니까 영어를 잘해야 한다"가 아니다. 오히려 반대다. 개발자에게 필요한 영어는 생각보다 범위가 좁다.

영어 회화? 외국계 회사가 아니면 거의 안 쓴다. 영작? 이메일 쓸 일이 있어도 지금은 번역 도구가 워낙 좋아서 큰 문제가 안 된다. TOEIC 점수? 개발자 채용에서 영어 점수를 보는 곳은 거의 없다.

필요한 건 딱 세 가지다.

기술 문서를 영어로 읽을 수 있는 능력
에러 메시지와 로그를 해석할 수 있는 능력
기술적 문제를 영어로 검색하고, 필요하면 간단히 질문할 수 있는 능력

이 세 가지는 의식적으로 공부하지 않아도, 개발을 하면서 영어 자료를 피하지 않으면 자연스럽게 늘어난다. "영어 공부를 해야지"라고 압박을 받을 필요 없이, 그냥 한국어 자료를 찾기 전에 영어 자료를 먼저 한번 열어보는 습관만 들이면 된다.

커밋 메시지와 변수명#

영어가 개발에서 필요한 또 다른 영역이 있다. 커밋 메시지와 변수명이다.

입사 초기에 커밋 메시지를 한국어로 쓸지 영어로 쓸지 고민했다. 우리 팀은 영어로 쓰는 컨벤션이었다. feat: add user profile page, fix: resolve infinite loop in useEffect. 이런 식. 처음에는 커밋 메시지 하나 쓰는 데도 구글 번역기를 켰는데, 커밋 메시지에 쓰이는 영어 패턴이 한정적이어서 금방 익숙해졌다. add, update, fix, remove, refactor. 이 다섯 개 동사면 대부분의 커밋 메시지를 쓸 수 있다.

변수명도 마찬가지다. isLoading, handleSubmit, fetchUserData, formatDate. 프로그래밍에서 쓰는 영어 단어는 일상 영어보다 범위가 훨씬 좁다. 자주 쓰는 패턴을 익히면 된다. is로 시작하면 불리언, handle로 시작하면 이벤트 핸들러, fetch로 시작하면 API 호출. 네이밍 규칙 자체가 일종의 문법이다.

가끔 변수명이 안 떠오를 때는 다른 오픈소스 프로젝트에서 비슷한 기능을 어떻게 이름 지었는지 본다. GitHub에서 검색하면 대부분 나온다. 남이 쓴 좋은 이름을 참고하는 건 부끄러운 게 아니다.

요즘 드는 생각#

입사 2년 차인 지금은 영어 문서를 읽는 게 자연스러워졌다. React 문서, MDN, TypeScript Handbook 같은 건 영어로 읽는 게 더 편하다. 한국어 번역이 원문의 뉘앙스를 놓치는 경우가 종종 있어서.

다만 최근에 느끼는 건, 영어 리스닝 능력이다. 해외 컨퍼런스 영상을 자막 없이 보려면 아직 버겁다. React Conf나 Next.js Conf 같은 거 볼 때 자막을 켜야 편한데, 자막 없이도 알아들을 수 있으면 좋겠다는 생각은 가끔 한다. 근데 이건 솔직히 "있으면 좋고 없어도 되는" 영역이라, 따로 시간을 들여서 공부하고 싶진 않다.

개발자 영어는 거창한 게 아니다. 에러 메시지 보고 당황하지 않고, 공식 문서 링크 받았을 때 뒤로 가기 안 누르는 정도면 충분하다고 생각한다. 나머지는 시간이 해결해준다.