알겠습니다. 제공해주신 유튜브 영상 스크립트를 바탕으로, 일타강사 저스틴이 AI 에이전트 개발, 특히 브라우저 활용을 중심으로 강의하는 형식으로 재구성해 보겠습니다. 내용은 최대한 보존하고, 자연스럽게 읽히도록 편집하겠습니다.

저스틴 강사의 AI 에이전트 특강: 브라우저, 가능성과 현실 사이

자, 반갑습니다! 여러분의 AI 길잡이, 저스틴입니다. 오늘 녹화하는 날짜 기준으로 보면 곧 구글 I/O가 열흘 앞으로 다가왔네요. 벌써부터 구글이 엄청난 소식들을 준비하고 있다는 소문이 무성합니다. 그렇죠? 뭔가 예열하는 느낌이랄까요. 최근 윈드서프(Windscribe)가 30억 달러, 우리 돈으로 4조 원이 넘는 거액에 오픈AI에 인수되었다는 소식도 있었고요.

요즘 분위기를 보면, AI 모델 자체의 성능이나 발전보다는 이 모델들을 어떻게 활용할 것인가, 즉 애플리케이션과 에이전트 쪽으로 관심이 확 쏠리는 것 같아요. 이제 웬만한 모델들은 기본적인 성능은 다 갖췄다는 공감대가 형성된 거죠. “얼마나 더 싸고 빠르게 만들 수 있느냐?” 이게 핵심 질문이 됐고요. 자연스럽게 ‘에이전트’로 대표되는 애플리케이션 시장이 뜨겁게 달아오르고 있습니다. 저 역시 현업에서 에이전트 구현에 매일 씨름하고 있고, 여기 계신 승준님처럼 많은 분들이 이 분야를 탐구하고 계시죠. 지난 시간에 이어, 오늘도 이 에이전트, 특히 브라우저를 활용하는 에이전트에 대해 깊이 파고들어 봅시다.

최근 오픈AI가 인스타카트(Instacart) CEO였던 분을 영입해서 ‘애플리케이션 CEO’라는 자리까지 만들었다는 소식, 들으셨나요? 이건 “우리는 이제 본격적으로 애플리케이션 만들겠다!”는 선언이나 다름없습니다. 사업화로 빠르게 전환하려는 움직임이죠. 사실 지금 AI 분야에 뚜렷한 ‘해자(Moat)’가 있는 것도 아니니, 이렇게 기민하게 움직이는 게 중요합니다.

자, 요즘 클로드(Claude), 제미나이(Gemini), 챗GPT(ChatGPT) 같은 LLM들이 웹 URL만 던져줘도 내용을 요약하거나 번역해주는 기능, 많이들 써보셨을 겁니다. 물론 제미나이 앱은 아직 좀 약하긴 한데, 곧 좋아지겠죠. 덕분에 웹페이지 내용을 복사해서 붙여넣는 과정 하나가 사라졌어요. 물론 페이월(Paywall)이 있거나 저작권이 민감한 내용은 거부하기도 하지만요.

저는 이런 기능들을 활용해서 특정 글을 번역시키고, 그 내용에 대한 반응을 조사하거나, 제가 이전에 읽었던 다른 글들과 연결시키는 식으로 LLM을 훈련시키곤 합니다. 그러면 LLM에 내장된 웹 서치 기능, 이게 아주 ‘에이전트스럽게’ 작동해요. 웹을 탐색해서 필요한 정보를 컨텍스트에 넣고 작업을 수행하는 거죠.

이런 에이전트적인 능력을 극단적으로 보여주는 예시가 바로 **지오게싱(GeoGuessing)**입니다. GPT-4o가 나왔을 때 사진만 보고 위치를 맞추는 능력으로 화제가 됐었죠. 저도 깊게 파고들진 않았었는데, 최근 스콧 알렉산더(Scott Alexander)라는 분이 올린 포스팅 때문에 다시 주목받고 있습니다.

지오게싱은 사진 한 장 딱 보여주고 “여기가 어디게?” 하고 맞추는 게임 같은 건데요. 놀라운 건, 정말 별 특징 없어 보이는 해변 사진이나 심지어는 방 안 사진만 보고도 거의 정확하게 위치를 찾아낸다는 겁니다. “혹시 사진에 위치 메타데이터(EXIF) 같은 거 숨겨둔 거 아냐?” 하는 의심도 있었지만, 아니랍니다. 캡처해서 메타데이터 다 날리고 넣어도 맞춘대요.

여기서 핵심은 바로 프롬프트입니다. 그냥 물어봐도 어느 정도 맞추지만, 아주 정교하게 작성된 ‘괴물 같은 프롬프트’를 사용하면 정확도가 비약적으로 상승합니다. 사진 속의 미세한 단서들, 예를 들어 식물의 종류, 건물의 양식, 심지어는 아주 작게 보이는 간판이나 자동차 번호판까지 분석해서 위치를 추론하는 거죠.

스콧 알렉산더는 이걸 **’헬리콥터 모멘트’**라고 표현했어요. 이게 단순한 기술 시연을 넘어 어떤 의미를 갖는지 깊이 분석했죠. (참고로 이분, 다니엘 코코타일로와 함께 ‘AI 2027’이라는 글을 쓰신 분입니다. 정신과 의사이면서 AI 분야에도 깊은 통찰을 보여주는 분이죠.) 샘 알트만도 이 글을 리트윗해서 더 화제가 됐고요.

실제로 얼마 전 안드레이 카파시(Andrej Karpathy)가 한국에 왔을 때 인스타 스토리에 올린 사진 한 장을 가지고 저희도 실험을 해봤습니다. 그 사진을 캡처해서 GPT-4o에게 지오게싱 프롬프트를 적용해 물어봤죠. 그랬더니 “서울 같다”, 사진 구석에 희미하게 보이는 ‘YES! IN KOREA’ 문구, 스카이라인, 저 멀리 아주 작게 보이는 서울타워 등을 포착하더군요. 이걸 바탕으로 명동성당 같은 특정 랜드마크를 식별하고, 첨탑 개수 등을 비교 분석해서 지역을 강남권으로 좁혀 나갔습니다.

여기서 더 나아가 웹 검색을 통해 블로그 글이나 관련 사진들을 찾아보고, 심지어 사진 속 건물의 각도, 방위각, 층수까지 계산해서 “이 각도에서 이런 뷰가 나오는 곳은 여기 호텔의 특정 라운지 발코니가 유일하다”는 결론을 내리더군요. 좌표까지 제시하면서요. 정말 소름 돋을 정도로 정확하게 맞췄습니다. 저희끼리는 “이거 어디지?” 하고 있었는데, 그 분야 지식이 있는 분이 바로 맞추시긴 했지만, AI가 이런 탐정 같은 추론 과정을 거쳐 답을 찾아내는 걸 보니 놀랍더군요.

이 지오게싱 사례가 뭘 의미할까요? 충분한 지능을 갖춘 모델에게 명확한 목표와 적절한 프롬프트를 주고, 웹 검색 같은 필요한 도구를 마음껏 쓸 수 있게 해주면, 굉장히 복잡한 문제도 해결할 수 있다는 겁니다. 물론 아직 AI가 어떤 건 기가 막히게 잘하지만, 어떤 건 어이없게 못하는 ‘미디어 사반트’ 같은 면모를 보이기도 합니다. 하지만 잘하는 능력, 특히 이미지 속 픽셀 수준의 정보를 읽어내는 멀티모달 능력은 정말 경이로운 수준으로 발전하고 있어요.

자, 그럼 이런 에이전트 능력을 브라우저 제어에 접목해보려는 시도들을 살펴볼까요? 저는 최근 **코덱스 CLI(Codex CLI)**를 이용해 브라우저를 제어하는 에이전트를 만드는 실험을 하고 있습니다. 사실 성능만 보면 엔트로픽의 클로드 코드(Claude Code)가 더 나을 수도 있지만, 제미나이(Gemini)를 쓸 수 있어서 비용 절감 차원에서 코덱스 CLI를 택했어요. 이런 실험은 많이 해봐야 감이 오는데, 클로드 코드는 비용이 정말 순식간에 사라지더라고요. (웃음) 제미나이와 코덱스 조합으로도 원하는 작업은 충분히 가능합니다. 특히 적은 비용으로 상상력을 마음껏 발휘해보는 데는 아주 좋아요.

제가 만들려는 건, 마인크래프트 에이전트처럼 특정 환경(여기서는 브라우저) 안에서 스스로 작업을 수행하는 에이전트입니다. 목표는 간단해요. 에이전트에게 “스콧 알렉산더의 최신 글을 찾아서 그가 어떤 인물인지 조사하고, 인도 베다 철학과 관련된 내용이 있는지 알아본 다음, 그 내용을 하이퍼링크가 포함된 에세이 형식으로 어바웃:블랭크(about:blank) 페이지에 작성해줘. 디자인도 신경 써서!” 같은 명령을 내리면, 에이전트가 알아서 브라우저를 열고, 검색하고, 내용을 읽고, 필요하면 코드를 주입해서 웹페이지를 조작하고, 최종 결과물을 만들어내는 거죠.

이걸 구현하기 위해 저는 ‘MCP(Multi-modal Cognitive Platform)’ 같은 복잡한 모듈 대신 좀 더 근본적인 접근을 시도했습니다. 핵심 구조는 이렇습니다.

코덱스 CLI: 제 컴퓨터의 셸(Shell) 명령어를 실행할 수 있습니다. curl로 웹에 접속하거나, ls로 파일 목록을 보거나, 파일을 읽고 쓸 수 있죠. 즉, 제 컴퓨터의 자원을 활용할 수 있는 능력이 있습니다.
중계 서버 (Bridge Server): 코덱스 CLI가 직접 웹페이지의 DOM(Document Object Model)을 읽거나 조작할 수는 없기 때문에, 중간 다리 역할을 하는 로컬 서버를 하나 만들었습니다.
크롬 확장 프로그램: 브라우저에서 실행되면서 현재 페이지의 DOM 정보를 읽어 중계 서버로 보내거나, 중계 서버로부터 받은 명령(예: 자바스크립트 코드 실행)을 브라우저에서 수행하는 역할을 합니다. 이 확장 프로그램은 **크롬 개발자 도구 프로토콜(Chrome DevTools Protocol, CDP)**을 사용해서 보안 제약을 우회하고 웹페이지에 임의의 코드를 주입할 수 있게 해줍니다.

이 구조의 장점은, 플레이라이트(Playwright) 같은 자동화 도구처럼 에이전트에게 제 로그인 정보(크리덴셜)를 직접 넘겨줄 필요 없이, 이미 제가 로그인해서 사용하고 있는 브라우저 세션에 살짝 ‘접속’해서 필요한 정보만 주고받거나 조작할 수 있다는 점입니다. 말 그대로 ‘브릿지’ 역할만 하는 거죠.

자, 제가 만든 이 시스템이 작동하는 과정을 한번 보시죠. (영상 시연 설명) 저는 브라우저가 눈에 보이는 ‘헤드풀(Headful)’ 방식으로 진행합니다. 웹 자동화에서는 보통 화면 없이 실행하는 ‘헤드리스(Headless)’ 방식을 많이 쓰지만, 저는 에이전트와 상호작용하면서 과정을 지켜보기 위해 헤드풀을 선호해요.

명령을 내리면, 코덱스 CLI가 먼저 curl 명령어로 웹사이트에 접속해서 HTML 내용을 가져옵니다. 내용이 너무 길면 파일로 저장한 뒤, sed 같은 명령어로 필요한 부분만 조금씩 읽어 들이죠. 로컬호스트 8000번에 띄워둔 중계 서버를 통해 브라우저의 DOM 정보를 가져오거나, “어떤 링크를 클릭해라”, “어떤 입력창에 텍스트를 입력해라” 같은 명령을 내립니다.

예를 들어, 스콧 알렉산더의 블로그 글을 찾아서 읽고, 구글에서 추가 정보를 검색한 뒤, 그 내용을 바탕으로 about:blank 페이지에 에세이를 작성하라고 지시하면, 에이전트는 먼저 제목을 넣고, 본문 내용을 조금씩 추가하고, 하이퍼링크를 거는 등의 작업을 순차적으로 수행합니다. 이때 브라우저 개발자 도구를 함께 띄워놓고 보면, DOM 요소들이 실제로 생성되고 수정되는 것을 확인할 수 있죠.

처음에는 한 번에 모든 작업을 처리하려고 하면 에러가 자주 발생합니다. 그래서 “문제가 생기면 한 번에 해결하려 하지 말고, 작업을 잘게 쪼개서 하나씩 처리하라(Divide and Conquer)“는 식의 지침을 프로젝트별 설정 파일(codex.md)에 시스템 프롬프트처럼 넣어두었습니다. 이 파일에는 사용할 수 있는 서버 엔드포인트 목록, 작업 공간 경로, 페이로드(Payload) 형식, 코드 주입 시 주의사항(따옴표 이스케이프 처리 등) 같은 정보도 담겨 있죠. 이런 디테일한 지침들이 에이전트의 성공률을 높이는 데 아주 중요합니다.

이런 과정을 거쳐서, 비록 아주 예쁘지는 않지만 하이퍼링크가 포함된 에세이가 about:blank 페이지에 만들어졌습니다. 여기서 더 나아가 “배경에 SVG 애니메이션을 추가해줘”라고 요청하면, SVG 코드도 생성해서 페이지에 주입해주고, “이 내용을 바탕으로 챗GPT에 접속해서 질문해봐”라고 하면, 챗GPT 웹사이트에 접속해서 대화를 시도하기도 합니다. (물론 아직 완벽하진 않아요.)

구독자분들이 보시기엔 이게 오픈AI의 딥 리서치(Deep Research)나 오퍼레이터(Operator)와 비슷해 보일 수 있습니다. 맞아요. 핵심 원리는 유사합니다. 오퍼레이터는 브라우저 접근에 더 특화되어 있고, 딥 리서치는 보고서 생성 같은 기능이 강화된 형태죠. 제가 만든 건 이런 상용 서비스들의 핵심 로직을 좀 더 직접적으로 구현해보려는 시도라고 할 수 있습니다.

더 나아가서는 3D 그래픽 라이브러리인 Three.js로 렌더링된 화면에서 오브젝트를 추가하거나 제거하는 작업도 가능하게 만들었습니다. 즉, 브라우저에서 실행되는 웹 앱이라면 어떤 것이든 에이전트가 조작하고 상호작용할 수 있는 기반을 마련한 셈이죠. 제가 특정 기능을 가진 웹 앱(도구)을 만들어두면, 에이전트가 그 도구를 활용해서 더 복잡한 작업을 수행하게 할 수도 있습니다. 이걸 잘만 활용하면 정말 별의별 걸 다 만들 수 있겠다는 상상이 들더군요. 네, 어쩌면 새로운 회사를 만들 수도 있겠죠? (웃음)

하지만, 이 과정이 결코 순탄하지만은 않습니다. 제가 보여드린 성공 사례는 수많은 시행착오 끝에 얻어진, 일종의 ‘체리피킹’ 결과물입니다. 실제로 에이전트를 개발해보면, 정말 골치 아픈 문제들이 많아요.

AI 에이전트 개발의 현실적인 어려움:

비결정성(Non-determinism): 똑같은 명령을 내려도 어떨 땐 잘 되다가 어떨 땐 엉뚱한 행동을 하거나 그냥 멈춰버리는 경우가 비일비재합니다. 마치 사람처럼요. 원하는 대로 깔끔하게 제어하기 위해선 엄청난 ‘노가다’가 필요해요.
프롬프트 엔지니어링의 중요성: 에이전트가 목표를 제대로 이해하고 작업을 수행하도록 시스템 프롬프트나 작업 지침(codex.md 같은)을 아주 세심하게 작성하고 계속 수정해야 합니다. 실패 사례를 분석해서 “아, 이 부분은 이렇게 지침을 바꿔줘야겠구나” 하고 끊임없이 개선해야 하죠.
환경과의 상호작용 문제:
- 따옴표 지옥 (Quote Hell): 코드를 웹페이지에 주입할 때 따옴표나 특수문자를 제대로 이스케이프(Escape) 처리하는 게 정말 까다롭습니다. 이걸 잘못하면 코드가 깨지거나 보안 문제가 발생할 수 있죠. 저도 이걸 해결하려고 베이스64 인코딩 같은 꼼수를 써보기도 했는데, 항상 성공하는 건 아니더라고요. (혹시 더 좋은 방법 아시는 분 계시면 알려주세요!)
- 취약한 코드(Fragile Code): 제가 AI의 도움을 받아 만든 코드들은 아직 버그가 많고 깨지기 쉽습니다. 문제를 해결하면서 관련 기술을 공부해야 하는데, AI가 너무 많은 걸 대신 해주다 보니 오히려 공부가 잘 안 되는 딜레마도 있더군요.
- 추상화의 한계: 브라우저 화면 전체(DOM)를 그대로 에이전트에게 주면 너무 정보량이 많고 지저분해서 컨텍스트 용량을 금방 초과합니다. 그래서 DOM 구조를 단순화하고 추상화해서(예: 버튼, 입력창, 링크 등으로 요약) 전달하는데, 이 과정에서 사람 눈에는 뻔히 보이는 중요한 정보를 놓치거나 잘못 해석하는 경우가 많아요. “여기 ‘무엇이든 물어보세요’라고 쓰인 게 입력창 아닐까?” 하고 추측해서 시도해보는 식이죠. 환경을 에이전트가 ‘잘’ 인식하도록 돕는 효과적인 추상화 방법을 찾는 게 핵심 과제입니다. 아마 많은 개발자들이 이 문제로 고통받고 있을 거예요.
- 피드백 루프의 중요성: 단순히 명령을 실행하는 것뿐만 아니라, 실행 결과(성공, 실패, 오류 메시지 등)를 에이전트에게 명확하게 피드백해주는 것이 정말 중요합니다. 이 피드백을 바탕으로 에이전트가 스스로 방향을 수정하고 다음 단계를 계획할 수 있게 해야 해요. 이걸 구현했을 때와 안 했을 때의 성능 차이가 엄청나게 컸습니다. “맥락 읽기 -> 코드 작성 -> 실행 -> 결과 읽기 -> 피드백” 이 순환 구조, 이게 바로 AI 시대의 새로운 프로그래밍 템플릿, 보일러플레이트라고 할 수 있겠죠.
- 환경 변화 추적: 에이전트는 작업을 수행하면서 환경(예: 웹페이지 DOM)을 변화시킵니다. 이 변경 이력을 제대로 관리하고 인지하는 것이 중요해요. 특히 여러 에이전트가 동시에 작업하는 멀티 에이전트 환경에서는 다른 에이전트가 변경한 내용까지 파악해야 하죠. (저는 아직 싱글 에이전트 위주로 실험하고 있지만, 코덱스 인스턴스를 여러 개 띄워서 역할을 분담시키는 멀티 에이전트 구조도 구상 중입니다.)
- 비동기 이벤트 처리의 어려움: 현재 구조에서는 코덱스 CLI가 브라우저 환경에서 발생하는 변화(예: 버튼 클릭 후 페이지 로딩 완료)를 실시간으로 감지하기 어렵습니다. 그래서 주기적으로 상태를 확인하는 ‘폴링(Polling)’ 방식을 써야 하죠. 이걸 개선하기 위해, 브라우저 환경에 “변화가 생기면 나(코덱스 CLI)에게 알려줘!”라고 역으로 이벤트를 발생시키는 코드를 주입하는 방식을 고민하고 있습니다. 즉, 에이전트가 자신의 피드백을 효과적으로 받기 위한 도구를 스스로 생성하고 환경에 심는 거죠. 이게 아마 다음 단계의 핵심 기술이 될 것 같습니다.

이런 어려움에도 불구하고, AI 에이전트 기술은 빠르게 발전하고 있습니다. 지난주에는 제미나이가 고전 게임 ‘포켓몬 블루’를 클리어했다는 소식도 있었죠. 게임 화면(픽셀)을 직접 분석하기도 하지만, 게임 내 지도 같은 정보를 추상화해서 에이전트에게 제공하는 도구를 활용했을 때 훨씬 좋은 성능을 보였다고 합니다. 앞으로는 더 작은 모델로, 더 빠른 시간 안에 이런 게임을 클리어하는 것이 새로운 벤치마크가 될 수도 있겠네요.

브라우저 사용 관련 최신 동향

자, 이제 시야를 넓혀서 브라우저를 활용하는 AI 에이전트 시장의 다른 움직임들도 살펴볼까요?

오픈AI 오퍼레이터(Operator): 프로 계정 사용자에게 제공되는 기능으로, 브라우저 작업을 자동화해줍니다. 페이스북 댓글을 가져오거나, 링크드인 정보를 취합하는 등의 간단한 업무에 활용하는 사례들이 나오고 있죠.
펠로우(Fellow): 최근에 등장한 서비스인데, 여러 브라우저 탭을 동시에 제어하면서 작업을 분산 처리하고 종합하는 모습을 보여줍니다.
퍼플렉시티 코멧(Perplexity Comet): 아직 정식 출시는 안 된 것 같지만, AI 기반의 새로운 브라우저 경험을 예고하고 있습니다.
어댑트(Adept) & 액트-원(Act-1): 사실 이런 시도는 꽤 오래전부터 있었습니다. 2022년에 트랜스포머 논문의 제1 저자인 애쉬시 바스와니(Ashish Vaswani) 등이 참여했던 어댑트라는 회사가 ‘액트-원’이라는 브라우저 제어 기술 데모를 공개했었죠. 이것도 여러 탭을 동시에 제어하는 등 현재의 에이전트들과 유사한 기능을 보여줬습니다. 어댑트는 이후 아마존에 인수되었고, 바스와니 등 핵심 인력들은 ‘이센셜 AI(Essential AI)’라는 새로운 회사를 창업해서 더 근본적인 AI 기술 연구(예: 새로운 옵티마이저 개발)와 비즈니스를 모색하고 있습니다.

결국, GPT-3 시절부터 컴퓨터나 브라우저를 AI가 자연스럽게 사용하게 만들려는 시도는 계속되어 왔습니다. 지금은 과도기라서 제가 실험하는 것처럼 다소 복잡한 과정을 거쳐야 하지만, 앞으로는 훨씬 더 세련되고 사용자 친화적인 형태의 컴퓨터/브라우저 제어 AI 에이전트가 당연하게 등장할 것이라고 봅니다. 마치 웹 초창기에 CGI로 인터랙션을 구현하다가 PHP, Ajax, React 등으로 발전해 온 것처럼요.

구글 I/O 기대감과 제미나이 1.5 프로의 진화

그래서 다가오는 구글 I/O가 더욱 기대됩니다. 특히 최근 공개된 제미나이 1.5 프로 프리뷰 버전은 정말 놀라운 기능들을 보여줬어요.

이미지 투 코드(Image-to-Code): 사용자가 손으로 그린 웹페이지 스케치(요구사항 포함)를 보고 즉석에서 작동하는 HTML/CSS/JS 코드를 생성해줍니다. GPT-4 발표 때 그렉 브록만이 보여줬던 데모보다 훨씬 발전된 모습이죠. 저도 직접 캡처해서 테스트해봤는데, 정말 됩니다! 현재 웹 개발 능력 벤치마크(WebDevBench)에서 최고 수준을 기록하고 있다고 해요. 프론트엔드 개발 능력이 비약적으로 향상된 거죠.
비디오 투 러닝 앱(Video-to-Learning App): 이건 정말 충격적이었습니다. 유튜브 영상 URL만 입력하면, 그 영상의 내용을 기반으로 사용자와 상호작용할 수 있는 학습용 웹 애플리케이션을 뚝딱 만들어줍니다! 예를 들어 프랙탈에 대한 설명 영상을 넣으면, 사용자가 직접 파라미터를 조절하며 프랙탈 이미지를 생성해볼 수 있는 앱을 만들어주는 식이죠. 제가 번개에 대한 짧은 교육 영상을 넣고 시도해봤더니, 번개의 원리(음전하/양전하 대전, 피뢰침 등)를 사용자가 직접 시뮬레이션해볼 수 있는 앱이 생성됐습니다. 유튜브에 있는 수많은 튜토리얼 영상들을 이런 인터랙티브 학습 앱으로 변환할 수 있다는 가능성! 정말 머리가 띵해지더군요.

이런 기능들은 구글의 AI 스튜디오(Vertex AI Studio)나 관련 API를 통해 제공되는데, 웹 앱에서 AI 기능을 아주 쉽게 가져다 쓸 수 있도록 만들어져 있습니다. 유튜브 영상을 처리하려면 상당한 토큰(비디오 길이에 따라 수십만~백만 토큰)이 소모되긴 하지만, 비디오 자체를 AI가 이해하고 활용하는 시대가 열리고 있다는 증거죠.

이번 구글 I/O에서는 제미나이 1.5 울트라 모델과 함께, 텍스트-비디오 생성 모델인 ‘베오(Veo)’의 차기 버전을 공개하고, 오디오 요약(Audio Overview)에 이어 비디오 요약(Video Overview) 기능까지 선보일 거라는 소문도 있습니다. 만약 이게 현실화된다면, 영상 콘텐츠를 활용하는 방식이 완전히 달라질 수 있겠죠.

또한, 검색 결과 대신 AI 요약본을 보여주는 ‘AI 모드(AI Overview)’가 어떻게 정식으로 구현될지도 큰 관심사입니다. 구글의 핵심 비즈니스인 검색 광고 모델과 어떻게 조화를 이룰지, LLM 답변에 광고를 어떻게 통합할지 지켜봐야 할 부분입니다.

AI 활용 자동화와 미래 전망

이런 기술 발전은 결국 ‘일의 자동화’라는 흐름으로 이어집니다. 드와케시 파텔(Dwarkesh Patel) 같은 사람들은 이미 “완전히 자동화된 회사는 어떤 모습일까?”를 논의하고 있고, 그 내용을 AI가 요약해서 영상으로 만들어주는 일까지 벌어지고 있죠. 우리나라에서도 릴 도지(Lil Doji)라는 래퍼가 AI 생성 영상을 활용해 활발히 활동하는 모습도 보이고요.

저희 팟캐스트도 한번 자동화해볼까 하는 농담을 하기도 했었는데, 최근 노트북LM(NotebookLM)에 한국어 오디오 요약 기능이 추가돼서 지난 방송 내용을 넣어봤습니다. 그랬더니 꽤 그럴듯하게 내용을 요약하고, 심지어는 가상의 진행자 두 명이 대화하는 형식으로 오디오 콘텐츠까지 만들어주더군요! (오디오 재생) 아직 완벽하진 않지만, 아나운서처럼 또렷하게 말하는 걸 보니 신기했습니다. 여기에 비디오 오버뷰 기능까지 더해진다면…? 정말 팟캐스트 제작 과정의 상당 부분을 자동화할 수 있을지도 모르겠습니다.

하지만 이런 자동화가 항상 긍정적인 것만은 아닙니다. 제가 실험 삼아 만든 에이전트에게 페이스북 메신저로 지인들에게 메시지를 보내게 해봤는데, 다들 답장을 잘 안 하시더라고요. (웃음) 사람들은 (적어도 아직은) 일상적인 대화를 AI와 하고 싶어 하지는 않는 것 같습니다. 물론 제가 AI라는 사실을 숨기고 제 페르소나를 부여해서 대화하게 할 수도 있겠지만, 그것도 제 말투를 완벽히 흉내 내기는 어렵고, 나중에 들켰을 때 관계가 어색해질 수도 있겠죠.

포스팅이나 댓글 달기, ‘좋아요’ 누르기 같은 활동은 어느 정도 자동화가 가능했습니다. 스콧 알렉산더의 글을 읽고, 제 생각을 정리해서 블로그 포스팅까지 자동으로 하게 만드는 것도 이론적으로는 가능하고요. 이게 바로 **’일의 미래’**의 한 단면이겠죠.

결론: 빌더의 시대, 닥치고 계속 간다!

자, 오늘 정말 많은 이야기를 나눴습니다. AI 에이전트, 특히 브라우저를 활용하는 기술의 가능성과 현실적인 어려움, 그리고 최신 동향과 미래 전망까지 짚어봤는데요.

결론은 이겁니다. 지금은 시대를 정의하거나 예측하는 게 거의 의미 없는 시기라는 겁니다. 작년이나 올해 초까지만 해도 “이게 될까?” 하는 논의를 했다면, 이제는 “이건 무조건 되는 게임이다!”라는 가정 하에 일단 만들어봐야 하는 시기입니다. 바로 ‘빌더(Builder)’의 시대가 온 거죠.

저 역시 직접 코딩하기보다는 저희 엔지니어들에게 프롬프트를 ‘주입’하는 방식으로 빌딩에 참여하고 있습니다만 (웃음), 이제는 코딩 경험이 없는 사람들도 이런 AI 도구들을 활용해서 충분히 빌더가 될 수 있다고 생각합니다. 커서(Cursor)나 깃헙 코파일럿 같은 도구들의 사용량이 늘어나는 것만 봐도 알 수 있죠.

“AI가 만든 코드는 보안에 취약해서 안 돼!”라는 목소리도 있지만, “그럼 나보다 더 똑똑한 AI한테 코드 리뷰를 시키면 되잖아? 두 번, 세 번 시키면 웬만한 문제는 잡지 않을까?” 하는 생각도 듭니다. 실제로 저도 어느 순간부터 AI 에이전트가 생성한 코드를 일일이 확인하지 않고, 그냥 작동하면 넘어가는 제 자신을 발견하고 깜짝 놀랐습니다. 이게 바로 미래의 모습이 아닐까 싶어요.

물론 여전히 해결해야 할 과제는 많고, 기술의 발전 속도는 어지러울 정도입니다. 하지만 중요한 것은, 이 변화의 흐름 속에서 직접 무언가를 만들어보고 부딪혀보면서 ‘온도’를 느끼는 것입니다. 내가 사용하는 작은 AI 챗봇과의 상호작용부터 시작해서, 가능하다면 직접 코드를 만져보거나 AI 도구를 활용해 작은 프로젝트라도 시도해보는 거죠. 그렇게 했을 때 비로소 이 ‘신기한 세상’이 어디로 흘러가고 있는지, 그 안에서 나는 무엇을 할 수 있을지 감을 잡을 수 있을 겁니다.

그러니 여러분, 너무 복잡하게 생각하지 마시고, “닥치고 계속 갑시다!” 이게 제가 오늘 여러분께 드리고 싶은 가장 중요한 메시지입니다.

자, 오늘 강의는 여기까지입니다. 다음 시간에는 아마 구글 I/O 이후 더 흥미로운 소식들을 가지고 돌아올 수 있을 것 같네요. 질문 있으신가요? 없으시면 여기서 마치겠습니다. 수고하셨습니다!