제이쓴만 알아도 ‘일잘러 기획자’ 소리 들을 수 있다.
|
기획자: 개발자님, A 유저가 들고 있는 포켓몬 도감 데이터 좀 추출해주세요. { 기획자: 이게 뭐죠..? 엑셀 형식으로 주실 수 있을까요? (대충 우당탕탕 싸우는 소리) |
기획일을 하면서 특정 데이터가 필요할 때 보통 우리는 데이터 사이언티스트나 백엔드 개발자에게 데이터를 요청한다. 최근에는 여러 DB 저장소가 바로 CSV, EXCEL 파일로 추출할 수 있는 기능을 지원하지만, JSON 포맷으로 데이터를 입출력하는 DB 저장소도 많다. (Elasticsearch, MongoDB 등..)
JSON이 무엇인지는 이미 다른 블로그에서 쉽게 찾아볼 수 있으니, 그 부분은 얕게 짚고 넘어가고, 이번 시간에는 기획자/PM이 왜 JSON을 알아야 하고, 언제 JSON을 사용하는지 알아보도록 하자.
JSON과 XML
What is JSON?
JSON(‘제이슨’이라 읽음)은 JavaScript Object Notation의 약자로 우리가 데이터를 저장하거나, 다른 곳에 전송(주로 API)하기 위해 기계와 사람이 동시에 읽기 편한 구조로 되어 있다. XML보다 사람이 더 읽기 쉬우며, 짧고 간결하며, 데이터 처리 속도도 빠르다. 우리가 API를 사용한다고 하면, 이 API로 주고받는 데이터는 JSON 형태로 이루어져 있다고 볼 수 있다.
위 이미지처럼 API는 JSON 데이터를 호출하며, 데이터에 담긴 코드를 Javascript에서 사용할 수 있도록 파싱하는 과정을 거쳐 우리가 흔히 알고 있는 JSON 타입의 형태로 보이게 된다.
JSON 이전의 XML
JSON이 등장하기 이전에 ‘XML’이라는 표기법을 사용해 데이터를 저장 및 전송했다. XML은 ‘eXtensible Markup Language’의 약자로 우리가 웹 환경에서 흔하게 사용하는 HTML처럼 문자 기반의 마크업 언어다. 단, HTML과 달리 데이터를 ‘보여주는 목적’이 아니라, ‘저장하기 위한 목적’으로 만들어졌다. 생김새 역시 HTML과 쏙 빼닮았다. 지금의 JSON과는 매우 다른 모습이다.
XML과 JSON의 차이?
최근에는 XML을 거의 사용하지 않는 추세다. 그러나, JSON은 데이터 무결성을 사용자가 직접 검증해야 하므로, 데이터 검증이 필요한 곳에서는 데이터의 무결성을 검증할 수 있는 XML이 아직도 사용되고 있다. (인터넷뱅킹, 보안기관, 학교 출결시스템 등) XML에 비해 JSON이 워낙 Pretty(진짜로 Pretty JSON이라는 용어가 있다)하기 때문에 XML과 JSON을 비교하는 재밌는 해외 meme를 찾아볼 수 있다.
기획자와 JSON
기획자가 JSON 십분 활용하기
자, 앞에서 JSON이 뭔지, XML과 어떻게 다른지, 왜 중요한지를 가볍게 살펴봤다. 그렇다면, 기획자는 JSON을 언제, 어떻게 사용할까? 우선, 기획자가 실무에서 쉽게 접할 수 있는 JSON 타입을 보자.
인터넷을 켜서 아무 도메인을 들어간 다음, 개발자 도구를 열어 ‘Network’ 창을 보자. jpeg, fetch, webp 타입 파일들이 우르르 쏟아져 나오는 것을 볼 수 있다. 이게 현재 도메인에서 API로 호출되는 파일 리스트다.
그리고 호출된 파일을 클릭하면 이 파일이 어디에서 왔는지(Request URL) 알 수 있다. 여기서 Key-Value 형태의 포맷으로 불러오는 것을 볼 수 있는데, (e.g. Request URL: https://img.~~) 이게 JSON이다. 여기서 Key는 Request URL이고 Value는 하위 링크가 된다.
API 에러 제보 스킬을 늘리는 팁
웹 서비스에 신규 기능을 출시했는데 에러가 뜨는 경우가 있다. 이럴 때 JSON을 아는 기획자와 모르는 기획자는 버그 리포트를 전달하는 방법에서도 차이가 있다. 당연히 JSON 개념을 알고 있다면, 개발자에게 더욱 명확한 에러 원인을 전달할 수 있다.
|
기획자: 개발자님, 이번에 출시한 서비스 ABC 페이지에서 오류가 나요! 개발자: 어떤 오류인가요? 재현할 수 있게 상세하게 알려주세요. 기획자: 어.. 이미지가 안 불러와지던데요? |
만약 어떤 기능(API 호출이 필요한 기능)이 제대로 작동하지 않는 상황을 가정해보자. 아직 JSON의 개념을 모르고, 버그 리포팅 경험이 없는 신입 기획자라면 이렇게 이슈를 제보할 수 있지만, 외부 고객도 아닌 서비스 기획자가 이 정도 수준으로 계속 개발자에게 제보한다면 같이 일하기 싫어질 것이다.
|
기획자: 개발자님, 이번에 출시한 서비스의 ABC 페이지에서 NNN 에러가 납니다. AAA 권한이 있는 BBB 계정으로 접근 시도했고, 지속적으로 API 호출이 안되고 있습니다. 에러가 발생하고 있는 *API Request 헤더와 Payload는 다음과 같습니다. (중략..) Windows 10, Google Chrome 환경에서 테스트했습니다. 개발자: 감사합니다! 버그 원인 파악했습니다. 바로 긴급배포(Hotfix)하겠습니다. |
*API Request 헤더와 Payload Copy 해서 개발자에게 전달하기
자, 어떤 특정 페이지에서 호출 에러가 난다고 했을 때, 개발자 도구 > Network를 보면 이렇게 빨갛게 불이 들어와 있을 것이다. Status Code를 보니 404. 서버 오류인 듯하다. 이 친구가 원인인 듯하니 Request 헤더를 카피에서 개발자에게 전달해주면 된다.
에러가 난 파일 위에 마우스 오른쪽 클릭, Copy에서 Copy as cURL을 하면, 해당 Request의 정보가 카피된다. 요놈이 위에서 말했던 Request 헤더, Payload다. 얘를 그대로 복붙해서 전달해주면 된다.
앞서 말한 예시 대비 조금 과하다고 느낄 수도 있지만, 버그 리포팅은 상세할수록 좋다. 어차피 개발자도 원인을 파악하려면 실제 에러가 난 상황을 똑같은 조건에서 재현해야 하기 때문에, 그 상황을 그대로 재현할 수 있는 정보와 어느 부분에서 호출 에러가 발생했는지 바로 파악할 수 있는 정보를 주어야 개발자의 시간 누수를 줄일 수 있다.
JSON을 완벽하게 이해하지 않아도, ‘이런 게 제이쓴이구나!’, ‘이럴 때 사용하는구나!’만 알아도 충분하다. 어차피 제이쓴도 하나의 표기법에 불과하고, 조금만 알아두어도 여러모로 써먹을 곳이 많다. (API 연동 스펙, 유저 CS 공유 등)
본 포스트는 유튜버 ‘판교뚜벅쵸’님의 영상 ‘[꼬기집개] #8 IT 기획자라면 JSON과 친해져야합니다.. 제발요 (+개발자랑 친해지는 팁)‘의 내용 중 일부를 발췌하여 사용했습니다.
알아두면 좋은 JSON 관련 서비스
JSON에 대해 더 깊이 알고 싶다면
채드윅 님이 브런치에 게재한 글을 편집한 뒤 모비인사이드에서 한 번 더 소개합니다.
