서버 API 디자인을 클라이언트 코더가 하는 것이 바람직할까? 아니다. API 디자인을 망칠 가능성을 높이는 길이다. 물론 케바케는 진리지만 일반적으로는 피해야 할 행동이다. 플랫폼 서비스의 프론

서버 API 디자인을 클라이언트 코더가 하는 것이 바람직할까? 아니다. API 디자인을 망칠 가능성을 높이는 길이다. 물론 케바케는 진리지만 일반적으로는 피해야 할 행동이다. 플랫폼 서비스의 프론트엔드 UI를 최종 사용자가 디자인 한다고 떠올려보자. 그들은 UX에 대해 고민해 본 적이 없었을 것이고 지금도 하지 않을 것이다. 좁은 시야에서 당장의 편의를 위해 일관성은 던져버릴 것이고 UI를 만드는 사람들의 업무 효율은 알 바 아니며 어쩌면 서비스 생존을 지탱하는 공급사 광고 영역은 시원하게 날려버릴 것이다. 힙스터라면 아직 세상에 존재하지도 않는 AI 기능을 전면에 배치할지도 모른다. 프론트엔드 UI를 UI 전문가가 디자인 한다면 어떨까? 당연히 최종 사용자의 요구사항을 최우선으로 고려할 것이다. 이중 일부는 최종 사용자 스스로도 인지하지 못해 UI 전문가가 몇가지 기법을 통해 발굴해 낸 것이다. 하지만 오로지 그것만을 고려하고 UI를 설계하지는 않을 것이다. 디자인 시스템, 주어진 일정과 인력, 코드베이스, 경영진과 공급사, 투자자의 이해관게, 수익모델과 재무상황 등을 고려해 적절한 균형점을 찾으려 밤낮없이 고민할 것이다. 요구사항과 그 구현은 걑은 것이 아니다. 서버 API 디자인은 어떤가? 다를 것 없다. 서버 API 디자인 작업 과정에서 클라이언트 코더들의 요구사항을 면밀히 검토하고 만족시키기 위해 노력해야 한다. 하지만 그들에게 디자인을 맡겨야 한다는 뜻은 아니다. 클라이언트 코더와 서버 코더는 일부 지식은 공유하지만 어떤 지식은 그러기 힘들다. 두 그룹 사이의 의사소통과 신뢰를 높여 서버 코더가 최적의 API를 디자인 하는 데에 전문성을 충분히 발휘할 수 있도록 하는 것이 바람직하다. 그 모든 산업에서 클라이언트가 인터페이스를 디자인 해서 좋은 일반적 사례가 있기는 한지 모르겠다. 서버 API 디자인은 클라이언트 요구사항을 존중하고 이해하는 서버 엔지니어링 전문가에게 맡기는 것이 일반적으로 이익의 총합이 극대화 된다.