https://www.latent.space/p/o1-skill-issue
o1 isn’t a chat model (and that’s the point)
How Ben Hylak turned from ol pro skeptic to fan by overcoming his skill issue.
www.latent.space
swyx입니다: 2025년의 첫 게스트 포스트¹를 소개하게 되어 기쁩니다! 이 글은 gdb, Ben, 그리고 Dan의 페이지에서 뜨거운 토론을 불러일으켰습니다.
지난 10월 o1이 출시되고 12월에 o1 pro/o3가 발표된 이후, 긍정이든 부정이든 다양한 의견이 쏟아져 나왔죠. 저희는 o1 Pro에 대한 부정적 기류가 가장 깊어졌을 때 강력한 긍정적 입장을 취했고, OpenAI가 곧(몇 주 내 출시 루머) 선보일 월 2,000달러짜리 에이전트 제품에 필요한 요소들을 짚어봤습니다. 그 후 o1은 LMArena의 모든 리더보드에서 안정적으로 1위를 지키고 있고(팟캐스트에서 언급했듯 곧 기본 스타일 컨트롤 기능도 추가될 예정입니다), 현재까지 흥미로운 행보를 이어가고 있습니다.
한편 저희는 Ben Hylak이 Apple VisionOS를 다루는 작업에 주목해왔고, 그를 World’s Fair에 초청해 직접 의견을 들었습니다. 이후 Ben은 Dawn Analytics를 창업하고 o1에 대한 거침없는 생각들을 계속 공개해왔습니다. 처음엔 아주 큰 회의론자로 출발했지만, 점차 o1을 일상적으로 사용하는 모습이 인상적이었습니다. 저희는 이렇게 ‘생각을 바꾸는 사람들’을—단어 그대로 ‘사고를 전환’하는 의미에서도, ‘상대방의 관점을 뒤집어주는’ 의미에서도—매우 흥미롭게 지켜보고 있습니다. 그리고 전 세계 수많은 사람들이 채팅형 패러다임에서 탈피해, 추론 중심의 새로운 시대와 Devin(이전에 WF에서 연사로 참여, 현재 GA) 같은 월 수백 달러대 프로슈머용 AI 제품으로 넘어가는 데 어려움을 겪고 있는 지금, 비슷한 고민이 곳곳에서 이어지고 있다고 생각합니다. 여기서 저희가 전하고 싶은 이야기를 공유합니다.
공지(PSA): 엄청난 관심과 지원(지원 대비 15배 이상의 경쟁률)으로 인해, 저희는 내일 AI Engineer Summit에 대한 CFP(Call for Proposals)를 마감합니다. 아직 제출하지 못하셨다면 마지막 기회를 놓치지 마세요! 많은 분들께서 지원해주셔서 감사드리며, 조만간 모든 분들께 연락드리겠습니다.
o1은 채팅 모델이 아니다 (그리고 바로 그게 핵심이다)
어떻게 o1을 증오하던 내가, 이제 가장 중요한 질문을 할 때마다 매일 o1을 사용하게 되었을까?
내가 o1을 “제대로” 쓰는 법을 배웠기 때문이다.
https://x.com/sama/status/1877814065088663763
o1 pro가 발표되었을 때 나는 망설임 없이 구독했다. 월 200달러라는 가격이 아깝지 않으려면, 한 달에 1~2시간 정도의 엔지니어링 리소스를 대체해주기만 하면 된다(우리 Dawn 팀에서 추가 채용을 덜 할 수 있다면 금상첨화!).
그런데 하루 종일 모델을 열심히 써본 뒤 내린 결론은 “쓰레기”라는 것이었다.
질문을 할 때마다 5분씩 기다려야 했고, 돌아오는 답변은 온갖 자가모순으로 뒤범벅된 거대한 텍스트 덩어리였다. 게다가 요청하지도 않은 아키텍처 다이어그램이나 장단점 목록까지 잔뜩 달려서 말이다.
o1이 내 질문에 대답하면서 여러 번 스스로를 반박하고 있었다.
나는 트위터에 이를 그대로 썼고, 많은 사람들이 동의했다. 하지만 더 흥미로웠던 건, 그중 일부는 반대로 o1이 굉장히 뛰어나다며 완전히 반대되는 의견을 내놓았다는 점이다. 실제로 그들은 이 모델에 완전히 감탄한 상태였다.
물론, 사람들은 보통 OpenAI가 무언가를 발표할 때마다 크게 열광하곤 한다(‘부정적으로’ 화제 몰이를 하는 것 다음으로 바이럴을 일으키는 가장 좋은 전략이기도 하다).
하지만 이번 경우는 사뭇 달랐다. 그들의 반응은 현장의 한복판에서 직접 부딪히고 있는 사람들에게서 나온 것이기 때문이다.
내가 반대 의견을 가진 사람들과 더 많이 대화해볼수록, 내가 완전히 잘못 쓰고 있었음을 깨달았다:
나는 o1을 채팅 모델처럼 사용하고 있었지만, o1은 채팅 모델이 아니었다.
o1을 제대로(?) 활용하는 방법
o1이 채팅 모델이 아니라면—그렇다면 대체 무엇일까?
나는 o1을 일종의 “리포트 생성기(report generator)”로 본다. 충분한 맥락(context)을 제공하고 원하는 결과물이 무엇인지 명확히 알려주면, 한 번에 정답을 깔끔하게 뽑아내는 경우가 많다.
swyx의 주석:
OpenAI가 o1 프롬프트 작성법에 대한 조언을 공식적으로 내놓긴 했지만, 저희가 보기에는 여전히 불완전합니다. 실제로 o1과 o1 pro를 써본 ‘현장 경험’을 담은 일종의 ‘Missing Manual(누락된 설명서)’로 이 글을 봐주셔도 좋겠습니다.
1. 프롬프트가 아니라 브리핑을 작성하라
가능한 한 방대한 양의 정보를 제공해야 한다. “많이”라고 했을 때 떠오르는 양의 10배 이상은 넣는다고 생각하면 된다.
Claude 3.5 Sonnet이나 4o 같은 일반적인 채팅 모델을 쓸 때는, 보통 간단한 질문 하나와 약간의 맥락만 주고 시작한다. 모델이 더 많은 정보가 필요하면 스스로 요청하거나(혹은 답변을 보면 필요하다는 게 분명히 드러난다), 그때 필요한 내용을 하나씩 추가하는 식으로 요구사항을 확장하고 수정해가며 원하는 결과물을 얻는다. 마치 도예 공예처럼 모델과의 상호작용을 통해 조금씩 형태를 잡아가는 방식이다. 그러다 보면 질문도 점점 짧고 대충이 되어도 어느 정도 괜찮은 답이 나오게 된다.
하지만 o1은 사용자가 대충 질문을 던지면 그대로 받아들이고, 맥락 정보를 적극적으로 캐내려 하지 않는다. 결국 사용자가 직접, 가능한 한 많은 맥락을 o1에게 ‘밀어넣어야’ 한다.
예컨대, 단순한 엔지니어링 질문을 한다고 해도 다음과 같은 정보를 모두 추가해보자:
- 실패했던 모든 시도와 그 실패 이유
- 데이터베이스 스키마 전부 (덤프 형태)
- 회사가 무슨 일을 하고 규모는 어떤지(회사 내부에서만 쓰는 전문 용어가 있다면 정의까지)
간단히 말해, o1을 막 채용된 신입사원이라고 생각하면 된다. 다만 유의할 점은, o1이 “얼마나 깊이 사고해야 하는지” 자체를 잘못 판단하는 실수를 저지르기도 한다는 것이다. 예를 들어 매우 단순한 작업에도 이유 없이 무의미한 사고의 ‘토끼굴’로 빠져들 수 있다. (참고로 o1 API에서는 reasoning_effort를 low/medium/high로 지정할 수 있지만, ChatGPT 사용자에게는 이런 기능이 노출되지 않는다.)
o1에게 맥락을 충분히 전달하기 위한 팁
- 음성 메모(Voice Memos) 앱 활용
맥이나 스마트폰의 음성 메모 앱을 켜고 1~2분 정도 문제 상황 전체를 말로 설명한 뒤, 그 녹취록(Transcript)을 복사해 붙이면 된다. - 맥락 노트 준비
나는 실제로 재사용할 긴 맥락 정보를 따로 모아두는 노트를 가지고 있다. 필요할 때마다 그 내용을 복사·붙여넣기 한다. - swyx: 나는 LS Discord에 올라온 Sarav의 Careless Whisper를 사용한다.
- 제품 내 AI 비서 기능 활용
최근 여러 제품에서 등장하는 AI 어시스턴트가 이런 맥락 정보를 추출·정리하는 과정을 훨씬 쉽게 만들어준다. 예를 들어 Supabase를 사용한다면, Supabase Assistant에게 관련 테이블, RPC 등 필요한 정보를 전부 요약하거나 덤프해달라고 시도해볼 수 있다.
swyx:
이 글의 도입부를 다시 쓴다면, “프롬프트에 10배 더 공들여라(spend 10x more in prompting)” 정도로 표현하는 편이 낫겠네요.
2. 목표에 집중하라: ‘무엇(WHAT)’을 정확하게 말하고, ‘어떻게(HOW)’는 최소화
이미 모델에 가능한 한 많은 맥락을 주입했다면—이번에는 결과물로 원하는 것이 무엇인지에 집중해서 설명하자.
일반적인 모델을 사용할 때는, 보통 “당신은 전문 소프트웨어 엔지니어입니다. 천천히, 신중하게 생각하세요”처럼 어떻게 답변해야 하는지(How)를 모델에 알려주는 쪽으로 학습되어 왔다.
하지만 o1을 제대로 활용하는 법은 정반대라고 느꼈다. 나는 모델에게 어떻게 할지는 지시하지 않고, 무엇을 할지만 말해준다. 그러고 나면 o1이 스스로 계획을 세우고 단계를 해결한다. 이것이야말로 자율적 추론(autonomous reasoning)의 목적이며, 사람이 직접 중간중간 검토하거나 지시하는 것보다 훨씬 빠를 수도 있다.
swyx의 조악한 일러스트
swyx의 전문가 팁(pro tip):
“좋은” 것과 “나쁜” 것에 대한 기준을 아주 구체적으로 세워두면, 모델이 스스로 출력을 평가하고 자기 오류를 교정할 수 있는 방식으로 활용할 수 있다. 즉, 프롬프트 안에 “LLM-판사(LLM-as-Judge)” 역할을 심어두고, 필요할 때마다 o1이 이를 돌려보도록 하는 셈이다.
이 작업을 잘 해두면, 차후 모델이 GA(General Availability) 상태에서 Reinforcement Finetuning을 진행할 때도 “LLM-판사”가 유용한 평가자로 쓰일 수 있다.
다만 이렇게 하려면, 정확히 내가 원하는 게 무엇인지를 명확히 알고 있어야 한다(또한, 프롬프트 하나당 오직 하나의 출력만 요청해야 한다—o1은 첫 단계에서만 추론할 수 있으므로).
말로는 쉬워 보여도, 막상 해보면 은근 어렵다! 예를 들어,
- 실제 프로덕션 환경에 특정 아키텍처를 구현하길 원했던 건지,
- 최소 테스트 앱을 만들길 원했던 건지,
- 아니면 가능한 옵션을 탐색해서 장단점을 나열하길 원했던 건지…
이 셋은 전혀 다른 요구사항이 된다.
그리고 o1은 종종 보고서(report) 형식의 해설을 덤으로 출력한다—숫자 헤딩과 서브헤딩까지 친절하게 달린 형태로 말이다. 만약 이런 설명이 필요 없고 “완성된 파일”만 보고 싶다면, 명시적으로 그렇게 지시해야 한다.
나는 이렇게 o1을 쓰는 방법을 익힌 뒤, 모델이 처음부터 “정답”을 뽑아내는 능력에 많이 놀랐다. (비용/지연 문제를 제외하면) 거의 모든 면에서 더 뛰어나다. 그중 특히 인상적이었던 순간 몇 가지를 간단히 공유해본다.
o1 사용법을 터득한 뒤로
o1을 어떻게 다뤄야 하는지 배운 다음, 이 모델이 “첫 시도부터 정답”을 뽑아내는 능력에 여러모로 깜짝 놀랐다. (비용/지연 문제를 제외하면) 사실상 모든 면에서 훨씬 뛰어난 느낌이다. 특히 아래와 같은 순간들이 인상적이었다.
3. o1이 잘하는 것, 그리고 아직 잘 못하는 것
o1이 잘하는 것
- 여러/전체 파일을 한 번에 ‘원샷’으로 작성
이게 단연코 o1의 가장 인상적인 능력이다. 나는 대량의 코드를 복사해 붙이고, 동시에 내가 만들고자 하는 것에 대한 맥락도 아주 많이 제공한다. 그러면 o1이 전체 파일(혹은 여러 파일)을 단숨에 만들거나 고쳐주는데, 보통은 오류가 거의 없으며 내 코드베이스에서 이미 사용 중인 패턴도 잘 따라간다. - 환각(hallucination)이 비교적 적다
전반적으로 혼동을 덜 일으킨다. 예컨대 o1은 (Claude가 종종 Postgres 구문과 혼동하는) ClickHouse나 New Relic 같은 독특한 쿼리 언어도 잘 다룬다. - 의학적 진단
내 여자친구가 피부과 의사여서, 지인들이 피부 문제로 사진을 보내오는 일이 잦다. 재미 삼아 o1에게도 같은 사진을 보여주곤 했는데, 보통은 3/5 정도 확률로 놀라울 만큼 정확한 진단을 내놓았다. 실제 의학 전문인이 보면 훨씬 유용할 텐데, 언제나 매우 정확한 감별진단(differential diagnosis)을 제시하더라. - 개념 설명
어려운 엔지니어링 개념을 예시와 함께 풀어내는 능력이 상당히 뛰어나다. 마치 긴 기사(아티클)를 통째로 생성하는 것 같은 느낌이다.
예를 들어 복잡한 아키텍처적 결정을 내려야 할 때, o1에게 다양한 방식의 설계안을 만들어 보게 한 다음 각각의 장단점을 비교하게 한다. 그 출력물을 PDF로 저장해놓고 마치 여러 사람의 제안서를 놓고 고민하듯 살펴볼 수도 있다. - 추가로: Evals(자동 평가) 사용
원래 나는 “LLM이 스스로의 출력을 평가(판정)하는 것”에 대해 회의적이었다. 왜냐하면 생성 모델과 동일한 실패 양상을 재현할 위험이 있기 때문이다. 그런데 o1은 꽤 가능성을 보여준다. 아주 간단한 맥락만으로도 생성된 결과가 타당한지 아닌지를 꽤 잘 가려낸다.
o1이 아직 잘 못하는 것
- 특정 문체/화법으로 글쓰기
일단 이 글은 o1로 작성한 것이 아니다!
o1은 특정 화법이나 문체로 글을 써야 할 때 특히 취약하다. 뭔가 늘 학술적·기업 보고서 같은 톤에서 벗어나지 못한다. 모델 내부의 “추론 토큰”이 이런 문체를 강하게 지향하도록 편향된 것 같다.
아래는 실제로 내가 이 글을 o1로 써보려고 여러 차례 시도했을 때 나온 결과물이다. 계속 bland(평범하고 밋밋한)한 보고서 형태로만 나오더라.
- 완전한 앱을 통째로 만드는 것
o1은 파일을 ‘원샷’으로 통째로 생성하는 데는 놀라울 정도로 뛰어나다. 하지만 트위터에서 간혹 보이는, “o1이 완전한 SaaS를 전부 만들어준다” 같은 지나친 낙관적 시연과는 달리, 실제로는 많은 반복(iteration) 없이는 완벽한 하나의 서비스를 뚝딱 만들어내지 못한다. 그래도 프론트엔드나 단순 백엔드 같은 특정 기능은 한 번에 통째로 만들어내는 경우가 꽤 많다.
(별도 주제) 리포트 생성기를 위한 인터페이스 설계에 관하여
지연(latency)은 우리가 어떤 제품을 쓸 때 느끼는 경험을 근본적으로 바꿔놓는다.
swyx: 맞아요. 지금은 AI 응답 속도만 해도 6단계 정도로 분류될 만큼 다양하죠.
- 우편과 이메일, 문자메시지의 차이는 결국 지연이 대부분을 차지한다.
- 음성 메시지와 전화의 차이도 지연 때문이다.
- 동영상과 화상회의(Zoom)의 차이도 마찬가지다.
나는 o1을 “리포트 생성기(report generator)”라고 부르는 이유가, 이 모델이 채팅 모델처럼 실시간 상호작용을 전제로 하지 않기 때문이다. 느낌상 이메일과 훨씬 더 흡사하다.
아직까지 o1의 제품 설계에서 이런 특성이 제대로 드러나지 않았다. 인터페이스도 좀 더 이 특성을 솔직하게 반영했으면 좋겠다. 만약 여러분이 o1 기반 제품을 만든다면, 다음과 같은 AI UX 팁을 고려해보면 좋을 것 같다:
- 응답에서 계층 구조(Hierarchy)를 쉽게 볼 수 있게 하라
미니 목차(table of contents) 같은 것을 보여주는 방식을 생각해보자. - 계층 구조를 쉽게 탐색할 수 있게 하라
일반적으로 o1의 응답은 화면 높이를 훌쩍 넘길 만큼 길어진다. Perplexity처럼 질문·답변을 각각 ‘페이지’ 단위로 구분해서 볼 수 있도록 하거나, 답변 안에서도 스티키 헤더나 접이식(collapse) 헤더 등을 구현해두면 훨씬 편리해진다. - 모델에게 제공하는 맥락(context)을 보기 좋게 관리하라
역설적이게도 Claude의 UI가 이 부분을 훨씬 잘 처리한다. 긴 텍스트를 붙여넣으면 별도의 첨부 파일(attachment)처럼 표시해주기 때문이다. ChatGPT Projects 기능은 Claude만큼 잘 작동하지 않는 듯해, 결국 나도 맥락을 매번 복사·붙여넣기 해야 했다.
추신:
ChatGPT에서 o1을 쓸 때는 버그가 굉장히 많다. o1이 어떤 식으로 추론하는지에 대한 설명은 코믹할 정도고, 종종 아예 응답을 못 내놓거나, 특히 모바일 앱에서는 잘 안 되는 경우가 많다.
케냐의 화창한 어느 날… 그리고 앞으로의 전망
어떤 식으로 이 모델들이 실제 사용될지, 개인적으로 매우 기대가 크다.
나는 o1이 처음으로 가능하게 해줄 제품들이 분명 있을 거라 생각한다. 예컨대 높은 지연(high-latency)을 전제로, 백그라운드에서 오래 걸리는 지능 작업을 수행하는 제품들 말이다.
“사용자가 5분을 기다릴 수 있는 작업”은 어떤 것인가? 1시간? 하루? 3~5 영업일은 어떤가?
나는 올바르게 설계만 된다면 의외로 할 수 있는 일이 많다고 본다.
모델이 점점 더 비싸질수록, 무작정 실험을 하기엔 비용을 정당화하기가 어려워진다. 순식간에 수천 달러를 태워버릴 수도 있으니 말이다.
현재 o1-preview나 o1-mini에서는 스트리밍이 지원되지만 구조화된 생성(structured generation)이나 시스템 프롬프트는 지원되지 않는다. 반면 정식 o1은 구조화된 생성과 시스템 프롬프트를 지원하지만, 아직 스트리밍은 지원되지 않는다.
응답이 오래 걸리다 보니, 스트리밍은 사실상 필수 요건처럼 느껴진다.
아무튼 2025년에 개발자들이 o1과 함께 실제로 어떤 작업을 하게 될지, 정말 기대된다.
swyx:
Ben, 좋은 글 고마워! 마지막 홍보 하나만 하자면—만약 o1을 이용해 에이전트를 만들거나, AI 엔지니어 팀을 리딩하고 있다면 AIES NYC에 꼭 지원해보길 추천해!
o1 모델을 효과적으로 쓰려면 다음과 같은 핵심 포인트를 기억하면 됩니다:
- 채팅형 모델이 아니다
- 짧게 묻고 답변을 받는 방식이 아니라, **‘리포트 생성기’**처럼 “처음부터 맥락을 잔뜩 넣어서 한 번에 원하는 결과물을 뽑아내는” 접근이 좋습니다.
- 프롬프트가 아니라 ‘브리핑’을 작성하라
- o1은 사용자가 별도로 맥락을 끌어내 주지 않으면 스스로 질문을 되묻지 않습니다. 따라서 필요한 모든 정보를 처음부터 한꺼번에 주입하세요.
- 실패했던 시도, DB 스키마, 회사 배경 등 — 신입사원에게 가르치듯 상세하게 써주면 좋습니다.
- 무엇을 원하는지(WHAT)에 집중하고, 어떻게(HOW)는 최소화
- “전문가처럼 답해라” “천천히 생각해라” 같은 지시보다는, **“어떤 결과물을 원하는가”**만 명확히 제시하는 편이 더 효과적입니다.
- 모델이 스스로 계획하고 추론해가며 단계를 해결하도록 맡기면, 오히려 정확도가 높아집니다.
- 구체적이고 단일한 목표 제시
- “설명만 해달라” “아키텍처를 짜달라” “완성된 코드를 달라” 등, 한 번의 프롬프트에서 하나의 요구사항만 확실히 지정하세요.
- 여러 요구사항을 한꺼번에 넣으면 모델이 혼동하거나 불필요하게 장황해질 수 있습니다.
- 형식·구조 제어
- o1은 기본적으로 보고서 형태(숫자 헤딩, 장단점 등)로 길게 답변하는 경향이 있습니다.
- 필요 없다면 **“해설은 빼고, 완성된 코드만 달라”**처럼 반드시 명시하세요.
- 지연(latency)과 비용 고려
- o1은 상대적으로 응답 시간이 길고 비용이 높을 수 있으므로, 정말 중요한 작업을 한 번에 처리하는 용도로 쓰는 것이 좋습니다.
- 최대한 맥락과 요구사항을 자세히 주어 재시도를 최소화하는 전략이 필요합니다.
- LLM-as-Judge(자가 평가) 기법 활용
- “좋은 출력 vs 나쁜 출력” 기준을 스스로 평가하도록 프롬프트에 심어두면, 모델이 출력을 자동으로 검증/개선하게 만들 수 있습니다.
- UI/UX에서 맥락과 답변 구조를 명확히
- o1의 답변은 길어지기 쉬우므로, 목차·접이식 헤더 등으로 답변을 쉽게 탐색할 수 있게 하는 인터페이스가 중요합니다.
- 붙여넣는 맥락 역시 별도의 ‘첨부’처럼 관리할 수 있으면 훨씬 편해집니다.
정리하자면, o1을 쓸 때는 ‘초반에 충분한 정보’를 ‘명확하게’ 주고, 원하는 결과물이 무엇인지 정확히 지정하여 한 번에 결과물을 뽑아내는 접근을 권장합니다. 이때 불필요한 지시는 최소화하되, 출력 형식이나 품질 기준은 분명히 지정해주세요. 이렇게 하면 o1이 길고 복잡한 작업도 의외로 한 번에 깔끔히 해결해줄 때가 많습니다.
