사람을 이해하고, 함께 더 나은 경험을 만들어가는 Frontend EngineerA Frontend Engineer who understands people and builds better experiences together

초등학생이 매일 쓰는 학습 앱에서 어색한 전환과 끊기는 모션은 몰입을 방해합니다. 성능 부담 없이 화면을 전환하고, 아바타 상태가 바뀌어도 움직임이 자연스럽게 이어져야 했습니다.In a learning app used daily by elementary students, awkward transitions and interrupted motion break focus. Screens had to transition without performance overhead, while avatar motion needed to continue naturally across state changes.

레이아웃 변화는 Motion의 layout(FLIP)으로, 상태에 따라 달라지는 아바타 모션은 Rive State Machine으로 나눴습니다. 인터랙션의 성격에 맞는 도구를 선택해 별도 로직과 상태 분기를 줄였습니다.I used Motion's layout animation (FLIP) for layout changes and Rive State Machines for state-driven avatar motion. Matching each tool to the interaction reduced custom transition logic and state branching.

Motion의 layout(FLIP)을 적용해 레이아웃 변화 전후를 자연스럽게 보간했습니다. Rive로 TTS와 입 모양을 동기화하고 아이템 교체를 상태 전이로 연결했습니다. 툴팁·튜토리얼·토스트는 공통 컴포넌트로 만들고 Storybook과 Cypress로 문서화·검증했습니다.I used Motion's layout animation (FLIP) to interpolate between layout states, synchronized avatar mouth shapes with TTS in Rive, and handled item changes as state transitions. Tooltips, tutorials, and toasts became shared components documented in Storybook and covered by Cypress.

Real Academy는 WebView로 만든 서비스지만 사용자는 태블릿 앱으로 인식합니다. 이미지가 뒤늦게 나타나거나 화면 로딩이 길어지면 앱 안에서 갑자기 웹을 보는 것처럼 어색해집니다. 네트워크가 끊기거나 404가 발생했을 때도 사용자가 직접 새로고침하기 어렵고, 블루투스·배터리 같은 기기 상태는 웹만으로 알 수 없었습니다.Real Academy is built with a WebView, but users experience it as a tablet app. Late-loading images or long screen loads made the app suddenly feel like a website. Users could not simply refresh after a network failure or 404, and the web layer could not read device states such as Bluetooth or battery on its own.

정상 화면뿐 아니라 로딩과 실패 상황까지 앱 경험의 일부로 봤습니다. 이미지와 콘텐츠는 미리 준비하고, 네트워크·디바이스 상태는 Flutter와 연결했습니다. 웹의 기본 오류 화면 대신 앱 안에서 상황을 설명하는 전용 화면을 제공했습니다.I treated loading and failure states as part of the app experience, not exceptions outside it. Images and content were prepared ahead of time, device state was connected through Flutter, and browser error pages were replaced with screens that stayed within the app's context.

Flutter와 flutter_inappwebview로 전용 컨테이너를 만들고 RpcService·AssetManager 캐싱으로 이미지와 콘텐츠 로딩을 줄였습니다. Web-App 브리지로 블루투스·네트워크·배터리 상태를 전달하고, 네트워크 단절과 404에서는 일반 웹 페이지 대신 앱 전용 오류 화면을 보여줬습니다.I built a dedicated container with Flutter and flutter_inappwebview and used RpcService and AssetManager caching to reduce visible image and content loading. The Web-App bridge delivered Bluetooth, network, and battery state to the web layer. Network failures and 404s showed app-specific error screens instead of generic web pages.

Real Academy는 WebView 기반 태블릿 앱이라 개발 PC에서 괜찮던 화면도 실제 기기에서는 느리게 느껴졌습니다. 사용자가 겪는 느린 화면 반응과 불안정한 학습 경험을 개선하려 했지만, 문제를 재현하고 개선 전후를 비교할 기준이 없었습니다. 그래서 초기 로딩, React 런타임, 프로덕션 안정성을 각각 측정·검증하고, 확인한 원인을 실제 개선까지 연결할 수 있는 환경부터 만들었습니다.Real Academy runs as a WebView-based tablet app, so screens that felt fine on development machines could still feel slow on real devices. I wanted to improve sluggish interactions and an unstable learning experience, but we had no repeatable way to reproduce problems or compare changes. I therefore first created environments for measuring and validating initial loading, React runtime performance, and production reliability, then used the findings to drive concrete improvements.

초기 로딩은 실제 태블릿과 비슷한 1280×800@2x, CPU 2배 감속, 10Mbps 환경에서 측정했습니다. 인증 화면과 캐시 상태를 맞춘 5회 측정의 중앙값으로 이미지 전송 병목을 찾고, 개선 후에도 같은 조건에서 다시 측정했습니다. React 런타임은 Profiler로 렌더 커밋과 상태 구독 범위를 추적한 뒤, 상태 구독과 DOM 렌더 범위를 필요한 만큼으로 줄였습니다.I measured initial loading under tablet-like conditions: 1280×800@2x, 2× CPU slowdown, and a 10Mbps network. With authentication and cache state controlled, I used the median of five runs to identify image-transfer bottlenecks and repeated the same measurement after each improvement. For React runtime performance, Profiler traced render commits and subscription scope before I reduced state subscriptions and DOM rendering to only what each screen needed.

프로덕션 안정성은 문제를 재현 조건과 근본 원인별로 분류하고 배포 전에 성공 기준을 정했습니다. 릴리스별 사용자당 Sentry 이벤트와 미수정 이슈의 추이를 함께 비교해 실제 사용자 환경에서 개선 여부를 확인하고, 확인된 문제는 회귀 테스트로 남겼습니다.For production reliability, I grouped issues by reproduction condition and root cause and defined success criteria before release. I compared Sentry events per user across releases with trends from unresolved issues, validated the changes in real user environments, and encoded confirmed failure scenarios in regression tests.

성능 계측·로딩 최적화 — CDP로 인증 상태를 주입해 로그인 이후 화면을 Lighthouse에서 측정했습니다. 홈 이미지는 실제 렌더 폭에 맞게 sizes를 지정하고 LCP 이미지에 priority를 적용해 불필요하게 큰 이미지가 전송되지 않도록 했습니다.Performance measurement and loading optimization — I injected authentication through CDP to measure post-login screens in Lighthouse. Home images received sizes based on rendered width and priority for the LCP image, avoiding unnecessarily large transfers.

런타임 최적화 — 자막 재생과 에세이 입력 중 관련 없는 컴포넌트까지 다시 렌더되는 경로를 Profiler로 찾았습니다. Zustand 스토어 전체를 구독하던 코드를 필요한 상태만 구독하도록 바꾸고, 1,279행의 가변 높이 자막과 마크다운은 화면에 보이는 7~8행만 렌더하도록 가상화했습니다. 렌더 커밋 횟수를 검사하는 성능 테스트도 추가했습니다.Runtime optimization — Profiler exposed unrelated re-renders during transcript playback and essay input. I replaced whole-store Zustand subscriptions with targeted selectors, virtualized the 1,279-line variable-height transcript to 7–8 visible rows, and added performance tests for render commits.

안정성·검증 — 6주간 수집한 레슨 기능의 프로덕션 문제를 재현 조건과 근본 원인별로 정리했습니다. 배포 전에 성공 기준을 정하고 미수정 이슈의 추이를 비교군으로 두어, 실제 사용자 환경에서 수정 효과를 검증했습니다. 레슨 중단·오디오·세션 생명주기 문제를 수정하고 회귀 테스트를 구축했습니다.Reliability and validation — I organized six weeks of production issues in the lesson experience by reproduction condition and root cause. I defined success criteria before release and used trends from unresolved issues as a comparison group to validate the fixes in real user environments. I fixed lesson-blocking, audio, and session-lifecycle issues and added regression tests.

Real Academy의 라이브 수업은 학생이 강사와 실시간 영어 수업을 듣고 VOD와 노트로 복습하는 서비스입니다. 매 학기 공지·개강 조건·QA 계정 설정을 수작업으로 반복해 일정 지연과 누락 위험이 있었고, 네트워크 단절과 재입장 때문에 한 번의 입·퇴실 이벤트만으로 출석을 정확히 판단하기도 어려웠습니다.Real Academy's live classes let students take real-time English lessons with instructors and review them through VOD and notes. Repeating notice, opening-condition, and QA-account setup by hand each term created risks of delays and omissions, while disconnections and re-entry made attendance difficult to determine from a single join or leave event.

학생에게는 참여부터 복습까지 이어지는 경험을, 운영자에게는 반복 준비를 설정 변경으로 처리하는 구조를 만들었습니다. 학기 상태와 권한은 코드와 데이터로 관리하고, 출석은 누적된 상태로 판단했으며, 상태 확인 주기는 수업 여부에 따라 조절했습니다.I created a connected journey from participation to review for students and reduced recurring preparation to configuration changes for operators. Term state and permissions moved into code and data, attendance was based on accumulated state, and polling frequency adapted to whether a class was active.

수업 경험 — 목록·상세·VOD·노트·커리큘럼·시간표·알림을 구현하고, Zoom SDK를 iframe으로 통합해 제품 안에서 참여와 복습이 이어지게 했습니다.Class experience — I built lists, details, VOD, notes, curriculum, schedules, and notifications, then integrated the Zoom SDK in an iframe to connect participation and review within the product.

운영 자동화 — 학기 상태와 권한을 백오피스와 연결하는 반자동 동기화 파이프라인을 만들고, 반복 설정과 QA 과정을 문서화했습니다.Operations automation — I built a semi-automated pipeline connecting term state and permissions to the back office and documented recurring configuration and QA.

출석·상태 동기화 — 1분 주기로 Heartbeat를 수집해 세션당 20회 이상 확인되면 출석으로 인정했습니다. Adaptive Polling으로 수업 중에는 상태를 자주 확인하고 비활성 구간에는 주기를 늘렸습니다.Attendance and state synchronization — I collected one-minute heartbeats and marked attendance after at least 20 detections per session. Adaptive Polling checked frequently during class and relaxed its interval during inactive periods.

정책 문서가 여러 곳에 흩어져 있어 동료들이 같은 내용을 반복해서 찾고 답해야 했고, 정책의 충돌이나 누락은 개발이 시작된 뒤에야 발견되기도 했습니다. Sentry 알림도 사람이 매번 열어 원인을 분석해야 했습니다. 검색과 분석은 AI로 줄일 수 있었지만, 정책 원문과 코드를 바꾸는 일까지 근거와 승인 없이 맡길 수는 없었습니다.Policy documents were scattered across multiple locations, so teammates repeatedly searched for and answered the same information, while conflicts and omissions sometimes surfaced only after development began. Every Sentry alert also required manual investigation. AI could reduce the search and analysis work, but changes to source policies and code could not be delegated without evidence and approval.

AI는 문서를 검색하고 문제를 분석해 수정안을 만들고, 사람은 근거를 확인해 최종 변경을 승인하도록 역할을 나눴습니다. 모든 답변과 수정안에 원문 출처와 판단 맥락을 남기고, 명시적인 승인 전에는 정책이나 코드가 바뀌지 않도록 두 워크플로에 같은 원칙을 적용했습니다.I divided responsibilities so AI searched documents, analyzed problems, and drafted changes, while people reviewed the evidence and approved final changes. Both workflows retained original sources and decision context, and neither policy nor code could change before explicit human approval.

RYACO — 흩어진 정책 문서를 RAG로 검색해 답변과 원문 출처를 함께 제공하는 사내 도구를 2인 풀스택으로 개발했습니다. 문서의 누락·충돌·개선점을 찾고 승인된 수정만 원문에 반영하는 검색→검토→반영 흐름을 설계했습니다. 운영 환경에 맞춰 ChromaDB를 Qdrant로, LLM 실행 경로를 CLI→워커→Azure OpenAI로 이관했습니다.RYACO — In a two-person full-stack team, I built an internal RAG tool that searches scattered policy documents and returns answers with original-source links. I designed a search→review→apply flow that finds omissions, conflicts, and improvements and applies only approved changes. To fit the operating environment, I migrated ChromaDB to Qdrant and the LLM execution path from CLI→worker→Azure OpenAI.

Sentry 자동 수정 에이전트 — 오류 알림→AI 분석→Slack 게시→사람 승인→Draft PR 생성 흐름을 구축했습니다. 분석과 코드 변경을 분리하고, Draft PR 강제·중복 실행 방지·토큰 마스킹을 적용했습니다. Kubernetes 환경변수와 webhook을 구성해 배포하고 예외 경로를 포함한 테스트 36건을 만들었습니다.Sentry Auto-fix Agent — I built a flow from error alert→AI analysis→Slack post→human approval→Draft PR. I separated analysis from code changes and added mandatory Draft PRs, duplicate-run prevention, and token masking. I configured Kubernetes environment variables and webhooks, deployed the workflow, and added 36 tests covering failure paths.