위키트리에 구글 크롬 익스텐션까지 설치해가시면서 바꾸는 방법이 소개되어 있던데… 그냥 간단하게 크롬, 파이어폭스, 사파리 등 모든 브라우저에서 적용하는 방법
javascript:document.cookie="PREF=ID=03fd476a699d6487:U=88e8716486ff1e5d:FF=0:LD=en:CR=2:TM=1322688084:LM=1322688085:S=McEsyvcXKMiVfGds; path=/;domain=.google.com";window.location.reload();
위 코드를 긁어서 (더블 클릭하면 전체 선택이 됨) 복사한 다음, 구글 홈페이지로 가서 주소창에 붙여 넣고 엔터.
많은 튜토리얼에서 간단한 아이폰 앱을 만드는 방법을 설명하고 있는데, 이런 튜토리얼을 따라서 이것 저것 만들어 보는 것 또한 재미도 있고, 또 여러가지 테크닉을 익힐 수 있지만 정작 활용이 가능한 앱을 만드는 것은 쉽지 않다. 이 글 (과 아마도 이어질 글들)에서는 메모장과 같이 간단히 입력한 텍스트를 저장하는 앱을 만들어 보는 것을 함께 알아보고자 한다. 혼자 삽질과 염탐(?)을 거듭하여 알아낸 내용들을 정리하는 차원이기도 하니 아주 자세하게는 아니지만 소상히 쓰려고 노력할 것이다.
iOS 앱이 어떤 데이터를 영구적으로 보관하는 방법에는 사실 여러가지가 있는데 대략 다음과 같은 방법들이 있다.
코어데이터는 데이터를 저장소에 읽고 쓰고 또 관리하는 전반적인 기능을 제공하는 프레임워크이다. 코어데이터는 저장 방법을 아카이브 또는 데이터베이스(SQLite)로 사용할 수 있고, 변경 사항을 쉽게 추적하여 저장하고 또 저장된 객체를 불러와서 자동으로 관리해주는 다양한 기능들을 제공한다. 이를 잘 사용하면 엄청나게 많은 양의 코드를 손쉽게 줄일 수도 있다. 하지만 이 프레임워크는 결정적으로 초보자가 사용하기에는 조금 어렵다. 코어데이터 프레임워크 자체의 개념 자체가 초보자에게는 낯설기 때문이나, 실질적으로 예제를 만들어보면 허무할만큼이나 간단하게 데이터를 처리해준다. 예를 들어 사용자가 편집한 변경사항을 자동으로 기록한다거나 하는 것들을 지원한다.
코어데이터는 OSX용 앱을 제작할 때 코코아 바인딩과 결합하면 “한 줄의 코드도 작성하지 않고” 데이터를 불러오고 편집하고 저장하는 앱을 만드는 것이 가능할 정도의 모든 기능을 제공해주므로 시간이 될 때 꼭 공부해볼 것을 권장하며, 이 연재의 마지막에는 코어데이터를 사용하여 메모앱을 작성하는 방법을 살펴볼 것이다.
SQLite는 아이폰에도 내장되어 있는 경량 데이터베이스 엔진이다. 개인적으로는 초보자에게 차라리 코코아 프레임워크를 권하고 싶다. 코코아터치에 포함되어 있는 SQLite3 프레임워크는 대부분 C 형식의 함수를 사용하고 있고 데이터 입출력시에는 일일이 쿼리 문을 작성해야 하므로 SQL에 대한 지식도 알고 있어야 하는 데 난점이 있다. 단, 사전이나 레퍼런스와 같은 형태의 앱을 작성할 때 미리 자료를 정제하여 DB 형태로 만들기가 쉬우므로 이 경우에는 SQLite를 쓰는 것이 좋을 수도 있다.
아카이빙 역시 초보자들에게는 조금 어려운 개념일 수 있으나, 대부분의 표준 코코아터치 클래스들은 스스로를 인코딩하는 방법을 알고 있기 때문에 의외로 손쉽게 접근할 수 있는 방법이나, SQLite에 밀려서 많이 쓰이고 있지 않다. 이 연재에서 우선적으로 다뤄볼 기법이기도 하다.
프로퍼티 리스트는 일종의 XML의 포맷으로 키-값 의 짝을 기록하는 방법이다. 이 방법으로 생성된 데이터는 별도의 프로그램 없이 사람이 확인할 수 있다는 장점이 있다. 하지만 나는 잘 모르므로 패스하겠다.
아카이빙은 앱이 실행될 때 서로 서로 관계를 맺고 있는 객체들을 직렬화하여 데이터 스트림으로 만드는 기법이다. 이 데이터 스트림을 파일에 저장하고 또 읽어 들이는 방법으로 사용자 데이터를 보존할 수 있다.
다행히도 많은 표준 코코아터치 클래스들은 스스로를 아카이빙하는 방법을 알고 있다. 이러한 객체들은 NSCoding 프로토콜을 따르는데, 이 프로토콜을 따르는 객체는 스스로를 아카이빙하면서 자신과 연관을 맺고 있는 모든 객체에 대해 아카이빙하라는 메시지를 보낸다. 따라서 우리는 각각의 객체가 NSCoding 프로토콜을 따르도록하고 루트 객체를 아카이빙하면 필요한 모든 객체를 아카이빙할 수 있게 된다. (이와 관련해서는 나중에 다시 살펴볼 계획이다.) 이 방식의 강점은 여러 객체를 저장하기 위해서는 이를 단순히 배열에 담고 그 배열 객체를 한 번만 아카이빙하면 마치 전염병처럼 메시지가 번져나가 모든 객체를 아카이빙 할 수 있다는 것이다. 또한 단순한 값이 아닌 바이너리 데이터도 파일에 함께 그대로 저장할 수 있다는 강점이 있다.
객체를 아카이빙하기 위해서는 NSCoder 클래스를 사용한다. 하지만 NSCoder는 추상 클래스로 프로그래머가 직접 NSCoder 클래스의 인스턴스를 만드는 일은 거의 없다, 대신에 이 클래스에서 구체화된 NSKeyedArchiver 나 NSKeyedUnarchiver 클래스를 사용한다.
이 모든 이야기는 예제를 통해 확인하면 보다 쉽게 이해될 수 있다. Xcode에서 새로운 프로젝트를 만든다. 프로젝트 이름이야 다들 알아서 하시고 iOS Application에서 single view 기반의 프로젝트를 생성하자. 이는 Xcode의 버전에 따라서는 window-based 앱일 수도 있다.
프로젝트가 생성되면 스토리보드 (혹은 MainWindow) 파일이 있는데 여기에 텍스트뷰를 하나 집어 넣고 사용자가 내용을 입력할 수 있도록 속성창에서 editable에 체크를 해 준다. 또한 저장하는 액션을 호출하기 위한 버튼도 하나 달아준다. 버튼은 텍스트뷰 위에 달아도 되고 아래에 달아도 된다. 디자인은 각자 알아서 하면 될 거 같다.
이제 RootViewController.h 에는 다음의 내용에 다음 코드를 추가하자
#import <UIKit/UIKit.h>
@interface RootViewController : UIViewController
{
NSString *dataFilePath;
}
@property (nonatomic, strong) IBOutlet UITextView *memo;
-(IBAction)saveData:(id)sender;
@end
dataFilePath는 데이터를 저장할 파일의 경로를 담는 변수가 될 것이며, memo는 인터페이스 빌더에서 추가한 텍스트뷰의 아울렛이다. 파일을 저장하고 인터페이스 빌더에서 해당 텍스트뷰에 아울렛을 지정해 준다. (지정이 끝나면 nib 파일을 꼭 저장하라)
이제 이 클래스의 구현부이다. 프로퍼티를 선언했으니 맨 먼저 해줘야 하는 일이 있겠지… @implementation RootViewController 라고 써 있는 줄 바로 아래에 다음 문장을 추가한다.
@synthesize memo;
다음은 앱이 실행되어 뷰가 로드되었을 때 바로 파일을 저장할 경로를 준비해두는 작업을 해보자. viewDidLoad 매서드를 찾아 다음 코드를 추가한다.
NSString *docsDir; NSArray *dirPaths; dirPaths = NSSearchPathForDirectoriesInDomains(NSDocumentDirectory , NSUserDomainMask, YES); docsDir = [dirPaths objectAtIndex:0]; dataFilePath = [[NSString alloc] initWithString:[docsDir stringByAppendingPathComponent:@"data.archive"]];
먼저 이 구문은 그냥 그대로 쓰는 거라고 외워두면 될 정도이다. 맨 마지막 줄의 파일 이름은 꼭 data.archive로 할 필요 없고 취향에 맞게 쓰면 된다. 이 코드는 앱의 하위 디렉토리 중에서 사용자 데이터 파일이 저장되는 Documents 디렉터리를 찾고 이 속에 파일이 저장될거라고 미리 파일의 경로를 생성해 두었다는 정도가 된다. 다행히 NSString은 파일 경로를 쉽게 다룰 수 있는 메서드를 이미 가지고 있으니 천만다행.
이제 실제 저장되는 부분을 보도록 하자.
-(IBAction)saveData:(id)sender
{
[NSKeyedArchiver archiveRootObject:[memo text] toFile:dataFilePath];
}
좀 허무하리 만치 간단하지 않은가? NSKeyedArchiver 객체가 저장할 데이터를 아카이빙하고 파일에 저장하는 작업을 모두 처리해 준다.
이제 다시 인터페이스 빌더에서 저장 버튼을 뷰컨트롤러의 saveData 메서드에 연결해준다.
뭔가 한가지 빠진게 있는데, 저장은 했다손 치더라도 그럼 앱이 다시 열렸을 때 저장된 내용을 복원해줘야 제맛 아니겠는가. 지금은 저장만 처리했지 데이터를 읽어오는 내용은 처리하지 않았다. 그럼 다시 RootViewController.m 에서 viewDidLoad 메서드의 끝 부분에 로딩에 관련된 코드를 추가하자.
로딩과 관련해서는 다음의 액션을 취한다.
코드는 다음과 같다.파일을 처리하기 위해서 NSFileManager를 사용한다.
// viewDidLoad의 마지막부분
NSFileManager *fileManager = [NSFileManager defaultManager];
if( [fileManager fileExistsAtPath:dataFilePath])
{
NSString *memoData = [NSKeyedUnarchiver unarchiveObjectWithFile:dataFilePath];
memo.text = memoData;
}
사실 여기까지하면 끝인데, 한 가지만 더 추가하자. 만약 텍스트 뷰 아래에 저장 버튼을 추가했다면, 키보드가 올라오는 바람에 저장 버튼을 누를 수 없는 경우가 있을 수 있는데, 뷰의 배경을 클릭해서 키보드를 닫도록 하자. 역시 뷰컨트롤러의 구현부에 추가한다.
-(void)touchesBegan:(NSSet *)touches withEvent:(UIEvent *)event
{
if( [memo isFirstResponder] ){
[memo resignFirstResponder];
}
}
끝이다. 빌드하고 실행해본다. 에뮬레이터에서 앱을 종료한 후 다시 실행해보아도 입력했던 내용이 여전히 남아 있는 것을 확인할 수 있을 것이다.
그런데 이 예제만 만들고 나면 왠지 좀 속는 기분이 든다. 만약 뷰에서 다루는 데이터가 여러 종류이고, 이를 함께 저장하려면 어떻게 하는가? 그럼 이 메모장에서 제목란을 추가해서 한 번 수정해 보도록 하자.
인터페이스 빌더에서 루트 뷰 컨트롤러의 텍스트 뷰 크기를 좀 조정해서 빈칸을 만든 다음, 여기에 텍스트 필드를 하나 추가한다. 그리고 뷰컨트롤러의 헤더에 이 텍스트 필드에 대한 아울렛을 지정하는 코드를 만들자.
@property (nonatomic, strong) IBOutlet UITextField *title;
헤더 파일을 저장한 다음, 인터페이스 빌더에서 이 아울렛을 실제 텍스트 필드와 연결한 후 저장한다. 다시 구현부로 간다. 추가한 property에 대해 synthesize 구문을 추가해준다.
@synthesize title;
이제 saveData 메서드를 바꾼다. title과 memo의 내용을 한 번에 저장할 것이기 때문에 NSString을 아카이빙하는 것이 아니라 NSDictionary로 만들어서 저장한다.
-(IBAction)saveData:(id)sender
{
NSMutableDictionary *dataDictionary = [[NSMutableDictionary alloc]
initWithObjectsAndKeys:title.text,@"title",memo.text,@"memo", nil];
[NSKeyedArchiver archiveRootObject:dataDictionary toFile:dataFilePath];
}
저장하는 방법을 바꿨으니, 불러오는 방법도 바꿔야겠지. viewDidLoad 의 마지막 부분을 아래와 같이 바꾸면 된다. NSKeyedUnarchiver를 사용하여 NSDictionary를 복원한다음, 각 키 값을 사용하여 title, memo의 내용을 복원해주면 된다.
if([filemanager fileExistsAtPath:dataFilePath])
{
NSDictionary *dataDictionary;
dataDictionary = [NSKeyedUnarchiver unarchiveObjectWithFile:dataFilePath];
memo.text = [dataDictionary objectForKey:@"memo"];
title.text = [dataDictionary objectForKey:@"title"];
}
자, 이래도 아카이빙이 어려운가? 다음 글에서는 메모 한 개가 아니라 여러 개를 만들 수 있는 앱을 어떻게 만들 것인지 알아보도록 하겠다. 긴 글 읽으시느라 고생많았다.
라이언에서 새롭게 등장한 런치패드(Launch Pad)는 마치 OSX을 아이패드와 같이 사용할 수 있도록 해주는 상당히 재밌는 녀석임에는 틀림없다. 물론 적응하기 따라서 다를 수 있겠는데, 기존의 OSX 사용자들 모두가 이 기능을 멋지다고 평가하지는 않는 듯 하다. 아무튼 멀티터치 제스쳐와 연동하여 사용하는 재미도 쏠쏠하고 좀 익숙해지면 상당히 편리하게 사용할 수 있다는 장점도 있다.
그런데 간혹, 특히 맥을 완전히 껐다가 다시 부팅하는 경우에 간혹 “정성스럽게” 순서를 맞춰놓은 런치패드 앱 아이콘이 자기 멋대로 정렬이 엉키는 문제는 정말 당혹스럽기도 하다. (물론 왠만하면 맥은 전원을 완전히 내릴 경우가 별로 없기 때문에, 이런 경우를 자주 경험하지는 않지만) 또한 Dock을 아주 심플한 상태로 유지하고 런치패드를 자주 쓰는 앱을 실행하는 도구로 사용하는 경우라면 이 곳에서 사라지지 않는 아이콘들도 참 짜증날 수 있다.
그래서 런치패드의 아이콘을 재구성하는 방법을 소개한다. 이 방법을 통해 아이콘을 재구성한 다음에는 앱 아이콘 정렬이 엉키는 문제도 해소가 되었다. (런치패드에서의 이 문제의 원인은 나도 알 수가 없으니 제대로된 해결책인지에 대해서는 자신이 없지만, 적어도 나는 그랬다.)
런치패드에 등록된 앱을 구성하는 정보는 SQLite라고 하는 경량 데이터베이스에 의해 관리된다. 그리고 이 정보는 Dock의 개인 설정 폴더에 db 파일로 만들어져 있다. 우리가 하고자 하는 일은 이 정보를 깨끗이 비운 다음, 앱 아이콘을 새롭게 등록하는 것이다.
터미널을 실행한다음, Dock의 런치패드 설정 정보 폴더로 이동한다. 이 폴더의 위치는 ~/Library/Application\ Support/Dock 이다.
$cd ~/Library/Application\ Support/Dock
(App 까지 입력하고 tab 키를 누르면 이후 부분이 자동으로 완성되고 Dock 만 추가하면 된다)
이제 기존 내용을 백업해 둔다. 먼저 ls 를 해서 어떤 파일이 있는지 본다.
$ls
그럼 숫자와 문자가 혼합된 복잡한 이름의 긴 DB 파일이 하나 보인다. 이 파일을 백업해 둔다. 이 파일은 사실 없어도 문제가 안되니까 굳이 백업하지 않아도 된다. 참고로 원래 이름은 길지만 앞에 한 두 글자만 입력한 다음 tab키를 누르면 자동완성해주니까 겁먹지 말자.
$cp {원래 이름}.db {원래 이름}.db_backup
이제 SQLite를 사용해서 앱 아이콘 정보를 싹 지운다. OSX에서 기본제공하는 sqlite3라는 DB 프로그램을 사용한다. 따옴표 안의 내용을 잘 입력하자.
$sqlite3 {원래이름}.db ‘DELETE FROM apps;’
이제 변경 사항을 다시 적용하기 위해서 Dock을 재실행한다. (Dock은 죽으면 자동으로 재시작하므로, 프로세스를 죽이면 된다.)
$killall Dock
여기까지 하고 런치패드로 돌아와보면, 모든 앱의 아이콘이 말끔하게 비워져 있다. 몇몇 폴더는 빈 채로 남아있다. 이제 런치패드에 원하는 프로그램의 앱을 추가하면 된다. 만약 저 빈 폴더들을 없애고 싶다면 다른 앱들을 추가하면서 그 폴더에 앱을 집어 넣었다가 다시 빼면 폴더는 정상적으로 사라지니 너무 걱정하지 말자.
런치패드에 앱 아이콘을 추가하려면 우선 Dock에 런치패드 앱을 올려두어야 한다. 런치패드 앱을 비롯한 거의 모든 앱의 아이콘은 Application 폴더에 있으므로 이 곳에서 런치패드를 Dock으로 끌어다 놓자.
그런다음 Application 폴더에서 런치패드에 추가하고 싶은 앱들을 하나씩 Dock에 있는 런치패드 아이콘으로 끌어다 놓으면 하나씩 하나씩 추가가 가능하다. Finder에서 응용프로그램 폴더를 들어가서 원하는 앱들을 모두 선택해서 끌어다 놓아도 되고, 유틸리티 폴더와 같이 폴더를 통째로 끌어다 놓아도 된다. 참고로 응용프로그램폴더가 아닌 곳에 설치된 앱도 런치패드 앱으로 아이콘을 끌어다 놓으면 런치패드에 등록되니 참고하라.
이제 마지막으로 등록된 앱의 아이콘을 정렬하고 정리해주면 된다.
팁 : 만약 런치패드 아이콘을 초기 상태로 복구하고 싶다면, Dock의 환경설정폴더에서 db 파일들을 모두 지워버리고 Dock을 재시작한 후 런치패드를 실행하면 응용프로그램 폴도를 자동으로 가져와서 모든 앱을 추가해준다.1 아니면 아까 백업해 둔 파일을 지금 DB 파일에 덮어써버려도 된다.
$rm ~/Library/Application\ Support/Dock/*.db
$killall Dock
이건 상당히 글로벌한(?) 문제인 것 같은데, OSX의 Mail 앱에서 (심지어는 최근에 업그레이드된 5.0에서) 나타나는 문제이다. 아마 이런 문제를 겪고 있는 사람이 꽤 될 것 같은데… 바로 주소록에서 ‘성’ 란을 빈칸으로 비워두고 이름란에 성을 붙여서 쓰는 경우에, 메일 작성 시 보내는 사람 주소를 자동완성으로 입력하면 이름이 중복되는 문제다.
예를 들어 ‘홍길동’이라는 이름이 주소록에 “홍” , “길동” (성, 이름) 으로 들어가 있지 않고 “”, “홍길동” 으로 이름에 3글자가 모두 들어 있는 경우, Mail 앱에서 홍길동에게 메일을 보내고 나면 “홍길동”, “홍길동”으로 이름이 바뀌어 있는 문제이다.
이는 상당히 고질적인데, 주소록에서 성 필드를 지우고 이름을 다시 “”, “홍길동”으로 수정해도 다시 한 번 메일을 보내면 이게 “홍길동”,”홍길동”으로 중복해서 수정되어 버린다. 아마 이 문제에 대한 리포트를 애플이 안 받진 않았을텐데… 버그인 건지 뭔지 도통 모르겠다. 아마 영어권에서는 성과 이름이 각각 분리되어 있으니 크게 불편을 못느끼는 것일 수도.
1. 자동 완성 기능을 사용하지 않는다. (Disable Auto Complete)
당연하게도 자동완성 기능을 사용하지 않으면 이런 문제를 겪지 않는다. 하지만 너무 불편하다. 친구에게 보내는 메일같은 경우에는 수신란에 메일 주소만 들어가도 상관 없지만 매번 “홍길동 <honggildong@mailmail.com>” 과 같은 식으로 주소를 넣어줄 수는 없는 일 아닌가. 따라서 Mail 앱을 잘 사용하지 않는 경우에만 이 방법을 추천한다.
2. 성 필드에 공백을 입력해 둔다. (Place white space into first name field)
이건 좀 꼼수인데, 성 필드에 공백 문자를 하나 입력해 두는 거다. 이러면 이 문제가 발생하지 않고 ” “,”홍길동”이 되어 일단 보이는데는 큰 문제가 없어 보일 수 있다. 대신에 이름 자동 완성 이후에 파란 타원 모양으로 처리되는 그래픽이 좀 밀려 보이는 문제는 있을 수 있겠다. 게다가 주소록이 큰 경우에 모든 사람의 성에 공백을 넣기란….
3. “이전 수신자” 목록을 지운다. (Clear Previous Receipts)
Mail 앱은 “이전 수신자” 목록을 사용하는데, 이게 주소록에 추가되지 않은 연락처를 관리하거나 자동 완성을 좀 더 빠르게 하는 목적으로 있는 것 같다. 문제는 이곳에 중복된 이름으로 이름이 들어 있는 경우에 주소록에 해당 메일 주소가 있으면 이 내용으로 업데이트 된다는 것. Mail의 윈도우 메뉴에서 이전 수신자를 클릭하여 열리는 목록의 전체를 지워버린다. 일단 이 부분이 정상적인 이름이 표시된다면 중복 이름은 표시되지 않는다.
4. “이전 수신자”를 아예 사용하지 않는다. (Disable Previous Receipts)
3번의 해결책이 완벽하지는 않다. 모종의 이유로 이전 수신자에 중복된 이름이 들어가버리는 경우가 생길 수 있는데, 이러면 똑같은 문제가 다시 발생할 수 있다. 따라서 아예 이전 수신자 기능 자체를 꺼두는 것도 (정신 건강에) 도움이 될 수 있다.
터미널을 열고 다음 명령을 입력한다.($ 는 입력하지 않는다. 그냥 터미널 프롬프트다)
$ defaults write com.apple.mail SuppressAddressHistory -bool YES
이 정도 해주면 좀 도움이 될 수 있을 것도 같다. 끝.
정말이지 깜짝 놀랐습니다. 네이트 해킹 사고 소식을 듣고, 또 그 이후 쏟아져 나오는 어처구니 없는 기사들을 접하고 짜증반 절망반으로 상당히 안 좋은 기분에서 갈겨쓴 글이 너무나 큰 관심을 받게 되고 여기 저기 퍼져나가는 것을 보면서 한 편으로는 참 놀랍기도 하고, 다른 한 편으로는 사실 좀 겁도 났었습니다. 사실, 야밤에 이사짐을 싸는 와중에 1 쓴 글이라 글만 딱 쓰고 컴퓨터를 바로 분해하였기에 토요일에 무슨 일이 있었는지도 몰랐습니다. 밤에 트위터에 접속해보니 트래픽 초과라고 리셋 좀 해달라는 멘션이 와 있어서 어리둥절했는데, 리셋하는 족족 블로그는 폭파되었더랬지요. 사실 이사 이후 건강 상태가 많이 좋지 않아서 제대로 관리도 못하고 답글도 성의있게 달기는 커녕, 트위터로 멘션 주신 분들께도 일일이 답변을 드리지 못했습니다. 그리고 지난 글에서 미처 하지 못했던 이야기들과 또 다른 쪽으로 관심을 가져야 할 부분들이 남아서 이렇게 후속 포스팅을 쓰기로 마음먹었습니다. 원래 이 블로그의 시리즈물은 대략 2~3년 주기로 완성이 되는데, 이렇게 빨리 후속 포스팅을 쓰는 것도 아주 드문 일인 것 같습니다.
참고로 실제 내용에서는 경어체를 쓰지 않더라도 양해부탁 드립니다. 경어체로 쓰는게 생각보다 분량을 상당히 뻥튀기시키는 경향이 있기 때문에 글이 또 너무 길어지지는 않을까 하고, 또 왠지 ‘빙빙 둘러간다’는 느낌도 들어서 말이죠.
그리고 또 참고로 저는 보안 전문가가 아닙니다. 비록 IT업계에서 밥을 먹고 있는 사람이긴 합니다만 기획자로 일하고 있지, 개발자도 아니며 학교에서도 컴퓨터나 이런쪽 관련한 전공을 한 것도 아닙니다. ‘비 전문가적인 입장’에서 쓴 글이었기에 많은 분들이 공감을 해주실 수 있지 않으셨나 싶네요. 하지만 나름 이 ‘비 전문가적인 입장’에서 바라보는 보안이 실제로는 가장 중요한 요소라는 것은 확신하고 있습니다.
지난 번 글에서 묻지도 따지지도 말고 IE를 쓰지 말자고 하였더니, 많은 이들이 “윈도가 아닌 OS를 쓰는 사람들도 다 써야하는 IE를 쓰지 말라니, 이건 또 무슨 어이없는 소리?”라는 반을 보인 것도 사실이다. 물론 앞뒤 다 잘라내버리고 “해야할 것”에 대해서만 쓴 부분이다보니 이런 오해는 살 수 있겠다고 쓸 때에도 생각이 들었던 차라 이야기를 잠깐 해 볼까. 한다. 물론 ActiveX랑 얽힌 이야기다. 보안 뭐 그런 거 잘 모르는 사람들도 액티브엑스는 많이 들어본 적 있을거다. 사실 상 이거 때문에 MAC으로 전향하려는 사람들도 IE를 써야하는 것이니까. 그럼 ActiveX는 뭐냐? 사실 이걸 이야기하려면 웹브라우저에 대한 이야기를 해야하고 또 뭘 이야기해야하고… 따로 글을 써야 할테니까 여기서는 생략하겠다.
대신에 쉽게 말하자면 “웹 브라우저 본연의 기능이 아닌 것을 웹 페이지에서 실행할 수 있도록 하는 도구” 정도 된다. 대표적인 ActiveX로는 플래시가 있다. 요즘은 HTML5다 뭐다 해서 상당히 리치미디어 친화적인 웹으로 웹 자체가 진화하고 있는데, 이런 기술이 전면적으로 부각되기 전에는 이 플래시가 웹을 “예쁘고 재밌게” 만들어 온 점은 분명 인정할 수 있다. 그러니까 동영상도 보여주고, 음악도 틀어주고 게임도 하게 만들어주고 등등 웹 브라우저를 다양한 프로그램으로 변신시켜 주었다고나 할까.
하지만 개념적으로는 이렇다는 건데 이해를 쉽게 하자면 온라인 게임 사이트를 생각해보면 이해가 쉽다.
즉 온라인 게임 사이트에서 어떤 ActiveX를 하나 설치하면 (보통 런쳐라고 하지) 이 작은 엑티브엑스는 인터넷에서 몇 기가에 달하는 게임 클라이언트를 내려 받아 PC에 설치해준다. 심지어 많은 온라인 게임들은 실행하면 게임프로그램이 실행되는게 아니라 일단 웹 브라우저부터 띄운다. 웹 브라우저가 게임을 설치도 하고, 실행도 하게 만든다.
원래 웹 브라우저는 “험난한 외부 세상”의 데이터가 PC로 유입되는 관문이므로 웹 컨텐츠가 우리PC를 함부로 제어할 수 없도록 되어있지만, 온라인 게임 사이트는 이를 가뿐히 무시하고 자기네가 원하는대로 모든 걸 컨트롤 할 수 있게 된다는 이야기다.
그리고 이건 ActiveX의 모양을 하고 있는 악성코드들이 동작하는 방식과 정확하게 일치한다. 일단 웹브라우저에서 사용자가 YES를 클릭하기만 하면, 뭐든 시스템에 자기 자신과 함께 설치할 수 있고, 그 이후로는 심지어 웹브라우저와 완전히 독립적으로 자신의 일을 수행할 수 있으며, 무슨 짓이든 할 수 있다. 이건 뉴스에서 종종 보는 “보안 취약점 발견”이랑 상관 없이 원래 그게 가능한 거다. 그렇다고해서 ActiveX가 나쁘다는 건 아니다. ActiveX는 과학 기술들이 늘 그렇듯이 ‘가치중립적’이다. 2 문제가 되는 것은 ActiveX를 활용하는 방식인데, 우리 나라에서는 이게 극도로 잘못되어 있다는 데 문제가 있고, 그것은 “가장 신뢰할만하다고 대대수 사람들이 믿는” 정부, 금융권, 포탈이 사람들을 호도했다는 점은 가히 절망적이라 말할 수 있다.
실제로 인터넷에서 유발되는 대부분의 위협은 ActiveX가 가장 많다. 해킹 수단으로 ActiveX를 사용하는 것은 어찌보면 상당히 저급한 해킹 기술일 수는 있다. 왜냐하면 그것은 사용자가 설치 자체를 거부할 수 있기 때문이다. 하지만 IT병신강국에서는 이야기가 좀 틀려진다. 일단 거의 80%는 그냥 무사 통과되기 때문이다. 일단 웹 사이트에 붙여 놓는데만 성공하면 병신들이 알아서 열심히 깔아주는 해킹툴. 끝내주지 않는가?
이미 우리는 DDOS 대란을 두 번이나 겪었는데, 이 역시 AcitveX를 사용했으니까 이렇게 쉬웠던 거지 진짜 사용자 몰래 설치되는 스파이웨어같은 형태를 사용했다면 어렵고, 비싸고 그렇게 성공적으로 동작하기도 힘들었을 것이다.
이러한 위협을 해결하는 가장 저렴한 방법은 무엇이냐. 바로 IE를 쓰지 않는 것이다. “이 ㅆㅂ, IE를 안 쓰면 은행도 못하고 쇼핑도 못하는데 어쩌라는 거냐”는 식의 반응은 내가 해줄 말이 없다. IE를 안 써도 은행도, 쇼핑도 되도록 하면 된다. 그게 불가능한 것도 아니고 사실 우리 병신 강국 빼고는 다 이렇게 하고 있다.
지난 글에서도 링크를 달았던 “인터넷상에서 만날 수 있는 위협들 – 1“이라는 글은 내가 만약 돈이 궁한 해커라면 가장 경제적인 방법으로 많은 돈을 획득하는 가상 시나리오이자, 각 단계에서 나에게 도움이되는 요소들은 곧 “많이들 이렇게 하는데 이러면 쉽게 털린다“는 이야기였다. 사실 이 글에서 내 정보를 지키는 가장 핵심적인 이야기를 해 놓고 있었는데 의외로 이 글은 상대적으로 많이 읽히진 않았다. 그런데 이번 네이트 건 이후, 글에 대한 사람들의 반응을 보니 그 글이 담고 있는 시나리오는 절대적으로 실현 가능한 이야기로 생각된다. 게다가 진짜 절망적인 건 저런 시나리오를 생각해낸 나는 “전문가”가 아니라는 점이다.
ActiveX가 현실적으로 가장 큰 문제가 되는 것은 뭐냐면 정부기관과 금융권 그리고 교육 기관들이 남발해대는 ActiveX 그 자체라기 보다는 (그렇다고 문제가 없는 것도 아니다) 그걸 운용하는 방식이다. “가장 믿을 만한 사이트들이 무조건 설치부터 하라고 하는” 것이니까 괜찮겠지 하는 습관이 생기는 것이다. 자, 이 글을 읽으시는 분들 중에 어디 한 번 ActiveX를 설치할 때 게시자를 확인하고 관련하여 확인할 수 있는 모든 정보를 다 확인해 보는 분들 있는가?
이 기술이 워낙 사용하기 쉽고 (정확히는 몰라도 윈도 프로그래밍의 기초 지식만 있으면 다룰 수 있는 MFC로 만들 수 있다.) 인터넷에는 정말이지 별의 별 인간이 다 있기 때문에 MS는 보안종합선물세트인 서비스팩을 내놓으면서 점차 ActiveX를 쉽게 설치할 수 없도록 더 안전해지는 방향으로 (이와 동시에 개발사들에게는 참 귀찮아지는 방향으로) 정책을 변경한다.
그랬더니 잘나신 금융권, 정부기관 등등의 사이트에서는 기껏 높여놓은 보안 수준을 거꾸로 떨어뜨리는 방법을 멋지게 디자인된 페이지를 통해서 계몽하고 있더라 이거다. 그리고 이와 동시에 언론에서는 MS가 혼자 미쳐 날뛰면서 자기만 살자고 서비스팩을 내놓고 있어서 사용자들이 엄청 불편함을 겪고 마치 사회의 절반이 마비될 거처럼 호들갑을 떨어댄다.
그래서 우리나라는 “반도의 인터넷”이라는 명칭을 붙여도 좋을 만큼의 병신 갖은 인터넷 환경을 자랑할 수 있게 되었다. “특수한 한국의 웹 환경”은 흔히 화려한 것을 좋아하는 한국 사람의 특징을 연관시키기도 하는데, 아침 저녁으로 뭘 먹으면 그런 잔머리가 생기는지 모르겠다.
네이트 사건과는 별개로 지난 주 쯤 많은 은행들이 저렇게.. 소제목과 같이 ActiveX를 안쓰고 다양한 운영체제와 브라우저를 지원하는 뱅킹 서비스를 개발하겠다고 대대적으로 홍보하고 있는 걸 본 적이 있다.
훗… 역시 IT 강국이다. 다른 나라에서 10년전쯤부터 하고 있던 걸 이제 개발 시작했다. 근데 이런 은행 사이트를 이용할 수 있게 해달라는 움직임이 10년 전부터 있어왔다. 물론 지금은 철저한 무관심속에서 아는 사람만 알고 있는 오픈웹이라는 곳인데, 관심있으면 찾아보기 바란다. 근데 저 기사에서 자꾸만 쓴 웃음이 나는 건 바로 사용자(소수)들의 목소리는 철저히 배제된 채, “스마트폰에서는 ActiveX가 안되니까”가 결국 이유라는 것이다. 대한민국 웹 서비스에서 소비자/사용자의 지위따위는 찾을 수 없는 현실을 재발견하게 되었다.
오픈웹을 주도했던 김기창 교수님은 마냥 저 기사가 반가웠을지 나도 그건 참 궁금하다.
보안에 있어서 가장 취약한 부분은 바로 다름 아닌 사용자 자신이다. 그 자신이 무지하고 게으르면 너무나 뚫기 쉬운 구멍이 될 수 밖에 없다. 지난 글에서 “모든 사이트마다 아이디, 패스워드가 달라야 한다”는 이야기를 듣고 뭔가 번쩍 생각 나신 분들 많을테다. 사이트마다 같은 아이디, 같은 패스워드를 쓴다는 것은 어디 한 곳만 털리면 나머지 모든 사이트가 고스란히 해커의 손아귀에 들어간다는 것이다. 그리고 이미 우리는 네이트 이전에도 크고 작은 개인 정보 유출 사고를 당해왔는데 그 긴긴 시간 동안 이 중요한 사실을 알려주는 언론사, 정보기관 심지어 보안업계관계자 중에서도 아무도 없었다는 것이 나에게는 충격이었다.
그리고 나서 많이 들은 이야기 중 하나는 “그 많은 사이트를 아이디까지 관리하라면 어휴..’ 등의 이야기였는데, 참고로 한 마디 드리자면 국내 3대 포털과 싸이월드 아이디만 모두 다르게 설정해 놓으면 네티즌수사대의 신상털기 난이도를 수십배 높일 수 있다는 뭐 그런 거… (대부분 네이버나 이런 곳의 아이디와 싸이월드의 아이디를 비교해보면 답이 나오니까 몇 분도 안돼서 신상이 털리는 것임)
두 번째 문제, 패스워드를 어떻게 만들어야 잘 만들 것이냐. 물론 패스워드를 만든 다음에 또 관리하는 방법도 문제인데. 패스워드 만들 때 방법부터 간단히 살펴보자. 패스워드는 가능한 다음 몇 가지 원칙을 지키면 좋다.
1. 길 것
2. 영문자 대소문자와 숫자, 그리고 가능하다면 특수문자를 섞어 쓸 것
3. 사전에 없는 단어일 것
4. 실제 자기 자신과 관련되지 않는 단어(이름, 별명)나 숫자(생일, 전화번호 등)일 것
누군가 나의 정보를 빼내기 위해 내 포탈 아이디의 비밀번호를 뚫고 싶다면, 아마 다음의 방법을 생각할 수 있다. 비밀번호로 사용이 가능한 영단어 사전 + 각 단어에 숫자값을 올리기. 물론 이렇게 무식하게 하는 건 마치 핸드폰 비밀번호를 0000부터 9999까지 다 눌러보는 것과 같은 방법인거다. 근데 이게 은근 통한다는게 더 큰 문제다. 그러니까 사전에 등재될리 없고 (아예 영단어 자체가 아니고) 대소문자가 섞이고 숫자는 폼으로 넣는 게 아니라 당당히 가운대로 들어가라는 것이다. 예를 들어서 love85 라고 하지말고 lo8V5e 라고만 해도 일단 한결 나아 보이지 않는가. 이러면 이런 식의 사전 공격으로는 뚫기가 어려워진다.
5. (중요)가능하면 길 것
그리고 가능하면 한 글자라도 길어야 한다. 핸드폰 번호를 0~999번 눌러보는 것과 9999번까지 누르는 것과 99999까지 다 눌러보는 것 중에 어떤게 침략자에게 경제적인지 생각해보면 된다.
여기까지는 비밀번호 만드는 원칙인데. 보통은 이렇게 만들면 되지 않을까 싶다. 솔직히 이건 내가 소개하는 한 가지 방법일 뿐이니, 다들 ‘그럴싸한 암호처럼 보이는’ 암호를 만드는 방법을 구상해보시길.
6. (중요) 가능하면 바꿀 것
암호를 바꾸는 작업는 사실 상 엄청난 고통을 수반한다. 왜냐면 타이핑에 익숙한 사람들은 거의 손가락의 연속 동작이 몸에 익은 상황이기 때문에 익숙하지 않은 암호와 같이 복잡한 타이핑을 할 때 오히려 오타가 많이 날 수 있기 때문이다. 그래서 좋은 암호를 만들어 놓고도 그걸 바꾸지 않으려는 습성이 있다. 솔직히 나도 좀 이런 습성은 있다. 그런데 바꿔줘야 한다. 왜냐면 그 암호를 쓰는 사이트가 털렸는데 그 사실을 사이트 관리자가 모른다거나 하는 문제가 있을 수 있기 때문이다. 물론 그 사이트에 별로 중요한 정보가 없는 곳이라면 신경쓰지 않아도 좋지만, 적어도 싸이월드 같은 곳이라면 응당 3개월에 한 번 정도는 바꿔주는 것이 “바꾸지 않는 것보다는 좋다”
화장은 하는 것보다 지우는 것이 중요하고, 암호는 좋은 암호를 만드는 것도 중요하지만 이를 잘 관리하는 것이 더욱 중요하다 하겠다. 암호 관리에서 가장 명심해야 하는 부분은 개인 차원에서 ‘유출’이 되지 않도록 하는 것이다. 암호가 유출되는 케이스 중 대표적으로는 다음과 같은 경우를 생각해 볼 수 있다. 바로 유출이 쉬운 곳에 보관하는 사용자들이 너무 많다는 것이다.
복잡도가 높게 만들어진 암호는 사람이 기억하기가 사실상 어렵다. 게다가 사용하는 모든 사이트에서 사용되는 모든 암호를 일일이 기억하는 것은 정말 쉬운 일이 아니다. 그래서 이를 이메일로 작성하여 보관한다거나, 텍스트 파일로 만들어서 저장해 두는 방법을 생각해 볼 수 있는데, 이런 경우의 위험도는 매우 높다.
재수 없게 그 암호를 보관해 둔 메일 계정이나 텍스트 파일 자체가 유출되는 경우에는 모든 사이트의 접근 암호를 한 번에 유출하는 셈이 되는 것이다. 정말 우습게 들릴 수 있지만 이런 경우에는 차차리 종이에 적어서 보관하는게 안전할 수 있다. 웃긴가? 진짜다.
은행 거래에서 사용하는 자물쇠번호 카드라 생각하면 된다. 심지어 이 자물쇠 카드를 사진으로 찍어서 핸드폰이나 메일에 보관해 두는 사람들이 있는데, 내가 알기로 은행 해킹 피해를 입었을 때 이 자물쇠카드의 소프트카피를 만든 이력이 확인된다면 사용자 과실이 되어 보상을 받기 어려운 것으로 알고 있다. (이는 대단히 여러가지 의미를 가지고 있다)
근데, 종이에 써두는게 폼도 안나고 우습게 보일 수 있지만 개인적인 차원에서는 가장 중요한 안전 장치(?)가 하나 있으니 이는 이 종이를 분실하게 되면 분실한 사실을 우리가 알아차리고 대응을 할 수 있다는 점이다. 텍스트 파일이나 메일등의 디지털 데이터로 민감한 정보를 저장할 때 가장 위험한 요소 중 하나는 디지털 데이터는 그대로 복제가 가능하고 원본만으로는 복제를 당한 사실 자체를 알아차리기가 쉽지 않다는 것이다.3
나 역시 비밀 번호를 외우지 못한다. 그래서 뭔가 좋은 방법이 없나 하고 이것 저것 살펴보던 중에 쓸만한 서비스들이 있는 것을 발견했다. 그 중에 대표적인 케이스는 Lastpass라는 서비스이다. 이 서비스는 각 웹사이트의 계정 정보를 암호화하여 보관하고 자동 채우기나 자동 로그인과 같은 기능을 함께 제공한다. 현재 일반적으로 많이 사용하는 대부분의 웹 브라우저를 지원하고 있고, 그 방식 또한 상당히 안전하다고 생각된다. 게다가 한글도 지원하니 한 번 사용해 볼 것을 강력히 권한다. 우리의 가장 큰 고민 중의 하나인 ‘강력한 암호 패턴’을 자동으로 생성해주는 기능도 있으니 참고하라.
LastPass : http://www.lastpass.com
즉, 웹 브라우저에서 사용하는 암호 기억 기능을 구현하고 기억되는 암호를 모조리 암호화하여 서버에 저장해 둔다. 그리고 이렇게 암호화되어 저장된 로그인 정보 내역들은 하나의 마스터 패스워드를 통해서 접근할 수 있도록 되어 있다. 따라서 사용자는 lastpass에 로그인하기 위한 마스터 패스워드 하나만 잘 관리하면 비교적 안전하게 로그인 정보들을 잘 보관하고 관리하며 심지어는 편리하게 사용할 수 있다.
이와 비슷한 형태의 서비스로는 로보폼과 같은 유료 서비스들도 있다. 물론 현재 상태에서는 이보다 나은 대안은 종이에 써 두는 것 외에는 없는 것 같다. 사실 이런 내용은 특정 서비스를 홍보 해주는 것 같아서 좀 거시기한 면도 있는데 나 역시 이것 저것 알아보고 하는 게 귀찮을 뿐, 혹 누군가가 이런 정보들을 많이 알고 계신다면 트랙백 부탁 드린다.
앞 서 세 개의 챕터에서는 비밀번호를 잘 만들고 또 관리하는 방법에 대해서 알아보았는데, 보다 더 나은 대안이 있다면 믿겠는가? 당연하지 있다. 듣고나면 그게 현실성이 있느냐라고 따져 물을 수도 있지만, 계속해서 요구하고 소비자들의 목소리를 높이면 그게 현실이 되지 말라는 법이 없는 것도 아니다. 그리고 우리나라 웹서비스가 개판 오분전의 상태로 계속해서 기형적으로 발전해 온 데는 “우리나라 사용자들의 취향”을 핑계되는 참 파렴치한 기획자들이 한 몫해 왔으니, 이제 우리는 더욱 안전하고 믿을 수 있는 웹을 선호하는 취향을 가졌음을 이들에게 피력할 필요는 있는 것 아닌가.
1) 주민번호 넣으라는 사이트는 사용하지 않는다. / 포탈을 사용하지 않는다.
물론 대형 사이트의 경우에는 제한적 본인확인제라는 거 때문에 주민번호를 받지 않느냐고 하는데, 내가 알기론 그게 댓글 달 때 본인인지 아닌지만 확인해주면 되는 거기 때문에 포탈 사이트가 우리의 주민번호를 DB에 보관할 수 밖에 없다고 찌질대는 핑계의 근거가 될 수 없다. 개인정보를 덜 요구하는 대안적 서비스를 사용하면 된다. 그런 서비스는 어떻게 알아서 찾아 쓰냐고? 그러기 위해서는 포탈을 안쓰면 된다. 포탈은 자연히 트래픽을 자신의 서비스 테두리 내에 가두려는 속성이 있으므로 포탈을 쓰지 않으면 꽤 괜찮은 서비스들을 자연스레 쉽게 찾을 수 있게 된다.
이 블로그는 ‘워드프레스’라는 설치형 블로깅 도구를 사용해서 만들었는데, 워드프레스는 전세계에서 가장 많은 사용자를 보유한 블로그 서비스이기도 하다. 그런데 우리 나라에서는 워드프레스로 된 블로그를 많이 찾아보기도 어렵고, 워드프레스라는 이름 자체를 잘 모른다. 전세계에서 가장 많이 쓰는데 우리만 모른다? 난 그 답을 포탈에서 찾아야 한다고 본다.
2) 회원가입을 하지 않아도 되는 사이트
로그인은 필요한데, 회원 가입을 하지 않아도 되는 사이트들이 있다. 국내에서도 어렵지 않게 그런 서비스들을 찾아볼 수 있다. 회원 가입을 하지 않고서 어떻게 로그인을 하느냐? 로그인 자체는 “ID”와 “패스워드”를 가지고 사용자 본인에 대한 인증을 받는 과정인데, 그것이 “내가 맞다”는 것만 증명을 하면 되는 거라면 그걸 굳이 회원가입까지 할 필요는 없다는 아이디어에서 출발하여 탄생한 결과물이 오픈ID라는 것이다. 오픈ID는 메일 주소 하나만 있으면 생성이 가능하고, 이 오픈ID를 지원하는 서비스에서는 아이디나 비밀번호를 별도로 만들 필요 없다. 단지 로그인을 하게 되면 오픈ID 홈페이지로 잠깐 이동하여 나의 오픈ID로 로그인을 하고 다시 원래의 웹사이트로 “로그인된 상태로” 돌아오게 된다.
아, 이거 어디서 본 적 있지 않는가? 트위터 쓰는 분들이라면 특정한 앱을 처음 시작할 때 트위터 로그인 화면을 한 번씩 다녀오게 된다. 이건 oAUTH라는 인증 방식인데, 사용자를 인증하는 어떤 표준 규격 같은 걸 만들어 놓고 대표 사이트에서 한번 인증한 결과 값을 주고 받아서 사용자를 인증하게 된다. 애초에 통신 자체에는 인증값만 있을 뿐 중요한 아이디나 패스워드는 필요치 않으므로 상당히 안전한 방식이라 이거다.
물론, 이런 사례는 현실성이 부족한 거 아니냐는 질타를 받을 지도 모르지만 oAuth의 경우에는 이미 엄청난 수의 대한민국 국민이 경험하고 있는 기술이다. 근데 왜 그게 우리 나라에서 만드는 웹사이트에서는 되면 안되는 건가? 왜 그런데? 법때문에? 그럼 그 법을 바꿀 수 있도록 목소리를 내고, 그런 방면에 전문성을 가지고 있는 사람에게 투표하면 된다. 그렇게 하면 안될 것도 없다고 보는데 왜 그럴까.
다시 한 번 말하자면 ‘공인인증서’나 ‘액티브액스’없는 인터넷 뱅킹은 못하고 있던 게 아니라 ‘안하고 있던 것’이었다. 그 이면에는 아무래도 수상쩍은 여러가지 상식을 벗어나는 배경들이 있는 것 같지만 어쨌든 조만간 우리는 이런 인터넷 뱅킹을 하게 될 것이다. 하지만 ‘목소리’가 부족했다는 이유로 이런 변화를 이끌어 낸 최대 공헌자는 애플과 구글이 되었다.
네이트의 해킹 사건에 이스트소프트가 날벼락을 맞았다. 알약의 업데이트 패치에 악성코드가 포함되었고, 이 코드가 유출에 개입되었다는 이야기가 있다. 덕분에 며칠전에 이스트소프트가 한 번 압수수색을 당했다지. 근데 그럼 SK컴즈 내부에서는 ‘허술하게도’ 알약 따위의 백신을 내부 PC에 사용했단 말인거다. 그리고 또 한가지, 지난 글에서도 이야기했지만 이런 식의 뒷북 처사는 “우리도 뭔가 하고 있다”는 쇼일 뿐이다. 아니면 이게 얼마나 심각한 사태인지 국내에 수많은 “관계자” 4들은 어디서 뭘하고 있길래 그게 아무 쓰잘데기 없다는 이야기를 안하는 걸까. 그런식으로 해커를 잡았다고 치자. 그럼 그 해커만 간첩행위로 처벌받으면 이번 사건은 정의가 승리한 깔끔한 결말을 맞이하게 되는 걸까.
이번 사건으로 나름대로 사람들의 보안에 대한 관심이 조금씩 커졌다는 것을 느꼈고 그것이 매우 좋은 출발이 될 수 있다고 생각하는데, 아무래도 이 나라는 계속 IT병신강국의 타이틀을 유지하고 싶은가보다.