토요일, 8월 27, 2016

[독서광] 생각하는 뇌, 생각하는 기계

그 어느 때보다 무더운 여름도 지나고 이제 가을로 접어들고 있으니 슬슬 블로그도 다시 시작해야겠다는 여유가 생긴다. 오늘은 간만에 서평을 하나 올려드리겠다. 팜 파일럿으로 유명한 제프 호킨스가 인공 지능과 관련해 많은 생각거리를 제공하는 '생각하는 뇌, 생각하는 기계'가 오늘의 주인공이다.

몇 년 전에 [일상다반사] 호프스태터와 인공지능이라는 글을 하나 올려드렸는데, 사람이 생각하는 방식 그대로를 컴퓨터에게 가르치려고 시도하는 사람이 호프스태터 뿐만이 아니라는 사실을 알게 되었다. 제프 호킨스는 그 당시 누구도 생각하지 못했던 그래피티라는 손쉬운 필기 입력 수단을 제공함으로써 PDA 세상을 싹슬이 해버린 팜 파일럿의 엄청난 성공을 뒤로 하고 뉴멘타라는 회사를 설립해 진정한 기계지능(Machine Intelligence) 연구에 집중하고 있다. 먼저 책을 읽기 전에 다음 동영상을 한번 감상해보시기 바란다(그러면 '생각하는 뇌, 생각하는 기계'가 어떤 내용으로 전개될지 확실하게 알게 될 것이다).

(한국어 자막이 담긴 영상은 테드의 '제프 호킨스 - 어떻게 뇌과학이 컴퓨터를 바꿀까' 참조)

이 책은 지능(원서 제목이 'On Intelligence'라는 사실을 기억하고 있으면 좋겠다)과 관련해 이 책을 지을 시점까지 연구된 최신 결과들을 알기 쉽게 설명하고 있다. 요즘 딥러닝으로 엄청나게 뜨고 있는 신경망을 시작으로 사람의 뇌와 관련해 여러 가지 지식을 정리한다. 그리고 나서 가장 중요한 기억의 비밀을 파헤친 다음에 지능의 새로운 기본 틀인 예측으로 넘어간다. 그거고 나서 피질의 동작 원리와 의식/창조성에 대해 집중한다. 마지막으로 지적 기계의 가능성과 장점에 대해 소개하면서 막을 내린다.

일반적인 인공지능 서적과는 달리 이 책은 철저하게 사람의 두뇌에 집중한다. 청각/촉각/시각 등 모든 감각을 동원해 세계에 대해 끊임없이 예측을 하며 각 예측들이 대단히 완벽하게 통합된다는 사실(예: 걸으면서 발을 내딛일 때마다, 뇌는 발의 움직임이 언제 멈출지 발에 닿은 물질이 얼마나 많은 반응을 줄지를 예측하며, 계단에서 발을 헛디디는 순간 예측에 뭔가 문제가 생겼음을 깨닫는다. 익숙한 멜로디를 들을 때, 다음 음이 들리기 전에 이미 머리 속에서 다음 음을 듣는다), 뉴런은 밀리초 단위로 동작하므로 나노초 단위로 동작하는 CPU에 비해 엄청 느리다는 사실, 기억에는 순서가 중요하므로 알파벳을 역순으로 발음하거나 노래를 거꾸로 부르기 어렵다는 사실, 여러 감각에서 나온 패턴들이 사실상 두뇌 내부에서는 동일하다는 사실은 이 책을 읽으면서 다시 한번 깜짝 놀란 내용이다.

책 후반부에 나오는 창조성에 대한 이야기는 기존 고정 관념에 정확하게 반하는 내용을 담고 있다.

창조성은 고도의 지능과 타고난 재능을 필요로 하는 비범한 특성이 아니던가? 그렇지 않다. 창조성은 그저 유추를 통해 예측을 하는 것이라고 정의할 수 있으며, 피질의 어디에서든 나타나고, 깨어 있을 때 당신이 계속 하는 일이기도 하다. 창조성은 낮은 수준의 것부터 높은 수준의 것까지 하나의 연속체를 이루고 있다.

창조성에 버금가는 인간의 중요한 특성인 상상 역시 예측을 입력으로 돌리는 신경 메커니즘으로 설명한다.

6층의 세포들은 계층 구조의 하위 영역으로 발을 뻗고 있지만, 거꾸로 4층의 입력 세포들로도 발을 뻗고 있다. 따라서 한 영역의 출력이 다시 자신의 입력이 될 수도 있다. 눈을 감고 하마를 상상해보면, 피질의 시각 영역은 실제로 하마를 보고 있을 때와 똑같이 활성을 띌 것이다. 당신은 상상하는 것을 본다.

인문학을 중요하게 여기는 분들께서 이 책을 읽으면 위와 같은 기계론적인 설명에 씩씩거릴지도 모르겠지만, 최근 딥러닝을 필두로 사람보다 더 나은 실리콘(?) 사람들이 출현함에 따라 사람도 아주 특이하고 이상한 생명체가 아니라는 결론에 도달할지도 모른다.

결론: 인공지능과 기계지능에 관심이 있는 분이라면 반드시 읽어보기 바란다. 강력 추천!

EOB

월요일, 7월 25, 2016

[일상다반사] 프론트엔드 엔지니어 구인

최근에 여러 가지 바쁜 일이 많아서 블로그에 거미줄이 많이 쳐진 상황이다. 다시 일상에 복귀했으므로, 기념으로 글을 하나 올려본다. 놀랍게도 오늘 주제는 구인이다. 블로그를 열고 나서 구인글은 처음이지 않나 싶다.

다름이 아니라, 엑셈에서 SaaS 형 성능관리 소프트웨어인 APM(Application Performance Management) 제품 개발을 진행하고 있는데, 함께 작업할 수 있는 호기심과 상상력이 풍부한 프론트엔드 엔지니어를 모시려고 한다. 혹시나 다음 조건을 읽어보시고 마음이 동하시는 프론트 엔드 엔지니어분들께서는 jrogue 에뜨 gmail.com 으로 지원을 부탁드리겠다. 노파심에서 말씀드리지만 울트라 초사이언인 개발자를 뽑을 의도는 없으므로 각 조건을 빠짐없이 AND로 연결할 필요는 없다.

  • HTML/CSS 명세를 밑줄 그어가면서 읽어보신 분
  • 자바스크립트 완벽 가이드HTTP 완벽 가이드를 완독하신 분
  • 자바스크립트의 메모리 관리 방법, 단일 스레드에 따른 콜백 매커니즘, 가베지 컬렉션 알고리즘, 스코프 규칙을 이해하시는 분
  • D3 등 차트 관련 라이브러리를 사용하다가 불편해서 직접 코드를 열어 손을 본적이 있는 분
  • 시각적인 웹 페이지 구성을 넘어서 웹 애플리케이션 관점에서 큰 틀을 잡고 작업을 하시는 분
  • 디자인 가이드라인에 따라 다양한 브라우저, 다양한 해상도, 다양한 폰트 렌더링 엔진을 고려해 설계와 구현을 하시는 분
  • AJAX를 넘어서 JSON 형태의 데이터 전송에 Websocket을 사용해보신 분.
  • SPA(Single Page Application)이 무엇이며, 어떤 이유로 이런 기술이 등장했는지 이해하시는 분
  • HTTP/2가 HTTP/1.1에 비해 개선된 사항을 정리하실 수 있는 분
  • CORS(Cross Origin Resource Sharing)를 고려하면서 XSS(Cross Site Scripting)와 CSRF(Cross Site Request Forgery) 공격을 방어할 수 있는 분
  • 클라이언트 쪽에서 자바스크립트 성능을 높이기 위해 여러 가지 다양한 시도를 해보신 분
  • 브라우저의 개발자 도구에 능숙하며, 메모리 누수와 자원 활용을 점검하고 자동화된 단위 테스트와 헤드리스 브라우저를 사용해 테스트를 하시는 분
  • 필요에 따라 자바스크립트 전처리 도구와 의존성 관리자를 활용하시는 분
  • 다양한 자바스크립트 오픈소스 라이브러리에 대한 경험이 풍부하신 분
  • 크롬 캔버스 등을 활용해 그리기 성능을 높여보신 분
  • 사용자 중심의 개발 철학을 중요하게 생각하시는 분

아무쪼록 훌륭한 프론트엔드 엔지니어분들께서 지원해주시기를 학수고대하고 있겠다.

EOB

토요일, 5월 21, 2016

[B급 프로그래머] 10가지 성능 실수

Top 10 Performance Mistakes라는 글이 있어 독자 여러분에게 간략하게 요즘을 소개해드리겠다. 내용은 다름이 아니라 우리가 자주 저지르는 성능 관련 실무 목록이다.

  • 10. 업그레이드하지 않음: 많은 회사들이 시스템이 충분히 빠르지 않다고 불평을 하며, 더 나은 알고리즘과 자료 구조를 찾지만, 실제로는 "업그레이드"가 필요한 경우가 많다. 운영체제, JVM이나 CLR 등을 업그레이드해야 하는데, "새로운 버전에 버그가 있을지도 모른다"며 변명을 댄다.
  • 9. 중복된 작업: 웹 페이지를 서비스하는 시스템이 아주 느린 바람에, 개발자들이 데이터베이스 문제로 생각해서 실제로 튜닝 작업에 들어갔다. 하지만 프로파일러를 돌려보니 ORM을 7000번 호출하는 루프가 존재했기에 페이지 읽기가 느렸다. 루프를 수정하고 나니 시스템이 정상으로 돌아왔다.
  • 8. 데이터 적재: 메모리 관련 연산은 유형에 따라 다르다. 다양한 자료 구조의 성능에 대한 기초 지식이 있어야 한다. 예를 들어, 2GB 이상의 자료인 경우 자바의 HashMap이 .Net의 Dictionary보다 10배 이상 느리다. 물론 .Net이 자바보다 느린 경우도 있다.
  • 7. 너무 많은 할당: 메모리를 너무 많이 할당할 경우 가베지 컬렉터가 대규모 데이터 집합을 처리하느라 상당한 시간을 소비한다.
  • 6. 병행 프로그래밍: 특정 알고리즘에서는 병행 프로그래밍이 아주 매력적이지만, 한계와 부하가 존재한다. 암달의 법칙과 USL(Universal Scalability Law)를 생각해야 한다. 특히 병행 시스템에서 구성 요소 사이의 통신과 관련한 성능에 특히 주의해야 한다.
  • 5. TCP에 대한 이해 부족: TCP를 제대로 이해하지 못한 상태에서 마이크로서비스를 고려하는 실수가 의외로 많다. Nagle 알고리즘을 비활성화하기 위해 TCP_NODELAY를 고려하고, 여러 작은 패킷을 차례로 전송하자.
  • 4. 동기식 통신: 클라이언트와 서버 사이의 동기식 통신은 빠른 통신이 필요한 시스템에서 문제로 등장한다. 더 비싸고 빠른 하드웨어 대신 비동기식 통신을 고려하자.
  • 3. 텍스트 인코딩: JSON이나 XML과 같은 텍스트 인코딩 형식을 사용해 데이터를 전송하는 방법을 택하는 이유는 "인간이 읽을 수 있기" 때문이다. 하지만, 두 시스템 사이에서 통신이 일어날 때 사람이 읽는 경우는 없다. 물론 텍스트 편집기로 디버깅은 편하겠지만, CPU를 많이 소비하게 된다. 이진 형식을 고려하자.
  • 2. API 설계: 성능에 가장 부정적인 영향을 주는 몇 가지 실수는 API와 관련이 있다. API만 제대로 설계되더라도 불필요한 메모리 복사와 추가 처리가 필요하지 않다.
  • 1. 로깅: #1 성능 문제의 주범은 로깅에 소비되는 시간이다. 스레드를 아무리 많이 사용하더라도 로깅에 필요한 시간은 선형적으로 증가한다. 로거는 시스템에서 찾을 수 있는 최고 병목 중 하나다. 해법은 비동기식 로거 사용이다. 또한 동일한 오류를 계속해서 저장하는 방법도 피해야 한다. 처음 오류가 발생했을 때 한 번만 찍는 방안을 고안하자.
EOB