이 글은 [조쉬의 뉴스레터]에서 발행되었습니다.

퀄리티 있는 프로덕트, 창업가, 비즈니스 이야기를 매주 구독해보세요. 
구독 시 100개의 1인 창업 케이스 스터디가 발송됩니다.

[구독하러 가기]

OpenAI 직원의 90%가 매주 Codex를 씁니다. 엔지니어 90%가 아니라, 회사 전체의 90%예요. 마케팅, 재무, 법무처럼 코드 한 줄 안 쓰는 사람들까지, 화면에 코드를 잔뜩 보여주는 이 개발자 도구를 매주 열고 있죠.

이 앱을 이끄는 사람이 앤드루 앰브로시노인데, 디자이너에서 엔지니어로, 다시 PM으로 옮겨온 독특한 이력을 갖고 있어요. 요즘 "이제 누구나 뭐든 만들 수 있다", "직군 구분이 사라진다" 같은 얘기가 여기저기서 나오잖아요. 가장 앞서 있는 팀에서 그 변화를 직접 겪고 있는 사람이 뭐라고 말하는지, 레니 팟캐스트 대담을 가져왔습니다.

만드는 건 공짜가 됐고, 이제 비싼 건 '취향'이다

Q. 몇 년 전과 지금, 제품 팀의 모습은 어떻게 달라졌나요?

한마디로 순서가 거꾸로 뒤집혔어요. 지금 리더로서 가장 어려운 일 중 하나가 바로 이 뒤집힘을 받아들이는 건데요. 이제는 누구나 뭐든 만들 수 있거든요. 우리 모델이든 다른 회사 모델이든, 백지에서 시작해서 "이런 기능을 원해"라고 말하면 웬만한 건 다 세워집니다. 기능을 세우는 것 자체가 소프트웨어에서 특별히 어려운 축은 아니에요. 그래도 이게 되는 건 정말 멋진 일이죠.

예전 제품 프로세스는 반대였어요. 리서치하고, 아이디어를 내고, 프로토타입을 좀 만들어 보긴 했지만, 밑바탕에는 항상 "구현은 비싸다"는 전제가 깔려 있었죠. 그러니까 문서로, 리서치로, 프로토타입으로 앞단에서 위험을 최대한 걷어냈어요. 프로토타입이나 디자인은 상대적으로 싸다고 봤으니까요. 그런데 그게 완전히 바뀌었습니다. 지금 우리 회사엔 "이 기능은 꼭 해야 해"라는 게 하나 있으면, 서로 조율도 안 한 90개 팀이 각자 그걸 구현해서 시도하고 있을 거예요.

Q. 구현이 비싼 부분이 아니라면, 이제 뭐가 비싼가요?

이제 비싼 건 취향(taste)입니다. 사람들이 하는 일이 근본적으로 달라졌다거나 직군이 사라졌다는 게 아니에요. 순서가 뒤집혔다는 거죠. 구현은 더 이상 비싼 부분이 아니고, 이제 값나가는 건 큐레이션(curation)이에요. 그 90개의 시도 중에서 뭐가 좋은지, 어떤 걸 다른 것에 합쳐야 하는지, 어떻게 틀을 잡을지, 이걸 다른 기능의 일부로 넣어야 할지, 토글 안에 구간을 몇 개나 둘지 같은 판단이요. 만드는 게 공짜가 되니까, 남는 건 전부 판단의 문제가 됩니다.

Q. 그렇다면 이제 문서(PRD)를 쓰던 걸 프로토타입으로 대신하는 건가요?

그 얘기가 많이 도는데, 저는 사실 거기에 전혀 동의하지 않아요. 요즘 여러 제품 리더들이 "PRD는 죽었고 프로토타입의 시대다"라고 말하죠. 구현이 워낙 싸졌으니, 특히 코드를 못 짜던 사람일수록 곧장 프로토타입으로 뛰어들고 싶은 유혹이 큽니다. "설명하지 말고 그냥 보여줄게"가 되는 거죠.

그런데 반대로 엔지니어들은 읽을 가치도 없는 문서를 잔뜩 쓰고 싶어 하는 유혹에 빠져요. 구현이 흔해질수록, 내가 말하려는 요점에 맞는 형식을 고르는 게 더 중요해집니다.

애매한 영역에서 제품의 방향을 또렷하게 잡는 게 목적이면 그건 문서가 맞아요. 반대로 뭔가를 사람들 손에 쥐여주고 상호작용 패턴을 실제로 두드려 보고 싶으면 그건 프로토타입이고요. 지금 정말 중요한 건 매체(medium)를 제대로 고르는 일입니다.

Q. 프로토타입이 오히려 방해가 될 때도 있다는 말씀인가요?

맞아요. 완성도 높은 프로토타입에 너무 일찍 고정돼 버리는 게 위험합니다. 예전엔 매체 자체가 신호를 담고 있었어요. 프로덕션에 나갈 앱처럼 보이는 걸 봤다면, 그건 프로세스 후반이라는 뜻이었죠. 위험이 걷혔고, 디자인 검토가 끝났고, 사업적으로도 말이 된다는 의미였어요. 리소스를 받으려면 그 정도로 다듬여 있어야 했으니까요. 그런데 이제 그 연결이 끊어졌어요.

문제는 여기서 생깁니다. 탐색용으로 만든 것에 불과한데, 너무 프로덕션 같아 보이니까 "시각적으로 준비됐네, 그냥 내보내자"가 되는 거죠. 실제로는 리서치가 어디로 가는지, 사용자가 뭘 원하는지, 사업에 뭐가 맞는지 아직 정리가 안 됐는데도요. 그래서 "이건 지금 어느 단계의 물건인가"를 서로 분명히 말해줘야 합니다. 화가가 캔버스에 찍는 첫 붓질처럼, 사람들은 결국 그 첫 자국에 반응하거든요. 그 첫 자국이 프로토타입이어야 할지 문서여야 할지를 아는 것, 그게 또 취향의 문제입니다.

'취향'이라는 애매한 단어의 정체

Q. 좋은 취향, 좋은 판단력이란 구체적으로 뭘 말하는 건가요?

취향은 미적인 부분만 뜻하는 게 아니에요. 어제쯤 리니어(Linear)의 제품 총괄이 올린 트윗이 있었는데, 사람들이 취향을 미적 감각으로만 과하게 좁혀 본다는 얘기였어요. 폴 그레이엄(Y Combinator 창업자)을 예로 들면서, 그는 카고 반바지를 입고 다니지만 분명히 취향이 뛰어난 사람이라고요. 그러니까 취향이 뭔지 결을 좀 나눠 볼 필요가 있어요.

물론 미적인 요소도 있어요. "이 인터랙션 애니메이션이 담아야 할 의미에 안 맞는다, 전하려는 것치고는 너무 톡톡 튄다" 같은 판단이요. 저는 사실 그런 데 지나치게 집착하는 편입니다. 그런데 그 위에 시스템적으로 생각하는 부분이 있어요. 이게 전체 시스템 안에서 어디에 들어맞는지, 우리가 어디로 가고 있고 이건 어떤 큰 흐름의 일부인지, 이 정보를 어떻게 보여줄 건지 같은 거요. 뭐든 만들 수 있는 세상에서 "그럼 대체 뭘 만들어야 하고, 목표가 뭐고, 거기까지 어떻게 갈 건가"를 판단하는 것. 그게 진짜 취향의 질문입니다.

AI는 왜 아직 디자인을 못 하는가

Q. 최고 수준의 AI 모델도 왜 디자인은 잘 못할까요? 언젠가는 잘하게 될까요?

디자인은 채점하기가 코드보다 어렵기 때문이에요. 코드는 "컴파일이 되나, 하려던 동작을 하나"로 맞고 틀림을 가르기 쉽죠. 그런데 디자인은 "좋은 디자인 VS 나쁜 디자인"으로 모델을 훈련시킬 채점 고리를 만들기가 훨씬 까다롭습니다. 취향이라는 인간적인 요소가 피드백 과정에 끼어 있어야 하거든요.

또 하나 현실적인 이유가 있어요. AI 연구소들은 역사적으로 'AI 연구 자체를 가속하는 능력'에 먼저 투자합니다. 코딩 초기에는 모델이 정확한 코드를 짜면 연구가 빨라진다는 게 분명했어요. 디자인은 그 선순환 고리에 직접 들어가 있지 않죠. 중요하지 않다는 게 아니라, 우선순위에서 밀렸다는 거예요. 이런 현실적 이유들은 시간이 지나면 사라질 거고, 모델도 디자인을 꽤 잘하게 될 겁니다.

Q. 현실적인 이유 말고, 더 풀기 어려운 문제도 있을까요?

디자인엔 '문화'라는 층이 있는데, 이게 까다롭습니다. 작년쯤엔 새로 나오는 웹사이트가 죄다 리니어 웹사이트를 베낀 것 같았어요. 리니어 사이트는 디자인도 취향도 훌륭하죠. 그런데 모델이 매번 리니어 사이트 같은 걸 뽑아낸다면, 그건 목표가 아니에요. 디자인엔 소프트웨어 공학보다 훨씬 더 '새로움'이 중요합니다. 오히려 코드는 이미 검증된 패턴을 따라가길 바라지만, 디자인은 어느 정도의 무작위성과 참신함이 필요하거든요.

그리고 더 깊은 층이 있어요. 소프트웨어 디자인과 실제로 짜여지는 코드 사이의 추상화 문제입니다. 예를 들어 화면 이 구석에 있는 이 요소가, 저 아래 있는 저 요소와 코드베이스 안에서 특정 속성을 공유해야 한다는 거요.

만약 내일 회사가 리브랜딩을 한다고 쳐요. 얕은 버전은 "컴포넌트 263개를 하나씩 다 고쳐야 한다"입니다. 깊은 버전은 "이 둘은 겉모습은 다르지만 둘 다 리스트이고, 사용자에게 같은 상호작용 패턴을 전달하니까 의미상 묶여 있다"를 아는 거예요. 지금 기술로는 이 추상화 층이 아직 손에 안 잡힙니다.

디자인 프로세스는 죽었나

Q. 제니 웬은 '디자인 프로세스는 죽었다'고 했는데, 다른 생각을 갖고 계신가요?

사실 제니 웬(Jenny Wen, Anthropic의 디자인 총괄)과 저는 겹치는 부분이 많아요. 프로세스가 죽었다는 그의 진단엔 저도 동의합니다. 저는 AI가 나오기 전부터 이른바 '정통 디자인 프로세스'의 팬이 아니었거든요.

제가 예전 스타트업을 운영할 때 디자이너를 채용하곤 했는데, 그 무렵 '케이스 스터디 공장'이라는 좀 뼈 있는 글이 돌았어요. 디자이너들이 이 프로세스를 배우면서 그걸 결과보다 위에 둔다는 지적이었죠. 뭔가가 이 프로세스(사용자 리서치, 발산과 수렴)를 거치면 두 가지가 참이 된다는 믿음이요.

하나는 그러면 반드시 좋을 거라는 것, 또 하나는 아무도 안 쓰더라도 프로세스를 거쳤으니 좋은 거라는 것. 늘 좀 학문적이었어요. 그리고 이 프로세스는 "구현은 비싸고, 딱 한 번만 만들 수 있다"는 전제 위에 서 있었습니다. 그러니 문제 공간과 해법 공간을 남김없이 훑고 나서야 구현에 들어가는 거였죠.

제가 예전 스타트업에서 디자이너를 뽑던 시절, 정통 디자인 프로세스는 결과보다 절차를 떠받드는 구석이 있었어요. 사용자 리서치, 발산과 수렴, 이 절차만 밟으면 결과물이 좋다고 믿고, 심지어 아무도 안 쓰더라도 절차를 거쳤으니 됐다는 식이었죠. 늘 좀 학문적이었어요. 게다가 이 프로세스는 "구현은 비싸고, 딱 한 번만 만들 수 있다"는 전제 위에 서 있어서, 문제 공간과 해법 공간을 남김없이 훑고 나서야 구현에 들어갔습니다.

Q. 그럼 디자인 프로세스가 죽었다는 건 사실인가요, 아닌가요?

절반은 맞고 절반은 틀립니다. 프로토타이핑을 프로세스 안으로 당겨온 것까지는 예전에도 있었어요. 피그마나 오리가미(Origami) 같은 도구로 인터랙티브 프로토타입을 앞단으로 끌어와 통찰을 빨리 얻는 거였죠. 그런데 지금은 구현 전체를 앞으로 당길 수 있게 됐어요.

여기서 어긋남이 생깁니다. 문 앞에 나갈 것처럼 완성돼 보이는 프로토타입을 보고, 회사 사람들이 "이거 지금 출시하면 안 돼?"라고 하는데, 사실은 아직 초기 디자인 단계이고 아무도 그 말을 안 해주는 거예요. 90명이 같은 아이디어를 갖고 다듬어 놨지만, 그게 바로 '지금의 디자인 프로세스'인 거죠.

그러니까 프로세스의 정확한 도구나 하루하루의 세부 절차에 매여 있다면, 그건 죽었어요. 좋은 시절 못 볼 거예요. 하지만 "우리가 지금 프로세스의 어느 지점에 있는가"라는 큰 틀, 그건 그 어느 때보다 중요해졌습니다. 요즘 디자이너에겐 오히려 도구가 더 많아졌어요. 지금 제품 안에 뭔가를 넣어 A/B 테스트를 하거나, 프로덕션 앱의 상호작용만 흉내 낸 '베이비 코덱스(baby codex, 대폭 단순화한 코드베이스)' 위에서 "사이드바가 이렇게 작동하면 어떨까"를 빠르게 실험하는 식으로요.

직군이 사라진다는 착각

Q. 코덱스 팀에서는 디자인·엔지니어·PM이 어떻게 함께 일하나요?

역할이 겹치는 정도가 예전보다 훨씬 큽니다. 요즘 '역할 붕괴(role collapse)' 얘기가 많은데, 우리 팀은 회사 다른 곳보다 그게 더 심해요. 이게 원래 엔지니어를 위한 기술 제품이다 보니, 우리 디자이너는 엔지니어의 언어를 하고, PM은 기술 용어를 쓰고 코드를 짭니다. 알렉산더(코덱스 제품 리드)는 컴퓨터공학 석사 학위가 있어요. 저는 없고요.

그래서 우리는 각 사람을 '디자인이 끝나고 엔지니어링이 시작되는 경계'로 정의하지 않고, '그 사람이 시간을 쓰는 지점들의 평균'으로 봅니다. 다이어그램에 점을 다 찍어서 평균을 내면, 디자인팀 누군가의 점은 저쪽에 몰려 있는 식이죠. 코드 쓰는 일도 하고 제품 일도 하지만, 평균은 디자인 쪽인 거예요.

게다가 코덱스 앱 전체가 '도그푸딩(자사 제품을 직접 써보며 고치는 것)'으로 만들어져서, 우리는 최선의 도구가 아닐 때조차 최대한 이 앱 안에서 일하려고 해요. 그래야 이 앱이 최선의 도구가 되니까요. 우리는 제품을 더 낫게 만들려고 우리 자신의 프로세스를 일부러 개선하지 않는, 꽤 불편한 자리에 있는 겁니다.

Q. 그럼 앞으로 모두가 '빌더'가 되고, 직군은 사라질까요?

솔직히 저는 그게 두려운 부분이 있어요. 어떤 회사들은 "누가 이렇게 될 거라더라" 하면 극단적으로 그 흐름에 올라타려 하죠. 역할 개념을 없애는 것의 위험은, 각 분야가 '알 만한 모범 사례를 가진 전문 영역'이라는 사실까지 함께 지워버릴 수 있다는 거예요. "우리는 제품 직군을 없애고 다들 빌더가 될 거야"라고 말하는 회사들을 꽤 봤는데, 저는 그게 아주 나쁜 생각이라고 봅니다. 그러면 그동안 쌓인 제품이라는 분야의 진짜 모범 사례, 시도하고 실패하며 얻은 것들이 "나도 코드 좀 짜봤어"라는 이유로 버려지거든요.

"이건 네 담당 아니야" 같은 칸막이가 사라지는 건 저도 환영해요. 하지만 균형이 있어야 합니다. 한 사람이 모든 걸 할 순 없어요. 넓이로도 깊이로도요. 그래서 매니저가 사라지지 않는 거고요. 그리고 모든 분야엔 기술 요소가 있어요. 엔지니어들이 흔히 저지르는 착각이 "코드 짜는 건 기술이고 다른 역할은 그냥 노는 거"라는 건데, 그렇지 않아요. 엑셀을 쓸 줄 안다고 해서 재무팀에서 일할 수 있는 건 아니거든요.

Q. 그렇다면 앞으로 직군은 계속 존재할까요, 흐릿해질까요?

역할을 바꾸기가 훨씬 쉬워질 거라고 봅니다. 모범 사례를 익히기도 쉬워지고, 자기 역량을 '특정 도구를 다루는 능력'에 묶어둘 필요도 줄어들죠. 저는 오랫동안 '나는 소프트웨어 엔지니어가 되면 안 되는 사람'이라고 느꼈어요. 어셈블리 언어에 관심이 없고, 타입스크립트 문법을 외우는 걸 싫어했거든요. 이런 역할들엔 늘 "이 역할을 잘한다는 건 이 도구를 잘 다루는 것"이라는 식의 게이트키핑이 있었어요. 그게 지금 무너지기 시작한 겁니다.

호칭도 그런 흐름의 하나예요. 우리가 쓰는 '기술 스태프(Member of Technical Staff)'라는 명칭은 사실 오래됐어요. 제록스(Xerox)에서 시작됐다고 알고 있고, 제가 처음 인턴 했던 회사에서도 그렇게 불렀거든요. 연구 중심 회사엔 일종의 전통이었는데, 지금 훨씬 흔해졌죠. 네 기능은 정해져 있지 않고, PM이나 디자인 같은 칸에 갇히지 않는다는 신호처럼요.

Q. 그럼 코덱스 팀은 어떻게 구성돼 있나요? 엔지니어·디자이너·PM이 몇 명씩인가요?

사람들이 코덱스 팀이 몇 명이냐고 물으면 저는 늘 "10명에서 몇천 명 사이"라고 답해요. 농담 같지만 진담이기도 합니다. 모델 리서치부터 프런트엔드까지, 여기서 모두가 하는 일이 결국 이 제품으로 모이거든요. 그렇다고 수천 명이 매일 PR을 올리는 건 아니고요.

실제 팀은 엔지니어가 두 자릿수, 디자인은 그 절반쯤이고, 제품(PM)은 몇 명 안 됩니다. PM은 오히려 '존 디펜스(zone defense)' 성격이 강해요. 코덱스·데스크톱 쪽 사람들의 공통점은 주도성(agency)과 취향이에요. 창업을 해봤거나 큰 회사에서 창업가처럼 일하던 사람이 많고, 하나같이 취향이 대단하죠. 우리는 팀을 꽤 크게 두는 편이고, 대부분 실무자(IC)입니다.

PM의 '존 디펜스'

Q. 제품 업무에 '존 디펜스(zone defense)'라는 표현을 쓰시던데, 제품 담당자에게 그건 어떤 모습인가요?

두 명의 제품 담당자가 너무 가까이 붙어서 일하면, 그건 대체로 안 좋은 신호예요. 농구의 지역 방어처럼, 서로 밀어내며 간격을 벌려서 회사 전체를 빈틈없이 커버하는 겁니다. 지금은 아이디어가 사방에서 쏟아지는 혼돈 상태잖아요. 위에서 1년치 계획을 짜서 내려보내는 방식은 안 통해요. 그래서 각 지점을 '취향을 가진 사람'이 처음 발상부터 완성까지 이끌어야 하고, 그러려면 회사 전체를 덮어야 합니다. "누가 뭘 제일 잘하지? 서로 공간을 벌려서 전 구역을 커버하자"가 되는 거죠.

그리고 빈 곳을 메웁니다. 우리는 제품 감각이 있는 엔지니어를 뽑고 싶어요. 코드를 잔뜩 짜놨는데 제품 정합성을 위해 팀 전체가 매번 리뷰해야 하는 상황은 원치 않거든요. 모두가 이런 감각을 갖되, 각자 깊이 파고드는 지점은 달라야 한다는 거예요.

Q. 그럼 IC(실무자)와 매니저의 구분도 흐려지나요?

이제 다들 둘 다입니다. 매니저가 사라지는 것도, 전부 IC가 되는 것도 아니에요. IC라도 이제 코드를 한 글자씩 타이핑하지 않아요. 뭔가를 관리하는 거죠. 에이전트를 관리하고, 특정 결과로 모아지는 작업을 관리하는 겁니다. 팀을 관리하는 매니저도 똑같은 일을 하는데, 단지 다른 단위에서 할 뿐이에요.

제가 사람을 볼 때 찾는 건 분야에 대한 장악력, 그리고 취향이에요. 토큰을 무제한으로 쥐여줘도, 뭐가 신호이고 뭐가 잡음인지 가려낼 줄 아는 취향 말이죠. 콘텐츠가 무한한 세상에서 그냥 슬롭(slop, 양산된 저품질 결과물)만 찍어내면 안 되니까요.

9개월 뒤 계획은 세우지 않는다

Q. 이렇게 빠른 속도에서 로드맵은 어떻게 짜나요?

거창한 방법은 없어요. 기본 원칙은 "가까운 것일수록 자세하게"입니다. 9개월 뒤를 아예 계획 안 하는 건 아니지만, 그건 아주 흐릿하게 둬요. 지금 9개월짜리 계획에 정밀함을 더하는 건 전부 '가짜 정밀함'이거든요. 시간만 낭비하는 거예요. 우리가 11월에 세운 계획은 12월까진 맞았을지 몰라도, 실제로 벌어진 일과는 달랐어요.

우리가 정말 알아야 하는 건 "모델이 어느 시점에 뭘 할 수 있게 되는가"입니다. 제 지난 회사에서 이 전환을 겪었어요. 결국엔 이렇게 됐죠. "앞으로 1~2년 안에 하고 싶은 걸 다 나열하자. 전부 프로토타입으로 만들어 보고, 지금 준비된 건 내보내고, 나머지는 그냥 재워두자. 그리고 모델이 도약할 때마다 그 기능을 새 모델로 갈아 끼워 다시 시도하자." 기능이 좋으냐 아니냐가 결국 '모델이 충분히 똑똑하냐'에 달려 있었거든요. 기능의 모양이 아니라요.

Q. '11월이었다면 코덱스 앱이 실패했을 것'이라고 하셨는데, 무슨 뜻인가요?

똑같은 앱이라도 출시 시점이 몇 달만 달랐어도 결과가 정반대였을 거라는 뜻이에요. 우리가 2월에 내놓은 코덱스 앱이, 만약 11월에 준비돼서 그때 나왔다면 시장에서 완전히 실패했을 거라고 저는 꽤 확신합니다. 유일한 차이는 11월과 2월 사이의 모델뿐이었어요. 제품의 모양은 똑같은데, 겨우 몇 달의 타이밍 차이로 결과가 갈린 거죠.

아직 안 되는 걸 미리 만들어 둔다

Q. 그럼 지금은 안 되는 기능도 일단 만들어두고, 모델이 따라오길 기다리는 건가요?

네, 그런 게 많아요. 다만 여기서 중요한 건, 그게 디자인 프로세스의 어느 단계에 있는지를 분명히 하는 겁니다. 사람들은 아직도 "내가 이 기능 코드를 짰으니 내보내야지" 하는 습관이 몸에 배어 있어요. 아니에요. 코드를 짰다는 건, 앞으로 새 모델이 나왔을 때 다시 시험해 볼 아티팩트(결과물)가 생겼다는 뜻일 뿐이죠.

앱 안의 브라우저가 그랬어요. 사실 예전으로 거슬러 가면 아틀라스(OpenAI의 브라우저) 안에서 에이전트가 돌아가게 한 적이 있고, 그전엔 ChatGPT 안에 오퍼레이터(Operator)가 있었어요. 그건 잘 안 됐죠. 아이디어는 멋졌지만요. 오퍼레이터 → 아틀라스 → 코덱스로 이어지는 근본적으로 같은 기능을, 지능이 달라진 상태로 다시 내놓으니 결과가 완전히 달라진 거예요. 그래서 저는 "이거 안 되니까 나쁜 기능"이라고 고집부리지 말라고 합니다. 아직 때가 안 됐을 뿐일 수 있거든요.

Q. 반대로, 너무 앞서가는 게 문제가 된 적도 있나요?

네, 우리가 너무 'AGI에 취해 있던(AGI-pilled)' 순간이 있었어요. 특히 연구 쪽엔 늘 "결국 모델이 그냥 이걸 다 할 수 있게 될 거야"라며 가장 야심 찬 쪽으로 가려는 욕구가 있는데, 제품에선 그게 안 통해요. 원래 코덱스 첫 출시가 'Codex 웹'이었는데, 상호작용 용도가 아니었어요. 모델에게 작업을 던지면 알아서 하고 완성해서 돌아오는 방식이었죠. 급진적으로 들리진 않지만, 문제는 그 작업을 그렇게 잘하지는 못했다는 거예요. 코드는 나쁘지 않았지만 그 형태가 너무 일렀습니다.

그다음에 나온 클로드 코드는 완전히 로컬이고, 클라우드에 연결도 안 돼 있고, AGI인 척하지도 않았어요. 오히려 질문을 던지고 옆에 앉아서 같이 하는 방식이라, 인생을 통째로 위임할 수 있는 게 아니었죠. 그게 훨씬 잘 됐어요. 그 시점의 모델 수준이 딱 거기였으니까요. 우리는 그 순간에 비해 너무 AGI에 취해 있었던 거예요. 저는 이 교훈을 자주 곱씹습니다.

루프는 지난주 얘기

Q. 요즘 가장 앞선 팀들은 어떤 식으로 개발하나요?

솔직히 말하면 '루프'는 이미 지난주 얘기예요. 흔히 "제품 중 AI가 짠 코드가 몇 %냐"를 묻는데, 작년 기준으로 보면 지금 우리 제품 코드는 100% AI가 짠 겁니다. 그래서 질문이 바뀌어야 해요. "그 코드가 감독하에 짜였느냐, 감독 없이 짜였느냐"로요. 이렇게 기준이 자꾸 올라가는 건 저는 오히려 반가워요. 그만큼 제품이 나아가고 있다는 뜻이니까요.

자율 개발 쪽 탐색이 많았어요. 밤사이에 들어가서 코드베이스를 청소하는 '가비지 컬렉션(불필요한 코드 정리)'을 시키면 어떨까 같은 거요. 지금 모든 모델의 공통된 약점 하나가, 코드를 자꾸 복잡하게 만든다는 겁니다.

어느 회사든 연구하는 분이 이 글을 본다면, 제발 모델이 '코드를 지우는 일'을 더 잘하게 만들어 주세요. 개발을 완전 자동 조종에 맡기려 할 때 이게 진짜 문제가 되거든요. "어떤 기능 요청을 만들고, 어떤 걸 무시하고, 어떤 걸 묶어서 다시 틀 잡을지"를 모델에게 어떻게 가르칠지, "올바른 추상화를 어떻게 세울지" 같은 문제요. 다 나아지고 있지만, "트위터·슬랙·이메일을 듣고 알아서 앱을 개선하는 루프"까지는 아직 아니에요. 하지만 그쪽으로 가려고 하고 있습니다.

Codex로 자기 일을 자동화하는 법

Q. 제품 리더로서 AI를 직접 어떻게 쓰시나요?

저는 늘 코덱스의 쓰임새를 '내 일이 어떤 모양으로 커졌는가'에 맞춰 왔어요. 원래 코덱스 앱을 만들 때 제 개인 목표는 "코덱스 앱을, 코덱스 앱으로 짤 수 있을 만큼 개발에 능하게 만들자"였습니다. 그 시절엔 개발 도구였으니까요. "이걸 못 하네, 그럼 그걸 고쳐서 할 수 있게 만들자, 이제 되네, 그럼 더 하자" 하는 아주 빠른 도그푸딩 고리였죠.

출시하고 나니 제 역할이 바뀌었어요. 사람을 몇 명 뽑아야 했고, 무엇을 만들지 찾아내는 '제품 탐색(product discovery)'을 더 해야 했죠 그래서 그때부터는 "다들 뭘 만들고 있는지 보고, 궤도를 벗어난 걸 바로잡는" 데 코덱스를 쓰기 시작했어요. 이제는 아침에 일어나면, 제가 들어가 있는 3,000개 슬랙 채널에서 뽑아낸 '데일리 브리프(daily brief)'를 봅니다. 어떤 게 내 주의가 필요한지요. 그리고 "질문 다섯 개만 줘, 답해줄게" 하는 식으로 되받을 수 있어요.

Q. 그런 자동화는 어떻게 설정하나요?

앱에 대고 그냥 말로 설정하면 됩니다. "내 슬랙 채널들을 훑어라, 내가 중요하게 보는 건 이런 것들이다" 하고 예약 작업(scheduled task)을 만드는 거예요. 처음 몇 번 돌릴 땐 방향을 좀 잡아줘야 하는데, 좋은 점은 지시문을 어떻게 고치는지 찾아 헤맬 필요가 없다는 겁니다. "다음에 돌릴 땐 이걸 좀 신경 써줘", "이 작업 흐름은 덜 강조해줘", "이번에 이런 일이 있었는데 브리프에 안 떴어, 다음엔 챙겨줘" 하고 말로 코치하면 됩니다. 그러면 알림 방식을 알아서 바꿔주는 거죠.

이게 챗봇 형태의 오랜 문제이기도 해요. 저는 이걸 설정할 줄 알고, 설정하는 것 자체가 제 제품 탐색 업무니까 시간을 씁니다. 하지만 OpenAI에서 이걸 만드는 사람이 아니라면, 이런 걸 일일이 알아내고 싶지 않겠죠. 그래서 최소한, 앱에서 뭔가 하는 법을 모르면 그냥 앱한테 물어보면 되게 만들어 뒀어요. 슬랙 커넥터가 없으면 "슬랙 커넥터를 추가할까요?"라고 묻고, '예'만 누르면 되게요. 이걸로 충분하다는 건 아니지만, 적어도 그 정도는 해줄 수 있죠.

Q. 브라우저 자동화가 왜 그렇게 강력한가요?

컴퓨터 자체를 직접 조작하게 되니까요. 제가 코덱스로 만든 작은 앱이 있는데, 받은 편지함에서 스팸성 메일을 걸러줍니다. 메일이 오면 "이게 원치 않는 콜드 이메일인가"를 판단해서 라벨을 붙이고 다른 곳으로 치워주는 거예요. 그런데 이걸 설정하려면 구글 클라우드 콘솔에 들어가서 펍섭(Pub/Sub, 메시지 전달 방식) API랑 트리거를 잔뜩 세팅해야 했어요. 그 화면 써보셨나요? 정말 느리고 짜증 나거든요.

그래서 "이걸 네가 해주면 어떨까?" 했더니, '컴퓨터 유즈(computer use, AI가 사람처럼 마우스·키보드로 컴퓨터를 직접 조작하는 기능)'로 제 컴퓨터를 넘겨받아서 직접 클릭하며 들어가더라고요. 커넥터가 없어도 상관없다는 듯 그냥 클릭을 시작하는 거예요. 그게 알아서 방법을 찾아냅니다. 눈앞에서 그게 벌어지는 걸 보는 게 좀 정신이 나갈 지경이었어요. 여기서 재미있는 건, 커넥터를 쓸지, 인앱 브라우저를 쓸지, 연결된 크롬 확장 프로그램을 쓸지, 컴퓨터 유즈로 직접 조작할지 그 경계를 정하는 판단이 결국 감으로 이뤄진다는 점입니다.

왜 Codex와 ChatGPT를 합치나

Q. 앞으로 코덱스는 어디로 가나요? 무엇이 되려고 하나요?

'개발자 도구냐, 일반 지식 노동 도구냐'의 이분법 자체가 생각보다 훨씬 미묘하다는 걸 깨달은 게 출발점이에요. 우리는 코덱스를 CLI로 갖고 있었고, 그다음 이 앱을 만들었어요. IDE가 아니라, 챗봇 같지만 그 이상이고, 코드를 볼 순 있지만 편집은 못 하게 한, 딱 적당한 크기의 표면이었죠. 1~2월쯤, 아직 세상에 내놓기 전에 사내에서 도그푸딩을 시작했는데, 엔지니어링과 연구 워크플로우에선 명확한 제품-시장 적합성(PMF)이 잡혔어요.

그런데 흥미로운 일이 벌어졌습니다. 이 앱이 그들에게 적극적으로 적대적인데도요. 코드를 보여주고, "이 명령을 실행해도 될까요?"라고 승인을 요구하고, 애초에 그들에게 맞는 제품 표면이 전혀 아니었는데도 말이죠. 그래서 우리는 이 코덱스의 교훈을 가져다가 ChatGPT 데스크톱 앱과 아틀라스 브라우저에도 코덱스를 붙여서, 더 일반적인 지식 노동 도구로 만들려고 했어요.

그런데 가장 골치 아픈 문제가 생겼습니다. 정작 그 다른 페르소나를 겨냥한 앱들(ChatGPT 데스크톱, 아틀라스)로는 아무도 옮겨가지 않고, 다들 코덱스 앱만 계속 쓴 거예요. 그래서 저희는 코덱스와 ChatGPT를 합치는 쪽으로 가고 있습니다.

Q. 그럼 하나로 합쳐서 모든 걸 하는 곳이 되는 건가요?

누군가 그걸 '슈퍼앱(super app)'이라고 불렀는데, 그 말을 안 했으면 좋았을 걸 싶어요. 이제 하루 종일 슈퍼앱 얘기만 듣게 생겼거든요. 우리가 보는 그림은, 이게 '홈 베이스(home base)'라는 거예요. 여러 표면에 걸친 할 일을 한곳에서 추적하는 곳이죠. 어떤 일은 앱 안에서 다 하고, 어떤 일은 이 앱이 다른 앱을 열어서 처리합니다.

예를 들어 앱 안에 스프레드시트 편집기가 있긴 해요. 그런데 OpenAI 재무팀이 수십억 달러를 조달하려고 돌리는 재무 모델에 그게 충분할까요? 아마 아닐 거예요. 그래서 앱이 데스크톱의 마이크로소프트 엑셀 애드인(add-in)에 직접 말을 겁니다. 작업이 끝나면 엑셀을 닫으면 되고요. "화면에 사각형 하나 그려놓고 그 안에서 모든 게 다 일어나야 한다"가 아니라, 여기서 일을 시작하고 끝내고 자동화하되, 필요한 도구는 뭐든 불러다 쓰는 집이 되는 겁니다.

최근에 사내 영상 담당 브렌트가 코덱스 출시 영상을 전부 코덱스로 편집한 일이 있어요. 코덱스는 영상 편집기가 아닌데, 직접 못 하는 부분은 스스로 프리미어 프로용 확장을 만들어 처리하더라고요. 이게 핵심이에요. 전문 도구를 새로 만들 필요 없이, 코덱스가 기존 도구를 그냥 갖다 쓰면 되는 겁니다.

소중한 노력이 들어간 글을 널리 알려주세요. 

이 기사가 좋으셨다면, 보상을 해주세요. 

가장 좋은 보상은 ‘조쉬의 뉴스레터 구독’입니다. :) 

구독을 하시면 100개의 1인 창업가 데이터베이스를 발송해드립니다.

[구독하러 가기]