OpenAI dot 첫 사용기, 내 블로그 운영까지 맡길 수 있을까

2026년 9월 30일, OpenAI의 dot을 처음 사용했다. 전날 OpenAI는 상시 작동 에이전트인 dots를 발표하고 지원 지역과 요금제에 순차적으로 제공하기 시작했다. OpenAI 발표 VECTORLOG에 먼저 쓴 소개 글은 발표 자료를 읽고 정리한 분석이었다. 이번 글은 실제로 dot과 대화하고, 내가 운영하는 사이트의 글 발행 준비까지 진행해본 첫 기록이다.

첫 대화에서 dot은 연결된 이메일을 살펴본 뒤 호스팅 사용량과 비용에 관한 이슈를 조사해보자고 제안했다. 내가 이미 알고 있던 문제였다. 새로운 문제를 발견한 것은 아니지만, 별도로 조사 요청을 하기 전에 내 업무 자료에서 후속 검토할 일을 가져왔다는 점이 이번 경험의 출발점이다.

이런 제안은 기존 ChatGPT에서도 가능한 것 아닌가. 그렇다면 dot을 어디에 써야 하는가.

제품이 지향하는 모습은 OpenAI 공식 소개 영상에서 볼 수 있다. 실제 사용 결과와는 구분해서 봤다.

기존 ChatGPT와 무엇이 다른가

내가 처음 확인하고 싶었던 것은 “기존 GPT의 챗, Work, 예약 기능, 메타의 MUSE, Grok Bot과 무슨 차이가 있어?”였다. 새 이름을 붙인 서비스가 늘어날수록, 실제 업무에서는 어떤 창을 열어야 하는지부터 구분할 필요가 있다.

공식 안내를 기준으로 정리하면 Chat은 질문하고 생각을 발전시키는 대화에, Work는 조사·분석·문서처럼 여러 단계를 거쳐 결과물을 만드는 일에 초점을 둔다. Chat·Work 안내 Tasks는 정해진 시간에 실행하는 작업뿐 아니라 변경 사항을 살피거나 지원되는 앱의 이벤트에 대응하는 작업도 제공한다. Tasks 안내

dot은 사용자와 계속 대화하면서 연결된 자료와 진행 중인 일을 바탕으로 다음 행동을 제안하고 작업을 이어가는 개인 에이전트로 소개된다. 다만 ‘먼저 연락한다’거나 ‘오래 걸리는 일을 한다’는 문장 하나만으로 다른 기능과 경계를 그을 수는 없다. 기능이 겹치는 부분이 있고, 실제 사용할 수 있는 범위도 요금제와 연결한 앱, 권한에 따라 달라진다.

내 첫 경험에 대입하면 구분이 조금 구체적이다. 호스팅 문제를 질문하고 설명을 듣는 것은 대화로 시작할 수 있다. 관련 자료를 모아 분석 보고서를 만드는 것은 결과물이 정해진 작업이다. 특정 조건을 정해 반복 확인하는 것은 예약·이벤트 기반 작업으로 설계할 수 있다. 이번에 dot이 보여준 것은 그보다 앞단에서 내 자료를 보고 “이 일을 살펴보자”고 가져온 모습이었다.

이 제안이 계속 유용하려면 다음 단계가 필요하다. 내가 이미 아는 사실인지, 지금 확인할 이유가 있는지, 판단에 필요한 근거가 무엇인지까지 좁혀줘야 한다. 알림을 받았다는 사실만으로 업무가 진전됐다고 평가할 수는 없다.

Muse와 Grok Bot도 함께 살펴봤다. Meta는 Muse가 사용자의 목표를 돕고 먼저 아이디어를 제안하며 자체 가상 컴퓨터에서 작업한다고 설명한다. Grok Bot은 지속되는 맥락과 클라우드 컴퓨터, 여러 Bot의 협업을 명시한다. 자체 실행 환경이나 백그라운드 작업을 dot만의 특징으로 소개하면 비교가 부정확해진다.

이 비교는 공식 문서를 기준으로 했다. 실제 선택에는 같은 과제를 맡겼을 때의 결과와 수정·승인 과정까지 확인이 필요하다.

내 업무에 대입해 간단히 정리하면 아래와 같다. 기능의 독점 여부나 성능 순위가 아니라, 어떤 일을 맡길지 고르는 기준이다.

여러 역할을 나누면 글이 더 나아질까

그다음 질문은 기능 목록보다 작업 방식에 가까웠다. Grok Bot처럼 여러 작업자가 팀으로 움직이는 방식이 가능하다면, 블로그를 쓸 때도 긍정과 부정 같은 역할을 나눠볼 수 있을까.

내가 관심을 둔 구성은 찬성, 반대, 팩트체크, 편집이다. 하나의 아이디어를 놓고 찬성 역할은 활용 가능성과 근거를 찾고, 반대 역할은 성립하지 않는 조건이나 빠진 비용을 짚는다. 팩트체커는 제품 발표와 실제 제공 기능을 대조하고, 편집자는 독자에게 필요한 내용만 남기는 식이다. 다음에 직접 시험해보고 싶은 방식이다.

여러 역할이 있다는 이유만으로 검토가 깊어지는 것은 아닐 것이다. 같은 자료를 읽고 비슷한 문장을 네 번 쓰면 분량만 늘어난다. 찬성 역할이 가져온 근거에 반대 역할이 실제로 반론을 제기하는지, 팩트체커가 확인하지 못한 내용을 보류하는지, 편집자가 그 차이를 지워버리지 않는지를 봐야 한다.

그렇다면 VECTORLOG도 맡길 수 있을까

대화가 이어지면서 나는 dot이 VECTORLOG를 스스로 키워볼 수 있는지, PeterOS를 통해 글도 발행할 수 있는지 물었다. 추상적인 활용법을 묻는 데서 내가 쓰는 도구와 실제 운영 과제를 연결하는 쪽으로 넘어갔다.

VECTORLOG를 운영하는 목적은 AI 소식을 모으는 데에만 있지 않다. 직접 사용한 경험과 그 과정의 판단을 쌓아두는 아카이브이면서, 구독자와 고객, 협업자가 내가 어떤 문제를 어떻게 다루는지 볼 수 있는 포트폴리오가 되길 바란다. CRM과 연결해 관계를 이어가는 접점으로도 생각하고 있다.

그래서 글이 늘어나는 것과 사이트가 성장하는 것은 따로 봐야 한다. 공식 발표를 빠르게 정리하는 글과 직접 써본 기록은 필요한 재료가 다르다. 발표 분석에는 정확한 출처와 적용 범위가 필요하고, 경험 글에는 실제로 한 요청과 얻은 결과, 중간에 고친 내용이 있어야 한다. 사용하지 않은 기능을 사용기처럼 쓰면 이 아카이브의 목적부터 흐려진다.

운영 구상으로는 오전 8시에 News, 오후 1시에 사용 경험을 다루는 흐름도 이야기했다. 현재 실행 중인 자동 발행 일정은 아니다. 특히 사용 경험은 매일 정해진 시각이 온다고 자동으로 생기는 재료가 아니다. 기록할 만한 실험이 있었는지부터 확인해야 한다.

이번에는 구상을 이야기하는 데서 한 단계 더 나아가, PeterOS를 통해 새 AI 글을 발행해달라고 구체적으로 요청했다. dot의 클라우드 브라우저에서 직접 로그인을 마쳤고, dot은 PeterOS의 Today와 Publishing 화면을 확인했다. 이어 VECTORLOG의 새 작업을 만들고, 이 글의 방향과 근거를 담은 Editorial Brief를 저장했다. 내가 직접 확인한 경험을 중심에 두고, 아직 해보지 않은 활용법은 계획으로 구분하는 방향이다.

2026.09.30. PeterOS에 저장한 이 글의 Editorial Brief. 직접 확인한 경험과 아직 검증하지 않은 부분을 나눠 기록했다.

출처: 허태현 · PeterOS 실제 작업 화면

여기서부터는 검증할 지점이 분명해진다. 작성한 원고가 편집기에 정확히 들어가는지, 제목과 본문·출처가 의도한 형태로 보이는지, 발행 후 실제 페이지에서도 같은 내용을 확인할 수 있는지다. 글을 만들 수 있다는 설명과 내 사이트에서 발행이 끝났다는 사실 사이에는 이런 확인 과정이 있다.

글을 처음 공개한 뒤에는 PeterOS의 배포 확인 기능과 실제 공개 페이지에서 본문·썸네일·작업 캡처가 표시되는 것을 확인했다. 아래는 이번 한 편이 발행된 경로다. 정기 자동 운영이나 성장 효과까지 검증한 것은 아니다.

2026.09.30. 이 글의 실제 발행 흐름. 방향과 로그인은 Peter가, 원고 준비와 발행 작업은 dot이 수행했고 중간에 문체·이미지 피드백을 반영했다.

출처: VECTORLOG · 실제 작업 기록을 바탕으로 제작

글을 맡긴 뒤에도 내가 정할 것이 있었다

발행을 부탁한 뒤에는 글의 기준을 다시 설명했다. 언더독스의 블로그 운영 사례를 참고 자료로 주고, 이 정도 밀도의 글을 원한다고 말했다. 기존 글들은 기능 구현에 막히거나 내가 도구를 충분히 활용하지 못해 아쉬움이 남아 있었다. 이번에는 기능 설명을 길게 붙이는 것보다 실제로 무엇을 물었고, 무엇을 맡겼고, 어디에서 사람이 개입했는지가 드러났으면 했다.

문체도 따로 이야기했다. 최대한 AI가 쓴 티가 나지 않고, 직접 경험한 사람이 작성한 느낌을 원했다. 오늘 내가 던진 질문과 실제 작업 장면이 글의 중심이 되어야 한다고 봤다.

썸네일도 마찬가지였다. 그동안은 번거로워 같은 형태에 글자만 바꿔 올렸지만, 이제는 글의 성격을 보여주는 이미지와 문구가 필요했다. 이번 글에는 ‘내 블로그도 맡길 수 있을까?’라는 질문을 넣은 별도 이미지를 준비했다. 채팅에서 편집 화면으로 이어지는 콘셉트 이미지이고, 위의 PeterOS 캡처는 실제 작업 화면이다. 둘의 용도는 구분했다.

이 과정에서 내가 맡긴 일은 단순히 원고 한 편을 만드는 데서 끝나지 않았다. 어떤 글을 내 이름으로 남길지, 어디까지를 직접 해본 일로 쓸지, 어떤 화면을 근거로 보여줄지도 함께 정해야 했다.

다음 기록에는 무엇을 남길 것인가

앞으로 검증해보고 싶은 일은 세 가지다. 하나는 앞서 이야기한 역할별 콘텐츠 검토다. 다른 하나는 이번 호스팅 사례처럼 이미 알고 있는 운영 문제를 조사 가능한 상태로 정리하는 일이다. 마지막은 실제 사용 과정을 VECTORLOG의 글과 포트폴리오로 남기는 일이다.

첫날의 대화는 이메일에서 시작해 VECTORLOG의 발행 준비까지 이어졌다. 그 사이 내가 한 일은 새 기능의 설명을 듣는 것에서, 어떤 작업을 맡길지 정하고 실제 도구에 연결하는 것으로 바뀌었다. 호스팅 문제 해결이나 방문자 증가 같은 성과는 아직 확인하지 못했다.

다음 글에서 확인할 것은 제안이 어떤 결과물로 이어졌는지, 발행 과정에서 무엇을 수정했는지, 내가 검토해야 할 일이 얼마나 남았는지다. VECTORLOG에는 발표가 약속한 가능성과 직접 확인한 결과 사이의 과정을 남기려 한다. 이번 기록은 그 첫 번째다.