jasu's blog
블로그 메뉴글
플래시 컨텐츠의 최적화
Design/Web
2007. 3. 5. 22:41
최적화는 상당히 어려운 부분이다. 사실 어렵다기 보다는 아는 부분도 실수로 보지 못하는 경우도 있고, 문제를 문제로 인식하지 못하는 과정에서 발생하는 경우도 많다. 플래시를 천직으로 생각하고, 플래시 툴이 항상 컴퓨터의 메모리에 상주해 있는 본인도 이러한 문제에 봉착할 때가 한 두 번이 아니다.
요즘은 워낙 컴퓨터 사양이 좋아져서 최적화의 유용성이 많이 감소되기는 하였으나 작업 과정에서 이런 최적화의 노력이 몸에 배어 있지 않으면 개발이 완료되는 시점에서 자신의 잘못 보다도 디자인의 묵직함을 탓하는 경우가 많다. 물론 우리나라의 웹 컨텐츠의 화려함을 보면 과연 컴퓨터가 온전할까 하는 두려움마저 드는 사이트들도 상당히 존재한다. 나 또한 그러한 사이트를 만들기 위해 없는 일정 만들어가며 동참한 것도 사실이다. 이러한 문제는 항상 바쁜 클라이언트의 명령에 서비스하는 차원에서 이루어 지는 경우도 있지만 그러한 볼멘소리에 숨겨놓은 자신의 귀차니즘이 더욱 큰 영향을 주는 경우도 있다.
하지만 그러한 노력을 하지 못하게 만드는 불가피한 현실도 문제다. 우리나라의 클라이언트를 보면 더 화려하고, 더 보기 좋고, 더 강렬한 사이트를 요구하는 경우가 많다. 그러한 요구를 맞추기 위해서 노력하다 보면 최적화는 다른 프로젝트에 밀려서 잊혀지고 만다. 서비스업이다 보니 의뢰하는 클라이언트의 눈높이에 맞출 수 밖에 없는 것이 현실지만 무엇보다도 웹을 개발하는 전문가로서 전문의식과 지식을 갖출 필요가 있다.
나는 웹에이전시에서 근무한 경력은 화려하지 않다. 그러다 보니 기획, 디자인, 컨텐츠, 개발, 코딩과 관련하여 총체적으로 회사 입장의 이익 창출을 위한 객관적인 판단이 미흡한 것이 사실이다. 그러나 단기적인 이익을 위한 위기 모면적 프로젝트와 그것을 생산하는 회사는 발전 가능성은 희박하다는 생각이다.
클라이언트와 직접적으로 커뮤니케이션을 하는 기획과 디자인의 경우에는 실질적으로 프로젝트를 진행하는 실무진의 기본적인 지식과 판단에 서서, 전문자로서의 커뮤니케이션이 가능해야 한다고 본다. 전문 지식을 바탕으로 하지 않은 커뮤니케이션은 자칫 클라이언트의 말 전달자가 될 수도 있고, 비 전문가의 개인적 취향에 따라 대외비적인 프로젝트로 전락할 수도 있을 것이다. 이러한 문제점을 지향하기 위해서는 개인적인 자기개발도 중요하겠으나 팀과 조직 구성원들의 스스럼 없는 커뮤니케이션과 의견 존중이 밑 바탕에 깔려 있어야 할 것이다.
나는 어떠한 경우에도 웹의 기본 정신은 훼손되어서는 안 된다고 생각한다. 웹의 모든 부분은 커뮤니케이션이다. 웹 == 커뮤니케이션이라는 정의는 항상 머리 속에 넣어두고 살아야 한다. 사이트가 아무리 화려하고 많은 컨텐츠를 가지고 있어도 궁극적으로 그것을 사용자가 학습하고 원하는 정보를 찾는데 어려움을 느낀다면 그 웹사이트는 이미 죽은 사이트다.
예전에는 얼마나 화려하고, 얼마나 많은 기능을 제공하는 가와 같은 양적인 측면 위주였다면, 앞으로는 질적인 측면과 감성적인 측면을 더 중요시 해야 한다. 이러한 면에서 Web 2.0이라는 트랜드가 많은 부분에서 변화를 꾀하고 있고 덕분에 UX(User Experience)는 예전보다 사용자에게 상당히 많은 접근을 하고 있다.
그러나 우리나라의 Web 2.0은 껍데기에 불과하다는 이야기를 하고 싶다. Web 2.0이라는 개념은 화려한 테크닉을 이야기 하는 것이 아니라 사용자 경험에 따른 좀더 편하고 쉽게 다가갈 수 있는 웹 가이드일 것이다. 가끔 보면 그러한 기본 정신을 잊고 엉뚱한 곳에서 헤매는 경우를 많이 보게 된다.
나는 웹에 종사하고 있기 때문에 임베디드 분야는 잘 알지는 못하지만 최적화의 요구가 필수적이라는 것은 간접적인 경험을 통해서 익히 들어왔다. 요즘처럼 수천 MB의 메모리를 갖춘 PC에서 프로그램을 개발하는 사람들에게는 수십 KB의 메모리에서 프로그램을 개발해야 된다는 것이 상당한 압박으로 느껴질 수 있을 것이다. 이러한 하드웨어적인 환경의 제약으로 인해 컴파일러 수준의 코드 최적화는 물론이고 소스 코드 수준에서도 최적화된 코드를 작성할 필요가 있을 것이다.
일반적으로 컴파일러가 제공하는 최적화의 종류는 크기 최적화와 속도 최적화의 두 부류로 나눠볼 수 있을 것이다. 임베디드 분야에서는 이 중에 크기 최적화를 통해 작은 크기의 실행 파일을 생성하는 것이 더 유리할 것으로 본다. 속도 향상은 알고리즘의 개선이나 소스 코드 튜닝을 통해 상당 부분 개선할 수 있지만 실행 파일의 크기를 소스 코드 레벨에서 수동으로 줄이기는 사실상 어려움이 있을 것이다. 물론 이런 것들 또한 지금의 발전과 같이 과거의 이야기가 될 수도 있으나 먼 미래에도 최적화에 대한 요구는 계속 있을 수 밖에 없을 것이다.
내가 만약 당장 임베디드 시스템에 필요한 컨텐츠와 UI를 제작한다면 그 코드를 담는 하드웨어의 무게보다 무거운 프로그램이 탄생하지 않을까 싶다. 웹에서 임베디드 분야와 같은 최적화를 가지고 갈 필요는 없을 것이다. 웹은 웹에서 충분히 사용할 수 있는 기술과 방법을 최대한 활용하여 보다 사용자 중심의 사이트를 만들면 된다. 하지만 그러한 기술과 방법에 치우쳐서 최적화를 소홀히 한다면 자신이 만든 프로그램으로 조종하는 전투기 안에 있어봐야 할 것이다.
요즘은 워낙 컴퓨터 사양이 좋아져서 최적화의 유용성이 많이 감소되기는 하였으나 작업 과정에서 이런 최적화의 노력이 몸에 배어 있지 않으면 개발이 완료되는 시점에서 자신의 잘못 보다도 디자인의 묵직함을 탓하는 경우가 많다. 물론 우리나라의 웹 컨텐츠의 화려함을 보면 과연 컴퓨터가 온전할까 하는 두려움마저 드는 사이트들도 상당히 존재한다. 나 또한 그러한 사이트를 만들기 위해 없는 일정 만들어가며 동참한 것도 사실이다. 이러한 문제는 항상 바쁜 클라이언트의 명령에 서비스하는 차원에서 이루어 지는 경우도 있지만 그러한 볼멘소리에 숨겨놓은 자신의 귀차니즘이 더욱 큰 영향을 주는 경우도 있다.
하지만 그러한 노력을 하지 못하게 만드는 불가피한 현실도 문제다. 우리나라의 클라이언트를 보면 더 화려하고, 더 보기 좋고, 더 강렬한 사이트를 요구하는 경우가 많다. 그러한 요구를 맞추기 위해서 노력하다 보면 최적화는 다른 프로젝트에 밀려서 잊혀지고 만다. 서비스업이다 보니 의뢰하는 클라이언트의 눈높이에 맞출 수 밖에 없는 것이 현실지만 무엇보다도 웹을 개발하는 전문가로서 전문의식과 지식을 갖출 필요가 있다.
나는 웹에이전시에서 근무한 경력은 화려하지 않다. 그러다 보니 기획, 디자인, 컨텐츠, 개발, 코딩과 관련하여 총체적으로 회사 입장의 이익 창출을 위한 객관적인 판단이 미흡한 것이 사실이다. 그러나 단기적인 이익을 위한 위기 모면적 프로젝트와 그것을 생산하는 회사는 발전 가능성은 희박하다는 생각이다.
클라이언트와 직접적으로 커뮤니케이션을 하는 기획과 디자인의 경우에는 실질적으로 프로젝트를 진행하는 실무진의 기본적인 지식과 판단에 서서, 전문자로서의 커뮤니케이션이 가능해야 한다고 본다. 전문 지식을 바탕으로 하지 않은 커뮤니케이션은 자칫 클라이언트의 말 전달자가 될 수도 있고, 비 전문가의 개인적 취향에 따라 대외비적인 프로젝트로 전락할 수도 있을 것이다. 이러한 문제점을 지향하기 위해서는 개인적인 자기개발도 중요하겠으나 팀과 조직 구성원들의 스스럼 없는 커뮤니케이션과 의견 존중이 밑 바탕에 깔려 있어야 할 것이다.
나는 어떠한 경우에도 웹의 기본 정신은 훼손되어서는 안 된다고 생각한다. 웹의 모든 부분은 커뮤니케이션이다. 웹 == 커뮤니케이션이라는 정의는 항상 머리 속에 넣어두고 살아야 한다. 사이트가 아무리 화려하고 많은 컨텐츠를 가지고 있어도 궁극적으로 그것을 사용자가 학습하고 원하는 정보를 찾는데 어려움을 느낀다면 그 웹사이트는 이미 죽은 사이트다.
예전에는 얼마나 화려하고, 얼마나 많은 기능을 제공하는 가와 같은 양적인 측면 위주였다면, 앞으로는 질적인 측면과 감성적인 측면을 더 중요시 해야 한다. 이러한 면에서 Web 2.0이라는 트랜드가 많은 부분에서 변화를 꾀하고 있고 덕분에 UX(User Experience)는 예전보다 사용자에게 상당히 많은 접근을 하고 있다.
그러나 우리나라의 Web 2.0은 껍데기에 불과하다는 이야기를 하고 싶다. Web 2.0이라는 개념은 화려한 테크닉을 이야기 하는 것이 아니라 사용자 경험에 따른 좀더 편하고 쉽게 다가갈 수 있는 웹 가이드일 것이다. 가끔 보면 그러한 기본 정신을 잊고 엉뚱한 곳에서 헤매는 경우를 많이 보게 된다.
나는 웹에 종사하고 있기 때문에 임베디드 분야는 잘 알지는 못하지만 최적화의 요구가 필수적이라는 것은 간접적인 경험을 통해서 익히 들어왔다. 요즘처럼 수천 MB의 메모리를 갖춘 PC에서 프로그램을 개발하는 사람들에게는 수십 KB의 메모리에서 프로그램을 개발해야 된다는 것이 상당한 압박으로 느껴질 수 있을 것이다. 이러한 하드웨어적인 환경의 제약으로 인해 컴파일러 수준의 코드 최적화는 물론이고 소스 코드 수준에서도 최적화된 코드를 작성할 필요가 있을 것이다.
일반적으로 컴파일러가 제공하는 최적화의 종류는 크기 최적화와 속도 최적화의 두 부류로 나눠볼 수 있을 것이다. 임베디드 분야에서는 이 중에 크기 최적화를 통해 작은 크기의 실행 파일을 생성하는 것이 더 유리할 것으로 본다. 속도 향상은 알고리즘의 개선이나 소스 코드 튜닝을 통해 상당 부분 개선할 수 있지만 실행 파일의 크기를 소스 코드 레벨에서 수동으로 줄이기는 사실상 어려움이 있을 것이다. 물론 이런 것들 또한 지금의 발전과 같이 과거의 이야기가 될 수도 있으나 먼 미래에도 최적화에 대한 요구는 계속 있을 수 밖에 없을 것이다.
내가 만약 당장 임베디드 시스템에 필요한 컨텐츠와 UI를 제작한다면 그 코드를 담는 하드웨어의 무게보다 무거운 프로그램이 탄생하지 않을까 싶다. 웹에서 임베디드 분야와 같은 최적화를 가지고 갈 필요는 없을 것이다. 웹은 웹에서 충분히 사용할 수 있는 기술과 방법을 최대한 활용하여 보다 사용자 중심의 사이트를 만들면 된다. 하지만 그러한 기술과 방법에 치우쳐서 최적화를 소홀히 한다면 자신이 만든 프로그램으로 조종하는 전투기 안에 있어봐야 할 것이다.
