AI 모델 및 플랫폼

ChatDev : 소프트웨어 개발을 위한 커뮤니케이션 에이전트

mm
Unite.AI를 Google의 선호 소스에 추가
ChatDev : AI Assisted Software Development

소프트웨어 개발은 조언과 직관을 함께 활용하며 복잡한 의사결정이 필요한 분야입니다. 개발뿐 아니라 유지보수와 운영에도 체계적이고 규율 있는 접근이 요구됩니다. 개발자는 문제의 복잡성에 따라 협의보다 직관에 의존하기도 합니다. 연구자들은 소프트웨어의 효과를 높이고 개발 비용을 줄이기 위해 개발 과정의 여러 작업에 딥러닝을 적용하고 있습니다. 최근 AI와 딥러닝의 발전은 각 단계에 정교한 설계를 도입해 개발 관행을 바꾸려는 시도로 이어지고 있습니다.

ChatDev는 개발 단계마다 전문 모델을 따로 사용하는 필요를 줄이려는 대규모 언어 모델(LLM) 기반 접근입니다. 자연어 의사소통으로 핵심 개발 과정을 통합하고 간소화합니다.

소프트웨어 개발을 전문으로 하는 가상 회사인 ChatDev는 폭포수 모델을 채택해 과정을 설계, 코딩, 테스트, 문서화의 네 단계로 나눕니다. 각 단계에는 프로그래머와 테스터 같은 가상 에이전트가 배치되어 대화로 협력합니다. 채팅 체인은 각 단계를 더 작은 원자적 하위 작업으로 나누고 두 역할이 맥락을 고려해 해법을 제안하고 검증하도록 돕습니다.

ChatDev : AI Assisted Software Development

원문의 분석에 따르면 ChatDev는 개발 과정을 효율적으로 완료하며, 전체 과정의 비용은 1달러 미만이었습니다. 또한 잠재적 취약점을 찾아 완화하고 환각을 수정하면서 효율성과 비용 효율성을 유지했습니다.

ChatDev: LLM 기반 소프트웨어 개발 소개

전통적인 개발 과정은 개발, 유지보수, 운영 전반에서 체계적인 접근을 요구합니다. 조직 내 조정, 작업 배분, 코드 작성, 테스트, 문서화 등 여러 역할이 참여하므로 복잡하고 시간이 오래 걸리며 개발 주기도 깁니다.

최근 대규모 언어 모델(LLM)은 컴퓨터 비전과 자연어 처리에서 중요한 성과를 냈습니다. 다음 단어 예측 방식으로 훈련한 모델은 기계 번역, 질의응답, 코드 생성 등 다양한 후속 작업에서 성능을 보여주었습니다.

LLM은 소프트웨어 전체의 코드를 작성할 수 있지만 코드 환각이라는 약점이 있습니다. 발견되지 않은 버그, 누락된 의존성, 불완전한 함수 구현 등이 이에 해당합니다. 주요 원인은 두 가지입니다.

  • 작업 명세 부족: 코드를 한 번에 생성할 때 사용자 요구 분석이나 프로그래밍 언어 선택 같은 구체적 작업을 명시하지 않으면 모델이 혼란을 겪습니다. 이런 작업은 사고의 방향을 제시하지만 추상적인 상위 작업만 주어지면 그 안내가 사라집니다.
  • 교차 검증 부족: 특히 의사결정 과정에서 상호 검증이 없으면 상당한 위험이 생깁니다.

ChatDev는 가상 소프트웨어 회사를 구성하고 설계, 코딩, 테스트, 문서화를 구분해 이 문제를 해결합니다. 각 단계의 에이전트는 협력하며, 채팅 체인의 각 노드는 특정 하위 작업을 나타냅니다. 두 역할이 여러 차례 맥락을 반영한 대화를 나누며 해법을 제안하고 검증합니다.

시스템은 고객 요구를 분석하고 아이디어를 생성하며 프로토타입을 설계·구현합니다. 잠재적 문제를 찾아 해결하고 그래픽을 제작하며 디버깅 정보를 설명하고 사용자 설명서를 만듭니다. 최종적으로 소프트웨어, 소스 코드, 설명서, 의존성 환경 명세를 함께 제공합니다.

ChatDev: 아키텍처와 작동 방식

채팅 체인

폭포수 모델의 네 단계는 각기 다른 역할을 수행하므로 단계 간 효과적인 의사소통이 필요합니다. 누구와 대화하고 어떤 순서로 상호작용할지 결정하는 것도 문제입니다. ChatDev의 일반화된 채팅 체인 구조는 각 단계를 두 역할이 참여하는 작업 중심의 작은 대화로 나눕니다. 에이전트의 협력과 지시 교환으로 얻은 결과는 목표 소프트웨어의 핵심 구성요소가 됩니다.

각 대화에서 지시자는 먼저 지침을 제시하고 작업 완료를 향해 대화를 이끕니다. 보조자는 지침을 따르며 해법을 제시하고 실행 가능성을 논의합니다. 양측이 합의하고 작업이 완료되었다고 판단할 때까지 여러 차례 대화합니다. 사용자는 개발 과정과 의사결정 경로를 투명하게 살펴볼 수 있으며, 오류를 분석·진단하고 중간 결과를 확인하며 필요하면 개입할 수 있습니다. 이 방식은 하위 작업에 세밀하게 집중하도록 해 협력과 결과 도출을 촉진합니다.

설계

설계 단계는 사람인 고객의 초기 아이디어로 시작합니다. 미리 정의된 역할은 CEO(최고경영자), CPO(최고제품책임자), CTO(최고기술책임자)입니다. 채팅 체인은 프로그래밍 언어 선택(CTO와 CEO), 목표 소프트웨어의 형태 결정(CPO와 CEO) 같은 순차적 하위 대화로 나눕니다. 주요 메커니즘은 역할 할당, 메모리 스트림, 자기 성찰입니다.

역할 할당

특별한 메시지나 프롬프트로 대화 전에 각 에이전트의 역할을 지정합니다. ChatDev는 다른 대화형 언어 모델과 달리 에이전트 사이의 역할극 시나리오를 시작하는 데 초점을 맞춥니다. 처음에는 지시자가 CEO로서 계획에 참여하고, 작업을 수행해 응답하는 에이전트가 CPO를 맡습니다.

역할 전문화를 위한 inception prompting에는 지정된 역할과 작업, 종료 조건, 의사소통 규약과 제약이 담깁니다. 이는 무한 반복, 정보가 없는 응답, 중복 지시 같은 바람직하지 않은 행동을 방지합니다.

메모리 스트림

메모리 스트림은 이전 대화의 전체 기록을 유지해 이후 의사결정이 앞선 발화를 고려하도록 돕습니다. 프롬프트는 필요한 의사소통 규약을 정합니다. 예를 들어 합의에 도달하면 <MODALITY>: Desktop Application 같은 지정 형식의 종료 메시지를 내야 합니다. 시스템은 형식 준수 여부를 계속 확인한 뒤 대화가 끝나도록 합니다.

자기 성찰

양측이 합의했지만 지정된 의사소통 규약이 실행되지 않는 경우가 있었습니다. 이를 해결하기 위해 ChatDev는 자기 성찰 메커니즘을 도입합니다. 새로운 질문자인 ‘의사 자아(pseudo self)’를 참여시킨 별도 대화를 시작해 이전 대화와 기록을 분석하게 합니다. 이 정보가 현재 보조자에게 전달되고, 결론이자 실행할 수 있는 정보를 요약하도록 요청합니다.

이 메커니즘은 보조자가 자신이 제안한 결정을 다시 성찰하고 분석하도록 유도합니다.

코딩

코딩에는 CTO, 프로그래머, 아트 디자이너가 참여합니다. 채팅 체인은 코드 생성(프로그래머와 CTO), GUI 설계(프로그래머와 디자이너) 같은 작은 작업으로 나눕니다. CTO는 프로그래머에게 마크다운 형식으로 소프트웨어 시스템을 구현하도록 지시합니다. 디자이너는 전통적인 텍스트 명령 대신 그래픽 아이콘으로 상호작용하는 사용자 친화적인 GUI를 제안합니다.

코드 관리

복잡한 시스템에는 Python, Java, C++ 같은 객체지향 언어를 사용합니다. 모듈성과 독립적인 객체는 문제 해결과 공동 개발을 돕고, 상속을 통한 재사용으로 중복을 줄입니다.

사고 지침

단순한 지시만 제공하는 전통적 질의응답 방식은 특히 코드 생성에서 관련 없는 정보나 부정확한 결과, LLM 환각을 일으킬 수 있습니다. ChatDev는 사고 사슬 프롬프트에서 영감을 받은 ‘사고 지침’ 메커니즘을 도입합니다. 작업을 순차적이고 체계적으로 해결하듯, 지시 안에 개별 문제 해결 사고 단계를 명시합니다.

테스트

첫 시도에 오류 없는 코드를 쓰기는 LLM뿐 아니라 사람에게도 어렵습니다. 잘못된 코드를 버리기보다 분석해 오류를 수정합니다. ChatDev의 테스트에는 프로그래머, 테스터, 검토자가 참여하며 두 작업을 순서대로 수행합니다.

  • 동료 검토 또는 정적 디버깅: 검토자와 프로그래머가 소스 코드를 분석해 오류를 찾습니다.
  • 시스템 테스트 또는 동적 디버깅: 프로그래머와 테스터가 인터프리터로 여러 테스트를 실행해 작동을 검증합니다. 동적 디버깅은 주로 블랙박스 테스트에 초점을 맞춥니다.

문서화

설계, 코딩, 테스트 후에는 CEO, CTO, CPO, 프로그래머가 문서를 생성합니다. LLM에 문맥 내 예시를 포함한 few-shot 프롬프트를 제공합니다. CTO는 프로그래머에게 환경 의존성 구성 지침과 requirements.txt 같은 의존성 문서를 작성하도록 합니다. 동시에 CEO는 CPO에게 요구사항과 시스템 설계를 전달해 제품 사용자 설명서를 만들게 합니다.

결과

소프트웨어 통계

개발팀은 생성된 소프트웨어를 대상으로 사용 토큰, 총 대화 차례, 이미지 자산, 소프트웨어 파일, 버전 업데이트 등 주요 지표를 통계적으로 분석했습니다. 결과는 다음 표와 같습니다.

소요 시간 분석

다양한 요청 프롬프트에 대한 제작 시간을 분석했습니다. 개발 시간의 차이는 작업의 명확성과 복잡성이 서로 다르다는 점을 보여줍니다.

사례 연구

다음 그림은 ChatDev가 오목(Five in a Row 또는 Gomoku)을 개발하는 과정을 보여줍니다.

맨 왼쪽의 기본 소프트웨어는 GUI가 없어 명령 터미널로만 게임을 할 수 있고 상호작용도 제한적입니다. 다음 버전은 GUI를 적용해 시각적 매력, 사용 경험, 상호작용을 개선합니다. 디자이너는 기능을 바꾸지 않으면서 추가 그래픽으로 사용성과 미관을 높입니다.

사람인 사용자가 생성된 이미지에 만족하지 않으면 개발 완료 후 직접 교체할 수 있습니다. 이 유연성은 소프트웨어 기능에 영향을 주지 않고 취향에 맞게 앱을 꾸미고 사용 경험을 개선하도록 해줍니다.

마무리

ChatDev는 개발 단계별 전문 모델의 필요를 줄이려는 대규모 언어 모델(LLM) 기반 접근입니다. 자연어 소통으로 핵심 개발 과정을 통합하고 간소화하며, 채팅 체인으로 순차적인 작은 작업을 구성해 각 작업에 세밀하게 집중하고 필요한 결과를 얻도록 합니다.

Kunal Kejriwal은 Python, PostgreSQL, Redis 및 GCP와 AWS의 클라우드 인프라를 전문으로 하는 백엔드 엔지니어입니다. 3년간 실서비스 운영 시스템을 구축하고 확장한 경험을 바탕으로 AI 인프라, 분산 시스템, 그리고 머신러닝 워크로드 배포의 아키텍처에 대해 글을 씁니다.