[앱소개] 꼬뜨 피드 : 커뮤니티 통합 뷰어 iOS 앱

댓글 4

1. 쩐의여왕 · 2026-09-21 12:24:05

   동시 접속 걱정을 적어두셔서 그쪽만 보면, 워커를 무료 플랜으로 쓰고 계시다면 숫자 두 개가 먼저 걸릴 것 같습니다. 공식 문서 기준으로 무료 플랜은 하루 요청 10만 건이고 UTC 자정, 그러니까 한국 시간 오전 9시에 초기화되며 넘으면 1027 오류가 뜹니다. 요청 하나당 CPU 시간도 10ms라서, 글목록 HTML 파싱을 워커 안에서 하고 계시면 사용자 수보다 이쪽이 먼저 걸릴 수 있습니다.
   
   같은 게시판 목록은 누가 불러도 결과가 같으니 수십 초만 캐시를 둬도 요청 수와 파싱이 같이 줄어듭니다. 다만 워커의 Cache API는 요청이 들어온 데이터센터에만 저장되고 다른 곳으로 복제되지 않는다고 적혀 있어서, 적중률은 기대보다 낮게 잡고 보시는 게 안전합니다.
   
   파싱은 앱에서 하시는지 워커에서 하시는지 궁금하네요.
2. 꼬뜨 · 2026-09-21 13:32:24

   @쩐의여왕님 피드백 감사합니다. ㅎㅎ 안그래도 정식 빌드 막바지까지 전체파싱을 워커에서 처리하고, 워커에서 접근 불가능한 커뮤니티만 기기파싱으로 돌리고 있었습니다. 혼자서 테스트 하는데도 로그를 보니 워커 파싱 접근이 꽤 되고, 시뮬레이션을 돌려보니 파싱요청이 한꺼번에 몰리면 실패 확률이 높다고 떠서, 마지막에 파싱을 앱에서 기본으로 하고 워커는 보조 파싱 및 파서 카탈로그 버전 관리, 보드 전체 목록, 앱 네이티브 보드 외 추가게시판 관리 정도로 나눠서 역할을 배분했네요. 초반 테스트를 하면서 사용자가 늘면 워커도 유료 플랜으로 전환할 계획이구요. 아직 안가본 길이라 테스트하면서 문제가 생기면 대응할 생각인데 잘 되려나 모르겠네요. 또 궁금한거 있으면 적어주세요~
3. 쩐의여왕 · 2026-09-22 12:23:51

   @꼬뜨님 기본을 기기 파싱으로 돌리신 게 맞는 방향 같습니다. 요청이 사용자 기기마다 흩어지니 워커 한도 걱정은 확실히 줄겠네요.
   
   그 구조면 이제 관건은 파서 카탈로그 쪽일 것 같습니다. 사이트 하나가 마크업을 바꾸면 그 게시판만 비는 날이 생기니까, 앱을 켤 때 카탈로그 버전만 가볍게 확인하고 바뀐 경우에만 내려받게 해두시면 대응이 빨라질 것 같아요.
   
   한 가지 조심하실 건, 카탈로그가 셀렉터 같은 데이터면 괜찮은데 스크립트를 내려받아 실행하는 형태가 되면 앱스토어 심사 가이드라인 2.5.2(앱 기능을 바꾸는 코드를 내려받아 실행하는 것 금지)에 걸릴 수 있다는 점입니다. 파서를 원격으로 고칠 수 있게 만들다 보면 자연스럽게 그쪽으로 가게 되더라고요.
4. 꼬뜨 · 2026-09-22 17:24:33

   @쩐의여왕님 맞습니다. 지금은 번들 보고 바뀌었을 때만 받도록 하고 TTL만 일단 설정해둔 상태입니다. 말씀하신 가이드라인은 몰랐는데 신경써야 겠네요. 대충 물어봤더니 앱 본래 목적 유지시엔 허용되는 경우가 있나보군요. 일단 원격으로 간단하거나 급한 경우에만 카탈로그 수정하고, 급하지 않거나 기본적인 목록 변경은 업데이트로 올리려고 생각만 하고 있었습니다 ㅎㅎ 말씀하신 셀렉터도 공부해보고 검토해 봐야겠네요. 좋은 지적 감사합니다.