AI 에이전트가 작업을 완료하기 위해 자체 리눅스 데스크톱과 터미널을 구동하는 방식

대부분의 비서 프로그램은 텍스트에서 멈춥니다. 답변을 하고, 사용자가 복사하여 붙여넣고, 직접 작업을 수행해야 합니다. 우리는 그 반대를 원했습니다. 즉, 자체 컴퓨터를 얻어 스스로 작업을 수행하는 에이전트입니다. 여기서는 그것이 실제로 어떻게 작동하는지, 즉 에이전트가 개인 리눅스 데스크톱과 터미널을 운영하고 실제로 작업이 완료되었음을 입증하는 과정을 설명합니다.

텍스트만으로는 충분하지 않은 이유

채팅 비서에게 "이 세 웹사이트의 Word 보고서를 작성해 줘"라고 요청하면 텍스트가 가득한 벽을 얻게 됩니다. 실제 작업은 더 많은 단계를 포함합니다. 페이지를 열고, 중요한 내용을 추출하고, 올바른 형식으로 파일을 작성하며, 파일이 존재하고 열리는지 확인한 다음, 그 위치를 알려주는 것입니다. 이것들은 문장이 아니라 기계에 대한 동작입니다.

그래서 에이전트는 하나의 기계를 얻게 됩니다. 사용자당 개인 리눅스 컴퓨터가 있으며, 여기에는 그래픽 데스크톱, 터미널, 파일 관리자가 포함되어 있습니다.

작업 공간: 네 가지 탭

사용자들은 동일한 기계의 네 가지 보기(view)를 통해 에이전트를 관찰합니다:

• Agent: 대화 내용과 단계별 로그입니다.
• Terminal: 에이전트가 타이핑하는 셸(shell)입니다.
• Files: 결과물이 저장되는 에이전트의 작업 폴더입니다.
• Computer: 브라우저 내에서 실시간으로 보이는 그래픽 데스크톱입니다.

Computer 탭은 예상보다 더 중요합니다. 로그는 에이전트가 자신이 무엇을 했다고 주장하는지를 알려줄 뿐입니다. 실시간 데스크톱은 그것을 눈으로 볼 수 있게 해줍니다. 신뢰는 후자로부터 훨씬 빠르게 얻어집니다.

루프: 계획, 실행, 검증, 보고

모든 작업은 동일한 네 단계의 과정을 거칩니다.

1. 계획(Plan). 에이전트는 요청을 작은 단계로 분할하고 각 단계에 맞는 도구를 선택합니다. 페이지 읽기를 위한 브라우저, 스크립트를 위한 셸(shell), Word/Excel/PDF 출력을 위한 문서 라이브러리 등이 있습니다.

2. 실행(Act). 에이전트는 데스크톱이나 터미널에서 한 단계씩 실행합니다. 각 단계에는 최대 제한 시간이 있으며, 전체 작업은 단계 제한(실행당 25단계)을 가지고 있어 혼란스러운 에이전트가 영원히 돌지 않도록 합니다.

3. 검증(Verify). 이 단계는 에이전트(agent)를 챗봇(chatbot)과 구분하는 지점입니다. 파일을 작성한 후, 에이전트는 단순히 "완료"라고 말하지 않습니다. 대신 다음을 확인합니다:

ls -la ~/results/report.docx          # 파일이 존재하는가, 크기가 합리적인가?
python3 -c "import docx; d = docx.Document('report.docx'); print(len(d.paragraphs))"

만약 파일이 누락되었거나, 비어 있거나, 읽을 수 없다면, 에이전트는 성공했다고 보고하는 대신 다시 작업 단계(act phase)로 돌아갑니다.

4. 보고(Report). 최종 메시지에는 무엇이 생성되었는지, 어디에 있는지, 그리고 처리할 수 없었던 내용이 포함됩니다. 파일은 다운로드 준비가 된 '파일' 탭에 있습니다.

긴 출력물: 청크 단위로 작성 (Long outputs: write in chunks)

저희의 첫 번째 버전에서는 10개 장의 문서를 한 번에 작성하려고 했습니다. 긴 생성 과정(long generations)은 중간에 잘렸고, 파일이 조용히 잘려나갔습니다(truncated). 해결책은 지루했지만 효과적이었습니다: 문서를 부분별로 작성하고 각 장을 파일에 추가한 다음, 전체 내용을 검증 단계에서 실행하고 누락된 부분이 있으면 재시도합니다. 청크 단위 작성과 검증 기능이 불안정했던 기능을 신뢰할 수 있는 기능으로 탈바꿈시켰습니다.

원칙으로서의 격리 (Isolation as a principle)

각 사용자의 기기는 오직 그들만의 것입니다: 자체 디스크 공간, 자체 프로세스, 자체 파일입니다. 사용자는 항상 자신의 기기만 보고, 에이전트는 내부의 내용물에만 접근할 수 있습니다. 우리는 이것을 최적화가 아닌 제품 규칙으로 취급합니다. 만약 에이전트가 임의의 명령(arbitrary commands)을 실행할 수 있다면, 실수로 인한 파괴 범위(blast radius)는 반드시 한 사용자의 샌드박스(sandbox) 내여야 합니다.

모바일 (Mobile)

모든 작업이 책상에서 시작되는 것은 아닙니다. 텍스트, 음성 또는 첨부 파일로 명령을 내리고 나중에 데스크톱이 보는 것과 동일한 파일에서 결과를 확인할 수 있는 Android 앱이 있습니다.

우리가 배운 점 (What we learned)

1. 출력을 검증하고 신뢰하지 마세요. 파일을 직접 확인하는 것이 고장 난 파일에 대해 사과하는 것보다 비용이 적게 듭니다.
2. 긴 내용은 청크(chunk) 단위로 나누고, 실패 시 재시도하세요.
3. 실제 데스크톱을 보여주세요. 가시성(Visibility)은 가장 저렴한 신뢰 기능입니다.
4. 채팅 입력창은 고정하고 헤더는 접을 수 있게 유지하세요. 대화에는 화면이 필요합니다.

직접 사용해보고 무엇이 깨지는지 알려주세요

이것이 바로 POSITROM AI의 아이디어입니다: 사용자가 지켜보는 동안 자체적인 개인 리눅스 컴퓨터를 얻어 작업을 완료하는 봇입니다. 만약 사용해보고 싶다면 [positrom.com]에서 할 수 있습니다. 저는 팀에 속해 있으며, 어떤 작업을 가장 먼저 맡기고 싶은지, 그리고 무엇이 이 봇에 대한 신뢰를 깨뜨릴 것인지 알고 싶습니다.