[토스] 🔥 라이브모닥불 | AI 시대, 토스 FE는 어떻게 일할까

토스 챌린저스

토스는 AI 에이전트를 활용해 관리자 페이지 개발 과정을 자동화함으로써 6개월 만에 440여 개의 프로젝트를 생성하고 개발 리소스 효율을 극대화했습니다.

브라우저 기반의 가상 파일 시스템과 ESBuild를 활용한 최적화된 프리뷰 런타임을 구축해, 초기 47초가 걸리던 로딩 시간을 1.3초로 단축했습니다.

패키지 조합의 일관성을 유지하기 위해 '패키지 셋 해시' 개념을 도입하여 모노레포 환경에서 의존성 관리 문제를 해결하고 생산성을 높였습니다.

프론트엔드 개발 환경을 브라우저 안으로 가져오기 위해 '브라우저 런타임 내 개발 환경'을 구현하는 과정에서 여러 기술적 시행착오가 있었습니다. 초기에는 서버 기반 데브 서버를 사용했으나 격리 문제로 실패했고, 이후 도입한 샌드팩(Sandpack) 라이브러리는 패키지 다운로드 지연으로 인해 화면 로딩에 47초가 소요되는 한계가 있었습니다. 결과적으로 가상 파일 시스템과 **ES빌드(ESBuild)의 웹 어셈블리 버전을 활용하여 브라우저 내 번들링 속도를 1.3초로 단축**하는 데 성공했습니다.

패키지 의존성 관리의 파편화를 막기 위해 '카탈로그(Catalog)' 시스템을 도입했습니다. 카탈로그는 여러 프로젝트가 동일한 의존성 버전 집합을 참조하게 함으로써 **의존성 설치 시간과 패키지 용량을 획기적으로 줄였습니다.** 매월 새로운 버전의 카탈로그를 발행하여 메이저 버전 업데이트를 유도하고, 개발자들이 자율적으로 최신 기술 스택으로 마이그레이션할 수 있는 환경을 조성하여 사내 패키지 운영의 예측 가능성을 확보했습니다.

AI를 활용한 패키지 마이그레이션의 신뢰성을 높이기 위해 '증분 분석 문서(Incremental Analysis Document)'를 도입했습니다. 이는 배포된 타볼(Tarball)을 분석하여 변경점을 미리 구조화해 둔 일종의 고정밀 지도입니다. AI는 단순히 코드 모드에 의존하는 것이 아니라, **증분 분석 문서를 통해 실제 변경점에 기반한 브레이킹 체인지를 사전에 인지**하고, 인간 메인테이너와의 핸드오프를 통해 결정론적인 마이그레이션이 가능하도록 설계되었습니다.

AI가 생성한 결과물에 대한 검증을 위해 엔드투엔드(E2E) 테스트를 자산화하는 전략을 택했습니다. 코드베이스가 모든 기획 의도를 담고 있지 않다는 점을 인지하고, **사람이 직접 테스트 시나리오를 작성하고 AI가 이를 보조하는 방식으로 '깨지지 않는 E2E 환경'**을 구축했습니다. 실패한 테스트의 로그와 스크린덤프를 AI에게 전달하여 자가 치유(Self-healing)를 유도함으로써, AI 에이전트가 도구를 활용해 능동적으로 문제를 해결하도록 하는 프레임워크를 정립했습니다.

토스의 AI 활용 전략의 핵심은 '최고의 동료'와 함께하는 인프라 환경에 있습니다. 잘 갖춰진 로깅 시스템, 자체 디바이스 팜, 그리고 팀 간의 긴밀한 협업이 결합되어 AI의 생산성을 극대화합니다. 개발자는 AI에게 작업을 단순히 맡기는 것이 아니라, **명확한 도구와 문맥을 제공함으로써 '딸깍' 한 번으로 업무를 처리할 수 있는 신뢰 가능한 자동화 워크플로우**를 완성해 나가고 있습니다.

라이브 모닥불 소개 및 발표 주제 안내

프론트엔드 개발자 강윤호 님의 진행으로 라이브 모닥불 시작

오늘의 발표 주제는 'AI, 모노레포, 어드민까지 프론트엔드 플랫폼 이야기'로, 토스팀의 AI 활용 사례를 공유

첫 번째 발표: AI 시대 어드민 - 브라우저 안에 개발 환경 만들기 (이현재 님)

발표 주제는 AI 시대에 AI를 활용하여 어드민을 만드는 과정에서 브라우저 안에서 사용자에게 어드민을 보여주는 프론트엔드 엔지니어링 측면의 개발 환경 구축 도전

이현재 님은 토스코어 프론트엔드 엔지니어로서 인터널 조직에서 어드민 제품을 만들고 있음

일반적인 서비스 및 어드민 개발 과정과 AI 시대의 차이점

프론트엔드 서비스 개발은 스캐폴딩, 패키지 의존성 추가, 빌드 도구 선택, 인증, 배포, 코드 작성 및 빌드/배포의 과정을 거침

어드민 개발은 보안, 정보 수집, 로그 증적, 파일 다운로드, 암호화, 마스킹 정책 등 추가적인 고려사항이 있음

기존 어드민 개발의 페인 포인트: 과정 반복, 개별 어드민에 보안 및 도메인 지식 규칙 적용의 어려움

토스의 AI 기반 어드민 생성 시스템 'TY' 소개

AI를 활용하여 프롬프트 입력만으로 어드민 화면을 생성하는 시연 영상 공개 (SQL 질문 등을 통해 어드민 생성)

몇 분 만에 어드민이 생성되며, 이 과정에는 API 등록 및 정책 적용이 포함

중앙에서 제어하는 플랫폼으로서의 어드민은 컴플라이언스(데이터 처리 정책)를 유관 부서와 협의하여 제품에 반영

TY 도입 후 반년 만에 440여 개 프로젝트, 2,400여 개 페이지가 생성되었고, 현재 120개 정도가 라이브 중

TY 개발 배경 및 어드민의 역할 분리

개발 배경: 토스의 빠른 비즈니스 성장으로 인한 어드민 수요 증가, FE 리소스 부족, 반복적인 개발 과정 문제 해결

어드민 역할: 데이터 처리 및 컴플라이언스 컨트롤(플랫폼에서 정책 정의), 화면 표시(AI가 API 스키마 참조하여 코드 생성 및 패턴 적용)

AI 생성 코드의 브라우저 개발 환경 구현 난관과 해결 과정

문제점: AI가 만든 코드를 브라우저 런타임에서 사용자에게 보여주기 위해 개발 환경을 브라우저 안으로 가져와야 함

시도 1 (Dev 서버): Next.js Dev 서버를 띄워 iframe 연결. POC에는 충분했으나, 에러 오버레이가 전체 전파되는 격리 문제 발생

시도 2 (샌드팩 - 코드 샌드박스 라이브러리): 브라우저 격리를 위해 샌드팩 사용. 초기 로딩 47초로 매우 느렸고(패키지 다운로드), 사내 패키지 주입 어려움

최종 해결 (직접 구현): 사용자 브라우저에서 실시간으로 코드 빌드, 패키지는 미리 준비, 실행 결과물을 화면에 표시

가상 파일 시스템 및 ESBuild-wasm 활용: 브라우저에 파일 시스템이 없어 가상 파일 시스템 구현, ESBuild-wasm으로 파일 해석 및 번들링

패키지 시스템 개선: 초기 고정 패키지 조합에서 동적 변화 대응 필요. 싱글톤 깨짐 문제 해결을 위해 '패키지 셋 해시' 개념 도입. 패키지 조합을 해싱하여 S3에 업로드 및 임포트 맵 사용

성능 개선: 직접 구현 후 로딩 시간을 47초에서 1.3초로 단축

엔지니어의 역할과 AI 활용의 의미

엔지니어는 제품 요구사항에 맞춰 경계를 설정하고, 안전하고 빠르게 코드가 실행될 구조를 만드는 역할. 기존 라이브러리/도구를 잘 조합하는 것이 중요

AI를 개인이 잘 쓰면 10x 엔지니어, 조직의 문제를 구조화하여 AI 활용 제품을 만들면 조직 전체의 10x 효과를 낼 수 있음

브라우저의 가상 파일 시스템은 메모리에서만 활용되며, 실제 코드는 S3에서 사용자 편집에 따라 업데이트됨

AI에게 어드민 페이지 요청 시 벡터화 사용 여부는 질문자가 추가 설명을 요청

두 번째 발표: AI 시대에 준비된 모노레포 (박성범, 이호현 님)

발표 주제: 토스의 모노레포 운영 방식과 AI 활용 사례 소개

박성범 님 (클라이언트 SR팀 프론트엔드 플랫폼 엔지니어), 이호현 님 (데스크탑 플랫폼팀 프론트엔드 플랫폼 엔지니어)

현재 수십 명의 개발자가 수백 개의 제품을 하나의 모노레포에서 최신 의존성 버전으로 공유하며 개발

과거에는 제품별로 의존성 버전과 개발 환경이 파편화되어 기술 스택 불균일

문제 1: 의존성 크기 증가 및 설치 시간 증대 (한 번 설치에 8분 이상 소요)

문제 2: 의존성 파편화로 인한 업데이트의 두려움. 사내 라이브러리 개선 시도 어려움, 서비스 개발자는 최신 기술 활용 기회 상실

해결책으로 폴리리포를 고려했으나, 파편화 심화 및 툴링 공유 어려움. 토스 조직 구조상 모노레포의 편익이 더 큼

문제의 근본 원인을 '모노레포 구조 자체'가 아닌 '개발 환경 파편화'로 정의

카탈로그 도입을 통한 의존성 통합

모든 제품이 같은 의존성 버전을 공유하여 개발/테스트 환경 통일

카탈로그: Yarn이나 pnpm 같은 패키지 매니저 기능으로, 하나의 파일에 의존성 종류/버전 집합을 정의하고 여러 패키지에서 참조

모노레포 루트 설정 파일에서 의존성 정의, 각 제품의 package.에서 카탈로그 참조

개선 효과: pnpm-lock.yaml 파일 크기 84% 감소, 의존성 설치 시간 절반 이상 단축. 사내 라이브러리 업데이트 및 제품 전파 용이, 서비스 개발자는 최신 기술 활용 가능

카탈로그 운영의 도전과 버전 관리

문제점: 하나의 카탈로그만 바라보면 예상치 못한 Breaking Change 발생 가능성 (예: Next.js 12 → 16 강제 업데이트)

해결책: 카탈로그를 버전링하여 매월 새로운 버전 발행. 의존성의 메이저 버전 업데이트 시 새로운 카탈로그 발행

운영 방식: 매월 초 사내 패키지 개발자들이 모여 변경 사항 공유, 메이저 버전 업데이트 시 월말에 새 카탈로그 발행. 제품 개발자들은 자율적으로 새 카탈로그로 마이그레이션

운영 예시: 월별 카탈로그 발행에도 불구하고, 일부 제품(예: 송금)은 마이그레이션 지연으로 오래된 카탈로그에 머무는 문제 발생

결과적으로 의존성 표준이 깨지고 파편화 문제가 재발하는 것처럼 보임

카탈로그 파편화 문제 해결: AI 기반 자동 마이그레이션 (오토파일럿)

문제 정의: 카탈로그 자체의 파편화는 마이그레이션 비용 문제. 마이그레이션 부담을 줄이고 플랫폼이 책임을 가져가 비용을 낮추자

기존 방식: 메인테이너가 코드 모드(AST 파싱 기반 기계적 코드 변경) 작성. 시간 소요, 코드베이스 다양성으로 일부 동작 실패, 수동 수정 필요 등 고통스러운 과정

목표: 마이그레이션을 테슬라 오토파일럿처럼 만들어, 사람은 확인만으로 안정적으로 목적지까지 도착하도록

AI 직접 적용의 문제점: 맥락 없는 요청 시 Breaking Change 간과, 토큰 과다 소모, AI 서버 트래픽에 따른 결과 품질 저하 (운에 좌우)

해결 기준: '가끔 잘 되면 된다'가 아닌, '누가 어느 상황에 언제 돌려도 항상 일관되게 잘 돌아가야' 하는 최소한의 안전 기준 만족

두 가지 축: 행동의 표준화 (정해진 주행 절차) 및 근거의 표준화 (고정밀 지도)

행동의 표준화: AI 에이전트의 마이그레이션 스킬 개발

카탈로그 마이그레이션 시 필요한 규칙(현재/목표 버전 확인, 코드 모드 실행 등)을 담은 스킬(플로우차트) 개발

코드 모드를 대체하는 것이 아니라, AI가 마치 사람처럼 코드 모드를 실행하고, 수동 수정 필요 부분은 AI가 추론 수정, 마지막으로 회기 확인

근거의 표준화: 증분 문서 (고정밀 지도) 구축

문제점: AI가 매번 변경점을 찾아 수정하기 어렵고, 결정론적으로 동작하지 않으며 실수 발생 가능성

증분 문서: 패키지(예: React)의 구간별 변경점(tarball 다운로드 및 diff 분석)을 미리 문서화(캐싱하듯이 구조화된 마크다운 작성)

활용 사례: Semantic Versioning이 거짓말하는 경우(예: 패치 업데이트인데 실제 Breaking Change 발생) 증분 문서가 실제 tarball 기반 분석으로 위험 감지

플라이휠 효과: 한 명의 마이그레이션으로 증분 문서가 쌓이고, 전사가 이를 활용하여 지식이 지속적으로 축적되는 구조

모노레포 및 AI 마이그레이션 Q&A

Breaking Change 분석 시 tarball diff 외에 GH changelog 등 참조 여부: 현재 사내 패키지 위주, 외부 패키지는 changelog 등 포함 예정. 가장 정확한 건 tarball 분석

라이브러리 팀이 직접 도구 만들어 배포 대신 소스 코드 수정 방식 비효율적 여부: 서비스가 너무 많아 직접 수정은 어려움

AI 에이전트의 넓은 코드 맥락 이해 문제: 토스는 도메인별 분리가 잘 되어 있어 큰 문제 없음. 서비스별 정리 및 컨텍스트 한 번에 처리할 일 적음

맥락 제공에 오픈 위키/그래피파이 사용 여부: 그래피파이와 유사한 맥락

오래된 패키지 업데이트 대신 교체/새로운 패키지 생성 대응: 증분 문서 스킬로 소급 적용 후 해당 팀/코드 오너 리뷰 통해 반영

회기 오류 없는 마이그레이션 검증: 코드 맥락이 많은 팀에 리뷰 요청. 증분 문서 스킬은 민감하게 설정하여 '아닌데 맞다'보다 '맞는데 아니다'가 낫다는 기조

AI의 비결정성 문제 해결: 의도한 대로 False Negative는 없어짐. 근거 없는 마이그레이션은 중단하고 보고. 중대한 오류는 막을 수 있음

최종 목표: '송금 서비스를 이 트래거로 마이그레이션 해줘'처럼 딸깍하는 경험으로, 모두가 규모의 경제를 누리며 쾌적하게 개발할 수 있는 환경 구축

세 번째 발표: AI로 만든 결과물 어떻게 검증하고 있나 (최지민 님)

발표 주제: AI 시대에 AI가 만든 결과물을 어떻게 효과적으로 검증하고 신뢰할 수 있는지에 대한 토스팀의 고민과 진행 과정 공유

최지민 님 (프론트 AI팀, 김예준 님과 2인 팀). 토스 프론트엔드 엔지니어들이 AI를 편하고 잘 쓸 수 있는 환경 연구 및 플랫폼 조직

팀 목표: AI가 가장 잘 일할 수 있는 환경을 만들고, AI 워크플로우가 토스팀 합류의 강력한 이유가 되도록

AI 시대의 프론트엔드 워크플로우와 새로운 문제

일반적인 워크플로우: 스펙 논의, 디자인 분석, 코드 계획/작성, 자체 검증, 알파 배포, 품질 보증(QA/인수 테스트), 라이브 배포, 피드백 대응

AI 도입 후 속도/양 4배 이상 증가. 하지만, AI가 생성한 코드 이해 및 검증에 필요한 시간이 증가하여, 결과물을 '믿기까지의 수고'가 늘어남

과제: AI를 더 잘 쓰기 위해 '검증의 문제'를 해결하고, 결과물을 '더 잘 믿을 수 있는' 방법에 집중

E2E 테스트 도입 시도와 방향 전환

실제 디바이스 팜에서 구동되는 E2E 테스트 샘플 (광고 보고 포인트 받는 퍼널) 시연

초기 접근 (코드 베이스): 코드 제너레이션에 AI 강점이 있고, 모노레포 내 노하우/참조 영역이 많아 코드에 진실이 담겨있다고 판단. 화면 흐름 추론, 시나리오 생성, E2E 생성 자동화 시도

실패 원인: 코드에는 모든 것이 담겼으나, '무엇이 중요한지'는 코드에 바로 드러나지 않는 사람의 의도(기획자/디자이너)가 부족

방향 전환: 제품 팀 관점에서 '고객(프론트엔드 개발자)'에게 직접 니즈 파악

고객 니즈: E2E 테스트가 필요하지만 만들지 못하고 있음. 유닛/통합 테스트와 달리 엔드투엔드를 커버하기 위해 타 팀 협업 필요, 빠른 이터레이션에서 놓치는 부분 발생

현재 검증 방식: AI가 다른 워크플로우를 효율화했으나, 검증(QA)은 사람이 수동으로 진행 중

E2E 테스트의 목표: 최대한 의존성을 없애고 표면(실제 유저 경험)에 의존, 언제 돌려도 동일한 결과 보장(플래키 제거), AI를 활용하여 생산/유지보수 비용 절감, 자산화

E2E 테스트 구현: 사람 기반 접근 및 협업

사람 기반 접근: E2E가 자산이 될 만한 팀(예: 얼굴 결제, 토스 쇼핑처럼 실수 파급력이 큰 영역)을 찾아 직접 투입하여 테스트 작성

다양한 팀과의 협업: 테스트 가능한 API 마련, 인증/네이티브 앱 동작/어드민 상품 생성 등 E2E 테스트를 위해 필요한 API 및 도구 요청 및 구축

내부 도구 활용 및 개발: 자체 디바이스 팜 팀과 협업, 시나리오 작성을 위한 QA 로그 분석(키바나 로그), 에이전트가 도구를 쓸 수 있는 에이전트 디바이스 개념 도입, AI로 UI 도구 제작

E2E 테스트 작성 과정 (시연): 자연어로 테스트 시나리오를 지시하고, AI가 수행하는 화면을 보며 직접 클릭/조작하여 시나리오를 완성하면, AI가 그 과정을 E2E 테스트 코드로 자동 생성

목표: E2E 테스트가 자산으로서 유지되기 위해 '깨지지 않는 E2E'. AI가 스스로 깨진 테스트를 고칠 수 있도록

[토스] 🔥 라이브모닥불 | AI 시대, 토스 FE는 어떻게 일할까

스크립트