ZAP Core Team은 대규모 언어 모델(LLM)을 활용한 기여를 계속 받되, 제출자가 코드의 동작과 정확성을 책임져야 한다고 밝혔다. 코드 작성은 쉬워졌지만 검토에 드는 노력은 줄지 않은 만큼, 기여자는 변경 사항을 작게 나누고 테스트와 설명을 충분히 제공해야 한다.
ZAP은 첫 기여자든 경험 많은 기여자든, 코드를 직접 썼든 LLM의 도움을 받았든 기여를 제한하지 않는다. 다만 제출자는 변경 내용을 설명할 수 있어야 하며, 의도한 대로 작동하고 주요 예외 상황을 처리하며 다른 기능을 깨뜨리지 않는다고 판단할 수 있어야 한다. “LLM이 작성했다”는 설명으로 책임을 대신할 수는 없다. 이 기준은 ZAP Core Team에도 똑같이 적용된다.
기여자는 검토를 쉽게 하도록 변경 범위를 좁히고, 가능한 경우 단위 테스트와 종단 간 테스트를 포함해야 한다. 단위 테스트는 경계 조건과 실패 경로까지 다루는 것이 좋고, 테스트하기 어렵다고 판단한 부분은 PR 설명에 이유를 밝혀야 한다. 종단 간 테스트는 실제 ZAP에서 기능이 작동하는지 확인하며, 준비 작업이나 별도 환경이 거의 필요 없는 Automation Framework 계획을 권장한다. PR 설명에는 문제와 해결 방식, 테스트 방법, 미완성 부분이나 의도적으로 제외한 범위를 적어야 한다.
ZAP 팀은 사소하지 않은 변경을 사람에게 검토받기 전에 LLM으로 먼저 검토할 계획이다. 이는 사람의 검토를 대체하는 절차가 아니라, 누락된 경계 조건이나 부실한 오류 처리, 실효성 없는 테스트처럼 명백한 문제를 먼저 찾기 위한 것이다. 기여자에게도 코드를 작성하는 데 쓴 모델과 다른 LLM으로 제출 전에 검토해 보라고 권했다.
팀은 종단 간 테스트 작성을 쉽게 하도록 통합 테스트 구조도 바꾸고 있다. 현재 통합 테스트는 매일 실행되며, 다수는 ZAP 안에서 테스트용 웹 서비스를 제공하는 Dev add-on에 의존한다. 팀은 테스트 페이지를 더 쉽게 추가할 수 있도록 서비스를 확장 가능한 구조로 재편하고, 기능을 구현하는 애드온에 해당 테스트 페이지도 함께 둘 수 있게 할 계획이다.
ZAP의 운영 방식이나 커뮤니티 기여 원칙 자체가 바뀌는 것은 아니다. 다만 코드 작성보다 이해와 테스트, 검토에 더 많은 노력을 들이는 방식으로 전환한다. 변경이 준비됐는지 확신하기 어렵다면 PR을 열기 전에 ZAP Developer Group이나 관련 이슈에서 문의할 수 있다.
참고 자료: ZAP 블로그, ZAP Core Team, Automation Framework, 통합 테스트, Dev add-on, AI 생성 기여를 제한한 오픈소스 프로젝트 사례.
댓글 (0)
로그인하면 이 기사에 내 생각을 남길 수 있어요