<div id="readability-page-1" class="page"><div>
        

<h2 id="목차">목차</h2>

<ol>
  <li><a href="#1-개요">개요</a>
    <ol>
      <li><a href="#11-시스템의-정의와-범위">시스템의 정의와 범위</a></li>
    </ol>
  </li>
  <li><a href="#2-시스템-설계">시스템 설계</a>
    <ol>
      <li><a href="#21-설계-목적">설계 목적</a></li>
      <li><a href="#22-Figma-Plugin">Figma Plugin</a></li>
      <li><a href="#23-Figma-Code-Connect">Figma Code Connect</a></li>
    </ol>
  </li>
  <li><a href="#3-운영-프로세스">운영 프로세스</a>
    <ol>
      <li><a href="#31-운영-원칙">운영 원칙</a></li>
      <li><a href="#32-릴리스와-피드백-루프">릴리스와 피드백 루프</a></li>
      <li><a href="#33-직군-합의와-품질-관리">직군 합의와 품질 관리</a></li>
    </ol>
  </li>
  <li><a href="#4-후기">후기</a></li>
</ol>

<hr>



<h2 id="1-개요">1. 개요</h2>

<p>안녕하세요 쏘카 개발자 아놀드입니다.</p>

<p>쏘카에서 장기간의 프로젝트인 쏘카프레임 2.0 개발에 참여하며 고민하고 개발하였던 이야기를 해보려 합니다. 이 글에서 쏘카프레임은 쏘카의 사내 디자인 시스템이며 프론트엔드 관점의 <strong>시스템 설계/연동/운영</strong>에 관해 적어보겠습니다.</p>

<p>1편에서는 시스템 설계, 운영 프로세스 등을 다루고, 2편에서는 컴포넌트 아키텍처, 패키지 전략, AI 활용을 중심으로 정리하며 총 2편으로 글을 적어보려합니다.</p>

<p>쏘카에는 기존의 UI 라이브러리인 <strong>쏘카프레임</strong>이 존재하였습니다.</p>

<p>기존 UI 라이브러리는 디자인 시스템을 표방했습니다. 하지만 입사 당시 이미 라이브러리의 역할분담이 모호한 상태였습니다. 유지보수가 거의 되지 않았고, 각 서비스별로 파편화된 UI/UX 개발이 이뤄지고 있는 상황이었습니다.</p>

<p>이로 인해 사내 디자이너와 FE(Frontend) 개발로 이어지는 제품 개발 프로세스의 일관성과 효율성이 떨어졌습니다. 이를 해결하기 위해 쏘카프레임 2.0 프로젝트가 시작되었습니다.</p>

<h2 id="11-시스템의-정의와-범위">1.1 시스템의 정의와 범위</h2>

<p>이 글에서 말하는 “시스템”은 <strong>컴포넌트 UI 라이브러리</strong> 이상의 개념을 내포하고 있습니다.</p>

<p>UI 라이브러리 위에 <strong>정책(규칙), 연동(디자인-코드), 운영(릴리스/검증)</strong>이 얹혀 있어 실제로 반복 가능한 생산 체계가 된다고 판단하여 구현물과 함께 <strong>합의된 규칙과 운영 방식까지 포함</strong>되는 것을 시스템으로 정의했습니다.</p>

<p>간단히 아래 4가지가 필요하다고 정의했습니다.</p>

<div><pre><code>[디자인 시스템]
  ├─ 규칙/정책 (토큰/상태/예외 처리 기준)
  ├─ 컴포넌트 라이브러리 (재사용 가능한 UI)
  ├─ 연동 체계 (Figma ↔ Code)
  └─ 운영 프로세스 (릴리스/검증/피드백)
</code></pre></div>

<p>범위 또한 시스템 개발이 진행되며 확실히 잡혔습니다. 디자인 토큰, 컴포넌트, 문서, 연동 규칙은 시스템의 범위로 포함했지만, 서비스별 UI 정책과 화면 구성은 각 서비스의 책임으로 분리했습니다.</p>

<p>이렇게 경계를 정해야 역할이 섞이지 않고, 시스템이 “공통 기반”으로 기능할 수 있다고 봤습니다.</p>

<h2 id="2-시스템-설계">2. 시스템 설계</h2>

<h2 id="21-설계-목적">2.1 설계 목적</h2>

<p>기존의 사례가 존재했기 때문에 변화에 대응하고 확장 가능한 UI 라이브러리가 포함된 시스템을 만드는 것이 첫번째 목표였습니다. (확장 가능한 UI 라이브러리에 대한 내용은 2편에서 자세히 다루도록 하겠습니다.)</p>

<p>두번째 목표는 정의한 <code>연동체계</code> 강화를 통한 기존의 업무방식의 효율성을 높이는 것 이었습니다.</p>

<p>쏘카는 사내 디자인 툴로 Figma를 활용하고 있고 디자인 산출물을 개발자가 한땀한땀 구현으로 옮기는 것이 기존 업무 방식이었습니다.
구체적으로는 <code>디자이너 → 개발자(라이브러리)</code> 전달 과정과 <code>개발자(라이브러리) → 개발자(서비스)</code> 전달 과정을 최적화하는 데 초점을 두었습니다.</p>

<p>이 과정은 Figma의 지원 기능을 적극 활용해 설계했습니다.</p>

<p>아래는 전체 업무 흐름을 기반으로 시스템을 통한 <code>연동체계</code> 강화 목표 지점을 나타낸 다이어그램입니다.</p>

<p><img src="https://tech.socarcorp.kr/img/2026-02-24-socar-frame2-web/architect-target.png" alt="설계결과"></p>

<h2 id="22-figma-plugin">2.2 Figma Plugin</h2>

<p><code>디자이너 → 개발자(라이브러리)</code> 방향으로 소통하는 과정의 최적화 중 일부는 정적인 에셋의 처리였습니다.</p>

<p>구상은 아래 그림과 같았고 이를 위해 <a href="https://www.figma.com/developers/plugins">Figma Plugin</a>을 활용했습니다.</p>

<p><img src="https://tech.socarcorp.kr/img/2026-02-24-socar-frame2-web/socar-frame2.png" alt="Figma Plugin을 통한 에셋 배포 자동화 흐름도"></p>

<p>기존에는 아이콘·스페이싱 토큰이 슬랙 → 담당 개발자 수동 PR(Pull Request) 생성 → 검증 → 배포로 이어져 리드타임이 길었고 이를 줄이기 위해 Figma 내부 플러그인을 도입해 디자이너가 바로 PR을 생성하도록 했습니다.
현재는 PAT(Personal Access Token) 기반으로 인증을 처리합니다.</p>

<p>운영상 보안·권한 문제는 남아 있어, 별도 인증 서버 도입을 후속 과제로 검토 중입니다.</p>

<p><img src="https://tech.socarcorp.kr/img/2026-02-24-socar-frame2-web/figma-plugin.png" alt="Figma 내 아이콘 PR 생성 플러그인 UI"></p>

<p><img src="https://tech.socarcorp.kr/img/2026-02-24-socar-frame2-web/icon-pr.png" alt="생성된 아이콘 PR 예시"></p>

<p>이 외에도 토큰과 같은 foundation 레벨의 요소가 추가될 때는 위와 같은 프로세스를 확장시켜 활용할 수 있을 것으로 보고 있습니다.</p>

<h2 id="23-figma-code-connect">2.3 Figma Code Connect</h2>

<p><code>개발자(라이브러리) → 개발자(서비스)</code> 방향으로 소통하는 과정의 최적화 중 일부는 UI 라이브러리 코드 사용법입니다.</p>

<p>기존에는 <a href="https://storybook.js.org/">Storybook</a>을 통해 UI를 확인했습니다.
이후 라이브러리를 포함한 레포지토리 내에서 코드를 확인해 실제 서비스에 구현하는 방식이었습니다.
하지만 <a href="https://www.figma.com/developers/api#code-connect">Figma Code Connect</a>를 잘 활용한다면 이 과정을 간소화할 수 있게 됩니다.</p>

<p><img src="https://tech.socarcorp.kr/img/2026-02-24-socar-frame2-web/figma-code-connect-code.png" alt="Figma Code Connect 적용 시 노출되는 코드"></p>

<p>Figma Code Connect를 적용하면 디자이너가 선택한 노드에 대해 대응되는 UI 라이브러리 코드가 즉시 노출돼 사용 흐름이 단축됩니다.</p>

<p><img src="https://tech.socarcorp.kr/img/2026-02-24-socar-frame2-web/figma-code-connect.png" alt="Figma에서 컴포넌트 선택 시 연결된 코드 확인"></p>

<p>사진과 같이 특정 UI를 클릭하면 그에 맞는 UI 라이브러리 코드가 나타나게 됩니다.</p>

<p>다만 DatePicker처럼 상태/변형이 많은 컴포넌트는 매핑이 쉽지 않았습니다.
이 과정에서 서로의 설계 방식에 대한 이해가 충분하지 않아 적지 않은 러닝커브가 있었습니다.</p>

<p>디자인 직군은 Figma의 Variant를 활용해 컴포넌트의 노출 여부를 토글하는 방식이 익숙했습니다.
시스템에 있는 컴포넌트를 복사해 Variant를 변경한 뒤 서비스에 적용하는 방식을 주로 사용하셨지만 Slot 형태를 쓰면 복사할 때마다 Slot에 넣을 컴포넌트를 변경해야 하는 번거로움이 있어 자주 쓰지 않는 방식이었습니다.</p>

<p>반면 개발은 합성 컴포넌트 구조에서 어떤 컴포넌트를 하위에 두더라도 유연하게 대응하는 것이 우선순위였기에, 작업 방식의 차이가 존재했습니다.</p>

<p>하지만 합성 컴포넌트 구조에서 이 방식을 그대로 적용하면 Code Connect를 위한 코드와 디자인의 정합성이 떨어진다고 판단했습니다.
그래서 Slot 개념을 활용하기로 합의했고, 이를 통해 확장성을 확보했습니다.</p>

<p>서로 다른 업무 방식의 차이로 인해 현재는 디자인 시스템 영역에서만 이 방식을 사용하고 있습니다.</p>

<p>특정 Slot 안에 정의된 children이 자유롭게 들어갈 수 있도록 개선한 예시로 설명해보겠습니다</p>

<p>아래 사진은 Figma 내에서 하위 UI들이 Main Component로 정의되어 있습니다.
<img src="https://tech.socarcorp.kr/img/2026-02-24-socar-frame2-web/datepicker-figma.png" alt="DatePicker의 Main Component 구성"></p>

<p>아래 보라색 텍스트는 Main Component로 정의된 컴포넌트를 Slot 형태의 children에 넣은 예시입니다. 이를 통해 다른 Main Component 내에서 유연하게 연결할 수 있습니다.</p>

<p><img src="https://tech.socarcorp.kr/img/2026-02-24-socar-frame2-web/datepicker-figma-slot.png" alt="Slot 구조로 연결된 DatePicker 구성"></p>

<p>위 형태를 기반으로 Code Connect를 할 수 있게 되었습니다.
<img src="https://tech.socarcorp.kr/img/2026-02-24-socar-frame2-web/datepicker-figma-slot-code.png" alt="Slot 구조에 매핑된 코드 예시"></p>

<p>결과적으로 합성 컴포넌트 형태와 Figma 설계 형태가 더 유사해졌습니다.</p>

<p>2.1~2.3 의 과정을 통해 <code>연동체계</code> 라는 항목을 강화하며 시스템으로서 생산성 증대의 기반을 닦을 수 있게 되었습니다.</p>

<h2 id="3-운영-프로세스">3. 운영 프로세스</h2>

<h2 id="31-운영-원칙">3.1 운영 원칙</h2>

<p>디자인 시스템 개발은 단기간에 끝나는 일이 아니라, 장기 프로젝트로 진행되었습니다.
파트별로 담당 팀/인원이 배정되었고, 그때그때 우선순위가 바뀌는 일도 많았습니다.
다만 큰 흐름은 <code>정기 회의 → UI/UX 정책 합의 → 구현 → 검증</code> 구조를 유지했습니다.</p>

<h2 id="32-릴리스와-피드백-루프">3.2 릴리스와 피드백 루프</h2>

<p>먼저 어떤 UI를 먼저 내릴지 우선순위를 정했고, N차 개발 마일스톤을 나눠서 진행했습니다.
이 과정에서 <strong>“구현이 완료된 컴포넌트는 최대한 빠르게 서비스에 반영해야 한다”</strong>는 요구가 있었기 때문에, 일부 컴포넌트는 <code>부분 적용 → 피드백 → 수정</code>의 흐름으로 운영되기도 했습니다.</p>

<h2 id="33-직군-합의와-품질-관리">3.3 직군 합의와 품질 관리</h2>

<p>그 과정에서 OS별 구현 방식 차이(모션, 스크롤, 터치/제스처 등)나 구조적으로 피할 수 없는 한계도 확인했습니다.
그리고 비개발 직군인 디자이너와 개발 직군 사이에서 Code Connect 매핑 규칙을 맞춰나가는 과정이 생각보다 큰 챌린지였습니다.
컴포넌트 슬롯 구조나 상태 정의가 Figma 설계와 맞아야 했기 때문에, 단순히 “연결”이 아니라 서로의 설계 방식 자체를 합의하는 과정이 필요했습니다.</p>

<p>이런 상황 속에서 각 직군의 컨텍스트를 맞추고 시스템의 일관성을 유지하기 위해, 큰 틀의 정책은 합의한 뒤 담당 개발자가 구현하고 QC(Quality Check)를 거쳐 배포 전략을 결정하는 구조를 유지했습니다.</p>

<h2 id="4-후기">4. 후기</h2>

<p>각 파트별로 정말 많은 이야기를 나눌 수 있는 주제들이지만, 이 글에서는 시스템으로 작동하기 위한 개념화를 통한 설계 및 운영 관점 위주로 공유했습니다.
세부 구현까지 모두 담기엔 부족하지만, 그만큼 넓게 봤던 고민과 경험을 기록해 두고 싶었습니다.</p>

<p>특히 Figma 연동을 통해 <code>디자이너 → 개발자(라이브러리)</code> 흐름과 <code>개발자(라이브러리) → 개발자(서비스)</code> 흐름을 동시에 정렬하려 했던 시도가 가장 큰 전환점이었습니다.
단순한 도구 연동을 넘어, <strong>설계 방식과 운영 규칙을 합의</strong>하는 과정이 시스템의 기반이 된다고 느꼈습니다.</p>

<p>2편에서는 컴포넌트 아키텍처, 패키지 전략, AI 활용 사례를 중심으로 좀 더 기술적인 내용을 정리해 보겠습니다.</p>

        </div></div>

SOCAR Tech Blog

목차
개요
    
시스템의 정의와 범위
시스템 설계
    
설계 목적
Figma Plugin
Figma Code Connect
운영 프로세스
    
운영 원칙
릴리스와 피드백 루프
직군 합의와 품질 관리
후기
1. 개요
안녕하세요 쏘카 개발자 아놀드입니다.
쏘카에서 장기간의 프로젝트인 쏘카프레임 2.0 개발에 참여하며 고민하고 개발하였던 이야기를 해보려 합니다. 이 글에서 쏘카프레임은 쏘카의 사내 디자인 시스템이며 프론트엔드 관점의 시스템 설계/연동/운영에 관해 적어보겠습니다.
1편에서는 시스템 설계, 운영 프로세스 등을 다루고, 2편에서는 컴포넌트 아키텍처, 패키지 전략, AI 활용을 중심으로 정리하며 총 2편으로 글을 적어보려합니다.
쏘카에는 기존의 UI 라이브러리인 쏘카프레임이 존재하였습니다.
기존 UI 라이브러리는 디자인 시스템을 표방했습니다. 하지만 입사 당시 이미 라이브러리의 역할분담이 모호한 상태였습니다. 유지보수가 거의 되지 않았고, 각 서비스별로 파편화된 UI/UX 개발이 이뤄지고 있는 상황이었습니다.
이로 인해 사내 디자이너와 FE(Frontend) 개발로 이어지는 제품 개발 프로세스의 일관성과 효율성이 떨어졌습니다. 이를 해결하기 위해 쏘카프레임 2.0 프로젝트가 시작되었습니다.
1.1 시스템의 정의와 범위
이 글에서 말하는 “시스템”은 컴포넌트 UI 라이브러리 이상의 개념을 내포하고 있습니다.
UI 라이브러리 위에 정책(규칙), 연동(디자인-코드), 운영(릴리스/검증)이 얹혀 있어 실제로 반복 가능한 생산 체계가 된다고 판단하여 구현물과 함께 합의된 규칙과 운영 방식까지 포함되는 것을 시스템으로 정의했습니다.
간단히 아래 4가지가 필요하다고 정의했습니다.
[디자인 시스템]
  ├─ 규칙/정책 (토큰/상태/예외 처리 기준)
  ├─ 컴포넌트 라이브러리 (재사용 가능한 UI)
  ├─ 연동 체계 (Figma ↔ Code)
  └─ 운영 프로세스 (릴리스/검증/피드백)
범위 또한 시스템 개발이 진행되며 확실히 잡혔습니다. 디자인 토큰, 컴포넌트, 문서, 연동 규칙은 시스템의 범위로 포함했지만, 서비스별 UI 정책과 화면 구성은 각 서비스의 책임으로 분리했습니다.
이렇게 경계를 정해야 역할이 섞이지 않고, 시스템이 “공통 기반”으로 기능할 수 있다고 봤습니다.
2. 시스템 설계
2.1 설계 목적
기존의 사례가 존재했기 때문에 변화에 대응하고 확장 가능한 UI 라이브러리가 포함된 시스템을 만드는 것이 첫번째 목표였습니다. (확장 가능한 UI 라이브러리에 대한 내용은 2편에서 자세히 다루도록 하겠습니다.)
두번째 목표는 정의한 연동체계 강화를 통한 기존의 업무방식의 효율성을 높이는 것 이었습니다.
쏘카는 사내 디자인 툴로 Figma를 활용하고 있고 디자인 산출물을 개발자가 한땀한땀 구현으로 옮기는 것이 기존 업무 방식이었습니다.
구체적으로는 디자이너 → 개발자(라이브러리) 전달 과정과 개발자(라이브러리) → 개발자(서비스) 전달 과정을 최적화하는 데 초점을 두었습니다.
이 과정은 Figma의 지원 기능을 적극 활용해 설계했습니다.
아래는 전체 업무 흐름을 기반으로 시스템을 통한 연동체계 강화 목표 지점을 나타낸 다이어그램입니다.
2.2 Figma Plugin
디자이너 → 개발자(라이브러리) 방향으로 소통하는 과정의 최적화 중 일부는 정적인 에셋의 처리였습니다.
구상은 아래 그림과 같았고 이를 위해 Figma Plugin을 활용했습니다.
기존에는 아이콘·스페이싱 토큰이 슬랙 → 담당 개발자 수동 PR(Pull Request) 생성 → 검증 → 배포로 이어져 리드타임이 길었고 이를 줄이기 위해 Figma 내부 플러그인을 도입해 디자이너가 바로 PR을 생성하도록 했습니다.
현재는 PAT(Personal Access Token) 기반으로 인증을 처리합니다.
운영상 보안·권한 문제는 남아 있어, 별도 인증 서버 도입을 후속 과제로 검토 중입니다.
이 외에도 토큰과 같은 foundation 레벨의 요소가 추가될 때는 위와 같은 프로세스를 확장시켜 활용할 수 있을 것으로 보고 있습니다.
2.3 Figma Code Connect
개발자(라이브러리) → 개발자(서비스) 방향으로 소통하는 과정의 최적화 중 일부는 UI 라이브러리 코드 사용법입니다.
기존에는 Storybook을 통해 UI를 확인했습니다.
이후 라이브러리를 포함한 레포지토리 내에서 코드를 확인해 실제 서비스에 구현하는 방식이었습니다.
하지만 Figma Code Connect를 잘 활용한다면 이 과정을 간소화할 수 있게 됩니다.
Figma Code Connect를 적용하면 디자이너가 선택한 노드에 대해 대응되는 UI 라이브러리 코드가 즉시 노출돼 사용 흐름이 단축됩니다.
사진과 같이 특정 UI를 클릭하면 그에 맞는 UI 라이브러리 코드가 나타나게 됩니다.
다만 DatePicker처럼 상태/변형이 많은 컴포넌트는 매핑이 쉽지 않았습니다.
이 과정에서 서로의 설계 방식에 대한 이해가 충분하지 않아 적지 않은 러닝커브가 있었습니다.
디자인 직군은 Figma의 Variant를 활용해 컴포넌트의 노출 여부를 토글하는 방식이 익숙했습니다.
시스템에 있는 컴포넌트를 복사해 Variant를 변경한 뒤 서비스에 적용하는 방식을 주로 사용하셨지만 Slot 형태를 쓰면 복사할 때마다 Slot에 넣을 컴포넌트를 변경해야 하는 번거로움이 있어 자주 쓰지 않는 방식이었습니다.
반면 개발은 합성 컴포넌트 구조에서 어떤 컴포넌트를 하위에 두더라도 유연하게 대응하는 것이 우선순위였기에, 작업 방식의 차이가 존재했습니다.
하지만 합성 컴포넌트 구조에서 이 방식을 그대로 적용하면 Code Connect를 위한 코드와 디자인의 정합성이 떨어진다고 판단했습니다.
그래서 Slot 개념을 활용하기로 합의했고, 이를 통해 확장성을 확보했습니다.
서로 다른 업무 방식의 차이로 인해 현재는 디자인 시스템 영역에서만 이 방식을 사용하고 있습니다.
특정 Slot 안에 정의된 children이 자유롭게 들어갈 수 있도록 개선한 예시로 설명해보겠습니다
아래 사진은 Figma 내에서 하위 UI들이 Main Component로 정의되어 있습니다.
아래 보라색 텍스트는 Main Component로 정의된 컴포넌트를 Slot 형태의 children에 넣은 예시입니다. 이를 통해 다른 Main Component 내에서 유연하게 연결할 수 있습니다.
위 형태를 기반으로 Code Connect를 할 수 있게 되었습니다.
결과적으로 합성 컴포넌트 형태와 Figma 설계 형태가 더 유사해졌습니다.
2.1~2.3 의 과정을 통해 연동체계 라는 항목을 강화하며 시스템으로서 생산성 증대의 기반을 닦을 수 있게 되었습니다.
3. 운영 프로세스
3.1 운영 원칙
디자인 시스템 개발은 단기간에 끝나는 일이 아니라, 장기 프로젝트로 진행되었습니다.
파트별로 담당 팀/인원이 배정되었고, 그때그때 우선순위가 바뀌는 일도 많았습니다.
다만 큰 흐름은 정기 회의 → UI/UX 정책 합의 → 구현 → 검증 구조를 유지했습니다.
3.2 릴리스와 피드백 루프
먼저 어떤 UI를 먼저 내릴지 우선순위를 정했고, N차 개발 마일스톤을 나눠서 진행했습니다.
이 과정에서 “구현이 완료된 컴포넌트는 최대한 빠르게 서비스에 반영해야 한다”는 요구가 있었기 때문에, 일부 컴포넌트는 부분 적용 → 피드백 → 수정의 흐름으로 운영되기도 했습니다.
3.3 직군 합의와 품질 관리
그 과정에서 OS별 구현 방식 차이(모션, 스크롤, 터치/제스처 등)나 구조적으로 피할 수 없는 한계도 확인했습니다.
그리고 비개발 직군인 디자이너와 개발 직군 사이에서 Code Connect 매핑 규칙을 맞춰나가는 과정이 생각보다 큰 챌린지였습니다.
컴포넌트 슬롯 구조나 상태 정의가 Figma 설계와 맞아야 했기 때문에, 단순히 “연결”이 아니라 서로의 설계 방식 자체를 합의하는 과정이 필요했습니다.
이런 상황 속에서 각 직군의 컨텍스트를 맞추고 시스템의 일관성을 유지하기 위해, 큰 틀의 정책은 합의한 뒤 담당 개발자가 구현하고 QC(Quality Check)를 거쳐 배포 전략을 결정하는 구조를 유지했습니다.
4. 후기
각 파트별로 정말 많은 이야기를 나눌 수 있는 주제들이지만, 이 글에서는 시스템으로 작동하기 위한 개념화를 통한 설계 및 운영 관점 위주로 공유했습니다.
세부 구현까지 모두 담기엔 부족하지만, 그만큼 넓게 봤던 고민과 경험을 기록해 두고 싶었습니다.
특히 Figma 연동을 통해 디자이너 → 개발자(라이브러리) 흐름과 개발자(라이브러리) → 개발자(서비스) 흐름을 동시에 정렬하려 했던 시도가 가장 큰 전환점이었습니다.
단순한 도구 연동을 넘어, 설계 방식과 운영 규칙을 합의하는 과정이 시스템의 기반이 된다고 느꼈습니다.
2편에서는 컴포넌트 아키텍처, 패키지 전략, AI 활용 사례를 중심으로 좀 더 기술적인 내용을 정리해 보겠습니다.

쏘카 디자인 시스템 2.0 개발기 1편: 시스템으로 굴리기(웹)

댓글