김우진
저는 올해 초에, "자기 컴퓨터를 가진 AI 동료를 만들자"는 목표로 수개월을 이에 매달린 적이 있습니다. 제가 슬랙으로 AI에게 일을 맡기면 자기 환경에서 작업하고, 막히면 질문하고, 끝나면 제가 쓰는 도구에 결과를 남기는 식으로요.
단순히 코딩해주고, 질문에 응답하는 기존 에이전트에 벗어나 훨씬 더 진보적인 형태로 만들고 싶었습니다.
그동안 저는 제 컴퓨터로 다른 일을 하고, 필요할 때 슬랙을 통해 진행 상황만 확인할 수 있으면 좋겠다고 생각했습니다.
제가 생각한 동료의 조건은 꽤 실무적이었습니다. 인간과 똑같은 작업 환경(컴퓨터, 슬랙,..)이 있고, 맡은 일을 이어갈 수 있고, 결과를 다음 작업으로 넘길 수 있는 것. 비대면으로 일하는 사람에게 업무를 맡길 때도 대부분 이런 조건을 기대하니까, AI에게도 비슷한 환경을 주면 어디까지 동료처럼 맡길 수 있을지가 궁금했습니다.
특히 일을 시작하고, 정보를 가져다주고, 결과를 전달하는 과정마다 제가 꼭 있어야 하는지가 저의 가장 큰 의문의 출발점이였습니다.
물론 ‘동료’라고 부르기에는 관계가 상당히 일방적입니다. 목표도 제가 정하고, 권한도 제가 주며, 원하면 작업을 멈출 수도 있으니까요. (그래서 제목도 노예라고, 대놓고 붙였습니다)
이 글에서는 그런 관계를 실제 업무에 넣어보고, 제가 개입하지 않아도 일이 이어지는 조건을 찾아보려 합니다. 일을 잘하는 AI 하나를 얻는 데서 그치지 않고, 사람을 항상 가운데 두는 업무 방식까지 의심해보고 싶었습니다.
제가 처음에 구상하고 실현했던 방식은 이렇습니다.
클라우드 컴퓨터에 클로드코드 세션을 띄우고 Slack으로 대화할 수 있게 연결했는데, 컴퓨터 안에 폴더를 여러 개 나눠 세션을 돌리다 보니 저는(저희는) 이걸 ‘기숙사’라고 부르게 됐어요. 각자 방은 있지만 같은 컴퓨터를 쓴다는 점에서 꽤 직관적이고 적절한 이름이었습니다.
다만 이 구조는 작업 디렉터리를 분리한 것이지, 세션마다 독립된 가상 머신이나 화면을 제공한 것은 아닙니다. 파일을 나눠 관리하는 것과 실행 환경을 격리하는 것은 별개의 문제였고, 당시에는 우선 화면을 보고 컴퓨터를 조작하는 흐름부터 구현해보려 했습니다. 웹사이트를 실제로 써보며 QA를 하거나, 로컬 skill을 개발하는 등 터미널과 파일 밖의 훨씬 더 범용적인 업무도 맡기고 싶었기 때문입니다.
방식은 단순했습니다. 화면을 캡처해서 클로드에게 보여주면 다음 행동을 판단하고, 그 판단에 따라 마우스나 키보드를 조작한 뒤 다시 캡처해 결과를 확인했습니다. 하지만 너무 치명적인 문제는, 이 단순한 루프 안에서 마우스 클릭을 처리하는 것이 정말 까다로웠다는 겁니다.
제가 붙여본 방식에서는 화면의 의미와 눌러야 할 버튼을 잘 이해하면서도, 정작 그 버튼의 정확한 좌표는 잘 얻어내지 못했습니다.
그래서 이것을 해결하기 위해 화면을 4×4로 나누고 각 영역에 코드를 붙였습니다. 클로드가 목표가 있는 영역을 선택하면 그 영역을 다시 4×4로 나눠 한 번 더 선택하게 했는데, 이렇게 하면 원래 화면의 가로와 세로를 각각 16등분한 크기까지 후보를 좁힐 수 있습니다.
클릭을 좀 더 정확하게 만들고 나니 이번에는 클릭 하나의 비용이 문제였습니다. 이미지를 읽고, 영역을 선택하고, 좁힌 이미지를 다시 읽고, 행동한 뒤 결과를 확인하는 동안 토큰 사용량과 지연이 함께 늘어났습니다. 당시 소넷을 low effort로 돌려봐도 기대한 속도는 나오지 않았고, 일을 맡겨놓고 편해지려던 저는 AI가 버튼을 누르는 과정을 기다리고 있었습니다.
정밀한 비용 측정을 하지는 않았지만, 체감한 시간과 토큰 비용으로는 계속 운영할 이유를 찾기 어려워 결국 접었습니다. 그래도 실패한 지점은 비교적 명확했습니다.범용적인 업무를 맡기는 데 컴퓨터는 필요했지만, 모든 행동을 이미지 해석과 좌표 선택으로 처리하는 고비용 방식은 제 용도에 맞지 않았습니다.
그대로 잊고 지내던 사이, 얼마 전에 OpenAI에서 Dots가 나왔습니다. 공식 설명에 따르면 Dots는 클라우드에 자기 컴퓨터와 브라우저를 가진 상시 에이전트로, 대화가 끝난 뒤에도 맡은 일을 이어갈 수 있습니다. 제 컴퓨터가 꺼져 있어도 클라우드 작업은 계속할 수 있고, 연결된 앱을 사용할 수 있고, Codex에 작업을 위임할 수도 있습니다.
(2026.10.10 기준으로 아직은 16만원 이상 플랜만을 대상으로 제공되고 있습니다)
그림 1. Dots가 클라우드 브라우저에서 첨부한 실제 자기 컴퓨터의 화면 및 소개
제가 이 기능을 보고 너무 신이 났던 이유는, 만들다가 포기했던 작업 방식이자 제가 생각했던 제품이 놀라울만큼 제가 생각했을 때에 이상적인 형태로 만들어져있었기 때문입니다.
Dots가 자기 컴퓨터를 자유롭고 아주 빠른 속도와 낮은 비용으로 다루며, 저와는 챗지피티 앱으로 상호작용 합니다. 특히, 제가 구현하며 많이 고민했었던 클라우드 컴퓨터의 인증 이슈(AI가 자신의 컴퓨터를 쓰다가 인증해야하는 순간을 맞이한 경우를 어떻게 해결할 것인가)도 꽤나 간편하고 유연하게 해결한 점이 역시 OpenAI구나 싶었습니다.
자기 환경에서 일을 이어가고, 실제 업무 도구를 사용하며, 결과를 가져오는 흐름은 제가 원했던 원격 동료의 모습과 아주 가까웠습니다. 적어도 이번에는 화면을 어떻게 읽히고 좌표를 어떻게 얻을지부터 직접 해결하지 않아도 됐습니다.
그래서 저는 바로 어떤 일을 시킬 수 있을까를 고민하게 되었고, 실험적으로 몇가지 일을 시켜봤습니다.
현재, 2학기에 운영 중인 멋쟁이사자처럼 백엔드 스터디는 각자 학습한 내용을 GitHub 저장소에 마크다운으로 제출합니다. 노트가 올라오면 내용을 읽고 질문을 남기는데, 제출 시점이 제각각이라 운영자가 계속 확인해야 합니다.
그림 2. 기존 스터디의 제출 방식. 주차별 폴더에 개인 학습노트가 쌓입니다.
질문 생성 자체는 AI에게 맡기기 쉬운 일입니다. 다만 새 제출을 발견하고, 원문을 가져오고, 질문을 작성자에게 전달하는 일을 제가 계속 한다면 제 시간에 묶인다는 점은 같습니다. 그래서 Dots에게 매시간 main 브랜치를 확인하고, 새 노트에 질문 2~3개를 만들어 GitHub 이슈로 남긴 뒤 작성자에게 할당하도록 요청했습니다.
*그림 3. Dots의 업무 설정
질문은 ‘어떤 문제를 해결하려는가 → 왜 이 설계를 선택했는가 → 조건이 달라지거나 장애가 나면 어떻게 되는가’를 따라가게 했습니다.
정의를 다시 설명하게 하는 것보다, 작성자가 선택한 설계의 경계를 생각하게 하고 싶었기 때문입니다.
반복 실행에서는 같은 노트에 질문 이슈를 계속 만드는 일이 없어야 하고, 작성자를 확인하지 못했을 때도 처리가 필요합니다. 중복 생성을 금지하고 권한·작성자 확인에 문제가 있으면 저에게 알리도록 했으며, 제출 독촉이나 점수 평가는 맡기지 않았습니다.
그 다음에는 제 자기소개 사이트를 Dots에게 줘봤습니다. 전문 UI·UX 디자이너의 관점에서 직접 사용해보고, 페이지마다 개선점을 찾아 스크린샷을 포함한 GitHub 이슈로 남겨달라고 했습니다. 제가 바로 작업에 연결할 수 있도록 개선점 하나당 이슈 하나로 정리하게 했고요.
그림 4. Dots는 22개 페이지를 확인하고 개선 이슈 11개를 만들었다고 보고했습니다.
작업 중에는 사이트맵에서 추가 페이지를 발견해 탐색 범위를 넓혔다고 알려줬습니다. 또 제 사이트가 GitHub 이슈를 블로그 글로 사용하는 구조라는 점을 확인하고, 리뷰 이슈에 발행 제외 라벨을 붙였다고 했습니다. 개선점을 찾으라고 시켰더니 블로그에 QA 보고서가 발행되는 상황까지 생길 수 있었는데, 이 부작용을 함께 살펴본 점이 정말 마음에 들었습니다.
그림 5. 목차 이동 문제를 다룬 실제 QA 이슈의 일부.
Dots가 제안한 수정으로 실제 문제가 해결되는지는 재검증이 필요하지만, 화면 증거와 개선안에 더해 첫 방문·이미지 로딩·URL hash 직접 진입 시의 완료 기준까지 남긴 결과는 제가 기대했던 탐색적 QA에 꽤 가까웠습니다.
Dots가 자신의 컴퓨터에서 자유롭게 브라우저를 열어 탐색을 진행하고 저와는 챗지피티, 그리고 깃허브 이슈로 소통하는 이것이 저는 정말 마음에 들었습니다.
지금은 실험적으로 간단한 작업 두개만 맡겨봤지만, 향후 더 다각적으로 더 진보적이고 도전적으로 Dots를 이용할수 있겠다고 생각했습니다.
단순히 지정된 범위에서 일시키는 것이 아니라, 훨씬 더 범용적인 태도로 "컴퓨터를 쥐어주고, 자유롭게 일하게 한다" 라는 멘탈 모델은 정말 가슴 설레이는 것 같습니다.
Dots에게 일을 맡겨보니, 동료가 꼭 인간일 필요는 없겠다는 생각이 아주 강하게 들었습니다.
자기 컴퓨터에서 작업하고, 결과를 GitHub에 남기고, 저는 채팅방에서 그에 대해 이야기 합니다. 몇 가지 업무만 맡겨봤지만, 일을 주고받는 방식은 원격으로 일하는 동료와 꽤 비슷했습니다. (인간이 Dots보다 나은 점은 무엇일까요?)
다음에는 Dots에게 이번에 맡겼던 작업의 연장선으로, 백엔드 스터디에서 풀리지 않은 문제를 계속 조사하는 역할을 맡겨보고 싶습니다. 제가 없는 동안 노트를 읽고 반례를 찾아둔 뒤, 돌아왔을 때 ‘지난번 설계는 이 상황에서 문제가 생긴다’며 먼저 이야기를 꺼내게 하는 겁니다. 제 질문에 답하는 것에서 더 나아가, 제가 생각하지 못한 질문을 가져오는 상대가 됐으면 합니다.
함께 일한 경험이 쌓이면 제가 Dots를 보는 방식도 달라질 것 같습니다. 이전에 어떤 일을 했고, 왜 그런 판단을 했는지 기억하면서 다음 대화를 이어갈 수 있다면, 저는 같은 상대와 계속 일하고 있다고 느낄 것 같습니다.
저는 여기서 AI를 사람처럼 대하는 실험까지 해보고 싶습니다. 스스로 일을 이어가고, 함께한 일을 기억하고, 제 의견에 근거를 들어 반대할 수 있다면 그 상대를 계속 도구로만 봐야 할까요? 적어도 저는 그 의견을 함께 일하는 동료의 의견처럼 검토해보고 싶습니다.
‘디지털 노예제’라는 제목으로 시작했지만, 제가 궁극적으로 기대하는 것은 시키는 대로만 하는 상대보다 제 생각의 빈틈도 찾아주는, 더욱 진보적인 형태의 AI에 가깝습니다. Dots와 계속 일하면서 그런 관계를 만들 수 있는지, 그리고 제가 정말 AI를 동료로 대하게 될 수 있을지도 스스로에 너무 궁금합니다.
