LOVEstation AD/DA - 게임 회사원의 도서관

http://www.yes24.com/Goods/FTGoodsView.aspx?goodsNo=2309846&CategoryNumber=001001003004

 

난 전산이나 소프트웨어 공학 전공자도 아니고 전문적인 프로그래머도 아니기 때문에 일부 이해하기 어려운 부분도 있었지만, 굉장히 재미있게 읽었다.

 

1990년에 처음 출판되었던 책이기 때문에 예시나 소재 등이 지금 트렌드와는 거리가 있지만, 오히려 그렇기 때문에 그때나 지금이나 변하지 않는 본질에 대해 생각해볼 수 있게 한다.

 

“소프트웨어 공학의 사실과 오해”의 필자가 쓴 책이라고 해서 주목했는데 꽤 알찼음. 은총알 비유의 출처를 알게 된 것도 의미있었다.  게임 개발을 전적으로 소프트웨어적 관점에서만 보는 것에는 동의하지 않지만, 공학적 마인드가 게임 개발 프로세스에 좀 더 적극적으로 도입되면 좋은 결과를 얻을 수 있을 걸로 보인다. (프로그래머 출신 디렉터들이 우대받는 경향도 바로 여기에 있다고 본다. 센스는 해결해도 무식한건 답이 안 나오니까…)

 

 

인상적이었던 부분을 옮겨적자면… . (*표는 감상 메모)

 

1) 13p.

소프트웨어 생산성을 비약적으로 향상시킬 계기, 몇배로 껑충 끌어올릴 방법은 무엇일까?

 

언어나 도구가 아니다.

자동 프로그래밍 방법론도 아니다.

소프트웨어 정형 검증도 아니다.

인공지능도 아니다. ~중략~

 

* XNA 와 관련해서 미래엔 프로그래머들 할 일이 없어질 거라는 논란이 생각났다.

 

2) 16p.은총알은 없다.

이 논문이 은총알 논문이라고 불리게 된 이유는 소프트웨어 공학의 근본 문제를 늑대 인간, 즉 은총알로만 죽일 수 있는 괴물에다 비유한 다음, 소프트웨어 분야에서 은총알은 없다고 주장했기 때문이다. ~중략~  소프트웨어 제작이 어려운 이유는 그것이 지니는, 그리고 지녀야 하는 복잡성 때문이다. “소프트웨어는 어쩌면 인간이 만든 어떤 피조물보다도 복잡하며,” “소프트웨어 시스템은 컴퓨터보다 상태(state)수가 몇배는 더 많으며,””소프트웨어의 복잡성은 본질적인 속성으로,” 수학 분야에서는 복잡한 문제를 단순화한 모델이 문제 해결 도구로 효과적이지만, 소프트웨어에서 복잡성은 다른 분야에서 사용하는 기술로 해결하지 못한다. ~ 중략 ~

 

* 그렇다면 게임 소프트웨어는 더욱 더 복잡하다. 우리 게임 업계 종사자들이 그 점에 대해 인정할 필요가 있다. 프로그래머에게 그 짐을 전부 떠맡겨서는 안된다.

 

그는 생산성향상을 위한 평범하지만 좀 더 가능성 있는 길을 제시한다.

1. 가능하면 소프트웨어를 제작하지 말고 구매하라.  

* 엔진! 미들웨어!

2. 점진적으로 소프트웨어를 제작하라. 프로토타이핑으로 소프트웨어 요구 사항을 다듬어라. 소프트웨어를 점진적으로 개발해서 개발 주기 초반부터 부분적인 해결책을 내놓아라. 소프트웨어 제작이 진정으로 어렵고 앞으로도 어렵다면 근본적으로 새로운 접근방식을 취해야만 한다.

3. 뛰어난 소프트웨어는 (방법론이 아니라) 뛰어난 설계자로부터 나온다는 사실을 기억하라. 창의적인 인재를 고용하고 양성하라.  ~중략~

 

 

3) 19p. 1980년대 후반 미 국방과학부 특별 위원회의 군용 소프트웨어 보고서에서.

“항후 십년 동안 소프트웨어 생산성, 안정성, 적시성을 10배 이상 향상시킬 기술적 발전은 눈 씻고 찾아봐도 없다.”

“업계 실무에서 최고 수준과 평균 수준이 이렇게 차이가 나는 분야는 거의 없다.”

* 암, 그렇고 말고.

“진짜 문제는 기술이 아니다. 오늘날 정말로 심각한 문제는 관리다.”

 

~ 중략~

시스템 분석에 관하여, 보고서는 소프트웨어 개발에서 요구사항 정의가 가장 어려운 부분이라고 지적한다. 요구사항 정의는 소프트웨어 분야에 내재하는 불가피한 문제라고 인정하며, 해결 방법으로 프로토타이핑을 지지한다.

 

~ 중략~

보고서는 전체 소프트웨어를 개발하는 과정에서 최소 완성 버전을 만들어 초기에 출시하라고 제안한다.

 

복잡한 소프트웨어 시스템을 개발하는 가장 간단하고, 가장 안전하며, 가장 신속하기조차 한 방법은 실제 용도를 바탕으로 우선 순위를 정한 다음, 최소 버전을 제작하여 실제로 사용하고 기능을 추가하고 속력을 높이고 크기를 줄여가는 방법이다.

 

~중략~

기성품 소프트웨어에 관하여, 보고서는 소프트웨어를 제작하는 최선의 방법은 `아예 제작하지 않기’라고 말한다.

 

소프트웨어를 가장 싸게 구하려면, 직접 제작하지 말고 시장에서 구매한다. 소프트웨어를 가장 빨리 구하려면, 직접 제작하지 말고 시장에서 구매한다. 소프트웨어를 가장 확실하게 구하려면, 직접 제작하지 말고 시장에서 구매한다.

* 안습, 이래서 하청에 하청인가..- -

 

~중략~

소스 코드 품질, 목적 코드 품질, 문서 품질 등을 평가할 기준이 없다. 전산 분야 밖에는 복잡한 성능의 품질을 전반적으로 평가하는 기술이 존재한다. 올림픽 다이빙, 스케이트, 체조 경기의 심판처럼 오늘날에도 훈련 받은 심판으로 이루어진 평가단이 소프트웨어 품질을 평가할 수 있겠다.

 

4) 33p. 인지적 견해: 소프트웨어 설계를 보는 다른 시각

이 수필에서 다루려는 질문은 “소프트웨어 설계란 무엇인가?”이다. ~중략~

 

설계의 외적인 표현에 연연하지 말고 사고의 흐름에 초점을 맞춰야 한다. 설계의 비밀은 마음 속에 있다.  ~ 중략~. 설계자는 마음 속으로 번개처럼 다음 작업을 수행한다.

 

1. 마음 속으로 모델을 만들어 본다.

2. 마음 속으로 모델을 실행한다. 즉, 시뮬레이션을 통해 모델이 문제를 해결하는지 확인한다.

3. (대개 모델이 너무 단순해서) 문제를 해결하지 못하면, 불충분한 모델에서 실패하는 부분을 찾아서 개선한다.

4. 모델이 문제를 해결할 때까지 1-3단계를 반복한다.

 

* 새로운 게임 컨셉을 구상하고, 설계하는 것도 이런 과정을 거친다고 봐야한다. 모델이란 단어를 게임 컨셉으로, 문제를 재미와 상업성으로 치환할 것

~중략~

그렇다면 설계의 본질은 신속한 모델링과 시뮬레이션이다! 그리고 설계의 핵심 요소는 해결책을 제안하고 실패를 허용하는 능력이다! 

말이 난 김에, 같은 연구진이 설계에 미숙한 사람들도 연구했다는 흥미로운 사실도 전한다. 이들은 모델이 아니라 설계의 표현에 치중했다. 시뮬레이션을 수행하지도 못했으며 불충분한 설계안을 내놓고는 더 이상 진전하지 못했다. 이와 같은 발견에서 내가 가장 선호하는 사고 방식 중 하나는 실패가 성공적인 설계의 핵심요소라는 생각이다! 직전 시뮬레이션의 끝에는 항상 실패한 모델, 즉 문제를 풀기에 불충분한 설계안이 있다. 따라서 성공하려면 실패하는 능력과 실패를 극복하는 능력이 필수적이다! ~중략~

 

어느 순간에 (설계가) 폭발적으로 떠올라서 머리 속에 모두 들어있다. 머리 속에 온갖 생각이 들어있어서 종이에 옮기지 못한다. 마음 속으로 계속 고치기 때문이다. [개리 킬달, CP/M 제작자]

 

프로그램이 어떻게 돌아갈지 마음 속으로 시뮬레이션 해야 한다. 무언가를 만들 때… 그리고 마음 속에 모델을 담고 있어야 한다. 이건 꽤나 고독한 작업이다. [빌게이츠]

~중략~

설계 수행 면에서, 설계자는 기존에 생각하던 설계 본질이 틀렸다는 사실을, 오히려 시행착오를 거쳐가며 반복하던 엉성한 절차가 바로 설계 핵심이라는 사실을 이해해야 한다. 그래야 설계자가 죄책감을 느끼지 않고 올바른 설계방식을 추구할 수 있다.

 

 

5) 45p. 소프트웨어 오류에 대한 단상

소프트웨어 개발자의 능력이 30배까지도 차이가 난다는 사실은 여러 차례 확인했다. 글렌포드 마이어는 한 소프트웨어 제품을 놓고 어떤 사람들은 다른 사람들보다 7배나 많은 오류를 찾아낸다는 사실을 발견했다. 낸시 레비슨의 연구에서는 오류가 60개인 소프트웨어 제품에서 24명 중 9명만이 오류를 하나라도 찾아냈다.

 

이 생각이 나타내는 바는…

소프트웨어 오류 제거에서 가장 중요한 요소는 제품의 특성이나 프로세스의 특성이 아니라 올바른 사람의 선택이다.

* 다른 책에서도 몇번 언급되었지만.

 

6) 67p. 소프트웨어 유지보수는 해결책이지 골칫거리가 아니다.

* 유비보수를 게임의 live, 업데이트로 생각하고 읽으면 재미있었음

여기서 다음 두가지 의문이 생긴다.

유지보수 문제에 최고 인력을 투입하는 정책이 타당한가?

현재 유지보수에 최고 인력을 투입하고 있는가? 

첫번째 질문에 대한 내 대답은 “그렇다. 유지보수는 소프트웨어 비즈니스에서 가장 어려운 업무중 하나다”이다. ~중략~

유지보수란,

> 지적으로 복잡하다. (유지보수 담당자에게 극심한 제약이 가해지는 가운데에서도 창조룍 발휘가 필요한 작업이다)

> 기술적으로 어렵다. (유지보수 담당자는 개념,설계,코드를 동시에 다룰 줄 알아야 한다.)

> 불공평하다. (유지보수 담당자는 항상 무언가 부족하다. 예를 들어 우수한 유지보수 문서가 없다.)

> 성공이 없다. (유지보수 담당자는 항상 문제가 있는 사람들을 만난다)

> 지저분하다. (유지보수 담당자는 세세한 구현까지 지저분한 수준에서 일해야 한다)

> 과거에 산다. (분명 코드는 누군가 구현에 능숙해지기 전에 작성했다)

> 보수적이다. (“긁어 부스럼 만들지 말자”라는 좌우명을 따른다.)

* 눈물 ,또 눈물

 

~중략~ 대다수 전산 업계에서는 신참이나 비숙련자가 유지보수를 맡는다. 유지보수는 창의력을 너무나 제한하므로 즐기기 어려운 탓이다. 그러다보니 자연적으로 가장 능력이 떨어지고 가장 수요가 낮은 인력이 대개 유지보수를 담당하게 된다.

내 추론을 여기까지 따라왔다면, 현 실정이 올바르지 못하다는 사실을 납득하리라. 유지보수는 골칫거리가 아니라, 상당한 지적 도전이자 해결책이다. 유지보수의 효율을 최대한 높이려면, 유지보수에 인력을 투입하는 방식이 크게 변해야 한다.

 

해결 방식을 구체적으로 제안하겠다.

 

음. 너무 많이 옮기는 것은 저작권 상 문제가 있을 듯 하여 여기까지만.

재미있겠죵? (..)