# API First 개발의 선순환
**어떤 행위**를 하고자 할 때 API를 우선으로 생각하자는 것이 API First의 의미입니다.
그럼 위에서 말하는 **어떤 행위**는 무엇을 말하고 싶은 걸까요?
우리는 흔히 서비스를 개발할 때 API 문서를 언급합니다.
이 API 문서는 아래와 같은 용도로 사용됩니다.
*백엔드와 프론트엔트가 협업시 '의사소통의 수단으로 API 문서를 활용한다.' 라고 말하지 않을까 싶습니다.*
과거에서 지금까지 FrontEnd와 Backend 간의 협업이 필요한 Toy 프로젝트를 Toy프로젝트를 진행하면서 어떻게 API 문서를 전달했는가를 생각해보면 다음과 같았습니다.
**1. Excel 로 정리해서 넘겨주기.**
일부 무식한 방법이라고 생각될 수 있지만, 당시 프로토타입을 개발할 적에는 Excel를 통해 API 문서를 전달해주는 행위가 그리 불편하지는 않았지만, 문제는 유지보수에 있었습니다.
시간이 지나 Excel로 된 API 문서를 다시 보니 각 property에 대해서 타입을 잘못 작성하는 일이 빈번했고, API 문서와는 다르게 서비스가 동작되는 경우도 종종 발견되었습니다. 이유는, 개발자들간에 소통하며, 변경된 내용이 코드에는 반영되었지만- 미쳐 Excel 파일에는 반영되지 못한 것입니다.
**
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 First 개발의 장점은 앞으로 천천히 코드로서 설명될 수 있도록 할 예정입니다.
**[참고자료]**
https://swagger.io/resources/articles/adopting-an-api-first-approach/
https://www.programmableweb.com/api-university/understanding-api-first-design