특별한주제/게임
개발은 개발 분야 간의 투쟁입니다.
Namu(南無)
2004. 12. 23. 00:25
어떤 서비스, 프로덕트를 개발한다는 것은 각 세부 분야 간의 투쟁과 협력에 의해서 이루어진다고 저는 생각합니다. 그것이 게임인가, 웹 서비스인가, 그것과는 무관하게. 심지어는 그것이 세탁기이던 간에 말입니다.
그 동안 저는 만 3년 간 동안 모 서비스의 개발에서 서비스 디자인을 담당해서 개발 업무를 진행하고 있었습니다. 클라이언트/서버에서 웹 서비스로 도중 플랫폼을 변경한 바가 있는 서비스였습니다. 초기 1년 반 정도는 유지와 보수, 후기 1년 반 정도는 새로운 서비스로의 기획과 개발 진행이었던 것으로 기억합니다. 이렇게 이야기하니 먼 옛날 같지만, 고작 몇년 안된 이야기입니다.
일반적으로 웹 서비스를 개발한다고 했을 때, 크게 나누면 서비스 디자인, 웹 개발, 서버 R&D, 클라이언트(어플리케이션, ActiveX), 웹 디자인 등으로 나뉩니다. 이때 각 분야는 투쟁하고 그러면서 협력할 수 밖에 없습니다. 최대한 각 분야는 자신의 일을 줄이길 바라고, 각 분야는 최대한 책임을 지고 싶어하지 않습니다. 그것이 절대 나쁜 것이 아니라 각 분야는 그렇게 할 수 밖에 없습니다. 그럴 때 그 분야가 서로 협력하여 그것을 책임과 일을 나누게 되는 것이겠지요.
이럴 때 그 일과 책임을 나누는 것은 서로의 봉사 정신도 아니고 꿈과 열정도 아니고, 그것은 개발 프로세스와 관련이 됩니다. 어느 쪽에서 아이디어를 내놓고 구체화하고 실현 계획을 세우고 그것을 바탕으로 실제 개발에 들어가게 되는 것이겠죠. 그러면서 일이 나누어지고 그에 따라 책임이 나누어지는 것이라 봅니다.
문제는, 이런 프로세스가 옳바르지 않았을 때 서로 옳지않은 분쟁이 생기고 서로를 믿지 못 하는 사태가 발생할 것입니다. 하지만, 그나마 이것을 서로 인식하고 인정하는 것은 괜찮습니다. 여기에서 그것을 무시하고 그것에서 눈을 돌리는 순간 그 개발 프로젝트는 문제의 더미로 빠져들게 됩니다.
이런 문제는 언제나 발생하고 그때 그것을 바라보고 해결을 하려 들어야지, 귀찮거나 마음이 상할까봐 해결하지 않으면 그 문제는 점점 커져 되돌리기 어렵게 됩니다. 이럴 때, 이런 문제를 해결하기 쉬운 프로세스의 예를 들어볼까 합니다.
만약, 웹 서비스를 개발한다면?
1단계 프로젝트의 컨셉 공유
처음, 어떤 서비스를 개발할 것인가 그 컨셉과 개략적인 계획을 짜고, 그 계획을 적절하게 모든 프로젝트 구성원에게 알립니다. 모두 이해할 수 없고 모두 이해할 필요는 없습니다. 다만 모두 알고는 있어야 합니다. 그 내용을 잘못 알고 있다면 그것은 문제가 됩니다.
2단계 프로젝트 계획의 작성
일정과 인원 배치, 비용 산정부터 프로젝트 진행에 있어 어떤 방법으로 각 분야가 서로 협의할 것인가 그것이 결정되야 합니다. 앞 부분은 돈에 관련된 부분이라면 뒷 부분은 서로의 커뮤니케이션 방법의 정의입니다. 이때 일반적으로 서비스 디자인이 서비스의 내용을 정의하고 그것을 구현하기 위해 각종 문서 작성을 한 뒤 각 분야와 이야기를 합니다. 먼저 서버 R&D와 협의하고, 그 표현을 위해 웹 개발과 협의하고 그것을 어떻게 디자인할 것인가는 웹 디자인과 동시에 진행하게 됩니다.
3단계 프로젝트의 개발
2단계에서 정의된 방법론에 의해 협의하고 문제 발생시 계속 계획을 맞춰 가게 됩니다. 이 단계가 바로 투쟁과 협력의 단계이고 이에 따라 각기 분야를 담당하고 담당끼리 투쟁과 협력을 하게 됩니다. 이른바 아수라장이며, 여기서 어디로 튈지 모르는 것이겠죠. 3단계가 그래서 어렵고 힘들지만, 1,2단계를 잘 잡는다면 그 만큼 3단계가 수월해지니 그만큼 앞 단계가 중요할 것입니다.
4단계 프로젝트의 QA
프로젝트 개발 완료가 가까워짐에 따라 그 프로덕트가 잘 구성되있고 문제가 없는가를 확인할 필요가 있습니다. 이 단계는 프로덕트에 대한 체크리스트를 프로젝트 개발 쪽에서 작성하여 그 체크리스트에 대해 QA 부문에서 체크를 해나가게 됩니다. 이 체크리스트는 초기 2단계에서 어느 정도 바탕이 짜이고 3단계를 거쳐 구체화가 되는 것으로, 이것이 부실하면 QA가 부실하게 되고 그 만큼 오픈 이후에 문제를 양산하게 됩니다. 미리미리 준비하여 챙기도록 합시다.
5단계 프로젝트 오픈
이 이후는 사용자와의 싸움입니다. 어디로 튈지 모르고 어떤 행동을 할지 모르는 사용자를 대상으로 그에 대해 대응하고 문제를 해결해야 합니다. 이 부분은 직접 부딛혀본 자만이 해결할 수 있는 부분이라 직접 겪어보시길 권합니다.
의도적으로 게임 개발이 아니라 웹 서비스 개발로 쪼개보았지만, 이미 게임 개발에 몸을 담고 있는 분이라면 이것이 그것과 큰 차이가 없다는 것을 아실 수 있을 듯 합니다. 언젠가 제가 게임 개발 부문에서 더 많은 일을 겪게 된다면, 이에 대해서 이야기해보고 싶습니다. 그 이전까지는 제가 경험한 것을 바탕으로 저 투쟁의 결과를 이야기해볼까 합니다.
그 동안 저는 만 3년 간 동안 모 서비스의 개발에서 서비스 디자인을 담당해서 개발 업무를 진행하고 있었습니다. 클라이언트/서버에서 웹 서비스로 도중 플랫폼을 변경한 바가 있는 서비스였습니다. 초기 1년 반 정도는 유지와 보수, 후기 1년 반 정도는 새로운 서비스로의 기획과 개발 진행이었던 것으로 기억합니다. 이렇게 이야기하니 먼 옛날 같지만, 고작 몇년 안된 이야기입니다.
일반적으로 웹 서비스를 개발한다고 했을 때, 크게 나누면 서비스 디자인, 웹 개발, 서버 R&D, 클라이언트(어플리케이션, ActiveX), 웹 디자인 등으로 나뉩니다. 이때 각 분야는 투쟁하고 그러면서 협력할 수 밖에 없습니다. 최대한 각 분야는 자신의 일을 줄이길 바라고, 각 분야는 최대한 책임을 지고 싶어하지 않습니다. 그것이 절대 나쁜 것이 아니라 각 분야는 그렇게 할 수 밖에 없습니다. 그럴 때 그 분야가 서로 협력하여 그것을 책임과 일을 나누게 되는 것이겠지요.
이럴 때 그 일과 책임을 나누는 것은 서로의 봉사 정신도 아니고 꿈과 열정도 아니고, 그것은 개발 프로세스와 관련이 됩니다. 어느 쪽에서 아이디어를 내놓고 구체화하고 실현 계획을 세우고 그것을 바탕으로 실제 개발에 들어가게 되는 것이겠죠. 그러면서 일이 나누어지고 그에 따라 책임이 나누어지는 것이라 봅니다.
문제는, 이런 프로세스가 옳바르지 않았을 때 서로 옳지않은 분쟁이 생기고 서로를 믿지 못 하는 사태가 발생할 것입니다. 하지만, 그나마 이것을 서로 인식하고 인정하는 것은 괜찮습니다. 여기에서 그것을 무시하고 그것에서 눈을 돌리는 순간 그 개발 프로젝트는 문제의 더미로 빠져들게 됩니다.
이런 문제는 언제나 발생하고 그때 그것을 바라보고 해결을 하려 들어야지, 귀찮거나 마음이 상할까봐 해결하지 않으면 그 문제는 점점 커져 되돌리기 어렵게 됩니다. 이럴 때, 이런 문제를 해결하기 쉬운 프로세스의 예를 들어볼까 합니다.
만약, 웹 서비스를 개발한다면?
1단계 프로젝트의 컨셉 공유
처음, 어떤 서비스를 개발할 것인가 그 컨셉과 개략적인 계획을 짜고, 그 계획을 적절하게 모든 프로젝트 구성원에게 알립니다. 모두 이해할 수 없고 모두 이해할 필요는 없습니다. 다만 모두 알고는 있어야 합니다. 그 내용을 잘못 알고 있다면 그것은 문제가 됩니다.
2단계 프로젝트 계획의 작성
일정과 인원 배치, 비용 산정부터 프로젝트 진행에 있어 어떤 방법으로 각 분야가 서로 협의할 것인가 그것이 결정되야 합니다. 앞 부분은 돈에 관련된 부분이라면 뒷 부분은 서로의 커뮤니케이션 방법의 정의입니다. 이때 일반적으로 서비스 디자인이 서비스의 내용을 정의하고 그것을 구현하기 위해 각종 문서 작성을 한 뒤 각 분야와 이야기를 합니다. 먼저 서버 R&D와 협의하고, 그 표현을 위해 웹 개발과 협의하고 그것을 어떻게 디자인할 것인가는 웹 디자인과 동시에 진행하게 됩니다.
3단계 프로젝트의 개발
2단계에서 정의된 방법론에 의해 협의하고 문제 발생시 계속 계획을 맞춰 가게 됩니다. 이 단계가 바로 투쟁과 협력의 단계이고 이에 따라 각기 분야를 담당하고 담당끼리 투쟁과 협력을 하게 됩니다. 이른바 아수라장이며, 여기서 어디로 튈지 모르는 것이겠죠. 3단계가 그래서 어렵고 힘들지만, 1,2단계를 잘 잡는다면 그 만큼 3단계가 수월해지니 그만큼 앞 단계가 중요할 것입니다.
4단계 프로젝트의 QA
프로젝트 개발 완료가 가까워짐에 따라 그 프로덕트가 잘 구성되있고 문제가 없는가를 확인할 필요가 있습니다. 이 단계는 프로덕트에 대한 체크리스트를 프로젝트 개발 쪽에서 작성하여 그 체크리스트에 대해 QA 부문에서 체크를 해나가게 됩니다. 이 체크리스트는 초기 2단계에서 어느 정도 바탕이 짜이고 3단계를 거쳐 구체화가 되는 것으로, 이것이 부실하면 QA가 부실하게 되고 그 만큼 오픈 이후에 문제를 양산하게 됩니다. 미리미리 준비하여 챙기도록 합시다.
5단계 프로젝트 오픈
이 이후는 사용자와의 싸움입니다. 어디로 튈지 모르고 어떤 행동을 할지 모르는 사용자를 대상으로 그에 대해 대응하고 문제를 해결해야 합니다. 이 부분은 직접 부딛혀본 자만이 해결할 수 있는 부분이라 직접 겪어보시길 권합니다.
의도적으로 게임 개발이 아니라 웹 서비스 개발로 쪼개보았지만, 이미 게임 개발에 몸을 담고 있는 분이라면 이것이 그것과 큰 차이가 없다는 것을 아실 수 있을 듯 합니다. 언젠가 제가 게임 개발 부문에서 더 많은 일을 겪게 된다면, 이에 대해서 이야기해보고 싶습니다. 그 이전까지는 제가 경험한 것을 바탕으로 저 투쟁의 결과를 이야기해볼까 합니다.