디자인(design)과 기획(design)과 설계(design) #1 |
 |
이전 글 "RIA 프로젝트와 애자일 방법론의 전체팀"에서 기획자, 개발자, 디자이너 간 협업에 대한 이야기를 하며 개발 방법론과 기획 방법론의 통합에 대해 간단히 언급한 바 있는데, 요즘에 이에 대한 고민을 틈틈이 하고 있다. 아직 생각이 설익었지만 일찍 꺼내놓고 독자들과 공유하고자 한다. 이메일이나 블로그 등을 통해 의견을 주고 받으며 서로의 생각을 다듬어갈 수 있기를 희망한다.
디자인, 기획, 설계
디자인, 기획, 설계를 영어에서는 모두 ‘design’이라고 쓴다. 물론 디자인은 "visual design"이나 "art design", 기획은 "product design" 또는 "design", 설계는 "software design" 혹은 "system design" 등으로 명확히 한정하여 표현하기도 한다. 영어권의 IT 관련 글이나 책 제목 등에서 특별한 맥락 없이 "design"이라는 말이 나왔다면 십중팔구 "기획"으로 해석하면 된다. 예를 들어 "Designing for the Social Web"의 번역서 이름은 "소셜 웹 기획"이 되는 식이다.
왜 이렇게 사뭇 다른 분야를 모두 design이라고 부르는 것일까? 헷갈리지는 않을까? 필자는 영어권 문화에 익숙지 않아 실제로 이 사람들이 헷갈려 할지 아닐지 알 수 없다. 하지만 확실한 것은 이 분야들을 모두 design이라고 부를 이유가 있다는 점이다. 필자는 오히려, design을 디자인, 기획, 설계로 나누어 부르는 우리의 언어 습관이 (언어권에 상관없이 이미 존재하는) 지식의 단편화, 분야간 소통의 단절을 심화하는 원인 중 하나라고 생각한다.
최근 몇 년 사이 RIA 기술이 보급되면서 개발 프로세스 상의 변화나 직군 간 협업을 위한 새로운 도구 등에 대해 수요가 늘고 있는데(이미 몇 개 회사에서는 가짜 특효약을 팔고 있다), 이는 분야간 지식의 단편화와 소통의 단절로 인한 오랜 문제가 RIA라는 유행 덕분에 드디어 가시화되는 것일 뿐이라 본다.
시스템 분석가와 기획자
필자는 얼마 전에 "기획자를 위한 객체지향"이라는 공개 강의를 들었다. 게임 기획 공부를 하는 학생들을 대상으로 하는 강의여서 매우 기초적인 내용 위주로 진행되기는 했으나 훌륭한 시도라고 생각한다. 기획과 객체지향이 무슨 상관인가 싶기도 하겠지만 실은 관련이 깊다. 포탈이나 웹 서비스 업계에서 "기획자"가 하는 일을 SI 업계에서는 "시스템 분석가"가 맡아서 하는데, 대부분의 시스템 분석가는 객체지향 방법론 등 다양한 공학적 방법론을 깊이 있게 공부한 사람들이다. 예를 들어 리팩토링으로 유명한 마틴 파울러의 "분석 패턴(Analysis Patterns)"은 시스템 분석가들이 읽어두면 좋을 책이다.
시스템 분석가와 기획자의 역할이 본질적으로는 동일한데 겉보기에 큰 이질감이 느껴지는 이유는 무엇일까? 필자의 경험으로는 이 두 직군의 사람들이 서로 집중하는 부분이 다르기 때문인 것 같다. 시스템 분석가는 논리적 일관성, 비즈니스 문제 해결, 분석 모델과 설계 모델의 관련성 등에 좀 더 관심이 많다면 기획자는 감성적 디자인, 사용 편의성, 대중성 등에 좀 더 많은 관심을 둔다. 하나의 시스템은 본질적으로 인간과 기계의 상호작용(HCI)으로 이루어진다는 관점에서 볼 때 시스템 분석가는 기계의 입장에 치우쳐 있고, 기획자는 인간의 입장에 치우쳐 있는 것이 아닐까?
최근 S사나 L사 등 대형 SI 업계에서도 감성 디자인이나 UX 등을 고민하기 시작했다는 소식을 들었는데 크게 환영할 일이다. 시스템 분석가와 기획자의 관심사가 적절히 섞일 수 있는 좋은 기회다. 단, SI 프로젝트에 특정 RIA 솔루션을 끼워 팔기 위한 상술에 그치는 것이 아니라면.
공통점 찾기 – 소프트웨어 설계의 관점에서
그래서 디자인과 기획과 설계의 공통점이 무엇인가? 우리는 서로 무엇을 공유할 것인가? 필자는 다른 분야보다는 프로그래밍에 경험이 많기 때문에 소프트웨어 설계 관점에서 디자인과 기획 분야에 무엇을 줄 것인가를 주로 고민한다.
나름대로 다양한 언어를 공부하고, 다양한 기술 도메인과 업무 도메인에서, 다양한 방식으로 일해온 경험을 돌이켜볼 때 프로그래머(또는 소프트웨어 분석가나 설계자)가 프로그래밍이라는 좁은 분야를 넘어서 기획자나 디자이너에게 전해줄 수 있는 가장 값진 보물은 복잡한 시스템을 다루는 기술이 아닐까 싶다.
돌이켜보면 프로그래밍의 역사는 복잡성을 효과적으로 다루기 위한 사고의 발전 과정으로 볼 수 있다. 복잡한 논리의 흐름을 몇 가지 기본적인 제어 구조로 분해하는 방법(structured programming theorem), 거대한 시스템을 작은 모듈들로 나누는 효과적인 방법(modular programming), 시스템을 객체 간 메시지 교환이라는 관점에서 풀어내는 방법(object oriented programming), 시스템의 다차원적 관심사(concern)를 식별하고 각각을 모듈화하는 방법(aspect oriented programming), 이러한 사고 방식을 적절히 표현하기 위한 시각화 언어(UML) 등이 그러한 발전 과정에서 나타났다.
필자는 이러한 지식을 기획자, 디자이너 들과 나누고 싶다. 하지만 아직 공부도 부족하고 고민과 경험도 부족한지라 적절한 방법을 찾지 못하고 있다. 이런 저런 책과 논문을 통해 많은 영감을 얻고 있지만 글로 풀어낼 만큼 충분히 체계화되지 않았다. 현재 가장 큰 영감을 주는 책은 수십 년간 MIT의 교재로 쓰였다는 “컴퓨터 프로그램의 구조와 해석(Structure and Interpretation of Computer Programs)”이다. 이 책에 의하면 프로그래밍은 단순히 컴퓨터에 일을 시키는 수단일 뿐 아니라 인간을 위한 사고의 도구이기도 하다.
우리가 만들어야 할 소프트웨어는 점점 더 복잡해지고 있다. 웹 2.0 이후 소셜 네트워킹이나 집단 지성 등의 키워드가 유행하면서 우리가 다뤄야 할 시스템의 범위는 고립된 개인과 컴퓨터 사이의 상호작용을 넘어서 사회와 컴퓨터 네트워크의 상호작용으로 확대되었다. 우리에게는 복잡한 시스템을 효과적으로 다루기 위한 사고의 도구가 필요하다. 설계자(software designer)가 기획자(product designer)와 디자이너(visual designer)에게 기여할 수 있는 한 가지 길이 여기에 있다고 믿는다.
이 문서 북마킹 하기
 [지난 developerWorks Column 보기]
|
강규영 
