1990년대 초에 바다 건너 미국에서는 바둑, 오목, 체스, 스크래블 같은 보드 게임의 AI 위주로 ‘컴퓨터 올림피아드’라는 대회가 잠깐 개최된 적이 있었다. 기억을 정말 오랜만에 다시 떠올린다. ㅠㅠㅠㅠ
IOI라고 불리는 '국제 정보 올림피아드'와 헷갈리지 마시길. 요즘은 저걸 검색하면 구글도 자꾸 IOI 쪽으로 안내하는 것 같은데 그거랑은 다르다. 컴올은 공식 명칭에 '국제 I'라는 말이 없다. ㄲㄲㄲㄲ

IOI는 대학에 진학하지 않은 중등 수준의 10대 청소년들이 문제 푸는 프로그램을 '즉석에서 작성'해서 그 코드의 성능과 정확도를 평가 받는 대회이다. 그 반면, 저건 현업에 종사하는 소프트웨어 개발자/개발사들이 오랫동안 미리 연구 개발해 놓은 자기 자기 제품의 AI 성능을 현장에서 겨루는 대회이다. 즉, 로봇 쥐 미로 찾기와 비슷하며, 저런 보드 게임을 사람이 아니라 컴퓨터끼리 대국한다는 차이가 있다.

근데 컴터 올림피아드도 첫 대회가 1989년부터 시작됐다니.. 그건 IOI와 동일하다. 그리고 가끔은 IOI에서도 간단한 게임을 진행하는 프로그램을 작성해서 주최측 AI와 대국하고 채점되는 형태의 문제가 나오기는 한다. 그러니 둘이 완전히 다른 별개 분야의 대회까지는 아니긴 하다.

본인이 저 대회에 대해 들어 본 건.. 한때 왕년에 영단어 보드 게임인 스크래블의 AI를 연구하느라 관련 자료를 많이 찾아봤었기 때문이다.
무려 1988년에는 World's fastest Scrabble program (by 앤드루 아펠, 가이 제이콥슨)이라는 논문이 CACM에 게재돼서 후대의 스크래블 AI 개발자에게 아주 큰 영향을 줬다. 모든 가능한 수를 찾는 기본 작업은 이 논문에서 소개된 알고리즘으로 해치우고, 그 뒤에 단순히 당장 점수가 가장 높은 수를 넘어 장기적인 이익을 따지는 건 전략과 휴리스틱의 영역으로..

사용자 삽입 이미지

오래된 생각이긴 하다만, 스크래블 게임의 컴퓨터 구현은 대학교 수준의 자료구조와 알고리즘 코딩 주제로 아주 적합하다. 만약 내가 학원이나 학교에서 저런 전공 과목을 가르칠 기회가 있다면 실습이나 과제로 저걸 꼭 넣었지 싶다. =_=;;
하긴, 석사 논문으로 두벌식 한글 연속입력 오토마타를 연구했던 모 교수님은 자기가 강의하는 형식언어와 오토마타 수업 시간에 한글 입력 오토마타를 구현하는 과제를 고정 편성으로 넣었더구만.. 그런 것처럼 말이다.

아무튼 그건 그렇고..
저 논문을 투고했던 연구진은 딱 이듬해인 1989년, 제1회 컴퓨터 올림피아드의 스크래블 부문에 참가해서 우승했다고 한다. 타이밍 절묘하군..

그 뒤 2회와 3회에서는 Jim Homan이라고 MIT 출신의 다른 엄친아 공돌이가 개발한 스크래블 AI가 2년 연속 우승을 차지했다. 정황상, 아마 저 논문 내용을 바탕으로 AI를 더 발전시킨 것 같다.
그리고 그 사람은 저 AI 엔진을 토대로 CrossWise라는 굉장히 깔끔한 크로스워드 게임(설정을 맞춰서 스크래블 게임도 가능한!!) 프로그램을 개발해서 판매했다.

그것 말고 브라이언 셰퍼드라는 사람이 개발한 Maven이라는 스크래블 AI도 유명했다. 얘도 개발 역사가 1980년대로 거슬러 올라갈 정도로 오래됐고, 스크래블 보드 게임의 총판사에서는 Maven을 공식적으로 밀었다고 하는데.. 얘에 대해서는 나도 더 아는 바가 없다. 이쪽은 딱히 컴올에 참가한 이력도 없는 것 같다.

뭐, 이것도 다 지난 얘기이다. 지금은 스크래블 게임쯤이야 폰이나 웹에서도 돌릴 수 있을 텐데.. 유행이 지난 것 같다.
하다못해 바둑조차도 세계를 석권해 버린 알파고 개발진이 "이젠 바둑은 더 연구할 게 없다~~" 명목으로 발을 뺐을 정도이니 말이다. -_-;;

저 컴퓨터 올림피아드는 스폰서 내지 운영진을 섭외할 수 없어서 1991년 이후부터 1990년대 내내 맥이 끊겼다. 그러다가 2000년대 이후부터 다시 개최는 되고 있지만.. 다들 아시다시피 인지도가 별로 없고 마이너하다는 냄새가 풍긴다. 고전적인 최적화나 휴리스틱 위주의 AI는 유행이 끝나고 닥치고 인공신경망이 대세가 돼서 그런지..??

우리나라에서 보드 게임 AI 외길을 가고 있는 제품은 '장기도사'가 유일하지 싶다. 의미 있는 연구이긴 하다만, 보드 게임이라는 장르 자체도 마이너해지고, AI 패러다임도 마이너해져서 수요가 무척 적을 것 같다. 뭐, 그런 식으로 염세적으로만 따지자면 본인의 주특기인 세벌식 자판도 마이너 중의 초 마이너이긴 하다만 말이다. -_-;;

고전적인 AI 대신 2010년대를 풍미했던 건 인공신경망들이었다. 2012년, 사물 인식을 기가 막히게 잘한다는 AlexNet부터 시작해서 VGG, ResNet, YOLO가 뒤를 잇고 chatGPT, transformer 등등이 쏟아져 나왔으니까.
컴퓨팅 패러다임이 싹 달라졌다. 이 과정에서 파이썬은 머신러닝 학계와 업계의 공용 언어가 되었고, 교육과 실무를 다 장악해 버렸다. ㄷㄷㄷㄷ 파이썬과 루아(Lua)가 처지가 극과 극으로 달라지게 될 줄은 20년 전엔 정말 예상할 수 없었다. 이것도 생각할 점이라 하겠다.

글을 맺기 전에 잠깐.. 그러고 보니 World Cyber games도 생각난다. 얘는 컴퓨터 AI가 아니라 사람이 겨루는 대회이지만, 그래도 E-스포츠 전문이니 뭔가 컴퓨터스럽고 사이버틱한 느낌이 나기 때문이다.
얘도 2001년에 처음으로 시작됐다가 2010년대엔 스폰서를 못 구해서 한동안 중단됐던 적이 있다. 그 뒤 지금은 재개되기는 했지만 권위나 인지도가 예전만 하지는 않다는 게 컴퓨터 올림피아드와 비슷해 보인다.

Posted by 사무엘

2024/06/25 08:35 2024/06/25 08:35
, , , , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/2312

우리가 매체에서 접하는 옛날 풍경 모습이란 게 한때는 그냥 사람이 붓에다 물감 찍어서 그린 그림이 전부였다.
그러다가 그게 흑백 사진을 거쳐서 컬러 사진으로 바뀌었는데, 이제는 애초에 흑백 사진밖에 전해지는 게 없던 장면조차 컬러로 재구성된 게 늘고 있다.
컬러이더라도 화질이 안 좋았던 것을 리마스터링까지 한다. 이런 건 소실된 색/화소 정보를 AI의 힘으로 창작해서 복원한 것이다.

AI는 완전히 생판 무에서 유를 창조할 정도로 혁명적인 일은 절대 못 한다.
뭔가 패턴이 있고 생노가다 같긴 하지만, 진짜 노가다보다는 미묘하게 복잡하고 전문성과 창의성(?)이 필요해서 자동화가 안 되고 인력 수작업이 필요했던 일들.. 그러면서 법적 책임과 부담감이 크지는 않은 일.
AI는 딱 그런 업종을 0순위로 잠식할 것으로 보인다.

(1) 음악: 없는 곡을 AI가 작곡도 하는 세상인데, 기존 악보 멜로디를 읽고서 E G Fm 등 코드를 매긴다거나 반주를 넣는 건(편곡) 당연히 자동화될 것이다. 이것도 답이 한 가지만 있는 게 아니기 때문에 곡에 대한 해석과 창작이라는 범주에 든다!
코드를 만에 하나 좀 이상하게 넣었다고 해서 당장 인명· 재산 손실이 발생하는 것도 아니고.. AI화하기에 딱 좋아 보인다.

(2) 폰트: 한 폰트 패밀리로부터 다양한 굵기 내지 이탤릭 바리에이션을 자동 생성하기. 윤곽선을 단순히 기계적으로 산술적으로 부풀리기만 하는 게 아니라, 그로 인한 세밀한 공간 배치를 인간이 보기 좋게 알아서 하는 것 말이다. 힌팅을 더 똑똑하고 정교하게 생성하는 것도 포함이다.
그리고 한글· 한자의 경우, 샘플 몇 글자만 넣어 주면 그로부터 규칙성을 파악해서 나머지 수천 자의 글자 모양까지 알아서 유추해서 자형 생성하기.

AI는 한글· 한자에 대해서도 알파벳처럼 폰트들이 엄청 많이 넘치도록 개발되게 도와줄 것이다. 한글· 한자가 글자수가 수천 자나 된다고 해서 진짜로 문자로서 자형의 절대적인 정보량? 엔트로피가 알파벳의 수백 배 이상인 건 아니다. '가각간갇'이 무슨 알파벳의 ABCD 급으로 서로 완전히 다른 건 아니기 때문이다.

옛날엔.. 알파벳은 글자 수가 적어서 폰트도 크기가 작고 쉽게 만들 수 있는 반면.. 한글 한자는 너무 무겁고 뚱뚱하고 컴퓨터 자원도 많이 차지한다고.. 이러니 동양이 서양보다 국가 경쟁력이 떨어지고 열등하고 도태할 수밖에 없다는 식으로 극단적으로 생각하는 정서가 있었다. 100여 년 전, 공 병우니 최 현배니 하던 시절엔 기계식 타자기만 갖고도 문자의 우열이 비교될 지경이었으니 말이다.

지금은 그 정도로 강박관념을 가질 필요는 없다. 컴퓨터 자원이야 풍부해서 넘쳐나고, AI가 사람으로 하여금 진짜로 본질적으로 창의성이 필요한 작업만 하면 되게 나머지를 보조해 줄 것이기 때문이다.
다만.. 인간이 이런 AI를 만들기 위한 연구 개발은(코딩, 수학식, 논문 등)... 알파벳처럼 원초적으로 가볍고 취급하기 쉬운 tier 1급 문자로 행해졌음이 부정할 수 없는 사실이다.

(3) 코드 정적분석: 재래식 알고리즘만으로는 컴퓨터 프로그램을 정적분석만으로 실행 결과를 100% 정확하게 예측하고 논리 결함을 찾아내는 게 불가능하다. 그 이상부터는 그냥 휴리스틱/AI의 영역으로 갈 수밖에 없다.
그리고 코드뿐만 아니라 주석에 적힌 자연어 문구도 의미를 파악해서 "이거는 시스템 정보나 패스워드가 하드코딩된 거 아냐?" 같은 것도 정적분석이 찾아낼 수 있다. AI는 재래식 정적분석 툴의 쓸데없는 오탐들을 줄이는 데 기여할 수 있다.

(4) 그 밖에 이런 AI 기술로 내 생각엔 인쇄된 글자 모양을 보고 그냥 OCR을 하는 게 아니라 이게 무슨 폰트인지를 알아맞힌다거나, (산돌, 윤~~ ㅋㅋㅋ) 거대한 인파 사진을 보고 여기 사람 머리가 몇 개인지 카운트 하는 것.. 아 이건 딥러닝 AI까지는 아니라 그냥 컴퓨터 비전이려나.. 이런 기술이 개발되면 일상생활에 도움이 될 것 같다.

(5) 그리고 식당· 카페의 무인 키오스크가 아예 커맨드라인 콘솔이 도입될 게 아니라면 진짜 사람 말을 빨랑빨랑 알아들었으면 좋겠다. 지금 터치스크린 인터페이스는 너무 느리고 답답한 반면, 단순 주문 접수는 지금 정도의 NLP로도 그렇게 어렵지 않을 테니 말이다. 확실히 AI 덕분에 단순 안내 데스크나 전화 상담 직원은 많이 없어질 것 같다.

다만, AI는 저렇게 창의성이 필요한 분야, 참고· 보조용 도구로서 강세이다. 법적 책임까지 수반되는 분야에 진입하는 건 많이 더디지 싶다. 그래서 의료 법조 쪽은 그냥 자문· 상담부터 시작할 것으로 보이며, 자동차의 완전 자율주행은 아직 갈 길이 멀어 보인다.

* 철도는 통제가 너무 잘 된 환경이니 AI 없이 재래식(?) 로직만으로 이미 무인 자동운전이 가능할 지경이다. 차량 번호판 숫자나 QR코드를 인식하는 것과 비슷한 수준이다. (이 정도로 잘 통제된 이미지의 인식은 AI가 아니라 그냥 통상적인 컴퓨터 비전 분야..)
그러니 자동차와 철도의 중간 난이도인 비행기나 선박의 운항에 AI 기반의 자동 운항이 먼저 파고들지 않을까 싶다. 허나, 승객 수백 명이 타는 여객기에 무인까지는 아니어도 부기장이 없어지고 1인 조종이 가능해질지는 과연..?? 저비용 항공사에서 작은 기종부터 1인 조종을 시킬 수는 있겠다.

* 미용· 이발은 굳이 AI화 자동화하자면 못 할 건 없지만.. 굳이 그럴 필요가 없다고 여겨진다. 사람이 직접 가위 들고 사람 머리 깎는 건 가까운 미래에도 변함없을 것 같다. ㄲㄲㄲㄲㄲㄲ

* 빌 게이츠는 무려 25~30년 전부터 제품에다가 자연어를 알아듣는 AI 비서? 에이전트를 넣으려고 애썼던 사람이다.
마소 Bob이라든가 Office 길잡이..;;는 좀 무리한 흑역사였긴 하지만.. 반대로 저 아저씨가 시대를 앞서간 시도를 한 거라고 볼 수도 있다. 그런 귀요미를 겨우 램 16MB, 150MHz짜리 펜티엄 컴터에다 집어넣으려 했으니 욕 먹었던 거지..;; 현실의 기술이 아이디어를 뒷받침하지 못했다.

* 미국 말고 의외로.. 중국이 2010년대 이후부터 머신러닝, 언어모델 쪽 연구를 많이 하는 것 같다. 외국의 최신 논문을 찾아 보면 중국 사람 이름이 엄청 많이 보인다.
그런데 중국은 그런 첨단 AI 기술을 이용해서 인터넷의 불온 컨텐츠를 검열하고 인민들 행동패턴을 감시하는 데도 적극 활용한다는 게 함정....

지난 1990년대 중반까지 기계번역 프로그램이 잠깐 나오다가 유행이 식은 적이 있었다. 일한이라면 모를까 영한은 이거 뭐 도저히 실용적인 결과가 나오지 않았기 때문이다. 하물며 한영은.. 난 지구가 멸망할 때까지 절대 개발되지 못할 거라고 생각했었다.
그런데 인공신경망 기반 AI로 언어 장벽이 이 정도까지 무너지고 낮아진 건 참으로 놀라운 일이다.

물론 무슨 기업간 회의나 대통령 연설, UN 컨퍼런스를 기계번역으로 때워도 되는 건 아니지만, 일상적으로 뭔 말인지 내용 파악하는 용도로는 기계번역이 정말 쓸 만해졌다.
게다가 이게 텍스트를 읽는 것에만 국한되지 않는다. waveform 형태의 말소리를 받아 적은 transcript를 생성하고 그걸 번역까지 하다니.. 유튜브에서 자기 동영상의 음성에서 자막을 아주 정확하게 실시간 생성해 주는 것만 해도 신기하기 그지없다.

암호 해독을 위해 언어학자가 아니라 수학자가 필요한 시대는 이미 20세기 중후반에 찾아왔다. 이제는 기계번역이나 자연어 처리 영역도 언어학자가 아니라 수학자와 데이터 과학자의 차지가 됐다.
2020년대가 되니 인간이 달이나 화성이나 해저에 기지를 만드는 건 전혀 가망이 없고, 그 대신 쌍팔년도 SF에서 거의 상상하지 못했던 스마트폰과 유튜브가 대세가 됐다. 그래서 카폰이라는 게 완전히 사라졌고, 무전기는 군· 경· 소방 같은 특수 직종에서나 쓰이는 물건이 된 거다. 뭐, 언어 자동 통번역기는.. 그 시절에도 상상은 했었고 얼추 실현돼 간다.

머신러닝에서 모델이라는 건 코드와 데이터의 성격을 모두 지니고 경계가 참 애매한 것 같다. =_=;; 물론 순수하게 데이터에 속하는 건 훈련용으로 먹이는 텍스트나 그림들이겠지만 저런 신경망 자체도 머신러닝 라이브러리 코드의 관점에서는 데이터일 것이다.
그리고 훈련시키는 건 뭔가 압축하는 것과 비슷하고, 이를 바탕으로 현실의 문제를 풀이하는 건(추론) 압축을 푸는 것과 비슷해 보인다.

이런 AI는 참 엄청나고 대단하긴 하지만.. 공짜로 평범한 계산량으로 돌아가는 물건이 아니다. AI를 돌리기 위해 동원되는 컴퓨팅 자원을 보면 정말 억소리 난다.
chatGPT가 저렇게 답을 '즉시' 뱉어내기 위해서 지구 반대편에서는 상상을 초월하는 고성능 슈퍼컴이 전기를 있는 대로 잡아먹고 열을 펑펑 내뿜으며 돌아가야 한다. 살인적인 분량의 신경망 연산이 행해지기 때문이다. 저기 서버가 하루 유지 비용이 원화로 몇 억? 몇십 억이니 그런다. 이때 컴퓨터 내부의 신경망 상태는 상상을 초월하게 너무 복잡하기 때문에 훈련이나 추론 과정의 추적이 도저히 불가능할 지경이다.

인간은 오랫동안 절대 불가능하다고 여겨졌던 유인 달 착륙과 귀환을 몇 차례 성공하긴 했다. 그러나 그건 정말 위험하고 어렵고 힘들고 비싸게 가까스로 해낸 것이었다. 민간인의 대중적인 달 여행이라든가 달· 화성 기지로 이어지는 건 지금 관점에서도 가까운 미래엔 요원하다.

그리고 AI의 발달 추세에도 이런 우주 개발과 비슷한 면모가 있는 것 같다. 과거에 불가능하다고 생각했던 자연어 처리가 가능해지기는 했지만.. 그걸 가능케 하는 컴퓨팅 환경이 저 우주 로켓 같은 물건이라는 거다. 물론 컴퓨터 업계도 가만히 앉아서 손가락만 빠는 건 아니니.. 그 연산에 특화된 CPU를 만들어 간다.

30여 년 전, 486이니 펜티엄이니 하던 시절엔 멀티미디어 지원이 컴터 업계의 최대 관심사였던 것 기억하시는가?
크게 (1) 동영상 아니면 (2) 게임용 3D 그래픽 실시간 렌더링이라는 두 분야이다.
하긴 그 시절엔 MPEG 동영상을 감상하기 위해서 전용 카드를 꽂네 마네 했던 것 같다. 요즘은 재생이 아니라 컴터 화면을 실시간으로 녹화하고 인코딩할 때에나 전용 카드가 필요한 듯하다.

나중에는 엄청난 물량을 자랑하는 멀티미디어 연산에 특화된 명령이 CPU에 추가되고, GPU라는 건 그래픽 가속기라는 이름으로 도입되곤 했었다.
그랬는데 이제는 단순 그래픽 처리를 넘어 머신러닝 신경망 연산에 특화된 CPU가 대세이다. 당연히 서버에 접속해서 API를 호출해서 구현된 거라고 생각한 통· 번역이 핸드폰에서 비행기 모드까지 켰는데도 동작한다는 게 정말 신기하다.

저런 컴퓨터에 비해 인간의 두뇌는? 환경에 끼치는 부작용이 없고 당분 몇 스푼만 공급해 주면 한 나절을 거뜬히 돌아간다.
물론 두뇌와 컴퓨터가 서로 비교 가능한 존재는 아니지만 어떤 면에서는 생체라는 게 참 경이롭다. 두뇌와 컴퓨터는 다리와 바퀴가 다른 것만큼이나 다른 건지도 모른다.

그러고 보니 우리나라의 이스트소프트는 맨 처음 1990년대엔 21세기 워드라는 평범한(?) 업무용 프로그램을 만들었다가 알툴즈로 명성 내지 악명을 떨쳤고.. 그러다가 게임이 더 돈 된다고 생각했던지 '카발'이라는 온라인 게임을 만들었고 지금 와서는 AI 기업을 표방하고 있다. (게임과 AI 모두 GPU가 쓰인다는 공통점이..)
각각의 제품들이 어떤 평을 받는지에 대해서는 논란의 여지가 있지만, 어쨌든 시류를 따라 참 다양한 분야를 개척하면서 생존하려고 애쓴다는 것 하나는 확실해 보인다.

Posted by 사무엘

2024/06/22 08:35 2024/06/22 08:35
, , ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/2311

1. 숫자를 표현하는 방식

20세기 중반에 컴퓨터가 아직 진공관 기반으로 만들어지던 시절에는 전기식이 아닌 전자식으로 바뀐 것뿐만 아니라 10진법 대신 순수 2진법을 사용하기 시작한 게 큰 전환점으로 여겨진다. 그게 더 기계 지향적이고 직관적인 설계이기 때문이다.

이건 사람으로 치면 별도의 교육을 통해 암산 때 머릿속에서 아라비아 숫자 대신 주판알을 떠올리는 것과 비슷하지 않을까 싶다. 아라비아 숫자는 문자로서 실용적인 기능도 겸하려다 보니, 숫자의 본질과 연산에 직관적으로 대응하는 체계가 아니기 때문이다.
심지어 주판법에는 선주법과 후주법이 모두 존재한다. 이건 컴퓨터에서 big/little endianness와 거의 동일한 개념인 것 같다.

2. 색공간과 실제 공간

우리가 사는 현실의 공간은 길이· 너비· 높이라는 xyz 세 축, 즉 3차원이라고 여겨진다.
그런데 우리에게 시각을 인지시켜 주는 색이라는 것도 어떤 형태로 축을 나누든.. RGB건 HSL이건 CMY건 결국 3개의 축으로 이뤄진다는 게 시사하는 바가 커 보인다.
가령, 색에서 hue라고 불리는 빨주노초~파남보 요소는 가시광선 파장의 차이라는 1차원 축으로 변별된다. 하지만 채도(S)와 명도(L)는 또 다른 차원의 변수라는 것이다.

컴퓨터의 그래픽 카드에서는 RGB 각 축에 대해 8비트의 정보량을 부여해서 총 2^24, 1600여 만 가지 색상을 제공하곤 하는데, 정작 1픽셀의 크기는 3바이트 24비트가 아니다. 컴퓨터가 처리하기 편한 단위인 4바이트 32비트 단위를 사용하며, 나머지 남는 8비트에다가는 픽셀의 알파 채널 정보를 넣곤 한다. 이건 여러 이미지를 부드럽게 합칠 때 활용된다.

알파 채널은 색깔을 나타내는 축 자체는 아니지만 색의 표현과 관계 있는 정보이다. 이걸 포함한 pixel format을 RGBA 구조라고 한다. 하지만 Windows의 GDI API는 1980년대에 개발되었으며, 픽셀에서 상위 8비트를 팔레트 등 독자적인 다른 용도로 이미 사용하다 보니 훗날 알파 채널을 제대로 지원하지 못하는 촌극이 벌어졌다. 그 역할은 GDI+ 등 후대의 API가 계승하게 됐다.

RGBA라는 개념은 물리학에서 XYZ 공간 세 축에다가 시간을 더한 XYZT 4차원과 뭔가 비슷하게 느껴진다.;; 그것도 기하학적 의미에서 정확한 4차원을 말하는 건 아니니 말이다. 하긴, 생각해 보니 3차원 컴퓨터그래픽에서는 픽셀마다 알파 채널이 아니라 Z buffer 값이 부가 정보로 들어가기도 한다.

3. 구 그리기

중고교 미술 시간에는 4B 연필 한 자루 들고 스케치북에다가 구를 그리는 데생(?) 실습을 해 보고.. 이과 나와서 컴공 전산을 전공한다면, 구 렌더링 정도는 C 코딩으로 저수준부터 뚝딱뚝딱 짜 봤으면 싶다.
둘이 매우 훌륭한 대조가 되리라 생각된다~! 후자의 경우, 구를 렌더링 하라고 openGL 셰이더 명령 한 줄 던져주고 끗~~이 아니라, 저 모든 픽셀의 RGB 값을 직접 계산해서 구하는 것을 말한다.

사용자 삽입 이미지

(본인이 직접 그리거나 생성한 그림이 아니니 오해하지 말 것! ㄲㄲㄲ)

이 픽셀이 구의 영역에 포함돼 있는지, 있다면 거리가 얼마나 되는지를 구의 방정식으로부터 구하고, 광원으로부터는 거리가 얼마나 되고 빛과 면이 접하는 각도가 어찌 되는지.. 최종적으로 밝기가 얼마가 돼야 하는지를 직접 공식 집어넣어서 계산으로 구한다는 뜻이다.

그림자까지 생각하면 일이 너무 어려워질지 모르니 필수가 아닌 옵션으로 남긴다만, 구 자체만이라도..;;
그럼 이 엄청난 계산을 실시간 애니메이션 수준으로 해내는 오늘날 PC와 폰의 그래픽 카드들이 얼마나 대단한 물건인지도 알 수 있을 것이다.

이런 이론 공부 잉여질 체험을 회사 취업한 뒤에 직장에서 할 수는 없을 것이고, 취업 목적 코딩 학원에서 할 수도 없을 것이다. 그러니 아직 학생일 때 학교에서 해야지...!!

4. AI

요즘 아시다시피 AI니 머신러닝이니 하는 분야가 아주 각광받고 있다. 현실에서의 문제의 목표와 input/output을 머신러닝 라이브러리가 이해하고 해결할 수 있는 형태로 변환하고, 데이터를 학습시키고 결과물을 얻는 건 확실히 학교에서 맛보기로나마 가르칠 필요가 있어 보인다.

자연어 처리라든가 영상에서 뭔가를 인식하기, ‘관련 추천 아이템 제시’ 같은 분야에서 요즘 AI들은 정말 눈부시게 똑똑해지고 기술이 발달해 있다.
개인적으로 좀 개발됐으면 하는 AI는 “문자열을 보고 폰트 종류 판별하기”, 그리고 “넓은 군중 사진을 보고는 여기에 사람이 몇 명이나 있나 추산하기”이다.

요즘은 AI를 통해 없는 정보를 유추해 내서 흑백 사진도 컬러로 얼추 복원하고, 흐릿한 영상을 선명하게 바꾸기도 한다. 그런 계산 능력이면 폰트 종류 유추는 말할 것도 없고, 이런 획이 요런 모양이었으니 다른 글자는 요런 모양이어야 하겠다는 것까지 유추를 못 할 이유가 없다. 그러면 한글이나 한자 같은 폰트를 만드는 일이 노가다가 줄어들고 한결 수월해질 것이다.

군중 사진에서 머릿수 카운트도.. 쉬울 것 같으면서도 은근히 어려울 수 있어 보인다. 하지만 기술적으로 불가능한 일은 절대 아닐 것이다. 이를 응용하면 사진에 찍힌 쌀알이나 콩알 개수를 세게 할 수도 있다.

지금 Google 검색은 영어는 정말 사람 말을 알아듣고 인간의 두뇌 활동을 어느 정도 흉내 내는 경지에 도달해 있다. 경악스럽게 그지없다. 유튜브 동영상에서 영어 자막을 자동 생성하는 걸 보면.. 어지간한 음성은 다 정확하게 알아듣는다.

여주인공이 격투를 벌이는 어느 첩보 영화의 제목을 까맣게 잊어버려서 “2017 female spy movie”라고만 쳤는데.. 우와, 저것만 토대로 Atomic Blonde라는 영화를 딱 정확하게 알아 맞히려면 도대체 저 영화의 특성을 어디까지 다 파악하고 있어야 되는 걸까..?
정말 외계인을 고문하는 기업이 아닐 수 없다.

꼭 인텔처럼 컴퓨터의 하드웨어 근간인 반도체의 본좌가 아니어도, 마소처럼 소프트웨어의 근간인 운영체제를 꽉 독점하고 있지 않아도 된다. 그 위에서 돌아가는 소프트웨어 내지 웹 서비스 중에서도 억 소리 나는 기술을 개발할 것들이 저렇게 넘쳐난다.;;

5. 암호 해독과 번역

난해한 수수께끼 암호를 풀기 위해 과거에는 언어학자가 동원되었다. 뭐, 보이니치 문서라든가 롱고롱고 문자, 로제타석처럼 인간이 만든 난해 정보를 해독할 때야 당연히 해당 지역의 고대 언어를 아는 것이 도움이 될 것이다.
하지만 현재의 군사 내지 보안 암호는 인간이 아닌 기계가 생성하다 보니 언어적인 요소가 전혀 동원되지 않으며, 오로지 수학자의 직관만이 필요하다. 2차 세계 대전 때 앨런 튜링이 독일군 에니그마 암호를 풀 때 딱히 독일어 지식이 쓰이지는 않은 것과 같은 이치이다.

기계번역도 이와 비슷한 맥락의 변화를 겪고 있다. 기계번역 시스템을 개발하는 데 입력 언어나 출력 언어의 전문가 내지 언어학자가 동원되지 않는다. 그냥 전산학자, 데이터 과학자, 머신 러닝 전문가가 동원된다.
취급하는 언어의 고유한 특성은 기계번역 시스템의 동작에 영향을 주지 않는다는 것이 한편으로는 굉장히 섬뜩한 점이다. 기계가 자연어든 암호문이든 언어 데이터를 취급하는 방식 자체가 근본적으로 바뀐 것이다.

6. 다중 상속

객체지향 패러다임에서 다중 상속이라는 걸 생각해 보자. 클래스가 기반 클래스를 하나만 두는 게 평범하고 일반적이고 권장되는 반면, 얘는 좀 특수한 상황에서 "논란과 무리수를 감수하고라도 둘 이상 갖는 것"이라는 특성이 있다.

이걸 인생에다가 투영해 보면 좀 뜬금없는 얘기지만 일부다처...;; 내지 복수 국적과 비슷한 것 같다.
C++에서 다중 상속을 지원해 봤는데.. 이건 좀 아니다 싶었는지 후대의 객체지향 언어들은 생짜 다중 상속은 금지하고, 데이터 멤버가 없는 인터페이스에 대해서만 복수 구현을 허용했다. class A extends B implements C,D,E처럼 말인데.. 이건 일부일처다첩-_-;;;처럼 들린다.

우리나라는 조선은 말할 것도 없고 일제 시대와 대한민국 초기에 이르기까지 오랫동안.. 일부다처체는 아니지만 첩이라는 게 관행적으로 있었다.
그러다가 1960년대, 박 정희 때 사회 구조를 대대적으로 뜯어고치면서 공무원들부터 첩을 두는 게 금지되었고(있으면 직장에서 징계=_=), 완전한 일부일처제가 자리잡았다.

이게 대놓고 불륜을 조장한다기보다는.. 전근대 시절엔 지금처럼 미혼 여성이 혼자 돈 벌고 사회 생활을 하는 게 도저히 가능하거나 용납되지 않았기 때문이다. 서로 필요하기 때문에 작은 마누라라는 게 존재했었다.

이런 결혼 말고 복수 국적도.. 나라마다 허용되는 정도가 케바케이고 우리나라는 징병제 병역 때문에 더 민감한 측면이 있다. 자기 원래 국적을 유지한 채로 외국의 영주권을 취득할 수는 있지만 완전히 시민권, 국적을 취득하는 건 또 별개의 문제가 된다.
우리나라의 경우, 이 대한민국 땅에 있을 때만은 한국 국적만 행사해야 한다는 각서를 쓴 뒤에 외국인의 복수 국적 취득을 허용한다.

국적 말고 이중학적, 이중인격 이런 건 명백하게 비정상일 것이다. =_=;;

Posted by 사무엘

2022/04/18 08:33 2022/04/18 08:33
, ,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/2010

Windows 운영체제에서 제공하는 GUI용 컨트롤 중에는 애니메이션 컨트롤이라는 게 있다. 이것은 명령 버튼이나 에디트 컨트롤, 리스트 및 콤보 박스처럼 Windows 1.x 시절부터 있었던 완전 native가 아니고, 1990년대 중반에 운영체제가 32비트로 갈아 타던 95/NT 3.5 시기에 도입된 '공용 컨트롤'에 속한다. 즉, 도구모음줄, 리스트뷰 컨트롤, 트리 컨트롤, 진행 상황(progress) 표시 컨트롤, 슬라이더와 같은 급이다.

애니메이션 컨트롤은 컴퓨터가 무슨 작업을 하고 있을 때, 작업 중임을 간단한 '움짤'을 통해 사용자에게 시각적으로 피드백을 주는 역할을 한다. 즉, progress 컨트롤과 같이 쓰이는 경우가 많으며, 그 작업의 소요 시간이 굉장히 길거나 언제 끝날지 예측할 수 없는 상황일 때 애니메이션이 더욱 유용해진다.

게다가 애니메이션은 단순한 눈요기 이상으로 컴퓨터가 지금 내부적으로 하는 작업이 무슨 의미를 지니는지를 사용자에게 상징적으로 일깨워 주는 효과도 있다!

사용자 삽입 이미지

  • 탐색기에서 파일을 복사 중일 때 종이가 이쪽 서류가방에서 저쪽 서류가방으로 날아가는 모습
  • 삭제 중일 때 종이가 날아가면서 인수분해-_-되는 모습
  • 다운로드 중일 때 지구본에서 사용자의 컴퓨터로 종이가 날아가는 모습
  • 디스크 조각 모음을 실행할 때, 흩어졌던 건물 블록들이 짠~ 다시 한데 조립되는 모습

등이 좋은 예이다.
Windows 8 이후로 등장한 그 뱅글뱅글 돌아가는 동그라미들, 슉~ 중앙에 나타났다가 다시 슉~ 사라지는 동그라미들도 당연히 애니메이션에 속한다. 단, 얘들은 내부 작업의 의미를 시각화하는 건 없고 그냥 기하학적인 눈요기가 전부라 하겠다.

그럼 이 애니메이션 컨트롤은 어떤 형식의 파일을 사용할까?
컴퓨터 GUI에는 복잡한 코덱으로 디코딩해야 하는 전문적인 멀티미디어 동영상 말고, 그보다 가벼운 '움짤' 애니메이션 데이터라는 카테고리가 존재한다. 자동차에다 비유하면 버스보다 작은 승합차 정도에 대응할 것 같다.

  • 전문 동영상에 비해 파일 구조가 훨씬 더 단순하고, 프레임 크기는 작은 편이다.
  • 16/256색 같은 저색상도 지원한다. 저색상은 각 프레임을 무손실 압축으로 저장한다.
  • 오디오는 지원하지 않는다. 그 대신 투명색· 알파 채널을 지원한다. 영화 같은 전문 동영상에서는 이런 개념이 반대로 전혀 필요하지 않을 것이다.

카카오톡 이모티콘의 애니메이션이라든가 심지어 마우스 포인터의 애니메이션도 딱 이런 범주에 든다.
한때는 이런 움짤 저장용으로는 플래시(swf) 아니면 애니메이션 GIF가 널리 쓰였다. 그러나 플래시는 기능이 너무 많이 추가되면서 플레이어 런타임도 너무 무거워졌고.. 또 결정적으로 2010년대 중반부터는 완전히 퇴출됐다. gif야 뭐.. 256색의 한계를 벗어나지 못한 구닥다리일 뿐이고..

1990년대엔 오토데스크 사에서 개발한 flc/ fli라는 파일 포맷도 전문 동영상이라기보다는 애니메이션에 가까운 물건이었다. 심지어 Windows 매체 재생기의 초창기 버전이 재생을 지원하기도 했었다. 하지만 얘 역시 개인적으로는 실제 파일을 본 적이 전혀에 가까이 없으며, 소리소문 없이 듣보잡으로 전락하며 묻혔다.;;

Windows에서는 *.ani라고 애니메이션이 들어간 마우스 포인터 파일도 지원하긴 했지만.. 얘는 일반적인 비트맵이 아니라 아이콘에 대한 애니메이션이다 보니 담을 수 있는 그림에 대한 제약이 크다.
그러니 아주 오랜 세월이 지난 2010년대가 돼서야 png에다가 애니메이션이 추가된 apng, 그리고 jpg의 대체제로 개발된 webp에다가도 애니메이션이 추가된 Animated WebP가 뒤늦게 각광받는 중이다.

하지만 Windows 애니메이션 공용 컨트롤은 처음 도입되었던 1990년대 중반 이후로 시간이 완전히 정지한 채 시대에 너무 뒤쳐져 있다. 저런 최신 기술들을 전혀 지원하지 않고 오로지 avi만 지원하는데.. 제~~~일 단순하고 원시적인 run-length (RLE) 방식으로 압축된 256색 이하의 색상 영상만을 받아들인다.

얘의 디코딩 난이도를 이미지 파일 포맷에다 비유하자면, GIF에도 못 미치고 지금은 역사 속으로 사라진 PCX급밖에 되지 않는다.
저색상 기반답게 color key 기반으로 투명색 처리도 지원하긴 하지만.. 그럴 거면 gif라도 좀 지원할 것이지 하는 아쉬움이 남는다.

애니메이션 컨트롤은 왜 이렇게 허접하게 설계된 걸까? 전문적인 동영상 재생을 목적으로 만들어진 게 아니며, 탐색기에 들어가는 자그마한 애니메이션을 재생할 정도로만 극도로 최소주의 최적화 정신에 입각하여 기능이 구현됐기 때문이다.

1994~95년이면 모자이크나 넷스케이프 같은 WWW 기반 그래픽 웹브라우저가 이제 막 만들어졌던 시절이고, 386~486에 램 겨우 4~8MB급 컴퓨터로는 JPG는커녕 GIF 디코더를 돌리는 것도 다소 부담스러웠었다. 또한 그림판조차 BMP와 PCX 이외의 파일 포맷은 읽고 쓰는 걸 지원하지 않았었는데 GIF를 운영체제의 공용 컨트롤이 지원할 거라고는 전혀 기대할 수 없을 것이다.

물론 그땐 그랬다 치지만 지금까지도 애니메이션 컨트롤이 너무 빈약한 것은 변명의 여지가 없다고 하겠다. 그래서 이제는 탐색기 같은 운영체제 셸조차 애니메이션 컨트롤을 사용하지 않고 있다. 공용 컨트롤이란 게 원래는 셸에서 쓰던 물건을 보편적인 컴포넌트로 확장한 것이었는데 이건 참 아이러니한 현상이 아닐 수 없다.

요즘이야 탐색기에서 파일을 복사할 때는 전송 속도 그래프가 종전의 애니메이션을 대신하고 있다. 하지만 저 그림에서 보듯, Vista인가 7까지만 해도, 뭔가 서류 갈은 게 복사본이 짠~ 생기는 걸 형상화한 애니메이션이 떴었다. 파일을 삭제할 때도 비슷한 컨셉의 애니메이션을 볼 수 있었다.

그런 것들은 딱 봐도 알겠지만 Windows 9x 시절 같은 16~256컬러 나부랭이의 단순한 애니메이션이 아니다. 그리고 그건 애니메이션 공용 컨트롤로 재생하는 게 아니라는 것이다.;;
파일 내용을 표시하는 제일 중요한 부분조차 Windows 7의 탐색기부터는 리스트뷰 컨트롤을 사용하지 않는 것처럼 말이다.

(단, Spy++로 확인해 보면, 트리 컨트롤은 여전히 사용하고 있음. 외형을 많이 마개조해서 말이다.
반대로 Visual Studio는 먼 옛날 6.0 시절부터 지금까지.. 프로젝트/리소스 view에서 트리 컨트롤을 사용한 적이 없었다. 단적인 예로 트리 구조에서 ctrl+클릭으로 multiple selection이 동작하는 건 공용 컨트롤에서 전혀 지원되지 않는 기능이다. 흥미로운 사실이다.)

이상이다.
Windows 95 이후로 지금은 셸의 GUI와 공용 컨트롤 사이의 격차가 너무 많이 벌어져 있다.
9x 시절엔 작업 표시줄(taskbar)에 표시되는 각종 프로그램들 제목이 '탭 컨트롤'로 구현돼 있었다는 거 아는 분 계시려나.. 하지만 얼마 못 가.. 아무리 늦게 잡아도 XP때부터는 뭐 없이 당연히 자체 구현으로 바뀌었다.

Windows 10부터는 절대 안 바뀔 것 같은 메모장도 큰 파일의 로딩 속도가 획기적으로 개선됐고, \n 같은 줄 바꿈 문자 처리도 개선됐다.
에디트 컨트롤 같은 그 극도의 고인물 썩은물 코드도 마소에서 마음만 먹으면 개선될 수 있다. 그런 것처럼 시대 추세의 변화에 따라 애니메이션 컨트롤도 좀 개선이 됐으면 좋겠다는 게 개인적인 생각이다.

애니메이션 컨트롤과 관련된 기술적인 여담을 몇 가지 늘어놓으며 글을 맺도록 하겠다.

(1) 비트맵, 아이콘 따위는 응용 프로그램에서 자주 쓰이는 물건이다 보니 RT_BITMAP, RT_GROUP_ICON 같은 번호 기반의 표준 리소스 포맷도 있다. 그러나 애니메이션은 쓰이는 빈도가 압도적으로 낮다 보니 표준 리소스 포맷 번호가 제정돼 있지 않고, 그냥 "AVI"라는 포맷 문자열만 제정돼 있다. 거의 폰트(RT_FONT) 급으로 마이너하지 싶은데 말이다.

(2) 애니메이션 컨트롤은 전통적으로 백그라운드 스레드를 사용해서 애니메이션을 출력했는가 보다. 그리하지 않고 UI 스레드와 동일한 스레드에서 타이머만 사용해서 출력하게 하는 옵션은 ACS_TIMER라고 따로 있었는데..
Windows XP에서 도입된 공용 컨트롤 6에 들어간 애니메이션 컨트롤은 스레드 기능이 완전히 삭제되고 언제나 타이머 기반으로만 동작하게 됐다.

뭐, 애니메이션을 출력할 만한 상황이라면 작업은 어차피 백그라운드 스레드에서 진행되고 있을 것이고, UI 스레드는 당연히 살아 있어야 한다. UI 스레드가 응답 없이 block돼 있는데 애니메이션 컨트롤이 별도의 스레드로 혼자 살아서 UI 쪽에 접근하면.. 응답을 못 받고 같이 멎어 버리는 deadlock에 빠질 것이다.
애니메이션 컨트롤은 성능과 안정성 같은 요인을 감안해서 멀티스레드 기능을 빼 버린 것으로 보인다.

(3) progress 컨트롤은 공용 컨트롤 6 시절부터 marquee 애니메이션을 출력하는 기능이 추가됐다. 즉, 전체 작업량을 예측할 수 없어서 기약 없이 기다려야 할 때.. 프로그램이 작업 중이고 뻗지 않았다는 사실만 알려주는 뱅글뱅글 애니메이션 말이다.
요것만으로도 별도의 애니메이션 컨트롤을 사용해야 할 필요를 많이 줄여 주긴 했다. 완전히 대체해 버린 건 당연히 아니지만 말이다.

Posted by 사무엘

2022/04/04 08:35 2022/04/04 08:35
,
Response
No Trackback , No Comment
RSS :
http://moogi.new21.org/tc/rss/response/2005


블로그 이미지

그런즉 이제 애호박, 단호박, 늙은호박 이 셋은 항상 있으나, 그 중에 제일은 늙은호박이니라.

- 사무엘

Archives

Authors

  1. 사무엘

Calendar

«   2024/12   »
1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30 31        

Site Stats

Total hits:
3049036
Today:
56
Yesterday:
2142