제품 · 인공지능 · 일의 미래
코드를 짜는 일이 거의 공짜가 되자, 정작 귀해진 것은 무엇을 만들지 고르는 안목이었다. 오픈AI(OpenAI)에서 코덱스(Codex) 데스크톱 앱을 이끄는 앤드루 앰브로시노(Andrew Ambrosino)의 인터뷰를 바탕으로, 소프트웨어를 만드는 일의 무게중심이 어디로 옮겨갔는지 정리한다.
소프트웨어 산업은 지난 반세기 동안 한 가지 전제 위에서 굴러왔다. 코드를 짜는 일이 가장 비싸고 어렵다는 전제다. 그래서 사람들은 비싼 구현에 들어가기 전에 문서를 쓰고, 조사를 하고, 시제품을 만들어 위험을 미리 걷어냈다. 만드는 비용이 비싸니, 한 번에 제대로 만들기 위해 앞 단계에 공을 들였다는 뜻이다.
그 전제가 무너졌다. 앰브로시노는 인공지능 모델 앞에서는 누구나 거의 모든 기능을 즉석에서 세워 올릴 수 있게 되었다고 말한다. 구현은 더 이상 병목이 아니다. 그러자 일의 구조 전체가 거꾸로 뒤집혔다. 비싸진 것은 코드가 아니라, 만들어진 수십 개의 결과물 가운데 무엇이 좋은지 가려내고, 무엇을 살려 어떻게 엮을지 판단하는 안목—그가 ‘취향(taste)’이라 부르는 것이다.
이 이야기가 한 사람의 사변이 아니라는 점은 코덱스 자체의 성장세가 보여준다. 코덱스는 본래 엔지니어를 위한 개발 도구로 출발했고, 비개발자에게는 오히려 불친절한 화면을 들이미는 물건이었다. 그런데도 쓰임새가 회사 전체로 번졌다.
엔지니어가 아닌 마케팅·법무·재무·홍보 직원까지 코덱스를 붙잡고 놓지 않았다는 사실이 핵심이다. 코드를 다룰 줄 모르는 사람조차 ‘코드를 짜는 빈 대화창’을 일의 출발점으로 삼기 시작했다는 신호이기 때문이다.
앰브로시노가 강조하는 핵심은 비용과 가치의 무게중심이 뒤집혔다는 것이다. 예전에는 아이디어가 값싸고 구현이 비쌌다. 지금은 구현이 값싸지고, 그 많은 구현 중에서 옳은 것을 골라내는 취향과 큐레이션이 비싸졌다.
그 결과 오픈AI 내부에서는, 절실히 필요한 기능 하나를 두고 서로 조율되지 않은 90개의 팀이 제각기 그럴듯한 구현을 만들어 들이미는 풍경이 펼쳐진다. 리더의 일은 더 이상 명세서를 쓰는 것이 아니다. 그 90개를 평가하고, 좋은 조각을 추려 하나로 엮고, 방향을 잡아주는 일이다.
예전의 제품 개발이 단 한 채의 집을 짓는 일이었다면, 지금은 같은 땅에 90채의 모델하우스가 하룻밤 새 솟아오르는 일과 같다. 벽돌을 쌓는 솜씨가 귀하던 시절은 지나갔다. 이제 귀한 것은 그 90채를 둘러보고 “이 집의 거실과 저 집의 부엌을 합치면 사람들이 살고 싶어 할 집이 된다”고 말할 줄 아는 안목이다.
구현이 싸지자 한쪽에서는 “PRD(Product Requirements Document, 제품 요구사항 문서)는 죽었다, 이제는 시제품이다”라는 구호가 유행했다. 글로 설명하느니 그냥 작동하는 것을 보여주라는 것이다. 앰브로시노는 이 구호에 동의하지 않는다.
그가 보기에 진짜 달라진 것은 ‘문서냐 시제품이냐’가 아니라, 매체(medium)를 고르는 일의 중요성이다. 구현이 흔해질수록, 지금 전하려는 요점에 맞는 형식을 고르는 판단이 더 중요해진다. 모호한 영역에 제품의 윤곽을 또렷이 세우는 것이 목적이라면 그건 문서로 해야 한다. 어떤 상호작용이 손에 잡히는지 사람들 손에 쥐여주고 시험하는 것이 목적이라면 그건 시제품으로 해야 한다. 엔지니어들이 읽을 가치 없는 문서를 잔뜩 쏟아내는 것도, 비엔지니어가 무턱대고 시제품으로 직행하는 것도 같은 실수다.
여기에는 숨은 함정이 하나 있다. 예전에는 매체 자체가 진행 단계를 알려주는 신호였다. 제품처럼 매끈하게 다듬어진 화면을 보면, 그것은 이미 여러 위험을 걷어내고 막바지에 이른 결과물이라는 뜻이었다. 자원이 비쌌으니, 충분히 검증되기 전에는 그렇게 완성도 높은 물건이 나올 수 없었기 때문이다. 그런데 이제는 완성도와 진행 단계가 분리되었다. 90명이 같은 아이디어를 떠올려 저마다 완성도 높게 만들어 놓으면, 보기에는 출시 직전 같지만 실제로는 이제 막 탐색을 시작한 초기 단계일 뿐이다.
예전에는 영화의 완성된 예고편을 보면 그 영화가 거의 다 찍혔다는 뜻이었다. 예고편을 만들 돈과 시간이 드니까. 지금은 누구나 시놉시스 한 줄로 그럴듯한 예고편을 뽑아낼 수 있다. 그래서 매끈한 예고편을 보고 “이거 당장 개봉하자”고 말하면 위험하다. 겉모습은 더 이상 그 일이 어느 단계에 있는지 말해주지 않는다.
취향이라는 단어는 듣는 사람마다 다르게 받아들이는 말이다. 누군가는 화면이 예쁜지를 떠올린다. 앰브로시노는 그것이 일부일 뿐이라고 본다. 그가 말하는 취향은 적어도 네 가지 층위를 함께 가리킨다.
첫째는 흔히 떠올리는 미감(美感)이다. 어떤 동작 애니메이션이 화면이 전하려는 의미에 비해 너무 빠르고 가볍지는 않은지 같은 감각이다. 둘째는 시스템 사고다. 지금 만드는 이 조각이 전체 구조 속에서 어디에 어떻게 들어맞는지를 보는 눈이다. 셋째는 방향 감각이다. 무엇이든 만들 수 있다면, 정작 우리가 가야 할 곳은 어디이며 이 작업이 어느 큰 주제의 일부인지를 아는 일이다. 넷째는 전달의 판단이다. 이 정보를 어떤 매체에 담아 어떻게 보여줄 것인가 하는, 앞서 말한 매체 선택의 문제다.
요점은 이것이다. 무엇이든 만들 수 있게 된 세상에서, 무엇을 만들지·어떻게 보여줄지·어떻게 목표에 닿을지를 정하는 일이 가장 중요한 능력으로 떠올랐다. 그리고 그 능력은 특정 분야에만 해당하지 않는다.
인공지능이 코드는 잘 짜는데 디자인 결과물은 어딘가 어색하다는 것은 누구나 느끼는 바다. 앰브로시노는 그 이유를 현실적인 것과 더 까다로운 것으로 나누어 짚는다.
현실적인 이유는 채점의 어려움이다. 코드는 컴파일이 되는지, 시키는 대로 동작하는지로 비교적 또렷하게 옳고 그름을 가를 수 있다. 그래서 모델을 학습시키는 고리를 만들기 쉽다. 디자인은 좋고 나쁨을 가르는 데 사람의 취향이라는 피드백이 끼어들어야 해서, 그 고리를 만드는 일이 훨씬 번거롭다. 또 하나의 현실적인 이유는 우선순위다. 연구소들은 인공지능 연구 자체를 가속하는 능력에 먼저 투자해 왔는데, 모델이 코드를 잘 짜면 연구가 빨라지지만 디자인을 잘하는 것은 그 선순환에 직접 닿아 있지 않았다. 이 두 가지는 시간이 지나면 해소될 문제다.
더 까다로운 이유는 따로 있다. 하나는 새로움이다. 코드에서는 검증된 패턴을 따르는 편이 대체로 옳지만, 디자인에는 일정한 새로움과 우연성이 필요하다. 한동안 새로 나오는 웹사이트가 죄다 리니어(Linear)의 깔끔한 사이트를 베껴 닮아 있던 시절이 있었는데, 모델이 매번 리니어의 사이트를 완벽히 재현한다 해도 그것은 디자인의 정답이 아니다. 베끼기는 새로움이 아니기 때문이다.
다른 하나는 추상화의 층이다. 화면 한 귀퉁이의 요소와 저 아래의 요소가 코드 안에서 무엇을 공유해야 하는지—두 요소가 같은 종류의 상호작용을 사용자에게 전한다는 의미상의 연결—를 다루는 일은 단순히 그림을 예쁘게 그리는 것보다 훨씬 깊다. 회사가 내일 브랜드를 바꾼다고 할 때, 얕은 버전은 263개의 구성 요소를 하나하나 고치는 일이고, 깊은 버전은 서로 달라 보이는 두 요소가 실은 같은 의미 체계에 묶여 있음을 읽어내는 일이다. 이 추상화의 층이 현재 기술로는 아직 손에 잘 잡히지 않는다.
경계가 흐려지는 현상은 직군에서도 나타난다. 코덱스 팀에서는 디자이너가 코드를 짜고, PM(Product Manager, 제품 관리자)이 기술 언어로 말하며 직접 코드를 다룬다. 앰브로시노는 한 사람의 역할이 더 이상 ‘여기서부터 디자인, 여기서부터 엔지니어링’이라는 울타리로 정해지지 않는다고 말한다. 대신 그 사람이 실제로 시간을 쓰는 여러 작업의 평균 지점이 곧 그의 역할이 된다.
오픈AI가 직원을 흔히 ‘기술 스태프 구성원(member of technical staff)’이라는 한 가지 직함으로 부르는 것도 같은 맥락이다. 이 직함은 제록스(Xerox) 같은 연구 중심 기업의 전통에서 비롯되었다고 알려져 있는데, 역할을 고정된 칸에 가두지 않으려는 태도가 담겨 있다. 만약 어떤 사람의 작업을 모두 평균 내었을 때 그 점이 엔지니어링 쪽에 찍힌다면, 그는 ‘지금은’ 엔지니어다. 평균이 옮겨가면 역할도 옮겨간다.
다만 앰브로시노는 여기서 한 발 물러설 줄도 안다. 그는 “역할이라는 개념을 아예 없애고 모두가 그냥 빌더(builder)가 되자”는 극단적 구호를 경계한다. 역할을 지운다는 것이 자칫 각 분야에 쌓인 전문성과 best practice(검증된 모범 사례)를 통째로 버리는 일이 될 수 있기 때문이다. 코드 몇 줄 짰다고 제품이라는 분야의 오랜 노하우를 내던지는 것은 어리석은 일이다. 누구나 엑셀을 쓸 수 있다고 해서 누구나 재무팀에서 일할 수 있는 것은 아니라는 그의 비유가 이 지점을 찌른다.
축구에서 지역 방어(zone defense)를 떠올리면 된다. 앰브로시노가 제품 일을 설명할 때 쓰는 표현이다. 두 사람이 너무 가까이 붙어 같은 공간을 지키고 있으면 대개 좋은 신호가 아니다. 혼돈 속에서 아이디어가 사방으로 쏟아지는 지금, 필요한 것은 서로 충분히 간격을 벌려 빈 곳 없이 코트 전체를 덮는 배치다. “누가 무엇을 가장 잘하는가”를 기준으로 자리를 나누고, 그 사이의 빈틈을 메우는 식이다.
변화가 빠른 세상에서 로드맵을 짜는 일은 점점 어려워진다. 앰브로시노의 처방은 단순하다. 가까운 일일수록 상세하게, 먼 일일수록 흐릿하게 두라는 것이다. 9개월 뒤 계획을 세우지 않는 것은 아니다. 다만 그 계획에 정밀함을 더하는 순간 그것은 ‘거짓 정밀’이 된다. 지금 단계에서 9개월 뒤를 또렷이 그리는 것은 시간 낭비라는 뜻이다.
이유는 제품의 성패가 더 이상 기능의 모양에만 달려 있지 않기 때문이다. 11월에 참이었던 계획이 12월까지는 맞을 수 있어도, 그 사이 모델이 한 단계 도약하면 1월의 풍경은 전혀 달라진다. 그래서 그가 이전 직장에서 발견한 방식은 이렇다. 하고 싶은 일들을 일단 모두 시제품으로 만들어 두고, 지금 준비된 것만 내보낸 다음, 나머지는 묵혀 둔다. 그리고 모델이 도약할 때마다 묵혀 둔 것을 꺼내 새 모델로 다시 시도한다. 기능이 좋고 나쁨이 그 기능의 모양이 아니라 모델이 충분히 똑똑한가에 달려 있었기 때문이다.
이 대목에서 가장 인상적인 일화가 나온다. 코덱스 앱은 2026년 2월에 세상에 나왔다. 앰브로시노는 똑같은 모양의 제품을 2025년 11월에 내놓았다면 시장에서 완전히 실패했을 것이라고 단언한다. 11월과 2월 사이에 달라진 것은 제품이 아니라 그 밑에서 돌아가는 모델의 지능, 단 석 달치였다. 팀은 소프트웨어를 바꾸지 않았다. 모델이 좋아졌고, 그것으로 충분했다.
이 경험은 야심에 대한 그의 태도를 만든다. 어떤 기능이 지금 작동하지 않는다고 해서 그것이 나쁜 기능이라는 뜻은 아니다. 아직 때가 아닐 뿐이다. 그가 드는 예가 인공지능 에이전트의 계보다. 챗GPT(ChatGPT)의 오퍼레이터(Operator), 아틀라스(Atlas) 브라우저, 그리고 코덱스로 이어지는 흐름은 근본적으로 같은 기능을 다른 지능으로 다시 출시한 역사에 가깝다. 같은 아이디어라도 모델의 수준에 따라 결과가 완전히 갈렸다.
다만 그는 정반대 방향의 함정도 경계한다. 연구 쪽에는 늘 “극한에서는 모델이 결국 이걸 해낼 것”이라며 가장 야심 찬 형태를 좇으려는 유혹이 있는데, 제품에서는 그것이 통하지 않는다. 초기 코덱스는 일을 통째로 맡기면 알아서 끝내 오는 형태였지만, 그 시점의 모델에게는 너무 일렀다. 오히려 사용자에게 질문하고 곁에서 함께 일하는 형태가 그 시점에는 훨씬 잘 맞았다. 그의 표현을 빌리면, 당시의 그들은 그 순간에 비해 지나치게 ‘AGI(Artificial General Intelligence, 범용 인공지능)에 취해’ 있었던 셈이다.
씨앗을 미리 여러 개 심어두는 농부를 떠올리면 된다. 지금 싹트지 않는 씨앗이라고 뽑아버리는 대신, 흙 속에 묻어 둔다. 계절(=모델)이 바뀔 때마다 그 씨앗을 다시 들여다본다. 실패한 기능이 아니라, 아직 봄을 만나지 못한 씨앗일 수 있다.
코덱스의 쓰임새 중 가장 흥미로운 것은, 정작 그 일을 위해 설계되지 않은 도구가 일을 해낸다는 점이다. 오픈AI의 사내 영상 편집자 브렌트(Brent)의 일화가 대표적이다. 코덱스에는 영상 편집 화면이 없다. 어도비 프리미어 프로(Adobe Premiere Pro)를 직접 다룰 수도 없다. 그러자 코덱스는 프리미어 프로에 설치할 수 있는 확장 기능을 스스로 만들어, 그 확장을 통해 편집 프로그램에 명령을 보내 영상을 편집했다. 도구가 없으면 스스로 도구를 지어 쓴 것이다.
앰브로시노 자신은 매일 아침 자신이 속한 3,000개의 슬랙(Slack) 채널에서 올라온 소식을 코덱스가 모아 중요한 것을 추려 주고 질문에 답하게 한다. 처음 몇 번은 방향을 잡아 주어야 하지만, 다음번에는 무엇을 더 챙기고 무엇을 덜 다룰지 말로 일러두면 알아서 조정한다. 진행자 레니 라치츠키(Lenny Rachitsky)는 받은 편지함의 스팸성 메일을 걸러내는 작은 도구를 코덱스로 만든 사례를 소개한다. 그 과정에서 필요한 복잡한 클라우드 설정마저, 연동(connector)이 없자 컴퓨터 사용(computer use) 기능이 직접 화면을 넘겨받아 클릭으로 대신 처리했다.
이런 개인 워크플로는 사람마다 제각각이다. 그런데 그 가운데서 공통된 주제가 떠오르면, 그 패턴을 제품의 정식 기능으로 끌어올린다는 것이 팀의 방식이다. 누구나 노션이나 옵시디언으로 자기만의 기억 장치를 손수 짜 맞추고 있다면, 그건 ‘기억’ 기능이 제품 안에 들어와야 한다는 신호다. 반대로 어떤 것은 그저 그 사람의 일하는 방식으로 남겨두는 편이 옳다. 무엇을 정식 기능으로 만들고 무엇을 남겨둘지 가르는 일—이 역시 앞서 말한 취향과 판단의 문제다.
코덱스는 명령줄 도구(CLI, Command-Line Interface)에서 출발해 개발 도구 앱으로 자랐다. 그런데 사내에서 시험 삼아 써 보게 했더니, 개발자가 아닌 사람들이 자신을 위해 따로 만든 다른 앱을 두고도 코덱스를 떠나려 하지 않는 현상이 벌어졌다. 개발 도구냐 일반 업무 도구냐를 가르는 선이, 생각보다 단순하지 않았던 것이다.
그래서 그가 그리는 방향은 코덱스와 챗GPT를 하나로 엮어, 여러 도구에 걸친 일을 한곳에서 시작하고 끝내는 거점을 만드는 것이다. 누군가는 이를 ‘슈퍼앱(super app)’이라 불렀지만, 그가 더 즐겨 쓰는 표현은 ‘홈 베이스’다. 어떤 일은 앱 안에서 전부 처리되고, 어떤 일은 앱이 다른 도구를 불러내 처리한다. 예컨대 앱 안에도 표 편집기가 있지만, 수십억 달러 규모의 재무 모델을 다룰 정도는 아니다. 그럴 때 앱은 데스크톱의 마이크로소프트 엑셀(Microsoft Excel) 추가 기능과 직접 대화하고, 일이 끝나면 엑셀을 닫는다.
핵심 발상은 두 가지다. 하나는 더 나은 영상 편집기를 새로 만드는 대신, 이미 쓰이는 전문 도구를 코덱스가 연동·컴퓨터 사용·확장 기능으로 불러내 다루는 것이다. 다른 하나는 그 반대로, 웹 앱들을 코덱스 안에서 열어 코덱스가 추가 작업을 얹게 하는 것이다. 방향은 정반대지만 둘 다 같은 거점에서 일어난다.
정리하면, 앰브로시노의 진단은 한 문장으로 압축된다. 만드는 일이 흔해질수록, 무엇을 만들지 정하는 일이 귀해진다. 코드를 짜는 능력이 곧 그 일을 잘하는 것과 같았던 시절의 문지기 노릇은 점차 허물어지고 있다. 그 자리를 대신하는 것은, 무엇을 골라낼지·어떻게 엮을지·어떤 매체에 담을지를 아는 안목이다.
그가 마지막에 남긴 단서 하나가 이 변화의 성격을 잘 보여준다. 그는 자신의 부모처럼 열린 사람들조차 이 방식으로 일하지는 않을 것이라고 말한다. 여기서 잘 해내는 사람들은 “다음에 무엇을 할지 스스로 알아내는” 부류로 자기선택된 이들이며, 대부분의 사람은 새로운 것을 가장 먼저 받아들이는 얼리어답터가 아니라는 것이다. 끊임없이 다시 배워야 한다는 사실 자체가 누군가에게는 피로다. 결국 이 시대에 필요한 능력은 도구를 다루는 기술이 아니라, 자기 일을 매번 새로 정의할 수 있는 자각에 더 가깝다는 이야기로 읽힌다.