상황 단계
플래시 혹은 플렉스 라는 작업 방법론을 통해서 도출되는 결과물은 swf 파일 입니다. 그 Shockwave Flash 라는 클라이언트 상에서 작동하는 인터렉티브 미디어 파일을 만들어내는 것이 바로 우리들이 하는 일이죠.
자, 우리가 목표로 하는 여러가지 툴들에 대해 총괄적인 이해를 하기 위해서는 바로 그 swf 가 만들어지고, 사용되어지는 상황들에 대한 이해가 필요합니다. 그 단계는 크게 세가지로 나눌 수 있습니다.
여러가지 파일들을 작업하는 소스 단계와 해당 소스들이 mxmlc 라는 컴파일러를 통해서 컴파일 되는 단계, 그리고, 컴파일이 정상적으로 종료가 된 후 아웃풋 되는 swf 가 실제 구동되는 런타임 단계 입니다.
굉장히 기초적인 이야기지만 여러가지 툴들에 대해서 대략적인 이해를 하기 위해서는 이 각 단계들에 대해 이해하는 것이 매우 중요합니다.
디버깅
우선적으로 여기서 에러에 대한 구분을 할 수가 있는데요.
소스가 컴파일 되는 과정에서 발생하는 오류가 컴파일 에러이고, 정상적으로 컴파일이 완료된 이후 swf 가 작동되는 과정 상에서 발생하는 오류는 런타임 에러 입니다.
이런 단계별 에러에 대한 것은 위와 같이 레퍼런스 상에 따로 분리되어 기재되어 있습니다.
그리고, 이 에러 상황을 해결하는 행위를 디버깅이라고 하고, 그것을 도와주는 유틸리티를 디버거 라고 합니다.
디버거는 위와 같이 컴파일 에러, 런타임 에러에 대한 에러 영역에 대한 확인이나 원인에 대한 안내, 런타임 상황에서 자원들의 변화를 감시하는 등의 역활을 합니다.
우리가 ActionScript 3.0 이라는 규칙이 까다로운 언어를 사용해야 하는 이유 중 하나는 바로 이런 디버거 라는 기계적 장치가 에러에 대한 원인을 파악하는데 있어서 인간이나 알아보는데 2.0 과 같은 규칙이 자유로운 코드가 아닌, 기계가 파악하기 쉽게 기계적 규칙이 까다롭게 적용된 3.0 같은 코드가 좋기 때문입니다.
2.0 보다 3.0 의 코딩이 좀 더 불편하긴 하지만, 디버거가 제공하는 오류 정보의 양은 2.0 보다 3.0 이 압도적으로 많습니다.
이런 디버거는 Flex builder 나 FDT 의 경우에는 위와 같이 Eclipse 고유의 Debug 패널과 유사한 형태로 제공되고,
Flash 의 경우엔 위와 같이 컴파일러 에러의 경우엔 compiler errors 패널로, 런타임 에러의 경우엔 output 패널로
변수의 변화나 breakpoint 의 적용등엔 위와 같은 Debug 모드를 통해서 지원합니다.
이런 디버거를 적절히 잘 활용하는 것은 (특히 흔히 사용하지 않는 변수에 대한 감시 같은 기능을 잘 활용하는 것은) 에러 상황에 대한 보다 빠른 대응에 큰 도움을 주곤 합니다.
그리고, Flex builder 나 FDT 같은 고급 에디터들의 경우엔 이렇게 컴파일이나 런타임 상황 이전에 소스 레벨에서 에러를 체크해 주기도 하는데요.
고급 (비싼) 에디터들의 경우 컴파일, 런타임 이전에 위와 같이 코딩을 진행하는 상황에서 바로 에러를 검출해주기도 합니다. 이런 소스 레벨에서의 에러검출은 작업에 대한 안정성을 향상시키는데 굉장히 큰 도움을 주죠. 컴파일 단계에서 발생할 수 있는 에러의 경우는 거의 대부분 발생하지 않게 해주고, 런타임 상의 에러 역시 많은 부분 미리 수정이 가능하게 해줍니다.
형상관리 및 버그리포팅
엄청나게 복잡한 맵이 탄생했는데요.
소스의 파일과 텍스트 소스코드의 특징을 사용하는 SVN, CVS 와 같은 형상관리 툴과 Trac, JIRA 와 같은 스케쥴, 프로젝트 관리툴, 그리고, 버그에 대한 리포팅 역활을 담당하는 BugZilla 와 Trac, JIRA, 그리고 그와 같은 전반적인 툴들이 Eclipse 기반의 Mylyn 과 통합되어서 소스코딩에 영향을 미치게 되는 것까지 좀 더 견고한 작업환경을 구축하는데 중요한 여러가지 개념들이 적혀있는 맵입니다.
이런 기능들은 소스코드가 어떤 방향으로 발전해야 하는지에 대한 좀 더 객관적인 시각에서의 방향성을 제시해주게 되는데 큰 도움이 됩니다.
뭐 이 중, 이 강좌가 다룰 것은 SVN, Trac, Mylyn 인데요. 지금 당장 저 맵을 보면서 "엥?" 할 필요는 없구요. 천천히 하나 하나 다뤄나갈 것이니 일단 기능들이 어떤 단계의 보강을 위해서 존재하는 것인지 대략 살펴보기만 하면 될 것 같습니다.
빌드 자동화
프로젝트가 커지고, 점점 Ctrl+Enter 따위로 컴파일 하기에는 그 분량이 너무 많아진다 싶을때쯤이 되면 빌드 자동화에 대한 요구가 생기게 됩니다.
이런 빌드자동화는 기본적으로 컴파일과 컴파일 된 결과물을 퍼블리싱 하는 과정을 기계적으로 자동화 시켜줍니다.
빌드 자동화 툴은 Action Script 개발의 경우는 크게 두가지를 씁니다. Ant 라는 Eclipse 와 궁합이 잘 맞는 상당히 편리한 빌드툴을 사용하던가, 아니면, shellscript 나 batch 등을 사용해서 직접 mxmlc 의 커맨드라인을 제어하는 방법 입니다. 이 두가지는 서로 장단점이 있는데요.
Ant 의 경우엔 Eclipse 라는 개발툴의 지원부터 시작해서 이미 FDT, Flex builder 상에서 Ant 에 대응하는 좋은 기능들을 이미 구현해놨지만, XML tag 형식으로 구성되어있어서 조금 분량이 많아진다거나 하면 아무래도 노가다량이 충분히 많아진다는 점이고,
Shellscript 의 경우엔 Ant 에서 사용할 수 없는 function 같은 script 적 표현을 사용해서 자동화 할 수 있기 때문에 보다 다채로운 표현이 가능하나, 아무래도 Eclipse 와 같은 에디터를 통해 지원되는 기능등은 없다는 것이 문제입니다. (Ant 보다는 좀 더 사용하기가 까다롭지만, 그만큼 다채롭기도 하죠...)
역시 이런 빌드 자동화에 대한 부분들도 하나 하나 세세하게 살펴보는 시간이 있을테니 일단 이런게 있구나 라면서 알아두면 될 것 같습니다.
프로그램이란 것은 필요에 의해 만들어진다...
인간이 만드는 모든 것은 결국 필요에 의해 만들어지지 않을까 싶습니다. 엄청 대단한 천재가 뜬금없이 나타나서 엄청 새로운 것을 만들어내는 것이 아닌, 기존에 아주 불편하던 것을 좀 더 편리하게 만드는 것... 그것이 바로 발명 이란게 아닐까 싶습니다.
swf 라는 결과물을 만들어내기 위해서 엄청나게 많은 툴들을 꼭 사용해야 하는 것은 아닙니다. 메뉴바, 배너 하나 만드는데 SVN, Trac 을 사용해서 형상관리나 프로젝트 관리 따위를 할 필요는 없고, 당연히 Ant 등을 사용한 빌드 자동화 따위도 필요없겠지요. 해당하는 툴들이란 "일이 너무 많아져서 버거워질때 그 업무량을 일정 부분 기계에게 할당하기 위해" 발명되어진 툴들이므로 자신의 작업분량을 줄이는데 도움이 되지 않는다면 사용을 구지 할 필요는 없습니다.
여러분이 어떤 툴을 이해하려고 할때 저와 같은 작업 단계에 대한 고려를 하면서 접근하는 것은 상당한 이해의 폭을 제공해줍니다. 어떤 툴도 그냥 만들어지지는 않았고, 결국 swf 를 만들어내는데는 저 세단계 중 한가지 단계의 작업을 보조하기 위해서 만들어진 것일테니깐요.
뭐 복잡하게 써놓긴 했지만, 그렇게 복잡하지도 않습니다. 그냥 소스 > 컴파일 > 런타임 이라는 swf 가 만들어지고 사용되어지게 되는 상황 단계를 이해하고 넘어가면, 앞으로 나올 여러가지 개발도구들에 대해 이해하는데 큰 도움이 될테니 꼭 기억해두도록 하세요.
