Merge pull request MichaelCade#402 from Me1e/ko/translate

Author: MichaelCade

2022/ko/Days/day04.md

@@ -82,7 +82,7 @@ id: 1048700
 
 1. 개발 팀과 운영 팀을 통합합니다.
 2. 빌드 및 운영 팀을 만들고 모든 개발 및 운영 관련 문제를 전체 DevOps 팀에서 논의합니다.
-3. 스프린트에 대한 접근 방식을 변경하고 우선순위를 지정하여 개발 작업과 동일한 가치를 지닌 DevOps 작업을 제공하세요. 개발 팀과 운영 팀이 다른 팀의 워크플로와 발생 가능한 문제에 대해 의견을 교환하도록 장려하세요.
+3. 스프린트에 대한 접근 방식을 변경하고 우선순위를 지정하여 개발 작업과 동일한 가치를 지닌 DevOps 작업을 제공하세요. 개발 팀과 운영 팀이 다른 팀의 workflow와 발생 가능한 문제에 대해 의견을 교환하도록 장려하세요.
 4. 모든 개발 단계에 QA를 포함하세요.
 5. 올바른 도구를 선택하세요.
 6. 가능한 모든 것을 자동화하세요.

2022/ko/Days/day07.md

@@ -28,7 +28,7 @@ Kasten K10이나 Terraform, HCL과 같은 데브옵스 도구와 상호 작용
 
 ## 제가 방금 프로그래밍 언어를 배우지 말라고 설득한 건가요?
 
-많은 경우, 데브옵스 엔지니어의 주된 책임은 엔지니어링 팀과 협력하여 데브옵스 관행을 워크플로우에 통합하는 것입니다. 여기에는 애플리케이션에 대한 광범위한 테스트와 워크플로우가 앞서 설명한 데브옵스 원칙을 준수하는지 확인하는 작업인 경우가 많습니다. 그러나 작업의 상당 부분에는 애플리케이션 성능 또는 기타 기술적 결함과 관련된 문제 해결도 포함될 수 있습니다. 따라서 작업 중인 애플리케이션에서 사용하는 프로그래밍 언어에 대한 전문 지식을 갖추는 것이 중요합니다. 예를 들어, 애플리케이션이 Node.js로 작성된 경우 Go나 Python을 알아도 별 도움이 되지 않습니다.
+많은 경우, 데브옵스 엔지니어의 주된 책임은 엔지니어링 팀과 협력하여 데브옵스 관행을 workflow에 통합하는 것입니다. 여기에는 애플리케이션에 대한 광범위한 테스트와 workflow가 앞서 설명한 데브옵스 원칙을 준수하는지 확인하는 작업인 경우가 많습니다. 그러나 작업의 상당 부분에는 애플리케이션 성능 또는 기타 기술적 결함과 관련된 문제 해결도 포함될 수 있습니다. 따라서 작업 중인 애플리케이션에서 사용하는 프로그래밍 언어에 대한 전문 지식을 갖추는 것이 중요합니다. 예를 들어, 애플리케이션이 Node.js로 작성된 경우 Go나 Python을 알아도 별 도움이 되지 않습니다.
 
 ## 왜 Go인가요?
 

2022/ko/Days/day18.md

@@ -114,7 +114,7 @@ Windows 클라이언트에서 Powershell을 사용하여 키를 생성했지만,
 
 위에서 설명한 SSH와는 별개로, 이번에는 웹 서버를 구축하는 방법을 다루고자 합니다. 처음에는 조금 어려워 보일 수 있지만, 실제로는 그렇지 않습니다.
 
-리눅스 가상 머신을 이미 구축해 두었다고 가정하고, 이 가상 머신에 아파치 웹 서버를 추가하여 내부 네트워크에서 접근할 수 있는 간단한 웹 사이트를 호스팅하려고 합니다. 인터넷에서 접근할 수 있는 웹 사이트는 아니며, 그에 대한 내용은 여기서 다루지 않습니다.
+리눅스 가상 머신을 이미 구축해 두었다고 가정하고, 이 가상 머신에 apache 웹 서버를 추가하여 내부 네트워크에서 접근할 수 있는 간단한 웹 사이트를 호스팅하려고 합니다. 인터넷에서 접근할 수 있는 웹 사이트는 아니며, 그에 대한 내용은 여기서 다루지 않습니다.
 
 이 과정은 LAMP 스택이라고도 불립니다.
 
@@ -197,7 +197,7 @@ LAMP 스택에 워드프레스를 설치하기 위해 [How to install WordPress
 
 위 링크의 Step 4에 도달했습니다. 워드프레스 디렉토리에 대한 모든 권한이 올바르게 설정되어 있는지 확인해야 합니다.
 
-내부 네트워크 전용이므로 이 단계에서 "generate security keys"를 할 필요가 없습니다. 아파치 구성을 워드프레스로 변경하는 Step 5로 이동합니다.
+내부 네트워크 전용이므로 이 단계에서 "generate security keys"를 할 필요가 없습니다. apache 구성을 워드프레스로 변경하는 Step 5로 이동합니다.
 
 모든 설정이 올바르게 구성되어 있다면, 내부 네트워크 주소를 통해 워드프레스 설치를 진행할 수 있습니다.
 

2022/ko/Days/day24.md

@@ -34,7 +34,7 @@ id: 1048805
 
 작업을 식별하고 네트워크 변경 요청에 대한 검색을 수행하여 솔루션을 자동화할 가장 일반적인 이슈와 문제를 파악해야 합니다.
 
-- 현재 수동으로 처리하고 있는 모든 변경 요청과 워크플로우의 목록을 작성합니다.
+- 현재 수동으로 처리하고 있는 모든 변경 요청과 workflow의 목록을 작성합니다.
 - 가장 일반적이고 시간이 오래 걸리며 오류가 발생하기 쉬운 활동을 파악하세요.
 - 비즈니스 중심 접근 방식을 취하여 요청의 우선순위를 정하세요.
 - 이는 자동화 프로세스를 구축하기 위한 프레임워크이며, 자동화해야 하는 작업과 자동화하지 않아야 하는 작업을 구분합니다.

2022/ko/Days/day31.md

@@ -100,7 +100,7 @@ Azure Functions - 서버리스 코드를 제공합니다. 퍼블릭 클라우드
 
 Azure Event Grid를 사용하면 서비스 및 이벤트에서 로직을 트리거할 수 있습니다.
 
-Azure Logic App은 그래픽 기반 워크플로 및 통합을 제공합니다.
+Azure Logic App은 그래픽 기반 workflow 및 통합을 제공합니다.
 
 또한 일관된 관리 및 예약을 통해 Windows 및 Linux 노드 모두에서 대규모 작업을 실행할 수 있는 Azure Batch도 살펴볼 수 있습니다.
 

2022/ko/Days/day33.md

@@ -88,7 +88,7 @@ Microsoft Azure에는 두 가지 로드 밸런싱 솔루션이 있습니다. (
 
 ### Azure 포털
 
-Microsoft Azure Portal은 커맨드라인 도구의 대안을 제공하는 웹 기반 콘솔입니다. Azure 포털에서 구독을 관리할 수 있습니다. 간단한 웹 앱부터 복잡한 클라우드 배포까지 모든 것을 빌드, 관리 및 모니터링할 수 있습니다. 포털 내에서 찾을 수 있는 또 다른 것은 이러한 이동 경로이며, 앞서 언급했듯이 JSON은 모든 Azure 리소스의 기반이며, 포털에서 시작하여 기능, 서비스 및 기능을 이해한 다음 나중에 자동화된 워크플로우에 통합하기 위해 그 아래에 있는 JSON을 이해할 수 있습니다.
+Microsoft Azure Portal은 커맨드라인 도구의 대안을 제공하는 웹 기반 콘솔입니다. Azure 포털에서 구독을 관리할 수 있습니다. 간단한 웹 앱부터 복잡한 클라우드 배포까지 모든 것을 빌드, 관리 및 모니터링할 수 있습니다. 포털 내에서 찾을 수 있는 또 다른 것은 이러한 이동 경로이며, 앞서 언급했듯이 JSON은 모든 Azure 리소스의 기반이며, 포털에서 시작하여 기능, 서비스 및 기능을 이해한 다음 나중에 자동화된 workflow에 통합하기 위해 그 아래에 있는 JSON을 이해할 수 있습니다.
 
 ![](/2022/Days/Images/Day33_Cloud2.png)
 

2022/ko/Days/day37.md

@@ -12,7 +12,7 @@ id: 1048707
 
 제목과 글 전체에 끔찍한 말장난이 들어가서 죄송합니다. Git을 아재 개그로 바꾼 사람이 제가 처음은 아닐 겁니다!
 
-지난 두 번의 포스팅에서 버전 관리 시스템과 버전 관리 시스템으로서의 Git의 기본적인 워크플로우에 대해 배웠고, [Day 35](day35.md)에서는 시스템에 Git을 설치하고 업데이트와 구성을 했습니다. 또한 클라이언트-서버 버전 관리 시스템과 분산 버전 관리 시스템인 Git [Day 36](day36.md) 사이의 이론에 대해 조금 더 자세히 알아보았습니다.
+지난 두 번의 포스팅에서 버전 관리 시스템과 버전 관리 시스템으로서의 Git의 기본적인 workflow에 대해 배웠고, [Day 35](day35.md)에서는 시스템에 Git을 설치하고 업데이트와 구성을 했습니다. 또한 클라이언트-서버 버전 관리 시스템과 분산 버전 관리 시스템인 Git [Day 36](day36.md) 사이의 이론에 대해 조금 더 자세히 알아보았습니다.
 
 이제 Git에서 흔히 볼 수 있는 몇 가지 명령어와 사용 사례를 살펴보겠습니다.
 

2022/ko/Days/day38.md

@@ -70,7 +70,7 @@ Nano가 열리면 설명을 추가한 다음 파일을 저장할 수 있습니
 
 프로젝트에서 파일을 제거하는 것은 어떨까요? 디렉토리에 커밋했지만 이제 프로젝트에 더 이상 필요하지 않거나 사용하지 않는 다른 파일이 있는 경우, 파일을 제거해야 합니다.
 
-디렉토리에서 파일을 제거해도 git은 여전히 이 파일을 인식하므로 리포지토리에서도 파일을 제거해야 합니다. 아래에서 이를 위한 워크플로우를 확인할 수 있습니다.
+디렉토리에서 파일을 제거해도 git은 여전히 이 파일을 인식하므로 리포지토리에서도 파일을 제거해야 합니다. 아래에서 이를 위한 workflow를 확인할 수 있습니다.
 
 ![](/2022/Days/Images/Day38_Git9.png)
 

2022/ko/Days/day39.md

@@ -196,7 +196,7 @@ git rebase main
 
 rebase의 가장 큰 장점은 프로젝트 히스토리가 훨씬 깔끔해진다는 것입니다. 또한 불필요한 merge commit을 제거하며, 마지막 두 이미지를 비교하면 훨씬 더 깔끔한 선형 프로젝트 히스토리를 따라갈 수 있습니다.
 
-아직 확실한 결론은 아니지만, 더 깔끔한 히스토리를 선택하는 것도 장단점이 있는데, [rebase의 황금률](https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing)을 따르지 않는다면 프로젝트 히스토리를 다시 작성하는 것은 협업 워크플로에 치명적일 수 있습니다. 그리고 더 중요한 것은 rebase를 하면 merge commit이 제공하는 컨텍스트가 사라져 업스트림 변경 사항이 언제 feature에 통합되었는지 알 수 없다는 것입니다.
+아직 확실한 결론은 아니지만, 더 깔끔한 히스토리를 선택하는 것도 장단점이 있는데, [rebase의 황금률](https://www.atlassian.com/git/tutorials/merging-vs-rebasing#the-golden-rule-of-rebasing)을 따르지 않는다면 프로젝트 히스토리를 다시 작성하는 것은 협업 workflow에 치명적일 수 있습니다. 그리고 더 중요한 것은 rebase를 하면 merge commit이 제공하는 컨텍스트가 사라져 업스트림 변경 사항이 언제 feature에 통합되었는지 알 수 없다는 것입니다.
 
 ## 자료
 

2022/ko/Days/day40.md

@@ -185,7 +185,7 @@ Insight 탭은 리포지토리의 활동량부터 commit 및 issues에 이르기
 
 이 단계에서는 이 작업이 완료되고 우리만 새로운 변경 사항을 사용할 것이므로 변경 사항에 만족할 수도 있지만, 버그 변경일 수도 있으며 이 경우, pull requests를 통해 기여하여 원래 리포지토리 관리자에게 변경 사항을 알리고 변경 사항을 수락하는지 확인하고 싶을 것입니다.
 
-아래 강조 표시된 기여 버튼을 사용하여 이 작업을 수행할 수 있습니다. 내일 오픈소스 워크플로우를 살펴보면서 이에 대해 더 자세히 다루겠습니다.
+아래 강조 표시된 기여 버튼을 사용하여 이 작업을 수행할 수 있습니다. 내일 오픈소스 workflow를 살펴보면서 이에 대해 더 자세히 다루겠습니다.
 
 ![](/2022/Days/Images/Day40_Git29.png)