AI 시대

요즘 제품을 사용하다가 바꾸고 싶은 부분을 발견하면 예전보다 더 답답하게 느껴집니다. 변경이 어려워서가 아닙니다. 오히려 그 반대입니다. AI와 함께라면 제가 직접 해볼 수도 있을 것 같은데, 여전히 생각을 정리해 누군가에게 전달하고 작업 가능한 시간을 기다려야 하기 때문입니다.

아주 작은 변경도 대개 익숙한 순서를 거칩니다. 문제를 발견한 사람이 내용을 정리하고, 누군가가 우선순위를 판단하고, 디자이너가 화면을 만들고, 개발자가 구현합니다. 각자의 전문성을 활용하기 위한 합리적인 분업입니다. 지금까지 회사는 대부분 이런 방식으로 제품을 만들어왔습니다.

그런데 이 구조에는 하나의 전제가 있습니다. 제품을 실제로 만들 수 있는 사람이 제한되어 있다는 전제입니다.

과거에는 이 전제가 당연했습니다. 아이디어를 가진 사람이 직접 제품을 만들려면 프로그래밍 언어부터 프레임워크, 데이터베이스, 서버와 배포 환경까지 긴 시간 동안 배워야 했습니다. 무엇을 만들고 싶은지 아는 능력과 그것을 실제로 구현하는 능력 사이에는 큰 간극이 있었습니다. 그래서 역할을 나누고, 구현 능력이 있는 사람에게 작업을 모으는 편이 효율적이었습니다.

하지만 지금은 그 전제가 빠르게 무너지고 있습니다.

바이브 코딩은 단순히 개발자가 코드를 작성하는 새로운 방식이 아닙니다. 개발자가 아니었던 사람에게 처음으로 상당한 수준의 제작 능력이 주어지고 있다는 신호에 가깝습니다. 자연어로 원하는 것을 설명하면서 화면과 기능을 만들고, 오류를 수정하고, 실제로 사용할 수 있는 결과물까지 완성하는 일이 이미 일어나고 있습니다.

물론 AI와 함께 무언가를 만들 수 있다는 것과 안정적인 제품을 운영할 수 있다는 것은 전혀 다른 문제입니다. 보안과 개인정보, 데이터 정합성, 성능과 장애 대응은 여전히 전문적인 판단을 요구합니다. 바이브 코딩으로 만든 기능을 아무런 검증 없이 실제 서비스에 배포해도 된다는 뜻은 아닙니다.

그럼에도 중요한 변화는 이미 발생했습니다. 과거에는 아이디어만 제시할 수 있었던 사람이 이제는 직접 작동하는 결과물을 만들 수 있습니다. 개발 우선순위에서 밀려 사라졌을 가설을 혼자 구현해볼 수 있고, 누군가를 설득하기 전에 실제 사용자의 반응으로 가능성을 확인할 수도 있습니다.

그런데 많은 회사는 이 새로운 능력을 과거의 조직 구조 안에서 사용하고 있습니다.

개발자는 AI로 코드를 더 빠르게 작성합니다. 기획자는 문서를 더 빨리 만들고, 디자이너는 시안을 더 많이 생산하며, 마케터는 더 많은 콘텐츠를 제작합니다. 모든 직무가 효율적으로 변하고 있지만, 제품이 만들어지는 순서는 그대로입니다. 문제를 발견한 사람은 여전히 기획하고, 실제 변경은 여전히 소수의 개발자를 통해 이루어집니다.

기술은 만들 수 있는 사람의 범위를 넓혔는데, 조직은 그 사람들에게 만들 권한을 주지 않은 셈입니다.

저는 AI 시대의 생산성을 지금과는 조금 다르게 봐야 한다고 생각합니다. 개발자 한 명이 이전보다 몇 퍼센트 더 빨라졌는지만 보는 것으로는 부족합니다. 더 중요한 것은 조직 안에서 제품을 변화시킬 수 있는 사람이 몇 명인지, 그리고 서로 다른 시도를 동시에 몇 개까지 진행할 수 있는지입니다.

이미 효율적으로 일하는 개발 조직을 90에서 99까지 끌어올리는 일은 분명 의미가 있습니다. 하지만 두 사람이 처리하던 일을 두 사람이 조금 더 빠르게 처리하는 것과, 이전에는 제품을 만들 수 없었던 세 사람이 새로운 실험을 시작할 수 있게 되는 것은 변화의 크기가 다릅니다.

하나는 기존 생산라인의 속도를 높이는 일이고, 다른 하나는 생산라인 자체를 늘리는 일입니다.

AI가 제공하는 더 큰 레버리지는 후자에 있을 가능성이 큽니다. 하나의 작업 스레드를 더 빠르게 만드는 것이 아니라, 조직 안에서 더 많은 작업 스레드가 동시에 시작될 수 있게 하는 것입니다. 그렇게 본다면 AI를 잘 활용하는 조직의 기준도 달라집니다. AI 도구를 얼마나 많이 사용하고 있는지가 아니라, AI로 인해 실제로 만들 수 있게 된 사람이 얼마나 늘어났는지를 봐야 합니다.

이런 생각을 하다 보면 직무에 대한 관점도 자연스럽게 달라집니다.

기획자의 역할이 좋은 기획서를 작성하는 데서 끝나야 할 이유가 없습니다. 마케터도 새로운 온보딩이나 랜딩페이지가 전환에 도움이 된다고 믿는다면 직접 만들어 확인해볼 수 있습니다. 디자이너는 화면을 설계하고 전달하는 것을 넘어 실제 인터랙션이 사용자에게 어떻게 작동하는지 검증할 수 있습니다. 대표 역시 제품에 필요한 변화가 있다고 생각하면 아이디어를 설명하는 것에 그치지 않고 직접 첫 번째 버전을 만들어볼 수 있습니다.

직무가 사라진다는 뜻은 아닙니다. 전문성은 여전히 중요하고, 오히려 더 어려운 문제를 해결하는 데 집중되어야 합니다. 다만 직무가 할 수 있는 일의 경계를 결정해서는 안 된다는 의미입니다.

각자의 직무는 출발점이지 종착점이 아닐 수 있습니다.

저에게도 이 변화는 꽤 직접적인 문제입니다. 그동안 저는 제품의 방향을 고민하고, 필요한 기능을 기획하고, 구성원이 제안한 아이디어의 우선순위를 판단하는 것을 제 역할이라고 생각했습니다. 회사의 목표와 제품을 가장 많이 고민하고 있으니 어느 정도는 자연스러운 구조처럼 보였습니다.

하지만 모든 아이디어가 제 판단을 통과해야 한다면, 저는 제품의 방향을 책임지는 동시에 제품의 속도를 제한하는 사람이 됩니다. 함께 일하는 사람들이 좋은 판단을 할 수 있다고 믿으면서도 모든 시도를 미리 평가하려 한다면, 그 믿음은 실제 권한으로 이어지지 않습니다.

좋은 사람을 모셔왔고, 그들이 회사의 목표와 제품의 데이터를 충분히 이해하고 있다면 일정 범위에서는 그냥 판단을 맡겨야 합니다. 무엇을 시도해도 되는지 매번 허락받게 하기보다, 어떤 결과를 만들어야 하는지 명확히 공유하는 편이 낫습니다.

이때 대표가 내려놓아야 하는 것은 제품에 대한 책임이 아니라, 모든 제품 판단의 독점입니다.

대신 더 많이 공유해야 합니다. 지금 회사가 해결해야 할 가장 중요한 문제가 무엇인지, 어떤 지표가 왜 중요한지, 사용자의 행동과 회사의 수익 구조가 어떻게 연결되는지를 구성원 모두가 알 수 있어야 합니다. 각자가 같은 맥락을 가지고 있다면 모든 생각이 일치하지 않더라도 적어도 완전히 다른 목적지를 향해 달리지는 않을 것입니다.

자율성은 사람을 믿는다는 선언만으로 만들어지지 않습니다. 좋은 판단을 내릴 수 있을 만큼 충분한 정보를 제공하고, 그 판단을 실제 행동으로 옮길 수 있는 권한을 주는 데서 시작합니다.

그러나 권한을 넓히는 것만으로는 부족합니다. 제품을 만들 수 있는 사람이 늘어나면 잘못된 변경이 고객에게 전달될 가능성도 함께 커집니다. 실행의 민주화는 필연적으로 더 강한 안전장치를 요구합니다.

여기서 개발자의 역할이 오히려 더 중요해집니다.

앞으로 개발자는 조직에서 들어오는 모든 요청을 직접 구현하는 사람이 아니라, 더 많은 사람이 안전하게 제품을 만들 수 있도록 기반을 설계하는 사람이 될 수 있습니다. 일부 사용자에게만 기능을 공개하는 방법, 문제가 생겼을 때 즉시 되돌리는 방법, 변경 이후의 이상 징후를 발견하는 방법, 중요한 데이터와 로직을 함부로 건드릴 수 없게 하는 방법이 필요합니다.

개발자 한 명이 기능을 하나 더 만드는 것보다, 다섯 명이 안전하게 실험할 수 있는 환경을 만드는 편이 더 큰 임팩트를 낼 수 있습니다. 개발자의 레버리지가 자신이 작성하는 코드의 양이 아니라, 다른 사람들이 만들 수 있게 해주는 변화의 양으로 확장되는 것입니다.

모든 변경이 같은 자유를 가져야 하는 것은 아닙니다. 문구나 콘텐츠, 독립적인 화면처럼 실패해도 쉽게 되돌릴 수 있는 변화는 빠르게 시도할 수 있어야 합니다. 반면 포인트와 정산, 개인정보, 인증처럼 한 번의 실수가 사용자에게 직접적인 피해를 주는 영역에는 전문적인 검토가 필요합니다.

중요한 것은 모든 시도를 통제하는 것이 아니라 실패의 크기를 통제하는 일입니다.

작게 공개할 수 있고, 곧바로 관찰할 수 있으며, 문제가 생기면 즉시 되돌릴 수 있다면 더 많은 판단을 각자에게 맡길 수 있습니다. 반대로 롤백하기 어렵고 피해가 크게 확산될 수 있는 변경에는 강한 제한을 두어야 합니다. 자율성과 안정성은 서로 반대되는 가치가 아닙니다. 안정적인 환경을 잘 만들수록 더 많은 자율성을 허용할 수 있습니다.

저는 주말에도 제품의 여러 부분을 직접 바꿔보고 싶을 때가 많습니다. 이것은 모든 구성원이 주말에도 일해야 한다는 뜻이 아닙니다. 저에게 회사를 만들고 제품을 고민하는 일은 일상에 가깝고, 새로운 생각을 실제로 만들어보는 과정 자체가 즐겁기 때문입니다.

제가 선택한 생활 방식이 다른 사람에게 근무의 기준으로 전달되어서는 안 됩니다. 주말에 만든 것에 즉시 반응해주기를 기대해서도 안 되고, 더 오래 일하는 사람이 더 높은 평가를 받아서도 안 됩니다.

제가 원하는 것은 모두가 더 오래 일하는 조직이 아닙니다. 같은 시간을 일하더라도 각자의 생각이 실제 변화에 도달할 가능성이 더 높은 조직입니다.

최근에는 어떻게 하면 우리도 조금 더 회사다운 회사가 될 수 있을지를 종종 고민했습니다. 역할을 명확하게 나누고, 의사결정 구조를 세우고, 체계적인 프로세스를 만드는 일이 조직의 성장처럼 느껴졌습니다.

하지만 회사다움이라는 것은 그 자체로 별다른 의미가 없는지도 모릅니다. 회사처럼 보이는 구조를 먼저 만들고 그 안에서 좋은 제품이 나오기를 기대하는 것보다, 좋은 제품을 만들기 위해 필요한 방식으로 일하다 보니 그 결과로 어떤 조직의 형태가 만들어지는 편이 자연스럽습니다.

필요한 역할은 나누고, 고객을 보호하기 위한 절차는 만들어야 합니다. 다만 역할과 절차는 좋은 제품을 만들기 위한 수단이어야 합니다. 그것들을 잘 갖추는 일이 제품을 더 낫게 만드는 일보다 앞서기 시작한다면, 회사는 조금 더 회사다워지는 대신 조금 덜 민첩해질 수 있습니다.

AI는 단순히 우리가 하던 일을 빨리 처리하게 해주는 기술이 아닐 수 있습니다. 회사가 오랫동안 전제로 삼아온 분업의 방식, 판단의 권한, 전문성의 경계를 다시 생각하게 만드는 기술에 가깝습니다.

바이브 코딩으로 누구나 프로토타입을 만들 수 있게 됐다는 사실보다 더 중요한 것은, 조직이 그 능력을 실제 제품의 변화로 연결할 준비가 되어 있는가입니다. AI가 제작의 문턱을 낮췄어도 권한과 정보, 배포 환경이 그대로라면 회사의 생산성은 과거의 구조 안에 머뭅니다.

결국 AI 시대에 조직이 넘어야 할 가장 어려운 벽은 기술이 아닐지도 모릅니다.

만들 수 있는 사람에게 실제로 만들 권한을 주는 것. 좋은 사람을 모셔왔다면 그 판단을 믿는 것. 대표가 모든 제품 판단의 중심에서 조금씩 물러나는 것. 동시에 더 많은 시도가 고객에게 안전하게 도달할 수 있는 구조를 만드는 것.

AI를 잘 활용하는 조직은 가장 빠른 개발자를 가진 조직이 아니라, 가장 많은 구성원이 좋은 판단을 실제 제품으로 바꿀 수 있는 조직에 가까울 것 같습니다.