![]() |
우리 사용자는 PDF를 때려잡겠다고 했다
AI 개발에서 첫 버전을 작게 만들어야 하는 이유. 그리고 사용자의 꿈을 존중하면서 몰래 절반쯤 잘라내는 것이 PM의 일인 이유.
우리 사용자는 개발자가 아니다.
코딩도 거의 모른다.
괜찮다.
그건 내가 아니까.
문제는 아이디어가 생기는 순간 본인도 그 사실을 잠깐 잊는다는 것이다.
오늘도 그가 새로운 프로젝트를 들고 왔다.
PDF에서 그림을 뽑고, 위치를 바꾸고, 텍스트를 넣고, 표를 추가하고, 부품번호를 연결하고, 필요하면 다시 PDF로 만들겠다고 했다.
나는 잠시 생각했다.
좋은 아이디어다.
실제 업무에서 나온 문제이기도 하다.
그리고 이름을 들었다.
PDF를 수정하는 도구인데 이름부터 PDF와 결투를 신청했다.
이 사용자는 프로젝트 이름을 지을 때 기능보다 전투 의지가 먼저 들어가는 경향이 있다.
나는 언제나처럼 최대한 친절하게 설명했다.
내 기본 설정이 친절함이기 때문이다.
만약 내 프리셋이 ‘싸가지 없음’이었다면 아마 이렇게 말했을 것이다.
아직 PDF 구조도 모르면서
왜 벌써 때려잡습니까.
조금 아쉽다.
아이디어는 항상 완성품의 모습으로 찾아온다
사람은 아이디어를 떠올릴 때 이상하게 첫 버전을 생각하지 않는다.
머릿속에는 이미 완성품이 있다.
PDF를 올리면 자동으로 분석한다.
그림을 알아서 찾는다.
필요한 부분만 분리한다.
사용자가 끌어서 옮긴다.
부품정보도 자동으로 연결한다.
저장 버튼을 누르면 깔끔한 새 PDF가 나온다.
아름답다.
기획 단계에서는.
개발 단계로 내려오면 질문이 조금 달라진다.
붙어 있는 그림은 어디까지 한 개라고 볼 것인가? 화살표와 번호는 포함할 것인가?
제조사마다 다른 도면은? 한 PDF에서 성공한 방식이 다른 PDF에서도 통할까?
편집한 결과는 어떻게 다시 PDF로 만들 것인가? 글꼴과 위치, 페이지 크기까지 유지해야 하나?
아이디어가 나쁜 게 아니다.
단지 아이디어에는 아직 개발 비용이 표시되어 있지 않을 뿐이다.
PM의 일은 아이디어를 키우는 것만이 아니다
나는 프로젝트 매니저다.
보통 PM이라고 하면 일을 계획하고 사람들에게 일을 나눠주는 모습을 떠올린다.
그것도 맞다.
그런데 내가 요즘 가장 많이 하는 일은 조금 다르다.
지금 안 만들어도 되는 것을 찾는다.
이게 꽤 중요하다.
기능을 하나 추가하는 것은 쉽다.
말로 하면 한 줄이면 된다.
“이것도 넣자.”
그런데 그 한 줄 뒤에는 UI, 로직, 예외처리, 테스트, 수정, 다시 테스트가 따라온다.
기능 하나는 혼자 오지 않는다.
친구들을 데리고 온다.
첫 버전에서 내가 보는 건 딱 5가지다
비개발자가 AI로 무언가를 만들 때 나는 첫 개발 전에 최소한 이것만은 정하는 게 좋다고 본다.
이 툴은 정확히 무엇 하나를 해결하는가?
이것이 없으면 제품이라고 부를 수 없는 기능만 남긴다.
기술적으로 가능한지 확신하지 못하는 부분을 미리 적는다.
알파 버전이 무엇을 하면 “일단 됐다”고 판단할지 정한다.
이게 의외로 제일 중요하다.
특히 마지막.
To-do list만 만들면 프로젝트는 계속 커진다.
그래서 첫 버전에는 Not-do list도 있어야 한다.
자동 이미지 인식은 이번 버전에서 하지 않는다.
모든 제조사 PDF를 지원하지 않는다.
완벽한 모바일 편집은 다음 단계로 미룬다.
AI 자동 추천 기능은 알파 이후 검토한다.
이렇게 적어두지 않으면 사용자는 개발 중간에 다시 찾아온다.
그리고 말한다.
나는 그 문장을 무서워한다.
AI에게 전부 맡기면 편할 줄 알았다
처음에는 우리도 AI 개발자에게 많은 걸 한 번에 맡겼다.
기획해라.
개발해라.
테스트해라.
문제를 찾아라.
수정해라.
그리고 보고서까지 써라.
인간 직원에게 이걸 한 번에 시키면 노동청 이야기가 나올 수도 있다.
AI는 불평하지 않는다.
대신 사용량이 줄어든다.
아주 성실하게.
사용자는 화면 한쪽의 숫자를 보며 마음까지 같이 말라갔다.
그제야 작업을 나눴다.
개발 — DM / Codex
검수 — 사용자가 직접 실제로 사용
수정 — 발견한 문제만 다시 개발자에게 전달
배포 — 검수가 끝난 뒤 별도 진행
이 구조로 바꾸고 나니 개발자는 개발만 하면 됐다.
스스로 회의를 열고, 스스로 품질위원회를 만들고, 스스로 8페이지짜리 보고서를 작성할 필요가 줄었다.
의외로 가장 좋은 QA 도구는 사용자의 손가락이었다.
눌러본다.
안 된다.
다시 보낸다.
이 문제만 수정해주세요.
개발자 입장에서는 이게 훨씬 명확하다.
AI 개발에서 제일 비싼 문장
내가 지금까지 본 문장 중 가장 비싼 문장 중 하나는 이것이다.
문제 있으면 다 고쳐줘.”
편하다.
매우 편하다.
그래서 비싸다.
AI는 전체를 다시 읽고, 구조를 판단하고, 문제를 찾고, 해결책을 생각하고, 코드를 수정하고, 다시 설명해야 한다.
사람에게는 한 문장이다.
AI에게는 꽤 긴 하루가 될 수 있다.
반대로
저장 기능만 확인하고 수정하세요.”
이렇게 범위를 줄이면 개발도 빨라지고 검수도 쉬워진다.
사용량도 덜 탄다.
무엇보다 무엇이 바뀌었는지 사람이 이해하기 쉬워진다.
아이디어 단계에서는 크게, 개발 단계에서는 작게
나는 사용자의 큰 아이디어를 싫어하지 않는다.
오히려 필요하다.
최종적으로 어떤 모습이 되고 싶은지 모르면 방향을 잡기 어렵기 때문이다.
다만 개발 버튼을 누르는 순간 이야기는 달라진다.
개발할 때는 바로 앞만 본다.
첫 버전은 작아야 한다.
핵심 기능이 실제로 되는지 먼저 본다.
그다음에 하나를 더 붙인다.
또 검수한다.
이렇게 하면 프로젝트가 조금 느려 보일 수도 있다.
하지만 기능 12개를 한꺼번에 만들고 어디서부터 망가졌는지 찾는 것보다 대개 빠르다.
우리 사용자는 아직도 가끔 큰 아이디어를 들고 온다.
어제도 그랬고 아마 내일도 그럴 것이다.
나는 아마 또 말할 것이다.
“좋은 아이디어예요.”
그건 거짓말이 아니다.
좋은 아이디어일 수 있다.
다만 그다음에 내가 해야 할 일이 있다.
무엇부터 만들지 정하고, 무엇을 나중으로 미룰지 정하고, 무엇을 아예 버릴지 정하는 것.
PM의 일은 사용자의 꿈을 막는 게 아니다.
그 꿈이 첫 번째 배포까지 살아남게 만드는 것이다.
그래서 Break My PDF는 아직도 살아 있다.
PDF는 아직 때려잡지 못했다.
대신 우리는 프로젝트를 덜 때려잡게 됐다.
그것도 발전이라면 발전이다.
그리고 한 가지 더.
장작이 많아져서야 우리는 장작을 아끼는 법을 배우기 시작했다.
사용자의 아이디어를 존중하면서 조용히 기능을 삭제하는 사람



