PRD에서 코드까지 거꾸로 따라가 보는 일
PM이 코드를 '읽는' 게 아니라 시스템을 '이해'하는 도구가 됐다
PM이 코드를 본다는 표현은 늘 어딘가 어색하다. PM이 코드를 짠다는 얘기와 헷갈리기 쉽고, 개발자 영역을 침범하는 것처럼 들리기도 한다.
그래서 한 번 다시 풀어보자면, 이 글은 PM이 시스템을 이해하기 위한 도구로 코드베이스를 들여다본 작업기다. 코드를 쓴 적도 없고, 코드 리뷰를 한 적도 없다. 다만 “이게 실제로 어떻게 동작하나”를 동료 개발자에게 묻기 전에 1차로 확인한 적이 늘었다.
”이거 어떻게 동작해요?”의 질문의 비용
PM으로 일하면서 가장 자주 한 질문 중 하나가 “이 기능, 실제로 어떻게 동작해요?”였다. 정책서에 적힌 규칙과 실제 코드가 늘 일치하는 것은 아니어서, 회의 들어가기 전에 동료 개발자에게 한 번 물어봐야 했다. 답을 받는 데 짧으면 10분, 길면 다음 날까지. 개발자 입장에서는 그게 흐름을 끊는 질문이라는 걸 안다. 받는 사람도, 묻는 사람도 당연하게 했지만 사실 조금만 살펴보면 미안한 질문일 수 있다.
ChatGPT를 쓰던 시절에는 이런 점에 대해서 깊이 고민하지 않았다. 어짜피 PM이 코드를 들여다 볼 수도 없고, 코드를 본다고 알 수 있는 것도 아니기에, 기존에 위키에 작성해둔 정책서를 바탕으로 다시한번 체크하고, 더블체크는 개발자에게 요청했다.
하지만, Claude Code가 결정적으로 달랐던 건 이 지점이었다. 레포 전체를 같이 본 채로 질문할 수 있다는 점이 가장 큰 지점이었다. “이 기능의 영향받는 코드와 팀을 알려줘” “이 기능의 플로우를 차트로 그려줘”라고 하면, 도구가 코드를 뒤져서 흐름을 추적해준다. 내가 코드를 한 줄씩 읽는 게 아니라, 도구가 읽은 결과를 사람 언어로 정리해주는 작업이 된다.
코드베이스 영향 범위 역추적
가장 또렷이 기억나는 사례 하나가 있다. 정책 변경 회의 전에 “이 정책이 영향을 주는 화면이 몇 개나 되는지” 미리 알고 싶었다. 동료 개발자에게 물어보기엔 회의가 다음 날 오전이라 시간이 빠듯했다. Claude Code에 레포 정보와 함께 정책서를 공유하고, “코드베이스에서 이 정책 분기가 일어나는 곳을 다 찾아줘. 화면단위로 영향범위 알려줘”라고 시켰다.
결과는 화면 3개, 그 중 그 중에서 영향범위 4군데 정도 였다. 처음엔 못 믿어서 정책서를 바탕으로 다시한번 더블체크를 했다. 결론적으로는 Claude Code가 맞았다. 다음날 회의에 들어가서 유관부서와 이야기 나눠보니 서로 이견이 없어, 회의시간이 20분이나 일찍 끝났다.
나는 이게 PM이 코드를 들여다보는 일의 본질이 아닐까 싶다. 코드를 하나하나 알아야한다는 의미가 아니라 그래도 시스템 구성도를 바탕으로 시스템의 영향 범위를 빠르게 가늠하는 것. 사실 플랫폼 PM으로서 이런 역량은 필수적이라고 생각했다. 그렇기에 이런 도구가 있다면 도구를 바탕으로, PM은 그 결과를 의사결정에 더 빠르게 옮길 수 있다고 생각한다.
회의의 모양이 바뀌었다
이 패턴이 익숙해진 시점에, 회의에서의 태도가 미세하게 바뀐 게 느껴졌다. 이전에는 “이 정책 바꾸면 어디까지 영향이 가요?”가 회의 안에서 던지는 질문이었고, 회의 끝나고도 다시한번 영향범위를 확인해야했는데, 이제는 회의 들어가기 전에 1차 답을 들고 들어가는 게 가능해졌다. 회의의 절반쯤이 “확인”에서 “결정”으로 이동했던 것 같다.
이게 의외로 컸다. 회의의 모양이 바뀌니까, 회의에서 다뤄지는 질문의 결도 바뀌었다. “어디까지 영향 가는지”는 회의 전에 끝나고, 회의 안에서는 “그래서 그걸 어떻게 할 것인가”가 본론이 됐다.
한계, 그래서 위험한 부분
여기까지 적으니 다 좋은 얘기 같지만, 한계는 분명히 있다. 이 단락이 사실 이 글에서 가장 중요한 부분일지도 모른다.
첫 번째 위험은 도구가 보여주는 단순화된 뷰가 진짜 시스템보다 깨끗하다는 점이다. 실제 코드에는 도구가 놓치는 분기, 사이드 이펙트, 레거시 케이스가 있다. 한번은 도구가 정확한 답을 하지 않아 동료 개발자가 잡아줬다. 그날 이후로 영향 범위 추정은 무조건 동료 개발자에게 1차 검증을 받는다.
두 번째 위험은 PM이 “이해했다”고 착각하기 쉽다는 점이다. 도구가 사람 언어로 정리해주니까 “내가 시스템을 이해했다”는 감각이 들기 쉽다. 그런데 그건 도구가 만든 요약을 이해한 것이지, 시스템 자체를 이해한 것은 아니라고 생각한다. 회의에서 “코드를 봤다”고 말하는 순간 그 차이가 사라진다. 의사결정의 무게가 잘못 실린다.
이 두 가지 때문에, 이 작업의 결과는 항상 “내가 1차로 검색해 본 것”이라는 라벨을 붙여서 동료 개발자에게 공유한다. “확정된 분석”이 아니라 “PM이 본 1차 가설”이라는 위치 설정이 중요하다고 생각한다.
PM과 개발자의 이야기가 쉬워질수도 어려워 질 수도 있다
좋은 쪽은 PM이 1차 가설을 들고 회의에 들어오니까 회의의 깊이가 달라진다는 점이다. “이 정책 바꾸면 어디까지 영향 가요?”가 아니라 “제가 1차로 본 게 이건데, 다른 점이 있을까요?”로 시작이 된다. 개발자 입장에서도 답하기가 더 명확해진다.
어색해진 쪽은 PM이 코드를 본다는 사실 자체가 동료에게 어떤 감정을 줄지는 잘 모르겠다는 점이다. 위협받는 느낌일 수도 있고, 부담이 줄어드는 느낌일 수도 있다. 사람마다 다르고, 같은 사람이라도 상황마다 다르다고 본다.
내가 만든 skill 파일
정책서의 변경 영향 범위를 코드베이스에서 추정하는 것은 한 슬래시 커맨드로 작업되어있다.
~/.claude/commands/impact-range.md:
---
name: impact-range
description: 정책, 기능 변경의 영향 범위를 코드베이스에서 추정
---
1. 링크로 받은 변경 내용(마크다운 또는 한 줄 설명)을 읽는다.
2. 코드베이스 전체에서 다음을 찾는다. **이때 도메인 별로 레포가 그룹핑 되어있고, 유관부서의 레포도 참조되어있다
- 변경되는 정책, 로직이 분기되는 위치
- 그 분기를 호출하는 함수, 컴포넌트
- 사용자에게 직접 보이는 화면 (route, page, view)
3. 결과를 세 묶음으로 정리한다.
- 직접 영향 (사용자에게 보이는 화면)
- 간접 영향 (호출 체인의 백엔드 분기)
- 의심 영역 (확신은 없지만 영향 가능성)
규칙:
- 모든 결과는 "PM이 본 1차 가설"임을 결과 상단에 명시한다. 참고될 수 있도록 개발자의 시점으로도 명시한다.
- 확정 분석이 아님을 강조하고, 동료 개발자 1차 검증을 권장한다.
- 환각 의심 부분은 `[검증필요]` 태그를 달고 출처를 단다.
- 추정 신뢰도가 낮은 항목은 별도 섹션으로 뺀다.모두 결과에 “PM이 본 1차 가설”이라는 라벨을 반드시 박도록 했다. 이게 도구의 결과를 “확정”으로 잘못 읽지 않게 하는 안전장치였다.
이런 식으로 사용한 지가 좀 되니까, 처음엔 “코드를 보는 건 개발자의 영역”이라고 생각했던 게, 이제는 “코드를 빠르게 가늠해보는 건 PM도 할 수 있다”는 쪽으로 바뀌었다. 다만 그 변화가 모두에게 좋은 변화로만 작동하는 걸까의 의문도 있다. 이건 다음 내용에서 다뤄보려고한다. 어쨌거나 일을 할 때 확실히 빠르고 편리해졌고, 덕분에 시야도 넓어졌다.