강남언니 프론트엔드 개발자가 API를 설계하는 이유

강남언니 프론트엔드 개발자가 새로 도입한 인터페이스 정의 언어를 이용한 인터페이스 관리 전략에 대한 좋은 글이 올라와서 일부 요약해서 공유해 봅니다!

인터페이스 정의 언어

강남언니 팀은 B2B SaaS 어플리케이션 개발을 시작하면서 인터페이스 정의 언어(IDL)를 도입했습니다. IDL은 소프트웨어의 인터페이스를 정의하는 명세 언어입니다. 각 어플리케이션의 언어가 달라도 같은 인터페이스로 통신할 수 있습니다. 여기서 강남언니 팀은 Google Protocol Buffers라는 IDL을 도입해 제품 개발 프로세스에 있던 비효율을 해결했습니다.

비효율적인 문제

1. 유지 보수 되지 않는 API 문서

   백엔드 개발자가 노션 문서에 통신에 필요한 통신 규약을 정의하고, 변경 사항이 생기면 변경을 인지한 개발자가 문서를 수정합니다. 수정된 문서는 1) 현재 구현된 코드가 반영되었는지 알기가 어렵고, 2)응답 필드가 많을 경우 어떤 불일치가 있는지 인지하기가 어렵습니다. API 개수가 늘어나면서 통신 규약을 외부 문서로 유지 보수 하는 데는 많은 수고가 들죠.
   

2. 시스템 관점의 인터페이스 설계

   백엔드 개발자가 인터페이스를 설계할 때 시스템 성능 최적화, 데이터 무결성과 같은 시스템적인 부분이 가장 먼저 고려됩니다. 기술적 측면에 있어 필수적인 고려 사항이지만 성능에 초점을 맞추면 오버 스펙을 가진 인터페이스를 정의할 수도 있죠. 이를 위해 프론트엔드 개발자와 지속적 합의를 하게 되고 이 과정에서 오버헤드와 운영 비용이 높아지는 문제가 생기기도 합니다.

IDL을 통한 문제 해결

1. 프론트엔드 주도로 인터페이스를 설계

   프론트엔드 개발자가 API를 설계하고, 백엔드 개발자는 설계된 인터페이스가 제품 구현을 반영할 수 있는지 리뷰하고 변경을 요청합니다. UI/UX 복잡성을 잘 아는 프론트엔드 개발자가 최종 엔드 유저와 요구 사항에 부합하는 방식으로 인터페이스를 설계하죠.
   

2. 프론트와 백엔드 애플리케이션 코드에 IDL 적용하기

   인터페이스로 정의된 Protobuf 코드를 서버와 클라이언트에서 정의해 동일한 계약 모델을 사용합니다. 이를 통해 유지보수 이슈에 대해 많은 부분을 해결하죠.

결국 모든 어플리케이션에서 동일한 통신 계약 모델을 강력하게 강제해 사용할 수 있다는 것이 가장 큰 무기라고 합니다.

위에 글은 아래의 링크에서 요약해 가져왔습니다. 비슷한 문제 상황을 겪는 프론트엔드 혹은 백엔드 개발자시라면 참고해서 더 좋은 방법을 도입해보는 게 어떨까요?

https://blog.gangnamunni.com/post/saas-why-do-frontend-developers-design-api