© rxspawn, 출처 Unsplash
디자인으로부터 코드를 빌드해내는 기술은 다양한 분야에서 연구되어 왔다. UML등 시스템 구조에 대한 논리적인 디자인부터 UI에 대한 시각적 디자인까지, 개발외적인 전문 지식이 반영된 디자인 결과물을 오류없이 낮은 비용으로 코드로 만들어 내는 것이 그 필요성이다. 완전한 코드를 만들어 낼 수 없을지라도 최소한 개발자가 전문 지식에 대한 높은 이해가 없이도 이후 개발을 지속해 나아갈 수 있도록 하는 것만으로도 의미있다.
기존에는 Sketch, Framer, Invision등과 같은 UI 디자인 및 프로토타이핑 도구로 UI를 그리면, Zeplin과 같은 협업 도구를 통해 개발자와 공유되고, 개발자는 UI 디자인을 하나하나 코드로 옮겨야 했다. 하지만 디자인-to-코드 도구를 통한다면 UI디자인을 하면 개발자의 중간 개입 없이 코드를 생성할 수 있다. 사실 발전하고 있는 UI 프로토타이핑 도구를 지켜보고 있노라면 조만간 이러한 도구가 나올 것이라는 것은 예상하기 어려운 일이 아니었다. 그리고 내가 주로 사용하는 모바일 프론트엔드 개발 프레임워크인 React Native에 대해서도 같은 시도가 이루어지고 있다 (참고: https://builderx.io/).
이런 도구를 바라보는 사람들의 머리속에 한가지 생각이 스쳐갈 것이라 예상한다: '프론트엔드 개발자 없이도 앱을 만들 수 있지 않을까?'. 최소한 프론트엔드 개발자의 중요성이 떨어져서 전문성이 떨어지는 적당한 친구로 고용하면 되지 않을까 생각하는 사장님들도 계실 것 같다. 하지만 한동안은 (사실 제법 오래 혹은 영원히) 그 생각은 착각으로 머물러 있으리라 생각한다. 만약 프론트엔드 개발자가 디자인을 그대로 코드로 옮기는 사람이라면 해당 개발자는 자신의 직업이 위태로울 수 있다. 그러나 대부분의 개발자는 그보다 훨씬 많은 일을 하고 있다.
하나 예를 들어보자. 디자인 과정은 사용자 관점의 look and feel과 경험을 창작한다. 그리고 그 결과물엔 당연하게도 시스템적 절차와 상황은 빠져있다. 예를 들어 버튼을 누르는 순간 데이터를 서버로부터 불러와 그래프로 그려주는 화면이 있다고하자. 디자인 상에는 버튼을 누르면 그래프가 그려지는 모습을 보여주면 되지만 그 뒤에는 다른 절차들이 있다. 실제의 모습을 '버튼을 누른다, 서버에 데이터를 요청한다, 응답을 기다린다, 응답받은 데이터를 그래프에 공급한다, 그래프가 데이터를 그린다' 이다. 그리고 그 절차 내에는 네트워크 문제로 요청이 실패 했을 때나 서버 문제로 응답이 실패 했을 때와 같이 예외적 상황과, 데이터가 1개일 때, 2개일 때, …., n개 일 때와 같은 정상적이지만 조건이 다른 상황들이 시스템적으로 반영되어야 한다. 여기에 좀 더 다이나믹을 집어 넣어보자. 만약 버튼을 누를 때마다 새로운 데이터 불러 그래프로 그려야 한다면? 단순한 예시지만 이미 시스템적 절차와 상황은 디자이너와 그 도구가 감당하기 불가능한 수준이 되어간다. 그리고 이러한 절차와 상황을 논리적으로 해석하여 다루는 능력을 지닌 사람을 우리는 개발자라 부른다.
실제로 도구가 '정말 잘' 구현된다면 최소한 디자인된 UI의 레이아웃이나 디자인 등을 그대로 옮기는 비용을 상당히 줄어들지 모른다. 개발자와 프론트엔드 디자이너가 버튼의 미묘한 위치 차이로 다투지 않게 되는 날이 올 수도 있다. 디자이너의 '느낌있는' 에니메이션을 수학적 표현으로 풀어내기 위해 머리가 빠지거나, 혹은 이런 복잡한 작업을 거부하기 위해 극렬히 저항하는 개발자의 모습이 사라질지도 모른다.
만약 도구가 '너무 정말 잘' 구현되어 현재 디자인에 녹아들어가기 어려운 절차와 상황을 상당부분 잘 반영해 낸다면 어떨까? 그럼 이러한 질문을 던져볼 수 있다. 과연 그것은 디자인 도구인가 개발 도구인가? 디자이너가 잘 할것인가, 개발자가 잘 할 것인가? 아마 답은 지금과 다를 것이 없을 것이다. 디자이너가 잘하는 부분은 디자이너가 잘할테고, 개발자가 잘하는 부분은 개발자가 잘 할 것이다. 그냥 도구만 같아졌기 때문에 업무의 연속성이 더 좋아졌을 뿐이다.
결국 디자인-to-코드 도구의 출현은 개발자의 전문성이 도구에 의해 손상되는 것이 아니라, 디자이너와 개발자가 좀 더 자신의 전문성에 집중하게 되는 결과로 이어진다. 오히려 도구와 도구로 생성된 코드를 이해하고 활용할 수 있는 능력이 생산성의 차이를 만들어 낼 것이기에, 프론트엔드 개발자에겐 또 하나의 전문성으로 인정받을 요소일 뿐이다. 그리고 새로운 전문성의 발생은 중단기적으로 해당 개발자의 몸값을 올리는 역할을 하고는 한다. (아쉽지만 사장님의 프론트엔드 개발자 고용 비용을 줄이려는 계획은 한동안 미뤄야 할 것이다.)
그렇기에 프론트엔드 개발자로서 이러한 도구들의 등장을 적지않은 기대감으로 바라보고 있다. 이런한 등장이 프론트엔드의 중요성이 대두되고 있고, 그동안 백엔드에 비해 상대적으로 더뎌왔던 발전이 빠르게 일어나고 있다는 증거로 읽혀 반갑게 느껴지기도 한다. 그러니 기대하는 마음으로 지켜보자. 어떤 도구가 만들어져 우리를 더 편하게하고 가치있게 만들어줄지 말이다.
가입하기
