* about Network..

함수 사용, 파일 분리, 그리고 linkage
시작부터 조금 당혹스러운 내용이 되었을지도 모르겠습니다. 다시 눈높이를 약간만 낮춰 함수와 분할 컴파일, 그리고 분할 컴파일을 위한 make에 대해서 조금만 알아보도록 하겠습니다.
아주 당연한 질문이지만 왜 소스 코드를 여러 파일에 분리해서 작성해야 할까요? 꼭 이렇게 해야 할 필요는 없습니다. 프로그램을 작성하는 것은 결국 실행 파일을 만들어내기 위해서이고 따라서 1만 라인 정도 되는 프로그램이라 하더라도 소스 파일 하나에 프로그래밍해도 별로 관계는 없습니다. 실행 파일만 제대로 생성되면 상관없다는 의미입니다. 문제는 이것이 간단한 프로그램 몇 개를 만드는 정도라면 상驩平嗤?조금 프로젝트의 규모가 커지기 시작하면 관리가 불가능해진다는 데에 있습니다. 1만 라인 정도 되는 소스 코드를 한 파일에 작성해놓고 찾아다니면서 프로그램을 수정하는 것은 거의 불가능에 가깝습니다.
하지만 또 하나 중요한 이유가 있습니다. 컴파일에 걸리는 시간 때문입니다. 프로그램을 개발하면서 소스 코드를 컴파일하기 위해 사용하는 시간은 결코 무시할 수 없습니다. 컴파일에 걸리는 시간을 줄이기 위해서 빠른 컴파일러를 개발하는 것은 물론이고, 분산 컴파일, 헤더만 미리 컴파일하기(precom piled header) 등의 갖가지 방법이 개발됩니다. 그만큼 컴파일 시간은 프로그램의 개발에 중요한 요소입니다. 당장 필자가 문서를 작성하고 있는 워드프로그램을 컴파일하려면 시간이 얼마나 필요할까요? 한두 라인만을 수정하기 위해서 워드의 소스 코드를 전부 컴파일해야 한다면 얼마나 비효율적인 일이 될까요!
이제부터 독자들은 가능한 한 프로그램을 분할해서 작성하도록 노력해야 합니다. 이런 작업을 하기 가장 좋은 툴 중의 하나가 바로 make라는 것이다. 비주얼 C++에는 nmake. exe는 툴이 있습니다. Make와 문법은 약간 다르지만 사용하는 방법이 크게 다르지는 않습니다.
먼저 hellojiny 프로그램(<리스트 2>)을 함수를 이용해 바꿔 보았습니다. 아주 간단한 코드이니 독자들에게 전혀 무리가 없으리라 생각합니다. 하지만 다시 퀴즈입니다. 왜 print_hello() 함수의 앞에 static을 사용했을까요? 답은 파일을 분리한 hellojiny에서 설명하려고 합니다. 이제 두 함수를 각각의 파일로 분리해 보았습니다(<리스트 3>).
자, 이제 hellojiny 프로그램을 두 개의 파일로 나눠 보았다. 하지만 이 파일들은 몇 가지 심각한 문제가 있습니다. 이 문제를 발견하기 위해서 두 파일을 컴파일합니다.





gcc -Wall main.c s2b.c
main.c: In function `main’:
main.c:5: warning: implicit declaration of function `print_hello’
main.c:6: warning: control reaches end of non-void function

gcc의 -Wall 옵션은 컴파일하는 과정에서 발견된 문법적인 오류를 검사해 줍니다(더 자세한 문법 오류를 검사하기 위해서는 lint라는 별도의 프로그램을 사용할 수도 있습니다). 컴파일하면서 오류 메시지를 두 개 발견했는데 첫번째는 main.c에서 print_hello()라는 함수에 대해 알고 있지 못하다는 내용이고, 두번째는 main() 함수에서 리턴값을 돌려주지 않는다는 내용입니다. 두 가지 다 중요한 내용이지만 지금은 첫번째 문제에 관해서 좀더 생각해보겠습니다.
C는 선언(declaration)이 꼭 필요한 언어입니다. 함수를 호출하는 부분은 컴파일러에게는 함수 자체가 변수와 마찬가지로 생각한다고 해도 과언이 아닙니다. 함수의 반환형(return type)이 제대로 선언되지 않은 경우 컴파일러는 무조건 int를 반환한다고 생각하기 때문에 심각한 오류의 원인이 되기도 합니다.
프로그램의 실행이 완전히 틀린 결과를 내놓을 수 있는 소스 코드를 첨부합니다. 실제로 복잡한 프로그램을 작성하면서 헤더를 제대로 작성해 주지 않고 컴파일러의 경고 메시지를 무시하다 보면 이런 사소한 실수에서 잘못된 결과를 얻어 디버깅에 어마어마한 시간을 소비하게 되는 경험을 여러 번 하게 됩니다. 선임자가 만들던 몇 만 라인짜리 프로그램이 이렇게 작성되어 있다면 이 프로그램은 언제 터질지 모르는 폭탄이라고 생각해도 좋습니다.


<리스트 4>는 정상적으로 컴파일되고 실행도 가능합니다. 왜 그런 것일까요? 앞에서 선언되지 않는 함수에 대해서는 int를 가정한다고 설명한 바 있습니다. 따라서 이 프로그램은 경고 메시지를 출력하기는 하지만 문법적으로 전혀 하자가 없습니다. 하지만 출력되는 결과는 어떤 값이 될지 예측할 수 없을 뿐만 아니라 이 값을 직접 이용하는 루틴이 있다면 심각한 오류의 원인이 된다는 것을 다시 강조합니다.
다시 원래의 소스 코드에 함수의 선언을 추가했습니다(<리스트 5>). 이제 컴파일러의 경고 메시지가 하나 없어졌다는 것을 알 수 있을 것입니다. 앞으로도 분리한 모듈에 대해서는 꼭 이렇게 함수의 선언을 추가해야 합니다. 하지만, 만일 sub.c를 다른 프로젝트에서도 계속 사용하고 싶은데 이렇게 함수를 선언해 줘야 한다면 아주 귀찮은 일이 될 것입니다. 이런 귀찮은 역할을 대신 해주는 것이 헤더라는 사실은 이미 잘 알고 있으리라 생각합니다. 헤더를 이용해서 hello jiny 프로그램을 다시 수정해보겠습니다(<리스트 6>).
이렇게 헤더가 완성되었습니다. 하지만 함수의 선언은 그렇다고 해도 시작과 끝에 적혀 있는 #ifndef는 왜 필요한 것일까요? sub.h에 다음 한 줄을 추가하고 #ifndef 등을 삭제해 컴파일해 보면 쉽게 답을 얻을 수 있을 것입니다.

sub.h
//#ifndef __SUB_H__
//#define __SUB_H__

#include “sub.h”
void print_hello(void);
//#endif /* __SUB_H__ */
#ifndef는 같은 헤더 파일이 프로그래머가 알지 못하는 사이에 재귀적으로 포함되어 문제가 생기는 것을 방지해 주는 역할을 합니다. 필자가 매우 놀랐던 것 중 하나는 비교적 경험이 많은 프로그래머들도 헤더의 시작에 ‘recursive inclusion’을 방지하기 위한 장치를 사용하는 것을 간과하는 경우가 많다는 것입니다. 독자들은 헤더를 작성하는 경우에 이렇게 쓰는 것을 공식이라고 생각하고 잊지 않았으면 합니다.
헤더 파일은 보통 파일로 분리된 모듈에 대해서 인터페이스를 제공해주기 위해 사용합니다. 하지만 헤더는 컴파일러의 입장에서는 C 소스 코드와 전혀 다르지 않습니다. #include에는 헤더만 포함될 수 있는 것이 아니므로 #include “sub.c”와 같은 문장을 사용해도 문법적으로는 전혀 문제가 없습니다. 하지만 이렇게 사용하는 것은 적어도 필자의 관점에서는 바람직하지 않습니다.
많은 초심자들이 자주 범하는 실수 중 하나가 헤더에 함수를 정의(definition)해 사용하는 것입니다. 이러한 방식은 코드를 작성하면서 자신이 그 내용에 대해 이미 알고 있다면, 그리고 편리한 프로그래밍을 위해 일부러 이렇게 작성한 것이라면 전혀 문제가 되지 않습니다. 하지만 작성자가 이 사실을 인지하지 못한 상태라면 심각한 문제가 될 가능성이 많습니다. 좋은 헤더를 만들기 위해서는 많은 경험이 필요합니다. 헤더 파일과 소스 파일에 대해 명확한 기준을 세워 놓지 않고 프로그래밍을 하게 되면 어느 한 순간 “symbol multiply defined”나 “include nested too deeply” 같은 피곤한 에러들을 만나게 될 것입니다. 헤더가 열 개가 넘고 서로의 포함 관계가 복잡한 경우 이런 문제를 해결하려면 소스 코드를 여러 곳 수정해야 하는 경우가 많습니다.
그러면 다시 여기에서 퀴즈를 내겠습니다. 이번에는 sub.c의 print_hello()에서 static을 사용하지 않았습니다. 만일 print_hello() 함수를 static void print_hello()로 바꾼다면 이 프로그램은 작동하지 않습니다. 정확하게 말하면 컴파일을 할 수 없습니다. 좀더 정확하게 말하면 컴파일된 sub.o와 main.o를 링크해 실행 파일을 생성하지 못합니다. 왜 그런 것일까요?
Static은 두 가지의 조금 다른 의미를 지닙니다. 함수에 사용되는 경우에는 “이 함수가 적혀 있는 이 파일 이외의 파일에서는 이 함수를 사용할 수 없다”는 의미를 가지게 됩니다. 아울러 C로 작성한 대형 프로젝트에서는 보통 C를 이용해 객체지향의 개념을 도입하게 되는데, 이때 C++에서의 private을 비슷하게 구현하기 위해 사용되기도 합니다.
Static을 변수에 사용하는 경우에는 “이 변수는 이 프로그램이 끝날 때까지 다른 변수와는 다른 특별한 곳에 저장되어 함수가 끝나도 값이 변형되지 않는다”라는 의미를 가지게 됩니다. Sub.c를 static을 사용해 약간 변형시켜 보았습니다. Print_text() 함수는 main.c에서는 직접 사용할 수 없는 함수로 선언되어 있으며 동시에 print_text() 내에서 사용하는 print_cout라는 변수는 실행될 때마다 값이 변하지 않고 계속 유지되는 것을 확인할 수 있습니다. 이 프로그램의 실행 결과는 다음과 같습니다.

./a.exe
[1] hello, world
[2] hello, world
[3] hello, world

자, 그러면 이때 static int print_count에서 static을 없애면 어떻게 될까요? 답은 ‘보장할 수 없다’입니다. Print_count라는 변수가 초기화되어 있지 않기 때문입니다. static으로 선언되는 변수는 선언되는 시점에서 자동으로 0으로 초기화가 되지만 다른 변수들은 그렇지 못합니다.
또 하나 소스 코드를 파일로 분리하면서 꼭 알고 있어야 하는 것은 extern과 global의 개념입니다. 자세한 설명은 따로 하지 않으려고 합니다. 다만 독자들에게 숙제로 남겨 놓고 해답은 다음 기사의 첫 부분에 싣도록 하겠습니다.
Static을 사용하지 않고 전역 변수를 이용해 프린트 함수를 호출한 횟수를 기억하기 위해서는 어떻게 하면 될까요? 그리고 main.c에서도 이 횟수를 알기 위해서는 sub.h에 어떤 내용이 추가되어야 할까요?
이 문제를 스스로 해결할 수 있다면 그 시점에서 static, extern, global에 대해 다시 한번 깊게 생각해 보기 바랍니다. Variable의 scope와 linkage라는 단어로 이 내용을 기술하게 되는데 프로그래밍 경험이 많아도 정확한 개념을 알지 못하고 대강 넘어가는 경우가 많기 때문입니다. 또 초심자들에게 가장 어렵게 느껴지는 개념 중 하나이기도 합니다.
이제 마지막으로 Makefile을 만들어 보겠습니다. Makefile을 이용하면 여러 개의 파일로 구성되어 있는 프로젝트를 손쉽게 관리할 수 있습니다.
BIN = hellojiny
OBJS = main.o sub.o

all: $(OBJS)
gcc -o ${BIN} ${OBJS}


clean:
rm ${OBJS}

.c.o:
gcc -c $<
Makefile은 개념과 작성하는 방법만으로도 소책자가 될 정도이므로 간단히라도 설명하기 위해서는 꽤 많은 지면을 필요로 합니다. 다만 makefile을 쓰면 몇 가지 편리한 점이 있습니다. 가장 좋은 점은 make라고 네 글자만 타이핑하면 된다는 것이고, 모든 작업을 target을 정해 기술해 둘 수 있으므로 rm과 같은 민감한 작업을 하는 경우 실수를 줄일 수 있습니다. 더 좋은 점은 아직 컴파일이 되지 않았거나 소스 코드가 변경된 파일에 대해 선택적으로 알아서 해당되는 작업을 수행해주기 때문에 전체 소스 코드를 컴파일하는 시간도 훨씬 짧아집니다. 또한 파일의 변경에 대해 의존성을 기술할 수 있기 때문에 sub.h가 변경된 경우 자동으로 sub.c를(sub.o가 존재하더라도) 새로 컴파일할 수 있습니다.
makefile은 단순히 소스를 컴파일하기 위해 사용할 수 있는 것만은 아닙니다. Makefile의 문법을 보며 눈치가 빠른 독자들은 느낄 수 있으리라 생각하지만 의존성을 가지고 하나의 파일을 다른 파일로 변경해야 하는 대부분의 작업에 makefile을 사용할 수 있습니다. 아주 좋은 예로는 latex 파일을 dvi로 컴파일하거나 오픈소스 프로젝트에서 문서를 생성하기 위해 makefile에 의존한다는 사실을 들 수 있겠지요.
좀 더 오픈소스 프로젝트에 가까운 방법은 GNU autoconf/ automake를 이용하는 것입니다. 많은 오픈소스 프로그램은 ./configure; make; make install만으로 컴파일과 설치를 마칠 수 있습니다. 이것을 가능하게 해주는 것이 autoconf와 automake이며 간단하게는 makefile을 간단한(?) 설정만으로 자동으로 생성할 수 있도록 해주는 프로그램입니다. 이 패키지의 사용에 대해서는 여기서는 생략할 수밖에 없지만 오픈소스와 GNU에 관심이 있는 독자라면 꼭 한번 관심을 가지고 배워보면 좋습니다. 물론 오픈소스 개발툴인 anjuta, kdevelop 등의 IDE 환경에서는 자동으로 automake, autoconf에 필요한 파일들을 생성해 줍니다.

자신감은 첫 프로그램으로부터!
이제 막 C 언어를 배웠지만 더 고급 프로그래밍을 하고 싶은 독자를 위해 첫 기사를 마쳤습니다. 필자는 어린 시절 터보 C라는 좋은 프로그램으로 처음 C를 배웠습니다. 무작정 책을 사 놓고 페이지를 뒤적이고 나서 문법은 이해가 되었다고 생각했던 바로 그 때쯤의 당혹스러움을 아직도 잊지 못하고 있다. 이곳저곳에서 몇 가지 언어로 여러 프로그램을 때로는 일로 때로는 재미삼아 만들고 있는 지금까지도 어느 순간 프로그래밍에 대해 두려움이 없어졌는지 잘 기억해 낼 수가 없嗤?확실한 것은 첫번째 프로그램 하나가 엄청난 자신감을 안겨준다는 사실입니다. 스스로 동기를 부여해 쓸모없어 보이는 간단한 프로그램이라도 많은 것을 만들어 보기를 권하고 싶습니다.
가능하면 C에 관한 내용보다는 C를 이용해 프로그래밍하면서 만나는 여러 가지 문제나 일부러 신경을 쓰지 않으면 간과하기 쉬운 문제들에 대해 다루려고 생각합니다. 특히 어느 정도 막막한 느낌을 떨쳐내고 나면 고민하게 되는 코딩 스타일의 문제나 버그를 적게 만들어 낼 수 있는 코드의 작성 등에 관해서도 다뤄보려 합니다.
다음 호에서는 C에서 가장 어려운 부분이라고 누구나 느끼게 되는 포인터에 대해 다루고자 합니다. 기본적인 포인터의 개념보다는 구조체의 포인터, 함수 포인터, 함수 포인터를 이용한 플러그인의 구현 방법 등에 대해 다룰 것입니다. 기사의 내용에 관한 궁금한 점이 있으면 언제든지 마소 사이트(www.imaso.co.kr)를 이용해 질문해 주기 바랍니다.