직장인을 위한 AI 봇·자동화 기록

[GitHub AI 스킬 #0167] ludwig: YAML 파일 하나로 LLM을 미세조정하는 로우코드 프레임워크

aibot-work — Fri, 17 Jul 2026 09:11:00 +0900

GitHub ludwig-ai/ludwig ★ 11,733
Low-code framework for building custom LLMs, neural networks, and other AI models https://github.com/ludwig-ai/ludwig

회사에서 "우리 고객 문의 데이터로 챗봇 하나 학습시켜볼 수 있냐"는 말을 들었다고 칩시다. 저는 개발자가 아니거든요. 파이썬 코드로 PyTorch 모델 짜고, 데이터로더 만들고, 학습 루프 돌리라고 하면 그 자리에서 멈춥니다.

그런데 정작 하고 싶은 건 단순하죠. "이 CSV 파일 던져주면 알아서 학습해줘." 딱 그거.

ludwig는 바로 그 지점을 노립니다.

코드 대신 설정 파일로 모델을 만든다는 것

ludwig의 핵심 단어는 "declarative(선언형)"입니다. 무슨 뜻이냐면, 어떻게 학습할지를 코드로 일일이 적지 않고, 무엇을 원하는지만 YAML 파일에 적는다는 거예요.

README 첫 화면에 나오는 예시가 이겁니다.

# Llama-3.1을 LoRA로 미세조정하는 설정 파일 전체
model_type: llm
base_model: meta-llama/Llama-3.1-8B
adapter:
  type: lora
trainer:
  type: finetune
  epochs: 3
input_features:
  - name: instruction
    type: text
output_features:
  - name: response
    type: text

이게 전부입니다. 입력은 instruction이라는 텍스트, 출력은 response라는 텍스트, 3번 반복 학습, LoRA 방식으로. 사람이 읽어도 무슨 소린지 대충 이해가 되죠.

그리고 실행은 터미널 한 줄.

ludwig train --config model.yaml --dataset my_data.csv

파이썬 파일을 열어서 클래스를 상속받고 어쩌고 하는 과정이 없어요. 설정 파일이랑 데이터만 있으면 되거든요.

LLM 미세조정만 하는 게 아니었다

솔직히 처음엔 "요즘 LLM 붙은 도구 다 그렇지 뭐" 싶었습니다. 근데 README를 뜯어보다가 생각이 좀 바뀌었어요.

이름을 보면 LLM 도구로 분류돼 있지만, 실제로는 세 종류를 다 다룹니다.

LLM 미세조정 (위의 Llama 예시)
이미지, 텍스트, 오디오를 섞은 멀티모달 모델
엑셀 표 같은 tabular 데이터 분류/예측

세 번째가 저한테는 오히려 반가웠어요. 회사 실무에서 진짜 자주 나오는 게 "이 고객이 이탈할까 안 할까" 같은 표 데이터 예측이거든요. 그런 걸 LLM 없이도 같은 방식으로 돌릴 수 있다는 게 이 도구의 진짜 무기입니다.

기술 스택도 최신입니다. PyTorch 2.7, Transformers 5, Ray 2.54를 쓴다고 적혀 있어요. Ray가 들어있다는 건 여러 대의 컴퓨터에 나눠서 학습을 돌릴 수 있다는 뜻이죠. 개인이 노트북에서 굴리는 것부터, 회사 서버 여러 대에 뿌리는 것까지 같은 설정 파일로 커버한다는 얘기.

별이 11,733개인데 왜 이제야 봤나 싶었는데, 이 프로젝트가 Linux Foundation AI & Data 재단에 소속돼 있더군요. 한 회사의 오픈소스가 아니라 재단이 관리하는 프로젝트라는 점이 좀 안심됐습니다.

일단 깔아보기

파이썬 3.12 환경이 있다는 전제로, 설치는 pip 한 줄입니다.

pip install ludwig

# LLM 관련 기능까지 다 쓰려면
pip install 'ludwig[llm]'

여기서 초보자가 걸리는 지점을 하나 짚고 갑니다. Llama-3.1 같은 모델은 HuggingFace에서 사용 승인을 받아야 다운로드가 됩니다. 설정 파일에 base_model 이름만 적는다고 알아서 받아지는 게 아니에요. HuggingFace 계정 만들고, 해당 모델 페이지에서 라이선스 동의하고, 토큰을 발급받아야 하죠.

이 부분이 README에는 짧게만 나와 있어서, 처음 하는 사람은 여기서 30분쯤 헤맬 겁니다. (저도 예전에 다른 도구에서 같은 걸로 막혔거든요.)

GPU 문제는 피할 수 없다

LLM 미세조정은 무조건 GPU가 필요합니다. 8B(80억 파라미터) 모델을 노트북 CPU로 학습시키겠다는 건 현실적으로 불가능해요. LoRA 같은 경량화 방식을 써도 최소한 괜찮은 그래픽카드가 있는 환경이거나, Google Colab 같은 클라우드 GPU를 빌려야 합니다.

반대로 표 데이터 분류 같은 가벼운 작업은 CPU로도 돌아가니까, 처음 감을 잡을 땐 그쪽부터 해보는 걸 추천합니다.

이 도구가 약한 부분

솔직하게 말하면, ludwig는 세밀한 커스터마이징에는 약합니다.

정확히는 약한 게 아니라, 애초에 그걸 목표로 만든 도구가 아니에요. YAML로 다 해결한다는 건 편하지만, 반대로 말하면 YAML이 지원하지 않는 특이한 구조를 만들고 싶을 때 벽에 부딪힌다는 뜻이거든요. 논문에 나온 최신 아키텍처를 처음부터 실험하는 연구자라면, 결국 순수 PyTorch나 HuggingFace Transformers를 직접 만지는 게 낫습니다.

또 하나. YAML 설정 항목이 생각보다 방대합니다. "로우코드"라는 말만 믿고 들어가면, 옵션이 수십 개 나오는 공식 문서 앞에서 잠깐 멍해질 수 있어요. 코드를 안 쓰는 대신, 설정 문법을 새로 배워야 하는 거죠. 공짜 점심은 없더라고요.

비슷한 도구랑 비교하면

저는 아직 아주 단순한 LLM 미세조정만 할 거라면 HuggingFace의 AutoTrain이나 Unsloth 쪽이 더 직관적이라고 느낍니다. 이유는 오로지 LLM 하나에만 집중해서 설정할 게 적거든요.

반대로 "표 데이터, 텍스트, 이미지를 한 프레임워크로 통일해서 다루고 싶다"면 ludwig가 강합니다. 여러 종류의 AI 모델을 같은 문법으로 관리한다는 게 이 도구의 존재 이유니까요.

결국 "하나만 잘하는 도구"와 "여러 개를 한 방식으로 하는 도구"의 차이입니다. 여러분은 어느 쪽 상황인가요? 만약 회사에서 이미 표 데이터 예측이랑 텍스트 분류를 둘 다 하고 있다면, 댓글로 그 케이스를 남겨주면 좋겠어요. 그런 환경일수록 ludwig의 이득이 커지거든요.

정리

ludwig는 "코드 없이 설정 파일로 AI 모델을 학습한다"는 약속을 꽤 성실하게 지키는 프레임워크입니다. LLM 미세조정부터 표 데이터 예측까지 하나의 문법으로 묶었다는 점이 개발자 아닌 사람에게 특히 반갑고요.

다만 GPU 환경 준비와 HuggingFace 모델 승인 같은 진입 장벽은 여전히 남아 있습니다. 그리고 YAML 옵션의 바다에서 헤엄칠 각오는 해야 하죠.

만약 당신이 오직 LLM 하나만, 그것도 최대한 빠르게 미세조정해보고 싶은 완전 초보라면, ludwig보다 Unsloth 노트북 예제를 먼저 열어보길 권합니다. 클릭 몇 번으로 무료 GPU에서 바로 돌려볼 수 있어서, 감을 잡는 데는 그쪽이 덜 아픕니다.

[GitHub AI 스킬 #0166] opik: LLM 앱이 왜 이상하게 답하는지 눈으로 확인하는 도구

aibot-work — Thu, 16 Jul 2026 22:13:00 +0900

GitHub comet-ml/opik ★ 20,528
Debug, evaluate, and monitor your LLM applications, RAG systems, and agentic workflows with comprehensive tracing, automated evaluations, and production-ready dashboards. https://github.com/comet-ml/opik

챗봇을 만들어서 사내에 배포했다고 칩시다. 어제까지 멀쩡하던 답변이 오늘 갑자기 엉뚱한 소리를 하기 시작합니다. 프롬프트를 바꾼 적도 없는데 말이죠.

이때 개발자가 아닌 우리가 할 수 있는 건 뭘까요. "음... 뭔가 이상하네요"라고 슬랙에 적는 것 정도.

문제는 LLM이 답을 만드는 과정이 완전히 블랙박스라는 겁니다. 어떤 문서를 참고했는지, 몇 번 재시도했는지, 토큰을 얼마나 썼는지 아무것도 안 보이거든요. 그래서 뭐가 잘못됐는지 짐작만 하다 하루가 갑니다.

오늘 GitHub를 뒤지다 만난 opik은 바로 그 블랙박스를 열어보는 도구입니다.

opik이 실제로 하는 일

Comet ML이라는 회사가 만든 오픈소스입니다. 별이 20,528개. 카테고리는 프롬프트 엔지니어링으로 묶여 있지만, 실제로는 "관찰(observability)" 쪽에 훨씬 무게가 쏠려 있어요.

핵심 기능을 정리하면 이렇습니다.

트레이싱(추적): LLM 앱이 답을 만드는 전 과정을 단계별로 기록. RAG면 어떤 문서를 검색했는지까지 보입니다.
평가(evaluation): "이 답변이 헛소리인지" 자동으로 채점. 사람이 일일이 안 봐도 됩니다.
대시보드: 운영 중인 앱의 비용, 지연시간, 에러를 한 화면에서 봅니다.
프롬프트 최적화: 프롬프트를 자동으로 이리저리 바꿔가며 더 나은 버전을 찾아줍니다.

말이 어려운데, 쉽게 말하면 CCTV + 성적표예요. 내 챗봇이 뭘 하고 있는지 녹화하고(트레이싱), 잘하고 있는지 점수 매기는(평가) 거죠.

코드 세 줄이면 녹화 시작

솔직히 이런 도구는 "설치가 지옥"인 경우가 많거든요. 근데 opik은 진입이 생각보다 쉬웠습니다.

파이썬 라이브러리 설치부터.

pip install opik
opik configure

opik configure를 치면 클라우드에 연결할지, 내 컴퓨터에 직접 띄울지 물어봅니다. 계정 만들기 싫으면 Docker로 로컬에 통째로 올릴 수도 있어요.

그다음, 기존 코드에 데코레이터 한 줄만 붙이면 녹화가 시작됩니다.

from opik import track

@track
def my_llm_function(question: str):
    # 여기가 원래 내 챗봇 로직
    return answer

my_llm_function("환불 규정이 어떻게 되나요?")

이렇게만 해도 이 함수가 언제 호출됐고, 입력이 뭐였고, 뭘 뱉었는지 대시보드에 쌓입니다. OpenAI나 LangChain을 쓴다면 통합(integration)이 이미 준비돼 있어서 데코레이터도 필요 없는 경우가 있고요.

README를 뜯어보다가 눈에 띈 건 지원하는 프레임워크 목록이었습니다. LangChain, LlamaIndex, Haystack에 심지어 DeepSeek, Gemini까지. "일단 다 붙여놓고 보자"는 회사의 야심이 보이더군요. (좋은 뜻으로요.)

평가 기능이 진짜 물건

트레이싱은 요즘 비슷한 도구가 많아요. LangSmith도 하고, Langfuse도 하죠. 근데 opik에서 제일 손이 갔던 건 평가 쪽입니다.

예를 들어 RAG 챗봇을 만들면 항상 걱정되는 게 "환각(hallucination)"이잖아요. 문서에 없는 내용을 지어내는 거요. opik은 이걸 자동으로 잡아주는 채점기를 기본으로 줍니다.

from opik.evaluation.metrics import Hallucination

metric = Hallucination()
score = metric.score(
    input="한국의 수도는?",
    output="한국의 수도는 부산입니다.",
    context=["한국의 수도는 서울이다."]
)
print(score)

context에 있는 정보랑 output이 어긋나면 점수가 떨어집니다. 이걸 수백 개 질문에 한꺼번에 돌려서 "우리 챗봇 헛소리 비율이 12%네" 같은 숫자를 뽑을 수 있는 거죠.

이게 왜 중요하냐면, 개발자가 아닌 저 같은 사람도 "느낌"이 아니라 "숫자"로 말할 수 있게 되거든요. 팀에 보고할 때 "좀 나아진 것 같아요"보다 "환각률 12%에서 5%로 내렸습니다"가 훨씬 먹히잖아요.

그래서 안 맞는 사람은

여기서 솔직해질게요.

opik은 코드를 아예 안 만지는 사람에겐 약합니다. "노코드"라고 광고하지 않아요. 데코레이터 한 줄, 라이브러리 임포트, 이 정도는 결국 파이썬을 열어야 한다는 뜻이거든요. ChatGPT 화면에서 프롬프트만 다듬는 게 목표라면 이 도구는 과합니다.

또 하나. 대시보드나 평가 지표를 보려면 결국 "내 LLM 앱"이 코드로 존재해야 합니다. 아직 앱을 안 만들었고 아이디어만 있는 단계라면, 옵틱을 먼저 깔 이유가 없어요. 관찰할 대상 자체가 없으니까.

개인적인 비교를 하자면, 저는 처음 트레이싱을 접할 때 Langfuse의 UI가 조금 더 직관적으로 느껴졌습니다. opik은 기능이 많은 대신 처음 대시보드를 열면 "이게 다 뭐지" 싶은 순간이 있었거든요. 대신 평가와 프롬프트 최적화까지 한 우산 아래 넣은 건 opik이 더 야무집니다.

여러분은 챗봇 만들면서 "왜 이렇게 답했지"를 어떻게 디버깅하고 있나요? 저는 지금까지 프린트 찍어가며 봤는데(부끄럽지만 사실), 이런 걸 쓰는 게 정석이었나 봅니다.

짧은 결론

opik은 "만든 다음"을 위한 도구입니다. LLM 앱을 이미 굴리고 있는데 왜 이상한지 답답한 사람에게 딱 맞아요. 트레이싱, 평가, 대시보드가 하나로 묶여 있고, 오픈소스라 로컬에 통째로 올려 쓸 수 있다는 것도 마음에 듭니다.

반대로 아직 코드 한 줄 안 짠 단계거나, 파이썬 자체가 부담스럽다면 이건 아직 여러분 도구가 아닙니다. 그럴 땐 프롬프트만 정리하고 버전 관리하는 가벼운 도구, 예를 들어 노션에 프롬프트 템플릿을 표로 쌓는 것부터 시작하는 게 낫습니다. 관찰은 관찰할 게 생긴 다음 얘기니까요.

[GitHub AI 스킬 #0165] sentence-transformers: 문장을 숫자로 바꿔 검색과 유사도 계산을 돕는 도구

aibot-work — Thu, 16 Jul 2026 08:47:00 +0900

GitHub UKPLab/sentence-transformers ★ 18,898
State-of-the-Art Embeddings, Retrieval, and Reranking https://github.com/huggingface/sentence-transformers

오늘 GitHub 트렌딩을 뒤지다가 별 18,898개짜리 레포를 하나 열어봤습니다. 이름은 sentence-transformers. HuggingFace가 관리하고 있고, 설명에는 "State-of-the-Art Embeddings, Retrieval, and Reranking"이라고만 딱 적혀 있더군요.

솔직히 첫 문장부터 막혔습니다. "임베딩"이 뭔데?

그래서 README를 붙잡고 한참 뜯어본 결과를 초보자 눈높이로 풀어봤습니다.

이게 도대체 뭐 하는 물건이에요?

한 줄로 말하면, 문장을 숫자 덩어리로 바꿔주는 도구입니다. 이 숫자 덩어리를 임베딩(embedding)이라고 불러요.

예를 들어볼게요. "강아지가 뛴다"와 "개가 달린다"는 글자는 다르지만 뜻은 거의 같죠. 사람은 바로 알아채지만 컴퓨터는 못 합니다. 그래서 두 문장을 각각 숫자 배열(예: [0.12, -0.5, 0.8 ...])로 바꾼 다음, 그 숫자들이 얼마나 가까운지를 재는 거예요.

숫자가 가까우면 뜻도 비슷하다. 이게 핵심 아이디어.

이걸로 뭘 할 수 있냐면요.

의미로 검색하기 (키워드가 안 맞아도 뜻이 통하면 찾아줌)
두 문장이 얼마나 비슷한지 점수 매기기
비슷한 문장 무더기에서 짝 찾아내기 (paraphrase mining)
챗봇이 참고할 문서를 골라주는 RAG의 검색 부분

무료인가요? 회원가입 같은 거 해야 해요?

네, 무료입니다. Apache 라이선스 오픈소스라 그냥 설치해서 쓰면 돼요.

README에 따르면 15,000개가 넘는 사전 학습된 모델이 HuggingFace에 올라와 있고, 이걸 이름만 적어서 불러오면 됩니다. 모델을 직접 훈련시킬 필요가 없다는 거죠. 남이 만들어둔 걸 다운받아 쓰는 구조.

다만 모델 파일 자체를 인터넷에서 받아오기 때문에, 처음 실행할 때 몇백 MB짜리 다운로드가 돌아갑니다. 회사 방화벽이나 느린 와이파이면 여기서 좀 답답할 수 있어요. (저는 카페에서 돌리다가 한 번 멈춰서 당황했습니다.)

코딩 몰라도 쓸 수 있나요?

솔직히 말하면, 파이썬을 아예 안 만져봤다면 조금 어렵습니다.

근데 놀란 건 코드가 생각보다 짧다는 점이에요. README에 있는 기본 예제를 보면 이 정도거든요.

from sentence_transformers import SentenceTransformer

# 모델 불러오기
model = SentenceTransformer("all-MiniLM-L6-v2")

# 바꿀 문장들
sentences = [
    "고양이가 소파에서 잔다",
    "강아지가 마당에서 뛴다",
    "냥이가 쿠션 위에서 낮잠 중",
]

# 문장을 숫자로 변환
embeddings = model.encode(sentences)
print(embeddings.shape)   # (3, 384) 같은 형태로 나옴

# 문장끼리 유사도 계산
similarities = model.similarity(embeddings, embeddings)
print(similarities)

줄 수만 보면 열 몇 줄. 첫 번째 문장이랑 세 번째 문장(둘 다 고양이 낮잠 얘기)의 점수가 높게 나올 거예요.

정리하면 이렇습니다.

파이썬 설치 + pip install sentence-transformers 한 줄 → 이건 넘을 수 있는 산
모델 이름을 바꿔가며 실험 → 복붙으로 가능
이 숫자를 실제 서비스에 연결 → 여기부터는 개발 영역

그러니까 "결과를 눈으로 확인하는 것"까지는 비개발자도 됩니다. 그걸 어디에 써먹느냐가 진짜 벽이에요.

비슷한 거 많던데 뭐가 다른가요?

임베딩만 놓고 보면 OpenAI의 text-embedding-3 API도 있고, Cohere도 있죠. 저는 예전에 OpenAI 임베딩을 몇 번 써봤는데, 그건 API 키를 발급받고 호출할 때마다 돈이 나갑니다. 문장 백만 개 돌리면 요금 걱정을 해야 하죠.

sentence-transformers의 매력은 내 컴퓨터에서 공짜로, 인터넷 없이도 돌릴 수 있다는 점입니다. 데이터를 외부로 안 보내니까 회사 내부 문서 다룰 때 마음이 편하고요.

대신 트레이드오프가 있습니다.

OpenAI API는 클릭 몇 번이면 최상급 성능이 나오지만 계속 돈이 든다. sentence-transformers는 공짜지만 좋은 모델일수록 무겁고, 내 노트북 사양이 발목을 잡는다. 어느 쪽이 낫냐는 상황 나름.

그리고 README를 읽다가 발견한 디테일 하나. 이 도구는 단순 임베딩뿐 아니라 Cross-Encoder(리랭커)랑 Sparse Encoder까지 세 종류를 다 다룹니다. 리랭커는 검색 결과를 다시 한 번 정밀하게 순서 매기는 역할인데, 이걸 한 라이브러리에서 같이 쓸 수 있게 묶어둔 게 실무자 입장에선 편하겠더라고요.

그래서 뭐부터 하면 되나요?

완전 초보라면 이 순서를 권합니다.

파이썬 3.9 이상 설치 (이미 있으면 통과)
터미널에서 pip install -U sentence-transformers
위에 붙여둔 예제 코드를 그대로 실행
all-MiniLM-L6-v2 대신 paraphrase-multilingual-MiniLM-L12-v2로 바꿔서 한국어 문장 테스트

4번이 중요합니다. 기본 예제 모델은 영어 위주라 한국어 문장을 넣으면 결과가 어정쩡해요. multilingual이 붙은 모델을 써야 한국어 유사도가 그나마 제대로 나옵니다. (이거 모르고 한글 넣었다가 "왜 다 비슷하다고 나오지?" 하고 헤맸습니다.)

단점이나 조심할 점은 없어요?

있습니다. 몇 개 짚을게요.

한국어 특화 성능은 약합니다. multilingual 모델이 여러 언어를 두루 담다 보니 한국어만 파고든 전용 모델보다 정밀도가 떨어질 때가 있어요. 결이 미묘한 한국어 문장은 헷갈려 합니다.
GPU가 없으면 대량 처리가 느립니다. 문장 몇 개는 노트북으로 순식간이지만, 수십만 개를 돌리면 CPU로는 하염없이 기다려야 해요.
임베딩을 만든 다음 그걸 어디에 저장하고 어떻게 빨리 검색하냐(벡터 DB 얘기)는 이 라이브러리가 안 해줍니다. 그 부분은 따로 공부해야 해요.

문제는 세 번째입니다. 임베딩 만드는 것까지는 쉬운데, 그걸 실제 검색 서비스로 만들려면 FAISS나 Chroma 같은 별도 도구를 붙여야 하거든요. "숫자로 바꿨다"와 "검색이 작동한다" 사이엔 생각보다 큰 강이 있습니다.

그래서, 블로거님은 이거 추천해요?

조건부로 추천합니다.

"AI가 어떻게 문장의 의미를 이해하는 척하는가"를 직접 손으로 확인해보고 싶다면, 이보다 진입 장벽 낮은 도구를 저는 아직 못 봤습니다. 무료고, 코드 짧고, 결과가 숫자로 딱 나오니까 원리가 손에 잡히거든요.

반대로 "당장 우리 회사 문서 검색 서비스를 만들겠다"는 목표라면, 이건 재료 중 하나일 뿐이라는 걸 알아두셔야 해요. 벡터 DB, 리랭커, API 서버까지 조립해야 완성이라서요.

저는 오늘 예제 돌려보면서 "고양이 낮잠" 문장 두 개의 유사도가 0.7 넘게 나오는 걸 보고 좀 신기했습니다. 컴퓨터가 글자가 아니라 뜻을 보고 있다는 게 눈에 보였거든요.

혹시 이거 말고 한국어 임베딩에 더 잘 맞는 모델 써보신 분 있나요? 댓글로 모델 이름 좀 알려주시면 제가 다음에 직접 돌려보고 비교해보겠습니다. 특히 KoSimCSE 같은 한국어 전용 모델 경험담이 궁금하네요.

[GitHub AI 스킬 #0164] unsloth: 로컬에서 오픈모델을 돌리고 학습시키는 웹 UI

aibot-work — Wed, 15 Jul 2026 19:10:00 +0900

GitHub unslothai/unsloth ★ 67,970
Unsloth Studio is a web UI for training and running open models like Gemma 4, Qwen3.6, DeepSeek, gpt-oss locally. https://github.com/unslothai/unsloth

매일 GitHub 트렌딩을 훑다 보면 "로컬에서 AI 돌린다"는 도구가 하루에 세 개씩 나옵니다. 대부분은 설치하다 포기하죠. 근데 unsloth는 별이 67,970개나 붙어 있어서 그냥 넘기기가 좀 그랬습니다.

결론부터 말하면, 개발자가 아닌 저 같은 사람한테도 문턱이 생각보다 낮았습니다. 명령어 한 줄 붙여넣으면 설치가 끝나거든요.

unsloth가 정확히 뭘 하는 물건인가

이름은 unsloth인데 실제로 설명에 나오는 건 "Unsloth Studio"입니다. 웹 UI로 Gemma, Qwen, DeepSeek, gpt-oss 같은 오픈모델을 내 컴퓨터에서 돌리거나(inference) 학습(fine-tuning)시키는 프로그램이에요.

여기서 두 단어만 알면 됩니다.

추론(Inference): 이미 만들어진 모델한테 질문하고 답 받는 것. ChatGPT 쓰듯이요.
파인튜닝(Fine-tuning): 기존 모델에 내 데이터를 추가로 먹여서 내 입맛대로 바꾸는 것.

보통 이 파인튜닝이라는 게 GPU 메모리를 엄청 잡아먹거든요. unsloth의 원래 이름값은 여기서 나옵니다. 같은 학습을 훨씬 적은 메모리로, 더 빠르게 돌리는 최적화가 핵심이었어요. Studio는 그걸 클릭으로 할 수 있게 껍데기를 씌운 버전이고요.

README를 뜯어보다가 눈에 띈 건, 텍스트뿐 아니라 오디오, 임베딩, 비전(이미지) 모델까지 다 지원한다고 적어둔 부분이었습니다. 보통 이런 도구는 텍스트 하나만 되는 경우가 많은데 범위를 넓게 잡았네요.

설치부터 첫 화면까지

설치는 운영체제별로 명령어 한 줄입니다. 진짜 한 줄.

macOS, Linux, WSL 사용자

curl -fsSL https://unsloth.ai/install.sh | sh

Windows 사용자

irm https://unsloth.ai/install.ps1 | iex

여기서 한 가지 짚고 갑니다. 저 명령어는 "인터넷에서 스크립트를 받아서 바로 실행"하는 방식이거든요. 편하긴 한데, 남이 만든 코드를 검증 없이 통째로 돌리는 거라 찜찜하면 install.sh 링크를 브라우저로 먼저 열어서 내용을 눈으로 훑고 실행하는 걸 권합니다. (저는 습관적으로 그렇게 해요.)

설치가 끝나면 웹 UI가 뜹니다. 터미널에 뜨는 로컬 주소(보통 localhost)를 브라우저에 붙여넣으면 위 이미지 같은 홈 화면이 나옵니다.

실전: 모델 하나 받아서 내 노트북에서 대화하기

파인튜닝은 나중 얘기고, 처음엔 모델을 그냥 돌려보는 게 맞습니다. unsloth Studio가 내세우는 기능 중 제일 실용적인 게 이거였어요.

"Search + download + run models" . 검색하고, 다운로드하고, 실행하는 걸 한 화면에서 끝낸다.

이게 왜 반가운지 설명하자면. 기존에 로컬 모델 돌리려면 Hugging Face에서 모델을 찾고, GGUF 파일이 뭔지 공부하고, 명령어로 변환하고... 이 과정이 초보자를 다 걸러냈거든요.

Studio에서의 흐름은 이렇습니다.

검색창에 모델 이름 입력. 예를 들어 "Qwen3" 또는 "gemma".
목록에서 용량 감당 가능한 버전 선택. 여기서 양자화(quantization) 표기를 봐야 해요. Q4니 Q8이니 하는 숫자가 작을수록 파일이 가볍고 메모리를 덜 씁니다. 대신 답변 품질이 약간 떨어지고요.
다운로드 버튼. 모델 크기가 몇 GB라 시간이 좀 걸립니다.
Run 눌러서 채팅.

제 기준 처음엔 무조건 Q4 정도의 작은 모델부터 받으라고 하고 싶네요. 7B 모델의 Q4면 대략 4~5GB 선이라 웬만한 노트북에서도 돌아가거든요. 32B짜리 큰 모델을 덜컥 받으면 다운로드만 하다 하루가 갑니다.

돌려보고 마음에 들면 Export 기능으로 GGUF나 16비트 safetensors로 저장할 수 있어요. 나중에 다른 도구에서 재활용할 때 유용합니다.

비슷한 도구랑 비교하면

솔직히 "로컬에서 모델 돌리기"만 놓고 보면 저는 아직 Ollama가 더 편합니다. 이유는 명령어 하나(ollama run llama3)로 끝나고, 커뮤니티 자료가 넘쳐서 막혔을 때 검색이 잘 되거든요.

근데 unsloth Studio의 진짜 무기는 파인튜닝을 GUI로 한다는 점입니다. Ollama는 학습 기능이 없죠. "내 데이터로 모델을 조금 손보고 싶다"는 순간, unsloth 쪽으로 넘어올 이유가 생깁니다.

막히기 쉬운 지점

제가 README를 읽으며 미리 예상한, 그리고 실제로 초보자가 걸릴 만한 구간을 정리했습니다.

GPU 없으면 파인튜닝은 사실상 그림의 떡. 추론은 CPU로도 느리게나마 되지만, 학습은 NVIDIA GPU가 거의 필수입니다. 맥북(애플 실리콘)은 추론은 되는데 학습 쪽은 제약이 있어요.
"Beta"라는 단어. README에 대놓고 Studio (Beta)라고 적혀 있습니다. 갑자기 안 되거나 UI가 바뀔 수 있다는 뜻이죠. 회사 업무에 바로 쓸 물건은 아닙니다.
모델 이름의 함정. 설명에 "Gemma 4, Qwen3.6"처럼 아직 나오지도 않은 듯한 버전 번호가 적혀 있어서 혼란스러웠어요. 실제 검색창에서는 배포된 버전(Qwen3, Gemma 3 등)으로 찾는 게 안전합니다.

한계도 하나 솔직하게. 이 도구는 여러 모델을 서로 연결해 자동으로 일을 시키는 복잡한 에이전트 워크플로우에는 약합니다. 툴 콜링(tool calling)은 지원한다고 적혀 있지만, LangChain이나 별도 에이전트 프레임워크가 하는 정교한 오케스트레이션을 대체하는 물건은 아니에요. Studio는 어디까지나 "모델 하나를 돌리고 다듬는" 작업대에 가깝습니다.

그래서 누구한테 추천하나

정리하면 이렇습니다. 로컬에서 그냥 대화만 하고 싶다면 Ollama가 더 쉬워요. 하지만 "내가 가진 데이터로 모델을 조금 커스텀하고 싶은데 코드는 무섭다"는 사람에게는 unsloth Studio가 지금 나온 것 중 문턱이 낮은 편입니다.

별 6만 개는 원래 라이브러리(파인튜닝 최적화) 시절부터 쌓인 신뢰가 크다고 봅니다. 그 기술력에 GUI를 얹었으니 방향은 좋죠.

저는 우선 Qwen3의 작은 모델로 추론만 며칠 써보고, GPU가 있는 데스크톱에서 파인튜닝을 시험해볼 생각입니다.

여러분은 로컬 AI를 돌릴 때 Ollama, LM Studio, unsloth 중 뭘 쓰고 계신가요? 그리고 그걸 고른 결정적인 이유 하나만 댓글로 알려주세요. 다음에 도구 비교할 때 참고하고 싶습니다.

[GitHub AI 스킬 #0163] DemoGPT: 프롬프트만 던지면 LLM 에이전트를 조립해주는 도구

aibot-work — Wed, 15 Jul 2026 08:54:00 +0900

GitHub melih-unsal/DemoGPT ★ 1,900
Create LLM agents in a second with your prompts. Everything you need to create an LLM Agent - tools, prompts, frameworks, and models - all in one place. https://github.com/melih-unsal/DemoGPT

오늘 아침에도 GitHub 트렌딩을 훑다가 이 레포에서 멈췄습니다. "Create LLM agents in a second"라는 문구. 1초 만에 에이전트를 만들어준다니, 그 "1초"가 진짜인지 확인해보고 싶었거든요. 개발자가 아닌 저 같은 사람 입장에서는 에이전트라는 단어부터 벽이 좀 있습니다.

별 1,900개. 애매하게 유명한 정도.

그래서 DemoGPT가 대체 뭘 하는 도구냐면

ChatGPT한테 "여행 일정 짜주는 봇 만들어줘"라고 말로 부탁하면, 그걸 실제로 돌아가는 파이썬 앱으로 뽑아주는 도구입니다. 정확히는 LangChain이라는 프레임워크 기반의 코드를 자동으로 생성해주죠.

여기서 에이전트라는 말이 핵심인데, 단순히 질문에 답만 하는 챗봇이 아니라 도구(tool)를 쓰고, 검색하고, 여러 단계를 알아서 처리하는 프로그램을 뜻합니다. 예를 들어 "날씨 물어보면 API 찾아서 답하고, 우산 챙기라고 알려주는 봇" 같은 거요.

README를 뜯어보니 RAG, Knowledge Graph, Vector Database 같은 단어가 배너부터 잔뜩 박혀 있더군요. (솔직히 이 단어들 다 아는 초보자는 드물 겁니다.) 쉽게 말하면 "봇이 내 문서를 읽고 그걸 근거로 답하게 만드는 기술"들입니다.

설치하고 처음 켜기까지

파이썬이 깔려 있다는 전제 하에, 설치 자체는 한 줄입니다.

pip install demogpt

그다음 OpenAI API 키가 필요합니다. 이게 첫 번째 관문. DemoGPT는 GPT 모델을 빌려 쓰기 때문에, OpenAI 계정에서 발급받은 키를 환경변수로 넣어줘야 합니다.

# 맥/리눅스
export OPENAI_API_KEY=sk-여기에_본인_키

# 윈도우 (파워셸)
$env:OPENAI_API_KEY="sk-여기에_본인_키"

키를 넣었으면 실행. 명령어 하나면 웹 화면이 뜹니다.

demogpt

브라우저에 Streamlit 기반 화면이 열리고, 여기에 "무슨 앱을 만들고 싶은지" 프롬프트를 적는 칸이 나옵니다. 이 방식은 처음 보면 좀 신기해요. 코드를 짜는 게 아니라 요청서를 쓰는 느낌.

실제로 봇 하나 만들어본 과정

저는 블로그 운영자니까, "긴 글을 넣으면 SNS 홍보 문구 3개로 요약해주는 봇"을 만들어보기로 했습니다.

입력창에 이렇게 적었어요.

"사용자가 블로그 글을 붙여넣으면, 트위터용 짧은 홍보 문구 3개를 이모지 포함해서 생성해주는 앱을 만들어줘."

그러자 DemoGPT가 뒤에서 이런 순서로 움직이더군요.

내 요청을 여러 단계(step)로 쪼갬. "입력 받기 → 요약 → 문구 생성 → 화면 출력"
각 단계에 맞는 LangChain 코드 조각을 생성
그걸 하나의 Streamlit 앱으로 합침
완성된 코드를 화면에 보여주고, 바로 실행 버튼 제공

여기서 눈에 띈 디테일 하나. DemoGPT는 코드를 통째로 뱉는 게 아니라 "계획 → 단계별 코드 → 최종 조립" 순으로 나눠서 처리합니다. 레포의 로직을 보면 이 방식을 "plan → task → code" 파이프라인이라고 부르더군요. 한 번에 큰 코드를 생성하면 오류가 나기 쉬우니, 잘게 쪼개서 실패 확률을 줄이려는 설계로 읽혔습니다.

결과물은 그럭저럭 돌아갔습니다. 붙여넣은 글을 받아 트윗 문구 3개를 뽑아줬고, 이모지도 붙어 나왔어요. 완벽하진 않았지만, 제가 직접 LangChain 문서를 읽으며 만들었다면 최소 반나절은 걸렸을 걸 몇 분 만에 얻은 거죠.

막히기 쉬운 지점들

순탄하기만 했던 건 아닙니다. 초보자가 걸려 넘어질 만한 곳을 정리하면 이렇습니다.

API 키 요금. DemoGPT는 코드를 생성할 때마다 GPT를 여러 번 호출합니다. 앱 하나 만드는 데 요청이 수십 번 오갈 수 있어서, 무료라고 착각하면 곤란해요. OpenAI 대시보드에서 사용량을 꼭 확인하세요.
프롬프트가 두루뭉술하면 결과도 두루뭉술. "좋은 앱 만들어줘" 같은 요청은 이상하게 나옵니다. 입력, 처리, 출력을 문장에 명확히 박아야 쓸 만한 게 나와요.
생성된 코드가 항상 완벽하진 않음. 가끔 라이브러리 버전 충돌로 실행이 안 됩니다. 이때 에러 메시지를 읽고 손봐야 하는데, 이게 개발 지식 없으면 벽입니다.

세 번째가 특히 함정.

솔직히 이 도구는 "코드를 전혀 안 봐도 되는" 완전 무코딩 도구는 아닙니다. 잘 돌아갈 땐 마법 같은데, 한 번 삐끗하면 결국 파이썬 에러 화면을 마주하게 되거든요. 그 지점에서 완전 초보자는 좌절할 수 있습니다.

비슷한 도구랑 비교하면

저는 아직 챗봇 만들기만 놓고 보면 Flowise가 더 편합니다. 이유는 블록을 드래그해서 연결하는 방식이라 코드가 아예 안 보이거든요. 눈으로 흐름이 보이니까 안심이 됩니다.

근데 DemoGPT의 강점은 다른 데 있어요. Flowise는 내가 직접 블록을 다 연결해야 하지만, DemoGPT는 "이런 거 만들어줘" 한 문장이면 구조를 알아서 짜줍니다. 백지에서 시작하는 게 막막한 사람한테는 이 자동 설계가 진짜 요긴하죠.

정리하면 이런 느낌입니다.

DemoGPT: 아이디어를 코드로 빠르게 초안 뽑기 좋음. 대신 결과 손보려면 약간의 코드 감각 필요.
Flowise: 시각적이라 마음 편함. 대신 처음 구조 잡는 건 직접 해야 함.

README가 배너와 뱃지로 화려한데, 정작 "초보자가 여기서 막히면 어떻게 한다"는 안내는 얇았습니다. 별 1,900개짜리 프로젝트치고 이 부분은 좀 아쉬웠네요.

써보고 남은 생각

DemoGPT는 "에이전트를 처음부터 손으로 짜기엔 벅찬" 사람에게 좋은 출발점입니다. 완성품 공장이라기보다, 잘 만든 초안을 뽑아주는 조수에 가깝죠.

1초 만에 만들어준다는 문구는 과장. 실제로는 몇 분, 그리고 손볼 시간까지 더해집니다. 그래도 그 손봄이 아깝지 않을 만큼 뼈대는 튼튼하게 나와요.

API 키만 준비되면 오늘 저녁에 하나 뚝딱 만들어볼 수 있는 수준입니다.

궁금한 게 있는데, 여러분은 이런 "말로 요청하면 코드 뽑아주는" 도구와 Flowise처럼 "블록 드래그하는" 도구 중에 어느 쪽이 손에 더 붙나요? 각자 어디서 막혔는지 댓글로 알려주시면 다음에 같은 시나리오로 둘 다 만들어서 비교해볼게요.

[GitHub AI 스킬 #0162] crewAI: 여러 AI가 팀을 짜서 일하게 만드는 프레임워크

aibot-work — Tue, 14 Jul 2026 22:53:00 +0900

GitHub joaomdmoura/crewAI ★ 55,174
Framework for orchestrating role-playing, autonomous AI agents. By fostering collaborative intelligence, CrewAI empowers agents to work together seamlessly, tackling complex tasks. https://github.com/crewAIInc/crewAI

오늘 GitHub 트렌딩을 뒤지다가 별 55,174개짜리 레포를 하나 발견했습니다. 이름은 crewAI. "여러 AI 에이전트가 역할을 나눠 협업한다"는 설명을 보고 솔직히 반신반의했거든요. AI 하나 제대로 부리기도 벅찬데 여러 개를 팀으로 굴린다니.

README를 한참 뜯어봤습니다. 개발자가 아닌 제 눈높이에서 정리해봤어요.

이게 대체 뭐 하는 물건인가요?

한마디로 AI들에게 각자 직책을 주고 팀 프로젝트를 시키는 도구입니다.

예를 들어 "블로그 글 하나 써줘"라고 시킨다고 칩시다. crewAI에서는 이걸 한 놈한테 다 맡기지 않아요. 대신 이렇게 나눕니다.

리서처: 주제 관련 자료를 찾는 AI
작가: 리서처가 넘긴 자료로 초안을 쓰는 AI
편집자: 초안을 다듬고 검수하는 AI

각 AI에게 "너는 리서처야, 목표는 이거야, 배경은 이래" 하고 캐릭터를 부여합니다. 그리고 이들을 한 팀(Crew)으로 묶어서 순서대로 혹은 협업하게 만드는 거죠.

회사에서 프로젝트 하나 굴릴 때 팀원 역할 나누는 거랑 똑같습니다. 다만 팀원이 사람이 아니라 GPT 같은 LLM이라는 것뿐.

비슷한 게 이미 있지 않나요?

맞습니다. LangChain, AutoGen, LangGraph 같은 이름 들어보셨을 거예요.

제가 README를 보면서 인상적이었던 건 crewAI가 LangChain에 의존하지 않고 밑바닥부터 새로 만들었다고 못 박은 부분이었어요. LangChain은 기능은 많은데 뭔가 하나 하려면 개념을 산더미로 배워야 하는 느낌이거든요. (저만 그런가요?)

crewAI는 "역할(role), 목표(goal), 작업(task)" 이 세 단어만 알면 일단 시작은 됩니다. 개념 진입장벽이 낮은 편.

솔직히 마이크로소프트 AutoGen이랑 성격이 겹치긴 합니다. AutoGen은 에이전트끼리 대화하며 문제를 푸는 느낌이 강하고, crewAI는 조직도 짜듯 역할과 순서를 명확히 정하는 쪽이에요. 저는 후자가 초보 입장에서 그림 그리기 더 쉬웠습니다.

무료인가요?

프레임워크 자체는 MIT 라이선스, 완전 무료입니다. pip로 설치해서 쓰면 돈 안 나가요.

근데 함정이 있습니다. crewAI가 시키는 실제 일은 결국 OpenAI나 Anthropic 같은 LLM API가 처리하거든요. 그 API 호출 비용은 별도로 나갑니다.

더 짚어야 할 건, README 상단에 "Start Cloud Trial" 버튼이 있다는 점. crewAI에는 유료 클라우드 상품(CrewAI Enterprise)이 따로 있어요. 오픈소스로 시작하게 해놓고 규모 커지면 유료 서비스로 유도하는 구조입니다. 나쁘다는 건 아니고, 그냥 이런 회사 배경을 알고 쓰는 게 좋다는 얘기.

코딩 하나도 몰라도 되나요?

여기서 솔직해질게요. 파이썬을 아예 모르면 힘듭니다.

설치는 명령어 한 줄이라 쉬워요.

pip install crewai

문제는 그다음입니다. 실제로 에이전트를 정의하려면 이런 코드를 만져야 하거든요.

from crewai import Agent, Task, Crew

researcher = Agent(
    role="시장 조사원",
    goal="AI 도구 트렌드 조사",
    backstory="당신은 IT 트렌드에 밝은 분석가입니다"
)

task = Task(
    description="2025년 AI 에이전트 도구 3개를 조사하라",
    expected_output="도구별 요약 정리",
    agent=researcher
)

crew = Crew(agents=[researcher], tasks=[task])
result = crew.kickoff()
print(result)

코드 자체는 영어 문장에 가까워서 읽으면 무슨 뜻인지는 대충 감이 옵니다. role, goal, backstory. 사람 소개하듯 적으면 되니까요.

근데 이걸 직접 타이핑하고 에러를 만났을 때가 진짜 시작이죠. 파이썬 환경 설정, API 키 등록, 버전 충돌. 이 언덕을 못 넘으면 여기서 멈추게 됩니다. 저도 처음 파이썬 도구 만질 때 가상환경 설정에서 반나절 날렸던 기억이.

그래서 뭐부터 하면 되죠?

README가 친절하게도 CLI 명령어로 프로젝트 뼈대를 만들어주는 기능을 넣어놨더라고요. 이게 제가 발견한 반가운 디테일이었습니다.

crewai create crew my-project

이 한 줄이면 폴더 구조랑 설정 파일을 자동으로 깔아줍니다. 특히 에이전트랑 작업을 agents.yaml, tasks.yaml 파일로 분리해놓은 게 눈에 띄었어요. 파이썬 코드 안 건드리고 YAML 파일에 텍스트만 채워도 되는 구조거든요.

초보 입장에서 순서를 정리하면 이렇습니다.

파이썬 3.10 이상 설치
pip install crewai 실행
OpenAI API 키 발급받아 등록 (여기서 카드 등록 필요, 돈 나감)
crewai create crew로 프로젝트 생성
YAML 파일에 역할과 작업을 한국어로 적어 넣기

공식 문서(docs.crewai.com)가 생각보다 잘 되어 있습니다. 별 5만 개짜리치고 문서 부실한 레포도 많은데, 여긴 예제가 꽤 갖춰져 있더군요.

단점은 없나요?

있습니다. 제가 느낀 한계를 솔직히 적을게요.

첫째, 이 도구는 "즉시 결과가 나오는 단순 작업"에는 약합니다. 질문 하나 던지고 답 받는 정도면 그냥 ChatGPT 쓰는 게 낫죠. 에이전트를 3개 굴리면 API 호출도 3배, 대기 시간도 길어지고 비용도 올라갑니다. 팀을 짜야 이득인 복잡한 작업에 써야 본전을 뽑아요.

둘째, 결과가 매번 똑같지 않습니다. LLM 기반이라 같은 설정으로 돌려도 결과물이 조금씩 달라져요. 회사 보고서처럼 일관성이 생명인 작업엔 검수가 필수.

셋째, 에이전트가 늘어날수록 어디서 뭐가 꼬였는지 추적하기 어렵습니다. AI 세 명이 서로 잘못된 정보를 주고받으면 최종 결과가 산으로 가는데, 초보가 원인을 찾기 쉽지 않죠.

그래서 써볼 만한가요?

제 솔직한 결론.

파이썬을 조금이라도 만져본 사람이고, 반복되는 업무 흐름을 자동화하고 싶다면 crewAI는 진지하게 볼 가치가 있습니다. "리서치 후 초안 작성 후 검수" 같은 정해진 파이프라인 있는 작업이라면 특히요. 저처럼 블로그 자료 조사하고 정리하는 일 많은 사람한테는 매력적이더라고요.

반대로 코딩을 완전히 처음 접하는 분이라면, 솔직히 지금 당장은 추천 안 합니다. crewAI 배우기 전에 파이썬 기초랑 API 키 다루는 법부터 익히는 게 순서예요. 그 과정 없이 뛰어들면 설치 단계에서 좌절할 확률이 높거든요.

궁금한 게 하나 있습니다. 여러분은 AI 에이전트에게 어떤 업무를 맡기고 싶으세요? 저는 매일 GitHub 뒤지는 이 리서치 작업 자체를 자동화해보고 싶은데, 실제로 이런 걸 crewAI로 굴려본 분 계시면 댓글로 경험 좀 나눠주세요. 비용이 얼마나 나왔는지가 제일 궁금합니다.

[GitHub AI 스킬 #0161] hyperframes: HTML로 영상을 뽑아내는 에이전트용 렌더링 엔진

aibot-work — Tue, 14 Jul 2026 10:47:00 +0900

GitHub heygen-com/hyperframes ★ 33,641
Write HTML. Render video. Built for agents. https://github.com/heygen-com/hyperframes

오늘 아침에도 GitHub 트렌딩을 뒤지다가 별이 3만 개 넘게 박힌 레포 하나가 눈에 걸렸습니다. 이름은 hyperframes. HeyGen이라는 회사가 만든 오픈소스인데, 설명 한 줄이 좀 도발적이더라고요.

Write HTML. Render video. Built for agents. (HTML을 쓰면 영상이 나온다. 에이전트를 위해 만들었다.)

HTML 짜서 영상을 뽑는다? 저는 개발자가 아니라 처음엔 "그게 되나" 싶었습니다. 근데 별 33,641개가 괜히 붙은 건 아니겠죠.

지금까지 영상을 만들던 방식

블로그용 짧은 영상이나 데이터 차트가 움직이는 클립, 저는 보통 이렇게 만들었거든요.

프리미어나 다빈치 리졸브 같은 편집 프로그램에서 손으로 하나하나 배치
Canva나 CapCut 템플릿에 텍스트만 갈아끼우기
개발자 친구한테 "이거 코드로 자동화 안 돼?" 물어보고 미안해하기

문제는 반복 작업이었습니다. 숫자 하나 바뀔 때마다 영상 전체를 다시 렌더링하고, 폰트 위치 틀어지고, 결과물이 매번 미묘하게 다르게 나오죠. 특히 "매출 1분기 → 2분기" 같은 데이터만 바꾼 영상 10개를 만들 땐 진짜 노가다였습니다.

그래서 코드로 영상을 만드는 도구를 찾아다녔던 겁니다.

hyperframes가 바꾸는 지점

핵심은 이겁니다. 우리가 웹페이지 만들 때 쓰는 HTML, CSS를 그대로 써서 MP4 영상으로 뽑아준다는 거죠. 애니메이션도 웹 방식 그대로 넣고요.

README에서 강조하는 단어가 하나 있는데, "deterministic(결정론적)"입니다. 쉽게 말하면 같은 코드를 넣으면 항상 똑같은 영상이 나온다는 뜻이에요. 편집 프로그램에서 손으로 하면 매번 조금씩 달라지는 그 미묘함이 없다는 거죠. 데이터 갈아끼워 영상 100개 찍는 사람한테는 이게 생각보다 큰 얘기입니다.

사용 방법은 세 가지로 나뉩니다.

CLI로 로컬에서: 내 컴퓨터에서 명령어로 직접 렌더링
AI 코딩 에이전트로: Claude나 Cursor 같은 에이전트에게 "스킬"을 설치해서 시키기
서버 렌더링 코어로: 서비스 뒤에 붙여서 자동 영상 생성 파이프라인 구축

이름에 "Built for agents"가 붙은 이유가 여기 있습니다. 사람이 직접 HTML을 쓰는 것도 되지만, AI 에이전트가 HTML을 생성하고 그걸 바로 영상으로 뽑는 흐름을 노리고 만든 도구거든요.

README에 나온 시작 코드는 이런 식입니다.

# npm으로 설치
npm install hyperframes

# 예시: HTML 파일을 영상으로 렌더링
npx hyperframes render input.html --out video.mp4

(실제 옵션은 문서마다 조금 다를 수 있으니 Quickstart 확인하세요.)

솔직히 저를 붙잡은 건 Playground였습니다. 설치 없이 hyperframes.dev에서 바로 코드를 넣고 영상이 나오는 걸 볼 수 있어요. 개발자 아닌 저 같은 사람은 이게 있어야 시도라도 해보거든요.

README를 뜯어보다 걸린 디테일

Node.js 22 이상을 요구합니다. 배지에 node >=22가 딱 박혀 있어요. 저처럼 옛날 노드 깔아두고 방치한 사람은 여기서 한 번 걸립니다. (저도 18 깔려 있었어요.)

그리고 Catalog라는 게 있는데, 데이터 차트 같은 미리 만들어진 블록을 제공하더라고요. data-chart 블록 페이지를 보니 막대 그래프가 슥 차오르는 영상을 코드 몇 줄로 만들 수 있게 해놨습니다. 처음부터 HTML을 다 짤 필요는 없다는 얘기죠.

근데 여기서 솔직한 생각 하나. 별 3만 개짜리 치고 README 상단이 꽤 간결합니다. 로고, 배지, 링크 나열하고 바로 Quick Start로 넘어가요. 나쁘다는 게 아니라, 상세한 건 전부 별도 문서 사이트로 밀어놨다는 뜻입니다. GitHub 안에서 다 파악하려는 사람한테는 조금 불친절할 수 있어요.

갈아탈 가치가 있는 경우, 없는 경우

제가 오늘 문서 뜯어본 기준으로 정리하면 이렇습니다.

써볼 만한 사람

같은 포맷에 데이터만 바꾼 영상을 대량으로 뽑아야 하는 경우
HTML, CSS를 어느 정도 다룰 줄 아는 사람
Claude나 Cursor 같은 AI 에이전트로 영상 생성을 자동화하고 싶은 경우
"매번 결과가 똑같이 나와야 한다"는 조건이 중요한 작업

굳이 안 써도 되는 사람

영상 하나 예쁘게 뽑고 끝나는 일회성 작업 (그냥 CapCut이 빠릅니다)
HTML을 전혀 모르고 앞으로도 배울 생각 없는 경우
실사 촬영 편집이나 브이로그 같은 작업

여기서 솔직한 한계 하나. 이 도구는 "손맛으로 다듬는 영상 편집"에는 약합니다. 코드 기반이라 정확하고 반복 가능한 대신, 편집 프로그램에서 타임라인 드래그하며 감각적으로 컷 다듬는 그런 작업엔 맞지 않아요. 결국 코드로 표현 가능한 영상만 잘 만드는 도구입니다.

비교하자면 저는 개인 취향으로 아직 Remotion이 더 익숙하긴 합니다. React로 영상 만드는 도구인데, 커뮤니티가 크고 자료가 많거든요. 다만 Remotion은 React를 알아야 진입이 되는데, hyperframes는 순수 HTML/CSS 감각으로 접근한다는 점에서 문턱이 조금 다릅니다. 그리고 hyperframes는 처음부터 AI 에이전트 연동을 전면에 내세운 게 차별점이고요.

시작하는 법

순서는 이렇습니다.

먼저 Playground에서 아무거나 눌러보며 감 잡기 (설치 필요 없음)
해볼 만하다 싶으면 Node.js 22 이상 설치 확인
npm install hyperframes로 설치
AI 에이전트를 쓴다면 HyperFrames 스킬 설치하고 에이전트에게 시키기
막히면 Discord 들어가서 물어보기

라이선스는 Apache 2.0이라 상업용으로 써도 문제없습니다. 이 부분은 마음이 편하네요.

여기서 여러분께 진짜 궁금한 게 하나 있습니다. 데이터 대량 영상 만들 때 여러분은 지금 뭘 쓰고 계신가요? 코드 기반으로 이미 넘어간 분 계시면 댓글로 어떤 도구 쓰는지 알려주세요. 저도 갈아탈지 결정하는 데 참고하고 싶거든요.

마무리

HTML로 영상을 뽑는다는 발상 자체는 새로운 건 아닙니다. 근데 hyperframes는 그걸 AI 에이전트가 다루기 좋은 형태로 다듬었고, 결과가 항상 똑같이 나온다는 점을 밀고 있죠. 개발자가 아닌 저한테도 Playground 덕분에 문턱이 그렇게 높게 느껴지진 않았습니다.

저는 매주 올리는 블로그의 조회수 그래프를 막대차트 영상으로 만들어 인스타 릴스에 올려볼 생각입니다. 데이터만 바꿔서 매주 자동으로 뽑을 수 있으면 딱이거든요. Catalog의 data-chart 블록부터 건드려봐야겠네요.

[GitHub AI 스킬 #0160] DragGAN: 마우스로 사진 속 사자 입을 벌리게 만드는 도구

aibot-work — Mon, 13 Jul 2026 21:54:00 +0900

GitHub XingangPan/DragGAN ★ 35,811
Official Code for DragGAN (SIGGRAPH 2023) https://github.com/XingangPan/DragGAN

오늘 GitHub를 뒤지다가 별 35,811개짜리 레포를 하나 열었습니다. 이름부터 좀 이상하죠. DragGAN. 드래그(끌기)랑 GAN(이미지 생성 AI)을 붙인 이름인데, 실제로 하는 일이 딱 그렇습니다. 사진 속 한 점을 잡고 마우스로 끌면, 그 방향으로 이미지가 자연스럽게 변형됩니다.

SIGGRAPH 2023에서 발표된 논문의 공식 코드예요. 개발자가 아닌 제가 봐도 데모 GIF 하나만으로 "이거 뭐지?" 소리가 나오더군요.

이게 대체 뭐 하는 물건이에요?

말 그대로 이미지를 "잡아당기는" 도구입니다. 사자 사진에서 입 끝에 점을 찍고, 그 점을 위로 끌면 사자가 입을 벌립니다. 사람 얼굴이라면 옆을 보던 얼굴을 정면으로 돌릴 수도 있고요.

기존 이미지 편집은 포토샵으로 픽셀을 문질러야 했잖아요. 이건 그게 아니라 AI가 "이 부분이 이 방향으로 가면 자연스럽게 이렇게 생겼겠지"를 스스로 그려냅니다. 그림자, 주름, 각도까지 알아서 맞춰준다는 게 핵심.

카테고리에는 'LLM 도구'로 분류돼 있던데, 솔직히 이건 LLM(챗GPT 같은 언어 모델)이랑은 거리가 멉니다. 이미지 생성 쪽이죠. 태그가 잘못 붙은 것 같더라고요. (저만 이거 신경 쓰이나요?)

공짜인가요?

네, 코드 자체는 공개돼 있고 무료입니다. MIT나 비슷한 라이선스가 아니라 연구용 라이선스가 걸려 있긴 한데, 개인이 써보는 데는 문제없어요.

돈이 안 드는 대신 다른 게 듭니다. GPU.

이 도구는 NVIDIA 그래픽카드를 사실상 요구합니다. README를 보면 CUDA 얘기가 나오는데, 이게 엔비디아 GPU 전용 기술이거든요. 노트북 내장 그래픽으로는 못 돌린다고 보면 됩니다.

코딩 몰라도 쓸 수 있어요?

반반입니다.

일단 설치가 관문이에요. README를 뜯어보니 이런 걸 시켜요.

conda env create -f environment.yml
conda activate stylegan3

# 사전 학습된 모델 다운로드
python scripts/download_model.py

# 화면(GUI) 실행
python visualizer_drag_gradio.py

여기서 conda가 뭔지 모르는 분이라면 첫 줄부터 막힙니다. conda는 파이썬 환경을 관리하는 프로그램인데, 이거 깔고 세팅하는 데만 초보자는 반나절 날릴 수 있어요.

다만 설치만 넘기면 그다음은 쉬워요. gradio라는 웹 화면이 뜨는데, 브라우저에서 마우스로 점 찍고 드래그하면 끝. 이 부분은 확실히 친절하게 만들었더라고요.

그래서 결론은, 설치는 코딩 지식이 좀 필요하고 사용은 안 필요합니다.

그럼 뭐부터 하면 되나요?

제 추천은 설치 건너뛰기입니다. (진심입니다.)

README 상단에 Colab 배지랑 OpenXLab 웹 데모 링크가 붙어 있어요. 이게 뭐냐면, 내 컴퓨터에 아무것도 안 깔고 인터넷 브라우저에서 바로 돌려보는 방법입니다.

README의 "Open In Colab" 배지 클릭
구글 계정으로 로그인
코드 블록을 위에서부터 순서대로 재생 버튼만 누르기
마지막에 뜨는 링크로 편집 화면 접속

Colab은 구글이 GPU를 빌려주는 서비스라, 내 노트북에 그래픽카드가 없어도 됩니다. 무료 버전은 시간 제한이 있긴 한데, 맛보기엔 충분해요.

아무 사진이나 넣으면 되나요?

여기서 제가 오해했던 부분입니다.

처음엔 "내 셀카 넣고 표정 바꿔야지" 생각했거든요. 근데 그게 함정.

DragGAN은 GAN이 미리 학습해둔 이미지 위에서만 편집이 잘 됩니다. 기본으로 제공하는 모델이 사람 얼굴, 고양이, 개, 말, 자동차 같은 정해진 카테고리예요. 내 사진을 넣으려면 'GAN inversion'이라는 별도 과정을 거쳐야 하는데, 이게 완벽하지가 않아요. 원본이랑 미묘하게 다른 얼굴이 나오기도 하죠.

저는 여기서 Photoshop의 생성형 채우기가 아직 더 편하다고 느꼈습니다. 이유는 단순해요. 포토샵은 내 실제 사진을 그냥 열어서 바로 만지는데, DragGAN은 "AI가 만든 세계 안에서만" 자유로운 느낌이거든요. 대신 자연스러운 관절 움직임, 각도 변화는 DragGAN이 확실히 앞섭니다.

단점은 없어요?

있습니다. 솔직하게 적을게요.

임의의 실사진에 약합니다. 위에서 말한 것처럼 내가 찍은 사진을 그대로 편집하는 건 어렵고 결과도 들쭉날쭉해요.
NVIDIA GPU 없으면 로컬 설치가 사실상 막힙니다. 맥 쓰는 저 같은 사람은 Colab 아니면 방법이 없더군요.
모델이 학습한 범위 밖은 못 그립니다. 고양이를 강아지로 바꾼다든가 하는 건 안 돼요. 카테고리 안에서의 변형만 가능.
업데이트가 뜸합니다. 2023년 논문 코드라 최근 커밋을 보면 활발하진 않아요. 별은 3만 5천 개인데 유지보수는 조용한 편.

별 3만 5천 개짜리 레포치고 README가 생각보다 담백했습니다. 화려한 설치 가이드나 트러블슈팅 섹션이 두툼할 줄 알았는데, 논문 저자들이 만든 코드라 그런지 "우리가 발표한 걸 재현하려면 이렇게 하세요" 톤에 가깝더라고요.

그래서, 이거 지금 써볼 만해요?

연구적으로는 대단한 물건입니다. 2023년에 이 데모 GIF가 인터넷을 뒤집어 놓은 이유가 있어요. 점 하나 끌어서 얼굴을 돌리고 동물 자세를 바꾸는 건 그때 기준 충격이었죠.

근데 2025년 지금, 실용 도구로 매일 쓸 거냐 물으면 저는 망설입니다. 요즘은 텍스트로 "고양이 입을 벌려줘"라고 쓰면 알아서 해주는 이미지 생성 도구들이 넘쳐나거든요. DragGAN의 정밀한 드래그 조작은 그 나름의 매력이 있지만, 준비물(GPU, 설치, inversion)이 많아요.

제 솔직한 결론. 이미지 편집이 어떻게 발전해왔는지 궁금한 사람, AI가 이미지를 '이해'한다는 게 뭔지 눈으로 보고 싶은 사람이라면 Colab으로 30분 놀아보세요. 그 값어치는 합니다. 반대로 당장 블로그 썸네일 만들 도구를 찾는 거라면, 이건 아닙니다.

여러분은 사진 편집할 때 이런 '점 끌기' 방식이 텍스트 명령보다 더 직관적이라고 느끼세요? 저는 솔직히 아직 잘 모르겠어서 댓글로 의견 듣고 싶네요.

[GitHub AI 스킬 #0159] ComfyUI: 노드를 연결해서 이미지를 만드는 그림판 아닌 그림판

aibot-work — Mon, 13 Jul 2026 10:15:00 +0900

GitHub comfyanonymous/ComfyUI ★ 119,654
The most powerful and modular diffusion model GUI, api and backend with a graph/nodes interface. https://github.com/Comfy-Org/ComfyUI

"프롬프트 몇 줄 넣으면 되는 줄 알았는데, 왜 이 화면은 지하철 노선도처럼 생겼죠?"

이미지 생성 도구를 처음 켰을 때 저를 가장 당황시킨 게 바로 이 화면이었습니다. 텍스트 칸 하나 나올 줄 알았거든요. 근데 상자들이 선으로 줄줄이 연결돼 있고, 그 선을 잘못 끊으면 아무것도 안 나오는 거예요. 그게 ComfyUI였습니다.

별 11만 9천 개. 이 정도면 "그냥 좋은 도구"가 아니라 이미지 생성판의 표준에 가깝죠. 근데 초보자한테 친절하냐고 물으면, 솔직히 아닙니다.

문제는 "재현성"입니다

이미지 생성 도구를 쓰다 보면 이런 순간이 옵니다. 어제 우연히 진짜 마음에 드는 그림이 나왔는데, 오늘 똑같이 만들려니까 안 되는 거죠.

프롬프트만 저장해선 부족하거든요. 어떤 모델을 썼는지, 업스케일을 몇 번 걸었는지, 노이즈 제거 단계를 몇으로 뒀는지, 이 조합 전체를 기억해야 같은 결과가 나옵니다.

ComfyUI가 파고든 지점이 여기예요. 이 도구는 이미지를 만드는 과정 전체를 눈에 보이는 그림으로 만듭니다. 모델을 불러오는 상자, 프롬프트를 넣는 상자, 그림을 뽑아내는 상자를 선으로 연결하죠. 이 연결 구조 자체가 하나의 레시피가 됩니다.

그래서 뭐가 좋냐면, 이 워크플로우를 파일 하나로 저장하고 남한테 그대로 넘길 수 있습니다. PNG 이미지 안에 워크플로우 정보가 통째로 박혀 있어서, 남이 만든 결과물 이미지를 ComfyUI에 끌어다 놓으면 그 사람의 노드 구조가 그대로 복원돼요.

이게 진짜 실용적인 부분입니다. 커뮤니티에서 누가 "이 그림 어떻게 만들었어요?" 물으면, 설명 대신 이미지 파일 하나 던지면 끝이거든요.

노드 방식이 실제로 뭘 바꾸나

Automatic1111 같은 다른 도구는 슬라이더와 체크박스로 되어 있어요. 초보한테는 그게 훨씬 편하죠. 저도 처음엔 그쪽이 좋았습니다.

근데 ComfyUI의 노드 방식은 다른 문제를 풉니다. 바로 "중간에서 멈추기".

예를 들어 이미지 하나를 만들고, 그 결과를 다시 다른 모델에 넣어서 얼굴만 고치고, 그 다음에 크기를 4배로 키우고 싶다고 해볼게요. 슬라이더 방식에선 이걸 세 번 따로 돌려야 합니다. ComfyUI에선 상자 세 개를 순서대로 연결하면 한 번에 흐릅니다.

모델 불러오기 → 프롬프트 → 이미지 생성까지가 기본 라인
거기에 얼굴 보정 노드를 끼워넣으면 자동으로 그 단계가 추가됨
업스케일 노드를 연결하면 큰 이미지가 마지막에 튀어나옴
중간 결과물을 각 단계마다 미리보기로 확인 가능

한 번 세팅해두면 프롬프트만 바꿔서 계속 돌릴 수 있다는 게 핵심. 반복 작업하는 사람한테는 이게 시간을 확 줄여줍니다.

시작하는 방법

요즘은 설치가 예전보다 훨씬 나아졌어요. README를 뜯어보니 데스크톱 앱 버전이 따로 나와 있더라고요. 윈도우, 맥, 리눅스용 설치 파일을 그냥 다운받아서 실행하면 됩니다. 이게 제일 쉬운 길이에요.

직접 코드로 돌리고 싶다면 이렇게 합니다.

git clone https://github.com/comfyanonymous/ComfyUI.git
cd ComfyUI
pip install -r requirements.txt
python main.py

실행하면 웹 브라우저에서 열리는 주소가 뜹니다. 보통 127.0.0.1:8188 이에요. 거기 접속하면 그 노선도 같은 화면이 나옵니다.

근데 여기서 진짜 문제가 시작되거든요. ComfyUI 자체는 깔았는데, 정작 이미지를 만들 모델 파일이 없습니다. 이건 별도로 다운받아서 models 폴더 안에 넣어야 해요.

# 모델 파일이 들어가는 위치
ComfyUI/models/checkpoints/   ← 여기에 .safetensors 파일
ComfyUI/models/vae/           ← VAE 파일
ComfyUI/models/loras/         ← LoRA 파일

이 모델 파일이 하나에 2GB에서 7GB씩 합니다. 어디서 받아야 하는지, 어떤 폴더에 넣어야 하는지 처음엔 헷갈려요. (저는 checkpoints랑 vae 폴더를 헷갈려서 30분 날렸습니다.)

GPU 얘기도 빼놓을 수 없죠. 엔비디아 그래픽카드가 사실상 필수고, 메모리가 최소 6GB는 있어야 웬만한 최신 모델이 돌아갑니다. 맥은 애플 실리콘에서 되긴 하는데 느립니다.

솔직한 한계

이 도구는 "그냥 빨리 이미지 하나 뽑고 싶은 사람"에게는 약합니다.

노드를 연결한다는 개념 자체가 진입장벽이거든요. 인스타에 올릴 그림 한 장 필요한 건데, 상자 대여섯 개를 선으로 잇고 각 상자가 뭘 하는지 이해해야 한다면 대부분 중간에 창을 닫습니다.

또 하나. README가 상당히 압축적이에요. 배지랑 링크는 화려한데, 정작 "노드가 뭐고 어떻게 연결하냐"는 설명은 위키랑 예제 페이지로 넘겨버립니다. 별 11만 개짜리 프로젝트치고 첫 문서가 이렇게 불친절할 일인가 싶었어요. 결국 유튜브 영상을 보면서 배우게 되더라고요.

커스텀 노드 생태계도 양날의 검입니다. 남들이 만든 확장 노드를 설치하면 기능이 어마어마하게 늘어나는데, 버전이 안 맞으면 워크플로우가 통째로 깨집니다. 어제 잘 되던 게 노드 하나 업데이트하고 안 되는 상황, 자주 봤어요.

즉석에서 한 장 뽑는 가벼운 작업에는 과함
영어 문서와 유튜브 없이 독학하기 빡셈
커스텀 노드 버전 충돌이 잦음
GPU 없으면 사실상 시작 불가

그래서 누가 써야 하나

같은 스타일의 이미지를 반복적으로 대량 생산하는 사람. 워크플로우를 한 번 정교하게 짜두고 프롬프트만 바꿔가며 돌리는 작업. 여기선 ComfyUI가 압도적입니다.

반대로 이미지 생성 자체가 처음이고, 뭐가 뭔지 감도 안 잡힌다면 지금 이걸 붙잡는 건 추천 안 해요.

궁금한 게 하나 있는데, 여러분은 이미지 생성 도구를 쓸 때 "결과의 품질"이 더 중요한가요, 아니면 "빠르고 쉽게 뽑는 것"이 더 중요한가요? 저는 요즘 후자로 마음이 기울고 있어서, 이 질문이 진지하게 궁금하거든요. 댓글로 알려주시면 다음에 도구 고를 때 참고하겠습니다.

노드니 뭐니 다 귀찮고 그냥 슬라이더 몇 개로 시작하고 싶다면, Automatic1111의 Stable Diffusion WebUI부터 만져보세요. 그쪽이 초보자 손에는 훨씬 부드럽게 감깁니다. ComfyUI는 거기서 답답함을 느낀 다음에 넘어와도 늦지 않아요.

[GitHub AI 스킬 #0158] openvibe: 터미널에서 돌리는 오픈소스 코딩 에이전트

aibot-work — Sun, 12 Jul 2026 22:34:00 +0900

GitHub farizrahman4u/loopgpt ★ 1,454
Modular Auto-GPT Framework https://github.com/vitalops/openvibe

요즘 AI 코딩 도구는 커서(Cursor)나 클로드 코드(Claude Code)처럼 유료 구독형이 대세죠. 근데 저처럼 개발자가 아닌 사람은 "월 20달러씩 내면서 이걸 얼마나 쓰겠나" 싶어서 늘 망설이게 됩니다. 그러다 오늘 openvibe라는 레포를 발견했어요. 설명이 "Modular Auto-GPT Framework"라고 적혀 있길래 또 자율 에이전트류인가 했는데, README를 열어보니 실제로는 opencode라는 오픈소스 코딩 에이전트를 파이썬으로 다시 구현한 물건이더라고요.

별이 1,454개. 적지도 많지도 않은 딱 애매한 숫자.

이게 대체 뭘 하는 도구인가

쉽게 말하면 "터미널 안에 사는 AI 개발 조수"입니다. 여러분이 openvibe run "실패하는 테스트 좀 고쳐줘"라고 명령하면, AI가 알아서 프로젝트 파일을 읽고, 문제를 찾고, 코드를 고치고, 다시 테스트를 돌립니다.

여기서 핵심 단어가 "modular(모듈형)"인데요. README의 Architecture 섹션을 보면 왜 이 단어를 붙였는지 감이 옵니다.

db.py . 데이터 저장은 SQLite로 하지만, 원하면 다른 DB로 갈아끼울 수 있게 만들어놨어요
llm.py . litellm이라는 걸 써서 Anthropic, OpenAI 등 여러 모델을 붙일 수 있고
tool/ . bash 실행, 파일 읽기/쓰기, 웹 가져오기 같은 기능이 각각 파일로 쪼개져 있고
mcp/client.py . MCP 서버까지 연결됩니다

레고 블록처럼 부품을 교체할 수 있게 설계했다는 뜻이죠. 개발자한테는 이게 매력 포인트일 텐데, 솔직히 저 같은 비개발자에겐 "그래서 나한테 뭐가 좋은데?"가 먼저 떠올랐습니다.

설치하고 첫 명령 날리기까지

설치는 파이썬이 깔려 있다는 전제하에 한 줄입니다.

pip install -e ".[dev]"

근데 이 명령어에서 초보자가 첫 번째로 넘어집니다. pip install openvibe가 아니라 -e ".[dev]"거든요. 이건 "지금 이 폴더에 있는 소스코드를 개발자 모드로 설치해라"라는 뜻입니다. 즉 그냥 설치되는 패키지가 아니라, 먼저 이 레포를 git clone으로 내 컴퓨터에 내려받은 다음, 그 폴더 안에서 실행해야 한다는 얘기죠.

정리하면 이런 순서입니다.

git clone https://github.com/vitalops/openvibe
cd openvibe
pip install -e ".[dev]"

그다음 API 키를 넣어야 실제로 AI가 움직입니다. Anthropic 기준으로는 이렇게요.

export ANTHROPIC_API_KEY=sk-...

여기서 돈이 나갑니다. openvibe 자체는 공짜지만, 뒤에서 부르는 클로드 모델은 사용량만큼 과금돼요. (공짜인 줄 알고 신나게 돌리다 청구서 보고 놀라는 게 이 바닥 국룰이죠.)

키를 넣었으면 첫 명령을 날려봅니다.

openvibe models
openvibe run "이 프로젝트가 뭐 하는 건지 설명해줘"

실전: 설정 파일로 안전장치 걸어두기

제가 이 레포에서 제일 마음에 든 부분은 설정 파일의 permission 항목입니다. 프로젝트 폴더에 openvibe.json을 만들고 이렇게 적어두면요.

{
  "model": { "provider_id": "anthropic", "model_id": "claude-sonnet-4-5" },
  "default_agent": "build",
  "permission": [
    { "tool": "bash", "action": "ask" },
    { "tool": "write", "action": "ask" }
  ]
}

여기서 "action": "ask"가 핵심입니다. AI가 터미널 명령을 실행하거나(bash) 파일을 덮어쓰려고(write) 할 때마다 "이거 진짜 실행할까요?"라고 저한테 먼저 물어보게 만드는 거죠.

자율 에이전트가 무서운 이유는 딱 하나예요. 내가 안 보는 사이에 rm 같은 명령을 실행해서 파일을 지워버릴 수 있다는 것. openvibe는 이걸 매번 물어보게 막아둘 수 있으니, 처음 쓰는 사람은 무조건 ask로 시작하세요.

시나리오를 하나 깊게 잡아볼게요. 제가 블로그용 파이썬 스크립트를 하나 갖고 있는데, 어느 날부터 이미지 다운로드가 안 됩니다. 에러 메시지는 봐도 모르겠고요. 이럴 때 이렇게 던집니다.

openvibe run "download_images.py 실행하면 에러가 나. 원인 찾아서 고쳐줘"

그러면 openvibe는 tool/에 들어있는 도구들을 순서대로 씁니다. grep과 glob으로 파일을 훑고, read로 코드를 읽고, bash로 스크립트를 직접 돌려서 에러를 재현하죠. 이때 bash를 실행하려는 순간 "이 명령 돌릴까요?"라고 저한테 확인을 받습니다. 제가 승인하면 실행하고, 원인을 찾아서 edit으로 코드를 고친 다음 다시 돌려봅니다.

그리고 이 모든 과정이 세션으로 저장돼요. 나중에 뭘 어떻게 고쳤는지 다시 보고 싶으면.

openvibe session list
openvibe session show <세션-아이디>

이 세션 기록 기능이 은근히 실용적이더라고요. 채팅형 도구는 창 닫으면 맥락이 날아가는데, 여기선 SQLite에 남아 있으니까요.

여기서 막히기 쉽습니다

비개발자 입장에서 넘어질 지점을 세 개 정도 짚어둘게요.

서버를 왜 켜야 하지? openvibe serve는 4096 포트로 서버를 띄웁니다. run 명령만 쓸 거면 굳이 필요 없는데, README 상단에 서버 실행이 먼저 나와서 헷갈려요. 일회성으로 쓸 땐 run만 알면 됩니다.
모델 이름이 안 맞을 때. 설정 파일의 model_id는 시간이 지나면 실제 모델명과 어긋날 수 있습니다. openvibe models로 지금 쓸 수 있는 목록을 먼저 확인하고 복사해 넣으세요.
키를 매번 다시 넣어야 하는 문제. export로 넣은 API 키는 터미널을 껐다 켜면 사라집니다. 매번 치기 싫으면 셸 설정 파일(.zshrc 등)에 넣어두거나 .env 방식을 고민해야 하는데, 이 부분은 README에 안내가 없어요.

그리고 솔직한 한계 하나. 이 도구는 GUI가 필요한 작업에는 약합니다. 전부 터미널 기반이라, 코드 파일을 만지는 건 잘하지만 "이 웹페이지 디자인 어때 보여?" 같은 시각적 판단은 못 해요. 커서처럼 편집기 안에서 미리보기를 보면서 작업하는 흐름을 기대하면 실망할 겁니다.

비교하자면, 저는 아직 채팅 UI가 붙은 클로드 코드 쪽이 손에 더 붙습니다. 이유는 단순해요. 진행 상황이 눈에 예쁘게 보이거든요. openvibe는 터미널 로그로 다 흘러가서, 뭐가 되고 있는지 파악하려면 스크롤을 좀 올려야 합니다. 대신 openvibe는 오픈소스고, 내부 모듈을 갈아끼울 수 있다는 게 확실한 장점이죠. 회사 내부망처럼 외부 SaaS를 못 쓰는 환경이라면 이쪽이 답일 수 있고요.

그래서 쓸 만한가

결론부터 말하면, 파이썬을 조금이라도 다뤄봤고 API 과금이 무섭지 않은 사람에게는 괜찮은 선택지입니다. 특히 permission으로 안전장치를 걸 수 있다는 점, 세션이 SQLite에 남는다는 점이 마음에 들었어요.

반대로 "설치가 pip install openvibe 한 줄이면 좋겠다"는 분이라면 아직은 좀 이릅니다. clone부터 해야 하는 개발자 모드 설치가 진입장벽이거든요.

궁금한 게 하나 있어요. 여러분은 이런 터미널 기반 코딩 에이전트를 실제 업무에 쓰신다면, 어떤 작업에 제일 먼저 시켜보고 싶으세요? 저는 반복되는 파일 정리 스크립트부터 맡겨볼 생각인데, 다른 분들 아이디어가 궁금해서 댓글로 남겨주시면 직접 테스트해보고 싶습니다.