한 번에 세 가지 기능을 동시에 설계하다 보면 서로 얽히는 부분이 생긴다. 이번에는 대진표 관리 앱에 다음을 추가했다. FAB 피드백 버튼 — 우측 하단 플로팅 버튼 → Telegram 전송 역할 기반 대진표 수정 권한 — 대회 vs 친선 모드에 따라 일반 참가자에게 수정 권한 부여 여부 선택 Audit Log — 누가 언제 무엇을 바꿨는지 전/후 데이터와 함께 기록 각각은 단순해 보이지만, 셋을 한꺼번에 설계하다 보니 “어디서 권한을 체크하고, 어디서 로그를 남기고, 어디까지 UI에 노출하는가"에 대한 결정이 계속 붙었다. ...
운영 중인 Rails 8 API 서버를 점검하기로 했다. 기능은 대부분 동작하고 있었지만, 테스트 커버리지가 3%밖에 안 되는 상태. “동작하니까 괜찮겠지"라는 생각이 얼마나 위험한지 확인하는 과정이었다. 프로젝트가 어느 정도 성숙기에 접어들면 기능 개발보다 안정화가 더 중요해진다. 테스트가 없는 코드베이스에서는 리팩토링도, 의존성 업그레이드도, 팀원 온보딩도 전부 도박이 된다. 이번 점검은 단순히 테스트 커버리지 수치를 올리는 작업이 아니라, 현재 코드베이스의 실제 상태를 정직하게 들여다보는 과정이었다. 점검 전 상태 Rails 8 + PostgreSQL (UUID PK) + JWT 인증 + Pundit 권한 RSpec 테스트: 16개 (기본 scaffold 수준) 모델 20개+, 컨트롤러 15개+, 서비스 5개+ Dockerfile은 배포용으로 작성되어 있었고, CI는 없음 테스트 16개가 있다고는 하지만, 실제로는 scaffold 생성 시 자동으로 만들어진 기본 라우팅 테스트 수준이었다. 핵심 비즈니스 로직, 권한 체크, 서비스 레이어는 전혀 커버되지 않은 상태. 이 상태로 몇 달을 운영하면서 기능을 계속 추가해왔다는 게 솔직히 불안했다. ...