웹개발을 하다보면 User-Agent String이라는걸 보게됩니다.
접속한 사람의 브라우저가 뭔지 서버에서 확인하는 그런건데 이게 요상한 역사가 있습니다.
2024년현재 이 Agent String(이하 UA)는 그냥 꼼수와 꼼수와 꼼수를 거쳐 하나의 거대한 역사의 한 장면을 연출합니다

처음에는 간단했습니다. Mosaic시절부터 Netscape때 까지만.

NCSA Mosaic/3.0 (Windows 95)
Mozilla/4.8 [en] (Windows NT 5.0; U)


위는 Win95의 모자이크고 아래는 윈도2000에서 넷스케이프4.8 (넷스케이프의 개발명이 Mozilla였습니다.)로 접속시 뜨는 UA입니다.
대충 이렇게 브라우저 이름과 운영체제가 뜨는 수준이었습니다.

하지만 Javascript(이하 JS)가 등장하면서 이를 활용한 웹페이지들이 만들어졌고 이를 지원하지 않으면 제대로 뜨지 않으니 웹개발자들은 지원여부를 구분해야했습니다. 다만 이를 지원하는지 확인하는게 UA밖에 없었습니다. 그래서 당시 주류이자 Javascript를 유일하게 지원했던 Netscape냐 아니냐 정도로 구분했습니다.

그 당시 쓰던 코드가 UA문구중에 Mozilla가 있느냐 없느냐 였습니다. 그러다 Internet Explorer(이하IE)가 등장하면서 꼬이기 시작합니다.

IE는 Netscape와 호환을 목표로 했기에 JS가 지원됐지만 웹페이지들은 Mozilla라는 문구만 확인했기에 IE에도 JS가 안되던 이전페이지만 보여줬고 이를 해결하기위해 MS가 만든건

Mozilla/1.22 (compatible; MSIE 2.0; Windows 95)

(Win95에서 IE2.0사용시)

네... User Agent에 Mozilla라고 집어넣고 compatible이라는 문구를 넣었습니다.
즉 나는 넷스케이프와 호환되는 녀석이다라고 적은건데 이 때까지만해도 이게 재앙의 시작일줄은 몰랐을겁니다.

이후 버전업을 하고 Windows가 이런저런 에디션이 생기면서 UA는 더 지랄맞아지게 됩니다

Mozilla/4.0 (compatible; U; MSIE 6.0; Windows NT 5.1) (Compatible; ; ; Trident/4.0; WOW64; Trident/4.0; SLCC2; .NET CLR 2.0.50727; .NET CLR 3.5.30729; .NET CLR 3.0.30729; .NET CLR 1.0.3705; .NET CLR 1.1.4322)


WindowsXP x64버전의 IE6.0을 32비트버전으로 실행했으며 닷넷프레임웍을 3.5버전으로 설치된 환경이라는 의미입니다.

닷넷프레임웍버전이 끼어들어간 이유가 당시 MS가 당시 많이 쓰이던 자바대신 닷넷을 밀고있었는데 이게 또 버전별로 호환을 탔기 때문입니다.

네...벌써 개판입니다. 하지만 MS는 IE개발에 손을 놓았고 Firefox가 등장하면서 또 한번의 격변이 일어납니다.

Firefox는 그래도 MS보단 고집이 있어서 (그리고 무엇보다 Netscape의 직계후손이라서)UA를 깔끔하게 보냈습니다.

Mozilla/5.0 (X11;U;Linux i686;en-US;rv:1.8.1) Gecko/2006101022 Firefox/2.0

 

리눅스 X11환경에서 영문으로 돌아가는 Firefox 2.0 대충요런식입니다.
특히 여기서 Gecko라는 문구가 중요한데 당시 웹표준이 대두가 되면서 HTML5가 이슈가 되기 시작했습니다. 그 당시 HTML5의 지원을 제일 서두르던것이 Firefox의 Gecko엔진이었고 Firefox의 엔진인 Gecko를 쓰는지만으로 HTML5가 지원되는지 아닌지 판단하곤했습니다. (Gecko는 오픈소스였기에 Firefox기반브라우저가 우후죽순 있었습니다.)

여기서 그동안 IE를 쓰던 애플은 자기들만의 브라우저가 있어야겠다고 판단하고 오픈소스 엔진인 KHTML을 가지고 Webkit이라는 엔진을 발표한뒤 Safari라는 이름으로 브라우저를 내놓게 됩니다.

Webkit은 HTML5를 준수하는 브라우저 였지만 웹페이지는 이를 알 수가 없었고 Gecko와 호환된다는 명목으로 UA에 like Gecko라는 문구를 적습니다.

Mozilla/5.0 (Macintosh; U; PPC Mac OS X 10_5_8; en-us) AppleWebKit/532.0+ (KHTML, like Gecko) Version/4.0.3 Safari/531.9.2009


물론 자신의 이름도 꼭 뒤에 적어서 Safari인지 판단하도록 했습니다.

그리고 Webkit을 기반으로 한 Chrome이 등장하면서 또 한번의 격변이 일어나는데...

Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/535.2 (KHTML, like Gecko) Chromium/15.0.871.0 Chrome/15.0.871.0 Safari/535.2


다시 개판이 되기 시작했습니다. 당시에는 Webkit을 이용한게 맞으니까 AppleWebkit이라고 적는건 이해하는데 뒤에 Safari도 함께 적었습니다. 그게 Webkit이 아닌 Safari라는 문구를 쓰는게 더 익숙했던 Webkit용 페이지 덕분에 그냥 Safari를 적었다고 합니다. 덕분에 크롬을 쓰면 애플홈페이지에서 맥 전용기능을 실행하려 들었다고 하네요.

추가로 IE11도 HTML5를 준수하면서 똑같이 like Gecko문구를 추가합니다.

Mozilla/5.0 (Windows NT 6.1; WOW64; Trident/7.0; AS; rv:11.0) like Gecko


어쩌다보니 자바스크립트지원 여부를 판단하는 Mozilla라는 문구처럼 Gecko라는 문구는 HTML5지원여부를 판단하는 문구가 되어버렸고 Mozilla와 관계없는 모든 브라우저가 Mozilla라고 적고 역시 Gecko엔진을 쓰지 않는 모든 브라우저가 Gecko를 적는 요상한 현상이 일어났습니다.

여기에 크롬이 브라우저의 대세가 되고 HTML5의 특정 기능들이 크롬에서 가장 먼저구현되며 Chrome이라는 문구를 찾아 전용코드를 쓰는 일이 생기게 되었는데

Chromium으로 만들어진 Edge는 당연히 이를 지원하기에 Chrome이라는 문구를 넣었습니다

 

Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/70.0.3538.102 Safari/537.36 Edge/18.19582


당연히 뒤에 자신이 Edge라는 문구를 추가해서요.

Mozilla에 Gecko에 Safari에 이젠 Chrome이라는 문구까지 UA에 들어가기 시작했습니다.

하하...이젠 개판이네...

,

※제목을 저렇게 해놓긴했지만 정확히 말하면 일반인이 생각하는 해커에 더 가깝습니다.
하지만 개발자는 곧 해커라고 볼 수있으니(안좋은 의미의 해커가 아니라 좋은 의미의 해커)그게그거 아닐까 싶습니다.

영화나 드라마등에서 개발자는 무슨 컴퓨터 앞에서 뚜드리고 뭔가 척!하면 짠하고 뭐가되는 그런 이미지입니다.
그런데 현실은 다들 알다시피 "이게 왜 이러지?"단계가 존재합니다. "생각한다-구현한다-기도한다"라는 개발자유머가 있을정도지요.

하지만 비개발자들은 개발을 맡기면 그냥 알아서 뿅하고 가져온다고 생각하는듯 합니다. 사실 개발의 80%가 디버깅이니 수없는 노가다끝에 만드는건데 말이지요.

개발자가 말하는 기능구현 = 이제 첫단추끼웠다. 이제 디버깅작업이다.
비개발자가 생각하는 기능구현 = 아무문제없이 완벽하다


PSP가 막 팔리던 시절 펌웨어 첫 해킹성공으로 사진한장이 공개됐는데 그냥 PSP화면에 "Hello, World!"가 띄워져있었습니다.
당연히 관련 커뮤니티는 난리났는데 당시 모 게시판에선 "고작 문구하나 띄운거가지고 뭔 호들갑이냐"라는 댓글을 달려있었습니다.
비개발자입장에선 "고작 문구"겠지만 이게 무엇을 의미하는거냐면 PSP라는 플랫폼에서 새로운 무언가를 만들수 있는 환경이 생겼다는겁니다.

사실 모든 개발환경을 갖추고 제일먼저하는건 "Hello World"를 띄우는겁니다. 해당 개발환경이 제대로 만들어진건지 확인하는것이지요.

비개발자들은 이 Hello World띄우는게 쉽다고 생각한거 같지만 개발자들입장에선 개발환경의 완성이라는 큰 의미인겁니다.
(이해가 안 된다면 집을 짓기위한 터다지기 작업이 완료됐다고 생각하시면 됩니다)

국내에선 디X인사이드 컴갤이나 Github갤에서 이런 요상한 글들이 많이 보이는데 거긴 아무래도 비개발자출신 자칭개발자들이 많아서 벌어지는듯 합니다. Hello World비하는 일상에 C99와 C17이 뭐가 다르냐고 하더군요. (Visual C++만 쓰는경우 이렇게 되곤합니다. 즉, 타 플랫폼 경험부족)

그러니까 개발자들에게 개발은 계단처럼 하나하나 밟아나가는 일입니다.
하지만 비개발자들은 개발이 짠하고 나오는걸로 착각을 자주합니다. 그러니 어렵게 하지말고 개발자들 힘들게 안 했으면 좋겠네요.

,

대부분은 관심없는거 압니다. 하지만 eu에게 뚜드려맞은 이유중 하나가 바로 webkit입니다.

webkit은 애플이 만드는 웹브라우저 엔진입니다
KDE에서 쓰던 KHTML을 잘 개량해서 쓸만하게 만들었고 대부분 크롬이긴했지만 한때는 웹브라우저 엔진 점유율 1위에 빛나던 물건입니다.

하지만 Webkit2를 애플이 발표하면서 크롬을  만들던 구글과 분쟁이 생겼고 구글이 기존의 Webkit을 포크해서 Blink로 바꾸게 되었습니다.
그리고 이름을 바꾸면서 기존에 크롬이 쓰던 Webkit1이 Blink가 되고 애플이 새로만든 Webkit2가 Webkit이 되었습니다.

즉, 지금의 Webkit은 사실 Webkit2고 과거의 영광을 가진 Webkit은 Blink인것이지요.

그리고 MS도 Webkit대신 Blink를 선택했고 현재대세는 애플의 Webkit이 아닌 기존Webkit을 계승한 Blink가 되었습니다.

하지만 애플은 이게 마음에 안들었는지 자사플랫폼(iOS)에선 Webkit(정확히는 Webkit2기반의 Webkit)사용을 강제했습니다. 그래서 Gecko엔진을 가진 Mozilla재단조차 iOS용 Firefox조차 Webkit으로 만들어야했습니다.

여기까진 십분이해 할 수 있습니다. 자사 라이브러리쓰게 할 수 있지요. 하지만 같은 Webkit이라도 Safari와 다른브라우저간의 레이아웃이 상당히 다릅니다. 성능도 당연히 다르고요. Safari외의 다른 브라우저를 못 쓰게하는건지 성능차이가 심하게 납니다.

심지어 웹 개발자들 말에 의하면 Chrome에 맞춰서 만들고 firerox로 접속해보면 딱히 건들곳이 없는데 iOS로 접속하면 다 깨지고 난리부르스라 그냥 Webkit용으로 따로 만드는게 낫다고 할정도입니다.

크롬과 파이어폭스는 엔진이 다름에도 서로 차이가 없지만 웹킷은 "어쩌라고"를 시전하는것이지요. 혼자 유아독존입니다.

그리고 최근 EU에서 애플을 Webkit에대해 반독점법 위반으로고소했습니다. 이미 라이트닝고수하다가 처맞은 전적이 있기에 이번에도 또 처맞을거 같은데 만약 이대로 된다면 Webkit의 점유율이 또 폭락하겠지요. iOS사용자들도 크롬을 선호하니까요.

Blink에 비해 특출난게 없고 Gecko보다 불안정하니 결국 트라이던트처럼 버려지고 Blink기반 사파리가 나올지도 모르겠습니다.

,

광고는 짜증나는 존재입니다
하지만 인터넷의 콘텐츠 제공자로서 수익을 얻을 몇 안되는 방법이지요

특히 광고제공계의 거인인 구글은 광고차단을 참 싫어합니다

하지만 웃기게도 구글외의 다른 회사들은 광고차단을 마케팅포인트로 삼고있습니다. 거기에 Adguard라던가 AdBlock plus라던가 ublock origin같은 광고차단플러그인들도 있지요.

최근 유튜브광고차단 플러그인 사용시 영상재생이 느려지는 일이 일어났습니다. 프리미엄 서비스를 쓰지 않으면 느려지게 하겠다는 의미인데 며칠 뒤에 이걸 또 해결해버리더군요.

거기에 유튜브앱을 수정해서 프리미엄기능을 활성화하거나 버전업을 막아서 서비스를 못 하게 막으니 앱버전을 Spoofing해버린다던지 합니다.

이쯤되니 구글vs해커가 되는 기분인데 과연 승자는 누구일까요.

,

구글은 ANGLE이라는 이름의 라이브러리를 잘 쓰고 있습니다.
구글답게 오픈소스로 풀려있습니다. 주로 안드로이드에서 이용중이지만 크롬에도 일부 적용중입니다.

https://github.com/google/angle

GitHub - google/angle: A conformant OpenGL ES implementation for Windows, Mac, Linux, iOS and Android.

A conformant OpenGL ES implementation for Windows, Mac, Linux, iOS and Android. - GitHub - google/angle: A conformant OpenGL ES implementation for Windows, Mac, Linux, iOS and Android.

github.com

사실 이 물건은 일종의 번역기입니다
리눅스 사용자들은 DXVK가 익숙하실수도 있습니다. DirectX로 만들어진 프로그램을 Vulkan으로 구동하게 만드는 라이브러리입니다.

이와 비슷하게 ANGLE은 그동안 모바일에서 쓰여온 OpenGLES를 최신API인 Vulkan나 윈도우의 DirectX등으로 구동되게 하는 물건입니다.

대체 왜 이걸 만든것이냐하면 사실 PC에서는 곁다리지원 정도고 모바일쪽이 개판되서 그렇습니다.

안드로이드에서  게임개발은 여전히 OpenGLES가 주력입니다. OpenGLES의 개발이 중단된지 오래지만 후속이라 할 수있는 Vulkan의 코드작성이 워낙 힘들고 그래픽칩셋업체(ARM Mali, Qualcomm Adreno)와 구글, 크로노스그룹 과의 손발이 안 맞아서 개판이된 상태라 아직도 절찬리에 OpenGLES가 이용중입니다.

모 게임회사에서는 OpenGLES로 만들던 게임을 Vulkan으로 가능하게 수정했더니 정상적으로 돌아가는걸 본 적이없다고 할 정도로 상태가 안 좋습니다.

저는 모바일Vulkan이 이 꼴이 된 제일 큰 범인으로 모바일 게임엔진의 투탑중 하나인 Unity를 꼽지만 Unity도 Vulkan을 이 따위로 만들고 싶어서 그랬을까요. (Unreal은 그나마 모바일 Vulkan의 상황이 괜찮습니다)

암튼 구글이 직접 OpenGLES로 만들어진 프로그램을 Vulkan으로 가능하게 만들어주기 위해 만들고 있는것이지요.

일부 커스텀 안드로이드에는 벌써부터 이를 적용해서 기존 Vulkan지원이 안되는 게임을 Vulkan으로 되게끔 하고 있더군요

EvolutionX의 게임옵션 중 일부 몇몇게임의 경우 확실히 프레임이 올라간다

실제로 DirectX로 돌아가게하는 기능도 있음에도 개발상황을 보면 Vulkan렌더링이 주력입니다. DirectX기능은 윈도용 크롬이 쓰는 중이라고 하지요.

이런걸보면 개판이 된 모바일 게임쪽을 구글이 총대를 멘듯한 느낌인데...ANGLE만 믿고 OpenGLES만 쓰는 일은 없어야 할텐데요. 과연...

,

일부러 픽셀 느낌을 내는 게임도 있지만 그냥 오래되서 고전 느낌이 나는 게임들이 의외로 많습니다. 대부분은 필터로 처리하지만 그래도 뭔가 이상한건 사실이지요.

 

3D게임에서는 FSR이라던가 DLSS라던가 하는 기술이 만들어졌습니다. 낮은 해상도로 렌더링 한다음 이를 AI로 업스케일링 하는 기술인데 GPU성능 발전이 슬슬 한계를 맞이하고 있다보니 FHD수준으로 렌더링한 다음 4k이상의 화질로 뽑는 것이지요. 그런데 사실 2023년 현재 FHD면 아직 충분하다는 소리를 듣고 있고 굳이 4k까지 욕심을 내지 않다보니 이쪽은 없어도 그만이라는 소리를 주로 듣습니다.

 

그렇다면 옛날 게임은 어떨까요? 옛날에는 640x480이면 고화질이란 소리를 들었습니다. 그리고 이 화질로만 구동되는 게임들이 꽤 있었습니다. 그래서 그런지 옛날 게임을 요즘 돌리면 옛날보다 화질이 더 구립니다. 아티팩트가 튄다고 하는데 말그대로 뭔가 튀어 보이니 화질이 더 구려보이는 겁니다.

 

옛날 게임중에 Need for Speed Underground라는 게임을 예로 들면 메뉴에선 640x480으로 렌더링하고 게임안에서는 1024x728 정도로 렌더링 되도록 짜여있는데 이를 Hook해서 1920x1080으로 렌더링 하는 파일이 배포되고 있습니다. DirectX 구조가 분석이 되다보니 이런것이 가능한 것이지요. 이런 류의 프로그램들은 많이 개발 되었고 지금도 만들어지고 있습니다. 특히 DirectX구버전에서 신버전으로 구동시키는 라이브러리(dgVoodoo같은)들이 이런 기능들을 같이 내장하고 있거나 별도의 플러그인 형태로 지원합니다.

 

3D게임들이야 렌더링 해상도를 강제로 변경하면 되니까 그렇다 치는데 2D게임들은 어떨까요?

이게 참 문제인데 기본적인 2D 이미지들은 해당해상도에서 굴리는 것을 전제로 그려졌기에 픽셀이 튑니다. 그래서 이를 뭉개는 필터들이 만들어졌습니다. 하지만 필터로 뭉개면 또 그건 그것대로 보기가 안 좋습니다. 색감도 죽어버리고요.

 

그래서 개인적으로 2D게임에도 이와 비슷한 DLSS같은 업스케일링 기능이 있었으면 좋겠는데 아직 이런 것이 만들어지지는 않은 것 같습니다. 옛날 게임인 쿠키샵을 해봤는데 해상도가 참...

 그래서 생각한 것이 고전게임을 창모드로 띄운 다음 이를 업스케일링해서 또 띄워주는 그런 프로그램은 없을까하는 것입니다. Waifu2X 라는 것이 느리긴 해도 확실히 아니메풍 2D게임의 업스케일링을 잘 해주고 있고 이와 비슷한 알고리즘들도 많이 만들어져있습니다.(Anime4k, Real-ESRGAN  등) Anime4k는 fast모드로 프레임당 5ms속도로 스케일을 올린다는데 가능하다면 이런 빠른 기술로 어떻게든 가능하지 않겠는가 하는게 제 생각입니다.

 

라고 생각하고 찾아본 순간..

Magpie 라는 프로그램이 있군요... 역시 세상은 좁다..

,

오래만의 넋두리입니다

요즘 전자기기들은 펌웨어라는게 대부분 들어갑니다. 전자기기들에게 있어서 이 펌웨어는 최소 구동을 위한 요소입니다. 즉, 이 펌웨어가 없으면 전자기기들은 그냥 벽돌이됩니다.

펌웨어는 엄연히 소프트웨어이기에 버그란게 당연히 존재합니다. 걔중에는 치명적인 버그도 있고 하드웨어에 밀접한 이상 기기를 망가뜨리기도 합니다.

----------------------------
최근 ESP8266모듈을 쓸일이 있었습니다.  교육용 키트로 와이파이 기능을 쓸 수 있게하는 제품입니다.  인기가 많아서 후속작인 ESP32가 기업용 제품에 쓰이기까지 하지요.

그런데 "교육용"이기에 당연히 저는 이 제품이 아두이노처럼 그냥 예제따라 하면 작동할 줄 알았습니다. 그런데 이상하게 동작이 안 되길래 찾던중 "펌웨어업데이트의 지옥에 온걸 환영한다"라는 글이 있더군요. ESP8266모듈은 펌웨어 업데이트가 엄청 빡세기로 유명하고 시중에 도는 제품은 펌웨어가 있기도 하고 없기도 하답니다.

이게 뭔 소리인가 싶었는데 칩셋제조국을 보고 이해했습니다. 본사가 상하이...
아무래도 칩셋 구하기 쉽다보니 짝퉁도 엄청 많아서(그런데 어찌어찌 동작은 합니다) 펌웨어 버전이 낮거나 없이 파는게 많은듯 하더군요.

결국 20개의 모듈을 개삽질해가면서 펌웨어 업데이트를 했고 지금은 정상작동합니다.
하지만 업데이트 하면서 펌웨어도 안 넣고 판다고 쌍욕을 엄청 했지요.
----------------------------
얼마전에 SSD 인클로저라는걸 샀습니다.
말이 거창해서 그렇지 SSD를 USB로 연결할 수 있게하는 제품입니다.

이쪽은 그래도 나름 유명업체것을 썼기에 큰불만 없었는데 이상하게 사용하고 30분만 지나면 열이 미친듯이 나더군요. 심지어 5기가 이상 파일을 넣으면 작동을 멈춥니다.

알고보니 펌웨어 버그였고 펌웨어 업데이트를 하고나니 정상적으로 작동합니다. 심지어 작년에 핫픽스수준으로 나온것이더군요. 그냥 펌웨어가 초기 버전이었던겁니다.
원인을 알고보니 제가 산건 한국정식업체것이 아니라 병행수입제품이었고 병행수입한곳이 펌웨어업데이트를 할리가 없으니 1년동안 먼지쌓인걸 그냥 배송한겁니다.

저야 이상해서 인터넷을 찾아서 원인을 펌웨어가 문제라고 알았지만 보통사람들은 모르겠지요. 그냥 고장난줄 알거고 버릴겁니다. 정식수입업체는 펌웨어 업데이트를 직접 해준다고 하는데 저는 그것도 불가능했지요.

----------------------------------
한때 닌텐도의 위유가 펌웨어 업데이트로 곤혹을 치뤘습니다.  새제품을 사면 업데이트로 허송세월을 보냈거든요. 그런데 인터넷 상태가 좋은 집만 있는게 아니죠. 그래서 사람들이 펌웨어를 업데이트해서 팔아달라고 하니(어차피 공장에서 나오는 족족 팔려나가고 있었으니) 닌텐도가 "선물하기전에 업데이트해주세요"라는 망발을 해서 욕을 먹었습니다. 포장을 풀어서 선물을 하면 쓰던거 주는거 같아서 좀 그렇잖아요.

플레이스테이션이 구버전 펌웨어에서 보안이 뚫려서 작살난거 생각하면 펌웨어를 미리 올려야 자사에 더 이득이었을텐데요.

스위치부터는 새제품에는 그 당시 최신 펌웨어가 들어있는것 같은데 펌웨어를 공장출고단계에서 올려주는게 이래저래 더 이득이었다는걸 몰랐던것 같습니다.
---------------------------------

그러니까 제발 펌웨어좀 최신버전 넣어서 팔아주세요...

,

노래를 불러주는 AI가 있습니다. Diff-SVC라고 부릅니다.
물론 정확히 말하면 stable-diffusion을 기반으로 목소리를 변환해주는것에 가깝습니다. 뒤에 SVC는 Singing Vocal Conversion이라고 해서 대놓고 목소리변환이라고 정의합니다.

누군가의 목소리를 학습한 AI가 다른 사람이 부른 노래의 목소리를 학습한 목소리로 바꿔주는 겁니다.

방법은 Stable-Diffusion과 동일한데

1. 목소리를 학습한 AI를 준비합니다. 이 AI는 사실 MEL-Spectrogram형태로 목소리를 학습했습니다.
2. 타겟의 음성을 준비합니다.
3. 여기에 각종노이즈를 섞어줍니다. 그냥 전파가 잘 안잡히는 라디오 수준으로 만든다고 생각하면 됩니다. 노래가 잡음과 함께 들려서 "노래가 들린다"수준으로 만드는겁니다.
4. 이걸 AI한테 "복원"하라고 시킵니다. AI는 자기나름대로 "복원"작업을 해서 돌려줍니다. 물론 아는 목소리는 자기가 학습한 목소리 뿐이라 오리지널이 아닌 학습한 그 목소리로 복원해줍니다.

...?

5. 보컬의 목소리가 바뀌었습니다.


그래서 이것저것 해보던 중 굉장한 사실을 알았습니다. 분명 "복원"이지만 원래 파일상태가 개판인 타겟을 넣으면 복원된것도 개판으로 나오더군요.

전 이걸 가이드보컬이라고 부르고 있습니다. 실제 녹음실에서 가수들이 노래부를때 가이드보컬의 노래를 듣고 이에 맞춰서 자신의 목소리로 부르거든요. 가이드보컬은 주로 오래된 경력자나 진짜 실력자가 합니다. 그래야 신인 가수들이 따라오니까요.

꼭 AI가 하는 짓이 가이드보컬을 따라 부르는 느낌이네요. 괜찮은 보컬은 AI가 변환했을때 상당히 훌륭한 결과가 나오는 반면 엉망인(특히 음반에서 보컬추출 등으로 만들어서 여기저기 망가진)걸 타겟으로하면 AI도 이상하게 만듭니다.

재미있지요.
TTS의 경우 학습초기를 보면 옹알이를 들을 수 있는데 꼭 애기들이 말을 배우는 느낌이 듭니다. 그런데 보컬AI도 좋은 가이드를 만나야 좋은 결과가 나온다는게 참 신기하네요.

,

우선 고등학교에서 수열은 배우셨을거라고 생각하고 간단한걸 이야기해보겠습니다

1 2 4 8 16 32 64 ?

다음에는 무엇이 올까요?
눈치빠른 사람은 128이라고 할겁니다.

이런걸 많이 해보셨다면 패턴이 눈에 보이니까요.
뒤의숫자=2x앞의숫자

2 3 5 9 17 33 65 ?
이건요?

129라는 숫자가 보이셨나요? 아까 수열에 +1이 된 패턴입니다. 생각보다 쉽죠?
뒤의숫자 = 2x앞의숫자+1

이제부터는 조금 다른 문제입니다.

0 1 3 7 15 29 63 127

여기서 잘못 된 숫자를 고쳐보세요.

이것의 답은 29가 아닌 31입니다. 아까 패턴에서 -1을 한건데 엉뚱한 녀석이 있습니다.
그래서 그 부분을 수열의 패턴을 "학습"을 통해 알아냈고 잘못 된 부분을 "복원"했습니다.

어쨌건 우린 일부가 망가진 수열에서 잘 못된 부분을 찾아서 고칠 수 있게 되었습니다. 왜냐하면 패턴을 함수형태로 알고 있으니 이 함수에서 벗어난 부분을 고치면 되니까요.

이번엔 일부가 망가진 수준이 아닌 모두 망가진 수열을 준비해봅니다.
이 수열은 우리가 알아낸 함수와 맞는 부분이 하나도 없습니다.

3 54 19 7 284 16 34 18

이중에 아무거나 하나를 붙잡고 복원해봅시다
저는 19를 기준으로 하겠습니다
7 11 19 36 67 131

역시 제일 위에서 알아낸 수열에서 -3을 한 것으로 했습니다. 하지만 19말곤 같은 숫자가 없네요.
이건 거의 "무에서 유를 창조"한 수준입니다. 어찌됐건 우리가 학습한 패턴에 맞게 "복원"을 했습니다.

우리는 이런식으로 "패턴을 학습"했고 이에 맞추어 "복원"했지만 사실상 "창조"에 가까운 짓을 해버렸습니다.


그런데 이 수열이라는게 말입니다. 우리가 보자마자 알아낼 수 있을 정도로 쉬운녀석들만 있는 것이 아닙니다.

이게 뭐지 싶은 규칙성따위 안 보이는 수열도 참 많습니다. 대부분의 자연현상들이 그러합니다. 그러나 과학자들은 그걸 최대한 복잡한 함수화해서 근사값형태로 중간값들을 뽑아내지요. 데이터들을 최대한 모아서 오차를 점점 줄여나가서 기어코 설명할 수 있을 정도로 수치화 합니다.

그림도 사실 규칙성따위 보이지 않는 수열입니다. 심지어 이건 그냥 수열도 아니고 2차원 수열입니다. 이걸 우린 행렬이라고 부릅니다. 고등학생때 수학을 포기한적이 없다면 한번은 들어보셨을겁니다.

정제가 잘 된 그림들을 모아 행렬로 표시하고 행렬들의 패턴을 알아내 함수 형태로 가지고 있는겁니다. 다만 그 함수가 굉장히 길고 복잡해서 여백이 부족해 적기 힘든겁니다.

하지만 컴퓨터는 단순노동으로 그 긴 함수계산을 빠르게 할 수 있고 "학습"이라는 이름하에 패턴파악을 할 수 있습니다. 그리고 인간이라는 놈들은 말도 안되는 다 망가진 노이즈 덩어리를 가지고 복원하라고 던지는거고 컴퓨터는 불평없이 복원을 하는겁니다.
매번 그림을 뽑을때마다 결과가 달라지는 것도 던지는 노이즈그림이 달라지기 때문입니다.

그렇기에 학습되지 못 한 그림은 만들지 못 하는 것이고 단순히 기존 그림들을 조합하는것도 아니라는 이야기가 되는 겁니다. 그렇기에 단순히 기존 그림들의 조합이 아니라는 것일 겁니다.

여기까지가 가장 이미지 생성알고리즘, 그 중 Stable-diffusion의 기초적인 이론입니다.

,

나도 참 희한하게 살았구나라는 생각이 듭니다.

우분투라는 녀석을 쓰게 된 계기도 특이한데 학교에서 이런저런 과제로 USB메모리를 쓰다가 집까지 바이러스가 들어오게 되었고 그것도 Virut.C라는 악질이 들어와서 모든 파일을 못 쓰게 만드는 일이 일어났습니다.

다행히 과제들과 자료들은 어찌저찌 백업되어있어서 살렸지만 이미 컴퓨터에 들어온 Virut의 박멸방법은 오직하나더군요. 모든 파일을 폐기해서 더 큰 피해를 막을것.
Virut은 모든 파일을 감염시키기 때문에 해당컴퓨터의 파일을 폐기하지 않으면 계속 남아있습니다.

그래서 이왕 깨끗하게 밀어버린는거 Windows대신 바이러스 걱정없는(실제로는 결국 이쪽도 보안관련으로 고생중이지만)리눅스로 넘어가기로 하고 그 중 가장 쉽다는 우분투를 선택했습니다. 당시 버전이 우분투 8.04라는 우분투 역사상 최고의 안정성을 보여준 버전이었습니다.

덕분에 우분투자체에 만족하면서 쓰다가(만약 9.10을 처음 접했다면 바로 접었을겁니다.) 역시 Windows가 필요하게 되서 가상머신도 돌리고 멀티부팅도하면서 썼는데 당시 인터넷은 ActiveX도배라서 인터넷하나 하는데도 고생을 엄청했습니다.

그나마 IEs4Linux라는게 있어서 IE를 쓸 수 있다는거에 만족해야했던 시절이었습니다.

그래서 Wine으로 이것저것 시도를 많이했고 아프리카TV를 보는데 성공하거나 한글2007을 돌리거나 하면서 노하우를 공유하고자 블로그를 시작했습니다.
이당시 삽질이 와닿지 않지만 그때 참 누군가에게 도움이 되길 바라면서 열심히 했었습니다.

요즘은 그렇게 힘들던 게임도 스팀덕에 어지간하면 돌아가고 MS Office는 별 힘 안들이고 쓸 수 있는 등 Wine과 그 파생의 발전이 눈부시게 빨라졌네요. 참고로 제 PC는 Windows 가상머신이 가끔 켜지고 대부분은 리눅스만으로 처리합니다.

이 정도로 리눅스가 편리해진 탓인지 그 때만큼 화려한 삽질이 덜하게 되었고 점점 포스팅이 늦어지고 있습니다. 언젠가는 여기있던 삽질들도 추억이 되는 날이 오겠지요.

,