vi의 조금 편리한 기능들

사실은 조금 더 강력한 기능이랄까.

반복

  • . – (dot) 구두점은 마지막으로 실행한 명령을 다시 한 번 더 실행해준다. 명령의 반복은 다음과 같이 볼 수 있다.
  • {숫자} {명령} – 명령 앞에 숫자를 붙이면 그 숫자만큼 반복하게 된다. 이동할 때 3w라고 하면 세 단어를 이동하는 데 이것이 사실은 거의 모든 명령에도 적용될 수 있다.
2dd     # 현재 줄을 포함하여 2줄을 삭제한다.
3p      # 잘라낸 2줄을 3번 붙인다.
100iDescription <ESC>  # 'Description '을 100번 삽입한다.
.       # 위의 것을 1번 더 즉 100번 더 쓴다.
3p      # 100번 쓰는 것을 3번 하니 300번을 더 쓴다.

특정 지점으로 이동

w로 다음 단어의 첫 글자로 이동하거나, e로 단어의 끝으로 이동하는 것 외에 몇 가지 추가적인 이동 명령. 역시 이동 명령은 ‘선택’하는 액션과 동일하게 동작하므로 살펴보면 도움이 된다.

  • fa – 다음에 나타나는 ‘a’로 이동. 3fa는 다음에 나타내는 a 중 3번째로 이동. 대문자는 역 방향.
  • ta – 다음에 나타나는 ‘a’의 바로 앞으로 이동. 대문자는 역방향.
  • % – 괄호 (대/중/소)에서 입력하면 그에 상응하는 괄호로 이동함. 코드에서 괄호를 안 닫거나 하는 부분을 찾기가 아주 편리하다.
  • ]) – 다음번 닫는 괄호로 이동한다. 여는 괄호로 이동은 ](. 다른 괄호 종류에 대해서도 동일하게 적용됨
  • ( , ) – 이전/다음 문장
  • {, } – 이전/다음 문단

Visual Mode

비주얼 모드는 텍스트의 일부 구간을 선택하는데 시각적으로 선택된 텍스트를 반전시켜 어떤 텍스트가 선택되는지를 눈으로 보여준다. 비주얼 모드와 비슷하게 비주얼 블록 모드가 있는데 이는 화면상에 사각형 영역으로 (행전체가 선택되지 않게) 선택할 수 있다. (일부 좋은 기능들이 많은 텍스트 편집기들이 이런 기능을 지원하고는 있음)

  • vi” – 따옴표로 둘러싼 영역을 모두 선택
  • va” – 따옴표로 둘러싼 영역을 따옴표를 포함하여 선택
  • v – 비주얼 모드 시작. 비주얼 모드를 시작하면 현재 위치로부터 커서를 옮기는 만큼 색상이 반전되며 선택된다. 선택된 내용에 대해 d 나 y 로 오려두기/복사하기를 할 수 있다.
  • ^v – 비주얼 블록 모드. 비주얼 블록 모드는 행 단위가아닌 열 단위로 선택하게 한다.
  • I, A – i, a 의 대문자. 비주얼 블록 모드로 선택한 여러 행에 걸친 위치에 같은 내용을 삽입한다. 예를 들어 1행부터 40행까지의 내용을 “// “으로 주석처리하고자 한다면 다음과 같이한다. (아래 [^v]는 control+v를 말하며 공백은 스페이스바를 입력했음을 의미한다.)
 gg0[^v]39jI// [ESC] 
  • gg – 1번행으로 간다.
  • 0 – 맨 왼쪽으로 간다
  • [^v] – 비주얼 블록 모드 시작
  • 39j – 39행 아래로 이동하여 40행까지 첫번째 열을 모두 선택
  • I – multiple insert mode 시작
  • //  – “// ” 입력
  • [ESC] – 삽입모드 종료. 40행까지 모두 주석처리가 된다.
  • <, > – 비주얼 모드에서 선택된 라인들에 대해 좌/우 방향으로 들여쓰기, 내어쓰기를 적용
  • = – 비주얼 모드에서 선택된 라인들에 대해 자동 들여쓰기 (정말 쿨함)

자동완성

insert mode에서 입력중에 ^p를 누르면 이전에 입력한 적 있는 단어 중에서 비슷한 단어를 자동완성해주는 기능이 있다.

창 분할

  • :split – 창을 상/하 분할한다. (분할된 공간에는 새 파일을 만들 수 있다.)
  • :vsplit – 창을 좌/우 분할한다.
  • ^w^w – 분할된 창 사이를 이동할 수 있다.
  • ^w_ – 현재 창을 최대화 (분할된 공간을 최대화함)
  • ^w| – 현재 창을 최대화 (세로 분할인 경우)
  • :tabnew – 새로운 탭을 만든다.
  • gt – 다른 탭으로 이동한다.

 

vi 기본 사용법

vi은 대부분의 유닉스나 리눅스 시스템에 설치되어 있다고 믿어도 좋을만큼 널리 퍼져있는 텍스트 편집기이고, 매우 오랜 역사를 가지고 있는 텍스트 편집기이다. 일견, 상식적으로 이해가 힘들 것 같은 조작법 때문에 재미삼아 열어봤다가는 메뉴 등등 익숙한 문서 편집 프로그램에서 볼 수 있는 UI도 없기 때문에 낭패를 보기 십상이지만, 터미널에서 텍스트 파일을 작성하거나 편집할 때 유용하게 사용할 수 있다. 익혀두면 좋을 뿐더러 엄청 편리한 기능들을 제공하기 때문에 오늘날에도 많은 개발자들의 사랑을 받고 있는 편집기..라고 한다.

텍스트로 구성된 설정파일이나 하다 못해 hosts 파일 수정에는 더 없이 깔끔하니 좋은 프로그램이다보니 한 번쯤은 사용법을 익혀서 정리해 둘 봄 즉도 해서 정리한다.

기본 컨셉

vi는 일반적인 메모장과는 완전히 다른 인터페이스를 가지고 있다. 모든 것이 ‘명령’으로 이루어지고 이들 ‘명령’은 키를 누르는 것으로 입력된다. 또한 이 ‘명령’들은 간소하나마 자신만의 문법을 가지고 있다. 텍스트를 입력하는 것은 명령모드에서 입력모드 (insert mode)로 전환한 후에야 가능하며, 다시 명령 모드로 돌아가기 위해서는 ESC 키를 눌러 준다. vi의 화면 맨 아래에는 현재 상태를 표시해주는 줄이 있다. 이 줄에서 insert 가 표시되는지 안되는지를 눈여겨 보면 좋다.

vi는 터미널에서 vi 명령으로 실행할 수 있고, 다음처럼 파일 이름을 덧붙여 준다. 파일이 존재하는 경우에는 그 파일을 열고, 새로운 파일 이름인 경우에는 파일을 생성한다.

 vi ~/mytext.txt

커서 이동

vi에서는 커서 이동도 하나의 명령이다. 이 개념을 이해 못하면 완전 낭패를 볼 수 있다. 물론 ㅍ플랫폼이나 버전에 따라서 약간 다를 수는 있는데 기본적으로 화살표 키가 아닌 h,j,k,l 키로 커서 이동을 한다. 한 번에 한 칸씩 이동하는 게 좀 답답하니까 몇 가지 추가적인 기능을 더해 제공해고 있다. 최소한 이 이동에 관한 내용은 외워줘야 한다.

  • j – 한 칸 아래로 이동
  • k – 한 칸 위로 이동
  • h – 한 칸 왼쪽으로 이동
  • l – 한 칸 오른쪽으로 이동
  • w – 한 단어만큼 앞쪽으로 점프 (여기서 앞쪽이란 문서를 써나가는 방향이다.)
  • b – 한 단어만큼 뒤쪽으로 점프
  • 0 – (숫자 0) 현재 줄의 시작지점으로 점프
  • $ – 현재 줄의 끝 지점으로 점프
  • ^ – 현재 줄에서 공백이 아닌 첫 글자로 점프
  • gg – 파일의 맨 첫줄로 점프
  • G – (shift + g) 파일의 맨 끝으로 점프
  • (숫자)G – 해당 번호의 행으로 점프
  • ^f – 다음 페이지로 이동. 특히 도움말을 볼 때 유용하다.
  • ^b – 이전 페이지로 이동.

각각의 키들은 단순히 방향키를 치환한 것이 아니라 하나의 명령이다. vi에서 재밌는 것은 숫자와 함께 사용하여 명령을 실행할 수 있다. 예를 들어 h 는 한 칸 왼쪽으로 이동하는데, 8h 라고 입력하면 8칸 왼쪽으로 이동할 수 있다. 같은 방법으로 9j 는 9줄 아래로 이동한다.

입력과 삭제

vi에서 텍스트를 입력하는 것은 사실 ‘추가’이다. 추가는 추가 모드로 진입한 후 타이핑을 하면 이 때부터 타이핑되는 글자들은 모두 파일의 내용으로 기록된다.

  • i – 현재 커서 위치에서부터 텍스트 삽입을 시작한다.
  • <ESC> -  esc키를 누르면 삽입 모드를 빠져나가 명령모드로 진입한다.
  • a – append. 현재 커서 위치 다음 글자부터 텍스트를 붙여 준다.
  • o – 현재 커서의 바로 다음에 새 줄을 추가하고 다음줄에서 바로 삽입모드로 전환된다.
  • O – (Shift + o) 커서의 바로 위에 새 줄을 추가해준다.

삭제

삭제는 커서를 기준으로 글자를 지우거나, 단어를 지우거나 하는 등의 동작이다. 재밌는 것은 입력모드에서는 백 스페이스 키를 눌러서 입력하던 글자를 얼마든지 지울 수 있는데, 입력모드가 끝나고 나면 삭제 명령으로 지워야 한다. (백스페이스키는 보통 왼쪽으로 이동하는 것과 동일하게 작동하는 경우가 많다.)

  • x – 커서가 위치한 곳의 글자를 지운다.
  • dh – 커서가 위치한 곳에서 부터 한칸 앞쪽으로 지운다. delete + h 인 셈인데, 이를 활용하여 d3h 하면 현재 커서 위치로 부터 3칸 앞의 글자들을 지울 수 있다. 즉 d 와 이동 명령을 결합하여 커서가 지나가는 자리만큼을 지운다.
  • dj – 현재줄을 포함하여 다음 줄까지 2줄을 지우게 된다.
  • dd – 가장 많이 쓰는 것은 아마 현재 줄을 지우는 경우일 것이다. dd는 현재 줄을 지운다.

삭제는 사실 “오려두기”이다. 이는 뒤에서 다시 설명하겠다.

고치기

오타를 수정하거나 하려면 덮어쓰기를 시전하면 된다. 다음과 같은 명령들이 있다.

  • r – 현재 커서 위치에서 한 글자만 바꾼다. 커서가 위치한 곳의 글자가 a 인경우 rb 라고 누르면 a가 b로 바뀐다. 한글자만 딱 입력받아 바꿔준다.
  • R – 수정모드가 되어 ESC를 누를 때까지 현재 줄의 내용을 수정해 준다. 재밌는 것은 수정 모드에서는 백스페이스키를 누르면 입력한 글자가 지워지는 것이 아니라 기존에 있던 글자로 되돌아간다는 점이다.
  • c -  change로 이동 명령과 결합하여 한 글자를 지우고 입력모드가 된다. 즉 커서위의 글자가 입력한 글자들로 바뀌게 된다. cl 이라고 입력하면 커서위의 글자가 지워진다.
  • cw – c+w로 커서 위치부터 그 단어의 끝까지가 새로 입력한 글자들로 대체된다. 즉 change + w로 실행되었다고 보면 된다. 비슷하게 c$ 하면 커서 위치부터 그 줄 끝까지를 지우고 새로 쓰게 되는 것이다.
  • C – c$와 같다.
  • s – cl 과 같다. 한 글자만 지우고 입력한다.
  • S – 줄 전체를 새로 쓴다. s는 아마 subtitute의 머리글자인 것 같다.

복사와 붙이기

복사 명령은 y 이다. yy는 현재 라인을 복사하고, 2yy는 현재 라인을 포함한 두 줄을 복사한다.

  • y – 복사 시작. y 다음에 이동 명령을 조합하여 복사할 범위를 지정한다.
  • yw – 단어 끝까지 복사
  • y$ – 현재 줄의 끝까지 복사
  • p – 붙여 넣기. 만약 줄을 복사하였다면 현재 커서위치가 아닌 바로 아래쪽에 줄이 붙는다.

또한 x, d 등을 통해 삭제한 글자들은 모두 ‘오려두기’로 지우고 메모리에 저장되어 있으므로 p를 사용하여 붙여넣을 수 있다.

되돌리기

  • u – 한 번의 변경을 되돌릴 수 있다.
  • U – 한 줄에 대해 변경사항을 모두 되돌린다.
  • ^r – (Ctrl+R) 되돌린 내용을 다시 적용한다.

되돌리기도 물론 지원하고 있다. 기본적으로 약 50번 정도의 undo를 지원하는 듯. 이쯤에서 메모장이 더 이상 아쉽지 않기 시작한다.

저장과 종료

편집이 아닌 파일에 접근하는 등의 명령은 : 로 시작한다. : 를 입력하면 화면 맨 아래에 : 가 입력되고 명령을 수행할 준비를 한다. 아래는 저장 종료 및 기타 유용한 명령들이다.

  • :cd – 현재 디렉토리를 보여준다.
  • :cd _PATHNAME_ – 다른 디렉토리로 변경한다.
  • :!{shell command} – 쉘 명령를 vi 안에서 실행한다. :!ls 하면 현재 디렉토리의 파일 목록을 확인할 수 있다. 명령 실행이 완료되면 엔터를 눌러 복귀한다.
  • ^g : 현재 행 번호를 보여준다.
  • :w – 현재 내용을 디스크에 기록한다.
  • :w __FILEPATH__ – 현재 내용을 다른 이름으로 저장할 수 있다.
  • :q – 종료한다. 만약 편집된 내용이 있다면 종료가 안된다.
  • :wq – 저장 후 종료한다.
  • :q! – 무조건 종료한다. 편집한 내용은 기록되지 않는다.
  • ZZ – 내용을 저장하고 종료한다.

찾기와 바꾸기

  • / – 패턴을 검색할 수 있다. 패턴은 당연히! 정규식을 지원한다. 점점 메모장과는 다른 세상이다.
  • n – 다음 검색 결과로 이동한다. 파일 끝까지 이동했다면 다시 맨 처음 검색 결과로 돌아간다.
  • N – 이전 검색 결과로 이동한다.
  • :%s/old/new – old를 찾아 new로 바꿔준다.
  • :%s/old/new/g – 전체를 검색하여 한 번에 모두 바꾼다.
  • :%s/old/new/gc – 위와 같은데 바꿀 때 마다 물어보게 한다. (c는 confirmation)

도움말 사용하기

vi 나름 잘 문서화된 도움말도 제공하고 있다. 도움말을 실행하는 명령은 :help 이다. 이 명령에는 다른 명령을 붙여 해당 명령의 도움말을 바로 확인할 수 있는 기능도 있다.

  • :help – 도움말을 시작한다. 도움말은 분리된 창의 형태로 보인다.
  • :help :cd – :cd 명령에 대한 도움말을 볼 수 있다.
  • ^] – 도움말내의 각 인덱스는 |01.1 인덱스제목| 과 같은 식으로 표시되는데, 커서를 이곳으로 옮기고 ^] 를 누르면 해당 항목으로 바로 이동한다.
  • ^t – 위에서 이동한 방식으로 문서를 탐색하다가 다시 되돌아가는 기능이다.
  • ^ww : 분리된 창 사이를 이동할 수 있다. (컨트롤 키를 누른 상태로 w키를 두 번 누른다)

간략히 살펴본 바와 같이 vi는 언뜻 처음에 볼 때는 사용하는 사람이 이해가 가지 않는 동작 방식 때문에 적잖이 당황스러울 수 있는데, 역시나 익숙해지려 조금만 노력하면 상당히 강력한 도구가 될 수 있을 것 같다.

vim을 별도로 설치한 경우에는 tutor 모드가 있는데, 이를 실행해서 기본적인 이동이나 편집 방법만 익혀두면 매뉴얼을 일일이 찾아보면서 익히는 것보다 훨씬 더 빠르고 효과적으로 배울 수 있다. (vi를 좀 사용할 일이 있다면 이를 적극 권장함)

끝으로 vi는 도저히 못쓰겠다. 그런데 터미널에서 파일 편집은 할일이 있다… 는 사람들은 nano 를 대신 쓰면 된다. nano는 그나마 비교적 메모장에 가깝게 생긴 프로그램이다. (ctrl+N 등과 같은 방식의 단축키도 지원하고 있고…)

[비평] 어떤 아이폰 개발책 이야기

아이폰의 팬이되면 한 번쯤은 ‘나도 이런 앱 한 번 만들어보고 싶다’는 생각을 한 번 쯤 할 수도 있고, 조금 용기를 내거나 (개발을 위해 mac을 사기 위해서는 보다 큰 용기가 필요할 수 있음) 하여 실제로 앱 개발을 배워보려는 사람도 많이 있더라. 문제는 어디서부터 시작해야 좋을까 하는 점이다. xcode라는 걸로 앱을 만든다는데, 이게 mac에서만 돌아가서 mac을 사야한다더라… 하지만 PC에도 OSX를 설치할 수 있고 어쩌고로 시작해서 많은 이야기들이 있는데 너무나 많은 이야기들이 있다보니 어디서 시작해야 할지, 그게 참 막막할 거다.

애플 개발자 사이트에 가입해보면 자료가 많다고 하는데, 영어의 압박이 너무 심하고해서 네이버를 찾아봐도 딱히 시작하는 시점에서 할 수 있는 건 안보이고, 덜컥 비싼 mac까지 샀다면 점점 마음은 조급해진다. 그래서 이제 서점으로 발길을 돌려 책을 찾아보는데….


여기까지가 비개발자들이 아이폰 개발을 위해 시작하는 단계에서 흔히 하는 잘못 중의 하나이다. 아이폰 개발은 사실 그리 어렵지 않다. 단, 그건 개발자에 한해서이다. 비개발자가 아이폰 앱을 만드는 일은 그리 녹록한 일이 아니다. 아이러니하게도 objective-C는 정말 배우기가 쉬운 언어중의 하나지만, 이 언어를 알고 있는 것과 아이폰 앱을 만드는 일은 완전히 다른 일이라고 봐도 좋다. 심지어 Xcode의 기능을 잘 활용하면 코드 한 줄 작성하지 않고도 만들 수 있는 앱이 실제로도 존재하니 말이다.

그러다보니 “쉽고, 빠르게” 접근하려 책에 욕심을 내게 된다. 하지만 한 두 권 사서보니까, 어째 우리 나라 기술 서적 분야는 비개발자들에게 이렇게 옹색할 수가 없다. 일단 기본적인 개발에 관한 지식이나 프로그래밍 경험, 기본적인 개발언어는 알고 있다고 가정하는 책들이 많다. 그러다보니 책에서 하는 말이 무슨 소린지도 모르겠고… 책에 쓰여진 코드들은 정성들여 똑같이 써보았더니 어떤 건 실행이 되고 또 어떤 건 안된다. 그래서 조금 쉬운책, 조금 더 쉬운책…. 이렇게 책만 (게다가 비싸다. 이건 소설책하고 비교할 수 없다.) 자꾸 사모으게 되는 우를 범하기 쉽다. 게다가 아이폰에 대한 인기가 많아지고 앱을 만들어보려는 사람들이 많아지면서 이런 사람들을 겨냥한 책들이 봇물 터지듯이 쏟아져 나온다.

나 역시 도저히 왜 샀는지 이해할 수 없는 책이 한 권 있다. 모 출판사에서 나온 “도전! 아이폰 4 개발’ 어쩌고 하는 책이다. 이 책은 한 번 사 놓고 약 14페이지 가량 보고 그냥 처박아 두었다. 문득 책장에서 이 책을 발견하고 버려야겠다 생각했는데, 그냥 버리기는 돈이 너무 아까워서 다시 한 번 훑어보고 뭐가 문제인지 좀 살펴보았다.

바로 이 책이다.

가격은 36,000원. 1주일 용돈에 달하는 금액이다. 비싼 가격에 걸맞게 풀컬러로 만들어져있다. 그때문인지 분량은 개발책치고는 좀 적은 편인데, 대부분이 큰~ 아주 큰~ 그림들과 소스코드라서 실제 내용은 별로 없다.

책을 펼치면 올컬러의 화려한 목차와 그외 쓸데 없는 내용들이 많이 나온다. Xcode를 설치할 줄 모르는데 개발을 할까 의문이 들지만, 저자들은 요딴 책들을 몇 번 써본 경험이 있는지 그런 내용들과 Xcode의 스크린샷 여러 장들, 앱스토어에 앱 제출하는 방법, Objective-C 입문이라는 내용들로 초기 100장이 채워진다.

100장이다. 10장이 아니라. 참, 목차만 10장이더라. 지구가 숨쉬는 데 필요한 나무는 안중에도 없다.

어차피 이 책을 봐서는 절대로 앱스토어 제출할 수 있는 수준의 앱을 만들 수 없으므로 앱스토어에 앱을 제출하는 방법을 쓴 이유가 뭔지는 모르겠다. 그냥 쓸 말이 없으면 안써서 책을 가볍게 만들어줘야지 집에 사들고가는 수고라도 덜할 거 아니냐. 그리고 Objective-C에 대한 냉용은 정말 성의없다. 언급 자체가 피곤한 일이니 패스.

그 다음부터는 7개 정도의 예제를 따라 만들도록 하는데, 상당히 문제가 많다. 아까도 이야기했지만 이 책은 쓸데 없는 내용이 정말 많다. 각각의 예제는 다 완성한 앱의 스크린샷이 엄청 많이 들어있고, 디자인 스케치, 앱을 구성하는 UI가 UIButton인지, UILabel인지를 표시하는 그림, 소스 코드를 써 놓은 Xcode를 캡쳐해 놓은 그림.

욕이 나온다.

그림을 넣고 싶다면 간략하게 동작하는 모양의 스크린샷 한 두 장이면 됐다. 그리고 또 넣고 싶다면 최소한 만드려는 앱이 어떤 구조로 되어 있는지 하는 도표도 넣으면 좋지 않은가. 아마 이 책의 저자들은 Omni Graffle을 쓸 줄 몰랐거나, 아니면 일러스트레이터로 쉽게 그릴 수 있는 박스 몇개 그리는 것 조차 귀찮았던 것 같다.

소스 코드의 글자 색상은 그렇게 친절할 거면 Xcode의 하이라이팅과 동일한 색상을 해줬으면 좀 좋아? 따라 쓰면서 오타가 있는지 금방 알 수 있게 말이지.

가장 심각한 문제는 소스코드 부분의 오탈자가 많다. 따라서 “멋진 앱이 나오겠지”라고 생각하고 책을 보고 열심히 타이핑한 고객님들은 Build & Run 만 계속 클릭하면서 하염없이 눈물만 흘릴 우려가 크다.

그리고 애플에서도 가장 중요하다고 강조하는 MVC에 대한 고민이 전혀 없다. 소스도 그다지 잘 정리되지 않고, 심지어 변수나 클래스의 네이밍 역시 가독성 따위는 무시한다. 변수명 쓰는 스타일을 보니까 이 책의 저자들 역시 Objective-C나 UIKit에 그리 많이 알고 있는 것 같지는 않고, 플래시 만드는 사람들이었던 것 같다.

그냥 보여주기 식의 앱들일 뿐이라, 이 책에서 다루는 거의 모든 내용은 책으로 낼만한 내용이 아니다. 대략의 내용들을 훑어보자면

1. 시계 : 시각에 따라 사각형이 생겼다 없어지는 효과를 주는 시계앱이다. 환경 설정하는 부분을 제외하고 동작하는 부분만 만든다고 하면 UIView의 서브클래스만 하나 만들면 된다.

2.관광지 안내 책자를 앱으로 만드는 건데, Xcode4에서는 코드 한 줄 없이 스토리보드로만 구현가능하다. 단, 지도 상에 위치를 표시할 수 있는 기본적인 기능을 ‘쓰고 있는 사실을 알리는’ 수준의 내용이 있다. 그런 기능을 제대로 소개도 안한다.

3. 메모 앱같은 걸 만든다. 이 블로그에 세 번에 걸쳐서 다른 방식으로 메모 앱을 만드는 글을 썼었다. 100페이지가량을 소비하면서 무슨 말이 그렇게 많은지… 물론 대부분의 지면은 메모장 디자인을 만들었다고 이쁘지? 하고 보여주는 내용에 할애된다. 심지어 저장은 SQLtie3으로 한다. 메모를 1만개 이상 작성할 헤비한 유저들에게 어울리나 보다. 참고로 SQLite3는 iOS에서 지극히 느리다. DB파일의 크기가 1메가를 넘기 시작하면 극도로 느려지고 iOS5에서는 더 느리다. 이에 대해 애플은 코어데이터를 쓰라고 권장한다. (SQLite3를 연동하는 가이드는 개발자 센터 내에서 문서를 찾을 수 없게 되었다.)

4. 간단한 트위터 클라이언트라고 거짓말한다. 그냥 Public API로 트윗을 받아와 뿌려주는 내용이 전부다. 사용자 인증 등의 내용을 모두 뺐기 때문에 이 앱으로는 트위터를 할 수 없다.

5. 포스퀘어 앱이란다. 트위터 사기와 동일한 수법이다.

6. Cocos 2d를 써서 게임을 만든다고 한다. 물론 자신들이 신나게 예제를 만든 과정을 소개하고 있을 뿐, cocos 2d에 관심없다면 패스해야 하고, 관심있다면 cocos2d 홈페이지를 참고하라고 하고 있다.

7. 2에서 만든 앱을 아이패드로 만드는 과정을 소개하고 있다.

전체적으로 예제를 따라해보면서 뭔가 배우거나 익히기가 불가능한 구성이다.

 

이 책을 훑어보고 느낀 점을 요약해 보자.

  • 이 책의 저자들은 책으로 누군가에게 앱 개발을 가르칠 수 있는 사람들이 아닌 것 같다.
  • 그러다보니 학교 과제 수준의 앱을 기획하고 , 스케치하고 디자인하는 과정을 지나치게 자세하게 묘사해준다. 돈주고 책 산 사람에게는 책장 넘어가는게 아까울 지경이다.
  • 쓸데없는 곳에 지면을 할애한 결과, 조금이라도 설명이 많이 필요한 기능이나 개념은 “예제니까” 쏙 빼린다. 4번 5번 프로젝트가 그런 예다.
  • 이 책이 나온 시점이 Xcode 4가 나온 시점과 거의 겹친다. 덕분에 책을 보고 xcode를 보면 많이 다르다. Xcode의 개념에 대해 본인들도 이해를 못하니 개념 설명을 할 수가 없고 책을 산 사람들은 Xcode4 책을 따로 사야할 판이다. (정작 저자들은 ‘애플이 너무 부지런해서 탈이다’란 조로 까페에 글을 달았더라.)
  • 앱의 디자인은 그럴싸한데 구현은 비전문가가 만든 것 같다.
  • 그런 구현마저 소스 코드가 실행안되는 문제가 많다. 책을 급조하느라 출판된 책의 코드를 따로 타이핑해보지 않은 것 같다. 이건 개발책을 만드는 사람으로서 기본적으로 독자들에게 지켜야할 예의같은 것이다. 사람들을 개발책을 보면서 다른 곳에 오탈자에 대해서 불평하지 않는다. 하지만 소스코드의 오탈자는 책의 품질을 말하는 척도이다.
  • 대학생들이 앱 공모전에 출품할 때 어떤 과정을 거쳐야할지, 싸이월드나 블로그에 멋지에 보이려면 어떤 식으로 사진을 추려서 연출할지는 도움을 줄 것 같다.
  • 결코 이 책은 앱 개발을 시작하려는 사람에게 어울리지 않는다. 안되는 소스코드를 붙잡고 네이버 지식인에 질문 올리는게 이 책이 말하는 ‘도전’이 아니라면 말이다.
  • 이 책에서 설명하는 예제 수준의 앱을(이정도는 구글링만 좀 해보면 튜토리얼이 널렸다.)  한 두 개 만들어본 사람이라면, 이미 이 책의 수준을 넘어섰을테니 필요없다. 컬러라서 냄비 받침 하기도 좀 그렇다.
  • 이미 이런 불평불만이 네이버 까페에 넘치고 있다.

그러면 도대체 개발자도 아닌 사람들은 아이폰 앱을 만들지도 못하고 이런 책에 사기 당해야 하는 것일까? 그래서 다음 글에서는 어디서 시작하면 좋을지에 대해서 좀 이야기해 보고자 한다.

편의점도 갈 겸, 책이나 버리고 와야겠다.

[잡담] 웹앱은 무엇을 위한 대안인가

아이폰의 국내 도입이후에 비로소 모바일웹에 대한 폭발적인 관심이 일어났던 것은 이미 모두가 알고 있는 사실이니 긴 말하지 않아도 될 것 같다. 당시 웹 기술은 거의 브라우저에 대한 것들이 많았다. 해묵은 IE에 병적으로 집착하는 대다수 사용자들과 이른바 모던 브라우저라고 하는 새로운 브라우저간의 싸움만 지겹도록 반복될 뿐이었다. 이미 HTML4 규격은 10년이 넘어가는 시점이었고 이 때문에 웹표준을 제정하는 W3C에 대해서도 불만들이 많았다.

어쨌거나 이 모바일 웹에서 시작된 붐은 모바일이 되었든, 데스크톱이 되었든 그 플랫폼을 가리지 않고 웹 표준이라든지 최신 브라우저에 대한 관심을 새로운 국면으로 접어들게 하는 큰 한 방이 될 수 있었던 것이다. 웹 표준 준수나 비 IE 환경을 지원하는 것에 대해 인색했던 국내 포털들은 폭발적으로 증가하는 모바일 트래픽에 깜짝 놀라 부랴부랴 모바일 웹에 대한 지원을 서둘렀고 그에 따라 웹킷이나 게코 엔진에서 잘 동작하는 웹 페이지들이 하나 둘 늘어나기 시작했다.

그리고 덕분에 비 IE 사용자들은 데스크톱 버전의 페이지를 사용하기보다는 더 가볍고, 그들이 사용하는 브라우저에 더 잘 맞는 모바일용 웹 페이지를 데스크톱에서도 즐겨쓰게 되는 역전 현상도 많이 일었다. (…라고 썼지만 그리 붐은 일지 않았다.)

어쨌든 그 즈음에 우리나라나 외국이나 할 것 없이, 웹 플랫폼을 사용하여 앱을 만드는 일에 대해 포탈들은 관심을 갖기 시작한다. 그도 그럴 것이 스마트폰 사용자는 계속해서 엄청나게 증가하는데, 이들을 위해 포탈의 서비스를 앱으로 제공할 필요가 있었기 때문이다. 물론 이런 앱을 통한 유입보다는 모바일 웹 브라우저를 통한 유입이 더욱 의미가 있던 포탈에서는 “웹 앱”을 밀고 나서고자 하는 그런 움직임들이 있었고, 당시에 유행처럼 일어나던 모바일 트렌드 컨퍼런스에서는 주로 이런 포탈에서 일하는 분들이 웹 앱의 가능성에 대해 거의 약 파는 수준으로 설파하고 다니기도 했다.

때마침, W3C의 굼뜬 행보를 참다참다 참을 수 없었던 브라우저 제작사들은 HTML5에 대한 논의를 먼저 시작한다. 그러니가 대략의 아웃라인에 대해 브라우저 제작사들이 먼저 기술적으로 구현을 하고 그에 맞춰서 웹 표준을 정하든가 말든가하는 그런 움직임들이 일어나는 것이다. 웹 브라우저에서 충분히 풍부한 미디어나 상호작용을 다룰 수 있도록 하여, 웹 브라우저 자체가 앱이 돌아가는 플랫폼이 되도록 하고, 웹 서비스들은 더 이상 ‘문서’로 취급되지 않고 ‘앱’으로 발전해 나가는 움직임이 시작된 것이다.

이런 움직임은 예상보다 아주 빨리 가시적인 성과를 보이면서 이미 구글 크롬 웹 스토어는 널리 영업중에 있고, 모질라 재단에서도 파이어폭스를 위한 웹 스토어를 준비중에 있는 것으로 알고 있다.

그래서 모바일 웹 앱도 탄력을 받아서 엄청 발전을 했느냐? 글쎄 그 점이 문제라면 문제이다. 사실 HTML5 를 생각하지 않고서라도 (그러니까 웹 페이지에서 동영상을 재생하는 등의 고급 미디어 기능을 빼고) 이미지와 텍스트로 정보를 제공하면서 앱과 비슷한(?) 사용자 경험을 제공하는 일은 기존의 웹 기술로도 어느 정도 가능한 것은 사실이고, 이미 이렇게 상용화한 앱이 한 두 개가 아니다. 웹 앱을 밀고 있던 진영에서는 특히 안드로이드 계열 스마트폰의 폼팩터 단편화 (안드로이드 폰들의 제각각 스펙은 이미 초창기부터 서비스 제공자들에게는 골칫덩이였음에 분명하다) 를 극복하는 방법으로 웹 앱이 딱이라며 웹 앱으로 가야한다고 이야기했다. 이는 일견 맞는 말이기도 하다. 그런데 이들이 말하던 웹 앱의 단점은 “네이티브 앱에 비해 UI의 미려함이 떨어진다”는 것이었는데, 그게 과연 단지 “미려한 UI”에 국한될 문제일까하는 점에 의심을 품지 않을 수 없다.

문제는 상호작용이고 이는 사용자 만족도의 척도이다

모바일 플랫폼의 성격을 대표하는 말 중에 하나는 바로 ‘손안에 XX’라는 것이다. 폰 자체가 손바닥 보다 작기 (*최근 나온 일부 모델 제외) 때문에 손 안에서 모든 정보가 조작되는다는 의미도 있지만, 실제로 손가락이 닿아서 동작하는 앱들이기 때문에 이러한 감성적인 측면에서의 접근은 적지 않은 의미를 가진다고 본다. 즉, 사용자의 터치 제스처에 적절히 반응해야 한다는 점이 모바일 기기에서 돌아가는 서비스 (그것이 앱이든 웹이든)에서는 “사용자 경험에 대한 만족도”의 가장 핵심이 되는 부분이다. 따라서 단지 화려한 화면 전환 효과만이 웹 앱이 제공할 수 없는 ‘소소한’ 부분이라고 치부할 수 없다.

결국 웹 앱은 정확히는 스마트폰을 플랫폼으로 하는 것이 아니라 스마트폰 용 모바일 브라우저를 플랫폼으로 하는데, 그 때문에 치명적인 한계를 가지게 된다. 첫째로 사용자와 직접적으로 접점을 이루는 인터페이스는 모바일 브라우저가 제공하는 사용자 이벤트이다. 즉 마우스 클릭에 해당하는 탭, 그리고 “실질적인 상호작용”을 할 수 없는 쓸기와 벌리기가 모두 인 것이다. 아직까지 멀티터치 제스처를 제대로 지원하는 모바일 브라우저는 없는 실정이고, 그나마 유연하게 확대/축소나 관성 스크롤은 되고 있지만 이건 웹 앱이 지원하는 기능이 아니라 모바일 브라우저의 인터페이스일 뿐인 것이다.

덕분에 모바일 웹 앱들은 사용자의 손가락을 따라 정확하게 반응할 수 없고, 쓸기나 두 손가락으로 벌리기는 사용자가 손가락을 움직이는 동안에는 아무 일도 할 수 없으며, 제스쳐가 끝난 뒤에야 “아 사용자가 방금 손가락으로 쓸기를 했어”, “사용자가 방금 두 손가락을 벌렸어” 정도의 뒤늦은 이벤트만 알아차릴 수 있는 것이다. (이는 태블릿으로 다음 지도를 접속해서 두 손가락으로 확대/축소해보면 쉽게 느낄 수 있다. 그냥 내가 멍청이가 되는 그런 느낌이다.)

두 번째로 하드웨어에서의 부하가 너무 크다. 같은 기능, 같은 효과를 만들기 위해 이미 스마트폰은 웹 브라우저를 띄우고 있는 상태에서 시작해야 한다. 그리고 사용자의 요청을 웹 브라우저는 부지런히 웹 앱에 전달해야 하고, 웹 앱은 자바스크립트로 이에 반응해야 한다. 따라서 너무 무겁다. 똑같은 기능을 제공하는 웹 앱과 네이티브 앱이 있을 때, 이 버벅임은 품질에 너무나 큰 차이를 가져다 준다.

세 번째로 UI를 그리기 위해 필요한 자원 역시 매 페이지를 불러올 때 가져와야 한다. 페이지를 만드는 데 필요한 정보가 네이티브 앱보다 월등히 많기 때문에 웹 앱의 화면 전환은 필연적으로 느릴 수 밖에 없다. 그리고 사용자가 지루해 하는 틈을 노리는 꼼수를 부릴 수 있는 여지도 그만큼 적다.

네번째로 웹 앱을 지지하는 진영에서 말하는 “다양한 폼팩터에 구애 받지 않는 구현”도 그리 구애를 적게 받는 것은 아니라는 것이다. 물론 서비스 제공자 입장에서는 엄청나게 많은 버전의 똑같은 앱을 만들어 내는 것은 쉽지가 않을 것이다. 하지만 이를 웹앱으로 만드는 것 역시 그리 녹록치 않은 일임에는 틀림없다. 스마트폰의 화면 크기나 해상도는 역시 저마다 각각 다른데, 이를 ‘적절히 맞추어 주는’ 디자인은 가능은 하나 어렵고, 모든 요구를 다 맞추기 힘들기 때문에 어떤 면에서는 포기를 해야 한다. 그런 면에서 ‘품질’은 계속 떨어지기 마련이다.

트위터와 페이스북, 애플 그리고 Path

트위터와 페이스북은 최근 앱 업데이트를 단행하면서 한 가지 치명적인 실수를 저질렀다. 바로 웹 앱으로의 전환이다. 물론 100% 웹 앱은 아니고 네이티브 앱 내에서 웹뷰를 사용하여 화면 UI를 웹을 통해 그려주고 있다. (이는 페이스북 앱에서 담벼락 글을 지우기 위해 손가락으로 쓸어보면 알 수 있다. 통상적인 테이블 뷰와 달리 손가락을 떼고 나서야 버튼이 표시된다.) 덕분에 엄청 반응이 느리고, 사소한 동작이나 사용자의 쓸데 없는 터치 때문에 기껏 공들여(!) 불러온 화면이 하얗게 변하면서 리프레시 된다.

서비스의 UX에 있어서 최고점을 보여주는 애플도 이 측면에서는 그리 잘 해내지 못하고 있다.애플의 앱스토어 앱도 웹 뷰로 구현되어 있다. 덕분에, 역시나 엄청나게 느리다. 심지어 목록에서 앱 상세 정보로 들어간 다음 다시 밖으로 나오면 처음부터 다시 스크롤하고 목록을 추가적으로 불러와야 한다. 엄청나게 짜증나는 일이 아닐 수 없다. 비슷비슷한 앱이 많은 앱 스토어에서 쓸만한 앱을 찾기 위해 상세 화면을 들락여야 하는 상황이라면 상당한 인내심을 가져야 한다. (아 진짜 제발 이거 좀 개선해라 ㅠㅠ 앱 깔자고 맥 켜야 하는 상황이 유쾌하지는 않잖아.)

물론 앞으로 스마트폰의 메모리 사정이나 프로세서 성능등이 점차 좋아지고, (역시 국내에서는 요원하기만 하다만) 무선 네트워크 상황이 좀 더 좋아진다면 이러한 문제는 현재의 일시적인 것으로 여길 수도 있다. 하지만 Path가 보여준 네이티브 앱만이 제공할 수 있는 UX의 장점들을 볼 때 트위터나 페이스북의 공식 앱은 그저 “겨우 보여주기에 급급하다”라는 느낌을 지우기가 힘들다.

웹 표준화 진영에서 내걸던 “One Web”이라는 구호가 기묘하게 변경되어 모바일 앱에 적용되고 있는 현실이 못내 씁쓸하다. 여기저기서 아직도 “N-Screen”이라는 말을 남발하면서 왜 “같은 화면을 보여주는 것”을 자랑하나. 통합되어야 하는 건 화면에 보이는 디자인이 아니라 총체적인 사용자 경험이어야 한다.

아, 이딴 글이나 적고 앉아있자니 괜시리 아이폰5가 기다려지는 그런 날이다. 날씨도 괜히 꿀꿀하다.

 

[OSX] Defaults 명령 사용법

OSX의 시스템 환경 설정이나 기타 앱의 환경 설정은 사실 허무하리만치 간단해서 설정을 바꿀 수 있는 부분이 제한되어 있다. 이는 애플의 UI 정책도 한 몫하고 있지만 사실 OSX와 여러 맥용 앱은 그보다 더 많은 기능들을 내장하고 있는 것이 사실이다. 이런 설정은 defaults라는 터미널 명령을 사용하여 변경할 수 있는데, 아무래도 터미널 자체가 좀 무서운(?) 물건이다보니 초보자들이 다가가기에는 쉽지 않은 것이 사실이다.

이 글에서는 OSX의 각종 환경 설정을 손 볼 수 있는 defaults 명령에 대해서 알아보도록 한다.

defaults 사용법

문법

defaults 명령의 주요 패턴은 다음과 같다. ( 대괄호로 둘러싸인 부분은 넣어도되고 빼도 되는 부분이다)

defaults [호스트] 액션 [도메인] [-타입] [값]

호스트는 시스템을 의미하는데 원격 시스템에 대한 설정을 이 명령으로 바꿀 수 있다. 기본적으로는 현재 로그인한 currentHost의 설정을 바꾼다고 보면 된다.

액션

환경설정 내용에 대해 어떤 동작을 취할 것인지를 결정한다.read, read-type, write, delete로 읽고 쓰고 지울 수 있으며, find 액션으로 전체 환경 설정 내용 중에서 특정한 키나 값을 찾는 것도 가능하다.

  • read 도메인 [키] : 지정한 도메인 혹은 도메인 내의 키의 값을 출력한다.
  • read-type 도메인 키 : 지정한 키의 값의 유형을 알아낸다.
  • write 도메인 키 [타입] 값 : 지정한 키를 지정한 값으로 쓴다.
  • rename 도메인 예전이름 새이름 : 지정한 도메인 내의 예전이름의 키를 새 이름으로 이름을 바꾼다.
  • delete 도메인 [키] : 특정한 도메인 내의 키 혹은 도메인 전체의 설정 내용을 삭제한다. (주의 : 도메인 이름까지만 입력하고 엔터치면 전체 설정이 홀랑 날아간다. 단, 이렇게 내용을 날려버리면 해당 앱을 실행하면 초기 값으로 복원되니 참고할 것)
  • domins : 전체 도메인 목록을 출력한다.
  • find [찾을 단어] :  환경 설정 내용에서 특정 단어를 검색한다.

도메인

도메인은 어떤 것과 관련된 환경 설정인지에 대한 범위를 지정한다. 인터넷 도메인주소와 반대방향으로 com.회사이름.앱이름 의 순으로 연결된다. 파인더의 환경 설정에 접근하고자 한다면 com.apple.finder 라고 도메인을 지정하면 된다. 또한 -g  옵션을 쓸 수 있는데 이는 NSGlobalDomain과 같은 뜻으로 전체 앱에 공통으로 적용되는 설정을 의미한다.

키는 환경 설정 데이터 내에서 특정한 기능과 관련되는 데이터를 가리키는 이름이다. 예를 들어 파인더에서 숨김 파일을 표시할 것인지의 여부를 결정하는 부분이 있는데, 이 부분을 가리키는 키가 바로 AppleShowAllFiles 이다. 키는 대소문자를 구분한다.

키는 응용 프로그램에서 어떤 동작을 어떻게 처리할 것인지를 결정할 때 참고하는 값이고, 따라서 이미 응용 프로그램을 만들 때 정의되어 있는 내용이다. 사용자가 임의의 키를 만드는 것은 가능하지만 그것이 응용 프로그램 동작에는 당연히 반응하지 않을 수 있다.

타입

도메인 내에 각 키는 값의 타입을 가진다. 예를 들어 2라는 숫자가 있을 때 이 것이 2라는 정수값을 의미할 수도 있고, 그냥 “2″라는 글자로서의 숫자를 의미할 수도 있다. 이는 완전히 다른 개념이고, 특정한 키는 그에 상응하는 타입을 가지고 있다.

타입을 지정할 때에는 타입명 앞에 – (하이픈/ 빼기기호)을 넣는다. 또한 타입이 생략되면 defaults는 이 값의 유형이 ‘문자열’이라고 인식한다.

타입에는 다음과 같은 것들이 있다.

  • -int : 정수
  • -float : 소수점이 있는 실수
  • -bool : YES or NO
  • -string : 문자열
  • -array : 여러 값이 집합으로 구성된 배열. ‘{ 값1 값2 값3 …;}’ 과 같은 식으로 쓴다.
  • -array-add : 배열을 값으로 갖는 키에 기존 배열에 추가하여 값을 더 넣을 때 사용하는 타입
  • -dict : 키-값 쌍으로 이루어진 사전 데이터.’{ 키1 값1 키2 값2 ;}’ 와 같은 식으로 쓴다.
  • -dict-add : -array-add 와 비슷하게 동작함

값은 키에 대응되는 값 자체를 말한다.

변경의 적용

앱이 실행 중인 상태에서 환경 설정 값을 변경하는 것은 보통 바로 적용되지 않는다. (보통은 앱이 처음 실행될 때 환경 설정을 한 번만 읽어들이도록 만들어지기 때문이다.) 따라서 Dock이나 Finder와 같이 항상 실행되는 앱은 터미널에서 강제 종료하여 재시작하면 변경 사항을 적용시킬 수 있다. 그외 특정 환경 설정은 로그온 시에 읽어들이므로 그런 경우에는 로그오프 후 다시 로그온 하거나 재부팅하면 적용된다.

예제

파인더에서 숨김 파일을 보기 위해서는 숨김 파일 표시와 관련된 키 값을 설정해주면 된다. 이 키는 AppleShowAllFiles 이며 타입은 -bool 타입이다. 따라서 다음과 같이 변경할 수 있다.

$ defaults write com.apple.finder AppleShowAllFiles -bool YES

이 변경 사항을 적용하려면 파인더를 강제로 재시작한다.

$ killall Finder

위 두 명령은 세미콜론으로 붙여 한 줄에 쓸 수도 있다.

$ defaults write com.apple.finder AppleShowAllFiles -bool YES; killall Finder

환경 설정 파일

이런 앱들의 환경설정은 주로 ~/Library/Preferences 폴더에 각 도메인 별로 파일로 저장된다. 예를들어, 파인더의 사용자별 환경 설정은 사용자의 ~/Library/Preferences/com.apple.finder.plist 라는 파일로 기록된다. 이 파일을 보기 위해서는 파인더에서 메뉴 > 이동 > 폴더로 이동… 을 선택한 다음  ~/Library 라고 입력하고 Preferences 폴더 속을 뒤져보면 된다.

실제로 파인더의 환경 설정 패널을 열고 값을 바꾸면 해당 내용이 이 파일에 기록된다. defaults 명령은 이 plist 파일을 직접 수정하도록 하는 명령이다.