Irene's Heart Complex

프로젝트 소개

Sissy Fight 3000¹은 게임 디자인 방법론인 MDA 프레임워크와 관련한 실습용 프로젝트이다. 기본적인 게임 시스템은 카드를 이용한 대전 형태의 게임으로, 각 플레이어는 목표 카드Target Card와, 행동 카드Action Card, 그리고 자존심(일종의 HPHealth Point)을 가지고 시작을 하게 되며, 각 턴이 시작 될 때 마다 자신이 선택할 행동(공격, 협동 공격, 방어)에 대한 카드와, 그 행동의 대상이 되는 목표 카드를 제시함으로써 결과를 가늠하는 형태로 진행된다. 최종적으로는 자신의 자존심을 지키고 상대방의 자존심을 0으로 만들어 승리를 쟁취하는 형태의 게임이다. 여기에 한가지 제약 조건이 붙는데 게임 내의 모든 커뮤니케이션은 완전 공개를 원칙으로 한다-즉, 상대에 대한 연합 작전이나 뒷담화도 공개적으로 해야 한다는 규칙이 붙는다.

여학생들의 자존심 싸움이라는 기본 스토리 컨셉을 가지고 있지만, 사실 시커먼 남자들이 게임을 해 보면 여학생들의 생기 발랄함(...) 따위는 전혀 찾아 볼 수 없는데다가, 공개적으로 열려있는 커뮤니케이션 때문에 중상 모략과 각종 간계가 판을 치게 된다. 흡사 플레이어 전부가 조조나 사마의, 제갈공명이라도 된 듯, 서로를 기만하거나, 협력하고 또는 배신하는 형국이 매 턴마다 치열하게 펼쳐지기 때문에 스토리 컨셉과 게임 내용이 대체 맞긴 한건가...? 하는 의심이 들 정도이다. 하지만, 처음 보는 사람들끼리라도, 가벼운 마음으로 진행하기에는 적당한 형태의 게임이기 때문에, 기본 설정 그대로라도 게임은 충분히 재미있고, 즐거운 형태가 될 수 있었다.

프로젝트 팀

2009년 4월 23일 늦은 저녁시간에 열린 제 2회 게임 디자인 워크샵에 참석한 분들의 면면은 프로그래머, 게임 기획, 그래픽 등등 여러 분야의 실무진 분들이 모여있었다. 지인들과 함께 온 분들도 몇몇 있었지만, 대부분은 아마 지금 이 글을 쓰고 있는 본인 처럼 서로를 처음 대면하는 자리였으리라 생각되어진다. 참여자들은 총 4개의 팀으로 랜덤으로 구성되었고, 우리 팀은 나를 포함 총 5명의 인원이 같이 자리에 하게 되었다.

첫번째 연습 게임이 끝나고, 각자 게임에 대한 룰에 대한 파악이 어느정도 끝났을 때 즈음, MDA 프레임워크에 대한 설명과 함께, 각 팀에게는 가상의 '퍼블리셔'의 사업부에서 온 메일 한통이 하나씩 전해 지기 시작했다. 이른바 사업부의 꼬장질(...)이 시작된 것이었는데, 각 팀은 자신의 퍼블리셔의 비위를 맞춰주기 위해 메일에 제시 된 불만 사항을 접수하고 해결해줘야 하는 과제가 주어졌다. 여러가지 과제들-게임의 한 라운드를 1분 이내로 마칠 수 있도록 해 달라던가, 혹은 게임의 커스터마이징이 손쉽게 될 수 있도록 해 달라라는 등-가운데 우리 팀에게는 '게임의 대상 연령인 8세 ~ 13세의 포커스 테스트에서 룰이 지나치게 어렵고 권모술수가 난무하는 게임이라 아이들이 거부감을 느낀다(그러니 좀 어떻게 좀 해 봐 달라, 그리고 우리 딸 애가 애완동물을 너무 좋아하는데... 그냥 그렇다고)'란 과제가 주어졌다. 그리고 주어진 시간은 약 1시간 이내! '젠장, 우리가 개발한 것도 아닌데...'라고 투덜거릴 여유도 없이, 팀원들은 바쁘게 논의에 들어가야 했다.

진행

' 우리가 개발 한 것도 아닌데'였기 때문에 당연히 초반에는 방향을 잃고 해맬 수 밖에 없었다. 처음 게임을 즐겨보고 난 이후에 감상에 대해서 논의가 오가는 도중, 룰의 복잡함에 대한 문제제기가 발생했고, 어린 아이들 대상에서는 복잡한 생각 보다는 게임이 단순하고 순간 순간에 집중 할 수 있도록 해야 할 필요가 있다는 의견이 나왔다. 나는 '공개된 커뮤니케이션 규칙'으로 인하여 어린 아이들이 친구를 속이고 남에게 해를 주는 행동에 대해 부담을 느낄 수 있다고 생각했기 때문에 비공개 커뮤니케이션 혹은 커뮤니케이션 규칙을 없애는 쪽으로 하는 편이 좋다는 의견을 냈고, 이는 바로 받아들여졌다. 이외에도 동시 턴 방식을 순차 턴 방식으로 변환, 상대와 전략에 대한 랜덤 선택 등의 아이디어가 나왔고 첫번째 테스트를 실시 하였다.

• 목표 카드와 행동 카드를 섞어서 테이블 가운데 둔다
• 순차 턴 방식으로 목표 카드와 행동 카드를 한 장씩 뽑아 카드 결과에 따라서 해당하는 플레이어의 자존심을 깎는다
• 공식 커뮤니케이션은 존재하지 않는다

이내 몇 턴이 돌지 않았지만, 직감적으로 다들 '이건 아닌데...'라는 분위기가 팽배했다. 무엇보다 랜덤에 많은 것을 의존한 나머지 머리 싸움에 대한 재미가 심하게 없어져버렸다. 결국 1안은 곧장 폐기되어버렸다. 게임은 다시 순차 턴에서 동시 턴으로 바뀌었고, 카드를 이용하여 행동과 타겟을 선택한다는 것도 다시 살아났다. 게임 플레이 보다는 게임 자체의 UI 쪽에 문제가 있다고 생각한 팀원들은 기본 시스템을 되도록 그대로 가되 복잡함을 야기하는 요소들을 삭제하는 것으로 다시 결정을 내렸다. 이를 통하여 '목표 카드'가 아에 통째로 사라져버렸고, 데미지 계산을 치명적으로 느리게 하는 '협동 공격 카드'를 제거해 버렸다. 대신 목표는 공격하려는 대상을 행동 카드를 제시하면서 상대에게 직접 제시 하는 방식으로 바뀌었다. 그리고 '방어 카드'는 성공 시 완전 방어가 되지만, 1회 사용 이후 버려지는 형태로 바뀌었다.

• 목표 카드 제거: 공격 상대를 직접 가리킨다
• 협동 공격 카드 제거
• 방어 카드: 1회만 사용 가능

이번에는 게임은 스피디하고 단순하게 진행되었지만, 방어 카드가 너무 쉽게 버려지는 문제가 발생했다. 무엇보다 게임 전체 통틀어서 방어 카드를 1회만 사용 할 수 있는 것은 방어 전략을 선택하는 것을 최후까지 미루게 만들어 다이나믹한 전략 구성이라는 본래의 게임의 장점이 무색하게 되어버렸었다. 때문에 이에 대한 보강이 필요하다는 판단이 팀원들 사이에 공감을 얻게 되었고, 방어 카드와 사라진 협동 공격에 대한 룰이 변경되게 되었다.

• 방어 카드는 방어 성공 시 계속 사용. 단, 방어 실패(자신에게 공격이 들어오지 않았는데 방어 카드를 낸 경우)때는 방어 카드를 버리게 된다
• 협동 공격 룰 추가: 별도의 협동 공격 카드를 넣지 않고, 한 사람에게 공격 카드가 2장 이상 들어 올 경우 협동 공격으로 간주. 데미지는 카드 수 * 2로 친다

이제 각 턴 마다 선택 할 수 있는 전략의 폭은 원작에 비하여 그리 줄어들지도 않은 상태에서 전반적인 UI는 단순해진 게임이 되었다. 소기의 목적을 달성했다고 생각한 팀원들은 프로젝트 릴리즈 5분전, 마지막 요구사항(?)인 '그리고 우리 딸 애가 애완동물을 너무 좋아하는데... 그냥 그렇다고'를 해결하기 위한 아이디어를 짜내기 시작했다. 팀원들 중 한 분은 자신이 선택하는 동물 캐릭터에 따라서 체력이나 공격력에 차별화를 두자는 의견을 내놨는데, 나는 이 의견에 대해서는 다음과 같은 이유로 반대를 했다. 첫번째로는 프로젝트 마감 시간이 5분 이내로 남았으며, 두번째로는 게임의 밸런스를 조정해야 될 필요가 있는데 5분이란 시간 동안 이를 해결할 방법은 없다. 마지막으로 (이에 대해서는 이야기 하지 않았지만) 기능을 넣는 아이디어 자체는 좋지만, 그 기능이 게임 플레이에 결정적인 순기능을 할 것이라는 판단이 서질 않는 상태에서 잘못 집어넣으면 게임 시스템만 다시 복잡해 질 우려가 있다는 이유였다. 다른 팀원 분께서도 '테스트로 검증되지 않은 시스템을 마지막에 넣는건 위험하다'라고 하셔서 결국 해당 시스템은 마지막에 철회되었다. 단, 게임의 전체적인 아트 컨셉 부분을 동물들을 보호하는 목자(또는 신)와 휘하의 동물들로 결정하였다. 최종적인 모양새에 있어서 아래와 같은 결과물이 도출되었다.

• 각 플레이어는 두 장의 행동 카드(공격, 방어)와, 10개의 동물 칩(자존심을 동물 형태로 변경하였다)을 가진다
• 10개의 동물 칩을 모두 소진하면 게임에서 지게 된다
• 두 장의 행동 카드 중 공격은 사냥꾼 이미지로, 방어 카드는 목자 이미지로 카드 디자인 컨셉으로 디자인 한다
• 게임 시작 시 각 턴은 '하나, 둘, 빵!' 하는 구호와 함께, 자신의 행동 카드를 제시 하는 형태로 진행한다
• 방어 카드는 자신 앞에 제출, 공격 카드는 공격하는 대상 앞으로 가리키면서 제출한다
• 한 사람 앞에 두 장 이상의 공격 카드가 제시 되는 경우, 이는 '협동 공격'으로 간주되며, 제시된 카드 수 * 2 만큼의 데미지를 얻게 된다
• 방어 성공 시 모든 공격은 무효 처리 된다. 단, 방어 실패(방어 카드를 냈을 때 자신에게 오는 방어 카드가 없을 경우)인 경우 자신의 방어 카드는 버려지게 된다

프로젝트 종료

그리고, 프로젝트 종료를 알리는 외침이 들려왔고, 각 팀의 프로젝트는 일단 종료되었다. 잠깐 동안의 휴식 시간 이후 각 팀에서 각자의 과제에 따라서 진행된 프로젝트 결과물을 다른 팀과 공유하는 시간을 가지게 되었는데, 다들 목표에 충실하게 변경하느라 노력한 흔적이 엿보였다.

우리팀의 프로젝트에 대해 자기 평가를 하자면, 어린 연령의 사용자 층에 집중한 결과 그에 걸맞는 결과물을 냈다고 생각한다. 무언가를 덧붙이는 것 보다 잘라는데 집중을 한 덕분에, 원작의 복잡한 UI는 상당히 개선되었으며, 룰 역시 직관적으로 파악하기 쉬워졌다는 것 역시 좋았다고 본다. 다만, 원작에 있었던 각 플레이어간의 치밀한 심리전은 완벽하게 제거 될 수 밖에 없었는데, 이는 게임을 소비하는 소비층에 따라서 평가가 극단적으로 갈릴 듯 보였다. 그래도 퍼블리셔가 의뢰했던 연령층에는 잘 먹히지 않을까 싶다.

게임 제작 방법론에서 프로토타입Prototype의 중요성은 익히 들어서 알고 있지만, 실제로 경험 할 수 있는 경우는 그다지 많지 않다. 우선적으로 프로토타입을 만드는데 공을 들이는 환경이 그리 많지 않다는 문제점과 더불어, 이런 방법론에 대해서 알고 있는 사람들, 그리고 그 중에서 이를 실천 할 수 있는 위치에 있는 사람들은 정말 극단적으로 소수이기 때문이다. 나 역시도 머리로 막연히 알고 있었던 부분을 실제로 체험해 보면서 일종의 쇼크를 받는 느낌이었는데, 특히 처음 보는 팀 구성원들과 고작 1시간 이내에(그것도몇장의 종이와 몇자루의 펜을 이용해서) 결과물을 만들어냈다는 것 자체가 MDA 프레임워크의 효과를 보여주는 가장 극단적인 부분이 아니었을까?-3년을 같이 일하는 동료와도 제대로 된 게임을 만들어 보지 못한 사람이라면 이것이 무엇을 의미하는지 알 수 있을것이다.

물론 MDA 프레임워크 뿐만 아니라 많은 요소들이 재미있는 게임을 만드는데 중요한 역할을 한다는 것은 자명한 일이지만, 무엇이든 처음 접하고 계속적으로 발전해 나가는 것이 가장 중요하다. 지금 내가 바라는 일은 이 경험을 지금 일하고 있는 회사의 구성원들과 공유하고 좀 더 발전적으로 나갈 계기를 만들었으면 한다. 그리고... 나도 내년에는 GDC를 가고 싶다. (...되도록이면 회사 돈으로 ;;)

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

1. 이 게임에 대한 자세한 내용은 http://sites.google.com/site/gdworkshop/materials/sissyfight-3000 참조 [Back]

Posted by Irene

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by Irene

개인적인 이야기를 먼저 해보자면 사실 게임 업계에 발을 살짝 담근 것은 1999년 초의 어느 추운 겨울날이 시작이었다. 일년 반 정도의 삽질과 후회 그리고 여러가지 경험들을 한 이후, 부족한게 많았다고 판단했었던 나는 한발짝 떨어져 다시 공부를 시작했다. 군대에서 3년 4개월-아는 사람만 아는 공군 장교로 전역했다-이라는 시간을 보내면서 나름 다시 게임 업계에서 일을 할 수 있기를 바라고 있었지만, 여러가지 사정-그 중 큰 것은 아무래도 개인적인 준비 미숙-으로 인하여 그리 쉽지 않은 구직 기간을 보냈었다. 그리고 지금의 회사에서 근무를 하게 되었다.

회사 입사 이후의 초반은 사업 전략 기획을 담당하는 것 부터 시작해서, 기획서 정리, 문서 작업 등의 전반적인 기획 업무를 맡아 처리하게 되었지만, 사내에 존재하는 별개의 게임 제작 프로젝트에 여기 저기 끌려다니면서 정신 없이 일한 것 밖에는 기억이 나질 않는다. 기억나는 일이라고는 이미 정신을 차렸을 때에는 신혼여행을 가는 비행기 안이었다는 것 정도 였으니깐. 여전히 정신을 놓은 상태에서 신혼여행을 다녀왔을 때, 회사에서는 지금의 프로젝트를 담당하라는 지시를 내렸다.

프로젝트 소개

P 프로젝트(가칭)은 국내 모 포탈 회사에서 발주한 Web/RIA(Flash)기반 SNS(Social Network Service)로, 해당 포털 내에 서비스 중인 어린이 맞춤형 포털에서 서비스 되고 있다(2008년 12월 22일 런칭). 기본 컨셉은 게임을 기반으로 한 Virtual World의 구성과 Cyworld의 미니룸과 동일한 개념의 Private 공간 제공, 서비스 전용의 메시지 전달 기능 등을 제공하여 어린이들이 쉽고 간편하게 쓸 수 있으면서 게임 처럼 재미있는 SNS를 만드는 것이다.

사실 프로젝트에 참여하면서 가장 애매모호한 설정이 '게임 처럼 재미있는 SNS'라는 부분이었다. 이미 내가 참여하기 전 부터 몇달간 발주사의 PM과 함께 서비스의 방향에 대해서 많은 논의가 있었던 것으로 전해 들었지만, 여전히 게임이 우선인지 아니면 어린이들이 쓰기 쉬운 SNS가 우선인지에 대한 방향성 조차 제대로 잡히지 않은 상태에서 서로 자신만의 이해를 바탕으로 디자인을 진행시키고 있었다. 지금에 와서 개인적으로 파악하기로는 결국 재미요소가 양념으로 들어가 있는 'SNS'가 원래 목표였던 모양이었던 듯 하다. 다만, '이었던 듯 한' 까닭은 서비스의 기본인 Social Network가 친구 수를 기반으로 한 레벨 업 시스템과 결부 되어 있기 때문에, 입소문을 통한 회원 수 확장을 지나치게 노렸고 때문에 SNS 본연의 서비스 보다는 자기 세력 불리기라는 이상한 모양세가 되어버렸기 떄문이다(발주사 쪽에서는 공공연하게 이를 '피라미드 형 게임'이라고 불렀다.

기본적인 서비스에서의 사용자 행동 양식은 다음과 같았다.

1. 서비스에 가입 한 후, 친구 맺기를 통한 다른 사용자와의 인위적인 관계 설정
   
2. 관계를 맺은 친구들과 메시징, 게임, '여행지'라 불리우는 Virtual World의 사용을 통한 관계 개선
   
3. 수치로 '계산'되는 관계에 따라서 레벨 및 등급의 향상(각 친구간의 친밀도가 높으면 많은 경험치를 받는 구조이다)
   
4. 자신에게 주어지는 집과 정원을 꾸밈으로써 각 개인에 대한 차별화 시도
   
5. '요정'이라는 존재를 삽입하여 육성 게임으로서의 기능 추가
   

프로젝트 참여 - 인력

프 로젝트의 기획은 2007년 12월 경 부터 시작 되었던 것으로 알고 있으며-추정인 것은 회사에 제대로 검토 할 수 있는 개발 데이터가 전혀 남아있지 않기 때문이다-나의 경우에는 2008년 5월 중순 부터 본격적으로 작업에 투입되기 시작했다. 기획이 정리되고 개발이 시작 된 것은 2008년 6월 경 부터였으나, 그때까지 관련하여 투입 된 MM은 기획자 1명 뿐이었고, 커뮤니케이션 문제로 인하여 그 기획마저도 진척이 지지부진한 상황이었다. 내가 프로젝트에 들어온 후 한달 즈음 정도 뒤에, 프로그래밍 팀과 그래픽 팀이 투입 되기 시작하였는데, 주로 웹 어플리케이션이나 아바타 디자인만을 전문적으로 담당했던 인력들이었기 때문에 서로 다른 관점에서 프로젝트를 이해하기 시작한 것이 잘못된 단추를 끼워넣는 첫번째가 되어버렸다. 일단 가장 큰 시각 차를 보였던 것은, 기획팀에서는 프로젝트를 게임으로 규정하고 일을 진행시킨 반면, 직접적인 개발을 담당하고 있던 프로그래밍 팀은 웹 어플리케이션으로 규정하고 서로 상이한 제작 시스템에 대해서는 서로간의 이해도 없이 무조건적으로 자신들이 익숙한 프로세스를 강요하고 있었다는 점이었다-그리고 이 문제는 새로운 프로젝트를 진행할 때에도 발목을 잡고 있다.

프 로젝트 인력 구성은 회사의 사정에 따라 그때 그때 달라졌다. 프로그래밍 팀의 경우, 초기에 무려 7명이나 투입되어 각각 어떠한 조율도 없이 무작정 모듈을 나눠 프로그래밍 작업을 들어가기 시작했다. 코드가 제대로 작동을 하기도 전에 적절한 신송도 없이 관련자들 중 세명이 퇴사, 한명이 다른 프로젝트에 투입되어야 했다. 그나마 남아있던 사람들도 시시 때때로 회사의 결정에 따라서 프로젝트를 한번에 두개, 세개 씩 나가는 경우가 있었고, 심한 경우 QA 기간 중 코드를 수정 할 수 있는 인력이 없어서 그냥 프로젝트를 버려두다시피 하기도 하는 상황도 발생했다.

그래픽 팀의 경우는 프로그래밍 팀 보다 더 사태가 심각했다. 주로 캐릭터나 아바타 디자인을 전문으로 하는 팀이었기 때문에 UI 디자인의 퀄리티는 기대하기 힘들었던 면도 있긴 하지만, 그렇다고 해서 모자란 전문성을 보충 할 여력이 있지도 않았다. 잦은 프로젝트 이외의 업무 때문에 작업과 결과물은 지지부진하기만 했고, 적절한 디자인 가이드가 전혀 없었기 때문에 각 개별 작업자들의 디자인은 전부 제각각 놀고 있었다. 이런 문제들을 더욱 부채질 했던 것은, 프로젝트 팀 내에 아트 디렉터 같은 그래픽 디자인을 총괄하고 책임을 질 만한 인력이 전혀 지정되지 않았었고, 아에 프로젝트 중반에 그래픽 담당 부서가 업무량 과다-그것도 프로젝트가 아닌 다른 업무들 때문에 디자인을 게임 사업부가 아닌 웹 사업부의 디자이너들에게 맡겨야만 하는 일이 발생해 버렸다.

웹 사업부가 전담을 하게 되었다고 해서 사정이 나아진 것은 하나도 없었다. 이들 역시 게임 제작과는 별로 연관이 없는 사람들의 집합이었고, 그들 사업부가 진행하고 있는 프로젝트도 과다하게 많은 상황이었다. 기본적인 플레시 개발에 대한 이해도 없었고 그것을 설명할 여유도 없었기 때문에 항상 프로그래머는 웹 사업부의 결과물에 불만족스러워 했고, 웹 사업부는 웹 사업부 나름대로 반복되는 수정 요구에 지쳐 항의를 하는 모습도 지속적으로 보였었다-그리고 중간 개발 점검에서 그래픽 퀄리티는 발주사의 가장 큰 불만이 되어버렸다.

인력과 관련하여 프로젝트에 가장 큰 위기는 런칭 1달전에 갑작스럽게 끼어든 공공기관 발주 프로젝트(기능성 게임 제작)를 시작하게 되면서 부터였다. 회사의 위험한 재정 상태를 해결하기 위해 급하게 시작된 프로젝트에 PM을 포함한 우리 프로젝트의 모든 인력들이 이 갑작스럽게 끼어든 프로젝트에 모두들 달려들어버렸기 때문에 마지막 QA에 나온 심각한 문제들만 겨우 수정 한 후 서비스가 내포하고 있는 여러가지 문제들은 그대로 안고 서비스를 런칭 할 수 밖에 없었다. M/M이 0이 되어버린 상황에서 복잡하게 꼬여있는 UI나, 용도가 모호하기만 한 기능들을 정리하거나 적절한 수정을 가할 기회를 놓쳐버렸고, 결국 서비스는 런칭 직전(계약상정식 버전이 런칭되어야 함에도 불구하고)에 Beta 버전으로 명명되어 서비스를 시작했다.

인력 문제는 말단이었던 내가 결정할 수 있는 문제도 아니었기도 했지만, 상황을 지켜보면서 안타까운 면이 적지 않았다. 적절하고 확실한 인력 배치가 이루어졌다면 사람들이 자신의 업무에 좀 더 책임감을 가지고 집중을 할 수도 있었지만, 지나치게 잦은 인력 교대와 프로젝트 중복(심한 경우 한 사람이 네 다섯개의 프로젝트에 동시에 참여하고 있는 경우도 발생했다)으로 인하여 각 참여자 전체의 책임감은 함께 분산되어 결국 프로젝트는 아무도 책임지지 않는 상황까지 와 버렸다. 또한, 프로젝트에 대한 집중도도 떨어져 퀄리티 저하라는 치명적인 결과를 불러왔으며, 퀄리티를 높이기 위한 부단한 노력마저도 인력이 없는 문제로 인하여 제대로 손 써 볼 기회마저 상실했다.

회사의 입장에서는 급한 상황을 타개하기 위한 어쩔 수 없는 결정이라고 변명할 지 모르겠지만, 회사의 인적자원 관리 시스템은 분명히 프로젝트를 적절하게 서포트하지 못했고 있었고 그로 인하여 막대한 시간과 금전적 기회비용을 날려버렸다고 생각한다. 다수의 프로젝트를 순차적으로 진행 할 수 있는 프로젝트 팀 조직으로 전환하였다면 한 명의 인력이 다수의 프로젝트를 신경쓰느라 결국 아무런 성과도 내지 못하는 일을 막았을 수 있었을 것이다. 아니 하다못해 조직 개선이 아니라 처음 프로젝트에 참여했던 인력이 끝까지 프로젝트를 진행할 수만 있었다고 하더라도 지금 보다는 좀 더 나은 결과물이 나올 수 있지 않았을까?

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by Irene