토스 메이커스 컨퍼런스 2025 프론트엔드 세션 후기 및 요약

정소현·2025년 7월 25일

프론트엔드 일지

목록 보기

4/4

👩‍💻 토스 메이커스 컨퍼런스 2025 – 프론트엔드 세션 후기
2025.07.25 | 프론트엔드 개발자 정소현

안녕하세요! 프론트엔드 개발자 정소현입니다.
2025년 7월 25일에 열린 토스 메이커스 컨퍼런스 2025에 다녀왔는데요,
그 중 프론트엔드 세션을 중심으로 제가 느꼈던 점과 얻은 인사이트들을 정리해보려고 해요.

저에게는 첫 컨퍼런스 참여였는데,
신선한 자극, 깊은 반성, 그리고 실제 업무에 적용할 수 있는 영감까지 얻을 수 있었던 뜻깊은 경험이었습니다.

많은 시도를 던지고 실패를 경험하고, 그 실패에서 또 다른 아이디어를 만들어내는 토스의 문화가 많은 자극을 주고 멋있다고 생각했어요.

나의 실패를 복기하고 공유하며 함께 더 빠르게 나아갈 수 있는 환경을 만드는 것이 멋진 문화인 것 같습니다.

또, 불편함에 끝나는 것이 아닌 불편함을 해소하기 위해 많은 고민을 한다라는 게 느껴져서 저도 평소 겪었던 불편함들에 대해서 적극적으로 해소하고 개선해보고 싶다는 생각이 들었어요.

🎯 컨퍼런스를 통해 얻은 핵심 인사이트

개발자로서 저는 단순히 잘 만드는 것을 넘어,

“적은 리소스로 높은 안정성과 생산성을 유지하면서 사용자에게 일관된 경험을 제공할 수 있는 개발자”가 되어야겠다는 결심을 했습니다.

그 중에서도 특히 아래 세 가지를 제 업무와 성장에 꼭 적용하고 싶어요:

✅ 테스트 코드의 중요성
테스트는 단순한 검증이 아니라 문서이자 안전망이라는 것을 다시 느꼈어요.

특히 E2E 테스트 자동화, 접근성 기반 테스트, 모델 기반 테스트 도구(Piece of Cake) 같은 세션을 보면서,

누구나 테스트를 쉽게 작성할 수 있는 환경을 만들 필요성과,

테스트 코드의 작성으로 장기적인 비용절감과 기능 확장의 용이성을 만들어낼 수 있다고 생각했어요..!

🧱 확장성과 유연성을 가진 코드
100년 가는 SDK, 마이크로 프론트엔드 구조 같은 세션에서는

코드 설계의 확장성과 유연성, 그리고 도메인 경계를 어떻게 잡아야 하는지 배울 수 있었어요.

기술적인 완성도 못지않게,

“어떻게 조직 내에서 설계와 기술이 협업될 수 있을지”를 고려하는 엔지니어로 성장하고 싶어졌습니다.

📊 에러 리포팅 & 통계 자동화 → DX 개선
장애 대응 자동화, 에러 모니터링 설계, 알림 시스템 설계 등의 사례를 보며,

“문제가 생긴 후 대응”이 아닌,
“문제가 생기기 전에 조직이 반응할 수 있는 구조”를 만드는 것이 중요하다는 걸 느꼈습니다.

개발자는 단순히 기능을 구현하는 사람이 아니라,
조직 전체의 개발 효율성과 안정성을 설계하는 역할도 해야 한다는 점에서 큰 책임감을 느꼈어요.

✨ 마무리하며
이번 컨퍼런스를 통해 단순히 “개발을 잘하는 사람”이 아니라,

“비즈니스와 기술을 연결하고, 조직 전체의 방향성까지 고려하는 프론트엔드 개발자”가 되고 싶다는 목표가 생겼습니다.

🚀 앞으로는

테스트 자동화,

기술 전파 설계,

접근성과 DX에 대한 관심을 더 키워가며
실력과 영향력을 함께 키우는 엔지니어가 되려고 합니다..!

아래부분들은 제가 토스 세션들을 들으면서 내용들을 정리했던 부분들입니다☑️

☑️ 세션 리스트

60개 React Native 패키지, 하나의 프레임워크로
Native ESM에 올라탄 마이크로 프론트엔드
언제나 누구에게나 평등하게 빠른 웹
100년가는 프론트엔드 코드
알림부터 대응까지, 장애 대응을 시스템으로
기술 중심 엔지니어에서 조직 중심 엔지니어로
누구나 작성하는 E2E 테스트를 향하여: 접근성에서 찾은 답

오프닝 세션 요약

실패를 감추지 말자 실패는 자연스럽고 중요한 학습의 기회. 숨기지 않고 드러내어 빠르게 보완할 수 있어야 함.
"내가 만들었다면?"이라는 시선으로 접근하자 문제 해결 중심의 태도 강조.

세션1 : 60개 React Native 패키지, 하나의 프레임워크로

발표자 : 김희철

👀 문제 인식

iOS vs Android 동작 차이

같은 코드라도 플랫폼별로 동작 방식이 다름.
버그가 수정된 패키지 버전 확인 어려움.
정확한 사용 예시 및 레퍼런스 부족.

📦 라이브러리 이슈

약 60개의 외부 라이브러리 사용 중.
역할과 책임이 분리된 패키지들이 계속 추가됨.
각 버전의 차이점을 인지해야 함.
일부 라이브러리 미업데이트 시 전체 기능이 정상 작동하지 않는 경우 존재.
변경에 대한 두려움이 크고 커뮤니케이션 어려움 발생.

🧩 해결 방법

1. 프레임워크 중심 재설계

하나의 공통된 언어로 소통 가능.
의존성을 최소화하고 버전 통일:
- ex. tosscore/granite, tosscore/granite-native
필요한 패키지만 package.json에 명시.
여러 패키지에서 컴포넌트를 가져오던 방식 → 단일 프레임워크 패키지로 통합.

2. E2E 테스트 자동화

프레임워크 변경마다 자동 테스트 수행.
기능 테스트, 회귀 테스트 → 리팩토링 시 안정성 보장.
테스트 자체가 공식 문서 역할 수행:
- 시그니처, 파라미터, 예제 코드 제공.

3. 문서화 및 기반 강화

명확한 역할 정의 → 글로 쓰기 쉬워지고 레퍼런스 확보.
Technical Writer → 리뷰 → 개발자 반영 후 배포.
기준을 충족한 코드만 프로젝트에 반영 가능.

4. _app.tsx 구성 변경 예시

Before	After
많은 정보 노출	필요한 정보만 노출
의존성 복잡	의존성 최소화
중복 컴포넌트 참조	단일 프레임워크에서 가져오도록 변경

🔁 테스트에 대한 철학

회귀 테스트는 기존 기능이 변경 없이 잘 작동하는지 확인하는 안전장치.
리팩토링을 위해서도 지속 가능한 테스트 환경이 반드시 필요.
테스트는 단순 확인이 아니라 문서화 + 팀 지식 공유의 도구.

❓ 질의응답

Q1. 엔트리 포인트를 여러 개로 구성할 때 배럴 파일 관련 이슈?

A: 배럴 파일이 많아질수록 번들 크기 증가 위험 → tree shaking 최적화로 해결.

Q2. 라이브러리 테스트만으로 도메인 내 문제를 모두 커버할 수 있는가?

A: 어렵다. 비즈니스 도메인에서 실제 사용하는 상황에서도 반드시 테스트 병행 필요.

granite QR :

Native ESM에 올라탄 마이크로 프론트엔드

발표자: 박건영, 장재영 (토스증권)

❗ 문제 정의

📉 생산성 저하

빌드 30분, Dev 서버 실행 5분 → 개발 생산성 저하

💡 근본 문제

수많은 변경사항이 한 번에 배포되어야 함!

배포 단위를 세분화할 필요 → 페이지 단위 도메인 분할로 해결

🧩 해결 전략: 마이크로 프론트엔드 + Native ESM

📌 설계 방향

페이지 단위로 앱 분할 → 팀 단위로 개별 배포
런타임 통합: 마이크로 앱을 동적으로 로딩
SPA와 차별점: 페이지마다 별도 빌드 & 동적 로딩

⚙️ 주요 기술 구성

1. Native ESM

브라우저에서 실행 시점에 ESM 모듈 직접 로딩
어떤 서비스를 불러올지 동적으로 판단

2. Import Map

HTML의 <head>에 import map 삽입
모듈 경로를 정의 → 브라우저가 어떤 주소에서 모듈을 불러올지 인지
웹 서버가 현재 import map 기준으로 HTML 생성 후 사용자에게 전달

3. 라우팅 처리

내부 또는 외부 페이지 이동 모두 고려
자체 SPA 라우팅 라이브러리를 사용해 처리

🛠️ 실제 구현 방식

✅ 번들 구조 및 배포

팀별 번들 존재 → 개별 배포 가능
웹 서버에서 번들 주소를 조합해 HTML 생성
HTML에는 ESM 주소, import map 포함

⚙️ 배포 환경

카나리 배포:
- 쿠키 값 기반으로 서로 다른 import map 생성
- 특정 유저만 새로운 기능에 접근 가능 (v1 / v2 선택적 분기)
프리뷰 배포:
- 개별 브랜치 기준 배포 → 디자이너가 실제로 확인 가능

💻 로컬 개발

특정 서비스만 Dev 모드로 실행 가능
전체 앱 구동 없이 빠른 실행 → 가벼운 개발 환경

📦 번들 최적화 & 호환성

중복 코드 이슈 해결

Sentry 등 공통 라이브러리 중복 포함 → 번들 커짐
해결: shared.modules.js에 공통 모듈 통합 → 중복 제거 + JS 리소스 정보 최소화

브라우저 호환성

최신 브라우저: Native ESM + Import Map 사용
구버전 대응: SystemJS 라이브러리 사용

📈 개선 결과 요약

항목	기존	개선 후
빌드 시간	30분	1분
Dev 서버 실행	5분	5초
배포 방식	전체 통합	팀별 독립 배포
로딩 방식	전체 로딩	페이지 단위 동적 로딩

❓ Q&A

Q. 마이크로 프론트 간 이동 시 상태는 어떻게 유지하나요?

마이크로 앱 mount/unmount를 명시적으로 선언
React 상태는 사라지지만 전역 상태 관리 도구로 유지

언제나 누구에게나 평등하게 빠른 웹

발표자: 강현구 (토스뱅크)

❗ 문제 인식

⚠️ 모두에게 같은 속도? 어려운 과제

유저마다 네트워크 환경, 하드웨어 성능이 상이함
→ 동일한 사용자에게도 매번 성능이 다를 수 있음

🙅 양질의 네트워크 기반 개발의 맹점

개발자는 빠른 환경에서 개발하지만,
유저는 상황에 따라 느린 웹 경험을 하게 됨

🎯 목표

모든 유저에게 평등한 속도 경험 제공
- 단순히 평균 속도가 아닌, 일관된 성능
React Native처럼 네트워크 변수 없이 동일한 성능을 목표로

🧪 시도 1: Critical Resource 최적화

✅ 전략

SSR 환경 + 지연 요청 처리 → CSS 먼저, JS 나중에 받아 화면 빠르게 노출
Critical Resource 중심 설계 (e.g. TDS 디자인 시스템)

📦 캐싱 전략

리소스를 로컬에서 가져오는 것이 이상적 → HTTP 캐시 활용
동일한 TDS 버전과 페이지 로직을 캐싱해 빠른 초기 로딩 가능

⚠️ 주의점

HTML은 SSR 환경에서 캐싱 금지
- CSR은 API 의존성 ↑ → SSR 선택
SWR 방식(Stale While Revalidate):
- 1번 버전으로 먼저 보여주고, 2번은 백그라운드에서 갱신
- 하지만 SWR 사용 시 HTML 캐싱도 필요함 → 한계 발생

🧪 시도 2: Payload 기반 preload 전략

🛠 핵심 구조

Service Worker 기반 프리로딩 (iOS 한계 존재)
Preload 도구 + Native 툴 활용

🔍 Preload List 선정 기준

유저 유입이 높은 첫 진입 페이지 중심
각 페이지별 필요한 리소스 선별 → 빌드 시 자동 추출
CSS 리스트도 함께 preload list에 포함

⚙️ 최적화 방식

중복 호출 방지: E-Tag (NTT 태그 기반) 사용
유저 타겟팅:
- 최근 5일 이내 접속 유저
- Wi-Fi 또는 무제한 요금제 유저만 대상
효율적인 리소스 사용 + 비용 절감

📈 성과

FCP (First Contentful Paint): 1.8초 이내 목표
프리로드 도입으로 최대 30% 성능 개선

😥 Fade Out된 이유

지속적인 배포 주기:
- 신규 배포가 잦아 preload 준비 시간 부족
비용 증가:
- 사용하지 않는 유저에게도 CDN 요청 증가
효율 대비 비용 증가 → 운영에서 제외

💡 결론 및 인사이트

"정형화된 최적화 전략"만으로는 충분하지 않다
서비스 특성에 맞춰 새로운 웹 서빙 전략을 실험해야 한다
웹 경험에 있어 "평등"을 추구하는 새로운 패러다임 가능성 제시

100년가는 프론트엔드 코드

발표자 : 박성현, 최진영 (토스 페이먼츠)

🎯 SDK 개발의 목적과 배경

🧩 FE 개발과 SDK 개발의 차이

SDK는 가맹점 코드 속에 깊숙이 내재
가맹점의 런타임 환경, 호출 방식에 직접 영향을 받음
한 번 연동되면 가맹점과 동일한 수명을 가짐

🔧 API 제공자의 역할

가맹점 비즈니스 연속성 보장
확장성 있는 인터페이스 제공
가맹점 개발자의 생산성 확보

v2 SDK 목표: 안정성 · 확장성 · 명확성

✅ 안정성

🧨 문제

SDK의 생명주기가 가맹점 코드에 의존적
QA로는 커버되지 않는 이슈들 발생
- 예: 특정 가맹점에서만 결제 실패, 특정 브라우저 환경 등
- 느낌상 “디도스”처럼 예측 불가한 문제들

🛠 해결

브랜드페이 유스케이스 기준 300+ 테스트 케이스 작성
자동화된 테스트 기반 검증
대시보드 & 알림 시스템으로 테스트 사각지대 보완
Monitor CLI Report 도입:
- 결제 성공률 하락 원인을 추적
- Global Trace ID 활용하여 전체 시스템 로그 연동 추적 가능

🧩 확장성: 조립 가능한 SDK

🎯 요구사항

특정 상황에서 결제 불가 유효성 검사 요청
초기 대응: if 문 추가 → 핵심 로직 오염 발생

🔄 구조적 개선

커스텀 로직은 레고 블록처럼 조립 가능하게 분리
핵심 로직과 가맹점 특수 요구 분리 → SDK의 유연성 극대화

🔧 레이어 기반 설계 원칙

"변경의 원인이 되는 곳을 기준으로 경계를 나눠라"

변경 대상	책임 영역 (Layer)
가맹점이 사용하는 메서드 형태 변경	Public Interface Layer
비즈니스 로직 변경	Domain Layer
외부 서비스, 서버 엔드포인트 변경	External Service Layer

📖 명확성: 명시적 계약 기반 개발

🤝 코드 = 계약

SDK의 함수는 단순한 코드가 아니라 “계약”
npm 배포: tosspayments/standard-public
Git을 계약서이자 히스토리 북으로 활용
- 커밋 메시지에 Slack 링크 첨부 → 기록 자동화

🧾 살아있는 연동 문서

TypeScript로 작성된 코드 → 자동 문서화
유효성 검사 계층도 문서화
개발자센터에서도 확인 가능 → Toss Payments 개발자 센터

📌 요약

항목	내용
🎯 목표	안정성 · 확장성 · 명확성
🧨 문제	다양한 가맹점 환경에 의한 예외 발생
🛠 해결	자동화 테스트, 모니터링, 레이어드 설계, 계약 기반 문서화
🚀 결과	100년 가는 SDK를 위한 기반 완성

알림부터 대응까지, 장애 대응을 시스템으로

발표자: 최강혁 (토스)

🏗️ 문제 정의

토스 프론트엔드 MSA 구조의 현실

하나의 앱에 수십 개 서비스가 존재 → 장애 인지 자체가 어려움
sentry: 서비스별 설정은 가능하지만 서비스 간 구분 어려움
500 에러 등 인프라 알림은 분석 없이는 담당 서비스 파악 어려움
로그 분석을 통한 수동 대응:
- 플랫폼팀이 우선 인지
- 수동 분류 후 각 서비스 담당자에게 전달
- 플랫폼팀에 대응 책임이 집중 → 병목 발생

✅ 해결 전략

📦 장애 대응 시스템의 핵심: 바로 문제를 아는 사람에게 알린다

1. ⚙️ 알림 자동 전달 시스템 구축

Sentry + Opsgenie 연동

서비스별로 Sentry 설정 → 각 서비스가 발생시 알림
알림은 Opsgenie를 통해 자동 라우팅:
1. 1차: 코드 오너
2. 2차: 대리인
3. 3차: 트라이브 전체
4. 최종: 플랫폼팀

🔔 다양한 알림 채널

Slack, 앱 알림 등 병렬 전달
대부분 1차 코드 오너 선에서 즉시 대응

2. 🧩 알림 설정의 코드화

서비스별 담당자와 알림 수신 대상, 순서, 채널을 코드로 명시
IaC 방식 (terraform) 으로 관리
신규 서비스는 템플릿 기반으로 쉽게 연동 가능

3. ✅ 대응 상태 추적 프로세스

단계	설명
✅ Ack	알림 확인 응답
🔧 Resolve	에러 조건 사라짐 (예: 에러 빈도 감소)
📌 대응 확인	문제가 실제로 해결되었는지 수동 체크 필요

※ 새벽/주말 대응 누락 방지, 장애 이력 명확화 목적

4. 📉 Alert 무시 현상 방지

문제

알림이 많으면 무뎌짐 → 무시하게 됨

해결

반복되지만 무해한 에러는 필터링
- Sentry Inbound 필터링
- 코드 레벨 전송 차단
Alert 자체도 모니터링 대상으로 관리
우선순위 기반 정렬:
- 중요한 알림은 강조
- 영향도가 낮거나 일시적 기능은 비우선 처리

5. 🔎 장애 대응 시스템도 감시 대상

알림 시스템도 결국 하나의 소프트웨어
알림이 전달되지 않거나, 대응 기록 누락 발생 가능
시스템 장애까지 고려한 이중 안전장치 필요

🎯 성과 및 효과

플랫폼팀 개입 없이 자동 알림 전달 및 선 대응 가능
반복되는 장애는 공통 프레임워크 수준에서 해결
중복 대응/혼선 감소 → 전사적 생산성 향상
장애 대응 가이드 없이도 모든 팀이 동일한 기준으로 대응 가능

🔭 Next 목표

프론트엔드 전담 SRE 팀 신설
- 어떤 에러를 Alert로 볼지, 어떤 지표를 모니터링할지 논의
Opsgenie 종료 예정 → 신규 컴포넌트로 교체 작업
신규 배포 시스템 완성 후 연동 계획

기술 중심 엔지니어에서 조직 중심 엔지니어로

발표자 : 진유림 (통합 시스텝)

❗ 문제의식

“기술적으로 완벽하게 만들었는데 아무도 안 써요”

공통 API를 만들었지만 다른 팀은 기존 방식 유지
코드만 잘 짜면 된다? → No. 진짜 엔지니어의 일은 그 이상이다.

🎯 조직 중심 엔지니어로의 성장

✅ 기술 중심 → 조직 중심 변화

기술 중심	조직 중심
잘 만드는 데 집중	잘 쓰이게 만드는 데 집중
기술적 완성	조직 설계, 협업 설계 포함
내 몫을 다했다	팀 전체가 성공해야 의미 있음

🔑 핵심 능력 3가지

1. 🧱 잘 만들기 + 퍼뜨리기

기술을 만들고 전파까지 책임지기
단순 B2B 기술 제공이 아니라 ‘비즈니스 통합’ 관점으로 접근
협업도 지속 가능하게 만들어야 진짜 실력

질문: "직접 개발하게 할까? 함께 하게 만들까?"

정답은 "둘 다 가능해야 한다"
회고를 통해 기준을 만든다:
- 어려웠던 순간들을 기반으로 기준 설정
- 확장성 / 경제성 / 목적성에 따라 판단
- 팀 차원의 의사결정 기준 확보

2. 📡 미래를 함께 설계하기

기술을 퍼뜨릴 때는 “우리 팀의 목표”를 넘어 상대 팀의 목표와 연결시켜야 함
기술은 "공감"으로 전파된다
*“이 기술을 쓰면 상대 팀의 성과도 올라간다!”**를 만들어야 한다

신뢰를 얻는 기술 설명법 (3요소)

VC에게 말하듯 가치 중심으로 설명
상대가 안심할 수 있게 위험/롤백/대응 전략 포함
상대 도메인을 사전 파악하고 대비책 제시

ex) 외국인 가입 시 시나리오까지 미리 준비한 구조

3. 🧠 기억을 돕는 시스템 설계

“도메인이 너무 많아 다 기억 못 해요” → 시스템 화로 해결

AI 검색 기반 문서화 시스템 도입

자연어로 탐색 가능하게 구성

문서 구조 설계 시 폴더 탐색 없이 접근 가능하게

🧩 기술 전파 전략 (전사 확산을 위한 6단계)

단계	설명
1. 입에 오르내리게 만들기	자주 언급되도록 기술 브랜딩
2. 기억에 남는 이름 붙이기	예: `b2b 네비게이션 통합 시스템` → `원네비`
3. 읽지 않아도 머리에 들어오게	한눈에 들어오는 가이드, 문서 요약 제공
4. 상대팀의 계획에 미리 들어가기	사전 설득 및 조율
5. 공통 로드맵 만들기	팀 간 공동의 일정과 비전 공유
6. 모범답안 적극 공유	성공 사례 확산, 코드 예시 공유

📌 정리: 기술을 조직에 안착시키는 법

기술적 완성도 ≠ 성공
*“쓰이게 만드는 기술”**이 진짜 실력
협업, 기준, 공감, 시스템화, 커뮤니케이션 역량까지 포함된 조직형 엔지니어로 성장해야 한다

누구나 작성하는 E2E 테스트를 향하여: 접근성에서 찾은 답

Piece of Cake: 토스의 E2E 테스트 자동화 도구

발표자 : 강민우(플랫폼 팀)

❗ 배경: 기존 E2E 테스트의 한계

테스트 코드 유지보수 실패
- 테스트 전용 코드가 과도하게 많았음
- API 목킹에 과도하게 의존
- 비개발자는 작성할 수 없었음

→ "테스트는 누구나 쉽게 작성할 수 있어야 한다"는 문제의식에서 시작

🎯 목표: 케이크처럼 쉽고, 똑똑한 테스트 작성

핵심 컨셉: 모델 기반 테스트 + 노코드 UI

비개발자도 쉽게 참여할 수 있는 테스트 자동화
복잡한 테스트 코드 작성 없이 시나리오 중심으로 테스트 정의

🔧 구조 및 구성

✅ 1. 모델 기반 테스트 흐름

상태 머신 정의
상태별 검증 함수 작성
이벤트 트리거 함수 작성
상태 전이 시나리오 자동 추론
JSON 기반 테스트 모델 생성
Cake 내부 실행 엔진이 이를 기반으로 테스트 수행

✅ 2. 노코드 테스트 작성 환경

Chrome Extension 제공 → Chrome DevTools Protocol 활용

가능 기능:

요소 인스펙트
요소 하이라이트
브라우저 상 유저 이벤트 실행
요소 기준 스크린샷

✅ 3. 접근성 기반 테스트 보조

접근성이 높은 요소는 자동 테스트 대상 등록
접근성 부족 시 경고 제공
CSS Selector 대신 의미 기반 선택 유도
테스트는 시나리오 녹화 방식으로 재사용 가능

🧪 실행 환경

현재 브라우저 or 외부 CI 환경 모두 지원
테스트는 독립된 흐름으로 실행 가능
성공/실패 리포트 수신 가능

⚙️ 개발 난이도 & 기술적 특징

Chrome DevTools Protocol (CDP)을 활용한 고도화
실제 구현 시 겪은 어려움:
- CDP 문서 부족
- 프로토콜 구조 추론 필요
사용한 주요 프로토콜:
- Runtime.callFunctionOn: 노드 위치 추출
- Page.captureScreenshot: 요소 기준 캡처
- Page.getLayoutMetrics: 디스플레이 배율 추적

🔧 CDP 명령을 고수준으로 추상화하기 위해 Puppeteer도 병행 사용

🌐 웹 접근성과의 접점

접근성 자동 로거 내장
- 올바르게 마크업된 요소의 이름/위치 자동 수집
테스트 뿐 아니라 자동 로그 시스템으로도 확장 중

📌 정리

항목	설명
🎯 목적	테스트를 누구나 쉽게, 접근성 중심으로
🛠 방식	모델 기반 + 노코드 UI + Chrome Extension
💡 특징	접근성 기반 자동 선택 / 시나리오 녹화 / CDP 프로토콜 활용
🌱 확장	접근성 자동 진단, 웹 로그 수집 도구로 확장 중

Piece of Cake은 단순한 테스트 도구를 넘어,