Developer Calssess

1. SQL Injection

 1.1 개요

Ÿ   SQL Injection

SQL Injection 이란 악의적인 사용자가 보안상의 취약점을 이용하여, 임의의 SQL 문을 주입하고 실행되게 하여 데이터베이스가 비정상적인 동작을 하도록 조작하는 행위 입니다. 인젝션 공격은 OWASP Top10 중 첫 번째에 속해 있으며, 공격이 비교적 쉬운 편이고 공격에 성공할 경우 큰 피해를 입힐 수 있는 공격입니다.

Ÿ   여기어때 해킹 사건

2017년 3월에 일어난 “여기어때” 의 대규모 개인정보 유출 사건도 SQL Injection 으로 인해 피해가 발생하였습니다.

 1.2 공격 종류 및 방법

Error based SQL Injection

논리적 에러를 이용한 SQL Injection 

SQL 공격 기법은 여러 가지가 있는데 논리적 에러를 이용한 SQL Injection은 가장 많이 쓰이고, 대중적인 공격 기법입니다.

Ÿ   Error based SQL Injection

위의 사진에서 보이는 쿼리문은 일반적으로 로그인 시 많이 사용되는 SQL 구문입니다. 해당 구문에서 입력값에 대한 검증이 없음을 확인하고, 악의적인 사용자가 임의의 SQL 구문을 주입하였습니다. 주입된 내용은 ‘ OR 1=1 -- 로  WHERE 절에 있는 싱글쿼터를 닫아주기 위한 싱글쿼터와 OR 1=1 라는 구문을 이용해 WHERE 절을 모두 참으로 만들고, -- 를 넣어줌으로 뒤의 구문을 모두 주석 처리 해주었습니다.

  매우 간단한 구문이지만, 결론적으로 Users 테이블에 있는 모든 정보를 조회하게 됨으로 써 가장 먼저 만들어진 계정으로 로그인에 성공하게 됩니다. 보통은 관리자 계정을 맨 처음 만들기 때문에 관리자 계정에 로그인 할 수 있게 됩니다. 관리자 계정을 탈취한 악의적인 사용자는 관리자의 권한을 이용해 또 다른 2차피해를 발생 시킬 수 있게 됩니다.

Union based SQL Injection

Union 명령어를 이용한 SQL Injection 

 SQL 에서 Union 키워드는 두 개의 쿼리문에 대한 결과를 통합해서 하나의 테이블로 보여주게 하는 키워드 입니다. 정상적인 쿼리문에 Union 키워드를 사용하여 인젝션에 성공하면, 원하는 쿼리문을 실행할 수 있게 됩니다. Union Injection을 성공하기 위해서는 두 가지의 조건이 있습니다. 하나는 Union 하는 두 테이블의 컬럼 수가 같아야 하고, 데이터 형이 같아야 합니다. 

Ÿ   Union based SQL Injection

위의 사진에서 보이는 쿼리문은 Board 라는 테이블에서 게시글을 검색하는 쿼리문입니다. 입력값을 title 과 contents 컬럼의 데이터랑 비교한 뒤 비슷한 글자가 있는 게시글을 출력합니다. 여기서 입력값으로 Union 키워드와 함께 컬럼 수를 맞춰서 SELECT 구문을 넣어주게 되면 두 쿼리문이 합쳐서서 하나의 테이블로 보여지게 됩니다. 현재 인젝션 한 구문은 사용자의 id와 passwd를 요청하는 쿼리문 입니다. 인젝션이 성공하게 되면, 사용자의 개인정보가 게시글과 함께 화면에 보여지게 됩니다. 

 물론 패스워드를 평문으로 데이터베이스에 저장하지는 않겠지만 인젝션이 가능하다는 점에서 이미 그 이상의 보안위험에 노출되어 있습니다. 이 공격도 역시 입력값에 대한 검증이 없기 때문에 발생하게 되었습니다.

Blind SQL Injection

Boolean based SQL

Blind SQL Injection은 데이터베이스로부터 특정한 값이나 데이터를 전달받지 않고, 단순히 참과 거짓의 정보만 알 수 있을 때 사용합니다. 로그인 폼에 SQL Injection이 가능하다고 가정 했을 때, 서버가 응답하는 로그인 성공과 로그인 실패 메시지를 이용하여, DB의 테이블 정보 등을 추출해 낼 수 있습니다.

Ÿ   Blind SQL Injection – Boolean based

위의 그림은 Blind Injection을 이용하여 데이터베이스의 테이블 명을 알아내는 방법입니다. (MySQL) 인젝션이 가능한 로그인 폼을 통하여 악의적인 사용자는 임의로 가입한 abc123 이라는 아이디와 함께 abc123’ and ASCII(SUBSTR(SELECT name From information_schema.tables WHERE table_type=’base table’ limit 0,1)1,1)) > 100 -- 이라는 구문을 주입합니다.

 해당구문은 MySQL 에서 테이블 명을 조회하는 구문으로 limit 키워드를 통해 하나의 테이블만 조회하고, SUBSTR 함수로 첫 글자만, 그리고 마지막으로 ASCII 를 통해서 ascii 값으로 변환해줍니다. 만약에 조회되는 테이블 명이 Users 라면 ‘U’ 자가 ascii 값으로 조회가 될 것이고, 뒤의 100 이라는 숫자 값과 비교를 하게 됩니다.  거짓이면 로그인 실패가 될 것이고, 참이 될 때까지 뒤의 100이라는 숫자를 변경해 가면서 비교를 하면 됩니다.  공격자는 이 프로세스를 자동화 스크립트를 통하여 단기간 내에 테이블 명을 알아 낼 수 있습니다.

Blind SQL Injection

Time based SQL

Time Based SQL Injection 도 마찬가지로 서버로부터 특정한 응답 대신에 참 혹은 거짓의 응답을 통해서 데이터베이스의 정보를 유추하는 기법입니다. 사용되는 함수는 MySQL 기준으로 SLEEP 과 BENCHMARK 입니다.

Ÿ   Blind SQL Injection - Time based

위의 그림은 Time based SQL Injection을 사용하여 현재 사용하고 있는 데이터베이스의 길이를 알아내는 방법입니다. 로그인 폼에 주입이 되었으며 임의로 abc123 이라는 계정을 생성해 두었습니다. 악의적인 사용자가 abc123’ OR (LENGTH(DATABASE())=1 AND SLEEP(2)) – 이라는 구문을 주입하였습니다. 여기서 LENGTH 함수는 문자열의 길이를 반환하고, DATABASE 함수는 데이터베이스의 이름을 반환합니다.

 주입된 구문에서, LENGTH(DATABASE()) = 1 가 참이면 SLEEP(2) 가 동작하고, 거짓이면 동작하지 않습니다. 이를 통해서 숫자 1 부분을 조작하여 데이터베이스의 길이를 알아 낼 수 있습니다. 만약에 SLEEP 이라는 단어가 치환처리 되어있다면, 또 다른 방법으로 BENCHMARK 나 WAIT 함수를 사용 할 수 있습니다. BENCHMARK 는 BENCHMARK(1000000,AES_ENCRYPT('hello','goodbye')); 이런 식으로 사용이 가능합니다. 이 구문을 실행 하면 약 4.74초가 걸립니다.

Stored Procedure SQL Injection

저장된 프로시저 에서의 SQL Injection

저장 프로시저(Stored Procedure) 은 일련의 쿼리들을 모아 하나의 함수처럼 사용하기 위한 것입니다. 공격에 사용되는 대표적인 저장 프로시저는 MS-SQL 에 있는 xp_cmdshell로 윈도우 명령어를 사용할 수 있게 됩니다. 단, 공격자가 시스템 권한을 획득 해야 하므로 공격난이도가 높으나 공격에 성공한다면, 서버에 직접적인 피해를 입힐 수 있는 공격 입니다.

Mass SQL Injection

다량의 SQL Injection 공격

 2008년에 처음 발견된 공격기법으로 기존 SQL Injection 과 달리 한번의 공격으로 다량의 데이터베이스가 조작되어 큰 피해를 입히는 것을 의미합니다. 보통 MS-SQL을 사용하는 ASP 기반 웹 애플리케이션에서 많이 사용되며, 쿼리문은 HEX 인코딩 방식으로 인코딩 하여 공격합니다. 보통 데이터베이스 값을 변조하여 데이터베이스에 악성스크립트를 삽입하고, 사용자들이 변조된 사이트에 접속 시 좀비PC로 감염되게 합니다. 이렇게 감염된 좀비 PC들은 DDoS 공격에 사용됩니다.

1.3 대응방안

입력 값에 대한 검증

SQL Injection 에서 사용되는 기법과 키워드는 엄청나게 많습니다. 사용자의 입력 값에 대한 검증이 필요한데요. 서버 단에서 화이트리스트 기반으로 검증해야 합니다. 블랙리스트 기반으로 검증하게 되면 수많은 차단리스트를 등록해야 하고, 하나라도 빠지면 공격에 성공하게 되기 때문입니다. 공백으로 치환하는 방법도 많이 쓰이는데, 이 방법도 취약한 방법입니다. 예를 들어 공격자가 SESELECTLECT 라고 입력 시 중간의 SELECT가 공백으로 치환이 되면 SELECT 라는 키워드가 완성되게 됩니다. 공백 대신 공격 키워드와는 의미 없는 단어로 치환되어야 합니다.

Prepared Statement 구문사용

 Prepared Statement 구문을 사용하게 되면, 사용자의 입력 값이 데이터베이스의 파라미터로 들어가기 전에DBMS가 미리 컴파일 하여 실행하지 않고 대기합니다. 그 후 사용자의 입력 값을 문자열로 인식하게 하여 공격쿼리가 들어간다고 하더라도, 사용자의 입력은 이미 의미 없는 단순 문자열 이기 때문에 전체 쿼리문도 공격자의 의도대로 작동하지 않습니다.

Error Message 노출 금지

공격자가 SQL Injection을 수행하기 위해서는 데이터베이스의 정보(테이블명, 컬럼명 등)가 필요합니다. 데이터베이스 에러 발생 시 따로 처리를 해주지 않았다면, 에러가 발생한 쿼리문과 함께 에러에 관한 내용을 반환헤 줍니다. 여기서 테이블명 및 컬럼명 그리고 쿼리문이 노출이 될 수 있기 때문에, 데이터 베이스에 대한 오류발생 시 사용자에게 보여줄 수 있는 페이지를 제작 혹은 메시지박스를 띄우도록 하여야 합니다.

웹 방화벽 사용

웹 공격 방어에 특화되어있는 웹 방화벽을 사용하는 것도 하나의 방법입니다. 웹 방화벽은 소프트웨어 형, 하드웨어 형, 프록시 형 이렇게 세가지 종류로 나눌 수 있는데 소프트웨어 형은 서버 내에 직접 설치하는 방법이고, 하드웨어 형은 네트워크 상에서 서버 앞 단에 직접 하드웨어 장비로 구성하는 것이며 마지막으로 프록시 형은 DNS 서버 주소를 웹 방화벽으로 바꾸고 서버로 가는 트래픽이 웹 방화벽을 먼저 거치도록 하는 방법입니다.

출처 : https://noirstar.tistory.com/264

ASP.Net MVC Core에서는 BundleConfig.cs를 제거하고 bundleconfig.json 파일로 대체했습니다. bundleconfig.json에서 번들을 설정해야합니다.. 프로젝트에 이 파일이 없으면이 이름으로 json 파일을 추가하고 사용하면 됩니다.

bundleconfig.json

예시

 // Configure bundling and minification for the project.
// More info at https://go.microsoft.com/fwlink/?LinkId=808241
[
  {
    "outputFileName": "wwwroot/css/site.min.css",
    // An array of relative input file paths. Globbing patterns supported
    "inputFiles": [
      "wwwroot/css/site.css"
    ]
  },
  {
    "outputFileName": "wwwroot/js/bundles.min.js",
    "inputFiles": [
      "wwwroot/js/site.js",
      "wwwroot/lib/jquery/dist/jquery.js",
      "wwwroot/lib/jquery/dist/jqueryvalidate.js"
    ],
    // Optionally specify minification options
    "minify": {
      "enabled": true,
      "renameLocals": true
    },
    // Optionally generate .map file
    "sourceMap": false
  }
]

_Layout.cshtml

 <script src="~/js/bundles.min.js"></script>

출처 : https://stackoverflow.com/questions/48415335/how-can-i-use-scripts-render-with-net-core-2-0-mvc-application

안녕하세요, 공백 기간이 또 길어졌습니다.

이번 글은 .NET 공식 블로그에 소개된 Introducing .NET 5를 번역한 글입니다. .NET Core 3.0을 끝으로 이제는 .NET 코어가 아닌 .NET 5라는 새로운 이름으로 소개되는데요, .NET 4또는 .NET Core 4.0으로 결정되지 않고 .NET 5로 불리게 된 이유는 .NET Framework 4.0과 헷갈릴 수 있기 때문이라고 합니다.

기울임꼴로 표시된 부분은 번역을 그대로 옮기면 자연스럽지 않아 제 맘대로 번역해봤습니다.
이 부분은 오역이구만? 이렇게 생각하시면 편할 것 같습니다.

Introducing .NET 5

오늘 우리는 .NET Core 3.0의 차기 버전인 .NET 5를 소개하려고 합니다.
이는 .NET 제품군에서 상당히 큰 변경을 포함할 것입니다. (next big release)

이제는 제품군이 나뉘지 않고 .NET 하나로 통합될 것이고 이를 다양한 플랫폼*에서 사용할 수 있게 됩니다.
(There will be just one .NET going forward / * 윈도우, 리눅스, 맥, iOS, Android, WebAssembly 등)

새로운 .NET API와 런타임 호환성/언어 기능들을 소개합니다.

새로운 .NET 소개

.NET Core 프로젝트를 시작할 때 개발팀은 약 5천개의 .NET 프레임워크 API를 추가했습니다. 이로써 .NET Core 3.0은 .NET Framework 4.8과 비교했을 때 기능 측면(Windows Forms, WPF 및 Entity Framework 6)에 있어 상당히 근접하게 되었습니다. 또한, .NET 5의 빌드 작업이 여기에 포함되었고 .NET Core + Mono 조합으로 당신의 멋☆진 .NET 코드를 사용할 수 있습니다! (.NET Core 3.0 closes much of the remaining capability gap with .NET Framework 4.8, enabling Windows Forms, WPF and Entity Framework 6. .NET 5 builds on this work, taking .NET Core and the best of Mono to create a single platform that you can use for all your modern .NET code)

.NET 5를 2020년 11월에 출시할 예정이고 첫 번째 Preview(베타 참여와 비슷한 개념입니다)는 2020년 상반기쯤에 사용할 수 있을 것입니다. 이는 추후에 업데이트를 통해 Visual Studio 2019, Visual Studio for Mac 그리고 Visual Studio Code 제품에서 지원될 예정입니다.

.NET 5 = .NET Core vNext

.NET 5는 .NET Core와 함께 한 걸음 나아간 것입니다. (.NET 5) 프로젝트는 .NET 을 향상시키기 위해 몇 가지 중요한 방법을 중점으로 두고 있습니다.

• 어디서든 사용될 수 있으며 동일한 런타임 환경, 개발자 경험을 제공하는 단일 .NET 런타임 / 프레임워크 생산 (uniform runtime behaviors, 프로그램을 실행했을 때 항상 동일한 동작을 하는 것을 말하는 것 같습니다. 이 부분은 저도 확실하지 않아 알려주시면 적극 반영하겠습니다.)
• .NET의 기능을 확장하기 위해 .NET Core, .NET Framework, Xamarin 그리고 Mono의 장점을 채용
• Build that product out of a single codebase that developers (ms) can work on and expand together and that improves all scenarios.

이 새로운 프로젝트와 방향성은 .NET 그리고 .NET 5에 어마어마한 변화를 가져올 줄 것입니다.

여러분의 코드와 프로젝트 파일은 여러분들이 어떤 종류의 앱을 개발하던지간에 동일하게 있을거예요! (your code and project files will look and feel the same no matter which type of app you're building. 여기서 말하는 앱이란 모바일 애플리케이션을 말하는 것이 아닌, WPF/Windows Forms/ASP 등 어떤 형태로 빌드를 해도 동일한 환경을제공한다는 의미로 쓰인 것 같습니다)

또한 각 앱마다 동일한 런타임, API 및 언어 기능에 접근할 수 있습니다. 이는 거의 매일 CoreFX에 커밋되는 수정사항으로 인해 새로운 성능 향상을 포함할 것입니다. (This includes new performance improvements that get committed to corefx, practically daily.)

여러분들이 사랑했던 .NET Core의 기능이나 특징들은 계속 이어나갈 것입니다.

• 오픈 소스 및 커뮤니티 중심적 (GitHub)
• 크로스 플랫폼 구현
• 플랫폼 종속적인 기능(대표적인 예로 Windows Forms나 WPF, 자마린을 이용한 네이티브 플랫폼 바인딩) 활용
• 높은 성능
• Side-by-side 설치
• 작은 프로젝트 파일 (SDK 스타일이라는데.. 뭐가 SDK 스타일이라는건지)
• 짱짱좋은 CLI
• Visual Studio, Visual Studio for Mac 그리고 Visual Studio Code 제품간의 통합

그리고 새로 추가되는 것들입니다.

• 런타임 경험에 대해 다양한 선택을 할 수 있습니다. (밑에 더 나와있음)
• 자바 Interop 기능은 모든 플랫폼에서 사용할 수 있을 예정입니다.
  (Interop 이란 상호 운용성을 말하는데, 쉽게 말해서 .NET에서 자바 코드를 사용할 수 있게 된다는 얘기입니다)
• Objective-C 그리고 Swift Interop 기능은 다양한 운영체제에서 지원될 예정입니다.
  (맥에 한정되지는 않을 것 같습니다. 원문에서도 on multiple operating systems 라고 나와있습니다)
• CoreFX에서 .NET의 정적 컴파일(AOT)을 지원하도록 확장하고, 더 작은 파일 크기와 다양한 운영체제에서 지원되도록 할 예정입니다.

.NET Schedule

.NET 개발 및 배포 계획

(글 맨 앞에서 설명드린 내용입니다)
우리는 .NET 프레임워크(4.x 버전을 긴 시간 사용해왔기 때문)를 주로 사용하던 사용자들이 .NET Framework 4.x 버전과 헷갈릴 수 있고 또 .NET 5가 .NET 플랫폼의 새로운 미래라는 것을 확실하게 전하고 싶었기 때문에 버전 4를 건너뛰도록 결정했습니다.

또한 단순한 이름을 사용하기 위한 기회를 잡았습니다. 우리는 "만약, 하나의 .NET만 개발된다면 'Core'를 명확하게 붙일 필요가 없지 않을까?" 라고 생각했습니다. 짧은 이름은 단순화 뿐만 아니라 .NET 5가 동일한 기능과 행동을 가진다는 것을 전달하기 위함입니다. 만약, ".NET Core"라고 부르는 것을 선호하신다면 그렇게 부르시면 됩니다.

Runtime experiences

Mono는 크로스플랫폼으로 구현된 최초의 .NET입니다. 이 프로젝트는 오픈소스로 시작하였고, .NET Framework의 대체제로 사용되었습니다. 그리고 모바일 기기가 대중화됨에 따라 모바일 기기도 지원하도록 변화하였습니다. Mono는 Xamarin의 런타임으로 사용되고 있습니다.

CoreCLR은 .NET Core의 런타임으로 사용되고 있습니다. .NET Core의 주 대상은 클라우드 애플리케이션(Microsoft에서 운영 중인 거대한 스케일의 서비스도 포함)을 지원하는 것이였지만 이제는 Windows Desktop, IoT 그리고 Machine Learning 애플리케이션에서도 사용되고 있습니다.

종합해보면 .NET Core하고 Mono 런타임은 상당히 많은 공통점(둘 다 .NET 런타임이니까요)을 가지고 있지만, 또 가치있는 고유의 기능들이 있습니다. 이는 사용자가 원하는 런타임 경험을 고를 수 있도록 해줄거예요. CoreCLR과 Mono의 성능을 다른 것보다 향상시키는 작업을 하는 중입니다. 우리는 이것을 간단하게 만들 예정입니다. 예를 들자면 빌드 스위치를 만들어 사용자가 다른 런타임 옵션을 설정할 수 있도록 하는 것 처럼요.

이후에 소개되는 주제에서는 .NET 5 계획에 있어 중요하다고 생각되는 것들을 설명할 것이고, 이는 우리가 어떻게 두 런타임(Mono와 CoreCLR을 말하는 것 같습니다)을 개별적으로 그리고 또한 같이 발전시킬 것인지 확실하게 보여줄 것입니다.

High throughput and high productivity

처음부터 .NET은 중간 언어(IL)를 머신에 최적화된 코드로 해석하기 위해 Just-in-Time (JIT) 컴파일러를 의지해왔습니다. 이후 우리는 아주 높은 처리량을 갖는 JIT 기반의 관리되는 런타임을 만들었습니다. 그리고 프로그래밍을 빠르고 쉽게 하기 위해 개발자 경험 또한 활성화했습니다. (Since that time, we've built an industry-leading JIT-based managed runtime that is capable of very high throughput and also enabled developer experiences that make programming fast and easy.)

JIT는 오래 지속되는 클라우드 및 클라이언트 시나리오에 적합합니다. JIT는 특정 머신 설정을 대상으로 한 코드를 생성(특정 CPU 명령 포함)할 수 있습니다. 또한, 런타임에 메서드를 재생성하는 것이 가능합니다. JIT를 빠르게 하기 위해 자주 사용되는 메서드일 경우 정밀하게 최적화된 코드를 생성하는 옵션을 추가했습니다. (a technique used to JIT quickly while still having the option to produce a highly-tuned version of the code if this becomes a frequently used method.)

ASP.NET Core를 TechEmpower의 프레임워크 벤치마킹에서 더 빠르게 동작하도록 하기 위한 노력은 JIT의 성능과 CoreCLR에 대한 투자를 보여주는 좋은 예입니다. 컨테이너를 위한 .NET Core를 더 강력하게 하는 우리의 노력은 제약된 환경에서 런타임의 기능을 동적으로 적응하는 것으로 보여주고 있습니다. (Our efforts to harden .NET Core for containers also demonstrates that runtime's ability to dynamically adapt to constrained environments.)

* TechEmpower Framework benchmark: 웹 프레임워크의 성능을 벤치마킹하는 것으로, 이 곳에서 웹 프레임워크의 성능 순위를 보실 수 있습니다.

개발자 도구는 JIT 기능의 동작을 보기에 아주 좋은 예제입니다. (another good example where JIT shines) dotnet watch 또는 edit and continue (편집하며 계속하기, 디버깅 중에 코드를 변경하고 변경된 코드를 프로그램의 재시작 없이 그대로 반영하는 것)기능을 예로 들 수 있습니다. 도구는 단일 프로세스에서 재시작을 하지 않고 빠르게 수행해야할 때 컴파일과 코드를 여러 번 불러오는 것을 자주 요구합니다. (Tools often require compiling and loading code multiple times in a single process without restarting and need to be do it very quickly.)

JIT을 주로 사용해오던 .NET Core 또는 .NET Framework 개발자 분들께서는 이 경험이 친숙할 것으로 보입니다.

기본적으로 .NET 5 작업의 경우 JIT 기반의 CoreCLR 런타임을 사용하게 됩니다. 다만, 두 가지 예외가 있는데 하나는 iOS이고 다른 하나는 클라이언트측의 Blazor (WebAssembly) 입니다. 둘 다 ahead-of-time (AOT) 컴파일을 필요로 하기 때문입니다.

Fast startup, low footprint, and lower memory usage

Mono 프로젝트는 모바일 및 게임 콘솔(Xbox, PlayStation 등)을 중점으로 많은 // 중요한 기능과 결과는 그 프로젝트는 .NET 기반의 AOT 컴파일러와 최신 LLVM 프로젝트입니다. // Mono의 AOT 컴파일러는 C++처럼 .NET 코드가 머신에서 실행될 수 있는 단일 네이티브 코드를 // AOT / 작은 공간에서도 효율적으로 실행될 수 있으며, 시작할 때 필요하다면 처리량을 줄이거나 늘리기도 합니다.

Blazor 프로젝트는 이미 Mono의 AOT를 사용하고 있습니다. 이 프로젝트는 .NET 5으로 변환한 첫 번째 프로젝트입니다. 우리는 우리의 계획을 증명하기 위한 방법으로 Blazor를 사용하고 있습니다. (We are using it as one of the scenarios to prove out this plan.)

두 가지 형태의 AOT가 있습니다. (There are two types of AOT solutions. / solutions를 따로 해석하지 않았습니다)

• 100% AOT 컴파일을 필요로 하는 것
• 대부분의 코드가 AOT로 컴파일 되었으나, JIT 또는 인터프리터가 사용 가능하고 또, 코드 패턴이 AOT와는 어울리지 않는 경우 (제네릭같은 것)

Mono AOT는 두 가지 형태 모두 지원합니다. 첫 번째 형태의 AOT인 경우는 보안상의 문제로 인해 애플의 iOS와 몇 가지 게임 콘솔에서 필요로 합니다. 두 번째는 AOT의 장점을 제공하면서도, 단점은 하나도 없이 사용할 수 있으므로 선호되는 방법입니다.

.NET Native는 우리가 Windows UWP 대상 애플리케이션을 만들 때 사용하는 AOT 컴파일러입니다. 그리고 위에서 나열한 AOT 첫 번째 형태의 예입니다. 특정 구현으로, 우리는 사용할 수 있는 .NET API와 기능을 제한했습니다. 우리는 이 경험을 통해 AOT는 모든 .NET API와 패턴을 커버해야 한다는 것을 배웠습니다. (.NET Native is the AOT compiler we use for Windows UWP applications and is an example of the first type of AOT listed above. With that particular implementation, we limited the .NET APIs and capabilities that you can use. We learned from that experience that AOT solutions need to cover the full spectrum of .NET APIs and patterns.)

AOT 컴파일은 iOS나 WebAssembly 및 몇몇 게임 콘솔의 요구로 없어지진 않을거예요. AOT 컴파일은 빠른 시작과 낮은 크기를 요구하는 애플리케이션을 위한 옵션으로 만들어질 예정입니다. (We will make AOT compilation an option for applications that are more appliance-like, that require fast startup and/or low footprint. appliance-like는 제외했습니다. 네이버 백과사전에서 찾은 의미인데, 도통 이해가 안가네요..)

Fundamentals and overlapping experiences

시작 시간, 처리량, 메모리 사용량, 안정성과 진단 기능을 갖춘 전체 플랫폼으로 나아가는 것이 중요합니다. 이와 동시에 우리의 노력을 여기에 집중하는 것도 말이 되구요. 우리는 CoreCLR의 처리량과 안정성에 더 많은 투자를 하는 한편, Mono AOT 컴파일러에도 시작 속도와 크기 감소에 더 많은 투자를 할 것입니다. 이러한 것들은 좋은 결합이라고 생각합니다. 그리고, 시작 속도와 크기 감소는 처리량과 안정성과 비례합니다. (It is critical that we continue to move forward as an overall platform with startup, throughput, memory use, reliability, and diagnostics. At the same time, it also makes sense to focus our efforts. We’ll invest more in throughput and reliability in CoreCLR while we invest more in startup and size reduction with the Mono AOT compiler. We think that these are good pairings. Throughput and reliability go together as do startup and size reduction.)

다른 투자를 하는 것이 더 나은 경우도 있지만, 그렇지 않은 경우도 있습니다. (there are some characteristics where it makes sense to make different investments)

진단 기능은 기능과 성능 진단을 위해 .NET 5에서 동일할 필요가 있습니다. 또한, 이는 같은 칩과 운영체제를 지원하기 위해서도 매우 중요합니다. (단, iOS와 Web Assembly는 예외입니다) (Diagnostics capabilities need to be the same across .NET 5, for both functional and performance diagnostics.)

우리는 각 작업과 시나리오에 대한 .NET 5 최적화를 계속 수행할 것입니다. 특히, 여러 작업이 중복되는 경우에는 최적화에 더 중점을 둘 것입니다.

모든 .NET 5 애플리케이션에서는 CoreFX를 사용하게 됩니다. 우리는 CoreFX가 자주 사용되지 않는 곳(주로, Xamarin이나 클라이언트측 Blazor 작업에서)에서도 제대로 동작하도록 보장할 것입니다.

모든 .NET 5 애플리케이션은 공용 명령줄 도구가 있는 경우, .NET CLI를 사용하여 빌드할 수 있을 것입니다. (ensuring that you have common command-line tooling across projects. )

C#은 이제 .NET 5와 함께 발전할 것입니다. .NET 5 앱을 작성하는 개발자는 항상 최신 버전의 C# 그리고 그 기능에 접근할 수 있을 것입니다. (이렇게 되면 C# 언어의 버전을 선택하는 과정이 없어질 것 같네요)

The birth of the project

2018년 12월에 보스턴에서 기술 팀을 만나 이 프로젝트를 시작했습니다. .NET 팀(Mono/Xamarin/.NET Core)과 유니티의 디자인 리더는 다양한 기술적 기능과 구조적 방향을 제시해줬습니다. (presented on various technical capabilities and architectural direction. / presented 를 발표하다로 해석했습니다.)

이제 우리는 이 프로젝트를 마치 제품의 묶음처럼 단일 팀으로 진행하고 있습니다. 12월 이후 우리는 몇몇 프로젝트에 많은 진전을 이뤄냈습니다. (moving forward on this project as a single team with one set of deliverables.)

• 런타임 <-> 관리되는 코드 레이어 / 99% 의 CoreFX 코드??? 뭐라는건지..
• MonoVM에서 CoreFX와 그 클래스 라이브러리들을 사용할 수 있음
• MonoVM에서 CoreFX의 구현을 이용하여 CoreFX의 모든 테스트를 실행할 수 있음
• MonoVM을 이용하여 ASP.NET Core 3.0 애플리케이션을 실행할 수 있음
• MonoDevelop/Visual Studio for Mac을 CoreCLR으로 실행할 수 있음

단일 .NET으로 구현하는 것은 중요한 의문을 가지게 합니다. 과연 대상 프레임워크는 어떤 것이 되는지? NuGet 패키지의 호환성 규칙은 이전과 동일할 것인지? 어떤 작업들이 설치 없이 .NET 5 SDK로 지원될 것인지? 특정 아키텍쳐를 대상으로 한 코드는 어떻게 작성할 것인지? .NET Standard가 여전히 필요할 것인지? 우리는 이러한 이슈들을 인지하고 작업하고 있으며, 조만간 디자인 문서를 공유하고 여러분께서 읽으신 후 피드백을 저희에게 주실 수 있도록 할 것입니다. (Which workloads should be supported out-of-the-box by the .NET 5 SDK?)

Closing

.NET 5 프로젝트는 중요하고 기대되는 .NET의 새 방향입니다. .NET이 더 간단해지지만 넓고 더 확장성있는 기능과 유용성을 갖는 것을 보실 수 있을겁니다. 새로운 C# 버전을 포함하여 새로운 개발 및 기능은 .NET 5의 일부가 될 것입니다. (The .NET 5 project is an important and exciting new direction for .NET. You will see .NET become simpler but also have broader and more expansive capability and utility. All new development and feature capabilities will be part of .NET 5, including new C# versions.)

우리는 대상 애플리케이션 형식이나 운영체제, 칩 아키텍쳐에 상관 없이 동일한 .NET API와 언어를 사용할 수 있는 밝은 미래를 보았습니다. 이는 Visual Studio나 Visual Studio for Mac, Visual Studio Code, Azure DevOps 또는 명령줄 인수를 이용하여 빌드 구성을 바꾸고 다른 애플리케이션을 빌드하는 것을 더 쉽게 만들어 줄 것입니다. (We see bright future ahead in which you can use the same .NET APIs and languages to target a broad range of application types, operating systems, and chip architectures. It will be easy to make changes to your build configuration to build your applications differently, in Visual Studio, Visual Studio for Mac, Visual Studio Code, Azure DevOps or at the command line. / 어떤 IDE나 편집 도구를 사용해도 설정이 쉬워지겠다는 얘기 같습니다.)

상당히 오랜 시간에 걸쳐 번역 작업을 마무리 했습니다. 모자란 영어 실력을 가지고 번역을 해서 죄송할 따름이지만, 번역하면서 느낀 가장 큰 키워드는 ".NET 플랫폼의 통합" 같습니다. 닷넷 코어나 프레임워크, 자마린 등 나뉘어 있던 플랫폼이 .NET 5 하나로 통합되면서 편리함을 챙기면서도 성능 면에서도 많은 발전이 있다고 하니, 정말로 기대가 되네요.

번역이 매끄럽지 않은 부분/틀린 부분은 댓글로 꼭 남겨주시면 감사드리겠습니다.

긴 글 읽어주셔서 감사합니다.

출처: https://slaner.tistory.com/192 [꿈꾸는 프로그래머]