"Slack 메시지나 기술 문서 독해는 완벽하게 할 수 있습니다. GitHub에서 PR(Pull Request) 코멘트도 막힘없이 작성할 수 있죠. 하지만 Zoom으로 진행되는 데일리 스탠드업(아침 회의)이나 아키텍처 리뷰 회의만 되면 갑자기 입이 얼어붙어 아무 말도 못 하게 됩니다..."
메가 벤처에서 GAFAM(Google, Amazon, Meta 등)을 비롯한 빅테크 기업으로 이직을 목표로 하거나, 이미 외국계 IT 기업에서 근무하고 있는 비영어권 출신의 우수한 소프트웨어 엔지니어 다수가 이와 같은 '텍스트(비동기) 소통과 구두(동기) 소통 능력의 극심한 괴리'로 어려움을 겪고 있습니다.
코드 품질이나 시스템 설계 능력은 세계 최고 수준임에도 불구하고, '스피킹 순발력'이 부족하다는 이유만으로 합당한 평가를 받지 못하는 것은 매우 안타까운 일입니다.
이 글에서는 외국계 IT 기업에서 L5(시니어 엔지니어) 이상의 승진을 위해 반드시 필요한 애자일 개발 환경에서의 발언 기술, 코드 리뷰 시 '갈등을 피하는 완곡한 표현', 그리고 시스템 디자인 면접 합격 비법을 전문가가 철저히 해설합니다.
1. "텍스트는 완벽, 회의에서는 침묵" 비영어권 엔지니어가 마주하는 장벽과 L5 승진 조건
왜 난해한 기술 문서를 능숙하게 읽고 정확한 코드를 작성하는 엔지니어가 Zoom/Teams 회의에서는 위축되는 것일까요?
많은 국가의 영어 교육이 독해와 문법에 치중되어 있어, 즉각적으로 반응해야 하는 회화 훈련이 절대적으로 부족하기 때문입니다. 그 결과, '완벽한 답변을 머릿속으로 구성한 뒤에 말해야 한다'는 생각에 주저하게 되고, 빠른 속도로 진행되는 대화의 흐름을 놓치게 됩니다.
한편, GAFAM과 같은 빅테크 기업에서는 시니어 엔지니어(L5 이상)로 승진할 때 '회의에서의 구두 소통 능력'을 매우 중요하게 평가합니다. IEEE Spectrum 저널이 "자신의 아이디어를 명확하게 전달할 수 있는 엔지니어는 승진할 가능성이 높다"고 지적했듯이, 빅테크에서는 뛰어난 기술력만으로는 충분하지 않으며, 회의 석상에서 '자신의 의견을 피력하여 영향력을 발휘할 수 있는지'가 평가에 직접적인 영향을 미칩니다. 현대적인 업무 환경에서는 개방형 사무실이나 회의에서의 '가시성(발언량)'이 성공의 척도가 될 수 있으므로, 발언하지 않으면 '너무 조용해서 존재감이 없는 사람'으로 비칠 위험이 있습니다.
2. 애자일・스크럼 개발(스탠드업 미팅) 필수 영어 템플릿
매일 진행되는 스크럼 미팅(데일리 스탠드업)에서는 길게 말할 필요가 없습니다. 전체 회의 시간을 고려하여 '1분 이내'로 간결하고 체계적으로 보고하는 것이 중요합니다. 아래의 세 가지 요소(어제 한 일・오늘 할 일・장애물)에 맞춰 템플릿을 활용해 보세요.
① 어제 한 일 (What I did yesterday)
- "Yesterday, I wrapped up the frontend of the registration page and today I'm going to get started on the backend."
(어제는 등록 페이지의 프론트엔드 작업을 마무리했고, 오늘부터 백엔드 작업을 시작할 예정입니다.) - "Yesterday I fixed the login issue and merged the related PR for team visibility."
(어제는 로그인 문제를 해결했고, 팀원들이 볼 수 있도록 관련 PR을 병합했습니다.)
② 오늘 할 일 (What I will do today)
- "Today I will integrate the payment gateway and write the unit tests for it."
(오늘은 결제 게이트웨이를 통합하고, 관련 유닛 테스트를 작성할 것입니다.) - "I plan to complete the cache implementation and update the documentation."
(캐시 구현을 완료하고 문서를 업데이트할 계획입니다.)
③ 장애물・도움 요청 (Blockers/Help) 무능하게 보이지 않도록, 구체적인 기술 용어를 포함하고 '스스로 시도해 본 해결 방법'과 함께 도움을 요청하는 것이 중요합니다.
- "I'm currently stuck on a database connection issue; could someone with SQL experience advise me?"
(현재 데이터베이스 연결 문제로 막혀 있습니다. SQL 경험이 있는 분이 조언해 주실 수 있을까요?) - "I'm facing a blocker with the API rate limit. I tried optimizing queries but still hit the limit — any suggestions would be appreciated."
(API 호출량 제한(rate limit) 때문에 작업이 중단되었습니다. 쿼리 최적화를 시도했지만 여전히 제한에 걸립니다. 어떤 제안이든 감사히 받겠습니다.)
3. 코드 리뷰(PR)에서 갈등을 피하는 '완곡어법'과 필수 약어
코드 리뷰 시, 비영어권 엔지니어들은 '직설적인 영어 표현이 공격적(Toxic)으로 비치지 않을까'하고 두려워하는 경향이 있습니다. 여기서는 상대방을 존중하면서도 정확하게 문제를 제기하는 '정중한 지적(Polite Pushback)' 기술을 소개합니다.
'You'를 피하고, 중립적이거나 제안하는 형태로 바꾸기
"You should..."나 "I think we should..."와 같은 직접적인 표현 대신, 코드 자체를 주어로 삼거나 질문 형태로 바꾸면 훨씬 부드러운 어조로 전달할 수 있습니다.
- × 직접적인 지적: "I think we should rename X to Y."
- 〇 중립적인 표현으로 바꾸기: "It looks like X could be renamed to Y for clarity." (명확성을 위해 X를 Y로 변경할 수 있을 것 같습니다.)
- 〇 제안 형태로 바꾸기: "How about using camelCase…" (camelCase를 사용하는 것은 어떨까요?)
- 〇 질문 형태로 문제 제기하기: "이 부분은 이렇게 구현된 것 같은데, 혹시 OO 방식이 더 효율적일 수도 있을 것 같습니다. 어떻게 생각하시나요?" 와 같이 상대방의 의견을 구하는 방식으로 전달합니다.
PR(Pull Request) 필수 용어・약어 모음
GitHub의 PR 코멘트에서 자주 사용되는 약어의 정의와 뉘앙스입니다.
약어 | 원문 (Full Meaning) | 뉘앙스・사용 예시 (When to use) |
LGTM | Looks Good To Me | 변경 사항에 문제가 없음을 나타내는 승인 코멘트로, 리뷰 완료 신호로 사용됩니다. |
nit | Nitpick | 치명적이지 않은 사소한 개선 요청이나 세부 지적에 사용됩니다. 예: "NIT: 변수명을 좀 더 명확하게 하면 좋겠습니다." |
WIP | Work In Progress | 작업이 진행 중이며 미완성 상태임을 알려, 심층적인 리뷰는 보류해 달라는 의미의 태그입니다. |
PTAL | Please Take A Look | 특정 리뷰어에게 '시간 될 때 확인해 주세요'라고 요청할 때 사용합니다. |
WIP/Draft | Work In Progress / Draft | 구현이 확정되지 않은 초기 단계에서 아키텍처에 대한 피드백만을 요청할 때 사용합니다. |
4. GAFAM 기술 면접(시스템 디자인 / 행동) 돌파를 위한 영어
빅테크 면접에서는 정답을 말하는 것뿐만 아니라, 자신의 사고 과정을 면접관과 논리적으로 공유하는 능력이 중요합니다.
시스템 디자인 면접(System Design Interview)
시스템 디자인 면접에서는 '왜 그 아키텍처를 선택했는가'에 대한 트레이드오프(trade-off)를 논리적으로 설명하는 표현이 필수적입니다.
- “We prioritized availability over strong consistency, allowing eventual consistency to keep write latency low.”
(쓰기 지연 시간(write latency)을 낮게 유지하기 위해, 강한 일관성(strong consistency)보다 가용성(availability)을 우선시하고 최종적 일관성(eventual consistency)을 허용했습니다.) - “If we required all replicas to sync on each write, write latency would increase significantly.”
(만약 모든 복제본(replica)에 동기식 쓰기를 요구했다면, 쓰기 지연 시간이 현저히 증가했을 것입니다.) - “In this design, we trade [Benefit] for [Drawback].”
(이 설계에서는 [단점]을 감수하는 대신 [장점]을 얻습니다.)
행동 면접(Behavioral Interview)
'과거의 실패 경험'이나 '갈등 해결 방법'에 대한 질문을 받으면, STAR 기법(Situation, Task, Action, Result)에 따라 논리적으로 이야기를 전개해야 합니다. 서두에서는 아래와 같은 템플릿을 사용하여 상황과 과제를 간결하게 설명합니다.
- “In my previous role at [Company], I encountered [Situation] and was responsible for [Task]...”
(이전 [회사명]에서 근무할 때, 저는 [상황]에 직면했고 [과제]를 책임지고 있었습니다...)
결론: 원어민 수준의 유창함보다 '기술 프로토콜'로서의 영어를
우수한 엔지니어일수록 '완벽한 문법과 원어민 같은 발음으로 말해야 한다'는 강박에 사로잡히기 쉽습니다. 하지만 이제는 사고방식을 크게 전환해야 합니다.
영어는 '모국어'처럼 유창하게 구사해야 하는 언어가 아니라, 다양한 국적의 엔지니어들이 소통하기 위한 '기술자 간의 프로토콜(통신 규약)'에 불과합니다. 완벽함보다는 대화 자체가 중요하며, 논리적으로 정확하게 의사를 전달할 수 있다면 사소한 문법적 오류는 용납됩니다. 일상 회화처럼 유창하게 말하려 하기보다, 정해진 템플릿이나 프레임워크를 사용하여 요점을 전달하는 '간결하고 명확한 문장'을 구사하는 데 집중하세요.
"데일리 스탠드업에서 간결하게 말하기 위한 템플릿을 제 업무에 맞게 적용해보고 싶습니다."
"시스템 디자인 면접을 대비해 영어로 모의 면접을 진행하고 싶습니다."
이처럼 실용적인 기술 커뮤니케이션으로서의 영어 실력을 최단 기간에 끌어올리고 싶은 소프트웨어 엔지니어라면, ELT의 개별 상담 및 체험 레슨을 활용해 보시기 바랍니다.
