코드 우선 방식 경험 정리

1. 내가 사용한 방법

• 백엔드는 코드 우선(Code-First) 방식으로 개발하고, 완료된 API를 Swagger에 반영하는 형태로 진행.
• 프론트엔드(Flutter)는 UI 화면을 먼저 제작한 뒤, 각 페이지에서 필요한 데이터는 텍스트 하드코딩으로 채워 넣음.
• 이후 실제 API가 나오면 하드코딩 데이터를 제거하고 API 연동 코드로 교체.
• 데이터 처리를 위해 UI 기준으로 모델 Class를 만들고 사용했음.

2. 문제점

1. 하드코딩 의존성
   • 초기 화면 제작을 위해 데이터 하드코딩을 많이 사용하다 보니, 실제 API를 붙일 때 교체 과정이 복잡하고 실수가 잦았음.
2. API 정의 완료 시점 지연
   • API 정의가 백엔드 개발 완료 후에야 Swagger로 공유되었기 때문에, 프론트는 UI를 먼저 개발한 다음에 API를 붙일 수 있었음.
3. UI 중심 모델과 API Response 불일치
   • Flutter에서 UI를 기준으로 모델 Class를 설계했기 때문에, 실제 서버 API Response와 구조가 달라 오류가 발생함.
   • 필요 없는 데이터가 포함되거나, 필요한 데이터가 누락되는 문제가 자주 생겼음.

3. 해결 방법

1. API 우선 개발하기
   • 백엔드 구현 전에 최소한의 API 스펙(OpenAPI 문서)을 먼저 정의하고 공유.
   • 이를 기반으로 프론트/백엔드가 병렬 개발 → 하드코딩 의존 줄이기.
2. 코드 생성(Codegen) 도입
   • OpenAPI 문서를 기반으로 Flutter용 모델 Class와 API Client 자동 생성.
   • 수동으로 UI 전용 모델을 만들지 않고, API Response 스펙을 기준으로 사용.
3. Mock 서버 활용
   • 하드코딩 대신 Prism Mock, MSW(Mock Service Worker), Flutter용 Fake Repository 등을 이용.
   • 프론트는 항상 “API 레이어”를 통해 데이터를 가져오게 만들고, 실제 API가 나오면 엔드포인트만 교체.

느낀점

첫 프론트엔드 작업이다 보니 시행착오가 많았다. 특히 UI에 보이는 데이터를 기준으로 모델 Class를 설계한 것이 가장 큰 실수였다. 처음부터 Swagger에 정의된 API 스펙을 참고했다면 실수도 줄고 개발 속도도 더 빨랐을 텐데, “UI를 빨리 완성하고 싶다”는 마음에 무리하게 하드코딩에 의존했던 것 같다.
또한 “실제 API가 나오면 그때 바꾸면 되겠지”라는 막연한 생각으로 접근했지만, 그 결과 교체 과정에서 많은 오류와 비효율이 발생했다. 결국 요구사항에 맞는 UI만 우선 구현하고 뒤에서 맞추려다 보니 후폭풍이 컸다.
이번 경험을 통해 앞으로는 하드코딩을 최소화하되 필요한 경우에는 단순 UI 확인용으로만 제한적으로 사용해야 한다는 점을 깨달았다. 실제 API가 준비되면 바로 연동할 수 있도록, 중요 UI와 API 기반 구조를 함께 고려하며 개발하는 것이 더 효율적이라는 것을 배웠다.