연구 소프트웨어 프로젝트의 결정은 한곳에서 이뤄지지 않는다. Slack 대화에서 나온 아이디어가 회의에서 다듬어지고, GitHub 이슈와 풀리퀘스트에서 구현되는 동안 처음의 과학적 가정과 이유가 사라질 수 있다. 도메인 연구자와 소프트웨어 엔지니어가 서로 다른 프로젝트 상태와 책임 구도를 이해하면 코드가 요구사항을 충족해도 연구 의도와 어긋날 수 있다. Aleena는 이런 정렬을 한 번의 킥오프가 아니라 프로젝트 전 생애주기의 문제로 다룬다.
오픈소스 에이전트인 Aleena는 GitHub를 공동 협업 표면으로 사용한다. 회의, 비공식 대화, 코드 리뷰 등 여러 형태의 이해관계자 상호작용을 구조화된 프로젝트 기록으로 변환한다. 기록은 현재 위험을 드러내고, 답이 나지 않은 질문을 추적하며, 결정이 바뀌어 온 맥락을 보존한다. 에이전트가 사람 대신 결정을 내리는 것이 아니라 서로 다른 매체 사이에서 상태와 근거가 끊어지지 않도록 지원하는 역할이다.
논문은 대학 기반 연구 소프트웨어 엔지니어링 센터의 경험을 토대로 문제와 시스템 설계, 프로토타입, 생애주기 사례를 제시한다. 초록에는 생산 환경의 성과나 비교 실험 수치가 제시되지 않는다. 따라서 Aleena를 검증이 끝난 자동 프로젝트 관리자로 보기보다 협업 단절을 줄이기 위한 설계와 시제품으로 이해해야 한다. 특히 과학적 가정은 일반 개발 이슈보다 해석의 여지가 커 자동 요약에서 중요한 조건이 빠질 수 있다.
도입 시에는 원대화와 구조화 기록을 연결해 사람이 근거를 확인할 수 있어야 한다. 민감한 회의와 비공개 저장소 정보를 어디까지 수집하고 보존할지 권한 정책도 필요하다. 에이전트가 제기한 위험과 질문은 책임자를 보조하되 공식 결정으로 오인되지 않게 구분해야 한다. Aleena는 코드를 생성하는 AI 동료와 다른 방향에서, 연구 협업의 기억과 이해관계자 정렬을 유지하는 에이전트의 가능성을 보여준다. 구조화 기록의 수정 권한과 이견 표시 기능을 명확히 하면 자동 요약이 하나의 합의처럼 굳어지는 위험도 줄일 수 있다.
원문: arXiv 2607.08043
저작권자 © STORIUM 무단전재 및 재배포 금지
