앤드류 응은 요즘 휴대폰으로 코딩을 합니다. 구글 브레인을 만들고, 코세라(Coursera)를 공동 창업하고, 딥러닝닷에이아이(DeepLearning.AI)로 전 세계 수백만 명에게 AI를 가르친 그 사람이요.
작년 랭체인(LangChain) 컨퍼런스 '인터럽트'에서 그가 나눈 대담은 유튜브에서 가장 많이 본 세션이었고, 올해 그는 1년 만에 같은 무대에 돌아왔습니다. 그 사이 그는 포춘 500 대기업의 AI 전략을 자문하는 회사를 차렸고, 동시에 1~10명짜리 초소형 팀들을 직접 돌리고 있었어요.
그가 양쪽 현장에서 공통으로 목격한 건 하나입니다. 코딩이 빨라질수록 병목은 코딩 바깥에서 생긴다는 것.
코딩 에이전트, 예상보다 빨랐다
Q. 1년 만에 다시 뵙습니다. 그 사이 AI 업계에서 예상을 빗나간 것, 그리고 예상보다 빨랐던 것은 뭐였나요?
과대광고는 제 예상을 넘어섰어요. 그리고 아쉽게도 비관적인 종말론 서사도 예상보다 힘을 얻었죠. '일자리 대멸종' 같은 얘기요. 저는 그런 일은 일어나지 않을 거라고 봅니다.
긍정적인 쪽에서는 코딩 에이전트가 예상보다 빨리 자리 잡았어요. "AI는 몇 달마다 모든 게 바뀐다"는 말이 전부 사실은 아니지만, 코딩 에이전트만큼은 정말 그렇습니다. 6개월 전에 저는 거의 클로드 코드만 썼는데, 요즘은 여전히 클로드 코드를 많이 쓰면서도 오픈AI 코덱스 비중이 점점 늘고, 제미나이 CLI도 섞어 쓰고, 오픈코드(OpenCode)도 지원하고 싶어요. 오픈소스니까요. 어떤 조합의 코딩 에이전트를 쓰는지가 이렇게 빠르게 바뀌고 있습니다.
1년 전에는 제가 휴대폰으로 이렇게 코딩을 많이 하게 될 줄도 몰랐어요. 여기 계신 많은 분들처럼 저도 사무실에 맥 미니를 두고 있고요. 이런 워크플로우 전체가 빠르게 바뀌는 중입니다. 그리고 에이전틱 워크플로우가 기업 안으로 본격적으로 들어가기 시작했다는 것도 좋은 신호고요.
나머지 전부가 병목이 된다
Q. 소프트웨어 얘기가 나온 김에 여쭤볼게요. 소프트웨어 엔지니어링의 미래는 어떤 모습일까요?
1년 전쯤 저는 '프로덕트 매니지먼트 병목'을 다룬 글을 썼어요. 만드는 속도가 훨씬 빨라지면, 프로젝트 범위를 잡고 고객 피드백을 받아 뭘 만들지 정하는 PM의 일이 병목이 된다는 이야기였죠. 지난 1년 동안 이 병목은 훨씬 심해졌습니다. 좋은 의미로요. 소프트웨어를 만드는 속도가 그만큼 빨라졌으니까요.
그런데 소프트웨어 작성이 10배, 100배 빨라지니 PM만 병목이 되는 게 아니더라고요. 사실상 나머지 전부가 병목이 됩니다. 제 팀 몇 곳은 마케팅 병목을 겪고 있어요. 기능을 하도 많이 만들어내니까, 마케터들이 "엔지니어들이 대체 뭘 만든 거지"부터 파악해서 어떻게 알릴지 정리하느라 허덕이는 거죠.
이미지 출처 : @AndrewYNg, X
법무 검토가 필요한 제품도 그래요. 예전에는 제품 하나 만드는 데 석 달이 걸렸으니 법무 승인에 일주일 기다리는 게 괜찮았어요. 그런데 이제 하루 만에 만드는데 승인에 일주일이 걸리면, 그게 법무·컴플라이언스 병목입니다. 같은 논리로 디자인 병목도 생기고요.
Q. 그럼 팀은 어떻게 조직해야 하나요?
미래의 소프트웨어 엔지니어링 팀이 어떻게 조직될지, 정답을 안다고는 못 하겠어요. 다만 저는 점점 더 아주 작은 팀을 꾸리게 됩니다. 1명에서 10명 사이, 대부분 제너럴리스트로요. 맥락을 깊이 알고, 권한을 크게 위임받은 제너럴리스트들이죠. 아주 넓은 가드레일만 정해 주고, 그 안에서는 마음껏 달리면서 코드를 만들어 배포하게 합니다. 마케팅 카피 작성처럼 전통적으로 엔지니어링 바깥에 있던 결정까지 직접 하게 하고요.
이렇게 생각해 보세요. 어떤 팀에 소프트웨어 엔지니어링, 프로덕트 매니지먼트, 새 이용약관 작성, 마케팅 카피, 디자인까지 다섯 가지 기능이 필요한데 사람은 두 명뿐이라면? 그러면 한 사람이 두 가지 이상의 역할을 맡을 수밖에 없죠.
다행인 건 이거예요. 저는 마케팅을 잘하는 사람이 아니지만, AI를 쓰면(여전히 잘하는 건 아니어도) AI 없이 할 때보다는 덜 못하게 됩니다. 그래서 저는 깊은 기술 역량을 갖추고 있으면서, 최신 기술의 도움을 받아 다른 역할까지 조금씩 해내는 고맥락 제너럴리스트들의 작은 팀을 선호해요. 실제로 저희 엔지니어들은 AI로 이용약관 초안을 만들어서 변호사에게 가져갑니다. 변호사는 내보내기 전에 마지막 다듬기만 하고요. 이런 프로세스 덕분에 팀이 훨씬 빨리 움직입니다.
Q. 그런 역할에 맞는 배경은 뭘까요? 원래 엔지니어인가요, 아니면 다른 분야에서 와서 코딩을 처음 배우는 사람들인가요?
제가 가장 가까이 일하는 사람들 다수는 깊은 엔지니어링 전문성을 갖고 있어요. 거기에 더해 다른 역할로 발을 넓히면서, 훈련받은 적 없는 기술을 AI의 도움으로 익힌 사람들이죠.
하지만 어느 방향에서든 성공할 수 있다고 봅니다. 코딩이 훨씬 강해져서 이런 팀에 합류한 프로덕트 매니저도 봤어요. AI 코딩이 워낙 엔지니어에게 유리한 영역이라, 최전선 기술을 이해하는 데 유리한 엔지니어 출신이 이 역할을 제일 많이 맡고 있긴 합니다. 그래도 코딩을 꽤 효과적으로 배운 마케터도 봤고, 점점 더 많은 제품을 직접 만드는 오퍼레이션 담당자도 봤어요. 어떤 배경이든 배울 수 있는 일이라고 생각합니다. 지금은 엔지니어 출신의 머릿수가 제일 많을 뿐이에요. 배경이 뭐든, 이 역할을 해낼 수 있을지 꼭 시도해 보시길 권합니다.
레고 브릭과 에이전트용 스택오버플로우
Q. 이 새로운 소프트웨어 엔지니어링의 세계에 더 깊이 들어가고 싶은 사람들에게 어떤 조언을 하시겠어요? 써 볼 도구든, 가져야 할 마인드셋이든요.
제가 늘 떠올리는 멘털 모델이 하나 있어요. 지금은 AI 빌딩 블록을 제공하는 곳이 정말 많습니다. RAG든, 에이전트 프레임워크든, 평가(eval, AI 출력의 품질을 채점하는 체계)든, 가드레일이든요. AI가 아닌 빌딩 블록도 있죠. UI 컴포넌트, 로그인 인증, 프런트엔드·백엔드, 데이터베이스 같은 것들이요. 컴퓨터 과학에는 원래부터 훌륭한 빌딩 블록이 많았는데, 에이전트 코딩 시대가 되면서 오픈소스든 유료 API든 블록이 사방에서 쏟아지고 있어요.
레고로 비유하면 이렇습니다. 흰색 브릭 하나만 있으면 만들 수 있는 게 뻔해요. 그런데 검은색, 노란색, 갈색, 초록색 브릭에 구불구불한 특수 조각까지 섞이면, 만들 수 있는 것이 브릭 종류가 늘어날수록 기하급수적으로 늘어납니다. 지금 우리 주변의 빌딩 블록들이 딱 그래요. 그래서 충분히 많은 블록이 각각 뭘 하는지 감을 잡고 있는 개발자는, 그것들을 조합해서 소프트웨어를 엄청나게 빨리 만들어냅니다. 딥러닝닷에이아이도 수많은 회사가 내놓은 이 훌륭한 빌딩 블록들을 익히도록 돕는 짧은 강의를 많이 제공하고 있고요. 그다음 과제는 코딩 에이전트를 시켜서 이 블록들을 원하는 소프트웨어로 빠르게 조립하는 겁니다.
Q. 코딩 에이전트가 그 블록들을 조립할 때 걸리는 게 있다면요?
빌딩 블록이 너무 새것이라 코딩 에이전트가 쓸 줄 모른다는 문제가 있어요. 예를 들어 나노 바나나는 주요 모델들의 지식 컷오프(학습 데이터가 끝나는 시점) 이후에 나왔습니다. 그러니 최근까지도 주요 코딩 에이전트들은 나노 바나나 API를 호출할 줄 모르는 건 물론이고, 나노 바나나가 존재한다는 것 자체를 몰랐어요.
이미지 출처 : @AndrewYNg, X
그래서 제 친구 로힛 프라사드(Rohit Prasad)와 제가 공들여 온 프로젝트가 컨텍스트 허브(Context Hub)라는 도구입니다. 말하자면 'AI 에이전트를 위한 스택오버플로우'예요. 에이전트가 최신 API, SDK, 빌딩 블록의 문서를 받아 가고, 거꾸로 에이전트가 그 문서에 피드백을 줘서 모두를 위해 문서를 개선하는 곳이죠. 저도 문법이 잘 안 외워져서 살짝 성가신 API들이 있는데, 컨텍스트 허브로 최신 문서를 불러오게 했더니 코딩 에이전트가 그 API 호출을 전부 정확하게 해 주더라고요. 덕분에 제 코딩 작업이 꽤 빨라졌습니다.
강의가 아니라 대화
Q. 이 새로운 AI 세계에서 교육은 어떻게 바뀔까요? 딥러닝닷에이아이 강의에도 그런 변화를 반영하기 시작하셨나요?
두 가지로 나눠서 봐야 해요. 먼저 '무엇을 배울 것인가'는 확실히 크게 바뀌었습니다. 개발자라면 코딩 에이전트를 배워야 하고, 이 빌딩 블록들을 배워야 하고, 프로덕트 매니지먼트 같은 범용 기술까지 익혀야 더 효과적으로 일할 수 있죠. 딥러닝닷에이아이와 코세라는 그 훈련을 제공하려고 해 왔고요.
그런데 그것과 별개로 '어떻게 전달할 것인가', 즉 교육의 전달 방식이 있습니다. 학습이 어떻게 변할지 오래 고민해 왔는데, 솔직히 그 변화는 아직 진짜로 오지 않은 느낌이에요.
몇 주 전에 코드림(codream.ai)이라는 새 웹사이트를 프리뷰로 열었습니다. 비전은 이거예요. 온라인 강의를 수강하는 게 아니라, 와서 대화를 하라는 것. 강의가 아니라 대화입니다. 저와 시뮬레이션된 화상 통화를 하는 경험인데, 편하게 기대앉아서 제가 컨텍스트 허브나 코딩 에이전트에 대해 일대일로 설명하는 걸 듣고 싶으면 그냥 들으면 되고, 중간에 질문하고 싶으면 언제든 저를(정확히는 제 AI를) 끊고 물어볼 수 있어요. 그리고 제가 개인적으로 많이 실험한 게 하나 더 있는데, 영상과 슬라이드를 자바스크립트로 대체하는 겁니다. 시연 영상 안에 여러분이 직접 프롬프트를 입력해 볼 수 있게요.
Q. 영상 안에 직접 입력한다는 게, 지금 되는 건가요? 아니면 앞으로의 방향인가요?
이미 됩니다. 화상 통화에서 제가 화면 공유를 하는 게 아니라 '자바스크립트 공유'를 한다고 생각해 보세요. 시연 영역이 미리 녹화된 영상이 아니라 실제로 돌아가는 코드니까, 여러분이 그 안을 클릭해서 직접 프롬프트를 치고 쿼리를 넣어 볼 수 있습니다. 멈춰 있는 영상이 그냥 재생되는 게 아니라, 영상이 있던 자리가 인터랙티브해지는 거죠. 그만큼 사람들이 참여할 방법이 늘어나고요. 써 보시면 피드백을 주시면 좋겠어요. 솔직히 이 경험은 지금도 매일 다듬는 중입니다.
이미지 출처 : app.codream.ai
크게 보면 교육의 대전환은 과대평가돼 왔다고 생각해요. 뭔가 오고 있긴 한데, 온라인 강의보다 훨씬 나은 무언가가 있었으면 좋겠다는 게 지금 심정입니다. 그래도 10년 전 강의들보다는 확실히 좋아졌어요. 오늘 오전 AMD의 샤론 저우(Sharon Zhou)가 가르치는 트랜스포머 신규 강의를 열었는데, 10년 전처럼 영상만 나열하는 게 아니라 인터랙티브 시각화처럼 갖고 놀 거리를 훨씬 많이 넣었습니다. 다만 그보다 큰 전환은, 저도 계속 고민하는 중이에요.
천 개의 꽃은 피지 않았다
Q. 소프트웨어 엔지니어링에서 다른 영역으로 넘어가 보죠. 기업들의 AI 도입은 어떻게 보고 계세요?
여기 계신 분들 회사도 다들 AI 도입에 들떠 있을 거예요. 제 팀 중 하나인 AI 어스파이어(AI Aspire)는 제가 비즈니스 파트너 커스티 탄(Kirsty Tan)과 공동 설립한 AI 자문사인데, 포춘 50, 포춘 500, 글로벌 2000급 대기업들과 AI 전략과 전환을 늘 이야기합니다.
일관되게 보이는 흐름이 있어요. 다들 상향식 혁신, 그러니까 '천 개의 꽃이 피게 하라'는 식으로 현장에서 아이디어가 올라오게 하는 전략에 투자해 왔는데, 대부분은 성과로 이어지지 않고 있다는 겁니다. 그래서 CEO와 이사회가 묻기 시작했어요. "AI의 ROI(투자 대비 수익)는 어디 있느냐"고요.
상향식 혁신에는 계속 투자해야 한다고 생각해요. 다만 상향식 혁신은 대개 점 단위 솔루션, 그러니까 소소한 효율 개선에 그칩니다. 그것 자체는 좋은 일이에요. 하지만 AI가 우리에게 약속해 온, 그리고 우리가 실제로 만들어내야 할 더 큰 전환은 아니라는 거죠.
Q. 소소한 효율 개선과 큰 전환의 차이를 구체적으로 설명해 주신다면요?
은행 사례로 설명해 볼게요. 저희가 금융 쪽 일을 많이 해서, 여러 은행과 실제로 진행한 이야기입니다. 대출 심사 과정은 대략 다섯 단계예요. 대출 상품을 마케팅하고, 신청을 받고, 심사해서 승인하고, 최종 실사를 하고, 대출을 실행합니다.
여러 팀이 주목한 건 한가운데 있는 승인 단계였어요. 여기에 AI를 쓰면, 사람이 한 시간 들여 검토하던 신청서를 AI가 처리할 수 있다는 거죠. 훌륭합니다. 당연히 해야 해요. 그런데 대출 심사의 전체 프로세스는 그대로 두고 사람의 한 시간짜리 작업만 자동화하면, 그건 소소한 효율 개선에 그칩니다.
이미지 출처 : 나노바나나 제작
그래서 몇몇 은행이 이렇게 말했어요. "그 효율 개선도 할 만한 일이지만, 아예 워크플로우 전체를 다시 생각해서 '10분 안에 승인되는 대출' 상품을 만들어 팔자"고요. 사람이 한 시간 짬이 나기를 일주일씩 기다릴 필요 없이, 신청서가 들어오는 즉시 AI에게 보내 결정을 받으면 되니까요.
문제는 이걸 실행하려면 전체 워크플로우를 다시 설계할 수 있는, 권한 범위가 더 넓은 사람이 필요하다는 거예요. 이제 '10분 승인' 상품을 마케팅해야 하고, 신청서를 하루 뒤가 아니라 즉시 승인 단계로 보내야 하니 마케팅과 데이터 인프라가 관여해야 합니다. AI가 1차 결정을 내린 다음에는 최종 실사와 실행 쪽 처리 용량도 같이 키워야 하고요.
그래서 상향식 혁신은 아이디어를 많이 만들어내는 귀중한 것이지만, 이 모든 단계의 작동 방식을 바꿔서 성장을 만들어내려면 더 넓은 시야를 가진 탑다운 움직임이 보완돼야 합니다. 많은 기업이 비용 절감을 이야기하는데, 그것도 할 만하면 해야죠. 하지만 저는 AI로 할 수 있는 더 상상력 있는 일을 밀어붙이는 편이에요. 바로 성장입니다. 아낄 수 있는 돈에는 한계가 있지만, 성장에는 사실상 천장이 없거든요.
Q. 그렇게 성장을 만들어낸 사례 중에 눈여겨볼 만한 게 또 있을까요?
방금 말씀드린 은행 건이 실제 사례고요. 여러 금융기관, 그리고 다른 업종에서도 같은 일이 벌어지고 있습니다.
패턴을 하나 더 들자면 고객센터예요. 보통 비용 절감 대상으로 보는데, 물론 비용 절감도 좋습니다만, 고객 응대를 자동화하거나 일부라도 보강하면 훨씬 많은 고객을 훨씬 빨리 응대할 수 있게 돼요. 그게 더 만족스러운 고객 경험이 되고, 성장으로 이어집니다. 드라이브스루 음성 주문을 자동화하는 기업들과도 이야기해 봤는데, 이것도 고객 경험을 좋게 해서 성장을 만드는 사례라고 봐요.
이미지 출처 : @QSRmagazine, X
경제 곳곳에서 이런 사례가 점점 늘고 있습니다. 알고는 있지만 아직 말할 권한이 없는 것들도 있는데, 지금 기업들이 진행 중인 일들을 보면 이런 사례는 계속 더 나올 거라고 꽤 확신해요.
Q. ROI 얘기가 나왔는데요. 어제 오늘 행사장에서도 다들 고민하던 주제입니다. ROI 측정은 어떻게 접근하라고 조언하시겠어요?
저도 알았으면 좋겠네요. 기업이 워낙 다양해서, ROI를 측정하는 건 결국 '비즈니스를 측정하는 일'이고, 만능 답이 있기 어려워요.
다만 하나는 분명합니다. 저를 가장 설레게 하는 프로젝트들은 측정 가능하고, 측정해야 하고, 측정할 가치가 있어요. 그런데 어떤 프로젝트는 크게 승부를 걸어 만들어내는 가치가 워낙 커서, "2% 성장에서 구현 비용 1%를 빼면…" 같은 논쟁 자체가 필요 없습니다. 이게 사업을 바꾸고 있다는 게 눈에 훤히 보이니까요. 물론 상장사라면 그래도 측정은 해야겠지만요.
이미지 출처 : 나노바나나 제작
그리고 하나 배운 게 있어요. 때로는 점진적 개선이 전환적 개선보다 더 어렵습니다. 내년에 실적을 2% 올리라고 하면 사람들은 "그래, 2% 더 열심히 일하라는 거군" 하고 받아들여요. 그런데 20%, 50% 성장을 노리면 모두를 50% 더 열심히 일하게 만들 수는 없으니, 더 창의적인 해법을 찾아 나설 수밖에 없죠.
AI 어스파이어에서 배운 것도 있습니다. 기업들이 말 그대로 수백 개의 아이디어가 담긴 스프레드시트를 보내와요. 어떤 금융기관은 300개가 넘는 아이디어를 담은 시트를 보내면서, 이 중 어디에 진짜 자본을 투입할지 골라 달라고 했습니다.
그런데 이 분석이 정말 어렵습니다. 시트를 쓱 훑어보고 "이거랑 이거요"라고 짚어낼 만큼 제가 똑똑하면 좋겠지만, 그렇게는 안 되더군요. 아이디어가 그 정도로 많으면 상향식과 하향식 양쪽으로 다시 브레인스토밍을 해야 하고, 뭐가 기술적으로 가능한지 따지는 기술 분석과 어떤 게 의미 있는 변화를 만들지 따지는 사업 분석에도 상당한 품이 들어갑니다.
그렇게 소수의 베팅으로 좁히고 나서, 거기에 아주 의미 있는 자원을 싣는 거죠.
Q. 그렇게 크게 휘두르는 시도들은 결국 하향식에서 나오는 건가요?
맞아요. 다만 기업이 한 방의 홈런 스윙에 모든 걸 거는 게 아니라, 어느 하나만 터져도 사업에 의미가 있는 신중한 베팅 몇 개로 포트폴리오를 짜는 쪽이길 바랍니다.
이미지 출처 : @nikitabier, X
에이전트 코딩의 좋은 점 하나는 프로토타입 비용이 뚝 떨어졌다는 거예요. 그래서 실험을 정말 많이 돌리고, 시제품도 수시로 만듭니다. 하지만 10만 달러 예산으로 모든 걸 할 수는 없잖아요. 어느 시점에는 소수의 프로젝트 각각에 의미 있는 자원을 배분해야 하는데, 그 수준의 자원 배분에는 결국 하향식 의사결정이 좀 더 필요해집니다.
에이전트에게 먹일 데이터가 준비돼 있지 않다
Q. 에이전트를 만들기 전에 데이터 전략부터 제대로 잡아야 한다는 말이 요즘 많은데요. 데이터에 에이전트를 붙이려는 기업들은 지금 어디서 막히고 있나요?
좋은 질문이에요. 대기업들과 이야기할 때 아주 흔한 페인 포인트가 데이터 아키텍처를 다시 생각하는 일입니다. 지난 10~20년 동안 우리는 정형 데이터, 그러니까 테이블, 관계형 데이터, 스프레드시트를 정리하는 데 엄청난 공을 들였어요. 훌륭한 일이고 여전히 중요합니다. 그런데 이제 AI가 비정형 데이터(텍스트, 이미지, PDF, 오디오, 어쩌면 영상까지)를 처리할 수 있게 되면서, 이걸 정리해서 필요한 순간에 필요한 자리에서 AI나 에이전트에게 넘겨주는 일의 가치가 갑자기 훨씬 커졌어요.
솔직히 시장을 한참 들여다봤습니다. 비정형 데이터를 다루겠다는 벤더는 많은데, 제가 만족할 만한 단일 솔루션은 아직 못 찾았어요. 그래서 AI 펀드와 AI 어스파이어 안에서 우리 자신의 데이터를 재설계하는 실험을 이것저것 돌리고 있습니다. 잘 되면 그때 더 이야기하겠지만, 사내 비정형 데이터를 에이전트가 제때 쓸 수 있게 재구축하는 방법을 고민하는 데 시간을 많이 쓰고 있어요.
예전에 많은 기업이 대규모 데이터 아키텍처 프로젝트를 했던 것처럼, 앞으로 몇 년 동안 많은 기업에서 데이터를 'AI 레디', '에이전트 레디'로 만들기 위한 수천만 달러, 어쩌면 수억 달러짜리 프로젝트가 벌어질 거라고 봅니다.
Q. 기존 데이터 아키텍처의 어떤 점이 AI 레디가 아닌 건가요?
하나만 꼽기 어렵네요. 파편화, 거버넌스, 데이터가 사방에 흩어져 있는 것, 일관된 스키마가 없는 것, 일부는 누군가의 노트북에 들어 있는 것. 그리고 권한 체계가 사람 기준으로 설계돼 있지, 에이전트 기준이 아니라는 것도요. 에이전트가 내 권한을 그대로 물려받아야 하나? 거버넌스와 관측은 어떻게 관리하지? 이런 문제들이죠.
다들 보셨을 거예요. 수많은 기업에 지난 20년간 아무도 안 열어 본 PDF 파일 더미가 쌓여 있습니다. 금융권에서는 컴플라이언스 때문에 보관만 해 둔 문서가 많죠. 예전에는 아무도 그걸 들여다볼 시간이 없었으니 볼 이유도 없었어요. 하지만 AI가 볼 수 있게 그 데이터를 정리해 두는 건, 이제 정말 가치 있는 일이 됐습니다.
아, 데이터 아키텍처 전체 얘기와는 좀 다른데 작은 교훈 하나만 덧붙일게요. 저는 몽고DB(정해진 스키마 없이 데이터를 넣을 수 있는 NoSQL 데이터베이스)를 많이 씁니다. 다들 관계형 데이터베이스 좋아하잖아요. 그런데 빠르게 반복하며 프로토타입을 만들 때는, 스키마를 다시 설계하는 일이 어찌나 성가신지요.
이미지 출처 : @jasonlk, X
다들 한 번쯤 겪어 보셨을 거예요. AI에게 데이터베이스 마이그레이션을 시켰더니, 백 번에 한 번쯤 영리하게도 데이터베이스 전체를 지워 버리는 일이요. '거의' 안 일어난다는 게 '절대' 안 일어난다는 건 아니라서, 그게 좀 성가시죠.
그래서 저는 일단 어떤 데이터든 던져 넣고, 스키마는 데이터를 읽는 시점에 정합니다. 반복 속도가 훨씬 빨라져요. 물론 엔터프라이즈급 대규모 서비스에는 결국 관계형 데이터베이스를 쓰지만, 요즘 NoSQL은 사람들 생각보다 확장성이 좋습니다.
1년 넘는 계약은 하지 않는다
Q. 요즘 기업 AI 도입에서 많이 회자되는 게 FDE인데요. 모든 회사가 FDE를 두게 될까요? 왜 이렇게 임팩트가 큰 걸까요?
실리콘밸리에서 FDE(Forward Deployed Engineer)가 확실히 한창 주목받고 있죠. FDE는 좋은 아이디어라고 생각합니다.
다만 미래를 내다보면 이렇게 물어야 해요. 한 회사 안에서 FDE 대 그 회사가 직접 고용한 AI 엔지니어의 비율이 어떻게 될까? 대부분의 기업은 사내 엔지니어가 훨씬 많고, 거기에 소수의 FDE 팀이 파견돼 있는 구조가 될 겁니다. 그래서 저는 FDE가 좋고, 성장도 반갑고, 더 많은 사람이 FDE로 일자리를 얻으면 좋겠지만, 흔히 그렇듯 하이프가 실제보다는 좀 크다고 봐요.
이미지 출처 : @AndrewYNg, X
그래도 좋은 흐름입니다. 에이전틱 워크플로우를 만드는 건 어렵거든요. 비즈니스에 대한 이해가 필요하고, 고객을 상대하는 기술도 필요해요. 안정적으로 돌아가게 하려면 평가와 옵저버빌리티(시스템이 뭘 하고 있는지 들여다보는 관측 체계)를 붙여야 하고, 기술적으로 불가능한 요구에는 고객에게 안 된다고 말할 줄 알아야 하고, 어떤 워크플로우를 자동화할지 이해관계자들과 조율해야 하고, 변화 관리까지 도와야 합니다. 깊은 기술적 판단력이 필요한 값진 역할이고, FDE가 상주하면 프로젝트가 확실히 빨라져요.
Q. 그런데 우려하시는 지점도 있는 것 같네요.
많은 기업이 어려워하는 문제가 하나 있어요. '벤더 중립적인 FDE'를 구할 방법이 있느냐는 겁니다. FDE는 결국 특정 업체 소속이니까요.
이미지 출처 : interconnects.ai
지금 AI에서 보이는 현상은, 선두 AI 모델이 빠르게 바뀐다는 거예요. 1년 뒤 최고의 AI 모델이 뭘지 저는 전혀 모르겠습니다. 1년 뒤 최고의 코딩 에이전트가 뭘지도 전혀 확신이 없어요. 이렇게 불확실할 때는 선택의 여지를 남겨 두는 것이 아주 소중합니다.
Q. 그 선택의 여지를 지키기 위해 실제로 어떻게 하고 계세요?
솔직히 말해, 많은 벤더가 기업들을 찾아와 20~30% 할인을 제시하면서 3년 계약을 요구해요. 누구에게 조언하는 게 아니라 제가 어떻게 하는지만 말씀드리면, 저는 할인 폭이 얼마든 1년 넘는 계약은 거의 하지 않습니다. 지금은 알 수 없는, 1년 뒤에 가장 좋을 벤더와 일할 수 있는 선택지가 그만큼 소중하거든요.
FDE도 같은 질문에 부딪힙니다. 한 회사 소속 FDE 몇 명이 우리 회사에 들어와 모든 걸 그 회사의 AI 모델에 딱 붙여 놓으면, 1~2년 뒤 우리에게 남는 선택의 여지는 얼마나 줄어들까. 기업들이 지금 씨름하고 있는 질문이에요.
저는 랭스미스(LangSmith, 랭체인이 만든 LLM 앱 관측·평가 도구)를 여러 번 써 봤는데, 해리슨(랭체인 창업자 해리슨 체이스)이 정말 쓰기 쉽게 잘 만들었더라고요. 이렇게 벤더 중립적인 도구들이 장기적으로 선택의 여지를 지키는 데 큰 가치가 있다고 봅니다. 벤더는 훌륭해요. 같이 일하세요. 다만 자신을 위한 장기적 선택지도 함께 지키는 게 중요합니다.
Q. 벤더 중립 얘기가 나온 김에, 오픈소스 모델은 어떻게 보세요? 프런티어 모델(최전선의 최고 성능 모델)과 비교하면요?
흥미로운 건, 오픈 웨이트 모델(모델 내부 값인 가중치가 공개된 모델)이 프런티어 모델보다 꾸준히 6~9개월쯤 뒤처져 왔다는 거예요. 그런데 프런티어 모델은 꽤 비싸서, 많은 용례에서 제 팀들은 오픈 웨이트 모델을 많이 씁니다. 파인튜닝해서 쓸 때도 있고 그냥 쓸 때도 있어요. 그래서 우리 모두 오픈 웨이트 모델을 계속 지지했으면 합니다.
이미지 출처 : Epoch AI
지난 2주 사이 백악관에서 모델을 출시 전에 검사하겠다는 우려스러운 이야기가 나왔어요. 저는 이게 꽤 걱정돼서 행정부에 있는 친구 몇 명과 연락하고 있습니다. 어떤 때는 미·중 경쟁의 이름으로, 어떤 때는 사람들이 그때그때 만들어내는 논리로, 오픈소스·오픈 웨이트를 상대로 한 전쟁이 여전히 벌어지고 있다고 느껴요.
오픈소스와 오픈 웨이트를 지켜낼 수 있다면, 우리 모두가 선택의 여지를 지킬 수 있습니다. 그리고 세상은 훨씬 풍요로워집니다.
조쉬가 직접 운영하는 AI 솔로프리너 클럽에 초대합니다.
이미 300명이 넘는 분들이 ASC와 함께 성장하고 있습니다.
구글 엔지니어, 토스 PM, 산부인과 전문의, 스타트업 대표까지
— 각자의 자리에서 정상에 선 사람들이 지금 AI로 새로운 도전을 시작했습니다.
그리고 ASC 10기는 단 30명만 함께합니다.
아직 늦지 않았습니다.
지금 시작하는 당신이, 1년 뒤 가장 앞서 있을 솔로프리너입니다.
[👉🏻ASC 신청하러 가기]
의견을 남겨주세요