🐋 《프리다이빙 기록 관리 서비스 개발기》 #3 - 기록에서 연결로: DB개선과, 외부 데이터 API 연동 도전

소개

이전 작업까지는 v0, Lovable을 통해 프로덕트 스케치, 그리고 실제 cursor로 프로젝트를 옮겨와 구현하는 단계를 거쳤습니다. 이번에는 1) 공식 대회 정보불러오기 위한 DB구조 개선과 2) 스크래핑 API 을 통한 대회정보 연동까지의 작업을 진행했습니다.

1편은 여기에 (https://www.gpters.org/dev/post/breathing-create-records-non-YgDBIBTV0etHjaW)

2편은 여기에 (https://www.gpters.org/dev/post/fridiving-app-development-machine-u928NikQWF2Qen4)

진행 방법

이번에는 로컬에서 동작했던 기능을 실제 운영으로 배포하는 작업까지 완료했고, (요건 생략)

아래와 같이 추가적인 기능을 고도화했습니다.

🚩 Phase 1:서비스 실사용을 위한 구조 재정비

지난 단계에서는 MVP 수준의 기록 입력 기능까지만 구현한 상태였어요. 하지만 실제로 이 서비스를 우리 팀(프리다이빙 팀원들)이 실제 기록 관리용으로 쓰기 시작하려다 보니 몇 가지 구조적 한계가 드러났습니다.

❌ 기록만 있고 ❌ 누가, 어떤 대회에서, 어떤 종목으로 했는지 정보가 빠져 있는 거예요.

예를 들어, 어떤 다이버가 53m DNF를 했다고 기록해도 “이게 공식 대회에서 나온 기록인지, 훈련인지, 연습인지” 알 수가 없습니다. 단순 '기록'입력이 첫번째 MVP 범위이긴 했지만.. 저희 팀이 실제로 유의미하게 서비스를 사용하기 위해서는 '공식 대회 정보'를 불러오는게 필수적이었어요. 그래서 이번 단계의 핵심 목표는 두 가지였습니다.

1. 공식 대회 정보를 수집해서 DB에 넣고, 기록과 연결하기

2. 사용자 국적/국가, 장소(풀장/바다 등) 등의 메타데이터를 구조화하기

🚩 Phase 2: DB 구조 확장: 마이그레이션이 아니라 ‘확장’

처음엔 Claude와 GPT에게 DB 스키마를 고도화할수 있는 방안을 물어봤습니다. 그런데 제시한 방식이 “신규 테이블 만들고, 마이그레이션 해라”라고 하더라고요. 아무리 생각해도 꽤 부담스러운 선택이었어요.

마이그레이션으로 망치면 복구도 쉽지 않겠다라는 좋지 않은 예감때문에, DB도 백업을 해둬야 겠다는 고민을 하던 중, 소스코드처럼 'DB도 별도의 브랜치로 나눌 수 있다' 고 스터디장님들을 통해서 알게되었습니다.

그래서 실제로 git에 브랜치를 별도로 따고, supabase까지 올리려고 하는 도중에...! 아무래도 커서가 제시해준대로 "이렇게 까지 어렵게 갈 필요가 있을까..?"라는 생각을 하게 되었습니다. ㅋㅋㅋ

지금까지는 테스트 데이터 기반으로 설계한 구조였기 때문에 기존 테이블을 최대한 살리고, 꼭 필요한 컬럼/테이블만 추가한다 는 방향으로 가기로 했습니다.

👩🏻‍💻 실제 진행한 작업은 아래와 같아요

• ❌ 데이터가 전혀 없고 활용 계획이 없는 기존의 테이블은 과감히 삭제

• ✅ records (필수적인) 테이블은 유지하되, 추가될 기능에 따라 competition_id, event_type, is_official, location_type 등의 컬럼을 확장하는 방식으로 진행

• ✅ competitions, countries, competition_events 등의 신규 카테고리는 아예 테이블을 새롭게 추가

실제 사이트에서 제공하는 데이터와, 아래 DB스키마 개선안을 기반으로 DB테이블 생성, 컬럼추가 등의 작업을 진행할거야. 첨부된 사이트의 리서치 내용 아주 꼼꼼하고 정확하게 분석해서 반영할 수 있도록 정리해주세요.  중간에 모호한 내용이 있으면 여러 번 질문/ 확인작업을 거쳐서 완결성있게 작업 해 주세요. @https://chatgpt.com/s/dr_683f1143e7b88191b0562195e6e7a9d0

TIP 기능을 확장하다 보면 DB스키마를 새로 짜거나, 테이블을 수정/ 마이그레이션 해야하는 상황이 생길 수도 있더라고요. 그래서 가장 중요한건 초반의 핵심 구조 설계인 것 같아요. 초반의 구조를 잘 짜놓으면, 테이블을 추가하거나 컬럼을 확장해도 꼬일 위험이 덜한 것 같습니다.

추가적으로, AI가 너무 어려운 해결방안을 내놓으면 (?) 현재 구조에서 최대한 변경되지 않는 방향을 제시하고, 다시 검토해보라고 하는 과정도 꼭 필요할 것 같아요..(개발자가 아니므로!!!복잡해지면 ~ 정말 ~~ 답 없을수도.. 😟 )

🚩 Phase 3: 사이트에서 대회 정보 가져오기 (API vs 스크래핑 vs MCP)

프리다이빙의 공식 대회 및 기록 정보는 [AIDA International](https://www.aidainternational.org/) 사이트에 대부분 등록돼 있습니다. 물론 다만 추후에 다른 사이트/방식을 통해서 가지고 올것도 고려해야 했습니다.

GPT와 대화하며 어떤 방식으로 대회정보를 불러와야 할지 찾아보고, 해당 리서치 정보를 다시 커서에게 준 다음에 어떠한 방식을 채택하면 될지 질문하며 API를 개발해 나갔습니다.

넌 AI 전문가이자 고급 개발자야. 지금까지 내가 만든 서비스 기반으로, 아래의 기능을 추가하려는데 그 방법을 비개발자 관점에서 쉽고 구체적으로 알려줘. 

1. 특정 사이트에서 대회정보를 자동으로 불러오고 이를 서비스(관리자가 확인 가능하도록) 에 연동 할거야(https://www.aidainternational.org/Events/EventCalendar)
2. 해당사이트의 대회정보는 국가별로 나뉘어져 있으며, 해당 페이지에 있는 주요한 값을 참조해서 가져올거야 (국가/연도/대회선택) 
3. 그리고 해당 대회 정보는 수시로 업데이트 되므로, 관리자가 직접 동기화가 가능하도록 해야 해.

이 프로젝트에서 사용하고 있는 기술스택을 기반으로 여기에 맞는 가이드를 제시해 줘

아래 단계에 따라, Next.js(React/TypeScript) + Supabase 환경에서 AIDA 대회 정보를 자동으로 크롤링·업데이트하는 기능을 구현할 수 있습니다.

✅ 1차 시도: 공식 제공하는 API를 찾아라

처음엔 사이트 구조를 분석해서(GPT가 알려준대로) API가 있는지 확인하는 과정을 거쳤습니다. 개발자 도구에서 request/response를 확인해보니 JSON은 있더라고요. 근데 그 JSON은 그냥 UI 구성용 설정값만 있었고, 대회 정보는 전혀 없어서 패스 😅

✅ 2차 시도: 그럼 직접 만들어라 (스크래핑)

결국 스크래핑 쪽으로 방향을 틀었습니다. Cursor에게 URL을 던지고 “이걸 기반으로 대회 정보를 수집할 수 있는 API 만들어줘”라고 했더니, 정확하게 스크래핑 기반 API 코드를 짜주었습니다.

초반엔 제대로 데이터가 안 넘어와서 당황했는데, response 값이 null이거나 항목이 누락되는 걸 보며 하나하나 디버깅 해 나갔습니다. 어떤 데이터를 어떤 테이블로 넣을지 화면을 캡쳐하고 GPT랑 계속 대화하면서 고쳤습니다.

여기서 중요한 점은, API를 개발하고 값을 주고받을 때 콘솔창에서 실제로 데이터가 잘 넘어오는지를 눈으로 확인하며 디버깅하는 작업입니다.

1. 개발자도구를 열고 콘솔/네트워크 창에서 제대로 된 정보가 들어오는지 확인하고 캡쳐화면 넘기기

   

   ALT

   중국 웹 사이트의 스크린 샷

2. 정보가 제대로 들어오지 않았고, 여러번 시도해도 안되었다면 정보가 들어와야 하는 테이블/컬럼 정보를 주고 여기로 들어오는게 맞는지 확인하기 // 혹은 // 정보를 주는 페이지 + 받는 페이지 를 모두 캡쳐한 뒤, 파싱이슈가 있는지 확인해보기

..등등등 여러가지 방법으로 같이 원인을 파악해봅니다

저는 개발자는 아니지만 DB 구조를 이해하고, 그걸 기준으로 어떤 데이터를 어떻게 연동하고 확장해야 하는지 고민하는 게 중요하다는 걸 이번에 많이 느꼈습니다. 기존에는 그냥 프론트에서 작동만 되면 되는 줄 알았는데 , 이번 작업을 통해 아래처럼 좀 더 깊이 고민하게 되었습니다.

“이 데이터는 어떤 구조로 개선되어야 나중에 확장이 쉬울까?”

“이 컬럼은 나중에 어떤 부분과 연결될 수 있을까?”

"국가 정보 테이블을 만들지만, 추후 다른 테이블에 어떻게 불러와서 사용할까?"

많은 분들이 백엔드 DB 연동 시, MCP를 사용해서 100% vibecoding 로만 진행하실 수 있을텐데요, 저같은 경우는 비개발자라도 DB구조(Supabase와 같은 서비스 페이지에서) 를 눈으로 꼭 파악하면서 문제의 원인을 찾아보고, 파악해 보시기를 추천드립니다. 정말 간단한 테이블/컬럼구조와 Join되는 개념만 알고있어도 DB설계 하는 것 부터 > 추후 확장할 때 많은 문제들을 보다 쉽게 해결하고, 확장시킬 수 있다고 생각합니다.

ALT

한국 축구 리그 웹 사이트의 스크린 샷

ㄴ대회 정보 불러오기 성공! 근데...일부 정보만 불러오고 아직 모든대회정보를 필터에 맞게 불러오지 못해서 디버깅 중 ㅠ_ㅠㅠㅠㅠㅠㅠㅠㅠ

✅ 3차 확장 구상: MCP 연동까지 가야하나요..?

궁극적으로는 대회 정보가 아닌 각 선수들의 기록까지 자동으로 불러오려고 합니다. 그런 경우 스크래핑으로는 한계가 있어서 MCP 를 구축해야 하나?라는 생각이 들었습니다. (댕멍님이 알려주신 MCP서버 만드는게 진짜 내 몫이 될 줄은…) 아직은 고민 중입니다만,, 크롤링만으로는 한계가 있으니 향후 도입을 검토해야 할 것 같아요

🚩 Phase 4: 기록 입력 화면에 API로 불러온 대회 정보 연결하기

DB에 대회 정보는 들어갔지만, 기록 입력 화면에서 그 정보를 불러와서 쓰지 못하면 아무 소용 없잖아요? 그래서 기존 기록 입력 방식을 아래와 같이 개선했습니다.

특히 record_type을 넣은 게 꽤 중요했어요. 기록이 단순 수치가 아니라 맥락을 갖게 되었고, 나중에 통계, 비교, 히스토리 뷰에서 유용해질 것 같더라고요.

기록 추가 시 이번에 변경된 DB구조를 반영하여 프리다이버가 추가적인 정보들을 등록할 수 있어야 합니다. 

1)종목 
2)거리 
3)판정결과 
4)날짜 
5)장소 
6)수온 
7)메모 

정보가 지금 저장이 가능한 정보이고, 아래 내용을 반영해주세요. 

1. record_types이라는 유형정보 (훈련/대회/연습) 셀렉박스로 선택할 수 있어야 합니다. 
2. 여기서 대회를 선택하면 대회정보를 별도로 불러올 수 있는 영역을 만들어주고, 대회정보에서 가지고올수 있는 정보 (장소, 날짜)는 자동으로 입력되도록 해주세요. 
3. 대회가 아닌 다른 유형을 선택시, 다른 입력영역은 현재와 동일하게 유지해주세요. 

[기존 기록등록 화면] - 단순 기록만 등록

[개선된 등록 화면] - 대회/훈련/연습 구분을 선택할 수 있으며, 대회를 선택 시에는 api로 가져온 정보를 불와서 장소나 날짜 등이 자동 등록 됨

✍️ 마무리하며

이번 작업을 통해 기록 기반 도구였던 BreatheLog가 “대회 히스토리를 기반으로 한 프리다이빙 활동 통합 기록 플랫폼”으로 진화할 수 있는 첫걸음을 뗀 것 같아요.

이제는 단순히 “내가 뭘 했는지”가 아니라 “어떤 대회에서 어떤 공식기록을 남겼는지”를 중심으로 기록이 남고, 이를 기반으로 확장이 가능해지는 구조가 만들어졌답니다 🙂

결과와 배운 점

1. 위에 설명하지 않은 git/github 에 대한 내용인데요, 특정시점부터는 단순 커서 프로젝트에 '저장'이 아닌 코드를 저장해야 하는 시점이 옵니다. (특히 배포시에도 필요해요) 이 부분을 처음부터 커서와 대화하며 git 설치부터 - github 에 커밋까지 진행했습니다. 그리고 어떤일이 발생할지 모르니... 소스를 수시로 올리는 습관을 들이는게 좋을 것 같아요!

2. DB스키마의 확장은 서비스를 구현하다보면 피할 수 없는 부분인 것 같아요. 1)최초에 여러가지 정보 (1편에 나옴/ PRD, 요구사항정의, 브랜드맵 등등)를 주면서 스키마 구조를 잘 잡고, 2)AI가 창의적인 방안을 제시해도 필수적인 사항이 아니면 현재의 구조를 유지하는게 좋은 것 같습니다.

3. 백엔드와 관련하여, 실제로 내 프로젝트에 어떤 주요 정보가 있는지 한번쯤은 훑어보기도 하면서, 디버깅할때 혹시 이런 문제가 있지는 않을지 ? AI와 함꼐 고민해보는 것도 좋은 습관인 것 같아요.
   
   읽어주셔서 감자합니당 :)