디자이너의 감각을
문장으로 정의할 수 있을까?

디자이너의 감각을 문장으로 정의할 수 있을까?
방지은
방지은 코어디자인팀
AI를 활용해 디자이너를 위한 사내 도구를 만들고 있습니다.

케이뱅크 앱을 쓰다 보면 곳곳에서 3D 그래픽을 만나게 됩니다. 블루 컬러를 중심으로, 재질은 매끈한 세라믹이거나 반투명한 아크릴이고, 빛은 늘 왼쪽 위에서 떨어집니다. 이 일관된 인상이 케이뱅크 그래픽의 얼굴인데요. 문제는 이 그래픽을 유지하는 비용과 시간이었습니다.

새 서비스와 이벤트가 생길 때마다 새 그래픽이 필요한데, 3D 툴을 다룰 수 있는 소수의 디자이너에게 요청이 몰렸습니다. 누구나, 케이뱅크다운 그래픽을, 몇 분 안에 만들 수 있다면? 사내 그래픽 생성 도구 kpic은 이 질문에서 시작했습니다.

케이뱅크에서 사용하는 3D 아이콘 스타일
케이뱅크에서 사용하는 3D 아이콘 스타일

학습 없이 만들기로 했습니다

이미지 생성 도구를 만든다고 하면 보통 두 가지 방법을 떠올립니다. 이미 만들어진 상용 모델의 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은 지금 사내 디자인 툴로 자리를 잡았고, 주로 서브 그래픽을 만드는 데 쓰이고 있습니다. 브랜드 규격에 맞는 그래픽이 요청 한 줄이면 나옵니다. 만들면서 배운 것들을 남겨봅니다.

  • 브랜드 스타일을 붙잡는 데 꼭 학습이 필요한 건 아니었습니다. API와 잘 벼린 문장만으로도 꽤 단단하게 잡혔고, 이 방식은 모델이 발전할 때마다 결과물도 따라 좋아집니다.
  • 감각은 형용사로는 전달되지 않았습니다. “예쁘게”는 버려지고 각도와 비율 같은 조건문만 살아남았는데, 특히 해야 할 것을 적기보다 되면 안 되는 것을 분명히 적는 쪽이 자주 이겼습니다.
  • 모델은 설득되지 않았습니다. 규칙 둘이 싸우면 먼저 적어둔 기본값이 이기기 때문에, 예외를 덧붙이는 대신 충돌하는 규칙을 치우고 그 자리를 통째로 내줘야 했습니다.

디자이너의 감각을 문장으로 정의할 수 있을까요. 완전히는 아닐 겁니다. 다만 그 과정에서 저희는 AI를 우리 기준대로 움직이게 하는 규칙의 언어를 갖게 됐습니다. 모델은 계속 좋아질 테고, 그 규칙 위에서 kpic도 함께 발전해 갈 겁니다.