AI와 빠르게 만들고,
시스템은 끝까지em.focus 이해합니다.

// 왜 이 구조였나

문제

영상을 전환하거나 다시 열면 진도와 이어보기 위치가 실제 재생과 어긋났습니다. 같은 콘텐츠의 요청 순서가 지켜지지 않은 탓이었습니다. 이전 실행의 종료와 새 실행의 시작이 엇갈리거나, 저장이 끝나기 전의 조회 결과가 늦게 도착해 위치를 되돌렸습니다.

순서

같은 콘텐츠의 요청은 순서를 지킵니다. 이전 실행의 종료가 끝난 뒤 새 실행을 시작하고, 진도는 저장이 끝난 뒤에 조회합니다. 다른 영상으로 넘어가는 것까지 늦어지지 않도록 같은 콘텐츠에만 적용했습니다.

권한

콘텐츠 ID가 같아도 실행이 다르면 다른 것으로 봅니다. 이전 실행의 응답은 그 실행을 마무리하는 데만 씁니다.

단순하게

숫자로 ‘세대’를 세던 방식 대신, 실행 하나를 하나의 수명으로 보고 끝난 실행의 늦은 결과는 반영하지 않는 기준으로 정리했습니다.

결과

세션 복구 보완과 함께 2주간 접수된 관련 문의 3건을 해소했습니다.

// 왜 이 구조였나

상황

강사는 여러 학습자를 골라 점수와 피드백을 한 번에 등록합니다. 점수와 피드백은 서로 다른 API라 둘 중 하나만 성공할 수 있습니다.

문제

실패한 뒤 그대로 다시 등록하면 이미 반영된 점수까지 다시 보냅니다. 그렇다고 무조건 건너뛰면, 그사이 선택한 학습자나 점수, 서버 쪽이 바뀐 경우를 놓칩니다.

판단

성공한 점수 요청을 누구에게, 어떤 값으로, 어떤 서버 기준에서 보냈는지 기록합니다. 셋이 그대로일 때만 건너뛰고 피드백만 다시 보냅니다.

// 왜 이 구조였나

문제

공유하던 것은 두 제품의 공통 UI뿐이었습니다. 새 제품은 같은 콘텐츠를 다른 화면으로 보여줘야 했습니다. 예를 들면 설문을 한 페이지에 한 문항씩.

질문

‘어떤 화면을 공유할까’ 대신 ‘화면이 달라도 같아야 하는 것은 무엇인가’를 물었습니다. 답은 입력 상태와 작업 순서였고, 이를 헤드리스 코어로 뽑았습니다.

기준 1

검증 함수만 떼어내는 공통화는 하지 않았습니다. 쓰는 쪽이 같은 흐름을 다시 조립하게 되므로 저장·제출 순서까지 코어에 담았습니다.

기준 2

코어가 제품 상태를 중계만 하는 중간 계층이 되지 않도록, 상태 자체를 코어가 소유하게 했습니다.

// 왜 이 구조였나

번들

설정이 node_modules 전체를 한 번들로 묶어 첫 진입 JS만 500kB 가까이 됐습니다. 기본 분할을 막던 설정을 걷어내고, MSW와 분석 도구는 필요한 시점에만 불러오게 했습니다.

인증

클라이언트와 서버가 인증을 각자 처리해 같은 코드가 두 벌이었고, 토큰은 스크립트에서 접근할 수 있었습니다. Route Handler 한 경로로 모으고 토큰을 HttpOnly 쿠키로 옮겼습니다.