javascript-tutorial · mayrang · May 13, 2026 · May 14, 2026 · May 16, 2026 · jjyy0804
diff --git a/1-js/03-code-quality/01-debugging-chrome/article.md b/1-js/03-code-quality/01-debugging-chrome/article.md
@@ -1,8 +1,4 @@
-<<<<<<< HEAD
-# Chrome으로 디버깅하기
-=======
-# Debugging in the browser
->>>>>>> upstream/master
+# 브라우저에서 디버깅하기
 
 좀 더 복잡한 코드를 작성하기 전에, 디버깅이란 것에 대해 이야기해봅시다.
 
@@ -42,11 +38,7 @@ Sources 패널은 크게 세 개의 영역으로 구성됩니다.
 
 콘솔 창에 구문(statement)을 입력하고 실행하면 아랫줄에 실행 결과가 출력됩니다.
 
-<<<<<<< HEAD
 `1+2`를 입력하면 `3`이 출력되고, `hello("debugger")`를 입력하면 `undefined`가 출력되죠. `undefined`가 출력되는 이유는 `hello("debugger")`가 아무것도 반환하지 않기 때문입니다.
-=======
-For example, here `1+2` results in `3`, while the function call `hello("debugger")` returns nothing, so the result is `undefined`:
->>>>>>> upstream/master
 
 ![](chrome-sources-console.svg)
 
@@ -70,22 +62,13 @@ Sources 패널 우측의 디버깅 영역을 보면 중단점 목록을 확인
 - 마우스 오른쪽 버튼을 클릭했을 때 나오는 'Remove breakpoint' 옵션을 통해 중단점을 삭제할 수도 있습니다.
 - 이 외에도 다양한 기능이 있습니다.
 
-<<<<<<< HEAD
 ```smart header="조건부 중단점"
-줄 번호에 커서를 옮긴 후 마우스 오른쪽 버튼을 클릭하면 *조건부 중단점(conditional breakpoint)* 을 설정할 수 있습니다. `Add conditional breakpoint`를 클릭했을 때 뜨는 작은 창에 표현식을 입력하면, 표현식이 참인 경우에만 실행을 중지시킬 수 있습니다.
-=======
-```smart header="Conditional breakpoints"
-*Right click* on the line number allows to create a *conditional* breakpoint. It only triggers when the given expression, that you should provide when you create it, is truthy.
->>>>>>> upstream/master
+줄 번호에 커서를 옮긴 후 마우스 오른쪽 버튼을 클릭하면 *조건부 중단점(conditional breakpoint)* 을 설정할 수 있습니다. `Add conditional breakpoint`를 클릭했을 때 뜨는 작은 창에 표현식을 입력하면, 표현식이 참으로 평가되는 경우에만 실행을 중지시킬 수 있습니다.
 
 조건부 중단점을 설정하면 변수에 특정 값이 할당될 때나 함수의 매개 변수에 특정 값이 들어올 때만 실행을 중단시킬 수 있어 디버깅 시 유용하게 활용할 수 있습니다. 
 ```
 
-<<<<<<< HEAD
 ## debugger 명령어
-=======
-## The command "debugger"
->>>>>>> upstream/master
 
 아래 예시처럼 스크립트 내에 `debugger` 명령어를 적어주면 중단점을 설정한 것과 같은 효과를 봅니다.
 
@@ -101,12 +84,8 @@ function hello(name) {
 }
 ```
 
-<<<<<<< HEAD
-debugger 명령어를 사용하면 브라우저를 켜 개발자 도구를 열고 소스 코드 영역을 띄워 중단점을 설정하는 수고를 하지 않아도 됩니다. 에디터를 떠나지 않고도 중단점을 설정할 수 있기 때문에 편리하죠.
+이 명령어는 개발자 도구가 열려있을 때만 동작하며, 그렇지 않으면 브라우저가 이를 무시합니다.
 
-=======
-Such command works only when the development tools are open, otherwise the browser ignores it.
->>>>>>> upstream/master
 
 ## 멈추면 보이는 것들
 
@@ -120,11 +99,7 @@ Such command works only when the development tools are open, otherwise the brows
 
 1. **`Watch` -- 표현식을 평가하고 결과를 보여줍니다.**
 
-<<<<<<< HEAD
     Add Expression 버튼 `+`를 클릭해 원하는 표현식을 입력한 후 `key:Enter`를 누르면 중단 시점의 값을 보여줍니다. 입력한 표현식은 실행 과정 중에 계속해서 재평가됩니다. 
-=======
-    You can click the plus `+` and input an expression. The debugger will show its value, automatically recalculating it in the process of execution.
->>>>>>> upstream/master
 
 2. **`Call Stack` -- 코드를 해당 중단점으로 안내한 실행 경로를 역순으로 표시합니다.**
 
@@ -162,20 +137,11 @@ Such command works only when the development tools are open, otherwise the brows
 <span class="devtools" style="background-position:-62px -192px"></span> -- 'Step over': 다음 명령어를 실행하되, *함수 안으로 들어가진 않음* (단축키 `key:F10`)
 : 'Step'과 유사하지만, 다음 문이 함수 호출일 때 'Step'과는 다르게 동작합니다(`alert` 같은 내장함수에는 해당하지 않고, 직접 작성한 함수일 때만 동작이 다릅니다).
 
-<<<<<<< HEAD
     'Step'은 함수 내부로 들어가 함수 본문 첫 번째 줄에서 실행을 멈춥니다. 반면 'Step over'는 보이지 않는 곳에서 중첩 함수를 실행하긴 하지만 함수 내로 진입하지 않습니다.
 
     실행은 함수 실행이 끝난 후에 즉시 멈춥니다.
 
     'Step over'은 함수 호출 시 내부에서 어떤 일이 일어나는지 궁금하지 않을 때 유용합니다.
-=======
-<span class="devtools" style="background-position:-62px -192px"></span> -- "Step over": run the next command, but *don't go into a function*, hotkey `key:F10`.
-: Similar to the previous "Step" command, but behaves differently if the next statement is a function call (not a built-in, like `alert`, but a function of our own).
-
-    If we compare them, the "Step" command goes into a nested function call and pauses the execution at its first line, while "Step over" executes the nested function call invisibly to us, skipping the function internals.
-
-    The execution is then paused immediately after that function call.
->>>>>>> upstream/master
 
 <span class="devtools" style="background-position:-4px -194px"></span> -- 'Step into' (단축키 `key:F11`)
 : 'Step'과 유사한데, 비동기 함수 호출에서 'Step'과는 다르게 동작합니다. 이제 막 자바스크립트를 배우기 시작한 분이라면 비동기 호출에 대해 아직 배우지 않았기 때문에 'Step'과 'Step into'의 차이를 몰라도 괜찮습니다.
@@ -191,13 +157,8 @@ Such command works only when the development tools are open, otherwise the brows
 <span class="devtools" style="background-position:-90px -146px"></span> -- 예외 발생 시 코드를 자동 중지시켜주는 기능을 활성화/비활성화
 : 활성화되어 있고, 개발자 도구가 열려있는 상태에서 스크립트 실행 중에 에러가 발생하면 실행이 자동으로 멈춥니다. 실행이 중단되었기 때문에 변수 등을 조사해 어디서 에러가 발생했는지 찾을 수 있게 됩니다. 개발하다가 에러와 함께 스크립트가 죽었다면 디버거를 열고 이 옵션을 활성화한 후, 페이지를 새로 고침하면 에러가 발생한 곳과 에러 발생 시점의 컨텍스트를 확인할 수 있습니다.
 
-<<<<<<< HEAD
 ```smart header="Continue to here 옵션"
 특정 줄에서 마우스 오른쪽 버튼을 클릭해 컨텍스트 메뉴를 열면 "Continue to here"라는 옵션을 볼 수 있습니다.
-=======
-<span class="devtools" style="background-position:-90px -146px"></span> -- enable/disable automatic pause in case of an error.
-: When enabled, if the developer tools is open, an error during the script execution automatically pauses it. Then we can analyze variables in the debugger to see what went wrong. So if our script dies with an error, we can open debugger, enable this option and reload the page to see where it dies and what's the context at that moment.
->>>>>>> upstream/master
 
 중단점을 설정하기는 귀찮은데 해당 줄에서 실행을 재개하고 싶을 때 아주 유용한 옵션입니다.
 ```
@@ -226,11 +187,7 @@ for (let i = 0; i < 5; i++) {
 2. `debugger`문 만났을 때
 3. 에러가 발생했을 때(개발자 도구가 열려있고 <span class="devtools" style="background-position:-90px -146px"></span> 버튼이 '활성화'되어있는 경우)
 
-<<<<<<< HEAD
 스크립트 실행이 중지되면 중단 시점을 기준으로 변수에 어떤 값이 들어가 있는지 확인할 수 있습니다. 또한 단계별로 코드를 실행해 가며, 어디서 문제가 발생했는지 추적할 수도 있습니다. 이런 식으로 디버깅이 진행됩니다.
-=======
-When paused, we can debug: examine variables and trace the code to see where the execution goes wrong.
->>>>>>> upstream/master
 
 개발자 도구는 여기서 소개한 기능 이외의 다양한 기능을 지원합니다. Google에서 제공하는 개발자 도구 공식 매뉴얼은 <https://developers.google.com/web/tools/chrome-devtools>에서 확인할 수 있습니다.
 

diff --git a/1-js/03-code-quality/02-coding-style/1-style-errors/solution.md b/1-js/03-code-quality/02-coding-style/1-style-errors/solution.md
@@ -2,7 +2,6 @@
 주석을 참고해 어떤 점이 좋지 않은지 살펴봅시다.
 
 ```js no-beautify
-<<<<<<< HEAD
 function pow(x,n)  // <- 인수 사이에 공백이 없음
 {  // <- 별도의 줄에 있는 중괄호
   let result=1;   // <- 할당 연산자 = 앞/뒤에 공백이 없음
@@ -16,21 +15,6 @@ let x=prompt("x?",''), n=prompt("n?",'') // <-- 에러를 발생시키는 코드
 if (n<=0)  // <- (n <= 0) 같이 공백을 넣는 게 좋고, 윗줄은 비워놓아야 함(세로 들여쓰기)
 {   // <- 별도의 줄에 있는 중괄호
   // 아랫줄같이 가로 길이가 길어지면 가독성을 위해 코드를 여러 줄로 쪼개는 게 좋음  
-=======
-function pow(x,n)  // <- no space between arguments
-{  // <- curly brace on a separate line
-  let result=1;   // <- no spaces before or after =
-  for(let i=0;i<n;i++) {result*=x;}   // <- no spaces
-  // the contents of { ... } should be on a new line
-  return result;
-}
-
-let x=prompt("x?",''), n=prompt("n?",'') // <-- technically possible,
-// but better make it 2 lines, also there's no spaces and missing ;
-if (n<=0)  // <- no spaces inside (n <= 0), and should be extra line above it
-{   // <- curly brace on a separate line
-  // below - long lines can be split into multiple lines for improved readability
->>>>>>> upstream/master
   alert(`Power ${n} is not supported, please enter an integer number greater than zero`);
 }
 else // <- "} else {"같이 else와 중괄호는 한 줄에 작성하는 게 좋음

diff --git a/1-js/03-code-quality/02-coding-style/article.md b/1-js/03-code-quality/02-coding-style/article.md
@@ -116,11 +116,7 @@ if (
 
     탭 대신 스페이스를 이용했을 때의 장점 중 하나는 들여쓰기 정도를 좀 더 유연하게 변경할 수 있다는 점입니다.
 
-<<<<<<< HEAD
     아래 예시처럼 인수 모두의 위치를 여는 괄호와 맞출 수 있죠.
-=======
-    For instance, we can align the parameters with the opening bracket, like this:
->>>>>>> upstream/master
 
     ```js no-beautify
     show(parameters,
@@ -305,19 +301,11 @@ Linter라는 도구를 사용하면 내가 작성한 코드가 스타일 가이
 
 유명 linter:
 
-<<<<<<< HEAD
-- [JSLint](http://www.jslint.com/) -- 역사가 오래된 linter
-- [JSHint](http://www.jshint.com/) -- JSLint보다 세팅이 좀 더 유연한 linter
-- [ESLint](http://eslint.org/) -- 가장 최근에 나온 linter
+- [JSLint](https://www.jslint.com/) -- 역사가 오래된 linter
+- [JSHint](https://jshint.com/) -- JSLint보다 세팅이 좀 더 유연한 linter
+- [ESLint](https://eslint.org/) -- 가장 최근에 나온 linter
 
-위 linter 모두 훌륭한 기능을 제공합니다. 글쓴이는 [ESLint](http://eslint.org/)를 사용하고 있습니다.
-=======
-- [JSLint](https://www.jslint.com/) -- one of the first linters.
-- [JSHint](https://jshint.com/) -- more settings than JSLint.
-- [ESLint](https://eslint.org/) -- probably the newest one.
-
-All of them can do the job. The author uses [ESLint](https://eslint.org/).
->>>>>>> upstream/master
+위 linter 모두 훌륭한 기능을 제공합니다. 글쓴이는 [ESLint](https://eslint.org/)를 사용하고 있습니다.
 
 대부분의 linter는 플러그인 형태로 유명 에디터와 통합해 사용할 수 있습니다. 원하는 스타일을 설정하는 것 역시 가능합니다.
 
@@ -347,11 +335,7 @@ ESLint를 사용한다고 가정했을 때 아래 절차를 따르면 에디터
 
 위 예시에서 지시자 `"extends"`는 "eslint:recommended"를 기반으로 이를 확장해 스타일 가이드를 설정하겠다는 걸 의미합니다. 이렇게 세팅한 이후에 자신만의 스타일을 설정하면 됩니다.
 
-<<<<<<< HEAD
-스타일 규칙을 모아놓은 세트를 웹에서 다운로드해 이를 기반으로 스타일 가이드를 설정하는 것도 가능합니다. 설치 방법에 대한 자세한 내용은 <http://eslint.org/docs/user-guide/getting-started>에서 확인해 보시기 바랍니다.
-=======
-It is also possible to download style rule sets from the web and extend them instead. See <https://eslint.org/docs/user-guide/getting-started> for more details about installation.
->>>>>>> upstream/master
+스타일 규칙을 모아놓은 세트를 웹에서 다운로드해 이를 기반으로 스타일 가이드를 설정하는 것도 가능합니다. 설치 방법에 대한 자세한 내용은 <https://eslint.org/docs/user-guide/getting-started>에서 확인해 보시기 바랍니다.
 
 몇몇 IDE에서는 자체 lint 도구가 있어 편리하긴 하지만 ESLint처럼 쉽게 설정을 변경하는 게 불가능하다는 단점이 있습니다.
 

diff --git a/1-js/03-code-quality/03-comments/article.md b/1-js/03-code-quality/03-comments/article.md
@@ -143,11 +143,7 @@ function pow(x, n) {
 
 [WebStorm](https://www.jetbrains.com/webstorm/) 등의 다양한 에디터는 이런 주석을 이용해 자동 완성 기능, 자동 에러 검출 기능 등을 제공합니다.
 
-<<<<<<< HEAD
-[JSDoc 3](https://github.com/jsdoc3/jsdoc)이나 기타 유사한 툴을 사용하면 주석으로 HTML 문서를 만들 수 있습니다. 자세한 정보는 <http://usejsdoc.org/>에서 확인하시기 바랍니다.
-=======
-Also, there are tools like [JSDoc 3](https://github.com/jsdoc/jsdoc) that can generate HTML-documentation from the comments. You can read more information about JSDoc at <https://jsdoc.app>.
->>>>>>> upstream/master
+[JSDoc 3](https://github.com/jsdoc/jsdoc)이나 기타 유사한 툴을 사용하면 주석으로 HTML 문서를 만들 수 있습니다. 자세한 정보는 <https://jsdoc.app>에서 확인하시기 바랍니다.
 
 왜 이런 방법으로 문제를 해결했는지를 설명하는 주석
 : 무엇이 적혀있는지는 중요합니다. 그런데 무슨 일이 일어나고 있는지 파악하려면 무엇이 *적혀있지 않은 지*가 더 중요할 수 있습니다. '왜 이 문제를 이런 방법으로 해결했나?'라는 질문에 코드는 답을 해 줄 수 없기 때문입니다.

diff --git a/1-js/03-code-quality/04-ninja-code/article.md b/1-js/03-code-quality/04-ninja-code/article.md
@@ -1,14 +1,9 @@
 # 닌자 코드
 
 
-<<<<<<< HEAD
-```quote author="공자"
+```quote author="공자(논어)"
 생각 없이 배우기만 하면 얻는 것이 없고,<br>
 생각만 하고 배우지 않으면 오류나 독단에 빠질 위험이 있다.
-=======
-```quote author="Confucius (Analects)"
-Learning without thought is labor lost; thought without learning is perilous.
->>>>>>> upstream/master
 ```
 
 닌자라 불리던 전설 속 개발자들은 유지보수 담당 개발자를 혹독하게 훈련하고자 (아래에서 소개해 드릴) 다양한 편법을 사용하곤 했습니다.
@@ -111,15 +106,10 @@ i = i ? i < 0 ? Math.max(0, len + i) : i : 0;
 
 ## 동의어 사용하기
 
-<<<<<<< HEAD
-```quote author="공자"
-모든 일 중 가장 어려운 일은<br>
-어두운 방에서 검은 고양이를 찾는 일이다.<br><br>
-특히 그 방에 고양이가 없을 때에.
-=======
-```quote author="Laozi (Tao Te Ching)"
-The Tao that can be told is not the eternal Tao. The name that can be named is not the eternal name.
->>>>>>> upstream/master
+```quote author="노자(도덕경)"
+말할 수 있는 도(道)는 영원한 도가 아니며,<br>
+이름 붙일 수 있는 이름은<br>
+영원한 이름이 아니다.
 ```
 
 *유사한* 뜻을 가진 단어 여러 개를 *같은*걸 명명하는 데 사용해서 당신의 풍부한 어휘력을 은연중에 드러내 봅시다.