6 minute read

“그냥 ChatGPT 하나만 쓰면 되는 거 아닌가요?”

개발 효율성을 고민하는 많은 분들이 가장 먼저 던지는 질문입니다. 하지만 실무 환경에서 LLM(거대 언어 모델)을 활용해 본 분들이라면, 단 하나의 모델만으로는 해결하기 어려운 명확한 한계에 부딪히곤 합니다.

왜 ChatGPT 하나만으로는 부족할까요?

ChatGPT는 훌륭한 대화형 파트너이지만, 실제 코드 베이스를 관리하고 복잡한 시스템을 구축하는 데에는 몇 가지 치명적인 어려움이 따릅니다.

  • 반복되는 컨텍스트 주입: 프로젝트의 규모가 커질수록 “지금까지 작성한 코드의 구조가 이렇고, 어제 수정했던 이 함수는 이렇게 동작해”와 같은 설명을 계속해서 반복해야 합니다.
  • 휘발성 정보: 대화창을 새로 열거나 시간이 지나면 이전의 맥락을 놓치기 일쑤이며, 이로 인해 개발자는 프로젝트의 상태를 매번 다시 학습시켜야 하는 소모적인 과정을 겪습니다.
  • 모델별 특성의 부재: 범용 모델인 ChatGPT와 코드 실행 및 최적화에 특화된 모델은 서로 다른 역할을 수행해야 합니다.

전략적 선택: Discussion LLM vs. Execution LLM

실제 소프트웨어 개발 과정은 ‘의사결정(Discussion)’‘코드 구현(Execution)’이라는 두 가지 핵심 영역으로 나뉩니다.

  • Discussion LLM (ChatGPT, Gemini 등): 아키텍처를 설계하고, 문제를 정의하며, 논리적인 해결책을 도출하는 데 탁월합니다.
  • Execution LLM (Codex, Claude Code 등): 도출된 설계를 바탕으로 실제 동작하는 코드를 생산하고, 문법적 오류를 수정하며, 실질적인 빌드 작업을 수행합니다.

하나의 도구에만 의존하는 것은, 기획자 없이 개발자만 있는 팀과 같습니다. 우리는 이 두 모델의 장점을 영리하게 결합해야 합니다.

개발의 페이스를 바꾸어 해결하기

저는 이러한 한계를 극복하기 위해 특별한 워크플로가 필요하다는 것을 알게되었습니다. 단순히 모델을 교체하는 것이 아니라, 프로젝트의 의도와 구조를 문서화하여 영구적으로 저장하는 시스템을 갖추어야 한다고 믿습니다.

새로운 워크플로의 차별점**

  1. 지능형 컨텍스트 관리: 프로젝트의 아키텍처와 핵심 요구사항을 문서화하여 모델에 자동으로 주입합니다. 반복적인 설명 없이도 바로 본론으로 들어갈 수 있습니다.
  2. 하이브리드 접근법: Discussion LLM과 Execution LLM을 워크플로우에 통합하여, 기획 단계부터 완성 단계까지 최적의 모델이 업무를 수행하게 합니다.
  3. 비용 효율성: 불필요한 프롬프트 토큰 낭비를 줄이고, 가장 효율적인 모델 조합을 통해 소프트웨어 개발의 완성도를 높입니다.

AI-Native 소프트웨어 개발 원칙

  • 사람은 특정 LLM을 고집해서는 안된다.
  • 사람은 어떤 문서도 직접 만들지 않는다.
  • 사람은 어떤 코드도 직접 작성하지 않는다.
  • 모든 문서는 Discussion AI와의 대화를 통해서만 작성한다.
  • 모든 코드는 Execution AI와 프롬프트를 통해서만 작성한다.
  • Discussion AI 와의 대화는 산출물이 반드시 나와야 하며, 그것은 문서 혹은 Issues 여야 한다.
  • 모든 문서와 코드의 작성 및 수정은 commits 메시지로 history가 기록되어야 한다.
  • 현재 구현 상태는 TASKS.md 파일로 관리되어야 한다.
  • 레포지토리의 Human 문서는 README.md 와 같은 특별한 예외를 제외하면 docs/안에 두어야 하며, AI는 이 폴더문서를 참조해서는 안된다.

이를 도와주는 도구

전 이런 반복되는 문서와 작업을 효율화 시키기 위해서 홈페이지와 Github 저장소, 그리고 cli 툴을 만들어서 오픈소스로 배포하고 운영하고 있습니다.

  • REPL Works : 워크플로, 표준 문서와 표준 프롬프트 제공하는 공식 웹사이트
  • AI 이슈 퍼블리셔: Discussion AI와의 토론 내용을 Github Issues로 가장 빠르게 올리는 도구
  • REPL Documents: 표준 문서와 미리 준비된 TECH-SPEC 문서 그리고 표준 문서를 만들기 위한 프롬프트 제공

이들은 모두 개발 중인 혹은 온보딩이 된 서비스와 앱을 만들 때 사용되고 개선되고 있으며, 개선 내용은 이 곳에서 소개할 예정이며, REPL Works 홈페이지 Showcases에서도 게시되고 있습니다.

결론: 소프트웨어 완성까지의 가장 짧은 길

LLM의 개발 실력은 이미 정점을 찍은 느낌입니다. 이제부터 발전하는 것은 추론과 기존 코드를 이해하는 능력이며, 이들은 최근들어서 anthropic 회사의 Claude Code에서 보여준 것 처럼 새로운 고성능 LLM들이 발빠르게 온보딩 되고 있습니다.

반면, 토큰 비용도 과거와는 비교가 안될 정도로 가파르게 오르고 있는 것도 사실입니다. 추론을 더 잘 하기 위해서 필요한 컴퓨팅 자원이 코딩만을 위한 것보다 더 많은 리소스가 필요하다는 뜻입니다.

그렇지만, 일반 대중을 위한 ChatGPT나 Gemini 등 Discussion AI들은 무료임에도 불구하고 그 성능이 비약적으로 발전하고 있습니다.

Discussion AI는 싸고, Execution AI는 비싸다.

이런 환경에서 전 Discussion AI를 통해서 Long Context가 필요한 대화를 꾸준히 유지해서 최선의 문서를 얻어내고, 비용이 큰 Execution AI에게는 최소한의 문서와 프롬프트만을 제공하고, 상태관리를 위한 최소한의 문서 규격을 만드는 것이 현재로서는 가장 효율적인 방법이라고 생각합니다.

100만원의 토큰을 사용하여 어떤 것을 만들었습니다. 그것을 수정하기 위해서는 몇 배에서 몇 십배의 토큰이 필요하게 됩니다. LLM은 그 앞단계의 모든 문서와 코드를 읽고 이해해야 다음 작업을 올바르게 할 수 있기 때문입니다.

이런 환경과 문제를 해결하기 위해 만든 것이 REPL Works AI-Native Development Framework 입니다.

Comments