쉐도잉 연습: FullStack Interview Questions (Junior & Mid) - 영상으로 영어 말하기 배우기
레슨 만드는 중...
1
So first question of today's interview, what is an SQL injection attack?
2
An SQL injection attack.
3
Can I share my screen?
4
Yeah, sure.
5
Go ahead.
6
If that helps.
7
Okay.
8
So SQL injection, it's basically when we have a webpage, right?
9
And we have an input field on that webpage.
10
Let's imagine it that way.
11
And basically the attacker, so this is our application.
12
We have a backend and the attacker is capable of writing SQL code over here.
13
So they do write some SQL.
14
Oh my God, I'm super zooming.
15
So they write some SQL over here
16
and that SQL gets actually executed because we failed to sanitize that input into our database.
17
And they could do certain things like they could probably, for example, change the privileges of their own user.
18
They can read our database.
19
They can drop the database.
20
And this was a very common attack, I think back in the early 2000s.
21
So basically what they would do is I would write here some SQL, like select all from but they need to engineer their queries very well
22
so for example what they would do is they would add they'll try different things
23
and you would start this statement with maybe a semicolon
24
and what that would do is that in the back
25
if in the back end the way the back end developers
26
go their queries was like this like let's say they had
27
a select all from users where user username it's equal to and you would normally do string interpolation
28
with the input that comes from the front end.
29
So you'd put directly the input here.
30
The attacker could actually put this query that they put in into here.
31
And so you'd end up running SQL on the database.
32
And the way to avoid this is to just use, first of all, sanitize all the input.
33
And second of all, use SQL parameters.
34
Basically, they look something like this.
35
But what SQL will do when you send this query over and you provide this dollar sign argument separately, it will not run this as SQL.
36
It was really like the query, the executable part of the query is this one and then provide this as an input and then it won't work.
37
If they provide some SQL here, it's just going to, they will get no results, but it's not going to execute that on our database.
38
Cool.
39
Now we're going to move on with the second question.
40
Can you explain HTTP caching?
41
Right.
42
And also go into advantages and let me know if you ever used it in the past later.
43
Awesome.
44
Sure.
45
So HTTP caching, it's one of my favorites because it's very easy to set up these days.
46
And basically, well, it's always, it's an HTTP mechanism.
47
So it happens between a client and a server.
48
And imagine we have here a CSS file or any other file, an image, a heavy file.
49
We definitely want the users, we could actually make the webpage load faster
50
if users could reuse this resource in the future and not have to download it every time they go to their website.
51
So what happens normally is, let's imagine this is our server.
52
And they will be our client.
53
Yes.
54
And they'll make a first request of an asset.
55
It can be even a REST resource, an HTML file.
56
And so what they would receive in the HTTP headers would be a header called cache control.
57
And there's different values for this header.
58
but one of the most common is to basically specify this is the header that specifies
59
how the client should cache this
60
so basically here they would have something like let me make this bigger perfect
61
so we'll have something like public and a max age property
62
so max age and this would be milliseconds
63
and what this means is the client can reuse that resource as long as the age
64
of the asset so there's an age which starts at zero
65
when we just got it as long as the age it's
66
smaller than max age the client doesn't need to get
67
that resource uh basically the web browser would store
68
that on the computer and get the resource from there get the css file from there um
69
and that's so that's basically the the basics behind it what would happen what what's happening
70
when the age goes higher than this uh then then whatever the max age was is that the
71
client will make a request but it's not a request for the resource
72
but it's rather to check
73
if it's this is what we call caching validation is the resource still fresh is the resource still fresh
74
and basically they will do that nowadays with the e-tag
75
so you probably have an extra tag which was it's the tag
76
and basically it's a unique hash that was computed for this version of the css file
77
and so they will send that to the server
78
and check was this modified
79
and the server can answer with in two ways they can either say no it wasn't modify keep
80
that version or yes it was modified make a request get a new version over
81
and back to your question on
82
if i ever used it this is basically uh most of
83
times comes out of the box with any cdn you're using
84
so if you're deploying your application
85
and you put a cdn in front of it like a
86
content delivery network basically they already apply this to all your
87
static assets they add etags they add the cache control
88
and the age and we can even go in
89
and look at the live example
90
if you want yeah let's pick something like maybe github
91
or any like popular developer website okay let me see if i can share my screen again Now,
92
one thing I want you to do to go over is this public parameter.
93
You know, what does public mean in that request?
94
Okay, so let's see how this looks like in Stack Overflow, for example.
95
Yeah, so I'm going to go over why I did that and what does that mean, but I just reloaded a page right now.
96
And as you see here, it says 200 from the disk cache.
97
So this was not, this is not coming from the server.
98
This is coming from my personal computer.
99
And the reason for that is that you see I'm not sure how big this is, but the age parameter here, the age, it's this minimum milliseconds.
100
And if we look at the cache control, it's a public mass max age 315, 360.
101
So basically what this is saying is, Hey, you, you can keep the asset for a bit longer.
102
Yes.
103
As long as this age goes over, they will rely on the e-tag.
104
So there's this e-tag header that should be somewhere.
105
Now, because there's no e-tag, because I probably did not, give me a second, accept.
106
Okay, it didn't really find the e-tag.
107
I think they might be relying on the last modified.
108
Last modified, it's an alternative and expires.
109
There are alternatives to eTags, but because it's so hard in programming to compare dates and you need to always bring them back to a time zone,
110
it's just a lot easier to use the eTags.
111
And so the modern way is to use eTags.
112
Maybe if we look at another asset, like a CSS asset, they probably use...
113
I could see the eTag there.
114
There you go.
115
It has an eTag.
116
but again um the cache control on this resource is no cache
117
so okay even
118
if we have it's not really being used that's what i was looking for this one that's a better example
119
but again there's no there's no e-tag on this one
120
so it very much depends on how they um perfect it's
121
pretty much i feel like they're using an older um setup because they're using expire and last modify all the time
122
The other thing is, as you see here, if we enable Disable Cache, what we will be doing, and this is something really cool that Google Chrome does for us, is that whenever we get a resource,
123
on the request headers, we are setting a cache control ourselves to no cache as the client.
124
We're saying, hey, there won't be any caching happening.
125
Bypass the cache, right?
126
Yes, you could say that.
127
We're actually using the headers to specify there is no cache.
128
and because we do that, you see cache control, no cache, then it doesn't really matter what the server implements.
129
So just going back to the drawing, this is how HTTP caching works, I'd say at top view.
130
Awesome, Bogdan.
131
Now let's move on with the next question.
132
So imagine you have a huge SQL database.
133
We want to scale that.
134
So what are the different ways we can scale that huge SQL database?
135
Okie dokie so we have one of those um i'm going to go back to my board just
136
because it's a lot easier to show than tell um yeah
137
as a quick question do we know anything about the traffic
138
on this database in terms of reads versus writes for example do we read a lot
139
or do we write a lot what is it let's let's assume we read a lot more than we write
140
but as we scale we will also um face a writing problem down the road.
141
Okay, I mean most web applications you will read a lot more than you write
142
if you take the example of Instagram and so on
143
or any social media people watch and consume stuff much more than they publish on average.
144
Yeah that's a good news feed based application like a social media that's a good example so you can use that yes.
145
Okay so if that's the case and we get a lot of incoming traffic here
146
and we figure out that the queries are getting slower the memory on this component memory
147
and cpu usage uh it's blown up what we can do is to basically apply a replication strategy
148
that will basically rather than having one database we will have one database
149
that handles the reading
150
and then we're going to have a bunch of let me copy this a bunch of read-only replicas so
151
they used to be called master
152
and slave although right now we can just call it the the main database
153
and then uh and basically what happens is we write to the main database
154
and whenever we write that it gets replicated to the child to the to the read-only replicas
155
but whenever we read from the database we go to this cluster of read-only replicas
156
and so we can offload a lot of reading pressure to these replicas
157
and they are quite performant and
158
that will be one of the easiest way to scale the
159
database by by having read-only let me write it down here
160
read-only replicas you can do this in aws i've done this with rds it's very straightforward
161
and it's one of the easiest way now to follow up
162
on what you mentioned as a second case imagine we do need to write a lot so
163
um we are getting to this point where this database right is getting bigger
164
and bigger we have too much pressure on the hardware
165
and we either add more hardware which is usually a bad strategy or what we can try to implement it's sharding
166
so basically what we do is
167
that we try to split um into different databases based on a property
168
that we hash so for example we have a bunch of records here
169
and then we take their let's say the id
170
and then we somehow hash it
171
and you can think of this as a almost a load balancer it's not really a load balancer
172
but based on the id we can actually push the record here or here or here
173
and whenever we need to read based on the id whenever we want to fetch
174
that then they will redirect
175
and read from the right database getting into the distributed systems
176
part right yes this is a bit more complex to implement again um
177
because you don't want to do this with you don't write
178
any application code you don't we don't want to couple the storage with our code
179
so this becomes a bit more complex to implement um you need to know about consistent hashing
180
and the hard thing about this is when you have joins
181
or when you want to query um you want to query records
182
that are distributed over distribution it's always um a huge limitation
183
but if you're on a scale there's There's no way around it.
184
Yeah, you mentioned scaling it via hardware, right?
185
Let's say vertical scaling.
186
This is an example of horizontal scaling.
187
Why not scaling our database vertically?
188
Why distribute in the first place?
189
Very good question.
190
The problem with vertical scaling is that it's going to become exponentially more expensive.
191
The more hardware...
192
So the difference between a machine that has, let's say 16 gigabytes to 32 in terms of price, it's very high.
193
And the other problem is you will most likely not need
194
so much capacity all the time you probably have peak hours
195
and so the problem once you scale vertically is that it's not
196
so easy to go back you need to shut down the server
197
and then relocate to a bigger machine or even
198
if you do it in the cloud it's usually very expensive it has downtime
199
and you still have a unique point of failure that's another problem that can appear.
200
So distribution not only improves scalability, but also improves availability of the resource.
201
Okay, now we're going to go and talk about deployment.
202
Could you explain the different deployment types?
203
And as you explain them, feel free to dive deep into pros and cons, advantages, disadvantages.
204
Yeah, different deployment types you've been exposed as a senior backend engineer.
205
Okay, so I'm going to start with the simplest one.
206
I used to do this, we used to do this at pretty much every startup you work for.
207
That would be the in-place deployment.
208
And this basically means that in one way or the other, we have our server, whatever that is, a Linux server, let's say.
209
And we have a code that's, let's say, so let me make this green.
210
Let me make my code blue.
211
And basically, we just kind of somehow replace the code with a new version.
212
I'm going to put that green.
213
right so we somehow push a new version
214
and then we restart the server i've done a lot of
215
those especially at the beginning of my of my career it's
216
very robust it's very easy to set up you just need to know a bit of server administration
217
but you do have downtime so whenever you are restarting the application there might be downtime
218
and it's extremely hard to roll back sometimes
219
so rollback can be a problem uh you and
220
because you don't have a good rollback mechanism downtime can another problem um
221
and also well it depends how you have it set up
222
but usually it's very very manual but this is like the good old-fashioned deployment um
223
and you need to stay awake until
224
2 p.m when you have no users right down downtime yeah i mean it depends on your traffic
225
but i had to i did a bunch of all nighters doing those
226
so um not funny cool not at all not at all um then Then there's the rolling deployment, which is more or less the same,
227
but the only difference here is that, and this is when it gets complicated, because you, let's say, have a fleet of instances, because we are horizontally scaling our service, let's say.
228
In Amazon, in AWS, they call this auto-scaling groups, but it doesn't really matter.
229
You have a fleet of instances, and so what you do is you gradually deploy the new version of the software, right?
230
So this becomes green all of a sudden, and then this too.
231
And then ideally, there's no issues, and then it can continue um this is again it's kind
232
of complex uh the disadvantage is some people will access version two
233
and some other will action version version one
234
so you can have problems there especially if you have databases involved
235
because you need to also deploy migrations if you have a skill databases
236
so again it's not great but it is the only way you can deploy to a fleet of instances
237
the advantage here it's if there's any problem with these two you still have the other two alive
238
so you can maybe just shut this down really quickly
239
and then instantiate a bunch of those really fast
240
so downtime it's a bit less
241
but it's also again it's complex um you pay a lot of costs
242
because you're distributing everything how do you distribute the traffic in this case
243
um so in this case you have a load balancer component
244
that sits here
245
and the load balancer it's responsible for kind of distributing traffic either with a round robin algorithm
246
or whatever load balancing algorithm you choose
247
but again the load balancer doesn't really know which version is it
248
so some users will go over there some users will go over there that's kind of the problem
249
let's go into prosynchrons
250
so um i what i understand is there is no downtime
251
you just might get different different users might get different versions right
252
but here we avoid the downtime right
253
because we have this rolling strategy um yes
254
and no you can still have users that experience bad experiences because if there's a mistake here, it's going to affect them.
255
So you have less downtime, but you can have problems.
256
And this is what the next, like the blue-green deployment kind of solves.
257
Blue-green.
258
So in here, we basically duplicate the whole thing.
259
So rather than, imagine this is our old version, right?
260
It's receiving traffic right now.
261
yes and what we do is we totally deploy
262
and provision in a total copy of this with a new application so let me just make this green
263
okie dokie and so that
264
because we have two of them we can actually make all our checks
265
and then start redirecting traffic here and
266
if there's any problem you keep alive this distribution and and shut it down as soon as you see there's a problem.
267
So this has basically, literally, it shouldn't have no downtime.
268
Like literally this has no downtime.
269
No downtime.
270
And the rollback, it's very fast because you keep this alive.
271
And if there's any problem, you can shut it down.
272
The disadvantage is you're going to pay a lot in your infrastructure costs.
273
This can cost you a lot because you are duplicating this infrastructure and you need to keep it alive for a while.
274
You also need to have a lot of complex tooling to be able to manage these load balancer components, to spin infrastructure really fast, so something like Infrastructure as Code can help you.
275
But again, this is very complex.
276
If you're using tools like Kubernetes and containers, you can set it up fairly quick.
277
Is there any more type of deployments that you would like to mention?
278
There's Canary deployment, and it's pretty much the same as Blue Green, but there's a big difference,
279
which is that you usually only redirect part of the traffic to our new instance.
280
So you go ahead and you say, let me have 2% of the traffic over here or 10%, or let me have the traffic from a specific geography.
281
I worked with that a lot.
282
And the other thing, the reason it's called canary is because you have a canary.
283
remember the
284
uh back in the days the miners had a canary
285
that they would send over to see if if there's any gas leak
286
and the canary
287
if it comes back then then it's all good um the
288
canary it's usually an entrance test that's running all the time
289
and you run it against the new instance and so
290
if the canary it's okay then you start um radiating more traffic again you need a canary that's number one
291
and complex load balancing setup because you want to redirect you want to slice your traffic somehow
292
and number five i do not consider this a type of deployment i know some people do
293
but that would be the feature toggles where you you're really not you deploy the whole version
294
but you have some code logic that can switch a feature on
295
and off um i do not consider this a type of
296
deployment for me it's almost like a feature in the software but some people do and it has several advantages
297
which is that you decouple your deployment from your code deployment, like the deployment of the feature from the code deployment, but at the same time having a lot of feature toggles
298
really increments the amount of testing you need to do to your software.
299
So I'm not gonna add it as an extra deployment.
300
Next question, how does the internet works?
301
And I want you to explain that, you know, since the moment you type something into your browser, until the page is shown,
302
but until the page is rendered to the users to yeah
303
to the final user okay that's actually a very fun exercise
304
um how does internet work well let's say it all starts as you mentioned with
305
a web browser where we type something let's say we type the senior dev
306
um so we type this in our web browser
307
and the first thing the web browser will do it will
308
make a query to look up the dns like the ip
309
address of this of the server that's hosting this website
310
and they will make
311
that to the dns server like the domain name system the servers are basically like tables
312
so you just kind of think of a table hosted somewhere
313
that says you know what the senior dev uh let me see has
314
so this senior dev whatever it has this ip address
315
so whatever okay that's not the real ip address
316
that i'm adding there but you get the idea so
317
and they have a bunch of them
318
and then the browser knows okay that's the ip address
319
and of course this is the internet protocol and
320
so over the ip network we will start sending we can now start sending ip packages um
321
these ip packages are containing tcp packages and tcp packages are put together in an http request so basically
322
when you type this address you end up making a 200
323
get a get request to uh to this path to our domain
324
and i would assume the the browser will send some headers to like what does it accept
325
and most of times it would be something like accept text slash html
326
so it's basically requesting an html file that we have here um
327
so that would be the request and then it will be a response.
328
So the server will connect, will open up a TCP connection with this and probably reply with, ideally, if I think it's successful, a 200 OK.
329
And there will be some headers, but basically the headers will tell you what's the content type of our response,
330
which would be text slash HTML.
331
And then there's an empty line, and then you have your HTML document.
332
HTML, which is obviously, it's just text, right?
333
It's just a bunch of text.
334
And then the browser will take this and see, okay, this is text HTML.
335
So I'm going to get all the body of the request here and applies basically what we call the critical rendering path.
336
So basically it will take our markdown.
337
It will try to build the HTML tree.
338
It will request any links to CSS assets
339
or javascript assets it will interpret those
340
and then it will try to stream to incrementally build the
341
ui as it reads down the html very good overview um
342
we're not gonna go deep into the critical rendering pad um because that belongs more to the front-end engineering
343
interview but that's definitely a topic that um that's pretty interesting talking about
344
painting final the final website to the user well bugdon uh
345
this is it for uh today very well done now uh for the people watching us um you know
346
if there's any specific back-end question you want bar the night
347
to dive deep uh just drop it in the comments
348
and we will add it to our next video that's number
349
one um number two we are putting together a community for javascript software engineers
350
that are looking to get to the senior level with quality
351
resources accountability we have monthly calls where you can directly interact with bargain
352
and i um you know we help you with interview technical
353
interview resources any kind of resources you need to make
354
that jump towards a senior and beyond um
355
if you want to check it out uh just check the link in comments you can apply
356
and we will um you know we we have a bunch of people waiting to get in
357
so we will review your application just give us time
358
and get you in if there's a fit and finally
359
if you would like to work personally with barton
360
and i in a you know one-on-one group mentoring um coaching
361
program right this is what software mastery is designed for we are helping developers fill up the tinkle gaps
362
and become that confident competent senior engineer um
363
but we cannot work with any kind of developer
364
so uh this is a premium service if you think you know
365
that would be something you'd be interested in just click on
366
the link in the comments also you'll find a link to
367
apply for a small chat with me where we will see hey can we help you is this a fit
368
and see if we can talk fighter uh whether you want to join us
369
or not with that being said thank you so much very great answers
370
and we will see you folks in the next one
📺 같은 채널
✨ 추천 영상
C11
245 문장
QA Automation Interview Questions and Answers
Business EnglishInterview EnglishUniversity Students
C11
158 문장
OWASP Top 10 Explained
Business EnglishUniversity StudentsWorking Adults
C11
49 문장
Next JS Interview Questions and Answers 2026 | Top 20 Most Asked Questions
Business EnglishInterview EnglishUniversity Students
B24
11 문장
full audio online video cutter com
Business EnglishInterview EnglishUniversity Students
C13
26 문장
🔥 Java Multithreading Rapid Fire | Can You Answer These Interview Questions? #shorts
Business EnglishInterview EnglishUniversity Students
C11
674 문장
FULL Data Science Mock Interview | SQL, Statistics, Business
Business EnglishInterview EnglishUniversity Students
B23
63 문장
How To Land Your First Junior Dev Role
Business EnglishInterview EnglishUniversity Students
B21
193 문장
SOC Analyst: Top Interview Questions & Answers (2025)
Business EnglishInterview EnglishUniversity Students
C11
114 문장
Design a File Upload Service Like a Senior Engineer
Business EnglishUniversity StudentsWorking Adults
C14
200 문장
10 JavaScript Interview Questions You HAVE TO KNOW
Business EnglishInterview EnglishUniversity Students
B22
230 문장
Job Interview in English | Talking About Your Weaknesses
Business EnglishInterview EnglishUniversity Students
C11
95 문장
API Gateways in System Design Interviews w/ Ex-Meta Staff Engineer
Business EnglishInterview EnglishUniversity Students
이 레슨의 어휘와 말하기 포인트
이 C1 수준 말하기 레슨은 영상 “FullStack Interview Questions”을(를) 바탕으로 합니다. 이 영상에는 섀도잉할 문장 370개와 단어 4456개가 있습니다. 말하는 구간의 길이는 24:36입니다. 화자는 분당 약 181단어로 빠르게 말하므로 연음과 약하게 발음되는 소리가 많습니다. 단어의 84%가 영어에서 가장 많이 쓰이는 3,000단어에 속합니다. 나머지는 연습 전에 미리 확인해 두세요.
이 영상의 핵심 어휘
영상에서 가장 어려운 단어 15개를 발음, 뜻과 함께 정리했습니다.
| 단어 | 발음 | 뜻 |
|---|---|---|
| cache 명사 | /kæʃ/ | 캐시 |
| downtime 명사 | /ˈdaʊnˌtaɪm/ | 다운타임 |
| query 명사 | /ˈkwɪɹ.i/ | 질문 |
| canary 명사 | /kəˈnɛəɹi/ | 카나리아 |
| deploy 동사 | /dɪˈplɔɪ/ | 배치하다 |
| modify 동사 | /ˈmɑ.dɪˌfaɪ/ | 수정하다 |
| hash 명사 | /ˈhæʃ/ | 해시 |
| parameter 명사 | /pəˈɹæm.ə.tɚ/ | 파라미터, 매개변수 |
| disadvantage 명사 | /ˌdɪsədˈvæntɪd͡ʒ/ | 불리 |
| render 동사 | /ˈɹɛn.dɚ/ | 일어나게 하다, 하게하다 |
| injection 명사 | /ɪnˈd͡ʒɛk.ʃən/ | 주사 |
| millisecond 명사 | /ˈmɪlɪˌsɛkənd/ | 밀리초, 밀리세컨드 |
| duplicate 동사 | /ˈd(j)uː.plɪˌkeɪt/ | 복사하다 |
| execute 동사 | /ˈɛksɪˌkjuːt/ | 처형하다 |
| algorithm 명사 | /ˈælɡəɹɪðm̩/ | 알고리즘, 알고리듬 |
영상에 나오는 구동사
| 단어 | 뜻 |
|---|---|
| blow up 동사 | 폭파하다 |
| come back 동사 | 돌아오다 |
| go back 동사 | 돌아가다 |
| put together 동사 | 조립하다 |
따라 말해 볼 만한 문장
영상에 나오는 짧고 완결된 문장으로, 일상 대화에서 그대로 쓸 수 있습니다:
- Can I share my screen?
- Let's imagine it that way.
- You know, what does public mean in that request?
- Why not scaling our database vertically?
- Could you explain the different deployment types?
이 영상의 문법
화자가 가장 많이 쓰는 문형을 영상 속 실제 표현과 함께 정리했습니다.
| 문형 | 영상 속 표현 |
|---|---|
| “used to” used to + 동사 — 지금은 아닌 과거의 습관이나 상태 | used to be · used to do |
| 수동태 be + 과거분사 — 누가 하는지보다 무슨 일이 일어나는지에 초점 | was computed · was modified · be called |
| 관계절 who / which + 절 — 사람이나 사물에 대한 추가 정보 | tag which was · hardware which is · deployment, which is |
| 현재완료 have/has + 과거분사 — 과거의 일이 지금도 관련이 있을 때 | i've done · you've been exposed |
주의할 발음
화자는 I'm, you're, we're 같은 축약형과 약화된 형태를 51번 사용합니다. 들리는 대로 짧게 발음하세요.
- “sh”와 “zh” 소리: cache /kæʃ/, hash /ˈhæʃ/, injection /ɪnˈd͡ʒɛk.ʃən/, exponentially /ɛkspə(ʊ)ˈnɛnʃəli/, instantiate /ɪnˈstænʃieɪt/
- 긴 단어 — 강세 위치에 주의: parameter /pəˈɹæm.ə.tɚ/, disadvantage /ˌdɪsədˈvæntɪd͡ʒ/, millisecond /ˈmɪlɪˌsɛkənd/, vertically /ˈvɝ.tɪ.kəli/, ideally /aɪˈdi.ə.li/
한국어 화자가 어려워하는 소리:
- /f/ — ㅍ(/p/)으로 바꾸지 말고 윗니를 아랫입술에 대기: modify /ˈmɑ.dɪˌfaɪ/, specify /ˈspɛs.əˌfaɪ/, offload /ˌɑfˈloʊd/, performant /pɚˈfɔɹmənt/, fetch /fɛt͡ʃ/
- /v/ — ㅂ(/b/)과 구별하기: disadvantage /ˌdɪsədˈvæntɪd͡ʒ/, vertically /ˈvɝ.tɪ.kəli/, validation /ˌvæl.əˈdeɪ.ʃən/
- /z/ — ㅈ이 아니라 성대를 울리는 /s/: browser /ˈbɹaʊ.zəɹ/, sanitize /ˈsænətaɪz/, horizontal /ˌhoɹəˈzɑn.təl/
이 영상으로 연습하는 방법
- 먼저 말하지 않고 영상을 끝까지 듣고 모르는 단어를 적어 둡니다.
- 0.75배속으로 한 문장씩 섀도잉을 시작하고, 익숙해지면 보통 속도로 돌아갑니다.
- 자신의 목소리를 녹음해 원본과 비교하고, cache, downtime, query 같은 단어에 특히 주의합니다.
쉐도잉이란? 영어 실력을 빠르게 키우는 과학적 방법
쉐도잉(Shadowing)은 원래 전문 통역사 훈련을 위해 개발된 언어 학습 기법으로, 다언어 학자인 Dr. Alexander Arguelles에 의해 대중화된 방법입니다. 핵심 원리는 간단하지만 매우 강력합니다: 원어민의 영어를 들으면서 1~2초의 짧은 지연으로 즉시 소리 내어 따라 말하는 것——마치 '그림자(shadow)'처럼 화자를 따라가는 것입니다. 문법 공부나 수동적인 청취와 달리, 쉐도잉은 뇌와 입 근육이 동시에 실시간으로 영어를 처리하고 재현하도록 훈련합니다. 연구에 따르면 이 방법은 발음 정확도, 억양, 리듬, 연음, 청취력, 말하기 유창성을 크게 향상시킵니다. IELTS 스피킹 준비와 자연스러운 영어 소통을 원하는 분들에게 특히 효과적입니다.