C 프로그래머가 알아야할 것들 - Chapter 4. 프로그램 언어
김성훈 (sunghun84@nate.com)
Chapter 4. 프로그램 언어
(1) 왜 문법을 배워야하는가?
(2) 내가 이걸 배워서 과연 실전에 사용할 수 있을까?
(3) 무엇을 위한 프로그램인가?
(1) 왜 문법을 배워야 하는가?
사실 이건 당연한 이야기 일 수 있는데요, 한국어를 할줄 모르는 독일인과, 독일어를 할줄 모르는 한국인과 대화가 가능할까요? 바디 랭귀지로 하면 되지 않느냐는 분도 계시겠지만 그것도 어느정도 한계가 있기에, 제대로된 의사소통은 불가능할겁니다.
컴퓨터는 0과 1 (2진수)밖에 인식하지 못한다고 앞에서 배웠습니다.
그렇다고 컴퓨터에게 00001110 01010101 이런식으로 모든 명령을 내려야한다면 프로그래머는 정말 수학에 능통한 사람이 아니면 힘들껍니다. (수학에 능통하더라도, 구현할 수 있는 수준은 한계가 있겠죠)
그래서, 기계어에서는 16진수 (2진수를 4개씩 묶어서) 표현하고 있습니다. 2진수일 때보다 조금 나아졌지만, 과연 이걸로 프로그램을 만들 수 있을까요? 이걸로도 뭔가 많이 부족해보입니다.
좀 더 사용자(프로그래머)가 이해하기 쉬운 언어가 필요했습니다.
그래서 나온 어셈블리어는 좀 더 사용자가 알기 편하게 하기 위해, 오퍼랜드, 오퍼레이터, 명령 니모닉등으로 구성되어 있는데, 그렇기에 프로그래머가 기계어보다는 이해하기 쉬웠습니다만, 규모가 큰 프로그램에는 적합하지 못했죠.
결국 프로그래머가 사용하기도 편하고, 기능도(비교적) 우수한 구조형 언어 (파스칼, 코볼,포트란, C언어)등이 나오게되었습니다.
프로그램 언어를 통해 컴퓨터에게 일을 시키기 위해선 어떻게 해야 할까요?
"야 지금부터 시간재라". "야 지금부터 음악 재생좀 해봐."
이렇게 컴퓨터에게 우리가 사용하는 말로 말하면 알까요? (음성인식 프로그램은 예외입니다) 컴퓨터는 컴퓨터가 알 수 있는 말로 해야하기 때문에, 기계어로 말하는건 사실상 불가능에 가까우니, 프로그램 언어의 힘을 빌려야하는데, 그 프로그램 언어가 가진 규칙이 문법입니다. 프로그래머가 컴퓨터와 의사소통을 하기 위해선, 사용하는 프로그램 언어의 문법을 지켜야만 원하는 일을 시키고, 컴퓨터에게 상황을 보고 받을 수 있기 때문에 문법에 대해 알아야 하는건 당연하겠죠?
(2) 내가 이걸 배워서 과연 실전에 사용할 수 있을까?
많은 분들이 하시는 고민. 지금 이 글을 쓰고 있는 저도 마찬가지였던 고민.
바로 그것이 과연 지금 배운 문법들로 프로그램을 만들 수 있겠는가 하는것입니다.
당연한 얘기지만, 정답은 "그렇다"는 것입니다.
그런데, 왜 문법까진 이해했는데, 왜 난 프로그램을 만들 수 없을까하는 생각을 하시는 분들이 많은데요, 그 이유는 프로그래밍에 대한 막연함과, 프로그램 개발 과정에 대한 부족한 이해도등의 이유도 있고, 또 프로그램을 구성하고 있는 기본 법칙이나 내부 원리에 대한 이해가 부족한 이유도 있습니다.
프로그래밍에 대한 막연함이란, 입문서 혹은 문법서에 나온 에제정도만 작성해보았지, 실제 사용할 만한 프로그램 개발 경험이 전무하기 때문에 가지는 부담감이라 할 수 있을겁니다.
프로그램 개발과정에 대한 부족한 이해도란, 프로그래밍이란 단순히 프로그램 언어만 안다고 되는 그런 간단한 것이 아닙니다. 프로그래머는 속도와 메모리의 최적화를 해야할 사명이 있는 것이고, 그것은 하드웨어의 발달과는 무관하게 당연한 것입니다. 프로그램의 개발 과정에는 분석,설계등의 선행 작업이 있고, 분석 과정은 개발할 프로그램이 무엇을 필요로 하고, 무엇이 필요한지, 설계과정에서는 데이터 구조, 사용할 알고리즘등 정해야하죠. 그리고 그것을 문서화하는데, 이러한 과정들이 없이 막연히 어떠한 프로그램을 만든다는 것은 한계가 있고, 그러한 프로그램들은 유지보수, 또는 재사용은 불가능에 가깝다고 봐야합니다. (이 부분은 XP=eXtream Programming과 의견을 달리하는데, 그 방법을 무시하는 것이 아니라, 저는 이 방식이 옳은 방식이라고 보기 때문입니다) 차근 차근 하나 하나 설계해나가고, 작성해나가면 생각보다 쉽게 풀립니다.
한마디로, 소프트웨어 개발 방법론에 대한 이해가 필요하다는 것이죠.
프로그램은 기본적으로 순차적이고, 그 분기는 순환문 또는 조건문을 통해 이루어지고 있고, 처리 과정이 계산을 통해 이루어져있다는 것만 이해한다면, 그다지 어려운 것이 아닙니다.
컴퓨터의 내부 원리에 대한 이해도 기본적으로 되어있어야 어떻게 프로그램을 구성해야 될지 감이 오게됩니다. (추상화=캡슐화를 통해 이런 부분까지 알지 않아도 가능한 시대가 왔다는 사람들도 있지만, 여전히 이 것에 대한 이해는 중요합니다) 우리는 API를 사용함으로써 키보드 장치에 대한 프로그래밍을 하지 않아도, 키보드 입력에 관한 정보를 얻을 수 있고, 어떤식으로 화면이 점을 찍는지 내부원리를 알지 못해도, SetPixel()함수를 통해서 점을 찍을 수 있습니다. 이 것은 매우 유용하고 저를 비롯하여 많은 프로그래머들이 이런 기능을 사용하고 있습니다. 그렇지만, 점을 어떤식으로 화면상이 표시하는지에 대한 원리, 키보드 입력이 어떻게 하여 프로그램으로 메시지로 전달되는지에 대한 이해가 되어있는 사람과, 그렇지 않은 사람과의 실력차이는 분명합니다.
근본 원리를 알고 있는 사람은 좀 더 멀리 내다볼 수 있고, 신 기술에 대한 적응도 빠릅니다. 음악파일의 근본 원리를 아는 사람은, 새로운 포맷을 만들어 낼 수도 있고, 압축과 신장 방법을 알아낼 수 있는등, 그 것의 효율적인 사용법을 알아 낼 수도 있지만, 원리는 모르고 MFC혹은 각종 라이브러리에서 제공하는 함수의 사용법만으로 프로그램을 개발하는 사람은 그 함수가 지원하는 기능으로 프로그램을 구성하는 그 이상은 불가능합니다.
문법을 배워서 실전(프로그래밍)에 사용할 수 있는 것은 가능한 일이고 당연한 일이지만, 더 좋은 프로그램, 더 나은 프로그래밍을 위해서는, 프로그램 언어 이외에도 배워야할 것들이 많고, 그것들을 놓치면 안되는것입니다.
(3) 무엇을 위한 프로그램인가?
프로그램이란 사용자를 위한 것입니다. 우리나라에서는 각종 시스템이 사용자 혹은 고객을 위한 경우가 매우 드뭅니다. (요새는 많이 나아진 편이지만, 그렇지 않은 곳이 여전히 존재하죠.) 기능의 업그레이드나, 버그 수정은 말할거 없이 '당연한'것이고, 부가적으로 사용자 입장을 고려한 프로그램이 개발 되어야하는데, 이 것도 부족한 경우가 상당히 많습니다.
저같은 경우는 자주 사용하는 기기가, 게임기, 컴퓨터, MP3정도인데, 가장 불만인 것이 이 MP3입니다. 해당 개발업체가 아니면 수정할수 없는 펌웨어의 경우 좀 더 신중한 테스트가 필요하고, 사용과정에서 쉽게 눈에 띄는 버그는 존재해선 안됩니다. 자주 발생하지 않는 특정상황이나, 특정 환경에서만 발생하는 버그가 아니라면 말이죠.
어떠한 프로그램이던지, 버그로부터 자유로울 수는 없습니다. 우리가 입문서등에서 가장 처음 접하는 "Hello World!"라는 문장을 출력하는 간단한 프로그램마저도여타 프로그램과 충돌또는 예기치 못할 문제에 이해 오작동할 가능성도 배재할 수 없습니다. 하지만, 눈에 보이는 버그. 테스트 과정에서 쉽게 발견할 수 있는 버그의 경우는 발견즉시 수정을 위한 노력을 기울여야하고, 기업은 자신들이 발매한 프로그램에 대한 문제수정을 위한 인력(프로그래머든, AS직원이든)을 배치해둘 필요가 있습니다. 이런 기본적인 사용자를 위한 배려도 되지 않는다는 것은 상식적으로 이해할 수 없는 일이지만, 이런 일이 빈번하게 벌어지고 있다는 것이 문제입니다.
프로그램 개발 기간에 대한 이야기도 해보자면, 투자자 혹은 기업주의 압박과 독촉에 의하여, 충분한 테스트 기간과, 완성도를 갖추지 못하고 제품이 출시되는 경우가 종종 있습니다. 이런 사례는 게임업계에서 유독 심한걸로 알려져있는데, 요새야 온라인 게임이 대세이다보니 클로즈베타, 오픈베타과정을 거쳐 정식 서비스를 하기에 이런 문제가 적어지고 있는 추세지만, 이전 PC패키지 게임이 주를 이루던 시기에 버그로 인한 사용자의 피해는 말도 못할정도였습니다. (마그나 카르타와, 포가튼 사가는 두고 두고 화자되고 있지요. 창세기전 시리즈, 어스토니시아 스토리,화이트 데이등 국내에서 손꼽히는 명작들도 버그로 인해 그 작품성에 흠을 내곤했으니 말이죠.) 개발자들의 노고와 힘든 상황을 이해 못하는 것은 아니지만, 그것은 자신들의 상황을 핑계로 사용자에게 피해를 입히는 행위로, 이런일이 다신 벌어지지 않아야할 것이고, 그러기 위해서는 개발자들을 위한 환경이 지금보다 많이 개선되어야하겠고, 개발자들도 사용자를 위해 완성도 높은 프로그램을 목표로 꾸준히 노력하는 자세를 가지도록해야한다고 생각합니다.
김성훈 (sunghun84@nate.com)
Chapter 4. 프로그램 언어
(1) 왜 문법을 배워야하는가?
(2) 내가 이걸 배워서 과연 실전에 사용할 수 있을까?
(3) 무엇을 위한 프로그램인가?
(1) 왜 문법을 배워야 하는가?
사실 이건 당연한 이야기 일 수 있는데요, 한국어를 할줄 모르는 독일인과, 독일어를 할줄 모르는 한국인과 대화가 가능할까요? 바디 랭귀지로 하면 되지 않느냐는 분도 계시겠지만 그것도 어느정도 한계가 있기에, 제대로된 의사소통은 불가능할겁니다.
컴퓨터는 0과 1 (2진수)밖에 인식하지 못한다고 앞에서 배웠습니다.
그렇다고 컴퓨터에게 00001110 01010101 이런식으로 모든 명령을 내려야한다면 프로그래머는 정말 수학에 능통한 사람이 아니면 힘들껍니다. (수학에 능통하더라도, 구현할 수 있는 수준은 한계가 있겠죠)
그래서, 기계어에서는 16진수 (2진수를 4개씩 묶어서) 표현하고 있습니다. 2진수일 때보다 조금 나아졌지만, 과연 이걸로 프로그램을 만들 수 있을까요? 이걸로도 뭔가 많이 부족해보입니다.
좀 더 사용자(프로그래머)가 이해하기 쉬운 언어가 필요했습니다.
그래서 나온 어셈블리어는 좀 더 사용자가 알기 편하게 하기 위해, 오퍼랜드, 오퍼레이터, 명령 니모닉등으로 구성되어 있는데, 그렇기에 프로그래머가 기계어보다는 이해하기 쉬웠습니다만, 규모가 큰 프로그램에는 적합하지 못했죠.
결국 프로그래머가 사용하기도 편하고, 기능도(비교적) 우수한 구조형 언어 (파스칼, 코볼,포트란, C언어)등이 나오게되었습니다.
프로그램 언어를 통해 컴퓨터에게 일을 시키기 위해선 어떻게 해야 할까요?
"야 지금부터 시간재라". "야 지금부터 음악 재생좀 해봐."
이렇게 컴퓨터에게 우리가 사용하는 말로 말하면 알까요? (음성인식 프로그램은 예외입니다) 컴퓨터는 컴퓨터가 알 수 있는 말로 해야하기 때문에, 기계어로 말하는건 사실상 불가능에 가까우니, 프로그램 언어의 힘을 빌려야하는데, 그 프로그램 언어가 가진 규칙이 문법입니다. 프로그래머가 컴퓨터와 의사소통을 하기 위해선, 사용하는 프로그램 언어의 문법을 지켜야만 원하는 일을 시키고, 컴퓨터에게 상황을 보고 받을 수 있기 때문에 문법에 대해 알아야 하는건 당연하겠죠?
(2) 내가 이걸 배워서 과연 실전에 사용할 수 있을까?
많은 분들이 하시는 고민. 지금 이 글을 쓰고 있는 저도 마찬가지였던 고민.
바로 그것이 과연 지금 배운 문법들로 프로그램을 만들 수 있겠는가 하는것입니다.
당연한 얘기지만, 정답은 "그렇다"는 것입니다.
그런데, 왜 문법까진 이해했는데, 왜 난 프로그램을 만들 수 없을까하는 생각을 하시는 분들이 많은데요, 그 이유는 프로그래밍에 대한 막연함과, 프로그램 개발 과정에 대한 부족한 이해도등의 이유도 있고, 또 프로그램을 구성하고 있는 기본 법칙이나 내부 원리에 대한 이해가 부족한 이유도 있습니다.
프로그래밍에 대한 막연함이란, 입문서 혹은 문법서에 나온 에제정도만 작성해보았지, 실제 사용할 만한 프로그램 개발 경험이 전무하기 때문에 가지는 부담감이라 할 수 있을겁니다.
프로그램 개발과정에 대한 부족한 이해도란, 프로그래밍이란 단순히 프로그램 언어만 안다고 되는 그런 간단한 것이 아닙니다. 프로그래머는 속도와 메모리의 최적화를 해야할 사명이 있는 것이고, 그것은 하드웨어의 발달과는 무관하게 당연한 것입니다. 프로그램의 개발 과정에는 분석,설계등의 선행 작업이 있고, 분석 과정은 개발할 프로그램이 무엇을 필요로 하고, 무엇이 필요한지, 설계과정에서는 데이터 구조, 사용할 알고리즘등 정해야하죠. 그리고 그것을 문서화하는데, 이러한 과정들이 없이 막연히 어떠한 프로그램을 만든다는 것은 한계가 있고, 그러한 프로그램들은 유지보수, 또는 재사용은 불가능에 가깝다고 봐야합니다. (이 부분은 XP=eXtream Programming과 의견을 달리하는데, 그 방법을 무시하는 것이 아니라, 저는 이 방식이 옳은 방식이라고 보기 때문입니다) 차근 차근 하나 하나 설계해나가고, 작성해나가면 생각보다 쉽게 풀립니다.
한마디로, 소프트웨어 개발 방법론에 대한 이해가 필요하다는 것이죠.
프로그램은 기본적으로 순차적이고, 그 분기는 순환문 또는 조건문을 통해 이루어지고 있고, 처리 과정이 계산을 통해 이루어져있다는 것만 이해한다면, 그다지 어려운 것이 아닙니다.
컴퓨터의 내부 원리에 대한 이해도 기본적으로 되어있어야 어떻게 프로그램을 구성해야 될지 감이 오게됩니다. (추상화=캡슐화를 통해 이런 부분까지 알지 않아도 가능한 시대가 왔다는 사람들도 있지만, 여전히 이 것에 대한 이해는 중요합니다) 우리는 API를 사용함으로써 키보드 장치에 대한 프로그래밍을 하지 않아도, 키보드 입력에 관한 정보를 얻을 수 있고, 어떤식으로 화면이 점을 찍는지 내부원리를 알지 못해도, SetPixel()함수를 통해서 점을 찍을 수 있습니다. 이 것은 매우 유용하고 저를 비롯하여 많은 프로그래머들이 이런 기능을 사용하고 있습니다. 그렇지만, 점을 어떤식으로 화면상이 표시하는지에 대한 원리, 키보드 입력이 어떻게 하여 프로그램으로 메시지로 전달되는지에 대한 이해가 되어있는 사람과, 그렇지 않은 사람과의 실력차이는 분명합니다.
근본 원리를 알고 있는 사람은 좀 더 멀리 내다볼 수 있고, 신 기술에 대한 적응도 빠릅니다. 음악파일의 근본 원리를 아는 사람은, 새로운 포맷을 만들어 낼 수도 있고, 압축과 신장 방법을 알아낼 수 있는등, 그 것의 효율적인 사용법을 알아 낼 수도 있지만, 원리는 모르고 MFC혹은 각종 라이브러리에서 제공하는 함수의 사용법만으로 프로그램을 개발하는 사람은 그 함수가 지원하는 기능으로 프로그램을 구성하는 그 이상은 불가능합니다.
문법을 배워서 실전(프로그래밍)에 사용할 수 있는 것은 가능한 일이고 당연한 일이지만, 더 좋은 프로그램, 더 나은 프로그래밍을 위해서는, 프로그램 언어 이외에도 배워야할 것들이 많고, 그것들을 놓치면 안되는것입니다.
(3) 무엇을 위한 프로그램인가?
프로그램이란 사용자를 위한 것입니다. 우리나라에서는 각종 시스템이 사용자 혹은 고객을 위한 경우가 매우 드뭅니다. (요새는 많이 나아진 편이지만, 그렇지 않은 곳이 여전히 존재하죠.) 기능의 업그레이드나, 버그 수정은 말할거 없이 '당연한'것이고, 부가적으로 사용자 입장을 고려한 프로그램이 개발 되어야하는데, 이 것도 부족한 경우가 상당히 많습니다.
저같은 경우는 자주 사용하는 기기가, 게임기, 컴퓨터, MP3정도인데, 가장 불만인 것이 이 MP3입니다. 해당 개발업체가 아니면 수정할수 없는 펌웨어의 경우 좀 더 신중한 테스트가 필요하고, 사용과정에서 쉽게 눈에 띄는 버그는 존재해선 안됩니다. 자주 발생하지 않는 특정상황이나, 특정 환경에서만 발생하는 버그가 아니라면 말이죠.
어떠한 프로그램이던지, 버그로부터 자유로울 수는 없습니다. 우리가 입문서등에서 가장 처음 접하는 "Hello World!"라는 문장을 출력하는 간단한 프로그램마저도여타 프로그램과 충돌또는 예기치 못할 문제에 이해 오작동할 가능성도 배재할 수 없습니다. 하지만, 눈에 보이는 버그. 테스트 과정에서 쉽게 발견할 수 있는 버그의 경우는 발견즉시 수정을 위한 노력을 기울여야하고, 기업은 자신들이 발매한 프로그램에 대한 문제수정을 위한 인력(프로그래머든, AS직원이든)을 배치해둘 필요가 있습니다. 이런 기본적인 사용자를 위한 배려도 되지 않는다는 것은 상식적으로 이해할 수 없는 일이지만, 이런 일이 빈번하게 벌어지고 있다는 것이 문제입니다.
프로그램 개발 기간에 대한 이야기도 해보자면, 투자자 혹은 기업주의 압박과 독촉에 의하여, 충분한 테스트 기간과, 완성도를 갖추지 못하고 제품이 출시되는 경우가 종종 있습니다. 이런 사례는 게임업계에서 유독 심한걸로 알려져있는데, 요새야 온라인 게임이 대세이다보니 클로즈베타, 오픈베타과정을 거쳐 정식 서비스를 하기에 이런 문제가 적어지고 있는 추세지만, 이전 PC패키지 게임이 주를 이루던 시기에 버그로 인한 사용자의 피해는 말도 못할정도였습니다. (마그나 카르타와, 포가튼 사가는 두고 두고 화자되고 있지요. 창세기전 시리즈, 어스토니시아 스토리,화이트 데이등 국내에서 손꼽히는 명작들도 버그로 인해 그 작품성에 흠을 내곤했으니 말이죠.) 개발자들의 노고와 힘든 상황을 이해 못하는 것은 아니지만, 그것은 자신들의 상황을 핑계로 사용자에게 피해를 입히는 행위로, 이런일이 다신 벌어지지 않아야할 것이고, 그러기 위해서는 개발자들을 위한 환경이 지금보다 많이 개선되어야하겠고, 개발자들도 사용자를 위해 완성도 높은 프로그램을 목표로 꾸준히 노력하는 자세를 가지도록해야한다고 생각합니다.
'프로그래밍 > C | C++' 카테고리의 다른 글
문자열 처리 함수 정리 (0) | 2013.08.14 |
---|---|
FFMPEG 압축 기본적인 사용법 (0) | 2013.08.14 |
[펌] C 프로그래머가 알아야할 것들 #3 (0) | 2013.08.14 |
[펌] C 프로그래머가 알아야할 것들 #2 (0) | 2013.08.14 |
[펌] C 프로그래머가 알아야 할 것들 #1 (0) | 2013.08.14 |