[paper] ChatDev - 소프트웨어 개발을 위한 통신 에이전트(Communicative Agents for Software Development)

ChatGPT가 공개되었을 때, 이러다가 채팅 가지고 자동화도 가능하겠는데? 하는 생각은 누구나 쉽게 할 수 있었을 것이다.

그리고 그 생각을 실제로 구현하다 못해 가상의 스타트업까지 만들어버린 칭화대의 "ChatDev"에 대해 공부해봤다.

 

 

ChatDev, Communicative Agents for Software Development

paper : https://arxiv.org/pdf/2307.07924.pdf

이 논문은 소프트웨어 개발의 모든 단계에서 대형 언어 모델(Large language models; LLMs)을 활용하는 방식을 제안했다.

이 방식의 핵심은 “ChatDev”라는 가상의 채팅 기반 소프트웨어 개발 회사로,

설계(designing), 코딩(coding), 테스트(testing), 문서화(documenting)의 4가지 단계로 구분된 워터폴 모델(waterfall model)을 따르는 회사이다.

 

각 단계는 프로그래머(programmers), 코드 리뷰어(code reviewers), 테스트 엔지니어(test engineers)와 같은 에이전트 팀(ChatGPT로 이루어진)이 참여하여 협업(collaborative) 대화를 통해 원활한 작업 흐름을 지원하게 된다.

 

 

ChatDev는 전체 소프트웨어 개발 프로세스를 7분 이내에 1달러 미만의 비용으로 완료하였으며,

잠재적인 취약점을 식별하고 완화할 뿐만 아니라, 잠재적인 환각(hallucinations)까지도 수정하면서 높은 효율성과 비용 효율성을 유지했다.

 

 

코드 환각(code hallucinations)

LLM을 사용하여 소프트웨어 시스템을 직접 생성할 때는 자연어 지식 쿼리(natural language knowledge querying)에서의 환각(hallucinations)*과 유사한 코드 환각(code hallucinations)이 발생할 수 있다.

*제시된 입력에 대해 항상 정확하거나 적절한 답변을 생성하지 못하는 상황

 

이러한 환상에는 기능의 불완전한 구현(incomplete implementation of functions), 누락된 의존성(missing dependencies) 및 발견되지 않은 버그(potential undiscovered bugs)가 포함된다.

 

해당 논문에서 이야기하는 코드 환각(code hallucinations)의 주요 원인은 두 가지이다.

1. one step으로 소프트웨어를 생성할 때, 작업이나 목표가 명확하게 정의되지 않은 경우
2. 결정 과정(decision-making)에서 교차 검증(cross-examination)의 부재

이러한 문제점을 해결하기 위해, ChatDev는 "chat chain"을 사용한다.

 

 

Chat Chain

"chat chain"은 효과적인 커뮤니케이션(communication)과 협력(collaboration)을 위해 사용되며, "chat chain" 내의 각 노드는 특정 서브테스크(subtask)를 나타낸다.

그리고 두 가지 역할이 존재하는데, 이들은 상황에 따라 의미를 파악하며, 여러 차례의 대화를 통해 솔루션을 제외하고 검증하게 된다.

 

이러한 접근 방식을 통해, 다음과 같은 작업을 진행할 수 있다.

• 클라이언트의 요구사항을 분석
• 아이디어 생성
• 프로토타입 시스템 설계 및 구현
• 잠재적인 문제 식별 및 해결
• 디버그 정보 설명
• 그래픽 생성
• 사용자 매뉴얼 제작

 

 

Designing

ChatDev에는 심지어 사전에 정의된 CEO (chief executive officer), CPO (chief product officer), CTO (chief technology officer)가 존재한다.

chat chain은 designing 단계를 세분화하게 된다.

1. Role specialization
2. Memory stream
3. Self-reflection

이 과정에는 target software의 형태 결정(CEO↔CPO), programming language 결정(CEO↔CTO) 등의 작업이 포함된다.

 

Role specialization

해당 단계에서의 System의 prompts/messages는 각 에이전트에게 역할을 할당하는 데 사용된다.

 

Memory stream

해당 단계에서는 에이전트가 이전 대화의 기록을 유지할 수 있게 해 준다.

이를 통해 에이전트는 이전 대화에서 논의된 사항을 기반으로 현재 상황에 대한 결정을 내릴 수 있게 된다.

 

Self-reflection

 

해당 단계는 미리 정의된 커뮤니케이션 프로토콜 상의 종료 조건이 발생하지 않았을 때, 대화의 내용을 재검토하고 요약하기 위한 방법으로 도입되었다. 

 

 

Coding

ChatDev의 Coding 단계에서는 CTO, programmer, art designer가 사전에 정의되어 있다.

chat chain은 designing 단계와 마찬가지로 coding 단계에서의 세분화를 진행한다.

이 과정에는 완벽한 code 생성(CTO↔programmer), 유저 인터페이스(GUI) 제작(art designer↔programmer) 등의 작업이 포함된다.

 

Code Management

 

ChatDev는 복잡한 software 시스템을 처리하기 위해 객체 지향 프로그래밍 언어를 사용한다. (특히, 모듈성 때문에 사용한다).

Git 관련 명령어를 통해 프로젝트를 관리하며, 버전 관리의 경우 Memory stream을 통해 해결한다. ("코드 환각"이 발생하는 이전 버전을 제거)

 

Thought Instruction

단순한 지시사항의 경우 환각(hallucinations)을 초래할 수 있기 때문에, "chain-of-thought prompting"*와 유사한 “thought instruction” 방법을 통해 이를 해결한다.

* chain-of-thought prompting : Google에서 대규모 언어 모델의 추론 능력을 향상하기 위해 제시한 prompting 방법론. 최종 답변에 이르는 중간 단계를 생성하도록 유도하는 기술

 

“thought instruction”란 문제 해결에 대한 구체적인 생각을 명시적으로 포함하는 것을 의미한다.

예를 들어 어떤 method의 구현 상태를 확인하기 위해, 역할을 바꿔서 확인해 보는 과정을 진행한다.

 

Testing

사람(human programmers)도 처음부터 오류가 없는 완벽한 code를 작성하는 것은 쉽지 않다.

사람이 오류를 해결하는 방식은 일반적으로 코드 실행 결과를 분석하고, 원인을 파악한 뒤 수정하는 것이다.

 

ChatDev도 마찬가지 과정을 진행한다.

testing 단계에서는 programmer, reviewer, tester 역할이 사전에 정의되어 있으며, peer review(programmer↔reviewer) 및 system testing(programmer↔tester) 등의 작업이 포함된다.

 

 

testing 단계에도 coding 단계에서 언급한 "thought instruction"를 사용한다.

interpreter의 feedback messages를 기반으로 두 에이전트가 소통함에도 버그가 없는 시스템을 구축하기 힘들다는 것을 연구 과정에서 발견하였고, 결국 환각(hallucinations)이 발생할 수 있다는 것을 알게 되었다.

이를 해결하기 위해 "thought instruction"를 도입하였고, 디버깅과 관련한 생각을 명시적으로 표현함으로써, programmer와 tester간의 소통이 명확해진다.

 

tester가 버그를 발견하면, programmer에게 지시를 내리고, programmer는 수정하고,

다시 tester가 software를 실행하여 버그를 분석하는 과정이 시스템이 성공적으로 실행될 때까지 계속 반복되게 된다.

 

이렇게 시스템이 성공적으로 실행되었다고, 완벽한 소프트웨어를 생성한 것은 아니다.

아시다시피, 인터프리터(interpreter)로 프로그램의 구문 오류나, 실행 오류는 감지할 수 있지만, 논리적 오류를 감지하기는 쉽지 않다.

소프트웨어 테스팅 과정에서 "사람"의 참여가 필요한 이유이다.

 

 

Documenting

designing, coding, testing 까지의 단계를 모두 거친 이후에, ChatDev는 documentation을 위해 4개의 에이전트(CEO, CPO, CTO, programmer)를 고용하게 된다.

document 생성을 위해 ChatDev는 "few-shot prompting"*을 사용한다.

* prompt engineering: Fine-tuning 없이 사전학습된 Language Model(LM)을 사용하는 방법론

* few-shot prompting: 본 질문을 하기 전 몇 가지 예시(일반적으로 2~5개) 제공하면서 LM이 새로운 예제에 빠르게 적용하도록 돕는 기술

 

CTO는 programmer에게 환경 설정(environmental dependencies)에 관한 문서 작성을 지시하고, "requirements.txt"와 같은 문서가 생성된다.

그리고 CEO는 시스템 디자인과 요구사항에 대해 CPO에게 전달하고, CPO는 이 정보를 바탕으로 사용자 매뉴얼(user manual)을 생성하게 된다.