AI Native가 되어야 하는 이유

최근 AI를 직접 쓰며 일하는 방식이 완전히 바뀌었다. 덕분에 기존에 당연하게 여기던 것들을 돌아볼 계기가 되었다. 그 과정에서 깨달은 것이 있다. 내가 PM으로서 가장 자신 있던 것들이, 지금은 가장 먼저 버려야 할 것이 되었다는 사실이다.

클로드 코드의 하네스 구조를 들여다본 순간, 이건 도구의 문제가 아니라는 걸 알았다. 일하는 방식, 우선순위를 정하는 방식, 프로덕트를 만드는 방식. 기존에 체화된 것들이 전부 재정의되어야 하는 상황이었다. 컴퓨터가 발명된 것과 비슷한 수준의 충격이었다. 이건 트렌드가 아니다. 혁명이다.

내가 버린 세 가지

AI Native가 된다는 건, 새로운 도구를 익히는 일이 아니다. 기존에 잘 작동하던 방식을 의심하고, 내려놓는 일이다. 나는 크게 세 가지를 버렸다.

첫째, 완벽한 기획서를 만드는 습관.
PM에게 기획서는 곧 실력의 증명이었다. PRD를 빈틈없이 작성하고, 스펙을 정리하고, 그것을 개발팀에 넘기는 프로세스. 이 과정에 수일에서 수주가 소요되는 것이 당연했다. 하지만 AI와 일하면서 이 프로세스 자체가 병목이 되었다. 완벽한 문서를 만드는 시간에 프로토타입을 세 번 만들고 버릴 수 있는 세상이 온 것이다.

둘째, 전문 영역을 구분하는 사고.
PM은 기획을, 개발자는 코드를, 디자이너는 디자인을. 이 구분이 효율적이라고 배웠다. 다만 AI가 개발과 디자인과 데이터 분석을 동시에 수행할 수 있는 상황에서, 직무의 칸막이는 더 이상 효율이 아니라 제약이 된다. PM이 직접 코드를 쓰고, 배포하고, 운영하는 것이 가능해진 세상에서 "그건 내 영역이 아니다"라는 말은 곧 "나는 그만큼만 하겠다"라는 선언과 같아졌다.

셋째, 프로덕트 개발 방법론 자체에 대한 의심.
MVP, 린 프로세스, 우선순위 매트릭스. 이것들이 등장한 배경에는 하나의 전제가 있었다. 개발 비용이 높다는 것이다. 비용이 높으니 한 번에 다 만들 수 없고, 그래서 가장 중요한 것부터 만들자는 논리였다. 우선순위를 치열하게 매기는 것이 PM의 핵심 역량이라고 배운 것도 이 전제 위에서이다. 다만 AI 시대에 실행 비용이 0에 수렴하는 상황에서, 이 전제 자체가 흔들린다. 비용이 거의 들지 않는데 왜 우선순위를 매겨야 하는가. 최소한의 기능만 만들어 검증하자는 MVP 개념이, 전부 만들어보고 검증할 수 있는 세상에서도 여전히 유효한가. 나는 이 질문에 대한 답이 과거와 같지 않다고 본다.

이 세 가지를 버리는 과정에서 가장 어려웠던 건, 솔직히 말하면 기술적인 장벽이 아니었다. '내가 AI보다 더 나을 것이다'라는 착각을 내려놓는 것이 가장 고통스러웠다.

온톨로지 앞에서 겸손해진 순간

그 착각이 완전히 깨진 순간이 있었다. AI가 잘 읽을 수 있는 지식 체계 — 마크다운 기반의 온톨로지를 구축하고, 그 위에서 LLM을 작동시켰을 때이다.

탄탄한 온톨로지 위의 AI는 나보다 나았다. 그리고 더 무서운 사실은, 피드백을 반영할 때마다 지속적으로 나아진다는 것이었다. 나는 컨디션에 따라 출력이 달라지지만, 잘 설계된 지식 체계 위의 LLM은 일관되게 학습하고 일관되게 개선된다.

이 경험은 단순히 "AI가 빠르다"는 차원의 이야기가 아니다. 구조화된 지식 위에서 작동하는 AI는 인간이 이길 수 없는 영역을 만들어낸다는 사실을 눈앞에서 목격한 것이다. 이걸 받아들이는 데 시간이 걸렸다. 다만 받아들이고 나니 오히려 명확해진 것이 있었다.

그렇다면, 사람은 무엇을 해야 하는가.

실행 비용이 0에 수렴하는 시대

결국, 이 질문으로 돌아온다. AI가 코드를 쓰고, 콘텐츠를 만들고, 데이터를 분석하고, 디자인을 하는 세상에서 사람의 가치는 어디에 있는가.

나의 대답은 명확하다. 문제 정의이다.

실행 비용이 0에 수렴하고 있다. 예전에는 "이걸 하려면 개발자 2명에 3주가 필요하다"는 이유로 포기하던 아이디어가, 이제는 하루 만에 프로토타입으로 나온다. 비용 절감의 폭은 압도적이고, 구현 속도는 상상을 초월한다. 특정 프로젝트에서만 그런 것이 아니다. 클로드 코드를 접한 이후로는 모든 작업이 그렇다.

실행이 거의 공짜가 된 세상에서, 유일하게 비용이 드는 것은 '무엇을 실행할 것인가'를 결정하는 일이다. 이것이 문제 정의이다.

직무의 경계가 무너졌기 때문에 이 변화는 더욱 가속된다. PM이 개발을 하고, 마케터가 데이터 분석을 하고, 비개발자가 서버를 운영하는 시대이다. 누구나 무엇이든 실행할 수 있게 되었다. 이러한 환경에서 '무엇을 할 것인가'를 정의하는 역량은, 특정 직군의 전유물이 아니라 모든 직장인에게 요구되는 본질적인 역량이 된다.

언러닝은 상실이 아니다

이 글을 쓰며 돌아보니, 나는 꽤 많은 것을 버렸다. 완벽한 기획서, 전문 영역의 칸막이, 프로덕트 개발 방법론에 대한 맹신, 그리고 나 자신에 대한 과신까지. 솔직히 그 과정이 편하지는 않았다. 수년간 체화해온 방식을 부정하는 것처럼 느껴졌으니까.

다만 직접 겪어보고 나서 할 수 있는 말은 이것이다. 언러닝은 상실이 아니었다. 해방에 더 가까웠다.

기획서에 매달리던 시간을 문제를 더 깊이 정의하는 데 쓸 수 있게 되었다. 직무의 벽이 사라지니 더 넓은 범위의 문제를 다룰 수 있게 되었다. 개발팀을 기다리지 않으니 아이디어가 떠오른 순간 바로 검증할 수 있게 되었다.

결론적으로, AI Native가 된다는 것은 새로운 기술을 습득하는 일이 아니다. 기존의 방식을 의심하고, 문제를 정의하는 역량에 집중하는 일이다. 지금 당연하게 여기고 있는 일하는 방식이 정말 최선인지 한 번쯤 의심해보기를 권한다.