데이터의 흐름을 어떻게 가르쳐주어야할까?
FLOW 차트에서부터 시작하는 데이터의 흐름에 대한 예측과 상상
1.
FLOW 차트를 작성하는 시점부터 생기는 몇가지 문제점. 데이터의 저장이나 DB로의 전달 같은 지점을 잘 알지 못하는 사람은, FLOW 차트 작성이 쉽지않다. 일반적인 서비스라면 데이터가 저장되는 시점 같은건 생각하지 않아도 되지만, 커스텀 OS나 키오스크, 변형 설계같은 것들이 들어가면 이야기가 달라진다. 누가 어디에서, 어떤 데이터를 끌고와서 무엇을 다루는지. 데이터가 DB로 전달되는 시점이나 방식이 굉장히 중요해진다. 그런 지점을 개발에 대한 이해도가 없는 팀원에게 설명하려면 어떻게 해야할까?
사실, 가장 좋은 방식은 화면 하나, 버튼 하나에서부터 일일히 설명을 진행하는 것이다. 실제로 개발자들이 기획자와 대화를 하는 과정에서 그러하듯이. 프론트엔드 개발자가 데이터를 백엔드쪽에 던지는 방식. 백엔드가 그걸 캐치해서 DB에 집어넣는 과정들을 일일히 설명하는게 가장 좋은 방식이다. 다만 일반적인 팀원들은 - 프론트엔드와 백엔드의 차이가 어디에서부터 나오는지. 각 플랫폼이 어떤 지점을 다루고있는지를 잘 알지못한다. 그래서 비유나, 축약된 예시같은 것들을 들어주지만. 그것만으로는 충분히 이해를 시킬 수 없다. 그래서 실제 서비스에서 '무슨 화면에서 어떤 버튼을 눌렀을때' 일어나는 과정 같은 것들을 직접 설명해주어야한다.
데이터베이스 (DB)에 데이터가 저장되는 과정을 설명하는 도식QR코드의 동작원리라던가, 4자리 시리얼 코드와 회원 데이터의 1:1 매칭방식이라던가. 개인이 자신임을 증명하는 여러가지 방법론부터, 로그인에 필요한 여러가지 설계방식까지. 데이터가 어떻게 저장되고, 또 어떤 방식을 통해 불러와지는지. 어떤 내용들을 고민해야 좋은 서비스를 만들 수 있는지를 이야기해주어야한다. 그러려면 물론, 일일히 이야기를 하는것 보다는 '그림과 도식화'를 통해서 이야기를 하는것이 훨씬 좋다. 단계별로 어떤 일들이 일어나고, 최종적으로 무슨 결과가 나오는지를 한눈에 볼 수 있기 때문이다.
2.
FLOW차트에서 화면을 상상하는것이 가능한지. 그것을 어떤 방식으로 상상하게 만들 것인지. 이 부분은 아직 내게도 쉽지않은 과제들 중 하나다. 결국 개개인이 여러가지 서비스들의 화면을 얼마나 이해하고있는지에 따라, FLOW차트의 내용만으로 - 화면을 상상할 수 있기 때문이다. 당장 눈에 보이지않는 화면을 상상하면서, 어떤 정보와 기능들이 들어있을지까지. 여러 지점들을 예측하면서 FLOW차트를 작성해야한다. 그러나 이런 방식에 익숙하지 않은 사람들은 '어떤 범위까지'를 FLOW로 표기해야할지. 어떤 기준을 IF 문으로 작성해야할지를 알지 못한다. 그러니 이런 지점들도 - 그 기준점을 명확하게 세워주고, 지속적으로 안내를 해줄 수 밖에 없다.
다만 그런 안내과정에서 - 정확한 기준점을 말해줄 수 있다면 더 좋을거라는 생각은 든다. 일일히 체크해서 체감시켜주는 방식을 넘어서 - FLOW로 표기해야할 정보와, 그렇지 않은 정보가 명확히 나뉜다면. 그 지점도 충분히 개선할 수 있을텐데. 아직까지는 그 방안이 명확하게 떠오르지않는다. 개발자들이 만들어둔 Data Flow에 대한 도식화라도 보여주어야할까? DB설계나 API 목록들을 보여주면 이해할 수 있을까? 사실 이런 지점들을 데이터의 흐름에 대해서라기보다, 구성에 대한 결과값에 가까울것 같다. 그러니 실제 데이터의 흐름에 대해서 이해하려면, 순차적으로 데이터를 주고받고, 체크하는 도식화 형태를 찾는게 가장 편할지도 모르겠다.
은행서비스의 FLOW 예시3.
데이터 하나의 규격에 여러 정보가 묶일수있다는건, 오히려 이해가 쉬울수도 있다. UI디자이너들은 List 형태로 묶여있는 정보들을 자주 다루게되니까. 실제로 데이터를 저장하는 방식도 이런 방식과 마찬가지라는걸 알면, 금방 이해할지도 모르겠다. 서로 '엮이는 지점'을 통해 커다란 데이터 테이블이 만들어지고, 개별 데이터들을 대표하는 Unique ID값이 있다는걸 이야기해주면. 생각보다 빠르게 Table 구조에 대해서 이해하는것 같기는 했다. 다만 다른것이 대체할 수 없는 Unique ID의 개념에 대해서는 여전히 이해가 쉽지않은것 같았다.
여러 테이블을 연결시킨 DB 다이어그램 사례예를 들어 전화번호는 절대로 Unique ID가 될 수 없다. 전화번호를 바꿀 수도 있으니까. 그래서 대부분의 서비스들에서는 이메일 주소를 Unique ID로 사용하거나, 별도의 회원번호 넘버링을 사용하기도 한다. 다만 이 부분이 당장 무엇이 중요한지. 이해하기 어려워하는 경우가 대부분이었다. 가장 큰 이유는 검색시스템에 대한 이해가 없기 때문에, 그 원본격의 Query문이나 정규식에 대해서도 알지못하는 경우가 많았다. 이런 지점들은 결국 '검색'이라는게 어떻게 일어나는지에 대해 알아야. 그 다음 단계의 내용을 이해할 수 있을 것 같다. 다만 이 부분을 '체감하기에는' 너무 추상적인 지점이 많다는게 문제다.
https://brunch.co.kr/@clay1987/349
게다가 이런 내용을 이해하려면 개발자 컨퍼런스까지 이야기를 다뤄야하는데. 대부분의 기획자들은 개발자 컨퍼런스같은건 듣지않는다. 혹은 개별적으로 검색 시스템을 기획해야하는 경험이 없으면, 이 지점까지 다룰 이유가 없다. 하지만 내가 생각하는 기준에서는 '검색시스템'을 알아야 비로소 다른 지점을 이해할 수 있다고 생각한다. 그래서 나중에는 검색시스템이 어떻게 구성되는지. 어떤 방식으로 원하는 결과값을 찾아낼 수 있는지. 백엔드 기준에서 기초교육을 해봐야할 것 같다.
4.
프론트엔드에서 데이터를 저장하는 '입구'를 만드는 방식과, API를 통해 DB에 접속하는 백엔드의 구조같은 것들에 대해서도 다뤄야할것 같다. API에 대해서도 설명은 해뒀지만, 외부에서 끌어오는것 말고, 내부에서 사용되는 API에대해서는 나 스스로도 깔끔한 설명이 되지않는 것 같다. 왜 굳이 API라는 형태로 그부분을 처리해야만 하는건지. 다른 방식으로 데이터를 저장할 수는 없는 건지. 이 지점에서 의문점이 여럿 든다는게 문제다. 또한 API라는 것의 정의가 Restful 형태로 처리되어야하는 이유에 대해서도, 솔직히 깔끔한 답을 내기가 어려웠다. 백엔드 개발자에게 Restful API로 개발해주세요, 라고 말하면서 스스로 명확한 이유를 모르니. 답답함이 생길 수 밖에 없다.
게다가 API 문서를 읽고, 필요한 정보를 파악하는 방식에 대해서도 이야기릃 해봐야한다. 개별 API의 범위가 얼마나 넓은지. 각 데이터를 찾아내는 방법은 어떻게 가르쳐야하는지. API 문서가 제공하는 데이터의 분류들 중 실제 사례를 체크하려면 어떻게 해야하는지. 그걸 발급받고 실제로 사용하기위해서, 어떤 준비과정이 필요한지. Postman 같은 API 테스팅 서비스를 통해서 실제로 구현하는 방식이나. 내가 원하는 정보를 개발자 없이 체크할 수 있는 방법은 없는지. 그런 실무적인 지점을 다뤄봐야할거란 생각을 한다. 단지 그 방법을 내 스스로도 명확히 알지 못하기 때문에, '이걸 이렇게 하면 결과가 나온다'는 이야기를 할 수가 없다. 그러니 또 배워야지. 알려주려면 제대로 배워야한다.
-
내가 아는것들을 다시 글로 표현하고, 명확한 구성을 이야기하기위해 다시 정보를 찾고. 그렇게 반복하다보면 조금 더 똑똑해질 수 있겠지. 시간을 들여서라도 계속 배우고, 고민하고, 더 나은 결과를 만드는게 유일한 방법이다. 새로운 정보를 찾고, 압축해보고, 다시 알려주는 과정을 반복해보자. 적어도 예전의 나보다는 더 나은 결과가 나오겠지.
