모두 첫 화면에 올라갈 만한 글이고, 최초 제출인 것으로 보임. 최신 기술 발표 알림을 설정할 만큼 관심이 있다면 어렵지 않게 할 수 있음. 기술을 이용해 게시물 노출을 조작하거나 HN을 악용한다면 우려할 일이지만, 그런 증거는 보이지 않음.

Codex에서도 이런 통합을 원하는 요청이 계속 나오는데, 두 연구소 모두 이를 받아들이려는 듯해 아쉬움. 복잡한 정치 문제나 여러 차례 대화를 이어가는 사업 전략, 새로운 개념 탐구처럼 사고와 조사가 필요한 질문은 Chat과 Work 모드에서 답변이 크게 달라짐.
코드를 주된 작업 수단으로 삼지 않는 질문에는 채팅·추론 제품의 실행 환경과 응답 유도 방식이 훨씬 적합함. 나도 코딩 에이전트를 늘 7개쯤 돌리지만, 생산성 열풍 때문에 먼저 생각하고 나중에 행동하는 AI UX가 퇴보할까 걱정됨.

현재 Chat은 무제한으로 쓸 수 있지만 Work는 Codex 토큰을 소비함. 이 차이를 생각하지 않고 통합을 원하게 만드는 이유는 이해가 됨. Chat까지 토큰을 소비하면, 비개발자들이 명령줄에 익숙하지 않다는 것 외에는 Chat을 쓸 이유가 별로 없어짐.
Claude Chat과 Cowork는 이미 둘 다 토큰을 소비하므로 큰 변화가 아닐 수 있음. 나는 로컬 파일을 다룰 때 CLI와 IDE 조합이 훨씬 편해서 Work를 써본 적은 없지만, 비개발자에게 매력적일 수는 있음.

반복 작업이나 여러 데이터 출처를 다룰 필요가 없는 사업 질문·계획에는 GPT Chat이 더 똑똑하게 느껴짐. 반면 Work에는 프로그램으로 데이터에 접근하고 API 데이터를 가공할 수 있는 컴퓨터 환경이 주어짐.
Chat으로는 Gmail의 보고서를 읽고 역제안을 작성하는 데 성공했음. Work로는 각 선택지의 운영 시간과 등하원 규칙을 교통 상황이 반영된 지도 데이터와 대조해, 이동 시간과 대기 시간을 나눈 표를 만들었음.

지금 잘 작동하지 않는다고 사용자의 필요까지 사라지는 건 아님. 모두가 터미널 같은 인터페이스를 원하는 것은 아님. 기존 플러그인에 접근해 일정 작업을 실행하는 경우라면 전통적인 UI가 더 자연스럽고, 선택권이 있다면 굳이 채팅으로 하고 싶지 않음.

초기 버전 중에는 Codex와 ChatGPT를 UX에서 구분해 줘서 좋았음. 이번 주말에는 Codex인 줄 알고 ChatGPT를 한동안 쓰다가, 기대와 다른 동작에 실망한 뒤에야 착각을 깨달았음.

같은 채팅 제품에 똑같은 질문을 여러 번 해도 답이 크게 달라질 때가 있음.

이런 업데이트에는 출근길에 여러 기기를 오가며 Claude로 발표 자료를 만드는 낭만적인 장면이 늘 등장함. 그런데 내게는 조금 슬프게 느껴지고, 실제 생활과도 전혀 맞지 않음.

내게는 악몽 같은 시나리오임. Claude에게 발표 자료를 맡긴 뒤 출근하자마자 회의실에서 열어보면, 무관한 세부 사항과 유행어, 잘못된 차트, 혼란스러운 문장으로 채워진 엉성한 LLM 결과물이 나오는 식임.
그대로 읽고 나서 Claude가 잘못 추론한 내용에 질문을 받으면 부끄러워 죽을 것 같음. 실제로 동료들에게서 이런 일을 봤는데, 이들은 LLM 출력을 믿은 실수를 인정하는 대신 얼버무림. 수치심을 느끼는 회로가 고장 난 듯함.

다른 사람의 직업이 실제로 어떤 일인지 잘 모르지만, 로맨틱 코미디 속 직장이 어떻게 돌아가는지는 모두 익숙하기 때문임. 거기서는 늘 “금요일에 인생을 좌우할 중요한 발표가 있다”는 식으로 긴장감을 만듦.
작가들이 보통 사무직으로 일하지 않고, 사무실에 가는 때도 작품 기획을 제안할 때뿐이라서 그런 게 아닐까 싶음.

제품 발표 시연은 거의 전부 나와 무관하고 아주 좁은 계층만 겨냥하는 듯함. 늘 식당이나 스포츠 시설을 예약하거나 업무 회의용 슬라이드를 만듦.
평범한 직업을 갖고 무한정 돈을 쓰지도 않는 90%의 사람을 위한 활용법을 보여주면 더 낫지 않을까 싶음. 내가 아는 사람 중 평생 식당 예약을 한두 번 넘게 해본 사람도 거의 없고, 대부분은 아예 해본 적이 없음. 내가 특이한 것일 수도 있지만 이런 시연에는 공감하기 어려움.

“다음 달 이탈리아 여행을 계획하고 항공편을 예약해 줘” 같은 시연을 늘 보지만, 절대로 그렇게 맡기지 않을 것임.

은퇴 후 취미로 코딩하고 발표 자료나 문서는 만들지 않지만, 여러 기기를 오가는 방식은 내가 exe.dev를 쓰는 모습과 잘 맞음. AI와 대화한 뒤 진행해 달라고 하고 노트북을 닫아 다른 일을 함.
전부 웹브라우저로 사용하므로 휴대전화·태블릿·노트북 어디서든 진행 상황을 확인할 수 있음. iOS와 Android 앱도 있지만 설치할 필요를 느끼지 못했음.

우리 팀이 만든 기능이며, 궁금한 점에 답할 수 있음! 이번 출시의 핵심은 제품을 단순하게 만들면서 더 많은 기능을 제공하는 것임. 이제 대화를 시작하기 전에 작업 규모를 미리 판단할 필요가 없음. 컴퓨터 앞에 있으면 Claude가 로컬 파일과 앱을 사용하고, 노트북을 닫으면 자체 컴퓨터에서 계속 작업할 수 있음.
대화에서 Claude Design, Claude Docs, Claude Slides를 바로 쓸 수도 있음. Artifacts를 크게 강화한 덕분에 앱·웹사이트·디자인 시스템 등을 만들 때 다중 사용자 기능과 데이터베이스를 갖춘 아티팩트로 배포할 수 있음.
기능은 강력하게, 사용 경험은 단순하게 만드는 일이 정말 어려워 여러 차례 개선을 거쳤음. 아직 갈 길이 멀지만, 사용자가 덜 고민하면서 더 많은 일을 할 수 있으리라 기대함.

UX 측면에서는 분명한 개선으로 보이지만, 발표에 AI 안전과 위험 관리가 빠진 것이 눈에 띔. Chat에서는 예기치 않은 부수 효과나 민감한 파일 읽기 같은 행동이 제한적일 것으로 기대할 수 있었음.
반면 Cowork는 강력한 기능이 기본 활성화되어 있고, 끄려면 설정을 깊이 찾아보며 안전 문제도 이해해야 하는 듯함. 모드 통합은 단순하고 이해하기 쉬운 위험 관리 수단을 없애는 것처럼 느껴짐. 통합 모드는 사용자가 어떤 위험을 수용하는지 이해하고 관리하며 안심할 수 있도록 어떻게 도와줌?

질문마다 얼마나 많은 작업을 수행할지 어떻게 결정함? 문서 요약을 요청하면 Claude Chat은 대화 안에 요약을 보여주지만, Cowork는 여러 도구 호출과 중간 단계를 거쳐 결국 디스크에 문서를 저장함. 새로운 Claude는 어느 깊이까지 작업해야 할지 어떻게 판단함?

Claude Design, Claude Docs, Claude Slides가 언제, 왜 필요한지 모르겠음. 대신 유용한 기능에 집중할 수는 없는지 궁금함.

Codex는 오픈 소스인데 Claude Code는 왜 여전히 독점 소프트웨어임? 공개하려면 무엇이 필요한지 궁금함. 어떤 모델이든 개방형 에이전트에 연결할 수는 있지만 연구소들이 그런 사용 방식에는 훨씬 비싼 요금을 매기므로, 이는 Anthropic보다 OpenAI 모델을 선택할 주요 이유가 됨.

Claude Sheets도 나올 예정임? 다른 문서보다 스프레드시트 작업에 Claude를 훨씬 자주 사용함. 지금도 괜찮지만, 특히 시각화와 수식은 더 좋아질 여지가 있어 보임.

Anthropic 공식 블로그에서 Claude 특유의 문체가 뚜렷하게 느껴진 첫 글 중 하나임. 평소보다는 덜하지만, “Claude가 만든 결과물도 별도 공간이 필요하지 않음”, “기업 관리자가 활성화 시점을 선택함”, “작업을 어디에 배정할지 결정하는 것이 답답한 부분이었음”, “한쪽에서 시작한 작업이 다른 쪽으로 이어지지 않았음” 같은 표현에서 드러남.
“Claude가 언제 확인을 요청할지 선택할 수 있고, 기본적으로 행동 전에 물어보며, 원한다면 계속 작업하다 자세한 검토가 필요할 때만 확인하도록 바꿀 수 있고, 최종 결정권은 사용자에게 있음”처럼 학교 과제 수준으로 불필요하게 장황한 문장도 눈에 띔.

지식 노동자에게 필요한 것은 업무를 최대한 간단하게 자동화하는 방법인데, Anthropic은 이를 지나치게 복잡하게 만드는 느낌임. 회계사라면 Claude 앱에서 장부 정리 절차를 설명하고, 요청할 때마다 실행할 수 있는 재사용 가능한 작업 흐름을 만들어주길 원할 것임.
기본 기능은 /work와 /review 두 개면 충분함. 여기에 지침 문서를 조합하고, 작업 흐름이 다른 작업 흐름을 호출하게 하면 됨. 전부 호출 가능한 스킬로 구성할 수 있음. /balance-books로 장부 정리를 요청하면, Claude가 지침과 하위 에이전트로 장부를 살피고 저렴한 모델에 병렬 작업을 맡긴 뒤 비싼 모델로 검토하게 됨. 매번 올바른 순서와 독립적인 검토를 반복할 수 있고, 새 모델이 나와도 구조는 유지하면서 지침의 세세한 지시만 줄이면 됨. https://github.com/DanMcInerney/orchflows

Claude가 내 디스크에 원하지 않았던 대용량 가상 머신을 만든다는 사실을 알게 됨.

일반 사용자는 Chat과 Cowork 중 무엇을 골라야 할지 잘 모름. 고객 95%에게는 합리적인 변화임.

이런 변화는 이 포럼 같은 기술 사용자 5%에게는 늘 끔찍하게 느껴지겠지만, 나머지 95%에게는 전체적으로 이득이 됨.

LLM 인터페이스를 채팅 너머의 제품으로 만드는 방법을 아직 아무도 제대로 모르는 듯함. 버튼·입력 폼·레이블이 있는 전통적인 UI 대신 채팅을 고집하지만, 채팅 자체가 번거로움.
특히 차례대로 주고받는 선형 상호작용이 더 지루하고 비생산적으로 만듦.

누군가 채팅 인터페이스를 원해서라기보다, 기반 기술 자체가 말을 입력받아 말을 출력하기 때문이라고 봄. 정전식 터치스크린에서 탭·드래그·핀치가 자연스러운 것과 비슷함.

Anthropic과 OpenAI의 딜레마는 고객의 사업까지 집어삼킬 의도를 드러내지 않으면서 순수 채팅을 벗어나는 방법임.

LLM의 가능성을 아직 다 알지 못하고 몇 달마다 기준이 바뀌므로, 특정 UI를 만들면 금방 낡거나 발전 속도를 따라가지 못할 위험이 있음.
조금 똑똑한 코드 자동 완성에서 ChatGPT 복사·붙여넣기, 프로젝트 안에서 돌아가는 CLI 에이전트와 세션 관리, 이를 관리하는 GUI, 다른 세션을 지휘하는 비서실장 에이전트까지 빠르게 변해왔음. 지금은 단순하고 쉽게 바꿀 수 있는 인터페이스가 필요하며, 채팅이 여전히 가장 나은 기본값으로 보임.

트랜스포머 모델 앞에 채팅을 붙였고, 이전의 AI 채팅들처럼 폭발적으로 인기를 얻었는데 그다음은 무엇인지 계속 답답함. 누군가 LLM을 위한 새로운 상호작용 방식을 찾아내면 다음 급성장이 시작될 것임.

우리 회사에서도 이 문제를 풀고 있음. 경쟁사들은 예전에 마법사 UI나 폼의 버튼 몇 개로 하던 일에 도구 몇 개와 서로 다른 시스템 프롬프트를 연결한 범용 채팅 에이전트를 쏟아냄.
우리는 대신 A2UI와 초기 화면 메시지로 완전한 화면 기반 에이전트를 만들고 있음. 사용자에게는 평범한 웹앱처럼 보이지만 내부는 에이전트 실행 환경이 구동함. UI 갱신은 클라이언트가 새 이벤트를 받는 방식이며, 개발자가 선택하면 LLM이 이벤트를 직접 생성하거나 결정론적으로 생성할 수 있음.

Anthropic이 Claude Code와 채팅을 합치지 않길 바람. 둘의 메모리를 따로 유지하는 것이 좋음.

나는 의도적으로 채팅 메모리를 전부 꺼둠. 접근 방식을 논의하려는데 과거 기억을 끌어와 판단을 특정 방향으로 유도하는 일이 너무 성가심.

친구가 전에 대화한 주제를 Claude에게 물어봐 달라고 가볍게 부탁했는데, 아직 누구에게도 알리고 싶지 않은 비밀까지 꺼낼 수 있음. 프로젝트를 따로 만든 뒤 질문하면 되지만 번거로움.