ActionScript

어도비 애니메이트(구 어도비 플래시 프로페셔널)에서 플래시 애니메이션의 컨트롤을 위해 사용하는 스크립트 언어. 어도비에서 인수되기 전 플래시를 개발하던 매크로미디어[1]에서 개발한 언어이다. 원래 플래시에는 2.0부터 '액션'이라 불리는 벡터 애니메이션 제어를 위한 간단한 스크립트 언어가 붙어있었는데 이것이 플래시 5에서부터 '액션스크립트'라는 이름이 붙으며 본격적인 스크립트 언어로 발전, 현행 버전인 액션스크립트 3.0은 독립된 프로그래밍 환경이라고 말해도 무방한 수준까지 발전했다.

특이한 점이라면 스크립트 언어이지만 AVM에서는 자바스크립트의 spidermonkey나 v8 처럼 텍스트 파일 상태로 바로 실행할수 없고 한번 컴파일한 바이트코드를 실행한다.

플래시를 컨트롤할 목적으로 만든 언어다보니 책이나 인터넷 강좌 등에선 Hello, world! 출력부터 하고 시작하는 다른 언어들과는 달리, 애니메이션을 조작하는 play(), stop() 등의 메서드부터 시작하는 것이 특징. 하려면 콘솔 창에 Hello, world!를 뿌릴 수는 있는데 그걸로 첫 코드를 시작하는 사람은 없다(...). 이런 점에서는 Processing과 비슷한 점이 있다.

2000년 9월 플래시 5.0에 처음으로 탑재되었다. 기존에도 '액션'(Actions)라는 이름으로 플래시에 스크립트 환경이 마련되어있었으나 타임라인 컨트롤이나 무비의 호출 등 애니메이션 컨트롤에 한정한 간단한 스크립트에 지나지 않았고 이전 버전인 4.0에서야 본격적인 풀 스크립팅 환경이 완성되었는데, 5.0에서는 이를 확장하는 동시에 문법 등을 새로 정리하여 '액션스크립트'라는 이름으로 발표한 것이다. 문법은 전반적으로 당시 버전의 JavaScript 및 1년전인 1999년에 ECMA-262 표준으로 확정된 ECMAScript 제 3판[2]의 영향을 받고 있어서 자바스크립트를 사용할 줄 안다면 비교적 쉽게 익힐 수 있다.

일단은 절차적 프로그래밍이 가능하며 객체지향요소도 첨가된 언어로 설계되었기는 한데 자바스크립트 및 ECMAScript의 영향을 직접적으로 받고있는 관계로 프로토타입 기반의 OOP를 구현하고 있어서 Java처럼 고전적인 클래스 기반의 OOP에 익숙한 사람이 보면 이게 뭐냐는 소리가 나온다. 게다가 OOP 그런거 몰라도 잘만 쓴다 인터프리터 방식인 자바스크립트와 달리 Java처럼 컴파일 후 바이트코드를 생성하여 AVM(ActionScript Virtual Machine)이라는 가상머신에서 구동하는 형식이다.

안그래도 자바스크립트의 영향을 받은 덕에 언어명세가 까다롭지 않아 입문은 쉬운 편인데, 이게 플래시의 구성요소들과 유기적으로 연동되어있다보니 풀 스크립팅을 할 일은 별로 없고 대체로 오브젝트들에 직접 코드를 심어주는 식으로 코드를 작성하기 때문에 실제로 코드를 작성해 보면 더더욱 쉽다. 디자이너들도 간단한 스크립트를 배워서 인터랙티브한 결과물을 직접 만들어낼 수있는 시대를 연 장본인이라고 하겠다. 언어적 특징 중 하나로 메소드와 프로퍼티를 구분하기 위해 모든 프로퍼티 이름 앞에는 _(언더바)가 들어간다는 게 있는데, 애당초 메소드와 프로퍼티는 호출하는 방법부터가 다르기 때문에 그냥 삽질이다(...).

2003년 9월, 플래시 MX 2004에서 기존의 AS 1.0에 많은 기능개선과 추가기능을 더하면서 판급을 올렸다. 특징적인 차이라면 컴파일 타임에 이루어지는 타입체크, 클래스 기반의 OOP 개념[3]을 도입했다는 점. 기본적인 문법은 ECMAScript 제 3판에 기반하고 있으나 클래스 관련 문법은 Java의 그것과 거의 유사한데, 실은 당시에 새로운 표준안으로 논의되고 있던 ECMAScript 제 4판 초안의 명세를 일부 도입한 것이다. 애초에 이쪽에서 프로토타입 때려치고 클래스 개념을 도입하려는 시도가 있었는데 이걸 그대로 가져온 것. 당시 매크로미디어는 ECMAScript 제 4판의 표준 제정에 꽤 적극적으로 참여하고 있었다고 한다.

바로 이 시기가 액션스크립트, 그리고 플래시의 리즈시절. PHP나 JavaScript와의 연동 등으로 점차 확대되어 플래시가 웹에서의 입지를 굳혀 나가면서 자연스럽게 이 때에 많은 액션스크립트 입문자가 생겼다. 몇몇 영세규모 업체들[4]에서는 아직도 현역인데, 그 이유는 이게 현역이던 시절에 어딘가에서 예제 등으로 나온 스크립트를 퍼오긴 했는데 정작 이걸 고칠 줄은 몰라서.

참고로 AS 2.0으로 코드를 작성하더라도 컴파일하면 AS 1.0의 바이트코드로 컴파일된다. 따라서 가상머신은 AS 1.0과 동일한 AVM1을 그대로 사용하게 된다. 사실 AS 3.0과 AVM2가 나오면서 현격한 성능차이, 보안상 취약점 등으로 인해 조만간에 AVM1과 그 기반언어인 AS 2.0은 버려질 것이라고 예상되었으나 하위호환 때문에 꽤 오래 살아남았다가 2011년 발표된 어도비 플래시 CC에서 기어이 짤렸다.. CC 버전부터는 AS 3.0 기반의 코딩만이 허용되며 여기에 대응되는 플래시 플레이어도 15.0 버전부터 AVM1을 들어내버렸기 때문에 기존의 AS 2.0 기반 SWF 파일이 더이상 작동하지 않게 되었다. 문제는 AS 3.0의 개발 난이도가 2.0과는 비교가 안된다는 것.

2005년 12월, 어도비가 RIA(Rich Internet Application) 시장에 진출하기 위해 당시 플래시로 상한가를 올리고 있던 매크로미디어를 인수하는 대형사건이 벌어진다. 이 과정에서 매크로미디어가 개발하고 있던 새로운 버전의 액션스크립트는 어도비로 넘어가 개발을 완료하게 되는데, 첫 등장은 플래시가 아니라 2006년 6월 발표된 Flex[5] 2.0이었고 플래시에는 이듬해에 나온 플래시 CS3 버전부터 탑재되었다.

Flex는 디자이너가 아닌 프로그래머 계층에게까지 플래시 환경을 제공하기 위한 SDK였다보니 처음엔 큰 반향이 없었으나 플래시 CS3가 나오고 AS 3.0의 언어명세가 플래시 개발자들에게 알려지자 업계의 분위기는 그야말로 혼돈의 카오스였다. 무엇보다 2007년에야 언어명세가 어느정도 틀이 잡힌 ECMAScript 제 4판을 기반으로 문법을 싸그리 갈아엎어버렸는데 2.0처럼 기존 액션스크립트 기반에 ES4의 요소를 약간 첨가한 게 아니라 그냥 ES4의 언어명세를 거의 그대로 들고왔다.[6] 문제는 이 ES4가 기존의 ES3에 비해 대단히 방대하고 언어의 기술 난이도가 높아져있었던데다 기존의 자바스크립트의 문제점[7]을 해결하겠다는 목적으로 너무 많은 부분에 손을 댔다는 것. 여담으로 결국 ES4는 위원회 참가업체들의 의견차가 극심해서 자바스크립트 표준안으로 확정되지 못하고 엎어졌다. 그렇다보니 사실상 ES4 명세를 실제 개발환경으로 구현한 구현체는 AS 3.0이 유일하다시피한데, ES4가 엎어진 이유 중 하나는 기존의 ES3에 비해 너무나 방대하고 어려워졌다는 것이었고 현재도 HTML5와 함께 잘 쓰이고 있는 ES5는 ES4가 아닌 ES3에서 점진적으로 발전시키는 형태가 되었다.[8]

어쨌거나 그렇다보니 기존의 AS 2.0의 쉬운 스크립팅에 익숙해졌던 디자이너들에게는 헬게이트가 열렸다. 기본적인 속성값이나 메서드 등은 같기에 그대로 사용이 되긴 하지만, 버튼 클릭이나 마우스 오버 등 이벤트 처리를 심볼 안에서 해결할 수 없다는 어마어마한 변경점이 생겨버려서 일일이 타임라인 또는 별도의 클래스 파일에 코딩을 해서 연결시켜야 하는데, 여기를 제외한 곳에는 AS를 아예 코딩할 수 없게 해놨다. 익숙하지 않은 사람은 번거로움을 넘어서 현기증이 난다. 결국 디자이너들은 문법은 엄격해졌지, 이벤트 다루는 법도 이해가 안되지, 버튼에 코딩도 안되지, 클래스는 또 뭐며 패키지는 또 뭐냐... 하며 멘탈이 나가는 경험을 하며 3.0을 익혀야했으며 그러다가 빡쳐서 그냥 2.0으로 롤백하는 사람도 꽤 있었다. CS3가 AS 2.0도 하위호환을 위해 지원을 해줬기 때문. [9] 반대로 Java와 같은 기성 프로그래밍 언어와 보다 흡사한 구조를 띄게된데다 기능과 자유도 면에서 현격한 파워업이 있었기 때문에 코딩에 익숙한 사람들 입장에서는 허술하고 (프로그래머의 사고방식으로) 이해하기 힘들었던 2.0보다 합리적이고 쓰기 편해졌기 때문에 환영받았다.

언어내적인 면에서는 새로운 요소가 꽤 많이 도입된 편인데, 클래스는 2.0에서도 사용할 수 있었지만 패키지, 네임스페이스를 사용할 수 있게 되어 코드가 은근히 Java스러워졌다. import라던가 extends라던가 interface라던가 어디서 많이 보던 키워드들이 보인다. 상속도 클래스 기반으로 이루어져서 기존의 프로토타입 기반 상속보다 퍼포먼스가 개선되었다. XML과 정규표현식을 직접 다룰 수 있게 되었고 그 외에도 2.0에서 줄기차게 써 제끼던 _(언더바)가 사라지고 컴파일러는 엄격해졌다. 타입체크는 컴파일 타임/런타임 양쪽에서 이루어지며 변수 선언도 반드시 먼저해야 되게 바뀌었지만, 예외는 있다.('var'를 쓰지 않고 특정 위치에 대입하는 경우) 그놈의 스코프랑 호이스팅은 안바뀌었더라만은

또한 AS 3.0으로 만든 코드는 컴파일하면 AS 1.0/2.0과는 다른 새로운 형태의 바이트코드를 생성하며 AS 3.0의 바이트코드는 새로운 가상머신인 AVM2에서 해석을 하게되는데, AVM2의 바이트코드는 기존의 AS 1.0/2.0의 바이트코드와 호환성이 전혀 없다. 다만 하위호환을 위해 플래시 플레이어는 기존의 AVM1도 내장하고 있었으며 AS 1.0/2.0의 바이트코드는 이쪽에서 담당하게 된다. AVM2는 구조를 새로이 최적화함과 더불어 JIT를 도입했는데 덕분에 퍼포먼스면에서는 AVM1과 비교가 되지 않을 정도로 개선되었다. 당시 플래시가 지탄받던 이유 중 하나가 무거운 동작이었는데 이것은 당시 컴퓨팅 성능도 성능이었지만 AVM1이 구렸던(...) 탓이 매우 컸다. 제대로 코딩만 한다면 AVM2에서는 플래시의 최대 난점이었던 느린 실행이 상당히 개선될 수 있었는데, 어도비 측의 주장으로는 2.0에 비해서 속도가 10배 빠르다고 하며, 실제로 웬만하면 정말 그만한 속도차가 났다. AS 3.0의 정규 표현식 속도는 JavaScript의 1.5배다. 더욱이 단순 계산이라면 AS 2.0의 몇백 배를 넘는다. 이 이유만으로도 AS 3.0으로 옮겨타야할 이유는 충분하긴 해서 눈물을 머금고 AS 3.0을 익히는 사람들도 차차 늘어나고 시장에 안착하...는가 했으나 결과적으로는 이미 알고들 있듯이 모바일 시대의 도래와 HTML5의 보급으로 인해 플래시가 망했다.. 안습. 그래도 아직은 Flex나 AIR도 있고 해서 2.0같이 아주 잊혀진 기술이라고 까지는 하기 어렵겠지만 2008~10년 무렵의 AS 3.0 반짝 열풍은 그야말로 과거의 영광. 한때는 플래시 기반의 애플리케이션 환경이 단순히 웹페이지를 꾸미는 애니메이션 수준을 벗어나 스탠드얼론 애플리케이션 영역까지 확대되는 거 아니냐 하는 기대도 있었지만 남가일몽으로 끝나고 말았다. 어도비가 생각한대로 잘 풀렸으면 Java 같은 크로스플랫폼 가상머신 애플리케이션 환경이 되었을 수도 있었겠지만... ??? : 계획대로 그러한 환경은 HTML5에서 다 이루어지게 되었다.

전술했듯이 플래시 CC부터는 아예 3.0을 쓸 수밖에 없게 되었다. AVM1을 내다버렸기 때문인데 오히려 예상보다 늦게 버렸다는 평가도 많이 있기 때문에 꼭 부적절한 처사였다고 보기는 어렵다. 언젠가는 버려야할 과거의 유산이기는 했기 때문이며 실질적으로 2.0 기반의 개발은 시간의 흐름에 따라서 거의 도태되었기 때문이기도 했다. 지금에 와서야 뭐 어도비가 플래시를 버린자식 취급하면서 3.0도 앞날을 장담할 수 없는 신세기는 하겠지만....

액션스크립트는 주로 플래시 플레이어에서 사용되지만, 플래시 플레이어 뿐만 아니라, 플래시 항목에서 볼 수 있는 플래시 파생 기술들(FLEX, AIR, 플래시 라이트 등)에서도 기능은 조금씩 다르지만 공통적으로 사용된다.