개요

말로만 그림을 설명하고 상대가 그리게 하는 게임이 있다. 설명이 자세할수록 그림이 닮아갈 거라 믿게 된다.

나도 그렇게 믿었다. 도면만 제대로 뽑아주면 AI가 잘 만들 거라 생각해서, GPT로 정면·측면·단면·분해도까지 담은 도면을 만드는 데 시간을 바쳤다.

그런데 Blender 안의 로봇은 아무리 설명을 보태도 blockout(큰 덩어리만 잡은 초안 모델)에서 더 나아가지 않았다..

Minor On Air는 로봇 광부들이 거대한 생명체 안에서 광석을 캐는 1인칭 협동 게임이다. 이번엔 플레이어가 조종할 그 로봇을 AI로 모델링해 보려 했다. ChatGPT 6.1-sol과 Claude Opus 5.5를 번갈아 썼고, AI가 Blender를 직접 조작하게 해주는 Blender MCP를 연결했다. 설명을 어떻게 보탰고, 그림이 왜 끝까지 닮아가지 않았는지 적어보겠다!

설명할 그림: Variant C 도면

기획 단계 콘셉트 시트의 로봇은 다리가 6개였다. 콘셉트 안에서는 그렇게 마무리했지만, 설계는 처음부터 4족이었다. 그 설계안 중 고른 것이 Variant C다.

  • 다리 B형: 관절이 외장 안에 숨은 복합 관절
  • 움직이는 귀
  • 등 해치를 열면 실제로 비어 있는 수납공간
  • 돌출 꼬리 없음, 해치 손잡이는 낮게

GPT로 만든 최종 도면이 이것이다.

Minor On Air 플레이어 로봇 Variant C 최종 도면. 정투영 5면, 주요 디테일, 표정 8종, 내부 단면, 파츠 분해도, 다리 관절, 가동 범위, 색상 변형

정면·측면·후면·상면·하면에 대략적인 치수(높이 약 1.0m, 귀 포함 폭 약 1.4m), 표정, 단면, 분해도, 관절 구조, 가동 범위, 색상 변형까지 들어 있다. 사람 모델러에게 넘겨도 될 만큼 자세해 보였다.

이 도면이 “설명”이고, Blender 안의 모델이 “그림”이다.

첫 그림은 책상이었다

도면과 요구사항은 다음 작업자(AI)에게 넘길 인수인계 묶음으로 정리했다. 설계 명세, 확정/제안/미확정 결정 목록, 좌표계, 검사 기준, 작업 지시문, 그리고 모델을 만드는 Python 스크립트 뼈대까지.

그런데 이 묶음에 도면 이미지 3장이 빠져 있었다. 설명서만 있고 그림은 없이 게임이 시작됐다. AI는 텍스트 요구사항만으로 Blender MCP를 통해 blockout을 만들었다.

도면 없이 텍스트 요구사항만으로 만든 첫 blockout. 노란 상자 몸통에 기둥 다리 4개와 작은 귀가 달려 책상처럼 보인다

책상이다..

그런데 이 모델은 정해 둔 검사를 거의 다 통과했다.

검사 결과
전체 크기 폭 1.400 / 높이 1.000m
해치 0~70° 개방 15개 자세에서 간섭 없음
귀 ±15° 14개 자세에서 간섭 없음
다리 관절 조합 900개 자세에서 외부 간섭 없음
같은 입력으로 다시 생성 0.000001m 단위까지 일치
원본 외형 대조 판단 불가(원본 누락)

검사 덕분에 진짜 버그도 잡혔다. 해치 회전 부호가 반대라 뒤쪽이 아래로 내려가던 것, 다리 윗부분이 몸통 바닥을 파고들던 것. 하지만 이 검사들은 “움직일 때 부딪히나”만 물었고 “도면을 닮았나”는 묻지 않았다. 마지막 줄만 판단 불가로 남은 채, 나머지 PASS는 책상에게 주어졌다.

도면을 붙이자 곡면이 됐다

빠진 도면을 대화에 직접 첨부하자 그림이 확 달라졌다.

도면을 첨부한 뒤 만든 곡면 모델. 타원체 몸통, 검은 유리 얼굴, 주황 링 눈, 상단 램프, 소시지 같은 다리

상자가 타원체로, 판자가 유리 얼굴과 링 눈으로 바뀌었다. 귀가 안쪽으로 15° 접히면 몸통에 닿아서 귀 회전축을 옮기는 등, 움직이는 부분의 검사도 계속 돌았다.

다만 색은 피부색에 가깝고 다리는 소시지처럼 부풀었다. 그리고 한 번 고칠 때마다 여러 곳이 같이 바뀌었다. 그래서 외형을 먼저 맞추고, 한 번에 많이 바꾸지 말라고 요청했다.

그 뒤로는 파츠를 하나씩 맞췄다. 몸통 → 얼굴 → 램프 → 귀 → 다리 순서로, 파츠 하나를 고치고 치수를 재고 접합부를 확인한 뒤 저장했다. 저장본(checkpoint)이 다섯 개 남았다.

파츠별 규격을 맞춰 조합한 모델. 노란 몸통, 검은 얼굴, 자주색 귀, 발끝이 검은 다리

전체 크기는 1.400 × 1.500 × 1.000m로 도면 수치와 맞았다. 그런데 나란히 놓고 보면 여전히 다른 로봇이다. 도면의 로봇은 동글동글하고 다리가 짧게 몸 아래로 숨는데, 이쪽은 길쭉하고 다리가 옆으로 뻗어 있다. 치수가 맞는다고 닮는 건 아니었다.

설명을 더 자세히: 도면을 다시 그리다

그림이 안 닮으면 설명을 보태는 게 이 게임의 본능이다. 그래서 도면 자체를 섹션별로 다시 그리기 시작했다.

01 정투영 시트부터 GPT 이미지 생성으로 보완했다. 이때 직접 짚은 오류는 이랬다.

  • 상면에서 귀가 몸 뒤쪽에 달려 보인다.
  • 상면에서 램프가 위로 뚫려 있는 것처럼 보인다.
  • 측면과 하면에서 발바닥 패드 모양이 서로 다르다.

수정본(v2)에서 상면 귀와 램프는 고쳐졌지만, 하면의 귀 위치는 요청만큼 반영되지 않았다. 같은 로봇을 다섯 방향에서 그린 그림인데, 이미지 생성은 각 방향을 따로 그린다. 정면의 귀와 하면의 귀가 같은 귀라는 보장이 없다.

같은 문제는 원래 도면에도 있었다. 정면 그림에서는 발가락이 3개인데, 발바닥 클로즈업에서는 4개다.

그래도 시트를 네 장 더 만들었다. 표정, 내부 수납 구조, 파츠 분해도, 그리고 후면 해치 확정안이다.

후면 해치 디자인 확정 시트. 정투영 5면과 해치 닫힘·열림, 잠금부, 힌지 커버, 내부 수납공간 디테일

이 해치 시트가 이후 몸통을 맞출 때 기준이 됐다. 설명은 점점 두꺼워졌다.

새로 만들고, 다듬고, 같은 자리를 맴돌다

두꺼워진 설명을 들고 그림을 아예 새로 그렸다. 기존 모델을 버리고 몸통, 얼굴, 램프, 귀, 다리, 해치, 수납공간, 표정 9종을 따로 만들어 조립했다.

새로 만든 파츠 조립본. 둥근 몸통, 큰 검은 얼굴, 자주색 귀, 발가락 패드 3개가 달린 발

지금까지 중 가장 도면을 닮았다. 해치는 실제로 열리고, 표정은 값 하나로 바뀐다. 이걸 다시 비율 단위로 다듬었다. 귀를 처지게, 발에 어깨선을 넣고, 다리를 원통 대신 위가 넓은 형태로. 수정 기록만 92건이 남았다.

비율과 실루엣을 다듬은 수정본. 귀가 처지고 발이 넓적해졌다

빠른 확인을 위해 피드백 렌더도 고정했다. 640×640, 가벼운 설정으로 한 장에 0.2~0.3초. 대신 결과를 볼 때마다 다음 수정은 작아졌다.

  • 정면 윤곽: 몸통 최대 폭 2.1% 축소
  • 측면 윤곽: 등 곡선 꼭짓점 33개를 앞뒤로만 이동

몸통 한 오브젝트만, 정해진 꼭짓점만, 정해진 축으로만. 다른 파츠가 하나도 안 바뀌었다는 것까지 확인하는 꼼꼼한 수정이었지만, 렌더를 나란히 놓으면 차이가 거의 안 보였다. 미세 수정만 반복한다고 지적하자 그제야 몸통을 크게 다시 만들었다.

원본 측면에서 추정한 몸통 윤곽(파란 점선), 이전 몸통, 재구성한 몸통 비교. 재구성 몸통은 앞뒤 깊이가 크게 늘었다

  이전 재구성
몸통 깊이 1.160 1.800(+55%)
몸통 높이 1.588 1.740(+9.6%)
꼭짓점 144 112

몸통이 55%나 얕았는데, 그동안은 2%씩 고치고 있었다.

그리고 몸통이 커지자 이번엔 해치, 테두리, 수납공간 안감이 예전 몸통 자리에 그대로 남아 맞지 않았다. 하나를 도면에 가깝게 고치면 그 파츠에 붙어 있던 나머지가 어긋났다.

설명이 그림까지 닿지 않는 이유

돌아보면 설명이 부족해서가 아니었다. 그리는 쪽이 설명을 숫자로 옮길 방법이 없었다.

  • 도면에는 카메라가 없다. GPT 도면은 원근이 들어간 렌더 이미지라, 픽셀을 미터로 바꿀 기준이 없다. 위 비교의 파란 점선도 사람 눈으로 따라 그린 추정선이다.
  • 가려진 곳은 그려져 있지 않다. 귀와 발에 가린 몸통 아래쪽 윤곽은 어느 시트에도 없다. 그 자리는 매번 추측으로 채웠다.
  • 방향끼리 서로 다르다. 정면 발가락 3개와 발바닥 발가락 4개처럼, 다섯 방향 그림이 한 로봇이라는 보장이 없다. 어느 쪽을 믿을지는 결국 사람이 정해야 했다.
  • 하나를 고치면 이웃이 어긋난다. 파츠마다 접합부가 있어서, 큰 수정 한 번이 작은 수정 여러 번을 다시 불러왔다.

자세한 설명은 “무엇을 그릴지”는 알려줬지만, “얼마나 틀렸는지”는 알려주지 못했다. 틀린 정도를 모르니 수정은 작아지거나(2%씩), 너무 커지거나(+55%) 둘 중 하나였다.

설명 대신 규칙을 주기로 했다

여기서 방향을 바꿨다. 아무리 시도해도 blockout에서 더 발전하기 어렵다는 걸 깨닫고, 도면을 더 그리는 대신 하네스 엔지니어링을 해보기로 했다.

하네스는 모델 자체가 아니라 모델이 일하는 틀이다. 어떤 도구를 쓰게 할지, 무엇을 고쳐도 되는지, 고친 뒤 무엇을 재는지, 어떤 결과를 남기는지. 게임으로 치면 설명을 더 하는 대신, 그리는 사람에게 자와 지우개와 “한 번에 한 획만, 그을 때마다 보여주기” 같은 규칙을 쥐여주는 쪽이다.

이미 그 흔적은 있었다. 다음 세션에 작업을 넘길 때 묶은 패키지에는 수정 전 상태를 저장하는 함수와 “몸통만 바뀌었는지” 확인하는 함수가 들어 있었다. 이걸 대화마다 다시 설명하는 대신 저장소로 만들기로 했다. 그 저장소에서 무슨 일이 있었는지는 다음 글에 이어서 적겠다.

아직 확인하지 못한 것

  • 도면 원근을 보정할 카메라 정보 없이, 이미지에서 실제 치수를 얼마나 뽑을 수 있는지
  • 가려진 부분의 형상을 추측이 아니라 관측으로 채우려면 몇 장의 보조 뷰가 필요한지
  • 처음부터 파츠별로 따로 만들었다면 접합부가 덜 어긋났을지

더 읽어볼 만한 것들

소감

도면이 자세해질수록 될 거라 믿고 시간을 쏟았는데, 그림은 blockout 근처에서 계속 맴돌았다.. 그래서 설명을 더 보태는 대신, 그리는 쪽에 규칙을 쥐여주는 쪽으로 방향을 틀었다.