포지션 상세
[어스얼라이언스 소개]
어스얼라이언스는 "금융을 콘텐츠로 혁신합니다."라는 미션 아래, 대한민국 개인투자자들이 믿고 선택할 수 있는 금융 생태계를 만들어가는 금융 콘텐츠·플랫폼 기업입니다.
우리는 단순히 금융 콘텐츠를 만드는 회사가 아닙니다. 전문가의 경험과 통찰을 콘텐츠에 담아 더 많은 사람들이 올바른 투자 원칙을 세울 수 있도록 돕고, 건강한 투자 문화를 만들어가는 회사입니다.
좋은 콘텐츠는 일시적인 관심을 얻을 수 있습니다. 하지만 사람들의 생각과 행동을 바꾸는 것은 꾸준히 쌓인 믿음이라고 생각합니다. 그리고 그 믿음은 하루아침에 만들어지지 않습니다. 전문성과 진정성, 흔들리지 않는 철학이 오랜 시간 축적될 때 비로소 만들어집니다.
그래서 어스얼라이언스는 콘텐츠를 만드는 데서 멈추지 않습니다. 각 분야 최고의 전문가들이 가진 경험과 통찰, 그리고 그 안에 담긴 철학이 더 많은 사람들에게 올바르게 전달될 수 있도록 고민합니다.
■ 우리는 이런 일을 합니다.
어스얼라이언스는 국내 최고의 금융·경제 전문가들과 함께 다양한 콘텐츠를 기획·제작하고 있습니다.
유튜브를 시작으로 교육, 출판, 컨퍼런스, 커뮤니티 등 다양한 영역으로 콘텐츠를 확장하며, 더 많은 사람들이 쉽고 올바르게 금융을 이해할 수 있는 환경을 만들어가고 있습니다.
우리에게 콘텐츠는 목적이 아니라 가치를 전달하는 가장 강력한 수단입니다.
좋은 콘텐츠를 통해 전문가와 금융소비자를 연결하고, 그들의 경험과 철학이 더 많은 사람들에게 자연스럽게 이어질 수 있도록 노력합니다.
■ 우리가 믿는 가치
대한민국에는 여전히 자극적인 정보가 빠르게 소비되고, 검증되지 않은 정보가 투자 판단에 영향을 미치는 경우가 많습니다.
우리는 이러한 환경 속에서도 '올바른 투자, 건강한 투자'라는 방향성을 지켜가고 있습니다.
많은 정보를 전달하는 것보다 올바른 기준을 제시하는 것이 더 중요하다고 믿습니다. 단기적인 관심보다 시간이 지나도 흔들리지 않는 철학이 더 큰 가치를 만든다고 생각합니다.
정보와 접근성의 차이로 발생하는 금융의 격차를 줄이고, 더 많은 사람들이 올바른 금융 지식을 접할 수 있도록 하는 것.
그것이 어스얼라이언스가 존재하는 이유입니다.
■ 어스얼라이언스와 함께하는 채널
• 홍춘욱의 경제강의노트 (38.4만명)
• 김영익의 경제스쿨 (33.9만명)
• 서재형의 투자교실 (25.5만명)
• 소수몽키 (115만명)
• 강민우 돈깡TV (59.3만명)
• 경제 읽어주는 남자(김광석TV) (50만명)
• 설명왕 테이버 (29.7만명)
• 박두환의 실전투자교실 (26.4만명)
■ 함께할 팀
• 어스얼라이언스의 Frontend Developer는 사용자 경험을 최우선으로 생각하며, 다양한 이용자와 콘텐츠 제공자 모두에게 더 나은 서비스를 제공하기 위해 끊임없이 고민합니다. 빠르고 안정적인 사용자 경험을 실현하고, 콘텐츠 제공자에게는 효율적인 발행 환경을 제공하기 위해 기술적 문제를 적극적으로 해결해 나갑니다.
• 유저들에게 쉽고 편하게 좋은 콘텐츠를 제공할 수 있도록 Product Owner, Product Designer, Server Developer, Client Developer등 여러 동료들과 함께 일하고 자유롭게 아이데이션과 피드백을 주고 받으며 제품을 개선해 나가고 있어요
• 프론트엔드 챕터는 주기적으로 챕터 위클리를 진행하고 새로운 기술 토픽 또는 개발 노하우를 공유 및 논의하고 공통으로 사용할 라이브러리 개발 및 서비스 개발에 대한 코드리뷰를 함께 진행해요.
• 단일 코드베이스 안에서 서비스별 책임을 명확히 분리하고, 유지보수 및 변화에 유연하게 대응할 수 있도록 FSD 아키텍처를 도입, 구조적 개선을 이어가고 있어요
• 프론트엔드 챕터는 인앱웹뷰 기반으로 신규 서비스 런칭 및 마이그레이션 작업을 진행하고 있고, 앞으로 기존 서비스들을 인앱웹뷰로 전환해나갈 예정이에요
■ Experienced
플랫폼 파트의 프론트엔드 개발자는 서비스 성장을 이끄는 핵심 역할을 맡습니다.
웹 서비스 5개와 Flutter 앱 안의 인앱웹뷰를 함께 운영합니다. 15만 명 이상이 쓰는 프로덕션 환경에서 웹과 네이티브 사이의 성능, 품질, 자동화 문제를 함께 풀어갈 분을 찾습니다.
■ 프론트엔드 구성은 어떻게 되어 있나요?
• pnpm 모노레포와 Turborepo 위에서 웹앱 5개(사용자 서비스, 커머스, 파트너센터, 어드민, 스튜디오)와 공용 패키지 6개(디자인 시스템, 에디터, 모달, Sentry 등)를 운영합니다. 공용 패키지를 하나 바꾸면 여러 앱이 함께 영향을 받기 때문에, 빌드 의존 순서와 패키지 버전을 모노레포 전체 관점에서 관리합니다.
• React 19와 TypeScript를 기반으로, 서비스 특성에 맞게 Next.js(App Router)와 Vite SPA를 함께 운영합니다. Next.js에서는 Server Component와 Client Component의 경계를 import 구조까지 설계합니다. 잘못된 import 하나로 클라이언트 전용 코드가 서버 번들에 섞이면 빌드가 깨지기 때문입니다.
• 코드는 FSD(Feature-Sliced Design) 아키텍처로 구성합니다. 읽기는 entities, 쓰기는 features로 나누고, 도메인 index만 public API로 노출합니다. 중간 barrel 파일을 두지 않고 내부 참조는 상대경로로만 하여 순환 의존을 구조적으로 막습니다.
• 서버 상태는 TanStack Query로 관리합니다. Query Key Factory로 캐시 키를 계층화해 mutation 후 필요한 범위만 무효화합니다. Server Component에서 미리 받아 온 데이터는 하이드레이션으로 클라이언트 캐시에 이어 붙여, 첫 화면에서 요청이 중복되지 않게 합니다.
• 사용자 행동 분석(Segment)과 에러 모니터링(Sentry)은 공용 패키지로 묶어 여러 앱이 같은 이벤트 계약을 쓰도록 맞춥니다. 서브도메인 사이에 사용자 식별 정보가 섞이지 않도록 관리하는 것도 여기에 포함됩니다.
■ 인앱웹뷰에서 어떤 기술적 문제를 풀고 있나요?
• Flutter와 웹 사이의 타입 기반 브릿지 계약을 관리하고, 인증·세션 전달과 화면 전환이 일관되게 동작하도록 개발합니다. 웹·브릿지·네이티브 사이의 호출과 상태 흐름을 추적해 문제의 원인을 해결합니다.
• Android System WebView와 iOS WKWebView의 동작 차이를 고려해 쿠키·세션, 미디어 재생, 키보드와 Safe Area를 처리합니다. 실제 앱 사용 흐름에서 문제를 재현하고, 플랫폼 특성에 맞게 사용자 경험을 다듬습니다.
• 실제 기기의 웹뷰를 프로파일링해 JavaScript 실행, 렌더링, 웹·네이티브 상호작용의 병목을 분석합니다. 측정 결과를 바탕으로 개선 우선순위를 정하고, 변경 전후의 효과를 검증합니다.
■ 성능은 어떻게 다루나요?
▸ 지금 하고 있는 것
• 스크롤 리스너는 passive로 등록해, 스크롤이 메인 스레드가 아닌 컴포지터 스레드에서 처리되게 합니다. 스크롤 위치에 반응하는 UI가 있어도 스크롤이 끊기지 않게 하기 위해서입니다.
• 이모지 검색처럼 입력할 때마다 큰 목록을 다시 그려야 하는 UI는 useDeferredValue로 입력 반응을 먼저 처리하고, 목록 갱신은 그 뒤로 미룹니다.
• 무거운 컴포넌트는 동적 import로 분리해 초기 JS 양을 줄입니다. 저사양 Android 기기에서는 JS 다운로드보다 파싱과 실행 비용이 더 크기 때문입니다.
• Server Component에서 미리 받아 온 데이터를 하이드레이션으로 클라이언트 캐시에 이어 붙여, 첫 화면에서 같은 요청이 다시 나가지 않게 합니다.
• 이미지는 next/image와 srcset/sizes로 화면 크기에 맞는 해상도만 받습니다. 디코딩된 이미지는 파일 크기가 아니라 해상도 기준으로 메모리를 차지하기 때문에, 앱 프로세스와 메모리를 나눠 쓰는 웹뷰에서는 이 차이가 큽니다.
▸ 앞으로 함께 해 나갈 것
• 터치 반응 지연(INP)을 입력 지연, 이벤트 처리, 화면 반영 지연 세 단계로 나누어 측정하고, 어느 단계가 병목인지 근거를 갖고 개선하는 체계를 만들어 갑니다.
• Long Task를 잘게 나누어 브라우저에 실행을 양보(yield)하는 구조를 도입합니다. Android WebView(Chromium)와 iOS WKWebView(WebKit)의 API 지원 차이를 고려해 두 엔진 모두에서 동작하게 설계합니다.
• backdrop-filter처럼 페인트 비용이 큰 효과와 레이어 승격을 실제 기기에서 Layers 패널과 Paint Flashing으로 점검하고, 저사양 기기 기준으로 사용 범위를 정리합니다.
• 긴 목록에는 가상화와 content-visibility를 적용해, 화면 밖 영역의 렌더링 비용을 줄여 나갑니다.
• 웹과 Flutter 사이 브릿지 메시지의 직렬화 비용을 측정하고, 큰 데이터를 자주 주고받지 않는 메시지 구조로 다듬어 갑니다.
• Flutter 쪽에서도 웹뷰를 화면에 합성하는 방식에 따라 렌더링 성능 특성이 달라집니다. Android Hybrid Composition은 아직 stable 단계에 오르지 않아 지금은 쓰지 않고 있으며, stable로 올라오면 교체할 계획입니다. 이 전환 과정에서 웹과 앱 양쪽 관점으로 성능 차이를 측정하고 최적의 구성을 함께 찾아갑니다.
■ 테스트는 어떻게 하나요?
• 테스트 수준은 피라미드 공식이 아니라 위험도로 정합니다. 결제, 권한, 사용자 데이터처럼 틀리면 큰 문제가 되는 흐름은 성공 경로뿐 아니라 실패 후 복구, 중복 요청, 경계값까지 검증합니다.
• API, PG, SDK 같은 외부 경계만 MSW로 mock합니다. 테스트 대상인 훅과 컴포넌트는 실제로 실행해서, 부품 사이의 연결과 요청 횟수까지 검증합니다.
• 로딩 중 상태는 delay(100) 같은 고정 대기 대신, 테스트가 직접 열고 닫는 Promise gate로 제어합니다. CI 환경 속도에 따라 결과가 달라지는 flaky 테스트를 원천적으로 막기 위해서입니다.
• 날짜를 다루는 로직은 실행 환경의 타임존과 상관없이 같은 결과를 내야 합니다. 그래서 CI에서 서울과 뉴욕 타임존 매트릭스로 함께 검증합니다.
• 버그를 고칠 때는 재현 테스트를 먼저 작성하고, 리팩토링할 때는 현재 동작을 고정하는 테스트를 먼저 작성합니다. 정책이 확정되지 않은 수상한 동작은 정답으로 고정하지 않고, 결함 후보로 따로 기록합니다.
• 웹 E2E는 Playwright로 로그인 복귀, 결제 콜백처럼 여러 화면을 거치는 핵심 흐름부터 적용하고 있습니다.
■ 인앱웹뷰 E2E 자동화, 함께 만들어 갈 분을 찾습니다
• 웹 단독 E2E만으로는 브릿지 통신, 네이티브 로그인 이후의 세션 전달, 기기별 웹뷰 엔진 차이처럼 앱 안에서만 드러나는 문제를 잡을 수 없습니다.
• 그래서 AWS Device Farm으로 실제 iOS/Android 기기 풀에서 인앱웹뷰를 끝까지 자동 검증하는 E2E 기반을 준비하고 있습니다.
◦ Appium으로 네이티브 컨텍스트와 WEBVIEW 컨텍스트를 오가는 시나리오를 작성합니다.
◦ 여러 OS 버전과 제조사 기기 조합에서 회귀를 자동으로 찾아내는 파이프라인을 만듭니다.
◦ 실기기 실행마다 남는 영상, 로그, 성능 데이터를 실패 원인 분석과 기기별 성능 비교에 활용합니다.
• 이미 갖춰진 정답을 따라가는 일이 아닙니다. 실기기 E2E 자동화의 기반을 처음부터 설계하고 함께 준비해 가는 경험을 해 보고 싶은 분을 기다립니다.
■ AI는 어떻게 사용하고 있나요?
• CLAUDE.md, AGENTS.md와 규칙 파일로 아키텍처, 코딩 스타일, API 패턴, 테스트 기준, Git 워크플로우를 에이전트가 읽을 수 있는 컨텍스트로 정리해 두었습니다. 에이전트가 같은 실수를 반복하면 그 내용을 규칙에 다시 반영해 컨텍스트를 계속 개선합니다.
• FSD 보일러플레이트 생성, Figma를 컴포넌트로 옮기는 작업, QA 케이스 설계와 E2E 구현, 커밋과 PR 작성까지 반복되는 작업은 스킬과 에이전트로 자동화했습니다.
• 에이전트가 "완료"라고 말하기 전에 타입 체크, 린트, 테스트를 실제로 실행해 증거를 남기도록 검증 절차를 강제합니다.
• 컨텍스트를 설계해서 생산성을 높이는 일에 관심이 있다면 함께해 주세요.
■ 오픈소스 경험은 어떻게 도움이 되나요?
• 라이브러리 버그를 만나면 문제를 피해 가는 대신 소스를 직접 읽고 디버깅합니다. upstream 수정을 기다리기 어려우면 pnpm patch로 직접 패치하고, 가능하면 기여합니다.
• 대규모 의존성 업데이트는 영향 범위를 단계별로 나누어 진행합니다. 업데이트로 생긴 회귀는 버전 변경 내역(changelog)과 소스를 근거로 원인을 추적합니다.
• 프레임워크를 쓰기만 하는 사람이 아니라, 품질과 속도를 저울질해 필요할 때 직접 도구를 만들어 보고 싶은 분이라면 도전할 과제가 충분히 준비되어 있습니다.
• 구독형 금융 콘텐츠를 중심으로, 다양한 사용자들이 쉽고 편하게 콘텐츠를 소비하고 교류할 수 있는 플랫폼 서비스 제품을 만들어요
• 콘텐츠 제공자들에게 쉽고 편한 콘텐츠 생성을 지원하는 제품을 만들어요
• 어스 플랫폼 서비스의 내부 운영을 위한 서비스로 내부 직원들에게 더 쉽고 편하게 서비스를 관리할 수 있도록 서포트하는 제품을 만들어요
• 어스 플랫폼 서비스의 라이브 스트리밍 서비스를 위한 라이브 스튜디오 제품을 만들어요
• 어스 플랫폼 서비스의 인앱웹뷰 개발을 담당할거에요
■ 현재 사용중인 기술
• 코어: React, TypeScript, Next.js ( App Router ), Flutter
• 상태 관리: Tastack Query, Jotai
• 스타일링: tailwindcss, shadcn/ui
• 패키지 매니저: pnpm
• 빌드: Webpack, SWC, Vite
• CI/CD: GitHub Actions
• 테스트: Vitest, Storybook
• 모니터링: Sentry
• Frontend 영역과 웹 서비스 환경에 대한 깊은 이해를 토대로 제품 개발에 기여하실 분
• 고객의 문제에 집중하여 복잡한 도메인을 유연한 시스템으로 풀어내는 역량을 갖추신 분
• 속도 저하를 유발할 가능성이 있는 기술 부채들을 인지하여 타협하지 않고 해결을 주도한 경험이 있는 분
• TypeScript를 이용한 JavaScript 정적 타입 분석을 경험해보신 분
• 주어진 업무에서 나아가 주도적으로 문제를 정의하고 해결하고자 하는 분
• 다양한 문제와 요구사항들에 대해서 그것을 추상화하고 코드로 표현할 수 있는 분
어스얼라이언스는 "금융을 콘텐츠로 혁신합니다."라는 미션 아래, 대한민국 개인투자자들이 믿고 선택할 수 있는 금융 생태계를 만들어가는 금융 콘텐츠·플랫폼 기업입니다.
우리는 단순히 금융 콘텐츠를 만드는 회사가 아닙니다. 전문가의 경험과 통찰을 콘텐츠에 담아 더 많은 사람들이 올바른 투자 원칙을 세울 수 있도록 돕고, 건강한 투자 문화를 만들어가는 회사입니다.
좋은 콘텐츠는 일시적인 관심을 얻을 수 있습니다. 하지만 사람들의 생각과 행동을 바꾸는 것은 꾸준히 쌓인 믿음이라고 생각합니다. 그리고 그 믿음은 하루아침에 만들어지지 않습니다. 전문성과 진정성, 흔들리지 않는 철학이 오랜 시간 축적될 때 비로소 만들어집니다.
그래서 어스얼라이언스는 콘텐츠를 만드는 데서 멈추지 않습니다. 각 분야 최고의 전문가들이 가진 경험과 통찰, 그리고 그 안에 담긴 철학이 더 많은 사람들에게 올바르게 전달될 수 있도록 고민합니다.
■ 우리는 이런 일을 합니다.
어스얼라이언스는 국내 최고의 금융·경제 전문가들과 함께 다양한 콘텐츠를 기획·제작하고 있습니다.
유튜브를 시작으로 교육, 출판, 컨퍼런스, 커뮤니티 등 다양한 영역으로 콘텐츠를 확장하며, 더 많은 사람들이 쉽고 올바르게 금융을 이해할 수 있는 환경을 만들어가고 있습니다.
우리에게 콘텐츠는 목적이 아니라 가치를 전달하는 가장 강력한 수단입니다.
좋은 콘텐츠를 통해 전문가와 금융소비자를 연결하고, 그들의 경험과 철학이 더 많은 사람들에게 자연스럽게 이어질 수 있도록 노력합니다.
■ 우리가 믿는 가치
대한민국에는 여전히 자극적인 정보가 빠르게 소비되고, 검증되지 않은 정보가 투자 판단에 영향을 미치는 경우가 많습니다.
우리는 이러한 환경 속에서도 '올바른 투자, 건강한 투자'라는 방향성을 지켜가고 있습니다.
많은 정보를 전달하는 것보다 올바른 기준을 제시하는 것이 더 중요하다고 믿습니다. 단기적인 관심보다 시간이 지나도 흔들리지 않는 철학이 더 큰 가치를 만든다고 생각합니다.
정보와 접근성의 차이로 발생하는 금융의 격차를 줄이고, 더 많은 사람들이 올바른 금융 지식을 접할 수 있도록 하는 것.
그것이 어스얼라이언스가 존재하는 이유입니다.
■ 어스얼라이언스와 함께하는 채널
• 홍춘욱의 경제강의노트 (38.4만명)
• 김영익의 경제스쿨 (33.9만명)
• 서재형의 투자교실 (25.5만명)
• 소수몽키 (115만명)
• 강민우 돈깡TV (59.3만명)
• 경제 읽어주는 남자(김광석TV) (50만명)
• 설명왕 테이버 (29.7만명)
• 박두환의 실전투자교실 (26.4만명)
■ 함께할 팀
• 어스얼라이언스의 Frontend Developer는 사용자 경험을 최우선으로 생각하며, 다양한 이용자와 콘텐츠 제공자 모두에게 더 나은 서비스를 제공하기 위해 끊임없이 고민합니다. 빠르고 안정적인 사용자 경험을 실현하고, 콘텐츠 제공자에게는 효율적인 발행 환경을 제공하기 위해 기술적 문제를 적극적으로 해결해 나갑니다.
• 유저들에게 쉽고 편하게 좋은 콘텐츠를 제공할 수 있도록 Product Owner, Product Designer, Server Developer, Client Developer등 여러 동료들과 함께 일하고 자유롭게 아이데이션과 피드백을 주고 받으며 제품을 개선해 나가고 있어요
• 프론트엔드 챕터는 주기적으로 챕터 위클리를 진행하고 새로운 기술 토픽 또는 개발 노하우를 공유 및 논의하고 공통으로 사용할 라이브러리 개발 및 서비스 개발에 대한 코드리뷰를 함께 진행해요.
• 단일 코드베이스 안에서 서비스별 책임을 명확히 분리하고, 유지보수 및 변화에 유연하게 대응할 수 있도록 FSD 아키텍처를 도입, 구조적 개선을 이어가고 있어요
• 프론트엔드 챕터는 인앱웹뷰 기반으로 신규 서비스 런칭 및 마이그레이션 작업을 진행하고 있고, 앞으로 기존 서비스들을 인앱웹뷰로 전환해나갈 예정이에요
■ Experienced
플랫폼 파트의 프론트엔드 개발자는 서비스 성장을 이끄는 핵심 역할을 맡습니다.
웹 서비스 5개와 Flutter 앱 안의 인앱웹뷰를 함께 운영합니다. 15만 명 이상이 쓰는 프로덕션 환경에서 웹과 네이티브 사이의 성능, 품질, 자동화 문제를 함께 풀어갈 분을 찾습니다.
■ 프론트엔드 구성은 어떻게 되어 있나요?
• pnpm 모노레포와 Turborepo 위에서 웹앱 5개(사용자 서비스, 커머스, 파트너센터, 어드민, 스튜디오)와 공용 패키지 6개(디자인 시스템, 에디터, 모달, Sentry 등)를 운영합니다. 공용 패키지를 하나 바꾸면 여러 앱이 함께 영향을 받기 때문에, 빌드 의존 순서와 패키지 버전을 모노레포 전체 관점에서 관리합니다.
• React 19와 TypeScript를 기반으로, 서비스 특성에 맞게 Next.js(App Router)와 Vite SPA를 함께 운영합니다. Next.js에서는 Server Component와 Client Component의 경계를 import 구조까지 설계합니다. 잘못된 import 하나로 클라이언트 전용 코드가 서버 번들에 섞이면 빌드가 깨지기 때문입니다.
• 코드는 FSD(Feature-Sliced Design) 아키텍처로 구성합니다. 읽기는 entities, 쓰기는 features로 나누고, 도메인 index만 public API로 노출합니다. 중간 barrel 파일을 두지 않고 내부 참조는 상대경로로만 하여 순환 의존을 구조적으로 막습니다.
• 서버 상태는 TanStack Query로 관리합니다. Query Key Factory로 캐시 키를 계층화해 mutation 후 필요한 범위만 무효화합니다. Server Component에서 미리 받아 온 데이터는 하이드레이션으로 클라이언트 캐시에 이어 붙여, 첫 화면에서 요청이 중복되지 않게 합니다.
• 사용자 행동 분석(Segment)과 에러 모니터링(Sentry)은 공용 패키지로 묶어 여러 앱이 같은 이벤트 계약을 쓰도록 맞춥니다. 서브도메인 사이에 사용자 식별 정보가 섞이지 않도록 관리하는 것도 여기에 포함됩니다.
■ 인앱웹뷰에서 어떤 기술적 문제를 풀고 있나요?
• Flutter와 웹 사이의 타입 기반 브릿지 계약을 관리하고, 인증·세션 전달과 화면 전환이 일관되게 동작하도록 개발합니다. 웹·브릿지·네이티브 사이의 호출과 상태 흐름을 추적해 문제의 원인을 해결합니다.
• Android System WebView와 iOS WKWebView의 동작 차이를 고려해 쿠키·세션, 미디어 재생, 키보드와 Safe Area를 처리합니다. 실제 앱 사용 흐름에서 문제를 재현하고, 플랫폼 특성에 맞게 사용자 경험을 다듬습니다.
• 실제 기기의 웹뷰를 프로파일링해 JavaScript 실행, 렌더링, 웹·네이티브 상호작용의 병목을 분석합니다. 측정 결과를 바탕으로 개선 우선순위를 정하고, 변경 전후의 효과를 검증합니다.
■ 성능은 어떻게 다루나요?
▸ 지금 하고 있는 것
• 스크롤 리스너는 passive로 등록해, 스크롤이 메인 스레드가 아닌 컴포지터 스레드에서 처리되게 합니다. 스크롤 위치에 반응하는 UI가 있어도 스크롤이 끊기지 않게 하기 위해서입니다.
• 이모지 검색처럼 입력할 때마다 큰 목록을 다시 그려야 하는 UI는 useDeferredValue로 입력 반응을 먼저 처리하고, 목록 갱신은 그 뒤로 미룹니다.
• 무거운 컴포넌트는 동적 import로 분리해 초기 JS 양을 줄입니다. 저사양 Android 기기에서는 JS 다운로드보다 파싱과 실행 비용이 더 크기 때문입니다.
• Server Component에서 미리 받아 온 데이터를 하이드레이션으로 클라이언트 캐시에 이어 붙여, 첫 화면에서 같은 요청이 다시 나가지 않게 합니다.
• 이미지는 next/image와 srcset/sizes로 화면 크기에 맞는 해상도만 받습니다. 디코딩된 이미지는 파일 크기가 아니라 해상도 기준으로 메모리를 차지하기 때문에, 앱 프로세스와 메모리를 나눠 쓰는 웹뷰에서는 이 차이가 큽니다.
▸ 앞으로 함께 해 나갈 것
• 터치 반응 지연(INP)을 입력 지연, 이벤트 처리, 화면 반영 지연 세 단계로 나누어 측정하고, 어느 단계가 병목인지 근거를 갖고 개선하는 체계를 만들어 갑니다.
• Long Task를 잘게 나누어 브라우저에 실행을 양보(yield)하는 구조를 도입합니다. Android WebView(Chromium)와 iOS WKWebView(WebKit)의 API 지원 차이를 고려해 두 엔진 모두에서 동작하게 설계합니다.
• backdrop-filter처럼 페인트 비용이 큰 효과와 레이어 승격을 실제 기기에서 Layers 패널과 Paint Flashing으로 점검하고, 저사양 기기 기준으로 사용 범위를 정리합니다.
• 긴 목록에는 가상화와 content-visibility를 적용해, 화면 밖 영역의 렌더링 비용을 줄여 나갑니다.
• 웹과 Flutter 사이 브릿지 메시지의 직렬화 비용을 측정하고, 큰 데이터를 자주 주고받지 않는 메시지 구조로 다듬어 갑니다.
• Flutter 쪽에서도 웹뷰를 화면에 합성하는 방식에 따라 렌더링 성능 특성이 달라집니다. Android Hybrid Composition은 아직 stable 단계에 오르지 않아 지금은 쓰지 않고 있으며, stable로 올라오면 교체할 계획입니다. 이 전환 과정에서 웹과 앱 양쪽 관점으로 성능 차이를 측정하고 최적의 구성을 함께 찾아갑니다.
■ 테스트는 어떻게 하나요?
• 테스트 수준은 피라미드 공식이 아니라 위험도로 정합니다. 결제, 권한, 사용자 데이터처럼 틀리면 큰 문제가 되는 흐름은 성공 경로뿐 아니라 실패 후 복구, 중복 요청, 경계값까지 검증합니다.
• API, PG, SDK 같은 외부 경계만 MSW로 mock합니다. 테스트 대상인 훅과 컴포넌트는 실제로 실행해서, 부품 사이의 연결과 요청 횟수까지 검증합니다.
• 로딩 중 상태는 delay(100) 같은 고정 대기 대신, 테스트가 직접 열고 닫는 Promise gate로 제어합니다. CI 환경 속도에 따라 결과가 달라지는 flaky 테스트를 원천적으로 막기 위해서입니다.
• 날짜를 다루는 로직은 실행 환경의 타임존과 상관없이 같은 결과를 내야 합니다. 그래서 CI에서 서울과 뉴욕 타임존 매트릭스로 함께 검증합니다.
• 버그를 고칠 때는 재현 테스트를 먼저 작성하고, 리팩토링할 때는 현재 동작을 고정하는 테스트를 먼저 작성합니다. 정책이 확정되지 않은 수상한 동작은 정답으로 고정하지 않고, 결함 후보로 따로 기록합니다.
• 웹 E2E는 Playwright로 로그인 복귀, 결제 콜백처럼 여러 화면을 거치는 핵심 흐름부터 적용하고 있습니다.
■ 인앱웹뷰 E2E 자동화, 함께 만들어 갈 분을 찾습니다
• 웹 단독 E2E만으로는 브릿지 통신, 네이티브 로그인 이후의 세션 전달, 기기별 웹뷰 엔진 차이처럼 앱 안에서만 드러나는 문제를 잡을 수 없습니다.
• 그래서 AWS Device Farm으로 실제 iOS/Android 기기 풀에서 인앱웹뷰를 끝까지 자동 검증하는 E2E 기반을 준비하고 있습니다.
◦ Appium으로 네이티브 컨텍스트와 WEBVIEW 컨텍스트를 오가는 시나리오를 작성합니다.
◦ 여러 OS 버전과 제조사 기기 조합에서 회귀를 자동으로 찾아내는 파이프라인을 만듭니다.
◦ 실기기 실행마다 남는 영상, 로그, 성능 데이터를 실패 원인 분석과 기기별 성능 비교에 활용합니다.
• 이미 갖춰진 정답을 따라가는 일이 아닙니다. 실기기 E2E 자동화의 기반을 처음부터 설계하고 함께 준비해 가는 경험을 해 보고 싶은 분을 기다립니다.
■ AI는 어떻게 사용하고 있나요?
• CLAUDE.md, AGENTS.md와 규칙 파일로 아키텍처, 코딩 스타일, API 패턴, 테스트 기준, Git 워크플로우를 에이전트가 읽을 수 있는 컨텍스트로 정리해 두었습니다. 에이전트가 같은 실수를 반복하면 그 내용을 규칙에 다시 반영해 컨텍스트를 계속 개선합니다.
• FSD 보일러플레이트 생성, Figma를 컴포넌트로 옮기는 작업, QA 케이스 설계와 E2E 구현, 커밋과 PR 작성까지 반복되는 작업은 스킬과 에이전트로 자동화했습니다.
• 에이전트가 "완료"라고 말하기 전에 타입 체크, 린트, 테스트를 실제로 실행해 증거를 남기도록 검증 절차를 강제합니다.
• 컨텍스트를 설계해서 생산성을 높이는 일에 관심이 있다면 함께해 주세요.
■ 오픈소스 경험은 어떻게 도움이 되나요?
• 라이브러리 버그를 만나면 문제를 피해 가는 대신 소스를 직접 읽고 디버깅합니다. upstream 수정을 기다리기 어려우면 pnpm patch로 직접 패치하고, 가능하면 기여합니다.
• 대규모 의존성 업데이트는 영향 범위를 단계별로 나누어 진행합니다. 업데이트로 생긴 회귀는 버전 변경 내역(changelog)과 소스를 근거로 원인을 추적합니다.
• 프레임워크를 쓰기만 하는 사람이 아니라, 품질과 속도를 저울질해 필요할 때 직접 도구를 만들어 보고 싶은 분이라면 도전할 과제가 충분히 준비되어 있습니다.
주요업무
■ 합류하면 담당할 서비스• 구독형 금융 콘텐츠를 중심으로, 다양한 사용자들이 쉽고 편하게 콘텐츠를 소비하고 교류할 수 있는 플랫폼 서비스 제품을 만들어요
• 콘텐츠 제공자들에게 쉽고 편한 콘텐츠 생성을 지원하는 제품을 만들어요
• 어스 플랫폼 서비스의 내부 운영을 위한 서비스로 내부 직원들에게 더 쉽고 편하게 서비스를 관리할 수 있도록 서포트하는 제품을 만들어요
• 어스 플랫폼 서비스의 라이브 스트리밍 서비스를 위한 라이브 스튜디오 제품을 만들어요
• 어스 플랫폼 서비스의 인앱웹뷰 개발을 담당할거에요
■ 현재 사용중인 기술
• 코어: React, TypeScript, Next.js ( App Router ), Flutter
• 상태 관리: Tastack Query, Jotai
• 스타일링: tailwindcss, shadcn/ui
• 패키지 매니저: pnpm
• 빌드: Webpack, SWC, Vite
• CI/CD: GitHub Actions
• 테스트: Vitest, Storybook
• 모니터링: Sentry
자격요건
• React, Vue와 같은 SPA 프레임워크 사용에 능숙하신 분• Frontend 영역과 웹 서비스 환경에 대한 깊은 이해를 토대로 제품 개발에 기여하실 분
• 고객의 문제에 집중하여 복잡한 도메인을 유연한 시스템으로 풀어내는 역량을 갖추신 분
• 속도 저하를 유발할 가능성이 있는 기술 부채들을 인지하여 타협하지 않고 해결을 주도한 경험이 있는 분
• TypeScript를 이용한 JavaScript 정적 타입 분석을 경험해보신 분
• 주어진 업무에서 나아가 주도적으로 문제를 정의하고 해결하고자 하는 분
• 다양한 문제와 요구사항들에 대해서 그것을 추상화하고 코드로 표현할 수 있는 분
