September 2007 Archives

작년 하반기에 가장 많은 시간을 할애해서 플레이하던 게임이 Battlefield 2142입니다. Battlefield 2142는 Battlefield 1942, Battlefield 2의 sequel로 64명까지 동시에 플레이할 수 있는 온라인 FPS입니다. 두 팀이 보다 많은 전략적 지점을 보다 오랫동안 점유하는 것을 목표로 경쟁하는 게임 형식을 취하고 있습니다. 성장 시스템을 가지고 있어서, 게임 내에서의 활동에 따라 점수가 지급되고, 일정 점수에 도달하면 계급이 오르며, 계급이 오를 때마다 특수한 무기를 새로이 사용할 수 있게 됩니다. 이러한 성장 시스템은 랭킹을 통한 명예라는 인센티브와 게임에 직접적으로 도움이 되는 실질적인 인센티브를 조합한 시스템이라고 볼 수 있습니다. 흔히 보는 MMORPG의 시스템을 FPS에 인접시킨 것이라고 볼 수 있겠죠.

Battlefield 2142는 전통적인 클래스 시스템을 가지고 있습니다. 즉, 이 게임에는 Recon, Assault, Engineer, Support라는 4가지의 병과가 있는데, 병과마다 특수한 무기들과 능력이 주어지고, 이에 따른 역할이 주어집니다. 예를 들어 봅시다. Assault 클래스는 라이플과 AR로켓을 장비하고 있어서 대보병전에 뛰어나며, 메디킷을 가지고 있어서 아군 보병을 치료할 수 있습니다. 한편, Engineer 클래스는 대전차무기를 장비하고 있어서 적 전차를 상대하는 역할을 맡게되고 아군 전차를 수리할 수 있습니다. 각 병과마다 역할이 다르기 때문에 고유의 플레이를 가지게되고, 성장을 할 때도 특정 병과에 집중해서 성장시킬 수 있기 때문에 독특한 플레이를 할 수 있습니다.

Battlefield 2142의 중요한 요소들 중 하나는 바로 분대(squad) 시스템입니다. 누구나 분대를 생성해서 분대장(squad leader)이 될 수 있습니다. 물론 누구나 자기가 원하는 분대에 들어갈 수 있습니다. 분대는 6명의 분대원이 최대이므로 제약은 있습니다. 분대를 만들 수 있다는 것만으로는 분대 시스템이 원활하게 동작하지 않겠죠. 서로 다른 병과의 분대원들이 모여서 시너지를 발휘할 수 있다는 것 외에도 분대에 참여하는 것만으로 게임 시스템에 의해 주어지는 것들이 있습니다. 각 병과에는 같은 분대원들에게 특별한 정보를 줄 수 있는 능력이 있습니다. 분대에 의해 발견된 적은 네트워크를 통해 바로 분대원의 레이더에 표시됩니다. 플레이어가 분대에 참여함으로서 얻을 수 있는 다른 중요한 이익은 바로 분대에 속한 다른 플레이어들-분대원들의 (경험치가 아닌) 경험입니다. 분대원끼리는 Voice를 통해서 대화를 나눌 수 있고, 급속한 전장 상황에 빠르게 대처하고 작전을 펼쳐나갈 수 있게됩니다. 물론, 분대장의 통솔 능력이 여기서 빛을 발합니다. 뛰어난 분대장이 이끄는 분대와 경험없는 분대장이 이끄는 분대는 분대원들의 생존 능력에서 뿐만 아니라, 분대원들이 느끼는 재미에 있어서도 커다란 차이가 있습니다. 분대장은 또다른 엄청나게 중요한 역할을 가지고 있는데, 바로 분대장 자신이 Spawn Point라는 사실입니다. 분대원들의 전방에서 멀리 떨어져있는 후방의 전략 지점이 아니라 전방에 있는 분대장 곁에서 바로 Spawn함으로써 빠르고 효율적으로 전투를 펼칠 수 있으며, 분대원들이 좀 더 뭉칠 수 있도록 도와줍니다. 이러한 분대 시스템은 아마도 Battlefield 이전에는 없었거나 또는 완성되지 않았던, 정말 완벽에 가까운 시스템이라고 생각합니다.

출시된 지 시간이 많이 지나서, 플레이어들의 실력 차이가 커지면서 팀사이의 밸런스가 맞지 않는 현상이 자주 발생하는 바람에 최근에는 이 게임에 어느 정도 흥미를 잃었습니다. 하지만, 제가 경험한 Battlefield 2, Battlefield 2142 모두, 제가 플레이해본 게임들 중 최고의 게임들이었습니다. Battlefield의 다음 시리즈를 기대해봅니다.

소프트웨어가 해결하려는 문제가 복잡하다면 그 해결책 즉, 소프트웨어도 복잡해진다. 즉, 소프트웨어의 복잡성은 부정적인 효과를 가지지만, 항상 잘못된 것이고 거절할 수 있는 것은 아니다.

따라서, 소프트웨어의 복잡성 문제를 해결하려고 할 때는 불필요한 소프트웨어의 복잡성(Unnecessary Software Complexity)라는 개념을 가지고 얘기해야한다.

한편, 소프트웨어의 복잡성이 문제의 복잡성에 의존하기 때문에, 문제가 달라지면 불필요한 소프트웨어의 복잡성도 달라진다. 다르게 말하면, 문제가 달라지면, 소프트웨어를 평가하는 기준도 달라질 수 있다는 것이다.

이야기를 하나 해보자. 어떤 소프트웨어 팀은 실제로 많은 문제가 있다고 생각해서, 또는 의욕적이어서 많은 문제를 해결하는 소프트웨어를 만든다. 시간이 지나고, 그런 문제를 해결할 필요가 없어졌고, 사람들은 그런 사실을 잊어버렸다고 해보자. 남아있는 소프트웨어는 그 시점에서 불필요한 소프트웨어의 복잡성이 높은 소프트웨어일테고, 그 소프트웨어의 개발자는 비난을 받는다. 이것은 공평하지 못하다. 소프트웨어 엔지니어링에서 얘기하는 것처럼 문제의 합의에 대한 계약서라도 써놓는 것이 이러한 문제를 해결할까? 그렇지는 않다고 생각한다. 사람들은 '문제가 변화한다'는 사실에 대한 명확한 인식을 가지고 있어야할 뿐만 아니라 '문제를 알고있다'라는 생각에 대해 좀 더 보수적일 필요가 있다.

문제가 언제 변화하냐고? 문제는 항상 변화한다.

생물학자 줄리언 헉슬리(Julian Huxley)는 1912년에 복잡성을 '부분들의 이질성'이라고 정의했는데, 이는 일종의 기능적 불가분성을 뜻한 것이었다. 만들어진 신, 리처드 도킨스

어떤 일을 할 때는 항상 그 일에 맞는 '생각의 틀'이 필요하다. 최근 4개월 가량 소프트웨어 개발에서 완전히 손을 떼고 있었고, 그 생각의 틀을 조금씩 회복하는 중이다. 그러던 중 읽은 복잡성에 관한 정의는 내가 지금 겪고 있는 소프트웨어 복잡성의 문제를 떠올리게 해주었다.

복잡성에 관한 얘기를 할 때, 소프트웨어의 복잡성은 흔히 생물의 복잡성과 함께 취급되곤 한다. 물론, 생물의 복잡성은 소프트웨어의 복잡성에 비교할 수 없을 정도지만, 소프트웨어의 복잡성에 대한 일반인들의 관용은 생물의 복잡성에 대한 관용보다 높지는 않을 듯하다. 하지만, 소프트웨어 엔지니어 입장에서 복잡한 소프트웨어를 바라보았을 때 '손을 댈 수도 없다'는 그 심정은 생물을 다루는 연구자나 중환자의 몸을 다루는 의사의 심정과 크게 다르지 않으리라고 생각한다.

소프트웨어 복잡성의 문제는 다른 과학이나 공학과 마찬가지로, 환원, 특히 기능적 환원으로 해결하는 것이 기본이다. 복잡한 소프트웨어는 하나의 부분을 이해하거나 고치기 위해서는 그 부분과 기능적 불가분의 관계에 있는 여러 부분들을 동시에 이해하고 고쳐야한다. 환원 과정을 통해 프로그래머가 신경써야할 거리를 분리함(separation of concern)으로써, 프로그래머는 한번에 하나의 부분만을 다른 부분과 관계없이 신경쓸 수 있다. 소프트웨어에 있어서는 이러한 과정을 decomposition또는 모듈화(modulization)이라고 부른다. 소프트웨어가 만들어지고 나서 수행하는 decomposition을 특히 리팩토링(refactoring)이라고 부르기도 한다.

생물과 소프트웨어의 또다른 유사성은 바로 계속 변화한다는 것이다. 그리고, 생물이 진화할 수록 그 복잡성이 높아지는 것처럼 (진화의 방향이 항상 복잡도가 높아지는 방향인 것은 아닐테지만, 적어도 현재까지의 생물사에서는 그러했던 것 같다.) 소프트웨어도 성장할될 때마다 복잡성이 높아진다. 생물의 진화는 인위적인 것이 아니므로 복잡성을 '해결'할 필요가 없지만, 소프트웨어의 변화에는 (아직은) 인간의 지적인 능력이 필수적이므로, 복잡성은 소프트웨어가 더이상 성장하는 것을 막는 요인이 되고, 심지어는 소프트웨어의 생명을 짧게 만드는 요인이 되기도 한다. 따라서, 소프트웨어가 오랫동안 성장하기 위해서는 복잡성을 일정 수준 이하로 항상 유지시켜야 하고, 이를 위해서는  decomposition에 더욱 많은 시간을 들이고 자주 해야한다.

소프트웨어 복잡성을 해결하는 과정 못지않게 그것을 인지하는 과정도 중요하다. 복잡성을 인지하지 못하면, 해결하려는 노력을 할 수도 없다. 또한, 복잡성을 인지하지 않고 decomposition을 하려는 노력은 무의미하거나 적어도 비용-효율적이지 못할 수 있다.

소프트웨어 복잡성은 소프트웨어를 만드는 과정 뿐만 아니라 소프트웨어의 결함들을 해결하는 과정 또는 그 원인을 분석하는 과정에서도 인지될 수 있다. 그러한 과정에서 프로그래머가 '너무 복잡하다'고 느끼는 것은 복잡성의 첫번째 징표다.

• 결함 해결 과정에서 너무 많은 부분들이 결함 가능성을 안고 있고 어느 부분에 결함이 있는지 가늠하기 어렵다면 그 소프트웨어는 복잡한 것이다.
• 결함의 원인이 한 부분만의 결함이 아니라 많은 부분들이 서로 영향을 주면서 발생한 결함이라면 그 소프트웨어는 복잡한 것이다.

복잡성을 훌륭하게 해결한 시스템들을 보면 항상 기능적 분화 뿐만 아니라 발생 가능한 결함 자체를 격리한다. 복잡한 시스템들은 그 부분들간에 너무 많은 기능을 서로 의존하고 있을 뿐만 아니라, 설령 기능은 분리되어있다고 하더라도, 발생가능한 결함들은 분리되어있지 않다.

가만히 생각해보면 소프트웨어 디자인이 해결하고자 하는 주요 문제는 결국 복잡성의 해결이다. 성능과 같은 비기능적 요소들은 제약조건에 불과하다. 이를테면, '성능 요건을 xxx만큼 만족시키면서 복잡성을 yyy만큼 해결하는 것'의 문제란 것이다. 대규모 소프트웨어를 높은 수준에서 바라보는 사람은 복잡성에 관한 생각이 반드시 그의 '생각의 틀'에 담겨있어야한다.