procedural 방식의 패턴 생성(1)

 

5월 28일자 회의에서 발표한 내용을 바탕으로 재구성함.

---

이미지 생성하기… 어케해

이미지를 생성해서 보여주는 방법에 대해 2가지 방법을 구상했다.

 

1. 이미지 생성 diffusion model을 사용한다. (이하 AI 방식)

LLM을 통해 가공된 프롬프트를 diffusion model에 전달해 이미지를 출력하는 방법이다. 가장 다양한 형태의 이미지를 생성할 수 있고, 하이퀄리티를 쉽게 뽑을 수 있다. 다만, AI를 전담으로 하는 개발자가 없는 상황에서 당장 이미지 생성 모델을 도입하기에는 부담이 있다.

 

2. procedural 한 방식으로 이미지를 생성한다. (이하 procedural 방식)

3D 모델링 분야에서 모델링과 텍스처링에서 사용하는 방법을 차용한 것으로, 흔히 노드 에디터에서 절차지향적 방식이 사용된다. 다만, 실제 서버에서는 이미지 생성 알고리즘을 노드로 에디팅하는게 아니라 코드로 작성해야 하므로 아티스트가 직접 참여하기에는 부담이 있다. 또, 그림보다는 패턴 이미지를 생성하는 것에 보다 적합하다.

애매하긴 한데 대충 이런 화면이 노드 에디터이다.텍스처는 섭스턴스 디자이너라는 툴에서 noise 값으로 절차적으로 생성했고, 머테리얼도 절차적으로 제작한 것이다.

 

AI 방식과 procedural 방식 모두 초기에 모두 초기에 고려대상으로 올렸고, 개별적으로 결과물을 출력하는 테스트를 진행했다.

하지만 결과물을 확인해보는 것 이상의 기능적, 성능적인 수준까지 들어간 검토가 부족했다. 일단 여러 결과를 뽑아보자 라는 목표도 모호했고, 4-5월 동안은 기획과 서버 작업에 집중하여 시간적인 문제도 있었다.

 

사실 제일 큰 문제는, 검토가 늦어지는 것이 일정상으로 일시적으로 발생한 문제가 아니라 앞으로 계속 발생할 구조적인 이슈일 수 있다는 점이었다.

 

 

할 일이 너무 많아

그니까… 1번이든 2번이든 아무튼간에 개발자가 계속 붙들고 있어야한다.

 

만약 static하게 이미지를 보여주는 경우 디자이너가 여러 이미지들을 만들어서 전달해주면 되기 때문에 개발자는 이미지에 관여하지 않아도 된다. 하지만 이번 프로젝트에서는 이 과정을 기계에게 넘겼기 때문에 아티스트에게 테크니컬한 역할이 많이 요구된다.

 

AI 방식의 경우 모델 선택, 프롬프트 설계, 이미지 품질 평가, 필요할 경우 파인 튜닝이 필요한데, 실제로 서버에 AI를 배포해서 사용하는 과정은 아티스트가 작업할 수 없으므로 개발자가 필요하다. 반대로, 개발자가 이걸 전담하기에는 내가 하기에는 시간이 없고(바빠요) 보통 보는 눈이 발가락에 달려서 힘들다…

 

procedural 방식은 일단 코드 기반이기 때문에 알고리즘을 직접 작성해야 한다. 그니까 아티스트가 직접 코드를 쓸게 아니라면 개발자를 조종해서 코드를 찍어야 한다는 의미이다. 그런데 이 이미지가 아티스트 맘에 들지는 모르겠다.

암튼간에 어느 방법이든 시간이 없고 바빠서 검토가 미뤄지는 일이 계속 반복될 수밖에 없다.

 

개인적으로는 우리 팀이 3D 그래픽에 대한 도메인이 있기 때문에 CG 분야에서 사용하는 방법론을 이미지 생성부분에 도입하고자 하는 욕심이 있었다. 그래서 procedural 방식을 끌어오는 것을 더 중점을 두고 고민해보았다.

 

 

이미지 생성 기능 요구사항

이미지 생성 기능에 고려해야할 요구사항은 아래와 같다.

 

이미지 생성 기능 요구사항

1. 프롬프트나 색상(RGB 값)과 같은 입력 파라미터가 필요하다.
2. 이미지를 생성하는 알고리즘(AI 또는 그래픽 기반)이 존재한다.
3. 입력값을 바꾸면 동일한 알고리즘을 활용해 서로다른 이미지를 반복적으로 생성할 수 있다.

 

AI 방식과 procedural 방식 모두 입력 파라미터를 받아 가변적으로 이미지를 생성할 수 있어야 한다. 이때 AI 방식은 자연어로 된 프롬프트를, procedural은 텍스트로부터 얻은 임의의 파라미터를 입력값으로 사용한다. 예를 들자면 speed는 R 값으로, fun은 B 값으로, sad는 G 값으로 파라미터를 정하여 색상을 만드는 방법이다.

 

 

 

아티스트와 클라이언트에 책임을 넘기자 (new!)

기존 방식의 시나리오 이미지

기존 방식은 서버가 직접 이미지를 생성하고 이를 클라이언트에 전달하는 구조다. 그래서 서버 개발자에게 특히나 책임이 몰려있는 상태였는데, 이를 클라이언트와 아티스트에 위임하는 방향으로 구조를 제안한다.

 

이미지 생성 시나리오

새로운 이미지 생성 시나리오

 

역할	책임
아티스트	노드 기반 템플릿 제작 (JSON 변환 가능)
서버	파라미터와 템플릿 전달
클라이언트	렌더링 및 시각화 수행

 

 

1. 아티스트가 이미지 출력 템플릿을 만든다.

• 툴: UE5 / Substance Designer / Blender 등 상용 노드 기반 에디터 사용
• 방식: 노드 기반의 절차적 이미지 생성 그래프를 구성
• 출력물: 렌더링 로직 = 노드 그래프 구조를 JSON으로 변환한 템플릿으로 입력 파라미터를 바꾸어 다양한 이미지를 생성할 수 있다.

 

2. 서버에서 이미지 생성 이벤트 발생 시

• 서버는 템플릿(노드 구성 JSON 데이터)과 입력 파라미터(색상, 좌표, 강도 등)를 클라이언트에 전달한다.
• 서버는 생성된 이미지 파일을 보관하지 않고, 템플릿 정보와 파라미터값만 관리한다.

 

3. 클라이언트에서 렌더링을 수행한다.

• 클라이언트는 받은 템플릿과 파라미터를 바탕으로 Canvas/WebGL/Three.js 등으로 실시간으로 이미지를 렌더한다.
• 출력물은 정적인 2D 이미지가 아니어도 가능해야 한다.(절차지향적으로 렌더된 이미지이기 때문)

 

예상되는 장점은 아래와 같다. 

 

1. 서버 부하 감소

이미지 렌더링 로직을 클라이언트에 위임함으로써, 특히 생성형 AI를 사용하지 않는 경우 서버의 처리 비용을 크게 줄일 수 있다.

 

2. 확장성과 유연성

템플릿과 파라미터만 주어지면 클라이언트에서 동적 UI, 애니메이션, 인터랙티브 요소까지 확장 가능하다.

 

3. 디자이너 중심의 튜닝 가능성 확대

파라미터만 조절해도 결과물이 바뀌기 때문에, 코드 수정 없이도 아티스트가 직접 결과물을 조정할 수 있다.

 

---

 

그래서 발표 후 동의를 얻어 새로운 방법으로 검토를 시작했다. 아래는 전달목적으로 간단히 작성한 검토 항목이고, 클라개발자는 기말고사를 앞두고 바쁜 상태라 라이브러리 검토는 내가 담당하고 있다. 언릉 넘겨받아주시길...