코덱스와 aside, 자동화 방식부터 갈렸다
코덱스와 aside의 자동화 방식 차이, computer use와 DOM 접근으로 갈렸다.
16일 오전 9시 35분, 에이전트코리아 방에서 한 참여자가 aside 사용법을 묻는 질문으로 하루의 도구 비교 대화가 시작됐다.
혹시 aside는 어떻게 사용하는 건가요? 지피티나 클로드에게 물어보는게 빠를려나
낮 시간이 지나며 대화는 도구 사용 습관 전반으로 번졌다. 오후 2시 48분, 다른 참여자가 작업 환경을 물었다.
다들 일하실때 터미널 몇개 정도 키고 하시나요?
이에 한 참여자는 예전엔 터미널을 열두 개까지 동시에 띄워 작업했지만, 요즘은 개별 터미널을 직접 관리하는 대신 특정 모델에게 작업 범위를 잡아 맡기는 방식으로 습관이 바뀌었다고 전했다. 여러 창을 손수 다루던 방식에서 한 모델에 범위를 통째로 위임하는 방식으로 무게중심이 옮겨간 셈이다.
오후 3시 25분에는 핵심 질문이 나왔다. 코덱스(Codex)가 이미 웹 브라우저를 잘 다루는데, aside라는 별도 유료 도구가 왜 필요하냐는 물음이었다.
선배님들 코덱스도 웹브라우저 활용 잘하는데 Aside 요게 필요한 이유가있나요? 그리고 유료결제도 잇네요..
1분 뒤 다른 참여자가 두 도구의 근본적인 차이를 짚으며 답했다.
코덱스가 아마 computer use 를 쓴다면 aside 는 스크립트 기반 DOM 접근이라
computer use(컴퓨터 사용, AI가 화면을 사람처럼 보고 마우스·키보드를 직접 조작하는 방식)와 DOM(Document Object Model, 웹페이지의 구조를 코드로 표현한 것) 기반 스크립트 접근은 같은 "브라우저 자동화"라는 목표를 서로 다른 경로로 푸는 방식이다. 화면을 보고 조작하는 쪽은 사람이 하는 일을 그대로 흉내 내는 방식이라 느리고 불안정할 수 있고, DOM을 직접 다루는 쪽은 빠르고 정교하지만 페이지 구조가 바뀌면 깨지기 쉬운 위험을 안고 있다는 취지로 읽힌다.
이날 오간 대화를 보면, 도구 선택은 단순한 취향 문제가 아니라 "화면을 보고 흉내 낼 것인가, 코드로 직접 접근할 것인가"라는 구조적 차이에서 갈린다. 아침의 입문 질문에서 오후의 구조 비교, 그리고 터미널 열두 개 대신 모델에 범위를 맡기는 작업 습관 변화까지, 하루 안에서 자동화 도구를 대하는 태도가 초심자의 궁금증부터 숙련자의 워크플로우 전환까지 폭넓게 오간 모습이다.
특히 오전의 "aside를 어떻게 쓰느냐"는 입문 질문과 오후의 "aside가 굳이 필요하냐"는 회의적 질문이 같은 날 같은 방에서 나왔다는 점이 흥미롭다. 도구를 처음 접하는 사람과 이미 코덱스를 쓰고 있는 사람이 같은 도구를 두고 정반대 방향에서 질문을 던진 셈이다. 유료 결제가 있다는 점을 짚은 질문에 "스크립트 기반이라 더 효율적"이라는 답이 나왔다는 것은, 속도와 정교함을 위해 추가 비용과 페이지 구조 변경 위험을 감수할 가치가 있는지가 이 도구 선택의 실질적인 쟁점이라는 뜻으로 읽힌다. 터미널을 열두 개씩 띄우던 방식에서 모델에 범위를 맡기는 방식으로 옮겨간 변화도, 결국 같은 방향의 흐름 — 사람이 직접 조작하던 영역을 점점 도구와 모델에 넘기는 흐름 — 위에 놓여 있다.
이 화두에는 16명이 참여해 43건의 메시지를 남겼다.