기술 면접 영어 어휘 80개: FAANG 오퍼를 만드는 단어들

---

TL;DR: 알아야 할 3가지

• 영어 기술 면접은 이중 도전입니다: CS 지식을 입증해야 하면서 동시에 제2언어로 정밀하게 표현해야 합니다. 대부분의 비원어민이 개념이 아니라 의사소통에서 점수를 잃습니다.
• 4개 카테고리 80단어가 실제로 필요한 어휘를 커버합니다: 알고리즘, 시스템 설계, 행동 면접, 직업 영어 연결구.
• STAR 방법(Situation, Task, Action, Result)이 모든 행동 질문의 구조적 척추입니다. 각 구성 요소의 어휘를 아는 건 양보 불가입니다.

---

왜 기술 면접 어휘가 숨은 차별점인가

LeetCode 문제를 풀 수 있습니다. 최적 시간 복잡도를 압니다. 실제 회사에서 프로덕션 코드를 출시했습니다. 그러나 면접관이 "walk me through your approach"라고 말하면 머릿속이 하얘집니다. 답을 몰라서가 아니라, 그것을 말할 영어를 모르기 때문입니다.

드문 상황이 아닙니다. FAANG과 최상위 스타트업 면접에서 비원어민에게 일반적입니다.

경쟁이 치열한 엔지니어링 채용에서 기술 기준은 차별점이 아니라 필터입니다. 모든 후보자가 LeetCode 미디엄 문제를 풀 수 있을 때, 의사소통 품질이 오퍼와 거절을 가릅니다. Google, Meta, Amazon, Microsoft의 면접관들은 명시적으로 사고를 얼마나 명확히 표현하는지를 평가합니다. 트레이드오프를 설명하고, 시스템 제약을 묘사하고, 행동 사례를 정밀하게 프레임하는 능력입니다.

세계 인재 풀에서 기술적으로 가장 숙련된 후보자에 속하는 한국, 중국, 일본 엔지니어들에게 이 의사소통 격차는 불균형하게 큰 비용을 부과합니다. 고압적 구두 평가에서 비원어민 성과 연구는 일관되게 어휘 격차—문법 오류가 아니라—가 무능력으로 인식되는 주된 원인이라고 보여줍니다. 무엇을 의미하는지 압니다. 그저 그 순간 정확한 단어가 없는 것뿐입니다.

이 도전에는 네 차원이 있습니다.

첫째, 기술 어휘는 추상적입니다. algorithm, complexity, bottleneck, trade-off—이 단어들은 많은 동아시아 언어에 직접 동등 표현이 없습니다. 번역할 수 없습니다. 영어 용어에 매핑된 개념으로 외워야 합니다.

둘째, 행동 어휘는 문화적입니다. ownership, ship it, rubber duck debugging, retrospective 같은 단어는 문화 특화입니다. 실리콘밸리 엔지니어링 문화에서 온 함의를 담고 있으며, 이는 직역에 존재하지 않습니다.

셋째, 정밀성이 유창함보다 중요합니다. 면접관은 원어민처럼 들리길 요구하지 않습니다. 정밀하길 원합니다. "This solution is O(n log n) which is better than the naive O(n²) approach, but the trade-off is increased space complexity"는 지적 능력을 전달합니다. 모호한 영어는 정반대입니다.

넷째, 압박 속 의사소통은 저하됩니다. 불안은 어휘 접근을 좁힙니다. 절반쯤 아는 단어가 긴장하면 가장 먼저 사라집니다. 해법은 긴장을 푸는 게 아니라, 어휘를 너무 철저히 자동화해서 압박 속에서도 사용 가능하게 만드는 것입니다.

이 가이드는 면접 맥락별로 정리된 80단어를 정의와 맞춤 예문과 함께 드립니다. 또한 면접관에게 명확히 사고함을 알려주는 구조 프레임워크(STAR, 시스템 설계 언어, 직업 연결구)를 드립니다.

---

섹션 1: 4개 카테고리의 기술 면접 단어 80개

각 항목에는 세 구성 요소가 있습니다. 단어나 구, 면접 특화 정의, 그리고 중급 수준 맞춤 예문—교과서가 아니라 실제 면접에서 쓸 종류의 문장.

카테고리 A: 자료구조 & 알고리즘 어휘

모든 코딩 면접에서 쓸 20단어입니다. 솔루션이 무엇을 하는지, 어떻게 수행하는지, 왜 그 선택을 했는지 묘사합니다.

단어 / 구	면접 정의	예문
algorithm	문제 해결을 위한 단계별 절차	"My algorithm processes each node once, so it runs in linear time."
complexity	입력 크기 증가에 따라 자원 사용이 어떻게 자라는지 측정	"The complexity of this approach improves from quadratic to linearithmic with a better data structure."
time complexity	알고리즘 실행 시간이 입력 크기에 따라 어떻게 확장되는지	"The time complexity of binary search is O(log n), which makes it efficient for large datasets."
space complexity	입력이 커짐에 따라 알고리즘이 사용하는 추가 메모리 양	"By reusing the input array instead of allocating a new one, I reduced the space complexity to O(1)."
optimization	솔루션의 효율성이나 정확성을 향상하는 과정	"The first step in my optimization was to eliminate redundant computations inside the inner loop."
iterate	보통 루프로 과정을 반복 적용하다	"I iterate through the array once, keeping track of the maximum value seen so far."
recursion	함수가 같은 문제의 더 작은 버전을 풀기 위해 자기를 호출하는 기법	"Recursion is natural here because the tree structure is self-similar at every level."
trade-off	한 가지를 향상하면 다른 게 나빠지는 상황	"The trade-off between time and space complexity is the central design decision in this problem."
edge case	예상 값의 극단 경계의 입력이나 조건	"I should handle the edge case where the input array is empty before entering the main logic."
bottleneck	전체 성능을 제한하는 시스템 부분	"Profiling revealed that the database query was the bottleneck, not the sorting algorithm."
latency	명령 후 데이터 전송 시작 전 지연	"Adding a cache reduces latency for repeated requests because the data no longer needs to be recomputed."
throughput	시간 단위당 완료된 작업량	"To increase throughput, we can process requests in parallel instead of sequentially."
scalability	성능 저하 없이 증가된 부하를 처리하는 시스템 능력	"The design lacks scalability because every new user doubles the number of database writes."
refactor	외부 행동을 바꾸지 않고 기존 코드를 재구조화	"I would refactor this into a helper function to make the logic reusable and easier to test."
modular	독립적이고 교체 가능한 구성 요소로 설계된	"Keeping the code modular means we can swap out the sorting function later without touching the rest."
abstraction	단순한 인터페이스 뒤에 구현 디테일을 숨기는 원칙	"Using a stack as an abstraction here means the calling code doesn't need to know how the data is stored internally."
encapsulation	데이터와 그것을 다루는 함수를 묶어 내부 상태를 숨김	"Encapsulation keeps the class's internal state safe from external modification."
debugging	코드의 오류를 식별하고 고치는 과정	"During debugging, I added logging statements at each step to trace where the value was going wrong."
iteration	루프의 한 번 완전 통과 또는 반복 과정의 한 사이클	"Each iteration of the outer loop processes one row of the matrix."
constraint	유효 솔루션 공간을 형성하는 입력, 시간, 메모리의 제한	"Given the constraint that the array is sorted, we can rule out any O(n²) approach."

---

카테고리 B: 시스템 설계 어휘

시스템 설계 면접은 규모로 사고할 수 있는지 시험합니다. 이 20단어가 분산 시스템의 어휘이며, 면접관이 "design a URL shortener"나 "how would you build Twitter"라고 물을 때 기대하는 언어입니다.

단어 / 구	면접 정의	예문
architecture	시스템의 고수준 구조와 구성 요소의 상호작용	"Before diving into components, I want to describe the overall architecture and then zoom into each layer."
microservices	작고 독립적으로 배포 가능한 서비스 모음으로 애플리케이션을 만드는 설계 접근	"Migrating from a monolith to microservices allowed each team to deploy their service independently."
monolith	모든 구성 요소가 긴밀히 결합된 단일 통합 애플리케이션	"Starting as a monolith makes sense here — we can extract services later once the domain is better understood."
distributed system	구성 요소가 네트워크를 통해 통신하는 여러 컴퓨터에서 실행되는 시스템	"In a distributed system, we have to assume that any node can fail at any time."
load balancing	어떤 한 서버도 압도되지 않도록 여러 서버에 들어오는 요청을 분산	"Load balancing across three server instances ensures no single server becomes a bottleneck."
caching	검색 시간을 줄이기 위해 자주 접근하는 데이터를 빠른 메모리에 저장	"Caching the top 1% of URLs would handle the vast majority of read traffic without hitting the database."
database sharding	데이터베이스를 여러 머신에 걸쳐 분산된 더 작고 빠르고 다룰 만한 조각으로 분할	"With 10 billion rows, database sharding by user ID would keep each shard's size manageable."
redundancy	신뢰성과 가용성을 늘리기 위한 구성 요소 복제	"Adding a secondary replica provides redundancy — if the primary fails, traffic fails over automatically."
fault tolerance	일부 구성 요소가 실패해도 시스템이 정확히 작동을 계속하는 능력	"Fault tolerance at this layer means replicating the message queue across three availability zones."
consistency	분산 시스템의 모든 노드가 같은 시점에 같은 데이터를 보는 보장	"There's a fundamental tension between consistency and availability in a distributed database."
availability	시스템이 작동하고 접근 가능한 시간 비율	"The design targets 99.9% availability, which allows for less than 9 hours of downtime per year."
partitioning	데이터나 기능을 여러 노드나 시스템에 걸쳐 분할	"Horizontal partitioning by region reduces cross-region latency for most users."
API gateway	모든 클라이언트 요청의 단일 진입점 역할을 하며 적절한 서비스로 라우팅하는 서버	"The API gateway handles authentication and rate limiting before requests reach any internal service."
rate limiting	클라이언트가 주어진 시간 창에서 만들 수 있는 요청 수 제어	"Rate limiting at 1,000 requests per minute per user prevents a single client from overwhelming the system."
message queue	생산자와 소비자 사이 메시지를 저장하는 버퍼, 둘을 분리	"Using a message queue means the notification service can fall behind without affecting the core transaction flow."
pub/sub	발행자가 토픽에 메시지를 보내고 구독자가 받는 메시징 패턴	"The pub/sub model here means adding a new consumer — say, an analytics service — requires zero changes to the publisher."
CDN	Content Delivery Network — 정적 콘텐츠를 사용자에게 더 가까이 전달하는 지리적으로 분산된 서버 네트워크	"Serving static assets through a CDN reduces page load time from 800ms to 90ms for users in Asia."
horizontal scaling	증가된 부하를 처리하기 위해 더 많은 머신 추가	"Horizontal scaling is preferable here because the workload is stateless and easy to distribute."
vertical scaling	단일 머신의 용량 증가 (더 많은 CPU, RAM, 저장소)	"Vertical scaling has a ceiling — at some point you can't buy a bigger server, and the cost grows non-linearly."
technical debt	지금 더 빠르고 쉬운 솔루션을 선택해 나중에 더 많은 작업으로 고쳐야 할 비용	"The current implementation has significant technical debt — we took shortcuts to hit the launch deadline that we'll need to pay back."

---

카테고리 C: 행동 면접 어휘

행동 질문("Tell me about a time you...")은 부드러운 질문이 아닙니다. 판단, 협업, 임팩트에 대한 구조화된 평가입니다. 이 20단어가 그 평가의 어휘입니다.

단어 / 구	면접 정의	예문
initiative	시키지 않아도 독립적으로 행동, 무엇이 필요한지 예상	"I took the initiative to write the post-mortem document before the team lead asked, which helped us identify the root cause faster."
accountability	실패 포함 자기 행동과 결과에 대한 책임을 지기	"When the deployment caused a 30-minute outage, I owned the accountability — I wrote the incident report and presented it to the team."
stakeholder	프로젝트 결과에 이해관계가 있거나 영향받는 모든 사람	"Aligning with stakeholders early meant we avoided a three-week rework cycle when requirements changed."
cross-functional	다른 부서나 분야의 사람·팀이 관련된	"I led a cross-functional effort between engineering, product, and legal to ship the data privacy feature on time."
ownership	공식 역할을 넘어 프로젝트나 영역을 자기 개인 책임으로 다루는 마인드셋	"Ownership in this context meant I stayed through the incident until the root cause was resolved, even though it wasn't technically my service."
retrospective	잘된 것과 개선할 것을 검토하기 위해 프로젝트나 스프린트 후 열리는 구조화된 회의	"After the launch failure, we ran a retrospective and identified three process gaps we've since addressed."
iterate (애자일)	먼저 작동하는 버전을 빨리 출시한 후 피드백 기반으로 반복 사이클로 향상	"We chose to iterate on a minimal version first rather than spend six months building the complete solution."
ship	사용자에게 기능이나 제품을 출시	"The goal of that sprint was to ship a working prototype that internal users could test before the end of Q3."
feedback loop	결과 정보를 수집해 미래 행동 향상에 사용하는 메커니즘	"We added user analytics to create a tighter feedback loop — we could see within 48 hours whether the change was working."
scope creep	프로젝트 요구사항이 원래 경계를 넘어 점진적으로 확장	"Scope creep was the primary risk — we had to make a deliberate decision to defer three features to the next release."
align	다른 당사자들을 공유된 이해나 방향으로 가져오기	"Before writing a single line of code, I aligned with the product manager on what success looked like."
escalate	현재 수준에서 해결할 수 없을 때 더 높은 권한이나 더 시니어 팀원에게 문제 제기	"When I couldn't get a decision on the API contract, I escalated to my manager, who resolved it with the other team lead in one meeting."
prioritize	상대적 중요도나 긴급성에 따라 과제나 목표 순서 정하기	"Given the two-week deadline, I had to prioritize the features by user impact and deprioritize anything that wasn't on the critical path."
impact	사용자, 비즈니스, 기술 결과에 대한 작업의 측정 가능한 효과	"The impact of the caching layer was 60% reduction in database load, which directly lowered our infrastructure costs."
influence	특히 공식 권한 없이 다른 사람의 방향, 행동, 의견을 바꾸기	"I influenced the team's decision to adopt the new framework by writing a comparative analysis and presenting it at the tech review."
mentor	조언, 피드백, 지식 공유를 통해 더 주니어 팀원을 안내하고 발전시키기	"I mentored two junior engineers during my time there, pair-programming with them weekly and reviewing their design documents."
collaborate	공유 목표를 향해 다른 사람들과 공동 작업, 능동적으로 기여하고 조정	"The feature required me to collaborate closely with the mobile team, which meant daily syncs and shared documentation."
deliver	합의된 범위, 품질, 일정 내 작동하는 결과를 완료하고 인계	"Despite the ambiguous requirements, I delivered a working API within the sprint timeline by making early, explicit assumptions and validating them."
pivot	새 정보나 결과 기반으로 접근에 의미 있는 변화	"Three weeks in, user testing showed our initial approach was wrong. We had to pivot quickly, which meant cutting two planned features."
drive	능동적 노력과 리더십으로 프로젝트나 목표를 앞으로 밀기	"I drove the migration project from start to finish — coordinating across four teams and delivering it two weeks ahead of schedule."

---

카테고리 D: 면접용 일반 직업 영어

이건 기술 단어가 아닙니다. 면접 의사소통의 결합 조직입니다. 명확히 사고하고, 진술을 적절히 한정하고, 면접관 질문에 몰입함을 보여주는 표현들.

비원어민은 종종 기술 어휘는 알지만 이 직업 연결구가 부족합니다. 그것 없이는 답이 끊기고, 과도하게 자신만만하거나, 회피적으로 들립니다. 그것이 있으면 답이 구조화되고 시니어로 들립니다.

표현	기능	면접 예시
elaborate	더 자세히 추가할 거라는 신호	"Could you elaborate on the scale requirements? That would change my design significantly."
clarify	진행 전 모호함 확인이나 해결	"Before I start, I want to clarify — are we optimizing for read performance or write performance?"
rephrase	이해 확인을 위해 질문이나 아이디어 재진술	"Let me rephrase that constraint to make sure I have it right: we have a 100ms SLA for 99th percentile response times?"
walk through	사고 과정을 단계별로 안내	"Let me walk through my reasoning before I write any code."
break down	복잡한 문제를 더 작은 부분으로 나눔	"I'll break down the problem into three components: data modeling, API design, and caching strategy."
in terms of	논의하는 차원 명시	"In terms of time complexity, this is optimal. The question is whether the space trade-off is acceptable."
to elaborate	더 자세한 설명 도입	"To elaborate on the latency concern — the bottleneck is the synchronous call to the third-party API, which we can't control."
to circle back	앞에서 언급한 점으로 돌아가기	"I want to circle back to the edge case I mentioned — it becomes important once we consider the concurrent write scenario."
approach	제안하는 전체 방법이나 전략	"My approach would be to start with a simple solution, establish correctness, and then optimize."
considerations	결정에 영향을 줘야 할 요소들	"The main considerations here are consistency requirements, expected read/write ratio, and team familiarity with the technology."
trade-offs	다른 옵션의 비용과 혜택	"There are real trade-offs between these two designs, and the right choice depends on the read/write ratio."
in my experience	개인 증거로 진술 한정	"In my experience, starting with a monolith and extracting services later is less risky than starting distributed."
I'd argue that	방어할 준비가 된 입장 도입	"I'd argue that the additional complexity of microservices isn't justified at this scale."
one way to think about it	정신 모델이나 비유 제공	"One way to think about this is that the cache is a buffer between the fast and slow parts of the system."
that said	반대 도입 전 이전 점 인정	"That said, there are scenarios where the simpler approach would fail — specifically, high-concurrency writes."
to be specific	구체적 예를 줄 거라는 신호	"To be specific, I reduced query time from 1.2 seconds to 40 milliseconds by adding a composite index."
building on that	이미 한 점 확장	"Building on that — if we add a read replica, we can handle the read scaling without changing the write path at all."
to your point	면접관이 한 말을 인정하고 몰입	"To your point about consistency — you're right that eventual consistency won't work here given the financial nature of the data."
the crux of the matter	중심이나 가장 중요한 점 식별	"The crux of the matter is whether we prioritize write throughput or read latency — everything else follows from that decision."
it depends on	답이 맥락에 따라 다름을 인식	"It depends on the access pattern. If reads far outnumber writes, a cache makes sense. If writes dominate, it adds complexity without benefit."

---

섹션 2: STAR 방법 어휘 가이드

STAR 방법은 행동 면접에서 가장 중요한 단일 프레임워크입니다. 모든 주요 테크 회사(Google, Amazon, Meta, Microsoft, Apple)가 명시적으로 역량 기반 행동 평가를 사용하며, STAR가 기대되는 응답 구조입니다.

STAR가 의미하는 것:

• Situation — 맥락과 배경. 어디에 있었고, 무슨 일이 일어났나?
• Task — 자기의 구체적 책임. 무엇을 할 거라고 기대됐나?
• Action — 실제로 한 것. 취한 구체적 단계.
• Result — 측정 가능한 결과. 행동 때문에 무슨 일이 일어났나?

면접관이 원하는 비율은 대략 10% / 15% / 50% / 25%입니다. 대부분의 후보자가 Situation에 과투자하고 Action과 Result에 미달합니다. 어휘가 가장 중요한 곳이 거기입니다.

STAR 시작 표현

Situation 시작 (장면을 빨리 설정):

1. "This happened during my time at [company], when our team was responsible for..."
2. "The context was a critical migration project with a hard deadline of..."
3. "We were in the middle of a product launch when..."
4. "Shortly after I joined the team, we encountered a situation where..."
5. "During Q3 of last year, our service started experiencing..."

Task 시작 (오너십 진술):

1. "My specific responsibility was to..."
2. "I was accountable for delivering..."
3. "The task fell to me because..."
4. "I owned the end-to-end design and implementation of..."
5. "The team needed someone to drive the..."

Action 시작 (이니셔티브와 사고 보임):

1. "The first thing I did was..."
2. "I started by breaking the problem into three components..."
3. "My approach was to first understand the root cause before proposing any solution..."
4. "I decided to escalate early, because..."
5. "Rather than accepting the existing approach, I proposed an alternative by..."

Result 시작 (숫자로 시작):

1. "The outcome was a [X]% improvement in..."
2. "As a direct result, we reduced [metric] from X to Y..."
3. "The feature shipped on time and within budget, and subsequently..."
4. "We received direct feedback from the engineering director that..."
5. "The impact was significant: specifically, [quantified outcome]..."

전체 STAR 예시 답변

질문: "Tell me about a time you dealt with a difficult technical problem."

Situation: During my second year at the company, our main product API started experiencing intermittent 500 errors that only appeared under high load — specifically during peak traffic hours. The errors were non-deterministic and difficult to reproduce in staging.

Task: I was assigned as the engineer responsible for identifying the root cause and resolving the issue. The constraint was that we had a major customer demo in eight days, and the instability was unacceptable for that event.

Action: My approach was methodical: I started by analyzing the error logs to establish a pattern before touching any code. I noticed the errors correlated with specific database query patterns, which suggested a bottleneck rather than a code bug. I added granular logging to iterate through the call stack and isolate the problem. To be specific, I found that a particular ORM query was performing a full table scan on a 50-million-row table because a composite index was missing. I wrote a database migration, tested it in a replica environment to verify correctness, and deployed it with a feature flag so we could roll back instantly if anything went wrong. I also circled back to review the other five highest-traffic queries to check for the same issue — I found two more.

Result: The fix reduced the error rate from approximately 0.8% to near zero within 24 hours of deployment. The impact on p99 response time was a reduction from 1.4 seconds to 210 milliseconds. The customer demo proceeded without any issues. I subsequently wrote a documentation guide for the team on identifying and preventing this class of query performance issue, which we've used in three code reviews since.

작동하는 어휘를 보세요. constraint, approach, bottleneck, iterate, to be specific, circle back, impact. 장식이 아닙니다. 구조화되고 직업적인 엔지니어링 용어로 사고함을 면접관에게 신호하는 것입니다.

---

섹션 3: 시스템 설계 면접 언어

시스템 설계 면접은 단일 정답이 없습니다. 면접관은 시니어 엔지니어처럼 사고하는지 평가합니다. 모호함을 구조화하고, 트레이드오프를 추론하고, 결정을 명확히 전달할 수 있나요?

아래 어휘 패턴이 시니어 엔지니어링 후보자들이 들리는 모습입니다. 스크립트를 외우려는 게 아니라 그것이 대표하는 사고 패턴을 내면화하기 위해 학습하세요.

답변 구조화 방법

시스템 설계 면접의 첫 2분이 나머지의 궤적을 결정합니다. 강한 후보자는 일관된 구조를 사용합니다.

1. 요구사항을 먼저 명확히 하기. "Before I start designing, I want to clarify a few things. What's the expected scale? Are we optimizing for reads or writes? What's the acceptable latency for the critical path?"

2. 접근을 명시적으로 진술. "My approach will be: define the data model, design the API, then talk through the main components and their interactions. I'll flag trade-offs as I go."

3. 결정을 향해 추진. "Given the constraints you've described, I'd lean toward a SQL database over NoSQL here, because the relational structure of the data is a better fit. That said, if write volume exceeds X, we'd want to revisit that decision."

시니어 사고를 보여주는 신호 표현 10개

이 표현들이 아키텍처적 성숙을 신호합니다. 강한 채용 추천을 받는 후보자들의 답변에 등장합니다.

신호 표현	전달하는 것
"The first question I'd ask is..."	설계 전에 요구사항을 모음
"The trade-off between X and Y is..."	경쟁 우려에 대해 추론
"A key consideration here is..."	중요한 것을 우선
"I'd start simple and add complexity only when needed..."	조기 최적화를 피함
"This assumes [assumption] — if that changes, the design would change significantly..."	가정을 명시적으로 만듦
"The bottleneck in this design is likely..."	실패 지점을 예상
"One failure mode we need to handle is..."	회복력에 대해 사고
"If I were to scale this to 10x traffic..."	현재 범위를 잃지 않고 미리 사고
"I would monitor this with..."	운영과 관찰 가능성에 대해 사고
"The simplest thing that could work is... and here's when we'd outgrow it..."	시스템 진화를 이해

비원어민의 흔한 실수

비원어민 면접에 자주 등장하고 면접관에게 일관되게 부정적 피드백을 끌어내는 패턴입니다.

실수 1: 명확화 없이 솔루션으로 점프.

• 일어나는 일: 요구사항이 정해지기 전에 후보자가 특정 기술을 묘사하기 시작.
• 면접관 생각: "그들이 명확화 질문을 안 한다. 실제 엔지니어링 환경에서 위험이다."
• 수정: "Before I propose a design, can I ask a few questions to make sure I understand the constraints?"

실수 2: 결정 대신 묘사.

• 일어나는 일: "We could use MySQL, or we could use Cassandra. Both have advantages. MySQL is relational. Cassandra is distributed."
• 면접관 생각: "사실을 암송할 수 있지만 결정을 못 한다."
• 수정: "Given the read-heavy workload and structured data, I'd go with PostgreSQL. Here's why..."

실수 3: 모호한 긍정 한정사 사용.

• 일어나는 일: 후보자가 "this is very efficient"나 "this approach is much better" 같은 말.
• 면접관 생각: "어떤 척도로 나은가? 얼마나 나은가?"
• 수정: 구체적이 되세요. "This reduces time complexity from O(n²) to O(n log n), which matters at 10 million records." 가능할 때마다 정량화.

실수 4: L1 문장 구조에서 직역.

• 중국어 예: "This problem, I think can be solved by using..." → "I think this problem can be solved by using..."
• 일본어 예: 기술 맥락에서 "I feel that..." 과용 → "My assessment is that..." 또는 "The data suggests..."
• 한국어 예: 영어에서 필수인 곳에서 주어 생략

실수 5: 사고 대신 침묵.

• 일어나는 일: 후보자가 사고하면서 조용해져, 면접관이 막혔는지 궁금해함.
• 수정: 사고를 내레이션. "Let me think about this for a moment... I'm considering whether the consistency requirement here rules out an eventually consistent store..." 막혀 보이는 것과 사려 깊어 보이는 것의 차이입니다.

---

섹션 4: 30일 면접 전 어휘 스프린트

면접 4주 전 이 집중 어휘 스프린트를 돌리세요. 순서가 중요합니다. 먼저 알고리즘, 그다음 시스템 설계, 그다음 행동, 그다음 통합.

1주 — 카테고리 A: 알고리즘 어휘

목표: 코드를 통해 말할 때 자연스럽게 등장하도록 알고리즘 단어 20개 자동화.

일일 연습 (20분):

• 1~2일: 첫 10단어 학습. Rhythm Word에 추가하고 첫 SRS 세션 완료.
• 3~4일: 나머지 10단어 학습. 20단어 모두 SRS 세션 완료.
• 5일: LeetCode Easy나 Medium 문제 하나를 완전히 소리 내어 풀기. 카테고리 A 어휘 최소 5개 사용 강제.
• 6일: 이전에 푼 LeetCode 솔루션 두 개를 가상의 면접관에게 설명. 자기 녹음.
• 7일: Rhythm Word의 SRS 시스템이 약하다고 표시한 카테고리 A 단어 복습. 거기 집중.

1주 체크포인트: 머지 정렬, 이진 검색, 해시 테이블 룩업의 시간·공간 복잡도를 망설이지 않고 명확한 영어로 설명할 수 있나?

2주 — 카테고리 B: 시스템 설계 어휘

목표: 정밀한 어휘로 시스템 설계 선택을 제안, 비교, 정당화할 수 있게 됨.

일일 연습 (25분):

• 8~9일: 첫 10개 시스템 설계 단어 학습. Rhythm Word에 추가.
• 10~11일: 나머지 10개 학습. 20단어 모두 SRS 세션 완료.
• 12일: 한 고전적 시스템 설계 문제(URL shortener, Twitter timeline, rate limiter) 가져와 15분 동안 설계를 통해 말하기. 카테고리 B 단어 최소 8개 사용 강제.
• 13일: 시스템 설계 블로그 글이나 아키텍처 기사 하나 읽기. 맥락에서 만나는 모든 카테고리 B 단어 적기.
• 14일: Rhythm Word에서 표시된 단어 복습. 소리 내어 설계 연습 반복.

2주 체크포인트: 수평 vs. 수직 스케일링의 트레이드오프와 각각을 언제 선택할지 60초 안에 설명할 수 있나?

3주 — 카테고리 C: 행동 어휘

목표: 행동 어휘를 자연스럽게 사용하는 STAR 답변 준비.

일일 연습 (25분):

• 15~16일: 행동 단어 20개 학습. Rhythm Word에 추가.
• 17일: 자기 경험에서 STAR 이야기 세 개 적기. 각 이야기에 행동 단어 최소 3개 사용.
• 18일: 세 이야기를 소리 내어 시간 재며 연습. 각 답이 2~3분.
• 19일: Result 섹션에 집중. 각 이야기의 결과 단락을 구체적 숫자나 측정 가능한 결과를 포함하도록 다시 쓰기.
• 20일: 가장 흔한 행동 질문 다섯 개 답하기 연습:
  • "Tell me about a time you had a conflict with a teammate."
  • "Describe a situation where you had to deliver under a tight deadline."
  • "Tell me about a time you made a significant technical decision."
  • "Give an example of a time you influenced a team without formal authority."
  • "Tell me about a time you failed."
• 21일: Rhythm Word에서 표시된 행동 단어 복습.

3주 체크포인트: 각 3분 미만, 측정 가능한 결과 최소 하나로 별개의 STAR 이야기 세 개를 말할 수 있나?

4주 — 모의 면접 통합

목표: 현실적 면접 압박 속에서 모든 어휘 결합.

• 22~23일: 모의 코딩 면접 두 번. 각각 후 놓치거나 피한 어휘 단어 검토하고 Rhythm Word 복습 큐에 추가.
• 24일: 모의 시스템 설계 면접 한 번 (Pramp, interviewing.io, 친구 같은 서비스 사용). 가능하면 녹음.
• 25일: 녹음 다시 보기 (또는 연습 파트너에게 피드백 요청). 어떤 어휘 격차가 등장했나?
• 26일: 22~25일에 격차로 표시한 모든 단어에 대한 집중 Rhythm Word 세션.
• 27~28일: 모의 면접 두 번 더. 이번에는 카테고리 D 연결 표현(elaborate, walk through, circle back, to your point, it depends on)을 능동적으로 사용. 자연스럽게 느껴져야 함.
• 29일: 휴식. 새 어휘 없음.
• 30일: Rhythm Word에서 가장 약한 10단어 가벼운 복습. 자신감 세션만.

월 체크포인트: 망설이지 않고 모호한 언어로 후퇴하지 않고 이 가이드의 어휘를 사용해 45분 모의 기술 면접(코딩, 시스템 설계, 행동)을 진행할 수 있어야 합니다.

---

FAQ

영어 기술 면접에 어떤 어휘가 필요한가요?

네 영역에 걸친 어휘가 필요합니다. (1) 알고리즘과 자료구조 — complexity, trade-off, edge case, recursion, bottleneck 같은 단어; (2) 시스템 설계 — architecture, scalability, fault tolerance, caching, consistency; (3) 행동 — ownership, accountability, impact, initiative, stakeholder; (4) 직업 연결구 — "walk me through," "to elaborate," "the trade-off between X and Y," "it depends on" 같은 표현. 대부분의 비원어민이 카테고리 전반에 걸쳐 부분적 커버리지를 가집니다. 이 가이드가 80개 모두 드립니다.

영어로 알고리즘을 어떻게 묘사하나요?

이 구조 사용: 알고리즘 진술, 시간·공간 복잡도 묘사, 왜 문제에 적합한지 설명, 그리고 트레이드오프 묘사. 예: "My approach uses a two-pointer technique. The time complexity is O(n) since we traverse the array once, and the space complexity is O(1) since we're not using any additional data structures. The trade-off is that this only works if the input is sorted — which, given the constraints, it is."

면접에서 "walk me through your approach"가 무슨 뜻인가요?

뜻: 코드를 쓰기 전에 사고 과정을 단계별로 설명. 면접관이 추론을 내레이션하는 걸 듣고 싶어 합니다. 문제를 어떻게 분해하는지, 어떤 트레이드오프를 고려하는지, 왜 한 자료구조를 다른 것보다 고르는지. 즉시 코딩을 시작하라는 신호가 아닙니다. 소리 내어 사고하라는 초대입니다. 강한 후보자는 이렇게 답합니다. "Sure. Let me start by clarifying the constraints, then I'll outline my approach before writing any code."

영어 테크 면접에서 어떻게 더 자신감 있게 들릴 수 있나요?

세 가지 구체적 기법: 첫째, 조직된 사고를 신호하는 구조 표현 사용 — "I'll break this into three parts," "the key considerations are X, Y, and Z." 이게 의도적으로 들리게 합니다. 둘째, 모든 걸 정량화 — "I reduced latency from 800ms to 90ms"가 "I improved the performance significantly"보다 훨씬 자신 있게 들립니다. 셋째, 가정을 명시적으로 — "I'm going to assume the input array is sorted; I'll note where that assumption matters." 명시적 가정은 약점이 아니라 인식을 신호합니다.

STAR 방법이 무엇이고 어떤 어휘를 사용하나요?

STAR는 Situation, Task, Action, Result의 약자—행동 면접 질문에 답하는 프레임워크. Situation 어휘: "The context was," "During my time at," "We were in the middle of." Task 어휘: "I was responsible for," "I owned," "My accountability was." Action 어휘: "My approach was to," "I escalated to," "I drove the," "I collaborated with." Result 어휘: "The outcome was a [X]% improvement," "As a direct result," "The impact was." 핵심 비율: 답의 50%를 Action에, 25%를 Result에. 대부분의 후보자가 Situation에 쓰는데, 면접관에게 매우 적은 걸 알려줍니다.

---

마무리

FAANG에서 오퍼를 받는 엔지니어가 항상 가장 어려운 LeetCode 문제를 풀 수 있는 사람들은 아닙니다. 그들은 미디엄 난이도 문제를 명확히 풀고, 사고를 정밀하게 전달하고, 함께 일하기 좋겠다는 자신을 면접관에게 주는 사람들입니다.

비원어민 영어 화자에게 이는 학습 가능한 기술입니다. 재능이 아닙니다. 운이 아닙니다. 이 가이드의 모든 표현은 실제 면접에서 실제 엔지니어가 사용한 것입니다. 어휘는 유한합니다. 프레임워크(STAR, 시스템 설계 구조화, 소리 내어 추론)는 학습 가능합니다.

30일 스프린트는 결정으로 시작합니다. 지금 어떤 어휘 격차가 가장 큰 비용을 부과하고 있나?

기술 면접을 능동적으로 준비하는 엔지니어를 위해, Rhythm Word는 이 가이드의 80단어를 추가하고 정확히 필요한 레지스터—직업적, 기술적, 맥락 풍부—의 맞춤 예문으로 학습할 수 있게 합니다. 앱의 간격 반복 엔진이 이미 아는 단어가 아니라 가장 약한 단어를 복습하도록 보장합니다.

자동화하는 모든 단어가 면접실에서 하나 적은 망설임입니다.

App Store에서 Rhythm Word 다운로드: 무료 다운로드

---

직업 영어 어휘 자료를 더 찾으세요? 또한 보기:

• 비즈니스 영어 어휘: 직장인을 위한 완전 가이드
• 면접용 영어: 채용을 만드는 60단어와 표현
• 능동 회상: 어휘를 박히게 하는 가장 빠른 방법
• 왜 맥락 예문이 어휘 학습의 가장 효율적인 방법인가