현재 ‘Hub’ 앱에서는 메시지 작성 시 해당 메시지를 받을 구독자 수가 표시되지 않아, 사용자가 메시지 전송 전 알림 대상을 확인할 수 없습니다. ThoughtBot 개발팀은 이 문제를 해결하기 위해 RSpec을 이용한 테스트 주도 개발 방식을 채택하고, Hotwire(Turbo/Stimulus) 프레임워크를 활용하여 동적인 업데이트를 구현하고자 했습니다. 그들은 기존 people_to_notify 메서드를 재사용하여 멘션된 사용자까지 포함한 정확한 구독자 수를 계산하고, 전체 폼 재렌더링 대신 Turbo Frame을 통해 특정 부분만 업데이트하는 방식을 사용했습니다. 개발 과정에서 본문(body)이 비어 있을 때 발생하는 오류나 텍스트 입력 필드(Tricks)의 비활성화 문제 등 여러 난관에 부딪혔으나, 기존 코드와 Rails의 HTML 프리미티브를 최대한 재활용하여 해결책을 모색했습니다. 특히, change 이벤트와 로컬 스토리지에 저장되는 드래프트 기능 간의 충돌 가능성을 파악하며 디버깅하는 모습은 실제 개발 환경의 복잡성을 잘 보여줍니다.
동일한 기능 개발 작업을 할당받은 GitHub Copilot은 자체적으로 코드베이스를 분석한 후 솔루션을 제시했습니다. Copilot은 새로운 API 엔드포인트(interest_subscriber_count)를 만들고, Stimulus 컨트롤러에서 fetch API를 사용하여 구독자 수를 가져오는 방식을 선택했습니다. 초기 구현에서는 멘션된 사용자를 고려하지 않았고, 통합 테스트(integration spec) 대신 API 요청 테스트만 작성했으며, CI(Continuous Integration) 테스트가 실패하는 문제도 발생했습니다. 개발팀의 피드백(기존 messages/new 엔드포인트와 Turbo Frame 재사용)을 받은 후 Copilot은 HTML 부분 업데이트 방식으로 리팩토링했지만, 여전히 별도의 비-RESTful 엔드포인트와 fetch를 사용하는 등 개발팀이 의도한 Hotwire 기반의 Rails 친화적인 방식과는 차이가 있었습니다.
ThoughtBot 개발팀의 솔루션은 기존 Rails 컨벤션과 코드 재사용을 통해 더 견고하고 유지보수가 용이한 결과를 낳았습니다. 반면 Copilot의 솔루션은 기능 구현에는 성공했으나, 코드의 효율성, 재사용성, 테스트 커버리지 측면에서 한계를 보였습니다. 이는 Copilot이 코드베이스의 전체적인 맥락과 Rails/Hotwire의 철학을 완전히 이해하여 최적의 솔루션을 제시하는 데는 아직 부족함이 있음을 시사합니다. 특히 복잡한 기능 개발보다는 독립적인 버그 수정(flaky spec)에 더 강점을 보인다는 점이 강조되었습니다.