Yonghwan's Blog

유튜브를 거실에서 볼 수 있게 된단다.

지금 세상은 좌회전인지 우회전인지는 몰라도, 어쨌든 크게 꺾어 가고 있는 것 같다. (어쩌면 이런 변화는, 앞으로의 세상에서 변화가 아닌 일상이 되어버릴지도 모르겠다.) 그런 변화의 물결 가운데 하나가 바로 멀티미디어의 변화, 확장, 일반화가 아닐까 한다.

수동적으로 바라만 보던 TV 방송이 양방향성을 갖게 되어가고 있으며 전파에 의존하던 방송 전송기술이 인터넷 프로토콜에 기반한 형식으로 빠르게 변화하고 있다. 이런 변화 속에서 많은 회사들이 대어를 낚기 위해 노력을 아끼지 않고 있다. 많은 회사들이 방송 제공자를 위한 서버측 솔루션을 개발하여 공급하고 있거나 공급하려 노력하고 있으며, 사용자측의 단말기 등을 생산, 공급하기 위하여 피를 말리는 경쟁에 돌입하여 있고, 또한 네트워크 인프라 확보와 활용에 대한 움직임도 심상치 않은 상황이 펼쳐지고 있다.

이런 와중에 눈에 띄는 제품이 하나 있으니 AppleTV. 이름에서 알 수 있듯이 매킨토시 컴퓨터로 유명한 애플사에서 만든 TV, 아니, 셋탑박스(사용자 단말)이다. 딱 보니 애플이다. 이쁘단 말이다. 기계도 그렇고 UI도 이쁘다. 눈에 띈다. 혼자 있어도 눈에 띄는 녀석이 이제는 YouTube와 함께 한덴다!

별거냐구? 그래. 별거 아니다. 단순히 PC에서 즐기던 UCC Video 서비스를 TV에서, 거실에서 즐길 수 있게 된다는 뜻일 뿐이다. TV를 즐겨 보지 않는 내게도 그렇고 외국의 컨텐츠가 대부분인 유튜브 역시 내게 큰 매력은 없다. 날 들뜨게 하는 것은, 유튜브나 애플티비가 아니라 바로 그들의 "동거" 그 자체이다. 공중파 방송, 인터넷 동영상, 인터넷 망을 이용한 VOD, 등으로 진화/분화하던 멀티미디어 세상이 이제 그 경계를 허물어 가고 있다는 느낌을 강하게 받았기 때문에, 그들의 동거에 내가 들뜨고 있는 것이다.

YouTube Coming to Apple TV

it’s bringing the Internet’s most popular originally-created content from YouTube to the living room with Apple TV™. Beginning in mid-June, Apple TV will wirelessly stream videos directly from YouTube and play them on a user’s widescreen TV. Using Apple TV’s elegant interface and simple Apple Remote, viewers can easily browse, find and watch free videos from YouTube in the comfort of their living room.

그런데 우쒸!...

사과 과수원의 스티브 잡스 아저씨가 하시는 말씀이... "애플티비는 취미"란다. 그들의 핵심이며 기반이었던 매킨토시, 음악 서비스 사업 iTunes, 그리고 최고의 iPod 이라고 표현한 iPhone 사업과 함께 애플이 진행하고 있는 취미란다.

남들은 젖먹던 힘까지 다하여 낑낑대면서도 툭툭 나가 떨어지는 IPTV, 셋탑박스 사업을 그들은 취미로 한단다. 아니, 오히려 그래서 취미로 한단다. 오호라... 이럴 때 벌할 수 없는 괘씸죄가 성립한다. 이미 사라져버린 영국 그룹 "퀸"의 네 멤버 중 둘은 석사, 둘은 박사라는 말을 들었을 때보다 더 괘씸하다!

Steve Jobs live from D 2007 - Engadget

Steve Jobs is up here in just a few, everybody. It looks like we can probably prepare ourselves for an update on the iTunes shift to no-DRM, the status of the iPhone, and whatever else is on El Jobso's mind. It's all on Mossberg, so hopefully he'll drill down deep to the topics we hold near and dear. Stay close, you'll know when it gets underway! (Note: Walt's questions are in bold.)

Those in search of eternal life need look no further than the computer industry. Here, last gasps are rarely taken, as aging systems crank away in back rooms across the U.S., not unlike 1970s reruns on Nickelodeon's TV Land. So while it may not be exactly easy for Novell NetWare engineers and OS/2 administrators to find employers who require their services, it's very difficult to declare these skills -- or any computer skill, really -- dead.

1. Cobol
2. Nonrelational DBMS
3. Non-IP networks
4. cc:Mail
5. ColdFusion
6. C programming
7. PowerBuilder
8. Certified NetWare Engineers
9. PC network administrators
10. OS/2

As the Web takes over, C languages are also becoming less relevant, according to Padveen. "C++ and C Sharp are still alive and kicking, but try to find a basic C-only programmer today, and you'll likely find a guy that's unemployed and/or training for a new skill," he says. (see also: "Hot Skills, Cold Skills ")

북마크만 의미없는게 아니다. 파일도 늘 다시 받고 있다. 참 우습다!

요즘, 디스크를 정리하는 일이 반복되다 보니 재미있는 현상, 습성을 발견했다. 생전 다시 보지도 않는 파일들이 널려있다는 점이다. 그냥 욕심에 받아놓은 것들도 있는 것 같고, 오래되었지만 읽지 않은 문서도 있다. 일부는 같은 프로그램의 다른 버전이 발견되기도 하고, 혹은 같은 파일이 중복되어 나타나기도 한다. 또는 왜 받아뒀는지 기억도 나지 않는 것도 있고... 아무튼 넘치는 디스크가 꼭 인터넷 같다는 생각이 든다. 반 휴지통이다. :-)

더 웃기는 것은, 어쨌든 관심이 가는 녀석은 받아보고, 풀어보고, 또는 나중에 보겠다는 생각으로 보관해두고 있다지만 정작 다시금 그것이 궁금해졌을 때 예전의 것을 찾아보기 보다는, 나는, 어느덧 다시 다운로드를 하고 있었다는 것이다.

바보같기도 하고 좀 우습기도 한데, 문제는 단순히 이미 받은 것을 (네트워크 자원을 낭비해가며?) 또 받는데 있지 않다. 이 현상에 주목하고 깜짝 놀란 진짜 이유는...

내 컴퓨터와 인터넷이 과연 별개인가? 경계가 존재하는가?

하는 의문이 들었다는 점이다.

• 나는 내 컴퓨터 위에서 놀고 있는 것일까? 아니면 인터넷 위에서 놀고 있는 것일까?
• 내 컴퓨터는 내 컴퓨터일까? 아니면 인터넷의 일부일까?
• 혹은 내 컴퓨터는 단지 인터넷 단말기일 뿐인가?

"호텔은 잠자리를 제공하는 곳이다." 라는, 기본적인 명제 하나로는 칭찬받는 호텔을 만들 수 없다. 최선의 기본과 함께 최소한의 배려, 입장 바꿔 생각하기가 완벽한 서비스를 만드는 것이 아닐까?

How to Change the World: Airline Boarding Pass Kiosk

The Hyatt Regency hotel at McCormick Place in Chicago, Illinois has a very helpful solution to this problem: an airline board pass printing kiosk. It’s very helpful and shows that someone was thinking about the customer. I hope that the person who thought of the kiosk sees this blog posting.

코드리뷰에 대한 좋은 글이 있어서 인용한다. 그런데, 한 문장도 빼놓기가 아까운게... 잔뜩 인용해버렸다. :-)

BSBlog » Blog Archive » The Power of Code Review

For the most part, reviewers are not responsible for ensuring correct code function: unit tests are much better suited to that task. What reviewers are responsible for is much more “social”, and typically does not require a detailed line-by-line analysis of the code to perform a review. In many cases, important parts of the review process should happen before a coder starts working on a patch, or after APIs are designed but before implementation.

There are some important side effects of the review process that are also beneficial:

• More than one person knows every piece of code. Many Mozilla modules have grown a buddy system where two people know the code intimately. This is very helpful because it means that a single person going on vacation doesn’t imperil a release or schedule.
• Reviewing is mentoring. New hackers who are not familiar with a project can be guided and improved through code review. Initiall, this requires additional effort and patience from the reviewer. Code from inexperienced hackers deserves a much more detailed review.
• A public review log is a great historical resource for new and experienced hackers alike. Following CVS blame and log back to bug numbers can give lots of valuable historical information.

There can’t really be general guidelines on how much time to spend reviewing. Some experienced hackers may spend up to 50% of their time doing reviews (I typically spend two days a week doing design and code reviews and various planning tasks). This can be hard, because coding feels much more productive than reviewing.

나의 지론, 휴가 가고싶으면 잘 하란 말이다.

재밌네. 누군가 번역하여 둔 것을 먼저 봤으나, 원본의 것을 붙인다. 역시 우리만의 문제는 아닌게다.

원본은 : (project.jpg 그림, JPEGx800 픽셀)

현재 안랩코코넛의 대표이사이시며 IBM, 안철수연구소 등에서 22년간 IT 산업에 종사하셨다는 이정규님의 글.

ZDNet Korea...문서작성의 5가지 口訣

공공기관의 입찰 선정 심사위원으로 참여한 적이 몇 번 있었다. 내공이 있는 심사위원은 제출된 문서의 형식만 척 보아도, 업체의 역량을 가늠해 볼 수가 있다. 커버에 반드시 있어야 할 제목, 부제목, 작성일자, 작성자명, 작성자 이메일, 부서명, 회사명, 문서의 비밀등급을 제대로 기입하였다면 잘 된 문서이다. 특히, 문서의 파일명을 귀퉁이에 기재한 경우는 정보검색의 효율을 관리하고 있다는 반증이 된다. 요약문과 구조화된 목차, 흔히 오리발 조항이라는 disclaimer의 유무, 약자의 설명페이지가 있다면 외형적 형식은 아주 잘 되어 있는 것이다. 그러나, 품격 있는 문서는 그 이상이 필요하다.

나의 문서는... 품격있는 문서의 그 이상은 그렇다 치고 외형적 형식은 얼마나 잘 맞추고 있는걸까?

커버, 제목, 부제목, 작성일자, 작성자명, 메일 등... 은 그렇고, 근래에는 비밀등급표기는 해본적이 없네. 근래의 문서는 모두 내부 열람용이었으나 그래도 표기는 필요했겠다. 왼쪽 상단의 파일명 또는 제목 표기는 문서철의 기본. 요약문과 목차도... 뭐 잘 하고 있네. 그런데 디스크라이머? 역시 비밀등급, 디스크라이머 등에 있어서 외부용 문서로써의 부분은 별로 신경써오지 않은 것이 사실이군.

일단, 기본에서 한 수 배움.

"생각이 없음"

(제목을 바꾸고 내용의 일부분, 이 위치에 있던 인용부분, 을 지웠다. 인용했던 글을 다시 읽어보니 스크랩 금지란다. 뭐, 나와는 다르더라도 그렇게 생각하신다면... :-)

뭐, 컴퓨터나 두들기는 쟁이가 "철학" 운운하면 좀 우스운가? 그런데, 철학이라는게 (한자어로 표현해서 그런지) 말은 좀 거창하지만 그 뜻은, "'생각' 하며 살자" 보다 더 크지 않은 듯.

개발자에게는 적어도 두 줄기의 철학이 필요하다. 그 중 첫번째는 물론, "사용자에 대한 배려"이다. 내가 만든 이 프로그램이, 이 기계가, 이 서비스가 사용자에게 어떤 행복을 줄 수 있을까? 또는 사용자의 행복을 빼앗게 되지는 않을까 하는 고민이 필요하다. 이것이 엔지니어와 취미생활의 차이가 아닐까?

다른 한 줄기는 "(주변과) 어울림"이다. 내가 만든 것이 어디에서 움직이는지를 생각하고 그 곳에 어울리도록 모양을 잡고 속을 채워야 한다. 사람의 삶이 그렇듯이, 기술, 도구 역시 어울림 속에서 그 빛을 발할 수 있고 기쁨을 만들어 낼 수 있다.

예전에, 한 10년도 더 전에, 나에게 많은 실망을 줬던 프로그램이 하나 있었는데, 그것은 다름아닌 당시의 "국민 프로그램", "아래한글" 의 첫 윈도 버전이었다.

윈도95 시대에 들어오면서 윈도가 비로소 DOS에서 벗어나 나름의 철학을 가지고 움직이기 시작했다. 예를 들면 윈도 3.1 시절의 .ini 라는 파일 기반의 설정 방식에서 벗어나 중앙의 규격화된 인터페이스의 레지스트리 방식으로 전환했다든지, 또는 C:\DOS 라는 자기 집만 챙기던 방식에서 나름의 계층화된 저장 구조를 이용하게 되었다든지...

그런데 문제의 "아래한글"은 그 철학을 전혀 존중해주지 않았으며(디렉토리에 대하여 아직도 독자적인 노선을 걷고 있고...) 심지어는 그래픽 툴킷까지도 독자적인 것을 사용하는 "만행(?)"을 저지르고 있었다. (게다가 더 향상되거나 편리해진 것도 아니었다. 단지 자신들의 기존 방식을 유지한 정도랄까?)

그들의 철학을 지키기 위해서 그랬다면, 듣자하니 별 것도 아닌데 무슨 상관이냐고? 그 무렵의 나는 이런 저런 이유로 윈도 기반 중앙 집중 관리식 전산실을 구성하여 관리하고 있었는데, 이 부분에 있어서는 윈도의 방식과 어울리지 않는 부분을 헤쳐나가기 위하여 이런 저런 꽁수와 삽질을 하지 않을 수 없었다. 그래서? 별로 행복하지 않았다는거지. 따지고 보면 극히 소수에게만 느껴지는, 그래서 무시할 수 있다고 생각하는(이것도 철학인데) 부분이라면? 뭐, 그냥 그렇다는 거다. 철학의 문제이니. :-)

요즘도 철학을 무시하는 경우를 가끔, 심심치 않게 볼 수 있다. 리눅스/유닉스의 세상은 비교적 잘 정리된, 뿌리가 있는, 그리고 오랜 기간 동안 다듬어진 철학을 가지고 있다. 반면, 근래의 리눅스 기반 프로그래머 중 일부는 리눅스/유닉스 세상에 대한 이해로부터 출발하여 "철학이 있는 개발"을 하기 보다는 돈이 되는 것 같아서 "아는 범위에서 일"을 하는 것 같다. 그러나 그 뿌리를 다른 곳에 두고 있고 그 범위 안에서 일을 하게 되므로 결과적으로 주변과 어울리지 않는 것을 만들어내는 것이다.

심각하다. 최근에는 프로그램의 임시 파일을 /usr/local/XXX/log 아래에 남기는 프로그램을 본 적도 있는데, 일반 사용자가 그 곳에 파일을 쓸 수 있을까? 혹시나 쓸 수 있도록 설정한다고 하여도 그것이 근본 철학과 맞는 것일까? 항상 root 계정으로 리눅스 PC를 사용하는, 마치 Administrator가 윈도의 기본 사용자이듯, 비전향 리눅스 개발자의 작품이겠지.

/home 아래에 MySQL, Apache, PHP 등의 패키지를 설치하여 사용하는 모습도 보인다. 엉뚱한 위치에 설치된 것은 물론이고 왜 공식적으로 배포되는 다듬어진 것을 사용하지 않고 직접 일을 만들어가며 하는 것이지?

이런 "철학의 부재"는 어디서 나타난걸까? 어떻게 하면 치료될까?

무선인터넷 재도약을 노리는 이통사 내건 새 전략이다. “휴대폰에서 이런 서비스가 가능하다” “IP 기반의 새로운 무선인터넷 서비스가 등장했다” 등 기술 우위의 서비스 전략에서 탈피하겠다는 취지다. 소비자에게 진정 필요한 서비스를 찾아낼 때 관련 산업도 활성화 될 수 있다는 기초로 돌아가겠다는 전략이다.

스크린은 여러 프로세스, 특히 대화형 쉘 들이 물리적 터미널을 함께 사용할 수 있도록 해주는 전체화면 창관리자이다. 각각의 가상 터미널은 DEC VT100 터미널의 기능과 더불어 ANSI X3.64와 ISO 2022 표준의 몇몇 제어 기능(예들 들어 줄의 삽입/삭제와 다중문자셋 지원 등)을 제공한다...

Screen is a full-screen window manager that multiplexes a physical terminal between several processes, typically interactive shells. Each virtual terminal provides the functions of the DEC VT100 terminal and, in addition, several control functions from the ANSI X3.64 (ISO 6429) and ISO 2022 standards (e.g., insert/delete line and support for multiple character sets). There is a scrollback history buffer for each virtual terminal and a copy-and-paste mechanism that allows the user to move text regions between windows. When screen is called, it creates a single window with a shell in it (or the specified command) and then gets out of your way so that you can use the program as you normally would. Then, at any time, you can create new (full-screen) windows with other programs in them (including more shells), kill the current window, view a list of the active windows, turn output logging on and off, copy text between windows, view the scrollback history, switch between windows, etc. All windows run their programs completely independent of each other. Programs continue to run when their window is currently not visible and even when the whole screen session is detached from the users terminal.

• 여러 프로그램을 동시에 실행하기 위하여 여러개의 접속(telnet이나 ssh 등)을 만들어야 한다.
• 작업이 오래 걸리는 프로그램의 실행을 유지하기 위하여 접속을 끊을 수 없다.
• 대화형 작업이기 때문에 스크립트로 처리할 수 없다.

• 여러개의 접속 대신 단일 접속 안에서 여러 가상 터미널을 만들 수 있다.
• 가상 터미널을 살짝 떼어 놓았다가 다시 새 연결(새 물리적 터미널)에 붙일 수 있다.