300명이 넘는 개발자와 디자이너를 위한 디자인 시스템을 4명의 디자이너가 운영하고 있어요. 이 과정에서 컴포넌트의 유려함뿐만 아니라, 가이드의 효율적인 제작도 중요함을 깨달았어요. 이번 아티클에서는 TDS 컴포넌트 가이드를 제작할 때 어떤 부분들을 고려해서 만들어가고 있는지 소개해드릴게요.


문제 
컴포넌트를 개선하려고 할 때, 기존 가이드로는 동료 플랫폼 디자이너 및 개발자분들과 소통하기 어려웠어요. 컴포넌트 가이드 작성에 대한 규칙이 없으니 디자이너마다 작성된 방식이 제각기였고, 이 때문에 기존에 작성된 가이드를 읽는 데에도 컴포넌트를 온전히 파악하기 어려웠기 때문이에요.
기존 컴포넌트의 가이드에서 어떤 부분들이 문제였길래, 컴포넌트를 만드는데 메이커들이 어려움을 겪었을까요? 그리고 플랫폼 디자이너들은 이 문제들을 어떻게 해결했을까요?


해결책
가이드 읽는 방향성 정하기
기존에는 한눈에 스펙을 확인할 수 있도록 정사각형에 가까운 형태로 가이드를 배치했어요. 


각 옵션이 한 눈에 보이고, 깔끔하게 정리된 가이드를 보며, 이 완벽한 가이드만 있으면 더 이상의 커뮤니케이션은 필요 없을 줄 알았어요. 하지만 개발자분들이 이미 가이드에 정의된 스펙을 보지 못한 채 따로 요청해주시기도 하고, 컴포넌트를 구현하면서 누락된 옵션들도 종종 나타났죠.
이유를 개발자와 이야기해보니 가이드를 어떤 순서로 읽어야 하는지 파악하기 어려웠다는 걸 알게 됐어요. 그래서 어떤 구조로 컴포넌트를 만들어야 하는지 이해하기 힘들었다고 하더라고요.


그래서 정보를 단순히 그룹핑만 하는 것이 아니라, 읽는 방식부터 누구나 같은 방향으로 읽을 수 있게끔 그룹핑된 가이드 내용을 위에서 아래로 흐르게끔 배치했어요. 

이로써, 가이드를 어떤 순서로 읽어야 하는지 알기 쉬워졌고, 그 결과 컴포넌트의 스펙을 단계별로 쉽게 소화할 수 있게 됐어요.


큰 구조부터 자세한 요소로
가이드의 방향성을 정한 이후로 순서에 대해서 고민하고 있을 때, 때마침 컴포넌트 스펙맞추기 해커톤이 예정되어있었어요. 안드로이드 iOS, 웹 세 플랫폼이 모이는 시간에 저도 아예 옆에 앉아서 가이드는 어떻게 기록되어야 좋은 가이드가 될 수 있을지, 신속하게 피드백을 구하며 빠르게 의사결정을 해나갔어요. 
그 과정에서 발견한 것은 개발도 그림을 그리듯이 큰 구조부터 자세한 요소로 진행된다는 점이었어요. 전체적인 스케치를 한 다음 묘사를 하는 것처럼요.

그래서, 토스트 컴포넌트 가이드에서는 가장 먼저 컴포넌트의 상위 옵션인 상단과 하단 타입을 보여주어 개발자가 구조를 이해할 수 있도록 하고, 그다음으로 각 타입에 포함된 요소들을 정리했어요. 마지막으로는 컴포넌트의 다양한 상태 변화(예를 들어 다크모드나 텍스트가 두 줄이 됐을 때)의 상세 스펙을 추가했어요. 
이처럼 큰 옵션 정의부터 내부 변경될 수 있는 자세한 스펙들 순으로 점층적으로 가이드를 구성해 원하는 스펙을 찾아 방황할 필요 없이 효율적으로 가이드를 읽을 수 있게 했어요.


최악의 케이스 그리기
컴포넌트의 정보 위계가 생긴 것은 좋았지만, 그 정보 위계의 지도를 한 눈에 볼 수 없다는 점이 아쉬웠어요. 컴포넌트 안에도 다양한 요소들이 있어서, 어떤 요소는 쓰고 어떤 요소는 안 썼을 때 등등 굉장히 다양한 경우의 수가 있었거든요. 
예를 들어 토스트에서 주로 쓰는 형태는 왼쪽이지만, 오른쪽처럼 버튼을 넣는 케이스도 있었어요.

이런 케이스를 하나하나 살펴볼 수 없으니, 오른쪽처럼 모든 요소를 최대한으로 썼을 때의 모습을 가이드의 제일 위에 첨부해두었어요. 모든 옵션을 다 사용한 사례를 먼저 보고 나면, 어떤 옵션이 있는지 전체적으로 지도를 그린 다음 하나씩 살펴볼 수 있으니까요.


접근성 영역 나누기
기존 가이드에선 접근성 스펙을 컴포넌트 레이아웃에 대한 설명할 때 포함하기도 하고, 별도의 페이지에 작성하기도 했어요. 그렇다 보니 ‘음! 새로운 A컴포넌트를 만들 땐 B컴포넌트의 접근성 가이드를 참고해야지! ‘라고 떠올리기 쉽지 않았어요. 그래서 접근성을 챙기기 위한 여러 가지 장치들을 새로운 컴포넌트를 설계할 때 참고하기 어려웠죠.
그래서 접근성에 대한 기존의 의사결정들을 비슷한 컴포넌트를 새롭게 설계할 때도 빠르게 참고할 수 있도록 선형으로 설계된 가이드에 가장 하단에 위치시키기로 약속했어요.

이를 통해서 디자이너가 가이드를 설계할 때 이 옵션을 의식적으로 챙길 수 있었고, 이러한 구조 변경으로 더 큰 텍스트 뿐만 아니라 보이스오버 사용성, 동작 줄이기와 같은 조건들을 조금씩 쌓아나갈 수 있었어요.


수십개의 컴포넌트 가이드에 적용하기
토스트, CTA, 리스트 등 여러 요소를 조합해 사용하는 대다수 컴포넌트는 앞서 정한 구성을 그대로 적용할 수 있게 했어요. 이를 위해, 큰 구조부터 시작해 타입, 영역, 상세 스펙, 더 큰 텍스트, 다크모드까지 포함하는 체크리스트를 정의했죠. 이 체크리스트를 바탕으로 가이드를 작성하도록 했어요. 타입이 나뉘어있지 않거나, 상세 스펙을 따로 정의할 필요가 없는 경우에는 생략했어요.


에셋, 버튼, 체크박스와 같은 아토믹 컴포넌트들은 구성요소가 단순해서 일반적인 컴포넌트 가이드와 비슷한 구조로 짜다 보면, 불필요한 정보를 넣게 되더라고요. 그래서 컴포넌트 자체의 특성에 맞게 뒤따라올 옵션들이 예측할 수 있게끔만 가이드를 구성했어요.


그리고 화면을 덮으며 나타나는 다이얼로그나, 바텀시트와 같은 컴포넌트들은 화면 안에서 어디에 위치해야 하는지에 대해 정의할 수 있도록 position이라는 항목을 체크리스트에 추가했어요.


또한 각 스펙을 가이드에 작성할 때는, 정확한 스타일 값과 결과물을 한 번에 볼 수 있도록 왼쪽에는 예시 이미지를 오른쪽에는 정확한 값을 꼭 작성하도록 했고, 이 작업을 최대한 효율화하기 위해 디자인 스펙을 표기하는 몇 가지 형태를 복붙해서 사용할 수 있도록 만들어두기도 했어요



결과 
이러한 해결책들을 통해서 기존 가이드의 많은 문제의식을 해결할 수 있었어요.
가이드 작성에 대한 규칙이 없을때는 하나의 컴포넌트 가이드를 작성하는 데에만 일주일이 걸렸는데, 가이드 작성하는 규칙이 생긴 이후로는 컴포넌트 3개를 하루 만에 가이드를 작업할 수도 있었어요. 또한 팀에 새로 합류한 플랫폼 디자이너들이 기존 시스템을 빠르게 이해하고 바로 기여할 수 있었어요. 
하지만 시스템이 성장하면서 가이드가 길어진 것들은 지금의 방식으로는 원하는 스펙을 찾아가기 힘들어져, 구조에 맞게 가이드를 끊거나 목차를 만드는 등의 새로운 방식들을 고민하고 있어요.
앞으로 시스템의 규모가 성장함에 따라 기존 가이드를 개선했던 것처럼 팀원들과 함께 논의해가며 가이드를 개선해 나가려고 해요.




300명이 넘는 개발자와 디자이너를 위한 디자인 시스템을 4명의 디자이너가 운영하고 있어요. 이 과정에서 컴포넌트의 유려함뿐만 아니라, 가이드의 효율적인 제작도 중요함을 깨달았어요. 이번 아티클에서는 TDS 컴포넌트 가이드를 제작할 때 어떤 부분들을 고려해서 만들어가고 있는지 소개해드릴게요.


문제 
컴포넌트를 개선하려

디자인 시스템을 운영하면서, 컴포넌트의 유려함뿐만 아니라 가이드의 효율적인 제작도 중요하다는 것을 깨달았어요. 이번 아티클에서는 TDS 컴포넌트 가이드를 제작 할 때 어떤 부분들을 고려해서 만들어가고 있는지 소개해드릴게요.

제품이 커지면 디자인 시스템 가이드는 어떻게 개선돼야 할까?

안녕하세요, 토스 프론트엔드 엔지니어링 헤드 박서진입니다.
토스에서는 최고의 사용자 경험이 필요한 곳은 Native, 매일매일 실험으로 제품을 개선하는 제품은 React Native/WebView로 구성하고 있어요.
토스 프론트엔드 챕터는 지난 2022년 6월부터 React Native 기술에 투자하고 있는데요. 이번 기술 블로그 아티클에서는 왜 React Native를 고려하고 있는지, 현재 어느 정도까지 사용하고 있는지, 그리고 앞으로의 계획이 어떻게 되는지에 대해서 소개드리려고 합니다.
왜 React Native인가
토스는 React Native로 매끄러운 사용자 경험과 높은 개발 생산성을 제공하여, 모바일 서비스를 만드는 새로운 표준을 제시하고자 해요.


React Native로 서비스를 개발하면, WebView로 서비스를 만들 때보다 사용자 경험을 크게 개선할 수 있어요. React Native는 기본적으로 파일 시스템에서 JavaScript 파일을 읽어오기 때문에, WebView와 다르게 네트워크로 인한 로딩 속도를 없앨 수 있기 때문이죠.
한국처럼 대부분의 사용자가 2020년 이후에 출시한 최신 핸드폰을 쓰는 환경에서는, JavaScript 실행도 매우 빨라요. 토스에서 “매일 방문 미션” 제품을 React Native로 만들었을 때, 1초 이상의 로딩 속도를 감축시킬 수 있었어요. 

특히 앞으로 모바일 기기 성능 발전과 더불어서 JavaScript 실행 속도는 매년 두 자릿수 퍼센티지로 빨라지고, 로딩 시간은 그만큼 계속 줄어들 것으로 보여요. Hermes 엔진으로 JavaScript를 미리 컴파일하면 초기 로딩 속도를 더 빠르게 할 수도 있답니다. (사진 출처)

프론트엔드 개발자의 개발 생산성도 개선할 수 있는데요. 

먼저, WebView에서 생산성을 깎는 다양한 문제를 근본적으로 해결할 수 있었어요. 토스는 모바일 서비스를 WebView로 만들면서, 여러 제약이 있다는 것을 알게 되었어요. iOS에서는 display: fixed와 autoFocus 문제가 있었고, Android는 WebView 버전마다 웹 서비스가 다르게 동작하기도 했죠. History도 마음껏 수정하기 어려웠습니다. React Native는 Native 렌더러를 사용하고, 높은 자유도를 제공하기 때문에, 이 문제를 모두 깔끔히 해결할 수 있었어요.


또한, 빌드와 배포 속도를 개선할 수 있었어요. 보통 WebView 기반으로 서비스를 만들면 빌드가 느리다는 문제에 맞닥뜨리게 되어요. SSR을 쓰는 경우 서버를 빌드하고 배포하는 시간이 필요하죠. 반면, React Native 기술에서는 배포 단계가 단순해서, 정적인 JavaScript 파일 1개만 빌드하고 업로드하면 돼요. 그래서 배포가 완료되기까지의 시간을 손쉽게 최적화할 수 있죠.


마지막으로, 코드의 복잡도도 낮출 수 있었어요. 토스는 100개 넘는 Server-side rendering (SSR) 서비스를 운영하고 있는데요. SSR을 이용하면 기존의 Client-side rendering 접근보다 로딩 속도를 크게 개선하지만, Server와 Client를 넘나드는 Universal한 코드를 작성해야 해요. 두 환경을 모두 고려해야 하기 때문에, 코드의 복잡도가 크게 올라갔죠. 반면, React Native를 이용하면 Client에서 실행되는 경우만 고려하면 되었어요.

토스에서는 사용자 경험과 개발 생산성의 두 가지 가치가 제일 중요한데요. 이렇게 React Native를 이용하면 사용자에게는 더 좋은 경험을 제공하면서도, 개발 생산성도 높일 수 있겠다는 생각이 들었어요.
토스 React Native 기술의 현재
토스 프론트엔드 챕터에서는 지난 1년 6개월간 React Native 화면을 조심스럽게 확대해 나가면서, 실제로 토스에서 가치를 제공하는지 확인했어요.


토스에서 “혜택 탭”은 React Native로 운영된 첫 번째 서비스로서, 토스에서 광고를 보고 앱테크로 돈을 버는 새로운 표준을 제시했습니다. 매출도 크게 증가했죠. 로딩 속도를 1초 이상 감축했고, 자동 동영상 재생과 같이 기존의 WebView에서 어려웠던 부분을 깔끔히 해결할 수 있었습니다.
혜택 탭 외로도, 지난 1년간 토스에서는 React Native 서비스를 다수 신규 런칭했어요. “피드 보고 포인트 받기”, “매일 방문 미션”과 같은 다양한 제품이 개발되어 서비스되고 있죠. 덕분에 지금은 React Native 뷰는 WebView를 이용한 화면보다도 많이 실행되고 있어요.
2024년 토스는 React Native를 서비스를 만들어 나가는 정식 기술 가운데 하나로 사용해보기로 하고, 서비스를 확대해 나가는 단계예요.
React Native 개발환경 자세히 살펴보기
그렇다면 토스에서는 어떻게 React Native 개발환경을 만들어나가고 있을까요?
마이크로 프론트엔드 아키텍처



토스에서는 사일로와 서비스마다 독립적으로 서비스를 운영하는 것이 매우 중요해요. 토스는 DRI 문화를 핵심 원칙으로 삼고 있기 때문에, 사일로에서 자체적으로 빠르게 의사결정을 내려서 배포 주기와 방법을 결정해야 하기 때문이죠. 한 서비스의 변경사항이 다른 서비스에게 영향을 주어서도 안 됩니다.
일반적으로 React Native 애플리케이션은 모놀리식한 단일 파일로 구성되는 경우가 많은데요. 토스에서는 자체적으로 React Native 애플리케이션을 마이크로 프론트엔드 아키텍처로 관리하는 시스템을 만들었습니다.


토스에서는 서비스마다 React Native 뷰가 나누어져 있으며, 각 서비스 화면은 독립적으로 실행되어 다른 화면에 영향을 주지 않습니다. 서비스가 실행될 때, 필요한 JavaScript 파일만 동적으로 로드해서 실행하는 형태예요. 
구체적으로는, 토스에서는 React Native 뷰를 그리기 위해 “Shared 번들” 과 “Service 번들”을 나누어 차례대로 실행합니다. “Shared 번들”은 react-native 라이브러리와 같이, 네이티브 영역과 강하게 연결되어 있어, 모든 서비스가 공통으로 사용하는 코드입니다. 그리고 “Service 번들”은 각 서비스에서 다르게 운영하는 부분만 별도로 분리된 코드에요. 두 코드는 서비스가 실행될 때 순서대로 동적으로 로드돼요. 이로써 사용자들은 서비스를 띄울 때 필요한 만큼만의 작은 JavaScript 코드를 실행하게 됩니다.
이렇게 만들어진 “Shared 번들” 과 “Service 번들” 은 토스의 React Native 플랫폼 팀이 만든 자체적인 어드민을 이용해서 CDN으로 배포돼요. 그리고 서비스 개발자는 간편한 UI로, 1초만에 React Native 화면을 배포하면 되죠.
1~100% 사이에서 일부 사용자들에게 원하는 만큼 카나리 배포를 할 수도 있고, 나만 보는 배포를 쉽게 만들 수도 있답니다.
ESBuild를 이용한 신속한 배포
토스에서는 React Native 번들을 빌드하기 위해 Metro 대신 ESBuild 번들러를 사용하고 있어요. Metro 번들러는 빌드하는 데에 시간이 오래 걸리고, Tree-shaking을 지원하지 않으며, 캐시를 리셋하지 않으면 일관적인 동작을 보장하기 어렵기 때문이었습니다. 
ESBuild를 도입한 이후에, 빌드 시간을 1분 안쪽으로 줄일 수 있었어요. 번들에서 안 쓰는 코드를 Tree-shaking으로 삭제해서, 번들 사이즈도 크게 감축시켰죠.
자세한 내용은 2023년 FEConf에서 “React Native, Metro를 넘어서” 발표에서 확인하실 수 있어요.


React Native의 미래
토스 프론트엔드 챕터는 React Native 기술의 미래가 밝다고 생각해요. 과거 React Native 기술에 대한 인식이 좋지 않았을 때도 있었지만, React Native 커뮤니티가 지속적으로 유의미한 발전을 만들고 있다고 보고 있습니다.
먼저, React Native 애플리케이션은 시간이 갈수록 자연스럽게 빨라지고 있어요. 스마트폰이 JavaScript를 실행하는 속도가 계속 빨라지고 있기 때문이죠. 하나의 예시로, 유명한 채팅 앱인 Discord는 iOS와 Android 모두 React Native로 구성되어 있는데요. 놀라울 정도로 빠른 성능과 아름다운 사용성을 보여주고 있어요. 그 외로 Microsoft가 제공하는 Office 앱이나, Shopify, Amazon 같은 사례도 있답니다. 
최근 Meta에서는 react-strict-dom (RSD) 이라고 하는 오픈소스 프로젝트를 발표했는데요. 하나의 코드베이스로 React와 React Native를 연결하려고 하는 비전을 제시하고 있어요. 마찬가지로 토스에서도 Web과 React Native에서 모두 아름답고 안정적으로 동작하는 “Isomorphic Package” 을 만들어 나가려고 해요.

Meta가 공개한 또다른 오픈소스 프로젝트로는 Static Hermes가 있어요. JavaScript를 바이너리로 컴파일함으로써 실행 속도를 네이티브와 동일한 수준으로 맞추려는 담대한 목표를 가지고 있죠. 
또한, 2024년 React Conf는 Meta와 React Native 전문 오픈소스 회사 Callstack이 협업해서 열리는데요. 아직 자세한 발표 내용이 공개되지는 않았지만, React Native를 주제로 하는 발표가 다수 예정되어 있어요. React Native는 앞으로 React Server Components와 함께 React 커뮤니티의 가장 중심적인 주제 중 하나가 될 것이라고 생각해요.
토스의 React Native Platform Team에서 일하기
토스에는 React Native Platform Team이 있어요. 프론트엔드 플랫폼 개발자 3명과 iOS 개발자 1명으로 구성되어 있고, 지금은 Android 개발자를 찾고 있어요. 
모든 팀원이 각자의 분야에 대한 전문가로 구성되어 있어요. 이근혁님은 React Native를 ESBuild로 빌드하는 react-native-esbuild 프로젝트를 오픈소스화하고 토스에 합류하셨어요. 오진성님은 iOS 분야의 전문가로, Cocoapods 없이 React Native를 앱에 포함하는 구조를 설계하셨죠. 기술적인 배경은 다르지만, 모두가 본인의 주된 개발 언어에 관계없이 주도적이고 열정적으로 프로젝트에 참여하고 있어요.

React Native Platform Team의 특징이라고 한다면, 모두가 전문 분야에 관계없이 JavaScript, iOS, Android 모든 영역을 담당하는 것을 지향한다는 점이에요. 프론트엔드 개발자도 iOS, Android 영역에 기여하고, 네이티브 개발자도 JavaScript 영역에 기여하려고 하죠. 프론트엔드와 네이티브 개발자가 다양한 도메인에 소프트랜딩할 수 있도록, 서로가 서로를 온보딩하고, 매일같이 모여서 짝 프로그래밍을 하는 문화를 가지고 있어요. 모두가 iOS, Android, JavaScript 등 클라이언트 개발 전반에 대한 전문성을 확보하려고 하고 있습니다.
대표적인 예시로, iOS 개발자도 React Native의 TDS(디자인 시스템) 라이브러리에 기여하고 있고, 프론트엔드 개발자도 iOS, Android의 React Native 모듈 유지보수에 참여하여 PR을 올리고 있어요.

React Native는 iOS와 Android, JavaScript 개발환경에 대한 이해가 없으면 다루기 힘든 기술인데요. 토스에는 국내 최고 수준으로 JavaScript, iOS, Android를 다루는 엔지니어들이 모여 있어요. 덕분에 어려운 문제를 맞닥뜨렸다고 하더라도, 각 플랫폼의 전문가와 함께 토론하면서 배워가고, 해결할 수 있죠. 치열하게 고민하며 최고의 개발환경을 만들어 나가는 짜릿함을 느끼고 있어요.
이렇게 토스의 React Native Platform Team은, 쫀득한 사용자 경험과 슬릭한 개발 생산성 모두를 제공하는 개발환경을 주도적으로 만들어 나갈 예정이에요.
무엇보다, 토스의 React Native 플랫폼은 여기에 그치지 않고, 올해 안에 지금까지 만든 React Native 배포 모듈과 AWS 인프라를 오픈소스화하고, 세계적으로 앱을 만들어 나가는 Best Practice를 제시하는 것이 목표예요.

최고의 개발환경에서 React Native 서비스를 만들어 나가고 싶으신가요? Frontend Developer로 합류하시면, 토스의 React Native 개발환경을 경험할 수 있답니다.
React Native Platform Team에서 개발환경을 가꾸어 나가는 여정에 함께하고 싶으신가요? Frontend Platform Engineer나 Android Developer (React Native) 에 지원하시면 팀에 합류하실 수 있어요.

그러면 앞으로 토스가 보여줄 React Native 개발환경을 기대해주세요!


안녕하세요, 토스 프론트엔드 엔지니어링 헤드 박서진입니다.
토스에서는 최고의 사용자 경험이 필요한 곳은 Native, 매일매일 실험으로 제품을 개선하는 제품은 React Native/WebView로 구성하고 있어요.
토스 프론트엔드 챕터는 지난 2022년 6월부터 React Native 기술에 투자하고 있는데요. 이번 기

토스 프론트엔드 챕터는 어떻게 React Native 기술을 발전시켜 나갈 예정일까요?

토스가 꿈꾸는 React Native 기술의 미래

여러분은 AI를 업무에 얼마나 활용하고 있나요? 토스에서는 그림 그려주는 AI, 토스트(tosst) 서비스를 사내에 오픈했어요. 토스트에 정보를 입력하면 그래픽이 몇 분 만에 만들어집니다. 토스 그래픽디자이너가 만든 것과 같은 톤과 퀄리티로요.



토스가 그래픽 AI를 만들게 된 이유
토스 그래픽 디자이너들은 하루에도 수십개의 그래픽을 제작해요. 그렇게 만들어진 그래픽들은 앱 아이콘부터 콘텐츠 이미지까지, 다양한 곳에서 ‘토스다움'을 보여주는 요소로 자리하고 있죠.

문제
하지만 중요도에 비해 팀 내 그래픽 디자이너는 턱없이 부족한 상황이에요. 협업해야 하는 팀원은 100명도 훌쩍 넘는데 그래픽 디자이너는 5명뿐이다 보니 요청이 들어오는 그래픽만 그리기에도 손이 모자랐고, 새로운 컨셉을 고민할 시간은 점점 부족해졌어요. 조직 규모에 맞게 그래픽 디자이너를 끊임없이 채용하고 교육하기에도 한계는 존재했고요. 
가설
그렇다면 토스의 그래픽 톤을 이해하는 그래픽 AI가 존재한다면? 그래서 단순한 작업에서 디자이너의 리소스를 줄일 수 있다면 그래픽 디자이너들이 좀 더 깊이 있는 작업에 뇌와 손을 쓸 수 있지 않을까? 토스의 그래픽 AI 프로젝트는 이 질문에서 시작됐어요.
해결
Step 1. 토스의 그래픽 톤 정의하기
스테이블 디퓨전(Stable Diffusion)을 활용해 보기로 한 뒤 가장 먼저 한 일은 ‘토스의 그래픽 톤을 정의하는 것'이었어요. 추상적으로 존재하는 토스의 그래픽 톤을 구체적으로 설명할 수 있어야 학습을 시킬 수 있기 때문이에요.
토스의 그래픽은 심플함을 위해 의미 없는 요소를 빼고 필요한 것만 남겨두지만, 요소의 부재로 그래픽의 완성도가 떨어지는 것을 막기 위해 형태와 텍스쳐의 완성도를 최대한으로 올려요. 좀 더 쉽게는 ‘가장 필요한 것만 예쁘게 남긴 상태'라고 설명할 수도 있는데요. 필요한 것만 남긴다는 것이 어떤 의미인지, 저희가 정의하는 가장 완성도 높은 형태와 텍스처는 무엇인지를 학습시켜야 한다는 결론이 나왔죠.
Step 2. 학습 리소스 만들기
토스의 모든 그래픽 자산은 소수의 그래픽 디자이너가 내부에서 제작하기 때문에 저작권에서 자유롭고, 톤도 통일되어 있어요. 이렇게 만들어져 있던 2,000여 개의 그래픽 리소스를 프롬프트*와 함께 1차로 학습시켰죠.
*프롬프트는 원하는 그래픽을 얻기 위해 AI에게 설명하는 명령어입니다. 컴퓨터와 사람이 서로 소통하는 일종의 언어라고 할 수 있어요

1차 학습이 끝난 뒤에는 기존 리소스와 겹치지 않는 리소스들을 새로 제작해 학습시키는 과정을 반복했어요. 더 좋은 퀄리티의 결과물을 내기 위해서는 절대적으로 많은 양의 그래픽을 학습시키는 것이 유리한데요. 이미 1차 학습을 마친 AI를 일부 이용해 하루 100개 이상의 그래픽을 만들고 학습시킬 수 있었어요. 특히 AI가 잘 만들어낸 것들을 여러번 학습시킬수록 정확도는 높아져 갔고요.
아래의 비교이미지처럼 학습을 통해 AI는 오브제나 인물의 형태를 더욱더 명확하게 표현하기 시작했어요. 프롬프트의 이해도도 높아졌고, 특히 버젼이 높아질수록 그래픽 톤에 대한 이해도가 높아진걸 확인할 수 있어요.

Step 3. 쉽게 이용할 수 있는 서비스로 만들기
AI를 활용할 때 프롬프트를 어떻게 쓰는지가 결과물의 퀄리티를 좌우한다는 사실, 들어보셨나요? 이미지 생성 AI도 마찬가지로 어떤 수식어를 개체의 앞에 넣는지, 뒤에 넣는지에 따라 천차만별의 결과물이 나와요. 하지만 토스트의 사용자는 생성 AI나 그래픽 디자인에는 전문 지식이 없는 사람들이기 때문에 배경지식 없이도 쉽게 이용할 수 있게 했어요. 
필수로 입력해야 하는 항목은 단 2가지인데요. 뽑고 싶은 그래픽이 어떤 타입인지 분류를 선택하고 개체를 입력하는 게 다예요. 뒷단에서는 이미지 타입에 맞는 결과물이 나오도록, 그래픽 디자이너가 찾아낸 프롬프트들을 붙여두었어요. 이 옵션값은 계속해서 추가하고 개선해 나가고 있고요. 디테일한 부분을 연구하고, 일정한 톤으로 나오도록 설정값 만드는 일은 이 분야의 전문가인 그래픽 디자이너의 역할이라고 생각한 거죠.

결과
여러분의 이해를 도울 사례를 보여드릴게요. 토스트에서 ‘통나무집’이라는 키워드를 넣고 ‘기본’, ‘동화같은’, ‘인포그래픽’ 세가지 다른 이미지 타입으로 뽑으면 아래와 같은 결과물이 나와요.

‘동화같은’ 옵션에는 creating dreamlike atmosphere, soft pastel colors등의 프롬프트가, ‘인포그래픽’ 옵션에는 catalog of, found in graphic magazine 등의 프롬프트가 들어가 있어요. 그래서 똑같이 ‘통나무집’이라는 키워드를 넣어도 원하는 타입의 결과물을 얻을 수 있죠.
적용해보기
프롬프트 Tip
AI 학습 모델에 따라 다른 결과물이 나오겠지만, 토스트를 만들며 기억에 남는 프롬프트 몇 가지가 있어요. 인물이 주인공인 그래픽을 만드는 경우, 원하는 톤을 만들기위해서는 프롬프트의 서두가 굉장히 중요한데요, 다음과 같은 몇가지의 prefix prompt(서두에 붙는 프롬프트)를 넣으면 원하는 결과에 더 가깝게 나온다는걸 알아냈어요.
Detailed realistic photography of~
다양한 인물사진을 참고하기 때문에 인물 동작의 완성도가 높아져요

Cinematic illustration of~
영화 속 장면을 참고하기 때문에 배경의 완성도가 높아져요

Pastel tone monochrome illustration of~
인물 배경까지 전체적인 컬러톤을 제어하기 좋아요

이처럼 토스에서 그래픽 디자이너의 역할은 직접 그래픽을 제작하는 것을 넘어 새로운 그래픽 톤을 정의하고, 프롬프트 연구를 통해 AI를 학습시키는 것으로까지 확장되고있어요. 
지금까지 토스가 토스트가 왜 시작됐고 어떻게 만들어졌는지 이야기 해봤는데요, 다음 아티클에서는 실제 서비스에 적용된 토스트 결과물들을 보여드릴게요.



여러분은 AI를 업무에 얼마나 활용하고 있나요? 토스에서는 그림 그려주는 AI, 토스트(tosst) 서비스를 사내에 오픈했어요. 토스트에 정보를 입력하면 그래픽이 몇 분 만에 만들어집니다. 토스 그래픽디자이너가 만든 것과 같은 톤과 퀄리티로요.



토스가 그래픽 AI를 만들게 된 이유
토스 그래픽 디자이너들은 하루에도 