이걸 뜯어 고치느니 새로 만들고 말지...

1. 절망의 구렁텅이

(첫 출근을 해서 소스 코드를 열어보는 순간...)

"이걸 뜯어 고치느니 새로 만들고 말지..."

개발을 하다보면 참으로 자주 내뱉거나 듣게되는 소리입니다.

스케일폼 작업을 하다보면서도 당연히 접하게 되는 말입니다.

그것도 다른 분야에서 일할 때보다 매우 자주 말입니다 :^)

작업을 하라고 받은 파일의 MovieClip 속의 MovieClip 속의 MovieClip 속에 (여기서부터 무한반복) 들어갔을 때 as 코드를 발견하기라도 하면 절로 욕이 튀어나오기도 하죠

2. 태초에...

스케일폼 작업에 디자이너의 영역이 많은 부분 들어 있습니다.

하지만 개발까지 잘하는 디자이너를 찾기란 게임을 성공시키는 것보다도 어려운 일입니다.

어쩌다 as를 할 줄 안다고 하는 디자이너의 출신의 면접을 보면...

할 줄 안다기 보다, 그냥 as 라는게 있다는걸 아는 정도에 가깝다고나 할까요?

그분들에게 불만을 표하려는게 아닙니다. (저도 애니메이터 출신이니까요)

개발자들이 디자인은 못하지만 포토샵은 좀 다룰 줄 아는 정도와 같은 것이니까요...

(플래시를 기반으로 한 녀석 태초의 문제)

그런데 이 스케일폼(결국 플래시 작업) 이라는 것이 경계가 애매합니다.

fla 라는 디자이너의 바이너리 파일과 as 라는 개발자의 코드 덩어리가 붙어 있어야만 돌아가는 것이니까요...

게다가 스케일폼은 최근까지 as2를 지원했습니다.

플래시 개발자들의 대부분이 as3 가 나오고서야 클래스 문법이나 객체 활용에 대한 방법론에 대해 익숙해졌습니다.

그전의 플래시 결과물은 마치 웹에이전시에서 js 를 ctrl+c, ctrl+v 로만 사용하는 것과 가까운 수준이 대부분이죠...

그러다 보니 대부분의 as2 기반의 플래시 결과물들도 그 수준에서 크게 다르지 않습니다.

참고로 as2가 잘 사용할 수 있다면 as3 보다 생산성 면에서 더 훌륭한 언어입니다. as3 를 택하는 이유는 속도나 여러 다양한 기능 때문이지요

지금의 세상은 js가 통일하지 않았습니까? :^)

3. 그럼 새로 만들자

라고 하고 싶지만, 플래시 개발과는 또 다른 문제가 있습니다.

스케일폼은 DA(다이렉트 액세스) 를 사용하여 플래시의 오브젝트들을 직접 컨트럴할 수가 있다 보니 클라이언트 코드와도 밀접한 관계를 맺고 있습니다.

이런 상황에서 변수나 함수 이름 하나 내 마음대로 고치지 못하게 될 수 있는 것이지요...

물론 UI 와 클라이언트 코드 모두 고치면 됩니다...

그런데 UI 개발하는 사람의 편의를 위해 코드 리팩토링을 클라이언트까지 해야 한다라...

뭐 프로젝트의 여유가 있다면 괜찮겠습니다만,  우리가 언제 바쁘지 않은 적 있었나요?

게다가 개발 초기에 스튜디오를 만들 때에는 스케일폼 인력을 배치하지 않는 경우가 많습니다.

무슨 엔진을 쓸 지, 스케일폼을 쓸지 조차 결정되지 않았는데... 인력 구성을 할 이유가 없지요.

그러다 보니 나중에 서비스가 가까워진 시점에 되서야 사람을 급하게 구하거나, 클라이언트가 벼락치기 공부를 해서 구현을 해버리지요...

이런 결과물이 제대로 돌아갈 일이 없고, 그런 개발사들은 스케일폼에 대한 반감도 생기지요...

이러다 서비스 단계까지 가면 정말 되돌릴 수도 없습니다

4. 그럼 래핑을 하면?

이런 상황까지 오면 일정 수준 이상의 개발자라면 자연스레 래핑 클래스를 만들 생각을 하게 될겁니다.

"기존의 클라이언트와의 통신 api를 고도로 래핑시켜서 클라이언트가 고치지 않고도 UI 내부 구조를 뜯어 고치겠어!!"

라고 할 지도 모릅니다.

(센스 있는 개발자의 선택은 래핑)

그런데 이것도 그리 쉽지 않습니다.

스케일폼의 플래시 작업은 정말로 양이 많습니다. 특히 mmorpg라거나, 스포츠 매니징 게임이라면 UI 의 숫자가 엄청나죠

(몇몇 회사에서 왜 전문 플래시 개발자를 고용 안하려고 하는지 모르겠습니다.... 전 이 작업량 때문이라도 무조건 전문 개발자가 있어야 한다는 생각이 듭니다)

에이전시에서 작업하던 플래시 작업으로 치면 수개월에 해당하는 작업량이 한 게임 안에서 돌아가는 데다가 그 요구사항마저 수시로 바뀝니다.

게다가 에이전시에서의 결과물 처럼 페이지마다의 독립적인 결과물이 아닌, 모든 결과물이 상호 관련이 있습니다.

그러니 코어를 잘못 한번 건드렸다가는 아주 큰 코를 다칠 수 있습니다.

5. 일단 이해부터 하자

전임자 들이 무조건 똥을 쌌다고 생각할 필요는 없습니다. :^)

프레임 코딩이 무조건 나쁜게 아닙니다.

(99% 정도는 나쁜게 사실이지만 1% 의 변명을 하자면 똑같은 코드라면 사실 프레임 코딩이 속도는 조금 빠릅니다)

다이렉트 액세스도 나쁜게 아닙니다.

(속도가 더 좋지요... 다만 쓰는 방법들이 잘못되어 있습니다.)

as 를 잘 모르는 클라이언트가 코드를 망쳐놓은게 아닙니다.

클라이언트 작업은 작업대로 하면서 as를 벼락치기 공부해서 그정도 구현해 놓은 것도 사실 엄청난 것이지요...

래핑을 하기 싫어서 안하는게 아닙니다.

너무 방대하다 보니, 문제가 생길 지도 모르니 함부로 건드릴 수가 없습니다.

as의 특성상 컴파일 타임에서는 정상적이였던 녀석이 런타임에서 어떤 문제를 일으킬 지 모르기 때문입니다

브랜치를 따로 만드는 것도 어렵습니다. 보통 UI 개발자를 한명 정도만 고용하는데, 요구사항을 라이브로 처리하면서 그런 작업을 할만큼의 여유가 있을 수가 없습니다.

게다가 브랜치를 따로 뜰 정도면 클라이언트 리더급 이상에게 양해(?)를 구해야 할 텐데, 일단 UI가 돌아가고는 있는 상황이라면 쉽게 허락해주지도 않을겁니다.

그리고 스케일폼이 플래시의 fla, swf 와 같은 바이너리 파일을 사용하기 때문에 브랜치를 떠도 나중에 다시 합치기가 만만치 않습니다

6. 그럼에도...

그럼에도 불구하고 도저히 불안하죠...

현재 어떻게든 어떻게든 악조건 속에서 요구사항을 구현하고는 있지만...

좋지 않은 구조는 향후의 대응력을 떨어뜨리게 됩니다.

어떻게든 구현하기 위해 코드를 떡칠(?)해가면 갈수록 더욱더 심해지죠...

그러다 보면 이런 의문이 들게 될겁니다.

"이러다가 라이브라도 시작하면 요구 사항에 제때 제때 응할 수 있을까?"

라고 말이죠...

7. 기회를 활용해야 합니다

모든걸 엎기 위한 몇번의 기회를 만들어낼 수 있습니다.

일단 as3 로의 업그레이드(?)가 있겠네요...

그런데 as3 란 언어가 as2 보다 나은 언어는 아닙니다. 오히려 생산성 면에서는 더욱 떨어지는 언어입니다.

gc 도 더 어려운 면이 있고요...

다만 속도와 다양한 기능을 활용할 수가 있습니다.

그런데 as3 는 CLIK 활용에 문제가 좀 있습니다. 런타임 공유를 기존의 방식대로 하다보면 자꾸 null 오류가 뜨는 걸 확인하실 수 있을겁니다.

그래도 이 기회가 거의 유일한 것이... 다른 이유로는 UI를 엎겠다고 말하기가 쉽지 않지요...

8. 그냥 넋두리였습니다

뭐 이정도까지 오면 사실 딱히 방법이 없습니다.

알아서 잘 해야지요...

하지만 hika 군은 이런 말도 했지요

https://www.facebook.com/hika00/posts/666620710020058

"작고 눈에 보일때 잡고 정리하기를 게을리하면 이미 그 시점에 개발이 실패한걸로 봐도 무방할지도 모른다."

라고요...

조금씩 조금씩이라도 자신의 코드 유지보수를 게을리 한다면 그 개발은 실패한 걸지도 모릅니다

군대에 가면 이런 말이 있지요...

"닦고 조이고 기름치자"

닦고 조이고 기름 칩시다!!!