7장. 슈퍼휴먼이 되는 법

외부 미팅 후 예쁜 삼청동 카페에서 일하던 날, 호현님이 말했다.

"아, 우리 이제 퇴근하자. 커밋하고 푸시해야지."

옆에서 작업하던 나도 Claude Code 창을 바라보며 말했다.

"그럼 저도 커밋하고 푸시할게요~!"

말이 끝나자마자, 우리 둘 다 동시에 빵 터졌다. 개발자들의 언어가 어느새 내 손과 입에 자연스럽게 붙고 있었다. 불과 몇 달 전만 해도 이 단어들을 개발자와 일할 때 들어본 수준이지 제대로는 몰랐던 문과 출신 PM이었는데 말이다.

나는 서강대 커뮤니케이션학부, 고전적인 단어로는 '신문방송학과'를 나왔다. 언론, 광고, 영화, 뉴미디어를 두루 배우다보니 자연스럽게 관찰·콘텐츠 기획·글쓰기·스토리텔링 구성이 강점이 된다. 개발자와 일한 적은 있지만 코딩은 내가 전혀 모르는 분야였다. 그런 내가 어떻게 엔지니어 명함을 달게 되었을까?

지난 커리어를 돌아보니 의도한 건 아니었지만 알파벳 'P'로 시작하는 세 가지 직군을 거쳐왔다. 첫 번째 P는 Producer, 라디오 PD였다. 이때 매일의 질문은 "청취자에게 무슨 이야기를 들려줄까?"였다. 아이템과 코너를 생각하고 프로그램을 조화로우면서도 다채롭게 채우는 것이 내 일이었다. 두 번째 P는 PM이었다. 문제를 파악하고, 프로덕트의 기능과 순서를 정하며, 사용자 흐름을 계획하는 것이 핵심 역할이었다. 질문도 달라졌다. '어떤 문제를 어떤 방식으로 해결할 것인가', 그리고 '무엇을 먼저 만들어야 하는가'가 내 일의 중심이 되었다. 이때 개발자들과 일하기 시작했지만 나는 여전히 '무엇(What)'을 정의하는 사람이었다. 기술적으로 '어떻게(How)' 만드는지는 내 영역이 아니었다. 세 번째 P는 Product Engineer다. AI를 활용해 코드 작성과 디자인, 기능 구현을 한 흐름 안에서 진행한다. 과거에는 기획안을 작성한 후 전달해야 했던 작업들이, 이제는 하나의 연속된 과정 안에서 구현된다. 예전에는 기획자가 프로그래밍 언어를 몰라서 구현을 못 했다면, 이제는 자연어로 AI에게 요청하면 코드가 만들어진다. 과거에는 기획안과 유저 플로우를 그리고 나머지는 팀원들의 손을 빌려야 했다면, 지금은 "어떤 문제를 어떻게 해결할까"까지 직접 할 수 있게 된 것이다.

직무명은 바뀌었지만, 세 가지 직무에는 공통된 사고 과정이 있다. 바로, 무엇을 만들고 왜 만들어야 하는지 정의하는 기획이다. AI가 강력해지면서 이 기획의 힘이 곧 실행력으로 확장되고, 이것이 나의 역할을 자연스럽게 엔지니어링 영역까지 넓혀 놓았다.

2023년 가을, 나는 내가 만든 AI 서비스에 의해 내 자리를 잃었다. 옥소폴리틱스에서 콘텐츠 팀장이자 PO/PM으로 일하면서 AI 뉴스 서비스, AI 리포트 서비스를 만들었다. AI 프롬프트를 고도화하고 결과물의 퀄리티를 높이는 작업을 담당했다. 그런데 그 AI 기능이 너무 잘 작동했다. 결국 콘텐츠 팀은 AI로 대체되었고, 회사는 30명에서 8명으로, 다시 3명으로 줄었다.

그때는 AI가 일자리를 빼앗는다고 생각했다. 하지만 2년이 지난 지금, 생각이 바뀌었다. AI가 일자리를 빼앗기도 하지만, 일하는 방식 자체를 통째로 바꾸고 있다. 이 변화에 맞춰 나의 사고와 워크플로우를 변화시키느냐 아니냐가 앞으로 나의 역량을 뛰어넘는 일을 하느냐, 아니면 그대로 밀려나느냐의 차이를 만든다.

Product Engineer로 일하는 지금 이번에는 AI에게 밀린 게 아니라, AI를 활용해 전문가가 아니었던 영역까지 역량을 확장하게 됐다. 코드 작성 없이도 개발이 가능해졌고, 빠른 프로토타이핑이 가능해졌고, 혼자서도 MVP를 만들 수 있게 됐다.

10년 전 대학가에는 "문송합니다(문과라서 죄송합니다)"라는 표현이 흔했다. 기술 기반 직무는 이과생의 영역이라고 여겨졌고, 문과생은 선택지가 제한적이라는 인식이 강했다.

그러나 지금은 상황이 달라지고 있다. 기술적 작업의 진입 장벽이 낮아지고 있기 때문이다. 영상 제작, 디자인, 프로토타이핑, 그리고 간단한 개발 작업까지, 과거라면 전문적인 훈련이 필요한 영역이었지만 이제는 다양한 AI 도구를 통해 접근 가능해졌다. 전문가의 깊이는 여전히 중요하지만, "아예 시도할 수 없는 영역"은 점차 사라지고 있다.

이제 중요한 건 코드를 짤 줄 아느냐가 아니라, 무엇을 만들어야 하는지 아느냐다. 문제를 정의하고, 해결책을 구상하고, 사용자 경험을 설계하는 능력. 이건 원래 문과생들이 잘하던 일이다.

기획력, 글쓰기, 관찰력, 스토리텔링. 이런 능력들이 AI 시대에 더 빛을 발한다. AI는 지시받은 대로 실행하지만, 무엇을 지시할지는 사람이 결정해야 한다. 그 결정을 잘 내리는 사람이 AI 시대의 승자다. 전공이 뭐였는지보다 문제를 어떻게 정의하고 해결하는지가 중요해졌다.

해결하고 싶은 문제가 있고, 그 문제를 무엇으로 해결하겠다는 관점이 있다면, AI는 당신의 동료가 될 준비가 되어 있다.

Claude code를 쓰기 위해 터미널과 깃을 처음 접했을 때, 검은 화면에 흰 글씨만 깜빡이는 모습이 무서웠다. cd, ls, mkdir 같은 단축어를 익히고, 깃의 커밋과 푸시, 빌드와 배포 사이 개념을 이해하는 데 시간이 걸렸다. 개발자들이 협업할 때 하던 말이라 들어는 봤지만, 직접 체감하는 건 달랐다. 커밋도하고 푸시도 완료되어서 다 된 줄 알았더니 빌드에 에러가 생겨 배포가 안 되고 있어 당황한적도 있다.

그런데 생각해보면 이게 처음은 아니었다. 대학교 때 영상 편집을 처음 배울 때도 마찬가지였다. 프리미어 프로 화면을 보고, 단축키와 기능을 익히는 과정이 있었다. 타임라인이 뭔지, 컷 편집이 뭔지, 렌더링이 뭔지. 처음엔 낯설었지만 손에 익으니 자연스러워졌다. 방송국에서 일할 때도 그랬다. 라디오 콘솔 앞에 처음 앉았을 때, 마이크 1번을 올려야 하는데 3번을 올리기도 했다. 하지만 손에 익을 때까지 반복하면 나중엔 번호를 보지 않고도 올리고 내릴 수 있게 된다. 몸이 기억하는 것이다. 터미널도 그것과 크게 다르지 않았다. 그냥 낯선 코드 창이 무서웠을 뿐, 일주일쯤 지나자 터미널 명령어가 손에 붙기 시작했다. 처음엔 cd workspace를 타이핑하고 claude를 입력했다. 좀 더 지나자 cd work + tap키로 자동완성 + claude가 되었다. 지금은 z work + claude다. 익숙한 단축키처럼 명령어들이 손에 자연스럽게 붙었다.

직장인들이 많이 쓰는 피그마, 엑셀, SQL도 다 똑같았다. 결국 개발 툴 역시 비개발자 입장에서 용어와 화면이 낯설어서 무서운 것이지, 어려워서 못할 건 아니었다.

특히 비개발자들은 바이브코딩을 시작할 때 에러 메시지가 무서울 수 있다. 영어로 가득한 창에 빨간 글씨가 주르륵 뜨면 당황스럽다. 하지만 그 에러를 복사해서 AI에게 붙여넣으면 해결책이 나온다. 모르는 용어가 나오면 "비개발자 입장에서 설명해줘"라고 AI에게 질문하면 된다. 예전보다 새 툴을 배우기가 훨씬 쉬워졌다. AI가 선생님 역할까지 해주기 때문이다.

결국 프리미어 프로를 배우든, 방송 콘솔을 익히든, 터미널과 깃을 배우든, 본질은 같다. 낯선 인터페이스에 익숙해지는 과정이다. 비개발자들이 바이브 코딩에 겁먹을 필요가 없는 이유다. 7일이면 손에 익고, AI가 옆에서 도와주니까 혼자 헤매지 않아도 된다.

원래 영상 편집도, 방송도 다 툴을 익히고 숙련되어야 하는 전문 영역이었다. 그런데 요즘은 영상 편집은 물론이고 AI로 아예 창작을 하는 것도 비전공자에게 가능해졌다. 이건 단순히 개발 영역의 일이 아니다. 모든 영역의 경계가 허물어지고 있는 것이다.

디자이너가 아니어도 Nano Banana와 Midjourney로 이미지를 만들고, 작곡가가 아니어도 Suno로 음악을 만든다. 개발자가 아니어도 Claude Code로 앱을 만들고, 영상 전문가가 아니어도 Runway로 영상을 편집한다. 진입 장벽이 급격히 낮아졌다.

다만, 전문 영역의 프롬프팅은 확실히 다르다. 디자인 기초를 아는 사람이 Midjourney에게 요청하면 결과물의 퀄리티가 다르다. 음악 이론을 아는 사람이 Suno에게 요청하면 더 정교한 곡이 나온다. 개발 기초를 아는 사람이 Claude Code에게 요청하면 더 안정적인 코드가 나온다.

AI를 쓸수록 그 영역에 대한 이해도 함께 커진다. 처음엔 5%만 알아도 시작할 수 있다. 하지만 퀄리티를 높이려면 그 5%를 10%로, 필요하면 15%로 늘려가면 된다. 중요한 건 100%를 목표로 하지 않는 것이다. 전문가 수준의 깊이는 AI가 채워주니까.

이게 내 실력인가? 나만의 선 찾기

처음엔 이런 생각도 했다. 엔지니어링 지식이 없는데 뭔가 만들어진다. 예전에 개발자, 디자이너와 일할 때 기다리던 시간 없이, 목표로 한 화면을 바로 만들 수 있다. 신기하고 재밌으면서도, 이게 맞는 건가? 이게 내 실력이라고 할 수 있나? 의문이 들었다.

결론부터 말하면, 사고를 바꾸면 된다. 100%를 알아야 시작할 수 있다는 생각을 버리는 것이 필요하다. 그리고 필요할 때마다 5%의 지식을 채워 넣는 애자일한 학습법으로 접근하면 부담 없이 따라갈 수 있다.

며칠 전 AI 데이터 사이언스 분야 석박사 과정을 밟고 있는 컴공 출신의 교회 동생과 얘기를 했는데, 대학원 학습 플로우도 많이 바뀌었다고 한다. 이전엔 개념을 완전 흡수하고 시작했다면, 지금은 하면서 계속 지식을 추가하는 형태로. 스타트업의 애자일한 개발 모델처럼 애자일한 학습 + 직접 해보는 것이 AI 시대 나의 한계를 무너뜨리는 핵심이 될 것 같다.

그렇다면 구체적으로 어디까지 알아야 할까? 각 영역마다 '이 정도는 알아야 AI와 대화가 된다'는 최소 기준이 있다. 그리고 '이 이상은 AI가 해주니까 굳이 안 배워도 된다'는 상한선도 있을 것이다. 이 두 선 사이에서 자신만의 지점을 찾아가면 된다.

나의 경우, PM으로 일할 때부터 UX 도서를 읽는 걸 좋아했고, 디자이너와 협업하면서 감각을 키워왔다. 옥소폴리틱스에서 '알쓸용잡(알고 보면 쓸모 있는 용어 잡학사전)'이라는 페이지를 만들어 개발자, 디자이너, 마케터와 일할 때 필요한 용어들을 팀원들과 함께 정리하며 익혔다. 그때도 어느 정도만 알면 충분했는데, 지금도 마찬가지다.

지금은 PM 출신이 엔지니어링을 하면서 필요한 기초 개발 용어집을 AI로 만들어서 쓰고 있다. 중요한 건 전문가처럼 다 알아야 한다가 아니라, 내가 하고 싶은 일을 AI와 함께 해낼 만큼만 유연하게 배우고 채워 넣는 것이다.

물론 프로덕트 엔지니어라고 내가 갑자기 엄청난 개발 스킬을 갖게 된 것은 아니다. 어느 날 Claude Code에게 물어봤다. "너는 내가 어떤 식으로 너를 쓰고 있다고 생각해?" Claude Code는 이렇게 답했다. "당신은 개발 툴을 PM/디자이너처럼 사용하고 있어요. 코드 자체를 보기보다는 결과물과 방향성으로 대화하죠. 스크린샷을 보여주고 자연어로 의도를 설명하고, 결과를 확인한 뒤 다시 수정 방향을 알려주는 방식으로요."

처음엔 '역시 엔지니어라기엔 부족하구나'라고 해석했는데, 곧 그 말이 정확하다는 걸 깨달았다. 애초에 단기간에 개발 지식을 폭발적으로 쌓는 것은 불가능하다.

그런데 가만 생각해보니, 이게 오히려 AI 시대 협업의 핵심이 아닐까? 과거의 협업 방식은 이랬다. PM이 기획서를 쓰고, 디자이너가 화면을 그리고, 개발자가 코드를 짰다. 각자의 영역이 명확히 구분되어 있었고, 그 경계를 넘어서려면 해당 분야를 "배워야" 했다. PM이 개발을 이해하려면 코딩을 배우고, 디자이너가 개발을 알려면 프론트엔드를 공부해야 했다. 하지만 AI와 함께하는 협업은 다르다. 경계가 허물어진 게 아니라, 각자의 전문성을 유지한 채로 다른 영역까지 손을 뻗을 수 있게 된 것이다.

개발자는 여전히 개발자의 눈으로 AI를 쓴다. 코드 구조를 보고, 최적화를 생각하고, 아키텍처를 설계한다. 하지만 이제는 반복 작업은 AI에게 맡기고, 더 복잡한 문제 해결에 집중할 수 있다. PM인 나는 PM의 눈으로 AI를 쓴다. "이 버튼을 누르면 어떤 일이 일어나야 하고, 예외 케이스는 뭐가 있을까"를 생각한다. 코드를 한 줄 한 줄 이해하지는 못해도, 제품의 흐름과 사용자 경험을 설계할 수 있다. 디자이너는 디자인 감각으로 AI를 쓴다. "이 간격은 10px가 아니라 12px여야 해", "이 색상 조합이 더 나아"라고 말하면, AI가 구현해준다.

과거에는 역할 전환(Role Switch)이 필요했다면, 지금은 역할 확장(Role Extension)이 가능해진 것이다. 각자의 전문성이 희석되게 두는 것이 아니라, 그것을 발판 삼아 더 넓은 영역으로 나아가는 것. 영역을 확장해가는 폭이 AI 시대를 슈퍼휴먼을 평가하는 '실력'이 되지 않을까.

나의 언어는 C언어나 JavaScript 같은 컴퓨터 언어가 아니었다. 스토리, 기획안, 그리고 사용자 경험을 설명하고 표현하는 '말과 글'이 내 언어였다. 그런데 사실 프로덕트 엔지니어로 개발을 하면서도 내 언어가 달라졌다는 생각은 들지 않는다. AI와 함께 일하는 방식에서는 "컨텍스트 엔지니어링. 즉 AI에게 정확하게 의도를 전달할 수 있는 역량"이 훨씬 중요하다는 것을 많이 느끼고 있다.

AI 시대에 필요한 역량을 정리하면 세 가지 P로 요약된다.

1. Problem Definition: 어떤 문제를 해결하고 싶은가

AI는 답을 잘 찾아주지만, 질문은 여전히 사람이 던져야 한다. "이 불편함을 왜 해결해야 하는가?", "누구를 위한 것인가?"를 정의하는 것이 첫 번째다. 문제 정의 없이 AI를 돌리면 화려하지만 쓸모없는 결과물이 나온다. 반대로 문제가 명확하면 AI는 놀라운 속도로 해결책을 제시한다.

2. Product Definition: 무엇을 만들 것인가

문제를 정의했으면 그것을 어떤 형태로 해결할지 결정해야 한다. 앱인가, 웹사이트인가, 자동화 시스템인가, 콘텐츠인가. 형태가 결정되면 AI에게 구체적으로 요청할 수 있다. "사용자가 버튼을 누르면 이런 일이 일어나야 해"처럼 제품의 동작을 정의하는 능력이 두 번째다.

3. Prompting Strategy: AI에게 어떻게 요청할 것인가

같은 질문도 어떻게 던지느냐에 따라 결과가 10배 차이 난다. AI와 대화하는 전략, 컨텍스트를 제공하는 방법, 결과물을 검증하고 개선하는 사이클. 이것이 세 번째 P다. 프롬프팅 전략은 경험을 통해 쌓인다. AI를 많이 쓸수록 어떤 질문이 좋은 답을 이끌어내는지 감이 생긴다.

이 세 가지 P가 갖춰지면, AI는 당신을 대신해 일하는 동료가 된다. 해결하고 싶은 문제가 있고, 그 문제를 무엇으로 해결하겠다는 관점이 있고, AI에게 그것을 요청하는 방법을 안다면, 당신은 이미 슈퍼휴먼의 조건을 갖춘 것이다. 이어지는 부록에는 비개발자 출신이 바이브 코딩을 하면서 원하는 것을 구현해내는 방법들을 담았다.