우연의 설계

복잡성에 대해 이야기하면서 무작위성과 확률에 대해 집중하여 이야기 하는 책. 무작위성이 어떻게 현실 세계에 영향을 미치는가를 여러 분야에 걸쳐 설명하고 있다.

나도 현실 세계는 점진적인 것으로는 도달할 수 없는 영역이 있고, 그것을 넘어서기 위해서는 도약이 수반되어야 한다고 믿는 입장이고 –이른바 혁신과 최적화– 책에서 주장하는 바와 같이 우주의 아주 본질적인 부분에 무작위성이 개입되어 있다고 믿기 때문에 책의 내용을 매우 흥미롭게 읽을 수 있었다.

우주는 확률과 지수적인 변화 –카오스– 에 기반하기 때문에 우주의 모든 요소를 측정하더라도 미래 예측은 본질적으로 불가능하다. 우주라는 비디오 테이프를 처음으로 돌려 다시 재생하면 나라는 개인은 물론 지금과 같은 모습의 호모 사피엔스라는 종도 출현하지 않을 것이다. –물론 도구를 사용하고 집단 협업이 가능한 지적인 생명체는 생명이 출현했다면 시간의 문제일 뿐 대단히 높은 확률로 존재할 것이다– 책에서도 언급 되지만 초기의 작은 오차는 지수적인 변화로 인해 급격한 차이를 만들고 나중에는 전혀 본체를 잡아 먹어 전혀 다른 양상을 만들어 낸다. –양자역학의 확률적인 부분을 다중우주라는 개념으로 결정적인 것으로 확장시키는 것은 사실 못 믿겠다. 그냥 우주가 불완전하고 불확정적이라는 것을 받아들이자는게 내 입장.

이것을 이해하면 불확실성을 받아들이는 것이 중요하다는 것을 깨닫게 되고, 어떻게 불확실한 외부세계에 대응할 것인가를 생각할 수 있게 된다 –책에 나오는 완전 무작위는 그 방법 중의 하나.

요즘 책을 좀 훑듯이 읽는 습관이 생겼는데, 기회가 되면 꼼꼼히 정리를 해 봐야겠다. 복잡성에 대한 대중적인 책에서 이미 많이 언급되는 내용도 많지만, 보다 촘촘하게 이해할 수 있는 내용도 많은 듯.

카카오 AI 리포트

AI 관련 연구, 개발자나 현업 사람들 등 다양한 사람들이 다양한 관점에서 AI에 대해 정리한 리포트를 한 권의 책으로 엮어낸 책. 자율주행(+교통)과 의료에 대한 이야기 비중이 좀 크다.

서점에서 얼핏 보고 기술적인 내용이 있길래 샀는데, AI 기술 자체에 대한 내용은 일부 적용 사례 리포트에 정리된 것이었고 대부분은 새로 등장한 AI 기술에 대한 전망이나 응용에 대한 내용이라 그냥 일종의 ‘2019년 트랜트’ 같은 책처럼 읽으면 될 듯 하다.

사실 나도 딥러닝 기술에 대해서는 몰라서 오히려 너무 기술적인 내용은 자세히 있더라도 이해는 못 했을 듯. 실제로 잘 이해 못한 리포트들이 많았다.

죽기 전에 알아야 할 5가지 물리법칙

교양 물리 서적. 제목에서 알 수 있듯 5가지 물리학 개념을 발견자 개인에 대한 이야기와 함께 다루고 있다. 큰 틀에서 보자면 고전 역학에서 상대성 이론 – 양자역학으로 가는 줄기에 있는 내용이 다뤄지는데 추가로 엔트로피 개념이 정립된 통계 역학 부분도 다뤄지고 있다. –이 부분 때문에 이 책을 읽었음.

가볍게 읽을 수 있는 내용이기 때문에 관심 있다면 한 번 쯤 읽어 볼 만한 책. –중간에 수식도 살짝 나오는데, 나는 내가 물리학도도 아니고 이런 내용은 대개 넘겨가며 읽는 편. 설마 책에 틀린 수식을 써 놨을까

개인적인 취향이 어쩌다 맞았는지 모르겠지만 교양 물리학은 보통 위 흐름 (고전역학 -> 상대성 이론 -> 양자역학) 대로 다뤄지는데, 묘하게도 그 흐름에서 전자기학은 잘 다뤄지지 않는 것 같다. 전자기학을 보려면 전자기학을 다루는 내용을 따로 찾아서 봐야 함. 묘한 일.

일상적이지만 절대적인 과학철학지식 50

제목 그대로 과학 철학에 대한 여러 이야기들을 담은 책. 과학을 접하면 한 번쯤 들어 봤을 법한 합리주의, 귀납주의, 유물론, 패러다임 등 여러 개념들에 대한 내용이 담겨 있다.

흥미롭게도 ‘불완전성’, ‘불확정성’ 같은 어떤 내용에 대한 설명도 담겨 있는데, 과학사에 큰 영향을 미친 여러 것들을 두루 담았다고 보면 될 듯.

이전에 읽은 <일상적이지만 절대적인 뇌과학지식 50>과 달리 번역도 깔끔해서 교양으로 읽기 좋다. 과학 자체에 대한 책은 많지만 이렇게 과학사와 과학 철학을 훑는 책은 많지 않아서 기회가 되면 다시 한 번 꼼꼼히 읽어 보고 정리해 두고 싶다는 생각을 했음.

일상적이지만 절대적인 뇌과학지식 50

제목 그대로 뇌과학에 대한 대중 교양서. 이전에 읽다가 포기한 물리학편 보다는 좀 더 대중적이고, 이전에 읽었던 화학편과 비슷한 듯. 뇌과학에 대해 아예 아무것도 모르면 따라가기 어려운 부분들이 좀 있다.

그래도 재미있는 내용이 많았고, 배운 것도 많았다. 차후에 따로 공부해도 괜찮겠다 싶었음. 다만 번역이 영 별로.

C# 6.0 완벽 가이드/ Roslyn 컴파일러

  • C# 6.0에는 완전히 C#으로 작성된 새로운 컴파일러가 있다. 새 컴파일러는 모듈식으로 구성되어 있어서, 소스 코드를 실행 파일이나 라이브러리로 컴파일하는 것 말고도 그 기능들을 다양한 방식으로 활용할 수 있다. Roslyn(로즐린)이라는 이름의 컴파일러 덕분에 정적 코드 분석 도구나 리팩터링 도구, 구문 강조 기능과 코드 완성 기능을 갖춘 편집기, 그리고 C# 코드를 이해하는 Visual Studio 플러그인을 만들기가 좀 더 쉬워졌다.
    • Roslyn 라이브러리들은 NuGet에서 내려받을 수 있다. C#용 패키지뿐만 아니라 VB용 패키지도 있다. 두 언어는 일부 구조를 공유하므로, 의존하는 라이브러리들도 일부 겹친다. C# 컴파일러 라이브러리들의 NuGet 패키지 ID는 Microfost.CodeAnalysis.CSharp이다.
    • Roslyn의 소스 코드는 Apache 2 오픈소스 사용권 하에 공개되어 있다. 이 소스 코드는 또 다른 가능성을 열어주는데, 예컨대 C#을 커스텀 언어 또는 영역 국한 언어(domain-specific language)로 바꾸는 것도 가능하다. 소스코드는 GitHub의 Roslyn 페이지(https://github.com/dotnet/roslyn)에서 내려받을 수 있다.
    • GitHub의 Roslyn 페이지에는 문서화와 예제들 그리고 코드 분석과 리팩터링 방법을 보여주는 단계별 튜토리얼들이 있다.
  • Roslyn C# 컴파일러 라이브러리를 구성하는 어셈블리들은 다음과 같다.
    • Microsoft.CodeAnalysis.dll
    • Microsoft.CodeAnalysis.CSharp.dll
    • System.Collections.Immutable.dll
    • System.Reflection.Metadata.dll

Roslyn의 구조

  • Roslyn은 컴파일 과정은 다음 세 단계로 나누어서 진행한다.
    1. 코드를 구문 트리로 파싱한다. 이 단계는 구문층(syntatic layer)에 해당한다.
    2. 식별자들을 기호(symbol)들에 묶는다(바인딩). 이 단계는 의미층(semantic layer)에 해당한다.
    3. IL 코드를 산출한다.
  • 첫 단계에서 파서는 C# 코드를 읽어서 구문 트리(syntax tree)를 출력한다. 구문 트리는 소스 코드의 구조와 내용을 트리 형태로 구성한 DOM(Document Object Model; 문서 객체 모형)이다.
  • 둘째 단계에서는 C#의 정적 바인딩(static binding)이 일어난다. 이 단계에서 컴파일러는 어셈블리 참조 정보를 마련해서, 이를테면 ‘Console’ 이라는 식별자가 mscorlib.dll의 System.Console을 지칭한다는 사실을 파악한다. 중복적재 해소와 형식 추론도 이 단계에서 일어난다.
  • 셋째 단계는 출력 어셈블리를 만들어 낸다. 독자가 코드 분석이나 리팩터링을 위해 Roslyn을 사용할 계획이라면 이 셋째 단계는 필요하지 않을 것이다.

Continue reading

C# 6.0 완벽 가이드/ 정규 표현식

  • 정규 표현식(regular expression) 줄여서 정규식(regex)은 문자 패턴을 식별하는 수단이다.
    • 정규식을 지원하는 .NET 형식들은 Perl 5의 정규 표현식 문법을 따르며, 패턴을 찾는 기능뿐만 아니라 찾아 바꾸는 기능도 지원한다.
  • 정규 표현식은 이를테면 다음과 같은 과제에 쓰인다.
    • 패스워드나 전화번호 같은 텍스트 입력의 유효성 점검(ASP.NET은 이 용도만을 위해 ReularExpressionValidator라는 컨트롤을 제공한다)
    • 텍스트 자료를 좀 더 구조화된 형태로 파싱(이를테면 HTML 페이지에서 자료를 추출해서 데이터베이스에 저장하는 등)
    • 문서에 있는 특정 패턴의 텍스트를 치환

정규 표현식의 기초

  • 정규 표현식에는 여러 연산자가 있는데, 그중 한정사(quantifier; 양화사)라고 부르는 연산자들이 특히나 많이 쓰인다.
    • 한정사 중 하나인 ?는 그 앞의 항목이 0회 또는 1회 나와야 한다는 뜻이다. 다른 말로 하면 ?는 그 앞의 항목이 선택적(optional)임을 뜻한다.
    • 예컨대 “colou?r”라는 정규 표현식은 color와도 부합하고 colour와도 부합하지만, colouur와는 부합하지 않는다.
Console.WriteLine(Regex.Match("color", @"colou?r").Success);  // True
Console.WriteLine(Regex.Match("colour", @"colou?r").Success);  // True
Console.WriteLine(Regex.Match("colouur", @"colou?r").Success);  // False
  • Regex.Match는 주어진 문자열에서 주어진 패턴과 부합하는 부분 문자열을 찾는다.
    • 이 메서드가 돌려주는 객체에는 패턴과 부합하는 부분 문자열의 시작 색인을 담은 Index 속성과 길이를 담은 Length 속성, 그리고 부함 문자열 자체를 담은 Value 속성이 있다.
Match m = Regex.Match("any colour you like", @"colou?r");

Console.WriteLine(m.Success);  // True
Console.WriteLine(m.Index);  // 4
Console.WriteLine(m.Length);  // 6
Console.WriteLine(m.Value);  // colour
Console.WriteLine(m.ToString());  // colour
  • Regex.Match를 string의 IndexOf 메서드의 좀 더 강력한 버전이라고 생각해도 될 것이다. 차이점은 Regex.Match는 주어진 문자열을 곧이곧대로 검색하는 것이 아니라 패턴을 검색한다는 것이다.
  • IsMatch 메서드는 Match 호출 후 Success 속성을 판정하는 과정을 하나로 엮은 단축 메서드이다.
  • 정규 표현식 엔진은 기본적으로 왼쪽에서 오른쪽으로 패턴을 점검하므로, Match는 가장 왼쪽의 부함만을 돌려준다. 더 많은 부합을 얻으려면 NextMatch 메서드를 사용해야 한다.
Match m1 = Regex.Match("One color? Threre are two colours in my head!", @"colou?rs?");
Match m2 = n1.NextMatch();
Console.WriteLine(m1);  // color
Console.WriteLine(m2);  // colour
  • Matches 메서드는 모든 부합을 배열에 담아 돌려준다.
foreach (Match m in Regex.Match("One color? Threre are two colours in my head!", @"colou?rs?"))
  Console.WriteLine(m);
  • 흔히 쓰이는 또 다른 정규 표현식 연산자로 대안 선택자(alternator)가 있다. 대안 선택자는 수직선 기호 |로 표시한다. 대안 선택자는 말 그대로 선택할 수 있는 대안들을 표현한다.
    • 예컨대 다음은 “Jen”이나 “Jenny”, “Jennifer”와 부합한다.
Console.WriteLine(Regex.IsMatch("Jenny", "Jen(ny|nifer)?"));  // True
  • 대안 선택자를 감싸는 괄호는 대안들을 정규식의 나머지 부분과 구분하는 역할을 한다.
  • .NET Framework 4.5 부터는 정규 표현식 부합 메서드 호출 시 만료 시간을 지정할 수 있다.
    • TimeSpan 객체로 주어진 시간이 다 지나도 부합 연산이 완료되지 않으면 RegexMatchTimeoutException 예외가 발생한다.
    • 임의의 정규 표현식(이를테면 고급 검색 대화상자에 사용자가 입력한 정규식)을 처리하는 프로그램이라면 잘못된 또는 악의적인 정규 표현식 때문에 프로그램이 무한히 멈추는 일을 방지하기 위해 이러한 시간 만료 기능을 활용하는 것이 바람직하다.

Continue reading

C# 6.0 완벽 가이드/ 상호운용성

네이티브 DLL 호출

  • Platform Invocation Services(플랫폼 호출 서비스)를 줄인 P/Invoke는 .NET 응용 프로그램에서 비관리(unmanaged; .NET이 관리하지 않는) DLL에 있는 함수나 구조체, 콜백에 접근하는데 사용하는 기술이다.
  • 예컨대 Windows DLL user32.dll에 있는 MessageBox 함수를 생각해 보자. 이 C함수는 다음과 같이 선언되어 있다.
int MessageBox(HWND hWnd, LPCTSTR lpText, LPCTStr lpCaption, UINT uType);
  • .NET 응용 프로그램에서 이 함수를 직접 호출하는 것은 생각보다 쉽다. 같은 이름의 정적 메서드를 선언하되 extern 키워드를 적용하고 DllImport 특성을 부여하면 된다.
using System;
using System.Runtime.IneropServices;

class MsgBoxTest
{
  [DllImport("user32.dll")]
  static extern int MessageBox(IntPtr hWnd, string text, string caption, int type);

  public static void Main()
  {
    MessageBox(IntPtr.Zero, "Please do not press this again.", "Attention", 0);
  }
}
  • 실제로 System.Windows 이름공간과 System.Windows.Forms 이름공간에 있는 MessageBox 클래스들이 이와 비슷한 비관리 메서드들을 이런 식으로 호출한다.
  • CLR에는 .NET 형식들과 비관리 형식들 사이에서 매개변수들과 반환 값들을 변환하는 방법을 아는 인도기(marshaler)가 있다.
    • 지금 예에서는 int 매개변수는 함수가 기대하는 4바이트 정수로 직접 대응되며, 문자열 매개변수는 2바이트 유니코드 문자들의 널 종료(null-terminated) 배열로 변환된다.
    • IntPtr은 비관리 핸들을 캡슐화 하도록 만들어진 하나의 구조체로, 그 너비는 32비트 플랫폼에서는 32비트이고 64비트 플랫폼에서는 64비트이다.

Continue reading

컴퓨터 과학 로드맵

교양 컴퓨터 과학 책. 제목만 보고 예상했던 것과 달리 알고리즘과 데이터에 대한 내용이 대부분이라서 기대와는 좀 달랐음. 하드웨어나 프로그래밍 언어론 같은 부분이 좀 다뤄질 줄 알았는데 그런 내용은 후반부에 조금 나온다.

그나저나 책에서도 인용 되는 내용이지만, 소프트웨어에 왜 과학(science)이나 공학(engineering)이라는 단어가 쓰이는지 궁금하다.

애초에 컴퓨터를 설계한 사람도 수학자이고, 소프트웨어는 논리를 기반으로 동작하기 때문에, 과학이나 공학보다는 수학과 좀 더 관계가 깊을 것 같은데, 왜 그런 용어가 붙었는지 궁금함. –비슷한 맥락에서 programmer를 software engineer라고 부르는 것도 적절하지 못하다고 생각함

물론 컴퓨터 하드웨어는 과학/공학이라는 말에 맞는 것 같긴 하지만.

C# 6.0 완벽 가이드/ 응용 프로그램 도메인

  • 응용 프로그램 도메인(appication domain)은 .NET 프로그램이 실행되는 하나의 실행 시점 격리 단위(unit of isolation)이다.
  • 응용 프로그램 도메인은 관리되는 메모리 경계로 작용하며, 적재된 어셈블리들과 응용 프로그램 구성 설정들을 담는 컨테이너이기도 하다. 또한 분산 응용 프로그램의 경우 통신의 경계를 나타내기도 한다.
  • 일반적으로 하나의 .NET 프로세스는 하나의 응용 프로그램 도메인을 수용한다. 프로세스 시동시 CLR이 자동으로 생성한 기본(default) 도메인이 바로 그것이다.
    • 그러나 한 프로세스가 응용 프로그램 도메인들을 더 생성하는 것이 가능하며, 종종 유용하다.
    • 응용 프로그램 도메인을 추가로 생성하면 개별 프로세스들을 둘 때 발생하는 통신상의 복잡한 문제를 피하면서도 코드 실행 단위들을 서로 격리할 수 있다.
    • 이러한 접근방식은 부하 검사나 응용 프로그램 부분 갱신(patching) 같은 시나리오에 유용하며 안정적인 오류 복구 메너티즘을 구현할 때에도 유용하다.
  • 이번 장은 Windows 스토어 앱이나 CoreCLR 앱과는 무관하다. 그런 앱에서는 오직 하나의 응용 프로그램 도메인만 사용할 수 있다.

응용 프로그램 도메인의 구조

  • 아래 그림은 단일 도메인, 다중 도메인, 그리고 전형적인 분산 클라이언트/서버 응용 프로그램 도메인 구조를 나타낸 것이다. 대부분의 경우, 응용 프로그램 도메인을 수용하는 프로세스들은 운영체제가 암묵적으로 생성한다. (예컨대 사용자가 .NET 실행 파일을 더블클릭하거나 Windows 서비스가 시작될 때)
    • 그러나 IIS 같은 다른 프로세스가 응용 프로그램 도메인을 가지거나 SQL Server가 CLR 통합을 통해서 응용 프로그램 도메인을 가지기도 한다.
  • 단순한 실행 파일에서 비롯된 프로세스는 기본 응용 프로그램 도메인의 실행이 끝나면 함께 끝난다. 그러나 IIS나 SQL Server 같은 호스트에서는 프로세스가 그 수명을 제어한다.
    • 즉 필요에 따라 .NET 응용 프로그램 도메인을 생성하고 파괴한다.

Continue reading