[심층분석] 운동 앱 백엔드를 5분 만에? 1,324개 운동 데이터셋과 '셋업 마법사'의 정체

요즘 헬스장 가보면 다들 한 손에 폰 들고 운동하잖아요. "오늘 벤치프레스 60kg 5세트", "스쿼트 3세트"… 이렇게 기록하는 앱 한 번쯤은 써보셨을 거예요. 그러다 보면 개발하는 사람은 자연스럽게 이런 생각이 들거든요. "이거 나도 만들 수 있지 않을까?" 그런데 막상 시작하려고 하면 의외의 벽에 부딪혀요. 코드가 어려운 게 아니라, '운동 데이터' 자체가 없다는 거예요. 화면이랑 버튼은 어떻게든 만들겠는데, 정작 "벤치프레스는 가슴 운동이고, 바벨이 필요하고, 이렇게 저렇게 하는 거예요" 하는 알맹이 정보가 손에 없는 거죠.

이번에 소개할 exercises-dataset이라는 깃허브 저장소가 바로 그 지점을 정확히 건드리는 프로젝트예요. 1,324개나 되는 운동 정보를 깔끔하게 정리해놓은 데이터 묶음이거든요. 그런데 단순히 데이터만 툭 던져주는 게 아니라, "이 데이터로 앱 백엔드 만드는 것까지 도와줄게"라는 콘셉트라서 더 흥미로워요. 게다가 이 프로젝트 하나에 데이터셋, 다국어 처리, 그리고 요즘 가장 민감한 주제인 '데이터 저작권' 이야기까지 다 녹아 있어서, 주니어 개발자가 배울 게 정말 많아요. 오늘은 이걸 천천히 뜯어볼게요.

그래서 이 데이터셋엔 뭐가 들어 있나요?

먼저 '데이터셋(dataset)'이라는 말부터 짚고 갈게요. 이게 뭐냐면, 쉽게 말해 잘 정리된 정보 묶음이에요. 우리가 엑셀에서 보는 표 있잖아요. 행(가로줄) 하나가 운동 하나고, 열(세로줄)이 그 운동의 속성들인 거예요. 그게 데이터셋이에요. 그냥 글로 줄줄 써놓은 게 아니라, 컴퓨터가 바로 읽어서 쓸 수 있게 칸칸이 나눠놓은 정보죠.

이 데이터셋은 운동 하나하나마다 이런 정보를 담고 있어요.

• 운동 이름(name) — 벤치프레스, 스쿼트 같은 이름
• 분류(category) — 근력 운동인지, 스트레칭인지 같은 큰 갈래
• 타깃 근육(target muscle group) — 이 운동이 주로 어디를 자극하는지 (가슴, 이두근 등)
• 신체 부위(body part) — 상체인지 하체인지
• 필요한 기구(equipment) — 바벨, 덤벨, 아니면 맨몸인지
• 단계별 방법(instructions) — 어떻게 하는지 순서대로
• 미디어 ID(media_id) — 시연 이미지·영상을 가리키는 고유 번호 (이건 뒤에서 자세히요)

여기서 진짜 눈에 띄는 게 하나 있어요. 바로 운동 설명이 6개 언어로 들어 있다는 점이에요. 영어, 스페인어, 이탈리아어, 터키어, 러시아어, 중국어요. 보통 이런 데이터는 영어로만 되어 있어서, 한국 서비스에 쓰려면 번역하는 데만 며칠씩 걸리거든요. 그런데 처음부터 여러 나라 말로 준비되어 있다는 건, 글로벌 서비스를 염두에 둔 사람한테는 시간을 엄청 아껴주는 부분이에요. (아쉽게도 한국어는 아직 없지만, 구조가 다국어용으로 잡혀 있으니 한국어 칸 하나 추가하는 건 어렵지 않아요.)

'셋업 마법사'가 대체 뭐길래

이 프로젝트에서 제일 독특한 부분이 바로 'developer setup wizard'예요. 우리말로 풀면 '개발자 셋업 마법사' 정도 되는데요. 마법사라고 하니까 거창해 보이지만, 이게 뭐냐면 "다음, 다음 누르면 설정이 알아서 끝나는 안내 도우미" 같은 거예요. 윈도우에서 프로그램 깔 때 "다음(Next)" 버튼 계속 누르다 보면 설치가 끝나잖아요. 그 느낌이라고 보시면 돼요.

이 프로젝트가 똑똑한 게, 데이터만 주고 "알아서 잘 써" 하고 끝내는 게 아니라, 그 데이터로 백엔드(서버 쪽 시스템)를 만들 때 필요한 세 가지를 자동으로 만들어줘요.

1. DB 스키마(database schema) — 이게 뭐냐면, 데이터를 담을 '데이터베이스 설계도'예요. 도서관에 책을 막 쌓아두면 못 찾잖아요. "소설은 여기, 과학책은 저기" 하고 책장 배치를 미리 정해두죠. 스키마가 바로 그 배치도예요. "운동 이름은 이 칸, 근육은 저 칸" 하고 데이터 들어갈 자리를 미리 짜주는 거예요.
2. API 코드 — API가 뭐냐면, 쉽게 말해 식당의 '주문 창구'예요. 손님(앱 화면)이 "가슴 운동 목록 주세요" 하고 주문하면, 주방(데이터베이스)에서 음식을 만들어 내보내잖아요. 그 주문을 받고 음식을 내주는 창구 역할을 하는 게 API고, 그 창구를 만드는 코드를 알아서 짜준다는 거예요.
3. LLM 프롬프트 — LLM은 ChatGPT 같은 AI를 말하고, 프롬프트는 그 AI한테 주는 '지시문'이에요. 즉, "이 운동 데이터를 가지고 AI한테 운동 추천을 시키려면 이렇게 물어봐" 하는 본보기 질문지를 같이 챙겨준다는 거죠.

정리하면, 예전엔 데이터셋 받으면 "좋아, 이제 이걸로 뭘 만들지" 하고 처음부터 다 직접 설계해야 했어요. 그런데 이 프로젝트는 데이터 + 설계도 + 주문창구 + AI 사용법을 한 묶음으로 준다는 거예요. 요즘 좋은 오픈소스 데이터셋들이 이런 방향으로 가고 있거든요. 데이터만 던지는 시대에서, '바로 굴러갈 수 있게 도구까지 챙겨주는' 시대로요.

그런데 왜 '이미지랑 영상은 빠져 있다'고 할까요?

여기가 사실 이 프로젝트에서 가장 배울 게 많은 대목이에요. README에 아주 솔직하게 적혀 있거든요. "운동 시연 이미지와 움직이는 GIF 영상은 이 저장소에 포함하지 않았다"고요. 그 이유가 뭐냐면, 그 미디어(이미지·영상)의 소유권을 두고 여러 곳에서 서로 '내 거다'라고 주장하는 충돌이 있어서, 함부로 다시 배포할 수 없다는 거예요.

이게 왜 중요하냐면요. 주니어 개발자가 자주 빠지는 함정이 바로 이거거든요. "인터넷에 공개된 데이터니까 그냥 가져다 써도 되겠지?" 하는 생각이요. 그런데 현실은 그렇게 단순하지 않아요. 데이터의 출처를 따라가 보면 이렇게 얽혀 있어요.

• 원본은 ExerciseDB v1(AscendAPI라는 곳에서 만든 운동 DB)에서 나왔고요,
• 그걸 누군가 Kaggle(데이터 공유 사이트)에 다시 올린 걸 가져왔어요,
• 텍스트 데이터(운동 설명)는 정리해서 공유하지만, 이미지·영상은 권리관계가 복잡해서 뺐다는 거예요.

대신 똑똑한 방법을 썼어요. 각 운동마다 media_id(예: 2gPfomN)라는 고유 번호만 남겨둔 거예요. 이게 뭐냐면, 실제 파일은 안 주지만 '이 운동의 이미지가 어디 있는지 가리키는 주소표'는 준다는 거죠. 정당하게 사용할 권리가 있는 사람은 static.exercisedb.dev/media/{media_id}.gif 같은 주소(CDN, 즉 콘텐츠를 빠르게 전달해주는 서버)에서 알아서 받아 쓰라는 거예요. 도서관 책 자체는 안 주지만, 청구기호는 알려줘서 "이 번호로 가면 그 책이 있어" 하고 안내하는 셈이죠.

게다가 README엔 이런 말도 있어요. "혹시 당신이 이 미디어의 권리자라면, 이슈를 열거나 연락 주세요. 빼거나 정정하겠습니다." 실제로 #5번 이슈에서 누가 출처 문제를 지적하자 원본 출처 표기를 추가했다고도 적혀 있고요. 이게 바로 오픈소스 세계에서 데이터를 다루는 올바른 태도예요. 출처를 밝히고, 권리관계가 애매하면 빼고, 문제 제기가 들어오면 고치는 거요. 데이터셋 하나 보면서 이런 '저작권 매너'를 배울 수 있다는 게 꽤 값진 부분이에요.

직접 만들기 vs API 쓰기 vs 이 데이터셋, 뭐가 다를까

운동 앱 데이터를 구하는 길은 크게 세 가지예요. 비유로 풀어볼게요.

• 처음부터 직접 만들기는 마치 밭에서 농사를 직접 짓는 것과 같아요. 운동 하나하나 조사하고, 근육 정보 찾고, 설명 쓰고… 가장 자유롭지만 시간과 노력이 어마어마하게 들어요. 1,324개를 손으로 채운다고 생각해보세요. 상상만 해도 아찔하죠.
• 운동 API를 매번 호출해서 쓰기는 배달 음식 시켜 먹기예요. 필요할 때마다 외부 서버에 "가슴 운동 줘" 하고 요청하면 받아오는 거죠. 편하지만, 그 서버가 멈추거나 요금 정책이 바뀌면 내 앱도 같이 흔들려요. 남의 주방에 의존하는 셈이거든요.
• 이 데이터셋을 받아서 내 DB에 넣기는 장 봐서 냉장고에 채워두기예요. 한 번 받아놓으면 내 손안에 데이터가 있으니 외부 서버가 죽어도 내 앱은 멀쩡해요. 대신 신선도 관리, 즉 데이터 업데이트는 내가 챙겨야 하죠.

많은 경우 세 번째 방식, 그러니까 검증된 데이터를 한번 받아서 내 것으로 만드는 방식이 MVP(최소 기능 제품, 일단 핵심만 빠르게 만든 시제품)에는 딱이에요. 빠르게 출발할 수 있으면서도, 외부 의존을 줄여서 안정적이거든요. 이 프로젝트가 '셋업 마법사'로 DB 스키마랑 API 코드까지 만들어주는 이유가 바로 이 길을 쉽게 걷게 해주려는 거예요.

한국 개발자에게 주는 시사점

자, 그럼 실전 이야기를 해볼게요. 만약 여러분이 사이드 프로젝트로 운동 기록 앱을 만들고 싶다고 쳐요. 예전 같으면 데이터 모으는 데만 2주는 썼을 거예요. 그런데 이런 데이터셋을 쓰면, 첫날에 바로 "화면에 운동 목록 띄우기"부터 시작할 수 있어요. 데이터 채우느라 기운 다 빼고 정작 만들고 싶던 기능은 손도 못 대는 일을 피할 수 있는 거죠.

다만 한국에서 서비스를 낼 거라면 꼭 챙길 점이 몇 가지 있어요.

1. 라이선스를 반드시 확인하세요. 앞에서 봤듯이 이미지·영상은 권리가 복잡해서 빠져 있어요. "데이터셋에 있으니 써도 되겠지"가 아니라, 상업적으로 쓸 거면 원본인 ExerciseDB 쪽 이용 약관까지 직접 확인하는 게 안전해요. 토이 프로젝트와 돈 버는 서비스는 기준이 완전히 달라요.
2. 한국어 번역을 채워 넣으세요. 6개 언어는 있는데 한국어가 없어요. 오히려 기회예요. 구조가 이미 다국어용으로 잡혀 있으니, 한국어 칸을 추가하면 국내 사용자에겐 훨씬 친절한 서비스가 돼요. 요즘은 LLM으로 1차 번역을 돌리고 사람이 다듬는 식으로 빠르게 채울 수도 있고요.
3. 데이터를 '내 것'으로 가져오되, 출처는 남기세요. 오픈 데이터를 쓸 땐 출처 표기가 기본 매너이자 안전장치예요. 이 프로젝트가 보여준 태도를 그대로 따라 하면 돼요.

학습 로드맵을 살짝 제안하자면 이래요. ① 먼저 데이터셋을 내려받아서 구조(스키마)를 눈으로 익히고요. ② 그다음 SQLite 같은 가벼운 DB에 직접 넣어보면서 "데이터를 DB에 적재한다"는 감을 잡아요. ③ 그 위에 간단한 API를 하나 올려서 "가슴 운동만 골라서 보내줘" 같은 요청을 처리해보고요. ④ 마지막으로 LLM 프롬프트를 붙여서 "오늘 등 운동 루틴 짜줘" 같은 AI 추천 기능까지 얹어보면, 데이터 → DB → API → AI로 이어지는 백엔드 흐름 전체를 운동이라는 친숙한 소재로 한 바퀴 돌게 되는 거예요. 이건 어떤 분야든 통하는 기본기라서 정말 좋은 연습이에요.

마무리

이 프로젝트가 던지는 진짜 메시지는 "운동 데이터 여기 있어요"가 아니에요. "데이터는 이제 도구와 한 묶음으로 온다"는 흐름, 그리고 "공개 데이터라고 다 마음대로 쓸 수 있는 건 아니다"라는 현실, 이 두 가지예요. 데이터셋이 단순한 파일 더미에서 벗어나 설계도와 사용 설명서까지 챙겨주는 방향으로 진화하고 있고, 동시에 출처와 권리를 투명하게 밝히는 문화가 자리잡아 가고 있는 거죠. 앞으로 좋은 오픈 데이터일수록 "바로 굴릴 수 있게 친절하게, 그리고 권리관계는 정직하게"라는 두 가지를 동시에 갖추게 될 거예요.

여러분은 어떠세요? 사이드 프로젝트 할 때 데이터를 직접 모으는 편인가요, 아니면 이렇게 잘 정리된 공개 데이터셋을 찾아 쓰는 편인가요? 그리고 공개 데이터를 가져다 쓸 때 라이선스를 어디까지 확인하시나요? 혹시 "이건 괜찮은 줄 알고 썼다가 식겁했다" 하는 경험 있으면 댓글로 나눠주세요. 다들 한 번쯤 겪는 일이라, 서로의 경험이 진짜 좋은 교과서가 되거든요.

---

🔗 출처: GitHub