12-3.어트리뷰트

12-3-1.공통 어트리뷰트

어트리뷰트(Attribute)는 컴파일러에게 코드에 대한 추가 정보를 제공한다. 이 정보는 컴파일 방식에 영향을 주거나 실행 파일에 포함되어 리플렉션으로 조사할 수 있으며 코드 문서화에도 사용된다. 개수나 활용 용도에 대한 제약은 없다. 적용 대상앞에 [ ]괄호와 함께 어트리뷰트 명을 적고 ( ) 괄호 안에 인수를 지정한다. 이름없는(unnamed, positional) 인수와 이름있는(named) 인수가 있는데 지정하는 방법이 조금 다르다. 기본 형식은 다음과 같다.

[SomeAttribute(인수)]

클래스, 메서드, 프로퍼티, 인수 등등

시스템이 제공하는 공통 어트리뷰트와 사용자가 정의하는 커스텀 어트리뷰트가 있다. 공통 어트리뷰트는 주로 컴파일 방식에 영향을 준다.

Conditional

메서드의 컴파일 여부를 결정한다. 인수로 지정한 심볼이 있으면 메서드를 컴파일하고 그렇지 않으면 무시한다. 심볼은 #define문으로 정의한다. 메서드 정의부 뿐만 아니라 호출부까지 같이 조건부 처리하여 아예 없는 함수로 만들 수 있다. 다음 조건에 부합하는 메서드에만 쓸 수 있다.

l 인터페이스 소속의 메서드에는 쓸 수 없다. 인터페이스는 확정된 계약이기 때문에 조건부로 컴파일해서는 안된다.

l 가상 메서드에는 쓸 수 있지만 재정의되는 메서드에는 쓸 필요가 없다. 가상 메서드가 조건부이면 재정의된 메서드도 자동으로 조건부이다.

l 메서드가 없어도 다른 부분이 영향을 받아서는 안된다. 있어도 그만 없어도 그만이어야 하며 핵심 메서드가 조건부여서는 안된다. 리턴 타입은 void여야 하며 출력용 인수도 가질 수 없다.

다음 예제는 셰어웨어 프로그램의 한 예인데 TRIAL 심볼의 정의 여부에 따라 TrialMessage 메서드의 컴파일 여부가 결정된다.

Trial
#define TRIAL using System; using System.Diagnostics; class CSTest { [Conditional("TRIAL")] static void TrialMessage() { Console.WriteLine("이 제품은 30일간만 사용할 수 있습니다."); Console.WriteLine("정품을 구입하시려면 어쩌고 저쩌고.\n"); } static void Main() { TrialMessage(); Console.WriteLine("게임을 시작합니다."); } }
실행결과	이 제품은 30일간만 사용할 수 있습니다. 정품을 구입하시려면 어쩌고 저쩌고. 게임을 시작합니다.

TrialMessage 메서드는 Conditional 어트리뷰트에 의해 TRIAL 심볼이 정의되어 있을 때만 컴파일된다. 이대로 컴파일하여 실행하면 TrialMessage도 같이 컴파일되며 프로그램 시작 전에 공짜 사용자를 귀찮게 하는 메시지가 출력된다.

소스 선두의 #define TRIAL을 주석 처리하면 TrialMessage 메서드는 컴파일 대상에서 제외되며 호출 코드도 같이 제거된다. 메시지가 출력되지 않고 곧바로 게임이 시작된다. 두 개의 조건을 같이 기술하면 둘 중 하나라도 정의되어 있을 때 컴파일된다.

[Conditional("TRIAL"), Conditional("FREE")]

static void TrialMessage() { ... }

TRIAL이나 FREE 둘 중 하나라도 정의되어 있으면 메시지는 출력된다. 즉, 두 조건은 OR로 연결된다. 두 조건을 AND로 연결하는 방법은 조금 까다로운데 두 개의 메서드를 정의하고 한 쪽에서 다른 쪽을 호출한다.

[Conditional("TRIAL")]

static void TrialMessage() { TrialMessage2(); }

[Conditional("FREE")]

static void TrialMessage2() { ... }

조건부 컴파일 기능은 활용성이 높다. 특히 디버그 버전과 릴리즈 버전을 다르게 작성할 때 실용적이다. 디버그 버전일 때는 DEBUG 심볼이 정의되므로 이 심볼이 있을 때 트레이스 출력문이나 로그 기록문을 작성하여 디버깅 용도로 쓸 수 있다.

Obsolete

Obsolete 어트리뷰트는 경고나 에러를 발생시켜 곧 폐기될 구식 코드임을 표시한다. 이전 것을 폐기하고 새로운 것으로 대체하더라도 기존 사용자를 위해 함부로 없애 버려서는 안되며 계도 기간이 있어야 한다. 이럴 때 Obsolete 어트리뷰트를 붙이는데 거의 대부분의 요소에 적용 가능하다.

[Obsolete("메시지", error)]

대상

첫 번째 인수는 경고나 오류 메시지 문자열이며 컴파일러의 출력창에 나타난다. 폐기 이유와 대체 수단, 폐기 시점을 상세하게 기술할 수 있다. 두 번째 인수는 오류 발생 여부인데 이 인수가 true이면 에러로 처리되어 컴파일이 거부된다. false이거나 생략하면 경고로 처리되어 당분간은 계속 쓸 수 있다.

Obsolete

using System;

using System.Diagnostics;

class CSTest {

[Obsolete("NewMethod를 사용하시오")]

static public void OldMethod() { }

static public void NewMethod() {

Console.WriteLine("새로 만든 최신형 메서드입니다.");

}

[Obsolete("앞으로는 이 메서드를 쓰지 마시오.", true)]

static public void OutDateMethod() { }

static void Main() {

OldMethod();

NewMethod();

// OutDateMethod();

}

}

OldMethod에 Obsolete 어트리뷰트가 지정되어 있어 곧 폐기된다는 것과 더 효율적인 NewMethod가 제공됨을 알린다. 컴파일하면 사용하지 말 것과 대체 수단에 대한 친절한 안내 메시지가 출력창에 나타난다.

경고 CS0618: 'CSTest.OldMethod()'은(는) 사용되지 않습니다. 'NewMethod를 사용하시오'

경고일 뿐이어서 컴파일은 가능하며 메시지를 무시하고 계속 사용할 수도 있다. 그러나 언제 폐기될지 모르니 가급적 지시대로 따르는 것이 좋다. 사용자는 이 메시지를 받았을 때 OldMethod 호출문을 NewMethod 호출문으로 하나 둘씩 바꿀 것이다.

OutDateMethod는 두 번째 인수가 true여서 아예 에러로 처리되며 주석을 풀면 컴파일이 거부된다. 아예 없애 버리는 것도 한 방편이지만 이렇게 되면 사용자는 왜 이 메서드가 폐기되었는지 알 수 없으므로 당분간은 유예 기간을 두는 것이 좋다.

개발자는 구형 메서드가 잘 동작하면 계속 쓰는 관성이 있다. 당장 잘 돌아가면 손 보기 귀찮아 방치하다가 메서드가 없어지면 그때서야 부랴부랴 새로운 방법을 찾느라 당황한다. Obsolete는 폐기 예정을 적극적으로 알려 부드러운 이전을 유도한다.

DllImport

DllImport 어트리뷰트는 외부 DLL의 함수를 선언할 때 사용한다. COM 라이브러리의 함수나 Win32 API 함수를 사용하고 싶을 때 이 어트리뷰트로 어떤 DLL에 있는 함수인지 밝힌다. 다음 예제는 두 개의 API 함수를 호출한다.

DllImport

using System;

using System.Runtime.InteropServices;

class CSTest {

[DllImport("User32.dll")]

public static extern int MessageBox(int hParent, string Message, string Caption, int Type);

[DllImport("Kernel32.dll")]

public static extern uint WinExec(string Path, uint nCmdShow);

static void Main() {

MessageBox(0, "메모장을 실행합니다.", "알림", 0);

WinExec("notepad.exe", 1);

}

}

메시지 박스를 열고 메모장을 실행하려면 MessageBox와 WinExec API 함수를 호출해야 한다. MessageBox는 User32.dll에 의해 제공되며 WinExec는 Kernel32.dll에 의해 제공된다. 둘 다 닷넷 외부의 DLL에 정의되어 있어 extern 지정자를 붙여야 하며 클래스의 멤버가 아니므로 static이어야 한다.

인수의 타입은 C# 스타일로 적당히 조정한다. 문자열 포인터는 string 타입으로 표현할 수 있으며 unsigned는 uint로 바꾼다. MB_OK나 SW_SHOWNORMAL 같은 매크로 상수는 값을 직접 조사하여 정수 상수를 쓰는 수밖에 없다.

두 언어에 대한 경험이 있다면 단순 타입을 사용하는 함수는 어느 정도 변환 가능하지만 구조체를 인수로 받는 함수는 호출하기 쉽지 않다. 구조체안에 포인터나 또 다른 구조체가 있으면 골치 아프다. 닷넷은 상호 운용성을 위해 외부 함수를 호출하는 것은 허용하지만 그 기술은 결코 간단하지 않다.

영어의 Property와 Attribute를 번역하면 둘 다 속성이어서 두 개념이 서로 구분되지 않는다. 그래서 영문 발음대로 표기하는데 영어로 해도 같은 개념을 칭하기는 마찬가지이다. 공식 문서에서는 프로퍼티를 속성으로, 어트리뷰트는 특성으로 번역하는데 사실 그게 그거다. 용어의 원문도 잘 알아둘 필요가 있다.

12-3-2.커스텀 어트리뷰트

사용자가 정의하는 커스텀 어트리뷰트는 컴파일 방식이나 코드에는 영향을 주지 않으며 실행 파일에 메타 데이터로 포함된다. 일종의 주석이되 일정한 형식이 있으며 프로그래밍 방식으로 조작할 수 있어 자동화된 처리가 가능하다. 컴파일러는 형식이 맞는지 체크하여 기록만 해 놓을 뿐 어디다 써 먹을 것인지는 사용자 마음대로이다. 다음 예제는 메서드와 필드에 제작자와 작성 시기를 어트리뷰트로 기록한다. 실행해 봐야 별 출력은 없다.

CustomAttribute

using System;

[AttributeUsage(AttributeTargets.Method | AttributeTargets.Field,

AllowMultiple = true, Inherited = false)]

class ProgrammerAttribute : Attribute {

private string Name;

private string Time;

public ProgrammerAttribute(string aName) {

Name = aName;

Time = "기록없음";

}

public string When {

get { return Time; }

set { Time = value; }

}

}

class CSTest {

[Programmer("Kim")]

static public int Field1 = 0;

[Programmer("Kim", When = "2019년 6월 29일")]

static public void Method1() { }

[Programmer("Lee")]

static public void Method2() { }

[Programmer("Park"), Programmer("Choi")]

static public void Method3() { }

static void Main() {

}

}

어트리뷰트도 클래스인데 ProgrammerAttribute라는 이름으로 정의했다. 커스텀 어트리뷰트는 Attribute 클래스로부터 상속받으며 꼬랑지가 ~Attribute로 끝나면 지정할 때 접미를 생략할 수 있어 편리하다.

Programmer는 제작자 이름을 기억하는 Name 필드와 작성 시점을 기록하는 Time 필드를 멤버로 선언한다. 생성자는 제작자 이름을 받아 Name 필드를 초기화하고 Time은 "기록없음"으로 초기화한다. Time을 변경할 때는 When 프로퍼티를 통해 When = "언제" 식으로 대입한다.

적용할 때는 [ ] 괄호 안에 어트리뷰트를 명시하고 () 괄호 안에 인수를 전달한다. 인수는 이름 여부에 따라 두 가지 종류로 구분되는데 초기화하는 방법이 다르다. 이름없는 인수는 생성자에서 실인수값을 받아 초기화하며 이름있는 인수는 필드나 프로퍼티로 표현하므로 A = B식으로 대입한다.

Name이 이름없는 인수이며 When은 이름있는 인수이다. 이름없는 인수는 반드시 지정해야 하지만 이름있는 인수는 필요할 때만 지정할 수 있다. 이름없는 인수가 이름있는 인수보다 먼저 와야 하며 이름있는 인수끼리의 순서는 중요하지 않다. 다음 두 지정문의 효과는 동일하다.

[SomeAttr("unnamed", A=1, B=2)]

[SomeAttr("unnamed", B=2, A=1)]

인수에 대입되는 값에는 아무 타입이나 쓸 수 없고 약간의 제약이 있다. 기본형과 string, object, Type 클래스, 열거형, 그리고 1차원 배열만 가능하다. 2차원 배열이나 클래스 타입의 객체는 쓸 수 없다. 그래서 시점을 표현하는 Time이 DateTime 객체가 아니라 단순한 string이다.

어트리뷰트 선언문에 또 다른 어트리뷰트인 AttributeUsage로 여러 가지 성질을 지정한다. 생략할 수 있지만 대개의 경우는 적용 대상을 지정하기 위해 꼭 필요하다. 어트리뷰트를 정의하는데 어트리뷰트가 사용되는 셈이다. AttributeUsage로 다음 세 가지 성질을 지정한다.

l ValidOn : 이름없는 인수이며 적용 가능한 요소를 지정한다. 초기화할 때 생성자로 딱 한 번만 지정할 수 있으며 이후 ValidOn 프로퍼티로 읽을 수만 있다. AttributeTargets 열거형으로 적용 대상을 지정하며 두 개 이상의 요소는 | 연산자로 묶는다.

열거값	적용 대상
All	모든 요소
Assembly	어셈블리
Class	클래스
Constructor	생성자
Delegate	델리게이트
Enum	열거형
Event	이벤트
Field	필드
GenericPrarameter	제네릭 인수
Interface	인터페이스
Method	메서드
Module	모듈. 단 비주얼 베이직 모듈은 제외
Parameter	형식 인수
Property	프로퍼티
ReturnValue	리턴값
Struct	구조체

l AllowMultiple : 이름있는 인수이며 필요할 때만 지정한다. 한 대상에 여러 번 적용할 수 있는지를 지정하는데 디폴트는 false여서 딱 한 번만 지정할 수 있다. 동일한 어트리뷰트를 여러 번 지정하는 것이 의미가 있다면 이 인수를 true로 변경한다.

l Inherited : 이름있는 인수이며 필요할 때만 지정한다. 파생 클래스나 재정의되는 메서드에도 적용할 것인가를 지정하는데 디폴트는 true이다. 클래스에 이 어트리뷰트를 지정하면 파생 클래스에도 적용된다.

Programmer 어트리뷰트는 메서드와 필드에 대해 적용하도록 초기화했다. 따라서 이 어트리뷰트를 클래스나 프로퍼티에 적용하면 에러 처리된다. 한 메서드를 여러 명의 개발자가 같이 만들 수도 있어 AllowMultiple은 true로 지정하여 여러 번 적용할 수 있도록 했다. Inherited는 false로 지정하여 상속은 하지 않았다.

CSTest에서 각 요소에 대해 Programmer 어트리뷰트를 붙여 누가 언제 만든 것인지 기록해 두었다. Field1은 Kim이 만들었으며 Method1은 Kim이 2019년 6월 29일 만들었다. Method2는 Lee가 만들었고 Method3는 Park, Choi가 같이 만들었음을 어트리뷰트로 기록해 두었다. 중복 지정할 때 순서는 무관하며 쉼표로 끊어 지정할 수도 있고 [ ] 괄호를 따로 쓸 수도 있다. 다음 지정문의 효과는 모두 동일하다.

[Programmer("Park"), Programmer("Choi")]

[Programmer("Choi"), Programmer("Park")]

[Programmer("Park")] [Programmer("Choi")]

어트리뷰트가 적용되는 대상은 바로 다음에 있는 요소이며 위치적으로 결정된다. 그러나 이렇게 하면 다소 애매한 경우도 있는데 이때는 어트리뷰트 지정문에 적용 대상을 분명히 밝혀야 한다. 다음 지정문을 보자.

[Some]

public static int Method1(string s) { return 0; }

Some 어트리뷰트를 Method1에 적용했다. 그런데 만약 메서드 전체가 아닌 리턴 타입에만 적용하고 싶다면 다음과 같이 지정문앞에 return:을 붙인다. 이런 식으로 assembly:, module:, type:, method:, param: 등의 적용 대상 지정문이 있는 어트리뷰트는 지정한 요소에만 적용된다.

[return:Some]

public static int Method2(string s) { return 0; }

커스텀 어트리뷰트는 코드에는 아무런 영향을 미치지 않는다. 그러나 실행 파일에 메타 데이터로 포함되므로 리플렉션으로 이 정보를 관리할 수 있다. 예를 들어 위 예제의 경우 어떤 메서드에서 버그가 발생했다면 누가 언제 추가한 메서드인지 알아낼 수 있으며 프로젝트 관리를 별도의 프로그램으로 만들어 자동화할 수 있다.

개발만큼이나 프로젝트 관리도 중요하다. 어트리뷰트를 잘 활용하면 프로젝트 관리에 필요한 모든 정보를 프로젝트 자체에 내장할 수 있다. 작성자와 시점 외에도 수정 사항, 우선순위, 버그 목록, 메모 등을 기록해 놓으면 여러 가지 용도로 활용할 수 있으며 프로젝트 관리 업무가 자동화된다.

12-3-3.전처리문

전처리문은 C에서 빌려온 문법이며 컴파일과 소스 관리 방식에 영향을 미친다. C의 전처리(Preprocessing)는 명령에 따라 소스를 재구성하는 과정을 의미하는데 C#에서는 실제로 전처리 과정이 존재하지 않으며 컴파일러가 처리한다.

C#의 전처리 명령은 종류와 형식이 C와 거의 비슷하고 동작이나 용도도 같다. 단, #include는 없는데 C#은 선언 순서가 의미 없고 헤더 파일의 개념이 없기 때문이다. C#의 전처리 명령을 간단하게 정리해 보자.

■ #define, #undef

심볼을 정의하거나 취소한다. #define SYMBOL 식으로 사용하며 존재를 정의할 뿐 값을 대입하지는 않는다. 이 심볼은 조건부 컴파일 지시자와 함께 사용한다. 반드시 소스의 선두에 적어야 하며 심지어 using 선언보다 더 앞에 있어야 한다. 프로젝트 속성창에서도 심볼을 정의할 수 있다.

■ #if, #else, #elif, #endif

조건부 컴파일 지시지이다. 심볼의 존재 여부에 따라 특정 부분을 컴파일하거나 제외한다. 대상 코드를 #if와 #endif로 감싸면 이 부분이 조건부 컴파일된다. 심볼이 없는 경우를 처리하고 싶다면 중간에 #else를 쓸 수도 있고 또 다른 조건을 지정하고 싶다면 #elif를 쓸 수도 있다.

이 두 전처리문을 사용하면 조건부 컴파일을 할 수 있다. 앞에서 Conditional 어트리뷰트로 만들었던 예제를 전처리문으로 다시 작성해 보자.

ifendif

#define TRIAL

using System;

class CSTest {

#if TRIAL

static void TrialMessage() {

Console.WriteLine("이 제품은 30일간만 사용할 수 있습니다.");

Console.WriteLine("정품을 구입하시려면 어쩌고 저쩌고.\n");

}

#endif

static void Main() {

#if TRIAL

TrialMessage();

#endif

Console.WriteLine("게임을 시작합니다.");

}

}

TRIAL 심볼의 존재 여부에 따라 TrialMessage 메서드 정의문과 호출문을 조건부로 컴파일했다. 전처리문은 들여쓰기를 하지 않기 때문에 소스 모양이 난잡하며 호출문까지 일일이 #if ~ #endif로 감싸야 한다. 그래서 C#은 더 편리한 Conditional 어트리뷰트를 제공한다.

그러나 이 방식이 불편해 보여도 아직까지 쓸 데가 많으며 어트리뷰트보다 융통성이 높다. 워낙 단순한 방식으로 동작하기 때문에 메서드 뿐만 아니라 개별 코드를 조건부 처리할 수 있고 클래스나 필드에 대해서도 적용할 수 있다. 다음과 같이 메서드 내의 일부 코드에 대한 조건부 컴파일은 어트리뷰트로는 할 수 없다.

static void TrialMessage() {

#if TRIAL

Console.WriteLine("이 제품은 30일간만 사용할 수 있습니다.");

Console.WriteLine("정품을 구입하시려면 어쩌고 저쩌고.\n");

#endif

}

또한 &&, || 같은 논리 연산자를 쓸 수 있어 두 개의 조건을 점검하기 쉽다. Conditional 어트리뷰트는 여러 가지 조건을 적용하기 불편하며 게다가 #else에 해당하는 기능이 없어 선택적으로 코드를 컴파일할 수 없다. 때로는 논리적으로 동작하는 신형보다 기계적으로 동작하는 구형이 더 편리한 경우도 있다.

■ #warning, #error

뒤쪽의 문자열을 경고나 에러로 출력한다. 경고는 출력창에 메시지만 출력하고 컴파일은 계속 되지만 에러는 메시지 출력 후 컴파일을 즉시 중지한다. 특정한 조건이 되지 않을 때 이를 개발자에게 알리거나 조건이 만족될 때까지 컴파일을 거부할 때 이 전처리문을 사용한다. 예를 들어 라이브러리 버전이 너무 낮다거나 문자 인코딩 방식이 맞지 않을 때 컴파일해 봐야 동작하지 않는다는 것을 분명히 알릴 필요가 있다.

■ #region, #endregion

코드의 블록에 이름을 주고 하나의 단위로 표시한다. 컴파일과는 상관이 없으며 편집기가 이 부분을 잠시 감출수 있도록 영역 지정만 해 놓는다. 자주 편집하지 않는 코드를 이 영역으로 감싸 놓으면 축소해 놓을 수 있다. 다음 그림은 앞에서 만들었던 DllImport 예제의 외부 DLL 정의문을 영역으로 감싸 놓은 것이다.

외부 DLL 정의문은 한 번만 선언하면 더 이상 손 델 필요가 없다. 게다가 선언문이 워낙 복잡해 보기만 해도 정신 사나운데 영역으로 지정해 놓으면 전체가 하나의 단위가 되며 옆에 - 버튼이 나타난다. 이 버튼을 누르면 영역이 축소되어 시원스러우며 눈에 거슬리지 않는다.

축소된 영역은 흐린 색으로 리전의 이름만 보이는데 펼쳐 보고 싶을 때 언제든지 + 버튼을 누르면 된다. 이 전처리문은 사용자가 직접 쓸 수도 있지만 컴파일러가 소스 관리 차원에서 더 많이 사용한다. 보통 사용자가 직접 작성하지 않는 코드를 이런 영역에 배치하여 신경쓰지 않아도 되게끔 한다.

■ #line

파일 이름과 줄 번호를 변경한다. 이 번호는 경고나 에러를 출력할 때 위치를 가리킨다. 일반적인 목적으로는 사용하지 않으며 디거깅이나 로그를 남길 때 가끔 사용한다. #line default는 원래 줄 번호로 돌아간다.

12-3-4.호출자 정보

메서드는 여러 곳에서 반복적으로 호출한다. 정상적인 인수가 전달되면 잘 동작하지만 잘못된 인수를 받으면 오동작한다. 다음 매서드는 월별 매출을 출력하는데 유효한 값은 1 ~ 12까지이며 15나 -8을 전달하면 정상적으로 동작할 수 없다.

static void OutMonthSales(int month) {

Console.WriteLine($"{month}월 매출 보고를 출력합니다.");

}

인수가 잘못되었을 때 누가 나에게 이런 엉뚱한 정보를 전달했는지 조사하여 메시지나 로그에 기록하고 싶다고 하자. C는 이런 용도로 __FILE__, __LINE__ 매크로 상수를 제공하며 좀 구닥다리 같아 보여도 디버그 로그 작성에는 굉장히 유용하다. 하지만 C#에는 대응되는 기능이 없어 아쉬웠다.

C# 5.0에서 똑같은 용도로 쓸 수 있는 애트리뷰트를 추가했다. 호출자 정보를 조사하고 싶은 메서드는 다음 세 개의 인수를 받고 애트리뷰트를 붙인다. 다 받을 필요는 없고 관심있는 정보만 받아도 된다. 원래의 메서드와 호환을 유지하기 위해 선택적 인수로 받아야 한다.

Caller
using System; using System.Runtime.CompilerServices; class CSTest { public static void Main() { OutMonthSales(3); YearReport(); } static void YearReport() { OutMonthSales(15); } static void OutMonthSales(int month, [CallerMemberName] string Caller = "", [CallerFilePath] string Path = "", [CallerLineNumber] int Line = 0 ) { if (month >= 1 && month <= 12) { Console.WriteLine($"{month}월 매출 보고를 출력합니다."); } else { Console.WriteLine("잘못된 요청입니다."); Console.WriteLine($"{Path}의 {Caller}메서드{Line}줄을 점검하십시오."); } } }
실행결과	3월 매출 보고를 출력합니다. 잘못된 요청입니다. C:\DotNetStudy\CSTest\CSTest\Program.cs의 YearReport메서드11줄을 점검하십시오.

컴파일러는 OutMonthSales를 호출할 때마다 세 인수에 호출자 관련 정보를 전달한다. 누가 어디쯤에서 나를 호출했는지 메서드 내부에서 정확히 알 수 있다. 꼭 디버깅 목적이 아니더라도 여러 가지 용도로 활용할 수 있다.