손그림 애니메이션 엔진은 왜 그림을 그리지 않고 덮었다 벗겨내는가

이 글은 사용법을 다루지 않습니다. 설치 명령과 단계별 절차는 따로 정리해뒀고, 여기서는 왜 그렇게 만들어졌는지만 봅니다.

오픈소스를 고쳐 쓰기 전에 설계 의도를 먼저 읽고 싶은 분들을 위한 글입니다.

소재는 깃허브 오픈소스 하나입니다. 별 2,600개를 받았는데 커밋이 하나뿐이고, 핵심 파일 하나가 77KB입니다. 설계를 한 번에 끝내고 올린 물건이라 의도를 읽기가 오히려 쉬웠습니다.

손그림 렌더 방식은 왜 두 갈래로 갈리는가

손그림 렌더는 두 방식이 있고, 무엇을 보존할지에서 갈립니다. 선을 다시 뽑는 방식은 입력 그림을 해석하고, 덮었다 걷어내는 방식은 입력 그림을 보존합니다. 다만 후자는 완성된 선화를 이미 갖고 있어야만 성립합니다.

재추출 방식은 이렇게 동작합니다. 입력 이미지에서 윤곽을 검출하고, 그 윤곽을 스트로크 순서로 재배열한 뒤, 펜이 그 순서대로 지나갑니다. 원본 픽셀은 참조일 뿐 최종 화면에 그대로 남지 않습니다.

마스크 방식은 반대입니다. 완성 이미지를 레이어 맨 아래 깔고, 그 위에 종이색 불투명 레이어를 덮습니다. 펜이 지나간 경로를 마스크에서 지워나가면, 지워진 곳에서 원본 픽셀이 드러납니다.

화면에 보이는 것은 펜 경로와 원본의 잉크 영역이 겹치는 부분입니다. 그래서 마지막 프레임은 정의상 원본과 동일합니다.

재추출 방식은 무엇을 잃는가

재추출은 세 가지를 잃습니다. 계조, 얇은 선, 색입니다. 윤곽 검출이 이진화를 전제하기 때문입니다.

보존 대상	마스크 방식	재추출 방식
계조(음영)	원본 그대로	이진화 과정에서 뭉개짐
1~2px 얇은 선	원본 그대로	임계값 아래로 떨어지면 소실
색 정보	원본 그대로	스트로크 재생성 시 재지정
입력 요구사항	완성 선화 필수	사진·러프도 가능

마지막 줄이 맞바꾸는 대목입니다. 마스크 방식이 원본을 완벽히 보존하는 이유는 애초에 그릴 것을 만들지 않기 때문이고, 그래서 완성된 선화가 없으면 아무것도 못 합니다.

사진을 스케치로 바꾸는 게 목적이라면 마스크 방식은 후보에서 빠집니다. 저는 완성 선화를 이미 만들어두는 워크플로였기 때문에 마스크 쪽을 골랐습니다.

펜 경로는 어떻게 결정되는가

펜 경로 알고리즘은 두 가지고, 입력 그림의 선 밀도에 따라 갈립니다. 격자 순회는 밀도와 무관하게 동작하지만 손 느낌이 약하고, 세선화 추적은 손 느낌이 강한 대신 또렷한 선을 요구합니다.

격자 순회는 이미지를 작은 셀로 나누고 잉크가 있는 셀의 중심을 이어 다닙니다. 구현이 단순하고 어떤 그림이든 돌아갑니다. 대신 펜이 실제 선을 따라가지 않아서, 자세히 보면 선 위를 지그재그로 훑습니다.

세선화 추적은 선 자체를 1픽셀 두께로 깎은 뒤 그 골격을 따라갑니다. 펜이 진짜 선 위에 있으니 손으로 긋는 것에 가깝습니다. 다만 선이 흐리면 골격 추출이 끊깁니다.

선이 또렷한 그림이면 세선화가 낫습니다. 흐린 스캔본이나 연필 러프면 격자 쪽이 안전합니다.

채색 단계에서 왜 색이 걸리는가

채색은 위에서 아래로 흐르는데, 잉크 경계를 만나면 그 자리에서 잠깐 멈췄다 넘어갑니다. 물감이 종이 위 선을 만나 고이는 현상을 흉내 낸 겁니다.

기술적으로는 채색 진행 마스크가 잉크 마스크와 만나는 지점에서 진행 속도에 감쇠를 주는 처리입니다. 없어도 색은 칠해집니다.

이 디테일 하나가 손 느낌을 만듭니다. 균일 속도로 내려오면 그라데이션 필터처럼 보이고, 걸렸다 넘어가면 액체처럼 보입니다.

여기에 실무 제약이 하나 붙습니다. 원본 그림이 무채색이면 이 단계가 화면에서 사라집니다. 칠할 색이 없으니 진행 마스크가 움직여도 픽셀이 안 변합니다. 제가 첫 버전을 회색으로만 만들었다가 재생 시간만 늘고 볼 게 없어서 다시 만들었습니다.

이 저장소의 진짜 설계는 코드가 아니라 어디에 있는가

이 저장소의 핵심은 렌더 코드가 아니라 AI 에이전트용 절차 명세입니다. 파이썬 파일 6개는 얇고, 14KB짜리 명세 파일 하나가 작업 순서 전체를 통제합니다.

절차는 일곱 단계입니다. 자막 파싱, 이미지 생성, 좌표 산출, 검증 이미지 출력, 미리보기 편집, 렌더, 병합.

여기에 규칙이 하나 붙어 있습니다. 매 단계 종료 시 정지하고 사람 확인을 받으며, 확인 전에는 다음 단계 파일을 만들지 않는다.

그다음 줄이 이 저장소에서 제일 값나가는 문장입니다.

무응답, 기존의 포괄적 승인, 반대하지 않음 — 이 셋을 승인으로 간주하지 않는다.

왜 자동화 도구에 멈춤을 일곱 번 박는가

자동화의 비용은 실행 시간이 아니라 잘못된 방향으로 실행된 시간입니다. 멈춤은 그 손실의 상한을 정하는 장치입니다.

이미지 100장 생성에 한 시간이 걸린다고 하면, 방향이 첫 장부터 틀렸을 때 손실은 한 시간입니다. 5분 간격으로 확인하면 손실 상한이 5분이 됩니다. 확인 비용은 늘지만 최악의 경우가 12분의 1로 줄어듭니다.

세 가지를 승인에서 뺀 이유도 같습니다. LLM 에이전트는 침묵을 동의로 읽는 경향이 있고, 한 번 잘못 잡힌 방향을 계속 밀고 갑니다. 명시적 긍정만 승인으로 치면 그 경로가 막힙니다.

내가 이 설계를 잘못 읽었던 지점

처음에 저는 이 멈춤 규칙을 과잉이라고 봤습니다. 자동화 도구를 만들어놓고 일곱 번 멈추면 자동화가 아니지 않냐고요.

그런데 제 파이프라인 로그를 뒤져보니 반증이 나왔습니다. 이미지 생성 단계에서 방향이 어긋난 채 79장을 만들고 전량 폐기한 기록이 있었습니다. 그때 저는 승인 게이트를 스타일 확정 한 곳에만 뒀습니다.

원인은 세 갈래였습니다. 게이트가 파일이 있는지만 보고 내용을 안 봤고, 스타일 승인이 개별 이미지 승인을 대신할 수 있다고 가정했고, 중간 점검 비용을 시간 낭비로 계산했습니다.

그래서 방향을 바꿨습니다. 게이트를 세 개로 늘렸습니다. 만들어진 내용 검사, 표본 육안 확인, 그리고 대량 생성 직전 별도 승인. 세 원인에 처방을 하나씩 붙인 겁니다.

남의 코드를 고칠 때 어디까지 건드려도 되는가

번역과 기본값 조정은 동작을 안 바꾸고, 그래서 원본과의 구조 동일성을 기계로 증명할 수 있습니다. 다만 증명하지 않으면 주장일 뿐입니다.

제가 한 검증은 이렇습니다. 원본과 수정본의 AST를 파싱해 함수·클래스 정의를 추출하고 집합으로 비교했습니다. 클래스 5개와 함수 102개가 이름·인자·중첩 구조까지 일치했습니다. 주석과 문자열을 제외한 코드 줄 수는 양쪽 2,193줄로 동일했습니다.

한 곳만 예외입니다. 인자 개수가 맞지 않아 특정 조건에서 예외를 던지던 호출부에서 여분 인자 하나를 뺐습니다. 이건 동작을 바꾸는 변경이라 별도로 기록했습니다.

동작을 바꾸는 변경과 안 바꾸는 변경을 섞어놓으면 나중에 원본과 병합할 수 없습니다. 두 종류를 파일 단위로 분리해두면 원본이 업데이트됐을 때 번역만 다시 얹으면 됩니다.

이 글에서 내가 틀릴 수 있는 곳

세 군데입니다.

렌더 시간 측정은 제 장비 한 대에서 각 1회씩만 잰 값입니다. 11초와 83초의 비율은 반복 측정하면 달라질 수 있습니다.

세선화가 격자보다 낫다는 판단은 제가 쓴 그림 종류에 묶여 있습니다. 선이 굵고 단순한 도식만 넣어봤습니다.

멈춤 일곱 단계가 최적이라는 근거는 없습니다. 이 저자가 일곱을 고른 이유는 문서에 없고, 저는 그 수를 검증하지 않고 그대로 썼습니다.

정리하면 무엇을 하면 되는가

완성 선화가 이미 있으면 마스크 방식을 쓰고, 사진에서 시작해야 하면 재추출 저장소를 찾으세요
선이 또렷하면 세선화, 흐리면 격자로 경로 알고리즘을 고르세요
그림에 강조색을 한 곳 넣어 채색 단계가 화면에 보이게 하세요
자기 파이프라인의 승인 게이트를 세어보고, 대량 생성 직전에 하나가 있는지 확인하세요

네 번째가 제일 값싸고 제일 많이 아낍니다. 저는 79장을 버리고 나서야 넣었습니다.

맨 위에서 커밋 하나에 77KB짜리 파일 하나라고 적었습니다. 뜯어보니 그 77KB 중 렌더 알고리즘은 절반이 안 됐고, 나머지는 언제 멈출지를 정하는 코드였습니다. 별 2,600개가 붙은 이유도 아마 그쪽일 겁니다.

여러분 파이프라인에서 방향이 틀렸을 때 가장 늦게 발견되는 단계는 어디인가요?