모두의 문제집
개발일지
개발 기록 58 · 1 / 6 페이지
최근 기록순풀이 이력이 쌓일수록 느려지는 모의고사 문항 추출 개선
SKCT 문항 추출은 적게 본 문항을 먼저 고르기 위해 후보 문항마다 해당 사용자의 노출 횟수를 셌다. 후보가 1,700개이고 풀이 이력이 50,000행이면, 정렬 중 각 후보에 대해 응시·문항 이력을 다시 탐색하게 된다. 후보 목록에 인덱스가 있어도 정렬 키를 계산하는 상관 서브쿼리 비용은 남았다.
채점 성공 뒤 브라우저 풀이 기록이 사라지는 문제 해결
일반 문제 풀이에서 서버 채점 응답을 받은 직후 브라우저 저장이 실패하면, 결과는 화면에 보였지만 다시 열었을 때 풀이 기록이 사라질 수 있었다. 채점 성공과 브라우저 기록의 영구 저장은 서로 다른 단계였다.
안전 조건이 중첩되며 D1 SQL 한도를 넘는 문제 해결
폐기 대상 실기 콘텐츠를 정리하는 SQL은 삭제 전 상태를 정확히 비교하고, 대체 콘텐츠 준비 여부와 학습 기록 연결 여부를 검사했다. 각각의 조건에 JSON 탐색·집계·여러 테이블의 EXISTS가 포함됐다. 이 SQL을 감사 기록의 SELECT·WHERE 안에 다시 삽입하면서 표현식 트리가 깊어졌다.
원본 변경으로 안전 백업 재개가 막히는 문제 해결
실기 콘텐츠 반영 전 안전 백업은 여러 요청에 걸쳐 원본 테이블을 읽었다. 첫 페이지를 저장한 뒤 다음 페이지를 수집하는 동안 원본 행이 추가·삭제되면, 처음 세어 둔 행 수와 실제 수집 결과가 달라졌다. 백업 검사는 이를 원본 변경으로 판단해 재개를 차단했다.
그룹 시험의 마지막 선택이 다음 문항 요청에 반영되지 않는 문제
그룹 시험에서 첫 선택의 저장이 끝나기 전에 답을 바꾸고 바로 다음 문항으로 이동하면, 화면과 다음 요청의 답안이 달라질 수 있었다. 선택 인덱스 [1]을 누른 뒤 [3]으로 바꾼 재현에서는 답안 저장 요청이 [1] → [3] 순서로 완료됐지만 다음 문항 요청은 [1]을 담았다.
SKCT API의 반복 DB 왕복 호출 줄이기
SKCT의 답안 저장·모의고사 시작·그룹 상태 갱신은 HTTP 요청 하나 안에서 DB를 여러 번 왕복했다. 계정·점검 상태를 읽고, 응시 기록을 조회한 뒤, 변경을 커밋하고 결과를 다시 읽는 작업이 각각 실행됐다. 종료 시각이 지난 그룹을 정리하는 경로에서는 참가자와 시험 상태를 확인하는 호출까지 겹쳤다.
가이드의 미방문 RSC 요청과 공통 탐색의 사전 로드 변경
공개 가이드 /guides/sqld의 첫 방문에서 누르지 않은 /, /privacy, /about, /guides의 RSC가 4개 요청됐다. 모바일 Lighthouse 3회에서 합계 전송량은 17,223–17,240B였다. header/footer의 보조 탐색까지 기본 next/link로 렌더해, 화면에 노출된 경로를…
모바일 관리자 drawer의 포커스 이동과 Escape 복귀 보강
모바일 관리자 메뉴를 열면 sidebar에 open class가 붙어도 초점은 열기 버튼에 남았다. DOM에서 sidebar가 열기 버튼보다 앞에 있어 순방향 Tab으로 내부에 진입하기 어려웠고, Escape 처리도 빠져 있었다.
목록 복귀 시 검색 조건 유지: URL 쿼리와 return_to
필터 목록 URL에는 q·category·topic이 있었지만 상세 링크에서 복귀 주소가 누락됐다. 돌아가기 링크는 document.listPath만 가리켜 상세를 다녀오면 기본 목록으로 돌아갔다.
SQLD 과목 번호 표시 수정: 배열 인덱스 대신 과정 정의
SQLD에서 “SQL 기본 및 활용” 기록만 남으면 화면에는 1과목으로 표시됐다. 과목 번호를 과정 정의 대신 화면 배열의 categoryIndex + 1로 계산했기 때문이다. “데이터 모델링의 이해”를 두 번째 위치에 놓으면 같은 이유로 2과목으로 바뀌었다.