Resume portfolio

Mail

백종환

Frontend Engineer

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

React·Next.js 기반 실서비스를 신규 구축하고 운영하며, 복잡한 상태와 실패 비용이 큰 흐름을 다뤄왔습니다.

LMS
7개 역할과 제한 시간 평가, HLS, 12~14GB 업로드를 화면별 예외가 아닌 공통 경계로 설계했습니다.
통합 계정
약 4,000명의 기존 로그인을 유지해 이관하고, 첫 장애를 약 1시간 안에 복구한 뒤 재전환했습니다.
홈페이지
대표 미디어를 67.5MB에서 3.1MB로 줄이고, LCP를 3.1초에서 1.1초로 개선했습니다.
Develog
학습 기록 문제를 제안해 약 한 달 만에 출시하고, 선택 사용 환경에서 341개 글과 검색 클릭 3,224회를 확인했습니다.
백종환 프로필 사진

경력 기록

경력과 성장 흐름

경력

2023.09.25 - 2026.08.31

디벨로켓에듀 · 스마트 훈련 플랫폼 개발팀 / 프론트엔드

LMS V2·V3 프론트엔드 신규 구축과 운영을 중심으로 통합 계정, 모집 백오피스, 기업 홈페이지, 학습 기록 제품을 개발했습니다. 기획·디자인·백엔드·인프라·운영 담당자와 기능의 책임 경계를 조율했습니다.

교육

2023.10 - 2026.08

학점은행제(국가평생교육진흥원) · 컴퓨터공학전공

컴퓨터공학 전공 학위를 이수했습니다.

2022.10 - 2023.07

경일게임아카데미 · 웹 개발/블록체인 과정

HTML, CSS, JavaScript의 동작 원리부터 React, Node.js와 Solidity를 학습하고 팀 프로젝트와 해커톤을 경험했습니다.

2013.03 졸업

오금고등학교 · 이공계열

기초 학력 사항입니다.

프로젝트 기록

결과와 판단을 함께 남긴 일

복잡한 상태와 미디어 운영

LMS V2·V3 프론트엔드 신규 구축 및 운영

역할·평가·영상·파일 업로드처럼 운영 중 반복해서 어긋날 수 있는 상태를 명시적인 경계와 복구 가능한 흐름으로 정리했습니다.

기간
2023.09 - 2026.08
역할
프론트엔드 신규 구축·운영 담당 · BE·Designer·Infra와 협업
ReactNext.jsTypeScriptTanStack QueryZustandS3HLS

프로젝트 전체

프로젝트 배경과 해결 방향

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

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

이번 프로젝트에서 정한 기준

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

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

해결 사례

01

7개 역할과 복수 역할을 공통 구조로 관리

판단 기준

ADMIN, COORDINATOR, PROFESSOR, CONTENT_MANAGER, CAREER_MANAGER, CREW, MEMBER를 중앙 설정에서 관리했습니다. 사용자 정보의 roles 배열과 우선순위를 기준으로 최초 진입 경로를 정하고, 보유 역할 사이를 명시적으로 전환하게 했습니다.

구현과 적용

공통 RoleGuard와 역할별 query cache를 적용했습니다. 다만 프론트엔드의 화면 진입 제어이며 모든 API의 최종 인가를 대신한다고 확대하지 않았습니다.

해결 사례

02

제한 시간 평가의 서버 상태와 작성 상태를 분리

판단 기준

평가 시작 여부와 제한 시간은 서버의 startedAt, timeLimit과 status를 기준으로 계산했습니다. 시작 API 성공 뒤 문제를 열고, 화면 타이머는 표시를 갱신하면서 서버 상태를 주기적으로 다시 동기화했습니다.

구현과 적용

작성 중인 답변과 문제 위치는 같은 기기에서 복원할 수 있게 했습니다. 서버 자동 저장이나 파일 답안까지 완전히 복원하는 구조는 아니라는 경계도 함께 두었습니다.

해결 사례

03

브라우저 POC 뒤 HLS 전달 구조를 협업 선택

판단 기준

ffmpeg WASM 변환 POC로 구현 가능성과 브라우저 자원 비용을 확인했습니다. 긴 변환 시간과 자원 점유를 업로더에게 전가하지 않기 위해 운영안에서는 제외했습니다.

구현과 적용

인프라 담당자가 MediaConvert·S3·CloudFront를 구성하고, 프론트엔드는 변환 상태와 결과 URL을 제품 흐름에 연결했습니다. 완료 전 MP4, 완료 후 HLS를 재생하는 fallback과 공통 플레이어 인터페이스를 구성했습니다.

해결 사례

04

화면 전환 뒤 남던 요청과 대용량 업로드를 복구 가능하게 처리

판단 기준

영상 A에서 B로 이동한 뒤 두 contentId의 진도 요청이 함께 발생하는 문제를 Network payload로 재현했습니다. 대상이 바뀌면 이전 interval을 정리해 현재 영상 요청만 남도록 수정했습니다.

구현과 적용

10MB 미만은 일반 업로드, 그 이상은 Multipart로 분기했습니다. 1GB 초과 파일은 part 수가 약 500개 이내가 되도록 크기를 계산하고, 실패한 part만 새 서명 URL로 최대 4회 재시도했습니다.

프로젝트 전체

확인한 결과와 남은 기준

확인한 결과

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

이후의 판단 기준

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

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