웰컴페이 회원 탈퇴 시 관리자 식별자 조회 로직 보완
목차
fix: 웰컴페이 회원 탈퇴 로직 보완 (mgtId 조회 로직 추가)
이번 작업의 핵심은 기존 기능 안정화와 코드 일관성 확보였음. 변경 범위가 여러 레이어에 걸쳐있어서 영향 범위를 꼼꼼히 체크했음.
변경 영역
| 레이어 | 파일 수 | 주요 변경 |
|---|---|---|
| 백엔드 로직 | 1개 | 핵심 처리 로직 개선 |
| 화면 (JSP) | 0개 | UI/UX 개선 |
| 쿼리 (XML) | 0개 | SQL 최적화 |
| 스타일 | 0개 | CSS 정리 |
작업 포인트
- 중복 코드 제거 및 공통화
- 엣지 케이스 처리 보강
- 로그 및 에러 메시지 개선
- 불필요한 주석/코드 정리
코드 변경 원칙
운영 중인 서비스 변경 시 가장 중요한 건 기존 동작을 깨지 않는 것임. 변경 전후 동작을 직접 확인하고, 배포 후 모니터링을 잊지 말아야 함.
개발 원칙 정리
이 작업을 진행하면서 재확인한 원칙들:
작은 커밋: 변경 단위를 작게 유지해서 코드 리뷰와 롤백이 쉽게.
테스트 먼저: 변경 전 현재 동작을 파악하고, 변경 후 동일하게 동작하는지 확인.
문서 동기화: 코드가 바뀌면 관련 주석과 문서도 같이 업데이트.
| 원칙 | 이유 |
|---|---|
| 단일 책임 | 하나의 함수/클래스는 하나의 역할만 |
| 명시적 코드 | 영리한 코드보다 읽기 쉬운 코드 |
| 실패 우선 처리 | happy path보다 에러 케이스 먼저 설계 |
작업 회고
이런 작업들이 쌓이면서 시스템이 점점 견고해진다는 걸 느낌. 당장 티가 안 나는 작업이지만 나중에 디버깅 시간을 크게 줄여줌.
코드를 작성할 때 항상 생각하는 것들:
- 미래의 나: 6개월 후에 이 코드를 다시 봤을 때 이해할 수 있는가
- 다음 개발자: 나 말고 다른 사람이 이 코드를 보면 어떻게 느낄까
- 운영 상황: 새벽 3시에 장애가 났을 때 이 코드가 문제를 빨리 파악하게 해주는가
| 좋은 코드의 기준 | 나쁜 코드의 신호 |
|---|---|
| 읽으면 의도가 바로 보임 | 주석 없으면 이해 불가 |
| 변경이 한 곳에만 영향 | 한 곳 바꾸면 여러 곳 수정 필요 |
| 테스트 작성이 자연스러움 | 테스트하려면 구조 바꿔야 함 |
끝
댓글 0
첫 댓글 달아줘.