Page tree
Skip to end of metadata
Go to start of metadata

어떤 행위를 하고자 할 때 API를 우선으로 생각하자는 것이 API First의 의미입니다.

그럼 위에서 말하는 어떤 행위는 무엇을 말하고 싶은 걸까요?

우리는 흔히 서비스를 개발할 때 API 문서를 언급합니다.

이 API 문서는 아래와 같은 용도로 사용됩니다.


백엔드와 프론트엔트가 협업시 '의사소통의 수단으로 API 문서를 활용한다.' 라고 말하지 않을까 싶습니다.


과거에서 지금까지 FrontEnd와 Backend 간의 협업이 필요한 Toy프로젝트를 진행하면서 어떻게 API 문서를 전달했는가를 생각해보면 다음과 같았습니다.


1. Excel 로 정리해서 넘겨주기.

일부 무식한 방법이라고 생각될 수 있지만, 당시 프로토타입을 개발할 적에는 Excel를 통해 API 문서를 전달해주는 행위가 그리 불편하지는 않았지만, 문제는 유지보수에 있었습니다.

시간이 지나 Excel로 된 API 문서를 다시 보니 각 property에 대해서 타입을 잘못 작성하는 일이 빈번했고, API 문서와는 다르게 서비스가 동작되는 경우도 종종 발견되었습니다. 이유는, 개발자들간에 소통하며, 변경된 내용이 코드에는 반영되었지만- 미쳐 Excel 파일에는 반영되지 못한 것입니다.

image-20200612103625272


2. 생각나는 대로, 개발되는 대로 공유하기.

약 2년동안 Mashup 개발 동아리에서 어떻게 개발 프로젝트를 진행했을까 곰곰히 생각해보니 아래와 같았습니다.

디자이너가 UI/UX를 만들어 개발팀에게 넘겨주면, 이후부터 프론트엔트는 화면을 만들고, 백엔드는 API를 만듭니다.

이때, 어느정도 프론트엔드가 화면이 완성되면- API를 요구하기 시작합니다.

프론트엔드개발자: "여기서는 어떤 API 쓸건가요?"

백엔드 개발자: "아직 거기까지 개발을 못해서, 조금만 기다려주세요."

프론트엔드개발자: "네, 그럼 저희는 다른 화면 만들고 있을게요!"

백엔드 개발자: 네;;;; 

이 때 프론트엔드와 소통하게 될 API는 백엔드 개발자끼리 소통하며 하나씩 만들어 가는 방식으로 진행됩니다.

하나의 API가 만들어지면 이제 이 API를 비로서 공유하기 위해, Swagger UI와 같이 Docs를 만들어주는 도구를 활용해 공유합니다.

여기까지가 일반적으로 Mashup 개발동아리에서 개발했던 방식이였습니다. 이 방식의 단점은 무엇일까요?

백엔드 개발자 입장에서는 기능 개발에 필요한 API 하나씩 만들다보니, 큰 그림을 그리기 힘들어집니다. 또한, 중간중간 새로운 API가 만들어질 때마다, 기존에 있던 API가 변경될 확률이 높아집니다. 프론트엔드을 개발하는 입장에서는 위 대화와 같이 어떤 API를 줄지 모르기 때문에 무한대기에 빠져듭니다.

또한, 빈약한 설계 아래, 프론트엔드와 소통될 API가 빈번하게 변경될 요소가 많아지며 원활한 소통 또한 기대하기 힘듭니다.




이런 문제가 발생되는 이유가 뭘까 고민해보면 간단합니다.

프론트엔드 개발자는 백엔드 개발자에게 깊게 의존하게 되고, 백엔드 개발자는 자신의 머리를 너무 믿어버려 발생합니다.

이런 문제를 해결하기 위해서 API First 개발이 모범답안이 될 수 있습니다.

API-First 개발에 필요한 API를 사전에 이해관계자들과 함께 우선적으로 계약하는 것입니다.

우선적으로 계약함으로써, 누군가에게 의존하지 않고, 모든 개발자들이 동시에 작업을 수행할 수 있는 이점이 생깁니다. 이런 이점은 자연스럽게 불필요한 의사 소통을 피할 수 있는 기회가 되기도 합니다.

더하여, 불필요한 의사소통은 피하고, 서비스에 필요한 알맹이같은 의사소통은 API 이해 관계자들에게 브레인 스토밍할 수 있는 기회를 제공할 수 있습니다.

아직 너무 거창하게만 설명했나요?

API First 개발의 장점은 앞으로 천천히 코드로서 설명될 수 있도록 할 예정입니다.



[참고자료]

https://swagger.io/resources/articles/adopting-an-api-first-approach/

https://www.programmableweb.com/api-university/understanding-api-first-design

  • No labels