소프트웨어 이야기 37

유튜브를 보고

인공지능 수업 들을 때, 지도교수의 옛날 얘기에서 레퍼토리 중 하나가 소프트웨어 모든 분야들이 실은 인공지능 하던 동료나 선배들의 연구 중 부산물로 나온 것들이라고. 나는 패턴에서 어떻게 기호가 출현하는지 궁금했다. 지금도 그렇다. 구글의 브린과 페이지가 쓴 초기 검색 논문을 보면 이 친구들 인공지능/기계학습 쪽 이라는 것이 보인다. Peter Russel이 "의식"이라는 좀 철학적인 주제에 관한 얘기를 한다. Einstein, Jung, Kant를 넘나들면서 space-time continuum, 빛 그리고 "경험"의 관계를 풀어나간다. "The hard question is not how does insentient matter ever give rise to experience, but how do..

some kind of mentor

애송이 개발자에게 멘토하기를, 너가 프로그램을, 칠판을 눈여겨 관측하다가, 원하는 패턴이 나오면 잽싸게 거기에 맞는 알고리즘을 전략적으로 지나치지도 모자라지도 않게 딱 맞는 멀티 스레드로 짤 수 있다고 하자. 너의 머리가 이렇게 구조화되어 이런 것이 자연스럽다 하자. 그렇지만, 내가 분명히 말하건데 그렇게 하는 것이 조금이라도 다른 방법보다 더 리스키하다던가, 개발 시간이 오래 들면 그 건 안된다. if then else 형태로 100배 크고, 100배 느려도 기한을 맞추면 그게 맞는 것이다. 이런 것을 이쪽 세계에서 효율화, 리스크 회피 방법이라 한다. 너가 받는 돈 만큼 품질을 맞추어라. 이런 것을 생태계에 적응한다, 먹이사슬에 포함된다, 또는 좋은 말로 value chain에 한 몫을 담당한다고 한..

빅데이터와 하둡 사이의 적정 거리는?

요즘 얘기되는 빅데이터는 하둡이 나오지 않았으면 가능하지 않았습니다. 전부터 필요성은 있었지만 이런 분산처리 구조를 만드는데 드는 "공구리 골조" 공사가 보통이 아닐뿐더러 성공사례도 찾기 힘들었을 터인데 구글이 이렇게 한다니닌까 불이 지펴진게 아니겠습니까? 앞으로 빅데이터를 하둡을 떼어놓고 생각할 수 있을까요? 거의 10년전 구글이 MapReduce를 막 발표했을 때 그 처리 스타일을 간단히 시뮬레이트 해 보는 프로그램을 만들었습니다. 많은 사람들이 그랬을 것입니다. 1주 정도 걸렸는데 색인에 필요한 태스크들은 Mapping과 Reducing 하기에 원천적으로 적절하지만 내가 관심있는 분석/Machine Learning을 해보려니 힘들 것 같았습니다. 지금도 그렇지 않을까 생각합니다. 빅데이터가 항상 필..

오픈소스와 명품과의 거리

R 과 Hadoop을 갖고 놀다가 이런 생각이 든다. 왜 오픈소스와 같은 개념이 명품 핸드백, 구두, 옷, 유모차 같은 것에는 출현하지 않는 것일까? "이 핸드백은 말야, 샤넬 핸드백 만든 사람보다 더 전문가가 실비로 좋은 뜻으로 만든 것인데 퍽 괜찮아. 그렇지만 이 것을 들면 너 돈 많다고 다른 사람들이 여겨진 않을거야" 이런 이유 때문인가?만약 오픈소스가 나오지 않았다면 어떻게 되었을까? 소프트웨어에도 브랜드가 힘을 쓰게 되었을까?

Big Data 단어 유감

빅데이터를 보통 기존의 DBMS나 파일 방식으로 처리하기 곤란한 매우 크고 복잡한 데이터를 처리하는 IT 방식이라 말한다. Tera, Peta 바이트 규모를 넘어 Exa 레벨의 데이터처리도 생각하고 있다 한다. 필요도 공감되고 더욱 좋은 기술이나 방법도 나올 것이라 생각한다. 하지만 빅데이터라는 낱말은 여전히 어색하게 들린다. 마케팅과 세일즈 필요에 의해 이 단어을 만들었다고 이해하려고 해도 그렇다. 컴퓨터가 원래 대용량 데이터를 처리하기 위해 탄생했고 지금껏 IT 발전의 가장 큰 동기가 더 크고 복잡한 데이터처리를 가능하게 함에 있었는데 새삼 빅테이터는 무슨 뒷북 치는 말인지. 낱말의 뜻 자체부터 오리무중이다. Teradata는 30년 전에 생겼고 구글은 Googol을 생각하다 Google이 되었는데...

간단한 C++ 전략 패턴

#include #include // typeid 를 사용하기 위해서 using namespace std; // 문제 : 디바이스 타입별로 읽기, 쓰기가 다르고 앞으로도 계속 새로운 디바이스 타입들이 나올텐데 어떻게 하면 기존 프로그램의 수정을 최소로 하고 기계적으로 // 새로운 디바이스를 지원할 수 있을까? // 해결책 : 디바이스 타입별로 다른 읽기/쓰기를 독립된 각각 독립된 객체로 만들고 이 것을 이용하는 client에 이 객체들을 담을 수 있는 추상클래스를 갖도록 하고 // 전체 디바이스를 아우르는 Device 추상 클래스를 만들고 구체적인 디바이스 타입별 클래스는 이 녀석을 상속한다. Client는 추상클래스(인터페이스)에 대해 프로그래밍한다. // Client는 추상클래스에 대해 읽기/쓰기를 ..

멀티스레딩

멀티스레딩을 어렵게 생각하는 경우가 있는데 기본 원리를 이해하면 쉽게, 정확하게 만들 수 있다. 좋은 멀티스레딩 구조를 만드려면 77%가 좋은 모델링/설계, 23%가 멀티스레딩이 돌아갈 플랫폼/OS/프로그래밍 언어 특성에 대한 지식이 필요하다. 쉽고 실용적인 (work) 멀티스레딩 원리 :1. 스레드들이 최대한 독립적으로 돌 수 있도록 한다. 자기를 생성한 스레드나 다른 스레드와의 교류를 최소한으로 한다. 2. 스레드가 만들어져 돌아가기 시작할 때 필요한 자원이나 데이터를 받거나 만들어 시작하고, 그것들로 스레드가 돌 수 있도록 한다.3. 스레드가 만들어져 돌기 시작하면 그 스레드나 그것을 만든 스레드가 각자 다른 인생을 사는 것임을 항상 명심한다. 사는 것, 죽는 것도 다르다. 4. 스레드들이 함께 사..

착한 프로그래밍

좋은 소프트웨어는 사용자가 원하는 것을 주어야 한다. 그러려면 사용자의 요구를 잘 분석해야 겠다. 경제성도 따져보아야 한다. 정해진 가격과 시간으로 만들어야 하기에. 이를 위해 적절한 소프트웨어 아키텍쳐를 생각해 보아야 한다. 좋은 소프트웨어는 SW적 품질이 좋아야 한다. 이해하기 쉽고, 간결하고, 유지보수 쉽고, 성능 좋게 짜여진 프로그램이 좋은 품질의 SW이다. 좋은 품질은 좋은 프로그래머가 만든다. 좋은 프로그래머는 프로그래밍을 단순히 code를 배설하는 행위라 여기지 않는다. 레고 블럭 쌓기 같이, 예쁜 공예품을 만드는 것 같은 세심함과 뿌듯함으로, 사랑하는 사람을 위해 음식을 만들 때와 같은 착한 마음으로 임한다. 최소한 전에는 그랬다. 80년대 프로그래밍은 K&R 로 시작했다. Fortran으..

윈도우즈 시스템 분석 도구

기술진들을 도와주려다가 윈도우즈 드라이버를, 레지스트리를 보게되었다. 원해서 그렇게 된 것은 아니지만 덕분에 윈도우즈에 대해 조금 더 알게된다. 그러다보니 당연히 이런 생각이 든다. 윈도우에서 프로세스/스레드가 뜨면 그에 따른 모든 정보를 다 함께 보면 좋겠는데... 프로세스명, PID, User, Path, 참조하는 레지스트리, 레지스트리 operation 등 이런 것들을 일목요연하게 보여 주는 도구가 있으면 좋겠는데... 대부분 그렇듯이, 질문이 좋으면 대답도 좋은 법. http://technet.microsoft.com/ko-kr/sysinternals 에 가보니 좋은 도구가 많다. 내가 원하던 것, 그리고 그 외에도 유용한 것이 많다. 윈도우 분석하거나 문제점 파악하려는 사람들에게 보물창고일 것 ..