새로운 기능 개발은 메시지 작성 화면에서 선택된 관심사에 따라 해당 메시지를 받을 구독자 수를 표시하는 것이었습니다. 초기 분석 결과, 페이지 로드 시에는 구독자 정보가 서버에 있기 때문에 동적인 업데이트가 필요하다는 점이 확인되었습니다.
인간 개발자 팀의 접근 방식
- 테스트 주도 개발 (TDD): 스펙(테스트 코드)을 먼저 작성하여 기능의 예상 동작을 정의하고, 이를 기반으로 개발을 진행했습니다.
- 기존 코드 재사용:
people_to_notify와 같이 이미 존재하는 메시지 객체의 구독자 계산 로직을 재사용하여 중복 개발을 피했습니다. - Hotwire (Turbo, Stimulus) 활용: Rails의 Turbo와 Stimulus를 적극적으로 활용하여 비동기 통신 및 UI 업데이트를 구현했습니다. 특히, 폼의
change이벤트를 감지하여 숨겨진 버튼을 클릭하고,new_message_path엔드포인트로 부분적인 폼 데이터를 GET 요청으로 전송하는 방식을 사용했습니다. 이는 Turbo Frame을 통해 특정 영역만 업데이트되도록 하여 페이지 전체 새로고침 없이 사용자 경험을 개선했습니다. - 에지 케이스 처리: 메시지 본문이 비어있을 때 발생하는
nil오류를 방지하기 위해mentions메서드에 가드 클로즈를 추가하는 등 견고성을 확보했습니다. 또한, 처음에는 관심사 구독자만 고려했으나, 멘션된 사용자도 알림 대상임을 인지하고 이를 자연스럽게 포함하는 방식으로 해결했습니다.
GitHub Copilot의 접근 방식
- API 엔드포인트 생성: Copilot은
interest_subscriber_count라는 새로운 API 엔드포인트를 생성하여 구독자 수를 계산하도록 했습니다. - Fetch API 사용: JavaScript의 Fetch API를 사용하여 비동기적으로 해당 엔드포인트에 요청을 보내고 응답을 처리했습니다.
- 새로운 Stimulus 컨트롤러:
interest_subscriber_count라는 별도의 Stimulus 컨트롤러를 도입하여 이 로직을 관리했습니다. - 한계점:
- CI 테스트 실패: Copilot이 생성한 코드는 CI 테스트를 통과하지 못했습니다.
- 기존 로직 미활용:
people_to_notify와 같은 기존의 구독자 계산 로직을 재사용하지 않고 새로운 계산 로직을 구현하여 코드 중복을 야기했습니다. - 멘션 기능 미반영: 메시지 본문 내 멘션을 통한 구독자 증가를 고려하지 않아 기능이 불완전했습니다.
- Hotwire 원칙 미준수: Turbo 프레임 내에서 HTML 프리미티브를 활용하는 대신, Fetch API를 사용하여 JavaScript 의존성을 높였습니다.
비교 결과
인간 개발자 팀은 기존 Rails 및 Hotwire의 강점을 활용하여 더 적은 코드로 더 견고하고 유지보수하기 쉬운 솔루션을 구현했습니다. 반면 Copilot은 전체 코드베이스의 맥락을 이해하려는 시도는 있었으나, 기존 코드의 재사용성이나 Rails의 관용적인 패턴을 충분히 활용하지 못했습니다. 특히, 복잡한 기능 개발에서는 Copilot이 생성한 솔루션이 CI를 통과하지 못하고 불완전한 부분이 많아 추가적인 수작업이 필요했습니다.