코드 작성 전 api 명세를 꼭 확정하고 진행하나요?

Question

현업은 아니고, 현재 함께 사이드 프로젝트를 진행한 팀이 있습니다.저는 비전공자이고, 다른 팀원분은 전공자다 보니 대부분의 의견은 전공자분을 따라가며 프로젝트를 끝마친것 같습니다.그런데 지금 생각해보니 궁금한 점이 생겨서요.저희가 처음 본격적으로 개발을 들어가기 전에,기획 / DB설계가 끝나고 API 명세를 뽑은 후에 코드를 작성하자. 코드는 버전을 나눠서v1 - api 명세바탕으로 구조 확정 후 Mock 데이터를 이용해 하드코딩해서 프론트에 쏴주면, 이걸 기준으로 프론트에서 api 연동v2 - v1을 바탕으로 목 데이터를 제거하고 실제 비즈니스 로직 작성v3 - 모니터링하며 성능개선 및 고도화순으로 가기로 했습니다.그런데 단순 CRUD만 있는 프로젝트가 아니고, 게임적인 요소가 들어가다 보니 저는 v1버전이 나온다해도 dto나 api명세가 변경될 여지가 있다고 생각했습니다. 실제로 있었고요. 사실 팀원분이 작성한 v1이 100% 바이브 코딩으로 작성된 코드다 보니 한 번에 클래스도 거의 100개 가깝게 생성이 됐었고 검토를 안하고 푸시를 해서 제가 검토 + v2 작업 들어가다보니 빼먹은 부분이나 수정되어야할거같은 부분들이 조금씩 보이더라구요그래서 작업 일단 끝낸후에 공유를 했습니다. dto 및 엔드포인트에 조금 변경이 있을거같다고요그런데 엄청 화를 내시더라구요 그러게 v1작업 전에 api 명세를 확정하라고 했는데 지금와서 고치면 프론트는 어쩌냐구요… 그래서 궁금해서 여쭤봅니다정말 현업에서는 api를 확정한 채로 작업이 들어가고, 작업 중에 api 변동이 있으면 안된다는 마인드로 작업 들어가기전 검토를 빠듯하게 하나요?

chytonpide · Accepted Answer

음.. 하드웨어를 만드시나. 원래 소프트웨어는 말랑말랑한게 변경이 많습니다. 유연하게 변경할 수 있게 하는게 좋은 설계를 하는거구요. 어느정도 시간을써서 설계도하고 스팩도 사전에 정하고 하지만, 요건이라는게 원래 계속 변하고, 요건이 바뀌지 않아도 구현하면서 디테일이 바뀌는 경우는 흔합니다. 해커톤에서 결과물 제출 해야 하는데 갑자기 내생각엔 이게 좋다고, 약속한 스팩대로 안만들면 화가 날 수도 있죠.근데 보통은 설계가 있어도 구현을 해나가면서 계속해서 디테일들을 조율해 나가는게 일반적인 개발 과정이라고 생각합니다.

집킨 · Answer

기획이 바뀌면 API 명세도 바뀌는거죠v1 v2 이렇게 api버전이 올라가는건 이미 런칭을 하고 난 뒤에 api변경 때문에 호환성 이슈가 있을때 하는거구요실무에서 api 명세는 자주 바뀝니다

더미 · Answer

그러면 사람들이 si 욕을 안 하겠죠.

으헝러헝헝 · Answer

네

js_ · Answer

프론트 백 나눠서 업무하면 당연히 api 명세 확정하고 그거대로 개발해야되는게 맞고물론 그렇다고 절대 변경 안되는건 아니고 필요하면 변경해야죠근데 한쪽에서 바꾸면 반대쪽도 업무가 늘어나니까 화나는것도 맞고 바꾸는 사람이 상황 설명 잘 하고 사과도 해야되는게 맞음그냥 당연히 바뀔수도 있다는 태도면 화나는게 당연

scissors hand · Answer

원래 Public API 는 한번 오픈하면, 함부로 Shutdown 할 수 없다. 제대로 만들 기회는 오직 딱 한 번 뿐이다.라는 말이 있지만, 백엔드 개발자가 신도 아니고 항상 아무런 문제 없이 한 번에 완벽하게 할 수 있기가 쉽겠습니까?프런트 엔드도 API 스펙 검토에 책임을 부여해야 합니다. 본인도 검토했고 문제 없다고 인정했으니, 놓친 게 있으면 프런트도 같이 책임져야 하는 거죠. 놓친게 있고 해당 내용을 수정하지 않으면 프런트 구현에도 문제가 발생 할텐데 화부터 낸다니 이해할 수가 없네요.구조가 엄청나게 변경된다면야 모르겠지만, 필드들이 추가되거나 변경되는 건 감수해야 하지 않나 합니다.

엡실론 · Answer

작업 일단 끝낸후에 공유를 했습니다. dto 및 엔드포인트에 조금 변경이 있을거같다고요명세를 바꾸는게 문제가 아니라, 프론트랑 충분히 협의가 안되고 작업한게 문제죠. 글쓴분 입장에서야 간단한 수정이라도 프론트 입장에서는 그렇지 않을 수도 있고요. 게다가 구체적으로 뭐가 어떻게 바뀌었다고 설명을 하신건지, 아니면 그냥 API 좀 바꿨어요 라고 하신건지. 후자라면 다른 팀 입장에서는 놀라고 화날만 하죠.현업에서도 API를 바꿀려면 일단 관계되는 사람들이랑 협의를 해서 무엇을, 왜, 어떻게, 언제 바꿀건지 최소한 구두로나마 협의를 하고 작업을 시작해야 합니다.

WLM · Answer

기획이 바뀌지 않는한, 더 정확히는 크게 기능이 바뀌지 않는 한 인터페이스가 추가될 순 있어도 변경될 가능성은 낮죠. 이게 추상화의 힘이기도 하고요다만 아직 주니어 시다보니 시행착오를 겪으면서 api 인터페이스가 바뀔 순 있다고 생각해요. 그게 외부 public api도 아니고 우리가 제어할 수 있는 내부 FE만 사용하는 api니까 이러한 수정에서 유연할 수 있다고 생각합니다. 그게 사이드 프로젝트, 작은 집단의 강점이죠그리고 버저닝은.. 솔직히 지금 단계에서 왜 하는지 모르겠네요.. 왜 하는가에 대한 이유도 잘 모른채 겈멋만 든 개발자가 있는듯..

코드 작성 전 api 명세를 꼭 확정하고 진행하나요?

8개의 답변

기타 목록