개발자가 영어 공부를
꼭 해야 하는 이유
막연하게 알고 있던 걸 직접 부딪히고 나서야 진짜로 깨달았다
영어가 필요없을 줄 알았다
솔직히 말하면, 개발자 되기 전에 영어를 크게 신경 쓰지 않았다. 코딩은 논리의 언어라고 생각했고, 한국어로 된 자료도 충분하다고 봤다. 유튜브 한글 강의, 국내 블로그, 번역된 책들 — 배울 게 차고 넘쳤으니까. 영어는 토익 점수나 해외 취업을 위한 거지, 국내에서 프론트엔드 개발하는 나한테는 굳이 필요 없을 것 같았다.
그 생각이 처음으로 흔들린 건 입사한 지 두 달이 안 됐을 때였다.
에러 메시지 하나에서 시작됐다
Next.js 13에서 앱 라우터를 처음 쓰던 시기였다. hydration mismatch 에러가 반복해서 터졌다. 한국어 블로그를 몇 개 찾아봤는데 다들 이론 설명뿐이었고, 내 케이스랑 딱 맞는 해결책이 없었다.
결국 Next.js 공식 GitHub Issues로 갔다. 비슷한 문제를 겪은 사람이 있었고, 스레드가 꽤 길었다. 그런데 읽다보니 절반쯤에서 멈춰버렸다. 기술 단어는 알겠는데, 뉘앙스가 안 잡혔다. "this doesn't reproduce consistently" 같은 문장이 뭘 말하는지는 알겠는데, 그 위아래 맥락을 연결해서 흐름을 따라가는 게 안 됐다.
Error: Hydration failed because the initial UI does not match what was rendered on the server.
─────────────────────────────────────────────
@vercel-bot: This seems to be related to #48 and the fix should land in 13.4.2
@user_a: Still seeing this with suppressHydrationWarning, any workaround?
@user_b: The root cause is that the server/client tree diverges when you conditionally render based on window...
@maintainer: We're aware of this edge case. The issue is that useLayoutEffect fires after paint on the client but...
→ 이 다음 내용을 이해하지 못한 채 그냥 창을 닫았다.
결국 구글 번역기를 돌렸다. 번역 자체는 됐다. 그런데 기술 문맥이 섞인 긴 문단을 번역기로 읽으면 어색한 부분이 생기고, 그게 이해를 방해했다. 해결하는 데 두 시간 넘게 걸렸다. 나중에 같은 팀 선배한테 물어봤더니 5분 만에 설명해줬다. 선배는 이미 그 스레드를 읽고 흐름을 알고 있었다.
영어를 못 읽어서 문제를 못 푼 게 아니었다. 영어를 읽는 데 에너지를 너무 많이 써서, 정작 기술적 판단을 내릴 여유가 없었던 것이다. 속도와 집중력의 문제였다.
공식 문서가 가장 정확하다는 걸 뒤늦게 알았다
Prisma로 데이터베이스 쿼리를 짜던 중에, 누군가 번역한 비공식 한국어 문서를 참고했다. 당시 Prisma 버전은 5.x였는데, 그 번역본은 4.x 기준이었다. 그걸 몰랐다. findUnique 동작 방식이 달라진 부분이 있었는데, 번역본에는 그 내용이 없었다.
결과적으로 특정 조건에서 null을 반환해야 하는 쿼리가 에러를 던지는 버그가 배포 후에 발견됐다. 원인을 찾는 데만 반나절이 걸렸다. 공식 문서에는 버전별 변경 사항이 명확하게 적혀 있었다. 영어로.
작성 시점이 불명확하고 버전 정보가 빠진 경우가 많다. 커뮤니티 번역은 최신 변경사항이 반영되지 않을 수 있다. 오역이 섞여 있어도 알기 어렵다.
버전별 변경 이력이 명확하다. 예제 코드가 항상 최신이다. deprecated 경고와 마이그레이션 가이드가 즉시 반영된다.
그 이후로 공식 문서는 반드시 원문을 본다. 처음엔 느렸다. 익숙하지 않은 표현이 나오면 멈추게 되고, 페이지 하나 읽는 데 한참 걸렸다. 그런데 3개월쯤 지나니 체감 속도가 달라졌다. 기술 문서에 쓰이는 단어와 문형이 생각보다 반복적이었다. 한번 익히면 계속 나온다.
Stack Overflow는 영어 읽기 훈련장이었다
TypeScript에서 제네릭 타입 추론 문제로 막혔을 때였다. Stack Overflow에서 비슷한 질문을 찾았고, 채택된 답변이 있었다. 코드는 복사해서 붙여넣으니 동작했다. 그런데 왜 동작하는지 설명하는 부분을 제대로 이해하지 못했다.
그냥 넘어갔다. 한 달 뒤 비슷한 상황이 왔을 때 또 막혔다. 또 검색했다. 이게 반복됐다. 코드는 빌려쓰는데 개념이 안 쌓이는 패턴. 나중에 그 Stack Overflow 답변을 제대로 읽고 나서야 패턴이 잡혔다.
// "The reason this works is that TypeScript narrows the type
// within the conditional branch, so the inferred type of T
// becomes more specific based on the discriminant property."
type Result<T> =
T extends string
? "string type"
: "other type";
// 이 한 문단을 제대로 읽었을 때 conditional type 개념이 잡혔다.
그때부터 Stack Overflow 답변을 코드만 보지 않고 설명 전체를 읽는 습관을 들였다. 느렸다. 모르는 단어도 나왔다. 그런데 이게 실질적인 영어 실력 향상으로 이어졌다. 기술 영어는 결국 반복 노출이 답이었다.
영어가 안 되면 정보의 속도가 달라진다
새 프레임워크나 라이브러리가 나오면, 영어 원문 블로그나 릴리즈 노트가 먼저 뜬다. 한국어 정리 글이 나오기까지는 빠르면 일주일, 길면 한 달 이상 걸린다. React 19가 나왔을 때, Server Actions가 stable로 들어왔을 때, Tailwind v4 베타가 공개됐을 때 — 다 영어 자료가 먼저였다.
평소엔 이 격차가 크게 느껴지지 않는다. 그런데 새 기술을 팀에 제안하거나, 트렌드를 빠르게 파악해야 하거나, 면접에서 최근 동향을 물어볼 때 — 그 1~2주 차이가 꽤 크게 느껴졌다.
한국어 자료를 기다리는 동안, 영어를 읽는 개발자는 이미 써보고 의견을 내고 있다. 정보를 소비하는 속도가 다르면, 결국 성장 속도도 달라진다.
예상 못 했던 영역 — 오픈소스 기여
사용하던 오픈소스 라이브러리에서 버그를 발견했다. 재현 코드도 만들었고, 원인도 파악했다. 그런데 Issue를 어떻게 써야 할지 막막했다. "이 버그 있어요, 고쳐주세요" 수준의 영어를 쓰면 무시당할 것 같았고, 격식 있게 쓰자니 어떤 표현이 맞는지 몰랐다.
결국 비슷한 이슈들을 20개쯤 읽고 패턴을 파악한 다음 썼다. 재현 환경, 재현 단계, 예상 동작, 실제 동작, 재현 코드 — 이 구조가 표준이었다. 처음 올린 이슈는 메인테이너가 하루 만에 확인했고, 다음 릴리즈에 픽스가 들어갔다.
GitHub에서 영어로 의견을 남기는 게 두렵지 않아졌다. 댓글, 이슈, PR description — 전부 쓸 수 있게 됐다. 영어 쓰기가 영어 읽기보다 훨씬 느리게 늘었지만, 꾸준히 하다 보니 패턴이 잡혔다. 기술 영어는 표현이 반복된다.
내가 실제로 영어 실력을 키운 방법
학원을 다니거나 토익을 다시 준비한 게 아니었다. 개발 일을 하면서 자연스럽게 쌓인 것들이다. 돌아보면 이 세 가지가 가장 효과적이었다.
영어를 잘해야 한다는 말이 아니다
지금 내 영어 실력이 뛰어난 게 아니다. 말하기는 여전히 버벅거리고, 원어민과 실시간으로 대화하면 많이 놓친다. 그런데 기술 문서를 읽고, 에러 스레드를 따라가고, 공식 채널에서 업데이트를 파악하는 것 — 이 정도는 된다. 그리고 그게 개발자한테 당장 필요한 영어다.
유창하게 말하는 게 목표가 아니어도 된다. 읽는 속도를 높이는 것, 문서 원문에 겁먹지 않는 것, 에러 메시지를 번역 없이 이해하는 것. 이 정도만 돼도 개발자로서 활용할 수 있는 정보의 양이 완전히 달라진다.
오늘 쓰고 있는 라이브러리 공식 문서 한 페이지를 번역 없이 읽어보는 것부터 시작하면 된다. 전부 이해 안 해도 된다. 그냥 원문에 노출되는 것, 그게 시작이다. 6개월 뒤 그 차이가 생각보다 크다.
영어는 개발자한테 필수 기술이라고 말하면 뻔하게 들린다. 그런데 직접 에러 스레드를 못 따라가고, 번역본 때문에 버그를 만들고, 공식 발표를 한 달 늦게 알고 나서야 비로소 실감했다. 뻔한 말이 맞는 말이기도 하다. 늦게 시작하는 것보다 지금 시작하는 게 낫다.
💬 개발하면서 영어 때문에 막혔던 경험 있으신가요?
에러 메시지를 이해 못 했던 순간, 공식 문서가 막막했던 경험, 혹은 영어를 키워서 달라진 것들 — 어떤 이야기든 댓글로 나눠주세요. 비슷한 상황에 있는 분들한테 분명히 도움이 됩니다.
'개발자 > 성장 학습' 카테고리의 다른 글
| 유료 강의 vs 무료 강의, 뭐가 더 도움됐나 (0) | 2026.07.07 |
|---|---|
| 개발 서적 10권 읽고 나서 느낀 점 (0) | 2026.06.30 |
| 1년간 기술 블로그가 내게 한 것, 조회수 34에서 68,000으로 (0) | 2026.06.23 |
| 사이드 프로젝트가 내 개발자 커리어를 바꾼 이야기 (1) | 2026.06.16 |
| 개발자 1년차와 3년차, 달라진 것들 — 솔직하게 써봤습니다 (0) | 2026.06.09 |
