[C++] 플러그인 구조로 프로그램 확장하기 (예제 포함)

본문의 내용은 Mike Dickheiser 저자의 C++ For Game Programmers (Game Development Series) 2nd Edition의 내용을 참고하여 작성했습니다.

소개

플러그인(plugin)에 대해서 들어보셨나요? Wikipedia에서는 아래와 같이 플러그인을 정의하고 있습니다.

링크: ko.wikipedia.org/wiki/%ED%94%8C%EB%9F%AC%EA%B7%B8%EC%9D%B8

플러그인(plugin) 또는 추가 기능(애드인;add-in, 애드온;add-on)은 호스트 응용 프로그램과 서로 응답하는 컴퓨터 프로그램이며, 특정한 "주문식" 기능을 제공한다. 응용 프로그램이 플러그인을 제공하는 까닭은 많다. 이를테면, 서드파티 개발자들이 응용 프로그램을 확장하는 기능을 만들게 하거나, 뜻밖의 기능을 지원하거나 응용 프로그램의 크기를 줄이거나, 호환되지 않는 소프트웨어 라이선스 문제로 인해 소스 코드를 응용 프로그램에서 분리하는 것을 들 수 있다.

전문적인 프로그램을 다루는 분이라면 플러그인을 많이 다뤄 봤으리라 생각합니다. 특히 Visual Studio의 확장 도구를 사용해봤다면 단 번에 이해가 되실 겁니다. 또는 최근에 소개한 이미지 처리 프로그램인 ImageJ의 플러그인도 같은 맥락입니다.

[유틸리티] 이미지 처리에 필수인 ImageJ 살펴보기!

[유틸리티] 이미지 처리에 필수인 ImageJ 살펴보기!

이번 포스팅에서는 플러그인의 개념과 플러그인을 사용하도록 프로그램을 설계하는 방법에 대해 소개합니다.

플러그인의 필요성

보통 프로그램을 사용하다 보면 특정 기능이 제공되지 않아 아쉬울 때가 있습니다. 그런데 이런 생각을 하는 사용자들이 꽤 많을 것입니다. 개발자들이 그런 기능들을 미리 예상하긴 힘들지만, 만약 그런 기능들을 프로그램 안에 모두 넣으면 어떻게 될까요? 프로그램에 수천 가지의 다른 기능들로 인해 유지 불가능한 프로그램으로 퇴보하고, 크기와 기능은 불필요하게 거대해질 것입니다. 그리고는 아무도 사용하고 싶어 하지 않은 블로트 웨어(Bloatware)가 되겠죠.

이러한 문제에서 훨씬 더 유연한 접근 방식은 플러그인을 사용하는 것입니다. 프로그램에는 대부분의 사용자가 원하는 핵심 기능만 제공하고, 나머지 기능은 플러그인이라는 확장을 통해 제공할 수 있습니다. 그리고 사용자는 원하는 플러그인만 로드하여 사용할 수 있습니다.

또한, 프로그램 이러한 방식으로 확장하고, 몇 가지 API를 제공함으로써 사용자 또는 다른 회사가 원하는 기능을 탑재할 수 있도록 자체 플러그인을 만들 수도 있습니다.

다른 프로그램을 위한 플러그인

디자인 팀에서 디자이너들이 선호하는 모델링 프로그램 최신 버전을 새로 구매했다는 예시를 들어보겠습니다. 처음부터 검토하고 구매했으면 좋겠지만, 프로그램 설치 후 이런 기능 저런 기능을 살펴봅니다. 그런데 정말로 필요로 하는 기능이 없다는 것을 깨달았을 때에는 이미 늦었습니다. 이 경우 어떤 대안이 있을까요?

첫 번째는 원하는 기능을 모두 갖춘 다른 프로그램을 사용하는 것입니다. 하지만 그런 프로그램을 찾기란 힘들 것입니다. 두 번째는 여러 프로그램을 같이 사용하는 것입니다. 이 경우에는 비용도 문제이고 프로그램 간에 상호 호환성이 문제일 것입니다. 세 번째는 디자이너를 위한 자체 프로그램을 개발하는 것입니다. 하지만 이러한 상용 프로그램은 수 백명의 팀이 만든 프로그램을 대체할 순 없을 것입니다.

마지막 방법은 기존 프로그램을 확장하는 것입니다. 물론, 확장 가능한 구조로 설계되어 있어야 가능합니다. 하지만 이러한 프로그램은 대부분 그렇게 설계되어 있기 때문에, 적은 비용으로 구현이 가능합니다.

우리 프로그램을 위한 플러그인

우리가 개발할 프로그램에 굳이 플러그인을 추가하려는 이유가 무엇일까요? 소스 코드가 있기 때문에 언제든지 프로그램을 수정하고, 다시 컴파일한 후 새로운 기능으로 릴리스할 수 있습니다.

간단하게 답변하자면, 프로그램을 확장하기가 더 쉽다는 것입니다.

한 번 플러그인 아키텍처가 구축되면, 프로그램 자체에 기본 기능을 추가하는 것보다 새로운 플러그인을 작성하는 것이 더 쉽습니다. 플러그인 사용의 또 다른 장점은, 프로그램이 플러그인의 내용으로부터 완전히 절연된다는 것입니다. 프로그램의 기본 기능뿐만 아니라 원하면 기능을 추가하여 사용할 수 있다는 의미입니다. 마지막 장점은 커뮤니티에서 사용자들에 의해 자발적으로 플러그인이 확산되어 프로그램의 인지도가 증가할 수 있습니다.

플러그인 아키텍처

본문에서 다룰 예제 코드는 사칙 연산을 하는 플러그인을 추가하여, 두 개의 숫자를 연산하는 동작을 수행합니다. 예제 코드는 본문 하단에 첨부되어 있으며, 여기서부터는 플러그인 아키텍처를 설정하는 방법에 대해 설명하겠습니다.

IPlugin Interface

전반적인 플러그인 아키텍처는 플러그인을 위한 추상 인터페이스를 중심으로 이루어집니다. 추상 인터페이스에는 프로그램에서 플러그인을 조작하는 데 사용하는 모든 기능이 포함되어 있습니다. 인터페이스는 플러그인과 상호 작용하는데 필요한 최소 함수 집합만 선언합니다.

class IPlugin 
{
public:
	virtual ~IPlugin() {};
	
	virtual bool Initialize() = 0;
	virtual bool Shutdown() = 0;
	virtual void About(HWND hParent) = 0;
	virtual double Execute(double a, double b) = 0;
	virtual const std::string GetName() = 0;
};

프로그램이 플러그인과 상호 작용하는 방법은 About() 함수를 호출하는 것입니다. About() 함수는 플러그인의 이름, 빌드 날짜 및 버전 정보 등이 표시됩니다. 이러한 기능은 플러그인을 처리할 때 매우 유용합니다. 현재 로드된 플러그인을 확인할 수 있을 뿐만 아니라, 플러그인이 올바른 버전인지 확인할 수 있습니다. 플러그인은 메인 프로그램과 서로 독립적으로 복사 및 업데이트할 수 있기 때문에 프로그램 내에서 버전을 확인할 수 있어, 사용자의 골칫거리를 많이 줄일 수 있습니다.

이 예에서는 모든 초기화는 생성자에서, 모든 종료는 소멸자에서 이루어져야 하므로 별도의 생성자 및 소멸자 함수는 없습니다. 객체가 성공적으로 생성됐지만 초기화되지 못하는 경우가 있기 때문에, 초기화 및 종료를 처리하는데 선호되는 방법입니다. 반면에 초기화가 실패할 수 있는 경우(예, 파일 접근 또는 메모리 할당), 생성자의 오류를 표시하기 위해 예외 처리가 필요합니다.

사칙연산 플러그인 구현

IPlugin을 상속받는 덧셈 플러그인의 구현은 다음과 같습니다.

class PluginAdd : public IPlugin
{
public:
	PluginAdd(PluginManager &mgr);
    
	virtual bool Initialize();
	virtual bool Shutdown();
	virtual void About(HWND hParent);
	virtual double Execute(double a, double b);
	virtual const std::string GetName();

private:
	PluginManager &m_hManager;
	std::string m_strName;
};

뺄셈 플러그인의 구현도 볼까요?

class PluginSub : public IPlugin
{
public:
	PluginSub(PluginManager &mgr);

	virtual bool Initialize();
	virtual bool Shutdown();
	virtual void About(HWND hParent);
	virtual double Execute(double a, double b);
	virtual const std::string GetName();

private:
	PluginManager &m_hManager;
	std::string m_strName;
};

IPlugin으로부터 상속받는 새로운 클래스를 만들고 다시 구현하는 작업은 거의 동일합니다.

다양한 유형의 플러그인 다루기

본문의 예제와 별개로, 데이터를 내보내는 플러그인을 작성한다고 가정하겠습니다. 여러 유형의 플러그인을 구성하는 가장 좋은 방법은 상속(Inheritance)을 이용하는 것입니다.

class IPlugin
{
	public:
		virtual ~IPlugin () {};
		virtual const std::string & GatName() = 0;
		virtual const VersionInfo & GetVersion() = 0;
		virtual void About() = 0;
};

각 플러그인 유형에 대해 IPlugin에서 파생된 클래스를 새로 생성하여, 해당 플러그인 유형에 대한 새로운 기능을 추가합니다.

class IPluginExporter : public IPlugin
{
	public:
		virtual ~IPluginExporter () {};
		virtual bool Export (Data * pRoot) = 0;
};

class IPluginImporter : public IPlugin
{
	public:
		virtual ~IPluginImporter () {};
		virtual bool Import (Data * pRoot) = 0;
};

class IPluginDataViewer : public IPlugin
{
	public:
		virtual ~IPluginDataViewer () {};
		virtual bool Preprocess (Data * pData) = 0;
		virtual bool View (Data * pData, HWND hwnd) = 0;
};

특정 플러그인을 생성하려면 이러한 특수 유형의 플러그인 중 하나에서 상속해야 합니다. 그런 다음 일반적인 IPlugin 함수와 해당 유형의 플러그인에 해당하는 함수 모두 구현하면 됩니다.

위 코드 예시는 아래와 같이 표현할 수 있습니다.

다양한 유형의 플러그인 구조 예시

플러그인 로드하기

지금까지 플러그인과 인터페이스 및 구현에 대해 설명했지만, 플러그인이 어떻게 작동하는지, 즉 런타임(Runtime)에 어떻게 로드되는지에 대해 언급하지 않았습니다. 플러그인이 런타임에 로드되기 위해서는 플러그인은 플러그인을 사용하는 프로그램의 일부가 될 수 없습니다. 그렇지 않으면, 프로그램이 컴파일되는 즉시 새 플러그인을 추가할 수 없습니다.
대신 개별적으로 컴파일한 다음 즉시 로드해야 합니다.

이해가 되셨나요? 설명이 부족해 보이는데요. 플러그인은 메인 프로그램과 별개로 불러오는 것이기 때문에, 메인 프로그램과 절연되어 있습니다. 따라서 개별적으로 컴파일한다는 것이고, 따로 로드해야 하는 것이죠.

프로그램 실행 중 플러그인을 로드하는 가장 간단한 방법은 DLL(Dynamic Link Libraries)을 사용하는 것입니다. DLL을 사용하면 런타임 중에 라이브러리 내의 코드와의 연결을 연기할 수 있습니다. DLL을 명시적으로 로드할 때만 프로그램의 나머지 부분에 사용할 수 있는 코드가 생성되는 것이죠.

DLL을 만들려면 Visual Studio에서 동적 라이브러리(DLL) 생성을 위한 프로젝트를 준비해야 합니다. 이렇게 하면 생성된 파일이 실행 파일(.exe)이나 정적 라이브러리(.lib)가 아닌 동적 라이브러리(.dll)가 됩니다. DLL을 생성한 후에는 Export 할 function을 결정해야 합니다. 다른 유형의 라이브러리와 달리 DLL에서는 라이브러리 외부에서 사용할 수 있도록 하려는 함수, 클래스 또는 변수에 명시적으로 플래그를 표시해야 합니다. 플러그인 클래스 자체를 Export 하는 대신, 실제 플러그인 객체 생성을 담당하는 전역 팩토리 함수를 Export 할 것입니다. 정의는 다음과 같습니다.

#ifdef PLUGIN_EXPORTS
#define PLUGINDECL __declspec(dllexport)
#else
#define PLUGINDECL __declspec(dllimport)
#endif

extern "C" PLUGINDECL IPlugin * CreatePlugin (PluginManager & mgr);

C++를 사용하여 DLL에서 함수를 내보내는 방법은 함수 선언 전에 키워드 _declspee(dllexport)를 추가하는 것입니다. 이 키워드는 PLUGINDECL로 정의됩니다. 보통 DLL을 생성하는 코드를 보면 위와 같이 정의되어 있는 것을 볼 수 있습니다. 이는 하나의 헤더 파일로 Export와 Import를 하기 위해 이렇게 사용됩니다. 그리고 이를 결정짓는 것은 프로젝트의 전처리기에 PLUGIN_EXPORTS가 정의되어 있는지입니다. 정의되어 있으면 Export로 동작할 것이고, 정의되어 있지 않으면 Import로 동작할 것입니다.

팩토리 함수의 선언에서 extern "C"를 사용했는데요. 이 키워드는 컴파일러에게 함수 이름을 일반적인 C++ 방식으로 장식하지 않도록 합니다. C 함수인 것처럼 꾸미지 않은 채로 두기 위함이죠. 그 결과, 컴파일러에 의해 맹글링 된(Mangled) 이름이 아닌 일반 이름을 사용하여 나중에 그 함수를 찾을 수 있습니다.

주의

 

 

C++에서는 컴파일러에 따라 각각의 규칙으로 함수 이름을 변경하는데, 이를 네임 맹글링(Name Mangling)이라고 합니다. extern "C"를 선언하면 함수의 이름을 맹글링 하지 않는다는 의미입니다.

사칙연산 플러그인을 예시로, 팩토리 함수에 대한 구현은 다음과 같습니다.

PLUGINDECL IPlugin *CreatePlugin(PluginManager &mgr)
{
	return new PluginAdd(mgr);
}

뺄셈의 경우에는 다음과 같습니다. 아주 간단하죠?

PLUGINDECL IPlugin *CreatePlugin(PluginManager &mgr)
{
	return new PluginSub(mgr);
}

여기까지, DLL을 플러그인으로 사용할 준비가 되었습니다. 다양한 유형의 플러그인이 있는 프로그램에서 자주 사용하는 편리한 방법 중 하나는 파일 이름을 바꾸는 것입니다. 일반 .dll 확장자를 사용하는 대신, 현재 플러그인 유형을 반영하는 확장자로 변경되는 경우가 많습니다. 예를 들어, 내보내기로 .exp 확장자, 가져오기로 .imp 확장자를 제공할 수 있습니다. 다양한 플러그인이 있기 때문에, 이 작은 트릭은 플러그인을 관리할 때 매우 편리합니다.

플러그인 매니저

지금까지 플러그인이 어떻게 만들어지는지에 대해 자세히 설명했지만, 플러그인이 실제로 어떻게 사용되는지는 다루지 않았습니다. 그리고 프로그램이 플러그인을 로드하고 사용할 것이라고만 설명했는데요. 이러한 작업은 플러그인 매니저의 역할입니다.

플러그인을 사용하는 각 프로그램에 대해 수행해야 하는 설계 결정은 플러그인이 정확히 불러와지는 시점입니다. 프로그램을 시작하는 즉시 로드되거나 사용자가 로드하기로 결정하거나 사용자가 선택한 개별 플러그인만 로드할 수 있습니다. 대부분의 프로그램은 프로그램이 시작될 때마다 모든 플러그인을 로드하려고 시도합니다. 이를 변경하는 것은 다른 시간에 올바른 플러그인 매니저 함수를 호출하기만 하면 됩니다.

본문의 예제에서는 프로그램이 실행되는 즉시 플러그인 매니저가 사용 가능한 플러그인을 로드하려고 시도합니다. 특정 경로에서 검색되며, 처리 중인 플러그인 유형과 일치하는 확장명을 가진 모든 파일을 찾습니다. 이 경로는 일반적으로 실행 파일과 관련이 있으며, 사용자가 직접 플러그인을 추가하거나 삭제할 수 있습니다. 샘플 코드에는 실행 파일의 경로에서 플러그인 파일을 추가, 삭제할 수 있습니다.

플러그인을 로드하기 위한 첫 단계는 DLL을 로드하는 것입니다.

HMODULE hDll = ::LoadLibrary(filename.c_str());

LoadLibrary 함수는 파일 이름에 따라 dll을 로드합니다. DLL을 해제하기 위해 나중에 사용될 핸들을 반환하거나, DLL을 로드하는 동안 오류가 발생한 경우 NULL을 반환합니다. 일부 다른 임의 파일의 확장자가 찾고 있는 플러그인과 같거나 파일이 손상될 수 있으므로 모든 단계에서 결과가 성공적이었는지 확인해야 합니다.

두 번째 단계는 DLL이 올바르게 로드되었다고 가정하고, Export 한 팩토리 함수를 찾아야 합니다.

CREATEPLUGIN pFunc = (CREATEPLUGIN)::GetProcAddress(hDLL, _T("CreatePlugin"));

GetProcAddress 함수는 특정 DLL에서 Export 한 함수 목록에서 특정 함수를 찾습니다. 함수를 찾으면, GetProcAddress는 해당 함수에 대한 포인터를 반환합니다. 그렇지 않으면 NULL을 반환하고, 이는 DLL에 함수가 없다는 것을 의미합니다.

이렇게 얻어진 함수 포인터에 플러그인 매니저에 대한 *this 파라미터를 전달하여, 해당 플러그인에 대한 포인터를 유지할 수 있습니다. 코드는 아래와 같습니다.

IPlugin *pPlugin = pFunc(*this);

플러그인 로드(Load) 및 언로드(Unload)

런타임 중 플러그인을 로드 및 언로드 하는 기능도 필요합니다. 최소한 프로그램이 종료될 때 모든 플러그인을 언로드 하여 모든 메모리가 올바르게 해제되도록 해야 합니다. 플러그인을 해제하려면 플러그인 목록에서 플러그인을 제거하고, 실제 개체를 삭제한 다음, FreeLibrary를 호출하여 해당 DLL을 언로드 하기만 하면 됩니다. DLL을 언로드 하는 함수는 LoadLibrary가 반환한 DLL 핸들을 매개변수로 사용하기 때문에, 해당 핸들을 플러그인 포인터 자체와 함께 유지해야 합니다.

또는, 프로그램 자체를 종료하지 않고 모든 플러그인(또는 특정 플러그인만)을 다시 로드할 수 있어야 합니다. 메인 프로그램과 데이터 세트를 로드하는데 시간이 걸리는 경우, 반복해서 플러그인을 테스트할 때 시간이 오래 걸릴 수 있습니다. 또한, 프로그램이 시작되어 LoadLibrary 함수를 통해 DLL이 로드되면 해당 파일이 운영체제에 의해 잠기므로, 새 버전의 플러그인으로 테스트가 불가합니다. 이런 경우에는 플러그인을 언로드 하고 DLL을 업데이트한 후 다시 로드해야 합니다. 따라서, 로드 및 언로드를 개별적으로 호출이 가능하도록 구현해야 합니다.

결론

본문의 내용이 꽤 길었습니다. 본문의 내용만 보면 '그래서 플러그인이 마냥 좋은가?'라는 의문이 남는데요. 대답은 '아니다'입니다. 분명 플러그인을 사용한 단점도 있을 것입니다. 하지만 이런 기법이 있고, 원본 소스 코드를 수정하지 않고도 프로그램을 확장할 수 있는 장점이 있다는 것입니다. 굳이 메인 프로그램에 온갖 기능을 다 구현하면서 다시 컴파일할 필요가 없다는 의미이죠.

플러그인 사용을 제공하기 위한 프로그램을 설계하는 방법, 다양한 플러그인을 구성하는 방법, 관리 방법, Windows 플랫폼에 로드하는 방법을 기억한다면 언젠가 큰 도움이 될 거라 생각합니다.

ExamPlugin.zip

0.14MB