• 북마크
  • 추가메뉴
어디로 앱에서 쉽고 간편하게!
애플 중고 거래 전문 플랫폼
오늘 하루 보지 않기
KMUG 케이머그

컬럼

아이폰 2.0에는 왜 플래시가 없을까?

본문

        
* 역자 주 : 2008년도 글이지만 여전히 의미가 있다고 생각하여 번역을 하였습니다. 관련 주제와 함께 생각해 볼만한 글입니다.                 
         1431422068_65ad2657a7_o.jpg

The new UI wars: Why there's no Flash on iPhone 2.0

TUE, JUN 17, 08

어도비는 맥오에스와 윈도 양측 모두에서 어도비 고유의 인터페이스를 지키는 것으로 알려져 있다. 그리고 맥 이용자들은 오랜동안 어도비를 비판해왔다. 어도비가 맥 네이티브 기술을 존중하지 않는다는 이유였다. 어도비는 10년이 넘게 포토샵에서 애플스크립트를 완전히 지원하지 않았으며, 윈도용 64비트 버전을 내놓을 때 맥오에스텐용 64-비트 버전도 내놓지 않았다.

Adobe's UI convergence

어도비의 목표는 언제나 플랫폼과 상관 없는 고유 UI 확립이었다. 맥과 윈도의 네이티브 UI가 아닌 세 번째의 대안인 셈이다. 이 과정 중에서 어도비는 네이티브 UI 패턴과 부딪히는 새로운 UI 컨벤션을 과감히 만들어왔다. 드림위버와 Thermo, Fireworks의 윈도 제목/메뉴바를 보면 알 수 있다.

cs4-windows.jpg?w=440&h=302

어도비가 꽤 성공을 거두었다고 볼 수 있다. Creative Suite 4가 나오면, 어도비는 패키지 안에 있는 프로그램 대부분의 인터페이스를 두 플랫폼 모두에서 동일하게 나오게 만들 것이다.

그러나 어도비의 플랫폼 공통 웹미디어 런타임인 플래시처럼 공통적인 UI를 성공시킨 프로그램은 없을 것이다. 기괴한 "Skip Intros"에서부터 수수께끼같은 UI 위젯에 이르기까지, "정말 이런 디자인을 했단 말인가?"라는 질문을 할 수밖에 없다. 어도비는 그동안 꾸준히 플렉스 프레임웍 안의 UI 위젯과 컴퍼넌트를 확대시켜 왔으며, 웹 상의 RIA(Rich Internet Applications) 룩앤필을 정의내리는 수준까지 이르렀다. 물론 기본 플래시/플렉스 UI 컨트롤을 반드시 이용할 필요는 없다. 필요에 따라 커스텀 스킨을 사용할 수 있기 때문이다.

flex-skin.jpg?w=440&h=256

데스크톱 시장은 이미 성숙한 시장이다. 따라서 UI 통일화는 어도비에게 유리하게 작용할 수 있다. 하지만 어도비의 다음 싸움터는 플래시 라이트(플래시의 모바일 버전)를 심비안과 윈도모바일, 자바가 지배하고 있는 휴대기기 플랫폼용 런타임과 애플리케이션 개발 플랫폼으로 확립하는 일이다.

노키아는 올해 S60 series에 플래시 라이트 3.0을 설치해서 내놓았다.

s60.jpg?w=440&h=244

Why not the iPhone?

수 백만 대 휴대폰에서 플래시 라이트를 돌릴 수는 있는데, 아이폰만은 플래시 라이트를 넣지 않았다.

아이폰에 플래시가 왜 좋은 선택이 아닌지에 대한 여러 가지 이유들이 떠돌고 있다. 플래시가 느리고, CPU를 잡아먹으며, 배터리를 소모시키고, 너무 자주 충돌하며, 맥오에스텐에 최적화되어 있지 않는 등의 이유가 있다. 물론 이 이유들은 타당하다. 그러나 당장 이 모든 문제를 오늘 해결한다손치더라도, 아이폰에 관련되는 한, 어도비와 애플 간에는 거대한 문제점이 놓여 있다. UI를 누가 통제하는가?

Adobe's conundrum

데스크톱 OS 고유의 UI 컨트롤을 피하고, 어도비 독자 크로스-플랫폼 UI 패러다임을 심어 놓는다. 그리고 멀티플랫폼에서 일관성 있게 런타임 엔진을 돌린다. 이것이 어도비의 데스크톱 인터페이스 전략이다.

그러나 어도비 입장에서는 불행히도, 애플은 현재 아이폰이라는 멀티터치 플랫폼을 최초로 대중화시켜 나아가고 있는 중이다. 그리고 아이폰은 이미 노트북 시장에 근접할 정도로 자라났다. 분명 애플은 (2005년, 애플은 FingerWorks와 그 특허권을 매입했었다) 멀티터치라는 제스쳐 패러다임을 더 넓게 확장시키고 싶을 것이다. 다른 기기도 포함해서 말이다.

gesturelib.jpg?w=440&h=310

아이폰이 나올 때, 아이폰을 다른 휴대기기와 분명 차별화시켜준 것은 아이폰이 가진 멀티터치 UI의 일관성이었다. 데스크톱의 WIMP(window, icon, menu, pointer)에서 직접 조작의 패러다임으로  크게 비약한 인터페이스라는 의미다. 컴퓨터와 소비자가전 업계에서 보아온 바와 같다.

flex-vs-iphone.jpg?w=440&h=185

즉시 다른 모든 휴대폰 업체들이 차세대 "아이폰 대항마"를 들고 나섰고, 실제로 출하한 회사도 있었다. 예상할 수 있는 일이다. 그러나 결과가 보여준다. 애플이 지닌 여러 가지 특허를 침해하거나, 아예 새로운 혁신을 만들지 않는 이상, 아이폰 UI의 유동성을 베끼기는 어렵다는 사실이 드러났다. 가령 대항마 기업들은 이정도밖에 안된다. 이 사례는 노키아 S60 휴대폰을 아이폰으로 "탈바꿈"시켜주는 플래시 라이트의 사례이다.

iphone-ui-s60.jpg?w=440&h=284

"두 번째" 페이지(영상 참조)를 가 보면, 터치 패러다임과 못난 WIMP 인터페이스의 합체를 볼 수 있다. 이 정도가지고 "아이폰 대항마"를 자칭하는 휴대폰이 절대 다수이다. 아예 멀티터치를 우회하려 하는 기업들도 있다. 가령 삼성은 제스쳐 기반의 UI를 특허화시켜 놓았다. 삼성 특허의 경우, 네비게이션과 상호반응을 위해, 휴대폰의 카메라가 손가락/손의 제스쳐를 추적하는 방식의 제스쳐 UI인데, 별로 실용성은 없어 보인다.

samsung-gestures.jpg?w=397&h=320

Apple: Not on my device!

애플은 아이폰을 선보이면서, 느리지만 확실하게 세 번째 규모이지만 메이저급 OS 플랫폼을 구축하고 있다. 적은 규모의 기기들이지만 멀티터치와 UI 미학을 덧붙인 플랫폼이 애플 플랫폼이다. 애플은 워낙에 UI와 사용감에 집착하는 회사다. 심지어 아이폰 2.0이 나올 때까지도 기본적인 베끼기/붙이기 기능을 소개하지도 않았을 정도다. 여기에 대해서는 적절한 UI 패턴을 못찾았기 때문이라는 루머가 있다.

스마트폰 시장은 차세대UI 패러다임의 확립을 두고, 경쟁이 매우 치열한 시장이다. 즉, 어도비는 물론 어느 회사에게도 애플은 크로스-플랫폼이나 공통 UI 기반에 애플 브랜드를 희석시키려하지 않을 것이다. 멀티터치에 대해 애플 고유의 방식을 밀고 나갈 것이라는 의미다. 그렇다면 어도비는 무엇을 선택할 수 있을까?

Adobe's iPhone choices

아이폰에 플래시를 집어 넣으려면 다음과 같은 방안을 생각해 볼 수 있다.

  • 애플의 아이폰 UI 컨트롤과 인터랙션 패턴을 통째로 라이센스 받아서, 플래시와 플렉스, 에어 개발 패키지에 컴퍼넌트로 집어 넣는다. Halo의 현재 기본 셋과 매우 유사한 접근이다. 그러나 애플이 그런 라이센스 약정을 체결할 것 같지는 않다.

  • 아이폰 UI를 그대로 베끼고, 애플 IP 법무팀의 위협을 무시해버린다. (한 때 UI 침해를 했다면서 매크로미디어를 고소한 회사가 어도비였다. 아이러니컬한 방안이다.)

  • 아이폰 호환 플래시 컴퍼넌트 제작을 써드파티에 맡겨버린다. 법적인 문제도 그들이 해결하도록 놓아둔다.

  • 하나는 아이폰 UI 패러다임을 따르고, 다른 하나는 다른 기기용으로 나누는 방안이 있다. 이렇게 할 경우 플래시 라이트로 만든 중요한 애플리케이션이 아이폰이나 다른 기기에서 깨질 수 있다(최소한, 깨져서 보일 수 있다). 드래깅이나 더블클릭과 같은 가장 간단한 플래시 UI 패턴조차도 멀티터치 플랫폼은 완전히 다른 개념이기 때문에 아이폰에서 제대로 작동하지 않을 것이다.

  • OS 네이티브 컨트롤을 무시하고 고유의 UI 패러다임을 쓰던 플래시의 오랜 "3자-플랫폼 전략"을 포기한다. 따라서 플래시 디자이너와 개발자들이 이제 OS에 특화된 문제를 해결해야 하는 상황이 된다. 이 경우 아이폰 멀티터치용으로 디자인한 UI가 아이폰보다 못한 기기에서는 부드럽게 돌아가지 못하게 될 것이다.

  • 아이폰과 다른 플랫폼용으로 별도 버전을 만들도록(디자인하도록) 독려한다. 하지만 이렇게 해서야 멀티-플랫폼 앱을 지향하는 플래시의 목표가 사라지게 된다.

  • 멀티터치 제스쳐 특허를 침해하지 않는 제스쳐 라이브러리를 플래시용으로 개발한다. 아이폰의 애플과 경쟁을 벌일 수도 있겠고, 아이폰을 무시하여 반-아이폰 멀티터치 플랫폼을 새로이 만들 수도 있겠다. (이를 위해서 구글에 접촉하여 안드로이드용 기술을 들여올 수도 있을 것이다.)

이론상 생각해본 이러한 방안은 물론 실용적이지 않다. 애플이 통제하는 "앱스토어"를 통과하지 않고서야, 아이폰에 합법적으로 써드파티 앱을 설치할 수 없기 때문이다.

Apple's Flash choices

다른 플랫폼과 너무나 차별화된 애플의 멀티터치, 그리고 직접-조작 방식의 아이폰 UI는 어도비 전략을 분명히 뒤흔들었다. 플랫폼과 기기들 간에 네이티브가 아니면서 일관성 있는 UI를 담보하자는 것이 어도비의 전략이었다. 최근 애플은 칩디자인 기업인 PA Semi를 인수하였다. 무슨 의미일까? 차후 나올 아이폰 플랫폼을 차별화시키겠다는 의미다. 애플 스스로 디자인한 SOC(system-on-chips)을 만들어서, 아예 써드파티나 클론 업체의 길을 막아버리겠다는 의도이기도 하다. 애플만이 부착 가능한 하드웨어 컴퍼넌트를 통해 아이폰 UI의 여러가지 기능이 개선될 것임은, 상상하기 그리 어렵지 않다. 따라서 어도비나 다른 업체들이 애플과 싸우기는 점점 더 어려워질 것이다.

그렇다면 아이폰용 플래시는 도대체 어떻게 될까? 아이폰이 플래시 없이 성공할 수 있을까? 애플의 숙제가 바로 여기에 있다.

전문가들은 아이폰에 "플래시"가 없기 때문에 일어날 수 있는 문제로, 보통 플래시 비디오 스트리밍을 예로 든다. 그러나 애플 입장에서 볼 때 유튜브는 해결하기 오히려 쉬운 문제다. 구글과의 약정에 따라 제일 거대한 플래시 비디오 업체인 유튜브가 비디오를 널리 퍼진 업계-표준, H.264 코덱으로 바꿔가고 있기 때문이다. 이 코덱은 퀵타임 영상으로도 볼 수 있다. 어도비 또한 플래시 플레이어 9에서 주요 비디오 코덱으로서 H.264를 채택하기도 하였다.

플래시가 없다는 의미는 브라우저 안에서 돌아가는 RIA(Rich Internet Applications) 런타임, .swf가 없다는 의미다. 데스크톱 상의 AIR가 없다는 의미이기도 하다. 이전에 논의했듯, 어도비 플래시나 마이크로소프트의 실버라이트, 썬의 자바FX와는 달리 애플은 멀티미디어/RIA 런타임을 갖고있지 않다. 이 세 회사가 모두 자신들의 런타임을 아이폰에서 돌리고 싶어함을 공개적으로 드러냈지만, 애플은 지금까지 전혀 그들에게 관심을 보이지 않고 있다. 전문가들의 압박은 거대하다. 그러나 스티브 잡스가 직접 나서서, 아이폰용 플래시는 "너무나 느려서 유용하지 않다"면서, 플래시 라이트는 "웹에서 사용할 정도도 못된다"며 일침을 해 놓았다.

mobileapps.jpg?w=440&h=174

애플의 "RIA 런타임"은 사실상 WebKit이다. 앞으로 나올 MobileMe 앱은 웹브라우저 안에서 Ajax-기반의 UI를 보일 텐데, 이 형태의 UI는 데스크톱용 프로그램이나 플래시를 통한 RIA만큼 효과적일 수 있다. 달리 말해서, 애플의 메시지는 이러하다. "아이폰용 앱을 네이티브로 만들고 싶으면 Cocoa Touch를 선택하시라. 크로스-플랫폼(사파리 모바일도 포함한다)을 노리고 있다면 Ajax를 선택하라." 복잡한 메시지가 아니다.

지난 해 한 애플 개발자 문서를 보면 플래시에 대해 다음과 같이 나와 있다. (아이폰용 웹 애플리케이션과 컨텐트 최적화라는 제목이다.) 플래시는 "지원하지 않는 기술" 섹션에 딱 하나의 아이템으로 올라와 있다.

"아이폰용 컨텐트로서 플래시와 자바는 비파게 될 것이다. 아이폰용 최신 플래시를 다운로드하도록 하지도 말아야 한다. 플래시나 다운로드 모두 아이폰용 사파리에서 지원하지 않기 때문이다."

어도비는 분명 아이폰용 플래시 런타임을 엔지니어링하여 애플을 설득시키려 노력할 것이다. 플래시가 꼭 필요하다면서 말이다.



The new UI wars: Why there’s no Flash on iPhone 2.0
위민복님이 번역한 글입니다.
0 0
로그인 후 추천 또는 비추천하실 수 있습니다.
회원사진
포인트 765,229
가입일 :
2002-05-23 22:53:10
서명 :
KMUG 애플에 대한 모든 것. 케이머그
자기소개 :
2000년 3월 1일 부터 시작 http://www.kmug.co.kr webmaster@kmug.co.kr

최신글이 없습니다.

최신글이 없습니다.

댓글목록 24

청범님의 댓글

  플래시 보다는 플래쉬를 먼저...

담배님의 댓글

  /청범 아 ..한국말 어렵습니다..ㅋㅋㅋ

怪獸王님의 댓글

  사전에는 플래시로 되어 있네요.

없어요님의 댓글

pighair님의 댓글

  어도비꺼나 불켜는 도구나 flash고 외래어 표기법에 따르면 플래시가 맞지요. 캐쉬가 아니고 캐시고... '윈도우즈'가 아니고 '윈도즈'고요.
어색할지라도 표기법이 그렇습니다.

Fenrir님의 댓글

  사실 웹디 하다보면 이것저것 만들기 편해서 플래쉬를 쓴 경우가 많았는데

만들고 나면 무겁죠 좀.. 많이... =ㅅ=...
이쁘게 만드는 것도 좋지만 로딩 뜨면서 카운트 돌아가는거 보다가
짜증나서 창 닫은 적 다들 한 번쯤은 있지 않으신가요?

요즘은 최대한 간단하고 빠른 페이지를 만들려고 노력중입니다.
이것저것 이쁘게 꾸미는 것도 중요하지만
웹페이지 방문한 사람들이 빠르게 볼 수 있는게 가장 중요하겠죠.

좀 좋은 대안이 나온다면 좋겠네요.
이쁘기도 하고 빠르게 로딩되는  :)

동성...님의 댓글

  결국, 아이폰에 플래시가 달리느냐 안 달리느냐는
'누가 먼저 포기하느냐'에 달렸군요.
공룡과 공룡이 싸우다보니 이건 뭐... -_-

Deminoth님의 댓글

  오 이거 좋은글이네요..

loveapo님의 댓글

  imac/플래쉬가 왜 죽은 기술입니까?? 얼마나 많은 사이트들이 플래쉬를 사용하는지 모르시나 보군요. 기술이 죽었으면, 사용을 안할텐데 아직 많은 사이트들은 플래쉬가 들어갔거나 플래쉬로 돌아가죠. 그리고 웹표준 가이드를 플래쉬와 함께 얘기하시다니 웃기지도 않군요. 웹표준이 뭔지나 알고 얘기하시는지 모르겠군요. 플래쉬는 웹표준에 준하는 기술입니다. 익스플러워, 파이어폭스, 사파리 등 여러 브라우저에 균일하게 돌아가죠. 무엇에 대해 평하려면 먼저 그것이 무엇인지 알고나 얘기하심이 좋을듯 합니다.

박순규님의 댓글

  물론 플래쉬가 무겁긴 하지만 현재 상황에서는 없는게 불편한건 확실하죠. 많은 사람들이 HTML5로 이주한다고 해도 HTML5가 플래쉬를 대체할때 까지는 많은 시간이 걸릴겁니다. 예전에는 스마트폰들의 기능자체가 많이 떨어지다보니 플래쉬를 넣을 생각을 안했다 하더라도 요즈음같이 스마트폰이 파워풀해진 시대에 꼭 넣지 않아야 할 이유도 없다고 봅니다. 그러다 보니 많은 스마트폰 OS들--심비안, 팜 WebOS, 안드로이드--이 점차 플래쉬를 구동하겠다고 하는거구요. 사실 풀 브라우징을 큰 장점으로 내세우는 아이폰에서 플래쉬가 없다는건 좀 아이러니 하더군요 (특히 3GS넘어오면서).

이현진님의 댓글

  플래시 자체가 웹표준인지 아닌지는 잘 모르겠으나, 확실한건 같은 플래시를 써도 익스플로러에서만 제대로 돌아가는 플래시가 존재한다는 것입니다. 그것은 바꿔말하면 플래시의 존재 자체가 웹표준은 아니라는 말이되겠죠. 플래시의 사용법도 웹표준에 맞춰야 한다는 말 입니다. 플래시 에니메이션 같은경우는 적용되지 않겠지만, 플래시로 UI를 구성하는 메뉴의 경우에는 문제가 됩니다. 심지어 어도비사이트를 가봐도 플래시는 엄청 제한적으로 사용됩니다. 네비게이션같은곳에서 플래시를 쓰지 않고 있습니다. 이것만으로도 말 다한거 아닐까 합니다.

trexx님의 댓글

  플래시가 웹표준이라고요? 완전 어불성설입니다. 웹표준이 되려면 기술공개가 선행되어야 하는데 어도브는 그럴 마음이 없지요.(라이센스하고는 별개로)
표준에 대한 이해를 먼저하셔야 할 것같습니다.
위키에서 발췌했습니다.
Non-standard and vendor-proprietary pressures

In the current Working Draft of the HTML 5 proposed standard document,[11] the W3C has a section entitled "Relationship to Flash, Silverlight, XUL and similar proprietary languages" that says, "In contrast with proprietary languages, this specification is intended to define an openly-produced, vendor-neutral language, to be implemented in a broad range of competing products, across a wide range of platforms and devices.

trexx님의 댓글

  이곳에 와서 깜짝 놀랐습니다..
멀티 플랫폼과 웹표준을 혼동하여 이해하는 분이 계시다니...
플래시는 멀티 플랫폼 지향할 뿐이지(멀티플랫폼을 완전히 따르지 못합니다.) 웹표준이 아닙니다.
플래시요? 죽은 기술인지 아닌지 모르지만 멀티 플래폼에서도 멀어져간 기술이긴합니다. 리눅스, 맥 퍼포먼스 보면요..

trexx님의 댓글

  loveapo 님//
님께서 "무엇에 대해 평하려면 먼저 그것이 무엇인지 알고나 얘기하심이 좋을듯 합니다. " 먼저 선행 하셨으면 하네요.
저는 항상 댓글을 달면서 위키페디아와 구글에서 정보를 뒤져보고 나름대로 판단해서 올립니다.
다른 분 댓글 중에 논리에 어긋났거나 사실과 다른 의견이 달렸다고 해서 그 사람을 향해서 판단하며댓글을 달진 않았으면 합니다.

loveapo님의 댓글

  trexx 님 //
글쎄요.. 제가 플렉스 개발을 3년, 플래시 액션 스크립트 개발자로 2년 일해서 인지 위키페디아 구글 서치는 님보다 많이 해봤을 것 같군요. 플래시를 웹표준에다가 맞춰 넣으려고 하는 정신은 한국인들밖에 없는것 같은데, 굳이 비판을 위해 플래시를 웹표준에 넣어야할 필요가 있을까요? 웹표준을 위한 시도는 좋습니다. 하지만, 플래시가 과연 웹표준의 기준 위에다가 넣어야할 기술일까요? 웹표준을 얘기하려면 웹표준 기술이 필요한 기술에다가 말씀하십시오. 기반 자체가 다른 플래시를 가지고 웹표준을 맞춰야한다면, trexx님은 플래시의 기반을 바꿔야 한다는 말처럼 들리군요. 저는 그런 생각에 더 놀라게 되는군요. 그렇다면 님이 생각하시는 어도비의 플래시, 플렉스가 웹표준을 위해 바꿔야하는것은 무엇일까요? 답은 한가지겠죠. 플래시를 쓰지말자

이현진님의 댓글

  trexx 님은 한입으로 두말하시네요..아까는 플래시가 웹표준 기술이라고 하시더니 이제와서는 플래시가 왜 웹표준이어야 하냐고 ..ㅋㅋㅋ 플래시가 없어지면 밥줄끊기게 되시니 충분히 이해는 하겠습니다만.............

이현진님의 댓글

  플래시를 웹표준에다가 맞춰넣으려고 하는 정신이 한국인들밖에 없다니요? 온갖 쓰레기 플래시는 한국인들이 만들어 내고 있는데요? 멀티브라우져에서 안돌아가는 플래시는 한국사이트밖에 없더군요..대체 플래시로 뭔 짓거리를 하면 다른브라우져에서 구동이 안되는지가 궁금할 정도 입니다. 웹표준 안지키는 한국인들때문에 한국의 웹 환경은 재앙수준 입니다.

trexx님의 댓글

  loveapo // 플래시는 어도브에서 절대 웹표준으로 하지 않을 겁니다. 제가 언급도 안한 내용을 쓰시는 군요.
제 생각을 정리해 드리지요.
1. 플래시는 웹표준이 아니다. (어도브는 멀티플랫폼을 지향하지 웹표준을 원하지 않는다.)
2. 웹표준은 우리나라에서 정하는 것이 아닙니다. 제발 웹표준에 대해 검색해 주시길 바랍니다. W3C 가 주축으로 IETF, ISO, 등 에서 기술공개를 원칙으로 표준을 정합니다.
3. 플래시가 웹표준에 넣어야한다고 언급한 적이 있던가요?

trexx님의 댓글

  이현진님//  전 플래시가 없어지길 바라는 사람으로 밥줄하곤 전혀 관계 없습니다. 정부출연연구원 작년 웹기획하면서 접근성을 고려하여 메뉴 등에서 플래시를 없애야한다고 주장했던 사람입니다. 그래서 우리 연구원은 플래시를 완전히 날렸습니다.

trexx님의 댓글

  loveapo 님// 정말 검색을 많이 해보셨다면 플래시가 웹표준이 아니라는 것쯤은 아셨어야 하지 않을까요? 모르셨다면 검색해서라도 자신의 오류를 검증하시고요. 검색을 왜 하시나요? 그냥 자기 주장의 근거를 만들려고요?
지식 검색은 새로운 지식을 유입함도 중요하지만 자신의 지식이 오류가 있음을 확인하는 것이 더 중요하다고 봅니다.
처음에 님께서 '플래시가 웹표준'이라고 해놓고 제가 위키페디아에서 '플래시는 웹표준이 아니다'라고 말하니 '나는 더 검색한다' 라고 답변하니 할말이 없습니다.
좀 자신의 정보의 오류를 인정하면 안됩니까? 그게 그렇게 어렵습니까?
저또한 웹기획 초기에 멀티플랫폼과 웹표준에 대해 개념이 불분명했었고 누군가 그 개념을 정확히 파악해주어 오류를 수정했습니다.
전 그분에게 현재도 아주 감사하고요. 제가 검색한다는 뜻은 댓글을 달기전에 감정적으로 자기 지식만을 믿지 말고 적어도 확인 정도는 해보는것이 좋지 않을까 싶습니다.
그리고 그 말은 님이 하셨죠.
"무엇에 대해 평하려면 먼저 그것이 무엇인지 알고나 얘기하심이 좋을듯 합니다. "
전 이말에 대한 답변으로 글을 쓴 것입니다.

steppinthe님의 댓글

  loveapo // 발언이 애매모호하게 비켜가려고만하듯느껴지네요 잘 모르셨던거같은데..

이현진님의 댓글

  trexx 님 죄송합니다..사람을 헷갈렸네요..ㅜㅜ 전 loveapo 닙에게 한 말이었습니다. ㅜㅜ 정말 죄송...ㅠㅠ

trexx님의 댓글

  이현진 님// 네.. 내용을 읽어보니 저한테 하신 말씀이 아니신 것 같았습니다. 이렇게 댓글 달아주시니 제가 송구스럽습니다. 감사합니다.

멍구님의 댓글

  어찌됐든 참 좋은 글 잘 읽었습니다

전체 2,464 건 - 83 페이지
2010.02
25

애플과 구글, 개방과 통제의 승부

http://news.nate.com/view/20100224n12890mid=n0607 개방’과 ‘폐쇄’는 구글과 애플이 선택한 사업전략이기 때문에 선악이나 우열의 잣대로 비교하는 것은 타당하지 않다. 애플은 하드웨어로부터 소프트웨어까지 아우르…

2010.02
22

iPad에서 플래시가 안돌아가는 이유

RoughlyDrafted MagazineDaniel Eran Dilger in San Francisco An Adobe Flash developer on why the iPad can’t use FlashFebruary 20th, 201…

2010.02
22

아이패드 인사이드: 어도비 플래시

Saturday, February 20, 2010 Inside Apple's iPad: Adobe Flash By Daniel Eran Dilger Published: 12:00 AM EST Apple's new iPad is bei…

2010.02
22

유럽은 스마트폰의 지배력을 어떻게 잃었는가

How the smartphone made Europe look stupidThe European giants that pioneered the mobile telecoms industry are now stumbling in the wake of A…

2010.02
17

플래시 보안문제에 관해..

플래시를 통해 멀웨어 설치가 가능한 보안홀 발견 http://news.cnet.com/8301-10784_3-9954408-7.html      플래시를 통해 시스템의 모든 권한을 장악할수 있는 보안 문…

2010.02
12

구글 버즈와 페이스북

Google v FacebookGenerating BuzzFeb 11th 2010 from The Economist print edition The search giant makes a belated attempt to take on the …

2010.02
12

애플의 마이크로소프트화

TOP STORIES INOpinionOpinion: The Microsofting of Apple OPINION: BUSINESS WORLD FEBRUARY 10, 2010The Microsofting of AppleBy HOLMAN W. JENK…

2010.02
12

스티브의 단추혐오증

The Wiki ManRORY SUTHERLAND WEDNESDAY, 27TH JANUARY 2010 A fortnightly column on technology and the web 필자는 비행기나 거미를 두려워하지 않는다. 혹은 친구…

2010.02
11

앱스토어 성공요인은 "훌륭한 개발자 경험(DX)"

애플 앱스토어의 성공요인은 사용자경험(UX:User Experience)뿐만이 아닌 훌륭한 개발자경험(DX:Developer Experience) 박동윤 | http://www.cre8ive.kr 2008년3월 스티브 잡스의 SDK와 A…