디자이너의 감각을
문장으로 정의할 수 있을까?
케이뱅크 앱을 돌아보면 곳곳에서 3D 그래픽을 만나게 됩니다. 블루 컬러를 중심으로, 질감이 매끈한 세라믹이거나 반투명한 아크릴이거나 빛이 한쪽 위에서 떨어집니다. 이것이 하나의 일관된 케이뱅크 그래픽의 얼굴인데요. 문제는 이 그래픽을 만드는 비용과 시간이었습니다.
서비스와 이벤트를 열 때마다 그래픽이 필요한데, 3D를 다룰 수 있는 소수의 디자이너에게 요청이 몰렸습니다. 그렇다면, 케이뱅크다운 그래픽을 나 혼자 만들 수 있다면? 사내 그래픽 생성 도구 kpic은 이 질문에서 시작했습니다.
학습 없이 만들기로 했습니다
이미지 생성 도구를 만든다고 하면 보통 두 가지 방법이 떠오릅니다. 이미 만들어진 상용 모델의 API를 활용하거나, 우리 그림을 잔뜩 모아 모델을 직접 학습(파인튜닝)시키는 것이죠. 처음부터 학습 없는 쪽을 택했습니다.
디자이너 1명, 개발자 1명이 만들어 운영하는 도구인 만큼 데이터셋과 모델 관리까지 감당하기 어렵고, 빠르게 좋아지는 모델의 발전을 그때그때 가져다 쓰고 싶은 마음이 컸거든요.
그래서 상용 모델의 API를 그대로 쓰되, 케이뱅크다운 이미지를 문장으로 정의한 요청과 함께 보내는 방식으로 했습니다. OpenAI의 이미지 모델과 구글 제미나이를 호출하는 서버 안에 브랜드 규격의 시스템 프롬프트를 담는 구조인데요. 새 이미지를 만드는 요청과 기존 이미지를 고치는 요청에는 각각 다른 API가 붙습니다. 사용자는 만들고 싶은 것만 말하면 되고, 색감·조명·형태 등 브랜드 디자인이 몰래 덧붙습니다. 모델이 좋아지면 kpic도 같이 좋아지고, 이미지를 고치려면 프롬프트 문장을 고치면 되죠.
그런데 이 결정은 곧바로 어려운 문제 하나를 던졌습니다. 그 문장을 어떻게 쓸 것인가, 하는 것이죠.
감각을 문장으로 번역하는 법
디자이너는 케이뱅크 아이콘을 보면 우리 것인지 아닌지 한눈에 압니다. 그런데 이 판단의 근거를 말로 풀어보려 하면 “이게 따뜻하고, 좀 살톰하고, 광이 좀 도네?”에서 막힙니다. kpic을 만드는 핵심은 이런 암묵적인 감각을 모델이 알아들을 수 있는 명시적인 문장으로 번역하는 것이었습니다.
그래서 먼저 기존 공식 이미지 사이트의 3D 렌더링 구조를 분석하고, 케이뱅크다움을 가장 잘 담았다고 생각하는 이미지 10개를 골라 공통 시각 규칙을 하나의 문장으로 뽑았습니다. 따뜻하다고만 해두면 안 되니 코발트 블루(#2F4CE8)까지 정확한 값을 박았고, 질감은 매트한 세라믹과 반투명 아크릴 두 갈래, 조명은 사선으로 한쪽 위에서 오는 방향, 카메라는 살짝 내려다보는 4분의 3 각도로 고정했습니다. 실제 프롬프트 안에서는 이런 모습입니다.
"camera_and_view": "Three-quarter EDITORIAL PRODUCT-SHOT view — gentle downward tilt. NOT orthographic, NOT flat isometric. Read like a hero product photograph, not a technical elevation." "_blue_match_rule": "CRITICAL: cobalt = #2F4CE8 EXACTLY. HEX is authority. NO navy, royal blue, generic mid-blue. (⚠)"
예쁘다거나 우리 느낌이라는 말은 모델에게 아무 정보가 되지 못합니다. 반면 각도의 범위, 광원의 방향, 질감을 표현하는 어휘까지 분명하게 적는 만큼 정확한 결과를 얻었습니다. 디자이너의 감각을 문장으로 정의할 수 있느냐는 질문에 제 답은 이렇습니다. “정의할 수 있다. 다만 형용사가 아닌 조건문으로.”
AI가 생각보다 더 말을 못 들었습니다
물론 규칙이 한 번에 완성되진 않았습니다. 그래픽 시스템에 맞지 않는 블루 컬러의 질감, 반사의 비율, 너무 실사인 질감, 패키지의 밋밋한 텍스트 등 결과를 보며 그때마다 규칙은 한 줄씩 쌓여갔고, 지금도 살아있는 문서입니다. 몇 가지를 옮겨봅니다.
- 라벨이 있는 물건마다 뭔가 글자가 채워졌습니다. 패키지에 밋밋한 글자가 꼭 생기는 겁니다. 그래서 “라벨의 글자는 항상 비어 있음”을 기본 규칙으로 두고, %처럼 꼭 필요한 기호는 반드시 포함하도록 명시했습니다.
- 어딘지 모르게 감각이 부족합니다. 잘 하는 디자이너가 직접 모델링한 이미지에 비하면 밋밋합니다. 볼륨감, 균일한 굴곡, 비례를 살짝 과장해 귀엽게 만드는 것들을 조건으로 세분화하며 격차를 줄여왔지만, 아직 사람 손이 필요한 부분이 있습니다.
- 그림자를 너무 붙이면 어딘가가 뚝 꺼져 보였습니다. 사용 안내의 예시 물건이 3개 이하가 된 이유입니다.
- 그리고 가장 골칫거리인 문제, 모든 것이 파랗습니다. 사용자가 “코랄 몸통”이라고 해도 모델이 꾸준히 코발트 블루로 돌아갔습니다.
마지막 문제는 문장을 덧붙이는 것으로는 해결되지 않았습니다. 기본으로 따뜻하라는 규칙이 사용자가 고른 색을 따르는 규칙과 프롬프트 안에서 충돌하고 있었고, 모델은 먼저 써진 브랜드 규칙을 따랐던 거죠.
적정 프롬프트 구조를 다시 설계했습니다
그래서 구조를 바꿨습니다. 사용자가 화면에서 컬러 칩과 각도 칩을 고르면, 이 선택으로 시스템 프롬프트 내의 해당 규칙 블록이 통째로 교체됩니다. 컬러를 고른 순간 코발트 블루를 기본으로 하는 규칙은 이 요청에서 아예 사라지고, “이번 이미지의 색상 권한은 사용자가 고른 색에만 있다”는 블록이 새로 들어갑니다. 전체 프롬프트 문구까지 같은 케이스로 맞춰 프롬프트 안에 모순이 없게 했습니다.
각도도 같은 방식으로, 화면에서 선택하면 카메라 규칙 블록이 통째로 바뀝니다. 규칙끼리 싸우지 않게 정리하고 나서야 모델이 고집을 꺾었습니다.
생성에서 멈추지 않도록
이제쯤 돌아보면 “80점짜리는 왔는데 여기 하나를 고치기 너무 어렵다”는 순간이 가장 많았습니다. 그래서 브러시로 칠한 영역을 다시 그리는 부분수정, 원본에 “버튼 하나를 추가해줘”라고 말하는 이미지 편집, 배경 제거를 기능으로 넣었습니다.
다만 보안으로 철저히 관리하는 사내 환경인 만큼 외부 모델에게 이미지를 그냥 보낼 수는 없어서, 승인받은 이미지의 라이브러리를 만들어 안에서 골라 생성·편집·참고로도 쓸 수 있게 했습니다.
마지막 관문은 사람입니다. 만든 그래픽을 실제 화면에서 픽셀로 놓인 피그마에 배치하고 레이아웃을 확인한 뒤, 해당 디자이너가 하루 안에 검수합니다. 이게 케이뱅크다운지 최종 판단은 전적으로 디자이너의 몫이고, kpic의 목표는 그 최종 판단 이전 단계의 공수를 줄이는 데 있었습니다.
도구를 만들며 배운 것
kpic은 지금 사내 디자이너들도 사용하고 있고, 주로 웹 그래픽을 만드는 데 쓰이고 있습니다. 브랜드 규격에 맞는 그래픽이 요청 줄에 옵니다. 만들면서 배운 것들을 옮겨봅니다.
- 브랜드 핏을 붙잡기 위해 파인튜닝은 필요하지 않았습니다. API와 잘 벼린 문장만으로도 단단하게 잡혔고, 이 방식은 모델이 발전할수록 결과물도 따라 좋아집니다.
- 감각은 전달 불가능하지 않았습니다. “예쁘다”고 버려지고 나면 각도와 비율 같은 조건문만 남는데, 특히 해야 할 것을 나열하기보다 하면 안 되는 것을 분명히 두는 쪽이 훨씬 효과적이었습니다.
- 모델은 설득되지 않았습니다. 규칙 외의 요청이 들어오면 먼저 써진 기본값이 이기기 때문에, 예외를 덧붙이는 대신 충돌하는 규칙 자체를 통째로 바꿔줘야 했습니다.
디자이너의 감각을 문장으로 정의할 수 있을까요. 완전하진 않을 겁니다. 하지만 그 과정에서 얻어지는 건 AI가 우리 기준으로 움직이게 하는 규칙들입니다. 모델은 계속 좋아질 것이고, 이 규칙 안에서 kpic이 함께 발전할 겁니다.
