UX 디자인과 개발 1. API에 대해

디자이너님! 저흰 그 API를 쓸 수 없어요!

"OO 목적의 페이지 만들어주세요."

    기획자가 스토리보드와 화면 구성을 다 알아서 만들어주는 곳도 있지만, 스타트업은 그렇지 않은 경우가 있다. 그럴 땐 기획자와 함께 기획하거나 디자이너가 알아서 기획부터 디자인까지 한다. 어떤 의도로 만들어달라고 하는지 이야기하고 시각적, 기획적인 부분을 우선 채워둔 다음 다듬어나간다. 이 프로세스를 처음으로 작업했을 때, 콘텐츠를 다듬는 시기에 내가 필요하다고 생각해 넣은 콘텐츠가 개발 불가능하다는 이야기가 들렸다. 열심히 준비한 나를 충격에 빠트렸다.

    "디자이너님! 저흰 그 API를 쓸 수 없어요!"

    처음엔 API가 뭔지 몰랐다. 그냥 개발에서 알아서 해주겠거니 했다. 다른 앱들도 다 있는데 왜 우린 못써요?! 하고 당황했지만 그 이유를 차분히 이야기해주는 개발자님 덕분에 새로운 설득의 무기가 생겼다.

API란?
API(Application Programming Interface, 응용 프로그램 프로그래밍 인터페이스)는 응용 프로그램에서 사용할 수 있도록, 운영 체제나 프로그래밍 언어가 제공하는 기능을 제어할 수 있게 만든 인터페이스를 뜻한다.

    구글에 API를 검색하면 이렇게 나온다. 응용프로그램에 사용할 수 있도록 만든 인터페이스? 그게 그래서 무슨 기능이고 어떻게 쓰는 거지? 라는 의문이 들기 쉽다.

    "왜 디자인 할 때, 여기에는 지도가 나오는 그런 거 있잖아요."

iOS, Swift를 통한 구글 지도 구현하기의 코딩 화면과 코딩 구현 화면

    디자인할 때 해당 정보를 여기에 넣어달라고 하면, 개발에서는 그 영역을 지정하고 맞는 정보를 불러온다. 그럴 때 필요한 정보(데이터)를 가져오는 연결이 API라고 생각하면 쉽다.

   예를 들자면 현재 위치, 날씨 등 관리자가 매번 업데이트를 하지 않아도 데이터를 자동으로 연결해 유저가 해당 정보 호출을 원할 때(주로 화면 접속이거나 새로고침 등의 버튼 클릭 행위) 가져다주는 기능이다. 화면 접속 시 바로 정보를 보여주는 것뿐만 아니라 번역 기능, 음성 인식 같은 추가적인 기능도 API를 통해 구현이 가능하다.

    심화 학습으로 REST API도 알고 있으면 좋겠지만 디자이너 직군으로 개발자와 소통을 하는 정도면 API와 REST API의 차이를 정확하게 알고 있지 않아도 된다.

    

    여기서 중요한 건 API가 있어도 사용하지 못하는 경우가 있다.

    1. 유료 API

    OPEN API라고 하면 단순히 무료 API라고 생각하기 쉽다. 하지만 OPEN API에서도 횟수, 기간(시간)에 대해 기준을 정해두고 유료가 되는 경우가 많다.

실제 구글 지도의 API 가격표

     API가 무엇인지 설명하기 위해 예시에서 사용한 보여준 구글 지도 API만 하더라도 무료 사용과 월간 사용량 범위를 지정해 비용을 다르게 제공하고 있다. UX 디자인은 소비자를 생각하기 때문에 들어가야 한다고 생각하는 콘텐츠로 특정 API를 원할 수도 있지만, 기획자와 PM의 입장에서는 제작비와 운영비에서 API 사용 가격을 신경 써야 하기 때문에 충돌이 일어날 수 있다. 가장 좋은 건 무료 API를 사용하는 방법이지만 원하는 무료 API가 있을지 미지수이다.

    2. 이용신청, 제휴를 통한 제공

실제 네이버 서비스 API 홈페이지

     모든 API가 공개된 것은 아니다. 어떤 API는 제휴를 통하거나 해당 API를 가진 회사에 신청을 통해 사용할 수 있다. 빠른 출시 일정, 서비스 제작 완료까지 남은 기간이 없다면 이용신청 단계, 제공 회사와의 조율에 걸리는 일정과 단계를 확인을 해야 한다. 또한 신청한다고 다 되는 게 아니라 어떠한 조건이 있어야 제공을 해주는 경우도 있다.

    최악의 경우, 서비스에 사용할 수 있는 API를 제공받지 못 한다.

     API가 왜 없어? 다른 곳에서는 되는데? 신청만 하면 되는 거 아니야? 할 수도 있다. 이 경우는 소수의 경우가 되겠지만, B2B, B2B2C의 형태의 경우 데이터를 가지고 있는 갑 회사가 을 회사에 부분 API만 줄 수도 있다. 혹은 갑 회사만의 규정에 맞지 않아 신청이 불허되는 경우, API를 가진 갑의 회사가 당사의 보안 때문에, 혹은 개발 진행 중이라며 주지 않을 경우도 있다.    

이베스트 데브센터  스크린샷

디자이너가 API를 알고 있어야 하나요?

    몰라도 UX 작업은 가능하다. 기획서가 나오고 화면에 들어갈 콘텐츠가 정확히 정해진 스크린을 UX 조율만 하는 일로 끝난다면 말이다.

    하지만 UX는 정해진 콘텐츠 배치에서 끝나지 않는다. 어떤 정보를 주고, 어떤 기능을 다룰지도 함께 고민하고 화면 설계서에 있는 구성이 부족하거나 과하다면 기획자와 개발자에게 의견을 낼 수도 있어야 한다. API를 알고 있다면 원하는 기능과 정보를 먼저 검색해볼 수 있고, 기획가 개발자를 설득할 수 있다.

     최상의 UX를 위해서 스토리보드와 와이어 프레임을 그릴 당시에 개발자와 기획자, 디자이너가 모여 각자의 영역에서 가능한 걸 이야기하는 게 가장 이상적인 과정이지만 여의치 않다면 회사가 보유하고 있는 API를 화면 기획 부분에서 먼저 공유하는 것도 좋다.

    예를 들자면, 이베스트 데브센터 스크린샷을 보면 개발에 사용할 수 있는 API(TR)리스트가 정리되어 있다. 기획자, 디자이너, 개발자가 함께 리스트를 보면서 화면을 기획하고 디자인하고, 개발하기에 편리하다.

    추가로, 금융권 서비스를 주로 진행하다보니 API보다 TR이라는 단어를 더 많이 듣는다. 들은 바로는 API와 TR은  차이가 있지만 금융이 아닌 다른 서비스에서는 TR을 잘 사용하지 않고, 비개발자가 개발자와 소통할 경우에는 API만 알고 있어도 충분하다고 한다. 더불어 사용 가능한 API를 알아도 금융 서비스를 만드는 건 많은 제도적, 기능적 제한이 있어 진행하다 예상외로 막히는 경우가 많다.

하지만 UX는 정해진 콘텐츠 배치에서 끝나지 않는다. 어떤 정보를 주고, 어떤 기능을 다룰지도 함께 고민하고 화면 설계서에 있는 구성이 부족하거나 과하다면 기획자와 개발자에게 의견을 낼 수도 있어야 한다. API를 알고 있다면 원하는 기능과 정보를 먼저 검색해볼 수 있고, 기획가 개발자를 설득할 수 있다.

심화 학습으로 REST API도 알고 있으면 좋겠지만 디자이너 직군으로 개발자와 소통을 하는 정도면 API와 REST API의 차이를 정확하게 알고 있지 않아도 된다.