즐거운 만남 액션스크립트까페 컨퍼런스를 다녀와서...

Programming/Etc 2010. 5. 3. 11:45

즐거운 만남 액션스크립트까페 6회를 다녀왔습니다. 양재 AT센터는 처음 방문이었는데 강남에서 그리 멀지 않을 곳이라 중소 규모의 컨퍼런스나 세미나를 하기에 좋은 장소라는 생각이 들더군요. 사운드나 인터넷을 지원되지 않았던 부분은 좀 아쉽지만…

매번 참가 할 때마다 느끼지만 플래시에 관심을 두시는 분들은 참 열정적이라는 생각이 듭니다. 발표를 하는 분들이나 발표를 듣는 모든 분들이 플래시 하나만으로도 공감을 소통할 수 있다는 것이 참 즐겁습니다.









그날 발표하신 저를 포함한 문군, 공씨, 우야꼬, 러브데브 수고 많았습니다. 그리고 컨퍼런스를 준비하신 스텝분들과 스텝이 아닌(?!) 언노운군도 고생 많았습니다. 그리고 즐거운 자리 더욱 즐겁고 활기차게 채워주신 참가자 모든 분들 만나서 반갑고 즐거웠습니다. ^^

사진 출처 : 액션스크립트까페 땡굴이


다음에도 이런 좋은 기회가 저에게 찾아올지는 모르겠지만(항상 이런 말을 하면서도 꾸준히 뵙게 됩니다… 쿠쿠) 저는 언제나 지식보다는 느낌을 전달하는 전달자로 남겠습니다. ^^

반가웠어요~ ^^

    

설정

트랙백

댓글

NHN의 플래시 폐지 기사를 보면서...

Programming/Etc 2010. 4. 16. 14:13
오늘 네이버에서 단계적으로 플래시를 폐지하겠다는 기사와 함께 네이버의 플래시팀이 다른 플랫폼 직무를 맏게 되었다는 소식을 접하게 되었습니다. 물론 현 시점에서 업계의 발빠른 대응이고 그 결단은 높이 평가할만 합니다. 하지만 회사의 정책이나 방침을 외부 언론에 배포할 때는 해당 기사의 내용과 방향성을 잡기 마련입니다. "문제는 바로 플래시(동영상, 게임 등을 위한 미국 어도비사의 플랫폼) 때문이었다."와 같은 내용은 그 동안 네이버가 욕을 먹어가며 플래시 개발자들을 흡수하고  각 서비스에서 적극적으로 활용했던 입장에서 표명하기에는 좋지 않은 태도입니다.

적어도 플래시가 국내 결제 서비스에 걸림돌이 되고 있는 ActiveX같이 취급해서는 안 될 일입니다. 플래시가 광고 관련된 상품으로 무분별하게 사용되면서 사용자들의 반감을 샀던 것은 사실이나, 기사 내용처럼  플래시 때문에 웹이 위협받고 있다는 식으로 표현이 되어서는 안 될 것입니다.  위 문장은 아래와 같이 정정해야 합니다. "문제는 Apple(iPhone, iPad등을 판매하는 회사)에서 Adobe의 플래시 플랫폼을 지원하지 않기 때문이다."  라고 말입니다.

플래시는 웹의 역사와 함께 발전해 왔던 플랫폼입니다. 웹 뿐만이 아니라 사용자에게 보다 편리한 UX경험을 제공하기 위해서 많은 노력을 해 왔던 플래시 개발자들이 사용자 경험에 지대한 공헌을 했다는 것은 인정하고 싶습니다.  그러한 공헌조차 인정할 수 없다면 우리나라에서 장인정신이 묻어나는 소프트웨어 전문가, UX는 탄생하기 어려울 것입니다. 

Adobe에서 앞으로 어떤 방향으로 플래시 플랫폼을 발전시켜 나갈지는 모르겠으나, 플래시 플랫폼을 사랑하고 즐겼던 한 개발자로써 플래시 플랫폼이 가져다 주었던 UX에 대한 경험적 개발론과 사용자의 사용성에 대한 고민은 꺼지지 않기를 바랍니다.

세상은 빠르게 돌아갑니다. IT계열에서 개발자로 종사하는 수 많은 사람들은 그러한 체감을 온 몸으로 받고 피를 토하며 이 길이 맞는지 확신도 없이 밤새도록 공부에 열중합니다. 어찌보면 대한민국의 IT 개발자들에게 지금 당장 필요한 것은 높은 연봉이 아니라 미래의 희망과 현재 하고 있는 일에 대한 즐거움, 그리고 열정이 아닐까요?  힘들지만 그럼에도불구하고 즐길 수 있는 최소한의 수혈이 필요한 시기입니다. NHN 플래시 개발자분들, 그리고 대한민국 IT 개발자분들 힘내시기 바랍니다.



추가 : 현재 기사에 대한 출처는 정확히 밝혀지지 않은 듯 합니다. 다만 점진적으로 플래시를 줄여 나간다는 내용이라고 하네요

네이버 다이어리 트위터의 멘션 내용 : "네이버 쉬프트 행사에서 플래시 사용을 점진적으로 줄여 나간다고 밝힌 바 있습니다. 기사 내용처럼 단기간내 플래시 사용이 중지되거나 하지는 않습니다. 기사가 좀 강하게 나온 것 같습니다"

    

설정

트랙백

댓글

플래시 개발자의 관망, 그리고 준비

Programming/Etc 2010. 3. 1. 08:23
이미 시장은 급변하고 있고 그에 따라서 환경은 많은 변화를 가져올 것입니다. 문제는 그것을 문제로 받아들이느냐 변화로 받아들이느냐 입니다. 그 동안 플래시는 이렇다 할 경쟁이 없었던 것이 사실입니다. 개발자 입장에서 이러한 변화에 능동적으로 대처할 필요가 있습니다.

국내 시장은 해외시장과 많이 다르다는 것을 알고 계실 것입니다. 변화가 있다면 그 변화에 적응할 수 있는 시간적인 여유는 충분히 있습니다. 하루 아침에 미래 가치를 판단할 수 없는 문제라는 것입니다. IT에서 주도적인 해외 기업이 게임의 룰을 다시 정하겠다는 것은 시간이 걸리더라도 그 파급효과는 있을 것입니다. 다만 그것이 곧 플래시 플랫폼의 끝을 의미하지는 않을 것입니다.

요즘의 플래시 논쟁 때문에 본인이 하고 있는 업무에 대해서 심각하게 고민하게 된다면 본인이 왜 플래시 개발을 하고 있는지 생각해 볼 필요가 있습니다. 플래시는 목적이 아니라 수단입니다. 본인이 하고 있는 업무가 플래시를 하는 개발인지, 아니면 사용성이 좋은 결과물을 만들어 내기 위해 노력하는 개발자인지 고민해 볼 필요가 있습니다.

그 동안 플래시 개발자가 만들어낸 UX 업적은 분명히 있습니다. 세상의 모든 것이 그렇듯이 기존에 하고 있던 것을 완전히 버리고 다른 것을 시작한다면 그 시작은 0%입니다. 시작에서 다른 사람보다 손해를 본다는 것입니다. 그러나 기존에 하던 것을 버리지 않고 단 5%라고 새로 시작하는 것에 적용할 수 있다면 플래시 개발을 경험하지 않은 사람이 느끼는 차이는 5%가 아니라 50%도 될 수 있을 것입니다. 

결국은 합당한 UI를 디자인하고, UX를 설계할 수 있는 플랫폼이 무엇이냐는 수단이며 결과물을 만들어 내는 것은, 결국 개발자의 철학입니다. 플래시로 개발하면서 사용성을 고민했던 노하우를 다른 플랫폼을 통해서 고민해 보는 것은 플래시 개발에도 많은 도움이 될 것이라 생각합니다.

또한 지금의 입력장치(마우스, 키보드 기타…)가 10년 후에도 그대로 사용되지는 않을 것입니다. 이미 터치스크린을 통해서 마우스가 필요 없는 디바이스가 쏟아져 나오고 있고, 키보드 또한 멀티터치를 통한 입력장치로 대체될 가능성도 배제할 수 없습니다. 이러한 환경의 변화에 능동적으로 적응하고 시장에서 살아 남기 위해서는 플랫폼을 떠나서 그에 맞는 개발도 중요합니다. 

우리가 굳이 가능성에 대하여 마음을 닫을 필요는 없습니다. 열린 마음으로 무엇이든 준비하는 자세는 중요합니다. 설령 그것이 시장에서 주도적인 역할을 수행하지 못한다고 하여도 어떤 방향으로든 도움을 줄 것이라는 믿음이 중요할 것입니다.

제가 플래시의 동향에 대해서 언급할 수 없는 이유는 그러한 능력도 부족하지만 아직 시장의 움직임이 없기 때문이기도 합니다. HTML5가 완성된 기술도 아니거니와 플래시의 화려한 그래픽 요소를 버릴 수 있다면 기존에 사용할 수 있는 다른 기술로도 충분히 기획이 가능할 것입니다. 물론 시장에서 변화의 움직임이 보인다면 이미 시장은 변했다고 판단하셔야 하겠지만 현재의 상황을 본다면 플래시는 아니라지만 그에 대한 대안을 제시하지 못하는 상황이라고 생각 됩니다. (HTML5는 현재 시점에서 플래시의 대체재가 될 수는 없습니다.)

결론적으로 말하자면 현재 논쟁이 되고 있는 시장은 관망할 필요가 있습니다. 그러나 그 관망이 자칫 무관심으로 변하지 않도록 개발자 입장에서 준비하는 자세는 필요하다는 것이 개인적인 견해입니다. 그 준비는 특정 플랫폼에 국한되지 않을 것입니다.

*  이 글은 @sexyflash 님께서 트위터를 통해서 견해를 물어보셨기에 작성합니다. 내용이 많아서 블로그를 통해서 전해 드립니다.


    

설정

트랙백

댓글

애플(Apple)의 마이크로소프트(Microsote)화?

Programming/Etc 2010. 2. 12. 15:11
- Adobe CTO Kevin Lynch의 WSJ 기자와 인터뷰 내용입니다.

Wall Street Journal
OPINION: The Microsofting of Apple?
February 9, 2010
By Holman W. Jenkins, Jr.

애플은 증오적 라이벌 관계로 인해 제로섬 전략에 집착하는 회사로 전락할 위험에 놓여있습니다.

현재를 언급하는 것이 아니라 애플의 시가총액이 상상할 수 없는 규모에 달하여 마이크로소프트의 시가총액을 뛰어넘는 해의 이야기가 될 수 있습니다. 당연히 축하 인사가 따르겠지만 위로의 말도 함께 따를 것입니다. 제품 개발에만 전념하는 회사의 경우 전략에 집착하는 회사가 될 위험의 소지가 있기 때문입니다. 그리고 여기서 “전략”이란 증오적 라이벌 관계로 인한 제로섬 전략을 의미합니다.

안타깝게도 현재 우리는 신뢰를 찾기 힘든 타락한 세상에 살고 있습니다.

아이패드(iPad)의 예를 들어보겠습니다. 아이패드는 세상에 공개되자마자 “구세주 태블릿”이라는 별명을 얻었습니다. 아이패드는 상상하지 못할 만큼 탁월한 제품이 아닌 단지 애플이 넷북 경쟁에 뛰어들기 위해 출시한 제품으로, 아이팟 터치(iPod Touch)를 확대해 놓은 버전에 불과합니다. 아이패드는 최상의 웹 브라우징 시스템으로 부각될 수 없을 수도 있습니다. 왜냐하면 애플이 웹 상에서 비디오를 전달하는 데 75% 가량 사용되고 있는 플래시(Flash) 지원을 거부했기 때문입니다. 그러나 아이패드(iPad)(‘지불’이라는 영어 PAID의 철자 순서를 바꾸어 만든 말)는 애플의 온라인 서비스를 통해 판매되고 있는 e북, 음악 및 비디오를 사용하기에는 적합한 디바이스로 보입니다. 단도직입적으로 말하자면 아이패드는 마치 아이튠즈(iTunes) 스토어를 후원하기 위해 최적화된 디바이스로 보입니다.

그렇다면 왜 애플은 플래시를 제외시키기로 결정했는지 궁금하지 않을 수 없습니다. 애플과 애플의 후원업체들은 플래시가 짜증나는 웹 광고를 만드는데 사용되는 제품이라는 미학적이고 철학적인 이유를 내세우고 있습니다.

애플이 플래시를 거부하는 이유는 바로 여기에 있습니다. 플래시를 사용하면 아이폰(iPhone) 및 아이패드 사용자는 아이튠즈를 통하지 않고 비디오 및 기타 엔터테인먼트를 사용할 수 있을 것이고 애플 앱 스토어(Apple App Store)에서만 현재 구입할 수 있는 다양한 기능을 무료로 얻을 수 있게 됩니다.

네트 중립성 옹호자들이나 독점 금지법 집행자들이 스티브 잡스(Steve Jobs)를 연행해가는 오류를 범하지 않도록, 한 가지 덧붙이자면 애플은 플래시를 거부할 수 있는 적법한 권리를 가지고 있습니다. 그러나 한 가지 짚고 넘어가야 할 것은 애플은 엄청난 양의 웹 컨텐츠와 사용자를 분리시키려는 전략적 선택을 내세우고 있다는 점입니다. 플래시가 버그를 부른다는 주장 등에 대해 플래시 옹호자의 시점에서 잠시 벗어나 설명해 보겠습니다. 플래시는 다른 비디오 플레이어와의 시장 경쟁에서 우위를 점하고 있으며 10억 명에 달하는 PC 사용자가 정기적인 업데이트를 다운로드하고 있다는 사실은 엄청난 성공이라고 해도 과언이 아닐 것입니다. Hulu.com에서 TV 프로그램을 시청하거나 MLB.com에서 야구 경기를 보거나 Facebook을 통해 친구와 커뮤니케이션할 때에도 플래시가 필요합니다.

현재로선 플래시를 소유하고 있는 어도비는 최소한 플래시 프로그래머가 애플의 앱 스토어를 통해 자신이 개발한 컨텐츠나 애플리케이션을 제공할 수 있도록 몇 가지 툴을 출시하고 있다고 말하고 있습니다. 이것도 애플의 축복이 있어야 가능할 것입니다. 그러나 애플은 미래의 웹 표준은 독점적인 플래시를 대체하게 될 것이라고 주장하고 있습니다. 이것은 지켜봐야 할 일입니다. 플래시는 현재 전세계 95%의 PC에 설치되어 있어 하루 아침에 웹 표준이 바뀔 가능성은 극히 희박합니다. 또한 파이어폭스(Firefox) 같은 브라우저 제작업체 모두가 애플이 말한 새로운 표준과 생각을 함께 하고 있는 것도 아닙니다.

더 크게 우려되는 바는 여기에 있습니다. 애플이 이러한 무모한 목표로 인해 자사의 모바일 디바이스 사용자층을 확대하여 단지 더 많은 사용자가 아이튠즈만 이용하도록 사용자를 가두는 “네트워크 효과”의 매혹적인 유혹에 무릎을 꿇을 수 있다는 점입니다. 애플은 최근까지 제휴 관계를 유지했던 구글(Google)과 전면전에 돌입했습니다.

지난달 말 애플 직원과의 미팅에서 스티브 잡스가 “지금까지 애플은 검색 시장에서 구글과의 경쟁을 피하기 위해 노력했지만 ‘아이폰 타도’ 를 위해 자사의 모바일 디바이스르 출시했다.” 면서 “사악해지지 말자(Don't be evil) " 라는 구글의 모토를 폄하한 발언이 일파 만파 퍼졌습니다.

구글폰으로 인해 아이폰이 없어지지는 않을 것입니다. 시장은 수많은 모바일 디바이스를 수용할 수 있는 여건을 충분히 갖추고 있습니다. 그러나 실제 위협이 되는 것은 수천만 명의 소비자를 앱 스토어인 아이튠즈만 이용할 것을 주입시킬 수 있는 애플의 능력입니다. 구글이 아이패드가 공개되기 며칠 전 자사의 슬레이트 모양의 디바이스 모델을 발표한 것은 의미 있는 행보였습니다. 구글의 모바일 디바이스는 플래시를 지원하고 있습니다. 애플 사용자가 사용할 수 없는 비디오 및 기타 웹 기능을 사용자가 구매하거나 사용할 수 있도록 했습니다.

애플이 아이폰에서 구글을 대체하기 위해 마이크로소프트의 검색 엔진인 빙(Bing)과 거래를 고려하고 있다는 소문이 돌고 있습니다. 또한 애플이 광고 사업에도 뛰어들어 구글의 서비스와 경쟁하기 위해 클라우드 서비스를 확대할 것이라는 소문도 들리고 있습니다. 어디서 많이 들어본 스토리 아닌가요?

네트워크 효과는 권력과 부를 가져오는 방법이 될 수는 있지만 마이크로소프트의 사례에서 볼 수 있듯이 너무 많은 성과는 특권의 지위를 유지하기 위한 방어적이고 망상적 시도로 인해 물거품이 될 수 있습니다. 회사의 최고 심미가이자 완벽주의자가 더 이상 정상적인 의사 결정을 내리지 못하게 되면 과연 애플은 어떤 회사가 될 것인지 많은 전문가들은 의문을 가지고 바라보고 있습니다. 애플이 점점 더 많은 사용자들에게 아이튠즈 앱 스토어만 사용할 수 있는 질이 나쁜 디바이스를 출시하는 회사로 전락되지 않을까 우려되는 바입니다.

- 번역: adobe korea

원문:
Apple is in danger of becoming preoccupied with zero-sum maneuvering versus hated rivals.

Don't look now but this may be the year when Apple's market cap does the unthinkable and surpasses Microsoft's. Congratulations will be in order but so will condolences. For a company preoccupied with products is in danger of becoming a company preoccupied with strategy. And by "strategy," we mean zero-sum maneuvering versus hated rivals.

Oh well, it's a fallen world we live in.

Take the iPad, which instantly shed the moniker "Jesus tablet" once it saw the light of day. It's a blown-up iPod Touch, rolled out not to be insanely great but to give Apple an entry in the netbook derby. The iPad may not be the best Web-browsing machine simply because Apple refuses to support Flash, which delivers 75% of the video on the Web. But the iPad (an anagram for paid) looks like a good device for consuming the e-books, music and video sold through Apple's online service. In fact, let's not mince words: The iPad looks like a device optimized to patronize the iTunes store.

And what about Apple's decision to exclude Flash? Apple and its supporters stake out aesthetic and philosophical grounds: Flash is buggy. Flash is a power hog. Flash is "proprietary" (horrors). Flash is used to create those annoying Web ads (never mind that advertising is what pays for most of the Web).

Uh huh. Flash would also allow iPhone and iPad users to consume video and other entertainment without going through iTunes. Flash would let users freely obtain the kinds of features they can only get now at the Apple App Store.

We hasten to add, before the net-neut crazies and antitrusters seek to perp-walk Steve Jobs, that Apple is perfectly within its rights to do so. But the thing to notice is that Apple is making a strategic choice to cut off its users from a huge amount of Web content. We'll leave Flash's acolytes to defend it against charges of bugginess, etc. Flash has been amazingly successful in crowding out other video players and amazingly successful in getting perhaps a billion PC users to download regular updates. If you want to watch TV shows at Hulu.com or baseball at MLB.com or play games at Facebook, you need Flash.


For now, Adobe, owner of Flash, says it's issuing tools to allow Flash programmers at least to offer their creations through the App Store (provided Apple gives its blessing). Apple insists a forthcoming Web standard will replace the proprietary Flash anyway. We'll see. Flash is installed on 95% of PCs, so its displacement won't happen overnight. And not all browser makers (e.g., Firefox) are on-board with the new standard.

Here's the bigger worry. Apple may be succumbing to the seductive temptations of "network effects," in which the all-consuming goal becomes getting its mobile devices into more and more hands simply for the purpose of locking more and more users into iTunes. Enter nemesis in the form of Google, a company with which Apple was recently allied.

Widely circulated have been remarks by Mr. Jobs at a meeting with Apple employees late last month in which he unceremoniously dumped on Google's "don't be evil" mantra. Apple had played nice, he reportedly said, steering clear of competing with Google in search, while Google traitorously plotted to launch its own mobile devices in order to "kill the iPhone."

Google won't kill the iPhone. The market is plenty big enough to support lots of mobile devices. What's really threatened is Apple's ability to keep convincing tens of millions of consumers to lock themselves into iTunes., the App Store, etc. Not for nothing Google flaunted a mockup of its own slate-like device a few days before the iPad unveiling. And Google's mobile devices support Flash—i.e., they allow users to patronize the video and other Web goodies that Apple users can't.

Rumors abound that Apple is considering a deal with Microsoft's search engine Bing to displace Google on the iPhone. Rumors abound that Apple will get into the advertising business, that it will expand its cloud services to compete with Google's. Who is this beginning to sound like?

Network effects can be a path to power and riches, but (as Microsoft has shown) much of the proceeds can also end up being squandered on defensive and paranoid attempts to secure the privileged position. Pundits have wondered what might become of Apple once its chief aesthete and perfectionist is no longer calling the shots. An Apple that rolls out increasingly junky devices merely to lock more and more customers into the iTunes-App Store mall is one gloomy possibility.


- 본인은 Kevin Lynch의 인터뷰 내용을 모두 수용할 수 없지만 현재 시장 상황에 대한 객관적인 주장과 우려가 담겨 있다고 생각한다. 물론 단적으로 "그럴 것이다"라는 내용에는 일부 선급한 판단일 수도 있을 것이다. IT에서의 표준이란 무엇인가에 대한 정의를 본인은 솔직히 모르겠다. 

- 표준이란?
1. 독점하지 않는 기술?
2. 이해관계가 투명하고 나누워 가질 수 있는 기술?
3. 이미 보편적으로 사용하고 있는 기술?
4. 돈을 받고 팔지 않는 기술?
5. 대체할 만한 기술이 없는 환경?
6. 거대한 기업에서 언급한 표준?
7. 계속적으로 투자할 수 있고 그 가치를 인정하는 기술?


    

설정

트랙백

댓글

스티브잡스의 발언과 플래시의 방향

Programming/Etc 2010. 2. 4. 11:51

Adobe CTO Kevin Lynch 가 Apple 디바이스에 플래시가 탑재하지 않는 것에 대하여 Adobe의 입장을 담았다.

원문 : http://blogs.adobe.com/conversations
/2010/02/open_access_to_content_and_app.html


컨텐츠 및 애플리케이션에 대한 오픈 액세스
게시자: Kevin Lynch, CTO

최근 출시되고 있는 우수한 디바이스에 Flash Player가 탑재되어 있지 않다는 사실에 적잖이 놀랐을 것입니다.
본래 Flash는 시장이 형성되지 않았던 약 15년 전에 펜(Pen) 컴퓨팅 태블릿을 위해 고안되었습니다. 초창기에는 낮은 대역폭의 벡터 그래픽을 지원했지만 지난 십여 년간 새로운 기능을 빠르게 추가해 나가면서, 웹의 틈새 시장을 공략했습니다. 현재는 새로운 활용 방안을 찾는 데 노력을 기울이고 있습니다. 일례로 웹상에서의 애니메이션, 스트리밍 오디오, 풍부한 인터랙션, 임의의 폰트, 양자간 오디오/비디오 커뮤니케이션, 로컬 저장소, 혁신적인 비디오 전달 등이 있습니다.

HTML 기능이 추가된 Flash는 상당히 높은 채택율을 기록하고 있는 가운데, 상위 웹 사이트의 85% 이상에서 Flash 컨텐츠를 사용하고 있으며, 인터넷이 연결된 컴퓨터의 98% 이상에서 Flash가 실행되고 있습니다. Flash는 웹상의 대부분의 캐주얼 게임, 비디오 및 애니메이션에 사용되고 있으며 Nike, Hulu, BBC, Major League Baseball 등 유명 브랜드에서 Flash를 사용하여 10억 이상에 달하는 전세계 사용자에게 매력적인 경험을 전달하고 있습니다.

Flash의 미래에 있어서 지금이 가장 중요한 시기입니다. 현재 PC 외에도 다양한 디바이스들이 하루가 다르게 출시되고 있으며, 많은 수의 디바이스가 인터넷 검색에 사용될 것입니다. 따라서 컨텐츠 및 애플리케이션 제작자와 사용자는 PC에서 Flash를 통해 얻어질 것으로 기대되는 경험, 즉 원활하고 일관되며 풍부한 경험을 디바이스에도 동일하게 전달하기 위해 많은 과제들을 해결해야 할 것입니다. Flash 엔지니어링 팀은 이를 실현하기 위해 다양한 디바이스에서 Flash Player를 철저히 분석해 왔습니다.

이러한 노력의 결과로 Adobe는 시장 선도적인 제조업체를 대상으로 한 스마트폰용 Flash Player 10.1을 선보이려고 합니다. 이러한 제조업체에는 스마트폰 뿐만 아니라 태블릿, 넷북, 인터넷 TV 등 시장을 형성하고 있는 Google의 Android, RIM의 Blackberry, Nokia, Palm Pre, 기타 업체들이 있습니다. Flash를 통해 고객은 전체 웹을 검색할 수 있으므로 브라우저에서 Flash를 사용하고 있는 이러한 디바이스는 경쟁력을 갖추게 됩니다. 이는 사실상 오픈 스크린 프로젝트(Open Screen Project)를 통해 이루어지고 있으며, Adobe는 50여 이상의 파트너와 협력하면서 다양한 디바이스에서 이를 실현하기 위해 노력하고 있습니다. 예를 들어, 최근 선보인 구글 넥서스원(Nexus One)은 Flash Player 10.1을 통해 탁월한 브라우저 경험을 선사할 것입니다.

그렇다면 Apple 디바이스에서 실행 중인 Flash는 어떨까요? Adobe는 Flash 기반으로 iPhone용 독립 실행형 애플리케이션을 구축할 수 있게 함으로써, Flash 기술은 이러한 디바이스에서의 사용을 넓혀 나가기 시작했습니다. 실제로 이러한 애플리케이션 중 일부는 FickleBlox, Chroma Circuit과 같은 Apple App Store(앱스토어)에서 이미 제공되고 있습니다. 이 동일한 솔루션은 iPad에서도 작동될 것입니다. Adobe는 이러한 디바이스의 브라우저에서 Flash를 지원하기 위한 준비를 마친 상태이며 이제 Apple에서 사용자를 위해 이를 허용하는 것만이 남아 있습니다. 그러나 Apple은 지금까지도 어도비의 이러한 협력 요청을 받아들이지 않고 있습니다.

장기적으로 볼 때, Flash에 대한 요구 사항을 대신하게 될 것으로 HTML이 꼽히고 있는 데, 특히 최근 개발된 HTML 5 버전이 출시되면 그 움직임은 본격화될 것으로 전망하는 사람들이 많아지고 있습니다. 그러나 오늘날은 물론이거니와 앞으로도 한 기술이 다른 한 기술을 대체하게 되지는 않을 것으로 예상됩니다.

Adobe는 HTML의 발전을 지원하고 있습니다. 앞으로 HTML이 진화를 거듭할수록 Adobe 소프트웨어에 더 많은 기능이 추가될 것으로 기대하고 있습니다. HTML이 Flash의 기능을 안정적으로 수행할 수 있다면, Adobe는 많은 시간과 수고를 덜 수 있지만, 사실상 그렇게 될 가능성은 거의 없습니다. 비디오 부문의 경우 현재 웹상에 있는 비디오의 75% 이상에서 Flash가 사용되고 있는 데도 불구하고, 브라우저 간 포맷 통일이 이루어질 수 없으므로 사용자와 컨텐츠 제작자는 비호환성이라는 문제를 안게 되고 결국 HTML 비디오 구현은 어두운 뒤안길에 남겨질 것입니다.

HTML의 진보에도 불구하고 Flash의 생산성과 표현 기능은 웹 커뮤니티에서 가희 독보적이라고 할 수 있습니다. Flash 팀은 지난 십여 년간 불가능하다고 여겼던 경험을 구현해 왔던 것처럼 앞으로도 더욱 혁신에 박차를 가할 것입니다. 1년도 채 안 되는 짧은 시간 동안 대다수의 웹 클라이언트를 업데이트할 수 있었던 Flash는 다양한 브라우저 전반에 걸쳐 HTML이 수행하는 것보다 훨씬 빠른 시간 내에 고객에게 이러한 혁신 기술을 선보일 수 있을 것으로 기대를 모으고 있습니다.

Adobe는 시간, 장소, 매체에 구애 받지 않고 아이디어와 정보를 생성하고 전달할 수 있는 방식을 혁신하고 있으며 디자이너와 개발자가 자신의 독창적인 아이디어를 마음껏 펼칠 수 있는 방법을 고안해 내는 데 전력을 다하고 있습니다. 또한 가장 생산성이 우수한 툴과 컨텐츠 및 애플리케이션을 배포할 수 있는 광범위한 기능을 창의적인 관리 방법과 접목시키는 것 또한 Adobe의 미션이라고 할 수 있습니다. Adobe는 고객이 목표를 달성하고 기술 격차를 극복할 수 있는 기술 혁신을 이뤄내는 데 필요한 모든 기술과 포맷을 지원하고 있습니다. Flash와 HTML이 결합되면 최고의 기술이 탄생하게 될 것입니다. 그렇게 되면 누구나 웹상에서 이 기술을 사용하여 최상의 경험을 제공할 수 있게 될 것입니다.

아이디어와 정보를 활용하는 것은 사용자가 선택한 컨텐츠와 애플리케이션을 보고 서로 인터랙션할 수 있는 개방된 에코시스템과 자유가 존재한다는 것을 의미합니다. 이 오픈 액세스 모델은 가장 효율적인 모델로 그간의 여러 시행착오를 거쳐 그 효과가 입증되었습니다. 이와 반대로 폐쇄 모델에서는 사용자가 개별 컨텐츠와 애플리케이션을 보거나 승인 및 거부할 수 있는 사항을 제조업체에서 결정하려고 했습니다. 웹은 디바이스에 상관없이 컨텐츠와 애플리케이션을 일관되게 액세스할 수 있는 개방된 환경으로 존재해야 한다는 데는 이견이 없을 것입니다.

Adobe는 고객들이 최상의 업무 성과를 달성하고 운영 체제, 브라우저 및 다양한 디바이스 전반에 걸쳐 효과적이고 안정적으로 전세계 모든 사용자에게 다가갈 수 있도록 지속적으로 지원해 나갈 것입니다.

번역 : adobe korea


아래 김국현님이 ZDnet에 올린 컬럼 내용이 공감이 갑니다. "후발주자의 입장에서 선두주자에게 타격을 입히는 가장 쉬운 방법은 게임의 룰을 바꿔 버리는 것이다."

http://www.zdnet.co.kr/Contents/2010/02/04/zdnet20100204092647.htm



    

설정

트랙백

댓글

네이트 앱스토어 공모전

Programming/Etc 2009. 10. 30. 20:39

요즘 프로젝트 일정으로 많이 바쁜 생활을 하고 있지만 플래시 개발자들에게 재미있는 서비스를 하나 소개할까 합니다. 소개하고자 하는 서비스가 공교롭게도 네이트 서비스입니다만, ^^ 그렇기 때문에 소개하는 것은 아닙니다. 플래시 개발자들에게는 재미있는 경험이 될 수도 있을 것 같고, 더 나아가서는 개인적으로 개발한 어플리케이션으로 수입을 창출할 수도 있는 서비스이기에 소개를 합니다.

네이트에 접속해 보시면 앱스토어라는 개발자 놀이터가 생겼습니다. 네이트 앱스토어는 쉽게 말해서 사용자의 정보(본인 개인정보, 일촌 정보 등등)을 이용하여 다양한 어플리케이션을 만들 수 있습니다.




간단한 예를 들면, 게임을 진행하고 본인의 랭킹과 일촌들의 랭킹을 확인할 수가 있고, 일촌에게 도전장을 발송할 수도 있습니다. 플래시는 웹에서 접근하기에 간단하면서도 중독성이 강한 게임들을 만들 수 있는 좋은 툴이죠, 물론 게임뿐만이 아니라 OpenAPI로 제공하는 데이터들을 활용하여 다양한 어플리케이션을 만들고 싸이월드의 수많은 사용자들과 함께 참여할 수 있습니다.

소셜 네트워크를 이용하고, 페이먼트 시스템(도토리)을 적용하여 만든 게임으로 수입이 발생할 수도 있습니다. 네이트 앱스토어가 서비스를 라이브한지 얼마 되지 않은 beta 서비스이지만, 현재 페이먼트 시스템을 적용한 게임의 경우 하루에 적지 않은 수입이 발생하고 있다고 합니다. 개발자의 말초신경을 자극하는 대목이지요^^

네이트가 소셜 네트워크를 이용하여 개발자들이 놀 수 있는 공간을 만든 것은 개인적으로 바람직한 현상(!) 이라고 생각합니다.

이번에 2009년 제1회 네이트 앱스토어 앱스 공모전이 있습니다. 이에 맞춰서 제2회 개발자 세미나(Hello, Dev.Square)가 진행될 예정이라고 합니다. 현재 아래 경로에서 선착순으로 모집을 하고 있으니 관심이 있으신 분들은 참여해 보시기 바랍니다.

2009 제 1회 네이트 앱스토어 앱스 공모전

1. 참가 대상
   - 대학생, 직장인 등 개인자격으로 참여 가능.
   - 팀을 구성할 수 있으며 팀 제한은 4명 이내로 함

2. 시상 내역


3. 진행 일정
   - 앱스 제작 설명회 : 2009년 11월 12일 [시간/장소 별도 공지예정]
   - 앱스 접수 : 2009년 12월 12일~12월 21일
   - 심사 : 2009년 12월 22일~ 12월 29일
   - 발표 : 2009년 12월 30일
   - 시상 : 별도 공지
 
4. 접수 방법
   - http://devsquare.nate.com 통해서 접수
   - OpenSocial API v0.81기반으로 앱스 개발
   - 필수 활용 API : 친구목록 API

5. 심사 기준
    (앱스가 꼭 복잡할 필요는 없어요! 간단할수록, 그래서 쉽고 재미있다면 많은 점수를 받을 수 있습니다.)
   - Social Network를 활용하여 일촌들이 함께 즐길 수 있는가?
   - 앱스 이용방법이 쉽고 간단하여 누구나 쓸 수 있는가?
   - 재미있고 유쾌한 사용 경험을 제공하는가?
   - 아이디어가 얼마나 새롭고 창의적인가?
=========================

앱스토어 관련 정보 경로

네이트 앱스토어 섹션페이지
http://appstore.nate.com/

개발자 등록 및 개발 가이드 페이지
http://devsquare.nate.com/

Dev.Square Forum_앱스정복을 꿈꾸는 개발자 세상
http://club.cyworld.com/club/main/club_main.asp?club_id=53489290

저도 시간이 허락된다면 좋은 아이디어가 있을 때마다 실행해볼 예정입니다.

    

설정

트랙백

댓글

ACC(Adobe Community Champion)

Programming/Etc 2009. 1. 22. 20:40


기존에 플렉스 개발자로만 구성되었던 ACC(Adobe Community Champion)가 adobe flash platform으로서 플래시, 플래시 라이트, 플렉스가 통합되어 활동하게 되었습니다. 송구스럽게도 실력 있는 분들과 함께 임명장을 받게 되어 스스로 소식을 전하는 것이 조심스럽습니다. 앞으로도 더욱 많이 배워야 하는 저이지만 임명장을 받은 마당에 의무감도 없지 않은 듯싶어서 소식을 전합니다.

임명식이 있던 날, 회사 업무로 부득이하게 참석을 하지 못하였는데, 마음을 담은 카드까지 전달해 주셨네요. Adobe ACC 관계자 분들에게도 감사를 전합니다.

제가 격식에 따라 활동하는 타입은 아니지만 앞으로 꾸준히 활동하도록 하겠습니다. 다소 부족한 부분이 있더라도 배우는 자세로 이해해 주시고 잘못된 부분이 있으면 서슴없이 말씀해 주시면, 앞으로 ACC 활동을 통해서 또 다른 진정한 커뮤니티 챔피언을 발견할 수 있지 않을까 생각해 봅니다.

감사합니다.

    

설정

트랙백

댓글

수퍼개발자의길 - 나눔과 교육으로 날아라

Programming/Etc 2008. 9. 8. 01:02

[수퍼개발자의 길 ③] 나눔과 교육으로 날아라

상훈형님의 블로그에 방문했다가 보게 된 칼럼이다. 사실 본인 또한 자수라는 이름으로 본인에 대해서 잘 모르는 분들의 찬사를 듣기도 했던 것 같다. 하지만 가만히 생각해 보면 과연 내가 그러한 찬사를 받을 만한 실력과 인내심을 가지고 있는지에 대해서 되묻지 않을 수 없다.

블로그를 통해서 소통을 한다고는 하지만 과연 나에 대해서 모든 것을 들어내고 순수한 마음으로 전달하고 소통하기를 바라고 있는지 모르겠다. 사실 요즘 들어서 나의 개발 성향과 가치관에 많은 의문을 제기했었다. 내가 생각하는 것이 과연 옳은 것인가, 무엇보다도 나에게 득이 없더라도 실이 되면 어쩌나 하는 두려움이 크지 않았을까 하는 생각도 든다.  그 동안 순수성을 상실한 이득에만 초점을 맞춘 소통을 하고 있지는 않았는지 반성하게 된다.

목표 보다는 과정이 중요하다는 말의 의미를 이 칼럼을 통해서 느끼게 된다. 만약 앞으로 그러한 두려움에 나눔을 실천하지 않는다면, 나는 현재로부터 더 이상 발전하지 않았다고 판단 하는 것이 옳을 것이다.

단순히 오늘의 충족보다 내일 느끼게 될 스스로의 만족에 더 충실한 내가 되기 위해서 더욱 노력해야 하겠다.
    

설정

트랙백

댓글

콜린무크의 「지금부터 시작한다 ActionScript 3.0 - WORLD WIDE TOUR 」

Programming/Etc 2007. 11. 7. 00:54
일본 adobe에서는 세계적으로 저명한 콜린무크의 ActionScript 3.0을 위한 1일 집중 트레이닝(무료)에 참가자를 모집하고 있다고 한다. 이 1일간의 트레이닝에서는 무크의 베스트셀러인 ssential ActionScript 3.0(O'Reilly, 2007)에 근거하고 Flash Player및 Adobe AIR의 프로그래밍에 필요한 기본적인 스킬을 습득한다고 한다.
토픽은 객체지향프로그래밍, 클래스, 오브젝트, 변수, 메소드, 패키지, 조건 제어, 루프, 연산자, 함수, 이벤트 핸들링, 화면상에서의 표시, 프로그램의 컴파일 및 실행 등과 관련된 내용이다.

학습 내용
    * 오브젝트 프로그래밍의 모든 주요 개념
    * 클래스 및 오브젝트의 이해
    * ActionScript 3.0프로그램의 구축 및 기술 방법
    * Flex Builder 2의 개발 환경
    * ActionScript3.0주요 개념의 리뷰

일정 :
2008년1월15일(화)     9:30개장 10:00-19:00     300명
사용자 삽입 이미지

MAX 레퍼런스가 한국에서 개최되지 않았던 것도 아쉬운 마당에 이런 군침 도는 기회조차 일본에 빼앗긴 것 같아서 아쉽다. 하루 동안에 얼마나 많은 지식을 얻을 수 있겠냐고 이야기 할 수도있지만 그 느낌만으로도 충분한 가치가 있는 자리가 아닐까 싶다.

일본에 계시거나 일본에 가는 분들은 신청을 해보시길….

http://www.event-web.net/as3/
    

설정

트랙백

댓글

ActionScript는 프로그래밍 언어가 아니다.

Programming/Etc 2007. 11. 4. 19:21
인터렉션 UI개발과 그 목적을 위해서 사용하고 있는 ActionScript는 프로그래밍 언어가 아니다. 내 천직으로 생각하고 지금 하고 있는 업무가 그것이지만 ActionScript를 프로그래밍 언어적 차원에서 접근 하는 것에는 한계가 있다고 생각한다.

플래시라는 것은 기술적인 환경이나 배경지식 보다는 아이디어가 중요하다. 이러한 아이디어는 다양한 결과물을 만들어 낼 수 있다. 물론 그 아이디어는 어느 정도의 배경 지식이 있어야 하겠지만 없어도 무방하다. 가령 내가 어떤 비주얼을 보고 머리 속에서 그린 인터렉션을 구현하기 위해 작업에 착수 했다고 하자, 내가 필요로 하는 편리한 기능이 플래시 안에 내제되어 있지 않더라도 자신이 가지고 있는 지식 범위 안에서 찾을 수 있는 길은 있을 것이다. 이것이 플래시를 즐기는 사람들의 즐거움이자 정석이다.

플래시로 작업을 하다 보면 자신도 이 방법이 정석인지 아닌지 알 수 없는 경우가 있다. 그래서 작업이 끝나고도 뒤 끝이 어수선한 경우가 종종 발생하게 되는데, 어찌보면 플래시 작업에서의 정석은 없을 수도 있다. 이미 플래시에 탑재 되어 있는 내장 클래스를 모르더라도 그와 유사한 기능을 하는 것을 만들어 낼 수도 있고 전혀 다른 방법으로 문제를 풀어 낼 수도 있다.

그 과정에서 파생된 또 다른 아이디어는 다시 싹을 틔우고 꽃이 피어나는 결과로 진행 될 수도 있다. 하지만 플래시를 프로그래밍 언어적 개발 마인드로 접근을 하다 보면 정석만이 있으며 그것이 유일한 방법이라는 확신에 사로잡혀서 크리에이티브한 창의를 발휘할 수 있는 여지를 묵살하게 된다.

나는 작업을 하면서 엉뚱하며, 디자인 표현에 맞지 않는 결과물들도 많이 만들어 낸다. 남들 보다 같은 결과물을 얻기 까지 시간이 많이 걸리지만 작업 과정에서 떼 묻은 코드들은 또 다른 나의 아이디어로 언젠가는 도움이 되는 것 같다.

현재 플래시를 공부하고 관심을 갖고 있는 분들은 이러한 즐거움을 느꼈으면 좋겠다. 설계, 개발이라는 단어보다는 디자인이라는 단어가 어울리는 플래시는 프로그래밍 언어가 아니라 크리에이티브 언어이다.

    

설정

트랙백

댓글

[에디터] Eclipse 플러그인 FDT 3.0

Programming/Etc 2007. 10. 17. 00:14
Flash 5.0 이전에는 특별히 코딩을 위해 따로 에디터를 사용할 필요성을 느끼지 못했다. 하지만 7.0으로 넘어오면서 ActionScript가 강화되었고, 코딩하는데 있어서 플래시 툴 자체에서 지원하는 에디터 화면으로는 불편한 점이 많았다. 그래서 예전에는 플래시 액션스크립트를 코딩 할 때, 주로 sepy를 사용하다가 요즘은 FlashDevelop 프로그램을 사용하고 있다. 둘 모두 무료 소프트웨어 이기 때문에 사용하는 것도 있지만 플래시툴에서 지원하는 에디터보다 사용성에 있어서 편리한 점이 많기 때문이다.

오늘 블로그를 돌아다니다가 Powerflasher.com에서 FDT 3.0 이라는 아주 훌륭한 상용 Eclipse 플러그인이 3.0으로 릴리즈 되었다는 정보를 알게 되었다. FDT는 예전에 땡굴이님이 배타테스터로 블로그에 포스팅 한 글을 읽어보긴 했지만 사용성에 있어서 얼마나 많은 편의를 제공하는지는 잘 알지 못했다.

아래 경로로 접근하면 FDT 사용방법에 대한 동영상을 볼 수 있다.

FDT 3.0 Basic
http://fdt.powerflasher.com/uploads/Media/liveCodeGeneration.htm

FDT 3.0 Professional
http://fdt.powerflasher.com/uploads/Media/formatter.htm

사용자 삽입 이미지 사용자 삽입 이미지 사용자 삽입 이미지



    

설정

트랙백

댓글

Flash Player 10 코드네임 Astro

Programming/Etc 2007. 10. 2. 18:28
Astro 코드네임으로 불리고 있는 Flash Player 10의 신기능 중에서 몇 개가 미국 시카고에서 개최한 MAX 컴퍼런스에서 공개되었다는 소개글이 있어서 포스팅한다. 공개된 내용은 아래와 같다.

1.새로운 텍스트 레이아웃 엔진
Astro에서는 향상된 새로운 기능의 텍스트 표현 엔진이 탑재될 예정이라고 한다. 이를 통해서 복수 컬럼의 레이아웃이나 이미지를 자동적으로 감싸는 레이아웃, 그리고 테이블 형식의 레이아웃 등이 가능하게 될 것 이라고 한다.

2. 3D 효과
Flash의 무비 클립을 3D 공간 내에서 취급할 수 있는 기능이 제공될 예정이라고 한다. PaperVision3D나 Away3D등과 같은 엔진이 탑재 되는 것은 아닌 것 같지만 표현의 폭이 다양해짐에 따라서 추가적인 3D엔진에 대한 기능 개선이 있을 것으로 기대되는 대목이다.

3.custom 필터, 브랜드, 효과
Flash Player 8 버전부터 추가되었던 필터기능에서 추가적으로 스스로 작성한 필터나 효과를 사용할 수 있게 될 예정이라고 한다. 필터등의 작성에는 Adobe Image Foundation (AIF) 툴킷을 사용하게 되는데 AIF 툴킷은 프리뷰판을 다운로드할 수 있게 되어 있다. 관심이 있는 분은 아래 경로에서 다운 받아서 사용해 보길 바란다.

(Adobe Image Foundation (AIF) Toolkit@Labs )



Flash Player 10의 릴리즈 시기는 아직 미정이라고 한다.


    

설정

트랙백

댓글

[스크린세이버] 바람과 데스크탑

Programming/Etc 2007. 9. 19. 04:16
웹 서핑중 재미있는 스크린세이버가 있어서 소개한다. 사내 프로젝트 일환으로 작업 했다고 하는데 발상이 재미있다. 플래시 AIR을 이용하여 데스크탑의 이미지를 비트맵데이타로 크롭하여 모션 효과를 준 듯하다. AIR을 이용하면 다양하고 기발한 결과물들을 만들 수 있지 않을까 싶다. 3.0에 어느정도 익숙해 지면 취미로 AIR도 접해봐야 겠다...

이 스크린세이버는 재미있기는 하지만 컴퓨터가 쉬어야할 시간에 너무 많은 일을 하고 있다. 화면 보호도 중요하지만 CPU가 너무 바쁜거 아닌지...

스크린세이버 제작자
프로그램 전반:키타무라 케이태
디자인/플래시:하나무라 타로
원안:사카이회리가
디렉션:나카무라 이사무오

프로젝트 임시 홈페이지 : http://scr.sc

트라이얼 버전 프로그램 :



    

설정

트랙백

댓글

플래시 게임 Budapest defenders

Programming/Etc 2007. 8. 26. 19:15
게임 장르를 잘모르지만 이런 장르를 전략시물레이션 게임이라고 하지 않나 싶다. 간단한 스토리지만 플래시 전략 보드게임으로서는 매력적이다.













http://alt.tnt.tv/tntoriginals/thecompany/budapestdefenders/index.htm

사용자 삽입 이미지





    

설정

트랙백

댓글

연말에 등장하는 FlashPlayer9 update3에서 실현되는 기능 향상이란?

Programming/Etc 2007. 8. 7. 05:55
퍼포먼스 향상에 주력 한 업데이트

2006년 6월에 발표된 flashPlayer9는 flash CS3 시대를 예감 시키는 중요한 내용을 포함하고 있었다. FlashPlayer9는 올 연말에도 대폭적인 업데이트를 예정하고 있다고 한다. Flash나 ActionScript의 향후를 예측하는데 있어서 중요한 FlashPlayer9 update3의 개요에 대해서 Adobe Systems사 FlashPlayer담당 그룹 프로덕트 메니저 Emmy Huang의 이야기다.

Update3은 주로 퍼포먼스 향상에 주력하고 있어 다양한 신기능의 추가나 기능 강화를 도모하고 있다고 한다. 또 이번은 크로스 플랫폼에서 제공하는 것을 중시하고 있고 처음으로 Windows/Macintosh/Linux판을 동시에 출시 한다고 한다.

추가되는 새로운 기능으로서는 크게 나누어 4개가 있는데, 우선 첫 번째로 거론되는 것이 하드웨어의 가속화에 의한 풀 스크린 모드이다.(예전에 포스트로 올려 놓은 것이 있는데 동영상을 위해서 기초적인 기능만을 첨부한 swc파일 컴포넌트로 복사해야 한다)  update3은 하드웨어 스켈링을 하기 위한 랜더링 속도를 향상하여 고해상도인 브라우저상에서 재생하고 있는 동영상을 부드럽게 재생할 수 있는 것이 특징이라고 한다. 물론 종래의 버전에서도 풀 스크린을 서포트하고 있고 고해상도의 동영상을 재생할 수 있었지만 컴퓨터의 처리 능력이 높지 않으면 재생이 어려웠던 것이 사실이다. 그러나 update3에서는 보다 많은 머신으로 고해상도의 동영상을 풀스크린으로 재생 할 수 있다. 『웹 브라우저로 이만큼의 HD 퀄리티의 영상을 제공할 수 있는 것은 adobe에 있어서도 매우 익사이팅한 일입니다』 라고 FlashPlayer 그룹 프로덕트 매니저의 Emmy Huang의 이야기다.

리치 인터넷 어플리케이션 관련 기능 강화


이 밖에도 리치 인터넷 어플리케이션 관련해서도 기능 강화가 있다고 한다. Adobe 플랫폼 컴포넌트에 추가된 새로운 플레이어의 캐시는 플랫폼 라이브러리를 포함하는 장소에서 정확히 브라우저 캐시와 같이 한 번 다운로드를 해 저장하면 두 번째에서는 곧바로 사용할 수 있게 된다고 한다. 이 기능을 우선 최초로 활용하는 것은 Flex 체제라고 한다. 약 500KB 정도의 Flex 파일을 캐시  시키는 것으로 swf파일의 사이즈를 작게 하는 것과 동시에 start up 시간을 단축할 수 있다고 한다. 현재 adobe labs에서 베타판을 다운로드하여 이 기능을 사용해 볼 수 있다. 미래지향적으로 라이브러리를 추가해 나가기 때문에 캐시를 사용해 다양한 작업을 시도할 수 있을 것이라고 이야기한다.

또 Flash와 브라우저와의 통신에 사용하는 API가 있지만 이 커뮤니케이션도 개선되고 있다고 한다. 즉 브라우저의 컴퍼넌트와 FlashPlayer의 통합, 인터그레이션이 보다 좋아지고 있다고 한다.

그 외의 추가 기능은 아래와 같다.

Internet Exploler(IE)에 보안 관련 API가 서포트 되고 있었지만 Windows 플러그인 외에 FireFox에도 서포트 된다는 설명이다.

Flash Media Server(FMS)에 전달되는 컨텐츠의 보호를 할 수 있도록 RTMP 프로토콜로 암호화가 서포트 된다고 한다.

    

설정

트랙백

댓글

물리를 좋아하는 사람들...

Programming/Etc 2007. 8. 4. 11:19
MIT sketching라는 제목으로 youtube에 올라와 있는 동영상이다. 물리 역학을 이용한 스케치 어플리케이션을 설명을 하고 있는데 결과물도 결과물이지만... 순간 머리속으로 이게 가능한가하는 생각마저 든다. 실행 화면과 설명하는 그림이 다른거 아닌가 했었는데 역시나 .... MIT 두뇌 집단 훌륭하다...

관련 사이트
http://icampus.mit.edu/MagicPaper/













    

설정

트랙백

댓글

ferryhalim.com의 플래시 게임

Programming/Etc 2007. 7. 30. 06:25
사용자 삽입 이미지

은근히 중독성이 강하다... 당신의 순발력은? ^^

http://www.ferryhalim.com/orisinal/g3/bells.htm
    

설정

트랙백

댓글

플래시의 CPU 문제에 대한 단상

Programming/Etc 2007. 7. 29. 06:13
플래시를 전문적으로 하지 않는 기획자나 다른 개발자의 경우에는 플래시의 CPU문제(버벅거림)에 대해서 막연하게 생각하는 경우가 많다. 플래시의 CPU 사용에 대한 문제는 항상 국내의 화려한 비주얼의 걸림돌이 되곤 한다.

플래시의 CPU 문제는 단적으로 말하면 flashplayer가 한번에 처리해야 하는 계산이 많다는 것을 의미한다. 예를 들면 아래와 같은 경우다.

비주얼 문제
* 복잡한 라운드 처리가 되어 있는 백터 이미지
* 그라데이션이 적용된 백터 이미지
* 알파가 적용된 DisplayObject
* 프레임이 진행하고 있는 MovieClip의 다수 복제
* 큰 사이즈의 이미지(백터 and 비트맵)
* 플래시에서 필터를 적용한 오브젝트의 움직임
...

액션스크립트 문제
* Array의 length
* .연산자
* ["instance name string"] 참조
...

이 밖에도 많은 경우의 수에 의해서 플래시 내에서 처리되는 속도는 차이가 날 수 밖에 없다. 아무리 좋은 디자인으로 표현이 되었더라도 동적인 움직임으로 표현을 해야 하는 플래시 개발자들은 이러한 문제를 항상 안고 작업을 한다.

플래시가 버전업을 하며 날로 발전을 하고 있음에도 그 발전에 대해 충분히 활용하지 못하는 경우가 많은 것 같다. 예를 들면 플래시8 버전부터 추가된 BitmapData, Bitmap 클래스는 ActionScript로 비주얼적인 표현을 할 수 있지만 위에서 이야기한 플래시의 CPU문제를 어느 정도 해결할 수 있는 방법이기도 하다.

플래시 스테이지상에 있는 모든 오브젝트들은 플래시플레이어가 계산해야 하는 영역 안에 있기 때문에 언제든지 CPU의 과부화를 만들어 낼 소지가 있다. 따라서 보여지는 화면 내에 걸쳐있는 모든 오브젝트들의 묘화에 필요한 계산을 줄이기 위해서 BitmapData 클래스를 사용할 수 있다. 

특정 DisplayObject 안에 있는 수많은 오브젝트들을 하나의 DisplayObject로 변환하고 다시 되돌리는 클래스를 만들어 특정 DisplayObject를 하나의 DisplayObject로 변환했다가 그 안에 있는 개별적인 요소의 기능을 사용해야 할 경우에는 원래의 DisplayObject로 변환하여 사용하지 않을때 낭비되는 CPU 문제를 해결할 수 있다.

블로그의 INFINITE의 왼쪽 메뉴의 경우도 위와 같은 방법을 사용한 예다. 마우스를 오버했을 때 메뉴가 나타나고 원래의 오브젝트로 되돌려 버튼을 사용하도록 하고 다시 메뉴 영역에서 마우스를 아웃 했을 때는 하나의 MovieClip으로 대체하여 불필요한 요소를 제거했다.

플래시의 CPU문제와 용량의 문제는 항상 비례하는 것이 아니다. 그리고 파일 용량과 RAM용량 또한  그러하다. 가끔 기획자나 디자이너들이 플래시의 CPU문제 == 파일용량크기 와 결부시키는 경우를 종종 보게 된다.

INFINITE의 메뉴 같은 경우를 보면 원래의 DisplayObject를 되돌려야 하기 때문에 메모리 영역에서 삭제해서는 안 된다. 이 때문에 RAM용량을 줄이는 방법이 아니며 이는 오로지 화면상에 표시되는 오브젝트들로 인해서 flashplayer에 의한 CPU 낭비를 줄이기 위한 방법인 것이다.

요즘은 플래시 개발자와 디자이너가 전문성을 위해서 분업화 되어 있지만 그로 인해서 디자이너들이 플래시에 대한 이해가 부족하여 생기는 문제도 다분히 존재하는 것 같다. 개인적인 생각이지만 국내 웹에이전시에서는 각 분야의 전문성도 중요하지만 작업자 간의 커뮤니케이션에 필요한 기본적인 타 업무에 대한 이해와 교육이 필요한 시기가 아닌가 싶다.

    

설정

트랙백

댓글

한국에서 SW 개발자가 성공하지 못하는 세가지 이유

Programming/Etc 2007. 7. 14. 14:02
소프트웨어 개발자 직종에 대한 회의론적인 얘기가 여기저기에서 들린다. 한때 IT 붐이 일었을 때는 많은 사람들이 개발자를 지망하기도 했다. 하지만 최근 상황을 보면, 신규 유입되는 인력이 아주 적은 편이다. 요즘 젊은이들은 영악해서 이 직종에 비전이 없다는 것을 너무나 잘 알고 있다.

신참 인력뿐만 아니라 고급 인력도 많이 부족하다. 현재의 사회 풍토에서 고급 인력으로 성장하는 것은 결코 쉬운 일이 아니기 때문이다. 그저 사회가 제시하는 길을 따라가다가는 고급 인력이 되는 것이 아니라 퇴출된다.

필자의 경우를 보면, 필자는 정말 프로그래밍이 좋아서 시작한 8비트 키드이다. 중학교 1학년 때 처음으로 컴퓨터를 알게 된 이후로 한시도 컴퓨터와 떨어진 적이 없는 소위 컴퓨터광(geek)이다. 하지만 대학 졸업 후 사회에 나와 첫 직장인 SI 업체에서 일하면서 몇 번이나 눈물을 흘렸다. 이후 프리랜서, 개인회사 창업, 벤처기업, 중소기업, 대기업, 외국계 기업을 두루 걸치면서 현재까지 겨우 살아남을 수 있었다.

만일 그런 인생의 순간순간에서 이를 악물고 분발하지 못한 채 끈을 놓아버렸다면 어땠을까? 정말 아찔한 생각이 든다. 특유의 헝그리 정신으로 인해 겨우 버텼으며 성격도 많이 변했다. 그간 필자 자신 그리고 선배, 동료, 후배들을 보면서 느꼈던 생각을 정리해서 개발자가 성공할 수 없는 이유 세 가지를 꼽아 보았다.

SI 중심의 왜곡된 업계 구조

첫 째, 업계 구조가 SI 중심으로 왜곡되어 있다. 국내의 소프트웨어 산업은 패키지나 솔루션 비즈니스가 제대로 작동되지 않는 상태에서, 대기업 중심의 SI 업체들이 시장을 차지하고 있다. 그 과정에서 산업의 혈액 순환이 잘 되지 않아, 대기업만 돈을 벌뿐 중소기업들은 협력 업체라는 미명 하에 근근이 먹고 살고 있는 형편이다. 통계에 따르면 전체 매출의 80% 이상을, 그리고 영업 이익의 90% 이상을 대기업 계열 SI 업체 상위 3개사가 가져가고 있다.

SI는 소프트웨어 산업을 구성하는 한 가지 요소일 뿐이지만 국내에서는 거의 SI 밖에 없는 수준이다. 그런 상태에서 빅3업체가 모든 것을 가져가고 있으며, 산업 전반에 하청 및 재하청에 따른 죽음의 순환 고리를 형성하고 있다. 그런 생태 구조에서 개발자는 단지 머리 수에 불과할 따름이다. 또한 전문적인 지식에 대한 가치 판단이 제대로 이루어지지 않고 있기 때문에, 소프트웨어 아키텍처까지도 비전문가에게 맡겨지는 경우가 많다.

SI 중심의 산업 구조, 그리고 전문가에 대한 평가 체계가 없고 단지 머리 수에 의해 개발자에 대한 판단이 이루어지는 상황에서 개발자의 성공 사례는 나올 수 없다. 대기업의 협력 업체에서 일하는 많은 개발자들이 과중한 업무로 인해 참다못해 전업을 하거나 건강이 나빠져서 자의반 타의반 일을 더 이상 할 수 없게 되곤 한다. 그러한 이유 때문에 많은 개발자들이 스스로를 막장 인생이라고 표현하고 있다.

엉성한 개발자 관리
둘째, 소프트웨어 업체들이 개발자를 제대로 관리하지 못하고 있다. 소프트웨어 개발은 멘탈(mental) 작업이다. 인간의 정신에 의해 결과물이 만들어지고 그것이 성공과 실패를 좌우한다. 하지만 국내 대부분의 소프트웨어 업체들은 그러한 멘탈 작업에 적합한 업무 환경을 제공하지 못하고 있다. 또한 커리어 관리도 이루어지지 않고 있다. 물론 실적에 대한 보상도 미비하다.

개발자들에 대해 출퇴근 시간을 정확하게 체크하고(아니, 출근시간을 지키는지 체크하고 퇴근시간은 얼마나 늦는지 체크한다), 집중할 수 없는 시끄러운 환경을 제공하고, 업무 실적의 가치를 제대로 평가하지도 못한다. 심지어 복장 점검을 하기도 한다. 또한 요즘 개발자들은 전문적인 교육은 고사하고 일일 세미나에 참석하는 것도 어려운 형편이다. 많은 기업들이 최소한의 투자조차 기피하고 있기 때문이다.

그것은 중소기업은 말할 것도 없고 소위 초일류 기업을 지향한다는 대기업도 마찬가지이다. 열악한 업무 환경을 제공하면서 성과에 있어서는 최고의 아웃풋을 강요한다. 개발 환경만 제대로 제공되지 못하는 것이 아니라 관리도 제대로 안되고 있다. 부적절한 관리자들이 개발자를 정신적으로 학대하고 있다. 소프트웨어 개발자로서 생존하기 위해서는 사회 구조적 환경, 그리고 기업문화와 싸워야 한다. 많은 선배 개발자들이 그런 생존을 위한 싸움에서 졌고 결국 사라져 갔다.

개발자들의 스킬 부족과 닫혀진 태도
셋째, 끝으로 개발자들의 커뮤니케이션 스킬 부족과 태도 문제를 지적하지 않을 수 없다. 이 문제는 한국적 기업문화(상명하복)와 결합하여 더욱 복잡한 문제를 야기하고 있다. 개발자들은 특히 다른 직종에 비해 성격이 까칠한 경우가 많다. 자신만의 지식과 세계가 있기 때문에 그것이 전부라고 우쭐한 채로, 다른 개발자나 다른 직종을 존중하지 못하는 사람들이 꽤 많다.

하지만 “타인이 원하는 것에 대해 관심을 갖지 않는 사람”은 인생의 가시밭길을 걷게 된다. 그런 태도는 타인과의 협업을 어렵게 하고 결국 자기 자신이 원하는 것도 얻지 못하게 한다. 젊은 시절에는 그런 태도에도 불구하고 큰 문제가 없을 수 있겠지만, 30대 중반이 넘을 때까지도 태도를 변화시키지 못할 경우 이후에 많은 고난을 겪게 된다. 그것은 이미 인간의 역사에서 증명된 삶의 법칙이다.

똑똑하고 샤프한 개발자들은 종종 있다. 하지만 타인의 관심사에 진정으로 주의를 기울이고 타인에게 친절한 마음을 가진 개발자를 만나기란 참으로 힘들다. 이것은 다른 직종도 마찬가지이겠지만 (개발자 출신인 필자가 볼 때에는) 개발자들의 세계에 유독 이런 까칠함과 폐쇄성이 심하다.

물론 그런 독불장군적 태도가 단지 개발자들의 탓만은 아닐 것이다. 많은 개발자들이 피해 의식을 갖고 있으며 그것이 타인에 대한 공격적 태도로 나타나기도 한다. 사회적 환경의 미비, 그리고 커뮤니케이션 스킬이 부족한 개발자들. 이 조합이 더욱 안타까운 결과를 만들어낸다.

추가적으로 언급할 점은, 혁신해야 할 여러 가지 네가티브한 요인에도 불구하고 개발자들끼리 잘 뭉치지 못한다는 사실이다. 외국과 달리 개발자 커뮤니티의 활동이 많지 않다. 물론 JCO(자바 개발자 커뮤니티), SCA(소프트웨어 커뮤니티 연합) 등 개발자들의 모임이 없는 것은 아니지만 가끔 오프라인 모임이나 컨퍼런스를 개최할 뿐, 별다른 ‘사회 변혁적 활동’을 구현하지는 못하고 있다. 개발자들의 실상을 알리고 대안을 마련하고 정부나 기업들과 접촉을 하고 해외에 진출하고 창업을 하는 등의 좀 더 적극적으로 행동하는 것이 필요하다.

아마도 필자의 이런 글에 대해 그저 현실에 대한 비판에 불과하다고 얘기하는 이도 있을 것이다. 하지만 대응 방안을 마련하기 위해서는 먼저 냉정하게 현실을 정리하지 않을 수 없다.

요약해보자. 대기업 계열사들이 장악한 SI 위주의 산업 구조에서 개발자들은 성장하지 못하고 성공하지 못한다. 이런 사회 풍토에서 과연 존경 받거나 성공한 개발자들이 얼마나 되는가? 또한 많은 소프트웨어 업체들의 기업 문화가 후진적이다. 제대로 된 업무 환경을 제공하지도 못하면서 프로젝트 관리도 안 된다. 그러면서 성과에 대해서는 초일류를 원한다. 이율배반적이다.

개발자들의 태도 문제도 있다. 환경을 바꾸지 못하면 자기 자신을 바꾸어야 한다. 개발자 스스로 그런 인식을 가져야 한다. 피해의식에 사로잡혀 있는 것만으로는 삶이 억울하지 않은가? 개인적으로 커뮤니케이션 스킬을 향상시키고 타인에 대해 친절한 태도를 갖추는 인간 수양이 필요하다. 그리고 동료 개발자들과 함께 변혁을 위해 협업하고 개척해나갈 부분이 있다는 것을 알고서 행동해야 한다.

왜곡된 업계 구조 속에서 가만히 있으면 퇴출될 뿐이다. 우리에게는 행동이 필요하다. 이후의 컬럼에서 하나씩 대응 방안을 다루어보도록 하겠다.

출처 : ZDNet Korea - 류한석(IT 컬럼니스트)
    

설정

트랙백

댓글

예의 바른 소프트웨어의 특성

Programming/Etc 2007. 4. 10. 23:54
요즘 전철을 오가며 읽고 있는 앨런 쿠퍼의 “정신병원에서 뛰쳐나온 디자인”을 보고 있는데 지옥철 2호선을 오가는 지라 하루에 10장 읽기도 어렵다. 그 본문 중에 예의 바른 소프트웨어의 특성에 관한 이야기가 나온다.

우리가 당연하게 받아들이고 있는 여러 가지 소프트웨어의 문제점들에 대한 이야기들이 나오는데 소프트웨어를 만든 사람으로서는 실용적이지 않은 귀찮은 질문들을 수없이 던지는 기능적인 요소들이 사용자에게 선택의 기회를 주었다고 생각하지만 사용자로서는 그다지 환영하지 않으며 선택의 여지들을 제공받는 것은 충복이 아니라 고문에 가깝다는 이야기가 나온다. 이러한 것들은 앨런 쿠퍼가 이야기 하는 무례한 소프트웨어다.

사실 이런 경험들은 무수히 많이 있다. 하루에도 수십 번씩 파일을 삭제할 것이냐, 프린트를 정말 할 것이냐, 창을 닫을 것이냐, 프로그램을 종료할 것이냐와 같은 메시지 창을 확인하게 되는데, 이러한 훈련 과정에는 대부분의 사람들은 자신의 어떤 행동에 대한 메시지로 인식하고 꼼꼼하게 읽고 확인하지 않는 듯 하다.

이런 바람직하지 않은 사용자의 훈련으로 그러한 소프트웨어의 무례한 행동에 대해 별로 거부감을 느끼지 않으며 그것이 잘못된 행동이든 잘 된 행동이든 무의식적으로 결정권을 컴퓨터에게 넘겨버린다.

물론 이러한 안내문이 없이 파일을 삭제하거나 덮어버릴 수 있는 여지도 다분히 있지만 안내창의 일련의 행동에 학습된 사용자가 과연 그것을 보고 삭제를 포기하거나 덮어쓰기를 취소하는 경우가 얼마나 있을까 하는 의구심이 든다.

예의 바른 소프트웨어의 특성
1.    나에게 관심을 갖는다.
2.    나에게 공손하다.
3.    사근사근하다.
4.    상식이 있다.
5.    내가 필요로 하는 것을 예측한다.
6.    빠르게 반응한다.
7.    자신의 개인적 문제에 대해 떠벌리지 않는다.
8.    정보에 밝다.
9.    통찰력이 있다.
10.    자신감을 갖고 있다.
11.    집중력을 유지한다.
12.    유연하게 대처한다.
13.    즉각적인 만족을 제공한다.
14.    신뢰할 수 있다.

책 에서도 이야기 했지만 이러한 무례한 소프트웨어의 행동들은 더 많은 문제점을 미리 예방하는 차원에서 행해지는 경우가 대부분일 듯 싶다. 나 또한 어떠한 기능적인 요소들에 대해서 작업을 진행할 때는 이보다 더 무례하고 돌이킬 수 없는 잘못을 사용자 탓으로 돌리기 위한 술책(?!)을 강구하는 편이다.

앞으로 어떠한 방향으로 소프트웨어가 변화해 갈지는 시대의 흐름에서 이미 밝혀진 것 같다. 하지만 그것을 구현하고 설계하는 것이 사람인 만큼 사람과 사람의 이해가 선행되지 않고서는 예의 바른 소프트웨어의 모든 요소들을 충족할 수 있는 소프트웨어는 나타날 수 없을 듯 싶다.
사용자 삽입 이미지
블로그에 추가한 사용자 방문 카운터



    

설정

트랙백

댓글

구글의 최종 목표는 인공지능 검색

Programming/Etc 2007. 4. 10. 00:46
구글을 위해 온갖 허드렛일을 마다하지 않을 사람을 꼽으라면 크레이그 실버스타인을 들 수 있을 것이다. 실버스타인은 구글의 핵심 멤버이자 기술 책임자이며 검색 분야에서 항상 “나쁜 짓은 하지 말라”는 구호를 외치는 사람으로 알려져 있다.

올해 31세인 실버스타인은 1998년에 스탠포드 대학에서 박사 과정을 밟던 중 서지 브린, 래리 페이지 등 학교 동창들과 함께 근처 차고에서 지금은 전세계적으로 유명해진 검색 엔진을 만들어냈다.

결국 이들의 노력은 성공을 거뒀다. 지금 이 검색 회사는 2000년 이래 IPO를 시행한 IT 업체들 중에서도 가장 큰 인기를 끌고 있으며 조만간 27억달러에 달하는 자금을 끌어모을 수 있을 것으로 기대되고 있다.

IPO 시행에 따라 엄청난 부도 챙기게 되겠지만 이와 별도로 실버스타인은 오랫동안 정말 열심히, 그리고 즐기면서 일한 것으로도 유명하다. 구글의 기술 책임자인 그는 검색이라는 비전을 가지고 사용자들이 실제로 정보에 접속하는 것은 도와주는 제품을 개발하는 임무를 수행중이다.

여기에는 구글 웹사이트를 각 개인에 맞춤화하는 새로운 기술과 무선 기기 활용 방안, 가격 비교 기능, 그리고 무료로 이메일을 1GB 용량까지 보내고 저장하고 관리할 수 있는 서비스 - 이것은 G메일이라고도 알려져 있다 - 등이 있다.

구글의 IPO 신청이 있기 이전에 가진 인터뷰에서 실버스타인은 사생활 옹호론자들의 G메일 반대 움직임과 구글의 문화적 변화, 그리고 페이지랭크(PageRank)에 대한 의존도가 변화하고 있는 현상에 대한 문제 등에 대해 얘기를 나눴다. 페이지랭크는 구글이 유명세를 떨치는데 크게 기여한 수학적 알고리즘이다. 최근 구글은 스탠포드 대학의 페이지랭크 라이선스를 2011년까지 연장한 바 있다.

검색 분야의 역사에 있어 구글이 한 역할에 대해 당신은 어떤 견해를 갖고 있는가?

구글은 사람들이 요구하는 딱 그 시점에 등장했다. 컴퓨터의 출현 이후 사람들은 점점 더 많은 정보를 가질 수 있게 됐다. 따라서 그 많은 정보들을 유용한 것으로 가공하는 우수한 기술을 필요로 했다. 그리고 바로 그때, 구글이 그 접점에 있었던 것이다.

당신은 그간 검색 엔진의 이상적인 모습을 스타트랙에 등장하는 스타쉽 엔터프라이즈가 갖고 있는 지적 능력이라든지 똑똑한 검색 애완동물들이 가득한 세상에 비유하곤 했다. 이에 대해 좀더 말해줄 수 있나?

좋다. 스타쉽 엔터프라이즈나 똑똑한 검색 애완동물에 이은 내 세 번째 생각은 컴퓨터가 도서관의 사서처럼 도움을 주는 것이다. 이것 또한 상당히 재미있다. 도서관 사서들은 검색하기 위해 물론 컴퓨터와 구글도 함께 사용하고 있지만 잘 보면 이들은 검색 작업에 컴퓨터만으로는 불가능한 어떤 지적인 요소를 집어넣고 있다.

결국 우리의 목표는 매우 영리한 컴퓨터를 만들어 상호 대화를 할 때 컴퓨터들로 하여금 실질적으로 더 좋은 검색 결과를 얻을 수 있도록 정보를 잘 활용할 수 있게 하는 것이다. 바로 이것이야말로 구글이 검색의 질을 향상시키기 위해 항상 생각하고 있는 부분이다.

설명한 것과 같은 인공지능적인 검색이 언제 가능해질 것이라고 생각하는가?

인공 지능의 마지막 미개척 분야는 언어 이해라고 본다. 이것이 이뤄진다면 컴퓨터와 대화를 나누는 것이 마치 도서관 사서와 얘기하는 것과 똑같은 경험이 될 것이다. 컴퓨터와 사서는 모두 우리가 살고 있는 이 세계와 우리 자신에 대해 매우 잘 알고 있다는 공통점을 갖게 되기 때문이다.

그러나 둘 간에는 큰 차이점이 있다. 바로 이 부분이 검색 애완동물이 필요한 지점인데 도서관 사서들은 컴퓨터가 완전히 이해할 수 없는 인간의 감정이나 다른 여러 상상속의 세계에 관한 정보들도 이해할 수 있다는 점이다.

언제 가능하냐고 묻는다면 나는 보통 200~300년이 걸릴 것이라고 말한다. 아마 300년보다는 더 짧아지지 않을까? 그러나 만약 200년이 걸리다 해도 어차피 나는 그 당시 살아잇지 않을 것이니까 아무도 나에게 뭐라고 말하진 못할 것이다.

정말 멋진 생각이다

좀 더 말해보자. 30년 내에 방금 언급한 것들이 이뤄질 것이라고 상정해보자. 사실 이런 문제들은 지난 60년대에 인공지능을 연구하던 사람들도 모두 생각했던 부분이다. 그렇다면 지금 우리가 사는 이 시대에 모든 문제가 다 해결됐어야 하지 않는가? 그러나 우리는 인공지능의 궁극적인 목표인 인간의 언어를 이해하기엔 아직 까마득한 수준이다.

몇몇 컴퓨터 연구가들은 페이지랭크가 이제 죽었다고 말한다. 인터넷 광고주들이 자사 사이트의 인기도를 허위로 만들어냄으로써 페이지랭크를 악용하고 있기 때문이라는 것이다. 사실인가? 그렇지 않다면 페이지랭크를 어떻게 수정한 것인가, 아니면 이젠 페이지랭크가 그리 큰 역할을 하지 않는 것인가?

페이지랭크가 죽었다는 주장은 우선 세계를 너무 정적으로 보기 때문에 나온 것이다. 페이지랭크는 언제나 순위 매김 방법 중 하나로 유효할 것이다.

그러나 시간이 가면서 우리가 순위를 매기는 방법에 대해 점점 더 새로운 아이디어를 개발해내고 기존 아이디어를 수정하거나 이 모든 것들을 함께 사용할 수 있는 새로운 방법을 생각해낼 것이기 때문에 우리가 사용하는 이런 모든 기술의 역할도 바뀔 수밖에 없다.

현재 구글에서 페이지링크보다 더 큰 역할을 하고 있는 알고리즘 기술이 있다면?

물론 우리는 현재 다른 기술도 사용하고 있다. 그러나 자세히 언급하는 것은 좀 곤란하다. 개괄적으로 말해보자면 우리는 약 2~3가지 종류의 기술을 사용하고 있다. 하나는 인간의 지능을 이해해 그것을 활용하는 종류다. 우리는 사람들이 어떤 한 페이지를 보고 있다가 다른 페이지로 넘어가기로 결정하는 것이라든지 아니면 그 텍스트가 어떤 것이라고 주석을 다는 행위에서 힌트를 찾아내고 있다.

현재 구글은 몇 대의 서버를 운영하고 있는가? 어떤 사람들은 10만대라고도 하고 어떤 사람들은 만대라고 추산하기도 한다.

몇몇 업계 관계자들은 구글의 컴퓨터 구성이야말로 일급비밀에 속하는 것이라고 하면서 그것만 잘 이용한다면 검색은 단지 한개의 애플리케이션에 불과하다고 말하기도 한다. 그러니까 G메일 같은 것이 가능하다는 것이다. 당신네들의 컴퓨터 구성이 바로 구글의 힘이라는 사람들의 평이 정당하다고 보는가?

재밌는 말이다. 검색의 역사는 실제로도 원래 검색을 위해 개발됐다기보다는 애플리케이션에 추가적으로 포함됐던 검색엔진의 역사에 그 궤를 같이 한다. 알타비스타와 같은 경우에도 원래는 알파 서버의 개념 증명(POC) 용도로 DEC에서 개발한 것이다.

구글에는 상업적 웹 검색 엔진 전용으로 1만대 이상의 컴퓨터를 갖고 있다. 그러나 이것은 물론 검색을 더 잘하기 위해 인프라스트럭처를 개발해온 결과다.

우리는 용이하게 확장시킬 수 있는 그 무언가를 원했다. 웹이 너무나 빨리 성장할 것이라는 사실을 이미 알고 있었기 때문이다. 우리는 컴퓨터만 추가시키면 코드를 새로 작성하지 않고 그 즉시 용량을 늘릴 수 있도록 확장성이 뛰어난 알고리즘을 개발해야만 했다.

이런 생각으로 시작했기 때문에 처음 회사를 설립했을 때는 지금보다 수천배나 작았던 것을 오늘날의 크기까지 키울 수 있었던 것이다.

여기에 우리는 이런 기술들이 많은 정보를 찾는 것과 같은 일상적인 업무에 상당히 유용하다는 것도 알게 됐다. G메일이 아주 좋은 예다. 게다가 이와 같은 정보들은 웹 자체만큼이나 클 수도 있으며 아니면 다 합쳤을 때 웹보다 더 클지도 모른다. 우리는 이런 종류의 정보도 다룰 수 있는 기술적 노하우를 갖고 있다.

현재 어떤 다른 애플리케이션을 개발하고 있는가?

자세히 말할 수는 없다. 일반적인 방향은 이미 위에서 언급한 것과 같다. 그러니까 사람들에게 좀더 많은 정보를 제공한다는 것이다. G메일은 사적인 정보를 검색할 수 있도록 하는 것으로 우리 노력의 첫 번째 실제 결과다.

사생활 옹호론자들부터 시작해 지금은 입법자들에 이르기까지 G메일에 부정적인 반응을 보이는 것을 보며 뭘 느꼈는가?

구글이 사람들의 생활에서 매우 중요한 역할을 하고 있으며 자극을 받는 것도 매우 가치 있다는 점들을 배웠다. 지난번에도 구글이 한 일에 대해 사람들이 흥분했던 것을 기억하고 있다.

바로 우리가 데자닷컴(Deja.com)으로부터 유즈넷(Usenet) 아카이브를 인수했을 때다. 이를 두고 유즈넷 공동체에서는 모두들 이제 유즈넷의 미래는 어떻게 되느냐면서 정보에 접속하는 문제에 대해 큰 우려를 표시했었다.

그러나 시간이 지나면서 상황에 익숙해지자 이들은 제품을 사용해보면서 정말로 좋다는 것을 알게 됐다. 그 사건은 지나갔지만 나는 이번에도 같은 일들이 일어날 것으로 보고 있다. 어떤 회사든지 모든 사람들에게 중요한 이슈로 간주되는 것에는 진지하게 임해야 한다. 나는 구글이 그런 회사라고 생각한다.

서비스는 어떻게 바뀔 것이라고 생각하는가?

어떤 변화가 생길 것이라고 추측하기엔 지금은 너무 이르다.

장기적으로 볼 때 하나의 거대한 검색 공간이 있는 것과 서로 다른 작은 검색 공간들, 그러니까 이 웹사이트에서는 이런 데이터베이스를 그리고 저 회사에서는 이메일 아카이브를 제공하는 식으로 존재하는 것 중 어떤 방식이 더 좋을 것 같은가?

사용자 입장에서는 한 개의 검색 공간을 가지고 싶어 할 것이다. 기술적인 면에서 나는 어느 것이나 상관없다. 나에게 중요한 것은 사용자들이 원하는 정보를 쉽게 얻을 수 있어야 한다는 것이다.

즉 한 공간에서 검색할 수 있어야 한다는 것이며 또한 그 단일한 검색 공간이 아주 영리해서 전세계 수억만 가지의 다른 정보 소스 중 어떤 결과가 적절한지 알아낼 수 있어야 한다는 것이다.

검색 기록이나 등록 데이터, 이메일 문서 등을 한 곳에 놓았을 때 사생활 보호 조치가 필요하다는 것에 대해서는 어떻게 생각하나?

정보를 만들어내고 정보를 소유하고 있는 사람들에게 정보 공개 방식에 대한 결정권이 있다는 것을 잘 알고 있다. 우리는 사람들이 구글을 통해 어떤 식으로 자기네 정보를 내보낼지 제어할 수 있도록 모든 종류의 방법을 제공하고 있다. 이것이 우리의 정책이 될 것이다.

구글의 알고리즘은 확장성이 있는가? 그러니까 예를 들어 당신네의 데이터베이스에 들어있는 데이터가 2배로 늘어나면 검색 결과를 보내주기 위해 단순히 컴퓨터만을 2배로 늘리면 되는 것인가?

우리 알고리즘은 물론 확장된다. 그리고 웹 크기가 2배로 늘어나면 컴퓨팅 기기도 물론 2배로 커져야할 것이다.

기계가 다운되는 특정한 경우가 있는가? 인위적으로 막대한 용량의 데이터를 입력시켜도 크게 상관이 없는가?

내가 아는 한도에서 볼 때 대용량 데이터가 인위적으로 들어와도 잘 돌아간다. 문제가 있을 수도 있겠지만 아직 실제로 그런 일이 일어나진 않았다.

검색 기능이 진보하려면 운영체제에 내장돼야 하며 MS가 개개인에 더 잘 맞는 툴을 만들어낼 수 있다고 생각하는가? 만약 그렇게 된다면 구글은 MS가 수집한 정보에 접속하기를 원하는가?

몇 년 전에 있었던 MS와 넷스케이프 간의 논쟁을 생각해보라. 당시에도 운영체제에 어떤 것이 들어가야 하는지, 들어가서는 안되는지 열띤 논쟁이 있었다. 주로 운영체제가 어떤 것이냐 하는 개념 정의에 관한 논쟁이었다.

사실 나에게 이런 것들은 그다지 흥미를 끌지 못한다. 나의 관심사는 사람들이 필요한 정보를 가능하면 가장 쉽게 얻어야 한다는 것이다.

MS 제품이 2006년도 이전에는 출시되지 않는다는 것을 상기해보자. MS가 검색 분야에서 이른바 FUD 전략을 사용하고 있다고 보는가?

그런 일에 별로 신경쓰지 않는다. MS는 검색이 사람들에게 매우 중요하다고 결론을 내렸고 공개적으로 표명한 적도 있다. 여기엔 우리도 확실하게 동의한다.

동영상이나 오디오 검색 엔진을 만드는데 있어 복잡성은 어느 정도인가?

텍스트가 아닌 정보를 어떻게 설명해야 하는지, 그리고 그런 정보들을 어떻게 활용할 것인지 등이 이런 복잡성에 속한다. 어찌 되든 간에 사람이 그것을 설명해야 하기 때문이다. 물론 쉬운 문제는 아니다. 그러나 오디오나 동영상에도 가능은 하다고 생각한다. 특히 학계에서 이 분야에 매우 큰 관심을 갖고 있다.

그러나 단기적인 문제점들은 그다지 기술적인 부분이 아니다. 이런 컨텐트를 갖고 있는 사람들은 공개를 꺼리고 사람들이 그것을 검색할 수 있도록 내놓으려 하지 않는다.

우리는 사람들의 의견을 존중한다. 언젠가 이런 정보를 웹상에서 검색할 수 있는 좋은 비즈니스 모델이 등장하거나 아무런 불편이 없는 어떤 방법이 나타날 때까지는 이와 관련한 기능을 제공하지 않을 작정이다.

현재 개인 맞춤화 툴들이 등장하고 있다. 아마존의 A9.com과 MSN에서는 각각 다른 기술로 개인화를 구현하고 있다.

구글의 툴은 이를테면 “우리에게 정보를 주면 검색을 도와주겠다”라는 식이다. 반면 다른 회사들은 “당신들의 방법을 배우고 싶다. 그런 이후에 당신을 돕겠다”라는 식이다. 구글의 접근 방식이 어떤 면에서 더 우월한지 설명해 달라.

후자의 경우에는 먼저 배우고 나서 방문자를 돕는다는 주의다. 컴퓨터는 2개의 다른 장소에서 각각 지적인 판단을 내려야한다. 이 방법이 나쁘다거나 전망이 없다는 것은 아니다. 그러나 이 방식을 사용하면 컴퓨터에 더 큰 부담을 준다. 컴퓨터에 당신의 관심사가 무엇인지 말하면 컴퓨터는 그 정보를 가지고 당신이 원하는 것을 찾아주는 정도만 수고하면 된다.

이 두가지 방법은 모두 사람들에게 개별적인 정보를 주자는 같은 목표를 가지고 있다. 다른 것은 단지 어떤 식으로 도달하느냐하는 것뿐이다. 미래에는 이런 검색이 더욱 더 흔해질 것이다.

당신은 구글의 첫번째 직원으로서 구글의 문화가 당신이 처음 시작했을 때와 비교해 어떻게 변했는지 말해줄 수 있는가?

분명히 많이 변했다. 과거에는 회사의 모든 사람들과 알고 지냈지만 지금은 그렇지 못하다는 것이 유감스럽다. 그러나 문화는 달라졌어도 구글의 기저를 이루는 기본 원칙들, 그러니까 제품에 있어서나 하나의 회사로서 내부 운영이 어떤 식으로 이뤄지느냐 하는 면에서는 시작할 때와 그다지 달라진 게 없다. 바로 이 점이 아직도 내가 감동하고 있으며 특히 아직도 구글에 있는 이유 중 하나다.

우리는 아직도 작업 분위기가 즐거워야 한다고 믿는다. 내가 처음에 시작했을 때처럼 지금도 이것은 지켜지고 있다. 구글 사무실에는 하루에도 몇 차례씩 마사지 치료사가 오는데 예전에는 한사람이 왔던 반면 지금은 몇 사람이 한번에 들어와서 마사지를 받고 싶어 하는 직원들에게 마사지를 해준다.

제품 면에서 구글은 매우 기술 중심적인 회사임과 동시에 사용자 경험에 매우 초점을 맞추고 있다. 물론 한 회사를 운영한다는 것은 어려운 일이다. 인터넷 회사로서 5년 반이라는 세월은 결코 짧지 않은 시간이다. 이런 저런 힘든 일이 있었음에도 불구하고 이렇게 늘 일관성 있게 운영되고 있다는 것은 대단한 일이다. 그리고 이 모든 것에 대해 나 자신은 감사하게 생각하고 있다.

출처 :  Stefanie Olsen ( ZDNet Korea )  

2004년 5월에 나온 기사인데 재미있는 내용들이 보이네요...^^

    

설정

트랙백

댓글

상황중심의 프로그래밍

Programming/Etc 2007. 3. 10. 20:54
스티븐 스필버그 감독은 영화 <뮌헨>을 발표한 후 알고 지내던 유태인 친구를 여러 명 잃었다고 고백했다. 영화 속에서 주인공은 이스라엘 정보기관 모사드의 도움을 받아 폭탄 제조, 문서 위조, 사건 뒤처리 등의 다양한 재주를 가진 6명의 요원으로 팀을 구성한 다음, 1972년 뮌헨 올림픽 선수촌에서 테러를 일으킨 검은 9월단의 배후 요원들을 한 명씩 살해한다.

하지만 시간이 흐르면서 주인공을 비롯한 요원들은 국가를 위한 복수와 비인도적인 살인 행위 사이에서 갈등을 겪게 되고 스스로의 생명마저 위협받자 깊은 회의에 빠져들게 된다. 스필버그 감독은 인간적인‘갈등’과‘회의’를 그렸을 뿐인데 열혈 유태인들은 그것조차 용납하기 어려웠던 모양이다.

아무튼 영화 속의 주인공은 복수의 대상 11명이 은거하고 있는 장소와 그밖에 필요한 정보를 얻기 위해서 일종의‘정보 브로커’와 거래를 한다. 그에게 거액의 돈을 주고 살해할 대상이 숨어 있는 장소에 대한 정보를 얻는 것이다. 재미있는 점은 주인공의 복수가 진행되는 동안 다른 나라의 정보조직에서도 똑같은 정보 브로커에게 접근해서 주인공과 동료들의 신원을 파악하려고 한다는 점이다. 이름도 없고, 얼굴도 없어서 어느 누구에게도 존재가 드러나지 않아야 하는 정보조직 세계의 요원들이 이렇게 ‘정보 브로커’라는 존재를 통해서 오히려 하나의 지점에서 만나는 현상이 벌어진다.


상황중심이란 개념 이해하기    

이렇게 다양한 독립적인 개체들이 자신의 목적을 위해서 공통적으로 통과할 수밖에 없는 지점, 혹은 수행할 수밖에 없는 행동을 상황중심 프로그래밍(Aspect Oriented Programming)에서는 접점(join point)라고 부른다.‘ 상황중심’이란 요즘 프로그래밍 세계에서 주목을 받고 있는 ‘Aspect Oriented’라는 표현을 나름대로 우리말로 옮겨본 것이다.‘ Aspect Oriented’라는 말이 국내에서는‘관점 지향’이라는 말로 표현되기도 하는데, 이것은 그 동안 ‘Object Oriented’를‘객체 지향’이라고 불러온 관성의 영향인 것으로 생각된다.

사실‘관점 지향’이라는 말은 의미가 분명하지 않을 뿐만 아니라 겉으로 드러나는 의미조차 정확하다고 보기 어렵다. ‘관점’을‘지향’한다니? 프로그래밍을 수행하는 사람이 자기 관점을 분명히 세우고 그것을 목표로 전진하라는 말인가?‘ 관점 지향’이라는 말이 국내 프로그래머 사이에서 일정한 합의를 이루고 있는 표현이라면 어쩔 수 없지만, 최소한 이 글에서는‘Aspect Object’를‘상황중심’으로 표현하고자 한다. 이렇게 해야 새로운 방법론이 전하고자 하는 의미가 분명하게 드러나기 때문이다.

상황중심 프로그래밍은 말 그대로 현재의 소프트웨어 코드가 처해 있는 특정한‘상황’에 초점을 맞추는 프로그래밍을 의미한다. 폭발적으로 늘어나는 수요를 감당하지 못해 심각한 위기를 맞이했던 소프트웨어 개발시장은‘모듈(module)’과‘객체(object)’라는 혁명적인 개념을 발견하면서 위기를 극복했다. 방대한 분량의 소프트웨어 코드를 모듈과 객체라는 작고 독립적인 부분으로 분리할 수 있었기 때문에 프로그래머들은 점점 더 복잡한 업무를 수행하는 코드를 만들어 낼 수 있었던 것이다. 하지만 독립적인 모듈과 객체의 수마저 기하급수적인 규모로 증가하면서 예전과는 전혀 다른 문제가 대두되었다.

모듈과 객체는 코드를 추상적이고 부분적인 캡슐로 분리해서 전체적인 코드에 대한 관리가 가능하도록 만들고 필요하면 재사용 할 수 있는 방법까지 제공했다. 즉 모듈과 객체는 코드의 부분을 떼어내서 추상화하는 방법을 제공한 것이다. 하지만 이러한 방법은 모듈과 객체를 가로지르며 존재하는 공통의 관심사(cross-cutting concern)를 효율적으로 추상화하는 방법은 제공하지 않았다. 공통의 관심사란 보안(security), 성능(performance), 기록(logging)과 같은 소프트웨어의 일반적인 속성에서부터 데이터 캐시(cache) 관리나 네트워크 프로토콜의 구현처럼 구체적인 기능에 이르기까지 다양하다.

이러한 공통의 관심사는 특정한 모듈이나 객체가 구현하는 기능에 국한되는 것이 아니라 소프트웨어 시스템 전체에 걸쳐 수평적으로 영향을 미친다. 잘 이해가 되지 않는 독자는 다음 예를 생각해 보면 도움이 될 것이다.


공통의 관심사    

인터넷 붐이 한창이던 90년대에 미국에서는‘수평적 시장(horizontal market)’과‘수직적 시장(vertical market)’이라는 표현이 자주 사용되었다. 수직적 시장이란 어떤 제품이 특정한 분야의 시장에 국한되는 경우를 의미한다. 예를 들어서 책, 의류, 자동차, 컴퓨터, 혹은 의료보험 시스템 등은 다른 분야와 겹치지 않는 자기 자신만의 시장을 형성한다.

이들은 모두 수직적 시장의 예이다. 하지만 웹브라우저와 같은 소프트웨어는 특정한 시장에 국한되지 않고 모든 수직적 시장들 사이에 공통적으로 존재하며 영향을 미친다. 그 자체로는 특정 품목에 대한 시장을 형성하지 않지만 여러 시장에서 동시에 존재하는‘공통의 관심사’가 되는 것이다.

영화 <뮌헨>에서 이스라엘의 모사드, 소련의 KGB, 미국의 CIA, 팔레스타인의 검은 9월단 등은 각자 겹치지 않는 고유의 영역을 구성하고 있지만, 그들이 어떤 인물의 은신처를‘검색’하기 위해서는 다양한 정보를 보유하고 있는‘정보 브로커’를 찾아가야만 했다. 각 국의 정보기관이 수직적 시장을 형성하고 있다면,‘ 정보 브로커’는 웹브라우저와 마찬가지로 수평적 시장을 형성하고 있는 셈이다. 이 경우에‘정보 브로커’는 여러 정보기관들을 가로지르며 공통적으로 존재하는‘공통의 관심사’로서의 역할을 담당한다.

오늘날의 프로그래밍 세계에서 수직적 시장을 구성하는 존재는 말할 것도 없이‘객체’들이다. 객체들은 저마다
주어진 일감을 구현하면서 일이 서로 겹치지 않도록 소프트웨어의 전체 영역을 분할한다. 이렇게 분할을 더욱 효율적으로 만들기 위해서 비슷한 일을 하는 객체를 한곳에 묶어서‘패키지(package)’라고 부르기도 한다. 지금까지 프로그래밍은 이러한 분할을 통해서 충분히 잘 이루어져 왔다.

하지만 이렇게 역할 분담을 통한 균형과 평화가 이루어진 상황에서도 여러 객체 사이에 존재하는‘공통의 관심사’는 존재하기 마련이다. 앞에서 예로 든 보안, 성능, 기록, 캐시, 프로토콜 등이 바로 그들이다. 이밖에 유닛테스트(unit test)나 테스트 자동화 등도 여기에 포함될 수 있을 것이다.

좀 더 이해를 돕기 위해서 하나의 구체적인 상황을 생각해보자. 소프트웨어의 사용자들이 항상 그렇듯이 개발자가 개발한 시스템을 이용하는 사용자 중에는 구체적인 데이터를 제시하지 않으면서 말로만“시스템이 느려 터졌다.

답답해서 못 쓰겠다.”라고 불평을 늘어놓는 사람이 있다. 소프트웨어를 제작하고 관리하는 입장에서는 이렇게 막연하게 불평만 늘어놓는 사용자처럼 속상한 존재가 없다.

구체적으로 어떤 기능을 사용할 때‘느린지’를 알아야 그가 겪고 있는 문제가 PC 하드웨어와 관련된 문제인지, 개발자가 만든 소프트웨어의 문제인지, 네트워크의 문제인지, 혹은 서버나 데이터베이스의 문제인지를 알 수 있고 그에 따른 해결책을 제시할 수 있기 때문이다(물론 사용자가 허락만 해준다면 그가 소프트웨어를 어떻게 사용하는지 직접 관찰할 수도 있을 것이다. 하지만 성격이 곱지 않은 월스트리트의 트레이더에게‘저는 소프트웨어를 제작한 사람인데요, 잠시 옆에서 PC를 사용하는 모습을 관찰해도 될 까요’라고 묻는 것은 자살 행위이다).

그렇지만 사용자가 데이터를 제공해 주지 않는다고 해서 손을 놓고 있을 수는 없으므로 우리는 필요한 데이터를 스스로 구해야 한다는 결론을 내리게 되었다. 그리하여 우리가 구현하기로 한 기능은 사용자가 소프트웨어에서 어떤 동작을 수행할 때마다 맨 처음 GUI의 이벤트 처리 메소드(event handler)에서 출발해서 서버와 데이터베이스에 이르는 과정에 존재하는 각 계층을 통과하는 데 걸린 시간을 측정한 다음 로그 파일과 같은 하나의 장소에 기록하는 것이었다.


스파이로그    

사용자가 GUI 화면에서 주식이나 채권 가격 같은 데이터를 입력하고 OK 버튼을 눌렀다고 해보자. 그러면 소프트웨어의 흐름은 GUI 계층, GUI 계층 아래에 존재하는 네트워크 계층, 실제 네트워크 전송, 서버에서 사용자의 요청을 받아들여서 적절한 컴포넌트( component)에게 전달하는 계층, 데이터베이스에 저장되어 있는 프로시저(stored procedure), 최종적인 데이터를 담고 있는 응답객체를 생성하는 계층, 응답 객체를 GUI 클라이언트에게 전송하는 계층, GUI가 서버의 응답을 받아서 처리하는 계층 등을 차례로 통과한다.

이 때 각 계층에서 소요된 시간을 측정해서 하나의 객체에 저장하는 것이다. 이렇게 처리시간이 기록된 객체는 각 계층을 통과할 때마다 다음 계층에게 전달되면서 값을 축적해 나간다. 필요한 처리 과정이 모두 끝나고 나면 이 객체에 저장된 값은 미리 지정된 포맷에 따라서 로그 파일에 기록되고 객체의 수명은 끝이 난다.

이제 사용자가 시스템의 성능에 대해서 밑도 끝도 없는 불평을 늘어놓으면 로그 파일에 저장되어 있는 데이터를 분석해서 실제로 성능에 문제가 있었는지, 만약 문제가 있었다면 어느 계층에서 문제가 있었는지를 파악할 수 있다.

이렇게 유용한 기능의 이름을‘스파이로그’라고 불러보자. 앞의 설명을 읽으면서‘흠 소프트웨어의 여러 계층을 관통하는 <공통의 관심사>를 설명하려고 애쓰고 있군’하고 생각하는 독자가 있다면 만점이다. ‘공통의 관심사(crosscutting concern)’라는 개념을 이해했다면 상황중심 프로그래밍의 98%를 거의 이해한 것과 다름이 없다.

이러한 스파이로그를 실제로 구현하는 방법은 어렵지 않다. 소프트웨어가 객체지향 기법에 따라서 계층별로 잘 분리되어 있다면 더욱 그러하다. 각 계층의 시작과 끝 부분에서 시간을 측정하는 데 필요한 동작을 수행하기만 하면 되기 때문이다. 하지만 그것이 가능하기 위해서는 최소한 두개의 전제 조건이 필요하다. 하나는 스파이로그를 구현하는 프로그래머가 각 계층의 입구와 출구를 정확하게 파악하고 있어야 한다는 점이고, 두 번째는 스파이로그를 구현하기 위해서는 입구와 출구에 해당하는 객체의 소스 파일이 수정되어야 한다는 점이다. 즉, 입구에 해당하는 위치에서는 앞의 계층에서 전달한 시간 측정용 객체를 받아들인 다음 들어온 시간(time stamp)을 찍고, 출구에 해당하는 위치에서는 같은 객체 위에 나가는 시간을 찍고 나서 뒤에 있는 계층에게 객체를 전달해 주는 것이다.

이런 방법은 기능적으로는 아무런 문제가 없지만 코드의 관리라는 측면에서 보면 문제가 많다. 한 가지만 예를 들자면 이런 식이다. 시스템에 A, B, C, D라는 네 개의 계층이 존재한다고 하자. 하나의 동작(operation)이 완성되려면 A, B, C, D, C, B, A라는 완성된 사이클이 그려져야하고, 스파이로그는 이러한 일곱 단계가 소비하는 시간을 각각 측정해서 기록한다.

그런데 나중에 누가 C 계층을 리팩토링해서 그것을 C1과 C2라는 두 개의 계층으로 분리했다고 가정해보자. 그리고 스파이로그의 존재를 의식하지 못한 그가 C1이 받아들인 객체를 C2에게 전달하는 것을 깜빡 잊었다고 하자. 이와 같은 본의 아닌‘실수’가 도입되는 순간 C1과 C2 사이의 고리가 끊어지면서 스파이로그의 기능은 동작을 멈출 수밖에 없다.

여러 계층이 공유하고 있는‘공통의 관심사’가 단지 한계층에서 발생한 실수 때문에 완전히 동작을 멈춘다는 것은 공정하게 들리지 않는다. 뿐만 아니라 스파이로그의 기능이 여러 소스 파일에 분산되면서 코드의 관리가 어려워진다는 단점도 존재한다. 이러한 상황은 서로 독립적으로 분할되어 있어야 하는‘객체’라는 존재를 중심으로 하는 프로그래밍 방법론으로는 명쾌하게 해결되기 어렵다.

객체는 본질적으로 다른 객체와 나란히 서 있도록 만들어진 존재이지, 다른 객체의 허리를 가로지르며 직교(orthogonal)하도록 만들어진 존재가 아니기 때문이다. 바로 이와 같이‘난처한 상황’에서 힘을 발휘하는 것이‘상황중심’의 프로그래밍이다.


제록스 팔로알토연구소에서 탄생    

상황중심 프로그래밍이라는 개념은 제록스 팔로알토 연구소에서 탄생한 것으로 알려져 있다. 현재 캐나다의 브리티시 콜롬비아 대학의 컴퓨터 사이언스 교수인 그레고르킥잘레스(Gregor Kiczales)는 팔로알토 연구소에서의 연구를 확장해서 현재 상황중심 프로그래밍 세계에서 대표적인 언어로 인정받고 있는 AspectJ를 설계했다. IBM에서도 HyperJ나 관심 변경 환경(Concern Manipulation Environment)과 같은 상황중심 프로그래밍 언어를 발표했지만, 현재 프로그래머 사이에서 널리 받아들여지고 있는 언어는 단연 AspectJ이다.

상황중심 프로그래밍에서 사용하는 개념은 크게 네 가지가 있다. 접점(pointcut), 안내(advice), 내부타입 선언(inter type declaration), 그리고 이들을 모두 묶어서 하나의 단위로 추상화하는 상황(aspect)이 그들이다. 상황중심 프로그래밍이나 이러한 개념들이 의미하는 바는 AspectJ의 홈페이지 등에서 쉽게 접할 수 있다. AspectJ에 대한 책도 이미 적지 않게 나와 있다. 여기에서 이들이 의미하는 바를 간단하게 살펴보자면 이렇다.

우선 접점(pointcut)은 공통의 관심사가 여러 개의 객체나 계층을 가로지를 때 그들과 만나게 되는 지점을 의미한다. 앞에서 살펴본 예에서는 각 계층의 입구와 출구가 접점에 해당하고, 더 앞에서 든 예에서는 모사드, CIA, KGB의 요원들이‘정보 브로커’와 만나는 상황 자체가 접점에 해당할 것이다. 접점은 상황중심 프로그래밍을 수행하는 프로그래머가 이미 존재하는 소프트웨어 시스템을 이해하고 있는 수준, 혹은 핵심을 짚어내는 안목에 따라 제대로 짚어질 수도 있고, 엉뚱한 곳이 접점으로 인식될 수도 있다. 어쨌든 프로그래머가 일단 접점을 골라냈으면 그 다음에 할 일은 그 곳에서 할 일을 정의하는 것이다.

그것이 안내(advice)이다. 상황중심 프로그래밍에서 안내는 객체지향 프로그래밍에서의 메소드에 해당한다고 생각하면 쉽다. 특정한 접점에 이르기 직전이나 혹은 직후에 어떤 일을 할 것인가를 정의하는 알고리즘이 안내의 내용을 이룬다.

내부 타입 정의(inter type declaration)는 약간 복잡하다. 이것은 자바 프로그래밍과 같은 기존의 프로그래밍 방식에 익숙한 사람들에게 개념적인 혼란을 초래하기 때문이다. 자바 언어를 예로 들자면, 어느 객체에게 새로운 인스턴스 변수(instance variable) 혹은 필드(field)를 추가하는 것은 언제나 소스 코드의 수정과 컴파일을 통해서 이루어진다.

프로그램이 실행되고 있는 도중에 새로운 필드를 내 마음대로 추가할 수는 없는 것이다. 자바 런타임(runtime) 내부에서 클래스 이름만 가지고 클래스의 인스턴스를 만들어내는 기능은 있지만 클래스에 이미 정의되어 있지 않은 필드를 더하는 기능은 없다.

그런데 상황중심 프로그램에서 사용하는‘내부 타입 정의’기능은 객체에게 새로운 필드를 동적으로 더하는 것을 가능하게 만든다. 이러한 기능이 필요한 이유는 이미 존재하는 다양한 객체와 계층을 가로지르면서 동작하는 알고 리즘을 작성하기 위해서는 주어진 객체의 정해진 틀을 뛰어넘는 능력이 필요하기 때문일 것으로 추측된다. 사실 필자 역시 상황중심 프로그래밍에 익숙하지 않기 때문에 섣불리 말하기는 어렵지만, 이러한 기능이 바람직한지에 대해서는 의문이 든다.

상황중심 프로그래밍을 구사하는 프로그래머가 어느 객체에게 내부 타입 정의 기능을 이용해서 동적으로 어떤 필드를 추가했다고 해보자. 그는 객체를 정의하고 있는 클래스에 새로운 필드를 사용하는 알고리즘을 추가할 수도 있다. ‘( 내부 타입 정의’기능을 통해서 추가한 필드가 퍼블릭으로 정의되어 있다면 기존의 자바 코드에서 접근하는 것이 가능하기 때문이다.)

이렇게 작성된 소스 코드를 나중에 읽는 다른 프로그래머는 (특히 그가 상황중심 프로그램의 존재를 인식하지 못하고 있다면) 도대체 이 코드가 사용하고 있는 필드가 어디에 정의되어 있는 것인지 알 길이 없다. 이런 식의 혼란은 미묘한 버그의 원인이 될 수 있다.

이런 측면에서 보자면 내부 타입 정의를 이용하는 것은 멀쩡한 객체에게 뼈를 깎고 살을 붙이는 성형수술을 시도하는 것, 혹은 객체의 유전자를 조작해서 없던 장기를 만들어 내는 것에 비유할 만하다. 수술이나 유전자 조작이 필요한 결과를 낳는다면 다행이지만, 잘못된 결과를 낳거나 그것이 남용된다면 차라리 하지 않느니만 못한 일이 될 것이다.

마지막으로, 객체지향 프로그래밍에서 클래스가 변수와 메소드를 한 곳에 묶어서 하나의 객체로 추상화하듯, 상황중심 프로그래밍에서 사용되는 접점, 안내, 내부 타입 정의를 한 곳에 묶어서 추상화하는 것은‘상황(aspect)’이다. 따라서 상황은 객체지향 프로그래밍에서 객체가 중심에 서있듯이 상황중심 프로그래밍에서 가장 중심에 서있는 개념이 된다(이것은 프로그래머들이 혐오하는‘중복’된 표현처럼 들린다. 하지만 달리 표현할 방법이 없다. 상황중심 프로그래밍에서 중심은 상황이기 때문이다).


출처 : 임백준(월스트리트 금융전문가) & 소프트웨어 산책외 다수 저자
    

설정

트랙백

댓글

trace 예찬론

Programming/Etc 2007. 3. 9. 00:48
action script를 코딩하다 보면 중간 중간 내가 작성하는 코드가 syntax error가 없는지 수시로 체크를 하게 되는데 그 단위는 코드 100줄을 넘지 못한다. 코딩을 하면서 중간에 딴 생각을 하다가 엉뚱한 방향으로 흐르는 경우도 있고 손가락의 강약 조절과 위치 파악을 제대로 하지 못한 손가락의 잘못도 있다.(결코 내 잘못 아니란다 쿠쿠)

대부분 syntax error로 수정이 가능한 것들이나 가끔은 overflow의 문제로 한참을 헤매는 경우도 종종 있다. Overflow의 경우는 컴파일러가 정확히 어느 위치에서 overflow가 발생했는지를 알려주지 않는 과계로 중간 체크를 하지 않고 코드를 길게 늘리다 보면 쉽게 문제가 되는 부분을 찾기가 어려울 경우가 있다.

더군다나 overflow가 발생했다는(플래시는 255번 이상 스택이 쌓이면 overflow가 발생한다.) 것을 output 패널 창에 보여주면 그나마 다행이지만 컴파일러가 한참을 계산하고서야 문제를 알려줄 때면 가뜩이나 바쁜 와중에 뒷골이 땡긴다.

이런 문제는 반복문에서의 조건문이 무한하거나 undefined일 경우 흔히 발생하게 된다. 가끔 사이트를 돌아다니다 보면 이런 문제로 브라우저를 종료해야 되는 경우가 종종 보이는데 외부에서 xml 데이터를 받아와서 처리해야하는 구문이 있다면 xml이 로드된 시점에서 처리해야 하는데 그것을 간과한 듯 하다.

이런 문제를 미연에 방지하기 위해서는 수시로 단위별로 체크를 해야 한다. 어느 언어나 기본적으로 특정 값을 확인 할 수 있도록 print 내장 메소드를 제공하는데 플래시도 trace라는 구문을 제공한다. 언제나 감사함을 느끼는 놈이다.

개인적으로 생각해 볼 때 논리적인 error를 잡아내는 데는 trace 하나면 충분하다. 중간 중간 확인을 하고 진행한 코드라고 했을 때 문제가 발생하지 않은 시점과 문제가 발생한 시점을 파악하고 그 문제가 발생했던 부분을 훑어봐도 어디가 문제인지를 모를 때는 최초 문제가 발생한 부분의 상위부터 단계별로 trace로 문제가 될만한 변수들을 확인하고 넘어가면 어느 시점에서는 문제의 변수를 잡아낼 수 있다.

가끔 프로그래밍에 발을 들여놓은 분들을 보면 이러한 확인 절차 없이 무턱대고 코드를 작성하고 한꺼번에 컴파일을 하는 경향이 있는데, 이럴 경우에는 문제가 발생할 만한 곳을 찾기란 쉽지가 않다. 문제가 없는 부분과 문제가 발생한 부분을 쉽게 파악하지 못하기 때문이다.

물론 oop 개념의 프로그래밍을 한다면 이러한 문제를 파악하는데도 많은 도움을 받게 된다. 하나의 독립된 class로 문제를 최대한 잘게 쪼개놓으면 문제가 된 class를 쉽게 알아 낼 수가 있기 때문이다. 플래시 액션스크립트도 2.0으로 넘어오면서 어느 정도 oop개념을 도입했지만 실무에서 완벽한 oop 프로그래밍을 하기에는 쉽지가 않다. Oop 개념을 완전하게 이해하지 못한 이유도 있지만 큰 프로젝트가 아닌 경우에는 사실 그러한 개발 노력보다 시간이 더 중요한 경우가 허다하게 발생하기 때문이기도 하다.

그래서 나 또한 실무에서는 oop반 막무가내 코드 반을 섞어서 사용하고 있고 개인적인 놀이나 작업을 할 때는 되도록 oop에 신경을 쓴다. 물론 개인적인 놀이에서 그러한 것을 하다 보면 실무의 실질적인 프로젝트에서도 기억을 되살려 사용하기도 하니 그러한 놀이를 통해서 점점 oop의 필요성과 유용성을 인정하게 된다.

이야기를 하다 보니 이야기가 엉뚱하게 흐르고 있다. 이쯤에서 trace 한번 찍어보자.

var 엉뚱한변수:String = “#@$#@$@#@$#”;
trace(“엉뚱하게 이야기가 흐른 변수 = ” + 엉뚱한변수);

액션 스크립트를 떠나 존재하는 모든 프로그래밍 언어에서 print 구문이 없었다면 아마도 지금도 어셈블리어로 코딩을 하고 있을지도 모르겠다. 생각해 보니 프로그래밍도 커뮤니케이션이다.

trace(“나 여깄어…너 거기있니”);
trace(“나 여기있고 너 거기있구나”);

trace를 사랑합시다. ^^
    

설정

트랙백

댓글

어도비, 모질라에 스크립트 코드 기증

Programming/Etc 2007. 3. 6. 23:32
어도비는 파이어 폭스 웹 브라우저에서 자바스크립트 프로그램들을 실행시키는데 사용될 소프트웨어를 모질라 재단에 기부할 것임을 밝혔다. 이는 모질라 재단 역사상 최대 규모의 기증이다.

어도비는 지난 화요일(미국 시간), 샌프란시스코에서 개최되는 웹 2.0 컨퍼런스에 발맞추어, 기부 내용을 발표할 예정이다. 이 코드는 어도비와 모질라의 개발자들에 의해 관리되고 운영될 ‘타마린’ 이라는 새로운 오픈 소스 프로젝트의 근간을 이룰 것이다.

어도비 또한 ‘액션 스크립트 버츄얼 머신’ 이라 불리는, 이와 똑같은 소프트웨어를 제공할 예정인데, 이것은 어도비 플래시 플레이어9에서 스크립트 코드를 실행시키는데 사용된다.

모질라 재단의 대표 프랭크 해커는 이 가상 머신이 2008년 1분기까지 파이어폭스 브라우저의 차세대 버전에 삽입될 것이라고 말했다.

어도비 플래시 플레이어 버츄얼 머신에서 사용될 스크립팅 언어는 액션 스크립트로 적힌 프로그램을 실행시키는데, 이는 ECMA 국제 표준인 ECMA 에디션4를 기반으로 하고 있다. 어도비의 소프트웨어 설계 부문 대표 케빈 린치는 MS의 제이스크립트와 기타 유명 자바 스크립트들도 이 표준을 적용하고 있다고 말했다.

그는 “플래시 플레이어9과 함께 지난 6월 선보여진 어도비 스크립트 ‘엔진’의 새로운 버전은 실시간 컴파일러를 사용하여 이전 버전보다 10배 빠른 속도로 프로그램을 실행한다”고 설명했다.

린치는 모질라와의 거래가 어도비에게는 오픈 소스 부문에서 진행한 가장 큰 거래였다고 밝혔다. 또한 이번 결정을 통해 개발자들이 에이젝 스타일의 웹 개발과 미디어와 애니메이션을 위한 플래시를 포함하여, 이러한 프로그램 기술들을 섞고 서로 조합할 수 있게끔 만들려는 어도비의 계획을 한 걸음 더 딛게 하는 계기를 만들었다고 덧붙였다.

“우리는 이러한 공통된 언어 사용을 통해 더욱 더 광범위한 HTML과 플래시 개발자 커뮤니티들을 한 데 모을 수 있다. 똑같은 언어 엔진을 사용한다는 것 자체가 매우 큰 진전이라고 할 수 있다.” (린치)

해커는 우수한 스크립트 엔진이 파이어폭스 브라우저나 썬더버드 이 메일 클라이언트 등을 포함한 오픈 소스 프로젝트들에게는 ‘매우 중요한’ 비중을 차지한다고 말했다. 그는 상당 부분의 파이어폭스와 확장자들이 자바 스크립트를 사용하고 있다고 말했다.

또, 타마린 프로젝트 코드는 파이어폭스 브라우저에 현존하는 자바 스크립트인 ‘스파이더 몽키’를 뒤이을 차세대 자바 스크립트의 근간이 될 것이라고 덧붙였다.

출처 : ZDNet Korea

기사가 나온지 오래된 내용이지만 익스플로러 vs 파이어폭스에서 어떤 브라우저가 우위를 차지할지 궁금해지는 기사다.
    

설정

트랙백

댓글

무결점에 도전하는 아름다운 사람들의 이야기

Programming/Etc 2007. 2. 27. 02:53
 지금의 고등학교에서는 문과와 이과를 구분하여 수업을 듣고 있는지 모르겠으나 나의 고등학교 시절에는 문과와 이과를 나누어 ‘가벼운 수학’과 ‘깊이 있는 수학’으로 구분하여 수업을 들었던 기억이다. 수학이 싫다는 단순한 생각에서 이과가 아닌 문과를 지망하게 되었지만 수학은 여전히 나의 기대에 부합하지 않고 문과에서 날 괴롭혔다.
 
 그러했던 나의 선택에 그나마 스스로에게 최선을 다 하겠다며 수학 시간에 학내 도서관에서 빌린 소설책을 선생님 몰래 보면서 스스로를 위한 하곤 했다…^^; 지금은 직장생활로 인해서 전문서적을 보는 것으로 책 읽기를 대신하고 있으니 평소에 소설을 책 한 권 접하기가 쉬운 일이 아니다.
 
 그래서 얼마동안 이 두 가지 토끼(전문 서적 & 에세이 & 소설)을 잡을 욕심으로 가벼운 프로그래밍 관련 서적을 구입하여 읽었다. 읽다 보니 임백준이라는 저자의 책들을 읽게 되었는데 그 중 4권을 소개해 볼까 한다.
 
 먼저 저자 임백준은 삼성 SDS와 미국 루슨트 테크놀로지에서 소프트웨어 엔지니어로 근무했으며 월간 마이크로소프트웨어에 컴퓨터 칼럼을 연재했고 인터넷 신문 “프레시안”에 시사 칼럼을 쓰고 있는 저자다.
 책은 초판발행일자 기준으로 정리 하였다.

1. 행복한 프로그래밍 – 컴퓨터 프로그래밍 미학 오디세이
사용자 삽입 이미지

: 책 제목에 ‘프로그래밍’이라는 말이 들어가면 사람들은 대개 기술적이거나 전문적인 내용을 다루는 책을 떠올리기 마련이다. 하지만 ‘행복한 프로그래밍’이라는 제목에서 필자가 중점을 둔 부분은 “프로그래밍”이라는 명사가 아니라 “행복한”이라는 형용사다. 다시 말해서 이 책은 특정한 기술이나 전공 지식을 담은 책이 아니라 컴퓨터 프로그래밍 속에 들어 있는 미학을 전달하려는 소프트한 얘기를 담고 있는 책이다. –서문중에서
해바라기 씨앗의 배열을 닮은 피보나치 수열은 매우 아름답지만, 그것을 컴퓨터 프로그램으로 옮기는 것이 별로 어려운 일이 아니라는 사실은 나중에야 알게 됐다. 그 때에는 화면에 나타나는 숫자들을 바라보는 것만으로도 황홀감을 느낄 지경이었다 – “영혼을 녹여서 만드는 아름다운 공식” 중에서…



2. 누워서 읽는 알고리즘 – 생각하는 방법을 알려주는 알고리즘 이야기
사용자 삽입 이미지
: 이 책은 어렵고 복잡한 알고리즘을 ‘쉽게 풀어서’ 설명한 책이 아니다. 오히려 맛있는 읽을거리를 만들기 위해서 알고리즘과 같은 기술적인 내용을 ‘동원한’ 책이다. 나는 새로운 알고리즘 이론을 소개하는 것도, 독자들에게 알고리즘을 ‘강의’ 하는 것도 아니다. 즉 ‘공부’와는 아무런 상관이 없다. 나는 실전 프로그래밍을 업으로 삼고 있는 사람들과 함께 가볍게 ‘수다’를 떨면서 우리가 매일 수행하는 ‘일’이 얼마나 재미있는지, 얼마나 아름다운지 그리고 얼마나 창조적인지 확인하고 싶었다 – 서문 중에서
짧은 시간이 흐르고, 화면에 나타나는 결과를 보았을 때 필자의 가슴은 그만 철렁 내려앉고 말았다. 화면에 나타난 것은 정상적인 페이지가 아니라 페이지 수가 이미 최대 값에 도달했으므로 더 이상의 페이지를 열 수 없다는 오류 메시지였다. 모든 경우에 대해서 완벽하게 동작하는 것처럼 보였던 알고리즘안에 조용히 숨어 있던 버그가 드디어 모습을 들어낸 순간이었다 – ‘재즈로 여는 아침의 향기’ 중에서



3. 나는 프로그래머다 – 무결점에 도전하는 아름다운 사람들의 이야기
사용자 삽입 이미지
: 인생에 있어서 도전이란 결코 입맛에 딱 맞는 방식으로 찾아오지 않는다. 그것은 언제나 두 발을 전부 땅에서 떼서 허공에 몸을 완전히 맡겨야 하는, 따라서 상당한 불편함과 두려움을 수반하는 방식으로 찾아온다. 어렵지만 마음에 쏙 드는 일자리를 만났을 때, 어렵지만 풀어 보고 싶은 문제를 만났을 때, 어렵지만 한 번 걸어 보고 싶은 길을 만났을 때, 어렵지만 한 번쯤 말을 꼭 걸어 보고 싶은 이성을 만났을 때, 필요한 것은 앞뒤를 재고 따지는 ‘계산’이 아니라 최선을 다해서 허공에 몸을 맡기는 ‘용기’다. – 서문 중에서
이 책은 IT 각 분야에서 종사하는 7분이 모여서 만든 책이다. 김용준, 김종호, 원은희, 유영창, 이춘식, 임백준, 허광남, 임백준을 제외한 분들은 책을 많이 써보지 않은 분들이라 그런지 문장이나 형식이 자연스럽지 못하다는 느낌이 많이 들었던 것 같다. 임백준의 글이 가장 읽기 편했다. (길들여 진 것일까..;;)





4. 임백준의 소프트웨어 산책 – 소프트웨어에 대한 새로운 시선 그리고 통찰력
사용자 삽입 이미지
: 이 책은 공부를 목적으로 하는 책이 아니다. 프로그래밍과 조금이라도 관련이 있는 사람이라면 이 책을 한 손에 들고 다른 한 속으로는 새우깡이라도 먹으면서 마치 소설책처럼 읽을 수 있기를 바라면서 글을 썼기 때문이다. 사실 이 책은 소설을 담고 있다는 점에서 실제로 ‘소설책’이기도 하다. 깊이와 짜임새를 향한 결심은 지켜내지 못했지만 독자들이 이 책을 재미있게 읽을 수 있기를 바라는 마음에서 아예 소설을 한 편 쓰기도 했다. 말하자면 프로그래머가 프로그래머를 위해서 프로그래밍을 주제로 쓴 소설인데, 책의 뒤에 실려 있다 – 서문중에서
“어려운 문제를 드디어 풀어냈다는 성급한 기대가 K씨의 심장을 빠르게 뛰게 만들었다. 사실 프로그래머가 이와 같은 ‘유레카’의 순간에 느끼는 순백의 열정은 사랑에 빠진 청춘의 감격과 별로 다를 것이 없다. 적어도 그 순간만큼은 세상의 모든 사물이 그 자리에서 동작을 멈추고 시간이 정지한다. – 프로그래머 K씨의 하루 중에서




 이렇게 4권의 책을 읽게 되었다. 임백준은 프로그래밍에 숨어 있는 미학을 발견하고 프로그래밍을 통해서 세상을 이해하려는 노력을 하고 있다. 현재는 뉴욕 월스트리트에서 금융 소프트웨어를 개발하고 있다고 한다. 책의 서문이나 내용을 보면 알 수 있겠으나 대부분의 책들은 프로그래밍이나 컴퓨터 언어에 대한 해박한 지식을 요구하거나 강요하지 않는다. 그렇다고 프로그래밍과 전혀 관련이 없는 사람들이 읽기에는 공감이 가는 성격의 글이 아니기에 권하고 싶은 마음은 없다.
 
 작년 Macromedia conference MAX 2005 KOREA에서 스피커로 나왔던 Jared Tarbell은  “프로그래밍은 시와 같다”, “프로그래밍은 아트다” 와 같은 이야기를 한 적이 있다. 임백준이 프로그래밍에서 발견한 미학이라는 것이 이런 의미에서의 아름다움이 아닐까 하는 생각이 든다. 나 자신도 구조적으로 잘 짜여진 짧지만 많은 의미를 담고, 아름다울 만큼 창의적인 결과를 표현하는 프로그램을 보면 ‘아름답다’라는 표현이 가장 적절하다는 생각이 든다.
 
 얼마 전에 모 출판사에서 나에게 책을 쓸 것을 권한 적이 있다. 판매금액의 10%를 받는 조건으로 책을 쓰면 어떻겠냐는 이야기였다. 금전적인 문제를 떠나 내가 쓴 책이 일반 서점에서 독자들에게 판매될 수 있다는 것을 생각하니 결정도 내리지 않은 시점인데도 흥분되는 일이 아닐 수 없었다.
 
 며칠 동안 고민하다가 일단 샘플을 하나 만들고 간단한 구조로 내용을 담아 보았다. 그런데 가만히 내가 만든 소스와 내가 쓴 글을 보고 있으니 책으로 세상에 내놓기에는 쓰레기 같아 보였다. 소스는 순전히 개인적인 습관과 입증되지 않은 구조와 알고리즘으로 낙서를 해놓은 것 같은 느낌이 들었다.
 
 임백준의 책 속에 이런 내용이 있다. “자신이 만든 프로그램으로 만든 전투기를 직접 자신이 조정할 수 있는 용기가 있는가” 결코 쉬운 일이 아닌 듯 싶다. 더군다나 인터넷이 아닌 인쇄물로 한번 세상에 내놓으면 수정할 수도, 업데이트 할 수도 없는 책을 출간한다면 잘못된 정보를 통해 위와 같은 질문에 ‘예’라고 대답한 사람들의 사고들을 내가 어찌 감당할 수 있겠는가 싶었다. 그래서 다음날 출판사 담당자에게 기회가 되면 다음에 쓰겠다고 정중히 거절을 했던 일이 있었다. 지금도 나는 그때의 결정을 잘 했다고 생각한다.
 
 프로그래밍이 아름다음을 갖으려면 그것을 만드는 사람의 흥미와 재미, 열정과 인내가 필요한 작업이 아닐까 싶다. 혹시나 나는 인내가 어려워 가벼운 흥미와 재미를 쫓고 그것을 열정이라 자찬하고 있는 것은 아닐런지...;
    

설정

트랙백

댓글

스킨 편집 팁 : 파이어폭스와의 CSS 호환성

Programming/Etc 2007. 2. 21. 11:05
스킨 편집 팁 : 파이어폭스와의 CSS 호환성

이번에 소개해 볼것은 스킨 편집 및 웹페이지 제작 등에 쓰일수 있는 파이어폭스와의 호환성에 관한 간단한 팁입니다.

'파이어폭스와의 호환성' 이라고 예기해 봤습니다만.
사실상 파이어폭스와의 호환성이라 함은 바로 '웹표준' 을 말하는 것입니다.
인터넷 익스플로러(이하 IE)가 대다수인 실정상. 한국에서는 대부분의 웹페이지가 IE에 맞추어져 제작되어 있습니다만.
IE에만 맞추어져 있는 홈페이지는 다른 브라우져에서 그 구조가 깨어지거나 사용이 불가능할 정도까지도 될수 있습니다.
이 문제는 IE가 웹표준을 따르지 않는데서 기인하는 문제인데요.

표준에 맞추었을 경우 IE및 모든 브라우져에서 완벽하게 잘 보이는 것에 반해,
IE에만 맞추었을 경우 다른 모든 브라우져에서는 올바르게 보이지 않는 것에 비추어 보아 이것은 전적으로 IE의 문제라고 볼수 있습니다.

그러나. 웹디자이너가 아닌 이상에야 일반 사용자가,
HTML코드를 짜는데에 있어 표준이고 아니고를 맞추기가 사실 실로 힘든 부분이라 할수 있습니다.
뭐니해도 사실상, 자신이 사용하고 또한 가장 많이 사용하는 IE에서만 잘 보이면 그만이니까요.

하지만. 웹페이지라는 것의 특성상 절대적 대다수만이 아닌 소수들에게도 동일한 서비스를 제공해야 하는 암묵적인 책임이 있을 뿐더러.
IE가 아닌 다른 브라우져 사용자들은 점점 늘어나는 추세라. 비록 일반 사용자임에도 불구하고 이것은 무시하지 못할 정도의 문제라고 생각할수 있습니다.
특히, 스킨 편집을 하고자 하시는 분들은 커스터마이징이나 디자인적 관점에서의 접근을 하게 됩니다만.
다른 브라우져에서 보았을때 그것이 무참하게 깨져 버림으로써 자신의 노력이 물거품이 되는 정신적 충격을 받을수도 있습니다.

이번 기회엔 초보자도 간단히 사용할수 있는 호환성에 관한 간단한 팁을 소개해 보겠습니다.




CSS에서 가장 문제가 되는 것은 다름아닌 '박스모델' 입니다.
특히 이글루스 스킨은 레이아웃을 잡는데에 있어 박스모델이 주로 사용됩니다만.
그 코드를 작성함에 있어 IE위주로 작성한다면 필연적으로 다른 브라우져에서는 깨지게 됩니다.
결론적으로, 이 '박스모델' 만 신경써 준다면 웬만한 브라우져에서는 다 잘 보인다는 것이죠.

IE에서 박스모델이 표준이 아닌 이유는 바로 padding, margin, border 사이즈에 있습니다.
예를들어 가로와 세로가 각각 100px인 박스에 padding 10px, margin 10px, border 1px를 준다고 생각해 봅시다.
간단히 생각해 보자면 다음과 같은 코드를 사용하면 되겠지요.

예제1-IE전용

DIV.TEST{
WIDTH: 100PX;
HEIGHT: 100PX;
PADDING: 10PX;
MARGIN: 10PX;
BORDER: 1PX SOLID #000000;
}


사실, 솔직히 말해 직관적입니다. 그냥 생각한 대로 가로세로 100픽셀에 그냥 padding, margin, border 만 주면 됩니다.
그런데. 이런 식으로 코드를 작성하면 반드시 이것은 다른 브라우져에서 문제가 생깁니다.
왜냐하면, IE의 경우 가로세로 수치가 눈으로 보이는 박스 사이즈에 기준한것에 반해,
다른 브라우져가 사용하는 가로세로 수치는 눈으로 보이는 사이즈가 아닌 내용이 표시되는 부분을 기준으로 하고 있기 때문이죠.

그러니까. 눈으로 보이는 박스 사이즈가 100px라고 하면, IE에서는 그냥 100px을 적어주면 끝납니다만.
표준 브라우져에서는 그 사이즈에서 padding과 border 사이즈를 뺀 사이즈, 위의 경우에서는 78px를 적어줘야 하는 것입니다.


자. 그렇다면 코드를 작성할때 일일히 이것을 계산해서 조심스레 적어야 할까요.
...솔직히 매우 머리아프고 귀찮은 짓임에 분명합니다.
또한 이렇게 적으면 되려 IE에서 잘 보이지 않는 결과가 생길수도 있습니다. (첨부 이미지 참조)

결국 생각해볼수 있는 방법은. 바로 표준과 IE를 따로 적어주는 방법인 것이죠.
위에서 초보자라도 쉽게 할수 있다고 언급했습니다만. 이 방법이야말로 가장 간단한 방법이라고 생각합니다.
왜. 이미 모든 코드를 작성한 상태에서도 각 박스모델에 몇줄씩 추가/수정만 해주는 것으로도 호환성 상승을 노릴수 있기 때문이죠.
자. 가로와 세로가 각각 100px인 박스에 padding 10px, margin 10px, border 1px를 준다면,
표준으로는 이렇게 적어야 다른 브라우져에서 IE와 같은 모델이 보입니다.

예제2-표준

DIV.TEST {
WIDTH: 78PX;
HEIGHT: 78PX;
PADDING: 10PX;
MARGIN: 10px;
BORDER: 1PX SOLID #000000;
}


그러나. 이 박스모델 코드를 해석하는 방식이. IE가 표준이 아니기 때문에 오히려 IE에서 깨지는 현상이 생겨버리는 것입니다.
IE 쪽을 쓰기 위해서는 그냥 가로세로 사이즈를 100px를 적으면 됩니다만 그러자니 다른 브라우져에서 깨지고....
해서, 위의 코드를 적은 뒤 아래에 IE에서만 인식하는 다음의 코드를 추가해 주는 방법으로 해결할수 있습니다.

* html DIV.TEST{
WIDTH: 100PX;
HEIGHT: 100PX;
}



* html ~~ 은 IE에서만 인식되는 특수한 selector라고 합니다. 저도 이유는 잘 모르겠습니다-_-
중요한 사실은 오로지, "* html ~~ 를 적어줌으로써 표준인 코드를 비표준인 IE에도 맞출수 있다" 는 것일 뿐이겠죠.

결론적으로, 가로와 세로가 각각 100px인 박스에 padding 10px, margin 10px, border 1px를 주고 싶을때.
표준과 IE에서 전부 잘 작동하는 코드를 만들고 싶다면 다음과 같이 작성하면 간단하게 해결할수 있습니다.

예제3-절충안

DIV.TEST{
WIDTH: 78PX;
HEIGHT: 78PX;
PADDING: 10PX;
MARGIN: 10px;
BORDER: 1PX SOLID #000000;
}

* html DIV.TEST{
WIDTH: 100PX;
HEIGHT: 100PX;
}



●중요!
이미 써져있는 코드를 수정할 경우, * html ~~ 을 각 박스 아래쪽 라인에 추가한 뒤,
원래의 수치는 * html ~~ 쪽으로 옮기고, 이미 써져 있던 수치는 margin은 제외하고 padding, border 사이즈를 빼서 적어주면 됩니다.
ex) 가로, 세로 100px에 padding 10px, border 1px라면. 100px - (20+2)= 78px 입니다.



<참고 이미지>
사용자 삽입 이미지

왼쪽은 파이어폭스, 오른쪽은 인터넷 익스플로러입니다.
IE전용이 파이어폭스에서는 크게 나오는 반면, 표준은 IE에서 작게 나옵니다.
절충안을 사용하면 두개의 브라우져에서 완전히 같은 박스모델이 구현 가능합니다.




이쪽에 대해서는 사실 크게 깊은 지식이 없기에 다소의 오류를 포함하고 있을수도 있습니다.
하지만. 위에 언급한 방법은 실제 사용해 본 결과, IE및 다른 브라우져에서도 완전히 같이 동작한다는 것을 확인하였기에 이렇게 소개해 봅니다.

이글루스에서 스킨을 직접 만드시는 분들.
특히 기존 스킨의 수정이 아닌 완전히 새로 만들 경우에 한해 호환성이 문제가 될 경우가 가끔 있습니다.
(물론, 이글루스 자체는 다른 브라우져에서 잘 보이는 편이고, 공개 스킨 또한 잘 보입니다만 가끔씩 과격한 모딩이 되어있는 스킨은 깨질때가 있습니다)

실로 간단한 방법입니다만.
이 팁으로 인해 리퍼러에 약 몇%만을 차지하는 소수의 타 브라우져 사용자들에게도 떳떳하게 블로그를 보일수 있었으면 하는 바램입니다.

참고 링크: 한국 모질라 포럼

덧붙임:
이 글은 한국 모질라 포럼의 웹 표준화 프로젝트 계시판에서 CSS 박스 모델 문서를 참조하였습니다.

출처 : 안티에고이스트
    

설정

트랙백

댓글

구글의 구인광고

Programming/Etc 2007. 2. 21. 10:55

이 수학문제를 풀어야 입사지원 된다?

실리콘밸리 중심가 101번 고속도로가 통과하는 곳에 최근 광고판 하나가 달렸다. 광고판에는 아무런 설명없이 수학문제 하나만 덩그러니 담겨있다.


검색업계의 강자 구글이 아무런 표시도, 설명도 없는 광고판을 세운 이유는 이 문제를 풀 수 있는 수학적 두뇌를 가진 사람을 골라 입사 기회를 주기 위해서라고 한다. 수학자 폴 아도스의 유명한 “수학자란 커피를 정리로 변환시키는 장치”라는 말을 연상시키는 채용방법이다.


광고판에는 ‘{첫 10자릿수 솟수 e}.com’이라고 적혀있다. 답은 7427466391이다. 이 문제를 풀어 7427466391.com으로 접속해보면 2번째 관문인 다른 문제가 나오는데, 여기에도 구글이라는 이름은 없다.


2단계 문제까지 풀면 비로소 구글 연구개발부서인 구글랩 페이지로 연결되며, “구글을 키워나가면서 우리가 배운 점 한가지는 우리가 찾고자 하는 상대방 역시 우리를 찾고 있을 때, 그 사람을 더 쉽게 찾게 된다는 것이다. 우리는 세계 최고의 엔지니어를 찾고 있고, 당신은 여기에 와있다”라는 환영메시지를 볼 수 있다.


메시지는 “짐작하겠지만 우리는 엄청난 량의 이력서를 매일같이 받고 있기 때문에 이러한 절차를 이용해 ‘신호대 잡음비’를 개선하려 하는 것”이라는 말로 이어진다.


올해 말 27억달러 규모의 IPO를 준비중인 구글은 깐깐한 채용 과정으로 유명하다. 회사 설립 첫날부터 3월 31일 현재 직원수 1907명에 이르기까지 구글은 자사만의 채용 기준을 엄격히 준수해왔다.


팔로알토 차고에서 운영되던 초창기에 입사한 한 직원은 “면접 볼 때 세르게이 브린과 래리 페이지(이상 구글 공동설립인)의 책상 위에는 8권의 채용관련 서적이 쌓여 있었다”고 말했다.

구글 직원들은 많은 면접 단계를 거쳤으며, 종종 수학이나 사업전략에 대한 테스트도 요구받았다고 한다. 채용조건은 이와같은 단계가 끝난 후에나 알 수 있었다. 최근 2년 동안에는 우수 인력을 영입하기 위해 프로그래밍 대회를 개최하기도 했다.


구글이 시행한 또한가지 독특한 채용방법은 검색결과 페이지의 광고 링크를 이용한 것이다. 예를 들면 아마존의 검색기술 연구팀인 A9의 팀장 우디 맨버(Udi Manber)를 구글에서 검색하면 검색결과 오른쪽 스폰서 링크에 ‘구글에서 일하세요’라는 문구가 뜨고, 구글 구인 페이지로 연결하는 링크가 나타난다.


한편 현재 구글에서 근무하는 컴퓨터 엔지니어들은 대부분 스탠포드 대학 컴퓨터과학도 출신인 것으로 알려졌다. 이번 수학문제 광고판은 산타클라라 방향에서 롤스톤으로 빠지는 길 근처에 세워졌다. 이 회사 관계자는 상황에 따라 광고판을 더 늘릴 수도 있다고 밝혔다.


출처: ZDnet

    

설정

트랙백

댓글