Manager와 Processor 클래스가 리팩터링 대상이라는 신호

출처 및 AI 안내: 이 글은 제미니의 개발실무 유튜브를 기반으로 작성되었습니다. gpt-5.6-sol 모델을 사용해 생성·편집했습니다.

Processor라는 클래스를 열고 메서드부터 본다. 좋아요 등록과 삭제, 데이터 수정, 검색, 서로 관계없는 CRUD가 한곳에 있을 수 있다. 무엇이든 처리할 수 있는 이름이라 이 모든 일이 어색해 보이지 않는다. Manager와 Handler도 같은 문제를 가릴 수 있다.

모호한 클래스 하나의 메서드 이름부터 본다

Reader는 읽는다는 뜻이 보인다. 수정만 하는 클래스라면 그 행위를 이름에 담을 수 있다. Handler가 수정만 한다면 Modifier가 더 많은 정보를 준다. Processor 안에 하나의 일관된 행위가 보이면 그 행위로 이름을 바꾼다. 여러 행위가 섞였다면 접미사만 예쁘게 고칠 게 아니라 책임을 나눠야 한다.

그래서 모호한 이름 자체가 쓸모 있는 증거다. 아직 책임을 찾지 못했다는 사실을 완성된 설계인 것처럼 숨기지 않는다. 팀이 무엇을 소유해야 하는지 배우는 동안 그런 상태가 생길 수 있다. 문제는 임시 통이 모든 새 동작을 넣는 기본 위치가 될 때 시작된다.

저장소 전체에서 반복되는지 확인한다

모호한 클래스 하나는 통제된 중간 단계일 수 있다. 프로세서가 스무 개 있거나 모든 기능마다 매니저가 있다면 설계 습관을 의심해야 한다. 넓은 이름에는 새 CRUD와 검색 메서드를 계속 넣어도 어울려 보인다. 이 반복은 어색한 이름 하나가 아니라 여러 책임을 가진 클래스가 퍼졌다는 신호다.

같은 검색에서 과도한 레이어도 드러날 수 있다. 앞으로 비즈니스가 복잡해질 것을 예상해 작은 프로젝트에 네 개 레이어를 먼저 만들면, 아직 할 일이 없는 자리를 채우려고 프로세서와 핸들러가 생긴다. 소프트웨어가 단순한 동안은 레이어를 줄이거나 실제 조율이 필요한 곳에서만 선택적으로 쓸 수 있다.

단어를 금지할 필요는 없다. 검색 결과를 하나씩 열어 이름으로 메서드를 예상할 수 있는지, 클래스를 나눠야 하는지, 레이어 자체가 필요한지 묻는다. 의도적으로 드러낸 중간 클래스 몇 개는 관리할 수 있다. 저장소 전체에 퍼져 있다면 모호한 책임이 과도기를 넘어 습관이 된 것이다.