|
|
||||||||
| 경고! 게시물 작성자의 사전 허락없는 메일주소 추출행위 절대 금지 |
|
지난 번 연합세미나 때에 제가 발표 했던 것처럼 플래시용 파스칼 RAD툴 개발에 대한 연구를 하면서 플래시를 이런저런 각도로 뜯어 봤었는데요.. 저도 스티브잡스가 했던 말의 상당 부분을 공감하게 됐습니다.(스티브잡스가 그 말을 하기 전에요)
플래시파일(SWF)의 구조를 잘 살펴보니 너무 비트구조가 많았습니다. 물론 비트구조는 파일의 크기를 줄이기 위해서 그렇게 한 것인데 매크로미디어가 SWF를 처음 만들었을 때에는 파일크기가 중요했기 때문에 사이즈를 줄이려고 그렇게 만들었던 것 같습니다. 잘아시다시피 CPU가 비트연산을 많이 하면 공간적으로는 효율적이지만 시간적으로는 낭비가 심합니다. 일반 PC에서는 CPU가 꽤 고속이니깐 괜찮은데 소형CPU에서는 그렇지가 못하겠죠.. 그것을 잘 알면서도 그렇게 한 것은 역시나 파일사이즈를 줄여서 인터넷에서 사용하기 용이하게 하자는 건데... 비트구조를 많이 만들어서 사이즈를 절약했으면 그러면 파일을 압축하지는 말아야하는데.. 결국 나중에는 압축까지 하고 말았죠. (현재 쓰이는 대부분의 SWF는 Deflte로 압축된 형식) 그러니 플레이어는 압축을 풀고 또 비트구조로 된 포맷을 읽어들여서 실제 데이터 구조로 변환도 해야하고.. 그러니 속도가 빠를 수가 없지않겠습니까.. 물론 이것은 플래시의 많은 부분중에 한 가지만 얘기해 본겁니다. 변수명이나 함수명등을 문자열로 가지고 있는 것도 큰 문젭니다. 변수, 함수를 많이 사용할 수록 속도는 느려집니다. (물론 쓰지 마라는 얘기는 아니죠.. 같은 라인 수라면 변수를 적게 쓰는것이 더 빠르다는 겁니다.) 게다가...플래시(개발툴)의 컴파일러 수준은 완전 대학교 졸업작품 수준입니다. 최적화를 거의 안하다시피하고 심지어는 플레이어에 내장된 액션스크립트 코멘드를 단 한줄만 호출하면 될 것을 그것을 액션스크립트에서 함수로 호출하도록 만들어 놔서 한라인이면 될 것을 함수호출하는 과정이 추가돼서 5~6라인으로 만들어 놓은 기능들도 많습니다. 델파이로 치자면 API함수 한 라인을 똑같은 구조의 델파이 함수로 만들어 놨다는 겁니다. 그 함수 내부에서는 여러가지 변수도 사용하고... 쓰는 개발자는 똑같이 쓰는데 함수를 호출하는 과정과 변수처리, 리턴하는 과정등이 추가 돼서 라인 수는 더 늘고 메모리도 더 쓰고.. 플래시는 변수버퍼가 문자열로 접근하게 되어 있어서 속도도 더 느려지고.... 그런 바보같은 부분이 많습니다. 어도비가 플래시를 인수하면서 가장 먼저 했어야하는 것이 속도 개선입니다. 호환성에 문제가 생길 것을 감수하고서라도 속도 개선은 했어야했습니다. 플래시가 더 오래 가려면 지금이라도 근본적인 부분부터 개선을 해서 최적화를 해야한다고 생각합니다. 자신들의 플랫폼 위에 중간 성격의 플랫폼이 얹혀질 경우의 재앙에 대해서 상당히 공감을 하고 있습니다. 플래시가 어도비의 독점 기술인데 너무 보급되어 있다보니 사실상 표준처럼 되어있습니다. 예를 들어 윈도우즈 개발툴은 델파이가 유일한 상황을 가정해보면, MS가 윈도우즈 2007을 발표했는데, 델파이가 2007의 최신 기술들을 지원하지 않거나, 지원하는데 오랜 시간이 걸린다면, 플랫폼 벤더로서 MS가 할 수 있는 일은 델파이 개발사에 비는 수밖에 더 없지 않을까 하는 생각도 해봅니다. 플래시 자체가 오픈된 기술이라서 플래시의 표준 제정을 함께 하고, 개발툴을 개발/판매하는 회사가 여러가지가 있다면 좀 얘기가 달라질 수도 있는 것 같습니다. 실제 우리 개발자들도 개발에 있어서 가장 중요하게 생각하는 것 중에 하나가 "대체가능성"이라고 알고 있습니다. 그래서 외부 라이브러리를 사용할때는 항상 "소스 포함" 된 것을 사용하라는 얘기들을 많이 합니다. 만에 하나 외부라이브러리에 치명적인결함이 있어서 그걸 사용한 우리 제품에 영향이 미치게 될 경우, 소스가 없다면 손쓸 방법이 없기 때문입니다. 뭐 그런 이유로 잡스의 판단은 옳은 걸로 생각하고 있습니다.
그런 의미에는 필수 앱들은 본인들이 직접 만들어 탑재하고(연락처, 달력, 사파리 등), 그 앱의 데이터는 외부 앱에 공개하지 않도록 하는 정책도 같은 의미라고 볼 수 있을 것 같습니다. 저역시도 데이터를 공유할 수 있게 해주면 훨씬 편하고 좋을텐데 (그들이 추구하는 사용자 경험을 훨씬 좋게 만들어 줄 수 있을텐데) 라는 생각을 했는데, 과거에 맥이 "포토샵을 사용하기 위한 컴퓨터" 정도의 위치를 차지했다가 어도비가 맥을 버리고 윈도우즈쪽으로 넘어가면서 겪었던 일들 등 과거의 쓰라린 경험을 통해 외부 의존적이지 않는 플랫폼을 만들어야 한다는 것은 타협할 수 없는 애플의 원칙이 된 것 같다는 생각이 듭니다.
소프트웨어가 느릴때 가속하는 가장 손쉬운 방법은 소프트웨어를 개선하는 것일 수 있지만 플래시처럼 저변확대가 충분히 된 기술일 경우 호환성이 중요해집니다.
이는 h.264같은 영상 포멧처럼 한 장면을 표현하기 위해 여러 알고리즘을 사용해서라도 용량을 줄이려고 하는 것과 비슷합니다. h.264 보다야 노력이 부족했겠지만 플래시는 하나의 포멧이고 일정부분 속도 개선이 가능하더라도 새로운 "플랑시?" 같은 포멧을 만들어 플래시 플레이어가 모두 지원하도록 하는 방향으로 변화해야합니다. 다르게 생각해보면 용량을 줄이는 방식이 속도가 느리다면 전용? 칩을 설계해서 제공할 수도 있습니다. (요즘 옆에 하드웨어 하시는 분과 있다보니 -_ -;; 살짝 생각이 물들기도 한것 같지만 ㅎㅎ) 칩이 뭐하다면 전용 연산 명령어를 만들수도 있습니다. 문제는 어도비가 그만한 영향력의 기업인가 하는 것이겠지만... 가속으로 보자면 플래시에서 3D 가속기능을 지원하게되면 게임 클라이언트 단은 웹(특히 클라우드 세상이라면 더욱 유용할듯)에 올라가서 훨씬 설치 및 파급력이 높아질 것입니다. 디자인을 필두로 하고 탄탄한 기술을 기반으로 성장한 애플의 독자 노선이 기술적 폐쇄성과 맞물려 매킨토시가 위기를 맞았듯 이런 스타일의 방향은 장기적으로 또다른 위기를 가져올 수 있습니다. 다만... 예전보다는 훨씬 덩치를 키운 상황이고 클라우드 컴퓨팅이라는 새로운 시장에 어떻게 대응하느냐가 중요해질 것 같습니다. 이미 PC를 넘어 스마트폰의 세계가 열렸습니다. 이러한 시기는 기술의 틈이 생기는 시기이며 막힌것 같은 상황도 변화할 수 있는 시기입니다. 기존 시장을 이탈하는 사람이 많으니 기존 시장에도 기회이고 새로운 시장이 넓어지고 있으니 새로운 시장도 기회입니다. 관련 글 리스트
|
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Copyright © 1999-2015, borlandforum.com. All right reserved. |
기술 리더들의 방향이 있더라도 대중이 원하는 방향이 있다면 항상? 잡은같지만 틈새 기술이 열리는것 같습니다.
정상적이라면 애플에서 PC로 생기겠지만...
그런데 탈옥?폰에서는 플래쉬 가능한가요? 애플은 잘 몰라서.. --;;