AI 시대의 PM은 '무엇을 만들까'보다 '무엇을 만들지 않을까'를 정한다 — Claude Code 협업 1,301건의 기록

Claude Code를 전제로 프로덕트 매니저의 일을 다시 짜 봤다

올해 들어 Claude Code를 매일의 업무에 녹여 왔습니다.

돌아보면 가장 크게 바뀐 것은 일의 속도가 아니라, 일을 진행하는 방식 그 자체였습니다.

일일 업무 기록을 집계해 보니 Claude Code와의 협업 로그는 1,807건, 실제 안건과 기술 검증을 합쳐 73개 프로젝트에 이릅니다.

이 글에서는 AI 툴 소개가 아니라, Claude Code를 전제로 일하는 방식을 어떻게 재편해 왔는지를 써 보려 합니다.

1. 일상 업무 — 반복 작업을 "운영 가능한 구조"로 바꾼다

Claude Code와 특히 궁합이 좋은 것은 규칙이 명확하고, 반복해서 발생하며, 결과를 검증할 수 있는 업무입니다.

번역이나 문서 작성, 백업, 환경 정비처럼 하나하나는 작은 작업이지만, 쌓이면 많은 시간을 잡아먹습니다.

이런 업무는 매번 지시를 내리기보다 한 번 워크플로로 구조화하는 쪽이 효과가 크다고 느끼고 있습니다.

실제로 스크립트로 만들어 온 것은 예를 들어 다음 같은 처리입니다.

• 원본 Excel의 서식, 병합 셀, 열 너비를 유지한 양방향 번역
• 용어 통일과 누락 번역 확인
• 브랜드 디자인에 맞춘 문서 생성
• 일일 업무 회고
• 파일 동기화와 클라우드 백업
• 개발 환경 클린업
• 각종 툴 업데이트

목표는 Claude Code에 매일 같은 지시를 내리는 것이 아닙니다. 한 번 만든 구조가 필요할 때 안정적으로 계속 도는 상태입니다.

2. 프로덕트 매니지먼트 — "무엇을 만들까"를 정하는 일에 더 많은 시간을 쓴다

최근 몇 달은 경쟁 조사와 시장 조사, 요구사항 간 차이 비교, 스코프 정리, 단계 설계, PRD 작성, 고충실도(하이파이) 프로토타입 제작 등을 Claude Code와 병행하며 진행해 왔습니다.

프로토타입을 PRD로 옮기고, 테스트 시나리오와 경계 조건, 인수 기준까지 정리하기도 합니다.

예전이라면 며칠 걸리던 작업도 이제는 짧은 시간에 초안까지 만들어집니다.

다만 계속 쓰면서 새삼 실감한 것이 있습니다.

시간이 걸리는 것은 PRD를 쓰는 일이 아닙니다.

정말 시간을 써야 하는 것은,

• 무엇을 해결할 것인가
• 이번 릴리스에서 어디까지 만들 것인가
• 왜 이번에는 만들지 않을 것인가

라는 의사결정입니다.

Claude Code를 쓰면 상상 이상으로 많은 선택지가 나옵니다.

"이 기능도 추가할 수 있을 것 같은데" "이쪽 UI 안도 나쁘지 않네"

그런 제안이 잇달아 나오기 때문에, 정신 차려 보면 스코프가 넓어져 있을 때가 있습니다.

그래서 요즘은 "무엇을 만들까" 이상으로 **"무엇을 만들지 않을까"**를 의식하게 되었습니다.

13개 설계 항목에서 Must Have를 4개까지 좁혔다

어느 관리 시스템에는 13개의 기능 블록이 있었습니다.

핵심 업무 흐름뿐 아니라, UX 개선용 기능과 운영 규칙이 굳지 않은 상태 표시까지 포함되어 있었죠.

전부를 개발 대상으로 삼으면 스코프는 상상 이상으로 불어나고, 품질과 일정 관리도 어려워집니다.

먼저 Claude Code에 맡긴 것은 정보 정리입니다.

디자인, 기존 코드, 과거 요구사항을 한데 놓고 비교하면서,

• 어디에 차이가 있는지
• 사양에 모순은 없는지
• 무엇을 확인해야 하는지

를 정리했습니다.

여기까지는 사람이 전부 다시 읽는 것보다 훨씬 빠르게 진행됩니다.

그 위에서 정말 필요한 기능인지, 사용자에게 가치가 있는지, 다른 기능과의 의존 관계는 어떤지, 이번 릴리스에 넣어야 하는지를 하나씩 판단했습니다.

최종적으로 Phase 1에 넣은 것은 4개 항목뿐입니다.

환불 사유, 리마인드 기능, 축하 애니메이션처럼 "있으면 편하지만 주요 업무 흐름에는 영향이 없는 기능"은 후속 단계로 돌리고, 보류한 이유도 남겼습니다.

이때 가치가 있었던 것은 Claude Code가 PRD를 써 준 일이 아닙니다.

정보가 정리된 상태에서 가치, 의존 관계, 리스크, 릴리스 계획을 견주어 가며 스코프를 정할 수 있었다는 점입니다.

정보 정리와 의사결정은 별개의 일입니다.

3. 프로젝트 매니지먼트 — 논점을 정리해 의사결정을 앞으로 밀고 나간다

프로젝트 매니지먼트에서도 Claude Code를 활용하는 장면이 늘고 있습니다. 목적은 리포트를 만드는 것이 아닙니다.

프로젝트 상태를 정확히 파악하고, "다음에 무엇을 진행해야 하는가"가 보이는 상태를 만드는 것입니다.

최근 몇 달은 예를 들어 다음 같은 업무에 활용해 왔습니다.

• 계획 투입 시간과 실제 투입 시간 비교
• 14개 프로젝트 상황을 한눈에 모으는 취합
• "진행 중", "수렴 단계", "정체", "신규 시작" 같은 상태 분류
• 리소스 부하 분석
• R0~R3 등급의 리스크 관리
• 이어지는 블로커 추적
• 견적 자료·리뷰 자료 작성
• 인수 체크리스트 작성
• Go/No-Go 판정 조건 정리
• 리스크 발굴

정보를 모으고, 비교하고, 정리하는 작업은 예전보다 훨씬 빨리 끝납니다.

그만큼 "프로젝트를 어떻게 앞으로 밀고 나갈까"라는 의사결정에 더 많은 시간이 갑니다.

27건의 미확정 사항을 3개의 시작 조건까지 정리했다

어느 시스템 안건에서 견적 단계에 들어갔을 때, 요구사항 자료에는 27건의 미확정 사항이 남아 있었습니다.

내용은 외부 인터페이스 연동, 법무 검토, 보안 요건, 다른 팀과의 역할 분담 등 여러 갈래에 걸쳐 있었습니다.

이대로 견적을 진행하면 전제 조건이 애매한 채로 투입 시간을 산출하게 됩니다.

한편 27개 항목을 그대로 고객사에 넘겨도 "무엇부터 정하면 되는지"가 보이지 않아 이야기가 앞으로 나아가지 않습니다.

그래서 가장 먼저 한 것은 논점 정리입니다.

Claude Code에 요구사항 자료 전체를 훑어 확인하게 해서,

• 사양의 모순
• 부족한 정보
• 확인이 필요한 항목

을 일람으로 만들었습니다.

그 위에서 이번 목표, 견적, 스코프에 미치는 영향과 프로젝트 시작 전에 정해야 하는지를 기준으로 우선순위를 매겼습니다.

그 결과 고객사에 부탁한 것은 딱 3가지입니다.

"이 3가지만 정해지면 프로젝트를 시작할 수 있습니다."

논점을 좁혀 상의한 덕분에 의사결정은 단숨에 진행됐습니다.

외부 인터페이스 사양 확정 대기 같은 것은 개발 작업량과 분리해 리스크로 따로 관리하고 있습니다.

그 결과 견적과 리뷰에 필요한 정보도 9개 카테고리로 정리되어, 관계자 전원이 같은 전제로 논의하게 되었습니다.

이 경험을 거치며 느낀 것은, "과제를 찾는 일"과 "과제를 해결하는 일"은 별개의 일이라는 점입니다.

Claude Code는 정보를 정리하고 모순과 논점을 찾아내는 데 강합니다.

한편 고객사의 의사결정을 지원하고, 관계자의 인식을 맞추고, 멈춰 있는 과제를 앞으로 밀고 나가는 것은 사람이 맡는 역할입니다.

4. Claude Code를 쓰게 된 뒤에도 끝까지 직접 판단하는 것

Claude Code를 업무 흐름에 녹인 뒤로 "맡길 수 있는 일"과 "끝까지 직접 판단하는 일"이 전보다 뚜렷해졌습니다.

요구사항 정의서와 설계서, 회의록, 사양 변경 이력 등은 먼저 Claude Code에 정리시킵니다.

PRD와 프로토타입, 테스트 케이스도 초안을 만든 뒤 리뷰하는 진행 방식이 자리 잡았습니다. 번역과 로그 분석, 정형 업무도 구조화할 수 있는 것은 자동화하고 있습니다.

한편 과제에 매달릴 가치, 우선순위, 스코프, 사용자 가치 같은 의사결정은 지금도 제가 맡고 있습니다.

Claude Code가 만든 PRD와 코드, 테스트 케이스를 그대로 채택한 적은 없습니다.

업무 요건을 충족하는지, 현장에서 굴러가는지, 이번 릴리스에 넣어야 하는지를 마지막에는 반드시 팀에서 확인합니다.

예전보다 "만드는 시간"은 짧아졌지만, "리뷰"와 "의사결정"에 쓰는 시간은 늘었습니다.

지금의 저에게 Claude Code는 판단을 대신해 주는 존재가 아니라, 판단에 필요한 정보를 정리해 주는 파트너입니다.

5. 의식하는 것 — "만들기"만으로 끝내지 않는다

자료 작성과 과제 정리, 리스크 발굴은 예전보다 빨라졌습니다. 하지만 실무에서는 그 뒤가 더 중요합니다.

누가 대응하는가. 언제까지 끝내는가. 외부 의존은 있는가. 정말 해결했다고 말할 수 있는가.

그래서 하나하나의 과제에 담당자, 기한, 외부 의존, 상태, 검증 근거를 연결해 "대응했다"가 아니라 "해결했다"고 말할 수 있는 상태까지 따라가도록 하고 있습니다.

또 하나 의식하는 것이 의사결정의 경위를 남기는 일입니다.

"왜 이 안을 골랐는가" "왜 이번에는 보류했는가"

판단 이유가 남아 있으면 몇 달 뒤 같은 논의가 벌어져도 당시의 전제를 공유한 위에서 논의를 시작할 수 있습니다.

Jira와 Confluence 동기화도 앞으로 더 다듬고 싶은 부분입니다.

Claude Code로 정리한 내용과 정식 관리 툴의 상태가 일치해야 비로소, Claude Code는 단순한 산출물 생성 툴이 아니라 업무 흐름의 일부가 된다고 생각합니다.

6. 시간을 쓰는 방식이 바뀌었다

돌아보면 가장 크게 바뀐 것은 일의 속도가 아니라 시간을 쓰는 방식이었습니다.

자료 작성과 조사는 짧은 시간에 끝나고, 그만큼 의사결정과 우선순위 정하기, 관계자와의 합의 형성에 시간이 돌아갑니다.

이미지로 말하면,

• 이전: 정보 정리 7, 의사결정 3
• 현재: 정보 정리 4, 의사결정 6

정도까지 시간 배분이 바뀌었습니다.

AI는 앞으로도 진화하고, 해내는 일은 늘어날 겁니다.

그래도 "무엇에 매달릴까", "무엇을 우선할까", "누구와 합의하고 그 결과에 책임을 질까"는 사람이 맡는 일입니다.

Claude Code를 쓰게 되면서 제 일이 줄었다고는 느끼지 않습니다.

오히려 본래 프로덕트 매니저로서 시간을 써야 할 일로 돌아왔다는 감각이 있습니다.

여러분은 Claude Code를 업무에 들인 뒤, 일하는 방식에 어떤 변화가 있었나요?

덧붙여

이 글은 일일 업무 기록과 프로젝트 자료, 자동화 실천 기록을 바탕으로 정리한 것입니다.

내용은 실제 안건 경험에 기반하지만, 고객명, 프로젝트명, 코드 식별자, 견적 내용 등 기밀에 관련된 내용은 전부 익명화·마스킹한 뒤 실었습니다.

---