-
Notifications
You must be signed in to change notification settings - Fork 0
3주차 회고
기능 구현
- namumark 렌더링 실패 시 복구 링크 표시 (이슈 #50)
- 렌더링 완료 전 링크 연타 이동 중복 차단 (이슈 #57)
- 이동 히스토리 사이드바 신규 항목 자동 스크롤 (이슈 #59)
- 랜덤 문서 선택을 ID 기반 전체 pool로 개선 (이슈 #60)
- 닉네임 localStorage 저장 및 복원 (이슈 #61, #63)
- 게임 포기 확인 모달 추가 (이슈 #62)
- 게임 시작 시 초기 문서 렌더링 완료 후 타이머 시작 (이슈 #65)
- 리더보드 개편 — 날짜별/랜덤도전 탭 분리, 정렬 기준 선택 (이슈 #68)
- 로비 게임 방법 안내 섹션 및 목차 네비게이션 추가 (이슈 #71)
- 게임 화면 목표 문서 설명 AI 요약 툴팁 추가 (Gemini API, 이슈 #76)
- Gemini 요약 재시도 로직 추가 (이슈 #77)
UI/UX 개선
- 메인 로비 UI 재설계 (compact hero + 2개 게임 모드 카드)
- 게임 화면 UI 재설계 (헤더 레이아웃, 경로 사이드바 스텝 번호, 게임 포기 모달)
- 새로고침 시 게임 상태 자동 복원 (sessionStorage)
- 렌더링 실패 시 "이전 문서로" / "랜덤 문서로" 복구 버튼
- CC BY-NC-SA 2.0 KR 라이선스 푸터 추가
코드 품질 & 자동화
- 98개의 커밋 (2주차 30개 대비 3배 이상)
- auto-develop 파이프라인 안정화 — 파일 충돌 시 브랜치 base 자동 변경
- 이슈 당 자동 PR 생성으로 병렬 작업 가능
이슈 품질 기준을 명확히 한 후 (시작점 파일 필수, 완료 조건 체크리스트), 여러 이슈를 동시에 /auto-develop으로 실행 가능하게 개선했습니다. 결과적으로 2주차 대비 3배의 커밋이 10일 내에 나왔으며, 이는 "각 단계 승인"이라는 수동 게이트를 제거했기 때문입니다.
코드를 구현한 뒤 Mintlify에서 문서를 보면 항상 최신 상태입니다. "코드는 업데이트됐는데 문서는 구 버전"이라는 문제가 사라졌습니다.
렌더링 실패, 연타 클릭, 새로고침 등 "정상 케이스가 아닌 상황"을 다루는 데 시간을 보냈는데, 게임으로서 이것이 얼마나 중요한지 실감했습니다.
namumark-clone-core가 기술적으로는 정확하지만 시각적으로는 불완전했습니다.
문제 사례:
- 표의 셀 너비가 원본과 다름 → 텍스트 줄바꿈 달라짐
-
{{{#!html}}}블록이 원문 그대로 텍스트로 출력됨 -
[include(틀:...)]가 완전히 숨겨짐 -
$1.30같은 달러 금액이$1,$2캡처 그룹으로 해석되어 RangeError 발생 - 몇몇 문서는 JSON 형식 깨짐/무한 재귀로 렌더링 자체 실패
해결 방식:
- PUA 유니코드(U+E025/U+E026)로
{{{#!html}}}토큰화 후 복원 - 수작업으로 정규식 작성해 known 틀(
틀:다른 뜻,틀:네모틀등) 선택 변환 -
$이스케이프: 파싱 전U+E024로 치환, 파싱 후 복원 - Worker에 에러 핸들링 추가, 렌더링 실패 시 복구 버튼
시간 소비: 3주차 전체 98개 커밋 중 30% 이상이 렌더링 및 엣지케이스 대응에 쓰였습니다. 리더보드 고급 기능, 모바일 최적화 등을 더 할 수 있었을 텐데, 기본기를 다지느라 시간이 많이 들었습니다.
1. 자동화 파이프라인도 "70점"
/auto-develop이 도중에 멈추거나 파일 충돌 처리가 필요할 수 있으며, 여전히 사람의 개입이 필요한 경우가 있습니다. 결국 자동화 파이프라인 자체도 지속적으로 유지보수해야 하는 코드임을 깨달았습니다.
2. "완벽함을 추구"하는 것이 시간낭비일 수 있다 렌더링이 "정확해야 하는가" vs "게임에 지장 없으면 되는가"의 줄다리기를 매주 했습니다. 결국 "링크가 동작하고 텍스트가 읽을 수 있으면 OK"로 결정했는데, 이를 처음부터 명확히 했으면 2주차부터 엣지케이스 whack-a-mole을 피할 수 있었을 것 같습니다.
3. 데이터 검증을 초기에 해야 한다 "867K개 문서가 있으니까 당연히 다 렌더링 되겠지"라는 가정이 나이브했습니다. 1주차 시점에 샘플 100개 문서로 렌더링 프로토타입을 실행했으면, "이 라이브러리는 70점짜리다"를 명확히 인식하고 2주차부터 틀 토큰화를 도입할 수 있었을 것 같습니다.
- 1주차: ~10개 커밋 (구조화)
- 2주차: ~30개 커밋 (자동화 파이프라인 구축)
- 3주차: ~98개 커밋 (대규모 기능 구현)
총 138개 커밋, 15개의 PR, 867,024개 문서의 게임화 완성.
2주차 회고에서 "이슈가 모호하면 자동화가 삐끗한다"고 했는데, 3주차에는 그 교훈을 잘 적용해서 안정적인 속도를 냈던 것 같습니다.
"자동화는 도구일 뿐, 판단은 사람이 한다" 는 균형을 유지하면서 개발하고 싶습니다.