OOJJRS

http://www.ndepend.com/

http://www.jetbrains.com/profiler/

보통 임시 폴더로 알고 있지만 임시 폴더라고 하기엔 사용처나 개념이 약간 다르다. XP 시절에는 별달리 구분이 없이 Application Data 라는 폴더 하나만 있었지만 (부모 경로도 미묘하게 다르다) 비스타 이후 세분화되었다.

Local 과 Roaming 폴더는 윈도우의 제반 환경이 사용 시 서버가 필요한가(AD) 여부에 따라 역할이 구분된다고 한다. 폴더 이름대로, 어느 컴퓨터에서든 내 계정으로 로그인할 경우 이전에 사용했던 환경이 현재 컴퓨터에 내용 일치(동기화)가 필요하면 Roaming 아래에, 그런 게 아니면 Local 에 기록한다는 것이다. 만약 동기화가 필요 없는 커다란 데이터가 불필요하게 Roaming 아래를 사용하면, 그 계정은 아마 로그인할 때마다 많은 시간을 필요로 하게 될 것이다. 그래서 대부분은 사용 로깅이나 환경 설정 같은 기록들을 Roaming 아래에 사용한다고 한다.

LocalLow 는 권한 등급(Integrity Level, 권장 번역 단어가 없음. 이하 IL)이 낮을 때에도 사용할 수 있는 폴더라는 뜻이다. 보안 위협이 큰 익스플로러 같은 브라우저는 IL이 Low로 설정되어 있다. 이런 프로그램도 당연히 임시로 뭔가를 저장하거나 기록할 수 있는 위치가 필요한데, 그때 Local은 사용하지 못하니 LocalLow를 사용하게 된다. 반대로 말하자면 프로그램이 가질 수 있는 권한이 설정에 따라 매우 다양한데, 무조건 뭔가를 기록해야할 필요(로그, 덤프 등)가 있다면 LocalLow에 하면 된다는 뜻.

※ 참고자료

Low IL로 프로그램을 실행하는 방법

msdn 페이지 링크

http://msdn.microsoft.com/en-us/library/windows/desktop/bb762494%28v=vs.85%29.aspx

저 동네 주소가 변경되어도 상관없는 tinylink 주소 같은 건 어떻게 못 하려나 백방으로 찾아도 빡세다.

CLSID 와 비슷해보이지만 전혀 다른 녀석들이다.

원문은 이쪽을 참고하기 바랍니다.

http://tortoisesvn.net/tsvn_1.8_releasenotes.html

메이저 버전이 올라갈 때마다 뭔가 적절한 기능이 추가되었다는 소리이므로 (1.7 버전으로 올라갈 때에는 .svn 폴더가 루트 쪽으로 통합된다는 내용이 가장 마음에 들었다) 이번에도 역시 기대를 갖고 보았다.

(물론 1.8 버전이 나온지는 좀 되었고, 안정화...를 기다린다는 명목으로 1.8.3 에 와서 좀 돌려보았다. 그런데 이번에는 마이너 버전이 1.7 시절에 비해 팍팍팍 올라간 기분.. 그냥 기분 탓)

다음은 개선된 기능의 목록

1. 블레임 UI 에서 각 리비전 별로 컬러가 추가됨

2. 파일 중 일부 내용만 커밋할 수 있음 (나이스!)

3. 거북이 merge 의 기능 향상

리본 UI 의 도입, go to line (항상 왜 없는지 의아했던), 등등

4. 저장소 브라우저 개선

드디어 한 svn 서버가 가진 모든 저장소를 루트로부터 찾아볼 수 있다. (나이스!)

뒤로 가기와 앞으로 가기 (나이스! 좀 더 브라우저스럽게 되었다)

5. Third Party Library 개선

외부에서 제작된 라이브러리를 svn 에 커밋했을 경우, 해당 라이브러리가 버전업이 되면 관리에 약간 부담을 갖게 되는데 대표적으로 파일이 삭제된 경우가 있다. 기존에는 파일의 추가나 변경은 그럭저럭 상관 없었지만 파일의 삭제는 캐치하지 못하고 계속 svn 에 등록된 채로 남아있었는데, 이제 1.8 버전부터는 간단한 마우스 우클릭 메뉴를 통해 그러한 녀석들도 한 방에 정리해줄 수 있게 되었다.

6. Progress Dialog

업데이트 등을 할 때 뜨는 진행 상태 다이얼로그가 좀 더 좋아졌다~

7. SubWCRev.exe 개선 (일종의 매크로 치환 동작을 하는 프로그램이다)

A. UTF-16 인코딩을 예쁘게 지원하게 되었다.

B. 작업소에 리비전을 박아넣을 때, 특히 리비전을 버전 정보로 사용할 때를 위한 새 옵션이 추가되었다. 기존에는 윈도우의 리소스가 16bit를 사용하기 때문에 65535 이상의 리비전 번호를 버전 정보로 사용할 수가 없었는데, 그래서 종전에는 16bit를 넘어가는 리비전 번호는 음수로 표기되는 골 때리는 일이 있었다.

C. SubWCRev 가 이제 등록되지 않은 (작업소 내의) 파일과 폴더 등도 찾아준다. 요 기능을 통해 커밋 때 빠뜨리고 올리지 않은 파일 같은 걸 찾아내서 담당자를 욕할 수 있다 에러를 콱 반환할 수 있다.

8. Custom 속성들

커스텀 속성을 사용하면 거북이svn을 좀 더 편리하게 사용할 수 있단다.

근데 이건 문서도 따로 있을 뿐더러 너무 길어서 해석은 생략 (죄송합니다) > 링크는 여기 <

9. 훅 스크립트를 속성 설정으로도 가능! (우와 씨앙 나이스!!!! 이번엔 네가 베스트)

기존에는 다이얼로그로만 설정이 가능해서 하나의 설정을 여러 컴퓨터에서 써야할 경우 (개인이 여러 플랫폼을 사용할 때 뿐 아니라 특히 대형 프로젝트에서 각자 설정할 때) 별도의 툴을 만들어 쓰거나 서비스 마인드를 함양하거나 포기했어야했는데 이제 속성으로 걸 수 있게 되었다. 이제 막 포맷하고 다시 깔아도 돼

이거 설정하면서 왜 서버에 한방에 설정하는 기능이 없냐고 욕을 바가지로 했었는데 이제 귀차니즘에서 해방된다!!

일단 무조건 버전업하고 보는 거다.

내가 개발 설계에서 항상 고민하는 점은 어떻게 해야 나중에 가서 이 작업이 고민거리로 발전하는 것을 막을 수 있을까 하는 점이다.

쥐뿔도 모르던 옛날부터 눈만 높아진 지금에 이르기까지 나를 개발자로 있게 하는 원동력은 욕망과 귀차니즘이었다.

컴퓨터로 하고 싶은 것들은 여럿 있는데 어찌나 사용하기 불편하고 귀찮은 게 많던지, 꽤나 세월이 흐른 지금도 나는 버튼 하나만 누르면 내가 원하는 기능이 딱 되는 그런 환경을 꿈꾼다.

모르긴 몰라도 수많은 설계 서적들에서 도달하고 싶은 경지는 결국 나와 같지 않을까 하고 상상한다.

하나의 마법과도 같은 단어, 혹은 함수 호출, 키워드, 정의를 통해 프로그램 하나가 턱 하고 튀어나오는 그런 세계.

수많은 개발자들이 일자리를 잃게 될지도 모르지만 어릴 때부터 항상 나는 귀차니즘에 휩싸여 살아왔던 듯 싶다.

다음과 같은 (Pseudo C++) 예제를 보자.

// 1단계 : 1에서 100까지 출력

printf("1\n");

printf("2\n");

...

printf("100\n");

근성을 발휘하여 100라인을 만들어보았다(상상 속에서). 그런데 조금만 공부해도 반복문이란 것을 배운다. 컴퓨터가 좀 더 우리의 삶을 윤택하게 해줄 수 있는, 가장 잘하는 일 아닌가?

// 2단계 : 반복문을 사용하여 1에서 100까지 출력

for(int i = 1; i <= 100; ++i)

printf("%d\n", i);

좀 더 재사용성을 높여서 함수로 만들 수 있을 것 같다.

// 3단계 : 1에서 100까지 출력하는 로직을 함수화

void func()

{

for(int i = 1; i <= 100; ++i)

printf("%d\n", i);

}

자, 이제 우리는 func() 함수만 호출하면 무조건 1에서 100까지 출력할 수 있는 기능을 갖게 되었다.

여기까지는 우리가 보통 어렵지 않게(그리고 순식간에) 도달하는 영역이다.

함수를 배우고 나서 조금 지나면 Parameter/Argument라는 것을 배운다. 갑자기 함수의 활용폭이 넓어진 것 같은 기분을 느끼며 시작값 1과 종료값 100을 외부에서 줘본다.

// 4단계 : Parameter를 통해 함수의 활용폭을 넓힘

void func(int begin, int end)

{

for(int i = begin; i <= end; ++i)

printf("%d\n", i);

}

어이쿠, 갑자기 1과 100이라는 숫자가 보이지 않으니 이 함수가 어떤 값을 처리할 수 있는지 명확하게 보이지 않아 조금 불안해졌다(의미 응집성 하락). 하지만 이 작업 하나로 지금 1에서 50까지 출력해야할 곳에서도, 나중에 927에서 23598까지 출력해야할 곳이 생겨도 모두 처리할 수 있게 되어 행복도가 증가했다(활용도 증가). 이 함수는 이제 뭐든지 다 할 것 같다. 그래서 약 5000군데에서 호출하여 사용했다.

이 단계까지는 연습용 코드 몇 개만 해봐도 그렇게 어렵지 않게 겪어볼 수 있다(5000곳에서 호출하는 정도는 아니겠지만). 그런데 아무래도 여러 곳에서 사용하다보니 점점 함수의 견고함이 증명되어 신뢰도가 올라간다. 따라서 이 함수에 기능을 잘 추가하면, 적어도 기존에 돌아가던 기능은 잘 돌아가고 추가 동작도 매끄럽게 될 것 같아서 다음과 같은 요구사항도 끼워넣게 되었다.

// 5단계 : begin ~ end 사이에서 2단위로 출력

void func(int begin, int end, bool jumpTwoStep)

{

if(jumpTwoStep)

{

for(int i = begin; i <= end; i += 2)

printf("%d\n", i);

}

else

{

for(int i = begin; i <= end; ++i)

printf("%d\n", i);

}

}

아뿔싸, Parameter 하나 추가했다고 5000군데에서 호출하던 곳에서 빌드 에러가 나서 동료/친구/나 스스로에게 욕을 왕창 얻어먹고 나서 5000곳을 변경할 자신은 없으니 황급히 Default-Argument 를 끼워넣는다.

// 5.5단계 : 기존 호출되던 함수와의 호환성 보장

void func(int begin, int end, bool jumpTwoStep = false)

{

if(jumpTwoStep)

{

for(int i = begin; i <= end; i += 2)

printf("%d\n", i);

}

else

{

for(int i = begin; i <= end; ++i)

printf("%d\n", i);

}

}

그런데 내 작업을 우연히 지나가다 본 선배/파트장/팀장/라이벌/리드개발자가 이 함수는 확장성이 없다며 변경할 것을 권고했다. 하지만 아무리 생각해도 나는 단순한 작업 대신 복잡도를 올리고 앞으로 더 쓰일지 확신도 없는 코드를 힘들여 생산해내는 것에 회의적이다. 하지만 그들의 부드러운 말투가 험악한 욕설과 구타로 변하기 직전 뜻을 꺾고 그들의 조언을 받아들였다.

// 6단계 : 확장성을 위해 명료함을 희생함. 또는 복잡도를 높여 미래를 대비함

void func(int begin, int end, int step = 1)

{

for(int i = begin; i <= end; i += step)

printf("%d\n", i);

}

만들어두고 보니 이전 코드가 시작과 종료값만 처리했지, step은 처리해두지 않았다는 설계적 구멍이 있었음을 역설한다. 그리고 그것 때문에 내가 고생했다며 억울함을 역설하면서, 한편으로는 이 견고하고 확장성 있던 함수의 약점을 내가 찾아 보완했다는 것에 기쁨과 자부심을 느끼며 업무를 종료하고 그날의 턴을 마친다(음?).

설계 시에 항상 화두에 오르는 것 중 하나는 명료함 vs 확장성이 아닐까 한다. 이제 와서 다시 1~3단계의 코드를 보고 6단계의 코드와 비교해보자. 애초에 우리는 1에서 100까지 출력하기 위해 작업을 시작했다. 하지만 6단계의 함수로는 대충 무엇을 하는지는 파악했어도 정확하게 어떤 출력값이 나오는지는 저 함수를 호출하는 코드를 포함하여 전체를 다 뒤져보거나, 실행해보기 전에는 알 수 없게 되었다. 데이터(1, 100, 1)와 로직(반복문)이 분리됨으로써 활용도가 높아지고 확장성을 가지게 되었지만, 프로그램의 정확한 동작을 분석하기 위해서는 좀 더 넓은 영역의 코드를 볼 필요가 생겼다는 뜻이다.

만약 나중에 가서 func() 함수의 step 기본값을 1에서 2로 변경해야할 일이 생긴다면, 그 사람에겐 5000군데 이상의 의존성을 지닌 코드를 모두 조사하고 분석해보고 나서야 문제 없이 작업을 완료할 수 있을 것이다. 더 슬픈 사실은 그렇게 시간을 들이고 나서 "이 작업은 진행할 수 없습니다" 라고 이야기할 지도 모른다는 것.

가끔 vs를 사용하다보면 vs의 버그라든지 버그라든지 버그 같은 것을 만나서

신기한 상황에 봉착하곤 하는데 대개는 삽질을 여러 시간 한 뒤에 알아차리게 되므로

굉장히 우울한 경우가 대부분이다.

이번에도 역시 마찬가지로, 특정 파일이 계속 encoding 이 뻑나는 상황이 나오기에

나는 해당 텍스트 파일이 미쳤거나 모종의 파일 BOM 트릭 같은 것에 걸린 줄 알았다.

그러니까, 다음과 같은 상황인데

// Note : 호환 이라는 구문이 잘 보이는가?

하지만 닫았다 열면,

인코딩이 깨진다.

삽질을 한 줄로 요약하여 결론을 내자면,

다음과 같은 새 프로젝트에서도

그냥 호환 << 이라고 주석을 달아버리니 깨진다.

두 글자들이 다 깨지는 것도 아니고, // 호환 이라고 해도 깨진다.

이러다가 깨지지 않는 글자로 인해 인코딩이 정상적으로 먹으면, 그 뒤로는 호환 이라고 써도 깨지지 않는다.

내 진짜 억울해서 팔딱팔딱 뛸 일이다만... (내 30분...)

방심하다가 가끔 당한다.

아키텍처를 현재 조직구조에 맞추도록 한다.

DB가 추가된 이유가 DB팀이 일거리를 찾기 위해서 라는 식은 곤란하다.

25개 이상의 최상위 아키텍처 컴포넌트가 존재하는 건 너무 복잡하다.

한 개의 요구사항이 설계의 전체 방향을 이끌어나간다.

이 요구사항이 없어지면 그 아키텍처는 다른 이슈를 감당하기엔 지나치게 다른 길을 걸어왔다.

하나의 요구사항에 집중하면, 다른 이슈들을 건성으로 다루는 경향이 있기 때문이다.

아키텍처가 운영체제의 특정 버전에 의존적이다.

생각보다 이런 경우가 잦다.

표준 컴포넌트가 사용될 수도 있는 곳에 독점적인 컴포넌트를 사용한다.

하드웨어 단위 구분과 동일하게 컴포넌트를 나눈다.

시스템이 진화하여 하드웨어가 변경되면, 넌 x 된다. 소프트웨어 조직을 하드웨어에 끼워맞추지 말라.

신뢰성 확보라는 명분 하에 필요하지 않은 중복이 있다.

DB 이중화, 2개의 시작 루틴 따위는 시스템을 필요 이상으로 복잡하게 한다.

설계가 예외상황 중심적이다.

핵심 공통성이 아닌 기능의 확장성만을 강조한다.

개발조직에서 시스템 아키텍트를 식별할 수 없다.

아키텍트 또는 프로젝트 관리자가 아키텍처의 이해 관계자를 식별하는데 어려움이 있다.

관계도가 명확하지 않다는 것은 고려 없이 만들었을 가능성이 높다.

개발자가 두 컴포넌트의 상호작용을 코딩하는데 있어서 지나치게 많은 선택권을 갖는다.

아키텍처가 과다하게 선택권을 제공하거나 해당 이슈를 간과하도록 설계됐다면, 아직 아키텍처를 정의하는 중이다.

아키텍트에게 아키텍처 문서 작성을 요청하면, 클래스 다이어그램만 만들고 다른 것은 만들지 않는다(못 한다).

아키텍트에게 아키텍처 문서를 요청하면, 누구도 보지 못한 도구에서 자동으로 생성된 다량의 문서더미를 제시한다.

자동으로 생성이라도 되면 다행이다. 너무 복잡해서 생성하다가 프로그램이 터지는 프로젝트를 나는 알고 있다.

전달된 문서가 예전 내용이라면 당연히 최신 내용으로 관리되지 않고 있다.

설계자 또는 개발자에게 아키텍처를 설명하도록 요청하면, 못 하거나 상이한 아키텍처에 대해서 설명하고 있다.

- 소프트웨어 아키텍처 평가 286p

굵은 글씨는 내 경험 상 깊이 느꼈던 부분들이다.

http://codeka.com/blogs/index.php/2009/03/21/got-visual-studio-2008-professional-want

http://veblush.blogspot.kr/2012/10/map-vs-unorderedmap-for-string-key.html

매우 정리가 잘 되어 있는 글입니다

http://en.wikipedia.org/wiki/Library_(computing)

http://stackoverflow.com/questions/140061/when-to-use-dynamic-vs-static-libraries

http://msdn.microsoft.com/en-us/library/958x11bc.aspx

http://stackoverflow.com/questions/4546507/lib-linking-other-libs

로 출발한 내용들

일단 기본 지식부터

SxS

http://en.wikipedia.org/wiki/Side-by-side_assembly

/MD, /MT 설정들

http://msdn.microsoft.com/en-us/library/2kzt1wy3(v=vs.100).aspx

제기한 주제와는 큰 관련 없지만 그럭저럭 /MD 와 /MT 설정에 대한 토론글

http://stackoverflow.com/questions/757418/should-i-compile-with-md-or-mt

역시 별 관련은 없지만 마침 나처럼 부스트 라이브러리를 빌드하는 사람의 글이 찾아져서

http://stackoverflow.com/questions/9527713/mixing-a-dll-boost-library-with-a-static-runtime-is-a-really-bad-idea

이건... 내 의문과 딱 떨어지는 누군가의 질문

http://social.msdn.microsoft.com/Forums/en-US/vcgeneral/thread/a98b46f1-2d26-45c5-89c5-30714b18596a/

전통적으로 인스톨러를 좋아하지 않는 나는 기본인 /MD 설정보다 /MT 를 즐겨쓴다.

VisualC.PDF

매번 찾기 힘들어서 링크 2

http://msdn.microsoft.com/en-us/library/vstudio/hh567368.aspx

http://msdn.microsoft.com/en-us/library/hh567368.aspx

우씨 근데 정작 찾는 페이지가 없네 어디갔지

매번 찾기 힘들어서 링크

http://msdn.microsoft.com/ko-kr/library/b0084kay(v=vs.100).aspx

프로젝트 규모가 조금 커지면 간혹 만나볼 수 있는 문제다.

주로 프로젝트 관리가 체계적이지 못하거나 잘못되어 발생하는 문제인데, 의외로 원인을 찾는데 시간이 조금 걸린다.

문제의 원인이 여럿이기 때문이지만, 크게 중요한 문제가 아니라서 생각되어 그냥 넘어가기도 한다.

하지만 개인적으로는 이 문제를 매 수행 시 개발자를 번거롭게 할 뿐 아니라 빌드의 정합성을 보장하지 못 하게 하는 문제로 판단한다.

지금까지 경험했던 원인은 다음과 같았는데,

1. 빌드 대상인 파일이 모종의 원인에 의하여 마지막 수정 시간이 현재 시간보다 꽤나 앞으로 설정된 경우

이 경우 obj 파일에 찍힌 timestamp 보다 cpp 파일의 수정 시간이 항상 크기 때문에 항상 빌드를 요청한다.

대개 시간과 얽힌 테스트를 할 때 시스템(OS) 시간을 조정하면서 작업을 하다보면 저도 모르게 발생함.

2. 실제 include 되어 사용하지만 프로젝트에는 포함되지 않은 파일이 있는 경우

대개 헤더파일의 경우가 많이 발생하는데 (유니티 빌드의 경우는 cpp도 발생함) 결국 timestamp 비교가

온전치 못해 발생한다.

또는 프로젝트에는 필터에 포함되어 있으나 실제 파일이 없는 경우도 동일하게 발생한다.

3. lib 파일의 timestamp 가 꼬여서 현재 시간보다 먼 미래로 가버렸을 때

꼬임의 이유야 몇 개 있겠지만 본질적으로 1번과 크게 다르지 않고 소스와는 달리 알아채기 어렵지 않다.

소스는 파일이 매우 많아서 찾기 어려울 수 있지만 lib 파일은 출력폴더의 특정 확장자만 뒤져보면 되기 때문

기억나지는 않지만 아마 몇 가지 사소한 원인이 더 있었다고 기억하는데, 오늘 새로운 원인을 접했다.

이것도 본질적으로는 그냥 프로젝트 관리 실수에다 timestamp 와 연관이 있는 문제여서 다른 원인들과 같은 범주다.

4. 프로젝트들의 PCH 파일명이 동일하여 뒷 프로젝트가 앞 프로젝트 PCH 를 덮어쓴 경우

이 원인을 찾기 위해 헤맸던 이유가, out of date 가 나는 양상이 기존 것들과 약간 차이가 있었기 때문인데,

clean and rebuild(build) => 성공

바로 리빌드 시 => 빌드 실패 (가장 이해하기 힘들었던 부분)

+ 빌드 => 리링킹(?)

+ 빌드 => 변경된 파일이 없으므로 빌드는 하지 않고 최후 lib 파일만 작성(timestamp 갱신)

+ 빌드 => 빌드 성공 (이후로는 빌드하지 않음)

웃기는 건 저 다섯 단계 사이에서 어느 시점에 실행하느냐에 따라 계속 out of date 가 나기도 하고

한 번만 더 빌드하기도 하고 한다는 점이다.

이런 랜덤한 양상을 겪고 나니 그 동안 희석되었던 PCH 에 대한 거부감이 다시 살짝 살아날 뻔했지만...

빌드 환경을 정리해주는 것으로 해결하였다.

http://stackoverflow.com/questions/10604243/call-stack-corruption-in-win32-vs2010-null-dereference-but-not-in-x64

자세한 해석은 귀찮으니 패스

결국 심볼이 잘못 연결된 문제

혹시 잊어먹을까 싶어 남겨둔다

파일, db, 네트워크 어떠한 기반 장치로부터인지에 관계 없이 데이터가 구축될 때 구조를 두 가지로 나눌 수 있을 것 같다.

(편의상 의미를 알아볼 수 있는 정도의 수도Pseudo 코드를 사용하였습니다. 그런 API 없는데요? 라고 하시면 곤란합니다 :-D)

1. 정형화Normalize된 데이터 구조라고 명명함. 혹은 목적형For Objective 스크립트라고 해도 되겠다(내 맘대로 명명했다).

이러한 데이터들은 코드에서 직접적인 행위를 통해 접근이 가능한 집단이다. 완전히 일반적인 언어를 만들고 있지 않는 한 데이터의 가공 및 처리 편의성을 위해 명확한 목적을 지닌 하드코딩 연결부가 존재하는데,

<server ip="192.168.0.1" port="15000" />

----------------------------------------------------------------

if(!LIB_NET::connect(xml["server"]["ip"], xml["server"]["port"]))

{

    cout << "접속 실패" << endl;

    return 1;

}

와 같은 예가 정형화된 데이터를 사용한 예다. 코드는 명확하게 xml 로 server 가 존재함(예외 처리가 추가될 수 있다고 하더라도)을 알고 있으며 "server" 라는 토큰은 명확히 어딘가로의 접속을 위해 사용되는 매개체가 된다. 조금 더 시간을 투자한다면 복잡한 일반화를 통해 코드에서 server 를 직접적으로 활용하여 connect 를 호출하지 않고 스크립트에 코드를 두며 해당 parser 를 제작하는 식으로 처리할 수도 있지만, 웬만큼 크지 않은 프로젝트 대부분에서 이는 낭비에 속할 것 같다.

정형화된 데이터는 개발자 입장에서 읽고 쓸 때 명쾌하며 빠른 개발 속도도 보장한다.

빠른 대신 독립성의 이점은 별로 없다. 개발자가 모두 관리한다고 가정했을 때 이런 어중간한 데이터의 분리보다는 차라리 코드로 한 몸에 있는 것이 훨씬 낫다.

즉, 장단점을 하나로 정리하자면,

독립성, 관리비용 : 동적 데이터 구조 > 목적형 구조 > 코드

위와 같은 어중간한 방법이 가장 좋은 효율을 내는 경우가 아이템 1,000개를 만들 때 제작자와 개발자가 다른 경우다. 이때 목적형 스크립트는 서로 간에 의사소통 비용을 적절히 조율할 수 있고 요구사항/제공사항을 명확하게 나열할 수 있어 데이터의 1차 관리로 많이 활용되는 것으로 보인다.

<name>    아이템 이름

<stat>      아이템을 착용했을 때 증가하는 스탯 정의부

<desc>    아이템 설명

와 같은 명세서가 있다고 할 때 제3작업자인 스크립터는 쉽고 빠르게 단순반복 작업이 가능하다.

그러나 이 방식의 치명적인 단점이 있는데, 재활용하는 스크립트의 수가 적은 곳에 사용되면 1회용 코드가 난무하게 된다는 것이다. 위의 connect 에 사용된 server 정보와 같은 예다.

2. 동적Dynamic 데이터 구조

위의 구조를 좀 더 발전시켰다, 라는 개념보다 반대의 구조를 찾는다고 하면 동적 데이터 구조다. 목적형 구조는 하드코딩을 발전시킨 개념으로 보이지 하드코딩과 반대 개념이라고 보여지진 않는다.

동적 데이터 구조는 말 그대로 언어의 처리 방식과 비슷하다. 데이터가 얼마나 들어올 지, 무슨 데이터가 들어올 지 정해져 있지 않기 때문에 정형화된 모양으로 읽어들일 수가 없다.

<color name="black" r=0 g=0 b=0 />

<color name="blue" r=0 g=0 b=255 />

<color name="yellow" r=0 g=255 b=255 />

위와 같은 데이터는 얼마나 중복으로 들어올 지 알 수 없다. 동적 데이터를 처리하는 구조가 더욱 복잡해지는 이유는, 무엇이 들어올 지도 잘 모르지만 "얼마나 중복이 생길 지"도 잘 모른다는 사실이 더욱 구조를 복잡하게 만든다. 단순히 위의 예를 처리하려고 해도 정형화된 아이템 구조에서는 필드 하나로 끝날 스크립트가 리스트 구조 등을 요구하게 된다.

동적 데이터 구조는 코드에서 명확하게 그 대상을 지칭할 수 없다는 문제를 항상 염두에 두어야할 것 같다. 그렇게 만들려고 한다면 못 할 것은 없겠지만, 스크립트로 만든 데이터들을 코드에서 임의대로 지칭하려면 고려해야할 것들이 꽤 많다. 생성 영역과 관리 영역domain 이 다르기 때문이다. 반면, 스크립트에서 만들었다면 스크립트에서 해당 구조를 지칭하는 것은 그리 어렵지 않다.

<text color="yellow">안녕하세요?</text>

만약 yellow 가 하나 더 추가되어 2개가 되었을 경우 이를 코드 영역에서 지칭하려면 수정 후 리빌드 과정이 필요하지만, 같은 스크립트 레이어에서 이를 지칭하기 위해선 그냥 식별자identifier 만 수정하면 된다. 이는 코드에서 만든 것을 스크립트에서 지칭하기 어려운 이유와도 일맥상통하는데, 결국 관리자가 다르다는 것이 이유인 것 같다.

그래도 사용을 하려고 들면 못 하진 않는다. 다만 다음과 같은 일이 생기면 껄끄러운 것은 나 뿐인가?

while( xml["color"].IsValid() )

colormap[xml["color"]["name"]] = RGB( xml["color"]["r"], xml["color"]["g"], xml["color"]["b"] );

------------------------------------------------------------------------------------------------

DrawLine(10, 10, 100, 100, colormap["black"]);

동적 스크립트로부터 얻은 데이터로부터 특정 키 값을 주어 라인을 그릴 때 색상 값을 취하고 있다. 아마 이 스크립트에는 다음과 같은 주석이 항상 따라다닐지도 모르겠다.

<color name="black" r=0 g=0 b=0 /> <!-- 코드에서 사용하고 있으니 변경 시에 개발자에게 문의하세요 -->

저런 경우가 많아지면 설계 상으로 꽤 곤란할 것 같은데, 나만 그렇게 느끼는 건지도 모르겠다.

위의 두 가지를 모두 지원하려니, 라이브러리가 DOM 형식과 반복자 형식을 항상 같이 지원해야 한다.

작금의 많은 XML 라이브러리들을 위시하여 스크립트 파서나 데이터 관리자 클래스들이 두 가지 모양을 모두 지원하는 이유에 대해 짧게 고찰해보았다.

DOM 형식이 코드도 보기 예뻐서 좋은데, 여러 모로 참 귀찮다. 으아아아아아!!!!!!!

결론은 한탄 뻘글

세 가지는 모두 비슷한 개념으로 여겨진다. 역할은 모두 인터페이스 교정에 사용되므로 공통점이 많은 이 세 가지 기법의 주요 차이점을 알아본다.

개인적으로 브릿지에 대한 오해가 약간 있었다.

Wrapper

Decorator 패턴의 주요 기법. 어떤 Component 의 기능을 그대로 놔두고 그 위에 기능을 얹는다(단순히 어댑터의 역할만 할 수도 있다).

어떤 Component 의 Wrapper Class 는 대상 Component 에 당연히 의존성Dependency이 강하다. 즉, Wrapper Class 만 따로 배포할 수는 없다는 뜻.

Bridge

Bridge 패턴으로도 사용됨. BUS, 공통 언어 같은 개념으로 보아도 무방할 듯. 대개의 경우 어댑터 역할을 할 때 설계 문서상으로는 암묵적으로 생략되는 경우가 많다고 함. 이는 임시적인 속성을 지니는 브릿지의 특성 상 그럴 듯하지만 구현과 설계의 괴리를 높이는 요소로 지적될 수 있을 듯.

Mediator

중재자 패턴은 링크 생략. 래퍼와 브릿지의 속성을 모두 지니고 있으며 두 패턴의 끝판왕 같은 기분으로 등장했다. 임시적인 녀석이 아니라 설계 단계에서도 명확하게 표현되는 특징적인 방식. 말하자면 서로 다른 라이브러리를 소통하게 하고 활용하고 꾸미기 위해 필수로 필요할 경우 해당 기능(래핑, 브릿지)을 모조리 모아 패키지로 구성했다고 생각할 수 있다.

게임의 비즈니스 로직에서 만약 중재자를 사용해야 한다면 엄청나게 슬픈 일이 될 것 같다. 엔진과 라이브러리 등의 밑단으로 잘 내려보자.