스타크래프트의 개발사 – 개발과 유지보수의 경계점은?

1996년 런던 E3쇼에서 최초 공개되었을 때의 모습. 지금 보자면 그야말로 “넌 누구냐?” 라는 말이 딱 어울리는 모습이다. 워크래프트2와 비슷한 이유는 워크래프트2 엔진으로 만들기 시작해서 그렇다고 한다. 무엇보다 공격 가능한 오버로드의 존재는 참(…)

욕을 바가지로 먹고 게임을 거의 다시 만들다시피 해서 토해낸 결과물(1997 알파). 워크래프트 물이 빠지고 캐리어도 꽤 익숙한 모습이지만, 드랍십이 캐리어만한 데다가 골리앗만 8개가 들어간다. 반면 캐리어 인터셉터 3개는 너무 심하다는 생각이.

일반에 공개되기 일보 직전(1997년 베타). 일단 가스 개념이 등장하는 등 맵도 어느 정도 제대로 구성이 되었고, 레이스를 비롯한 공중 유닛들도 틀이 잡혔다. 하지만 유닛 업그레이드 창에 있는 촌스러운 파란색 테두리와 아직 어설픈 폭발 효과는 아직 눈에 띈다.

일반에 공개하기 시작(1997). 스파이어가 좀 기괴하게 생긴 것 빼면 봐줄 만 한 모습이다. 덧붙이자면, 나온 지 10년이 지나도 스타크래프트의 지형 배경(왼쪽 위 가게 간판 같은)은 정말 멋지다는 생각이 든다.

이 과정에서 정말 많은 왔다리 갔다리가 있었던 것으로 보인다. 이 스크린샷에서는 파일런이 게이트웨이만하질 않나, 파이어뱃이 엄청난 장사정 화염방사기를 쏘질 않나…

1999년 겨울에 나왔던 브루드 워 베타 버전도 막상막하. 스팀팩 비슷한 기능을 가진 발키리. 이 기능이 있으면 발키리가 너무 세졌기 때문에 결국 정식 버전에서는 제거되었다고 전해진다.

피드백,쉴드채우기,옵티컬 플레어를 가진 다크 아칸 -_-;

1.

출처는 기억나지 않지만, 어딘가에서 줏어들은 스타크래프트 개발 에피소드 중에 이런 것이 있었다. 위 스크린샷에서도 확인할 수 있지만, 스타크래프트는 게임을 좀 더 재미있게 하기 위해 (과장 좀 해서)수백 번을 갈아엎은 결과물이다. 게임을 좀 더 재미있게 하기 위한 기획자들의 고민도 깊었겠지만, 게임도 엄연히 프로그램인지라 이 기획을 구현하는 과정이 중요하다.

전하는 이야기에는, 기획자들이 게임이 재미없을 거 같다고 하도 바꾸고 뒤엎고를 반복하자, 보다 못한 프로그램 팀이 결국 한마디 했다: “두 달만 시간을 주세요. 원하는 대로 만들어 줄께요.” 말이 원하는 대로 만들어 주는 거지, 게임을 엔진 수준에서 들이엎는 것이었으니 완전히 다시 만드는 거나 다름 없었다.

문제는, 정말 두 달 뒤에 완성이 됐다는 거다. 이 때 추가된 기능들 중 하나가 그 유명한 버로우 기능이란다.

2.

학교에 처음 들어갔을 때 들은 Computer Science 전공 수업에서 객체 지향 프로그래밍Object-Based Programming의 개념을 설명하는 부분이 있었다. “소프트웨어는 개발하는 기간보다 수정하는 기간이 더 길며, 따라서 수정에 유연하도록 프로그램을 개발해야 한다.” 고 배웠던 기억이 난다. 그 뒤로도 소프트웨어 공학에 대해 이런저런 자료를 섭렵했지만, 맨 처음에 배운 교수님의 한 마디는 지금까지도 내 머릿속에 또렷히 박혀 있다.

3.

회사에서 유지 보수 1년 반 정도 한 것 가지고 이런 이야기 하기는 좀 뭐한데, 개인적으로 게임에 있어서 개발과 유지 보수 사이에 얼마나 선명한 경계선이 있는지 의심스럽다. 일반적인 소프트웨어는 그 용도와 기능이 상당히 명확한 편이고, 바뀔 일이 그리 많지 않을지도 모른다. 하지만 게임의 경우, 용도(=재미)는 명확할지 몰라도 그 구체적인 기능이 어떠해야 하는지는 아무도 모른다. 일단 만들어 보고 테스트해야 어느 정도 손에 잡힌다. 그리고 그 길은 끝없는 고행이다. FPS 게임에서 모드 하나 만들려고 하면 기획자의 부탁 하나에 수십 번 뜯었다 고쳤다를 반복하는 건 예사다. 그러고도 재미가 있을지 없을지는 장담하지 못한다. 이렇게 놓고 보면, 게임 프로그래밍은 개발하는 기간보다 수정하는 기간이 긴 정도의 문제가 아니다. 개발 기간 따위는 장식에 불과하고, 수정하는 기간이 거의 전부다.

언젠가 게임 프로그래밍이 다른 프로그래밍(예를 들어 SI, 보안 등)분야와 다른 점이 뭐라고 생각하느냐는 질문을 받은 적이 있다. 그 때 내가 어떻게 대답했는지는 기억이 나지 않는다. 하지만 지금 내게 그 질문을 던진다면, 나는 “끝없는 변화의 연속”1 이라고 대답하겠다. “온라인 게임 서비스” 라는 말에서도 알 수 있듯, 온라인화된 게임은 이미 상당 부분 고정된 실체라기보다 계속 살아서 업데이트되는 서비스다. 해외 유통사에서 어떠한 것을 요구할지, 유저들을 위해 어떠한 것을 업데이트해야 할지는 아무도 모른다. 문제는 수익의 상당 부분이 이 업데이트 과정에서 발생한다는 점이다. 상황이 이렇다보니, 유연하고 변화에 적응하는 코드는 필수적이다.

4.

덧붙이자면, 개발을 빙자한 고행이라는 측면에서 보면 워크래프트3도 스타크래프트에 결코 뒤지지 않는다. 이 경우엔 게임의 컨셉 자체가 거의 유례가 없다보니 삽질이나 뒤집어 엎기가 훨씬 심했다. 심지어 게임이 정식으로 발매된 이후에도 한참을 수정 작업을 거쳤을 정도니까. 그래도 어떻게든 제대로 된 완성품을 내놓은 걸 보면, 블리자드가 세계 최고라 불리는 이유를 알 수도 있을 것 같다.

결론: 블리자드 굇수님들아 매너 좀.


  1. 생각해보니 이 점에서는 web 프로그래밍 영역이 상당히 비슷할 것 같음. 

19 thoughts on “스타크래프트의 개발사 – 개발과 유지보수의 경계점은?

  1. 실제로는 객체지향을 잘 적용하는 걸로는 많이 부족하고, 데이터 드리븐을 얼마나 잘 하는지가 관건일 듯..

    • 음, 가능하면 많은 기능을 하드 코딩보다 스크립트 쪽으로 뺀다던가?

  2. Data-driven 내지는, 컴파일된 코드 부분이 얼마나 큰지가 변경이 용이한가 그렇지 않은가를 결정짓는 요소인거 같음
    + 근데 일단 OO부터되야(…)

  3. 개발비화를 보면 잘 만들어진 이유를 납득합니다;

  4. 하여간…. 이 괴수집단. 중간에 몽땅 갈아 업을 수 있는 자세가 부럽기 그지 없습니다. 저는 아까워서 그렇게는 못할거 같아요^^

    그러니 괴수들은 전세계를 상대로 장사하고 저는 여기 구석에 있는거겠죠?^^

  5. > 기획자가 게임이 재미없을 거 같다고 하도 바꾸고, 고치고, 뜯고, 뒤엎고를 반복하자 프로그램 팀이 한마디 했다: “두 달만 주삼. 원하는 대로 만들어 주겠으니까.”

    기획자는 개발에 대한 부담없이 지를 수 있고,
    개발자도 기획자를 믿고 같이 지를 수 있다면.. 정말 훌륭한 팀인 것 같아.

  6. 다크아콘 사진에서 저 아이콘은 마인드컨트롤 아닌가요?(아닌가….)

    • 마인드컨트롤 맞습니다 ㅋㅋㅋ 고어님 오타 은근히 많아요 오늘 첨와서 주루룩 훑어봤지만 ㅎㅎ(전 띄어쓰기 많이 틀리고)

  7. 아마도 브리자드의 프로세싱에는 리뉴얼도 계산되어있지않을까요?
    이모든게 즉흥적인것이 아닌 개발하면서 고쳐나간다 고로 초반 디자인에 에너지 소비하지 말아라

    뭐 이러한 내용으로 팀원들이 진행한다는게 더 무섭지만;;;

    • 충분히 미리 계산했겠죠. 언제고 프로그램까지 뒤집어 엎을 수 있도록…

  8. 스타를 광적으로 좋아하는데,

    하면 할수록 게임의 완성도에 놀라곤 합니다.

    물론 저는 프로그레밍에 대해 전무 합니다. ;;

    • 예, 아마도 걸작이란 그런 거겠죠. 민간인이 보나 선수가 보나 언제 봐도 놀라운 물건들…

Comments are closed.