세계의끝과 플래시 원더랜드

플래시가 처음 등장했을 무렵의 액션스크립트는 자바스크립트 수준의 쉬운 언어였기 때문에 그만큼 장벽이 낮게 느껴져 많은 숫자의 플래시 개발자들이 등장할 수 있었습니다. 네비게이션 바나 롤링 배너와 같은 간단한 작업물 만을 만들던 시절에는 객체지향적인 프로그래밍 방법론은 그닥 중요한 이슈가 아니었습니다. 되려, 플래시가 처음부터 현재 AS3.0 과 같은 형태로 시작했다면 현재 현업에서 일하고 있는 플래시 개발자 중 꽤 많은 숫자가 아마 다른일을 하고 있을 것입니다. 시각적이고 쉬운 접근 방식이 브라우저의 일개 플러그인에 불과한 플래시가 이 정도 수준의 개발자 인구를 가지게 하는 원인이 되기도 했죠.

그러나 사용자들의 웹 애플리케이션에 대한 기대치가 높아지고 플래시로 만들어진 다양한 형태의 애플리케이션이 등장함으로서 보다 높은 차원의 프로그래밍 스킬이 요구되는 경우가 생겼습니다. 객체 재사용(재활용) 은 그런 한 단계 높은 차원의 프로그래밍 스킬 중 하나라고 볼 수 있는데요, 객체를 재사용 하는 방법에 대해 몇 개의 연속 포스팅으로 알아보겠습니다.

제가 이 주제에 대해 포스팅을 하게 된 직접적인 계기가 된 일이 있습니다. 얼마전 액션스크립트 카페에 아래와 같은 질문이 올라왔었습니다.^[01]

(계속 읽기…)

1. http://cafe.naver.com/flashactionscript/53831 [↑]

이 포스트는 “여러분은 플래시로 언제까지 네비게이션 바나 만들고 있을껀가요?” 로부터 이어진 내용입니다. 날코딩을 탈피해 보자는 첫걸음 중 한 발자국인 OOP(Object-Oriented Programming)의 다형성(Polymorphism)에 대해 알아보는 시간입니다.

A. Polymorphism in ActionScript (액션스크립트에서의 다형성)

그럼 액션스크립트에서는 다형성이 어떻게 나타나는 걸까요?
먼저 위키백과 한글판의 OOP 항목에 나타난 다형성에 대한 설명을 인용해 보겠습니다.

다형성이란 같은 메시지에 대해 클래스에 따라 다른 행위를 하게 되는 특징이다. 일반적으로 같은 이름을 가지는 메서드에 대해 인자(Argument)의 개수와 데이터형(Data Type)에 따라 수행되는 행위가 달라짐을 의미한다. 다형성을 통해서 사용자는 약속된 인터페이스를 따르는 서로 다른 객체를 같은 방식으로 사용 할 수 있게 된다.

상당한 숫자의 플래시 개발자들이 해당되겠습니다만, 여러분이 액션스크립트 이전에 다뤄본 객체지향 언어가 없다면 위의 설명만으로는 다형성이 도무지 무엇인지 이해할 수가 없을 것입니다. 특히나 액션스크립트같이 다뤄지는 객체 대부분이 시각적인 표현을 다루는 경우라면, 다형성이라는 개념은 “단지 여러가지 형태를 가지고 있는 그 어떤것” 정도의 피상적인 개념만 느끼게 되는거죠.

(계속 읽기…)

액션스크립트는 클래스라던가, 인스턴스화를 할 수 있다던가, 메서드를 구성하고 호출할 수 있다던가 하는 요소들 덕분에 객체지향 프로그래밍을 할 수 있는 구조적 장치들을 충분히 가지고 있습니다.
AS3.0 이 발표되고 시간이 흘러 현재에 와서는 개발자의 역량이 높아지고 유지보수의 편리성에 대한 열망이 점차 강해짐에 따라, 객체 지향적인 프로그래밍을 하려는 분위기가 조금씩 높아지고는 있습니다만, 실제 필드에 나가보면 정말로 객체지향 스럽게 프로그래밍을 하는 경우는 보기가 드문 편이고, 날코딩으로 프로젝트를 수행하는 경우가 대부분임을 느낄 수 있습니다.

우리나라 경영진들의 개발에 대한 몰이해, 또는 액션스크립트 프로젝트는 프레임웍 이라기 보다는 front-end (사용자단) 쪽의 결과물로 표현되는 경우가 대부분이므로 JAVA 등과 같이 강한 객체지향 개발의 필요성을 느끼지 못하기 때문이기도 하는 이런저런 구조적인 문제점들이 있으나, 정작 가장 결정적인 이유는 액션스크립트 개발자 자신들의 역량 부족에 기인한다고 볼 수 있을 것입니다.
즉, 액션스크립트 개발자들은 대부분 시각적인 것에 대단히 관심이 높은 (개발) 비전공자 출신인 경우가 많기 때문에, 화면만 어떻게 표현만 된다면 내부구조야 어찌되었든 별로 상관 없다는 식의 작업 방식을 취하는 경우가 많습니다. 이런 경우 프로젝트가 약간만 복잡해지거나 클라이언트의 유지보수 요구가 강하다면, 프로젝트 초반에 아무생각 없이 날코딩한 자신을 탓하고 있을 것이 틀림 없습니다.

(계속 읽기…)