brunch

매거진 Sinclair

라이킷 5 댓글 5

You can make anything
by writing

C.S.Lewis

계정을 잊어버리셨나요?

by Sinclair Feb 03. 2016

C언어 프로그래밍이란?

씽클레어, 컴퓨터에게 처음 작업을 걸다.

우리는 이제 { Sinclair ˚C* }를 통해 C언어 프로그래밍을 시작할 겁니다.

C언어라 함은 문법을 말하는 것입니다. 불어, 영어, 한국어 문법이 다르듯이 프로그래밍을 하는 데는 여러 가지 다양한 프로그래밍 언어가 존재합니다. 그 중에서 우리는 C언어를 선택했습니다.

사실 우리는 영어 때문에 정말 고민이 많죠? 그러면 먼저 우리의 모국어인 한국어를 제대로 공부해 보길 바랍니다. 제 경험상 한국어를 제대로 잘하면 영어도 자신 있게 잘 할 수 있다고 생각합니다. 물론 제가 영어나 한국어 전공자가 아니니 결과는 책임지지는 못합니다. 하하하~ 아무튼 프로그래밍을 공부할 때는 C언어 하나를 제대로 알게 되면 다른 언어도 환히 보인다는 겁니다. 그럴 수밖에 없는 것이 현존하는 거의 모든 언어의 조상이 바로 1960년대에 나온 ALGOL이라는 언어입니다. 그러니 프로그래밍언어의 족보를 확인해 보면 지금 사용하고 있는 거의 모든 언어들이 친인척 관계라는 거죠. 게다가 C언어는 얼마나 위대한 언어인지 C언어 이후에 나온 언어들이 거의 C언어와 비슷한 문법을 따르고 있습니다. 어때요 놀랍지 않나요? 그러니 이제는 C언어를 제대로 공부해야겠다는 의지가 막 샘솟지 않나요? 아직은 아니라고요?

C언어 문법에 대한 이야기는 앞으로 쭉 계속 할 것이니 먼저 프로그래밍에 대해 간단히 설명하겠습니다.

"프로그래밍이 뭐죠?" 이건 제가 Java를 강의하건, C++를 강의하건 간에 항상 먼저 하는 질문입니다.

자, 여러분들은 프로그래밍이 무엇이라고 생각합니까? 간단한 답을 원하세요? 아니면 심오한 답을 원하세요? 심오한 답을 원하신다면 프로그래밍 언어론 책을 보면 됩니다. 간단하게 말하자면 프로그래밍은 프로그램을 만드는 일입니다. 너무 간단하죠? 원래 진리는 간단한 법입니다. 그래서 위대하죠.

"그러면 프로그램이 뭐죠?" 항상 두 번째 질문은 이거죠.

우리가 프로그래머가 되어 프로그램을 만들 텐데 적어도 우리가 만드는 게 무엇인지는 알아야 하지 않겠습니까? 컴퓨터 프로그램 말고 그냥 프로그램 말입니다. 그러면 많은 사람들이 대답을 합니다. 여러 가지 복잡한 말들이 많이 떠오르겠지만 간단히 한마디로 하자면 프로그램은 바로 작업 순서를 말합니다. 뭐 쉽게 말해 작업의 정석이라고 불러도 괜찮을 듯 합니다. 하지만 그냥 작업 순서가 아니라 시간에 따른 작업 순서를 말합니다.

흠, 혹시 부산국제영화제(http://biff.kr)에 가보셨나요? 한번 가보세요. 공부만 열심히 하면 바보가 된다고 하죠? 프로그램만 열심히 짜면 마찬가지로 바보가 됩니다. 그런데 부산국제영화제에는 항상 프로그래머가 있습니다. 이상하죠? 그러면 대체 국제영화제 프로그래머는 어떤 언어로 무슨 프로그램을 짜는 걸까요? 그건 바로 국제영화제 기간 동안 언제 어느 상영관에서 어떤 영화를 상영할지를 프로그래밍하는 거죠.

요즘도 종이 신문을 보는 지 모르겠지만 예전에 신문은 오로지 석간 뿐이었던 제 어린 시절에 오후 늦게 신문이 오면 그 어린 나이에 제일 먼저 뛰어 나가 받아 들고 펼쳐 보던 면이 있었습니다. 사회면? 정치면? 스포츠? 문화면? 당연히 아니죠. 그건 바로 TV프로그램입니다. TV프로그램이란 것도 결국엔 방송국에서 진행하는 시간에 따른 작업 순서가 맞죠?

또 오페라나 뮤지컬 공연에 가면 공연프로그램이라고 파는 걸 많이 보았습니다. 공연 프로그램은 그 공연장에서 시간마다 어떤 공연을 하는 지 설명하고 있습니다.

그래서 간단하게 말하자면 컴퓨터 프로그램은 컴퓨터가 하는 시간에 따른 작업 순서를 말하는 겁니다. 하지만 이것이 예전에는 거의 맞는 말이었지만 지금은 많이 달라졌습니다. 바로 Event라는 개념이 도입되었기 때문입니다. 예전 프로그램들을 보면 대부분 프로그래머가 정해놓은 순서대로 한번 실행하고 그냥 종료해 버립니다. 하지만 지금 프로그램들은 한번 실행하고 종료하는 프로그램은 거의 없죠? 그랬다간 아주 큰일 납니다. 프로그램이 제 멋대로 종료하면 심각한 에러입니다. 이거 완전 "오류 보고하시겠습니까?" 입니다. 대부분의 프로그램들이 사용자가 원할 때까지 종료하지 않습니다. 마우스를 사용하거나 키보드를 사용해 이벤트를 발생시켜 사용자가 종료하고 싶다는 걸 프로그램에게 알려야 종료합니다.

20세기의 조용필님의 콘서트를 가보면 별다른 이벤트 없이 매번 같은 순서로 같은 노래를 같은 모습으로 부르고 같은 모습으로 끝냈던 걸로 기억합니다. 노래 하나로 승부합니다. 하지만 21세기의 이승환 아저씨 콘서트나 싸이 아저씨(?) 콘서트를 가보면 매번 다른 초대손님을 부르고 고객의 반응에 따라 다른 이벤트로 공연을 합니다.

프로그램도 마찬가지입니다. 예전에야 프로그램을 사용하는 사람들이 바로 프로그래머였습니다. 일반 사용자는 컴퓨터를 사용할 일이 전혀 없었습니다. 하지만 이제는 프로그래머들이 자신이 사용할 프로그램을 만드는 것이 아니라 일반 사용자들을 위해 프로그램을 만들고 있습니다. 때문에 프로그램들은 더 이상 프로그래머가 원하는 대로 진행하는 것이 아니라 사용자가 원하는 대로 움직여야 합니다. 물론 사용자로 하여금 프로그래머가 원하는 방향으로 요구하게 만들 수도 있겠습니다만 일반 사용자가 원하는 그것, 요구 사항을 잡아내는 기술을 바로 이벤트 처리라고 합니다. 이벤트와 관련된 부분은 이 { Sinclair ˚C* }의 분량을 한참 넘어가 버리는 관계로 더 이상 이야기하지 않겠습니다. 다른 좋은 자료를 참조하길 바랍니다.

매우 간단히 정리하면

프로그래밍은 프로그램을 만드는 일이고

일반적으로 프로그램은 바로 시간에 따른 작업 순서입니다.

프로그램이 작업 순서라는 것은 아주 중요합니다. 순서대로 해야 한다는 말입니다. 옛 우리 선조들은 '우물가서 숭늉 찾으랴?'라는 정말 멋진 명언을 남겼습니다. 그런데 요즘 프로그래머들의 모습을 보면 마치 멀리 우물이 보이기만 해도 숭늉을 찾는 게 아닌가 하는 생각이 들기 까지 합니다. 어떤 문제를 해결하기 위해 프로그래밍을 하면서 대부분 우리들이 가장 먼저 하는 것이 무엇인지 압니까? 바로 비주얼 스튜D5나 기타 에디터를 열고 열심히 타이핑하는 일입니다. 그러나 사실 어떤 문제가 발생하면 먼저 해결방법과 순서를 정해야 합니다. 해결방법과 순서를 정하는 일을 유식한 말로 알고리즘(문제를 해결하기 위한 절차나 방법)을 작성한다고 말합니다. 알고리즘은 어느 특정 언어에 한정되어 있지 않습니다. 때론 파스칼등 특정 언어를 사용하는 경우도 있고 그냥 일상 언어를 사용하기도 합니다. 또는 그림을 사용하기도 하는데 Flow Chart나 NS Chart도 있습니다. 객체지향 분석 방법론에서는 UML이라는 것을 사용하기도 합니다. 하지만 우리는 여기서 그냥 일상적인 언어로 작성해보도록 하겠습니다. 다양한 설계 방법론을 설명하고 있는 멋진 책들이 서점에 있고 정보의 바다 인터넷에 널려 있습니다.

아직도 잘 모르겠다고요? 흠... 예를 들자면 오늘 저녁을 일찍 먹어 밤늦게 배가 고파졌습니다. 그 배고픈 문제를 해결하기 위해 라면을 끓여 먹어야겠다는 생각을 했습니다. 자 이제 여러분들은 라면을 끓이기로 한 순간 무작정 라면을 끓인다고 생각하겠지만 자세히 기억을 더듬어 보면 정확하게 정해진 순서에 의해서 라면을 끓이지 않습니까? 물론 취향에 따라서 냉장고 안의 상태에 따라서 다른 프로세스(?)가 끼어들긴 하지만 다른 프로세스가 끼어드는 위치도 정해져 있는 법입니다. 작업 순서를 무시하고 라면을 끓이면 결국 꿀꿀이 죽이 되고 맙니다. 이게 바로 프로그래밍입니다. 간혹 외국인 친구들은 짜장라면이나 비빔라면을 물을 끓인 채로 스프를 넣어 먹고는 맛이 없다고 불평을 하더라구요. 잘못된 프로그래밍의 결과라 할 수 있습니다.

자 그럼 한번 제대로 라면을 끓여 볼까요? 일반적인 경우만 생각하겠습니다. 우리가 뭐 라면 집 차릴 일 있습니까? 라면 끓이는 자판기 제어 프로그램이라면 이야기가 되겠지만 말입니다.

라면 끓이기 알고리즘/작업순서

1. 먼저 라면이 있는지 확인한다.

(보통 먼저 라면이 있나 확인하죠? 라면도 없는데 물부터 끓이면 어쩝니까?

설마 물은 끓고 있는데 라면이 없다고 끓인 물만 따라 마시려는 건 아니겠지요?)

2. 라면이 있으면 다음으로, 없으면 사온다. (귀찮으신 분들은 그냥 주무시길)

3. 물을 끓인다. (언제까지 끓이죠? 팔팔 끓을 때까지? 그게 언제냐는 거죠?)

4. 물 온도 100℃ 인지 확인 후 100℃ 이면 다음으로, 아니면 3)으로

5. 스프와 면을 넣는다.
(스프를 먼저 넣는 게 맛이 더 좋답니다. 참고로 스프를 넣을 때 끓는점 때문에 갑자기 끓어 넘치는 경우가 있으니 부디 조심하시길… - 얼씨구 라면 집 안 차린다더니? ㅎㅎㅎ)

6. 다시 끓인다. (이번에도 100℃까지 끓일까요? 이미 100℃라니까요.)

7. 시간 3분 경과 확인 후 경과 되었으면 다음으로, 경과 되지 않았으면 6)으로

8. 맛있게 냠냠 (설거지는 설거지 알고리즘을 사용하시길)

다시 한번 말씀 드리지만 일반적인 경우입니다. 푹 삶기 원하면 시간을 5분으로 늘이거나 꼬들꼬들한 게 좋으면 시간을 2분20초 정도로 줄이면 됩니다. 끓일 그릇이 없습니까? 뽀글이로 해 드세요. 중간에 가스가 떨어졌다? 뿌셔뿌셔도 있지 않습니까?

그러면 고작 라면이나 끓이려고 이 { Sinclair ˚C* }를 읽는 줄 아냐? 생각하는 분들이 있을 듯 해서 전화 걸기로 넘어가겠습니다. 다들 이제는 1인 1전화 시대인지라 모두들 휴대용 단말기를 가지고 있겠지만 아련한 옛추억(?)을 떠올리면서 일반 전화기로 전화 걸기에 도전(?) 해보도록 하겠습니다. 일반전화 걸어본 지가 하도 오래되 놔서 기억이 가물가물합니까? 자, 기억을 더듬어 보죠.

일반 전화 걸기 알고리즘/작업순서

1. 수화기를 든다.

2. 신호음을 확인한다. (휴대용 단말기는 원래 신호음이 안 들리죠?)

3. 신호음이 안 들리면 9)으로, 들리면 다음으로
(신호음도 안 들리는데 어쩔려구요?)

4. 다이얼을 돌린다.

5. 다이얼이 늦었다는 메세지 or 없는 번호라는 알림 메세지가 들리면 후크 스위치를 눌렀다 떼고 2)이나 10)으로

혹은 통화 중 인지 확인 후 통화 중이면 수화기를 내려놓고 9)으로, 아니면 다음으로

6. 발신음이 들리면 발신음을 하나씩 센다.

7. 발신음 횟수가 10이면 후크 스위치를 눌렀다 떼고 2)이나 9)로, 아니면 다음으로

8. 상대방이 받으면 용건만 간단히 하고 9)로, 상대방이 받지 않으면 6)으로

9. 조용히 수화기를 내려놓고

10. 통화종료

이것도 물론 일반적인 경우의 전화 걸기 알고리즘입니다.

전화를 잘못 걸었다면? 그야 프로그램 한번 더 돌리면 되죠. 간혹 잘못 걸린 전화가 인연이 되기도 합니다만...(영화를 너무 많이 봤어!!!)

이렇게 알고리즘을 세워가면서 라면을 끓여보고 전화를 걸어보니 어떤가요? 아주 간단한 작업인 듯 했지만 의외로 생각할 것들이 많다는 것을 느꼈을 겁니다. 이렇게 우리가 문제를 분석하고 프로그램의 알고리즘을 작성할 때 반드시 기억해야 할 사실은 모든 가능성을 다 고려해야 한다는 것입니다. 라면 끓이기 경우에서도 보면 냄비가 없다거나 가스가 끊기거나 하게 되면 어떻게 해야 하는 지 미리 염두 해 두지 않으면 나중에 실제 문제가 발생했을 때 해결할 수 없게 됩니다. 뭐 그렇게 인생을 그렇게 빡빡하게 살려고 하느냐 생각할 분들도 있지만 매우 중요하며 반드시 그렇게 하셔야 합니다. 나중에 문제가 발생할 때 고치려고 하면 너무 늦습니다. 이 세상 가장 어리석은 바보는 바로, 늘 '에이, 다음에 하지'라고 뒤로 미루는 사람입니다. 제 프로그래머 인생을 돌이켜 보면 늘 계획 없이 프로그래밍을 하다가 수많은 버그와 에러에 휩싸여 발표 일을 계속 뒤로 미루고 미루다가 결국 수많은 버그와 함께 험한 세상에 자식 같은 프로그램들을 고아처럼 내보냈던 날들의 연속이 아닌가 하는 후회가 마음 가득합니다. 저는 바보처럼 살았지만 여러분은 멋진 프로그래머가 되길 바랍니다. 너나 잘하세요 라고 하면 뭐 할 말은 없습니다. 앞으로는 열심히 잘하겠습니다. 하지만 레오나르도 다빈치가 처음 비행기를 설계하면서 비행기가 잘못 될 때를 미리 예상하고 낙하산도 같이 설계했다는 것은 우리에게 많은 것을 느끼게 해줍니다.

전화 걸기도 시시하죠?

그럼 이번에는 이차방정식의 근을 구하는 프로그램을 한 번 생각해 보겠습니다. 먼저 이차방정식이 무엇인지 알아야겠죠? 중학교 시절 배운 건데 기억이 가물가물하죠? 사실 저는 이차방정식의 근을 구하는 프로그램을 잊을 수가 없습니다. 제가 머리털 나고 처음으로 직접 작성한 프로그램이 바로 이차방정식의 근을 구하는 프로그램이었습니다. 그때는 포트란으로 종이에 작성했었는데 세월이 무상하네요. ( 너 나이가 몇이니? )

이차방정식 aX² + bX + c = 0 의 수식에서 a, b, c값이 주어질 때 X의 두 근을 구하는 방법입니다. 근의 공식과 판별식을 사용해야 한다는 건 기억나죠?

(선행 조건)

정수형 a, b, c값 만을 입력 받는다.

판별식 d = b² – 4 ac

근의 공식 판별식 d가 0이면 중근, X = -b / 2a

d가 0보다 크면 실근 X = (-b±√d )/ 2a

d가 0보다 작으면 허근 X = (-b±√-di)/ 2a (허근도 구할 겁니다.)

그러면 이 조건을 사용해 이차방정식의 근을 구하는 알고리즘을 생각해보죠. 잘 따라 오셔야 합니다. 이 알고리즘을 가지고 나중에 C프로그램을 작성할 겁니다.

이차방정식의 근을 구하는 알고리즘

1. 사용 변수를 초기화 한다.

2. a, b, c값을 정수 형으로 입력 받는다.

2'. a값이 0인지 확인(∵ a값이 0이면 일차방정식이잖아요. 안 그래요?)
(이 부분에서 a값을 입력 받을 때 먼저 체크하고 b, c값을 입력 받을지, 모든 값을 다 입력 받은 후 체크하여 또 다시 전체 값을 다시 입력 받을지 결정해야죠.)

3. a값이 0이면 2)로 0이 아니면 다음으로

4. 판별식 d를 구한다.

5. d가 0이면 중근을 구하고 d가 0보다 크면 실근, 0보다 작으면 허근을 구한다.

6. 근을 출력한다.

물론 여기서도 a값이 0일 때 다시 입력 받지 않고 1차 방정식으로 계산할 수도 있습니다. 우리가 지금 이렇게 알고리즘을 작성하고 있으니 그것을 결정할 수 있겠죠?

하지만 늘 하던 대로 타이핑을 시작했다면 중간에 잘못된 값이 입력되었을 때 프로그램은 이상한 동작을 하게 될 겁니다. a가 0이면 근의 공식에서 0으로 나누게 되는 어마 무시한 실수를 저지르게 됩니다. (앗, 이런 나의 실수?)

어떻습니까? 이제 알고리즘을 생각했으니 이 알고리즘을 가지고 C프로그램을 작성해야죠? 그런데 머가 그렇게 급합니까?

앞으로 쭈욱 프로그래밍은 내 운명이 되도록 프로그램만 짜게 될 것입니다. 하지만 그 전에 여러분에게 중요한 몇 가지 이야기를 더 해야겠습니다.

우리는 앞에서 프로그램이 무엇인지 배웠습니다. 그런데 어느 날 길을 걷고 있는데 어떤 사람이 다가오더니 "프로그래머의 기운이 느껴지시네요. 저기 혹시 프로세스에 대해 아십니까?"라고 하며 길을 막아 선다면 어떻게 대답하겠습니까?

설마 그런 일이 있겠습니까마는 그때 바로 "프로세스는 현재 실행 중인 프로그램입니다."라고 대답하면 됩니다.

프로세스가 무엇이냐 라는 정의를 내리기 위해서는 몇 백 페이지 짜리 논문을 줄줄이 읊어야 할지도 모르겠습니다. 하지만 그것을 다 이야기하고도 "현재 실행 중인 프로그램"이란 말을 빼먹었다면 그건 틀린 내용 일 수도 있습니다. 왜냐하면 일반적으로 프로그램이 실행되면 프로세스라고 부르기 때문입니다. 다시 말해 프로그램은 하드 디스크, 플로피 디스크, 컴팩트 디스크 등 물리적인 저장장치에 존재하고 프로세스는 메모리에 존재하게 됩니다.

프로그램이 실행되면 메모리에 올라가 프로세스가 된다.

이렇게 단순한 명제가 왜 중요할까요? 그건 바로 메모리에 올라가면 반드시 주소 값을 갖는다는 것 때문입니다. 모든 프로그램의 요소는 메모리에 올라가야 실행이 되고 메모리에 올라가면 반드시 주소 값을 갖게 됩니다. 주소 값을 갖지 않는 프로그램 요소는 레지스터 변수 말고는 없습니다. 이렇게 주소 값을 가지기 때문에 C의 포인터를 사용할 수 있습니다. C의 포인터는 바로 주소 값을 담기 위한 데이터 타입이기 때문입니다.

포인터 이야기가 나오자 이마를 찌푸리는 분이 있을 텐데 저는 포인터가 나오면 차라리 죽고 싶었습니다.

그러다가 포인터가 없다는 이유 하나만으로 Java를 배우고 Java 프로그램을 짜고 심지어 북한의 엔지니어들에게까지 Java를 강의했던 사람입니다. (혹시종북이냐?) 하지만 포인터가 없다는 Java 프로그램을 짜다 보면 종종 만나는 에러가 있었습니다. 그건 바로 NullPointerException이었습니다. 포인터가 없다던 Java에서 만난 NullPointerException은 저를 충분히 좌절시키고도 남음이 있었습니다. '아, 포인터를 피해 Java로 왔더니 여기에도 포인터가 있구나. 정녕 프로그래머는 나의 길이 아니란 말이더냐?' 라고 까지 생각했습니다. Java 프로그램도 메모리에 올라가야 실행된다는 작은 진리를 몰랐던 것입니다. Java에는 포인터가 없는 게 아닙니다. 다만 감춰놓았을 뿐입니다.

그런데 말입니다...

이제 포인터를 제대로 이해하니 메모리가 제대로 보이기 시작했습니다. 다른 어떤 프로그램을 짜더라도 두렵지 않습니다. 사실 이 { Sinclair ˚C* }를 쓰게 된 이유도 바로 그것을 여러분들과 함께 나누기 위함입니다. 게다가 저는 컴퓨터의 '컴'자도 모르던 사람이었습니다. 심지어 제가 고등학교 때 문과였다면 이제 희망이 보입니까?

어떻게 하면 프로그램을 잘 짤 수 있을까요?

저도 프로그램을 잘 짜고 싶어요. 프로그래밍 고수가 되려면 어떻게 해야 할까요? 고민하는 여러분들께 두 가지 부탁을 드리겠습니다.

첫째 자료 구조와 컴퓨터 구조를 공부하기 바랍니다. 컴퓨터 프로그래밍은 컴퓨터에게 작업을 시키는 일입니다. 그러려면 컴퓨터가 무엇을 좋아하는지 알아야 하지 않겠습니까? 여자친구나 남자친구에게 작업을 걸 때도 많은 준비를 하셨으면서 컴퓨터에게 작업을 거는데 겨우 이 정도 준비로 되겠습니까? 매우 중요한 일입니다. 제 마음 같아서는 이 { Sinclair ˚C* }를 덮고 먼저 자료 구조와 컴퓨터 구조를 먼저 공부하라고 하고 싶습니다.

둘째 다양한 생각을 키우기 바랍니다. 21세기는 다양성의 시대입니다. 고객의 다양한 요구사항을 만족시키려면 프로그래머가 먼저 다양한 사고력을 지녀야 하는 것은 당연합니다. 한가지 사물을 바라보더라도 한번 뒤집어 보고 다르게 생각해보기 바랍니다. 사고력도 훈련입니다. 다른 사람과 같다면 다른 프로그램과 같을 수 밖에 없습니다. 다양한 사고력을 갖기 위해 가장 좋은 방법은 스스로 많은 경험을 쌓는 것입니다. 모든 것을 다 경험할 수 없다면 독서도 좋은 방법입니다. 저는 영화를 많이 보는 편입니다. 여러 다양한 장르의 영화를 보면서 다양한 경험을 대신합니다. 작은 컴퓨터 모니터로 불법으로 다운받은 영화만 감상하지 말고 오늘은 다른 복잡한 모든 것을 접어두고 오랜만에 영화관 나들이 한 번 해보면 어떨까요? 자 이번 chapter 글의 과제는 영화관에 가서 영화 한 편 보고 오기 입니다. 어떤 영화여도 괜찮습니다. 자, 자.. 이제 { Sinclair ˚C* }를 덮죠!!!

자 영화는 잘 보셨나요? 영화를 보고 오셨다면 이걸 한번 풀어보시죠.
아주 넓은 공간 한가운데 작은 구멍이 있고 그 구멍에 아주 작은 탁구공 하나가 빠졌습니다.
손을 넣어보니 들어가지도 않습니다.
그리고 주변에는 어떤 도구도 없을 뿐만 아니라 도구를 사용할 수도 없습니다.
또한 구멍을 넓힐 수도 없다고 합니다.
하지만 24시간 안에 그 탁구공을 꺼내야 합니다. 자, 오직 탁구공과 여러분뿐입니다.
어떻게 해야 할까요? 한번 생각해 보세요.
이것은 결코 넌센스 문제가 아닙니다.
문제를 해결하는 방법은 정말 다양합니다.