LLM 에이전트가 항상 "프롬프트 스파게티"가 되어버리는 이유는 무엇일까요?

커뮤니티 반응

에이전트 개발 과정에서 겪는 공통적인 고충에 대해 깊은 공감이 형성되어 있으며, 구조적 해결책에 대한 관심이 높다.

주요 논점

01찬성다수

LLM 시스템은 본질적으로 확률적이므로 프롬프트가 복잡해지는 것은 자연스러운 현상이며 이를 관리할 도구가 필요하다.

합의점 vs 논쟁점

합의점

단순한 프롬프트 나열은 대규모 시스템에서 반드시 한계에 직면한다.
확률적 시스템을 제어하기 위해서는 구조화된 프레임워크의 도움이 필수적이다.

실용적 조언

프롬프트가 비대해지기 전에 LangGraph와 같은 상태 관리 프레임워크 도입을 검토하여 흐름을 명시적으로 정의하라.
DSPy를 사용하여 프롬프트를 하드코딩하는 대신 프로그래밍 방식으로 최적화하고 구조화하라.
단순한 재시도 로직 대신 모델의 출력을 검증하고 수정할 수 있는 명확한 스키마와 피드백 루프를 설계하라.

섹션별 상세

에이전트 개발 초기에는 단일 시스템 프롬프트와 도구로 시작하여 우아한 아키텍처를 유지하지만, 실무 적용 과정에서 예외 상황을 처리하기 위해 수많은 프롬프트와 숨겨진 가드레일이 추가되는 현상을 지적했다. 이는 초기 설계의 단순함이 실제 복잡성을 감당하지 못해 발생하는 문제로, 개발자가 의도치 않게 시스템을 누더기처럼 기워 붙이게 만든다. 결국 코드는 읽기 어려워지고 특정 부분을 수정했을 때 전체 시스템에 미치는 영향을 예측하기 힘든 상태에 도달한다.

결과적으로 결정론적 로직을 작성하는 소프트웨어 공학이 아니라, 확률적 시스템이 올바르게 작동하도록 유도하는 '프롬프트 가드닝(Prompt Gardening)'으로 변질되는 것에 대한 피로감을 공유했다. 개발자는 코드를 짜는 것이 아니라 모델이 똑똑하게 행동하기를 바라며 프롬프트를 조금씩 수정하는 반복 작업에 매몰된다. 이러한 방식은 재현성이 낮고 디버깅이 극도로 어려워지는 결과를 초래하여 개발 효율성을 크게 저하시킨다.

복잡해진 시스템을 관리하기 위해 프롬프트를 구조화된 시스템으로 리팩터링하거나, LangGraph 또는 DSPy와 같은 프레임워크를 도입하여 제어권을 확보하려는 시도들에 대해 질문했다. 단순히 프롬프트를 늘리는 대신 상태 머신이나 프로그래밍 방식의 프롬프트 최적화를 통해 시스템의 예측 가능성을 높이려는 노력이 필요하다는 인식이 깔려 있다. 커뮤니티 구성원들이 이러한 혼돈을 어떻게 구조적으로 해결하고 있는지에 대한 실질적인 경험 공유를 요청했다.

용어 해설

프롬프트 스파게티(Prompt Spaghetti): — 여러 개의 프롬프트와 가드레일, 재시도 로직이 복잡하게 얽혀 유지보수가 불가능해진 상태를 의미한다. 이는 에이전트의 예외 상황을 처리하려다 발생하는 전형적인 안티 패턴으로, 시스템의 예측 가능성을 떨어뜨리고 디버깅을 어렵게 만든다.
결정론적 로직(Deterministic Logic): — 동일한 입력에 대해 항상 동일한 출력을 보장하는 프로그래밍 방식이다. 확률적으로 동작하는 LLM과 대비되는 전통적인 소프트웨어 공학의 핵심 개념으로, 시스템의 안정성과 신뢰성을 확보하는 데 필수적이다.
확률적 시스템(Probabilistic System): — 입력에 대해 결과가 확률적으로 결정되어 매번 출력이 달라질 수 있는 시스템이다. LLM 에이전트가 이 특성을 가지기 때문에 제어가 어렵고, 개발자가 의도한 대로 동작하게 만들기 위해 정교한 설계가 요구된다.
가드레일(Guardrails): — LLM의 출력이 특정 범위를 벗어나지 않도록 제한하거나 필터링하는 안전장치이다. 시스템의 신뢰성을 높이기 위해 사용되지만, 과도하게 추가될 경우 시스템의 복잡성을 증대시키고 성능 저하를 유발할 수 있다.

언급된 도구

LangGraph추천

에이전트의 상태와 흐름을 그래프 구조로 관리하여 복잡성을 제어함

DSPy추천

프롬프트를 프로그래밍 방식으로 최적화하고 구조화하여 유지보수성 향상