오래 전 중세의 길드 제도에서 19세기 산업혁명 이후의 공장구조까지 사람들은 작업을 효율적으로 하는 방법이 분업이라는 것을 잘 알고 있었습니다. 이러한 시스템은 제조산업에서는 더욱 고도화 되어 일례로 의류업계를 예를 들면 디자인, 제작 정도가 분리는 되는 것이 아닙니다. 실밥만 자르는 회사, 반짝이만 박는 회사, 다림질만 하는 회사 등 참여하는 회사들의 상세한 작업내용은 비의류업계 종사자가 들어보면 깜짝 놀랄 수준으로 상세하게 분업화 되어있습니다.

나름 첨단 산업인 컴터 프로그래밍 분야는 이러한 분업화가 매우 더디게 진행되는 경향이 있습니다. 이점에 대해서는 맨먼스 미신을 비롯하여 다양한 책에서 지적하는 공통된 포인트가 있습니다. 산업을 노동지향적인 분야와 지식지향적인 분야가 있다고 할 때 프로그래밍 분야는 지나치게 지식지향적인 분야라는 것이죠.

즉 학습곡선이 높고 노동력을 쉽게 배가할 수 있는 전통적인 산업에서는 그에 따라 분업에 매우 큰 효율을 가져옵니다. 사과를 따거나 청소를 하는 것은 물론 그것에 대한 학습이 필요 없는 것은 아니지만, 습득하기 위한 시간이 상대적으로 적습니다. 따라서 학습곡선 효과가 발생하여 분업의 효율이 높아집니다.

하지만 개발의 경우 학습곡선이 매우 천천히 상승하기 때문에 인력을 투입하면 낮은 학습상태가 초래하는 비효율로 말미암아 노동력의 추가분 효과가 오히려 마이너스가 되곤 합니다.

플래시업계의 관행과 대처

이러한 비효율성은 최종 개발산출물의 책임을 개발자가 갖게 되는 산업구조상 그 피해가 고스란히 개발자에게 돌아갑니다. 우리 머리 속에 기획자와 디자이너는 퇴근하고 막바지에 개발자가 밤새고 있는 장면이 흔히 떠오르는 이유이기도 합니다.

만약 이 때 개발자에게 개발 외의 일도 시키면 어떻게 될까요?

원래 분업의 효과가 적어 작업시간이 상대적으로 긴데 다른 종류의 업무가 중간중간 끼어들면 그야말로 작업효율은 무한히 낮아지게 됩니다. 이 때쯤 되면 야근을 넘어 주말이 없어지기 시작하기 때문에 본능적으로 개발자들은 개발 외의 뭔가에 대해 극심한 방어태세를 갖추게 됩니다. 야근과 밤셈에 이어 개발자에게 떠오르는 이미지는 ‘안되는데요’ 라는 것이죠.

그래서 기획자와 디자이너의 의도를 개발자는 기본적으로 안된다로 대처하게 됩니다. 하지만 전부 안된다로 대응하는 개발자 맘대로 하면 프로젝트가 성립하지 않으니 이를 중재하는 상위관리자 pm이 존재합니다. 회사 입장에서는 더욱 비싼 연봉의 pm을 투입해야만 하기 때문에 전체 효율성은 거의 제로에 가까워지고 사실 상 에이전시가 얼마에 공사를 수주하든 사기성이 아닌 정상 시장가인 이상 수익을 내기란 매우 힘든 게 현실입니다.

하지만 그래서 개발자의 마인드를 고쳐야 한다는 말을 하는 거냐구요? 아닙니다. 사실은 그 정반대의 이야기를 하고 있습니다.

다른 언어 개발자는 그나마 저렇게 대처를 합니다. 다른 언어라 하면  자바,, 닷넷, php 등의 서버개발 주류언어나 오라클, MSSQL등의 dba 대상의 확장 sql언어를 말합니다. 또한 네이티브 기반의 c++개발자 등도 적극적으로 개발분야 외의 것을 수비합니다.

하지만 이 포스트를 보고 계시는 대부분의 플래시 개발자 여러분은 어떠신가요?

그래픽작업과 기획작업과 개발작업을 병행하고 있지 않은가요?

‘음 그러니까 그 이벤트 한 번 뽀샤시하게 만들어봐~’, ‘테트리스 좀 변형해서 재밌고 이쁜 것 좀 뽑아봐~’ 이런 게 보통 플래시 개발자가 처하는 상황이죠. 이건 머 다른 언어였으면 적어도 3인분이 투입되어 분업해야 할 일입니다.

하지만 현실적으로 플래셔라 불리는 직종군의 사람들은 스샷을 떠서 리소스를 확보하고 포샵질해서 그래픽 자원을 만들고, 게임기획을 하고 사운드 클립을 찾아서 포지로 변형하고 구현하고 테스트한 뒤 서버 개발자와 지랄하면서 업로드에 동작 확인까지 다 합니다.

이게 참 재밌다는 거죠. 사실 다른 분야의 개발자도 이걸 못하는 건 아닙니다. 단지 그렇게 하면 인생이 끝장날 거 같아 적극적으로 심지어 업계 전체 종사자가 한마음으로 거부하는 거죠.

하지만 플래시고용업계가 저걸 한 명에게 다 시키는 게 관례인걸 저라고 어쩔 수 있는 것은 아닙니다.

제가 오늘 드릴 말씀은 단지 저걸 그냥 인정하시고 그 안에서 분업을 추구하라는 것입니다.

플래시 작업의 비효율을 초래하는 가장 큰 이유

그거야 위에 주저리 설명했다시피 여러 가지를 돌려가며 하기 때문입니다. 개발할 때는 개발만, 그래픽 작업할 때는 그래픽 작업만 하면 훨씬 효율이 증대됩니다.

여러 가지 작업 중에서도 가장 비효율적인 부분은 개인적인 경험으로 판단하건 데 UI개발입니다.

UI개발이 비효율적인 이유는 분명히 UI도 코딩이 들어가는 개발이지만 디자인 리소스가 동시에 필요한 작업이기 때문입니다.

따라서 UI개발을 하는 동안 필요한 그래픽자원을 가짜로 만들어 전부 끼워 넣고 나중에 대체한다면 더욱 효율적인 작업이 될 수 있고 이 부분만 개선되어도 크게 작업시간이 줄어듭니다.

그래서 이것과 관련되어 전용클래스를 하나 짜서 운영하시는 걸 강력히 추천합니다.

//리소스 생성기
Resource.ADD( 'button1', 100, 30 ); //이름, 가로, 세로
Resource.ADD( 'button2', 100, 30 );
Resource.ADD( 'backGround', 500, 500 );
Resource.ADD( 'titleBar', 500, 20 );
Resource.ADD( 'menu1', 50, 18 );
Resource.ADD( 'menu2', 50, 18 );

//실제 ui코딩
addChild( new Bitmap( Resource.GET( 'backGround' ) );
addChild( new Bitmap( Resource.GET( 'titleBar' ) );

addChild( new Bitmap( Resource.GET( 'menu1' ) );
getChildAt(numChildren - 1 ).x = 5;
getChildAt(numChildren - 1 ).y = 1;

addChild( new Bitmap( Resource.GET( 'menu2' ) );
getChildAt(numChildren - 1 ).x = 60;
getChildAt(numChildren - 1 ).y = 1;

addChild( new Bitmap( Resource.GET( 'button1' ) );
getChildAt(numChildren - 1 ).x = ( 500 - 100 ) / 2;
getChildAt(numChildren - 1 ).y = 250 - 50;

addChild( new Bitmap( Resource.GET( 'button2' ) );
getChildAt(numChildren - 1 ).x = ( 500 - 100 ) / 2;
getChildAt(numChildren - 1 ).y = 250 + 50;

위의 코드의 결과는 대략 아래와 같은 화면이 될 겁니다.

이러한 작업을 통해 미리 레이아웃을 제작하게 됩니다. 그 이후 실제 디자인 리소스로 대체하는 경우는 아래와 같이 코드가 변경됩니다.

Resource.SET( 'button1', bitmapData1 );
Resource.SET( 'button2', bitmapData2 );
Resource.SET( 'backGround', bitmapData3 );
Resource.SET( 'titleBar', bitmapData4 );
Resource.SET( 'menu1', bitmapData5 );
Resource.SET( 'menu2', bitmapData6 );

그러면 그 밑에 있던 ui코드는 그대로 유지해도 괜찮겠죠. 사실 실제 리소스가 오면 위치가 좀 조정될 텐데 그렇다 하더라도 이로 인해 증대된 효율성에 비하면 아무 것도 아닙니다.

결론

사실 Resource는 제가 귀찮아서 bitmapData생성기처럼 보이게 코드를 짠 것이고 벡터나 무비클립 등 DisplayObject의 자식을 반환하는 식으로 더욱 크게 확장하는 게 편리합니다.

저러한 가짜 리소스 생성기를 갖게 되면 개발을 하는 타이밍에 쭉 코드만 들여다 볼 수 있게 도움을 줍니다. 이러한 효율성 증대는 매우 커서 작업시간을 많게는 절반 정도 줄여줍니다.

애시당초 왜 이렇게나 효율성이 증대될까요? 그것은 사람이 작업을 전환할 때도 컴터와 마찬가지로 컨텍스트 스위칭(context switching) 비용이 발생하기 때문입니다. 이 일을 하다가 저 일을 하면 여러 가지를 다시 떠올리고, 기존의 작업흐름에 돌아오는데 까지 시간이 필요할 뿐 아니라, 속도가 붙기 위해서도 시간이 필요하기 때문입니다.

전체적인 분업시스템 자체가 컨텍스트 스위칭 비용을 줄이는 게 큰 목적 중에 하나 이기도 합니다. 단지 가짜 이미지를 제공하는 라이브러리 외에도 여러분의 개발 시점에서 다른 컨텍스트가 끼어 든다면 그 컨텍스트를 나중에 따로 할 수 있게 도와주는 라이브러리를 작성하시는 게 훨씬 효율적으로 만들어줍니다.

컨텍스트 스위칭 비용을 줄이는 개념은 개발 뿐만 아니라 모든 곳에 적용해 볼만합니다. 예를 들어 포샵에서 그래픽 작업하기 전에 디자이너의 스타일가이드를 받아 등장하는 색상을 팔레트에 다 등록하고 그래픽 노가다가를 한다던가 하는 식입니다.