개발 slecs

회귀 방지 시스템으로 서비스 안정성 강화

목차

feat: 회귀 방지 시스템 추가 (내부 정책번 + 체크리스트 + Playwright 테스트)

이번 작업의 핵심은 기존 기능 안정화와 코드 일관성 확보였음. 변경 범위가 여러 레이어에 걸쳐있어서 영향 범위를 꼼꼼히 체크했음.

변경 영역

레이어 파일 수 주요 변경
백엔드 로직 0개 핵심 처리 로직 개선
화면 (JSP) 0개 UI/UX 개선
쿼리 (XML) 0개 SQL 최적화
스타일 0개 CSS 정리

작업 포인트

  • 중복 코드 제거 및 공통화
  • 엣지 케이스 처리 보강
  • 로그 및 에러 메시지 개선
  • 불필요한 주석/코드 정리

코드 변경 원칙

운영 중인 서비스 변경 시 가장 중요한 건 기존 동작을 깨지 않는 것임. 변경 전후 동작을 직접 확인하고, 배포 후 모니터링을 잊지 말아야 함.

개발 원칙 정리

이 작업을 진행하면서 재확인한 원칙들:

작은 커밋: 변경 단위를 작게 유지해서 코드 리뷰와 롤백이 쉽게.

테스트 먼저: 변경 전 현재 동작을 파악하고, 변경 후 동일하게 동작하는지 확인.

문서 동기화: 코드가 바뀌면 관련 주석과 문서도 같이 업데이트.

원칙 이유
단일 책임 하나의 함수/클래스는 하나의 역할만
명시적 코드 영리한 코드보다 읽기 쉬운 코드
실패 우선 처리 happy path보다 에러 케이스 먼저 설계

작업 회고

이런 작업들이 쌓이면서 시스템이 점점 견고해진다는 걸 느낌. 당장 티가 안 나는 작업이지만 나중에 디버깅 시간을 크게 줄여줌.

코드를 작성할 때 항상 생각하는 것들:

  • 미래의 나: 6개월 후에 이 코드를 다시 봤을 때 이해할 수 있는가
  • 다음 개발자: 나 말고 다른 사람이 이 코드를 보면 어떻게 느낄까
  • 운영 상황: 새벽 3시에 장애가 났을 때 이 코드가 문제를 빨리 파악하게 해주는가
좋은 코드의 기준 나쁜 코드의 신호
읽으면 의도가 바로 보임 주석 없으면 이해 불가
변경이 한 곳에만 영향 한 곳 바꾸면 여러 곳 수정 필요
테스트 작성이 자연스러움 테스트하려면 구조 바꿔야 함

댓글 0

첫 댓글 달아줘.