2012.11.07.수요일

아외로워

 

 

 

 

 

지난 편에서 우리는 아주 간단한 목표를 세웠었다. 이번주에 당장 하는 것은 아니고, 거기에 필요한 기술들을 익혀나가며 조만간 함께 로또번호 생성기를 만들어보자.

 

 

OS X의 보안

 

자 쉬어가는 의미에서 지금까지 이 시리즈에서 이슈가 됐던 내용들을 되짚어보자. 어떤 분이 맥이 해커가 뚫기 쉽다고 했는데 사실이 아니다. 사실 요즘 현역으로 뛰고 있는 OS나 웹브라우저는 모두 거의 동등한 수준으로 안전하다.

 

컴퓨터가 멀쩡하게 작동하며, 알려진 보안 문제(트로이목마 같은 것이 깔렸다거나, 매수된 보안담당자라던가, 버그라던가)가 없는 시스템을 한컴타자연습 1분에 1000타 치는 해커가 뚫어내는 것은 사실상 영화에나 나오는 거라고 보면 된다. OS에 상관 없이 말이다. 설령 버그가 있다고 해도 요즘 세상에는 패치가 순식간에 나온다. 최신 업데이트만 꼬박꼬박해주면 된다.

 

윈도우가 비교적 덜 안전하다고 하는 것은 무슨 말이냐면 의심스러운 프로그램이 너무 쉽게 관리자 권한으로 실행 될 수 있으며, 특히 인터넷에 돌아다니는 뜨내기 프로그램이 Active X라는 형식으로 사용자의 컴퓨터에서 실행되기 때문이다. 얘네가 보안의 구멍이 되며, 좀비피씨도 이런 식으로 만들어진다.

 

맥이 사용하는 OS X는 BSD라는 유닉스 시스템의 변형이다. 수십년간 검증되고 보완되고 강화된 대단히 안전한 시스템이며, 지금도 발전하고 있다. 게다가 OS X는 윈도와 달리 검증되지 않은 프로그램을 울며 겨자먹기로 설치할 필요가 없고, 특히 액티브X는 애초에 설치가 되지도 않는다. 그리고 검증되지 않은 개발자가 배포하는 프로그램을 설치하려면 시스템 설정에서 보안수준을 사용자 스스로 낮춰야 하는데, 그 자체도 매우 성가시다.

 

 

한마디로 OS X는 매우 안전하다.

 

 

앱스토어의 원조 논란?

 

앱스토어 이야기 하면서, 이거 원조라 리눅스라는 말을 했었다. 인터넷에서 앱 패키지를 다운받아 설치하는 것은 댓글에서 XXX님이 지적해주신 것과 같이 FreeBSD의 ‘port’가 먼저인 것으로 보인다. 맥이 사용하는 OS X도 BSD계열인 만큼 맥에서도 darwin port라는 것을 사용 할 수 있는가보더라. 자세한 것은 더 공부를 해봐야겠다.

 

그리고, ‘데비안’ 리눅스의 파일매니저는 ‘dpkg’이며(레드햇 리눅스는 rpm), dpkg를 port처럼 사용하게 해주는 것이 ‘apt-get(레드햇은 yum)’이다. ‘apt-get’을 그래픽 환경에서 쓸 수 있게 한 것이 ‘시냅틱’이다. 데비안 리눅스의 변종인 ‘우분투’ 리눅스에서는 ‘시냅틱’을 더 사용하기 쉽게 만든 ‘소프트웨어 센터’ 라는 것을 만들었는데, 애플이 처음 맥 앱스토어를 선보였을 때 우분투의 소프트웨어 센터를 표절한 것이라는 논란이 일기도 했었다.

 

쉬어가자고 해놓고 안 쉬어가는 이야기만 한 것 같으니 걍 다음 과업으로 가보자.

 

 

본격 까막눈 탈출

 

인터페이스를 만들며, 앱을 하나씩 조금씩 만들어 가려 하였으나 크나큰 장벽에 부딪혔으니, 그건 바로 우리가 활용해야 할(쉽다던) 예제파일을 봐도 뭔 말인지 이해가 전혀 되지 않는다는 것이다.

 

정말 기본적인 뷰컨트롤 화면이지만 뭔 말인지 모른다.

 

고등학교 시절, 모르는 문제를 선생님한테 물어봤는데 선생님의 설명조차 이해하지 못했던 어두운 과거를 가져본 사람이라면 이게 무슨 말인지 이해 할 수 있을 것이다. 저게 도대체 어느 나라 말인지도 잘 이해가 안되는 상황이 되고마는 것이다. 왜냐면 이 시리즈를 열심히 읽는 당신은 아마도 프로그래밍 경험이 없을 것이고, 따라서 우리는 저 이상한 기호들을 이해하기 위해 먼저 프로그래밍에 대한 최소한의 감각을 익혀야 하는 것이다.

 

프로그래밍을 하기 위해 각종 기호가 섞인 외계어를 타이핑 하는 것을 ‘코딩한다’ 라고 한다. 이제 우리는 기본적인 코딩을 배워나갈 참이다. 유치원생이 되어 하나 둘 셋 세는 법부터 배운다고 생각하자. 지지난 편에 잠깐 나왔다가 이제 거의 잊혀져가는 ‘hello world’ 코드를 다시 돌아보자. 저 코드 어디에 있는지 모르겠는 사람은 “hello, world!” 편을 읽고 오시라.

 

 

첫 번째 코드 - 주석

 

‘//’ 는 이 뒤에 나오는 모든 내용이 주석이라는 것을 알려준다. 이 주석이라는 것. 이건 엄연히 말하면 프로그램은 아니다. 컴퓨터 프로그래밍이란 궁극적으로 인간의 뜻을 컴퓨터에게 전달하는데 그 목적이 있는데 주석은 컴퓨터에 전해지지 않는 인간만의 언어인 것이다.

 

원래 인간과 컴퓨터, 이 둘의 언어는 너무 달라서 배워도 서로 이해 할 수가 없기 때문에 중간에 ‘컴파일러’ 라는 것이 끼어서 통역을 해준다.

 

   인간 - 컴파일러(통역) - 컴퓨터

 

그런데 문제는 뭐냐면 이 컴파일러도 인간의 언어를 할 줄 모른다는 것이다. 컴파일러가 할 줄 아는 언어는 ‘Objective-C’ 같은 프로그래밍 언어 뿐이다. 그래도 이 언어는 컴퓨터 언어(‘기계어’ 라고 부른다)와는 달리 인간이 배울만 하기 때문에 인간들이 저 언어로 컴퓨터와 대화 하는 것이다.

 

그러나 십수년간 영어를 배웠음에도, 영어를 말하는데 유창함 이라고는 눈을 씻고 찾아도 찾아지지 않는 우리 작금의 행태로부터 유추하였을 때, 우리가 프로그래밍 언어를 모국어처럼 자연스럽게 구사할 가능성은 극히 낮다.

 

잘 이해도 안되는 내용을 아름아름 책 찾아가며 어떻게 작성하는데 성공하였다 한들, 담날 일어나서 보면 저게 뭔소린지 코드를 작성한 본인도 이해가 안 되는 상황이 발생하는 것이다. 본인도 이해가 안되는 마당에 이 코드를 보는 제3자는 이해를 할리가 만무하다.

 

따라서 코드를 작성하면서, 내가 지금 뭔 소리를 왜 작성하고 있는지 ‘인간의 언어’로 따로 기록해 놓을 필요가 있는 것이다.

 

주석을 얼마나 잘 쓰느냐가 프로그래머의 자질을 평가하는 지표가 되기도 한다. 주석을 이상하게 쓴다거나, 클래스나 변수 명을 이상하게 정하는 사람은 협업을 하기도 힘들고, 자기가 짰던 코드를 고치기도 힘들다.

 

주석. 따로 배울 필요도 없는 쉬운 것이지만, 잊지 말고 열심히 쓰자.

 

주석을 쓰는 방법은 줄의 맨 앞에 ‘//’를 넣는 것이다.

 

 

이렇게 해놓으면 컴파일러는 그 내용을 무시하기 때문에 프로그램에는 아무런 영향도 주지 않는다.

 

빌드해보면 주석은 프로그램에 아무 영향도 주지 않는다. 빌드 하는 방법을 모르겠으면 지난편을 참고.

 

프로그램 코드를 쓰다가도 ‘//’를 넣으면 그 뒤에 있는 내용이 모두 주석으로 처리된다.

 

 

여러 줄의 긴 내용을 주석으로 남기는 방법도 있다. ‘/*’ 로 시작해서 ‘*/’로 끝내면 된다.

 

   #import<Foundation/Foundation.h>

 

이 부분은 Foundation.h라는 파일을 불러오라는 명령어다. 그러니까 컴파일러에게 ‘우리가 지금 작성하는 코드는 저 파일에 나온 어휘를 참고하고 있단다’ 하고 알려주는 것이다. 저 파일은 오브젝티브C 에 포함된 매우 기본적인 명령어나 함수를 담고 있다고 한다. 지금 단계에서는 달리 생각 할 필요 없이 습관적으로 불러와주면 된다. 어차피 기본적으로 써있잖은가.

 

   int main(int argc, const char * argv``)

   {

 

이 부분 역시 지금 단계에서는 습관적으로 써주면 되는 부분이다.(이것 역시 저절로 써지니까 신경 쓸 것도 없다) int main 은 아래 써내려가는 코드가 ‘main’이라는 함수에 포함된다는 뜻이며, ‘main’이 결과물로 내놓는 값이 정수(integer)라는 뜻이다.

 

맨 아래 있는 return 0; 과 연결되는 부분인데, 이 return은 이 함수가 뭐를 결과물로 내놓을지(‘반환한다’ 고 한다) 가르쳐준다. 우리가 보고있는 헬로월드 코드는 가운데 무슨 내용이 있든 0을 반환한다. 한마디로 아직은 반환이고 뭐고 상관 없다는 뜻. 형식적으로 필요해서 쓰는 부분이다. 반환이 어쩌고 이해가 안되면 그냥 넘어가면 된다. 나중에 다시 다루도록 하자.

 

그 밑에는 중괄호( { ) 가 보이는데 이 중괄호로 ‘int main(int argc, const char * argv``)’가 포괄하는 범위를 알려준다. 중괄호를 열었으면 나중에 반드시 닫아줘야 한다.

 

   @autoreleasepool {

 

이건 메모리 관리에 관한 명령어다. 원래 프로그래밍 할 때는 메모리 관리를 해줘야 한다는데, 오토릴리즈풀에 중괄호로 묶여있는 모든 프로그램들은 실행된 이후 자동으로 메모리에서 해제(release)된다. 자동으로 되니까 신경쓰지 말자. 지금은 이것도 걍 그러려니 하고 넘어가자.

 

여태까지는 지금 시점에서는 굳이 알 필요 없는 부분을 알아봤다. 그 밑에

 

   //insert code here...

 

라고 주석이 달려있다. 정말 친절하지 않은가. 우리가 코드를 작성할 부분은 바로 이 부분이다.

 

 

그러니까 결국 뭔가 복잡해 보였지만 결국 저기에서 프로그램이라고 할만한 부분은

 

   NSLog(@”Hello, World!”);

 

밖에 없었던 거다.

 

NSLog(@”쓰고 싶은 내용”);

 

을 해주고 실행하면 쓰고싶은 내용이 디버그창에 나타난다. 따옴표 안쪽에 써줘야 한다.

 

이렇게 해서 실행하면

 

이렇게 된다.

 

NSLog를 쳐줄때 대소문자를 잘 구분해줘야 한다. 이 명령어의 NS는 Next Step의 약자라고 한다. 넥스트스텝이 뭐냐면,

 

 

잡스가 애플에서 쫓겨난 뒤 만들었던 컴퓨터고, 오브젝티브C를 전격적으로 도입했던 컴퓨터다. 즉, 좋든 싫든 우리는 잡스의 영향 아래 있는 거다.

 

그런데 NSLog는 말 그대로 로그를 보여주는 화면이다. NSLog의 결과로 나오는 걸 보면, 원하는 결과물 외에도 실행한 날짜, 시간, 프로젝트 이름 같은 것이 나온다. 그런거 다 빼고 우리가 원하는 결과물만 보고 싶다면? 이렇게 해보자.

 

 

아까 썼던 NSLog대신 ‘printf’라는 명령어를 썼다. 보다시피 printf에는 앞에 NS라는 게 붙지 않았다. 그러니까 이 명령어는 오리지널 C에 포함된 명령어라는 말이다. 전에도 말했지만, C에 객체지향에 관한 기능을 추가한 것이 오브젝티브C다.

 

NSLog는 괄호 안에 따옴표에 앞서 ‘@’를 넣었지만 printf는 골뱅이가 빠진다. 골뱅이의 존재는 이게 오리지널 C 영역인지 오브젝티브 C 영역인지 구분해 준다. 즉, 갑자기 코드에 골뱅이가 나왔다면 그건 C에 덧붙여진 오브젝티브C의 명령어란 말이고, 이는 필시 ‘객체지향 프로그래밍’ 과 관련됐을 가능서이 높다는 말이다. 이건 나중에 이야기 하고, 자 실행을 해보자.

 

 

 

아까 나왔던 날짜 시간이 없이 따옴표 안에 있는 내용만 나온다. 그러나 첫째 줄의 내용과 둘째 줄의 내용이 줄바꿈 없이 딱 붙어있다. 이건 어떻게 해야할까?

 

 

왼쪽 위에서 오른 쪽 아래로 내려오는 막대기는 윈도 한글 키보드에서는 ‘원’ 표시다. 그래서 윈도가 깔린 PC, 혹은 맥에서도 윈도 폰트로 쓰는 경우라면 ‘n’으로 보이게 된다. 효과는 똑같다. 여튼 저 막대기와 ‘n’을 연달아 쓰면 엔터를 친 것과 같은 효과를 준다.

 

   printf(“여기에 쓰고 싶은 내용을 쓰세요n두 번 쓰세요”);

 

이렇게 해도 결과는 위에 두 줄로 쓴 것과 같다는 말.

 

원래 백문이 불여일타라 했다. 백 번 읽는 것 보다 키보드로 한 번 두들겨 보는이 낫다는 프로그래밍계의 격언이다. 별거 아니라도 한 번 직접 작성해 보고 실행시켜보자.

 

 

변수

 

지금 배우는 것은 프로그래밍 언어의 기초중의 기초이며 한국말로 치면 옹알이에 해당되는 것이다. 아이폰 앱 만든다더니 이 무슨 쓰잘데 없는 것만 하고있나 싶어도 같이 해보자. 옹알이가 없으면 달변도 없다. 변수 역시 엄청엄청 기본이다. 수학에 나오는 거랑 같다. 자 예를 들어보자.

 

   a = 1

   b = 2

   c = a + b

   따라서 c = 3

 

이런 거다. a라는 변수에는 1을 넣고, b에는 2를 넣는다. c 에는 a와 b를 더한 값을 넣는다. 따라서 c는 3이다. 이런 논리 흐름이 오브젝티브C를 비롯한 모든 프로그래밍 언어에서 똑같이 적용된다. 서문에 언급했던 ‘파이썬’ 같은 언어는 위에 보여준 것과 같이 간단하게 쓸 수 있는데, 오브젝티브C는 여기에 더해 ‘선언’ 과 ‘자료형’을 고려해야 한다. 무슨말인지 어디 한번 보자.

 

 

한 줄이 끝날 때마다 세미콜론(;)으로 줄을 끝낸 것을 눈여겨보자. 이렇게 해줘야 한 줄이 끝난다.

 

   a = 1

   b = 2;

 

이렇게 세미콜론을 빼먹으면 컴파일러가 ‘a = 1’과 ‘b = 2;’ 가 같은 줄에 있는 걸로 생각하기 때문에 에러가 난다. 코드를 치다가 이런 실수를 저지르면...

 

 

요롷게 Xcode가 잘못 됐다고 알려준다. 일종의 맞춤법 검사도구인 건데, 이게 Xcode가 사용하는 LLVM이라는 똑똑한 컴파일러 덕분이란다. 이거 덕분에 실수 할 가능성이 아주 극적으로 줄어든다. 맞춤법 잘 맞춰서 autoreleasepool 안쪽에 잘 타이핑 해주자.

 

그리고 실행을 누르면 이런 결과가 나온다.

 

 

보다시피 변수 c에는 숫자 3이 들어있다. NSLog를 이용해서 c의 값을 보여달라고 했더니 당연하게도 3을 보여줬다. 물론 NSLog대신 printf를 쓴다고 해도 누가 안 잡아간다.

 

   printf(“%i”, c);

 

자 그럼 저 3나온 코드를 다시 보고 각 줄이 무슨 의미인지 풀어보도록 하자.

 

먼저 첫 줄이다.

 

   int a, b, c;

 

이건 뭐냐면 우리가 쓸 a, b, c 라는 변수를 만드는 거다. 즉, 컴파일러에게 ‘내가 이제 변수를 세 개 쓸 건데, 그게 각각 a, b, c야’ 라고 알려주는 것이다.

 

이 한 줄은...

 

   int a;

   int b;

   int c;

 

라고 세 줄로 나누어 쓸 수 있다. 무슨 말인지 아시겠지? 즉, int 를 쓰는 변수라면 쉼표로 구분해주면서 연속해서 한 줄에 선언해 줄 수 있다는 소리.

 

3개의 변수를 쓴다고 ‘선언’ 해줬으니, 선언한 변수를 사용하면 된다.

 

   a = 1; // (기억나는가? ‘//’ 뒤에 나온 내용은 모두 주석이다) a는 1이고

   b = 2; // b는 2고

   c = a + b; //그 둘을 더한 것을 c라고 하자.

 

그리고 마지막줄...

 

   NSLog(@”%i”, c);

 

이건 c를 출력하라는 명령어다. 저 위에서 봤다시피 NSLog명령어는...

 

   NSLog(@”하고 싶은 말”);

 

이런 식으로 쓴다. 그럼 도대체 방금 쓴 ‘%i’ 는 뭘까 하는 생각이 들지 않는가? 그런 생각이 들지 않았다면 직접 코딩하며 읽고 있지 않다는 뜻이다. NSLog를 다음과 같이 바꿔보자.

 

   NSLog(@”1더하기 2는 %i입니다.”, c);

 

그러면 결과는...

 

 

이렇게 나온다. 알듯 말듯 하지 않은가? 그러면 이렇게도 바꿔보자.

 

   NSLog(@”%i더하기 %i는 %i입니다.”, a, b, c);

 

실행 한 결과는 놀랍게도 아까랑 같다. 말로 풀어 설명하자면, 따옴표 안에 글자가 출력되긴 출력되는데 ‘%i’ 라고 되어있는 부분은 따옴표 닫은 다음에 나오는 변수의 값으로 순서대로 대체된다. 따라서 아까 ‘NSLog(@”i%”, c);’ 라고 했던 부분도 이해가 갈 것이다.

 

다른 소리 하지 말고 그냥 변수 c의 값만 보여달라는 뜻이었던 거다.

 

자 그렇다면 코드를 아래와 같이 바꿔보자.

 

 

여기에서 보다시피 변수를 꼭 알파벳 한 자리로 할 필요는 없다. 나중에 이게 어디에 쓰려는 변수였는지 까먹지 않도록 적당한 이름으로 만들어주면 된다. 변수로 쓸 수 없는 문자나 문구도 있는데, 그런 문자는 맞춤법 검사기에서 쓰지말라고 해주니까, 몇 번의 시행착오만 거치면 변수를 지정하는데 아무 문제가 없을 것이다. 무엇하고 있는가. 얼른 실행시켜보지 않고.

 

 

코드를 보고 이미 눈치 깠겠지만, 이건 3으로 지정된 a와 4로 지정된 b를 가지고 사칙연산하는 아주 간단한 프로그램이었다.

 

   더하기는 ‘+’, 빼기는 ‘-’, 곱하기는 ‘*’, 나누기는 ‘/’

 

그런데 사칙연산에 끼어있는 이교도 ‘%’ 때문에 사칙연산이 아닌 오칙연산이 돼버렸다. 도대체 ‘a % b’ 는 뭐하라는 소리일까?

 

그리고 3나누기 4의 정답은 0.75 이건만, 이녀석은 0이라고 대답했다. 어찌된 일일까. 우리는 어쩌면 오브젝티브씨의 사칙연산 오류를 발견한 것일까?

 

의문의 연산자 ‘%’, 그리고 나눗셈 오답의 비밀은 다음편에 공개된다.

 

 

아외로워

Ddanzi.Lonely@gmail.com

트위터 : @vforveri