UI 디자인과 설계를 다루다보면, 기획업무를 함께 하는 경우가 많습니다. 이런 경우 개발자와 커뮤니케이션을 해야하는데, 대부분은 여기서 문제가 생기죠. 개발자의 이야기가 뭔지도 모르겠고, 그들은 항상 일정과, 기능 부분에서 우선순위를 골라달라 이야기합니다. 아니, 내가 보기에는 다 중요한 기능이고. 일정은 정해져있는데, 나보고 어쩌라는거지? 이럴때마다 개발자들은 화를 내거나. '개발을 알고 이야기하라'는 말을 하곤합니다.
- 개발팀 일정은 생각하고 이야기하는건가요? 그 기획서대로면, 일정 내로는 절대 못 만들어요.
- 이번 버전에서 핵심내용만 개발하고. 이후에 단계별로 업데이트를 하죠.
- 기획을 하는거라면 개발에 대해서 좀 이해를 하고서 이야기를 해야하지않겠어요?
개발자는 왜 안된다고만 할까?
개발자들의 논리는 일반적으로 맞는 말인 경우가 많습니다. 물론 사람의 차이는 있겠지만, 기술에 있어서. 자신이 직접 구현하고, 앞으로도 책임을 져야하는 일이기에. 개발자들의 이야기를 신뢰하는게 가장 우선입니다. 물론, 회사의 기술수준을 파악한 상태라면 이야기가 더 쉬울겁니다. 적어도 상대가 게을러서 그런건지. 아니면 회사의 전반적인 기술 수준이 낮은건지. 다른 업무로 인해 일정이 부족한건지. 체크할 수는 있을테니까요.
- 전체 일정에서 7~80%를 들여도 정상적으로 끝날 수 없는 프로젝트 일정.
- 유지보수를 계약서 상에 넣어, 완성되지 못한 지점을 추가로 돈을 받고 수정해주는 계약.
- 대부분의 IT 프로젝트를 수주하는 회사들이. 이런 방식을 통해 무리한 계약을 합니다.
대부분의 개발 프로젝트는 100의 일정이 있다면. 7~80% 정도를 들여서 개발을 하더라도, 일정 내에 모든 작업이 끝나지 않는 경우가 많습니다. 가장 큰 이유는 한국의 IT 환경이 QA나 충분한 테스트 기간을 생각하기보다. 인력을 갈아넣어 납기일을 맞추는 형태로 이뤄져있기 때문입니다. 그래서 대부분의 개발자들은 주로 야근을 하게되고, 수정사항이 생길 때 마다, 이런 야근은 더 자주, 많이 일어나게됩니다. 경쟁입찰 방식으로 가격을 산정하기 때문에, 어쩔 수 없다는게 회사의 입장이구요.
여기에 회사는 또 한가지 무리수를 두게됩니다. 여러 프로젝트에 한 인원을 동시에 투입하는거죠. 1년에 약 세개의 프로젝트를 진행한다고 했을 때. 한개를 모두 끝내고, 다시 다른 한개로 이동하는 방식이라면, 큰 문제가 없을겁니다. 진짜 문제는 중간에 무언가를 중단하고. 다시 새로운 프로젝트를 하다가, 기존의 작업으로 돌아갸아하는. 분산된 방식을 사용한다는 거죠. 그래서 기존에 진행하던 것들이 뭔지. 개발자 본인도 제대로 기억하지 못하는 문제가 생깁니다.
개발은 비즈니스와 직접적으로 연결되는 경우가 많습니다. 동작하느냐, 그 기능이 있느냐의 문제가 상품의 판매나. 서비스의 시작을 가르기 떄문에. 무엇보다 안정적으로 동작하는 것이 중요합니다. 본인이 짠 코드이지만, 스스로 장담할 수 없는 기간과 내용들을. 한번에 개발해버리고, 다시는 돌아보지않을 거라면 몰라도. 서비스를 지속적으로 운영해야하는 입장에서는 안정성이 매우 중요합니다.
개발자가 바라보는 세상
디자이너나 기획자라면 개발자와 부딛히는 일이 많을겁니다. 그러나 정작 그들이 어떤 식으로 일을 하는지에 대해서는 잘 알지 못하는 경우가 많습니다. 개발자들은 무작정 무언가를 코딩해서 프로그램을 만드는게 아닙니다. 마치 커다란 조립품을 만들듯이. 작은 부품들을 만들고, 모듈화된 기능들을 연결해 커다란 구조를 만들어냅니다. 여기에서 반복되는 구조가 뭐고, 핵심 기능이 뭔지를 구분하는게 매우 중요하죠.
일반적으로 디자이너들은 정보단위나, 설계 단위에서 개발적 관점을 잘 이해하지 못합니다. 서비스의 여러 화면들과 UI 컴포넌트들을 세세하게 다루는 것은 좋아하지만. 그 안에 들어가는 정보들이 실제로 어떤 과정을 거쳐서 서버에 저장되는지. 그 과정에서 필수적으로 필요한 단계나, 기술들이 무엇인지는 거의 생각하지 않죠. 심지어 기획자들도 정보의 우선순위나, 실제 개발에서 바라보는 핵심 기능을 잘 구분하지 못하는 경우가 많습니다.
대부분 기획자나 디자이너들은 화면 단위로 생각을 합니다. 그러나 개발자들은 데이터의 흐름과, 기능을 구현하기 위한 '모듈' 기반으로 생각을 합니다. 어떤 정보를 다룬다고 했을 때, 그게 어디에서 오는지. 그리고 그걸 실제로 구현하기 위해 어떤 기술들을 쓸 것인지. 개발자들은 이런 세세한 내용들을 파악하고, 그 내용을 실로 엮어내듯이. '큰 흐름의 단위와 함께, 실제 그 데이터가 어떻게 연결되는지'를 알고싶어합니다.
- 우선적으로 봐야하는 핵심 기능들이 뭐가 있죠?
- 전체 서비스 플로우 말고, 기능별 플로우차트는 준비되어있나요?
- 그 기능에서 데이터는 어디에서 끌어오는거에요?
- 에러 케이스들은 따로 정리해두신거 맞죠?
일반적으로 디자이너나 기획자는, 화면 중심의 기획을 합니다. 그 화면에는 뭐가 들어가고, 어떤 페이지로 이동을 한다. 그런 내용이 주로 들어가죠. 하지만 개발자의 입장에서는 하나의 데이터가 들어갈 때. 어떤 규격으로, 어떤 제한조건을 가져야하는지. 주요 flow에서 발생할 수 있는 주요 flow와, 에러 케이스들까지. 이 서비스에서 주로 발생할 수 있는 핵심내용들과, 그렇지 않은 내용들을 따로 묶어서 생각하게됩니다.
우리가 생각할 때는 단순한 하나의 화면도. 에러 케이스와, 변형 케이스들까지. 내용을 모두 정의하고 문서화해야. 제대로 개발을 시작할 수 있습니다. 예를 들어 입력창 하나만 하더라도, 어떤 데이터 셋을 입력시킬 수 있게 할건지. 에러 메시지에는 어떤 케이스들이 있는지. 기존 입력 내용을 끌어다가 보여줄 수 있는지 등등. 당장 눈앞에선 보이지않지만. 엄연히 로직 상에는 존재하는 것들. 개발자는 이런 지점들까지 생각을 해야하는 사람들입니다.
반대로 말하면 이런 세세한 지점들을 대부분 빼먹고 디자인, 기획을 하기 때문에. 비어있는 자리를 개발자가 알아서 채우거나. QA 진행시 비어있는 내용들을 하나하나 채우게되는 경우가 많습니다. 대부분의 개발자들은 '어쩔 수 없는 야근과, 추가적인 QA를 하는데 익숙해져 있기 때문에' - 그냥 짜증을 내고 넘어가는 거죠. 하나하나 설명하기에는 '너무 빠져있는게 많기 떄문에, 빠른 업무를 위해 '그냥 넘어가고있다는' 이야기입니다.
내 기획서는 정말 개발을 위한 문서일까?
디자인 파일에서 오탈자나 아이콘이 빠져있는 정도는 사실 애교에 가깝습니다. 세세한 flow까지 모두 체크하지 못하는 기획서. 비어있는 기능들과 제한범위. 개발자가 상상의 나래를 펴서 작업을 해야하는 '엉터리 기획서'가 문제를 만드는 가장 큰 원인입니다. 그러나 대부분의 경우 기획자들은 개발자들과 밀접하게 대화를 나누지 않습니다. 부서가 다르고, 일정 관련 문제로 인해, 이런 문제들은 표면상에 드러나지 않게되죠. 그래서 개발팀 내부의 자료검토 + 자체적인 데이터 구조 설계 등으로 메워지기 마련입니다.
기획 과정에서 비어있는 내용이 많아지니, 디자이너 역시도 전체 flow를 이해하지 못하는 경우가 많습니다. 그러니 화면 단위에 자꾸만 집착하게됩니다. 그렇게 작업을 하다가, 실제 화면을 만들고, 프로토타이핑을 통해 flow 검증을 하고 나서야 이 문제를 확인하게되죠. 그러면 서비스 flow에 문제가 있다는걸 알게되니, 기획서가 바뀌어야하고. 다시 개발자는 이 내용을 반영하기 위해, 뼈대를 수정해야하는 과정이 생기는 겁니다.
개발을 이해하지 못하면 기획을 할 수 없습니다. 그러나 개발을 제대로 이해한다면 차라리 개발을 하지, 기획자가 될 필요가 없죠. 한국 IT 업계에서 제대로된 기획자를 찾아보기 어려운 이유도 여기에 있습니다. 그래서 요즘은 기획자의 역할과, 화면단위 설계를 함꼐 다루는 UI 디자이너들이 많이 늘어나고있지만. 여전히 개발자가 믿고 맡길만큼 자세한 스펙을 이해하는 사람은 별로 많지 않죠. 전체 프로젝트 일정의 7~80%를 다뤄야하는 사람의 입장에서. 군데군데 내용이 비어있는 기획서를 받아보게된다면. 어떤 기분이 들까요?
네. 그래서 개발자들은 화를 내게 되는 겁니다. 상대가 내게 필요한 것들을 전혀 채워주지 못하는데다. 하나하나 가르쳐주기도 복잡한 것들이 많으니까. 그저 감정적인 부딛힘이 일어날 뿐인 거죠.
그건 개발자가 해야하는 일 아니에요?
개발자들 사이에서도 '그저 주어진 대로 코딩을 할 뿐이면, 개발자가 아니다'라는 말이 있습니다. 물론 실제 업무에 필요한 내용이니. 당연하다고 생각할 수 있겠지만. 실제 IT 업계의 개발 기피 현상에 빗대어 바라보면. 문제가 생각보다 심각하다는 걸 알 수 있습니다. 당장 디자이너들만 하더라도. '나는 개발을 다룰 머리는 안되니, 알아서 해주세요' - 라는 태도로 일관하고있지 않나요? 기획자들도 상황은 비슷합니다. '나는 할 일 다 했으니, 부족한 부분은 개발팀에서 채워주세요'라는 식으로 일하는데 익숙해져있진 않은가요?
개발자의 고충, 그리고 분노에는 생각보다 많은 문제가 엮여있습니다. 디자이너는 개발을 모르고, 기획자들도 개발자들이 실제로 하는 일에 대해 자세히 알지 못합니다. 결국 개발자들은 주어진 기획서를 받아보고서. 실제 개발을 위한 자체적인 정보 flow와 설계를 다시 진행합니다. 그러니 결국 기획에 비어있는 내용을 개발자들이 상상해서 처리해야하는 구조이고. 결국 그걸 테스트한 이후에, 빠져있는 부분을 메우는 것도 개발자들의 몫이 되죠. 이러니 QA를 흐지부지 처리해버리고, 유지보수를 계약을 추가하는 것이 현실이 된 겁니다.
분명 IT 업계에도 제대로 공부하고, 개발적인 관점까지 다루고있는 기획자분들이 계실겁니다. 하지만 세상에는 그런 모범적인 사람들만 살고있는게 아니죠. 수많은 디자이너들과 기획자들이 '내 할 일만 해도 바빠 죽겠다'며 자신의 역할을 제한하고있고. 여전히 개발자들은 높은 연봉을 받는 대신 야근과 주말 근무를 강요받고있죠. 물론 모든 개발자가 뛰어난 실력을 갖고있는게 아니라는 것도 맞는 말입니다. 다만 '개발자가 아닌 이들이, 과연 개발을 위해 충분한 정보를 제공하고있는가'는 다시 한 번 생각해봐야할 문제입니다.
그렇게 잘 알면 내가 개발자를 하고 만다 (?)
제가 이야기한 케이스가 모든 회사에 들어맞지는 않을겁니다. 하지만 적어도 6~7년간 여러 IT 업체에서 일하면서. 반복적으로 겪었던 '개발에 대한 이해부족'과 '내가 할 일이 아니다'라는 태도가. 여러 문제를 만드는걸 확인해왔습니다. 그리고 여러 개발자분들과의 대화에서 반복되는 주제이기도 했죠. UI 디자이너와 기획자들이 설 자리가 계속 좁아지고있는 현실에서. '개발자를 위한 기획'이란게 대체 뭔지. 그리고 나는 과연 제대로 일을 하고 있는건지. 다시 한번 상황을 돌아보게 됩니다.
왜 UI 디자인과 기획을 가르치는 학교와 학원에서는 이런 지점들을 다루지 않았을까요? 왜 항상 화면 단위의 설계만을 우선시하고. 실제로 그걸 구현하는 입장과, QA를 하는 관점에서. 더 자세한 지점까지 기획서를 제작하거나. 개발자의 관점에서 필요한 로직들까지. 더 깊숙한 지점까지 다루려는 사람이 많지 않은 걸까요? UI 디자인을 다뤄온 사람 입장에서, 과연 이 문제가 '그건 내 일이 아니다'라고 말하며. 넘어갈 수 있는 지점인건지. 좀 더 깊은 고민이 필요한 시점인듯 합니다.
리플러스의 UD LAB에 대해 더 궁금하시다면, 다음 링크를 확인해보세요!
UD LAB - 이용안내
안녕하세요, 리플러스입니다. UD LAB (구 UI 디자인 연구소)은 UI 디자인과, IT 생태계를 집중적으로 다루고있는 커뮤니티입니다. 크게 단톡방과 디스코드 채널로 이루어져있으며, 주기적으로 디스
udlab.tistory.com
'IT 상식' 카테고리의 다른 글
| VPN 이란 무엇인가? (0) | 2021.03.18 |
|---|---|
| IT 상식 : 구글의 마케팅 핵심 키워드 2021 (0) | 2021.02.05 |
| IT 상식 : 데이터가 만들어지는 3가지 방식 (0) | 2021.02.02 |
| IT 상식 : 회사의 기술 수준을 파악하는 방법 (0) | 2021.01.31 |
댓글