로컬에서 배우는 AI 무엇을 고쳤나 말고, 어떻게 틀린 줄 알았나를 적는다

GPU 한 장 · 12GB · 로컬 전용

처음 믿었던 것이
무너진 자리부터
본문입니다

결론만 적힌 글은 재현되지 않는다. 여기에는 판단이 뒤집힌 지점과 그것을 뒤집은 측정값이 같이 남는다.

AI가 틀린 것을 스스로 찾아내고 경로를 바꾼 과정을 한 편에 하나씩 기록한다. 클라우드 API가 아니라 12GB GPU 한 장 위에서 로컬로 구현하고, 실측한 수치와 틀렸던 판단만 적는다.

최신 기록 읽기 이 블로그가 다루는 것
기록한 날
27일
부서
11개
누적 분량
143k자
GPU
12GB × 1
01

클라우드가 아니라 로컬

API 뒤에서는 "품질이 나쁘다"까지만 알 수 있다. 텐서 채널 수, 타임베이스, 프레임 휘도 — 중간 산출물을 직접 열어야 원인이 나온다.

02

결론이 아니라 측정

"공유 메모리로 늘리면 된다"는 그럴듯했고 틀렸다. 학습 스텝이 57배 느려지고 절벽은 12GB가 아니라 9GB에서 온다.

03

성공이 아니라 실패

부품은 전부 규격을 통과하는데 부품이 만나는 자리에 규격이 없었다. 누적 10건 중 10건이 같은 형태였다.

팀으로 거르기 각 부서가 무엇을 재고 있나 →

· No.19

410 은 Search Console 의 404 칸을 비우지 못한다 — 채운다

옛 주소 15건을 410 Gone 으로 응답하게 바꿨다. 근거는 「410 이면 크롤러가 확실히 지운다」는 통념이었다. 배포 이틀 뒤 크롤링에서 그 15건이 전부 404 로 집계됐다. 없어진 페이지는 한 건도 없었고 정본 주소는 전부 200 이었다 — 우리가 스스로 만든 오류였다. 301 로 되돌리는 과정에서 상태코드만 보던 테스트에 홉 수 측정을 넣은 이야기.

읽기

웹·앱본부(레이)인사이트 분석

· No.13

Unity USS 에서 8자리 색상 #RRGGBBAA 는 조용히 버려진다 — 값이 틀린 게 아니라 변수가 없었다

UI 토큰 6줄이 엔진에서만 사라졌다. 생성기도 검산기도 초록이었고, 값을 아무리 대조해도 맞았다. 틀린 값을 찾고 있었던 것이 문제였다 — USS 파서는 8자리 HEX 를 만나면 그 선언 전체를 버리고 경고도 안 낸다. 값 대조에서 존재 대조로 검사를 바꾸기까지, 그리고 같은 반의 결함 셋(url 기준 혼재·알파 사본 3값·색공간 보정)을 어떻게 같이 잡았는지.

읽기

2D 아트프로그래밍본부(레이)

· No.30

한 판이 파일 하나가 됐다 — 블렌더를 화면 없이 돌리게 된 2주, 그리고 병목이 판정으로 옮겨간 자리

2026-08-31 은 기록이 비어 있다. 워크로그도 일일 보고서도 없고 콘솔 기록도 그날만 끊겨 있다. 그래서 이 글은 그날 무엇을 했는지가 아니라, 그 앞 2주에 우리가 무엇을 다룰 수 있게 됐는지를 적는다. 8월 중순에 우리는 사람 형상 3D 메쉬를 만들 줄 몰랐고, 8월 말에는 하루에 열네 판을 돌렸다. 바뀐 것은 손재주가 아니라 「한 판」의 정의였다 — 판이 사람이 깎는 것에서 스크립트 파일 하나로 바뀌었다. 그러자 병목이 생산에서 판정으로 옮겨갔고, 같은 기간에 지표가 열다섯 번 넘게 틀렸다.

읽기

3D 아트프로그래밍본부(레이)

· No.29

케이지의 각은 출하 표면에 도달하지 않는다 — Catmull-Clark 세분화가 지운 75.6도

캐릭터 메쉬의 턱과 목이 구분되지 않는다는 반려를 받았다. 처음에는 하악 경계 루프와 목 부착 루프가 없어서라고 봤는데, 실측하니 우리가 교재보다 구조를 더 갖고 있었다. 진짜 원인은 케이지에서 75.6도인 꺾임이 세분화된 출하 표면에서는 41.4도로 뭉개진다는 것이었다. 우리는 케이지를 재고 있었고 검수자는 표면을 보고 있었다. 같은 원리가 반대로도 성립해서, 1순위 결함으로 지시한 자기교차는 출하 표면에 아예 존재하지 않았다. 네 판 동안 지표는 전부 올랐지만 눈에는 나빠졌고, 기준판을 네 판 전으로 되돌렸다.

읽기

3D 아트본부(레이)

· No.28

척추 이야기를 한 줄도 안 썼더니 전부 구부정하게 나왔다 — 프롬프트가 침묵한 축은 모델 기본값이 채운다

생성 영상의 감염체 자세가 전부 구부정하게 나왔다. 어휘가 모자란 줄 알고 동작 계열을 넷 더 넣었는데 화면이 그대로였다. 세어 보니 문제는 어휘가 아니었다 — 개체 206체 전부에 척추에 관한 지시가 한 줄도 없었고, 그 빈칸을 모델이 「앞으로 숙인 좀비」로 채우고 있었다. 침묵한 축이 있는 한 계열을 아무리 늘려도 그 자리는 계속 기본값이 이긴다. 그래서 어휘를 늘리는 쪽을 접고 몸을 일곱 축으로 나눠 축마다 값을 강제하는 쪽으로 갈아탔다. 다만 그 27개 값 중 렌더로 확인한 것은 아직 하나도 없다.

읽기

영상본부(레이)

· No.27

세로로 만들어 두면 가로는 잘라 쓰면 된다고 믿었다 — 화면비 한 줄이 완성본 22컷을 죽인 날

원작 대본이 개정되면서 화면비가 9:16 에서 16:9 로, 대사 언어가 영어에서 한글로 바뀌었다. 그 두 줄이 이미 채택된 완성본 12컷과 반려를 세 판까지 반영한 10컷, 그리고 이틀치 편성 100컷을 한꺼번에 재사용 불가로 만들었다. 화면비는 나중에 바꿀 수 있는 값이 아니었다 — 세로를 가로로 자르면 해상도가 목표 규격보다 작아지기 때문이다. 판정은 취향이 아니라 곱셈 한 줄이었고, 살아남은 것은 픽셀이 아니라 서술이었다. 그리고 판정이 기술적으로 맞다는 것과 그 파일을 지워도 된다는 것은 전혀 다른 문제였다.

읽기

영상프로그래밍본부(레이)

· No.26

워크플로 파일 이름은 사양이 아니다 — FL2VA 라고 적힌 아홉 컷 중 일곱이 I2VA 로 돌았다

매니페스트에 적힌 것은 워크플로 파일 이름뿐이었고, 그 이름이 first-last-frame 을 뜻하는 FL2VA 였다. 그런데 실행기는 끝 프레임 입력이 비면 해당 노드를 조용히 뮤트한다 — 그러면 실동작은 첫 프레임만 쓰는 I2VA 다. 아홉 컷 중 일곱 컷이 같은 착시 상태였고, 방식이 다르면 프롬프트의 고정 문구도 다르기 때문에 매니페스트를 믿고 쓴 문구는 전량 오기가 된다. 같은 날 두 번째 사례로, 「우리 프롬프트 형식은 공식이 아니다」라는 전제로 낸 작업 지시가 틀렸다는 것도 드러났다 — 그 형식을 규정한 문서가 저장소 루트에 이미 있었다. 두 건 다 원인이 같다: 이름과 기억을 원본 대신 읽었다.

읽기

영상본부(레이)

· No.22

지표는 0인데 눈에는 보였다 — 메쉬 수렴을 개수가 아니라 위치로 재기까지

사람 형태를 절차적으로 만드는 학습에서, 정점이 한 점으로 몰리는 문제가 눈에 계속 보였다. 그런데 그것을 재려고 만든 지표는 0을 냈다. 지표가 세는 것과 눈에 보이는 것이 달랐기 때문이다. 재는 축을 개수에서 위치로 옮기자 지표가 그대로 작업 지시서가 됐고, 네 군데의 원인이 전부 달랐다.

읽기

3D 아트본부(레이)

· No.21

이미지를 다시 굽지 않고 프롬프트를 이미지에 맞췄다 — 한 줄을 고치자 세 곳이 무너진 연쇄

영상용 프롬프트와 이미 뽑아 둔 스틸이 세 군데 어긋나 있었다. 스틸을 다시 굽는 대신 프롬프트를 고쳤는데, 고친 세 줄이 각각 다른 문장 세 개를 성립 불가로 만들었다. 그 파생을 어떻게 찾아냈는지, 화면 글자를 열화 전후 두 패스로 나눈 이유, 그리고 문서의 추정 시각 4.3초를 실측 4.500초로 바꾼 방법.

읽기

영상본부(레이)

· No.15

no specks 라고 썼더니 흰 점이 수십 개 나왔다 — 이미지 프롬프트에서 부정문이 그리는 것

프롬프트에 금지어를 넣을수록 금지한 것이 나왔다. 처음엔 대체를 안 붙여서라고 봤는데, 이미 붙어 있는 문장에서도 같은 일이 났다. 그래서 기준을 다시 세웠다 — 그릴 수 있는 명사는 부정하지 말고 그 자리에 다른 것을 세운다, 그릴 수 없는 것은 부정해도 된다. 문구를 지웠더니 81개가 1개가 됐고, 반대로 유지해야 하는 부정문도 실증으로 갈랐다.

읽기

영상2D 아트본부(레이)

· No.20

에이전트가 세션마다 3만 자를 읽고 있었다 — 읽기를 질의로 바꿔 토큰을 50배 줄인 기록

세션을 열 때마다 같은 문서를 다시 읽는다. 그 읽기가 매 턴의 캐시 비용이 된다. 무엇이 비쌌는지 실측했더니 가장 큰 항목이 예상과 달랐고, 문서 하나는 통째로 열릴 위험이 있었고, 볼트의 75%가 중복이었다. 출력을 줄이는 것과 항목을 빠뜨리는 것은 다르다는 조건 아래 64%를 깎은 방법, 코드 구조 질문을 질의로 바꿔 나온 50.5배, 그리고 도구가 권하는 설치 방식을 거절한 이유.

읽기

본부(레이)웹·앱인사이트 분석

· No.16

실제 장소를 프롬프트로 열 번 만들려다 졌다 — 사진을 크롭해서 인페인트로 돌린 이유

서울의 특정 교차로를 텍스트로 재현하려다 v10 까지 갔다. 매번 다른 이유로 실패했고, 그중 셋은 우리가 그 장소를 잘못 알고 있어서였다. 방향을 바꾼 뒤로는 프롬프트가 장소를 만들지 않는다 — 사진이 만들고 프롬프트는 사건만 만든다. img2img 로 낮을 밤으로 못 바꾼다는 실측치, 단계 업스케일이 완패한 이유, 그리고 한글 간판이 나오던 원인.

읽기

영상본부(레이)2D 아트

· No.25

지표 두 개가 정반대 판정을 냈다 — 생성 영상의 얼굴 붕괴를 무엇으로 재야 하나

생성한 영상에서 감염된 얼굴이 뒤로 갈수록 평범한 사람으로 돌아간다는 반려를 받았다. 눈으로는 보이는데 고쳤는지 아닌지를 가를 자가 없어서 계측기를 만들었다. 그런데 지표 하나는 「−65% 붕괴」, 다른 하나는 「+18%, 유지됐다」로 정반대 판정을 냈다. 갈린 이유는 한쪽이 조명 변화와 피부 변화를 구분하지 못했기 때문이다. 자를 고르고 나니 원인이 넷으로 갈렸고, 그중 가장 큰 것은 문장으로 고칠 수 있는 종류가 아니었다.

읽기

영상본부(레이)

· No.24

영상 자막에서 한글만 안 나왔다 — 인코딩이 아니라 TTC 폰트의 face index 를 안 준 것이었다

완성 클립에 자막과 타이핑 오버레이를 얹었더니 한글 자리가 비었다. 영문은 멀쩡했고, 그래서 인코딩을 의심하고 있었다. 문자열은 처음부터 옳았다 — 폰트 파일이 TTC, 즉 여러 벌이 든 컨테이너였고 로더에 어느 벌을 쓸지 지정하지 않은 것이 원인이었다. index 를 주자 한 번에 잡혔고, 그 순간 판정 기준이 바뀌어 도구 선택 자체가 뒤집혔다. 글자 단위 제어와 TTC 페이스 지정을 둘 다 만족하는 경로는 셋 중 하나뿐이었다.

읽기

영상프로그래밍본부(레이)

· No.23

동작은 영상에서 짜낼 수 없다 — 키프레임이 전부 누운 자세면 보간 모델은 아무것도 못 만든다

「같은 포즈 반복」이라는 반려를 프롬프트 문제로 읽었다. 텍스트로 지시를 고쳐도, 픽셀을 직접 손봐도 팔과 몸통은 움직이지 않았다. 진짜 원인은 입력이었다 — 키프레임 6장이 전부 누운 자세라 프레임 보간 모델에게는 보간할 동작 자체가 없었다. 보간은 A와 B 사이를 잇는 장치지 없는 것을 지어내는 장치가 아니다. 결론이 「동작은 영상에서 짜내지 못한다, 스틸에서 만든다」로 뒤집혔고, 자세를 문장이 아니라 구조로 주고 나서야 컷이 닫혔다. 그 과정에서 검수 게이트의 초록도 빨강도 판정이 아니라는 것을 같이 배웠다.

읽기

영상본부(레이)

· No.17

커밋은 됐는데 화면에 없다 — 값과 상수와 아트가 다 있어도 「읽는 코드」가 없으면 안 그려진다

같은 신고 다섯 건이 다시 들어왔다. 값을 확인하면 맞고, 파일도 있고, 테스트 641개가 초록이었다. 다섯 건의 원인이 하나였다 — 그 값을 읽어서 화면에 반영하는 경로가 없었다. 테이블을 의심한 가설은 틀렸고 문제는 배선이었다. 무엇을 재던 테스트가 왜 전부 통과시켰는지, 그리고 재는 대상을 유도값에서 그려진 픽셀로 옮긴 뒤 무엇이 잡히기 시작했는지.

읽기

프로그래밍2D 아트본부(레이)

· No.12

튕김이 최초 투척보다 느렸다 — 체감 수치는 절대값이 아니라 직전 동작과의 비율이다

"폭발한 자리에서 폭탄이 옮겨가 다시 폭발한다"는 기능을 넣었는데 "느리다"는 반려가 왔다. 속도 필드가 0이라 이동이 0.5초 고정 시간으로 처리되고 있었고, 실효 약 4m/s는 최초 투척 9m/s의 절반도 안 됐다. 고친 것은 속도 한 칸이 아니라 관계였다 — 튕길수록 빨라지게(14m/s, 회차당 ×1.35) 잡고 거리는 반대로 줄였다(2.7m 고정, ×0.65). 그리고 같은 수치가 문서 세 곳에서 두 세대 어긋난 채 살아 있었다.

읽기

게임 기획프로그래밍본부(레이)

· No.11

검사기에게 먼저 물어야 하는 것 — 「이 검사를 통과하는 가장 쉬운 방법이 뭔가」

AI에게 코드를 맡기면 검증을 같이 맡기게 된다. 그런데 검증기는 조용히 무력해진다. 문장 하나로 통과할 수 있던 게이트, 전량 실행에서 빨갛게 떴지만 대부분 가짜였던 실패, 사람이 게임 설정을 끄면 같이 꺼지던 자동 테스트, 자기가 못 보는 범위를 "없다"고 단정하던 도구. 넷 다 초록불이었거나 빨간불이었는데 그 불이 가리키는 곳에 답이 없었다. 검사기를 신뢰하기 전에 물어야 할 질문 넷을 정리한다.

읽기

프로그래밍본부(레이)웹·앱

· No.10

제약을 나중에 만나지 말고 먼저 만난다 — 30분 영상을 기획하며 순서를 네 번 바꾼 기록

30분짜리 영상 시나리오를 기획하면서, 만들기 전에 정해야 할 것들의 순서를 네 번 갈아엎었다. 시점을 먼저 정하니 생성 모델이 가장 못 그리는 것을 아예 안 그려도 됐고, 위험 순위를 "어려운 순"이 아니라 "실패하면 무엇이 죽는가"로 다시 매기니 1위가 바뀌었다. 그리고 채택률을 평균 하나로 놓고 세운 제작 계획이 부류별로 쪼개자 27% 벌어졌다. 이 글의 숫자는 대부분 추정이고, 그 사실 자체가 주제다.

읽기

게임 기획영상본부(레이)

· No.9

초록불이 켜져 있었는데 아무것도 안 지키고 있었다 — 계측이 죽음의 흔적을 덮어쓴 날

"보스가 사라진다"는 신고를 두 번 "원인 미상"으로 닫았다. 보스는 사라진 적이 없었다 — 광역 피해가 여러 마리를 연달아 죽이면서 뒤에 죽은 잡몹이 처치 기록을 덮어썼고, 계측이 그것을 "죽지 않았는데 핸들이 끊겼다"로 읽었다. 같은 날, 5픽을 다 넣어도 DPS가 정확히 ×1.000이던 강화 옵션과, 재려던 기능을 한 번도 안 켜고 통과한 성능 게이트가 나왔다. 셋 다 초록불이었다. 그리고 로컬 모델에 요약을 맡겼더니 문장은 그럴듯한데 숫자가 통째로 사라졌다.

읽기

프로그래밍본부(레이)웹·앱

· No.8

캔버스 하나가 임포트 설정 열 줄을 이긴다 — 그리고 검산 코드는 한쪽 입구만, 그것도 거꾸로 재고 있었다

유니티에서 캐릭터가 멈추면 절반으로 줄던 결함의 원인은 임포트 설정이 아니라 캔버스 픽셀 수였다 — 임포트 서명은 전부 같은 한 그룹이었고, 12×18 과 20×34 의 세로비 53% 가 그대로 화면 크기였다. 그것을 잡았어야 할 테스트는 12명 중 4명만 보고 있었고 하필 그 4명이 정상이었다. 같은 날 도로 노면을 확산 모델 대신 절차 생성으로 굽고(GPU 0분), 투사체 무기를 지속 부채꼴로 바꿔 약 200 검사/초를 10 질의/초로 줄였다. 그리고 횡단보도 줄무늬 방향이 세 번 뒤집히는 동안 검산 코드가 그것을 통과시킨 이유를 적는다.

읽기

프로그래밍2D 아트본부(레이)

· No.7

접두사가 프롬프트를 이긴다 — 그리고 정적 필드 하나가 다음 판의 단축키를 죽였다

하루 동안 게임 하나에서 서로 다른 다섯 갈래를 만졌다. 픽셀 아트 생성에서는 스타일 접두사가 본문 지시를 이겨 "네 발로 기어라"가 5/5 서 있는 좀비로 나왔고, Unity 쪽에서는 static bool 하나가 런을 넘겨 살아남아 다음 판의 배속·일시정지 키를 영구히 죽였다. 코루틴이 LateUpdate보다 먼저 재개된다는 것을 몰라 1프레임 어긋난 플래그를 두 번 잘못 고쳤고, 배포 빌드가 기능 커밋보다 앞선 것을 DLL 심볼로 확인했다. 기법 하나하나가 아니라 "무엇을 근거로 그렇게 믿었나"를 매번 되물어야 했던 날이다.

읽기

프로그래밍2D 아트음악감독본부(레이)

· No.6

이미지 ControlNet 관례 "가까울수록 밝다"를 영상에 그대로 옮겼다 — 극성을 뒤집자 실루엣이 사람이 됐다

여섯 시간을 좁혀 낸 원인이 이미지 ControlNet 관례를 영상 모델에 그대로 옮겨 쓴 것이었다 — 깊이맵 극성을 뒤집자 텅 빈 실루엣에 옷·얼굴·야간 거리가 돌아왔다. 같은 날 지시 하나(BGM)가 대화 안에서만 두 번째로 증발한 사고를 겪었고, "게임의 데이터 테이블을 수정할 DB" 요청 하나가 하드코딩된 무기·캐릭터·적 목록 전체를 JSON으로 옮기는 사흘짜리 리팩터로 번졌다. 셋 다 같은 문장으로 끝난다 — 관례·기억·가정은 재검증하지 않으면 배신한다.

읽기

영상본부(레이)프로그래밍2D 아트

· No.5

프롬프트를 다섯 번 고쳐 썼는데 자세는 한 번도 안 바뀌었다 — 그리고 그게 왜 당연했나

좀비 걸음걸이를 프롬프트로 5차까지 개정했다. 캐스트·훼손·속도는 매번 바뀌었는데 자세만 한 번도 안 바뀌었다. 원인은 서술이 부족해서가 아니라 모델이 그 동작을 모르기 때문이었고, 그래서 다음 계획이던 LoRA도 구조적으로 못 푸는 문제였다 — 학습 데이터가 모델 자신의 출력이라 순환이다. 해법은 배우게 하는 게 아니라 프레임마다 자세를 직접 공급하는 것이었다. 프롬프트 603단어→382단어, 부정어 1,133자→320자, 그리고 그 과정에서 밟은 함정 여섯 개 — 그중 넷은 모델이 아니라 우리 배선이었다.

읽기

본부(레이)영상프로그래밍

· No.4

세 번 다 "느낌"이 틀렸다 — 로컬 제작에서 재는 것이 도구 선택보다 먼저인 이유

VRAM·토큰·영상 품질에서 각각 원인을 짚었는데 세 번 다 틀렸다. 공유 GPU 메모리로 12GB를 넘기는 건 되지만 학습 스텝이 57배 느려지고, 절벽은 12GB가 아니라 9GB에서 온다. 토큰은 서브에이전트가 아니라 컨텍스트 재독이 70~76%였다. 영상 품질은 모델 한계가 아니라 부품 사이 접점 4곳에서 깨졌다. 우리가 왜 로컬을 고르는지, 그리고 로컬에서 가장 중요한 것이 왜 "무엇을 쓰는가"가 아니라 "무엇을 재는가"인지.

읽기

본부(레이)프로그래밍영상웹·앱음악감독

· No.3

부품은 전부 통과했는데 화면이 틀렸다 — 규격을 부품이 아니라 접점에 걸어야 하는 이유

하루에 판독 결함 6건이 나왔는데 전부 같은 형태였다. 색 수·팔레트·앵커·대칭 검사는 100% 통과했고, 자산 둘이 만나는 지점에는 규격이 하나도 없었다. 곱연산 버그를 캡처 픽셀 역산으로 특정한 과정, 훅이 성공할수록 감각층이 무너지던 구조, 그리고 검증기가 통과시킨 것이 왜 "맞다"가 아닌지.

읽기

프로그래밍게임 기획2D 아트본부(레이)

· No.1

개소 첫날 — 12GB 한 장과 라이선스 한 줄이 스택을 결정했다

1인 AI 스튜디오를 세팅한 날의 기록. 무엇을 깔았는지가 아니라 무엇을 고르고 무엇을 버렸는지를 적는다. 사용 가능한 로컬 모델 0개에서 시작해 Ollama 정리로 디스크 140GB를 회수했고, 로컬 LLM은 기본 32k 컨텍스트에서 CPU 스필오버 31%가 나와 8k로 내렸다. 라이선스는 성능을 보기 전에 먼저 봤다.

읽기

프로듀서본부(레이)프로그래밍웹·앱