You are here: Home - Studies∞ - 라이브러리언에 대해서

0905112150라이브러리언에 대해서

내가 프로가 된 지 얼마 되지 않았을 즈음 ‘술형님(TM)’께서 해주신 말씀 중에 재미있는 것이 있어서, 소개해볼까 한다.

바로 EA에 있는 라이브러리언에 대한 내용이다.
라이브러리언이라고 하면, 한국어로 이야기 하자면 도서관 사서.. 정도로 번역될 수 있겠지만, 프로그래밍 특히, EA같은 게임 회사에 ‘사서’가 왠 말인가? (회사 도서관이 방대한가?)

사실 여기서 이야기 하는 ‘사서’라 함은 도서관에서의 그 뜻이 아니다.

프로그래밍을 해본 경험이 있는 사람들이라면 당연히 ‘Library’에 대해서 이해하고 있을 것이다. 바로 이 라이브러리로 부터 ‘Librarian’이라는 단어가 파생된 것이다.

좀 화제를 돌려서,

한국 프로그래밍 여건의 특징이라 함은 뭐..
두가지 뿐 아니겠는가.

‘일정’ 과 ‘압박’

일정과 압박이라는 단어와 반대되는 것도 있다. 바로 ‘설계’와 ‘테스트’ 이다.

일반적으로 한국에서의 SW는 ‘안정성’과 ‘완성도’로 평가 되는 것이 아니라,
‘돌아가는가?’ 와 ‘내일 있을 데모를 마칠수 있는가?’로 평가 된다.

아무도 소스코드의 품질이나, 내적인 완성도에 대해서(예를 들어 아름다운 노테이션이라던가)는 관심이 없다. 보통 사장님들은 내일 데모만을 원하고, 펀딩을 원하고, 한 몫 단단히 챙겨서 손 털기를 원할 뿐이다. 소스코드의 아름다움 따위야 그들의 관심사가 아니다.

그래서,
EA에서의 라이브러리언은 한국 같은 프로그래밍 여건에서는 정말 갖추어지기가 쉽지 않은 재미있는 Role이다.

일단, 라이브러리언이 있는 회사에서는
어떤 프로그램 코드를 작성하는 도중에 새로운 기능을 추가해야 하거나, 새로운 모듈을
개발해야 할 상황이 닥치게 되면(거의 매 순간 닥치지 않는가?) 프로그래머는 그냥 알아서 소스를 소스세이프나 CVS에서 꺼내 내키는 대로 코드를 써대는 게 아니라,

라이브러리언에게 멘트를 날린다.

“내가 지금 이런 기능을 구현하려는데, 이게 지금 회사의 라이브러리 풀에 있나요?” 라고…

그럼 라이브러리언은 Yes or No의 대답을 해주는데,

그냥 그 대답으로 끝나는게 아니라,
만일 대답이 Yes라면 해당 함수를 돌려주며,
만약 대답이 No 라면,
라이브러리언은 그 새로운 ‘모듈 혹은 기능’을 구현함에 있어서 그 함수가 갖추었으면 할
범용적인 틀을 제시한다. 그러면 프로그래머는 그 Frame을 받아서
(꼭 함수의 프로토타입을 의미하는 건 아니다.) 내부를 구현하고, 그 함수를 사용한다.

성공적으로 해당 함수가 사용되게 되면, 라이브러리언은 새롭게 구현된 그 함수를 수거하게 되는데 이렇게 수거된 함수는 다시 라이브러리언의 Source code purifing을 거쳐 깨끗한 노테이션의 상태로 회사의 라이브러리 풀에 적재 된다.

절대 불필요한 함수들이 여기 저기서 재 작성되는 낭비도 없고, 완성된 함수들이 말 그대로 “진정으로 완성..” 되지 않고, 적당히 동작만 하는 상태로 남아 있지도 않는다.

또, 라이브러리풀에 아무나 접근해서 그냥 단순하게 현재 쓰기 편한대로, 혹은 원하는 대로 코드를 헤집어놓을 수도 없다. 라이브러리 풀에 적재된 라이브러리는 완벽한 상태로 보존된다. (적어도 라이브러리언의 입장에서는 확실하다.)

내가 예전에 다녔던 직장에서는
하나의 3D엔진 속에 Matrix x Vector 연산이 4개가 존재했다.

내가 처음 이 이야기를 들은지 벌써 10년이 다 되어간다. EA는 이 10년간 라이브러리를
쌓았을테고(짧게 봐도), 내가 다녔던 그 직장은 10년간 만들었던 모든 엔진을 폐기처분하고, 언리얼엔진으로 갈아탔다.

by HKPark

Leave a Reply

Back to top