안녕하세요, 오늘의집 마케팅디자인팀 디자이너 Leeji입니다.

마케팅디자인팀은 매일 수많은 이미지를 만듭니다. 기획전 배너부터 라이브 프로모션, CRM 메시지, 퍼포먼스 광고, SNS 콘텐츠까지. 노출 채널도, 이미지 규격도 제각각이지만 제작 과정을 들여다보면 놀랄 만큼 비슷한 작업이 반복됩니다. 행사명을 바꾸고 상품 이미지를 교체하고 할인율이나 날짜를 수정하는 일을 하루에도 몇 번씩 되풀이하죠. 그러던 어느 날, 팀에서 한 가지 질문이 나왔어요.

“지금 하는 건 디자인일까, 아니면 정보를 옮기는 일일까?”

업무를 하나씩 살펴보니 새로운 디자인 판단이 필요한 작업보다, 정해진 규칙에 맞춰 정보를 옮기는 작업이 더 많았습니다. 처음에는 제작 시간을 줄이면 문제를 해결할 수 있을 거라고 생각했습니다. 하지만 요청부터 전달까지의 흐름을 살펴보니, 더 큰 병목은 제작 자체가 아니라 그 앞뒤 과정에 있었습니다.

기획자가 작업을 요청하면 디자이너는 우선순위에 따라 이미지를 제작합니다. 완성된 이미지는 검수와 수정을 거쳐 다시 전달되고요. 텍스트 한 줄을 바꾸는 데도 여러 사람의 손을 거쳐야 했습니다. 프로모션이 몰릴 때는 이미지를 만드는 시간보다 작업 순서를 기다리는 시간이 더 길어지기도 했습니다.

단순히 제작 속도를 높이는 것만으로는 부족했습니다. 반복 작업이 발생하는 업무 구조 자체를 바꿔야 했어요. 그 고민 끝에 내린 답이 ‘웹 기반 이미지 빌더’였습니다. 프론트엔드 개발자는 없었지만 Claude Code를 활용해 직접 만들어보기로 했습니다. 한 사람의 실험으로 시작한 빌더가 어떻게 팀의 제작 체계로 자리 잡고, 사내 구성원과 외부 파트너사까지 사용하는 도구로 확장됐는지 지금부터 소개할게요.

[ 문제 정의 ] 반복되는 것은 디자인이 아니라 규칙이었다

가장 먼저 떠올린 해결책은 템플릿이었어요. 그동안에도 반복 제작을 줄이려고 PSD나 Figma 템플릿을 만들어 배포하곤 했거든요. 하지만 템플릿만으로는 해결이 어려운 문제가 있었습니다.

• 도구의 장벽 : 템플릿을 사용하려면 결국 Figma와 같은 디자인 도구를 다룰 수 있어야 합니다. 파일과 레이어 구조도 어느 정도 이해해야 하고요. 디자인 도구에 익숙하지 않은 사람에게는 템플릿 자체가 또 하나의 진입 장벽이었습니다.
• 품질 관리의 어려움 : 텍스트 박스를 옮기거나 폰트와 컬러를 임의로 수정하면 템플릿에 담아둔 디자인 기준이 쉽게 흐트러졌습니다. 작은 수정 하나가 의도하지 않은 결과로 이어지기도 했어요.
• 제작 구조의 한계 : 디자인 파일을 전달하더라도 누군가는 파일을 열어 직접 수정해야 했습니다. 제작 주체만 바뀌었을 뿐, ‘반복 제작’이라는 업무 구조는 그대로 남아 있었습니다.

저희가 바꾸고 싶었던 것은 디자인 파일이 아니라 반복 제작이 발생하는 구조였습니다. 그래서 결과물을 공유하는 대신, 디자인 규칙을 실행하는 시스템(빌더)을 만들어보기로 했습니다. 레이아웃과 타이포그래피부터 컬러, 여백, 텍스트 길이, 이미지 비율, 예외 상황까지 디자이너가 자연스럽게 내리던 판단을 하나씩 명확한 규칙으로 정리했습니다. 사용자가 텍스트와 이미지를 입력하면 그 규칙에 따라 결과물이 자동으로 만들어지는 구조를 설계했고요. 개별 디자인을 만드는 데서 나아가, 디자인이 만들어지는 방식 자체를 설계하기 시작한 것입니다.

빌더의 주 사용자는 디자이너가 아니라 MD, 마케터, 기획자였습니다. 디자인 도구에 익숙하지 않아도 쉽게 사용할 수 있어야 했습니다. 이를 위해 초기부터 네 가지 원칙을 세웠습니다.

• 텍스트와 이미지만 입력하면 결과물이 완성될 것
• 자유롭게 조정하기보다 필요한 선택지만 제공할 것
• 입력값이 달라져도 레이아웃이 쉽게 무너지지 않을 것
• 별도의 프로그램 설치나 계정 생성 없이 URL만으로 사용할 수 있을 것

사용자가 디자인을 직접 판단하지 않아도 시스템 안에서 일정한 품질의 결과물이 나오게 만드는 것. 이것이 빌더를 설계하면서 가장 중요하게 생각한 기준이었습니다.

[ 기술 구조 ] 왜 빌드 시스템 없는 정적 웹을 선택했나

기술 구조는 의도적으로 단순하게 설계했습니다. 별도의 빌드 시스템 없이 HTML, CSS, JavaScript로만 동작하는 ‘정적 웹 방식’입니다. React같은 프레임워크나 복잡한 번들러, 별도의 배포 파이프라인도 사용하지 않았습니다.

이 결정은 일반적인 프론트엔드 개발 환경과 비교하면 단순한 선택처럼 보일 수 있습니다. 하지만 개발자가 아닌 디자이너가 직접 만들고 관리해야 하는 팀에는 이 방식이 가장 현실적이었습니다.

• 디자이너가 직접 관리할 수 있어야 했습니다 : 복잡한 프레임워크나 추상화 계층이 없어 파일을 열면 전체 구조를 비교적 쉽게 파악할 수 있습니다. 다른 팀원이 작업을 이어받거나 새로운 Claude Code 세션에서 작업을 시작할 때도 빠르게 맥락을 이해할 수 있고요.
• 수정과 배포 과정이 단순해야 했습니다 : 완성된 파일을 정적 호스팅 환경에 올리면 URL로 바로 공유할 수 있습니다. 사용자는 별도의 프로그램을 설치하거나 업데이트된 파일을 다시 전달받지 않아도 됩니다.
• 서버 운영 범위를 줄여야 했습니다 : 미리보기 렌더링과 이미지 추출은 사용자의 브라우저 안에서 이루어집니다. 별도의 서버 로직이나 이미지 생성 API에 의존하지 않아 서버 운영에 필요한 비용과 관리 범위를 줄일 수 있었습니다.

대부분의 빌더는 동일한 2컬럼 구조를 따릅니다. 왼쪽에는 텍스트, 이미지, 옵션 등을 입력하는 패널이 있고, 오른쪽에는 결과물을 확인할 수 있는 실시간 미리보기가 있습니다. 입력값을 바꾸면 미리보기가 바로 갱신돼, 사용자는 결과를 확인하면서 필요한 정보를 조정할 수 있습니다.

브랜드 컬러와 타이포그래피에 사용되는 주요 값은 CSS 변수로 관리했습니다. 반복되는 값을 한곳에서 관리해 빌더마다 같은 디자인 기준을 적용하기 위해서였습니다. 폰트도 웹폰트로 불러와 사용자 환경에 따른 결과 차이를 줄였습니다.

이미지 추출에는 html2canvas를 사용했습니다. 화면에 렌더링된 미리보기 영역을 브라우저에서 캡처해 PNG 파일로 저장하는 방식입니다. 화면에서는 실제 출력 이미지보다 작은 크기로 보여주고, 다운로드할 때는 출력 배율을 높여 필요한 해상도로 생성합니다. 이를 통해 사용자는 브라우저에서 결과를 빠르게 확인하면서도 실제 운영에 필요한 크기의 이미지를 내려받을 수 있습니다.

*html2canvas : 웹페이지의 HTML 요소와 스타일을 읽어 브라우저 안에서 이미지로 변환해주는 JavaScript 라이브러리

[ Claude Code ] 디자이너가 스펙을 쓰고, AI가 구현한다

팀에는 프론트엔드 개발자가 없습니다. 빌더의 구조를 설계하고 기능을 정의하며 실제 사용성을 검증한 사람은 모두 디자이너입니다. Claude Code는 그 과정에서 디자이너의 아이디어를 작동하는 도구로 옮기는 협업 파트너가 되었습니다.

저희가 경험한 Claude Code는 단순히 코드를 대신 작성해주는 도구에 그치지 않았습니다. 디자이너가 필요한 기능과 사용 방식을 구체적으로 설명하면 Claude Code가 이를 코드로 구현하고, 디자이너는 실제 사용자의 관점에서 결과를 검증합니다. 원하는 방식과 다르면 조건을 다시 정리해 수정을 요청하고요. 이 과정은 디자이너와 개발자가 함께 제품을 만드는 협업 방식과도 닮아 있었습니다.

예를 들어, KV 이미지의 위치와 크기를 조정하는 기능을 만들 때는 다음과 같이 요구사항을 작성했습니다.

KV 배경 이미지 업로드 영역 아래에 포토샵 스타일 이미지 조정 UI 추가

• 1. 이미지 4귀퉁이 + 4엣지 중앙 = 8개 핸들 (흰색 정사각형, 파란 테두리)
• 2. 핸들 드래그 → 비율 유지하며 크기 조정 (반대쪽 모서리 고정)
• 3. 이미지 본체 드래그 → 위치 이동, 마우스 휠 → 확대/축소
• 4. 크기 변경 시 우하단에 비율 뱃지 (예: 150%) 1.2초 표시
• 5. 상태 변수: scale, x, y 기준 transform — scale 1 = cover fit

디자이너는 사용자가 어느 부분에서 불편함을 느낄지, 어떤 조작 방식이 자연스러울지를 구체적으로 상상할 수 있습니다. 그 판단을 구현 가능한 스펙으로 바꾸는 것은 디자이너가 맡고, 코드로 옮기는 과정은 Claude Code와 함께 진행했습니다. 하지만 Claude Code를 팀 단위로 활용하려면 개인의 프롬프트 작성 능력만으로는 부족했습니다. 누가 작업하더라도 기존 구조를 이해하고 같은 기준으로 결과를 만들 수 있는 공통 지침이 필요했어요. 그래서 저장소 최상단에 CLAUDE.md 문서를 만들었습니다. 이 문서에는 전체 기술 구조의 원칙과 빌더에서 공통으로 지켜야 할 패턴을 정리했어요.

*CLAUDE.md : Claude Code가 새 세션을 시작할 때 참고할 프로젝트의 구조와 작업 규칙을 정리해두는 문서

CLAUDE.md는 새로운 세션이 시작될 때 프로젝트의 맥락으로 불러와집니다. 어떤 팀원이 어떤 빌더에서 작업하더라도 Claude Code가 기존 구조와 컨벤션을 참고한 상태에서 작업을 시작할 수 있도록 한 것입니다. 사람에게 온보딩 문서가 필요하듯, AI에게도 팀의 일하는 방식을 알려주는 온보딩 문서가 필요했습니다.

CLAUDE.md는 작업할 때마다 같은 기준을 다시 설명하는 일을 줄이고, 여러 팀원이 하나의 코드베이스를 일관된 방향으로 다룰 수 있게 해주는 가드레일이 되었습니다. 아이디어를 검증하는 방식도 달라졌습니다. “텍스트가 길어지면 어떻게 처리해야 할까?”, “이미지 비율이 달라도 레이아웃을 안정적으로 유지할 수 있을까?” 같은 질문이 생기면 논의에만 머무르지 않고 그 자리에서 기능을 구현해 프로토타입으로 확인했습니다. 개발 리소스를 요청하고 일정을 기다리는 대신, 아이디어가 나온 날 바로 형태로 만들어 사용자에게 보여줄 수 있게 된 것입니다.

이 과정에서 가장 크게 달라진 것은 코드를 작성하는 속도보다, 아이디어를 실제 기능으로 옮기고 검증하는 속도였습니다.

[ 스케일링 ] 빌더 하나가 팀의 개발 체계가 되기까지

이 프로젝트에서 의미 있었던 것은 빌더를 여러 개 만들어냈다는 결과보다, 하나의 기획전 빌더로 시작한 경험이 팀 전체의 일하는 방식으로 확장되었다는 점입니다.

시작은 기획전 빌더 하나였습니다. 하지만 첫 빌더는 하나의 결과물로 끝나지 않았습니다. 빌더를 만들며 정리한 정적 웹 구조와 2컬럼 패턴, 이미지 추출 방식, CLAUDE.md 컨벤션이 다음 빌더를 만들기 위한 설계도가 되었습니다.

이 설계도를 팀에 공유한 뒤에는 팀원들이 자신이 담당하는 채널의 빌더를 하나씩 맡아 만들기 시작했습니다. CRM을 담당하는 디자이너는 카카오톡 캐러셀과 와이드 이미지 빌더를, 온사이트 채널을 담당하는 디자이너는 배너 빌더를 만들었습니다. 각 채널에서 반복되는 작업과 예외 상황을 가장 잘 아는 사람이 자신의 업무 규칙을 직접 시스템으로 옮긴 것입니다.

이렇게 현재는 7개의 빌더를 운영하고 있으며, 2개의 빌더를 추가로 준비하고 있습니다. 빌더가 늘어나면서 운영 방식도 함께 정리했습니다. 각 빌더에 담당 디자이너를 지정하고, 새로운 기능이나 개선 요청이 들어오면 담당자가 Claude Code와 함께 직접 수정하고 배포하도록 했습니다. 여러 빌더에서 함께 사용하는 기능은 ‘shared/’ 폴더의 모듈로 분리해, 같은 기능을 빌더마다 다시 구현하지 않고 필요한 곳에서 재사용할 수 있도록 했습니다.

AI 이미지 배경 확장 기능도 이런 방식으로 확산됐습니다. 한 팀원이 특정 빌더에서 먼저 기능을 검증한 뒤 공용 스크립트로 분리했고, 다른 빌더에서는 최소한의 설정만 추가해 같은 기능을 사용할 수 있도록 했습니다. 이제 한 빌더에서 시작한 개선이 그 빌더에만 머무르지 않고, 다른 빌더로도 빠르게 이어질 수 있게 된 것입니다.

돌아보면 저희가 만든 것은 개별 빌더만이 아니었습니다. 공통 아키텍처와 컨벤션 문서, 기능 재사용 방식, 담당자 중심의 오너십까지. 디자인팀이 직접 디지털 도구를 만들고 개선할 수 있는 작은 개발 체계를 함께 만든 셈입니다.

[ UX ] 누구나 사용할 수 있어야 시스템이 된다

빌더를 만들면서 가장 오래 고민한 것은 코드보다 사용자 경험이었습니다. 새로운 도구는 존재하는 것만으로 사용되지 않습니다. 기능을 익혀야 하고 사용 방법을 계속 찾아봐야 한다면, 바쁜 업무 속에서 점차 멀어지기 쉽습니다. 그래서 저희는 ‘배워야 하는 도구’보다 ‘열면 바로 사용할 수 있는 도구’를 목표로 삼았습니다.

특히 같은 정보를 반복해서 입력하지 않도록 신경 썼습니다. 예를 들어, 브랜드 로고를 한 번 업로드하면 여러 소재에 자동으로 반영하고, 사용자가 기획 과정에서 이미 정리한 정보를 그대로 입력하면 필요한 결과물이 만들어지도록 설계했습니다. 물론 처음부터 모든 불편을 예상할 수는 없었습니다. 실제 사용자들이 빌더를 사용하면서 새로운 문제가 보이기 시작했고, 그 피드백을 바탕으로 기능을 하나씩 보완해 나갔습니다.

• 입력한 내용을 이어서 작업할 수 있게 : 가장 자주 받은 피드백은 창을 닫으면 입력한 내용이 사라진다는 것이었습니다. 텍스트 입력값을 브라우저의 localStorage에 자동으로 저장해, 빌더를 다시 열어도 이전에 작성하던 내용을 이어서 편집할 수 있도록 했습니다. 이미지와 설정을 포함한 전체 작업은 JSON 형식의 프로젝트 파일로 저장할 수 있게 했습니다. 작업 내용을 보관해두었다가 다시 불러오거나, 프로젝트 파일을 동료에게 전달해 이어서 작업할 수 있습니다.
• 설명 없이도 익숙하게 조작할 수 있게 : 이미지의 위치와 크기를 조정하는 방식은 기존 디자인 도구의 사용 경험을 참고했습니다. 이미지를 드래그해 옮기고, 조절점을 움직여 크기를 바꾸며, 마우스 휠로 확대하거나 축소할 수 있습니다. 사용자가 새로운 조작법을 익히지 않아도 되도록 익숙한 인터랙션을 적용했습니다.
• 규격이 맞지 않는 이미지도 활용할 수 있게 : 빌더의 사용법을 단순하게 만드는 것만으로 해결되지 않는 문제도 있었습니다. 기획자가 보유한 이미지와 소재의 규격이 맞지 않는 경우였습니다. 이를 해결하기 위해 이미지 주변의 빈 영역을 생성형 AI로 확장하는 기능을 추가했습니다. 필요한 경우 문구나 배지, 컬러칩처럼 이미지 안에 포함된 요소를 제거하고, 여러 생성 결과를 비교한 뒤 원하는 이미지를 선택할 수 있도록 구성했습니다.

AI 기능은 추가하는 것만큼 안정적으로 운영하는 것도 중요했습니다. 이미지 한 장을 처리할 때마다 비용이 발생하기 때문에 비용과 품질, 처리 속도를 함께 비교해 모델을 선정했습니다. 특정 모델에 과도하게 의존하지 않도록 지원 종료 여부와 가격 정책도 주기적으로 확인하고 있습니다. 기능은 계속 늘어나지만 사용 방법만큼은 단순하게 유지하는 것. 이것이 빌더를 개선하며 지키고 있는 가장 중요한 원칙입니다.

[ 변화 ] ‘이미지 요청’이 ‘기능 요청’으로

빌더가 실제 업무에 자리 잡으면서 예상하지 못했던 변화가 생겼습니다. 다른 팀에서 디자인팀으로 보내는 요청의 성격이 달라진 것입니다. 예전에는 “이 이미지를 만들어 주세요”라는 요청이 대부분이었다면, 이제는 “빌더에서 이 작업도 할 수 있을까요?”라는 요청이 들어오기 시작했습니다. 필요한 결과물을 요청하는 데서 나아가, 반복되는 업무 과정까지 빌더로 해결할 수 있는지 묻기 시작한 것이죠.

예를 들어, CRM팀은 이미지를 제작한 뒤, 발송에 사용할 수 있는 링크로 만드는 작업을 매번 반복하고 있었습니다. 이 과정까지 빌더 안에 연결해 이미지 생성부터 링크 작업까지 한 번에 마칠 수 있도록 개선했습니다. 요청의 범위는 이미지 제작 밖으로도 넓어졌습니다. 이미지 형태로만 제공하던 전면 배너를 HTML 코드로 추출하는 기능도 준비하고 있습니다. HTML로 활용하면 링크와 트래킹, 개인화 문구 등을 적용할 수 있어 하나의 소재를 더 다양한 방식으로 사용할 수 있습니다. 두 사례의 공통점은 새로운 이미지 한 장을 요청한 것이 아니라, 반복되는 업무 과정을 빌더의 기능으로 해결해달라는 요청이었다는 점입니다.

이미지 요청 하나를 처리하면 한 번 사용할 수 있는 결과물이 남습니다. 하지만 빌더에 기능을 추가하면 그 기능이 사용될 때마다 같은 작업을 반복하는 수고가 줄어듭니다. 개별 결과물을 만드는 데서 그치지 않고, 반복되는 문제를 해결하는 구조를 만드는 것입니다. 빌더는 완성해서 배포하면 끝나는 도구가 아니었습니다. 사용하는 사람들의 피드백을 반영하며 업무 방식과 함께 계속 성장하는 시스템이 되었습니다.

[ 확장 ] 빌더는 회사 밖으로도 나갔다

사내에서 효과를 확인한 빌더는 외부 파트너사를 위한 도구로도 확장됐습니다. 그동안 파트너사에는 오늘의집 프로모션을 홍보할 수 있도록 PSD 형식의 SNS 템플릿을 배포해 왔습니다. 하지만 모든 파트너사에 디자이너가 있는 것은 아니었고, 포토샵을 사용하지 않는 곳도 많았습니다. 아무리 잘 만든 템플릿이라도 파일을 열고 수정할 수 없다면 활용하기 어려웠습니다. 사내에서 템플릿 대신 빌더를 선택했던 이유가 회사 밖에서 더욱 분명하게 드러난 셈입니다.

외부 파트너사를 위한 SNS 이미지 빌더의 사용 방식은 단순합니다. 배경 이미지 한 장을 업로드하면 피드와 스토리 규격의 이미지가 동시에 만들어집니다. 밝기와 대비, 채도를 조절하고 화이트 모드와 다크 모드를 선택하는 과정도 빌더 안에서 해결할 수 있고요. 완성된 이미지는 ZIP 파일로 한 번에 내려받을 수 있습니다.

파트너사는 이제 포토샵이나 별도의 디자인 인력 없이도 오늘의집 프로모션 가이드에 맞는 SNS 이미지를 직접 제작할 수 있습니다. 사내의 반복 제작 문제를 해결하기 위해 시작한 시스템이 파트너사의 제작 장벽까지 낮추는 도구로 확장된 것입니다. 이처럼 디자인 규칙을 시스템으로 만들면, 그 규칙이 적용되는 범위도 함께 넓어집니다.

[ 결과 ] 요청 → 제작 → 전달로, 입력 → 생성으로

빌더 도입 이후 가장 크게 달라진 것은 이미지 한 장을 만드는 시간이 아니라, 업무가 흘러가는 방식입니다. 기존에는 다음과 같은 과정을 거쳤습니다.

• 요청 → 디자인 제작 → 검수·수정 → 전달

빌더로 전환한 작업은 훨씬 단순해졌습니다.

• 입력 → 생성 → 다운로드

기획자는 행사명과 혜택, 기간, 상품 정보처럼 기획 과정에서 정리해야 하는 내용을 빌더에 직접 입력합니다. 입력이 끝나면 미리 정의된 디자인 규칙에 따라 결과물이 만들어지고요. 이전에는 요청서를 작성하고 디자인팀의 작업 일정을 기다려야 했다면, 이제는 기획 정보를 정리하는 과정이 이미지 생성까지 바로 이어집니다. 텍스트나 이미지가 바뀌어도 사용자가 직접 수정하고 결과를 확인할 수 있습니다.

그만큼 반복 운영 소재에서 요청과 대기, 수정 내용을 주고받는 과정이 줄었습니다. 디자이너에게도 단순한 정보 교체와 규격별 반복 제작에서 벗어나 캠페인과 브랜딩, 크리에이티브처럼 디자인 판단이 더 필요한 업무에 집중할 여지가 생겼습니다.

디자이너는 무엇을 만드는 사람일까?

이 프로젝트를 진행하며 가장 크게 달라진 것은 빌더의 개수가 아니라, 디자이너가 자신의 역할을 바라보는 방식이었습니다. 물론 지금도 디자이너는 요청에 맞는 결과물을 직접 만듭니다. 하지만 이제 역할은 거기서 끝나지 않습니다. 하나의 결과물을 만드는 것을 넘어, 결과물이 만들어지는 규칙과 과정까지 설계합니다.

어떤 정보를 입력받을지, 사용자에게 어디까지 선택권을 줄지, 무엇을 제한해야 할지 고민합니다. 예상과 다른 값이 들어와도 일정한 품질을 유지하려면 어떤 규칙이 필요한지도 정하고요. 디자이너가 자연스럽게 내리던 판단을 누구나 활용할 수 있는 구조로 옮기는 일입니다. 좋은 결과물을 한 번 만드는 데서 그치지 않고, 같은 품질의 결과가 반복해서 만들어질 수 있는 조건을 설계하는 것이죠.

이러한 변화는 한 사람의 역량에 머무르지 않았습니다. 팀원들은 자신이 가장 잘 아는 업무 영역의 빌더를 만들고 Claude Code와 함께 기능을 개선합니다. 한 빌더에서 검증된 기능은 공용 모듈로 정리해 다른 팀원과 빌더에서도 활용할 수 있도록 했습니다. 개인의 경험이 팀의 공통 자산으로 이어지는 구조를 만든 것입니다.

Claude Code가 구현의 많은 부분을 도왔지만, 무엇을 만들지 정하고 어떤 결과가 좋은지 판단하는 역할까지 대신한 것은 아닙니다. AI가 디자이너를 대신한 것이 아니라, 구현의 장벽을 낮춰 디자이너의 판단을 실제 시스템으로 옮길 수 있게 한 것입니다. 그 결과 디자이너가 해결할 수 있는 문제의 범위도 더 넓어졌습니다.

마치며

저희는 이미지 제작을 조금 더 빠르게 하기 위해 빌더를 만들기 시작했습니다. 하지만 프로젝트를 이어갈수록 바뀌고 있는 것은 제작 속도만이 아니라는 사실을 알게 되었습니다. 반복 제작을 입력 기반의 생성 구조로 전환하면서 요청과 대기에서 발생하던 병목이 줄었습니다. 사내 기획자부터 외부 파트너사까지, 비디자이너도 일정한 품질의 운영 이미지를 직접 만들 수 있는 환경이 마련되었고요.

빌더를 만드는 과정에서 팀의 일하는 방식도 달라졌습니다. 공통 기술 구조와 컨벤션 문서, 기능을 재사용하는 방식, 담당자 중심의 오너십이 자리 잡았습니다. 디자이너의 역할도 결과물을 직접 만드는 데서 나아가, 디자인 규칙을 정리하고 실제로 작동하는 시스템을 설계하는 데까지 넓어졌습니다.

앞으로 디자이너에게 필요한 역량이 이미지를 얼마나 많이, 얼마나 빠르게 만드는 능력에만 있지는 않을 것이라고 생각합니다. 디자이너가 매번 개입하지 않아도 일관된 품질을 유지할 수 있는 구조를 만들고, 동료들의 반복 업무를 줄여주는 도구를 설계하는 능력도 점점 더 중요해질 것입니다.

이 프로젝트는 그 가능성을 실제 업무에서 확인한 첫 번째 시도였습니다.