토스 피플 #1: 잘 알려지지 않은 새로운 직군들
토스 커뮤니티 구성원은 어떤 길을 따라 토스에 도착했을까요? <토스 피플: 토스에 없던 직무를 만든 사람들> 시리즈에서는 토스에 색다른 직무를 맡아 직접 커리어를 개척해 나간 분들의 이야기를 들려드려요. 고민이 있는 모든 직장인에게 도움이 되길 바랍니다.

오늘은 토스에서 Employer Branding Manager로 근무하고 있는 차지현님의 인터뷰를 공유드려요. 지현님은 토스 테크 직군의 채용 브랜딩을 위해 SLASH 개발자 컨퍼런스, 지금 읽고 있는 토스 테크 블로그와 같은 다양한 업무를 담당하고 있어요.  개발자로써 “토스에 지원해보고 싶다”라고 생각해봤다면, 보이지 않는 곳에서 지현님이 기울이시는 노력이 영향을 미쳤을 가능성이 높아요.
SLASH와 같은 큼직한 프로젝트를 기획할 때 지현님은 수십 명의 개발자, 테크 헤드, 채용팀과 브랜드커뮤니케이션팀 등 토스 내 여러 유관부서 팀원, 그리고 대행사 구성원과 협업하는데요. 지현님은 명확한 프로젝트 일정과 요구사항 정리는 물론, 어떤 일을 누구에게 언제까지 맡길지 정확히 파악하고 있는 능력을 갖고 계세요.
하지만 지금의 지현님이 있기 전에는 과거의 지현님이 있었는데요. 오늘은 토스에서 처음으로 Employer Branding Manager를 담당하신 지현님의 커리어 이야기를 나눠드려요.



지현님은 토스에 Employer Branding Manager로 입사하셨나요?
아니요. 처음에는 토스 CX 채용을 담당했어요. 이때가 제 커리어 맵에서 아직까지도 가장 높게 평가한 시기인데요. 일단 제가 굉장히 많은 것을 주도적으로 진행할 수 있었어요. 운 좋게도 딱 토스에서 CX 계열사가 분리되는 시점에 입사해서 채용부터 입사 예정자 온보딩까지 CX 채용 프로세스를 처음부터 만들 수 있는 기회였어요.
토스씨엑스 채용을 약 10개월정도 경험하고, 토스의 다양한 엔지니어 직군을 채용하기 위해 테크 채용팀으로 이동하게 되었어요.

테크 채용팀에 합류하고서는 어떤 업무를 담당하셨나요?
테크 채용 팀에 합류하고 나서, 직무별 밋업(meet-up)이나 직무 관련 콘텐츠 작성, 집중채용 같은 채용 이벤트를 많이 진행했는데요. 그 중에는 특정 팀을 더 잘 알리는 일이나, 지원을 망설이는 잠재 후보자의 인게이지먼트를 높이는 브랜딩 액션도 다수 있었어요.
토스 개발자 컨퍼런스 SLASH22의 PM도 맡게 되었는데요, 이런 브랜딩 프로젝트의 경우 생각보다 많은 이해관계자를 설득하고, 조율하고, 여러가지 일을 멀티태스킹 해야 한다는 것을 알게 되었어요. 디자이너, 개발자, 영상 PD, 콘텐츠 매니저, 홍보팀, 개인정보 보호팀, 리걸팀, 재무팀, HRBP, 보상팀 등 수많은 분들과 일하다 보니, 신뢰를 얻은 소수의 인원이 프로세스를 구축하고 타임라인을 잘 세워 프로젝트를 리딩하는 것이 필수적이라는 것도 배우게 되었고요.
그런데 저는 이 모든 일이 처음이었어요. 누군가가 길을 닦아 놓았던 상황도 아니라서, 이 환경에 적응하고 문제를 해결해 나가는 과정이 제게는 너무 벅찼던 것 같아요. 이를테면 의견을 어디서부터 어떻게 모아야 하는지, 특정 문제가 생기면 누구에게 이야기해서 해결해야 하는지, 어떤 사람에게 어떤 일을 맡겨야 성공적으로 마무리될 수 있는지를 모두 몰랐거든요. 이 과정을 겪으면서 많이 지치기도 했고, “내가 할 수 있는 일이 맞나?” 에 대해서도 고민하며 제 역량도 많이 의심했던 시기인 것 같아요.

지금의 척척박사 지현님 모습이랑 너무 다르네요! 그래도 계속 브랜딩 일을 하신 이유가 있나요?
제가 이런 큰 좌절을 겪고 나서 다시는 브랜딩 일을 안 하겠다고 선언했어요. 너무 크게 데인 거죠. 한 동안은 브랜딩의 ‘ㅂ’도 쳐다보기 싫었어요. 근데 팀에서 꾸준히 브랜딩에 대한 요구가 있었고 4~5개월 지나니까 기억이 미화되기 시작하더라고요(웃음).
어쨌든 채용 브랜딩은 팀에서 필요로 하는 일이고, 나를 대신할 사람이 없다는 생각이 들었어요. 제가 좋아하는 행사 기획과 교육을 동시에 할 수 있는 일이기도 하고요. 팀 리더분께서 감사하게도 새로운 직무를 시작할 수 있는 기회를 주셨고, 그렇게 ‘채용브랜딩 담당자’ 라는 직무로 전환을 하게 되었죠.

이때 본격적으로 Employer Branding Manager이라는 직무를 맡게 됐는데, 어떤 어려움이 있었나요?
회사에 없던 직무를 만든거니까 처음에 굉장히 혼란스러웠어요. 직무를 혼자 정의하고 직무의 성과는 뭐고 성공은 어떻게 생겼는지 고민을 많이 했어요. 무슨 일을 해도 “과연 이게 임팩트있는 일인가?”라는 의문도 들었고요. 그래도 꾸준히 시스템을 만들고 업무를 하다 보니 도와주시는 분들도 생겼어요.
2024년을 기점으로 제 직무가 더 명확해진 느낌이에요. 미션을 “토스로의 지원에 관심을 가지지 않았던 엔지니어가 꼭 지원하고 싶은 회사가 되게 만들기”로 잡았는데요. 미션 달성을 위해 테크 블로그 활성화, SLASH24 준비, LIVE JD 제작, 기술 토크쇼 콘텐츠 제작, 엔지니어링 공개채용 등을 준비하고 있어요. 앞으로도 데이터를 더 기민하게 트래킹하면서, 많은 분들이 토스라는 회사를 ‘일해보고 싶은 곳’ 으로 기억할 수 있도록 만들어 나가고 싶어요. 대한민국의 엔지니어 100%가 토스에 지원하는 그 날까지 달릴 거예요.


업무의 기준을 만든다는 건 정말 쉽지 않은데 대단하세요. 지현님처럼 회사에 아예 새로운 직무를 만들고 싶은 분들에게 해주실 조언이 있을까요?
새로운 직무에 열려있는 토스에 오세요(웃음)! 장난이고요. 저도 새로운 직무를 만들어야겠다고 시작한 건 아니었기에, ‘새로운 직무’ 에 포커스 하시기 보다는 ‘팀 내에서 꼭 필요한 일’과 ‘내가 잘할 수 있는 일’의 교집합을 찾는 게 중요하다는 말씀을 드리고 싶어요. 그리고 그 교집합이 지금 정의된 직무에서 하기 어려운 일이라면, 회사의 유연성을 믿고 과감히 요청해보세요. 회사에서도 꼭 필요한 일이라는 점에 공감한다면, 여러분의 역량 성장을 적극 지원할 거예요.

토스 오시기 전에도 브랜딩 같은 업무에 관심이 있었나요?
일단 대학교에서 저는 두 가지 관심사가 있다는 것을 확실히 알게됐어요.
첫 번째는 교육인데요. 이건 고등학교 때부터 알았어요. 고등학교 시절, 내신 보기 전에 친구들이 모르는 거 물어보면 답변을 해주고 문제 풀이를 설명해준 기억이 있어요. 미니 세션이나 오답노트를 공유하기도 했고요. 9등급 친구랑 꾸준히 같이 공부했더니, 결국 그 친구 성적이 5등급까지 올라와서 엄청난 성취감과 희열을 느꼈죠. 저는 퇴사하면 학원 강사를 하고 싶어요. 대치동의 일타 강사를 꿈꾸고 있어요(웃음).
제 두 번째 관심사는 행사 기획이에요. 대학교에서 중고등학생들을 위한 대회를 주최하는 활동을 했었어요. 논문 대회, 토론 대회 같은 거요. 이런 큰 행사를 기획할 때는 커뮤니케이션 포인트가 굉장히 많고 멀티 태스킹이 필수인데, 그런 게 너무 재밌었어요. 여러 사람과 접점을 만들어서 일을 하고, 이 조각조각들이 하나로 어떻게 완성될지 상상하고 기획하는 게 재밌었어요.
제 두 관심사가 겹치는 곳이 브랜딩이라는 것을 다양한 커리어 경험을 통해서 알게 됐고요.



어떤 경험이 지금의 커리어를 꿈꾸는데 도움이 되셨나요?
저는 처음에 화장품 회사의 조직문화 및 복지 팀에 입사했어요. 감사하게도 첫 직장임에도 불구하고 팀의 배려와 응원으로 많은 시도를 해볼 수 있었던 환경이었어요. 
기억에 남는 건 창립기념일 행사의 애프터 파티를 기획한 경험이에요. 회사의 생일을 축하하는 자리인만큼 모든 구성원이 모인 자리에서 그간 이뤄온 성과를 모두가 같이 축하하고 기억하는 자리가 필요하다고 생각했어요. 회사 창립 이후로 발행된 모든 광고 캠페인을 찾아서, 컬러를 입히고, 인쇄해서 전시했어요. 야외에서 맥주를 마실 수 있는 곳도 만들고요. 
그 외에도 임직원 교육 프로그램 등 다양한 조직문화 관련 업무를 담당하면서 제가 중요하게 생각한 교육과 행사 기획을 접목할 기회가 많았어요. 하지만 한편으로는 성과를 정성적으로 판단해야 하는 부분이 많아 정량적인 성과로 저의 역량을 측정해 보고 싶었어요. 

이런 경험을 바탕으로 채용을 시작하셨군요! 커리어 맵에 “채용이라는 새로운 세계”는 왜 낮게 평가하셨나요?
다음으로는 외국계 IT 회사의 채용팀 인턴으로 들어갔어요. 근데 아쉽게도 채용이 필요한 직무가 시니어리티가 높은 편이라, 이벤트 형태의 채용보다는 아웃바운드 형태의 리드 발굴과 콜드콜이 주요 업무였어요. 이 때 저는 프로젝트 형태로 문제를 발굴하고, 액션 플랜을 세우는 기획형 업무가 잘 맞다는 것을 알게 되었죠. 더 다이내믹한 채용을 하고 싶었거든요. 인턴이 끝날 때 쯤 제가 권한을 가지고 주도적으로 일 할 수 있는 환경을 찾고 싶다는 생각을 다시 하게 됐어요.
그래도 이 경험을 통해서 ‘채용’이라는 직무가 얼마나 매력적인지 알게 된 것 같아요. 채용해야 하는 직무의 특성을 파악하고, 후보자들을 설득하려면 어떤 점을 노출해야 하는지 전략적으로 고민하는 방법을 배웠거든요.

오늘 소중한 시간을 내주셔서 오랜만에 커리어를 뒤돌아 보셨는데 어떠셨나요?
일을 하다 보면, 하고 싶은 일을 찾아서 하는 경우도 있지만 관성적으로 해야 하는 일, 하던 일을 계속 해야 하는 상황도 있잖아요. 이번 인터뷰를 통해서 제가 어떤 일에 관심있고 가치를 느끼는지 다시 한 번 생각해 볼 수 있었어요. 앞으로 또 어떤 도전을 하게 될지 아직은 모르지만, ‘도움을 필요로 하는 사람에게 적절한 도움’을 제공하고 싶어요.

마지막으로 5년 전 나에게 조언을 할 수 있다면 어떤 얘기를 하고 싶으신가요?
제가 커리어를 딱 시작하는 시점인 것 같은데요, ‘동료들의 신뢰를 얻기까지는 시간과 노력이 필요하니, 너무 조급해 하지 말아라’는 말을 해주고 싶어요. 보통 신뢰와 라포(rapport)가 쌓여야 인정을 받잖아요. 근데 커리어를 막 시작할 때는 아직 한 번도 성공 경험이 없는데, 동료들이 저를 인정해주기를 바랬어요. 제 생각대로 풀리지 않는 일이 있을 때에는 자책도 많이 하고요. 그런데 꾸준히 작은 성공을 모으면 동료들의 신뢰도 얻고, 일도 더 편해진다고 이야기 하고 싶네요! 


토스 피플 #1: 잘 알려지지 않은 새로운 직군들
토스 커뮤니티 구성원은 어떤 길을 따라 토스에 도착했을까요? <토스 피플: 토스에 없던 직무를 만든 사람들> 시리즈에서는 토스에 색다른 직무를 맡아 직접 커리어를 개척해 나간 분들의 이야기를 들려드려요. 고민이 있는 모든 직장인에게 도움이 되길 바랍니다.

오늘은 토스에서

토스 커뮤니티 구성원은 어떤 길을 따라 토스에 도착했을까요? 오늘은 SLASH 개발자 컨퍼런스, 지금 읽고 있는 토스 테크 블로그와 같은 업무를 담당하는 Employer Branding Manager 차지현님의 인터뷰를 공유드려요. 

토스 피플 #1: 테크 채용 브랜딩의 새로운 기준

안녕하세요, 토스 코어 Teens Growth Silo의 서버 개발자 조민규입니다. 

서비스를 개발하다 보면 클라이언트의 호출에 의한 에러가 발생합니다. 클라이언트는 반환된 에러 메시지를 통해 발생 원인을 파악하고 해결할 수 있어야 하는데, 대부분의 경우 오류 메시지가 불친절하거나 혹은 보안적 이슈로 추상화되어 본질적인

LLM으로 에러 원인 분석과 해결 방안 제시까지 자동화하고, 팀의 생산성을 향상시킨 이야기를 들려드립니다.

Flowise와 LLM을 활용한 에러 분석 자동화


빠르게 쌓이는 PR, 느리게 달리는 리뷰. 결국 남는 건 LGTM(Looks Good To Me)뿐이라면?
이번 모닥불에서는 토스 프론트엔드 챕터가 어떻게 코드 리뷰 문화를 활성화했는지 알려드릴게요.
‘고맥락자 코드 리뷰’ 부터 ‘코드스멜 워킹그룹’, ‘가독성 위원회’ 그리고 ‘코드 리뷰 배틀’ 까지
실전에 적용해 볼 수 있는 다양한 코드 리뷰 꿀팁들, 지금 바로 공개합니다!

타임스탬프
00:00 인트로
01:40 코드 리뷰, 왜 필요한가요?
02:22 저맥락자 vs 고맥락자 리뷰
08:56 코드 스멜 워킹그룹 그리고 가독성 위원회
11:20 좋은 코드의 4가지 기준!
14:29 코드 리뷰 배틀 Ssul

출연진
박서진, 토스 Head of Frontend
진유림, 토스 Frontend Developer
전환오, 토스 Frontend Developer

Frontend Fundamentals
; 변경하기 쉬운 프론트엔드 코드를 위한 지침서
👉바로가기: https://frontend-fundamentals.com

다른 모닥불 회차 보러가기
EP.10 캠프파이어 특집 상편 | 무엇이든 물어보세요 (feat. 프론트엔드 코드, 디렉토리 관리)
EP.10 캠프파이어 특집 하편 | 무엇이든 물어보세요 (feat. 테스트 코드, ESLint Rule)
EP.11 토스의 디자인 편집기 ‘데우스’, 이렇게 만들었어요!




빠르게 쌓이는 PR, 느리게 달리는 리뷰. 결국 남는 건 LGTM(Looks Good To Me)뿐이라면?
이번 모닥불에서는 토스 프론트엔드 챕터가 어떻게 코드 리뷰 문화를 활성화했는지 알려드릴게요.
‘고맥락자 코드 리뷰’ 부터 ‘코드스멜 워킹그룹’, ‘가독성 위원회’ 그리고 ‘코드 리뷰 배틀’ 까지
실전에 적용해 볼 

이번 모닥불에서는 토스 프론트엔드 챕터가 어떻게 코드 리뷰 문화를 활성화했는지 알려드릴게요.

‘고맥락자 코드 리뷰’ 부터 ‘코드스멜 워킹그룹’, ‘가독성 위원회’ 그리고 ‘코드 리뷰 배틀’ 까지실전에 적용해 볼 수 있는 다양한 코드 리뷰 꿀팁들, 지금 바로 공개합니다!

코드 리뷰할 시간이 어딨어요? 모닥불 | EP.12

AI 시대에 디자이너는 어떤 모습일까요?
한번 쯤 이런 생각 해보지 않으셨나요? UI가 더 이상 필요 없어지거나, 로봇이 모든 일을 대신하는 날이 오면, 디자이너는 어떤 역할을 하게 될까?
저도 같은 고민을 하다가 반대로 생각해 보기로 했어요. 언젠가 사라질 운명이라면, 차라리 그 미래를 앞당겨서 직접 경험해보기로요. “미래를 예측하는 가장 좋은 방법은 미래를 만드는 것이다”라는 말도 있잖아요.
그래서 조금 파격적인 목표를 세웠어요. 
바로 ‘디자이너 없애기’
제가 팀에서 빠지더라도 아무 문제 없이 돌아가는 시스템을 만들어보는 실험이었어요.
어떻게 했을까요?


반복되는 작업을 '규칙'으로 정의하기
저는 제휴를 맺은 회사들과 돈을 주고받는 정산 업무를 맡고 있는 팀에 있었어요. 문제는, 회사마다 수수료 계산 방식이 모두 달라서 매번 비슷한 일을 반복해야 했다는 거예요. 팀 인원이 아무리 많아도 일손이 부족한 구조였어요.
그래서 생각했죠.
"매번 다른 방법으로 하지 말고, 공통된 규칙을 찾아보면 어떨까?"
예를 들어, 어떤 제휴사는 사용자가 토스를 통해 대출을 많이 받으면 더 많은 수수료를 지급하고, 덜 이용하면 적은 수수료를 주는 구조였어요. 이런 유사한 계약들을 묶어 ‘구간별 수수료율’이라는 하나의 규칙으로 정리했더니, 여러 회사의 정산을 모두 같은 방식으로 처리할 수 있게 됐어요.
이런 식으로 복잡한 계약들을 표 하나로 정리하면서, 매번 새로 디자인하지 않아도 되는 구조 가 만들어졌어요. 이 시스템이 없었다면 지금도 저는 비슷한 화면 수백 장을 계속 만들고 있었을지도 몰라요.


규칙을 시스템화 하기
규칙을 만든지 반년쯤 지난 어느 날, 신기한 광경을 목격했어요. 프론트엔드 개발자가 저 없이도 UI를 만들고 있는 거예요. 디자인에 관심이 있는 개발자이기도 했지만, 디자이너 없이 돌아가는 시스템을 만들었다는 작은 성공의 신호였던 것 같아요. 물론 제가 디자인하는 시간도 매우 줄어들었고요. 
제가 생각한 다음 단계는 스펙을 작성하는 것조차 없애는 것이었어요. 보통 디자인하기 전에 제품의 요구조건 문서를 만들잖아요. 이것도 시스템화 할 수 있을 것 같았어요. 정산 서비스를 요청하는 임직원이 몇 가지 설문에만 답하면 그 정보를 토대로 UI가 자동 생성되도록 매핑 시스템을 만들었죠. 완전히 자동화되진 않았지만, 어시스턴트 디자이너 혼자 작업할 수 있을 만큼은 되더라고요.
이쯤 되니 진짜로 ‘디자이너를 없앤다’는 실험이 현실이 되어가고 있다는 느낌이 들었어요.


시스템을 AI 한테 맡기기
누구나 디자인할 수 있는 시스템을 갖추고 나니, ‘이 시스템을 돌리는 주체가 꼭 사람이어야 할까?’ 라는 생각이 들었어요. 지금은 AI가 MCP(Model Context Protocol - AI와 제품이 소통할 수 있는 표준화된 소통 체계)를 통해 디자인 툴을 다루는 시대잖아요. 게다가 토스에서는 직접 디자인툴을 만들어 사용하기 때문에 어떠한 제약도 없이 다양한 시도를 해볼 수 있어요. 
아직은 바로 사용할 만한 수준의 화면을 만들지는 못하지만, 괜찮은 시스템이 정의되어 있다면 AI는 꽤 준수한 결과물을 만들어내더라고요. 그래서 앞으로 사람은 모두 시스템을 만들고, AI가 그 시스템을 활용해 제품을 만들게 되는 날이 올 것이라고 생각했어요.


디자이너, 이제는 시스템을 설계하는 사람
처음엔 내가 필요 없을 정도로 잘 작동하는 시스템을 만든다는 게 두렵기도 했어요. 하지만 역설적으로, 그렇게 해보니까 디자이너가 할 수 있는 더 본질적이고 가치 있는 일들이 보이기 시작했죠.
이제는 누구나 UI를 만들 수 있는 시대예요. 우리가 지금 ‘UX 디자인’이라고 부르는 일도 머지않아 버튼 하나 그리는 것처럼 간단한 작업이 될지도 몰라요. 디자이너가 오랜 시간 고민하던 일들도 더 이상 우리의 고유 영역이 아닐 수 있죠.
그렇기 때문에, 앞으로 디자이너의 역할은 직접 디자인하는 것이 아니라 AI가 나보다 더 뛰어난 결과물을 만들 수 있도록 원칙과 시스템을 설계하는 것이라고 생각해요.
즉, 하나의 일을 잘 해내는 사람보다,누구라도 제품을 만들 수 있게 틀을 만들 수 있게, ‘시스템적 사고’를 갖춘 디자이너가 필요한 시대가 오고 있는 거예요.


조직의 러닝이 순환되는 구조 만들기
이건 저의 사례일 뿐이고, 토스엔 이런 경험을 하고 있는 동료들이 많아요. 이런 노하우를 서로 빠르게 공유하고, 챕터 차원에서 러닝이 축적되는 조직을 만들고 싶었어요.
예전에 저는 ‘그룹 권한’ 기능 없이 제품을 설계했다가, 나중에 꼭 필요한 상황이 생기면서 서버 구조까지 갈아엎는 큰 비용을 치른 적이 있어요. 당시엔 초기 제품이라 단순하게 시작하고 싶었고, 필요 없을 거라 판단했었거든요. 돌아보면, 제가 토스 안의 더 고도화된 계정 체계를 알고만 있었더라도 ‘그룹 권한’은 반드시 필요해질 기능이라는 걸 미리 예측할 수 있었을 거예요.
그래서 다른 사람들은 비슷한 실수를 반복하지 않고, 이런 노하우를 더 빠르게 습득할 수 있으면 좋겠다는 생각이 들었어요. 사실 계정 권한 같은 구조를 직접 설계해본 디자이너는 많지 않잖아요. 디자이너는 예상보다 자주, 처음 해보는 구조나 흐름을 직접 정의해야 하는 상황을 마주하게 돼요. 데이터 CRUD(Create, Read, Update, Delete)는 어떤 방식으로 구현하는 게 최선일지, 앱 미리보기는 어디에, 어떻게 노출하는 게 좋을지 등도 그렇죠. 그래서 저는 이런 러닝들이 잘 축적되고 공유되는 조직을 만들고 싶었어요.
이제는 작은 단위의 디자인 시스템을 넘어, 챕터 전체가 중요한 의사결정이나 노하우를 공유할 수 있는 'UX 시스템'이 필요하다고 생각했어요. 이를 통해 우리 각자의 러닝이 단순히 공유되는 것을 넘어서, 계속 누적되어 성장하는 사이클을 만드는 것이 올해의 목표예요.


토스가 툴을 직접 만드는 이유
이런 시스템을 잘 구축하려면, 비슷한 고민과 목표를 가진 사람들이 모여 다양한 제품을 함께 만들어갈 수 있는 환경이 꼭 필요해요. 토스는 구성원 모두가 최고의 효율을 낼 수 있도록, 우리가 일하는 방식에 딱 맞는 각종 툴을 직접 만들고 있어요. 어떤 툴을 쓰느냐는 곧 우리의 일하는 방식과 생산성을 좌우하니까요. 게다가 토스는 금융 기업이라 고객 데이터를 외부에 맡길 수 없는 환경적인 제약도 있어요. 이런 이유들로 자연스럽게 내부에서 필요한 툴을 직접 개발하는 문화가 자리 잡았고, 이 툴들은 전담 역할인 Product Designer (Tools)가 만들고 있어요.
만드는 툴의 범위도 정말 상상 이상인데요. 데이터 분석 툴, 디자인 툴 리스크 모니터링 툴, 검토 프로세스 툴, 상담 관리 툴, 광고 관리 툴, 쇼핑 상품 관리 툴, 정산 툴, 컴플라이언스 툴, 업무 자동화 툴, 리서치 자동화 툴 등 생산성 툴만 수십가지가 있으며 계속 늘어나고 있어요. 
가끔은 솔직히 ‘다른 회사처럼 SaaS 툴 사서 쓰면 편할텐데’라는 생각도 들어요. 그 많은 기능을 새로 다 만드는 게 엄청 챌린징하거든요. 근데 이런 환경 덕분에 우리가 일하는 방식에 맞게 최적화할 수 있고, 필요한 기능은 빠르게 구현할 수도 있어요. 덕분에 디자이너들은 더 생산성이 높아져 이전엔 한 명이 하지 못했을 더 큰 시스템을 만들어가고 있어요.


마치며
이미 토스에서는 AI가 디자인한 화면이 실제 제품에 쓰이기 시작했어요. 아직은 디자이너의 손길이 필요하지만, 조만간 디자이너 없이도 충분히 좋은 결과물이 나오는 날이 오겠죠.
그렇게 되면 우리의 역할은 분명 달라질 거예요. 디자인을 만드는 사람이 아니라, AI가 더 뛰어난 디자인을 만들도록 원칙과 시스템을 만드는 사람이 되는 거죠.

여러분은 ‘디자이너가 디자인을 하지 않는 시대'에 어떻게 가치를 만들 수 있을 것 같나요?
AI가 모두 대신할 때, 디자이너로서 당신은 무엇을 하고 있을까요?








AI 시대에 디자이너는 어떤 모습일까요?
한번 쯤 이런 생각 해보지 않으셨나요? UI가 더 이상 필요 없어지거나, 로봇이 모든 일을 대신하는 날이 오면, 디자이너는 어떤 역할을 하게 될까?
저도 같은 고민을 하다가 반대로 생각해 보기로 했어요. 언젠가 사라질 운명이라면, 차라리 그 미래를 앞당겨서 직접 경험해보기로요. “

아티클 시리즈