Romergo 개발 이야기

끝없는 수정에서 작은 촬영장으로: 이야기를 생성하는 법을 배우며

지난 글에서는 원문을 실제로 플레이할 수 있는 비주얼 노벨로 만들기까지 왜 하나의 과정이 필요한지 이야기했습니다. 사실을 지키고, 캐릭터를 준비하고, 장면을 조립한 다음, 플레이어가 실제로 보는 결과를 확인하는 과정입니다.

그 뒤로 과정은 더 복잡해졌습니다. AI에 그럴듯한 이름을 몇 개 더 붙이고 싶어서가 아닙니다. 이야기를 만들면서 같은 문제에 자꾸 부딪혔습니다. 좋은 이미지를 조금 개선하려다가 오히려 망가뜨리기가 너무 쉽다는 문제요.

처음에는 손을 고쳐 달라고 합니다. 다음에는 사라진 옷을 돌려 달라고 하고, 그다음에는 다리 하나를 지워 달라고 합니다. 네, 실제로 그런 일이 있습니다. 그러다 보면 얼굴이 달라지고, 그림자가 짙어지고, 깨끗했던 배경이 탁해져 있습니다.

한 부분을 고치는 동안 이미지 전체가 계속 바뀝니다. 결국 인정할 수밖에 없습니다. 다섯 버전 전이 더 좋았다고요.

이미지를 고치는 것과 지키는 것은 다르다

특히 답답한 건 변화가 쌓인다는 점입니다. 이미지 A로 B를 만들고, B로 C를 만든 뒤 여러 번 더 시도합니다. 새 버전에는 의도한 수정뿐 아니라 이전에 조용히 바뀐 것들까지 이어집니다.

제 생성 결과에서는 얼굴이 ‘녹고’, 그림자가 무거워지고, 표면에 이상한 흔적이 생기고, 작은 특징이 사라지곤 했습니다. 다음 이미지가 반드시 더 나빠지는 건 아닙니다. 하지만 긴 수정 사슬은 원래 모습에서 벗어날 기회를 너무 많이 만들었습니다.

사람에게 “나머지는 그대로 두고 고개만 돌려 줘”는 명확한 말입니다. 우리는 캐릭터와 방을 이해하고, 다시 말하지 않아도 재킷은 입고 있으리라 생각합니다. 생성기와는 그런 전제를 명시적으로 맞춰야 합니다. 그럴듯한 새 이미지를 만들면서도 우리가 당연히 유지되리라 생각한 것을 깨뜨릴 수 있으니까요.

결국 작업의 상당 부분은 AI와 말이 통하는 법을 배우는 일입니다. 가끔은 정말로 세 번째 다리는 여전히 필요 없다고 설명해야 합니다.

GENERAL: 돌아갈 수 있는 기준

첫 번째 대응은 GENERAL입니다. 캐릭터, 장소, 사물의 승인된 기준 이미지를 만드는 겁니다. 최대한 중립적이고, 고정된 특징이 잘 보이며, 특정 에피소드에만 해당하는 요소는 적게 담습니다.

그다음부터는 ‘직전 수정본 → 다음 수정본’이 끝없이 이어지는 방식을 피하려 합니다. 새로운 상태는 GENERAL에서 출발해 지금 일어나야 할 일을 반영합니다.

장면을 수정할 때는 세 가지를 참고할 수 있습니다.

이전 버전은 보조 참고 자료로 남습니다. 쌓인 오류까지 품은 채 슬그머니 새로운 기준이 되어서는 안 됩니다.

![GENERAL 도식: 이전 버전을 계속 물려받는 대신 새로운 상태는 하나의 승인된 기준 이미지로 돌아간다. 이전 이미지는 보조 참고 자료다.](../assets/ai-film-crew-general.webp)

*실제 생성 결과의 비교가 아니라 접근 방식을 설명한 그림입니다. GENERAL은 안정적인 기준점을 제공하지만 모든 픽셀이 그대로 유지된다는 보장은 아닙니다.*

생성기가 실수하지 않게 하는 마법은 없습니다. 그래도 이제 “전체가 흐트러지면 어디로 돌아가지?”라는 질문에는 분명한 답이 있습니다. 수정의 목표도 달라집니다. 마지막 실패작을 계속 편집하는 대신 같은 캐릭터로 필요한 장면을 만드는 겁니다.

Render Eye: 세계에 있는 것과 화면에 보이는 것

다음 문제는 더 미묘했습니다. 캐릭터 설정에 재킷, 장갑, 벨트, 부츠가 상세히 적혀 있다고 합시다. 그런데 현재 숏은 허리 위까지만 보이고, 한 손은 등 뒤에 있으며, 문이 몸 일부를 가립니다.

어떤 특징을 그려야 하고, 무엇은 가려져야 할까요? 장갑이 가려진 건지 생성기가 잊은 건지는 어떻게 구별할까요?

이 때문에 Render Eye를 개발하고 있습니다. 생성 전에 요구사항을 준비하고, 생성 후에는 결과 이미지를 확인하는 두 가지 역할입니다.

먼저 이야기 설정집에서 저장된 캐릭터, 장소, 사물과 그 상태를 읽습니다. 이어서 카메라 위치, 행동, 플레이어의 주의를 끌어야 할 지점 등 연출과 대조합니다.

중요한 세부 요소마다 완전히 보이는지, 일부만 보이는지, 다른 물체에 가려지는지, 화면 밖인지 결정합니다. 손이 등 뒤에 있다고 장갑이 세계에서 사라지는 것은 아닙니다. 그 각도에서 확인할 수 없을 뿐입니다.

![생성 전후의 Render Eye: 세계 설명과 연출을 바탕으로 보이는 것과 가려지는 것의 요구사항을 정하고, 완성 이미지를 같은 기준으로 확인한다.](../assets/ai-film-crew-render-eye.webp)

이렇게 구체적인 화면 요구사항이 나옵니다. 단순히 “복도에 주인공을 그려 줘”가 아니라 “이 주인공을, 이 옷으로, 이 시점에서, 이 세부 요소가 보이게”입니다. 장면을 이해하는 데 필요한 사물이 실수로 화면 바깥에 숨어서는 안 됩니다.

생성 후 Render Eye는 같은 요구사항으로 돌아옵니다. 의상, 사물, 캐릭터 배치를 확인하고, 인체 구조와 이미지 결함도 별도로 확인합니다. 오류나 불확실성이 발견되면 수정으로 돌려보냅니다. 재킷이 사라진 결과를 받아들인 뒤, 애초에 재킷이 없었던 것처럼 설정을 고쳐서는 안 됩니다.

다만 시스템에 상상 속 초능력을 부여하고 싶지는 않습니다. 이미지를 보는 것은 AI이고, AI도 놓칠 수 있습니다. 필수 검사는 과정을 더 체계적으로 만들지만, 시각 모델을 완벽한 관찰자로 만들지는 않습니다.

연출 감독: 왜 이 장면이 필요한가

옷이 맞고, 얼굴이 유지되고, 모두 제자리에 있어도 장면은 밋밋할 수 있습니다.

이야기는 무엇이 놓여 있느냐만의 문제가 아닙니다. 플레이어가 언제 알아차리는지, 어떤 대사가 먼저인지, 반응에 얼마의 시간을 주는지, 그때 무슨 소리가 들리는지가 중요합니다.

그래서 연출 감독 역할을 따로 만들었습니다. 대사와 반응의 순서, 인물의 등장, 조명, 색감, 음악, 효과음, 쉼, 인터페이스 구성을 장면 가까이에서 다룹니다. 원문은 처음 한 번 읽는 설명서가 아니라 작업 내내 참고하는 자료입니다.

“문 뒤에서 발소리가 들렸다”라는 가상의 문장을 생각해 봅시다.

문을 보여 주고 글을 띄울 수도 있습니다. 먼저 음악을 줄이고, 조용한 실내 환경음만 남긴 뒤, 화면 밖에서 발소리가 들리게 하고, 인물의 반응을 잠시 보여 준 다음 대화를 이어 갈 수도 있습니다. 원문이 방문자를 아직 밝히지 않았다면 카메라가 친절하게 먼저 보여 줘서는 안 됩니다.

같은 복도라도 추리물에서는 단서에, 로맨스에서는 만남에 대한 기대에 시선을 모을 수 있습니다. 차이는 구체적인 결정에서 나옵니다. 요구사항에 ‘분위기: 공포’라고 쓰는 것만으로는 되지 않습니다.

연출 감독은 결정을 연출 계획에 저장합니다. 원작의 사실과 해석은 구분합니다. 차가운 빛은 예술적 선택일 수 있지만, 새로운 추격자를 등장시키면 사건이 달라집니다.

게임에는 또 다른 어려움이 있습니다. 사람마다 읽는 속도가 다릅니다. 대사 전의 쉼과 읽기를 끝낼 때까지 기다리는 것은 다릅니다. 아름다운 4초를 설계했다가 6초가 필요한 사람의 글을 닫아 버릴 수는 없습니다.

밋밋한 장면을 기계적인 효과 모음으로 바꾸고 싶지도 않습니다. 때로는 정지 화면, 단순한 컷, 음악 없는 상태가 맞습니다. 기법에는 목적이 필요합니다.

품질 감독: 의도한 결과가 나왔는가

‘연출 감독’과 ‘품질 감독’은 비슷하게 들리지만 책임을 나눕니다. 연출 감독은 장면을 설계하고, 품질 감독은 결과를 검사합니다.

원문과 연출 계획을 실제 게임에 들어간 결과와 비교합니다. 예쁜 이미지 하나하나뿐 아니라 완성된 장면의 흐름을 봅니다.

인터페이스가 중요한 사물을 가리지는 않나요? 대사가 바뀔 때 듣고 있던 인물이 사라지지는 않나요? 이전 방의 음악이 계속 나오나요? 휴대폰에서 구도가 무너지나요? 조명과 쉼, 소리로 전하려던 정서가 실제로 전해지나요?

검사가 유용하려면 문제를 어디로 돌려보낼지도 알아야 합니다. 이미지 내부의 결함은 생성 단계로, 멀쩡한 캐릭터 이미지의 위치 문제는 조립 단계로 보냅니다. 소리가 너무 일찍 시작한다고 배경을 다시 그릴 필요는 없습니다.

![역할 도식: 원문을 바탕으로 연출 감독이 설계하고, Render Eye가 화면을 준비하고 검사한다. 조립 후 게임에서 품질을 확인하고 해당 단계로 피드백을 보낸다.](../assets/ai-film-crew-roles.webp)

*그림의 Director는 연출 감독, QA는 품질 감독입니다. 간략한 도식이며 조립과 최종 검사에서도 원문을 참고합니다. 돌아가는 화살표는 해당 단계의 수정이지 반드시 모든 작업의 재시작은 아닙니다.*

사람도 생성기를 계속 지키고 있을 필요는 없다

이미지가 빨리 나와도 또 다른 비용이 남습니다. 계속 주의를 전환해야 한다는 점입니다. 채팅을 열고, 그림을 보고, 의견을 쓰고, 자기 일로 돌아갑니다. 몇 분 뒤 다시 반복합니다.

그래서 GENERAL을 묶어서 검토하는 방식도 만들고 있습니다. 서로 독립적인 기준 이미지는 미리 준비한 뒤 한 그룹으로 보여 줄 수 있습니다. 함께 보면 불일치가 눈에 들어오고, 공통 의견이나 개별 의견을 줄 수 있습니다.

이후 필요한 이미지만 다시 만듭니다. 한 번의 실패 때문에 승인된 결과를 잃어서는 안 됩니다. 의존 관계는 여전히 지켜야 합니다. 다음 이미지가 미승인 기준에 의존한다면 먼저 그 기준을 해결해야 합니다.

생성기 자체를 몇 배 빠르게 하겠다는 약속은 아닙니다. 제게 더 중요한 것은 다음 검토를 위해 하던 일을 내려놓는 횟수를 줄이는 것입니다.

거대한 지시 하나 대신 작은 촬영팀

결국 저는 정말 작은 AI 촬영팀을 만들고 있습니다. 설명된 세계, 기준 이미지, 연출, 화면 제작, 조립, 품질 관리가 있는 팀입니다.

이는 에이전트의 작업 과정 안에서 나눈 책임입니다. 각 역할마다 별도로 계속 실행되는 AI가 이미 있다는 뜻은 아닙니다. 결정이 저장되고, 요구사항이 사후에 바뀌지 않고, 수정할 때마다 무엇을 다시 확인해야 하는지 분명해지는 것이 중요합니다.

새 단계에는 이제 도구와 저장되는 계획이 있습니다. 다음은 실제 긴 장에서 시험하는 일입니다. 이야기 전체에 걸쳐 인물, 분위기, 창작자의 집중을 얼마나 잘 지켜 줄까요?

최종 목표는 두꺼운 책을 가져와 한 장을 고르고, 차례로 플레이 가능한 퀘스트로 바꾸는 것입니다. 멈추고, 결과를 확인하고, 중요한 부분을 고친 뒤, 중단한 자리에서 계속할 수 있도록요.

이야기 생성은 ‘좋은 프롬프트 쓰기’보다 훨씬 어려웠습니다. 하지만 이제 어려움을 구체적인 작업으로 나눌 수 있습니다. 안정적인 기준이 필요할 때도, 꼼꼼한 독해가 필요할 때도, 대사 전의 정적이 필요할 때도 있습니다. 그리고 여전히 사람이 장면을 보고 “아니, 여기는 믿기 어려워”라고 말해야 할 때도 있습니다.

개발 블로그로 돌아가기