프로젝트를 시작하는 단계에서 반드시 정해야 하는 규칙 중의 하나가 바로 명명법(Naming Rule)이다. ActionScript 프로젝트에 적합한 명명법을 찾기 위해서 대표적인 명명법을 살펴볼 것이다.

PascalCasing (파스칼 케이싱)
클래스, 열거형, 이벤트, 메서드 등의 이름을 만들 때에는 대문자로 시작하는 변수명을 사용한다. 복합어일 경우 중간에 시작하는 새로운 단어는 대문자로 적는다.
예) UtilityBox, MainFrame

CamelCasing (카멜 케이싱)
메서드의 매개변수의 이름에 적용되는데 첫번째 문자는 소문자로 시작하고 복합어 일 경우 파스칼 케이싱과 동일하게 적용한다. 동일한 이름을 가지는 두 항목을 구분하는 용도로도 사용한다.
예) utilityBox, mainFrame

GNU Naming Convention
Linux의 프로젝트들은 GNU Naming Convention이라는 형태의 명명법을 주로 사용한다. 모두 소문자를 사용하고 복합어 사이를 '_'를 사용하여 연결한다.
예) gtk_widget_activate

Hungarian notation (헝가리안 표기법)
Microsoft 의 개발자중 헝가리 사람의 프로그래머가 쓰던 변수 명명법으로 MS내부에서 따라쓰기 시작하던 것이 점차 전세계의 프로그래머들에게 널리 퍼져 이젠 프로그램 코딩시 변수 명명의 표준적인 관례가 되었다. C#에서는 이러한 명명법을 사용하지 않고 있으며 주로 윈도우즈 프로그래밍에 사용된다.
예) g_bTrue
첫글자 g는 전역변수, m은 멤버변수를 의미한다. 전역이나 멤버변수의 경우에는 그 다음에 _ 를 적는다. b는 Boolean타입을 의미하고 True가 의미있는 이름이다.
예) nCnt
전역이나 멤버변수가 아니므로 g_ 나 m_ 가 없다. n과 i는 자연수를 뜻하며 i는 주로 인덱스에 사용하고, n은 카운트의 목적에 주로 사용한다. 의미있는 이름이 길 경우에는 자음만을 사용한다.

BREW Naming Convention
BREW 는 Qualcomm에서 만든 플랫폼으로 국내의 휴대폰 제조사들은 초기부터 현재까지 이 코드들을 많이 사용하고 있다. 기존 명명법을 조합한 형태로 변종 명명법이지만, 익숙함을 벗어나지 못하는 국내 제조사의 개발자들이 선호하는 형태이다. 클래스나 인터페이스를 대문자나 파스칼 케이싱으로 앞에 두고, '_' 이후에 다시 파스칼 케이싱 형태의 메서드 명을 적는다.
예) IDISPLAY_ClearScreen

Constant (상수)
거의 모든 명명법에서 상수를 표기하는 방법은 거의 동일하다. 모든 문자를 대문자로 사용하는 GNU Naming Convention의 형태를 사용한다.
예) DEFAULT_COUNTRY_CODE

다양한 명명법들이 존재한다. 어떤 방법이 가장 좋다라는 것은 없다. 프로젝트의 상황에 가장 적합한 명명법을 팀에서 결정하는 것이다. 리눅스에 사용될 플래시 프로젝트라면 GNU Naming Convention을 사용할 수도 있다. 구식(?)인 헝가라인 표기법을 도입하거나 C#과 같은 파스칼 케이싱, 카멜 케이싱을 도입하거나, 매크로미디어식의 첨자를 추가하는 명명법을 도입할 수도 있다. 중요한 것은 프로젝트의 초기에 명명법을 결정하고 모든 개발자들이 규칙을 따라 코드를 작성하는 것이다.

이러한 변수 명명법의 목적은 '코드의 일관성을 유지한다'라는 것으로 요약된다. 코드의 일관성은 최종적으로 '읽기 쉬운 코드'를 만들어 낸다. 모든 소프트웨어 개발 프로젝트에서 가독성보다 중요한 것은 없을 것이다.

내가 속한 부서에서 관련된 업무를 하는 사람이 혼자인지라, Adobe CS4 신제품 발표회와 Flash Day 행사에 다녀왔다.

 

딱히 기대한건 없었지만 그래도 조금 실망스럽다(왜 난 모든 Adobe 행사에 다 가는데 경품이 안되냐고?). 너무 큰 장소에 너무나 많은 사람이 와서 집중이 불가능했다. 너무 어수선한 상황에 몰입할 수 없는 분위기의 진행...

 

업무로 인해서 Photoshop CS4(Photoshop 11)와 Flash CS4(Flash 10)를 이미 사용하고 있어서 배우러 가는 행사라기 보다, 눈을 쉬게 할 목적으로 간 행사였다. 그러나... 실망하고 경품만 기대하게 되었다. 결국 친구가 전화와서 7시 정도에 행사장을 빠져 나갔다.

 

디카가 없는 관계로 사진은 없고, 입사후에 알게된 허한솔 선임연구원님의 발표에 내가 그린 그림도 나왔는데... 황소를 그리면서 bool이라는 단어를 썻더라. bull이 모양이 안나오고 참/거짓의 뭔가 오묘한 의미로 그 단어를 썼던가?

 

결론은 이제 Adobe 전시회에 기대를 접고 다음부터는 가지 않겠다.

그래픽과 언어를 모두 가진 컨텐츠. 이것이 바로 Flash이다.

 

Flash가 가지는 장점은 작은 크기와 많은 개발자, 이미 만들어지 수많은 컨텐츠들을 들 수 있다. 웹상의 Rich Contents 뿐 아니라, Rich Application에서도 가장 선호하는 개발 플랫폼으로 자리잡았다. 이러한 Flash의 장점은 당연히 스크린을 가지는 모든 임베디드 기기에서도 발휘될 수 있다. 가장 적합한 기기는 당연히 휴대폰이다.

 

가장 먼저 Flash를 휴대폰에서 상용화한 회사는 Macromedia가 아니라 국내의 DigitalAria라는 회사이다. 그래픽스 분야가 좁다보니 내가 근무했던 HUONE의 이환용 이사님을 통해서 아주대학교의 최정주 박사님도 알게되었고, 여러 경로로 DigitalAria도 알게되었다.

 

Flash 기술은 Macromedia를 인수한 Adobe가 원천 기술을 가지고 있으며 기술을 이끌어 가고 있다. Flash Lite라는 임베디드 솔루션 또한 Adobe의 제품으로 휴대폰 상에서도 표준 Flash 솔루션으로 자리잡아 가고 있다.

 

그러나 그래픽스의 급격한 변화와 시장의 요구사항보다 Flash Lite의 기술은 뒤쳐져 있다. 데스크탑의 Flash 10은 가장 앞선 기술이지만, Flash Lite는 버전이 2.5 단계 정도 뒤쳐져 있는 기술이다. Flash 10이 스마트 폰에 적용되기 위해서는 1년 이상의 시간이 필요하다. 이제까지의 Adobe가 계획을 발표하고 시행한 시기의 차이를 보면 1년 반정도 후에야 만나볼 수 있을 것 같다.

 

Flash를 이용한 Rich Application 분야는 Flash Lite를 이용한 표준 개발환경이 중요한 요소가 된다. 그러나 휴대폰의 GUI를 강화하는 분야는 Adobe만을 믿고 기다리기에 1년 반은 너무 긴 시간이다. Flash에서도 iPhone과 같은 GUI를 개발할 수 있는 3D 그래픽스 기능이 필수적이다. C언어를 이용하여 OpenGLES를 직접 이용하거나 3D 솔루션을 이용하는 것이 가능하지만, Flash가 가졌던 장점들을 버리고 다시 C를 이용한 과거 방식의 개발로 돌아가는 것은 우둔한 짓이다.

 

이러한 문제를 해결하는 방법은 Flash기반의 3D 확장이다. 직접 개발하거나 개발된 솔루션을 도입하는 것이다. 개발에 필요한 모든 기술(Flash, ActionScript, OpenGLES, Flash Lite Engine)을 가지고 있어서 이 분야를 개발하고 싶지만 실제 개발에 착수하는 데는 내부적인 이슈들을 해결해야 한다. 순수한 기술 이외에 다른 이슈들이 개입된다는 것은 슬픈일이다.

 

그러나 이러한 개발을 완성한 회사가 있다. 바로 DigitalAria이다. 최초로 Flash를 휴대폰에 도입한 회사답게 ActionScrpt에서 사용할 수 있는 3D API를 제공하는 솔루션을 가지고 있다. DigitalAria의 FXUI가 바로 그것이다.

 

DigitalAria는 ActionScript 코어와 렌더링 코어를 모두 가지고 있다. 이를 바탕으로 하드웨어 가속을 지원하는 렌더링 엔진을 개발하고, ActionScript가 사용할 수 있는 하드웨어 가속을 지원하는 3D API를 제공한다. OpenGLES 2.0에 기반을 두고 있어 다양한 픽셀 효과도 제공된다. Adobe가 1년 반 후에 제공할 기능보다 더 확장된 기능을 FXUI에서는 제공하고 있는 것이다.

(그림출처: DigitalAria)

 

Flash Lite와 FXUI 이외에도 Flash를 기반한 솔루션들은 다양하게 존재한다. NeoMtel, Bluestreak, Scaleform, Acrodea 등의 솔루션들이 있다. Adobe만이 휴대폰에서 Flash를 제공한다면 성장은 지금보다 훨씬 늦을 것이다. Flash 개발자 입장에서는 이들 엔진들 모두가 Flash일 뿐이다. 여기에 Flash 개발자들이 원하는 기능을 확장해주는 FXUI와 같은 제품들이 있다는 것이 즐거울 뿐이다. 경쟁 솔루션들은 Flash가 3D 솔루션들에게 밀려나는 것을 막아주고, Adobe의 개발 방향을 제대로 잡아주고 개발 주기도 단축시켜 줄 것이다.

Flash의 영역을 더 넓혀갈 수 있도록 더 많은 선의의 경쟁이 계속되기를 바란다.