앱의 가이드라인은 산업분야, 앱의 목적에 따라 달라집니다. 전체이용가의 경우 심사가 더욱 꼼꼼해지고, 뉴스는 교육자료보다 더욱 엄격한 규제가 적용됩니다. 모든걸 완벽하게 파악하려해도 나와 경우가 조금씩 다르기에 일단 심사를 신청하고 빠르게 피드백을 하는것이 훨씬 유리합니다.
아래는 제가 반려된 사유 중 하나입니다. openapi를 기반으로 정책을 알려주는 뉴스형이라고 생각하여 뉴스 카테고리를 분류하였더니, 뉴스 기사를 확인하지 못하면 반려가 됩니다. 저는 정책을 사람들에게 쉽게 알려주고 요약해주는 앱이기에 뉴스보단 교육 카테고리에 적합했습니다. 간단하게 카테고리를 변경하느 것만으로 문제를 빠르게 개선할 수 있었습니다.
아래는 정부의 정책을 openapi를 사용하고 있을 경우에 설명서에 정보 링크에 대한 사실을 표기해야합니다. 이를 앱 설명문가에 간단하에 openapi 링크를 첨부하는 것만으로 해결할 수 있었습니다.
2. 크몽등 외주를 통한 비공개 테스트
비공개 테스트의 경우 꾸준히 업데이트를 하고, 지속적인 사용을 하는 것이 중요합니다. 단순하게 다운로드 한번만 했더니 저 같은 경우에 테스터의 지속적인 참가가 없었기 때문에재심사대상이 되었습니다. 하지만 12명 이상을 14일동안 지속적으로 접속하게 하는 것은 지인을 통해서 부탁하더라도 쉽지 않기에 크몽을 통해서 간단하게 1만원 내의 비용으로 테스트를 부탁하는 것이 편했습니다. 제 경우에는 추후 프로덕션 신청시에 필요한 답변 예시도 제공해주셔서 편했습니다.( 테스트 같은 경우에 크몽에 굉장히 많은 업체가 존재해서 가격이 합리적인 업체를 선정했었습니다.)
혹시 직접 테스트 하실 분들도 계실테니 그럴 경우에는 아래 조건을 준수해야합니다.
1. 앱을 비공개 테스트 기간 내에 2번 이상 업데이트 (단순한 버전 변경이라도)
2. 지속적인 접속
이 경우에도 결국 앱을 업데이트를 해야하기 때문에 굳이 완벽한 앱을 처음부터 자체 테스트로 만든 후 배포하는 것 보다, 비공개 테스트 기간에 개선하는 것이 더 유리하다고 느꼈습니다.
위 웹페이지는 바이브 코딩을 통해서 만들어낸 프로젝트입니다. 해당 프로젝트를 진행하면서 느낀 경험을 공유하려고 합니다.
우선 해당 프로젝트에 대해서 간략히 설명을 하겠습니다.
'이터널 리턴'이라는 게임에서 밸런싱을 위해서 패치노트가 생성이 됩니다. 그리고 각각의 실험체에 대한 패치내역이 존재합니다.
현재 이터널리턴 전적 검색 사이트인 dak.gg 와 공식 홈페이지에서는 패치내역에 대해서는 공유하지만 각 실험체에 대한 패치내역 필터링 기능이 존재하지 않습니다. 따라서 해당 정보를 '크롤링'을 통해 수집하여 상향,하향,조정 여부를 측정하여 유저에게 제공하는 것이 제 목표입니다.
해당 페이지에서 더보기를 통해서 패치노트를 추가로 호출할 수 있는데, html 구조에서 link 버튼속의 url을 크롤링하면 된다고 판단하였습니다.
2. 해당 패치노트 링크중에서 유효한 패치노트를 필터링 하기 이터널리턴에서는 패치노트가 만료된 경우에 링크는 존재하지만 실제 페이지가 존재하지 않아서 리다이랙트 되는 경우가 있었습니다. 이를 필터링 할 필요가 있었습니다. 또한 실험체와 관련없는 패치내역은 저한테 필요하지 않았습니다.
3. 실험체 이름을 기준을 필터링 하기
실험체 영역에 존재하는 실험체 이름과 패치내역을 필터링할 필요가 있었습니다. 85개의 실험체 나무위키등을 활용해서 입력시키는 방법도 있지만, 그럴 경우 새로운 실험체가 생길때마다 직접 등록해야한다는 불편함이 생깁니다. 따라서 확장성을 확보하기 위해서는 기존에 없는 실험체 이름을 발견할 경우 자동으로 추가해주는 로직으로 만들 필요가 있었습니다.
4. 이후 키워드를 활용하여 1차적으로 패치내역의 성격 여부에 대해서 작성하게 할 필요가 있었습니다.
패치내역만 크롤링하는 것은 큰 의미가 없다고 생각했습니다. 상향 여부까지 알려주고, 시즌 별로 분류하면 유저에게 더 많은 가치를 제공할 수 있고, 유의미한 데이터로 가공할 수 있다고 판단하였습니다. 다만 게임 시스템적으로 단순히 수치의 상승 혹은 하락이 상향 혹은 하향에 직결되지 않았습니다. 따라서 보편적인 기준을 마련하여 상향 혹은 하향을 1차적인 필터링을 하도록 하였습니다.
이제 4가지 목표를 가지고 진행하여 느낀점들과 경험에 대해서 공유하고자 합니다.
느낀점 및 경험
1. 간단한 기능에 대해서 굉장히 잘 만들어준다. 패치노트 리스트를 크롤링 같은 경우에는 마크업 구조가 탄탄해서 손쉽게 얻을 수 있었습니다. 필요한 라이브러리의 설치 허가를 물어보고 Puppeteer를 활용하여 크롤링한 후에 패치 리스트를 수집하여 주었습니다. 유효하지 않은 패치노트 필터링도 손쉽게 하였고, 심지어 firebase를 효율적으로 사용하기 위해서 필요한 mcp 설치까지 도와주었습니다. 아래는 실제로 firebase mcp를 설치할 때 도움을 받은 채팅 내역입니다.
> 해당 브랜치에서는 이제 firebase에 mcp를 통해 연동하는 작업을 하려고 해. 현재 데이터는 전분 json형태로 관리되고 있는데, 이러면 수정에 용이하지 않다고 판단을 했어. 그래서 수정할 수 있도록 firebase에
연동하려고 해
● Firebase MCP 연동 작업이군요. 먼저 현재 JSON 데이터 구조를 파악해야 합니다.
● Search(pattern: "**/*.json")
⎿ Found 100 files (ctrl+o to expand)
● Explore(Explore project structure)
⎿ Done (14 tool uses · 37.2k tokens · 57s)
● 프로젝트 구조를 파악했습니다.
현재 데이터 구조
| 파일 | 용도 |
|---------------------------|--------------------------------------|
| data/balance-changes.json | 캐릭터별 패치 히스토리 (핵심 데이터) |
| data/patch-notes.json | 패치노트 메타데이터 |
데이터는 src/lib/patch-data.ts에서 로드되어 홈페이지와 캐릭터 상세 페이지에서 사용됩니다.
---
Firebase 연동을 진행하기 전에 몇 가지 확인이 필요합니다:
● User answered Claude's questions:
⎿ · Firebase 프로젝트가 이미 생성되어 있나요? → 아직 없음
· 어떤 Firebase 데이터베이스를 사용할 예정인가요? → Firestore (권장)
· Firebase MCP 서버가 이미 설정되어 있나요? → 설정 안됨
● Firebase 설정부터 시작해야 하겠네요. 전체 작업을 정리하겠습니다.
● 1단계: Firebase 프로젝트 생성
Firebase Console에서 프로젝트를 생성해주세요:
1. https://console.firebase.google.com/ 접속
2. "프로젝트 추가" 클릭
3. 프로젝트 이름 입력 (예: vibe-patch-tracker)
4. Google Analytics는 선택사항 (비활성화해도 됨)
5. 프로젝트 생성 완료
Firestore 활성화
1. 좌측 메뉴 "빌드" → "Firestore Database" 클릭
2. "데이터베이스 만들기" 클릭
3. 위치: asia-northeast3 (서울) 선택
4. 보안 규칙: "테스트 모드에서 시작" 선택 (개발용)
서비스 계정 키 생성 (MCP 연동용)
1. 프로젝트 설정 (톱니바퀴 아이콘) → "서비스 계정" 탭
2. "새 비공개 키 생성" 클릭
3. JSON 파일 다운로드 → 프로젝트 루트에 firebase-service-account.json으로 저장
---
위 과정을 완료하면 알려주세요. 그 다음 Firebase MCP 설정을 진행하겠습니다.
> 완료했어
2. 토큰 개수로 인한 대기 시간
저는 pro 요금제를 사용하고 있어서 토큰 사용량에 제한이 있었습니다. 크롤링하는 과정에서 많은 토큰이 소모가 되고 검사하는 과정에서 많은 토큰이 소모가 되었습니다. 또한 지난번에 했던 작업을 스스로 복귀하는데도 많은 량의 토큰이 소모가 되었습니다.
이를 통해서 인수인계 시스템을 만들 필요를 느꼈습니다. 내가 오늘 할당된 토큰 내에 작업을 끝내지 못하더라도, 다음번에 실행한 claude가 전날 내용을 인수인계 받도록 할 필요가 있었습니다.
이때 사용한 것이 claude.md 파일입니다. claude의 경우 해당 프로젝트에서 작업하기전에 먼저 Claude.md를 확인하고 작업을 진행합니다. 루트 경로에 아래와 같은 작업 규칙을 명시해서 작업로그를 작성하였고, 토큰이 만료되어도 다음 번에 이어서 작업할 수 있었씁니다.
## Claude 작업 규칙
### 작업 시작 전
1. `docs/work-logs/YYYY-MM-DD-작업명.md` 파일 생성
2. 목표, 실행 스크립트, 예상 단계 작성
3. 진행하면서 상태 업데이트
### 작업 로그 생성 시점
**명확한 작업 요청:**
> "OOO 기능 추가해줘" → 즉시 작업 로그 생성
**질문/디버깅으로 시작하는 경우:**
> "왜 안 돼?", "이거 뭐가 문제야?" → 원인 분석 → 해결책 제안
이 경우 다음 시점에서 작업 로그 생성:
- 사용자가 해결책을 선택/확정할 때 (예: "3번 방식으로 해줘")
- 코드 수정을 시작하기 직전
### 작업 중단 시
- "중단 시 이어서 할 작업" 섹션에 다음 단계 기록
- 상태를 "중단"으로 변경
### 작업 재개 시
- 작업 로그 파일 읽고 이어서 진행
- 새 날짜 섹션 추가하여 진행 상황 기록
3. 복잡한 작업의 경우 목적을 이루기 위해서는 더욱 자세한 지시 및 가이드라인이 필요함
패치노트의 경우에 게임사 관리자가 직접 작성하는데, 해당 내용이 일관되지 않은 경우가 종종 있었습니다. 마크업 구조가 점점 다르고, 이로 인해서 오차가 점점 생겼습니다. 이를 정정하기 위한 작업을 진행하였는데, 코드가 효율적이지 못한 경우도 경험하였습니다.
이터널리턴에서는 기본적으론 h5 태그를 사용하여서 카테고리를 구분합니다.
대부분의 패치노트에서는 실험체 탭에 패치내역이 정리가 되어있었습니다. 하지만 기본적으로 스크립트가 실험체 라는 단어와 정확히 일치하는 경우에 크롤링하는 로직으로 작성되어 있었습니다. 하지만 '실험체 및 아이템 주요 패치의도' 라고 특정 패치노트에서는 기존과 양식이 다른 경우도 존재하였습니다.
또한 패치내역을 크롤링하는 로직이 효율적이지 않은 경우도 종종 있어서 효율적으로 지시할 필요가 있었습니다.
따라서 어떤 작업을 어떻게 진행할지에 대한 가이드라인을 먼저 md에 정리하고 저한테 공유하도록 지시하였습니다. 이후 해당로직을 확인하고 효율성을 개선할 수 있는 부분에 대해서는 검증하는 방식으로 진행하였습니다.
4. mcp를 적극적으로 활용할 필요성
next.js를 처음에 설치할떄도 claude를 사용하였는데, 다행스럽게 최신 버전의 next.js를 설치해주었습니다. 하지만 tailwind를 사요할 떄는 옛날 문법을 사용하는 경우가 생겨서 lint 경고가 발생하였습니다. 이를 위해서 Context7 mcp를 활용하면 AI가 최신 버전의 문법을 사용하도록 할 수 있습니다.
결론
지속적인 비용 부담 때문에 도입을 조금 늦게 하였는데, 확실히 업무 효율성을 굉장히 높여준다는 사실을 체감하였습니다. 또한 어떻게 효율적으로 지시할지에 대한 고민이 앞으로 더욱 필요하다는 점을 느꼈습니다.
