스타트업에서 프론트엔드 개발자로 일한 지 어느덧 두 달 반 정도 되었다. 규모가 작은 회사라서 개발자는 신입 프론트엔드 개발자 두 명이 있고, 외주업체의 백엔드 개발자와 협업하여 프로젝트를 진행하고 있다. 백엔드와 프론트엔드는 긴밀하게 협업해야 하는 관계인데, 백엔드가 다른 회사 분이라 거의 메신저로만 소통을 하다 보니 즉각적인 의사소통이 어려웠다. 게다가 프론트엔드 동료는 GraphQL만 사용해봐서 REST API나 JavaScript의 fetch 함수에 대해 잘 모른다고 했다. 기능 개발 과정에서 나의 역할이 매우 중요했고 여러 우여곡절을 겪으며 개발해나갔다.
RESTful하지 않은 API
초반에 백엔드 개발자분께 Swagger를 요청드렸는데, 받아보고 나서 등골이 서늘했다. 모든 API가 POST 메서드로 되어 있고 URI 설계도 제대로 되어 있지 않았다. 어떤 API가 어떤 데이터를 리턴하는지 파악하는 데도 꽤 오랜 시간이 걸렸다.
Under-fetching 문제
또한 API가 너무 작은 단위로 쪼개져 있어 under-fetching 문제가 있었다. API가 연관 데이터를 충분히 보내주지 않아 한 페이지에서 여러 개를 호출해 조합해서 사용해야 했다. 예를 들어, 운동 목록을 조회하는 API가 있는데 운동 하나의 썸네일 이미지를 받아오는 API가 따로 있는 식이었다. 만약 운동 목록에 열 개의 운동이 있다면 운동 목록 조회 한 번, 각 운동의 썸네일 조회 열 번 해서 총 열한 번의 API 호출이 필요한 것이다. 이렇게 비효율적인 작업을 해야 하는 부분이 여러 군데 있어 수정을 요청드려도, 이미 각 기능을 수행하는 API가 있으니 조합해서 사용하라는 답변이 돌아왔다.
데이터를 요리하는 셰프가 되자
프로젝트 기한도 여유롭지 않고 외부 백엔드 개발자가 만든 API를 가져다 쓸 수밖에 없는 열악한 상황이었다. 기한 내에 어떻게든 프로그램이 돌아가도록 만들려면, 데이터를 필요한 형식에 맞게 적절히 가공해서 사용하는 능력이 필요했다. 엄밀히 따지자면 프론트엔드 개발은 사용자의 인터랙션에 따라 화면에 적절한 데이터를 보여주는 작업이기 때문에, 데이터의 퀄리티가 어떻든 간에 잘 가공하여 보여주면 되는 것이었다. 생각해보면 public API 중에도 리턴 값이 이상하거나 데이터가 정제되어 있지 않은 경우도 종종 있지 않은가.
물론 백엔드 개발자가 데이터를 잘 담아 밀키트처럼 바로 조리할 수 있게 보내주면 프론트엔드 개발을 효율적으로 할 수 있고 사용자 경험 향상에 더 신경 쓸 수 있을 것이다. 하지만 원재료를 날것 그대로 보내주더라도 잘 다듬고 요리하여 사용자에게 고급 요리처럼 보이게 하는 게 프론트엔드 개발자가 갖춰야 할 역량이라는 생각이 들었다. 그래서 데이터를 fetch한 후 여러 가지 메서드를 사용하여 상황에 따라 적절한 자료구조로 가공해서 사용했다. 그 결과 썩 효율적이진 않지만 한정된 자원을 활용하여 기한 내에 내가 맡은 기능 개발을 완수할 수 있었다. 그리고 이러한 과정이 익숙지 않은 동료를 위해 적절한 자료구조를 선택하는 방법과 JavaScript의 다양한 내장 메서드를 활용하여 데이터를 가공하는 방법에 대해서 차근차근 알려주었다.
재료를 이상하게 준다고 남 탓하지 말고, 본인의 요리 실력을 키워 셰프가 되자. 이번 프로젝트를 통해 얻은 교훈이다. 그리고 다른 개발자분들과 긴밀하게 소통할 수 있는 환경에서 일하고 싶은 바람이 생겼다.
