프로덕트 AI 스택에 더해야 할 세 가지 역량

*원문을 번역한 글입니다.

*원문은 발행 이후 수정될 수 있으며, 본 번역은 발송 시점 기준으로 작성되었습니다.

AI는 더 많은 결과물을 더 빠르게 만들 수 있게 해주지만, 그것이 곧 좋은 작업을 의미하는 것은 아닙니다. 문제는 도구나 기술에 있는 것이 아니라, 그 뒤에 있는 사고 방식에서 생깁니다. 이 글에서는 AI 네이티브 시대에 제품을 만들 때 조용히, 그러나 가장 중요하게 작동하는 역량들을 살펴봅니다.

사진: 츠치야 세.

저는 거의 1년 동안 한 AI 네이티브 스타트업의 CPO와 긴밀하게 일해오고 있습니다. 이 회사는 현재 가능한 기술의 최전선에서 움직이고 있는 곳입니다. 이들의 코드는 AI 에이전트가 작성합니다. 그리고 이들이 만드는 제품 역시 AI 에이전트입니다. 최근에는 내부로 초점을 옮겨, 단순히 AI 제품을 개발하는 것을 넘어 내부 제품 프로세스까지 AI 기반으로 전환하고 있습니다. 바로 그 지점에서 저는 곧 부딪히게 될 벽을 보았고, 문제를 제기해야겠다고 느꼈습니다.

비슷한 상황에 놓인 많은 팀들처럼, 이들도 먼저 눈에 보이는 실행 레이어에 집중하려는 경향이 있었습니다. AI로 어떻게 디자인할지, 어떻게 더 빠르게 프로토타이핑할지, 어떻게 스펙을 생성할지, 어떻게 더 빠르게 움직일지 같은 것들입니다. 솔직히 말하면, 이 접근은 효과가 있습니다. 역량은 빠르게 향상되었고, 결과물을 만들어내는 능력도 크게 증가했습니다. 하지만 일은 거기서 끝나지 않습니다.

더 많이 하는 것이 곧 좋은 결과물을 내는 것은 아닙니다. 속도는 격차를 줄이는 것이 아니라 오히려 더 크게 부각시킬 뿐입니다. 더 많은 아이디어, 더 많은 작업 흐름, 더 많은 문서, 더 많은 코드를 만들어낼 수는 있지만, 품질은 여전히 다른 요소에 달려 있습니다.

그 "다른 무언가"는 새로운 것이 아닙니다.

그것은 좋은 제품 의사결정을 내리기 위해 늘 필요했던 역량들의 묶음입니다. AI는 이 역량들을 대체하지 않습니다. 오히려 그런 역량이 없을 때 치러야 할 비용을 더 크게 만듭니다.

결국 저는 클라이언트와 함께 이러한 메타 역량 몇 가지에 집중하게 되었습니다. 이 역량들은 AI에만 해당되는 것은 아닙니다. 하지만 지금 AI를 활용해 제품 개발 프로세스를 만들고 있다면, 이 역량들은 더 이상 무시할 수 없는 요소가 됩니다.

논리적 사고

요즘 AI를 쓰면 생각을 멈추게 되고, 결국 머리가 굳는다는 이야기가 널리 오가고 있습니다. 솔직히 말해서, 그건 사실이에요. 예전에는 직접 하던 생각 중 일부를, 이제는 더 이상 하지 않습니다. 이제는 처음부터 만드는 대신 검토합니다. 하지만 검토하는 것과 만드는 것은 같은 일이 아닙니다. 처음부터 스펙을 작성할 때 작동하던 사고의 근육은, 에이전트가 준 초안을 편집할 때 같은 방식으로 움직이지 않습니다.

하지만 제가 계속해서 되돌아보는 관점은 이렇습니다. 모든 생각이 같은 가치를 갖는 것은 아닙니다. 단순한 사고 과정을 건너뛰는 것은 괜찮습니다. 사실 AI는 그런 일을 하기 위해 존재합니다. 문제는 단순한 사고가 사라졌기 때문에, 어려운 사고의 중요성이 줄어드는 것이 아니라 오히려 더 커진다는 점입니다. 지금 필요한 역량은 어디에서 깊이 생각해야 하는지를 더 엄격하게 구분하고, 그 지점에서는 더 치열하게 사고하는 것입니다.

구축하려는 것의 논리적 뼈대는 명확해야 합니다. AI가 없던 때에는, 무언가를 직접 작성하는 과정 자체를 거치면서 그 논리의 일부를 자연스럽게 검토하게 됐습니다. 하지만 AI는 그 발판을 없애버립니다. 따라서 논리적 사고는 과거의 향수를 불러일으키는 기술이 아니라, 오히려 이전보다 더 날카롭게 요구되는 역량입니다.

MVP를 엄격하게 다루는 힘

AI는 무언가를 만드는 비용을 낮췄습니다. 이전에는 개발 속도를 늦추던 마찰 요인들이 대부분 사라졌습니다. 흐름을 생성하고, 구성 요소를 연결하고, 아이디어를 테스트하고, 반복 작업을 하는 데 걸리는 시간이 훨씬 단축되었습니다. 그러면 자연스럽게 계속 만들고 싶어집니다. 이렇게 쉬운데, 레이어 하나쯤 더하고, 기능 하나쯤 더 넣고, 시나리오 하나쯤 더 추가하지 못할 이유가 없다고 느끼게 됩니다.

하지만 MVP는 개발이 어려워서 생긴 게 아닙니다. MVP가 필요한 이유는 우리가 무엇을 만들어야 하는지 미리 정확히 아는 데 서툴기 때문입니다. 실제로 무엇이 중요한지 이해하려면 작동하는 모습을 보고, 만져보고, 사용해 보고, 경험해 봐야 합니다. 만드는 비용이 낮아졌다고 해서 이 사실이 달라지지는 않습니다. 오히려 그 사실을 더 쉽게 무시하게 만들 뿐입니다.

Claude Code 에이전트 환경을 WhatsApp에 연결할 때 저도 모르게 똑같은 실수를 저지르고 있었습니다. 저는 제가 필요할 것이라고 생각한 모든 엣지 케이스와 세션, 여러 조건들을 설계하기 시작했습니다. 그러다 어느 순간 멈춰서 이렇게 생각했습니다. “아니, 일단 출시하자. 단순하게라도 작동하는 것을 먼저 만들고, 거기서부터 쌓아가자.”

단순한 버전을 직접 사용하기 시작하자마자, 상황이 달라졌습니다. 처음 떠올렸던 아이디어 중 일부는 현실적이지 않은 UX에 불과했습니다. 더 나은 아이디어들이 떠올랐습니다. 새로운 방향도 열렸습니다. 지금은 그것이 제가 주로 사용하는 도구 중 하나가 되었습니다. 만드는 일이 쉬워질수록 MVP는 하나의 역량이 됩니다. 일찍 멈추는 것이 오히려 더 어려운 선택이 되기 때문입니다.

의도적으로 반대편에 서기

이 부분은 저에게 가장 의외였습니다.

반대 관점에서 생각하는 능력은 언제나 유용했지만, 저는 그동안 필요할 때만 제한적으로 사용했습니다. 큰 결정을 내리기 전에는 잠시 멈춰서, 가정을 의심하고, 내가 놓치고 있는 것이 없는지 살펴보곤 했습니다. 대부분의 경우에는 그것만으로도 충분했습니다.

하지만 AI와 함께 일할 때는 그렇지 않습니다.

예를 들어 에이전트에게 “왜 이 방식으로 했지?”라고 물을 때가 있습니다. 제 의도는 원래의 판단 근거를 이해하고 싶다는 뜻입니다. 그런데 에이전트는 이를 “왜 다르게 하지 않았지?”라는 의미로 받아들이고, 곧바로 방식을 바꿔버립니다. 순수한 질문이 어느새 제 입장에 반하는 지시로 바뀌어버리는 것입니다.

또는 제가 무언가를 말하면, 저조차 확신하지 못하는 상황에서도 에이전트는 “정말 맞습니다!”라고 답합니다. 그러면 저는 다시 되묻게 됩니다. "정말 내가 맞는 게 확실해? 내가 무언가를 놓치고 있다면, 나에게 동의하지 않았으면 좋겠어."

이 사례들은 서로 달라 보이지만, 같은 근본 원인에서 비롯됩니다. AI는 기본적으로 동의하는 쪽으로 작동합니다. 그 빠져 있는 긴장감, 반박, “정말 확실해?”라는 질문은 저절로 생겨나지 않습니다. 그 역할을 의도적으로 설정하고, AI에게 내 주장에 반박해달라고 요청하고, 그 과정을 스택 안에 포함시켜야 합니다.

마무리하며

이 세 가지 역량은 새로운 것이 아닙니다. 언제나 중요했습니다. 하지만 AI 중심의 방식으로 옮겨갈수록, 이 역량들의 중요성은 더 커집니다. AI로 단순히 더 많은 일을 하는 것이 아니라 좋은 일을 하고 싶다면, 전술적인 기술 역량과 함께 이 역량들도 반드시 포함해야 합니다.

원문 출처: https://noaganot.medium.com/three-skills-to-add-to-your-product-ai-stack-199b21f9c82c

DEET를 구독하고 커리어 성장을 위한 작은 습관을 시작해 보세요.