복잡한 운영 문제를 구조로 풀고,제품의 시작부터 결과까지 책임집니다.

학생·교강사·운영자가 함께 사용하는 LMS에서는 역할과 과정 상태에 따라 같은 기능도 접근 가능 여부와 표시 정보가 달랐습니다. 화면마다 조건문을 추가하면 권한 정책과 캐시가 서로 다른 기준을 갖기 쉬웠습니다.

제한 시간 평가는 새로고침과 뒤로가기에서 답안·현재 문제·남은 시간이 어긋날 수 있었고, 영상은 이용 증가에 따라 비용과 재생 문제가 함께 커졌습니다. 프로젝트·평가·실습에는 10GB가 넘는 파일도 사용됐습니다.

권한과 평가 규칙을 개별 화면의 예외 처리가 아니라 역할·서버 상태·로컬 작성 상태의 경계로 관리하고자 했습니다.

영상과 업로드는 정상 경로뿐 아니라 브라우저 자원, 네트워크 실패와 화면 전환까지 고려해 운영 가능한 구조로 만드는 것을 목표로 했습니다.

• 과정당 약 50~75명, 동시에 2~4개 과정이 운영되는 범위에서 V2·V3 프론트엔드를 구축·운영했습니다.
• 7개 역할과 복수 역할의 우선순위·기본 경로·전환 흐름을 공통 기준으로 관리했습니다.
• 영상 이동 시 서로 다른 contentId로 발생하던 진도 요청을 현재 콘텐츠 한 건으로 줄였습니다.
• 12~14GB 실제 영상 파일의 업로드 완료를 확인했습니다.
• HLS 전환 뒤 비용과 재생 경험이 안정됐다는 협업자·운영자의 정성 피드백을 확인했습니다.

복잡한 프론트엔드 문제는 조건문의 수보다 역할, 서버 상태, 로컬 작성 상태와 자원 생명주기의 경계가 불분명할 때 커졌습니다.

기술 선택에서도 구현 가능성만 보지 않고 비용이 사용자·브라우저·서버·운영 조직 중 어디에 발생하는지를 함께 판단하게 됐습니다.

홈페이지·LMS·백오피스의 계정 체계를 통합하면서 기존 사용자가 비밀번호를 다시 설정하거나 새로운 사용자로 인식되지 않게 해야 했습니다.

이메일이 같아도 동일인이라고 단정할 수 없는 충돌 계정이 있었고, 잘못된 자동 병합은 다른 사용자의 데이터 접근으로 이어질 수 있어 편의보다 정확성과 복구 가능성이 중요했습니다.

사용자 신원과 서비스별 역할·수강 데이터를 분리하면서 기존 ID와 비밀번호 hash를 보존하는 것을 목표로 했습니다.

새 인증 경로에서 문제가 생겨도 기존 로그인으로 빠르게 돌아갈 수 있는 실제 복구 경로를 유지하고자 했습니다.

• 약 4,000명의 기존 사용자 ID와 비밀번호 hash를 보존한 계정 이관을 수행했습니다.
• 동일인 확인이 어려운 이메일 충돌 계정 10명 미만을 자동 병합에서 제외했습니다.
• 첫 전환 실패를 개발팀 접수 후 약 1시간 안에 기존 v1 로그인으로 복구했습니다.
• 보완 후 재배포했으며 같은 로그인 문제는 다시 보고되지 않았습니다.

인증 전환은 로그인 화면 교체가 아니라 사용자 식별 경계, 데이터 소유권과 실패 복구를 함께 설계하는 문제였습니다.

정상 전환만큼 token 수명과 폐기, 추적 가능한 감사 로그 같은 운영 안전장치를 단계적으로 갖춰야 한다는 기준을 얻었습니다.

기존 LMS의 TIL은 로그인한 과정 참여자만 볼 수 있어 수료 후 외부 포트폴리오나 지속적인 학습 기록으로 연결되기 어려웠습니다.

정해진 기획을 전달받은 프로젝트가 아니어서 어떤 사용자의 문제를 해결할지, 한 달 안에 어디까지 구현해야 제품 가치가 완결되는지, 출시 후 무엇으로 사용 여부를 판단할지 직접 정해야 했습니다.

기록이 피드에서 발견되고 프로필에 축적되며 성장과 관심사를 시각화한 뒤 URL로 공유되고 다시 기록으로 돌아오는 제품 루프를 목표로 정했습니다.

제품 기획과 애플리케이션 코드는 직접 담당하고 초기 큰 레이아웃과 배포 환경은 각 담당자에게 요청해 약 한 달의 일정 안에서 범위를 완결하고자 했습니다.

• 2026년 2월 중순 착수해 약 한 달간 집중 구축하고 3월 말 초기 제품을 공개했습니다.
• 2026-08-31 기준 가입 계정 약 100개와 게시글 341개가 누적됐습니다. 가입자는 대부분 학생·직원이며 외부 자연 유입 100명으로 표현하지 않습니다.
• 18주 주별 활성 작성자 WAW는 3~11명이었고 Search Console 누적 노출 70,841회·클릭 3,224회를 별도 지표로 확인했습니다.
• GA4에서 Gemini·ChatGPT·Perplexity referral과 Google AI Overview 참고 출처 한 사례를 관찰했습니다.

제품을 주도한다는 것은 기능 수가 아니라 문제를 정의하고 제한된 시간 안에서 가치가 완결되는 범위를 선택하며, 공개 이후 행동을 다음 판단으로 연결하는 일이었습니다.

검색 노출·클릭·WAW·제품 행동을 서로 다른 신호로 관리하고 확인하지 못한 인과관계는 성과로 주장하지 않는 기준을 갖게 됐습니다.

외주 PHP 홈페이지를 사내에서 유지·확장하기 어려웠고, 시각 콘텐츠 비중이 큰 첫 화면의 대용량 미디어가 렌더링을 지연시키고 있었습니다.

정적 배포 구조에서 콘텐츠 담당자의 작업 흐름을 유지하면서 미디어를 가볍게 만들고 검색엔진이 페이지 정보를 이해할 수 있는 기본 구조도 정리해야 했습니다.

조직이 유지할 수 있는 React·Next.js 기반으로 프론트엔드를 재구축하고, 체감이 아니라 같은 조건의 측정값으로 성능 개선 대상을 선택하고자 했습니다.

별도 runtime 변환 서버 없이 배포 전에 미디어를 변환하고 브라우저 호환 fallback을 제공하는 운영 흐름을 목표로 했습니다.

• 여러 미디어 중 대표 파일 한 건을 67.5MB에서 3.1MB로 줄였습니다.
• 동일한 데스크톱 환경에서 Lighthouse LCP 대표값을 3.1초에서 1.1초로 확인했습니다.
• Lighthouse SEO 대표값을 58점에서 92점으로 확인했습니다.
• WebM·MP4 변환 도구와 운영 문서를 만들어 초기 구축 이후의 반복 작업 기준을 남겼습니다.

브라우저 성능은 코드만이 아니라 첫 화면 자원, 렌더링 순서와 콘텐츠 제공 흐름을 함께 측정해야 하는 문제였습니다.

이후에는 단일 최고 점수보다 측정 대상과 조건을 먼저 고정하고, 공통화도 외형보다 변경 주기와 요구 수렴 정도를 기준으로 판단하게 됐습니다.

모집 담당자는 전화로 상담하고 결과를 엑셀에 기록했으며 일정은 외부 캘린더에서 관리했습니다. 정보가 담당자별 문서에 흩어져 이전 상담과 다음 행동을 이어보기 어려웠습니다.

같은 지원자도 현재 단계와 연락 가능성에 따라 필요한 행동이 달랐습니다. 기존 문서를 화면으로 옮기는 것만으로는 예외 상태와 인수인계 문제를 해결할 수 없었습니다.

지원자 한 명의 유입부터 과정 합류까지 현재 상태, 변경 이유, 담당자와 다음 행동을 추적할 수 있는 운영 도구를 만들고자 했습니다.

운영자가 같은 조회 조건과 상세 맥락을 동료에게 넘길 수 있도록 화면 상태와 서버 조회 상태를 함께 구조화했습니다.

• 모집 실무자 약 2~3명이 지원자 한 명의 상담과 후속 행동 맥락을 한 화면에서 확인했습니다.
• 이전 상담 이력과 메모를 후속 상담과 담당자 인수인계에 활용할 수 있게 했습니다.
• 외부 캘린더와 입력 화면을 오가던 예약 흐름을 지원자 상세 맥락에 연결했습니다.

백오피스 복잡도는 화면 수보다 운영 규칙과 예외 상태에서 발생했습니다.

모든 기능을 완성도 높게 확장하기보다 실제 사용자 수와 우선순위를 고려해 사용자-facing 프로젝트를 먼저 선택했고, 일부 필터 개선은 기술 부채로 남겼습니다.