OpenAI O3: 에이전틱 코딩의 획기적 발전인가?

Prompt Engineering 구독자 190,000명

요약

본 영상은 OpenAI의 새로운 O3 모델이 보여주는 에이전틱 코딩 능력을 다양한 코딩 데모와 함께 심층적으로 분석합니다. 프롬프트를 통한 UI 디자인, 내부 체인 오브 씽(사고 과정) 및 웹 검색 통합, 그리고 순차적 도구 호출을 활용하여 복잡한 코딩 문제를 해결하는 과정을 설명합니다. 또한 텍스트-이미지 앱 구현과 다양한 벤치마크 비교를 통해 모델의 강점과 개선점을 살펴봅니다.

주요 키워드

OpenAI O3 에이전틱 코딩 체인 오브 씽 순차적 도구 호출 웹 검색 UI 디자인 Gemini Flash 2.0 코드 디버깅 SDK 벤치마크

하이라이트

🔑 프롬프트를 통해 포켓몬 백과사전 및 TV 채널 UI를 생성하는 과정을 시연합니다.
⚡️ 모델이 내부 체인 오브 씽과 웹 검색을 순차적으로 활용해 문제를 해결하는 점을 강조합니다.
🌟 자바스크립트를 활용한 시뮬레이션(회전 구체, 육각형 내 바운싱 볼 등) 코드 생성과 디버깅 과정을 자세히 분석합니다.
📌 텍스트-이미지 앱 구현 예제에서 SDK 선택 및 최신 Gemini Flash 2.0 API 활용 과정을 보여줍니다.
🚀 벤치마크 비교를 통해 O3 모델의 성능과 비용 효율성을 Gemini 제품군과 함께 평가합니다.

용어 설명

에이전틱 코딩 (Agentic Coding)

모델이 스스로 사고하고 도구를 호출하여 코딩 문제를 해결하는 능력을 의미합니다.

체인 오브 씽 (Chain-of-Thought)

내부 사고 과정을 단계별로 전개하며 문제 해결 계획을 세우는 모델의 내부 연산 방식입니다.

순차적 도구 호출 (Sequential Tool Calling)

모델이 웹 검색이나 함수 호출 등 다양한 도구들을 순서대로 활용하는 과정을 뜻합니다.

Gemini Flash 2.0

텍스트 기반 프롬프트로 이미지 생성 기능을 제공하는 최신 Gemini API 버전입니다.

웹 검색 (Web Search)

모델이 외부 자료를 참고하기 위해 실시간으로 검색을 수행하여 정보를 보완하는 기능입니다.

포켓몬 백과사전과 TV 채널 UI를 생성하는 프롬프트 데모를 소개합니다. 간단한 HTML/CSS/JS를 사용해 인터랙티브한 웹사이트 구현을 시연합니다.

[00:01] 포켓몬 백과사전 웹사이트 제작 프롬프트를 소개하며, CSS, JS, HTML을 포함한 단일 파일로 구현된 멋진 결과물을 보여줍니다.

[00:33] OpenAI의 첫 모델이 완벽하진 않지만 인상적인 기능을 보여주며, 때로는 특이한 방식으로 실패하는 경우도 있다고 설명합니다.

[01:16] O3에게 모델 컨텍스트 프로토콜과 에이전트 간 프로토콜의 차이점을 물어보았을 때, 웹 검색 기능을 자발적으로 활용하는 특징을 보여줍니다.

모델이 내부 사고 과정을 통해 요구사항을 분석하는 방법을 설명합니다. 웹 검색을 순차적으로 활용하여 답변을 보완하는 점이 강조됩니다.

[02:34] O3의 웹 검색 기능이 GPT-4.0과는 다르게 더 에이전트적인 특성을 가지고 있으며, 단계적이고 체계적인 검색 방식을 사용한다고 설명합니다.

[03:01] 클로드의 웹 검색 기능과 비교하며, 확장된 사고 기능과 함께 웹 검색을 수행하는 방식을 설명합니다.

[03:29] 모델이 웹 검색을 수행하고 필요한 경우 추가 검색을 통해 응답을 정교화합니다.

[03:36] 첫 번째 테스트로 포켓몬 백과사전 웹사이트를 만드는 프롬프트를 실행했습니다. 모델은 GPT-4 1.0과 다른 주도적인 사고 방식을 보여주었습니다.

[04:22] 생성된 웹사이트는 매우 세련된 UI를 보여주었고, 검색창 추가 요청에도 완벽하게 대응했습니다.

[05:14] LLM의 실제 가치는 창의적 자유도보다는 구체적인 지시사항을 얼마나 잘 따르는지에 있다는 점을 강조했습니다.

[05:37] TV 채널 전환 애플리케이션 예제를 통해 구체적인 지시사항과 창의성의 균형을 테스트했습니다.

자바스크립트를 이용한 시뮬레이션과 인터랙티브 코딩 예제를 다룹니다. 함수 호출, 레이어 문제 등 코드 개선 및 디버깅 전략을 소개합니다.

[06:30] 각 채널별로 다양한 애니메이션을 구현했으나, GPT-4 1.0에 비해 애니메이션 품질 면에서는 개선의 여지가 있었습니다.

[06:52] 모델이 애니메이션을 잘 처리했지만, 이를 혼란스럽게 만들어보기 위해 스크린샷을 제공하고 요구사항과 비교해 문제점을 찾아보도록 했습니다.

[07:20] 날씨 채널 이미지에 대해 데드 픽셀 검사 등 다양한 분석을 수행했고, 이미지를 직접 보여주며 분석하는 새로운 기능을 보여주었습니다.

[07:41] 채널 아이디어는 잘 만들어졌지만, 레이어 구성과 TV 세트 테두리의 가시성 문제, 그리고 background 함수 호출 관련 잠재적 문제를 지적했습니다.

[08:11] 모델이 파이썬 코드를 작성하고 실행하며, 순차적인 분석과 결과 기반의 업데이트를 수행하는 새로운 수준의 추론 능력을 보여주었습니다.

[08:47] TV 스크린 마스크 관련 이슈와 캔버스 크기 문제에 대해 분석하고 해결책을 제시했습니다.

[09:32] 새로운 프롬프트로 회전하는 숫자 구체 시뮬레이션을 요청했고, 거리에 따른 색상 변화를 구현하도록 지시했습니다.

[10:03] AI가 만든 시뮬레이션에서 색상 반전 문제를 발견하고, 멀티모달 추론을 통해 분석을 시작했습니다.

[10:30] AI가 Z 정렬 문제와 페인터스 알고리즘의 순서가 잘못되었음을 파악하고, 두 단계의 사고 과정을 거쳐 분석했습니다.

[11:26] 첫 번째 해결 시도가 실패한 후, AI는 코드를 재분석하고 페인터스 알고리즘과 깊이 쉐이딩 매핑을 수정하여 문제를 해결했습니다.

[12:36] 새로운 프로젝트로 넘어가며, 20개의 공이 육각형 안에서 튀는 시뮬레이션에 대한 구체적인 요구사항을 설명합니다.

[13:13] O3가 HTML 파일 하나에 모든 코드를 담아 요구사항을 처리하는 방식에 대해 설명합니다. 코드는 간결하지만 설명이 부족한 특징이 있습니다.

[13:40] OpenAI 모델 중 처음으로 칠각형 회전과 20개 공의 물리적 상호작용을 성공적으로 구현했습니다.

[14:22] 떨어지는 글자 애니메이션 구현 시도에서 발생한 오픈타입 시그니처 404 에러와 해결 과정을 설명합니다.

[15:45] 텍스트-이미지 변환 앱 개발 프로젝트에 대한 소개와 요구사항을 설명합니다. Gemini Flash 2.0 API를 활용한 이미지 생성 기능 구현이 목표입니다.

Gemini Flash 2.0 API를 활용해 텍스트로 이미지 생성 앱을 만드는 과정을 시연합니다. SDK 선택, 최신 구성 반영과 벤치마크 비교로 모델 성능을 평가합니다.

[16:22] 기존에는 API 문서를 제공했지만, 이번에는 검색 기능이 있는 모델의 성능을 테스트하기로 결정했습니다.

[16:38] Gemini SDK가 최근 업데이트되어 대부분의 모델들이 새로운 SDK와 이전 SDK를 혼동하는 상황에서 모델의 대응 능력을 확인하고자 했습니다.

[17:07] 모델은 텍스트-이미지 변환 앱 개발을 위해 FastAPI나 Flask 중에서 플랫폼을 선택해야 했고, Gemini Pro 2.0 API 관련 정보를 검색했습니다.

[17:42] 모델은 더 나은 결과를 위해 최소 10개의 다양한 소스가 필요하다고 판단하여 Gradio와 Streamlit에 대한 추가 검색을 수행했습니다.

[18:04] 이 시스템은 에이전트적 특성을 보이며, 여러 번의 시도를 통해 최적의 결과를 찾아내려 노력했습니다.

[18:51] 모델은 새로운 버전의 Gemini SDK를 선택했지만, 일부 설정에서 이전 SDK의 configure 함수를 잘못 사용하는 실수를 했습니다.

[19:25] 에러 발생 시 모델은 자체적으로 계획을 수정하고 추가 검색을 통해 코드를 개선했으며, 최종적으로 앱의 시각적 모습까지 제시했습니다.

[19:41] AI가 예측한 앱의 디자인과 실제 구현된 앱을 비교하며, 생성 설정과 프롬프트 등이 매우 유사하게 구현되었음을 설명합니다.

[20:28] O3의 강력한 기능으로 SDK 버전 분석, 검색 메커니즘, 순차적 도구 호출 능력을 강조하며, 한 번에 완벽하지는 않지만 오류를 수정하며 개선되는 과정을 설명합니다.

[21:18] OpenAI가 윈드서프와 협력하여 O3의 코딩 기능을 IDE에 통합할 가능성과 Codex CLI의 개발에 대해 논의합니다.

[22:03] 추후 제작될 영상에서 추론 능력 테스트와 misguided attention 데이터셋 분석 계획을 소개합니다.

[22:22] O3의 벤치마크 결과를 소개하며 Gemini 2.5 Pro와 비교하여 좋은 성능을 보이고 있음을 설명합니다.

[22:53] Gemini 2.5 Pro와 O3의 성능 대비 비용 비교에서, Gemini가 더 나은 비용 효율성을 보여주고 있습니다. 특히 2025년 04 Mini 모델이 가장 좋은 성능 대비 비용을 보여줍니다.

[23:28] PhD 수준의 GPQA 테스트에서 Gemini는 O3와 04 Mini보다 저렴한 비용으로 더 좋은 성능을 달성했습니다. MMU 벤치마크에서도 O3가 더 나은 성능을 보이지만, Gemini는 훨씬 저렴한 비용으로 비슷한 성능을 보여줍니다.

[23:57] 코드 관련 폴리글랏 분야에서는 O3가 새로운 표준이 되었지만, 높은 비용이 단점입니다. 직접 테스트 결과 훌륭한 코딩 모델이지만, AGI 수준은 아니며 기본적인 실수들을 여전히 범하고 있습니다.

[24:23] O3의 가장 큰 장점은 도구 사용과 에이전트 워크플로우 처리 능력으로, 이는 이전의 추론 모델에서 볼 수 없었던 수준입니다. 현재 사용 가능한 벤치마크에서 코딩 능력이 최고 수준을 보여주고 있습니다.

[00:01] 자, 제가 프롬프트를 보여드리겠습니다. '첫 25마리의

[00:03] 전설의 포켓몬에 대한 간단한 백과사전을

[00:06] 만들어주세요. 타입과 코드 스니펫,

[00:08] 이미지를 포함하고, CSS와 JS,

[00:11] HTML을 하나의 파일로 만들어주세요.'

[00:13] 이 프롬프트로 만든 결과물은 제가 본 것 중

[00:15] 가장 멋진 웹사이트 중 하나입니다.

[00:17] 심지어 검색 기능도 작동하고, TV 채널도 만들었는데

[00:22] 숫자를 입력하면 채널이

[00:24] 멋진 애니메이션과 함께 전환됩니다.

[00:27] 단 하나의 짧은 프롬프트로

[00:29] 이런 것들을 만들었죠. 이 멋진 애니메이션을 보세요.

[00:33] 이것은 OpenAI의 첫 번째 모델로

[00:35] 아무런 문제없이 이런 것을

[00:37] 할 수 있습니다. 하지만 완벽하진 않아서

[00:41] 때로는 놀라운 방식으로 실패합니다.

[00:43] 이에 대한 예시들을 나중에 살펴보겠습니다.

[00:48] 이 영상에서는 O3의

[00:50] 코딩 능력을 살펴볼 텐데

[00:53] 다른 모델에서는 본 적 없는

[00:56] 몇 가지 특별한 기능들이 있어서 정말 인상적입니다.

[00:59] O3로 아주 간단한 웹 앱을 만들었는데,

[01:02] 제가 본 모델 중에서 가장 인상적인

[01:07] 결과물 중 하나라고 생각합니다.

[01:10] 이유는 나중에 설명드리겠습니다. 코딩 예제를

[01:14] 살펴보기 전에

[01:16] 이것을 보여드리고 싶습니다. O3에게 물었습니다.

[01:20] '모델 컨텍스트 프로토콜이 무엇이고

[01:23] 에이전트 간 프로토콜과는 어떻게 다른가요?'

[01:25] 웹 검색을 활성화하지 않은 상태에서

[01:28] 질문했습니다. 다른 모델들처럼

[01:30] 환각 현상이 일어날 거라

[01:32] 예상했는데

[01:34] 놀랍게도 이런 결과가 나왔습니다.

[01:37] 내부 사고 과정을 보면

[01:39] '사용자가 모델 컨텍스트 프로토콜과

[01:41] 에이전트 간 프로토콜에 대해 물었는데,

[01:44] 이 용어들은 2025년 이후의 새롭거나

[01:48] 동적인 개념일 수 있으니 정확한 정의를

[01:52] 찾아봐야겠다'고 합니다.

[01:54] 모델 컨텍스트 프로토콜은 새로운 개념이고

[01:56] 에이전트 간 프로토콜은

[01:59] AI 얼라이언스의 에이전트 간

[02:02] 명세와 관련이 있을 수 있다고 합니다. 이건

[02:06] 전에는 보지 못했던 특징입니다.

[02:09] 다른 추론 모델에게 이런 질문을 하면

[02:11] 그냥 답변을 하는데,

[02:13] 이 모델은 답변하기 전에

[02:17] 웹 검색을 하기로 결정했습니다.

[02:20] 웹 검색을 활성화하지 않았는데도

[02:22] 웹 검색 도구에 접근할 수 있었고

[02:26] 이를 사용하기로 했습니다. 또 한 가지,

[02:29] 수행하는 웹 검색은 GPT-4.0이

[02:34] 하던 일반적인 웹 검색과는

[02:36] 매우 다릅니다. 이것은 더 에이전트적인

[02:40] 성격을 띱니다. 보시다시피

[02:42] 먼저 모델 컨텍스트 프로토콜

[02:44] 명세와 에이전트 간 프로토콜을

[02:47] 검색했고, 그 다음 두 번째

[02:51] 웹 검색을 수행했습니다. 이 모든 정보를

[02:54] 바탕으로 최종 답변을 만들었죠.

[02:58] 이것 자체로 매우 인상적입니다.

[03:01] 다른 에이전트 웹 검색

[03:02] 구현은 클로드에서

[03:04] 본 적이 있는데, 여기서는 웹 검색을

[03:07] 확장된 사고와 함께 활성화할 수 있습니다.

[03:09] 이걸 사용하면

[03:11] 비슷한 패턴을 볼 수 있습니다.

[03:14] 먼저 내부 사고 과정을 보여주고

[03:17] 웹 검색 쿼리를 만듭니다.

[03:19] 여기서도 웹 검색을 수행했고,

[03:22] 중간 단계의 웹 검색을 했다고 생각합니다.

[03:25] 지금은 웹 검색 결과를 바탕으로

[03:27] 응답을 생성하고 있습니다.

[03:29] 때때로 웹 검색을 다시 수행하고

[03:32] 검색 엔진에 추가 쿼리를 수행합니다.

[03:36] 자, 이제 제가 테스트한

[03:37] 몇 가지 코드 예시를 보여드리겠습니다.

[03:40] 첫 번째 프롬프트는

[03:42] 전설의 포켓몬 25마리에 대한

[03:44] 타입과 이미지가 포함된 간단한 백과사전을

[03:47] CSS, JS, HTML이 하나의 파일로 만드는 것이었습니다.

[03:49] 이 모델의 내부 사고 과정은

[03:53] GPT-4 1.0과는 매우 다르며

[03:54] 더욱 주도적인 특성을 보입니다.

[03:58] 사용자의 요구사항이 무엇이고

[04:00] 어떻게 충족시킬 수 있는지 고민한 다음

[04:03] 계획을 수립합니다.

[04:06] 나중에 보여드리겠지만

[04:08] 사고 과정 내에서 순차적인

[04:11] 도구 호출이나 함수 호출을 수행하는데

[04:13] 이전에는 본 적이 없는 기능입니다.

[04:15] 이에 대해서는 나중에 자세히 살펴보겠습니다.

[04:18] 전반적으로 매우 인상적인

[04:20] 기능입니다.

[04:22] 자, 여기 생성된 코드가 있는데

[04:23] 이건 아마도 지금까지 본

[04:26] LLM이 만든 웹사이트 중에서

[04:28] 가장 보기 좋은 결과물 중 하나일 것 같습니다.

[04:31] 코딩, 특히 UI 디자인 측면에서

[04:34] 확실히 파인튜닝이 잘 되어있네요.

[04:37] 이 경우에는 상단에 검색창이 없어서

[04:40] 모델에게 검색창을 추가해달라고 요청했더니

[04:43] 이전 기능은 모두 유지하면서

[04:45] 완벽한 코드를 생성해냈습니다.

[04:47] 주의할 점은

[04:49] 전체 코드를 요청해야 한다는 것입니다.

[04:51] 왜냐하면 모델이

[04:53] 수정된 코드만 제공하는 경향이 있는데

[04:55] 코딩 IDE 안에서 작업할 때는 괜찮지만

[04:58] 저는 여기서 모든 것을 테스트하고 있어서

[05:01] 작동하는 전체 코드가 필요했기 때문입니다.

[05:04] 업데이트도 잘 작동하고

[05:06] 결과물도 매우 보기 좋네요.

[05:09] 첫 번째 프롬프트에서는

[05:12] 창의적인 자유도가 높았습니다.

[05:14] 하지만 이러한 LLM의

[05:16] 주요 유용성은 구체적인 지시사항을

[05:19] 얼마나 잘 따르는지에 있습니다.

[05:22] 창의성의 여지를 많이 주면

[05:25] 모델이 자유롭게 생성하기 때문에

[05:27] 여기 제가 자주 사용하는

[05:29] 프롬프트를 보여드리겠습니다.

[05:31] 이는 매우 구체적인 지시사항과

[05:33] 약간의 창의적 여지를 함께 주는 방식입니다.

[05:37] 프롬프트는 0에서 9까지의 숫자 키로

[05:40] 채널을 변경할 수 있는 TV를 만드는 것입니다.

[05:42] 각 채널마다 아이디어를 내고

[05:45] 흥미로운 애니메이션을 만들어야 하는데

[05:48] 전통적인 TV 채널 장르에서

[05:51] 영감을 받아야 합니다.

[05:53] p5.js를 사용해 800x800 크기의 스케치를 만들고

[05:57] HTML을 사용하지 않으면서

[06:02] 모든 TV 채널 콘텐츠는

[06:04] 우리가 요청한 TV 화면 영역 안에

[06:08] 마스킹되어야 합니다.

[06:11] 이제 이 코드를 복사해보겠습니다.

[06:14] 결과물이 이렇습니다.

[06:15] 첫 번째 채널은 클래식 튠즈입니다.

[06:19] 이제 글로벌 뉴스를 볼까요.

[06:21] 이 바도 추가됐네요.

[06:25] 액션 스포츠, 그루브 TV, 네이처스케이프

[06:30] 이건 코스모스 사이파이네요.

[06:34] 이 경우에는 왠지

[06:37] TV 채널 이름을 하단에 넣었네요.

[06:41] 제가 본 최고의 애니메이션은

[06:43] 이 특정 프롬프트에 대해

[06:46] GPT-4 1.0에서 나왔던 것 같습니다.

[06:50] 애니메이션 개선을 요청해볼 수 있겠네요.

[06:52] 전반적으로 애니메이션은

[06:54] 정말 잘 작동합니다. 이제 한 가지 실험을 해보고 싶었는데,

[06:57] 이 모델을 혼란스럽게 만들 수 있는지 테스트해보려고 합니다.

[07:01] 스크린샷을 제공하고

[07:03] 실제 요구사항에 비춰봤을 때 문제가 있는지 물어봤습니다.

[07:06] 그러자 모델이 답변하기를,

[07:09] 사용자가 제공한 솔루션에

[07:12] 원래 요구사항과 비교했을 때

[07:15] 문제가 있는지 확인하고 싶어 보인다고 했습니다.

[07:17] 모델이 다양한 측면을 검토했는데,

[07:20] 특히 날씨 채널 이미지이다 보니

[07:21] 데드 픽셀이 있는지 등을 체크했죠.

[07:24] 이제 모델의 사고 과정을 보면

[07:26] 이미지를 직접 보여주고 있는데,

[07:28] 이는 정말 흥미로운 부분입니다.

[07:31] 다른 모델에서는 본 적 없는

[07:33] 기능이거든요.

[07:35] 그런데 여기서 가장 흥미로운 점은,

[07:38] 모델이 각 번호에 대한 채널 아이디어를

[07:41] 잘 만들어냈다고 평가하면서도

[07:43] 채널 아이디어를 생성하는 과정에서

[07:45] 문제가 있을 수 있다고 지적한 것입니다.

[07:47] 레이어 구성 방식에 있어서

[07:49] 채널 텍스트가 겹칠 수 있고

[07:51] TV 세트의 테두리가 가시성에

[07:54] 영향을 줄 수 있다고 봤습니다. 특히

[07:57] background를 채널 함수 내에서 호출하는 것이

[08:00] 클리핑 영역을 넘어서

[08:02] 캔버스를 초기화할 수 있다는 점을 우려했죠.

[08:05] 이처럼 모델이

[08:08] 다양한 디버깅 전략을 고민하고 있습니다.

[08:11] 이제 파이썬 코드를 작성하기 시작했는데,

[08:15] 분석하고자 하는 여러 항목에 대해

[08:17] 코드를 실행하는 것을 볼 수 있습니다.

[08:20] 이 모든 과정이 사고 흐름 속에서 일어나고 있어요.

[08:23] 순차적인 함수 호출이나

[08:25] 실행을 통해 결과를 분석하고,

[08:28] 그 결과를 바탕으로

[08:30] 계획이나 구현을 업데이트하는데,

[08:33] 이는 정말 흥미롭습니다.

[08:35] 저는 개인적으로

[08:37] 이런 걸 본 적이 없어요. 이는 확실히

[08:41] 이러한 추론 모델의 새로운 수준의 지능을 보여줍니다.

[08:44] 자, 모델이 환각 현상을 보이는지는 모르겠지만

[08:47] 분석을 기반으로

[08:48] 날씨 채널이

[08:50] TV 스크린 마스크 밖으로

[08:52] 새어나간다고 말했습니다.

[08:56] 실제로 보기에는

[08:58] 그렇지 않아 보이네요. 하지만 모델은

[09:02] 몇 가지 업데이트를 추천했습니다.

[09:04] 제가 문제가 될 수 있다고 생각한 점은

[09:06] 스케치가 800x800이 아니라

[09:08] 정사각형이 아닌 직사각형이라는 점이었죠.

[09:11] 이미지를 다시 보라고 했더니

[09:13] 캔버스는 만들었지만

[09:15] 표시되는 방식 때문에

[09:18] 직사각형처럼 보일 수 있다고 했습니다.

[09:20] 몇 가지 예시를 더 보고

[09:22] 이 특정 앱과 그 제작 방식에 대해 논의해보려고 합니다.

[09:26] 이는 ChatGPT에서 많은 가능성을 열어준다고 생각합니다.

[09:29]

[09:32] 더 큰 규모의 추론 모델에

[09:34] 제가 자주 사용하는 또 다른 프롬프트가 있는데,

[09:37] 회전하는 구체를 JS로 시뮬레이션하되,

[09:40] 구체가 숫자로 이루어져있고

[09:43] 가장 가까운 숫자는 순수한 흰색,

[09:45] 가장 먼 숫자는 회색으로 페이드되며

[09:48] 검은 배경 위에 표시되도록

[09:50] 모든 코드를 한 줄로 작성해달라고 했습니다.

[09:52] 여기 생성된 코드가 있는데

[09:55] 이 코드를 실행하면 문제가 있습니다.

[09:57] 우리가 요청했던 것은 가까운 숫자는

[10:00] 순수한 흰색으로 표시되어야 하는데

[10:03] 숫자들이 멀어질수록

[10:05] 회색으로 표시되어야 하는데, 전체가 반전되어 있습니다.

[10:09] 그래서 제가 이 이미지를 제공했고,

[10:12] 멀티모달 추론 기능이 있기 때문에

[10:14] '당신이 만든 시뮬레이션에 문제가 보이나요?'라고 물었죠.

[10:16] 그러자 약 20초 정도 생각한 후에

[10:19] 이렇게 답변했습니다.

[10:21] '스크린샷을 원래 요구사항과 비교해보니

[10:23] 구의 그라데이션은

[10:25] 중앙이 하얗고 가장자리가

[10:27] 회색으로 흐려지는 것은 대체로 맞지만,

[10:30] Z 정렬 문제가 있을 수 있습니다.

[10:33] 4개의 점을 먼저 그리다 보니

[10:35] 숫자들이 겹칠 수 있네요.'

[10:38] 이것이 첫 번째 생각이었습니다.

[10:40] 그런데 흥미로운 점은

[10:43] 처음에 20초를 생각하고 나서

[10:46] 또 다른 사고 과정을 시작했다는 겁니다.

[10:49] 이번에는 47초 동안 생각했죠.

[10:52] 이것이 더 주체적인 특성을 보여줍니다.

[10:54] 다른 추론 모델처럼 몇 초 생각하고

[10:57] 응답을 생성하는 것이 아닙니다.

[11:01] 실제로 사고 과정 중에

[11:03] 행동을 취할 수 있습니다.

[11:06] 흥미로운 점은

[11:08] 두 번의 다른 세션으로

[11:09] 생각했다는 것입니다. 이제 페인터스 알고리즘 순서가

[11:12] 반대로 되어 있다는 것을 파악했습니다.

[11:15] '카메라에서 뒤쪽으로

[11:17] 점들을 정렬했기 때문에, 가장 뒤쪽의

[11:20] 숫자들이 마지막에 그려져서

[11:24] 가까운 밝은 숫자들을 부분적으로 가립니다'라고 했죠.

[11:26] 그리고 업데이트된 코드를 제공했는데

[11:30] 이걸 실행해보니

[11:31] 작동하지 않았습니다.

[11:34] 정확히 같은 문제가 발생했고

[11:36] 이를 통해 알 수 있듯이

[11:38] 한 번에 해결되지 않을 수 있습니다.

[11:42] 여전히 같은 문제가 있다고 말하자

[11:45] 다시 한동안 생각했습니다.

[11:47] 사고 과정은 맞았지만

[11:50] 코드 구현이 잘못된 것 같았죠.

[11:52] 그래서 '두 문제를 모두 해결한

[11:54] 버전을 보여드리겠습니다.

[11:57] 페인터스 알고리즘이 먼 점들을 먼저 그리고

[12:00] 가까운 점들을 나중에 그리며

[12:03] 깊이 쉐이딩 매핑에서 가까운 것은

[12:05] 순수한 흰색, 먼 것은 회색으로 했습니다'라고 했죠.

[12:08] 이게 문제를 해결하는지 봅시다.

[12:10] 보시다시피 문제가

[12:12] 해결되었습니다. 몇 번의 반복으로

[12:14] 문제를 해결할 수 있었지만

[12:17] 우리가 안내해야 했고,

[12:19] 좋은 점은 두 경우 모두

[12:22] 스크린샷만 제공하면 되었다는 겁니다.

[12:24] 스크린샷만으로도 문제를

[12:27] 이해할 수 있다는 것은

[12:29] 모델이 멀티모달 데이터에 대해

[12:31] 추론할 수 있다는 점에서 매우 인상적입니다.

[12:36] 이제 텍스트-이미지 생성기를

[12:37] 살펴보기 전에

[12:39] 코딩 프로젝트 예제를

[12:42] 두 개 더 보여드리고

[12:44] 제가 왜 감명받았는지 설명하겠습니다.

[12:47] 이것은 육각형 안에서 튀는 공의 바이럴 버전입니다.

[12:50] 비슷한 프롬프트를 사용했지만

[12:52] 이번에는 20개의 공이 안에서 튀어야 하고

[12:55] 반지름이 모두 같아야 하며

[12:57] 번호가 매겨져 있어야 합니다.

[12:59] 중앙에서 떨어지기 시작하고

[13:01] 색상 구성도 있습니다.

[13:04] 또한 상호작용에 대해

[13:06] 매우 구체적인 요구사항이 있는데

[13:09] 벽면과의 상호작용뿐만 아니라

[13:11] 공들 간의 상호작용도 포함됩니다.

[13:13] 이 모든 내용을 하나의 HTML 파일에 담아야 합니다.

[13:16] 코드 관련 작업에서는 먼저 요구사항을 분석하는데,

[13:19] 이는 매우 훌륭한 접근 방식입니다.

[13:22] 제가 관찰한 바로는

[13:24] 생성되는 코드가 매우 간결하고

[13:27] 다른 작은 모델들과 비교했을 때

[13:30] 코드에 대한 설명이

[13:32] 그다지 자세하지 않습니다.

[13:35] 자, 여기 코드가 있는데요.

[13:38] OpenAI 모델 중에서는 처음으로

[13:40] 이 문제를 효과적으로

[13:43] 해결할 수 있는 모델입니다.

[13:44] 다시 실행해보겠습니다.

[13:46] 보시다시피 모든 것이 중앙에서 시작되고

[13:49] 이제 모든 요구사항을

[13:50] 따르고 있습니다. 총 20개의

[13:53] 공이 육각형 또는

[13:55] 칠각형 회전에 따라

[13:57] 움직이고 있습니다. 이게 정말

[14:00] 칠각형인지 확인해야겠네요. 네, 칠각형이 맞습니다.

[14:02] 모든 요구사항을

[14:04] 완벽하게 충족시켰습니다. 정말 인상적이네요.

[14:06] 다른 OpenAI 모델에서는 본 적이 없는 수준입니다.

[14:09] 제가 테스트해본 모델 중에서

[14:11] 이 정도 수준에 근접한 건 클로드(Claude) 뿐이었습니다.

[14:15] 물론 완벽한 모델은 아닙니다.

[14:18] 꽤 이상한 방식으로 실패할 수 있죠.

[14:22] 다른 결과들을 보고 나서

[14:24] 꽤 간단할 것이라 생각한

[14:26] 프롬프트가 있습니다.

[14:29] '물리 효과가 적용된

[14:31] 떨어지는 글자들의

[14:32] 자바스크립트 애니메이션을 만들어주세요.

[14:34] 글자들은 화면 상단에서

[14:36] 다양한 크기로 무작위로 나타나고

[14:39] 지구 중력의 영향을 받아 떨어지며

[14:41] 앞서 본 공과 마찬가지로

[14:43] 충돌 감지가 있어야 합니다.'

[14:45] 이런 요구사항들을 제시했고, 코드를 생성했습니다.

[14:48] 하지만 몇 가지 흥미로운

[14:50] 문제가 발생했네요.

[14:53] 코드를 붙여넣고 실행해보면

[14:56] 오픈타입 시그니처와 관련된

[14:58] 404 에러가 발생하는 것을 볼 수 있습니다.

[15:02] 이후 여러 번의 반복을 거쳐

[15:04] 해결책을 제안받았고

[15:07] 추가적인 대화를 나눴습니다.

[15:09] 다른 테스트로 넘어가야 해서 중단했지만

[15:12] 여기까지가 우리가 도달한

[15:15] 최종 결과입니다.

[15:18] 보시다시피 글자들은 떨어지고 있지만

[15:21] 제대로 보이지 않습니다.

[15:22] 다른 모델들에서 보통 보이는 현상은

[15:24] 글자 주변에 사각형이 있어서

[15:27] 글자가 가려지는 경우가 있었죠.

[15:31] 아마도 그런 문제일 수 있습니다.

[15:33] 하지만 4-5번의

[15:36] 다른 시도에도 불구하고

[15:38] O3는 제대로 작동하는 코드를

[15:41] 만들어내지 못했습니다.

[15:45] 자, 이제 마지막 예제로 넘어가보죠.

[15:48] 이건 정말 인상적이었는데

[15:49] 다른 모델에서는 본 적이 없는

[15:51] 결과였습니다. 프롬프트는

[15:55] 매우 간단했습니다. '텍스트를 이미지로

[15:57] 변환하는 앱을 만들어주세요. 사용자가

[16:00] 텍스트 프롬프트를 입력하면 Gemini Flash 2.0

[16:03] 네이티브 이미지 생성 API를 사용해

[16:06] 이미지를 만들고 사용자에게

[16:08] 보여줍니다. 이미지를

[16:10] 다시 생성할 수 있고

[16:12] 다운로드도 가능해야 합니다.' 이 프롬프트를

[16:15] 두 번 시도했는데, 두 번째는

[16:18] 모든 기능을 파이썬

[16:20] 파일 하나로 구현하고 싶어서였습니다.

[16:22] 네, 보통 제가 다른 LLM들로 이 프롬프트를 테스트할 때는

[16:25] 사용하려는 API의 문서를

[16:28] 같이 제공합니다. 이렇게 하면 LLM이

[16:30] 구현할 때 참조할 수 있죠.

[16:33] 하지만 이번에는 검색 기능이 있기 때문에,

[16:35] Gemini SDK가 최근에 변경된 상황에서

[16:38] 어떻게 작동하는지 보고 싶었습니다.

[16:41] 대부분의 모델들은 학습 데이터에서

[16:44] 이전 SDK만 봤었고,

[16:47] 문서를 제공해도 보통

[16:50] 새로운 SDK와 이전 SDK를

[16:53] 혼동하는 경우가 많았습니다.

[16:56] 이번에는 모델이

[16:59] 어떤 SDK를 사용할지 스스로 파악하고

[17:02] 문제가 생기면 어떻게 해결하는지

[17:05] 보고 싶었습니다.

[17:07] 자, 여기 내부 사고 과정을 보시죠.

[17:11] 먼저 사용자가 원하는 것은

[17:13] 텍스트를 입력하면

[17:16] Gemini Pro 2.0 API로

[17:18] 이미지를 생성하고 표시하는 앱입니다.

[17:22] 그 다음으로 FastAPI나

[17:25] Flask 같은 플랫폼을 사용해

[17:27] 작은 파이썬 웹 앱을 만들라고 했는데,

[17:30] 제가 어떤 것을 사용할지 지정하지 않았기 때문에

[17:33] 모델이 직접 선택해야 했습니다.

[17:35] 그래서 웹 검색을 시작했고

[17:38] Gemini Pro 2.0 이미지 생성 API를 찾아보았죠.

[17:42] 모델은 '최소 10개의

[17:45] 다양하고 질 좋은 소스가 필요하다'고 했고

[17:47] 이전 검색 결과도 있지만 Gradio나 Streamlit에 대해

[17:51] 더 알아볼 필요가 있다고 판단했습니다.

[17:53] 이게 두 번째 웹 검색이고

[17:55] 이것도 순차적인 도구 사용의 예시죠.

[17:58] 이 영상에서 계속 언급했듯이

[18:01] 이것은 더 에이전트적인 시스템처럼 보입니다.

[18:04] 아마도 모델 자체의 특성이거나,

[18:08] 제가 추측하기로는

[18:10] 여러 번의 시도를 권장하는 시스템인 것 같습니다.

[18:13] 그래서 모델이 '자료를 모았지만

[18:16] 최소 10개의 다양하고

[18:18] 질 좋은 소스가 필요하다'고 했죠.

[18:21] 첫 번째 검색을 했지만

[18:24] 소스가 충분히 좋지 않다고 판단해서

[18:25] 추가 검색을 하기로 했습니다.

[18:28] 이건 정말 인상적인데,

[18:30] 심층 검색 기능이 아닌

[18:33] 단순한 웹 검색만으로도

[18:35] 이런 판단을 했다는 게 놀랍습니다.

[18:38] 이 모든 정보를 바탕으로

[18:41] 구현 계획을 세우고

[18:43] 전체를 구현했죠.

[18:45] 흥미로운 점은

[18:48] 새로운 버전의 Gemini SDK를

[18:51] 사용하기로 결정했다는 겁니다.

[18:54] 새 버전을 사용했다는 걸 보여드리겠는데,

[18:58] 이건 정말 좋은 선택이었습니다.

[19:00] 하지만 설정을 할 때 실수가 있었는데,

[19:03] 일부 설정을

[19:05] 이전 SDK의 것을 사용했습니다.

[19:08] 이건 이전 버전에서

[19:11] configure 함수를

[19:13] 옛날 SDK로 사용하려 했던 거죠.

[19:15] 문제가 생겼고, 저는 단순히

[19:19] 잘못된 SDK를 보고 있다고

[19:21] 알려줬습니다. 몇 가지 일이 있었는데,

[19:23] 에러 메시지만 제공했더니

[19:25] 다시 계획을 세우고 두 번째 검색을 한 뒤

[19:29] 코드를 업데이트했습니다.

[19:33] 그런데 여기서 재미있는 점이 있는데,

[19:35] 코드를 실행하기 전에

[19:37] 앱이 어떻게 보일지

[19:40] 이미지를 만들어달라고 요청했습니다

[19:41] 네, 코드를 기반으로

[19:44] 앱이 어떻게 보일지 예상한 모습인데

[19:47] 실제로 만든 앱과 매우 유사합니다.

[19:50] 여기 실제로 만든 앱을 보시면

[19:53] 원본 앱 또는 실제 생성된 앱이 있습니다.

[19:56] 생성 설정에서

[19:58] 요청할 수 있는 이미지 수가 있고

[20:00] 현재는 한 개로 제한되어 있습니다.

[20:03] 예시 프롬프트도 추가했죠.

[20:05] 다시 돌아가서 보면 아마 더 깔끔하겠지만

[20:09] 제목은 정확히 동일합니다.

[20:11] 앱에 약간의 추가 텍스트가 있지만

[20:13] 전반적인 디자인은 매우 유사합니다.

[20:15] 몇 번의 반복 끝에 앱이 완전히

[20:18] 작동하게 되었고

[20:21] 제가 요청한 대로

[20:23] 모든 것이 단일 파일에 포함되어 있으며

[20:25] 기능이 예상대로 작동합니다.

[20:28] 정말 인상적인 점은

[20:31] SDK 버전을 분석하고

[20:33] SDK의 변경 사항을 파악할 수 있는

[20:36] 능력을 가지고 있다는 것입니다.

[20:38] 구글 검색이나 다른 검색 메커니즘이

[20:42] 정말 잘 작동하고

[20:44] 또한 사고 과정 안에서

[20:46] 순차적인 도구 호출 기능을 가지고 있어

[20:50] 매우 강력합니다.

[20:52] 물론 이것도 한 번에

[20:55] 모든 것을 완성하지는 않았습니다.

[20:58] 예를 들어

[20:59] 여기 설정 기능이 있는

[21:01] 초기 이미지가 있는데

[21:03] 오류 메시지를 제공하면

[21:05] 검색을 다시 수행하고

[21:08] 그 정보를 사용하여

[21:10] 응답을 업데이트할 수 있습니다.

[21:14] OpenAI가 이것을 코딩 IDE에 통합한다면 어떨까요?

[21:18] OpenAI가 윈드서프와 협상 중이라는

[21:21] 소문이 있는데

[21:24] O3와 같은 모델의

[21:26] 코딩 또는 에이전트 코딩 기능을

[21:29] 윈드서프에 통합하는 것은

[21:32] 정말 놀라울 것 같습니다.

[21:35] 특히 OpenAI가

[21:36] 이러한 추론 모델을 기반으로

[21:40] 제품을 만들 수 있다면 말이죠.

[21:42] OpenAI의 Codex CLI도 있는데

[21:46] 이는 Anthropic의 Cloud Code에 대한

[21:49] 대응으로 보입니다.

[21:51] 이에 대한 실제 소프트웨어 개발에서의

[21:54] 성능을 확인하는 영상을

[21:56] 제작할 예정입니다.

[21:58] 관심 있으시다면

[22:01] 채널 구독 부탁드립니다.

[22:03] 추론 능력을 specifically 테스트하는

[22:05] 또 다른 영상이 있을 예정인데

[22:07] 특히 misguided attention 데이터셋과

[22:09] 이미지에 대한

[22:11] 추론 능력을 살펴볼 것입니다.

[22:14] 지금까지의 결과는

[22:16] 꽤 좋아 보입니다.

[22:18] 이런 주제에 관심이 있으시다면

[22:20] 채널 구독 부탁드립니다.

[22:22] 이제 벤치마크에 대해 이야기해보죠.

[22:25] 몇몇 독립적인 벤치마크 결과가

[22:27] 나오기 시작했는데

[22:29] Gemini 2.5 Pro와 비교했을 때

[22:31] 특히 OpenAI가 강조한

[22:34] 벤치마크에서 꽤 좋은 성능을 보입니다.

[22:37] 예를 들어,

[22:39] humanities last exam이 있는데

[22:42] 이것은 텍스트 버전이고

[22:45] multi-challenge benchmark enigma evolves가 있습니다.

[22:48] 이것들은 커뮤니티에서 수행한

[22:51] 벤치마크인데

[22:53] 성능 대비 비용 측면에서 Gemini 2.5

[22:56] Pro는 여전히 O3와 비교했을 때

[22:59] 비용 면에서 더 나은 편입니다.

[23:02] 예를 들어, 이것은 블로그 포스트나

[23:05] 실제로는 Reddit 게시물인데요,

[23:07] 원본 포스터의 링크를 공유하겠습니다.

[23:11] 2025년 04 Mini가 성능 대비

[23:15] 비용이 가장 좋은 모델입니다.

[23:18] Gemini는 O3보다 뒤처지지만,

[23:21] 70에서 100점 사이만 보고 있다는 점을 기억하세요.

[23:24] 하지만 Gemini의 비용이 확실히 더 저렴합니다.

[23:28] PhD 수준의 질의응답을 위한

[23:31] GPQA에서는 Gemini가

[23:33] O3와 04 Mini보다 훨씬 저렴한 비용으로

[23:37] 더 좋은 성능을 보여줍니다.

[23:41] 이것은 또 다른 벤치마크인 MMU입니다.

[23:44] 보시다시피

[23:46] O3가 상대적으로 더 나은 성능을 보이지만

[23:50] Gemini는 이러한 벤치마크에서

[23:53] 훨씬 낮은 비용으로

[23:55] 비슷한 수준의 성능에 도달하고 있습니다.

[23:57] 하지만 코드 관련 특화 분야인

[23:59] 폴리글랏에서는 O3가 새로운 표준이 되었습니다.

[24:03] 물론 훨씬 높은 비용이 든다는 점이 있지만요.

[24:05] 비용을 제외하고, 제가 직접 테스트해본 결과

[24:09] 정말 훌륭한 코딩 모델인 것 같습니다.

[24:11] 하지만 이게 AGI일까요? 전혀 아닙니다.

[24:15] 왜냐하면 정말 좋은 코딩 모델에서

[24:19] 기대하지 않을 정도의

[24:21] 어리석은 실수들을 하기 때문입니다.

[24:23] 하지만 도구를 사용하고 에이전트 워크플로우를

[24:26] 다루는 능력은 확실히

[24:29] 이전에는 본 적 없는 수준입니다.

[24:31] 특히 추론 모델로서는요.

[24:32] 그래서 이것은 정말 큰 가치가 있다고 생각합니다.

[24:35] 그리고 다시 말하지만,

[24:38] 현재 사용 가능한 벤치마크에서

[24:40] 코딩 능력이 최고 수준입니다.

[24:42] 여러분이 이 새로운 모델로

[24:45] 무엇을 만들지 정말 기대됩니다.

[24:48] 여러분의 경험은 어떤가요?

[24:50] Gemini 2.5 Pro와 비슷한 성능을 보시나요?

[24:54] 더 좋은가요, 더 나쁜가요?

[24:56] 아래 댓글 섹션에 의견을 남겨주시고

[24:58] 이 새로운 릴리즈에 대한

[25:00] 생각을 공유해주세요.

[25:02] 이 영상이 도움이 되었길 바랍니다.

[25:05] 시청해주셔서 감사하며, 다음 영상에서 뵙겠습니다.