티스토리 뷰
목차
디자이너가 코드를 짜야 할까요? 솔직히 처음 이 질문을 마주쳤을 때 저는 반사적으로 "그건 개발자 일이지"라고 생각했습니다. 그런데 실제로 창립기념 프로젝트를 진행하면서, 캐릭터 세계관을 이미지에서 영상 시퀀스까지 혼자 밀어붙이다 보니 그 경계가 생각보다 훨씬 흐릿하다는 걸 체감했습니다. 바이브코딩이라는 개념이 BX 디자이너에게 실제로 어떤 의미인지, 직접 부딪히며 정리해봤습니다.
실행범위 : 디자이너의 손이 닿는 곳이 달라지고 있다
일반적으로 디자이너의 결과물은 피그마 파일이나 시안 이미지라고 알려져 있습니다.
발표 자리에서 정적인 화면을 넘기며 "이 버튼을 누르면 이런 반응이 나옵니다"라고 설명하는 게 오랜 관행이었죠.
그런데 제 경험상 이건 점점 설득력을 잃고 있습니다.
바이브코딩(Vibe Coding)이란 자연어 프롬프트로 AI에게 코드 작성을 지시해 비개발자도 작동하는 프로토타입을 빠르게 만드는 방식을 뜻합니다. 쉽게 말해 "이런 기능을 만들어줘"라고 말하면 AI가 실제로 돌아가는 화면을 뚝딱 만들어주는 것입니다. 덕분에 디자이너가 제안할 수 있는 범위가 정적인 시안에서 인터랙티브 프로토타입, 브랜드 아카이브, 데이터 시각화까지 넓어졌습니다.
저도 비슷한 변화를 실감했습니다. 창립기념 프로젝트에서 캐릭터가 별을 관측하고 흩어진 별들이 하나의 별자리로 완성되는 세계관을 구성했는데, 과거라면 키비주얼과 응용 그래픽 몇 장으로 마무리됐을 작업이었습니다. 이번엔 정지 이미지, 영상 시퀀스, 공간 배경, 타이틀 모션, 피켓 디자인까지 제가 직접 연결해야 했습니다. 생성형 AI 도구를 활용하니 장면 검토 속도가 빨라지긴 했지만, 문제는 전혀 다른 곳에서 생겼습니다.
정지 이미지에서 유지되던 캐릭터 외형이 영상 전환에서 틀어지고, 장면마다 별자리 형태와 광원 방향이 달라지는 오류가 반복된 겁니다. 그 시점에서 저는 프롬프트 엔지니어링(Prompt Engineering), 즉 AI에게 작업 의도를 명확하게 전달하는 언어 설계 방식이 단순한 텍스트 입력과는 다른 작업임을 깨달았습니다.
캐릭터 정체성, 컬러 시스템, 카메라 시점, 금지 오브제를 고정값으로 따로 관리하고, 장면마다 변동값을 구분해 입력하기 시작하면서 결과물의 일관성이 눈에 띄게 달라졌습니다.
브랜드디자인 관점에서 이 변화가 중요한 이유는 제안 방식 자체가 달라지기 때문입니다. 브랜드 아이덴티티(Brand Identity), 즉 로고·컬러·서체로 구성된 시각적 정체성 시스템이 더 이상 정적인 문서로만 전달되지 않습니다. 사용자가 클릭하고 이동하며 반응을 경험하는 움직이는 브랜드 언어로 확장되고 있고(출처: 플러스엑스 브런치), 그 언어를 설계하는 사람이 디자이너입니다.
- 브랜드가 적용된 인터랙티브 웹 경험
- 캠페인용 인터랙션 및 참여형 콘텐츠
- 브랜드 세계관을 탐색하는 디지털 아카이브
- 움직이는 디자인 시스템과 모션 가이드
- 사내 브랜드 에셋 운영 도구
개발리터러시와 조직시스템 : 혼자 잘하는 것은 절반짜리 답이다
바이브코딩으로 화면을 빠르게 만들 수 있다고 해서 그게 바로 서비스가 되진 않습니다. 이 부분은 경험해보지 않으면 과소평가하기 쉬운 영역입니다. 실제 서비스에는 데이터베이스, 백엔드 API, 인증 체계, 서버 배포 환경이 필요하고, 운영 단계에서는 보안 패치와 캐시 관리까지 따라옵니다. 디자이너가 이 모든 것을 직접 다뤄야 한다는 이야기가 아닙니다. 하지만 어디까지가 AI로 빠르게 검증 가능한 프로토타입이고, 어디서부터 전문 개발자의 검토가 필요한지 판단할 수 있어야 한다는 뜻입니다.
이것이 바로 개발 리터러시(Development Literacy)입니다. 여기서 개발 리터러시란 코드를 직접 짜는 능력이 아니라 기술이 어디까지 가능하고 어디서부터 위험해지는지를 판단하는 능력을 말합니다.
이미지 생성에서도 마찬가지입니다. 모델별 이미지 보존 성능, 저작권 및 초상권 위험, 해상도와 출력 환경, 영상 전환 시 캐릭터 일관성 — 이 조건들을 모르면 AI가 만들어준 결과를 무비판적으로 수용하게 됩니다. 솔직히 이건 예상 밖이었습니다. 저는 처음에 좋은 프롬프트만 쓰면 되는 줄 알았거든요.
하이엔드 스킨케어 클리니컬 화보 작업에서 이 점이 더 명확해졌습니다. 비커, 피펫, 유리관을 배치하는 것만으로는 전문적인 브랜드 이미지가 나오지 않았습니다. 제품 외관의 보존율, 포뮬러의 점도와 표면장력 표현, 유리의 굴절과 금속 반사 방향, 하이키(High-Key) 조명 — 하이키 조명이란 밝고 균일한 조명으로 그림자를 최소화하는 촬영 기법으로, 클리니컬 이미지에서 제품의 청결함과 신뢰감을 강조하는 데 자주 쓰입니다 — 이런 조건들을 구체적으로 규칙화했을 때 비로소 결과물이 달라졌습니다. 기술 리터러시는 새로운 툴을 많이 아는 능력보다 기술의 가능성과 한계를 판단하는 능력에 훨씬 가깝습니다(출처: 한국디자인진흥원).
그렇다면 개인이 이 역량을 갖추는 것으로 충분할까요? 제가 직접 써봤는데, 그렇지 않습니다. 프로젝트가 쌓일수록 제가 혼자 관리하는 프롬프트와 실패 사례는 점점 파편화됩니다. 팀원이 비슷한 작업을 새로 시작하면 처음부터 다시 시행착오를 반복합니다. 이 지점이 조직 시스템이 필요한 이유입니다.
PRD(Product Requirements Document)란 제품의 목적, 핵심 기능, 구현 범위를 정리한 요구사항 문서를 말합니다. 바이브코딩 환경에서는 AI와의 인터뷰를 통해 이 PRD를 먼저 만들고, 그것을 실제 개발의 출발점으로 삼는 방식이 결과물의 편차를 줄이는 데 효과적입니다. AI디자인에서도 이와 동일한 구조가 필요합니다. 개인이 만든 고품질 프롬프트, 영상 전환 노하우, 리터칭 기준을 개인 폴더에만 쌓아두면 조직 이동이나 퇴사와 함께 사라집니다. 그것을 브랜드별 제작 시스템과 검수 체크리스트로 구조화할 때 비로소 팀 전체의 역량이 됩니다.
아이디어 → 바이브코딩 프로토타입 → 조직 기준 검수 → 내부 플랫폼 등록 → 팀 공유 자산
이 흐름이 만들어지지 않으면 디자이너의 실행 범위가 넓어지는 것은 창의성 확장이 아니라 피로도와 책임의 증가로 끝날 가능성이 있습니다. 제 경험상 이 부분이 가장 조심해야 할 지점입니다.
자주 묻는 질문
Q. 바이브코딩을 하려면 디자이너도 코딩을 배워야 하나요?
A. 코드를 직접 작성하는 능력보다는 판단력이 더 중요합니다. 어디까지 AI로 빠르게 검증할 수 있고, 어디서부터 개발자의 검토가 필요한지 구분할 수 있어야 합니다. 코딩 문법을 외우기보다 개발 구조의 기본 개념을 이해하는 것이 현실적인 방향입니다.
Q. AI로 이미지나 영상을 만들 때 일관성이 무너지는데 어떻게 해결하나요?
A. 일반적으로 프롬프트를 길게 쓰면 해결된다고 알려져 있지만, 제 경험상 고정값과 변동값을 분리하는 게 더 효과적입니다. 캐릭터 정체성, 컬러, 금지 요소는 고정값으로 따로 관리하고, 카메라 앵글이나 배경처럼 장면마다 달라지는 조건만 변동값으로 입력하면 세션이 바뀌어도 일관성을 유지하기 훨씬 수월해집니다.
Q. 디자이너가 AI로 실행 범위를 넓히면 업무량이 오히려 늘어나지 않나요?
A. 이 부분은 실제로 주의가 필요합니다. 생산 가능한 결과물이 많아지면 조직은 더 많은 시안과 배리에이션을 요구하는 경향이 있습니다. 프롬프트 설계, 결과물 선별, 후반 보정에 드는 시간은 잘 보이지 않기 때문에 일정과 기대치 조율을 명확히 하지 않으면 피로도만 높아질 수 있습니다.
Q. 디자인 시스템이 AI 작업에 왜 필요한가요?
A. 사람을 위한 가이드와 AI를 위한 가드레일은 다릅니다. 컬러 토큰, 타이포그래피 스케일, 생성 금지 요소, 프롬프트 템플릿처럼 AI가 반복 적용할 수 있는 구체적인 규칙이 있어야 브랜드 기준 안에서 빠르고 안정적인 결과물이 나옵니다. 감성적인 무드보드만으로는 AI가 브랜드 언어를 일관되게 유지하지 못합니다.
결론
도구는 빠르게 평준화되지만 판단은 평준화되지 않는다는 말이 이 주제를 가장 잘 요약합니다. 바이브코딩과 생성형 AI가 디자이너의 실행 범위를 넓혀주는 건 맞지만, 그것이 자동으로 좋은 결과나 건강한 업무 환경을 보장하지는 않습니다. 제가 직접 경험한 것처럼, 결과물의 완성도를 높인 건 특정 툴의 성능이 아니라 세계관과 시각 규칙을 반복해서 관리한 과정이었습니다.
지금 AI 도구를 쓰고 있다면, 프롬프트를 잘 쓰는 것과 동시에 그 노하우를 팀이 공유할 수 있는 구조로 만드는 것을 병행해 보시길 권합니다. 개인의 실험이 조직의 자산이 되는 시스템을 갖추는 것, 그게 이 시대 디자이너에게 남은 진짜 숙제라고 생각합니다.