플래시로 개발하기 시작하면서 이태까지 경험하면서

실제로 책이나 블로그에서는 잘 가르쳐주지 않는 사실들을 가끔 깨달을 때가 있다.

그중에서도 내가 가장 크게 깨달았고

플래시 프로그래밍을 공부하는 분들께 도움이 되었으면 하는 바람에서

몇 가지 숨겨져있는 사실들을 이야기해보겠다.



1. 클래스는 대부분 재사용되지 않는다.

OOP가 플래시에서도 뜨거운 감자로써

기본 소양처럼 널리 공부되고 있다.

OOP의 원칙은 두 가지.

바로 재사용성과 확장성.

하지만 실제로 플래시 개발이 고도화되고 복잡해질수록

클래스가 재사용되는 일은 매우 드물다.

오히려 프레임웍으로 만들어 프레임웍 자체가 재사용되면 되었을까

프로젝트에서 만들어진 클래스의 대부분(특히 UI관련)을 재사용되지 않는다.

클래스를 만들때는 각종 OOP기법과 디자인 패턴을 적용하여

최대한 재사용되고 확장될 수 있도록 만들려고 애를 쓴다.

하지만 정작 새로운 프로젝트와 새로운 모듈을 만들때는

그 프로젝트만의 특성이 있기 때문에 결국 새로운 클래스를 만들게 된다.

재사용되는 클래스는 완전 프로젝트와 분리될 수 있는 각종로더나 문자열 관련 유틸, 숫자 연산같은

유틸성이 대부분이다.

프로젝트를 진행하면서 앞으로도 재사용될 수 있는 클래스를 바로 바로 만든다는 것은

경력 8, 9년차정도 되어야 가능한 일이라고 본다.

프로젝트를 진행하면서 클래스를 재사용하려고 너무 시간을 허비하는 것 보다

일단 어떻게든 돌아가게 개발하고 그것을 리팩토링하는게 5배이상 프로그래밍 실력 향상에 도움이 되리라 믿는다.

Do First, then Fix After.

먼저 어떻게든 돌아가는 프로그램을 짜고

마음에 안들거나 바꿔야하는 부분이 생기면 그때 바꾸는게 훨씬 효율적이며

결과적으로도 더 깔끔한 컴퍼넌트가 나오는 걸 경험할 수 있다.



2. 디자인 패턴은 약보다 독이 될 경우가 훨씬 더 많다.

미친 소리로 들릴 수도 있겠지만

디자인 패턴은 실제로 경력 4, 5년차 미만의 플래시 개발자의 경우

득보다 독이 되는 경우가 훨씬 많다.

디자인 패턴은 어떤 패턴 한 두개가 핵심이 되는게 아니라

아키텍쳐의 한 부분을 가지를 쳐내다보면 디자인 패턴으로 보이는것이지

디자인 패턴이 모여서 아키텍쳐가 되는게 절대 아니다.

디자인 패턴이라는 개념 자체가

굉장히 많은 프로그래밍 경험을 토대로

이런 이런 상황에서는 이런 이런 식으로 해서 쓰니까 좋"더라"라는

경험의 축적으로부터 나온 것이기 때문에

그 경험이 충분치 않은 개발자들에게 디자인 패턴은

초등학생에게 철학을 가르치는 것과 마찬가지다.

디자인 패턴을 공부하고나서 중독증상으로

자기 앞의 모든 코드를 모두 패턴이라는 이름하에서 코딩하려고 하는 디자인 패턴 초입자들은

대부분 자기가 원래 개발할 수 있는 시간보다

세배 네배, 심지어는 아예 개발을 못하고 멈춰버리는 수가 많다.

프로그래밍은 코드 자체가 의미있는게 아니다.

프로그래밍은 만들고자하는 것을 쉽게 만들어주는 도구이지

코드를 얼마나 이쁘게 짜는지가 프로그래밍이 아니라는 뜻이다.

까짓거 한글 변수면 어떻고, 4중 for문이면 뭐 어떻나...

for 문 좀 많이 썼다고 프로젝트가 망하는거 아니다.

디자인 패턴은 무의식중에 코드를 무지막지하게 써내려가다가

손끝에서 알아서 나올때 그게 유용한 디자인 패턴인 것이다.

이 모든 사설을 다 빼고 이렇게 한 문장으로 말할 수 있을것이다.

"디자인 패턴은 공부하지 않아도 경력이 쌓이면 알아서 익혀지게되는 것들이다."



3. Flash는 느리지 않다.

HTML5가 이끈 퍼포먼스에 대한 Flash 이슈들에 대해서 많이들 들어봤을 것이다.

"Flash is sucks"라는 말까지 듣는 상황이다.

플래시가 느리다는 대부분의 이유는 바로

대부분의 플래시는 Display 관련 처리가 많고

거기다가 엉망으로 짠 플래시들은 대부분 이미지를 대량으로 최적화 없이 싣고 있기 때문이다.

사실 enterFrame이나 single-thread 여서 느린것도 있다.

하지만 "대부분"의 경우에는 이미지를 무지막지하게 쓰거나 벡터나 동영상들을

최적화 없이 마구 돌리기 때문이다.

실제로 Flash는 virtual machine 위에서 돌아가기 때문에

기본 연산이나 반복문, 바이너리 처리는 굉장히 빠른편이다.

물론 C나 Java에 비할바는 아니겠지만

적어도 Flash is Sucks라는 말을 들을 정도까진 아니다.

HTML이나 Javascript는 아예 비교할 가치도 없을 뿐더러 ShockWave나 Unity(3D기능 빼고 ㅋ)에 비해서

결코 뒤지는 퍼포먼스가 아니라는 이야기다.

int 대신 Number를 쓰면 메모리 많이 먹는다고 걱정하거나

클래스가 너무 많아서 고민이라거나

이미 로드된 swf를 사용하지 않으면 어떻게 unload 해야할지 발을 동동구르거나

하는 걱정들은 솔직히 프로젝트에 아무 영향 없을 때가 훨씬 많다. (사실 대부분이다.)

for 문이나 메모리 때문에 플래시 개발이 막히는 경우는 거의 없다.

게임이나 모바일, 미디어 관련 프로젝트에는 중요하겠지만

게임도 대부분의 미니게임에서는 메모리나 for 문 한두개, 클래스 1, 200개 정도로 문제가 되진 않는다.

Flash는 여러분의 생각보다 충분히 빠르며

이 역시도 마찬가지로 일단

Do First, then Fix After, 일단 만들어보고 문제가 된다면 그때 고쳐도 충분하다.



4. Frame Script는 의외로 좋다.

ActionScript 3.0이 나오고 나서

Frame Script가 죄악시되는데

Frame Script는 fla안에 코드가 있어서

UI와 개발이 분리되는 개발환경일 때 코드가 일원화 되어 있지 않다는 문제가 있을 뿐이지

Frame Script가 느리거나 절대 쓰면 안되는 그런 죄악은 아니다.

프로그래밍이라는 의미자체가

반복작업을 줄여주고 인간의 사고를 최대한 효율적으로 기계어로 풀어내는 것일진데

UI에 붙어있는 짧은 코드 한줄은

클래스 수십개를 능가하는 효율을 발휘할 때가 있다.

가령 예를 들자면

마지막 프레임에 넣어놓은 stop() 구문을 굳이 따로 개발한다면

어떻게 개발할건가?

솔직히 난 Frame Script를 쓰지 않고는 잘 방법이 떠오르지 않는다.

this.addFrameScript( stop, this.totalFrames - 1 ); 이거 말고는 생각이 나지 않는다.

적절히, 다른 클래스들에게 영향을 끼치지 않는 한에서는

Frame Script는 개발 편의성 측면에서 한 점의 화룡정점이 될 수 있다는 것을 잊지 않았으면 한다.



5. Event 구조는 매우 안좋은 기능이다.

특히 Display List에서 Dispatch - Listen 구조는

정말 최악중에 최악이다.

Event의 장점은 단 하나다.

SRP - Single Responsibility Principle

바로 클래스를 캡슐화하는데 있어서 내부의 상황을 바깥으로 알리는데 드러내지 않고 구현할 수 있기 때문이다.

하지만 Display List에서의 이벤트는 너무 느리다.

특히 child 구조가 복잡해질수록 event의 전달과정은 느리기 짝이 없다.

그중에서도 가장 나쁜 이벤트 방식은

내부에서 이벤트를 받아다가 다른 이벤트를 새로 작성해서 바깥으로 보내는 경우다.

btn.addEventListener( "click", clickListener );

function clickListener( $e: MouseEvent ): void
{
    this.dispatchEvent( new Event( "merong" ) );
}

Display List에서 마우스 이벤트는 전달되는 과정이 생각보다 매우 복잡해서

메모리 뿐만 아니라 속도도 매우 느리다.

이는 작은 프로젝트에선 모르다가 이벤트를 맹신하고 마음놓고 쓰기 시작하면서부터 경험할 수 있는데

이를 경험하고 나서 부터는 반드시 필요한 때가 아니면

주로 callback 방식으로 바꿔서 쓰고 있다.

Event는 클래스를 캡슐화하는데 있어서 탁월한 기능이 있지만

Display List 구조에서는 생각보다 굉장히 느리다는 단점이 있다는 것을 반드시 기억해야한다.



블로그에 포스팅하면서 처음쓰는 네거티브한 내용의 글인것 같은데

그만큼 너무 부풀어 있는 거품을 좀 걷어내어야 할 필요성을 느꼈고

실제로 크고 작은 개발을 해보면서 느낀 바를 옮겨적어보았다.

옳다 그렇다의 이분법적인 이야기를 하려하기보다는

책이나 포스팅에서 너무 이론적인 접근만 하는

공부보다 실제 개발을 할 때 도움이 되었으면 하는 이야기들이라고 생각했다.

혹시 다른 생각을 가진 분이 계시면 꼭 댓글을 달아주었으면 한다.

:D
저작자 표시 비영리 동일 조건 변경 허락
신고
  1. Favicon of http://leejimyung.com desty 2011.04.19 07:51 신고

    경험에서 나온 귀한 정보 !

  2. Favicon of http://nicekon.tistory.com 닥서클(권오남) 2011.04.19 13:35 신고

    공감가는 부분이 많네요 :)

  3. gohee 2011.04.20 13:35 신고

    상콤, 쫄깃함이 몰려오네요.

  4. Favicon of http://balcode.tistory.com BALCODE 2011.04.20 21:50 신고

    뉴 이벤트 메롱에서 감동 :D

  5. alex 2011.04.21 11:54 신고

    좋은글 감사합니다. 실무에서 느꼈던 것들인데 이렇게 글로 잘 정리되다니 놀랐어요~~

  6. Favicon of http://codeonwort.tistory.com 늣풀 2011.04.21 12:09 신고

    특히 2번-디자인패턴과 4번-프레임스크립트가 공감이 갑니다. 헤드 퍼스트 디자인 패턴을 보고 처음에 느낀 게 '이걸 굳이 배워야 하는 건가? 코딩하다 보면 걍 이렇게 만들게 되지 않나?' 였거든요. 프레임스크립트를 안 쓰면 enterFrame 수신자에서 프레임 레이블을 체크하는 식으로 코딩하게 되어 쓸데 없이 복잡해지곤 했습니다.

    • Favicon of http://wooyaggo.tistory.com 우야꼬  2011.04.25 23:23 신고

      스스로 느끼다니 대단하네요.
      유난히 플래시쪽에는 패턴 중독이 많이 보이는거 같아서 안타까워요.

    • Favicon of http://codeonwort.tistory.com codeonwort 2011.04.26 00:44 신고

      갠적으로 "이걸 설계할 때는 이런 디자인 패턴을 써볼까?" 가 아니라 "이걸 편하고 쉽게 쓰려면 이렇게 설계하고.. 여기서 이런 패턴과 저런 패턴이 보이는 군" 이라고 생각하는 게 옳다고 생각합니다.

  7. 찰카닥 2011.04.21 14:43 신고

    오우!! 좋은내용 1 , 2 번 다 나에게 와닿는다는 일단 클라이언트와의 시간도 중요한듯 결과물을 보여줘야되니 오히려 패턴 oop생각에 빠지다가 사용하지않는 클래스만 많아져서 다시 단순하게 가게 됬다는 ㅜㅜ 공부합시다!!

    • Favicon of http://wooyaggo.tistory.com 우야꼬  2011.04.25 23:24 신고

      공부하자!! 할게 너무 많아 ㅠㅠ
      시간이 없어서 하나둘씩 놓아버려야될게 많아지고 있어 ㅠ.ㅠ

  8. 마카오슈 2011.04.21 23:46 신고

    2번내용에 좋아요 1표~

  9. Favicon of http://blog.flashplatform.kr 검쉰 2011.04.23 10:02 신고

    항상 케바케가 존재하는 듯.
    만들고 나서 고치라는 건 대공감.

    • Favicon of http://wooyaggo.tistory.com 우야꼬  2011.04.25 23:25 신고

      응~ 만들기전에 완벽하게 구상해서 쨔잔~하고 만들면 좋겠지만
      대부분은 일단 만들고 나서 고치는게 현실적이더라 ㅎㅎ

  10. 야훔 2011.04.25 21:20 신고

    생각할 수록 공감이 많이 가는 글이네요 ㅎ
    디자인패턴은 많은 경험으로 인해 몸에 새겨지지 않으면 효과적으로 쓰기 어렵죠

  11. mistmini 2011.05.02 14:49 신고

    ㅎㅎ 그린취업반에서 타고 왔어요...ㅋㅋ
    좋은 글 보고가네요 ㅋㅋ
    전 1,4번에 한표 ㅋㅋㅋ..

    정말 직접 실무하시면서 느끼신 거라 ㅎㅎ 참 현실적이고 좋네요 ㅋㅋ 공감공감~ㅎ

  12. OneLove 2011.05.09 12:04 신고

    늘 쓰는 패턴은 어딜 가나 쓰는 경향이 있지 않나요?
    여기서 말하는 패턴이 Gof 패턴만 말하는건 아닙니다.
    객체들의 생성, 관리, 상태 등은 프로젝트가 변화해도 늘 해줘야 하는 것 아닌가요 ㅡ_ㅡ;;

    • Favicon of http://wooyaggo.tistory.com 우야꼬  2011.05.09 14:47 신고

      늘 쓰던 패턴이면 자주 써야죠.
      하지만 패턴 초입자가 패턴을 쓰기위해 주객이 전도되는 경우를 경계해야한다는 생각입니다.
      그리고 특정한 패턴도 때와 상황에 따라서 쓰지 않고 흔히 말하는 막코딩으로 먼저 짜고
      나중에 시간이 될 때 리팩토링으로 패턴화시키는 것도 꼭 고려했음 좋겠다는게 제 생각입니다^^

    • OneLove 2011.05.09 17:08 신고

      리팩토링 하실때 간단한 팁이 있을까요 ^_^
      꼭 리팩토링 한다고 하면 전역변수 지역변수로 손보고
      애매모한 메소드 이름, 클래스 이름등 만 손이 가고
      나머지는 뭘 어떻게 눠야 할지 막막할때가 많습니다.

    • Favicon of http://wooyaggo.tistory.com 우야꼬  2011.05.09 22:07 신고

      저는 리팩토링의 시작은 메소드 쪼개기부터라고 생각합니다.

      SoC(Seperation of Concern) 관심을 분리시켜 하나의 클래스는 하나의 역할만 담당한다는 객체 지향 방법을
      메소드에도 적용하는게 좋다고 생각합니다.
      한 메소드는 하나의 로직을 담당하도록 쪼개다보면
      비슷한 역할끼리 뭉치는 경향이 보이게 됩니다.

      그렇게 되면 클래스를 빼게 되고
      멤버변수와 상관없이 도는 메소스들끼리는 유틸 클래스로 뺀다거나

      클래스들끼리의 관계를 관장을 하는 메소드들끼리는
      매니저 클래스로 뺀다거나

      객체의 생성과 제거를 타이트하게 해야되겠다 싶으면
      팩토리패턴을 하나 새로짜서 바꿔치기하고...

      저는 이런 절차의 가장 첫 걸음을 메소드 분리에서부터 시작합니다.
      혹시 도움이 되셨으면 좋겠네요^^

  13. 난최장군 2011.05.11 15:22 신고

    좋은글 감사합니다^^
    전체적으로 많은 부분에서 공감이 갑니다. 특히 stopㅋㅋ
    저역시 수많은 리팩토링을 하다 보니 자연스레 패턴을 익히고 패턴 책을 보면서
    자연스레 리팩토링에 적용하다 보니 지금은 코드짜기 전에 그림만 수십장 그려 봅니다 ㅎㅎ
    이벤트 구조의 경우 공감이 가기도 하고.. 애매 하기도 하고.. 경험이 적다보니 이벤트로 인한 속도문제는
    크게 겪어 본 적이 없는 부분이었는데 많은 도움이 됬습니다^^ 1페이지부터 정주행 중인데 332까지 얼른 읽어야 겠네요^^

  14. 액션푸우 2011.07.22 09:45 신고

    와우~~!! 공감도 가고 좋은 글이네요. 디자인 패턴을 공부해야하는 개발자로써 어떻게 보면 닭이 먼저인지 달걀이 먼저인지 생각이 들기도 했었거든요. 그리고 클래스의 재사용성~~!! 작업을 하면서 실제로 가져다가 다시 수정해서 쓰고 있는 그대로 쓰는 경우가 드물게 느껴져서 내가 잘못 만들고 있는건가 하는 생각도 들었습니다. 이 글을 보니 제가 잘못된 방향으로 하는 건 아니라고 느꼈습니다..~~!!

+ Recent posts