기존 협업 방식

약속되지 않는 협업

기존 협업에서 API 문서화 없이 백엔드 개발이 모두 완료가 된 후 API에 대한 내용은 눈치껏 DB Table의 컬럼을 확인하고 API를 만들어야하는 상황이였습니다.

이러한 협업방식은 아래와 같은 문제들을 야기했습니다.

문제 1.
DB Table에 name, age, adress 컬럼이 존재한다고 가정했을 때 사용자를 등록하는 API를 작성할 때 어떠한 Body 값을 넣어야하는지 알 수 없음.

문제 2.
백엔드 소스코드가 완전히 작성되기 전까지 API URL을 작성할 수 없음.
백엔드 개발자가 API URL을 깃허브에 올리지 않으면 내가 API URL을 작성할 수가 없으며, 임의로 작성한다하더라도 추후 수정이 필요함.

문제 3.
백엔드 개발에서 실제 동작 테스트를 하기 어려움.
백엔드 API를 받은 후 프론트에서 추가 개발을 진행하는 시간이 소요됨.
이에 백엔드에서 미쳐 발견하지 못한 에러들을 백엔드 개발자가 스스로 테스트하고 확인하기 어려움.

문제 4.
통일되지 않는 파라미터 값.
시작일과 종료일을 A라는 사람은 startDate, endDate로 B라는 사람은 from_dt, toxx_dt로 작성하여 통일성이 떨어짐.
또한 날짜형태도 YYYY-MM-DD인지 YYYYMMDD인지 백엔드 개발자마다 다름.

협업이라고 하기에는 조금 무리가 있는 업무 방식이고 생산성이 너무나도 떨어지게 된 상황이였습니다.

"백엔드랑 API 문서화를 하면 해결되는거 아니야 ?" 라고 간단하게 생각할 수 있지만 꽤나 쉽지 않았습니다.

먼저 개발을 이끌어가는 부장님은 프론트와 백엔드의 구분없이 일을 해오신분이셨고 이에 파트가 나누어진 개발을 경험해보시지 않았기에 백엔드 중심적으로 개발을 진행하셨습니다.
첫 문장에서 말한 "눈치껏 DB Table의 컬럼명을 확인"하라는 것이 바로 부장님이 생각하시는 협업이였습니다.

지금이야 프론트엔드와 백엔드가 나누어져 개발을 하지만 예전엔 그러한 구분없이 풀스택으로 개발을 진행하신 경험이 있으시다보니 설득이 쉽지 않았습니다.
개발 초기에 꽤나 갈등이 있었습니다.

위와 같은 문제점은 프론트엔드 개발자의 추가시간 소요와 함께 불안전하고 유지보수가 어려운 개발 환경을 만들어냈습니다.

구두로 각 개발자의 자리에 찾아가 API마다 물어보며 개발을 진행하다보니 전체적인 개발 속도가 늦어지고 커뮤니케이션에 문제가 발생하여 정해진 기간 안에 결과물을 만들어 낼 수 없었습니다.

화면 개발 이후 백엔드 개발이 마무리 되고나서 API 연동을 진행하고 테스트를 진행해야함.

자투리 시간에 다른 페이지 화면 개발을 들어가게 되는데 집중력이 떨어질 뿐만 아니라 커밋을 분리하기 어려움을 느끼게 되었습니다.

첫번째 해결방안 Swagger

첫번째 해결방안으로 Swagger를 사용한 API 문서화의 정리를 활용함.

프론트엔드 개발자가 DB와 Eclipse를 사용하여 직접 백엔드 소스코드를 확인하고 파라미터 값과 URL을 확인하는 것은 꽤나 큰 리소스를 낭비하게 됩니다.
그리하여 Swagger를 사용한 API 문서화를 백엔드 개발자분들에게 권유하였습니다.

장점 1.
Swagger에서 백엔드 개발자들이 API 테스트를 진행할 수 있게 되어 보다 안정적인 API 테스트가 가능해짐.

장점 2.
프론트 또한 API 문서화로 소스코드에서 URL과 파라미터 값을 찾지 않게 되어 시간적으로 절약됨.
특히 프론트에서 swagger-typescript-api 라이브러리를 사용한다면 자바에서 만들어놓은 URL뿐 아니라 파라미터들의 타입까지도 프론트엔드에서 바로 사용할 수 있음.

단점 1.
API 테스트가 정확하지 않음.
이유는 API 문서화를 프론트와 백이 함께 정하지 않고 온전히 백엔드 개발자가 작성함.
대부분 누락되거나 잘못 넘어오는 API가 많아 프론트에서 다시 확인하여 백엔드로 이슈사항 전달해야함.

단점 2.
VO(혹은 DTO)가 하나에 모든 타입을 정해놓고 사용하기에 다른 행위지만 파라미터는 동일하게 됨.
예를 들어 GET 요청에는 name만 파라미터를 받고 POST 요청에는 name, age, adress를 받아야하는 상황이라면 Swagger에는 두 요청 모두 name, age, adress 파라미터를 받아야한다고 나와있음.
즉. 요청마다 파라미터를 구별해서 사용하지 않고 모두 사용함.
프론트 개발자는 해당 문서로 어떠한 파라미터를 보내야하는지 알 수 없을 뿐 아니라 필수값(required) 값을 또한 알 수 없어 개발이 어려움.

Swagger를 잘 사용하면 되는 거 아닌가 ?

익숙치 않기에 VO(혹은 DTO)를 요청마다 나눌 시간이 많이 소요가 됩니다.
그리고 백엔드 개발자들이 반대한다면 프론트엔드 개발자로서는 설득할 방법이 딱히 없습니다.
"너 편하자고 우리가 그만큼의 시간을 할애해야해 ?" 라고 말한다면 사실 할 말이 없습니다.
회사에서 이러한 문서화를 하지 않는다는 것이 참 안타까웠습니다.

두번째 해결방안 함께하는 API 설계

현재 사용하는 방법으로 API 설계를 함께 진행하는 방식입니다.
화면설계가 끝나고 난 후 API 설계를 함께 진행하여 URL과 파라미터를 약속하여 동시에 개발을 진행하기로 하였습니다.

예를 들어 A라는 페이지의 사용자 정보를 가져오는 URL은 /user 로 약속을 하고 파라미터로 use_id 를 보내 검색조회 할 수 있도록 약속을 합니다.

위와 같이 API 설계를 함께 진행하여 문서화를 작성한 결과 프론트는 약속된 URL과 파라미터로 API 연결하고 개발자도구 Network에 URL과 파라미터가 정상적으로 요청되는지 확인하면 됩니다.

물론 당연하게 404에러가 나오지만 상관없습니다. 약속대로 개발을 완료한거기 때문에 해당 소스코드는 문제가 없기에 추후 백엔드 개발이 완료되고 동작을 테스트하면 됩니다.

위와 같이 개발을 진행하기에 백엔드도 먼저 만들어진 화면을 통해 API를 동작테스트로 확인이 가능하고 프론트 또한 백엔드가 먼저 만들어준 API를 통해 동작테스트를 진행할 수 있습니다..

또한 백엔드 API에 의존되지 않는 개발을 진행하기에 생산성이 굉장히 올라가게 되었음.

마지막으로

최종적으로 함께 API를 설계하는 것으로 개발방향을 맞춰가고 있습니다.
개발 기간은 체감 할 수 있을 정도로 감소하였고 커뮤니케이션으로 인한 문제 또한 빈도수가 상당히 감소했습니다.

최근 "흑백요리사"라는 넷플릭스 프로그램을 재미있게보고 있는데 프로그램에서 팀미션을 가장 인상깊게 보았습니다.

국내/해외에서 유명한 프로 쉐프들도 협업을 하는 과정에서 갈등이 생기게 되면 그들의 실력보다 낮은 결과물을 만들어낸다는 것입니다.

반면에 리드를 하는 사람의 의견을 존중하고 믿고 따라준 팀은 좋은 결과를 낼 수 있었습니다.

소프트스킬로 나와 다른 생각을 하는 팀원을 설득하는 방법은 굉장히 어렵습니다.
만약 감정이라도 섞여 들어가게 된다면 자칫 싸움으로까지 이어질 수 있기 때문입니다.

오랫동안 자기 스타일의 개발방식에서 주니어의 리드가 불편하게 느끼셨을 수도 있으셨을텐데 긍정적으로 협업해주신 저희 팀분들께 감사함을 표합니다.