학원 데이터·API 자동화 설계 브리프

자동화 목표가 'AI를 해보고 싶다'가 아니라 줄일 업무 3개로 표현되어 있다.

수업 전 안내, 수업 중 모니터링, 수업 후 리포트 중 우선순위가 정해져 있다.

선생님이 수동으로 보내는 알림과 운영팀이 수동으로 만드는 보고서를 구분했다.

학부모 상담 전에 필요한 학생별 근거 자료가 무엇인지 적었다.

결석, 과제 미제출, 보강 대상 학생을 찾는 현재 방식과 소요 시간을 알고 있다.

자동화 성공 기준을 시간 절감, 누락 감소, 상담 품질, 재등록 설득력 중 하나 이상으로 잡았다.

대표 반 1개에서 먼저 실험할 수 있는 작은 자동화 주제가 있다.

관리자 또는 허가된 교사 계정에서 수업 시간과 수업 특이사항을 확인할 수 있다.

네트워크 상태와 학생 참여 정보를 운영 판단에 활용할 필요가 있다.

수업 녹화, 수업 채팅, LMS 활동을 학생 관리 맥락에서 보고 싶다.

원장, 실장, 강사가 각각 봐야 할 데이터 범위가 다르다는 점을 알고 있다.

권한 없는 사람이 학생별 기록이나 수업 자료를 열람하지 않도록 역할을 나눌 수 있다.

관리자 대시보드로 충분한 지표와 API로 가져와야 할 지표를 분리했다.

수업 데이터가 강사 개인 파일이나 개인 메신저에만 남지 않도록 기관 기준을 세웠다.

수업 전 리마인드, 보강 안내, 과제 안내처럼 반복 발송되는 메시지를 나열했다.

ClassIn 앱 푸시로 해결할 수 있는 알림과 카카오/문자/이메일이 필요한 알림을 나눴다.

일괄 알림의 발송 대상, 발송 조건, 발송 후 확인 기준을 정했다.

선생님이 수동으로 보내던 안내 중 운영팀이 표준화해야 할 메시지를 찾았다.

알림 자동화가 학부모에게 과도하게 느껴지지 않도록 빈도와 문구 기준을 세웠다.

개인정보가 포함된 메시지와 단순 안내 메시지를 구분했다.

알림 실패나 미확인 학생을 누가 후속 처리할지 정했다.

코스, 반, 수업, 학생, 강사 정보를 어떤 내부 기준으로 매칭할지 정했다.

수업 시간, 출석/참여, 녹화, 과제 상태를 학생 리포트에 넣을지 결정했다.

일간/주간/월간 보고서 중 실제 의사결정에 쓰일 보고서 주기를 정했다.

학생별 리포트를 자동 생성할 때 담을 핵심 문장과 제외할 민감 정보를 정했다.

수업 데이터와 기존 CRM, Notion, Google Sheet, 자체 DB를 연결할 후보가 있다.

API로 가져온 데이터가 틀리거나 누락될 때 확인할 원본 화면과 담당자를 정했다.

리포트 UI가 약한 영역은 자체 제작하거나 BI/시트로 먼저 검증할 수 있다.

SDK나 수업 중계가 필요한 이유가 명확한 대형 운영 시나리오가 있다.

별도 계정 발급, 수업 화면을 다른 서비스로 내보내기, 외부 시스템 연동을 '기능 하나 켜 달라'가 아니라 어떤 운영 흐름을 만들고 싶은지로 설명할 수 있다.

개발 범위, 보안 검토, 테스트 기간, 장애 대응 담당자를 따로 잡아야 함을 이해했다.

공식 API 문서를 기준으로 가능한 것과 기술 검토가 필요한 것을 구분한다.

처음부터 3단계 연동을 하지 않고 1단계 알림, 2단계 데이터 조회로 검증할 계획이 있다.

연동 후에도 결제, 오프라인 출입/출석, 고급 경영 리포트는 별도 시스템 후보로 남길 수 있다.

기술 담당자와 원장이 같은 언어로 볼 수 있는 요구사항 문서가 필요하다.

자료 다운로드, 자료 열람, CTA 클릭, 상담 신청이 내부 이벤트로 남는 구조를 이해했다.

외부 픽셀은 동의 기반으로 운영하고, 자료 파일 안에 임의 추적 코드를 심지 않는 원칙을 세웠다.

리드 스코어는 다운로드 자료, 상담 CTA, 도입 일정, 하드웨어 관심도를 함께 보고 판단한다.

학생 개인정보와 학부모 상담 자료를 마케팅 추적 데이터와 섞지 않는다.

권한 회수, 자료 접근, 다운로드 기록 삭제 요청에 대응할 운영 기준이 있다.

자동 리포트가 학생을 낙인찍는 표현을 쓰지 않도록 문구 검수 기준을 둔다.

데이터 자동화가 선생님의 감각을 대체하는 것이 아니라 놓치는 학생을 줄이는 보조 도구임을 설명할 수 있다.