AI가 3개인데 사람은 1명

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

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

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

왜 계획이 먼저인가

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

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

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

체크리스트 예시:

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

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

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

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

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

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

리팩토링한 Claude Code에서 바로 "이거 맞아?" 물어볼 수도 있어요. 근데 저는 일부러 다른 창에서 검증해요.

이유는 간단해요. 만든 사람한테 검증을 맡기면 안 돼요.

같은 Claude라도 맥락이 다르면 다른 관점에서 봐요. 리팩토링 맥락이 가득한 Claude Code한테 "이거 맞아?"라고 물으면, 자기가 만든 코드를 긍정적으로 볼 확률이 높아요.

브라우저에서 새로 열고, Confluence의 검증 체크리스트를 붙여넣고, 리팩토링된 코드를 보여주면 — 선입견 없이 체크리스트 기준으로만 판단해요.

이건 코드 리뷰랑 같은 원리예요. 작성자 ≠ 리뷰어. AI 도구에서도 이 원칙은 유효해요.

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

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

1. 재현 가능해요

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

2. 인수인계가 쉬워요

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

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

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

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