남정현의 닷넷 블로그 ~ 강좌 ~

블로그 이사갑니다.

rkttu — Sat, 4 Oct 2008 02:31:09 +0900

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

http://rkttu.com/ 으로 이사갑니다.

클래스에 대하여

rkttu — Wed, 1 Aug 2007 09:04:22 +0900

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

시작하기 전에: 네임스페이스에 관한 글을 다시 한 번 읽어보시면 유익합니다. :-)

클래스는 객체 지향 프로그래밍에서 기본이 되는 단위입니다. 우리가 지금 다루고자 하는 프로그래밍 언어 C#은 객체 지향 프로그래밍 언어로서 클래스를 이용한 프로그래밍을 가장 핵심적으로 다룹니다. 그렇다면 클래스에 대하여 잠시 짚고 넘어가 보는 것이 좋겠지요.

클래스를 설명하는 방법이나 비유는 매우 많습니다. 이런 비유들을 일일이 열거하자면 참으로 깁니다. 이런 긴 비유들을 일일이 나열하지 않더라도 한 가지 핵심이 있는데, 바로 "실제 세계의 자료나 형상"을 컴퓨터가 이해할 수 있는 단위로 변형하거나 재구성하는 것이 그 핵심이라 할 수 있겠습니다.

1. 시작

class MyClass
{
}

위와 같이 선언하기만 하더라도 클래스는 바로 완성됩니다. C#에서의 위와 같은 클래스 선언 구문은 C++에서와는 다르게 이미 많은 가정을 내포하고 있습니다. 특별한 언급이 없어도 C#에서의 클래스는 모두 System 네임스페이스에 위치한 Object 클래스를 부모 클래스로 합니다. 그에 따라 기본적인 기능들 몇 가지는 자동으로 구현됩니다. 무엇이 자동으로 이루어지게되는지에 대해서는 추후에 살펴보기로 하지요.

2. 접근 제한자

접근 제한 기능은 객체 지향에 있어서 매우 중요한 기능입니다. 접근을 제한함으로서 해당 클래스를 가져다 쓰는 소비자 코드에 일관성과 규칙성을 부여할 수 있고, 이를 바탕으로 좀 더 생산적이고 유지보수하기 쉽도록 통제하는것이 가능하게 됩니다.

접근 제한자는 어디에 쓰일 것인지에 따라서 조금씩 규칙이 달라지기는 하지만 기본적으로 다음의 다섯가지 틀을 벗어나지는 않습니다.

public - 이 키워드가 붙는 항목은 접근에 제약이 없습니다.

internal - Visual Studio에서 말하는 프로젝트는 EXE 파일이나 DLL 파일을 만들어내기 위한 기본 틀이라고 이야기한 적이 있었습니다. 만들어지게될 EXE 파일이나 DLL 파일은 집합체라는 뜻을 가진 용어 "어셈블리"로 이름이 지어지게 됩니다. 이 어셈블리 안에 속한 코드 끼리만 접근이 허용됨을 의미합니다.

protected - 상속과 밀접한 관련이 있습니다. 간단히 요약하면, 상속의 대상이 되는 부모가 상속의 주체가 되는 자식에게만 접근을 허용하도록 하는 의미를 가집니다. 쉬운 말로, 조상이 후손에게 남겨주는 유산 임을 알리는 것입니다.

private - 접근 범위가 무엇이든, 누가 접근을 하든 간에 관계없이 클래스 자기 자신만 사용할 수 있도록 통제함을 의미합니다.

protected internal - protected의 성격과 internal의 성격을 동시에 지니며, 특수한 경우에만 사용되므로 크게 신경쓰지 않아도 됩니다.

그렇다면 이들 접근 제한자가 클래스 선언 부에 있어서 어떻게 쓰일 수 있는지 한 번 살펴보겠습니다.

public class MyClass1
{
}

internal class MyClass2
{
}

class MyClass3
{
}

private class MyClass4_Error
{
}

protected class MyClass5_Error
{
}

하나씩 살펴보기로 하지요. MyClass1은 public 접근 제한자가 지정되었으니까 어디서든 재사용이 가능함을 의미합니다. 그리고 MyClass2는 internal 접근 제한자가 지정되었으니까 프로젝트 안에서는 사용할 수 있겠지만 프로젝트 밖에서는 보이지 않게 되겠네요. 그리고 MyClass3는 처음 우리가 만든 클래스와 똑같은 모양새를 가지지만 실제로는 internal 접근 제한자를 붙인것과 같이 동작합니다.

그렇다면 private과 protected가 쓰인 MyClass4_Error와 MyClass5_Error 클래스의 경우는 무엇일까요? 네임스페이스에 속한 클래스에 대해서는 private, protected, internal protected 접근 제한자를 지정할 수 없습니다. 모두 internal 키워드로 대체할 수 있는데다가 의미도 원래의 것과 일치하지 않기 때문에 어설프게 통과시키지 않고 오류를 발생시킨 것입니다.

private, protected, protected internal 접근 제한자는 그럼 언제 쓰일 수 있을까요? 이들 접근 제한자는 원래 클래스 안에 선언된 내용에 대해서 적용이 되어야 하는 것들이었는데 클래스 또한 마찬가지입니다. 클래스 안의 클래스를 중첩 클래스라고 부르며, 중첩 클래스들에 대해서는 이들 접근 제한자가 유효하게 됩니다.

결론: 대부분의 경우, public 접근 제한자를 쓰는 것이 유리합니다.

3. 부모 클래스의 지정

코드를 보면서 이야기해보도록 하겠습니다.

public class MyClassA
{
}

public class MyClassB : System.Object
{
}

public class MyClassC: System.MarshalByRefObject
{
}

public class MyClassD_Error: System.String
{
}

public class MyClassE_Error: System.Int32
{
}

C#에서는 아주 기본적인 코드를 작성하더라도 이미 상속의 혜택을 많이 누리게 됩니다. MyClassA는 따로 명시한 적이 없어도 자동으로 System.Object 클래스를 부모로 하고 있습니다. 혹은, 의미가 명확하길 바라는 차원에서 MyClassB와 같이 명시적으로 System.Object 클래스를 지정할 수도 있겠습니다만, 잘 하지 않을 일입니다.

상속할 대상이 있다면 MyClassC와 같이 상속할 기존의 클래스를 지정하거나 직접 만든 새 클래스를 부모 클래스로 하여 코딩을 시작할 수도 있습니다.

그렇지만 MyClassD_Error와 MyClassE_Error와 같은 경우는 주의하여야 합니다. 뒤에서 설명할 sealed 키워드가 지정된 클래스나 이후에 설명할 클래스가 아닌 나머지 (구조체, 나열 상수, 대리자)들은 부모 클래스로 사용할 수 없습니다.

4. abstract 키워드와 sealed 키워드

어떤 클래스를 만들었을 때, 이 클래스의 내용이 그 자체만으로는 완전해질 수 없는 경우가 있을 수 있습니다. 이러한 경우 소비자 코드가 완전하지 않은 어떤 클래스를 직접 사용할 수 없도록 통제해야 할 필요가 있는데 이 때 유용한 것이 abstract 키워드입니다.

선언부에 이 키워드가 지정된 클래스는 그 자체로는 객체를 생성할 수 없으며 반드시 새로운 클래스를 생성하여 부모 클래스로 abstract 키워드가 붙은 클래스를 지정하고, 구현되지 않은 나머지 내용들을 구현해야 합니다.

반대로 소비자 코드에서 임의로 새로운 클래스를 만들어 새로운 동작을 추가하거나 데이터를 끼워넣도록 허용하는 것을 막아야 할 필요도 있습니다. 이 때에는 sealed 키워드를 써서 더 이상 상속이 일어날 수 없도록 통제할 수도 있습니다.

다음이 그 예제입니다.

public abstract MyClass1A
{
}

public abstract MyClass1B : MyClass1A
{
}

public sealed class MyClass1C : MyClass1B
{
}

public class MyClass1D_Error : MyClass1C
{
}

MyClass1A는 abstract 키워드를 지정한 것으로 객체를 직접 생성할 수 없으며 반드시 MyClass1B나 MyClass1C와 같이 상속되어야만 하는 클래스입니다. MyClass1B 역시 상속을 받았지만 역시 abstract 키워드가 지정되었으므로 상속이 필요합니다. 결국 MyClass1C는 MyClass1A의 내용과 MyClass1B의 내용을 동시에 상속받게 됩니다.

반면 MyClass1C 클래스는 sealed 키워드가 지정된 클래스로 MyClass1D_Error 클래스에서 상속을 받고자하였을 때 오류가 발생하게 됩니다.

중요: C#에서의 상속은 C++와는 다르게 다중 상속이 지원되지 않습니다. 다중 상속으로 인하여 발생할 수 있는 위험 요소나 모호성을 방지하고 효율성을 높이기 위함입니다. 이후에 살펴볼 다중 인터페이스 구현을 위한 지정은, 겉으로 보기에는 마치 다중 상속처럼 보이지만 실제로는 그렇지 않습니다.

다음 글에서는 클래스의 주요 사항들 중 생성자, 멤버 변수, 멤버 함수, 멤버 속성의 선언 방법과 사용 예제를 살펴보기로 하겠습니다.

네임스페이스

rkttu — Fri, 27 Jul 2007 12:53:58 +0900

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

시작하기 전에: 지난번의 응용 과제를 통하여 닷넷 프레임워크와 좀 친해지셨나요?

C#은 닷넷 프레임워크의 구조를 가장 가깝게 받아들인 언어이기 때문에 닷넷 프레임워크의 구조를 배우기에 적합합니다. C#을 시작으로 하여 다른 언어를 접한다면 훨씬 쉽습니다. :-) 오늘은 C#을 비롯하여 닷넷 프로그래밍 세계에서 기본이 되는 "네임스페이스"라는 논리적 단위에 대한 개념을 살펴보기로 합니다.

1. 네임스페이스란?

네임스페이스라는 용어는 직역하면 "이름 공간"입니다. 이름 공간이 무엇일까요? 직역이라서 표현이 어색하지만 제일 설명이 잘 된 표현(?) 이기도 합니다. 바로 "그릇"의 역할을 하는 것입니다. 네임스페이스 안에는 기존에 이미 작성된 클래스나 구조체와 같은 것들이 담겨져 있는 것입니다.

namespace Welcome
{
public class Home
{
// Blah Blah Blah ...
}
}

위의 코딩과 같이 네임스페이스는 그 안에 다른 클래스를 포함할 수 있습니다. 그렇다면 여기서 궁금한 것이 하나 생기는데, 우리가 이전 강좌에서 살펴보았던 네임스페이스 안에 담겨있지 않았던 클래스는 네임스페이스와의 관계가 어떻게 되는것일까요?

정답은 그 클래스 역시 네임스페이스를 가지고 있다는 것입니다. 하지만 이름이 없는 네임스페이스가 있을 수 있을까요? 이러한 네임스페이스를 우리는 글로벌 네임스페이스라고 부릅니다. 즉, 특별한 명시가 없어도 바로 찾을 수 있는 네임스페이스를 말합니다.

또 하나의 궁금한 점이 생기지 않으셨나요? 그렇다면 왜 귀찮게 네임스페이스를 굳이 나누어서 일을 복잡하게 하는지에 대해서 말이죠. 귀찮은 것은 사실입니다. 하지만 더 귀찮은 일은, 네임스페이스가 존재하지 않기 때문에 같은 이름의 다른 일을 하는 클래스를 정의할 수 없는 경우입니다. 이러한 불편을 방지하기 위하여 네임스페이스가 도입된 것입니다.

네임스페이스라 하는 것은 이미 C++에서도 널리 사용되고 있는 개념이고 Java에서는 비슷한 개념으로 패키지 개념이 제공됩니다. 언어 상에서 사용하는 문법에 다소 차이가 있을 뿐 네임스페이스와는 사실상 같은 개념이라고 할 수 있습니다.

* 오늘의 포인트 1: 네임스페이스의 선언을 위해서는 C#의 namespace 키워드를 사용합니다.
* 오늘의 포인트 2: 네임스페이스는 클래스나 구조체 등을 담기 위한 논리적인 공간입니다.
* 오늘의 포인트 3: C#에서 네임스페이스 선언 없이 정의된 클래스나 구조체들은 글로벌 네임스페이스 안에 자동으로 포함됩니다.

2. 네임스페이스 안의 네임스페이스

앞에서 설명하였던 글로벌 네임스페이스를 다시 보기로 합니다. 별도의 선언 없이 사용하는 네임스페이스도 사실은 글로벌 네임스페이스 아래에 소속된다고 할 수 있습니다. 이것은 달리 말하여 네임스페이스들은 계층적인 구조를 형성할 수 있다는 것을 뜻합니다. 즉, 네임스페이스 안에 네임스페이스를 포함하는 것이 가능하다는 뜻입니다.

하지만 네임스페이스는 계층적인 구조 뿐만이 아니라 수평적인 구조도 지원합니다. 이 말이 무슨 말이냐 하면, 네임스페이스를 사용하기 위하여 몇 단계를 거쳐서 접근하는 것이 아니라, 마치 하나의 주소처럼 바로 찾아들어가는 것이 가능하다는 의미입니다. 좀 더 쉬운 설명을 해볼까요?

네임스페이스가 계층적이기만 하다면 아마도 우리는 우리가 사는 곳의 주소를 이런식으로 불러야할지도 모릅니다.

"서울특별시" 안에 위치한, "종로구" 안에 위치한, "서린동" 안에 위치한, "영풍 빌딩"의 "아무개씨 법무소"
"서울특별시" 안에 위치한, "종로구" 안에 위치한, "서린동" 안에 위치한, "영풍 빌딩"의 "영풍 문고"

하지만 우리가 위와 같이 주소를 이야기하지는 않지요.

"서울특별시 종로구 서린동 영풍빌딩"의 "아무개씨 법무소"와 "영풍문고"

그렇습니다. "~안에 위치한"이라는 거추장스러운 표현대신 그냥 "서울특별시 종로구 서린동 영풍빌딩"과 같이 하나의 이름을 사용합니다. 그리고 그 안에 위치한 아무개씨 법무소와 영풍 문고인 것입니다. 이와 같이 네임스페이스가 계층적인 구조를 형성하기도 하지만 이러한 것과는 상관없이 하나의 이름이 될 수 있다는 것을 설명하고자 한 것입니다.

프로그래밍 언어마다 중첩된 네임스페이스의 이를을 이해하는 이름 규칙이 조금씩 다를 수 있습니다. 하지만 우리가 사용하고자 하는 프로그래밍 언어인 C#을 기준으로 생각해보았을 때 위의 이름을 아래와 같이 쓸 수 있습니다.

서울특별시.종로구.서린동.영풍빌딩.아무개씨법무소
서울특별시.종로구.서린동.영풍빌딩.영풍문고

즉, 중첩된 네임스페이스 안의 항목을 참조하기 위하여 피리어드 '.' 기호를 사용하였습니다.

* 오늘의 포인트 4: 네임스페이스는 계층적인 구조를 지원하지만 그렇다고 접근하는 방법까지 계층적일 필요는 없습니다.

3. C#에서 네임스페이스를 편리하게 사용하는 방법 - using 키워드

네임스페이스는 선언 공간을 논리적으로 쪼개어 같은 이름의 다른 클래스를 정의하는 일을 가능하게 한다고 하였습니다. 하지만 네임스페이스의 이름은 충분히 길어질 수 있기 때문에 이 때 마다 전체 네임스페이스의 이름을 가져다 쓰려면 여간 불편한 것이 아닙니다. 그렇기 때문에 사용하는 것이 바로 using 키워드입니다.

C#의 using 키워드는 C++에서 단독으로 사용하는 using 키워드보다는 using namespace 구문과 의미가 유사합니다. 반대로 C++에서 단독으로 사용하는 using 키워드는 Java나 J#의 import 키워드와 유사합니다. C++에서는 using namespace 구문의 선택이 권장되지 않다는 것을 상당히 강조하고 있습니다. 그러나 C#에서는 권장되지 않는 이런 스타일의 기능을 기본 기능으로 채택하고 있습니다. 왜 이것이 문제가 될까요?

앞서 말했던 대로 네임스페이스를 사용하려는 목적은 같은 이름의 다른 클래스를 정의하기 위함이라고 하였는데, using 키워드로 네임스페이스를 가져오면 해당 네임스페이스 안의 모든 정보들을 다시 글로벌 네임스페이스와 합치게 됩니다. 이렇게 되면 틀림없이 겹치는 정보도 있을 것입니다. C#의 using 키워드는 바로 이런 문제점을 내포하고 있습니다. 만약 실제로 이러한 경우가 발생한다면 컴파일러는 어떻게 대처할까요?

이런 상황이 발생하더라도 컴파일러는 직접 오류를 발생시키지는 않습니다. 그러나, 이름이 겹치는 문제의 클래스를 사용하려고 하면 "이름이 모호하다"라는 오류를 발생시키게 됩니다. 이 문제를 해결하기 위해서는 다시 전체 네임스페이스 이름을 기재하거나 뒤에서 설명할 using 키워드의 또 다른 용법을 통하여 문제를 해결할 수 있습니다.

네임스페이스를 참조를 위한 using 키워드의 사용법은 다음과 같습니다.

using [네임스페이스이름];

using System;
using System.Collections;
using System.Windows.Forms;

위에서 언급하였던 것처럼 using 키워드는 잠재적인 문제점을 안고 있습니다. 이 문제를 해결하기 위해서 전체 네임스페이스를 다시 기재할 수도 있겠습니다만 이런 경우 참으로 비효율적인 일이 됩니다. 서로 겹치는 이름으로 인하여 발생한 모호성 문제를 효율적으로 해결하기 위한 using 키워드의 또 다른 용법을 소개할까 합니다.

using [별칭] = [실제 네임스페이스명 + 클래스 이름];

using NonGUIForm = MyApp.Form;
using System.Windows.Forms.Form;

MyApp 네임스페이스의 Form 클래스와 System.Windows.Forms 네임스페이스의 Form 클래스를 동시에 사용하고자 할 경우 발생하는 문제를 해결하기 위하여 MyApp.Form 클래스에 임시 별칭인 NonGUIForm을 부여하였습니다. 이렇게 하면 MyApp.Form이라는 이름 대신 NonGUIForm 이라는 이름을 사용할 수 있게 됩니다.

위와 같이 별칭을 정하면 컴파일러 전체에 영향을 주는 것은 아니며 별칭이 선언된 네임스페이스에 일시적으로 영향을 주게 됩니다. 만약 using 키워드를 C# 코드 파일 제일 위에 배치하였다면 Global Namespace에 대한 선언이 되므로 다른 파일에서는 별칭 설정이 유지되지 않습니다.

* 오늘의 포인트 5: C#의 using 키워드는 잠재적인 문제점을 가지고 있지만 이를 해결하기 위하여 클래스 이름 등에 별칭을 부여할 수 있는 기능도 제공합니다.

4. 네임스페이스를 선언하는 방법

잠깐 되짚어보기로 하지요. 글로벌 네임스페이스 안에 어떤 내용을 집어넣기 위해서는 "특별한 명시 없이" 내용의 선언을 시작하면 된다고 하였습니다. 그리고 이런 규칙을 바탕으로 글로벌 네임스페이스 아래에 또 다른 네임스페이스를 정의할 수 있습니다. 그렇다면 네임스페이스를 선언하는 문법을 한 번 살펴보도록 하지요.

namespace Tools
{
namespace ForHome
{
}
}

글로벌 네임스페이스 아래에 Tools.ForHome 이라는 네임스페이스를 정의하기 위하여 위와 같이 기술하였습니다. 이와 같은 방법을 통하여 계층적인 네임스페이스 구조를 선언하는 것이 가능합니다. 하지만 한 번에 이것을 정의할 수 있는 방법은 없을까요?

namespace Tools.ForHome
{
}

네임스페이스에 접근할 때와 마찬가지로 Period 기호를 사용하여 네임스페이스 이름을 작명하면 자동으로 계층적인 구조가 만들어집니다. 그리고 달리 말하자면 Tools.ForHome이라는 이름의 네임스페이스를 만들기도 한 것입니다.

네임스페이스에 어떤 이름을 붙일지에 대해서는 특별한 제약이 없습니다. 다만, 2바이트 언어 (한국어, 일본어, 중국어 등)나 일반 표준 QWERTY/DVORAK 키보드 자판으로 타이핑할 수 없는 특수 문자로 네임스페이스 이름을 작명하지 않도록 하여야 합니다. 그리고 컴파일러와 닷넷 프레임워크가 이해할 수 있는 이름이어야 하므로 공백을 사용하거나 첫 글자에 숫자가 포함되면 안됩니다. 그 외에는 약간의 작명에 관한 관례가 있습니다.

A. 네임스페이스는 최소한 두 계층 이상을 유지할 것을 권장하고 있으며 처음 계층은 회사 - 또는 - 저작자와 관련된 단체명 - 또는 - 저작자 본인을 설명할 수 있는 별칭을 사용하고 그 다음은 작성한 코드의 범주와 관련된 설명을 기준으로 이름을 작명할 것을 권합니다. 이 관례를 따르는 예시는 다음과 같습니다.

Microsoft.PointOfServices
Microsoft.Win32
Mono.Posix

B. 만약 Java 언어와의 연동이나 J# 프로그래밍 언어와의 연동이 필요하면 네임스페이스의 작명은 Java 스타일의 패키지 작명을 따르는 것이 유리합니다. 다음과 같이 저작자 본인 - 또는 - 회사의 웹 사이트 도메인 네임을 역순으로 하여 처음 두 계층에서 세 계층까지는 들어가는 것이 좋습니다. 그 이후에는 작성한 코드의 범주와 관련된 설명을 기준으로 이름을 작명할 것을 권합니다. 이 관례를 따르는 예시는 다음과 같습니다.

com.rkttu.design.tools
com.rkttu.net.sockets

C. 네임스페이스에 사용하는 이름을 위한 단어는 제품 명칭을 제외한 나머지 모든 부분에 대하여, 되도록 표준 영어 단어를 사용하여 이해하기 쉽도록 구성하는 것이 좋고, 큰 분류에서 작은 분류 순으로 이름을 짓는 것이 좋습니다. 이 관례를 따르는 예시는 다음과 같습니다.

System.Runtime.InteropServices
System.Xml.Serialization
System.Text.RegularExpressions

D. 네임스페이스에 사용하는 제품명은 가급적 확정적인 이름을 택하는 것이 좋습니다. 네임스페이스 설정에 상당한 종속성을 지니고 있는 닷넷 프레임워크의 하위 기술들을 사용하고 있다면 특히 더 신중하여야 합니다. 나중에 네임스페이스를 바꾸는 것으로 인하여 예상하지 못한 버그나 오류가 발생할 수 있습니다.

이러한 관례를 선호하는 이유는 네임스페이스를 참조하고자 하는 프로그래머가 라이브러리에 대한 이해도를 높일 수 있는 중요한 계기가 될 수 있기 때문이고 이를 통하여 생산성을 향상시킬 수 있기 때문입니다.

* 오늘의 포인트 6: 네임스페이스 작명에 신경쓰면 좀 더 완성도 높은 제품을 만들 수 있습니다.

다음 강좌에서는 네임스페이스 안에 포함될 수 있고 가장 많이 프로그래밍하게 되는 요소인 클래스에 대하여 기본을 살펴보기로 하겠습니다. 좋은 하루 되십시오. :-)

콘솔 프로그래밍 실전

rkttu — Thu, 12 Jul 2007 00:31:17 +0900

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

시작하기 전에: 닷넷 프레임워크에서 문자열을 사용한다는 것이 어떤 의미인지 되새겨보셨나요?

드디어 콘솔 프로그래밍 실전입니다. 강좌를 올리기까지 상당 시간이 소요되었음을 양해를 구합니다. 이번 단원에서는 콘솔 프로그래밍을 통하여 C#에서 문자열을 활용하는 여러 가지 방법을 배워보기로 합니다.

C#은 C와 C++의 언어적인 컨셉을 답습합니다. 그래서 문자와 문자열의 개념이 분명하게 분리되어있습니다. 말이 어렵지만 간단히 생각해보면 글자 하나가 문자이고, 이것이 연속적으로 모여서 만들어지는 단어, 문장, 글, 심지어는 책의 내용과 파일이 저장하고 있는 내용까지 모두 문자열이 됩니다.

C#에서 문자는 작은 따옴표 ('')를 사용하여 표기합니다. 예를 들어 다음과 같은 표현들은 올바른 표현이 됩니다.

'a' '가' '南' '※'

하지만 C#의 문자는 C와 C++의 문자와는 차이가 있습니다. 바로 표현하고 담을 수 있는 데이터의 크기가 다르다는 점입니다. C#의 문자는 Java의 문자와 동일한 스케일로 유니코드 방식으로 문자를 저장하기 때문에 항상 문자 하나 당 2바이트를 사용합니다. 하지만 C와 C++은 기본이 1바이트였고, 필요한 경우 우리가 이전 시간에서 봤던 것 처럼 C와 C++의 기본 char 형이 더 큰 형식을 사용하여 유니코드 문자를 표기했었습니다.

그렇다면 이런 문자를 담기 위한 변수의 형식 이름은 무엇일까요? C#에서는 이러한 문자를 담기 위하여 char 형을 그대로 제공합니다. 그리고 char 형은 나중에 닷넷 프레임워크에서 제공하는 System.Char 형식으로 바뀌게 됩니다. 즉, char 형 변수를 만들어도 좋고 System.Char 형 변수를 만들어도 상관이 없는 것입니다. 다만 타이핑할 때 조금이라도 덜 타이핑할 수 있는 방법으로 코딩하는게 편리하겠지요.

한 가지 더 살펴볼 것이 있는데 그것을 위하여 퀴즈를 하나 내도록 하겠습니다. 만약, 문자로서 작은 따옴표를 표현하고 싶다면 어떻게 해야 할까요?

정답 보기

이제 문자열을 살펴보기로 하겠습니다. C#에서의 문자열은 C와 C++과 마찬가지로 쌍 따옴표 ("")를 사용합니다. 그리고 앞서 언급한 문자와 같이 유니코드 방식으로 문자열을 관리하기 때문에 각 문자당 2바이트씩을 할당하여 결과적으로는 (글자 수 * 2바이트) 만큼의 용량을 차지하게 될 것입니다.

앞서 살펴 본 퀴즈에서처럼 이스케이프 문자를 그대로 적용할 수 있는 것은 같습니다. 그런데 C#의 문자열은 이스케이프 문자를 거의 사용하지 않을 수 있도록 하는 아주 편리한 방법을 제공합니다. 바로 버바팀 문자열 (Verbatim String)입니다.

다음의 예를 살펴보기로 합니다.

@"Welcome to ""my world""!"

보통의 문자열 앞에 @ 기호를 붙이는 것이 일단 눈에 띕니다. 그리고 쌍 따옴표를 이스케이프하기 위하여 역 슬래시 기호 대신 쌍 따옴표를 두 번 쓴 것이 눈에 띄지요. 이것이 Verbatim String을 설명하는 전부입니다. 이 조건을 만족하기만 한다면 Verbatim String 안에 있는 어떤 문자라도 표현이 가능합니다. 심지어는 줄을 내리기 위하여 입력한 캐리지 리턴까지도 말입니다.

@"using System;

public class Test
{
   [MTAThread()]
   public static void Main(string[] oArguments)
   {
Console.WriteLine(@""Welcome to """"my world!""""!"");
   }
}
";

이런 문자열까지도 표현이 가능합니다.

이제 문자열을 담을 수 있는 형식을 살펴볼 차례입니다. C#에서는 string이라는 이름의 형식을 제공하며 이것을 나중에는 System.String으로 바꾸게 됩니다. 역시 어떤 쪽을 택하여도 상관이 없으며 코딩할 때 좀 더 효율적인 이름을 고르는 것이 좋겠습니다. C와 C++과는 달리 하나의 저장 방식을 사용하고 하나의 통일된 형식을 제공합니다.

C#과 닷넷 프레임워크의 문자열을 설명하면서 한 가지 더 이야기하면 좋은 것이 있습니다. 바로 문자열을 이어붙이는 것이 매우 간단하는 점입니다. C와 C++에서는 이런 작업이 아주 까다로운 작업 중 하나였습니다. 왜 까다로웠을까요?

C와 C++은 문자열을 하나의 형식이 아닌 배열로 관리를 하고 있습니다. 그렇기 때문에 내부적으로는 서로 다른 내용의 두 배열을 하나의 통합된 배열로 관리하기 위한 복잡한 프로그래밍 코드를 필요로 하게 되는 것입니다. 더불어서 문자열 표기 방법에 따라 적절한 후 처리도 따라야만 했지요.

물론 C#의 문자열은 닷넷 프레임워크의 것이고 닷넷 프레임워크 안을 헤집어보면 원리는 다르지 않습니다. 하지만 이러한 원리를 모두 감추고 정말 필요한 작업을 수행하는 방법과 그 결과만을 보여줍니다. 즉, 문자열을 합칠 수 있다는 사실과 합쳐진 결과를 보여주는 것입니다. 다음의 코드를 살펴보기로 하지요.

"Hello, " + "My Name Is " + "남정현, " + "Nice To Meet You!";

아주 직관적인 코드입니다. 더하기 위하여 그저 + 연산자를 부른 것이지만 합쳐진 문자열을 볼 수 있는 것입니다. 여기서 왜 + 연산자를 사용하였고 이것이 어떻게 동작하는지에 대해서는 좀 더 알아야 하는 것이 많아야 하므로 지금은 살펴보는 것으로 끝냅니다.

이제 문자열의 기본 사용법을 익혀보았으니 콘솔을 가지고 간단한 프로그램을 하나 만들어보겠습니다. 이름을 입력받고, 간단한 인사를 건네는 기본적인 프로그램입니다.

using System;

public class Program
{
   public static void Main()
   {
string userName;
Console.Write("What is your name? ");
userName = Console.ReadLine();
Console.Write("Hello " + userName + ". Nice to meet you!");
   }
}

네 줄의 코드로 이름을 묻고 알게 된 이름으로 간단한 인사말을 출력하는 프로그램을 만들었습니다. 프로그램을 테스트하기 위하여 F5 키를 누르면 프로그램을 만들어서 디버그 모드로 들어가게 됩니다. 이름을 입력하면 테스트해볼 수 있을 것입니다.

위의 코드에서도 그러하듯, 특별한 언급이 없어도 using System; 은 반드시 코드 내에 배치하는 습관을 들이도록 합시다. using 구문은 네임스페이스의 구성 요소들을 모두 가져오겠다는 의미이며 여기서는 System 네임스페이스의 구성 요소들 (클래스, 나열 상수, 대리자, 인터페이스, 구조체)을 전역 네임스페이스로 가져옴을 의미합니다. System 네임스페이스 안에는 우리가 지금 사용하는 Console 클래스는 물론 기본적인 데이터 형식들 (정수, 실수, 문자, 문자열, 메모리 주소에 대한 포인터 형식 등)이 모두 포함되어있습니다.

또한, C#을 비롯한 닷넷 프레임워크의 모든 언어들은 클래스를 기본 단위로 조작할 수 있게 되어있습니다. 단, 기존의 언어적인 특성 상 클래스를 기본 단위로 할 수 없는 언어들의 경우 (예: 파이썬, 자바스크립트 등)에는 이러한 기준에 맞출 수 있도록 동적으로 클래스를 생성하기도 하지만 결국 이러한 기준에 부합하는 환경을 조성합니다. 클래스 아래에서 메서드, 속성, 이벤트 등을 프로그래밍하는 습관을 들이는 것이 중요하다는 점을 숙지하여야 합니다.

위의 코드를 살펴보면 System 네임스페이스를 참조하도록 되어있고 클래스 안에 메서드의 선언이 포함되어있는 것을 볼 수 있습니다. 정확히 기준에 부합하는 것을 알 수 있습니다.

그렇다면 여기서 궁금한 점이 하나 생깁니다. Main 메서드를 위와 같은 용법으로 사용하는 것은 예약된 규칙일까요? 그리고 static 키워드의 의미가 대체 무엇일까요? 이러한 점에 대해서는 나중에 심층적으로 살펴보기로 합니다. 살펴보기로 약속한 것과는 별개로 일단 Main 메서드는 위와 같은 형태여야 우리가 원하는대로 프로그램을 실행하자마자 Main 메서드를 실행할 수 있는 것입니다. (철자도 틀리면 안됩니다. :-) )

C#으로 콘솔 프로그래밍을 하면서 꼭 숙지해야 할 부분을 정리해 보겠습니다.

1. 모든 함수와 멤버 변수 선언은 반드시 클래스 선언 안에 포함되어야만 합니다.
2. 프로그램의 시작점이 되는 Main 함수는 반드시 static 키워드가 붙어야 하고 Main의 Case 및 Spelling을 정확히 엄수해야 합니다.
3. 콘솔에 문자열을 출력하거나 사용자로부터 입력을 받기 위하여 Console 클래스를 사용하고 In과 Out 프로퍼티를 사용하였습니다.

이제 응용해 볼 수 있는 두 가지 연습 문제입니다.

1. 한 사람의 신상 정보를 입력받아서 다시 출력하는 프로그램을 만들되, 신상 정보를 한 번에 입력받고 한 번에 다시 출력하는 프로그램을 위에서 사용한 예제 코드를 변형하여 만들어봅니다.

2. Visual Studio 2005 Express Edition을 설치하셨다면 Console 클래스 다음에 오는 Period (점) 기호를 타이핑하면 수 많은 멤버들이 나타나는 것을 볼 수 있습니다. 이 멤버들을 한 번씩 미리 살펴보시기 바랍니다. F1키를 눌러서 도움말을 보는 것도 필요합니다.

다음 단원부터는 오늘 배운 기본 콘솔 프로그래밍을 토대로 본격적인 C# 문법 공부를 시작하도록 하겠습니다. C# 문법 공부를 시각적으로 이해하고 배우기 쉽게 하기 위한 준비 기간이 길었습니다만 이제부터는 직접 체감하고 확실히 이해할 수 있는 프로그래밍을 시작할 수 있습니다. 감사합니다. :-)

C/C++의 문자열과 C#의 문자열

rkttu — Sun, 10 Jun 2007 01:57:56 +0900

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

시작하기 전에: Console.In, Console.Out, Console.Error 기억나세요?

닷넷 프레임워크에서는 문자열을 매우 유연하게 처리하고 있기 때문에 문자열을 가지고 무엇을 할것인지에 대한 목적만 설정하고 프로그래밍할 수 있다면 문자열 할당과 해제, 재 사용 등 어려운 문제들은 모두 알아서 해결해줍니다.

하지만 편리하게 모든 것을 처리해 준다고 해서 과거의 기술들을 전혀 알 필요가 없을까요? 그렇지 않다고 봅니다. 과거의 C/C++에서 문자열을 사용하기 위해서는 상당히 많은 노력과 계산이 필요로 했다는 것을 기억하고 이번 시간에는 C/C++에서 문자열을 어떻게 사용할 수 있었는지 잠시 짚어보도록 하지요. 오늘 강좌에서 살펴본 내용은 이후 좀 더 고급 기법을 배울 때 매우 유용하게 활용할 수 있을 것입니다.

- char형 1차원 배열: C/C++을 배우게 되면 가장 먼저 사용하는 배열 유형이기도 하고, 문자열의 기본이 되기도 합니다.

- char형 1차원 포인터: char형 1차원 배열에 대한 메모리 주소를 나타내기 위하여 사용합니다. 사실, char형 1차원 포인터는 단지 char형 변수 하나에 대한 주소일 수도 있고, char형 배열의 시작 지점에 대한 주소일 수도 있습니다. 포인터가 아직까지도 실수하기 쉽고 어려운 부분일 수 밖에 없는것은 바로 이 점 때문입니다. Visual C++과 Windows SDK의 헤더에서는 특별히 LPSTR이라는 별칭을 제공하며, const 속성이 붙을 경우 LPCSTR이라는 별칭을 이용할 수 있습니다.

- char형 1차원 배열에 대한 접근법의 변화: char형의 경우 ANSI 표준에서 정의한 255개의 문자열을 표현하기에 무리가 없습니다. 하지만, 영어 이외의 유럽 언어들, 아시아 언어들을 표현하기에는 터무니없이 모자랍니다. 그래서 등장한 것이 2바이트씩 한 문자를 표기하는 MBCS (다중 바이트 문자 시스템) 방식과 코드 페이지입니다.

- unsigned short형 1차원 배열 - 또는 - wchar_t형 1차원 배열: MBCS를 사용하여 문자열을 표기하는 것은 다국어 지원에 대한 적절한 해결책이 될 수 있었지만 프로그래머들에게는 어려운 과제를 남기고 말았습니다. 가장 간단히 생각해보면 문자열에서 문자의 수를 세기 위한 프로그램에서조차도 로직이 둘로 나뉘는 것은 물론 언제 어느 시점에서 어떻게 문자의 수를 셈해야 하는 지를 판단하기 위한 조건도 필요하게 되었기 때문입니다. 그러나 이러한 문제점을 모두 해결할 수 있는 방안이 국제적으로 논의되기 시작하여 Windows NT 기반 시스템에서는 본격적으로 유니코드를 사용할 수 있게 되었습니다. 그리고 늦게나마 Windows 95, 98, Me 기반 시스템에서도 MS Unicode Layer 라이브러리가 배포되기 시작하여 유니코드를 사용할 수 있게 되었습니다. 이 때 사용하게 되는 유니코드 문자열의 기본 단위는 unsigned short형이며 이것에 대한 별칭으로 wchar_t를 사용합니다. 유니코드 문자열을 담기 위하여 우리는 L이라는 접두사를 문자열 앞에 붙였었습니다.

- unsigned short형 1차원 포인터 - wchar_t형 1차원 포인터: 앞에서 언급한 char형 1차원 포인터와 같은 맥락으로 이해할 수 있습니다. Visual C++과 Windows SDK의 헤더에서는 특별히 LPWSTR이라는 별칭을 제공하며, const 속성이 붙을 경우 LPCWSTR이라는 별칭을 이용할 수 있습니다.

- _TCHAR형 1차원 배열: _TCHAR는 tchar.h 헤더에 정의된 매크로 별칭입니다. 하지만 중요한 의미를 가지고 있는데, 바로 컴파일할 프로그램의 소스 코드에서 사용하는 문자열 시스템을 무엇으로 할 것인가에 따라서 _TCHAR형이 char형으로 번역될 수도 있고, wchar_t형으로 번역될 수도 있다는 뜻입니다. 만약 처음부터 _TCHAR형에 대해 지원을 염두에 두고 만든 라이브러리와 작업 중이거나 완전히 새로운 프로그램을 작성 중이라면 _TCHAR형 1차원 배열을 사용하는 것이 좋은 선택입니다. 하지만, char형 - 또는 - wchar_t형 자체를 문자를 담는 저장소보다 데이터를 담는 기준으로 선택한 경우에는 _TCHAR가 가지는 의미가 완전히 달라질 수 있으므로 선택에 신경을 써야 합니다. 선택적으로 변할 수 있는 문자열 시스템에 맞추어 _T() 매크로 - 또는 - __TEXT() 매크로를 사용하여 문자와 문자열을 지정하였었습니다.

- _TCHAR형 1차원 포인터: 앞에서 언급한 문자열에 대한 주소를 가리키는 포인터들과 역시 같습니다. 하지만, _TCHAR형 1차원 포인터는 어떻게 컴파일하는가에 따라서 몇 바이트씩 끊어 읽어야 하는지가 완전히 달라질 수 있다고 하였습니다. Visual C++과 Windows SDK의 헤더에서는 특별히 LPTSTR이라는 별칭을 제공하며, const 속성이 붙을 경우 LPCTSTR이라는 별칭을 이용할 수 있습니다.

- OLECHAR형 1차원 배열: OLECHAR형은 특별한 약속 없이도 인텔 기반 시스템에서는 2바이트 유니코드를 사용하도록 알려져 있습니다. OLECHAR형 자체의 정의를 보면 wchar_t와 같습니다. 하지만 OLECHAR형의 1차원 배열을 다루도록 하는 API들을 보면 wchar_t형의 1차원 배열을 다루도록 하는 API들과는 차이가 있습니다. 이것을 정확히 구분하기 위하여 BSTR이라는 별도의 정의를 두었습니다.

- OLECHAR형 1차원 포인터: OLECHAR형 1차원 배열과 맥락은 같습니다.

- BSTR: BSTR은 Basic String - 또는 - Binary String으로 알려져있으며 기존의 문자열과는 구성이 다릅니다. 다음은 MSDN Library의 설명을 인용한 것입니다. (http://msdn2.microsoft.com/en-us/library/ms221069.aspx)

이 그림에서 보여주는 것이 BSTR의 구조입니다. 우리가 아는 일반적인 문자열과는 꽤 다른 모습을 보여줍니다. 각 문자당 2바이트를 할당한다는 개념은 wchar_t형 배열과 같아서 혼동하기 쉽지만 문자열의 길이에 대한 규정이 있다는 것이 다르다는 것을 정확히 숙지하여야 합니다.

BSTR의 처음 네 바이트는 길이를 나타내는 정수 값입니다. BSTR은 기존의 문자열 시스템이 가지고 있던 치명적인 문제점의 극복을 위하여 약간의 비용을 더 지불하는 것이 특징입니다. 기존의 문자열 시스템은 NULL 문자를 만날 때 까지 계속 문자열을 탐색해야 한다는 논리적인 헛점이 존재하였습니다. 이러한 사항을 제대로 준수하지 않고 효율성만을 고려하여 작성한 프로그램의 상당수가 보안 상의 심각한 문제점을 노출하였고 현재도 그러한 사례가 빈번합니다.

- Standard Template Library의 basic_string 클래스: Standard Template Library (이하 STL)의 basic_string 클래스는 C++ 프로그래머에게는 너무나도 친숙하고 유명합니다. basic_string에 필요한 템플릿 인수만 정확히 지정하면 ANSI 문자열부터 유니코드 문자열까지 자유자재로 구사할 수 있으니까요. 하지만 C++에는 근본적인 제약이 하나 걸려있습니다. basic_string을 바라보는 프로그래머의 컴퓨터에 대한 시각은 같지만, basic_string을 바라보는 컴퓨터들과 컴파일러들의 시각은 제각기 다르다는 사실입니다.

- MFC 6.x까지의 CString 클래스: 그렇습니다. Visual C++ 초심자부터 전문가들까지 모두 사로잡은 문자열에 관한 기본 중의 기본이 되는 클래스입니다. 컴파일되는 프로그램이 유니코드 기반이던 아니던 중립을 유지하면서 상당히 많은 일을 해내는 유용한 클래스입니다.

- MFC 7.x 이후의 CString 클래스와 ATL의 CAtlString 클래스: 하지만 MFC 7.x 이후부터는 ATL과 상당히 많은 부분에서 공유를 하고 있는데 그 중 가장 큰 변화가 바로 CAtlString과 CString 클래스의 동시 제공입니다. 양쪽 클래스의 상속도를 추적해보면 CStringT 클래스와 만날 수 있습니다.

- ATL의 CComBSTR 클래스: CComBSTR 클래스는 BSTR 문자열의 응용을 위하여 설계된 클래스입니다. 특별한 변환 작업이 필요로 하지 않다면 대개는 이 클래스를 사용해왔었습니다. 하지만 별도의 변환을 위하여 매크로 구문을 사용하는 경우가 많았습니다.

- Visual C++의 _bstr_t 클래스: _bstr_t 클래스는 Visual C++에서 특별히 제공하는 클래스로 BSTR을 LPCTSTR로 전환하기 위한 C++ 스타일의 창구입니다. 거추장스러운 매크로를 사용하지 않아도 된다는 장점이 있습니다.

Visual C++에서 사용할 수 있었던 문자열의 유형만을 모아보았을 뿐인데 이토록 많은 수의 방법이 공존합니다. 게다가 메모리 관리와 운용 모두 프로그래머가 스스로 해결해야 하는 문제점이 있습니다. 이러한 모든 사항들을 닷넷 프레임워크에서는 "관리되지 않는 프로그래밍"이라고 부릅니다.

그렇다면 닷넷 프레임워크에서의 문자열은 어떤 장점들을 가지고 있는 것일까요?

1. 닷넷 프레임워크에서의 문자열은 중앙 관리 방식입니다: 닷넷 프레임워크에서는 모든 문자열을 중앙에서 관리합니다. 기본적으로 사용하지 않는 객체는 알아서 정리해준다고 하였지만 여기에 부수적으로 문자열 하나 하나를 직접 관리한다는 의미입니다. 가령 "abc" 라는 문자열을 3회 사용하는 프로그램이 있다고 합시다. 그러면 메모리에서는 "abc"라는 문자열이 세 번 저장되어있을까요? 아닙니다! "abc"라는 문자열은 하나이지만 여기에 대한 참조가 3번 걸려있는 것입니다.

2. 닷넷 프레임워크에서의 문자열은 유니코드 기반입니다: 자바와 마찬가지로 닷넷 프레임워크는 문자열을 2바이트 유니코드로 처리합니다. 따라서 2바이트 언어의 문자열 처리 때문에 고민할 이유가 전혀 없습니다.

3. 닷넷 프레임워크에서의 문자열은 매우 유연합니다: 기본적으로 제공되는 문자열 관련 유틸리티 함수들이 많고, 대량의 문자열을 다루면서 성능 상의 손해를 보지 않을 수 있는 문자열 버퍼 클래스가 있으며, 문자열의 검증과 치환을 초고속으로 수행할 수 있는 정규 표현식 도구까지 닷넷 프레임워크에서 모두 제공합니다. 따라서 문자열을 다루는 것에 관하여 닷넷 프레임워크에서는 고민할 것이 없어집니다.

이제 이러한 장점들을 가지고 있는 닷넷 프레임워크의 문자열을 가지고 콘솔 프로그래밍에서 같이 접목하여 어떻게 활용할 수 있는지를 살펴보기로 합니다.

콘솔 프로그래밍 시작하기

rkttu — Wed, 9 May 2007 11:29:53 +0900

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

시작하기 전에: 콘솔의 세 가지 표준 장치에 대한 내용, 기억나세요?

이번 단원에서는 콘솔의 세 가지 표준 장치를 닷넷 프레임워크 기반 콘솔 프로그램에서 사용하는 방법을 직접 살펴보도록 하겠습니다.

Console 클래스는 System 네임스페이스 안에 있는 클래스입니다. 다른 클래스들처럼 객체를 생성하거나 하지 않고 Console 클래스 그 자체를 직접 사용합니다. 이러한 방식으로 사용하는 클래스를 싱글턴 (Singleton) 클래스라고 부르며 실행하는 프로그램 당 하나씩만 사용할 수 있는 특별한 클래스라고 부릅니다.

Console 클래스에서 우리는 앞 단원에서 살펴본 기본 구성 요소 세 가지를 볼 수 있습니다. 마치 변수처럼 사용하고 있는 In과 Out, 그리고 Error입니다. In, Out, Error는 정확히 표현하면 변수가 아니라 Getter 함수와 Setter 함수를 묶어서 만든 Property입니다. 즉, 실제로는 Getter 함수를 호출하고 이 함수가 반환하는 어떤 객체를 변수에 담아서 사용하는 모습이지만 이것을 C#에서는 사용하기에 편리하도록 변수처럼 사용하는 것을 가능하게 한 것입니다.

In Property로 가져올 수 있는 것은 표준 입력 장치로 따로 설정하지 않았다면 키보드를 뜻합니다. 하지만 앞 단원에서 살펴보았듯이 Redirection을 이용하면 키보드가 아닌 일반 파일도 이용할 수 있다고 하였습니다.

Out Property로 가져올 수 있는 것은 표준 출력 장치로 따로 설정하지 않았다면 현재 콘솔 프로그램을 실행하고있는 콘솔 윈도우의 화면 - 또는 - 현재 콘솔 터미널의 화면을 의미합니다. 하지만 앞 단원에서 살펴보았듯이 Redirection을 이용하면 화면이 아닌 일반 파일에 내용을 쓰는 것이 가능하다고 하였습니다.

Error Property로 가져올 수 있는 것은 표준 오류 출력 장치로 따로 설정하지 않았다면 현재 콘솔 프로그램을 실행하고있는 콘솔 윈도우의 화면 - 또는 - 현재 콘솔 터미널의 화면을 의미합니다. 하지만 표준 출력 장치와 그 용도가 구분된다고 하였습니다. 그리고, 명령줄을 이용하여 표준 오류 출력 장치는 따로 지정할 수 없었지만 약간의 프로그래밍 기술을 이용하면 표준 오류 출력 장치의 내용을 파일 - 또는 - 다른 곳에 기록하는 것 역시 가능합니다.

이제 Ctrl + F5키를 눌러서 어떻게 결과가 나타나는지 살펴보기로 하겠습니다. 콘솔 프로그램은 실행이 끝나면 즉시 종료되어버리기 때문에 끝까지 내용을 확인하려면 반드시 Ctrl + F5키를 눌러야 합니다. 디버그 모드와 컴파일, 프로그램의 실행에 대한 내용은 지난 강좌를 참고하여 주세요.

Console.WriteLine과 Console.Out.WriteLine 모두 화면에 "Test"라는 문자열을 출력합니다. 그렇다면 지금 사용한 두 가지 메서드는 무슨 차이가 있을까요? 사실, 차이가 없으며 편의상 제공되는 것이 전자의 Console.WriteLine 메서드입니다. 다시 말해, Console.WriteLine은 Console.Out.WriteLine을 대리로 호출하는 것에 불과합니다.

곧이어 다른 내용을 출력하지 않고 프로그램이 멈추는 것을 알 수 있습니다. 즉, 사용자로부터 입력을 기다리고 있다는 것을 뜻합니다. 이런 상태를 가능하게 하는 메서드는 무엇일까요? 바로 Console.ReadLine 메서드입니다. 이 프로그램에서 입력되는 내용을 처리하거나 하는 코드를 따로 두지는 않았으므로 그냥 Enter 키를 눌러서 다음 동작을 살펴봅니다. 그런데 이번에도 입력을 기다리고 있습니다. 이번에는 Console.In.ReadLine 메서드를 만난 것입니다. Console.ReadLine과 Console.In.ReadLine 역시 같은 일을 하며, Console.ReadLine은 단지 Console.In.ReadLine 메서드를 호출한 것에 불과합니다.

이번에도 Enter 키를 눌러서 다음 동작을 살펴봅니다. 이번에는 "Test2" 라는 문자열이 화면에 나타나는 것을 볼 수 있습니다. 얼핏 보기에는 Console.WriteLine이나 Console.Out.WriteLine 메서드와 전혀 차이가 없는듯 보입니다. 하지만 여기에 대한 자세한 설명은 지난 강좌를 참고하시면 되겠습니다. 즉, "표준 오류 출력 장치"에 문자열을 작성하였고 그 결과를 화면에 출력한 것입니다. 이것이 Console.Error.WriteLine 메서드의 역할이 되겠습니다.

앞으로 실전에서 우리는 이렇게 기본적인 표준 장치들을 잘 활용할 필요가 있습니다. 표준 장치들을 잘 활용하면 잘 풀리지 않을 것 같은 문제도 간단히 접근할 수 있습니다. 가장 대표적인 사례가 바로 Visual Studio로 직접 간섭하기 번거로운 DLL 파일이나 Windows NT, 2000, XP, Server 2003, Vista 등의 OS에서 사용하는 Windows 서비스와 같은 프로그램의 문제를 추적할 때 아주 유용합니다.

다음 단원에서는 콘솔에 문자열을 출력하거나 콘솔로부터 문자열을 읽는 보다 자세한 방법을 공부해 볼까 합니다.

콘솔 프로그래밍 이해하기

rkttu — Sun, 29 Apr 2007 11:20:40 +0900

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

시작에 앞서: 지난번 강좌에서 살펴보았던 디버그 모드 사용법은 충분히 숙지하셨나요?

중요: Windows Fundamentals for Legacy PCs (WinFLP)를 운영 체제로 사용하고 계신 분들께서는 반드시 Windows XP Service Pack 2가 설치된 컴퓨터 - 또는 - Windows XP Service Pack 2 CD-ROM에서 null.sys 파일을 가져와 시스템에 등록하여야 합니다. 상세한 등록 방법은 "여기"에서 볼 수 있습니다.

이번 단원에서는 콘솔 프로그래밍의 개념을 배워보도록 하겠습니다. 콘솔이란 일단 무엇일까요? 쉽게 설명하면 여러분이 알고 있는 MS-DOS 창에서 실행되는 구식 인터페이스를 말합니다. 까만 배경에 회색 전경의 글자가 80열 25행의 화면에 나타나는 것을 연상할 수 있을 것입니다. 하지만 우리가 배워보려고 하는 콘솔은 언제나 이런 구식 화면이나 구식 유물 따위는 아닙니다. 실제로 콘솔은 우리들이 모르는 매우 중요한 기능들을 꼭꼭 숨겨두고 있습니다.

우선 콘솔은 세 가지의 구성 요소를 프로그래머에게 노출합니다. 표준 출력 장치, 표준 입력 장치, 표준 오류 출력 장치가 그것들인데 대개의 경우 처음 콘솔 프로그래밍에 대하여 배울 때 이러한 세부적인 구성 요소에 대한 이야기는 거의 하지 않고 넘어갑니다. 단지 화면에 글자를 찍는 것에 불과한데 처음부터 저렇게 복잡한 구성 요소가 세 개씩이나 등장한다는 게 무슨 의미가 있을 지 의아해하실 분도 계실 것입니다. 하지만 저 세 가지 구성 요소가 콘솔 프로그래밍의 백미이자 핵심입니다.

이 세 가지 구성 요소는 사실 우리가 만드는 모든 프로그램에서 기본적으로 가지고 있는 기본적인 기능들입니다. 심지어 까만 콘솔 창에서 실행되는 프로그램이 아닌 지극히 일반적인 Windows 프로그램들 (아래아 한글, 그림판, 계산기, 스타크래프트 같은 게임 등등...)에게도 당연히 주어지는 것입니다. 물론 이러한 구성 요소들을 활용해서 화면 상에 무언가 기록을 남긴다거나 하는 것은 의미가 없습니다. 하지만 우리가 앞 시간에서 살펴보았던 방법처럼 프로그램을 검사하는 것이 불가능한 경우, 지금 우리가 사용하는 이 세 가지 구성 요소는 매우 중요합니다.

그러면 이번 시간에는 운영 체제의 사용법을 되짚어보면서 이 세 가지 구성 요소들이 하는 일이 무엇인지 살펴보기로 하겠습니다.

1. 표준 출력 장치

MS-DOS에서는 CON이라는 예약어로 알려져있고 유닉스 계열 시스템에서는 /dev/stdout 이라는 파일 핸들로 찾아볼 수 있습니다. 여기에 무언가 내용을 작성하면 화면에 작성한 내용이 다시 나타나는 것을 볼 수 있습니다. 아래의 COPY 명령어의 사용법을 혹시 기억하시는지요?

COPY hello.txt CON

첫 번째 명령어는 hello.txt를 CON이라는 장치에 복사하라는 명령어입니다. 좀 더 의역하면, CON이라는 장치는 여기서 "쓰임"을 당하는 대상이며 이런 관점에서 CON은 표준 출력 장치가 됩니다. 표준 출력 장치에 무언가를 쓴다면 그 내용이 화면 상에 고스란히 나타나겠지요. 이와 같은 일을 하는 것이 바로 TYPE 명령어입니다.

그리고 아래와 같은 리디렉션의 사용법도 기억하시는지요?

DIR > result.txt

그렇습니다. DIR 명령어로 나타나는 결과는 CON이라는 장치에 복사되는데, CON이라는 장치가 원래 가리키는 모니터 출력에 내용을 작성하는 것이 아니라 현재 작업 중인 디렉터리에 result.txt라는 파일을 새로 만들어서 그 결과를 텍스트로 쓰는 것입니다. 물론 같은 이름의 파일이 있다면 지워지고 새로 만들어질 것입니다.

2. 표준 입력 장치

MS-DOS에서는 CON이라는 예약어로 알려져있고 유닉스 계열 시스템에서는 /dev/stdin 이라는 파일 핸들로 찾아볼 수 있습니다. 이것은 표준 출력 장치와는 반대로 키보드로 입력하는 내용을 받아들이는 역할을 합니다. (참고: 마우스, 스캐너, 바코드 리더 등의 확장 입력 장치는 표준 입력 장치에서 관리할 수 없는 장치들입니다.) 아래의 COPY 명령어의 사용법은 보신 적이 있으실 겁니다.

COPY CON hello.txt

그렇습니다. 방금 전에 우리가 살펴보았던 COPY hello.txt CON 이라는 명령어와 정확히 반대로 움직이게 됩니다. 키보드로부터 입력받은 내용을 현재 작업 중인 디렉터리의 hello.txt라는 파일로 복사하는 역할을 하게 되는 것입니다. 위와 같이 명령을 내려서 파일에 내용을 작성하고 저장하기 위하여 Ctrl + Z키를 눌러서 종료하는 것까지 기억하고 계신다면 잘 알고 계신 것입니다. 만약 작업을 취소하려면 어떻게 해야할까요? Ctrl + C키를 눌러서 종료하는 것입니다.

유용한 명령어 하나를 배워도록 하겠습니다. find 명령어를 이용하여 텍스트 파일에서 내용을 검색하도는 방법을 확인해보도록 하지요. 리눅스나 유닉스에서는 grep 명령어가 find 명령어와 유사합니다. (물론 grep 명령어의 기능이 더 확장된 것입니다.)

우선 파일의 내용을 만들기 위하여 시스템 디렉터리 안의 파일 목록을 한꺼번에 저장해보도록 하겠습니다.

dir %windir%\system32\*.exe > result.txt

%windir%는 시스템에서 관리하는 환경 변수입니다. Windows 운영 체제가 설치된 직후 정확한 값이 지정되는 환경 변수로 시스템에 특별한 이상이 발생하지 않았다면 언제나 유효한 환경 변수라고 할 수 있겠지요.

파일의 내용이 만들어졌으니 find 명령어를 사용하여 ntoskrnl.exe라는 파일에 관한 정보를 파일로부터 검색해보도록 하겠습니다.

find "ntoskrnl.exe" < result.txt

그러면 ntoskrnl.exe이라는 단어가 들어간 줄의 내용이 다시 표준 출력 장치에 복사되어 그 내용을 볼 수 있게 됩니다. dir 명령어는 파일 하나 당 한 줄로 표시하기 때문에 ntoskrnl.exe에 대한 내용을 정확히 살펴 볼 수 있습니다. 여기서 우리가 알 수 있는 것은 파일 이름, 파일이 수정된 날짜, 바이트 단위 파일 크기 정도가 될 것입니다.

3. 표준 오류 장치

표준 오류 장치는 주로 오류 메시지를 출력하기 위한 목적으로 사용됩니다. 표준 출력 장치와는 별도로 구분된 것이지만 그냥 보기에는 표준 출력 장치와 똑같이 움직이기 때문에 구분이 어렵습니다. 그렇다면 표준 오류 장치가 어떤 방식으로 동작하는 지 확인할 수 있는 방법은 무엇일까요? 간단합니다. 방금전에 우리가 살펴본 find 명령어를 사용하면 됩니다.

루트 디렉터리로 이동하여 NTLDR 파일이 가지고 있는 메시지를 검색해보도록 하겠습니다.

cd \
find "cat" *.*

그러면 디렉터리에 대해서는 액세스할 수 없다는 메시지와 함께 후반에 NTLDR 파일 안에 들어있는 오류 메시지들의 내용이 나타나는 것이 보입니다. NTLDR 파일은 Windows NT 기반 운영체제를 실행하는 부트 로더이며 정식 명칭은 NT Loader입니다.

이제 표준 오류 장치가 정말 작동하는지 확인해보도록 하겠습니다. 편의를 위하여 한 가지 시스템 장치를 더 사용해보도록 하겠습니다. 바로 NUL 장치입니다. NUL 장치는 유닉스에서 /dev/null과 같습니다. NUL 장치에 무언가 내용을 쓰려고 한다면 자동으로 모든 내용을 메모리에서 소거하는 것과 같습니다. (쉽게 말하면 일종의 블랙홀인 셈입니다.)

find "cat" *.* > NUL

위와 같이 명령어를 지정하면 재미있는 모습이 보입니다. 방금전에 나타났던 오류 메시지만이 화면 상에 나타나고 찾은 내역은 보이지 않게 됩니다. 이것이 바로 표준 오류 장치에 내용을 쓴 결과가 됩니다. 만약 표준 오류 장치에 내용을 기재하지 않고 표준 출력 장치에 그대로 기재하였다면 오류에 대한 정보를 알 방법이 없게 되는 것이지요.

우리가 지금 살펴본 세 가지 구성 요소는 단지 화면에 내용을 출력하는 것 이상의 역할을 할 수 있다는 것을 알 수 있습니다. "리디렉션"이라는 것을 사용하여 원하는 형태로 데이터를 가공하는 것이 가능한 것입니다. 실제로 콘솔 입/출력 기능을 성공적으로 사용하는 대표적인 예가 있는데 그것이 바로 CGI (Common Gateway Interface) 프로그램들입니다. 웹 서버가 단순히 HTML 파일을 보내기만하는 것이 아니라, HTML 파일을 웹 서버 外의 프로그램이 조작하여 그 내용을 웹 서버가 보내주는 방식입니다. 이 때, 웹 브라우저가 웹 서버에게 보낸 첨부 파일은 표준 입력 장치를 통하여 들여보내지게 되며, 웹 브라우저가 보내온 쿠키 및 변수에 관련된 정보는 환경 변수로 프로그램에 들여보내지게 되며, 이런 입력을 토대로 내용을 출력하는 것은 표준 출력 장치를 이용하게 됩니다. 만약 서버와의 처리 과정에서 발생하는 오류를 보고하려고 한다면 표준 오류 출력 장치를 응용할 수 있는 것입니다.

지금까지 설명하였던 내용이 많이 어색하시다면 차근차근 실험해보시고 이해하셔야 합니다. 사실 매우 중요한 내용이지만 항상 소개되는 비중이 적었던 부분이었고 이러한 기본 기능을 제대로 활용하지 못하여 나중에 낭패를 겪는 일도 많습니다.

새 프로젝트 만들기와 디버그 모드를 다루는 요령

rkttu — Thu, 26 Apr 2007 22:34:59 +0900

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

이번 단원에서는 Visual C# 2005 Express Edition을 이용하여 새 프로젝트를 만드는 것에 대한 설명과 함께 간단히 디버그 모드를 사용해 보기로 합니다.

1단계: 새 프로젝트 만들기

Visual C# 2005 Express Edition을 처음 시작하면 다음과 같은 화면을 볼 수 있습니다. 여기서 새 프로젝트 만들기 링크를 클릭합니다.

이제 아래와 같은 대화 상자를 보실 수 있습니다. 이 대화 상자에서 "콘솔 응용프로그램" 항목을 선택하고 이름을 확인한 뒤 "확인" 버튼을 클릭합니다.

기본적인 뼈대를 갖춘 몇 줄 안되는 코드가 화면에 나타납니다. 프로그램 코드는 아래와 같으며 한 줄 한 줄 파악해보기로 합니다.

using System;
using System.Collections.Generic;
using System.Text;

namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
}
}
}

* using 구문 (1행 ~ 3행)
C#에서 사용하고자 하는 각종 클래스와 기능들을 가져오는 구문입니다. 닷넷 프레임워크에서는 수많은 기능들을 주제별로 구분하여 편리하게 가져다 쓸 수 있도록 "묶음"을 만들어 놓았습니다. 이러한 묶음을 네임스페이스라고 부릅니다. 이 코드에서 처음 세 줄의 using 구문을 살펴보면 무엇을 사용하려고 가져왔는지 이해하기 쉽습니다. 첫 줄은 System 네임스페이스를 가져온 것인데, System 네임스페이스라면 당연히 기초적인 기능들을 모두 포함하고 있지 않을까요? 두 번째줄은 배열 이외의 특수한 자료 구조를 가져오기 위한 것임을 유추할 수 있습니다. 세 번째줄은 문자열에 관한 특수한 작업을 하기 위하여 적어놓은 구문이겠지요?

* namespace 구문 (5행)
앞에서 using은 이미 묶어놓은 네임스페이스를 가져오기 위한 구문이라고 하였습니다. 하지만 우리도 새로운 프로그램을 만드는 입장이고, 그러므로 우리 역시도 네임스페이스를 사용하여 기능별로 프로그램을 묶을 수 있습니다. 하지만 여기서 궁금한 점이 하나 생깁니다. 네임스페이스를 반드시 정해두어야만 할까요? 사실 정의하지 않아도 됩니다. 그러나 네임스페이스를 정의해두는 것은 C#과 닷넷 프레임워크를 이용하여 프로그래밍하는 동안은 지켜주어야 하는 일종의 관례가 됩니다.

* class 구문 (7행)
이제부터가 진짜입니다. class 구문은 이름 그대로 클래스를 정의하기 위한 것입니다. C#에서는 C나 C++처럼 클래스 없이 함수를 만들고 사용할 수 없습니다. 모든 기능들은 클래스를 통하여 설계가 이뤄져야 하고 클래스를 통하여 접근할 수 있어야 합니다. 심지어 우리가 사용하고자하는 DLL이 제공하는 C 언어 함수도 클래스 안에 따로 정의해야 합니다. 클래스에 대한 심층적인 내용은 나중에 다시 살펴보기로 합니다.

* Main 함수 (9행)
class 구문에 대한 설명에서도 언급하였듯이 모든 것은 반드시 클래스 안에 선언되어있어야만 한다고 하였습니다. 프로그램의 시작을 정의하는 Main 함수 역시 클래스 안에 선언되어있는 것을 볼 수 있습니다. 하지만 보통의 함수 선언과는 달리 Main 함수는 좀 특별하게 취급됩니다. 우선, 프로그램의 시작점을 알리기 위한 일종의 약속이므로 Main 함수의 이름은 철자 및 대소문자 구분 그대로 "Main" 이라는 이름의 함수여야 합니다. 더 자세한 내용은 나중에 다시 살펴보기로 합니다.

2단계: 빌드와 디버그

일단 프로그램의 기본 뼈대는 갖추어진 것이므로 컴파일하여 실행하는 것은 가능합니다. 아무것도 하는 일은 없지만 문법적인 오류는 없는지 확인해볼 수 있겠지요.

Visual C# 2005 Express Edition은 Visual Studio 2005의 기본 기능을 그대로 제공합니다. 그러므로 닷넷 프레임워크 기반의 프로그램을 컴파일하는 것은 물론 디버거 기능까지 제공해줍니다. 그렇기 때문에 컴파일러를 호출하는 방법이 다양합니다. 여기서 빌드와 디버그라는 용어가 나옵니다.

빌드는 컴파일 과정을 통하여 프로그램을 완성하는것 까지를 의미합니다. 빌드 단계에서는 주로 프로그래머가 작성한 코드에 문법적인 오류나 잠재적인 오류는 없는지 검사해줍니다. 여기에서 검사할 수 있는 오류는 문법적인 오류나 잠재적인 오류에만 한정되며 변수나 클래스의 작명이 어색하다거나 철자가 틀렸다던가 하는 부분에 관하여 간섭하지는 않습니다. 또한 프로그래머가 작성한 코드가 무엇을 하는가에 대한 내용도 역시 직접적인 검사 대상이 아닙니다.

디버그는 빌드를 수행한 다음 빌드 수행 과정을 거쳐서 나온 산출물을 실제로 실행합니다. 단, 그냥 실행하는 것이 아니라, Visual C# 2005 Express Edition 프로그램과 함께 연결하여 프로그램의 실행 과정을 추적하고, 프로그래머가 원하는 지점에서 프로그램을 강제로 중단시켜서 중단된 지점의 변수나 함수 호출 상태를 점검할 수 있습니다. 또한 어떤 명백한 오류를 우리는 예외라고 부르는데, 이러한 예외가 발생하면 예외의 내용과 발생한 원인을 살펴볼 수 있고 예외가 발생한 위치에서 프로그램을 멈추게 할 수 있는 실행 기능을 말합니다.

보통 빌드 단계와 디버그 단계는 별도로 구분되는 것입니다. 하지만 디버그 단계를 수행하기 위하여 빌드를 하는 것은 당연하고, 우리가 실제로 문제를 해결하기 위해서는 디버그 단계에 접근할 수 있어야 합니다. Visual C# 2005 Express Edition은 빌드 단계와 디버그 단계를 따로 나누지 않고 한 번에 처리하며, 디버그를 시작하도록 명령을 내리기만 하면 빌드 단계도 자동으로 수행하여 문법적인 오류를 검사합니다. 만약 문법적인 오류가 있는 코드라면 컴파일이 중지되고 사용자에게 안내를 하게 될 것입니다.

표준 메뉴를 잠시 살펴보도록 하지요.

가운데의 "빌드(B)" 메뉴와 "디버그(D)" 메뉴가 보입니다. 실제로 이들 메뉴는 여기에 관련된 기능만 모아서 표시해줍니다. 우선 "빌드(B)" 메뉴부터 클릭해 보도록 하겠습니다.

빌드 메뉴를 클릭했는데, 갑자기 어려운 용어가 보입니다. "솔루션"이 뭘까요? 역시 사전적인 정의와는 거리가 먼 그저 별칭일 뿐입니다. 프로그램을 만들기 위하여 우리가 만들었던 것은 "프로젝트"였고, 이것들의 모음을 Visual C# 2005 Express Edition과 Visual Studio 2005에서는 "솔루션"이라고 부르는 것 뿐입니다. 이것은 실제로 개발 도구마다 제각기 명칭이 다릅니다. 볼랜드 디벨로퍼 스튜디오에서는 그룹 프로젝트라고 부르며, 옛날 Visual Studio 6.0 이하 버전의 경우 Visual C++에서는 워크스페이스, Visual InterDev에서는 솔루션이라고 불렀습니다. 별칭만 다양할 뿐 진짜 의미는 하나입니다. "프로젝트"의 묶음입니다.

솔루션과 프로젝트의 차이는 쉽습니다. 개발 도구 화면의 오른쪽을 보시면 솔루션이 부모이고 프로젝트가 자식으로 표현되어있는 것이 보이실 겁니다. 오른쪽 그림과 같습니다.

그러면 빌드 메뉴와 다시 빌드 메뉴의 차이가 궁금해지네요. 둘 다 같은 일을 수행합니다. 하지만 기왕 빌드하는것이면 시간을 좀 더 절약하면서 빠르게 빌드할 수 있다면 좋겠지요? 우리가 보통 사용하는 빌드는 똑똑한 빌드입니다. 즉, 소스 코드를 검사해서 바뀐 내용이 없으면 컴파일하지 않고 바뀐 내용이 있으면 전체를 다시 컴파일합니다. 반면 다시 빌드는 이러한 검사 기능 없이 무조건 새로 빌드를 시작합니다. 드문 사례이지만 가끔 다시 빌드가 필요할 때가 있습니다.

맨 아랫쪽의 게시 메뉴또한 궁금증을 유발합니다. 프로그램 게시 기능에 대해서는 C# 강좌가 아닌 다른 강좌를 통하여 상세하게 다룰 예정이며 이 기능은 우리가 C#을 배우는 동안 필요하지 않은 기능이므로 건너뜁니다.

디버그 메뉴는 무엇인지 모를 기능이 많습니다. 첫 번째 메뉴는 하위 메뉴까지 있지만 지금은 볼 필요가 없습니다. 디버그 모드에 들어가면 Visual C# 2005 Express Edition이 알아서 창을 구성해주기 때문입니다.

디버깅 시작이 바로 우리가 찾는 기능입니다. 단축키는 F5키이니 외워두도록 합시다. 디버그를 시작하기 전에 빌드를 한다고 하였는데, 이 때 사용하는 빌드도 똑똑한 빌드입니다.

그리고 가끔은 디버깅하지 않고 시작이라는 메뉴도 필요합니다. 이 역시 똑똑한 빌드를 사용하여 먼저 빌드를 진행하고 프로그램을 실행합니다만, Visual C# 2005 Express Edition과 따로 놀게 실행하는 것을 말합니다.

예외 메뉴는 거의 사용하지 않는 메뉴입니다. 이 메뉴는 디버거가 프로그램을 실행하는 동안 발생할 수 있는 다양한 예외들 가운데에서 특정 예외는 디버거가 잡아내지 않도록 하는 것을 말합니다. 하지만 이러한 설정 아래에서 디버거를 시작하는 일은 별로 없습니다.

한 단계씩 코드 실행이라는 메뉴와 프로시저 단위 실행이라는 메뉴가 있습니다. 이들 메뉴 역시 F5키를 눌러 시작하는 것과 동작은 비슷합니다. 하지만 프로그램이 시작된 첫 순간부터 프로그램을 중단시키고 현재 실행 중인 코드를 화면에 나타냅니다. 여기서, 한 단계씩 코드 실행을 누르면 한 줄 - 또는 - 한 번에 처리 가능한 명령어 단위로 끊어서 실행하고 다시 정지합니다. 만약 함수를 호출하는 부분에 이르러 이 메뉴를 부르면 함수 안으로 들어가게 됩니다. 프로시저 단위 실행은 한 단계씩 코드 실행과 비슷하게 동작하지만 함수를 호출하는 부분에서 함수 안으로 들어가지 않고 함수 호출이 끝난 그 다음 단계를 실행합니다.

중단점 설정/해제 기능이 제일 중요합니다. 이 기능을 사용하여 프로그래머가 원하는 곳에서 프로그램을 정지시킬 수 있습니다. 그리고 앞서 설명한 기능을 응용할 수 있습니다. 예를 들어, 어떤 지점에서 프로그램을 정지시켰다면 코드를 한 줄 한 줄 실행해가며 변화를 추적할 수 있습니다. 이 기능은 꼭 외워야 하는 단축키를 가지고 있으며 F9키입니다. 원하는 곳에서 F9키를 누르면 왼쪽 그림과 같이 중단점이 설정됩니다. 다시 F9를 누르면 중단점 설정이 해제됩니다.

3단계: 디버그 모드 실전

중단점 기능을 시험해보기 위하여 위의 그림과 같이 중단점을 설정합니다. 그리고 F5키를 눌러서 프로그램을 실행시켜보십시오. 오른쪽 그림과 같이 프로그램의 실행이 멈추고 Visual C# 2005 Express Edition의 화면에서 현재 중단된 위치가 나타납니다.

이와 같이 실행이 멈추게 되면 멈춘 시점에서의 변수 상황과 어떠한 함수들을 호출하게 되어 현재까지 이르게 되었는가에 대한 함수 목록을 화면 아래의 창에서 볼 수 있습니다.

미리 지정된 변수인 args에 대한 정보가 나오는 것을 볼 수 있습니다. 이번에는 아랫쪽의 "조사식" 탭을 클릭해봅시다.

조사식 창에서는 현재 중단된 시점에서 사용할 수 있는 변수들과 닷넷 프레임워크의 함수들, 그리고 수식의 조합으로 프로그래머가 알고 싶은 내용을 계산해주는 창입니다. 조사식 창 안의 테이블은 입력이 가능한 테이블로 테이블에서 가장 마지막 행의 "이름" 열에 해당하는 셀을 클릭하면 입력이 가능한 상태로 바뀝니다.

이번에는 오른쪽편의 호출 스택 창을 살펴보도록 하겠습니다.

스택이라는 말에 대해서 잠시 되짚어볼까요? 스택은 First-In / Last-Out 또는 Last-In / First-Out 방식의 자료 구조입니다. 즉, 옆의 그림과 같은 틀을 스택이라고 부릅니다. 옆의 그림과 같은 틀에서 어떤 물건을 집어넣거나 뺀다고 하면 당연히 가장 먼저 들어간 물건은 가장 아래로 들어가므로 가장 나중에 꺼내어지게 됩니다. 반대로 가장 나중에 들어간 물건은 가장 먼저 꺼내어지게 됩니다.

호출 스택이라는 용어도 정리하면 같습니다. 다만 스택에 무엇을 담았느냐의 차이가 됩니다. 즉, 함수가 실행된 순서를 스택이라는 저장소에 보관해두는 것을 말합니다. 함수가 새로 시작되면 스택에 밀어넣고, 함수가 끝나면 스택에서 꺼냅니다. 이것을 호출 스택이라고 부르며 위의 창은 현재 시점에서의 호출 스택을 조회한 결과가 됩니다.

호출 스택 조회 결과에 나타나는 항목을 더블 클릭하면 해당되는 소스 코드를 자동으로 보여주게 됩니다. 호출 스택은 나중에 프로그램을 디버그하는 도중에 발생하는 예외를 잡는데 아주 중요한 역할을 합니다. 그러므로 꼭 기억해두도록 합시다.

호출 스택을 살펴보았고 이제 "직접 실행 창" 탭을 클릭해봅시다.

직접 실행 창은 조사식 창에서 사용할 수 있는 문법을 그대로 지원하지만 조사식 창과는 달리 콘솔 윈도우처럼 되어있어서 출력할 내용이 많은 조사식의 검증에 유리합니다. 직접 실행 창에 관한 자세한 내용은 나중에 자세히 살펴보기로 하겠습니다.

중단점에서 모든 내용을 분석하고 다음 단계로 진행하기 위해서 우리는 몇 가지 단축 키를 사용할 수 있습니다.

* F5키: 하나 이상의 중단점을 한 함수 안에 여러 개 설정해두었다면 F5키를 눌러 다음 중단점을 만날 때 까지 계속 실행하도록 할 수 있습니다.
* F10키: 중단점 설정 여부와 상관없이 다음 단계를 실행하지만 함수 호출을 만나면 함수 안으로 진입하여 상세한 내용을 봅니다.
* F11키: 중단점 설정 여부와 상관없이 다음 단계를 실행하지만 함수 호출을 만나도 함수 안으로 진입하지 않고 계속 진행합니다.

팁: 만약 F10키를 눌러서 함수 안으로 들어왔지만 별 다른 소득이 없는 경우도 있습니다. 이럴 때에는 Shift + F11키를 누르면 함수의 실행이 끝나자마자 다시 프로그램을 중단시켜줍니다.

프로그램의 실행이 끝나면 자동으로 디버그 모드가 해제되면서 원래 상태로 복귀됩니다. 만약 중간에 디버그를 취소하고싶다면 오른쪽 그림에서처럼 정지 버튼을 클릭하면 됩니다.

이제 디버그 모드를 사용하는 방법을 모두 살펴보았습니다. 아무것도 프로그래밍한 것이 없지만 벌써 이만큼의 기능을 활용해 볼 수 있었습니다. 좀 더 복잡한 프로그램을 작성하다보면 이번 강좌에서 알려드린 기본적인 조작법이 매우 유용할 것입니다.

C# 제대로 알고 넘어가기

rkttu — Thu, 19 Apr 2007 23:06:55 +0900

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

Visual C# 2005 Express Edition을 설치하고 등록 과정까지 마치느라 수고 많으셨습니다. 이제부터 본격적으로 C#을 사용하기 위하여 필요한 중요한 몇 가지 개념을 같이 살펴보기로 합니다.

기본적으로 C#은 컴파일러가 필요한 컴파일 기반 언어입니다. 하지만 우리가 이전에 사용한 적이 있는 C와 C++ 처럼 링커가 존재하지 않습니다. 지금 말하고자 하는 개념은 상당히 중요한 부분이지만 의외로 가볍게 여겨집니다.

C와 C++은 컴파일러를 통하여 현재 컴파일러를 실행한 컴퓨터의 프로세서가 가장 잘 이해할 수 있고 받아들이기 쉬운 형태의 기계어로 번역하는 작업과, 이렇게 만들어진 기계어 모음들을 하나로 묶어주는 링커를 통해 최종 형태의 파일을 받아볼 수 있게 됩니다.

하지만 C#은 컴파일러를 통하여 컴퓨터가 이해할 수 있는 형태의 기계어 모음을 만드는 것이 아닙니다. 닷넷 프레임워크 안에서 통용되는 별도의 기계어로 번역하고 이것을 최종 산출물인 EXE 파일이나 DLL 파일로 바로 만들어냅니다. 하지만 컴퓨터가 이해할 수 있는 형태의 기계어가 아님에도 불구하고 실행하면 잘 실행될 것입니다. 왜 그럴까요?

C#을 통하여 만들어낸 닷넷 프레임워크 안에서 통용되는 별도의 기계어를 우리는 MSIL이라고 부릅니다. 그리고 MSIL의 조합으로 만들어진 EXE 파일이나 DLL 파일을 닷넷 어셈블리라고 부릅니다. 이들 닷넷 어셈블리는 닷넷 프레임워크가 설치된 컴퓨터에서는 잘 실행되지만 그렇지 않은 컴퓨터에서는 닷넷 프레임워크가 필요하다는 안내 메시지를 띄우고 곧바로 종료됩니다. 즉, 닷넷 프레임워크에 의하여 MSIL이 해석되는 것이므로 닷넷 프레임워크가 없으면 C#으로 만든 프로그램은 실행할 수 없는 것이지요.

여기서 우리는 확실히 정하고 넘어가야 하는 것이 있습니다. C#은 닷넷 프레임워크와 같은 별도의 프레임워크가 있어야 실행이 되고 사용할 수 있는 언어입니다. 성능의 문제와 상관없이 여러분께서 다음과 같은 분야의 프로그래밍을 위하여 C#을 선택하신 것이라면 좀 더 생각해 보시면 좋겠습니다.

* 게임 / 성능 집약적 소프트웨어 개발
* 인터넷 브라우저를 통하여 전송될 수 있는 작은 규모의 소프트웨어
* 필요한 구성 요소 없이 한 번에 배포가 가능해야만 하는 소프트웨어
* 빠른 성능이 특별히 필요로 하는 Windows CE용 소프트웨어

반면 아래와 같은 조건의 프로그램에 대하여 C#은 매우 이상적입니다.

* 균일한 인트라넷 환경 아래에서의 데스크 탑 소프트웨어
* 윈도우 서버에 최적화된 웹 사이트 및 웹 서비스 개발
* 데이터를 보여주고 교환하는 Windows CE용 소프트웨어
* 32비트/64비트 소프트웨어를 최적의 비용으로 구현 시
* Windows Vista / Windows Server 2008용 소프트웨어 구현
* XBOX 360용 게임 소프트웨어 구현

위의 조건이 항상 절대적인 것은 아닙니다. 하지만 일반적인 사례를 들어 나열한 것으로 대개의 경우 위의 조건에 맞추어보면 C#이 지금 사용하고자 하는 언어로서 적절한 언어인지 아닌지를 빠르게 파악할 수 있을것입니다.

만약 C#이 현재 사용하고자 하는 언어로서 적절하지 않다는 결론이 나왔더라도 너무 실망하지는 마시기 바랍니다. C#의 장점과 단점을 살펴보시면서 C#과 닷넷 프레임워크에 대한 기술적인 이해를 겸하실 수 있다면 좋을 것입니다.

다음 강좌부터는 본격적으로 우리가 설치한 개발 도구를 이용하여 콘솔 프로그래밍부터 시작해 보도록 하겠습니다. 천리길도 한걸음부터입니다. :-)