Gradio Workflow로 AUTOMATIC1111을 다시 지으면 생기는 일

이번에 다룰 글은 Hugging Face가 공개한 Rebuilding AUTOMATIC1111 with Gradio Workflow입니다. 이 글은 예전 Stable Diffusion 시절의 대표 웹 화면이었던 AUTOMATIC1111을 요즘 Gradio로 다시 만들면 어떻게 되는지를 설명합니다. 원문 링크는 제목 아래에 붙어 있습니다.

제가 이 글을 고른 이유는 단순합니다. 많은 사람이 그 화면을 직접 써봤기 때문에, 다시 짓는 과정을 따라가면 추상적인 아키텍처 이야기가 아니라 손에 잡히는 변화로 이해할 수 있기 때문입니다. 그래서 이번 글에서는 화면의 기억을 하나씩 꺼내면서, 무엇이 그대로 남고 무엇이 바뀌었는지를 차근차근 살펴보겠습니다.

안녕하세요, 그 화면 아직 기억하시죠

안녕하세요, 패트릭입니다.

사진관 앞을 지나다가 문 앞에 붙은 사용 설명서를 본 적이 있으실 겁니다. 처음 오는 손님도 순서대로 따라가면 증명사진을 뽑을 수 있게 적어둔 안내문인데요. 예전 AUTOMATIC1111의 첫 화면도 저에게는 그런 안내문처럼 느껴졌습니다. 왼쪽에 프롬프트를 쓰고, 아래에서 크기와 스텝을 고르고, 생성 버튼을 누르면 오른쪽에 그림이 나타나는 흐름이었죠. 처음 써보는 사람도 몇 번 눌러보면 감이 잡혔습니다.

그렇다면 그 익숙한 화면을 왜 지금 다시 만들어야 할까요. 이유는 그 화면이 낡아서가 아니라, 그 화면이 살던 집이 바뀌었기 때문입니다. 원래 AUTOMATIC1111은 Gradio 3 시절에 지어진 집인데, 지금 Gradio는 Blocks 중심으로 구조가 많이 달라졌거든요. 집은 그대로인데 배관과 전기 규격이 바뀌면, 겉은 멀쩡해 보여도 속에서는 하나둘 고장이 나기 마련입니다. 저는 이 글을 읽으면서 리모델링보다 재건축에 가까운 고민이 들어있다고 느꼈습니다.

탭 네 개가 만든 세계는 생각보다 컸습니다

AUTOMATIC1111을 써본 분이라면 txt2img와 img2img라는 탭 이름을 바로 떠올리실 겁니다. 거기에 inpainting과 extras까지 더해지면, 사실상 그 시절 오픈소스 이미지 생성이 하던 일이 거의 다 담겼습니다. 글로 그림을 만들고, 있는 그림을 변형하고, 비어 있는 부분을 메우고, 마지막으로 크기를 키우거나 다듬는 일까지요. 저는 이 구성이 잘한 점이 기능을 많이 넣은 데 있는 게 아니라, 작업의 순서를 정해준 데 있다고 봅니다.

처음에는 글을 넣어 그림을 뽑는 일이 전부처럼 보였습니다. 그런데 막상 써보면 그다음 일이 바로 생기는데요. 마음에 드는 그림이 나왔는데 크기가 작으면 어떻게 할까요. 얼굴은 좋은데 배경 일부가 어색하면 어디를 고쳐야 할까요. 이런 질문이 이어지면서 탭을 옮겨 다니는 흐름이 자연스럽게 몸에 익었습니다. 그래서 그 탭 구조는 단순한 메뉴가 아니라, 사람들이 이미지를 다루는 순서를 정해준 사용법이었죠.

물론 지금 보면 그 순서가 유일한 정답은 아닙니다. 노드를 엮어 쓰는 방식도 있고, 코드를 직접 돌리는 방식도 있으니까요. 하지만 당시에는 설치하고 켜면 바로 쓸 수 있다는 점이 컸습니다. 저는 그래서 AUTOMATIC1111을 모델 자체보다 화면의 발명품에 가깝게 봅니다. 좋은 모델을 많은 사람의 손에 닿게 만든 것은 결국 그 순서였기 때문입니다.

3점대 위에 지은 집을 옮기는 일은 왜 어려울까

원래 AUTOMATIC1111이 올라가 있던 Gradio 3 시절과 지금의 Gradio 4와 5 사이에는 생각보다 큰 간격이 있습니다. 겉으로 보면 버튼과 슬라이더가 비슷해 보이지만, 화면을 구성하는 Blocks의 문법과 이벤트 처리 방식이 달라졌거든요. 예전 방식대로 짠 코드는 새 버전에서 그대로 돌아가지 않는 경우가 생깁니다. 운영 관점에서 보면 이 차이가 꽤 큽니다. 밤에 버전 하나를 올렸는데 아침에 화면이 깨져 있으면, 그날 하루 작업이 통째로 멈추기 때문입니다.

그렇다면 코드를 조금씩 고쳐서 쓸 수는 없을까요. 짧게 보면 그렇게 할 수도 있습니다. 그런데 길게 보면 낡은 구조 위에 덧칠을 계속하는 셈이라 언젠가는 한계가 옵니다. 특히 이벤트를 연결하는 부분이나 레이아웃을 나누는 부분은 버전이 바뀌면서 권장하는 방식 자체가 달라졌는데요. 예전에는 돌아가던 꼼수가 새 버전에서는 아예 막히는 경우도 있습니다. 제가 예전에 작은 데모를 옮겨본 경험으로 말하면, 버튼 한두 개는 금방 고치지만 화면 전체의 상태가 얽혀 있으면 손이 훨씬 많이 갑니다.

이 글에서 다시 짓자는 말이 나오는 배경도 여기에 있습니다. 낡은 것을 버리자는 선언이라기보다는, 지금 규격에 맞춰서 같은 사용감을 되살리자는 쪽에 가깝습니다. 집의 외관은 예전 그대로 두되, 배관과 배선을 지금 기준에 맞게 새로 깔자는 것이죠. 그렇게 보면 재건축은 과거를 부정하는 일이 아니라, 기억을 현재에서 쓸 수 있게 만드는 일입니다.

슬라이더 하나가 결국 사용자와의 약속입니다

다시 만들 때 가장 먼저 손이 가는 부분은 생성 옵션을 다루는 조작 영역입니다. 스텝 수와 CFG scale, 샘플러, 시드, 가로와 세로 크기 같은 값들은 그림의 결과를 직접 바꾸기 때문에 화면에서도 가장 자주 만지게 됩니다. 이 글에서 소개하는 방식은 이런 값들을 Gradio의 Slider와 Dropdown, Number 같은 부품으로 하나씩 옮기는 일인데요. 표면적으로 보면 단순합니다. 실제로는 그렇지 않습니다. 숫자 하나를 어떻게 보여주느냐에 따라 사용자가 느끼는 난이도가 완전히 달라지기 때문입니다.

예를 들어 스텝 수를 생각해보겠습니다. 숫자를 직접 입력하게 할 수도 있고, 범위를 정해 밀어서 고르게 할 수도 있습니다. 직접 입력은 자유롭지만 처음 쓰는 사람에게는 막막하고, 슬라이더는 고르기 쉽지만 범위를 잘못 정하면 정작 자주 쓰는 값이 밖에 놓이게 됩니다. 그래서 범위의 양 끝을 어디에 두느냐가 은근히 중요합니다. CFG scale도 마찬가지인데요. 값을 조금만 바꿔도 그림의 분위기가 달라지다 보니, 눈금이 너무 성기면 조정이 어렵고 너무 빽빽하면 고르기가 피곤해집니다.

저는 이 대목을 보면서 화면 부품이 단순한 장식이 아니라는 생각을 다시 했습니다. 같은 모델에 같은 질문을 던져도 설정에 따라 결과가 크게 달라질 수 있다는 것을 경험으로 알고 있죠. 그렇다면 화면의 역할은 숫자를 받아 적는 데서 끝나지 않습니다. 자주 쓰는 값을 손이 닿는 곳에 두고, 위험한 값은 한 번 더 생각하게 만드는 일까지 포함합니다. 다시 짓는 과정에서 부품 하나하나를 고르는 일이 길게 설명되는 이유도 여기에 있다고 봅니다.

뒤쪽 엔진을 갈아끼우면 무엇이 달라질까

화면 다음으로 눈이 가는 곳은 뒤쪽에서 그림을 만드는 엔진입니다. 원래 AUTOMATIC1111은 Stable Diffusion 초기에 맞춰 직접 짠 실행 코드 위에서 돌아갔습니다. 다시 만드는 흐름에서는 그 자리를 Hugging Face Diffusers의 파이프라인이 대신하는 경우가 많습니다. 겉에서 보면 같은 버튼을 누르는 것처럼 보이지만, 속에서는 그림을 만드는 절차를 누가 책임지느냐가 바뀌는 것이죠. 이 차이는 생각보다 중요합니다.

직접 짠 코드는 그 시절 필요에 딱 맞춰져 있었습니다. 원하는 기능을 빠르게 붙이기 좋았지만, 시간이 지나면 고치는 사람이 줄어들수록 유지가 어려워집니다. 반면 Diffusers 같은 공용 파이프라인은 여러 모델과 절차를 같은 모양으로 다루게 해줍니다. 텍스트로 그림을 만드는 파이프라인과 그림을 고치는 파이프라인이 비슷한 방식으로 불린다면, 화면 쪽에서는 값을 넘기는 방법이 단순해집니다. 저희가 새로운 AI 아키텍처를 볼 때도 숫자만 보지는 않습니다. 실제로 무엇이 바뀌었고, 그 변화가 시스템에서 어떤 비용 구조를 만드는지를 함께 보는데요. 여기에서도 같은 질문이 필요합니다.

다만 공용 파이프라인이 만능이라는 뜻은 아닙니다. 예전 AUTOMATIC1111에만 있던 세밀한 동작이나 확장 기능 중에는 새 구조에서 똑같이 재현하기 어려운 것도 있습니다. 그래서 갈아끼운다는 말은 정확하지 않고, 옮겨 심는다는 쪽이 더 가깝습니다. 뿌리가 살 수 있는 부분은 살리고, 환경이 달라져서 살리기 어려운 부분은 새로 접붙여야 하니까요. 저는 이 지점에서 무리하게 똑같이 만들려는 시도보다, 자주 쓰이는 흐름부터 옮기는 선택이 현실적이라고 봅니다.

누르고 기다리고 이어 붙이는 순서를 어떻게 살릴까

AUTOMATIC1111의 진짜 사용감은 버튼 하나에 있지 않았습니다. 만들고, 고르고, 키우고, 다듬는 순서가 끊기지 않고 이어진다는 데 있었죠. Gradio Blocks에서는 이런 흐름을 .click과 .submit, .then 같은 이벤트 연결로 풀어냅니다. 생성이 끝나면 자동으로 업스케일로 넘기거나, 앞 단계의 결과를 다음 단계의 입력으로 넣어주는 방식입니다. 예전에 스크립트나 hires fix 같은 이름으로 불리던 동작도, 다시 짓는 화면에서는 이런 이어 붙이기로 다시 표현됩니다.

여기서 재미있는 질문이 생깁니다. 자동 흐름은 어디까지가 편하고 어디부터가 답답할까요. 전부 자동으로 이어지면 손은 편하지만 중간에 끼어들 여지가 줄어듭니다. 반대로 매번 확인을 거치면 제어가 쉬워지지만 손이 많이 갑니다. 그래서 잘 만든 흐름은 보통 중간 결과를 보여주는 지점을 남겨둡니다. 첫 그림이 나오면 잠깐 멈춰서 고르게 하고, 마음에 드는 것만 다음 단계로 보내는 것이죠. 생각해보면 사람도 일할 때 비슷하게 합니다. 한 번에 끝까지 몰아치지 않고, 중간에 한 번 훑어보고 방향을 정하니까요.

실제 시스템 관점에서 보면 다음 질문이 바로 생깁니다. 단계가 길어질수록 중간에 실패했을 때 어떻게 되느냐는 것입니다. 앞 단계는 됐는데 뒤 단계에서 막히면, 처음부터 다시 돌릴까요 아니면 중간부터 이어갈까요. (참고로 저는 이런 이어 붙이기에서 중간 산출물을 어떻게 들고 있느냐가 체감 속도를 좌우한다고 봅니다. 화면에 보여주는 것과 서버가 들고 있는 것이 어긋나면 사용자는 같은 버튼을 여러 번 누르게 되거든요.) 다시 짓는 일의 절반은 그래서 화면이 아니라, 실패와 대기를 다루는 태도에 있습니다.

혼자 쓰는 컴퓨터와 여럿이 쓰는 공간은 다릅니다

예전에는 자기 컴퓨터에 설치해서 혼자 쓰는 경우가 많았습니다. 그래픽카드가 받쳐주면 밤새 여러 장을 뽑아보면서 설정을 바꿔볼 수 있었죠. 그런데 다시 만든 화면을 Hugging Face Spaces 같은 공유 공간에 올리면 이야기가 달라집니다. 여러 사람이 같은 그래픽카드를 나눠 쓰기 때문에, 누가 먼저 왔는지와 얼마나 오래 붙잡고 있는지가 바로 문제가 됩니다. 그래서 gr Queue 같은 대기열과 동시 실행 수 조절이 함께 다뤄집니다.

문제는 그다음입니다. 대기열이 있다는 것은 기다림이 있다는 뜻이고, 기다림이 있다는 것은 사용자가 화면 앞에서 어떻게 기다리느냐까지 설계해야 한다는 뜻입니다. 진행 상황이 보이지 않으면 사람은 같은 요청을 다시 보내기 쉽고, 그러면 대기열은 더 길어집니다. 반대로 현재 순서와 남은 단계를 솔직하게 보여주면, 기다릴 사람은 기다리고 급한 사람은 나중에 오게 됩니다. 이 차이는 서버 비용의 문제가 아니라 예절의 문제에 가깝습니다. 함께 쓰는 주방이라면, 자기 요리만 생각해서는 안 되니까요.

저는 그래서 공유 공간에 올리는 일을 단순한 배포로 보지 않습니다. 혼자 쓰던 도구를 함께 쓰는 약속으로 바꾸는 일이라고 보는데요. 동시에 돌릴 개수를 몇으로 할지, 오래 걸리는 작업은 어떻게 나눌지, 실패한 작업이 자리를 차지하지 않게 할지를 정해야 합니다. 화면을 다시 짓는다는 말 속에는 이런 운영의 문장이 숨어 있습니다. 버튼을 예쁘게 만드는 일보다, 기다리는 사람을 덜 지치게 만드는 일이 더 어려울 때가 많습니다.

노드로 엮을까 순서대로 누를까

이쯤에서 ComfyUI 이야기를 빼놓을 수 없습니다. 노드를 선으로 이어서 흐름을 만드는 방식은, 정해진 순서를 따라가는 탭 방식과 정면으로 대비됩니다. 노드 방식은 중간 과정을 눈으로 보면서 조립할 수 있어서 실험하기 좋고, 복잡한 파이프라인을 저장하고 나누기에도 편합니다. 반면 탭 방식은 처음 보는 사람도 길을 잃지 않고 따라갈 수 있습니다. 무엇이 더 낫냐는 질문은 그래서 틀렸고, 누구에게 무엇을 맡기느냐가 더 맞는 질문입니다.

저는 두 방식을 사진 편집에 비유해서 봅니다. 탭 방식은 잘 정리된 자동 보정 코스에 가깝습니다. 순서대로 누르면 대부분의 경우 무난한 결과가 나오죠. 노드 방식은 레이어를 직접 쌓는 수동 편집에 가깝습니다. 손은 많이 가지만 원하는 지점을 정확히 찌를 수 있습니다. 그런데 막상 작업이 반복되면 수동 편집도 자주 쓰는 묶음은 저장해두고 재사용하게 됩니다. 그렇게 보면 두 방식은 멀리 있는 것이 아니라, 자주 쓰는 묶음을 어떻게 다루느냐에서 다시 만납니다.

그렇다면 Gradio로 탭 흐름을 다시 만드는 선택은 무엇을 뜻할까요. 저는 익숙함의 복원이라고 봅니다. 새로운 가능성을 여는 실험이라기보다는, 많은 사람이 이미 몸으로 익힌 순서를 지금 기술 위에서 다시 쓸 수 있게 만드는 일이죠. 여기서는 조금 조심해서 읽을 필요가 있습니다. 노드 방식이 유연하다고 해서 모든 사람에게 좋은 것은 아니고, 탭 방식이 쉽다고 해서 깊이 있는 작업이 불가능한 것도 아니기 때문입니다. 고르는 기준은 유행이 아니라, 누가 얼마나 자주 어떤 작업을 반복하느냐여야 합니다.

겉보기에 쉬워 보이는 곳에서 자주 놓치는 것들

다시 짓는 과정을 글로만 보면 모든 것이 매끈해 보입니다. 부품을 옮기고, 파이프라인을 붙이고, 이벤트를 이으면 끝나는 것처럼요. 하지만 실제로 해보면 매끈하지 않은 지점이 꽤 있습니다. 예전 확장 기능이 새 구조에서 어떻게 동작할지, 시드와 샘플러의 조합이 예전과 같은 느낌을 주는지, 화면 상태가 새로고침 뒤에도 유지되는지 같은 것들입니다. 이런 것은 큰 그림에서는 잘 안 보이지만, 매일 쓰는 사람에게는 바로 불편으로 느껴집니다.

그래서 저는 숫자로 된 자랑보다 이런 경계 조건의 설명을 더 눈여겨봅니다. 예를 들어 같은 프롬프트와 같은 시드를 넣었을 때 예전 화면과 새 화면의 결과가 같아야 할까요. 이론적으로는 엔진이 같으면 비슷해야 하지만, 전처리나 기본값이 조금만 달라도 체감이 달라집니다. 이때 같아야 한다는 기대 자체를 어디까지 둘지가 먼저 정해져야 합니다. 완전히 같게 만들겠다는 약속은 듣기 좋지만 지키기 어렵고, 자주 쓰는 범주에서 같게 하겠다는 약속은 지키기 쉬운데 설명이 필요합니다.

또 하나는 속도의 착각입니다. 화면이 가벼워졌다고 해서 그림이 빨리 나오는 것은 아닙니다. 그림을 만드는 시간은 대부분 뒤쪽 모델 계산에서 나가기 때문에, 화면을 바꾼다고 계산이 빨라지지는 않거든요. 다만 대기열을 잘 다루거나 중간 결과를 빨리 보여주면 체감은 좋아질 수 있습니다. 저는 이 구분이 중요하다고 봅니다. 벽시계로 잰 시간과 사람이 느낀 시간은 다르지만, 둘을 섞어서 말하면 오해가 생기기 때문입니다.

제가 다음에 보고 싶은 장면은 생각보다 구체적입니다

여기까지 오면 자연스럽게 다음 질문이 생깁니다. 다시 만든 화면이 오래가려면 무엇이 더 필요할까요. 저는 크게 세 가지를 보고 싶습니다. 첫째는 자주 쓰는 흐름을 묶음으로 저장하고 나누는 방법입니다. 탭 방식의 장점은 길을 잃지 않는 데 있는데, 매번 처음부터 누르게 하면 그 장점이 반감됩니다. 마음에 드는 설정 묶음을 이름 붙여 저장하고, 다음에 불러와서 바로 쓰는 흐름이 있으면 좋겠습니다.

둘째는 실패를 다루는 방식입니다. 생성은 됐는데 업스케일에서 막혔을 때, 중간 그림을 들고 다음 시도를 할 수 있을까요. 대기열에서 밀렸을 때, 요청이 사라지지 않고 차례를 기다릴 수 있을까요. 이런 장면은 데모에서는 잘 안 보이지만, 실제 운영에서는 매일 일어납니다. 밤사이 공유 그래픽카드가 바빠지거나 아침에 갑자기 사람이 몰려도 작업 흐름이 깨지지 않아야 하니까요. 운영의 아침을 지켜주는 장치가 결국 신뢰를 만듭니다.

셋째는 예전 자산을 어떻게 데려올지입니다. 많은 사람이 예전 화면에서 모아둔 프롬프트와 설정, 확장 조합을 갖고 있습니다. 그것을 새 화면에서 다시 쓸 수 있느냐는 단순한 호환성 문제가 아니라, 기억을 이어주는 문제입니다. 물론 모든 것을 그대로 옮길 수는 없습니다. 그래도 자주 쓰이던 조합 몇 가지를 손으로 옮겨보면, 어디가 막히고 어디가 쉬운지가 바로 드러날 겁니다. 제가 앞으로 보고 싶은 것은 거창한 기능보다 그런 옮겨 심기의 기록입니다.

다시 짓는다는 말의 온도를 오래 남기고 싶습니다

처음 AUTOMATIC1111을 켰을 때를 떠올려보면, 그 화면은 기술보다 태도에 가까웠습니다. 어려운 모델을 어려운 채로 두지 않고, 손이 닿는 곳까지 내려오게 만들겠다는 태도 말입니다. 이번에 Hugging Face 쪽에서 나온 다시 짓기 글도 저는 같은 온도에서 읽었습니다. 새로운 모델을 자랑하는 글이 아니라, 이미 많은 사람이 아는 사용감을 지금 도구로 다시 살리는 방법을 정리한 글이기 때문입니다.

그렇다면 사람의 역할은 무엇일까요. 화면을 다시 짓는 일이 끝난 뒤에도 남는 일은 결국 무엇을 만들고 싶은지를 정하는 일이라고 봅니다. 탭을 누르는 순서는 도구가 정해줄 수 있지만, 어떤 그림을 왜 만들고 싶은지는 도구가 대신해줄 수 없으니까요. 도구가 쉬워질수록 그 질문은 오히려 더 또렷해집니다. 저는 그래서 이 재건축을 효율의 이야기로만 보지 않습니다. 더 많은 사람이 그림을 다루는 언어를 갖게 되는 과정으로 봅니다.

다음에 이 화면을 다시 켜게 되면, 버튼 아래에 숨은 선택들을 한 번쯤 떠올려보셔도 좋겠습니다. 어떤 값은 슬라이더로, 어떤 흐름은 이어 붙이기로, 어떤 기다림은 대기열로 다뤄졌다는 것을요. 그렇게 보면 다시 짓는다는 말은 과거로 돌아가는 일이 아닙니다. 익숙했던 순서를 지금 손에 맞게 고쳐 쥐는 일입니다. 그리고 그 고쳐 쥠이 모이면, 다음 화면의 모양도 조금씩 달라질 겁니다.