참고로, 이 내용은 Flex 뿐 아니라, 현대의 수많은 프로그래밍 언어에서 통용되는 이야기이다.
다른 글에서도 유사한 내용을 종종 언급하였지만, 아직 별 효과가 없는 듯 하여(?) 정리하여 다시 적는다.
민감한 이슈, 퍼포먼스
프로그래머들에게 있어서, 성능은 매우 민감한 이슈이다. 애초에 그렇게 배워왔고, 이 이슈에 민감하게 반응할 수 있기 때문에(?) 프로그래머가 될 수 있었을 것이다.
하지만, 컴퓨터 과학(Computer Science)이 아닌 소프트웨어 공학(Software Engineering)에서는, 즉 실무 프로젝트에서는, 성능에 대해서 논하기 전에, 아래와 같은 내용을 미리 생각해볼 필요가 있다.
성능의 한시적 특성
Flex, 그리고 ActionScript는 Virtual Machine 기반의 언어이다. 다시 말하면, C나 Assembly와는 달리, CPU나 메모리 등의 하드웨어 아키텍쳐에 직관적이지 않고, 여러 차례 추상화 레벨을 거친 언어이다.1
그런데, 이러한 Virtual Machine에 기반한 언어의 API 성능은, Virtual Machine의 버전에 따라, 또는 플랫폼에 따라, 언제든지, 그리고 얼마든지 변화할 수 있다. 다시 말하면, 한시적 특성을 가진다.
어제까지만 해도 제일 느렸던 함수가, 새로 나온 버전에서는 가장 빠른 함수가 될 수 있다는 것이다. 그것이 사용자의 요구에 의해서든, 아니면 API 개발자의 욕심에 의해서든, API의 성능은 필연적으로 계속 변화한다. 절대적으로는 물론이며, 상대적으로도 그러하다.
성능 과민성
위에서도 언급하였지만, 프로그래머들은 성능에 매우 민감한 편이다. 하지만 문제라면, 일반 사용자들보다도 더 성능에 민감하다는 것이다.
하지만, 소프트웨어 공학에서, 성능 문제는 사용자가 체감하지 못하면 전혀 문제가 되지 않는다. 즉, 사용자가 체감하기 전까지는, 그 소프트웨어의 가치에 전혀 변화를 주지 않는다는 뜻이다.2
특히, 커뮤니티를 돌아다니다보면, 소프트웨어의 전체 성능의 1%에도 채 미치지 못할 성능 저하에 신경을 쓰는 경우를 자주 목격한다. 특정 프레임워크에서 가장 중요한 기능 중 하나를, 평생 한 번이나 문제가 될까 싶은 미세한 성능의 저하를 언급하며 쓰지 말라고 조언하는 경우도 있다.
하지만 여전히 중요한 이슈, 퍼포먼스
물론 그렇다고는 해도, 성능에 대해 전혀 모르는 것도 문제가 된다. 여러 프로젝트를 하다 보면, 리소스의 제한에 부딪치는 경우는 비일비재하다. 만약에라도, 퍼포먼스에 전혀 신경을 쓰지 않고 개발을 한다면, 어쩌면 거의 모든 프로젝트에서 성능 문제가 발생할지도 모른다. (물론 그렇게 해 본 적도 없고, 그런 사람을 본 적도 없다.)
다행히, 가장 적절한 수준의 퍼포먼스를 유지하는 방법이 있다. 그것은 바로 '일반적인 코딩 스타일'과 레퍼런스 매뉴얼과 API의 숙지이다.
해당 프로그래밍 언어에서 가장 일반적으로 통용되는 코딩 스타일이 있다면, 그 스타일을 따르는 것만으로도, 가장 적절한 수준의 퍼포먼스를 유지할 수 있다. 또한, 레퍼런스 매뉴얼에는 거의 모든 일반적인 문제를 해결하는 방법과, (적어도 API를 개발한 사람 입장에서는) 가장 이상적인 스타일의 예시 코드를 제공한다.
물론 범위를 조금 넓게 잡으면 '패턴'도 그에 속할 수 있지만, '패턴 남용'으로 인한 폐단도 매우 큰 문제이기 때문에, 일단는 제외하기로 하겠다.
결론
이 글의 내용을 한 문장으로 정리하라고 하면, '성능 문제는 꼭 필요한 시점이 될 때까지는 잊고 살자'라고 정리하고 싶다. 성능 문제에 대해서 알고 있는 것은, 꼭 필요한 시점에서는 분명히 도움이 되지만, 그렇지 않은 상황에서는 오히려 방해가 될 뿐이다.
지식의 축적은 언제고 도움이 되기 마련이지만, 그 지식에 얽매여서는 일정 수준을 벗어나기 어렵다. 인터넷 등에서 성능에 대해 언급해놓은 정보를 접하게 된다면, 일단 기억은 해두되, 집착하지는 말자.
마치며 덧붙임
사실, 이 글은 조금은 의도적으로 '퍼포먼스'를 깎아내린 감이 없지 않다. 그렇기에 어느 정도 경험이 있는 분들은 '이 정도 까진 아닌데'라는 생각을 가질 수 있다. 굳이 이렇게 글을 쓴 이유는, 아직 충분한 경험이 쌓이지 않은 분들의 경우, 퍼포먼스에 과도한 신경을 쓰다가 더 큰 그림을 놓치는 경우가 많기 때문이다.
야구에는 "끝나기 전에는 끝난 것이 아니다"라는 말이 있다. 프로그래밍에서, 적어도 성능 문제에 관해서는 "문제가 되기 전에는 문제가 아니다"라는 말을 마지막으로 하고 싶다.
- 예를 들어, C에서 strcat()의 경우에는, 일반적인 C 개발자들은, 이 함수를 실행할때 메모리에서 어떠한 일이 일어나는지 매우 정확히 알고 있다. 또한 그것은 일종의 약속이기도 하다. 하지만, Flex에서는, String.concat()을 실행할 때, (물론 String 두 개를 붙여준다는 것은 알고 있지만) 시스템 상에서 대관절 무슨 일이 일어나는지 정확히 알고 있는 개발자는 몇 명 없다. 엄밀히 말하면, API 개발자 외에는 내부 구현을 알 필요가 없다. API의 내부 구현에 대해 아는 것은, Application 개발자의 역할이 아니다. [본문으로]
- Lean 소프트웨어 개발 방법론에서는 이러한 문제에 대해 미리 대비하는 것을 '낭비(waste)'라고 표현한다. [본문으로]
'Adobe Flash Platform > Flex' 카테고리의 다른 글
| Mustella와 Test 생성기 (8) | 2009/12/08 |
|---|---|
| Array.indexOf()가 괴롭힐 때 (0) | 2009/11/28 |
| 성능을 논하기 전에 (0) | 2009/11/28 |
| Function.apply()를 이용한 퍼포먼스 튜닝 (3) | 2009/11/27 |
| 커스텀 메타데이터 태그 (22) | 2009/11/26 |
| FlexUnit 4, Ant Task 지원 (4) | 2009/11/26 |
댓글을 달아 주세요