Why is it that humans can create machines that are vastly more intelligent than their own kind, yet these machines are incapable of the basic perception and recognition skills of a newborn child?
...
For now, however, Baird concedes computers are still both "extremely brilliant and extremely stupid."
"인공지능" 이란 학문이 많이 이야기되고 있기는 하지만.
Artificial Perception 이란 측면에서 생각해 보면 아직도 극히 초보적인 걸음마 단계라는 생각이 든다.
인터넷에서 찾은 ANN (Artificial Neural Network) 에 관한 괜찮은 자료이다. ( 오래된 내용이긴 해도 reference 로는 괜찮은 듯.. )
왜 국내 웹사이트 중에는 이렇게 소스코드 레벨로 제공되는 좋은 자료들을 찾아보기 힘들까는 생각을 잠시 해 보면서..
신경망에 대해 처음 접했을때는 많은 매력을 느꼈다. 그런데 최근에는 출판되는 책이나 논문 동향을 봐도 그렇고, 1990 년대까지 한창 신경망 연구에 대한 붐이 일다가 2000 년 이후로는 신경망에 대한 연구가 좀 활기를 잃은 느낌을 받는다. 인공지능 박사 과정에 있는 친구도 신경망에 대한 전망을 어둡게 얘기하곤 했다.
일단 내가 느껴 본 바로는 신경망의 단점들이 몇가지가 있는데, 그중에서도 가장 큰 게 느껴지는 것은 구성된 신경망 내부 구조에 대해서는 디테일하게 내부 파악이 어렵다는 점이다. 이는 디버깅이 어렵다는 말과도 동일하다. 처음 신경망 구성 알고리즘을 설계하고 나면 이 알고리즘으로 생성되는 신경망의 결과는 실험을 통해서만 검증할 수 있다. 혹자는 이를 가르켜 "논리의 부재" 라고 설명하기도 하는데, 주어진 입력에 대해서 신경망 학습을 통해 원하는 결과에 가깝게 출력하도록 훈련 시킬수는 있지만 근본적으로 이 입력에서 왜 이런 결과가 나오는지의 논리에 대한 설명은 신경망이 갖고 있지 않다는 것이다.
또 하나는 신경망을 구성하기 위한 학습을 하는데 과도한 시간이 걸리며, 더 큰 문제는 학습이 끝나는데 ( 학습이 끝난다는 것은 최적화 된 신경망 구성이 완료된다는 의미로 말할 수 있겠다) 시간이 얼마나 걸릴지 알 수 없다는 점이다. 경험한 바로는 신경망 구성을 위한 학습에 시간이 무지막지하게 소요되고, 어느정도 만족한 결과가 나온 시점에서 이 상태보다 더 나은 결과가 나오는데 과연 얼마나 더 많은 학습이 필요한지 ( 혹은 현 시점의 신경망 구성 알고리즘으로는 더이상 개선된 결과가 나오지 않을 수도 있다. 이는 결국 실험을 통해서 재검증 할 수 밖에 없다 ) 사전에 알 수 없다는 문제가 있다.
그래서 최근 연구들을 보면 기존 신경망의 단점을 개선하는 방향에 대한 연구가 많이 진행되고 있는데 읽어본 내용 중에는 신경망 학습에 소요되는 시간을 줄이기 위해서 분산처리 시스템을 활용한다든지, Generic Algorithm 을 적용하는 등의 방법등이 있었다.
- 다양한 가격대의 제품 라인업을 갖추고 있어 선택의 폭이 넓다.
- 가격도 조립 PC 치고는 괜찮은 편이고, 가격대비 성능도 따져보면 쓸만하다.
- A/S 가 확실하다고 광고하고 있는데 이건 내가 아직 경험해 보지 못했으므로 패스...
단점
- 가끔 이상한 부품으로 제품 구성을 하는 경우가 있다. 예를 들면 2009년 11월 표준 PC 제품군에 사용된 메모리는 많이들 쓰는 삼성이 아닌 이케이(EKMEMORY) 라는 첨 들어보는 업체의 메모리가 사용되었는데 이게 불량률 때문에 이슈가 좀 되었던 것 같다.
- 라인업이 다양하다고는 해도 사실 완벽하게 자기 입맛대로 조립하기는 어렵다.. 그래서 어느정도 적절하게 타협을 해야 했다.
이런 류의 조립 PC 구매시에 주의할 점이, 업체에서 부품 품절을 이유로 갑작스럽게 다른 싸구려 부품을 대신 끼워넣어서 판매하는 장난을 치는 경우가 종종 있어서 주의해야 한다. 나 역시 주문하고 나니 파워 서플라이가 품절이라는 연락이 왔는데, 좀 찾아보니 원래 넣기로 한 부품과 동급에 가격도 비슷한 제품이길래 그냥 ok 했다.
위의 스펙에서 그래픽 카드는 GTS 250 이 아닌 GTX 260 이었고 ( 초기에는 260 으로 판매하다가 중순 이후로 250 으로 바뀌면서 가격을 좀 내린 모양이다 ) 파워는 히로이치 500WP 대신 ToPower 500W 으로 왔다.
써본 후에 소감...
1. 일단 조립이 깔끔하지 못한 상태로 왔다. 부팅이 안되길래 확인해 보니 그래픽 카드가 제대로 보드에 꽂혀있지 않아서 나사를 풀고 다시 제대로 꽂았다. 배송 중에 충격으로 그럴 수도 있겠지만 아무래도 이 가능성은 낮아 보인다. PC 는 OS 도 안깔린 상태로 배송되는데, 제대로 OS 는 설치해서 잘 돌아가는지 테스트는 해 보고 출하한 것인지 조금 의심이 든다.
2. 확장이 생각보다 불편했다.
파워 서플라이의 하드디스크 파워 케이블이 총 3개 밖에 없어서 하드디스크는 3개 뿐이 쓸수 없었는데, 그것도 길이가 좀 짧아서 CD-ROM 위치를 변경하는 대공사 끝에 겨우 하드디스크 2개를 추가로 다는 공사를 마무리 지을 수 있었다.
Visual Studio 2005 에서 서비스 팩 1 (SP1) 을 설치할 경우 몹시 불편하던 점 2 가지가 개선된다.
1. "찾기" 기능에서 찾기 범위로 "전체 솔루션" 이 추가된다.
여러 프로젝트가 붙어있는 솔루션 환경에서 개발할때 매우 유용하다.
참고로, Visual Studio 2008 에서는 기본적으로 제공하고 있는 기능이다. 영문판의 경우 "Entire Solution" 이라고 표기된다.
2. SourceSafe 에서 수정사항이 발생하면 자동으로 "편집하기 위해 체크아웃" 상태가 된다.
이것도 매우 편리하다. 이 기능이 없으면 매번 수동으로 체크아웃을 해줘야 하기 떄문이당.
이 걸 제대로 안해주면 다른 개발PC 에서 개발한 내용이 제대로 반영이 안되는 형상관리가 제대로 안되는 문제가 생길 수 있다.
ps ) 참고로 Windows 7 에서 Visual Studio 2005 를 사용하려면 무조건 SP1 을 설치해야 한다. 그냥 Visual Studio 2005 만 설치한 상태로 쓰려고 하면 호환성 오류가 나서 실행이 안됨...
ODBC 는 Open Data Base Connectivity 라 하여, 데이터 소스에 연결하는 방법을 제공하는 표준 API 를 말한다. DB 에 접근하기 위해서는 DSN 을 이용한 SQL driver 혹은 기타 다른 driver 같은 것을 설치해야 한다. 대부분의 DBMS 들은 ODBC 를 지원한다.
OLE 는 Object Linking and Embedding 의 약어로서, OLEDB 는 흔히들 "automation"(자동화) 라고 말하는 OLE 와는 구분된다.
OLEDB 는 MS 에서 제공하는, ODBC 를 계승한 기술로서 VB 나 C++ 기반의 GUI 를 제공하는 "front end" 와 SQL Server, DB2, mySQL 등과 연결하는 "back end" 의 두 컴포넌트로 구성되어 있다. OLEDB 는 많은 경우 ODBC 보다 좋은 성능을 보여준다.
OLEDB 는 DSN driver 등을 설치할 필요가 없으며, VB 어플리케이션 개발에서 많이 이용되며 ADO 와 유사하다. 또한 SQL 7.0 에서 COM, DCOM 과 함께 동작한다.
1 대의 서버가 N 개의 클라이언트들을 상대로 서비스를 하다보니 결국 멀티스레드로 구현하게 되었다. 네트워크 프로그래밍을 함에 있어서 스레드 사용은 필수라는 생각이 든다.
멀티 스레드에서 조심할 것은 하나의 자원에 대해서 여러개의 스레드가 동시에 접근하지 못하도록 제한을 걸어야 하는 것이다. 하나의 자원에 대해 두개 이상의 스레드가 동시에 접근할때 바로 OS 시간에 배웠던 Race Condition 상태가 발생할 수 있는 것인데, 보통 이를 해결하기 위해서 Mutex, Critical Section ( Critical Section 을 우리나라 말로는 "임계 영역" 이라고 하고, 일본에서는 "위험역(危險域) 이라고 한다는군), Semaphore 등을 사용 한다.
Mutex 와 Critical Section 의 차이는 서로 다른 프로세스 간의 동기화도 지원하는 Mutex 와 달리 Critical Section 은 하나의 프로세스 내에서만 사용할 수 있다는 점이다. 그래서 보통 Mutex 는 프로그램의 중복 실행을 방지하는 용도로 많이 쓴다. Semaphore 는 뮤텍스와 비슷한데, 접근 가능한 스레드의 갯수를 지정할 수 있다는 점이 다르다.
외부에서 사용되는 변수를 스레드 내에서 변경하는 행위 등도 상당히 조심해야 한다. 특히 이 변수들이 스레드 외부 다른 곳에서 수정이 발생하는 경우 값이 꼬일 가능성이 커지므로 주의해야 한다. 이런 실수를 종종 하게 되는 이유는 스레드가 생성되는 순간부터 메인 프로세스 외에 스레드 함수가 병렬적으로 실행되고 있다는 것을 늘 머리속에 염두를 해 두어야 하는데, 사실 인간의 직관이 병렬 처리라는 개념으로 코딩하는게 쉽지 않기 때문이다.
서버와 클라이언트가 연결을 맺고 파일 전송과 같은 sequential 한 작업을 진행하는 도중에는 이 작업의 atomicity( DB 에서 트랜젝션 처리등에서 말하는 "원자성" 이다 ) 를 보존해 주는 처리가 있어야 한다. 예를 들면 파일 전송이 끝나지 않은 상태에서 또다른 파일을 열어서 같은 소켓으로 전송을 시도하려고 하는 경우등에 에러가 발생할 소지가 있을 수 있다.
여러 스레드가 동시에 파일을 읽는 경우, 동시에 파일을 쓰는 경우 등에 대해서도 잘 고려해 봐야 한다. 여기에 대해서는 친구가 좋은 팁을 알려줬는데, 일단 메모리상에 파일 버퍼에서 파일들을 저장해 놓고 있다가 큐에 일정 용량이 쌓이거나 일정 주기가 되면 그때마다 file write 를 하라는 것이다. client 가 주는대로 서버에서 그때마다 스레드 생성해서 각각이 file open 해서 파일을 쓰는 경우 상당히 퍼포먼스 측면에서 부담이 커진다. 그런데 현재 테스트 해 본 바로는 파일 크기가 그리 크지 않은 경우 ( 수백 kb 정도 ) 에서는 동시에 여러개 ( n < 10 ) 의 스레드로 파일 쓰기를 반복 시도 하여도 체감상 느껴지는 부하는 없었다.
지금은 최대한 심플하게 만들기 위해서 간단하게 비동기 소켓으로 만들고 있지만 보통 이렇게 다중으로 file write 를 해야 하는 경우 IOCP 를 많이 쓰는 것 같다. 이쪽은 나중에 시간나면 더 찾아봐야 겠다.
어쨌든 네트워크 프로그래밍은 어렵다. 일단 개발 및 테스트를 위해 장비가 최소 2 ~ n 개가 준비되어야 하고, 네트워크가 일시적으로 단절되는 경우 등 통신 상에서 필요한 여러가지 예외처리를 해 줘야 하는 부분들이 있다. 역시 많은 노하우가 필요하다고 생각된다.
나 병특할때 그러니까 2000년대 초 쯤에는 , IOCP 니 Overlapped IO 니 그런걸로다 대용량 네트워크 서버를 많이 만들곤 했던 기억이 있당…
2003년 이후부터는 ACE 프레임워크 같은걸 많이 썼었지.... 대용량 서버를 직접 만들고 최적화 하는 곳은 일부 게임회사등을 제외하고는 많지 않았던 듯.... windows nt 계열 서버를 쓰는 데는 거의 IOCP 를 많이 썻고, 유닉스 나 리눅스 쓰는 데는 게임회사들도 ACE 를 많이 썼었는데.. 그러다가 ACE 가 운영체제마다 최적화된 메커니즘이 아닌지라 ASIO 라는 프레임워크로 또 나중엔 대세가 넘어가는거 같기도 했고.(요즘유행은 잘 모르겠음. 게임업계를 떠난지가 언 5년이 다되가니..) ASIO 는 ACE 와 달리 운영체제마다 최적화된 메커니즘으로 되어 있어서 windows nt 계열에서는 IOCP 를 쓴다더군... ASIO 는 안써봤지만.. ACE 를 쓰면서 느낀점은....역시.... 공부해가면서 내가 직접 짜는 것 보다는 검증된 Open 소스도 잘쓰면 업계 평균 이상은 된다는 것...
나같은 경우는 회사에선 걍 WCF 나 웹서비스로다가 몇줄만에 IOCP 로 하던 코딩을 끝네고 대용량 다중 접속 처리를 웹서버에다가 떠넘기고 있지만.... (WCF 가 좋은 점은 웹서비스로 가면 독립 어플리케이션은 양방향 통신에서 자체가 웹서버 역할은 못하니까 클라이언트 역할 밖에 못하는데.... WCF 는 웹서버 없는 클라이언트가 자체적으로도 웹서버 처럼 웹서비스 호스팅 기능을 가지고 있다는 것...)
3년여 전부터 금융권에 몸담으면서 네트워크 코딩이 극명하게 두가지로 나뉘었는데..한가지는 편하면서 범용적으로 코딩하는 경우와 또 한가지는 실시간 계좌이체 처럼 속도와 안정성이 대단히 민감한경우... 전자는 자바등 레거시와의 연동이슈 때문에 최근 1~2년 사이에는 소켓통신 거의 안쓰고 SOAP 이나 REST, JSON 같은거 쓰고 있고.. 후자는 Tmax 나 Tuxedo 등 상용 미들웨어를 쓴다는점... 게임업계처럼 오픈소스나 자체 제작을 안해서 요즘은 IOCP 구경 할 일이 거의 없어서 IOCP 는 아련한 기억으로만 남아있당…
메일은 꾸준히 아웃룩으로 보관하면서 모아놓는 스타일인데, 드디어 Office 2003 의 Outlook 의 메일파일 (pst 파일) 의 저장 한계에 다다랐다. 20 기가...
예전에 Outlook 97 에서는 pst 파일 당 저장 용량이 2 기가에 불과해서 ( pst 크기 정보 변수가 integer 였나 보다) 몹시 불편했는데, Outlook 2003 으로 버전업 하면서 pst 파일의 2 기가 제한이 풀렸길래 이제는 수십기가 이상도 저장이 가능할 것이라 지레 짐작을 했다. 그래서 첨부파일이 큰 메일들도 별 생각없이 (백업 차원에서) 계속 저장하다 보니 몇년만에 드디어 pst 파일 크기가 20 기가에 도달하면서... 더이상 메일을 다운받아도 메일 다운은 성공하되, 실제 편지함에 받은 메일은 생성이 되지 않는 버그가 나타나기 시작했다.
다행히 서핑을 좀 해보니 쉬운 해결안이 있었다. pst 가 커지면 메일을 적당히 나눠서 "내보내기" 메뉴를 통해서 별도의 pst 로 분리할 수 있다. 그런데 outlook 의 또다른 버그인지 pst 로 옛날 메일들을 분리한 후에 분리한 옛날 메일과 폴더들을 완전히 삭제해도 outlook.pst 파일 크기는 줄어들지 않았다. 그래서 pst 파일 압축하기를 했더니 outlook.pst 파일 크기가 점점 줄어들기 시작한다. pst 가 내부적으로 어떤 자료구조로 되어 있는지는 몰라도 제대로 정리되지 않은 빈공간을 정리해 주는 작업을 하는 듯 하다.
문득 생각난 건데, 32 비트 signed integer 가 표현할 수 있는 2,147,483,647 이라는 제한 때문에 일부 프로그램들은 2 기가 이상의 램을 인식하지 못한다든지, 2 기가 이상의 하드디스크를 인식하지 못하는 문제들이 있는 경우가 있었다. 하드디스크야 요즘은 테라바이트 시대이니 그런 문제를 잘 찾아볼 수 없지만, 아직 2 기가 이상 램을 쓰는 컴퓨터가 그리 많지 않아서인지 2 기가 이상 램을 체크하지 못하는 버그를 가진 프로그램은 주변에서 종종 보곤 한다. ㅋ
IT 산업의 최첨단을 달리는 소프트웨어 개발자들이 오히려 새로운 기술/툴 의 사용에는 둔감한 모습을 보이는 경우를 종종 보곤 하는데, 개인적으로 그 대표적인 예 중 하나로 출시된 지 이미 10 년이 넘은 Visual C++ 6.0 을 아직도 많은 이들이 사용하는 것을 꼽고 싶다.
Visual C++ 6.0 은 가볍다는 장점도 있으나, 그에 못지 않게 최신 MFC, STL 지원 미비, 닷넷 기술 사용 불가, VC 6.0 컴파일러의 비표준 코드 생성, VC 6.0 의 컴파일러의 오류, 유니코드 사용의 불편함 등 여러 문제점이 더욱 크다고 생각된다. (VS 6.0 의 문제점에 대해서는 싹 정리해서 따로 포스팅을 해보고 싶다. ) 사실 주변을 둘러보면 개발자가 VC 6.0 을 고집하는 주요 이유로 Visual Studio .Net 이 익숙치 않아서... 가 가장 크지 않을까도 싶다.
어쨌든 Visual C++ 6.0 에서 유니코드를 쓰려다 빌드시 mfc42ud.lib 가 없다는 링크 에러로 한참 고생했다.
VS 6.0 설치시 default 로 설치하면 유니코드 관련된 라이브러리는 깔리지 않는다. Custom 설치를 선택해서 위의 "Static Libraries for Unicode", "Shared Libraries for Uniode" 를 선택해서 깔아줘야 한다. 유니코드 프로그래밍이 기본이 되고 있는 요새 이런 불편을 겪게 하다니... VS 6.0 을 하루빨리 버려야 하는 또다른 이유를 찾았다. -0-
