저는 지난 6개월 동안 제가 매일 사용하는 텍스트 처리(text_processing) 및 추출 도구를 위해 완전히 로컬로 작동하는 에이전트형 파이프라인(agentic pipeline)을 구축하려고 노력해 왔습니다.

모든 것을 단일 소비자용 GPU 설정에서 실행하고 있기 때문에, 저의 선택지는 더 작은 양자화된 오픈 웨이트(open weights) 모델로 제한됩니다(주로 Gemma 4 31B와 Qwen 3.5 변형 모델 사이를 오가고 있습니다).

새로운 모델이 출시될 때마다 저는 그것을 불러오고, Hugging Face를 읽습니다. 솔직히 말해서 새로운 것이 나올 때마다 엄청난 소외감(FOMO)을 느끼거든요. 벤치마크를 확인하며 "드디어 이 모델은 스스로 전체 실행 로직을 설계할 수 있는 추론 능력(reasoning capacity)을 갖추겠지"라고 생각합니다.

하지만 결코 제대로 작동하지 않았습니다. 저는 제 프로토 에이전트(proto agent)에게 거대한 시스템 프롬프트(system prompt)를 주고, 수많은 도구(tools)를 건네주며, 들어오는 비정형 데이터(unstructured data)를 자율적으로 분석하고, 최선의 처리 단계를 결정하며, 예외 케이스(edgecase exceptions)를 처리하고, 깔끔한 JSON을 출력하기를 기대했습니다. 어떤 날은 완벽하게 실행되기도 했습니다.

하지만 다음 날이면 그냥 작동하지 않습니다. 마치 "아, 나 안 해"라고 하는 식이죠. 모든 것이 엉망이 되고 온도는 하늘 높이 치솟는 그런 상황 말입니다. 저는 실제로 데이터를 사용하는 시간보다 프롬프트 가중치(prompt weights)를 미세 조정하고 온도(temperature)를 조절하는 데 더 많은 시간을 보냈습니다. 결국 저는 추론 루프(reasoning loops)를 전통적이고 지루하며 완전히 경직된 Python 코드로 교체했습니다.

모델에게 워크플로우(workflow)에 대해 생각하라고 요청하는 대신, 스크립트가 모든 힘든 일을 처리하게 했습니다. 스크립트가 텍스트를 청크(chunk)로 나누고, API 로직을 처리하며, 엄격한 정규 표현식(regex) 필터를 실행하고, 실행 흐름을 관리합니다. 저는 로컬 LLM의 역할을 절대적인 최소한으로 축소했습니다. 즉, "정확히 이 300단어 분량의 청크를 보고, 이 세 가지 특정 엔티티(entities)를 추출하여, 반드시 스키마(schema) 내에 출력하라"는 식입니다. 만약 텍스트 청크가 예상되는 기준과 일치하지 않으면, 코드는 즉시 에러를 발생시키고 이를 수동 검토 폴더로 보냅니다.

이제 모델은 더 이상 독자적인 결정을 내릴 수 없습니다. 결과는 어떨까요? 처리 속도는 올라갔고, 리소스 활용률(resource utilization)은 떨어졌으며, 파이프라인은 단 한 번의 로직 실패 없이 4일 연속으로 작동했습니다. 하지만 뭐, 이게 폭풍 전야일지도 모르죠? 잘 모르겠습니다.

단순한 데이터 파서 (data_parser)로서 고도로 특화된 로컬 모델을 사용하는 멍청하고 경직된 스크립트가, 엣지 케이스 (edge case) 때문에 정신을 놓지 않았는지 확인하기 위해 인간의 보살핌이 필요한 "똑똑한" 에이전트보다 무한히 더 가치 있습니다. 하지만 이것은 단지 제 개인적인 의견일 뿐입니다.

제출자: /u/SpicyTofu_29
[링크] [댓글]