「LLM의 출력이 불안정한 문제」를 「먼저 모듈을 만든다」로 상당히 개선했다는 이야기

LLM을 사용하여 개발하다 보면, 이런 일이 늘어나지 않나요?

무한 프롬프트 지옥 (Infinite Prompt Hell): 첫 출력에서 80%는 완성되었는데, 세부 사양 조정이나 버그 수정을 위해 20회 이상 주고받기(미세 조정)를 반복하게 된다. -
패턴의 중복: 비슷한 기능을 만들 때마다, 유사한 수정 프롬프트를 몇 번이고 LLM에 다시 보낼 필요가 있어 효율이 떨어진다. -
컨텍스트의 비대화와 비용 증가: 주고받는 횟수가 늘어날수록 프롬프트 소비 토큰이 증가하여, API 비용이나 ChatGPT의 이용 제한이 급증한다.

이 문제를 해결하기 위해, Reddit의 한 게시자는

기능을 직접 만들게 하는 것이 아니라, 먼저 재사용 가능한 모듈을 만든다

라는 진행 방식을 시도했고, 그 결과

LLM에 대한 지시의 흔들림이 줄어들고, 신규 기능 구현도 안정적으로 변했다

라는 효과를 얻었다고 합니다.

본 기사에서는 게시자의 허가를 받은 후, 그 워크플로우(Workflow)의 개요에 대해 실례를 곁들여 정리합니다.

게시자가 채택한 것은 먼저 재사용 가능한 모듈을 만들고, 그 후에 개별 기능을 구현한다는 2단계 접근 방식입니다.

구체적으로는 프로세스를 다음과 같은 두 가지 페이즈(Phase)로 분리합니다.

페이즈 1: 「Verdent의 플래닝(Planning) 기능」 + 「Codex」로, 범용적으로 재사용할 수 있는 **「재사용 가능한 모듈」**을 먼저 작성한다 -
페이즈 2: 완성된 모듈을 컨텍스트(Context)로 제공하여, 구체적인 개별 기능을 구현한다

게시자가 검증한 예를 소개합니다.

백엔드(API/K8s)부터 프론트엔드(UI)까지 포함하는, 다소 복잡한 「비동기 워크플로우 실행 모듈」을 구현하는 케이스입니다.

기존의 Reddit 분석 도구(reddit-post-analyzer) 코드를 참고하면서, 다음과 같은 프롬프트를 투입했습니다.

please combine the code from /en/tools/reddit-post-analyzer and the doc docs/workflow/ASYNC_WORKFLOW_GUIDE.md generate a demo tool, contain preview logic and async execute logic preview return some test information execution sleep 10 seconds then return test information

(번역:
/en/tools/reddit-post-analyzer의 코드와 docs/workflow/ASYNC_WORKFLOW_GUIDE.md 문서를 조합하여 데모 도구를 생성해 주세요. 프리뷰 로직과 비동기 실행 로직을 포함해야 합니다. 프리뷰 시에는 테스트 정보를 반환하고, 실행 시에는 10초간 슬립(Sleep)한 후 테스트 정보를 반환하도록 하세요)

여기서 「Verdent의 진가가 발휘됩니다.

Verdent는 이 모호한 요구사항을 잘게 쪼개어, 엄격한 아키텍처 계획으로 분해했습니다.

Verdent가 작성한 정교한 플랜을 Codex에 읽히자, 놀랍게도

• React 컴포넌트 (UI)
• API 라우팅 (Backend)
• Kubernetes 매니페스트 파일 (Infrastructure)

등을 포함한 총 21개의 파일을 한 번에 수정 및 생성했다고 합니다.

그 후에는 이 완성된 모듈을 향후 개발의 「기준(Reference)」으로 저장해 두기만 하면 됩니다.

게시자는

「처음부터 Verdent + Codex로 최종 기능을 만들려고 했을 때보다, 중간에 모듈화를 거치는 것이 훨씬 결과가 안정적이었다」

라고 언급하며, 명확한 이론적 근거는 알 수 없으나 다음과 같은 이유 때문일 것이라고 추측하고 있습니다.

프로세스를 나눔으로써 LLM의 태스크(Task)가 단순해집니다.

모듈 작성 시: LLM은 「범용적인 설계 패턴 (아키텍처)」을 올바르게 구성하는 것에만 집중하면 된다. -
기능 구현 시: 이미 눈앞에 있는 설계 패턴을 컨텍스트(본보기)로 참고하면서, 「고유한 비즈니스 로직」을 구현하는 것에만 집중할 수 있다. -

사람이 난해한 시스템을 설계할 때와 마찬가지로, LLM에게도 「설계」와 「구현」을 동시에 시키지 않는 편이 압도적으로 정밀도가 높아집니다.

「Verdent로 「플래닝(Planning)」을 수행하는 페이즈는 가장 토큰을 많이 소비하는 부분입니다.

하지만, 이 워크플로우라면 무거운 플래닝(Planning) 세션은 「처음 한 번(모듈의 설계)」만으로 충분합니다.

유사한 기능을 만들 때는 해당 모듈을 복사해서 재사용하면 됩니다. 이를 통해 개발 비용을 대폭 절감할 수 있습니다.

작성자의 사례에서는 Verdent로 플래닝(Planning)을 수행하고, Codex로 모듈 구현과 기능 전개를 진행함으로써, 복잡한 기능이라도 안정성과 재사용성을 양립하기 쉬워졌다고 합니다.

특히, 비슷한 종류의 기능을 지속적으로 개발하고 있는 경우, 이러한 「모듈 선행」 방식은 궁합이 상당히 잘 맞는다고 느껴졌습니다.

만약 LLM을 사용한 개발 플로우 내에서 요구사항 정리나 설계 분해를 조금 더 자연스럽게 포함하고 싶다면, 플래닝(Planning)의 선택지로서 Verdent를 살펴보는 것도 좋을 것입니다.