디자이너와 개발자와 방법론
디자인 방법론
수많은 기업들이 실리콘밸리에서 유행하는 방법론과 업무 방식을 따라가고자 한다. 그들은 많은 시행착오와 연구를 통해 가장 빠르고 효율적이게 업무 할 수 있는 방법을 알아냈기 때문이다. 이 방법론에 대해 이야기해보겠다.
Agile, Waterfall
애자일 방법론이라고 많이 들어봤을 것이다. 애자일 방법론은 다양한 프로젝트 개발 방식 중에 하나이다. 프로젝트를 진행할 때 결정권자, 혹은 클라이언트의 요구사항이 수시로 변화한다는 가정을 하고 이들의 변화에 맞추어 민첩하고 재빠르게 대응하며 업무를 하는 방법에 대한 이론이라고 말할 수 있다. 반면에 Waterfall(폭포수) 방법론은 말 그대로 폭포가 위에서 아래로 떨어지듯이 요구사항을 확인하고 설계한 다음 개발, 테스트 과정을 거쳐 유지보수 단계로 순차 진행하는 방식을 말하는데 앞 단계의 일이 끝나지 않으면 뒷 단계를 수행할 수 없으며, 요구사항이 변경될 경우에는 이 프로세스를 반복해야 하기 때문에 시간과 비용이 매우 늘어난다. 요즘에는 변화를 도모하고자 하는 많은 잘 나가는 기업들이 애자일 방법론을 채택하고 있고 새로 창업한 신생 기업들도 이러한 방식을 도입하고 있다.
디자이너와 개발자의 언어
방법론 전에 디자이너의 역할부터 보자면 디자이너가 필요 없었던 기업에서 서비스의 상용화를 위해 새로 들어온 디자이너의 업무는 무엇부터 해야 할까? 디자이너는 해당 서비스의 정체성과 성격에 들어맞는 디자인 시스템을 구조화시키는 단계에서 시작하기 때문에 초기에 체계적으로 튼튼하게 구조를 쌓아가는 것이 매우 중요하다. 기초공사가 중요하다는 것은 당연히 아는 사실일 것이다. 그 후에는 기초공사를 기반으로 다양한 서비스를 만들어 나갈 텐데 디자이너는 서비스 각 페이지의 Flow를 명확히 하고, 해당 Flow에 맞는 GUI(Graphic user interface)를 적절한 Grouping과 hierarchy에 맞게 배치하여야 한다. 이와 동시에 사용자의 시선을 잡는 Color, Shape, Pattern 등의 아름답고 세련된 Artwork에 대한 지식이 바탕이 되어야 한다. - 모든 설계를 진행할 때 심미성을 잊는다면… 디자이너라 할 수 없다.
WEB, APP의 개발에 있어서 디자이너는 개발자들과 동시간대의 다른 위치에서 많은 시간을 보낸다. 디자이너는 사용자의 시선을 끌고 손쉬운 행동 유도를 위해 노력하지만, 개발자는 실제 그 이야기를 구현함에 있어서 가능한 범위인지, 서버의 조건과 서비스의 광활한 Backstage에서 많은 것을 따져야 된다. - 고객과 서비스가 이루어지는 반대편을 Backstage(무대의 뒤편)라고 표현한다. 이렇게 같은 이야기라도 위치에 따라 보는 시선이 다르다. 때문에 디자이너와 개발자 간의 소통이 매우 중요할 수밖에 없다. 아무리 예쁘게 만들어도 구현을 하지 못하면 그저 보기 좋은 사진일 뿐이다. 이들의 소통이 업무를 완전히 뒤집어 놓을 수 있기 때문에 회사의 타임테이블과 성과를 좌지우지하기도 한다. 그래서 개발자와 디자이너는 일어날 수 있는 모든 경우의 수에 대해 예측하고 준비해야 한다. Miscommunication으로 디자이너가 의도했던 것과 완전히 다른 결과물을 보게 된다면 처음부터 다시 반복해야 하는 불상사가 일어나게 된다.
실제로 개발을 하게 된다면 예상치 못한 변수들이 생기기 마련이다. 나는 조금이라도 프로세스에 변경사항이 생긴다던지, (스타트업의 특징인) 의사결정권자의 마음이 수시로 바뀐다던지 등의 경우에 무조건 회의를 소집하고 변경사항을 정확하게 확인한 뒤에 진행을 한다. 물론 방향이 바뀌지 않게 기획을 탄탄히 하는 것이 가장 좋지만 생각처럼 쉽게 되지 않는다. 디자인과 개발은 업무가 너무나 다르기 때문에 이런 사사로운 변경점은 서로 모를 수밖에 없다. 분명 누군가는 “이 정도는 척하면 척. 이해하고 알아서 할 수 있지 않나?”라고 생각할 수도 있다. 그래도 어쩔 수 없다. 내가 깐깐쟁이가 되더라도 짚고갈 건 짚어야 한다. 간혹 대화와 회의가 어색하다고 피하는 경우가 있는데 회의 소집에 대한 걱정도 할 필요 없다. 소통의 부재로 업무를 몇 번 뒤엎어 봤다면 깐깐한 확인과 검토는 경험으로 자연스레 습득하게 된다. 이때! 애자일 방법론이 매우 유용하게 빛을 발한다!
그렇다면 AIMS에서는?
에임스에서도 애자일 방식을 활용하고 있는데, 처음에 입사하고 업무의 process를 보고 웬만한 기업보다 착실히 애자일 방법론이 스며들어 있어서 놀랐다. 매주 Jira의 스프린트를 활용하여 업무를 진행하고 있었고 Daily scrum으로 role을 정리하며 slack으로 프로젝트별 소통을 관리하고 있었다. 이러한 시스템들은 엔지니어뿐만 아니라 디자이너에게도 매우 유용하고 유연하게 업무를 할 수 있게 도와주고 있었다.
Scrum은 유동적인 상황에 기획-디자인-개발-피드백을 계속 반복하면서 그때그때 필요한 요구사항을 더하고 빼면서 해결해 나아갈 수 있는 장점이 있다. 단, 외주 프로젝트나 에이전시의 경우에는 다소 적용하기 어렵다는 단점이 있지만 스타트업인 에임스는 회사 구조에는 빈번하게 발생하는 요구사항에 기민하게 대응할 수 있어서 매우 유리하게 작용한다. 그리고 이러한 흐름에 맞추어 기존에 사용하던 Sketch를 뒤로하고 요즘 핫한 Figma를 도입하였기 때문에 개발자 - 디자이너 간의 소통이 매우 쉽게 이루어질 수 있다. 실시간으로 업무상황을 확인할 수 있고 코멘트를 남길 수 있기 때문이다. 원래 Sketch에서 Figma로의 이주가 힘들고 오래 걸린다고 하지만 나의 경우에는 프로젝트를 새로 시작하는 상황이고 혼자이기 때문에 망설일 이유가 없었다. Scrum과 Figma는 바로바로 검토를 할 수 있어서 업무 속도가 뒤쳐지거나 다른 방향으로 가는 것을 바로잡기에 아주 적절한 방식이다.
실무에서
하지만, 모든 것에는 단점이 있기 마련이다. 이렇게 그럴싸해 보이는 방법론과 프로그램이 있지만 정말 실무에 적용할 수 있느냐가 관건이다. 아직 이런 문화가 익숙하지 않아서인지 많은 기업들이 제대로 적용을 못하고 있다고 한다. 우선 애자일 방법론은 직원 모두가 인지하고 함께 움직여야 효과가 있는데 전 직원이 따르기엔 한국의 문화적 특성과 새로 도입되는 방법론이 당장 업무에 적용되기에 다소 무리가 있다고 생각한다. 하루빨리 완벽하게 완성된 결과물을 보아야 한다는 생각과 업무가 무한 수정이 된다는 단점들이 더욱 업무를 혼란스럽게 만들기 때문이다.
하루하루 급변하는 기술과 웹, 앱 트렌드의 소용돌이 속에서 우리는 현재 과도기적 위치에 있다고 생각한다. 컴퓨터와 인간 사이의 연결점을 만들어주는 21세기 신문물의 직업인 만큼 기존의 문화와 업무방식은 바뀌어야 한다고 생각한다. 불필요한 보고와 내부의 컨펌, 형식적인 회의들은 우리들의 업무와 어딘가 맞지 않기 때문이다. 나는 결코 부정적으로 생각하지 않는다. 여기는 통신과 모바일의 강국이다. 이렇게 불편함을 인지하고, 새로운 방법론과 더 효율적으로 일하고 싶은 욕구를 계속 갖고 새로운 변화에 대한 두려움에 맞서 부딪히면 언젠간 우리에게 맞는 업무방식이 정착하여 수출이 될지도 모르는 일이다.
다음 편에서는 잠시 쉬어가며 가볍게 이야기할 수 있는 디자인 관련 주제를 적어보도록 하겠습니다 :)