AI 3개, 사람 1명 — 시니어 개발자의 리팩토링 워크플로우

AI가 3개인데 사람은 1명

요즘 제 리팩토링 워크플로우는 이래요.

1. Jira/Confluence — 리팩토링 계획과 검증 체크리스트를 세운다
2. Claude Code — 계획에 따라 코드를 리팩토링한다
3. Claude Chrome — 실제 앱 화면을 보면서 체크리스트를 검증한다

AI 도구가 3개예요. 사람은 1명이에요. 그 1명이 하는 건 코드를 짜는 게 아니라 판단하는 거예요.

나중에 이 워크플로우를 영상으로 찍어서 올릴 예정이에요.

왜 계획이 먼저인가

AI한테 "이거 리팩토링 해줘"라고 하면 코드는 나와요. 근데 그게 맞는 리팩토링인지는 모르죠.

대시보드처럼 데이터도 많고 기능도 많은 프로젝트에서는 리팩토링 범위를 정하는 게 코드를 짜는 것보다 어려워요.

• 어떤 컴포넌트를 먼저 건드릴 것인가
• 의존성이 꼬인 부분은 어디인가
• 리팩토링 후에 깨지면 안 되는 기능은 뭔가

이걸 Jira 티켓으로 쪼개고, Confluence에 설계 문서로 정리해요. AI가 코드를 짜기 전에, 사람이 판단을 먼저 끝내는 거예요.

Confluence 설계 문서는 이렇게 생겼어요

실제로 제가 쓰는 Confluence 리팩토링 문서의 구조예요. 예를 들어 700줄짜리 대시보드 컴포넌트를 리팩토링한다면:

1. Current Structure — 지금 뭐가 문제인가

문제점을 명확히 적어요:

• 720줄 모놀리스 — 상태, 핸들러, 컬럼, 레이아웃, 컨트롤이 한 파일에
• 모바일/데스크톱이 비대칭 구조 (별도 컴포넌트 vs 인라인 JSX)
• 상태 관리가 다른 대시보드와 중복 패턴

2. Target Structure — 어떻게 바꿀 것인가

3. Detailed Design — 컴포넌트별 상세 설계

각 분리 대상에 대해 이렇게 정리해요:

Category	State / Handler	Notes
Search	searchKeyword, searchValue, handleChangeSearchValue	URL param sync
Pagination	page, setPage	Auto-resets on search/filter change
Sort	sortState, setSortState	{ id, desc } shape
Row selection	selectedRowId, handleSelectRow, handleClose	Toggle behavior
Filter	selectedFilters, handleFilterConfirm	Resets page on change

이 문서가 왜 중요하냐면 — Claude Code한테 "이 구조대로 리팩토링해줘"라고 하면, AI가 정확히 의도대로 움직여요. 문서 없이 "리팩토링해줘"라고 하면 AI 마음대로 쪼개요.

검증 체크리스트도 같이 만들어요

설계 문서와 체크리스트, 이 두 개가 세트예요. 설계 문서는 AI에게 "뭘 해라"를 알려주고, 체크리스트는 "제대로 했는지"를 확인하는 거예요.

이게 없으면 AI가 만든 코드를 "느낌"으로 검증해요. 느낌은 틀릴 수 있어요. 체크리스트는 안 틀려요.

Claude Code로 리팩토링하기

계획이 잡혔으면 Claude Code를 열어요.

여기서 중요한 건 프롬프트가 아니라 맥락이에요. 프로젝트 구조를 알고 있는 상태에서 "이 컴포넌트를 이 방향으로 리팩토링해줘"라고 하면, Claude Code가 파일을 읽고, 의존성을 파악하고, 코드를 바꿔요.

시니어가 유리한 지점이 여기예요.

• 주니어: "이 코드 리팩토링해줘" → AI가 나름대로 바꿈 → 맞는지 모름
• 시니어: "이 컴포넌트에서 API 호출을 커스텀 훅으로 분리하고, 에러 핸들링은 상위에서 하도록 바꿔줘" → AI가 정확히 바꿈 → 의도대로인지 확인 가능

지시의 구체성이 결과의 품질을 결정해요. 그리고 구체적으로 지시하려면 코드가 왜 이렇게 되어야 하는지 알아야 해요. 그게 경험이에요.

Claude Chrome으로 직접 눈으로 검증하기

리팩토링한 Claude Code에서 바로 "이거 맞아?" 물어볼 수도 있어요. 근데 저는 그렇게 안 해요.

만든 사람한테 검증을 맡기면 안 돼요. 같은 Claude라도 리팩토링 맥락이 가득한 상태에서 "이거 맞아?"라고 물으면, 자기가 만든 코드를 긍정적으로 볼 확률이 높아요. 코드 리뷰에서 작성자 ≠ 리뷰어인 것과 같은 원리예요.

그래서 저는 Claude Chrome 확장 프로그램을 써요.

Claude Chrome은 Claude Code와 완전히 달라요. 코드를 읽는 게 아니라 실제 브라우저 화면을 봐요. localhost:3000에 띄운 앱을 사용자 관점에서 직접 보면서 체크리스트를 검증해요. 코드 리뷰가 아니라 화면 리뷰예요.

Confluence에서 검증 체크리스트를 복사해서 Claude Chrome에 붙여넣으면, 이런 식으로 동작해요:

Claude Chrome이 이걸 받으면, 실제 화면을 캡처하면서 항목을 하나씩 확인해요. 그리고 마지막에 검증 결과 리포트를 줘요:

코드가 아니라 화면을 보고 검증한다는 게 핵심이에요. Claude Code는 코드를 읽어요. Claude Chrome은 사용자가 보는 것과 같은 화면을 봐요. 관점이 완전히 달라요.

이건 코드 리뷰랑 같은 원리예요. 작성자 ≠ 리뷰어. AI 도구에서도 이 원칙은 유효해요. 코드를 만든 AI와 화면을 검증하는 AI를 분리하는 거예요.

워크플로우 정리

핵심은 사람이 하는 일이 명확하다는 거예요.

• 1단계: 무엇을 리팩토링할지 판단
• 2단계: 어떻게 리팩토링할지 지시
• 3단계: 맞는지 확인
• 4단계: 다시 할지 결정

코드를 직접 짜는 시간은 줄었어요. 대신 판단하는 시간의 비중이 늘었어요. 그게 AI 시대 시니어의 일이에요.

이 방식이 좋은 이유

1. 재현 가능해요

체크리스트가 Confluence에 남아있으니까, 다음에 비슷한 리팩토링을 할 때 그대로 쓸 수 있어요. 내 머릿속에만 있던 검증 기준이 문서가 되는 거예요.

2. 인수인계가 쉬워요

"이 컴포넌트 리팩토링했는데, 이 체크리스트로 검증했어요"라고 하면 끝이에요. 코드 리뷰어도 체크리스트를 보면서 확인하면 되니까요.

3. AI가 바뀌어도 워크플로우는 유지돼요

내일 Claude 대신 다른 도구가 나와도, "계획 → 실행 → 검증" 구조는 안 바뀌어요. 도구는 끼워넣는 거고, 워크플로우가 본체예요.

정리

1. AI한테 시키기 전에 계획을 세워라 — 체크리스트 없이 리팩토링하면 "느낌"으로 검증하게 된다
2. 만든 도구와 검증 도구를 분리하라 — 작성자 ≠ 리뷰어 원칙은 AI에도 적용된다
3. 시니어의 일은 코드가 아니라 판단이다 — 무엇을, 어떻게, 맞는지, 다시 할지

AI가 코드를 짜주는 시대에, 코드를 잘 짜는 건 덜 중요해졌어요. 코드가 맞는지 판단하는 능력이 진짜 실력이에요.