LMS 마이페이지

문제 상황 대학 운영 환경에서 다른 장시간 Job이 공용 큐를 점유하면 스마트알림이 제시간에 발송되지 않았다. 이후 로그 분석에서는 한 고객 환경의 출결 상태 이력 재계산이 약 296만 건까지 커지는 경로도 확인됐다.

문제 정의 알림 생성 로직만 빠르게 만드는 문제가 아니라, 불필요한 이벤트가 과도하게 생기고 시간 민감 작업이 다른 Job과 실행 자원을 공유하는 구조가 핵심이었다.

가설 실행 경로를 먼저 격리하고, 변경이 없는 상태와 지원하지 않는 컴포넌트를 앞단에서 제거하면 운영 지연을 더 작은 단위로 통제할 수 있다고 봤다.

행동 스마트알림 전용 큐와 PM2 워커를 분리했다. 이후 학생×과목 단위의 미변경 이벤트를 억제하고, 처리 가능한 학습유형 선필터·수강 섹션 캐시·병목 구간 누적 로깅과 회귀 테스트를 추가했다.

성과 초기 부하 검증에서 3개 과제·2,000명 대상의 동시 마감 알림이 2분 내 도착했다. 운영 단계에서는 시간 민감 작업이 공용 큐에 밀리는 경로를 분리하고, 알림 재생성 전에 불필요한 후속 처리를 줄였다.

회고 현재 이벤트 판정 단위는 여전히 학생×과목이다. 학습요소 단위 증분 처리와 처리 시간·지연 p95 대시보드를 다음 단계의 명확한 과제로 남겼다.

문제 상황 한 화면에서 학기, 과목, 할 일, 공지, 게시물, 학습 부진과 평가 현황을 가져와야 했고 학생·교수자 역할마다 필요한 데이터가 달랐다.

문제 정의 모든 코드와 데이터를 한꺼번에 불러오면 역할 전환과 필터 상태가 얽히고, 학기를 바꿀 때 이전 조건이 남을 수 있었다.

가설 역할별 화면과 상태를 분리하고 현재 역할의 코드·데이터만 가져오면 불필요한 로딩과 상태 간섭을 줄일 수 있다고 봤다.

행동 역할별 화면을 React.lazy로 나누고 필터와 API 호출을 분리했다. 학기 변경 시 필터를 초기화하고 사용자 설정은 계정 단위로 저장했다.

성과 선택한 역할의 코드와 데이터만 불러오고, 학기와 역할 변화에 맞춰 관련 상태를 초기화하는 구조를 만들었다.

회고 구조 개선은 설명할 수 있지만 로딩 시간과 요청 수의 전후 측정은 남아 있지 않다. 성능 성과로 주장하기보다 책임 분리 사례로 제시하는 편이 정확하다.

문제 상황 3개월 동안 12종의 화면과 API를 개발한 뒤, 2주 안정화 기간에 132개 QA 항목이 접수됐다.

문제 정의 항목 수 자체보다 데이터 정합성 오류와 기능·UX 이슈가 섞여 있어 처리 순서가 불명확한 것이 문제였다.

가설 데이터 정합성 → 기능 → UX 순으로 분류하면 사용자 영향이 큰 오류부터 닫고 남은 작업을 예측할 수 있다고 봤다.

행동 항목을 유형별로 묶고 우선순위를 정해 기획·QA와 처리 순서를 공유했다. 기존 코드의 관례와 데이터 흐름도 먼저 확인한 뒤 수정했다.

성과 2주 안정화 기간의 작업을 우선순위에 따라 처리했다. 132개라는 수치는 품질 성과가 아니라 조정한 작업 범위를 뜻한다.

회고 종료 후 Post-Mortem에 재작업 원인과 다음 검증 항목을 기록했다. 이후 프로젝트에서는 QA 전에 데이터 흐름과 예외 상태를 먼저 점검하는 절차로 반영했다.

문제 상황 마이페이지는 Canvas LMS의 Global LTI iframe에서 렌더링돼 콘텐츠 높이, 모달 위치와 스크롤이 부모 페이지와 어긋났다.

문제 정의 자식 화면만 수정해서는 부모 문서의 높이와 스크롤 위치를 알 수 없고, LMS 내부와 외부 임베딩의 부모 DOM도 달랐다.

가설 부모와 자식이 높이·스크롤 정보를 메시지로 교환하면 두 실행 환경에서 같은 화면 동작을 만들 수 있다고 봤다.

행동 window.parent.postMessage로 콘텐츠 높이를 전달하고 부모 스크롤을 바탕으로 모달을 배치했다. 두 부모 구조의 수신 처리도 각각 구성했다.

성과 콘텐츠 잘림과 모달 위치 문제를 줄이고 LMS 내부·외부 임베딩을 모두 지원했다.

회고 정성적 동작 확인만 남아 있다. 브라우저·해상도별 회귀 테스트와 오류 건수 전후를 기록하면 더 설득력 있는 사례가 된다.