react

소프트웨어 3.0 시대를 맞이하며 (새 탭에서 열림)

소프트웨어 개발은 명시적 코딩(1.0)과 데이터 기반 학습(2.0)을 거쳐, 자연어 프롬프트가 프로그램이 되는 '소프트웨어 3.0' 시대로 진입하고 있습니다. 하지만 강력한 LLM 모델이라도 실질적인 업무를 수행하기 위해서는 모델의 능력을 제어하고 연결하는 '하네스(Harness)'라는 도구적 환경이 필수적이며, 이를 설계하는 데 있어 기존 소프트웨어 1.0의 계층형 아키텍처 원칙은 여전히 유효한 가이드가 됩니다. 결국 미래의 개발은 전통적인 설계 원칙을 유지하면서도, 에이전트가 인간과 소통하며 의사결정을 내리는 'Human-in-the-Loop(HITL)' 모델을 결합하는 방향으로 진화할 것입니다. **소프트웨어 3.0과 하네스의 필요성** - 안드레 카파시는 소프트웨어 3.0을 자연어로 된 프롬프트가 코드를 대신하는 시대로 정의하며, 이것이 이전 세대의 패러다임을 흡수할 것이라고 예측했습니다. - 하지만 LLM 단독으로는 코드베이스를 읽거나 데이터베이스에 접근하는 등의 실질적인 작업을 수행할 수 없다는 한계가 있습니다. - 이를 해결하기 위해 등장한 것이 '하네스(Harness)' 개념으로, 앤스로픽의 'Claude Code'처럼 모델이 도구(Skills)를 사용하고 외부와 통신하며 에이전트로 동작하게 만드는 실행 환경을 의미합니다. **계층형 아키텍처로 매핑한 에이전트 구조** - **슬래시 커맨드(Slash Command) = 컨트롤러(Controller):** `/review`, `/refactor`와 같은 명령어는 사용자 요청을 받아 적절한 워크플로우를 실행하는 서비스의 진입점 역할을 합니다. - **서브 에이전트(Sub-agent) = 서비스 계층(Service Layer):** 여러 기술(Skills)을 조합해 특정 비즈니스 로직을 완수하며, 독립적인 컨텍스트를 유지하는 단위입니다. - **기술(Skills) = 도메인 컴포넌트:** 단일 책임 원칙(SRP)에 따라 코드 리뷰, 테스트 생성 등 명확한 한 가지 기능만 수행하는 가장 작은 단위의 기능 모듈입니다. - **MCP(Model Context Protocol) = 인프라/어댑터:** 외부 API나 DB와의 연결을 추상화하여 내부 로직이 외부 시스템의 구현 상세를 몰라도 동작하게 돕습니다. - **CLAUDE.md = 프로젝트 헌장:** 기술 스택, 코딩 컨벤션 등 프로젝트의 변하지 않는 근간 원칙을 정의하며 시스템의 안정성을 보장합니다. **에이전트 설계에서 경계해야 할 안티패턴** - **God Sub-agent:** 하나의 서브 에이전트가 너무 많은 역할과 권한을 가지게 되면 관리 효율이 떨어지므로 적절한 분리가 필요합니다. - **기능 편애(Feature Envy):** 특정 기술이 자신의 역할 범위를 벗어나 다른 기술의 데이터나 프롬프트에 과도하게 의존하는 경우입니다. - **프롬프트 중복:** 동일한 프롬프트 내용이 여러 기술에 중복되어 포함될 경우 유지보수가 어려워지므로 공통화가 필요합니다. **에이전트만의 핵심 차별점: 질문하는 능력(HITL)** - 전통적인 소프트웨어는 예외 상황에서 미리 정의된 에러를 던지지만, 3.0 시대의 에이전트는 `UserAskQuestion` 기술을 통해 모호한 상황에서 사용자에게 직접 질문을 던질 수 있습니다. - 에이전트는 삭제나 배포처럼 되돌리기 어려운 작업, 혹은 여러 대안 중 선택이 필요한 고위험 상황에서 인간의 판단을 구하는 'Human-in-the-Loop' 구조를 가집니다. - 반면, 관습적으로 처리 가능한 일이나 안전한 반복 작업은 질문 없이 자율적으로 수행함으로써 효율성과 안정성 사이의 균형을 맞춥니다. 소프트웨어 3.0 시대에 적응하기 위해서는 모든 로직을 명시적으로 작성하려는 강박에서 벗어나야 합니다. 대신 계층 분리, 추상화, 단일 책임 원칙과 같은 전통적인 소프트웨어 공학의 정수를 에이전트 설계에 투영하여, LLM을 단순한 자동완성 도구가 아닌 신뢰할 수 있는 협력자로 구축하는 능력이 핵심 경쟁력이 될 것입니다.

엔터프라이즈 LLM 서비스 구축기 2: 에이전트 엔지니어링 (새 탭에서 열림)

엔터프라이즈 LLM 서비스를 구축함에 있어 복잡한 최신 기술을 무작정 도입하기보다, 서비스의 본질에 집중하여 불필요한 기술을 덜어내는 '소거법' 기반의 아키텍처를 설계했습니다. 실전 운영 결과, 파인 튜닝 대신 RAG를, 기계적 청킹 대신 '검색 후 자르기' 전략을, 그리고 복잡한 워크플로 대신 단순한 ReAct 구조를 채택함으로써 96.1%라는 높은 응답률과 시스템 안정성을 동시에 확보할 수 있었습니다. 이는 화려한 기술적 기교보다 제한된 비용과 속도 안에서 최적의 효율을 찾는 것이 실제 서비스 환경에서 더 효과적임을 입증합니다. ### 지식 주입 방식의 선택: 파인 튜닝 제외와 RAG 채택 * 파인 튜닝은 새로운 지식(Fact)을 주입하기보다 답변 스타일(Style)을 조정하는 데 훨씬 효율적이며, 지식 주입 정확도는 상대적으로 낮다는 연구 결과를 바탕으로 RAG를 주력 기술로 선정했습니다. * 제품 문서가 수시로 갱신되는 환경에서 파인 튜닝은 매번 데이터셋을 재구성하고 교차 검수해야 하는 막대한 유지보수 비용이 발생하지만, RAG는 원본 문서 업데이트만으로 즉각적인 대응이 가능합니다. * 실험 결과, 소규모 데이터셋을 통한 파인 튜닝은 모델이 이미 학습한 방대한 기존 지식의 벽을 넘지 못하고, 질문 형식이 조금만 바뀌어도 오답을 내놓는 한계를 보였습니다. ### 문맥 보존을 위한 전략: 청킹 없는 '검색 후 자르기' * 기존 RAG의 기계적 청킹(Pre-split)은 문맥 상실의 문제를 야기하므로, 각 문서의 주제가 명확하고 분량이 적은 서비스 특성을 고려해 문서를 통째로 임베딩하는 역발상을 적용했습니다. * 사용자 질문이 들어오면 관련 문서를 통째로 찾은 뒤, 마크다운 헤더(##) 기준으로 분할하고 경량 LLM 필터를 통해 질문과 관련 있는 섹션만 정밀하게 추출하는 '검색 후 자르기(Post-split)' 프로세스를 구축했습니다. * 이 방식은 질문의 맥락을 이미 알고 있는 상태에서 문서를 자르기 때문에, 정보의 희석 없이 모델에게 가장 필요한 핵심 조각들만 선별하여 전달할 수 있다는 장점이 있습니다. ### 효율적인 행동 구조: 복잡한 워크플로 대신 ReAct 방식 * '계획 후 실행(Plan-and-execute)'이나 '멀티 에이전트' 구조는 시스템 복잡도와 응답 지연(Latency)을 높일 뿐, 실제 답변 품질에서의 체감 성능 향상은 크지 않았습니다. * 특히 멀티 에이전트 구조는 전문가 간의 질문 배분 과정에서 추가적인 LLM 호출 비용이 발생하고, 여러 도메인이 섞인 질문에서 정보가 누락되는 취약점을 보였습니다. * 정제된 컨텍스트와 적절한 도구가 주어진다면 모델 스스로 추론하고 행동하는 ReAct 루틴만으로도 복잡한 논리적 순서를 충분히 구현할 수 있음을 확인하여, 시스템을 단순하게 유지했습니다. 성공적인 AI 에이전트 구축의 핵심은 유행하는 기술을 좇는 '덧셈'이 아니라, 서비스의 본질에 맞는 기술만 남기는 '뺄셈'에 있습니다. 현재 발생하는 답변 실패 원인의 절반 이상이 기술적 결함이 아닌 '참조 문서의 부재'에서 기인한다는 점을 고려할 때, 모델 아키텍처를 복잡하게 만들기보다는 AI가 학습하고 참조할 '교과서(원본 문서)'의 품질을 높이는 것이 성능 향상을 위한 가장 확실하고 실용적인 투자입니다.

AI로 일주일 만에 Next. (새 탭에서 열림)

Cloudflare의 한 엔지니어가 AI 모델을 활용해 단 일주일 만에 Next.js를 Vite 기반으로 재구현한 'vinext'를 공개했습니다. vinext는 Next.js의 복잡한 빌드 아키텍처와 타 플랫폼 배포 시 발생하는 파편화 문제를 해결하기 위해 등장했으며, 기존 Next.js 코드를 그대로 유지하면서도 최대 4배 빠른 빌드 속도와 57%의 번들 크기 감소를 달성했습니다. 이는 AI를 활용해 기존 프레임워크의 API 표면을 완전히 새롭게 구현함으로써 서버리스 환경에서의 배포 효율성을 극대화한 사례입니다. ### 기존 Next.js 배포 및 개발 환경의 문제점 * Next.js는 Turbopack이라는 독자적인 툴체인을 사용하기 때문에, Cloudflare나 AWS Lambda 같은 서버리스 환경에 배포하려면 빌드 결과물을 해당 플랫폼에 맞게 재가공하는 복잡한 과정이 필요합니다. * 기존의 해결책인 OpenNext는 Next.js의 빌드 결과물을 역공학(Reverse-engineering)하여 대응해왔으나, 프레임워크 버전 업데이트 시 구조가 변경되면 대응이 늦어지거나 기능이 깨지는 등 취약한 구조를 가집니다. * 로컬 개발 환경은 Node.js에서 실행되는 반면 실제 배포는 에지 런타임에서 이루어지는 불일치 문제로 인해, Durable Objects나 AI 바인딩 같은 플랫폼 전용 API를 개발 단계에서 테스트하기가 매우 어렵습니다. ### Vite 기반의 완전한 재구현, vinext * vinext는 Next.js의 출력물을 수정하는 방식이 아니라, Vite 위에서 Next.js의 API 표면(라우팅, SSR, RSC, Server Actions, 미들웨어 등)을 처음부터 다시 구현한 클린 구현체입니다. * 사용자는 기존의 `app/`, `pages/` 디렉토리와 `next.config.js`를 그대로 사용할 수 있으며, 스크립트에서 `next`를 `vinext`로 바꾸는 것만으로 즉시 교체가 가능한 'Drop-in replacement' 형태를 지향합니다. * Vite의 환경 API(Environment API)를 활용하여 특정 플랫폼에 종속되지 않는 빌드 결과물을 생성하며, 향후 Rust 기반 번들러인 Rolldown이 도입되면 더 높은 성능 향상이 기대됩니다. ### 성능 지표 및 Cloudflare 최적화 기능 * 33개의 라우트를 포함한 앱 기준 벤치마크 결과, Next.js 16 대비 빌드 시간은 약 4배 단축되었고 클라이언트 번들 크기(Gzip 기준)는 57% 감소하는 성과를 보였습니다. * `vinext deploy` 명령어를 통해 소스 코드에서 Cloudflare Workers로 즉시 배포가 가능하며, Cloudflare KV를 활용한 캐시 핸들러를 통해 ISR(Incremental Static Regeneration) 기능을 기본적으로 제공합니다. * 개발 단계부터 실제 배포 환경과 동일한 `workerd` 런타임에서 앱이 구동되므로, 플랫폼 전용 기능을 별도의 워크아라운드 없이 로컬에서 완벽하게 테스트할 수 있습니다. ### 생태계 협력 및 향후 전망 * vinext 코드의 약 95%는 순수 Vite 기반으로 작성되어 있어 특정 호스팅 업체에 종속되지 않으며, Vercel을 포함한 타 플랫폼으로의 이식도 매우 용이한 구조입니다. * 현재 이 프로젝트는 실험적인 단계(Experimental)로 대규모 트래픽에서의 검증이 더 필요하지만, 이미 1,700개 이상의 테스트를 통과하며 안정성을 확보해 나가고 있습니다. * Cloudflare는 타 호스팅 제공업체들과 협력하여 이 툴체인을 확장할 계획이며, 오픈 소스 커뮤니티의 참여를 통해 다양한 배포 타겟을 확보하고자 합니다. **결론:** vinext는 현대적인 빌드 도구와 AI의 결합이 프레임워크의 구조적 한계를 얼마나 빠르게 극복할 수 있는지 보여주는 사례입니다. 성능 최적화와 서버리스 배포 편의성을 동시에 잡고자 하는 개발자들에게 유망한 대안이 될 것으로 보입니다.

Spotify 앱을 출시하는 방법: 내부 (새 탭에서 열림)

스포티파이는 Jira 중심의 복잡하고 분절된 릴리스 관리 프로세스를 개선하기 위해 자체 개발 포털인 Backstage 기반의 '릴리스 매니저 대시보드(Release Manager Dashboard)'를 구축했습니다. 이 도구는 10개 이상의 시스템에서 데이터를 통합하여 릴리스 매니저의 인지 부하를 줄이고, 안드로이드, iOS, 데스크톱 등 각 플랫폼의 릴리스 상태를 한눈에 파악할 수 있게 합니다. 결과적으로 스포티파이는 데이터 중심의 빠른 의사결정 체계를 갖추게 되었으며, 릴리스 과정에서 발생할 수 있는 휴먼 에러를 최소화했습니다. ### Jira 중심 프로세스의 한계와 새로운 도구의 탄생 * 기존에는 모든 릴리스 정보가 Jira 티켓에 흩어져 있어, 릴리스 매니저가 수많은 탭을 오가며 상태를 확인해야 하는 컨텍스트 스위칭 문제가 심각했습니다. * 새로운 대시보드는 컨텍스트 스위칭 최소화, 인지 부하 감소, 빠르고 정확한 의사결정 지원을 목표로 설계되었습니다. * 이를 통해 모바일 릴리스 프로세스에 대한 기본 지식만 있다면 누구나 직관적으로 상황을 이해할 수 있는 환경을 조성했습니다. ### 통합된 데이터와 트랙 중심의 관리 * 플랫폼(Android, iOS, Desktop)과 버전의 조합을 '트랙(Track)'으로 정의하고, 각 트랙을 독립적이면서도 통합적으로 관리합니다. * **트랙별 필수 데이터:** 릴리스 상태(State), 릴리스 차단 버그(Blocking Bugs), 회귀 테스트 통과 여부(Sign-off), 최신 릴리스 후보(RC) 빌드 및 앱스토어 업로드 상태 등을 포함합니다. * **품질 및 사용량 지표:** Crash 발생률, ANR(응답 없는 앱), 곡당 CPU 예외 사항, DAU(일일 활성 사용자 수) 등 실시간 품질 지표를 함께 모니터링합니다. * **미할당 버그 관리:** 특정 버전에 할당되지 않았거나 우선순위가 없는 버그들을 별도로 표시하여, 릴리스를 방해할 수 있는 잠재적 요소를 사전에 분류하고 담당 팀을 지정합니다. ### Backstage 기반의 에코시스템과 직관적인 UI * 스포티파이의 내부 개발자 포털인 Backstage의 플러그인(React, TypeScript 기반)으로 개발되어 기존 개발 도구들과의 UI/데이터 일관성을 유지합니다. * **신호등 시스템:** 상태를 초록색(준비 완료), 노란색(대기/경고), 빨간색(오류/즉각 조치 필요)으로 시각화하여 즉각적인 상황 판단을 돕습니다. * 상세 정보가 필요한 경우 클릭 한 번으로 앱 빌드나 크래시 상세 리포트 등 관련 플러그인으로 바로 연결되는 드릴다운(Drill-down) 구조를 갖췄습니다. ### 백엔드 아키텍처 및 성능 최적화 * 약 10개의 기존 시스템으로부터 데이터를 수집하고 통합하는 API 게이트웨이 역할을 수행하는 백엔드 서비스를 구축했습니다. * 초기 버전은 매번 대규모 쿼리를 실행하여 속도가 느리고 비용이 높았으나, 5분 단위의 데이터 사전 집계(Pre-aggregation)와 캐싱 기술을 도입해 최적화했습니다. * 이를 통해 대시보드 로딩 시간을 8초로 단축하고, 운영 비용을 획기적으로 낮추면서도 높은 신뢰성을 확보했습니다. ### 단계별 릴리스 모니터링 상세 * **Production(운영):** 이미 배포된 버전의 크래시 지표와 지난 24시간 동안의 DAU 추이를 모니터링하여 배포 후 예기치 못한 문제를 감시합니다. * **Current(현재):** 배포 대기 중인 버전의 상태를 집중 관리합니다. ITGC(IT 일반 통제) 테스트 통과 여부와 데이터 손실 임계치 준수 여부 등을 확인하여 최종 배포 가능 여부를 결정합니다. * **Upcoming(차기):** 다음 릴리스 버전을 미리 준비하며, 해당 단계에서 불필요한 섹션은 비활성화하여 현재 집중해야 할 정보와 구분합니다. 복잡한 마이크로서비스 환경이나 멀티 플랫폼 앱을 운영하는 조직이라면, 흩어진 릴리스 데이터를 하나로 모으는 전용 대시보드 구축이 필수적입니다. 특히 Backstage와 같은 내부 개발 포털을 활용해 도구 간 데이터 일관성을 확보하고 시각적인 상태 지표(초록/노랑/빨강)를 도입하면, 릴리스 관리의 효율성을 극대화하고 배포 안정성을 크게 높일 수 있습니다.

Cloudflare 플랫폼에서 수직적 마 (새 탭에서 열림)

Cloudflare는 단일 도메인 내에서 여러 독립적인 Cloudflare Workers를 특정 URL 경로에 매핑하여 팀별로 자율성을 보장하는 '버전별 마이크로프론트엔드(VMFE)' 템플릿을 발표했습니다. 이 방식은 기존의 수평적 마이크로프론트엔드와 달리 경로별로 전체 기술 스택을 분리함으로써, 팀이 프레임워크 선택부터 배포 파이프라인까지 독립적으로 제어할 수 있게 합니다. 결과적으로 사용자에게는 하나의 매끄러운 서비스로 보이지만, 내부적으로는 여러 팀이 서로의 간섭 없이 독립적으로 기능을 개발하고 배포할 수 있는 환경을 제공합니다. ### 수직적 마이크로프론트엔드(VMFE)의 정의와 이점 * **경로 기반의 독립성**: `/blog`, `/docs`, `/dash`와 같은 URL 경로별로 개별 Worker를 할당하며, 각 경로는 프레임워크, 라이브러리, CI/CD 파이프라인을 포함한 전체 스택을 독립적으로 소유합니다. * **기술 선택의 유연성**: 마케팅 페이지에는 Astro를 사용하고 대시보드에는 React를 사용하는 등, 서비스의 특성에 가장 적합한 도구를 팀별로 자유롭게 선택할 수 있습니다. * **배포 리스크 감소**: 모놀리식 구조에서 발생하던 '한 팀의 오류로 인한 전체 배포 중단' 문제를 해결하며, 특정 기능의 업데이트나 롤백이 다른 서비스에 영향을 주지 않습니다. ### URL 기반의 정교한 라우팅 구조 * **세분화된 관리**: 단순한 최상위 경로뿐만 아니라 `/dash/product-a`와 `/dash/product-b`처럼 세부 경로별로 다른 Worker를 매핑하여 대규모 애플리케이션 내의 개별 제품군을 독립적으로 관리할 수 있습니다. * **코드 공유 제로**: 각 경로는 서로 코드를 공유하지 않는 완전히 독립된 프로젝트로 운영되어 프로젝트 간의 의존성을 완벽히 차단합니다. * **실제 적용 사례**: Cloudflare는 이미 자사 대시보드에 이 전략을 적용하고 있으며, 사용자가 대시보드에서 ZeroTrust 제품으로 이동할 때 실제로는 별개의 프로젝트로 라우팅되도록 구현했습니다. ### 사용자 경험을 통합하는 기술적 전략 * **CSS View Transitions**: 서로 다른 Worker 간의 이동 시 발생하는 브라우저의 흰색 공백(interstitial loading state)을 방지하고, 내비게이션 바와 같은 공통 요소를 화면에 유지시켜 SPA(Single Page Application)와 같은 부드러운 전환 효과를 제공합니다. * **Speculation Rules API**: 사용자가 다음에 방문할 가능성이 높은 경로를 브라우저가 미리 사전 페치(prefetch)하거나 사전 렌더링하도록 설정하여, 멀티 페이지 아키텍처임에도 불구하고 즉각적인 페이지 로딩 속도를 구현합니다. * **시각적 일관성**: CSS의 `view-transition-name` 등을 활용하여 기술적인 구현 세부 사항(여러 개의 Worker 사용)을 사용자에게 노출하지 않고 단일한 애플리케이션 경험을 유지합니다. 독립적인 개발 속도와 일관된 사용자 경험이라는 두 마리 토끼를 잡고 싶은 성장하는 조직에게 이 VMFE 아키텍처는 매우 강력한 솔루션입니다. Cloudflare가 제공하는 새로운 Worker 템플릿과 최신 브라우저 API(View Transitions, Speculation Rules)를 결합하면, 기술적 복잡성을 관리하면서도 고성능의 웹 애플리케이션을 구축할 수 있습니다.

플로우 이해하기: 멀티 (새 탭에서 열림)

GitLab Duo Agent Platform의 '플로우(Flows)'는 여러 전문 AI 에이전트가 협업하여 복잡한 개발 과업을 자율적으로 수행하는 멀티 에이전트 워크플로우 시스템입니다. 사용자와 대화하며 협력하는 개별 에이전트와 달리, 플로우는 특정 이벤트에 의해 트리거되어 백그라운드에서 분석부터 실제 구현 및 결과 도출까지 엔드 투 엔드(end-to-end) 작업을 독립적으로 처리합니다. 이를 통해 개발자는 반복적인 파이프라인 관리나 단순 구현 업무에서 벗어나 보다 고차원적인 설계에 집중할 수 있는 자율형 자동화 환경을 구축할 수 있습니다. ### 에이전트와 플로우의 차이 및 주요 특징 * **자율성:** 에이전트가 사용자와 상호작용하며 실시간으로 도움을 준다면, 플로우는 사용자를 대신해 독립적으로 워크플로우를 완수하는 데 초점을 맞춥니다. * **플랫폼 통합:** 별도의 외부 인프라 구축 없이 GitLab 플랫폼의 컴퓨팅 자원에서 직접 실행되는 내장형 시스템입니다. * **비동기 및 이벤트 기반:** 멘션(@), 담당자 할당, 리뷰어 지정 등의 이벤트로 트리거되며, 작업이 진행되는 동안 개발자는 다른 업무를 중단 없이 수행할 수 있습니다. * **기본 및 커스텀 옵션:** GitLab이 직접 관리하는 생산 준비 완료 단계의 '기본 플로우'와 팀의 특정 요구에 맞춰 구성하는 '커스텀 플로우'를 모두 지원합니다. ### 커스텀 플로우의 활용과 트리거 방식 * **팀 맞춤형 자동화:** 조직 고유의 보안 정책 검토, 특정 기술 스택에 맞춘 코드 리뷰, API 문서 자동 생성 등 범용 AI가 해결하기 어려운 구체적인 워크플로우를 자동화할 수 있습니다. * **다양한 실행 경로:** 이슈나 머지 리퀘스트(MR)에서 `@flow-name`으로 멘션하거나, `/assign @flow-name` 명령어를 통해 담당자 또는 리뷰어로 지정하는 즉시 실행됩니다. * **실제 활용 사례:** 핀테크 기업의 경우 컴플라이언스 플로우를 구축하여, 모든 MR에 대해 PCI-DSS 위반 여부를 스캔하고 보안 코딩 표준 준수 여부를 확인한 뒤 자동으로 보고서를 게시하도록 설정할 수 있습니다. ### YAML 기반의 플로우 설계 및 구성 요소 * **구조적 정의:** 플로우는 YAML 구성을 통해 정의되며 구성 요소(Components), 프롬프트(Prompts), 라우터(Routers), 도구 모음(Toolsets)으로 이루어집니다. * **에이전트 컴포넌트:** 워크플로우의 각 단계를 담당할 에이전트의 유형과 동작 방식을 정의하며, 특정 AI 모델의 행동 지침을 프롬프트 ID로 연결합니다. * **강력한 도구 연결:** `get_issue`, `create_commit`, `create_merge_request`와 같은 GitLab API 도구를 에이전트에게 부여하여 실제로 코드를 수정하고 저장소에 반영할 수 있는 권한을 제공합니다. * **전문성 주입:** 프롬프트 템플릿 내에 도메인 지식(예: 여행 예약 시스템의 특수성)과 코드 표준을 명시하여 AI가 조직의 맥락에 맞는 최적의 결과물을 내놓도록 정교하게 제어합니다. 단순한 코드 생성을 넘어 복잡한 프로세스의 완전 자동화를 목표로 한다면, 팀 내에서 가장 반복적으로 발생하는 작업부터 커스텀 플로우로 전환해 보길 권장합니다. 처음에는 GitLab에서 제공하는 기본 플로우로 기능을 탐색한 뒤, 점진적으로 팀의 정책이 반영된 YAML 정의 플로우를 확장해 나가는 것이 생산성 향상에 가장 효과적입니다.

디자인 시스템 다시 생각해보기 (새 탭에서 열림)

디자인 시스템은 성장에 따라 경직되기 마련이며, 시스템이 제품 팀의 변화하는 요구사항을 제때 수용하지 못할 경우 팀은 시스템을 우회하거나 파편화된 코드를 생성하게 됩니다. 토스의 디자인 시스템(TDS)은 디자인 시스템을 통제 수단이 아닌 '하나의 제품'으로 정의하고, 수요자의 니즈에 따라 유연하게 대응할 수 있는 설계 구조를 지향합니다. 이를 위해 단순함과 유연함을 동시에 잡을 수 있는 하이브리드 API 전략을 도입하여 일관성과 생산성을 모두 확보하는 해결책을 제시합니다. ### 시스템의 경직성과 파편화 문제 * 조직이 커지고 제품이 다양해지면 기존 시스템의 제약 내에서 해결할 수 없는 UI 요구사항이 빈번하게 발생합니다. * 제품 팀은 빠른 해결을 위해 피그마 컴포넌트를 해제(detach)하거나 라이브러리 코드를 복제(fork)하여 로컬에서 수정해 사용하게 됩니다. * 이러한 우회 방식은 시스템 업데이트와의 연결을 끊어버려 UI 불일치를 초래하고, 장기적으로 디자인 시스템의 핵심 가치를 무너뜨립니다. * 결국 디자인 시스템이 팀의 속도를 늦추는 장애물이 되지 않으려면, 강력한 규칙보다 '우회할 이유를 줄이는 유연한 설계'가 필요합니다. ### 확장성을 고려한 컴포넌트 API 패턴 비교 * **Flat 패턴**: 내부 구조를 숨기고 모든 변형을 props로 처리하는 방식입니다. 사용이 직관적이고 간결하지만, 예외적인 요구사항이 늘어날수록 props가 기하급수적으로 증가하여 유지보수가 어려워집니다. * **Compound 패턴**: 하위 컴포넌트(Header, Body, Footer 등)를 제공하여 사용자가 직접 조합하는 방식입니다. 시스템이 예측하지 못한 레이아웃도 유연하게 구현할 수 있으나, 코드량이 늘어나고 구조에 대한 학습 비용이 발생한다는 단점이 있습니다. * 두 패턴은 상충하는 장단점을 가지고 있으므로, 단순히 하나의 패턴을 강요하는 것은 사용자의 이탈을 막기에 부족합니다. ### TDS의 하이브리드 전략과 Primitive 레이어 * TDS는 단순하고 빈번한 케이스를 위한 **Flat API**와 복잡한 커스텀을 위한 **Compound API**를 동시에 제공합니다. * 사용자는 별도의 커스텀이 필요 없을 때는 간결한 Flat 형식을 선택하고, 세밀한 제어가 필요할 때는 Compound 형식을 선택하여 시스템 내부에서 문제를 해결할 수 있습니다. * 디자인 시스템 팀은 관리 효율을 위해 **Primitive(기초 단위)** 레이어를 먼저 구축합니다. * 내부적으로는 동일한 Primitive 컴포넌트를 공유하면서 외부로 드러나는 API만 두 가지 형태로 노출함으로써, 유지보수 부담을 최소화하면서도 사용자 경험을 극대화합니다. 디자인 시스템은 팀을 가두는 울타리가 아니라 안전하게 안내하는 가드레일이 되어야 합니다. 중앙에서 모든 것을 통제하려 하기보다, 규칙에서 벗어난 예외 상황까지 시스템 안에서 지원할 수 있는 유연한 설계를 갖출 때 진정한 일관성을 유지할 수 있습니다.

세금 환급 자동화 : AI-driven UI 테스트 자동화 일지 (새 탭에서 열림)

토스인컴의 복잡한 세금 환급 서비스 QA를 위해 1명의 매니저가 AI를 팀원으로 활용하여 4~5명 규모의 자동화 성과를 낸 과정을 다룹니다. AI 에이전트에게 코드 작성과 설계를 맡기고 사람은 문제 정의와 검증에 집중함으로써, 5개월 만에 35개의 고난도 E2E 테스트 시나리오를 성공적으로 구축하고 운영화했습니다. 이 실험은 기술적 난도가 높은 환경에서도 AI와의 협업을 통해 자동화 효율을 극대화할 수 있음을 입증했습니다. **AI 자동화 도입 배경과 도구 구성** * 복잡한 환급 플로우(15~20단계)와 빈번한 UI/정책 변경, 외부 연동 시스템의 불안정성 때문에 전통적인 수동 자동화 방식으로는 대응이 불가능했습니다. * 메인 개발자인 Claude Sonnet 4.5를 비롯해 Cursor(IDE 페어 프로그래밍), Codex(코드 분석) 등 각기 다른 강점을 가진 AI 도구들을 조합하여 사용했습니다. * AI를 SDET 에이전트(설계), 문서화 전문가(기록), Git 마스터(형상 관리)라는 세 가지 페르소나로 분리하여 역할 분담을 명확히 했습니다. **기술적 문제 해결과 아키텍처 고도화** * **Page Object Model(POM) 도입:** 중복 셀렉터 문제를 해결하고 유지보수성을 높이기 위해 AI와 협업하여 모든 페이지 요소를 객체화하는 POM 구조를 설계했습니다. * **React 타이밍 이슈 해결:** 요소가 화면에는 보이지만 이벤트 핸들러가 바인딩되지 않아 발생하는 클릭 실패를 해결하기 위해, UI 안정화와 상호작용 준비 상태를 분리해 감지하는 'Interaction Readiness' 전략을 구현했습니다. * **Fallback 클릭 로직:** 표준 클릭 실패 시 키보드 엔터 입력, 자바스크립트 직접 클릭 순으로 시도하는 안전한 클릭 함수를 만들어 테스트의 견고함을 높였습니다. * **동적 약관 처리:** 서비스별로 상이하고 복잡한 약관 동의 플로우를 AI가 자동으로 감지하고 처리하도록 설계하여, 약관이 변경되어도 테스트가 중단되지 않는 구조를 만들었습니다. **운영 효율화를 위한 협업 시스템 구축** * **문서화 및 일지 자동 생성:** 매일 커밋 기록을 기반으로 AI가 회고 일지와 가이드 문서를 작성하게 하여, 수십 분이 걸리던 기록 업무를 1~2분 내외의 검토 수준으로 단축했습니다. * **메신저 기반 리포팅 루프:** 테스트 결과, 실패 지점 스크린샷, 오류 로그(EventID 등)를 사내 메신저에 자동으로 연동하여 개발팀과의 빠른 논의가 가능하도록 환경을 조성했습니다. * **테스트 격리 및 리팩토링:** 수천 줄의 단일 파일을 분리하고 테스트 데이터(userNo) 충돌 방지 로직을 도입하여 자동화 품질을 관리 가능한 수준으로 끌어올렸습니다. 단순히 AI에게 코드를 짜게 하는 수준을 넘어, 아키텍처 설계와 운영 프로세스 전반을 AI와 함께 고민하는 'AI-First' 접근 방식은 리소스가 제한된 환경에서 QA 품질을 혁신적으로 높일 수 있는 실질적인 해법이 됩니다. 6개월간의 여정은 AI를 도구가 아닌 실제 팀원으로 대우할 때 자동화의 본질인 '안정적인 반복 실행'을 달성할 수 있음을 보여줍니다.

코드 레이어로 사이트를 인터랙티브 (새 탭에서 열림)

피그마(Figma)는 디자인 환경 내에서 커스텀 리액트(React) 코드를 활용해 역동적인 상호작용을 구현할 수 있는 ‘코드 레이어(Code Layers)’ 기능을 출시했습니다. 이 기능을 통해 디자이너는 복잡한 개발 지식 없이도 AI 채팅이나 직접적인 코드 수정을 통해 정적인 디자인을 실제 작동하는 웹 요소로 변환하고 실험할 수 있습니다. 결과적으로 디자인과 실제 제품 구현 사이의 장벽을 허물어, 별도의 개발 전달 과정 없이도 고도화된 애니메이션이나 기능적 컴포넌트를 피그마 사이츠(Figma Sites)에서 즉시 빌드할 수 있게 되었습니다. **코드 레이어를 활용한 인터랙션 구현** * 코드 레이어는 리액트 코드를 기반으로 구동되는 상호작용 요소로, 피그마 사이츠 내에서 기존 컴포넌트를 코드로 변환하거나 새롭게 생성할 수 있습니다. * 피그마 메이크(Figma Make)의 AI 기술을 활용하여 "꽃 이미지를 무한히 복제해서 드래그할 수 있게 해줘"와 같은 자연어 프롬프트만으로 복잡한 로직을 생성합니다. * 캔버스 위에서 바로 코드 레이어를 복제(Cmd + D)하여 여러 버전의 상호작용을 나란히 비교하고 실험하는 유연한 워크플로우를 제공합니다. **기존 디자인의 동적 변환 및 제작 방식** * 작업 중인 요소에 애니메이션(회전, 바운스 등)을 추가하거나, 마우스 호버 시 색상이 변하는 리플 효과 등 정적 이미지에 생명력을 불어넣을 수 있습니다. * 대출 계산기, 가격 추정기, 실시간 통계 카운터와 같이 단순한 프로토타입을 넘어 실제 로직이 작동하는 유틸리티 컴포넌트를 제작할 수 있습니다. * 단축키(E)를 사용하여 캔버스에 즉석에서 코드 레이어를 그려 넣고, AI에게 이모지 파티클 생성이나 이미지 갤러리 구축 등을 요청하여 빠르게 아이디어를 시각화합니다. **개발자 수준의 확장성과 재사용성** * **커스텀 속성 편집:** AI가 코드 기반의 속성(문자열, 숫자 등)을 자동으로 생성하며, 사용자는 코드 수정 없이도 패널에서 직접 값을 조정해 레이어의 동작을 변경할 수 있습니다. * **컴포넌트화:** 일반적인 피그마 프레임처럼 코드 레이어도 재사용 가능한 컴포넌트로 전환하여 여러 페이지나 팀 프로젝트에 공유할 수 있습니다. * **npm 패키지 지원:** `motion`이나 `@react-three/fiber`와 같은 외부 노드 패키지 매니저(npm) 라이브러리를 임포트하여 고난도의 3D 렌더링이나 정교한 모션 그래픽을 구현할 수 있습니다. 웹 디자인의 한계를 넓히고자 하는 디자이너라면 피그마 사이츠에서 제공되는 코드 레이어를 적극적으로 활용해 보시기 바랍니다. 특히 AI 프롬프트를 통해 기초 코드를 생성한 뒤, npm 패키지를 결합해 시중의 템플릿으로는 불가능했던 독창적인 사용자 경험을 직접 구축해 보는 것을 추천합니다.

강력해진 디스 (새 탭에서 열림)

디스코드는 개발 생산성을 높이고 여러 플랫폼에 신속하게 기능을 배포하기 위해 데스크톱은 React, 모바일은 React Native를 기반으로 클라이언트를 구축해 운영하고 있습니다. 특히 2022년에는 하드웨어의 발전과 새로운 자바스크립트 엔진인 Hermes의 도입을 계기로 안드로이드 앱까지 React Native로 전환하는 큰 변화를 시도했습니다. 현재는 저사양 기기의 구동 속도를 절반으로 단축하는 등 성능 최적화에 집중하며, 앱의 기능을 한계까지 사용하는 파워 유저들에게 최상의 경험을 제공하는 것을 목표로 하고 있습니다. **안드로이드 React Native 전환 배경과 Hermes 엔진** * 과거에는 성능 문제로 안드로이드에서 React Native 도입을 주저했으나, 안드로이드 기기 성능의 향상과 React Native 전용 자바스크립트 엔진인 'Hermes'의 등장으로 전환의 기술적 기반이 마련되었습니다. * 2022년 안드로이드 클라이언트를 React Native로 전환함으로써, 단일 코드베이스의 이점을 살려 모든 플랫폼에서 일관되고 빠른 기능 업데이트가 가능해졌습니다. **성능 트레이드오프와 초기 구동 시간 개선** * 플랫폼 전환 과정에서 저사양 기기의 초기 구동 시간(Startup time)이 늘어나는 성능상의 손실이 발생했습니다. * 디스코드 팀은 이를 해결하기 위해 2023년 한 해 동안 집중적인 최적화를 진행했으며, 결과적으로 초기 구동 시간의 중앙값을 기존 대비 절반 수준으로 줄이는 성과를 거두었습니다. **파워 유저를 위한 지속적인 최적화** * React Native는 네이티브 개발에 비해 성능 오차 범위가 좁기 때문에, 디스코드는 사용 빈도가 가장 높은 기능들을 중심으로 세밀한 성능 개선을 이어가고 있습니다. * 특히 앱의 기능을 극한으로 활용하는 파워 유저들이 불편함을 느끼지 않도록 리소스를 많이 소모하는 작업들에 대한 최적화 작업에 박차를 가하고 있습니다. 디스코드의 사례는 대규모 서비스가 개발 효율성을 위해 크로스 플랫폼 프레임워크를 채택할 때, 성능 문제를 어떻게 기술적으로 극복하고 사용자 경험을 유지하는지 잘 보여줍니다. 특히 Hermes 엔진과 같은 최신 기술을 적극 도입하여 안드로이드 환경의 제약을 해결한 점은 모바일 개발 팀이 참고할 만한 중요한 전략입니다.

피그마 내부 이야기: 엄 (새 탭에서 열림)

Figma는 복잡한 협업 환경에서 수많은 댓글을 60fps의 부드러운 속도로 렌더링하기 위해 React의 기본 성능 한계를 극복한 과정을 공유합니다. 단순히 컴포넌트를 최적화하는 수준을 넘어, 브라우저의 레이아웃 계산 방식을 이해하고 불필요한 리렌더링을 원천 차단하는 아키텍처적 변화를 시도했습니다. 그 결과, 수천 개의 댓글이 있는 파일에서도 끊김 없는 사용자 경험을 제공할 수 있게 되었습니다. ### 대규모 댓글 목록의 성능 병목 현상 * 수천 개의 댓글이 존재할 때 React가 모든 요소를 DOM에 유지하면 메모리 사용량과 렌더링 시간이 기하급수적으로 증가하는 문제가 발생했습니다. * 사용자가 스크롤할 때마다 발생하는 상태 업데이트가 전체 컴포넌트 트리를 재평가하게 만들어, 브라우저가 초당 60프레임을 유지하지 못하고 화면이 버벅이는 현상이 나타났습니다. * 특히 각 댓글의 내용에 따라 높이가 가변적인 특성 때문에, 브라우저가 레이아웃을 다시 계산(Reflow)하는 과정에서 막대한 CPU 자원을 소모했습니다. ### 가상 리스트(Windowing)와 동적 높이 관리 * 화면에 현재 보이는 부분만 렌더링하는 가상화(Windowing) 기법을 적용하여 실제 DOM 노드 수를 수천 개에서 수십 개 수준으로 압축했습니다. * 댓글마다 높이가 다른 문제를 해결하기 위해, 렌더링 전에 각 요소의 높이를 측정하고 이를 캐싱하는 메커니즘을 구현하여 스크롤 위치를 정확하게 계산했습니다. * 사용자가 빠르게 스크롤할 때 빈 화면이 보이지 않도록 '오버스캔(Overscan)' 영역을 설정하여 위아래로 여분의 컴포넌트를 미리 렌더링했습니다. ### React 상태 관리의 탈중앙화와 구독 모델 * React의 전형적인 단방향 데이터 흐름은 상위 컴포넌트의 상태 변경 시 하위 트리 전체를 리렌더링하므로, 대규모 목록에서는 부적합하다고 판단했습니다. * 이를 해결하기 위해 각 댓글 컴포넌트가 중앙 스토어를 직접 구독(Subscription)하게 하여, 특정 댓글이 수정될 때 해당 컴포넌트만 정밀하게 업데이트되도록 설계했습니다. * 이러한 '밀어내기(Push)' 방식의 업데이트를 통해 불필요한 VDOM 비교(Reconciliation) 과정을 생략하고 CPU 부하를 획기적으로 줄였습니다. ### 브라우저 렌더링 엔진 최적화 * CSS의 `contain` 속성(예: `contain: layout`)을 활용하여 특정 댓글의 변화가 전체 페이지의 레이아웃에 영향을 주지 않도록 브라우저에게 명시적인 힌트를 제공했습니다. * `requestIdleCallback` API를 도입하여 사용자 상호작용에 즉각 필요하지 않은 비핵심 작업들은 브라우저의 유휴 시간에 처리되도록 스케줄링했습니다. * 마우스 오버 효과와 같은 고빈도 인터랙션은 React 상태를 거치지 않고 CSS 클래스 조작이나 직접적인 DOM 접근을 통해 처리하여 즉각적인 반응성을 확보했습니다. 대규모 웹 애플리케이션에서 극도로 매끄러운 성능을 달성하려면 React의 추상화 계층에만 의존하지 말고 브라우저의 실제 렌더링 메커니즘을 깊게 제어해야 합니다. 초기 개발 단계에서는 생산성을 위해 표준 React 패턴을 따르되, 성능 임계점에 도달한 복잡한 UI에서는 가상화, 상태 구독 모델, 레이아웃 격리 등의 로우레벨 최적화 기법을 도입하는 것을 권장합니다.

60fps의 React: Figma (새 탭에서 열림)

Figma가 발표한 **'Figma to React'**와 관련된 기술적 변화와 주요 기능을 요약한 내용입니다. Figma는 디자인과 엔지니어링 사이의 장벽을 허물기 위해 디자인 구성 요소를 React 코드로 직접 변환하는 기능을 강화했습니다. 이 도구는 디자이너가 의도한 시각적 요소를 개발자가 수동으로 재구현하는 번거로움을 줄이고, 디자인 시스템과 실제 코드 간의 일관성을 보장하는 데 목적을 둡니다. 결론적으로, Figma는 단순한 디자인 도구를 넘어 개발 생산성을 극대화하고 제품 출시 속도를 높이는 통합 협업 플랫폼으로 진화하고 있습니다. **Dev Mode를 활용한 코드 생성 최적화** - 개발자 전용 인터페이스인 'Dev Mode'를 통해 디자인 요소에서 직접 React 컴포넌트 코드를 추출할 수 있습니다. - 디자인의 오토 레이아웃(Auto Layout) 속성을 Flexbox나 Grid와 같은 최신 CSS 레이아웃 방식으로 정확하게 매핑하여 제공합니다. - 단순한 스타일 복사를 넘어 컴포넌트의 구조와 Props 관계를 고려한 코드 생성을 지원합니다. **디자인 시스템과 코드의 긴밀한 연결** - Figma에서 정의한 변수(Variables)와 스타일 토큰을 코드상의 테마 변수나 디자인 시스템 토큰과 동기화할 수 있습니다. - Tailwind CSS와 같은 최신 CSS 프레임워크를 지원하여, 프로젝트 환경에 맞는 최적화된 클래스 기반 코드를 생성합니다. - 디자인 시스템의 변경 사항이 발생했을 때, 이를 코드 수준에서 어떻게 반영할지 미리 확인하고 적용할 수 있어 관리 효율성이 높아집니다. **VS Code 통합을 통한 개발 흐름 개선** - 'Figma for VS Code' 확장 프로그램을 통해 IDE를 벗어나지 않고도 디자인 문서를 확인하고 코드를 작성할 수 있습니다. - 디자인 에셋을 다운로드하거나 색상 값을 확인하는 반복적인 작업을 편집기 내에서 즉시 수행하여 컨텍스트 스위칭 비용을 최소화합니다. - 코드와 디자인 파일 간의 링크를 유지함으로써, 특정 UI 요소가 디자인의 어떤 부분에서 기인했는지 추적하기 용이합니다. **실용적인 권장 사항** 협업 효율을 극대화하기 위해 디자이너는 Figma 작업 시 오토 레이아웃과 변수를 엄격하게 적용하는 것이 중요합니다. 개발자는 Figma에서 생성된 코드를 그대로 사용하기보다는 프로젝트의 아키텍처에 맞춰 리팩토링하는 기반 작업(Boilerplate)으로 활용할 때 가장 높은 생산성을 얻을 수 있습니다.

새로운 Principle 연동 기능 (새 탭에서 열림)

에어비앤비의 디자이너 젬 골드(Jem Gold)는 React 코드를 Sketch 디자인 파일로 직접 렌더링하는 혁신적인 오픈 소스 라이브러리를 공개하며 디자인과 엔지니어링의 결합을 시도했습니다. 이 라이브러리는 코드 기반의 디자인 시스템을 구축하여 두 직군 간의 협업 효율성을 극대화하는 것을 목표로 합니다. 이를 통해 에어비앤비는 실제 제품 코드와 디자인 결과물 사이의 간극을 줄이는 선구적인 워크플로우를 제시하고 있습니다. **React와 Sketch의 통합 렌더링** * React 컴포넌트를 기반으로 Sketch 디자인 자산을 생성하는 새로운 방식의 오픈 소스 도구입니다. * 디자인 시스템의 단일 소스(Single Source of Truth)를 코드로 관리함으로써, 디자인 가이드와 실제 구현체 간의 동기화 문제를 해결합니다. * 디자이너가 코드를 통해 디자인 요소를 조작하고, 엔지니어는 디자인된 결과물을 즉시 코드로 확인할 수 있는 환경을 제공합니다. **디자인 엔지니어링의 새로운 패러다임** * 기존의 정적인 디자인 도구에서 벗어나 코드가 중심이 되는 동적인 디자인 프로세스를 구축했습니다. * 디자인 커뮤니티에서 큰 반향을 일으키며 디자인과 개발의 경계를 허무는 디자인 엔지니어링의 새로운 지평을 열었다는 평가를 받습니다. * 이러한 접근법은 복잡한 UI 구성 요소를 대규모로 일관성 있게 관리해야 하는 조직에 강력한 영감을 제공합니다. 디자인 시스템의 일관성을 유지하고 핸드오프 과정의 비효율을 줄이고 싶다면, 에어비앤비의 사례처럼 코드를 디자인의 출발점으로 삼는 '코드 중심 디자인(Code-to-Design)' 방식을 검토해 볼 것을 추천합니다.

놓치셨을 분들을 (새 탭에서 열림)

에어비앤비의 디자이너 젬 골드(Jem Gold)는 디자인과 엔지니어링의 간극을 좁히기 위해 React 코드를 Sketch 디자인으로 직접 렌더링하는 혁신적인 오픈소스 라이브러리를 개발했습니다. 이 프로젝트는 디자인 커뮤니티에서 큰 화제가 되었으며, 실제 프로덕션 코드를 디자인 도구와 결합하려는 선구적인 시도로 평가받고 있습니다. 젬 골드는 이러한 기술적 접근 방식의 기저에 영감을 준 다섯 권의 책을 통해 자신의 디자인 철학을 정립했습니다. **코드와 디자인의 결합: React-Sketchapp** * 에어비앤비가 공개한 이 라이브러리는 엔지니어링 단계의 React 코드를 활용해 Sketch 파일을 자동으로 생성함으로써 디자인 시스템의 일관성을 극대화합니다. * 이는 디자이너가 정적 자산을 수동으로 업데이트하는 번거로움을 줄여주며, 코드 기반의 '단일 진실 공급원(Single Source of Truth)'을 구축하는 데 기여합니다. * 디자인과 개발 프로세스를 하나로 통합하여 제품 개발의 효율성과 정확도를 획기적으로 높였습니다. **젬 골드의 설계 철학을 형성한 배경** * 젬 골드의 디자인 접근 방식은 단순히 시각적인 측면에 머물지 않고, 구조적이고 논리적인 설계를 강조합니다. * 라이브러리 개발의 영감이 된 문헌들은 UI/UX 설계, 문제 해결을 위한 통찰력, 그리고 기술 중심의 디자인 사고를 포함하고 있습니다. * 이러한 철학적 배경은 에어비앤비 내에서 디자인 시스템이 단순한 가이드라인을 넘어 실제 동작하는 코드로 구현되는 원동력이 되었습니다. 제품 개발 환경에서 디자인과 엔지니어링의 경계가 갈수록 모호해지는 만큼, 코드를 디자인의 도구로 적극 활용하는 에어비앤비의 방식은 효율적인 디자인 시스템 운영을 고민하는 조직에게 중요한 이정표를 제시합니다. 단순한 툴 사용법을 넘어 그 이면에 담긴 설계 철학을 이해하는 것이 기술적 혁신을 이루는 핵심입니다.