디자이너는 코드를 어디까지 배워야 할까: 아직 안 해본 사람이 그은 경계선

바이브코딩이 BX 디자이너의 실행 범위를 어떻게 넓히는지, 개발 리터러시와 협업 경계를 프로젝트 경험으로 분석합니다.

디자이너가 코드를 짜야 할까요? 솔직히 처음 이 질문을 마주쳤을 때 저는 반사적으로 "그건 개발자 일이지"라고 생각했습니다. 그런데 실제로 창립기념 프로젝트를 진행하면서, 캐릭터 세계관을 이미지에서 영상 시퀀스까지 혼자 밀어붙이다 보니 그 경계가 생각보다 훨씬 흐릿하
다는 걸 체감했습니다. 바이브코딩이라는 개념이 BX 디자이너에게 실제로 어떤 의미인지, 직접 부딪히며 정리해봤습니다.

먼저 밝혀둡니다. 저는 아직 코드를 직접 짜본 적이 없습니다. 이 글은 "이렇게 하면 된다"가 아니라, 개발 쪽으로 넘어가려는 디자이너가 어디까지 배우고 어디서 멈출지 선을 그어본 기록입니다.

BX 디자이너의 바이브코딩 작업 흐름

 

 

 

왜 이 질문이 생겼나

제가 코드에 관심을 갖게 된 건 회사에서 시켜서가 아닙니다. 채용 공고와 팀 구성이 바뀌는 걸 보면서였습니다.

디자인과 개발의 경계가 눈에 띄게 희미해지고 있습니다. 요즘 회사가 찾는 인재상은 자기 영역만 잘하는 사람이 아니라 서로의 스콥을 넘나들 수 있는 사람입니다. 디자이너 공고에 개발 관련 문장이 붙고, 개발자 공고에 디자인 감각이 언급됩니다.

그래서 질문이 생겼습니다. 넘나든다는 게 정확히 어디까지를 말하는 걸까. 이걸 정하지 않으면 둘 다 어중간해집니다.

안 해본 사람이 이 글을 쓰는 이유

해본 사람의 글은 이미 많습니다. 그런데 그 글들은 대개 이미 넘어간 사람의 관점입니다. 배우고 나서 돌아보면 "생각보다 쉽다"가 되기 쉽습니다.

저는 아직 안 넘어갔습니다. 그래서 넘어가기 전에 무엇이 두렵고 무엇이 필요해 보이는지가 지금은 선명합니다. 이건 배우고 나면 사라지는 감각입니다. 사라지기 전에 적어둡니다.

 

 

경계가 희미해진다는 말은 아무 데나 가도 된다는 뜻이 아닙니다.

 

 

인터랙션은 정지된 화면에서 판단이 안 됩니다.

 

 

배우려는 것 — 버튼 하나가 온에어되기까지

구체적으로 배우고 싶은 게 있습니다. 거창한 게 아닙니다.

CTA 버튼 디자인을 바로 온에어할 수 있는 3~4줄짜리 코드입니다.

왜 하필 버튼인가

버튼은 디자이너가 가장 자주 만들고 가장 자주 수정하는 요소입니다. 그런데 만드는 건 제가 하는데 화면에 올리는 건 제가 못 합니다.

색을 반 톤만 바꾸고 싶어도, 호버 인터랙션을 조금 다르게 하고 싶어도 요청을 넣고 기다려야 합니다. 개발자 입장에서는 우선순위가 낮은 요청이고, 저는 그 대기 시간 동안 다음 작업으로 넘어갑니다. 돌아왔을 때는 제가 왜 그렇게 하려 했는지 감각이 흐려져 있습니다.

속도가 아니라 감각의 문제입니다

3~4줄을 익혀서 얻는 게 시간 절약이라고 생각하지 않습니다. 만든 직후에 바로 확인할 수 있다는 것이 더 큽니다.

인터랙션은 정지된 화면에서 판단이 안 됩니다. 실제로 눌러보고 움직이는 걸 봐야 빠른지 느린지 알 수 있습니다. 그 확인을 남의 일정에 맡기면 판단이 매번 며칠씩 밀립니다.

그래서 제가 원하는 건 개발 능력이 아니라 내 판단을 즉시 검증할 수 있는 최소한의 손입니다.

 

실행범위 : 디자이너의 손이 닿는 곳이 달라지고 있다

일반적으로 디자이너의 결과물은 피그마 파일이나 시안 이미지라고 알려져 있습니다.

발표 자리에서 정적인 화면을 넘기며 "이 버튼을 누르면 이런 반응이 나옵니다"라고 설명하는 게 오랜 관행이었죠.

그런데 제 경험상 이건 점점 설득력을 잃고 있습니다.

바이브코딩(Vibe Coding)이란 자연어 프롬프트로 AI에게 코드 작성을 지시해 비개발자도 작동하는 프로토타입을 빠르게 만드는 방식을 뜻합니다. 쉽게 말해 "이런 기능을 만들어줘"라고 말하면 AI가 실제로 돌아가는 화면을 뚝딱 만들어주는 것입니다. 덕분에 디자이너가 제안할 수 있는 범위가 정적인 시안에서 인터랙티브 프로토타입, 브랜드 아카이브, 데이터 시각화까지 넓어졌습니다.

저도 비슷한 변화를 실감했습니다. 창립기념 프로젝트에서 캐릭터가 별을 관측하고 흩어진 별들이 하나의 별자리로 완성되는 세계관을 구성했는데, 과거라면 키비주얼과 응용 그래픽 몇 장으로 마무리됐을 작업이었습니다. 이번엔 정지 이미지, 영상 시퀀스, 공간 배경, 타이틀 모션, 피켓 디자인까지 제가 직접 연결해야 했습니다. 생성형 AI 도구를 활용하니 장면 검토 속도가 빨라지긴 했지만, 문제는 전혀 다른 곳에서 생겼습니다.

정지 이미지에서 유지되던 캐릭터 외형이 영상 전환에서 틀어지고, 장면마다 별자리 형태와 광원 방향이 달라지는 오류가 반복된 겁니다. 그 시점에서 저는 프롬프트 엔지니어링(Prompt Engineering), 즉 AI에게 작업 의도를 명확하게 전달하는 언어 설계 방식이 단순한 텍스트 입력과는 다른 작업임을 깨달았습니다.

 

캐릭터 정체성, 컬러 시스템, 카메라 시점, 금지 오브제를 고정값으로 따로 관리하고, 장면마다 변동값을 구분해 입력하기 시작하면서 결과물의 일관성이 눈에 띄게 달라졌습니다.

브랜드디자인 관점에서 이 변화가 중요한 이유는 제안 방식 자체가 달라지기 때문입니다. 브랜드 아이덴티티(Brand Identity), 즉 로고·컬러·서체로 구성된 시각적 정체성 시스템이 더 이상 정적인 문서로만 전달되지 않습니다. 사용자가 클릭하고 이동하며 반응을 경험하는 움직이는 브랜드 언어로 확장되고 있고(출처: 플러스엑스 브런치), 그 언어를 설계하는 사람이 디자이너입니다.

 

• 브랜드가 적용된 인터랙티브 웹 경험
• 캠페인용 인터랙션 및 참여형 콘텐츠
• 브랜드 세계관을 탐색하는 디지털 아카이브
• 움직이는 디자인 시스템과 모션 가이드
• 사내 브랜드 에셋 운영 도구

 

 

 

 

 

개발리터러시와 조직시스템 : 혼자 잘하는 것은 절반짜리 답이다

바이브코딩으로 화면을 빠르게 만들 수 있다고 해서 그게 바로 서비스가 되진 않습니다. 이 부분은 경험해보지 않으면 과소평가하기 쉬운 영역입니다. 실제 서비스에는 데이터베이스, 백엔드 API, 인증 체계, 서버 배포 환경이 필요하고, 운영 단계에서는 보안 패치와 캐시 관리까지 따라옵니다. 디자이너가 이 모든 것을 직접 다뤄야 한다는 이야기가 아닙니다. 하지만 어디까지가 AI로 빠르게 검증 가능한 프로토타입이고, 어디서부터 전문 개발자의 검토가 필요한지 판단할 수 있어야 한다는 뜻입니다.

이것이 바로 개발 리터러시(Development Literacy)입니다. 여기서 개발 리터러시란 코드를 직접 짜는 능력이 아니라 기술이 어디까지 가능하고 어디서부터 위험해지는지를 판단하는 능력을 말합니다.

이미지 생성에서도 마찬가지입니다. 모델별 이미지 보존 성능, 저작권 및 초상권 위험, 해상도와 출력 환경, 영상 전환 시 캐릭터 일관성 — 이 조건들을 모르면 AI가 만들어준 결과를 무비판적으로 수용하게 됩니다. 솔직히 이건 예상 밖이었습니다. 저는 처음에 좋은 프롬프트만 쓰면 되는 줄 알았거든요.

하이엔드 스킨케어 클리니컬 화보 작업에서 이 점이 더 명확해졌습니다. 비커, 피펫, 유리관을 배치하는 것만으로는 전문적인 브랜드 이미지가 나오지 않았습니다. 제품 외관의 보존율, 포뮬러의 점도와 표면장력 표현, 유리의 굴절과 금속 반사 방향, 하이키(High-Key) 조명 — 하이키 조명이란 밝고 균일한 조명으로 그림자를 최소화하는 촬영 기법으로, 클리니컬 이미지에서 제품의 청결함과 신뢰감을 강조하는 데 자주 쓰입니다 — 이런 조건들을 구체적으로 규칙화했을 때 비로소 결과물이 달라졌습니다. 기술 리터러시는 새로운 툴을 많이 아는 능력보다 기술의 가능성과 한계를 판단하는 능력에 훨씬 가깝습니다(출처: 한국디자인진흥원).

그렇다면 개인이 이 역량을 갖추는 것으로 충분할까요? 제가 직접 써봤는데, 그렇지 않습니다. 프로젝트가 쌓일수록 제가 혼자 관리하는 프롬프트와 실패 사례는 점점 파편화됩니다. 팀원이 비슷한 작업을 새로 시작하면 처음부터 다시 시행착오를 반복합니다. 이 지점이 조직 시스템이 필요한 이유입니다.

PRD(Product Requirements Document)란 제품의 목적, 핵심 기능, 구현 범위를 정리한 요구사항 문서를 말합니다. 바이브코딩 환경에서는 AI와의 인터뷰를 통해 이 PRD를 먼저 만들고, 그것을 실제 개발의 출발점으로 삼는 방식이 결과물의 편차를 줄이는 데 효과적입니다. AI디자인에서도 이와 동일한 구조가 필요합니다. 개인이 만든 고품질 프롬프트, 영상 전환 노하우, 리터칭 기준을 개인 폴더에만 쌓아두면 조직 이동이나 퇴사와 함께 사라집니다. 그것을 브랜드별 제작 시스템과 검수 체크리스트로 구조화할 때 비로소 팀 전체의 역량이 됩니다.

 

아이디어 → 바이브코딩 프로토타입 → 조직 기준 검수 → 내부 플랫폼 등록 → 팀 공유 자산

 

 

이 흐름이 만들어지지 않으면 디자이너의 실행 범위가 넓어지는 것은 창의성 확장이 아니라 피로도와 책임의 증가로 끝날 가능성이 있습니다. 제 경험상 이 부분이 가장 조심해야 할 지점입니다.

 

 

 

 

 

섹션의 표 아래 : 캡션안 경계선을 정하는 기준은 하나였습니다. 내가 틀렸을 때 누가 수습하는가

 

 

여기부터는 선 밖입니다

반대쪽 선도 그어야 합니다. 배울 것만 정하고 안 배울 것을 안 정하면 결국 끝없이 따라가게 됩니다.

제가 선 밖으로 둔 건 이겁니다. 코드를 기획하고, 하나의 코드에 그치지 않고 응용해서 다른 산업군에까지 적용하는 능력.

이건 취미로 넘볼 영역이 아닙니다

버튼 3~4줄과 이건 성격이 완전히 다릅니다. 앞의 것은 내가 만든 걸 확인하는 손이고, 뒤의 것은 구조를 설계하는 머리입니다.

구조 설계는 왜 그렇게 짜야 하는지를 알아야 하고, 그건 실패를 여러 번 겪어야 생깁니다. 곁눈질로 몇 달 배워서 되는 게 아닙니다. 어설프게 손대면 개발자가 뒤에서 다시 짜야 합니다. 그건 도와주는 게 아니라 일을 늘리는 겁니다.

그래서 선은 이렇게 그었습니다

	배운다	안 배운다
대상	내가 만든 화면 요소	시스템 구조
목적	내 판단을 즉시 확인	제품을 만듦
범위	버튼, 색, 간격, 간단한 인터랙션	데이터, 상태 관리, 배포
실패하면	내 화면만 안 됨	남의 일이 늘어남

마지막 줄이 기준입니다. 내가 틀렸을 때 나만 손해면 배워도 되고, 남이 수습해야 하면 넘지 않습니다.

 

결론

도구는 빠르게 평준화되지만 판단은 평준화되지 않습니다. 바이브코딩도 마찬가지라고 봅니다.

지금 상태를 그대로 적자면

저는 아직 시작하지 않았습니다. 관심만 있고 손은 안 댔습니다. 이 글은 배운 사람의 결론이 아니라 배우기 직전 사람의 계획입니다.

그래도 이 선을 미리 그어두는 게 의미가 있다고 생각합니다. 경계가 희미해진다는 말은 아무 데나 가도 된다는 뜻이 아니라 각자 선을 다시 그어야 한다는 뜻이기 때문입니다. 선을 안 그으면 넘나드는 게 아니라 떠돌게 됩니다.

나중에 실제로 버튼 하나를 올려보고 나면 이 글을 다시 쓰게 될 겁니다. 그때 무엇이 틀렸는지 비교해보려고 지금 상태를 남겨둡니다.

 

 

이 글과 이어지는 내용은 AI 시대 디자이너 역할 변화, 생성형 AI 스킬 설계 방법, 피그마 AI 기능 실무 후기에 정리했습니다.

디자이너가 개발에 어디까지 들어가야 하는지 고민한 기록입니다.