그러니까 전엔 개발자들이 이걸 하나하나 다 바꿨다고요?
npm 에러 하나가 하루를 통째로 삼키던 시절은 끝났다
요즘 나는 Jira를 쓰지 않는다.
대신, 내게 필요한 PM 도구를 도메인별로 직접 만들어 쓰기 시작했다.
우리 조직과 업무 흐름에 딱 맞는 기능만 담아서, 필요한 것만 빠르게 붙여 넣고, 원하는 기능을 바로 만들어 쓰는 방식이다.
어찌 보면 시간 낭비 같아 보이지만, 전혀 그렇지 않다.
1. 프로덕트 엔지니어로서 경험을 더 쌓을 수 있다.
2. 실제 필요에 의해 만들기 때문에 만드는 사람도 즐겁고 + 즉각적인 업무 효율화를 끌어낸다.
3. 놀랍게도 만들고 개선하는데 시간이 별로 걸리지 않는다... (!)
>>> 다른 프로젝트 할 때 AI가 작업하는 동안 뜨는 시간만으로도 충분히 구현 가능하다. ㅎㅎ
물론, 시중에 나와있는 툴은 좋고 편한 것은 누구나 알지만 내가 쓰는 기능 외의 추가 기능이 많을 때도 있고, 비용도 계속해 발생한다. 그렇다고 팀별로, 개인별로 툴을 다르게 도입하기보다는 하나의 툴을 함께 쓰는 게 조직엔 익숙한 일이다. 나 역시 내가 툴을 직접 만들어 쓴다는 것은 PM으로 일하던 시절에는 상상도 못 했던 일인데, 이제는 맞춤형 에디터도 고르고, DB 필드도 설계하고, 라우팅과 저장 로직도 직접(?) 만든다. 아니, AI에게 지시해서 만든다. ㅎㅎ
사건의 발단(?) - 에디터 기능 추가
Jira 대용으로 만들어 쓰는 PM 대시보드 안에 노션처럼 문서를 작성할 수 있는 페이지를 넣기로 했다. 작업명(Task)을 클릭하면 PRD, 문제정의, 해결방안, 개발 변화 내역 등을 바로 작성할 수 있는 문서 페이지가 필요해졌기 때문이다. 프로덕트를 담당하는 사람이 두 명뿐인데도 하루에 신규 기능 추가/수정/개선/버그 픽스가 동시에 너무 많이 일어나다 보니 이슈나 버그 외에 기록할만한 내용을 저장해 두고 꺼내보거나 공유할 수 있게 하고 싶었다.
기획자 입장에서는 단순한 기능처럼 보이지만, 막상 실제로 구현해 보면 꽤 큰 요소라는 것을 알게 된다. 그리고 이 과정에서 나는 AI가 없던 시절 개발자들이 어떤 문제를 해결하며 일해왔는지 비로소 이해하게 되었다.
무슨 일이 일어나고 있나요?
나: 에디터 입력이 안 되는데?
Claude Code: “BlockNote과 Tiptap 버전 충돌이 있네요. Novel 에디터로 전환하거나 이전 버전 시도해 볼게요”
이게 무슨 말인가 했더니 라이브러리 의존성 충돌(Dependency Conflict)이라고 했다. BlockNote과 Tiptap이라는 두 에디터 라이브러리가 각자 “나는 이 버전만 돼!”라고 요구하는데 그 요구사항이 서로 맞지 않아 프로젝트가 깨져버리는 상황.
쉽게 말하면 내가 레고로 성을 만들고 있는데
- BlockNote = "레고 2024 버전" 블록 세트
- Tiptap = "레고 2022 버전" 블록 세트라 2024년 버전 블록은 2022년 레고와 결합이 안 된다는 얘기다.
그래서 Claude Code는 자동으로 충돌을 분석한 뒤
Novel 에디터로 바꾸거나
Tiptap 버전을 낮추거나
이 두 가지 해결책을 제안한 것이다.
이 과정을 보면서 나도 모르게 AI에게 말했다.
그럼 원래는... 개발자들이 이걸 하나하나 다 찾아서 작업하다 수정하고 패키지 바꾸고 했던 거야?
AI가 말해준 개발자들의 고군분투
AI말로는, 버전 충돌은 프런트엔드 개발자들이 가장 많이 겪는 문제라고 한다. 이 문제를 해결하기 위해 전통적인 개발자라면 다음 과정을 거친다.
전통적으로는 개발자가:
버전 요구조건 정독
npm 트리 구조 분석
원인 파악
해결책 실험
코드 전부 테스트
를 하면서 몇 시간에서 며칠까지 쓰곤 했던 문제라고 한다.
근데 이제 Claude Code는:
의존성 트리 자동 분석
충돌 지점 파악
해결 방안 탐색
코드 마이그레이션까지 자동 수행
이걸 몇 초~몇 분 안에 해버린다.
** 클러드의 설명을 이미지로 조금 더 자세하게 붙여보면, 똑같은 문제를 해결하느라 얼마나 고생고생해야 했는지 알게 된다. 이 과정을 보고 나면 정말 '개발자들이 이걸 하나하나 다 찾아서 했다고?'라는 생각이 든다.
그런데… AI덕에 나는 이 모든 과정을 프롬프트 한 줄로 해결했다.
내가 한 건 딱 하나다.
“에러 나는데?”
그리고
"오키 수정해"
문제가 있다는 것만 알려줘도 코드와 관련된 부분은 Claude Code가 분석하고, 충돌 지점을 찾아, 버전 요구 조건을 비교한 뒤 해결 전략을 도출했다. 전통적인 개발자라면 하루 반나절을 썼을 문제를 AI는 몇 초 만에 구조적으로 해결한 것이다.
이전 작업 방식을 보고 나니 “코드 들여다보다 하루가 그냥 갔다…”라는 개발자의 말이 이해가 된다. 정말 에러 하나로 하루가 날아갈 수 있겠구나...! 하지만 앞으로는 개발자도, Product Engineer도 이런 곳에서 시간을 소모할 일은 없을 것 같다.
AI-first 개발이 가져온 변화
AI는 프로그래밍의 본질을 바꾸고 있다.
이전에는:
개발자는 문제를 찾고
원인을 읽고
구조를 해석하고
코드를 고치고
전체 일관성을 유지해야 했다.
이 모든 과정이 “개발자의 전문성”이었다.
하지만 지금은 대부분 AI가 대신한다.
그럼 사람에게 남는 일은 무엇일까?
서비스 방향을 정하고
문제를 정의하고
사용자 경험을 결정하고
제품 철학과 일관성을 설계하는 일
즉, 사람만이 할 수 있는 결정의 영역이다.
그런데… 여기서 중요한 사실 하나
AI가 방향성을 제안하고, 복잡한 설계 문서를 초안까지 뽑아주는 시대라고 해도 나는 백엔드 대규모 아키텍처 문서를 개발자처럼 한 번에 ‘독해’ 하지는 못한다. 그럼에도 최근에 꽤 대규모 백엔드 구조를 만드는 작업에서도 AI가 얼마나 강력한 ‘확장 장치’가 되는지 제대로 경험했다. 시작은 이랬다. 회의 말미에 대표님이 말했다. "아 그거.. 흠... AI한테 어떤 식으로 효율화할 수 있는지 한번 물어나 봐봐"
나는 다른 작업을 처리하다가 탭을 하나 더 켜서 Claude Code에게 말했다.
“~~~ 한 상황에서 우리가 효율적으로 코드를 구현할 수 있는 방향과 개발 과정에서 고려해야 할 중요 사항을 리스트업 해줘.”
몇 분 뒤, Claude Code는 1차 구조 문서를 뽑아냈다. 백엔드 아키텍처, 함수 설계, Firestore 트리거, 엣지 케이스, 위험 요소까지 정리된 문서였다. 나는 그 문서를 개발자 출신인 대표님께 공유했다. 대표님은 문서를 읽고 나서 말했다.
“와, 이거 원래 진짜 오래 걸리는 일이거든!”
그리고 나에게는 없는 개발자만의 판단으로 원하는 수정 방향을 알려주셨다. 그리고 우리는 함께 UX적으로는 어떤 원칙을 가지고 갈 것인지를 결정했다.
그리고 나는 다시 Claude Code에게 말했다.
{피드백}을 반영해서 문서를 수정해 줘. 그리고 상세 구현 방향도 정리해 줘
Claude code가 문서를 다시 작성하는 동안 나는 cmd+tab으로 또 다른 Claude code창을 열어 프런트엔드에서 필요한 수정 사항들을 작업했다.
몇 분 뒤 파란불이 들어온 탭을 다시 열어 HTML로 변환된 30페이지 가까운 개발 계획이 담긴 문서를 확인했다. 대표님은 그 문서를 보고 다시 이렇게 말했다.
“여기에 {~~~}라는 프롬프트 하나만 추가하면 그대로 진행하면 되겠다!”
오후 늦게, '시간 될 때 방안을 물어보기나 해 봐'라는 지시로 시작한 작업인데 퇴근 전 내가 '구현 완료하고 지금 배포 중이니, 내일 확인 한번 확인해 달라'라고 요청하니까 대표님이 말했다.
"헐! ㅇㅋㅇㅋ"
그렇게 복잡하다는 작업이 어려운 줄 모르고 끝나버렸다.
(물론 내가 하나하나 코드를 읽지 않고, 전적으로 맡겼기 때문에 어려울 게 없었던 것도 사실이다. 근데 개발자가 확인했을 때 아무런 문제가 없었다는 게 현시점 AI의 능력이다.)
사실 요즘 PM 업무에서도 AI 도움을 많이 받는다.
예전에는 알림(푸시) 서비스 하나를 개선할 때도 노션을 켜고서는 케이스별로 리스트업을 한 뒤, 알림 문구 텍스트를 고정과 {변경}될 부분을 나누어 적고, 랜딩 페이지는 어디로 되어야 하는지 알림 리스트에서는 어떻게 보여야 하는지 하나하나 수작업으로 적었다. 그리고 다른 팀원의 시간을 빌려 리뷰도 거쳤다.
요즘은....
클러드코드에게 초안을 만들라고 하고 보완하거나, 그냥 다짜고짜 알림 기능을 만들고 세부 케이스 리스트업 해달라고 한 뒤 빠진 케이스가 있는지 체크하고 빠진 거 추가하라고 말한다. 문서화가 필요할 땐 html로 정리해서 PRD, 세부 정책 사항 결정한 거 정리하라고 한다. 노션을 직접 붙들고 쓰고 고치고 할 필요가 없다.
AI가 PM의 문서와 개발자의 코드를 대신 써주는 동안, 무엇을 만들지, 왜 만들어야 하는지, 그리고 그것이 사용자와 비즈니스에 어떤 의미를 갖는지를 고민하고 UX 경험에 더 집중하게 되는 것 같다. 그리고 작업을 해보면 이러한 방향 결정과 판단, 설계는 아직 사람의 영역이다. 그래서 책임자도 사람이 된다.
이렇게 AI가 확장시켜 준 역량의 세계에서 Product Manager/Product Engineer는 더 많은 판단을 내리고, 더 깊은 문제를 정의하고, 더 넓은 제품을 설계하는 사람이 될 수 있다.
