한소담(Heather) - (주)GS 52g Studio, 디자인 엔지니어
"AI 시대에 디자이너는 어떻게 살아남아야 하나요?"
이 질문을 받는 디자이너들 대부분은 피그마를 더 잘 쓰거나, AI 이미지 툴을 익히는 방향으로 생각합니다. 한소담 매니저는 다른 방향으로 갔습니다. 코드를 직접 짰습니다. 개발자에게 구현을 부탁하지 않고, 기획부터 배포까지 혼자 완결하는 구조를 만들었습니다. 그 과정에서 AI는 지시를 흘려듣고, 정해둔 규칙을 어기고, 시치미를+ 떼며 변명까지 했습니다.
사람과 합을 맞춰가듯, 수많은 시행착오를 거치며 AI와 일하는 방식을 익혔습니다. 그 경험이 지금의 일하는 방식을 만들었어요.
한소담 매니저는 52g 스튜디오에서 '디자인 엔지니어'라는 직함으로 일하고 있습니다. 52g는 GS그룹의 오픈 이노베이션 조직입니다. 디자인 엔지니어라는 타이틀은 한국 기업에선 흔치 않습니다. 그녀도 작년 샌프란시스코 출장에서 Vercel을 방문하며 이 직무를 처음 접했고, 한 사람이 기획 - 디자인 - 개발을 책임지는 그 역할이 자신에게 맞는다는 걸 알았습니다.
이 직무가 매력적으로 느껴진 건, 구현 가능성에 발목 잡히는 대신 고객 접점에서 가치를 전달한다는 본질에 온전히 몰입하고, 그것을 하나의 경험으로 완성해낼 수 있다는 점이었어요. 그리고 그건 AI가 기술의 허들을 허물어줬기에 비로소 가능해진 일이었습니다.
Chapter 1. 엔지니어의 세상으로 나아가기
작년 초, 한소담 매니저는 처음으로 바이브 코딩을 시작했습니다. 계기는 불안이었습니다. 사람들이 다 좋다고 하는데 도무지 정체를 모르겠다는 불안. 디자이너로서 호기심과 불안이 섞인 감각이었어요. 이러다 정말 뒤처지겠다는 위기감에, 일단 그 정체부터 직접 파헤쳐 보기로 했습니다.
처음 만든 건 UX DAY 홈페이지였습니다. AI 기반 UI 생성 툴 v0로 시작했어요. 디자이너이기 때문에 머릿속에 이미지는 있었지만, 그 이미지를 AI에게 전달하는 방법은 의문이었어요. 피그마에서는 마우스로 끌어다 놓으면 끝날 일을, 말로 풀어야 했습니다. "오른쪽 원을 왼쪽 최상단으로, 패딩값 10으로." 디테일을 말로 옮길수록 손이 더 많이 가는 것 같았죠.
그런데도 이렇게 일하는 게 맞다는 확신이 들었어요. 자연어로 설명하면 원하는 디자인이 곧장 코드가 되어 나온다는 것. UX/UI를 디자인할 때 기술적 구현 난이도를 고려하지 않고, 오직 최적의 사용자 경험만을 위한 UX를 의도한 그대로 정확하게 구현할 수 있다는 것. 거기서 엄청난 쾌감을 느꼈습니다. 이 방향이 맞다, 더 잘해보고 싶다는 생각이 들었어요.
*v0: Vercel이 만든 AI 기반 UI 컴포넌트 생성 툴. 자연어로 설명하면 리액트 코드를 생성해준다.
하지만 진짜 벽은 그다음이었어요. 서비스에 데이터를 연동하는 단계부터 막혔습니다. 데이터베이스를 붙이려면 무엇이 필요하고 어떻게 연결해야 하는지를 몰랐기 때문이에요. API가 뭔지, 데이터베이스가 뭔지, 서버가 각각 어떤 역할을 하는지 아주 기본적인 것부터 개발자 동료들과 AI에게 물어가며 익혔어요.
개념을 다 안다고 한 번에 연동이 되는 것도 아니었어요. 성공한 화면보다 알 수 없는 오류 메시지를 마주하는 시간이 훨씬 길었습니다. 삽질에 삽질을 반복하는 동안 머릿속은 온통 '왜 안 될까, 뭐가 잘못된 걸까'로 가득 찼어요. 그렇게 매달린 끝에, 포기하지 않으면 결국 해결된다는 걸 알게 됐습니다.
"문제가 해결이 안 되니까 멈출 수가 없는 거예요. 진짜 끝장을 봐야겠다는 생각이 들었죠. 결국 됐을 때, 안 되는 게 없구나 싶었어요." - 한소담 매니저
이 경험 이후 그는 개발자의 세계를 더 깊이 들여다보고 싶어졌어요. 바이브 코딩 툴을 넘어, 할 수 있는 게 훨씬 많고 자율도도 높은 터미널 환경의 Claude Code까지 오게 된 이유예요. 처음에는 터미널의 까만 화면이 낯설었지만 이제는 익숙합니다. 확실한 베네핏의 순간을 맛보고 나니, 허들은 자연스럽게 낮아졌어요.
도구는 갖춰졌는데 새로운 문제가 생겼습니다. 작업이 복잡해질수록 AI가 요구사항이나 의도와 다르게 작동하는 경우가 부쩍 늘기 시작한 것입니다.
Chapter 2. AI와 협업하는 환경 설계하기
이미 정의된 디자인 시스템에 맞춰 화면을 만들어 달라고 지시한 작업이었습니다. 그런데 Claude는 매번 기존 시스템을 두고 새로운 디자인을 만들어냈어요. 한두 번이 아니었습니다.
Claude Code에는 claude.md라는 규칙 파일이 있습니다. 여기 적은 규칙을 최우선으로 따른다고 했어요. 그래서 디자인 시스템 규칙을 꼼꼼히 써넣었습니다. 그런데도 결과물을 받아보면 규칙은 깡그리 무시돼 있었어요. 디자인 시스템을 반영하기는커녕, 아예 새 컴포넌트를 만들어버린 겁니다. 왜 그랬냐고 묻자 돌아온 답은 이랬습니다. "빨리 만드느라 기존 것을 무시하고 새로 만들었습니다."
*claude.md: Claude Code가 작업 전에 읽는 규칙 파일. 프로젝트의 제약 조건이나 코딩 스타일을 지시할 수 있다.
*디자인 시스템(design system): 서비스 전반에 일관되게 적용되는 색상, 컴포넌트(버튼 - 내비게이션 등 UI 요소), 타이포그래피 등의 규칙을 정의한 문서.
여기서 한소담 매니저는 문제를 'AI가 말을 안 듣는다'가 아니라 '아직 함께 일하는 방법을 못 찾았다'로 봤습니다. 그래서 다시 물었어요. "이걸 방지하려면 어떻게 해야 해?" 답은 규칙을 더 강하게 적는 게 아니라, 규칙을 어길 수 없는 환경을 만드는 것이었습니다.
방식은 이렇습니다. 규칙을 텍스트로 일러주는 대신, 규칙을 어기면 다음 단계로 넘어갈 수 없도록 코드에 장치를 걸어둡니다. 디자인 시스템에 없는 컴포넌트를 만들면 검수 스크립트에 걸리고, 걸리면 Claude가 스스로 되돌아가 다시 작업합니다. 예전엔 결과물이 다 나온 뒤에야 무엇이 틀렸는지 알았지만, 이제는 작업 도중에 바로잡힙니다. 사람이든 AI든, 잘하라고 당부하는 것보다 잘할 수밖에 없는 환경에 두는 편이 낫다는 걸 그때 알았다고 합니다.
그래서 좋은 디자인 시스템이란 무엇일까요. 한소담 매니저는 따르기 쉬운 시스템이 아니라 '어기기 어려운 시스템'이라고 말합니다. AI든 사람이든 똑같아요. 규칙을 지키게 하려면 지킬 수밖에 없는 환경을 만들어야 합니다.
또 하나 알게 된 건, claude.md가 길어질수록 뒤쪽 규칙의 우선순위가 떨어진다는 점이었어요. 해법은 의외로 단순했습니다. 규칙을 파일에 다 욱여넣는 대신 "디자인 시스템은 이 링크에 있으니 이 파일을 읽어"라고만 가리킨 거죠. 사람도 긴 문서에 내용을 잔뜩 넣으면 정작 필요한 걸 못 찾는 것과 같은 이치였습니다.
그렇게 AI와 협업하는 환경이 자리를 잡을 무렵, 해커톤이 열렸습니다. 이번엔 개발자들의 세상으로 직접 뛰어들 차례였습니다.
Chapter 3. 경계없이 코드로 기여하며 협업하기
GS그룹 해커톤을 위해 기획자, 디자이너, 개발자가 함께 PRD* 생성 툴을 만드는 프로젝트가 생겼습니다. 해커톤 참가자들이 문제 정의부터 PRD 작성까지 할 수 있도록 도와주는 툴이었어요. 그런데 막상 역할을 나누려니 막막했습니다. 이제 모두가 디자인도 기획도 개발도 할 수 있는 상황이 되어버렸거든요. 원래라면 디자이너니까 디자인을 하고, 기획자니까 기획을 하는 걸로 끝날 일인데, 그게 통하지 않았습니다. 결국 뭘 하고 싶고, 어떤 것에 흥미가 있는지로 나눌 수밖에 없었어요.
*PRD(Product Requirements Document): 제품 요구 사항 정의서. 어떤 기능을 만들지, 사용자가 어떤 경험을 해야 하는지를 구체적으로 정리한 문서.
그중 한소담 매니저가 맡은 건 전반적인 UX와 프론트엔드 UI 수정이었습니다. 그러려면 깃허브를 써야 했어요. 모두가 코드로 기여하고 협업하려면, 깃허브를 통해 코드를 공유하고 그동안 개발자들만의 것이던 협업 방식과 규칙을 디자이너도 알아야 했던 거죠. 여럿이 동시에 작업하고 코드를 주고받으려면 깃허브를 거쳐야 한다는 것까진 알겠는데, 정작 어떻게 하는 건지 몰랐습니다. 개발자를 붙잡고 비장하게 말했어요. "깃허브를 배우고 싶어." 개발자로서는 어리둥절한 말이었습니다. "깃허브를 배운다는 게 도대체 무슨 얘기야?”
*깃허브(GitHub): 코드를 저장 - 공유 - 협업하는 플랫폼. 개발자들이 코드를 올리고 서로 검토하고 합치는 작업이 여기서 이루어진다.
설명을 듣고 보니 방법은 간단했습니다. 그저 낯설었을 뿐, 깃허브도 결국 작업을 공유하기 위한 협업 툴이라는 점에서 다른 협업 도구와 다르지 않았어요. 상대의 언어를 알고 나니, 그들의 세상도 그렇게 멀지 않았습니다.
그날 한소담 매니저는 처음으로 프론트엔드를 직접 수정하고, 커밋 메시지를 쓰고, 슬랙으로 "코드 올렸으니 리뷰해주세요"를 보냈습니다. 첫 PR (*Pull Request:내가 작성한 코드를 공식 버전에 합쳐달라고 팀에 요청하는 것)이었어요. 개발자 동료들은 '이제 진짜 엔지니어'로 거듭났다며 축하해줬습니다. 그렇게 낯설던 방식이 지금은 더없이 익숙한 일이 됐습니다.
Chapter 4. 더 많이 시도하고, 더 깊이 책임진다
변화는 숫자로 먼저 다가왔습니다. 손으로 UI시안을 그리면 한 시간에 하나, AI를 활용하면 한 시간에 열 개. 한소담 매니저가 직접 체감한 차이였어요.
10배의 차이는 단순히 속도의 문제가 아닙니다. 같은 시간에 열 가지 방향을 고민했다는 뜻이에요. 더 많이 시도하고, 더 빨리 틀렸음을 확인할 수 있습니다. 같은 시간에 가져오는 결과물의 개수가 달라지면, 조직에서 역량을 평가하는 방식도 달라지죠. 무엇보다 좋은 건, UX 자체를 고민할 시간이 확보됐다는 점이었어요. 구현에 매달리던 시간이 줄면서, 사용자 경험을 더 깊이 들여다보고 전보다 훨씬 많은 것을 고려할 수 있게 됐습니다.
업무 시간 자체가 크게 줄지는 않았어요. 다룰 수 있는 범위가 넓어진 만큼 하는 일도 많아졌으니까요. 달라진 건 일의 깊이였습니다. 예전에는 시안을 넘기면 개발자가 구현하는 방식이었다면, 지금은 시안을 만들고 직접 올리고 수정까지 합니다. 개입해서 판단하는 지점이 늘었고, 그만큼 결과물에 대한 책임도 커졌어요. 더 많이 시도한다는 건, 더 많이 선택한다는 뜻이기도 합니다.
덕분에 더 꼼꼼하게 챙길 수 있게 됐어요. AI에게 빠트린 시나리오가 없는지 물으면, 평소엔 놓치기 쉬운 예외 상황까지 짚어줍니다. 가령 오류 메시지가 언제 어떻게 떠야 하는 상황처럼, 혼자였다면 빠트렸을 경우의 수를 같이 챙겨주는 거죠.
이쯤 되니 이 방식은 더 이상 혼자만의 실험이 아니었습니다. 좋은 걸 알수록, 나만 알고 있기엔 아까웠어요. 남은 질문은 하나였습니다. 어떻게 하면 더 많은 디자이너가 이 경험을 함께 할 수 있을까?
Chapter 5. 조직이 움직여야 개인도 움직인다
주변 디자이너들이 바이브 코딩을 어떻게 시작하냐고 물어올 때, 한소담 매니저는 매번 모르는 것부터 그냥 물어보라고 합니다. 계속 질문하다 보면 어느새 도달하게 되거든요. 그래도 막막하면 찾아오라고, 다 알려주겠다고 하죠.
물론 이런 말을 할 수 있는 건 그녀가 속한 환경 덕분이기도 합니다. 52g는 실험이 일상인 조직입니다. 코드에 손 대도 되냐고 눈치 볼 필요가 없고, 새로운 툴을 써봤는데 망했다고 혼나지 않아요. 실패를 기록하고, 다음에 참고하는 선 순환 구조가 있습니다. 그 환경이 있었기에, 그녀는 혼자 새벽까지 붙들 수 있었고, 깃허브를 비장하게 배우겠다고 할 수도 있었어요.
가장 큰 장벽은 개인의 의지가 아니라 조직 문화라고 합니다. 코드에 손 대는 걸 허락하지 않는 조직, 기다리라고만 하는 조직. 혼자 시작한다고 되는 게 아닙니다. 먼저 써보고, 확실한 베네핏이 느껴지는 순간을 맛봐야 합니다. 그 경험을 보여줄 수 있을 때 조직도 움직입니다.
마지막으로 한소담 매니저가 겪은 이 모든 경험을 한 문장으로 표현했습니다.
"지금 느끼는 변화는 성장보다 진화에 가까워요. 성장은 더 잘하게 되는 거지만, 진화는 아예 다른 존재가 되는 거잖아요. AI가 우리 업을 진화시키고 있는 거예요." — 한소담 매니저
🖊️ Editor's Note
인터뷰 내내 그녀가 가장 많이 쓴 단어는 "왜"였어요. AI가 말을 안 들으면 왜 그럴까 묻고, 왜 안 될까 묻고, 그럼 어떻게 해야 되는지 묻고. 그 질문들이 쌓여서 하네스가 됐고, 일하는 방식이 됐어요. '좋은 시스템은 어기기 어려운 것'이라는 말이 오래 남았어요. 말로 하는 규칙은 어겨집니다. 어길 수 없는 구조를 만드는 게 진짜 설계입니다. AI한테도, 사람한테도.
'52g' 구독하기
사이트를 구독하면 새 포스트 등 최신 업데이트를 알림과 메일로 가장 먼저 받아보실 수 있습니다.
Slashpage에 가입하고 '52g'을 구독하세요!
Slashpage에 가입하고 '52g'을 구독하세요!
구독
2