AI 이미지 사이트에서는 LoRA를 흔히 ‘LoRA 모델’이라고 부른다. 그래서 처음 ComfyUI를 설치한 사용자는 checkpoint처럼 LoRA 파일 하나만 불러오면 이미지 생성이 가능한 독립 모델이라고 생각하기 쉽다.
실제 구조는 조금 다르다. LoRA는 독립적인 base model이라기보다 이미 학습된 모델에 추가해서 사용하는 adapter에 가깝다. 현재 Hugging Face의 PEFT 문서도 LoRA를 대표적인 parameter-efficient fine-tuning adapter 방식으로 다루고 있다.
lora ai에서 가장 먼저 볼 변화
LoRA AI는 독립 모델보다 adapter에 가깝다
LoRA는 pretrained model 전체를 새로 학습하지 않고 일부 추가 파라미터를 학습하는 방식이다. 학습 결과로 만들어지는 LoRA weight는 원래 모델의 모든 능력을 담고 있지 않다.
따라서 LoRA 파일만 가지고는 일반적인 이미지 생성 pipeline 전체가 완성되지 않는다. 먼저 해당 LoRA와 호환되는 base model이 필요하다.
‘LoRA 모델’이라는 표현이 틀린 것은 아니다
실제 서비스나 다운로드 사이트에서는 편의상 LoRA model이라는 표현을 널리 사용한다. ComfyUI 공식 문서에서도 사용자가 이해하기 쉽게 LoRA model이라는 이름을 사용한다.
다만 내부 구조를 이해할 때는 base model + LoRA adapter라고 생각하는 편이 정확하다. 이 구분을 알고 있으면 LoRA를 다운로드했는데 왜 checkpoint처럼 단독으로 실행되지 않는지도 바로 이해할 수 있다.
즉 LoRA가 하나의 파일로 배포된다는 사실과 완전한 생성 모델이라는 것은 같은 의미가 아니다.
ComfyUI Load LoRA에도 base model 입력이 필요하다
ComfyUI의 기본 Load LoRA 노드를 보면 이 구조가 그대로 드러난다. 노드는 LoRA 파일만 입력받는 것이 아니라 MODEL과 CLIP을 함께 입력받는다.
공식 문서에서도 MODEL 입력은 일반적으로 base model과 연결한다고 설명한다. LoRA를 적용한 뒤에는 조정된 MODEL과 CLIP이 다시 출력된다.
lora ai가 ComfyUI 워크플로우에 미치는 영향
checkpoint를 먼저 불러오는 이유
기존 방식과 비교해야 할 부분
기본적인 ComfyUI LoRA workflow는 다음 순서로 이해할 수 있다.
checkpoint 또는 diffusion model을 불러온다.
해당 model을 Load LoRA에 연결한다.
사용할 LoRA를 선택한다.
LoRA가 적용된 model을 sampler 쪽으로 넘긴다.
따라서 Load LoRA는 새로운 base model을 만드는 노드가 아니다. 이미 존재하는 model에 LoRA의 학습 결과를 추가하는 단계다.
ComfyUI 공식 예제에서도 checkpoint는 models/checkpoints에, LoRA는 별도의 models/loras 폴더에 저장한다. 폴더부터 역할이 분리돼 있는 셈이다.
LoRA를 바꾸면 같은 base model을 계속 사용할 수 있다
adapter 구조의 가장 실용적인 장점은 하나의 base model을 여러 방향으로 활용할 수 있다는 점이다.
성능과 결과 품질에서 확인할 차이
예를 들어 동일한 base model에 캐릭터 LoRA를 연결했다가 스타일 LoRA로 교체할 수 있다. 여러 LoRA를 연속으로 연결해 조합하는 workflow도 만들 수 있다.
워크플로우 구성에서 놓치기 쉬운 부분
Hugging Face PEFT에서도 하나의 pretrained model에 여러 adapter를 추가하고 필요한 adapter를 활성화하거나 전환하는 구조를 지원한다. 분야는 다르지만 LoRA가 어떤 방식으로 사용되는지를 이해하기에는 같은 개념이다.
ComfyUI 역시 여러 Load LoRA 노드를 직렬로 연결하는 공식 workflow 예제를 제공한다. base model 전체를 계속 새로 불러오는 것이 아니라 LoRA라는 추가 weight를 바꿔가며 사용하는 구조다.
base model이 맞지 않으면 LoRA도 제대로 작동하지 않는다
LoRA가 adapter라는 점을 이해하면 호환성 문제도 쉬워진다. LoRA는 학습 당시 기준이 된 모델 구조와 연결되어 있기 때문에 아무 checkpoint에나 붙인다고 같은 결과가 나오는 것이 아니다.
SDXL용 LoRA, FLUX용 LoRA처럼 이름이 나뉘는 이유가 바로 여기에 있다. 최근 ComfyUI 공식 workflow에서도 Qwen-Image용 control LoRA나 LTX-2.3용 distilled LoRA처럼 특정 모델과 함께 사용하는 LoRA가 별도로 제공된다.
LoRA를 받을 때 확인할 조건
따라서 LoRA를 받을 때는 먼저 다음을 확인하는 편이 좋다.
어떤 base model용인지
어떤 파일과 함께 사용해야 하는지
실제로 적용할 때 체크할 점
ComfyUI에서 어느 LoRA loader를 사용하는지
별도 trigger word나 권장 strength가 있는지
파일 확장자가.safetensors라는 이유만으로 서로 호환된다고 판단하면 안 된다.
AI에서 adapter라는 표현이 중요한 이유
LoRA를 단순히 ‘작은 모델’이라고 이해하면 checkpoint와의 차이가 모호해진다. 반대로 adapter라고 이해하면 학습과 inference 구조가 한 번에 정리된다.
base model에는 일반적인 생성 능력이 있고, LoRA에는 특정 작업이나 스타일을 위해 학습된 추가 변화량이 들어간다. 필요할 때 adapter를 붙이고, 필요하지 않으면 제거하거나 다른 LoRA로 교체하는 방식이다.
이 구조 덕분에 여러 목적마다 완전한 모델 전체를 별도로 관리하지 않아도 된다. LoRA가 AI 생태계에서 널리 사용되는 이유 중 하나도 이런 가벼운 저장·교체 구조에 있다.
마지막 확인
AI에서 LoRA를 ‘LoRA 모델’이라고 부르는 것은 흔한 표현이지만, 실제 사용 구조는 base model에 연결하는 adapter weight로 이해하는 편이 정확하다.
ComfyUI에서도 Load LoRA가 MODEL과 CLIP을 입력받는 이유가 여기에 있다. LoRA를 다운로드할 때는 파일 자체보다 먼저 어떤 base model용인지 확인하고, 그 모델 위에 adapter를 적용한다는 순서로 접근하면 된다.