CoCo는 좌표, 크기, 문자열을 코드로 명시해 이미지 배치를 더 잘 통제할 수 있지만, 최종 이미지까지 결정론적으로 만드는 것은 아닙니다.
CoCo 논문은 자연어 Chain-of-Thought 대신 실행 가능한 Code를 중간 표현으로 사용합니다. 모델이 Code로 Layout Draft를 만들고, 그 이미지를 원래 Prompt와 함께 최종 생성 단계에 전달합니다. 배치를 수정 가능한 산출물로 노출한다는 점이 장점이지만, Code 생성과 실행을 위한 새로운 실패, 보안 지점이 생깁니다.
첫 단계에서 모델은 객체 좌표, 크기, 쌓임 순서, Text 내용을 표현하는 Code를 생성합니다. 원문은 HTML, CSS나 Python PIL, Canvas에 가까운 형태를 예로 듭니다.
두 번째 단계에서는 Code를 격리된 Sandbox에서 실행해 Wireframe, Bounding Box, Text가 포함된 Draft Image를 렌더링합니다. 같은 Code와 환경에서는 Draft를 재현하고 Syntax, Layout 오류를 찾기 쉽습니다.
세 번째 단계에서는 Draft와 원 Prompt를 이용해 Texture와 Style을 입힌 최종 Image를 생성합니다. 이 단계는 다시 생성 모델의 확률적 추론이므로 Draft의 모든 좌표와 철자가 그대로 보존된다고 보장할 수 없습니다.
CoCo는 1만 쌍의 구조적 Draft와 최종 Image로 구성된 CoCo-10K를 사용해 정제 단계를 학습합니다. 원문은 StructT2IBench에서 +68.83%, OneIG-Bench에서 +54.8% 향상을 제시합니다.
이 값은 두 Benchmark의 비교 조건에서 나온 상대 개선으로 읽어야 합니다. 정확한 Baseline, 평가 지표와 Model 크기가 없으면 “Text가 거의 완벽하다”거나 모든 Image Task에서 같은 폭으로 좋아진다고 결론 내릴 수 없습니다. 특히 긴 문구, 겹치는 객체, Draft에 없는 질감에서 결과를 별도로 확인해야 합니다.
기존 생성에서는 객체를 조금 옮기려면 Prompt를 바꾸고 전체 결과를 다시 뽑았습니다. CoCo에서는 중간 Code의 x, y, width 같은 값을 바꾸고 Draft를 다시 렌더링할 수 있습니다. Layout 규칙을 Version 관리하거나 회사 Logo, Text 영역을 고정하는 작업에 유리합니다.
하지만 생성된 Code가 실제 API와 Brand Rule을 정확히 따르는지는 별도 검사해야 합니다. Code Schema, 허용 Component, Canvas 크기를 제한하지 않으면 모델마다 서로 다른 표현을 만들어 후처리가 복잡해질 수 있습니다. 결과물의 원인을 찾기 쉬워지는 대신 중간 표현의 규격을 관리하는 일이 생깁니다.
사용자 Prompt가 Code 생성에 영향을 주므로, 생성된 Code를 Host에서 바로 실행하면 File, Network, Process 접근 위험이 생깁니다. Production에서는 Network 차단, Read-only Base Image, CPU, Memory, 시간 제한, 일회성 File System과 Process 격리가 필요합니다. 렌더러가 허용할 API도 좁혀야 합니다.
Code 생성 → Sandbox 시작 → Draft 렌더링 → 최종 생성이라는 세 단계는 단일 생성보다 지연이 큽니다. Cold Start와 실패 재시도까지 포함해 한 장의 비용을 측정해야 합니다. CoCo의 원문에는 이 인프라를 그대로 재현할 실행 Code가 없으므로, 논문 구조를 곧바로 완성 API로 받아들여서는 안 됩니다.
CoCo는 Banner, Diagram, UI Mockup처럼 객체 위치와 Text가 중요한 작업에 먼저 시험할 가치가 있습니다. 추상적 Style이나 자연 장면에서는 Code라는 중간 단계가 표현을 제한할 수 있습니다.
평가 세트에는 긴 Text, 같은 종류의 여러 객체, 가림, Z-index, 비정상 Canvas와 실행 실패를 넣습니다. Direct Generation과 비교해 Layout 정확도, 철자, 최종 미감, Latency, Sandbox 실패율을 함께 기록해야 합니다. 코드 저장소와 Paper ID 2603.08652은 구현 범위를 확인하는 출발점이며, Code-as-CoT의 가치는 통제력 증가가 추가 실행 계층의 비용보다 클 때 드러납니다.
모델이 임의의 HTML, Python을 만들게 두면 렌더러와 후처리가 매번 다른 구조를 해석해야 합니다. 허용 객체, 좌표 단위, 캔버스 크기, 색상과 글꼴, 쌓임 순서를 제한한 스키마를 두는 편이 좋습니다. 스키마 밖의 속성은 실행 전에 거부하고 누락된 필수 값은 모델에게 다시 묻거나 안전한 기본값으로 처리합니다.
좌표는 픽셀인지 비율인지 명확해야 합니다. 화면 밖 요소, 음수 크기, 겹쳐서는 안 되는 텍스트를 정적 검사할 수 있습니다. 같은 프롬프트에서 코드가 얼마나 달라지는지와 동일 코드가 같은 초안을 만드는지도 기록해야 중간 표현의 재현성을 평가할 수 있습니다.
렌더링 성공은 배치 성공과 다릅니다. 객체 수, 라벨 텍스트, 위치 관계, 겹침과 여백을 코드와 초안에서 다시 읽어 비교해야 합니다. “제목은 위, 버튼은 아래”처럼 프롬프트에서 추출한 제약을 체크리스트로 만들면 문법은 맞지만 의미가 틀린 코드를 걸러낼 수 있습니다.
복잡한 장면에서는 모든 제약을 동시에 만족하지 못할 수 있습니다. 어떤 제약을 우선할지 정하지 않으면 재시도마다 다른 배치가 나옵니다. 필수 텍스트와 브랜드 영역은 고정하고 장식 요소는 유연하게 두는 식으로 우선순위를 명시하는 것이 좋습니다.
최종 이미지에서 초안의 박스와 실제 객체 영역을 비교하고, OCR로 문자열을 다시 읽을 수 있습니다. 객체가 사라지거나 추가됐는지, 서로의 위치 관계와 쌓임 순서가 유지됐는지 측정합니다. 초안 점수는 높지만 최종 단계에서 계속 틀린다면 코드 생성보다 정제 모델이나 가이드 강도가 병목입니다.
재시도할 때 코드를 다시 만들 것인지 같은 초안으로 최종 생성만 반복할지도 구분해야 합니다. 원인이 배치 오류라면 코드를 고치고, 질감이나 철자 드리프트라면 최종 단계만 다시 실행하는 편이 비용을 줄일 수 있습니다. 실행 ID로 프롬프트, 코드, 초안과 최종 이미지를 연결해야 어느 단계가 실패했는지 추적할 수 있습니다.
보장되지 않습니다. 초안의 좌표와 문자열은 구조를 안내하지만 최종 생성 단계는 확률적이므로 위치, 철자와 객체 수가 다시 달라질 수 있습니다.
안 됩니다. 사용자 입력이 코드에 영향을 주므로 네트워크와 파일 접근을 막고 CPU, 메모리, 시간, 허용 API를 제한한 일회성 샌드박스에서 실행해야 합니다.
배너, 다이어그램, UI 모형처럼 좌표, 텍스트, 쌓임 순서가 중요한 작업부터 직접 생성과 비교하면 중간 코드의 통제 이득을 확인하기 쉽습니다.
←→ 키와 좌우 스와이프를 지원합니다. 읽던 페이지는 이 기기에 저장됩니다.