인터뷰/예측
OpenAI 코덱스 개발 직원 " 6개월 후, 속도 면에서 또 다른 차원의 도약이 있을 것이고 그것은 상황을 다시 바꿀 것"
Tibo: 분명히 2년은 너무 긴 기간입니다. (웃음) 6개월 후를 말씀드리자면, 제가 아주 확신 있게 말할 수 있는 것들은 이렇습니다. 속도 면에서 또 다른 차원의 도약이 있을 것이고 그것은 상황을 다시 바꿀 것입니다. 우리가 해낼 또 다른 것은 매우 큰 목표를 위해 협력할 수 있는 다중 에이전트(multi-agent)의 대규모 네트워크입니다. 예를 들어, 같은 팀 안에서 커서(Cursor)가 처음부터 브라우저를 다시 만드는 것을 시연했던 것과 같이 실행 가능한 영역이 될 것입니다. '자, 시작해'라고 하고 24시간 후에 2백만 줄의 코드로 만들어진 결과물을 얻게 되는 거죠.
이런 것들은 그 속에서 실제로 무슨 일이 일어나는지 이해하기가 거의 불가능할 정도로 복잡할 것입니다. 그래서 여기서 우리가 보게 될 것은 빌드되는 것에 대한 가드레일을 설정하여 더 이상 코드를 볼 필요가 없게 만드는 것입니다. 증명하거나 제약을 두는 방식을 통해 코드가 안전하다는 것을 알고 입력과 출력만 보면 되는 것이죠. 코드는 더 추상화될 것이고, 시스템의 실제 과제와 속성에 대한 모든 것이 될 것입니다.
저는 미래에는 여러분이 그냥 비서를 부르고, 작업을 확인하게 될 것이라고 생각합니다. 여러분을 위해 일하는 모든 AI 에이전트들의 작업을 대표할 수 있는 전담 개인 비서가 하나 있어서, 백그라운드에서 생산적으로 일하게 될 것입니다. 100개나 200개의 개별적인 작은 에이전트들을 모니터링하고 일일이 확인하는 대신에요. 올해 안으로 이런 것들을 아주 빠르게 보게 될 것이라고 생각합니다.
요약
Gergely: 우리 중 많은 사람들이 묻고 있는 질문에 대해 말씀해 주실 수 있나요? 지금 OpenAI 내부에서는 무슨 일이 일어나고 있나요? 더 구체적으로 말하자면, 엔지니어들이 작업하는 방식과 소프트웨어를 구축하는 일, 그리고 이 모든 것이 어떻게 변하고 있는지에 대해서요.
Vijaye: 질문을 명확히 해주셔서 좋네요. 정말 많은 일이 일어나고 있습니다. 저는 그곳에 약 6개월 동안 있었는데, 제가 배운 것 중 하나는 회사에서 진행되는 연구에서 배울 것이 너무 많다는 것입니다. 그리고 가능성을 예상해 보면 정말 놀랍습니다. 이렇게 말씀드릴게요. 우리가 소프트웨어를 작성하는 방식이 근본적으로 변했습니다. 아주 극적으로 변했고, 지난 6개월 동안에도 코덱스(Codex)가 도구에서 확장 프로그램, 에이전트, 그리고 이제는 팀원(teammate)으로 발전하는 것을 보았습니다. 이제 엔지니어들이 에이전트의 이름을 짓고 자신들의 팀원이라고 부를 것으로 전적으로 예상합니다. 그리고 이 일은 아주 빠르게 일어나고 있습니다.
내부적으로 코덱스를 사용하는 사람들의 리더보드를 살펴봤는데, 일부 엔지니어들은 매주 일상적으로 수천억 개의 토큰을 사용합니다. 이건 단일 에이전트 이야기만이 아닙니다. 지난주에 내부적으로 '코덱스 박스(Codex Box)'라는 것을 출시했는데, 이는 서버에 개발 박스를 실제로 예약하고 프롬프트를 실행하여 알아서 작업을 처리하게 하는 방식입니다. 노트북에서 이 모든 것을 조율하는 동안에요. 사람들은 노트북을 덮고 회의에 갔다가 돌아오면 모든 작업이 완료되어 있습니다. 즉, 이 일들이 병렬로 일어나고 있는 겁니다. 이것이 바로 OpenAI 내부에서 소프트웨어가 근본적으로 변한 방식입니다. 실리콘 밸리 중심부에 있는 이 모든 것들이 몇 달 안에 점점 더 확장되기를 기다릴 수가 없네요. 제 생각에 이것이 표준이 될 것이고, 모두가 이런 방식으로 소프트웨어를 개발하게 될 겁니다. 정말 멋진 일이죠.
Gergely: 제가 6개월이나 1년 전으로 돌아가서 당신이 이런 말을 하는 것을 들었다면, '아, 마법 같은 동화 이야기네, 절반은 지어낸 얘기겠지'라고 생각했을 겁니다. 하지만 실제로 우리 중 많은 사람들이 그것을 사용하고 있고, 저도 사용하면서 무슨 일이 일어나고 있는지 보고 있습니다. 그리고 OpenAI 내부의 엔지니어들과도 이야기를 나눴습니다. 저는 엔지니어들과 이야기하는 것을 좋아하는데, 그들은 '#필터없음(no filter)' 상태니까요. 이것이 프래그매틱 엔지니어(The Pragmatic Engineer)의 작업 방식의 비밀 중 하나인데, 미디어 교육 같은 걸 받지 않은 엔지니어들과 이야기하면 그들은 그냥 있는 그대로 말해줍니다.
OpenAI 내부에서 저에게 꽤 위안이 되었던 한 가지는, 솔직히 말해서 모든 엔지니어들이 100% 코덱스로만 코드를 작성하는 것은 아니라는 점입니다. 모두가 훨씬 더 많이 사용하고는 있지만, 수준의 차이는 있습니다. 하지만 절대적으로 최첨단에 있는 한 팀이 있는데(다른 엔지니어들과 이야기해 본 결과), 코덱스 팀입니다. 심지어 OpenAI 내부의 다른 팀들보다도 앞서 있습니다. 그래서 코덱스 팀을 이끌고 있는 티보(Tibo)에게 묻고 싶습니다. 오늘날 코덱스 팀은 어떻게 일하고 있으며, 어제나 오늘 아침 기준으로 엔지니어의 전형적인 워크플로우는 어떤가요?
Tibo: 아주 빠르게 진화하는 상황입니다. 코덱스 팀의 운영 방식에서 흥미로운 점은 그들이 일하는 방식을 끊임없이 재창조하고 있다는 것입니다. 거의 매주 단위로요. 우리가 추구하는 것은 모든 작은 병목 현상을 식별하는 것인데, 이 병목 현상들이 계속 이동합니다. 예전에는 코드 생성이었고, 그다음에는 코드 리뷰로 이동했고, 지금은 '어떻게 하면 사용자 요구를 더 빨리 이해할 수 있을까?', '어떻게 티켓을 분류할까?', '트위터, 레딧 등 모든 중요한 플랫폼에서 사람들이 무슨 말을 하는지 어떻게 파악하고 이를 전략으로 종합할까?'와 같은 문제에 매우 집중하고 있습니다. 그리고 모든 사람이 이 목적을 위해 에이전트를 최대한 활용하려고 노력하고 있습니다.
흥미로운 일화가 있는데, 며칠 전 누군가 코덱스 팀에 합류하려고 협상하는 자리에서 처음으로 이런 질문을 했습니다. "OpenAI에서 제품을 개발하려면 컴퓨팅 자원을 얼마나 쓸 수 있나요?" 저는 속으로 '음, 흥미로운 질문이네요. 컴퓨팅 자원이 많긴 하지만, 직원당 컴퓨팅 예산에 대해서는 별로 생각해 본 적이 없는데'라고 생각했습니다. 보통 그런 건 아주 뛰어난 모델을 실제로 훈련시키는 연구원들에게나 배정되는 거니까요. 저는 사람들이 새롭고 다양한 방식으로 자신을 초월적으로 활용(hyper-leverage)할 수 있다는 것을 깨닫는 이런 변화가 일어나고 있다고 생각합니다. 만약 여러분이 훌륭한 취향과 훌륭한 아이디어를 가지고 있고 소프트웨어를 구축하는 방법을 알고 있다면, 정말 살아있기 좋은 시대입니다. 할 수 있는 일이 정말 믿을 수 없을 정도입니다.
Gergely: 코덱스 팀에서 조금 벗어나서, 비제이, 당신은 OpenAI 내부에 대해 많은 가시성을 가지고 있습니다. 소프트웨어 엔지니어, 혹은 제품 엔지니어(product engineer)의 업무는 어떻게 변하고 있나요? OpenAI는 항상 제품 엔지니어 성향이 강한 소프트웨어 엔지니어들을 명확하게 채용해 왔습니다. 그들의 업무는 어떻게 변하고 있나요? 제품에 맞춰 변화하고 있나요, 아니면 그렇지 않나요?
Vijaye: 근본적으로 우리는 여전히 인간이 사용할 제품을 만들고 있습니다. 그래서 제품에 대한 직관이 아주 많이 작용합니다. 누구나 코딩을 더 쉽게 시작할 수 있게 해주는 새로운 1P(first-party) 앱 덕분에 코덱스를 만지작거리고 있을 때조차도, 우리가 구축하고 출시해야 할 제품이 무엇인지 상상해야 하는 경우가 많습니다. 바로 거기서부터 시작해서 올바른 위치에 도달하기 위해 끊임없이 수정해야 합니다. 저는 그것이 변할 것이라고 생각하지 않습니다. 우리가 계속해서 인간을 위한 소프트웨어를 만드는 한은요.
미래의 어느 시점에는 에이전트를 위한 소프트웨어를 만들게 될지도 모르고, 그러면 그 에이전트들이 제품 엔지니어나 제품 관리자가 될 수도 있겠죠. 하지만 저는 그 속도가 소프트웨어 개발을 훨씬 더 매력적이고, 흥미롭고, 솔직히 더 재미있게 만든다고 생각합니다. 비행기에서 코딩을 하고 있었는데, 그때는 개발 박스(dev boxes)에 접근할 수 없었지만, 비행 승무원이 와서 노트북을 닫으라고 하면 '안 돼요, 에이전트가 멈추는 걸 원치 않아요'라며 노트북을 살짝 열어둔 채로 내려놓기도 했습니다.
Tibo: 지금 모두가 노트북을 반쯤 닫은 채로 돌아다니고 있어요. '우리 지금 뭐 하는 거지?' 싶을 정도로요.
Vijaye: 제 생각에는... 솔직히 이제 소프트웨어를 구축하는 것이 더 재미있어졌다고 생각합니다. 왜냐하면 만족감의 주기가 훨씬 짧아졌기 때문입니다. 자신이 만들고 있는 제품을 보고, 테스트하고, 검증한 다음 다시 코덱스로 돌아가는 과정이 정말 멋집니다.
Gergely: 엔지니어들 입장에서, 지금 막 나타나기 시작한 새롭고 다르거나 이상한 엔지니어링 관행에는 어떤 것들이 있나요? 이상하긴 하지만 이치에 맞기 시작하는 것들 말이죠.
Tibo: 예전에는 까다로운 기술적 트레이드오프가 있으면 디자인 문서를 작성하고, 그것에 대해 토론하고, '다른 실행 가능한 대안은 무엇인가?' 고민한 뒤 하나를 폐기하곤 했습니다. 이제 정말 즐거운 점은 사람들이 여러 개의 다른 구현을 병렬로 탐색하는 것을 본다는 것입니다. 그런 다음 가장 잘 작동하는 것으로 입증된 것에 집중할 수 있습니다.
제가 보는 또 다른 점은 규칙(역할)의 경계가 모호해진다는 것입니다. 예를 들어, 우리 디자이너들은 6개월 전의 엔지니어들보다 더 많은 코드를 배포하고 있습니다. 이는 모델들이 충분히 좋아져서 그들이 생산하는 코드가 우리가 그대로 병합(merge)하고 싶을 정도의 코드이기 때문입니다.
Gergely: 비제이, OpenAI 전체적으로 다른 의견이 있나요?
Vijaye: 제가 알아챈 건... 여러분 모두가 사용하는 커맨드 라인 도구들의 명령어들을 전부 다 기억하시나요? 저는 아닙니다. 티보 팀과 이야기하다 보면 비디오 파일을 편집하는데, FFmpeg을 아신다면, 그 커맨드 라인을 기억하는 사람은 아무도 없을 겁니다. 코덱스는 '내가 이걸 하고 싶은데'라고 말하면 커맨드 라인을 만들어주고 그걸 실행할 수 있게 해주는 아주 훌륭한 도구입니다. 그래서 이런 것들이 우리가 사람들이 코덱스를 구체적으로 사용하는 방식에서 새롭게 보고 있는 부분입니다.
또한 이제 우리는 단순한 코딩을 넘어서 코드 리뷰, 보안 리뷰로 넘어갔다고 생각합니다. 그리고 티보가 말했듯이 더 많은 병목 현상을 발견하게 될 겁니다. 예를 들어 코딩 문제를 해결하고 나면, 이제 모든 엔지니어의 생산성을 5배 높였으니 무슨 일이 일어날까요? 더 많은 코드가 작성될 것이고, 이는 코드 리뷰가 병목 현상이 된다는 뜻입니다. 코드 리뷰 이후에는 통합(integration)과 배포, CI/CD가 병목 현상이 될 것입니다. 그래서 우리는 끊임없이 다음 문제들을 해결하러 가야 합니다. 이 점이 실제로 꽤 흥미롭습니다.
Gergely: 그리고 티보, 우리가 코덱스에서 하고 있는 작업에 대해 이야기할 때 제가 한 번도 들어본 적 없는 정말 흥미로운 점은, 이 '오버나이트 런(overnight runs, 밤샘 작업)'과 셀프 테스팅(self-testing)입니다. 그것에 대해 말씀해 주실 수 있나요? 그건 완전히 새로운 것이니까요.
Tibo: 이걸 단순히 '강력한 자동완성(autocomplete on steroids)' 정도로만 갇혀 생각하기 쉽습니다. 그냥 작은 기능을 구현해 주고, 10분 만에 끝날 거라고 생각하죠. 하지만 우리가 보고 있는 것은 모델이 훨씬, 훨씬 더 유능하다는 것입니다. 아주 큰 작업을 주면 여러 시간 동안 실행할 수 있습니다. 그래서 우리는 환경과 기술들을 조합해서 코덱스가 완전히 자율적으로 스스로를 테스트할 수 있게 만들었습니다. 우리는 이것을 밤새 실행해서 기본적으로 루프(loop) 속에서 QA를 수행하고 회귀(regression) 오류를 찾아내도록 합니다.
또 다른 것은, 실제로 모델을 훈련시키는 팀의 한 연구원과 계속 이야기를 나눴는데, 그는 '매번 내가 코덱스보다 낫다고 생각하다가도, 내가 틀렸고 프롬프트를 제대로 입력하지 않았거나 설정을 제대로 하지 않았다는 걸 깨닫는다'고 하더군요. 이것은 흥미로우면서도 동시에 약간 우울해지는 부분입니다. 왜냐하면 그는 '이제 완전히 독립적으로 모델을 훈련시키고, 끝에는 자체적인 통찰력과 결과가 담긴 작은 PDF 보고서를 작성하게 한다'고 말하기 때문입니다. 그런 다음 우리는 그것을 받아서 가장 유망한 것들을 찾아 반복하고, 다시 코덱스에 집어넣습니다. 그래서 이런 매우 매우 길게 실행되는 작업과 성과들을... 모델이 이렇게 독립적으로 해내는 것을 보는 것은 정말 놀랍습니다.
Gergely: 그리고 우리가 이야기했던 것 중 공상과학(sci-fi) 소설처럼 느껴졌던 또 다른 점은, 가끔 코덱스에 대한 회의나 문제에 대한 회의를 할 때, 사람들이 회의실에 모여서 코덱스로 진단하기 위해 코덱스 스레드(threads)를 실행시킨다고 하셨죠. 그게 어떻게 진행되는지 조금 말씀해 주실 수 있나요? 그건 정말 그 자체로 하나의 루프(loop) 같으니까요.
Tibo: 우리가 하는 큰 일이 두 가지 있습니다. 우리는 매주 분석 리뷰를 하는데, 기능 채택, 유지(retention), 퍼널(funnel) 분석 등을 검토합니다. 그리고 항상 회의를 시작할 때 대시보드에 답변이 없거나 아직 살펴보지 않은 질문들을 제기합니다. '오, 이거 흥미로워 보이네요.' 그러면 데이터 분석가가 그냥 '좋아요, 백그라운드에서 코덱스 스레드를 하나 실행시킵시다. 20분 후에 돌아올 거고, 회의 마지막 10분 동안 그 답변에 대해 이야기할 수 있을 겁니다'라고 합니다. 그리고 방에 있는 사람들이 가진 5~6개의 질문에 대해 그렇게 합니다. 백그라운드에서 이 작은 컨설턴트들이 우리를 위해 일하고 있는 이 마법 같은 경험이죠.
또 다른 하나는 SEV(심각한 장애/사고) 상황입니다. 당직 때 호출을 받으면, 코덱스가 무엇이 잘못되었는지, 복구를 위한 가장 빠른 경로가 무엇인지 파악하는 데 도움을 줍니다. 그래서 모든 것이 훨씬 가속화되고 우리가 수집할 수 있는 정보의 양과 문제를 해결할 수 있는 속도가 엄청납니다.
Gergely: 이건 한편으로는 절대적으로 상황을 가속시키고 있으며, 다른 곳에서도 이런 현상을 보고 있습니다. 업계 전반에서 계속 제기되는 큰 질문 중 하나는 '신입 졸업생은 어떻게 되나? 주니어 엔지니어들은 어떻게 되나?'입니다. 제가 OpenAI의 엔지니어링 책임자와 이야기했을 때, 그는 초기 경력(early career) 엔지니어들을 채용하고 있다는 흥미로운 말을 했습니다. 그것에 대해 조금 말씀해 주실 수 있나요? 정말 듣기 좋은 소식이거든요. 상황이 어떻게 진행되고 있는지, 그들에게서 무엇을 보고 있는지, 시니어들이 이제 AI 에이전트를 사용할 수 있어서 주니어들이 별로 좋지 않을 것이라는 두려움은 얼마나 근거가 있는지, 그리고 그들은 어떻게 업무 속도를 따라잡고 있는지 말씀해 주시겠어요?
Vijaye: 우리는 대학에서 갓 졸업한 신입들을 많이 채용하고 있습니다. 올해에는 꽤 탄탄한 인턴십 프로그램도 운영하고 있습니다. 저는 새롭게 탄생하는 새로운 소프트웨어 엔지니어들이 'AI 네이티브(AI-native)'가 될 것이라고 진심으로 믿습니다. 그들은 이 도구들을 자연스럽게 알게 될 것이고, 첫날부터 우리의 AI 도구들을 활용할 수 있을 것입니다. 그리고 그들에게 기회를 주는 것은 아주 중요하고 결정적이며, 이런 환경에서 그들을 성장시키는 것은 놀라운 일이 될 것입니다.
저는 이것이 정말 기대됩니다. 이번 여름이 OpenAI에 들어올 첫 번째 신입 졸업생 배치(batch)가 될 텐데, 약 100명 정도 될 겁니다. 정말 기대하고 있습니다. 그리고 OpenAI 내부의 인턴십 프로그램을 계속 성장시키고 싶습니다. 그래서 이 시대에 이런 모습을 목격하는 것은 정말 멋진 일이 될 것입니다.
Gergely: 그리고 티보, 구체적으로 코덱스 팀에는 사람들을 어떻게 온보딩하고 있나요? OpenAI 내부에서조차 제 느낌으로는 코덱스 팀이 여러분이 일하는 방식에서 몇 달이나 몇 주 정도 앞서 있는 것 같습니다. 외부에서나 심지어 OpenAI 내부에서 새로운 사람이 오면, 팀의 작업 방식에 어떻게 적응시키나요?
Tibo: 저는 팀을 매우 수평적인 조직으로 운영하고 있습니다. 저에게 직접 보고하는 직원이 33명인데, 그들은 뛰어다니며 멋진 일들을 해냅니다. 제가 병목이 되고 싶지 않거든요. 리더로서, 사람들이 실제로 얼마나 빨리 무언가를 구축할 수 있는지에 맞춰 조직 구조를 충분히 빠르게 바꾸지 않는 것은 매우 유혹에 빠지기 쉬운 일입니다. 모든 단일 결정에 한 사람이 병목이 되는 것은 더 이상 작동하지 않음이 분명합니다.
하지만 사람들이 처음 소개받는 것은 당연히 코덱스 자체입니다. 온보딩은 코덱스가 담당합니다. 그냥 코덱스에게 질문을 하고, 코드베이스를 탐색하고, 다른 사람들이 무엇을 하고 있는지 이해하고, 일일 보고서를 받습니다. 하지만 온보딩을 담당하고 우리가 구축하는 문화와 방식을 책임지는 사람들은 가장 최근에 팀에 합류한 사람들입니다.
신입 직원에 대해 이야기하자면, 6개월 전에 팀에 합류해 아주 엄청난 활약을 보여주는 신입 직원이 한 명 있습니다. 처음엔 좀 놀랐지만, 이 친구가 저보다 훨씬 더 무한한 에너지를 가지고 있다는 걸 이해하게 되었습니다. 아주아주 빠르죠. 제 뇌는 이미 쇠퇴기에 접어들었을지 모르지만, 이 친구의 뇌는 완전 최정점에 있습니다. 정말 경이로운 사람이고 팀에서 너무나 성공적이었습니다. 이런 모습을 보는 건 정말 즐거운 일입니다.
Gergely: 약간 악마의 변호인(반대 의견) 역할을 해볼게요. 우리 중 경험이 더 많은 사람들은 신입 졸업생들이 아주 성공적인 전문가로 성장하는 것을 보아왔습니다. 그리고 최소한 지금까지는 기초(foundations)가 매우 중요했다는 것을 보았습니다. 신입 졸업생들의 기초가 AI 코딩을 사용하고 우리가 10~20년 이상 해왔던 것들을 건너뛴 상태라면, 어떤 일이 일어날 것이라고 생각하시나요? 그들이 올바른 기초를 쌓고 있는 걸까요? 아니면 우리가 여기서 올바른 질문을 던지고 있는 걸까요?
Tibo: 기초는 여전히 매우 중요합니다. 우리는 전체 코드베이스를 설계하고 전반적인 아키텍처를 관리하는 데 큰 주의를 기울이고 있습니다. 코드 리뷰도 합니다. 당신이 말했듯이, 코덱스가 모든 것을 작성하게 내버려두고 눈을 감은 채 '다 잘 될 거야'라고 하지는 않습니다. 우리에게는 이 작업에 참여하는 최고 수준의 엔지니어들도 있습니다. 하지만 신입들이 이를 잘 흡수할 수 있다는 것을 발견했습니다. 코드베이스에 대한 올바른 구조가 있고 올바른 가이드라인을 설정한다면, 그들은 엄청나게 생산적일 수 있습니다. 그래서 저는 그것이 설정하는 환경과 이런 코드베이스가 어떻게 진화할 것인지 미리 생각하는 것에 달려있다고 생각합니다.
Gergely: 비제이, 6개월이나 8개월 전과 비교해서 소프트웨어 엔지니어의 역할은 어떻게 변하고 있나요? 만약 당신이 새로 입사한 사람에게 '비제이, 제가 매일 무슨 일을 하게 되나요?'라는 질문을 받는다면, 그들은 무엇을 하게 될까요?
Vijaye: 기초에 대한 아이디어, 기초는 결코 유행에 뒤떨어지지 않을 것입니다. 그것은 무슨 일이 있어도 항상 중요할 것입니다. 우리 모두가 튼튼한 기초를 가지고 있기 때문에 이 자리에 있는 것입니다. 그리고 소프트웨어 엔지니어의 역할 측면에서 보면, 꽤 많이 변했습니다. 제 나이가 드러날 수도 있지만, 업계에 25년 동안 있으면서 정말 많은 패러다임의 변화를 보았습니다. 저는 마이크로소프트에서 개발자 도구 작업을 했고, Visual Studio와 언어 서비스용 편집기를 만들었습니다. 그래서 인텔리센스(IntelliSense)를 처음 봤을 때, 타자를 치고 점(dot)을 누르면 옵션이 나타나는 그 순간은 정말 멋진 순간이었습니다.
하지만 기억하시나요? 제가 그 무렵 업계에 합류했을 때 주변 개발자들은 '어셈블리를 작성하지 않으면 넌 좋은 소프트웨어 엔지니어가 아니야'라고 말했었습니다. 맞습니다. 제가 본 것들이 이렇습니다. 아마 제가 입사하기 전에는 사람들이 '어셈블리를 작성하지 않으면 좋은 소프트웨어 엔지니어가 아니다'라고 했을 것이고, 그다음엔 C++, 그다음엔 추상화가 계속 올라갔고, 사람들은 자바스크립트에 대해 불평하곤 했습니다. 그런 시절 기억하시죠?
저는 그런 것들이 실제로 중요하다고 생각하지 않습니다. 중요한 것은 강력한 기초가 있고, 제품에 대한 직관이 있으며, 자신이 무엇을 만들고 있는지 알고, 문제를 해결하기 위해 스택의 위아래로 내려갈 수 있는 능력입니다. 그런 것들이 더 중요한 것들이며, 그런 것들은 결코 유행에 뒤떨어지지 않을 것입니다. 저는 항상 그럴 것이라고 느낍니다.
Gergely: 여기에는 대부분 엔지니어와 엔지니어링 리더들이 모여 있지만, 제품 관리자(PM)와 디자이너들에 대해서도 잠시 생각해 보죠. 특히 엔지니어들과 그들 모두가 훨씬 더 빠르게 기능을 구축할 수 있게 된 지금, 그들의 역할이 어떻게 변하고 있다고 보시나요? 그들의 역할이 변하고 있나요? 가까워지고 있나요, 아니면 여러분이 보는 관점에서 여전히 뚜렷하게 구분된 역할을 가지고 있나요?
Vijaye: 우리가 인간이 사용할 제품을 만드는 한, 우리는 인간 디자이너와 인간 제품 관리자가 필요할 것입니다. 제품 감각이나 디자인 감각을 대체할 수 있는 것은 없다고 생각합니다. 이러한 것들은 진화할 것이고, 훨씬 더 생산적이 될 것이며, 훨씬 더 많은 추상화가 이루어지겠지만, 우리는 계속해서 그것을 진화시킬 것입니다. 그들은 갈수록 점점 더 생산적이 되고 있습니다. 제품 관리자들은 코드를 작성하고 있고, 디자이너들도 코드를 작성하고 있습니다. 그들은 디자인을 가져와 제품으로, 프로토타입으로 만들고 검증한 뒤 엔지니어에게 가져옵니다. 그래서 이런 부분들이 이미 훨씬 더 생산적으로 변하고 있습니다.
제품 관리자들은 또한 코덱스를 사용하여 파워포인트 슬라이드를 만들고, 엑셀 플러그인을 다루는 등, 전방위적으로 엔지니어뿐만 아니라 주변의 모든 사람들이 더 생산적으로 변하고 있습니다.
Gergely: 오픈AI 내부에서 하고 있는 멋진 일 중 하나로 제가 들은 것은 지식 공유(knowledge sharing), 즉 '보여주며 설명하기(show and tell)'입니다. 팀들이 자신들이 하는 일을 보여주죠. 그 아이디어를 어떻게 생각하게 되었는지, 역학(mechanics)은 어떻게 사용하는지, 그리고 다른 팀들이 채택하는 것을 본 멋진 것들에 대해 말씀해 주실 수 있나요?
Tibo: 흥미로운 부분은 우리도 기술을 발견하고 그것에 맞춰 함께 진화하고 있다는 것입니다. 마치 여러분 모두가 '오, AI가 나를 위해 무엇을 할 수 있지?', '이게 조직을 위해, 혹은 내 프로젝트를 위해 무슨 의미일까?'를 발견하는 것처럼, 우리도 거의 동시에 그것을 발견하고 있습니다. 작동하기 시작하는 느낌이 드는 무언가가 있으면 세상에 배포하죠. 그래서 우리는 아주 짧은 시간 동안 여러분보다 조금 더 미래를 보는 눈을 가지고 있는 셈입니다.
좋은 아이디어가 조직 전체에 매우 빠르게 퍼지는 것이 아주 중요합니다. 그래서 우리는 슬랙(Slack)을 사용하고, 코덱스 슬랙 채널들과 '핫 팁(hot tips)' 같은 채널들이 매우 활발하게 운영됩니다. 그리고 정기적인 해커톤, 'show and tell'을 조직합니다. 우리는 가능한 한 빨리 AI와 함께 일하는 새로운 방법을 전파하려고 노력하며, 이는 매우 창의적인 시기입니다. 이 도구들을 사용하는 단 하나의 정답은 없고, 아직은 발견하는 단계에 있습니다.
그리고 우리에게는 코덱스를 담당하는 아주 훌륭한 제품 관리자인 알렉산더 엠버리코스가 있습니다. 그는 코덱스 팀 전체를 담당하는 유일한 PM인데, 코덱스의 도움을 받아 자신을 극대화(hyper-leverage)합니다. 며칠 전에 그는 버그 배시(bug bash)를 조직했는데, 한 시간 동안 사람들이 출시 예정인 기능들을 살펴봤습니다. 그런 다음 코덱스를 시켜 모든 사람의 피드백을 수집하게 했고, 노션(Notion) 문서로 정리했습니다. 그러고는 코덱스에 명령을 내려 기능 개선 사항, 버그 리포트 등을 Linear 티켓으로 등록하게 하고 모든 사람에게 할당한 다음, 진행 상황에 대해 후속 조치를 취하게 했습니다. 그는 이렇게 AI를 활용하여 10배, 50배의 PM이 되어가고 있습니다.
다시 병목 현상에 대해 말씀드리자면, 제품 관리자가 병목이 되어서는 안 되기 때문에 계속해서 그 부분을 확인해야 합니다. 그것을 원칙적인 방법으로 살펴봐야 합니다.
Vijaye: 한 가지 덧붙이자면, 저도 이 '데모 데이(demo days)'에 가봤는데 정말 많은 프로젝트가 시연되는 것을 보았습니다. 이런 해커톤에 가서 데모를 볼 때 제가 느끼는 점 한 가지는 데모의 '깊이(depth)'가 지속적으로 깊어지고 있다는 것입니다. 단순히 겉핥기식으로 '여기 가능한 것이 있습니다'가 아닙니다. 이 데모들 중 일부는 '여기 가능한 것이 있고, 게다가 이 모든 코너 케이스(예외 상황)까지 처리했습니다'라는 식입니다. 실제로 매우 사용 가능한 제품인 것이죠. 그래서 사람들이 구축하는 모든 제품의 깊이가 매일매일 더 깊어지는 것은 분명하고, 이런 기능의 일부를 뽐내는 것조차 정말 흥미롭습니다.
Gergely: 우리가 덧붙여야 할 한 가지 면책 조항(disclaimer)은, OpenAI 내부에서는 모든 사람이 무제한 토큰에 접근할 수 있고 비용이 없다는 것입니다. (웃음) 사람들도 웃고 있는데, 그게 꽤 중요한 부분이니까요. 외부 세계에서는 비용이 여전히 문제이고, 최대 구독량(max subscription)에 도달하면 크레딧을 사야 하죠. 창업자들을 포함해 어떤 사람들은 괜찮다고 생각하지만, 가끔 사람들은 비용에 대해 질문합니다. 많은 곳이 현실적인 이유로 비용의 제약을 받고 있다는 점을 염두에 둘 때, 팀의 작업 방식에서 영감을 받았지만 이런 제약/수갑을 차고 있는 사람들에게 어떤 제안이나 전술을 조언해 주시겠습니까?
Vijaye: 비용은 저희도 끊임없이 생각하는 부분입니다. 하나는 당연히 우리 모델들을 점점 더 유능하게 만들어서 사용자들에게 제공하고 싶다는 것입니다. 저는 또 언젠가는 생각의 전환이 일어날 것이라고 믿습니다. 지금 여러분에게 연중무휴 24시간 일하는 '팀원'이 있다고 상상해 보세요. 여러분은 그 팀원에게 Linear 작업이나 Jira 작업을 할당하고 그 팀원이 그 일들을 처리할 수 있을 것으로 충분히 기대할 수 있습니다. 그렇다면 질문은 '몇 개의 토큰을 사용할 것인가'가 아니라 '이 팀원에게 얼마를 지불할 것인가'가 됩니다.
그래서 모든 엔지니어가 4~5명의 이 (AI) 팀원들로 구성된 팀을 가졌을 때의 생산성 측면에서 측정하기 시작하면 훨씬 더 이치에 맞기 시작합니다. 물론 우리도 이 에이전트들을 팀원으로 대우할 수 있을 만큼 훨씬 더 유능하게 만들어야 할 책임이 있고, 그것이 바로 우리가 지금 작업하고 있는 부분입니다.
Tibo: 그것이 회사 전반에 걸쳐 어떻게 비용을 대체하는지에 대해 생각해보는 것도 유용하다고 생각합니다. 이제는 아주 저렴하게 할 수 있는 일들이 있습니다. 마케팅 조사를 하거나, 전체 기능 백로그를 검토하고 사소하게 구현할 수 있는 것들을 파악하는 일 등이죠. 예전에는 15명의 엔지니어를 투입해서 백로그를 살펴봐야 했겠지만, 이제는 거의 무료입니다. 당연히 모든 직원이 무제한 추론(인퍼런스) 혜택을 제공받을 수는 없겠지만, 저는 그것을 조기에 제한하는 것은 위험하다고 생각합니다. 우리는 아직 사람들이 얼마나 잘 활용할 수 있는지 아주아주 초기 단계에 있으니까요. 그래서 저는 분명히 '회사에서 가장 우수한 사람들에게 편안하게 사용할 수 있는 아주 많은 양의 추론 환경을 제공하라'고 말할 것입니다.
Gergely: 변화의 속도를 되돌아보면, 속도가 빠르고 또 아주 빠르게 빨라지고 있다는 느낌이 듭니다. OpenAI 이전의 시간을 되돌아볼 때, 비제이 당신은 이 업계에 오랫동안, 25년 이상 있었습니다. 과거를 돌아봤을 때 변화가 이렇게 빠르다고 느꼈던 때가 있었나요? 과거에 이와 비교할 만한 것이 있었나요?
Vijaye: 이런 건 본 적이 없는 것 같습니다. 25년 동안 대학 시절의 닷컴 버블 붕괴, Y2K, 모바일 혁명, 그리고 제가 속해있던 소셜 네트워크 혁명을 보았지만, 이번 건은 매우 다르게 느껴집니다. 대규모로 일어나고 있을 뿐만 아니라 매우 빠르게 일어나고 있습니다. 이것이 일어나는 속도 때문에 차트 중 일부는 말이 안 될 정도입니다. 그래서 저는 이것이 매우 특별하고 독특한 것이라고 생각합니다. 그리고 이 시대를 살아가고 있다는 것 자체도 멋진 일입니다.
Gergely: 마지막 질문입니다. 아주 빠르게 변하고 있지만, 두 분은 꽤 오랫동안 OpenAI에 계셨습니다. 그래서 솔직한 예측을 하나 부탁드리겠습니다. 여러분이 아는 한, 2년 후의 소프트웨어 엔지니어링과 엔지니어링 관리는 어떤 모습일 것이라고 생각하시나요?
Tibo: 분명히 2년은 너무 긴 기간입니다. (웃음) 6개월 후를 말씀드리자면, 제가 아주 확신 있게 말할 수 있는 것들은 이렇습니다. 속도 면에서 또 다른 차원의 도약이 있을 것이고 그것은 상황을 다시 바꿀 것입니다. 우리가 해낼 또 다른 것은 매우 큰 목표를 위해 협력할 수 있는 다중 에이전트(multi-agent)의 대규모 네트워크입니다. 예를 들어, 같은 팀 안에서 커서(Cursor)가 처음부터 브라우저를 다시 만드는 것을 시연했던 것과 같이 실행 가능한 영역이 될 것입니다. '자, 시작해'라고 하고 24시간 후에 2백만 줄의 코드로 만들어진 결과물을 얻게 되는 거죠.
이런 것들은 그 속에서 실제로 무슨 일이 일어나는지 이해하기가 거의 불가능할 정도로 복잡할 것입니다. 그래서 여기서 우리가 보게 될 것은 빌드되는 것에 대한 가드레일을 설정하여 더 이상 코드를 볼 필요가 없게 만드는 것입니다. 증명하거나 제약을 두는 방식을 통해 코드가 안전하다는 것을 알고 입력과 출력만 보면 되는 것이죠. 코드는 더 추상화될 것이고, 시스템의 실제 과제와 속성에 대한 모든 것이 될 것입니다.
저는 미래에는 여러분이 그냥 비서를 부르고, 작업을 확인하게 될 것이라고 생각합니다. 여러분을 위해 일하는 모든 AI 에이전트들의 작업을 대표할 수 있는 전담 개인 비서가 하나 있어서, 백그라운드에서 생산적으로 일하게 될 것입니다. 100개나 200개의 개별적인 작은 에이전트들을 모니터링하고 일일이 확인하는 대신에요. 올해 안으로 이런 것들을 아주 빠르게 보게 될 것이라고 생각합니다.
Gergely: 비제이, 그리고 티보, 정말 감사합니다. 내부에서 실제로 무슨 일이 일어나고 있는지, 팀이 어떻게 일하고 있는지 보여주셔서 감사합니다. 몇 달, 몇 주, 혹은 그보다 더 앞서 나가고 있는 느낌이 들지만, 분명히 현실로 일어나고 있는 일입니다. 그리고 이 정말 흥미로운 시기에 우리가 무엇을 보게 될지, 혹은 보지 못할지에 대해서도요. 정말 감사합니다.
Vijaye & Tibo: 감사합니다.
큰 목표를 위해 협력할 수 있는 다중 에이전트(multi-agent)의 대규모 네트워크입니다. 이거 그록이 하고 있는거 아닌가? 똑똑한 에이전트가 하면 또 다를려나
완전히 자율적으로 작동하는 수 백만의 폰 노이만보다 강력한 에이전트들을 생각해야하셈
만약 그렇다면 사회 혼란이 야기됨 정부가 어떻게 해쳐나갈지 걱정
정부는 해결 못할거셈
초지능 주도로 사회혼란을 해결하게 될 거셈
자율화된 초지능이 어서 나와야함 한 수 배워 가겠음
사실은 싹다 준비돼있을거 같셈.. 그리고 생각보다 한방에 뒤집어질거같셈.. 그리고 사람들은 걱정이 무색할만큼 금방 적응할거같셈
이거 ㄹㅇ 개기대된다 6개월 뒤 ㄷㄷ
대충 인턴 연구원 타임라인 언저리네