Archive for March 2010
Blitting 모델을 간단히 정리해보면 다음과 같습니다.
그럼 반대로 생각하면 가상의 속성을 갖는데 그게 꼭 실제와 일치할 필요가 있을까요? 예를들어 Sprite에서 Graphics의 DrawingAPI는 x,y 좌표계를 지원하지만 제 Blitting 모델에서는 짜피 그 x,y가 matrix변환시 영향을 주는 가상의 좌표계일 뿐입니다.
따라서 이왕 가상의 좌표계라면 당연히 x,y,z 도 가능합니다. 그럼 가상의 x,y,z 좌표를 맘대로 정의하고 변경한 뒤 렌더링 시에만 잘 반영해주면 되죠.
여기에서는 bitmapData를 통해서 구현했습니다만, 사실 플래시는 벡터에 최적화 된 그래픽스 엔진을 갖고 있습니다. 벡터에 최적화되었다는 의미가 비트맵보다 벡터보다 빨리 재생한다는 뜻은 아니지만 벡터를 그리는데 상당히 고속으로 처리한다는 의미는 됩니다. 플10부터는 새로운 Drawing API가 도입되어있습니다. 이 기술은 FXG포멧을 번역하는 기저 기술이기도 합니다. 이 Drawing API가 잘 알려져 있지 않은 이유는 이 API를 사용하려면 먼저 커맨드 패턴에 대한 이해가 필요하기 때문입니다.
디자인패턴에서 가장 중요한 패턴을 딱 하나 꼽아야 한다면 전 주저 없이 커맨드패턴을 꼽습니다. 제 포스트 중에도 커맨드 패턴에 대한 글이 있긴 합니다만, 이 포스트는 한참 DP 스터디를 할 때 교보재로 작성한거라 처음 보는 분들에게는 힘듭니다. 해서 간단히 커맨드 패턴을 정리해보겠습니다.
하나의 개발용 언어를 취미가 아닌 상용 수준으로 사용한다는 것은 많은 고민과 훈련은 물론 수 많은 라이브러리 작성(과 시간도)을 동반합니다. 저의 호기심은 비지니스 필드에서 as3를 사용하는 사람이 얼마나 있을까? 라는 점입니다. 물론 as3를 자신의 업으로 사용한다는 의미는 여러가지가 될 수 있습니다만 제가 정확하게 말하고자 하는 경우는 as3로 어플리케이션 전체를 작성해야하는 직업을 가리킵니다.
한국 플래시 시장 매출 대부분이 핸드폰이나 휴대용 디바이스용 UI 컨텐츠인 걸 감안하면, as1만 안써도 다행인 경우가 대부분이고 이러닝 업계는 더욱 as2에 집착해가는 지경입니다. 그런가하면 비지니스 사이트가 플래시로 구현된 경우는 flex를 기반으로 개발되는 경우가 대부분이라 as3를 개발 기저용 언어로 사용한다기보다는 framework을 돌리기 위한 스크립트로서 사용하는 방식이 대부분입니다.
간단히 말해 as3로 슬라이드쇼, 이미지 에디터, 비지니스 사이트, 게임 등을 만드는 게 직업인 인구는 몇 명이나 있을까? 싶은 거죠.
예를 들어 용호씨가 스타플에서 as3로 격하게 개발하니 비지니스 필드에서 as3를 사용하는 케이스라 할 수 있을 것입니다. 또한 전 잘 모르는 분이지만, 제가 몸담았던 모기업에서 각종 플래시 어플을 만드는 노경섭이란 분도 그 결과물을 보면 업으로 as3를 사용하고 있는 분이라 할 수 있겠죠. 다음의 스트릿뷰, 네이버블로그의 이미지 편집기, 수 많은 웹게임 등을 개발한 사람들도 모두 as3를 비지니스 필드에서 사용하고 있다 할 만 합니다.
하지만 사실 전체 플래시 업계의 매출 생태계를 보면 as3가 직업인 인구는 거의 무시할 수준의 영역이 아닐까 싶습니다. 다들 취미와 호기심 외에 as3를 사용해야하는만 직업적인 환경 자체가 아니란거죠. 전 이런 환경 하에서 과연 프로 수준의 as3에 대한 포스트가 갖는 의미는 뭘까? 라고 가끔 회의를 느낍니다. 제가 다이버스터라는 블로그에서 추구하는 가치는 as3에 대한 포스팅을 통해 제 직업적인 내용으로 사회 환원같은걸 하고 싶은 작은 바램입니다(되고 있는지는 별개로 ^^) 따라서 같은 노력을 as2나 flex로 포스팅하는 편이 방문자에게 기부에 대한 가치가 더 있을 것 같다는 생각도 자주 합니다.
스터디나 여러 만남에서 많이 느끼는 현실은 자신의 본업이 as2인데 as3를 가르쳐봐야, 짜피 집중력이나 열의는 한 없이 낮은 취미 또는 학생 수준이더라는 겁니다. 한국에서 as3를 사용해야하는 시장이 얼마나 넓어질지는 잘모르겠지만 현재 상태로는 인력시장에서 as3를 업무에서 요구하는 수준으로 사용할 수 있는 인재가 매우 희귀하고, 쓸만하다싶으면 최소 어디 팀장인 이 현실은 당분간 달라질 것 같지는 않습니다.
단지 저는 현재 as3를 사용하는 일을 하고 있다보니 겸사겸사 생각나는걸 포스팅하는 식이라 as3관련 내용을 포스팅하고 있는 건지도 모르겠습니다. 어쩔 땐 php, asp, jsp 등에 대한 좋은 아이디어를 포스팅하고 싶을 때도 있고, RDBMS에 대해서 뛰어난 설계가 생각날 때도 있고 DX3D, OpenGL에 좋은 파이프라인 알고리즘을 찾아낼 때도 있습니다. 하지만 결국 잡스런 블로그가 웹에서 그닥 의미를 갖지 못한다는걸 한 명의 기획자로서 잘 느끼는지라 오직 as3로 방향을 잡아서 포스트를 모아왔습니다.
이러한 방향성과 블로그의 주제나 의미가 저의 목적(다수에게 사회환원)과 맞지 않는다는 회의가 밀려오고 있었는데, 최근에 일어난 일은 저에게 다이버스터를 다시 계속 운영할까 라는 반전을 줬습니다.
바로 용호씨의 열성과 집중력이죠. 뭔가 참 보람이 있다고 할까요. 이 포스트는 거의 제 대문으로 사용해야할 지경입니다.
잡담에 결론이 있겠습니까만은 다이버스터에서 매우 희귀한 신변잡기글을 하나 쓰게 만드신 용호님의 열성에 심심한 감사의 인사를 포스트로 대신합니다.
웹을 돌아다니다보면 visualist라고 부르는 사람들의 플래시 작품을 보게됩니다. 상당히 현란하고 부드러운 애니메이션 보면 이게 과연 플래시 성능으로 가능하단 말이야? 라는 생각까지 들곤하죠. 대부분 이러한 전시(?) 전용 플래시가 높은 성능을 낼 수 있는 이유는 뭘까요? 여러 가지 자신 만의 노하우를 사용했겠지만 다음과 같은 공통점이 있습니다.
반대로 생각해 봅시다. 다른 플래시 어플은 왜 느릴까요? 의외로 답은 당연한 곳에 있습니다.
여러 가지 다른 이유도 있을 수 있지만, 사실 다른 이유보다는 위의 두 가지가 Direct2D로 작동하는 설치형 어플같은 FPS를 낼 수 없게 만듭니다.
as3가 제안하는 Display 모델과 Event 모델은 사실 플래시플레이어가 감당하기엔 너무 무거운 객체구조라는 겁니다. 이는 마치 광범위한 핫스왑이 잡히기 전인 자바 1.2x. 1.3x 시대의 swing과 같은 느낌입니다.
그러면 visualist 들의 작품과 같이 부드러운 FPS를 갖게 하면서도 기존 플래시 어플이 처리 해주던 모든 Event와 Display의 다양한 기능을 사용하려면 어떻게 해야할까요?
정말이지 죽어버린게 아닐까 싶던 학영씨의 블로그에 새로운 글이 포스팅 되었습니다. 그런 김에 문서화에 대한 조금 다른 관점의 얘기를 해볼까 합니다. asDoc을 통해 플래시 업계에도 많이 알려진 구조적 문서화는 해당 코드를 상세하게 설명하는 방법입니다. 코드를 읽는 것보다 표와 사람의 언어로 정리된 문서를 읽는 게 보다 이해를 쉽게 해주기 때문에 문서에는 코드가 암묵적으로 내포하고 있는 의미나 제한, 순서 등을 기술할 수 있고 거기에 더해 적절한 호스트 샘플도 같이 기재할 수 있는 장점이 있습니다. 그래서 문서화를 하자는 건 개발업계에서 상당히 주류적인 움직임입니다.
저는 문서화에 대해 반대하는 파는 아닙니다만 문서화는 상당히 위험하다는 걸 설명해드리려고 합니다.
문서는 코드를 설명하지만 코드와 문서는 매우 다른 특성을 갖고 있습니다. 문서는 단지 텍스트 덩어리 일 뿐이지만, 코드는 컴파일러가 매번 검사하는 안전한 텍스트입니다. 따라서 이러한 차이가 여러 가지 문제점을 만들어냅니다. 그것을 상세히 알아보죠.
이러한 문서의 특성은 매우 흔한 것으로 여러분이 심지어 컴파일 타임마다 문서를 새로 생성해서 웹에 매번 게시한다고 해도 소용없습니다. 왜냐면 게시한 순간 누군가 그것을 내려받거나 퍼가거나 복사한 문서의 복제본을 갖게 되고 그러한 문서를 이용하여 개발하려고 하기 때문입니다. 이러한 문제는 pv3d, corelib등 유명한 라이브러리에서도 매우 흔합니다. 문서로 개발하면 큰일나는 거죠.
자동화 서버를 이용해서 코드가 수정될 때마다 문서를 새로 갱신하여 웹에 게시하면 온라인문서는 현재 코드와 일치할 수도 있습니다.
하지만 이도 매우 위험한 게 코드의 수정자가 여러 명이다 보니 문서화에 대해서도 충돌이 일어나게 됩니다. 전에도 설명한 적이 있는데 문서의 품질은 전적으로 글짓기실력에 달려있습니다. 코드의 일관성이 중요한 것처럼 문서의 일관성이 지켜지지 않는다면 문서의 가치는 크게 떨어집니다. 생각해보세요. 거의 모든 문서에 샘플코드가 있다가 갑자기 샘플코드가 없는 패키지가 덩그라니 있다던가 조목조목 리스트로 설명하던 스타일이 어떤 클래스에서는 아무런 설명도 없다던가하는 건 마치 코드에서 받는 이질성과 비슷한 쇼크를 일으킵니다. 액션스크립트3.0도 이는 마찬가지라 비교적 새로 생긴 플10api군에서 대해선 전혀 설명이나 예제가 없는 식으로 문서가 되어있는 건 꽤나 당혹스런 경험입니다.
이 문제를 해결하는 방법은 그닥 명쾌한게 없습니다만 다음과 같은 노력을 통해 다소 완화시킬 수는 있습니다.
하지만 이 문제의 근본적인 해결 방법은 한가지로 요약할 수 있습니다.
문서관리를 위한 추가적인 자원을 배분해야 한다.
만약 현재 개발팀의 여력이 문서화에 대한 제대로 된 자원을 배분할 수 없다면 문서화는 독이 됩니다. 최초 클래스를 설계할 때 작성한 스케치 같은 문서는 결국 작업일정에 밀려 그 이후 코드 수정 시 제대로 같이 수정되지 못하고 코드를 오해하게 만드는 문서로서 남게 됩니다. 결국 이러한 부패는 코드 전체에 번져 문서를 읽을 수록 오류가 커지는 결과를 초래합니다. 이 문제는 매우 심각하여 많은 오픈소스 커뮤니티에서도 문서의 유지보수에 대한 자원을 할당하는데 실패하여 문서는 썩어 문드러져 있습니다.
따라서 문서 유지보수에 대한 확실한 자원할당이 부족하다면 과감하게 문서화를 하지 마세요. 오히려 문서가 없으면 코드를 확인하여 사용하게 되므로 문서화로 인한 오류를 막을 수 있습니다.
