* KGDC2002 [경직된
회사에서 게임 개발하기] - 김웅남 님깨서 작성한 글입니다. 1.3.5.10
에서 퍼왔습니다.
1. 들어가는 말
한국에서 게임을 개발한다는 것은 굉장히 힘든
일이다.
초창기에는 너무나도 시장이 작고 영세 하다는 점이 개발자들을 괴롭혔고, 지금은 짧은 역사에 비해 개발 규모가 너무나도 급속히
증가했다는 점이 우리를 힘들게 하고 있다. 특히 온라인 게임 시장 규모가 갑자기 커지고 벤처 열풍이 불면서 이른바 대박 신화에 이끌린 수많은
투자자들이 “게임개발”에 뛰어든 지난2000년 이후 한국에는 <경직된 회사>들이 우후죽순처럼 생겨나기 시작하였다.
대기업
출신의 마케터, MBA 자격을 가진 경영자 등 몇 년전만해도 꿈도 꿀 수 없었던 유능한 인력들이 대거 게임 개발에 뛰어들었음에도 불구하고 게임
개발의 현장은 더 힘들고 괴롭기만 한 이유는 어디에 있을까? 그리고 필연적으로 경직된 회사에서 게임을 개발할 수밖에 없는우리 개발자들은 어떤
자세로 게임을 제작해야 할까?
필자는 지난 6년간 수많은 경직된 회사들을 전전해 온 경험을 살려 이 문제를 한번 진지하게 검토해
보려고 한다.
2. 경직된 회사의 정의
사실 “경직된 회사”라는 용어는 굉장히
애매모호한 말이다. 필자가 그냥 만들어낸말이기 때문에 더 그럴 것이다. 여하튼 필자는 게임 개발이라는 창조적인 작업의 성격이나 정체를 제대로
이해하지 못하면서 어설프게 게임을 제작하고 있는 모든 개발사들을 가리켜 이 용어를 사용하려고 한다.
1. 경직된 회사의 대표적인
유형 2가지
1) 소규모의유연한 회사로 출발했다가 규모가 급속히 커지면서 경직화한 경우
게임이 좋다는 열정 하나로 시작한
회사였으나, 규모가 급속히 커지면서 이를 감당하지 못하고 경직화한 회사들을 가리킨다.
2) 창업초기부터 경직화한
회사
나름대로 자신있는 창업 아이템을 가지고 시작했으며, 따라서 창업초부터 상당한 투자를 받은 회사이다. 하지만 회사의 주역들이 게임
개발에 무지하며, 이 때문에 필연적 으로 경직화할 수밖에 없는 운명에 놓여있다.
2. 경직된 회사의 공통적 특징
필자가 경험해 본결과, 경직된 회사는 대개 몇가지 공통점을 가지고 있다. 이를 정리해 보면다음과 같다.
1) 회사의
리더급 멤버들이 게임 자체또는게임 개발에대해 무지하다.
게임 개발에 무지하다는것에는 2가지 유형이 있는데, 하나는 아예
무지한것이고 또 하나는 어설프게 아는 것이다.
후자의 경우 보통 다음의 과정을 통해 지식을 습득하는게 대부분인데, 대개 이렇게
얻은 지식을 통해 “게임 개발을 다 이해했다”고 생각하고는 직접 개발을 컨트롤하려는 유혹에 빠지기십상이다.
● 신문이나 잡지
기사를 읽고 대략짐작(피상적으로 이해)
● 자신이게임을 해 보기보다는 남의경험에 전적으로 의존함(이야기를 듣거나 플레이하는 것을 건너다
보는 정도)
● 이렇게얻어들은 지식과, 자신이 타 분야에서 얻은 경험을 적당히섞어서 자신만의 게임관을 만들어 냄. 그리고 이에 대해확고한
믿음을 가짐.
피상적인 이해에 머무르는 경영자 또는 마케터와 일하기 어려운 이유는 경험의 차이가 서로의 의사소통을 방해한다는
점에있다. 이 점은 준비 없는 개발자로서는 넘기 힘든벽이다.
2) 번거롭고 비효율적인 조직 구성
비효율적인조직에는
다음과 같은 두 가지 유형이 있다.
● 처음부터 대기업의 조직 체계를 기계적으로 답습한 경우
● 처음에는 소규모
게임개발사로 시작했다가 규모가 커지면서 대기업의 체계적인 조직 시스템을 도입한 경우 (역시 기계적으로 도입한경우임)
회사규모가
커지게 되면 체계적인 관리의 필요성이높아지는 것은 당연하다.
많은 회사들이 이 시점에 이르게 되면 대기업 출신의 중견 관리자를영입하여 회사
조직 시스템을 재정비하는데, 이들관리자들 중에는 자신이 몸담았던 대기업의관리 시스템을 기계적으로 적용시키려는 사람들이 있기 마련이다. (삼성
출신은 삼성의 시스템을, LG 출신은 LG 시스템을 모델로 한다. )
이 때문에 학력과 경력 등을 근거로 무려 수십등급의 직급체계를
적용하는 무리수가 나오기도 한다. 여기에서 관리자와 개발자의 충돌이시작되며 결과적으로 회사에 좋지않은 영향을 끼치게 되는 것이다. (서로에 대한
불신이 쌓이므로)
3) 현실 감각은 없고 이상만 있는 대표이사
● 잭윌치 환상
필자가 만나 본
대표이사들 중, 책상위에 “잭윌치” 관련 책이없는 사람이 거의 없었다.
문제는 잭윌치가 달성한 업적만 보고 있다는 것이다.
이상은 높아야 하지만 발은 땅(현실)에 붙이고 있어야 하는 법이다.
이들은 잭윌치의 의자만을 보고 있을뿐(회장자리) 게임
개발이라는 현장을 제대로보고 있지 못하고 있는 듯하다.
● 개발 현장에서 완전고립된 대표이사실
필자가 방문한 어떤
회사의 경우, 단몇 시간만에 필자는 그쪽 회사의 중요 개발 파트에 커다란 구멍이 나 있는 것을 발견한 적이 있다.
하지만 그
회사의 대표이사와 이야기해 본 결과 그 사실을 전혀 모르고 있었다. 대표이사실과 개발실을 멀리 떨어뜨려 놓음으로써 개발자에게 부담을 주지
않겠다는 의도는 좋지만 그렇다고 눈과 귀를 막고 있으면 곤란하다.
(경영자와 개발자 간에 정보가 소통되지 않는다는 점이 회사를
경직화시키는 가장 중요한 원인 중 하나이다.)
● 문턱을 낮춘다는 말만있고, 실제로는 전혀문턱이 낮지않음
“사장실
문은 항상열려 있으니 문제점이 있으면 언제나 찾아오도록”.
대표이사는 이렇게 말하지만 실상 문제점을 말하는 직원은 하나도
없다.
개방된 분위기는 대표이사의 말 한마디로 생겨나는 것이 아니라.
그러한 문화 또는 풍토가 형성되어야만 가능한 것이다.
이를 깨닫지 못하고 “나는 항상 사장실 문을 열어 놓고 있다.
따라서 우리회사는 상당히 개방적인 회사이다”라고 흡족해 하는
사장이 있는가하면,
남이 보지 않는곳에 모이기만 하면 불만을 터뜨리는 개발자들이 동시에 존재하기도 한다.
● 비전을
공유한다는 환상 속에자신의 비전을 직원들에게 강요. (공감대형성에 실패)
“직원과 회사의 비전이 공유되는 회사가 좋은 회사이다.”
외국의 성공한 경영자들의 자서전을 보면 거의 항상 나오는말이다. 하지만 비전의 공유는 대표이사가 “Vision Statement(비전을 간단
명료하게 표현한 문장)”을만들고 이를 직원들에게 외우게 함으로써 하루아침에 이루어지지 않는다. 이를 혼동하는 대표이사들이 의외로 많았다.
● 개발에 지나치게 간섭하거나 아예신경을 쓰지않음
어설프게 아는 사람이라면 개발에 지나치게 간섭할 것이며, 아예
모르는 사람이라면 신경을 쓰지않을 것이다.
게임 개발프로세스를 이해하는 데 몇 년간의 대학 공부가 필요한 것도아니고, 1년정도만
관심을 갖고 노력하면 될 일인데, 경직된 회사의 리더들은 이런데 힘을별로 쓰지 않는다.
4) 필요 이상의 많은 투자를 유치하는데
성공
최근 투자분위기가 냉랭해졌지만, 99년 말부터 2001년까지 상당한 액수의 투자금을 유치하는데 성공한 회사들이 꽤 많았다.
이들 중에는 지나치게 많은 투자로 인해 경직화의 길을 걷게 된 회사들도 있었는데 그 이유를 정리해 보면 다음과 같다.
●
대표이사의 냉정한 현실 인식감각이 흔들림
투자 유치란 프로젝트 또는 회사의 출발일 뿐이다.
하지만 거액의 투자금이
통장에들어오는 순간 이미 목표를 달성한 것으로 착각하는 경우가 많다. 그 결과 다음에 이야기할 무리수들이 시작되곤 한다.
●
회사의 규모를키우는데 재미가 붙음 투자받자 마자 대표이사가 차부터 바꿨다면 그 회사는 경직화의 길로 들어서고 있다고 생각하면 된다.
이제부터 자본금의 규모에 어울리는 회사가 되어야 한다고 생각하는 것이다. 직원들도 많이 뽑고, 사무실도 넓히고…(명분은좋은 개발
환경을 만드는 것이지만)
● 대기업을흉내낸 마케팅으로 실속없는 비용 지출이 늘어남
대표적인 것이 효과가 의심되는 TV
광고/ 이미지 광고 등이다.
이미지 광고는 TTL의 경우처럼 주요 광고 시간대를 물량으로 도배하지 않으면 별 효과가 없다.
투자를많이 받았다고는 하지만 작은 규모의회사에서 TV 광고를 아무리많이 해보았자 일 주일에 몇번에 지나지 않는다.
이처럼 적을
모르고 나를 모르는 마케팅은 투자로 인해 경직된 회사의 특징 중 하나이다.
● 회사의 전략이나 게임 개발 방향을 결정하는데
"투자자"를 의식하지 않을 수 없게됨으로써 제약이 많아짐.
투자액수의 규모가 클수록 작은성공으로는 만족할 수 없으므로, 한번에
크게터뜨려야 한다는 "대박"에 대한 심리적 압박감이 높아지게 된다.
따라서 점진적인 성장 계획이나 단계적 개발 계획을 세우는것이
불가능한 회사 분위기가 형성 되기 쉽다.
5) 관리자와 마케터, 그리고 개발자간의 대단한 인식차
경직된 회사에서
관리자와 마케팅 담당자, 그리고 개발자들은 근본적으로 다른 시각을 가지고 있다. 이를 정리해 보면 다음과 같다.
● 관리자가
개발자를 보는 시각
<초기/중기>
“자기 관리가 안되는 믿을 수 없는놈들. 매일밤새 게임하고 아침까지 널부러져
있으니..이거손 댈 수도없고.. 콱”
<중기/말기>
“안되겠다. 내일부터 엄격한 출퇴근 관리에 들어간다. 9시까지
출근하고 반드시 출근부 써!”
● 마케터가 개발자를 보는 시각
<초기/중기>
“마케팅의 중요성을
모르고 자기 하고 싶은것만 만들려고 하는 무식한 것들”
“지금 이런 게임 만들어서 장사가 되나? 경쟁자가 얼마나 많은데… 마케팅
통계도 안보나?”
“크리스마스까지 완성해야만 게임을 팔 수있는데...”
<중기/말기>
“안되겠다.
내가 개입해야겠다. 무슨 일이 있어도 스케쥴 대로 발매한다. 알았나!”
● 개발자가 관리자나 마케터를 바라보는
시각
<초기>
“게임을 한번도 해보지도 않은것들이... 아무것도 모르면서.. 젠장”
“게임 개발은
자유로운분위기에서 해야 하는데, 우리 회산이게 뭐야.”
<중기>
“저런 무식한 것들... 하지만 힘이 없으니
시키는 대로 할 수밖에.. 이 게임 만들어봐야 팔리지도 않겠다.. 완성이나될까? (체념)”
“크리스마스 때까지 출시 불가능한데..
근데 이걸어떻게 말하지? 에라 모르겠다 어떻게든되겠지.. 안되면 뭐 그때 연기하지(우리만 게임 연기하나)”
2) schedule, scope,resource 중에서 항상 schedule이
우선이다.
하지만 셋중 하나를 선택하면 나머지 2개는 어느 정도포기를 감수해야 한다는 사실을 깨닫지 못한다. (머리로만 이해한다.)
3) 따라서 초반에는놔두더라도개발 막바지에갈 수록 간섭이 심해진다. (특히 스케쥴 관리를 직접하려고 함)
4) 조직
관리를 중요시 하면서도 가장 중요한 "직원(=게임개발자)의 심리 대한 이해" 능력이 떨어진다. -> 조직 관리가 될 리가 없다.
5) 성공프로젝트에대한 마케팅의결정적 요소를 강조하면서도 마케팅 능력이 현저히 떨어진다. (구매자의 심리를이해하지 못하므로)
따라서 기본을 도외시하고 기상천외한 마케팅에만 몰두하는 경향이있다.
6) 문서를 좋아한다.
7) 기본을
소홀히 하므로 항상 묘안을 짜내느라고생한다.
8) 내용보다는 형식을 강화함으로써 안도감을 얻으려고 한다. (좀 어렵다 싶으면
출퇴근 관리를 강화함으로써 분위기를 잡으려고 하는것이 대표적이 예이다.)
[경직된 회사에서 게임
만들기]
1. 전제
그렇다면 이런 경직된회사에서 게임을
만들기 위해서는어떻게 해야 할까? 필자의 경험상 몇 가지 원칙만 지킨다면 경직된 회사에서 게임을 만드는것이 불가능한 것만은 아니다. 단, 비록
회사는 경직되었을지라도 관리자나 마케터들이 어느 정도 이성적인 인물들이라는 전제하에서 말이다.
만약이 성적 사고능력이 마비된
사람들이라면 다음에 말할 어떤 방법도 통하지 않으며, 따라서 딴 회사를 빨리 알아보는 것이 인생을 낭비하지 않는지름길이라고 생각한다.
2. 경직된 회사에서 게임만들기
경직한 회사에서 게임을만들기 위해서 가장 중요한 것은 개발의
시작부터끝까지 한결같은 신뢰를 획득해야 한다는 점이다.
어차피 마케터나 관리자들은 자신들이 게임 개발의 전문가가 아니라는 것을
어느 정도 이해하고 있다. 따라서 이들이 개발자들에게 불안감을 느끼게 만드는 요소를 미연에 제거 하기만 한다면, 개발의 시작부터 끝까지를
보장받을 수 있을것이다.
하지만 결코 이것이 쉬운것은 아니며, 최소한 다음과 같은 노력을 끊임없이 할 필요가
있다.
1) 안되는 것,자신 없는 것은 처음부터 이야기해라 (아무리 겁나도 이야기 해야한다). 그렇지 않으면 프로젝트는 실패할
수밖에 없으며, 책임은 항상 개발자에게 돌아온다.
2) 헌장(Charter)부터만들어라. 그리고 이 헌장에 주요 책임자들의 사인을
받아 놓아라. 헌장(Charter)이란 원래중세 도시의 상인들이 자신들의 상업적 자유를 얻기 위해 영주와 계약을 맺은 증서를 가리킨다.
영주로부터헌장을 받아냄으로써그들은 훗날 영주가 변덕을 부리더라도 꼼짝 못하게 반박할 수 있었던 것이다. (이 헌장의 대표적인 것이 유명한 대헌장
.마그나 카르타- 이다) 게임프로젝트를 시작하기 전에도 헌장을 만들어 둘 필요가 있다. 헌장에는 다음과 같은 내용이 들어가야한다.
- 비즈니스적인 목표
- 개발측면에서 바라본 프로젝트 목표
- 최종 결과물 정의
- 고객 정의(내부 고객및
외부고객)
- 고객의 어떠한 요구를 충족시켜줄 것인지정의(scope)
- 공동 운명체(stakeholder) 정의
- 개발
프로젝트 책임자정의
- 출시 시기(데드라인) 정의(schedule)
- 투입 인력한도 정의(resource)
- 투입
비용한도 정의(resource)
- 기타 제약사항 정의
- 프로젝트 우선 순위정의 (schedule, scope,
resource)
- 기타 필요한 정의
● 헌장작성의 의미
- 헌장에 사인을 받는 순간 회사와의 계약이
이루어지는 것이므로, 작성은 신중하게, 그리고 자신있는 내용만을 적어야 한다. 만약 "안될 줄 알면서" 분위기에 휩쓸려 싸인해 놓으면 훗날 모든
문제의 책임은 개발 책임자가 뒤집어 쓰게된다.
- 헌장 작성과정에서 회사 책임자나마케팅 등 관련 부서책임자들은 회사의 실상
(개발자의 개발 능력이나 장단점, 어느 인력이 부족한지등)을 정확히 이해하게 되므로, 개발 현장의 문제점을 미리 알고 함께 대처할 수가있다.
- 신뢰할 수 있는 정보를 토대로 헌장을 작성함으로써 개발외의모든 부서가 비교적 정확한 계획을 세울 수 있다. (개발 따로
마케팅/홍보따로의 악습에서 벗어날 수 있음)
- 헌장작성 과정에서 각 운명체들은 프로젝트를 함께 수행한다는 공감대를 형성할 수가
있다.
- 이성과 상식이 안 통하는 불합리한 회사에서 헌장은 훌륭한 방패의 역할을 수행하기도 한다. (책임 회피용 방패?)
3) 공동운명체(stakeholder)를 우리 편으로만들어라.
- 공동 운명체(stakeholder)와는 중요한
정보를 항상 공유해야하며, 문제가 생기면 미리미리 상의. 함께 해결책을 찾는습관을 들여야 한다. 이들은 게임이 성공하면 함께 웃고, 실패하면
함께 울게될 사람들이기 때문이다.
- 또한 평소에 인간적인 신뢰를 쌓도록 노력하는것이 좋은데, 인간은 감정의 동물이기 때문이다.
감정이 안좋다면 어려운 상황에서 협조를 기대하기 어려울 것이다.
4) 게임의 포커스를 단순 명쾌하게 정리하여 윗사람들을 충분히
이해시키고, 확신시켜라.
- 윗사람들이 프로젝트 성공을 확신하게 되면 개발이 편해진다.
- 장황한 설명보다는 단순 명쾌하게
요점을 정리할 필요가 있다. (써서 벽에붙여도 좋다)
- 필요하다면 사내 프리젠테이션을 해라 (이 경우 제품의 우수성 보다는 왜 돈이 될
것 같은지에 집중해서 할 필요가 있다.)
5) 스케쥴 작성시 마일스톤(milestone)을 중간중간에 세워놓고 작업 진행 상황을
눈으로 확인시켜 주어라
- 일이 진행되는 과정을 전혀 보지 못하면서 일년이상 계속적인 신뢰를 보낼 사람은 없다.
-
눈으로 보여 주는것이 중요하다. 말로 설명하는 것은오해 또는 억측을 불러 일으키기 쉽다. (경험이 다른 사람들은 같은 용어를 사용해도 다른
의미로 받아들이기 쉽다. 또는 전혀 다른 식으로 이해할수도 있다,)
- 본인이 이해하지 못하는 프로젝트의 성공을 확신하고 끝까지
밀어줄 사람은 없다. (만약 프로젝트 중간에 이 프로젝트의 성공 가능성을 의심하는 다른사람의 의견이 들려 오거나할 때 반드시 마음이 흔들리고 말
것이다.)
6) 스케쥴 작성시 타 부서와의 공동작업까지도 염두에 두어야 한다.
- 개발팀이한창 바쁠 때 홍보용 자료
제작 의뢰가 들어온다거나 하면 무척 곤란하다.
- 타 부서와의 업무협조가 안되면 사방에서 불평이 나올 수밖에 없다.
- 특히 마케팅 쪽의 요구에 소홀한 모습을 보인다면 “마케팅의 중요성을 인식하지 못 하는 개발자” 라는오해를 살 수 있다.
- 따라서 스케쥴 작성시 타 부서와의 업무 협조가 필요한시기를 미리 파악, 스케쥴에 반영해 놓아야만 작업막바지의 혼란과 대립을
미연에 방지할 수 있다.
- 한국에서 이런 스케쥴작성의 주체는 대부분 개발쪽이다. 아직까지 개발프로세스 전반에 대해 충분히
알고있는 마케터들이 많지 않기 때문이다.
7) 리스크 관리를 미리해두어야 한다.
- 개발도중 어떤 위험요소가
있는지를 미리 알고 있는 것과 모르고있는 것은 큰 차이가 있다.
- 개발팀만으로는 대처할 수 없는 리스크가 있다면 계획 단계에서
미리 공동운명체(stakeholder)와 이 문제를 논의해야 한다. 이경우 함께 해결 방안을 찾거나, 최소한 최악의 경우를 대비한 책임분배가
가능하다.
- 리스크를 예상하고 미리 대처준비를 해 두는모습은 경영자에게 신뢰감을 심어 줄수 있다. 뒤늦게 허둥지둥하는 모습을
보일 때마다 경영자의 신뢰는 감소하게 된다.
8) 팀이 단합된 모습을 항상 보여줄 수 있어야 한다.
- 팀이 흔들리고 말이
많으면 어떤 경영자도 그 팀이 수행하는 프로젝트에 신뢰를 보내지 못할것이다.
효율적인 팀 및 프로젝트 관리를 통해 팀이 안정적으로
개발프로젝트를 수행한다는 전제 하에서 위의 원칙들이 의미가 있는것이다. 일단 잃어버린 신뢰는 다시 회복될 가능성이 거의없다.
-
견고한 팀은 그 팀의 리더에게 힘을 부여한다.
따라서 부득이하게 대립이 일어날 경우에도 리더가 소신껏 싸울 수 있는
것이다.(그렇지 않다면 경영자는 리더를 교체 함으로써 문제를 빨리 해결하고자 하는 유혹에 빠지게 될 것이다.)
9) 스케쥴을
지키지 못할 심각한 변수가 생겨났을경우(개발팀혼자서 해결할 수 없는 문제인경우) 공동운명체(stakeholder)에게 미리 이야기하고 대처
방안을 찾는다.
- 어떤 프로젝트도 계획대로 이루어지는 경우는 없다 (리스크 관리를 했다고 해도)
- 따라서 돌발
변수가 나오는 것은 자연스러운 것이며, 다만이 돌발변수를 해결 할 시간을 스케쥴 작성시 미리 안배해 놓았느냐 아니냐가 문제가 될 뿐이다.
- 개발막바지에 와서스케쥴을 연기해야 한다고 이야기하는 것은 무책임한 행동이다.
- 개발 막바지에는 이미 마케팅
측면에서 온갖 계약이 다 이루어져 있을 가능성이 높으므로 스케쥴 연기는 쉬운 일이아니다. (거의 불가능)
- 해결할 수 있는
시간이 있을 때 발견되는 문제는 “예상치 못한변수”이지만, 시간이 없을 때 발견되는 문제는 “재앙” 이다.
3.
결론
- 어떤 회사건 개발팀이 경영자로부터 신뢰를 얻지 못하면 개발 과정이 고달프고 결가 나쁠수밖에 없다.
- 문제는 대개의 회사에서 개발 능력이 높은 사람보다는 정치 술수가 좋은 사람이 신뢰를 얻는다는 것이다.
- 개발
능력이 높은사람이 신뢰를 받기 위해서는 “합리성”과 “체계성”에 근거 할 수 밖에 없다. 그 밖의 수단. 예를 들어 ‘정치’ . 에 의존하다가는
큰 낭패를 볼 수 있다.
- 또한 체계적인 개발 관리와 팀 운영, 그리고 개발팀이 개발뿐 아니라 마케팅이나 홍보에 대해서도 폭
넓게 고려하고 있다는 인상을 심어 주는 것이 중요하다.
대개의 경직된 회사에서는 “마케팅 지상주의”과 “개발 지상주의”가 충돌하기
때문이다.
-신뢰를 얻는 다는것은 게임 개발의 특성에 무지한 경영자나 관리자가 바라는 대로 따라 줌으로써 얻을 수 있는
것이아니다. 또한 그들과 비타협적으로 싸우는 것만이 능사도 아니다. 그들의 성향을 이해하고, 또한 모두가 공동운명체라는 전제하에, 그들의 신뢰와
협조를 자연스럽게 이끌어내는 지혜가 필요한것이다.
- 끝으로 위와같은 이성적, 합리적 접근이 아예 통하지않을 것 같은 회사라면
당장 사표를 쓰기를 권한다.
그 경우엔 어떠한 노력도 소용없을 것이기 때문이다. (몸 망치고, 경력망치고,정서적으로 타격을 입게 될
것이다.)
---출처---
KGDC 2002
경직된 회사에서 게임 개발하기
작성자 : 김 웅 남
이오리스 온라인 사업팀
gomsik@eolith.co.kr
* generic 을 옴기는 과정에서 그냥 일반화라고 적었는데요, specialize 와 마찬가지로 template 관련 책을 보시지 않으면 잘 이해가 되지 않을 것입니다. 보통 객체지향 프로그래밍과 대비되는 말로 template 을 사용한 디자인을 일반화 프로그래밍이라고 하며, 일반화로 디자인된 객체를 실제 객체로 매칭시켜서 특화시킨 것을 template specialize 라고 합니다.
* stl 도 마찬가지지만 boost 는 고수준의 template 코딩 테크닉이 함축되어 있어 사용 혹은 구현 소스를 보실 때 혼동이 많으실 겁니다. 국내에 관련하여 빨간책 시리즈가 나와 있는데요, 이 책들이 도움을 줄 수 있을 것입니다.(modern c+ design 외 다수)
* 정리하다 보니 정말 너무 많네요. 제가 영어가 부족한 부분도 있는데다가 실제 내용을 읽어보지 않고서 정리하기에 무리가 있는 부분도 있고, 중간에 볼드체로 표시하지 않은 부분 부터는 간단하게 적어보았습니다. ---------------- [ Container ] ----------------
Any 다른 형태의 타입들을 담을 수 있는 안정적이고 일반화된 컨테이너
Array 고정 크기 배열을 위한 wrapper 로, STL 과 쉽게 연동하여 사용할 수 있다.
Assign 컨테이너를 채우는 것을 보다 쉽게 만들어 주는 유틸
Bimap 쌍방향 map 라이브러리. Boost.Bitmap 을 사용하면 map 의 key 와 value 모두를 key 로 사용할 수 있는 결합 컨테이너 를 생성할 수 있다.
Dynamic Bitset
bit 집합을 나타내는 class. operator[] 를 사용하여 각 bit 에 접근할 수 있으며, 모든 비트 연산자를 바로 사용할 수 있다. 집합에 들어있는 bit 의 갯수는 실행 시간에 dynamic_bitset 의 생성자의 인자를 사용하여 지정할 수 있다.
Fusion
다양한 컨테이너나 알고리즘 등을 통합한 tuples 을 만들 수 있도록 도와주는 라이브러리.
Intrusive
컨테이너와 알고리즘을 조합하여 사용할 수 있는 일반화 객체
Iterators
두 가지 기능을 지원한다. 첫 째, c++ 표준 반복자 개념을 확장한 시스템. 두 번째는 확장된 반복자 개념과 몇 가지 유용한 반복자 아답터를 포함하는 기능을 기본으로 하여 새로운 반복자를 만들어 낼 수 있도록 컴포넌트화 하는 것이다.
Multi-Array
일반화된 N차원 배열을 정의하거나 공용 인터페이스를 구성할 수 있도록 도와주는 라이브러리
Multi-Index
하나 혹은 그 이상의 인덱스를 가지고 있는 컨테이너를 만들고 정렬하거나 접근할 수 있도록 도와주는 multi_index_container
Property Map
맵의 키와 값을 연결 시킬 수 있는 인터페이스를 정의할 수 있도록 도와준다.
Variant
안전하고 일반화 되어 있으며 스텍 기반의 판별 결합 컨테이너(descriminated union container)
Call Traits 파라메터를 넘기기 위한 최적의 방법(어떤 타입 T 의 value, reference, const reference, 함수 인자(const T&) )을 제공한다.
Conversion C++ 표준 cast 를 보완하기 위한 변환 함수를 제공한다.
Concept Check 일반화 프로그래밍을 위한 도구. 컴파일러가 보여주는 복잡하고 이해할 수 없는 템플릿 에러 메시지를 이해할 수 있도록 바꾸어 준다.
Enable If 함수 템플릿 혹은 클래스 템플릿을 특화할 때 인자에 제약을 줄 수 있는 도구
MPI
메시지 교환 인터페이스를 제공하는 라이브러리, 분산 메모리에서 병렬 응용 프로그램들이 사용할 수 있도록 고완되었다.
Sprint
인라인 c++ 의 EBNF 문법을 바로 분석할 수 있는 LL 파서
Tuple
여러 값을 반환할 수 있는 함수를 정의할 수 있게 해준다.
Type Traits
타입을 프로퍼티로 사용할 수 있게 해준다.
Typeof
Wave
표준을 따르며, 반복자 인터페이스로 쉽게 c++ 프리 프로세서의 고수준 설정을 구현할 수 있게 도와준다.
Xpressive
문자열이나 템플릿으로 만들 수 있는 정규식으로 다른 정규식들과 결합하거나 context-free grammer 에 의한 재귀적 사용이 가능하다.
---------------- [ Math ] ----------------
Integer
1999 년 C 표준의 <stdint.h> 의 기능 강화판
Interval
수리적 범위를 처리하기 위한 함수들을 확장시켰다.
MPL
컴파일 시간에 수행되는 알고르즘, 반복, 메타 함수를 구현하기 위한 고수준의 메타 프로그램 제작을 위한 프레임워크. 기본적인 개념과 c++ 문법안에서 쉽고 즐겁게 메타 프로그래밍을 할 수 있도록 도와주는 광범위하고 강력하며 일관된 도구들을 지원한다.
Math
수학 라이브러리. 실시간 혹은 컴파일 타임에 계산할 수 있는 GCD(Greatest Common Divisor, ㅎㅎ;지금 보니 최대공배수네요) 와 LCM(Least Common Multiple, 최소공배수) 라이브러리를 제공한다. Special Functions 는 현재 버전에서는 8개의 특수한 함수를 제공한다. Complex Number Inverse Trigonometic Functions 는 C++ 표준에 있는 삼각 함수의 역함수를 제공한다. Quaternions 는 3차원 공간에서 회전을 위해 종종 사용하는 복잡한 숫자들의 관계를 알아내는데 도움을 줄 수 있다. Octonions 는 quaterinos 처럼 복잡한 숫자들의 관계를 규명하는데 도움을 줄 수 있는 라이브러리 이다.
In Place Factory, Typed In Place Factory
다양한 인자 리스트를 포함할 수 있는 객체를 내부에 생성할 수 있도록 고안된 일반화 생성기
---------------- [ Image ] ----------------
GIL
일반화된 이미지 라이브러리.
Graph
BGL 그래프 인터페이스와 그래프 컴포넌트들을 STL 처럼 일반화 하였다.
---------------- [ String ] ----------------
Format formatting 된 stream 을 만들기 위한 강력한 library.
Regex
정규식 라이브러리
String Algo
문자열 알고리즘 라이브러리
Tokenizer
문자열이나 문자 패턴을 을 나눈다.
---------------- [ System ] ----------------
Filesystem portable file library
IO State Savers
boost 의 I/O 보조 라이브러리로써 매우 많은 개수의 boost 헤더 파일들을 분류하여 사용하기 편하게 해준다. 이 보조 라이브러리는 표준 I/O 라이브러리를 사용한 매우 다양한 아이템들을 포함하고 있다.
System
운영체제를 지원하는 라이브러리
Thread
포팅 가능한 c++ 멀티 쓰레딩
---------------- [ ETC ] ----------------
CRC 템플릿 기반으로 작성된 두개의 CRC 객체와 두개의 함수를 제공한다.
Compatibility
Boost 의 일부 라이브러리가 표준 라이브러리와 호환되지 않을 경우 도움을 줄 수 있다. 언젠가 이 라이브러리가 필요 없는 날이 오기를 바란다:D
Compressed Pair
std::pair 와 유사하지만 비어있는 맴버가 있는 경우 최적화를 시도한다.
Date Time
일반화 프로그래밍으로 만들어진 날짜/시간 라이브러리
Foreach
for_each 강화 버전. iterator 를 이용하는 for 문을 perl 과 같이 단순화
Interprocess
공유 메모리, 메모리를 파일에 맵핑 시키기, 프로세스 공유가능한 뮤텍스, 상태 변수들, 컨테이너, 할당자
Iostreams
스트림, 스트림 버퍼, I/O 필터를 제공한다.
Parameter
이름으로 함수 인자를 구별할 수 있도록 해줌
Pool
메모리 풀 관리자
Preprocessor
반복, 재귀를 포함한 메타 프로그래밍 도구
Program Options
커맨드 라인이나 설정 파일과 같은 편리한 인터페이스로 프로그램 옵션을 설정할 수 있도록 도와주는 라이브러리
Python
파이썬과 c++ 의 연동을 지원하는 프레임워크. 빠르고 균일하게 c++ 클래스의 함수나 객체들을 파이썬에서 사용할 수 있게 만들어 주며 다른 특별한 도구를 추가로 실행할 필요가 없다. (c++ 컴파일러만 있으면 된다.)
Random
랜덤 숫자를 생성하기 위한 완벽한 시스템이다.
Range
새로운 반복자 개념을 사용한 일반화 알고르즘을 위한 인프라
Ref
함수에 레퍼런스를 전달하는 것을 도와주는 유틸리티 라이브러리
Serialization
persistence 와 마샬링을 위한 serialization
Signals
콜벡으로 구현할 수 있으며 관리되는 시그널과 슬롯
Statechart
복잡한 유한 상태 오토마타를 일기 쉽고 유지 보수하기 쉽게 구현할 수 있도록 도와준다.