AI를 많이 쓸수록 채팅창을 벗어나게 된다

AI를 처음 많이 쓰기 시작했을 때는 채팅창이면 충분했다.

하고 싶은 일을 적고, 결과를 받고, 마음에 들지 않으면 다시 설명하면 됐다. 자연어만으로 원하는 작업을 시킬 수 있다는 것 자체가 기존 소프트웨어와는 완전히 다른 경험이었다.

그런데 사용량이 늘어나면서 이상한 일이 생겼다.

AI에게 더 많은 일을 맡기고 있는데, 오히려 내가 같은 설명을 반복하는 시간이 늘어났다.

“이 형식으로 만들어줘.” “여기까지 진행했어.” “이 상태에서 다음 단계로 넘어가줘.” “아니, 전에 정한 기준을 유지해야 해.”

한두 번이라면 문제가 아니다. 하지만 같은 종류의 일을 매일 반복하기 시작하면 채팅의 자유로움이 오히려 번거로움으로 바뀐다.

최근 Peter OS를 만들면서 이 문제를 꽤 직접적으로 겪었다.

처음에는 대화만 잘하면 될 줄 알았다

Peter OS에서 콘텐츠 발행 시스템을 만들기 시작했을 때도 처음부터 복잡한 화면이 있었던 것은 아니다.

내가 원하는 방향을 AI에게 설명하고, 결과를 받아서 다시 수정하면 된다고 생각했다.

하지만 VECTORLOG 글을 반복해서 기획하고 작성하고 발행하다 보니 매번 설명해야 하는 내용이 생겼다.

어떤 종류의 글인지, 실제 경험이 있는지, 어떤 Source를 사용할지, 어떤 결과물을 받아야 하는지, 이미지가 필요한지, 최종 글을 어디서 확인하고 어떻게 발행할지 같은 것들이다.

한 번의 글을 만드는 데는 대화로도 충분했다.

문제는 두 번째, 세 번째 글이었다.

이미 정해진 작업 순서가 있는데도 매번 대화를 통해 그 순서를 다시 설명하고 있었다.

그때부터 생각이 바뀌었다.

대화를 더 잘하는 게 아니라, 반복되는 대화를 없애야 했다.

그래서 대화를 화면과 버튼으로 바꾸기 시작했다

Peter OS의 Editorial Workflow도 그런 과정을 거쳐 바뀌었다.

Editorial Brief에서 방향을 입력하고, GPT Handoff로 필요한 맥락을 정리하고, 완성된 글은 Final Package로 가져온다. 이후 Asset을 연결하고 Compiled Preview에서 실제 발행 결과를 확인한 뒤 Publish한다.

최근에는 Preview에서 제목이나 본문을 직접 수정하면 SEO/AEO/GEO 관련 메타데이터도 그 내용에 맞춰 따라오도록 구조를 바꿨다.

이 과정에서 내가 계속 했던 일은 AI 기능을 더 많이 붙이는 것이 아니었다.

오히려 사람이 반복해서 설명하던 부분을 UI와 워크플로로 옮기는 일이었다.

반복되는 설명이 많아질수록 대화를 계속 이어가는 것보다 작업 순서를 인터페이스로 고정하는 편이 자연스러워진다.

Chat에서는 매번 현재 상태를 설명해야 한다.

Workflow에서는 현재 상태가 이미 화면에 존재한다.

이 차이가 AI 사용량이 많아질수록 꽤 크게 느껴졌다.

GitHub도 비슷한 이야기를 꺼냈다

2026년 9월 24일 GitHub는 공식 블로그에 ‘When chat is the wrong UI’라는 글을 공개했다.

GitHub의 설명은 꽤 직설적이다. Chat은 사용자가 AI로 무엇을 하려는지 미리 알 수 없을 때 범용 인터페이스로 잘 작동한다. 하지만 사용자는 자신이 무엇을 하려는지 알고 있고, 그런 상황에서는 chat이 종종 적합하지 않은 UI가 될 수 있다는 것이다.

GitHub Copilot 앱의 Canvas가 그 대안 중 하나다.

GitHub에 따르면 Canvas는 Copilot 앱 내부에서 실행되는 작은 full-stack application이다. Agent와 양방향으로 통신할 수 있고, third-party API를 호출하거나 사용자의 로컬 머신에서 코드를 실행하는 인터페이스도 만들 수 있다.

흥미로운 건 기능 자체보다 GitHub가 설명하는 사용 방식이다.

반복 작업을 계속 agent에게 요청하는 대신, agent에게 필요한 도구를 한 번 만들게 하고 이후 상호작용은 그 도구를 통해 처리할 수 있다는 것이다.

GitHub는 이를 token 사용 관점에서도 이야기한다. 모든 동작을 agent에게 계속 시키는 것보다 앞으로 반복해서 사용할 도구를 만드는 편이 나을 수 있다는 주장이다.

나는 GitHub Copilot Canvas 자체를 직접 사용해본 것은 아니다.

다만 그 글을 읽으면서 최근 Peter OS를 만들며 계속 했던 일이 떠올랐다.

결국 같은 방향이었다.

AI에게 계속 말해야 한다면 아직 시스템이 아닐 수 있다

AI를 잘 쓰는 방법을 이야기하면 대개 프롬프트가 먼저 나온다.

무엇을 어떻게 설명해야 하는지, 어떤 컨텍스트를 줘야 하는지, 어떤 역할을 지정해야 결과가 좋아지는지를 고민한다.

물론 중요하다.

하지만 같은 프롬프트를 반복해서 사용하고, 같은 수정 지시를 반복하고, 매번 같은 순서로 작업을 진행한다면 다른 질문을 해볼 필요가 있다.

이걸 계속 대화로 해야 할까?

예를 들어 글 하나를 발행할 때마다 AI에게 “이제 제목을 확인하고, 다음에는 이미지를 넣고, Preview를 보여주고, 마지막에 SEO도 다시 맞춰줘”라고 말하고 있다면 그 과정은 이미 하나의 작업 흐름이다.

그렇다면 자연어로 반복해서 설명하는 것보다 화면과 버튼으로 고정하는 편이 더 자연스럽다.

AI는 그 화면 뒤에서 판단과 생성이 필요한 순간에만 등장하면 된다.

내가 Peter OS를 만들면서 조금씩 도달한 결론도 여기에 가깝다.

AI가 모든 인터페이스가 될 필요는 없다.

오히려 AI가 잘 보이지 않는 곳으로 내려가는 것이 더 편할 때가 있다.

채팅은 사라지는 게 아니라 역할이 달라진다

그렇다고 채팅 인터페이스가 사라질 거라고 생각하지는 않는다.

새로운 일을 시작하거나, 문제 자체가 무엇인지 아직 모를 때, 자유롭게 생각을 주고받을 때는 채팅만큼 좋은 인터페이스도 드물다.

나도 새로운 아이디어를 정리하거나 처음 방향을 잡을 때는 여전히 대화형 AI를 가장 많이 쓴다.

대신 일이 반복되기 시작하면 기준이 달라진다.

한 번의 대화였던 것이 반복 업무가 되고, 반복 업무가 작업 순서가 되고, 그 작업 순서가 어느 순간 UI가 된다.

여기서 AI의 역할도 달라진다.

처음에는 화면 그 자체였던 AI가 점점 화면 뒤에서 움직이는 엔진에 가까워진다.

사람은 어떤 일을 할지 선택하고, 결과를 확인하고, 필요한 순간에 판단한다. AI는 그 사이에서 생성하고, 정리하고, 연결하고, 자동화한다.

반복되는 대화는 인터페이스를 만들 신호다

요즘 내가 AI를 쓰면서 보는 기준이 하나 더 생겼다.

같은 설명을 계속 하고 있는가?

그렇다면 더 좋은 프롬프트를 만들기 전에 그 과정 자체를 시스템으로 만들 수 있는지 먼저 생각해본다.

매번 같은 파일을 넣고 있다면 업로드 화면을 만들 수 있다.

매번 같은 형식을 요구한다면 입력 필드를 만들 수 있다.

매번 같은 순서로 확인한다면 Preview와 버튼을 만들 수 있다.

그리고 정말 판단이 필요한 부분만 AI에게 넘기면 된다.

AI를 많이 쓰면서 채팅을 덜 쓰게 된다는 말은 조금 역설적으로 들린다.

하지만 실제로는 AI를 덜 사용하는 것이 아니다.

AI가 더 깊게 시스템 안으로 들어가는 것이다.

처음에는 내가 AI에게 말을 걸었다면, 이제는 내가 만든 작업 흐름 속에서 필요한 순간마다 AI가 움직인다.

아마 앞으로 AI를 잘 쓴다는 말도 점점 이런 의미에 가까워질 것 같다.

채팅을 얼마나 많이 하는가가 아니라, 반복되는 대화를 얼마나 좋은 시스템으로 바꿨는가.