diff --git a/locale/ko/about/governance.md b/locale/ko/about/governance.md
new file mode 100644
index 0000000000000..e297f9d5ab241
--- /dev/null
+++ b/locale/ko/about/governance.md
@@ -0,0 +1,247 @@
+---
+title: 프로젝트 거버넌스
+layout: about.hbs
+---
+# 프로젝트 거버넌스
+
+## 기술 결정 위원회(TSC, Technical Steering Committee)
+
+<!--
+The project is jointly governed by a Technical Steering Committee (TSC)
+which is responsible for high-level guidance of the project.
+
+The TSC has final authority over this project including:
+
+* Technical direction
+* Project governance and process (including this policy)
+* Contribution policy
+* GitHub repository hosting
+* Conduct guidelines
+* Maintaining the list of additional Collaborators
+-->
+프로젝트의 고수준 지침에 대한 책임이 있는 기술 결정 위원회(TSC)가 함께 프로젝트를 운영하고 있습니다.
+
+TSC는 다음을 포함해서 이 프로젝트의 최종 권한을 가집니다.
+
+* 기술적 방향
+* 프로젝트 거버넌스와 절차 (이 정책을 포함해서)
+* 기여 정책
+* GitHub 저장소 호스팅
+* 행동 지침
+* 추가적인 협업자 목록의 관리
+
+<!--
+Initial membership invitations to the TSC were given to individuals who
+had been active contributors, and who have significant
+experience with the management of the project. Membership is
+expected to evolve over time according to the needs of the project.
+
+For the current list of TSC members, see the project
+[README.md](https://github.com/nodejs/node/blob/master/README.md#tsc-technical-steering-committee).
+-->
+최초의 TSC 멤버십 초대는 활발한 기여자나 프로젝트 관리에 충분한 경험을 가진 사람들에게 주어졌습니다.
+멤버십은 프로젝트의 요구사항에 따라 발전될 것입니다.
+
+현재 TSC 회원 목록은 프로젝트
+[README.md](https://github.com/nodejs/node/blob/master/README.md#tsc-technical-steering-committee)에서
+볼 수 있습니다.
+
+<!--
+## Collaborators
+
+The [nodejs/node](https://github.com/nodejs/node) GitHub repository is
+maintained by the TSC and additional Collaborators who are added by the
+TSC on an ongoing basis.
+
+Individuals making significant and valuable contributions are made
+Collaborators and given commit-access to the project. These
+individuals are identified by the TSC and their addition as
+Collaborators is discussed during the weekly TSC meeting.
+-->
+## 협업자
+
+TSC와 TSC가 지속적으로 추가한 협업자들이
+[nodejs/node](https://github.com/nodejs/node) GitHub 저장소를 관리하고 있습니다.
+
+중요하고 가치 있는 기여를 하는 개인이 협업자가 되고 프로젝트의 커밋-접근 권한을 받습니다. 이러한 개인은
+TSC가 인정하고 주간 TSC 회의에서 협업자로 추가하는 것을 논의합니다.
+
+<!--
+_Note:_ If you make a significant contribution and are not considered
+for commit-access, log an issue or contact a TSC member directly and it
+will be brought up in the next TSC meeting.
+
+Modifications of the contents of the nodejs/node repository are made on
+a collaborative basis. Anybody with a GitHub account may propose a
+modification via pull request and it will be considered by the project
+Collaborators. All pull requests must be reviewed and accepted by a
+Collaborator with sufficient expertise who is able to take full
+responsibility for the change. In the case of pull requests proposed
+by an existing Collaborator, an additional Collaborator is required
+for sign-off. Consensus should be sought if additional Collaborators
+participate and there is disagreement around a particular
+modification. See _Consensus Seeking Process_ below for further detail
+on the consensus model used for governance.
+-->
+_Note:_ 중요한 기여를 했음에도 커밋 접근 권한을 얻지 못한다면 이슈를 남기거나 TSC 멤버에게
+직접 연락을 취하면 다음 TSC 회의 때 다루게 될 것입니다.
+
+nodejs/node 저장소 내용의 수정은 협업을 통해서 이뤄집니다. GitHub 계정을 가진 누구나 풀 리퀘스트로
+수정을 제안할 수 있고 프로젝트 협업자가 이를 검토할 것입니다. 모든 풀 리퀘스트는 반드시 리뷰를
+받아야 하고 변경사항에 대한 전체 책임을 지고 상당한 전문성을 가진 협업자가 이를 받아들일 것입니다.
+기존의 협업자가 제안한 풀 리퀘스트는 다른 협업자가 승인해야 합니다. 다른 협업자가 관여해서
+특정 수정 부분에 대해서 동의하지 않는다면 합의가 이루어져야 합니다. 거버넌스의 합의 모델에 관한
+더 자세한 내용은 아래의 _합의점을 찾는 과정_을 보기 바랍니다.
+
+<!--
+Collaborators may opt to elevate significant or controversial
+modifications, or modifications that have not found consensus to the
+TSC for discussion by assigning the ***tsc-agenda*** tag to a pull
+request or issue. The TSC should serve as the final arbiter where
+required.
+
+For the current list of Collaborators, see the project
+[README.md](https://github.com/nodejs/node/blob/master/README.md#current-project-team-members).
+
+A guide for Collaborators is maintained in
+[COLLABORATOR_GUIDE.md](https://github.com/nodejs/node/blob/master/COLLABORATOR_GUIDE.md).
+-->
+협업자는 TSC에서 논의하려고 풀 리퀘스트나 이슈에 ***tsc-agenda*** 태그를 할당함으로써 중요하거나
+논쟁이 되는 수정사항이나 합의점을 찾지 못한 수정사항을 개선하려고 할 수도 있습니다.
+TSC는 필요한 경우 최종 중재자가 되어야 합니다.
+
+현재 협업자 목록은 프로젝트
+[README.md](https://github.com/nodejs/node/blob/master/README.md#current-project-team-members)에서
+볼 수 있습니다.
+
+협업자 가이드는
+[COLLABORATOR_GUIDE.md](https://github.com/nodejs/node/blob/master/COLLABORATOR_GUIDE.md)에서
+관리되어 있습니다.
+
+<!--
+## TSC Membership
+
+TSC seats are not time-limited.  There is no fixed size of the TSC.
+However, the expected target is between 6 and 12, to ensure adequate
+coverage of important areas of expertise, balanced with the ability to
+make decisions efficiently.
+
+There is no specific set of requirements or qualifications for TSC
+membership beyond these rules.
+
+The TSC may add additional members to the TSC by a standard TSC motion.
+-->
+## TSC 멤버십
+
+TSC 멤버십은 기간 제한이 없고 TSC에 인원 제한도 없습니다. 하지만, 전문성과 균형을 가진 채
+효율적인 결정을 하면서 중요한 영역을 충분히 다룰 수 있도록 6 ~ 12명 정도가 적당하다고 생각합니다.
+
+이 규칙을 뛰어넘는 TSC 멤버십의 요구사항이나 자격에 대한 특정 조건은 없습니다.
+
+TSC는 표준 TSC 발의를 통해 새로운 회원을 TSC에 추가할 것입니다.
+
+<!--
+A TSC member may be removed from the TSC by voluntary resignation, or by
+a standard TSC motion.
+
+Changes to TSC membership should be posted in the agenda, and may be
+suggested as any other agenda item (see "TSC Meetings" below).
+
+No more than 1/3 of the TSC members may be affiliated with the same
+employer.  If removal or resignation of a TSC member, or a change of
+employment by a TSC member, creates a situation where more than 1/3 of
+the TSC membership shares an employer, then the situation must be
+immediately remedied by the resignation or removal of one or more TSC
+members affiliated with the over-represented employer(s).
+-->
+TSC 회원은 자발적인 사퇴나 표준 TSC 발의를 통해 TSC에서 제외될 수 있습니다.
+
+TSC 멤버십의 변경은 의제에 올라와야 하고 다른 의제로 제안될 수도 있습니다.(아래 "TSC 회의"를 보세요.)
+
+TSC 회원의 1/3 이상이 같은 고용주와 관련되면 안 됩니다. TSC 회원이 제외되거나 사퇴하거나 TSC 회원의
+고용상태가 바뀔 때 TSC 멤버십의 1/3 이상이 같은 고용주를 갖게 되는 상황이 만들어질 수 있습니다.
+이 상황은 같은 고용주를 가진 1명 이상의 TSC 멤버가 사퇴하거나 제외됨으로써 즉시 해결되어야 합니다.
+
+<!--
+## TSC Meetings
+
+The TSC meets weekly on a Google Hangout On Air. The meeting is run by
+a designated moderator approved by the TSC. Each meeting should be
+published to YouTube.
+
+Items are added to the TSC agenda which are considered contentious or
+are modifications of governance, contribution policy, TSC membership,
+or release process.
+
+The intention of the agenda is not to approve or review all patches.
+That should happen continuously on GitHub and be handled by the larger
+group of Collaborators.
+-->
+## TSC 회의
+
+TSC는 구글 행아웃으로 매주 만납니다. TSC가 승인해서 선정한 중재자가 회의를 주최합니다.
+각 회의는 YouTube로 발행되어야 합니다.
+
+논쟁이 필요하거나 거버넌스, 기여 정책, TSC 멤버십, 릴리스 절차의 수정에 대한 주제가
+TSC 의제에 추가됩니다.
+
+이 의제의 의도는 모든 패치를 승인하거나 리뷰하는 것이 아닙니다. 이러한 승인이라 리뷰는
+GitHub에서 계속해서 이루어지고 더 큰 협업자 그룹에서 다뤄집니다.
+
+<!--
+Any community member or contributor can ask that something be added to
+the next meeting's agenda by logging a GitHub Issue. Any Collaborator,
+TSC member or the moderator can add the item to the agenda by adding
+the ***tsc-agenda*** tag to the issue.
+
+Prior to each TSC meeting, the moderator will share the Agenda with
+members of the TSC. TSC members can add any items they like to the
+agenda at the beginning of each meeting. The moderator and the TSC
+cannot veto or remove items.
+-->
+어떤 커뮤니티 회원이나 기여자도 GitHub에 이슈를 남김으로써 다음 미팅 일정에 무언가를 추가하도록
+요청할 수 있습니다. 어떤 협업자, TSC 회원, 중재자라도 이슈에 ***tsc-agenda*** 태그를
+추가해서 의제를 추가할 수 있습니다.
+
+각 TSC 회의 전에 중재자는 TSC 회원과 의제를 공유할 것입니다. TSC 회원은 각 회의를 시작할 때
+원하는 의제를 추가할 수 있습니다. 중재자와 TSC는 의제를 거부하거나 제거할 수 없습니다.
+
+<!--
+The TSC may invite persons or representatives from certain projects to
+participate in a non-voting capacity. These invitees currently are:
+
+* A representative from [build](https://github.com/node-forward/build)
+  chosen by that project.
+
+The moderator is responsible for summarizing the discussion of each
+agenda item and sending it as a pull request after the meeting.
+-->
+TSC는 특정 프로젝트의 사람들이나 대표자가 투표권 없이 회의에 참여하도록 초대할 수 있습니다. 현재 이렇게 초대된 사람은 다음과 같습니다.
+
+* [build](https://github.com/node-forward/build) 프로젝트에서 선택된 대표자
+
+중재자는 각 의제를 논의한 내용을 요약하고 미팅 후에 풀 리퀘스트로 보낼 책임이 있습니다.
+
+<!--
+## Consensus Seeking Process
+
+The TSC follows a
+[Consensus Seeking](http://en.wikipedia.org/wiki/Consensus-seeking_decision-making)
+decision making model.
+
+When an agenda item has appeared to reach a consensus, the moderator
+will ask "Does anyone object?" as a final call for dissent from the
+consensus.
+
+If an agenda item cannot reach a consensus, a TSC member can call for
+either a closing vote or a vote to table the issue to the next
+meeting. The call for a vote must be approved by a majority of the TSC
+or else the discussion will continue. Simple majority wins.
+-->
+## 합의점을 찾는 과정
+
+TSC는 [합의점 찾기](http://en.wikipedia.org/wiki/Consensus-seeking_decision-making) 의사결정 모델을 따릅니다.
+
+의제가 합의점을 찾았을 때 중재자는 합의점에 대한 반대의견을 받기 위한 마지막 요청으로 "반대하는 사람 있습니까?"라고 물을 것입니다.
+
+의제가 합의점에 이르지 못한다면 TSC 멤버는 투표를 종료하거나 다음 회의에 이슈를 올리도록 하는 투표를 요청할 수 있습니다. 투표요청은 반드시 TSC의 과반수가 동의해야 하고 그렇지 않으면 논의를 계속할 것입니다. 간단히 과반수가 이깁니다.
diff --git a/locale/ko/about/index.md b/locale/ko/about/index.md
new file mode 100644
index 0000000000000..97ccd380942b6
--- /dev/null
+++ b/locale/ko/about/index.md
@@ -0,0 +1,115 @@
+---
+layout: about.hbs
+title: About
+trademark: 트레이드마크
+---
+# Node.js&reg;에 대해서
+
+<!--
+As an asynchronous event driven JavaScript runtime, Node is designed to build
+scalable network applications. In the following "hello world" example, many
+connections can be handled concurrently. Upon each connection the callback is
+fired, but if there is no work to be done Node is sleeping.
+-->
+
+비동기 이벤트 주도 JavaScript 런타임으로써 Node는 확장성 있는 네트워크 애플리케이션을 만들 수 있도록
+설계되었습니다. 다음 "hello world" 예제는 다수의 연결을 동시에 처리할 수 있습니다.
+각 연결에서 콜백이 실행되는데 실행할 작업이 없다면 Node는 대기합니다.
+
+```javascript
+const http = require('http');
+
+const hostname = '127.0.0.1';
+const port = 3000;
+
+const server = http.createServer((req, res) => {
+  res.statusCode = 200;
+  res.setHeader('Content-Type', 'text/plain');
+  res.end('Hello World\n');
+});
+
+server.listen(port, hostname, () => {
+  console.log(`Server running at http://${hostname}:${port}/`);
+});
+```
+
+<!--
+This is in contrast to today's more common concurrency model where OS threads
+are employed. Thread-based networking is relatively inefficient and very
+difficult to use. Furthermore, users of Node are free from worries of
+dead-locking the process, since there are no locks. Almost no function in Node
+directly performs I/O, so the process never blocks. Because nothing blocks,
+scalable systems are very reasonable to develop in Node.
+-->
+이는 오늘날 OS 스레드가 일반적으로 사용하는 동시성 모델과는 대조적입니다. 스레드 기반의 네트워크는
+상대적으로 비효율적이고 사용하기가 몹시 어렵습니다. 게다가 잠금이 없으므로 Node의 사용자는 프로세스의
+교착상태에 대해서 걱정할 필요가 없습니다. Node에서 I/O를 직접 수행하는 함수는 거의 없으므로 프로세스는
+결과 블로킹 되지 않습니다. 아무것도 블로킹 되지 않으므로 Node에서는 확장성 있는 시스템을 개발하는 게
+아주 자연스럽습니다.
+
+<!--
+If some of this language is unfamiliar, there is a full article on
+[Blocking vs Non-Blocking][].
+
+---
+-->
+여기서 나오는 용어가 익숙하지 않다면 [블로킹 대 논-블로킹][]에 대한 글을 읽어보세요.
+
+---
+
+<!--
+Node is similar in design to, and influenced by, systems like Ruby's
+[Event Machine][] or Python's [Twisted][]. Node takes the event model a bit
+further, it presents an [event loop][] as a runtime construct instead of as a library. In other systems there is always a blocking call to start the
+event-loop.
+Typically behavior is defined through callbacks at the beginning of a script
+and at the end starts a server through a blocking call like
+`EventMachine::run()`. In Node there is no such start-the-event-loop call. Node
+simply enters the event loop after executing the input script. Node exits the
+event loop when there are no more callbacks to perform. This behavior is like
+browser JavaScript — the event loop is hidden from the user.
+-->
+Node는 Ruby의 [Event Machine][]이나 Python의 [Twisted][]같은 시스템과 설계상 유사하고
+영향을 받았습니다. Node는 좀 더 발전된 이벤트 모델을 선택해서 라이브러리가 아닌 런타임 생성자로
+[event loop][]를 제공합니다. 다른 시스템에서는 이벤트 루프를 시작하는 블럭킹 호출이 항상 존재합니다.
+
+보통은 스크립트의 시작 부분에서 콜백을 통해서 동작을 정의하고 마지막에서 `EventMachine::run()`같은
+블로킹 호출로 서버를 시작합니다. Node에서는 이와 같은 이벤트 루프를 시작하는 호출이 없습니다. Node는
+입력 스크립트를 실행한 후에 이벤트 루프에 바로 진입합니다. 더이상 실행할 콜백이 없다면 Node는
+이벤트 루프를 종료합니다. 이 동작은 브라우저 JavaScript과 같이 사용자에게서 이벤트 루프를 감춥니다.
+
+<!--
+HTTP is a first class citizen in Node, designed with streaming and low latency
+in mind. This makes Node well suited for the foundation of a web library or
+framework.
+
+Just because Node is designed without threads, doesn't mean you cannot take
+advantage of multiple cores in your environment. Child processes can be spawned
+by using our [`child_process.fork()`][] API, and are designed to be easy to
+communicate with. Built upon that same interface is the [`cluster`][] module,
+which allows you to share sockets between processes to enable load balancing
+over your cores.
+-->
+Node에서 HTTP는 일급 시민(first class citizen)이고 스트리밍과 저지연은 염두에 두고
+설계되었습니다. 이는 Node가 웹 라이브러리나 프레임워크의 기반으로 아주 적합하게 하였습니다.
+
+Node는 스레드를 사용하지 않도록 설계되지만 멀티 코어 환경의 장점을 얻지 못한다는 의미는 아닙니다.
+[`child_process.fork()`][] API를 사용해서 자식 프로세스를 생성할 수 있습니다. 같은 인터페이스로
+만들어진 [`cluster`][]을 사용하면 다수의 코어에 로드 밸런싱이 가능하도록 프로세스 간에
+소켓을 공유할 수 있습니다.
+
+<!--
+[Blocking vs Non-Blocking]: https://github.com/nodejs/node/blob/master/doc/topics/blocking-vs-non-blocking.md
+[`child_process.fork()`]: https://nodejs.org/api/child_process.html#child_process_child_process_fork_modulepath_args_options
+[`cluster`]: https://nodejs.org/api/cluster.html
+[event loop]: https://github.com/nodejs/node/blob/master/doc/topics/the-event-loop-timers-and-nexttick.md
+[Event Machine]: http://rubyeventmachine.com/
+[Twisted]: http://twistedmatrix.com/
+-->
+
+[Blocking vs Non-Blocking]: https://github.com/nodejs/node/blob/master/doc/topics/blocking-vs-non-blocking.md
+[`child_process.fork()`]: https://nodejs.org/api/child_process.html#child_process_child_process_fork_modulepath_args_options
+[`cluster`]: https://nodejs.org/api/cluster.html
+[event loop]: https://github.com/nodejs/node/blob/master/doc/topics/the-event-loop-timers-and-nexttick.md
+[Event Machine]: http://rubyeventmachine.com/
+[Twisted]: http://twistedmatrix.com/
diff --git a/locale/ko/about/releases.md b/locale/ko/about/releases.md
new file mode 100644
index 0000000000000..2b0d1070f6b8a
--- /dev/null
+++ b/locale/ko/about/releases.md
@@ -0,0 +1,165 @@
+---
+layout: about.hbs
+title: 릴리스
+---
+<!--
+# Releases
+
+The core team defines the roadmap's scope, as informed by Node.js' community.
+Releases happen as often as necessary and practical, but never before work is
+complete. Bugs are unavoidable, but pressure to ship a release will never
+prevail over ensuring the software is correct. The commitment to quality
+software is a core tenet of the Node.js project.
+-->
+# 릴리스
+
+Node.js 커뮤니티가 알고 있듯이 코어 팀은 로드맵의 범위를 정의합니다. 필요하고 실용적이라면 최대한
+자주 릴리스를 하지만 작업이 완료되지 않으면 하지 않습니다. 버그는 보이지 않을 수 있지만, 릴리스에 대한
+압박은 소프트웨어가 제대로 되었다고 확신을 넘어설 수 없습니다.
+소프트웨어의 질에 대한 책임은 Node.js 프로젝트의 핵심 신조입니다.
+
+<!--
+## Patches
+
+Patch releases:
+
+- Include bug, performance, and security fixes.
+- Do not add nor change public interfaces.
+- Do not alter the expected behavior of a given interface.
+- Can correct behavior if it is out-of-sync with the documentation.
+- Do not introduce changes which make seamless upgrades impossible .
+-->
+
+## 패치
+
+패치 릴리스는
+
+- 버그, 성능, 보안 수정을 포함합니다.
+- 공개 인터페이스를 추가하거나 변경하지 않습니다.
+- 제공한 인터페이스에서 기대되는 동작을 변경하지 않습니다.
+- 문서와 일치하지 않다면 제대로 동작하도록 할 수 있습니다.
+- 자연스럽게 업그레이드할 수 없는 변경사항을 추가하지 않습니다.
+
+<!--
+## Minors
+
+Minor releases:
+
+- Include additions and/or refinements of APIs and subsystems.
+- Do not generally change APIs nor introduce backwards-incompatible breaking
+changes, except where unavoidable.
+- Are mostly additive releases.
+-->
+
+## 마이너
+
+마이너 릴리스는
+
+- API와 서브시스템의 추가나 개선을 포함합니다.
+- 보통 API를 변경하지 않고 불가피하지 않은 경우를 제외하고는 하위호환성을 깨뜨리는 변경사항을 추가하지 않습니다.
+- 대부분 부가적인 릴리스입니다.
+
+<!--
+## Majors
+
+Major releases:
+
+- Usually introduce backwards-incompatible, breaking changes.
+- Identify the API Node.js intends to support for the foreseeable future.
+- Require conversation, care, collaboration and appropriate scoping by the team
+and its users.
+-->
+
+## 메이저
+
+메이저 릴리스는
+
+- 보통 하위호환성을 깨뜨리는 변경사항을 추가합니다.
+- Node.js가 예견할 수 있는 미래를 준비할 수 있도록 API를 식별합니다.
+- 코어 팀과 사용자들의 대화, 관심, 협업, 적당한 범위 설정이 필요합니다.
+
+<!--
+## Scoping Features
+
+The team can add features and APIs into Node.js when:
+
+- The need is clear.
+- The API or feature has known consumers.
+- The API is clean, useful, and easy-to use.
+
+If when implementing core functionality for Node.js, the team or community may
+identify another lower-level API which could have utility beyond Node.js. When
+identified, Node.js can expose it for consumers.
+-->
+
+## 기능의 범위 정하기
+
+코어 팀은 다음에서 Node.js에 기능이나 API를 추가할 수 있습니다.
+
+- 요구사항이 확실할 때
+- API나 기능이 알려진 사용자를 가질 때
+- API가 깔끔하고 유용하면서 사용하기 쉬울 때
+
+<!--
+For example, consider the [`EventEmitter`] interface.  The need to have an event
+subscription model for core modules to consume was clear, and that abstraction
+had utility beyond the Node.js core.  It was not the case that its interface
+couldn't be implemented externally to Node.js; instead, Node.js needed the
+abstraction for itself, and also exposed it for use by Node.js consumers.
+
+Alternatively, it may be that many in the community adopt a pattern to handle
+common needs which Node.js does not satisfy.  It may be clear that Node.js
+should deliver, by default, an API or feature for all Node.js consumers.
+Another possibility is a commonly-used compiled asset which is difficult to
+deliver across environments.  Given this, Node.js may incorporate those changes
+directly.
+
+The core team does not take the decision lightly to add a new API to Node.js.
+Node.js has a strong commitment to backwards compatibility. As such, community
+input and conversation must occur before the team takes action. Even if an API
+is otherwise suitable for addition, the team must identify potential consumers.
+-->
+예를 들어, [`EventEmitter`] 인터페이스를 생각해 보겠습니다. 코어 모듈에서 사용할 수 있는
+이벤트 구독 모델이 필요하다는 것은 했고 이 추상화는 Node.js 코어의 범위를 벗어나는 유틸리티를 가집니다.
+이는 이 추상화의 인터페이스가 Node.js 외부에서 구현될 수 없는 경우가 아닙니다. 오히려 Node.js가
+직접 추상화할 필요가 있었고 Node.js 사용자가 사용할 수 있도록 이를 노출해야 했습니다.
+
+아니면 Node.js가 만족하게 하지 못하는 일반적인 요구사항을 해결하는 패턴을 커뮤니티의 다수가 도입할
+수도 있습니다. Node.js가 모든 Node.js 사용자를 위한 API나 기능을 기본적으로 제공하는 것이
+더 명확할 수도 있습니다. 여러 환경을 지원하기 어렵지만, 일반적으로 사용되는 에셋을 컴파일해서 제공하는
+것도 가능합니다. 이러한 상황을 고려하면 Node.js가 직접 이러한 변경사항을 받아들여야 할 수도 있습니다.
+
+코어 팀은 새로운 API를 Node.js에 추가할 때 가볍게 결정하지 않습니다. Node.js는 하위호환성을
+지원해야 하는 큰 의무가 있습니다. 그래서 코어 팀이 행동을 취하기 전에 커뮤니티의 요청이나 토론이
+반드시 먼저 일어나게 됩니다. API를 추가하는 것이 적합한 경우조차도 코어 팀은 잠재적인 사용자를
+확인해야 합니다.
+
+<!--
+## Deprecation
+
+On occasion, the team must deprecate a feature or API of Node.js. Before coming
+to any final conclusion, the team must identify the consumers of the API and how
+they use it.  Some questions to ask are:
+
+- If this API is widely used by the community, what is the need for flagging it
+as deprecated?
+- Do we have a replacement API, or is there a transitionary path?
+- How long does the API remain deprecated before removal?
+- Does an external module exist which its consumers can easily substitute?
+
+The team takes the same careful consideration when deprecating a Node.js API as
+they do when adding another.
+
+[`EventEmitter`]: https://nodejs.org/api/events.html#events_class_eventemitter
+-->
+
+## 폐기 예정
+
+때때로 코어 팀은 Node.js의 기능이나 API를 폐기해야 합니다. 최종 결정을 하기 전에 코어 팀은 API의 사용자와 이들이 그 API를 어떻게 사용하고 있는지를 반드시 확인해야 합니다. 이때 다음과 같은 질문을 해봐야 합니다.
+
+- 커뮤니티에서 이 API를 광범위하게 사용하고 있다면 폐기 예정으로 표시하는 데 필요한 일은 어떤 것인가?
+- 대체 API가 있는가? 아니면 과도기적인 경로가 존재하는가?
+- API를 제거하기 전에 폐기 예정을 얼마나 오랫동안 유지해야 하는가?
+- 그 API의 사용자가 쉽게 대체할 수 있는 외부 모듈이 존재하는가?
+
+코어 팀은 Node.js API를 폐기할 때 API를 추가할 때와 마찬가지로 신중하게 고려합니다.
diff --git a/locale/ko/about/resources.md b/locale/ko/about/resources.md
new file mode 100644
index 0000000000000..9b93b204624fa
--- /dev/null
+++ b/locale/ko/about/resources.md
@@ -0,0 +1,79 @@
+---
+layout: about.hbs
+title: 로고와 그래픽
+---
+
+<!--
+# Resources
+
+## Logo Downloads
+
+ Please review the [trademark policy](/about/trademark/) for information about permissible use of Node.js&reg; logos and marks.
+
+ Guidelines for the visual display of the Node.js mark are described in
+ the [Visual Guidelines](/static/documents/foundation-visual-guidelines.pdf).
+-->
+
+# 관련 자료
+
+## 로고 다운로드
+
+Node.js&reg; 로고와 마크를 사용할 수 있는 경우에 대한 정보는 [상표 정책](/about/trademark/)을
+확인해보기 바랍니다.
+
+Node.js의 시각적인 가이드라인은
+[시각적 가이드라인](/static/documents/foundation-visual-guidelines.pdf)에 나와 있습니다.
+
+<!--
+<table border="0" cellspacing="0" cellpadding="10" class="logos">
+  <tr>
+    <td bgcolor="#FFFFFF">[![Node.js on light background](/static/images/logos/nodejs-new-pantone-black.png)](/static/images/logos/nodejs-new-pantone-black.ai)</td>
+    <td bgcolor="#333333">[![Node.js on dark background](/static/images/logos/nodejs-new-pantone-white.png)](/static/images/logos/nodejs-new-pantone-white.ai)</td>
+  </tr>
+  <tr>
+    <td>[Node.js standard AI](/static/images/logos/nodejs-new-pantone-black.ai)</td>
+    <td>[Node.js reversed AI](/static/images/logos/nodejs-new-pantone-white.ai)</td>
+  </tr>
+  <tr>
+    <td bgcolor="#FFFFFF">[![Node.js on light background](/static/images/logos/nodejs-new-black.png)](/static/images/logos/nodejs-new-black.ai)</td>
+    <td bgcolor="#333333">[![Node.js on dark background](/static/images/logos/nodejs-new-white.png)](/static/images/logos/nodejs-new-white.ai)</td>
+  </tr>
+  <tr>
+    <td>[Node.js standard with less color AI](/static/images/logos/nodejs-new-black.ai)</td>
+    <td>[Node.js reversed with less color AI](/static/images/logos/nodejs-new-white.ai)</td>
+  </tr>
+</table>
+-->
+
+<table border="0" cellspacing="0" cellpadding="10" class="logos">
+  <tr>
+    <td bgcolor="#FFFFFF">[![밝은 배경의 Node.js](/static/images/logos/nodejs-new-pantone-black.png)](/static/images/logos/nodejs-new-pantone-black.ai)</td>
+    <td bgcolor="#333333">[![어두운 배경의 Node.js](/static/images/logos/nodejs-new-pantone-white.png)](/static/images/logos/nodejs-new-pantone-white.ai)</td>
+  </tr>
+  <tr>
+    <td>[Node.js 표준 AI](/static/images/logos/nodejs-new-pantone-black.ai)</td>
+    <td>[Node.js 반전 AI](/static/images/logos/nodejs-new-pantone-white.ai)</td>
+  </tr>
+  <tr>
+    <td bgcolor="#FFFFFF">[![밝은 배경의 Node.js](/static/images/logos/nodejs-new-black.png)](/static/images/logos/nodejs-new-black.ai)</td>
+    <td bgcolor="#333333">[![어두운 배경의 Node.js](/static/images/logos/nodejs-new-white.png)](/static/images/logos/nodejs-new-white.ai)</td>
+  </tr>
+  <tr>
+    <td>[적은 색상을 가진 Node.js 표준 AI](/static/images/logos/nodejs-new-black.ai)</td>
+    <td>[적은 색상을 가진 Node.js 반전 AI](/static/images/logos/nodejs-new-white.ai)</td>
+  </tr>
+</table>
+
+<!--
+## Desktop Background
+
+![Screensavers](/static/images/logos/monitor.png)
+
+Select your screen resolution: <span class="desktops">[1024 x 768](/static/images/logos/nodejs-1024x768.png)  | [1280 x 1024](/static/images/logos/nodejs-1280x1024.png) | [1440 x 900](/static/images/logos/nodejs-1440x900.png) | [1920 x 1200](/static/images/logos/nodejs-1920x1200.png) | [2560 x 1440](/static/images/logos/nodejs-2560x1440.png)</span>
+-->
+
+## 데스크톱 배경
+
+![스크린세이버](/static/images/logos/monitor.png)
+
+원화는 화면 해상도를 선택하세요. <span class="desktops">[1024 x 768](/static/images/logos/nodejs-1024x768.png)  | [1280 x 1024](/static/images/logos/nodejs-1280x1024.png) | [1440 x 900](/static/images/logos/nodejs-1440x900.png) | [1920 x 1200](/static/images/logos/nodejs-1920x1200.png) | [2560 x 1440](/static/images/logos/nodejs-2560x1440.png)</span>
diff --git a/locale/ko/about/trademark.md b/locale/ko/about/trademark.md
new file mode 100644
index 0000000000000..21f9f4a94b922
--- /dev/null
+++ b/locale/ko/about/trademark.md
@@ -0,0 +1,51 @@
+---
+layout: about.hbs
+title: 트레이드마크 정책
+---
+
+<!--
+# Trademark Policy
+-->
+# 트레이드마크 정책
+
+<!--
+The Node.js trademarks, service marks, and graphics marks are symbols of the
+quality, performance, and ease of use that people have come to associate with
+the Node.js software and project. To ensure that the Node.js marks continue to
+symbolize these qualities, we must ensure that the marks are only used in ways
+that do not mislead people or cause them to confuse Node.js with other software
+of lower quality. If we don’t ensure the marks are used in this way, it cannot
+only confuse users, it can make it impossible to use the mark to protect
+against people who maliciously exploit the mark in the future. The primary goal
+of this policy is to make sure that this doesn’t happen to the Node.js mark, so
+that the community and users of Node.js are always protected in the future.
+-->
+Node.js 트레이트마크, 서비스마크, 그래픽 마크는 Node.js 소프트웨어와 프로젝트와 연관있는 사람들의
+품질, 성능, 쉬운 사용법을 상징합니다. Node.js 마크가 이러한 품질을 의미할 수 있게 사람들이 저품질의
+다른 소프트웨어를 Node.js와 혼동하지 않도록 하는 방법으로만 사용해야 합니다. 이러한 방법으로 마크를
+사용하지 않는다면 사용자가 혼란스러울 뿐만 아니라 미래에 악의적으로 마크를 사용하는 사람들한테서 마크를
+보호할 수도 없습니다. 이 정책의 주요 목적은 이러한 일이 Node.js 마크에서 일어나지 않도록 해서
+Node.js 커뮤니티와 사용자가 항상 보호받을 수 있게 하는 것입니다.
+
+<!--
+At the same time, we’d like community members to feel comfortable spreading the
+word about Node.js and participating in the Node.js community. Keeping that
+goal in mind, we’ve tried to make the policy as flexible and easy to understand
+as legally possible.
+
+Please read the [full policy](/static/documents/trademark-policy.pdf).
+If you have any questions don't hesistate to
+[email us](mailto:trademark@nodejs.org).
+
+Guidelines for the visual display of the Node.js mark are described in
+the [Visual Guidelines](/static/documents/foundation-visual-guidelines.pdf).
+-->
+
+동시에 커뮤니티 회원이 편안하게 Node.js라는 말을 퍼트리고 Node.js 커뮤니티에 참여하기를 원합니다.
+이 목표를 유지한 채 법적으로 가능한 한 유연하고 이해하기 쉽게 정책을 만들고 있습니다.
+
+[전체 정책](/static/documents/trademark-policy.pdf)을 읽어보세요.
+질문이 있다면 주저하지 말고 [이메일](mailto:trademark@nodejs.org)을 보내주세요.
+
+Node.js 마크에 대한 시각적 가이드라인은
+[시각적 가이드라인](/static/documents/foundation-visual-guidelines.pdf)에 잘 나와 있습니다.
diff --git a/locale/ko/about/working-groups.md b/locale/ko/about/working-groups.md
new file mode 100644
index 0000000000000..23d7dae77efc5
--- /dev/null
+++ b/locale/ko/about/working-groups.md
@@ -0,0 +1,653 @@
+---
+layout: about.hbs
+title: 워킹 그룹
+---
+<!--
+# Working Groups
+There are 2 types of Working Groups:
+* [Top-Level Working Groups](#top-level-working-groups)
+* [Core Working Groups](#core-working-groups)
+-->
+
+# 워킹 그룹
+2가지 종류의 워킹 그룹이 있습니다.
+* [최상위 워킹 그룹](#top-level-working-groups)
+* [핵심 워킹 그룹](#core-working-groups)
+
+<!--
+## Top-Level Working Groups
+-->
+<!-- Information here should mostly mirror: https://github.com/nodejs/TSC/blob/master/WORKING_GROUPS.md -->
+
+## 최상위 워킹 그룹
+
+<!--
+Top-Level Working Groups are created by the
+[Technical Steering Committee (TSC)](https://github.com/nodejs/TSC#top-level-wgs-and-tlps).
+-->
+최상위 워킹 그룹은 [기술 결정 위원회(TSC)](https://github.com/nodejs/TSC#top-level-wgs-and-tlps)에서 만듭니다.
+
+<!--
+### Current Top-Level Working Groups
+* [Inclusivity](#inclusivity)
+-->
+
+### 현재의 최상위 워킹 그룹
+* [Inclusivity](#inclusivity)
+
+<!--
+#### [Inclusivity](https://github.com/nodejs/inclusivity)
+The Inclusivity Working Group seeks to increase inclusivity and diversity for
+the Node.js project:
+-->
+
+#### [Inclusivity](https://github.com/nodejs/inclusivity)
+Inclusivity 워킹 그룹은 Node.js 프로젝트의 포괄성과 다양성을 높이는 작업을 합니다.
+
+<!--
+* Increasing inclusivity means making the Node.js project a safe and friendly
+place for people from diverse backgrounds.
+* Increasing diversity means actively onboarding people from diverse backgrounds
+to the Node.js project and maintaining their participation.
+-->
+
+* 포괄성을 높인다는 것은 다양한 배경을 가진 사람들한테 Node.js 프로젝트를 안전하고 친숙한 곳으로
+  만든다는 것을 의미합니다.
+* 다양성을 높인다는 것은 다양한 배경을 가진 사람들이 활발하게 Node.js 프로젝트에 합류하고
+  이들의 참여를 관리하는 것을 의미합니다.
+
+<!--
+Its responsibilites are:
+* Foster a welcoming environment that ensures participants are valued and can
+feel confident contributing or joining discussions, regardless of any [aspect of
+their identity](https://github.com/nodejs/inclusivity/#list-of-responsibilities).
+* Proactively seek and propose concrete steps the project can take to increase
+inclusivity.
+* Serve as a resource for the development and enforcement of workflows that
+protect community members and projects from harassment and abuse.
+* Acknowledge and celebrate existing diversity accomplishments within the project
+while seeking to build upon them.
+* Identify ways to measure diversity and inclusivity within the project and report
+them at regular intervals.
+-->
+이 워킹 그룹은 다음에 대한 책임이 있습니다.
+
+* [신분에 따른 관점](https://github.com/nodejs/inclusivity/#list-of-responsibilities)에
+  상관없이 참여의 가치를 인정하고 자신 있게 기여하고 논의에 참여할 수 있도록 환영하는 환경을 추구합니다.
+* 프로젝트 포괄성을 키울 수 있는 확실한 방법을 적극적으로 찾고 제안합니다.
+* 희롱이나 욕설에서 커뮤니티 멤버와 프로젝트를 보호하는 작업 흐름의 개발과 시행에 대한 리소스로서
+  제공합니다.
+* 프로젝트 내에 다양성을 이룬 것을 인정하고 축하하면서 이 다양성 위에서 방법을 모색합니다.
+* 프로젝트 내의 다양성과 포괄성을 평가하고 이를 정기적으로 보고하는 방법을 결정합니다.
+
+<!--
+# Core Working Groups
+-->
+<!-- Information here should mostly mirror: https://github.com/nodejs/node/blob/master/WORKING_GROUPS.md -->
+
+# 핵심 워킹 그룹
+
+<!--
+Core Working Groups are created by the
+[Core Technical Committee (CTC)](https://github.com/nodejs/node/blob/master/GOVERNANCE.md#core-technical-committee).
+-->
+핵심 워킹 그룹은
+[핵심 기술 위원회 (CTC, Core Technical Committee)](https://github.com/nodejs/node/blob/master/GOVERNANCE.md#core-technical-committee)에서
+만듭니다.
+
+<!--
+## Current Working Groups
+
+* [Website](#website)
+* [Streams](#streams)
+* [Build](#build)
+* [Tracing](#tracing)
+* [i18n](#i18n)
+* [Evangelism](#evangelism)
+* [Roadmap](#roadmap)
+* [Docker](#docker)
+* [Addon API](#addon-api)
+* [Benchmarking](#benchmarking)
+* [Post-mortem](#post-mortem)
+* [Intl](#intl)
+* [HTTP](#http)
+* [Documentation](#documentation)
+* [Testing](#testing)
+-->
+
+## 현재의 워킹 그룹
+
+* [Website](#website)
+* [Streams](#streams)
+* [Build](#build)
+* [Tracing](#tracing)
+* [i18n](#i18n)
+* [Evangelism](#evangelism)
+* [Roadmap](#roadmap)
+* [Docker](#docker)
+* [Addon API](#addon-api)
+* [Benchmarking](#benchmarking)
+* [Post-mortem](#post-mortem)
+* [Intl](#intl)
+* [HTTP](#http)
+* [Documentation](#documentation)
+* [Testing](#testing)
+
+<!--
+### [Website](https://github.com/nodejs/nodejs.org)
+
+The website working group's purpose is to build and maintain a public
+website for the `Node.js` project.
+
+Its responsibilities are:
+* Develop and maintain a build and automation system for `nodejs.org`.
+* Ensure the site is regularly updated with changes made to `Node.js` like
+releases and features.
+* Foster and enable a community of translators.
+-->
+
+### [Website](https://github.com/nodejs/nodejs.org)
+
+웹사이트 워킹그룹의 목적은 `Node.js` 프로젝트의 공개 웹사이트를 만들고 관리하는 것입니다.
+
+이는 다음에 대한 책임이 있습니다.
+
+* `nodejs.org`의 빌드와 자동화 시스템을 개발하고 유지 보수합니다.
+* 릴리스와 기능처럼 `Node.js`에 변경된 내용을 정기적으로 사이트에 갱신합니다.
+* 번역 커뮤니티를 지원합니다.
+
+<!--
+### [Streams](https://github.com/nodejs/readable-stream)
+
+The Streams WG is dedicated to the support and improvement of the Streams API
+as used in Node.js and the npm ecosystem. We seek to create a composable API that
+solves the problem of representing multiple occurrences of an event over time
+in a humane, low-overhead fashion. Improvements to the API will be driven by
+the needs of the ecosystem; interoperability and backwards compatibility with
+other solutions and prior versions are paramount in importance. Our
+responsibilities include:
+
+* Addressing stream issues on the Node.js issue tracker.
+* Authoring and editing stream documentation within the Node.js project.
+* Reviewing changes to stream subclasses within the Node.js project.
+* Redirecting changes to streams from the Node.js project to this project.
+* Assisting in the implementation of stream providers within Node.js.
+* Recommending versions of readable-stream to be included in Node.js.
+* Messaging about the future of streams to give the community advance notice of changes.
+-->
+
+### [Streams](https://github.com/nodejs/readable-stream)
+
+스트림 워킹 그룹은 Node.js와 npm 생태계에서 사용하는 Streams API를 지원하고 개선합니다.
+오랜 시간 동안 여러 번 나타나는 문제를 어렵지 않은 방법으로 해결하는 API를 조합 가능하게 만들고
+있습니다. 생태계에 요구사항에 따라 API를 개선할 것입니다. 다른 솔루션과의 상호운용성과 하위 호환성 및
+이전 버전이 가장 중요합니다. 이 워킹 그룹은 다음에 대한 책임이 있습니다.
+
+* Node.js 이슈 트래커에서 스트림 관련 이슈를 처리합니다.
+* Node.js 프로젝트 내 스트림 문서를 작성하고 수정합니다.
+* Node.js 프로젝트 내 스트림 하위 클래스의 변경사항을 리뷰합니다.
+* 스트림 변경사항을 Node.js 프로젝트에서 이 프로젝트로 리다이렉트합니다.
+* Node.js 내 스트림 프로바이더의 구현체를 지원합니다.
+* 읽기 가능한 스트림의 버전이 Node.js에 포함되도록 권장합니다.
+* 차후 스트림의 변경사항을 커뮤니티에 알립니다.
+
+<!--
+### [Build](https://github.com/nodejs/build)
+
+The build working group's purpose is to create and maintain a
+distributed automation infrastructure.
+
+Its responsibilities are:
+* Produce Packages for all target platforms.
+* Run tests.
+* Run performance testing and comparisons.
+* Creates and manages build-containers.
+-->
+
+### [Build](https://github.com/nodejs/build)
+
+빌드 워킹 그룹의 목적은 분산 자동화 인프라스트럭처를 만들고 유지 보수하는 것입니다.
+
+이 워킹 그룹은 다음에 대한 책임이 있습니다.
+
+* 모든 대상 플랫폼에서 패키지를 만듭니다.
+* 테스트를 수행합니다.
+* 성능테스트를 수행하고 비교합니다.
+* 빌드 컨테이너를 생성하고 관리합니다.
+
+<!--
+### [Tracing](https://github.com/nodejs/tracing-wg)
+
+The tracing working group's purpose is to increase the
+transparency of software written in Node.js.
+
+Its responsibilities are:
+* Collaboration with V8 to integrate with `trace_event`.
+* Maintenance and iteration on AsyncWrap.
+* Maintenance and improvements to system tracing support (DTrace, LTTng, etc.)
+* Documentation of tracing and debugging techniques.
+* Fostering a tracing and debugging ecosystem.
+-->
+
+### [Tracing](https://github.com/nodejs/tracing-wg)
+
+트레이싱 워킹 그룹의 목적은 Node.js로 작성된 소프트웨어의 투명성을 증가시키는 것입니다.
+
+이 워킹 그룹은 다음에 대한 책임이 있습니다.
+
+* `trace_event`를 통합하기 위해 V8과 협업합니다.
+* AsyncWrap을 유지보수하고 반복합니다.
+* 시스템의 추적 도구를 관리하고 개선합니다.(DTrace, LTTng 등)
+* 추적과 디버깅 기법을 문서로 만듭니다.
+* 추적 및 디버깅 생태계를 육성합니다.
+
+<!--
+### i18n
+
+The i18n working groups handle more than just translations. They
+are endpoints for community members to collaborate with each
+other in their language of choice.
+
+Each team is organized around a common spoken language. Each
+language community might then produce multiple localizations for
+various project resources.
+-->
+
+### i18n
+
+i18n 워킹 그룹은 단순 번역 이상의 작업을 수행합니다. 이 워킹 그룹은 커뮤니티 회원들이 각자의 언어로
+협업할 수 있도록 하는 종점입니다.
+
+각 팀은 공통으로 말하는 언어를 중심으로 조직되어 있습니다. 각 언어 커뮤니티는
+다양한 프로젝트의 자원을 지역화할 것입니다.
+
+<!--
+Their responsibilities are:
+* Translations of any Node.js materials they believe are relevant to their
+community.
+* Review processes for keeping translations up
+to date and of high quality.
+* Social media channels in their language.
+* Promotion of Node.js speakers for meetups and conferences in their
+language.
+-->
+
+이 워킹 그룹은 다음에 대한 책임이 있습니다.
+
+* 커뮤니티와 연관있는 Node.js 자료를 모두 번역합니다.
+* 높은 품질로 번역하고 번역된 내용이 최신화되도록 번역 과정을 검토합니다.
+* 언어별 소셜 미디어 채널을 관리합니다.
+* 언어별 밋업 및 콘퍼런스의 node.js 발표자를 추천합니다.
+
+<!--
+Note that the i18n working groups are distinct from the [Intl](#Intl) working group.
+
+Each language community maintains its own membership.
+
+* [nodejs-ar - Arabic (اللغة العربية)](https://github.com/nodejs/nodejs-ar)
+* [nodejs-bg - Bulgarian (български език)](https://github.com/nodejs/nodejs-bg)
+* [nodejs-bn - Bengali (বাংলা)](https://github.com/nodejs/nodejs-bn)
+* [nodejs-zh-CN - Chinese (中文)](https://github.com/nodejs/nodejs-zh-CN)
+* [nodejs-cs - Czech (Český Jazyk)](https://github.com/nodejs/nodejs-cs)
+* [nodejs-da - Danish (Dansk)](https://github.com/nodejs/nodejs-da)
+* [nodejs-de - German (Deutsch)](https://github.com/nodejs/nodejs-de)
+* [nodejs-el - Greek (Ελληνικά)](https://github.com/nodejs/nodejs-el)
+* [nodejs-es - Spanish (Español)](https://github.com/nodejs/nodejs-es)
+* [nodejs-fa - Persian (فارسی)](https://github.com/nodejs/nodejs-fa)
+* [nodejs-fi - Finnish (Suomi)](https://github.com/nodejs/nodejs-fi)
+* [nodejs-fr - French (Français)](https://github.com/nodejs/nodejs-fr)
+* [nodejs-he - Hebrew (עברית)](https://github.com/nodejs/nodejs-he)
+* [nodejs-hi - Hindi (फिजी बात)](https://github.com/nodejs/nodejs-hi)
+* [nodejs-hu - Hungarian (Magyar)](https://github.com/nodejs/nodejs-hu)
+* [nodejs-id - Indonesian (Bahasa Indonesia)](https://github.com/nodejs/nodejs-id)
+* [nodejs-it - Italian (Italiano)](https://github.com/nodejs/nodejs-it)
+* [nodejs-ja - Japanese (日本語)](https://github.com/nodejs/nodejs-ja)
+* [nodejs-ka - Georgian (ქართული)](https://github.com/nodejs/nodejs-ka)
+* [nodejs-ko - Korean (한국어)](https://github.com/nodejs/nodejs-ko)
+* [nodejs-mk - Macedonian (Mакедонски)](https://github.com/nodejs/nodejs-mk)
+* [nodejs-ms - Malay (بهاس ملايو)](https://github.com/nodejs/nodejs-ms)
+* [nodejs-nl - Dutch (Nederlands)](https://github.com/nodejs/nodejs-nl)
+* [nodejs-no - Norwegian (Norsk)](https://github.com/nodejs/nodejs-no)
+* [nodejs-pl - Polish (Język Polski)](https://github.com/nodejs/nodejs-pl)
+* [nodejs-pt - Portuguese (Português)](https://github.com/nodejs/nodejs-pt)
+* [nodejs-ro - Romanian (Română)](https://github.com/nodejs/nodejs-ro)
+* [nodejs-ru - Russian (Русский)](https://github.com/nodejs/nodejs-ru)
+* [nodejs-sv - Swedish (Svenska)](https://github.com/nodejs/nodejs-sv)
+* [nodejs-ta - Tamil (தமிழ்)](https://github.com/nodejs/nodejs-ta)
+* [nodejs-tr - Turkish (Türkçe)](https://github.com/nodejs/nodejs-tr)
+* [nodejs-zh-TW - Taiwanese (Hō-ló)](https://github.com/nodejs/nodejs-zh-TW)
+* [nodejs-uk - Ukrainian (Українська)](https://github.com/nodejs/nodejs-uk)
+* [nodejs-vi - Vietnamese (Tiếng Việtnam)](https://github.com/nodejs/nodejs-vi)
+-->
+
+i18n 워킹 그룹은 [Intl](#Intl) 워킹 그룹과는 다릅니다.
+
+언어별 커뮤니티는 개별 권한을 가지고 운영되고 있습니다.
+
+* [nodejs-ar - Arabic (اللغة العربية)](https://github.com/nodejs/nodejs-ar)
+* [nodejs-bg - Bulgarian (български език)](https://github.com/nodejs/nodejs-bg)
+* [nodejs-bn - Bengali (বাংলা)](https://github.com/nodejs/nodejs-bn)
+* [nodejs-zh-CN - Chinese (中文)](https://github.com/nodejs/nodejs-zh-CN)
+* [nodejs-cs - Czech (Český Jazyk)](https://github.com/nodejs/nodejs-cs)
+* [nodejs-da - Danish (Dansk)](https://github.com/nodejs/nodejs-da)
+* [nodejs-de - German (Deutsch)](https://github.com/nodejs/nodejs-de)
+* [nodejs-el - Greek (Ελληνικά)](https://github.com/nodejs/nodejs-el)
+* [nodejs-es - Spanish (Español)](https://github.com/nodejs/nodejs-es)
+* [nodejs-fa - Persian (فارسی)](https://github.com/nodejs/nodejs-fa)
+* [nodejs-fi - Finnish (Suomi)](https://github.com/nodejs/nodejs-fi)
+* [nodejs-fr - French (Français)](https://github.com/nodejs/nodejs-fr)
+* [nodejs-he - Hebrew (עברית)](https://github.com/nodejs/nodejs-he)
+* [nodejs-hi - Hindi (फिजी बात)](https://github.com/nodejs/nodejs-hi)
+* [nodejs-hu - Hungarian (Magyar)](https://github.com/nodejs/nodejs-hu)
+* [nodejs-id - Indonesian (Bahasa Indonesia)](https://github.com/nodejs/nodejs-id)
+* [nodejs-it - Italian (Italiano)](https://github.com/nodejs/nodejs-it)
+* [nodejs-ja - Japanese (日本語)](https://github.com/nodejs/nodejs-ja)
+* [nodejs-ka - Georgian (ქართული)](https://github.com/nodejs/nodejs-ka)
+* [nodejs-ko - Korean (한국어)](https://github.com/nodejs/nodejs-ko)
+* [nodejs-mk - Macedonian (Mакедонски)](https://github.com/nodejs/nodejs-mk)
+* [nodejs-ms - Malay (بهاس ملايو)](https://github.com/nodejs/nodejs-ms)
+* [nodejs-nl - Dutch (Nederlands)](https://github.com/nodejs/nodejs-nl)
+* [nodejs-no - Norwegian (Norsk)](https://github.com/nodejs/nodejs-no)
+* [nodejs-pl - Polish (Język Polski)](https://github.com/nodejs/nodejs-pl)
+* [nodejs-pt - Portuguese (Português)](https://github.com/nodejs/nodejs-pt)
+* [nodejs-ro - Romanian (Română)](https://github.com/nodejs/nodejs-ro)
+* [nodejs-ru - Russian (Русский)](https://github.com/nodejs/nodejs-ru)
+* [nodejs-sv - Swedish (Svenska)](https://github.com/nodejs/nodejs-sv)
+* [nodejs-ta - Tamil (தமிழ்)](https://github.com/nodejs/nodejs-ta)
+* [nodejs-tr - Turkish (Türkçe)](https://github.com/nodejs/nodejs-tr)
+* [nodejs-zh-TW - Taiwanese (Hō-ló)](https://github.com/nodejs/nodejs-zh-TW)
+* [nodejs-uk - Ukrainian (Українська)](https://github.com/nodejs/nodejs-uk)
+* [nodejs-vi - Vietnamese (Tiếng Việtnam)](https://github.com/nodejs/nodejs-vi)
+
+<!--
+### [Intl](https://github.com/nodejs/Intl)
+
+The Intl Working Group is dedicated to support and improvement of
+Internationalization (i18n) and Localization (l10n) in Node. Its responsibilities are:
+
+1. Functionality & compliance (standards: ECMA, Unicode…)
+2. Support for Globalization and Internationalization issues that come up in the tracker
+3. Guidance and Best Practices
+4. Refinement of existing `Intl` implementation
+
+The Intl WG is not responsible for translation of content. That is the responsibility of the specific [i18n](#i18n) group for each language.
+-->
+
+### [Intl](https://github.com/nodejs/Intl)
+
+Intl 워킹 그룹은 Node의 국제화(i18n)와 지역화(l10n)을 지원하고 개선합니다.
+이 워킹 그룹은 다음에 대한 책임이 있습니다.
+
+1. 모든 기능과 표준 준수 (표준: ECMA, 유니코드...)
+2. 트래커에 올라온 세계화(Globalization)와 국제화(Internationalization) 이슈를 지원합니다.
+3. 가이드라인과 권장 사례를 만듭니다.
+4. 기존의 `Intl` 구현체를 정체합니다.
+
+<!--
+### [Evangelism](https://github.com/nodejs/evangelism)
+
+The evangelism working group promotes the accomplishments
+of Node.js and lets the community know how they can get involved.
+
+Their responsibilities are:
+* Project messaging.
+* Official project social media.
+* Promotion of speakers for meetups and conferences.
+* Promotion of community events.
+* Publishing regular update summaries and other promotional
+content.
+-->
+
+### [Evangelism](https://github.com/nodejs/evangelism)
+
+에반젤리즘 워킹 그룹은 Node.js의 성과를 홍보하고 커뮤니티가 참여하는 방법을 알립니다.
+
+이 워킹 그룹은 다음에 대한 책임이 있습니다.
+
+* 프로젝트 메시징
+* 공식 프로젝트 소셜 미디어
+* 밋업과 콘퍼런스의 발표자 추천
+* 커뮤니티 이벤트의 홍보
+* 정기적인 수정사항 요약과 다른 홍보 내용의 발행
+
+<!--
+### [HTTP](https://github.com/nodejs/http)
+
+The HTTP working group is chartered for the support and improvement of the
+HTTP implementation in Node. It's responsibilities are:
+
+* Addressing HTTP issues on the Node.js issue tracker.
+* Authoring and editing HTTP documentation within the Node.js project.
+* Reviewing changes to HTTP functionality within the Node.js project.
+* Working with the ecosystem of HTTP related module developers to evolve the
+  HTTP implementation and APIs in core.
+* Advising the CTC on all HTTP related issues and discussions.
+* Messaging about the future of HTTP to give the community advance notice of
+  changes.
+-->
+
+### [HTTP](https://github.com/nodejs/http)
+
+HTTP 워킹 그룹은 Node의 HTTP 구현체를 지원하고 개선하는 권한을 가집니다.
+이 워킹 그룹은 다음에 대한 책임이 있습니다.
+
+* Node.js 이슈 트래커에 올라온 HTTP 이슈를 처리합니다.
+* Node.js 프로젝트의 HTTP 문서를 작성하고 수정합니다.
+* Node.js 프로젝트의 HTTP 기능 변경을 검토합니다.
+* 코어의 HTTP 구현체와 API가 발전하도록 HTTP 생태계와 관련된 모듈 개발자들과 협업합니다.
+* HTTP와 관련된 모든 이슈와 토론을 핵심 기술 위원회(CTC)에 알립니다.
+* 차후 HTTP의 변경사항을 커뮤니티에 알립니다.
+
+<!--
+### [Roadmap](https://github.com/nodejs/roadmap)
+
+The roadmap working group is responsible for user community outreach
+and the translation of their concerns into a plan of action for Node.js.
+
+The final [ROADMAP](https://github.com/nodejs/node/blob/master/ROADMAP.md) document is still
+owned by the TC and requires the same approval for changes as any other project asset.
+
+Their responsibilities are:
+* Attract and summarize user community needs and feedback.
+* Find or potentially create tools that allow for broader participation.
+* Create Pull Requests for relevant changes to
+[ROADMAP.md](https://github.com/nodejs/node/blob/master/ROADMAP.md)
+-->
+
+### [Roadmap](https://github.com/nodejs/roadmap)
+
+로드맵 워킹 그룹은 사용자 커뮤니티의 활동과 관심사가 Node.js의 수행 계획에 포함되도록 하는 책임을
+집니다.
+
+최종 [로드맵](https://github.com/nodejs/node/blob/master/ROADMAP.md) 문서는 아직
+TC가 관리하고 있고 다른 프로젝트 자산과 마찬가지로 변경할 때 같은 승인절차가 필요합니다.
+
+이 워킹 그룹은 다음에 대한 책임이 있습니다.
+
+* 사용자 커뮤니티의 요구사항과 피드백을 받아서 요약합니다.
+* 더 넓은 참여가 가능한 도구를 찾거나 만들 수도 있습니다.
+* [ROADMAP.md](https://github.com/nodejs/node/blob/master/ROADMAP.md)
+  관련 변경사항에 대한 풀 리퀘스트를 올립니다.
+
+<!--
+### [Docker](https://github.com/nodejs/docker-node)
+
+The Docker working group's purpose is to build, maintain, and improve official
+Docker images for the `Node.js` project.
+
+Their responsibilities are:
+* Keep the official Docker images updated in line with new `Node.js` releases.
+* Decide and implement image improvements and/or fixes.
+* Maintain and improve the images' documentation.
+-->
+
+### [Docker](https://github.com/nodejs/docker-node)
+
+Docker 워킹 그룹은 `Node.js` 프로젝트의 공식 Docker 이미지를 만들고 관리하고 개선합니다.
+
+이 워킹 그룹은 다음에 대한 책임이 있습니다.
+
+* 새로운 `Node.js` 릴리스로 공식 Docker 이미지를 갱신합니다.
+* 이미지의 개선이나 수정사항 구현을 결정합니다.
+* 이미지 문서를 관리하고 개선합니다.
+
+<!--
+### [Addon API](https://github.com/nodejs/nan)
+
+The Addon API Working Group is responsible for maintaining the NAN project and
+corresponding _nan_ package in npm. The NAN project makes available an
+abstraction layer for native add-on authors for Node.js,
+assisting in the writing of code that is compatible with many actively used
+versions of Node.js, V8 and libuv.
+
+Their responsibilities are:
+
+* Maintaining the [NAN](https://github.com/nodejs/nan) GitHub repository,
+  including code, issues and documentation.
+* Maintaining the [addon-examples](https://github.com/nodejs/node-addon-examples)
+  GitHub repository, including code, issues and documentation.
+* Maintaining the C++ Addon API within the Node.js project, in subordination to
+  the Node.js CTC.
+* Maintaining the Addon documentation within the Node.js project, in
+  subordination to the Node.js CTC.
+* Maintaining the _nan_ package in npm, releasing new versions as appropriate.
+* Messaging about the future of the Node.js and NAN interface to give the
+  community advance notice of changes.
+
+The current members can be found in their
+[README](https://github.com/nodejs/nan#collaborators).
+-->
+
+### [Addon API](https://github.com/nodejs/nan)
+
+애드온 API 워킹 그룹은 NAN 프로젝트와 npm에서 _nan_ 패키지를 유지 보수하는 책임을 집니다.
+NAN 프로젝트는 네이티브 애드온 작성자가 다수가 사용하는 Node.js, V8, libuv 버전과 호환성 있는
+코드를 작성할 수 있도록 추상화 계층을 제공한다.
+
+이 워킹 그룹은 다음에 대한 책임이 있습니다.
+
+* [NAN](https://github.com/nodejs/nan) GitHub 저장소에서 코드, 이슈, 문서를 관리합니다.
+* [addon-examples](https://github.com/nodejs/node-addon-examples)
+  GitHub 저장에서 코드, 이슈, 문서를 관리합니다.
+* Node.js CTC 하에 Node.js 프로젝트의 C++ Addon API를 관리합니다.
+* Node.js CTC 하에 Node.js 프로젝트의 Addon 문서를 관리합니다.
+* npm의 _nan_ 패키지를 관리하고 절절하게 새로운 버전을 릴리스합니다.
+* 차후 Node.js와 NAN 인터페이스의 변경사항을 커뮤니티에 알립니다.
+
+현재 회원은 nan의 [README](https://github.com/nodejs/nan#collaborators)에서
+볼 수 있습니다.
+
+<!--
+### [Benchmarking](https://github.com/nodejs/benchmarking)
+
+The purpose of the Benchmark working group is to gain consensus
+for an agreed set of benchmarks that can be used to:
+
++ track and evangelize performance gains made between Node releases
++ avoid performance regressions between releases
+
+Its responsibilities are:
+
++ Identify 1 or more benchmarks that reflect customer usage.
+   Likely need more than one to cover typical Node use cases
+   including low-latency and high concurrency
++ Work to get community consensus on the list chosen
++ Add regular execution of chosen benchmarks to Node builds
++ Track/publicize performance between builds/releases
+-->
+
+### [Benchmarking](https://github.com/nodejs/benchmarking)
+
+벤치마킹 워킹 그룹의 목적은 벤치마크 세트가 동의하에 사용될 수 있도록 합의점을 찾는 것입니다.
+
++ Node 릴리스 간의 성능 차이를 추적하고 알립니다.
++ 릴리즈 간의 성능 저하를 피합니다.
+
+이 워킹 그룹은 다음에 대한 책임이 있습니다.
+
++ 사용자 용도를 반역하는 하나 이상의 벤치마크를 확인합니다. 지연이 낮고 높은 동시성을 가지는 것을 포함해서 일반적인 Node 사용 사례를 다루는 하나 이상의 벤치마크가 필요합니다.
++ 선택한 벤치마크 목록에서 커뮤니티의 합의를 합니다.
++ Node 빌드에 선정한 벤치마크를 정기적으로 실행합니다.
++ 빌드/릴리스 간에 성능을 추적하고 알립니다.
+
+<!--
+### [Post-mortem](https://github.com/nodejs/post-mortem)
+
+The Post-mortem Diagnostics working group is dedicated to the support
+and improvement of postmortem debugging for Node.js. It seeks to
+elevate the role of postmortem debugging for Node, to assist in the
+development of techniques and tools, and to make techniques and tools
+known and available to Node.js users.
+
+Its responsibilities are:
+
++ Defining and adding interfaces/APIs in order to allow dumps
+  to be generated when needed
++ Defining and adding common structures to the dumps generated
+  in order to support tools that want to introspect those dumps
+-->
+
+### [Post-mortem](https://github.com/nodejs/post-mortem)
+
+포스트모템 진단 워킹 그룹은 Node.js 포스트모템 디버깅을 지원하고 개선합니다. 이 워킹 그룹은 Node에서
+포스트모템 디버깅의 역할을 향상시켜서 기술과 도구개발을 돕고 Node.js 사용자가 알고 있고 사용하는
+기술과 도구를 만드는 것입니다.
+
+이 워킹 그룹은 다음에 대한 책임이 있습니다.
+
+* 필요할 때 덤프를 생성할 수 있도록 인터페이스/API를 정의하고 추가합니다.
+* 이러한 덤프를 분석하는 도구를 지원하기 위해 생성된 덤프의 공통 구조를 정의하고 추가합니다.
+
+<!--
+### [Documentation](https://github.com/nodejs/docs)
+
+The Documentation working group exists to support the improvement of Node.js
+documentation, both in the core API documentation, and elsewhere, such as the
+Node.js website. Its intent is to work closely with Evangelism, Website, and
+Intl working groups to make excellent documentation available and accessible
+to all.
+
+Its responsibilities are:
+
+* Defining and maintaining documentation style and content standards.
+* Producing documentation in a format acceptable for the Website WG to consume.
+* Ensuring that Node's documentation addresses a wide variety of audiences.
+* Creating and operating a process for documentation review that produces
+  quality documentation and avoids impeding the progress of Core work.
+-->
+
+### [Documentation](https://github.com/nodejs/docs)
+
+문서화 워킹 그룹은 코어 API 문서와 Node.js 웹사이트 같은 문서를 포함한 모든 Node.js 문서를 개선합니다. 모두가 뛰어난 문서를 사용할 수 있도록 Evangelism, Website, Intl 워킹 그룹과 밀접하게 작업합니다.
+
+이 워킹 그룹은 다음에 대한 책임이 있습니다.
+
+* 문서 형식과 콘텐츠 표준을 정의하고 관리합니다.
+* Website 워킹그룹이 받아들일 수 있는 형식으로 문서를 작성합니다.
+* Node의 문서가 다양한 사용자를 지원할 수 있도록 합니다.
+* 핵심 작업 절차를 방해하지 않고 질 좋은 문서를 만들기 위해 문서 리뷰과정을 만들고 운영합니다.
+
+<!--
+### [Testing](https://github.com/nodejs/testing)
+
+The Node.js Testing Working Group's purpose is to extend and improve testing of
+the Node.js source code.
+
+It's responsibilities are:
+
+* Coordinating an overall strategy for improving testing.
+* Documenting guidelines around tests.
+* Working with the Build Working Group to improve continuous integration.
+* Improving tooling for testing.
+-->
+
+### [Testing](https://github.com/nodejs/testing)
+
+Node.js 테스팅 워킹 그룹은 Node.js 소스 코드의 테스트를 확장하고 개선합니다.
+
+이 워킹 그룹은 다음에 대한 책임이 있습니다.
+
+* 테스트를 개선하는 전반적인 전략을 조정합니다.
+* 테스트와 관련된 가이드라인을 문서로 만듭니다.
+* 지속적인 통합을 개선하기 위해 Build 워킹 그룹과 협업합니다.
+* 테스트 도구를 개선합니다.
diff --git a/locale/ko/security.md b/locale/ko/security.md
new file mode 100644
index 0000000000000..6af03d88ef98c
--- /dev/null
+++ b/locale/ko/security.md
@@ -0,0 +1,123 @@
+---
+layout: security.hbs
+title: 보안
+---
+
+<!--
+# Security
+
+## Reporting a Bug
+
+All security bugs in Node.js are taken seriously and should be reported by emailing [security@nodejs.org](mailto:security@nodejs.org).
+This will be delivered to a subset of the core team who handle security issues.
+
+Your email will be acknowledged within 24 hours, and you’ll receive a more detailed response to your email within 48
+hours indicating the next steps in handling your report.
+-->
+# 보안
+
+# 버그 보고
+
+Node.js의 모든 보안 버그는 심각한 문제이므로
+[security@nodejs.org](mailto:security@nodejs.org) 이메일로 보고해야 합니다.
+이 이메일은 보안 이슈를 처리하는 코어 팀 내의 사람들에게 보내질 것입니다.
+
+보고된 내용은 24시간 이내에 승인하고 48시간 이내에 다음 처리 단계를 안내하는
+자세한 내용을 응답할 것입니다.
+
+<!--
+After the initial reply to your report, the security team will endeavor to keep you informed of the progress being made
+towards a fix and full announcement, and may ask for additional information or guidance surrounding the reported issue.
+These updates will be sent at least every five days, in practice, this is more likely to be every 24-48 hours.
+
+Security bugs in third party modules should be reported to their respective maintainers and can also be coordinated
+through the [Node Security Project](https://nodesecurity.io).
+
+Thank you for improving the security of Node.js. Your efforts and responsible disclosure are greatly appreciated and
+will be acknowledged.
+-->
+보고한 내용에 첫 답변을 한 후 보안 팀은 수정사항과 전체 공지를 만드는 과정을 보고자에게 계속 알려주려고
+노력할 것입니다. 보고된 이슈에 대한 추가 정보나 안내를 물어볼 수도 있습니다. 이러한 진행사항은
+최소 5일마다 계속 알려줄 것입니다만 실제로는 24~48시간 마다 알려줄 가능성이 큽니다.
+
+서드파티 모듈의 보안 버그는 각 메인테이너에게 보고해야 하고
+[Node 보안 프로젝트](https://nodesecurity.io)를 통해 조정할 수도 있습니다.
+
+Node.js의 보안을 개선하게 해 준 것에 감사드립니다. 당신이 들인 노력과 책임 있는 공개에 아주
+감사드리고 이는 인정받을 것입니다.
+
+<!--
+## Disclosure Policy
+
+Here is the security disclosure policy for Node.js
+
+- The security report is received and is assigned a primary handler. This person will coordinate the fix and release
+process. The problem is confirmed and a list of all affected versions is determined. Code is audited to find any
+potential similar problems. Fixes are prepared for all releases which are still under maintenance. These fixes are not
+committed to the public repository but rather held locally pending the announcement.
+
+- A suggested embargo date for this vulnerability is chosen and a CVE (Common Vulnerabilities and  Exposures (CVE®))
+is requested for the vulnerability.
+
+- On the embargo date, the Node.js security mailing list is sent a copy of the announcement. The changes are pushed to
+the public repository and new builds are deployed to nodejs.org. Within 6 hours of the mailing list being notified, a
+copy of the advisory will be published on the Node.js blog.
+
+- Typically the embargo date will be set 72 hours from the time the CVE is issued. However, this may vary depending on
+the severity of the bug or difficulty in applying a fix.
+
+- This process can take some time, especially when coordination is required with maintainers of other projects. Every
+effort will be made to handle the bug in as timely a manner as possible, however, it’s important that we follow the
+release process above to ensure that the disclosure is handled in a consistent manner.
+-->
+
+## 공개 정책
+
+다음은 Node.js의 보안 공개 정책입니다.
+
+- 보안 보고를 받으면 주요 처리자에게 할당됩니다. 이 사람은 수정사항과 릴리스 정차를 책임질 것입니다.
+  해당 문제를 확인하고 영향을 받는 버전 목록을 결정합니다. 잠재적으로 비슷한 문제를 일으킬 수 있는
+  코드를 점검합니다. 관리 중인 모든 릴리스 버전에 대한 수정사항을 준비합니다. 이 수정사항은
+  공개 저장소에 커밋하지 않고 공지할 때까지 로컬에 보관해 둡니다.
+
+- 해당 취약점에 대한 공개 금지 날짜를 결정하고
+  CVE(Common Vulnerabilities and Exposures (CVE®))를 요청합니다.
+
+- 공개 금지 날짜가 끝나면 Node.js 보안 메일링 리스트로 공지의 복사본을 보냅니다. 수정사항을 공개
+  저장소에 올리고 새로운 빌드를 nodejs.org에 배포합니다. 메일링 리스트에 공지하고 6시간 이내에
+  권고안의 복사본을 Node.js 블로그에 발행합니다.
+
+- 보통 공개 금지 날짜는 CVE가 발급된 후 72시간으로 정하지만, 버그의 심각도나 수정의 어려움에 따라
+  달라질 수 있습니다.
+
+- 이 절차는 시간이 걸릴 수 있고 다른 프로젝트의 메인테이너들과의 협업이 필요한 경우에는 더 오랜 시간이
+  걸릴 수 있습니다. 가능한 최적의 시기에 버그를 처리하려고 노력할 것이지만 정보 공개를 일관되게 하려고
+  위에서 설명한 릴리스 절차를 따르는 것이 중요합니다.
+
+<!--
+## Receiving Security Updates
+
+Security notifications will be distributed via the following methods.
+
+- [https://groups.google.com/group/nodejs-sec](https://groups.google.com/group/nodejs-sec)
+- [https://nodejs.org/en/blog](https://nodejs.org/en/blog)
+-->
+
+## 보안 업데이트 받기
+
+다음 방법으로 보안 공지를 합니다.
+
+- [https://groups.google.com/group/nodejs-sec](https://groups.google.com/group/nodejs-sec)
+- [https://nodejs.org/en/blog](https://nodejs.org/en/blog)
+
+<!--
+## Comments on this Policy
+
+If you have suggestions on how this process could be improved please submit a [pull request](https://github.com/nodejs/nodejs.org)
+or email [security@nodejs.org](mailto:security@nodejs.org) to discuss.
+-->
+
+## 이 정책에 대한 의견
+
+이 절차를 개선하기 위한 의견이 있다면 논의를 위해 [풀 리퀘스트](https://github.com/nodejs/nodejs.org)를 올리거나
+[security@nodejs.org](mailto:security@nodejs.org)로 이메일을 보내주시기 바랍니다.
diff --git a/locale/ko/site.json b/locale/ko/site.json
index 18e1cd7712556..4eeec36368e66 100644
--- a/locale/ko/site.json
+++ b/locale/ko/site.json
@@ -48,6 +48,14 @@
             "link": "about/resources",
             "text": "관련 자료"
         },
+        "foundation": {
+            "link": "foundation",
+            "text": "재단"
+        },
+        "security": {
+            "link": "security",
+            "text": "보안"
+        },
         "trademark": {
             "link": "about/trademark",
             "text": "트레이드마크"
@@ -63,6 +71,10 @@
         "package-manager": {
             "link": "download/package-manager",
             "text": "패키지 관리자를 통한 Node.js 설치"
+        },
+        "shasums":{
+          "link": "SHASUMS256.txt.asc",
+          "text": "릴리스 파일에 서명된 SHASUMS"
         }
     },
     "docs": {
@@ -88,10 +100,6 @@
         "guides": {
             "link": "docs/guides",
             "text": "안내"
-        },
-        "knowledge": {
-            "link": "knowledge",
-            "text": "지식 베이스"
         }
     },
     "foundation": {
@@ -125,6 +133,10 @@
     "getinvolved": {
         "link": "get-involved",
         "text": "참여하기",
+        "code-and-learn": {
+            "link": "get-involved/code-and-learn",
+            "text": "코딩 + 배우기"
+        },
         "contribute": {
             "link": "get-involved/contribute",
             "text": "기여하기"
@@ -133,16 +145,13 @@
             "link": "get-involved/development",
             "text": "개발하기"
         },
-        "code-and-learn": {
-            "link": "get-involved/code-and-learn",
-            "text": "코딩 + 배우기"
-        },
         "events": {
           "link": "get-involved/events",
           "text": "이벤트"
         },
         "conduct": {
-            "text": "Conduct"
+            "link": "https://github.com/nodejs/node/blob/master/CONTRIBUTING.md#code-of-conduct",
+            "text": "행동강령"
         }
     },
     "security"   : { "link": "security",        "text": "보안" },