개발자 없이 IT 서비스를 만들 수 있을까요? 상상하기 어렵습니다. 서비스들은 모두 컴퓨터나 핸드폰에서 작동하니까요. 그러면, 디자이너 없이 서비스를 만들 수 있을까요? 가능은 하겠지만, 근사한 서비스를 만들긴 어려워 보입니다. 서비스 기획자 없이 서비스를 만드는 건요? 왠지 그럴싸해 보이지만 이 또한 쉽지 않을 것입니다. ‘통제’의 역할을 충실히 수행하는 기획자가 있는 팀과 없는 팀의 안정성은 천지차이니까요.
자원(인력, 지원, 비용 등) 결핍을 이유로 우리 팀에 어떤 역할이 하나 빠진다면, 누군가는 그 역할을 대신해야 할 것입니다. 같은 이유로 어떤 역할이 없는 채로 돌아가고 있는 팀이라면, 누군가 그 빈자리를 채우고 있을 가능성이 높습니다.
모든 기술이 내 손에
지금까지는 이렇게 누군가의 빈자리를 채우는 건 쉽지 않았습니다. 전문가들은 대부분 자신의 분야에 신경 쓰기 급급했기 때문입니다. 이는 폐쇄적인 기술공유로부터 기인합니다. 커뮤니티가 지금만큼 발달되지 않았고, 전문지식은 개인 혹은 소수의 단체에만 조용하게 공유되어 왔습니다. 기술은 여러 스페셜리스트의 협업으로 개발되었고, 융합 지식을 가진 전문가는 지금보다 적었습니다.
기술의 발전은 서로 유사한 전문지식 사이 세워진 벽에 작은 틈을 냈습니다. 손가락 하나 들어갈만한 구멍은 조그마한 관심으로 시작되어 관음증으로 이어집니다. 서서히 벽은 부서지고, 커뮤니티는 순식간에 팽창했습니다. 기술의 경계가 흐려지고 생산성이 급격하게 향상되기 시작했습니다. 반대로 생산성 향상으로 인해 만들어진 잉여시간이 기술의 경계를 허물었다고 할 수도 있습니다.
어찌 되었든, 2024년 기준 IT 분야는 과거에 비해 기술 간의 경계가 더욱 흐려졌고, 생산성은 눈에 띄게 향상되었습니다.
그런데 기술의 경계가 무너지는 것이 어째서 생상성 향상으로 이어지는 걸까요? 이는 90년대 TV에서 방영했던 “가족오락관”이라는 방송의 “고요 속의 외침”을 생각해 보면 이해하기 쉽습니다. 참가자들은 시끄러운 소리가 나오는 헤드셋을 착용하고, 옆에 있는 사람에게 ‘지시어’를 전달합니다. 불분명한 입모양과 소음을 뚫고, 지시어가 엉성하게 전달됩니다.
이렇게 몇 사람을 거치면서 개구리가 뻐꾸기가 되고, 뻐꾸기가 며느리가 되는 이상한 풍경이 연출합니다. 이것이 ‘소통 비용(Communication Cost)’입니다. 여러 사람이 일할 때에는 필연적으로 소통 비용이 발생합니다. 여러 분야의 지식을 가진 전문가가 협업하면, 소통 비용을 최소화할 수 있습니다. 이 모습은 서로 동일한 일을 한다기보다는, 발로 공을 차지만 서로의 포지션에서 최고의 호흡을 만들어내는 축구팀을 상상하면 좋을 것 같습니다.
자, 처음의 질문을 조금 바꿔보겠습니다. 만약 기획자, 개발자, 디자이너 셋 중 한 명이 혼자서 서비스를 만들어야 하는 상황이라면 누가 가장 ‘상품’에 가까운 결과물을 낼 수 있을까요? 사실 이것은 아주 어리석은 질문이고 주어진 보기에는 정답도 없습니다. 가장 ‘서비스’에 관심이 많은 사람이 결국 ‘상품’에 가까운 결과물을 만들어낼 테니까요. 그 말은 즉, 관심이 있다면 누구라도 ‘Product’를 만들어낼 수 있는 세상이 되었다는 것입니다.
‘서비스 기획’은 서비스를 만들고 싶은 자의 몫
1) 디자이너의 영역을 벗어난 디자인 도구
지식은 더 빨리 더 멀리 공유될 것입니다. 생산성은 지수함수처럼 한동안은 더 가파르게 향상될 것입니다. 생산성 도구 ‘Figma’는 론칭한 지 10년도 안되었습니다. UI 디자인 툴로 시작한 피그마는 기획과 디자인의 경계를 허물다 못해 개발자를 위한 강력한 도구까지 지원하게 되었습니다. 지난 2024년 3월 15일 서울에서 “Figma Design & Dev Leaders Meetup”행사가 열렸습니다.
창업자인 ‘딜런 필드(Dylan Field)’의 세션도 들어볼 수 있었는데요. 딜런 필드는 ‘Product’를 만드는 모든 이를 위한 피그마에 대해 이야기했습니다. 실제로 피그마를 사용하는 유저의 70%는 디자이너가 아니라고 밝혔습니다. 그 시작이 디자인 툴이었단 것을 생각하면 아이러니합니다.
피그마에는 당장 코드로 출력해서 Product에 적용할 수 있도록 설계된 툴도 많습니다. 피그마가 퍼블리셔의 자리를 90% 이상 대체하게 된 것입니다. 단순히 “눈에 보이는 부분”만 이야기하자면, 프런트 엔드개발자의 자리 또한 상당 부분 대체하게 되었습니다.
2) 누구나 이해할 수 있는 관계형 데이터 베이스
‘데이터’ 또한 대부분의 작업자들에게 생소하지 않습니다. ‘구글 스프레드 시트’는 공유 가능한 ‘표’를 제공했습니다. 얼마 지나지 않아 ‘스프레드 시트’는 App script, 시트에서 사용 가능한 query 및 다양한 플러그인들을 통해 누구나 접근 가능한 ‘관계형 데이터 베이스’의 형태를 갖추기 시작했습니다. 아예 이런 용도로 특화된 ‘Airtable‘과 같은 도구도 등장했습니다.
데이터 베이스 설계나나 쿼리에 대한 깊은 지식 없이도 간단한 데이터베이스를 만들 수 있게 된 것입니다. 비개발자 입장에서는 고객과 상호작용할 수 있는 서비스의 DB를 구축하거나, 영업 관리를 위한 CRM 도구를 구축하는 등 다양한 도움을 받을 수 있습니다. 개발자 입장에서도 이러한 도구는 유효합니다. 별도의 서버 구축 없이 간편하게 다른 서비스와 데이터를 주고받는 환경을 만들 수 있기 때문입니다.
3) 슬랙이 구글 스프레드 시트를 만났을 때
데이터 베이스는 서비스 간 통합 도구인 (Intergation Tool) “Zapier”나 “Make”와 같은 서비스를 만났을 때, 만개한 꽃이 됩니다. 이 도구들은 Slack, Google, Jira, Meta 등 인지도 높은 서비스들 간의 통합을 쉽게 도와줄 뿐만 아니라, 웹훅이나 호스팅을 활용해 공개된 API까지도 활용할 수 있도록 합니다.
고객으로부터 온 요청을 슬랙의 특정 채널에 전송하고, 구글 스프레드 시트에 추가하는 형태를 상상하면 됩니다. 만약 이렇게 수집한 정보들을 데이터 베이스화 한다면, Air table이나 스프레드 시트의 App script를 활용하여 보다 적극적인 통합 작업을 할 수 있습니다.
공공기관에서 제공하는 Open API 또한 손쉽게 활용할 수 있습니다. 워크넷의 채용정보나 기상청이 제공하는 정보를 지속적으로 수집하는 형태입니다. 만약 내게 꼭 맞는 채용정보를 찾거나, 이상 기온이 발생하면 메시지나 이메일로 받아볼 수 있는 구성도 가능합니다.
4) 코드 없이 개발하는 서비스
그리고, 대미를 장식하는 것은 노코드 퍼블리싱입니다. 코드 없이 고객과 대면할 수 있는 서비스를 만드는 것은 정말 놀라운 일입니다. 단 한 줄의 코드 없이 고객과 소통할 수 있는 화면을 제작할 수 있습니다. 노코드 퍼블리싱 툴 자체는 굉장히 오래전부터 존재했습니다. Adobe의 ‘드림위버’ 라든가, 90년대에 초등학교를 다녔던 분들에게는 익숙한 ‘나모 웹에디터’와 같은 형태로 말입니다.
과거의 노코드 도구들은 한계가 분명했습니다. 우선 기능적인 한계가 뚜렷했습니다. 제한적인 환경에서 작동했고, 웹표준을 지키기 어려웠을뿐더러 성능이 굉장히 부족했습니다. 높은 학습 난이도 또한 큰 문제였습니다. 이런 도구를 배울 바엔 코딩을 제대로 이해하는 게 더 도움이 될 정도였으니까요.
하지만 지금은 아닙니다. 가장 괄목할 만한 것은 비약적인 성능의 향상입니다. 올해 초부터 ‘Framer’를 이용해 여러 사이트를 개발하기 시작했는데요. 스크롤 애니메이션이 개별적으로 동작하다 보니 이런 요소가 많아지면 급격하게 성능이 저하되었습니다. 그 외 애니메이션이나 이펙트 또한 말할 것도 없었습니다. 지연된 이미지 불러오기가 적용되지 않아, 많은 이미지를 사용하는 것 또한 기피되었습니다. 그러나 올해 5월부터 8월까지 3번이나 최적화 업데이트가 적용되었고, 지금은 웬만큼 질 좋은 개발보다 속도가 빠른 것처럼 느껴지기까지 합니다.
배우기도 쉽습니다. 여기엔 디자인 가이드라인을 컴포넌트, 오토 레이아웃 등 다양한 방법을 통해 손쉽게 구현할 수 있도록 한 피그마의 공헌이 있다고 생각됩니다. 프레이머는 피그마와 유사한 UI를 가지고 있어 가끔은 헷갈릴 정도입니다. 피그마는 개발 툴 킷의 활용도가 높아 여러 도구와 연동이 잘 된다는 장점도 있는데, 노코드 퍼블리싱 툴에서도 이는 매우 큰 장점이 됩니다. 피그마의 디자인은 플러그인을 통해 즉시 프레이머, 웹플로우, 버블과 같은 툴로 Import 될 수 있으며, 전환된 결과물의 퀄리티도 상당히 우수합니다.
작성한 디자인을 바탕으로 코드 없이 만들어진 이 사이트에서는, 고객이 회원가입을 통해 정보를 제출하고, 임의의 활동을 할 수 있습니다. 이러한 정보와 활동은 데이터 베이스에 적재되고, 다시 사이트에 고객이 확인할 수 있는 형태로 출력됩니다. 말 그대로 서비스가 되는 것입니다.
물론, 규모 있는 서비스를 만드는 데에는 한계가 있습니다만, 실제 론칭에 앞서 Product market fit을 찾기 위한 방법으로 활용하기에는 매우 적합합니다. 사실 이러한 도구들은 꽤 오래전부터 인지도를 쌓아오고 있었습니다. 최근 들어 이들의 활용도가 매우 높아진 것은 단 하나의 이유, “AI” 때문이라고 단정할 수 있습니다.
AI가 방아쇠를 당겼다
이 모든 것들에 대해 쉽게 말했지만, 사실 쉽지 않습니다. 피그마를 잘 활용하려면 디자인 이해도가 높아야 합니다. 앱스크립트 작성은 어느 정도의 개발지식이 필요하며, 에어 테이블은 별도의 학습이 필요합니다. 재피어와 같은 통합도구 또한 아무리 간단하다고 하더라도 학습이 필요하며, 다양한 도구에 대한 지식이나 관심이 없다면 활용하기 또한 쉽지 않습니다. 노코드 퍼블리싱도 쉽지 않습니다. 어느 정도는 개발의 DNA를 가진 도구들이기에 여러 배경지식이 있을 때 활용도가 높아집니다.
그런데 AI와 함께라면 이런 것들은 크게 문제가 되지 않는 것 같습니다. GPT는 ‘Google App script’에 대한 이해도가 높아, 간단한 요청만으로 원하는 결과물을 만들어줍니다. “고객에게 답변이 오면 이를 정리해서 구글 스프레이드 시트에 추가해 줘. 행이 추가되면 추가된 시간을 6번째 열에 입력해 줘” 와 같은 간단한 요청을 GPT에 입력하면 그걸로 끝입니다. (사실 손을 좀 더 봐야 하지만 굉장히 빠름에는 틀림없습니다.)
통합 도구들 또한 GPT가 없었다면 활용도가 더 낮았을 것입니다. 제가 만든 게임은 5개 국어를 지원하는데, GPT가 없었다면 시도조차 하지 않았을 것입니다.
최근의 AI들은 풍부한 기능의 디자인까지도 알아서 만들어줍니다. 최근 등장한 Creatie AI는 피그마와 유사하지만, AI를 활용한 UI 자동 생성에 더욱 특화된 모습입니다. (2024년 9월 기준, 출시가 연기된 Figma AI와의 대결이 궁금합니다.) 디자인에 소질이 없는 개발자나 기획자가 활용하기 딱 좋겠지요.
이제 서비스를 만들기 위해서는 오직 두 가지만 있으면 됩니다. 목적과 실행력입니다. 뚜렷한 목적을 가지고 만들고 싶은 서비스를 정의하고, 열정적으로 실행하기만 하면 됩니다. 과거에도 그랬다고요? 단언컨대 아닙니다. 과거에는 더 많은 노력과 더 많은 자산과 더 많은 발품 팔이 같은 것들이 필요했습니다.
몇 년 전 처음으로 업무 권태기가 왔다는 글을 쓴 적이 있습니다. 이미 보유한 지식에 비해 새롭게 알아나가는 것이 적기 때문이라고 했었는데요. 제가 틀렸습니다. 지금은 배울 것이 너무나 많습니다. 생각하기를 멈추면, 모든 것이 멈출 것 같습니다. 예전에는 어느 정도 지식과 경험을 쌓고 나면, 여유롭게 다양한 세상을 만날 수 있을 것 같았습니다만, 지금은 여유를 갖게 된 순간 모든 걸 잃을 것 같은 두려움이 듭니다.
누구나 서비스를 만들 수 있는 세상에서 ‘서비스 기획자’라는 직무가 사라질 수도 있을 것 같다는 생각이 들었습니다. 물론 쉽지는 않을 것입니다. 하지만, 생각하기를 멈춘 서비스 기획자라면 정말 사라질 수도 있겠습니다. 아, 생각이 많아지는, 아니 많아져야 하는 밤입니다.
beyes 님의 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
