태터데스크 관리자

도움말
닫기
적용하기   첫페이지 만들기

태터데스크 메시지

저장하였습니다.
블로그 이미지
Lonewolf dlbo

calendar

1 2 3 4 5 6 7
8 9 10 11 12 13 14
15 16 17 18 19 20 21
22 23 24 25 26 27 28
29 30          

Notice

'(비정기) Dlbo's Post'에 해당되는 글 70

  1. 2010.09.27 [모토로이]Dream of Ubiquitous, Naver Ndrive.(2)
  2. 2010.09.27 [모토로이]Virtual My Sweet Home. Naver Blog.
  3. 2010.09.27 [모토로이]World on Hand. Naver Map.
  4. 2010.09.27 [모토로이]Mobile Lifestyle Innovation, 네이버.
  5. 2010.04.29 파일시스템 - 08. MFT가 무엇인가?(3)
  6. 2010.04.14 파일시스템 - 07. MFT가 무엇인가?(2)
  7. 2010.04.05 dlbo's 포스트 연기 공지
  8. 2010.03.27 파일시스템 - 06. MFT가 무엇인가?(1)
  9. 2010.03.21 dlbo's 포스트 연기 공지
  10. 2010.03.15 파일시스템 - 05. NTFS 개요.(2)
  11. 2010.03.13 dlbo's 포스트 연기 공지
  12. 2010.03.07 파일시스템 - 04. FAT 엔트리의 내용, 디렉터리.
  13. 2010.02.28 파일시스템 - 03. FAT 12, FAT 16! FAT 엔트리 부분?(1)
  14. 2010.02.16 파일시스템 - 02. FAT 파일시스템.
  15. 2009.06.23 파일시스템 - 01. 개요.(1)
  16. 2009.06.16 프로그래밍이란?(4)
  17. 2009.06.09 Dlbo's Post 연기 공지.
  18. 2009.06.02 코드 최적화, 어떻게, 왜 하는걸까?(9)
  19. 2009.05.26 자유에는 그만큼의 책임이 따른다.(5)
  20. 2009.05.19 Design Pattern & Network, 5. 간략한 UDP 서버.(2)
  21. 2009.04.25 Dlbo's Post 연기 공지(2)
  22. 2009.04.21 Design Pattern & Network, 5. 간략한 TCP/IP 서버.
  23. 2009.04.14 Design Pattern & Network, 4. 네트워크, 프로토콜.(6)
  24. 2009.04.07 Dlbo's Post 연기 공지.(1)
  25. 2009.03.31 Design Pattern & Network, 3. Observer & Client.(3)
  26. 2009.03.24 Design Pattern & Network, 2. Singleton & Server.
  27. 2009.03.19 Design Pattern & Network, 1. Introduction.
  28. 2009.03.15 Dlbo's post 연기 공지
  29. 2009.03.10 Generic Algorithm with C++, Last -min, max, foreach
  30. 2009.03.03 Generic Algorithm with C++, 08 - find & searching!(2)
2010.09.27 13:32 (비정기) Dlbo's Post


 

 

 

 

 

 

 

 

 

 


 

 


 
 



  날씨가 갑자기 추워졌습니다. 지난 21일 갑작스런 홍수때, 서울 경기 지방 분들은 다들 무사히 잘 넘기셨는지요. 저희집은 다행히 고지대라 마당에만 물 조금 차고 말았습니다. 국철 경인선은 아예 전철이 서버렸더군요.

 

  그렇게 비가 미친듯이 오고 나니 이제 정말 가을입니다. 낮에는 덥지만 아침저녁으로 춥네요. 일교차가 무지하게 큰게 무슨 사막에 사는것 같습니다. 매 리뷰마다 말을 꺼냈던 저희집 개는 아침저녁으로 집안에 들여보내 달라고 문을 박박 긁어댑니다. 그냥 개면 털 밀고 들여보내겠는데, 진돗개를 털을 다 밀어버리면 좀 슬프잖아요. 그래서 신문지좀 내다 놨더니 혼자서 자기 몸에 똘똘 두르고 잘 잡니다. 진돗개면 좀 집좀 지키지 잠만 자네요. 개팔자가 상팔자입니다.

 

  어느덧 그냥 앞만 보고 달려온 리뷰가 마지막을 달립니다. 1부당 4회씩, 총 2부를 기획한 이 리뷰는 이번 N드라이브 리뷰가 마지막입니다. 사실 느티나무님의 N드라이브 리뷰를 보고 상당히 자신감이 다운되었던 터라, 다른 리뷰는 쓰던 중 조금씩 손 보고 N드라이브의 리뷰는 처음부터 완전히 내용을 갈아엎느라 좀 오래걸렸습니다. 최종 검수까지 다 하고 나면 25일 오후에나 모두 올라가지 싶은데, 무언가 좀 민망하기도 하네요.

 

  이 리뷰는 이벤트가 종료된 후, http://studyinglw2.tistory.com 에 제 닉네임 Lonewolf dlbo의 이름으로 게제됩니다. 프로그래밍에 관심 있으신 분들은 추후 한번씩 놀러와 주세요. 멤버들의 사정으로 현재 활동이 거의 얼어있습니다만, 조만간 다시 활발해 질 겁니다.


 


 

  새로운 IT계의 길이 열렸습니다. 애니악이니 뭐니 하는 공룡만한 크기의 컴퓨터에서 시작해서, 어느덧 제 손에 들려있는 모토로이라는 코딱지만한 기계가 이제 그 시절의 공룡보다 머리가 더 좋습니다. 세상 참 좋아지지 않았습니까?

 

  이런 IT 세상에 또 다른 길이 열리고 있습니다. 생활과 IT의 융합. 리모콘 하나로 TV뿐만 아니라 컴퓨터도 끄고 켤 수 있게 되고, 실수로 켜놓고 나온 가스불을 핸드폰으로 끌 수도 있는 시대입니다.

 


 
 http://kr.news.yahoo.com/service/news/shellview.htm?linkid=4&articleid=2010091303000048810&newssetid=1352

 

  얼마나 돈을 벌어야 저런 집을 살 수 있으련지.... 뭐, 열심히 돈 벌다 보면 언젠가 살 수 있겠지요? 그런데, 유비쿼터스 하면 참 아이러니하게, 이 친구가 최강입니다.

 


 

 

  도라에몽.... 이정도면 정말 최강의 유비쿼터스 로봇입니다.

 

  유비쿼터스라는게 무엇인가 하면, 언제나(anytime), 어디서나(anywhere) 원하는 정보를, 원하는 데이터를, 원하는 액션을 IT의 힘을 빌려 아무곳에서나 자연스럽게 할 수 있는 것을 말합니다. 그리고 이걸 해내는 컴퓨팅 기술을 유비쿼터스 컴퓨팅이라고 하지요. 컴퓨터로, 혹은 컴퓨터에 준하는 단말기를 이용해 어디서나 컴퓨팅을 하는 겁니다.

 

  유비쿼터스 컴퓨팅이 자리를 갖추기 전에, 저장용량에 대한 부분이 참 애매한 포지션이었습니다. 1개의 중앙 서버에서 네트워크 디스크 형식으로 데이터를 저장하느냐, 혹은 각각의 단말기들이 독자적으로 소량의 디스크를 가지고 서로 동등한 관계로서 데이터를 주고 받느냐. 이 문제가 상당히 오묘했습니다. 어짜피 데이터의 양은 오고 갈 수준이 비슷했고, 보안 등의 문제를 고려할 때 한 군데에 데이터를 몰아넣는게 가장 바람직하다는 결론이 나오게 되었습니다.

 

  그리하여 p2p를 변형한 웹하드 서비스가 발전하게 되었고, 여러 웹하드 서비스가 갑작스레 엄청나게 폭풍처럼 쏟아져 내려가며 춘추전국시대를 열어가는 판에, 4국시대로 줄여나갈 강력한 4대 강자가 있었으니, N드라이브, 세컨드라이브, U+Box와 외산 dropbox입니다.
 

 

 

 

 

  이 넷의 웹하드 서비스는 상당히 발전적이며, 유저 친화적인 유비쿼터스 컴퓨팅에 근접해 있습니다. 어디서나 언제나 접근 가능한 유비쿼터스 웹하드 시스템이라고 부르면 되겠군요.

 

  이 중, 오늘의 주인공 N드라이브는 얼마나 대단한 물건인지 알아보겠습니다.


 



 

  네이버로 치면 안나오길래, n드라이브로 검색하니 나오더라구요. 이름을 네이버 N드라이브로 해 두었으면 좋았을텐데. 별 네개 반의 평이한(?) 총점을 가지고 출발합니다.

 
 

 


 

  1.0.6버전에 1.32MB. 생각보다 작은 용량입니다. 최근 업데이트로 폰에서도 파일당 200MB까지 업로드가 가능하며, 이로 인해 요즘 추세인 고용량 야동의 N드라이브 업로드는 매우 힘들겠습니다.

 

이번 N드라이브의 개발자 이메일은 좀 개발자 이메일 같네요. android_nd@naver.com 이네요. 근데 저번 Naver 포털 어플리케이션 리뷰때 쓴 이메일은 아직 답변이 안왔어요. 이 리뷰 다 보고 나시면 답변좀 부탁드려요~ 뒤늦게라도 Q&A 내용 넣고 싶네요;

 

  N드라이브는 웹페이지를 써 봤을땐 정말 감격했습니다. 일단 hwp를 자체 뷰어로 보여줬으니까요. 네이버 N드라이브의 안드로이드 어플리케이션은 안드로이드 단말기의 삶을 어디까지 유비쿼터스로 이끌어 줄 까요?

 

 

 


 

  N드라이브는 기본적으로 네이버의 포토앨범 서비스와 연동이 됩니다. 추후 Naver Word와 연동되어 문서의 작성과 관리가 용이해지며, 유비쿼터스가 아니라 아예 모바일 오피스를 차려버릴 기세입니다. N드라이브가 아직 베타인 점을 감안하면, 앞으로의 발전할 길도 정말 무궁무진하지요.

 

  N드라이브의 최초 실행화면입니다. 상당히 깔끔하고 네이버 다운 디자인입니다만, 왠지 아이폰의 최초 실행화면을 그대로 가져온건 아닐까 싶기도 합니다. 네이버 N드라이브가 제공할 수 있는 것들을 그대로 최초실행화면에 한 편의 그림으로 다 담아냈군요.

 

  로그인 화면입니다. 자동 로그인을 설정할 수 있으며, 설정하지 않을 경우 원하는 다른 아이디로 로그인이 가능합니다. N드라이브에서 제공하지 않는 유저간 공유 기능을 그냥 아이디 바꿔 접속하는걸로 땜빵 가능합니다.

 

 

  N드라이브의 메인화면. 테스트를 위해 올린 파일들이 보입니다. 이 파일들은 테스트를 위해 dropbox, U+box, 세컨드라이브에 모두 업로드한 상태이며, 저 파일들의 업/다운을 통해 N드라이브만한 물건이 없음을 확실히 느꼈지요.

 

  먼저, 가장 중요한 hwp 파일을 디립따 열어보았습니다. 한국에서 가장 많이 쓰는 문서 파일 형식이자 유명한 녀석인데,

 

  이거... 웹페이지에서는 지원하지만 어플리케이션에서는 지원하지 않아 조금 실망한 감이 있었습니다.

 

  안드로이드 네이버 N드라이브 어플리케이션에서는 웹페이지와는 다르게 폰의 내장 뷰어를 이용하여 파일 보기를 제공합니다. 간단히 말해, hwp는 지원할 수 없었다는 것이죠. doc파일은 모토로이의 내장 퀵오피스를 통해 뷰잉이 가능했습니다.

 

  N드라이브에서 자체 jpg 뷰잉은 됩니다. 안타깝게도, 미리보기의 성격이라 사진의 확대/축소는 지원되지 않네요. 하단에는 4개의 버튼이 있는데, 이게 버튼인지 아닌지 약간 묘한 느낌입니다. 상당히 직관적인 인터페이스로, 화살표가 옆으로 가면 보내기, 별표는 중요 파일 표시, 화살표가 아래로 가면 다운로드, 쓰레기통 모양은 삭제입니다.

 

  폴더 내부를 보는 모습입니다. 폴더 구조를 채택 안하면 참 골아픈데, 폴더별로 정리해 놓을 수 있어 다행입니다. 심지어, 이 파일들 자체 뷰어로 재생도 가능합니다.

 

  여기서 매우 슬펐던 사실. 인코딩 안되어 있으면 재생은 되나 안보입니다. 슬퍼요... 대신, 모토로이에 들어있던 Wolfman의 예고편은 잘 나왔습니다.

 

  단지 동영상 재생중에는 어떻게 캡쳐를 해도 사진에 안나와서 안습.

 

  이렇게 어플들을 백업해 N드라이브에 올려 둘 수도 있습니다. 문서파일 형식이 아니라 전송이 자유롭지는 않지만, 한번 올려두면 N드라이브에서 다운받지 않고 바로 실행이 가능합니다.

 

  모토로이용 버그픽스버젼 프링을 뷰어로 실행한 결과입니다. 이렇게 다운로드 하지 않고 자체적으로 바로 인스톨이 가능합니다. 리뷰 쓰느라 알아낸 기능이지만 이후로 정말 잘 쓰고 있습니다. 어플은 일단 N드라이브로~

 

  최초 화면에 있던 안내문구의 jpg파일을 제 메일로 보내보았더니, 딱 10분만에 제 네이버 메일을 거쳐 지메일을 통해 모토로이로 전달되었습니다. 꽤나 빠르고 바람직한 전송속도입니다. 일단 N드라이브의 네이버 서버를 통해 바로 첨부되기 때문에 메일에 파일 첨부시 평시 첨부보다 속도가 비교 불가능할 정도로 빠릅니다.

 

  이렇게 즉석에서 N드라이브에 올린 사진을 블로그에 포스트로 보내버릴수도 있습니다. 네이버 블로그 유저라면 SD카드에 사진을 저장할 필요도 없이 바로 모바일 블로깅이 가능해 지는 것이지요. 거기에 웹페이지를 로딩하지 않고 바로 블로깅 해주니, 이 얼마나 대단한지요!

 

  이건 모토로이로 찍어서 N드라이브에 업로드해둔 사진입니다. 정말 개팔자가 상팔자네요. 주인은 리뷰쓰느라 똥줄타는데, 개 주제에 정말 곤히 잘 자고 있습니다.

 

  메인화면에서 우측 상단을 보면 올리기 버튼이 있습니다. 이걸 누르면 이렇게 어떤걸 업로드 할 지 물어보게 됩니다. 아직 N드라이브가 베타인지라, 사진, 음악, 동영상만 업로드가 가능합니다.

 

  이 중 사진을 골라 업리스트에 담고, 여러개의 파일을 전송 가능합니다. 다만, 여기서 아쉬운 점이, 한 파일을 고른 후 아무런 말 없이 다음 파일을 고르라고 뷰어가 또 나온다는 겁니다. 약간 난감하지요.

 

  이렇게 사진을 즉석에서 찍어서 바로 올릴 수도 있습니다. 블로거들에겐 꽤나 바람직한 기능.

 

  음악은 이렇게 음악 뷰어를 통해 고를 수 있습니다. 클릭시 헛갈리지 않도록 해당 음을 재생해주나, 설정으로 좀 막을 수 있었으면 좋겠더군요. 혹은 재생해서 확인할지 물어보는 방법으로... Millennium을 골랐는데 순간 놀랬습니다.

 

  이렇게 업로드 리스트에서 원하는 파일을 추가할수도, 삭제할수도 있습니다. 원하는 파일들을 골라서 한번에 업로드가 가능하지요. 파일당 최대 200MB까지 지원합니다. 물론 모든 파일의 크기 합이 10GB가 넘어가선 안되겠지요? 폰으로 그렇게 하면 용량도 용량이거니와, 모토로이라면 불타오를지도 모릅니다.

 

  올리기에서 안타까운 점은, 무조건 루트에만 업로드가 된다는 것. 요리조리 많이 시도해 봤지만 결국은 루트 폴더에만 업로드가 되더라구요. 그렇다고 안드로이드에서는 파일의 이동/변경이나 폴더 생성이 지원되지 않습니다.

 

  이렇게 자기가 동영상인양 재생됩니다만, 음악만 나오니 안심. 잘 재생됩니다.

 

  폴더 내에서 원하는 스타일로 정렬이 가능합니다. 아주 기본적인 이름순 정렬이 디폴트로 설정되어 있고, 중요표시순, 종류순, 변경일순으로 원하는대로 설정이 가능하지요. 내림차순/오름차순 선택도 가능했으면 좋았지 않을까 싶습니다.

 

  N드라이브의 포토앨범 서비스입니다. 하드웨어 메뉴 버튼을 눌러 스트립메뉴를 띄우면 네이버 포토앨범 서비스를 볼 수 있습니다. N드라이브에 사진을 업로드하면 포토앨범에서 자동으로 분류해서 보여주며, N드라이브와 연동되기 때문에 메일을 통해 사진관에서 바로 사진관 주인분께 전송해 사진 인화를 하는 스마트폰 유저다운 모습을 보일 수도 있습니다.

 

 

  아직 네이버 N드라이브가 베타버전임을 감안하면, 상당히 많은 기능을 지원하고 있음을 알 수 있습니다. 폰에서의 업로드, 다운로드가 모두 지원되며 컴퓨터에서의 N드라이브도 시스템에 마운트되어 사용자들은 아무것도 몰라도 자기 하드디스크처럼 사용이 가능하고, 업/다운 속도 또한 매우 빠릅니다. 다운로드 받지 않아도 바로 실행이 가능하며, 부분적이지만 자체 뷰어 기능도 지니고 있습니다. 몇몇 부분에서 타 웹하드보다 밀리는 부분이 있기는 하지만, 전체적으로 안드로이드 웹하드중에서는 가장 강력합니다.


 


 

  N드라이브와 경쟁이 가능한 웹하드로는 dropbox와 U+Box, 세컨드라이브가 있습니다. 모두 안드로이드에서 다운로드가 가능한 웹하드 서비스인데요, 이들과 하나씩 비교한 부분을 아래에 표로 정리해 보았습니다. 하단의 표는 안드로이드 단말기에서의 지원에 따라 작성하였습니다.

 

 

 N드라이브

 세컨드라이브

 U+Box

 Dropbox

 사용자 편의성

 한국에 특화

 한국에 특화

 자동 영상/음악/사진 분류 제공

 매우 간편한 인터페이스

 제공 용량

 10GB

 1TB

 1GB

 1GB

 폰에서의 업로드

 지원(음악/영상/사진)

 미지원

 미지원

 모든파일 지원

 업로드 제한

 파일당 200MB

 

 

 없음

 파일 저장 기한

 없음

 1개월

 없음

 없음

 동영상 자동 인코딩

 지원 안함

 요청한 파일만 인코딩, 하루 개수 제한

 업로드시 자동으로 인코딩

 지원 안함

 자체 문서 뷰어

 jpg, 동영상, mp3 플레이어 지원

 지원 안함

 지원 안함

 지원 안함

 다운로드 없이 실행

 뷰어가 있다면 가능

 지원 안함

 동영상, 사진, 음악에 한함

 지원 안함

 사진 자동 정리

 포토앨범 서비스로 제공

 지원 안함

 사진 폴더에서 지원

 지원 안함

 문서 정리 기능

 추후 Naver Word와 연동

 소식 없음

 문서 기능 지원 안함

 폴더 생성 및 파일 이동 가능

 파일 공유 기능

 지원 안함

 지원 안함

 지원 안함

 지원함

 

  의도적으로 타 웹하드 서비스들의 장점을 골라서 비교 대상을 추려봤는데, 그렇게 해도 N드라이브는 대부분을 지원합니다. 그것도 베타버전 주제에 말입니다. 생각보다 골때리는 물건이네요. 탐색기의 능력이이 부족하고, 몇몇 특정 파일만 업로드가 가능하다는 점에서는 Dropbox에 밀리지만, 그렇다고 아예 지원을 안하는건 아닙니다. 다른 방법으로 돌려서 사용이 가능합니다.

 

  동영상 자동 인코딩이 상당히 아쉬운 부분입니다. 인코딩 하지 않고 그냥 바로 재생시켜 버려 강의파일의 음성만 나온게 참 아쉬웠습니다. mp3파일들에 대해서도 아쉬웠던 부분이, 보통은 음악을 재생할때 여러 곡을 돌려서 듣지 1개 파일만 듣지는 않거든요. 그런데 이 부분은 어느 웹하드 서비스에서도 지원하지 않더라구요. 여러 미디어 파일을 리스트로 재생 가능하면 좋지 않을까요?

 

  이것 저것 모두 지원하면서도, 절대 어정쩡하지 않습니다. 모든 부분이 평균점 이상입니다. 뚜렷한 장점은 존재하지 않지만, 뚜렷한 단점이 존재하는 것도 아닙니다. 현재 베타버전임을 감안하면, 정식 버젼으로 릴리즈 된다면 정말 최고의 서비스가 되지 않을까 싶습니다.


 


 

  아직 끝나지 않은 비교. Google Docs를 아십니까?

 

  국내엔 아직 정식적으로 지원하지 않는 구글 Docs는 Naver Word와 비슷한 시스템입니다.

 

  Google Docs는 웹페이지에서 문서를 쉽게 편집하고, 관리하며, 공유할수 있는 서비스입니다. 한국에는 아직 본격적으로 서비스를 제공하지 않지만, 어떤 파일이든 업로드하고 어떤 파일이든 쉽게 공유하며, 쉽게 문서를 편집, 작성할 수 있는 도구입니다. 한마디로, N드라이브와 Naver Word 서비스의 결합체라고 볼 수 있습니다.

 

  이런 Google Docs가, 이제 곧 아이패드와 안드로이드 패드, 안드로이드 폰을 위한 발사를 준비하고 있다고 합니다. N드라이브와 아직 출시되지도 않은 Naver Word의 강력한 라이벌이 등장한 셈이지요.

 

  Google의 서비스를 굳이 여기에 올려둔 이유는, 안드로이드를 만든 회사인 만큼 안드로이드에서의 최적화와 안정화능력, 가벼운 수준 등 여러 면에서 경쟁사들을 너무 쉽게 압도할 수 있기 때문입니다. 정말 강력하다 못해 저질스러울 정도로 대단한 이 서비스는 안드로이드 세상에 있어서는 거의 언터쳐블한 신의 세계에 있다고 봐야 하지요.

 

  구글 문서도구와 네이버 N드라이브의 현재 기능을 비교해 보겠습니다.

 

 

  Google docs

Naver Ndrive 

 이메일에 파일 첨부

 지원

지원 

 타인과의 파일 공유

 지원

 미지원

 블로그 및 SNS에 파일 보내기

 미지원

 지원

 한국어 지원

 지원

 지원

 문서 다중 공동 작업

 지원

 미지원

 업로드 파일 확장자

 제한(유료 사용시 무제한)

 제한

 업로드 용량 제한

 문서 500KB, 프레젠테이션 10MB, 스프레드 시트 1MB

파일당 200MB 

 제공 용량

 지메일 잔여 용량과 연동

 10GB

 다운로드 속도

 느림

 매우 빠름

 

  이거, N드라이브도 Google Docs에 전혀 밀리지 않네요. 팽팽합니다. 문서의 공유 및 동시 작업이라는 부분에서 Naver Word와 N드라이브를 함께 붙여놓는다 하더라도 Google Docs를 압도할 수 없지만, 다운로드 속도와 한국어 지원 수준에서 N드라이브가 어쩔 수 없이 유리합니다. 한국인에겐 한국어로 서비스 해 주어야지요.

 

  다만, N드라이브는 네이버의 작품인 만큼, 한국인에게 가장 적합한 인터페이스에 대해 구글보다 더 잘 알고 있습니다. N드라이브가 현재 부족한 점을 잘 메꾼 후, 한국인에게 맞는 특성을 고려해 발전해 나간다면 토박이나 마찬가지인 구글을 굴러들어온 네이버가 빼버리는 상황이 충분히 올 수 있다는 것입니다.

 


 


 

  N드라이브 어플리케이션에서, 폴더의 생성 및 파일의 이동/변경이 되지 않는 다는 점이 첫번째 아쉬움이요,

 

  업로드 위치를 정할 수 없다는게 두번째 아쉬움이었으며,

 

  폰 내장 뷰어가 없으면 파일을 볼 수 없다는게 세번째 아쉬움이었으며,

 

  동영상을 서버에서 인코딩해주지 않음이 네번째 아쉬움이고,

 

  파일을 공유할 수 없음이 마지막 아쉬움이었습니다.

 

  안드로이드 웹하드중 Google Docs가 상륙하지 않은 현재, N드라이브를 따라갈 강자는 없습니다. 위의 네가지 단점만 커버한다 하더라도 N드라이브는 이미 역대 최고의 물건입니다. 동시에, Naver Word도 출시후 안드로이드에 얹혀지며 N드라이브와 조화를 이룬다면, 네이버는 그냥 안드로이드랑 맞먹을 스마트폰 운영체제를 내놓아도 문제 없을 정도로 유비쿼터스 모바일 오피스에 걸맞는, 유비쿼터스 모바일 라이프에 적합한 '네이버 생태계'를 만들 수 있습니다.

 

  포토앨범과의 연동 등 타 웹하드 서비스와 완전히 차별화된 모습은 PC웹시장 1위의 저력을 보여주며, 그에 뒤떨어지지 않는 높은 수준의 서비스 퀄리티도 네이버에 대해 다시 한번 깊게 생각해볼만한 느낌입니다.

 

  여러모로, 첫번째와 두번째 아쉬움은 속히 변경되기를 기원합니다.


 

 

  2부 8편으로 구성된 네이버 안드로이드 어플리케이션 시리즈의 리뷰가 이 리뷰로 마무리지어 집니다. 네이버의 미투데이 서비스를 제가 써본 적이 없고, 친구도 없어서 포기하기로 했습니다. 딱 한명, 지인중에 미투데이를 쓰는 사람이 있으나, 네이버 미투데이 스태프들이 모두 알만한 사람이라고, 괜히 유명인 아이디 팔아먹는다는 오해를 받을 수 있으니 조용히 접는게 좋다고 당사자가 말해주더라구요. 뭐, 그래도 그냥 팔아먹고 한편 더 쓸까 고민중이긴 하지만, 시간 여유상 미투데이까지 작성하기엔 상당히 힘드네요.

 

  솔직한 심정으로, 처음 네이버 포털 어플리케이션을 리뷰할 때 정말 그냥 막막하기 그지 없었습니다. 전부다 웹브라우저로 연결되어 버리니 웹 서비스를 리뷰하느냐, 포털 어플리케이션 자체를 리뷰하느냐를 두고 참 고민을 많이 했고, 그냥 "불만 다 내뱉으면서 웹 서비스도 리뷰하자 크핳핳핳핳핳핳"이라고 결정내리고 제 2 리뷰를 휘갈기기 시작했습니다. 그리고 가장 시간이 많이 걸린 네이버 N드라이브를 제외한, 네이버 포털 어플리케이션, 네이버 지도, 네이버 블로그의 리뷰가 거의 준비되고 형태가 잡혔을 즈음, 느티나무님의 리뷰를 보고 좌절했습니다. 느티나무님 너무 잘쓰셨어요......

 

  그렇다 해도, 준비한 게 억울해서, 일단 더 검수하고 온갖 용을 다 써서 최대한 열심히 써보기로 했습니다. 원래 제가 글을 쓰는걸 좋아한 터라, 팀블로그와 블로그를 통해서 글을 자주 쓰곤 했습니다만, 제 작업용 컴퓨터와 노트북이 모두 망가지면서 글을 꽤 오랜 시간 못쓰고 있던 터였습니다. 그리고 이번 리뷰에 "갤럭시탭 갖고싶어!!!" 라며 달려들어서 한달여의 시간을 쏟아부어 리뷰를 써내려가며, 글 쓰는 재미를 다시 느꼈습니다.

 

  문제는 저는 글쟁이가 아니라 컴퓨터공학도라는 것이지요. 어찌 보면 상당히 개발자스러운 단어들이나 어투들이 리뷰 구석구석에 또아리를 틀고 있겠습니다만, 최대한 End-User의 입장에서 리뷰를 하기 위해 상당히 조심스럽게 작성했습니다. 코드 쳐내려가듯 글이 써지지 않도록 주의를 기울이면서요.

 

  억지로 살려놓은 제 작업용 노트북이 마지막 제 발악에 맞추어 남은 힘을 모두 짜 내어 준 것 같습니다. 리뷰가 완성이 다 되어 가니 노트북도 거의 맛이 갔네요. 마지막 글을 남기는 이 순간에도 상당히 버벅입니다.

 

  그리고, 리뷰마다 출현해 리뷰 쓰다 뛰어나가서 상황을 진화하게 해준 저희집 진돗개, "똥개"에게 감사를 표합니다. 이건 뭔 진돗개가 의젓하고 충성심 높은 모습따위는 자기 밥그릇에 던져버리고 주인도 물고 자기 꼬리도 물고 지나가던 고양이도 물고 난리도 아니네요.

 

  이 리뷰를 끝까지 다 보신분이 몇 분 되실지는 모르겠습니다만, 긴 글 모두 읽어주시느라 수고하셨습니다. 이만, 이 길디긴 리뷰를 마칩니다. 

 

 

 

p.s. 네이버 포털 어플리케이션때 쓴 이메일의 답장은 아직도 기다리고 있답니다.


 


 
 

posted by Lonewolf dlbo

댓글을 달아 주세요

  1. 아놔 네이버블로그에서 사진이 바로 연동이 안되서 처음부터 하나하나 다시 다 첨부해 넣었어;;;

  2. 고생했다

2010.09.27 13:15 (비정기) Dlbo's Post

 


 
 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 



 
 
 

  갑자기 비가 오더니 날씨가 좀 서늘해 집니다. 이제 날씨가 좀 풀리려나 봅니다. 아직 태풍이 올라올 게 좀 남아있다고 하는데, 이거 태풍 맞으면서 춥기까지 한건 아니려나 걱정이 되네요. 태풍 곤파스가 올때 옆 빌라 외벽이 무너져도 잘 버텨낸 저희집 개의 개집이 부럽습니다. 그때 저희집 지붕은 뜯겨져 나갈뻔 했거든요. 집이 너무 낡아서...

 

  전 현재 철도에서 근무중인 공익근무 요원이지만, 개발자를 꿈꾸는 한 대학생이기도 합니다. 일전에는 네이버 블로그를 애용했으나 딱 한가지 기능때문에 티스토리로 옮겨갈 수 밖에 없었습니다. 바로, 구글의 Code Syntax highlighter 기능입니다. C언어 뿐만 아니라 여러가지 프로그램의 코드를 네이버 블로그에서는 깔끔하게 게시하기가 힘들었습니다. 그리고 드래그 방지를 걸더라도 이 기능을 이용하면 코드만큼은 클립보드에 복사가 가능했습니다만, 네이버 블로그에선 이 기능이 지원되지 않아 상당히 불편했습니다. 이 기능 하나 때문에 티스토리로 옮겨가기는 했지만, 개발에 관련된 내용으로 코드를 첨부하는게 아니라면 아직도 네이버 블로그가 더 끌립니다. 요즈음은 여자친구가 네이버 블로그를 쓰기 때문에 어쩔 수 없이 네이버 블로그를 통해 쓰는 편이지만, 스크랩 등의 여러가지 복잡하고 사용자 편의적인 기능이 많아 기회만 된다면 다시 네이버 블로그로 넘어오고 싶습니다.

 


 


 

  PC 웹시장에서 언제인지 모르게 홈페이지들이 급격하게 사라지고, 블로그라는 알 수 없는 묘한 물건이 떠오르기 시작했습니다. 기존 홈페이지란 것이 웹서버를 호스팅받고 유지비를 꾸준히 내면서 HTML과 자바스크립트, 플래시 등의 손 가는 작업들이 꽤 많았는데, 아마 이런 이유 때문에 수많은 홈페이지 서비스들이 사라진게 아닐까 싶습니다. 웹호스팅에 대한 부담감을 줄게 하기 위해 각종 포털들이 개인 홈페이지를 위한 공간을 제공하였으나, 보안 등 여러가지 문제로 인해 제약된 크기의 공간이나 포털에서 제공하는 템플릿 틀 안에서만 홈페이지를 만들 수 있게 되었지요. 그 와중에 손이 최대한 적게 가고, 제작 과정을 간소화 시켜 굳이 웹 프로그래밍에 대한 지식이 없어도 만들 수 있는 간단형 홈페이지들이 제공되기 시작했고, 크게 성황되는것 처럼 보였었지요.

 

  끝내는 정해진 템플릿 안에서 원하는 형식으로 마음껏 꾸밀 수도 있고, 서로 홈페이지의 내용을 쉽게 퍼가고 퍼줄 수 있는 새로운 서비스가 홈페이지 시장을 수면 아래로 꾸욱~ 눌러버립니다. 바로 싸이월드입니다.

 


 
 

  아주 간단한 서비스를 통해서 많은 부분을 신경쓰지 않고 사용할 수 있는 미니홈피와, 타 홈페이지를 쓰나 자신과 친밀한 사람들을 쉽게 관리할 수 있는 일촌 서비스. 어찌하면 요즘 언급이 많이 되고있는 UX의 할아버지라고 볼 수도 있겠습니다.

 

  하지만, 정해진 템플릿 안에서밖에 자유도가 보장되지 않아, 자유도의 수준이 지나치게 떨어진 싸이월드 외에, 사람들의 욕구를 더 채워줄 무언가가 필요했습니다. 기존의 홈페이지처럼 너무 어려우면 안되고, 동시에 친밀한 타 유저들을 쉽게 리스트화 시켜 관리하며, 자신의 글에 대한 저작권을 강화하고, 타인들과의 정보를 쉽게 공유하고 가져갈 수 있는 공간. 그게 바로 블로그였습니다. RSS feed와 트랙백 등의 새로운 기능으로 무장한 블로그라는 새로운 개념은 여태까지 나온 모든 것들의 장점을 골고루 취해 PC 웹시장을 선도해 나갑니다. 그동안 정말 많은 업체들이 블로그 서비스를 제공해 왔습니다.

 


 
 


 
 
 
 
 

  이 외에 드림위즈, 파란, 구글 등 정말 수많은 업체들이 블로그 서비스에 참여하여, 아직도 블로그 서비스는 대 성행입니다.싸이월드는 자신만의 강점을 살려 아직 남아있고, 블로그는 아예 전 세계적으로 대 성행하는 엄청난 서비스가 되어버렸지요.

 

  블로그 서비스가 대 성장함에 따라 블로그를 위한 많은 서비스들이 생겨났습니다. 인터넷에 접속이 되지 않은 상태에서 미리 글을 작성하고, 연결되자마자 바로 블로그로 글을 송고해주는 서비스부터 모바일 기기에서 블로깅을 지원하는 서비스까지. 그리고 그 위에 지금 안드로이드와 네이버가 있습니다.

 

  현재 마켓에서 블로그로 검색해 보신다면 알겠지만, 웹브라우저나 웹페이지에 의존하지 않고 블로깅 서비스를 제공하는 어플리케이션은 네이버 외에는 없습니다. 심지어 모바일 페이지에서는 글을 게제조차 할 수 없는 블로그 서비스도 있지요. 티스토리를 개인 개발자가 어플리케이션화 시켜 제공하고는 있으나, 제대로된 서비스를 제공하지 못하고 있습니다. 그냥 모바일 웹페이지를 끌어온 수준이더라구요.

 


 

 

  이런 상황에서 네이버의 블로그 서비스에 대해 제 입장은 매우 긍정적이며, 개발자의 코드를 게제할 방법만 생긴다면 저는 언제든 다시 네이버 블로그로 돌아올 겁니다. 네이버의 N드라이브와 포토앨범과 함께 연동하게 되면 모바일에서 블로그에 글을 쓸 때 가장 강력한 강자는 네이버 블로그라고 생각합니다.


 


 


 

 


 
 

 
 

  설치 용량은 1.37MB, 이번 개발자 이메일 주소는 blog_app@naver.com 이네요. 아. 저번에 네이버 포털 어플리케이션 리뷰때의 문의 메일에 대한 답은 아직도 오지 않았답니다. 이 리뷰를 완전히 마치고 나면 오려나요.

 

 

  아무래도 비교 대상이 없다 보니 뭐 어떻고 저렇고 할 말이 상당히 없습니다. 그 뿐만 아니라, 네이버 블로그 어플리케이션을 직접 사용해 본 결과, 그냥 말이 필요 없이 군더더기 없는 걸작이었기에, 리뷰를 쓰고는 있지만 이 리뷰에서 딱히 무어라고 강조하거나 풀어헤치기 힘드네요.

 

  아직 경쟁 대상이 없음에도 불구하고, 업데이트는 꾸준히 되고 있습니다.

 

  꾸준한 버그픽스가 보입니다. 2.2 프로요가 아직 적용된 안드로이드폰이 얼마 없음에도 불구하고, 신속하게 이미 업데이트가 되어 있습니다. 3번째 부분의 '기타 오류 해결'이 무어였는지 기록해주었으면 좋았을 텐데요. 전 아직 사용해보면서 별다른 오류는 보지 못했습니다.


 


 

 

  처음 로딩 화면부터 상당히 심플한 네이버 블로그. 제가 아이폰 네이버 앱은 하나도 안써봐서(아이폰이 없으니 써 볼 수 있을리가 없지요) 아이폰의 네이버 앱과는 어떻게 다른지는 모르겠습니다만, 깔끔한 로딩화면은 상당히 마음에 듭니다.

 

  최초 실행이거나 자동 로그인을 걸어두지 않았다면 직후에 이 로그인 창이 뜹니다. 아무나 폰을 막 열어볼 것을 대비해서인지 자동로그인을 사용할지 말 지에 대해 설정이 가능합니다.

 

  아아. 메인화면인데, 역시 네이버 블로그의 데이터를 밀어버렸던 터라 아무것도 없네요. 가끔 여친님께서 보우하사 무언가 안부글을 남겨주면 그게 끝입니다. 이웃새글에는 New가 떠있네요. 그 외엔 뭐 없습니다.

 

  흐음... 문득 느끼는건데, 여친님께서 점점 살이 쪄 가는 이유가 저게 문제가 아닌가 싶네요. 뭐... 요즘 들어서 제목부터 먹는거 삘 나는걸 스크랩해둡니다. 그 외에는 커리어우먼 다운 글도 하나 있네요. 댓글 7개 달린 것.

 

  덧글이 가장 많은 글을 골라봤습니다. 글의 카테고리가 "읽기 골치아픔"으로 나와있네요. 여친님의 블로그로 이동하는 버튼도 있고, 이전글, 다음글 버튼도 꺽쇠로 위아래로 잡혀있습니다. 덧글보기, 공감보기, 보내기에, 별표로 표시된 '책갈피'기능도 있습니다. 저 책갈피를 체크하면, 메인화면의 상단에 있는 별 모양 버튼에서 책갈피를 꽂은 리스트를 볼 수 있습니다. 모바일 환경에 맞게 잘 재구성한것 같습니다.

 

  덧글 보기에 들어가면 덧글 쓰기 버튼도 있습니다. 선택해보면 이렇게 덧글을 바로 쓸 수 있는 창이 나옵니다. 비밀글 체크도 가능하고, 네이버 블로그 고유의 댓글 달 때 선택 가능한 퍼스나콘까지 고를 수 있습니다.

 

  글 보기에서 글 보내기 부분입니다. 메일로 보내기와 미투데이로 보내기가 있는데, 메일로 글을 보낼 수 있다는게 마음에 듭니다. 아쉬운 점이 하나 있는데요, 메일로 보낼 수 있었다면 폰에 파일로 저장할 수 있으면 좋지 않을까 싶습니다. 혹은 문서형으로 변환시켜서 다운로드 시켜주는것도 나쁘지 않았을텐데 말이지요.

 

  책갈피 리스트는 SD카드에 저장되지 않나봅니다. 제 모토로이를 한번 공초 돌렸는데, 이전 책갈피가 사라졌습니다. SD카드로 저장해서 만일의 일이 있어도 사라지지 않게 해 주면 좋을 것 같습니다.

 

  남긴글 소식의 덧글 부분입니다. 덧글을 남긴 글의 덧글에 대한 새소식을 알려줍니다. 안부글에서는 자신에게 남겨진 안부글, 남에게 남긴 안부글의 덧글에 대해 알림을 전해주며, 공감한 글은 자신이 공감한 글에 대해 알림을 전달해줍니다.

 

  안부글 소식은 이렇게 나옵니다. 네이버 블로그를 폐쇄한 후는 저 한명만의 댓글 외에는 아무런 소식이 없네요...

 

   이웃블로그의 리스트입니다. 일방적인 이웃이나, 서로 이웃등 여러가지에 대해 좌측의 하트모양 아이콘을 통해 알려줍니다. 네이버 블로그 서비스의 경우 커뮤니케이션 캐스트만으로는 모든걸 전달해주기 힘들다는 면에서, 네이버 블로그의 모든 방식이 상당히 마음에 드는 상태입니다. 이렇게 이웃 리스트를 나열하는것도 꽤나 괜찮아 보입니다. 가독성도 좋고, 지금 이 블로그들은 '관심 블로그' 그룹이나, 원하는대로 그룹을 설정해 저장도 가능합니다.


  메인에서 메뉴버튼을 누르면 아래와 같이 스트립메뉴가 뜹니다. 홈, 내블로그, 이웃블로그, 포스트쓰기, 설정이 있는데, 포스트쓰기는 말 그대로 글을 쓸 수 있고, 내 블로그 버튼은 내 블로그로, 홈버튼은 홈으로 이동합니다..... 너무 당연한걸 설명하고 있는것 같아 민망합니다. 인터페이스도 단순해서 헤멜 일은 없습니다.

 

  내 블로그의 모습입니다. 안부글에서는 저에게 남겨진 안부글을 볼 수 있습니다. 심플하니 보기 좋군요.

 

  카테고리를 이렇게 골라서, 카테고리에 맞는 글만 볼 수도 있습니다. 덕분에 화면이 훨씬 깔끔한 느낌입니다. 어짜피 이웃의 블로그에 가면 최신글을 보지, 카테고리를 골라서 보지는 않으니 이렇게 한 구석으로 빼둔게 현명하다고 생각합니다.

 

  후후.... 예전에 티스토리로 옮기기 전에는 안부글에 참 많은 사람들이 글을 남겨줬었는데 이제는 여친님만 방명록을 달아주시네요. 방명록의 리스트도 상당히 간편해서 좋습니다.

 

  허락 받고 캡쳐한 여친님 블로그의 모습. 포스트가 정말 징그럽게 많네요. 1773개라니. 하긴, 10년 전부터 꾸준히 글을 써 왔으니 충분히 이정도가 될 만합니다. 여친님 또한 네이버 블로그 어플리케이션을 통해 자주 포스팅을 하는 편입니다.


 

  네이버 블로그를 워낙 오래 쓰니 이렇게 안부글이 많네요. 제가 심심해서 꼬장부린 안부글도 보입니다. 이건 모자이크 패스~

 

 상단의 안부글쓰기 버튼을 누르면 안부글을 남길 수 있습니다.

 

  아, 한가지 잊을뻔 했군요. 상단에 빨간색으로 강조한 부분을 누르면, 해당 블로거의 프로필을 볼 수 있습니다.

 

  성별도 비공개인 미스테리 아가씨. 이웃이 정말 엄청나게 많네요. 포스트 스크랩이나 토탈 전부 어마어마 합니다.

 

  네이버 블로그 어플에 대해 정말 쓸 만한게 없었습니다. 일단 안드로이드 상에서는 경쟁 서비스도 없어서 비교할 대상도 존재하지 않았고, N드라이브나 네이버지도, 네이버 어플과는 달리 상당히 완성도가 높다는 느낌이 들었습니다. 다만, 어느 블로그를 가도 화면이 다 똑같으니 약간 지루한 면이 없진 않았다는것? 이게 유일한 결점이네요.


 


 

  안드로이드의 네이버 블로그 어플리케이션은 상당히 완성도가 높습니다. 별다른 결점도 보이지 않구요. 다만 약간의 바램만 있습니다.

 

  • 책갈피를 저장할때, 폰의 내장 메모리가 아닌 SD카드에 저장하면 좋겠습니다. 웹에 저장되는줄 알았는데 공장초기화 하니 없어져 있더군요. 웹에 올리지 않는다면 SD카드에라도 저장해서 폰이 망가져도 쉽게 복구할 수 있으면 좋겠습니다.
  • 보내기에서, 글을 문서화 시켜서 폰에 저장이 가능하면 좋겠습니다. 좋은 글은 두고두고 보는 것, 문서파일화 시켜서 인터넷을 쓰지 못하는 상황에서도 볼 수 있으면 더 좋지 않을까요?
  • 모바일 페이지에서 보일 수 있는 화면도 개인별로 꾸밀 수 있으면 좋겠습니다. 이렇게 단일화된 모양도 나쁘진 않지만, 개인별로 자신의 개성을 살린 디자인을 가지게 된다면 눈이 좀 더 즐거우리라 생각합니다.

 

  네이버 블로그 어플리케이션의 완성도가 높아서, 단점을 보완한다기 보단 새로운 기능을 덧대었으면 하는 방향이네요.


 


 

  정말로, 네이버 블로그에서 프로그램 코드의 강조에 관한 google code syntaxhighlighter와 비슷한 서비스가 제공이 된다면 바로 네이버로 돌아와야 겠습니다. '디지털 노마드'라는 ISDN이 동네에 쫙~ 깔릴 당시의 단어처럼, 디지털 유목민이 되어 보고 싶었거든요. 그런데 맨날 쓰던 글이 코드가 들어있으니 보는 사람도 불편하고 쓰는 저도 불편해서....

 

  어느덧 4편의 네이버 어플리케이션 리뷰중 3번째 리뷰까지 왔네요. 워낙에 쓸 게 없어서 고민했던 리뷰이면서, 네이버 블로그로 다시 돌아가고 싶게 만든 리뷰였습니다. 어느덧 밤은 저물어가고, 저희집 썩을 개는 진돗개의 위엄을 살리겠다는건지 버리겠다는건지 마당에 있는 지렁이를 보고 징그럽게 짖어대고 있습니다. 리뷰를 마치고, 개 좀 조용히 시키러 가겠습니다.


 

posted by Lonewolf dlbo

댓글을 달아 주세요

2010.09.27 12:57 (비정기) Dlbo's Post

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 


 
 


 

 

 

 

  어찌하다 보니, 저번 네이버 포털 어플리케이션 리뷰에서는 정말 신나게 네이버 포털 어플리케이션을 까버린 글이 된 것 같습니다. 나름 수위 조절을 최대한 한다고 했는데, 그래도 주변 사람들의 읽고 난 평이 "형.. 너무했다... 이거 너무 공격적으로 깐 거 아니야? 글 배치를 바꾸던가 좀 해라." 라는 의견이 상당히 지배적이더라구요. 뭐.... 너무 공격적으로 까서 기분 나빠서 갤럭시탭 안줄꺼라는 의견도 다들 덧붙여 줬습니다. 아무래도 뭐, 갤럭시탭이 정말 미친듯이 갖고는 싶지만, 제 글이 지나치게 공격적이었다면 별 수 없지요. 진짜로 그런가......

 

  그것보다는, 놀라운 사실을 발견했습니다. I/O계열 장치가 아작나서 내장 그래픽 칩도 같이 나갔을줄 알았던 제 노트북이, 그래픽 칩은 아직 살아있긴 하더군요. 작업용으로 꿍쳐놨던 다른 모니터에 연결하자 화면이 보입니다. 그나마 정말 다행이라는 생각이 들더라구요. 노트북 고장으로 활동하지 못했던 팀블로그나 카페 활동을 다시 재개할 수 있을것 같습니다. 고장난 노트북을 대신해 정말 엉성하기 그지없게 프로젝터용 보드를 가지고 만들었던 데스크탑은 이제 안녕입니다.

 

  이번 리뷰를 준비하기 위해, 여자친구와 저희 집에서 직접 남산까지 네이버지도에 의존해 이동해 보았습니다. 그 과정에서 네이버지도의 확실한 강점을 보았고, 신은 모두를 공평하게 대한다는 말이 정말로 맞는지, 네이버지도의 확실한 결점도 같이 발견했습니다. 네이버가 아직 안드로이드에서 후발주자임을 고려해본다면, 그리고 네이버 지도가 상당한 속도로 꾸준히 업데이트 되고 있다는 점을 고려해본다면 충분히 극복할 수 있는 수준이라 봅니다.


 

 

 

  기존의 핸드폰은 단순히 전화와 문자를 주고받는 수준에 머물러 있었습니다. 그리고 PDA라는 또 다른 Handset이 자리잡고 있었지요. 이 둘이 서서히 결합되기 시작하면서, 스마트폰이라는 새로운 분야가 열리기 시작했습니다. PDA에 전화기능을 가미시킨 PDA폰은 그 성능은 스마트폰보다 막강했으나, 결국 그 무식한 두께와 배터리 성능으로 인해 스마트폰의 시장에 편입되어 버립니다. 여기서 스마트폰 유저들은, 더 나아가 단지 스마트폰을 '폰'이 '스마트'한 수준이 아닌, 생활에 밀접한 '스마트'한 '폰'이 되길 바라기 시작합니다. 기존 핸드폰 시장에서 mp3 플레이어가 지원되어 있던 상황이다 보니 스마트폰은 그보다 훨씬 엄청난 영역을 '폰'의 세상으로 불러옵니다. OS를 폰에 불러오고, OS를 기반으로 전화와 문자메시지 뿐만 아니라 날씨, 지도, 일정, 웹서핑, 사진찍기를 넘어서서 이제는 블로깅과 트위터, 페이스북 마저도 모두 스마트폰의 영역 안에 들어와 버렸습니다. 존재하지 않는다 하여 이 기능들을 쓰지 못하는것은 아니지만, 움직이면서 손 안에 모든 세상을 넣을 수 있게 되어버린 것이지요.

 

  여기서 이 수많은 것들이 손에 들어왔지만, 그냥 손에 잡고 껄떡껄떡 거린다고 모든 세상을 다 손에 쥔 것은 아닙니다. 블로깅을 하기 위해, 트윗을 날리기 위해, 맛집을 찾아내기 위해 결국은 현장을 찾아가보아야 합니다. 무슨 환타지 소설의 텔레포트 마법을 익히거나, 공상 SF의 공간이동 기술을 익히지 않는 한, 우리가 직접 해당 장소들을 방문해야 하는 것이지요. 스마트폰이 세상을 뒤흔들기 전에는 물어보고, 약도를 그리고, PC에서 지도를 뽑아가고, 네비게이션을 들고 다니며 찾아다녔지만 이제 유저들은 그 기능을 스마트폰에 모두 전가시키고 있습니다.

 

  물론, 이 기능들을 서로 완벽하게 한 뭉텅이로 묶어놓는 서비스들은 모바일 세상에 풀리고 있습니다. 아래의 멋진 친구들이지요.

 

오브제. 안드로이드 마켓을 통해 제공되는 안드로이드의 증강현실입니다.


 

 Layar. 안드로이드와 아이폰 양쪽 모두에서 유명한 증강현실 어플리케이션이지요.


 
 

 

 스캔서치. 안드로이드에서는 옵티머스 계열에만 공급되는 증강현실 입니다.


  바로 증강현실 친구들입니다. 타 유저들과 여러 정보를 공유하며, 원하는 위치에 대한 포스팅을 하고, 유저들간의 위치가 파악됨을 이용해 서로 직접 만나서 대화를 할 수도 있습니다. 지도와 GPS를 활용해 원하는 위치를 표기하고, 다른 사람들은 그 위치를 보고, 자신의 위치에서 어떻게 갈 지 방법을 찾아낼 수 있습니다. 카메라로 현실을 비추면, 증강현실이라는 이름 하에 숨겨진 모습들이, 위치들이 드러나게 되는 것이지요.

 

  하지만. 증강현실에는 아주 치명적인 단점이 있습니다.

 

 

  1. 대부분 카메라를 쓰기 때문에 상당히 무거우며, 발열이 심하고, 둔하다.
  2. 웹과의 연동에서 사용되는 데이터의 단위가 큰 편으로, 데이터 통신계에 상당한 부담이 간다.
  3. 배터리를 무지하게 잡아먹는다.

 

 

  이러한 단점들은, 현재의 안드로이드 스마트폰들이 버텨내기엔 너무나도 버거운 짐입니다. 세상을 스마트폰 하나에 담기에는 너무나 무겁고, 힘이 듭니다. 물론 갤럭시S등의 괴물폰에서는 훨씬 나은 모습을 보여줄수는 있겠습니다만, 전 제 모토로이가 너무 버거워해서 증강현실은 사용하지 않습니다. 너무 버거워 툭하면 픽픽 모토로이의 전원이 꺼져버리니, 미안해서 못돌리겠습니다.

 

  이런 단점때문에, 아직 지도 서비스는 꽤나 유용한 서비스입니다. 지도의 원하는 부분을 약도화 시켜 저장하고 이를 공유하거나, 지도에서 원하는 위치의 GPS 좌표를 공유할 수도 있고, 덜 무거운 웹브라우저를 이용해 블로거들이 추천하는 지역을 지도로 찾아 가 볼 수도 있습니다. 지도가 발전하면서 버스, 자동차, 대중교통의 정보를 제공해줄 수 있게 되면서 지도는 상당히 메리트있는 서비스가 되어가고 있습니다. 무엇보다도,

 

 매우 가볍습니다.

굳이 용을 써서 증강현실에 매달리지 않아도, 증강현실 못지 않은 좋은 효과를 볼 수 있다는 겁니다. 맛집을 찾고 싶다면 네이버 포털 어플리케이션의 윙버스 서울맛집과 네이버 지도 어플리케이션의 조합으로 자신의 스마트폰에 무리를 주지 않으면서 충분히 찾아 갈 수 있다는 겁니다.

 

  현재까지 안드로이드에서 최강의 지도 강자는 구글이었습니다. 구글은 스트리트뷰와 latitude, buzz 등의 서비스를 한국에서는 제공하지 않음에도 불구하고 한국내 안드로이드폰에서 지도 하면 구글지도를 떠올리는 상황까지 오게 되었지요. 물론 이런 현상은 구글 지도가 시스템에 들러붙어있기 때문임은 부정할 수 없는 사실이긴 합니다만, 구글이 한국 내 지도서비스에 대해 깊게 관심을 가지지 않는다면, 한국에 특화된 네이버와 다음에게 그 자리를 내주어야 할 겁니다. 시스템 기본 부착 어플리케이션이 마켓에서 다운받는 어플리케이션에게 밀려서 외면받게 되는 것이지요.

 

 

 모바일 뿐만 아니라 어떤 면으로든 세계 최강자인 구글 맵스. 하지만 한국에서만큼은 녹록치 않을 겁니다.

 

  솔직히 구글 지도에서 검색해서 나오지 않는 부분은, 네이버 지도에서 찾아보면 나오는 경우도 종종 있습니다. 구글이 아직 한국에 대해 완벽하게 지도 데이터베이스를 얻어내지는 못했다는 의미이지요. 구글 지도도 여러가지 대단한 기능들이 많이 생기기는 했습니다만, 아직 국내 기업들의 데이터베이스를 따라잡지는 못한 것 같습니다. 뭐, 따라잡힌다 한들 한국인에게 특화된 UI를 제공하게 된다면 구글 지도가 그리 쉽게 국내 서비스들을 압도하지 못할 겁니다.



 

  이전의 네이버 포털 어플리케이션은 안드로이드 마켓에서 바로 다운로드가 가능했습니다. 다른 네이버의 어플리케이션들 또한 미투데이를 제외하면 '네이버' 키워드로 검색하여 다운로드 받을 수 있습니다.

 

 그냥 단순하게 안드로이드 마켓에서 네이버로 검색해도 역시 네이버 지도는 나옵니다. 빨간색으로 강조한 부분이 오늘의 리뷰 대상이 될 네이버 지도 어플리케이션입니다. 안드로이드 마켓 외에는 별다른 습득 루트가 없는 것 같아 매우 아쉽습니다. 하긴, 안드로이드 마켓을 통해야 업데이트가 가장 간편할테니 별 수 없는 부분이기도 하네요.

 

 


 
 

 버전과 용량, 스크린샷과 개발자 소개입니다. 이전 네이버 포털 어플리케이션의 개발자 이메일과 다르군요.

아참! 이전 네이버 포털 어플리케이션 개발자 이메일에 보낸 메일은 아직 답신이 없습니다. 쳇. 바빠도 좀 알려주시지. 그나마 이번에는 확실히 고객센터 이메일임을 알 수 있네요. cs_로 시작합니다. Customer Service의 약자입니다. 꾸준한 업데이트에도 불구하고 아직 1.1.3버전밖에 되지 않았네요. 용량은 2.17MB라고 나와 있으나, 설치하고 나면 무식하게 불어나더라구요.

 

  네이버 지도의 설치 직후 용량입니다. 아직은 별거 아니죠? 구글 지도가 업데이트 다 날리면 8메가를 가뿐히 넘는 다는 점에서 네이버 지도가 조금 바람직하긴 합니다만, 검색결과가 늘어나면 늘어날수록 구글 지도보다 압도적으로 데이터 용량이 늘어나더군요.

 

그것보다도, 버전 102가 묘하게 거슬리네요. 마켓에서 다운로드 받을 때 설명에서 알려준 버전정보와는 다릅니다. 버전 정보 빼놓고 업데이트했나?

 
  무난한 네이버 지도. 다음의 로드뷰나 구글지도의 스트리트뷰 같은 서비스를 우겨넣어 두지 않은 덕에 용량은 훨씬 가볍습니다만, 여태까지의 구글 지도의 용량을 보았을 때, 구글 지도에서 필요없는 기능을 빼더라도 네이버 지도의 용량이 훨씬 작을거라는 예상이 듭니다. 왜냐구요? 구글 지도는 해외의 정보까지 모두 싸그리 긁어모아놓았기 때문입니다. 반면, 네이버 지도는 한국 특화이니, 외국의 정보가 그리 많지 않아 용량이 훨씬 작을겁니다.
 
 


 

  네이버 지도를 처음 열어 보는 순간 상당히 놀라웠습니다. 구글 지도보다 훨씬 빨리 로딩되었기 때문입니다. 처음 리뷰를 썼을 땐, 단순히 네이버가 최적화를 잘 했기 때문일거라 생각했습니다만, 여러가지를 고루 확인해 본 결과 네이버 지도의 제공 범위 덕분임을 알았습니다. 동북아시아 지역만 제공하며, 남한 외의 지역에서는 일정 수준 이상 확대하면 확대 불가라는 이미지가 떠버립니다.

 


 중국의 어느 지역을 확대한 모습입니다. 어디인지는 저도 모릅니다....?

2.4Km 축척단위로 확대하자마자 뜨는 이미지. 정말 순수 국내용입니다.

 
  뭐, 예상 못한 것은 아니지만 이렇게 되면 국내 서비스만 볼 경우 네이버 지도가 구글 지도에 국내에서만큼은 압승하리란건 거의 확실시해 집니다. 제공해야 할 범위가 엄청나게 줄어드니까요. 대신 World on Hand 라는 부제를 Korea on Hand로 바꿔야 겠습니다.
 
  그보다는, 아무래도 네이버 지도가 얼마나 알찬 서비스를 제공하고 있는지가 관건입니다. 단순히 빠르다고 해서 우위를 보여주는 시대는 지났습니다. 스마트폰은 "빠르게"도 중요하지만, "정확하게"와 "다양하게"도 절대 무시할 수 있는 수준은 아니기 때문이지요. 국내에서 만큼은 구글이 네이버의 강력한 정보력을 따라잡기 힘들겁니다. 여태까지 테스트를 통해 직접 확인한 네이버 지도의 기능들은 아래와 같습니다.
 
  • 돋보기아이콘을 이용한 줌인 & 줌아웃 기능
  • 멀티터치를 이용한 줌인 & 줌아웃(업데이트후 지원)
  • 현재 내 위치를 지도상에 표기
  • 현재 내 폰의 머리가 가르키고 있는 방향 표기(찾기 어려웠으나, 있었습니다.)
  • 내 위치 기반 주변 정보 제공 서비스
  • 위성사진지도/일반지도/혼합지도 기능
  • 교통정보/자전거도로/일반지도 기능
  • 지도 저장 후 오프라인 제공 기능
  • 대중교통을 통한 목적지 경로 찾기 기능
  • 자동차를 통한 목적지 경로 찾기 기능
  • 출발지와 목적지 간 경유지 설정후 경로찾기 기능(1개 경유지만 가능)
  • 검색결과(위치, 경로) 자동 저장 및 삭제, 불러오기 기능
  • 축척자 기능
  • 대중교통 검색 기능

 

  꽤나 많은 기능을 제공합니다. 구글 지도가 한국에서 서비스하는 기능은 일단 거의 다 된다고 보면 됩니다. 설명서보다는 리뷰가 목적이기에, 간단하게 스크린샷을 하나하나 첨부해 두고 간단한 설명만 곁들이겠습니다.

 

  네이버 지도의 메인 페이지입니다. 상단에 빨간색으로 강조한 부분이 보이시나요? 저 부분이 바로 돋보기를 통한 확대/축소 버튼입니다. 두배 단위로 확대/축소가 됩니다.

 

  하단부에 강조한 부분은 축척자 기능입니다. 원하는 두 지점간의 직선거리는 구할 수 없지만, 축척자를 통해 대략적인 거리는 가늠할 수 있습니다. 구글 지도에서도 실험실이라는 이름으로 정식 제공하지 않는 기능인데, 대단하지 않나요?

 

근데 이거 멀티터치를 이용한 줌인 & 줌아웃은 도저히 어떻게 스크린샷을 찍어야 할까요?


     상단부에 빨간색으로 강조한 부분 보이시나요? 저기를 클릭하면, 자신의 위치를 보여줍니다.

     

     

     

     

     

     

     

     

     이렇게 확대까지 되지는 않습니다. 보이기 쉽도록 확대를 제가 해 두긴 했습니다만, 아쉽네요.

    빨간 부분을 다시 클릭하면, 방향까지 표기됩니다. 이게 참 불만이었습니다. 못찾을뻔 했어요. 버튼을 나눠주던가, 아니면 아이콘을 더 알기 쉽게 바꿔야 할 겁니다.

     

     

     

     

     저기 부분적으로 강조한거 보이시죠? 남산투어중 저기까지 가서야 알았습니다. 배터리 소모와 센서 사용으로 인한 폰에 걸리는 과부하 등의 여러 요인들을 살펴볼 때 이 기능은 정말 강력하지만, 좀 알기 쉽게 고쳐줬으면 하는 바램입니다. 강력해도 못찾아서 못쓰면 슬픕니다. 그래도, 구글 지도와 대비하여 이렇게 두 단계로 나눠 쓸 수 있다는 부분에서 네이버의 세심한 배려가 느껴집니다.

     

     주변 지역 정보 서비스입니다. 이 기능은 자신의 위치가 확인 되어야만 사용이 가능합니다. 자신의 위치를 기반으로 주변에 어느 정도 거리에 무엇이 있는지를 알려주기 때문입니다. 사용자가 지정한 위치를 기준으로 알려주는 방법도 가능했다면 하는 아쉬움이 남습니다.

     

      보기옵션 파트입니다. 여기서 일반지도/겹쳐보기/위성사진을 선택할 수 있고, 지도만 보기/교통정보보기/자전거 지도 보기를 선택할 수 있습니다. 선택에 따라 원하는 지도를 볼 수 있습니다. 위성지도/교통정보로 설정해 보겠습니다.


      꽤나 복잡하네요. 이렇게 원하는 지도를 필요할때마다 설정해서 볼 수 있습니다. 생각보다 엄청난 메리트로 작용합니다. 일단, 추석 귀경길에 써먹을 수 있거든요. 네비게이션 슬슬 치워도 되겠습니다.

     

      원하는 범위만큼의 지도를 저장해 둘 수 있습니다. 저장후 저장 목록에서 저장했던 지도를 볼 수 있지요.

     


      지도의 경우는 SD카드에 저장되는걸로 추정됩니다. 제가 이전 리뷰 이후 공장초기화를 날렸는데도 살아있다는건, SD카드에 저장된다는 의미겠지요? 상당한 메리트입니다.

     


      빠른길 찾기 기능입니다. 출발과 도착 옆에 책 모양이 있는데, 이는 이전의 검색 결과중에서 선택하겠다는 의미이고, 더 옆의 요상한 모양은 지도에서 직접 선택하겠다는 겁니다. 여기서 문제점이, 정확한 위치를 골라주어도 "어느동 근처"로 선택된다는 점입니다. 쓰나 마나한 느낌이네요. 좌측의 + 모양 버튼은 중간경유지 입니다. 중간경유지를 추가하지 않으면 자동차 길찾기와 대중교통 길찾기가 모두 가능합니다만, 경유지를 추가하면 대중교통 길찾기가 불가능합니다. 조만간 지원되지 않을까 싶네요. 꽤나 중요한 기능이니...

      부천시 원미구 원미두산아파트에서 부천역을 경우해 N서울타워(남산타워)에 가는 길을 보려 했으나, 위 스크린샷처럼 대중교통길찾기가 비활성화 되어 있습니다. 이 부분은 빠른 시일 내에 업데이트 되길 기대합니다.

     




     

     

       대중교통 검색입니다. 역/정류장/버스번호 검색이 가능하며, 전철역을 조회할 경우 첫차/막차정보가 제공되고, 1호선의 경우 열차의 시간별 정보도 제공됩니다. 그리고 버스의 경우 각 노선의 실제 정차 정류장들 이름까지 모두 볼 수 있습니다. 버스 정류장 검색에서 아쉬웠던 점이, 정류장 정보에서 해당 정류장의 위치와 경기도 버스정보 시스템과의 연계로 버스의 위치도 알려줄 수 있었다면 정말 좋았을텐데 아쉽습니다. 구글과는 달리 한국 기업이기 때문에 충분히 가능성이 있지 않았나 싶네요.

     
      업데이트가 잦은 것은 그만큼 아직 걸음마 단계라는 이야기가 아닌가 싶습니다. 네이버 포털 어플리케이션과는 달리 정말 한 끗 차로 아쉬운 부분이 많았습니다. '이거 됐으면 좋았을텐데...' 하는 부분의 비율이 높았지요. 특히나, 버스정류장의 위치를 지도에서 바로 보여주는건 당연히 될 줄 알았지만, 안 된게 그리 썩 찝찌름하진 않아도 매우 아쉽습니다. 여러모로, 단점 몇개만 수정한다면 가장 바람직해 보이는 지도 서비스에서 가장 가까워 보입니다.
     
     
     
      아. 처음에는 원미 두산아파트에서 시작해서, N서울타워까지 네이버 지도를 믿고 간 후, 그 주변의 맛집을 네이버 지도로 찾아내어 식사를 하고 집에 가려고 했습니다. 하지만, 의외로 네이버 지도가 현장에서 길 찾기에는 사람 진이 쭉 빠지게 만들더군요.
     


      처음 시작은 가볍게, 옆에 원미산의 등산로까지 보일 정도로 상세한 네이버 지도를 등에 업고, 직접 검색하여 출발지와 도착지를 정해 대중교통 길찾기를 눌러줬습니다. 역시 네이버 답게 검색어에 대해 많은 결과물들을 보여줬습니다.

     


      얼추 이런 경로로 가라네요. 1호선에 접근하는 상세 경로는 확대하지 않았습니다만, 부천 원미동 두산아파트 근처 사는 분이라면 좀 당황하실지도 모릅니다. 급행열차가 있는 부천역으로 가는게 더 좋은데, 왜 굳이 소사역을 추천해주는지....


      1호선으로 가는 버스편은 여기서 이렇게 적지 아니합니다. 일단 원미 두산아파트 기준으로 56번, 56-1번, 60번, 95번, 9번이 1호선 소사역으로 이동하며, 3번 버스는 부천역, 3-1 버스는 부천역과 중동역, 013-1, 013-2번 버스는 역곡역으로 갑니다. 밑에 시내(최적)으로 된 부분을 클릭하면 여러가지 옵션을 택할 수 있습니다만, 어느 옵션을 클릭해도 다른 노선은 나오지 않았습니다. 아! 하나 있었네요. 시외버스 터미널 가서 4천원 내고 강변역의 동서울 터미널로 가라고 한 난감한 결과.


      여기선 또 다른 재미를 느꼈습니다. 다시 시도하려고 해도 반복되지 않아 매우 당황스러웠는데, 지하에서 내 위치가 잡히긴 합니다만, 반경 200미터 이내를 거의 0.5초단위로 제가 텔레포트 하고 다니더군요. 반면, 여친님의 모토로이에서 작동한 구글 맵은 아예 "일시적으로 위치를 사용할 수 없습니다." 라고 떴구요.

      이후 다른 곳을 돌아다니며 GPS가 잡히지 않는 곳 내부로 들어가보았는데, 아무래도 네이버 지도를 켠 상태에서 걸어들어가면 이런 현상이 발생하는게 아닌가 싶습니다.


      결국은 이렇게 현장에 도착했습니다만, 중도에 상당히 뻘쭘한 느낌이었습니다. 3호선 충무로역으로 갔다면, 혹은 명동역의 한개 역 직전인 회현역에서 남대문시장으로 갔다면, 동일한 버스를 타고 남산타워로 올라갈 수 있었습니다. 거리상, 시간상 모두 명동역에서 가는 방법보다 빠릅니다. 끝내 남산에 도착하긴 했지만... 진이 빠져서 주변의 맛집 탐색은 포기했습니다. 아. 진이 빠졌다는건 네이버 지도가 잘못된 정보를 주어서가 아닙니다. 제가 알고 있던 훨씬 쉬운 길과 네이버 지도가 준 길을 비교하는데, 햇볕이 무지막지하게 쨍쨍하게 비춰준 탓에 더워서 뻗어버린 겁니다. 인증은.... 안할랍니다. 처참해요. 그런데 이런 느낌은 있습니다. "네이버 지도는 가장 편하지도, 가장 어렵지도 않고, 그냥 무난한 길을 알려준다."

     

      여러모로 네이버 지도에 대해 다시 생각해보게 되었습니다. 네이버 지도가 정해준 길이 틀리진 않았습니다. 그리고 그렇게 썩 나쁜 길은 아니었구요. 하지만 명동 한복판에서의 텔레포트로 인해, 그리고 방향 지시 기능을 뒤늦게 발견하여 명동역에서 좀 헤맸습니다. 제가 좀 심한 길치거든요. 빠르다는 점은 엄청난 장점이지만, 헤메게 만든건 좀 얄밉습니다. 하지만, 그 정도는 커버할 수 있을 정도로 타 지도보다 빠릅니다.

     

      네이버 지도의 대중교통 길찾기는 대체적으로 "개략적인 길찾기"는 가능하여, 안내용으로는 적합하나 "실제 자신이 움직이며 쓰기에는 썩 좋은 편은 아니다" 라고 평하고 싶습니다. 명동 한복판에서 좀 덜 허덕이게, 방향 지시 기능을 쉽게 찾을 수 있었다면 좋았을 텐데요. 그리고 표기는 못했지만, 명동 한복판에서 제 위치가 이리저리 날라다닐때는 심히 당황했습니다. 이 때 여친의 모토로이에서 돌아가고 있던 구글맵은 꽤나 정확한 위치를 보여주고 있었구요. 아무래도 버그가 아닐까 싶습니다만.... 재현하기가 상당히 힘들군요. 네이버 지도는 '목적지에 가기 위한 기본적인 틀'을 잡는데 쓰시고, 실제 현지에서의 길은 현지 지리에 능숙한 사람에게 묻거나, PC에서의 지도를 보고 찾아가는게 편할 겁니다.

     

      하지만, 상당히 많은 양의 지하철/버스 노선 및 정류장 정보는 상당히 도움되었습니다. 네이버 지도가 찾아준 대중교통 길찾기에 의존하지 않고, 네이버 지도에서 제공된 대중교통 정보를 기반으로 제가 직접 경로를 짰다면 엄청나게 유용했을 겁니다. 제가 잘 보지 못했던 노선부터, 1호선 전철역의 시간별 전철 도착정보까지, 주어진 정보를 잘 활용할 수 있다면 엄청난 물건입니다.

     

     

     

     

    구글 지도

    네이버 지도 

     설치 후 용량

     8.91MB

    3.57MB 

     빌딩숲 내 내 위치 정확도

    약 2미터 반경의 오차 

    약 5미터 반경의 오차 

     내 위치 기능 분리

    한번에 위치와 방향 알려줌 

    두번에 나누어 위치와 방향을 단계적으로 보여줌 

     지도 저장 및 오프라인 사용

    X

     교통정보

    X

     해외 지원

    O

     메인 페이지 구동 시간(내위치 찾기 포함)

    약 8초 

    약 4초 


     전체적으로 보았을 때, 네이버 지도가 구글 지도에 비해 그리 밀리지 않습니다. 유저 인터페이스 부분은 솔직히 제가 구글을 더 자주 썼기 때문에 구글의 인터페이스가 더 쉽다고 느끼긴 합니다. 하지만, 네이버 지도의 인터페이스도 몇번 쓰지 않았지만 손에 착 붙는 느낌이 강해 뒤지지 않는 인터페이스 구성력을 갖췄다고 볼 수 있습니다. 방향지시 기능 빼고....

     

      네이버 지도가 한국에 특화된 서비스이기 때문에 한국 지도 서비스에서는 오히려 구글 지도보다 우위를 보입니다. 거기에 가지고 있는 정보의 수준도 네이버 지도가 한수 위입니다. 그렇기에 구글 지도에서 지원하지 못한 서비스도 제공할 수 있었지요. 다만, 그 정보를 제대로 활용하지 못했다는 느낌이 들어 아쉽습니다. 그 정보를 일부 활용하지 못했는데도 밀리지 않는 느낌의 네이버 지도. 앞으로의 꾸준한 업데이트를 기대합니다.

     

      비교 표에는 표기하지 않았지만, 버스 노선 및 전철 노선등 대중교통에 관한 정보의 상세함과 양에서 네이버 지도가 구글 지도를 압도했습니다. 구글 지도에는 대중교통 노선 검색같은건 존재하지 않거든요. 뿐만아니라, 구글 지도에서는 제공해 주기 힘든 "주변 교통정보(정체 수준)"는 지도 서비스에서 내놓을 줄은 생각도 못했었습니다. 네이버의 저력이 엿보이는, 아니, 그냥 대놓고 보이는 부분이었습니다.

     

      여기서, 가장 강력한 것은 바로 "교통정보" 입니다. 이 교통정보 덕분에, 이번 추석에 내려가고 올라가는 시간이 엄청 단축되었습니다. 21일 오전 10시에 경기도 부천에서 출발, 오후 3시에 경남 진해에 도착했습니다. 단 5시간만이지요. 정체가 한참이었는데, 정체 구간을 모두 피해가버렸습니다. 국도와 고속도로의 교통정보를 잘 혼합해, 가장 간편한 길을 찾았으며, 이는 네이버 지도의 빠른길찾기에서 지원되는 '실시간 빠른 길'에서 자동으로 찾아준 길입니다. 또한, 22일 오후 6시에 출발해 경상남도 창원시 마산구 내서읍 주변의 정체구간을 다 피해서, 오후 11시에 경기도 부천시에 도착했습니다. 또 5시간이지요. 구글 맵에서는 지원되지 않는, 가장 강력한 기능입니다. 트위터의 힘을 빌리지 않고 바로 네이버지도의 위력으로 이뤄냈습니다.

     


     

      한 명의 네이버 지도 유저로서, 이 부분만은 정말 강력하게 요청합니다.

    "방향 지시 버튼좀 알아보기 쉽게 바꿔주세요."

    하아.... 뭐. 말이 필요 없습니다. 이 기능이 없는 줄 알았으니까요. 뒤늦게 발견하지 못했다면 이 리뷰에서 정말 네이버 지도를 깊이가 보이지 않는 쿠릴 해구의 바닥을 박박 긁어댈 정도로 깊숙하게 네이버 지도를 비판했을 겁니다. 기능이 있다는데, 못찾으면 유저와 제공자가 서로 짜증날 수 밖에 없습니다.

     

      그 뿐만 아니라, 대중교통 검색에서, 정류장의 위치를 지도에서 보여줄 수 있었으면 합니다. 버스가 어느 정류장에 선다는것을 아는 것 만으로는 부족합니다. 네이버 지도의 대중교통 길찾기에서 버스 정류장의 위치를 알 수 있음에도 불구하고, 대중교통 검색에서 정류장의 위치를 지도에 보여주지 않는다는 것은 정말 매우 아쉽습니다.

     

      경유지의 갯수를 한개로 제한한 부분은 마음에 듭니다. 좁은 화면에서 여러개 경유지를 고르게 한다면 그저 화면에 경유지 갯수로 가득 채워지는, 보기 민망한 사태가 나올 수 있어 그리 썩 보기 좋지 않은 모양새가 될 가능성이 있습니다. 하지만! 경유지로 가는 대중교통 길찾기와, 경유지에서 최종 목적지로 가는 대중교통 길찾기를 뭉치면 경유지가 있어도 대중교통 길찾기가 가능하지 않나 싶습니다. 경유지가 있어도 대중교통 길찾기가 가능했으면 합니다.

     

      주변지역 검색 기능에서 사용자의 위치 뿐만 아니라, 사용자가 지정한 위치의 주변지역도 검색할 수 있도록 추가해 주신다면 상당히 좋지 않을까 합니다. 지극히 사용자적인 입장에서 본다면 이 기능이 추가될 경우 사용자의 편의성이 엄청나게 증대됩니다.

     

      한가지 더... 대중교통 길찾기에서 출발지부터 목적지까지 가는 방법들을 좀 더 다양하게 볼 수 있도록 알고리즘을 수정해 주셨으면 합니다. 무조건 최단거리 우선으로, 전철에서는 최소 환승으로 찾도록 하고 최단거리에서 어느 정도 벗어난 수준이면 바로 잘라버리는 것 같습니다만, 그게 항상 베스트 솔루션이지는 않습니다. 허용 범위를 늘려서 사용자가 더 많은 선택을 할 수 있도록 해 주시는게 어떨런지요.

     

      개략적으로 개선해야 할 점을 정리해 보았습니다.

     

    • 방향 지시 버튼을 좀 더 알아보기 쉽게 수정하거나, 내 위치 버튼과 분리해 배치할것.
    • 대중교통 검색에서 버스정류장의 위치를 지도상에서 바로 볼 수 있도록 처리해줄 것.
    • 경유지를 거쳐 가는 경우에도 대중교통 길찾기를 지원해줄 것.
    • 주변지역 검색 기능에서 사용자가 지정한 위치의 주변지역도 검색할 수 있게 해 줄 것.(개인적인 희망 사항입니다.)
    • 대중교통 길찾기에서 좀 더 많은 방법을 보여 줄 것.

     

    너무 무리한 부탁은 아니겠지요? 개발자분들께는 참 죄송한데, 제가 이 부분만 오면 너무 신들린듯 비판하는것 같아 미안할 나름입니다.


     


     

      네이버 지도에 대한 거의 무한한 기대감이 이 리뷰를 쓰면서 상당히 꺾이긴 했습니다만, 여전히 구글 지도보다 네이버 지도가 한국 국내에서 사용하기엔 훨씬 편하다는 생각은 변하지 않았습니다. 특히나, 업데이트가 잘 되고 있다는 점에서 앞으로의 무한한 가능성이 엿보이고 있어 네이버 지도에 대한 기대감이 아직은 예전의 반정도는 남아있습니다.

     

      '정보만 많은 네이버'라는 인식이 박힐 수도 있습니다. 하지만, '많은 정보를 잘 응용해 주는 네이버'가 된다면 네이버 서비스는 모바일 스마트 서비스의 절대 강자가 될 겁니다. 정보의 양과 상세함 만으로는 이미 국내 1위입니다. 이제, 양과 질을 넘어서서, '스마트'의 영역으로 네이버가 넘어오길 기대합니다.

     

      특히나, 이번 추석에 사용해본 네이버 지도의 교통정보 기능은 정말 강력했습니다. 정체구간을 피해 국도정보까지 결합되어 정말 놀라울 정도로 빠르고 신속하게 귀성길을 달려왔지요. 이 기능덕분에 네이버 지도가 '스마트'의 영역에 매우 가까워져 있다는 느낌입니다.

     

      머리를 쥐어싸매고 리뷰를 쓰니 시간이 의외로 잘 가는군요. 어느덧 저희집 개도 잠들어 있네요. I/O장치가 작살난 노트북이라 그런지 확실히 엄청 버벅댑니다. 솔직히 몇 글자 남지 않은 상황인데 갑자기 전원이 나가버릴 까봐 조마조마 합니다. 여러분은 모쪼록 컴퓨터를 너무 막 굴리지 마시길 바랍니다. 저처럼 집에 컴퓨터가 남아나지 않을 수도 있답니다.


     


     
     

    posted by Lonewolf dlbo

    댓글을 달아 주세요

    2010.09.27 12:42 (비정기) Dlbo's Post

    

















     
     

     

     

     

     

     


     
     


     
     

      말이 가을이지 무지하게 덥네요. 저희집 개도 혀를 길게 늘여놓고, 침을 질질 흘리면서 집안에 침입합니다. 말 못하는 개라 참 때리기도 그렇고 한데, 말은 분명히 알아듣는 머리좋은 개라 참 묘합니다. 때려서 내쫒아야 할 까 봐요. 마당에 키우는 진돗개입니다.

     

      일전의 리뷰에서는 웹브라우저로 제공되는 서비스를 네이버의 포털 어플리케이션에 포함 시키느냐, 마느냐의 문제로 어떻게 써야 할 지 감이 오질 않았습니다. 그래서 일단 간단한 시리즈로 네이버 어플리케이션부터 N드라이브, 지도, 블로그의 간단한 심플 리뷰를 작성하고, 제대로 된 디테일 리뷰를 따로 준비하게 되었습니다.

     

      네이버 어플리케이션의 첫 주자, "네이버"의 포털 어플리케이션 서비스를 상세하게 리뷰하겠습니다.



     

    국내에는 아이폰이 안드로이드보다 우선 발을 들여놓았습니다. 국내 뿐만 아니라, 세계적으로 안드로이드는 아이폰보다 후발주자입니다. 애플 앱스토어 대 안드로이드 마켓. 미국에서 드로이드로 시작된 안드로이드의 열풍이 한국의 모토로이를 만들어내면서 국내에도 안드로이드 열풍이 불기 시작했습니다. 이로 인하여, 2010년 7월 안드로이드가 아이폰의 웹브라우저를 넘어서기 시작, 2010년 9월 현재, 안드로이드의 모바일 브라우저 접속율은 아이폰을 크게 상회하는 69%까지 급증한 상태입니다.

     


     
     http://gs.statcounter.com/#mobile_browser-KR-monthly-200908-201009

     

    안드로이드의 모바일 접속 시장이 급격하게 커 가고 있는 시점, 네이버로서는 안드로이드 시장을 그냥 쉽게 버릴 수는 없을 것. 이는 네이버만의 문제가 아닙니다. 다음, 야후를 비롯하여, 여러 신문사들과, 심지어는 몇몇 소규모 포럼에서도 안드로이드를 위한 모바일 페이지를 따로 제공하기 시작했습니다. 하지만 데스크탑이나 노트북이나 핸드폰이나 스마트폰이나 mp3나 모두 공통적으로 갖게 되는 골치아픈 부분이 있었으니...

     

    웹브라우저는 어디서든 무겁다.

    라는 불변의 진리.

    이건 도무지 어떻게 할 방안이 쥐뿔도 없으며, CPU가 좋건 램이 좋건 웹브라우저가 일반 어플리케이션보다 느리다는건 도저히 바꿀수 없는 내용이지요. 그렇다고 모든 회사가 웹브라우저를 제작하는 회사에 좀 가볍게, 빠르게 만들라고 닥달한다고 이게 해결되지는 않잖습니까? 웹브라우저 제작사들도 한두개도 아니고. 특히나, 안드로이드의 비좁은 내장메모리 속에서 웹브라우저 덕분에 엄청난 속도로 쌓여가는 캐시들. 안드로이드 유저의 입장에서는 초반에는 어떨런지 몰라도, 루팅을 하지 않는 한 캐시의 정리에 점점 지쳐갈 뿐입니다.

     

      이런 상황에서 나온 대안이, 어플리케이션으로 웹페이지를 대신한다는 방법입니다. 안드로이드 어플리케이션은 자체로서 XML로 화면을 구성해, HTML 웹페이지와 비슷한 환경으로 어플리케이션을 가동시킵니다. 즉, 기존의 모바일 웹페이지를 약간만 고친다면, 웹브라우저를 쓰지 않고 훨씬 빠르고 가벼운 어플리케이션에서 모바일 서비스를 받을 수 있다는 것이지요. 외국에서는 이미 BBC, 야후 등의 우량 회사들이 어플리케이션을 통해 모바일 서비스를 제공하고 있고, 국내에서는 네이버와 다음을 필두로 하여, 연합뉴스, MBC mini 등의 서비스가 확산되고 있습니다.

     

      국내 포털 서비스의 1인자인 네이버는 과연, 어떤 식으로 안드로이드에서 서비스를 제공할까요?


     


     

      일반적으로 안드로이드의 어플리케이션은 안드로이드 마켓에서 대부분 다운로드 할 수 있습니다. 안드로이드 마켓의 규모도 엄청나게 급성장하고 있음이 눈에 보이는 것이, 저는 루팅사용자로서 Market Enabler를 이용해 미국 T-Mobile의 마켓을 이용하고 있습니다. 마켓의 새 어플 카테고리에서 무수히 업데이트 되어 올라오는 어플의 양을 보면, 가히 상상을 초월합니다.

     

    안드로이드 마켓에서 네이버를 검색해볼까요?

     

     네이버의 안드로이드 마켓 검색 결과입니다. CONI Team이라는 팀에서 개별적으로 제공하는 또다른 네이버 서비스도 있네요. 네이버의 OpenAPI를 활용한 사례일까요? 네이버가 모바일에서도 상당한 강자임을 확인할 수 있는 부분이지요.

    

    네이버의 제공자는, 네이버의 모기업인 NHN Corporation이군요. 평점이 별 네개 반. 아쉽게도 5개를 모두 채우지는 못한 모습입니다.

     

     NHN에서 제공하는 공식 네이버 어플들의 모습입니다. 대체적으로 별 네개는 받고 시작하는군요. 네이버 포털 어플리케이션으로 끝내지 않고 5개의 서비스로 나눈 이유가 무엇일까요? 부분 기능만 사용하는 유저들을 위한 배려일까요?

     

    일단 네이버를 클릭하여 설치하겠습니다.

     

    

     네이버 어플리케이션의 설명부분. 의외로 3724명의 평가밖에 없습니다. 스크린샷 하단에 빨간색으로 표기한 부분이 보이시나요? 폰에서 저 부분을 클릭하면, 설치가 진행됩니다.

     

    네이버의 포털 서비스 어플리케이션은 기본적으로 안드로이드 마켓에서 다운로드 할 수 있습니다. 'NHN Corporation'으로 검색하면, 네이버의 공식 어플리케이션들을 다운로드 받아 설치할 수 있고, '네이버'로 검색하면 CONI Team의 비공식 어플리케이션도 다운로드 할 수 있습니다.

     

    설명 부분에서, 네이버 포털 어플리케이션의 제공 서비스에 대해 설명하고 있군요.

    보기 쉽도록 아래에 정리해 두었습니다.

     

    1. 초성 자동완성 기능. 초성 입력만으로 그에 맞는 원하는 검색어를 제공합니다.
    2. 연락처 검색 기능. 휴대폰 안의 연락처를 네이버 포털 어플리케이션에서 검색이 가능합니다.
    3. 검색어의 저장과 삭제를 제공합니다.
    4. 실시간 급상승, 영화/뉴스의 일간 검색어를 제공합니다.
    5. 네이버 모바일 웹 서비스에 주소를 입력하지 않고 접속이 가능합니다.
    6. 대기화면에 네이버 검색 위젯을 제공합니다.

     

    휴대폰 안의 연락처를 검색해주는 기능 외에는 대체적으로 평이합니다. 제가 사용하는 폰은 모토로이로, 사실상 이 기능은 필요치 않습니다. 하지만 검색 부분에서 초성 자동완성 기능을 제공하는 부분은 의외로 기대되는군요. 솔직히 키보드 없는 휴대폰에서 초성만으로 검색이 가능하다면, 꽤나 편한 입력을 맛볼 수 있습니다.

     

      그러나 이 설명만 가지고는 상당히 실망입니다. 그래도 1위 기업 네이버인데, 이정도 수준의 기본적인 내용만 제공한다? 실제로 사용해보면, 상당히 많은 서비스를 제공하고 있음을 알 수 있지만, 1.0 버젼으로 업데이트가 전혀 되어있지 않고, 설명도 그냥저냥 글자 수에 맞추어 써놓은 느낌입니다. 아무래도 직접 사용해보지 않으면 확실히 알 수 없겠군요. 어찌 보면 1위 검색포털의 당당함일지도 모르겠습니다.


     


    

    잘 생각해 보니, 네이버 어플리케이션의 용량과 정보에 대해 언급하지 않고 넘어왔군요. 네이버야 당연히 네이버에서 개발했겠고, 개발자도 네이버 개발자이겠거니.... 하지만, 네이버 개발자의 이메일 주소가 급 궁금해 집니다. 과연?

     

      네이버의 어플리케이션 스크린샷과 개발자 소개 부분입니다. 일단 버전은 1.0.25로, 업데이트를 한번 하긴 했나 보군요. 용량은 542KB로 상당히 가벼운 편입니다. 개발자 웹페이지는 네이버가 아닌, NHNCorp의 주소가 기록되어 있고, 개발자 이메일은 search_app@naver.com으로 기록되어 있군요. 개발자 이메일의 도메인과 개발자 웹페이지의 도메인이 서로 달라, 상당히 이질적인 느낌이 듭니다. 거기에 덧붙여, 저 이메일은 아무리 봐도 개발자 이메일이 아닌 고객민원접수창구로 보입니다. 대기업이니 만큼 민원접수를 거쳐서 개발자에게 전달되는 걸까요?

     

      폭팔하는 호기심이 결국 이메일을 보냈습니다. 민원창구냐, 아니면 개발자 메일이냐고 물어보았습니다. 바쁘실텐데 상당히 귀찮게 해드려서 죄송하다는 생각....보다도. 알고싶습니다. 저게 개발자 이메일인지. 단지 그 뿐.

     

      네이버 어플리케이션의 메인 화면과 제공 서비스를 공개합니다!

       안타깝게도 밑에 두 친구가 잘렸는데, 그 두 친구는 영어사전과 책 서비스입니다. 상당하군요. 네이버 웹페이지에서 제공하는 대부분의 서비스가 네이버 포털 어플리케이션에서 제공됩니다. 하지만, 지나치게 작은 용량이 걱정됩니다. 무엇 덕분에 그리 작은 용량을 만들 수 있었을까요?

    

    메일, 캘린더, 커뮤니케이션캐스트, 블로그, 카페, 뉴스, 지식iN..... 여기까지만 제공하는 것이 아닙니다. 인기검색어 부분을 통해, 아까 어플리케이션 소개에서 강조된 급상승 인기검색어와, 영화, 뉴스의 검색 순위도 제공됩니다.

     

     

    상단의 빨간색으로 강조한 부분을 터치하여, 세개의 다른 화면으로 각각 이동이 가능합니다. 또한, 화면의 아무 부분이나 누르고 옆으로 슬라이드 시켜주면, 다른 화면으로 전환됩니다. 글자 입력이 불편한 휴대폰임을 고려하면 상당히 유용한 기능입니다만, 원하는 검색 테마도 추가할 수 있었다면 좋았을텐데 말이지요. 이 점이 조금 안타깝습니다.

     

     


     
     

     

    네이버 위젯의 모습입니다. 여자친구의 얼굴은 초상권상 편집했습니다. 솔직히 그냥 올리고 싶은데, 자기 얼굴 너무 팔아먹는거 아니냐길래 슬그머니 가렸습니다만, 빨간색으로 너무 대충 가린 느낌입니다. 뭐... 가려주긴 했습니다. 이렇게 홈화면에 위젯으로 네이버 검색을 띄울 수도 있습니다. 안타까운 점은, 음성검색이 안된다는것. 그리고 디자인이 좀 너무 튄다는것. 네이버가 녹색 이미지라고는 해도 너무 톡 튀는 색입니다. 원하는 색상으로 변경 가능하면 좋겠군요. 투명까지 바라면 너무 욕심이겠지요?

     

      무엇보다도, 네이버의 웹페이지 서비스를 거의 대부분 고스란히 안드로이드에서 사용 가능하게 되었다는 점이 매력적입니다. 대체로 유저들의 평 또한 "빠르다, 좋다"로 모아지고 있는 상황이며, 화면이 간결해 네이버 웹페이지와는 다르게 어떤 서비스가 제공되는지 한 눈에 들어옵니다. 네이버 카페, 블로그가 상당히 활성화 되어 있는 점을 볼 때, 상당히 매력적인 서비스라고 볼 수 있습니다.

     

      다만, 아쉬운 점은, 영어사전, 증권 등의 기능을 보면서 느낀 부분입니다만, 원하는 서비스만 골라서 서비스받을 수 있다면, 좁은 모토로이의 화면에서 귀찮은 스크롤링을 하며 쓰지 않는 서비스까지 다 봐야 하는 문제점을 커버할 수 있었을 것이라는 부분입니다. 기능이 많다고 다 좋은게 아니라, 쓰고 싶은 기능만 골라서 볼 수 있다면 그보다 더 좋은 환경이 어디있겠습니까?


     

    

      일단 서비스가 무지하게 많습니다만, 과연 저 서비스들이 얼마나 위력적일까요? 윙버스 서울맛집이라는 처음 보는 서비스부터, 친숙한 메일과 뉴스, 카페, 블로그 서비스에, 제가 가장 자주 쓰는 웹툰 서비스도 제공되고, 가장 눈길을 끌던 부분은 바로 N드라이브와 포토앨범 서비스였습니다. 웹하드 서비스가 안드로이드에도 본격적으로 제공되면서 상당히 유용하게 쓰일 수 있다는 부분입니다. 모토로이의 비좁은 내장 용량에 활기를 트여줄 부분이고, 용량 적은 일반적인 안드로이드 폰에 매우 매력적인 서비스이니 눈길이 가장 갈 수 밖에 없더군요.

     

     

     

    

      네이버 N드라이브를 선택해 보았습니다. 일전에 N드라이브의 리뷰를 위해 올려두었던 파일들이 보이는군요. 참 안타까운건, 파일 올리기와 다운로드가 지원되지 않는다는 겁니다. 하긴, 브라우저를 통해 다운받아도 되니 굳이 고생할 필요도 없고, N드라이브의 어플리케이션이 따로 나와 있으니 굳이 여기서 다운 받을 필요도 없습니다만, 상당히 아쉬운 부분입니다.

     

      모토로이에서의 식은 감자, hwp 파일이 보입니다. 한번 클릭해 보았습니다.


      의외입니다! 웹페이지에서 바로 hwp파일이 보입니다. 모토로이에는 hwp 뷰잉 능력이 전혀 없고, 그럴만한 어플리케이션을 현재까지 구할 수 없었는데, 생각보다 간단하게 hwp 파일을 볼 수 있게 되었습니다. 웹브라우저를 거친다는게 참 민망하고 아쉽기 그지없지만, hwp 파일을 이렇게 볼 수 있다는 점은 정말 대단합니다.

     

     멀티터치로 확대해서 보는 기염까지! 보아 하니 hwp 파일을 그림화 시켜서 보여주는 것 같습니다. 매우 빠르고 신속하게 확대/축소가 되고, 원하는 내용도 쉽게 볼 수 있습니다. 꽤 깔끔하게 보입니다. 이렇게 모바일 뷰잉이 지원된다면, 모토로이의 사용성이 엄청나게 확장될 겁니다.

    

    좀 더 뜯어보고 싶지만, 웹페이지 기반이라 그런지 이게 다입니다. 웹페이지에 너무 많은 걸 바랄 수 없으니, 메일로 jpg 파일을 전송해 보겠습니다.


      파일 좌측의 체크박스를 클릭해 파일을 고르고, 하단에 빨간색으로 강조된 메일 보내기를 눌러주면 메일 보내기 창이 열립니다. 일단 사용법은 단순해서 좋네요.

     


      메일 창이 열리며 자동으로 파일이 첨부됩니다. 내게 쓰기와 개인별 보내기가 가능하고, 주소록과 연동이 가능하군요. 임시저장 버튼도 존재하구요. 나름대로 대충 채워서 전송해봤습니다. 가장 중요한게 전송이 되는지 아닌지 아니겠어요?


      오호. 전송 잘 됩니다. 이 메일은 네이버 메일 서버를 통해 전달되고, 지메일에서 수집을 한 후, 제 모토로이로 날아왔습니다. 여기까지 걸린 시간은 대략 10분. 생각보다 빠른 속도입니다. 네이버 서버에서 네이버 서버로 전송하기 때문에 빠른것이겠지요?

     
    웹페이지에서 hwp파일이 보인다는게 상당히 매력적입니다. 그리고 바로 즉석에서 메일로 전송이 된다는 점도 좋구요. 다만, N드라이브 어플리케이션이 따로 제공되기 때문에 굳이 용을 써서 웹페이지에서 다운받고 할 필요는 없어보입니다. 굳이 중복되는 기능을 개발자들 피똥싸게 만들 필요는 없잖아요?
     
    다음으로 주목했던 포토앨범 서비스. 자동 분류 기능이 상당히 마음에 들었습니다.
     

      오호. N드라이브 탭이 있군요. 포토앨범과 N드라이브가 서로 연동된 구조라는 의미이겠죠? 여태까지 N드라이브에 사진을 올렸는데, 이게 포토앨범에서 자동으로 월별 분류를 해주네요. 상당히 편리한 기능입니다.

     

     8월을 누르니, 8월의 두 날짜에 찍은 사진들이 보입니다. 위에 26일자 찍은건 명동 고양이 다락방에서 찍은 사진들입니다. 클릭할 경우, 그 날의 사진들이 모두 주르륵 나옵니다. 이 부분 또한 스크린샷을 첨부할까 했지만, 여친님의 초상권도 보장해 줘야지요. 이 부분은 추가 첨부하지 않겠습니다.

     
      N드라이브와 포토앨범, 꽤나 쓸만한 기능입니다. N드라이브 어플리케이션에서 다루는게 더 유용한 부분이니, 이 부분에 대해선 더 상세히 다루지 않겠습니다.
     
      다음 볼 부분은 웹툰 서비스입니다.
     

      웹툰을 열면 요일별, 장르별, My 웹툰 세가지의 탭이 나오는군요. 개인적으로 상당히 즐겨보는 나이트런이 두번째에 올라와 있군요. 상당히 즐겨보는 웹툰입니다. 각 웹툰을 클릭하여, 리스트에서 관심 웹툰을 추가하면 My 웹툰에서 볼 수 있습니다.

     

      저어~기 상단에 빨강으로 강조한 부분 보이시죠? 저기를 누르시면 My 웹툰에 추가됩니다. 추가된 부분을 보실까요?

     

      하핫. 제가 자주 보는 웹툰들이 이미 추가되어 있네요. 최근 업데이트된 작품은 UP이 붙어있답니다. 옆에 나이트런 처럼 말이지요.

     
      저처럼 시간이 남을때 웹툰을 보면서 시간을 때우는 사람들에게 상당히 유용합니다. 원하는 서비스만 골라서 챙겨 보는 유용함도 웹툰 서비스에는 잘 추가되어 있네요. 기존의 웹브라우저를 열어 네이버 주소창을 입력하고 접속하는 방법보다 훨씬 빠르고 간편하긴 합니다만, 웹브라우저의 기본 홈페이지가 네이버로 설정되어 있으면.... 있으나 마나이긴 합니다. 브라우저에 의존하지 않고 바로 보여주었다면 꽤 좋았을텐데 말이지요.
     
      이렇게 하나하나 소개하다가는 정말 끝도 없이 소개만 해야 할 것 같습니다. 이 글을 읽는 분들의 편의를 위해서, 이제부터 간략하게 각 서비스의 핵심 부분 스크린샷만 첨부하고 리뷰하지요.
     

      네이버 블로그 서비스의 내 소식 부분입니다. 제 경우는 개발자 지망생인지라, 코드 구문 강조 기능을 쓸 수 있는 타 사의 블로그로 옮겨가서 현재 블로그가 폐쇄상태입니다. 하지만, 내가 남긴 글 소식에서 덧글이 달리거나, 안부글이나, 여러 소식들을 전달 받을 수 있지요. 상단의 포스트에서는 자신의 포스트를 볼 수 있고, 안부글과 이웃 새글에서는 각각 자신 블로그의 안부글과 이웃 새글 소식을 볼 수 있습니다. 또한, 자신의 블로그에 글을 게제하는 포스트 쓰기 버튼 또한 이웃새글의 상단에 존재하네요.

     

      네이버의 영어사전 서비스입니다. 로또를 검색하기 위해 lott까지 쓰니, 자동완성 기능이 동작합니다. 이 뿐만 아니라, 기존 검색한 단어를 저장해주어 언제든 다시 쉽게 볼 수 있게 해주고, 너무 자주 봐서 다시 볼 필요 없는 단어는 검색목록에서 삭제도 가능합니다. 단점이 있다면, 웹브라우저에서 보는 것이기 때문에 폰 자체의 내장 영어사전에 비해 심히 무겁다는 점입니다만, 네이버 웹과 연동이 된다는 점은 무시할 수 없습니다. 

     

      여친님과 함꼐 가볼 맛집을 검색할 수 있는 윙버스 서울맛집. 여친님께서 홍대를 나와서 홍차를 좋아하는(?).. 여인네라 홍대 근처의 티앙팡을 찾았습니다. 여러 사람들의 평가와 지도, 전화번호를 갖고 있어 쉽게 찾아갈 수 있고, 사용해본 사람들의 평가를 볼 수 있어 분위기가 어떠한지 짐작해볼 수 있습니다. 하지만, 네이버에서 직접 관리하는게 아닌, 계약에 의해 외부 업체가 수주하는 형식으로 서비스를 제공하는것 같습니다. 그로 인해 네이버 포털 어플리케이션 자체와 상당히 분위기가 다른 느낌입니다.

     

      네이버의 책 서비스. 내 서재에는 자신이 골라둔 책들의 리스트를 볼 수 있습니다. 오늘의책 탭에서는 네이버가 매일 책을 선정해 보여주며, 베스트셀러는 가장 잘 팔린 서적들을 보여줍니다. 책들의 가격 정보와 간략한 내용, 리뷰를 볼 수 있습니다. 참고로 전 가난해서 저 5개 책도 못샀습니다 ㄱ-.....

     

      네이버의 캘린더 서비스입니다. 제 경우 구글캘린더에 너무 익숙해져 있어 도저히 사용할 엄두가 나지 않습니다. 게다가 웹브라우저 기반인데, 캘린더의 경우 상당히 자주 왔다갔다 거려야 하기 때문에 웹브라우저의 속도로는 쓰기 참 민망합니다. 네이버 하나에 모든 기능을 다 통합해서 쓰면 참 좋겠지만, 캘린더는 도저히 엄두가 안나서 패스.

     

      제가 네이버를 가장 자주 쓰는 이유인 커뮤니케이션 캐스트 서비스입니다. 내 소식 부분에서는 카페와 블로그의 모든 글에 달린 덧글 및 여러 소식을 모두 보여줍니다. 블로그와 카페 부분에서는 각각 블로그 이웃들과 자신 블로그의 소식을, 카페에서는 자신이 가입한 카페들의 새 소식을 알려줍니다. 미투데이는 제가 사용하지 않아서 New가 없군요.

     

      커뮤니케이션 캐스트로 인해 상당히 존재가치가 묘한 카페 서비스입니다. 알림이나 여러 부분을 커뮤니케이션 캐스트가 모두 전달해 주다 보니 카페 목록을 보는데 그칩니다. 새 소식이 잘 없는 카페에 접속할때는 괜찮겠습니다.

     

      네이버의 꽃, 지식iN 서비스입니다. My지식을 비롯하여 여러 부분에서 자신의 관심분야나, 아는 것에 대해 질문의 답을 할 수 있고, 역으로 자신이 궁금한 것을 질문할 수도 있습니다. 이 부분에서 엄청나게 아쉬운점! 질문은 문자메시지로 모바일 서비스를 써야 한다는 겁니다...... PC버젼으로 접속해서 질문하시는게 훨씬 낫습니다.

     

      타 유저분들의 프라이버시를 위해 연락처들은 가렸습니다. 잘 보시면 보일지도 모르겠습니다만... 그 전에 눈이 아플겁니다. 쪽지를 주고 받을 수 있고, 메일을 보낼 수도 있으며, 각 사람들의 이메일이나 블로그, 연락처를 관리할 수 있는 서비스입니다. 네이버 N드라이브나 메일 등에 연동된 서비스라고 보면 됩니다. 안타까운 부분이, 폰에 있는 주소를 자동으로 픽업해다가 추가해주면 참 좋겠는데 말이지요. 하나하나 다 추가해야 하나 봅니다. 아무리 검색해봐도 방법이 없네요.

     

     네이버 뉴스의 크게보기 부분입니다. 참.... 민망하게시리, 크게보기를 해도 원래랑 똑같더라구요. 민망해서 원래 보기는 안올리겠습니다. 그냥 민망할 뿐, 다만 속보 등을 네이버를 통해 빨리 볼 수 있다는 점은 장점입니다. 속보 뿐만 아니라, 분야별로 원하는 뉴스를 골라 볼 수 있습니다.

     

      원하는 지역을 골라서 날씨를 볼 수 있는 네이버 날씨. 자신의 지역과, 관심 지역을 설정해두면 네이버 날씨 메인에서 바로 해당 지역들의 기상예보를 볼 수 있습니다. 참 묘한게, 상단 부분은 왜 파란색으로 잡아뒀는지 모르겠습니다. 그냥 통일성 있게 녹색으로 두었으면 좋았을텐데. 전 갑자기 기상청 홈페이지로 이동한줄 알았습니다.

     

    

      네이버의  증권 서비스입니다. 증권의 시세와 해외 증시, 종목별, 시장별 내용을 전부 볼 수 있으면서, 증권가 뉴스를 접해 볼 수 있습니다. 또한 원하는 업종을 골라 My 증권에서 관심목록으로 두고 볼 수 있지요.

     

      TV편성표 서비스입니다. 스카이라이프, 공중파, 지상파 등 여러 채널의 TV 편성표를 볼 수 있으며, 좋아하는 채널들을 골라서 My 채널에 리스트를 두고 해당 채널들을 모니터링 할 수 도 있지요. 만에 하나, 각 폰의 내장 DMB 뷰어와 연동해서 해당 방송들을 볼 수 있었으면 어떨까... 합니다.

     
      네이버의 서비스. 정말 많네요. 그냥 뭐 징그럽다고 해도 과언이 아니겠습니다. 정말 아쉬운게 원하는 서비스만 골라서 어플리케이션의 화면에 둘 수 없다는게 안타깝습니다. iGoogle 같은 경우는 자신이 자주 쓰는 서비스만 골라서 연동시켜 두기 때문에 상당히 유용합니다만, 네이버에서도 이런 서비스를 해 준다면 정말 고맙겠습니다.
     
    아. 넘어가기 전에 네이버의 안드로이드 제공 서비스들을 정리해 볼까요?
     
    • 메일
    • 카페
    • 캘린더
    • 커뮤니케이션 캐스트
    • 뉴스
    • 블로그
    • 미투데이
    • 지식iN
    • 증권
    • 날씨
    • 웹툰
    • TV편성표
    • 윙버스 서울맛집
    • N드라이브와 포토앨범
    • 주소록
    • 영어사전
    •  

     

      정말 많습니다. Mobile Lifestyle Innovation이라고 부를 수 있겠습니다. 웹브라우저에 의존해야 하는 부분만 제거한다면 말입니다.

     


     
      다음 어플리케이션은 네이버 어플리케이션의 세배가 넘는 용량인 2.7MB를 자랑합니다. 육중하지요? 하지만, 다음 어플리케이션은 네이버와 다르게, 웹브라우저 의존도가 낮습니다.

     


     
     다음 어플리케이션의 캘린더 부분의 스크린샷입니다. 다음 어플리케이션의 경우는 훨씬 무겁지만, 자체 안드로이드 HTML뷰어를 통해서 무겁디 무거운 웹브라우저를 띄우지 않아도 됩니다. 이 경우 캐시가 많이 쌓이는 단점이 있으나, 이 부분은 어플리케이션이 종료될때 알아서 지우도록 만드면 될 일입니다.

     

      이 뿐만이 아니라, 다음 어플리케이션은 음성검색도 됩니다.



     
      그저 허허... 웃지요. 이 부분때문에 다음이 용량이 더 크다고 할 수도 있겠습니다.  여기서 끝나지 않습니다. 네이버 포털 어플리케이션에서는 웹브라우저를 가동시키지만, 로그인은 시켜주지 못합니다. 아니, 로그인 자체가 없습니다. 모토로이처럼 상당히 가용 램이 작은 경우에는 매번 서비스를 실행할때마다 로그인을 일일이 해 주어야 한다는 겁니다. 반면, 다음은 아예 로그인 기능을 집어넣어 아래처럼 되어있습니다.

     


     
     

      하하.... 너무 적나라하게 까고 있는 느낌이 듭니다. 위젯도 네이버처럼 다음도 모두 지원합니다. 네이버가 다음보다 서비스가 더 많다는 점이 우세하긴 합니다만, 사용자 편의성의 부분에서 네이버가 아주 사소한걸 놓쳤습니다. '로그인' 이라는 중요한 열쇠.


     

     네이버

    다음 

     설치 후 용량

     1.36 MB

    4.77 MB 

     로그인 기능 지원

     서비스간 이동 방법

    웹브라우저 

    자체 뷰어 

     제공 서비스의 수

    18개 

    30개 

     음성검색 지원

     캐시 사용 여부

     
      허허.... 놓고 보니 네이버. 민망하네요. 이렇게 두면 안되는거 였나요? 제공 서비스의 수에서조차 네이버가 밀립니다. 아이폰에 먼저 투자하고 안드로이드로 넘어온건 다음 또한 같을텐데 말이지요. 다음보다 한발 늦게 들어왔기 때문일까요?
     
      그래도, 데스크탑 웹의 시장에서 1위를 했던 네이버인 만큼, 각 서비스의 퀄리티는 다음에 비해 우위였습니다.  무엇보다도, 저 용량의 압도적인 차이는 도저히 어찌 할 수가 없네요. 거기에 다음은 캐시를 사용한다는 점이 핸디캡으로 작용합니다. 자체적인 캐시 삭제 루틴도 없더군요. 네이버가 안드로이드에서는 후발주자임을 고려한다면 그리 썩 나쁘다고만은 할 수는 없네요. 네이버의 다음번 업데이트를 기다려봐야 하겠습니다.
     
      아. 이건 확실히 짚고 넘어가야 겠네요. 네이버의 여태까지의 PC 웹에서의 행보는 상당히 "일단 많은 서비스와 정보를 제공한다" 라는 느낌이 강했습니다. 그로 인해 PC 웹에서는 국내 1위의 검색포털이 되었고, 검색 포털을 넘어서서 PC 웹의 Lifestyle로 자리잡았습니다. 이 행보를 그대로 모바일 시장에 그대로 옮기지 않았으면 하는 바람입니다. 모바일 안드로이드 기기는 PC나 노트북처럼 화면이 광활하지 않습니다. '스마트'폰, '스마트'패드 등의 이름이 붙을 정도로, 똑똑함을 요구하는 기기기 되어 가고 있기 때문에, 단순히 많은 서비스와 많은 정보를 제공한다고 만사 OK가 아닙니다. 현재 다음이 모바일 서비스에서 네이버의 PC 웹 시장의 행보를 따라 걷는다는 느낌이 있는데, 네이버는 PC웹 시장에서의 행보에서 자연스레 다음보다 고 퀄리티의 서비스를 아주 자연스럽게 제공하기 시작했습니다. 모바일 시장에서는 무작정 서비스와 정보, 기능을 늘리는 것이 아니라, 이미 있는 서비스들에서 선별하여 '유저가 원하는 서비스'만 제공하고, '유저가 원하는 정보'만 캡쳐할 수 있는 인터페이스를 갖추어 나가야 한다고 생각합니다.
     



      네이버 어플리케이션은 일단 상당히 치명적인 "자체적인 로그인"을 지원하지 않는다는 부분이 있습니다. 모바일에서 안그래도 글씨 하나씩 치기 버거운데, 음성입력도 지원하지 않으면서 자체 로그인이 없다는건 상당히 귀찮습니다. 물론 비밀번호를 음성입력으로 하면 안된다는 점에서 자체적인 로그인 기능 외에는 해법이 없는게 사실입니다. 음성 검색의 부재 또한 그렇습니다. 모바일 검색에서 버튼 하나하나 누르기 힘들다는 점을 고려해 음성 검색을 추가해 주어야 합니다. 웹브라우저에 대한 의존도 또한 낮춰야 합니다. 웹브라우저가 둔하기 때문에 어플리케이션으로 커버를 하려는 건데, 이런 식이라면 그냥 웹브라우저의 홈페이지를 네이버로 두어도 크게 차이가 없습니다.

     

    1. 자체적인 로그인을 지원할 것. 유저들은 이 부분이 매우 귀찮으니, 한번만 설정에서 입력하면 언제든 로그인 가능하게 지원해주어야 함.
    2. 웹브라우저를 켜서 보여주는 것 보다 안드로이드 HTML뷰를 이용해 보여주고 프로그램 종료 전에 캐쉬가 삭제되도록 변경해줄 것. 안드로이드 어플을 개발하기 위해 공부중인 한 사람으로서 이 부분이 그리 썩 어렵지만은 않다는것을 알고 있음.
    3. 음성검색을 지원해 줄 것.
    4. 화면에 표기되는 서비스 수를 줄일 수 있도록 원하는 서비스만 화면에 표시할수 있는 옵션을 추가해 줄 것. 무조건 많다고 좋은것이 아님.

     

    얼추 이정도가 되겠군요. 그렇게 많은 것을 바라는게 아닙니다. 이 부분은 적어도 처리해주었으면 하는 것이지요. 특히나, 2번이 업데이트 된다면 제 모토로이의 시스템 폴더에 네이버 어플을 박아버릴 겁니다. 작업할 양이 상당히 많아지겠지만, 언젠가 된다면 반드시 박아넣습니다. 사실, 2번의 내용은 저렇게 HTML뷰를 이용해 처리한다면 거의 겉핥기식이나 다름없습니다. 저 수준에서 더 나아가, 모바일 웹 페이지와는 완전히 독립적으로 구동 가능한 어플리케이션이 되길 희망합니다만, 개발자분들 수고가 지나치게 많으려나요.



     

      리뷰를 쓰기 시작한지 어느새 7시간이 흘렀습니다. 중도에 소개를 띄엄띄엄 한 부분이 있긴 합니다만, 전부 하나하나 상세히 소개했다면 왠만한 근성있는 분이 아니면 끝까지 읽지 못할 겁니다. 솔직히 지금 이 글도 끝까지 읽어주실 분이 있을까 의문이 들긴 합니다. 네이버 어플리케이션이 웹브라우저에 너무 의존하지만 않는다면 상당히 이용가치가 높은 어플리케이션입니다. 말 그대로 손안에 한국을 들고다닌다고 해도 과언이 아닙니다.

     

      네이버의 높은 퀄리티의 서비스와, 많은 기능. 그리고 수많은 PC웹에서의 유저들로 인해 제대로 잘 다져진 네이버의 앞길은 모바일 포털 시장에서 좀더 '스마트'한 행보를 걷도록 주의한다면 빠른 시일 내에 국내 안드로이드 기본 검색자가 네이버로 변경될 지도 모르겠습니다. 네이버가 속히 단점들을 개선하는 업데이트들을 내놓길 바라며 리뷰를 마치겠습니다.

     


     
     


     

     
    posted by Lonewolf dlbo

    댓글을 달아 주세요

    2010.04.29 21:22 (비정기) Dlbo's Post

    아앍.

    미칠꺼 같아요 정신없어서 ㄱ-

    ---------------------------------------------------------------------------------------------------------------

    각 MFT에 대해 정보를 알려면 이 MFT의 헤더를 읽어야 합니다.

    그리고 이 MFT의 헤더에 속성들이 들어가있지요.

    ..............


    ...............

    MFT 헤더가 아니고 MFT의 엔트리에 들어있습니다 -_-;

    낚이는 분 있을까봐;

    MFT는 MFT Entry Header 부분과 빈 공간으로 나뉘고,

    빈 공간에 속성이 들어가서 이 MFT의 성격을 결정해 줍니다.

    이 속성에 파일의 데이터, MFT의 성격 등이 모두 들어가 있는 것이지요.

    이 속성에 대한 접근은 속성으로 접근합니다.(?)

    MFT의 상세 속성을 알아볼까요?

    차례로 번호, 이름, 역할을 기재합니다.

     속성 번호  이름  역할
     16  $STANDARD_INFORMATION  마지막 접근시간, 생성시간 등의 파일에 대한 기초적인 정보를 저장
     32  $ATTRIBUTE_LIST  속성들의 리스트 저장. 속성들에 대한 접근시 사용.
     48  $FILE_NAME  파일의 이름을 저장.
     64  $VOLUME_VERSION  볼륨에 대한 정보.
     80  $OBJECT_id  16바이트 파일이나 디렉터리에 대한 값.
     96  $SECURITY_DESCRIPTOR  파일 접근 제어/보안 제어
     96  $VOLUME_NAME  볼륨의 이름
     112  $VOLUME_INFORMATION  볼륨의 정보
     128  $DATA  파일의 내용
     144  $INDEX_ROOT  인덱스 트리의 루트에 관한 정보
     160  $INDEX_ALLOCATION  인덱스 트리의 내용 노드들
     176  $BITMAP  할당 정보 관리. 비트맵 그림 아님!
     192  $SYMBOLIC_LINK  SOFT LINK 정보이나, 건드릴 일이 없음.
     192  $REPARSE_POINT  위의 속성 관련임. 역시 건드릴 일 없음.
     208  $EA_INFORMATION  OS/2와의 호환용
     224  $EA  위와 동일
     256  $LOGGED_UTILITY_STREAM  NT스테이션 2000 이후의 버젼에서 속성 암호화와 관련된 키값.

    $ATTRIBUTE_LIST 속성이 속성들에 대해 접근하는 방법을 제시해 줍니다.

    그래서 속성에 대한 접근은 속성으로 한다는 오묘한 말을 했지요.

    -_-;

    여기서, MFT 내용의 구성은 아래와 같이 이루어져서, MFT가 최종 완성이 됩니다.

    MFT Entry header - 속성 Header - 속성 내용 - 속성 Header - 속성 내용 - 0xFFFFFFFF

    0xFFFFFFFF는 이 엔트리가 끝난다는 End Marker이고, MFT 엔트리의 지정 크기를 넘어설 경우는 마지막 부분에 자동으로 위치하며,

    채워야 하나 기록하지 못한 속성값은 다른 MFT 엔트리에 기록합니다.

    또한, MFT 속성은 2개 꼴랑 있는것으로 끝나는 것이 아니며, 원하는 만큼 기록이 가능합니다.

    MFT 엔트리가 MFT Entry Header/MFT Content로 구성되고,

    MFT Content가 여러개의 속성으로 구성되며,

    속성은 속성 Header/속성 Content로 구성된다고 보면 됩니다.

    -------------------------------------------------------------------------------------------------------------------

    끝내 MFT에 대해 다 얘기하긴 했지만, 코드는 안짜보고 넘어가네요;

    그림도 없고, 뭔가 내용도 대충 휘갈긴것 같고;

    일단 파일시스템에 관한 내용은 여기서 끝내도록 하고, 앞으로 비정기적으로 안드로이드 개발중인 것으로 종종 때우겠습니다;

    posted by Lonewolf dlbo

    댓글을 달아 주세요

    2010.04.14 23:13 (비정기) Dlbo's Post

    아앍

    이미 포스트가 올라와 있어야 하는데

    갑작스런 사정으로 좀 늦었습니다;

    예상하기에 3번에 걸쳐서 올린 후, 안드로이드 프로그래밍에 대해 올리지 싶습니다.

    ---------------------------------------------------------------------------------------------------------------

    MFT에는 메타 데이터 파일 외에 일반 파일을 위한 MFT 엔트리들이 연결되어 있습니다.

    부트 레코드에서 MFT 시작 엔트리의 클러스터 번호를 담고 있고, 이 내용을 통해 MFT 엔트리 0번에 접근하지요.

    여기 MFT 엔트리 0번부터 파일들의 연결 체인이 시작되며, 이 부분부터는 FAT의 엔트리 체인과 상당히 흡사하다고

    볼 수 있습니다.

    가령 예를 들면, MFT 엔트리 0번에는 몇번 클러스터와 몇번 클러스터에 이 엔트리의 내용이 연결, 확장된

    엔트리들이 있다고 표기되어 있지요.

    MFT 0번 엔트리를 읽어 MFT 전체의 레이아웃을 읽어들여 파일시스템을 이용한다고 보면 됩니다.

    (참고로 $MFT 메타 데이터 파일은 0번 MFT 엔트리에 언.제.나 존재합니다.)

    여기서, 그렇다면, 한 개의 MFT 엔트리로 담을 수 없는 큰 파일의 경우는 어떻게 기록할까요?

    FAT 체인과 비슷하다고 했지 않습니까?

    약간 다릅니다.

    MFT 엔트리는 Non based MFT와 Based MFT, 두 가지로 나눌 수 있습니다.

    "이런 파일이 존재한다!" 라고 표현하는 Based MFT와, "저 파일의 내용은 이거다!" 라고 표현하는 Non based MFT로 나뉘지요.

    물론 소규모 파일의 경우 1개 MFT 엔트리로 표현 가능하다면 Based MFT만 사용해 표현이 가능하니 상관이 없습니다.

    하지만 Non based MFT까지 확장해야 하는 경우는, MFT 엔트리 내의 File Reference to Base MFT Entry 필드에

    Based MFT 엔트리의 경우 0을, Non based MFT의 경우 Based MFT 엔트리의 파일 레퍼런스 주소를 담게 됩니다.

    이를 통해 트리형의 구조로 Based MFT에 Non based MFT 여러개가 주렁주렁 달리는 형태가 되지요.

    덕분에 파일 탐색시 Based MFT만 조사하면 되어 기존 FAT의 체인을 타고 조사하는 것보다 더 빠르게 검색이 가능하고

    한 파일에 대해 내용을 읽을 경우 파일 레퍼런스 주소에 대한 다른 처리를 이용해 훨씬 빠른 로드를 보여 줄 수 있습니다.

    (그래봤자 하드디스크가 느리다는건 별 수 없습니다 -_-;;;)

    여기서, 파일 레퍼런스 주소(File Reference Address)는 16비트의 시퀀스 밸류와 48비트의 MFT 엔트리 주소로 구성됩니다.

    Sequence value 16비트를 추가해서 레퍼런스 주소를 할당하는 이유는 단순합니다.

    이 값은 MFT 엔트리의 할당, 링크 상황이 변화할 때마다 증가하도록 설계가 되어 있으며,

    이 값을 이용해 MFT 엔트리의 검색 속도를 향상시킵니다.

    왠만해서는 이 Seq 값이 같기 힘들기 때문에(뭐... 만들려면 만들 수는 있습니다.) 이 값을 이용해 이 데이터에 접근하려는

    다른 데이터가 서로 매치되는지를 확인합니다.

    Seq값이 다르다면, 생성 시기나 할당 상황, 변동 사항이 다르기 때문에 매치가 되지 않고, 찾는 자료가 아니라는 의미가 되어

    그냥 다음 탐색으로 제껴버릴 수 있는 것이지요.

    순수하게 MFT 엔트리 주소만으로 찾을 경우 주소만 잘못 알고 접근한 경우에 대해 선 조치를 취해준다고 볼 수 있습니다.

    --------------------------------------------------------------------------------------------------------------

    감기조심하세요

    -_-;

    죽을꺼같아요
    posted by Lonewolf dlbo

    댓글을 달아 주세요

    2010.04.05 21:49 (비정기) Dlbo's Post

    계속 연기만 반복되는거 같아 죄송합니다;

    사유를 대자면, 공익 근무 땜빵 + 갑작스러운 후임 신규자 교관 + 알바 로 인해 오늘 아침에 퇴근했습니다.

    -_-;;

    몸살도 지금 쩔게 제대로 걸렸구요;

    최대한 다음주 수요일 안에 포스트 준비해서 올리겠습니다;
    posted by Lonewolf dlbo

    댓글을 달아 주세요

    2010.03.27 20:12 (비정기) Dlbo's Post

    원래 일요일 포스팅 예정이었습니다만,

    공익 정신이상 후임 녀석때문에 일요일 땜빵 뛰게 되어서 상당히 좀 부실합니다;

    ---------------------------------------------------------------------------------------------------------------

    MFT란 Master File Table의 약자로, FAT의 파일 엔트리와 비슷한 개념입니다.

    다만, NTFS에서는 루트 디렉토리 등의 엔트리에 관한 내용이 없으며, B+ 트리 알고리즘 등으로 인해

    엔트리 검색 형태 등에서 차이가 납니다.

    훨씬 개선된 검색속도를 가지며, 클러스터의 크기가 64비트로 월등히 크다는 점을 감안할때 상당히 유용하지요.

    엔트리의 대체물로 볼 수 있기 때문에 이 MFT에도 번호가 존재하며, 0~15번의 16개 MFT에 대해서는

    이미 예약된 형태가 존재합니다.

    이를 메타 데이터 파일(Meta Data File)이라고 부르며, 아래 리스트와 같습니다.

    1. $MFT                           MFT를 담고 있는 메타 데이터 파일
    2. $MFTMirr                     FAT엔트리가 비상용으로 2개 이상인것과 같음. 파일 손상시 대체할 미러
    3. $LogFile                       트랜잭션 저널로 파일 변화의 기록
    4. $Volume                      볼륨의 레이블, 버전 등의 정보를 가진 파일
    5. $AttrDef                        인자, 이름, 크기등 여러 속성을 가진 파일
    6. .                                  FAT의 루트 디렉터리. 아무리 잘난 NTFS라지만 있는게 유리함.
    7. $Bitmap                       파일시스템의 클러스터 할당 정보, 그림파일 아님.
    8. $Boot                           부트영역 정보
    9. $BadClus                     배드클러스터 정보
    10. $Secure                       파일 보안, 접근 권한 제어
    11. $Upcase                      모든 유니코드 대문자 저장... 왜지?
    12. $Extend                       윈도우면 아무것도 없음. 파일시스템의 확장을 위한 영역
    13. ~15. 예약된 영역(사용하지 않음)

    이 외에도 16 ~ 24번까지 미래를 위해 임시로 비워둔 친구들이 있고,

    윈도 2000부터 추가된 4개의 MFT친구들이 있습니다.

    이 친구들은 일반 파일 영역에서 아무데나 자유롭게 배치되지요.

    이 메타 데이터 파일들은 하드디스크에 실존 데이터 파일로 존재합니다.

    간단히 말해서, FAT의 단점인 "엔트리영역은 언터쳐블"을 극복시킨 방법이 파일 시스템 내용의 전체 파일화 라는거지요.

    그래도 맥 파일 시스템처럼 파티션을 나누는 부분 빼고 전부 다 쓸 수 있는 수준은 아니지만요.
    (맥 파일 시스템은 부트코드가 롬바이오스에 붙어있답니다;;;)

    일반적으로 FAT에서는 데이터 영역의 최초 부분이 루트 디렉터리였으나, 이제 NTFS에서는 그런 구분 안해도 됩니다.

    루트 디렉터리 또한 일반 파일로 아무 곳에나 자리잡을 수 있으며, 저 메타 데이터 파일들도 어디든 자리잡을 수 있습니다.

    다만, 부트 레코드 영역에서 0번 MFT 엔트리의 위치만 정확하게 기록되어 있다면 말이지요.

    -------------------------------------------------------------------------------------------------------------------

    ;;; 일단 여러번에 걸쳐서 올리도록 하겠습니다;

    posted by Lonewolf dlbo

    댓글을 달아 주세요

    2010.03.21 21:07 (비정기) Dlbo's Post
    죄송합니다; 황사때문인지 감기가 더욱 심해져서 감기 몸살이 되어버렸습니다;

    MFT는 정리는 되어 있지만 아직 포스트로 띄울 수 있는 상태가 아니라서

    일단 1주 휴재하겠습니다;
    posted by Lonewolf dlbo

    댓글을 달아 주세요

    2010.03.15 19:40 (비정기) Dlbo's Post
    한영키가 또 안먹히는군요.... 우라질;

    아무래도 놋북 키보드를 갈아야 할 것 같습니다;

    ------------------------------------------------------------------------------------------------------------------

    NTFS는 New Technology File System이라는 길다란 풀네임을 가지고 있습니다.

    이는 FAT파일시스템이 체계를 잡아가던 서버용 윈도우즈, 윈도우즈NT 시절부터 태어나 자라왔지요.

    FAT의 막내격이자 가장 최신형인 FAT32는 FAT엔트리에서 한 엔트리당 크기가 32비트였던 것에 비해

    아예 윈도우즈 3.x버전이 돌던 시기의 최초형 윈도우즈 NT스테이션때부터 엔트리당 64비트의 크기를 가지고 시작했습니다.

    어찌 보면 지금을 기준으로 했을 때, 대단한 선견지명일 수 있지만...

    '서버용'인 윈도우즈 NT스테이션이었음을 생각해보면 그냥 그럭저럭 적당한 대처였다고 볼 수 있습니다.

    FAT 계열의 용량 한계는 아래와 같습니다.




    • FAT 16 - 이론상 한계 2GB, 파일의 최대 크기는 볼륨의 크기만큼, 클러스터 갯수는 65524개. 루트디렉터리에 파일 제한 있음, 디렉터리당 파일 65535개 제한.
    • FAT 32 - 이론상 한계 4TB(클러스터 크기 16KB로 설정시), 인식 한계 2TB, 윈도우즈 자체 제한 32GB, 파일의 최대 크기는 4GB. 유일하게 루트 디렉터리에 파일 개수 제한이 없음. 디렉터리당 파일 65535개.
    • VFAT - FAT16과 마찬가지.
    • FAT 12 - 16MB가 최대 크기, 클러스터 4084개 포함 가능, 파일 최대 크기는 볼륨 크기만큼, 디렉터리당 파일 개수 제한 없으나, 루트디렉터리에는 제한이 있음.


    대충 보기에 NTFS는 용량 제한도 없고 하기 때문에 훨씬 좋아 보입니다.

    윈도우즈 기준의 파일시스템별 클러스터 크기를 볼까요?

     볼륨 크기 FAT16 FAT32  NTFS 
     16 - 32MB  512B X 512B
     32 - 64MB 1KB 512B  512B
    64 - 128MB  2KB 1KB 512B
     128 - 256MB  4KB  2KB  512B
     256 - 512MB  8KB  4KB  512B
     512MB - 1GB  16KB 4KB  1KB
     1 - 2GB  32KB  4KB  2KB
     2 - 4GB  64KB  4KB  4KB
     4 - 8GB  안돼 너무 커  4KB  4KB
     8 - 16GB  지원 못...  8KB  4KB
     16 - 32GB 지원 안함   16KB  4KB
     32 GB - 2TB  지원 못함(?)  인식은 가능  4KB



    쩝...

    사실 FAT16으로 1기가 넘기는게 참 독특한 짓이긴 합니다만;

    4기가까진 읽을 수 있겠군요.

    반면, 용량에 따라 클러스터 크기가 점차 늘어나는 16과 32에 비해 NTFS는 증가폭이 거의 눈에 안보입니다.

    처음부터 NTFS는 고용량 하드디스크를 고려해 설계했다는 이야기가 되지요.

    서버용이니깐 -_-;

    -------------------------------------------------------------------------------------------------------------------

    다음번엔 MFT에 대해 개략적으로 언급하고, 파일시스템 포스트를 마치려고 합니다.

    리눅스나 유닉스 파일 시스템을 다루지 못했지만, 의외로 그림을 많이 그려야 하더라구요;

    생각보다 답답해서 일단 제껴두고, 현재 자격증 시험을 준비하려 하는 리눅스 관련 포스트를 시작해볼까 합니다.

    뭐... 일단 다음주에 포스트를 써 봐야 알꺼 같지만요 -_-;

    posted by Lonewolf dlbo

    댓글을 달아 주세요

    1. 그림이 없어서 겉핥기로 보이는 건 그렇다 쳐도 ext2마저 관두시나요 ㅜㅠ

      • Favicon of http://dlbo.tistory.com BlogIcon Lonewolf dlbo 2010.03.21 21:05  Addr Edit/Del

        죄송합니다 -_-; 지금 건강상황도 상당히 좋지 못하고 자리는 잡아서 시간을 만들긴 했는데 아직 넉넉하지가 않아요; 무리해서 일정을 끌어와서 하다 보니; 완전 정상화는 좀 힘들것 같아요;

    2010.03.13 21:36 (비정기) Dlbo's Post

    시간상의 문제로 이르면 일요일, 늦으면 화요일 오후까지 포스트 올라갑니다.

    -_-;
    posted by Lonewolf dlbo

    댓글을 달아 주세요

    2010.03.07 19:03 (비정기) Dlbo's Post

    FAT 엔트리에 관한 저번 내용을 보셨다면, 문득 궁금한 내용이 생기시지 않았을까 합니다.

    "디렉터리는?"

    하는 의문 말이지요.

    -_-; 뭔가 글씨가 안맞네요.

    FAT 시스템에서는 디렉터리나 파일이나 동일한 구조를 갖습니다.


    1. Name 필드 - 최초 8바이트의 필드로, 이 엔트리가 지시하고 있는 파일의 이름을 가지고 있는 필드입니다. 8바이트중 텅 빈 부분은 공백문자(20h)로 메꿔넣어야 하며, 0h로 채워넣게 되면 대략 낭패.
    2. Extender 필드 - 이름에서도 느껴지듯, 확장자가 들어가는 필드입니다. 3글자만 가능하며, 3바이트로 구성, 디렉터리인 경우는 빈칸으로 둡니다.
    3. Attrivute 필드 - 01부터 02, 04, 08, 10, 20, F0의 값을 가지고 있는 1바이트 필드이며, 이게 어떤 파일인지를 표시해 줍니다. 보통 01이면 읽기 전ㅇㅇ, 02이면 숨긴 파일, 04이면 시스템, 08이면 이 자체로 하-_-드디스크가 되며;;; 10이면 디렉터리임을, 20이면 그냥 파일임을, F0이면 FAT32부터 사용가능한 긴 파일명을 지원하기 위한 엔트리임을 표현합니다.
    4. NT 리소스 필드 - 냅두세요. 0으로 채워둬야 합니다. 윈도가 지멋대로 메꿔요 -_-. 1바이트 크기이구요.
    5. CTT 필드 - Create Time Tenth라는 요상한 이름의 필드입니다. '만들어진 시간 10번째'라는 요상한 의미가 아닙니다; 파일 생성 시간을 10분의 1 단위로 기록해둔 내용입니다. 1바이트 크깁니다.
    6. CT 필드 - Create Time이라는 이름의 필드로, 2바이트 공간을 차지합니다. 5비트로 초, 6비트로 분, 나머지 5비트로 시간을 표시합니다.
    7. CD 필드 - Create Date라는 필드로, 생성된 시날짜, 월, 연도를 표기하는 2바이트 필드입니다. 날, 월, 년 순으로 5, 4, 7비트를 차지합니다.
    8. LAD 필드 - Last Access Date 필드로 마지막으로 건드린 날짜를 기록하는 2바이트 필드입니다.
    9. First Cluster High 2B - 첫번째 클러스터 번호의 상위 2바이트를 답고 있는 2바이트 필드입니다만, FAT16이라면 클러스터 크기가 2바이트인지라 0이 표기됩니다. FAT 32라면 여기에 상위 2바이트가 표기되겠지요?
    10. Write Time - 가장 최근에 이 파일을 수정한 시간으로, 파일 생성도 쓰기로 간주합니다. 2바이트 필드입니다.
    11. Write Date - 다른 말이 필요 없겠지요? 날짜입니다.
    12. First Cluster Low 2B - 아까 9번 친구 뒤에 이어지는 2바이트 클러스터 번호입니다. FAT16이라면 이 친구만 실제 값을 가집니다.
    13. File Size - 바이러스 만들어본 분들은 종종 건드려 봤을겁니다. 4바이트 필드로, 파일의 사이즈를 표현합니다. 최대 4기가를 넘을 수 없으며, 디렉터리로 체크되어 있다면 이 필드는 0이 되어야 합니다. 용량이 있는 디렉터리가 있으면 그건 마치 자-_-웅동체 같지 않아요?

    이전 포스트에서 보았던 파일 클러스터 체인의 내용은 사실 12번 내용만 표기한 겁니다.

    루트 디렉터리니 일반 디렉터리니 파일이니 전부 저거만 봤던 거였지요. ㅡ_ㅡ

    근데 잘 살펴 보면, 어찌 됐건 별 차이 없지 않나요? -_-ㅋㅋㅋ



    posted by Lonewolf dlbo

    댓글을 달아 주세요

    2010.02.28 20:30 (비정기) Dlbo's Post
    포스트가 쪼까 늦었네요; 아마 다음 포스트는 대략 금요일이나 토요일즈음 올라가지 싶습니다.

    ------------------------------------------------------------------------------------------------------------------

    FAT12와 FAT16은 FAT엔트리가 각각 12, 16비트로 구성된 파일시스템입니다.

    12비트로 구성된 FAT12는 주로 용량이 적은 플로피디스켓에, 16비트로 구성된 FAT16은 윈도95, 98시절 사용하던 소용량의

    하드디스크에 쓰이던 파일 시스템이지요.

    두 시스템이 공통적으로 갖는 부분은 "최초 1섹터인 512바이트가 부트 코드 블록" 이라는 겁니다.(사실 FAT계열은 다 이래요;)

    이 부분은 BPB(Bios Parameter Block)으로도 불리우며, 이 자리에 어떤 OS를 메모리에 올릴 지, 부팅시 어떤 동작을 할 지가

    쓰이게 됩니다.

    최초 1섹터 BPB에 기록된 내용을 FAT16을 기준으로 보자면 아래와 같은 내용이 됩니다.

    1. 0~2비트 : 점프 부트 코드 - OS가 있다면 OS의 시작코드로 점프하라는 의미의 명령어가 자리잡고 있습니다.
    2. 3~10비트 : OEMName - OS, 혹은 하드디스크의 이름이 기입되는 부분입니다.
    3. 11~12비트 : 섹터의 크기 - 1개 섹터에 몇 바이트가 들어가는지를 의미하며, 일반적으로 512를 기입합니다. 윈도우에 인식되려면 512를 기입하며, 1024, 2048, 4096까지 기입 가능합니다.
    4. 13비트 : 클러스터의 크기 - 1개 클러스터에 몇개의 섹터가 들어가느냐를 표기합니다. 일반적으로 32를 넣으며, 2의 배수를 넣어야 합니다.
    5. 14~15비트 : 예약된 섹터의 개수 - FAT엔트리가 나오기 전 까지 일정 부분은 0으로 초기화 되어 있어야 함을 의미합니다.
    6. 16비트 : FAT엔트리의 개수 - FAT엔트리 집합은 2개 이상이어야 엔트리 부분이 고장나더라도 다른 사본을 이용해 간접 접근이 가능합니다. 보통 2의 값을 넣습니다.
    7. 17~18비트 : 루트 디렉터리의 크기 - FAT12, 16은 이 영역에 설정한 만큼만 루트 디렉터리에 저장이 가능합니다. FAT32 이후로는 이 영역이 0이 되어야 하며, 보통 FAT16의 경우는 512를 기록합니다.

    FAT시리즈 파일시스템의 공통된 부분은 여기까지입니다.

    이후의 FAT 영역(FAT 엔트리 집합)은 FAT 엔트리와 클러스터 크기, 하드디스크의 용량에 의해 크기가 결정되며, 이를 BPB에서 설정하지요.

    FAT영역이 끝나는 순간부터가 실질적으로 하드디스크에서 쓸 수 있는 용량부분이라고 보면 됩니다.

    파일의 이름이나 용량 등에 관한 정보는 모두 FAT엔트리에 보관되며, 하드디스크의 실제 쓸 수 있는 클러스터 영역에는 파일의

    실제 내용만 기입되고, FAT 엔트리의 내용에 따라 OS나 프로그램이 파일을 읽어들이게 되지요.

    저번 포스트나 이 포스트의 초반부에 말했듯, FAT12는 이 엔트리가 12비트로, FAT16은 16비트로 설정되어 있습니다.

    특별한점은, FAT12의 경우 이도저도 아닌 애매한 12비트로 되어 있기 때문에 3바이트(24비트)단위로 읽어들여서 2개 엔트리로

    파싱해 사용해야 한다는 점이 있습니다.

    FAT16의 경우는 2바이트로 바로 불러들여서 1개 단위로 처리가 가능하지요.

    이러한 FAT 엔트리들은....

    참 신기하게도 2번부터 시작합니다. -_-

    0번 엔트리의 위치에 Media Type, 즉 "이게 뭔 종류느냐"를 표기하고, 1번 엔트리에는 파티션 타입을 담는 내용이 들어옵니다.

    이후 2번 엔트리가 실질적 하드디스크의 첫 위치를 표기하게 되지요. 일반적으로 2번 엔트리가 하드디스크의 루트 디렉터리를 가르키게 됩니다.

    참고

    위 링크를 타고 가면 엔트리에 들어가는 내용중, 여러 클러스터에 걸치게 되는 파일은 엔트리에 나온 다음 클러스터 번호를 타고

    이동하며 체크한다는 내용이 있습니다.

    FAT16 기준 0x0000이 들어가 있다면 빈 클러스터, 0x0001, 0xFFF0~0xFFF6이 들어있다면 예약된 클러스터이며

    0x0002~ 0xEEEF라면 다음 엔트리에 연결된 클러스터 번호를 의미합니다.

    0xFFF7은 불량 클러스터를 의미하며, 배드 섹터가 위치한 클러스터입니다.

    0xFFF8 이후의 값은 EoC(End of Cluster)로, 이 파일의 끝이 이 클러스터에 존재한다는 의미입니다.

    이런 시스템 형태로 인해 FAT의 경우 1 클러스터의 512 바이트중 1바이트짜리 파일이라면 어쩔 수 없이 512바이트를 사용하게

    되어 있지요.

    엔트리 부분은 이러하게 생겼답니다.

    -------------------------------------------------------------------------------------------------------------------

    뭔가 여전히 허술하다는 느낌을 지울 수가 없네요.

    -_-;

    다음번엔 FAT 영역이 끝난 직후인 데이터 영역에서 데이터를 찾는 방법과 FAT 엔트리의 상세 내용을 쓰도록 하겠습니다.
    posted by Lonewolf dlbo

    댓글을 달아 주세요

    1. Favicon of http://anster.egloos.com/ BlogIcon 복군 2010.03.22 15:35  Addr Edit/Del Reply

      음 저 bit가 아니라 본문중에 byte 아닌가요 ^^;?

    2010.02.16 19:24 (비정기) Dlbo's Post
    오래간만에 다시 연재하는 포스트이군요.

    대략 3월부터는 월화수목금만 근무하게 되어 있으니

    3월부터는 다시 연재가 제대로 이루어지지 싶습니다.

    ------------------------------------------------------------------------------------------------------------------

    애초에 하드디스크건 무엇이건, 용량은 정해져있고, 0번지부터 max번지까지(물론 하드디스크의 맨 뒤 입니다) 쓸 수 있습니다.

    마치 램을 쓰는것처럼 하드디스크도 그렇게 쓰인다는 것이지요. 이 번지 하나하나에 파일을 쑤셔넣고 배치하면, 그게 바로

    파일시스템이 되는 것이지요.

    그런데, 애초에 파일을 그냥 마구잡이로 하드디스크에 쑤셔넣는다면?

    가뜩이나 느려 터진 하드디스크를 0번지부터 끝까지 하나하나 선형탐색으로 뒤져봐야 합니다.

    그렇다고 이걸 정렬시켜 버리면 -_-

    하드디스크 내의 모든 자료들이 서로 한데 섞여버려서 개판 5분'후'가 되겠지요.

    이 때, 테이블을 사용해 하드디스크의 선두번지들을 파일을 관리하는 시스템으로 두는 것이 FAT파일시스템입니다.

    File Allocation Table이라는 풀 네임이 이 테이블을 지칭하는 것이구요.

    이해를 위한 개략적인 설명.

    대략적으로 아래와 같은 모습을 볼 수 있습니다.



    1번 테이블의 요소는 1번 클러스터를 가르키고 있고, 이 말인 즉슨, 1번 실제 저장 장소에 데이터가 있다는 얘기입니다.

    2번 테이블의 요소는 3번 클러스터를, 3번 테이블의 요소는 2번 클러스터를 가르키고 있다는 겁니다.

    실제로는, 테이블의 한 칸 한 칸마다 파일의 이름과, 해당 파일의 내용이 몇번 클러스터에 있는가가 기술되어 있습니다.

    클러스터란, 데이터를 관리하기 편하도록 나눠둔 하나의 단위이고, 엔트리란, 파일의 기초적 정보를 저장하는 내용입니다.

    실질적으로는, 아래와 같은 모양이 나오겠지요.


    4개의 클러스터에 걸친 파일이 저런 모양새를 가진다는 겁니다.

    그리고 보통의 FAT시스템이라면 1번 클러스터는 루트 디렉터리를 의미하지요.

    1번 엔트리는 2번 엔트리를, 2번 엔트리는 4번 엔트리를, 4번은 6, 6번에서는 EOC(End Of Cluster)값이 들어가 있어

    실질적으로 1번, 2번, 4번, 6번 클러스터에 데이터가 들어가 있다는 의미입니다.

    FAT 파일시스템에서는 이런 방법을 이용해 파일을 관리하며, 이 엔트리의 용량이 12비트이면 FAT12, 16비트는

    FAT16, 32비트는 FAT32라 부릅니다.

    안타깝게도 FAT64는 만들면 있겠지만, 현존하지는 않으며, NTFS라는 새로운 시스템이 대체합니다.

    [각주:1]참고로, NTFS는 호환을 위해 FAT와 기본적인 형태만 비슷하게 두었을 뿐, 전혀 다른 형태를 가집니다.

    1번 섹터부터 마지막 섹터까지중 1섹터는 부트 레코드로 두는 점에서 FAT나 모든 파일시스템이 동일하고,

    2번섹터부터 시작하는 2개의 FAT 엔트리(엔트리가 있는 물리공간의 고장을 대비해 최소 2개를 준비합니다.)가 있고,

    그 후에 실제 데이터 영역이 존재하는 것이지요.

    -------------------------------------------------------------------------------------------------------------------

    뭔가 좀 많이 부족하네요.

    다음번엔 FAT12, 16을 가지고 다시 돌아오겠습니다.
    posted by Lonewolf dlbo

    댓글을 달아 주세요

    2009.06.23 22:11 (비정기) Dlbo's Post
    으흠...

    한동안 파일시스템에 대해 휘갈겨 볼까 합니다.

    FAT12부터 시작해서, FAT16과 FAT32, NTFS, Ext에 대해 대략적으로 써 볼 생각입니다.

    FAT는 마이크로소프트의 윈도우즈를 위한 파일 시스템 시리즈이고,

    File Allocation Table의 약자라나 뭐라나...

    그리고 NTFS는 New Technology File System의 약자라고 하는군요.

    NTFS는 윈도우즈 NT계열의 1.0버젼부터 시작해서 FAT와 함께 커왔지만,

    FAT와는 다르게 애초에 큰 용량의 하드디스크를 타겟으로 한 파일시스템입니다.

    그리고 Ext파일시스템은 리눅스의 파일시스템으로, Ext2 파일시스템은 유닉스의 UFS를 기반으로

    만들어진 파일시스템이라고 합니다.

    ---------------------------------------------------------------------------------------

    저장장치를 쓰는데 그냥 파일들 우겨넣으면 될 것을 어째서 굳이 파일시스템별로 나누고 쪼개고 해서

    귀찮게 하느냐... 하실지도 모르겠지만,

    의외로 파일시스템을 구축함으로서 파일 탐색을 비롯한 여러 부분에서 어드밴테이지가 있답니다.

    다음 포스트에서는 FAT의 전체 개요와 FAT계열의 부트섹터에 대해서 들고 오도록 하겠습니다 ㅁ_ㅁ!
    posted by Lonewolf dlbo

    댓글을 달아 주세요

    1. Favicon of http://klone.tistory.com BlogIcon Mr.K 2010.02.17 01:52  Addr Edit/Del Reply

      zz

      이걸 못봤는데 왜 2편이 올라왔지 싶었는데

      이게 올라온지 반년이 지났네 -_-;

    2009.06.16 15:07 (비정기) Dlbo's Post
    사용자 삽입 이미지

    WoC 2008에서 CCL의 윤종수 판사님의 말씀이었지요.

    "개발자는 예술가다.
    프로그램은 개발자의 예술이다."

    라고.

    그렇심다!

    프로그래머는 코드를 통해 세상과 소통합니다.

    개발자의 프로그램은 프로그래머의 내적 세계를 표현하고, 그 사람의 철학을 담고 있습니다.

    읽기 힘든 코드나 읽기 쉬운 코드나,

    더 빠른 코드나 더 느린 코드나,

    호환이 되는 코드나 종속적인 코드나 모두 코더의 필요에 의해서

    유저와, 컴퓨터와, 혹은 개발자가 의도한 상대에게 개발자의 의미를 전달하는 매개체입니다.

    사용자 삽입 이미지
    프로그래밍은 또한 "표현" 입니다.

    아까 쓴 것처럼,

    컴퓨터나, 특정 대상에게 의미를 "표현"하는 수단인 것이지요.

    그리고 그 자체로 목적이 됩니다.

    개발자의 표현은 코드로, 프로그램으로 나타납니다.

    남들이 말로, 기획서로, 이상으로 표현하는 바를

    프로그래머는 코딩, 개발을 통해 프로그램으로 현실화 시켜버리지요.

    프로그래머는 코드로서 자신을, 자신의 의미를, 세상을 표현합니다.

    사용자 삽입 이미지
    프로그래머는 스스로의 세계를 만들어 나갑니다.

    우리가 살고 있는 현실 외에도,

    스스로 가상공간을 만들어 나갑니다.

    스스로 만든 규칙과 행동, 패턴을 기반으로 자신이 꿈꾸는 이상향을 직접 만들어 냅니다.

    프로그래머는 컴퓨터와 함께하는 동안, 자신만의 공간에 있어서는 "신"입니다.

    사용자 삽입 이미지
    프로그래머의 코드는 코더의 지식수준과 성격, 가치관, 철학을 담고 있습니다.

    스스로의 자아가 담겨있는, 자신만의 모든 것을 표현하는 하얀 종이가 바로 모니터이고, 소스코드입니다.

    자신만의 자유에 맞게 코딩하고, 자신의 프로그램에 생긴 버그에 대해 스스로가 책임지며 나아갑니다.

    자신만의 자유가 담긴 코드에 대해 남에게 명확하지 못한, 혹은 주관적인 비판을 받는다면

    해당 코더, 프로그래머들은 화를 냅니다.

    남의 자유에 침해하지 않는, 자신의 자유에 침해받지 않는, 그러면서도 조화를 이룰 수 있는,

    프로그래밍은 그런 세계입니다.

    사용자 삽입 이미지
    팀 작업에서조차 서로의 각자 담당에 있어서는

    스스로의 자유가 보장되는 곳,

    서로 미리 만든 기본적인 약속만 지킨다면 자신의 자유는 무한정한 곳.

    그런 무릉도원, 유토피아가 프로그래머가 살고 있는 세상이라고 생각합니다.

    (야근 빼고 -_-)

    -------------------------------------------------------------------------------------------

    뭔가 심하게 거저먹는듯한 기분이 드네 =_=;
    posted by Lonewolf dlbo

    댓글을 달아 주세요

    1. 예술은 참 힘들죠. 제 코드도 언젠가는 인정받을거에요.
      제발 ㅎㅎ, 못받으려나??

    2. 어떤 코드라도 모두 존중받을 가치가 있습니다 (x2)

    2009.06.09 22:24 (비정기) Dlbo's Post
    ---------------------------------------------------------------------------------

    사유 : 일정관리 실패 -_-;

    연기일자 : 6. 9. 화.

    예상 복귀 일자 : 6. 16 화.

    ---------------------------------------------------------------------------------

    ...

    -_-;;

    이번주 한주만 쉬겠습니다 -_-;
    posted by Lonewolf dlbo

    댓글을 달아 주세요

    2009.06.02 14:58 (비정기) Dlbo's Post
    아...

    비가 쩔어주게 오네요.

    책 제본뜨러 가야 하는데;;

    ----------------------------------------------------------------------------------------

    요즘은 컴퓨터가 워낙에 빨라져서 코드 최적화에 대해 대학이나 여타 여러곳에서 잘 언급을

    하지 않는 것 같습니다. 그래도 KOI 준비하는 학생분들은 시간적 옵티마이즈에 목숨을 걸지요 =ㅁ=

    최대한 빠르게 동작해야 하니까요.

    예전의 느린 컴퓨터에서는 시간을 줄이기 위한 최적화가 종종 이루어 졌습니다.

    물론 요즘도 실행시간을 줄이기 위한 시도(암호깨기...)가 종종 이루어 지지만 말이지요.

    사용자 삽입 이미지

    추...추억의 286입니다 -_-;

    저때만 해도 느린 컴퓨터 덕분에 시간 차원의 옵티마이즈가 필요했습니다.

    http://retirno.pe.kr/117?srchid=BR1http%3A%2F%2Fretirno.pe.kr%2F117

    소수판별법의 기본형입니다.

    n의 데이터에 대해 최악의 경우 a의 시간이 걸리지요 -_-;

    http://tblog.javaf.net/541?srchid=BR1http%3A%2F%2Ftblog.javaf.net%2F541

    이건 소수판별법의 소규모 변형입니다.

    합성수의 약수들이 루트n을 기준으로 좌우대칭형으로 존재하기 때문에

    루트n까지만 조사하면 된다는 특성을 이용한 변형 알고리즘이지요.

    그래도 필요한 시간복잡도는 루트n입니다.

    http://dlbo.tistory.com/305

    밀러-라빈 소수판별법이라는 확률론적인 소수판정법입니다.

    n에 대해 k회의 소수판정을 실시했을때, n의 소수판정이 틀릴 확률은 2의 k승입니다.

    n의 크기에 따라 (약 20 정도) 일반 소수판별보다 느릴 수 있으나,

    수가 커지면 커질수록 매우 빠른 속도효율을 얻게 되지요.

    사용자 삽입 이미지

    대략 요런 느낌이랄까 =ㅁ=

    이런 방식을 알고리즘 측면의 속도 옵티마이즈라 합니다.

    그런데 코드가 난잡해져 읽기 힘들어지면,

    아무래도 직장 상사한테 싸다구를

    사용자 삽입 이미지

    요걸로 후려맞겠죠 -_-;;

    대표적인 예시를 보지요.

    http://dlbo.tistory.com/196

    트리 서밍 문제의 일반적인 해답 코드입니다.

    그리고...



    전설의 숏코더 cozy ozy(ozy4dm)의 gcc 코드입니다. -_-;;

    이런 것을 맹목적인 속도 옵티마이즈라고 합니다.

    알고리즘 차원에서도 옵티마이즈를 했으나,

    코드의 가동속도를 최대한 끌어올리기 위해 온갖 변태짓을 해 실행해야 할 기계어 코드를

    최대한 대폭 줄여버리는 것이지요.

    아, 물론 이방법도 기계어코드를 직접 터치해버리는 방식에는 미치지 못하긴 합니다 =ㅁ=

    그래도.

    이렇게 했다간 상사한테 후들겨 맞기 좋답니다 -_-;

    또 다른 최적화로써 메모리 공간의 옵티마이즈 방식이 있습니다.

    http://zfanta.com/entry/for문-10000번-VS-노가다-타이핑-10000번

    ㅋㅋㅋㅋㅋㅋ 환타님의 포스트입니다.

    파일 크기의 문제도 발생하지만,

    문제는 저 파일 내용을 고.대.로 메모리에 로드한다는것도 문제입니다.

    이 경우는 컴파일러가 멍청(?)해서 생긴 경우지만,

    좀 복잡한 코드가 될 경우 프로그래머가 직접 구조를 변경해 사용할 메모리를 줄여주어야 하지요.

    메모리 사용량은 곧 전력소모와도 연결되기 때문에,

    요즘 유행하는 임베디드 시스템에서의 '저전력' 설계와도 연관되게 됩니다.

    한번에 최대한 적은 데이터가 이동하면서 모든 일을 처리해야 하는 형태이지요.

    사용자 삽입 이미지

    아무리 아이폰이 잘났어도 10초만에 꺼지면 눈물나겠지요? -_-;;

    그렇다고 해서

    사용자 삽입 이미지

    요러시면 안됩니다 =ㅁ=;;

    ------------------------------------------------------------------------------------------------

    크흠. 뭔가 글이 상당히 산만한거 같네요 ㄱ-
    posted by Lonewolf dlbo

    댓글을 달아 주세요

    1. 저어기.. '삼성' 하나 남아 있습니다만. 누리시라는 말에...

    2. 배드링크
      http://zfanta.com/entry/for문-10000번-VS-노가다-타이핑-10000번
      제일 아끼는 글이에요 ㅋㅋ

      • Favicon of http://dlbo.tistory.com BlogIcon Lonewolf dlbo 2009.06.03 21:21  Addr Edit/Del

        -_-ㅋㅋ 링크 다시 수정했습니다. 그 때의 실시간 댓글이 아직 기억에 남아요 ㅋㅋ

    3. 비 잠깐 오고 말았지 거 참.

    4. -_-근데 저 야구 스크린샷은 뭐죠? 포수가 공을 떨어뜨렸는데 도루??

      • Favicon of http://studyinglw.tistory.com BlogIcon Reuent 2009.06.05 00:58  Addr Edit/Del

        백홈하고 있는 모습이네요.

        사진속 주인공은 한화 이글스의 김태균입니다.

    5. .... 저 아이폰은 제닉스 님의 미투데이를..

    2009.05.26 19:51 (비정기) Dlbo's Post
    프로그래밍 포스트 치고는 뭔가 오묘한 제목이지요?

    요즈음 이것저것 해보다가 갑자기 든 생각이라 포스트로 구성해 보았습니다.

    ------------------------------------------------------------------------------------------

    자유에는 책임이 따른다고 하지요?

    같은 밥솥으로...
    사용자 삽입 이미지

    .... 요런 밥을 탄생시킬 수도 있고,

    사용자 삽입 이미지

    요런 밥이 나올 수도 있습니다 -_-;

    밥 하는 사람의 책임에 따른 문제이지요.

    프로그래밍 또한 같습니다.

    프로그래밍의 자유도, 즉, 사용할 언어의 자유도에 따른 책임은 스스로 져야 한다는 것이지요.

    어셈블리언어의 어셈블러는 아주 기초적인 문법만 체크할 뿐, 데이터와 코드의 구분도 잘 안해줍니다.

    (MASM의 구분니모닉은 예외로 칩시다 =ㅁ=)

    이리 하여 프로그래머의 자유도를 거의 무한에 가깝게 보장해 주는 대신,

    엄.청.난 길이의 코드와 -_-

    한끗 삑날때마다 컴이 어디로 튈 지 모르는 위험-_-한 상황을 연출할 수 있지요.

    사용자 삽입 이미지

    .... 그런 면에서 이분은 나름 잘 버티고 있지요? -_-;

    반면, 자바와 C#을 봅시다.

    프로그래머의 편의는 엄청나게 제공합니다.

    객체지향적인 형태로 객체들을 조합하기만 하면 금방 쉽게 프로그램이 구성이 되지요.

    사소한 익셉션 조차도 try-catch와 내장 익셉션 기능을 이용해 처리가 가능하고,

    이런 문제가 발생하더라도 시스템에 무리가 가지 않는, 그야말로 프로그래머의 책임을 엄청나게 덜어주는

    사용자 삽입 이미지

    같은 친구이지요 -_-;

    이렇게 프로그래머의 책임과 수고를 덜어주는 대신,

    Java와 C#의 프로그래머의 자유도는

    사용자 삽입 이미지

    ...

    프로그래머의 수고를 덜어주기 위한 객체지향의 기본 원칙들이

    프로그래머의 자유를 제한하고 있습니다.

    분명히 Java와 C#은 디버깅이나 코딩에 있어서, 그 뿐만 아니라 프로그램의 개발 속도나 생산성,

    유지 비용 및 타 팀원과의 협동에는 매우 유리할 수 있으나,

    그로 인해 스스로의 발을 어느정도 묶어버리게 되어버린 다는 것이지요.

    자, 그럼 우리의 히어로 C와 C++을 볼까요?

    C는 절차지향 언어이고, 하이레벨 언어이면서, 동시에 로우레벨 시스템의 컨트롤에 관여할 수 있습니다.

    C++영감탱이는 객체지향을 표방한 절차지향 + 객체지향의 짬뽕 언어이면서,

    C언어의 형태를 고대로 쓸 수도 있고, Java나 C#을 어느정도 흉내내서 쓸 수도 있으며,

    자신만의 독창적인 신기한 형태의 객체지향을 구현할 수도 있지요.

    그런데...

    사용자 삽입 이미지

    C와 C++은 타겟 프로그램을 어디에서 돌릴 목적으로 컴파일/링크/어셈블리 하느냐에 따라

    자유도가 달라집니다.

    가령 예를 들면, 윈도우즈 어플리케이션으로 컴파일 한 친구는 메모리 내부의 비디오메모리 번지에

    접근하려 할 경우,

    사용자 삽입 이미지

    라는 OS의 강력한 경고를 받지만 -_-;;

    커널 수준에서 제어할 목적으로 만들었다면,

    사용자 삽입 이미지

    요래도 뭐 문제삼지 않습니다 -_-;

    왜냐,

    시킨놈 마음대로니까요 -_-;

    시킨놈이 알아서 처리할꺼라고 굳게 믿는거지요.

    시키는 사람이 사태에 대해 잘 알건 모르건 신경 안쓰는 겁니다.

    사용자 삽입 이미지

    -_-;;

    뽑던 말던... 뽑아서 보던 말던... =_=;;

    고로, 프로그래머의 자유도는 사용하는 프로그래밍 언어의 자유도와 같다고 할 수 있고,

    사용할 수 있는 프로그래밍 언어의 갯수이며,

    프로그래머가 가진 지식의 양에 비례하고,

    "프로그래머의 책임 정도에 달렸다"

    라고 할 수 있지요.
    posted by Lonewolf dlbo

    댓글을 달아 주세요

    1. 왠지 이번엔 설명을 위한 짤방이 아니라서 살짝 아쉬웠어

    2. 테슬라 2009.06.01 00:37  Addr Edit/Del Reply

      자바가 짜증나긴 하지...
      C하다가 자바쓰면 답답해...ㅎㅎ

    3. 실제로 마지막 cd엔 별거 없다더군요 ㅇㅅㅇ;;;

    2009.05.19 22:17 (비정기) Dlbo's Post
    아흠. 아무래도 그냥 데스크탑 한대 뽑아야 할까 봅니다. -_-;;

    -------------------------------------------------------------------------------------------

    간만에 돌아왔습니다.

    이번에는 UDP 서버의 간략한 소스를 보지요.



    ... 저번 TCP/IP 서버보다 더 대충 만들어진 티가 납니다만 -_-;

    전송 프로토콜이 SOCK_DGRAM이 되었다는 점만 바뀌고, 사실상 거의 안바뀌었다고 봐도 됩니다.

    UDP프로토콜은 이전 포스트에서도 언급했듯, 일단 그냥 패킷을 네트워크 상에 보내버리고,

    그 패킷이 타겟에 도착했는지 아닌지 체크하지 않습니다.

    뭐... 그리하여 소스가 더 간단하지는 않을까 고민을 해도,

    이 코드처럼 결국은 TCP/IP나 UDP나 코드가 얼추 비스무레 해져 버리지요.

    절차지향언어인 C에서 소켓을 구성하기에는 무리가 있기 때문에 이런 비효율적인 코드형태가 되었습니다.

    오버로딩이 없으니 같은 기능을 하는 함수임에도 불구하고 각 소켓에 따른 다른 이름의 함수(recvfrom과 recv)등이

    나오고, 귀찮게시리 다 외워야 하게 된 거지요.

    ------------------------------------------------------------------------------------------------

    요 주제도 요만 끊어야 할 듯 합니다.

    좀 눈요기거리라도 많을법하면 포스팅거리로 적당한데,

    주로 내부 동작 위주이기 때문에 간략하게 서버까지만 소개하고 끝내는 방법이 좋을 듯 합니다.

    적당한 포스팅거리가 생길때 까진 간단한 칼럼 형식으로 포스트를 띄우겠습니다.
    posted by Lonewolf dlbo

    댓글을 달아 주세요

    1. 그냥 C++로 만드셨으면...? C++ 윈속은 없나요?

      • Favicon of http://dlbo.tistory.com BlogIcon Lonewolf dlbo 2009.06.13 01:15  Addr Edit/Del

        MFC에 제공되긴 하지만 요래저래 엉키기 때문에 귀찮기도 하고, API윈속이 더 간단해서 API로 해뒀습니다 -_-a;

    2009.04.25 01:24 (비정기) Dlbo's Post
    ---------------------------------------------------------------------------------

    사유 : 노트북 개아작남

    연기일자 : 4. 28. 화. ~

    예상 복귀 일자 : 장담 못함 -_-;

    ---------------------------------------------------------------------------------

    드디어 노트북님이 제 뻘짓을 감당 못하고 뻗어버렸습니다.

    이 컴은 동생컴인데.... 코딩은 커녕 웹서핑도 힘들 정도로 상태가 안좋습니다.

    아무래도 놋북님이 되살아날때까지 일시 중지할듯 합니다.

    대략 예상컨데 하드와 보드가 모두 나간게 아닐까... -_-;
    posted by Lonewolf dlbo

    댓글을 달아 주세요

    1. 불쌍하게도 강행군을 따라와줘야 했던 너의 노트북님께 애도

    2009.04.21 15:18 (비정기) Dlbo's Post


    간략한 윈속을 이용한 TCP/IP 서버의 예제입니다.

    뭐...

    1:1 전용이긴 하지만 -_-ㅋㅋ

    클라이언트로부터 데이터를 받아 출력하고 다시 돌려보내준다는 점은 서버로서의 역할을 미약하게나마

    갖췄다고 볼 수 있지요.

    저 예제에서 보시면 알겠지만, 1개의 연결에 대해 1개의 소켓이 필요합니다.

    받는 소켓인 listen과 클라이언트에게 보내는 client_send 소켓이 분류되어 있지요?

    컴 두대가 대화하려면 소켓이 2개 필요하다는 이야기입니다.

    아, 물론 두대가 1개의 소켓으로 대화하는 방법도 있지만..

    저런 구조로 그런걸 하는건 왠만해선 추천해드리지 않습니다.

    -_-;;

    여기서 잠깐.

    서버 자체가 싱글턴이냐, 소켓이 싱글턴이냐... 혹은 아무것도 아니느냐.

    약간 머리굴려볼 필요가 있습니다.

    같은 IP주소에 같은 역할을 하는 서버가 2~3개씩이라면?

    이 경우는 두세개의 서버가 모두 같은 패킷을 받아 같은 소켓으로 같이 쏴대기 때문에

    서로 엉키거나, 혹은 쓸데없이 리소스를 많이 잡아먹는 안습상황이 발생할 수 있습니다.

    한마디로 뻘.짓. 이라는 거지요.

    반면, 같은 기능을 하는 서버를 여럿 띄워서 1개 클라이언트로 접속 시도시 여러개의 서버에서

    동시에 1개의 클라이언트가 다중접속한것처럼 보이며,

    각각의 서버가 따로 클라이언트에게 잘만 데이터를 보내줍니다.

    -_-;;

    이 점으로 미루어 볼 때, 소켓은 여럿이서 같이 쓸 수 있으므로 그냥 아무것도 아니지만,

    서버는 왠만해선 같은 기능이라면 싱글턴으로 돌아가도록,

    같은 프로세스가 실행중일때는 실행되지 않도록 만드는 것이 좋습니다.

    객체지향의 싱글턴과는 다르지만 =_=

    싱글턴과 비슷한 모습으로 만드는게 유리하다는 의미이죠.
    posted by Lonewolf dlbo

    댓글을 달아 주세요

    2009.04.14 15:38 (비정기) Dlbo's Post

    한주나 지났는데도 몸상태는 쉣이군요.

    괴기한 집 구조덕분인듯... 아무래도 자취방이라도 구해서 나가야 하지 않을까 싶습니다 -_-;;

    ------------------------------------------------------------------------------------------------

    이번엔 디자인패턴을 제외해두고 네트워크의 기본구조중 프로토콜에 대해 포스팅하지요.

    네트워크는 여러대의 컴퓨터가 일대 일, 혹은 다대 다나 다대 일, 일대 다의 관계로 데이터를

    주고받는 영역입니다.

    이렇게 여러 컴퓨터가 데이터를 주고 받기 위해서는 일정한 규약이 필요합니다.

    규약이 없다면 아마 이리 되겠지요 -_-;;


    사용자 삽입 이미지


    으흠... 좀 쩌는듯 -_-;

    이런 규약을 네트워크에서 프로토콜(Protocol)이라고 부릅니다.

    네트워크상에서는 마치 신호등, 혹은 기본적인 대화법이라고 볼 수 있지요.

    이 방식에는 여러가지가 있습니다.

    1. TCP/IP

    네트워크에서는 소통을 하기 위해 소켓(Socket)이라는 것을 씁니다.

    포트라는 하나의 컴퓨터 내의 항구 같은 역할을 하는 친구들을 소켓당 하나씩 붙잡고,

    소켓이 포트를 관리하면서 다른 컴퓨터와의 대화를 체크하지요.

    TCP/IP는 1개의 컴퓨터와 대화할때마다 1개의 소켓을 사용합니다.

    포트넘버야 아무래도 같이 쓰기도 하고 혼자 쓰기도 하고 한다지만,

    소켓만큼은 1개의 연결에 대해 1개씩은 필요하다는 의미이지요.

    이리하여 select모델 등을 사용하여 여러개의 소켓을 관리하는 방법을 써야 다대다, 혹은

    일대다의 통신이 가능한 프로토콜이 TCP/IP입니다.

    이 TCP/IP 프로토콜은 아래 친구들과 비슷하지요.

    사용자 삽입 이미지

    ....

    한번 적을 보면 끝장을 보는 특수부대입니다 -_-a

    한개의 연결에 대해서 확실하게 데이터가 오고감을 체크하는 프로토콜이지요.

    2. UDP 프로토콜

    UDP프로토콜은 TCP/IP와 크게 다르진 않습니다만,

    성격이 TCP/IP와 약간 다르다는 면이 있지요.

    사용자 삽입 이미지

    .....;;;

    UDP는 소켓으로 그냥 쏩니다.

    -_-;

    그리고 그냥 받지요.

    "알아서 받아... 귀찮어..." 라는거지요.

    TCP/IP가 "나 못받았어 다시 해봐" 라고 패킷응답을 하는 반면,

    UDP프로토콜은 그냥 네트워크상에 훽~ 던져놓고는 "내껀가... 가져가자..."

    하고 대충 챙겨가는 그런 무심한 녀석이라는 것이지요.

    4. 브로드캐스팅, 멀티캐스팅

    브로드캐스팅과 멀티캐스팅은 정확히 말하면 프로토콜은 아닙니다.

    UDP를 기반으로 한 통신모델이지요.

    멀티캐스팅은 몇몇 대상을 잡고 여러 대상에 대해 패킷을 송신하는 방식으로,

    일대 다 방식중 선별적인 방법으로 볼 수 있습니다.

    이후 TCP/IP처럼 응답패킷 처리를 하면 TCP/IP인것처럼 돌릴 수도 있지요.

    반면 브로드캐스팅은 UDP의 특성에 충실하게 그냥 뿌립니다.

    마치 TV인양 -_-

    한국어로 번역하면 "방송"이라는 말에 맞게

    그냥 뿌립니다

    ㅡ,.ㅡ;;

    다만, 타겟이 정해진것이 아니기 때문에 어느 누구나 브로드캐스팅 방식과

    전송되는 포트를 안다면 받아볼 수 있다는 것이 다르지요.

    무전기와 비슷한 원리라고 볼 수 있습니다.

    ---------------------------------------------------------------------------------------------

    다음 포스트에서는 TCP/IP 서버의 소스코드와 싱글턴패턴을 써볼 생각입니다.

    사실 서버를 통채로 싱글턴패턴으로 쓰는건 아니지만 말이지요... =_= 그건 돌맞을 일이고 ㅋㅋㅋ;;
    posted by Lonewolf dlbo

    댓글을 달아 주세요

    1. Favicon of http://klone.tistory.com BlogIcon Mr.K 2009.04.15 14:08  Addr Edit/Del Reply

      미안의 압박 ㅋㅋㅋㅋㅋㅋ


      "주인 백"이 있으면 적당할 자리에 그게 있으니 묘함 ㅋㅋㅋㅋ

    2. 재밌게 읽을 수 있었군

    3. 테슬라 2009.04.18 21:45  Addr Edit/Del Reply

      ㅎㅎ 나도 재밌게 읽었어~

    4. 테슬라 2009.04.20 23:37  Addr Edit/Del Reply

      앗 문제는 풀고 있어.
      절반 정도 풀긴했는데... 시험끝나고 올릴게... 시험기간인지라...ㅎㅎ;;

    5. 저 안내문 사진에 두 사람이 폰 들고 사진 찍는 모습이 비치는군요 ㅋㅋㅋ

    2009.04.07 15:23 (비정기) Dlbo's Post
    ---------------------------------------------------------------------------------

    사유 : 몸살 및 시간관리 실패

    연기일자 : 4. 7. 화.

    예상 복귀 일자 : 4. 14 화.

    ---------------------------------------------------------------------------------

    ...

    좀만 쉴께요 ㄱ-
    posted by Lonewolf dlbo

    댓글을 달아 주세요

    1. 너도 그럴 때가 있구나

    2009.03.31 13:39 (비정기) Dlbo's Post
    아....

    코드를 첨부하긴 해야 하는데,

    미리 만들어놓은 레퍼런스가 없으니 좀 곤란하군요.

    한번 따로 준비해서 올려야 할듯...

    -----------------------------------------------------------------------------------------

    옵저버 패턴이라는건..

    사용자 삽입 이미지

    요런 놈을 연상시키게도 하지만 -_-;;

    이름만 같을 뿐, 약간은 다른 기능을 가집니다.

    스타크의 옵저버는 숨어있는 것들을 찾아냅니다.

    반면, 옵저버패턴은 자신에게 등록된 클라이언트들에게 '통보'를 하는 역할을 갖습니다.

    가장 간단한 예를 들자면 바로 이거지요.

    사용자 삽입 이미지

    자신의 통신사에 등록된 모든 고객에게 재난 문자나 여러 정보를 통보해주는 서비스.

    그 서비스를 해주는 객체가 옵저버입니다.

    이러한 패턴이 옵저버 패턴.

    여기서 잠깐, 옵저버는 자신의 고객들에게 선별적으로 각각 다른 통보를 할 수 없습니다.

    좀 비효율적일수도 있겠지요?

    근데 이게 왜 중요하느냐...

    바로 게임 서버를 생각해보면 알 수 있습니다.

    1 : 1로 맞고를 치고 있습니다.

    이번에 뒤집어 까서 나온 패로 인해 쪽이 난다면 -_-

    본인은 쓰리고까지 지나서 스톱을 해야 하는 상황.

    "응-_-가"가 나오면 이기는데...

    본인에게는 응-_-가패가 나와 쪽이 되고,

    상대방에게는 전혀 다른 엉뚱한 패가 나온걸로 보인다면

    서로 차질이 생기겠지요?



    자.

    저 옵저버-서버 라는 클래스가 옵저버패턴의 형태라고 볼 수 있습니다.

    개발새발로 대충 짜놓은 코드라 완전히 맞는건 아니지만 말이지요 -_-;;

    서버가 저렇게 모든 클라이언트에게 동일한 정보를 쏘아 줄 때, 이를 옵저버 패턴이라 볼 수 있습니다.

    근데 여기서 잠깐.

    그럼 옵저버 패턴이면 서버 얘기를 하지 왜 클라이언트를 제목에 박아넣었느냐. =_=

    ....

    서버는 지난번에 얘기를 했기 때문이에요 -_-. 돌던지지 마세요;

    사실 옵저버 패턴이라는 것은 정보를 뿌리는 Sender와 정보를 받는 Client가 결합되야 하는 구조이기

    때문에 클라이언트를 언급 한 것입니다.

    클라이언트는 서버가 보내는 정보를 같은 규칙에 의해 받아내야 하지요.

    네트워크에서는 이 규칙을 "프로토콜"이라 부릅니다.

    http, ftp, TCP/IP, UDP 같은 여러 프로토콜들이 존재하지요.

    ------------------------------------------------------------------------------------------

    ... 너무 막 휘갈긴거같은 찝질한 느낌...

    사용자 삽입 이미지

    이런 기분이랄까요.
    posted by Lonewolf dlbo

    댓글을 달아 주세요

    1. Favicon of http://klone.tistory.com BlogIcon Mr.K 2009.03.31 16:10  Addr Edit/Del Reply

      지난 포스트에서 서버에 대해 뭘 얘기한거임?

    2009.03.24 00:16 (비정기) Dlbo's Post
    푸후. 디자인패턴과 네트워크 포스팅의 첫삽이군요.

    아직 완전히 결합시켜 이해중인게 아니라서 제대로 써 질지 고민됩니다.

    ------------------------------------------------------------------------------

    Singleton 패턴이란 녀석이 디자인패턴에 있습니다.

    디자인패턴은 객체지향 언어로 프로그래밍할 경우 잡는 하나의 기본 골격인데요.

    Singleton 패턴은 이런 골격중 하나이지요.

    Skeleton이랑 비슷하다고 이런건 아닙니다 -_-;

    사용자 삽입 이미지

    아 깜찍해 -_-

    Singleton 패턴은 single이라는 앞단어와 관련있습니다.

    "유일한!" 객체라는 겁니다.

    왜 Unique가 아니냐고 물어보면 할말 없습니다.

    GoF(Gang of Four, 디자인패턴의 창시멤버)형제들에게 물어보세요 그건 -_-;

    Singleton패턴은 객체지향에서 여러 객체가 동시에 사용할수 있는 전역변수를

    Java같은 언어에선 사용할수 없기 때문에 탄생한 녀석입니다.

    동시에 C++이더라도 단순전역변수는 캡슐화가 거의 되지 않는다는 단점도 극복해줄수 있지요.

    대충 코드를 보자면 이러합니다. >



    제가 싫어하는 자바이긴 하지만 -_-

    디자인패턴 구현시에는 자바가 훨씬 편하고 유용한 편입니다.

    저렇게 하면 한 프로세스 내에서 단 한개만의 객체만 존재하게 됩니다.

    그래서 "유일한!" 객체라는 거지요 -_-;

    클래스가 유일하다는게 아닙니다.

    멀티스레드 사용시 서로 엉켜서 두개, 세개, 네개씩 객체가 생성되기도 합니다만,

    이때는 DCL이라는 새로운 기법의 패턴을 적용합니다.

    Double Checking Lock이라는건데... 이는 나중에 다시 언급하도록 하지요.

    자... 그런데 왜 Singleton & Server라는 제목이 붙었을까요?

    .....

    생각해보시면 답은 간단합니다.

    한국에 살고 있습니다.

    근데 정부가 3개입니다.

    어쩔껍니까 -_-;;

    사용자 삽입 이미지

    에누리없이 이말 튀어나와야죠 =ㅁ=....

    Singleton 객체는 이렇게 "꼭 하나만 존재해야 할 때" 씁니다.

    아, 물론 정부가 2~3개씩 되는 내분이 피터지는 국가들도 있겠지만;;

    이런 특수한 케이스는 예외로 합시다.

    ------------------------------------------------------------------------------

    포스트가 의외로 짧습니다. -_-;;

    다음 포스트에는 클라이언트와 옵저버패턴에 대해 언급해야 겠군요.
    posted by Lonewolf dlbo

    댓글을 달아 주세요

    2009.03.19 16:38 (비정기) Dlbo's Post

    또 다시 새로 시작하는 시리즈물이 되는군요.

    디자인패턴과 네트워크중 뭘 해야 하나... 고민하다가

    잘 생각해보니깐 그냥 섞-_-어서 하는게 좋다는 생각이 들었답니다.

    =========================================================================================

    네트워크가 뭔진 다들 아시지요?

    사용자 삽입 이미지

    http://photo.naver.com/view/2007083002463140444 펌


    대략 요거 비슷하네요.

    -_-;

    WWW(월드 와이드 웹)이 저런 거미줄 같은거라고 하는 분들이 계실진 모르겠습니다만,

    WWW도 네트워크에 기반을 둔 모델이니까요.

    같습니다.

    (우기는중 -_-)

    사실 좀 다르긴 하다 해도... 그건 나중에 차차 설명하지요.

    -_-;

    그런듸, 객체지향의 디자인패턴도 사실은 저런 거미줄같아요.

    그러니 제가 두개 합쳐 쓸 생각을 했겠지만 말입니다 -_-ㅋㅋ

    사용자 삽입 이미지

    이런식으로 우기고 있는건 아니구요 =_=

    서버와 클라이언트, 브로드캐스터와 브로드캐스티 등의 관계가 사실상 객체간의 관계와 비슷함을 생각하면

    네트워크 프로그래밍은 가장 객체지향적이라고 볼 수 있거든요.

    뭐, 여튼 다음 TCP/IP와 객체 편에서 다시 뵙겠습니다 -_-!

    =========================================================================================

    posted by Lonewolf dlbo

    댓글을 달아 주세요

    2009.03.15 13:12 (비정기) Dlbo's Post

    ---------------------------------------------------------------------------------

    사유 : 입-_-대하는 친구

    연기일자 : 3. 17. 화.

    예상 복귀 일자 : 3. 19 목.

    ---------------------------------------------------------------------------------

    친척집도 몇군데 돌아야 하고 해서 아마 제때 포스트를 올리지 못할것 같습니다.

    최대한 빨리 돌아와서 포스트 업로드 하겠습니다.
    posted by Lonewolf dlbo

    댓글을 달아 주세요

    2009.03.10 20:57 (비정기) Dlbo's Post
    끄흥흥

    제네릭 알고리즘의 라스트 파트입니다.

    어느새 끝나버렸군요.

    -_-;

    -------------------------------------------------------------------------------------------



    이것이 바로 foreach입니다.

    -_-;

    단순하지요?

    what_do같은 중간매개함수를 만들어서,

    foreach 함수로 지정해주면

    해당 컨테이너의 구간에서 반복해 실행합니다. 각 요소마다 말이지요.

    리스트 뿐만이 아니라 벡터는 물론이고 string객체에도 적용된답니다. ㅡ.,ㅡ;;

    여기선 단순히 cout객체를 이용한 출력만을 했지만...

    PKU의 문제에서 문자열에 대해 글자마다 처리하는것도 foreach로 처리가 가능하고,

    혹은 실제 개발에서 for문 다 쓰기 귀찮을때 이걸 쓸 수도 있지요 ㅡ.,ㅡ;





    아주 간단하군요.

    min과 max입니다 -_-;

    역시 algorithm 헤더에 들어있으며,

    두 수중 큰 수를 리턴하는게 max, 작은걸 리턴하는게 min입니다.

    정수형뿐만 아니라, 템플릿으로 처리되어 있어 비교연산자가 오버로딩되어 있다면 뭐든지 사용 가능합니다.

    강력하면서도 단순한 물건이지요 -_-;

    ---------------------------------------------------------------------------------------------

    정말 제네릭 알고리즘은 단순하게 끝났군요. -_-;

    네트워크 프로그래밍을 다음 포스트로 해야 할지, 아니면 디자인패턴으로 해야 할 지 고민입니다.

    다음주 화요일까지 결정 안난다면 공지로 띄우도록 하지요 -_-;
    posted by Lonewolf dlbo

    댓글을 달아 주세요

    2009.03.03 21:13 (비정기) Dlbo's Post
    ㄲㄲㄲㄲㄲ

    이번엔 find와 search를 동시에 연재합니다.

    이래야 후딱 끝내고 네트워크를 들어가지 ㄱ-

    ----------------------------------------------------------------------------

    find() 함수와 search()함수는 쪼까 다르면서도 비슷한 친구입니다.

    find는 찾아내서 해당 녀석을 리턴하는거고, search는 구간을 찾아내어 그 결과를 알려줍니다.

    find()함수는 아주 간단한데요,

    템플릿 함수라 그런지 이터레이터 두개와 값 한개를 받고 이터레이터를 반환합니다.



    아주 간단한 예제.
    사용자 삽입 이미지

    참 쉽죠? -_-

    find()는 존재여부를 찾은 후, 존재한다면 해당 이터레이터를, 아니면 해당 리스트의 end()를 리턴합니다.

    리스트가 아니라 여러가지도 가능하구요...

    만약 사용자 정의 클래스나 여타 이러저러한 것들을 쓰려면 ==연산자를 오버로딩 하셔야 합니다.

    - _- 귀찮게시리

    그 다음 search()는 뭐...

    생긴게 살짝 복잡합니다.

    search(해당 컨테이너의 시작, 해당 컨테이너의 끝, 타겟 컨테이너의 시작, 타겟 컨테이너의 끝)

    ......

    드럽죠? -_-;



    위에꺼랑 어딘가 닯은 코드.

    -_-;;

    조금만 고친게 아니구요.

    .....

    예.

    좀만 고쳤어요.

    -_ -

    사용법은 거의 똑같습니다.
    사용자 삽입 이미지

    참... 쉽죠?-_-?;;

    --------------------------------------------------------------------------------------

    이번에도 뭔가 아쉬울정도로 쉽게 끝났습니다.

    다음에는 더 간단한 for_each와 min, max에 대해 하고 네트워크 프로그래밍에 대해 간단한 시리즈물을

    올리도록 하지요.

    ....

    아마 두세번이면 엥간한건 다 할수 있을겁니다.

    -_-;;

    사용자 삽입 이미지
    posted by Lonewolf dlbo

    댓글을 달아 주세요

    1. 내가 꼭 요래야되?-_-;;

    2. 오빠못믿니? 2009.03.24 20:43  Addr Edit/Del Reply

      ㅋㅋ

    prev 1 2 3 next