소리나는 그림판, 영어단어풍선, 마이크로 안젤로,dav3Dtxt플래시mx 공룡뼈.그림맞추기,뿌요뿌요,손오순뿡뿡,얼굴만들기다이렉트게임

소리나는 그림판, 영어단어풍선, 마이크로 안젤로,dav3Dtxt 플래시mx 공룡뼈.그림맞추기,뿌요뿌요,손오순뿡뿡,얼굴만들기 다이렉트게임
소리나는 그림판, 영어단어풍선, 마이크로 안젤로,dav3Dtxt 다운로드
플래시mx 다운로드
공룡뼈.그림맞추기,뿌요뿌요,손오순뿡뿡,얼굴만들기 다운로드
다이렉트게임.vol1 다운로드
다이렉트게임.vol2 다운로드

 

 

어도비의 리치 인터넷 애플리케이션.

 

처음에는 원래의 목적대로 GIF 애니메이션을 대체할 정도의 웹용 애니메이션 제작 도구로 주로 쓰였으며, 우리나라에서 본격적으로 퍼지기 시작한 것은 2000년대 초반에 졸라맨, 마시마로, 달묘전설, 우비소년, 뿌까 같은 다들 한 번 쯤은 들어봤을 익숙한 플래시 애니메이션들이 유행하기 시작하면서부터다.

사실 주로 쓰이는 곳은 웹 디자인 분야인데, 웹 디자인 관련 및 디지털 디자이너의 개인 사이트를 들어가면 플래시로 만들어진 멋진 영상 및 디지털 앱스트랙트들을 볼 수 있다. 이쪽 분야에서 플래시를 잘 다루는 괴수들은 차고 넘쳤다. 특히 1세대 플래시 개발자로 큰 영향력을 미친 사람인 조슈아 데이비스와 나카무라 유고. MIT 미디어랩의 교수인 존 마에다의 초기 액션스크립트 작품은 MoMA에 전시되기도 했다.

플래시는 원래 GIF를 대신할 애니메이터일 뿐이었으나, 나중에 보조하기 위해 액션 기능(코드)가 생기고, 버전 4까지만 해도 단순한 동영상 재생을 제어할 때나 쓰던 이 액션 기능이 버전 5부터 액션스크립트라는 이름으로 강화되면서 슬슬 프로그래밍 도구의 냄새를 풍기기 시작하더니, 나중에 2.0(AS2.0)이 되고, 좀 더 시간이 흐르자 액션 스크립트 가상머신(AVM)을 완전히 갈아엎어 새로 만들다 시피한 액션스크립트 3.0(AS 3.0)가 나와서 웬만한 프로그래밍 언어 수준의 능력을 갖춘 무서운 도구(툴)가 되어 버렸다. 결국 동영상 재생을 넘어서는 시도가 각 방면으로 이루어졌고, 그 중 하나가 플래시 게임이다.

멀티 플랫폼에 평균 이상은 찍는 성능, JIT, 내장된 그래픽 처리가 상용 그래픽 엔진 급, 바이트 단위의 저수준 조작, 그래픽 가속을 통한 3D 개발, 소켓 서버 등. 이 정도 기능을 내장하여 지원하는 스크립트 언어는 그렇게 많지 않다. 단지 프로그래밍 언어의 냄새를 풍기기 시작하면서 단순히 동영상 재생이나 광고 정도에 쓰기엔 좀 과하다는 게 문제라면 문제.

그리고 보통 프로그램은 뜯어 보지 않는 한 무엇으로 만들어졌는지 알기 어려운데, 플래시도 웹 상에서 재생되는 플래시 플레이어가 아니면 플래시로 만들어졌다는 걸 직접적으로 확인하기 어렵다. 덕분에 관련 업계 종사자가 아닌 한 대부분 동영상이나 광고 정도만을 접하게 되는데, 이 때문에 일반인들의 플래시에 대한 인식은 "플래시? 그거 그냥 동영상 재생이나 하는 거 아냐? 그거에 무슨 의의가 있어?" 수준이다.

스티브 잡스는 세상을 떠날 때까지 플래시를 싫어했다.[1] 초기 어도비는 매킨토시를 밀고 있었고 이때는 양자의 관계가 좋았지만, 마이크로소프트가 Windows 95를 출시한 이후로 조금씩 옮겨가는 모습을 보이면서 애플과 사이가 나빠졌다. 플래시는 원래 어도비 회사 제품이 아니었지만 어도비가 인수하고 나서 부터 애플지원정책에 아예 빠져버려 자연적으로 배척하게 되었다. 결국 사업 비즈니스 마찰로 인한 트러블이라고 보는게 적절하다. 아무튼 iOS는 플래시를 아예 지원하지 않으며, macOS에서는 돌아가기는 하지만 발열이 심해지는 등[2] 최적화가 잘 되어있지 않고 상당히 불안정하다.

페이스북 게임의 대부분은 플래시를 기반으로 하여 만든 것이다.

플래시 버전 간의 하위호환 정책은 전통적으로 두 버전 전까지만 지원했다. 예를 들면 CS6에서는 CS5.5와 CS5 버전의 FLA 파일을 작성할 수 있고 CC2014라면 CC, CS6까지만 지원되는 식. 그래서 두 버전 이상의 구 버전 환경에서 옮겨 작업해야하는 부득이한 경우가 생겼을 때, 예를 들어 CS6에서 작업하다 CS4로 옮겨가야 할때는 CS5 호환으로 저장한 다음 CS5 버전이 있는 컴퓨터를 찾아 다시 CS4 호환으로 저장하는 삽질을 거쳐야 했다. 거기다가 CC부터는 AS 2.0을 지원하지 않으므로, 해당 파일이 AS 2.0으로 작성됐다면 호환되지 않는다. 그런데 사실 어도비가 포토샵과 일러스트레이터를 제외한 다른 시리즈에서는 하위호환을 별로 신경쓰지 않는 편이며 두 버전 씩이나 구 버전을 배려해주는 플래시 쪽이 오히려 구 버전 배려가 많은 편에 속한다. 예를 들어, 인디자인은 하위호환 자체가 안된다.

 

매크로미디어가 시절부터 사용된 AS1.0/2.0과 어도비 인수 이후 만들어진 AS3.0이 존재하는데, 이 둘은 전혀 호환이 안 된다. 심지어 코드의 해석을 위한 가상 머신도 따로 쓴다.[3]

AS3.0이 AS2.0의 단점들을 개선하여 좀 더 객체 지향적인 언어에 가까우며, AIR이나 FLEX같은 RIA에도 대응하기 위해서 여러 가지 언어로서의 체계가 정비되어 크게 바뀌어 있다. AS3.0의 문법은 ECMA 스크립트 제4판에 준하고 있는데 덕분에 현행 자바 스크립트와 문법이 거의 유사하다. 자바 스크립트를 사용하던 기존의 웹개발자들을 끌어들이기 위한 정책이었을 것이라 추정된다. 실제로 CS3 당시에 AS3.0이 처음 나왔을때 AS2.0을 사용해오던 디자이너들은 울상을 짓고 웹프로그래머들은 환영했다는 이야기도 있으니. 상세한 내용은 액션스크립트 항목 참조.

AS3.0이 2.0에 비해 코딩이 어려워진 대신 최소 10배 이상 빠르다는 이유로 차츰차츰 3.0으로 시장환경이 이행되어오고 있었는데 아예 CC부터는 AS 3.0만 지원하게 되었다.

 

안드로이드는 4.1(코드명 젤리빈)부터 지원하지 않으며, 리눅스용 플래시 런타임은 2012년 11.2.X버전을 마지막으로 지원이 끊겼다. 리눅스 유저들은 2017년까지 플래시에 대한 보안 업데이트만을 받을 수 있다. 다만 크롬에 포함되어 있는 플래시 플러그인은 구글을 통해 계속해서 지원되고 있으니 만약 리눅스에서 플래시를 쓰고 싶다면 구형버전, 오픈소스 플래시 플러그인, 크롬. 이 세 가지 중 하나를 골라야 한다. iOS와 Windows Phone은 처음부터 플래시를 지원하지 않았다.

많은 운영 체제를 지원하던 플래시가 단기간에 많은 지원을 끊은 이유는 여러 가지가 있겠지만, 일단 애플이 iOS에 플래시를 지원하지 않겠다고 한 것이 기폭제가 되었다. 당시 iOS는 모바일 기기 시장에서 큰 영향력을 발휘하고 있었고 인터넷으로 풀리는 컨텐츠의 대부분을 차지하는 미국에서의 점유율도 높았다. 게다가 지겹도록 논의된 바이지만, 배터리가 한정된 모바일 기기에서 강력한 컴퓨팅 파워를 내기 위해서는 보통 전용 하드웨어 명령어를 칩에 내장하고 복잡한 명령어나 자주쓰지 않는 명령어는 걷어내는 방법으로 돌파하고 있는데[6] 어도비라는 일개 회사에서 출시하는 제품에 맞추어 칩셋을 제조 설계하는 것은 칩셋 제조업체나 모바일 운영체제를 소유한 업체나 별로 달가운 일은 아니다. 반대로 어도비가 출시되는 칩셋의 하드웨어를 분석하여 이에 최적화해준다는 보장만 있다면 가능할 수 도 있겠으나 어도비는 그런 면에서 발빠르게 지원해주는 회사는 아니었고 삼자 모두 강제력-즉 상대에 대한 예측 가능성을 장담하기 어렵다. 명분을 그럴듯하게 제시 할 수 있겠으나 결국은 시장 주도권과 제품 장악력에 대한 싸움이다.

일단 이러한 이유들로 모바일 시장에서 플래시는 퇴출되기 시작했고, 모바일이 대세가 되면서 인터넷 환경이 빠르게 비플래시 환경으로 넘어갔는데 기업들도 두가지 버전을 만드느니 양쪽에서 사용할 수 있는 플랫폼을 선호하게 되어 입지가 더 줄어들었다. 그런데 사실 더 중요한 사실이 있는데 현재 어도비의 HTML5 저작도구 시장 점유율은 90%에 육박한다. 쉽게 말하면 어도비 입장에서 플래시 시장이 줄어들고 그 대안으로 제시되는 HTML5 시장이 커지는 것은 그저 왼손에 들었던 떡을 오른손으로 옮겨 먹는 것에 불과하다.

 

비트맵도 사용 가능하지만 기본적으로 벡터 그래픽을 사용하며, 동영상(그래픽) 처리 기술이 강점이다.

비교 자료:

• http://themaninblue.com/experiment/AnimationBenchmark/html/

• http://themaninblue.com/experiment/AnimationBenchmark/canvas/

• http://themaninblue.com/experiment/AnimationBenchmark/svg/

• http://themaninblue.com/experiment/AnimationBenchmark/flash/

비교 자료 2:

• http://www.youtube.com/watch?v=nBkLfgDueyw&feature=player_embedded

게임 자료 :

• 3D로 구현한 언리얼 토너먼트 데모

보통 무작정 '플래시는 느리다'라고 알려져 있는데, 적어도 알려진 것처럼 HTML5보다 느리진 않다. 오히려 전체적인 성능을 보자면 C++, C#, JAVA 같은 쟁쟁한 언어들을 데리고 와서 비교해도 적어도 평균 이상은 찍는다. 성능 비교 사이트. 이런 편견은 아마 플래시 게임이 오브젝트가 늘어남에 따라 기하급수적으로 속도가 느려져서 생긴 듯 하다.

원래 플러그인이었던 것의 영향인지, 익스플로러 외의 웹 브라우저와는 그다지 잘 맞지 않으며[10], 윈도우 이외의 운영 체제에 대한 지원도 미흡하다. 특히 리눅스에선 아주 느리고, 자원을 엄청나게 먹기로 유명하다. 플래시에 대한 인식을 나쁘게 만들었던 주원인 중 하나였던 대형 사이트들의 디자인을 빙자한 플래시 광고 도배. 이런 사이트 한번 가면 아주 환장하게 느리다. 이건 예전 자바 떡칠의 경우와도 같은데, 아무리 좋은 것이라도 남용은 금물이다.[11] 아무튼, 그래서 리눅스로 웹 서핑을 하는 사람들 중 어도비나 플래시를 욕 안 해 본 사람을 찾기 힘들다. 가장 큰 문제는 플래시가 어도비에서만 개선을 할 수 있는데 어도비는 이러한 개선에 미흡했다.

그래도 나름대로 플래시도 성능 향상을 위해 노력하는 모습을 보인다. 당장 최근에 나온 플래시 플레이어 11만 봐도 여태까지 안 쓴 그래픽 가속을 기본적으로 지원하여[12] 그래픽적인 부분에서 CPU의 부담이 훨씬 줄어들었다.
플래시 플레이어 11로 구동하는 레이싱 게임

그리고 JIT인 액션스크립트(AS3.0) 정규 표현식의 속도는 JavaScript의 1.5배로 알고리즘만 잘 짜면 폴리곤 몇백만 개는 무리 없이 돌릴 수 있다. 즉 플래시의 문제도 없는 건 아니겠지만, 개발자의 코딩 실력 문제도 비중이 높다고 볼 수 있다.

AS 3.0에 와서 속도와 함께 많은 문제점들이 몰라보게 개선되었지만, 아직도 일부 광고나 자본이 적은 소규모 회사는 AS 2.0을 사용하고 있어 플래시의 인식을 나쁘게 하는 데 한몫하고 있다. 더욱이 플래시가 사용하는 액션스크립트 각 버전(AS 1.0/2.0/3.0)의 차이점을 일반인은 잘 모르기에 인식이 쉽게 개선되진 않을 것으로 보인다.

또, 플래시의 문제점들이 꽤나 과장되게 알려지기도 했는데, 예로 배터리를 많이 먹는다라는 문제는 어디까지나 HTML에 비해서 많이 먹는다는 거지 유니티3D나 자바와 비교하면 딱히 심하진 않다. 아니, 오히려 배터리를 많이 먹는 놈을 뽑자면 분명히 자바다. 그리고 AS1/2/3의 차이를 잘 모르는 일반인들이 AS1/2의 문제점을 AS3의 문제점인양 알리는 바람에 잘못 알려진 문제들도 꽤 된다.

플래시의 그래픽 툴로서의 장점을 뽑자면, 심볼을 통해서 일종의 객체 지향 그래픽을 지원해 만든 애니메이션을 재사용할 수 있으며, 모션 트위닝과 모핑(쉐이프 트위닝)을 지원한다. 다만 모핑은 제어하기 어려워서 이상한 모양으로 나올 때가 많다. 카툰 애니메이션을 만들 떄 주로 쓴다.

플래시의 게임 엔진으로서의 장점을 뽑자면, 무엇보다 자체 그래픽 기능이 있어 다른 그래픽 소프트웨어를 사고 창을 옮겨다닐 필요가 없다는 점을 꼽을 수 있으며, 이로 인해 1인 개발시 편리하다.

 

기본적으로, 플래시는 벡터 그래픽 방식의 프로그램이다. 벡터 그래픽은 비트맵에 비해 용량이 적으나, 별도의 계산이 필요하기에 느리다는 단점을 보유하고 있다. 모니터에 출력을 하려면 결국에는 벡터 도형을 픽셀에 대응시켜야 하기 때문. 별로 무거워 보이지 않는 프로그램도 벡터 그래픽을 쓰면 CPU 점유율이 급격하게 오르는데, 예로 HTML5도 벡터 그래픽을 쓰면 CPU 점유율이 플래시와 비슷하게 나온다.

초창기 웹 환경에서 이러한 플래시의 특징은 엄청난 강점이 되었다. 느리디 느린 웹 환경에서 플래시는 적은 용량으로 아주 효과적인 애니메이션을 표현할 수 있었고, 정적인 개념의 웹 환경을 동적인 개념으로 완전히 바꾸어 내었다. 또 낮은 화질의 동영상도 보통 10MB대의 용량이 필요한 반면, 플래시는 100KB대의 용량으로 애니메이션을 표현할 수 있다. 이러한 특징들 덕분에 초기 웹 환경을 점령할 수 있었던 것이다. 그러나 이런 특징은 용량보다 속도나 CPU 점유율을 생각하는 요즘의 웹 환경에서 오히려 독이 되기도 한다.

원래는 GPU를 통한 하드웨어 가속 없이 CPU만으로 렌더링된다는 단점이 있었지만, 9.0 판급(버전) 이후로 동영상 재생에 한해 하드웨어 가속을 지원하였고 11 이후로는 하드웨어 가속을 완전하게 지원하기 때문에 이 문제는 사라졌다. 또한 인터프리터 방식 특유의 속도도 문제였지만, 플래시 플레이어 9 이상의 AVM2 부터는 저스트인타임 컴파일 방식으로 바뀌어 매우 빨라졌다.

또, 진입 장벽이 낮은 플래시의 특징 탓에 역으로 효율성이 떨어지는, 한 마디로 더럽게 만든 코드가 많다는 점과, 초보 개발자들은 잘 모르는 wmode 등이 있다.

 

플래시는 원래 표준이 아닌 어도비(이전엔 매크로미디어)의 독점 기술이었지만 워낙 널리 사용되고 있었고, HTML5 이전에는 브라우저에서 스크립팅을 통해 화면에 뭔가를 그린다든가 하는 기능에 대한 표준은 사실상 없었던 데다가 그 외의 다른 기능들에 대해서도 표준이 있다 한들 브라우저 전쟁 속에서 각종 상용 비표준 태그가 남발되던 탓에 사실상 표준 취급을 받았다.

그러나 최근엔 HTML이 꾸준히 개선되면서 웹 표준으로서의 입지는 조금씩 위태해지고 있다. 당장 HTML5를 지원하는 웹 브라우저에서 유튜브에 접속하면 플래시를 이용하지 않고도 동영상 재생이 가능하다.

하지만 플래시를 선호하는 사람들은 여전히 많은 편. 무엇보다도 액션스크립트는 비슷한 기능을 지원하는 다른 개발환경에 비하면 플래시는 무지하게 쉽고 개발 속도도 빠르다. [13] 이 낮은 진입장벽 탓에 초보자가 코딩한 스파게티 코드들이 웹상에서 사용자 컴퓨터의 성능과 플래시의 이미지를 같이 갉아먹고 있다는 문제가 있기는 하지만, 적어도 JavaScript처럼 브라우저 특성을 타서 그걸 다 Hack으로 끊어줘야한다던가 하는 문제는 플래시에선 거의 없다. 그리고 조금 무거운 웹 앱이나 게임 같은 것들은 HTML5로 개발하기 어렵다. 코드가 오픈된다는 점과, 파편화된다는 문제점도 있고, 기본적으로 HTML5는 퍼포먼스(속도)가 좋지 않다.

그리고 과거에는 플래시가 HTML5보단 유니티3D와 경쟁하게 될 것이라고 여겼다. 멀티 플랫폼이라는 공통점에(실제로 구현하는 성격은 많이 다르지만), 요즘은 Flash Player가 지원하는 운영 체제가 줄어 Unity Web Player와 비슷한 수준이 되었고, 지원하는 운영 체제도 비슷비슷했기 때문이다.[14] 그러나 둘은 2D와 3D[15], 다목적 언어와 게임용 엔진이라는 차이가 있다.

하지만 현재 플래시는 웹표준에 맞지 않는 구식 기술 취급을 받고 있다. HTML5가 가장 주목을 받고 있는 이유는 플래시를 능가하는 최적화와 표현력이라기 보단, 어떤 기기에서도 작동될 수 있다는 범용성에 대한 개발자들의 로망(?)이 반영된 산물이기 때문이다. 플래시는 웹표준 정립보다는 아티스트들이 디자인이나 감성 표현을 위해 사용하는 목적이 더 크기 때문에 앞으로의 미래를 장담하기가 쉽지 않다.

원래부터 애플, 오페라, 모질라 등의 업체가 모여 HTML 을 기반으로 한 새로운 표준을 준비하고 있었으나, 스티브 잡스의 발언 때문에 문제가 대두되었다. 애플의 플래시 관련 기술(AIR) 배척은, 플래시와 애플 둘 다 좋아하던 사람들이 애플을 욕하게 만들기도 했다. 이전에는 HTML5가 플래시를 완전히 대체할 수 있는 것도 아니고, 플래시의 플러그인이라는 특성상 HTML5에 맞춰서 기능을 추가할 수도 있을 뿐더러, HTML5+JS가 지금의 플래시만큼의 수준이 되면 플래시는 그만큼 더 발전할 수도 있으리라는 기대가 우세했다.# HTML5가 플래시를 완전히 대체할 수 있는것도 아니고 설마 플래시가 단숨에 망하겠어 식의 생각이었다.

하지만 2015년 들어 플래시는 HTML5보다 장래성이 없는 것으로 평가받고 있다. HTML5의 등장과 CSS&JavaScript의 기능 강화, 스마트폰의 대중화 전까지만 해도 플래시는 영원히 갈 것만 같다고 여겨졌던 걸 생각하면 격세지감이 드는 부분이다. 왜 그런가 하면, 우선 플래시에 보다 고급기능을 추가하는 것이 가능하다고 하더라도 실제로는 채용이 될 가망이 없다는게 문제이다. 이를테면 구글 드라이브의 스프레드 시트만큼 빠르고 정교한 데이터 처리를 하는 플래시 제품이나 서비스는 없다는거다. 다른 예를 들자면 아이클라우드 웹버전의 키노트만큼 가볍고 안정적으로 그래픽 처리를 해내는 플래시 제품도 존재하지 않는다. 이외에도 MS나 Zoho를 위시하여 웹 기반 엔터프라이즈급 솔루션을 제공하는 업체들은 전 세계에 헤아리기 힘들 정도로 많지만 주요 업체들 중 플래시를 쓴다는 곳은 단 하나도 없다는 것이 문제인 것이다. 게임 쪽도 중국의 양산형 웹게임을 제외하면 플래시가 아니면 안 될 정도의 규모라면 그냥 모바일로 가던가 유니티3D로 모바일과 웹을 동시에 공략하는 것이 보통. 게다가 최신 버전 플래시 개발을 쫒아가는 개발자는 갈수록 줄어들어도 유니티와 HTML5 개발자는 갈수록 늘어간다는 점에서 인력 수급 면에서도 여러모로 문제가 있다. 이로인해 플래시로 프로그래밍을 하던 사람들은 플래시가 점점 위축된다는 소식에 고생하기만 할 뿐. 안습.

하지만 더 큰 문제는 이하 내용에 있으니....

 

안그래도 거의 운영체제급으로 기능을 많이 제공하면서 그만큼 메모리를 쓰는 플래시는 처음 출시될 때부터 보안 문제가 끊임 없이 제기되어 왔고, 실제로 2000년 이후 바이러스 감염 경로 대부분이 플래시였기 때문에 매크로미디어 시절부터 매해마다 수십번씩 보안 패치나 하던 중 2011년 플래시가 랜섬웨어 감염의 유일한 통로가 된다는 점이 알려지면서 보안에 취약한 애물단지 기술 취급을 받고 있다. 현재 플래시 퇴출이나 사용 금지가 논의될 정도로 심각한 상황. 플래시가 시장에서 배척받고 있는 주된 이유중 가장 큰 이유는 바로 이것.

이런 보안 문제는 사실상 플래시가 미래 지향적인 기술이 될 수 없는 가장 근본적인 이유이다. 업데이트를 통해 보안 취약점 및 오류를 개선해 나가고는 있으나, 현재 시장 추세가 다양한 기능을 포기하더라도, 보다 더 가볍고 다양한 환경에서 같은 서비스를 제공할 수 있는 HTML5로 노선을 갈아타기 시작하였다. 플랫폼별 서비스의 일체성은 오히려 HTML5보다 플래시가 훨씬 더 우위이긴 하나, 갈수록 각종 플랫폼들에서 퇴출되고 있다는 문제가 있다.

이제는 어도비조차 애니메이트으로 개명하고, 플래시보다는 HTML5을 메인으로 지원할 계획이라고 공지를 했다. 어도비사 공지 여담으로, CC 버전부터는 플래시에서 HTML5 코드 기반 작업물을 직접 생성할 수 있다.

현재 랜섬웨어 감염의 유일한 경로이며, 어도비에서조차 보안 문제로 플래시 즉시 사용 중단을 권고했다. 불안하다고 하면 어도비 플래시 플레이어 11.2 이후 버전에서는 자동 업데이트를 제공하고 있으며 매일 1시간 단위로 업데이트 검사를 하고 있다 물론 해당 자동 업데이트 주기도 변경을 할수가 있다.#

 

2010년대 들어서 플래시를 배척하는 분위기가 고조되었다. 최근 버전으로 올수록 플짤 제조기에서 점점 거리가 멀어져 가고 있다.

• 스마트폰과 모바일 데이터 사용이 증가함으로 인해 성능 관리, 저전력, 데이터 사용량 절감이 필요한 모바일 환경에 대한 지원이 거의 없었던 플래시 이용을 자제하기 시작했다.

• 인터넷 익스플로러 이외의 브라우저 사용이 늘면서, 비표준이면서 IE 외에는 최적화 되지도 않은 플래시 플러그인 사용을 꺼리게 되었다.

• 플래시 보안 취약점을 악용한 해킹 때문에 플래시를 금기시 해야만 하는 상황이 왔다.

결국 어도비에서 Flash에 대한 지원을 2020년에 종료하기로 했다. 기사 그리고 플래시 개발 환경인 어도비 애니메이트를 플래시 개발 환경보다는 애니메이션 제작에 중점을 둔 소프트웨어로 전환시켰다.

인터넷 브라우저들은 플래시 플레이어를 기본적으로 비활성화 상태로 두고, 필요한 웹 사이트에 한해서 활성화할 수 있도록 기본값을 변경했다. 구글 크롬의 경우 버전 69에서는 활성화를 하더라도 브라우저를 끄면 기본값인 비활성화 상태로 되돌아가도록 업데이트되었으며, 버전 76에서는 기본값이 '우선 묻기'에서 '차단'으로 바뀌었다. 2020년 12월 정식 출시 예정인 버전 87에서 플래시가 완전히 삭제될 예정이다.

Microsoft Windows 역시 지원 중단에 맞춰서 플래시를 삭제할 예정이다. 지원 중단 시점인 2020년 12월 중에 Windows 8.1 이상의 모든 윈도우에 플래시를 삭제하는 업데이트가 배포될 것으로 예상된다. 업데이트로 구성요소를 삭제한다는 것이 생소하게 느껴질 수도 있지만, 마이크로소프트는 2016년에 보안 취약점이 발견된 Windows 필기장을 삭제하는 업데이트를 배포한 전적이 있다.

이러한 이유 때문에 오늘날의 웹 트랜드는 플래시가 조금씩 사라져 가는 추세로 가고 있다. 스마트폰이 대중화되기 전까지만 해도 웹에서 플래시를 심심찮게 볼 수 있었음을 생각하면 그야말로 격세지감. 동영상은 플짤을 직접 만들어서 올리는 대신 유튜브를 링크하는 것이 대세가 되었고, 각종 유머 사이트에서는 아예 BGM을 넣지 않는 쪽으로 추세가 바뀌었다.

다만 실시간 스트리밍 쪽에선 끈질기게 주류 중 하나로 남아서 골치를 아프게 하는데 RTMP 프로토콜이 플래시 기반이라서 일어나는 일이다. RTMP에서 탈피하면 되는 일이겠지만 현재까지 OBS Studio 같은 무료 개인용 방송 프로그램들이 실질적으로 RTMP만 쓸만하게 지원하고 있어서 문제다. Nginx에서 hls 변환 송출하는 편법이 있긴 한데 지연이 너무 심해져서 보조용으로나 쓰인다. 유튜브, 트위치 등의 대형 스트리밍 서비스에선 RTMP로 전송된 스트림을 서버에서 HTML5로 변환 송출해 해결하는 경우가 많아졌지만 개인이 직접 서버를 구축해 소규모 방송을 할 때는 HLS의 지연문제와 겹쳐서 여전히 골칫거리다. OBS 같은 프로그램 개발진들에게 HTML5 지원을 요청하는 글도 많으나 개발진의 역량 부족인지 대안이 나오지 않는 상황. 이외에도 한국에서 인기있는 플랫폼인 아프리카TV 역시 플래시 기반으로 되어 있다.

국내 지도의 스트리트뷰 서비스도 웹은 플래시 기반으로 되어 있었다. 네이버 지도는 새 지도 베타 버전에서 플래시를 제거했고 다음 지도도 카카오맵으로 통합되면서 제거되었다.

네이버 블로그와 네이버 카페에 사용되는 BGM 플레이어도 플래시 기반이다. 그래서 네이버 블로그만 접속하면 플래시가 차단되었다는 경고가 뜨며, BGM 플레이어가 설정된 블로그에서는 Adobe Flash Player를 활성화하라는 문구까지 나타난다. 이런 음악이나 동영상 플레이어들은 저작권 문제로 DRM사용이 필요해 DRM을 제공하는 플래시 플러그인을 사용하는 경우도 있다.

네이버 가계부 역시 플래시 기반이다. 이쪽은 PC나 모바일이나 오류수정이나 점검 외에는 사실상 손 놓은 수준이라서 모바일앱도 과거의 디자인을 그대로 유지중이다.

과거 루리웹에는 플래시 아바타라는 기능이 있었다. 프로필 사진이 표시되는 자리에 플짤을 집어넣는 기능이었는데, 주로 동영상을 별도의 서버에서 따로 불러오게 한 뒤 마우스 포인터를 올리면 소리가 나오게 하는 식으로 많이 활용했다. 루리웹이 다음에서 서비스하던 시절까지는 이게 가능했는데, 2016년 7월 1일에 독립개편하면서 플래시 아바타를 새로 등록할 수 없게 바뀌었다. 그나마 기존에 등록해둔 아바타는 계속 볼 수 있었지만, 2019년 11월 이후로 기존에 등록한 플래시 아바타까지 전부 삭제처리되어서 기본 루리웹 로고로 대체되었다.

 

 

친척뻘이라고 볼 수 있는 기술들로 그 중 플래시 라이트와 AIR, FLEX는 분야에 따라 기능이 조금씩 다르지만, 공통적으로 액션스크립트를 사용하고 있다.

 

플래시에서 사용되는 액션스크립트에 MXML이라는 마크업을 더하고 이걸 .net이나 J2EE같은 서버사이드 언어와 통합해서 아예 디자이너 없이 개발자가 개발해서 넷상에서 작동하는 애플리케이션을 만들도록 만든 물건으로, 주로 엔터프라이즈급 인트라넷 등에 사용하고 있으며 일반 유저가 이것으로 만든 물건을 접할 기회는 흔치는 않다. 사실 애시당초 플렉스로 만든 프로젝트도 결과물은 동일한 .swf파일이라 일반인이 구별하기가 쉽지 않다. 굳이 구별하는 방법은 처음 구동시에 플렉스에서 고정적으로 이용하는 로딩바가 나오나 안 나오나의 여부.

FLEX 애플리케이션은 일반적으로는 플래시와 함께 설치되는 전용 IDE인 '플래시 빌더'를 이용해서 개발하지만 별도로 무료배포[16] 하고 있는 FLEX SDK를 이용하면 이클립스나 Flash Develop 같은 IDE를 가지고 FLEX 코딩이 가능하다. 즉, FLEX를 이용하면 비싼 플래시를 사지 않아도 합법적으로 돈 한푼 안들이고 플래시 개발환경을 구축할수 있다는 어마어마한 장점이 있다.

 

플래시 플레이어로 웹 브라우저나 플래시 플레이어에서 돌아가는 것이 아닌, 아예 별도로 실행되는 응용 프로그램을 제작하는 기술로, 이것으로 만든 프로그램을 작동시키기 위해서는 어도비에서 AIR 런타임이 있어야 하는데, 보통 프로그램 설치 시 자동으로 설치된다.

웹상에서 보안 등의 여러 가지 이유로 불가능한 명령어들을 사용 가능하며, 그와 관련된 일부 기능들이 추가되어 있고, 속도도 플래시 플레이어보다 더 빠르다. 간단한 게임부터 앱 등, 여러 곳에 쓰인다.

런타임은 윈도우용과 맥OS용으로 나오며, 원래는 리눅스용도 있었지만 2.6을 마지막으로 중단. 그 외에 플래시로 만든 결과물을 안드로이드의 응용 프로그램으로 돌릴 수 있는 AIR for Android가 있으며, 블랙베리의 타블렛PC인 플레이북은 대인배스럽게도 아예 이 런타임을 OS 안에 내장하여 별도 플러그인 설치 없이도 AIR for Android용으로 만들어진 APK파일은 바로 설치해서 돌릴 수 있다.

CS5.5에 와서는 iOS용인 AIR for iOS도 추가. 이걸로 플래시 개발자들은 소스 하나를 윈도우, 맥OS, iOS, 블랙베리. 이 모든 것에 사용할 수 있게 되었다. 또한 플래시가 원래 웹 플러그인이었던 만큼 플래시 개발자 중 웹프로그래머 출신이 많은데, 거기에 AIR이 더해지면서 앱/프로그램 개발과 웹 개발을 다 할 수 있는 만능 개발자가 나오게 된다!

iOS의 경우 In-App Purchase가 지원되지 않는 등의 문제가 있었는데, 애플의 수익을 침해하는 것이라 규정 위반이라면서 막아 버렸기 때문. 하지만 Native Extension[17]이 추가되면서 문제 해결.

플래시 AIR로 만들어진 것들 중 잘 알려진 유명한 것으로는 애니팡이 있다.

 

 

Flash Lite. 이름 그대로 가볍게 만든 플래시. NTT 도코모에서 "우리 무선인터넷에서 플래시 좀 돌려보게 한번 좀 만들어주세요" 해서 만든 물건이 시초이다. 주로 모바일이나 셋톱박스, TV같이 PC용 플래시를 쌩으로 돌리기에는 CPU등의 퍼포먼스가 좋지 않은 기기에 들어가며, 국내에 출시되는 피처폰이나 MP3 플레이어, 전자사전 등의 구형 휴대용 전자기기들은 이것으로 만든 인터페이스를 채용한 경우가 많다.

EV-W100은 플래시 라이트 기반 swf파일을 실행할 수 있다.

 

 

플래시를 기반으로 한 게임 UI 미들웨어. 2000년대 후반부터 나오는 상당수의 게임 UI가 이걸 이용해서 만들어진다. 플래시 게임이 아닌데도 게임에 플래시를 사용한다거나 하는 말이 나오면 100% 이걸 가리킨다고 보면 된다.
게임 UI를 만들때 이걸 이용하면 자체적인 툴을 만들지 않아도 되고, 플래시의 특성상 상당히 화려하고 정교한 효과를 줄 수 있다. 벡터 방식의 그래픽 사용이 가능하기에 게임 해상도에 구애받지 않고 UI 확대/축소를 마음대로 할 수 있고, UI 동작은 스케일폼에 맞게 일부 커스터마이징한 액션스크립트를 이용하기 때문에 게임 제작에 들이는 시간과 수고를 줄일 수 있다. 이 때문에 많이 선호되고 있고, 특히 언리얼 엔진 3에는 기본적으로 제공된다.

2011년 2월 오토데스크가 스케일폼을 인수했다.

 

과거 매크로미디어 시절에 플래시에서는 감당하지 못하는 서버사이드 스크립트를 구동하기 위한 기술로 만들어진 언어지만, 개발자 수가 적은 데다가 이걸 사용하기 위해서는 콜드퓨전 서버 데몬을 별도로 돈 주고 사야한다는 이유로 국내에서는 처절하게 망했다. 개발 속도가 빠르다는 장점이 있어서 해외에서는 아직도 제법 사용하고 있다는 듯하다.