코드로 그림 그리는 AI, RL의 보상은 디자인 문제다

이미지를 직접 만들지 않고 코드를 남긴다

Surya Narreddi의 Training AI to Paint with Code는 이미지 생성 AI의 참여 방식을 다르게 본다. 일반 이미지 모델은 사용자가 프롬프트를 고치면 다시 이미지를 받는다. 결과물 자체를 세밀하게 편집하기 어렵다. 이 프로젝트는 언어 모델이 p5.brush JavaScript sketch를 작성하게 하고, 그 코드가 수채화 이미지를 렌더링하도록 학습했다. 결과물은 PNG뿐 아니라 수정 가능한 코드다.

시스템은 네 단계 loop로 설명된다. 모델이 "watercolour hibiscus" 같은 프롬프트를 받고 완전한 p5.brush sketch를 쓴다. Puppeteer sandbox가 코드를 렌더링해 PNG를 만든다. PNG는 hand-rated reference pool에서 뽑은 두 장의 그림과 비교되고, 별도의 judge 모델이 더 나은 수채화를 고른다. 그 판단이 reward signal이 되어 GRPO 업데이트로 돌아간다. Qwen 계열 모델, HPSv3, pairwise judge, reference pool이 결합된 창작 RL 실험이다.

창작 RL의 난점은 정답이 없다는 것이다

수학 문제는 맞거나 틀린다. 게임은 이기거나 진다. 하지만 수채화의 아름다움은 단일 정답이 없다. 프로젝트의 첫 rubric은 compile gate, p5.brush 사용 여부, 3,000 토큰 길이 목표, HPSv3, prompt adherence, recognisability, aesthetics, technique, depth 등 9개 신호를 썼다. 그러나 reward가 0.65 부근에서 멈추고, 결과물은 다섯 장 꽃잎의 평평한 clip-art처럼 반복됐다.

진단은 보상 설계의 실패였다. 여러 quality judge와 prompt adherence가 0.85에서 0.95까지 서로 강하게 상관돼 사실상 같은 말을 반복했다. code length는 step 30 이후 포화되어 gradient를 주지 못했다. 실제 variance를 가진 HPSv3는 0.10 가중치에 불과했다. 보상 함수가 정교해 보였지만 모델에게는 좁고 반복적인 신호였다.

HPSv3 논문 페이지와 GRPO를 알린 DeepSeekMath 논문은 preference와 policy optimization이 창작과 추론 모두에서 중요해지고 있음을 보여준다. 다만 창작에서는 보상이 곧 취향의 인터페이스다. 무엇을 재고, 무엇을 무시할지 자체가 디자인 결정이다.

Prompt engineering도 학습 인프라다

프로젝트는 400줄짜리 p5.brush API reference를 시스템 prompt에 넣었을 때 모델이 존재하지 않는 API를 자신 있게 만들었다고 설명한다. 해결은 더 많은 문서가 아니라 더 짧은 제약이었다. GEPA라는 prompt optimization library로 200 iteration을 돌리고, strict allowlist 8개 brush method, 문서 없음, 예시 없음에 수렴했다. 긴 설명이 아니라 좁은 행동 공간이 더 나은 결과를 만든 셈이다.

Huzzah, 프롬프트를 파일로 남기는 코딩 실험는 prompt가 개발 산출물이 되는 흐름을 다뤘다. agent.md, 코딩 에이전트 품질의 새 계약서는 에이전트에게 주는 지시가 품질 계약이 된다고 봤다. Codex와 Claude, 코딩 에이전트 UX가 갈라진다는 같은 작업도 에이전트 표면에 따라 달라진다고 분석했다. 이 프로젝트에서는 prompt가 단순 지시문이 아니라 학습 환경의 경계다.

reference pool은 취향의 데이터베이스다

프로젝트는 1,664개 생성 이미지를 love, okay, nope로 손수 평가했고, love-tier 117개를 comparison pool의 씨앗으로 썼다고 밝힌다. 이후 pool은 581개 reference painting으로 확장됐다. 모든 reference가 모델 출력이라는 한계도 공개한다. 인간 작가의 예시를 충분히 모으기 어려웠기 때문이다. 이것은 창작 AI에서 자주 마주칠 현실적 문제다. 좋은 취향 데이터는 비싸고, 저작권과 출처 문제가 있으며, 도메인마다 기준이 다르다.

흥미로운 점은 이 작업이 "더 좋은 이미지 모델"을 만들기보다 "어떤 이미지를 좋다고 볼 것인가"를 구조화했다는 점이다. RLHF가 흔히 인간 선호를 추상적으로 말하지만, 실제 제품에서는 누군가가 예시를 고르고, 평가 기준을 쓰고, judge model의 질문을 다듬는다. OpenAI의 RLHF 설명은 오래전부터 선호 학습의 중요성을 설명했지만, 창작 도구에서는 그 선호가 곧 제품 정체성이 된다.

한국 창작 도구가 배울 점

한국의 디자인, 웹툰, 게임, 광고 도구는 생성 이미지의 품질만 경쟁하기 쉽다. 그러나 사용자에게 중요한 것은 수정 가능성과 반복 비용이다. 코드로 만든 그림은 느리고 제한적일 수 있지만, 레이어처럼 편집 가능한 구조를 남긴다. 사용자는 색, stroke, composition을 코드 수준에서 바꿀 수 있다. AI가 완성 이미지를 던지는 대신 편집 가능한 원본을 남기는 방향은 전문 창작 도구에서 특히 중요하다.

WorldClaw, 3D 월드 생성이 에이전트 파이프라인이 되다는 생성 결과가 파이프라인 산출물이 될 때의 의미를 봤다. 코드로 그림을 그리는 방식도 비슷하다. 출력물이 최종 파일이 아니라 다음 편집의 재료가 된다. 창작 AI의 다음 경쟁은 "더 예쁜 첫 장"이 아니라 "사용자가 개입할 수 있는 구조"가 될 가능성이 크다.

자주 묻는 질문

Q1: 이 방식이 일반 이미지 모델보다 낫나요?

A: 속도와 사실성에서는 아닐 수 있다. 프로젝트 자체도 더 느리다고 말한다. 장점은 결과물이 수정 가능한 코드라는 점이다.

Q2: 왜 pairwise judge가 더 나았나요?

A: 추상적인 0~10 점수보다 "둘 중 무엇이 더 나은가"가 judge model에 더 안정적인 질문이기 때문이다.

Q3: reference pool이 모델 출력이면 편향이 생기지 않나요?

A: 생길 수 있다. 다만 도메인 자료가 부족할 때는 손수 평가한 생성물을 기준으로 삼는 현실적 접근이 될 수 있다.

Q4: 긴 API 문서가 왜 나쁜 결과를 냈나요?

A: 모델이 문서를 이해하기보다 그럴듯한 API 패턴을 만들 수 있다. 좁은 allowlist가 실행 가능한 코드를 만드는 데 더 유리했다.

Q5: 제품팀이 배울 교훈은 무엇인가요?

A: 창작 AI의 핵심은 모델 선택만이 아니다. 보상 함수, reference set, judge 질문, prompt 제약이 모두 제품 디자인이다.